From xen-devel-bounces@lists.xensource.com Thu Nov 17 12:38:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 12:38:24 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1EW-0001P1-Cu
	for archives@lists.xen.org; Thu, 17 Nov 2011 12:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1E5-0000bi-9N; Thu, 17 Nov 2011 04:37:57 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR1Dx-0000aX-MJ
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 04:37:49 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1321533465!4578067!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2061 invoked from network); 17 Nov 2011 12:37:46 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 12:37:46 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=aSC1Zdh7jm5R8Q1gAwhwR2KttQDNwtyvjuZX8kpysttGQSoHUo5nG6Ea
	3cEdJIuJ49XH2zhMV4wE8tR/9e51pFSE8GDpE2rwMgBGE9KAUVgZvuavw
	WwEOmStmPcFviVP6CVTTkE5hpXETbzYSOogfAejpc0POfjTfK9NCHfmjl
	eIqiRawxJFxB7aXvXuQ9RAppOwDzd/Nc/yI5osns0I8dn1eh7mrBiKHkM
	7M1ZlYdtNukwXQNOc0LMZtYrys0LK;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321533466; x=1353069466;
	h=mime-version:subject:message-id:date:from:to;
	bh=CH3HMtKoGafvrLn6CY8DOh2WoQk+bB2a5yWLXL2JsDw=;
	b=kI3AFpV1RAeIpU8YzoXtzkvSuXU46yQnAFke84+DtACwTUvRALE5KdPW
	h0sV4jeW3qxA059IQeHPt+c0Fn6MUx/ozneMfPj/2aA8Fr/8InEg+MQ03
	cVAvruZj+a9uZTZQ40Qc6pqtdJy8pMdR+v3wmFYCxoQkGTKqgHKGtGFIL
	vIzXxWaotYYJ6qPKNqz0nkhYVii02FQ2oWMaH8D1T7JJ1DVCuHorDX/QV
	rgbaFy+l/HF2OSlgVO4pE4nZcuFO6;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="79252178"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 17 Nov 2011 13:37:45 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123235531"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 17 Nov 2011 13:37:45 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 2D829A1C20;
	Thu, 17 Nov 2011 13:37:45 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============5848945970933229940=="
MIME-Version: 1.0
X-Mercurial-Node: 7167eaa187b3cd996637b1f995707ff9196d00d3
Message-Id: <7167eaa187b3cd996637.1321533214@nehalem1>
Date: Thu, 17 Nov 2011 13:33:34 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.

Signed-off-by: juergen.gross@ts.fujitsu.com


1 file changed, 4 insertions(+)
xen/common/sched_sedf.c |    4 ++++



--===============5848945970933229940==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1321533195 -3600
# Node ID 7167eaa187b3cd996637b1f995707ff9196d00d3
# Parent  fd3567cafe1c7ccd0ddba0ad7fb067d435e13529
Avoid panic when adjusting sedf parameters

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r fd3567cafe1c -r 7167eaa187b3 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Tue Nov 15 14:50:18 2011 +0100
+++ b/xen/common/sched_sedf.c	Thu Nov 17 13:33:15 2011 +0100
@@ -1304,6 +1304,8 @@ static void sedf_dump_cpu_state(const st
     rcu_read_lock(&domlist_read_lock);
     for_each_domain ( d )
     {
+        if ( (d->cpupool ? d->cpupool->sched : &sched_sedf_def) != ops )
+            continue;
         for_each_vcpu(d, ed)
         {
             if ( !__task_on_queue(ed) && (ed->processor == i) )
@@ -1369,6 +1371,8 @@ static int sedf_adjust_weights(struct cp
     rcu_read_lock(&domlist_read_lock);
     for_each_domain( d )
     {
+        if ( c != d->cpupool )
+            continue;
         for_each_vcpu ( d, p )
         {
             if ( (cpu = p->processor) >= nr_cpus )

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

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

--===============5848945970933229940==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 12:38:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 12:38:24 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1EW-0001P1-Cu
	for archives@lists.xen.org; Thu, 17 Nov 2011 12:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1E5-0000bi-9N; Thu, 17 Nov 2011 04:37:57 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR1Dx-0000aX-MJ
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 04:37:49 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1321533465!4578067!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2061 invoked from network); 17 Nov 2011 12:37:46 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 12:37:46 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=aSC1Zdh7jm5R8Q1gAwhwR2KttQDNwtyvjuZX8kpysttGQSoHUo5nG6Ea
	3cEdJIuJ49XH2zhMV4wE8tR/9e51pFSE8GDpE2rwMgBGE9KAUVgZvuavw
	WwEOmStmPcFviVP6CVTTkE5hpXETbzYSOogfAejpc0POfjTfK9NCHfmjl
	eIqiRawxJFxB7aXvXuQ9RAppOwDzd/Nc/yI5osns0I8dn1eh7mrBiKHkM
	7M1ZlYdtNukwXQNOc0LMZtYrys0LK;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321533466; x=1353069466;
	h=mime-version:subject:message-id:date:from:to;
	bh=CH3HMtKoGafvrLn6CY8DOh2WoQk+bB2a5yWLXL2JsDw=;
	b=kI3AFpV1RAeIpU8YzoXtzkvSuXU46yQnAFke84+DtACwTUvRALE5KdPW
	h0sV4jeW3qxA059IQeHPt+c0Fn6MUx/ozneMfPj/2aA8Fr/8InEg+MQ03
	cVAvruZj+a9uZTZQ40Qc6pqtdJy8pMdR+v3wmFYCxoQkGTKqgHKGtGFIL
	vIzXxWaotYYJ6qPKNqz0nkhYVii02FQ2oWMaH8D1T7JJ1DVCuHorDX/QV
	rgbaFy+l/HF2OSlgVO4pE4nZcuFO6;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="79252178"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 17 Nov 2011 13:37:45 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123235531"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 17 Nov 2011 13:37:45 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 2D829A1C20;
	Thu, 17 Nov 2011 13:37:45 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============5848945970933229940=="
MIME-Version: 1.0
X-Mercurial-Node: 7167eaa187b3cd996637b1f995707ff9196d00d3
Message-Id: <7167eaa187b3cd996637.1321533214@nehalem1>
Date: Thu, 17 Nov 2011 13:33:34 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.

Signed-off-by: juergen.gross@ts.fujitsu.com


1 file changed, 4 insertions(+)
xen/common/sched_sedf.c |    4 ++++



--===============5848945970933229940==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1321533195 -3600
# Node ID 7167eaa187b3cd996637b1f995707ff9196d00d3
# Parent  fd3567cafe1c7ccd0ddba0ad7fb067d435e13529
Avoid panic when adjusting sedf parameters

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r fd3567cafe1c -r 7167eaa187b3 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Tue Nov 15 14:50:18 2011 +0100
+++ b/xen/common/sched_sedf.c	Thu Nov 17 13:33:15 2011 +0100
@@ -1304,6 +1304,8 @@ static void sedf_dump_cpu_state(const st
     rcu_read_lock(&domlist_read_lock);
     for_each_domain ( d )
     {
+        if ( (d->cpupool ? d->cpupool->sched : &sched_sedf_def) != ops )
+            continue;
         for_each_vcpu(d, ed)
         {
             if ( !__task_on_queue(ed) && (ed->processor == i) )
@@ -1369,6 +1371,8 @@ static int sedf_adjust_weights(struct cp
     rcu_read_lock(&domlist_read_lock);
     for_each_domain( d )
     {
+        if ( c != d->cpupool )
+            continue;
         for_each_vcpu ( d, p )
         {
             if ( (cpu = p->processor) >= nr_cpus )

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

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

--===============5848945970933229940==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 12:43:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 12:43:02 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1J0-0001hL-2M
	for archives@lists.xen.org; Thu, 17 Nov 2011 12:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1Ih-00019h-02; Thu, 17 Nov 2011 04:42:43 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR1Ia-00018d-5D
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 04:42:36 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321533753!4640753!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9854 invoked from network); 17 Nov 2011 12:42:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 12:42:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,526,1315180800"; 
   d="scan'208";a="8987273"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 12:42:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 12:42:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RR1IW-0005Uc-51; Thu, 17 Nov 2011 12:42:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RR1IV-0004Uk-Uu;
	Thu, 17 Nov 2011 12:42:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20165.306.108988.408925@mariner.uk.xensource.com>
Date: Thu, 17 Nov 2011 12:42:26 +0000
To: Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] [xen-4.1-testing test] 9805: regressions - FAIL
In-Reply-To: <496217016.20111117123211@eikelenboom.it>
References: <4EC4E1DD.1030309@canonical.com> <CAEA944D.343E5%keir@xen.org>
	<496217016.20111117123211@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>, Stefano,
	Jan Beulich <JBeulich@suse.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sander Eikelenboom writes ("Re: [Xen-devel] [xen-4.1-testing test] 9805: regressions - FAIL"):
> Don't know how much room (time wise) the machines that do the automated testing have, but additional tests based on latest 3.x and/or konrad's linux-next branch should perhaps be considered ?

Yes.  This is right at the top of my todo list, except for all the
other things that are even more urgent/important...

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 12:43:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 12:43:02 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1J0-0001hL-2M
	for archives@lists.xen.org; Thu, 17 Nov 2011 12:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1Ih-00019h-02; Thu, 17 Nov 2011 04:42:43 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR1Ia-00018d-5D
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 04:42:36 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321533753!4640753!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9854 invoked from network); 17 Nov 2011 12:42:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 12:42:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,526,1315180800"; 
   d="scan'208";a="8987273"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 12:42:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 12:42:32 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RR1IW-0005Uc-51; Thu, 17 Nov 2011 12:42:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RR1IV-0004Uk-Uu;
	Thu, 17 Nov 2011 12:42:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20165.306.108988.408925@mariner.uk.xensource.com>
Date: Thu, 17 Nov 2011 12:42:26 +0000
To: Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] [xen-4.1-testing test] 9805: regressions - FAIL
In-Reply-To: <496217016.20111117123211@eikelenboom.it>
References: <4EC4E1DD.1030309@canonical.com> <CAEA944D.343E5%keir@xen.org>
	<496217016.20111117123211@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>, Stefano,
	Jan Beulich <JBeulich@suse.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sander Eikelenboom writes ("Re: [Xen-devel] [xen-4.1-testing test] 9805: regressions - FAIL"):
> Don't know how much room (time wise) the machines that do the automated testing have, but additional tests based on latest 3.x and/or konrad's linux-next branch should perhaps be considered ?

Yes.  This is right at the top of my todo list, except for all the
other things that are even more urgent/important...

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 12:44:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 12:44:22 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1KH-0001hp-Qh
	for archives@lists.xen.org; Thu, 17 Nov 2011 12:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1K0-0001Y3-69; Thu, 17 Nov 2011 04:44:04 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR1Jr-0001VY-Be
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 04:43:55 -0800
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1321533830!3521311!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21274 invoked from network); 17 Nov 2011 12:43:51 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 12:43:51 -0000
Received: by iaby12 with SMTP id y12so2694715iab.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 04:43:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=su1q87hoTPepbkrGzZvS+ar0PZeeYyhFqqsKZHfiTfU=;
	b=bCc0f5FWgavSrynTML9J/h+frFyBVwDi5PZXaqSgm2ZspkDDUTgIfzpkV7CPkycbh1
	3+GAj7agDyaWPNqc6g9QpaAceJSCAMRQG7Nr8H48uI5FF7e/FUxfbX3tXFoF4kRoQ91x
	ARH99TZMj1iABCbEvf4ch9H43sijuB8UQq2pE=
MIME-Version: 1.0
Received: by 10.231.64.78 with SMTP id d14mr9554971ibi.56.1321533830014; Thu,
	17 Nov 2011 04:43:50 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Thu, 17 Nov 2011 04:43:49 -0800 (PST)
In-Reply-To: <7167eaa187b3cd996637.1321533214@nehalem1>
References: <7167eaa187b3cd996637.1321533214@nehalem1>
Date: Thu, 17 Nov 2011 12:43:49 +0000
X-Google-Sender-Auth: bwaKEqDk1NpHV8igxeUNkSW2SYs
Message-ID: <CAFLBxZaxpPq0AqzVEMAPZbboY7xOUt0bA7oQW3mGM9zTnEkPHw@mail.gmail.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 12:33 PM, Juergen Gross
<juergen.gross@ts.fujitsu.com> wrote:
> When using sedf scheduler in a cpupool the system might panic when settin=
g
> sedf scheduling parameters for a domain.

The cpupool structures keep track of which domain is in which pool,
right?  I wonder if a more elegant solution might be to make a
for_each_domain_cpupool() macro.

Just an idea, not a NACK; if you don't think my idea is good / don't
have time / inclination to do it now, I'm fine with this patch..

 -George


>
> Signed-off-by: juergen.gross@ts.fujitsu.com
>
>
> 1 file changed, 4 insertions(+)
> xen/common/sched_sedf.c | =A0 =A04 ++++
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 12:44:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 12:44:22 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1KH-0001hp-Qh
	for archives@lists.xen.org; Thu, 17 Nov 2011 12:44:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1K0-0001Y3-69; Thu, 17 Nov 2011 04:44:04 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR1Jr-0001VY-Be
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 04:43:55 -0800
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1321533830!3521311!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21274 invoked from network); 17 Nov 2011 12:43:51 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 12:43:51 -0000
Received: by iaby12 with SMTP id y12so2694715iab.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 04:43:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=su1q87hoTPepbkrGzZvS+ar0PZeeYyhFqqsKZHfiTfU=;
	b=bCc0f5FWgavSrynTML9J/h+frFyBVwDi5PZXaqSgm2ZspkDDUTgIfzpkV7CPkycbh1
	3+GAj7agDyaWPNqc6g9QpaAceJSCAMRQG7Nr8H48uI5FF7e/FUxfbX3tXFoF4kRoQ91x
	ARH99TZMj1iABCbEvf4ch9H43sijuB8UQq2pE=
MIME-Version: 1.0
Received: by 10.231.64.78 with SMTP id d14mr9554971ibi.56.1321533830014; Thu,
	17 Nov 2011 04:43:50 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Thu, 17 Nov 2011 04:43:49 -0800 (PST)
In-Reply-To: <7167eaa187b3cd996637.1321533214@nehalem1>
References: <7167eaa187b3cd996637.1321533214@nehalem1>
Date: Thu, 17 Nov 2011 12:43:49 +0000
X-Google-Sender-Auth: bwaKEqDk1NpHV8igxeUNkSW2SYs
Message-ID: <CAFLBxZaxpPq0AqzVEMAPZbboY7xOUt0bA7oQW3mGM9zTnEkPHw@mail.gmail.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 12:33 PM, Juergen Gross
<juergen.gross@ts.fujitsu.com> wrote:
> When using sedf scheduler in a cpupool the system might panic when settin=
g
> sedf scheduling parameters for a domain.

The cpupool structures keep track of which domain is in which pool,
right?  I wonder if a more elegant solution might be to make a
for_each_domain_cpupool() macro.

Just an idea, not a NACK; if you don't think my idea is good / don't
have time / inclination to do it now, I'm fine with this patch..

 -George


>
> Signed-off-by: juergen.gross@ts.fujitsu.com
>
>
> 1 file changed, 4 insertions(+)
> xen/common/sched_sedf.c | =A0 =A04 ++++
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 12:48:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 12:48:10 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1Nx-0001iO-Ii
	for archives@lists.xen.org; Thu, 17 Nov 2011 12:48:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1Ne-0001xj-TC; Thu, 17 Nov 2011 04:47:50 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with smtp (Exim 4.43) id 1RR1NX-0001wZ-Lr
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 04:47:44 -0800
X-Env-Sender: niall.fleming@webanywhere.co.uk
X-Msg-Ref: server-8.tower-174.messagelabs.com!1321534060!1933472!1
X-Originating-IP: [212.227.17.8]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21824 invoked from network); 17 Nov 2011 12:47:40 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8) by server-8.tower-174.messagelabs.com with SMTP;
	17 Nov 2011 12:47:40 -0000
Received: from [192.168.80.60] (host81-130-25-5.in-addr.btopenworld.com
	[81.130.25.5])
	by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis)
	id 0LfGuG-1R7Q8a07J2-00p5VV; Thu, 17 Nov 2011 13:47:40 +0100
Message-ID: <4EC5026B.6030800@webanywhere.co.uk>
Date: Thu, 17 Nov 2011 12:47:39 +0000
From: Niall Fleming <niall.fleming@webanywhere.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>
	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
In-Reply-To: <20111116142604.GA7476@phenom.dumpdata.com>
X-Provags-ID: V02:K0:MHsT3xZjU8FEJ9Kl+4bmfr6n+VmucaDtnnU/H1SGXh9
	Y7jrlaQ+GLT7hZGH/lNrKKqmXBn9Z6vZcFgCyd//SHEwd74Jp+
	Wym1fmmYZ3cAsjgBh4Xr5gXHtAcpqg9wtLntMGkVxz1qJUA3S7
	I4Bd/kuGvyLJA9Xg7+kh1qTMPxZ6o/YKvRxfCAfKLmyy0bXJnz
	+LB8Jo/f22F8BENQzDERKHcpzEAcMUmFjJUE4WotFGpStSVOOI
	mBj16b6SlUGR/yJi2aGljWlKDHqsqaxL/nHHlLuLAX/yzpMsFT
	DCj6jzid+j7gsW5ZJkETQ2roDx05zyqzkBm54HIeOD779jwvM4
	83XZe/CpJAnBEnzMSIwsXs7NBVMw3sXH+xuwZ0fmi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1242919255=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

OK, what's the lead time on getting that patched?

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

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

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

On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>> Right. With those patches too (he used the xen-settime patch set which has it).
>>> The hypercall is done (and the do_settime gets called) and the results are saved
>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>
>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>> existing guests.
>>>
>>> If you launch a new guest after the 'hwclock', the new guests
>>> retains the old wallclock time.
>> Existing (pvops) guests shouldn't see updated wallclock time, because
>> they never look at the hypervisor's wallclock after boot time.
>>
>> It's surprising that new guests don't see the updated wallclock though.
>> That sounds like a Xen issue.
> <nods>  That is what I think is happening here.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    OK, what's the lead time on getting that patched?<br>
    <div class="moz-signature"><br>
      <b>Niall Fleming BSc. (Hons)</b><br>
      Systems Administrator<br>
      Webanywhere Limited<br>
      <br>
      Phone: 0800 862 0131 Ext: 203<br>
      Web: <a class="moz-txt-link-freetext" href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a><br>
      <br>
      Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB<br>
      Registered in England with company number 4881346</div>
    <br>
    On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
    <blockquote cite="mid:20111116142604.GA7476@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Right. With those patches too (he used the xen-settime patch set which has it).
The hypercall is done (and the do_settime gets called) and the results are saved
in the RTC. And the wc_sec and wc_nsec are updated and propagated.

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

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

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

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

--------------070502040800000603080906--


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

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

--===============1242919255==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 12:48:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 12:48:10 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1Nx-0001iO-Ii
	for archives@lists.xen.org; Thu, 17 Nov 2011 12:48:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1Ne-0001xj-TC; Thu, 17 Nov 2011 04:47:50 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with smtp (Exim 4.43) id 1RR1NX-0001wZ-Lr
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 04:47:44 -0800
X-Env-Sender: niall.fleming@webanywhere.co.uk
X-Msg-Ref: server-8.tower-174.messagelabs.com!1321534060!1933472!1
X-Originating-IP: [212.227.17.8]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21824 invoked from network); 17 Nov 2011 12:47:40 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8) by server-8.tower-174.messagelabs.com with SMTP;
	17 Nov 2011 12:47:40 -0000
Received: from [192.168.80.60] (host81-130-25-5.in-addr.btopenworld.com
	[81.130.25.5])
	by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis)
	id 0LfGuG-1R7Q8a07J2-00p5VV; Thu, 17 Nov 2011 13:47:40 +0100
Message-ID: <4EC5026B.6030800@webanywhere.co.uk>
Date: Thu, 17 Nov 2011 12:47:39 +0000
From: Niall Fleming <niall.fleming@webanywhere.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>
	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
In-Reply-To: <20111116142604.GA7476@phenom.dumpdata.com>
X-Provags-ID: V02:K0:MHsT3xZjU8FEJ9Kl+4bmfr6n+VmucaDtnnU/H1SGXh9
	Y7jrlaQ+GLT7hZGH/lNrKKqmXBn9Z6vZcFgCyd//SHEwd74Jp+
	Wym1fmmYZ3cAsjgBh4Xr5gXHtAcpqg9wtLntMGkVxz1qJUA3S7
	I4Bd/kuGvyLJA9Xg7+kh1qTMPxZ6o/YKvRxfCAfKLmyy0bXJnz
	+LB8Jo/f22F8BENQzDERKHcpzEAcMUmFjJUE4WotFGpStSVOOI
	mBj16b6SlUGR/yJi2aGljWlKDHqsqaxL/nHHlLuLAX/yzpMsFT
	DCj6jzid+j7gsW5ZJkETQ2roDx05zyqzkBm54HIeOD779jwvM4
	83XZe/CpJAnBEnzMSIwsXs7NBVMw3sXH+xuwZ0fmi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1242919255=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

OK, what's the lead time on getting that patched?

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

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

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

On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>> Right. With those patches too (he used the xen-settime patch set which has it).
>>> The hypercall is done (and the do_settime gets called) and the results are saved
>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>
>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>> existing guests.
>>>
>>> If you launch a new guest after the 'hwclock', the new guests
>>> retains the old wallclock time.
>> Existing (pvops) guests shouldn't see updated wallclock time, because
>> they never look at the hypervisor's wallclock after boot time.
>>
>> It's surprising that new guests don't see the updated wallclock though.
>> That sounds like a Xen issue.
> <nods>  That is what I think is happening here.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    OK, what's the lead time on getting that patched?<br>
    <div class="moz-signature"><br>
      <b>Niall Fleming BSc. (Hons)</b><br>
      Systems Administrator<br>
      Webanywhere Limited<br>
      <br>
      Phone: 0800 862 0131 Ext: 203<br>
      Web: <a class="moz-txt-link-freetext" href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a><br>
      <br>
      Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB<br>
      Registered in England with company number 4881346</div>
    <br>
    On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
    <blockquote cite="mid:20111116142604.GA7476@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Right. With those patches too (he used the xen-settime patch set which has it).
The hypercall is done (and the do_settime gets called) and the results are saved
in the RTC. And the wc_sec and wc_nsec are updated and propagated.

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

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

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

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

--------------070502040800000603080906--


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

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

--===============1242919255==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:08:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:08:21 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1hV-0001r3-7N
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1h5-0002dy-7p; Thu, 17 Nov 2011 05:07:55 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR1gd-0002ck-0a
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:07:27 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321535243!3898823!1
X-Originating-IP: [80.70.172.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18488 invoked from network); 17 Nov 2011 13:07:23 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 13:07:23 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=oZr9yCa/2GHL3n7pYoKiCBQuMHHh44Aij0YZVhzvoS3bW+gl98YPC50A
	5w/nR5jmaZFucpt/loes3reW7YKXWSGB8DBe2ULiT5It6GL60L9bAP79x
	S0NC0wEccjzJVbEel8DMrgf4Lktfff5StN3QQcD4jC90zxrB1YD7FjmUL
	a0HFcMO1Yr6sbMSerT6Y5eX8elCRxQcMQLENEZ4pjDwwu7V3oWmbjG089
	zyjCmqgnXp6DowljiWeOzRRaAmXQL;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321535244; x=1353071244;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=mkjoJYOvEO/m/CGibLbxpaj9rNppNnrN88XbYuhuSPY=;
	b=iIyycQmMad3jUCuiC2o9abndIp55+WbylKBzW1qGbonwzlNIs+ZODzt1
	2t032YIhWra1TMJjjrBhSFr+RxArp6qA8R687mD7nZdMY5y06a+ztMzLT
	FJXHZXjR6aru+M/qHxiX2FS973h2WIDHxC3ExkTpgz+jFMujpgnOjAIAy
	achPP/1TOsLDuAAP7tfg94snIrlleOmCszQMJxBDiAe73rIAf4+nXIDtp
	xxpZB19Vb72zyMJ5mQOSZ04A5noqq;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,525,1315173600"; d="scan'208";a="93391577"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 17 Nov 2011 14:07:23 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123237547"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 17 Nov 2011 14:07:22 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id A5BDEA1C20;
	Thu, 17 Nov 2011 14:07:22 +0100 (CET)
Message-ID: <4EC5070A.1050107@ts.fujitsu.com>
Date: Thu, 17 Nov 2011 14:07:22 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
References: <7167eaa187b3cd996637.1321533214@nehalem1>
	<CAFLBxZaxpPq0AqzVEMAPZbboY7xOUt0bA7oQW3mGM9zTnEkPHw@mail.gmail.com>
In-Reply-To: <CAFLBxZaxpPq0AqzVEMAPZbboY7xOUt0bA7oQW3mGM9zTnEkPHw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/17/2011 01:43 PM, George Dunlap wrote:
> On Thu, Nov 17, 2011 at 12:33 PM, Juergen Gross
> <juergen.gross@ts.fujitsu.com>  wrote:
>> When using sedf scheduler in a cpupool the system might panic when setting
>> sedf scheduling parameters for a domain.
> The cpupool structures keep track of which domain is in which pool,
> right?  I wonder if a more elegant solution might be to make a
> for_each_domain_cpupool() macro.
>
> Just an idea, not a NACK; if you don't think my idea is good / don't
> have time / inclination to do it now, I'm fine with this patch..

Good idea. New patch coming soon.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:08:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:08:21 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1hV-0001r3-7N
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1h5-0002dy-7p; Thu, 17 Nov 2011 05:07:55 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR1gd-0002ck-0a
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:07:27 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321535243!3898823!1
X-Originating-IP: [80.70.172.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18488 invoked from network); 17 Nov 2011 13:07:23 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 13:07:23 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=oZr9yCa/2GHL3n7pYoKiCBQuMHHh44Aij0YZVhzvoS3bW+gl98YPC50A
	5w/nR5jmaZFucpt/loes3reW7YKXWSGB8DBe2ULiT5It6GL60L9bAP79x
	S0NC0wEccjzJVbEel8DMrgf4Lktfff5StN3QQcD4jC90zxrB1YD7FjmUL
	a0HFcMO1Yr6sbMSerT6Y5eX8elCRxQcMQLENEZ4pjDwwu7V3oWmbjG089
	zyjCmqgnXp6DowljiWeOzRRaAmXQL;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321535244; x=1353071244;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=mkjoJYOvEO/m/CGibLbxpaj9rNppNnrN88XbYuhuSPY=;
	b=iIyycQmMad3jUCuiC2o9abndIp55+WbylKBzW1qGbonwzlNIs+ZODzt1
	2t032YIhWra1TMJjjrBhSFr+RxArp6qA8R687mD7nZdMY5y06a+ztMzLT
	FJXHZXjR6aru+M/qHxiX2FS973h2WIDHxC3ExkTpgz+jFMujpgnOjAIAy
	achPP/1TOsLDuAAP7tfg94snIrlleOmCszQMJxBDiAe73rIAf4+nXIDtp
	xxpZB19Vb72zyMJ5mQOSZ04A5noqq;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,525,1315173600"; d="scan'208";a="93391577"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 17 Nov 2011 14:07:23 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123237547"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 17 Nov 2011 14:07:22 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id A5BDEA1C20;
	Thu, 17 Nov 2011 14:07:22 +0100 (CET)
Message-ID: <4EC5070A.1050107@ts.fujitsu.com>
Date: Thu, 17 Nov 2011 14:07:22 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
References: <7167eaa187b3cd996637.1321533214@nehalem1>
	<CAFLBxZaxpPq0AqzVEMAPZbboY7xOUt0bA7oQW3mGM9zTnEkPHw@mail.gmail.com>
In-Reply-To: <CAFLBxZaxpPq0AqzVEMAPZbboY7xOUt0bA7oQW3mGM9zTnEkPHw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/17/2011 01:43 PM, George Dunlap wrote:
> On Thu, Nov 17, 2011 at 12:33 PM, Juergen Gross
> <juergen.gross@ts.fujitsu.com>  wrote:
>> When using sedf scheduler in a cpupool the system might panic when setting
>> sedf scheduling parameters for a domain.
> The cpupool structures keep track of which domain is in which pool,
> right?  I wonder if a more elegant solution might be to make a
> for_each_domain_cpupool() macro.
>
> Just an idea, not a NACK; if you don't think my idea is good / don't
> have time / inclination to do it now, I'm fine with this patch..

Good idea. New patch coming soon.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:09:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:09:46 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1ir-0001rI-SU
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1iW-00032a-Ao; Thu, 17 Nov 2011 05:09:24 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR1h9-0002ev-Sm
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:08:02 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321535276!3528144!1
X-Originating-IP: [80.70.172.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6530 invoked from network); 17 Nov 2011 13:07:56 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 13:07:56 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=e70qjB5Y2074MJDoY6bTQAvASnRN4nI4EXESEG7Nt8hfvZOHm/5C5EUa
	YjwSwCOM+CvbMdbyqE8Pps9SQPiCaczByDbLsLyJBV1UVBQ3N3239tJbl
	9DJHbqJHQJRzLiEkN1PR4tRHtd3syAyiZKy6mM4gTTtUNATsqHvlJxfKb
	7WdkErekCZOaGyOmaVZ1oR7LA7CO4BUUWoLgjFy7ehxdwOU57/eVRL2U3
	M8Oak68lp+yl8dYZr5+lW3KikEDje;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321535276; x=1353071276;
	h=mime-version:subject:message-id:date:from:to;
	bh=EY7f7NDyXsNoSpAJJ3Syhflvn54K/x4a7nECMsQ/8aM=;
	b=Jfg3BtyT4oaRMfixp0HEJSxbrT8SG23NIt4wvti7BUyx5v4Ag3sWG/kb
	p1Av4StxBx6T3gPtr0GQ8jfS5BV8rgoa2DessvFMbLQP41k0vS5NtnAzG
	+xce0MQy5gVNX/pl4S2dV4s9DCl204y4NCSC0UShOlZOYoiCVdifyiL8t
	CQoHA3uiUDXHGlGzkZ8sKg1DOp1cNU9442HKJ3zp4fFN3391krsP4tbrJ
	N+vdcDqmOiHZcRdgt5On29GzO1dUT;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,525,1315173600"; d="scan'208";a="93391667"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 17 Nov 2011 14:07:56 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123237581"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 17 Nov 2011 14:07:55 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 168E456A5E3;
	Thu, 17 Nov 2011 14:07:56 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============2267812866842333141=="
MIME-Version: 1.0
X-Mercurial-Node: 8eea2b53adb207b8ab92148c8248b60831639e52
Message-Id: <8eea2b53adb207b8ab92.1321535022@nehalem1>
Date: Thu, 17 Nov 2011 14:03:42 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.
Introduces for_each_domain_in_cpupool macro as it is usable 4 times now.

Signed-off-by: juergen.gross@ts.fujitsu.com


4 files changed, 12 insertions(+), 11 deletions(-)
xen/common/cpupool.c    |    4 +---
xen/common/sched_sedf.c |    8 ++++----
xen/common/schedule.c   |    5 +----
xen/include/xen/sched.h |    6 ++++++



--===============2267812866842333141==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1321534918 -3600
# Node ID 8eea2b53adb207b8ab92148c8248b60831639e52
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Avoid panic when adjusting sedf parameters

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.
Introduces for_each_domain_in_cpupool macro as it is usable 4 times now.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r dbdc840f8f62 -r 8eea2b53adb2 xen/common/cpupool.c
--- a/xen/common/cpupool.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/cpupool.c	Thu Nov 17 14:01:58 2011 +0100
@@ -309,10 +309,8 @@ int cpupool_unassign_cpu(struct cpupool 
     if ( (c->n_dom > 0) && (cpumask_weight(c->cpu_valid) == 1) &&
          (cpu != cpupool_moving_cpu) )
     {
-        for_each_domain(d)
+        for_each_domain_in_cpupool(d, c)
         {
-            if ( d->cpupool != c )
-                continue;
             if ( !d->is_dying )
             {
                 ret = -EBUSY;
diff -r dbdc840f8f62 -r 8eea2b53adb2 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/sched_sedf.c	Thu Nov 17 14:01:58 2011 +0100
@@ -1304,6 +1304,8 @@ static void sedf_dump_cpu_state(const st
     rcu_read_lock(&domlist_read_lock);
     for_each_domain ( d )
     {
+        if ( (d->cpupool ? d->cpupool->sched : &sched_sedf_def) != ops )
+            continue;
         for_each_vcpu(d, ed)
         {
             if ( !__task_on_queue(ed) && (ed->processor == i) )
@@ -1335,10 +1337,8 @@ static int sedf_adjust_weights(struct cp
 
     /* Sum across all weights. */
     rcu_read_lock(&domlist_read_lock);
-    for_each_domain( d )
+    for_each_domain_in_cpupool( d, c )
     {
-        if ( c != d->cpupool )
-            continue;
         for_each_vcpu( d, p )
         {
             if ( (cpu = p->processor) >= nr_cpus )
@@ -1367,7 +1367,7 @@ static int sedf_adjust_weights(struct cp
 
     /* Adjust all slices (and periods) to the new weight. */
     rcu_read_lock(&domlist_read_lock);
-    for_each_domain( d )
+    for_each_domain_in_cpupool( d, c )
     {
         for_each_vcpu ( d, p )
         {
diff -r dbdc840f8f62 -r 8eea2b53adb2 xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/schedule.c	Thu Nov 17 14:01:58 2011 +0100
@@ -538,11 +538,8 @@ int cpu_disable_scheduler(unsigned int c
     if ( c == NULL )
         return ret;
 
-    for_each_domain ( d )
+    for_each_domain_in_cpupool ( d, c )
     {
-        if ( d->cpupool != c )
-            continue;
-
         affinity_broken = 0;
 
         for_each_vcpu ( d, v )
diff -r dbdc840f8f62 -r 8eea2b53adb2 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/xen/sched.h	Thu Nov 17 14:01:58 2011 +0100
@@ -569,6 +569,12 @@ extern struct domain *domain_list;
        (_d) != NULL;                            \
        (_d) = rcu_dereference((_d)->next_in_list )) \
 
+#define for_each_domain_in_cpupool(_d,_c)       \
+ for ( (_d) = rcu_dereference(domain_list);     \
+       (_d) != NULL;                            \
+       (_d) = rcu_dereference((_d)->next_in_list )) \
+       if ((_d)->cpupool == (_c))
+
 #define for_each_vcpu(_d,_v)                    \
  for ( (_v) = (_d)->vcpu ? (_d)->vcpu[0] : NULL; \
        (_v) != NULL;                            \

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

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

--===============2267812866842333141==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:09:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:09:46 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR1ir-0001rI-SU
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR1iW-00032a-Ao; Thu, 17 Nov 2011 05:09:24 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR1h9-0002ev-Sm
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:08:02 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321535276!3528144!1
X-Originating-IP: [80.70.172.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6530 invoked from network); 17 Nov 2011 13:07:56 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 13:07:56 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=e70qjB5Y2074MJDoY6bTQAvASnRN4nI4EXESEG7Nt8hfvZOHm/5C5EUa
	YjwSwCOM+CvbMdbyqE8Pps9SQPiCaczByDbLsLyJBV1UVBQ3N3239tJbl
	9DJHbqJHQJRzLiEkN1PR4tRHtd3syAyiZKy6mM4gTTtUNATsqHvlJxfKb
	7WdkErekCZOaGyOmaVZ1oR7LA7CO4BUUWoLgjFy7ehxdwOU57/eVRL2U3
	M8Oak68lp+yl8dYZr5+lW3KikEDje;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321535276; x=1353071276;
	h=mime-version:subject:message-id:date:from:to;
	bh=EY7f7NDyXsNoSpAJJ3Syhflvn54K/x4a7nECMsQ/8aM=;
	b=Jfg3BtyT4oaRMfixp0HEJSxbrT8SG23NIt4wvti7BUyx5v4Ag3sWG/kb
	p1Av4StxBx6T3gPtr0GQ8jfS5BV8rgoa2DessvFMbLQP41k0vS5NtnAzG
	+xce0MQy5gVNX/pl4S2dV4s9DCl204y4NCSC0UShOlZOYoiCVdifyiL8t
	CQoHA3uiUDXHGlGzkZ8sKg1DOp1cNU9442HKJ3zp4fFN3391krsP4tbrJ
	N+vdcDqmOiHZcRdgt5On29GzO1dUT;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,525,1315173600"; d="scan'208";a="93391667"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 17 Nov 2011 14:07:56 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123237581"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 17 Nov 2011 14:07:55 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 168E456A5E3;
	Thu, 17 Nov 2011 14:07:56 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============2267812866842333141=="
MIME-Version: 1.0
X-Mercurial-Node: 8eea2b53adb207b8ab92148c8248b60831639e52
Message-Id: <8eea2b53adb207b8ab92.1321535022@nehalem1>
Date: Thu, 17 Nov 2011 14:03:42 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.
Introduces for_each_domain_in_cpupool macro as it is usable 4 times now.

Signed-off-by: juergen.gross@ts.fujitsu.com


4 files changed, 12 insertions(+), 11 deletions(-)
xen/common/cpupool.c    |    4 +---
xen/common/sched_sedf.c |    8 ++++----
xen/common/schedule.c   |    5 +----
xen/include/xen/sched.h |    6 ++++++



--===============2267812866842333141==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1321534918 -3600
# Node ID 8eea2b53adb207b8ab92148c8248b60831639e52
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Avoid panic when adjusting sedf parameters

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.
Introduces for_each_domain_in_cpupool macro as it is usable 4 times now.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r dbdc840f8f62 -r 8eea2b53adb2 xen/common/cpupool.c
--- a/xen/common/cpupool.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/cpupool.c	Thu Nov 17 14:01:58 2011 +0100
@@ -309,10 +309,8 @@ int cpupool_unassign_cpu(struct cpupool 
     if ( (c->n_dom > 0) && (cpumask_weight(c->cpu_valid) == 1) &&
          (cpu != cpupool_moving_cpu) )
     {
-        for_each_domain(d)
+        for_each_domain_in_cpupool(d, c)
         {
-            if ( d->cpupool != c )
-                continue;
             if ( !d->is_dying )
             {
                 ret = -EBUSY;
diff -r dbdc840f8f62 -r 8eea2b53adb2 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/sched_sedf.c	Thu Nov 17 14:01:58 2011 +0100
@@ -1304,6 +1304,8 @@ static void sedf_dump_cpu_state(const st
     rcu_read_lock(&domlist_read_lock);
     for_each_domain ( d )
     {
+        if ( (d->cpupool ? d->cpupool->sched : &sched_sedf_def) != ops )
+            continue;
         for_each_vcpu(d, ed)
         {
             if ( !__task_on_queue(ed) && (ed->processor == i) )
@@ -1335,10 +1337,8 @@ static int sedf_adjust_weights(struct cp
 
     /* Sum across all weights. */
     rcu_read_lock(&domlist_read_lock);
-    for_each_domain( d )
+    for_each_domain_in_cpupool( d, c )
     {
-        if ( c != d->cpupool )
-            continue;
         for_each_vcpu( d, p )
         {
             if ( (cpu = p->processor) >= nr_cpus )
@@ -1367,7 +1367,7 @@ static int sedf_adjust_weights(struct cp
 
     /* Adjust all slices (and periods) to the new weight. */
     rcu_read_lock(&domlist_read_lock);
-    for_each_domain( d )
+    for_each_domain_in_cpupool( d, c )
     {
         for_each_vcpu ( d, p )
         {
diff -r dbdc840f8f62 -r 8eea2b53adb2 xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/schedule.c	Thu Nov 17 14:01:58 2011 +0100
@@ -538,11 +538,8 @@ int cpu_disable_scheduler(unsigned int c
     if ( c == NULL )
         return ret;
 
-    for_each_domain ( d )
+    for_each_domain_in_cpupool ( d, c )
     {
-        if ( d->cpupool != c )
-            continue;
-
         affinity_broken = 0;
 
         for_each_vcpu ( d, v )
diff -r dbdc840f8f62 -r 8eea2b53adb2 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/xen/sched.h	Thu Nov 17 14:01:58 2011 +0100
@@ -569,6 +569,12 @@ extern struct domain *domain_list;
        (_d) != NULL;                            \
        (_d) = rcu_dereference((_d)->next_in_list )) \
 
+#define for_each_domain_in_cpupool(_d,_c)       \
+ for ( (_d) = rcu_dereference(domain_list);     \
+       (_d) != NULL;                            \
+       (_d) = rcu_dereference((_d)->next_in_list )) \
+       if ((_d)->cpupool == (_c))
+
 #define for_each_vcpu(_d,_v)                    \
  for ( (_v) = (_d)->vcpu ? (_d)->vcpu[0] : NULL; \
        (_v) != NULL;                            \

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

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

--===============2267812866842333141==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:31:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:31:09 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR23Y-0001xV-Uj
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:31:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR23G-0003jB-GW; Thu, 17 Nov 2011 05:30:50 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR23A-0003iC-5R
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:30:44 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321536640!1952663!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14877 invoked from network); 17 Nov 2011 13:30:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 13:30:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 17 Nov 2011 13:30:39 +0000
Message-Id: <4EC51A8D0200007800061933@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 17 Nov 2011 13:30:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf
 parameters
References: <8eea2b53adb207b8ab92.1321535022@nehalem1>
In-Reply-To: <8eea2b53adb207b8ab92.1321535022@nehalem1>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.11.11 at 14:03, Juergen Gross <juergen.gross@ts.fujitsu.com> =
wrote:
>--- a/xen/include/xen/sched.h	Wed Nov 16 18:21:14 2011 +0000
>+++ b/xen/include/xen/sched.h	Thu Nov 17 14:01:58 2011 +0100
>@@ -569,6 +569,12 @@ extern struct domain *domain_list;
>        (_d) !=3D NULL;                            \
>        (_d) =3D rcu_dereference((_d)->next_in_list )) \
>=20
>+#define for_each_domain_in_cpupool(_d,_c)       \
>+ for ( (_d) =3D rcu_dereference(domain_list);     \
>+       (_d) !=3D NULL;                            \
>+       (_d) =3D rcu_dereference((_d)->next_in_list )) \

Wouldn't this, up to here, simply be for_each_domain()?

>+       if ((_d)->cpupool =3D=3D (_c))

This is dangerous - consider code like

    if ( x )
        for_each_domain_in_cpupool ()
            function();
    else
        other_stuff;

which would now associate the else with the wrong (inner) if. One
possible solution that comes to mind would be

#define for_each_domain_in_cpupool(_d,_c) \
    for_each_domain_in_cpupool (_d) \
        if ((_d)->cpupool !=3D (_c)) \
            continue; \
        else

but I think I had seen a more clever solution to this problem, but cannot
remember/locate it right now.

Jan

>+
> #define for_each_vcpu(_d,_v)                    \
>  for ( (_v) =3D (_d)->vcpu ? (_d)->vcpu[0] : NULL; \
>        (_v) !=3D NULL;                            \


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:31:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:31:09 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR23Y-0001xV-Uj
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:31:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR23G-0003jB-GW; Thu, 17 Nov 2011 05:30:50 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR23A-0003iC-5R
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:30:44 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321536640!1952663!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14877 invoked from network); 17 Nov 2011 13:30:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 13:30:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 17 Nov 2011 13:30:39 +0000
Message-Id: <4EC51A8D0200007800061933@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 17 Nov 2011 13:30:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf
 parameters
References: <8eea2b53adb207b8ab92.1321535022@nehalem1>
In-Reply-To: <8eea2b53adb207b8ab92.1321535022@nehalem1>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.11.11 at 14:03, Juergen Gross <juergen.gross@ts.fujitsu.com> =
wrote:
>--- a/xen/include/xen/sched.h	Wed Nov 16 18:21:14 2011 +0000
>+++ b/xen/include/xen/sched.h	Thu Nov 17 14:01:58 2011 +0100
>@@ -569,6 +569,12 @@ extern struct domain *domain_list;
>        (_d) !=3D NULL;                            \
>        (_d) =3D rcu_dereference((_d)->next_in_list )) \
>=20
>+#define for_each_domain_in_cpupool(_d,_c)       \
>+ for ( (_d) =3D rcu_dereference(domain_list);     \
>+       (_d) !=3D NULL;                            \
>+       (_d) =3D rcu_dereference((_d)->next_in_list )) \

Wouldn't this, up to here, simply be for_each_domain()?

>+       if ((_d)->cpupool =3D=3D (_c))

This is dangerous - consider code like

    if ( x )
        for_each_domain_in_cpupool ()
            function();
    else
        other_stuff;

which would now associate the else with the wrong (inner) if. One
possible solution that comes to mind would be

#define for_each_domain_in_cpupool(_d,_c) \
    for_each_domain_in_cpupool (_d) \
        if ((_d)->cpupool !=3D (_c)) \
            continue; \
        else

but I think I had seen a more clever solution to this problem, but cannot
remember/locate it right now.

Jan

>+
> #define for_each_vcpu(_d,_v)                    \
>  for ( (_v) =3D (_d)->vcpu ? (_d)->vcpu[0] : NULL; \
>        (_v) !=3D NULL;                            \


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:49:30 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2LK-0001yn-7n
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2Kt-0004YN-DW; Thu, 17 Nov 2011 05:49:03 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2Kj-0004X1-Mt
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:48:54 -0800
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321537688!57219381!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25254 invoked from network); 17 Nov 2011 13:48:09 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 13:48:09 -0000
Received: by ywn1 with SMTP id 1so1805177ywn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 05:48:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=8kMyfhIdiwsMLnsU976399ulaqPJYctpklxYz6riMCw=;
	b=PDCrGUXMOsTsHgwyQfKglpGh8hBkmVtW7Ei2MiNK7MqPowmmKMG9UR1CHMESsZaNJi
	ZvIeZsjKr2d4cfnmPb5+Fp4V1i8bzscuC1gLKpcdJiOsDqiPuHsj4bTjMDd6cr8EijZh
	WSPJXz3dBmJ032hSJx6mjITiE9k3mulbzWgCM=
Received: by 10.236.75.230 with SMTP id z66mr9287412yhd.66.1321537728639;
	Thu, 17 Nov 2011 05:48:48 -0800 (PST)
Received: from [10.80.114.172] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id t62sm6025996yht.0.2011.11.17.05.48.45
	(version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 05:48:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 17 Nov 2011 13:48:36 +0000
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>
Message-ID: <CAEAC134.25132%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
Thread-Index: AcylL5pw1Hce9pn+5kyrK6KRIMP8Vg==
In-Reply-To: <4EC51A8D0200007800061933@nat28.tlf.novell.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/11/2011 13:30, "Jan Beulich" <JBeulich@suse.com> wrote:

>> +#define for_each_domain_in_cpupool(_d,_c)       \
>> + for ( (_d) = rcu_dereference(domain_list);     \
>> +       (_d) != NULL;                            \
>> +       (_d) = rcu_dereference((_d)->next_in_list )) \
> 
> Wouldn't this, up to here, simply be for_each_domain()?
> 
>> +       if ((_d)->cpupool == (_c))
> 
> This is dangerous - consider code like

I also wonder (and this is true for the existing open-coded versions too)
whether we have sufficient locking around use of d->cpupool? Do these loops
hold enough locks to ensure that d->cpupool doesn't change under their feet?

 -- Keir



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:49:30 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2LK-0001yn-7n
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2Kt-0004YN-DW; Thu, 17 Nov 2011 05:49:03 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2Kj-0004X1-Mt
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:48:54 -0800
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321537688!57219381!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25254 invoked from network); 17 Nov 2011 13:48:09 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 13:48:09 -0000
Received: by ywn1 with SMTP id 1so1805177ywn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 05:48:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=8kMyfhIdiwsMLnsU976399ulaqPJYctpklxYz6riMCw=;
	b=PDCrGUXMOsTsHgwyQfKglpGh8hBkmVtW7Ei2MiNK7MqPowmmKMG9UR1CHMESsZaNJi
	ZvIeZsjKr2d4cfnmPb5+Fp4V1i8bzscuC1gLKpcdJiOsDqiPuHsj4bTjMDd6cr8EijZh
	WSPJXz3dBmJ032hSJx6mjITiE9k3mulbzWgCM=
Received: by 10.236.75.230 with SMTP id z66mr9287412yhd.66.1321537728639;
	Thu, 17 Nov 2011 05:48:48 -0800 (PST)
Received: from [10.80.114.172] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id t62sm6025996yht.0.2011.11.17.05.48.45
	(version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 05:48:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 17 Nov 2011 13:48:36 +0000
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>
Message-ID: <CAEAC134.25132%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
Thread-Index: AcylL5pw1Hce9pn+5kyrK6KRIMP8Vg==
In-Reply-To: <4EC51A8D0200007800061933@nat28.tlf.novell.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/11/2011 13:30, "Jan Beulich" <JBeulich@suse.com> wrote:

>> +#define for_each_domain_in_cpupool(_d,_c)       \
>> + for ( (_d) = rcu_dereference(domain_list);     \
>> +       (_d) != NULL;                            \
>> +       (_d) = rcu_dereference((_d)->next_in_list )) \
> 
> Wouldn't this, up to here, simply be for_each_domain()?
> 
>> +       if ((_d)->cpupool == (_c))
> 
> This is dangerous - consider code like

I also wonder (and this is true for the existing open-coded versions too)
whether we have sufficient locking around use of d->cpupool? Do these loops
hold enough locks to ensure that d->cpupool doesn't change under their feet?

 -- Keir



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:53:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:53:34 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2PG-0001z1-G3
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:53:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2Ot-00054y-6Q; Thu, 17 Nov 2011 05:53:11 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2Om-00053O-Aa
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:53:04 -0800
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1321537980!4614481!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32178 invoked from network); 17 Nov 2011 13:53:01 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 13:53:01 -0000
Received: by yenl7 with SMTP id l7so1734025yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 05:53:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HiPbjF5Q/GJ21ygk3RWsQytOpe7Q3gw4C96FSPtRB0o=;
	b=gudawA2vR/MiNQU9NtCjqg+4D5qnSpO/lNEMJAxULO3b482pvRz4Vqe2s/P/YOaS/s
	wvR4wrpKZ5ZKSCLEtJOCp/xFKFh/8Pozd6yXOXwbVFr0xo7qTezA39fTxvh9oGDL3Dsa
	kUNyEqt/KqrZhTnszit6zIyoi9+jGru0oLsn0=
Received: by 10.236.185.104 with SMTP id t68mr2036803yhm.85.1321537980083;
	Thu, 17 Nov 2011 05:53:00 -0800 (PST)
Received: from [10.80.114.172] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id n5sm6041738yhk.1.2011.11.17.05.52.57
	(version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 05:52:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 17 Nov 2011 13:52:48 +0000
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>
Message-ID: <CAEAC230.25135%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
Thread-Index: AcylMDCkouJTEqHWkk25vYsthNixeQ==
In-Reply-To: <4EC51A8D0200007800061933@nat28.tlf.novell.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/11/2011 13:30, "Jan Beulich" <JBeulich@suse.com> wrote:

> which would now associate the else with the wrong (inner) if. One
> possible solution that comes to mind would be
> 
> #define for_each_domain_in_cpupool(_d,_c) \
>     for_each_domain_in_cpupool (_d) \
>         if ((_d)->cpupool != (_c)) \
>             continue; \
>         else
> 
> but I think I had seen a more clever solution to this problem, but cannot
> remember/locate it right now.

Given the gcc ({}) construction, you could do a double-loop:
 for ( (_d) = rcu_dereference(domain_list);     \
       (_d) != NULL;                            \
       ({ while ((_d) = rcu_dereference((_d)->next_in_list != NULL)
             if ((_d)->cpupool == (_c)) break;
          (_d); }) )

A bit ugly. ;-) And I still worry about cpupool locking...

 -- Keir



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:53:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:53:34 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2PG-0001z1-G3
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:53:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2Ot-00054y-6Q; Thu, 17 Nov 2011 05:53:11 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2Om-00053O-Aa
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:53:04 -0800
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1321537980!4614481!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32178 invoked from network); 17 Nov 2011 13:53:01 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 13:53:01 -0000
Received: by yenl7 with SMTP id l7so1734025yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 05:53:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HiPbjF5Q/GJ21ygk3RWsQytOpe7Q3gw4C96FSPtRB0o=;
	b=gudawA2vR/MiNQU9NtCjqg+4D5qnSpO/lNEMJAxULO3b482pvRz4Vqe2s/P/YOaS/s
	wvR4wrpKZ5ZKSCLEtJOCp/xFKFh/8Pozd6yXOXwbVFr0xo7qTezA39fTxvh9oGDL3Dsa
	kUNyEqt/KqrZhTnszit6zIyoi9+jGru0oLsn0=
Received: by 10.236.185.104 with SMTP id t68mr2036803yhm.85.1321537980083;
	Thu, 17 Nov 2011 05:53:00 -0800 (PST)
Received: from [10.80.114.172] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id n5sm6041738yhk.1.2011.11.17.05.52.57
	(version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 05:52:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 17 Nov 2011 13:52:48 +0000
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>
Message-ID: <CAEAC230.25135%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
Thread-Index: AcylMDCkouJTEqHWkk25vYsthNixeQ==
In-Reply-To: <4EC51A8D0200007800061933@nat28.tlf.novell.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/11/2011 13:30, "Jan Beulich" <JBeulich@suse.com> wrote:

> which would now associate the else with the wrong (inner) if. One
> possible solution that comes to mind would be
> 
> #define for_each_domain_in_cpupool(_d,_c) \
>     for_each_domain_in_cpupool (_d) \
>         if ((_d)->cpupool != (_c)) \
>             continue; \
>         else
> 
> but I think I had seen a more clever solution to this problem, but cannot
> remember/locate it right now.

Given the gcc ({}) construction, you could do a double-loop:
 for ( (_d) = rcu_dereference(domain_list);     \
       (_d) != NULL;                            \
       ({ while ((_d) = rcu_dereference((_d)->next_in_list != NULL)
             if ((_d)->cpupool == (_c)) break;
          (_d); }) )

A bit ugly. ;-) And I still worry about cpupool locking...

 -- Keir



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:56:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:56:46 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2SM-0001zE-2v
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:56:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2S4-0005Ug-EO; Thu, 17 Nov 2011 05:56:28 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2Rx-0005Tc-G8
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:56:21 -0800
X-Env-Sender: ben.guthro@virtualcomputer.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321538176!4653841!1
X-Originating-IP: [72.32.253.68]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24714 invoked from network); 17 Nov 2011 13:56:18 -0000
Received: from server514a.exghost.com (HELO server514.appriver.com)
	(72.32.253.68)
	by server-3.tower-21.messagelabs.com with DES-CBC3-SHA encrypted SMTP;
	17 Nov 2011 13:56:18 -0000
X-Note-AR-ScanTimeLocal: 11/17/2011 7:56:17 AM
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Primary: ben.guthro@virtualcomputer.com
X-Note: This Email was scanned by AppRiver SecureTide
X-ALLOW: @virtualcomputer.com ALLOWED
X-Virus-Scan: V-
X-Note: Spam Tests Failed: 
X-Country-Path: PRIVATE->UNITED STATES->UNITED STATES->UNITED STATES
X-Note-Sending-IP: 72.32.253.65
X-Note-Reverse-DNS: 
X-Note-Return-Path: ben.guthro@virtualcomputer.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G211 G212 G213 G214 G218 G219 G230 G320 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: ALLOWEDSENDER
X-Note: Headers Injected
Received: from [72.32.253.65] (HELO fe04.exg4.exghost.com)
	by server514.appriver.com (CommuniGate Pro SMTP 5.4.3k)
	with ESMTP id 244067559; Thu, 17 Nov 2011 07:56:17 -0600
Received: from fe04.exg4.exghost.com ([72.32.253.153]) by
	fe04.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 17 Nov 2011 07:56:16 -0600
Received: from [10.1.1.121] ([67.192.118.157]) by fe04.exg4.exghost.com with
	Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 07:56:15 -0600
Message-ID: <4EC51292.7000302@virtualcomputer.com>
Date: Thu, 17 Nov 2011 08:56:34 -0500
From: Ben Guthro <ben.guthro@virtualcomputer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] ioperm problem
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
In-Reply-To: <20111116145730.GA11502@phenom.dumpdata.com>
Content-Type: multipart/mixed; boundary="------------090206080007060907020407"
X-OriginalArrivalTime: 17 Nov 2011 13:56:15.0755 (UTC)
	FILETIME=[AC795DB0:01CCA530]
Cc: =?UTF-8?B?UGF2ZWwgTWF0xJtqYQ==?= <pavel@netsafe.cz>,
	xen-devel@lists.xensource.com, tom.goetz@virtualcomputer.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------090206080007060907020407
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Attached is our patch to work around issues with the ioports with some 
older nVidia cards.

This, admittedly is a bit of a hack, and not exactly something that I 
would see upstream wanting to carry, for a variety of reasons. It really 
should all be predicated on whether the kernel is the initial domain, etc.

This opens up the legacy VGA ports in the VGA arbiter code.

Konrad - I think that you had suggested an alternate way of doing this, 
IIRC, but I can't seem to find it in my inbox. Due to competing demands, 
and my nVidia hardware disappearing, I never went back to rework this code.

As written, however, it did solve the problem at hand - however hacky it 
may be.

/btg

On 11/16/2011 09:57 AM, Konrad Rzeszutek Wilk wrote:
> On Sun, Nov 13, 2011 at 10:19:06PM +0100, Pavel Matěja wrote:
>> Hi,
>> I'm trying to port AMD VGA passthru patch to the latest XEN and vanila kernel
>> and I got SIGSEGV in
>>
>> static void ati_hw_out(uint16_t hport, uint32_t data)
>> {
>>      ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 1);
>>      asm volatile ("out %1, %0"::"Nd"(hport),"a"(data));
>>      ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 0);
>> }
>
> Does it work under baremetal?
>
> What is the host_pio_base?
>
> Is the host_pio_base part of the permitted IO ports? (you can
> see that if you run 'xl debug-keys q' and it should show you something
> like this:
>
> (XEN) Rangesets belonging to domain 1:
> (XEN)     I/O Ports  { b400-b41f, b800-b81f }
> (XEN)     Interrupts { 18-19, 54-55 }
> (XEN)     I/O Memory { fe940-fe9ff }
> (XEN) Memory pages belonging to domain 1:
>
> (you can get that from xm dmesg).
>
> As you can see, the b400->b41f are allowed in the domain 1. Is your
> host_pio_base in there?
>
>
>>
>> I tried old 2.6.32 XEN kernel and there is no such problem.
>> It looks related to arch/x86/kernel/ioport.c but I'm not sure.
>> Is anyone here familiar with that code?
>
> Yes, and I think I saw somebody ask me about that too.
>
> Lets rope them in this converstation - they got it to work
> but my memory is foggy at what was required.
>
> Ben, Thomas,
>
> I remember you guys had a tough time with vd86 which did something similar
> and it ultimately was due to to /dev/mem not passing in VM_IO. But the
> ioperm/outb sounds familiar too. Was there a missing hypercall when
> forking/copying the ioperm bitmap?

--------------090206080007060907020407
Content-Type: text/x-patch;
 name="vga-ioport-enable.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="vga-ioport-enable.patch"

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index ace2b16..d488426 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -421,6 +421,50 @@ bail:
 }
 EXPORT_SYMBOL(vga_put);
 
+#ifdef CONFIG_XEN
+#include <xen/xen.h>
+#include <xen/interface/physdev.h>
+#include <xen/interface/xen.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+#define IO_BITMAP_BITS 65536
+#define IO_BITMAP_BYTES (IO_BITMAP_BITS/8)
+
+#define VGA_START_PORT 0x3B0
+#define VGA_END_PORT 0x3DF
+
+static void
+vga_ioport_map(struct pci_dev *pdev)
+{
+	unsigned int i, j;
+	struct physdev_set_iobitmap op;
+	uint8_t *bitmap;
+
+	bitmap = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
+	memset(bitmap, 0xff, IO_BITMAP_BYTES);
+
+	/* PCI io bars */
+	for (i = 0; i < PCI_NUM_RESOURCES; i++)
+		if (pci_resource_flags(pdev, i) & IORESOURCE_IO)
+			for (j = pci_resource_start(pdev, i);
+				j <= pci_resource_end(pdev, i); j++)
+				__clear_bit(j, (unsigned long*)bitmap);
+
+	/* legacy vga */
+	for (i = VGA_START_PORT; i <= VGA_END_PORT; i++)
+		__clear_bit(i, (unsigned long*)bitmap);
+
+	op.bitmap = bitmap;
+	op.nr_ports = IO_BITMAP_BITS;
+	if(HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, &op) != 0)
+		pr_info("PHYSDEVOP_set_iobitmap failed\n");
+
+}
+#else
+#define vga_ioport_map(x)
+#endif
+
 /*
  * Currently, we assume that the "initial" setup of the system is
  * not sane, that is we come up with conflicting devices and let
@@ -509,6 +553,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
 		vga_iostate_to_str(vgadev->owns),
 		vga_iostate_to_str(vgadev->locks));
 
+	vga_ioport_map(pdev);
 	spin_unlock_irqrestore(&vga_lock, flags);
 	return true;
 fail:

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

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

--------------090206080007060907020407--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 13:56:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 13:56:46 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2SM-0001zE-2v
	for archives@lists.xen.org; Thu, 17 Nov 2011 13:56:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2S4-0005Ug-EO; Thu, 17 Nov 2011 05:56:28 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2Rx-0005Tc-G8
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 05:56:21 -0800
X-Env-Sender: ben.guthro@virtualcomputer.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321538176!4653841!1
X-Originating-IP: [72.32.253.68]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24714 invoked from network); 17 Nov 2011 13:56:18 -0000
Received: from server514a.exghost.com (HELO server514.appriver.com)
	(72.32.253.68)
	by server-3.tower-21.messagelabs.com with DES-CBC3-SHA encrypted SMTP;
	17 Nov 2011 13:56:18 -0000
X-Note-AR-ScanTimeLocal: 11/17/2011 7:56:17 AM
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Primary: ben.guthro@virtualcomputer.com
X-Note: This Email was scanned by AppRiver SecureTide
X-ALLOW: @virtualcomputer.com ALLOWED
X-Virus-Scan: V-
X-Note: Spam Tests Failed: 
X-Country-Path: PRIVATE->UNITED STATES->UNITED STATES->UNITED STATES
X-Note-Sending-IP: 72.32.253.65
X-Note-Reverse-DNS: 
X-Note-Return-Path: ben.guthro@virtualcomputer.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G211 G212 G213 G214 G218 G219 G230 G320 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: ALLOWEDSENDER
X-Note: Headers Injected
Received: from [72.32.253.65] (HELO fe04.exg4.exghost.com)
	by server514.appriver.com (CommuniGate Pro SMTP 5.4.3k)
	with ESMTP id 244067559; Thu, 17 Nov 2011 07:56:17 -0600
Received: from fe04.exg4.exghost.com ([72.32.253.153]) by
	fe04.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 17 Nov 2011 07:56:16 -0600
Received: from [10.1.1.121] ([67.192.118.157]) by fe04.exg4.exghost.com with
	Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 07:56:15 -0600
Message-ID: <4EC51292.7000302@virtualcomputer.com>
Date: Thu, 17 Nov 2011 08:56:34 -0500
From: Ben Guthro <ben.guthro@virtualcomputer.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] ioperm problem
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
In-Reply-To: <20111116145730.GA11502@phenom.dumpdata.com>
Content-Type: multipart/mixed; boundary="------------090206080007060907020407"
X-OriginalArrivalTime: 17 Nov 2011 13:56:15.0755 (UTC)
	FILETIME=[AC795DB0:01CCA530]
Cc: =?UTF-8?B?UGF2ZWwgTWF0xJtqYQ==?= <pavel@netsafe.cz>,
	xen-devel@lists.xensource.com, tom.goetz@virtualcomputer.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------090206080007060907020407
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Attached is our patch to work around issues with the ioports with some 
older nVidia cards.

This, admittedly is a bit of a hack, and not exactly something that I 
would see upstream wanting to carry, for a variety of reasons. It really 
should all be predicated on whether the kernel is the initial domain, etc.

This opens up the legacy VGA ports in the VGA arbiter code.

Konrad - I think that you had suggested an alternate way of doing this, 
IIRC, but I can't seem to find it in my inbox. Due to competing demands, 
and my nVidia hardware disappearing, I never went back to rework this code.

As written, however, it did solve the problem at hand - however hacky it 
may be.

/btg

On 11/16/2011 09:57 AM, Konrad Rzeszutek Wilk wrote:
> On Sun, Nov 13, 2011 at 10:19:06PM +0100, Pavel Matěja wrote:
>> Hi,
>> I'm trying to port AMD VGA passthru patch to the latest XEN and vanila kernel
>> and I got SIGSEGV in
>>
>> static void ati_hw_out(uint16_t hport, uint32_t data)
>> {
>>      ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 1);
>>      asm volatile ("out %1, %0"::"Nd"(hport),"a"(data));
>>      ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 0);
>> }
>
> Does it work under baremetal?
>
> What is the host_pio_base?
>
> Is the host_pio_base part of the permitted IO ports? (you can
> see that if you run 'xl debug-keys q' and it should show you something
> like this:
>
> (XEN) Rangesets belonging to domain 1:
> (XEN)     I/O Ports  { b400-b41f, b800-b81f }
> (XEN)     Interrupts { 18-19, 54-55 }
> (XEN)     I/O Memory { fe940-fe9ff }
> (XEN) Memory pages belonging to domain 1:
>
> (you can get that from xm dmesg).
>
> As you can see, the b400->b41f are allowed in the domain 1. Is your
> host_pio_base in there?
>
>
>>
>> I tried old 2.6.32 XEN kernel and there is no such problem.
>> It looks related to arch/x86/kernel/ioport.c but I'm not sure.
>> Is anyone here familiar with that code?
>
> Yes, and I think I saw somebody ask me about that too.
>
> Lets rope them in this converstation - they got it to work
> but my memory is foggy at what was required.
>
> Ben, Thomas,
>
> I remember you guys had a tough time with vd86 which did something similar
> and it ultimately was due to to /dev/mem not passing in VM_IO. But the
> ioperm/outb sounds familiar too. Was there a missing hypercall when
> forking/copying the ioperm bitmap?

--------------090206080007060907020407
Content-Type: text/x-patch;
 name="vga-ioport-enable.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="vga-ioport-enable.patch"

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index ace2b16..d488426 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -421,6 +421,50 @@ bail:
 }
 EXPORT_SYMBOL(vga_put);
 
+#ifdef CONFIG_XEN
+#include <xen/xen.h>
+#include <xen/interface/physdev.h>
+#include <xen/interface/xen.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+#define IO_BITMAP_BITS 65536
+#define IO_BITMAP_BYTES (IO_BITMAP_BITS/8)
+
+#define VGA_START_PORT 0x3B0
+#define VGA_END_PORT 0x3DF
+
+static void
+vga_ioport_map(struct pci_dev *pdev)
+{
+	unsigned int i, j;
+	struct physdev_set_iobitmap op;
+	uint8_t *bitmap;
+
+	bitmap = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
+	memset(bitmap, 0xff, IO_BITMAP_BYTES);
+
+	/* PCI io bars */
+	for (i = 0; i < PCI_NUM_RESOURCES; i++)
+		if (pci_resource_flags(pdev, i) & IORESOURCE_IO)
+			for (j = pci_resource_start(pdev, i);
+				j <= pci_resource_end(pdev, i); j++)
+				__clear_bit(j, (unsigned long*)bitmap);
+
+	/* legacy vga */
+	for (i = VGA_START_PORT; i <= VGA_END_PORT; i++)
+		__clear_bit(i, (unsigned long*)bitmap);
+
+	op.bitmap = bitmap;
+	op.nr_ports = IO_BITMAP_BITS;
+	if(HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, &op) != 0)
+		pr_info("PHYSDEVOP_set_iobitmap failed\n");
+
+}
+#else
+#define vga_ioport_map(x)
+#endif
+
 /*
  * Currently, we assume that the "initial" setup of the system is
  * not sane, that is we come up with conflicting devices and let
@@ -509,6 +553,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
 		vga_iostate_to_str(vgadev->owns),
 		vga_iostate_to_str(vgadev->locks));
 
+	vga_ioport_map(pdev);
 	spin_unlock_irqrestore(&vga_lock, flags);
 	return true;
 fail:

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

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

--------------090206080007060907020407--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:06:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:06:58 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2cE-0001zR-O8
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2bv-00062W-4S; Thu, 17 Nov 2011 06:06:39 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2YJ-0005xR-Kz
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:03:27 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321538571!3553818!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8141 invoked from network); 17 Nov 2011 14:02:51 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 14:02:51 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=hWvfzQXc7Ty8MYpdBFr3ZM1FaVCuN8E2zRMJT5S/JRxMfdxLRWkMkSih
	Jtx5lfoGwQ5qRmYXJz3Q1zS1O+v8jkK2MUv+UGEyIxjVExZ3mWPROAMbJ
	kpVJyhBPDYx7L3LPoHltOH09C1q+bWAEpY5Sgx+I8REGeRc7iSsXkd5jT
	vCpJQ/qPmKkpii/tXWEW/40GO7axGAfGhNp7OoOvb/qqrNseGI3jsKhiz
	WtD83GcawQ9Y8EizPp9H2CxsBhswY;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321538571; x=1353074571;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=6prDOhl5+6E8l21XsW1ASinIO3HZxQYU3364uy0BkrQ=;
	b=PK8jr/S4UGITMWlgC5vFBNoRSbXhaT9uKMYYOT+8oqREDasbjhfYP1RY
	y9LapvqwfWuA+Fc5qyIQcZqyhSaQnL4Xtx2EXXAOmhceYMJcGm7Bn8DF7
	+KM/ZK0X6pGBorOk9E05VP8yMfajimg7TvLVUZKEcwyqdFL0f3NZUdLoW
	r5yTyuPJKMDqYpCXs/daE8XNc/1bvQ9/ewQgcyBRQ2es3pjkM3Rn8Z733
	toAwQ4mVXt0zyjZTb2ByHp4y60lJx;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="79262942"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 17 Nov 2011 15:02:46 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123636543"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 17 Nov 2011 15:02:46 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 211109DF17;
	Thu, 17 Nov 2011 15:02:46 +0100 (CET)
Message-ID: <4EC51406.3090008@ts.fujitsu.com>
Date: Thu, 17 Nov 2011 15:02:46 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
References: <CAEAC134.25132%keir.xen@gmail.com>
In-Reply-To: <CAEAC134.25132%keir.xen@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/17/2011 02:48 PM, Keir Fraser wrote:
> On 17/11/2011 13:30, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>>> +#define for_each_domain_in_cpupool(_d,_c)       \
>>> + for ( (_d) = rcu_dereference(domain_list);     \
>>> +       (_d) != NULL;                            \
>>> +       (_d) = rcu_dereference((_d)->next_in_list )) \
>> Wouldn't this, up to here, simply be for_each_domain()?
>>
>>> +       if ((_d)->cpupool == (_c))
>> This is dangerous - consider code like
> I also wonder (and this is true for the existing open-coded versions too)
> whether we have sufficient locking around use of d->cpupool? Do these loops
> hold enough locks to ensure that d->cpupool doesn't change under their feet?

d->cpupool is changed in three functions:

I was just preparing a patch for cpupool_unassign_cpu() which is lacking
rcu_lock_domain().
cpupool_add_domain() is called only for domains not yet in the domain list.
sched_move_domain() is only called with domain lock held.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:06:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:06:58 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2cE-0001zR-O8
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:06:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2bv-00062W-4S; Thu, 17 Nov 2011 06:06:39 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2YJ-0005xR-Kz
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:03:27 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321538571!3553818!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8141 invoked from network); 17 Nov 2011 14:02:51 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 14:02:51 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=hWvfzQXc7Ty8MYpdBFr3ZM1FaVCuN8E2zRMJT5S/JRxMfdxLRWkMkSih
	Jtx5lfoGwQ5qRmYXJz3Q1zS1O+v8jkK2MUv+UGEyIxjVExZ3mWPROAMbJ
	kpVJyhBPDYx7L3LPoHltOH09C1q+bWAEpY5Sgx+I8REGeRc7iSsXkd5jT
	vCpJQ/qPmKkpii/tXWEW/40GO7axGAfGhNp7OoOvb/qqrNseGI3jsKhiz
	WtD83GcawQ9Y8EizPp9H2CxsBhswY;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321538571; x=1353074571;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=6prDOhl5+6E8l21XsW1ASinIO3HZxQYU3364uy0BkrQ=;
	b=PK8jr/S4UGITMWlgC5vFBNoRSbXhaT9uKMYYOT+8oqREDasbjhfYP1RY
	y9LapvqwfWuA+Fc5qyIQcZqyhSaQnL4Xtx2EXXAOmhceYMJcGm7Bn8DF7
	+KM/ZK0X6pGBorOk9E05VP8yMfajimg7TvLVUZKEcwyqdFL0f3NZUdLoW
	r5yTyuPJKMDqYpCXs/daE8XNc/1bvQ9/ewQgcyBRQ2es3pjkM3Rn8Z733
	toAwQ4mVXt0zyjZTb2ByHp4y60lJx;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="79262942"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 17 Nov 2011 15:02:46 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123636543"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 17 Nov 2011 15:02:46 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 211109DF17;
	Thu, 17 Nov 2011 15:02:46 +0100 (CET)
Message-ID: <4EC51406.3090008@ts.fujitsu.com>
Date: Thu, 17 Nov 2011 15:02:46 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
References: <CAEAC134.25132%keir.xen@gmail.com>
In-Reply-To: <CAEAC134.25132%keir.xen@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/17/2011 02:48 PM, Keir Fraser wrote:
> On 17/11/2011 13:30, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>>> +#define for_each_domain_in_cpupool(_d,_c)       \
>>> + for ( (_d) = rcu_dereference(domain_list);     \
>>> +       (_d) != NULL;                            \
>>> +       (_d) = rcu_dereference((_d)->next_in_list )) \
>> Wouldn't this, up to here, simply be for_each_domain()?
>>
>>> +       if ((_d)->cpupool == (_c))
>> This is dangerous - consider code like
> I also wonder (and this is true for the existing open-coded versions too)
> whether we have sufficient locking around use of d->cpupool? Do these loops
> hold enough locks to ensure that d->cpupool doesn't change under their feet?

d->cpupool is changed in three functions:

I was just preparing a patch for cpupool_unassign_cpu() which is lacking
rcu_lock_domain().
cpupool_add_domain() is called only for domains not yet in the domain list.
sched_move_domain() is only called with domain lock held.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:08:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:08:40 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2ds-0001zf-JM
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2da-0006Q7-RM; Thu, 17 Nov 2011 06:08:22 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2aK-0005zj-Pd
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:05:04 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321538697!1959223!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25320 invoked from network); 17 Nov 2011 14:04:57 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 14:04:57 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=LAw6C2Thz3VP8H+WlEc9KkV550SDzEoOzjmAhfN3vOYPZpAK8oDz10di
	FkTyzgl+K8w/3epzyZu320b58LeXqWPKz1PLYZIqROTnbdYyRcAIiAQnD
	vqi+ISNkY0AlGoG0SHPfvovY0cvVhl+GkKum1gvyRb0ihVpkMobTJvFWj
	rzxL4UJqnHdKqrpwHKkkpqdMa2YrNviNckFoxLolm7TighOFbiYAqrBfM
	m0rc8cUbEZnzXkBgsSVAj6PEo3tR5;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321538697; x=1353074697;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=dL/On0Wn7Ai/CxtTDm49+G+g7Us7vlnMoEKIOg23Qeo=;
	b=W7g02WN0V1vBaGcNwFjiXRXGy1r2TUg79xLpJ5Qc/ZkR1oDQr0Kpy5oK
	0NRmYH+SHbCCcCm2n5+IATuXSzTa/gdd9FrMZpCz8wf6d5RJQZozU9OF2
	7WSoclCnin8BN3RXP+ULktx9cbogdtrhxwhBqRiM5y7B0vHmGccVoi9n7
	j2kC8LE9pujwsej+7F3IGD60ZCdCBxO3rf62JVTZmjt6Cb6Ef8IyyhTqs
	NcFXC6aoHRBLv4Xbyhu8okwssB1kj;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="79263233"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 17 Nov 2011 15:04:57 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123636620"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 17 Nov 2011 15:04:57 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 5DAD495828A;
	Thu, 17 Nov 2011 15:04:57 +0100 (CET)
Message-ID: <4EC51489.4090609@ts.fujitsu.com>
Date: Thu, 17 Nov 2011 15:04:57 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
References: <CAEAC230.25135%keir.xen@gmail.com>
In-Reply-To: <CAEAC230.25135%keir.xen@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/17/2011 02:52 PM, Keir Fraser wrote:
> On 17/11/2011 13:30, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>> which would now associate the else with the wrong (inner) if. One
>> possible solution that comes to mind would be
>>
>> #define for_each_domain_in_cpupool(_d,_c) \
>>      for_each_domain_in_cpupool (_d) \
>>          if ((_d)->cpupool != (_c)) \
>>              continue; \
>>          else
>>
>> but I think I had seen a more clever solution to this problem, but cannot
>> remember/locate it right now.
> Given the gcc ({}) construction, you could do a double-loop:
>   for ( (_d) = rcu_dereference(domain_list);     \
>         (_d) != NULL;                            \
>         ({ while ((_d) = rcu_dereference((_d)->next_in_list != NULL)
>               if ((_d)->cpupool == (_c)) break;
>            (_d); }) )
>
> A bit ugly. ;-) And I still worry about cpupool locking...

What about:

static inline struct domain *next_domain_in_cpupool(
     struct domain *d, struct cpupool *c)
{
     for (d = rcu_dereference(d->next_in_list); d && d->cpupool != c;
          d = rcu_dereference(d->next_in_list));
     return d;
}

#define for_each_domain_in_cpupool(_d,_c)       \
  for ( (_d) = rcu_dereference(domain_list);     \
        (_d) != NULL;                            \
        (_d) = next_domain_in_cpupool((_d), (_c)))


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:08:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:08:40 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2ds-0001zf-JM
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:08:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2da-0006Q7-RM; Thu, 17 Nov 2011 06:08:22 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2aK-0005zj-Pd
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:05:04 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321538697!1959223!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25320 invoked from network); 17 Nov 2011 14:04:57 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 14:04:57 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=LAw6C2Thz3VP8H+WlEc9KkV550SDzEoOzjmAhfN3vOYPZpAK8oDz10di
	FkTyzgl+K8w/3epzyZu320b58LeXqWPKz1PLYZIqROTnbdYyRcAIiAQnD
	vqi+ISNkY0AlGoG0SHPfvovY0cvVhl+GkKum1gvyRb0ihVpkMobTJvFWj
	rzxL4UJqnHdKqrpwHKkkpqdMa2YrNviNckFoxLolm7TighOFbiYAqrBfM
	m0rc8cUbEZnzXkBgsSVAj6PEo3tR5;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321538697; x=1353074697;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=dL/On0Wn7Ai/CxtTDm49+G+g7Us7vlnMoEKIOg23Qeo=;
	b=W7g02WN0V1vBaGcNwFjiXRXGy1r2TUg79xLpJ5Qc/ZkR1oDQr0Kpy5oK
	0NRmYH+SHbCCcCm2n5+IATuXSzTa/gdd9FrMZpCz8wf6d5RJQZozU9OF2
	7WSoclCnin8BN3RXP+ULktx9cbogdtrhxwhBqRiM5y7B0vHmGccVoi9n7
	j2kC8LE9pujwsej+7F3IGD60ZCdCBxO3rf62JVTZmjt6Cb6Ef8IyyhTqs
	NcFXC6aoHRBLv4Xbyhu8okwssB1kj;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="79263233"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 17 Nov 2011 15:04:57 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123636620"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 17 Nov 2011 15:04:57 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 5DAD495828A;
	Thu, 17 Nov 2011 15:04:57 +0100 (CET)
Message-ID: <4EC51489.4090609@ts.fujitsu.com>
Date: Thu, 17 Nov 2011 15:04:57 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
References: <CAEAC230.25135%keir.xen@gmail.com>
In-Reply-To: <CAEAC230.25135%keir.xen@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/17/2011 02:52 PM, Keir Fraser wrote:
> On 17/11/2011 13:30, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>> which would now associate the else with the wrong (inner) if. One
>> possible solution that comes to mind would be
>>
>> #define for_each_domain_in_cpupool(_d,_c) \
>>      for_each_domain_in_cpupool (_d) \
>>          if ((_d)->cpupool != (_c)) \
>>              continue; \
>>          else
>>
>> but I think I had seen a more clever solution to this problem, but cannot
>> remember/locate it right now.
> Given the gcc ({}) construction, you could do a double-loop:
>   for ( (_d) = rcu_dereference(domain_list);     \
>         (_d) != NULL;                            \
>         ({ while ((_d) = rcu_dereference((_d)->next_in_list != NULL)
>               if ((_d)->cpupool == (_c)) break;
>            (_d); }) )
>
> A bit ugly. ;-) And I still worry about cpupool locking...

What about:

static inline struct domain *next_domain_in_cpupool(
     struct domain *d, struct cpupool *c)
{
     for (d = rcu_dereference(d->next_in_list); d && d->cpupool != c;
          d = rcu_dereference(d->next_in_list));
     return d;
}

#define for_each_domain_in_cpupool(_d,_c)       \
  for ( (_d) = rcu_dereference(domain_list);     \
        (_d) != NULL;                            \
        (_d) = next_domain_in_cpupool((_d), (_c)))


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:29:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:29:45 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2yH-0001zz-As
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:29:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2xw-00077D-9U; Thu, 17 Nov 2011 06:29:24 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2xm-000767-Kc
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:29:14 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321540150!3949683!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3408 invoked from network); 17 Nov 2011 14:29:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 14:29:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 17 Nov 2011 14:29:11 +0000
Message-Id: <4EC528450200007800061980@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 17 Nov 2011 14:29:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"Juergen Gross" <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf
 parameters
References: <4EC51A8D0200007800061933@nat28.tlf.novell.com>
	<CAEAC230.25135%keir.xen@gmail.com>
In-Reply-To: <CAEAC230.25135%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.11.11 at 14:52, Keir Fraser <keir.xen@gmail.com> wrote:
> On 17/11/2011 13:30, "Jan Beulich" <JBeulich@suse.com> wrote:
>=20
>> which would now associate the else with the wrong (inner) if. One
>> possible solution that comes to mind would be
>>=20
>> #define for_each_domain_in_cpupool(_d,_c) \
>>     for_each_domain_in_cpupool (_d) \
>>         if ((_d)->cpupool !=3D (_c)) \
>>             continue; \
>>         else
>>=20
>> but I think I had seen a more clever solution to this problem, but =
cannot
>> remember/locate it right now.
>=20
> Given the gcc ({}) construction, you could do a double-loop:
>  for ( (_d) =3D rcu_dereference(domain_list);     \
>        (_d) !=3D NULL;                            \
>        ({ while ((_d) =3D rcu_dereference((_d)->next_in_list !=3D NULL)
>              if ((_d)->cpupool =3D=3D (_c)) break;
>           (_d); }) )
>=20
> A bit ugly. ;-) And I still worry about cpupool locking...

No - the very first domain would make into the body of the loop
without its pool being checked. The (adjusted) construct would
need to go into the checking (middle) portion of the for.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:29:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:29:45 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR2yH-0001zz-As
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:29:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR2xw-00077D-9U; Thu, 17 Nov 2011 06:29:24 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR2xm-000767-Kc
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:29:14 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321540150!3949683!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3408 invoked from network); 17 Nov 2011 14:29:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 14:29:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 17 Nov 2011 14:29:11 +0000
Message-Id: <4EC528450200007800061980@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 17 Nov 2011 14:29:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"Juergen Gross" <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf
 parameters
References: <4EC51A8D0200007800061933@nat28.tlf.novell.com>
	<CAEAC230.25135%keir.xen@gmail.com>
In-Reply-To: <CAEAC230.25135%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.11.11 at 14:52, Keir Fraser <keir.xen@gmail.com> wrote:
> On 17/11/2011 13:30, "Jan Beulich" <JBeulich@suse.com> wrote:
>=20
>> which would now associate the else with the wrong (inner) if. One
>> possible solution that comes to mind would be
>>=20
>> #define for_each_domain_in_cpupool(_d,_c) \
>>     for_each_domain_in_cpupool (_d) \
>>         if ((_d)->cpupool !=3D (_c)) \
>>             continue; \
>>         else
>>=20
>> but I think I had seen a more clever solution to this problem, but =
cannot
>> remember/locate it right now.
>=20
> Given the gcc ({}) construction, you could do a double-loop:
>  for ( (_d) =3D rcu_dereference(domain_list);     \
>        (_d) !=3D NULL;                            \
>        ({ while ((_d) =3D rcu_dereference((_d)->next_in_list !=3D NULL)
>              if ((_d)->cpupool =3D=3D (_c)) break;
>           (_d); }) )
>=20
> A bit ugly. ;-) And I still worry about cpupool locking...

No - the very first domain would make into the body of the loop
without its pool being checked. The (adjusted) construct would
need to go into the checking (middle) portion of the for.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:33:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:33:38 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR322-00020D-Pd
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR31i-0007Ys-5T; Thu, 17 Nov 2011 06:33:18 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR31c-0007Xm-2L
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:33:12 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1321540332!3913037!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1536 invoked from network); 17 Nov 2011 14:32:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 14:32:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 17 Nov 2011 14:32:14 +0000
Message-Id: <4EC528FD0200007800061983@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 17 Nov 2011 14:32:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"Juergen Gross" <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf
 parameters
References: <CAEAC230.25135%keir.xen@gmail.com>
	<4EC51489.4090609@ts.fujitsu.com>
In-Reply-To: <4EC51489.4090609@ts.fujitsu.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.11.11 at 15:04, Juergen Gross <juergen.gross@ts.fujitsu.com> =
wrote:
> On 11/17/2011 02:52 PM, Keir Fraser wrote:
>> On 17/11/2011 13:30, "Jan Beulich"<JBeulich@suse.com>  wrote:
>>
>>> which would now associate the else with the wrong (inner) if. One
>>> possible solution that comes to mind would be
>>>
>>> #define for_each_domain_in_cpupool(_d,_c) \
>>>      for_each_domain_in_cpupool (_d) \
>>>          if ((_d)->cpupool !=3D (_c)) \
>>>              continue; \
>>>          else
>>>
>>> but I think I had seen a more clever solution to this problem, but =
cannot
>>> remember/locate it right now.
>> Given the gcc ({}) construction, you could do a double-loop:
>>   for ( (_d) =3D rcu_dereference(domain_list);     \
>>         (_d) !=3D NULL;                            \
>>         ({ while ((_d) =3D rcu_dereference((_d)->next_in_list !=3D =
NULL)
>>               if ((_d)->cpupool =3D=3D (_c)) break;
>>            (_d); }) )
>>
>> A bit ugly. ;-) And I still worry about cpupool locking...
>=20
> What about:
>=20
> static inline struct domain *next_domain_in_cpupool(
>      struct domain *d, struct cpupool *c)
> {
>      for (d =3D rcu_dereference(d->next_in_list); d && d->cpupool !=3D =
c;
>           d =3D rcu_dereference(d->next_in_list));
>      return d;
> }
>=20
> #define for_each_domain_in_cpupool(_d,_c)       \
>   for ( (_d) =3D rcu_dereference(domain_list);     \
>         (_d) !=3D NULL;                            \
>         (_d) =3D next_domain_in_cpupool((_d), (_c)))

Same problem as with Keir's variant - you'd enter the loop body for
the first domain on the list regardless of its cpupool. But with a
first_domain_in_cpupool() counterpart this might be usable. Or, as
said in the other reply, putting a more complex construct in the
middle clause.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:33:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:33:38 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR322-00020D-Pd
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR31i-0007Ys-5T; Thu, 17 Nov 2011 06:33:18 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR31c-0007Xm-2L
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:33:12 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1321540332!3913037!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1536 invoked from network); 17 Nov 2011 14:32:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 14:32:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 17 Nov 2011 14:32:14 +0000
Message-Id: <4EC528FD0200007800061983@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 17 Nov 2011 14:32:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"Juergen Gross" <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf
 parameters
References: <CAEAC230.25135%keir.xen@gmail.com>
	<4EC51489.4090609@ts.fujitsu.com>
In-Reply-To: <4EC51489.4090609@ts.fujitsu.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.11.11 at 15:04, Juergen Gross <juergen.gross@ts.fujitsu.com> =
wrote:
> On 11/17/2011 02:52 PM, Keir Fraser wrote:
>> On 17/11/2011 13:30, "Jan Beulich"<JBeulich@suse.com>  wrote:
>>
>>> which would now associate the else with the wrong (inner) if. One
>>> possible solution that comes to mind would be
>>>
>>> #define for_each_domain_in_cpupool(_d,_c) \
>>>      for_each_domain_in_cpupool (_d) \
>>>          if ((_d)->cpupool !=3D (_c)) \
>>>              continue; \
>>>          else
>>>
>>> but I think I had seen a more clever solution to this problem, but =
cannot
>>> remember/locate it right now.
>> Given the gcc ({}) construction, you could do a double-loop:
>>   for ( (_d) =3D rcu_dereference(domain_list);     \
>>         (_d) !=3D NULL;                            \
>>         ({ while ((_d) =3D rcu_dereference((_d)->next_in_list !=3D =
NULL)
>>               if ((_d)->cpupool =3D=3D (_c)) break;
>>            (_d); }) )
>>
>> A bit ugly. ;-) And I still worry about cpupool locking...
>=20
> What about:
>=20
> static inline struct domain *next_domain_in_cpupool(
>      struct domain *d, struct cpupool *c)
> {
>      for (d =3D rcu_dereference(d->next_in_list); d && d->cpupool !=3D =
c;
>           d =3D rcu_dereference(d->next_in_list));
>      return d;
> }
>=20
> #define for_each_domain_in_cpupool(_d,_c)       \
>   for ( (_d) =3D rcu_dereference(domain_list);     \
>         (_d) !=3D NULL;                            \
>         (_d) =3D next_domain_in_cpupool((_d), (_c)))

Same problem as with Keir's variant - you'd enter the loop body for
the first domain on the list regardless of its cpupool. But with a
first_domain_in_cpupool() counterpart this might be usable. Or, as
said in the other reply, putting a more complex construct in the
middle clause.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:40:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:40:10 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR38M-00020V-M4
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR384-00086l-82; Thu, 17 Nov 2011 06:39:52 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR37w-00085g-OS
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:39:45 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321540756!45012728!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14403 invoked from network); 17 Nov 2011 14:39:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 14:39:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170987104"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 09:39:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 09:39:39 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHEdbBY026184;	Thu, 17 Nov 2011 06:39:37 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 9aa0fdb44068548abc75cd5d8fd6c1bb6c346de2
Message-ID: <9aa0fdb44068548abc75.1321540776@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 14:39:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: dgdegra@tycho.nsa.gov, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libvchan: clean *.opic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540749 0
# Node ID 9aa0fdb44068548abc75cd5d8fd6c1bb6c346de2
# Parent  02c9422d8b8bb077988b1b383222098fa1e148b7
libvchan: clean *.opic

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

diff -r 02c9422d8b8b -r 9aa0fdb44068 tools/libvchan/Makefile
--- a/tools/libvchan/Makefile	Thu Nov 17 14:35:37 2011 +0000
+++ b/tools/libvchan/Makefile	Thu Nov 17 14:39:09 2011 +0000
@@ -52,7 +52,7 @@ install: all
 
 .PHONY: clean
 clean:
-	$(RM) -f *.o *.so* *.a vchan-node1 vchan-node2 $(DEPS)
+	$(RM) -f *.o *.opic *.so* *.a vchan-node1 vchan-node2 $(DEPS)
 
 distclean: clean
 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:40:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:40:10 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR38M-00020V-M4
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR384-00086l-82; Thu, 17 Nov 2011 06:39:52 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR37w-00085g-OS
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:39:45 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321540756!45012728!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14403 invoked from network); 17 Nov 2011 14:39:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 14:39:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170987104"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 09:39:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 09:39:39 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHEdbBY026184;	Thu, 17 Nov 2011 06:39:37 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 9aa0fdb44068548abc75cd5d8fd6c1bb6c346de2
Message-ID: <9aa0fdb44068548abc75.1321540776@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 14:39:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: dgdegra@tycho.nsa.gov, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libvchan: clean *.opic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540749 0
# Node ID 9aa0fdb44068548abc75cd5d8fd6c1bb6c346de2
# Parent  02c9422d8b8bb077988b1b383222098fa1e148b7
libvchan: clean *.opic

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

diff -r 02c9422d8b8b -r 9aa0fdb44068 tools/libvchan/Makefile
--- a/tools/libvchan/Makefile	Thu Nov 17 14:35:37 2011 +0000
+++ b/tools/libvchan/Makefile	Thu Nov 17 14:39:09 2011 +0000
@@ -52,7 +52,7 @@ install: all
 
 .PHONY: clean
 clean:
-	$(RM) -f *.o *.so* *.a vchan-node1 vchan-node2 $(DEPS)
+	$(RM) -f *.o *.opic *.so* *.a vchan-node1 vchan-node2 $(DEPS)
 
 distclean: clean
 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:43:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:43:56 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3C0-00020w-Hv
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:43:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3Bg-0000r8-L5; Thu, 17 Nov 2011 06:43:36 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR39P-0008Sn-ML
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:41:16 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321540872!3948260!1
X-Originating-IP: [80.70.172.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7313 invoked from network); 17 Nov 2011 14:41:12 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 14:41:12 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=Y9rp3T7s6CyMDZisF48T5m+AXH6JwijiedAt5+1t6tJJ+F4QWx4cz59C
	F2LrddWVuF96X8GZvRmWR6P7DK6/X2zkxLwB85Z8ia2gPdFzppSh5vuEA
	alvAVahS+TsmLEAL8zaMVEkZuN4jfQKG30SMfP7nLezkEmov0YKHz0LAh
	4kVrH+vpvKRYysGxCsTkWpXynFEATc87E13n/5NbqOkYbMMXhqCmVAkJB
	OG+5VEb2/urElt+2DLQRRkIXR5AVh;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321540872; x=1353076872;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=LBVrF5MzzN/qmo3KhGYhXbZtJw5kE4CUJCvTBYrnSdM=;
	b=XK5B9Gtu184OWGMVhQzA5I9QKp21MkboD638KC9kOAX401N+pXlK9VZO
	SSAQ3k4+MoKSppClJkoghBdswtO4L2eRuH+n+6ybWBtFbk7emhCFiAHu+
	eqpXaGB0mvf3nt3LgCGHpHySnFbKi/JUBKP0zau3btC5/323Y1Dkzv2BY
	TsTKuIuUanoNgkLX+IVD0hEiv0s7c+9fJI+et7u6K8thZia1Gwfm+94Il
	GgZwzAibINQaCuR4NEBDKKZtE5jJh;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,527,1315173600"; d="scan'208";a="93406440"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 17 Nov 2011 15:41:12 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123639280"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 17 Nov 2011 15:41:12 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id BD48E959F34;
	Thu, 17 Nov 2011 15:41:11 +0100 (CET)
Message-ID: <4EC51D07.2030302@ts.fujitsu.com>
Date: Thu, 17 Nov 2011 15:41:11 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
References: <CAEAC230.25135%keir.xen@gmail.com>	<4EC51489.4090609@ts.fujitsu.com>
	<4EC528FD0200007800061983@nat28.tlf.novell.com>
In-Reply-To: <4EC528FD0200007800061983@nat28.tlf.novell.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/17/2011 03:32 PM, Jan Beulich wrote:
>>>> On 17.11.11 at 15:04, Juergen Gross<juergen.gross@ts.fujitsu.com>  wrote:
>> On 11/17/2011 02:52 PM, Keir Fraser wrote:
>>> On 17/11/2011 13:30, "Jan Beulich"<JBeulich@suse.com>   wrote:
>>>
>>>> which would now associate the else with the wrong (inner) if. One
>>>> possible solution that comes to mind would be
>>>>
>>>> #define for_each_domain_in_cpupool(_d,_c) \
>>>>       for_each_domain_in_cpupool (_d) \
>>>>           if ((_d)->cpupool != (_c)) \
>>>>               continue; \
>>>>           else
>>>>
>>>> but I think I had seen a more clever solution to this problem, but cannot
>>>> remember/locate it right now.
>>> Given the gcc ({}) construction, you could do a double-loop:
>>>    for ( (_d) = rcu_dereference(domain_list);     \
>>>          (_d) != NULL;                            \
>>>          ({ while ((_d) = rcu_dereference((_d)->next_in_list != NULL)
>>>                if ((_d)->cpupool == (_c)) break;
>>>             (_d); }) )
>>>
>>> A bit ugly. ;-) And I still worry about cpupool locking...
>> What about:
>>
>> static inline struct domain *next_domain_in_cpupool(
>>       struct domain *d, struct cpupool *c)
>> {
>>       for (d = rcu_dereference(d->next_in_list); d&&  d->cpupool != c;
>>            d = rcu_dereference(d->next_in_list));
>>       return d;
>> }
>>
>> #define for_each_domain_in_cpupool(_d,_c)       \
>>    for ( (_d) = rcu_dereference(domain_list);     \
>>          (_d) != NULL;                            \
>>          (_d) = next_domain_in_cpupool((_d), (_c)))
> Same problem as with Keir's variant - you'd enter the loop body for
> the first domain on the list regardless of its cpupool. But with a
> first_domain_in_cpupool() counterpart this might be usable. Or, as
> said in the other reply, putting a more complex construct in the
> middle clause.

I think adding first_domain_in_cpupool() is a good way to go.
Sending out adjusted patch with appropriate locking added in
cpupool_unassign_cpu() soon.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:43:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:43:56 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3C0-00020w-Hv
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:43:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3Bg-0000r8-L5; Thu, 17 Nov 2011 06:43:36 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR39P-0008Sn-ML
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:41:16 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321540872!3948260!1
X-Originating-IP: [80.70.172.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7313 invoked from network); 17 Nov 2011 14:41:12 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 14:41:12 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=Y9rp3T7s6CyMDZisF48T5m+AXH6JwijiedAt5+1t6tJJ+F4QWx4cz59C
	F2LrddWVuF96X8GZvRmWR6P7DK6/X2zkxLwB85Z8ia2gPdFzppSh5vuEA
	alvAVahS+TsmLEAL8zaMVEkZuN4jfQKG30SMfP7nLezkEmov0YKHz0LAh
	4kVrH+vpvKRYysGxCsTkWpXynFEATc87E13n/5NbqOkYbMMXhqCmVAkJB
	OG+5VEb2/urElt+2DLQRRkIXR5AVh;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321540872; x=1353076872;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=LBVrF5MzzN/qmo3KhGYhXbZtJw5kE4CUJCvTBYrnSdM=;
	b=XK5B9Gtu184OWGMVhQzA5I9QKp21MkboD638KC9kOAX401N+pXlK9VZO
	SSAQ3k4+MoKSppClJkoghBdswtO4L2eRuH+n+6ybWBtFbk7emhCFiAHu+
	eqpXaGB0mvf3nt3LgCGHpHySnFbKi/JUBKP0zau3btC5/323Y1Dkzv2BY
	TsTKuIuUanoNgkLX+IVD0hEiv0s7c+9fJI+et7u6K8thZia1Gwfm+94Il
	GgZwzAibINQaCuR4NEBDKKZtE5jJh;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,527,1315173600"; d="scan'208";a="93406440"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 17 Nov 2011 15:41:12 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123639280"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 17 Nov 2011 15:41:12 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id BD48E959F34;
	Thu, 17 Nov 2011 15:41:11 +0100 (CET)
Message-ID: <4EC51D07.2030302@ts.fujitsu.com>
Date: Thu, 17 Nov 2011 15:41:11 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
References: <CAEAC230.25135%keir.xen@gmail.com>	<4EC51489.4090609@ts.fujitsu.com>
	<4EC528FD0200007800061983@nat28.tlf.novell.com>
In-Reply-To: <4EC528FD0200007800061983@nat28.tlf.novell.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/17/2011 03:32 PM, Jan Beulich wrote:
>>>> On 17.11.11 at 15:04, Juergen Gross<juergen.gross@ts.fujitsu.com>  wrote:
>> On 11/17/2011 02:52 PM, Keir Fraser wrote:
>>> On 17/11/2011 13:30, "Jan Beulich"<JBeulich@suse.com>   wrote:
>>>
>>>> which would now associate the else with the wrong (inner) if. One
>>>> possible solution that comes to mind would be
>>>>
>>>> #define for_each_domain_in_cpupool(_d,_c) \
>>>>       for_each_domain_in_cpupool (_d) \
>>>>           if ((_d)->cpupool != (_c)) \
>>>>               continue; \
>>>>           else
>>>>
>>>> but I think I had seen a more clever solution to this problem, but cannot
>>>> remember/locate it right now.
>>> Given the gcc ({}) construction, you could do a double-loop:
>>>    for ( (_d) = rcu_dereference(domain_list);     \
>>>          (_d) != NULL;                            \
>>>          ({ while ((_d) = rcu_dereference((_d)->next_in_list != NULL)
>>>                if ((_d)->cpupool == (_c)) break;
>>>             (_d); }) )
>>>
>>> A bit ugly. ;-) And I still worry about cpupool locking...
>> What about:
>>
>> static inline struct domain *next_domain_in_cpupool(
>>       struct domain *d, struct cpupool *c)
>> {
>>       for (d = rcu_dereference(d->next_in_list); d&&  d->cpupool != c;
>>            d = rcu_dereference(d->next_in_list));
>>       return d;
>> }
>>
>> #define for_each_domain_in_cpupool(_d,_c)       \
>>    for ( (_d) = rcu_dereference(domain_list);     \
>>          (_d) != NULL;                            \
>>          (_d) = next_domain_in_cpupool((_d), (_c)))
> Same problem as with Keir's variant - you'd enter the loop body for
> the first domain on the list regardless of its cpupool. But with a
> first_domain_in_cpupool() counterpart this might be usable. Or, as
> said in the other reply, putting a more complex construct in the
> middle clause.

I think adding first_domain_in_cpupool() is a good way to go.
Sending out adjusted patch with appropriate locking added in
cpupool_unassign_cpu() soon.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:45:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:45:01 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3D3-000219-A9
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3Ci-0001J2-7S; Thu, 17 Nov 2011 06:44:40 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3AI-0000Jj-TX
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:42:11 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1321540927!4653822!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12934 invoked from network); 17 Nov 2011 14:42:07 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 14:42:07 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=Q4LNH7EFrwhnHoUrDDJJ80h9Fa4SMUC5e4vlTEk2Y+JY57Fa7v3zLMZM
	QaVrKOns4QYCJOfiMlD7sBqxByfKcROTDQClRZr5IVUj+T99GO5kwefxI
	V499hsVcjJ0e8T4R8e5u6zpv4fF1agHq1b0kWTh6/E58k9kqvnGnhWw2b
	OXeve062MgsmbgE+1RF58pu8lTcWpScTbWKasRUna2pR2UyXmZV6pS/ii
	VPLYfI93co5VjGiU8+UyD4jZFV3Az;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321540927; x=1353076927;
	h=mime-version:subject:message-id:date:from:to;
	bh=3Te7JMLYTewFxOAyqHxxpYC3mEzNbO1jQm/GMTBq2PA=;
	b=Lm7mhQcW9hamycKTmCaFJMejuuv4DGG0aivUDz2AMAIJ0Aoj6T/u1IiH
	iurh7ySWeQ8mK9oK/M5Pvu1v6YmhwgXtRi+9phw6V1mr7hJsgjnADLjqq
	zBiT69TcmkrmNPgA1gvNIWGMtxrPyXaTpLTFvft+bpPYeCiHziRFAhKZE
	BrhNc3ZHDpeauD0peKuQ7q8qhkO4ZQeSSo0sPqrbcf5qs6hQ16cgghFQ4
	KgqLejECbo6F8KjqTn2fNUE6dYLZ3;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="79267844"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 17 Nov 2011 15:42:07 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123639329"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 17 Nov 2011 15:42:07 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id D69B8959F34;
	Thu, 17 Nov 2011 15:42:06 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============4732070679637249194=="
MIME-Version: 1.0
X-Mercurial-Node: fabc84feab2c1a6d22777cdbc670f65508e6fc46
Message-Id: <fabc84feab2c1a6d2277.1321540669@nehalem1>
Date: Thu, 17 Nov 2011 15:37:49 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.
Introduces for_each_domain_in_cpupool macro as it is usable 4 times now.
Add appropriate locking in cpupool_unassign_cpu().

Signed-off-by: juergen.gross@ts.fujitsu.com


4 files changed, 28 insertions(+), 11 deletions(-)
xen/common/cpupool.c    |    6 +++---
xen/common/sched_sedf.c |    8 ++++----
xen/common/schedule.c   |    5 +----
xen/include/xen/sched.h |   20 ++++++++++++++++++++



--===============4732070679637249194==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1321540598 -3600
# Node ID fabc84feab2c1a6d22777cdbc670f65508e6fc46
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Avoid panic when adjusting sedf parameters

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.
Introduces for_each_domain_in_cpupool macro as it is usable 4 times now.
Add appropriate locking in cpupool_unassign_cpu().

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r dbdc840f8f62 -r fabc84feab2c xen/common/cpupool.c
--- a/xen/common/cpupool.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/cpupool.c	Thu Nov 17 15:36:38 2011 +0100
@@ -309,10 +309,9 @@ int cpupool_unassign_cpu(struct cpupool 
     if ( (c->n_dom > 0) && (cpumask_weight(c->cpu_valid) == 1) &&
          (cpu != cpupool_moving_cpu) )
     {
-        for_each_domain(d)
+        rcu_read_lock(&domlist_read_lock);
+        for_each_domain_in_cpupool(d, c)
         {
-            if ( d->cpupool != c )
-                continue;
             if ( !d->is_dying )
             {
                 ret = -EBUSY;
@@ -327,6 +326,7 @@ int cpupool_unassign_cpu(struct cpupool 
             }
             cpupool0->n_dom++;
         }
+        rcu_read_unlock(&domlist_read_lock);
         if ( ret )
             goto out;
     }
diff -r dbdc840f8f62 -r fabc84feab2c xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/sched_sedf.c	Thu Nov 17 15:36:38 2011 +0100
@@ -1304,6 +1304,8 @@ static void sedf_dump_cpu_state(const st
     rcu_read_lock(&domlist_read_lock);
     for_each_domain ( d )
     {
+        if ( (d->cpupool ? d->cpupool->sched : &sched_sedf_def) != ops )
+            continue;
         for_each_vcpu(d, ed)
         {
             if ( !__task_on_queue(ed) && (ed->processor == i) )
@@ -1335,10 +1337,8 @@ static int sedf_adjust_weights(struct cp
 
     /* Sum across all weights. */
     rcu_read_lock(&domlist_read_lock);
-    for_each_domain( d )
+    for_each_domain_in_cpupool( d, c )
     {
-        if ( c != d->cpupool )
-            continue;
         for_each_vcpu( d, p )
         {
             if ( (cpu = p->processor) >= nr_cpus )
@@ -1367,7 +1367,7 @@ static int sedf_adjust_weights(struct cp
 
     /* Adjust all slices (and periods) to the new weight. */
     rcu_read_lock(&domlist_read_lock);
-    for_each_domain( d )
+    for_each_domain_in_cpupool( d, c )
     {
         for_each_vcpu ( d, p )
         {
diff -r dbdc840f8f62 -r fabc84feab2c xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/schedule.c	Thu Nov 17 15:36:38 2011 +0100
@@ -538,11 +538,8 @@ int cpu_disable_scheduler(unsigned int c
     if ( c == NULL )
         return ret;
 
-    for_each_domain ( d )
+    for_each_domain_in_cpupool ( d, c )
     {
-        if ( d->cpupool != c )
-            continue;
-
         affinity_broken = 0;
 
         for_each_vcpu ( d, v )
diff -r dbdc840f8f62 -r fabc84feab2c xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/xen/sched.h	Thu Nov 17 15:36:38 2011 +0100
@@ -564,10 +564,30 @@ extern struct domain *domain_list;
 extern struct domain *domain_list;
 
 /* Caller must hold the domlist_read_lock or domlist_update_lock. */
+static inline struct domain *first_domain_in_cpupool( struct cpupool *c)
+{
+    struct domain *d;
+    for (d = rcu_dereference(domain_list); d && d->cpupool != c;
+         d = rcu_dereference(d->next_in_list));
+    return d;
+}
+static inline struct domain *next_domain_in_cpupool(
+    struct domain *d, struct cpupool *c)
+{
+    for (d = rcu_dereference(d->next_in_list); d && d->cpupool != c;
+         d = rcu_dereference(d->next_in_list));
+    return d;
+}
+
 #define for_each_domain(_d)                     \
  for ( (_d) = rcu_dereference(domain_list);     \
        (_d) != NULL;                            \
        (_d) = rcu_dereference((_d)->next_in_list )) \
+
+#define for_each_domain_in_cpupool(_d,_c)       \
+ for ( (_d) = first_domain_in_cpupool(_c);      \
+       (_d) != NULL;                            \
+       (_d) = next_domain_in_cpupool((_d), (_c)))
 
 #define for_each_vcpu(_d,_v)                    \
  for ( (_v) = (_d)->vcpu ? (_d)->vcpu[0] : NULL; \

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

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

--===============4732070679637249194==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:45:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:45:01 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3D3-000219-A9
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3Ci-0001J2-7S; Thu, 17 Nov 2011 06:44:40 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3AI-0000Jj-TX
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:42:11 -0800
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1321540927!4653822!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12934 invoked from network); 17 Nov 2011 14:42:07 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 14:42:07 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=Q4LNH7EFrwhnHoUrDDJJ80h9Fa4SMUC5e4vlTEk2Y+JY57Fa7v3zLMZM
	QaVrKOns4QYCJOfiMlD7sBqxByfKcROTDQClRZr5IVUj+T99GO5kwefxI
	V499hsVcjJ0e8T4R8e5u6zpv4fF1agHq1b0kWTh6/E58k9kqvnGnhWw2b
	OXeve062MgsmbgE+1RF58pu8lTcWpScTbWKasRUna2pR2UyXmZV6pS/ii
	VPLYfI93co5VjGiU8+UyD4jZFV3Az;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321540927; x=1353076927;
	h=mime-version:subject:message-id:date:from:to;
	bh=3Te7JMLYTewFxOAyqHxxpYC3mEzNbO1jQm/GMTBq2PA=;
	b=Lm7mhQcW9hamycKTmCaFJMejuuv4DGG0aivUDz2AMAIJ0Aoj6T/u1IiH
	iurh7ySWeQ8mK9oK/M5Pvu1v6YmhwgXtRi+9phw6V1mr7hJsgjnADLjqq
	zBiT69TcmkrmNPgA1gvNIWGMtxrPyXaTpLTFvft+bpPYeCiHziRFAhKZE
	BrhNc3ZHDpeauD0peKuQ7q8qhkO4ZQeSSo0sPqrbcf5qs6hQ16cgghFQ4
	KgqLejECbo6F8KjqTn2fNUE6dYLZ3;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="79267844"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 17 Nov 2011 15:42:07 +0100
X-IronPort-AV: E=Sophos;i="4.69,526,1315173600"; d="scan'208";a="123639329"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 17 Nov 2011 15:42:07 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id D69B8959F34;
	Thu, 17 Nov 2011 15:42:06 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============4732070679637249194=="
MIME-Version: 1.0
X-Mercurial-Node: fabc84feab2c1a6d22777cdbc670f65508e6fc46
Message-Id: <fabc84feab2c1a6d2277.1321540669@nehalem1>
Date: Thu, 17 Nov 2011 15:37:49 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.
Introduces for_each_domain_in_cpupool macro as it is usable 4 times now.
Add appropriate locking in cpupool_unassign_cpu().

Signed-off-by: juergen.gross@ts.fujitsu.com


4 files changed, 28 insertions(+), 11 deletions(-)
xen/common/cpupool.c    |    6 +++---
xen/common/sched_sedf.c |    8 ++++----
xen/common/schedule.c   |    5 +----
xen/include/xen/sched.h |   20 ++++++++++++++++++++



--===============4732070679637249194==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1321540598 -3600
# Node ID fabc84feab2c1a6d22777cdbc670f65508e6fc46
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Avoid panic when adjusting sedf parameters

When using sedf scheduler in a cpupool the system might panic when setting
sedf scheduling parameters for a domain.
Introduces for_each_domain_in_cpupool macro as it is usable 4 times now.
Add appropriate locking in cpupool_unassign_cpu().

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r dbdc840f8f62 -r fabc84feab2c xen/common/cpupool.c
--- a/xen/common/cpupool.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/cpupool.c	Thu Nov 17 15:36:38 2011 +0100
@@ -309,10 +309,9 @@ int cpupool_unassign_cpu(struct cpupool 
     if ( (c->n_dom > 0) && (cpumask_weight(c->cpu_valid) == 1) &&
          (cpu != cpupool_moving_cpu) )
     {
-        for_each_domain(d)
+        rcu_read_lock(&domlist_read_lock);
+        for_each_domain_in_cpupool(d, c)
         {
-            if ( d->cpupool != c )
-                continue;
             if ( !d->is_dying )
             {
                 ret = -EBUSY;
@@ -327,6 +326,7 @@ int cpupool_unassign_cpu(struct cpupool 
             }
             cpupool0->n_dom++;
         }
+        rcu_read_unlock(&domlist_read_lock);
         if ( ret )
             goto out;
     }
diff -r dbdc840f8f62 -r fabc84feab2c xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/sched_sedf.c	Thu Nov 17 15:36:38 2011 +0100
@@ -1304,6 +1304,8 @@ static void sedf_dump_cpu_state(const st
     rcu_read_lock(&domlist_read_lock);
     for_each_domain ( d )
     {
+        if ( (d->cpupool ? d->cpupool->sched : &sched_sedf_def) != ops )
+            continue;
         for_each_vcpu(d, ed)
         {
             if ( !__task_on_queue(ed) && (ed->processor == i) )
@@ -1335,10 +1337,8 @@ static int sedf_adjust_weights(struct cp
 
     /* Sum across all weights. */
     rcu_read_lock(&domlist_read_lock);
-    for_each_domain( d )
+    for_each_domain_in_cpupool( d, c )
     {
-        if ( c != d->cpupool )
-            continue;
         for_each_vcpu( d, p )
         {
             if ( (cpu = p->processor) >= nr_cpus )
@@ -1367,7 +1367,7 @@ static int sedf_adjust_weights(struct cp
 
     /* Adjust all slices (and periods) to the new weight. */
     rcu_read_lock(&domlist_read_lock);
-    for_each_domain( d )
+    for_each_domain_in_cpupool( d, c )
     {
         for_each_vcpu ( d, p )
         {
diff -r dbdc840f8f62 -r fabc84feab2c xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/schedule.c	Thu Nov 17 15:36:38 2011 +0100
@@ -538,11 +538,8 @@ int cpu_disable_scheduler(unsigned int c
     if ( c == NULL )
         return ret;
 
-    for_each_domain ( d )
+    for_each_domain_in_cpupool ( d, c )
     {
-        if ( d->cpupool != c )
-            continue;
-
         affinity_broken = 0;
 
         for_each_vcpu ( d, v )
diff -r dbdc840f8f62 -r fabc84feab2c xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/xen/sched.h	Thu Nov 17 15:36:38 2011 +0100
@@ -564,10 +564,30 @@ extern struct domain *domain_list;
 extern struct domain *domain_list;
 
 /* Caller must hold the domlist_read_lock or domlist_update_lock. */
+static inline struct domain *first_domain_in_cpupool( struct cpupool *c)
+{
+    struct domain *d;
+    for (d = rcu_dereference(domain_list); d && d->cpupool != c;
+         d = rcu_dereference(d->next_in_list));
+    return d;
+}
+static inline struct domain *next_domain_in_cpupool(
+    struct domain *d, struct cpupool *c)
+{
+    for (d = rcu_dereference(d->next_in_list); d && d->cpupool != c;
+         d = rcu_dereference(d->next_in_list));
+    return d;
+}
+
 #define for_each_domain(_d)                     \
  for ( (_d) = rcu_dereference(domain_list);     \
        (_d) != NULL;                            \
        (_d) = rcu_dereference((_d)->next_in_list )) \
+
+#define for_each_domain_in_cpupool(_d,_c)       \
+ for ( (_d) = first_domain_in_cpupool(_c);      \
+       (_d) != NULL;                            \
+       (_d) = next_domain_in_cpupool((_d), (_c)))
 
 #define for_each_vcpu(_d,_v)                    \
  for ( (_v) = (_d)->vcpu ? (_d)->vcpu[0] : NULL; \

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

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

--===============4732070679637249194==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:45:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:45:59 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3Dz-00021M-1F
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3De-0001gP-MZ; Thu, 17 Nov 2011 06:45:38 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3BZ-0000pL-KT
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:43:30 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321541005!1965673!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17686 invoked from network); 17 Nov 2011 14:43:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 14:43:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 17 Nov 2011 14:43:27 +0000
Message-Id: <4EC52B9D020000780006199E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 17 Nov 2011 14:43:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part634CE59D.0__="
Cc: Charles Arnold <CARNOLD@suse.com>, Bruce Rogers <BROGERS@suse.com>
Subject: [Xen-devel] [PATCH] x86/xsave: provide guests with finit-like
	environment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

Without the use of xsave, guests get their initial floating point
environment set up with finit. At least NetWare actually depends on
this (in particular on all exceptions being masked), so to be
consistent set the same environment also when using xsave. This is
also in line with all SSE exceptions getting masked initially.

To avoid further fragile casts in xstate_alloc_save_area() the patch
also changes xsave_struct's fpu_see member to have actually usable
fields.

The patch was tested in its technically identical, but modified-file-
wise different 4.1.2 version.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Charles Arnold <carnold@suse.com>

--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -17,7 +17,6 @@
 #include <asm/xstate.h>
 #include <asm/asm_defns.h>
=20
-#define MXCSR_DEFAULT 0x1f80
 static void fpu_init(void)
 {
     unsigned long val;
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -97,7 +97,7 @@ bool_t xsave_enabled(const struct vcpu *
=20
 int xstate_alloc_save_area(struct vcpu *v)
 {
-    void *save_area;
+    struct xsave_struct *save_area;
=20
     if ( !cpu_has_xsave || is_idle_vcpu(v) )
         return 0;
@@ -109,8 +109,9 @@ int xstate_alloc_save_area(struct vcpu *
     if ( save_area =3D=3D NULL )
         return -ENOMEM;
=20
-    ((u32 *)save_area)[6] =3D 0x1f80;  /* MXCSR */
-    *(uint64_t *)(save_area + 512) =3D XSTATE_FP_SSE;  /* XSETBV */
+    save_area->fpu_sse.fcw =3D FCW_DEFAULT;
+    save_area->fpu_sse.mxcsr =3D MXCSR_DEFAULT;
+    save_area->xsave_hdr.xstate_bv =3D XSTATE_FP_SSE;
=20
     v->arch.xsave_area =3D save_area;
     v->arch.xcr0 =3D XSTATE_FP_SSE;
--- a/xen/include/asm-x86/xstate.h
+++ b/xen/include/asm-x86/xstate.h
@@ -11,6 +11,9 @@
 #include <xen/types.h>
 #include <xen/percpu.h>
=20
+#define FCW_DEFAULT               0x037f
+#define MXCSR_DEFAULT             0x1f80
+
 #define XSTATE_CPUID              0x0000000d
 #define XSTATE_FEATURE_XSAVEOPT   (1 << 0)    /* sub-leaf 1, eax[bit 0] =
*/
=20
@@ -46,7 +49,29 @@ extern u64 xfeature_mask;
 /* extended state save area */
 struct xsave_struct
 {
-    struct { char x[512]; } fpu_sse;         /* FPU/MMX, SSE */
+    union {                                  /* FPU/MMX, SSE */
+        char x[512];
+        struct {
+            uint16_t fcw;
+            uint16_t fsw;
+            uint8_t ftw;
+            uint8_t rsvd1;
+            uint16_t fop;
+            union {
+#ifdef __x86_64__
+                uint64_t addr;
+#endif
+                struct {
+                    uint32_t offs;
+                    uint16_t sel;
+                    uint16_t rsvd;
+                };
+            } fip, fdp;
+            uint32_t mxcsr;
+            uint32_t mxcsr_mask;
+            /* data registers follow here */
+        };
+    } fpu_sse;
=20
     struct {
         u64 xstate_bv;




--=__Part634CE59D.0__=
Content-Type: text/plain; name="x86-xstate-init.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-xstate-init.patch"

x86/xsave: provide guests with finit-like environment=0A=0AWithout the use =
of xsave, guests get their initial floating point=0Aenvironment set up =
with finit. At least NetWare actually depends on=0Athis (in particular on =
all exceptions being masked), so to be=0Aconsistent set the same environmen=
t also when using xsave. This is=0Aalso in line with all SSE exceptions =
getting masked initially.=0A=0ATo avoid further fragile casts in xstate_all=
oc_save_area() the patch=0Aalso changes xsave_struct's fpu_see member to =
have actually usable=0Afields.=0A=0AThe patch was tested in its technically=
 identical, but modified-file-=0Awise different 4.1.2 version.=0A=0ASigned-=
off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: Charles Arnold =
<carnold@suse.com>=0A=0A--- a/xen/arch/x86/i387.c=0A+++ b/xen/arch/x86/i387=
.c=0A@@ -17,7 +17,6 @@=0A #include <asm/xstate.h>=0A #include <asm/asm_defn=
s.h>=0A =0A-#define MXCSR_DEFAULT 0x1f80=0A static void fpu_init(void)=0A =
{=0A     unsigned long val;=0A--- a/xen/arch/x86/xstate.c=0A+++ b/xen/arch/=
x86/xstate.c=0A@@ -97,7 +97,7 @@ bool_t xsave_enabled(const struct vcpu =
*=0A =0A int xstate_alloc_save_area(struct vcpu *v)=0A {=0A-    void =
*save_area;=0A+    struct xsave_struct *save_area;=0A =0A     if ( =
!cpu_has_xsave || is_idle_vcpu(v) )=0A         return 0;=0A@@ -109,8 =
+109,9 @@ int xstate_alloc_save_area(struct vcpu *=0A     if ( save_area =
=3D=3D NULL )=0A         return -ENOMEM;=0A =0A-    ((u32 *)save_area)[6] =
=3D 0x1f80;  /* MXCSR */=0A-    *(uint64_t *)(save_area + 512) =3D =
XSTATE_FP_SSE;  /* XSETBV */=0A+    save_area->fpu_sse.fcw =3D FCW_DEFAULT;=
=0A+    save_area->fpu_sse.mxcsr =3D MXCSR_DEFAULT;=0A+    save_area->xsave=
_hdr.xstate_bv =3D XSTATE_FP_SSE;=0A =0A     v->arch.xsave_area =3D =
save_area;=0A     v->arch.xcr0 =3D XSTATE_FP_SSE;=0A--- a/xen/include/asm-x=
86/xstate.h=0A+++ b/xen/include/asm-x86/xstate.h=0A@@ -11,6 +11,9 @@=0A =
#include <xen/types.h>=0A #include <xen/percpu.h>=0A =0A+#define FCW_DEFAUL=
T               0x037f=0A+#define MXCSR_DEFAULT             0x1f80=0A+=0A =
#define XSTATE_CPUID              0x0000000d=0A #define XSTATE_FEATURE_XSAV=
EOPT   (1 << 0)    /* sub-leaf 1, eax[bit 0] */=0A =0A@@ -46,7 +49,29 @@ =
extern u64 xfeature_mask;=0A /* extended state save area */=0A struct =
xsave_struct=0A {=0A-    struct { char x[512]; } fpu_sse;         /* =
FPU/MMX, SSE */=0A+    union {                                  /* =
FPU/MMX, SSE */=0A+        char x[512];=0A+        struct {=0A+            =
uint16_t fcw;=0A+            uint16_t fsw;=0A+            uint8_t ftw;=0A+ =
           uint8_t rsvd1;=0A+            uint16_t fop;=0A+            =
union {=0A+#ifdef __x86_64__=0A+                uint64_t addr;=0A+#endif=0A=
+                struct {=0A+                    uint32_t offs;=0A+        =
            uint16_t sel;=0A+                    uint16_t rsvd;=0A+        =
        };=0A+            } fip, fdp;=0A+            uint32_t mxcsr;=0A+   =
         uint32_t mxcsr_mask;=0A+            /* data registers follow here =
*/=0A+        };=0A+    } fpu_sse;=0A =0A     struct {=0A         u64 =
xstate_bv;=0A
--=__Part634CE59D.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__Part634CE59D.0__=--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 14:45:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 14:45:59 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3Dz-00021M-1F
	for archives@lists.xen.org; Thu, 17 Nov 2011 14:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3De-0001gP-MZ; Thu, 17 Nov 2011 06:45:38 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3BZ-0000pL-KT
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 06:43:30 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321541005!1965673!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17686 invoked from network); 17 Nov 2011 14:43:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 14:43:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 17 Nov 2011 14:43:27 +0000
Message-Id: <4EC52B9D020000780006199E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 17 Nov 2011 14:43:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part634CE59D.0__="
Cc: Charles Arnold <CARNOLD@suse.com>, Bruce Rogers <BROGERS@suse.com>
Subject: [Xen-devel] [PATCH] x86/xsave: provide guests with finit-like
	environment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

Without the use of xsave, guests get their initial floating point
environment set up with finit. At least NetWare actually depends on
this (in particular on all exceptions being masked), so to be
consistent set the same environment also when using xsave. This is
also in line with all SSE exceptions getting masked initially.

To avoid further fragile casts in xstate_alloc_save_area() the patch
also changes xsave_struct's fpu_see member to have actually usable
fields.

The patch was tested in its technically identical, but modified-file-
wise different 4.1.2 version.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Charles Arnold <carnold@suse.com>

--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -17,7 +17,6 @@
 #include <asm/xstate.h>
 #include <asm/asm_defns.h>
=20
-#define MXCSR_DEFAULT 0x1f80
 static void fpu_init(void)
 {
     unsigned long val;
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -97,7 +97,7 @@ bool_t xsave_enabled(const struct vcpu *
=20
 int xstate_alloc_save_area(struct vcpu *v)
 {
-    void *save_area;
+    struct xsave_struct *save_area;
=20
     if ( !cpu_has_xsave || is_idle_vcpu(v) )
         return 0;
@@ -109,8 +109,9 @@ int xstate_alloc_save_area(struct vcpu *
     if ( save_area =3D=3D NULL )
         return -ENOMEM;
=20
-    ((u32 *)save_area)[6] =3D 0x1f80;  /* MXCSR */
-    *(uint64_t *)(save_area + 512) =3D XSTATE_FP_SSE;  /* XSETBV */
+    save_area->fpu_sse.fcw =3D FCW_DEFAULT;
+    save_area->fpu_sse.mxcsr =3D MXCSR_DEFAULT;
+    save_area->xsave_hdr.xstate_bv =3D XSTATE_FP_SSE;
=20
     v->arch.xsave_area =3D save_area;
     v->arch.xcr0 =3D XSTATE_FP_SSE;
--- a/xen/include/asm-x86/xstate.h
+++ b/xen/include/asm-x86/xstate.h
@@ -11,6 +11,9 @@
 #include <xen/types.h>
 #include <xen/percpu.h>
=20
+#define FCW_DEFAULT               0x037f
+#define MXCSR_DEFAULT             0x1f80
+
 #define XSTATE_CPUID              0x0000000d
 #define XSTATE_FEATURE_XSAVEOPT   (1 << 0)    /* sub-leaf 1, eax[bit 0] =
*/
=20
@@ -46,7 +49,29 @@ extern u64 xfeature_mask;
 /* extended state save area */
 struct xsave_struct
 {
-    struct { char x[512]; } fpu_sse;         /* FPU/MMX, SSE */
+    union {                                  /* FPU/MMX, SSE */
+        char x[512];
+        struct {
+            uint16_t fcw;
+            uint16_t fsw;
+            uint8_t ftw;
+            uint8_t rsvd1;
+            uint16_t fop;
+            union {
+#ifdef __x86_64__
+                uint64_t addr;
+#endif
+                struct {
+                    uint32_t offs;
+                    uint16_t sel;
+                    uint16_t rsvd;
+                };
+            } fip, fdp;
+            uint32_t mxcsr;
+            uint32_t mxcsr_mask;
+            /* data registers follow here */
+        };
+    } fpu_sse;
=20
     struct {
         u64 xstate_bv;




--=__Part634CE59D.0__=
Content-Type: text/plain; name="x86-xstate-init.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-xstate-init.patch"

x86/xsave: provide guests with finit-like environment=0A=0AWithout the use =
of xsave, guests get their initial floating point=0Aenvironment set up =
with finit. At least NetWare actually depends on=0Athis (in particular on =
all exceptions being masked), so to be=0Aconsistent set the same environmen=
t also when using xsave. This is=0Aalso in line with all SSE exceptions =
getting masked initially.=0A=0ATo avoid further fragile casts in xstate_all=
oc_save_area() the patch=0Aalso changes xsave_struct's fpu_see member to =
have actually usable=0Afields.=0A=0AThe patch was tested in its technically=
 identical, but modified-file-=0Awise different 4.1.2 version.=0A=0ASigned-=
off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: Charles Arnold =
<carnold@suse.com>=0A=0A--- a/xen/arch/x86/i387.c=0A+++ b/xen/arch/x86/i387=
.c=0A@@ -17,7 +17,6 @@=0A #include <asm/xstate.h>=0A #include <asm/asm_defn=
s.h>=0A =0A-#define MXCSR_DEFAULT 0x1f80=0A static void fpu_init(void)=0A =
{=0A     unsigned long val;=0A--- a/xen/arch/x86/xstate.c=0A+++ b/xen/arch/=
x86/xstate.c=0A@@ -97,7 +97,7 @@ bool_t xsave_enabled(const struct vcpu =
*=0A =0A int xstate_alloc_save_area(struct vcpu *v)=0A {=0A-    void =
*save_area;=0A+    struct xsave_struct *save_area;=0A =0A     if ( =
!cpu_has_xsave || is_idle_vcpu(v) )=0A         return 0;=0A@@ -109,8 =
+109,9 @@ int xstate_alloc_save_area(struct vcpu *=0A     if ( save_area =
=3D=3D NULL )=0A         return -ENOMEM;=0A =0A-    ((u32 *)save_area)[6] =
=3D 0x1f80;  /* MXCSR */=0A-    *(uint64_t *)(save_area + 512) =3D =
XSTATE_FP_SSE;  /* XSETBV */=0A+    save_area->fpu_sse.fcw =3D FCW_DEFAULT;=
=0A+    save_area->fpu_sse.mxcsr =3D MXCSR_DEFAULT;=0A+    save_area->xsave=
_hdr.xstate_bv =3D XSTATE_FP_SSE;=0A =0A     v->arch.xsave_area =3D =
save_area;=0A     v->arch.xcr0 =3D XSTATE_FP_SSE;=0A--- a/xen/include/asm-x=
86/xstate.h=0A+++ b/xen/include/asm-x86/xstate.h=0A@@ -11,6 +11,9 @@=0A =
#include <xen/types.h>=0A #include <xen/percpu.h>=0A =0A+#define FCW_DEFAUL=
T               0x037f=0A+#define MXCSR_DEFAULT             0x1f80=0A+=0A =
#define XSTATE_CPUID              0x0000000d=0A #define XSTATE_FEATURE_XSAV=
EOPT   (1 << 0)    /* sub-leaf 1, eax[bit 0] */=0A =0A@@ -46,7 +49,29 @@ =
extern u64 xfeature_mask;=0A /* extended state save area */=0A struct =
xsave_struct=0A {=0A-    struct { char x[512]; } fpu_sse;         /* =
FPU/MMX, SSE */=0A+    union {                                  /* =
FPU/MMX, SSE */=0A+        char x[512];=0A+        struct {=0A+            =
uint16_t fcw;=0A+            uint16_t fsw;=0A+            uint8_t ftw;=0A+ =
           uint8_t rsvd1;=0A+            uint16_t fop;=0A+            =
union {=0A+#ifdef __x86_64__=0A+                uint64_t addr;=0A+#endif=0A=
+                struct {=0A+                    uint32_t offs;=0A+        =
            uint16_t sel;=0A+                    uint16_t rsvd;=0A+        =
        };=0A+            } fip, fdp;=0A+            uint32_t mxcsr;=0A+   =
         uint32_t mxcsr_mask;=0A+            /* data registers follow here =
*/=0A+        };=0A+    } fpu_sse;=0A =0A     struct {=0A         u64 =
xstate_bv;=0A
--=__Part634CE59D.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__Part634CE59D.0__=--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:11:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:11:03 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3cF-000227-4R
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:11:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3bs-00041e-N3; Thu, 17 Nov 2011 07:10:40 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TU-0002Qe-Ai
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:26 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321542115!3938195!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14005 invoked from network); 17 Nov 2011 15:01:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990604"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:49 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lN9026208;	Thu, 17 Nov 2011 07:01:48 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 00 of 17] Documentation updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The following series flushes my documentation queue and replaces
previous postings of those patches.

The main difference is that the xl cfg file is now formatted using POD
instead of markdown and presented as a manpage.

I have setup a cron job to build docs/html and publish it at
http://xenbits.xen.org/docs/unstable/ (it's a bit bare right now).

The motivation for some of these patches e.g. creating an index was
more to support this use case although it is probably useful for
packaging /usr/share/doc/xen etc.

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:11:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:11:03 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3cF-000227-4R
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:11:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3bs-00041e-N3; Thu, 17 Nov 2011 07:10:40 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TU-0002Qe-Ai
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:26 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321542115!3938195!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14005 invoked from network); 17 Nov 2011 15:01:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990604"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:49 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lN9026208;	Thu, 17 Nov 2011 07:01:48 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 00 of 17] Documentation updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The following series flushes my documentation queue and replaces
previous postings of those patches.

The main difference is that the xl cfg file is now formatted using POD
instead of markdown and presented as a manpage.

I have setup a cron job to build docs/html and publish it at
http://xenbits.xen.org/docs/unstable/ (it's a bit bare right now).

The motivation for some of these patches e.g. creating an index was
more to support this use case although it is probably useful for
packaging /usr/share/doc/xen etc.

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:12:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:12:57 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3e5-00022K-G7
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3dn-0004SA-Ey; Thu, 17 Nov 2011 07:12:39 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TW-0002Qq-It
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:25 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321542117!1909981!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11561 invoked from network); 17 Nov 2011 15:01:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990628"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:58 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNJ026208;	Thu, 17 Nov 2011 07:01:56 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Mercurial-Node: 617f5d6e9e69b4f6362df91f078b7dc2abdbd80a
Message-ID: <617f5d6e9e69b4f6362d.1321542116@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:56 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 10 of 17] docs: remove non-breaking spaces from
 sedf_scheduler_mini-HOWTO.txt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321541652 0
# Node ID 617f5d6e9e69b4f6362df91f078b7dc2abdbd80a
# Parent  c4571d33f5829bac2e1da169f9d1398810c0b7d2
docs: remove non-breaking spaces from sedf_scheduler_mini-HOWTO.txt

This document contains several 0xa0 characters (non-breaking spaces). These do
not display correctly in (some) terminals or when the document is rendered by (some)
browsers. Re-encode them as spaces.

I'm not confident that this change will make it through being encoded as a patch
and sent through email. Its effect can be replicated with:

	perl -i -p -e 's/\xa0/ /g' docs/misc/sedf_scheduler_mini-HOWTO.txt

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

diff -r c4571d33f582 -r 617f5d6e9e69 docs/misc/sedf_scheduler_mini-HOWTO.txt
--- a/docs/misc/sedf_scheduler_mini-HOWTO.txt	Thu Nov 17 14:35:37 2011 +0000
+++ b/docs/misc/sedf_scheduler_mini-HOWTO.txt	Thu Nov 17 14:54:12 2011 +0000
@@ -8,37 +8,37 @@ Overview:
   uses realtime-algorithms to ensure time guarantees.
 
 Usage:
-   -add "sched=sedf" on Xen's boot command-line
-   -create domains as usual
-   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
-    Where:
-      -period/slice are the normal EDF scheduling parameters in nanosecs
-      -latency-hint is the scaled period in case the domain is doing heavy I/O
+   -add "sched=sedf" on Xen's boot command-line
+   -create domains as usual
+   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
+    Where:
+      -period/slice are the normal EDF scheduling parameters in nanosecs
+      -latency-hint is the scaled period in case the domain is doing heavy I/O
          (unused by the currently compiled version)
-      -extra is a flag (0/1), which controls whether the domain can run in
+      -extra is a flag (0/1), which controls whether the domain can run in
        extra-time
-      -weight is mutually exclusive with period/slice and specifies another
+      -weight is mutually exclusive with period/slice and specifies another
        way of setting a domains cpu slice
 
 Examples:
- normal EDF (20ms/5ms):
-  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
+ normal EDF (20ms/5ms):
+  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
   
- best-effort domains (i.e. non-realtime):
-  xm sched-sedf <dom-id> 20000000 0 0 1 0
- 
+ best-effort domains (i.e. non-realtime):
+  xm sched-sedf <dom-id> 20000000 0 0 1 0
+ 
  normal EDF (20ms/5ms) + share of extra-time:
-  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
+  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
   
- 4 domains with weights 2:3:4:2
-  xm sched-sedf <d1> 0 0 0 0 2
-  xm sched-sedf <d2> 0 0 0 0 3
-  xm sched-sedf <d3> 0 0 0 0 4
-  xm sched-sedf <d4> 0 0 0 0 2
+ 4 domains with weights 2:3:4:2
+  xm sched-sedf <d1> 0 0 0 0 2
+  xm sched-sedf <d2> 0 0 0 0 3
+  xm sched-sedf <d3> 0 0 0 0 4
+  xm sched-sedf <d4> 0 0 0 0 2
   
- 1 fully-specified (10ms/3ms) domain, 3 other domains share
- available rest in 2:7:3 ratio:
-  xm sched-sedf <d1> 10000000 3000000 0 0 0
-  xm sched-sedf <d2> 0 0 0 0 2
-  xm sched-sedf <d3> 0 0 0 0 7
-  xm sched-sedf <d4> 0 0 0 0 3
+ 1 fully-specified (10ms/3ms) domain, 3 other domains share
+ available rest in 2:7:3 ratio:
+  xm sched-sedf <d1> 10000000 3000000 0 0 0
+  xm sched-sedf <d2> 0 0 0 0 2
+  xm sched-sedf <d3> 0 0 0 0 7
+  xm sched-sedf <d4> 0 0 0 0 3

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:12:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:12:57 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3e5-00022K-G7
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3dn-0004SA-Ey; Thu, 17 Nov 2011 07:12:39 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TW-0002Qq-It
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:25 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321542117!1909981!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11561 invoked from network); 17 Nov 2011 15:01:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990628"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:58 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNJ026208;	Thu, 17 Nov 2011 07:01:56 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Mercurial-Node: 617f5d6e9e69b4f6362df91f078b7dc2abdbd80a
Message-ID: <617f5d6e9e69b4f6362d.1321542116@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:56 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 10 of 17] docs: remove non-breaking spaces from
 sedf_scheduler_mini-HOWTO.txt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321541652 0
# Node ID 617f5d6e9e69b4f6362df91f078b7dc2abdbd80a
# Parent  c4571d33f5829bac2e1da169f9d1398810c0b7d2
docs: remove non-breaking spaces from sedf_scheduler_mini-HOWTO.txt

This document contains several 0xa0 characters (non-breaking spaces). These do
not display correctly in (some) terminals or when the document is rendered by (some)
browsers. Re-encode them as spaces.

I'm not confident that this change will make it through being encoded as a patch
and sent through email. Its effect can be replicated with:

	perl -i -p -e 's/\xa0/ /g' docs/misc/sedf_scheduler_mini-HOWTO.txt

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

diff -r c4571d33f582 -r 617f5d6e9e69 docs/misc/sedf_scheduler_mini-HOWTO.txt
--- a/docs/misc/sedf_scheduler_mini-HOWTO.txt	Thu Nov 17 14:35:37 2011 +0000
+++ b/docs/misc/sedf_scheduler_mini-HOWTO.txt	Thu Nov 17 14:54:12 2011 +0000
@@ -8,37 +8,37 @@ Overview:
   uses realtime-algorithms to ensure time guarantees.
 
 Usage:
-   -add "sched=sedf" on Xen's boot command-line
-   -create domains as usual
-   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
-    Where:
-      -period/slice are the normal EDF scheduling parameters in nanosecs
-      -latency-hint is the scaled period in case the domain is doing heavy I/O
+   -add "sched=sedf" on Xen's boot command-line
+   -create domains as usual
+   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
+    Where:
+      -period/slice are the normal EDF scheduling parameters in nanosecs
+      -latency-hint is the scaled period in case the domain is doing heavy I/O
          (unused by the currently compiled version)
-      -extra is a flag (0/1), which controls whether the domain can run in
+      -extra is a flag (0/1), which controls whether the domain can run in
        extra-time
-      -weight is mutually exclusive with period/slice and specifies another
+      -weight is mutually exclusive with period/slice and specifies another
        way of setting a domains cpu slice
 
 Examples:
- normal EDF (20ms/5ms):
-  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
+ normal EDF (20ms/5ms):
+  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
   
- best-effort domains (i.e. non-realtime):
-  xm sched-sedf <dom-id> 20000000 0 0 1 0
- 
+ best-effort domains (i.e. non-realtime):
+  xm sched-sedf <dom-id> 20000000 0 0 1 0
+ 
  normal EDF (20ms/5ms) + share of extra-time:
-  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
+  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
   
- 4 domains with weights 2:3:4:2
-  xm sched-sedf <d1> 0 0 0 0 2
-  xm sched-sedf <d2> 0 0 0 0 3
-  xm sched-sedf <d3> 0 0 0 0 4
-  xm sched-sedf <d4> 0 0 0 0 2
+ 4 domains with weights 2:3:4:2
+  xm sched-sedf <d1> 0 0 0 0 2
+  xm sched-sedf <d2> 0 0 0 0 3
+  xm sched-sedf <d3> 0 0 0 0 4
+  xm sched-sedf <d4> 0 0 0 0 2
   
- 1 fully-specified (10ms/3ms) domain, 3 other domains share
- available rest in 2:7:3 ratio:
-  xm sched-sedf <d1> 10000000 3000000 0 0 0
-  xm sched-sedf <d2> 0 0 0 0 2
-  xm sched-sedf <d3> 0 0 0 0 7
-  xm sched-sedf <d4> 0 0 0 0 3
+ 1 fully-specified (10ms/3ms) domain, 3 other domains share
+ available rest in 2:7:3 ratio:
+  xm sched-sedf <d1> 10000000 3000000 0 0 0
+  xm sched-sedf <d2> 0 0 0 0 2
+  xm sched-sedf <d3> 0 0 0 0 7
+  xm sched-sedf <d4> 0 0 0 0 3

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:14:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:14:39 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3fj-00022X-IY
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:14:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3fQ-0004qd-GW; Thu, 17 Nov 2011 07:14:20 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TX-0002Qs-Ip
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:30 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321542117!1909981!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11597 invoked from network); 17 Nov 2011 15:02:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990637"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:00 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNL026208;	Thu, 17 Nov 2011 07:01:58 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: c1f8406da50743cd0597b93c4b5b8b6ff03ede42
Message-ID: <c1f8406da50743cd0597.1321542118@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 12 of 17] docs: tweak markup and wording of qemu
 upstream doc slightly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321541678 0
# Node ID c1f8406da50743cd0597b93c4b5b8b6ff03ede42
# Parent  55ce23cb7b2af3c497b3a10658e09d5fc11eb45f
docs: tweak markup and wording of qemu upstream doc slightly

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

diff -r 55ce23cb7b2a -r c1f8406da507 docs/misc/qemu-upstream_howto_use_it.markdown
--- a/docs/misc/qemu-upstream_howto_use_it.markdown	Thu Nov 17 14:54:38 2011 +0000
+++ b/docs/misc/qemu-upstream_howto_use_it.markdown	Thu Nov 17 14:54:38 2011 +0000
@@ -1,11 +1,11 @@
-Help to use QEMU (upstream version) with Xen
-============================================
+Using Upstream QEMU with Xen
+============================
 
 Note
 ----
 
 All these steps will become unnecessary after the patches to integrate
-SeaBIOS/QEMU build will be applied.
+SeaBIOS/QEMU into the Xen build system have been applied.
 
 
 How to build it
@@ -15,14 +15,15 @@ How to build it
 
 The new device-model needs a different BIOS, SeaBIOS. Clone the repository from:
 
-  - git://git.qemu.org/seabios.git
-  - http://git.qemu.org/git/seabios.git
+  - [git://git.qemu.org/seabios.git]()
+  - [http://git.qemu.org/git/seabios.git]()
 
-Put the `.config` file in the appendix at the root of seabios.git and build SeaBIOS.
+Put the `.config` file in the appendix at the root of `seabios.git`
+and build SeaBIOS by typing `make`.
 
-In xen-unstable source tree, add the file `.config` with
+In the xen-unstable source tree, add the file `.config` with
 `SEABIOS_DIR = /path/to/seabios.git`.
-To build hvmloader with SeaBIOS, you propably need to `make -C tools/firmware
+To build hvmloader with SeaBIOS, you probably need to `make -C tools/firmware
 clean` first and then `make tools`, to use the new SEABIOS_DIR parameter.
 
 
@@ -30,10 +31,10 @@ clean` first and then `make tools`, to u
 
 Get QEMU upstream source from:
 
-  - git://xenbits.xensource.com/qemu-upstream-unstable.git
-  - http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
+  - [git://xenbits.xensource.com/qemu-upstream-unstable.git]()
+  - [http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git]()
 
-To configure build QEMU upstream with Xen
+To configure QEMU upstream with support for Xen:
 
     ./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I$path_to_xen_source/tools/include -I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore" --extra-ldflags="-L$path_to_xen_source/tools/libxc -L$path_to_xen_source/tools/xenstore"
 
@@ -43,15 +44,15 @@ You can also use other several options s
 How to use QEMU upstream
 ------------------------
 
-Only xl support QEMU upstream.
+Only `xl` supports QEMU upstream.
 
 To actually use it, add or change this in your VM configuration file:
 
     device_model_version = 'qemu-xen'
     device_model_override = '/path/to/qemu/i386-softmmu/qemu'
 
-NB: On qemu-upstream repository, the default binary name has been renamed to
-`qemu-system-i386`.
+NB: In the `qemu-upstream` repository, the default binary name has been
+renamed to `qemu-system-i386`.
 
 
 Appendix

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:14:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:14:39 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3fj-00022X-IY
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:14:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3fQ-0004qd-GW; Thu, 17 Nov 2011 07:14:20 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TX-0002Qs-Ip
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:30 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321542117!1909981!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11597 invoked from network); 17 Nov 2011 15:02:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990637"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:00 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNL026208;	Thu, 17 Nov 2011 07:01:58 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: c1f8406da50743cd0597b93c4b5b8b6ff03ede42
Message-ID: <c1f8406da50743cd0597.1321542118@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 12 of 17] docs: tweak markup and wording of qemu
 upstream doc slightly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321541678 0
# Node ID c1f8406da50743cd0597b93c4b5b8b6ff03ede42
# Parent  55ce23cb7b2af3c497b3a10658e09d5fc11eb45f
docs: tweak markup and wording of qemu upstream doc slightly

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

diff -r 55ce23cb7b2a -r c1f8406da507 docs/misc/qemu-upstream_howto_use_it.markdown
--- a/docs/misc/qemu-upstream_howto_use_it.markdown	Thu Nov 17 14:54:38 2011 +0000
+++ b/docs/misc/qemu-upstream_howto_use_it.markdown	Thu Nov 17 14:54:38 2011 +0000
@@ -1,11 +1,11 @@
-Help to use QEMU (upstream version) with Xen
-============================================
+Using Upstream QEMU with Xen
+============================
 
 Note
 ----
 
 All these steps will become unnecessary after the patches to integrate
-SeaBIOS/QEMU build will be applied.
+SeaBIOS/QEMU into the Xen build system have been applied.
 
 
 How to build it
@@ -15,14 +15,15 @@ How to build it
 
 The new device-model needs a different BIOS, SeaBIOS. Clone the repository from:
 
-  - git://git.qemu.org/seabios.git
-  - http://git.qemu.org/git/seabios.git
+  - [git://git.qemu.org/seabios.git]()
+  - [http://git.qemu.org/git/seabios.git]()
 
-Put the `.config` file in the appendix at the root of seabios.git and build SeaBIOS.
+Put the `.config` file in the appendix at the root of `seabios.git`
+and build SeaBIOS by typing `make`.
 
-In xen-unstable source tree, add the file `.config` with
+In the xen-unstable source tree, add the file `.config` with
 `SEABIOS_DIR = /path/to/seabios.git`.
-To build hvmloader with SeaBIOS, you propably need to `make -C tools/firmware
+To build hvmloader with SeaBIOS, you probably need to `make -C tools/firmware
 clean` first and then `make tools`, to use the new SEABIOS_DIR parameter.
 
 
@@ -30,10 +31,10 @@ clean` first and then `make tools`, to u
 
 Get QEMU upstream source from:
 
-  - git://xenbits.xensource.com/qemu-upstream-unstable.git
-  - http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
+  - [git://xenbits.xensource.com/qemu-upstream-unstable.git]()
+  - [http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git]()
 
-To configure build QEMU upstream with Xen
+To configure QEMU upstream with support for Xen:
 
     ./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I$path_to_xen_source/tools/include -I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore" --extra-ldflags="-L$path_to_xen_source/tools/libxc -L$path_to_xen_source/tools/xenstore"
 
@@ -43,15 +44,15 @@ You can also use other several options s
 How to use QEMU upstream
 ------------------------
 
-Only xl support QEMU upstream.
+Only `xl` supports QEMU upstream.
 
 To actually use it, add or change this in your VM configuration file:
 
     device_model_version = 'qemu-xen'
     device_model_override = '/path/to/qemu/i386-softmmu/qemu'
 
-NB: On qemu-upstream repository, the default binary name has been renamed to
-`qemu-system-i386`.
+NB: In the `qemu-upstream` repository, the default binary name has been
+renamed to `qemu-system-i386`.
 
 
 Appendix

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:16:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:16:38 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3he-00022k-2z
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3hL-0005Ez-8W; Thu, 17 Nov 2011 07:16:19 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TS-0002Qb-84
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:28 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16691 invoked from network); 17 Nov 2011 15:01:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189107"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:54 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNF026208;	Thu, 17 Nov 2011 07:01:53 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 22264859117b883d37b563ddad14515d80568a4e
Message-ID: <22264859117b883d37b5.1321542112@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 06 of 17] xl: the name field in a guest config
 file is mandatory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540536 0
# Node ID 22264859117b883d37b563ddad14515d80568a4e
# Parent  c88ff1ac24170a7d2a3c8824735ef9311eb95fe0
xl: the name field in a guest config file is mandatory

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

diff -r c88ff1ac2417 -r 22264859117b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:24 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:36 2011 +0000
@@ -575,8 +575,10 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "hap", &l))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name))
-        c_info->name = strdup("test");
+    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+        fprintf(stderr, "Domain name must be specified.");
+        exit(1);
+    }
 
     if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:16:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:16:38 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3he-00022k-2z
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:16:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3hL-0005Ez-8W; Thu, 17 Nov 2011 07:16:19 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TS-0002Qb-84
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:28 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16691 invoked from network); 17 Nov 2011 15:01:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189107"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:54 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNF026208;	Thu, 17 Nov 2011 07:01:53 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 22264859117b883d37b563ddad14515d80568a4e
Message-ID: <22264859117b883d37b5.1321542112@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 06 of 17] xl: the name field in a guest config
 file is mandatory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540536 0
# Node ID 22264859117b883d37b563ddad14515d80568a4e
# Parent  c88ff1ac24170a7d2a3c8824735ef9311eb95fe0
xl: the name field in a guest config file is mandatory

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

diff -r c88ff1ac2417 -r 22264859117b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:24 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:36 2011 +0000
@@ -575,8 +575,10 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "hap", &l))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name))
-        c_info->name = strdup("test");
+    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+        fprintf(stderr, "Domain name must be specified.");
+        exit(1);
+    }
 
     if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:18:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:18:28 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3jQ-00022x-LE
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:18:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3j7-0005cr-Uu; Thu, 17 Nov 2011 07:18:10 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3Td-0002RL-57
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:32 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321542117!1909981!4
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11933 invoked from network); 17 Nov 2011 15:02:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990659"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:02:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:03 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNO026208;	Thu, 17 Nov 2011 07:02:01 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 29d91e4d1f4f8d9233014b616547a9aed53b1515
Message-ID: <29d91e4d1f4f8d923301.1321542121@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:02:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 15 of 17] libxlu: add
	xlu_cfg_get_list_as_string_list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542095 0
# Node ID 29d91e4d1f4f8d9233014b616547a9aed53b1515
# Parent  7d77e0269af797cb8ab8e7d536412a222e7da3ef
libxlu: add xlu_cfg_get_list_as_string_list

Returns a cfg list as a libxl_string_list.

Use this to simplify the parsing of device model extra args.

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

diff -r 7d77e0269af7 -r 29d91e4d1f4f tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Thu Nov 17 15:01:28 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Thu Nov 17 15:01:35 2011 +0000
@@ -254,6 +254,29 @@ int xlu_cfg_get_list(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                     libxl_string_list *psl, int dont_warn) {
+    int i, rc, nr;
+    XLU_ConfigList *list;
+    libxl_string_list sl;
+
+    rc = xlu_cfg_get_list(cfg, n, &list, &nr, dont_warn);
+    if (rc)  return rc;
+
+    sl = malloc(sizeof(char*)*(nr + 1));
+    if (sl == NULL) return ENOMEM;
+
+    for (i=0; i<nr; i++) {
+        const char *a = xlu_cfg_get_listitem(list, i);
+        sl[i] = a ? strdup(a) : NULL;
+    }
+
+    sl[nr] = NULL;
+
+    *psl = sl;
+    return 0;
+}
+
 const char *xlu_cfg_get_listitem(const XLU_ConfigList *set, int entry) {
     if (entry < 0 || entry >= set->nvalues) return 0;
     return set->values[entry];
diff -r 7d77e0269af7 -r 29d91e4d1f4f tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Thu Nov 17 15:01:28 2011 +0000
+++ b/tools/libxl/libxlutil.h	Thu Nov 17 15:01:35 2011 +0000
@@ -58,6 +58,8 @@ int xlu_cfg_get_list(const XLU_Config*, 
                      int *entries_r /* may be 0 */,
                      int dont_warn);
   /* there is no need to free *list_r; lifetime is that of the XLU_Config */
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                                    libxl_string_list *sl, int dont_warn);
 const char *xlu_cfg_get_listitem(const XLU_ConfigList*, int entry);
   /* xlu_cfg_get_listitem cannot fail, except that if entry is
    * out of range it returns 0 (not setting errno) */
diff -r 7d77e0269af7 -r 29d91e4d1f4f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 15:01:28 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 15:01:35 2011 +0000
@@ -529,13 +529,6 @@ static void parse_config_data(const char
     int pci_msitranslate = 1;
     int e;
 
-    XLU_ConfigList *dmargs;
-    int nr_dmargs = 0;
-    XLU_ConfigList *dmargs_hvm;
-    int nr_dmargs_hvm = 0;
-    XLU_ConfigList *dmargs_pv;
-    int nr_dmargs_pv = 0;
-
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
 
@@ -1089,19 +1082,14 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
-#define parse_extra_args(type)                                          \
-    if (!xlu_cfg_get_list(config, "device_model_args"#type,             \
-                          &dmargs##type, &nr_dmargs##type, 0))          \
-    {                                                                   \
-        int i;                                                          \
-        dm_info->extra##type =                                          \
-            xmalloc(sizeof(char*)*(nr_dmargs##type + 1));               \
-        dm_info->extra##type[nr_dmargs##type] = NULL;                   \
-        for (i=0; i<nr_dmargs##type; i++) {                             \
-            const char *a = xlu_cfg_get_listitem(dmargs##type, i);      \
-            dm_info->extra##type[i] = a ? strdup(a) : NULL;             \
-        }                                                               \
-    }                                                                   \
+#define parse_extra_args(type)                                            \
+    e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
+                                    &dm_info->extra##type, 0);            \
+    if (e && e != ESRCH) {                                                \
+        fprintf(stderr,"xl: Unable to parse device_model_args"#type".\n");\
+        exit(-ERROR_FAIL);                                                \
+    }
+
     /* parse extra args for qemu, common to both pv, hvm */
     parse_extra_args();
 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:18:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:18:28 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3jQ-00022x-LE
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:18:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3j7-0005cr-Uu; Thu, 17 Nov 2011 07:18:10 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3Td-0002RL-57
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:32 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321542117!1909981!4
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11933 invoked from network); 17 Nov 2011 15:02:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990659"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:02:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:03 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNO026208;	Thu, 17 Nov 2011 07:02:01 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 29d91e4d1f4f8d9233014b616547a9aed53b1515
Message-ID: <29d91e4d1f4f8d923301.1321542121@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:02:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 15 of 17] libxlu: add
	xlu_cfg_get_list_as_string_list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542095 0
# Node ID 29d91e4d1f4f8d9233014b616547a9aed53b1515
# Parent  7d77e0269af797cb8ab8e7d536412a222e7da3ef
libxlu: add xlu_cfg_get_list_as_string_list

Returns a cfg list as a libxl_string_list.

Use this to simplify the parsing of device model extra args.

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

diff -r 7d77e0269af7 -r 29d91e4d1f4f tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Thu Nov 17 15:01:28 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Thu Nov 17 15:01:35 2011 +0000
@@ -254,6 +254,29 @@ int xlu_cfg_get_list(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                     libxl_string_list *psl, int dont_warn) {
+    int i, rc, nr;
+    XLU_ConfigList *list;
+    libxl_string_list sl;
+
+    rc = xlu_cfg_get_list(cfg, n, &list, &nr, dont_warn);
+    if (rc)  return rc;
+
+    sl = malloc(sizeof(char*)*(nr + 1));
+    if (sl == NULL) return ENOMEM;
+
+    for (i=0; i<nr; i++) {
+        const char *a = xlu_cfg_get_listitem(list, i);
+        sl[i] = a ? strdup(a) : NULL;
+    }
+
+    sl[nr] = NULL;
+
+    *psl = sl;
+    return 0;
+}
+
 const char *xlu_cfg_get_listitem(const XLU_ConfigList *set, int entry) {
     if (entry < 0 || entry >= set->nvalues) return 0;
     return set->values[entry];
diff -r 7d77e0269af7 -r 29d91e4d1f4f tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Thu Nov 17 15:01:28 2011 +0000
+++ b/tools/libxl/libxlutil.h	Thu Nov 17 15:01:35 2011 +0000
@@ -58,6 +58,8 @@ int xlu_cfg_get_list(const XLU_Config*, 
                      int *entries_r /* may be 0 */,
                      int dont_warn);
   /* there is no need to free *list_r; lifetime is that of the XLU_Config */
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                                    libxl_string_list *sl, int dont_warn);
 const char *xlu_cfg_get_listitem(const XLU_ConfigList*, int entry);
   /* xlu_cfg_get_listitem cannot fail, except that if entry is
    * out of range it returns 0 (not setting errno) */
diff -r 7d77e0269af7 -r 29d91e4d1f4f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 15:01:28 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 15:01:35 2011 +0000
@@ -529,13 +529,6 @@ static void parse_config_data(const char
     int pci_msitranslate = 1;
     int e;
 
-    XLU_ConfigList *dmargs;
-    int nr_dmargs = 0;
-    XLU_ConfigList *dmargs_hvm;
-    int nr_dmargs_hvm = 0;
-    XLU_ConfigList *dmargs_pv;
-    int nr_dmargs_pv = 0;
-
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
 
@@ -1089,19 +1082,14 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
-#define parse_extra_args(type)                                          \
-    if (!xlu_cfg_get_list(config, "device_model_args"#type,             \
-                          &dmargs##type, &nr_dmargs##type, 0))          \
-    {                                                                   \
-        int i;                                                          \
-        dm_info->extra##type =                                          \
-            xmalloc(sizeof(char*)*(nr_dmargs##type + 1));               \
-        dm_info->extra##type[nr_dmargs##type] = NULL;                   \
-        for (i=0; i<nr_dmargs##type; i++) {                             \
-            const char *a = xlu_cfg_get_listitem(dmargs##type, i);      \
-            dm_info->extra##type[i] = a ? strdup(a) : NULL;             \
-        }                                                               \
-    }                                                                   \
+#define parse_extra_args(type)                                            \
+    e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
+                                    &dm_info->extra##type, 0);            \
+    if (e && e != ESRCH) {                                                \
+        fprintf(stderr,"xl: Unable to parse device_model_args"#type".\n");\
+        exit(-ERROR_FAIL);                                                \
+    }
+
     /* parse extra args for qemu, common to both pv, hvm */
     parse_extra_args();
 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:21:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:21:01 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3lt-00023A-5j
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:21:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3la-00062P-NF; Thu, 17 Nov 2011 07:20:42 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TW-0002Qn-5A
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:26 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321542116!3546609!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5065 invoked from network); 17 Nov 2011 15:01:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990611"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:52 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNC026208;	Thu, 17 Nov 2011 07:01:50 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: e8f0094323d0edcf8e35573f37b74beab5694bd3
Message-ID: <e8f0094323d0edcf8e35.1321542109@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 03 of 17] README: add markdown to dependency list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540451 0
# Node ID e8f0094323d0edcf8e35573f37b74beab5694bd3
# Parent  5e3e5757de0fcd0b826d0ca8330db7fa1cfccba4
README: add markdown to dependency list

although this tool is strictly speaking optional we are providing various user
docs in this format so increase the changes that they will install it.

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

diff -r 5e3e5757de0f -r e8f0094323d0 README
--- a/README	Thu Nov 17 14:34:11 2011 +0000
+++ b/README	Thu Nov 17 14:34:11 2011 +0000
@@ -55,6 +55,7 @@ provided by your OS distributor:
     * GNU gettext
     * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
     * ACPI ASL compiler (iasl)
+    * markdown
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:21:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:21:01 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3lt-00023A-5j
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:21:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3la-00062P-NF; Thu, 17 Nov 2011 07:20:42 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TW-0002Qn-5A
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:26 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321542116!3546609!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5065 invoked from network); 17 Nov 2011 15:01:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990611"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:52 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNC026208;	Thu, 17 Nov 2011 07:01:50 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: e8f0094323d0edcf8e35573f37b74beab5694bd3
Message-ID: <e8f0094323d0edcf8e35.1321542109@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 03 of 17] README: add markdown to dependency list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540451 0
# Node ID e8f0094323d0edcf8e35573f37b74beab5694bd3
# Parent  5e3e5757de0fcd0b826d0ca8330db7fa1cfccba4
README: add markdown to dependency list

although this tool is strictly speaking optional we are providing various user
docs in this format so increase the changes that they will install it.

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

diff -r 5e3e5757de0f -r e8f0094323d0 README
--- a/README	Thu Nov 17 14:34:11 2011 +0000
+++ b/README	Thu Nov 17 14:34:11 2011 +0000
@@ -55,6 +55,7 @@ provided by your OS distributor:
     * GNU gettext
     * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
     * ACPI ASL compiler (iasl)
+    * markdown
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:23:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:23:50 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3oc-00023N-Ca
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:23:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3oJ-0006RL-MH; Thu, 17 Nov 2011 07:23:32 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TQ-0002QW-OL
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:27 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16553 invoked from network); 17 Nov 2011 15:01:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189106"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lND026208;	Thu, 17 Nov 2011 07:01:51 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: f3fc909a083ddcea05cd0c9ab51a7241e573f6a6
Message-ID: <f3fc909a083ddcea05cd.1321542110@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 04 of 17] docs: install html and txt versions of
	manpages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540451 0
# Node ID f3fc909a083ddcea05cd0c9ab51a7241e573f6a6
# Parent  e8f0094323d0edcf8e35573f37b74beab5694bd3
docs: install html and txt versions of manpages

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

diff -r e8f0094323d0 -r f3fc909a083d docs/Docs.mk
--- a/docs/Docs.mk	Thu Nov 17 14:34:11 2011 +0000
+++ b/docs/Docs.mk	Thu Nov 17 14:34:11 2011 +0000
@@ -5,6 +5,8 @@ FIG2DEV		:= fig2dev
 LATEX2HTML	:= latex2html
 DOXYGEN		:= doxygen
 POD2MAN		:= pod2man
+POD2HTML	:= pod2html
+POD2TEXT	:= pod2text
 DOT		:= dot
 NEATO		:= neato
 MARKDOWN	:= markdown
diff -r e8f0094323d0 -r f3fc909a083d docs/Makefile
--- a/docs/Makefile	Thu Nov 17 14:34:11 2011 +0000
+++ b/docs/Makefile	Thu Nov 17 14:34:11 2011 +0000
@@ -15,9 +15,13 @@ DOC_MARKDOWN	:= $(wildcard misc/*.markdo
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
 DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
-		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
-		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,txt/man/%.5.txt,$(DOC_MAN5SRC))
 
 GFX = $(patsubst %.fig, %.eps, $(wildcard figs/*.fig))
 
@@ -76,7 +80,7 @@ clean:
 	$(MAKE) -C xen-api clean
 	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
 	rm -rf *.ilg *.log *.ind *.toc *.bak core
-	rm -rf $(GFX) ps pdf html
+	rm -rf $(GFX) ps pdf html txt
 	rm -rf api
 	rm -rf man5
 	rm -rf man1
@@ -132,6 +136,16 @@ html/%.html: %.markdown
 	$(call move-if-changed,$@.tmp,$@) ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/man/%.1.html: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+html/man/%.5.html: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
@@ -141,3 +155,14 @@ txt/%.txt: %.markdown
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.1.txt: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.5.txt: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:23:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:23:50 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3oc-00023N-Ca
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:23:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3oJ-0006RL-MH; Thu, 17 Nov 2011 07:23:32 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TQ-0002QW-OL
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:27 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16553 invoked from network); 17 Nov 2011 15:01:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189106"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lND026208;	Thu, 17 Nov 2011 07:01:51 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: f3fc909a083ddcea05cd0c9ab51a7241e573f6a6
Message-ID: <f3fc909a083ddcea05cd.1321542110@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 04 of 17] docs: install html and txt versions of
	manpages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540451 0
# Node ID f3fc909a083ddcea05cd0c9ab51a7241e573f6a6
# Parent  e8f0094323d0edcf8e35573f37b74beab5694bd3
docs: install html and txt versions of manpages

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

diff -r e8f0094323d0 -r f3fc909a083d docs/Docs.mk
--- a/docs/Docs.mk	Thu Nov 17 14:34:11 2011 +0000
+++ b/docs/Docs.mk	Thu Nov 17 14:34:11 2011 +0000
@@ -5,6 +5,8 @@ FIG2DEV		:= fig2dev
 LATEX2HTML	:= latex2html
 DOXYGEN		:= doxygen
 POD2MAN		:= pod2man
+POD2HTML	:= pod2html
+POD2TEXT	:= pod2text
 DOT		:= dot
 NEATO		:= neato
 MARKDOWN	:= markdown
diff -r e8f0094323d0 -r f3fc909a083d docs/Makefile
--- a/docs/Makefile	Thu Nov 17 14:34:11 2011 +0000
+++ b/docs/Makefile	Thu Nov 17 14:34:11 2011 +0000
@@ -15,9 +15,13 @@ DOC_MARKDOWN	:= $(wildcard misc/*.markdo
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
 DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
-		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
-		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,txt/man/%.5.txt,$(DOC_MAN5SRC))
 
 GFX = $(patsubst %.fig, %.eps, $(wildcard figs/*.fig))
 
@@ -76,7 +80,7 @@ clean:
 	$(MAKE) -C xen-api clean
 	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
 	rm -rf *.ilg *.log *.ind *.toc *.bak core
-	rm -rf $(GFX) ps pdf html
+	rm -rf $(GFX) ps pdf html txt
 	rm -rf api
 	rm -rf man5
 	rm -rf man1
@@ -132,6 +136,16 @@ html/%.html: %.markdown
 	$(call move-if-changed,$@.tmp,$@) ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/man/%.1.html: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+html/man/%.5.html: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
@@ -141,3 +155,14 @@ txt/%.txt: %.markdown
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.1.txt: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.5.txt: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:25:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:25:49 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3qW-00023a-Sn
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:25:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3qE-0006po-Ru; Thu, 17 Nov 2011 07:25:31 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TV-0002Qh-5j
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:28 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321542115!3938195!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14025 invoked from network); 17 Nov 2011 15:01:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990605"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:50 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNA026208;	Thu, 17 Nov 2011 07:01:49 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 14a8af47bf11e9e4be35a0000336b49da95d9860
Message-ID: <14a8af47bf11e9e4be35.1321542107@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 01 of 17] Replace references to old wiki with
	ones to new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540451 0
# Node ID 14a8af47bf11e9e4be35a0000336b49da95d9860
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Replace references to old wiki with ones to new.

I have confirmed that the relevant pages have been transitioned.

What remains is pages which have not yet been moved over:

$ rgrep xenwiki *
docs/misc/xenstore.txt:	See http://wiki.xensource.com/xenwiki/XenBus section
tools/libxen/README:http://wiki.xensource.com/xenwiki/XenApi
tools/xenballoon/xenballoond.README:http://wiki.xensource.com/xenwiki/Open_Topics_For_Discussion?action=AttachFile&do=get&target=Memory+Overcommit.pdf

Note that "PythonInXlConfig" never existed in the old wiki and does not exist
in the new. This reference was introduced by 22735:cb94dbe20f97 and was
supposed to have been written prior to the 4.1 release. I have transitioned it
anyway but it's not clear how valuable the message actually is. Perhaps we
should just remove that aspect of it?

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

diff -r dbdc840f8f62 -r 14a8af47bf11 README
--- a/README	Wed Nov 16 18:21:14 2011 +0000
+++ b/README	Thu Nov 17 14:34:11 2011 +0000
@@ -59,10 +59,10 @@ provided by your OS distributor:
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
 no suitable kernel is available from your OS distributor then refer to
-http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
+http://wiki.xen.org/wiki/XenDom0Kernels for suggestions for
 suitable kernels to use.
 If you are looking to compile a Dom0 kernel from source, please refer to
-http://wiki.xensource.com/xenwiki/XenParavirtOps.
+http://wiki.xensource.com/wiki/XenParavirtOps.
 
 [NB. Unless noted otherwise, all the following steps should be
 performed with root privileges.]
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/misc/vtd.txt
--- a/docs/misc/vtd.txt	Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/misc/vtd.txt	Thu Nov 17 14:34:11 2011 +0000
@@ -184,7 +184,7 @@ http://www.dell.com/content/products/cat
 - HP Compaq:  DC7800
 http://h10010.www1.hp.com/wwpc/us/en/en/WF04a/12454-12454-64287-321860-3328898.html
 
-For more information, pls refer to http://wiki.xensource.com/xenwiki/VTdHowTo.
+For more information, pls refer to http://wiki.xensource.com/wiki/VTdHowTo.
 
 
 Assigning devices to HVM domains
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/misc/xl-network-configuration.markdown	Thu Nov 17 14:34:11 2011 +0000
@@ -123,4 +123,4 @@ defaults to domain 0. Specifying another
 driver domain which is outside the scope of this document.
 
 [oui]: http://en.wikipedia.org/wiki/Organizationally_Unique_Identifier
-[net]: http://wiki.xen.org/xenwiki/HostConfiguration/Networking
+[net]: http://wiki.xen.org/wiki/HostConfiguration/Networking
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/src/interface.tex
--- a/docs/src/interface.tex	Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/src/interface.tex	Thu Nov 17 14:34:11 2011 +0000
@@ -1579,7 +1579,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xensource.com/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/src/user.tex
--- a/docs/src/user.tex	Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/src/user.tex	Thu Nov 17 14:34:11 2011 +0000
@@ -2349,7 +2349,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xensource.com/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r dbdc840f8f62 -r 14a8af47bf11 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Thu Nov 17 14:34:11 2011 +0000
@@ -72,7 +72,7 @@ static void parse(CfgParseContext *ctx) 
         fputs(
  "warning: Config file looks like it contains Python code.\n"
  "warning:  Arbitrary Python is no longer supported.\n"
- "warning:  See http://wiki.xen.org/xenwiki/PythonInXlConfig\n",
+ "warning:  See http://wiki.xen.org/wiki/PythonInXlConfig\n",
               ctx->cfg->report);
     }
 }
diff -r dbdc840f8f62 -r 14a8af47bf11 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/sched_credit2.c	Thu Nov 17 14:34:11 2011 +0000
@@ -51,7 +51,7 @@
 /*
  * WARNING: This is still in an experimental phase.  Status and work can be found at the
  * credit2 wiki page:
- *  http://wiki.xensource.com/xenwiki/Credit2_Scheduler_Development
+ *  http://wiki.xensource.com/wiki/Credit2_Scheduler_Development
  * TODO:
  * + Immediate bug-fixes
  *  - Do per-runqueue, grab proper lock for dump debugkey

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:25:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:25:49 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3qW-00023a-Sn
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:25:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3qE-0006po-Ru; Thu, 17 Nov 2011 07:25:31 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TV-0002Qh-5j
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:28 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321542115!3938195!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14025 invoked from network); 17 Nov 2011 15:01:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990605"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:50 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNA026208;	Thu, 17 Nov 2011 07:01:49 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 14a8af47bf11e9e4be35a0000336b49da95d9860
Message-ID: <14a8af47bf11e9e4be35.1321542107@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 01 of 17] Replace references to old wiki with
	ones to new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540451 0
# Node ID 14a8af47bf11e9e4be35a0000336b49da95d9860
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Replace references to old wiki with ones to new.

I have confirmed that the relevant pages have been transitioned.

What remains is pages which have not yet been moved over:

$ rgrep xenwiki *
docs/misc/xenstore.txt:	See http://wiki.xensource.com/xenwiki/XenBus section
tools/libxen/README:http://wiki.xensource.com/xenwiki/XenApi
tools/xenballoon/xenballoond.README:http://wiki.xensource.com/xenwiki/Open_Topics_For_Discussion?action=AttachFile&do=get&target=Memory+Overcommit.pdf

Note that "PythonInXlConfig" never existed in the old wiki and does not exist
in the new. This reference was introduced by 22735:cb94dbe20f97 and was
supposed to have been written prior to the 4.1 release. I have transitioned it
anyway but it's not clear how valuable the message actually is. Perhaps we
should just remove that aspect of it?

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

diff -r dbdc840f8f62 -r 14a8af47bf11 README
--- a/README	Wed Nov 16 18:21:14 2011 +0000
+++ b/README	Thu Nov 17 14:34:11 2011 +0000
@@ -59,10 +59,10 @@ provided by your OS distributor:
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
 no suitable kernel is available from your OS distributor then refer to
-http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
+http://wiki.xen.org/wiki/XenDom0Kernels for suggestions for
 suitable kernels to use.
 If you are looking to compile a Dom0 kernel from source, please refer to
-http://wiki.xensource.com/xenwiki/XenParavirtOps.
+http://wiki.xensource.com/wiki/XenParavirtOps.
 
 [NB. Unless noted otherwise, all the following steps should be
 performed with root privileges.]
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/misc/vtd.txt
--- a/docs/misc/vtd.txt	Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/misc/vtd.txt	Thu Nov 17 14:34:11 2011 +0000
@@ -184,7 +184,7 @@ http://www.dell.com/content/products/cat
 - HP Compaq:  DC7800
 http://h10010.www1.hp.com/wwpc/us/en/en/WF04a/12454-12454-64287-321860-3328898.html
 
-For more information, pls refer to http://wiki.xensource.com/xenwiki/VTdHowTo.
+For more information, pls refer to http://wiki.xensource.com/wiki/VTdHowTo.
 
 
 Assigning devices to HVM domains
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/misc/xl-network-configuration.markdown	Thu Nov 17 14:34:11 2011 +0000
@@ -123,4 +123,4 @@ defaults to domain 0. Specifying another
 driver domain which is outside the scope of this document.
 
 [oui]: http://en.wikipedia.org/wiki/Organizationally_Unique_Identifier
-[net]: http://wiki.xen.org/xenwiki/HostConfiguration/Networking
+[net]: http://wiki.xen.org/wiki/HostConfiguration/Networking
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/src/interface.tex
--- a/docs/src/interface.tex	Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/src/interface.tex	Thu Nov 17 14:34:11 2011 +0000
@@ -1579,7 +1579,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xensource.com/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/src/user.tex
--- a/docs/src/user.tex	Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/src/user.tex	Thu Nov 17 14:34:11 2011 +0000
@@ -2349,7 +2349,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xensource.com/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r dbdc840f8f62 -r 14a8af47bf11 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Thu Nov 17 14:34:11 2011 +0000
@@ -72,7 +72,7 @@ static void parse(CfgParseContext *ctx) 
         fputs(
  "warning: Config file looks like it contains Python code.\n"
  "warning:  Arbitrary Python is no longer supported.\n"
- "warning:  See http://wiki.xen.org/xenwiki/PythonInXlConfig\n",
+ "warning:  See http://wiki.xen.org/wiki/PythonInXlConfig\n",
               ctx->cfg->report);
     }
 }
diff -r dbdc840f8f62 -r 14a8af47bf11 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/sched_credit2.c	Thu Nov 17 14:34:11 2011 +0000
@@ -51,7 +51,7 @@
 /*
  * WARNING: This is still in an experimental phase.  Status and work can be found at the
  * credit2 wiki page:
- *  http://wiki.xensource.com/xenwiki/Credit2_Scheduler_Development
+ *  http://wiki.xensource.com/wiki/Credit2_Scheduler_Development
  * TODO:
  * + Immediate bug-fixes
  *  - Do per-runqueue, grab proper lock for dump debugkey

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:27:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:27:38 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3sI-00023n-Lu
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3rz-0007Dq-92; Thu, 17 Nov 2011 07:27:20 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TZ-0002R2-9c
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:26 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!7
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16987 invoked from network); 17 Nov 2011 15:02:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189115"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:02:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:01 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNN026208;	Thu, 17 Nov 2011 07:02:00 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 7d77e0269af797cb8ab8e7d536412a222e7da3ef
Message-ID: <7d77e0269af797cb8ab8.1321542120@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:02:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 14 of 17] docs: move user and interface .tex
 documents under reference
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542088 0
# Node ID 7d77e0269af797cb8ab8e7d536412a222e7da3ef
# Parent  8f2404eef8fac8020528b408b3a958d81cbb73c0
docs: move user and interface .tex documents under reference.

Taking over the top level "user" entry with a relatively obsolete document is a
bit of an annoyance but these docs are not so out of date that they should be
deleted. Move them out of the top-level instead.

(the original motivation here was to allow for user/xl-domain-cfg.markdown but
we have since decided to go with man/xl.cfg.pod.5 instead so perhaps this is a
waste of time)

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

diff -r 8f2404eef8fa -r 7d77e0269af7 docs/INDEX
--- a/docs/INDEX	Thu Nov 17 15:01:15 2011 +0000
+++ b/docs/INDEX	Thu Nov 17 15:01:28 2011 +0000
@@ -1,5 +1,5 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
 # These are not all that useful anymore, hide them from the index
-interface/index			NO-INDEX
-user/index			NO-INDEX
+reference/interface/index	NO-INDEX
+reference/user/index		NO-INDEX
diff -r 8f2404eef8fa -r 7d77e0269af7 docs/Makefile
--- a/docs/Makefile	Thu Nov 17 15:01:15 2011 +0000
+++ b/docs/Makefile	Thu Nov 17 15:01:28 2011 +0000
@@ -14,7 +14,7 @@ DOC_TEX		:= src/user.tex src/interface.t
 DOC_MARKDOWN	:= $(wildcard misc/*.markdown)
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
-DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
+DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
 		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
@@ -119,14 +119,14 @@ ps/%.ps: %.dvi
 %.eps: %.fig
 	$(FIG2DEV) -L eps $< $@
 
-html/%/index.html: src/%.tex
+html/reference/%/index.html: src/%.tex
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(LATEX2HTML) 1>/dev/null 2>/dev/null; then \
-        echo "Running latex2html to generate $*/index.html ... "; \
+        echo "Running latex2html to generate reference/$*/index.html ... "; \
 	$(LATEX2HTML) -split 0 -show_section_numbers -toc_depth 3 -nonavigation \
 	-numbered_footnotes -local_icons -noinfo -math -dir $(@D) \
 	$< 1>/dev/null 2>/dev/null ; else \
-	echo "latex2html not installed; skipping $*."; fi
+	echo "latex2html not installed; skipping reference/$*."; fi
 
 html/index.html: $(DOC_HTML) ./gen-html-index INDEX
 	./gen-html-index -i INDEX html $(DOC_HTML)

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:27:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:27:38 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3sI-00023n-Lu
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3rz-0007Dq-92; Thu, 17 Nov 2011 07:27:20 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TZ-0002R2-9c
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:26 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!7
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16987 invoked from network); 17 Nov 2011 15:02:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189115"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:02:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:01 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNN026208;	Thu, 17 Nov 2011 07:02:00 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 7d77e0269af797cb8ab8e7d536412a222e7da3ef
Message-ID: <7d77e0269af797cb8ab8.1321542120@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:02:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 14 of 17] docs: move user and interface .tex
 documents under reference
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542088 0
# Node ID 7d77e0269af797cb8ab8e7d536412a222e7da3ef
# Parent  8f2404eef8fac8020528b408b3a958d81cbb73c0
docs: move user and interface .tex documents under reference.

Taking over the top level "user" entry with a relatively obsolete document is a
bit of an annoyance but these docs are not so out of date that they should be
deleted. Move them out of the top-level instead.

(the original motivation here was to allow for user/xl-domain-cfg.markdown but
we have since decided to go with man/xl.cfg.pod.5 instead so perhaps this is a
waste of time)

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

diff -r 8f2404eef8fa -r 7d77e0269af7 docs/INDEX
--- a/docs/INDEX	Thu Nov 17 15:01:15 2011 +0000
+++ b/docs/INDEX	Thu Nov 17 15:01:28 2011 +0000
@@ -1,5 +1,5 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
 # These are not all that useful anymore, hide them from the index
-interface/index			NO-INDEX
-user/index			NO-INDEX
+reference/interface/index	NO-INDEX
+reference/user/index		NO-INDEX
diff -r 8f2404eef8fa -r 7d77e0269af7 docs/Makefile
--- a/docs/Makefile	Thu Nov 17 15:01:15 2011 +0000
+++ b/docs/Makefile	Thu Nov 17 15:01:28 2011 +0000
@@ -14,7 +14,7 @@ DOC_TEX		:= src/user.tex src/interface.t
 DOC_MARKDOWN	:= $(wildcard misc/*.markdown)
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
-DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
+DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
 		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
@@ -119,14 +119,14 @@ ps/%.ps: %.dvi
 %.eps: %.fig
 	$(FIG2DEV) -L eps $< $@
 
-html/%/index.html: src/%.tex
+html/reference/%/index.html: src/%.tex
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(LATEX2HTML) 1>/dev/null 2>/dev/null; then \
-        echo "Running latex2html to generate $*/index.html ... "; \
+        echo "Running latex2html to generate reference/$*/index.html ... "; \
 	$(LATEX2HTML) -split 0 -show_section_numbers -toc_depth 3 -nonavigation \
 	-numbered_footnotes -local_icons -noinfo -math -dir $(@D) \
 	$< 1>/dev/null 2>/dev/null ; else \
-	echo "latex2html not installed; skipping $*."; fi
+	echo "latex2html not installed; skipping reference/$*."; fi
 
 html/index.html: $(DOC_HTML) ./gen-html-index INDEX
 	./gen-html-index -i INDEX html $(DOC_HTML)

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:29:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:29:32 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3u8-000240-9n
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:29:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3tn-0007cA-50; Thu, 17 Nov 2011 07:29:11 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3Te-0002Ri-0m
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:32 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321542117!1909981!5
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12012 invoked from network); 17 Nov 2011 15:02:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990660"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:02:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:03 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNP026208;	Thu, 17 Nov 2011 07:02:02 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: bd514e08c509dd62a1db26318782ab37646788f5
Message-ID: <bd514e08c509dd62a1db.1321542122@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:02:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 16 of 17] xl: make bootloader_args a list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542097 0
# Node ID bd514e08c509dd62a1db26318782ab37646788f5
# Parent  29d91e4d1f4f8d9233014b616547a9aed53b1515
xl: make bootloader_args a list

This is much more natural. Continue to support the old syntax in xl but deprecate it.

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

diff -r 29d91e4d1f4f -r bd514e08c509 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Nov 17 15:01:35 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Thu Nov 17 15:01:37 2011 +0000
@@ -321,10 +321,11 @@ Run C<PROGRAM> to find the kernel image 
 C<PROGRAM> would be C<pygrub>, which is an emulation of
 grub/grub2/syslinux.
 
-=item B<bootloader_args=STRING>
+=item B<bootloader_args=[ "ARG", "ARG", ...]>
 
-Append B<STRING> (split into words at whitespace) to the arguments to
-the B<bootloader> program.  XXX this should be a list of strings.
+Append B<ARGs to the arguments to the B<bootloader>
+program. Alternatively if the argument is a simple string then it will
+be split into words at whitespace (this second option is deprecated).
 
 =item B<root="STRING">
 
diff -r 29d91e4d1f4f -r bd514e08c509 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Nov 17 15:01:35 2011 +0000
+++ b/tools/libxl/libxl_bootloader.c	Thu Nov 17 15:01:37 2011 +0000
@@ -58,13 +58,9 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *saveptr;
-        /* Operate on a duplicate since strtok modifes the argument */
-        char *dup = libxl__strdup(gc, info->u.pv.bootloader_args);
-        char *t = strtok_r(dup, " \t\n", &saveptr);
-        do {
-            flexarray_set(args, nr++, t);
-        } while ((t = strtok_r(NULL, " \t\n", &saveptr)));
+        char *p = info->u.pv.bootloader_args[0];
+        while (*(p++))
+            flexarray_set(args, nr++, p);
     }
 
     flexarray_set(args, nr++, disk);
diff -r 29d91e4d1f4f -r bd514e08c509 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Nov 17 15:01:35 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Nov 17 15:01:37 2011 +0000
@@ -185,7 +185,7 @@ libxl_domain_build_info = Struct("domain
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
                                       ("bootloader", string),
-                                      ("bootloader_args", string),
+                                      ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, True),
diff -r 29d91e4d1f4f -r bd514e08c509 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 15:01:35 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 15:01:37 2011 +0000
@@ -334,9 +334,14 @@ static void printf_info(int domid,
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
+        int i;
         printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
-        if (b_info->u.pv.bootloader_args)
-            printf("\t(bootloader_args %s)\n", b_info->u.pv.bootloader_args);
+        if (b_info->u.pv.bootloader_args) {
+            printf("\t(bootloader_args");
+            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
+                printf(" %s", b_info->u.pv.bootloader_args[i]);
+            printf(")\n");
+        }
     }
 
     printf("\t(image\n");
@@ -515,6 +520,51 @@ static void parse_disk_config(XLU_Config
     parse_disk_config_multistring(config, 1, &spec, disk);
 }
 
+static void split_string_into_string_list(const char *str,
+                                          const char *delim,
+                                          libxl_string_list *psl)
+{
+    char *s, *saveptr;
+    const char *p;
+    libxl_string_list sl;
+
+    int i = 0, nr = 0;
+
+    s = strdup(str);
+    if (s == NULL) {
+        fprintf(stderr, "unable to allocate memory to parse bootloader args\n");
+        exit(-1);
+    }
+
+    /* Count number of entries */
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        nr++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+
+    free(s);
+
+    s = strdup(str);
+
+    sl = malloc((nr+1) * sizeof (char *));
+    if (sl == NULL) {
+        fprintf(stderr, "unable to allocate memory for bootloader args\n");
+        exit(-1);
+    }
+
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        assert(i < nr);
+        sl[i] = strdup(p);
+        i++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+    sl[i] = NULL;
+
+    *psl = sl;
+
+    free(s);
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -735,10 +785,26 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader",
-                                &b_info->u.pv.bootloader, 0);
-        xlu_cfg_replace_string (config, "bootloader_args",
-                                &b_info->u.pv.bootloader_args, 0);
+        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader, 0);
+        switch (xlu_cfg_get_list_as_string_list(config, "bootloader_args",
+                                                &b_info->u.pv.bootloader_args, 1))
+        {
+
+        case 0: break; /* Success */
+        case ESRCH: break; /* Option not present */
+        case EINVAL:
+            if (!xlu_cfg_get_string(config, "bootloader_args", &buf, 0)) {
+
+                fprintf(stderr, "WARNING: Specifying \"bootloader_args\" as a string is deprecated. "
+                        "Please use a list of arguments.\n");
+                split_string_into_string_list(buf, " \t\n",
+                                              &b_info->u.pv.bootloader_args);
+            }
+            break;
+        default:
+            fprintf(stderr,"xl: Unable to parse bootloader_args.\n");
+            exit(-ERROR_FAIL);
+        }
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:29:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:29:32 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3u8-000240-9n
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:29:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3tn-0007cA-50; Thu, 17 Nov 2011 07:29:11 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3Te-0002Ri-0m
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:32 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321542117!1909981!5
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12012 invoked from network); 17 Nov 2011 15:02:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990660"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:02:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:03 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNP026208;	Thu, 17 Nov 2011 07:02:02 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: bd514e08c509dd62a1db26318782ab37646788f5
Message-ID: <bd514e08c509dd62a1db.1321542122@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:02:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 16 of 17] xl: make bootloader_args a list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542097 0
# Node ID bd514e08c509dd62a1db26318782ab37646788f5
# Parent  29d91e4d1f4f8d9233014b616547a9aed53b1515
xl: make bootloader_args a list

This is much more natural. Continue to support the old syntax in xl but deprecate it.

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

diff -r 29d91e4d1f4f -r bd514e08c509 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Nov 17 15:01:35 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Thu Nov 17 15:01:37 2011 +0000
@@ -321,10 +321,11 @@ Run C<PROGRAM> to find the kernel image 
 C<PROGRAM> would be C<pygrub>, which is an emulation of
 grub/grub2/syslinux.
 
-=item B<bootloader_args=STRING>
+=item B<bootloader_args=[ "ARG", "ARG", ...]>
 
-Append B<STRING> (split into words at whitespace) to the arguments to
-the B<bootloader> program.  XXX this should be a list of strings.
+Append B<ARGs to the arguments to the B<bootloader>
+program. Alternatively if the argument is a simple string then it will
+be split into words at whitespace (this second option is deprecated).
 
 =item B<root="STRING">
 
diff -r 29d91e4d1f4f -r bd514e08c509 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Thu Nov 17 15:01:35 2011 +0000
+++ b/tools/libxl/libxl_bootloader.c	Thu Nov 17 15:01:37 2011 +0000
@@ -58,13 +58,9 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *saveptr;
-        /* Operate on a duplicate since strtok modifes the argument */
-        char *dup = libxl__strdup(gc, info->u.pv.bootloader_args);
-        char *t = strtok_r(dup, " \t\n", &saveptr);
-        do {
-            flexarray_set(args, nr++, t);
-        } while ((t = strtok_r(NULL, " \t\n", &saveptr)));
+        char *p = info->u.pv.bootloader_args[0];
+        while (*(p++))
+            flexarray_set(args, nr++, p);
     }
 
     flexarray_set(args, nr++, disk);
diff -r 29d91e4d1f4f -r bd514e08c509 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Nov 17 15:01:35 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Nov 17 15:01:37 2011 +0000
@@ -185,7 +185,7 @@ libxl_domain_build_info = Struct("domain
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
                                       ("bootloader", string),
-                                      ("bootloader_args", string),
+                                      ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, True),
diff -r 29d91e4d1f4f -r bd514e08c509 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 15:01:35 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 15:01:37 2011 +0000
@@ -334,9 +334,14 @@ static void printf_info(int domid,
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
+        int i;
         printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
-        if (b_info->u.pv.bootloader_args)
-            printf("\t(bootloader_args %s)\n", b_info->u.pv.bootloader_args);
+        if (b_info->u.pv.bootloader_args) {
+            printf("\t(bootloader_args");
+            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
+                printf(" %s", b_info->u.pv.bootloader_args[i]);
+            printf(")\n");
+        }
     }
 
     printf("\t(image\n");
@@ -515,6 +520,51 @@ static void parse_disk_config(XLU_Config
     parse_disk_config_multistring(config, 1, &spec, disk);
 }
 
+static void split_string_into_string_list(const char *str,
+                                          const char *delim,
+                                          libxl_string_list *psl)
+{
+    char *s, *saveptr;
+    const char *p;
+    libxl_string_list sl;
+
+    int i = 0, nr = 0;
+
+    s = strdup(str);
+    if (s == NULL) {
+        fprintf(stderr, "unable to allocate memory to parse bootloader args\n");
+        exit(-1);
+    }
+
+    /* Count number of entries */
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        nr++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+
+    free(s);
+
+    s = strdup(str);
+
+    sl = malloc((nr+1) * sizeof (char *));
+    if (sl == NULL) {
+        fprintf(stderr, "unable to allocate memory for bootloader args\n");
+        exit(-1);
+    }
+
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        assert(i < nr);
+        sl[i] = strdup(p);
+        i++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+    sl[i] = NULL;
+
+    *psl = sl;
+
+    free(s);
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -735,10 +785,26 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader",
-                                &b_info->u.pv.bootloader, 0);
-        xlu_cfg_replace_string (config, "bootloader_args",
-                                &b_info->u.pv.bootloader_args, 0);
+        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader, 0);
+        switch (xlu_cfg_get_list_as_string_list(config, "bootloader_args",
+                                                &b_info->u.pv.bootloader_args, 1))
+        {
+
+        case 0: break; /* Success */
+        case ESRCH: break; /* Option not present */
+        case EINVAL:
+            if (!xlu_cfg_get_string(config, "bootloader_args", &buf, 0)) {
+
+                fprintf(stderr, "WARNING: Specifying \"bootloader_args\" as a string is deprecated. "
+                        "Please use a list of arguments.\n");
+                split_string_into_string_list(buf, " \t\n",
+                                              &b_info->u.pv.bootloader_args);
+            }
+            break;
+        default:
+            fprintf(stderr,"xl: Unable to parse bootloader_args.\n");
+            exit(-ERROR_FAIL);
+        }
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:31:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:31:00 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3vY-00024D-HS
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:31:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3vG-000801-Uf; Thu, 17 Nov 2011 07:30:43 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TV-0002Qi-Bl
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:33 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!5
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16800 invoked from network); 17 Nov 2011 15:01:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189110"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:57 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNI026208;	Thu, 17 Nov 2011 07:01:56 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: c4571d33f5829bac2e1da169f9d1398810c0b7d2
Message-ID: <c4571d33f5829bac2e1d.1321542115@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:55 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 09 of 17] libxl: use named options for tsc_mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540537 0
# Node ID c4571d33f5829bac2e1da169f9d1398810c0b7d2
# Parent  6911d1235f82e52b0b16eeb505ebf80054e47f40
libxl: use named options for tsc_mode.

Add an enum at the libxl level with a hopefully descriptive set of names.
Deprecate the use of an integer in xl cfg files.

Signed-off-by: Ian Campbell

diff -r 6911d1235f82 -r c4571d33f582 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Nov 17 14:35:37 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Thu Nov 17 14:35:37 2011 +0000
@@ -491,11 +491,45 @@ compatibility mode on more modern Window
 
 =item B<tsc_mode="MODE">
 
+
 Specifies how the TSC (Time Stamp Counter) should be provided to the
-guest.  XXX ???
+guest (X86 only). Specifying this option as a number is
+deprecated. Options are:
+
+=over 4
+
+=item B<"default">
+
+Guest rdtsc/p executed natively when monotonicity can be guaranteed
+and emulated otherwise (with frequency scaled if necessary).
+
+=item B<"always_emulate">
+
+Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
+always emulated and the virtual TSC will appear to increment (kernel
+and user) at a fixed 1GHz rate, regardless of the PCPU HZ rate or
+power state; Although there is an overhead associated with emulation
+this will NOT affect underlying CPU performance.
+
+=item B<"native">
+
+Guest rdtsc always executed natively (no monotonicity/frequency
+guarantees); guest rdtscp emulated at native frequency if unsupported
+by h/w, else executed natively.
+
+=item B<"native_paravirt">
+
+Same as B<native>, except xen manages TSC_AUX register so guest can
+determine when a restore/migration has occurred and assumes guest
+obtains/uses pvclock-like mechanism to adjust for monotonicity and
+frequency changes.
 
 =back
 
+=back
+
+Please see F<docs/misc/tscmode.txt> for more information on this option.
+
 =head3 Support for Paravirtualisation of HVM Guests
 
 The following options allow Paravirtualised features (such as devices)
diff -r 6911d1235f82 -r c4571d33f582 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Nov 17 14:35:37 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Nov 17 14:35:37 2011 +0000
@@ -73,12 +73,29 @@ int libxl__build_pre(libxl__gc *gc, uint
               libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    int tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
                 (info->max_memkb + info->u.pv.slack_memkb));
-    xc_domain_set_tsc_info(ctx->xch, domid, info->tsc_mode, 0, 0, 0);
+    switch (info->tsc_mode) {
+    case LIBXL_TSC_MODE_DEFAULT:
+        tsc_mode = 0;
+        break;
+    case LIBXL_TSC_MODE_ALWAYS_EMULATE:
+        tsc_mode = 1;
+        break;
+    case LIBXL_TSC_MODE_NATIVE:
+        tsc_mode = 2;
+        break;
+    case LIBXL_TSC_MODE_NATIVE_PARAVIRT:
+        tsc_mode = 3;
+        break;
+    default:
+        abort();
+    }
+    xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
     if ( info->disable_migrate )
         xc_domain_disable_migrate(ctx->xch, domid);
 
diff -r 6911d1235f82 -r c4571d33f582 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Nov 17 14:35:37 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Nov 17 14:35:37 2011 +0000
@@ -85,6 +85,13 @@ libxl_button = Enumeration("button", [
     (2, "SLEEP"),
     ])
 
+libxl_tsc_mode = Enumeration("tsc_mode", [
+    (0, "default"),
+    (1, "always_emulate"),
+    (2, "native"),
+    (3, "native_paravirt"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -154,7 +161,7 @@ libxl_domain_create_info = Struct("domai
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
-    ("tsc_mode",        integer),
+    ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
     ("video_memkb",     uint32),
diff -r 6911d1235f82 -r c4571d33f582 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:37 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:37 2011 +0000
@@ -328,7 +328,7 @@ static void printf_info(int domid,
 
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
-    printf("\t(tsc_mode %d)\n", b_info->tsc_mode);
+    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
@@ -662,8 +662,28 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
+        const char *s = libxl_tsc_mode_to_string(l);
+        fprintf(stderr, "WARNING: specifying \"tsc_mode\" as an integer is deprecated. "
+                "Please use the named parameter variant. %s%s%s\n",
+                s ? "e.g. tsc_mode=\"" : "",
+                s ? s : "",
+                s ? "\"" : "");
+
+        if (l < LIBXL_TSC_MODE_DEFAULT ||
+            l > LIBXL_TSC_MODE_NATIVE_PARAVIRT) {
+            fprintf(stderr, "ERROR: invalid value %ld for \"tsc_mode\"\n", l);
+            exit (1);
+        }
         b_info->tsc_mode = l;
+    } else if (!xlu_cfg_get_string(config, "tsc_mode", &buf, 0)) {
+        fprintf(stderr, "got a tsc mode string: \"%s\"\n", buf);
+        if (libxl_tsc_mode_from_string(buf, &b_info->tsc_mode)) {
+            fprintf(stderr, "ERROR: invalid value \"%s\" for \"tsc_mode\"\n",
+                    buf);
+            exit (1);
+        }
+    }
 
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:31:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:31:00 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3vY-00024D-HS
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:31:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3vG-000801-Uf; Thu, 17 Nov 2011 07:30:43 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TV-0002Qi-Bl
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:33 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!5
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16800 invoked from network); 17 Nov 2011 15:01:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189110"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:57 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNI026208;	Thu, 17 Nov 2011 07:01:56 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: c4571d33f5829bac2e1da169f9d1398810c0b7d2
Message-ID: <c4571d33f5829bac2e1d.1321542115@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:55 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 09 of 17] libxl: use named options for tsc_mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540537 0
# Node ID c4571d33f5829bac2e1da169f9d1398810c0b7d2
# Parent  6911d1235f82e52b0b16eeb505ebf80054e47f40
libxl: use named options for tsc_mode.

Add an enum at the libxl level with a hopefully descriptive set of names.
Deprecate the use of an integer in xl cfg files.

Signed-off-by: Ian Campbell

diff -r 6911d1235f82 -r c4571d33f582 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Thu Nov 17 14:35:37 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Thu Nov 17 14:35:37 2011 +0000
@@ -491,11 +491,45 @@ compatibility mode on more modern Window
 
 =item B<tsc_mode="MODE">
 
+
 Specifies how the TSC (Time Stamp Counter) should be provided to the
-guest.  XXX ???
+guest (X86 only). Specifying this option as a number is
+deprecated. Options are:
+
+=over 4
+
+=item B<"default">
+
+Guest rdtsc/p executed natively when monotonicity can be guaranteed
+and emulated otherwise (with frequency scaled if necessary).
+
+=item B<"always_emulate">
+
+Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
+always emulated and the virtual TSC will appear to increment (kernel
+and user) at a fixed 1GHz rate, regardless of the PCPU HZ rate or
+power state; Although there is an overhead associated with emulation
+this will NOT affect underlying CPU performance.
+
+=item B<"native">
+
+Guest rdtsc always executed natively (no monotonicity/frequency
+guarantees); guest rdtscp emulated at native frequency if unsupported
+by h/w, else executed natively.
+
+=item B<"native_paravirt">
+
+Same as B<native>, except xen manages TSC_AUX register so guest can
+determine when a restore/migration has occurred and assumes guest
+obtains/uses pvclock-like mechanism to adjust for monotonicity and
+frequency changes.
 
 =back
 
+=back
+
+Please see F<docs/misc/tscmode.txt> for more information on this option.
+
 =head3 Support for Paravirtualisation of HVM Guests
 
 The following options allow Paravirtualised features (such as devices)
diff -r 6911d1235f82 -r c4571d33f582 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Nov 17 14:35:37 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Nov 17 14:35:37 2011 +0000
@@ -73,12 +73,29 @@ int libxl__build_pre(libxl__gc *gc, uint
               libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    int tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
                 (info->max_memkb + info->u.pv.slack_memkb));
-    xc_domain_set_tsc_info(ctx->xch, domid, info->tsc_mode, 0, 0, 0);
+    switch (info->tsc_mode) {
+    case LIBXL_TSC_MODE_DEFAULT:
+        tsc_mode = 0;
+        break;
+    case LIBXL_TSC_MODE_ALWAYS_EMULATE:
+        tsc_mode = 1;
+        break;
+    case LIBXL_TSC_MODE_NATIVE:
+        tsc_mode = 2;
+        break;
+    case LIBXL_TSC_MODE_NATIVE_PARAVIRT:
+        tsc_mode = 3;
+        break;
+    default:
+        abort();
+    }
+    xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
     if ( info->disable_migrate )
         xc_domain_disable_migrate(ctx->xch, domid);
 
diff -r 6911d1235f82 -r c4571d33f582 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Nov 17 14:35:37 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Nov 17 14:35:37 2011 +0000
@@ -85,6 +85,13 @@ libxl_button = Enumeration("button", [
     (2, "SLEEP"),
     ])
 
+libxl_tsc_mode = Enumeration("tsc_mode", [
+    (0, "default"),
+    (1, "always_emulate"),
+    (2, "native"),
+    (3, "native_paravirt"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -154,7 +161,7 @@ libxl_domain_create_info = Struct("domai
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
-    ("tsc_mode",        integer),
+    ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
     ("video_memkb",     uint32),
diff -r 6911d1235f82 -r c4571d33f582 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:37 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:37 2011 +0000
@@ -328,7 +328,7 @@ static void printf_info(int domid,
 
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
-    printf("\t(tsc_mode %d)\n", b_info->tsc_mode);
+    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
@@ -662,8 +662,28 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
+        const char *s = libxl_tsc_mode_to_string(l);
+        fprintf(stderr, "WARNING: specifying \"tsc_mode\" as an integer is deprecated. "
+                "Please use the named parameter variant. %s%s%s\n",
+                s ? "e.g. tsc_mode=\"" : "",
+                s ? s : "",
+                s ? "\"" : "");
+
+        if (l < LIBXL_TSC_MODE_DEFAULT ||
+            l > LIBXL_TSC_MODE_NATIVE_PARAVIRT) {
+            fprintf(stderr, "ERROR: invalid value %ld for \"tsc_mode\"\n", l);
+            exit (1);
+        }
         b_info->tsc_mode = l;
+    } else if (!xlu_cfg_get_string(config, "tsc_mode", &buf, 0)) {
+        fprintf(stderr, "got a tsc mode string: \"%s\"\n", buf);
+        if (libxl_tsc_mode_from_string(buf, &b_info->tsc_mode)) {
+            fprintf(stderr, "ERROR: invalid value \"%s\" for \"tsc_mode\"\n",
+                    buf);
+            exit (1);
+        }
+    }
 
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:31:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:31:52 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3wO-00024Q-2c
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3w6-0008NH-IP; Thu, 17 Nov 2011 07:31:34 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TQ-0002QV-B6
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:30 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16499 invoked from network); 17 Nov 2011 15:01:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189105"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:51 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNB026208;	Thu, 17 Nov 2011 07:01:50 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 5e3e5757de0fcd0b826d0ca8330db7fa1cfccba4
Message-ID: <5e3e5757de0fcd0b826d.1321542108@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:48 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 02 of 17] docs: xlexample.hvm is missing
	"builder = 'hvm'"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540451 0
# Node ID 5e3e5757de0fcd0b826d0ca8330db7fa1cfccba4
# Parent  14a8af47bf11e9e4be35a0000336b49da95d9860
docs: xlexample.hvm is missing "builder = 'hvm'"

This is rather critical...

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

diff -r 14a8af47bf11 -r 5e3e5757de0f tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Thu Nov 17 14:34:11 2011 +0000
+++ b/tools/examples/xlexample.hvm	Thu Nov 17 14:34:11 2011 +0000
@@ -5,6 +5,9 @@
 # This is a fairly minimal example of what is required for an
 # HVM guest. For a more complete guide see <XXX Document TBD>
 
+# This configures an HVM rather than PV guest
+builder = "hvm"
+
 # Guest name
 name = "example.hvm"
 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:31:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:31:52 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3wO-00024Q-2c
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3w6-0008NH-IP; Thu, 17 Nov 2011 07:31:34 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TQ-0002QV-B6
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:30 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16499 invoked from network); 17 Nov 2011 15:01:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189105"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:51 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNB026208;	Thu, 17 Nov 2011 07:01:50 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 5e3e5757de0fcd0b826d0ca8330db7fa1cfccba4
Message-ID: <5e3e5757de0fcd0b826d.1321542108@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:48 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 02 of 17] docs: xlexample.hvm is missing
	"builder = 'hvm'"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540451 0
# Node ID 5e3e5757de0fcd0b826d0ca8330db7fa1cfccba4
# Parent  14a8af47bf11e9e4be35a0000336b49da95d9860
docs: xlexample.hvm is missing "builder = 'hvm'"

This is rather critical...

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

diff -r 14a8af47bf11 -r 5e3e5757de0f tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Thu Nov 17 14:34:11 2011 +0000
+++ b/tools/examples/xlexample.hvm	Thu Nov 17 14:34:11 2011 +0000
@@ -5,6 +5,9 @@
 # This is a fairly minimal example of what is required for an
 # HVM guest. For a more complete guide see <XXX Document TBD>
 
+# This configures an HVM rather than PV guest
+builder = "hvm"
+
 # Guest name
 name = "example.hvm"
 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:32:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:32:47 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3xH-00024d-4A
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3wz-0000Iz-5b; Thu, 17 Nov 2011 07:32:29 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TW-0002Qo-IQ
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:28 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321542116!3546609!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5110 invoked from network); 17 Nov 2011 15:01:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990617"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:55 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNG026208;	Thu, 17 Nov 2011 07:01:54 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: f1464f6fba419acc019c824cea4aefb97b2360f6
Message-ID: <f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final
	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540536 0
# Node ID f1464f6fba419acc019c824cea4aefb97b2360f6
# Parent  22264859117b883d37b563ddad14515d80568a4e
docs: generate docs direct into final filename

Nothing depends on the final document so there is not much point in generating
to a tempfile and move-if-changed.

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

diff -r 22264859117b -r f1464f6fba41 docs/Makefile
--- a/docs/Makefile	Thu Nov 17 14:35:36 2011 +0000
+++ b/docs/Makefile	Thu Nov 17 14:35:36 2011 +0000
@@ -132,37 +132,30 @@ html/%.html: %.markdown
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \
 	echo "Running markdown to generate $*.html ... "; \
-	$(MARKDOWN) $< > $@.tmp ; \
-	$(call move-if-changed,$@.tmp,$@) ; else \
+	$(MARKDOWN) $< > $@ ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
 html/man/%.1.html: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2HTML) --infile=$< --outfile=$@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	$(POD2HTML) --infile=$< --outfile=$@
 
 html/man/%.5.html: man/%.pod.5 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2HTML) --infile=$< --outfile=$@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	$(POD2HTML) --infile=$< --outfile=$@
 
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
-	cp $< $@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	cp $< $@
 
 txt/%.txt: %.markdown
 	$(INSTALL_DIR) $(@D)
-	cp $< $@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	cp $< $@
 
 txt/man/%.1.txt: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2TEXT) $< $@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	$(POD2TEXT) $< $@
 
 txt/man/%.5.txt: man/%.pod.5 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2TEXT) $< $@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	$(POD2TEXT) $< $@
 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:32:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:32:47 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3xH-00024d-4A
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3wz-0000Iz-5b; Thu, 17 Nov 2011 07:32:29 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TW-0002Qo-IQ
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:28 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321542116!3546609!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5110 invoked from network); 17 Nov 2011 15:01:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990617"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:55 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNG026208;	Thu, 17 Nov 2011 07:01:54 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: f1464f6fba419acc019c824cea4aefb97b2360f6
Message-ID: <f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final
	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540536 0
# Node ID f1464f6fba419acc019c824cea4aefb97b2360f6
# Parent  22264859117b883d37b563ddad14515d80568a4e
docs: generate docs direct into final filename

Nothing depends on the final document so there is not much point in generating
to a tempfile and move-if-changed.

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

diff -r 22264859117b -r f1464f6fba41 docs/Makefile
--- a/docs/Makefile	Thu Nov 17 14:35:36 2011 +0000
+++ b/docs/Makefile	Thu Nov 17 14:35:36 2011 +0000
@@ -132,37 +132,30 @@ html/%.html: %.markdown
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \
 	echo "Running markdown to generate $*.html ... "; \
-	$(MARKDOWN) $< > $@.tmp ; \
-	$(call move-if-changed,$@.tmp,$@) ; else \
+	$(MARKDOWN) $< > $@ ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
 html/man/%.1.html: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2HTML) --infile=$< --outfile=$@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	$(POD2HTML) --infile=$< --outfile=$@
 
 html/man/%.5.html: man/%.pod.5 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2HTML) --infile=$< --outfile=$@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	$(POD2HTML) --infile=$< --outfile=$@
 
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
-	cp $< $@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	cp $< $@
 
 txt/%.txt: %.markdown
 	$(INSTALL_DIR) $(@D)
-	cp $< $@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	cp $< $@
 
 txt/man/%.1.txt: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2TEXT) $< $@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	$(POD2TEXT) $< $@
 
 txt/man/%.5.txt: man/%.pod.5 Makefile
 	$(INSTALL_DIR) $(@D)
-	$(POD2TEXT) $< $@.tmp
-	$(call move-if-changed,$@.tmp,$@)
+	$(POD2TEXT) $< $@
 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:33:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:33:41 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3y9-00024q-Ot
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3xs-0000jS-7u; Thu, 17 Nov 2011 07:33:24 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3Te-0002Rk-HI
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:29 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321542125!3564035!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13049 invoked from network); 17 Nov 2011 15:02:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990667"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:02:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:04 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNQ026208;	Thu, 17 Nov 2011 07:02:03 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 83fc69637135353021aaacc96ded8fbbad1a4244
Message-ID: <83fc69637135353021aa.1321542123@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:02:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 17 of 17] docs: install txt files as html
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542098 0
# Node ID 83fc69637135353021aaacc96ded8fbbad1a4244
# Parent  bd514e08c509dd62a1db26318782ab37646788f5
docs: install txt files as html

A browser will display them just fine.

NB: I'm not totally sure about this since many of the *.txt docs are out of
date or deeply technical etc. It might be preferable to simply add the minimal
necessary markdown to the ones we actually want to publish.

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

diff -r bd514e08c509 -r 83fc69637135 docs/INDEX
--- a/docs/INDEX	Thu Nov 17 15:01:37 2011 +0000
+++ b/docs/INDEX	Thu Nov 17 15:01:38 2011 +0000
@@ -1,5 +1,7 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
+misc/console.txt		Xen PV Console notes
+
 # These are not all that useful anymore, hide them from the index
 reference/interface/index	NO-INDEX
 reference/user/index		NO-INDEX
diff -r bd514e08c509 -r 83fc69637135 docs/Makefile
--- a/docs/Makefile	Thu Nov 17 15:01:37 2011 +0000
+++ b/docs/Makefile	Thu Nov 17 15:01:38 2011 +0000
@@ -17,7 +17,8 @@ DOC_PDF		:= $(patsubst src/%.tex,pdf/%.p
 DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
-		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC)) \
+		   $(patsubst %.txt,html/%.txt,$(wildcard misc/*.txt))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
@@ -138,6 +139,10 @@ html/%.html: %.markdown
 	$(MARKDOWN) $< > $@ ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/%.txt: %.txt
+	@$(INSTALL_DIR) $(@D)
+	cp $< $@
+
 html/man/%.1.html: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
 	$(POD2HTML) --infile=$< --outfile=$@

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:33:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:33:41 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3y9-00024q-Ot
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:33:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3xs-0000jS-7u; Thu, 17 Nov 2011 07:33:24 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3Te-0002Rk-HI
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:29 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321542125!3564035!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13049 invoked from network); 17 Nov 2011 15:02:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990667"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:02:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:04 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNQ026208;	Thu, 17 Nov 2011 07:02:03 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 83fc69637135353021aaacc96ded8fbbad1a4244
Message-ID: <83fc69637135353021aa.1321542123@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:02:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 17 of 17] docs: install txt files as html
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542098 0
# Node ID 83fc69637135353021aaacc96ded8fbbad1a4244
# Parent  bd514e08c509dd62a1db26318782ab37646788f5
docs: install txt files as html

A browser will display them just fine.

NB: I'm not totally sure about this since many of the *.txt docs are out of
date or deeply technical etc. It might be preferable to simply add the minimal
necessary markdown to the ones we actually want to publish.

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

diff -r bd514e08c509 -r 83fc69637135 docs/INDEX
--- a/docs/INDEX	Thu Nov 17 15:01:37 2011 +0000
+++ b/docs/INDEX	Thu Nov 17 15:01:38 2011 +0000
@@ -1,5 +1,7 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
+misc/console.txt		Xen PV Console notes
+
 # These are not all that useful anymore, hide them from the index
 reference/interface/index	NO-INDEX
 reference/user/index		NO-INDEX
diff -r bd514e08c509 -r 83fc69637135 docs/Makefile
--- a/docs/Makefile	Thu Nov 17 15:01:37 2011 +0000
+++ b/docs/Makefile	Thu Nov 17 15:01:38 2011 +0000
@@ -17,7 +17,8 @@ DOC_PDF		:= $(patsubst src/%.tex,pdf/%.p
 DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
-		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC)) \
+		   $(patsubst %.txt,html/%.txt,$(wildcard misc/*.txt))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
@@ -138,6 +139,10 @@ html/%.html: %.markdown
 	$(MARKDOWN) $< > $@ ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/%.txt: %.txt
+	@$(INSTALL_DIR) $(@D)
+	cp $< $@
+
 html/man/%.1.html: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
 	$(POD2HTML) --infile=$< --outfile=$@

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:34:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:34:39 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3z5-000253-AR
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:34:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3ym-00018A-Vy; Thu, 17 Nov 2011 07:34:21 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TW-0002Qp-DY
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:33 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321542115!3938195!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14064 invoked from network); 17 Nov 2011 15:01:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990614"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNE026208;	Thu, 17 Nov 2011 07:01:52 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: c88ff1ac24170a7d2a3c8824735ef9311eb95fe0
Message-ID: <c88ff1ac24170a7d2a3c.1321542111@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 05 of 17] docs: add a document describing the xl
 cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540524 0
# Node ID c88ff1ac24170a7d2a3c8824735ef9311eb95fe0
# Parent  f3fc909a083ddcea05cd0c9ab51a7241e573f6a6
docs: add a document describing the xl cfg file syntax

Based on an initial version by Ian Jackson.

I believe that all keys are now present in the document although there are are
various omissions in the actual documentation of them. Hopefully however this
covers the majority of the most interesting keys.

Spice section:
Signed-off-by: Zhou Peng <zhoupeng@nfs.iscas.ac.cn>

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

diff -r f3fc909a083d -r c88ff1ac2417 docs/man/xl.cfg.pod.5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/man/xl.cfg.pod.5	Thu Nov 17 14:35:24 2011 +0000
@@ -0,0 +1,844 @@
+=head1 NAME
+
+xl.cfg - XL Domain Configuration File Syntax
+
+=head1 SYNOPSIS
+
+ /etc/xen/xldomain
+
+=head1 DESCRIPTION
+
+To create a VM (a domain in Xen terminology, sometimes called a guest)
+with xl requires the provision of a domain config file.  Typically
+these live in `/etc/xen/DOMAIN.cfg` where DOMAIN is the name of the
+domain.
+
+=head1 SYNTAX
+
+A domain config file consists of a series of C<KEY=VALUE> pairs.
+
+Some C<KEY>s are mandatory, others are global options which apply to
+any guest type while others relate only to specific guest types
+(e.g. PV or HVM guests).
+
+A value C<VALUE> is one of:
+
+=over 4
+
+=item B<"STRING">
+
+A string, surrounded by either single or double quotes.
+
+=item B<NUMBER>
+
+A number, in either decimal, octal (using a C<0> prefix) or
+hexadecimal (using an C<0x> prefix).
+
+=item B<BOOLEAN>
+
+A C<NUMBER> interpreted as C<False> (C<0>) or C<True> (any other
+value).
+
+=item B<[ VALUE, VALUE, ... ]>
+
+A list of C<VALUES> of the above types. Lists are homogeneous and are
+not nested.
+
+=back
+
+The semantics of each C<KEY> defines which form of C<VALUE> is required.
+
+=head1 OPTIONS
+
+=head2 Mandatory Configuration Items
+
+The following key is mandatory for any guest type:
+
+=over 4
+
+=item B<name="NAME">
+
+Specifies the name of the domain.  Names of domains existing on a
+single host must be unique.
+
+=back
+
+=head2 Selecting Guest Type
+
+=over 4
+
+=item B<builder="generic">
+
+Specifies that this is to be a PV domain. This is the default.
+
+=item B<builder="hvm">
+
+Specifies that this is to be an HVM domain.  That is, a fully
+virtualised computer with emulated BIOS, disk and network peripherals,
+etc.  The default is a PV domain, suitable for hosting Xen-aware guest
+operating systems.
+
+=back
+
+=head2 Global Options
+
+The following options apply to guests of any type.
+
+=over 4
+
+=item B<uuid="UUID">
+
+Specifies the UUID of the domain.  If not specified, a fresh unique
+UUID will be generated.
+
+=item B<pool="CPUPOOLNAME">
+
+Put the guest's vcpus into the named cpu pool.
+
+=item B<vcpus=N>
+
+Start the guest with N vcpus initially online.
+
+=item B<maxvcpus=M>
+
+Allow the guest to bring up a maximum of M vcpus. At start of day if
+`vcpus=N` is less than `maxvcpus=M` then the first `N` vcpus will be
+created online and the remainder will be offline.
+
+=item B<memory=MBYTES>
+
+Start the guest with MBYTES megabytes of RAM.
+
+=item B<on_poweroff="ACTION">
+
+Specifies what should be done with the domain if it shuts itself down.
+The C<ACTION>s are:
+
+=over 4
+
+=item B<destroy>
+
+destroy the domain
+     
+=item B<restart>
+
+destroy the domain and immediately create a new domain with the same
+configuration
+        
+=item B<rename-restart>
+
+rename the domain which terminated, and thenimmediately create a new
+domain with the same configuration as the original
+
+=item B<preserve>
+
+keep the domain.  It can be examined, and later destroyed with `xl
+destroy`.
+
+=item B<coredump-destroy>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+destroy the domain.
+
+=item B<coredump-restart>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+restart the domain.
+
+=back
+
+The default for C<on_poweroff> is C<destroy>.
+
+=item B<on_reboot="ACTION">
+
+Action to take if the domain shuts down with a reason code requesting
+a reboot.  Default is C<restart>.
+
+=item B<on_watchdog="ACTION">
+
+Action to take if the domain shuts down due to a Xen watchdog timeout.
+Default is C<destroy>.
+
+=item B<on_crash="ACTION">
+
+Action to take if the domain crashes.  Default is C<destroy>.
+
+=item B<seclabel="LABEL">
+
+Assign an XSM security label to this domain.
+
+=back
+
+=head2 Devices
+
+The following options define the paravirtual, emulated and physical
+devices which the guest will contain.
+
+=over 4
+
+=item B<disk=[ "DISK_SPEC_STRING", "DISK_SPEC_STRING", ...]>
+
+Specifies the disks (both emulated disks and Xen virtual block
+devices) which are to be provided to the guest, and what objects on
+the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
+
+=item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
+
+Specifies the networking provision (both emulated network adapters,
+and Xen virtual interfaces) to provided to the guest.  See
+F<docs/misc/xl-network-configuration.markdown>.
+
+=item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
+
+Specifies the paravirtual framebuffer devices which should be supplied
+to the domain.
+
+This options does not control the emulated graphics card presented to
+an HVM guest. See L<Emulated VGA Graphics Device> below for how to
+configure the emulated device.
+
+Each B<VFB_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
+settings, from the following list:
+
+=over 4
+
+=item C<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item C<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item C<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use.  The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item C<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item C<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item C<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is to not enable this mode
+
+=item C<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using C<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item C<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below or consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item C<display=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=item C<authority=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=back
+
+=item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ... ]>
+
+Specifies the host PCI devices to passthrough to this guest. Each B<PCI_SPEC_STRING>
+has the form C<[DDDD:]BB:DD.F[@VSLOT],KEY=VALUE,KEY=VALUE,...> where:
+
+=over 4
+
+=item B<DDDD:BB:DD.F>
+
+identifies the PCI device from the host perspective in domain
+(B<DDDD>), Bus (B<BB>), Device (B<DD>) and Function (B<F>) syntax. This is
+the same scheme as used in the output of C<lspci> for the device in
+question. Note: By default C<lspci> will omit the domain (B<DDDD>) if it
+is zero and it is optional here also. You may specify the function
+(B<F>) as B<*> to indicate all functions.
+
+=item B<@VSLOT>
+
+specifies the virtual device where the guest will see this
+device. This is equivalent to the B<DD> which the guest sees. In a
+guest B<DDDD> and B<BB> are C<0000:00>. XXX how does this really work?
+
+=item B<KEY=VALUE>
+
+Posible B<KEY>s are:
+
+=over 4
+
+=item B<msitranslate=BOOLEAN>
+
+XXX
+
+=item B<power_mgmt=BOOLEAN>
+
+XXX
+
+=back
+
+=back
+
+=back
+
+=head2 Paravirtualised (PV) Guest Specific Options
+
+The following options apply only to Paravirtual guests.
+
+=over 4
+
+=item B<kernel="PATHNAME">
+
+Load the specified file as the kernel image.  Either B<kernel> or
+B<bootloader> must be specified for PV guests.
+
+=item B<ramdisk="PATHNAME">
+
+Load the specified file as the ramdisk.
+
+=item B<bootloader="PROGRAM">
+
+Run C<PROGRAM> to find the kernel image and ramdisk to use.  Normally
+C<PROGRAM> would be C<pygrub>, which is an emulation of
+grub/grub2/syslinux.
+
+=item B<bootloader_args=STRING>
+
+Append B<STRING> (split into words at whitespace) to the arguments to
+the B<bootloader> program.  XXX this should be a list of strings.
+
+=item B<root="STRING">
+
+Append B<root="STRING"> to the kernel command line (Note: it is guest
+specific what meaning this has).
+
+=item B<extra="STRING">
+
+Append B<STRING> to the kernel command line. Note: it is guest
+specific what meaning this has).
+
+=item B<e820_host=BOOLEAN>
+
+Selects whether to expose the host e820 (memory map) to the guest via
+the virtual e820. When this option is false the guest psuedo-physical
+address space consists of a single contiguous RAM region. When this
+option is specified the virtual e820 instead reflects the host e820
+and contains the same PCI holes. The total amount of RAM represented
+by the memory map is always the same, this option configures only how
+it is layed out.
+
+Exposing the host e820 to the guest gives the guest kernel the
+opportunity to set aside the required part of its pseudo-physical
+address space in order to provide address space to map passedthrough
+PCI devices. It is guest Operaring System dependant whether this
+option is required, specifically it is required when using a mainline
+Linux ("pvops") kernel. This option defaults to true if any PCI
+passthrough devices are configued and false otherwise. If you do not
+configure any passthrough devices at domain creation time but expect
+to hotplug devices later then you should set this option. Conversely
+if your particular guest kernel does not require this behaviour then
+it is safe to allow this to be enabled but you may wish to disable it
+anyway.
+
+=back
+
+=head2 Fully-virtualised (HVM) Guest Specific Options
+
+The following options apply only to HVM guests.
+
+=head3 Boot Device
+
+=over 4
+
+=item B<boot=[c|d|n]>
+
+Selects the emulated virtual device to boot from. Options are hard
+disk (B<c>), cd-rom (B<d>) or network/PXE (B<n>). Multiple options can be
+given and will be attempted in the order they are given. e.g. to boot
+from cd-rom but fallback to the hard disk you can give B<dc>. The
+default is B<cd>.
+
+=back
+
+=head3 Paging
+
+The following options control the mechanisms used to virtualise guest
+memory.  The defaults are selected to give the best results for the
+common case and so you should normally leave these options
+unspecified.
+
+=over 4
+
+=item B<hap=BOOLEAN>
+
+Turns "hardware assisted paging" (the use of the hardware nested page
+table feature) on or off.  This feature is called EPT (Extended Page
+Tables) by Intel and NPT (Nested Page Tables) or RVI (Rapid
+Virtualisation Indexing) by AMD.  Affects HVM guests only.  If turned
+off, Xen will run the guest in "shadow page table" mode where the
+guest's page table updates and/or TLB flushes etc. will be emulated.
+Use of HAP is the default when available.
+
+=item B<oos=BOOLEAN>
+
+Turns "out of sync pagetables" on or off.  When running in shadow page
+table mode, the guest's page table updates may be deferred as
+specified in the Intel/AMD architecture manuals.  However this may
+expose unexpected bugs in the guest, or find bugs in Xen, so it is
+possible to disable this feature.  Use of out of sync page tables,
+when Xen thinks it appropriate, is the default.
+
+=item B<shadow_memory=MBYTES>
+
+Number of megabytes to set aside for shadowing guest pagetable pages
+(effectively acting as a cache of translated pages) or to use for HAP
+state. By default this is 1MB per guest vcpu plus 8KB per MB of guest
+RAM. You should not normally need to adjust this value. However if you
+are not using hardware assisted paging (i.e. you are using shadow
+mode) and your guest workload consists of a a very large number of
+similar processes then increasing this value may improve performance.
+
+=back
+
+=head3 Processor and Platform Features
+
+The following options allow various processor and platform level
+features to be hidden or exposed from the guest's point of view. This
+can be useful when running older guest Operating Systems which may
+misbehave when faced with more modern features. In general you should
+accept the defaults for these options wherever possible.
+
+=over 4
+
+=item B<pae=BOOLEAN>
+
+Hide or expose the IA32 Physical Address Extensions. These extensions
+make it possible for a 32 bit guest Operating System to access more
+than 4GB of RAM. Enabling PAE also enabled other features such as
+NX. PAE is required if you wish to run a 64-bit guest Operating
+System. In general you should leave this enabled and allow the guest
+Operating System to choose whether or not to use PAE. (X86 only)
+
+=item B<acpi=BOOLEAN>
+
+Expose ACPI (Advanced Configuration and Power Interface) tables from
+the virtual firmware to the guest Operating System. ACPI is required
+by most modern guest Operating Systems. This option is enabled by
+default and usually you should omit it. However it may be necessary to
+disable ACPI for compatibility with some guest Operating Systems.
+
+=item B<apic=BOOLEAN>
+
+Include information regarding APIC (Advanced Programmable Interrupt
+Controller) in the firmware/BIOS tables on a single processor
+guest. This causes the MP (multiprocessor) and PIR (PCI Interrupt
+Routing) tables to be exported by the virtual firmware. This option
+has no effect on a guest with multiple virtual CPUS as they must
+always include these tables. This option is enabled by default and you
+should usually omit it but it may be necessary to disable these
+firmware tables when using certain older guest Operating
+Systems. These tables have been superceded by newer constructs within
+the ACPI tables. (X86 only)
+
+=item B<nx=BOOLEAN>
+
+Hides or exposes the No-eXecute capability. This allows a guest
+Operating system to map pages such that they cannot be executed which
+can enhance security. This options requires that PAE also be
+enabled. (X86 only)
+
+=item B<hpet=BOOLEAN>
+
+Enables or disables HPET (High Precision Event Timer). This option is
+enabled by default and you should usually omit it. It may be necessary
+to disable the HPET in order to improve compatibility with guest
+Operating Systems (X86 only)
+
+=item B<nestedhvm=BOOLEAN>
+
+Enable or disables guest access to hardware virtualisation features,
+e.g. it allows a guest Operating System to also function as a
+hypervisor. This option is disabled by default. You may want this
+option if you want to run another hypervisor (including another copy
+of Xen) within a Xen guest or to support a guest Operating System
+which uses hardware virtualisation extensions (e.g. Windows XP
+compatibility mode on more modern Windows OS).
+
+=back 
+
+=head3 Guest Virtual Time Controls
+
+=over 4
+
+=item B<tsc_mode="MODE">
+
+Specifies how the TSC (Time Stamp Counter) should be provided to the
+guest.  XXX ???
+
+=back
+
+=head3 Support for Paravirtualisation of HVM Guests
+
+The following options allow Paravirtualised features (such as devices)
+to be exposed to the guest Operating System in an HVM guest.
+Utilising these features requires specific guest support but when
+available they will result in improved performance.
+
+=over 4
+
+=item B<xen_platform_pci=BOOLEAN>
+
+Enable or disable the Xen platform PCI device.  The presence of this
+virtual device enables a guest Operating System (subject to the
+availability of suitable drivers) to make use of paravirtualisation
+features such as disk and network devices etc. Enabling these drivers
+improves performance and is strongly recommended when available. PV
+drivers are available for various Operating Systems including HVM
+Linux L<http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers> and Microsoft
+Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
+
+=item B<viridian=BOOLEAN>
+
+Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
+compatible enlightenments to the guest.  These can improve performance
+of Microsoft Windows guests (XXX which versions of Windows benefit?)
+
+=back
+
+=head3 Emulated VGA Graphics Device
+
+The following options control the features of the emulated graphics
+device.  Many of these options behave similarly to the equivalent key
+in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
+(see above).
+
+=over 4
+
+=item B<videoram=MBYTES>
+
+Sets the amount of RAM which the emulated video card will contain,
+which in turn limits the resolutions and bit depths which will be
+available. This option is only available when using the B<stdvga>
+option (see below). The default is 8MB which is sufficient for
+e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
+amount of video ram is fixed at 4MB which is sufficient for 1024x768
+at 32 bpp.
+
+=item B<stdvga=BOOLEAN>
+
+Select a standard VGA card with VBE (VESA BIOS Extensions) as the
+emulated graphics device. The default is false which means to emulate
+a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
+later (e.g. Windows XP onwards) then you should enable this.
+
+=item B<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item B<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item B<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use. The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item B<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item B<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item B<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below of consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item B<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is not to enable this mode.
+
+=item B<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using B<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item B<nographic=BOOLEAN>
+
+Enable or disable the virtual graphics device.  The default is to
+provide a VGA graphics device but this option can be used to disable
+it.
+
+=back
+
+=head3 Spice Graphics Support
+
+The following options control the features of SPICE.
+
+=over 4
+
+=item B<spice=BOOLEAN>
+
+Allow access to the display via the SPICE protocol.  This enables the
+other SPICE-related settings.
+
+=item B<spicehost="ADDRESS">
+
+Specify the interface address to listen on if given, otherwise any
+interface.
+
+=item B<spiceport=NUMBER>
+
+Specify the port to listen on by the SPICE server if the SPICE is
+enabled.
+
+=item B<spicetls_port=NUMBER>
+
+Specify the secure port to listen on by the SPICE server if the SPICE
+is enabled. At least one of the spiceport or spicetls_port must be
+given if SPICE is enabled.  NB. the options depending on spicetls_port
+have not been supported.
+
+=item B<spicedisable_ticketing=BOOLEAN>
+
+Enable client connection without password. The default is false. If
+it's false (set to 0), spicepasswd must be set.
+
+=item B<spicepasswd="PASSWORD">
+
+Specify the ticket password which is used by a client for connection.
+
+=item B<spiceagent_mouse=BOOLEAN>
+
+Whether SPICE agent is used for client mouse mode. The default is true
+(turn on)
+
+=back
+
+=head3 Miscellaneous Emulated Hardware
+
+=over 4
+
+=item B<serial=DEVICE>
+
+Redirect the virtual serial port to B<DEVICE>. Please see the
+B<-serial> option in the L<qemu(1)> manpage for details of the valid
+B<DEVICE> options. Default is B<vc> when in graphical mode and
+B<stdio> if B<nographics=1> is used.
+
+=item B<soundhw=DEVICE>
+
+Select the virtual sound card to expose to the guest. The valid
+devices are defined by the device model configuration, please see the
+L<qemu(1)> manpage for details. The default is not to export any sound
+device.
+
+=item B<usb=BOOLEAN>
+
+Enables or disables a USB bus in the guest.
+
+=item B<usbdevice=DEVICE>
+
+Adds B<DEVICE> to the USB bus. The USB bus must also be enabled using
+B<usb=1>. The most common use for this option is B<usbdevice=tablet>
+which adds pointer device using absolute coordinates. Such devices
+function better than relative coordinate devices (such as a standard
+mouse) since many methods of exporting guest graphics (such as VNC)
+work better in this mode. Note that this is independent of the actual
+pointer device you are using on the host/client side. XXX should/could
+be a list of devices.
+
+=back
+
+=head3 Unclassified HVM Specific Options
+
+These HVM specific options have not yet been documented or
+classified. They almost certainly belong in a more appropriate
+section.
+
+=over 4
+
+=item B<vpt_align=BOOLEAN>
+
+Align the Virtual Platform Timer ??? XXX Reduces interrupts?
+
+=item B<timer_mode=NUMBER>
+
+Set mode for Virtual Timers XXX ??? should be an enum of particular
+values. See C<HVM_PARAM_TIMER_MODE> in
+F<xen/include/public/hvm/params.h>.
+
+=back
+
+=head2 Device-Model Options
+
+The following options control the selection of the device-model.  This
+is the component which provides emulation of the virtual devices to an
+HVM guest.  For a PV guest a device-model is sometimes used to provide
+backends for certain PV devices (most usually a virtual framebuffer
+device).
+
+=over 4
+
+=item B<device_model_version="DEVICE-MODEL">
+
+Selects which variant of the device-model should be used for this
+guest. Valid values are:
+
+=over 4
+
+=item B<qemu-xen-traditional>
+
+Use the device-model based upon the historical Xen fork of Qemu.  This
+device-model is currently the default.
+
+=item B<qemu-xen>
+
+use the device-model merged into the upstream Qemu project.  This
+device-model will become the default in a future version of Xen.
+
+=back
+
+It is recommended to accept the default value for new guests.  If
+you have existing guests then, depeending on the nature of the guest
+Operating System, you may wish to force them to use the device
+model which they were installed with.
+
+=item B<device_model_override="PATH">
+
+Override the path to the binary to be used as the device-model. The
+binary provided here MUST be consistent with the
+`device_model_version` which you have specified. You should not
+normally need to specify this option.
+
+=item B<device_model_stubdomain_override=BOOLEAN>
+
+Override the use of stubdomain based device-model.  Normally this will
+be automatically selected based upon the other features and options
+you have selected.
+
+=item B<device_model_args=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command
+line. Each element in the list is passed as an option to the
+device-model.
+
+=item B<device_model_args_pv=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+a PV device model only. Each element in the list is passed as an
+option to the device-model.
+
+=item B<device_model_args_hvm=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+an HVM device model only. Each element in the list is passed as an
+option to the device-model.
+
+=back
+
+=head2 Unclassified General Options
+
+These have not yet been fully documented or classified. They almost
+certainly belong in a more appropriate section.
+
+=over 4
+
+=item B<gfx_passthrough=BOOLEAN>
+
+Enable graphics device PCI passthrough. XXX which device is passed through ?
+
+=item B<nomigrate=BOOLEAN>
+
+Disable migration of this domain.  This enables certain other features
+which are incompatible with migration (currently certain TSC modes XXX
+?).
+
+=item B<pci_msitranslate=BOOLEAN>
+
+XXX
+
+=item B<pci_power_mgmt=BOOLEAN>
+
+XXX
+
+=item B<cpuid=XXX>
+
+XXX
+
+=back
+
+=head2 Keymaps
+
+The keymaps available are defined by the device-model which you are
+using. Commonly this includes:
+
+        ar  de-ch  es  fo     fr-ca  hu  ja  mk     no  pt-br  sv
+        da  en-gb  et  fr     fr-ch  is  lt  nl     pl  ru     th
+        de  en-us  fi  fr-be  hr     it  lv  nl-be  pt  sl     tr
+
+The default is B<en-us>.
+
+See L<qemu(1)> for more information.
+
+=head1 SEE ALSO
+
+=over 4
+
+=item L<xl(1)>
+
+=item F<xl-disk-configuration>
+
+=item F<xl-network-configuration>
+
+=back
+
+=head1 FILES
+
+F</etc/xen/NAME.cfg>
+F</var/xen/dump/NAME>
+F<docs/misc/tscmode.txt>
+
+=head1 BUGS
+
+This document is a work in progress and contains items which require
+further documentation and which are generally incomplete (marked with
+XXX).  However all options are included here whether or not they are
+fully documented.
+
+Patches to improve incomplete items (or any other item) would be
+greatfully received on the xen-devel@lists.xensource.com mailing
+list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
+information on how to submit a patch to Xen.
+
diff -r f3fc909a083d -r c88ff1ac2417 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Nov 17 14:34:11 2011 +0000
+++ b/docs/man/xl.pod.1	Thu Nov 17 14:35:24 2011 +0000
@@ -54,7 +54,7 @@ previously, most commands take I<domain-
 
 =item B<create> [I<OPTIONS>] I<configfile>
 
-The create subcommand requires a config file: see L<xldomain.cfg> for
+The create subcommand requires a config file: see L<xl.cfg(5)> for
 full details of that file format and possible options.
 
 I<configfile> can either be an absolute path to a file, or a relative
@@ -232,7 +232,7 @@ FIXME: Why would you ever see this state
 
 The domain has crashed, which is always a violent ending.  Usually
 this state can only occur if the domain has been configured not to
-restart on crash.  See L<xldomain.cfg> for more info.
+restart on crash.  See L<xl.cfg(5)> for more info.
 
 =item B<d - dying>
 
@@ -319,8 +319,8 @@ executed the reboot action, which may be
 domain actually reboots.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_reboot> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_reboot> parameter of the domain configuration file when the
+domain was created.
 
 =item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile>
 
@@ -372,8 +372,8 @@ services must be shutdown in the domain.
 immediately after signally the domain unless that B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_shutdown> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_shutdown> parameter of the domain configuration file when the
+domain was created.
 
 B<OPTIONS>
 
@@ -699,7 +699,7 @@ The domain id of the guest domain that t
 =item I<disc-spec-component>
 
 A disc specification in the same format used for the B<disk> variable in
-the domain config file. See L<xldomain.cfg>.
+the domain config file. See F<xl-disk-configuration>.
 
 =back
 
@@ -733,9 +733,9 @@ How the device should be presented to th
 
 =item I<be-dev>
 
-the device in the backend domain (usually domain 0) to be exported; it can be a
-path to a file (file://path/to/file.iso). See B<disk> in L<xldomain.cfg> for the
-details.
+the device in the backend domain (usually domain 0) to be exported; it
+can be a path to a file (file://path/to/file.iso). See B<disk> in
+L<xl.cfg(5)> for the details.
 
 =back
 
@@ -754,7 +754,7 @@ I<VirtualDevice> is the cdrom device in 
 
 Creates a new network device in the domain specified by I<domain-id>.
 I<network-device> describes the device to attach, using the same format as the
-B<vif> string in the domain config file. See L<xldomain.cfg> for the
+B<vif> string in the domain config file. See L<xl.cfg(5)> for the
 description.
 
 =item B<network-detach> I<domain-id> I<devid|mac>
@@ -795,7 +795,7 @@ List pass-through pci devices for a doma
 
 =head1 SEE ALSO
 
-B<xldomain.cfg>(5), B<xlcpupool.cfg>(5), B<xentop>(1)
+L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
 
 =head1 AUTHOR
 
diff -r f3fc909a083d -r c88ff1ac2417 tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Thu Nov 17 14:34:11 2011 +0000
+++ b/tools/examples/xlexample.hvm	Thu Nov 17 14:35:24 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for an
-# HVM guest. For a more complete guide see <XXX Document TBD>
+# HVM guest. For a more complete guide see xl.cfg(5)
 
 # This configures an HVM rather than PV guest
 builder = "hvm"
diff -r f3fc909a083d -r c88ff1ac2417 tools/examples/xlexample.pvlinux
--- a/tools/examples/xlexample.pvlinux	Thu Nov 17 14:34:11 2011 +0000
+++ b/tools/examples/xlexample.pvlinux	Thu Nov 17 14:35:24 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for a
-# Paravirtualised Linux guest. For a more complete guide see <XXX Document TBD>
+# Paravirtualised Linux guest. For a more complete guide see xl.cfg(5)
 
 # Guest name
 name = "example.pvlinux"

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:34:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:34:39 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR3z5-000253-AR
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:34:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3ym-00018A-Vy; Thu, 17 Nov 2011 07:34:21 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TW-0002Qp-DY
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:33 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321542115!3938195!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14064 invoked from network); 17 Nov 2011 15:01:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990614"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNE026208;	Thu, 17 Nov 2011 07:01:52 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: c88ff1ac24170a7d2a3c8824735ef9311eb95fe0
Message-ID: <c88ff1ac24170a7d2a3c.1321542111@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 05 of 17] docs: add a document describing the xl
 cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540524 0
# Node ID c88ff1ac24170a7d2a3c8824735ef9311eb95fe0
# Parent  f3fc909a083ddcea05cd0c9ab51a7241e573f6a6
docs: add a document describing the xl cfg file syntax

Based on an initial version by Ian Jackson.

I believe that all keys are now present in the document although there are are
various omissions in the actual documentation of them. Hopefully however this
covers the majority of the most interesting keys.

Spice section:
Signed-off-by: Zhou Peng <zhoupeng@nfs.iscas.ac.cn>

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

diff -r f3fc909a083d -r c88ff1ac2417 docs/man/xl.cfg.pod.5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/man/xl.cfg.pod.5	Thu Nov 17 14:35:24 2011 +0000
@@ -0,0 +1,844 @@
+=head1 NAME
+
+xl.cfg - XL Domain Configuration File Syntax
+
+=head1 SYNOPSIS
+
+ /etc/xen/xldomain
+
+=head1 DESCRIPTION
+
+To create a VM (a domain in Xen terminology, sometimes called a guest)
+with xl requires the provision of a domain config file.  Typically
+these live in `/etc/xen/DOMAIN.cfg` where DOMAIN is the name of the
+domain.
+
+=head1 SYNTAX
+
+A domain config file consists of a series of C<KEY=VALUE> pairs.
+
+Some C<KEY>s are mandatory, others are global options which apply to
+any guest type while others relate only to specific guest types
+(e.g. PV or HVM guests).
+
+A value C<VALUE> is one of:
+
+=over 4
+
+=item B<"STRING">
+
+A string, surrounded by either single or double quotes.
+
+=item B<NUMBER>
+
+A number, in either decimal, octal (using a C<0> prefix) or
+hexadecimal (using an C<0x> prefix).
+
+=item B<BOOLEAN>
+
+A C<NUMBER> interpreted as C<False> (C<0>) or C<True> (any other
+value).
+
+=item B<[ VALUE, VALUE, ... ]>
+
+A list of C<VALUES> of the above types. Lists are homogeneous and are
+not nested.
+
+=back
+
+The semantics of each C<KEY> defines which form of C<VALUE> is required.
+
+=head1 OPTIONS
+
+=head2 Mandatory Configuration Items
+
+The following key is mandatory for any guest type:
+
+=over 4
+
+=item B<name="NAME">
+
+Specifies the name of the domain.  Names of domains existing on a
+single host must be unique.
+
+=back
+
+=head2 Selecting Guest Type
+
+=over 4
+
+=item B<builder="generic">
+
+Specifies that this is to be a PV domain. This is the default.
+
+=item B<builder="hvm">
+
+Specifies that this is to be an HVM domain.  That is, a fully
+virtualised computer with emulated BIOS, disk and network peripherals,
+etc.  The default is a PV domain, suitable for hosting Xen-aware guest
+operating systems.
+
+=back
+
+=head2 Global Options
+
+The following options apply to guests of any type.
+
+=over 4
+
+=item B<uuid="UUID">
+
+Specifies the UUID of the domain.  If not specified, a fresh unique
+UUID will be generated.
+
+=item B<pool="CPUPOOLNAME">
+
+Put the guest's vcpus into the named cpu pool.
+
+=item B<vcpus=N>
+
+Start the guest with N vcpus initially online.
+
+=item B<maxvcpus=M>
+
+Allow the guest to bring up a maximum of M vcpus. At start of day if
+`vcpus=N` is less than `maxvcpus=M` then the first `N` vcpus will be
+created online and the remainder will be offline.
+
+=item B<memory=MBYTES>
+
+Start the guest with MBYTES megabytes of RAM.
+
+=item B<on_poweroff="ACTION">
+
+Specifies what should be done with the domain if it shuts itself down.
+The C<ACTION>s are:
+
+=over 4
+
+=item B<destroy>
+
+destroy the domain
+     
+=item B<restart>
+
+destroy the domain and immediately create a new domain with the same
+configuration
+        
+=item B<rename-restart>
+
+rename the domain which terminated, and thenimmediately create a new
+domain with the same configuration as the original
+
+=item B<preserve>
+
+keep the domain.  It can be examined, and later destroyed with `xl
+destroy`.
+
+=item B<coredump-destroy>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+destroy the domain.
+
+=item B<coredump-restart>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+restart the domain.
+
+=back
+
+The default for C<on_poweroff> is C<destroy>.
+
+=item B<on_reboot="ACTION">
+
+Action to take if the domain shuts down with a reason code requesting
+a reboot.  Default is C<restart>.
+
+=item B<on_watchdog="ACTION">
+
+Action to take if the domain shuts down due to a Xen watchdog timeout.
+Default is C<destroy>.
+
+=item B<on_crash="ACTION">
+
+Action to take if the domain crashes.  Default is C<destroy>.
+
+=item B<seclabel="LABEL">
+
+Assign an XSM security label to this domain.
+
+=back
+
+=head2 Devices
+
+The following options define the paravirtual, emulated and physical
+devices which the guest will contain.
+
+=over 4
+
+=item B<disk=[ "DISK_SPEC_STRING", "DISK_SPEC_STRING", ...]>
+
+Specifies the disks (both emulated disks and Xen virtual block
+devices) which are to be provided to the guest, and what objects on
+the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
+
+=item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
+
+Specifies the networking provision (both emulated network adapters,
+and Xen virtual interfaces) to provided to the guest.  See
+F<docs/misc/xl-network-configuration.markdown>.
+
+=item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
+
+Specifies the paravirtual framebuffer devices which should be supplied
+to the domain.
+
+This options does not control the emulated graphics card presented to
+an HVM guest. See L<Emulated VGA Graphics Device> below for how to
+configure the emulated device.
+
+Each B<VFB_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
+settings, from the following list:
+
+=over 4
+
+=item C<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item C<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item C<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use.  The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item C<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item C<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item C<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is to not enable this mode
+
+=item C<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using C<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item C<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below or consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item C<display=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=item C<authority=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=back
+
+=item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ... ]>
+
+Specifies the host PCI devices to passthrough to this guest. Each B<PCI_SPEC_STRING>
+has the form C<[DDDD:]BB:DD.F[@VSLOT],KEY=VALUE,KEY=VALUE,...> where:
+
+=over 4
+
+=item B<DDDD:BB:DD.F>
+
+identifies the PCI device from the host perspective in domain
+(B<DDDD>), Bus (B<BB>), Device (B<DD>) and Function (B<F>) syntax. This is
+the same scheme as used in the output of C<lspci> for the device in
+question. Note: By default C<lspci> will omit the domain (B<DDDD>) if it
+is zero and it is optional here also. You may specify the function
+(B<F>) as B<*> to indicate all functions.
+
+=item B<@VSLOT>
+
+specifies the virtual device where the guest will see this
+device. This is equivalent to the B<DD> which the guest sees. In a
+guest B<DDDD> and B<BB> are C<0000:00>. XXX how does this really work?
+
+=item B<KEY=VALUE>
+
+Posible B<KEY>s are:
+
+=over 4
+
+=item B<msitranslate=BOOLEAN>
+
+XXX
+
+=item B<power_mgmt=BOOLEAN>
+
+XXX
+
+=back
+
+=back
+
+=back
+
+=head2 Paravirtualised (PV) Guest Specific Options
+
+The following options apply only to Paravirtual guests.
+
+=over 4
+
+=item B<kernel="PATHNAME">
+
+Load the specified file as the kernel image.  Either B<kernel> or
+B<bootloader> must be specified for PV guests.
+
+=item B<ramdisk="PATHNAME">
+
+Load the specified file as the ramdisk.
+
+=item B<bootloader="PROGRAM">
+
+Run C<PROGRAM> to find the kernel image and ramdisk to use.  Normally
+C<PROGRAM> would be C<pygrub>, which is an emulation of
+grub/grub2/syslinux.
+
+=item B<bootloader_args=STRING>
+
+Append B<STRING> (split into words at whitespace) to the arguments to
+the B<bootloader> program.  XXX this should be a list of strings.
+
+=item B<root="STRING">
+
+Append B<root="STRING"> to the kernel command line (Note: it is guest
+specific what meaning this has).
+
+=item B<extra="STRING">
+
+Append B<STRING> to the kernel command line. Note: it is guest
+specific what meaning this has).
+
+=item B<e820_host=BOOLEAN>
+
+Selects whether to expose the host e820 (memory map) to the guest via
+the virtual e820. When this option is false the guest psuedo-physical
+address space consists of a single contiguous RAM region. When this
+option is specified the virtual e820 instead reflects the host e820
+and contains the same PCI holes. The total amount of RAM represented
+by the memory map is always the same, this option configures only how
+it is layed out.
+
+Exposing the host e820 to the guest gives the guest kernel the
+opportunity to set aside the required part of its pseudo-physical
+address space in order to provide address space to map passedthrough
+PCI devices. It is guest Operaring System dependant whether this
+option is required, specifically it is required when using a mainline
+Linux ("pvops") kernel. This option defaults to true if any PCI
+passthrough devices are configued and false otherwise. If you do not
+configure any passthrough devices at domain creation time but expect
+to hotplug devices later then you should set this option. Conversely
+if your particular guest kernel does not require this behaviour then
+it is safe to allow this to be enabled but you may wish to disable it
+anyway.
+
+=back
+
+=head2 Fully-virtualised (HVM) Guest Specific Options
+
+The following options apply only to HVM guests.
+
+=head3 Boot Device
+
+=over 4
+
+=item B<boot=[c|d|n]>
+
+Selects the emulated virtual device to boot from. Options are hard
+disk (B<c>), cd-rom (B<d>) or network/PXE (B<n>). Multiple options can be
+given and will be attempted in the order they are given. e.g. to boot
+from cd-rom but fallback to the hard disk you can give B<dc>. The
+default is B<cd>.
+
+=back
+
+=head3 Paging
+
+The following options control the mechanisms used to virtualise guest
+memory.  The defaults are selected to give the best results for the
+common case and so you should normally leave these options
+unspecified.
+
+=over 4
+
+=item B<hap=BOOLEAN>
+
+Turns "hardware assisted paging" (the use of the hardware nested page
+table feature) on or off.  This feature is called EPT (Extended Page
+Tables) by Intel and NPT (Nested Page Tables) or RVI (Rapid
+Virtualisation Indexing) by AMD.  Affects HVM guests only.  If turned
+off, Xen will run the guest in "shadow page table" mode where the
+guest's page table updates and/or TLB flushes etc. will be emulated.
+Use of HAP is the default when available.
+
+=item B<oos=BOOLEAN>
+
+Turns "out of sync pagetables" on or off.  When running in shadow page
+table mode, the guest's page table updates may be deferred as
+specified in the Intel/AMD architecture manuals.  However this may
+expose unexpected bugs in the guest, or find bugs in Xen, so it is
+possible to disable this feature.  Use of out of sync page tables,
+when Xen thinks it appropriate, is the default.
+
+=item B<shadow_memory=MBYTES>
+
+Number of megabytes to set aside for shadowing guest pagetable pages
+(effectively acting as a cache of translated pages) or to use for HAP
+state. By default this is 1MB per guest vcpu plus 8KB per MB of guest
+RAM. You should not normally need to adjust this value. However if you
+are not using hardware assisted paging (i.e. you are using shadow
+mode) and your guest workload consists of a a very large number of
+similar processes then increasing this value may improve performance.
+
+=back
+
+=head3 Processor and Platform Features
+
+The following options allow various processor and platform level
+features to be hidden or exposed from the guest's point of view. This
+can be useful when running older guest Operating Systems which may
+misbehave when faced with more modern features. In general you should
+accept the defaults for these options wherever possible.
+
+=over 4
+
+=item B<pae=BOOLEAN>
+
+Hide or expose the IA32 Physical Address Extensions. These extensions
+make it possible for a 32 bit guest Operating System to access more
+than 4GB of RAM. Enabling PAE also enabled other features such as
+NX. PAE is required if you wish to run a 64-bit guest Operating
+System. In general you should leave this enabled and allow the guest
+Operating System to choose whether or not to use PAE. (X86 only)
+
+=item B<acpi=BOOLEAN>
+
+Expose ACPI (Advanced Configuration and Power Interface) tables from
+the virtual firmware to the guest Operating System. ACPI is required
+by most modern guest Operating Systems. This option is enabled by
+default and usually you should omit it. However it may be necessary to
+disable ACPI for compatibility with some guest Operating Systems.
+
+=item B<apic=BOOLEAN>
+
+Include information regarding APIC (Advanced Programmable Interrupt
+Controller) in the firmware/BIOS tables on a single processor
+guest. This causes the MP (multiprocessor) and PIR (PCI Interrupt
+Routing) tables to be exported by the virtual firmware. This option
+has no effect on a guest with multiple virtual CPUS as they must
+always include these tables. This option is enabled by default and you
+should usually omit it but it may be necessary to disable these
+firmware tables when using certain older guest Operating
+Systems. These tables have been superceded by newer constructs within
+the ACPI tables. (X86 only)
+
+=item B<nx=BOOLEAN>
+
+Hides or exposes the No-eXecute capability. This allows a guest
+Operating system to map pages such that they cannot be executed which
+can enhance security. This options requires that PAE also be
+enabled. (X86 only)
+
+=item B<hpet=BOOLEAN>
+
+Enables or disables HPET (High Precision Event Timer). This option is
+enabled by default and you should usually omit it. It may be necessary
+to disable the HPET in order to improve compatibility with guest
+Operating Systems (X86 only)
+
+=item B<nestedhvm=BOOLEAN>
+
+Enable or disables guest access to hardware virtualisation features,
+e.g. it allows a guest Operating System to also function as a
+hypervisor. This option is disabled by default. You may want this
+option if you want to run another hypervisor (including another copy
+of Xen) within a Xen guest or to support a guest Operating System
+which uses hardware virtualisation extensions (e.g. Windows XP
+compatibility mode on more modern Windows OS).
+
+=back 
+
+=head3 Guest Virtual Time Controls
+
+=over 4
+
+=item B<tsc_mode="MODE">
+
+Specifies how the TSC (Time Stamp Counter) should be provided to the
+guest.  XXX ???
+
+=back
+
+=head3 Support for Paravirtualisation of HVM Guests
+
+The following options allow Paravirtualised features (such as devices)
+to be exposed to the guest Operating System in an HVM guest.
+Utilising these features requires specific guest support but when
+available they will result in improved performance.
+
+=over 4
+
+=item B<xen_platform_pci=BOOLEAN>
+
+Enable or disable the Xen platform PCI device.  The presence of this
+virtual device enables a guest Operating System (subject to the
+availability of suitable drivers) to make use of paravirtualisation
+features such as disk and network devices etc. Enabling these drivers
+improves performance and is strongly recommended when available. PV
+drivers are available for various Operating Systems including HVM
+Linux L<http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers> and Microsoft
+Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
+
+=item B<viridian=BOOLEAN>
+
+Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
+compatible enlightenments to the guest.  These can improve performance
+of Microsoft Windows guests (XXX which versions of Windows benefit?)
+
+=back
+
+=head3 Emulated VGA Graphics Device
+
+The following options control the features of the emulated graphics
+device.  Many of these options behave similarly to the equivalent key
+in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
+(see above).
+
+=over 4
+
+=item B<videoram=MBYTES>
+
+Sets the amount of RAM which the emulated video card will contain,
+which in turn limits the resolutions and bit depths which will be
+available. This option is only available when using the B<stdvga>
+option (see below). The default is 8MB which is sufficient for
+e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
+amount of video ram is fixed at 4MB which is sufficient for 1024x768
+at 32 bpp.
+
+=item B<stdvga=BOOLEAN>
+
+Select a standard VGA card with VBE (VESA BIOS Extensions) as the
+emulated graphics device. The default is false which means to emulate
+a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
+later (e.g. Windows XP onwards) then you should enable this.
+
+=item B<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item B<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item B<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use. The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item B<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item B<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item B<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below of consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item B<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is not to enable this mode.
+
+=item B<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using B<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item B<nographic=BOOLEAN>
+
+Enable or disable the virtual graphics device.  The default is to
+provide a VGA graphics device but this option can be used to disable
+it.
+
+=back
+
+=head3 Spice Graphics Support
+
+The following options control the features of SPICE.
+
+=over 4
+
+=item B<spice=BOOLEAN>
+
+Allow access to the display via the SPICE protocol.  This enables the
+other SPICE-related settings.
+
+=item B<spicehost="ADDRESS">
+
+Specify the interface address to listen on if given, otherwise any
+interface.
+
+=item B<spiceport=NUMBER>
+
+Specify the port to listen on by the SPICE server if the SPICE is
+enabled.
+
+=item B<spicetls_port=NUMBER>
+
+Specify the secure port to listen on by the SPICE server if the SPICE
+is enabled. At least one of the spiceport or spicetls_port must be
+given if SPICE is enabled.  NB. the options depending on spicetls_port
+have not been supported.
+
+=item B<spicedisable_ticketing=BOOLEAN>
+
+Enable client connection without password. The default is false. If
+it's false (set to 0), spicepasswd must be set.
+
+=item B<spicepasswd="PASSWORD">
+
+Specify the ticket password which is used by a client for connection.
+
+=item B<spiceagent_mouse=BOOLEAN>
+
+Whether SPICE agent is used for client mouse mode. The default is true
+(turn on)
+
+=back
+
+=head3 Miscellaneous Emulated Hardware
+
+=over 4
+
+=item B<serial=DEVICE>
+
+Redirect the virtual serial port to B<DEVICE>. Please see the
+B<-serial> option in the L<qemu(1)> manpage for details of the valid
+B<DEVICE> options. Default is B<vc> when in graphical mode and
+B<stdio> if B<nographics=1> is used.
+
+=item B<soundhw=DEVICE>
+
+Select the virtual sound card to expose to the guest. The valid
+devices are defined by the device model configuration, please see the
+L<qemu(1)> manpage for details. The default is not to export any sound
+device.
+
+=item B<usb=BOOLEAN>
+
+Enables or disables a USB bus in the guest.
+
+=item B<usbdevice=DEVICE>
+
+Adds B<DEVICE> to the USB bus. The USB bus must also be enabled using
+B<usb=1>. The most common use for this option is B<usbdevice=tablet>
+which adds pointer device using absolute coordinates. Such devices
+function better than relative coordinate devices (such as a standard
+mouse) since many methods of exporting guest graphics (such as VNC)
+work better in this mode. Note that this is independent of the actual
+pointer device you are using on the host/client side. XXX should/could
+be a list of devices.
+
+=back
+
+=head3 Unclassified HVM Specific Options
+
+These HVM specific options have not yet been documented or
+classified. They almost certainly belong in a more appropriate
+section.
+
+=over 4
+
+=item B<vpt_align=BOOLEAN>
+
+Align the Virtual Platform Timer ??? XXX Reduces interrupts?
+
+=item B<timer_mode=NUMBER>
+
+Set mode for Virtual Timers XXX ??? should be an enum of particular
+values. See C<HVM_PARAM_TIMER_MODE> in
+F<xen/include/public/hvm/params.h>.
+
+=back
+
+=head2 Device-Model Options
+
+The following options control the selection of the device-model.  This
+is the component which provides emulation of the virtual devices to an
+HVM guest.  For a PV guest a device-model is sometimes used to provide
+backends for certain PV devices (most usually a virtual framebuffer
+device).
+
+=over 4
+
+=item B<device_model_version="DEVICE-MODEL">
+
+Selects which variant of the device-model should be used for this
+guest. Valid values are:
+
+=over 4
+
+=item B<qemu-xen-traditional>
+
+Use the device-model based upon the historical Xen fork of Qemu.  This
+device-model is currently the default.
+
+=item B<qemu-xen>
+
+use the device-model merged into the upstream Qemu project.  This
+device-model will become the default in a future version of Xen.
+
+=back
+
+It is recommended to accept the default value for new guests.  If
+you have existing guests then, depeending on the nature of the guest
+Operating System, you may wish to force them to use the device
+model which they were installed with.
+
+=item B<device_model_override="PATH">
+
+Override the path to the binary to be used as the device-model. The
+binary provided here MUST be consistent with the
+`device_model_version` which you have specified. You should not
+normally need to specify this option.
+
+=item B<device_model_stubdomain_override=BOOLEAN>
+
+Override the use of stubdomain based device-model.  Normally this will
+be automatically selected based upon the other features and options
+you have selected.
+
+=item B<device_model_args=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command
+line. Each element in the list is passed as an option to the
+device-model.
+
+=item B<device_model_args_pv=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+a PV device model only. Each element in the list is passed as an
+option to the device-model.
+
+=item B<device_model_args_hvm=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+an HVM device model only. Each element in the list is passed as an
+option to the device-model.
+
+=back
+
+=head2 Unclassified General Options
+
+These have not yet been fully documented or classified. They almost
+certainly belong in a more appropriate section.
+
+=over 4
+
+=item B<gfx_passthrough=BOOLEAN>
+
+Enable graphics device PCI passthrough. XXX which device is passed through ?
+
+=item B<nomigrate=BOOLEAN>
+
+Disable migration of this domain.  This enables certain other features
+which are incompatible with migration (currently certain TSC modes XXX
+?).
+
+=item B<pci_msitranslate=BOOLEAN>
+
+XXX
+
+=item B<pci_power_mgmt=BOOLEAN>
+
+XXX
+
+=item B<cpuid=XXX>
+
+XXX
+
+=back
+
+=head2 Keymaps
+
+The keymaps available are defined by the device-model which you are
+using. Commonly this includes:
+
+        ar  de-ch  es  fo     fr-ca  hu  ja  mk     no  pt-br  sv
+        da  en-gb  et  fr     fr-ch  is  lt  nl     pl  ru     th
+        de  en-us  fi  fr-be  hr     it  lv  nl-be  pt  sl     tr
+
+The default is B<en-us>.
+
+See L<qemu(1)> for more information.
+
+=head1 SEE ALSO
+
+=over 4
+
+=item L<xl(1)>
+
+=item F<xl-disk-configuration>
+
+=item F<xl-network-configuration>
+
+=back
+
+=head1 FILES
+
+F</etc/xen/NAME.cfg>
+F</var/xen/dump/NAME>
+F<docs/misc/tscmode.txt>
+
+=head1 BUGS
+
+This document is a work in progress and contains items which require
+further documentation and which are generally incomplete (marked with
+XXX).  However all options are included here whether or not they are
+fully documented.
+
+Patches to improve incomplete items (or any other item) would be
+greatfully received on the xen-devel@lists.xensource.com mailing
+list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
+information on how to submit a patch to Xen.
+
diff -r f3fc909a083d -r c88ff1ac2417 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Nov 17 14:34:11 2011 +0000
+++ b/docs/man/xl.pod.1	Thu Nov 17 14:35:24 2011 +0000
@@ -54,7 +54,7 @@ previously, most commands take I<domain-
 
 =item B<create> [I<OPTIONS>] I<configfile>
 
-The create subcommand requires a config file: see L<xldomain.cfg> for
+The create subcommand requires a config file: see L<xl.cfg(5)> for
 full details of that file format and possible options.
 
 I<configfile> can either be an absolute path to a file, or a relative
@@ -232,7 +232,7 @@ FIXME: Why would you ever see this state
 
 The domain has crashed, which is always a violent ending.  Usually
 this state can only occur if the domain has been configured not to
-restart on crash.  See L<xldomain.cfg> for more info.
+restart on crash.  See L<xl.cfg(5)> for more info.
 
 =item B<d - dying>
 
@@ -319,8 +319,8 @@ executed the reboot action, which may be
 domain actually reboots.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_reboot> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_reboot> parameter of the domain configuration file when the
+domain was created.
 
 =item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile>
 
@@ -372,8 +372,8 @@ services must be shutdown in the domain.
 immediately after signally the domain unless that B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_shutdown> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_shutdown> parameter of the domain configuration file when the
+domain was created.
 
 B<OPTIONS>
 
@@ -699,7 +699,7 @@ The domain id of the guest domain that t
 =item I<disc-spec-component>
 
 A disc specification in the same format used for the B<disk> variable in
-the domain config file. See L<xldomain.cfg>.
+the domain config file. See F<xl-disk-configuration>.
 
 =back
 
@@ -733,9 +733,9 @@ How the device should be presented to th
 
 =item I<be-dev>
 
-the device in the backend domain (usually domain 0) to be exported; it can be a
-path to a file (file://path/to/file.iso). See B<disk> in L<xldomain.cfg> for the
-details.
+the device in the backend domain (usually domain 0) to be exported; it
+can be a path to a file (file://path/to/file.iso). See B<disk> in
+L<xl.cfg(5)> for the details.
 
 =back
 
@@ -754,7 +754,7 @@ I<VirtualDevice> is the cdrom device in 
 
 Creates a new network device in the domain specified by I<domain-id>.
 I<network-device> describes the device to attach, using the same format as the
-B<vif> string in the domain config file. See L<xldomain.cfg> for the
+B<vif> string in the domain config file. See L<xl.cfg(5)> for the
 description.
 
 =item B<network-detach> I<domain-id> I<devid|mac>
@@ -795,7 +795,7 @@ List pass-through pci devices for a doma
 
 =head1 SEE ALSO
 
-B<xldomain.cfg>(5), B<xlcpupool.cfg>(5), B<xentop>(1)
+L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
 
 =head1 AUTHOR
 
diff -r f3fc909a083d -r c88ff1ac2417 tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Thu Nov 17 14:34:11 2011 +0000
+++ b/tools/examples/xlexample.hvm	Thu Nov 17 14:35:24 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for an
-# HVM guest. For a more complete guide see <XXX Document TBD>
+# HVM guest. For a more complete guide see xl.cfg(5)
 
 # This configures an HVM rather than PV guest
 builder = "hvm"
diff -r f3fc909a083d -r c88ff1ac2417 tools/examples/xlexample.pvlinux
--- a/tools/examples/xlexample.pvlinux	Thu Nov 17 14:34:11 2011 +0000
+++ b/tools/examples/xlexample.pvlinux	Thu Nov 17 14:35:24 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for a
-# Paravirtualised Linux guest. For a more complete guide see <XXX Document TBD>
+# Paravirtualised Linux guest. For a more complete guide see xl.cfg(5)
 
 # Guest name
 name = "example.pvlinux"

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:35:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:35:40 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR404-00025G-Ib
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3zl-0001VY-GZ; Thu, 17 Nov 2011 07:35:22 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TU-0002Qf-Hw
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:32 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!4
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16760 invoked from network); 17 Nov 2011 15:01:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189108"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:56 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNH026208;	Thu, 17 Nov 2011 07:01:55 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 6911d1235f82e52b0b16eeb505ebf80054e47f40
Message-ID: <6911d1235f82e52b0b16.1321542114@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 08 of 17] xlu: add "dont_warn" to xlu_cfg_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540537 0
# Node ID 6911d1235f82e52b0b16eeb505ebf80054e47f40
# Parent  f1464f6fba419acc019c824cea4aefb97b2360f6
xlu: add "dont_warn" to xlu_cfg_*

I want it for get_long but we might as well have it everywhere.

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

diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Thu Nov 17 14:35:37 2011 +0000
@@ -165,17 +165,18 @@ static XLU_ConfigSetting *find(const XLU
 }
 
 static int find_atom(const XLU_Config *cfg, const char *n,
-                     XLU_ConfigSetting **set_r) {
+                     XLU_ConfigSetting **set_r, int dont_warn) {
     XLU_ConfigSetting *set;
 
     set= find(cfg,n);
     if (!set) return ESRCH;
 
     if (set->avalues!=1) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is"
-                " a list but should be a single value\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is"
+                    " a list but should be a single value\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *set_r= set;
@@ -183,49 +184,51 @@ static int find_atom(const XLU_Config *c
 }
 
 int xlu_cfg_get_string(const XLU_Config *cfg, const char *n,
-                       const char **value_r) {
+                       const char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     *value_r= set->values[0];
     return 0;
 }
 
 int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
-                           char **value_r) {
+                           char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     free(*value_r);
     *value_r= strdup(set->values[0]);
     return 0;
 }
 
 int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
-                     long *value_r) {
+                     long *value_r, int dont_warn) {
     long l;
     XLU_ConfigSetting *set;
     int e;
     char *ep;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     errno= 0; l= strtol(set->values[0], &ep, 0);
     e= errno;
     if (errno) {
         e= errno;
         assert(e==EINVAL || e==ERANGE);
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' could not be parsed"
-                " as a number: %s\n",
-                cfg->filename, set->lineno, n, strerror(e));
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' could not be parsed"
+                    " as a number: %s\n",
+                    cfg->filename, set->lineno, n, strerror(e));
         return e;
     }
     if (*ep || ep==set->values[0]) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is not a valid number\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is not a valid number\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *value_r= l;
diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/libxlutil.h	Thu Nov 17 14:35:37 2011 +0000
@@ -41,13 +41,17 @@ void xlu_cfg_destroy(XLU_Config*);
  * Return values are:
  *   0        OK
  *   ESRCH    not defined
- *   EINVAL   value found but wrong format for request (prints warning)
+ *   EINVAL   value found but wrong format for request (prints warning unless dont_warn=true)
  *   ERANGE   value out of range (from strtol)
  */
 
-int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r);
-int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char **value_r); /* free/strdup version */
-int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r);
+int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r,
+                       int dont_warn);
+/* free/strdup version */
+int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
+                           char **value_r, int dont_warn);
+int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/xl.c
--- a/tools/libxl/xl.c	Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/xl.c	Thu Nov 17 14:35:37 2011 +0000
@@ -62,10 +62,10 @@ static void parse_global_config(const ch
         exit(1);
     }
 
-    if (!xlu_cfg_get_long (config, "autoballoon", &l))
+    if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
-    if (!xlu_cfg_get_string (config, "lockfile", &buf))
+    if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
         e = asprintf(&lockfile, "%s/xl", (char *)libxl_lock_dir_path());
@@ -75,7 +75,7 @@ static void parse_global_config(const ch
         }
     }
 
-    if (!xlu_cfg_get_string (config, "vifscript", &buf))
+    if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
     xlu_cfg_destroy(config);
diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:37 2011 +0000
@@ -554,7 +554,7 @@ static void parse_config_data(const char
     if (libxl_init_create_info(ctx, c_info))
         exit(1);
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf)) {
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
@@ -568,19 +568,19 @@ static void parse_config_data(const char
     }
 
     c_info->type = LIBXL_DOMAIN_TYPE_PV;
-    if (!xlu_cfg_get_string (config, "builder", &buf) &&
+    if (!xlu_cfg_get_string (config, "builder", &buf, 0) &&
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l))
+    if (!xlu_cfg_get_long (config, "hap", &l, 0))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+    if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.");
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
+    if (!xlu_cfg_get_string (config, "uuid", &buf, 0) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {
             fprintf(stderr, "Failed to parse UUID: %s\n", buf);
             exit(1);
@@ -589,10 +589,10 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l))
+    if (!xlu_cfg_get_long(config, "oos", &l, 0))
         c_info->oos = l;
 
-    if (!xlu_cfg_get_string (config, "pool", &buf)) {
+    if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
@@ -606,37 +606,37 @@ static void parse_config_data(const char
         exit(1);
 
     /* the following is the actual config parsing with overriding values in the structures */
-    if (!xlu_cfg_get_long (config, "vcpus", &l)) {
+    if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;
     }
 
-    if (!xlu_cfg_get_long (config, "maxvcpus", &l))
+    if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus = l;
 
-    if (!xlu_cfg_get_long (config, "memory", &l)) {
+    if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
     }
 
-    if (!xlu_cfg_get_long (config, "maxmem", &l))
+    if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
         b_info->max_memkb = l * 1024;
 
-    if (xlu_cfg_get_string (config, "on_poweroff", &buf))
+    if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_poweroff)) {
         fprintf(stderr, "Unknown on_poweroff action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_reboot", &buf))
+    if (xlu_cfg_get_string (config, "on_reboot", &buf, 0))
         buf = "restart";
     if (!parse_action_on_shutdown(buf, &d_config->on_reboot)) {
         fprintf(stderr, "Unknown on_reboot action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_watchdog", &buf))
+    if (xlu_cfg_get_string (config, "on_watchdog", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_watchdog)) {
         fprintf(stderr, "Unknown on_watchdog action \"%s\" specified\n", buf);
@@ -644,7 +644,7 @@ static void parse_config_data(const char
     }
 
 
-    if (xlu_cfg_get_string (config, "on_crash", &buf))
+    if (xlu_cfg_get_string (config, "on_crash", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_crash)) {
         fprintf(stderr, "Unknown on_crash action \"%s\" specified\n", buf);
@@ -654,48 +654,48 @@ static void parse_config_data(const char
     /* libxl_get_required_shadow_memory() must be called after final values
      * (default or specified) for vcpus and memory are set, because the
      * calculation depends on those values. */
-    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l)
+    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l, 0)
         ? l * 1024
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l))
+    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
         b_info->tsc_mode = l;
 
-    if (!xlu_cfg_get_long (config, "videoram", &l))
+    if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+    if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
         dm_info->gfx_passthru = l;
 
     switch(c_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        if (!xlu_cfg_get_string (config, "kernel", &buf))
+        if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
             fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "
                     "Use \"firmware_override\" instead if you really want a non-default firmware\n");
 
         xlu_cfg_replace_string (config, "firmware_override",
-                                &b_info->u.hvm.firmware);
-        if (!xlu_cfg_get_long (config, "pae", &l))
+                                &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l))
+        if (!xlu_cfg_get_long (config, "apic", &l, 0))
             b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l))
+        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
             b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "nx", &l))
+        if (!xlu_cfg_get_long (config, "nx", &l, 0))
             b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l))
+        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
             b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l))
+        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
             b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l))
+        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
             b_info->u.hvm.vpt_align = l;
-        if (!xlu_cfg_get_long (config, "timer_mode", &l))
+        if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
             b_info->u.hvm.timer_mode = l;
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l))
+        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -703,12 +703,12 @@ static void parse_config_data(const char
         char *cmdline = NULL;
         const char *root = NULL, *extra = "";
 
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_get_string (config, "root", &root);
-        xlu_cfg_get_string (config, "extra", &extra);
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_get_string (config, "root", &root, 0);
+        xlu_cfg_get_string (config, "extra", &extra, 0);
 
         if (root) {
             if (asprintf(&cmdline, "root=%s %s", root, extra) == -1)
@@ -722,8 +722,10 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader);
-        xlu_cfg_replace_string (config, "bootloader_args", &b_info->u.pv.bootloader_args);
+        xlu_cfg_replace_string (config, "bootloader",
+                                &b_info->u.pv.bootloader, 0);
+        xlu_cfg_replace_string (config, "bootloader_args",
+                                &b_info->u.pv.bootloader_args, 0);
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");
@@ -731,7 +733,7 @@ static void parse_config_data(const char
         }
 
         b_info->u.pv.cmdline = cmdline;
-        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path);
+        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path, 0);
         break;
     }
     default:
@@ -906,15 +908,15 @@ skip_vfb:
         }
     }
 
-    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l))
+    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l, 0))
         pci_msitranslate = l;
 
-    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l))
+    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l, 0))
         pci_power_mgmt = l;
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l)) {
+    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
         switch (c_info->type) {
         case LIBXL_DOMAIN_TYPE_HVM:
             fprintf(stderr, "Can't do e820_host in HVM mode!");
@@ -982,7 +984,7 @@ skip_vfb:
         }
         break;
     case EINVAL:    /* config option is not a list, parse as a string */
-        if (!xlu_cfg_get_string(config, "cpuid", &buf)) {
+        if (!xlu_cfg_get_string(config, "cpuid", &buf, 0)) {
             char *buf2, *p, *strtok_ptr = NULL;
             const char *errstr;
 
@@ -1030,7 +1032,7 @@ skip_vfb:
     if (libxl_init_dm_info(ctx, dm_info, c_info, b_info))
         exit(1);
     /* parse device model arguments, this works for pv, hvm and stubdom */
-    if (!xlu_cfg_get_string (config, "device_model", &buf)) {
+    if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) {
         fprintf(stderr,
                 "WARNING: ignoring device_model directive.\n"
                 "WARNING: Use \"device_model_override\" instead if you"
@@ -1049,8 +1051,8 @@ skip_vfb:
 
 
     xlu_cfg_replace_string (config, "device_model_override",
-                            &dm_info->device_model);
-    if (!xlu_cfg_get_string (config, "device_model_version", &buf)) {
+                            &dm_info->device_model, 0);
+    if (!xlu_cfg_get_string (config, "device_model_version", &buf, 0)) {
         if (!strcmp(buf, "qemu-xen-traditional")) {
             dm_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
@@ -1064,7 +1066,7 @@ skip_vfb:
         }
     } else if (dm_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l))
+    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
 #define parse_extra_args(type)                                          \
@@ -1092,46 +1094,46 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l))
+        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
             dm_info->stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l))
+        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
             dm_info->vnc = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd);
-        if (!xlu_cfg_get_long (config, "vncdisplay", &l))
+        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd, 0);
+        if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             dm_info->vncdisplay = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l))
+        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
             dm_info->vncunused = l;
-        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap);
-        if (!xlu_cfg_get_long (config, "sdl", &l))
+        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
+        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l))
+        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
             dm_info->opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l))
+        if (!xlu_cfg_get_long (config, "spice", &l, 0))
             dm_info->spice = l;
-        if (!xlu_cfg_get_long (config, "spiceport", &l))
+        if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             dm_info->spiceport = l;
-        if (!xlu_cfg_get_long (config, "spicetls_port", &l))
+        if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             dm_info->spicetls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l))
+        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost, 0);
+        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
             dm_info->spicedisable_ticketing = l;
-        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l))
+        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd, 0);
+        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
             dm_info->spiceagent_mouse = l;
         else
             dm_info->spiceagent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l))
+        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             dm_info->nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
-        xlu_cfg_replace_string (config, "serial", &dm_info->serial);
-        xlu_cfg_replace_string (config, "boot", &dm_info->boot);
-        if (!xlu_cfg_get_long (config, "usb", &l))
+        xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);
+        xlu_cfg_replace_string (config, "boot", &dm_info->boot, 0);
+        if (!xlu_cfg_get_long (config, "usb", &l, 0))
             dm_info->usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice);
-        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l))
+        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice, 0);
+        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
+        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
             dm_info->xen_platform_pci = l;
     }
 
@@ -4761,7 +4763,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "name", &buf))
+    if (!xlu_cfg_get_string (config, "name", &buf, 0))
         name = strdup(buf);
     else
         name = libxl_basename(filename);
@@ -4770,7 +4772,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "sched", &buf)) {
+    if (!xlu_cfg_get_string (config, "sched", &buf, 0)) {
         if ((schedid = libxl_name_to_schedid(ctx, buf)) < 0) {
             fprintf(stderr, "Unknown scheduler\n");
             return -ERROR_FAIL;

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:35:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:35:40 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR404-00025G-Ib
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:35:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR3zl-0001VY-GZ; Thu, 17 Nov 2011 07:35:22 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TU-0002Qf-Hw
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:32 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!4
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16760 invoked from network); 17 Nov 2011 15:01:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189108"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:56 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNH026208;	Thu, 17 Nov 2011 07:01:55 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 6911d1235f82e52b0b16eeb505ebf80054e47f40
Message-ID: <6911d1235f82e52b0b16.1321542114@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 08 of 17] xlu: add "dont_warn" to xlu_cfg_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540537 0
# Node ID 6911d1235f82e52b0b16eeb505ebf80054e47f40
# Parent  f1464f6fba419acc019c824cea4aefb97b2360f6
xlu: add "dont_warn" to xlu_cfg_*

I want it for get_long but we might as well have it everywhere.

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

diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Thu Nov 17 14:35:37 2011 +0000
@@ -165,17 +165,18 @@ static XLU_ConfigSetting *find(const XLU
 }
 
 static int find_atom(const XLU_Config *cfg, const char *n,
-                     XLU_ConfigSetting **set_r) {
+                     XLU_ConfigSetting **set_r, int dont_warn) {
     XLU_ConfigSetting *set;
 
     set= find(cfg,n);
     if (!set) return ESRCH;
 
     if (set->avalues!=1) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is"
-                " a list but should be a single value\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is"
+                    " a list but should be a single value\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *set_r= set;
@@ -183,49 +184,51 @@ static int find_atom(const XLU_Config *c
 }
 
 int xlu_cfg_get_string(const XLU_Config *cfg, const char *n,
-                       const char **value_r) {
+                       const char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     *value_r= set->values[0];
     return 0;
 }
 
 int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
-                           char **value_r) {
+                           char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     free(*value_r);
     *value_r= strdup(set->values[0]);
     return 0;
 }
 
 int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
-                     long *value_r) {
+                     long *value_r, int dont_warn) {
     long l;
     XLU_ConfigSetting *set;
     int e;
     char *ep;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     errno= 0; l= strtol(set->values[0], &ep, 0);
     e= errno;
     if (errno) {
         e= errno;
         assert(e==EINVAL || e==ERANGE);
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' could not be parsed"
-                " as a number: %s\n",
-                cfg->filename, set->lineno, n, strerror(e));
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' could not be parsed"
+                    " as a number: %s\n",
+                    cfg->filename, set->lineno, n, strerror(e));
         return e;
     }
     if (*ep || ep==set->values[0]) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is not a valid number\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is not a valid number\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *value_r= l;
diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/libxlutil.h	Thu Nov 17 14:35:37 2011 +0000
@@ -41,13 +41,17 @@ void xlu_cfg_destroy(XLU_Config*);
  * Return values are:
  *   0        OK
  *   ESRCH    not defined
- *   EINVAL   value found but wrong format for request (prints warning)
+ *   EINVAL   value found but wrong format for request (prints warning unless dont_warn=true)
  *   ERANGE   value out of range (from strtol)
  */
 
-int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r);
-int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char **value_r); /* free/strdup version */
-int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r);
+int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r,
+                       int dont_warn);
+/* free/strdup version */
+int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
+                           char **value_r, int dont_warn);
+int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/xl.c
--- a/tools/libxl/xl.c	Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/xl.c	Thu Nov 17 14:35:37 2011 +0000
@@ -62,10 +62,10 @@ static void parse_global_config(const ch
         exit(1);
     }
 
-    if (!xlu_cfg_get_long (config, "autoballoon", &l))
+    if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
-    if (!xlu_cfg_get_string (config, "lockfile", &buf))
+    if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
         e = asprintf(&lockfile, "%s/xl", (char *)libxl_lock_dir_path());
@@ -75,7 +75,7 @@ static void parse_global_config(const ch
         }
     }
 
-    if (!xlu_cfg_get_string (config, "vifscript", &buf))
+    if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
     xlu_cfg_destroy(config);
diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 14:35:37 2011 +0000
@@ -554,7 +554,7 @@ static void parse_config_data(const char
     if (libxl_init_create_info(ctx, c_info))
         exit(1);
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf)) {
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
@@ -568,19 +568,19 @@ static void parse_config_data(const char
     }
 
     c_info->type = LIBXL_DOMAIN_TYPE_PV;
-    if (!xlu_cfg_get_string (config, "builder", &buf) &&
+    if (!xlu_cfg_get_string (config, "builder", &buf, 0) &&
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l))
+    if (!xlu_cfg_get_long (config, "hap", &l, 0))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+    if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.");
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
+    if (!xlu_cfg_get_string (config, "uuid", &buf, 0) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {
             fprintf(stderr, "Failed to parse UUID: %s\n", buf);
             exit(1);
@@ -589,10 +589,10 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l))
+    if (!xlu_cfg_get_long(config, "oos", &l, 0))
         c_info->oos = l;
 
-    if (!xlu_cfg_get_string (config, "pool", &buf)) {
+    if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
@@ -606,37 +606,37 @@ static void parse_config_data(const char
         exit(1);
 
     /* the following is the actual config parsing with overriding values in the structures */
-    if (!xlu_cfg_get_long (config, "vcpus", &l)) {
+    if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;
     }
 
-    if (!xlu_cfg_get_long (config, "maxvcpus", &l))
+    if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus = l;
 
-    if (!xlu_cfg_get_long (config, "memory", &l)) {
+    if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
     }
 
-    if (!xlu_cfg_get_long (config, "maxmem", &l))
+    if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
         b_info->max_memkb = l * 1024;
 
-    if (xlu_cfg_get_string (config, "on_poweroff", &buf))
+    if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_poweroff)) {
         fprintf(stderr, "Unknown on_poweroff action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_reboot", &buf))
+    if (xlu_cfg_get_string (config, "on_reboot", &buf, 0))
         buf = "restart";
     if (!parse_action_on_shutdown(buf, &d_config->on_reboot)) {
         fprintf(stderr, "Unknown on_reboot action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_watchdog", &buf))
+    if (xlu_cfg_get_string (config, "on_watchdog", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_watchdog)) {
         fprintf(stderr, "Unknown on_watchdog action \"%s\" specified\n", buf);
@@ -644,7 +644,7 @@ static void parse_config_data(const char
     }
 
 
-    if (xlu_cfg_get_string (config, "on_crash", &buf))
+    if (xlu_cfg_get_string (config, "on_crash", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_crash)) {
         fprintf(stderr, "Unknown on_crash action \"%s\" specified\n", buf);
@@ -654,48 +654,48 @@ static void parse_config_data(const char
     /* libxl_get_required_shadow_memory() must be called after final values
      * (default or specified) for vcpus and memory are set, because the
      * calculation depends on those values. */
-    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l)
+    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l, 0)
         ? l * 1024
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l))
+    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
         b_info->tsc_mode = l;
 
-    if (!xlu_cfg_get_long (config, "videoram", &l))
+    if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+    if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
         dm_info->gfx_passthru = l;
 
     switch(c_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        if (!xlu_cfg_get_string (config, "kernel", &buf))
+        if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
             fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "
                     "Use \"firmware_override\" instead if you really want a non-default firmware\n");
 
         xlu_cfg_replace_string (config, "firmware_override",
-                                &b_info->u.hvm.firmware);
-        if (!xlu_cfg_get_long (config, "pae", &l))
+                                &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l))
+        if (!xlu_cfg_get_long (config, "apic", &l, 0))
             b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l))
+        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
             b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "nx", &l))
+        if (!xlu_cfg_get_long (config, "nx", &l, 0))
             b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l))
+        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
             b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l))
+        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
             b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l))
+        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
             b_info->u.hvm.vpt_align = l;
-        if (!xlu_cfg_get_long (config, "timer_mode", &l))
+        if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
             b_info->u.hvm.timer_mode = l;
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l))
+        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -703,12 +703,12 @@ static void parse_config_data(const char
         char *cmdline = NULL;
         const char *root = NULL, *extra = "";
 
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_get_string (config, "root", &root);
-        xlu_cfg_get_string (config, "extra", &extra);
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_get_string (config, "root", &root, 0);
+        xlu_cfg_get_string (config, "extra", &extra, 0);
 
         if (root) {
             if (asprintf(&cmdline, "root=%s %s", root, extra) == -1)
@@ -722,8 +722,10 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader);
-        xlu_cfg_replace_string (config, "bootloader_args", &b_info->u.pv.bootloader_args);
+        xlu_cfg_replace_string (config, "bootloader",
+                                &b_info->u.pv.bootloader, 0);
+        xlu_cfg_replace_string (config, "bootloader_args",
+                                &b_info->u.pv.bootloader_args, 0);
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");
@@ -731,7 +733,7 @@ static void parse_config_data(const char
         }
 
         b_info->u.pv.cmdline = cmdline;
-        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path);
+        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path, 0);
         break;
     }
     default:
@@ -906,15 +908,15 @@ skip_vfb:
         }
     }
 
-    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l))
+    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l, 0))
         pci_msitranslate = l;
 
-    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l))
+    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l, 0))
         pci_power_mgmt = l;
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l)) {
+    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
         switch (c_info->type) {
         case LIBXL_DOMAIN_TYPE_HVM:
             fprintf(stderr, "Can't do e820_host in HVM mode!");
@@ -982,7 +984,7 @@ skip_vfb:
         }
         break;
     case EINVAL:    /* config option is not a list, parse as a string */
-        if (!xlu_cfg_get_string(config, "cpuid", &buf)) {
+        if (!xlu_cfg_get_string(config, "cpuid", &buf, 0)) {
             char *buf2, *p, *strtok_ptr = NULL;
             const char *errstr;
 
@@ -1030,7 +1032,7 @@ skip_vfb:
     if (libxl_init_dm_info(ctx, dm_info, c_info, b_info))
         exit(1);
     /* parse device model arguments, this works for pv, hvm and stubdom */
-    if (!xlu_cfg_get_string (config, "device_model", &buf)) {
+    if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) {
         fprintf(stderr,
                 "WARNING: ignoring device_model directive.\n"
                 "WARNING: Use \"device_model_override\" instead if you"
@@ -1049,8 +1051,8 @@ skip_vfb:
 
 
     xlu_cfg_replace_string (config, "device_model_override",
-                            &dm_info->device_model);
-    if (!xlu_cfg_get_string (config, "device_model_version", &buf)) {
+                            &dm_info->device_model, 0);
+    if (!xlu_cfg_get_string (config, "device_model_version", &buf, 0)) {
         if (!strcmp(buf, "qemu-xen-traditional")) {
             dm_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
@@ -1064,7 +1066,7 @@ skip_vfb:
         }
     } else if (dm_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l))
+    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
 #define parse_extra_args(type)                                          \
@@ -1092,46 +1094,46 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l))
+        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
             dm_info->stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l))
+        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
             dm_info->vnc = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd);
-        if (!xlu_cfg_get_long (config, "vncdisplay", &l))
+        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd, 0);
+        if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             dm_info->vncdisplay = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l))
+        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
             dm_info->vncunused = l;
-        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap);
-        if (!xlu_cfg_get_long (config, "sdl", &l))
+        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
+        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l))
+        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
             dm_info->opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l))
+        if (!xlu_cfg_get_long (config, "spice", &l, 0))
             dm_info->spice = l;
-        if (!xlu_cfg_get_long (config, "spiceport", &l))
+        if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             dm_info->spiceport = l;
-        if (!xlu_cfg_get_long (config, "spicetls_port", &l))
+        if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             dm_info->spicetls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l))
+        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost, 0);
+        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
             dm_info->spicedisable_ticketing = l;
-        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l))
+        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd, 0);
+        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
             dm_info->spiceagent_mouse = l;
         else
             dm_info->spiceagent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l))
+        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             dm_info->nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
-        xlu_cfg_replace_string (config, "serial", &dm_info->serial);
-        xlu_cfg_replace_string (config, "boot", &dm_info->boot);
-        if (!xlu_cfg_get_long (config, "usb", &l))
+        xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);
+        xlu_cfg_replace_string (config, "boot", &dm_info->boot, 0);
+        if (!xlu_cfg_get_long (config, "usb", &l, 0))
             dm_info->usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice);
-        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l))
+        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice, 0);
+        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
+        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
             dm_info->xen_platform_pci = l;
     }
 
@@ -4761,7 +4763,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "name", &buf))
+    if (!xlu_cfg_get_string (config, "name", &buf, 0))
         name = strdup(buf);
     else
         name = libxl_basename(filename);
@@ -4770,7 +4772,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "sched", &buf)) {
+    if (!xlu_cfg_get_string (config, "sched", &buf, 0)) {
         if ((schedid = libxl_name_to_schedid(ctx, buf)) < 0) {
             fprintf(stderr, "Unknown scheduler\n");
             return -ERROR_FAIL;

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:37:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:37:08 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR41U-00025T-C8
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR41C-0001uL-SM; Thu, 17 Nov 2011 07:36:50 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TY-0002Qw-0B
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:34 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!6
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16870 invoked from network); 17 Nov 2011 15:01:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189112"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:59 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNK026208;	Thu, 17 Nov 2011 07:01:57 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 55ce23cb7b2af3c497b3a10658e09d5fc11eb45f
Message-ID: <55ce23cb7b2af3c497b3.1321542117@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:57 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 11 of 17] docs: remove some fatally out of date
	documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321541678 0
# Node ID 55ce23cb7b2af3c497b3a10658e09d5fc11eb45f
# Parent  617f5d6e9e69b4f6362df91f078b7dc2abdbd80a
docs: remove some fatally out of date documentation

I think these are better off deleted than remaining to confuse people.

docs/misc/blkif-drivers-explained.txt:

 - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.

docs/misc/cpuid-config-for-guest.txt:

 - Doesn't really say anything, in particular doesn't actually describe how to
   configure CPUID.

docs/misc/hg-cheatsheet.txt:

 - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
   under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
   hardly unusual anymore I think there must be better guides out there so this
   one is not worth resurecting.

docs/misc/network_setup.txt:

 - This is more comprehensively documented on the wiki these days.

docs/misc/VMX_changes.txt:

 - Is basically a changelog from the initial implementation of VMX in 2004.

I'm not sure about some of the other docs, but these ones seemed fairly
obvious.

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

diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/VMX_changes.txt
--- a/docs/misc/VMX_changes.txt	Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,90 +0,0 @@
-Changes to Xen in support of Intel(R) Vanderpool Technology
--------------------------------------------------------------
-
-Our VT extensions to the Xen hypervisor provide full platform
-virtualization, including CPU(s), memory, and I/O infrastructure. The
-generic code in Xen handles and schedules those virtual machines as it
-does for the existing para-virtualized domains.
-
-Full virtualization required by the OS guests requires full device
-virtualization as well. The device models in BOCHS
-(http://bochs.sourceforge.net/) were decoupled from the CPU
-virtualization, and are used to virtualize the legacy devices (such as
-keyboard, mouse, VGA, IDE) in the PC platform. At this point, the
-device models run in user mode on domain 0, not in the Xen hypervisor.
-
-We would like to thank Ian Pratt and Keir Fraser for reviewing our
-design and code intensively, and for providing numerous useful
-suggestions to improve the architecture and code. 
-
-We have a list of Intel team members who take credit for making this
-release happen: Yunhong Jiang, Nitin Kamble, Chengyuan Li, Xin Li,
-Xiaofeng Ling, Benjamin Liu, Asit Mallick, Jun Nakajima, Sunil Saxena,
-Arun Sharma, Edwin Zhai, Jeff Zheng, and Louis Zhuang. We'll continue
-to add more features to complete full virtualization in Xen using VT.
-
-The notes document the changes to the Xen hypervisor in order to add
-VT support. The changes to other areas, such as Control Panel will be
-added as we deliver the code.
-
-Summary of changes for the first release
-----------------------------------------
-December 15, 2004
-
-    * VT specific event handling and domain management were added. 
-
-    * Shadow mode was extended to support full 32-bit guests
-    
-    * Domain switching code was extended to support VT domain
-    
-    * I/O request handling was added to communicate with the device model
-
-    * Domain builder was extended to provide the environment when the
-      guest enters the protected mode, including E820 memory and VGA
-      info, typically obtained by BIOS calls.
-
-New code:
----------
-    VT (Vanderpool Technology) is based on the new VMX (Virtual
-    Machine Extensions) architecture. The current release of the
-    software supports 32-bit only.
-
-    * arch/x86/vmx.[ch] and arch/x86/vmx_*.[ch]: created to handle
-      VMX-specific events in order to provide virtual machine.
-
-    * arch/x86/x86_32/entry.S: new code path was added to have the
-      first-level handler from VM exits. The first-level handler calls
-      the second-level handler in arch/x86/vmx.c.
-
-    * arch/x86/setup.c: new function start_vmx() to init_intel() to
-      enable VMX mode.
-
-    * include/asm-x86/config.h: #ifdef CONFIG_VMX was added.
-
-    * arch/x86/domain.c: new code patch was added to create a VMX
-      domain given the flag from the control panel.
-
-    * include/public/io/ioreq.h: A new data structure was added to
-      define the I/O requests between the Xen hypervisor and the
-      device models.
-
-Changes to the existing code:
------------------------------
-
-    * arch/x86/shadow.[ch]: new mode SHM_full_32 was added to support
-      full virtualization. The current Xen code assumes that the guest
-      page directory and tables have _machine_ (or host) physical page
-      frame numbers, and the new code allows to support _guest_
-      physical page frame numbers
-
-    * include/asm-x86/processor.h: struct arch_vmx_struct arch_vmx has
-      been added to the thread_struct data structure. The arch_vmx has
-      the additional VMX-related CPU context.
-
-    * arch/x86/io_apic.c: reverse mapping between vector and irq has
-      been added. We will revisit this code when considering MSI
-      support.
-
---- Jun
-
-
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/blkif-drivers-explained.txt
--- a/docs/misc/blkif-drivers-explained.txt	Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,485 +0,0 @@
-=== How the Blkif Drivers Work ===
-Andrew Warfield
-andrew.warfield@cl.cam.ac.uk
-
-The intent of this is to explain at a fairly detailed level how the
-split device drivers work in Xen 1.3 (aka 2.0beta).  The intended
-audience for this, I suppose, is anyone who intends to work with the
-existing blkif interfaces and wants something to help them get up to
-speed with the code in a hurry.  Secondly though, I hope to break out
-the general mechanisms that are used in the drivers that are likely to
-be necessary to implement other drivers interfaces.
-
-As a point of warning before starting, it is worth mentioning that I
-anticipate much of the specifics described here changing in the near
-future.  There has been talk about making the blkif protocol
-a bit more efficient than it currently is.  Keir's addition of grant
-tables will change the current remapping code that is used when shared
-pages are initially set up.
-
-Also, writing other control interface types will likely need support
-from Xend, which at the moment has a steep learning curve... this
-should be addressed in the future.
-
-For more information on the driver model as a whole, read the
-"Reconstructing I/O" technical report
-(http://www.cl.cam.ac.uk/Research/SRG/netos/papers/2004-xenngio.pdf).
-
-==== High-level structure of a split-driver interface ====
-
-Why would you want to write a split driver in the first place?  As Xen
-is a virtual machine manager and focuses on isolation as an initial
-design principle, it is generally considered unwise to share physical
-access to devices across domains.  The reasons for this are obvious:
-when device resources are shared, misbehaving code or hardware can
-result in the failure of all of the client applications.  Moreover, as
-virtual machines in Xen are entire OSs, standard device drives that
-they might use cannot have multiple instantiations for a single piece
-of hardware.  In light of all this, the general approach in Xen is to
-give a single virtual machine hardware access to a device, and where
-other VMs want to share the device, export a higher-level interface to
-facilitate that sharing.  If you don't want to share, that's fine.
-There are currently Xen users actively exploring running two
-completely isolated X-Servers on a Xen host, each with it's own video
-card, keyboard, and mouse.  In these situations, the guests need only
-be given physical access to the necessary devices and left to go on
-their own.  However, for devices such as disks and network interfaces,
-where sharing is required, the split driver approach is a good
-solution.
-
-The structure is like this:
-
-   +--------------------------+  +--------------------------+
-   | Domain 0 (privileged)    |  | Domain 1 (unprivileged)  |
-   |                          |  |                          |
-   | Xend ( Application )     |  |                          |
-   | Blkif Backend Driver     |  | Blkif Frontend Driver    |
-   | Physical Device Driver   |  |                          |
-   +--------------------------+  +--------------------------+
-   +--------------------------------------------------------+
-   |                X       E       N                       |
-   +--------------------------------------------------------+
-
-
-The Blkif driver is in two parts, which we refer to as frontend (FE)
-and a backend (BE).  Together, they serve to proxy device requests
-between the guest operating system in an unprivileged domain, and the
-physical device driver in the physical domain.  An additional benefit
-to this approach is that the FE driver can provide a single interface
-for a whole class of physical devices.  The blkif interface mounts
-IDE, SCSI, and our own VBD-structured disks, independent of the
-physical driver underneath.  Moreover, supporting additional OSs only
-requires that a new FE driver be written to connect to the existing
-backend.
-
-==== Inter-Domain Communication Mechanisms ====
-
-===== Event Channels =====
-
-Before getting into the specifics of the block interface driver, it is
-worth discussing the mechanisms that are used to communicate between
-domains.  Two mechanisms are used to allow the construction of
-high-performance drivers: event channels and shared-memory rings.
-
-Event channels are an asynchronous interdomain notification
-mechanism.  Xen allows channels to be instantiated between two
-domains, and domains can request that a virtual irq be attached to
-notifications on a given channel.  The result of this is that the
-frontend domain can send a notification on an event channel, resulting
-in an interrupt entry into the backend at a later time.
-
-The event channel between two domains is instantiated in the Xend code
-during driver startup (described later).  Xend's channel.py
-(tools/python/xen/xend/server/channel.py) defines the function
-
-
-def eventChannel(dom1, dom2):
-    return xc.evtchn_bind_interdomain(dom1=dom1, dom2=dom2)
-
-
-which maps to xc_evtchn_bind_interdomain() in tools/libxc/xc_evtchn.c,
-which in turn generates a hypercall to Xen to patch the event channel
-between the domains.  Only a privileged domain can request the
-creation of an event channel.
-
-Once the event channel is created in Xend, its ends are passed to both the
-front and backend domains over the control channel.  The end that is
-passed to a domain is just an integer "port" uniquely identifying the
-event channel's local connection to that domain.  An example of this
-setup code is in linux-2.6.x/drivers/xen/blkfront/blkfront.c in
-blkif_connect(), which receives several status change events as
-the driver starts up.  It is passed an event channel end in a
-BLKIF_INTERFACE_STATUS_CONNECTED message, and patches it in like this:
-
-
-   blkif_evtchn = status->evtchn;
-   blkif_irq    = bind_evtchn_to_irq(blkif_evtchn);
-   if ( (rc = request_irq(blkif_irq, blkif_int, 
-                          SA_SAMPLE_RANDOM, "blkif", NULL)) )
-       printk(KERN_ALERT"blkfront request_irq failed (%ld)\n",rc);
-
-
-This code associates a virtual irq with the event channel, and
-attaches the function blkif_int() as an interrupt handler for that
-irq.  blkif_int() simply handles the notification and returns, it does
-not need to interact with the channel at all.
-
-An example of generating a notification can also be seen in blkfront.c:
-
-
-static inline void flush_requests(void)
-{
-    DISABLE_SCATTERGATHER();
-    wmb(); /* Ensure that the frontend can see the requests. */
-    blk_ring->req_prod = req_prod;
-    notify_via_evtchn(blkif_evtchn);
-}
-}}}
-
-notify_via_evtchn() issues a hypercall to set the event waiting flag on
-the other domain's end of the channel.
-
-===== Communication Rings =====
-
-Event channels are strictly a notification mechanism between domains.
-To move large chunks of data back and forth, Xen allows domains to
-share pages of memory.  We use communication rings as a means of
-managing access to a shared memory page for message passing between
-domains.  These rings are not explicitly a mechanism of Xen, which is
-only concerned with the actual sharing of the page and not how it is
-used, they are however worth discussing as they are used in many
-places in the current code and are a useful model for communicating
-across a shared page.
-
-A shared page is set up by a front end guest first allocating and passing 
-the address of a page in its own address space to the backend driver.  
-
-Consider the following code, also from blkfront.c.  Note:  this code
-is in blkif_disconnect().  The driver transitions from STATE_CLOSED
-to STATE_DISCONNECTED before becoming CONNECTED.  The state automata
-is in blkif_status().
-
-   blk_ring = (blkif_ring_t *)__get_free_page(GFP_KERNEL);
-   blk_ring->req_prod = blk_ring->resp_prod = resp_cons = req_prod = 0;
-   ...
-   /* Construct an interface-CONNECT message for the domain controller. */
-   cmsg.type      = CMSG_BLKIF_FE;
-   cmsg.subtype   = CMSG_BLKIF_FE_INTERFACE_CONNECT;
-   cmsg.length    = sizeof(blkif_fe_interface_connect_t);
-   up.handle      = 0;
-   up.shmem_frame = virt_to_machine(blk_ring) >> PAGE_SHIFT;
-   memcpy(cmsg.msg, &up, sizeof(up));  
-
-
-blk_ring will be the shared page.  The producer and consumer pointers
-are then initialised (these will be discussed soon), and then the
-machine address of the page is send to the backend via a control
-channel to Xend.  This control channel itself uses the notification
-and shared memory mechanisms described here, but is set up for each
-domain automatically at startup.
-
-The backend, which is a privileged domain then takes the page address
-and maps it into its own address space (in
-linux26/drivers/xen/blkback/interface.c:blkif_connect()):
-
-
-void blkif_connect(blkif_be_connect_t *connect)
-
-   ...
-   unsigned long shmem_frame = connect->shmem_frame;
-   ...
-
-   if ( (vma = get_vm_area(PAGE_SIZE, VM_IOREMAP)) == NULL )
-   {
-      connect->status = BLKIF_BE_STATUS_OUT_OF_MEMORY;
-      return;
-   }
-
-   prot = __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED);
-   error = direct_remap_area_pages(&init_mm, VMALLOC_VMADDR(vma->addr),
-                                   shmem_frame<<PAGE_SHIFT, PAGE_SIZE,
-                                   prot, domid);
-
-   ...
-
-   blkif->blk_ring_base = (blkif_ring_t *)vma->addr
-}}}
-
-The machine address of the page is passed in the shmem_frame field of
-the connect message.  This is then mapped into the virtual address
-space of the backend domain, and saved in the blkif structure
-representing this particular backend connection.
-
-NOTE:  New mechanisms will be added very shortly to allow domains to
-explicitly grant access to their pages to other domains.  This "grant
-table" support is in the process of being added to the tree, and will
-change the way a shared page is set up.  In particular, it will remove
-the need of the remapping domain to be privileged.
-
-Sending data across shared rings:
-
-Shared rings avoid the potential for write interference between
-domains in a very cunning way.  A ring is partitioned into a request
-and a response region, and domains only work within their own space.
-This can be thought of as a double producer-consumer ring -- the ring
-is described by four pointers into a circular buffer of fixed-size
-records.  Pointers may only advance, and may not pass one another.
-
-
-                         resp_cons----+
-                                      V
-           +----+----+----+----+----+----+----+
-           |    |    |  free(A)     |RSP1|RSP2|
-           +----+----+----+----+----+----+----+
- req_prod->|    |       -------->        |RSP3|
-           +----+                        +----+
-           |REQ8|                        |    |<-resp_prod
-           +----+                        +----+
-           |REQ7|                        |    |
-           +----+                        +----+
-           |REQ6|       <--------        |    |
-           +----+----+----+----+----+----+----+
-           |REQ5|REQ4|    free(B)   |    |    |
-           +----+----+----+----+----+----+----+
-  req_cons---------^
-
-
-
-By adopting the convention that every request will receive a response,
-not all four pointers need be shared and flow control on the ring
-becomes very easy to manage.  Each domain manages its own
-consumer pointer, and the two producer pointers are visible to both
-(xen/include/public/io/blkif.h):
-
-
-/* NB. Ring size must be small enough for sizeof(blkif_ring_t) <=PAGE_SIZE.*/
-  #define BLKIF_RING_SIZE        64
-
-  ...
-
-/*
- * We use a special capitalised type name because it is _essential_ that all
- * arithmetic on indexes is done on an integer type of the correct size.
- */
-typedef u32 BLKIF_RING_IDX;
-
-/*
- * Ring indexes are 'free running'. That is, they are not stored modulo the
- * size of the ring buffer. The following macro converts a free-running counter
- * into a value that can directly index a ring-buffer array.
- */
-#define MASK_BLKIF_IDX(_i) ((_i)&(BLKIF_RING_SIZE-1))
-
-typedef struct {
-    BLKIF_RING_IDX req_prod;  /*  0: Request producer. Updated by front-end. */
-    BLKIF_RING_IDX resp_prod; /*  4: Response producer. Updated by back-end. */
-    union {                   /*  8 */
-        blkif_request_t  req;
-        blkif_response_t resp;
-    } PACKED ring[BLKIF_RING_SIZE];
-} PACKED blkif_ring_t;
-
-
-
-As shown in the diagram above, the rules for using a shared memory
-ring are simple.  
-
- 1. A ring is full when a domain's producer and consumer pointers are
-    equal (e.g. req_prod == resp_cons).  In this situation, the
-    consumer pointer must be advanced.  Furthermore, if the consumer
-    pointer is equal to the other domain's producer pointer,
-    (e.g. resp_cons = resp_prod), then the other domain has all the
-    buffers.
-
-2. Producer pointers point to the next buffer that will be written to.
-   (So blk_ring[MASK_BLKIF_IDX(req_prod)] should not be consumed.)
-
-3. Consumer pointers point to a valid message, so long as they are not
-   equal to the associated producer pointer.
-
-4. A domain should only ever write to the message pointed
-   to by its producer index, and read from the message at it's
-   consumer.  More generally, the domain may be thought of to have
-   exclusive access to the messages between its consumer and producer,
-   and should absolutely not read or write outside this region.
-
-   Thus the front end has exclusive access to the free(A) region 
-   in the figure above, and the back end driver has exclusive
-   access to the free(B) region.
-
-In general, drivers keep a private copy of their producer pointer and
-then set the shared version when they are ready for the other end to
-process a set of messages.  Additionally, it is worth paying attention
-to the use of memory barriers (rmb/wmb) in the code, to ensure that
-rings that are shared across processors behave as expected.
-
-==== Structure of the Blkif Drivers ====
-
-Now that the communications primitives have been discussed, I'll
-quickly cover the general structure of the blkif driver.  This is
-intended to give a high-level idea of what is going on, in an effort
-to make reading the code a more approachable task.
-
-There are three key software components that are involved in the blkif
-drivers (not counting Xen itself).  The frontend and backend driver,
-and Xend, which coordinates their initial connection.  Xend may also
-be involved in control-channel signalling in some cases after startup,
-for instance to manage reconnection if the backend is restarted.
-
-===== Frontend Driver Structure =====
-
-The frontend domain uses a single event channel and a shared memory
-ring to trade control messages with the backend.  These are both setup
-during domain startup, which will be discussed shortly.  The shared
-memory ring is called blkif_ring, and the private ring indexes are
-resp_cons, and req_prod.  The ring is protected by blkif_io_lock.
-Additionally, the frontend keeps a list of outstanding requests in
-rec_ring[].  These are uniquely identified by a guest-local id number,
-which is associated with each request sent to the backend, and
-returned with the matching responses.  Information about the actual
-disks are stored in major_info[], of which only the first nr_vbds
-entries are valid.  Finally, the global 'recovery' indicates that the
-connection between the backend and frontend drivers has been broken
-(possibly due to a backend driver crash) and that the frontend is in
-recovery mode, in which case it will attempt to reconnect and reissue
-outstanding requests.
-
-The frontend driver is single-threaded and after setup is entered only
-through three points:  (1) read/write requests from the XenLinux guest
-that it is a part of, (2) interrupts from the backend driver on its
-event channel (blkif_int()), and (3) control messages from Xend
-(blkif_ctrlif_rx).
-
-===== Backend Driver Structure =====
-
-The backend driver is slightly more complex as it must manage any
-number of concurrent frontend connections.  For each domain it
-manages, the backend driver maintains a blkif structure, which
-describes all the connection and disk information associated with that
-particular domain.  This structure is associated with the interrupt
-registration, and allows the backend driver to have immediate context
-when it takes a notification from some domain.
-
-All of the blkif structures are stored in a hash table (blkif_hash),
-which is indexed by a hash of the domain id, and a "handle", really a
-per-domain blkif identifier, in case it wants to have multiple connections.
-
-The per-connection blkif structure is of type blkif_t.  It contains
-all of the communication details (event channel, irq, shared memory
-ring and indexes), and blk_ring_lock, which is the backend mutex on
-the shared ring.  The structure also contains vbd_rb, which is a
-red-black tree, containing an entry for each device/partition that is
-assigned to that domain.  This structure is filled by xend passing
-disk information to the backend at startup, and is protected by
-vbd_lock.  Finally, the blkif struct contains a status field, which
-describes the state of the connection.
-
-The backend driver spawns a kernel thread at startup
-(blkio_schedule()), which handles requests to and from the actual disk
-device drivers.  This scheduler thread maintains a list of blkif
-structures that have pending requests, and services them round-robin
-with a maximum per-round request limit.  blkifs are added to the list
-in the interrupt handler (blkif_be_int()) using
-add_to_blkdev_list_tail(), and removed in the scheduler loop after
-calling do_block_io_op(), which processes a batch of requests.  The
-scheduler thread is explicitly activated at several points in the code
-using maybe_trigger_blkio_schedule().
-
-Pending requests between the backend driver and the physical device
-drivers use another ring, pending_ring.  Requests are placed in this
-ring in the scheduler thread and issued to the device.  A completion
-callback, end_block_io_op, indicates that requests have been serviced
-and generates a response on the appropriate blkif ring.  pending
-reqs[] stores a list of outstanding requests with the physical drivers.
-
-So, control entries to the backend are (1) the blkio scheduler thread,
-which sends requests to the real device drivers, (2) end_block_io_op,
-which is called as serviced requests complete, (3) blkif_be_int()
-handles notifications from the frontend drivers in other domains, and
-(4) blkif_ctrlif_rx() handles control messages from xend.
-
-==== Driver Startup ====
-
-Prior to starting a new guest using the frontend driver, the backend
-will have been started in a privileged domain.  The backend
-initialisation code initialises all of its data structures, such as
-the blkif hash table, and starts the scheduler thread as a kernel
-thread. It then sends a driver status up message to let xend know it
-is ready to take frontend connections.
-
-When a new domain that uses the blkif frontend driver is started,
-there are a series of interactions between it, xend, and the specified
-backend driver.  These interactions are as follows:
-
-The domain configuration given to xend will specify the backend domain
-and disks that the new guest is to use.  Prior to actually running the
-domain, xend and the backend driver interact to setup the initial
-blkif record in the backend.
-
-(1) Xend sends a BLKIF_BE_CREATE message to backend.
-
-  Backend does blkif_create(), having been passed FE domid and handle.
-  It creates and initialises a new blkif struct, and puts it in the
-  hash table.
-  It then returns a STATUS_OK response to xend.
-
-(2) Xend sends a BLKIF_BE_VBD_CREATE message to the backend.
- 
-  Backend adds a vbd entry in the red-black tree for the
-  specified (dom, handle) blkif entry.
-  Sends a STATUS_OK response.
-
-(3) Xend sends a BLKIF_BE_VBD_GROW message to the backend.
-
-  Backend takes the physical device information passed in the 
-  message and assigns them to the newly created vbd struct.
-
-(2) and (3) repeat as any additional devices are added to the domain.
-
-At this point, the backend has enough state to allow the frontend
-domain to start.  The domain is run, and eventually gets to the
-frontend driver initialisation code.  After setting up the frontend
-data structures, this code continues the communications with xend and
-the backend to negotiate a connection:
-
-(4) Frontend sends Xend a BLKIF_FE_DRIVER_STATUS_CHANGED message.
-
-  This message tells xend that the driver is up.  The init function
-  now spin-waits until driver setup is complete in order to prevent
-  Linux from attempting to boot before the disks are connected.
-
-(5) Xend sends the frontend an INTERFACE_STATUS_CHANGED message
-
-  This message specifies that the interface is now disconnected
-  (instead of closed).
-  The domain updates it's state, and allocates the shared blk_ring
-  page.  Next, 
-
-(6) Frontend sends Xend a BLKIF_INTERFACE_CONNECT message
-
-  This message specifies the domain and handle, and includes the
-  address of the newly created page.
-
-(7) Xend sends the backend a BLKIF_BE_CONNECT message
-
-  The backend fills in the blkif connection information, maps the
-  shared page, and binds an irq to the event channel.
-  
-(8) Xend sends the frontend an INTERFACE_STATUS_CHANGED message
-
-  This message takes the frontend driver to a CONNECTED state, at
-  which point it binds an irq to the event channel and calls
-  xlvbd_init to initialise the individual block devices.
-
-The frontend Linux is stall spin waiting at this point, until all of
-the disks have been probed.  Messaging now is directly between the
-front and backend domain using the new shared ring and event channel.
-
-(9) The frontend sends a BLKIF_OP_PROBE directly to the backend.
-
-  This message includes a reference to an additional page, that the
-  backend can use for it's reply.  The backend responds with an array
-  of the domains disks (as vdisk_t structs) on the provided page.
-
-The frontend now initialises each disk, calling xlvbd_init_device()
-for each one.
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/cpuid-config-for-guest.txt
--- a/docs/misc/cpuid-config-for-guest.txt	Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,23 +0,0 @@
-CPUID emulation for guest
--------------------------
-
-When HVM guest tries to execute CPUID, or PV guest tries to execute XEN_CPUID,
-the xen hypervior traps and emultes them.
-
-For HVM guest and PV DomU guest, xen's CPUID emulation can be adjusted using
-the guest configation file if necessary (e.g., to supply better support for
-guest live migration). The CPUID syntax in guest configration file is
-described in detail in the examples like /etc/xen/xmexample.hvm,
-/etc/xen/xmexample.hvm-stubdom.
-
-However, a user (or an administrator) must be aware that the CPUID in guest
-configuration file can NOT be configured casually. The default CPUID
-configuration should be safe, but illegal configuration can cause unexpected
-behaviors of guest -- even can crash guest.
-
-For example, we should not expose the MONITOR CPUID feature flag (ECX bit 3;
-CPUID executed EAX = 1) to HVM guest, otherwise, on guest's attempt of
-executing MWAIT, the VMExit handler in Xen would inject #UD (Invalid Opcode
-Exception) into the HVM guest, and guest kernel would panic.
-
-/* We can add more unsafe CPUID configuration here in future. */
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/hg-cheatsheet.txt
--- a/docs/misc/hg-cheatsheet.txt	Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,438 +0,0 @@
-
-Mercurial(hg) Cheatsheet for Xen
-================================
-
-Written by Andrew Warfield, extended by Michael Fetterman and Ian Pratt
-June 29, 2005, extended by Grzegorz Milos 04 July 2005.
-
-Overview
---------
-The Xen project has moved from BitKeeper to Mercurial for source
-control.  This note aims to provide a quick guide to getting up and
-running with the new tools as quickly as possible, and is written from
-the perspective of someone who has been using BK.
-
-For a more detailed exposition, see the mercurial tutorial:
- http://www.serpentine.com/mercurial/index.cgi?Tutorial
-
-The Hg manpage is available at:
- http://www.selenic.com/mercurial/hg.1.html
-
-There's also a very useful FAQ that explains the terminology:
- http://www.selenic.com/mercurial/FAQ.html
-
-There's also a good README:
- http://www.selenic.com/mercurial/README
-
-Necessary software
-------------------
-Mercurial is available at:
-  http://www.selenic.com/mercurial/ 
-
-You will also need a Python version >= 2.3
-
-How Mercurial is different from BK
-----------------------------------
-There are several pertinent differences between hg and bk.  This
-section aims to give an overview of the conceptual differences between
-the two SCMs -- if you just want examples to get going, skip ahead to
-"Getting Xen". The key differences are:
-
-  - No explicit per-file locking.  You do not need to explicitly 
-    check a file out before editing it.
-  - No notion (currently) of file renames.
-  - A repository can have multiple active heads.
-  - Automatic merge support is currently inferior to BK's.
-  - No graphical tools.
-  - No per-file revision history, only per-changeset (we never really used this anyhow)
-  - Hg repositories tend to be rather bigger than Bk ones, but Hg does seem faster.
-
-Mercurial is based on the notion of changesets as complete, immutable,
-versions of the repository.  You make changes to a working version of
-the repository that is based on a particular changeset.  When you
-commit, you will generate a new child changeset with whatever changes
-you choose to apply.
-
-A major difference between Hg and BK is that you aren't forced to
-resolve conflicts immediately: BK forced you to resolve conflicts
-immediately on any merge, and it then immediately created a changeset
-with those conflicts' resolutions.  Frequently, you then had to add
-yet another changeset to fixup the things for which the automatic
-merge yielded bad results. Hg puts the results of the merge into your
-work directory, and remembers what you merged with (so that it can
-later record both of the merge parents, if you decide to make a
-changeset), but it doesn't immediately create a changeset.
-
-A further feature of Hg is that it allows a repository to have
-multiple heads. This means that you can have changesets with no common
-descendent in one repository -- something BK won't allow. This is
-actually pretty neat. For example, it would in principle enable you to
-have both the 2.0-testing and unstable trees in a single
-repository. We shyed away from doing this as we thought the risk of
-committing to the wrong head was too great.
-
-One slightly confusing aspect of Hg is that many of the commands have
-aliases, and hence when looking things up in the man page its not
-always obvious what the underlying command is. For example 'co' is
-actually an alias for the 'update' command, but 'co' seems to make
-more sense, at least to RCS refugees like me.
-
-
-Getting Xen
------------
-
-The URL for the mainline Xen mercurial repository is:
-
-   http://xenbits.xensource.com/xen-unstable.hg
-   (similarly for xen-2.0 and xen-2.0-testing)
-
-You can point a browser and this and use Hg's web interface to view
-revision history, or use it as the nominated source when issuing
-"hg init" or "hg pull" commands. 
-
-However, to avoid taxing the Mercurial server with a complete pull of
-the Xen repository, it is best to download a tarball of a seed
-repository from:
- 
-  http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-unstable.hg.tar.gz
-
-  (or copy from /usr/groups/netos/html/xen/downloads/xen-unstable.hg.tar.gz)
-
-Untar the repository on your disk, cd into it, and then pull the most
-recent changes:
-
-  hg pull -u
-
-By default hg does not automatically checkout ('update') files from
-the repository as used to happen with bk. The above is equivalent to
-"hg pull; hg co"
-
-The repository parent is stored in a repository configuration file, 
-.hg/hgrc, from the repository root.  If you look at this file, you 
-will see:
-
-  |  [paths]
-  |  default = http://xenbits.xensource.com/xen-unstable.hg
-
-"default" specifies the appropriate parent repository for hg to pull 
-from.  Hg allows you to pull additional repositories, for instance if 
-you want to work between unstable and testing concurrently.
-
-The command "hg pull" simply adds changesets to your repository,
-without any merging of any kind.  "hg pull -u" implies merging with
-the current state of your working directory.  If you weren't already
-"updated" to your local repository's tip, you might be surprised to
-find yourself merging the results of the pull with a non-tip node in
-your local repository. 
-
-
-Revision History
-----------------
-
-You can view the repository revision history with:
-
-   hg history
-
-In practice, you'll probably want to use pipe the output through
-'head' or 'more' as it prints the entire history.
-
-Looking at the first few lines of output, you can see the changeset at
-the head of the current branch, known as the 'tip' (the tip is
-automatically given a special tag to make it easy to refer to):
-
-   | changeset:   5599:6cbf9ec05cd9e05c0c46a85df7fc00262633cd3d
-   | tag:         tip
-   | user:        kaf24@firebug.cl.cam.ac.uk
-   | date:        Tue Jun 28 18:47:14 2005
-   | summary:     bitkeeper revision 1.1768 (42c18d2259NPELcGV7ohyZNh72ufSw)
-
-By default, Hg just shows the first line of the changset comments. You
-can find further information with "hg -v history".
-
-The changeset identifier has two parts, a _local_ monotonically
-increasing changeset id, 5599 above, and a _global_ hash, which
-follows the colon on the changeset line.  The hash uniquely identifies
-the changeset and its lineage back to the root of the changeset tree
--- it is useful for distributed management and so on.  However, as it
-is a bit unruly, the local id will allow you to work easily with the
-local repo. Hg commands will take either identifier. Additionally, a
-tags mechanism lets you give common names to specific changesets.
-
-You should always use the global hash when referring to versions of
-the mainline Xen respoitory. With Bk you could often get away with
-using the shortform version, but with Hg the local ids are pretty much
-guaranteed to be different.
-
-
-Creating a child repository from an existing repository
--------------------------------------------------------
-If you wanted to create additional local child repositories,
-
-   hg init [path or url]
-
-is effectively equivalent to bk clone.  The major difference is that 
-it should be run from the root of your new repository.  So:
-
-   bk clone /foo/bar
-
-would be replaced with:
-
-   mkdir bar
-   cd bar
-   hg init /foo/bar
-
-NB: newer version of Hg support a 'clone' command that works in the
-same manner as bk.
-
-Editing files
--------------
-
-Normal edits may be made in place.  File creation needs explicit
-marking, though deletes should be picked up automatically
-
-creation:
-
-   touch a.txt (or otherwise created a file)
-   hg add a.txt
-
-You can see what has changed using:
-
-   hg status
-
-   | C foo/foo.c
-   | R foo/bar.c
-   | ? a.txt
-
-This shows that in the current repo, foo.c has been changed, bar.c has
-been deleted, and a.txt is new, but has not been added.  '?' changes
-to 'A' after "hg add a.txt". There is a .hgignore file which contains
-regexps of files that should be ignored when scanning for new
-files. We try to ensure that all the generated files in a build are
-covered by the regexps.
-
-You can add all the new files in a repository with "hg addremove". If
-you discover that you've added a file you didn't want, you can remove
-it from the list of files to be included in the next commit using
-"hg forget".
-
-Committing changes
------------------
-
-After you've checked that hg knows about any new files you've created,
-you probably want to see a diff of what you're about to commit. You
-can do this with:
-   
-   hg diff
-
-Once you're happy with what you have, invoke:
-
-   hg commit
-
-This will pop up an editor with a list of files to be committed to the
-repository.  It will look vaguely like this:
-
-   | 
-   | HG: manifest hash 6397b04bd5c2a992482d973b685a7e5e498788e7
-   | HG: changed doc/thesis/new.tex
-   | HG: removed doc/2005-hotdep-protection/paper.tex
-
-Your comments can go anywhere in this file.  The first line is the 
-most important, as it will show as the changeset description in 
-non-verbose-mode history listings.
-
-You can do commits without the editor and of partial sets of files 
-using command-line switches. See:
-
-   hg help commit
-
-You can use the -A (--addremove) flag to commit e.g. "hg -A commit" to
-ask mercurial to scan the tree looking for newly created files to add
-in to the changeset. This avoids having to explicitly use "hg add",
-but you probably want to be careful of adding any new generated files
-too.
-
-
-Generating a patch
-------------------
-Generating a patch is easy,
-
-   hg export [changeset]
-
-will generate a patch describing the diff between that changeset and 
-its parent.
-    
-To generate a patch between two specified revisions use:
-   hg diff -r A -r B [files]
-NB: BK syntax -rA..B isn't supported by Hg.   
-
-
-Pushing changesets to a parent repository
------------------------------------------
-
-   hg push
-
-Pushes changes up to a parent. You can't push if you pulled the
-repository off the web interface. In fact, you can currently only push
-to an ssh target -- filesystem directory targets don't work, but this
-will be fixed soon.
-For now it is possible to set up asymmetric pull/push paths. Pulls can
-be done via web interface while pushes via ssh. Example of .hg/hgrc config
-file:
-  | [paths]
-  | default = http://your.server/repository_name
-  | default-push = ssh://[username@]your.server//repository_location
-
-
-Repository history
-------------------
-
-Here are a collection of common commands to get you started:
-
-   hg history | less
-
-shows the history of changesets, starting from the most recent.  You 
-want to pipe it to some sort of pager.  For more complete details,
- 
-   hg -v history | less
-
-will include files modified and full (not just first-line) comments.
-
-Additionally, you can see just the tip (head of the current
-branch) of the repository by typing:
-
-   hg [-v] tip
-
-
-Moving to a specific changeset
-------------------------------
-
-The co command lets you change the working version of the repository
-to a different changeset. 
-
-   hg co [changeset]
-
-NB: 'co' is an alias for 'update'
-
-This command enables you to rewind the working repository to previous
-changesets, for example to isolate the changeset in which a bug is
-introduced.
-
-If you try and do a 'co' but have modified files in your repository Hg
-won't let you unless you ask it explicitly to merge the checked out
-version into the current tree using the "-m" option. The "-C"
-(--clean) option will force overwrite any locally modified files.
-
-Any commits that are made to non-head changesets will obviously fork
-the tree, creating a new head. You can see all the heads in a tree with
-"hg heads".
-
-In general, "hg co" does the right thing, although it doesn't
-currently seem to clean up unused directories that have been created
-by other checked-out versions. This can confuse the Xen build
-system. Hg will probably get fixed soon, but in the meantime you can
-cleanup with "find -depth -type d -print | xargs -r rmdir".
-
-You can return to the tip by omitting an explicit changeset id.
-   
-The manifest command lets you see the contents of the repository for 
-the current changeset.
-
-   hg manifest
-
-This will print a bunch of records of the form: 
-
-   | 98856c45c35a504bc6da06a62b7787ddfdfd1c8b 644 COPYING
-   | f28971eedc5b54e7a9b26dd18d52992955354981 644 Config.mk
-   | a3575cc4db59e50bbac8a039a0c74f081a8dfc4f 644 Makefile
-   | 7fc869aae2945a9f4626fad96552db3103e61cb9 644 README
-   | ...
-
-This lists the hash of each file, its 1-bit 'executable' attribute
-(either file permission mode 644 or 755), and the file name.  So, to
-determine the files that change across two changesets, you would dump
-the respective manifests to files, and use diff.
-
-
-Managing changeset tags
------------------------
-To create a tag to the current changeset:
-
-   hg tag tagname
-
-This will _immediately_ generate a changeset with a change to the file
-.hgtags in the repository root.   The new tag in this file will look
-something like:
-
-   | 35159ed4b30538e7a52c60ad0a63f7e9af156e4c tagname
-
-and may be used to identify that changeset throughout the repo.
-Storing tags in this file and generating changesets immediately 
-forces people to merge and keep tags up to date across the repository.
-
-Note that tags are resolved by searching .hgtags in each of the 
-repository heads, sequentially, and using the first match.  "hg heads"
-lists the current heads.
-
-The "hg tags" command, will lists all the currently valid tags.
-
-
-Hg server and source browser
-----------------------------
-
-   hg serve -p port
-
-Launches a web server on the specified port, serving a source browser 
-for the repository.  This browser may be used to examine the 
-changeset history, view annotated source files, generate diffs.  
-Additionally "hg pull" may be run against it.
-
-Additional useful commands
-(that probably only need one-line descriptions)
------------------------------------------------
-
-(Slightly) more detail on all of these is available with
-
-  hg help [command]
-
-Shows the differences between whatever changeset you most recently
-checked out, and your current working directory:
-
-   hg diff 
-
-View an annotated version of a source file:
-
-   hg annotate
-
-Get a historical version of a file:
-
-   hg cat
-
- NB: Most commands accepting a version number want the changeset's
- version number.  "hg cat" is different in that it wants the
- *file*'s version number.
-
-Unadd a file to the current commit:
-
-   hg forget
-
-List all heads in the current repository:
-
-   hg heads
-
-Undo exactly one (and ONLY one) changeset:
-
-   hg undo
-
-Show the parents of a changeset:
-
-   hg parents
-
- NB: Changesets have either one or two parent changesets. If your
- working directory contains the uncommitted results of a merge, then
- you have two parents.  Otherwise, the single parent is the changeset
- which you most recently checked out.
-
-Show the revision history for a single file
-
-   hg [-v] log <filename>
-
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/network_setup.txt
--- a/docs/misc/network_setup.txt	Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,196 +0,0 @@
-Native OS bridge configuration
-==============================
-
-The traditional "network-bridge" script attempts to modify existing active
-network interfaces to enable bridging. For non-trivial network configurations
-though this can be error prone, and the temporary disruption to network
-connectivity can upset some applications.  This document outlines how to
-configure bridging using an OS' native network configuration files.
-
-Disabling Xen's network scripts
--------------------------------
-
-The first step is to check XenD's network bridge is disabled by
-editing /etc/xen/xend-config.sxp and changing the line
-
- (network-script network-bridge)
-
-To be
-
- (network-script /bin/true)
-
-
-Fedora/RHEL Bridging
-====================
-
-This outlines how to setup bridging using standard network initscripts
-present in Fedora or RHEL distros and their derivatives
-
-
-Disabling NetworkManager
-------------------------
-
-As of time of writing (Fedora 14) NetworkManager does not support bridging,
-so it is neccessary to disable NetworkManager, and revert to "classic"
-network initscripts
-
- # chkconfig NetworkManager off
- # chkconfig network on
- # service NetworkManager stop
- # service network start
-
-NB, as an alternative to turning off NetworkManager, you can also add a line
-"NM_CONTROLLED=no" to the ifcfg-XXX scripts below
-
-Creating network initscripts
-----------------------------
-
-In the /etc/sysconfig/network-scripts directory it is necccessary to create
-2 config files. The first (ifcfg-eth0) defines your physical network interface,
-and says that it will be part of a bridge:
-
-# cat > ifcfg-eth0 <<EOF
-DEVICE=eth0
-HWADDR=00:16:76:D6:C9:45
-ONBOOT=yes
-BRIDGE=br0
-EOF
-
-Obviously change the HWADDR to match your actual NIC's address. You may also
-wish to configure the device's MTU here using e.g. MTU=9000.
-
-The second config file (ifcfg-br0) defines the bridge device:
-
-# cat > ifcfg-br0 <<EOF
-DEVICE=br0
-TYPE=Bridge
-BOOTPROTO=dhcp
-ONBOOT=yes
-DELAY=0
-EOF
-
-WARNING: The line TYPE=Bridge is case-sensitive - it must have uppercase
-'B' and lower case 'ridge'
-
-After changing this restart networking (or better still reboot)
-
- # service network restart
-
-
-The final step is to configure iptables to allow all traffic to be
-forwarded across the bridge
-
-# echo "-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT" > /etc/sysconfig/iptables-forward-bridged
-# lokkit --custom-rules=ipv4:filter:/etc/sysconfig/iptables-forward-bridged
-# service libvirtd reload
-
-Alternatively, you can prevent bridged traffic getting pushed through
-the host's iptables rules completely. In /etc/sysctl.conf add
-
- # cat >> /etc/sysctl.conf <<EOF
- net.bridge.bridge-nf-call-ip6tables = 0
- net.bridge.bridge-nf-call-iptables = 0
- net.bridge.bridge-nf-call-arptables = 0
- EOF
- # sysctl -p /etc/sysctl.conf
-
-You should now have a "shared physical device", to which guests can be
-attached and have full LAN access
-
- # brctl show
- bridge name     bridge id               STP enabled     interfaces
- br0             8000.000e0cb30550       no              eth0
-
-
-
-Debian/Ubuntu Bridging
-=======================
-
-This outlines how to setup bridging using standard network interface config files
-on Debian / Ubuntu distributions and their derivatives
-
-Disabling NetworkManager
-------------------------
-
-Stop network manager
-
- sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher stop
- sudo /etc/dbus-1/event.d/25NetworkManager stop
-
-Create two files with only the word 'exit' in them. These files are:
-
- /etc/default/NetworkManager
- /etc/default/NetworkManagerDispatcher
-
-
-Altering the interface config
------------------------------
-
-First take down the interface you wish to bridge
-
- ifdown eth0
-
-Edit /etc/network/interfaces and find the config for the physical
-interface, which looks something like
-
- allow-hotplug eth0
- iface eth0 inet static
-        address 192.168.2.4
-        netmask 255.255.255.0
-        network 192.168.2.0
-        broadcast 192.168.2.255
-        gateway 192.168.2.2
-
-Remove the 'allow-hotplug eth0' line, replacing it with 'auto br0',
-and change the next line with iface name to 'br0', so it now starts
-with
-
- auto br0
- iface br0 inet static
-
-And then define the interface as being a bridge and specify its ports
-
-       bridge_ports eth0
-       bridge_stp off
-       bridge_maxwait 5
-
-The complete config should now look like
-
- auto br0
- iface br0 inet static
-         address 192.168.2.4
-         netmask 255.255.255.0
-         network 192.168.2.0
-         broadcast 192.168.2.255
-         gateway 192.168.2.2
-         bridge_ports eth0
-         bridge_stp off
-         bridge_maxwait 5
-
-The interface can now be started with
-
- ifup br0
-
-Finally add the '/etc/sysctl.conf' settings
-
-net.bridge.bridge-nf-call-ip6tables = 0
-net.bridge.bridge-nf-call-iptables = 0
-net.bridge.bridge-nf-call-arptables = 0
-
-And then load the settings with
-
- sysctl -p /etc/sysctl.conf
-
-
-You should now have a "shared physical device", to which guests
-can be attached and have full LAN access
-
- # brctl show
- bridge name     bridge id               STP enabled     interfaces
- br0             8000.000e0cb30550       no              eth0
-
-
-Other operating systems / distributions
-=======================================
-
-[...send patches to this file with instructions....]

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:37:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:37:08 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR41U-00025T-C8
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR41C-0001uL-SM; Thu, 17 Nov 2011 07:36:50 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TY-0002Qw-0B
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:34 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321542111!1984114!6
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16870 invoked from network); 17 Nov 2011 15:01:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:01:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19189112"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:01:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:01:59 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNK026208;	Thu, 17 Nov 2011 07:01:57 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 55ce23cb7b2af3c497b3a10658e09d5fc11eb45f
Message-ID: <55ce23cb7b2af3c497b3.1321542117@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:57 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 11 of 17] docs: remove some fatally out of date
	documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321541678 0
# Node ID 55ce23cb7b2af3c497b3a10658e09d5fc11eb45f
# Parent  617f5d6e9e69b4f6362df91f078b7dc2abdbd80a
docs: remove some fatally out of date documentation

I think these are better off deleted than remaining to confuse people.

docs/misc/blkif-drivers-explained.txt:

 - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.

docs/misc/cpuid-config-for-guest.txt:

 - Doesn't really say anything, in particular doesn't actually describe how to
   configure CPUID.

docs/misc/hg-cheatsheet.txt:

 - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
   under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
   hardly unusual anymore I think there must be better guides out there so this
   one is not worth resurecting.

docs/misc/network_setup.txt:

 - This is more comprehensively documented on the wiki these days.

docs/misc/VMX_changes.txt:

 - Is basically a changelog from the initial implementation of VMX in 2004.

I'm not sure about some of the other docs, but these ones seemed fairly
obvious.

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

diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/VMX_changes.txt
--- a/docs/misc/VMX_changes.txt	Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,90 +0,0 @@
-Changes to Xen in support of Intel(R) Vanderpool Technology
--------------------------------------------------------------
-
-Our VT extensions to the Xen hypervisor provide full platform
-virtualization, including CPU(s), memory, and I/O infrastructure. The
-generic code in Xen handles and schedules those virtual machines as it
-does for the existing para-virtualized domains.
-
-Full virtualization required by the OS guests requires full device
-virtualization as well. The device models in BOCHS
-(http://bochs.sourceforge.net/) were decoupled from the CPU
-virtualization, and are used to virtualize the legacy devices (such as
-keyboard, mouse, VGA, IDE) in the PC platform. At this point, the
-device models run in user mode on domain 0, not in the Xen hypervisor.
-
-We would like to thank Ian Pratt and Keir Fraser for reviewing our
-design and code intensively, and for providing numerous useful
-suggestions to improve the architecture and code. 
-
-We have a list of Intel team members who take credit for making this
-release happen: Yunhong Jiang, Nitin Kamble, Chengyuan Li, Xin Li,
-Xiaofeng Ling, Benjamin Liu, Asit Mallick, Jun Nakajima, Sunil Saxena,
-Arun Sharma, Edwin Zhai, Jeff Zheng, and Louis Zhuang. We'll continue
-to add more features to complete full virtualization in Xen using VT.
-
-The notes document the changes to the Xen hypervisor in order to add
-VT support. The changes to other areas, such as Control Panel will be
-added as we deliver the code.
-
-Summary of changes for the first release
-----------------------------------------
-December 15, 2004
-
-    * VT specific event handling and domain management were added. 
-
-    * Shadow mode was extended to support full 32-bit guests
-    
-    * Domain switching code was extended to support VT domain
-    
-    * I/O request handling was added to communicate with the device model
-
-    * Domain builder was extended to provide the environment when the
-      guest enters the protected mode, including E820 memory and VGA
-      info, typically obtained by BIOS calls.
-
-New code:
----------
-    VT (Vanderpool Technology) is based on the new VMX (Virtual
-    Machine Extensions) architecture. The current release of the
-    software supports 32-bit only.
-
-    * arch/x86/vmx.[ch] and arch/x86/vmx_*.[ch]: created to handle
-      VMX-specific events in order to provide virtual machine.
-
-    * arch/x86/x86_32/entry.S: new code path was added to have the
-      first-level handler from VM exits. The first-level handler calls
-      the second-level handler in arch/x86/vmx.c.
-
-    * arch/x86/setup.c: new function start_vmx() to init_intel() to
-      enable VMX mode.
-
-    * include/asm-x86/config.h: #ifdef CONFIG_VMX was added.
-
-    * arch/x86/domain.c: new code patch was added to create a VMX
-      domain given the flag from the control panel.
-
-    * include/public/io/ioreq.h: A new data structure was added to
-      define the I/O requests between the Xen hypervisor and the
-      device models.
-
-Changes to the existing code:
------------------------------
-
-    * arch/x86/shadow.[ch]: new mode SHM_full_32 was added to support
-      full virtualization. The current Xen code assumes that the guest
-      page directory and tables have _machine_ (or host) physical page
-      frame numbers, and the new code allows to support _guest_
-      physical page frame numbers
-
-    * include/asm-x86/processor.h: struct arch_vmx_struct arch_vmx has
-      been added to the thread_struct data structure. The arch_vmx has
-      the additional VMX-related CPU context.
-
-    * arch/x86/io_apic.c: reverse mapping between vector and irq has
-      been added. We will revisit this code when considering MSI
-      support.
-
---- Jun
-
-
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/blkif-drivers-explained.txt
--- a/docs/misc/blkif-drivers-explained.txt	Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,485 +0,0 @@
-=== How the Blkif Drivers Work ===
-Andrew Warfield
-andrew.warfield@cl.cam.ac.uk
-
-The intent of this is to explain at a fairly detailed level how the
-split device drivers work in Xen 1.3 (aka 2.0beta).  The intended
-audience for this, I suppose, is anyone who intends to work with the
-existing blkif interfaces and wants something to help them get up to
-speed with the code in a hurry.  Secondly though, I hope to break out
-the general mechanisms that are used in the drivers that are likely to
-be necessary to implement other drivers interfaces.
-
-As a point of warning before starting, it is worth mentioning that I
-anticipate much of the specifics described here changing in the near
-future.  There has been talk about making the blkif protocol
-a bit more efficient than it currently is.  Keir's addition of grant
-tables will change the current remapping code that is used when shared
-pages are initially set up.
-
-Also, writing other control interface types will likely need support
-from Xend, which at the moment has a steep learning curve... this
-should be addressed in the future.
-
-For more information on the driver model as a whole, read the
-"Reconstructing I/O" technical report
-(http://www.cl.cam.ac.uk/Research/SRG/netos/papers/2004-xenngio.pdf).
-
-==== High-level structure of a split-driver interface ====
-
-Why would you want to write a split driver in the first place?  As Xen
-is a virtual machine manager and focuses on isolation as an initial
-design principle, it is generally considered unwise to share physical
-access to devices across domains.  The reasons for this are obvious:
-when device resources are shared, misbehaving code or hardware can
-result in the failure of all of the client applications.  Moreover, as
-virtual machines in Xen are entire OSs, standard device drives that
-they might use cannot have multiple instantiations for a single piece
-of hardware.  In light of all this, the general approach in Xen is to
-give a single virtual machine hardware access to a device, and where
-other VMs want to share the device, export a higher-level interface to
-facilitate that sharing.  If you don't want to share, that's fine.
-There are currently Xen users actively exploring running two
-completely isolated X-Servers on a Xen host, each with it's own video
-card, keyboard, and mouse.  In these situations, the guests need only
-be given physical access to the necessary devices and left to go on
-their own.  However, for devices such as disks and network interfaces,
-where sharing is required, the split driver approach is a good
-solution.
-
-The structure is like this:
-
-   +--------------------------+  +--------------------------+
-   | Domain 0 (privileged)    |  | Domain 1 (unprivileged)  |
-   |                          |  |                          |
-   | Xend ( Application )     |  |                          |
-   | Blkif Backend Driver     |  | Blkif Frontend Driver    |
-   | Physical Device Driver   |  |                          |
-   +--------------------------+  +--------------------------+
-   +--------------------------------------------------------+
-   |                X       E       N                       |
-   +--------------------------------------------------------+
-
-
-The Blkif driver is in two parts, which we refer to as frontend (FE)
-and a backend (BE).  Together, they serve to proxy device requests
-between the guest operating system in an unprivileged domain, and the
-physical device driver in the physical domain.  An additional benefit
-to this approach is that the FE driver can provide a single interface
-for a whole class of physical devices.  The blkif interface mounts
-IDE, SCSI, and our own VBD-structured disks, independent of the
-physical driver underneath.  Moreover, supporting additional OSs only
-requires that a new FE driver be written to connect to the existing
-backend.
-
-==== Inter-Domain Communication Mechanisms ====
-
-===== Event Channels =====
-
-Before getting into the specifics of the block interface driver, it is
-worth discussing the mechanisms that are used to communicate between
-domains.  Two mechanisms are used to allow the construction of
-high-performance drivers: event channels and shared-memory rings.
-
-Event channels are an asynchronous interdomain notification
-mechanism.  Xen allows channels to be instantiated between two
-domains, and domains can request that a virtual irq be attached to
-notifications on a given channel.  The result of this is that the
-frontend domain can send a notification on an event channel, resulting
-in an interrupt entry into the backend at a later time.
-
-The event channel between two domains is instantiated in the Xend code
-during driver startup (described later).  Xend's channel.py
-(tools/python/xen/xend/server/channel.py) defines the function
-
-
-def eventChannel(dom1, dom2):
-    return xc.evtchn_bind_interdomain(dom1=dom1, dom2=dom2)
-
-
-which maps to xc_evtchn_bind_interdomain() in tools/libxc/xc_evtchn.c,
-which in turn generates a hypercall to Xen to patch the event channel
-between the domains.  Only a privileged domain can request the
-creation of an event channel.
-
-Once the event channel is created in Xend, its ends are passed to both the
-front and backend domains over the control channel.  The end that is
-passed to a domain is just an integer "port" uniquely identifying the
-event channel's local connection to that domain.  An example of this
-setup code is in linux-2.6.x/drivers/xen/blkfront/blkfront.c in
-blkif_connect(), which receives several status change events as
-the driver starts up.  It is passed an event channel end in a
-BLKIF_INTERFACE_STATUS_CONNECTED message, and patches it in like this:
-
-
-   blkif_evtchn = status->evtchn;
-   blkif_irq    = bind_evtchn_to_irq(blkif_evtchn);
-   if ( (rc = request_irq(blkif_irq, blkif_int, 
-                          SA_SAMPLE_RANDOM, "blkif", NULL)) )
-       printk(KERN_ALERT"blkfront request_irq failed (%ld)\n",rc);
-
-
-This code associates a virtual irq with the event channel, and
-attaches the function blkif_int() as an interrupt handler for that
-irq.  blkif_int() simply handles the notification and returns, it does
-not need to interact with the channel at all.
-
-An example of generating a notification can also be seen in blkfront.c:
-
-
-static inline void flush_requests(void)
-{
-    DISABLE_SCATTERGATHER();
-    wmb(); /* Ensure that the frontend can see the requests. */
-    blk_ring->req_prod = req_prod;
-    notify_via_evtchn(blkif_evtchn);
-}
-}}}
-
-notify_via_evtchn() issues a hypercall to set the event waiting flag on
-the other domain's end of the channel.
-
-===== Communication Rings =====
-
-Event channels are strictly a notification mechanism between domains.
-To move large chunks of data back and forth, Xen allows domains to
-share pages of memory.  We use communication rings as a means of
-managing access to a shared memory page for message passing between
-domains.  These rings are not explicitly a mechanism of Xen, which is
-only concerned with the actual sharing of the page and not how it is
-used, they are however worth discussing as they are used in many
-places in the current code and are a useful model for communicating
-across a shared page.
-
-A shared page is set up by a front end guest first allocating and passing 
-the address of a page in its own address space to the backend driver.  
-
-Consider the following code, also from blkfront.c.  Note:  this code
-is in blkif_disconnect().  The driver transitions from STATE_CLOSED
-to STATE_DISCONNECTED before becoming CONNECTED.  The state automata
-is in blkif_status().
-
-   blk_ring = (blkif_ring_t *)__get_free_page(GFP_KERNEL);
-   blk_ring->req_prod = blk_ring->resp_prod = resp_cons = req_prod = 0;
-   ...
-   /* Construct an interface-CONNECT message for the domain controller. */
-   cmsg.type      = CMSG_BLKIF_FE;
-   cmsg.subtype   = CMSG_BLKIF_FE_INTERFACE_CONNECT;
-   cmsg.length    = sizeof(blkif_fe_interface_connect_t);
-   up.handle      = 0;
-   up.shmem_frame = virt_to_machine(blk_ring) >> PAGE_SHIFT;
-   memcpy(cmsg.msg, &up, sizeof(up));  
-
-
-blk_ring will be the shared page.  The producer and consumer pointers
-are then initialised (these will be discussed soon), and then the
-machine address of the page is send to the backend via a control
-channel to Xend.  This control channel itself uses the notification
-and shared memory mechanisms described here, but is set up for each
-domain automatically at startup.
-
-The backend, which is a privileged domain then takes the page address
-and maps it into its own address space (in
-linux26/drivers/xen/blkback/interface.c:blkif_connect()):
-
-
-void blkif_connect(blkif_be_connect_t *connect)
-
-   ...
-   unsigned long shmem_frame = connect->shmem_frame;
-   ...
-
-   if ( (vma = get_vm_area(PAGE_SIZE, VM_IOREMAP)) == NULL )
-   {
-      connect->status = BLKIF_BE_STATUS_OUT_OF_MEMORY;
-      return;
-   }
-
-   prot = __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED);
-   error = direct_remap_area_pages(&init_mm, VMALLOC_VMADDR(vma->addr),
-                                   shmem_frame<<PAGE_SHIFT, PAGE_SIZE,
-                                   prot, domid);
-
-   ...
-
-   blkif->blk_ring_base = (blkif_ring_t *)vma->addr
-}}}
-
-The machine address of the page is passed in the shmem_frame field of
-the connect message.  This is then mapped into the virtual address
-space of the backend domain, and saved in the blkif structure
-representing this particular backend connection.
-
-NOTE:  New mechanisms will be added very shortly to allow domains to
-explicitly grant access to their pages to other domains.  This "grant
-table" support is in the process of being added to the tree, and will
-change the way a shared page is set up.  In particular, it will remove
-the need of the remapping domain to be privileged.
-
-Sending data across shared rings:
-
-Shared rings avoid the potential for write interference between
-domains in a very cunning way.  A ring is partitioned into a request
-and a response region, and domains only work within their own space.
-This can be thought of as a double producer-consumer ring -- the ring
-is described by four pointers into a circular buffer of fixed-size
-records.  Pointers may only advance, and may not pass one another.
-
-
-                         resp_cons----+
-                                      V
-           +----+----+----+----+----+----+----+
-           |    |    |  free(A)     |RSP1|RSP2|
-           +----+----+----+----+----+----+----+
- req_prod->|    |       -------->        |RSP3|
-           +----+                        +----+
-           |REQ8|                        |    |<-resp_prod
-           +----+                        +----+
-           |REQ7|                        |    |
-           +----+                        +----+
-           |REQ6|       <--------        |    |
-           +----+----+----+----+----+----+----+
-           |REQ5|REQ4|    free(B)   |    |    |
-           +----+----+----+----+----+----+----+
-  req_cons---------^
-
-
-
-By adopting the convention that every request will receive a response,
-not all four pointers need be shared and flow control on the ring
-becomes very easy to manage.  Each domain manages its own
-consumer pointer, and the two producer pointers are visible to both
-(xen/include/public/io/blkif.h):
-
-
-/* NB. Ring size must be small enough for sizeof(blkif_ring_t) <=PAGE_SIZE.*/
-  #define BLKIF_RING_SIZE        64
-
-  ...
-
-/*
- * We use a special capitalised type name because it is _essential_ that all
- * arithmetic on indexes is done on an integer type of the correct size.
- */
-typedef u32 BLKIF_RING_IDX;
-
-/*
- * Ring indexes are 'free running'. That is, they are not stored modulo the
- * size of the ring buffer. The following macro converts a free-running counter
- * into a value that can directly index a ring-buffer array.
- */
-#define MASK_BLKIF_IDX(_i) ((_i)&(BLKIF_RING_SIZE-1))
-
-typedef struct {
-    BLKIF_RING_IDX req_prod;  /*  0: Request producer. Updated by front-end. */
-    BLKIF_RING_IDX resp_prod; /*  4: Response producer. Updated by back-end. */
-    union {                   /*  8 */
-        blkif_request_t  req;
-        blkif_response_t resp;
-    } PACKED ring[BLKIF_RING_SIZE];
-} PACKED blkif_ring_t;
-
-
-
-As shown in the diagram above, the rules for using a shared memory
-ring are simple.  
-
- 1. A ring is full when a domain's producer and consumer pointers are
-    equal (e.g. req_prod == resp_cons).  In this situation, the
-    consumer pointer must be advanced.  Furthermore, if the consumer
-    pointer is equal to the other domain's producer pointer,
-    (e.g. resp_cons = resp_prod), then the other domain has all the
-    buffers.
-
-2. Producer pointers point to the next buffer that will be written to.
-   (So blk_ring[MASK_BLKIF_IDX(req_prod)] should not be consumed.)
-
-3. Consumer pointers point to a valid message, so long as they are not
-   equal to the associated producer pointer.
-
-4. A domain should only ever write to the message pointed
-   to by its producer index, and read from the message at it's
-   consumer.  More generally, the domain may be thought of to have
-   exclusive access to the messages between its consumer and producer,
-   and should absolutely not read or write outside this region.
-
-   Thus the front end has exclusive access to the free(A) region 
-   in the figure above, and the back end driver has exclusive
-   access to the free(B) region.
-
-In general, drivers keep a private copy of their producer pointer and
-then set the shared version when they are ready for the other end to
-process a set of messages.  Additionally, it is worth paying attention
-to the use of memory barriers (rmb/wmb) in the code, to ensure that
-rings that are shared across processors behave as expected.
-
-==== Structure of the Blkif Drivers ====
-
-Now that the communications primitives have been discussed, I'll
-quickly cover the general structure of the blkif driver.  This is
-intended to give a high-level idea of what is going on, in an effort
-to make reading the code a more approachable task.
-
-There are three key software components that are involved in the blkif
-drivers (not counting Xen itself).  The frontend and backend driver,
-and Xend, which coordinates their initial connection.  Xend may also
-be involved in control-channel signalling in some cases after startup,
-for instance to manage reconnection if the backend is restarted.
-
-===== Frontend Driver Structure =====
-
-The frontend domain uses a single event channel and a shared memory
-ring to trade control messages with the backend.  These are both setup
-during domain startup, which will be discussed shortly.  The shared
-memory ring is called blkif_ring, and the private ring indexes are
-resp_cons, and req_prod.  The ring is protected by blkif_io_lock.
-Additionally, the frontend keeps a list of outstanding requests in
-rec_ring[].  These are uniquely identified by a guest-local id number,
-which is associated with each request sent to the backend, and
-returned with the matching responses.  Information about the actual
-disks are stored in major_info[], of which only the first nr_vbds
-entries are valid.  Finally, the global 'recovery' indicates that the
-connection between the backend and frontend drivers has been broken
-(possibly due to a backend driver crash) and that the frontend is in
-recovery mode, in which case it will attempt to reconnect and reissue
-outstanding requests.
-
-The frontend driver is single-threaded and after setup is entered only
-through three points:  (1) read/write requests from the XenLinux guest
-that it is a part of, (2) interrupts from the backend driver on its
-event channel (blkif_int()), and (3) control messages from Xend
-(blkif_ctrlif_rx).
-
-===== Backend Driver Structure =====
-
-The backend driver is slightly more complex as it must manage any
-number of concurrent frontend connections.  For each domain it
-manages, the backend driver maintains a blkif structure, which
-describes all the connection and disk information associated with that
-particular domain.  This structure is associated with the interrupt
-registration, and allows the backend driver to have immediate context
-when it takes a notification from some domain.
-
-All of the blkif structures are stored in a hash table (blkif_hash),
-which is indexed by a hash of the domain id, and a "handle", really a
-per-domain blkif identifier, in case it wants to have multiple connections.
-
-The per-connection blkif structure is of type blkif_t.  It contains
-all of the communication details (event channel, irq, shared memory
-ring and indexes), and blk_ring_lock, which is the backend mutex on
-the shared ring.  The structure also contains vbd_rb, which is a
-red-black tree, containing an entry for each device/partition that is
-assigned to that domain.  This structure is filled by xend passing
-disk information to the backend at startup, and is protected by
-vbd_lock.  Finally, the blkif struct contains a status field, which
-describes the state of the connection.
-
-The backend driver spawns a kernel thread at startup
-(blkio_schedule()), which handles requests to and from the actual disk
-device drivers.  This scheduler thread maintains a list of blkif
-structures that have pending requests, and services them round-robin
-with a maximum per-round request limit.  blkifs are added to the list
-in the interrupt handler (blkif_be_int()) using
-add_to_blkdev_list_tail(), and removed in the scheduler loop after
-calling do_block_io_op(), which processes a batch of requests.  The
-scheduler thread is explicitly activated at several points in the code
-using maybe_trigger_blkio_schedule().
-
-Pending requests between the backend driver and the physical device
-drivers use another ring, pending_ring.  Requests are placed in this
-ring in the scheduler thread and issued to the device.  A completion
-callback, end_block_io_op, indicates that requests have been serviced
-and generates a response on the appropriate blkif ring.  pending
-reqs[] stores a list of outstanding requests with the physical drivers.
-
-So, control entries to the backend are (1) the blkio scheduler thread,
-which sends requests to the real device drivers, (2) end_block_io_op,
-which is called as serviced requests complete, (3) blkif_be_int()
-handles notifications from the frontend drivers in other domains, and
-(4) blkif_ctrlif_rx() handles control messages from xend.
-
-==== Driver Startup ====
-
-Prior to starting a new guest using the frontend driver, the backend
-will have been started in a privileged domain.  The backend
-initialisation code initialises all of its data structures, such as
-the blkif hash table, and starts the scheduler thread as a kernel
-thread. It then sends a driver status up message to let xend know it
-is ready to take frontend connections.
-
-When a new domain that uses the blkif frontend driver is started,
-there are a series of interactions between it, xend, and the specified
-backend driver.  These interactions are as follows:
-
-The domain configuration given to xend will specify the backend domain
-and disks that the new guest is to use.  Prior to actually running the
-domain, xend and the backend driver interact to setup the initial
-blkif record in the backend.
-
-(1) Xend sends a BLKIF_BE_CREATE message to backend.
-
-  Backend does blkif_create(), having been passed FE domid and handle.
-  It creates and initialises a new blkif struct, and puts it in the
-  hash table.
-  It then returns a STATUS_OK response to xend.
-
-(2) Xend sends a BLKIF_BE_VBD_CREATE message to the backend.
- 
-  Backend adds a vbd entry in the red-black tree for the
-  specified (dom, handle) blkif entry.
-  Sends a STATUS_OK response.
-
-(3) Xend sends a BLKIF_BE_VBD_GROW message to the backend.
-
-  Backend takes the physical device information passed in the 
-  message and assigns them to the newly created vbd struct.
-
-(2) and (3) repeat as any additional devices are added to the domain.
-
-At this point, the backend has enough state to allow the frontend
-domain to start.  The domain is run, and eventually gets to the
-frontend driver initialisation code.  After setting up the frontend
-data structures, this code continues the communications with xend and
-the backend to negotiate a connection:
-
-(4) Frontend sends Xend a BLKIF_FE_DRIVER_STATUS_CHANGED message.
-
-  This message tells xend that the driver is up.  The init function
-  now spin-waits until driver setup is complete in order to prevent
-  Linux from attempting to boot before the disks are connected.
-
-(5) Xend sends the frontend an INTERFACE_STATUS_CHANGED message
-
-  This message specifies that the interface is now disconnected
-  (instead of closed).
-  The domain updates it's state, and allocates the shared blk_ring
-  page.  Next, 
-
-(6) Frontend sends Xend a BLKIF_INTERFACE_CONNECT message
-
-  This message specifies the domain and handle, and includes the
-  address of the newly created page.
-
-(7) Xend sends the backend a BLKIF_BE_CONNECT message
-
-  The backend fills in the blkif connection information, maps the
-  shared page, and binds an irq to the event channel.
-  
-(8) Xend sends the frontend an INTERFACE_STATUS_CHANGED message
-
-  This message takes the frontend driver to a CONNECTED state, at
-  which point it binds an irq to the event channel and calls
-  xlvbd_init to initialise the individual block devices.
-
-The frontend Linux is stall spin waiting at this point, until all of
-the disks have been probed.  Messaging now is directly between the
-front and backend domain using the new shared ring and event channel.
-
-(9) The frontend sends a BLKIF_OP_PROBE directly to the backend.
-
-  This message includes a reference to an additional page, that the
-  backend can use for it's reply.  The backend responds with an array
-  of the domains disks (as vdisk_t structs) on the provided page.
-
-The frontend now initialises each disk, calling xlvbd_init_device()
-for each one.
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/cpuid-config-for-guest.txt
--- a/docs/misc/cpuid-config-for-guest.txt	Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,23 +0,0 @@
-CPUID emulation for guest
--------------------------
-
-When HVM guest tries to execute CPUID, or PV guest tries to execute XEN_CPUID,
-the xen hypervior traps and emultes them.
-
-For HVM guest and PV DomU guest, xen's CPUID emulation can be adjusted using
-the guest configation file if necessary (e.g., to supply better support for
-guest live migration). The CPUID syntax in guest configration file is
-described in detail in the examples like /etc/xen/xmexample.hvm,
-/etc/xen/xmexample.hvm-stubdom.
-
-However, a user (or an administrator) must be aware that the CPUID in guest
-configuration file can NOT be configured casually. The default CPUID
-configuration should be safe, but illegal configuration can cause unexpected
-behaviors of guest -- even can crash guest.
-
-For example, we should not expose the MONITOR CPUID feature flag (ECX bit 3;
-CPUID executed EAX = 1) to HVM guest, otherwise, on guest's attempt of
-executing MWAIT, the VMExit handler in Xen would inject #UD (Invalid Opcode
-Exception) into the HVM guest, and guest kernel would panic.
-
-/* We can add more unsafe CPUID configuration here in future. */
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/hg-cheatsheet.txt
--- a/docs/misc/hg-cheatsheet.txt	Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,438 +0,0 @@
-
-Mercurial(hg) Cheatsheet for Xen
-================================
-
-Written by Andrew Warfield, extended by Michael Fetterman and Ian Pratt
-June 29, 2005, extended by Grzegorz Milos 04 July 2005.
-
-Overview
---------
-The Xen project has moved from BitKeeper to Mercurial for source
-control.  This note aims to provide a quick guide to getting up and
-running with the new tools as quickly as possible, and is written from
-the perspective of someone who has been using BK.
-
-For a more detailed exposition, see the mercurial tutorial:
- http://www.serpentine.com/mercurial/index.cgi?Tutorial
-
-The Hg manpage is available at:
- http://www.selenic.com/mercurial/hg.1.html
-
-There's also a very useful FAQ that explains the terminology:
- http://www.selenic.com/mercurial/FAQ.html
-
-There's also a good README:
- http://www.selenic.com/mercurial/README
-
-Necessary software
-------------------
-Mercurial is available at:
-  http://www.selenic.com/mercurial/ 
-
-You will also need a Python version >= 2.3
-
-How Mercurial is different from BK
-----------------------------------
-There are several pertinent differences between hg and bk.  This
-section aims to give an overview of the conceptual differences between
-the two SCMs -- if you just want examples to get going, skip ahead to
-"Getting Xen". The key differences are:
-
-  - No explicit per-file locking.  You do not need to explicitly 
-    check a file out before editing it.
-  - No notion (currently) of file renames.
-  - A repository can have multiple active heads.
-  - Automatic merge support is currently inferior to BK's.
-  - No graphical tools.
-  - No per-file revision history, only per-changeset (we never really used this anyhow)
-  - Hg repositories tend to be rather bigger than Bk ones, but Hg does seem faster.
-
-Mercurial is based on the notion of changesets as complete, immutable,
-versions of the repository.  You make changes to a working version of
-the repository that is based on a particular changeset.  When you
-commit, you will generate a new child changeset with whatever changes
-you choose to apply.
-
-A major difference between Hg and BK is that you aren't forced to
-resolve conflicts immediately: BK forced you to resolve conflicts
-immediately on any merge, and it then immediately created a changeset
-with those conflicts' resolutions.  Frequently, you then had to add
-yet another changeset to fixup the things for which the automatic
-merge yielded bad results. Hg puts the results of the merge into your
-work directory, and remembers what you merged with (so that it can
-later record both of the merge parents, if you decide to make a
-changeset), but it doesn't immediately create a changeset.
-
-A further feature of Hg is that it allows a repository to have
-multiple heads. This means that you can have changesets with no common
-descendent in one repository -- something BK won't allow. This is
-actually pretty neat. For example, it would in principle enable you to
-have both the 2.0-testing and unstable trees in a single
-repository. We shyed away from doing this as we thought the risk of
-committing to the wrong head was too great.
-
-One slightly confusing aspect of Hg is that many of the commands have
-aliases, and hence when looking things up in the man page its not
-always obvious what the underlying command is. For example 'co' is
-actually an alias for the 'update' command, but 'co' seems to make
-more sense, at least to RCS refugees like me.
-
-
-Getting Xen
------------
-
-The URL for the mainline Xen mercurial repository is:
-
-   http://xenbits.xensource.com/xen-unstable.hg
-   (similarly for xen-2.0 and xen-2.0-testing)
-
-You can point a browser and this and use Hg's web interface to view
-revision history, or use it as the nominated source when issuing
-"hg init" or "hg pull" commands. 
-
-However, to avoid taxing the Mercurial server with a complete pull of
-the Xen repository, it is best to download a tarball of a seed
-repository from:
- 
-  http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-unstable.hg.tar.gz
-
-  (or copy from /usr/groups/netos/html/xen/downloads/xen-unstable.hg.tar.gz)
-
-Untar the repository on your disk, cd into it, and then pull the most
-recent changes:
-
-  hg pull -u
-
-By default hg does not automatically checkout ('update') files from
-the repository as used to happen with bk. The above is equivalent to
-"hg pull; hg co"
-
-The repository parent is stored in a repository configuration file, 
-.hg/hgrc, from the repository root.  If you look at this file, you 
-will see:
-
-  |  [paths]
-  |  default = http://xenbits.xensource.com/xen-unstable.hg
-
-"default" specifies the appropriate parent repository for hg to pull 
-from.  Hg allows you to pull additional repositories, for instance if 
-you want to work between unstable and testing concurrently.
-
-The command "hg pull" simply adds changesets to your repository,
-without any merging of any kind.  "hg pull -u" implies merging with
-the current state of your working directory.  If you weren't already
-"updated" to your local repository's tip, you might be surprised to
-find yourself merging the results of the pull with a non-tip node in
-your local repository. 
-
-
-Revision History
-----------------
-
-You can view the repository revision history with:
-
-   hg history
-
-In practice, you'll probably want to use pipe the output through
-'head' or 'more' as it prints the entire history.
-
-Looking at the first few lines of output, you can see the changeset at
-the head of the current branch, known as the 'tip' (the tip is
-automatically given a special tag to make it easy to refer to):
-
-   | changeset:   5599:6cbf9ec05cd9e05c0c46a85df7fc00262633cd3d
-   | tag:         tip
-   | user:        kaf24@firebug.cl.cam.ac.uk
-   | date:        Tue Jun 28 18:47:14 2005
-   | summary:     bitkeeper revision 1.1768 (42c18d2259NPELcGV7ohyZNh72ufSw)
-
-By default, Hg just shows the first line of the changset comments. You
-can find further information with "hg -v history".
-
-The changeset identifier has two parts, a _local_ monotonically
-increasing changeset id, 5599 above, and a _global_ hash, which
-follows the colon on the changeset line.  The hash uniquely identifies
-the changeset and its lineage back to the root of the changeset tree
--- it is useful for distributed management and so on.  However, as it
-is a bit unruly, the local id will allow you to work easily with the
-local repo. Hg commands will take either identifier. Additionally, a
-tags mechanism lets you give common names to specific changesets.
-
-You should always use the global hash when referring to versions of
-the mainline Xen respoitory. With Bk you could often get away with
-using the shortform version, but with Hg the local ids are pretty much
-guaranteed to be different.
-
-
-Creating a child repository from an existing repository
--------------------------------------------------------
-If you wanted to create additional local child repositories,
-
-   hg init [path or url]
-
-is effectively equivalent to bk clone.  The major difference is that 
-it should be run from the root of your new repository.  So:
-
-   bk clone /foo/bar
-
-would be replaced with:
-
-   mkdir bar
-   cd bar
-   hg init /foo/bar
-
-NB: newer version of Hg support a 'clone' command that works in the
-same manner as bk.
-
-Editing files
--------------
-
-Normal edits may be made in place.  File creation needs explicit
-marking, though deletes should be picked up automatically
-
-creation:
-
-   touch a.txt (or otherwise created a file)
-   hg add a.txt
-
-You can see what has changed using:
-
-   hg status
-
-   | C foo/foo.c
-   | R foo/bar.c
-   | ? a.txt
-
-This shows that in the current repo, foo.c has been changed, bar.c has
-been deleted, and a.txt is new, but has not been added.  '?' changes
-to 'A' after "hg add a.txt". There is a .hgignore file which contains
-regexps of files that should be ignored when scanning for new
-files. We try to ensure that all the generated files in a build are
-covered by the regexps.
-
-You can add all the new files in a repository with "hg addremove". If
-you discover that you've added a file you didn't want, you can remove
-it from the list of files to be included in the next commit using
-"hg forget".
-
-Committing changes
------------------
-
-After you've checked that hg knows about any new files you've created,
-you probably want to see a diff of what you're about to commit. You
-can do this with:
-   
-   hg diff
-
-Once you're happy with what you have, invoke:
-
-   hg commit
-
-This will pop up an editor with a list of files to be committed to the
-repository.  It will look vaguely like this:
-
-   | 
-   | HG: manifest hash 6397b04bd5c2a992482d973b685a7e5e498788e7
-   | HG: changed doc/thesis/new.tex
-   | HG: removed doc/2005-hotdep-protection/paper.tex
-
-Your comments can go anywhere in this file.  The first line is the 
-most important, as it will show as the changeset description in 
-non-verbose-mode history listings.
-
-You can do commits without the editor and of partial sets of files 
-using command-line switches. See:
-
-   hg help commit
-
-You can use the -A (--addremove) flag to commit e.g. "hg -A commit" to
-ask mercurial to scan the tree looking for newly created files to add
-in to the changeset. This avoids having to explicitly use "hg add",
-but you probably want to be careful of adding any new generated files
-too.
-
-
-Generating a patch
-------------------
-Generating a patch is easy,
-
-   hg export [changeset]
-
-will generate a patch describing the diff between that changeset and 
-its parent.
-    
-To generate a patch between two specified revisions use:
-   hg diff -r A -r B [files]
-NB: BK syntax -rA..B isn't supported by Hg.   
-
-
-Pushing changesets to a parent repository
------------------------------------------
-
-   hg push
-
-Pushes changes up to a parent. You can't push if you pulled the
-repository off the web interface. In fact, you can currently only push
-to an ssh target -- filesystem directory targets don't work, but this
-will be fixed soon.
-For now it is possible to set up asymmetric pull/push paths. Pulls can
-be done via web interface while pushes via ssh. Example of .hg/hgrc config
-file:
-  | [paths]
-  | default = http://your.server/repository_name
-  | default-push = ssh://[username@]your.server//repository_location
-
-
-Repository history
-------------------
-
-Here are a collection of common commands to get you started:
-
-   hg history | less
-
-shows the history of changesets, starting from the most recent.  You 
-want to pipe it to some sort of pager.  For more complete details,
- 
-   hg -v history | less
-
-will include files modified and full (not just first-line) comments.
-
-Additionally, you can see just the tip (head of the current
-branch) of the repository by typing:
-
-   hg [-v] tip
-
-
-Moving to a specific changeset
-------------------------------
-
-The co command lets you change the working version of the repository
-to a different changeset. 
-
-   hg co [changeset]
-
-NB: 'co' is an alias for 'update'
-
-This command enables you to rewind the working repository to previous
-changesets, for example to isolate the changeset in which a bug is
-introduced.
-
-If you try and do a 'co' but have modified files in your repository Hg
-won't let you unless you ask it explicitly to merge the checked out
-version into the current tree using the "-m" option. The "-C"
-(--clean) option will force overwrite any locally modified files.
-
-Any commits that are made to non-head changesets will obviously fork
-the tree, creating a new head. You can see all the heads in a tree with
-"hg heads".
-
-In general, "hg co" does the right thing, although it doesn't
-currently seem to clean up unused directories that have been created
-by other checked-out versions. This can confuse the Xen build
-system. Hg will probably get fixed soon, but in the meantime you can
-cleanup with "find -depth -type d -print | xargs -r rmdir".
-
-You can return to the tip by omitting an explicit changeset id.
-   
-The manifest command lets you see the contents of the repository for 
-the current changeset.
-
-   hg manifest
-
-This will print a bunch of records of the form: 
-
-   | 98856c45c35a504bc6da06a62b7787ddfdfd1c8b 644 COPYING
-   | f28971eedc5b54e7a9b26dd18d52992955354981 644 Config.mk
-   | a3575cc4db59e50bbac8a039a0c74f081a8dfc4f 644 Makefile
-   | 7fc869aae2945a9f4626fad96552db3103e61cb9 644 README
-   | ...
-
-This lists the hash of each file, its 1-bit 'executable' attribute
-(either file permission mode 644 or 755), and the file name.  So, to
-determine the files that change across two changesets, you would dump
-the respective manifests to files, and use diff.
-
-
-Managing changeset tags
------------------------
-To create a tag to the current changeset:
-
-   hg tag tagname
-
-This will _immediately_ generate a changeset with a change to the file
-.hgtags in the repository root.   The new tag in this file will look
-something like:
-
-   | 35159ed4b30538e7a52c60ad0a63f7e9af156e4c tagname
-
-and may be used to identify that changeset throughout the repo.
-Storing tags in this file and generating changesets immediately 
-forces people to merge and keep tags up to date across the repository.
-
-Note that tags are resolved by searching .hgtags in each of the 
-repository heads, sequentially, and using the first match.  "hg heads"
-lists the current heads.
-
-The "hg tags" command, will lists all the currently valid tags.
-
-
-Hg server and source browser
-----------------------------
-
-   hg serve -p port
-
-Launches a web server on the specified port, serving a source browser 
-for the repository.  This browser may be used to examine the 
-changeset history, view annotated source files, generate diffs.  
-Additionally "hg pull" may be run against it.
-
-Additional useful commands
-(that probably only need one-line descriptions)
------------------------------------------------
-
-(Slightly) more detail on all of these is available with
-
-  hg help [command]
-
-Shows the differences between whatever changeset you most recently
-checked out, and your current working directory:
-
-   hg diff 
-
-View an annotated version of a source file:
-
-   hg annotate
-
-Get a historical version of a file:
-
-   hg cat
-
- NB: Most commands accepting a version number want the changeset's
- version number.  "hg cat" is different in that it wants the
- *file*'s version number.
-
-Unadd a file to the current commit:
-
-   hg forget
-
-List all heads in the current repository:
-
-   hg heads
-
-Undo exactly one (and ONLY one) changeset:
-
-   hg undo
-
-Show the parents of a changeset:
-
-   hg parents
-
- NB: Changesets have either one or two parent changesets. If your
- working directory contains the uncommitted results of a merge, then
- you have two parents.  Otherwise, the single parent is the changeset
- which you most recently checked out.
-
-Show the revision history for a single file
-
-   hg [-v] log <filename>
-
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/network_setup.txt
--- a/docs/misc/network_setup.txt	Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,196 +0,0 @@
-Native OS bridge configuration
-==============================
-
-The traditional "network-bridge" script attempts to modify existing active
-network interfaces to enable bridging. For non-trivial network configurations
-though this can be error prone, and the temporary disruption to network
-connectivity can upset some applications.  This document outlines how to
-configure bridging using an OS' native network configuration files.
-
-Disabling Xen's network scripts
--------------------------------
-
-The first step is to check XenD's network bridge is disabled by
-editing /etc/xen/xend-config.sxp and changing the line
-
- (network-script network-bridge)
-
-To be
-
- (network-script /bin/true)
-
-
-Fedora/RHEL Bridging
-====================
-
-This outlines how to setup bridging using standard network initscripts
-present in Fedora or RHEL distros and their derivatives
-
-
-Disabling NetworkManager
-------------------------
-
-As of time of writing (Fedora 14) NetworkManager does not support bridging,
-so it is neccessary to disable NetworkManager, and revert to "classic"
-network initscripts
-
- # chkconfig NetworkManager off
- # chkconfig network on
- # service NetworkManager stop
- # service network start
-
-NB, as an alternative to turning off NetworkManager, you can also add a line
-"NM_CONTROLLED=no" to the ifcfg-XXX scripts below
-
-Creating network initscripts
-----------------------------
-
-In the /etc/sysconfig/network-scripts directory it is necccessary to create
-2 config files. The first (ifcfg-eth0) defines your physical network interface,
-and says that it will be part of a bridge:
-
-# cat > ifcfg-eth0 <<EOF
-DEVICE=eth0
-HWADDR=00:16:76:D6:C9:45
-ONBOOT=yes
-BRIDGE=br0
-EOF
-
-Obviously change the HWADDR to match your actual NIC's address. You may also
-wish to configure the device's MTU here using e.g. MTU=9000.
-
-The second config file (ifcfg-br0) defines the bridge device:
-
-# cat > ifcfg-br0 <<EOF
-DEVICE=br0
-TYPE=Bridge
-BOOTPROTO=dhcp
-ONBOOT=yes
-DELAY=0
-EOF
-
-WARNING: The line TYPE=Bridge is case-sensitive - it must have uppercase
-'B' and lower case 'ridge'
-
-After changing this restart networking (or better still reboot)
-
- # service network restart
-
-
-The final step is to configure iptables to allow all traffic to be
-forwarded across the bridge
-
-# echo "-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT" > /etc/sysconfig/iptables-forward-bridged
-# lokkit --custom-rules=ipv4:filter:/etc/sysconfig/iptables-forward-bridged
-# service libvirtd reload
-
-Alternatively, you can prevent bridged traffic getting pushed through
-the host's iptables rules completely. In /etc/sysctl.conf add
-
- # cat >> /etc/sysctl.conf <<EOF
- net.bridge.bridge-nf-call-ip6tables = 0
- net.bridge.bridge-nf-call-iptables = 0
- net.bridge.bridge-nf-call-arptables = 0
- EOF
- # sysctl -p /etc/sysctl.conf
-
-You should now have a "shared physical device", to which guests can be
-attached and have full LAN access
-
- # brctl show
- bridge name     bridge id               STP enabled     interfaces
- br0             8000.000e0cb30550       no              eth0
-
-
-
-Debian/Ubuntu Bridging
-=======================
-
-This outlines how to setup bridging using standard network interface config files
-on Debian / Ubuntu distributions and their derivatives
-
-Disabling NetworkManager
-------------------------
-
-Stop network manager
-
- sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher stop
- sudo /etc/dbus-1/event.d/25NetworkManager stop
-
-Create two files with only the word 'exit' in them. These files are:
-
- /etc/default/NetworkManager
- /etc/default/NetworkManagerDispatcher
-
-
-Altering the interface config
------------------------------
-
-First take down the interface you wish to bridge
-
- ifdown eth0
-
-Edit /etc/network/interfaces and find the config for the physical
-interface, which looks something like
-
- allow-hotplug eth0
- iface eth0 inet static
-        address 192.168.2.4
-        netmask 255.255.255.0
-        network 192.168.2.0
-        broadcast 192.168.2.255
-        gateway 192.168.2.2
-
-Remove the 'allow-hotplug eth0' line, replacing it with 'auto br0',
-and change the next line with iface name to 'br0', so it now starts
-with
-
- auto br0
- iface br0 inet static
-
-And then define the interface as being a bridge and specify its ports
-
-       bridge_ports eth0
-       bridge_stp off
-       bridge_maxwait 5
-
-The complete config should now look like
-
- auto br0
- iface br0 inet static
-         address 192.168.2.4
-         netmask 255.255.255.0
-         network 192.168.2.0
-         broadcast 192.168.2.255
-         gateway 192.168.2.2
-         bridge_ports eth0
-         bridge_stp off
-         bridge_maxwait 5
-
-The interface can now be started with
-
- ifup br0
-
-Finally add the '/etc/sysctl.conf' settings
-
-net.bridge.bridge-nf-call-ip6tables = 0
-net.bridge.bridge-nf-call-iptables = 0
-net.bridge.bridge-nf-call-arptables = 0
-
-And then load the settings with
-
- sysctl -p /etc/sysctl.conf
-
-
-You should now have a "shared physical device", to which guests
-can be attached and have full LAN access
-
- # brctl show
- bridge name     bridge id               STP enabled     interfaces
- br0             8000.000e0cb30550       no              eth0
-
-
-Other operating systems / distributions
-=======================================
-
-[...send patches to this file with instructions....]

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:38:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:38:29 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR42n-00025g-Ga
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR42V-0002KB-UP; Thu, 17 Nov 2011 07:38:12 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TY-0002R0-I0
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:42 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321542117!1909981!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11635 invoked from network); 17 Nov 2011 15:02:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990645"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:02:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:00 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNM026208;	Thu, 17 Nov 2011 07:01:59 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 8f2404eef8fac8020528b408b3a958d81cbb73c0
Message-ID: <8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the html
	output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542075 0
# Node ID 8f2404eef8fac8020528b408b3a958d81cbb73c0
# Parent  c1f8406da50743cd0597b93c4b5b8b6ff03ede42
docs: generate an index for the html output

nb: I'm not a Perl wizard...

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

diff -r c1f8406da507 -r 8f2404eef8fa docs/INDEX
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/INDEX	Thu Nov 17 15:01:15 2011 +0000
@@ -0,0 +1,5 @@
+misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
+
+# These are not all that useful anymore, hide them from the index
+interface/index			NO-INDEX
+user/index			NO-INDEX
diff -r c1f8406da507 -r 8f2404eef8fa docs/Makefile
--- a/docs/Makefile	Thu Nov 17 14:54:38 2011 +0000
+++ b/docs/Makefile	Thu Nov 17 15:01:15 2011 +0000
@@ -45,7 +45,7 @@ ps: $(DOC_PS)
 pdf: $(DOC_PDF)
 
 .PHONY: html
-html: $(DOC_HTML)
+html: $(DOC_HTML) html/index.html
 
 .PHONY: txt
 txt: $(DOC_TXT)
@@ -128,6 +128,9 @@ html/%/index.html: src/%.tex
 	$< 1>/dev/null 2>/dev/null ; else \
 	echo "latex2html not installed; skipping $*."; fi
 
+html/index.html: $(DOC_HTML) ./gen-html-index INDEX
+	./gen-html-index -i INDEX html $(DOC_HTML)
+
 html/%.html: %.markdown
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \
diff -r c1f8406da507 -r 8f2404eef8fa docs/gen-html-index
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/gen-html-index	Thu Nov 17 15:01:15 2011 +0000
@@ -0,0 +1,129 @@
+#!/usr/bin/perl -w
+
+#
+# Generate indexes for html documentation
+#
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+use IO::File;
+use File::Basename;
+use List::MoreUtils qw/ uniq /;
+
+Getopt::Long::Configure('bundling');
+
+@ARGV >= 2 or die;
+
+our @docs;
+our @dirs;
+our %index;
+
+our $outdir;
+
+GetOptions("i=s" => sub { read_index(@_);} )
+    or die;
+
+($outdir,@docs) = @ARGV;
+
+sub write_file ($$) {
+    my ($opath, $odata) = @_;
+    my $out = new IO::File "$opath.new", '>' or die "$opath $!";
+    print $out $odata or die $!;
+    rename "$opath.new", "$opath" or die "$opath $!";
+}
+
+sub make_page($$$) {
+    my ($file,$title,$content) = @_;
+    my $o = '';
+    my $h1;
+    if ( $title eq "" )
+    {
+	$title = $h1 = "Xen Documentation";
+    }
+    else
+    {
+	$h1 = "<a href=\"../index.html\">Xen Documentation</a> - $title";
+	$title = "Xen Documentation - $title";
+    }
+    $o .= <<END;
+<html><head><title>$title</title></head>
+<body>
+<h1>$h1</h1>
+<ul>
+$content
+</ul>
+</body></html>
+END
+    print STDERR "Writing: $file\n";
+    write_file($file, $o);
+}
+
+sub make_linktext($) {
+    my ($l) = @_;
+    return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
+    $l =~ s/.(html)$//g;
+    return $index{$l} if exists $index{$l};
+    return basename($l);
+}
+
+sub make_link($$) {
+    my ($ref,$base) = @_;
+
+    my $txt = make_linktext($ref);
+    $ref = basename($ref) if $base;
+
+    return "<li><a href=\"$ref\">$txt</a></li>\n";
+}
+
+sub make_links($$@) {
+    my ($dir,$base,@docs) = @_;
+    my $idx = '';
+    foreach my $of (sort { $a cmp $b } @docs) {
+	$idx .= make_link($of,$base);
+    }
+    return $idx;
+}
+
+sub read_index
+{
+    my ($opt, $val) = @_;
+    my $idx = new IO::File "$val", '<' or die "$val $!";
+    while ($_ = $idx->getline()) {
+	s/#.*$//;
+	m/./ or next;
+	m/([^\t]+)\t+(.*)/ or die;
+	$index{$1} = $2;
+    }
+}
+
+for (@docs) { s,^${outdir}/,, }
+
+@docs = grep { -e "$outdir/$_" && (make_linktext($_) ne "NO-INDEX") } @docs;
+
+my $top = '';
+
+foreach my $od (sort { $a cmp $b } uniq map { dirname($_) } @docs) {
+    my @d = (grep /^$od/, @docs);
+    if ( $#d == 0 and $d[0] eq "$od/index.html" )
+    {
+	$top .= "<li><a href=\"${od}/index.html\">${od}/index.html</a></li>\n";
+    }
+    else
+    {
+	$top .= "<li><a href=\"${od}/index.html\">$od</a></li>\n";
+	$top .= "<ul>\n";
+	$top .= make_links($od,0,@d);
+	$top .= "</ul>\n";
+
+	my $idx = '';
+	$idx .= "<li>$od</li>\n";
+	$idx .= "<ul>\n";
+	$idx .= make_links($od,1,@d);
+	$idx .= "</ul>\n";
+	make_page("$outdir/$od/index.html", $od, $idx);
+    }
+}
+
+make_page("$outdir/index.html", "", $top);

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:38:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:38:29 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR42n-00025g-Ga
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR42V-0002KB-UP; Thu, 17 Nov 2011 07:38:12 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3TY-0002R0-I0
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:02:42 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321542117!1909981!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11635 invoked from network); 17 Nov 2011 15:02:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:02:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170990645"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:02:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:02:00 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAHF1lNM026208;	Thu, 17 Nov 2011 07:01:59 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 8f2404eef8fac8020528b408b3a958d81cbb73c0
Message-ID: <8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321542106@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 15:01:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the html
	output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542075 0
# Node ID 8f2404eef8fac8020528b408b3a958d81cbb73c0
# Parent  c1f8406da50743cd0597b93c4b5b8b6ff03ede42
docs: generate an index for the html output

nb: I'm not a Perl wizard...

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

diff -r c1f8406da507 -r 8f2404eef8fa docs/INDEX
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/INDEX	Thu Nov 17 15:01:15 2011 +0000
@@ -0,0 +1,5 @@
+misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
+
+# These are not all that useful anymore, hide them from the index
+interface/index			NO-INDEX
+user/index			NO-INDEX
diff -r c1f8406da507 -r 8f2404eef8fa docs/Makefile
--- a/docs/Makefile	Thu Nov 17 14:54:38 2011 +0000
+++ b/docs/Makefile	Thu Nov 17 15:01:15 2011 +0000
@@ -45,7 +45,7 @@ ps: $(DOC_PS)
 pdf: $(DOC_PDF)
 
 .PHONY: html
-html: $(DOC_HTML)
+html: $(DOC_HTML) html/index.html
 
 .PHONY: txt
 txt: $(DOC_TXT)
@@ -128,6 +128,9 @@ html/%/index.html: src/%.tex
 	$< 1>/dev/null 2>/dev/null ; else \
 	echo "latex2html not installed; skipping $*."; fi
 
+html/index.html: $(DOC_HTML) ./gen-html-index INDEX
+	./gen-html-index -i INDEX html $(DOC_HTML)
+
 html/%.html: %.markdown
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \
diff -r c1f8406da507 -r 8f2404eef8fa docs/gen-html-index
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/gen-html-index	Thu Nov 17 15:01:15 2011 +0000
@@ -0,0 +1,129 @@
+#!/usr/bin/perl -w
+
+#
+# Generate indexes for html documentation
+#
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+use IO::File;
+use File::Basename;
+use List::MoreUtils qw/ uniq /;
+
+Getopt::Long::Configure('bundling');
+
+@ARGV >= 2 or die;
+
+our @docs;
+our @dirs;
+our %index;
+
+our $outdir;
+
+GetOptions("i=s" => sub { read_index(@_);} )
+    or die;
+
+($outdir,@docs) = @ARGV;
+
+sub write_file ($$) {
+    my ($opath, $odata) = @_;
+    my $out = new IO::File "$opath.new", '>' or die "$opath $!";
+    print $out $odata or die $!;
+    rename "$opath.new", "$opath" or die "$opath $!";
+}
+
+sub make_page($$$) {
+    my ($file,$title,$content) = @_;
+    my $o = '';
+    my $h1;
+    if ( $title eq "" )
+    {
+	$title = $h1 = "Xen Documentation";
+    }
+    else
+    {
+	$h1 = "<a href=\"../index.html\">Xen Documentation</a> - $title";
+	$title = "Xen Documentation - $title";
+    }
+    $o .= <<END;
+<html><head><title>$title</title></head>
+<body>
+<h1>$h1</h1>
+<ul>
+$content
+</ul>
+</body></html>
+END
+    print STDERR "Writing: $file\n";
+    write_file($file, $o);
+}
+
+sub make_linktext($) {
+    my ($l) = @_;
+    return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
+    $l =~ s/.(html)$//g;
+    return $index{$l} if exists $index{$l};
+    return basename($l);
+}
+
+sub make_link($$) {
+    my ($ref,$base) = @_;
+
+    my $txt = make_linktext($ref);
+    $ref = basename($ref) if $base;
+
+    return "<li><a href=\"$ref\">$txt</a></li>\n";
+}
+
+sub make_links($$@) {
+    my ($dir,$base,@docs) = @_;
+    my $idx = '';
+    foreach my $of (sort { $a cmp $b } @docs) {
+	$idx .= make_link($of,$base);
+    }
+    return $idx;
+}
+
+sub read_index
+{
+    my ($opt, $val) = @_;
+    my $idx = new IO::File "$val", '<' or die "$val $!";
+    while ($_ = $idx->getline()) {
+	s/#.*$//;
+	m/./ or next;
+	m/([^\t]+)\t+(.*)/ or die;
+	$index{$1} = $2;
+    }
+}
+
+for (@docs) { s,^${outdir}/,, }
+
+@docs = grep { -e "$outdir/$_" && (make_linktext($_) ne "NO-INDEX") } @docs;
+
+my $top = '';
+
+foreach my $od (sort { $a cmp $b } uniq map { dirname($_) } @docs) {
+    my @d = (grep /^$od/, @docs);
+    if ( $#d == 0 and $d[0] eq "$od/index.html" )
+    {
+	$top .= "<li><a href=\"${od}/index.html\">${od}/index.html</a></li>\n";
+    }
+    else
+    {
+	$top .= "<li><a href=\"${od}/index.html\">$od</a></li>\n";
+	$top .= "<ul>\n";
+	$top .= make_links($od,0,@d);
+	$top .= "</ul>\n";
+
+	my $idx = '';
+	$idx .= "<li>$od</li>\n";
+	$idx .= "<ul>\n";
+	$idx .= make_links($od,1,@d);
+	$idx .= "</ul>\n";
+	make_page("$outdir/$od/index.html", $od, $idx);
+    }
+}
+
+make_page("$outdir/index.html", "", $top);

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:42:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:42:33 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR46j-00025y-CI
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR46P-0003H6-03; Thu, 17 Nov 2011 07:42:14 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3ie-0005VQ-2U
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:17:40 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1321543055!3963335!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14858 invoked from network); 17 Nov 2011 15:17:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190182"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:17:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:17:35 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaK026286;	Thu, 17 Nov 2011 07:17:33 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:03 +0000
Message-ID: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 00/10] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Hi all,

This patch series introduces the PCI passthrough for Xen.

First, we have HostPCIDevice that help to access one PCI device of the host.

Then, there is an additions in the QEMU code, pci_check_bar_overlap.

There are also several change in pci_ids and pci_regs.

Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
(or file), there is one to take care of the initialisation of a passthrough
device. The second one handle everything about the config address space, there
are specifics functions for every config register. The third one is to handle
MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:00:1b.0".


Change since v3:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.


Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.


Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property



Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (6):
  pci_ids: Add INTEL_82599_VF id.
  pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
  pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce HostPCIDevice to access a pci device on the host.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

Yuji Shimada (1):
  pci.c: Add pci_check_bar_overlap

 Makefile.target                      |    6 +
 configure                            |   25 +
 hw/apic-msidef.h                     |   30 +
 hw/apic.c                            |   11 +-
 hw/host-pci-device.c                 |  279 ++++
 hw/host-pci-device.h                 |   75 +
 hw/pci.c                             |   47 +
 hw/pci.h                             |    3 +
 hw/pci_ids.h                         |    1 +
 hw/pci_regs.h                        |    3 +-
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  902 ++++++++++++
 hw/xen_pci_passthrough.h             |  337 +++++
 hw/xen_pci_passthrough_config_init.c | 2637 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  678 +++++++++
 xen-all.c                            |   12 +
 16 files changed, 5038 insertions(+), 11 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c
 create mode 100644 hw/xen_pci_passthrough_msi.c

-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:42:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:42:33 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR46j-00025y-CI
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR46P-0003H6-03; Thu, 17 Nov 2011 07:42:14 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3ie-0005VQ-2U
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:17:40 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1321543055!3963335!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14858 invoked from network); 17 Nov 2011 15:17:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190182"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:17:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:17:35 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaK026286;	Thu, 17 Nov 2011 07:17:33 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:03 +0000
Message-ID: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 00/10] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Hi all,

This patch series introduces the PCI passthrough for Xen.

First, we have HostPCIDevice that help to access one PCI device of the host.

Then, there is an additions in the QEMU code, pci_check_bar_overlap.

There are also several change in pci_ids and pci_regs.

Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
(or file), there is one to take care of the initialisation of a passthrough
device. The second one handle everything about the config address space, there
are specifics functions for every config register. The third one is to handle
MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:00:1b.0".


Change since v3:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.


Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.


Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property



Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (6):
  pci_ids: Add INTEL_82599_VF id.
  pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
  pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce HostPCIDevice to access a pci device on the host.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

Yuji Shimada (1):
  pci.c: Add pci_check_bar_overlap

 Makefile.target                      |    6 +
 configure                            |   25 +
 hw/apic-msidef.h                     |   30 +
 hw/apic.c                            |   11 +-
 hw/host-pci-device.c                 |  279 ++++
 hw/host-pci-device.h                 |   75 +
 hw/pci.c                             |   47 +
 hw/pci.h                             |    3 +
 hw/pci_ids.h                         |    1 +
 hw/pci_regs.h                        |    3 +-
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  902 ++++++++++++
 hw/xen_pci_passthrough.h             |  337 +++++
 hw/xen_pci_passthrough_config_init.c | 2637 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  678 +++++++++
 xen-all.c                            |   12 +
 16 files changed, 5038 insertions(+), 11 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c
 create mode 100644 hw/xen_pci_passthrough_msi.c

-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:44:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:44:09 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR48G-00026B-US
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR47y-0003fV-Jo; Thu, 17 Nov 2011 07:43:50 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jP-0005fs-4W
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:28 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321543069!57657688!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4434 invoked from network); 17 Nov 2011 15:17:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170994194"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:23 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaO026286;	Thu, 17 Nov 2011 07:18:22 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:07 +0000
Message-ID: <1321543033-22090-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 04/10] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target |    2 ++
 configure       |   25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index a111521..2e881ce 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -219,6 +219,8 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/configure b/configure
index 6c77fbb..1e6ea91 100755
--- a/configure
+++ b/configure
@@ -127,6 +127,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 attr=""
 libattr=""
@@ -644,6 +645,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -990,6 +995,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1357,6 +1364,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3462,6 +3484,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:44:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:44:09 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR48G-00026B-US
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR47y-0003fV-Jo; Thu, 17 Nov 2011 07:43:50 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jP-0005fs-4W
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:28 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321543069!57657688!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4434 invoked from network); 17 Nov 2011 15:17:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170994194"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:23 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaO026286;	Thu, 17 Nov 2011 07:18:22 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:07 +0000
Message-ID: <1321543033-22090-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 04/10] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target |    2 ++
 configure       |   25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index a111521..2e881ce 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -219,6 +219,8 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/configure b/configure
index 6c77fbb..1e6ea91 100755
--- a/configure
+++ b/configure
@@ -127,6 +127,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 attr=""
 libattr=""
@@ -644,6 +645,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -990,6 +995,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1357,6 +1364,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3462,6 +3484,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:45:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:45:05 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR49B-00026P-HW
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR48t-00043R-Va; Thu, 17 Nov 2011 07:44:47 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jN-0005fe-C2
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:26 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321543069!57657688!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4264 invoked from network); 17 Nov 2011 15:17:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170994189"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:22 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaN026286;	Thu, 17 Nov 2011 07:18:20 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:06 +0000
Message-ID: <1321543033-22090-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 03/10] pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index 6b42515..56a404b 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -392,6 +392,7 @@
 #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
+#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
 #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:45:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:45:05 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR49B-00026P-HW
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR48t-00043R-Va; Thu, 17 Nov 2011 07:44:47 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jN-0005fe-C2
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:26 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321543069!57657688!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4264 invoked from network); 17 Nov 2011 15:17:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170994189"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:22 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaN026286;	Thu, 17 Nov 2011 07:18:20 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:06 +0000
Message-ID: <1321543033-22090-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 03/10] pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index 6b42515..56a404b 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -392,6 +392,7 @@
 #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
+#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
 #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:46:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:46:06 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4A9-00026c-TZ
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:46:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR49o-0004RZ-Be; Thu, 17 Nov 2011 07:45:44 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jM-0005fd-Tn
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:25 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321543069!57657688!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4200 invoked from network); 17 Nov 2011 15:17:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170994185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:20 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaM026286;	Thu, 17 Nov 2011 07:18:18 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:05 +0000
Message-ID: <1321543033-22090-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 02/10] pci_regs: Fix value of
	PCI_EXP_TYPE_RC_EC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Value check in PCI Express Base Specification rev 1.1

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index e8357c3..6b42515 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -393,7 +393,7 @@
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
-#define  PCI_EXP_TYPE_RC_EC	0x10	/* Root Complex Event Collector */
+#define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
 #define PCI_EXP_FLAGS_IRQ	0x3e00	/* Interrupt message number */
 #define PCI_EXP_DEVCAP		4	/* Device capabilities */
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:46:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:46:06 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4A9-00026c-TZ
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:46:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR49o-0004RZ-Be; Thu, 17 Nov 2011 07:45:44 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jM-0005fd-Tn
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:25 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321543069!57657688!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4200 invoked from network); 17 Nov 2011 15:17:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170994185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:20 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaM026286;	Thu, 17 Nov 2011 07:18:18 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:05 +0000
Message-ID: <1321543033-22090-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 02/10] pci_regs: Fix value of
	PCI_EXP_TYPE_RC_EC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Value check in PCI Express Base Specification rev 1.1

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index e8357c3..6b42515 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -393,7 +393,7 @@
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
-#define  PCI_EXP_TYPE_RC_EC	0x10	/* Root Complex Event Collector */
+#define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
 #define PCI_EXP_FLAGS_IRQ	0x3e00	/* Interrupt message number */
 #define PCI_EXP_DEVCAP		4	/* Device capabilities */
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:47:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:47:04 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4B6-00026p-Cx
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Aj-0004pu-Gk; Thu, 17 Nov 2011 07:46:41 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jK-0005ew-7X
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:25 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1321543062!46333550!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3896 invoked from network); 17 Nov 2011 15:17:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190237"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:17 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:17 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaL026286;	Thu, 17 Nov 2011 07:18:16 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:04 +0000
Message-ID: <1321543033-22090-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 01/10] pci_ids: Add INTEL_82599_VF id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index 83f3893..2ea5ec2 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -117,6 +117,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_VF     0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:47:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:47:04 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4B6-00026p-Cx
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Aj-0004pu-Gk; Thu, 17 Nov 2011 07:46:41 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jK-0005ew-7X
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:25 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1321543062!46333550!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3896 invoked from network); 17 Nov 2011 15:17:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190237"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:17 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:17 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaL026286;	Thu, 17 Nov 2011 07:18:16 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:04 +0000
Message-ID: <1321543033-22090-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 01/10] pci_ids: Add INTEL_82599_VF id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index 83f3893..2ea5ec2 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -117,6 +117,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_VF     0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:48:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:48:00 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4C0-000272-81
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:48:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Bi-0005FL-DF; Thu, 17 Nov 2011 07:47:42 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jS-0005gY-Fr
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:33 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321543105!3550834!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29144 invoked from network); 17 Nov 2011 15:18:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:18:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190243"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:25 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaP026286;	Thu, 17 Nov 2011 07:18:23 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:08 +0000
Message-ID: <1321543033-22090-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 05/10] Introduce HostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target      |    1 +
 hw/host-pci-device.c |  279 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/host-pci-device.h |   75 ++++++++++++++
 3 files changed, 355 insertions(+), 0 deletions(-)
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index 2e881ce..e527c1b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -220,6 +220,7 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 0000000..06f7761
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "host-pci-device.h"
+
+#define PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+enum error_code {
+    ERROR_SYNTAX = 1,
+};
+
+static int path_to(const HostPCIDevice *d,
+                   const char *name, char *buf, ssize_t size)
+{
+    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
+                    d->domain, d->bus, d->dev, d->func, name);
+}
+
+static int get_resource(HostPCIDevice *d)
+{
+    int i, rc = 0;
+    FILE *f;
+    char path[PATH_MAX];
+    unsigned long long start, end, flags, size;
+
+    path_to(d, "resource", path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
+            fprintf(stderr, "Error: Syntax error in %s\n", path);
+            rc = ERROR_SYNTAX;
+            break;
+        }
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].flags = flags;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.flags = flags;
+        }
+    }
+
+    fclose(f);
+    return rc;
+}
+
+static int get_value(HostPCIDevice *d, const char *name, unsigned long *pvalue)
+{
+    char path[PATH_MAX];
+    FILE *f;
+    unsigned long value;
+
+    path_to(d, name, path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -1;
+    }
+    if (fscanf(f, "%lx\n", &value) != 1) {
+        fprintf(stderr, "Error: Syntax error in %s\n", path);
+        return -1;
+    }
+    fclose(f);
+    *pvalue = value;
+    return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+    int rc;
+    char path[PATH_MAX];
+    struct stat buf;
+
+    path_to(d, "physfn", path, sizeof (path));
+    rc = !stat(path, &buf);
+
+    return rc;
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+
+    if (d->config_fd < 0) {
+        path_to(d, "config", path, sizeof (path));
+        d->config_fd = open(path, O_RDWR);
+        if (d->config_fd < 0) {
+            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
+                    path, strerror(errno));
+        }
+    }
+    return d->config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pread(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "host_pci_config: read failed: %s (fd: %i)\n",
+                strerror(errno), fd);
+        return -errno;
+    }
+    return 0;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+                                 int pos, const void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pwrite(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "host_pci_config: write failed: %s\n",
+                strerror(errno));
+        return -errno;
+    }
+    return 0;
+}
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
+{
+  uint8_t buf;
+  if (host_pci_config_read(d, pos, &buf, 1)) {
+      return -1;
+  }
+  *p = buf;
+  return 0;
+}
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p)
+{
+  uint16_t buf;
+  if (host_pci_config_read(d, pos, &buf, 2)) {
+      return -1;
+  }
+  *p = le16_to_cpu(buf);
+  return 0;
+}
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p)
+{
+  uint32_t buf;
+  if (host_pci_config_read(d, pos, &buf, 4)) {
+      return -1;
+  }
+  *p = le32_to_cpu(buf);
+  return 0;
+}
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+  return host_pci_config_read(d, pos, buf, len);
+}
+
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
+{
+  return host_pci_config_write(d, pos, &data, 1);
+}
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
+{
+  data = cpu_to_le16(data);
+  return host_pci_config_write(d, pos, &data, 2);
+}
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
+{
+  data = cpu_to_le32(data);
+  return host_pci_config_write(d, pos, &data, 4);
+}
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+  return host_pci_config_write(d, pos, buf, len);
+}
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return 0;
+}
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
+{
+    HostPCIDevice *d = NULL;
+    unsigned long v = 0;
+
+    d = g_new0(HostPCIDevice, 1);
+
+    d->config_fd = -1;
+    d->domain = 0;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    if (host_pci_config_fd(d) == -1) {
+        goto error;
+    }
+    if (get_resource(d) != 0) {
+        goto error;
+    }
+
+    if (get_value(d, "vendor", &v)) {
+        goto error;
+    }
+    d->vendor_id = v;
+    if (get_value(d, "device", &v)) {
+        goto error;
+    }
+    d->device_id = v;
+    d->is_virtfn = pci_dev_is_virtfn(d);
+
+    return d;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+    return NULL;
+}
+
+void host_pci_device_put(HostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+}
diff --git a/hw/host-pci-device.h b/hw/host-pci-device.h
new file mode 100644
index 0000000..c8880eb
--- /dev/null
+++ b/hw/host-pci-device.h
@@ -0,0 +1,75 @@
+#ifndef HW_HOST_PCI_DEVICE
+#  define HW_HOST_PCI_DEVICE
+
+#include "pci.h"
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+#define IORESOURCE_IRQ          0x00000400
+#define IORESOURCE_DMA          0x00000800
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_READONLY     0x00002000
+#define IORESOURCE_CACHEABLE    0x00004000
+#define IORESOURCE_RANGELENGTH  0x00008000
+#define IORESOURCE_SHADOWABLE   0x00010000
+
+#define IORESOURCE_SIZEALIGN    0x00020000      /* size indicates alignment */
+#define IORESOURCE_STARTALIGN   0x00040000      /* start field is alignment */
+
+#define IORESOURCE_MEM_64       0x00100000
+
+    /* Userland may not map this resource */
+#define IORESOURCE_EXCLUSIVE    0x08000000
+#define IORESOURCE_DISABLED     0x10000000
+#define IORESOURCE_UNSET        0x20000000
+#define IORESOURCE_AUTO         0x40000000
+    /* Driver has marked this resource busy */
+#define IORESOURCE_BUSY         0x80000000
+
+
+typedef struct HostPCIIORegion {
+    unsigned long flags;
+    pcibus_t base_addr;
+    pcibus_t size;
+} HostPCIIORegion;
+
+typedef struct HostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+
+    HostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    HostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} HostPCIDevice;
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func);
+void host_pci_device_put(HostPCIDevice *pci_dev);
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p);
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p);
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p);
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data);
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data);
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data);
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *s, uint32_t cap);
+
+#endif /* !HW_HOST_PCI_DEVICE */
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:48:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:48:00 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4C0-000272-81
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:48:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Bi-0005FL-DF; Thu, 17 Nov 2011 07:47:42 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jS-0005gY-Fr
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:33 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321543105!3550834!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29144 invoked from network); 17 Nov 2011 15:18:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:18:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190243"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:25 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaP026286;	Thu, 17 Nov 2011 07:18:23 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:08 +0000
Message-ID: <1321543033-22090-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 05/10] Introduce HostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target      |    1 +
 hw/host-pci-device.c |  279 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/host-pci-device.h |   75 ++++++++++++++
 3 files changed, 355 insertions(+), 0 deletions(-)
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index 2e881ce..e527c1b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -220,6 +220,7 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 0000000..06f7761
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "host-pci-device.h"
+
+#define PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+enum error_code {
+    ERROR_SYNTAX = 1,
+};
+
+static int path_to(const HostPCIDevice *d,
+                   const char *name, char *buf, ssize_t size)
+{
+    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
+                    d->domain, d->bus, d->dev, d->func, name);
+}
+
+static int get_resource(HostPCIDevice *d)
+{
+    int i, rc = 0;
+    FILE *f;
+    char path[PATH_MAX];
+    unsigned long long start, end, flags, size;
+
+    path_to(d, "resource", path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
+            fprintf(stderr, "Error: Syntax error in %s\n", path);
+            rc = ERROR_SYNTAX;
+            break;
+        }
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].flags = flags;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.flags = flags;
+        }
+    }
+
+    fclose(f);
+    return rc;
+}
+
+static int get_value(HostPCIDevice *d, const char *name, unsigned long *pvalue)
+{
+    char path[PATH_MAX];
+    FILE *f;
+    unsigned long value;
+
+    path_to(d, name, path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -1;
+    }
+    if (fscanf(f, "%lx\n", &value) != 1) {
+        fprintf(stderr, "Error: Syntax error in %s\n", path);
+        return -1;
+    }
+    fclose(f);
+    *pvalue = value;
+    return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+    int rc;
+    char path[PATH_MAX];
+    struct stat buf;
+
+    path_to(d, "physfn", path, sizeof (path));
+    rc = !stat(path, &buf);
+
+    return rc;
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+
+    if (d->config_fd < 0) {
+        path_to(d, "config", path, sizeof (path));
+        d->config_fd = open(path, O_RDWR);
+        if (d->config_fd < 0) {
+            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
+                    path, strerror(errno));
+        }
+    }
+    return d->config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pread(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "host_pci_config: read failed: %s (fd: %i)\n",
+                strerror(errno), fd);
+        return -errno;
+    }
+    return 0;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+                                 int pos, const void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pwrite(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "host_pci_config: write failed: %s\n",
+                strerror(errno));
+        return -errno;
+    }
+    return 0;
+}
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
+{
+  uint8_t buf;
+  if (host_pci_config_read(d, pos, &buf, 1)) {
+      return -1;
+  }
+  *p = buf;
+  return 0;
+}
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p)
+{
+  uint16_t buf;
+  if (host_pci_config_read(d, pos, &buf, 2)) {
+      return -1;
+  }
+  *p = le16_to_cpu(buf);
+  return 0;
+}
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p)
+{
+  uint32_t buf;
+  if (host_pci_config_read(d, pos, &buf, 4)) {
+      return -1;
+  }
+  *p = le32_to_cpu(buf);
+  return 0;
+}
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+  return host_pci_config_read(d, pos, buf, len);
+}
+
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
+{
+  return host_pci_config_write(d, pos, &data, 1);
+}
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
+{
+  data = cpu_to_le16(data);
+  return host_pci_config_write(d, pos, &data, 2);
+}
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
+{
+  data = cpu_to_le32(data);
+  return host_pci_config_write(d, pos, &data, 4);
+}
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+  return host_pci_config_write(d, pos, buf, len);
+}
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return 0;
+}
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
+{
+    HostPCIDevice *d = NULL;
+    unsigned long v = 0;
+
+    d = g_new0(HostPCIDevice, 1);
+
+    d->config_fd = -1;
+    d->domain = 0;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    if (host_pci_config_fd(d) == -1) {
+        goto error;
+    }
+    if (get_resource(d) != 0) {
+        goto error;
+    }
+
+    if (get_value(d, "vendor", &v)) {
+        goto error;
+    }
+    d->vendor_id = v;
+    if (get_value(d, "device", &v)) {
+        goto error;
+    }
+    d->device_id = v;
+    d->is_virtfn = pci_dev_is_virtfn(d);
+
+    return d;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+    return NULL;
+}
+
+void host_pci_device_put(HostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+}
diff --git a/hw/host-pci-device.h b/hw/host-pci-device.h
new file mode 100644
index 0000000..c8880eb
--- /dev/null
+++ b/hw/host-pci-device.h
@@ -0,0 +1,75 @@
+#ifndef HW_HOST_PCI_DEVICE
+#  define HW_HOST_PCI_DEVICE
+
+#include "pci.h"
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+#define IORESOURCE_IRQ          0x00000400
+#define IORESOURCE_DMA          0x00000800
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_READONLY     0x00002000
+#define IORESOURCE_CACHEABLE    0x00004000
+#define IORESOURCE_RANGELENGTH  0x00008000
+#define IORESOURCE_SHADOWABLE   0x00010000
+
+#define IORESOURCE_SIZEALIGN    0x00020000      /* size indicates alignment */
+#define IORESOURCE_STARTALIGN   0x00040000      /* start field is alignment */
+
+#define IORESOURCE_MEM_64       0x00100000
+
+    /* Userland may not map this resource */
+#define IORESOURCE_EXCLUSIVE    0x08000000
+#define IORESOURCE_DISABLED     0x10000000
+#define IORESOURCE_UNSET        0x20000000
+#define IORESOURCE_AUTO         0x40000000
+    /* Driver has marked this resource busy */
+#define IORESOURCE_BUSY         0x80000000
+
+
+typedef struct HostPCIIORegion {
+    unsigned long flags;
+    pcibus_t base_addr;
+    pcibus_t size;
+} HostPCIIORegion;
+
+typedef struct HostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+
+    HostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    HostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} HostPCIDevice;
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func);
+void host_pci_device_put(HostPCIDevice *pci_dev);
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p);
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p);
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p);
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data);
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data);
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data);
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *s, uint32_t cap);
+
+#endif /* !HW_HOST_PCI_DEVICE */
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:48:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:48:53 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Cr-00027F-JC
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Ca-0005ff-3q; Thu, 17 Nov 2011 07:48:36 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jT-0005gj-Tj
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:33 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321543069!57657688!4
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4759 invoked from network); 17 Nov 2011 15:17:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170994212"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:28 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaQ026286;	Thu, 17 Nov 2011 07:18:26 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:09 +0000
Message-ID: <1321543033-22090-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 06/10] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>

This function help Xen PCI Passthrough device to check for overlap.

Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/pci.h |    3 +++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 399227f..563bb37 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -2038,3 +2038,50 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
 {
     return dev->bus->address_space_io;
 }
+
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type)
+{
+    PCIBus *bus = dev->bus;
+    PCIDevice *devices = NULL;
+    PCIIORegion *r;
+    int i, j;
+    int rc = 0;
+
+    /* check Overlapped to Base Address */
+    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
+        devices = bus->devices[i];
+        if (!devices) {
+            continue;
+        }
+
+        /* skip itself */
+        if (devices->devfn == dev->devfn) {
+            continue;
+        }
+
+        for (j = 0; j < PCI_NUM_REGIONS; j++) {
+            r = &devices->io_regions[j];
+
+            /* skip different resource type, but don't skip when
+             * prefetch and non-prefetch memory are compared.
+             */
+            if (type != r->type) {
+                if (type == PCI_BASE_ADDRESS_SPACE_IO ||
+                    r->type == PCI_BASE_ADDRESS_SPACE_IO) {
+                    continue;
+                }
+            }
+
+            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {
+                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
+                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
+                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
+                       PCI_FUNC(devices->devfn), j, r->addr, r->size);
+                rc = 1;
+            }
+        }
+    }
+
+    return rc;
+}
diff --git a/hw/pci.h b/hw/pci.h
index 4b2e785..307fa13 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -550,4 +550,7 @@ static inline void pci_dma_sglist_init(QEMUSGList *qsg, PCIDevice *dev,
     qemu_sglist_init(qsg, alloc_hint);
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type);
+
 #endif
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:48:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:48:53 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Cr-00027F-JC
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Ca-0005ff-3q; Thu, 17 Nov 2011 07:48:36 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jT-0005gj-Tj
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:33 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321543069!57657688!4
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4759 invoked from network); 17 Nov 2011 15:17:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:17:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170994212"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:28 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaQ026286;	Thu, 17 Nov 2011 07:18:26 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:09 +0000
Message-ID: <1321543033-22090-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH V4 06/10] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>

This function help Xen PCI Passthrough device to check for overlap.

Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/pci.h |    3 +++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 399227f..563bb37 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -2038,3 +2038,50 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
 {
     return dev->bus->address_space_io;
 }
+
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type)
+{
+    PCIBus *bus = dev->bus;
+    PCIDevice *devices = NULL;
+    PCIIORegion *r;
+    int i, j;
+    int rc = 0;
+
+    /* check Overlapped to Base Address */
+    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
+        devices = bus->devices[i];
+        if (!devices) {
+            continue;
+        }
+
+        /* skip itself */
+        if (devices->devfn == dev->devfn) {
+            continue;
+        }
+
+        for (j = 0; j < PCI_NUM_REGIONS; j++) {
+            r = &devices->io_regions[j];
+
+            /* skip different resource type, but don't skip when
+             * prefetch and non-prefetch memory are compared.
+             */
+            if (type != r->type) {
+                if (type == PCI_BASE_ADDRESS_SPACE_IO ||
+                    r->type == PCI_BASE_ADDRESS_SPACE_IO) {
+                    continue;
+                }
+            }
+
+            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {
+                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
+                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
+                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
+                       PCI_FUNC(devices->devfn), j, r->addr, r->size);
+                rc = 1;
+            }
+        }
+    }
+
+    return rc;
+}
diff --git a/hw/pci.h b/hw/pci.h
index 4b2e785..307fa13 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -550,4 +550,7 @@ static inline void pci_dma_sglist_init(QEMUSGList *qsg, PCIDevice *dev,
     qemu_sglist_init(qsg, alloc_hint);
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type);
+
 #endif
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:49:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:49:46 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Di-00027S-Gq
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:49:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4DQ-00065X-NV; Thu, 17 Nov 2011 07:49:28 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jY-0005hS-DJ
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:39 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321543105!3550834!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29453 invoked from network); 17 Nov 2011 15:18:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:18:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190247"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:31 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaR026286;	Thu, 17 Nov 2011 07:18:29 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:10 +0000
Message-ID: <1321543033-22090-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>
Subject: [Xen-devel] [PATCH V4 07/10] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    2 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  831 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough.h             |  282 ++++++++++++
 hw/xen_pci_passthrough_config_init.c |   11 +
 xen-all.c                            |   12 +
 6 files changed, 1141 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c

diff --git a/Makefile.target b/Makefile.target
index e527c1b..33435a3 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -221,6 +221,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
new file mode 100644
index 0000000..998470b
--- /dev/null
+++ b/hw/xen_pci_passthrough.c
@@ -0,0 +1,831 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       <ptdev->msi_trans_en is false>
+ *         - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       <ptdev->msi_trans_en is false>
+ *         - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+
+#define PCI_BAR_ENTRIES (6)
+
+#define PT_NR_IRQS          (256)
+char mapped_machine_irq[PT_NR_IRQS] = {0};
+
+void pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+
+/* Config Space */
+static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
+{
+    /* check offset range */
+    if (address >= 0xFF) {
+        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        PT_ERR(d, "Failed to access register with invalid access length. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (address & (len - 1)) {
+        PT_ERR(d, "Failed to access register with invalid access size "
+               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = address;
+
+    if (pt_pci_config_access_check(d, address, len)) {
+        goto exit;
+    }
+
+    /* check power state transition flags */
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        /* can't accept until previous power state transition is completed.
+         * so finish previous request here.
+         */
+        PT_WARN(d, "Guest want to write during power state transition\n");
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, address);
+    if (reg_grp_entry) {
+        /* check 0 Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, address, (uint8_t *)&val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (address & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((address & 3) << 3);
+
+exit:
+    PT_LOG_CONFIG(d, address, val, len);
+    return val;
+}
+
+static void pt_pci_write_config(PCIDevice *d, uint32_t address,
+                                uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = address;
+    XenPTRegInfo *reg = NULL;
+
+    if (pt_pci_config_access_check(d, address, len)) {
+        return;
+    }
+
+    PT_LOG_CONFIG(d, address, val, len);
+
+    /* check unused BAR register */
+    index = pt_bar_offset_to_index(address);
+    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
+        PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                "Register. (addr: 0x%02x, len: %d)\n", address, len);
+    }
+
+    /* check power state transition flags */
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        /* can't accept until previous power state transition is completed.
+         * so finish previous request here.
+         */
+        PT_WARN(d, "Guest want to write during power state transition\n");
+        return;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, address);
+    if (reg_grp_entry) {
+        /* check 0 Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            PT_WARN(d, "Access to 0 Hardwired register. "
+                    "(addr: 0x%02x, len: %d)\n", address, len);
+            return;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, address,
+                             (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (address & 3) << 3;
+    val <<= (address & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to host_pci_device */
+    val >>= (address & 3) << 3;
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = host_pci_set_block(s->real_device, address, (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* ioport/iomem space*/
+static void pt_iomem_map(XenPCIPassthroughState *s, int i,
+                         pcibus_t e_phys, pcibus_t e_size, int type)
+{
+    PCIIORegion *r = &s->dev.io_regions[i];
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int ret = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "e_phys=%#"PRIx64" maddr=%#"PRIx64" type=%d"
+           " len=%#"PRIx64" index=%d first_map=%d\n",
+           e_phys, s->bases[i].access.maddr, type,
+           e_size, i, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        memory_region_del_subregion(r->address_space,
+                                    r->memory);
+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                               old_ebase >> XC_PAGE_SHIFT,
+                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                               DPCI_REMOVE_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "remove old mapping failed!\n");
+            return;
+        }
+    }
+
+    /* map only valid guest address */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        memory_region_add_subregion_overlap(r->address_space,
+                                            e_phys, r->memory, 1);
+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                                   DPCI_ADD_MAPPING);
+
+        if (ret != 0) {
+            PT_ERR(&s->dev, "create new mapping failed!\n");
+        }
+    }
+}
+
+static void pt_ioport_map(XenPCIPassthroughState *s, int i,
+                          pcibus_t e_phys, pcibus_t e_size, int type)
+{
+    PCIIORegion *r = &s->dev.io_regions[i];
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int ret = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "e_phys=%#04"PRIx64" pio_base=%#04"PRIx64" len=%"PRId64
+           " index=%d first_map=%d\n",
+           e_phys, s->bases[i].access.pio_base, e_size, i, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        memory_region_del_subregion(r->address_space,
+                                    r->memory);
+        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, old_ebase,
+                                       s->bases[i].access.pio_base, e_size,
+                                       DPCI_REMOVE_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "remove old mapping failed!\n");
+            return;
+        }
+    }
+
+    /* map only valid guest address (include 0) */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        memory_region_add_subregion_overlap(r->address_space,
+                                            e_phys, r->memory, 1);
+        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, e_phys,
+                                       s->bases[i].access.pio_base, e_size,
+                                       DPCI_ADD_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "create new mapping failed!\n");
+        }
+    }
+
+}
+
+
+/* mapping BAR */
+
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable)
+{
+    PCIDevice *dev = &s->dev;
+    PCIIORegion *r;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    pcibus_t r_size = 0, r_addr = PCI_BAR_UNMAPPED;
+    int rc = 0;
+
+    r = &dev->io_regions[bar];
+
+    /* check valid region */
+    if (!r->size) {
+        return;
+    }
+
+    base = &s->bases[bar];
+    /* skip unused BAR or upper 64bit BAR */
+    if ((base->bar_flag == PT_BAR_FLAG_UNUSED)
+        || (base->bar_flag == PT_BAR_FLAG_UPPER)) {
+           return;
+    }
+
+    /* copy region address to temporary */
+    r_addr = r->addr;
+
+    /* need unmapping in case I/O Space or Memory Space disable */
+    if (((base->bar_flag == PT_BAR_FLAG_IO) && !io_enable) ||
+        ((base->bar_flag == PT_BAR_FLAG_MEM) && !mem_enable)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+    if ((bar == PCI_ROM_SLOT) && (r_addr != PCI_BAR_UNMAPPED)) {
+        reg_grp_entry = pt_find_reg_grp(s, PCI_ROM_ADDRESS);
+        if (reg_grp_entry) {
+            reg_entry = pt_find_reg(reg_grp_entry, PCI_ROM_ADDRESS);
+            if (reg_entry && !(reg_entry->data & PCI_ROM_ADDRESS_ENABLE)) {
+                r_addr = PCI_BAR_UNMAPPED;
+            }
+        }
+    }
+
+    /* prevent guest software mapping memory resource to 00000000h */
+    if ((base->bar_flag == PT_BAR_FLAG_MEM) && (r_addr == 0)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    rc = pci_check_bar_overlap(dev, r_addr, r_size, r->type);
+    if (rc) {
+        PT_WARN(dev, "Region: %d (addr: %#"FMT_PCIBUS
+                ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                bar, r_addr, r_size);
+    }
+
+    /* check whether we need to update the mapping or not */
+    if (r_addr != s->bases[bar].e_physbase) {
+        /* mapping BAR */
+        if (base->bar_flag == PT_BAR_FLAG_IO) {
+            pt_ioport_map(s, bar, r_addr, r_size, r->type);
+        } else {
+            pt_iomem_map(s, bar, r_addr, r_size, r->type);
+        }
+    }
+}
+
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable)
+{
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        pt_bar_mapping_one(s, i, io_enable, mem_enable);
+    }
+}
+
+static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
+{
+    PCIDevice *d = o;
+    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+    return 0;
+}
+static void bar_write(void *o, target_phys_addr_t addr,
+                      uint64_t data, unsigned size)
+{
+    PCIDevice* d = o;
+    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = bar_read,
+    .write = bar_write,
+};
+
+/* register regions */
+static int pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    uint32_t bar_data = 0;
+    HostPCIDevice *d = s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr && r->size) {
+            s->bases[i].e_physbase = r->base_addr;
+            s->bases[i].access.u = r->base_addr;
+
+            /* Register current region */
+            if (r->flags & IORESOURCE_IO) {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-io", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_IO,
+                                 &s->bar[i]);
+            } else if (r->flags & IORESOURCE_PREFETCH) {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-mem", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                                 &s->bar[i]);
+            } else {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-mem", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_MEMORY,
+                                 &s->bar[i]);
+            }
+
+            PT_LOG(&s->dev, "IO region registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64")\n",
+                   r->size, r->base_addr);
+        }
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].e_physbase = d->rom.base_addr;
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL, &s->dev.qdev,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64")\n",
+               d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    int i, type, rc;
+    uint32_t e_size;
+    PCIDevice *d = &s->dev;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        e_size = s->bases[i].e_size;
+        if ((e_size == 0) || (s->bases[i].e_physbase == PT_PCI_BAR_UNMAPPED)) {
+            continue;
+        }
+
+        type = d->io_regions[i].type;
+
+        if (type == PCI_BASE_ADDRESS_SPACE_MEMORY
+            || type == PCI_BASE_ADDRESS_MEM_PREFETCH) {
+            rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                    s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                    s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                    (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                    DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old mem mapping failed!\n");
+                continue;
+            }
+
+        } else if (type == PCI_BASE_ADDRESS_SPACE_IO) {
+            rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                        s->bases[i].e_physbase,
+                        s->bases[i].access.pio_base,
+                        e_size,
+                        DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old io mapping failed!\n");
+                continue;
+            }
+        }
+    }
+}
+
+static int pt_initfn(PCIDevice *pcidev)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        PT_ERR(pcidev, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    PT_LOG(pcidev, "Assigning real physical device %02x:%02x.%x"
+           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    s->real_device = host_pci_device_get(bus, slot, func);
+    if (!s->real_device) {
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device->is_virtfn;
+    if (s->is_virtfn) {
+        PT_LOG(pcidev, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+               s->real_device->domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (host_pci_get_block(s->real_device, 0, pcidev->config,
+                           PCI_CONFIG_SPACE_SIZE) == -1) {
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
+    /* Handle real device's MMIO/PIO BARs */
+    pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        PT_LOG(pcidev, "no pin interrupt\n");
+        goto out;
+    }
+
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        PT_ERR(pcidev, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+               machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        host_pci_set_word(s->real_device,
+                          PCI_COMMAND,
+                          pci_get_word(s->dev.config + PCI_COMMAND)
+                          | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (rc < 0 && machine_irq != 0) {
+        uint8_t e_device = PCI_SLOT(s->dev.devfn);
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq, 0,
+                                       e_device, e_intx);
+        if (rc < 0) {
+            PT_ERR(pcidev, "Binding of interrupt %i failed! (rc: %d)\n",
+                   e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            host_pci_set_word(s->real_device, PCI_COMMAND,
+                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                              | PCI_COMMAND_INTX_DISABLE);
+            mapped_machine_irq[machine_irq]--;
+
+            if (mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    PT_ERR(pcidev, "Unmapping of machine interrupt %i failed!"
+                           " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
+           "\nIRQ type = %s\n", bus, slot, func, "INTx");
+
+    return 0;
+}
+
+static int pt_unregister_device(PCIDevice *pcidev)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
+    uint8_t e_device, e_intx;
+    uint8_t machine_irq;
+    int rc;
+
+    /* Unbind interrupt */
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+    machine_irq = s->machine_irq;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);
+        if (rc < 0) {
+            PT_ERR(pcidev, "Unbinding of interrupt failed! rc=%d\n", rc);
+        }
+    }
+
+    if (machine_irq) {
+        mapped_machine_irq[machine_irq]--;
+
+        if (mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                PT_ERR(pcidev, "Unmaping of interrupt failed! rc=%d\n", rc);
+            }
+        }
+    }
+
+    /* unregister real device's MMIO/PIO BARs */
+    pt_unregister_regions(s);
+
+    host_pci_device_put(s->real_device);
+
+    return 0;
+}
+
+static PCIDeviceInfo xen_pci_passthrough = {
+    .init = pt_initfn,
+    .exit = pt_unregister_device,
+    .qdev.name = "xen-pci-passthrough",
+    .qdev.desc = "Assign an host pci device with Xen",
+    .qdev.size = sizeof(XenPCIPassthroughState),
+    .config_read = pt_pci_read_config,
+    .config_write = pt_pci_write_config,
+    .is_express = 0,
+    .qdev.props = (Property[]) {
+        DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+        DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
+                        0, false),
+        DEFINE_PROP_END_OF_LIST(),
+    }
+};
+
+static void xen_passthrough_register(void)
+{
+    pci_qdev_register(&xen_pci_passthrough);
+}
+
+device_init(xen_passthrough_register);
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
new file mode 100644
index 0000000..110325c
--- /dev/null
+++ b/hw/xen_pci_passthrough.h
@@ -0,0 +1,282 @@
+#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
+#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "host-pci-device.h"
+
+/* #define PT_LOGGING_ENABLED */
+/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
+
+void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
+
+#ifdef PT_LOGGING_ENABLED
+#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
+#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
+#else
+#  define PT_LOG(d, _f, _a...)
+#  define PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+#  define PT_LOG_CONFIG(d, addr, val, len) \
+    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+           __func__, addr, val, len)
+#else
+#  define PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+typedef int (*conf_dword_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint32_t dev_value, uint32_t *val);
+typedef int (*conf_word_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint16_t dev_value, uint16_t *val);
+typedef int (*conf_byte_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint8_t dev_value, uint8_t *val);
+
+/* power state transition */
+#define PT_FLAG_TRANSITING  0x0001
+
+#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
+#define PT_PCI_BAR_UNMAPPED (-1)
+#define PT_UNASSIGNED_PIRQ (-1)
+
+
+typedef enum {
+    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
+    GRP_TYPE_EMU,                               /* emul reg group */
+} RegisterGroupType;
+
+typedef enum {
+    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
+    PT_BAR_FLAG_IO,                             /* I/O type BAR */
+    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
+    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
+} PTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* Virtual phys base & size */
+    uint32_t e_physbase;
+    uint32_t e_size;
+    /* Index of region in qemu */
+    uint32_t memory_index;
+    /* BAR flag */
+    PTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    conf_reg_init init;
+    /* read/write/restore function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            conf_dword_write write;
+            conf_dword_read read;
+            conf_dword_restore restore;
+        } dw;
+        struct {
+            conf_word_write write;
+            conf_word_read read;
+            conf_word_restore restore;
+        } w;
+        struct {
+            conf_byte_write write;
+            conf_byte_read read;
+            conf_byte_restore restore;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data;
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    RegisterGroupType grp_type;
+    uint8_t grp_size;
+    pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_reg_tbl;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+typedef struct XenPTPM {
+    QEMUTimer *pm_timer;  /* QEMUTimer struct */
+    int no_soft_reset;    /* No Soft Reset flags */
+    uint16_t flags;       /* power state transition flags */
+    uint16_t pmc_field;   /* Power Management Capabilities field */
+    int pm_delay;         /* power state transition delay */
+    uint16_t cur_state;   /* current power state */
+    uint16_t req_state;   /* requested power state */
+    uint32_t pm_base;     /* Power Management Capability reg base offset */
+    uint32_t aer_base;    /* AER Capability reg base offset */
+} XenPTPM;
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    HostPCIDevice *real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
+
+    uint32_t machine_irq;
+
+    uint32_t power_mgmt;
+    XenPTPM *pm_state;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+};
+
+int pt_config_init(XenPCIPassthroughState *s);
+void pt_config_delete(XenPCIPassthroughState *s);
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable);
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable);
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the intertupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = pci_read_intx(s);
+
+    PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+               " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
new file mode 100644
index 0000000..1e9de64
--- /dev/null
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pci_passthrough.h"
+
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index b5e28ab..0e3bbcf 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -979,3 +979,15 @@ void destroy_hvm_domain(void)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:49:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:49:46 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Di-00027S-Gq
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:49:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4DQ-00065X-NV; Thu, 17 Nov 2011 07:49:28 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jY-0005hS-DJ
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:39 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321543105!3550834!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29453 invoked from network); 17 Nov 2011 15:18:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:18:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190247"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:31 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaR026286;	Thu, 17 Nov 2011 07:18:29 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:10 +0000
Message-ID: <1321543033-22090-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>
Subject: [Xen-devel] [PATCH V4 07/10] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    2 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  831 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough.h             |  282 ++++++++++++
 hw/xen_pci_passthrough_config_init.c |   11 +
 xen-all.c                            |   12 +
 6 files changed, 1141 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c

diff --git a/Makefile.target b/Makefile.target
index e527c1b..33435a3 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -221,6 +221,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
new file mode 100644
index 0000000..998470b
--- /dev/null
+++ b/hw/xen_pci_passthrough.c
@@ -0,0 +1,831 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       <ptdev->msi_trans_en is false>
+ *         - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       <ptdev->msi_trans_en is false>
+ *         - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+
+#define PCI_BAR_ENTRIES (6)
+
+#define PT_NR_IRQS          (256)
+char mapped_machine_irq[PT_NR_IRQS] = {0};
+
+void pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+
+/* Config Space */
+static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
+{
+    /* check offset range */
+    if (address >= 0xFF) {
+        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        PT_ERR(d, "Failed to access register with invalid access length. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (address & (len - 1)) {
+        PT_ERR(d, "Failed to access register with invalid access size "
+               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = address;
+
+    if (pt_pci_config_access_check(d, address, len)) {
+        goto exit;
+    }
+
+    /* check power state transition flags */
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        /* can't accept until previous power state transition is completed.
+         * so finish previous request here.
+         */
+        PT_WARN(d, "Guest want to write during power state transition\n");
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, address);
+    if (reg_grp_entry) {
+        /* check 0 Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, address, (uint8_t *)&val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (address & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((address & 3) << 3);
+
+exit:
+    PT_LOG_CONFIG(d, address, val, len);
+    return val;
+}
+
+static void pt_pci_write_config(PCIDevice *d, uint32_t address,
+                                uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = address;
+    XenPTRegInfo *reg = NULL;
+
+    if (pt_pci_config_access_check(d, address, len)) {
+        return;
+    }
+
+    PT_LOG_CONFIG(d, address, val, len);
+
+    /* check unused BAR register */
+    index = pt_bar_offset_to_index(address);
+    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
+        PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                "Register. (addr: 0x%02x, len: %d)\n", address, len);
+    }
+
+    /* check power state transition flags */
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        /* can't accept until previous power state transition is completed.
+         * so finish previous request here.
+         */
+        PT_WARN(d, "Guest want to write during power state transition\n");
+        return;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, address);
+    if (reg_grp_entry) {
+        /* check 0 Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            PT_WARN(d, "Access to 0 Hardwired register. "
+                    "(addr: 0x%02x, len: %d)\n", address, len);
+            return;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, address,
+                             (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (address & 3) << 3;
+    val <<= (address & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to host_pci_device */
+    val >>= (address & 3) << 3;
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = host_pci_set_block(s->real_device, address, (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* ioport/iomem space*/
+static void pt_iomem_map(XenPCIPassthroughState *s, int i,
+                         pcibus_t e_phys, pcibus_t e_size, int type)
+{
+    PCIIORegion *r = &s->dev.io_regions[i];
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int ret = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "e_phys=%#"PRIx64" maddr=%#"PRIx64" type=%d"
+           " len=%#"PRIx64" index=%d first_map=%d\n",
+           e_phys, s->bases[i].access.maddr, type,
+           e_size, i, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        memory_region_del_subregion(r->address_space,
+                                    r->memory);
+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                               old_ebase >> XC_PAGE_SHIFT,
+                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                               DPCI_REMOVE_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "remove old mapping failed!\n");
+            return;
+        }
+    }
+
+    /* map only valid guest address */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        memory_region_add_subregion_overlap(r->address_space,
+                                            e_phys, r->memory, 1);
+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                                   DPCI_ADD_MAPPING);
+
+        if (ret != 0) {
+            PT_ERR(&s->dev, "create new mapping failed!\n");
+        }
+    }
+}
+
+static void pt_ioport_map(XenPCIPassthroughState *s, int i,
+                          pcibus_t e_phys, pcibus_t e_size, int type)
+{
+    PCIIORegion *r = &s->dev.io_regions[i];
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int ret = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "e_phys=%#04"PRIx64" pio_base=%#04"PRIx64" len=%"PRId64
+           " index=%d first_map=%d\n",
+           e_phys, s->bases[i].access.pio_base, e_size, i, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        memory_region_del_subregion(r->address_space,
+                                    r->memory);
+        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, old_ebase,
+                                       s->bases[i].access.pio_base, e_size,
+                                       DPCI_REMOVE_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "remove old mapping failed!\n");
+            return;
+        }
+    }
+
+    /* map only valid guest address (include 0) */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        memory_region_add_subregion_overlap(r->address_space,
+                                            e_phys, r->memory, 1);
+        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, e_phys,
+                                       s->bases[i].access.pio_base, e_size,
+                                       DPCI_ADD_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "create new mapping failed!\n");
+        }
+    }
+
+}
+
+
+/* mapping BAR */
+
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable)
+{
+    PCIDevice *dev = &s->dev;
+    PCIIORegion *r;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    pcibus_t r_size = 0, r_addr = PCI_BAR_UNMAPPED;
+    int rc = 0;
+
+    r = &dev->io_regions[bar];
+
+    /* check valid region */
+    if (!r->size) {
+        return;
+    }
+
+    base = &s->bases[bar];
+    /* skip unused BAR or upper 64bit BAR */
+    if ((base->bar_flag == PT_BAR_FLAG_UNUSED)
+        || (base->bar_flag == PT_BAR_FLAG_UPPER)) {
+           return;
+    }
+
+    /* copy region address to temporary */
+    r_addr = r->addr;
+
+    /* need unmapping in case I/O Space or Memory Space disable */
+    if (((base->bar_flag == PT_BAR_FLAG_IO) && !io_enable) ||
+        ((base->bar_flag == PT_BAR_FLAG_MEM) && !mem_enable)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+    if ((bar == PCI_ROM_SLOT) && (r_addr != PCI_BAR_UNMAPPED)) {
+        reg_grp_entry = pt_find_reg_grp(s, PCI_ROM_ADDRESS);
+        if (reg_grp_entry) {
+            reg_entry = pt_find_reg(reg_grp_entry, PCI_ROM_ADDRESS);
+            if (reg_entry && !(reg_entry->data & PCI_ROM_ADDRESS_ENABLE)) {
+                r_addr = PCI_BAR_UNMAPPED;
+            }
+        }
+    }
+
+    /* prevent guest software mapping memory resource to 00000000h */
+    if ((base->bar_flag == PT_BAR_FLAG_MEM) && (r_addr == 0)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    rc = pci_check_bar_overlap(dev, r_addr, r_size, r->type);
+    if (rc) {
+        PT_WARN(dev, "Region: %d (addr: %#"FMT_PCIBUS
+                ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                bar, r_addr, r_size);
+    }
+
+    /* check whether we need to update the mapping or not */
+    if (r_addr != s->bases[bar].e_physbase) {
+        /* mapping BAR */
+        if (base->bar_flag == PT_BAR_FLAG_IO) {
+            pt_ioport_map(s, bar, r_addr, r_size, r->type);
+        } else {
+            pt_iomem_map(s, bar, r_addr, r_size, r->type);
+        }
+    }
+}
+
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable)
+{
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        pt_bar_mapping_one(s, i, io_enable, mem_enable);
+    }
+}
+
+static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
+{
+    PCIDevice *d = o;
+    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+    return 0;
+}
+static void bar_write(void *o, target_phys_addr_t addr,
+                      uint64_t data, unsigned size)
+{
+    PCIDevice* d = o;
+    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = bar_read,
+    .write = bar_write,
+};
+
+/* register regions */
+static int pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    uint32_t bar_data = 0;
+    HostPCIDevice *d = s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr && r->size) {
+            s->bases[i].e_physbase = r->base_addr;
+            s->bases[i].access.u = r->base_addr;
+
+            /* Register current region */
+            if (r->flags & IORESOURCE_IO) {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-io", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_IO,
+                                 &s->bar[i]);
+            } else if (r->flags & IORESOURCE_PREFETCH) {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-mem", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                                 &s->bar[i]);
+            } else {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-mem", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_MEMORY,
+                                 &s->bar[i]);
+            }
+
+            PT_LOG(&s->dev, "IO region registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64")\n",
+                   r->size, r->base_addr);
+        }
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].e_physbase = d->rom.base_addr;
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL, &s->dev.qdev,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64")\n",
+               d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    int i, type, rc;
+    uint32_t e_size;
+    PCIDevice *d = &s->dev;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        e_size = s->bases[i].e_size;
+        if ((e_size == 0) || (s->bases[i].e_physbase == PT_PCI_BAR_UNMAPPED)) {
+            continue;
+        }
+
+        type = d->io_regions[i].type;
+
+        if (type == PCI_BASE_ADDRESS_SPACE_MEMORY
+            || type == PCI_BASE_ADDRESS_MEM_PREFETCH) {
+            rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                    s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                    s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                    (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                    DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old mem mapping failed!\n");
+                continue;
+            }
+
+        } else if (type == PCI_BASE_ADDRESS_SPACE_IO) {
+            rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                        s->bases[i].e_physbase,
+                        s->bases[i].access.pio_base,
+                        e_size,
+                        DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old io mapping failed!\n");
+                continue;
+            }
+        }
+    }
+}
+
+static int pt_initfn(PCIDevice *pcidev)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        PT_ERR(pcidev, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    PT_LOG(pcidev, "Assigning real physical device %02x:%02x.%x"
+           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    s->real_device = host_pci_device_get(bus, slot, func);
+    if (!s->real_device) {
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device->is_virtfn;
+    if (s->is_virtfn) {
+        PT_LOG(pcidev, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+               s->real_device->domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (host_pci_get_block(s->real_device, 0, pcidev->config,
+                           PCI_CONFIG_SPACE_SIZE) == -1) {
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
+    /* Handle real device's MMIO/PIO BARs */
+    pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        PT_LOG(pcidev, "no pin interrupt\n");
+        goto out;
+    }
+
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        PT_ERR(pcidev, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+               machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        host_pci_set_word(s->real_device,
+                          PCI_COMMAND,
+                          pci_get_word(s->dev.config + PCI_COMMAND)
+                          | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (rc < 0 && machine_irq != 0) {
+        uint8_t e_device = PCI_SLOT(s->dev.devfn);
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq, 0,
+                                       e_device, e_intx);
+        if (rc < 0) {
+            PT_ERR(pcidev, "Binding of interrupt %i failed! (rc: %d)\n",
+                   e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            host_pci_set_word(s->real_device, PCI_COMMAND,
+                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                              | PCI_COMMAND_INTX_DISABLE);
+            mapped_machine_irq[machine_irq]--;
+
+            if (mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    PT_ERR(pcidev, "Unmapping of machine interrupt %i failed!"
+                           " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
+           "\nIRQ type = %s\n", bus, slot, func, "INTx");
+
+    return 0;
+}
+
+static int pt_unregister_device(PCIDevice *pcidev)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
+    uint8_t e_device, e_intx;
+    uint8_t machine_irq;
+    int rc;
+
+    /* Unbind interrupt */
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+    machine_irq = s->machine_irq;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);
+        if (rc < 0) {
+            PT_ERR(pcidev, "Unbinding of interrupt failed! rc=%d\n", rc);
+        }
+    }
+
+    if (machine_irq) {
+        mapped_machine_irq[machine_irq]--;
+
+        if (mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                PT_ERR(pcidev, "Unmaping of interrupt failed! rc=%d\n", rc);
+            }
+        }
+    }
+
+    /* unregister real device's MMIO/PIO BARs */
+    pt_unregister_regions(s);
+
+    host_pci_device_put(s->real_device);
+
+    return 0;
+}
+
+static PCIDeviceInfo xen_pci_passthrough = {
+    .init = pt_initfn,
+    .exit = pt_unregister_device,
+    .qdev.name = "xen-pci-passthrough",
+    .qdev.desc = "Assign an host pci device with Xen",
+    .qdev.size = sizeof(XenPCIPassthroughState),
+    .config_read = pt_pci_read_config,
+    .config_write = pt_pci_write_config,
+    .is_express = 0,
+    .qdev.props = (Property[]) {
+        DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+        DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
+                        0, false),
+        DEFINE_PROP_END_OF_LIST(),
+    }
+};
+
+static void xen_passthrough_register(void)
+{
+    pci_qdev_register(&xen_pci_passthrough);
+}
+
+device_init(xen_passthrough_register);
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
new file mode 100644
index 0000000..110325c
--- /dev/null
+++ b/hw/xen_pci_passthrough.h
@@ -0,0 +1,282 @@
+#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
+#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "host-pci-device.h"
+
+/* #define PT_LOGGING_ENABLED */
+/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
+
+void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
+
+#ifdef PT_LOGGING_ENABLED
+#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
+#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
+#else
+#  define PT_LOG(d, _f, _a...)
+#  define PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+#  define PT_LOG_CONFIG(d, addr, val, len) \
+    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+           __func__, addr, val, len)
+#else
+#  define PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+typedef int (*conf_dword_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint32_t dev_value, uint32_t *val);
+typedef int (*conf_word_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint16_t dev_value, uint16_t *val);
+typedef int (*conf_byte_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint8_t dev_value, uint8_t *val);
+
+/* power state transition */
+#define PT_FLAG_TRANSITING  0x0001
+
+#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
+#define PT_PCI_BAR_UNMAPPED (-1)
+#define PT_UNASSIGNED_PIRQ (-1)
+
+
+typedef enum {
+    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
+    GRP_TYPE_EMU,                               /* emul reg group */
+} RegisterGroupType;
+
+typedef enum {
+    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
+    PT_BAR_FLAG_IO,                             /* I/O type BAR */
+    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
+    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
+} PTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* Virtual phys base & size */
+    uint32_t e_physbase;
+    uint32_t e_size;
+    /* Index of region in qemu */
+    uint32_t memory_index;
+    /* BAR flag */
+    PTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    conf_reg_init init;
+    /* read/write/restore function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            conf_dword_write write;
+            conf_dword_read read;
+            conf_dword_restore restore;
+        } dw;
+        struct {
+            conf_word_write write;
+            conf_word_read read;
+            conf_word_restore restore;
+        } w;
+        struct {
+            conf_byte_write write;
+            conf_byte_read read;
+            conf_byte_restore restore;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data;
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    RegisterGroupType grp_type;
+    uint8_t grp_size;
+    pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_reg_tbl;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+typedef struct XenPTPM {
+    QEMUTimer *pm_timer;  /* QEMUTimer struct */
+    int no_soft_reset;    /* No Soft Reset flags */
+    uint16_t flags;       /* power state transition flags */
+    uint16_t pmc_field;   /* Power Management Capabilities field */
+    int pm_delay;         /* power state transition delay */
+    uint16_t cur_state;   /* current power state */
+    uint16_t req_state;   /* requested power state */
+    uint32_t pm_base;     /* Power Management Capability reg base offset */
+    uint32_t aer_base;    /* AER Capability reg base offset */
+} XenPTPM;
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    HostPCIDevice *real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
+
+    uint32_t machine_irq;
+
+    uint32_t power_mgmt;
+    XenPTPM *pm_state;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+};
+
+int pt_config_init(XenPCIPassthroughState *s);
+void pt_config_delete(XenPCIPassthroughState *s);
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable);
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable);
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the intertupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = pci_read_intx(s);
+
+    PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+               " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
new file mode 100644
index 0000000..1e9de64
--- /dev/null
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pci_passthrough.h"
+
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index b5e28ab..0e3bbcf 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -979,3 +979,15 @@ void destroy_hvm_domain(void)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:51:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:51:27 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4FL-00027h-KV
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:51:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Ez-0006Wm-D5; Thu, 17 Nov 2011 07:51:05 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jV-0005gs-Ms
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:40 -0800
X-Env-Sender: yujiageng734@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321543108!3550845!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29288 invoked from network); 17 Nov 2011 15:18:30 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:18:30 -0000
Received: by ywn1 with SMTP id 1so1970105ywn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 07:18:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ZlyEdpuDpaPtkrh3JhToY31OUH5P+s/ZXUygsnc3XrU=;
	b=wH8+sALpihRQGAkkLJovOR/q2b3hu9pAdB9j6DQAL51dEkFPIl+CVsD3AciATiuOoc
	0lmJuHbo1z/P+PZQChuhZnyog4Ay+68Ys+t0wU1t+bAyKfT6xk3xELwV5Vuy1WDwQL9i
	M4p+Cun19FbNEZTw17mP7+3uhrfZn3/GiKDsQ=
MIME-Version: 1.0
Received: by 10.42.172.70 with SMTP id m6mr26787441icz.37.1321543102510; Thu,
	17 Nov 2011 07:18:22 -0800 (PST)
Received: by 10.42.170.197 with HTTP; Thu, 17 Nov 2011 07:18:22 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111091656060.3519@kaball-desktop>
References: <alpine.DEB.2.00.1109021401000.12963@kaball-desktop>
	<CA8694A1.20379%keir.xen@gmail.com>
	<CAJ0pt17eoZbEnmziLaSd1Cxi+sU90rJ-c8TSgt+ikE3wZj1jhA@mail.gmail.com>
	<alpine.DEB.2.00.1109151110020.12963@kaball-desktop>
	<CAJ0pt15daSuXGi_8T3NS53E2Xv0bYV90b94100Wi6ajt99gedQ@mail.gmail.com>
	<alpine.DEB.2.00.1111081412270.3519@kaball-desktop>
	<CAJ0pt154u9GY-6x6ZJA2UDyfgE135hZkr27XHnJ2ooaaNtTEmw@mail.gmail.com>
	<alpine.DEB.2.00.1111091340110.3519@kaball-desktop>
	<CAJ0pt15HEYGkXXR00tkyc6FXwt7eGKi-0yGo67y=UeWEuNrbTg@mail.gmail.com>
	<alpine.DEB.2.00.1111091656060.3519@kaball-desktop>
Date: Thu, 17 Nov 2011 23:18:22 +0800
Message-ID: <CAJ0pt17qsAjO4YzbNNvNxWsbG0B2ZRrOs1QwS7ueNxpxhpD9Fw@mail.gmail.com>
Subject: Re: [Xen-devel] Re: Linux Stubdom Problem
From: Jiageng Yu <yujiageng734@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Content-Type: multipart/mixed; boundary=90e6ba6e8f602e34a604b1efbbe7
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Anthony PERARD <anthony.perard@gmail.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--90e6ba6e8f602e34a604b1efbbe7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2011/11/10 Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> On Wed, 9 Nov 2011, Jiageng Yu wrote:
> > The keyboard driver is OK now. I am working on network device. In
> > linux stubdom, I have udev, ifconfig and brctl tools. After udevd
> > started, stubdom executes "ifconfig eth0 IPadderss netmask netgate up"
> > to setup the network. When qemu in stubdom creates a tapxx interface
> > for hvm guest, =C2=A0the script should be executed to build a net bridg=
e.
> >
> > =C2=A0 =C2=A0 =C2=A0 /sbin/brctl addbr eth0
> > =C2=A0 =C2=A0 =C2=A0 /sbin/brctl addif eth0 tapXX
> >
> > Therefore, the hvm guest has the network device. Is this plan
> > reasonable? Or have better one?
>
> The bridge should be called xenbr0, the stubdom's network interface
> (that should probably called eth0) should be added to the bridge at boot
> time.
>
> Like you said, when qemu starts is going to create a tap interface, on
> Linux usually we rely on a udev script to add the tap interface to the
> bridge. The script is tools/hotplug/Linux/vif-setup, that calls
> tools/hotplug/Linux/vif-bridge.
>
> So at the end you have:
>
> xenbr0 (bridge)
> ||
> |+-------------------------------+
> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> eth0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> (stubdom network interface) =C2=A0 =C2=A0 =C2=A0tapXX
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (qemu's tap interface)


Hi Stefano,

=C2=A0 =C2=A0=C2=A0I have a prototype of network of linux based stubdom, as=
 shown in
attached figure. I list my design=C2=A0points, please comment on them.

    1. Qemu-ifup script in Linux stubdom.

     Qemu in stubdom invokes qemu-ifup script to setup the
bridge(net/tap.c). Because the linux stubdom only has nash and can not
execute the qemu-ifup script, I implement a c version of qemu-ifup
script. Using the following way, the qemu will invoke qemu-ifup
program in stubdom.

diff -r 0f36c2eec2e1 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jul 28 15:40:54 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Nov 17 22:41:29 2011 +0000
@@ -29,9 +29,12 @@
 #include "libxl.h"
 #include "flexarray.h"

-static const char *libxl_tapif_script(libxl__gc *gc)
+static const char *libxl_tapif_script(libxl__gc *gc,
+                                      libxl_device_model_info *info)
 {
 #ifdef __linux__
+    if(info->device_model_linux_stubdomain)
+        return libxl__sprintf(gc, "/bin/qemu-ifup");
     return libxl__strdup(gc, "no");
 #else
     return libxl__sprintf(gc, "%s/qemu-ifup", libxl_xen_script_dir_path())=
;

     I do not use libxl_xen_script_dir_path() to determine the path of
qemu-ifup, because we don't want include xen-unstable.hg/Config.mk in
linux stubdom. Therefore, I hardcoded this path.

    2. Network tools.

    Our linux based stubdom do not have the real shell and IP stack,
so we must custom the network tools. I notice the bridge-utils-1.5
version creates AF_LOCAL socket, so brctl can be used without
modification. But ifconfig would not be so luck. I need to rewrite
ifconfig and make it only support bring up the interfaces.

    3. The mac address.

    If we declare the mac address in stubdom-cfg file, the eth0 in
stubdom and eth0 in hvm guest will be set to the same mac address.

   do_domain_create (or libxl__create_stubdom)
         -->libxl_device_nic_add

   As a temporary solution, I hardcoded a static mac address for linux
stdubom in libxl__create_stubdom().


  Thanks.


Jiageng Yu.

--90e6ba6e8f602e34a604b1efbbe7
Content-Type: image/png; name="Screenshot-QEMU (fedora14-dm)-1.png"
Content-Disposition: attachment; 
	filename="Screenshot-QEMU (fedora14-dm)-1.png"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gv3w7i6x0

iVBORw0KGgoAAAANSUhEUgAAAyYAAAJwCAYAAAB8l3VsAAAABHNCSVQICAgIfAhkiAAAABl0RVh0
U29mdHdhcmUAZ25vbWUtc2NyZWVuc2hvdO8Dvz4AACAASURBVHic7d159CXXXRj47+tuSS1ZkrW0
LFnebdnYGBtvYALGGAwEs+aEMGkPDmGkmNgH5gARNsHJwJCZGKJEGSCskyiDSU7cmG3CsAUDIoDN
YiCysQHvNt4kubUvLXX3r3/zx09Pev36VdWtV7fqVr33+Zyjo1+/V+8uVbdu3W/VrapZrHDo6ut2
V30OAADQ1dH/+PrZ8mcHFv8xD0iOfu43DVUmAADYaM990uXZ0/zrP31bPPNFXzCpdI9fdtXD/z4U
sRd3LAQoDwcmh66+bve2F74yIiJmOyeyFwYAALbRsZ2Is08dz5rm7OTxyaW7GGPM445DEbvz4ORA
xF5QcvvzvyFmp05mLQAAAGy7YzsR+zOf+J/tnJhcuqtijduf/w1x6Oq94OTA4sIAAEBeD+xEnHcy
90D/+OTSbYo3Dhy6+rrdO5/91THbSbta8vjf/q9rFebjL/+6tX4HsKn+0XMvip/40sfGt//OzfHj
N93x8Odf+qRHxb/7kiviqRedHftmEc/7mQ/Fe44+uFYezz50Ttz0TU+NiIiz/u1fZSn32HSt48ue
cF689RueFD9+0x3x7b9zc+7iAcSxnYid7AP9E0XSfcoF+2PfLOJDd+/E/GlZs4h4/Pn7Y/8s4iP3
7FSmWxVv3Pnsr45DV8fugYiI2al2Ffq73/AVrZb/xZ/7jdZ5ALT1hAvPiu/7/Cviy55yflx27oH4
9LGT8dsfuTe+/+23xEfvemSu7PHveu7K35/9b9512ve7EfGc//jeeN/te0HBZ1xyTrzr6s+IWcXy
z//p98V7jj5Q+dmi887aF//i8y+Lux7ciZ9+19GYnTr18Hc/9vK9oOTGv7k33n30gbj9vgfWnmo7
O7V/4e/h+uGf/donxYuvPC+uPP+siKheD/tmEb/xDU+Nlz3x/Nrl6nSt43//6F3xrk8/EP/4sy+K
H/uzW+P9d6wXBAJUeWAnYudE3j54387evSAp6T7pggPxiicdjLd96sH4i9vql69L92mPPhBf+8Sz
4tRuxE1Hd+N3P/FgzCLiix9/MJ5z6Vmxfxbxix86GR+5+8xj1r6d44199F5gkni1ZNHvvf09Scu9
9POfHevmAZDqiReeHW9/1dPjsvMOxJ/dfH/88vvujM957KPiVc++OL7iqRfE57/pr08LTiIi/st7
bo/bjz3SNy33U7OI+LbnXRLf/taPRUTEtz7/sbH4bMMzlj+1k/RZRMQ3PudQXHbegfjP7749Hnjw
+GnpPuWisyMi4nW/9bH4i08fe7gs65ideuTMVZd++Kx9szhxKv1J8p935Xnxjk/dF1/79IseLseq
/F/3eVfESx7/qNPK27acOer48391ezz3pVfGtz3/kviOh7Y3QDYnj8epHq5spKb7RY89GCdO7sQL
D+2Pd95y/9rp3v/gbpzcOTs+cOeJeM7FZ8WpnQMxi4jPvGhfvP/2B+Kqi86K+x84HqdOnnnVpO6K
ydyBhwuQ6DUvOxXf/c3Pi79+yVkxi4jZbBa7u7sxm80iZrOYxSz2Lfz91Cc/PR7z6V+L78scJQIs
+r6XPDEuO+9A/NoH7oyvf8t7Yzf2zsb/wjd8Rrziqovi+77girjm//vgab+5/u0fj/c8NPCPOHPw
f/uxk/Gqz7okvvfGj8YsIl717Evi9mMn45Jz927PW+479zrd5s8iIr7mqgsjIuIPPnrnad8/8IYX
P/z3n179rIiIOPjGP374s9e88PJ47Ysuj6defDDuPHYyfv6vbo9/duPfxP0n9q64HDywL37iK58S
f+eZl8TH7z4eP/aOR6YmzfOZRcS3v/ix8S0veEw84dHnxNH7T8Rb3nNbfN9//3g8cPLUaeV4/W99
NF79gsvjaRcfjPN+YK8cX/7Ui+JffskT4ikXnRPnnrUvbr//ZLz1w3fF637ro3Hb/XsHnaf8yJ+f
ls6q9fCixz4qvvcLHxv/x+99PL7/ZU+oXV+LUuo4z/d/u/Fj8doXXR5n75/Fd731o3HBOfvjf3/p
Xl7XvvUjceQ9t0VExO9/5M6Il14ZX/W0C+M7f8PxCshs50QvU65S0z0Qp+KuB07FhWfva1y+Lt2P
3Xki/vzmWTzvsoPx/tsfiOdesnci7QO3PxBXXXR2/Omn7o9P3L36qndK/77WVK6IiH2zfRGziFnM
Ima7MYtZzGaPBCUPLzMvjKlcQI++7Cl7A/2fescnIk6diFnsTcX6qXd8Il5x1UXx8qdceEY/9F2f
d0XctnDF5HW/+aHTvv/pm26Of/K3Hh//8DmXRETE+Wfvj+vf/vG49vMfHxFn9muzUyeTPouIeMEV
e1cJPnDbvad9/6N/8sn4ts+9MiIi3vwXt8Ztxx75/f/64sfFdV/25PjUPcfjZ266JZ5z+aPitS+6
PC47b3/8g1/864iI+N4vfHK88rMOxafvOxG/95E743u+4MqFsuyl851/6/Hxxpc/Me44djLedNMt
8aVPvSi+/cWPjUvP3R+v/uX3nVbOf/GyJ8Qv/OXReOfNj5Tzcefvi1vvPR5/9LG7IyLiJU+6MP7n
zzoUjzowi8M/v/oej+X1cP7Z++Nn/s5V8fa/uTv+zds++khgUrG+FqXUce7VL3hMvPOWe+MVV10S
P/lVT41b7j0ef/yJu+Mrn35J/LtXPCV+6S9vieM7u/HeT+/V5YmPPicOHYy47X7HLCCfWR+ByUOP
361K9zmXHYzPu/K82D+LuOScWdx5bCcuOWd/vPqzLoid3Yg/+uT98RefPjOIaEr3tz98V5za2Ynn
PeZgvO/2vZN7V110dvzZzffFjX9zb315+5rKtW/f3hWRePjwP9v7c7Yv9s32rqQsnn80lQvo06Xn
7d3LcPNdx07rb26+e6/TPHTeWWf0Q698zmNO+/frf/30QfnP/8Ut8arnPiZe86LHRkTELfcej194
9y2PBCbL/dqqaUgVU5Mufuiqy73Hjp/2/et//X0PBybX/8FH4y9vve/hnvRbP2evHDd96p544MTJ
eOen7onPfdwF8fWfeSi+41dmcfuxE3H4sy6LiIjX/cb74y3vvjV+/7MeEz/99Z95Wnlf86IrIiLi
2l9/fxz5i1vis684P/7wH78oXvmcy+K7fu19cfeDj5Tne3/7Q/Gjf/Txvd8/9NnP/Nkn4pN3HYvP
fdyFceHBA/Hum++NZx06L77kqRdV9/VL6+GH/vZVcdHB/fHl/89fxu7JkyuX+9dfcdVpSbzuNz4Q
EZFUx7nv+c0PxFs/cHvc+j1fGAcP7Is3vPWD8evvuy1u/2cvjQvO3h9PvuCseP9t98e99z8y7eDS
s2dx+z2OWUBGOyf6mcpVk+7LHndx3HP8ZNx98lTccf/xuO/EqXj/bXt927kH9sXLHnduvPNT97RO
dxYRcepk7J46Fbs7e33nqVOnInZOxu7JE1E16beXqVwPJ/7QVK29qVwP/fuhKyR7fy8HJs4+Af25
7f4Tcfn5Z8fl5+2Ldy/0N1ect9cv3XHszEvIn/Ojfxh/eesjZ3eWp3KdOH48/sOffDze8MV7T3z6
lzd+ME4cf+Q+lXl6O6d2Y/++WRzY3YnZzok4sO+RlE6eWH3p+o77T8Rjzj87LjxQ3T/Odk6e9t3j
LjwnIiJe8YxLT18uIh73qH1xx70n4vJH7V1Wf/+t98Rs50R84NP3LKS3l9aVF+yl895b7o7Zzol4
7y13RUTE/tksrjh3FvcsXC14+4dvO6N8P/p1nxn/ywsfd0Z5Lzh7f3JdvvGzr4iP3HEsfvSrn37a
cj/0iqvihj/9eLzlXTfHt7748ad99/pf3bsak1LHuQ9++p6479gDp/37wQcfubn97NjbZo8+56yH
P7vj3vsds4CsZjsnern5vS7dGz98Z3z+48+Pc8/ZFxcf3B8fvOPBeNqjz4o7HtiJnVO7ceOH71z5
27p0ZxHxZU99dDzn0nPivZ++L55x6cHY3Y1436fvi+ccOhindnbitz9818rgZF/K44IjYq2nvcxm
+x4JQB66x2QxWHl4mtd8eS9vBHr0W+//dHzj8x8X17zwyvid990SEXuzSl/9OXuD299+/9Ez+qHZ
7k5t3zTb3Ykb/vgj8V0vfXJERNzwxx+NQw8NiiMe6dc+ftcD8aSLz40XPPZR8e5P3hHPv/LRERFx
anc3PnXnvafdnD3355+4K77iMy6LZ1x6MN7+4dVlWC7fJx7K59U//654802fePjzJ1x0bnzszmMx
i4hb7n0wrrzwYDzj0nPinZ84GU+/5JwzyvvJux+IJ150bjzz0MF45yduj2ddeuHD5b3l7vtPy/P4
iTNfiPXKz967cvMtv/Cu+Nl3fjJe9tRL479+8+eclkdTXSIinnzxufHki8897bOXPPni+L0P3Raz
Uyfj/H/+66en8dD/U+o4d2rn5GmfLf97Xq5nXnpBRER89I5jcfu9x9Z+2ADASjVTo5592Xnx4sdf
EPtnZ/Y8J3d3448+fk/81afPvGF9f8M9Jn/68TvjTz9+Z0REfNvnPjZO7ezErfc+GD/6J5+qLWpd
us+49Nx47mUH471H74unX3Iw3vGJu2MWEc+74lHxvqP3xfMec2588LZ74wO3nzlFbH/FCxYXrX3F
ZN++fQ8FIRE7u81PanH2CejTG3/zL+NvP+Oy+LpnXxE3fsvnxU2fvCte+PiL4gWPvyjueuBE/MBv
/dUZ/dA/ecmT4/b7H7kC8t2/8u7Tvp/tnIhb77o3vvwn/yAiIj59171x2cELTvs+IuJn/8fH4vVf
8oz4v77m2fEPnv+4ePYVe8v88ns+Ffcfe2DlIPdX3/PJ+IrPuCxe8qSL4k1//KEVS5x5o+C//8MP
xf/5lc+OH/66Z8eXXnVJ3H98J5772Avj8gsPxrN+8K0REfFz7/xEfPsXPi2u+8pnxUuffHF89Wde
cUZ5/8MffTj+xVd8Zvybr3pWfMETHx0vf8belLafvekTce/9pw/KV92sePPdD8STLzkvvuVznxBf
8MRHx99+5uVn5PGT3/D8037zfS+/Ku584ES85uf+R0REXPA9v3za9/f8wNdGRMSLf+jG+Mtb7qkN
DFLqWFX+qn9/4ZP2nh72a3/1KccrIL+aqVFf9MTz4+SpU3HsxKkzvjv/7P3xBY97VLznU3ed8d2B
nePJU8ROntyJg/t34+TJncbl69Ld3Tkr9sWp+IxLzok//vhd8TsfumPvpo6dk/HCKy+IfXEqTp08
ufK3B5KvmHS8/2PfbF/MHrpCMpvfFD/bV/tYTYCcPnbbPfHSH/6deMOXPyte/ozL44VPuCj2zWZx
+/3H4yt+4vfiw7fefcZg9/DzT58q9E//602n/Xv+6No//+jRvX/H6kfT/qu3/mXsn+3G4Rc8MT73
iRfHHceOx8/8yUfiDb/yF5V931v+7CPxvV/+zPiqZ10e5+3bjWMnVjxacem+jB/53ffGA8dPxj/6
W0+Jv/ucK+Pkqd147y33xL9/2wcfXu6Nv/HuuPL8s+NrnnNlvOxph+Lf3vje+IGvee5p5f3hG/86
4tSpuObznhLf9DlPitvuezB+/Pc/EN//G++J2c5ObRkiIv7xkXfEv/t7L4jPvvLRcc6BffH9v/6e
+In/6YWn5fGNL3jCab/5qoeCh9ceecfK9VGX37KUOlalV/Xvv/ucx8bJU7vxU7//AccrILvZyeor
Gzd+8Gh8/hMvivP2n3lK5sETJ+NtH71z5W9nOydq0130Bx++LV7+tEvidz50W9JTuarS/etb7o43
nzgRO7u78aHbH3mq5X97763xgaN7U6M/eNv9K6dypdxjMjt09XW7xy9+YmOF5t5w+Qfju1/3huTl
IyL+1b9+Y7zxlqe1+g1AF+cc2Bf/+R++JL78WY+N7/vVd8UP3Ti+t55/8+c9LX74770oXvdLfx7/
99veX7o4W+sLr3pM/Mprvjh+6g/eH6//f/+8dHGADfTAFc+K/XfVT6Fq68L3/27c8aJXTirdY49/
XuX3Z9/xN+tN5fpX//qNrQvj0jgwpOM7Ea+64cZ47Rc9Kw6etS8uOWcWd9x/vPmHA3rT2/463vS2
vcf8uqehnD947yfiou/8zxFhOwD9mO2ciEi49aGN3dm+aaZbo/VUrh/82JXNC60wC5fGgWGd2In4
kbe+8+F/G3QCUMTOiYjKB+muabZvcummPS7Yyw8BAKAXfVyBiJ6ubPSabl8vWAQAABLsnIhZT1c2
ppRu0s3veXMFAADm7r/8WaWLMArn3VL/IJoDEREx2x8REUdvuLb3AgEAANvnzNdERhy65vq9P3Z3
Yt+gpQEAAFhBYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5g
AgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQITAACgOIEJAABQnMAEAAAoTmACAAAUJzABAACK
E5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAA
gOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQIT
AACgOIEJAABQnMAEAAAoTmACAAAUJzABAACKE5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCc
wAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5gAgAA
FCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQITAACgOIEJAABQnMAEAAAoTmACAAAUJzABAACKE5gA
AADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIE
JgAAQHECEwAAoDiBCQAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQITAACg
OIEJAABQnMAEAAAoTmACAAAUJzABAACKE5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCcwAQA
AChOYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIOlC7AOo4cOfLw34cPHy5Ykj115SlV1iNHjnTOb+iy
z/MbwzYdWo7tBQAwZZO8YjK2AVxdeUqUdTGg6GJs63lT5dpeAABTNskrJmymXIHQNl95AQCYqo0M
TFadga6bYpW6TI6BbtWgOUeZl7/ve4DetsyHDx9Oqn/Vd4u/X7VcDql5TXF7AQCM2ezQ1dftxmx/
REQcveHawsVJ1zTAXTUAnH+WskxqfinfNw3Oc5c55wA353rOsQ5T0+piytsLAGBKDl1z/d4fuzub
ecVkHU0BRV95tPntkSNHTrtJ2kC2X9YvAMBwJnnz+xAWz2KPZYC6eDbeDdPDGVMbAADYVAKTiVkc
JAtOVhO4AQBMj8DkIWMfzC6XLzU4GXu9OJ3tBQBsq0ne/N70tKw+nsqV+kSp5e/rgom6JzStW+a6
fNsaaj23yavvm99Tn8Q2xu0FADA1ize/TzIwYZo8fQoAgEWLgYmpXPTGtCQAAFIJTOjNqqeIuVoC
AMAq3mNCrwQiAACkcMUEAAAoTmACAAAUN6mpXFU3Um/bdCGPlgUAYNNM6orJ4iB8m9+ALhgBAGDT
TCowIZ1H9QIAMCWTmsqVKuXt3Tne3N30Jvi6KzpV6TRN0xJsAACwiSZ7xaTu3RjzaV5VgcHi76qW
S1kmtZxN6Sx/llLuJot5AQDA2E32ikndoLspeJhfmThy5MjD6awKbpqW6UNVHl5QCADAJpvsFZMq
y1coqqx6K/k6yyzmm3OalSseAABsk40LTNpImaI11ad/ufkdAIAp2crAZHnQXnWPSdMyi8uu+hsA
AEgzO3T1dbsx2x8REUdvuLZwceqlPG1rebnFJ12tehJWXXptlqm6gT0lnZz1AgCAqTh0zfV7f+zu
TCswAQAANsdiYLKVU7kAAIBxEZgAAADFCUwAAIDiBCYAAEBxAhMAAKC4A6UL0EbqY3X7yLdrXqve
idKnMTxKuOmdLouPPJ7/e4jyrHpUc+lHLleVo24drlvmMeRVlV/bfFLK3Ee9hpTS/+Too+bpRExj
vQCweSYVmJR4d0euFyYuD8K3yfJ2q3ofy1ByDeJySal/03txppZXVZC47rZJ+c2YtnmqlPWfa//Z
1v4JgPGYVGBCulyDsK6B4KrfjSFIG0twknJVaax5tb0a0ldedFd6fwSAiA0NTFKmfLV9G3vfA6O2
b6Kvu3pUNz2q7spFbnVpNr3dvm66Va5tUTUYS20bdes2Vcp0o1w2Na8htWkbXfavlP6nzTJNn23q
9gJgWjYyMGmaHpIyjST3ILhOSnnaDM7rrkjMv1tOu+oKwpBnqOdl6DKlJ0Xd+sk9xSi3Ia8cNOWV
856GpjRT7rFoWr7rPWqp/Uab/atK6n7etAwATMlGBiapN12vCkQoZ8htMIbpZG2NKSjJpWsAWBWA
NO3bYwo2AYA9G/e44MUBVcpUovkAhe0zpUHpJgYlAACLNiIwWTewWAxeBCerCdzOtKrNbONgfsi2
oR0CwOabfGCyzmBleZCTGpwYHDG36orbNgUlXeXal1LS2ZT9dpvqCsB2mh26+rrdmO2PiIijN1xb
uDj16g64VU+rqXp6VcpTsKrSW0fTjbdtn8pVV57UvIa6ebauPHUBYtttmlqO1KcWVZW5Kc026h5S
kDOfMebVZj23zWvdfSdnXrn2r5T+p26ZdbdFXX4AkMuha67f+2N3Z1qBCY9wlh5Yh74DgDFZDEwm
P5VrW5iiAXQlKAFgzDbyccGbaPERx4ufAVTJNYUNAIYgMJkQAwqgDX0GAFNiKhcAAFCcwAQAAChu
klO5mh6HW8KRI0eSHuU51/SY37HUaa7uEaRDlrVuPaf+fq7uscNjbGND2tSbpLu2n1xlmJvSvjPW
vADYHJO+YrL45vaS6p6WtTjAa3rT/BjqsqiuPCXK2vWpZG3eL9HUthYfROCJadMwlm00xX1nrHkB
sFkmecUE1rE4IBxbEDg21g8AMLSNC0wWz4K3fRty22WWvx/6Deqr8lpnmRzlTZ0Stc4yQ6/nJovl
Wf67bZlyrp+6Nt+0farWd9OUw3XLnCLXvpzSflLXT45tscq6bTrXvtPUJ7RpY015AUCVSb75vemA
13QfQcrApMvgpeq7lIBgnQHkOmXO8f2Y1nNfUsrSdVCZY/2ssy1yfZ6jHVZpSruP/bTq81zbIiXd
FH3tOynBS8r9WQISAFIsvvl9466YLHJgTD/jnTuPNr+d36MxT2dbtlubuqdusxLrrmuZcxjjfQ1d
goDU9HPtO23W37bsnwAMb6MDkzkH0kekTE0Z2uIAa/7vbZFa97brZAzrcMgy5Mwrdzvscz3k2HfW
7RPG0MYA2CyTfirXlDmon+7w4fonlo1J3T0m6xii7qvS38ZAcGxybPcp7TsAUEdgktni2ctl8wHE
0PdIjHmwsly+1AFWyXotbr+qv1MMXffF9HMGJSnlGXJ7dSlPjkCzrXWDiinsO2PvfwAYl0nf/D5X
92SYNvPfm55Uk5reuuk0lT1XmdvexLoqnboBUd32WLfMdfn2IXVbdLl5eVU+dXlVLZPa5peXT903
+mqHKdrc7J6SV8p+2iWvlG2Ruu+k6KOPqnt4QlMeKXkBwKLFm98nGZgAAADTtxiYmMoFAAAUJzAB
AACKE5gAAADFCUwAAIDiBCYAAEBxk3rze937QbqmOcQjLbf1hXZjeXTokOXoI69c7efIkSODtveI
7WvzwPi1fQz2+hmt+OxwxfeHlz7rq0hD1R1amtQVk+WX2Xnb8TSMpcMbshxjqfOyIV+sF5HnzeYA
fer1xceLAcb8v8XPI3oLPuoM/bJnSDWpKyZ9MFhlKqbafhZf2Ffatl61BIAp2LjAZNUbuef/rlp2
1fep6azzFvW+86rT5u3WKeswh5xvP08tc926a/v27qa8UvJs0rX9LJc3pZ3WpdO2bfS5nnO9ZR5g
FHqexgVjNrk3v7cdqDQN4Nt81/bfJfOqkppOrvyq0qv7vG3wtO7vUuq0bt7r5NWkS/tZJ42mz+af
N03bSqlzX9sYoMogfcWqIKPus1jxXY/0l4zB4pvfJ3vFZHFgUnUzrx2NOvNB9XL7WWfaUdvgZsxS
619Vn7ZBXxtNQT8AMF2TDUzamMqAkPLctN1+f+kyNS3XeraPAxvhcOxdPTkSpnKxlSb1VC6Yom0O
csZmfoUMYLRWPbkLtoTABDJoGvCOMThJGaSPbSA/xTIDAGkmdfN7ygsW29x427Rsmxttm/IcMq8m
KQ8HyPmko9S6j3GZddfPqidW5XoqV12ZU/JKffLbqmXWeZJWyn0hXdqhp3IB61jnQR3rZbTis6ob
35evlvRVpKHqDgkWb36fVGAydkPe5Nx3XlO7YTtimmUGANhmi4GJqVwdDDllxPQUAAA2mSsmHQ15
OXSovKZ4iXeKZQYA2HamcgEAAMWZygUAAIyKwAQAAChuUm9+T3lc8LppbsKTtMYsV92PHDky6LaK
2LztVbUOU+vs8bwAQB8mdcVkcfBz+PDhUb60jv4M+QS0iHG+FLGrlJdApvx+vv9t4joCAMqY1BWT
Pgx5pnebzypPte6LL/6jvW2+SggAtLNxgcniQKhpakrKG7Cb0kl5e/XQedVp84b5lHXYJs9VaaTk
tRwYpKzjunTa1mvdt5sP+dbytm9sT2k7bZYBAOhqco8LbjvYaxrAt/mu7b9L5lUlNZ1c+VWll6NM
Td/VfTb/vGnaVtvpTW0+S/1drvxT0k9dP6uuJLkqAgC0tfi44MleMVkcKFXdzGugtH1Sz+BXtY3U
K1HrXClICQa6yHn1omnfqQtQAADWMdnApA0ByvZou627TJvKdeN3rvY5dDu3XwEAOU3qqVzAOKQG
JfMrmgAATQQmTFLKgHdsg+IhyzzFEO0aMgAAIABJREFU9QMAbLdJ3fye8oLFNjfkNi3b5mblpjyH
zKtJysMBcr5EL0fdV6W17lO5qn6fusyqcqy7Dod6KlfVsnUPBlj8rK+2AQBst8Wb3ycVmIzdkO9s
6Dsv758AAKBvi4GJqVwdDDkVxrQbAAA2mSsmHQ35Loeh8vJ+CgAAhmAqFwAAUJypXAAAwKgITAAA
gOIm9eb3Ph5TeuTIkVHdQ5HraVhjeqpW3T0rKY+AXje/HGl0TWdoKe15rG1jDOVJVbWeU+szxkcu
l7pfLuWx3SnL9dlntn0UedVyKfnlfMz40PcLTm2/aFuuHI/n30Rd9p2UZZr2lcVH9leVY8xylX3K
62DRpK6YLK7o5fcsrMNTroaxartVfZdju3ZV9V6VsZtKOec2cT2nHAwW6z2WNr9osUx9WK5/0/dV
66cpnXXKlFLeuu21vEzb/FLyWqc8Q5jifjHEupnyADFF132nzXZf9bu5qa7nnMfBqa6DZZO6YrJs
HiWP7apHF7nqsSnrYx056758JmYTjLFtbOJ65kxjvCKco921KUfXATx7hrzya7usVqLP3uTjhOPg
nkkHJlXaXnZf95J6ymXE1LdpVy3bJq+c6aS82XyMcq3DRV2mduRoG01nhlLbc1WedWlVlaWPS+el
y5Or31h3Gcpoe6Yyx1X6KQ1Atn2/6OOYss7xtOrM+lD98yp97Ds5tnvXqV9DTymsyydlu2+aSU3l
SpFyWXD58vaqy92p6Swvu7zMcprrXopcTDvl8n2XdJbrPtSOsLh+1s0rV92X/14u5zy9IdpG0yXu
lPa8XK4c9Wpqh3VKreem8nTtN5bTTNnu22je3pfbfcTp27CpT6hLp69yt1muatCY8vuquletnz6M
eb9oyieXXMfluT6Pp7n65z7kCEpW7Qd1y9X1Lanjnz7XYcpxcBttXGAyl6vTTk2nqZNJ3aG22XJH
UKoMq/7OleY6eQ458BpKifWcIue67uOs6aaoO+i3GRgMMXhYVa4uyzWdoJr/NuVkxFD9pf0ij02u
W52Ueqeum9Q2v26fkBJ852JcuNpGTuWKKDfY0biosk7b6HolYBt12QeH3n/1F9PSZVC9/NmUBqn2
C7pqE0yUdvjw4dMC8bGUa1ts7BUTgDFzsJsW22sYqet5ileRx3aCaah1OKWgZK7N1LyxbM9NMenA
pM2l9aaGk2sZGANttbux9An6r+6mUvd1yjn0WV1trZuxBSecbrnt2l7Dmx26+rrdmO2PiIijN1xb
uDj1qubirrvc8rJVl9qr0qm6sWpVGvNLg6v+Tk2valpPU7nXSafNOmxSV56UdZgrr8Xvq+qeWp4h
28ZyG60biNS155RypWz31HZYZ8j1vG6ZUstVVZ5c+1eu+dkp9z6klKerNm2s6zLLy6YeL5aXbXvs
SZ3ytW5e6+4/XaaTts2v7/0ihzb9dNUybY4pXfrMVWkN0beklqcqvxz7ctNYpy54KNm3NFlnP64b
AwzVh/fh0DXX7/2xuzOtwIQyzLMEgPFrGxxv23E9Z723dR32YTEw2dib31mfnQ0ANpfje3fWYT8m
fY8J/Vi8LCpIAYDxW5zK456IM1k/02AqFwAAUMTiVC5XTAAAgOIEJgAAQHGTvPm96ZGopdIaQz45
janMuR4j2fbxs6uWS1lmVZ6l1yEAwJhN8opJzgHeUIPFKQ5Kx1LmxYF96ttYu6azuMzisvPvlpdr
yhMAgHqTDExgbNq8uA0AgDNNcipXLnUDxzZvR198E+fyMl3Kss6bT4eSWvc+3kS6al2ts35yBQ5H
jhxZeeVk3Ss7AADbaGuvmOQY0C8OPPueYrTqs5L3LqTWvev0q2VVv2+7fprKMX+Hy+K7XNqUBwCA
djbyiknq4HUs91DMNQ1y51cnxnRTepOcA/eqqzRzqeunLp2q5ecBWFWeAAB0s5GBydgH61VSyr04
EB57Paumw3XRVOfU9TPFBygAAGyyrZ3KNVWrpipVLbdpZ/JTAoCU9dNXILFp6xsAYEgCk5FaFVgs
34uy+Bl51s+6AZ3tAADQzezQ1dftxmx/REQcveHawsVJk+NJT8v3IdQ9dSt1mbryNJU591O5ckz3
6lrm5WW6TEPLtX7alrkur1VSljP1CwBgz6Frrt/7Y3dnmoHJmIzxfo+hyjTGugMAMB2LgclG3vy+
7QQKAABMjXtMOki9EX0TbXPdAQDIzxWTDrb5ysQ21x0AgPxcMQEAAIoTmAAAAMVt9FSu5UfVAgAA
47TRV0wEIwAAMA0bHZgAAADTsLFTuZoeYdvmTeJ1U8JS3/wOAABU28grJk1vJF/8fv7f4ueLvz1y
5EjlMinpAAAAzTbuiklTUNJnngAAwHo2LjApwdQtAADoZiOncgEAANMiMMnsyJEjlVO76r4DAIBt
tnGByeIN6PMb1+f/rlpm3ftScqUDAADbbnbo6ut2Y7Y/IiKO3nBt4eIAAADb4tA11+/9sbuzeVdM
AACA6RGYAAAAxQlMAACA4gQmAABAcQITAACgOG9+BwC2zvJ7xXp71P+q15cdrvj+8NJnfRVpqLpD
SwITAGBr9TooXxVgHHnov8ML3w387uVV73iDMTCVCwAAKE5gAgAwFj1P44IxE5gAAIyBoIQtJzAB
AACKE5gAAIzB8lO5YMsITAAAxkJwwhYTmAAAAMV5jwkAsLXm7/Lo5X0m83eULF/9qHrB4kC8v4Sx
mh26+rrdmO2PiIijN1xbuDgAAMC2OHTN9Xt/7O6YygUAAJQnMAEAAIoTmAAAAMUJTAAAgOIEJgAA
QHGTfFzw8mPuennEX0tHjhypLMeqx/KtWnZxubHUaW65PKXKWreeU38/d/jw4crHRI61jUWMoyzU
G9u+DABTMOkrJocPHx7FQb/ueeCLg8nF8qYGKyXVladEWbs+d315YF830G9qW0eOHHn494t/Q8T4
9mUAmIJJXjGBdSwOFqc4cJximQEAUm1cYLJ4Fjx1KtK6yyx/3/dUmxxlXrVMjvKmTolaZ5mh13OT
xfIs/92mTKltdTmfqvXXps3XTWNLLXNTGbou07ZMdWn3se+suw5T88qVTpv9K+VqIgD0ZdJTuVap
OrCuGkzWTa9KWWZ5uk+b6T9t5SpzyvfrlG1M67lvVVde2pZpsa5dpvmlpLO8njdl4JlSr1ztMNc6
bDO9s2s6bfNa7qNMUQRgSBt3xWTR1AddOTSdfe8rjza/nQ+G5unYbmyDPgb9OfbF5b8BYCgbHZjM
Geg+ou5KUimLwcn834xfyvbKtcwm2rb6AkCTjZvKNRUGJafLObWsb3X3mAAAsB6BSWZ195Esz/Mu
XZ4xWC5fanBSsl657jGZspSALNcy8+/G3I67qqtfm7pv+noCYLPNDl193W7M9kdExNEbri1cnDR1
T5VKfeJUrqf0rFp23XSayj70k4VS13Pdk3yGXM85pW6LrjeS524bXbdFijZ5dV2matlV3y0aYt+p
WmbVcjnafF91r2rL2zrFDoBhHbrm+r0/dnemGZjApig1+NvUQeeQ9drUdQgAQ1oMTEzlgi2wqVN8
hqzXpq5DABgLV0ygkNRph1PNbyhD1mtT1yEAlGIqFwAAUJypXAAAwKgITAAAgOIm9eb3uveDNC1b
95jSqs+a0pmyoR67O7RNrVcbqY8KnlvnMbVdylJXpq5lritDajq5nrY1VN27lnedvFLyS+1Tm9Ja
9zHSKfroL44cOTKpvifnOsiV1tTWIZDPpK6YLL/Mru5lfCkvvkt5iV9KXlO0qZ3+ptYrVdNALfUl
nznaedMLE1eVp2pfXv5vHSm/z7V/D1n3XH1TU16r+sMqTUFJSt3rPl8sc8pyTb/PZWrHh6p3Ca0r
x/qc2joE8ppUYNKHpgNiSoADY1AXlLQZ0PcdlLQtT1epeQ0RlPSl7xMnba5M5L7i1GTTThqV4vgG
jMGkpnL1pc0BrW3nnXLmMNcyQ0t5g/zQb6tvU+aqvHKl02a6zvLgqtQgYVWbW0fbwWLpei/mneus
cdu684hc7XDdPJs+b7rS0GUa25B9VI586vKr+76p3ts2vRrYM9nAJMdc1iEPepum6sDcdN/O/CV1
Tb+rW6ZrUFKXV6502ua16qDc5wG3zX1WfWvKN/dAZAxB0FzXwVyfZUlpp23LM+9z69IptX0Wy7ZO
vSLa3w/Ttd+o0iav+d85gpK6Y2pTnVL7967rBhi3yQYmuTqilODEGZrN0kcw2qVNLF8B6jtYbhsI
9Hngb5p+tmr5LuUZY1Cyapv3UfcqbfIaYsC8vOziv/vebl2Ck1R1+/eq/PsqR5crz4tS08jVrzmZ
CJttsoFJTk2DwVxTPFI68FzLUG2b11ubQKDvdjZ0Ox7jfjOmsozFmKar9iFlOtXiVaVNqHfT1Leh
0wHGa+tvfgeGt0mDrnVtc92pd/jw5j0JEiCFwKRC7oPC8nzePpeZf5ej7LnSGau6+rWp+xjW09AD
mdx1Xk6vbfpDboO+81qn7hHr3ySdsy4l2uFivmORsl6b2vy2Bydd2+YY+mWgndmhq6/bjdn+iIg4
esO1hYtTr829Hm1vrqw6uC0fJNaZe1x1+TnlKS9tl2mqz6p6pSyXciPsquWGXGbVcuums7hsX3Vf
dY9BjnnfXdrF8nKryt0mn2UpA61V66ipLE3lafN9Sn5d6l61TNc2n+M+gRzlaSrXOtu0qUwl6l6V
76rAomte6wacdem0OZ62yauqD0tZpmrZtnktLzu2oBU43aFrrt/7Y3dnWoEJ4zXkAcDBBihJHwSQ
z2JgYioXa9mkaTMAqQQlAP1xxYS15ZwKMKa8AOZyTa0CYDVTuQAAgOJM5QIAAEZFYAIAABQ3yTe/
1z1KsGrZdR/xu85v69Icy9zkPurXl1JlHeom19T6dXl8cerjedvItX6GeCR1CTn396bHry5b95HJ
65alrkx9tMO26YyhrbYp89A32Luhv7ucbSxlXJP6uoRcj5pelV7uvje17l3zyWlTj18lTS4wadMo
uzzJafH56DmM6alSy+/MGFPAtErubTEmqduirv5Vg9ZVaeUeKPeZTkq92tR9SH30HVX1SR385ijT
2NphSt3H0lbnUuo+lb6ZPUO0sTbL5Dpmtj1R1qXNTvEYv6nHr9ImFZgMFZRsk00e9Hc1dMdQtS3G
tn2GPAhvu7o+L9cVhlxpDLm/pOY15baaEpzkOnu8zYOgrvRjwxpLW7Xd+zOpwCTV8lnonOk1fb78
2XL+TWktGuqSX1296i4Jt5m6UHeGoK2U9d70eWoeTWnmnmZWNwBNbct9d5gp5Ulpq33Ua92699Hm
l9MtJVd/uO72Kln3tmXOlc6UBi1NfViOfj5Xn5lrP11V7rrjSl1aOdpYSr+Rs29JqVeuNNv+rq5e
qdu86YrEspT2s7xcrr4lh77GWqVMMjBZbggpA9QuulxWT2kkQ17yW1x3Vb9drO/yv9ctz6rOZ90O
dVV5UsuYqm4QV5VXH9uiraZOsm7fyaWPy9N9BiURads0pV4lDwptAvYSZVn1/VzX8o3pIDzkPpjr
ZEhVmXP187n6zFzHprrAaTm/IaT0Gzn7lnWvOKbuz+uUJaVeqSdXqtphanvOuV/VlbdqmZwBYq6x
xZAmGZikdJK5N06X4CRVagNeHgS1UbVz1i3f1XKeOTqxunzanklrSnddTXm13Rap+a1ax1WDiFLt
eZ10UgdQfZ/BGsMZsmVtA4Ehtnvd4Gp5+RxB6xgOvmPbB/tQVdac/XyXcsyNcT+dijZtdchtniKl
HQ5VzpRx6fJyXfqEoffBvkwyMKlTt9OMXVMZV50tGsoU1l9E82B/09fZmLZTzrIMFUSnGNM6jmgX
CPTddwzdN42xfx9TWbZBXaDU1ZAnsoaUu15TWx/rBrVTq+dUbVxgsum6XAbfBn1Mj5qKTa3rmIIS
qo0xSBja2KbM0c2mrtehTxpNzSbWaUq8YLGApnmHq5apmqI01Ut1fVg8SFs/p0tpc12WHzq9sZRj
nX25jaHbcd/rp3Q7LJnXOnWPGN8gaSz7chubWua+6lV6fW3Sfr+YT8T49ucxmh26+rrdmO2PiIij
N1xbuDjNVjWg1HnVbRtESl5tLvm1vfdhnWWapM57TsmjqTyr5jquc19FXUDWdOPcup1B0zpIzb9L
HlXLrVo+d/upq0+f5cmVTpd61W3TdfufrgejNuVuSqOuTF22e93Bves67Pp9Sn6l2nyXbZpDal9X
tUxqPz/U8Ss1rxzlqUpn3bSW01u3b+k69lmVxqp0cq3DVem1rdeQ7bAqnaoy1eWTc7/oOtYq6dA1
1+/9sbszvcBk7KbUEABgCGM+No65bLANFgMT95hkpHMDgPaaptM4rsJ2cMWkg9yXMQFg0+SYWtSX
MZcNtoWpXAAAQHGLgYmncgEAAMUJTAAAgOIEJgAAQHECEwAAoDiBCQAAUNzk3mPiEb0AALB5JnXF
ZPEFhvP/Fj8HAACmaVKByapAZDFAAQAApmlSgUnE6cGJKyUAALAZJheYRIRpXAAAsGEmFZgsXyUR
nAAAwGaY1FO5Dh8+vHIKl3tMAABg2iYVmEQIQgAAYBNNaioXAACwmQQmAABAcQITAACgOIEJAABQ
nMAEAAAobnJP5YqIle8yaVq27dO82uTRJs2xPFWsj/r1pVRZ12076+bTlFddeVa9y2dxubp3/axb
v1zrp0u9UpcpIef+vmodrbNNc2yzMbTDtumMoa22KfNQfU+p/DZJ7v4npd9oWqbrMTO1rZaqe9d8
chpDf7hpJheYtGmUXV68OH9nSi5jegnk4jqcvxdmzDtB7m0xJqnboq7+VYPWVWnlHij3mU5KvdrU
fUh99B1V9Uk90OUo09jaYUrdx9JW51LqPpW+edvl7n9S2mrKMrmOmW1PlPVd97Hpo0+Y4nrIbVKB
yVBByTbZ5EF/V0MPCKq2xdi2zxADPfbU9Xm5rjDkSmPI/SU1rym31ZTgJNfZY8HPeqy34Y1lnfcd
+G2zSQUmqZbPQudMr+nz5c+W829Ka9FQU1bq6lV3SbjNZcq6M9xtpaz3ps9T82hKM/c0s7oBaGpb
7nsQlVKelLbaR73WrXsfbX453VJy9Yfrbq+SdW9b5lzpTCnoburDcvTzufrMXPvpqnLXHVea0uoq
pd/I2bf0Ua+ufe/yv5vaYtP2rEpr3bHW8nK5+pYc+hprlTLJwGS5IaQMULvoclk9pZEMOWVlcd1V
/Xaxvsv/Xrc8qzqfdTvUVeVJLWOqukFcVV59bIu2mjrJun0nl1xtdVWaXZepkrJNU+pV8qDQJmAv
UZZV3891Ld+YDsJD7oO5ToZUlTlXP5+rz8x1bKoLnJbzS9F1m6b0Gzn7ltz1ynnCo65sqSdXqtph
anvOuV+1WTc5tm2usVZJkwxMUjrJ3BunS3CSqq4BVw3G26raOeuW72o5zxydWF0+bc+kNaW7rqa8
2m6L1PxWreOqQUSp9rxOOqkDqL7PYI3hDNmytoHAENu9bnC1vHyOoHUMB9+x7YN9qCprzn6+Sznm
htxPc56EGYM2bXXIbZ4ipR0OVc7U8cfidznGqct/T80kA5M6dTvN2DWVcdXZoqFMYf1FNA/2N32d
jWk75SzLUEF0ijGt44h2gUDffcfQfdMY+/cxlWUb1AVKXQ15ImtIues1tfWxblC7Kf3m2G1cYLLp
ulwG3wZ9TI+aik2t65iCEqo5uI5vyhzdbOp6Hfqk0dRsYp2mxAsWC0iZd7i8TNUUpalequvD4kHa
+jndOnNdc6673OmNpRzr7MttDN2O+14/pdthybxKzDfvw1j25Tb6KnOf66LvvqVEumPMf6i8xro/
j9Hs0NXX7cZsf0REHL3h2sLFabaqAaXOq27bIFLyanPJr+29D+ss0yR13nNKHk3lWTXXcZ37KuoC
sqYb59btDJrWQWr+XfKoWm7V8rnbT119+ixPrnS61Ktum67b/3Q9GLUpd1MadWXqst3rDu5d12HX
71PyK9Xmu2zTHFL7uqplUvv5oY5fqXnlKE/OdFalt27f0nXssyqNVekMXfe6eg3ZDqvSqSpTUz5d
9/dcY62SDl1z/d4fuzvTC0zGbkoNAQCGMOZj45jLBttgMTBxj0lGOjcAaK9pOo3jKmwHV0w6yH0Z
EwA2TY6pRX0Zc9lgW5jKBQAAFLcYmHgqFwAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxU3uPSYe
0QsAAJtnUldMFl9gOP9v8XMAAGCaJhWYrApEFgMUAABgmiYVmEScHpy4UgIAAJthcoFJRJjGBQAA
G2ZSgcnyVRLBCQAAbIZJPZXr8OHDK6dwuccEAACmbVKBSYQgBAAANtGkpnIBAACbSWACAAAUJzAB
AACKE5gAAADFCUwAAIDiJvdUrohY+S6TpmXbPs2rTR5t0hzLU8X6qF9fSpV13bazbj5NedWVZ9W7
fBaXq3vXz7r1y7V+utQrdZkScu7vq9bROts0xzYbQztsm84Y2mqbMg/V95TKb1Pl2r9SxjUpx4p1
y5LaVnP3val175pPTmPoDzfN5AKTNo2yy4sX5+9MyWVML4FcXIfz98KMeSfIvS3GJHVb1NW/atC6
Kq3cA+U+00mpV5u6D6mPvqOqPqkHuhxlGls7TKn7WNrqXErdp9I384i+9682y+Q6ZrY9UdalzU7x
GN9HnzDF9ZDbpAKToYKSbbLJg/6uhh4QVG2LsW2fIQZ67Knr83JdYciVxpD7S2peU26rKcFJrrPH
gp9u9GXDGUtb7Tvw22aTCkxSLZ+Fzple0+fLny3n35TWoqGmrNTVq+6ScJvLlHVnuNtKWe9Nn6fm
0ZRm7mlmdQPQ1Lbc90EypTwpbbWPeq1b9z7a/HK6peTqD9fdXiXr3rbMudKZ0kC1qQ/L0c/n6jNz
7aeryl13XKlLK8f+ldJv5OxbUuqVK822v6urV+o2b7qiviyl/Swvl6tvyaGvsVYpkwxMlhtCygC1
iy6X1VMayZBTVhbXXdVvF+u7/O91y7Oq81m3Q11VntQypqo7yFTl1ce2aKupk6zbd3LJ1VZXpdl1
mSop2zSlXiUPCm0C9hJlWfX9XNfyjekgPOQ+mOtkSFWZc/XzufrMXMemusBpOb86udpdSr+Rs29J
/W1qW815wqOubKnBX1U7TG3POferNusmx7bNNdYqaZKBSUonmXvjdAlOUtU14KrBeFtVO2fd8l0t
55mjE6vLJ/WsSmq662rKq+22SM1v1TquGkSUas/rpJM6gOr7DNYYzpAtaxsIDLHd6wZXy8vnCFrH
cPAd2z7Yh6qy5uznu5Rjbsj9dBMGg4vatNUht3mKlHY4VDlTxx+L3+UYpy7/PTWTDEzq1O00Y9dU
xlVni4YyhfUX0TzY3/R1NqbtlLMsQwXRKca0jiPaBQJ99x1D901j7N/HVJZtUBcodZVycmnV8mNv
A7lP0I29vsvWDWo3pd8cu40LTDZdl8vg22CxQ9m29bOpdR1TUEI1B9fxTZmjm01dr0OfNJqaTazT
lHjBYgEp8w6Xl6maojTVS3V9WDxIWz+nW2eua851lzu9sZRjnX25jaHbcd/rp3Q7LJlXifnmfRjL
vtzGppa5r3qVXl+btN8v5hMxvv15jGaHrr5uN2b7IyLi6A3XFi5Os1UNKHVeddsGkZJXm0t+be99
WGeZJqnznlPyaCrPqrmO69xXUReQNd04t25n0LQOUvPvkkfVcquWz91+6urTZ3lypdOlXnXbdN3+
p+vBqE25m9KoK1OX7V53cO+6Drt+n5JfqTbfZZvmkNrXVS2T2s8PdfxKzStHedYpW5t01u1bcpSl
9DpsW68h22FVOlVlasqn6/6ea6xV0qFrrt/7Y3dneoHJ2E2pIQDAEMZ8bBxz2WAbLAYm7jHJSOcG
AO01TadxXIXt4IpJB7kvYwLApsk1zakPYy4bbAtTuQAAgOIWAxNP5QIAAIoTmAAAAMUJTAAAgOIE
JgAAQHECEwAAoLjJvcfEI3oBAGDzTOqKyeILDOf/LX4OAABM06QCk1WByGKAAgAATNOkApOI04MT
V0oAAGAzTC4wiQjTuAAAYMNMKjBZvkoiOAEAgM0wqadyHT58eOUULveYAADAtE0qMIkQhAAAwCaa
1FQuAABgMwlMAACA4gQmAABAcQITAACgOIEJAABQ3OSeyhURK99l0rRs26d5tcmjTZpjeapYH/Xr
S6myrtt21s2nKa+68qx6l8/icnXv+lm3frnWT5d6pS5TQs79fdU6Wmeb5thmY2iHbdMZQ1ttU+ah
+p5S+W2KvvrVlHFNyrFi3XKk1it335ta96755NT1+LW83FjqVdLkApM2jbLLixfn70zJZUwvgVxc
h/P3wox5Z8i9LcYkdVvU1b9q0LoqrdwD5T7TSalXm7oPqY++o6o+qYPfHGUaWztMqftY2upcSt2n
0jezZ8h+NWWZXMfMtifKurTZKR7jc/QJYwu0xmBSgclQQck22eRBf1dDdxRV22Js22eIgR576vq8
XFcYcqUx5P6SmteU22pKcJJrUGNQxFSMpa3m7FPHUqexmFRgkmr5LHTO9Jo+X/5sOf+mtBYNNWWl
rl51lxjbTF2oO8PdVsp6b/o8NY+mNHNfgq0bgKa25b4HUSnlSWmrfdRr3br30eaX0y0lV3+47vYq
Wfe2Zc6VzpSC7qY+LEc/n6vPzLWfrip33XGlKa2uUvqNnH1LH/Xq2vcu/7vtlKfU8ca6Y63l5XL1
LTn0NdYqZZKByXJD6PuyWJfL6imNZMgpK4vrruq3i/Vd/ve65VnV+azboa4qT2oZU9UN4qry6mNb
tNXUSdbtO7nkaqur0uy6TJWUbZpSr5IHhTYBe4myrPp+rmv5xnQQHnIfzHUypKrMufr5XH1mrmNT
XeC0nF+Krts0pd/I2bfkrlfOEx51ZUs9uVLVDlPbc879ap3y5gwQc40thjTJwCSlk8y9cboEJ6nq
GnDVYLytqp2zbvmulvPM0Ykq0jDqAAATO0lEQVTV5dP2TFpTuutqyqvttkjNb9U6rhpElGrP66ST
OoDq+wzWGM6QLWsbCAyx3esGV8vL5whax3DwHds+2Ieqsubs57uUY26I/XRTtumyNvUacpunSGmH
Q5VznfFHl/Yz9D7Yl0kGJnXqdpqxayrjqrNFQ5nC+otoHuxv+job03bKWZahgugUY1rHEe0Cgb77
jqH7pjH272MqyzaoC5S6GvJE1pBy12tq62PdoHZq9ZyqjQtMNl2Xy+DboI/pUVOxqXUdU1BCtTEG
CUMb25Q5utnU9Tr0SaOp2cQ6TYkXLBaQMu9weZmqKUpTvVTXh8WDtPVzutS5rusuP3R6YynHOvty
G0O3477XT+l2WDKvdeoeMb5B0lj25Tb6KnOf66LvvqVEumPMf6i8xro/j9Hs0NXX7cZsf0REHL3h
2sLFabaqAaXOq27bIFLyanPJr+29D+ss0yR13nNKHk3lWTXXcZ37KuoCsqYb59btDJrWQWr+XfKo
Wm7V8rnbT119+ixPrnS61Ktum67b/3Q9GLUpd1MadWXqst3rDu5d12HX71PyK9Xmu2zTHFL7uqpl
Uvv5oY5fqXnlKE/OdFalt27f0nXssyqNVekMXfe6eg3ZDqvSqSpTXT4594uuY62SDl1z/d4fuzvT
C0zGbkoNAQCGMOZj45jLBttgMTBxj0lGOjcAaK9pOo3jKmwHV0w6yH0ZEwA2TY6pRX0Zc9lgW5jK
BQAAFLcYmHgqFwAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxU3uPSYe0QsAAJtnUldMFl9gOP9v
8XMAAGCaJhWYrApEFgMUAABgmiYVmEScHpy4UgIAAJthcoFJRJjGBQAAG2ZSgcnyVRLBCQAAbIZJ
PZXr8OHDK6dwuccEAACmbVKBSYQgBAAANtGkpnIBAACbSWACAAAUJzABAACKm2xg4klcAACwOSYZ
mMyDEsEJAABshskFJvNgpOkdJvPHCntDPAAAjN+kApPloKQqOFlczksYAQBg/Cb1HpNV7zBZ/mw5
eJn/LTABAIDxmtQVky68mBEAAMZrawITAABgvAQmAABAcQITAACguK0JTNz8DgAA47VxgcmqxwML
SgAAYNw2LjCJOD04WfX4YAAAYFwm9R6TNgQiAAAwHRt5xQQAAJgWgQkAAFCcwAQAAChOYAIAABQn
MAEAAIoTmGyg+WOSN+39LZtar5ymuH5ylTclnVzrZ8i8AGBbCEw20KY+KnlT67XNhgxKchFsAEA/
NvY9JrCNBG/1hlw/tgUAtCMw6aDqrfKLn+daZmiLZ4WryrjqzHFVHVKXqVsfbcpclVeudJqWWa7T
4mdtyrSqnVSlUfd9ajpDbYvl75v2gZTy1qWzvGzT913KnCOv1GUAYJPMDl193W7M9kdExNEbri1c
nGkZc2CS87d1QUndZ+ss01TuNuuqayCQo15VupQpZUCc8l3XbZFa3rq02uSxbr1TluujzF3yytWe
AWDsDl1z/d4fuzvTu2JSNeBrOpO/zjJMTx/z/7u0ieXAcxvuT5jX88iRIw+vu3XX4VDrK2eZ182/
r/LoMwGYiskFJikHwVzLtJFyNjPXMlSz3sZhcWA9/3dbba9CdZWjzGMsz1j7TABY5qlcQC8OHz48
WFCRy9jKPLbyAECfBCYZLA4YqgYPuZaZf5frXQybPNipq1+bum/6espteX2lDqxLtuuxlXnd8gDA
lLn5vaMcN3ynLlO1bNX3c21vJF+Vxqrlhlxm1XJdnmLUd92rHm7Q5Yb8uvKsWq7ppuu6dtiUV5N1
tsWqZZa/S91uQ7WfPvPKtS0AYMwWb34XmNBoyDn3Y5nfPyal1oltAQD0bTEwMZWLMww5dck0qfGw
LQCAklwxYaXU6WBTy2tqhl43tgUAMCRTuQAAgOJM5QIAAEZFYAIAABQ3uTe/RzQ/qnNM+ijrkSNH
Bqv3kHkNKeWJUyl1z7V+hm7Tm/jErRJPj+szv219pPBY+8wpHXfaSu3rIsrWve7hHG0fe57r8fJA
XpO7YrLYQUyhk8hdxiGfmrTNT2hKqXvO9TNkW97m7ZrLUA8hmPdzq16wmLLMFI21z5zC8WYdU2wv
i21+eSyQe9+Z4vqBKZvUFRNnLchlW9vQJh9kN2mbptQlZZmqPnNTr4TSn21sL5vcX8JYTSowyWXV
m7jn/161XNX3q5apWq4q/9R0lr+vG3C0LU9V+VLK23UdrptOVXkWP09ZR035pGyrrttiyHfGzMuw
bp65tlfOZZaXa3rjfdXnY9tefVmn/JvcZ+YydJvvqs36Sd3mdX1vqWmHXa5+N12FHHvdYYom9bjg
ps5jnbSaBrFVy6/7WZd0msrZJp0Uqetkvsw663DV5ynbJmVQuajNekz5vmmZXG0jl7btPSWt+e+7
bK+uy6wq1zqBydi213J+cykD/XXbbGpZNqnPbKtNHkO0+RxS029zAmZRm22YWtZVeaxKt2rfSFlm
Vb4l6w6bbPFxwZO8YrK8gx850s+0hHXOLHYZFHQ9EzvvBBfXxxAdX0qdu6afWq/lA0Hps9t1+Zc4
OK06S7pu/qkDma7pDbkNx7a9Uvq61P6wRCCVomSfOaSUfqxUH55DSt+b4xi3Ks1VbT7lOJDrWFFX
9ylvUyhhkoHJENqekc8hR2e12AnmSrNN3otyrsOS9epiLOXs8yxyXZCYQ8k2vCmGDEqm1mcOKaUf
m2pfl2LouqTkN9TJu03dppDb5J7KNWVDHbAPH96cJ/Qs2tR6pVo8sJFuVZsZaqA+hu015cHQJu7v
Kf1Yal83ljY2RmMJShbz2sT2DLkJTDJrOlCkdkwpB5zlZZb/nbMTLHkA7LNe6+Tf5zKbqvQ6XGwz
bebUj6XNd1kmYvV0r7Eo2WcOKaUfm0JfVzKvsbXdFKW3KUzNpG5+j1i9M3e5kbMunVXzRJeXa0qn
rkNqk05duaq+a0onRVVey/mklrWu7l3Wz6r5vanbbJ31nLJMrja2vGzXs3yp9e/y27Z177LMOuVK
SaOpPH1vrxzr58iR+rn3fZZnKn1mqqY2NnSbX1w2Z5/Qdv9K7XtLHbtzL7O43NB1h021ePP75AKT
XHJ16DAE7XVaNnF7bWKdpsz2ADbF5J/KBdvG4GNabC/6po0Bm2gr7zFZntMLQDV9JgBD2MorJs40
AaTTZwJ0t3///tjZ2SldjFHbyismAAAwpFtvvTUOHNjKawLJBCYAANCzSy65JE6cOBFnnXVW6aKM
1kaHbaselbnOMjnLE2FaxFTkeMToGHV9ZO7yciUfh5uzPMtprbN+Ut7H0aYMbdKpKndfjxDP8cjl
dcvTZv20fRTuOuXJlU5qvUo8UhjI481vfnMcP348zjnnnDh+/Hjp4ozOxgYmKTdouomTOovPo98U
dfWpelfEcvCeY6CTkteQ5VlOa90yz6UGK01S61SVR5syd8knNa/c5Wlaz01tI1d5hqxXm7w2rf+C
TfCqV/2DiIh48MEHBScrmMo1oMOHD2c/azW2A4/yjFeOdTG2s69dylM14Ouij328SV9tvI/1k0vK
eu67rfaxPnK2nzFtL+ARZx+8IL77n/5IvPnNb44HH3wwzj777NJFGpVJXTFZ9WbV+b+Xl1n1mzbL
tCnP4m9TplPUvYm5zZSUujOEKXnVfb5cjpR1VDeQafMG53XLnKs8q37blPZyGuuWOTWvtmksLm/A
Ur/9prR+qvqOXOkumuL6aSu1buv0D0PLsb3W7cOXvwcecfZZ58VFlz4p/uk//8mIcOVk2eTe/J46
YG4zkM45R35RmzJVBQZd5g3XHUBSgqPUsjTlVSVlPVR9vu4UjZTy1K2LprRTA56SB+2UdrisaZCT
c1pQyjbrUp4u+1bb/HKc9KjKp22bSylvXTop36+7TbvuD23296p12HSCJCWvNumkyLFNc15VXJVn
m+MMbLvd3d049JhnxDOe9Yp431/dGI8676L4wR94bbzyla/c6uBkI978PqYOb7lz7vts2ToDgz41
HYSa1k9Kmee/S7mi1KU8bQ6oYzgrmlvqlaMcc+nXGWx1LU/XAVObK2td8qoq+6p6rdqfms5ul1o/
bcuTImV/b8ortf9uE7R17R/anNzoug6b1PWZi33zPP8xHZ9hbM4+64K45NCT4pxzD8V9x47Gd1z7
gxHhysncZAOTuW3rANe56lKqPOv8vq7MdVfIcpWnjaHaXs6rFNtsyLYxRF65r8ZN8Sx3zjI3pZGa
V46yTG1bLJ84mkq5oYQDB86JRz3qonj0pU+PozffF/fd96l4zWu+KyIEJxFufp+UHJ3+qgCg63ST
EgP0VYP1MR0Uc67nw4cPr/yPdGNqG2O07etnTEHJVC32S5t4NRlyOXnywThx/IE465zz48CBc2L3
5Mm4//4745u++R+5IT62JDBZngK07jIl9XFmsMsZrlJBSdXBr/TAalX7ybGeS8pR5tT9KiWvsbXV
PtfPkP3RFNfPkPpYP2OoVy5VU2w3pX6Q2/ET98Sdd90ax++7PY4/eF+cOnU8Tp16ME6dfCBe9apX
bX1wMqmpXMsD0boDRcql5SEvP7cpe5WUs3XL9amae1w3LWrV/RzrlCdFSplXlbOvec0p5alaP3Vt
LFf5ukid778otW2sU7eUNHKVJ6V8OdZPLm3Xc1X/Mrb1k7P9NEnJK9f6GVu9ItK215DlAfacePC+
OHrLB+P22z4Yl1z6+Lj40Yfi937vTfHYK644bbmbb745rrjiiq2b1jW5p3IxvLEMrAEApmp3dzfO
fdTFcdmhZ8Uv/sKPxi//+k3x8z/3q/E9rz8cFz36YHzt135t6SIWsfhUrq2YykU7mzTNAABgLE6e
PB6/9Es/Hldd9dT4+q/7gjjrrHPjx3/qZ+OLv/hLShdtFAQmnGHq90YAAIzR2//gd+PY/ffGxRdf
HM/8jCfH4x73mPjkJ2+Nm256Z3zrt35r6eIVN6l7TBiOQAQAIK9jx47FF33RF0VExJve9KZ47bd8
VXzbt70j3vjGH4n/8l9+Mn7sx36scAnLcsUEAAB69pa3vOXhoCQi4g1veEN84UteFCd3j8fb//AP
47bbbo9nPvOZBUtYnsAEAAB69vf//t8/7d+33XZbvPOdN8Xr/snVceWVV8SxY8fiO7/zOwuVbhwm
OZVrjI8lrHsE8KobyZsejTqWOs3VPYpyyLKu+6jlxd/P1T3Kd4xtDADYLK973eviv/2334zXvuab
4z/9p/8U3/Ed31G6SEVN+orJWN6AXfcEq+UXA9a9fGoMdVnU9J6YoXV9UthyENL0jpuml/3Nf+8p
ZgDAOt7xjnfEJZdcHAcPHoxXv/rVcezYsdJFKmqSV0xgHcsvVgMAYDw2LjBZfmP3XNNUnXWWGerN
uqnlWXeZHOVNnRK1zjJDr+cmy2/ZXvxbwAMAsJ5JT+VapWqazqrBZN30qpRllqf7tJn+01auMqd8
v07ZxrSe+1Z15UVQAgCwvo27YrLIQLH5Jvu+8mjz23nANk/HdgMA2D4bd8VkldJn2Mdk+QrFGKx6
0zwAANtlKwKTMRpLUDAWOaeW9a3uHhMAANYjMMms7qz/8n0UpcszBsvlSw1OStbLPSYAAPnNDl19
3W7M9kdExNEbri1cnDR1T5VKfeJUridcrVp23XSayt7HU7nWfclgXTBRtz3WLXNdvn1I3RZ16w8A
gHqHrrl+74/dnWkGJgAAwPQtBiYb/VQuGLOUqWiuwgAA28I9JgAAQHGumEAhroYAADzCFRMAAKA4
gQkAAFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIEJgAAQHECEwAAoDiBCQAAUJzABAAA
KE5gAgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQITAACgOIEJAABQnMAEAAAoTmACAAAUJzAB
AACKE5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJ
TAAAgOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABA
cQITAACgOIEJAABQnMAEAAAoTmACAAAUJzABAACKE5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkA
AFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5g
AgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQITAACgOIEJAABQnMAEAAAoTmACAAAUJzABAACK
E5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAA
gOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQIT
AACgOIEJAABQnMAEAAAoTmACAAAUJzABAACKE5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCc
wAQAAChOYAIAABR3YPEfh665vlQ5AACALeaKCQAAUNzeFZPdncLFAAAAttn/D7FfMgNyjMO6AAAA
AElFTkSuQmCC
--90e6ba6e8f602e34a604b1efbbe7
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--90e6ba6e8f602e34a604b1efbbe7--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:51:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:51:27 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4FL-00027h-KV
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:51:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Ez-0006Wm-D5; Thu, 17 Nov 2011 07:51:05 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jV-0005gs-Ms
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:40 -0800
X-Env-Sender: yujiageng734@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321543108!3550845!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29288 invoked from network); 17 Nov 2011 15:18:30 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:18:30 -0000
Received: by ywn1 with SMTP id 1so1970105ywn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 07:18:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ZlyEdpuDpaPtkrh3JhToY31OUH5P+s/ZXUygsnc3XrU=;
	b=wH8+sALpihRQGAkkLJovOR/q2b3hu9pAdB9j6DQAL51dEkFPIl+CVsD3AciATiuOoc
	0lmJuHbo1z/P+PZQChuhZnyog4Ay+68Ys+t0wU1t+bAyKfT6xk3xELwV5Vuy1WDwQL9i
	M4p+Cun19FbNEZTw17mP7+3uhrfZn3/GiKDsQ=
MIME-Version: 1.0
Received: by 10.42.172.70 with SMTP id m6mr26787441icz.37.1321543102510; Thu,
	17 Nov 2011 07:18:22 -0800 (PST)
Received: by 10.42.170.197 with HTTP; Thu, 17 Nov 2011 07:18:22 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111091656060.3519@kaball-desktop>
References: <alpine.DEB.2.00.1109021401000.12963@kaball-desktop>
	<CA8694A1.20379%keir.xen@gmail.com>
	<CAJ0pt17eoZbEnmziLaSd1Cxi+sU90rJ-c8TSgt+ikE3wZj1jhA@mail.gmail.com>
	<alpine.DEB.2.00.1109151110020.12963@kaball-desktop>
	<CAJ0pt15daSuXGi_8T3NS53E2Xv0bYV90b94100Wi6ajt99gedQ@mail.gmail.com>
	<alpine.DEB.2.00.1111081412270.3519@kaball-desktop>
	<CAJ0pt154u9GY-6x6ZJA2UDyfgE135hZkr27XHnJ2ooaaNtTEmw@mail.gmail.com>
	<alpine.DEB.2.00.1111091340110.3519@kaball-desktop>
	<CAJ0pt15HEYGkXXR00tkyc6FXwt7eGKi-0yGo67y=UeWEuNrbTg@mail.gmail.com>
	<alpine.DEB.2.00.1111091656060.3519@kaball-desktop>
Date: Thu, 17 Nov 2011 23:18:22 +0800
Message-ID: <CAJ0pt17qsAjO4YzbNNvNxWsbG0B2ZRrOs1QwS7ueNxpxhpD9Fw@mail.gmail.com>
Subject: Re: [Xen-devel] Re: Linux Stubdom Problem
From: Jiageng Yu <yujiageng734@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Content-Type: multipart/mixed; boundary=90e6ba6e8f602e34a604b1efbbe7
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Anthony PERARD <anthony.perard@gmail.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--90e6ba6e8f602e34a604b1efbbe7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2011/11/10 Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> On Wed, 9 Nov 2011, Jiageng Yu wrote:
> > The keyboard driver is OK now. I am working on network device. In
> > linux stubdom, I have udev, ifconfig and brctl tools. After udevd
> > started, stubdom executes "ifconfig eth0 IPadderss netmask netgate up"
> > to setup the network. When qemu in stubdom creates a tapxx interface
> > for hvm guest, =C2=A0the script should be executed to build a net bridg=
e.
> >
> > =C2=A0 =C2=A0 =C2=A0 /sbin/brctl addbr eth0
> > =C2=A0 =C2=A0 =C2=A0 /sbin/brctl addif eth0 tapXX
> >
> > Therefore, the hvm guest has the network device. Is this plan
> > reasonable? Or have better one?
>
> The bridge should be called xenbr0, the stubdom's network interface
> (that should probably called eth0) should be added to the bridge at boot
> time.
>
> Like you said, when qemu starts is going to create a tap interface, on
> Linux usually we rely on a udev script to add the tap interface to the
> bridge. The script is tools/hotplug/Linux/vif-setup, that calls
> tools/hotplug/Linux/vif-bridge.
>
> So at the end you have:
>
> xenbr0 (bridge)
> ||
> |+-------------------------------+
> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> eth0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> (stubdom network interface) =C2=A0 =C2=A0 =C2=A0tapXX
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (qemu's tap interface)


Hi Stefano,

=C2=A0 =C2=A0=C2=A0I have a prototype of network of linux based stubdom, as=
 shown in
attached figure. I list my design=C2=A0points, please comment on them.

    1. Qemu-ifup script in Linux stubdom.

     Qemu in stubdom invokes qemu-ifup script to setup the
bridge(net/tap.c). Because the linux stubdom only has nash and can not
execute the qemu-ifup script, I implement a c version of qemu-ifup
script. Using the following way, the qemu will invoke qemu-ifup
program in stubdom.

diff -r 0f36c2eec2e1 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jul 28 15:40:54 2011 +0100
+++ b/tools/libxl/libxl_dm.c	Thu Nov 17 22:41:29 2011 +0000
@@ -29,9 +29,12 @@
 #include "libxl.h"
 #include "flexarray.h"

-static const char *libxl_tapif_script(libxl__gc *gc)
+static const char *libxl_tapif_script(libxl__gc *gc,
+                                      libxl_device_model_info *info)
 {
 #ifdef __linux__
+    if(info->device_model_linux_stubdomain)
+        return libxl__sprintf(gc, "/bin/qemu-ifup");
     return libxl__strdup(gc, "no");
 #else
     return libxl__sprintf(gc, "%s/qemu-ifup", libxl_xen_script_dir_path())=
;

     I do not use libxl_xen_script_dir_path() to determine the path of
qemu-ifup, because we don't want include xen-unstable.hg/Config.mk in
linux stubdom. Therefore, I hardcoded this path.

    2. Network tools.

    Our linux based stubdom do not have the real shell and IP stack,
so we must custom the network tools. I notice the bridge-utils-1.5
version creates AF_LOCAL socket, so brctl can be used without
modification. But ifconfig would not be so luck. I need to rewrite
ifconfig and make it only support bring up the interfaces.

    3. The mac address.

    If we declare the mac address in stubdom-cfg file, the eth0 in
stubdom and eth0 in hvm guest will be set to the same mac address.

   do_domain_create (or libxl__create_stubdom)
         -->libxl_device_nic_add

   As a temporary solution, I hardcoded a static mac address for linux
stdubom in libxl__create_stubdom().


  Thanks.


Jiageng Yu.

--90e6ba6e8f602e34a604b1efbbe7
Content-Type: image/png; name="Screenshot-QEMU (fedora14-dm)-1.png"
Content-Disposition: attachment; 
	filename="Screenshot-QEMU (fedora14-dm)-1.png"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gv3w7i6x0

iVBORw0KGgoAAAANSUhEUgAAAyYAAAJwCAYAAAB8l3VsAAAABHNCSVQICAgIfAhkiAAAABl0RVh0
U29mdHdhcmUAZ25vbWUtc2NyZWVuc2hvdO8Dvz4AACAASURBVHic7d159CXXXRj47+tuSS1ZkrW0
LFnebdnYGBtvYALGGAwEs+aEMGkPDmGkmNgH5gARNsHJwJCZGKJEGSCskyiDSU7cmG3CsAUDIoDN
YiCysQHvNt4kubUvLXX3r3/zx09Pev36VdWtV7fqVr33+Zyjo1+/V+8uVbdu3W/VrapZrHDo6ut2
V30OAADQ1dH/+PrZ8mcHFv8xD0iOfu43DVUmAADYaM990uXZ0/zrP31bPPNFXzCpdI9fdtXD/z4U
sRd3LAQoDwcmh66+bve2F74yIiJmOyeyFwYAALbRsZ2Is08dz5rm7OTxyaW7GGPM445DEbvz4ORA
xF5QcvvzvyFmp05mLQAAAGy7YzsR+zOf+J/tnJhcuqtijduf/w1x6Oq94OTA4sIAAEBeD+xEnHcy
90D/+OTSbYo3Dhy6+rrdO5/91THbSbta8vjf/q9rFebjL/+6tX4HsKn+0XMvip/40sfGt//OzfHj
N93x8Odf+qRHxb/7kiviqRedHftmEc/7mQ/Fe44+uFYezz50Ttz0TU+NiIiz/u1fZSn32HSt48ue
cF689RueFD9+0x3x7b9zc+7iAcSxnYid7AP9E0XSfcoF+2PfLOJDd+/E/GlZs4h4/Pn7Y/8s4iP3
7FSmWxVv3Pnsr45DV8fugYiI2al2Ffq73/AVrZb/xZ/7jdZ5ALT1hAvPiu/7/Cviy55yflx27oH4
9LGT8dsfuTe+/+23xEfvemSu7PHveu7K35/9b9512ve7EfGc//jeeN/te0HBZ1xyTrzr6s+IWcXy
z//p98V7jj5Q+dmi887aF//i8y+Lux7ciZ9+19GYnTr18Hc/9vK9oOTGv7k33n30gbj9vgfWnmo7
O7V/4e/h+uGf/donxYuvPC+uPP+siKheD/tmEb/xDU+Nlz3x/Nrl6nSt43//6F3xrk8/EP/4sy+K
H/uzW+P9d6wXBAJUeWAnYudE3j54387evSAp6T7pggPxiicdjLd96sH4i9vql69L92mPPhBf+8Sz
4tRuxE1Hd+N3P/FgzCLiix9/MJ5z6Vmxfxbxix86GR+5+8xj1r6d44199F5gkni1ZNHvvf09Scu9
9POfHevmAZDqiReeHW9/1dPjsvMOxJ/dfH/88vvujM957KPiVc++OL7iqRfE57/pr08LTiIi/st7
bo/bjz3SNy33U7OI+LbnXRLf/taPRUTEtz7/sbH4bMMzlj+1k/RZRMQ3PudQXHbegfjP7749Hnjw
+GnpPuWisyMi4nW/9bH4i08fe7gs65ideuTMVZd++Kx9szhxKv1J8p935Xnxjk/dF1/79IseLseq
/F/3eVfESx7/qNPK27acOer48391ezz3pVfGtz3/kviOh7Y3QDYnj8epHq5spKb7RY89GCdO7sQL
D+2Pd95y/9rp3v/gbpzcOTs+cOeJeM7FZ8WpnQMxi4jPvGhfvP/2B+Kqi86K+x84HqdOnnnVpO6K
ydyBhwuQ6DUvOxXf/c3Pi79+yVkxi4jZbBa7u7sxm80iZrOYxSz2Lfz91Cc/PR7z6V+L78scJQIs
+r6XPDEuO+9A/NoH7oyvf8t7Yzf2zsb/wjd8Rrziqovi+77girjm//vgab+5/u0fj/c8NPCPOHPw
f/uxk/Gqz7okvvfGj8YsIl717Evi9mMn45Jz927PW+479zrd5s8iIr7mqgsjIuIPPnrnad8/8IYX
P/z3n179rIiIOPjGP374s9e88PJ47Ysuj6defDDuPHYyfv6vbo9/duPfxP0n9q64HDywL37iK58S
f+eZl8TH7z4eP/aOR6YmzfOZRcS3v/ix8S0veEw84dHnxNH7T8Rb3nNbfN9//3g8cPLUaeV4/W99
NF79gsvjaRcfjPN+YK8cX/7Ui+JffskT4ikXnRPnnrUvbr//ZLz1w3fF637ro3Hb/XsHnaf8yJ+f
ls6q9fCixz4qvvcLHxv/x+99PL7/ZU+oXV+LUuo4z/d/u/Fj8doXXR5n75/Fd731o3HBOfvjf3/p
Xl7XvvUjceQ9t0VExO9/5M6Il14ZX/W0C+M7f8PxCshs50QvU65S0z0Qp+KuB07FhWfva1y+Lt2P
3Xki/vzmWTzvsoPx/tsfiOdesnci7QO3PxBXXXR2/Omn7o9P3L36qndK/77WVK6IiH2zfRGziFnM
Ima7MYtZzGaPBCUPLzMvjKlcQI++7Cl7A/2fescnIk6diFnsTcX6qXd8Il5x1UXx8qdceEY/9F2f
d0XctnDF5HW/+aHTvv/pm26Of/K3Hh//8DmXRETE+Wfvj+vf/vG49vMfHxFn9muzUyeTPouIeMEV
e1cJPnDbvad9/6N/8sn4ts+9MiIi3vwXt8Ztxx75/f/64sfFdV/25PjUPcfjZ266JZ5z+aPitS+6
PC47b3/8g1/864iI+N4vfHK88rMOxafvOxG/95E743u+4MqFsuyl851/6/Hxxpc/Me44djLedNMt
8aVPvSi+/cWPjUvP3R+v/uX3nVbOf/GyJ8Qv/OXReOfNj5Tzcefvi1vvPR5/9LG7IyLiJU+6MP7n
zzoUjzowi8M/v/oej+X1cP7Z++Nn/s5V8fa/uTv+zds++khgUrG+FqXUce7VL3hMvPOWe+MVV10S
P/lVT41b7j0ef/yJu+Mrn35J/LtXPCV+6S9vieM7u/HeT+/V5YmPPicOHYy47X7HLCCfWR+ByUOP
361K9zmXHYzPu/K82D+LuOScWdx5bCcuOWd/vPqzLoid3Yg/+uT98RefPjOIaEr3tz98V5za2Ynn
PeZgvO/2vZN7V110dvzZzffFjX9zb315+5rKtW/f3hWRePjwP9v7c7Yv9s32rqQsnn80lQvo06Xn
7d3LcPNdx07rb26+e6/TPHTeWWf0Q698zmNO+/frf/30QfnP/8Ut8arnPiZe86LHRkTELfcej194
9y2PBCbL/dqqaUgVU5Mufuiqy73Hjp/2/et//X0PBybX/8FH4y9vve/hnvRbP2evHDd96p544MTJ
eOen7onPfdwF8fWfeSi+41dmcfuxE3H4sy6LiIjX/cb74y3vvjV+/7MeEz/99Z95Wnlf86IrIiLi
2l9/fxz5i1vis684P/7wH78oXvmcy+K7fu19cfeDj5Tne3/7Q/Gjf/Txvd8/9NnP/Nkn4pN3HYvP
fdyFceHBA/Hum++NZx06L77kqRdV9/VL6+GH/vZVcdHB/fHl/89fxu7JkyuX+9dfcdVpSbzuNz4Q
EZFUx7nv+c0PxFs/cHvc+j1fGAcP7Is3vPWD8evvuy1u/2cvjQvO3h9PvuCseP9t98e99z8y7eDS
s2dx+z2OWUBGOyf6mcpVk+7LHndx3HP8ZNx98lTccf/xuO/EqXj/bXt927kH9sXLHnduvPNT97RO
dxYRcepk7J46Fbs7e33nqVOnInZOxu7JE1E16beXqVwPJ/7QVK29qVwP/fuhKyR7fy8HJs4+Af25
7f4Tcfn5Z8fl5+2Ldy/0N1ect9cv3XHszEvIn/Ojfxh/eesjZ3eWp3KdOH48/sOffDze8MV7T3z6
lzd+ME4cf+Q+lXl6O6d2Y/++WRzY3YnZzok4sO+RlE6eWH3p+o77T8Rjzj87LjxQ3T/Odk6e9t3j
LjwnIiJe8YxLT18uIh73qH1xx70n4vJH7V1Wf/+t98Rs50R84NP3LKS3l9aVF+yl895b7o7Zzol4
7y13RUTE/tksrjh3FvcsXC14+4dvO6N8P/p1nxn/ywsfd0Z5Lzh7f3JdvvGzr4iP3HEsfvSrn37a
cj/0iqvihj/9eLzlXTfHt7748ad99/pf3bsak1LHuQ9++p6479gDp/37wQcfubn97NjbZo8+56yH
P7vj3vsds4CsZjsnern5vS7dGz98Z3z+48+Pc8/ZFxcf3B8fvOPBeNqjz4o7HtiJnVO7ceOH71z5
27p0ZxHxZU99dDzn0nPivZ++L55x6cHY3Y1436fvi+ccOhindnbitz9818rgZF/K44IjYq2nvcxm
+x4JQB66x2QxWHl4mtd8eS9vBHr0W+//dHzj8x8X17zwyvid990SEXuzSl/9OXuD299+/9Ez+qHZ
7k5t3zTb3Ykb/vgj8V0vfXJERNzwxx+NQw8NiiMe6dc+ftcD8aSLz40XPPZR8e5P3hHPv/LRERFx
anc3PnXnvafdnD3355+4K77iMy6LZ1x6MN7+4dVlWC7fJx7K59U//654802fePjzJ1x0bnzszmMx
i4hb7n0wrrzwYDzj0nPinZ84GU+/5JwzyvvJux+IJ150bjzz0MF45yduj2ddeuHD5b3l7vtPy/P4
iTNfiPXKz967cvMtv/Cu+Nl3fjJe9tRL479+8+eclkdTXSIinnzxufHki8897bOXPPni+L0P3Raz
Uyfj/H/+66en8dD/U+o4d2rn5GmfLf97Xq5nXnpBRER89I5jcfu9x9Z+2ADASjVTo5592Xnx4sdf
EPtnZ/Y8J3d3448+fk/81afPvGF9f8M9Jn/68TvjTz9+Z0REfNvnPjZO7ezErfc+GD/6J5+qLWpd
us+49Nx47mUH471H74unX3Iw3vGJu2MWEc+74lHxvqP3xfMec2588LZ74wO3nzlFbH/FCxYXrX3F
ZN++fQ8FIRE7u81PanH2CejTG3/zL+NvP+Oy+LpnXxE3fsvnxU2fvCte+PiL4gWPvyjueuBE/MBv
/dUZ/dA/ecmT4/b7H7kC8t2/8u7Tvp/tnIhb77o3vvwn/yAiIj59171x2cELTvs+IuJn/8fH4vVf
8oz4v77m2fEPnv+4ePYVe8v88ns+Ffcfe2DlIPdX3/PJ+IrPuCxe8qSL4k1//KEVS5x5o+C//8MP
xf/5lc+OH/66Z8eXXnVJ3H98J5772Avj8gsPxrN+8K0REfFz7/xEfPsXPi2u+8pnxUuffHF89Wde
cUZ5/8MffTj+xVd8Zvybr3pWfMETHx0vf8belLafvekTce/9pw/KV92sePPdD8STLzkvvuVznxBf
8MRHx99+5uVn5PGT3/D8037zfS+/Ku584ES85uf+R0REXPA9v3za9/f8wNdGRMSLf+jG+Mtb7qkN
DFLqWFX+qn9/4ZP2nh72a3/1KccrIL+aqVFf9MTz4+SpU3HsxKkzvjv/7P3xBY97VLznU3ed8d2B
nePJU8ROntyJg/t34+TJncbl69Ld3Tkr9sWp+IxLzok//vhd8TsfumPvpo6dk/HCKy+IfXEqTp08
ufK3B5KvmHS8/2PfbF/MHrpCMpvfFD/bV/tYTYCcPnbbPfHSH/6deMOXPyte/ozL44VPuCj2zWZx
+/3H4yt+4vfiw7fefcZg9/DzT58q9E//602n/Xv+6No//+jRvX/H6kfT/qu3/mXsn+3G4Rc8MT73
iRfHHceOx8/8yUfiDb/yF5V931v+7CPxvV/+zPiqZ10e5+3bjWMnVjxacem+jB/53ffGA8dPxj/6
W0+Jv/ucK+Pkqd147y33xL9/2wcfXu6Nv/HuuPL8s+NrnnNlvOxph+Lf3vje+IGvee5p5f3hG/86
4tSpuObznhLf9DlPitvuezB+/Pc/EN//G++J2c5ObRkiIv7xkXfEv/t7L4jPvvLRcc6BffH9v/6e
+In/6YWn5fGNL3jCab/5qoeCh9ceecfK9VGX37KUOlalV/Xvv/ucx8bJU7vxU7//AccrILvZyeor
Gzd+8Gh8/hMvivP2n3lK5sETJ+NtH71z5W9nOydq0130Bx++LV7+tEvidz50W9JTuarS/etb7o43
nzgRO7u78aHbH3mq5X97763xgaN7U6M/eNv9K6dypdxjMjt09XW7xy9+YmOF5t5w+Qfju1/3huTl
IyL+1b9+Y7zxlqe1+g1AF+cc2Bf/+R++JL78WY+N7/vVd8UP3Ti+t55/8+c9LX74770oXvdLfx7/
99veX7o4W+sLr3pM/Mprvjh+6g/eH6//f/+8dHGADfTAFc+K/XfVT6Fq68L3/27c8aJXTirdY49/
XuX3Z9/xN+tN5fpX//qNrQvj0jgwpOM7Ea+64cZ47Rc9Kw6etS8uOWcWd9x/vPmHA3rT2/463vS2
vcf8uqehnD947yfiou/8zxFhOwD9mO2ciEi49aGN3dm+aaZbo/VUrh/82JXNC60wC5fGgWGd2In4
kbe+8+F/G3QCUMTOiYjKB+muabZvcummPS7Yyw8BAKAXfVyBiJ6ubPSabl8vWAQAABLsnIhZT1c2
ppRu0s3veXMFAADm7r/8WaWLMArn3VL/IJoDEREx2x8REUdvuLb3AgEAANvnzNdERhy65vq9P3Z3
Yt+gpQEAAFhBYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5g
AgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQITAACgOIEJAABQnMAEAAAoTmACAAAUJzABAACK
E5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAA
gOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQIT
AACgOIEJAABQnMAEAAAoTmACAAAUJzABAACKE5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCc
wAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5gAgAA
FCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQITAACgOIEJAABQnMAEAAAoTmACAAAUJzABAACKE5gA
AADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIE
JgAAQHECEwAAoDiBCQAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQITAACg
OIEJAABQnMAEAAAoTmACAAAUJzABAACKE5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCcwAQA
AChOYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIOlC7AOo4cOfLw34cPHy5Ykj115SlV1iNHjnTOb+iy
z/MbwzYdWo7tBQAwZZO8YjK2AVxdeUqUdTGg6GJs63lT5dpeAABTNskrJmymXIHQNl95AQCYqo0M
TFadga6bYpW6TI6BbtWgOUeZl7/ve4DetsyHDx9Oqn/Vd4u/X7VcDql5TXF7AQCM2ezQ1dftxmx/
REQcveHawsVJ1zTAXTUAnH+WskxqfinfNw3Oc5c55wA353rOsQ5T0+piytsLAGBKDl1z/d4fuzub
ecVkHU0BRV95tPntkSNHTrtJ2kC2X9YvAMBwJnnz+xAWz2KPZYC6eDbeDdPDGVMbAADYVAKTiVkc
JAtOVhO4AQBMj8DkIWMfzC6XLzU4GXu9OJ3tBQBsq0ne/N70tKw+nsqV+kSp5e/rgom6JzStW+a6
fNsaaj23yavvm99Tn8Q2xu0FADA1ize/TzIwYZo8fQoAgEWLgYmpXPTGtCQAAFIJTOjNqqeIuVoC
AMAq3mNCrwQiAACkcMUEAAAoTmACAAAUN6mpXFU3Um/bdCGPlgUAYNNM6orJ4iB8m9+ALhgBAGDT
TCowIZ1H9QIAMCWTmsqVKuXt3Tne3N30Jvi6KzpV6TRN0xJsAACwiSZ7xaTu3RjzaV5VgcHi76qW
S1kmtZxN6Sx/llLuJot5AQDA2E32ikndoLspeJhfmThy5MjD6awKbpqW6UNVHl5QCADAJpvsFZMq
y1coqqx6K/k6yyzmm3OalSseAABsk40LTNpImaI11ad/ufkdAIAp2crAZHnQXnWPSdMyi8uu+hsA
AEgzO3T1dbsx2x8REUdvuLZwceqlPG1rebnFJ12tehJWXXptlqm6gT0lnZz1AgCAqTh0zfV7f+zu
TCswAQAANsdiYLKVU7kAAIBxEZgAAADFCUwAAIDiBCYAAEBxAhMAAKC4A6UL0EbqY3X7yLdrXqve
idKnMTxKuOmdLouPPJ7/e4jyrHpUc+lHLleVo24drlvmMeRVlV/bfFLK3Ee9hpTS/+Too+bpRExj
vQCweSYVmJR4d0euFyYuD8K3yfJ2q3ofy1ByDeJySal/03txppZXVZC47rZJ+c2YtnmqlPWfa//Z
1v4JgPGYVGBCulyDsK6B4KrfjSFIG0twknJVaax5tb0a0ldedFd6fwSAiA0NTFKmfLV9G3vfA6O2
b6Kvu3pUNz2q7spFbnVpNr3dvm66Va5tUTUYS20bdes2Vcp0o1w2Na8htWkbXfavlP6nzTJNn23q
9gJgWjYyMGmaHpIyjST3ILhOSnnaDM7rrkjMv1tOu+oKwpBnqOdl6DKlJ0Xd+sk9xSi3Ia8cNOWV
856GpjRT7rFoWr7rPWqp/Uab/atK6n7etAwATMlGBiapN12vCkQoZ8htMIbpZG2NKSjJpWsAWBWA
NO3bYwo2AYA9G/e44MUBVcpUovkAhe0zpUHpJgYlAACLNiIwWTewWAxeBCerCdzOtKrNbONgfsi2
oR0CwOabfGCyzmBleZCTGpwYHDG36orbNgUlXeXal1LS2ZT9dpvqCsB2mh26+rrdmO2PiIijN1xb
uDj16g64VU+rqXp6VcpTsKrSW0fTjbdtn8pVV57UvIa6ebauPHUBYtttmlqO1KcWVZW5Kc026h5S
kDOfMebVZj23zWvdfSdnXrn2r5T+p26ZdbdFXX4AkMuha67f+2N3Z1qBCY9wlh5Yh74DgDFZDEwm
P5VrW5iiAXQlKAFgzDbyccGbaPERx4ufAVTJNYUNAIYgMJkQAwqgDX0GAFNiKhcAAFCcwAQAAChu
klO5mh6HW8KRI0eSHuU51/SY37HUaa7uEaRDlrVuPaf+fq7uscNjbGND2tSbpLu2n1xlmJvSvjPW
vADYHJO+YrL45vaS6p6WtTjAa3rT/BjqsqiuPCXK2vWpZG3eL9HUthYfROCJadMwlm00xX1nrHkB
sFkmecUE1rE4IBxbEDg21g8AMLSNC0wWz4K3fRty22WWvx/6Deqr8lpnmRzlTZ0Stc4yQ6/nJovl
Wf67bZlyrp+6Nt+0farWd9OUw3XLnCLXvpzSflLXT45tscq6bTrXvtPUJ7RpY015AUCVSb75vemA
13QfQcrApMvgpeq7lIBgnQHkOmXO8f2Y1nNfUsrSdVCZY/2ssy1yfZ6jHVZpSruP/bTq81zbIiXd
FH3tOynBS8r9WQISAFIsvvl9466YLHJgTD/jnTuPNr+d36MxT2dbtlubuqdusxLrrmuZcxjjfQ1d
goDU9HPtO23W37bsnwAMb6MDkzkH0kekTE0Z2uIAa/7vbZFa97brZAzrcMgy5Mwrdzvscz3k2HfW
7RPG0MYA2CyTfirXlDmon+7w4fonlo1J3T0m6xii7qvS38ZAcGxybPcp7TsAUEdgktni2ctl8wHE
0PdIjHmwsly+1AFWyXotbr+qv1MMXffF9HMGJSnlGXJ7dSlPjkCzrXWDiinsO2PvfwAYl0nf/D5X
92SYNvPfm55Uk5reuuk0lT1XmdvexLoqnboBUd32WLfMdfn2IXVbdLl5eVU+dXlVLZPa5peXT903
+mqHKdrc7J6SV8p+2iWvlG2Ruu+k6KOPqnt4QlMeKXkBwKLFm98nGZgAAADTtxiYmMoFAAAUJzAB
AACKE5gAAADFCUwAAIDiBCYAAEBxk3rze937QbqmOcQjLbf1hXZjeXTokOXoI69c7efIkSODtveI
7WvzwPi1fQz2+hmt+OxwxfeHlz7rq0hD1R1amtQVk+WX2Xnb8TSMpcMbshxjqfOyIV+sF5HnzeYA
fer1xceLAcb8v8XPI3oLPuoM/bJnSDWpKyZ9MFhlKqbafhZf2Ffatl61BIAp2LjAZNUbuef/rlp2
1fep6azzFvW+86rT5u3WKeswh5xvP08tc926a/v27qa8UvJs0rX9LJc3pZ3WpdO2bfS5nnO9ZR5g
FHqexgVjNrk3v7cdqDQN4Nt81/bfJfOqkppOrvyq0qv7vG3wtO7vUuq0bt7r5NWkS/tZJ42mz+af
N03bSqlzX9sYoMogfcWqIKPus1jxXY/0l4zB4pvfJ3vFZHFgUnUzrx2NOvNB9XL7WWfaUdvgZsxS
619Vn7ZBXxtNQT8AMF2TDUzamMqAkPLctN1+f+kyNS3XeraPAxvhcOxdPTkSpnKxlSb1VC6Yom0O
csZmfoUMYLRWPbkLtoTABDJoGvCOMThJGaSPbSA/xTIDAGkmdfN7ygsW29x427Rsmxttm/IcMq8m
KQ8HyPmko9S6j3GZddfPqidW5XoqV12ZU/JKffLbqmXWeZJWyn0hXdqhp3IB61jnQR3rZbTis6ob
35evlvRVpKHqDgkWb36fVGAydkPe5Nx3XlO7YTtimmUGANhmi4GJqVwdDDllxPQUAAA2mSsmHQ15
OXSovKZ4iXeKZQYA2HamcgEAAMWZygUAAIyKwAQAAChuUm9+T3lc8LppbsKTtMYsV92PHDky6LaK
2LztVbUOU+vs8bwAQB8mdcVkcfBz+PDhUb60jv4M+QS0iHG+FLGrlJdApvx+vv9t4joCAMqY1BWT
Pgx5pnebzypPte6LL/6jvW2+SggAtLNxgcniQKhpakrKG7Cb0kl5e/XQedVp84b5lHXYJs9VaaTk
tRwYpKzjunTa1mvdt5sP+dbytm9sT2k7bZYBAOhqco8LbjvYaxrAt/mu7b9L5lUlNZ1c+VWll6NM
Td/VfTb/vGnaVtvpTW0+S/1drvxT0k9dP6uuJLkqAgC0tfi44MleMVkcKFXdzGugtH1Sz+BXtY3U
K1HrXClICQa6yHn1omnfqQtQAADWMdnApA0ByvZou627TJvKdeN3rvY5dDu3XwEAOU3qqVzAOKQG
JfMrmgAATQQmTFLKgHdsg+IhyzzFEO0aMgAAIABJREFU9QMAbLdJ3fye8oLFNjfkNi3b5mblpjyH
zKtJysMBcr5EL0fdV6W17lO5qn6fusyqcqy7Dod6KlfVsnUPBlj8rK+2AQBst8Wb3ycVmIzdkO9s
6Dsv758AAKBvi4GJqVwdDDkVxrQbAAA2mSsmHQ35Loeh8vJ+CgAAhmAqFwAAUJypXAAAwKgITAAA
gOIm9eb3Ph5TeuTIkVHdQ5HraVhjeqpW3T0rKY+AXje/HGl0TWdoKe15rG1jDOVJVbWeU+szxkcu
l7pfLuWx3SnL9dlntn0UedVyKfnlfMz40PcLTm2/aFuuHI/n30Rd9p2UZZr2lcVH9leVY8xylX3K
62DRpK6YLK7o5fcsrMNTroaxartVfZdju3ZV9V6VsZtKOec2cT2nHAwW6z2WNr9osUx9WK5/0/dV
66cpnXXKlFLeuu21vEzb/FLyWqc8Q5jifjHEupnyADFF132nzXZf9bu5qa7nnMfBqa6DZZO6YrJs
HiWP7apHF7nqsSnrYx056758JmYTjLFtbOJ65kxjvCKco921KUfXATx7hrzya7usVqLP3uTjhOPg
nkkHJlXaXnZf95J6ymXE1LdpVy3bJq+c6aS82XyMcq3DRV2mduRoG01nhlLbc1WedWlVlaWPS+el
y5Or31h3Gcpoe6Yyx1X6KQ1Atn2/6OOYss7xtOrM+lD98yp97Ds5tnvXqV9DTymsyydlu2+aSU3l
SpFyWXD58vaqy92p6Swvu7zMcprrXopcTDvl8n2XdJbrPtSOsLh+1s0rV92X/14u5zy9IdpG0yXu
lPa8XK4c9Wpqh3VKreem8nTtN5bTTNnu22je3pfbfcTp27CpT6hLp69yt1muatCY8vuquletnz6M
eb9oyieXXMfluT6Pp7n65z7kCEpW7Qd1y9X1Lanjnz7XYcpxcBttXGAyl6vTTk2nqZNJ3aG22XJH
UKoMq/7OleY6eQ458BpKifWcIue67uOs6aaoO+i3GRgMMXhYVa4uyzWdoJr/NuVkxFD9pf0ij02u
W52Ueqeum9Q2v26fkBJ852JcuNpGTuWKKDfY0biosk7b6HolYBt12QeH3n/1F9PSZVC9/NmUBqn2
C7pqE0yUdvjw4dMC8bGUa1ts7BUTgDFzsJsW22sYqet5ileRx3aCaah1OKWgZK7N1LyxbM9NMenA
pM2l9aaGk2sZGANttbux9An6r+6mUvd1yjn0WV1trZuxBSecbrnt2l7Dmx26+rrdmO2PiIijN1xb
uDj1qubirrvc8rJVl9qr0qm6sWpVGvNLg6v+Tk2valpPU7nXSafNOmxSV56UdZgrr8Xvq+qeWp4h
28ZyG60biNS155RypWz31HZYZ8j1vG6ZUstVVZ5c+1eu+dkp9z6klKerNm2s6zLLy6YeL5aXbXvs
SZ3ytW5e6+4/XaaTts2v7/0ihzb9dNUybY4pXfrMVWkN0beklqcqvxz7ctNYpy54KNm3NFlnP64b
AwzVh/fh0DXX7/2xuzOtwIQyzLMEgPFrGxxv23E9Z723dR32YTEw2dib31mfnQ0ANpfje3fWYT8m
fY8J/Vi8LCpIAYDxW5zK456IM1k/02AqFwAAUMTiVC5XTAAAgOIEJgAAQHGTvPm96ZGopdIaQz45
janMuR4j2fbxs6uWS1lmVZ6l1yEAwJhN8opJzgHeUIPFKQ5Kx1LmxYF96ttYu6azuMzisvPvlpdr
yhMAgHqTDExgbNq8uA0AgDNNcipXLnUDxzZvR198E+fyMl3Kss6bT4eSWvc+3kS6al2ts35yBQ5H
jhxZeeVk3Ss7AADbaGuvmOQY0C8OPPueYrTqs5L3LqTWvev0q2VVv2+7fprKMX+Hy+K7XNqUBwCA
djbyiknq4HUs91DMNQ1y51cnxnRTepOcA/eqqzRzqeunLp2q5ecBWFWeAAB0s5GBydgH61VSyr04
EB57Paumw3XRVOfU9TPFBygAAGyyrZ3KNVWrpipVLbdpZ/JTAoCU9dNXILFp6xsAYEgCk5FaFVgs
34uy+Bl51s+6AZ3tAADQzezQ1dftxmx/REQcveHawsVJk+NJT8v3IdQ9dSt1mbryNJU591O5ckz3
6lrm5WW6TEPLtX7alrkur1VSljP1CwBgz6Frrt/7Y3dnmoHJmIzxfo+hyjTGugMAMB2LgclG3vy+
7QQKAABMjXtMOki9EX0TbXPdAQDIzxWTDrb5ysQ21x0AgPxcMQEAAIoTmAAAAMVt9FSu5UfVAgAA
47TRV0wEIwAAMA0bHZgAAADTsLFTuZoeYdvmTeJ1U8JS3/wOAABU28grJk1vJF/8fv7f4ueLvz1y
5EjlMinpAAAAzTbuiklTUNJnngAAwHo2LjApwdQtAADoZiOncgEAANMiMMnsyJEjlVO76r4DAIBt
tnGByeIN6PMb1+f/rlpm3ftScqUDAADbbnbo6ut2Y7Y/IiKO3nBt4eIAAADb4tA11+/9sbuzeVdM
AACA6RGYAAAAxQlMAACA4gQmAABAcQITAACgOG9+BwC2zvJ7xXp71P+q15cdrvj+8NJnfRVpqLpD
SwITAGBr9TooXxVgHHnov8ML3w387uVV73iDMTCVCwAAKE5gAgAwFj1P44IxE5gAAIyBoIQtJzAB
AACKE5gAAIzB8lO5YMsITAAAxkJwwhYTmAAAAMV5jwkAsLXm7/Lo5X0m83eULF/9qHrB4kC8v4Sx
mh26+rrdmO2PiIijN1xbuDgAAMC2OHTN9Xt/7O6YygUAAJQnMAEAAIoTmAAAAMUJTAAAgOIEJgAA
QHGTfFzw8mPuennEX0tHjhypLMeqx/KtWnZxubHUaW65PKXKWreeU38/d/jw4crHRI61jUWMoyzU
G9u+DABTMOkrJocPHx7FQb/ueeCLg8nF8qYGKyXVladEWbs+d315YF830G9qW0eOHHn494t/Q8T4
9mUAmIJJXjGBdSwOFqc4cJximQEAUm1cYLJ4Fjx1KtK6yyx/3/dUmxxlXrVMjvKmTolaZ5mh13OT
xfIs/92mTKltdTmfqvXXps3XTWNLLXNTGbou07ZMdWn3se+suw5T88qVTpv9K+VqIgD0ZdJTuVap
OrCuGkzWTa9KWWZ5uk+b6T9t5SpzyvfrlG1M67lvVVde2pZpsa5dpvmlpLO8njdl4JlSr1ztMNc6
bDO9s2s6bfNa7qNMUQRgSBt3xWTR1AddOTSdfe8rjza/nQ+G5unYbmyDPgb9OfbF5b8BYCgbHZjM
Geg+ou5KUimLwcn834xfyvbKtcwm2rb6AkCTjZvKNRUGJafLObWsb3X3mAAAsB6BSWZ195Esz/Mu
XZ4xWC5fanBSsl657jGZspSALNcy8+/G3I67qqtfm7pv+noCYLPNDl193W7M9kdExNEbri1cnDR1
T5VKfeJUrqf0rFp23XSayj70k4VS13Pdk3yGXM85pW6LrjeS524bXbdFijZ5dV2matlV3y0aYt+p
WmbVcjnafF91r2rL2zrFDoBhHbrm+r0/dnemGZjApig1+NvUQeeQ9drUdQgAQ1oMTEzlgi2wqVN8
hqzXpq5DABgLV0ygkNRph1PNbyhD1mtT1yEAlGIqFwAAUJypXAAAwKgITAAAgOIm9eb3uveDNC1b
95jSqs+a0pmyoR67O7RNrVcbqY8KnlvnMbVdylJXpq5lritDajq5nrY1VN27lnedvFLyS+1Tm9Ja
9zHSKfroL44cOTKpvifnOsiV1tTWIZDPpK6YLL/Mru5lfCkvvkt5iV9KXlO0qZ3+ptYrVdNALfUl
nznaedMLE1eVp2pfXv5vHSm/z7V/D1n3XH1TU16r+sMqTUFJSt3rPl8sc8pyTb/PZWrHh6p3Ca0r
x/qc2joE8ppUYNKHpgNiSoADY1AXlLQZ0PcdlLQtT1epeQ0RlPSl7xMnba5M5L7i1GTTThqV4vgG
jMGkpnL1pc0BrW3nnXLmMNcyQ0t5g/zQb6tvU+aqvHKl02a6zvLgqtQgYVWbW0fbwWLpei/mneus
cdu684hc7XDdPJs+b7rS0GUa25B9VI586vKr+76p3ts2vRrYM9nAJMdc1iEPepum6sDcdN/O/CV1
Tb+rW6ZrUFKXV6502ua16qDc5wG3zX1WfWvKN/dAZAxB0FzXwVyfZUlpp23LM+9z69IptX0Wy7ZO
vSLa3w/Ttd+o0iav+d85gpK6Y2pTnVL7967rBhi3yQYmuTqilODEGZrN0kcw2qVNLF8B6jtYbhsI
9Hngb5p+tmr5LuUZY1Cyapv3UfcqbfIaYsC8vOziv/vebl2Ck1R1+/eq/PsqR5crz4tS08jVrzmZ
CJttsoFJTk2DwVxTPFI68FzLUG2b11ubQKDvdjZ0Ox7jfjOmsozFmKar9iFlOtXiVaVNqHfT1Leh
0wHGa+tvfgeGt0mDrnVtc92pd/jw5j0JEiCFwKRC7oPC8nzePpeZf5ej7LnSGau6+rWp+xjW09AD
mdx1Xk6vbfpDboO+81qn7hHr3ySdsy4l2uFivmORsl6b2vy2Bydd2+YY+mWgndmhq6/bjdn+iIg4
esO1hYtTr829Hm1vrqw6uC0fJNaZe1x1+TnlKS9tl2mqz6p6pSyXciPsquWGXGbVcuums7hsX3Vf
dY9BjnnfXdrF8nKryt0mn2UpA61V66ipLE3lafN9Sn5d6l61TNc2n+M+gRzlaSrXOtu0qUwl6l6V
76rAomte6wacdem0OZ62yauqD0tZpmrZtnktLzu2oBU43aFrrt/7Y3dnWoEJ4zXkAcDBBihJHwSQ
z2JgYioXa9mkaTMAqQQlAP1xxYS15ZwKMKa8AOZyTa0CYDVTuQAAgOJM5QIAAEZFYAIAABQ3yTe/
1z1KsGrZdR/xu85v69Icy9zkPurXl1JlHeom19T6dXl8cerjedvItX6GeCR1CTn396bHry5b95HJ
65alrkx9tMO26YyhrbYp89A32Luhv7ucbSxlXJP6uoRcj5pelV7uvje17l3zyWlTj18lTS4wadMo
uzzJafH56DmM6alSy+/MGFPAtErubTEmqduirv5Vg9ZVaeUeKPeZTkq92tR9SH30HVX1SR385ijT
2NphSt3H0lbnUuo+lb6ZPUO0sTbL5Dpmtj1R1qXNTvEYv6nHr9ImFZgMFZRsk00e9Hc1dMdQtS3G
tn2GPAhvu7o+L9cVhlxpDLm/pOY15baaEpzkOnu8zYOgrvRjwxpLW7Xd+zOpwCTV8lnonOk1fb78
2XL+TWktGuqSX1296i4Jt5m6UHeGoK2U9d70eWoeTWnmnmZWNwBNbct9d5gp5Ulpq33Ua92699Hm
l9MtJVd/uO72Kln3tmXOlc6UBi1NfViOfj5Xn5lrP11V7rrjSl1aOdpYSr+Rs29JqVeuNNv+rq5e
qdu86YrEspT2s7xcrr4lh77GWqVMMjBZbggpA9QuulxWT2kkQ17yW1x3Vb9drO/yv9ctz6rOZ90O
dVV5UsuYqm4QV5VXH9uiraZOsm7fyaWPy9N9BiURads0pV4lDwptAvYSZVn1/VzX8o3pIDzkPpjr
ZEhVmXP187n6zFzHprrAaTm/IaT0Gzn7lnWvOKbuz+uUJaVeqSdXqtphanvOuV/VlbdqmZwBYq6x
xZAmGZikdJK5N06X4CRVagNeHgS1UbVz1i3f1XKeOTqxunzanklrSnddTXm13Rap+a1ax1WDiFLt
eZ10UgdQfZ/BGsMZsmVtA4Ehtnvd4Gp5+RxB6xgOvmPbB/tQVdac/XyXcsyNcT+dijZtdchtniKl
HQ5VzpRx6fJyXfqEoffBvkwyMKlTt9OMXVMZV50tGsoU1l9E82B/09fZmLZTzrIMFUSnGNM6jmgX
CPTddwzdN42xfx9TWbZBXaDU1ZAnsoaUu15TWx/rBrVTq+dUbVxgsum6XAbfBn1Mj5qKTa3rmIIS
qo0xSBja2KbM0c2mrtehTxpNzSbWaUq8YLGApnmHq5apmqI01Ut1fVg8SFs/p0tpc12WHzq9sZRj
nX25jaHbcd/rp3Q7LJnXOnWPGN8gaSz7chubWua+6lV6fW3Sfr+YT8T49ucxmh26+rrdmO2PiIij
N1xbuDjNVjWg1HnVbRtESl5tLvm1vfdhnWWapM57TsmjqTyr5jquc19FXUDWdOPcup1B0zpIzb9L
HlXLrVo+d/upq0+f5cmVTpd61W3TdfufrgejNuVuSqOuTF22e93Bves67Pp9Sn6l2nyXbZpDal9X
tUxqPz/U8Ss1rxzlqUpn3bSW01u3b+k69lmVxqp0cq3DVem1rdeQ7bAqnaoy1eWTc7/oOtYq6dA1
1+/9sbszvcBk7KbUEABgCGM+No65bLANFgMT95hkpHMDgPaaptM4rsJ2cMWkg9yXMQFg0+SYWtSX
MZcNtoWpXAAAQHGLgYmncgEAAMUJTAAAgOIEJgAAQHECEwAAoDiBCQAAUNzk3mPiEb0AALB5JnXF
ZPEFhvP/Fj8HAACmaVKByapAZDFAAQAApmlSgUnE6cGJKyUAALAZJheYRIRpXAAAsGEmFZgsXyUR
nAAAwGaY1FO5Dh8+vHIKl3tMAABg2iYVmEQIQgAAYBNNaioXAACwmQQmAABAcQITAACgOIEJAABQ
nMAEAAAobnJP5YqIle8yaVq27dO82uTRJs2xPFWsj/r1pVRZ12076+bTlFddeVa9y2dxubp3/axb
v1zrp0u9UpcpIef+vmodrbNNc2yzMbTDtumMoa22KfNQfU+p/DZJ7v4npd9oWqbrMTO1rZaqe9d8
chpDf7hpJheYtGmUXV68OH9nSi5jegnk4jqcvxdmzDtB7m0xJqnboq7+VYPWVWnlHij3mU5KvdrU
fUh99B1V9Uk90OUo09jaYUrdx9JW51LqPpW+edvl7n9S2mrKMrmOmW1PlPVd97Hpo0+Y4nrIbVKB
yVBByTbZ5EF/V0MPCKq2xdi2zxADPfbU9Xm5rjDkSmPI/SU1rym31ZTgJNfZY8HPeqy34Y1lnfcd
+G2zSQUmqZbPQudMr+nz5c+W829Ka9FQU1bq6lV3SbjNZcq6M9xtpaz3ps9T82hKM/c0s7oBaGpb
7nsQlVKelLbaR73WrXsfbX453VJy9Yfrbq+SdW9b5lzpTCnoburDcvTzufrMXPvpqnLXHVea0uoq
pd/I2bf0Ua+ufe/yv5vaYtP2rEpr3bHW8nK5+pYc+hprlTLJwGS5IaQMULvoclk9pZEMOWVlcd1V
/Xaxvsv/Xrc8qzqfdTvUVeVJLWOqukFcVV59bIu2mjrJun0nl1xtdVWaXZepkrJNU+pV8qDQJmAv
UZZV3891Ld+YDsJD7oO5ToZUlTlXP5+rz8x1bKoLnJbzS9F1m6b0Gzn7ltz1ynnCo65sqSdXqtph
anvOuV+1WTc5tm2usVZJkwxMUjrJ3BunS3CSqq4BVw3G26raOeuW72o5zxydWF0+bc+kNaW7rqa8
2m6L1PxWreOqQUSp9rxOOqkDqL7PYI3hDNmytoHAENu9bnC1vHyOoHUMB9+x7YN9qCprzn6+Sznm
htxPc56EGYM2bXXIbZ4ipR0OVc7U8cfidznGqct/T80kA5M6dTvN2DWVcdXZoqFMYf1FNA/2N32d
jWk75SzLUEF0ijGt44h2gUDffcfQfdMY+/cxlWUb1AVKXQ15ImtIues1tfWxblC7Kf3m2G1cYLLp
ulwG3wZ9TI+aik2t65iCEqo5uI5vyhzdbOp6Hfqk0dRsYp2mxAsWC0iZd7i8TNUUpalequvD4kHa
+jndOnNdc6673OmNpRzr7MttDN2O+14/pdthybxKzDfvw1j25Tb6KnOf66LvvqVEumPMf6i8xro/
j9Hs0NXX7cZsf0REHL3h2sLFabaqAaXOq27bIFLyanPJr+29D+ss0yR13nNKHk3lWTXXcZ37KuoC
sqYb59btDJrWQWr+XfKoWm7V8rnbT119+ixPrnS61Ktum67b/3Q9GLUpd1MadWXqst3rDu5d12HX
71PyK9Xmu2zTHFL7uqplUvv5oY5fqXnlKE/OdFalt27f0nXssyqNVekMXfe6eg3ZDqvSqSpTUz5d
9/dcY62SDl1z/d4fuzvTC0zGbkoNAQCGMOZj45jLBttgMTBxj0lGOjcAaK9pOo3jKmwHV0w6yH0Z
EwA2TY6pRX0Zc9lgW5jKBQAAFLcYmHgqFwAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxU3uPSYe
0QsAAJtnUldMFl9gOP9v8XMAAGCaJhWYrApEFgMUAABgmiYVmEScHpy4UgIAAJthcoFJRJjGBQAA
G2ZSgcnyVRLBCQAAbIZJPZXr8OHDK6dwuccEAACmbVKBSYQgBAAANtGkpnIBAACbSWACAAAUJzAB
AACKE5gAAADFCUwAAIDiJvdUrohY+S6TpmXbPs2rTR5t0hzLU8X6qF9fSpV13bazbj5NedWVZ9W7
fBaXq3vXz7r1y7V+utQrdZkScu7vq9bROts0xzYbQztsm84Y2mqbMg/V95TKb1Pl2r9SxjUpx4p1
y5LaVnP3val175pPTmPoDzfN5AKTNo2yy4sX5+9MyWVML4FcXIfz98KMeSfIvS3GJHVb1NW/atC6
Kq3cA+U+00mpV5u6D6mPvqOqPqkHuhxlGls7TKn7WNrqXErdp9I384i+9682y+Q6ZrY9UdalzU7x
GN9HnzDF9ZDbpAKToYKSbbLJg/6uhh4QVG2LsW2fIQZ67Knr83JdYciVxpD7S2peU26rKcFJrrPH
gp9u9GXDGUtb7Tvw22aTCkxSLZ+Fzple0+fLny3n35TWoqGmrNTVq+6ScJvLlHVnuNtKWe9Nn6fm
0ZRm7mlmdQPQ1Lbc90EypTwpbbWPeq1b9z7a/HK6peTqD9fdXiXr3rbMudKZ0kC1qQ/L0c/n6jNz
7aeryl13XKlLK8f+ldJv5OxbUuqVK822v6urV+o2b7qiviyl/Swvl6tvyaGvsVYpkwxMlhtCygC1
iy6X1VMayZBTVhbXXdVvF+u7/O91y7Oq81m3Q11VntQypqo7yFTl1ce2aKupk6zbd3LJ1VZXpdl1
mSop2zSlXiUPCm0C9hJlWfX9XNfyjekgPOQ+mOtkSFWZc/XzufrMXMemusBpOb86udpdSr+Rs29J
/W1qW815wqOubKnBX1U7TG3POferNusmx7bNNdYqaZKBSUonmXvjdAlOUtU14KrBeFtVO2fd8l0t
55mjE6vLJ/WsSmq662rKq+22SM1v1TquGkSUas/rpJM6gOr7DNYYzpAtaxsIDLHd6wZXy8vnCFrH
cPAd2z7Yh6qy5uznu5Rjbsj9dBMGg4vatNUht3mKlHY4VDlTxx+L3+UYpy7/PTWTDEzq1O00Y9dU
xlVni4YyhfUX0TzY3/R1NqbtlLMsQwXRKca0jiPaBQJ99x1D901j7N/HVJZtUBcodZVycmnV8mNv
A7lP0I29vsvWDWo3pd8cu40LTDZdl8vg22CxQ9m29bOpdR1TUEI1B9fxTZmjm01dr0OfNJqaTazT
lHjBYgEp8w6Xl6maojTVS3V9WDxIWz+nW2eua851lzu9sZRjnX25jaHbcd/rp3Q7LJlXifnmfRjL
vtzGppa5r3qVXl+btN8v5hMxvv15jGaHrr5uN2b7IyLi6A3XFi5Os1UNKHVeddsGkZJXm0t+be99
WGeZJqnznlPyaCrPqrmO69xXUReQNd04t25n0LQOUvPvkkfVcquWz91+6urTZ3lypdOlXnXbdN3+
p+vBqE25m9KoK1OX7V53cO+6Drt+n5JfqTbfZZvmkNrXVS2T2s8PdfxKzStHedYpW5t01u1bcpSl
9DpsW68h22FVOlVlasqn6/6ea6xV0qFrrt/7Y3dneoHJ2E2pIQDAEMZ8bBxz2WAbLAYm7jHJSOcG
AO01TadxXIXt4IpJB7kvYwLApsk1zakPYy4bbAtTuQAAgOIWAxNP5QIAAIoTmAAAAMUJTAAAgOIE
JgAAQHECEwAAoLjJvcfEI3oBAGDzTOqKyeILDOf/LX4OAABM06QCk1WByGKAAgAATNOkApOI04MT
V0oAAGAzTC4wiQjTuAAAYMNMKjBZvkoiOAEAgM0wqadyHT58eOUULveYAADAtE0qMIkQhAAAwCaa
1FQuAABgMwlMAACA4gQmAABAcQITAACgOIEJAABQ3OSeyhURK99l0rRs26d5tcmjTZpjeapYH/Xr
S6myrtt21s2nKa+68qx6l8/icnXv+lm3frnWT5d6pS5TQs79fdU6Wmeb5thmY2iHbdMZQ1ttU+ah
+p5S+W2KvvrVlHFNyrFi3XKk1it335ta96755NT1+LW83FjqVdLkApM2jbLLixfn70zJZUwvgVxc
h/P3wox5Z8i9LcYkdVvU1b9q0LoqrdwD5T7TSalXm7oPqY++o6o+qYPfHGUaWztMqftY2upcSt2n
0jezZ8h+NWWZXMfMtifKurTZKR7jc/QJYwu0xmBSgclQQck22eRBf1dDdxRV22Js22eIgR576vq8
XFcYcqUx5P6SmteU22pKcJJrUGNQxFSMpa3m7FPHUqexmFRgkmr5LHTO9Jo+X/5sOf+mtBYNNWWl
rl51lxjbTF2oO8PdVsp6b/o8NY+mNHNfgq0bgKa25b4HUSnlSWmrfdRr3br30eaX0y0lV3+47vYq
Wfe2Zc6VzpSC7qY+LEc/n6vPzLWfrip33XGlKa2uUvqNnH1LH/Xq2vcu/7vtlKfU8ca6Y63l5XL1
LTn0NdYqZZKByXJD6PuyWJfL6imNZMgpK4vrruq3i/Vd/ve65VnV+azboa4qT2oZU9UN4qry6mNb
tNXUSdbtO7nkaqur0uy6TJWUbZpSr5IHhTYBe4myrPp+rmv5xnQQHnIfzHUypKrMufr5XH1mrmNT
XeC0nF+Krts0pd/I2bfkrlfOEx51ZUs9uVLVDlPbc879ap3y5gwQc40thjTJwCSlk8y9cboEJ6nq
GnDVYLytqp2zbvmulvPM0Ykq0jDqAAATO0lEQVTV5dP2TFpTuutqyqvttkjNb9U6rhpElGrP66ST
OoDq+wzWGM6QLWsbCAyx3esGV8vL5whax3DwHds+2Ieqsubs57uUY26I/XRTtumyNvUacpunSGmH
Q5VznfFHl/Yz9D7Yl0kGJnXqdpqxayrjqrNFQ5nC+otoHuxv+job03bKWZahgugUY1rHEe0Cgb77
jqH7pjH272MqyzaoC5S6GvJE1pBy12tq62PdoHZq9ZyqjQtMNl2Xy+DboI/pUVOxqXUdU1BCtTEG
CUMb25Q5utnU9Tr0SaOp2cQ6TYkXLBaQMu9weZmqKUpTvVTXh8WDtPVzutS5rusuP3R6YynHOvty
G0O3477XT+l2WDKvdeoeMb5B0lj25Tb6KnOf66LvvqVEumPMf6i8xro/j9Hs0NXX7cZsf0REHL3h
2sLFabaqAaXOq27bIFLyanPJr+29D+ss0yR13nNKHk3lWTXXcZ37KuoCsqYb59btDJrWQWr+XfKo
Wm7V8rnbT119+ixPrnS61Ktum67b/3Q9GLUpd1MadWXqst3rDu5d12HX71PyK9Xmu2zTHFL7uqpl
Uvv5oY5fqXnlKE/OdFalt27f0nXssyqNVekMXfe6eg3ZDqvSqSpTXT4594uuY62SDl1z/d4fuzvT
C0zGbkoNAQCGMOZj45jLBttgMTBxj0lGOjcAaK9pOo3jKmwHV0w6yH0ZEwA2TY6pRX0Zc9lgW5jK
BQAAFLcYmHgqFwAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxU3uPSYe0QsAAJtnUldMFl9gOP9v
8XMAAGCaJhWYrApEFgMUAABgmiYVmEScHpy4UgIAAJthcoFJRJjGBQAAG2ZSgcnyVRLBCQAAbIZJ
PZXr8OHDK6dwuccEAACmbVKBSYQgBAAANtGkpnIBAACbSWACAAAUJzABAACKm2xg4klcAACwOSYZ
mMyDEsEJAABshskFJvNgpOkdJvPHCntDPAAAjN+kApPloKQqOFlczksYAQBg/Cb1HpNV7zBZ/mw5
eJn/LTABAIDxmtQVky68mBEAAMZrawITAABgvAQmAABAcQITAACguK0JTNz8DgAA47VxgcmqxwML
SgAAYNw2LjCJOD04WfX4YAAAYFwm9R6TNgQiAAAwHRt5xQQAAJgWgQkAAFCcwAQAAChOYAIAABQn
MAEAAIoTmGyg+WOSN+39LZtar5ymuH5ylTclnVzrZ8i8AGBbCEw20KY+KnlT67XNhgxKchFsAEA/
NvY9JrCNBG/1hlw/tgUAtCMw6aDqrfKLn+daZmiLZ4WryrjqzHFVHVKXqVsfbcpclVeudJqWWa7T
4mdtyrSqnVSlUfd9ajpDbYvl75v2gZTy1qWzvGzT913KnCOv1GUAYJPMDl193W7M9kdExNEbri1c
nGkZc2CS87d1QUndZ+ss01TuNuuqayCQo15VupQpZUCc8l3XbZFa3rq02uSxbr1TluujzF3yytWe
AWDsDl1z/d4fuzvTu2JSNeBrOpO/zjJMTx/z/7u0ieXAcxvuT5jX88iRIw+vu3XX4VDrK2eZ182/
r/LoMwGYiskFJikHwVzLtJFyNjPXMlSz3sZhcWA9/3dbba9CdZWjzGMsz1j7TABY5qlcQC8OHz48
WFCRy9jKPLbyAECfBCYZLA4YqgYPuZaZf5frXQybPNipq1+bum/6espteX2lDqxLtuuxlXnd8gDA
lLn5vaMcN3ynLlO1bNX3c21vJF+Vxqrlhlxm1XJdnmLUd92rHm7Q5Yb8uvKsWq7ppuu6dtiUV5N1
tsWqZZa/S91uQ7WfPvPKtS0AYMwWb34XmNBoyDn3Y5nfPyal1oltAQD0bTEwMZWLMww5dck0qfGw
LQCAklwxYaXU6WBTy2tqhl43tgUAMCRTuQAAgOJM5QIAAEZFYAIAABQ3uTe/RzQ/qnNM+ijrkSNH
Bqv3kHkNKeWJUyl1z7V+hm7Tm/jErRJPj+szv219pPBY+8wpHXfaSu3rIsrWve7hHG0fe57r8fJA
XpO7YrLYQUyhk8hdxiGfmrTNT2hKqXvO9TNkW97m7ZrLUA8hmPdzq16wmLLMFI21z5zC8WYdU2wv
i21+eSyQe9+Z4vqBKZvUFRNnLchlW9vQJh9kN2mbptQlZZmqPnNTr4TSn21sL5vcX8JYTSowyWXV
m7jn/161XNX3q5apWq4q/9R0lr+vG3C0LU9V+VLK23UdrptOVXkWP09ZR035pGyrrttiyHfGzMuw
bp65tlfOZZaXa3rjfdXnY9tefVmn/JvcZ+YydJvvqs36Sd3mdX1vqWmHXa5+N12FHHvdYYom9bjg
ps5jnbSaBrFVy6/7WZd0msrZJp0Uqetkvsw663DV5ynbJmVQuajNekz5vmmZXG0jl7btPSWt+e+7
bK+uy6wq1zqBydi213J+cykD/XXbbGpZNqnPbKtNHkO0+RxS029zAmZRm22YWtZVeaxKt2rfSFlm
Vb4l6w6bbPFxwZO8YrK8gx850s+0hHXOLHYZFHQ9EzvvBBfXxxAdX0qdu6afWq/lA0Hps9t1+Zc4
OK06S7pu/qkDma7pDbkNx7a9Uvq61P6wRCCVomSfOaSUfqxUH55DSt+b4xi3Ks1VbT7lOJDrWFFX
9ylvUyhhkoHJENqekc8hR2e12AnmSrNN3otyrsOS9epiLOXs8yxyXZCYQ8k2vCmGDEqm1mcOKaUf
m2pfl2LouqTkN9TJu03dppDb5J7KNWVDHbAPH96cJ/Qs2tR6pVo8sJFuVZsZaqA+hu015cHQJu7v
Kf1Yal83ljY2RmMJShbz2sT2DLkJTDJrOlCkdkwpB5zlZZb/nbMTLHkA7LNe6+Tf5zKbqvQ6XGwz
bebUj6XNd1kmYvV0r7Eo2WcOKaUfm0JfVzKvsbXdFKW3KUzNpG5+j1i9M3e5kbMunVXzRJeXa0qn
rkNqk05duaq+a0onRVVey/mklrWu7l3Wz6r5vanbbJ31nLJMrja2vGzXs3yp9e/y27Z177LMOuVK
SaOpPH1vrxzr58iR+rn3fZZnKn1mqqY2NnSbX1w2Z5/Qdv9K7XtLHbtzL7O43NB1h021ePP75AKT
XHJ16DAE7XVaNnF7bWKdpsz2ADbF5J/KBdvG4GNabC/6po0Bm2gr7zFZntMLQDV9JgBD2MorJs40
AaTTZwJ0t3///tjZ2SldjFHbyismAAAwpFtvvTUOHNjKawLJBCYAANCzSy65JE6cOBFnnXVW6aKM
1kaHbaselbnOMjnLE2FaxFTkeMToGHV9ZO7yciUfh5uzPMtprbN+Ut7H0aYMbdKpKndfjxDP8cjl
dcvTZv20fRTuOuXJlU5qvUo8UhjI481vfnMcP348zjnnnDh+/Hjp4ozOxgYmKTdouomTOovPo98U
dfWpelfEcvCeY6CTkteQ5VlOa90yz6UGK01S61SVR5syd8knNa/c5Wlaz01tI1d5hqxXm7w2rf+C
TfCqV/2DiIh48MEHBScrmMo1oMOHD2c/azW2A4/yjFeOdTG2s69dylM14Ouij328SV9tvI/1k0vK
eu67rfaxPnK2nzFtL+ARZx+8IL77n/5IvPnNb44HH3wwzj777NJFGpVJXTFZ9WbV+b+Xl1n1mzbL
tCnP4m9TplPUvYm5zZSUujOEKXnVfb5cjpR1VDeQafMG53XLnKs8q37blPZyGuuWOTWvtmksLm/A
Ur/9prR+qvqOXOkumuL6aSu1buv0D0PLsb3W7cOXvwcecfZZ58VFlz4p/uk//8mIcOVk2eTe/J46
YG4zkM45R35RmzJVBQZd5g3XHUBSgqPUsjTlVSVlPVR9vu4UjZTy1K2LprRTA56SB+2UdrisaZCT
c1pQyjbrUp4u+1bb/HKc9KjKp22bSylvXTop36+7TbvuD23296p12HSCJCWvNumkyLFNc15VXJVn
m+MMbLvd3d049JhnxDOe9Yp431/dGI8676L4wR94bbzyla/c6uBkI978PqYOb7lz7vts2ToDgz41
HYSa1k9Kmee/S7mi1KU8bQ6oYzgrmlvqlaMcc+nXGWx1LU/XAVObK2td8qoq+6p6rdqfms5ul1o/
bcuTImV/b8ortf9uE7R17R/anNzoug6b1PWZi33zPP8xHZ9hbM4+64K45NCT4pxzD8V9x47Gd1z7
gxHhysncZAOTuW3rANe56lKqPOv8vq7MdVfIcpWnjaHaXs6rFNtsyLYxRF65r8ZN8Sx3zjI3pZGa
V46yTG1bLJ84mkq5oYQDB86JRz3qonj0pU+PozffF/fd96l4zWu+KyIEJxFufp+UHJ3+qgCg63ST
EgP0VYP1MR0Uc67nw4cPr/yPdGNqG2O07etnTEHJVC32S5t4NRlyOXnywThx/IE465zz48CBc2L3
5Mm4//4745u++R+5IT62JDBZngK07jIl9XFmsMsZrlJBSdXBr/TAalX7ybGeS8pR5tT9KiWvsbXV
PtfPkP3RFNfPkPpYP2OoVy5VU2w3pX6Q2/ET98Sdd90ax++7PY4/eF+cOnU8Tp16ME6dfCBe9apX
bX1wMqmpXMsD0boDRcql5SEvP7cpe5WUs3XL9amae1w3LWrV/RzrlCdFSplXlbOvec0p5alaP3Vt
LFf5ukid778otW2sU7eUNHKVJ6V8OdZPLm3Xc1X/Mrb1k7P9NEnJK9f6GVu9ItK215DlAfacePC+
OHrLB+P22z4Yl1z6+Lj40Yfi937vTfHYK644bbmbb745rrjiiq2b1jW5p3IxvLEMrAEApmp3dzfO
fdTFcdmhZ8Uv/sKPxi//+k3x8z/3q/E9rz8cFz36YHzt135t6SIWsfhUrq2YykU7mzTNAABgLE6e
PB6/9Es/Hldd9dT4+q/7gjjrrHPjx3/qZ+OLv/hLShdtFAQmnGHq90YAAIzR2//gd+PY/ffGxRdf
HM/8jCfH4x73mPjkJ2+Nm256Z3zrt35r6eIVN6l7TBiOQAQAIK9jx47FF33RF0VExJve9KZ47bd8
VXzbt70j3vjGH4n/8l9+Mn7sx36scAnLcsUEAAB69pa3vOXhoCQi4g1veEN84UteFCd3j8fb//AP
47bbbo9nPvOZBUtYnsAEAAB69vf//t8/7d+33XZbvPOdN8Xr/snVceWVV8SxY8fiO7/zOwuVbhwm
OZVrjI8lrHsE8KobyZsejTqWOs3VPYpyyLKu+6jlxd/P1T3Kd4xtDADYLK973eviv/2334zXvuab
4z/9p/8U3/Ed31G6SEVN+orJWN6AXfcEq+UXA9a9fGoMdVnU9J6YoXV9UthyENL0jpuml/3Nf+8p
ZgDAOt7xjnfEJZdcHAcPHoxXv/rVcezYsdJFKmqSV0xgHcsvVgMAYDw2LjBZfmP3XNNUnXWWGerN
uqnlWXeZHOVNnRK1zjJDr+cmy2/ZXvxbwAMAsJ5JT+VapWqazqrBZN30qpRllqf7tJn+01auMqd8
v07ZxrSe+1Z15UVQAgCwvo27YrLIQLH5Jvu+8mjz23nANk/HdgMA2D4bd8VkldJn2Mdk+QrFGKx6
0zwAANtlKwKTMRpLUDAWOaeW9a3uHhMAANYjMMms7qz/8n0UpcszBsvlSw1OStbLPSYAAPnNDl19
3W7M9kdExNEbri1cnDR1T5VKfeJUridcrVp23XSayt7HU7nWfclgXTBRtz3WLXNdvn1I3RZ16w8A
gHqHrrl+74/dnWkGJgAAwPQtBiYb/VQuGLOUqWiuwgAA28I9JgAAQHGumEAhroYAADzCFRMAAKA4
gQkAAFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIEJgAAQHECEwAAoDiBCQAAUJzABAAA
KE5gAgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQITAACgOIEJAABQnMAEAAAoTmACAAAUJzAB
AACKE5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJ
TAAAgOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABA
cQITAACgOIEJAABQnMAEAAAoTmACAAAUJzABAACKE5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkA
AFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAAgOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5g
AgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQITAACgOIEJAABQnMAEAAAoTmACAAAUJzABAACK
E5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCcwAQAAChOYAIAABQnMAEAAIoTmAAAAMUJTAAA
gOIEJgAAQHECEwAAoDiBCQAAUJzABAAAKE5gAgAAFCcwAQAAihOYAAAAxQlMAACA4gQmAABAcQIT
AACgOIEJAABQnMAEAAAoTmACAAAUJzABAACKE5gAAADFCUwAAIDiBCYAAEBxAhMAAKA4gQkAAFCc
wAQAAChOYAIAABR3YPEfh665vlQ5AACALeaKCQAAUNzeFZPdncLFAAAAttn/D7FfMgNyjMO6AAAA
AElFTkSuQmCC
--90e6ba6e8f602e34a604b1efbbe7
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--90e6ba6e8f602e34a604b1efbbe7--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:52:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:52:58 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Gn-00027u-Bo
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4GV-00071o-5A; Thu, 17 Nov 2011 07:52:39 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jd-0005hy-D7
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:44 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321543105!3550834!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29687 invoked from network); 17 Nov 2011 15:18:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:18:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190249"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:36 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaS026286;	Thu, 17 Nov 2011 07:18:34 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:11 +0000
Message-ID: <1321543033-22090-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>
Subject: [Xen-devel] [PATCH V4 08/10] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c             |   15 +
 hw/xen_pci_passthrough_config_init.c | 2131 ++++++++++++++++++++++++++++++++++
 2 files changed, 2146 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 998470b..c816ed5 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -360,6 +360,11 @@ out:
             PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
         }
     }
+
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        qemu_mod_timer(s->pm_state->pm_timer,
+                       qemu_get_clock_ms(rt_clock) + s->pm_state->pm_delay);
+    }
 }
 
 /* ioport/iomem space*/
@@ -706,6 +711,13 @@ static int pt_initfn(PCIDevice *pcidev)
     /* Handle real device's MMIO/PIO BARs */
     pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (pt_config_init(s)) {
+        PT_ERR(pcidev, "PCI Config space initialisation failed.\n");
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         PT_LOG(pcidev, "no pin interrupt\n");
@@ -798,6 +810,9 @@ static int pt_unregister_device(PCIDevice *pcidev)
         }
     }
 
+    /* delete all emulated config registers */
+    pt_config_delete(s);
+
     /* unregister real device's MMIO/PIO BARs */
     pt_unregister_regions(s);
 
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 1e9de64..ae64544 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1,11 +1,2142 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pci_passthrough.h"
 
+#define PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data);
+static int pt_init_pci_config(XenPCIPassthroughState *s);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+/* parse BAR */
+static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int flags = s->real_device->io_regions[index - 1].flags;
+
+        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
+                return PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
+        return PT_BAR_FLAG_IO;
+    } else {
+        return PT_BAR_FLAG_MEM;
+    }
+}
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int pt_common_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+
+/* Write register functions */
+
+static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint8_t *value, uint8_t dev_value,
+                             uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t dev_value,
+                             uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint32_t *value, uint32_t dev_value,
+                             uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* common restore register fonctions */
+static int pt_byte_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint8_t dev_value,
+                               uint8_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_byte(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint16_t dev_value,
+                               uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int pt_vendor_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->vendor_id;
+    return 0;
+}
+static int pt_device_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->device_id;
+    return 0;
+}
+static int pt_status_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t dev_value,
+                            uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t wr_value = *value;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*value & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* mapping BAR */
+    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
+                   wr_value & PCI_COMMAND_MEMORY);
+
+    return 0;
+}
+static int pt_cmd_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint16_t dev_value,
+                              uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+    uint16_t restorable_mask = 0;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring to I/O device register
+     * but do not include Fast Back-to-Back Enable bit.
+     */
+    restorable_mask = reg->emu_mask & ~PCI_COMMAND_FAST_BACK;
+    *value = PT_MERGE_VALUE(*value, dev_value, restorable_mask);
+
+    if (!s->machine_irq) {
+        *value |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        *value &= ~PCI_COMMAND_INTX_DISABLE;
+    }
+
+    return 0;
+}
+
+/* BAR */
+#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
+#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
+#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
+#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
+
+static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
+{
+    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set initial guest physical base address to -1 */
+    s->bases[index].e_physbase = -1;
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
+        reg_field = PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device->io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t dev_value,
+                            uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t new_addr, last_addr;
+    uint32_t prev_offset;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_IO:
+        new_addr = cfg_entry->data;
+        last_addr = new_addr + r_size - 1;
+        /* check invalid address */
+        if (last_addr <= new_addr || !new_addr || last_addr >= UINT16_MAX) {
+            /* check 64K range */
+            if ((last_addr >= UINT16_MAX) &&
+                (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask))) {
+                PT_WARN(d, "Guest attempt to set Base Address "
+                       "over the 64KB. (offset: 0x%02x,"
+                       " addr: 0x%08x, size: 0x%08x)\n",
+                       reg->offset, new_addr, r_size);
+            }
+            /* just remove mapping */
+            r->addr = PCI_BAR_UNMAPPED;
+            goto exit;
+        }
+        break;
+    case PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
+                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                        "Ignore mapping. "
+                        "(offset: 0x%02x, high address: 0x%08x)\n",
+                        reg->offset, cfg_entry->data);
+            }
+            /* clear lower address */
+            d->io_regions[index-1].addr = -1;
+        } else {
+            /* find lower 32bit BAR */
+            prev_offset = (reg->offset - 4);
+            reg_grp_entry = pt_find_reg_grp(s, prev_offset);
+            if (reg_grp_entry) {
+                reg_entry = pt_find_reg(reg_grp_entry, prev_offset);
+                if (reg_entry) {
+                    /* restore lower address */
+                    d->io_regions[index-1].addr = reg_entry->data;
+                } else {
+                    return -1;
+                }
+            } else {
+                return -1;
+            }
+        }
+
+        /* never mapping the 'empty' upper region,
+         * because we'll do it enough for the lower region.
+         */
+        r->addr = -1;
+        goto exit;
+    default:
+        break;
+    }
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+exit:
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+static int pt_bar_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint32_t dev_value,
+                              uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t bar_emu_mask = 0;
+    int index = 0;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use value from kernel sysfs */
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UPPER) {
+        *value = s->real_device->io_regions[index - 1].base_addr >> 32;
+    } else {
+        *value = base_address_with_flags(&s->real_device->io_regions[index]);
+    }
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, bar_emu_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint32_t *value,
+                                    uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r = &d->io_regions[PCI_ROM_SLOT];
+    r_size = r->size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR*/
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, PCI_ROM_SLOT,
+                               reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+/* restore ROM BAR */
+static int pt_exp_rom_bar_reg_restore(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry,
+                                      uint32_t real_offset,
+                                      uint32_t dev_value, uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t v;
+
+    if (host_pci_get_long(s->real_device, PCI_ROM_ADDRESS, &v)) {
+        return -1;
+    }
+    /* use value from kernel sysfs */
+    *value = PT_MERGE_VALUE(v, dev_value, reg->emu_mask);
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_vendor_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_device_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_cmd_reg_read,
+        .u.w.write  = pt_cmd_reg_write,
+        .u.w.restore  = pt_cmd_reg_restore,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = pt_status_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = pt_header_type_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_irqpin_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_exp_rom_bar_reg_write,
+        .u.dw.restore = pt_exp_rom_bar_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+/* initialize Link Control register */
+static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = 0;
+    uint8_t dev_type = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+    dev_type = (pci_get_byte(s->dev.config + real_offset - reg->offset
+                             + PCI_EXP_FLAGS)
+                & PCI_EXP_FLAGS_TYPE) >> 4;
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    uint8_t cap_ver = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_long_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_devctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* initialize Power Management Capabilities register */
+static int pt_pmc_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+
+    if (s->power_mgmt) {
+        /* set Power Management Capabilities register */
+        s->pm_state->pmc_field = pci_get_word(d->config + real_offset);
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize PCI Power Management Control/Status register */
+static int pt_pmcsr_reg_init(XenPCIPassthroughState *s,
+                             XenPTRegInfo *reg, uint32_t real_offset,
+                             uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t cap_ver  = 0;
+    uint16_t v = 0;
+
+    if (!s->power_mgmt) {
+        *data = reg->init_val;
+        return 0;
+    }
+
+    /* check PCI Power Management support version */
+    cap_ver = s->pm_state->pmc_field & PCI_PM_CAP_VER_MASK;
+
+    if (cap_ver > 2) {
+        /* set No Soft Reset */
+        s->pm_state->no_soft_reset =
+            pci_get_byte(d->config + real_offset) & PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    host_pci_get_word(s->real_device, real_offset, &v);
+    /* wake up real physical device */
+    switch (v & PCI_PM_CTRL_STATE_MASK) {
+    case 0:
+        break;
+    case 1:
+        PT_LOG(d, "Power state transition D1 -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        break;
+    case 2:
+        PT_LOG(d, "Power state transition D2 -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        usleep(200);
+        break;
+    case 3:
+        PT_LOG(d, "Power state transition D3hot -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        usleep(10 * 1000);
+        if (pt_init_pci_config(s)) {
+            return -1;
+        }
+        break;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* read Power Management Control/Status register */
+static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    if (!s->power_mgmt) {
+        valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* reset Interrupt and I/O resource  */
+static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    PCIIORegion *r;
+    int i = 0;
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    /* unbind INTx */
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+
+    if (s->machine_irq) {
+        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
+                                    PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
+            PT_ERR(d, "Unbinding of interrupt failed!\n");
+        }
+    }
+
+    /* clear all virtual region address */
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        r = &d->io_regions[i];
+        r->addr = -1;
+    }
+
+    /* unmapping BAR */
+    pt_bar_mapping(s, 0, 0);
+}
+/* check power state transition */
+static int check_power_state(XenPCIPassthroughState *s)
+{
+    XenPTPM *pm_state = s->pm_state;
+    PCIDevice *d = &s->dev;
+    uint16_t read_val = 0;
+    uint16_t cur_state = 0;
+
+    /* get current power state */
+    if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                          &read_val)) {
+        return -1;
+    }
+    cur_state = read_val & PCI_PM_CTRL_STATE_MASK;
+
+    if (pm_state->req_state != cur_state) {
+        PT_ERR(d, "Failed to change power state. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, cur_state);
+        return -1;
+    }
+    return 0;
+}
+/* write Power Management Control/Status register */
+static void pt_from_d3hot_to_d0_with_reset(void *opaque)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTPM *pm_state = s->pm_state;
+    int ret = 0;
+
+    /* check power state */
+    ret = check_power_state(s);
+
+    if (ret < 0) {
+        goto out;
+    }
+
+    pt_init_pci_config(s);
+
+out:
+    /* power state transition flags off */
+    pm_state->flags &= ~PT_FLAG_TRANSITING;
+
+    qemu_free_timer(pm_state->pm_timer);
+    pm_state->pm_timer = NULL;
+}
+static void pt_default_power_transition(void *opaque)
+{
+    XenPCIPassthroughState *ptdev = opaque;
+    XenPTPM *pm_state = ptdev->pm_state;
+
+    /* check power state */
+    check_power_state(ptdev);
+
+    /* power state transition flags off */
+    pm_state->flags &= ~PT_FLAG_TRANSITING;
+
+    qemu_free_timer(pm_state->pm_timer);
+    pm_state->pm_timer = NULL;
+}
+static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint16_t *value, uint16_t dev_value,
+                              uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    XenPTPM *pm_state = s->pm_state;
+
+    if (!s->power_mgmt) {
+        emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    if (!s->power_mgmt) {
+        return 0;
+    }
+
+    /* set I/O device power state */
+    pm_state->cur_state = dev_value & PCI_PM_CTRL_STATE_MASK;
+
+    /* set Guest requested PowerState */
+    pm_state->req_state = *value & PCI_PM_CTRL_STATE_MASK;
+
+    /* check power state transition or not */
+    if (pm_state->cur_state == pm_state->req_state) {
+        /* not power state transition */
+        return 0;
+    }
+
+    /* check enable power state transition */
+    if ((pm_state->req_state != 0) &&
+        (pm_state->cur_state > pm_state->req_state)) {
+        PT_ERR(d, "Invalid power transition. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, pm_state->cur_state);
+
+        return 0;
+    }
+
+    /* check if this device supports the requested power state */
+    if (((pm_state->req_state == 1) && !(pm_state->pmc_field & PCI_PM_CAP_D1))
+        || ((pm_state->req_state == 2) &&
+            !(pm_state->pmc_field & PCI_PM_CAP_D2))) {
+        PT_ERR(d, "Invalid power transition. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, pm_state->cur_state);
+
+        return 0;
+    }
+
+    /* in case of transition related to D3hot, it's necessary to wait 10 ms.
+     * But because writing to register will be performed later on actually,
+     * don't start QEMUTimer right now, just alloc and init QEMUTimer here.
+     */
+    if ((pm_state->cur_state == 3) || (pm_state->req_state == 3)) {
+        if (pm_state->req_state == 0) {
+            /* alloc and init QEMUTimer */
+            if (!pm_state->no_soft_reset) {
+                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                    pt_from_d3hot_to_d0_with_reset, s);
+
+                /* reset Interrupt and I/O resource mapping */
+                pt_reset_interrupt_and_io_mapping(s);
+            } else {
+                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                                        pt_default_power_transition, s);
+            }
+        } else {
+            /* alloc and init QEMUTimer */
+            pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                pt_default_power_transition, s);
+        }
+
+        /* set power state transition delay */
+        pm_state->pm_delay = 10;
+
+        /* power state transition flags on */
+        pm_state->flags |= PT_FLAG_TRANSITING;
+    }
+    /* in case of transition related to D0, D1 and D2,
+     * no need to use QEMUTimer.
+     * So, we perfom writing to register here and then read it back.
+     */
+    else {
+        /* write power state to I/O device register */
+        host_pci_set_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                          *value);
+
+        /* in case of transition related to D2,
+         * it's necessary to wait 200 usec.
+         * But because QEMUTimer do not support microsec unit right now,
+         * so we do wait ourself here.
+         */
+        if ((pm_state->cur_state == 2) || (pm_state->req_state == 2)) {
+            usleep(200);
+        }
+
+        /* check power state */
+        check_power_state(s);
+
+        /* recreate value for writing to I/O device register */
+        if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                              value)) {
+            return -1;
+        }
+    }
+
+    return 0;
+}
+
+/* restore Power Management Control/Status register */
+static int pt_pmcsr_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t real_offset, uint16_t dev_value,
+                                uint16_t *value)
+{
+    /* create value for restoring to I/O device register
+     * No need to restore, just clear PME Enable and PME Status bit
+     * Note: register type of PME Status bit is RW1C, so clear by writing 1b
+     */
+    *value = (dev_value & ~PCI_PM_CTRL_PME_ENABLE) | PCI_PM_CTRL_PME_STATUS;
+
+    return 0;
+}
+
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = pt_pmc_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = pt_pmcsr_reg_init,
+        .u.w.read   = pt_pmcsr_reg_read,
+        .u.w.write  = pt_pmcsr_reg_write,
+        .u.w.restore  = pt_pmcsr_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* AER register operations */
+
+static void aer_save_one_register(XenPCIPassthroughState *s, int offset)
+{
+    PCIDevice *d = &s->dev;
+    uint32_t aer_base = s->pm_state->aer_base;
+    uint32_t val = 0;
+
+    if (host_pci_get_long(s->real_device, aer_base + offset, &val)) {
+        return;
+    }
+    pci_set_long(d->config + aer_base + offset, val);
+}
+static void pt_aer_reg_save(XenPCIPassthroughState *s)
+{
+    /* after reset, following register values should be restored.
+     * So, save them.
+     */
+    aer_save_one_register(s, PCI_ERR_UNCOR_MASK);
+    aer_save_one_register(s, PCI_ERR_UNCOR_SEVER);
+    aer_save_one_register(s, PCI_ERR_COR_MASK);
+    aer_save_one_register(s, PCI_ERR_CAP);
+}
+static void aer_restore_one_register(XenPCIPassthroughState *s, int offset)
+{
+    PCIDevice *d = &s->dev;
+    uint32_t aer_base = s->pm_state->aer_base;
+    uint32_t config = 0;
+
+    config = pci_get_long(d->config + aer_base + offset);
+    host_pci_set_long(s->real_device, aer_base + offset, config);
+}
+static void pt_aer_reg_restore(XenPCIPassthroughState *s)
+{
+    /* the following registers should be reconfigured to correct values
+     * after reset. restore them.
+     * other registers should not be reconfigured after reset
+     * if there is no reason
+     */
+    aer_restore_one_register(s, PCI_ERR_UNCOR_MASK);
+    aer_restore_one_register(s, PCI_ERR_UNCOR_SEVER);
+    aer_restore_one_register(s, PCI_ERR_COR_MASK);
+    aer_restore_one_register(s, PCI_ERR_CAP);
+}
+
+/* capability structure register group size functions */
+
+static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Power Management Capability Structure register group size */
+static int pt_pm_size_init(XenPCIPassthroughState *s,
+                           const XenPTRegGroupInfo *grp_reg,
+                           uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+
+    if (!s->power_mgmt) {
+        return 0;
+    }
+
+    s->pm_state = g_new0(XenPTPM, 1);
+
+    /* set Power Management Capability base offset */
+    s->pm_state->pm_base = base_offset;
+
+    /* find AER register and set AER Capability base offset */
+    s->pm_state->aer_base = host_pci_find_ext_cap_offset(s->real_device,
+                                                         PCI_EXT_CAP_ID_ERR);
+
+    /* save AER register */
+    if (s->pm_state->aer_base) {
+        pt_aer_reg_save(s);
+    }
+
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int pt_vendor_size_init(XenPCIPassthroughState *s,
+                               const XenPTRegGroupInfo *grp_reg,
+                               uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int pt_pcie_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t exp_flag = 0;
+    uint16_t type = 0;
+    uint16_t version = 0;
+    uint8_t pcie_size = 0;
+
+    exp_flag = pci_get_word(d->config + base_offset + PCI_EXP_FLAGS);
+    type = (exp_flag & PCI_EXP_FLAGS_TYPE) >> 4;
+    version = exp_flag & PCI_EXP_FLAGS_VERS;
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
+                   type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
+                   type);
+            return -1;
+        }
+    } else {
+        PT_ERR(d, "Internal error: Unsupported capability version (%d).\n",
+               version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_header0_tbl,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = pt_pm_size_init,
+        .emu_reg_tbl = pt_emu_reg_pm_tbl,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_vendor_size_init,
+        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_pcie_size_init,
+        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int pt_ptr_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    /* uint32_t reg_field = (uint32_t)s->dev.config[real_offset]; */
+    uint32_t reg_field = pci_get_byte(s->dev.config + real_offset);
+    int i;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+            if (pt_emu_reg_grp_tbl[i].grp_id == s->dev.config[reg_field]) {
+                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+        /* next capability */
+        /* reg_field = (uint32_t)s->dev.config[reg_field + 1]; */
+        reg_field = pci_get_byte(s->dev.config + reg_field + 1);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+/* restore a part of I/O device register */
+static int pt_config_restore(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+    uint32_t read_val = 0;
+    uint32_t val = 0;
+    int rc = 0;
+
+    /* find emulate register group entry */
+    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
+        /* find emulate register entry */
+        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
+            reg = reg_entry->reg;
+
+            /* check whether restoring is needed */
+            if (!reg->u.b.restore) {
+                continue;
+            }
+
+            real_offset = reg_grp_entry->base_offset + reg->offset;
+
+            /* read I/O device register value */
+            rc = host_pci_get_block(s->real_device, real_offset,
+                                    (uint8_t *)&read_val, reg->size);
+
+            if (rc < 0) {
+                PT_ERR(&s->dev, "pci_read_block failed. "
+                       "return value: %d.\n", rc);
+                memset(&read_val, 0xff, reg->size);
+            }
+
+            val = 0;
+
+            /* restore based on register size */
+            switch (reg->size) {
+            case 1:
+                /* byte register */
+                rc = reg->u.b.restore(s, reg_entry, real_offset,
+                                      (uint8_t)read_val, (uint8_t *)&val);
+                break;
+            case 2:
+                /* word register */
+                rc = reg->u.w.restore(s, reg_entry, real_offset,
+                                      (uint16_t)read_val, (uint16_t *)&val);
+                break;
+            case 4:
+                /* double word register */
+                rc = reg->u.dw.restore(s, reg_entry, real_offset,
+                                       (uint32_t)read_val, (uint32_t *)&val);
+                break;
+            }
+
+            /* restoring error */
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid restoring."
+                                         " (%s, rc: %d)\n", __func__, rc);
+                return -1;
+            }
+
+            PT_LOG_CONFIG(&s->dev, real_offset, val, reg->size);
+
+            rc = host_pci_set_block(s->real_device, real_offset,
+                                    (uint8_t *)&val, reg->size);
+
+            if (rc < 0) {
+                PT_ERR(&s->dev, "pci_write_block failed. "
+                       "return value: %d.\n", rc);
+                return -1;
+            }
+        }
+    }
+
+    /* if AER supported, restore it */
+    if (s->pm_state->aer_base) {
+        pt_aer_reg_restore(s);
+    }
+    return 0;
+}
+/* reinitialize all emulate registers */
+static int pt_config_reinit(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    int rc = 0;
+
+    /* find emulate register group entry */
+    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
+        /* find emulate register entry */
+        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
+            reg = reg_entry->reg;
+            if (reg->init) {
+                /* initialize emulate register */
+                rc = reg->init(s, reg_entry->reg,
+                               reg_grp_entry->base_offset + reg->offset,
+                               &reg_entry->data);
+                if (rc < 0) {
+                    return rc;
+                }
+            }
+        }
+    }
+    return 0;
+}
+
+static int pt_init_pci_config(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    int rc = 0;
+
+    PT_LOG(d, "Reinitialize PCI configuration registers due to power state"
+           " transition with internal reset.\n");
+
+    /* restore a part of I/O device register */
+    rc = pt_config_restore(s);
+    if (rc < 0) {
+        return rc;
+    }
+
+    /* reinitialize all emulate register */
+    rc = pt_config_reinit(s);
+    if (rc < 0) {
+        return rc;
+    }
+
+    /* rebind machine_irq to device */
+    if (s->machine_irq != 0) {
+        uint8_t e_device = PCI_SLOT(s->dev.devfn);
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq, 0,
+                                       e_device, e_intx);
+        if (rc < 0) {
+            PT_ERR(d, "Rebinding of interrupt failed! rc=%d\n", rc);
+        }
+    }
+
+    return rc;
+}
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    int max_cap = 48;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (host_pci_get_byte(s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < 0x40) {
+            break;
+        }
+
+        pos &= ~3;
+        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int pt_config_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int pt_config_init(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    uint32_t reg_grp_offset = 0;
+    XenPTRegInfo *reg_tbl = NULL;
+    int i, j, rc;
+
+    QLIST_INIT(&s->reg_grp_tbl);
+
+    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
+        if (pt_emu_reg_grp_tbl[i].size_init) {
+            /* get register group size */
+            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
+                                                 reg_grp_offset,
+                                                 &reg_grp_entry->size);
+            if (rc < 0) {
+                pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
+                reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
+                /* initialize capability register */
+                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
+                    /* initialize capability register */
+                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
+                    if (rc < 0) {
+                        pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+        reg_grp_offset = 0;
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free Power Management info table */
+    if (s->pm_state) {
+        if (s->pm_state->pm_timer) {
+            qemu_del_timer(s->pm_state->pm_timer);
+            qemu_free_timer(s->pm_state->pm_timer);
+            s->pm_state->pm_timer = NULL;
+        }
+
+        g_free(s->pm_state);
+    }
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:52:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:52:58 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Gn-00027u-Bo
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4GV-00071o-5A; Thu, 17 Nov 2011 07:52:39 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jd-0005hy-D7
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:44 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321543105!3550834!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29687 invoked from network); 17 Nov 2011 15:18:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:18:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190249"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:36 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaS026286;	Thu, 17 Nov 2011 07:18:34 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:11 +0000
Message-ID: <1321543033-22090-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>
Subject: [Xen-devel] [PATCH V4 08/10] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c             |   15 +
 hw/xen_pci_passthrough_config_init.c | 2131 ++++++++++++++++++++++++++++++++++
 2 files changed, 2146 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 998470b..c816ed5 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -360,6 +360,11 @@ out:
             PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
         }
     }
+
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        qemu_mod_timer(s->pm_state->pm_timer,
+                       qemu_get_clock_ms(rt_clock) + s->pm_state->pm_delay);
+    }
 }
 
 /* ioport/iomem space*/
@@ -706,6 +711,13 @@ static int pt_initfn(PCIDevice *pcidev)
     /* Handle real device's MMIO/PIO BARs */
     pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (pt_config_init(s)) {
+        PT_ERR(pcidev, "PCI Config space initialisation failed.\n");
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         PT_LOG(pcidev, "no pin interrupt\n");
@@ -798,6 +810,9 @@ static int pt_unregister_device(PCIDevice *pcidev)
         }
     }
 
+    /* delete all emulated config registers */
+    pt_config_delete(s);
+
     /* unregister real device's MMIO/PIO BARs */
     pt_unregister_regions(s);
 
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 1e9de64..ae64544 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1,11 +1,2142 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pci_passthrough.h"
 
+#define PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data);
+static int pt_init_pci_config(XenPCIPassthroughState *s);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+/* parse BAR */
+static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int flags = s->real_device->io_regions[index - 1].flags;
+
+        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
+                return PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
+        return PT_BAR_FLAG_IO;
+    } else {
+        return PT_BAR_FLAG_MEM;
+    }
+}
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int pt_common_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+
+/* Write register functions */
+
+static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint8_t *value, uint8_t dev_value,
+                             uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t dev_value,
+                             uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint32_t *value, uint32_t dev_value,
+                             uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* common restore register fonctions */
+static int pt_byte_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint8_t dev_value,
+                               uint8_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_byte(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint16_t dev_value,
+                               uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int pt_vendor_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->vendor_id;
+    return 0;
+}
+static int pt_device_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->device_id;
+    return 0;
+}
+static int pt_status_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t dev_value,
+                            uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t wr_value = *value;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*value & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* mapping BAR */
+    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
+                   wr_value & PCI_COMMAND_MEMORY);
+
+    return 0;
+}
+static int pt_cmd_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint16_t dev_value,
+                              uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+    uint16_t restorable_mask = 0;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring to I/O device register
+     * but do not include Fast Back-to-Back Enable bit.
+     */
+    restorable_mask = reg->emu_mask & ~PCI_COMMAND_FAST_BACK;
+    *value = PT_MERGE_VALUE(*value, dev_value, restorable_mask);
+
+    if (!s->machine_irq) {
+        *value |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        *value &= ~PCI_COMMAND_INTX_DISABLE;
+    }
+
+    return 0;
+}
+
+/* BAR */
+#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
+#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
+#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
+#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
+
+static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
+{
+    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set initial guest physical base address to -1 */
+    s->bases[index].e_physbase = -1;
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
+        reg_field = PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device->io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t dev_value,
+                            uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t new_addr, last_addr;
+    uint32_t prev_offset;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_IO:
+        new_addr = cfg_entry->data;
+        last_addr = new_addr + r_size - 1;
+        /* check invalid address */
+        if (last_addr <= new_addr || !new_addr || last_addr >= UINT16_MAX) {
+            /* check 64K range */
+            if ((last_addr >= UINT16_MAX) &&
+                (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask))) {
+                PT_WARN(d, "Guest attempt to set Base Address "
+                       "over the 64KB. (offset: 0x%02x,"
+                       " addr: 0x%08x, size: 0x%08x)\n",
+                       reg->offset, new_addr, r_size);
+            }
+            /* just remove mapping */
+            r->addr = PCI_BAR_UNMAPPED;
+            goto exit;
+        }
+        break;
+    case PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
+                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                        "Ignore mapping. "
+                        "(offset: 0x%02x, high address: 0x%08x)\n",
+                        reg->offset, cfg_entry->data);
+            }
+            /* clear lower address */
+            d->io_regions[index-1].addr = -1;
+        } else {
+            /* find lower 32bit BAR */
+            prev_offset = (reg->offset - 4);
+            reg_grp_entry = pt_find_reg_grp(s, prev_offset);
+            if (reg_grp_entry) {
+                reg_entry = pt_find_reg(reg_grp_entry, prev_offset);
+                if (reg_entry) {
+                    /* restore lower address */
+                    d->io_regions[index-1].addr = reg_entry->data;
+                } else {
+                    return -1;
+                }
+            } else {
+                return -1;
+            }
+        }
+
+        /* never mapping the 'empty' upper region,
+         * because we'll do it enough for the lower region.
+         */
+        r->addr = -1;
+        goto exit;
+    default:
+        break;
+    }
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+exit:
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+static int pt_bar_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint32_t dev_value,
+                              uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t bar_emu_mask = 0;
+    int index = 0;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use value from kernel sysfs */
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UPPER) {
+        *value = s->real_device->io_regions[index - 1].base_addr >> 32;
+    } else {
+        *value = base_address_with_flags(&s->real_device->io_regions[index]);
+    }
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, bar_emu_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint32_t *value,
+                                    uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r = &d->io_regions[PCI_ROM_SLOT];
+    r_size = r->size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR*/
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, PCI_ROM_SLOT,
+                               reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+/* restore ROM BAR */
+static int pt_exp_rom_bar_reg_restore(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry,
+                                      uint32_t real_offset,
+                                      uint32_t dev_value, uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t v;
+
+    if (host_pci_get_long(s->real_device, PCI_ROM_ADDRESS, &v)) {
+        return -1;
+    }
+    /* use value from kernel sysfs */
+    *value = PT_MERGE_VALUE(v, dev_value, reg->emu_mask);
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_vendor_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_device_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_cmd_reg_read,
+        .u.w.write  = pt_cmd_reg_write,
+        .u.w.restore  = pt_cmd_reg_restore,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = pt_status_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = pt_header_type_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_irqpin_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_exp_rom_bar_reg_write,
+        .u.dw.restore = pt_exp_rom_bar_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+/* initialize Link Control register */
+static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = 0;
+    uint8_t dev_type = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+    dev_type = (pci_get_byte(s->dev.config + real_offset - reg->offset
+                             + PCI_EXP_FLAGS)
+                & PCI_EXP_FLAGS_TYPE) >> 4;
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    uint8_t cap_ver = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_long_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_devctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* initialize Power Management Capabilities register */
+static int pt_pmc_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+
+    if (s->power_mgmt) {
+        /* set Power Management Capabilities register */
+        s->pm_state->pmc_field = pci_get_word(d->config + real_offset);
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize PCI Power Management Control/Status register */
+static int pt_pmcsr_reg_init(XenPCIPassthroughState *s,
+                             XenPTRegInfo *reg, uint32_t real_offset,
+                             uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t cap_ver  = 0;
+    uint16_t v = 0;
+
+    if (!s->power_mgmt) {
+        *data = reg->init_val;
+        return 0;
+    }
+
+    /* check PCI Power Management support version */
+    cap_ver = s->pm_state->pmc_field & PCI_PM_CAP_VER_MASK;
+
+    if (cap_ver > 2) {
+        /* set No Soft Reset */
+        s->pm_state->no_soft_reset =
+            pci_get_byte(d->config + real_offset) & PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    host_pci_get_word(s->real_device, real_offset, &v);
+    /* wake up real physical device */
+    switch (v & PCI_PM_CTRL_STATE_MASK) {
+    case 0:
+        break;
+    case 1:
+        PT_LOG(d, "Power state transition D1 -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        break;
+    case 2:
+        PT_LOG(d, "Power state transition D2 -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        usleep(200);
+        break;
+    case 3:
+        PT_LOG(d, "Power state transition D3hot -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        usleep(10 * 1000);
+        if (pt_init_pci_config(s)) {
+            return -1;
+        }
+        break;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* read Power Management Control/Status register */
+static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    if (!s->power_mgmt) {
+        valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* reset Interrupt and I/O resource  */
+static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    PCIIORegion *r;
+    int i = 0;
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    /* unbind INTx */
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+
+    if (s->machine_irq) {
+        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
+                                    PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
+            PT_ERR(d, "Unbinding of interrupt failed!\n");
+        }
+    }
+
+    /* clear all virtual region address */
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        r = &d->io_regions[i];
+        r->addr = -1;
+    }
+
+    /* unmapping BAR */
+    pt_bar_mapping(s, 0, 0);
+}
+/* check power state transition */
+static int check_power_state(XenPCIPassthroughState *s)
+{
+    XenPTPM *pm_state = s->pm_state;
+    PCIDevice *d = &s->dev;
+    uint16_t read_val = 0;
+    uint16_t cur_state = 0;
+
+    /* get current power state */
+    if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                          &read_val)) {
+        return -1;
+    }
+    cur_state = read_val & PCI_PM_CTRL_STATE_MASK;
+
+    if (pm_state->req_state != cur_state) {
+        PT_ERR(d, "Failed to change power state. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, cur_state);
+        return -1;
+    }
+    return 0;
+}
+/* write Power Management Control/Status register */
+static void pt_from_d3hot_to_d0_with_reset(void *opaque)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTPM *pm_state = s->pm_state;
+    int ret = 0;
+
+    /* check power state */
+    ret = check_power_state(s);
+
+    if (ret < 0) {
+        goto out;
+    }
+
+    pt_init_pci_config(s);
+
+out:
+    /* power state transition flags off */
+    pm_state->flags &= ~PT_FLAG_TRANSITING;
+
+    qemu_free_timer(pm_state->pm_timer);
+    pm_state->pm_timer = NULL;
+}
+static void pt_default_power_transition(void *opaque)
+{
+    XenPCIPassthroughState *ptdev = opaque;
+    XenPTPM *pm_state = ptdev->pm_state;
+
+    /* check power state */
+    check_power_state(ptdev);
+
+    /* power state transition flags off */
+    pm_state->flags &= ~PT_FLAG_TRANSITING;
+
+    qemu_free_timer(pm_state->pm_timer);
+    pm_state->pm_timer = NULL;
+}
+static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint16_t *value, uint16_t dev_value,
+                              uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    XenPTPM *pm_state = s->pm_state;
+
+    if (!s->power_mgmt) {
+        emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    if (!s->power_mgmt) {
+        return 0;
+    }
+
+    /* set I/O device power state */
+    pm_state->cur_state = dev_value & PCI_PM_CTRL_STATE_MASK;
+
+    /* set Guest requested PowerState */
+    pm_state->req_state = *value & PCI_PM_CTRL_STATE_MASK;
+
+    /* check power state transition or not */
+    if (pm_state->cur_state == pm_state->req_state) {
+        /* not power state transition */
+        return 0;
+    }
+
+    /* check enable power state transition */
+    if ((pm_state->req_state != 0) &&
+        (pm_state->cur_state > pm_state->req_state)) {
+        PT_ERR(d, "Invalid power transition. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, pm_state->cur_state);
+
+        return 0;
+    }
+
+    /* check if this device supports the requested power state */
+    if (((pm_state->req_state == 1) && !(pm_state->pmc_field & PCI_PM_CAP_D1))
+        || ((pm_state->req_state == 2) &&
+            !(pm_state->pmc_field & PCI_PM_CAP_D2))) {
+        PT_ERR(d, "Invalid power transition. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, pm_state->cur_state);
+
+        return 0;
+    }
+
+    /* in case of transition related to D3hot, it's necessary to wait 10 ms.
+     * But because writing to register will be performed later on actually,
+     * don't start QEMUTimer right now, just alloc and init QEMUTimer here.
+     */
+    if ((pm_state->cur_state == 3) || (pm_state->req_state == 3)) {
+        if (pm_state->req_state == 0) {
+            /* alloc and init QEMUTimer */
+            if (!pm_state->no_soft_reset) {
+                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                    pt_from_d3hot_to_d0_with_reset, s);
+
+                /* reset Interrupt and I/O resource mapping */
+                pt_reset_interrupt_and_io_mapping(s);
+            } else {
+                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                                        pt_default_power_transition, s);
+            }
+        } else {
+            /* alloc and init QEMUTimer */
+            pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                pt_default_power_transition, s);
+        }
+
+        /* set power state transition delay */
+        pm_state->pm_delay = 10;
+
+        /* power state transition flags on */
+        pm_state->flags |= PT_FLAG_TRANSITING;
+    }
+    /* in case of transition related to D0, D1 and D2,
+     * no need to use QEMUTimer.
+     * So, we perfom writing to register here and then read it back.
+     */
+    else {
+        /* write power state to I/O device register */
+        host_pci_set_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                          *value);
+
+        /* in case of transition related to D2,
+         * it's necessary to wait 200 usec.
+         * But because QEMUTimer do not support microsec unit right now,
+         * so we do wait ourself here.
+         */
+        if ((pm_state->cur_state == 2) || (pm_state->req_state == 2)) {
+            usleep(200);
+        }
+
+        /* check power state */
+        check_power_state(s);
+
+        /* recreate value for writing to I/O device register */
+        if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                              value)) {
+            return -1;
+        }
+    }
+
+    return 0;
+}
+
+/* restore Power Management Control/Status register */
+static int pt_pmcsr_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t real_offset, uint16_t dev_value,
+                                uint16_t *value)
+{
+    /* create value for restoring to I/O device register
+     * No need to restore, just clear PME Enable and PME Status bit
+     * Note: register type of PME Status bit is RW1C, so clear by writing 1b
+     */
+    *value = (dev_value & ~PCI_PM_CTRL_PME_ENABLE) | PCI_PM_CTRL_PME_STATUS;
+
+    return 0;
+}
+
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = pt_pmc_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = pt_pmcsr_reg_init,
+        .u.w.read   = pt_pmcsr_reg_read,
+        .u.w.write  = pt_pmcsr_reg_write,
+        .u.w.restore  = pt_pmcsr_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* AER register operations */
+
+static void aer_save_one_register(XenPCIPassthroughState *s, int offset)
+{
+    PCIDevice *d = &s->dev;
+    uint32_t aer_base = s->pm_state->aer_base;
+    uint32_t val = 0;
+
+    if (host_pci_get_long(s->real_device, aer_base + offset, &val)) {
+        return;
+    }
+    pci_set_long(d->config + aer_base + offset, val);
+}
+static void pt_aer_reg_save(XenPCIPassthroughState *s)
+{
+    /* after reset, following register values should be restored.
+     * So, save them.
+     */
+    aer_save_one_register(s, PCI_ERR_UNCOR_MASK);
+    aer_save_one_register(s, PCI_ERR_UNCOR_SEVER);
+    aer_save_one_register(s, PCI_ERR_COR_MASK);
+    aer_save_one_register(s, PCI_ERR_CAP);
+}
+static void aer_restore_one_register(XenPCIPassthroughState *s, int offset)
+{
+    PCIDevice *d = &s->dev;
+    uint32_t aer_base = s->pm_state->aer_base;
+    uint32_t config = 0;
+
+    config = pci_get_long(d->config + aer_base + offset);
+    host_pci_set_long(s->real_device, aer_base + offset, config);
+}
+static void pt_aer_reg_restore(XenPCIPassthroughState *s)
+{
+    /* the following registers should be reconfigured to correct values
+     * after reset. restore them.
+     * other registers should not be reconfigured after reset
+     * if there is no reason
+     */
+    aer_restore_one_register(s, PCI_ERR_UNCOR_MASK);
+    aer_restore_one_register(s, PCI_ERR_UNCOR_SEVER);
+    aer_restore_one_register(s, PCI_ERR_COR_MASK);
+    aer_restore_one_register(s, PCI_ERR_CAP);
+}
+
+/* capability structure register group size functions */
+
+static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Power Management Capability Structure register group size */
+static int pt_pm_size_init(XenPCIPassthroughState *s,
+                           const XenPTRegGroupInfo *grp_reg,
+                           uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+
+    if (!s->power_mgmt) {
+        return 0;
+    }
+
+    s->pm_state = g_new0(XenPTPM, 1);
+
+    /* set Power Management Capability base offset */
+    s->pm_state->pm_base = base_offset;
+
+    /* find AER register and set AER Capability base offset */
+    s->pm_state->aer_base = host_pci_find_ext_cap_offset(s->real_device,
+                                                         PCI_EXT_CAP_ID_ERR);
+
+    /* save AER register */
+    if (s->pm_state->aer_base) {
+        pt_aer_reg_save(s);
+    }
+
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int pt_vendor_size_init(XenPCIPassthroughState *s,
+                               const XenPTRegGroupInfo *grp_reg,
+                               uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int pt_pcie_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t exp_flag = 0;
+    uint16_t type = 0;
+    uint16_t version = 0;
+    uint8_t pcie_size = 0;
+
+    exp_flag = pci_get_word(d->config + base_offset + PCI_EXP_FLAGS);
+    type = (exp_flag & PCI_EXP_FLAGS_TYPE) >> 4;
+    version = exp_flag & PCI_EXP_FLAGS_VERS;
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
+                   type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
+                   type);
+            return -1;
+        }
+    } else {
+        PT_ERR(d, "Internal error: Unsupported capability version (%d).\n",
+               version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_header0_tbl,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = pt_pm_size_init,
+        .emu_reg_tbl = pt_emu_reg_pm_tbl,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_vendor_size_init,
+        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_pcie_size_init,
+        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int pt_ptr_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    /* uint32_t reg_field = (uint32_t)s->dev.config[real_offset]; */
+    uint32_t reg_field = pci_get_byte(s->dev.config + real_offset);
+    int i;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+            if (pt_emu_reg_grp_tbl[i].grp_id == s->dev.config[reg_field]) {
+                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+        /* next capability */
+        /* reg_field = (uint32_t)s->dev.config[reg_field + 1]; */
+        reg_field = pci_get_byte(s->dev.config + reg_field + 1);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+/* restore a part of I/O device register */
+static int pt_config_restore(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+    uint32_t read_val = 0;
+    uint32_t val = 0;
+    int rc = 0;
+
+    /* find emulate register group entry */
+    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
+        /* find emulate register entry */
+        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
+            reg = reg_entry->reg;
+
+            /* check whether restoring is needed */
+            if (!reg->u.b.restore) {
+                continue;
+            }
+
+            real_offset = reg_grp_entry->base_offset + reg->offset;
+
+            /* read I/O device register value */
+            rc = host_pci_get_block(s->real_device, real_offset,
+                                    (uint8_t *)&read_val, reg->size);
+
+            if (rc < 0) {
+                PT_ERR(&s->dev, "pci_read_block failed. "
+                       "return value: %d.\n", rc);
+                memset(&read_val, 0xff, reg->size);
+            }
+
+            val = 0;
+
+            /* restore based on register size */
+            switch (reg->size) {
+            case 1:
+                /* byte register */
+                rc = reg->u.b.restore(s, reg_entry, real_offset,
+                                      (uint8_t)read_val, (uint8_t *)&val);
+                break;
+            case 2:
+                /* word register */
+                rc = reg->u.w.restore(s, reg_entry, real_offset,
+                                      (uint16_t)read_val, (uint16_t *)&val);
+                break;
+            case 4:
+                /* double word register */
+                rc = reg->u.dw.restore(s, reg_entry, real_offset,
+                                       (uint32_t)read_val, (uint32_t *)&val);
+                break;
+            }
+
+            /* restoring error */
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid restoring."
+                                         " (%s, rc: %d)\n", __func__, rc);
+                return -1;
+            }
+
+            PT_LOG_CONFIG(&s->dev, real_offset, val, reg->size);
+
+            rc = host_pci_set_block(s->real_device, real_offset,
+                                    (uint8_t *)&val, reg->size);
+
+            if (rc < 0) {
+                PT_ERR(&s->dev, "pci_write_block failed. "
+                       "return value: %d.\n", rc);
+                return -1;
+            }
+        }
+    }
+
+    /* if AER supported, restore it */
+    if (s->pm_state->aer_base) {
+        pt_aer_reg_restore(s);
+    }
+    return 0;
+}
+/* reinitialize all emulate registers */
+static int pt_config_reinit(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    int rc = 0;
+
+    /* find emulate register group entry */
+    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
+        /* find emulate register entry */
+        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
+            reg = reg_entry->reg;
+            if (reg->init) {
+                /* initialize emulate register */
+                rc = reg->init(s, reg_entry->reg,
+                               reg_grp_entry->base_offset + reg->offset,
+                               &reg_entry->data);
+                if (rc < 0) {
+                    return rc;
+                }
+            }
+        }
+    }
+    return 0;
+}
+
+static int pt_init_pci_config(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    int rc = 0;
+
+    PT_LOG(d, "Reinitialize PCI configuration registers due to power state"
+           " transition with internal reset.\n");
+
+    /* restore a part of I/O device register */
+    rc = pt_config_restore(s);
+    if (rc < 0) {
+        return rc;
+    }
+
+    /* reinitialize all emulate register */
+    rc = pt_config_reinit(s);
+    if (rc < 0) {
+        return rc;
+    }
+
+    /* rebind machine_irq to device */
+    if (s->machine_irq != 0) {
+        uint8_t e_device = PCI_SLOT(s->dev.devfn);
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq, 0,
+                                       e_device, e_intx);
+        if (rc < 0) {
+            PT_ERR(d, "Rebinding of interrupt failed! rc=%d\n", rc);
+        }
+    }
+
+    return rc;
+}
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    int max_cap = 48;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (host_pci_get_byte(s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < 0x40) {
+            break;
+        }
+
+        pos &= ~3;
+        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int pt_config_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int pt_config_init(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    uint32_t reg_grp_offset = 0;
+    XenPTRegInfo *reg_tbl = NULL;
+    int i, j, rc;
+
+    QLIST_INIT(&s->reg_grp_tbl);
+
+    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
+        if (pt_emu_reg_grp_tbl[i].size_init) {
+            /* get register group size */
+            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
+                                                 reg_grp_offset,
+                                                 &reg_grp_entry->size);
+            if (rc < 0) {
+                pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
+                reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
+                /* initialize capability register */
+                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
+                    /* initialize capability register */
+                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
+                    if (rc < 0) {
+                        pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+        reg_grp_offset = 0;
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free Power Management info table */
+    if (s->pm_state) {
+        if (s->pm_state->pm_timer) {
+            qemu_del_timer(s->pm_state->pm_timer);
+            qemu_free_timer(s->pm_state->pm_timer);
+            s->pm_state->pm_timer = NULL;
+        }
+
+        g_free(s->pm_state);
+    }
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:55:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:55:38 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4JO-000287-KT
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Iz-0007kV-QX; Thu, 17 Nov 2011 07:55:13 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jj-0005il-L4
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:48 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1321543122!4598437!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19712 invoked from network); 17 Nov 2011 15:18:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:18:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170994250"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:42 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaT026286;	Thu, 17 Nov 2011 07:18:40 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:12 +0000
Message-ID: <1321543033-22090-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: [Xen-devel] [PATCH V4 09/10] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
---
 hw/apic-msidef.h |   28 ++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 29 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..3182f0b
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,28 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 8289eef..18c4a87 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -24,6 +24,7 @@
 #include "sysbus.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 /* APIC Local Vector Table */
 #define APIC_LVT_TIMER   0
@@ -65,16 +66,6 @@
 #define MAX_APICS 255
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 #define MSI_ADDR_SIZE                   0x100000
 
 typedef struct APICState APICState;
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:55:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:55:38 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4JO-000287-KT
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:55:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Iz-0007kV-QX; Thu, 17 Nov 2011 07:55:13 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3jj-0005il-L4
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:18:48 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1321543122!4598437!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19712 invoked from network); 17 Nov 2011 15:18:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:18:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="170994250"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:42 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaT026286;	Thu, 17 Nov 2011 07:18:40 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:12 +0000
Message-ID: <1321543033-22090-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: [Xen-devel] [PATCH V4 09/10] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
---
 hw/apic-msidef.h |   28 ++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 29 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..3182f0b
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,28 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 8289eef..18c4a87 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -24,6 +24,7 @@
 #include "sysbus.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 /* APIC Local Vector Table */
 #define APIC_LVT_TIMER   0
@@ -65,16 +66,6 @@
 #define MAX_APICS 255
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 #define MSI_ADDR_SIZE                   0x100000
 
 typedef struct APICState APICState;
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:56:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:56:58 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Kg-00028K-6o
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:56:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4KH-0008B0-Bi; Thu, 17 Nov 2011 07:56:33 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3k6-0005ng-AJ
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:19:11 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1321543144!1980210!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22990 invoked from network); 17 Nov 2011 15:19:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:19:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190250"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:44 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaU026286;	Thu, 17 Nov 2011 07:18:42 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:13 +0000
Message-ID: <1321543033-22090-11-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>
Subject: [Xen-devel] [PATCH V4 10/10] Introduce Xen PCI Passthrough,
	MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    1 +
 hw/apic-msidef.h                     |    2 +
 hw/xen_pci_passthrough.c             |   60 +++-
 hw/xen_pci_passthrough.h             |   55 +++
 hw/xen_pci_passthrough_config_init.c |  505 +++++++++++++++++++++++++-
 hw/xen_pci_passthrough_msi.c         |  678 ++++++++++++++++++++++++++++++++++
 6 files changed, 1294 insertions(+), 7 deletions(-)
 create mode 100644 hw/xen_pci_passthrough_msi.c

diff --git a/Makefile.target b/Makefile.target
index 33435a3..81cff70 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -223,6 +223,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
index 3182f0b..6e2eb71 100644
--- a/hw/apic-msidef.h
+++ b/hw/apic-msidef.h
@@ -22,6 +22,8 @@
 
 #define MSI_ADDR_DEST_MODE_SHIFT        2
 
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
 #define MSI_ADDR_DEST_ID_SHIFT          12
 #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
 
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index c816ed5..cd7e3c7 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -38,6 +38,39 @@
  *     Write '1'
  *       <ptdev->msi_trans_en is false>
  *         - Set real bit to '1'.
+ *
+ * MSI-INTx translation.
+ *   Initialize(xc_physdev_map_pirq_msi/pt_msi_setup)
+ *     Bind MSI-INTx(xc_domain_bind_pt_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *           <success>
+ *             - Set dev->msi->pirq to '-1'.
+ *           <fail>
+ *             - Do nothing.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       <ptdev->msi_trans_en is true>
+ *         - Set MSI Enable bit to '1'.
+ *
+ *     Write '1'
+ *       <ptdev->msi_trans_en is true>
+ *         - Set MSI Enable bit to '0'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(pt_msi_setup, pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -389,6 +422,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
     }
 
     if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        pt_add_msix_mapping(s, i);
         /* Remove old mapping */
         memory_region_del_subregion(r->address_space,
                                     r->memory);
@@ -417,6 +451,15 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
         if (ret != 0) {
             PT_ERR(&s->dev, "create new mapping failed!\n");
         }
+
+        ret = pt_remove_msix_mapping(s, i);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed!\n");
+        }
+
+        if (old_ebase != e_phys && old_ebase != -1) {
+            pt_msix_update_remap(s, i);
+        }
     }
 }
 
@@ -744,6 +787,9 @@ static int pt_initfn(PCIDevice *pcidev)
         mapped_machine_irq[machine_irq]++;
     }
 
+    /* setup MSI-INTx translation if support */
+    rc = pt_enable_msi_translate(s);
+
     /* bind machine_irq to device */
     if (rc < 0 && machine_irq != 0) {
         uint8_t e_device = PCI_SLOT(s->dev.devfn);
@@ -773,7 +819,8 @@ static int pt_initfn(PCIDevice *pcidev)
 
 out:
     PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
-           "\nIRQ type = %s\n", bus, slot, func, "INTx");
+           "\nIRQ type = %s\n", bus, slot, func,
+           s->msi_trans_en ? "MSI-INTx" : "INTx");
 
     return 0;
 }
@@ -790,7 +837,7 @@ static int pt_unregister_device(PCIDevice *pcidev)
     e_intx = pci_intx(s);
     machine_irq = s->machine_irq;
 
-    if (machine_irq) {
+    if (s->msi_trans_en == 0 && machine_irq) {
         rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
                                      PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);
         if (rc < 0) {
@@ -798,6 +845,13 @@ static int pt_unregister_device(PCIDevice *pcidev)
         }
     }
 
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         mapped_machine_irq[machine_irq]--;
 
@@ -832,6 +886,8 @@ static PCIDeviceInfo xen_pci_passthrough = {
     .is_express = 0,
     .qdev.props = (Property[]) {
         DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+        DEFINE_PROP_BIT("msitranslate", XenPCIPassthroughState, msi_trans_cap,
+                        0, true),
         DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
                         0, false),
         DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 110325c..acbbab5 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -74,6 +74,10 @@ typedef int (*conf_byte_restore)
 #define PT_PCI_BAR_UNMAPPED (-1)
 #define PT_UNASSIGNED_PIRQ (-1)
 
+/* MSI-X */
+#define PT_MSI_FLAG_UNINIT 0x1000
+#define PT_MSI_FLAG_MAPPED 0x2000
+
 
 typedef enum {
     GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
@@ -177,6 +181,34 @@ typedef struct XenPTRegGroup {
 } XenPTRegGroup;
 
 
+typedef struct XenPTMSI {
+    uint32_t flags;
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+} XenPTMSI;
+
+typedef struct XenMSIXEntry {
+    int pirq;        /* -1 means unmapped */
+    int flags;       /* flags indicting whether MSI ADDR or DATA is updated */
+    uint32_t io_mem[4];
+} XenMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    int enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_off;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    int mmio_index;
+    void *phys_iomem_base;
+    XenMSIXEntry msix_entry[0];
+} XenPTMSIX;
+
 typedef struct XenPTPM {
     QEMUTimer *pm_timer;  /* QEMUTimer struct */
     int no_soft_reset;    /* No Soft Reset flags */
@@ -200,6 +232,13 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
+    /* Physical MSI to guest INTx translation when possible */
+    uint32_t msi_trans_cap;
+    bool msi_trans_en;
+
     uint32_t power_mgmt;
     XenPTPM *pm_state;
 
@@ -279,4 +318,20 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+void pt_msi_set_enable(XenPCIPassthroughState *s, int en);
+int pt_msi_setup(XenPCIPassthroughState *s);
+int pt_msi_update(XenPCIPassthroughState *d);
+void pt_msi_disable(XenPCIPassthroughState *s);
+int pt_enable_msi_translate(XenPCIPassthroughState *s);
+void pt_disable_msi_translate(XenPCIPassthroughState *s);
+
+int pt_msix_init(XenPCIPassthroughState *s, int pos);
+void pt_msix_delete(XenPCIPassthroughState *s);
+int pt_msix_update(XenPCIPassthroughState *s);
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void pt_msix_disable(XenPCIPassthroughState *s);
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index ae64544..28523f1 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -398,11 +398,19 @@ static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
     throughable_mask = ~emu_mask & valid_mask;
 
     if (*value & PCI_COMMAND_INTX_DISABLE) {
-        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
-    } else {
-        if (s->machine_irq) {
+        if (s->msi_trans_en) {
+            pt_msi_set_enable(s, 0);
+        } else {
             throughable_mask |= PCI_COMMAND_INTX_DISABLE;
         }
+    } else {
+        if (s->msi_trans_en) {
+            pt_msi_set_enable(s, 1);
+        } else {
+            if (s->machine_irq) {
+                throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+            }
+        }
     }
 
     *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
@@ -1282,13 +1290,21 @@ static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
     e_device = PCI_SLOT(s->dev.devfn);
     e_intx = pci_intx(s);
 
-    if (s->machine_irq) {
+    if (s->msi_trans_en == 0 && s->machine_irq) {
         if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
                                     PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
             PT_ERR(d, "Unbinding of interrupt failed!\n");
         }
     }
 
+    /* disable MSI/MSI-X and MSI-INTx translation */
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     /* clear all virtual region address */
     for (i = 0; i < PCI_NUM_REGIONS; i++) {
         r = &d->io_regions[i];
@@ -1536,6 +1552,415 @@ static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
     },
 };
 
+/********************************
+ * MSI Capability
+ */
+
+/* Message Control register */
+static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        PT_LOG(&s->dev, "MSI already enabled, disable it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    s->msi->flags |= reg_field | PT_MSI_FLAG_UNINIT;
+    s->msi->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t val;
+
+    /* Currently no support for multi-vector */
+    if (*value & PCI_MSI_FLAGS_QSIZE) {
+        PT_WARN(&s->dev, "try to set more than 1 vector ctrl %x\n", *value);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->flags |= cfg_entry->data &
+        ~(PT_MSI_FLAG_UNINIT | PT_MSI_FLAG_MAPPED | PCI_MSI_FLAGS_ENABLE);
+
+    /* create value for writing to I/O device register */
+    val = *value;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (s->msi->flags & PT_MSI_FLAG_UNINIT) {
+            if (s->msi_trans_en) {
+                PT_LOG(&s->dev,
+                       "guest enabling MSI, disable MSI-INTx translation\n");
+                pt_disable_msi_translate(s);
+            } else {
+                /* Init physical one */
+                PT_LOG(&s->dev, "setup MSI\n");
+                if (pt_msi_setup(s)) {
+                    /* We do not broadcast the error to the framework code, so
+                     * that MSI errors are contained in MSI emulation code and
+                     * QEMU can go on running.
+                     * Guest MSI would be actually not working.
+                     */
+                    *value &= ~PCI_MSI_FLAGS_ENABLE;
+                    PT_WARN(&s->dev, "Can not map MSI.\n");
+                    return 0;
+                }
+            }
+            if (pt_msi_update(s)) {
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            s->msi->flags &= ~PT_MSI_FLAG_UNINIT;
+            s->msi->flags |= PT_MSI_FLAG_MAPPED;
+        }
+        s->msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        s->msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit when no MSI-INTx translation */
+    if (!s->msi_trans_en) {
+        *value &= ~PCI_MSI_FLAGS_ENABLE;
+        *value |= val & PCI_MSI_FLAGS_ENABLE;
+    }
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int pt_msgaddr64_reg_init(XenPCIPassthroughState *ptdev,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(ptdev->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int pt_msgdata_reg_init(XenPCIPassthroughState *ptdev,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    uint32_t flags = ptdev->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) ||
+        ((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {
+        *data = reg->init_val;
+    } else {
+        *data = PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        PT_ERR(&s->dev, "Write to the Upper Address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) &&
+        !((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {
+        /* exit I/O emulator */
+        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = pt_msgctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr32_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgaddr64_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr64_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        PT_LOG(d, "MSIX already enabled, disable it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                 XenPTReg *cfg_entry, uint16_t *value,
+                                 uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*value & PCI_MSIX_FLAGS_ENABLE)
+        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
+        if (s->msi_trans_en) {
+            PT_LOG(&s->dev,
+                   "guest enabling MSI-X, disable MSI-INTx translation\n");
+            pt_disable_msi_translate(s);
+        }
+        pt_msix_update(s);
+    }
+
+    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = pt_msixctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msixctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
 
 /****************************
  * Capabilities
@@ -1709,6 +2134,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int pt_msi_size_init(XenPCIPassthroughState *s,
+                            const XenPTRegGroupInfo *grp_reg,
+                            uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check 64 bit address capable & Per-vector masking capable */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int pt_msix_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = pt_msix_init(s, base_offset);
+
+    if (rc == -1) {
+        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
     /* Header Type0 reg group */
@@ -1749,6 +2217,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .grp_size   = 0x04,
         .size_init  = pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_msi_size_init,
+        .emu_reg_tbl = pt_emu_reg_msi_tbl,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1793,6 +2269,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .size_init   = pt_pcie_size_init,
         .emu_reg_tbl = pt_emu_reg_pcie_tbl,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = pt_msix_size_init,
+        .emu_reg_tbl = pt_emu_reg_msix_tbl,
+    },
     {
         .grp_size = 0,
     },
@@ -1965,8 +2449,11 @@ static int pt_init_pci_config(XenPCIPassthroughState *s)
         return rc;
     }
 
+    /* setup MSI-INTx translation if support */
+    rc = pt_enable_msi_translate(s);
+
     /* rebind machine_irq to device */
-    if (s->machine_irq != 0) {
+    if (rc < 0 && s->machine_irq != 0) {
         uint8_t e_device = PCI_SLOT(s->dev.devfn);
         uint8_t e_intx = pci_intx(s);
 
@@ -2117,6 +2604,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free Power Management info table */
     if (s->pm_state) {
         if (s->pm_state->pm_timer) {
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
new file mode 100644
index 0000000..73d3d9b
--- /dev/null
+++ b/hw/xen_pci_passthrough_msi.c
@@ -0,0 +1,678 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+#include "apic-msidef.h"
+
+
+#define AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define GFLAGS_SHIFT_DEST_ID        0
+#define GFLAGS_SHIFT_RH             8
+#define GFLAGS_SHIFT_DM             9
+#define GLFAGS_SHIFT_DELIV_MODE     12
+#define GLFAGS_SHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static uint32_t get_msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = (addr >> MSI_ADDR_DEST_ID_SHIFT) & 0xff;
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
+             (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
+             (trig_mode << GLFAGS_SHIFT_TRG_MODE);
+
+    return result;
+}
+
+
+/*
+ * MSI virtualization functions
+ */
+
+void pt_msi_set_enable(XenPCIPassthroughState *s, int en)
+{
+    uint16_t val = 0;
+    uint32_t address = 0;
+
+    PT_LOG(&s->dev, "enable: %i\n", en);
+
+    if (!s->msi) {
+        return;
+    }
+
+    address = s->msi->ctrl_offset;
+    if (!address) {
+        return;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    val &= ~PCI_MSI_FLAGS_ENABLE;
+    val |= en & PCI_MSI_FLAGS_ENABLE;
+    host_pci_set_word(s->real_device, address, val);
+}
+
+/* setup physical msi, but don't enable it */
+int pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = PT_UNASSIGNED_PIRQ;
+    uint8_t gvec = 0;
+    int rc = 0;
+
+    if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
+        PT_ERR(&s->dev, "Setup physical MSI when it's already initialized.\n");
+        return -1;
+    }
+
+    gvec = s->msi->data & 0xFF;
+    if (!gvec) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        pirq = (s->msi->addr_hi & 0xffffff00) |
+               ((s->msi->addr_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
+        if (!pirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            pirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
+        }
+    }
+
+    rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
+                                 PCI_DEVFN(s->real_device->dev,
+                                           s->real_device->func),
+                                 s->real_device->bus, 0, 0);
+    if (rc) {
+        PT_ERR(&s->dev, "Mapping of MSI failed. (rc: %d,"
+               " assigned device: %02x:%02x.%x)\n", rc,
+               s->real_device->dev, s->real_device->func, s->real_device->bus);
+        return -1;
+    }
+
+    if (pirq < 0) {
+        PT_ERR(&s->dev, "Invalid pirq number.\n");
+        return -1;
+    }
+
+    s->msi->pirq = pirq;
+    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int pt_msi_update(XenPCIPassthroughState *s)
+{
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    int rc = 0;
+
+    /* get vector, address, flags info, etc. */
+    gvec = s->msi->data & 0xFF;
+    addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
+    gflags = get_msi_gflags(s->msi->data, addr);
+
+    PT_LOG(&s->dev, "Update MSI with pirq %d gvec 0x%x gflags 0x%x\n",
+           s->msi->pirq, gvec, gflags);
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  s->msi->pirq, gflags, 0);
+    if (rc) {
+        PT_ERR(&s->dev, "Binding of MSI failed. (rc: %d)\n", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI pirq %d failed.\n",
+                   s->msi->pirq);
+        }
+        s->msi->pirq = PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+void pt_msi_disable(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    pt_msi_set_enable(s, 0);
+
+    e_device = PCI_SLOT(d->devfn);
+    e_intx = pci_intx(s);
+
+    if (s->msi_trans_en) {
+        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                                    PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                                    e_device, e_intx, 0)) {
+            PT_ERR(d, "Unbinding pt irq for MSI-INTx failed!\n");
+            goto out;
+        }
+    } else if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
+        /* get vector, address, flags info, etc. */
+        gvec = s->msi->data & 0xFF;
+        addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
+        gflags = get_msi_gflags(s->msi->data, addr);
+
+        PT_ERR(&s->dev, "Unbind MSI with pirq %x, gvec %x\n",
+               s->msi->pirq, gvec);
+
+        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
+                                     s->msi->pirq, gflags)) {
+            PT_ERR(&s->dev, "Unbinding of MSI failed. (pirq: %d)\n",
+                   s->msi->pirq);
+            goto out;
+        }
+    }
+
+    if (s->msi->pirq != PT_UNASSIGNED_PIRQ) {
+        PT_LOG(&s->dev, "Unmap msi with pirq %d\n", s->msi->pirq);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI failed. (pirq: %d)\n",
+                   s->msi->pirq);
+            goto out;
+        }
+    }
+
+out:
+    /* clear msi info */
+    s->msi->flags = 0;
+    s->msi->pirq = -1;
+    s->msi_trans_en = 0;
+}
+
+/*
+ * MSI-INTx translation virtualization functions
+ */
+
+int pt_enable_msi_translate(XenPCIPassthroughState *s)
+{
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    if (!(s->msi && s->msi_trans_cap)) {
+        return -1;
+    }
+
+    pt_msi_set_enable(s, 0);
+    s->msi_trans_en = 0;
+
+    if (pt_msi_setup(s)) {
+        PT_ERR(&s->dev, "MSI-INTx translation MSI setup failed, fallback\n");
+        return -1;
+    }
+
+    e_device = PCI_SLOT(s->dev.devfn);
+    /* fix virtual interrupt pin to INTA# */
+    e_intx = pci_intx(s);
+
+    if (xc_domain_bind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                              PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                              e_device, e_intx, 0)) {
+        PT_ERR(&s->dev, "MSI-INTx translation bind failed, fallback\n");
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI failed.\n");
+        }
+        s->msi->pirq = PT_UNASSIGNED_PIRQ;
+        return -1;
+    }
+
+    pt_msi_set_enable(s, 1);
+    s->msi_trans_en = 1;
+
+    return 0;
+}
+
+void pt_disable_msi_translate(XenPCIPassthroughState *s)
+{
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    /* MSI_ENABLE bit should be disabed until the new handler is set */
+    pt_msi_set_enable(s, 0);
+
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+
+    if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                                PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                                e_device, e_intx, 0)) {
+        PT_ERR(&s->dev, "Unbinding pt irq for MSI-INTx failed!\n");
+    }
+
+    if (s->machine_irq) {
+        if (xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq,
+                                      0, e_device, e_intx)) {
+            PT_ERR(&s->dev, "Rebinding of interrupt failed!\n");
+        }
+    }
+
+    s->msi_trans_en = 0;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static void msix_set_enable(XenPCIPassthroughState *s, int en)
+{
+    uint16_t val = 0;
+    uint32_t address = 0;
+
+    if (!s->msix) {
+        return;
+    }
+
+    address = s->msix->ctrl_offset;
+    if (!address) {
+        return;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    val &= ~PCI_MSIX_FLAGS_ENABLE;
+    if (en) {
+        val |= PCI_MSIX_FLAGS_ENABLE;
+    }
+    host_pci_set_word(s->real_device, address, val);
+}
+
+static void mask_physical_msix_entry(XenPCIPassthroughState *s,
+                                     int entry_nr, int mask)
+{
+    void *phys_off;
+
+    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;
+    *(uint32_t *)phys_off = mask;
+}
+
+static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenMSIXEntry *entry = &s->msix->msix_entry[entry_nr];
+    int pirq = entry->pirq;
+    int gvec = entry->io_mem[2] & 0xff;
+    uint64_t gaddr = *(uint64_t *)&entry->io_mem[0];
+    uint32_t gflags = get_msi_gflags(entry->io_mem[2], gaddr);
+    int rc;
+
+    if (!entry->flags) {
+        return 0;
+    }
+
+    if (!gvec) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        pirq = ((gaddr >> 32) & 0xffffff00) |
+               (((gaddr & 0xffffffff) >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
+        if (!pirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            pirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
+        }
+    }
+
+    /* Check if this entry is already mapped */
+    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
+                                     PCI_DEVFN(s->real_device->dev,
+                                               s->real_device->func),
+                                     s->real_device->bus, entry_nr,
+                                     s->msix->table_base);
+        if (rc) {
+            PT_ERR(&s->dev, "Mapping msix entry %x\n", entry_nr);
+            return rc;
+        }
+        entry->pirq = pirq;
+    }
+
+    PT_LOG(&s->dev, "Update msix entry 0x%x with pirq %d gvec 0x%x\n",
+            entry_nr, pirq, gvec);
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags,
+                                  s->msix->mmio_base_addr);
+    if (rc) {
+        PT_ERR(&s->dev, "Updating msix irq %d info for entry %d\n",
+               pirq, entry_nr);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI-X failed. (pirq: %d)\n",
+                   entry->pirq);
+        }
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        return rc;
+    }
+
+    entry->flags = 0;
+
+    return 0;
+}
+
+int pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void pt_msix_disable(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    int i = 0;
+    XenMSIXEntry *entry = NULL;
+
+    msix_set_enable(s, 0);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+
+        if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+            continue;
+        }
+
+        gvec = entry->io_mem[2] & 0xff;
+        addr = *(uint64_t *)&entry->io_mem[0];
+        gflags = get_msi_gflags(entry->io_mem[2], addr);
+
+        PT_LOG(d, "Unbind msix with pirq %d, gvec 0x%x\n",
+                entry->pirq, gvec);
+
+        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
+                                        entry->pirq, gflags)) {
+            PT_ERR(d, "Unbinding of MSI-X failed.\n");
+        } else {
+            PT_LOG(d, "Unmap msix with pirq %d\n", entry->pirq);
+
+            if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
+                PT_ERR(d, "Unmapping of MSI-X failed.\n");
+            }
+        }
+        /* clear msi-x info */
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        entry->flags = 0;
+    }
+}
+
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
+            }
+            entry->flags = 1;
+        }
+    }
+    pt_msix_update(s);
+
+    return 0;
+}
+
+static void pci_msix_invalid_write(void *opaque, target_phys_addr_t addr,
+                                   uint32_t val)
+{
+    XenPCIPassthroughState *s = opaque;
+    PT_ERR(&s->dev, "Invalid write to MSI-X table,"
+           " only dword access is allowed.\n");
+}
+
+static void pci_msix_writel(void *opaque, target_phys_addr_t addr,
+                            uint32_t val)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenMSIXEntry *entry;
+    int entry_nr, offset;
+    void *phys_off;
+    uint32_t vec_ctrl;
+
+    if (addr % 4) {
+        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
+                "addr 0x"TARGET_FMT_plx"\n", addr);
+        return;
+    }
+
+    entry_nr = addr / 16;
+    entry = &msix->msix_entry[entry_nr];
+    offset = (addr % 16) / 4;
+
+    /*
+     * If Xen intercepts the mask bit access, io_mem[3] may not be
+     * up-to-date. Read from hardware directly.
+     */
+    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;
+    vec_ctrl = *(uint32_t *)phys_off;
+
+    if (offset != 3 && msix->enabled && !(vec_ctrl & 0x1)) {
+        PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
+                "enabled.\n", entry_nr);
+        return;
+    }
+
+    if (offset != 3 && entry->io_mem[offset] != val) {
+        entry->flags = 1;
+    }
+    entry->io_mem[offset] = val;
+
+    if (offset == 3) {
+        if (msix->enabled && !(val & 0x1)) {
+            pt_msix_update_one(s, entry_nr);
+        }
+        mask_physical_msix_entry(s, entry_nr, entry->io_mem[3] & 0x1);
+    }
+}
+
+static CPUWriteMemoryFunc *pci_msix_write[] = {
+    pci_msix_invalid_write,
+    pci_msix_invalid_write,
+    pci_msix_writel
+};
+
+static uint32_t pci_msix_invalid_read(void *opaque, target_phys_addr_t addr)
+{
+    XenPCIPassthroughState *s = opaque;
+    PT_ERR(&s->dev, "Invalid read to MSI-X table,"
+           " only dword access is allowed.\n");
+    return 0;
+}
+
+static uint32_t pci_msix_readl(void *opaque, target_phys_addr_t addr)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    if (addr % 4) {
+        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
+                "addr 0x"TARGET_FMT_plx"\n", addr);
+        return 0;
+    }
+
+    entry_nr = addr / 16;
+    offset = (addr % 16) / 4;
+
+    return msix->msix_entry[entry_nr].io_mem[offset];
+}
+
+static CPUReadMemoryFunc *pci_msix_read[] = {
+    pci_msix_invalid_read,
+    pci_msix_invalid_read,
+    pci_msix_readl
+};
+
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+         DPCI_ADD_MAPPING);
+}
+
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    s->msix->mmio_base_addr = s->bases[bar_index].e_physbase
+        + s->msix->table_off;
+
+    cpu_register_physical_memory(s->msix->mmio_base_addr,
+                                 s->msix->total_entries * 16,
+                                 s->msix->mmio_index);
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+         DPCI_REMOVE_MAPPING);
+}
+
+int pt_msix_init(XenPCIPassthroughState *s, int base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    HostPCIDevice *d = s->real_device;
+    int fd;
+
+    if (host_pci_get_byte(d, base + PCI_CAP_LIST_ID, &id)) {
+        return -1;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        PT_ERR(&s->dev, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    host_pci_get_word(d, base + 2, &control);
+    total_entries = control & 0x7ff;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenMSIXEntry));
+
+    s->msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        s->msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
+    }
+
+    s->msix->mmio_index =
+        cpu_register_io_memory(pci_msix_read, pci_msix_write,
+                               s, DEVICE_NATIVE_ENDIAN);
+
+    host_pci_get_long(d, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = s->msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = s->msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    s->msix->table_base = s->real_device->io_regions[bar_index].base_addr;
+    PT_LOG(&s->dev, "get MSI-X table BAR base 0x%"PRIx64"\n",
+           s->msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        PT_ERR(&s->dev, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    PT_LOG(&s->dev, "table_off = %#x, total_entries = %d\n",
+           table_off, total_entries);
+    s->msix->table_offset_adjust = table_off & 0x0fff;
+    s->msix->phys_iomem_base =
+        mmap(0,
+             total_entries * 16 + s->msix->table_offset_adjust,
+             PROT_WRITE | PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             s->msix->table_base + table_off - s->msix->table_offset_adjust);
+
+    if (s->msix->phys_iomem_base == MAP_FAILED) {
+        PT_ERR(&s->dev, "Can't map physical MSI-X table: %s\n",
+               strerror(errno));
+        close(fd);
+        goto error_out;
+    }
+    s->msix->phys_iomem_base = (char *)s->msix->phys_iomem_base
+        + s->msix->table_offset_adjust;
+
+    close(fd);
+
+    PT_LOG(&s->dev, "mapping physical MSI-X table to %p\n",
+           s->msix->phys_iomem_base);
+    return 0;
+
+error_out:
+    g_free(s->msix);
+    s->msix = NULL;
+    return -1;
+}
+
+void pt_msix_delete(XenPCIPassthroughState *s)
+{
+    /* unmap the MSI-X memory mapped register area */
+    if (s->msix->phys_iomem_base) {
+        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+           s->msix->phys_iomem_base);
+        munmap(s->msix->phys_iomem_base, s->msix->total_entries * 16 +
+           s->msix->table_offset_adjust);
+    }
+
+    if (s->msix->mmio_index > 0) {
+        cpu_unregister_io_memory(s->msix->mmio_index);
+    }
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:56:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:56:58 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Kg-00028K-6o
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:56:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4KH-0008B0-Bi; Thu, 17 Nov 2011 07:56:33 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3k6-0005ng-AJ
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:19:11 -0800
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1321543144!1980210!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22990 invoked from network); 17 Nov 2011 15:19:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:19:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="19190250"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 10:18:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 10:18:44 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAHFHWaU026286;	Thu, 17 Nov 2011 07:18:42 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 17 Nov 2011 15:17:13 +0000
Message-ID: <1321543033-22090-11-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>
Subject: [Xen-devel] [PATCH V4 10/10] Introduce Xen PCI Passthrough,
	MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    1 +
 hw/apic-msidef.h                     |    2 +
 hw/xen_pci_passthrough.c             |   60 +++-
 hw/xen_pci_passthrough.h             |   55 +++
 hw/xen_pci_passthrough_config_init.c |  505 +++++++++++++++++++++++++-
 hw/xen_pci_passthrough_msi.c         |  678 ++++++++++++++++++++++++++++++++++
 6 files changed, 1294 insertions(+), 7 deletions(-)
 create mode 100644 hw/xen_pci_passthrough_msi.c

diff --git a/Makefile.target b/Makefile.target
index 33435a3..81cff70 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -223,6 +223,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
index 3182f0b..6e2eb71 100644
--- a/hw/apic-msidef.h
+++ b/hw/apic-msidef.h
@@ -22,6 +22,8 @@
 
 #define MSI_ADDR_DEST_MODE_SHIFT        2
 
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
 #define MSI_ADDR_DEST_ID_SHIFT          12
 #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
 
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index c816ed5..cd7e3c7 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -38,6 +38,39 @@
  *     Write '1'
  *       <ptdev->msi_trans_en is false>
  *         - Set real bit to '1'.
+ *
+ * MSI-INTx translation.
+ *   Initialize(xc_physdev_map_pirq_msi/pt_msi_setup)
+ *     Bind MSI-INTx(xc_domain_bind_pt_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *           <success>
+ *             - Set dev->msi->pirq to '-1'.
+ *           <fail>
+ *             - Do nothing.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       <ptdev->msi_trans_en is true>
+ *         - Set MSI Enable bit to '1'.
+ *
+ *     Write '1'
+ *       <ptdev->msi_trans_en is true>
+ *         - Set MSI Enable bit to '0'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(pt_msi_setup, pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -389,6 +422,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
     }
 
     if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        pt_add_msix_mapping(s, i);
         /* Remove old mapping */
         memory_region_del_subregion(r->address_space,
                                     r->memory);
@@ -417,6 +451,15 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
         if (ret != 0) {
             PT_ERR(&s->dev, "create new mapping failed!\n");
         }
+
+        ret = pt_remove_msix_mapping(s, i);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed!\n");
+        }
+
+        if (old_ebase != e_phys && old_ebase != -1) {
+            pt_msix_update_remap(s, i);
+        }
     }
 }
 
@@ -744,6 +787,9 @@ static int pt_initfn(PCIDevice *pcidev)
         mapped_machine_irq[machine_irq]++;
     }
 
+    /* setup MSI-INTx translation if support */
+    rc = pt_enable_msi_translate(s);
+
     /* bind machine_irq to device */
     if (rc < 0 && machine_irq != 0) {
         uint8_t e_device = PCI_SLOT(s->dev.devfn);
@@ -773,7 +819,8 @@ static int pt_initfn(PCIDevice *pcidev)
 
 out:
     PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
-           "\nIRQ type = %s\n", bus, slot, func, "INTx");
+           "\nIRQ type = %s\n", bus, slot, func,
+           s->msi_trans_en ? "MSI-INTx" : "INTx");
 
     return 0;
 }
@@ -790,7 +837,7 @@ static int pt_unregister_device(PCIDevice *pcidev)
     e_intx = pci_intx(s);
     machine_irq = s->machine_irq;
 
-    if (machine_irq) {
+    if (s->msi_trans_en == 0 && machine_irq) {
         rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
                                      PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);
         if (rc < 0) {
@@ -798,6 +845,13 @@ static int pt_unregister_device(PCIDevice *pcidev)
         }
     }
 
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         mapped_machine_irq[machine_irq]--;
 
@@ -832,6 +886,8 @@ static PCIDeviceInfo xen_pci_passthrough = {
     .is_express = 0,
     .qdev.props = (Property[]) {
         DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+        DEFINE_PROP_BIT("msitranslate", XenPCIPassthroughState, msi_trans_cap,
+                        0, true),
         DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
                         0, false),
         DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 110325c..acbbab5 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -74,6 +74,10 @@ typedef int (*conf_byte_restore)
 #define PT_PCI_BAR_UNMAPPED (-1)
 #define PT_UNASSIGNED_PIRQ (-1)
 
+/* MSI-X */
+#define PT_MSI_FLAG_UNINIT 0x1000
+#define PT_MSI_FLAG_MAPPED 0x2000
+
 
 typedef enum {
     GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
@@ -177,6 +181,34 @@ typedef struct XenPTRegGroup {
 } XenPTRegGroup;
 
 
+typedef struct XenPTMSI {
+    uint32_t flags;
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+} XenPTMSI;
+
+typedef struct XenMSIXEntry {
+    int pirq;        /* -1 means unmapped */
+    int flags;       /* flags indicting whether MSI ADDR or DATA is updated */
+    uint32_t io_mem[4];
+} XenMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    int enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_off;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    int mmio_index;
+    void *phys_iomem_base;
+    XenMSIXEntry msix_entry[0];
+} XenPTMSIX;
+
 typedef struct XenPTPM {
     QEMUTimer *pm_timer;  /* QEMUTimer struct */
     int no_soft_reset;    /* No Soft Reset flags */
@@ -200,6 +232,13 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
+    /* Physical MSI to guest INTx translation when possible */
+    uint32_t msi_trans_cap;
+    bool msi_trans_en;
+
     uint32_t power_mgmt;
     XenPTPM *pm_state;
 
@@ -279,4 +318,20 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+void pt_msi_set_enable(XenPCIPassthroughState *s, int en);
+int pt_msi_setup(XenPCIPassthroughState *s);
+int pt_msi_update(XenPCIPassthroughState *d);
+void pt_msi_disable(XenPCIPassthroughState *s);
+int pt_enable_msi_translate(XenPCIPassthroughState *s);
+void pt_disable_msi_translate(XenPCIPassthroughState *s);
+
+int pt_msix_init(XenPCIPassthroughState *s, int pos);
+void pt_msix_delete(XenPCIPassthroughState *s);
+int pt_msix_update(XenPCIPassthroughState *s);
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void pt_msix_disable(XenPCIPassthroughState *s);
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index ae64544..28523f1 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -398,11 +398,19 @@ static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
     throughable_mask = ~emu_mask & valid_mask;
 
     if (*value & PCI_COMMAND_INTX_DISABLE) {
-        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
-    } else {
-        if (s->machine_irq) {
+        if (s->msi_trans_en) {
+            pt_msi_set_enable(s, 0);
+        } else {
             throughable_mask |= PCI_COMMAND_INTX_DISABLE;
         }
+    } else {
+        if (s->msi_trans_en) {
+            pt_msi_set_enable(s, 1);
+        } else {
+            if (s->machine_irq) {
+                throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+            }
+        }
     }
 
     *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
@@ -1282,13 +1290,21 @@ static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
     e_device = PCI_SLOT(s->dev.devfn);
     e_intx = pci_intx(s);
 
-    if (s->machine_irq) {
+    if (s->msi_trans_en == 0 && s->machine_irq) {
         if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
                                     PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
             PT_ERR(d, "Unbinding of interrupt failed!\n");
         }
     }
 
+    /* disable MSI/MSI-X and MSI-INTx translation */
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     /* clear all virtual region address */
     for (i = 0; i < PCI_NUM_REGIONS; i++) {
         r = &d->io_regions[i];
@@ -1536,6 +1552,415 @@ static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
     },
 };
 
+/********************************
+ * MSI Capability
+ */
+
+/* Message Control register */
+static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        PT_LOG(&s->dev, "MSI already enabled, disable it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    s->msi->flags |= reg_field | PT_MSI_FLAG_UNINIT;
+    s->msi->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t val;
+
+    /* Currently no support for multi-vector */
+    if (*value & PCI_MSI_FLAGS_QSIZE) {
+        PT_WARN(&s->dev, "try to set more than 1 vector ctrl %x\n", *value);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->flags |= cfg_entry->data &
+        ~(PT_MSI_FLAG_UNINIT | PT_MSI_FLAG_MAPPED | PCI_MSI_FLAGS_ENABLE);
+
+    /* create value for writing to I/O device register */
+    val = *value;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (s->msi->flags & PT_MSI_FLAG_UNINIT) {
+            if (s->msi_trans_en) {
+                PT_LOG(&s->dev,
+                       "guest enabling MSI, disable MSI-INTx translation\n");
+                pt_disable_msi_translate(s);
+            } else {
+                /* Init physical one */
+                PT_LOG(&s->dev, "setup MSI\n");
+                if (pt_msi_setup(s)) {
+                    /* We do not broadcast the error to the framework code, so
+                     * that MSI errors are contained in MSI emulation code and
+                     * QEMU can go on running.
+                     * Guest MSI would be actually not working.
+                     */
+                    *value &= ~PCI_MSI_FLAGS_ENABLE;
+                    PT_WARN(&s->dev, "Can not map MSI.\n");
+                    return 0;
+                }
+            }
+            if (pt_msi_update(s)) {
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            s->msi->flags &= ~PT_MSI_FLAG_UNINIT;
+            s->msi->flags |= PT_MSI_FLAG_MAPPED;
+        }
+        s->msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        s->msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit when no MSI-INTx translation */
+    if (!s->msi_trans_en) {
+        *value &= ~PCI_MSI_FLAGS_ENABLE;
+        *value |= val & PCI_MSI_FLAGS_ENABLE;
+    }
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int pt_msgaddr64_reg_init(XenPCIPassthroughState *ptdev,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(ptdev->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int pt_msgdata_reg_init(XenPCIPassthroughState *ptdev,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    uint32_t flags = ptdev->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) ||
+        ((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {
+        *data = reg->init_val;
+    } else {
+        *data = PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        PT_ERR(&s->dev, "Write to the Upper Address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) &&
+        !((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {
+        /* exit I/O emulator */
+        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = pt_msgctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr32_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgaddr64_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr64_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        PT_LOG(d, "MSIX already enabled, disable it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                 XenPTReg *cfg_entry, uint16_t *value,
+                                 uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*value & PCI_MSIX_FLAGS_ENABLE)
+        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
+        if (s->msi_trans_en) {
+            PT_LOG(&s->dev,
+                   "guest enabling MSI-X, disable MSI-INTx translation\n");
+            pt_disable_msi_translate(s);
+        }
+        pt_msix_update(s);
+    }
+
+    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = pt_msixctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msixctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
 
 /****************************
  * Capabilities
@@ -1709,6 +2134,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int pt_msi_size_init(XenPCIPassthroughState *s,
+                            const XenPTRegGroupInfo *grp_reg,
+                            uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check 64 bit address capable & Per-vector masking capable */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int pt_msix_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = pt_msix_init(s, base_offset);
+
+    if (rc == -1) {
+        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
     /* Header Type0 reg group */
@@ -1749,6 +2217,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .grp_size   = 0x04,
         .size_init  = pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_msi_size_init,
+        .emu_reg_tbl = pt_emu_reg_msi_tbl,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1793,6 +2269,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .size_init   = pt_pcie_size_init,
         .emu_reg_tbl = pt_emu_reg_pcie_tbl,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = pt_msix_size_init,
+        .emu_reg_tbl = pt_emu_reg_msix_tbl,
+    },
     {
         .grp_size = 0,
     },
@@ -1965,8 +2449,11 @@ static int pt_init_pci_config(XenPCIPassthroughState *s)
         return rc;
     }
 
+    /* setup MSI-INTx translation if support */
+    rc = pt_enable_msi_translate(s);
+
     /* rebind machine_irq to device */
-    if (s->machine_irq != 0) {
+    if (rc < 0 && s->machine_irq != 0) {
         uint8_t e_device = PCI_SLOT(s->dev.devfn);
         uint8_t e_intx = pci_intx(s);
 
@@ -2117,6 +2604,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free Power Management info table */
     if (s->pm_state) {
         if (s->pm_state->pm_timer) {
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
new file mode 100644
index 0000000..73d3d9b
--- /dev/null
+++ b/hw/xen_pci_passthrough_msi.c
@@ -0,0 +1,678 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+#include "apic-msidef.h"
+
+
+#define AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define GFLAGS_SHIFT_DEST_ID        0
+#define GFLAGS_SHIFT_RH             8
+#define GFLAGS_SHIFT_DM             9
+#define GLFAGS_SHIFT_DELIV_MODE     12
+#define GLFAGS_SHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static uint32_t get_msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = (addr >> MSI_ADDR_DEST_ID_SHIFT) & 0xff;
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
+             (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
+             (trig_mode << GLFAGS_SHIFT_TRG_MODE);
+
+    return result;
+}
+
+
+/*
+ * MSI virtualization functions
+ */
+
+void pt_msi_set_enable(XenPCIPassthroughState *s, int en)
+{
+    uint16_t val = 0;
+    uint32_t address = 0;
+
+    PT_LOG(&s->dev, "enable: %i\n", en);
+
+    if (!s->msi) {
+        return;
+    }
+
+    address = s->msi->ctrl_offset;
+    if (!address) {
+        return;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    val &= ~PCI_MSI_FLAGS_ENABLE;
+    val |= en & PCI_MSI_FLAGS_ENABLE;
+    host_pci_set_word(s->real_device, address, val);
+}
+
+/* setup physical msi, but don't enable it */
+int pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = PT_UNASSIGNED_PIRQ;
+    uint8_t gvec = 0;
+    int rc = 0;
+
+    if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
+        PT_ERR(&s->dev, "Setup physical MSI when it's already initialized.\n");
+        return -1;
+    }
+
+    gvec = s->msi->data & 0xFF;
+    if (!gvec) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        pirq = (s->msi->addr_hi & 0xffffff00) |
+               ((s->msi->addr_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
+        if (!pirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            pirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
+        }
+    }
+
+    rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
+                                 PCI_DEVFN(s->real_device->dev,
+                                           s->real_device->func),
+                                 s->real_device->bus, 0, 0);
+    if (rc) {
+        PT_ERR(&s->dev, "Mapping of MSI failed. (rc: %d,"
+               " assigned device: %02x:%02x.%x)\n", rc,
+               s->real_device->dev, s->real_device->func, s->real_device->bus);
+        return -1;
+    }
+
+    if (pirq < 0) {
+        PT_ERR(&s->dev, "Invalid pirq number.\n");
+        return -1;
+    }
+
+    s->msi->pirq = pirq;
+    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int pt_msi_update(XenPCIPassthroughState *s)
+{
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    int rc = 0;
+
+    /* get vector, address, flags info, etc. */
+    gvec = s->msi->data & 0xFF;
+    addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
+    gflags = get_msi_gflags(s->msi->data, addr);
+
+    PT_LOG(&s->dev, "Update MSI with pirq %d gvec 0x%x gflags 0x%x\n",
+           s->msi->pirq, gvec, gflags);
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  s->msi->pirq, gflags, 0);
+    if (rc) {
+        PT_ERR(&s->dev, "Binding of MSI failed. (rc: %d)\n", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI pirq %d failed.\n",
+                   s->msi->pirq);
+        }
+        s->msi->pirq = PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+void pt_msi_disable(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    pt_msi_set_enable(s, 0);
+
+    e_device = PCI_SLOT(d->devfn);
+    e_intx = pci_intx(s);
+
+    if (s->msi_trans_en) {
+        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                                    PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                                    e_device, e_intx, 0)) {
+            PT_ERR(d, "Unbinding pt irq for MSI-INTx failed!\n");
+            goto out;
+        }
+    } else if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
+        /* get vector, address, flags info, etc. */
+        gvec = s->msi->data & 0xFF;
+        addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
+        gflags = get_msi_gflags(s->msi->data, addr);
+
+        PT_ERR(&s->dev, "Unbind MSI with pirq %x, gvec %x\n",
+               s->msi->pirq, gvec);
+
+        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
+                                     s->msi->pirq, gflags)) {
+            PT_ERR(&s->dev, "Unbinding of MSI failed. (pirq: %d)\n",
+                   s->msi->pirq);
+            goto out;
+        }
+    }
+
+    if (s->msi->pirq != PT_UNASSIGNED_PIRQ) {
+        PT_LOG(&s->dev, "Unmap msi with pirq %d\n", s->msi->pirq);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI failed. (pirq: %d)\n",
+                   s->msi->pirq);
+            goto out;
+        }
+    }
+
+out:
+    /* clear msi info */
+    s->msi->flags = 0;
+    s->msi->pirq = -1;
+    s->msi_trans_en = 0;
+}
+
+/*
+ * MSI-INTx translation virtualization functions
+ */
+
+int pt_enable_msi_translate(XenPCIPassthroughState *s)
+{
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    if (!(s->msi && s->msi_trans_cap)) {
+        return -1;
+    }
+
+    pt_msi_set_enable(s, 0);
+    s->msi_trans_en = 0;
+
+    if (pt_msi_setup(s)) {
+        PT_ERR(&s->dev, "MSI-INTx translation MSI setup failed, fallback\n");
+        return -1;
+    }
+
+    e_device = PCI_SLOT(s->dev.devfn);
+    /* fix virtual interrupt pin to INTA# */
+    e_intx = pci_intx(s);
+
+    if (xc_domain_bind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                              PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                              e_device, e_intx, 0)) {
+        PT_ERR(&s->dev, "MSI-INTx translation bind failed, fallback\n");
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI failed.\n");
+        }
+        s->msi->pirq = PT_UNASSIGNED_PIRQ;
+        return -1;
+    }
+
+    pt_msi_set_enable(s, 1);
+    s->msi_trans_en = 1;
+
+    return 0;
+}
+
+void pt_disable_msi_translate(XenPCIPassthroughState *s)
+{
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    /* MSI_ENABLE bit should be disabed until the new handler is set */
+    pt_msi_set_enable(s, 0);
+
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+
+    if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                                PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                                e_device, e_intx, 0)) {
+        PT_ERR(&s->dev, "Unbinding pt irq for MSI-INTx failed!\n");
+    }
+
+    if (s->machine_irq) {
+        if (xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq,
+                                      0, e_device, e_intx)) {
+            PT_ERR(&s->dev, "Rebinding of interrupt failed!\n");
+        }
+    }
+
+    s->msi_trans_en = 0;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static void msix_set_enable(XenPCIPassthroughState *s, int en)
+{
+    uint16_t val = 0;
+    uint32_t address = 0;
+
+    if (!s->msix) {
+        return;
+    }
+
+    address = s->msix->ctrl_offset;
+    if (!address) {
+        return;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    val &= ~PCI_MSIX_FLAGS_ENABLE;
+    if (en) {
+        val |= PCI_MSIX_FLAGS_ENABLE;
+    }
+    host_pci_set_word(s->real_device, address, val);
+}
+
+static void mask_physical_msix_entry(XenPCIPassthroughState *s,
+                                     int entry_nr, int mask)
+{
+    void *phys_off;
+
+    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;
+    *(uint32_t *)phys_off = mask;
+}
+
+static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenMSIXEntry *entry = &s->msix->msix_entry[entry_nr];
+    int pirq = entry->pirq;
+    int gvec = entry->io_mem[2] & 0xff;
+    uint64_t gaddr = *(uint64_t *)&entry->io_mem[0];
+    uint32_t gflags = get_msi_gflags(entry->io_mem[2], gaddr);
+    int rc;
+
+    if (!entry->flags) {
+        return 0;
+    }
+
+    if (!gvec) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        pirq = ((gaddr >> 32) & 0xffffff00) |
+               (((gaddr & 0xffffffff) >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
+        if (!pirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            pirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
+        }
+    }
+
+    /* Check if this entry is already mapped */
+    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
+                                     PCI_DEVFN(s->real_device->dev,
+                                               s->real_device->func),
+                                     s->real_device->bus, entry_nr,
+                                     s->msix->table_base);
+        if (rc) {
+            PT_ERR(&s->dev, "Mapping msix entry %x\n", entry_nr);
+            return rc;
+        }
+        entry->pirq = pirq;
+    }
+
+    PT_LOG(&s->dev, "Update msix entry 0x%x with pirq %d gvec 0x%x\n",
+            entry_nr, pirq, gvec);
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags,
+                                  s->msix->mmio_base_addr);
+    if (rc) {
+        PT_ERR(&s->dev, "Updating msix irq %d info for entry %d\n",
+               pirq, entry_nr);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI-X failed. (pirq: %d)\n",
+                   entry->pirq);
+        }
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        return rc;
+    }
+
+    entry->flags = 0;
+
+    return 0;
+}
+
+int pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void pt_msix_disable(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    int i = 0;
+    XenMSIXEntry *entry = NULL;
+
+    msix_set_enable(s, 0);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+
+        if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+            continue;
+        }
+
+        gvec = entry->io_mem[2] & 0xff;
+        addr = *(uint64_t *)&entry->io_mem[0];
+        gflags = get_msi_gflags(entry->io_mem[2], addr);
+
+        PT_LOG(d, "Unbind msix with pirq %d, gvec 0x%x\n",
+                entry->pirq, gvec);
+
+        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
+                                        entry->pirq, gflags)) {
+            PT_ERR(d, "Unbinding of MSI-X failed.\n");
+        } else {
+            PT_LOG(d, "Unmap msix with pirq %d\n", entry->pirq);
+
+            if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
+                PT_ERR(d, "Unmapping of MSI-X failed.\n");
+            }
+        }
+        /* clear msi-x info */
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        entry->flags = 0;
+    }
+}
+
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
+            }
+            entry->flags = 1;
+        }
+    }
+    pt_msix_update(s);
+
+    return 0;
+}
+
+static void pci_msix_invalid_write(void *opaque, target_phys_addr_t addr,
+                                   uint32_t val)
+{
+    XenPCIPassthroughState *s = opaque;
+    PT_ERR(&s->dev, "Invalid write to MSI-X table,"
+           " only dword access is allowed.\n");
+}
+
+static void pci_msix_writel(void *opaque, target_phys_addr_t addr,
+                            uint32_t val)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenMSIXEntry *entry;
+    int entry_nr, offset;
+    void *phys_off;
+    uint32_t vec_ctrl;
+
+    if (addr % 4) {
+        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
+                "addr 0x"TARGET_FMT_plx"\n", addr);
+        return;
+    }
+
+    entry_nr = addr / 16;
+    entry = &msix->msix_entry[entry_nr];
+    offset = (addr % 16) / 4;
+
+    /*
+     * If Xen intercepts the mask bit access, io_mem[3] may not be
+     * up-to-date. Read from hardware directly.
+     */
+    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;
+    vec_ctrl = *(uint32_t *)phys_off;
+
+    if (offset != 3 && msix->enabled && !(vec_ctrl & 0x1)) {
+        PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
+                "enabled.\n", entry_nr);
+        return;
+    }
+
+    if (offset != 3 && entry->io_mem[offset] != val) {
+        entry->flags = 1;
+    }
+    entry->io_mem[offset] = val;
+
+    if (offset == 3) {
+        if (msix->enabled && !(val & 0x1)) {
+            pt_msix_update_one(s, entry_nr);
+        }
+        mask_physical_msix_entry(s, entry_nr, entry->io_mem[3] & 0x1);
+    }
+}
+
+static CPUWriteMemoryFunc *pci_msix_write[] = {
+    pci_msix_invalid_write,
+    pci_msix_invalid_write,
+    pci_msix_writel
+};
+
+static uint32_t pci_msix_invalid_read(void *opaque, target_phys_addr_t addr)
+{
+    XenPCIPassthroughState *s = opaque;
+    PT_ERR(&s->dev, "Invalid read to MSI-X table,"
+           " only dword access is allowed.\n");
+    return 0;
+}
+
+static uint32_t pci_msix_readl(void *opaque, target_phys_addr_t addr)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    if (addr % 4) {
+        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
+                "addr 0x"TARGET_FMT_plx"\n", addr);
+        return 0;
+    }
+
+    entry_nr = addr / 16;
+    offset = (addr % 16) / 4;
+
+    return msix->msix_entry[entry_nr].io_mem[offset];
+}
+
+static CPUReadMemoryFunc *pci_msix_read[] = {
+    pci_msix_invalid_read,
+    pci_msix_invalid_read,
+    pci_msix_readl
+};
+
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+         DPCI_ADD_MAPPING);
+}
+
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    s->msix->mmio_base_addr = s->bases[bar_index].e_physbase
+        + s->msix->table_off;
+
+    cpu_register_physical_memory(s->msix->mmio_base_addr,
+                                 s->msix->total_entries * 16,
+                                 s->msix->mmio_index);
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+         DPCI_REMOVE_MAPPING);
+}
+
+int pt_msix_init(XenPCIPassthroughState *s, int base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    HostPCIDevice *d = s->real_device;
+    int fd;
+
+    if (host_pci_get_byte(d, base + PCI_CAP_LIST_ID, &id)) {
+        return -1;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        PT_ERR(&s->dev, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    host_pci_get_word(d, base + 2, &control);
+    total_entries = control & 0x7ff;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenMSIXEntry));
+
+    s->msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        s->msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
+    }
+
+    s->msix->mmio_index =
+        cpu_register_io_memory(pci_msix_read, pci_msix_write,
+                               s, DEVICE_NATIVE_ENDIAN);
+
+    host_pci_get_long(d, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = s->msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = s->msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    s->msix->table_base = s->real_device->io_regions[bar_index].base_addr;
+    PT_LOG(&s->dev, "get MSI-X table BAR base 0x%"PRIx64"\n",
+           s->msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        PT_ERR(&s->dev, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    PT_LOG(&s->dev, "table_off = %#x, total_entries = %d\n",
+           table_off, total_entries);
+    s->msix->table_offset_adjust = table_off & 0x0fff;
+    s->msix->phys_iomem_base =
+        mmap(0,
+             total_entries * 16 + s->msix->table_offset_adjust,
+             PROT_WRITE | PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             s->msix->table_base + table_off - s->msix->table_offset_adjust);
+
+    if (s->msix->phys_iomem_base == MAP_FAILED) {
+        PT_ERR(&s->dev, "Can't map physical MSI-X table: %s\n",
+               strerror(errno));
+        close(fd);
+        goto error_out;
+    }
+    s->msix->phys_iomem_base = (char *)s->msix->phys_iomem_base
+        + s->msix->table_offset_adjust;
+
+    close(fd);
+
+    PT_LOG(&s->dev, "mapping physical MSI-X table to %p\n",
+           s->msix->phys_iomem_base);
+    return 0;
+
+error_out:
+    g_free(s->msix);
+    s->msix = NULL;
+    return -1;
+}
+
+void pt_msix_delete(XenPCIPassthroughState *s)
+{
+    /* unmap the MSI-X memory mapped register area */
+    if (s->msix->phys_iomem_base) {
+        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+           s->msix->phys_iomem_base);
+        munmap(s->msix->phys_iomem_base, s->msix->total_entries * 16 +
+           s->msix->table_offset_adjust);
+    }
+
+    if (s->msix->mmio_index > 0) {
+        cpu_unregister_io_memory(s->msix->mmio_index);
+    }
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:59:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:59:16 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Mu-00028X-6w
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:59:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Ma-0000Ii-5m; Thu, 17 Nov 2011 07:58:56 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3m2-00067l-CW
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:21:12 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1321543266!3559950!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28691 invoked from network); 17 Nov 2011 15:21:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:21:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315180800"; 
   d="scan'208";a="8991965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 15:20:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 15:20:39 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 17 Nov 2011 15:20:38 +0000
In-Reply-To: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321543238.3664.278.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, netdev@vger.kernel.org,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> It was pointed out to me recently that the xen-netfront driver can't safely
> support shared skbs on transmit, since, while it doesn't maintain skb state
> directly, it does pass a pointer to the skb to the hypervisor via a list, and
> the hypervisor may expect the contents of the skb to remain stable.  Clearing
> the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.

What are the actual constraints here? The skb is used as a handle to the
skb->data and shinfo (frags) and to complete at the end. It's actually
those which are passed to the hypervisor (effectively the same as
passing those addresses to the h/w for DMA).

Which parts of the skb are expected/allowed to not remain stable?

(Appologies if the above seems naive, I seem to have missed the
introduction of shared tx skbs and IFF_TX_SKB_SHARING)

Ian.

> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: xen-devel@lists.xensource.com
> ---
>  drivers/net/xen-netfront.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 226faab..fb1077b 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1252,6 +1252,12 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
>  		return ERR_PTR(-ENOMEM);
>  	}
>  
> +	/*
> +	 * Since frames remain on a queue after a return from xennet_start_xmit,
> +	 * we can't support tx shared skbs
> +	 */
> +	netdev->priv_flags &= ~IFF_TX_SKB_SHARING;
> +
>  	np                   = netdev_priv(netdev);
>  	np->xbdev            = dev;
>  



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 15:59:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 15:59:16 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Mu-00028X-6w
	for archives@lists.xen.org; Thu, 17 Nov 2011 15:59:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Ma-0000Ii-5m; Thu, 17 Nov 2011 07:58:56 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR3m2-00067l-CW
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 07:21:12 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1321543266!3559950!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28691 invoked from network); 17 Nov 2011 15:21:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 15:21:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315180800"; 
   d="scan'208";a="8991965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 15:20:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 15:20:39 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 17 Nov 2011 15:20:38 +0000
In-Reply-To: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321543238.3664.278.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, netdev@vger.kernel.org,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> It was pointed out to me recently that the xen-netfront driver can't safely
> support shared skbs on transmit, since, while it doesn't maintain skb state
> directly, it does pass a pointer to the skb to the hypervisor via a list, and
> the hypervisor may expect the contents of the skb to remain stable.  Clearing
> the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.

What are the actual constraints here? The skb is used as a handle to the
skb->data and shinfo (frags) and to complete at the end. It's actually
those which are passed to the hypervisor (effectively the same as
passing those addresses to the h/w for DMA).

Which parts of the skb are expected/allowed to not remain stable?

(Appologies if the above seems naive, I seem to have missed the
introduction of shared tx skbs and IFF_TX_SKB_SHARING)

Ian.

> 
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CC: xen-devel@lists.xensource.com
> ---
>  drivers/net/xen-netfront.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 226faab..fb1077b 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1252,6 +1252,12 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
>  		return ERR_PTR(-ENOMEM);
>  	}
>  
> +	/*
> +	 * Since frames remain on a queue after a return from xennet_start_xmit,
> +	 * we can't support tx shared skbs
> +	 */
> +	netdev->priv_flags &= ~IFF_TX_SKB_SHARING;
> +
>  	np                   = netdev_priv(netdev);
>  	np->xbdev            = dev;
>  



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:05:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:05:20 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Sm-00028k-CP
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:05:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4SN-0000si-4j; Thu, 17 Nov 2011 08:04:56 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4Qc-0000nZ-6c
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:03:07 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1321545767!55450929!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6697 invoked from network); 17 Nov 2011 16:02:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 16:02:49 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHG2twM022362
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 16:02:56 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHG2pqu019671
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 16:02:51 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHG2kl3003610; Thu, 17 Nov 2011 10:02:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 08:02:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 44D3F81489; Thu, 17 Nov 2011 11:02:44 -0500 (EST)
Date: Thu, 17 Nov 2011 11:02:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Wang2 <wei.wang2@amd.com>, keir@xen.org
Subject: Re: [Xen-devel] Backport per-device vector map patches to xen 4.1.3
Message-ID: <20111117160244.GA6667@phenom.dumpdata.com>
References: <201110271607.52785.wei.wang2@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201110271607.52785.wei.wang2@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4EC53030.00AE,ss=1,re=-2.300,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Dunlap <George.Dunlap@eu.citrix.com>,
	"Huang2, Wei" <Wei.Huang2@amd.com>, "Shin,
	Jacob" <Jacob.Shin@amd.com>, George@acsinet12.oracle.com,
	Jan Beulich <JBeulich@suse.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Oct 27, 2011 at 04:07:51PM +0200, Wei Wang2 wrote:
> Recently we found an issue in xen 4.1. Under heavy I/O stress such as running 
> bonnie++, Dom0 would lost its hard disk with lots of I/O errors. We found 
> that some PCI-E devices was using the same vector as SMBus on AMD platforms 
> and George' patch set that enables per-device vector map can fix this 
> problem.
> 
> Following patches have been back ported and tested by Jacob and Wei H.  
> Please apply them to Xen 4.1.3 

Can they be applied please? I've been running these without hiccups for well,
since they were posted. On both AMD and Intel boxes.

So, Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> Thanks,
> Wei
> 
> 23752 xen: Infrastructure to allow irqs to share vector maps
> 23753 xen: Option to allow per-device vector maps for MSI IRQs
> 23754 xen: AMD IOMMU: Automatically enable per-device vector maps
> 23786 x86: Fix up irq vector map logic
> 23812 xen: Add global irq_vector_map option
> 23899 AMD-IOMMU: remove dead variable references

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1311701852 -3600
> # Node ID fa4e2ca9ecffbc432b451f495ad0a403644a6be8
> # Parent  2e0cf9428554da666616982cd0074024ff85b221
> xen: AMD IOMMU: Automatically enable per-device vector maps
> 
> Automatically enable per-device vector maps when using IOMMU,
> unless disabled specifically by an IOMMU parameter.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r e017a9a2f27c xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Tue Jul 26 18:37:16 2011 +0100
> +++ b/xen/arch/x86/irq.c	Fri Oct 21 15:15:13 2011 -0400
> @@ -32,6 +32,7 @@
>  unsigned int __read_mostly nr_irqs;
>  integer_param("nr_irqs", nr_irqs);
>  
> +/* This default may be changed by the AMD IOMMU code */
>  bool_t __read_mostly opt_irq_perdev_vector_map = 0;
>  boolean_param("irq-perdev-vector-map", opt_irq_perdev_vector_map);
>  
> diff -r e017a9a2f27c xen/drivers/passthrough/amd/pci_amd_iommu.c
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Tue Jul 26 18:37:16 2011 +0100
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Fri Oct 21 15:15:13 2011 -0400
> @@ -24,6 +24,9 @@
>  #include <asm/hvm/iommu.h>
>  #include <asm/amd-iommu.h>
>  #include <asm/hvm/svm/amd-iommu-proto.h>
> +
> +extern bool_t __read_mostly opt_irq_perdev_vector_map;
> +extern bool_t __read_mostly iommu_amd_perdev_vector_map;
>  
>  extern unsigned short ivrs_bdf_entries;
>  extern struct ivrs_mappings *ivrs_mappings;
> @@ -164,6 +167,18 @@
>      {
>          printk("AMD-Vi: Error initialization\n");
>          return -ENODEV;
> +    }
> +
> +    /* Enable use of per-device vector map unless otherwise
> +     * specified */
> +    if ( iommu_amd_perdev_vector_map )
> +    {
> +        printk("AMD-Vi: Enabling per-device vector maps\n");
> +        opt_irq_perdev_vector_map=1;
> +    }
> +    else
> +    {
> +        printk("AMD-Vi: WARNING - not enabling per-device vector maps\n");
>      }
>  
>      return scan_pci_devices();
> diff -r e017a9a2f27c xen/drivers/passthrough/iommu.c
> --- a/xen/drivers/passthrough/iommu.c	Tue Jul 26 18:37:16 2011 +0100
> +++ b/xen/drivers/passthrough/iommu.c	Fri Oct 21 15:15:13 2011 -0400
> @@ -49,6 +49,7 @@
>  bool_t __read_mostly iommu_intremap = 1;
>  bool_t __read_mostly iommu_hap_pt_share;
>  bool_t __read_mostly amd_iommu_debug;
> +bool_t __read_mostly iommu_amd_perdev_vector_map = 1;
>  bool_t __read_mostly amd_iommu_perdev_intremap;
>  
>  static void __init parse_iommu_param(char *s)
> @@ -84,6 +85,8 @@
>              iommu_dom0_strict = 1;
>          else if ( !strcmp(s, "sharept") )
>              iommu_hap_pt_share = 1;
> +        else if ( !strcmp(s, "no-perdev-vector-map") )
> +            iommu_amd_perdev_vector_map = 0;
>  
>          s = ss + 1;
>      } while ( ss );

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1311701836 -3600
> # Node ID 2e0cf9428554da666616982cd0074024ff85b221
> # Parent  ef9ed3d2aa870a37ed5e611be9c524d526a2d604
> xen: Option to allow per-device vector maps for MSI IRQs
> 
> Add a vector-map to pci_dev, and add an option to point MSI-related
> IRQs to the vector-map of the device.
> 
> This prevents irqs from the same device from being assigned
> the same vector on different pcpus.  This is required for systems
> using an AMD IOMMU, since the intremap tables on AMD only look at
> vector, and not destination ID.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r 84b8504a6125 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Tue Jul 26 18:36:58 2011 +0100
> +++ b/xen/arch/x86/irq.c	Fri Oct 21 15:12:46 2011 -0400
> @@ -31,6 +31,9 @@
>  unsigned int __read_mostly nr_irqs_gsi = 16;
>  unsigned int __read_mostly nr_irqs;
>  integer_param("nr_irqs", nr_irqs);
> +
> +bool_t __read_mostly opt_irq_perdev_vector_map = 0;
> +boolean_param("irq-perdev-vector-map", opt_irq_perdev_vector_map);
>  
>  u8 __read_mostly *irq_vector;
>  struct irq_desc __read_mostly *irq_desc = NULL;
> @@ -1560,6 +1563,9 @@
>              dprintk(XENLOG_G_ERR, "dom%d: irq %d in use\n",
>                d->domain_id, irq);
>          desc->handler = &pci_msi_type;
> +        if ( opt_irq_perdev_vector_map
> +             && !desc->chip_data->used_vectors )
> +            desc->chip_data->used_vectors = &pdev->info.used_vectors;
>          d->arch.pirq_irq[pirq] = irq;
>          d->arch.irq_pirq[irq] = pirq;
>          setup_msi_irq(pdev, msi_desc, irq);
> diff -r 84b8504a6125 xen/include/xen/pci.h
> --- a/xen/include/xen/pci.h	Tue Jul 26 18:36:58 2011 +0100
> +++ b/xen/include/xen/pci.h	Fri Oct 21 15:12:46 2011 -0400
> @@ -11,6 +11,7 @@
>  #include <xen/types.h>
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
> +#include <xen/irq.h>
>  
>  /*
>   * The PCI interface treats multi-function devices as independent
> @@ -38,6 +39,7 @@
>          u8 bus;
>          u8 devfn;
>      } physfn;
> +   vmask_t used_vectors; 
>  };
>  
>  struct pci_dev {

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1311701818 -3600
> # Node ID ef9ed3d2aa870a37ed5e611be9c524d526a2d604
> # Parent  590aadf7c46ae979da3552332f592f9492ce6d8b
> xen: Infrastructure to allow irqs to share vector maps
> 
> Laying the groundwork for per-device vector maps.  This generic
> code allows any irq to point to a vector map; all irqs sharing the
> same vector map will avoid sharing vectors.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r 590aadf7c46a -r ef9ed3d2aa87 xen/arch/x86/io_apic.c
> --- a/xen/arch/x86/io_apic.c	Tue Jul 26 17:00:25 2011 +0100
> +++ b/xen/arch/x86/io_apic.c	Tue Jul 26 18:36:58 2011 +0100
> @@ -449,6 +449,11 @@
>                   irq, vector, smp_processor_id());
>  
>          __get_cpu_var(vector_irq)[vector] = -1;
> +        if ( cfg->used_vectors )
> +        {
> +            ASSERT(test_bit(vector, cfg->used_vectors));
> +            clear_bit(vector, cfg->used_vectors);
> +        }
>          cfg->move_cleanup_count--;
>  unlock:
>          spin_unlock(&desc->lock);
> diff -r 590aadf7c46a -r ef9ed3d2aa87 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Tue Jul 26 17:00:25 2011 +0100
> +++ b/xen/arch/x86/irq.c	Tue Jul 26 18:36:58 2011 +0100
> @@ -108,6 +108,8 @@
>          per_cpu(vector_irq, cpu)[vector] = irq;
>      cfg->vector = vector;
>      cfg->cpu_mask = online_mask;
> +    if ( cfg->used_vectors )
> +        set_bit(vector, cfg->used_vectors);
>      irq_status[irq] = IRQ_USED;
>      if (IO_APIC_IRQ(irq))
>          irq_vector[irq] = vector;
> @@ -172,6 +174,7 @@
>      desc->depth   = 1;
>      desc->msi_desc = NULL;
>      desc->handler = &no_irq_type;
> +    desc->chip_data->used_vectors=NULL;
>      cpus_setall(desc->affinity);
>      spin_unlock_irqrestore(&desc->lock, flags);
>  
> @@ -199,6 +202,9 @@
>  
>      for_each_cpu_mask(cpu, tmp_mask)
>          per_cpu(vector_irq, cpu)[vector] = -1;
> +
> +    if ( cfg->used_vectors )
> +        clear_bit(vector, cfg->used_vectors);
>  
>      cfg->vector = IRQ_VECTOR_UNASSIGNED;
>      cpus_clear(cfg->cpu_mask);
> @@ -277,6 +283,7 @@
>      cfg->vector = IRQ_VECTOR_UNASSIGNED;
>      cpus_clear(cfg->cpu_mask);
>      cpus_clear(cfg->old_cpu_mask);
> +    cfg->used_vectors = NULL;
>  }
>  
>  int __init init_irq_data(void)
> @@ -402,6 +409,10 @@
>          if (test_bit(vector, used_vectors))
>              goto next;
>  
> +        if (cfg->used_vectors
> +            && test_bit(vector, cfg->used_vectors) )
> +            goto next;
> +
>          for_each_cpu_mask(new_cpu, tmp_mask)
>              if (per_cpu(vector_irq, new_cpu)[vector] != -1)
>                  goto next;
> @@ -417,6 +428,11 @@
>              per_cpu(vector_irq, new_cpu)[vector] = irq;
>          cfg->vector = vector;
>          cpus_copy(cfg->cpu_mask, tmp_mask);
> +        if ( cfg->used_vectors )
> +        {
> +            ASSERT(!test_bit(vector, cfg->used_vectors));
> +            set_bit(vector, cfg->used_vectors);
> +        }
>  
>          irq_status[irq] = IRQ_USED;
>              if (IO_APIC_IRQ(irq))
> diff -r 590aadf7c46a -r ef9ed3d2aa87 xen/include/asm-x86/irq.h
> --- a/xen/include/asm-x86/irq.h	Tue Jul 26 17:00:25 2011 +0100
> +++ b/xen/include/asm-x86/irq.h	Tue Jul 26 18:36:58 2011 +0100
> @@ -24,11 +24,16 @@
>  #define irq_to_desc(irq)    (&irq_desc[irq])
>  #define irq_cfg(irq)        (&irq_cfg[irq])
>  
> +typedef struct {
> +    DECLARE_BITMAP(_bits,NR_VECTORS);
> +} vmask_t;
> +
>  struct irq_cfg {
>          int  vector;
>          cpumask_t cpu_mask;
>          cpumask_t old_cpu_mask;
>          unsigned move_cleanup_count;
> +        vmask_t *used_vectors;
>          u8 move_in_progress : 1;
>  };
>  

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1314026133 -3600
> # Node ID 3a05da2dc7c0a5fc0fcfc40c535d1fcb71203625
> # Parent  d1cd78a73a79e0e648937322cdb8d92a7f86327a
> x86: Fix up irq vector map logic
> 
> We need to make sure that cfg->used_vector is only cleared once;
> otherwise there may be a race condition that allows the same vector to
> be assigned twice, defeating the whole purpose of the map.
> 
> This makes two changes:
> * __clear_irq_vector() only clears the vector if the irq is not being
> moved
> * smp_iqr_move_cleanup_interrupt() only clears used_vector if this
> is the last place it's being used (move_cleanup_count==0 after
> decrement).
> 
> Also make use of asserts more consistent, to catch this kind of logic
> bug in the future.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r d1cd78a73a79 -r 3a05da2dc7c0 xen/arch/x86/io_apic.c
> --- a/xen/arch/x86/io_apic.c	Mon Aug 22 16:15:19 2011 +0100
> +++ b/xen/arch/x86/io_apic.c	Mon Aug 22 16:15:33 2011 +0100
> @@ -485,12 +485,14 @@
>                   irq, vector, smp_processor_id());
>  
>          __get_cpu_var(vector_irq)[vector] = -1;
> -        if ( cfg->used_vectors )
> +        cfg->move_cleanup_count--;
> +
> +        if ( cfg->move_cleanup_count == 0 
> +             &&  cfg->used_vectors )
>          {
>              ASSERT(test_bit(vector, cfg->used_vectors));
>              clear_bit(vector, cfg->used_vectors);
>          }
> -        cfg->move_cleanup_count--;
>  unlock:
>          spin_unlock(&desc->lock);
>      }
> diff -r d1cd78a73a79 -r 3a05da2dc7c0 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Mon Aug 22 16:15:19 2011 +0100
> +++ b/xen/arch/x86/irq.c	Mon Aug 22 16:15:33 2011 +0100
> @@ -113,7 +113,10 @@
>      cfg->vector = vector;
>      cfg->cpu_mask = online_mask;
>      if ( cfg->used_vectors )
> +    {
> +        ASSERT(!test_bit(vector, cfg->used_vectors));
>          set_bit(vector, cfg->used_vectors);
> +    }
>      irq_status[irq] = IRQ_USED;
>      if (IO_APIC_IRQ(irq))
>          irq_vector[irq] = vector;
> @@ -207,15 +210,13 @@
>      for_each_cpu_mask(cpu, tmp_mask)
>          per_cpu(vector_irq, cpu)[vector] = -1;
>  
> -    if ( cfg->used_vectors )
> -        clear_bit(vector, cfg->used_vectors);
> -
>      cfg->vector = IRQ_VECTOR_UNASSIGNED;
>      cpus_clear(cfg->cpu_mask);
>      init_one_irq_status(irq);
>  
>      if (likely(!cfg->move_in_progress))
>          return;
> +
>      cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map);
>      for_each_cpu_mask(cpu, tmp_mask) {
>          for (vector = FIRST_DYNAMIC_VECTOR; vector <= LAST_DYNAMIC_VECTOR;
> @@ -228,6 +229,12 @@
>               break;
>          }
>       }
> +
> +    if ( cfg->used_vectors )
> +    {
> +        ASSERT(test_bit(vector, cfg->used_vectors));
> +        clear_bit(vector, cfg->used_vectors);
> +    }
>  
>      cfg->move_in_progress = 0;
>  }

> # HG changeset patch
> # User Jan Beulich <jbeulich@suse.com>
> # Date 1317730316 -7200
> # Node ID a99d75671a911f9c0d5d11e0fe88a0a65863cb44
> # Parent  3d1664cc9e458809e399320204aca8536e401ee1
> AMD-IOMMU: remove dead variable references
> 
> These got orphaned up by recent changes.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Acked-by: Keir Fraser <keir@xen.org>
> 
> diff -r 599cf097900b xen/drivers/passthrough/amd/pci_amd_iommu.c
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Mon Sep 05 15:00:15 2011 +0100
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Fri Oct 21 15:39:30 2011 -0400
> @@ -24,9 +24,6 @@
>  #include <asm/hvm/iommu.h>
>  #include <asm/amd-iommu.h>
>  #include <asm/hvm/svm/amd-iommu-proto.h>
> -
> -extern bool_t __read_mostly opt_irq_perdev_vector_map;
> -extern bool_t __read_mostly iommu_amd_perdev_vector_map;
>  
>  extern unsigned short ivrs_bdf_entries;
>  extern struct ivrs_mappings *ivrs_mappings;
> diff -r 599cf097900b xen/drivers/passthrough/iommu.c
> --- a/xen/drivers/passthrough/iommu.c	Mon Sep 05 15:00:15 2011 +0100
> +++ b/xen/drivers/passthrough/iommu.c	Fri Oct 21 15:39:30 2011 -0400
> @@ -49,7 +49,6 @@
>  bool_t __read_mostly iommu_intremap = 1;
>  bool_t __read_mostly iommu_hap_pt_share;
>  bool_t __read_mostly amd_iommu_debug;
> -bool_t __read_mostly iommu_amd_perdev_vector_map = 1;
>  bool_t __read_mostly amd_iommu_perdev_intremap;
>  
>  static void __init parse_iommu_param(char *s)
> @@ -85,8 +84,6 @@
>              iommu_dom0_strict = 1;
>          else if ( !strcmp(s, "sharept") )
>              iommu_hap_pt_share = 1;
> -        else if ( !strcmp(s, "no-perdev-vector-map") )
> -            iommu_amd_perdev_vector_map = 0;
>  
>          s = ss + 1;
>      } while ( ss );

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1315231215 -3600
> # Node ID 32814ad7458dc842a7c588eee13e5c4ee11709a3
> # Parent  f1349a968a5ac5577d67ad4a3f3490c580dbe264
> xen: Add global irq_vector_map option, set if using AMD global intremap tables
> 
> As mentioned in previous changesets, AMD IOMMU interrupt
> remapping tables only look at the vector, not the destination
> id of an interrupt.  This means that all IRQs going through
> the same interrupt remapping table need to *not* share vectors.
> 
> The irq "vector map" functionality was originally introduced
> after a patch which disabled global AMD IOMMUs entirely.  That
> patch has since been reverted, meaning that AMD intremap tables
> can either be per-device or global.
> 
> This patch therefore introduces a global irq vector map option,
> and enables it if we're using an AMD IOMMU with a global
> interrupt remapping table.
> 
> This patch removes the "irq-perdev-vector-map" boolean
> command-line optino and replaces it with "irq_vector_map",
> which can have one of three values: none, global, or per-device.
> 
> Setting the irq_vector_map to any value will override the
> default that the AMD code sets.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r 6fc00d52c179 docs/src/user.tex
> --- a/docs/src/user.tex	Mon Aug 22 16:15:33 2011 +0100
> +++ b/docs/src/user.tex	Fri Oct 21 15:21:23 2011 -0400
> @@ -4197,6 +4197,10 @@
>  \item [ vcpu\_migration\_delay=$<$minimum\_time$>$] Set minimum time of 
>    vcpu migration in microseconds (default 0). This parameter avoids agressive
>    vcpu migration. For example, the linux kernel uses 0.5ms by default.
> +\item [ irq_vector_map=xxx ] Enable irq vector non-sharing maps.  Setting 'global' 
> +  will ensure that no  IRQs will share vectors.  Setting 'per-device' will ensure 
> +  that no IRQs from the same device will share vectors.  Setting to 'none' will
> +  disable it entirely, overriding any defaults the IOMMU code may set.
>  \end{description}
>  
>  In addition, the following options may be specified on the Xen command
> diff -r 6fc00d52c179 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Mon Aug 22 16:15:33 2011 +0100
> +++ b/xen/arch/x86/irq.c	Fri Oct 21 15:21:23 2011 -0400
> @@ -24,6 +24,8 @@
>  #include <asm/mach-generic/mach_apic.h>
>  #include <public/physdev.h>
>  
> +static void parse_irq_vector_map_param(char *s);
> +
>  /* opt_noirqbalance: If true, software IRQ balancing/affinity is disabled. */
>  bool_t __read_mostly opt_noirqbalance = 0;
>  boolean_param("noirqbalance", opt_noirqbalance);
> @@ -33,8 +35,10 @@
>  integer_param("nr_irqs", nr_irqs);
>  
>  /* This default may be changed by the AMD IOMMU code */
> -bool_t __read_mostly opt_irq_perdev_vector_map = 0;
> -boolean_param("irq-perdev-vector-map", opt_irq_perdev_vector_map);
> +int __read_mostly opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_DEFAULT;
> +custom_param("irq_vector_map", parse_irq_vector_map_param);
> +
> +vmask_t global_used_vector_map;
>  
>  u8 __read_mostly *irq_vector;
>  struct irq_desc __read_mostly *irq_desc = NULL;
> @@ -63,6 +67,26 @@
>  /* irq_ratelimit: the max irq rate allowed in every 10ms, set 0 to disable */
>  static unsigned int __read_mostly irq_ratelimit_threshold = 10000;
>  integer_param("irq_ratelimit", irq_ratelimit_threshold);
> +
> +static void __init parse_irq_vector_map_param(char *s)
> +{
> +    char *ss;
> +
> +    do {
> +        ss = strchr(s, ',');
> +        if ( ss )
> +            *ss = '\0';
> +
> +        if ( !strcmp(s, "none"))
> +            opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_NONE;
> +        else if ( !strcmp(s, "global"))
> +            opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_GLOBAL;
> +        else if ( !strcmp(s, "per-device"))
> +            opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_PERDEV;
> +
> +        s = ss + 1;
> +    } while ( ss );
> +}
>  
>  /* Must be called when irq disabled */
>  void lock_vector_lock(void)
> @@ -348,6 +372,41 @@
>      end_none
>  };
>  
> +static vmask_t *irq_get_used_vector_mask(int irq)
> +{
> +    vmask_t *ret = NULL;
> +
> +    if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_GLOBAL )
> +    {
> +        struct irq_desc *desc = irq_to_desc(irq);
> +
> +        ret = &global_used_vector_map;
> +
> +        if ( desc->chip_data->used_vectors )
> +        {
> +            printk(XENLOG_INFO "%s: Strange, unassigned irq %d already has used_vectors!\n",
> +                   __func__, irq);
> +        }
> +        else
> +        {
> +            int vector;
> +            
> +            vector = irq_to_vector(irq);
> +            if ( vector > 0 )
> +            {
> +                printk(XENLOG_INFO "%s: Strange, irq %d already assigned vector %d!\n",
> +                       __func__, irq, vector);
> +                
> +                ASSERT(!test_bit(vector, ret));
> +
> +                set_bit(vector, ret);
> +            }
> +        }
> +    }
> +
> +    return ret;
> +}
> +
>  int __assign_irq_vector(int irq, struct irq_cfg *cfg, const cpumask_t *mask)
>  {
>      /*
> @@ -366,6 +425,7 @@
>      int cpu, err;
>      unsigned long flags;
>      cpumask_t tmp_mask;
> +    vmask_t *irq_used_vectors = NULL;
>  
>      old_vector = irq_to_vector(irq);
>      if (old_vector) {
> @@ -380,6 +440,17 @@
>          return -EAGAIN;
>  
>      err = -ENOSPC;
> +
> +    /* This is the only place normal IRQs are ever marked
> +     * as "in use".  If they're not in use yet, check to see
> +     * if we need to assign a global vector mask. */
> +    if ( irq_status[irq] == IRQ_USED )
> +    {
> +        irq_used_vectors = cfg->used_vectors;
> +    }
> +    else
> +        irq_used_vectors = irq_get_used_vector_mask(irq);
> +
>      for_each_cpu_mask(cpu, *mask) {
>          int new_cpu;
>          int vector, offset;
> @@ -405,8 +476,8 @@
>          if (test_bit(vector, used_vectors))
>              goto next;
>  
> -        if (cfg->used_vectors
> -            && test_bit(vector, cfg->used_vectors) )
> +        if (irq_used_vectors
> +            && test_bit(vector, irq_used_vectors) )
>              goto next;
>  
>          for_each_cpu_mask(new_cpu, tmp_mask)
> @@ -424,15 +495,22 @@
>              per_cpu(vector_irq, new_cpu)[vector] = irq;
>          cfg->vector = vector;
>          cpus_copy(cfg->cpu_mask, tmp_mask);
> +
> +        irq_status[irq] = IRQ_USED;
> +        ASSERT((cfg->used_vectors == NULL)
> +               || (cfg->used_vectors == irq_used_vectors));
> +        cfg->used_vectors = irq_used_vectors;
> +
> +        if (IO_APIC_IRQ(irq))
> +            irq_vector[irq] = vector;
> +
>          if ( cfg->used_vectors )
>          {
>              ASSERT(!test_bit(vector, cfg->used_vectors));
> +
>              set_bit(vector, cfg->used_vectors);
>          }
>  
> -        irq_status[irq] = IRQ_USED;
> -            if (IO_APIC_IRQ(irq))
> -                    irq_vector[irq] = vector;
>          err = 0;
>          local_irq_restore(flags);
>          break;
> @@ -1521,7 +1599,7 @@
>  
>      if ( !IS_PRIV(current->domain) &&
>           !(IS_PRIV_FOR(current->domain, d) &&
> -          irq_access_permitted(current->domain, pirq)))
> +           irq_access_permitted(current->domain, pirq)))
>          return -EPERM;
>  
>      if ( pirq < 0 || pirq >= d->nr_pirqs || irq < 0 || irq >= nr_irqs )
> @@ -1569,11 +1647,21 @@
>  
>          if ( desc->handler != &no_irq_type )
>              dprintk(XENLOG_G_ERR, "dom%d: irq %d in use\n",
> -              d->domain_id, irq);
> +                    d->domain_id, irq);
>          desc->handler = &pci_msi_type;
> -        if ( opt_irq_perdev_vector_map
> +        if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_PERDEV
>               && !desc->chip_data->used_vectors )
> +        {
>              desc->chip_data->used_vectors = &pdev->info.used_vectors;
> +            if ( desc->chip_data->vector != IRQ_VECTOR_UNASSIGNED )
> +            {
> +                int vector = desc->chip_data->vector;
> +                ASSERT(!test_bit(vector, desc->chip_data->used_vectors));
> +
> +                set_bit(vector, desc->chip_data->used_vectors);
> +            }
> +        }
> +
>          d->arch.pirq_irq[pirq] = irq;
>          d->arch.irq_pirq[irq] = pirq;
>          setup_msi_irq(pdev, msi_desc, irq);
> @@ -1584,9 +1672,12 @@
>          d->arch.pirq_irq[pirq] = irq;
>          d->arch.irq_pirq[irq] = pirq;
>          spin_unlock_irqrestore(&desc->lock, flags);
> +
> +        if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_PERDEV )
> +            printk(XENLOG_INFO "Per-device vector maps for GSIs not implemented yet.\n");
>      }
>  
> - done:
> +done:
>      return ret;
>  }
>  
> diff -r 6fc00d52c179 xen/drivers/passthrough/amd/pci_amd_iommu.c
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Mon Aug 22 16:15:33 2011 +0100
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Fri Oct 21 15:21:23 2011 -0400
> @@ -169,18 +169,35 @@
>          return -ENODEV;
>      }
>  
> -    /* Enable use of per-device vector map unless otherwise
> -     * specified */
> -    if ( iommu_amd_perdev_vector_map )
> +    /*
> +     * AMD IOMMUs don't distinguish between vectors destined for
> +     * different cpus when doing interrupt remapping.  This means
> +     * that interrupts going through the same intremap table
> +     * can't share the same vector.
> +     *
> +     * If irq_vector_map isn't specified, choose a sensible default:
> +     * - If we're using per-device interemap tables, per-device
> +     *   vector non-sharing maps
> +     * - If we're using a global interemap table, global vector
> +     *   non-sharing map
> +     */
> +    if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_DEFAULT )
>      {
> -        printk("AMD-Vi: Enabling per-device vector maps\n");
> -        opt_irq_perdev_vector_map=1;
> +        if ( amd_iommu_perdev_intremap )
> +        {
> +            printk("AMD-Vi: Enabling per-device vector maps\n");
> +            opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_PERDEV;
> +        }
> +        else
> +        {
> +            printk("AMD-Vi: Enabling global vector map\n");
> +            opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_GLOBAL;
> +        }
>      }
>      else
>      {
> -        printk("AMD-Vi: WARNING - not enabling per-device vector maps\n");
> +        printk("AMD-Vi: Not overriding irq_vector_map setting\n");
>      }
> -
>      return scan_pci_devices();
>  }
>  
> diff -r 6fc00d52c179 xen/include/asm-x86/irq.h
> --- a/xen/include/asm-x86/irq.h	Mon Aug 22 16:15:33 2011 +0100
> +++ b/xen/include/asm-x86/irq.h	Fri Oct 21 15:21:23 2011 -0400
> @@ -44,6 +44,13 @@
>  extern u8 *irq_vector;
>  
>  extern bool_t opt_noirqbalance;
> +
> +#define OPT_IRQ_VECTOR_MAP_DEFAULT 0 /* Do the default thing  */
> +#define OPT_IRQ_VECTOR_MAP_NONE    1 /* None */ 
> +#define OPT_IRQ_VECTOR_MAP_GLOBAL  2 /* One global vector map (no vector sharing) */ 
> +#define OPT_IRQ_VECTOR_MAP_PERDEV  3 /* Per-device vetor map (no vector sharing w/in a device) */
> +
> +extern int opt_irq_vector_map;
>  
>  /*
>   * Per-cpu current frame pointer - the location of the last exception frame on

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


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:05:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:05:20 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Sm-00028k-CP
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:05:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4SN-0000si-4j; Thu, 17 Nov 2011 08:04:56 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4Qc-0000nZ-6c
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:03:07 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1321545767!55450929!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6697 invoked from network); 17 Nov 2011 16:02:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 16:02:49 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHG2twM022362
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 16:02:56 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHG2pqu019671
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 16:02:51 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHG2kl3003610; Thu, 17 Nov 2011 10:02:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 08:02:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 44D3F81489; Thu, 17 Nov 2011 11:02:44 -0500 (EST)
Date: Thu, 17 Nov 2011 11:02:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Wang2 <wei.wang2@amd.com>, keir@xen.org
Subject: Re: [Xen-devel] Backport per-device vector map patches to xen 4.1.3
Message-ID: <20111117160244.GA6667@phenom.dumpdata.com>
References: <201110271607.52785.wei.wang2@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201110271607.52785.wei.wang2@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4EC53030.00AE,ss=1,re=-2.300,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Dunlap <George.Dunlap@eu.citrix.com>,
	"Huang2, Wei" <Wei.Huang2@amd.com>, "Shin,
	Jacob" <Jacob.Shin@amd.com>, George@acsinet12.oracle.com,
	Jan Beulich <JBeulich@suse.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Oct 27, 2011 at 04:07:51PM +0200, Wei Wang2 wrote:
> Recently we found an issue in xen 4.1. Under heavy I/O stress such as running 
> bonnie++, Dom0 would lost its hard disk with lots of I/O errors. We found 
> that some PCI-E devices was using the same vector as SMBus on AMD platforms 
> and George' patch set that enables per-device vector map can fix this 
> problem.
> 
> Following patches have been back ported and tested by Jacob and Wei H.  
> Please apply them to Xen 4.1.3 

Can they be applied please? I've been running these without hiccups for well,
since they were posted. On both AMD and Intel boxes.

So, Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> Thanks,
> Wei
> 
> 23752 xen: Infrastructure to allow irqs to share vector maps
> 23753 xen: Option to allow per-device vector maps for MSI IRQs
> 23754 xen: AMD IOMMU: Automatically enable per-device vector maps
> 23786 x86: Fix up irq vector map logic
> 23812 xen: Add global irq_vector_map option
> 23899 AMD-IOMMU: remove dead variable references

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1311701852 -3600
> # Node ID fa4e2ca9ecffbc432b451f495ad0a403644a6be8
> # Parent  2e0cf9428554da666616982cd0074024ff85b221
> xen: AMD IOMMU: Automatically enable per-device vector maps
> 
> Automatically enable per-device vector maps when using IOMMU,
> unless disabled specifically by an IOMMU parameter.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r e017a9a2f27c xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Tue Jul 26 18:37:16 2011 +0100
> +++ b/xen/arch/x86/irq.c	Fri Oct 21 15:15:13 2011 -0400
> @@ -32,6 +32,7 @@
>  unsigned int __read_mostly nr_irqs;
>  integer_param("nr_irqs", nr_irqs);
>  
> +/* This default may be changed by the AMD IOMMU code */
>  bool_t __read_mostly opt_irq_perdev_vector_map = 0;
>  boolean_param("irq-perdev-vector-map", opt_irq_perdev_vector_map);
>  
> diff -r e017a9a2f27c xen/drivers/passthrough/amd/pci_amd_iommu.c
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Tue Jul 26 18:37:16 2011 +0100
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Fri Oct 21 15:15:13 2011 -0400
> @@ -24,6 +24,9 @@
>  #include <asm/hvm/iommu.h>
>  #include <asm/amd-iommu.h>
>  #include <asm/hvm/svm/amd-iommu-proto.h>
> +
> +extern bool_t __read_mostly opt_irq_perdev_vector_map;
> +extern bool_t __read_mostly iommu_amd_perdev_vector_map;
>  
>  extern unsigned short ivrs_bdf_entries;
>  extern struct ivrs_mappings *ivrs_mappings;
> @@ -164,6 +167,18 @@
>      {
>          printk("AMD-Vi: Error initialization\n");
>          return -ENODEV;
> +    }
> +
> +    /* Enable use of per-device vector map unless otherwise
> +     * specified */
> +    if ( iommu_amd_perdev_vector_map )
> +    {
> +        printk("AMD-Vi: Enabling per-device vector maps\n");
> +        opt_irq_perdev_vector_map=1;
> +    }
> +    else
> +    {
> +        printk("AMD-Vi: WARNING - not enabling per-device vector maps\n");
>      }
>  
>      return scan_pci_devices();
> diff -r e017a9a2f27c xen/drivers/passthrough/iommu.c
> --- a/xen/drivers/passthrough/iommu.c	Tue Jul 26 18:37:16 2011 +0100
> +++ b/xen/drivers/passthrough/iommu.c	Fri Oct 21 15:15:13 2011 -0400
> @@ -49,6 +49,7 @@
>  bool_t __read_mostly iommu_intremap = 1;
>  bool_t __read_mostly iommu_hap_pt_share;
>  bool_t __read_mostly amd_iommu_debug;
> +bool_t __read_mostly iommu_amd_perdev_vector_map = 1;
>  bool_t __read_mostly amd_iommu_perdev_intremap;
>  
>  static void __init parse_iommu_param(char *s)
> @@ -84,6 +85,8 @@
>              iommu_dom0_strict = 1;
>          else if ( !strcmp(s, "sharept") )
>              iommu_hap_pt_share = 1;
> +        else if ( !strcmp(s, "no-perdev-vector-map") )
> +            iommu_amd_perdev_vector_map = 0;
>  
>          s = ss + 1;
>      } while ( ss );

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1311701836 -3600
> # Node ID 2e0cf9428554da666616982cd0074024ff85b221
> # Parent  ef9ed3d2aa870a37ed5e611be9c524d526a2d604
> xen: Option to allow per-device vector maps for MSI IRQs
> 
> Add a vector-map to pci_dev, and add an option to point MSI-related
> IRQs to the vector-map of the device.
> 
> This prevents irqs from the same device from being assigned
> the same vector on different pcpus.  This is required for systems
> using an AMD IOMMU, since the intremap tables on AMD only look at
> vector, and not destination ID.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r 84b8504a6125 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Tue Jul 26 18:36:58 2011 +0100
> +++ b/xen/arch/x86/irq.c	Fri Oct 21 15:12:46 2011 -0400
> @@ -31,6 +31,9 @@
>  unsigned int __read_mostly nr_irqs_gsi = 16;
>  unsigned int __read_mostly nr_irqs;
>  integer_param("nr_irqs", nr_irqs);
> +
> +bool_t __read_mostly opt_irq_perdev_vector_map = 0;
> +boolean_param("irq-perdev-vector-map", opt_irq_perdev_vector_map);
>  
>  u8 __read_mostly *irq_vector;
>  struct irq_desc __read_mostly *irq_desc = NULL;
> @@ -1560,6 +1563,9 @@
>              dprintk(XENLOG_G_ERR, "dom%d: irq %d in use\n",
>                d->domain_id, irq);
>          desc->handler = &pci_msi_type;
> +        if ( opt_irq_perdev_vector_map
> +             && !desc->chip_data->used_vectors )
> +            desc->chip_data->used_vectors = &pdev->info.used_vectors;
>          d->arch.pirq_irq[pirq] = irq;
>          d->arch.irq_pirq[irq] = pirq;
>          setup_msi_irq(pdev, msi_desc, irq);
> diff -r 84b8504a6125 xen/include/xen/pci.h
> --- a/xen/include/xen/pci.h	Tue Jul 26 18:36:58 2011 +0100
> +++ b/xen/include/xen/pci.h	Fri Oct 21 15:12:46 2011 -0400
> @@ -11,6 +11,7 @@
>  #include <xen/types.h>
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
> +#include <xen/irq.h>
>  
>  /*
>   * The PCI interface treats multi-function devices as independent
> @@ -38,6 +39,7 @@
>          u8 bus;
>          u8 devfn;
>      } physfn;
> +   vmask_t used_vectors; 
>  };
>  
>  struct pci_dev {

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1311701818 -3600
> # Node ID ef9ed3d2aa870a37ed5e611be9c524d526a2d604
> # Parent  590aadf7c46ae979da3552332f592f9492ce6d8b
> xen: Infrastructure to allow irqs to share vector maps
> 
> Laying the groundwork for per-device vector maps.  This generic
> code allows any irq to point to a vector map; all irqs sharing the
> same vector map will avoid sharing vectors.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r 590aadf7c46a -r ef9ed3d2aa87 xen/arch/x86/io_apic.c
> --- a/xen/arch/x86/io_apic.c	Tue Jul 26 17:00:25 2011 +0100
> +++ b/xen/arch/x86/io_apic.c	Tue Jul 26 18:36:58 2011 +0100
> @@ -449,6 +449,11 @@
>                   irq, vector, smp_processor_id());
>  
>          __get_cpu_var(vector_irq)[vector] = -1;
> +        if ( cfg->used_vectors )
> +        {
> +            ASSERT(test_bit(vector, cfg->used_vectors));
> +            clear_bit(vector, cfg->used_vectors);
> +        }
>          cfg->move_cleanup_count--;
>  unlock:
>          spin_unlock(&desc->lock);
> diff -r 590aadf7c46a -r ef9ed3d2aa87 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Tue Jul 26 17:00:25 2011 +0100
> +++ b/xen/arch/x86/irq.c	Tue Jul 26 18:36:58 2011 +0100
> @@ -108,6 +108,8 @@
>          per_cpu(vector_irq, cpu)[vector] = irq;
>      cfg->vector = vector;
>      cfg->cpu_mask = online_mask;
> +    if ( cfg->used_vectors )
> +        set_bit(vector, cfg->used_vectors);
>      irq_status[irq] = IRQ_USED;
>      if (IO_APIC_IRQ(irq))
>          irq_vector[irq] = vector;
> @@ -172,6 +174,7 @@
>      desc->depth   = 1;
>      desc->msi_desc = NULL;
>      desc->handler = &no_irq_type;
> +    desc->chip_data->used_vectors=NULL;
>      cpus_setall(desc->affinity);
>      spin_unlock_irqrestore(&desc->lock, flags);
>  
> @@ -199,6 +202,9 @@
>  
>      for_each_cpu_mask(cpu, tmp_mask)
>          per_cpu(vector_irq, cpu)[vector] = -1;
> +
> +    if ( cfg->used_vectors )
> +        clear_bit(vector, cfg->used_vectors);
>  
>      cfg->vector = IRQ_VECTOR_UNASSIGNED;
>      cpus_clear(cfg->cpu_mask);
> @@ -277,6 +283,7 @@
>      cfg->vector = IRQ_VECTOR_UNASSIGNED;
>      cpus_clear(cfg->cpu_mask);
>      cpus_clear(cfg->old_cpu_mask);
> +    cfg->used_vectors = NULL;
>  }
>  
>  int __init init_irq_data(void)
> @@ -402,6 +409,10 @@
>          if (test_bit(vector, used_vectors))
>              goto next;
>  
> +        if (cfg->used_vectors
> +            && test_bit(vector, cfg->used_vectors) )
> +            goto next;
> +
>          for_each_cpu_mask(new_cpu, tmp_mask)
>              if (per_cpu(vector_irq, new_cpu)[vector] != -1)
>                  goto next;
> @@ -417,6 +428,11 @@
>              per_cpu(vector_irq, new_cpu)[vector] = irq;
>          cfg->vector = vector;
>          cpus_copy(cfg->cpu_mask, tmp_mask);
> +        if ( cfg->used_vectors )
> +        {
> +            ASSERT(!test_bit(vector, cfg->used_vectors));
> +            set_bit(vector, cfg->used_vectors);
> +        }
>  
>          irq_status[irq] = IRQ_USED;
>              if (IO_APIC_IRQ(irq))
> diff -r 590aadf7c46a -r ef9ed3d2aa87 xen/include/asm-x86/irq.h
> --- a/xen/include/asm-x86/irq.h	Tue Jul 26 17:00:25 2011 +0100
> +++ b/xen/include/asm-x86/irq.h	Tue Jul 26 18:36:58 2011 +0100
> @@ -24,11 +24,16 @@
>  #define irq_to_desc(irq)    (&irq_desc[irq])
>  #define irq_cfg(irq)        (&irq_cfg[irq])
>  
> +typedef struct {
> +    DECLARE_BITMAP(_bits,NR_VECTORS);
> +} vmask_t;
> +
>  struct irq_cfg {
>          int  vector;
>          cpumask_t cpu_mask;
>          cpumask_t old_cpu_mask;
>          unsigned move_cleanup_count;
> +        vmask_t *used_vectors;
>          u8 move_in_progress : 1;
>  };
>  

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1314026133 -3600
> # Node ID 3a05da2dc7c0a5fc0fcfc40c535d1fcb71203625
> # Parent  d1cd78a73a79e0e648937322cdb8d92a7f86327a
> x86: Fix up irq vector map logic
> 
> We need to make sure that cfg->used_vector is only cleared once;
> otherwise there may be a race condition that allows the same vector to
> be assigned twice, defeating the whole purpose of the map.
> 
> This makes two changes:
> * __clear_irq_vector() only clears the vector if the irq is not being
> moved
> * smp_iqr_move_cleanup_interrupt() only clears used_vector if this
> is the last place it's being used (move_cleanup_count==0 after
> decrement).
> 
> Also make use of asserts more consistent, to catch this kind of logic
> bug in the future.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r d1cd78a73a79 -r 3a05da2dc7c0 xen/arch/x86/io_apic.c
> --- a/xen/arch/x86/io_apic.c	Mon Aug 22 16:15:19 2011 +0100
> +++ b/xen/arch/x86/io_apic.c	Mon Aug 22 16:15:33 2011 +0100
> @@ -485,12 +485,14 @@
>                   irq, vector, smp_processor_id());
>  
>          __get_cpu_var(vector_irq)[vector] = -1;
> -        if ( cfg->used_vectors )
> +        cfg->move_cleanup_count--;
> +
> +        if ( cfg->move_cleanup_count == 0 
> +             &&  cfg->used_vectors )
>          {
>              ASSERT(test_bit(vector, cfg->used_vectors));
>              clear_bit(vector, cfg->used_vectors);
>          }
> -        cfg->move_cleanup_count--;
>  unlock:
>          spin_unlock(&desc->lock);
>      }
> diff -r d1cd78a73a79 -r 3a05da2dc7c0 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Mon Aug 22 16:15:19 2011 +0100
> +++ b/xen/arch/x86/irq.c	Mon Aug 22 16:15:33 2011 +0100
> @@ -113,7 +113,10 @@
>      cfg->vector = vector;
>      cfg->cpu_mask = online_mask;
>      if ( cfg->used_vectors )
> +    {
> +        ASSERT(!test_bit(vector, cfg->used_vectors));
>          set_bit(vector, cfg->used_vectors);
> +    }
>      irq_status[irq] = IRQ_USED;
>      if (IO_APIC_IRQ(irq))
>          irq_vector[irq] = vector;
> @@ -207,15 +210,13 @@
>      for_each_cpu_mask(cpu, tmp_mask)
>          per_cpu(vector_irq, cpu)[vector] = -1;
>  
> -    if ( cfg->used_vectors )
> -        clear_bit(vector, cfg->used_vectors);
> -
>      cfg->vector = IRQ_VECTOR_UNASSIGNED;
>      cpus_clear(cfg->cpu_mask);
>      init_one_irq_status(irq);
>  
>      if (likely(!cfg->move_in_progress))
>          return;
> +
>      cpus_and(tmp_mask, cfg->old_cpu_mask, cpu_online_map);
>      for_each_cpu_mask(cpu, tmp_mask) {
>          for (vector = FIRST_DYNAMIC_VECTOR; vector <= LAST_DYNAMIC_VECTOR;
> @@ -228,6 +229,12 @@
>               break;
>          }
>       }
> +
> +    if ( cfg->used_vectors )
> +    {
> +        ASSERT(test_bit(vector, cfg->used_vectors));
> +        clear_bit(vector, cfg->used_vectors);
> +    }
>  
>      cfg->move_in_progress = 0;
>  }

> # HG changeset patch
> # User Jan Beulich <jbeulich@suse.com>
> # Date 1317730316 -7200
> # Node ID a99d75671a911f9c0d5d11e0fe88a0a65863cb44
> # Parent  3d1664cc9e458809e399320204aca8536e401ee1
> AMD-IOMMU: remove dead variable references
> 
> These got orphaned up by recent changes.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Acked-by: Keir Fraser <keir@xen.org>
> 
> diff -r 599cf097900b xen/drivers/passthrough/amd/pci_amd_iommu.c
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Mon Sep 05 15:00:15 2011 +0100
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Fri Oct 21 15:39:30 2011 -0400
> @@ -24,9 +24,6 @@
>  #include <asm/hvm/iommu.h>
>  #include <asm/amd-iommu.h>
>  #include <asm/hvm/svm/amd-iommu-proto.h>
> -
> -extern bool_t __read_mostly opt_irq_perdev_vector_map;
> -extern bool_t __read_mostly iommu_amd_perdev_vector_map;
>  
>  extern unsigned short ivrs_bdf_entries;
>  extern struct ivrs_mappings *ivrs_mappings;
> diff -r 599cf097900b xen/drivers/passthrough/iommu.c
> --- a/xen/drivers/passthrough/iommu.c	Mon Sep 05 15:00:15 2011 +0100
> +++ b/xen/drivers/passthrough/iommu.c	Fri Oct 21 15:39:30 2011 -0400
> @@ -49,7 +49,6 @@
>  bool_t __read_mostly iommu_intremap = 1;
>  bool_t __read_mostly iommu_hap_pt_share;
>  bool_t __read_mostly amd_iommu_debug;
> -bool_t __read_mostly iommu_amd_perdev_vector_map = 1;
>  bool_t __read_mostly amd_iommu_perdev_intremap;
>  
>  static void __init parse_iommu_param(char *s)
> @@ -85,8 +84,6 @@
>              iommu_dom0_strict = 1;
>          else if ( !strcmp(s, "sharept") )
>              iommu_hap_pt_share = 1;
> -        else if ( !strcmp(s, "no-perdev-vector-map") )
> -            iommu_amd_perdev_vector_map = 0;
>  
>          s = ss + 1;
>      } while ( ss );

> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1315231215 -3600
> # Node ID 32814ad7458dc842a7c588eee13e5c4ee11709a3
> # Parent  f1349a968a5ac5577d67ad4a3f3490c580dbe264
> xen: Add global irq_vector_map option, set if using AMD global intremap tables
> 
> As mentioned in previous changesets, AMD IOMMU interrupt
> remapping tables only look at the vector, not the destination
> id of an interrupt.  This means that all IRQs going through
> the same interrupt remapping table need to *not* share vectors.
> 
> The irq "vector map" functionality was originally introduced
> after a patch which disabled global AMD IOMMUs entirely.  That
> patch has since been reverted, meaning that AMD intremap tables
> can either be per-device or global.
> 
> This patch therefore introduces a global irq vector map option,
> and enables it if we're using an AMD IOMMU with a global
> interrupt remapping table.
> 
> This patch removes the "irq-perdev-vector-map" boolean
> command-line optino and replaces it with "irq_vector_map",
> which can have one of three values: none, global, or per-device.
> 
> Setting the irq_vector_map to any value will override the
> default that the AMD code sets.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> diff -r 6fc00d52c179 docs/src/user.tex
> --- a/docs/src/user.tex	Mon Aug 22 16:15:33 2011 +0100
> +++ b/docs/src/user.tex	Fri Oct 21 15:21:23 2011 -0400
> @@ -4197,6 +4197,10 @@
>  \item [ vcpu\_migration\_delay=$<$minimum\_time$>$] Set minimum time of 
>    vcpu migration in microseconds (default 0). This parameter avoids agressive
>    vcpu migration. For example, the linux kernel uses 0.5ms by default.
> +\item [ irq_vector_map=xxx ] Enable irq vector non-sharing maps.  Setting 'global' 
> +  will ensure that no  IRQs will share vectors.  Setting 'per-device' will ensure 
> +  that no IRQs from the same device will share vectors.  Setting to 'none' will
> +  disable it entirely, overriding any defaults the IOMMU code may set.
>  \end{description}
>  
>  In addition, the following options may be specified on the Xen command
> diff -r 6fc00d52c179 xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c	Mon Aug 22 16:15:33 2011 +0100
> +++ b/xen/arch/x86/irq.c	Fri Oct 21 15:21:23 2011 -0400
> @@ -24,6 +24,8 @@
>  #include <asm/mach-generic/mach_apic.h>
>  #include <public/physdev.h>
>  
> +static void parse_irq_vector_map_param(char *s);
> +
>  /* opt_noirqbalance: If true, software IRQ balancing/affinity is disabled. */
>  bool_t __read_mostly opt_noirqbalance = 0;
>  boolean_param("noirqbalance", opt_noirqbalance);
> @@ -33,8 +35,10 @@
>  integer_param("nr_irqs", nr_irqs);
>  
>  /* This default may be changed by the AMD IOMMU code */
> -bool_t __read_mostly opt_irq_perdev_vector_map = 0;
> -boolean_param("irq-perdev-vector-map", opt_irq_perdev_vector_map);
> +int __read_mostly opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_DEFAULT;
> +custom_param("irq_vector_map", parse_irq_vector_map_param);
> +
> +vmask_t global_used_vector_map;
>  
>  u8 __read_mostly *irq_vector;
>  struct irq_desc __read_mostly *irq_desc = NULL;
> @@ -63,6 +67,26 @@
>  /* irq_ratelimit: the max irq rate allowed in every 10ms, set 0 to disable */
>  static unsigned int __read_mostly irq_ratelimit_threshold = 10000;
>  integer_param("irq_ratelimit", irq_ratelimit_threshold);
> +
> +static void __init parse_irq_vector_map_param(char *s)
> +{
> +    char *ss;
> +
> +    do {
> +        ss = strchr(s, ',');
> +        if ( ss )
> +            *ss = '\0';
> +
> +        if ( !strcmp(s, "none"))
> +            opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_NONE;
> +        else if ( !strcmp(s, "global"))
> +            opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_GLOBAL;
> +        else if ( !strcmp(s, "per-device"))
> +            opt_irq_vector_map=OPT_IRQ_VECTOR_MAP_PERDEV;
> +
> +        s = ss + 1;
> +    } while ( ss );
> +}
>  
>  /* Must be called when irq disabled */
>  void lock_vector_lock(void)
> @@ -348,6 +372,41 @@
>      end_none
>  };
>  
> +static vmask_t *irq_get_used_vector_mask(int irq)
> +{
> +    vmask_t *ret = NULL;
> +
> +    if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_GLOBAL )
> +    {
> +        struct irq_desc *desc = irq_to_desc(irq);
> +
> +        ret = &global_used_vector_map;
> +
> +        if ( desc->chip_data->used_vectors )
> +        {
> +            printk(XENLOG_INFO "%s: Strange, unassigned irq %d already has used_vectors!\n",
> +                   __func__, irq);
> +        }
> +        else
> +        {
> +            int vector;
> +            
> +            vector = irq_to_vector(irq);
> +            if ( vector > 0 )
> +            {
> +                printk(XENLOG_INFO "%s: Strange, irq %d already assigned vector %d!\n",
> +                       __func__, irq, vector);
> +                
> +                ASSERT(!test_bit(vector, ret));
> +
> +                set_bit(vector, ret);
> +            }
> +        }
> +    }
> +
> +    return ret;
> +}
> +
>  int __assign_irq_vector(int irq, struct irq_cfg *cfg, const cpumask_t *mask)
>  {
>      /*
> @@ -366,6 +425,7 @@
>      int cpu, err;
>      unsigned long flags;
>      cpumask_t tmp_mask;
> +    vmask_t *irq_used_vectors = NULL;
>  
>      old_vector = irq_to_vector(irq);
>      if (old_vector) {
> @@ -380,6 +440,17 @@
>          return -EAGAIN;
>  
>      err = -ENOSPC;
> +
> +    /* This is the only place normal IRQs are ever marked
> +     * as "in use".  If they're not in use yet, check to see
> +     * if we need to assign a global vector mask. */
> +    if ( irq_status[irq] == IRQ_USED )
> +    {
> +        irq_used_vectors = cfg->used_vectors;
> +    }
> +    else
> +        irq_used_vectors = irq_get_used_vector_mask(irq);
> +
>      for_each_cpu_mask(cpu, *mask) {
>          int new_cpu;
>          int vector, offset;
> @@ -405,8 +476,8 @@
>          if (test_bit(vector, used_vectors))
>              goto next;
>  
> -        if (cfg->used_vectors
> -            && test_bit(vector, cfg->used_vectors) )
> +        if (irq_used_vectors
> +            && test_bit(vector, irq_used_vectors) )
>              goto next;
>  
>          for_each_cpu_mask(new_cpu, tmp_mask)
> @@ -424,15 +495,22 @@
>              per_cpu(vector_irq, new_cpu)[vector] = irq;
>          cfg->vector = vector;
>          cpus_copy(cfg->cpu_mask, tmp_mask);
> +
> +        irq_status[irq] = IRQ_USED;
> +        ASSERT((cfg->used_vectors == NULL)
> +               || (cfg->used_vectors == irq_used_vectors));
> +        cfg->used_vectors = irq_used_vectors;
> +
> +        if (IO_APIC_IRQ(irq))
> +            irq_vector[irq] = vector;
> +
>          if ( cfg->used_vectors )
>          {
>              ASSERT(!test_bit(vector, cfg->used_vectors));
> +
>              set_bit(vector, cfg->used_vectors);
>          }
>  
> -        irq_status[irq] = IRQ_USED;
> -            if (IO_APIC_IRQ(irq))
> -                    irq_vector[irq] = vector;
>          err = 0;
>          local_irq_restore(flags);
>          break;
> @@ -1521,7 +1599,7 @@
>  
>      if ( !IS_PRIV(current->domain) &&
>           !(IS_PRIV_FOR(current->domain, d) &&
> -          irq_access_permitted(current->domain, pirq)))
> +           irq_access_permitted(current->domain, pirq)))
>          return -EPERM;
>  
>      if ( pirq < 0 || pirq >= d->nr_pirqs || irq < 0 || irq >= nr_irqs )
> @@ -1569,11 +1647,21 @@
>  
>          if ( desc->handler != &no_irq_type )
>              dprintk(XENLOG_G_ERR, "dom%d: irq %d in use\n",
> -              d->domain_id, irq);
> +                    d->domain_id, irq);
>          desc->handler = &pci_msi_type;
> -        if ( opt_irq_perdev_vector_map
> +        if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_PERDEV
>               && !desc->chip_data->used_vectors )
> +        {
>              desc->chip_data->used_vectors = &pdev->info.used_vectors;
> +            if ( desc->chip_data->vector != IRQ_VECTOR_UNASSIGNED )
> +            {
> +                int vector = desc->chip_data->vector;
> +                ASSERT(!test_bit(vector, desc->chip_data->used_vectors));
> +
> +                set_bit(vector, desc->chip_data->used_vectors);
> +            }
> +        }
> +
>          d->arch.pirq_irq[pirq] = irq;
>          d->arch.irq_pirq[irq] = pirq;
>          setup_msi_irq(pdev, msi_desc, irq);
> @@ -1584,9 +1672,12 @@
>          d->arch.pirq_irq[pirq] = irq;
>          d->arch.irq_pirq[irq] = pirq;
>          spin_unlock_irqrestore(&desc->lock, flags);
> +
> +        if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_PERDEV )
> +            printk(XENLOG_INFO "Per-device vector maps for GSIs not implemented yet.\n");
>      }
>  
> - done:
> +done:
>      return ret;
>  }
>  
> diff -r 6fc00d52c179 xen/drivers/passthrough/amd/pci_amd_iommu.c
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Mon Aug 22 16:15:33 2011 +0100
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Fri Oct 21 15:21:23 2011 -0400
> @@ -169,18 +169,35 @@
>          return -ENODEV;
>      }
>  
> -    /* Enable use of per-device vector map unless otherwise
> -     * specified */
> -    if ( iommu_amd_perdev_vector_map )
> +    /*
> +     * AMD IOMMUs don't distinguish between vectors destined for
> +     * different cpus when doing interrupt remapping.  This means
> +     * that interrupts going through the same intremap table
> +     * can't share the same vector.
> +     *
> +     * If irq_vector_map isn't specified, choose a sensible default:
> +     * - If we're using per-device interemap tables, per-device
> +     *   vector non-sharing maps
> +     * - If we're using a global interemap table, global vector
> +     *   non-sharing map
> +     */
> +    if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_DEFAULT )
>      {
> -        printk("AMD-Vi: Enabling per-device vector maps\n");
> -        opt_irq_perdev_vector_map=1;
> +        if ( amd_iommu_perdev_intremap )
> +        {
> +            printk("AMD-Vi: Enabling per-device vector maps\n");
> +            opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_PERDEV;
> +        }
> +        else
> +        {
> +            printk("AMD-Vi: Enabling global vector map\n");
> +            opt_irq_vector_map = OPT_IRQ_VECTOR_MAP_GLOBAL;
> +        }
>      }
>      else
>      {
> -        printk("AMD-Vi: WARNING - not enabling per-device vector maps\n");
> +        printk("AMD-Vi: Not overriding irq_vector_map setting\n");
>      }
> -
>      return scan_pci_devices();
>  }
>  
> diff -r 6fc00d52c179 xen/include/asm-x86/irq.h
> --- a/xen/include/asm-x86/irq.h	Mon Aug 22 16:15:33 2011 +0100
> +++ b/xen/include/asm-x86/irq.h	Fri Oct 21 15:21:23 2011 -0400
> @@ -44,6 +44,13 @@
>  extern u8 *irq_vector;
>  
>  extern bool_t opt_noirqbalance;
> +
> +#define OPT_IRQ_VECTOR_MAP_DEFAULT 0 /* Do the default thing  */
> +#define OPT_IRQ_VECTOR_MAP_NONE    1 /* None */ 
> +#define OPT_IRQ_VECTOR_MAP_GLOBAL  2 /* One global vector map (no vector sharing) */ 
> +#define OPT_IRQ_VECTOR_MAP_PERDEV  3 /* Per-device vetor map (no vector sharing w/in a device) */
> +
> +extern int opt_irq_vector_map;
>  
>  /*
>   * Per-cpu current frame pointer - the location of the last exception frame on

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


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:09:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:09:38 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Wv-00028x-Q7
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:09:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Wd-0001Q4-Te; Thu, 17 Nov 2011 08:09:20 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4Rw-0000r7-M1
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:04:30 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1321545865!3572845!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17787 invoked from network); 17 Nov 2011 16:04:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:04:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315180800"; 
   d="scan'208";a="8993475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 16:04:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 16:04:25 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RR4Rs-0006bX-Kq;
	Thu, 17 Nov 2011 16:04:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RR4Rs-0004EW-Ek;
	Thu, 17 Nov 2011 16:04:24 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9850-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 17 Nov 2011 16:04:24 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 9850: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                    fail pass in 9827
 test-amd64-amd64-xl           9 guest-start          fail in 9827 pass in 9850
 test-amd64-amd64-xl-sedf      5 xen-boot             fail in 9827 pass in 9850

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf     15 guest-stop                   fail   never pass
 test-amd64-i386-xl-credit2    5 xen-boot                     fail    like 9757
 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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail in 9827 blocked in 9757
 test-amd64-i386-xl-win-vcpus1  7 windows-install       fail in 9827 never pass

version targeted for testing:
 xen                  c16b0a997a05
baseline version:
 xen                  cdff7052bad8

------------------------------------------------------------
People who touched revisions under test:
  Gianluca Guida <gianluca.guida@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Mark Langsdorf <mark.langsdorf@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-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-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


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

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

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


Pushing revision :

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

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:09:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:09:38 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Wv-00028x-Q7
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:09:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4Wd-0001Q4-Te; Thu, 17 Nov 2011 08:09:20 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4Rw-0000r7-M1
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:04:30 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1321545865!3572845!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17787 invoked from network); 17 Nov 2011 16:04:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:04:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315180800"; 
   d="scan'208";a="8993475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 16:04:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 16:04:25 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RR4Rs-0006bX-Kq;
	Thu, 17 Nov 2011 16:04:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RR4Rs-0004EW-Ek;
	Thu, 17 Nov 2011 16:04:24 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9850-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 17 Nov 2011 16:04:24 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 9850: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                    fail pass in 9827
 test-amd64-amd64-xl           9 guest-start          fail in 9827 pass in 9850
 test-amd64-amd64-xl-sedf      5 xen-boot             fail in 9827 pass in 9850

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf     15 guest-stop                   fail   never pass
 test-amd64-i386-xl-credit2    5 xen-boot                     fail    like 9757
 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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail in 9827 blocked in 9757
 test-amd64-i386-xl-win-vcpus1  7 windows-install       fail in 9827 never pass

version targeted for testing:
 xen                  c16b0a997a05
baseline version:
 xen                  cdff7052bad8

------------------------------------------------------------
People who touched revisions under test:
  Gianluca Guida <gianluca.guida@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Mark Langsdorf <mark.langsdorf@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          fail    
 test-amd64-i386-xl                                           fail    
 test-i386-i386-xl                                            fail    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-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-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


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

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

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


Pushing revision :

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

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:11:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:11:35 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Yp-00029F-06
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4YQ-0001qu-VB; Thu, 17 Nov 2011 08:11:12 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4ST-0000tN-3A
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:05:07 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1321545896!1966150!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14897 invoked from network); 17 Nov 2011 16:04:57 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 16:04:57 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHG4r6D021497
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 16:04:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHG4qND005953
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 16:04:52 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHG4is7005267; Thu, 17 Nov 2011 10:04:44 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 08:04:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2A61F81489; Thu, 17 Nov 2011 11:04:43 -0500 (EST)
Date: Thu, 17 Nov 2011 11:04:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jason Thomas <jethomas100@gmail.com>
Subject: Re: [Xen-devel] VMM Architecture documentation
Message-ID: <20111117160443.GD6008@phenom.dumpdata.com>
References: <CABKwQ+pT7LFqmnfGoK5YVsmzqomYjnA6t0jr=RyTVoTjFUDNLw@mail.gmail.com>
	<20111116170034.GC2793@phenom.dumpdata.com>
	<CABKwQ+q5a-FNxho8LfX=LSNY9xHHAYOHeGb97r==sez+buwa=g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABKwQ+q5a-FNxho8LfX=LSNY9xHHAYOHeGb97r==sez+buwa=g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EC530A6.00AA,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 16, 2011 at 10:50:07AM -0800, Jason Thomas wrote:
> On Wed, Nov 16, 2011 at 9:00 AM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com> wrote:
> 
> > On Tue, Nov 15, 2011 at 10:12:14AM -0800, Jason Thomas wrote:
> > > I am looking for a low level description of the VMM architecture, if one
> > > exists. Specifically which modules are required for 32 bit guests and
> > which
> > > are needed for 64 bit guests. Does this exist or do I have to sift
> > through
> > > the source code to find the differences?
> >
> > We are kind of working through to make that easier to read.
> >
> > But I am not actually sure what you mean by 'modules'?
> >
> 
> I am looking to get a more modular view of the Xen architecture.  What Xen
> VMM components are required to support a 32 bit guest, what components are
> required to support 64 bit guest. Are there components that both the 32 bit
> and the 64 bit guests share? How does HVM come into this (i.e. what code
> supports the usage of HVM and what code is no longer needed if HVM is used)?
> 
> Is there a document out there that depicts this, or is it something you get
> by going through the source code?

Source code.

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:11:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:11:35 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4Yp-00029F-06
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4YQ-0001qu-VB; Thu, 17 Nov 2011 08:11:12 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4ST-0000tN-3A
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:05:07 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1321545896!1966150!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14897 invoked from network); 17 Nov 2011 16:04:57 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 16:04:57 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHG4r6D021497
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 16:04:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHG4qND005953
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 16:04:52 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHG4is7005267; Thu, 17 Nov 2011 10:04:44 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 08:04:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2A61F81489; Thu, 17 Nov 2011 11:04:43 -0500 (EST)
Date: Thu, 17 Nov 2011 11:04:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jason Thomas <jethomas100@gmail.com>
Subject: Re: [Xen-devel] VMM Architecture documentation
Message-ID: <20111117160443.GD6008@phenom.dumpdata.com>
References: <CABKwQ+pT7LFqmnfGoK5YVsmzqomYjnA6t0jr=RyTVoTjFUDNLw@mail.gmail.com>
	<20111116170034.GC2793@phenom.dumpdata.com>
	<CABKwQ+q5a-FNxho8LfX=LSNY9xHHAYOHeGb97r==sez+buwa=g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABKwQ+q5a-FNxho8LfX=LSNY9xHHAYOHeGb97r==sez+buwa=g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EC530A6.00AA,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 16, 2011 at 10:50:07AM -0800, Jason Thomas wrote:
> On Wed, Nov 16, 2011 at 9:00 AM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com> wrote:
> 
> > On Tue, Nov 15, 2011 at 10:12:14AM -0800, Jason Thomas wrote:
> > > I am looking for a low level description of the VMM architecture, if one
> > > exists. Specifically which modules are required for 32 bit guests and
> > which
> > > are needed for 64 bit guests. Does this exist or do I have to sift
> > through
> > > the source code to find the differences?
> >
> > We are kind of working through to make that easier to read.
> >
> > But I am not actually sure what you mean by 'modules'?
> >
> 
> I am looking to get a more modular view of the Xen architecture.  What Xen
> VMM components are required to support a 32 bit guest, what components are
> required to support 64 bit guest. Are there components that both the 32 bit
> and the 64 bit guests share? How does HVM come into this (i.e. what code
> supports the usage of HVM and what code is no longer needed if HVM is used)?
> 
> Is there a document out there that depicts this, or is it something you get
> by going through the source code?

Source code.

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:13:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:13:54 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4b4-00029S-3M
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4ag-0002Jd-Cd; Thu, 17 Nov 2011 08:13:30 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4Ul-0001BY-0G
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:07:28 -0800
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1321546003!48904008!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9555 invoked from network); 17 Nov 2011 16:06:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 16:06:44 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHG76Ip029154
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 16:07:07 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHG760H011592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 16:07:06 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHG6xGu028333; Thu, 17 Nov 2011 10:06:59 -0600
Received: from [10.154.37.9] (/10.154.37.9)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 08:06:57 -0800
Message-ID: <4EC53119.7060307@oracle.com>
Date: Fri, 18 Nov 2011 00:06:49 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EC3B62F.6080702@oracle.com>	
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<1321526148.3664.263.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321526148.3664.263.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EC5312C.0024,ss=1,re=-2.300,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: [Xen-devel] Re: [PATCH 1/3] xen/granttable: Introducing grant table
	V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1020048056=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

This is a multi-part message in MIME format.
--------------090106010607000406010701
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for your review, Ian.
See following,
>> -       } while ((nflags = sync_cmpxchg(&shared[ref].flags, flags, 0)) != flags);
>> +       } while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0))
>> +                       != flags);
>>     
>
> I think this is one of those cases where strictly adhering to an
> 80-column rule hurts the readability of the code.
>
> If you had left the static global as "shared" rather than
> "gnttab_shared" you wouldn't have this issue. If you want a more
> descriptive name why not just call it "gnttab"?
>
>   
Actually, whether the name is "gnttab_shared" or "shared" or "gnttab", 
the code line still breaks the 80-column rule.
>>         return 1;
>>  }
>> +
>> +int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
>> +{
>> +       return gnttab_interface.end_foreign_access_ref(ref, readonly);
>> +}
>>  EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);
>>
>>  void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
>> @@ -246,37 +309,45 @@ EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer);
>>  void gnttab_grant_foreign_transfer_ref(grant_ref_t ref, domid_t domid,
>>                                        unsigned long pfn)
>>  {
>> -       update_grant_entry(ref, domid, pfn, GTF_accept_transfer);
>> +       gnttab_interface.update_entry(ref, domid, pfn, GTF_accept_transfer);
>>  }
>>  EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer_ref);
>>
>> -unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
>> +static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
>>  {
>>         unsigned long frame;
>>         u16           flags;
>> +       u16          *pflags;
>> +
>> +       pflags = &gnttab_shared.v1[ref].flags;
>>     
>
> It would be nice if these refactoring bits could be separated out from
> the more mechanical renaming and abstracting to fn pointer aspects of
> the patch.
>   
I am not so sure about your meaning, do you mean change gnttab_shared 
back to shared?
>>         /*
>>          * If a transfer is not even yet started, try to reclaim the grant
>>          * reference and return failure (== 0).
>>          */
>> -       while (!((flags = shared[ref].flags) & GTF_transfer_committed)) {
>> -               if (sync_cmpxchg(&shared[ref].flags, flags, 0) == flags)
>> +       while (!((flags = *pflags) & GTF_transfer_committed)) {
>> +               if (sync_cmpxchg(pflags, flags, 0) == flags)
>>                         return 0;
>>                 cpu_relax();
>>         }
>>
>>         /* If a transfer is in progress then wait until it is completed. */
>>         while (!(flags & GTF_transfer_completed)) {
>> -               flags = shared[ref].flags;
>> +               flags = *pflags;
>>                 cpu_relax();
>>         }
>>
>>         rmb();  /* Read the frame number /after/ reading completion status. */
>> -       frame = shared[ref].frame;
>> +       frame = gnttab_shared.v1[ref].frame;
>>         BUG_ON(frame == 0);
>>
>>         return frame;
>>  }
>> +
>> +unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
>> +{
>> +       return gnttab_interface.end_foreign_transfer_ref(ref);
>> +}
>>  EXPORT_SYMBOL_GPL(gnttab_end_foreign_transfer_ref);
>>
>>  unsigned long gnttab_end_foreign_transfer(grant_ref_t ref)
>> @@ -520,6 +591,23 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>>  }
>>  EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
>>
>> +static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
>> +{
>> +       int rc;
>> +
>> +       rc = arch_gnttab_map_shared(frames, nr_gframes,
>> +                                   gnttab_max_grant_frames(),
>> +                                   &gnttab_shared.addr);
>> +       BUG_ON(rc);
>> +
>> +       return 0;
>> +}
>> +
>> +static void gnttab_unmap_frames_v1(void)
>> +{
>> +       arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
>> +}
>> +
>>  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>>  {
>>         struct gnttab_setup_table setup;
>> @@ -567,19 +655,33 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>>
>>         BUG_ON(rc || setup.status);
>>
>> -       rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
>> -                                   &shared);
>> -       BUG_ON(rc);
>> +       rc = gnttab_interface.map_frames(frames, nr_gframes);
>>     
>
> Nothing checks rc here now?
>
> In fact the gnttab_map_frames_v1 function has its own BUG_ON(rc) and
> always returns 0 if it returns at all so perhaps that hook should be
> returning void?
>   
Yes, it should be that if there is only v1 function existing.
However, I added returns 0 here in order to keep consistence with v2 
function of next patch. The function pointer type is: int 
(*map_frames)(....), and v2 function returning value is meaningful. The 
returning value directly decides returning value of gnttab_map. See 
following code in function gnttab_map of v2 patch:

        if (rc < 0)
                return rc;
        return 0;

If gnttab_map_frames_v1 returns void here, it is necessary to change it 
back(including "void (*map_frames)"  --> "int (*map_frames)") in next v2 
implementation patch. So I only added return 0 here.
>   
>>         kfree(frames);
>>
>>         return 0;
>>  }
>>
>> +static void gnttab_request_version(void)
>> +{
>> +       grant_table_version = 1;
>> +       gnttab_interface.map_frames = gnttab_map_frames_v1;
>> +       gnttab_interface.unmap_frames = gnttab_unmap_frames_v1;
>> +       gnttab_interface.update_entry = update_grant_entry_v1;
>> +       gnttab_interface.end_foreign_access_ref =
>> +                                       gnttab_end_foreign_access_ref_v1;
>> +       gnttab_interface.end_foreign_transfer_ref =
>> +                                       gnttab_end_foreign_transfer_ref_v1;
>> +       gnttab_interface.query_foreign_access = gnttab_query_foreign_access_v1;
>>     
>
> The more normal way to do this would be to make gnttab_interface a
> pointer, define gnttab_v1_ops and do:
> 	gnttab_interface = &gnttab_v1_ops;
> or if the pointer overhead is significant remove that and just do a
> struct assignment:
> 	gnttab_interface = gnttab_v1_ops;
>
>   
If using this way, we need two more public structures(gnttab_v1_ops and 
gnttab_v2_ops), and two more functions to initialize those two 
structures and then initialize the pointer gnttab_interface. It is more 
complicated, am i missing something?

.....
>> +/*
>>   * Bitfield values for update_pin_status.flags.
>>   */
>>   /* Map the grant entry for access by I/O devices. */
>> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> index 6a6e914..710afe0 100644
>> --- a/include/xen/interface/xen.h
>> +++ b/include/xen/interface/xen.h
>> @@ -523,6 +523,8 @@ struct tmem_op {
>>         } u;
>>  };
>>
>> +DEFINE_GUEST_HANDLE(uint64_t);
>>     
>
> The kernel uses uN style types rather than the uintN_t style ones,
> although include/xen/interface/grant_table.h seems not to adhere to that
> at the moment. It might be worth cleaning that up as you go passed.
>   
Thanks, I'd like to change it.

Thanks
Annie
>   
>> +
>>  #else /* __ASSEMBLY__ */
>>
>>  /* In assembly code we cannot use C numeric constant suffixes. */
>> --
>> 1.7.6.4
>>
>>     
>
>
>   

--------------090106010607000406010701
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks for your review, Ian.<br>
See following,<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">
-       } while ((nflags = sync_cmpxchg(&amp;shared[ref].flags, flags, 0)) != flags);
+       } while ((nflags = sync_cmpxchg(&amp;gnttab_shared.v1[ref].flags, flags, 0))
+                       != flags);
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I think this is one of those cases where strictly adhering to an
80-column rule hurts the readability of the code.

If you had left the static global as "shared" rather than
"gnttab_shared" you wouldn't have this issue. If you want a more
descriptive name why not just call it "gnttab"?

  </pre>
</blockquote>
Actually, whether the name is "gnttab_shared" or "shared" or "gnttab",
the code line still breaks the 80-column rule.<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">        return 1;
 }
+
+int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+{
+       return gnttab_interface.end_foreign_access_ref(ref, readonly);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);

 void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
@@ -246,37 +309,45 @@ EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer);
 void gnttab_grant_foreign_transfer_ref(grant_ref_t ref, domid_t domid,
                                       unsigned long pfn)
 {
-       update_grant_entry(ref, domid, pfn, GTF_accept_transfer);
+       gnttab_interface.update_entry(ref, domid, pfn, GTF_accept_transfer);
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer_ref);

-unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 {
        unsigned long frame;
        u16           flags;
+       u16          *pflags;
+
+       pflags = &amp;gnttab_shared.v1[ref].flags;
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It would be nice if these refactoring bits could be separated out from
the more mechanical renaming and abstracting to fn pointer aspects of
the patch.
  </pre>
</blockquote>
I am not so sure about your meaning, do you mean change gnttab_shared
back to shared?<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">        /*
         * If a transfer is not even yet started, try to reclaim the grant
         * reference and return failure (== 0).
         */
-       while (!((flags = shared[ref].flags) &amp; GTF_transfer_committed)) {
-               if (sync_cmpxchg(&amp;shared[ref].flags, flags, 0) == flags)
+       while (!((flags = *pflags) &amp; GTF_transfer_committed)) {
+               if (sync_cmpxchg(pflags, flags, 0) == flags)
                        return 0;
                cpu_relax();
        }

        /* If a transfer is in progress then wait until it is completed. */
        while (!(flags &amp; GTF_transfer_completed)) {
-               flags = shared[ref].flags;
+               flags = *pflags;
                cpu_relax();
        }

        rmb();  /* Read the frame number /after/ reading completion status. */
-       frame = shared[ref].frame;
+       frame = gnttab_shared.v1[ref].frame;
        BUG_ON(frame == 0);

        return frame;
 }
+
+unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+{
+       return gnttab_interface.end_foreign_transfer_ref(ref);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_transfer_ref);

 unsigned long gnttab_end_foreign_transfer(grant_ref_t ref)
@@ -520,6 +591,23 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);

+static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
+{
+       int rc;
+
+       rc = arch_gnttab_map_shared(frames, nr_gframes,
+                                   gnttab_max_grant_frames(),
+                                   &amp;gnttab_shared.addr);
+       BUG_ON(rc);
+
+       return 0;
+}
+
+static void gnttab_unmap_frames_v1(void)
+{
+       arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
        struct gnttab_setup_table setup;
@@ -567,19 +655,33 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)

        BUG_ON(rc || setup.status);

-       rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
-                                   &amp;shared);
-       BUG_ON(rc);
+       rc = gnttab_interface.map_frames(frames, nr_gframes);
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Nothing checks rc here now?

In fact the gnttab_map_frames_v1 function has its own BUG_ON(rc) and
always returns 0 if it returns at all so perhaps that hook should be
returning void?
  </pre>
</blockquote>
Yes, it should be that if there is only v1 function existing.<br>
However, I added returns 0 here in order to keep consistence with v2
function of next patch. The function pointer type is: int
(*map_frames)(....), and v2 function returning value is meaningful. The
returning value directly decides returning value of gnttab_map. See
following code in function gnttab_map of v2 patch:<br>
<br>
        if (rc &lt; 0)<br>
                return rc;<br>
        return 0;<br>
<br>
If gnttab_map_frames_v1
returns void here, it is necessary to change it back(including "void
(*map_frames)"  --&gt; "int (*map_frames)") in next v2 implementation
patch. So I only added return 0 here.<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">        kfree(frames);

        return 0;
 }

+static void gnttab_request_version(void)
+{
+       grant_table_version = 1;
+       gnttab_interface.map_frames = gnttab_map_frames_v1;
+       gnttab_interface.unmap_frames = gnttab_unmap_frames_v1;
+       gnttab_interface.update_entry = update_grant_entry_v1;
+       gnttab_interface.end_foreign_access_ref =
+                                       gnttab_end_foreign_access_ref_v1;
+       gnttab_interface.end_foreign_transfer_ref =
+                                       gnttab_end_foreign_transfer_ref_v1;
+       gnttab_interface.query_foreign_access = gnttab_query_foreign_access_v1;
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The more normal way to do this would be to make gnttab_interface a
pointer, define gnttab_v1_ops and do:
	gnttab_interface = &amp;gnttab_v1_ops;
or if the pointer overhead is significant remove that and just do a
struct assignment:
	gnttab_interface = gnttab_v1_ops;

  </pre>
</blockquote>
If using this way, we need two more public structures(gnttab_v1_ops and
gnttab_v2_ops), and two more functions to initialize those two
structures and then initialize the pointer gnttab_interface. It is more
complicated, am i missing something?<br>
<br>
.....<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">
+/*
  * Bitfield values for update_pin_status.flags.
  */
  /* Map the grant entry for access by I/O devices. */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..710afe0 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -523,6 +523,8 @@ struct tmem_op {
        } u;
 };

+DEFINE_GUEST_HANDLE(uint64_t);
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The kernel uses uN style types rather than the uintN_t style ones,
although include/xen/interface/grant_table.h seems not to adhere to that
at the moment. It might be worth cleaning that up as you go passed.
  </pre>
</blockquote>
Thanks, I'd like to change it.<br>
<br>
Thanks<br>
Annie<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">+
 #else /* __ASSEMBLY__ */

 /* In assembly code we cannot use C numeric constant suffixes. */
--
1.7.6.4

    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
</body>
</html>

--------------090106010607000406010701--


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

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

--===============1020048056==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:13:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:13:54 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4b4-00029S-3M
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4ag-0002Jd-Cd; Thu, 17 Nov 2011 08:13:30 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4Ul-0001BY-0G
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:07:28 -0800
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1321546003!48904008!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9555 invoked from network); 17 Nov 2011 16:06:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 16:06:44 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHG76Ip029154
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 16:07:07 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHG760H011592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 16:07:06 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHG6xGu028333; Thu, 17 Nov 2011 10:06:59 -0600
Received: from [10.154.37.9] (/10.154.37.9)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 08:06:57 -0800
Message-ID: <4EC53119.7060307@oracle.com>
Date: Fri, 18 Nov 2011 00:06:49 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EC3B62F.6080702@oracle.com>	
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<1321526148.3664.263.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321526148.3664.263.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4EC5312C.0024,ss=1,re=-2.300,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: [Xen-devel] Re: [PATCH 1/3] xen/granttable: Introducing grant table
	V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1020048056=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

This is a multi-part message in MIME format.
--------------090106010607000406010701
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for your review, Ian.
See following,
>> -       } while ((nflags = sync_cmpxchg(&shared[ref].flags, flags, 0)) != flags);
>> +       } while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0))
>> +                       != flags);
>>     
>
> I think this is one of those cases where strictly adhering to an
> 80-column rule hurts the readability of the code.
>
> If you had left the static global as "shared" rather than
> "gnttab_shared" you wouldn't have this issue. If you want a more
> descriptive name why not just call it "gnttab"?
>
>   
Actually, whether the name is "gnttab_shared" or "shared" or "gnttab", 
the code line still breaks the 80-column rule.
>>         return 1;
>>  }
>> +
>> +int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
>> +{
>> +       return gnttab_interface.end_foreign_access_ref(ref, readonly);
>> +}
>>  EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);
>>
>>  void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
>> @@ -246,37 +309,45 @@ EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer);
>>  void gnttab_grant_foreign_transfer_ref(grant_ref_t ref, domid_t domid,
>>                                        unsigned long pfn)
>>  {
>> -       update_grant_entry(ref, domid, pfn, GTF_accept_transfer);
>> +       gnttab_interface.update_entry(ref, domid, pfn, GTF_accept_transfer);
>>  }
>>  EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer_ref);
>>
>> -unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
>> +static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
>>  {
>>         unsigned long frame;
>>         u16           flags;
>> +       u16          *pflags;
>> +
>> +       pflags = &gnttab_shared.v1[ref].flags;
>>     
>
> It would be nice if these refactoring bits could be separated out from
> the more mechanical renaming and abstracting to fn pointer aspects of
> the patch.
>   
I am not so sure about your meaning, do you mean change gnttab_shared 
back to shared?
>>         /*
>>          * If a transfer is not even yet started, try to reclaim the grant
>>          * reference and return failure (== 0).
>>          */
>> -       while (!((flags = shared[ref].flags) & GTF_transfer_committed)) {
>> -               if (sync_cmpxchg(&shared[ref].flags, flags, 0) == flags)
>> +       while (!((flags = *pflags) & GTF_transfer_committed)) {
>> +               if (sync_cmpxchg(pflags, flags, 0) == flags)
>>                         return 0;
>>                 cpu_relax();
>>         }
>>
>>         /* If a transfer is in progress then wait until it is completed. */
>>         while (!(flags & GTF_transfer_completed)) {
>> -               flags = shared[ref].flags;
>> +               flags = *pflags;
>>                 cpu_relax();
>>         }
>>
>>         rmb();  /* Read the frame number /after/ reading completion status. */
>> -       frame = shared[ref].frame;
>> +       frame = gnttab_shared.v1[ref].frame;
>>         BUG_ON(frame == 0);
>>
>>         return frame;
>>  }
>> +
>> +unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
>> +{
>> +       return gnttab_interface.end_foreign_transfer_ref(ref);
>> +}
>>  EXPORT_SYMBOL_GPL(gnttab_end_foreign_transfer_ref);
>>
>>  unsigned long gnttab_end_foreign_transfer(grant_ref_t ref)
>> @@ -520,6 +591,23 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>>  }
>>  EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
>>
>> +static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
>> +{
>> +       int rc;
>> +
>> +       rc = arch_gnttab_map_shared(frames, nr_gframes,
>> +                                   gnttab_max_grant_frames(),
>> +                                   &gnttab_shared.addr);
>> +       BUG_ON(rc);
>> +
>> +       return 0;
>> +}
>> +
>> +static void gnttab_unmap_frames_v1(void)
>> +{
>> +       arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
>> +}
>> +
>>  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>>  {
>>         struct gnttab_setup_table setup;
>> @@ -567,19 +655,33 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>>
>>         BUG_ON(rc || setup.status);
>>
>> -       rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
>> -                                   &shared);
>> -       BUG_ON(rc);
>> +       rc = gnttab_interface.map_frames(frames, nr_gframes);
>>     
>
> Nothing checks rc here now?
>
> In fact the gnttab_map_frames_v1 function has its own BUG_ON(rc) and
> always returns 0 if it returns at all so perhaps that hook should be
> returning void?
>   
Yes, it should be that if there is only v1 function existing.
However, I added returns 0 here in order to keep consistence with v2 
function of next patch. The function pointer type is: int 
(*map_frames)(....), and v2 function returning value is meaningful. The 
returning value directly decides returning value of gnttab_map. See 
following code in function gnttab_map of v2 patch:

        if (rc < 0)
                return rc;
        return 0;

If gnttab_map_frames_v1 returns void here, it is necessary to change it 
back(including "void (*map_frames)"  --> "int (*map_frames)") in next v2 
implementation patch. So I only added return 0 here.
>   
>>         kfree(frames);
>>
>>         return 0;
>>  }
>>
>> +static void gnttab_request_version(void)
>> +{
>> +       grant_table_version = 1;
>> +       gnttab_interface.map_frames = gnttab_map_frames_v1;
>> +       gnttab_interface.unmap_frames = gnttab_unmap_frames_v1;
>> +       gnttab_interface.update_entry = update_grant_entry_v1;
>> +       gnttab_interface.end_foreign_access_ref =
>> +                                       gnttab_end_foreign_access_ref_v1;
>> +       gnttab_interface.end_foreign_transfer_ref =
>> +                                       gnttab_end_foreign_transfer_ref_v1;
>> +       gnttab_interface.query_foreign_access = gnttab_query_foreign_access_v1;
>>     
>
> The more normal way to do this would be to make gnttab_interface a
> pointer, define gnttab_v1_ops and do:
> 	gnttab_interface = &gnttab_v1_ops;
> or if the pointer overhead is significant remove that and just do a
> struct assignment:
> 	gnttab_interface = gnttab_v1_ops;
>
>   
If using this way, we need two more public structures(gnttab_v1_ops and 
gnttab_v2_ops), and two more functions to initialize those two 
structures and then initialize the pointer gnttab_interface. It is more 
complicated, am i missing something?

.....
>> +/*
>>   * Bitfield values for update_pin_status.flags.
>>   */
>>   /* Map the grant entry for access by I/O devices. */
>> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
>> index 6a6e914..710afe0 100644
>> --- a/include/xen/interface/xen.h
>> +++ b/include/xen/interface/xen.h
>> @@ -523,6 +523,8 @@ struct tmem_op {
>>         } u;
>>  };
>>
>> +DEFINE_GUEST_HANDLE(uint64_t);
>>     
>
> The kernel uses uN style types rather than the uintN_t style ones,
> although include/xen/interface/grant_table.h seems not to adhere to that
> at the moment. It might be worth cleaning that up as you go passed.
>   
Thanks, I'd like to change it.

Thanks
Annie
>   
>> +
>>  #else /* __ASSEMBLY__ */
>>
>>  /* In assembly code we cannot use C numeric constant suffixes. */
>> --
>> 1.7.6.4
>>
>>     
>
>
>   

--------------090106010607000406010701
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks for your review, Ian.<br>
See following,<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">
-       } while ((nflags = sync_cmpxchg(&amp;shared[ref].flags, flags, 0)) != flags);
+       } while ((nflags = sync_cmpxchg(&amp;gnttab_shared.v1[ref].flags, flags, 0))
+                       != flags);
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I think this is one of those cases where strictly adhering to an
80-column rule hurts the readability of the code.

If you had left the static global as "shared" rather than
"gnttab_shared" you wouldn't have this issue. If you want a more
descriptive name why not just call it "gnttab"?

  </pre>
</blockquote>
Actually, whether the name is "gnttab_shared" or "shared" or "gnttab",
the code line still breaks the 80-column rule.<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">        return 1;
 }
+
+int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+{
+       return gnttab_interface.end_foreign_access_ref(ref, readonly);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);

 void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
@@ -246,37 +309,45 @@ EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer);
 void gnttab_grant_foreign_transfer_ref(grant_ref_t ref, domid_t domid,
                                       unsigned long pfn)
 {
-       update_grant_entry(ref, domid, pfn, GTF_accept_transfer);
+       gnttab_interface.update_entry(ref, domid, pfn, GTF_accept_transfer);
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer_ref);

-unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 {
        unsigned long frame;
        u16           flags;
+       u16          *pflags;
+
+       pflags = &amp;gnttab_shared.v1[ref].flags;
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It would be nice if these refactoring bits could be separated out from
the more mechanical renaming and abstracting to fn pointer aspects of
the patch.
  </pre>
</blockquote>
I am not so sure about your meaning, do you mean change gnttab_shared
back to shared?<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">        /*
         * If a transfer is not even yet started, try to reclaim the grant
         * reference and return failure (== 0).
         */
-       while (!((flags = shared[ref].flags) &amp; GTF_transfer_committed)) {
-               if (sync_cmpxchg(&amp;shared[ref].flags, flags, 0) == flags)
+       while (!((flags = *pflags) &amp; GTF_transfer_committed)) {
+               if (sync_cmpxchg(pflags, flags, 0) == flags)
                        return 0;
                cpu_relax();
        }

        /* If a transfer is in progress then wait until it is completed. */
        while (!(flags &amp; GTF_transfer_completed)) {
-               flags = shared[ref].flags;
+               flags = *pflags;
                cpu_relax();
        }

        rmb();  /* Read the frame number /after/ reading completion status. */
-       frame = shared[ref].frame;
+       frame = gnttab_shared.v1[ref].frame;
        BUG_ON(frame == 0);

        return frame;
 }
+
+unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+{
+       return gnttab_interface.end_foreign_transfer_ref(ref);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_transfer_ref);

 unsigned long gnttab_end_foreign_transfer(grant_ref_t ref)
@@ -520,6 +591,23 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);

+static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
+{
+       int rc;
+
+       rc = arch_gnttab_map_shared(frames, nr_gframes,
+                                   gnttab_max_grant_frames(),
+                                   &amp;gnttab_shared.addr);
+       BUG_ON(rc);
+
+       return 0;
+}
+
+static void gnttab_unmap_frames_v1(void)
+{
+       arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
        struct gnttab_setup_table setup;
@@ -567,19 +655,33 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)

        BUG_ON(rc || setup.status);

-       rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
-                                   &amp;shared);
-       BUG_ON(rc);
+       rc = gnttab_interface.map_frames(frames, nr_gframes);
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Nothing checks rc here now?

In fact the gnttab_map_frames_v1 function has its own BUG_ON(rc) and
always returns 0 if it returns at all so perhaps that hook should be
returning void?
  </pre>
</blockquote>
Yes, it should be that if there is only v1 function existing.<br>
However, I added returns 0 here in order to keep consistence with v2
function of next patch. The function pointer type is: int
(*map_frames)(....), and v2 function returning value is meaningful. The
returning value directly decides returning value of gnttab_map. See
following code in function gnttab_map of v2 patch:<br>
<br>
        if (rc &lt; 0)<br>
                return rc;<br>
        return 0;<br>
<br>
If gnttab_map_frames_v1
returns void here, it is necessary to change it back(including "void
(*map_frames)"  --&gt; "int (*map_frames)") in next v2 implementation
patch. So I only added return 0 here.<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">        kfree(frames);

        return 0;
 }

+static void gnttab_request_version(void)
+{
+       grant_table_version = 1;
+       gnttab_interface.map_frames = gnttab_map_frames_v1;
+       gnttab_interface.unmap_frames = gnttab_unmap_frames_v1;
+       gnttab_interface.update_entry = update_grant_entry_v1;
+       gnttab_interface.end_foreign_access_ref =
+                                       gnttab_end_foreign_access_ref_v1;
+       gnttab_interface.end_foreign_transfer_ref =
+                                       gnttab_end_foreign_transfer_ref_v1;
+       gnttab_interface.query_foreign_access = gnttab_query_foreign_access_v1;
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The more normal way to do this would be to make gnttab_interface a
pointer, define gnttab_v1_ops and do:
	gnttab_interface = &amp;gnttab_v1_ops;
or if the pointer overhead is significant remove that and just do a
struct assignment:
	gnttab_interface = gnttab_v1_ops;

  </pre>
</blockquote>
If using this way, we need two more public structures(gnttab_v1_ops and
gnttab_v2_ops), and two more functions to initialize those two
structures and then initialize the pointer gnttab_interface. It is more
complicated, am i missing something?<br>
<br>
.....<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">
+/*
  * Bitfield values for update_pin_status.flags.
  */
  /* Map the grant entry for access by I/O devices. */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..710afe0 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -523,6 +523,8 @@ struct tmem_op {
        } u;
 };

+DEFINE_GUEST_HANDLE(uint64_t);
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The kernel uses uN style types rather than the uintN_t style ones,
although include/xen/interface/grant_table.h seems not to adhere to that
at the moment. It might be worth cleaning that up as you go passed.
  </pre>
</blockquote>
Thanks, I'd like to change it.<br>
<br>
Thanks<br>
Annie<br>
<blockquote cite="mid1321526148.3664.263.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">+
 #else /* __ASSEMBLY__ */

 /* In assembly code we cannot use C numeric constant suffixes. */
--
1.7.6.4

    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
</body>
</html>

--------------090106010607000406010701--


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

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

--===============1020048056==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:17:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:17:29 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4eX-00029s-99
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4eC-0002ww-Un; Thu, 17 Nov 2011 08:17:09 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4aE-0002G2-Nw
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:13:05 -0800
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321546378!1989607!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3742 invoked from network); 17 Nov 2011 16:12:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:12:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="171006121"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 11:12:57 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 17 Nov 2011
	11:12:57 -0500
Message-ID: <4EC53288.5010400@citrix.com>
Date: Thu, 17 Nov 2011 16:12:56 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: refine EOI-ing of migrating
	level	interrupts
References: <4EC273B40200007800061145@nat28.tlf.novell.com>
In-Reply-To: <4EC273B40200007800061145@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/11/11 13:14, Jan Beulich wrote:
> Rather than going through all IO-APICs and calling io_apic_eoi_vector()
> for the vector in question, just use eoi_IO_APIC_irq().
>
> This in turn allows to eliminate quite a bit of other code.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Tested-and-acked-by: Andrew Cooper <andrew.cooper3@citrix.com> (tested
via backport to xen-4.1.x)

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -69,10 +69,6 @@ int __read_mostly nr_ioapics;
>  
>  #define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20)
>  
> -#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), -1)
> -#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin))
> -
> -
>  /*
>   * This is performance-critical, we want to do it O(1)
>   *
> @@ -213,21 +209,18 @@ static void ioapic_write_entry(
>      spin_unlock_irqrestore(&ioapic_lock, flags);
>  }
>  
> -/* EOI an IO-APIC entry.  One of vector or pin may be -1, indicating that
> - * it should be worked out using the other.  This function expect that the
> - * ioapic_lock is taken, and interrupts are disabled (or there is a good reason
> - * not to), and that if both pin and vector are passed, that they refer to the
> +/* EOI an IO-APIC entry.  Vector may be -1, indicating that it should be
> + * worked out using the pin.  This function expects that the ioapic_lock is
> + * being held, and interrupts are disabled (or there is a good reason not
> + * to), and that if both pin and vector are passed, that they refer to the
>   * same redirection entry in the IO-APIC. */
>  static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin)
>  {
> -    /* Ensure some useful information is passed in */
> -    BUG_ON( (vector == -1 && pin == -1) );
> -    
>      /* Prefer the use of the EOI register if available */
>      if ( ioapic_has_eoi_reg(apic) )
>      {
>          /* If vector is unknown, read it from the IO-APIC */
> -        if ( vector == -1 )
> +        if ( vector == IRQ_VECTOR_UNASSIGNED )
>              vector = __ioapic_read_entry(apic, pin, TRUE).vector;
>  
>          *(IO_APIC_BASE(apic)+16) = vector;
> @@ -239,42 +232,6 @@ static void __io_apic_eoi(unsigned int a
>          struct IO_APIC_route_entry entry;
>          bool_t need_to_unmask = 0;
>  
> -        /* If pin is unknown, search for it */
> -        if ( pin == -1 )
> -        {
> -            unsigned int p;
> -            for ( p = 0; p < nr_ioapic_entries[apic]; ++p )
> -            {
> -                entry = __ioapic_read_entry(apic, p, TRUE);
> -                if ( entry.vector == vector )
> -                {
> -                    pin = p;
> -                    /* break; */
> -
> -                    /* Here should be a break out of the loop, but at the 
> -                     * Xen code doesn't actually prevent multiple IO-APIC
> -                     * entries being assigned the same vector, so EOI all
> -                     * pins which have the correct vector.
> -                     *
> -                     * Remove the following code when the above assertion
> -                     * is fulfilled. */
> -                    __io_apic_eoi(apic, vector, p);
> -                }
> -            }
> -            
> -            /* If search fails, nothing to do */
> -
> -            /* if ( pin == -1 ) */
> -
> -            /* Because the loop wasn't broken out of (see comment above),
> -             * all relevant pins have been EOI, so we can always return.
> -             * 
> -             * Re-instate the if statement above when the Xen logic has been
> -             * fixed.*/
> -
> -            return;
> -        }
> -
>          entry = __ioapic_read_entry(apic, pin, TRUE);
>  
>          if ( ! entry.mask )
> @@ -301,17 +258,6 @@ static void __io_apic_eoi(unsigned int a
>      }
>  }
>  
> -/* EOI an IO-APIC entry.  One of vector or pin may be -1, indicating that
> - * it should be worked out using the other.  This function disables interrupts
> - * and takes the ioapic_lock */
> -static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin)
> -{
> -    unsigned int flags;
> -    spin_lock_irqsave(&ioapic_lock, flags);
> -    __io_apic_eoi(apic, vector, pin);
> -    spin_unlock_irqrestore(&ioapic_lock, flags);
> -}
> -
>  /*
>   * Saves all the IO-APIC RTE's
>   */
> @@ -1693,11 +1639,7 @@ static void end_level_ioapic_irq(struct 
>  
>      /* Manually EOI the old vector if we are moving to the new */
>      if ( vector && i != vector )
> -    {
> -        int ioapic;
> -        for (ioapic = 0; ioapic < nr_ioapics; ioapic++)
> -            io_apic_eoi_vector(ioapic, i);
> -    }
> +        eoi_IO_APIC_irq(desc);
>  
>      v = apic_read(APIC_TMR + ((i & ~0x1f) >> 1));
>  
>
>

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


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:17:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:17:29 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4eX-00029s-99
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:17:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4eC-0002ww-Un; Thu, 17 Nov 2011 08:17:09 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4aE-0002G2-Nw
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:13:05 -0800
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321546378!1989607!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3742 invoked from network); 17 Nov 2011 16:12:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:12:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,527,1315195200"; d="scan'208";a="171006121"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 11:12:57 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Thu, 17 Nov 2011
	11:12:57 -0500
Message-ID: <4EC53288.5010400@citrix.com>
Date: Thu, 17 Nov 2011 16:12:56 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: refine EOI-ing of migrating
	level	interrupts
References: <4EC273B40200007800061145@nat28.tlf.novell.com>
In-Reply-To: <4EC273B40200007800061145@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 15/11/11 13:14, Jan Beulich wrote:
> Rather than going through all IO-APICs and calling io_apic_eoi_vector()
> for the vector in question, just use eoi_IO_APIC_irq().
>
> This in turn allows to eliminate quite a bit of other code.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Tested-and-acked-by: Andrew Cooper <andrew.cooper3@citrix.com> (tested
via backport to xen-4.1.x)

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -69,10 +69,6 @@ int __read_mostly nr_ioapics;
>  
>  #define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20)
>  
> -#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), -1)
> -#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin))
> -
> -
>  /*
>   * This is performance-critical, we want to do it O(1)
>   *
> @@ -213,21 +209,18 @@ static void ioapic_write_entry(
>      spin_unlock_irqrestore(&ioapic_lock, flags);
>  }
>  
> -/* EOI an IO-APIC entry.  One of vector or pin may be -1, indicating that
> - * it should be worked out using the other.  This function expect that the
> - * ioapic_lock is taken, and interrupts are disabled (or there is a good reason
> - * not to), and that if both pin and vector are passed, that they refer to the
> +/* EOI an IO-APIC entry.  Vector may be -1, indicating that it should be
> + * worked out using the pin.  This function expects that the ioapic_lock is
> + * being held, and interrupts are disabled (or there is a good reason not
> + * to), and that if both pin and vector are passed, that they refer to the
>   * same redirection entry in the IO-APIC. */
>  static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin)
>  {
> -    /* Ensure some useful information is passed in */
> -    BUG_ON( (vector == -1 && pin == -1) );
> -    
>      /* Prefer the use of the EOI register if available */
>      if ( ioapic_has_eoi_reg(apic) )
>      {
>          /* If vector is unknown, read it from the IO-APIC */
> -        if ( vector == -1 )
> +        if ( vector == IRQ_VECTOR_UNASSIGNED )
>              vector = __ioapic_read_entry(apic, pin, TRUE).vector;
>  
>          *(IO_APIC_BASE(apic)+16) = vector;
> @@ -239,42 +232,6 @@ static void __io_apic_eoi(unsigned int a
>          struct IO_APIC_route_entry entry;
>          bool_t need_to_unmask = 0;
>  
> -        /* If pin is unknown, search for it */
> -        if ( pin == -1 )
> -        {
> -            unsigned int p;
> -            for ( p = 0; p < nr_ioapic_entries[apic]; ++p )
> -            {
> -                entry = __ioapic_read_entry(apic, p, TRUE);
> -                if ( entry.vector == vector )
> -                {
> -                    pin = p;
> -                    /* break; */
> -
> -                    /* Here should be a break out of the loop, but at the 
> -                     * Xen code doesn't actually prevent multiple IO-APIC
> -                     * entries being assigned the same vector, so EOI all
> -                     * pins which have the correct vector.
> -                     *
> -                     * Remove the following code when the above assertion
> -                     * is fulfilled. */
> -                    __io_apic_eoi(apic, vector, p);
> -                }
> -            }
> -            
> -            /* If search fails, nothing to do */
> -
> -            /* if ( pin == -1 ) */
> -
> -            /* Because the loop wasn't broken out of (see comment above),
> -             * all relevant pins have been EOI, so we can always return.
> -             * 
> -             * Re-instate the if statement above when the Xen logic has been
> -             * fixed.*/
> -
> -            return;
> -        }
> -
>          entry = __ioapic_read_entry(apic, pin, TRUE);
>  
>          if ( ! entry.mask )
> @@ -301,17 +258,6 @@ static void __io_apic_eoi(unsigned int a
>      }
>  }
>  
> -/* EOI an IO-APIC entry.  One of vector or pin may be -1, indicating that
> - * it should be worked out using the other.  This function disables interrupts
> - * and takes the ioapic_lock */
> -static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin)
> -{
> -    unsigned int flags;
> -    spin_lock_irqsave(&ioapic_lock, flags);
> -    __io_apic_eoi(apic, vector, pin);
> -    spin_unlock_irqrestore(&ioapic_lock, flags);
> -}
> -
>  /*
>   * Saves all the IO-APIC RTE's
>   */
> @@ -1693,11 +1639,7 @@ static void end_level_ioapic_irq(struct 
>  
>      /* Manually EOI the old vector if we are moving to the new */
>      if ( vector && i != vector )
> -    {
> -        int ioapic;
> -        for (ioapic = 0; ioapic < nr_ioapics; ioapic++)
> -            io_apic_eoi_vector(ioapic, i);
> -    }
> +        eoi_IO_APIC_irq(desc);
>  
>      v = apic_read(APIC_TMR + ((i & ~0x1f) >> 1));
>  
>
>

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


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:22:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:22:00 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4iu-0002A5-4s
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4iT-0003R0-QQ; Thu, 17 Nov 2011 08:21:34 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4eP-0002ze-KI
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:17:23 -0800
X-Env-Sender: yujiageng734@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321546637!4630253!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24203 invoked from network); 17 Nov 2011 16:17:18 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:17:18 -0000
Received: by iaby12 with SMTP id y12so3040617iab.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 08:17:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=OhN3fr9/ztW/XVH1wP6DlU/wPsTpzDm2Zw93thnQrkw=;
	b=p9fIQeZqgcyikDHJmX29RYB3eZ6eMnncK6eg6DEu5/w6uijE8mixFsxmc5O7KDvZas
	Q/khoU9osB9ftqzLGBuIaT3KQsIPHEOWlT1o6CVoK7OJ15zbTxpx+RKpe4pS0AlRYEEK
	QbN7FlQ1Lksqe3rbSe4SkXu9JekzzwinZMnNg=
MIME-Version: 1.0
Received: by 10.42.172.70 with SMTP id m6mr27048207icz.37.1321546635125; Thu,
	17 Nov 2011 08:17:15 -0800 (PST)
Received: by 10.42.170.197 with HTTP; Thu, 17 Nov 2011 08:17:15 -0800 (PST)
Date: Fri, 18 Nov 2011 00:17:15 +0800
Message-ID: <CAJ0pt17MtRWNa16NbsXbSm_zuvdYzS5DUZ7wZBeM6b_C+m3MGQ@mail.gmail.com>
From: Jiageng Yu <yujiageng734@gmail.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	"Xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Cc: 
Subject: [Xen-devel] Benchmarks of Linux based stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0258162412=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0258162412==
Content-Type: multipart/alternative; boundary=90e6ba6e8f60bda2ba04b1f08d03

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

Hi Samuel,

   Since the periodic achievement is obtained in Linux based stubdom
project, I am very interesting in the benchmarks of Linux stubdom. To have
a good comparison with mini-os based stubdom, I want to do the same
benchmarks as you did in
http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf.
Please offer me the tools and methods you had used to measure the mini-os
based stubdom. Any details would be thankful.

   Cheers!

Jiageng Yu.

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

Hi Samuel,<br><br> =C2=A0 =C2=A0Since the periodic achievement is obtained =
in Linux based stubdom project, I am very interesting in the benchmarks of =
Linux stubdom. To have a good comparison with mini-os based stubdom, I want=
 to do the same benchmarks as you did in <a href=3D"http://www.xen.org/file=
s/xensummitboston08/SamThibault_XenSummit.pdf">http://www.xen.org/files/xen=
summitboston08/SamThibault_XenSummit.pdf</a>. Please offer me the tools and=
 methods you had used to measure the mini-os based stubdom.=C2=A0Any detail=
s would be thankful.<div>
<br></div><div>=C2=A0 =C2=A0Cheers!</div><div><br></div><div>Jiageng Yu.</d=
iv>

--90e6ba6e8f60bda2ba04b1f08d03--


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

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

--===============0258162412==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:22:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:22:00 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4iu-0002A5-4s
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4iT-0003R0-QQ; Thu, 17 Nov 2011 08:21:34 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4eP-0002ze-KI
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:17:23 -0800
X-Env-Sender: yujiageng734@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321546637!4630253!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24203 invoked from network); 17 Nov 2011 16:17:18 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:17:18 -0000
Received: by iaby12 with SMTP id y12so3040617iab.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 08:17:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=OhN3fr9/ztW/XVH1wP6DlU/wPsTpzDm2Zw93thnQrkw=;
	b=p9fIQeZqgcyikDHJmX29RYB3eZ6eMnncK6eg6DEu5/w6uijE8mixFsxmc5O7KDvZas
	Q/khoU9osB9ftqzLGBuIaT3KQsIPHEOWlT1o6CVoK7OJ15zbTxpx+RKpe4pS0AlRYEEK
	QbN7FlQ1Lksqe3rbSe4SkXu9JekzzwinZMnNg=
MIME-Version: 1.0
Received: by 10.42.172.70 with SMTP id m6mr27048207icz.37.1321546635125; Thu,
	17 Nov 2011 08:17:15 -0800 (PST)
Received: by 10.42.170.197 with HTTP; Thu, 17 Nov 2011 08:17:15 -0800 (PST)
Date: Fri, 18 Nov 2011 00:17:15 +0800
Message-ID: <CAJ0pt17MtRWNa16NbsXbSm_zuvdYzS5DUZ7wZBeM6b_C+m3MGQ@mail.gmail.com>
From: Jiageng Yu <yujiageng734@gmail.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>, 
	"Xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Cc: 
Subject: [Xen-devel] Benchmarks of Linux based stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0258162412=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0258162412==
Content-Type: multipart/alternative; boundary=90e6ba6e8f60bda2ba04b1f08d03

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

Hi Samuel,

   Since the periodic achievement is obtained in Linux based stubdom
project, I am very interesting in the benchmarks of Linux stubdom. To have
a good comparison with mini-os based stubdom, I want to do the same
benchmarks as you did in
http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf.
Please offer me the tools and methods you had used to measure the mini-os
based stubdom. Any details would be thankful.

   Cheers!

Jiageng Yu.

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

Hi Samuel,<br><br> =C2=A0 =C2=A0Since the periodic achievement is obtained =
in Linux based stubdom project, I am very interesting in the benchmarks of =
Linux stubdom. To have a good comparison with mini-os based stubdom, I want=
 to do the same benchmarks as you did in <a href=3D"http://www.xen.org/file=
s/xensummitboston08/SamThibault_XenSummit.pdf">http://www.xen.org/files/xen=
summitboston08/SamThibault_XenSummit.pdf</a>. Please offer me the tools and=
 methods you had used to measure the mini-os based stubdom.=C2=A0Any detail=
s would be thankful.<div>
<br></div><div>=C2=A0 =C2=A0Cheers!</div><div><br></div><div>Jiageng Yu.</d=
iv>

--90e6ba6e8f60bda2ba04b1f08d03--


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

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

--===============0258162412==--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:31:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:31:18 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4ru-0002AV-Nb
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:31:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4ra-0004k5-56; Thu, 17 Nov 2011 08:30:58 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4qv-0004i6-ID
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:30:18 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321547371!63628123!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8751 invoked from network); 17 Nov 2011 16:29:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 16:29:32 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHGU3q6027204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 16:30:04 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHGU29R027436
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 16:30:03 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
	pAHGTvGB026700; Thu, 17 Nov 2011 10:29:57 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 08:29:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0EA9081489; Thu, 17 Nov 2011 11:29:56 -0500 (EST)
Date: Thu, 17 Nov 2011 11:29:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: annie li <annie.li@oracle.com>
Message-ID: <20111117162955.GA6758@phenom.dumpdata.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<1321526148.3664.263.camel@zakaz.uk.xensource.com>
	<4EC53119.7060307@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EC53119.7060307@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4EC5368E.00A4,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: [Xen-devel] Re: [PATCH 1/3] xen/granttable: Introducing grant table
	V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> >The more normal way to do this would be to make gnttab_interface a
> >pointer, define gnttab_v1_ops and do:
> >	gnttab_interface = &gnttab_v1_ops;
> >or if the pointer overhead is significant remove that and just do a
> >struct assignment:
> >	gnttab_interface = gnttab_v1_ops;
> >
> If using this way, we need two more public structures(gnttab_v1_ops
> and gnttab_v2_ops), and two more functions to initialize those two
> structures and then initialize the pointer gnttab_interface. It is
> more complicated, am i missing something?

Why two functions? I agree on the structures - but they need not to be
public (they can be static).

For a good example look at how apic_physflat is done.

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:31:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:31:18 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR4ru-0002AV-Nb
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:31:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR4ra-0004k5-56; Thu, 17 Nov 2011 08:30:58 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4qv-0004i6-ID
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:30:18 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321547371!63628123!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8751 invoked from network); 17 Nov 2011 16:29:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 16:29:32 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHGU3q6027204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 16:30:04 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHGU29R027436
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 16:30:03 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
	pAHGTvGB026700; Thu, 17 Nov 2011 10:29:57 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 08:29:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0EA9081489; Thu, 17 Nov 2011 11:29:56 -0500 (EST)
Date: Thu, 17 Nov 2011 11:29:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: annie li <annie.li@oracle.com>
Message-ID: <20111117162955.GA6758@phenom.dumpdata.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<1321526148.3664.263.camel@zakaz.uk.xensource.com>
	<4EC53119.7060307@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EC53119.7060307@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4EC5368E.00A4,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: [Xen-devel] Re: [PATCH 1/3] xen/granttable: Introducing grant table
	V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> >The more normal way to do this would be to make gnttab_interface a
> >pointer, define gnttab_v1_ops and do:
> >	gnttab_interface = &gnttab_v1_ops;
> >or if the pointer overhead is significant remove that and just do a
> >struct assignment:
> >	gnttab_interface = gnttab_v1_ops;
> >
> If using this way, we need two more public structures(gnttab_v1_ops
> and gnttab_v2_ops), and two more functions to initialize those two
> structures and then initialize the pointer gnttab_interface. It is
> more complicated, am i missing something?

Why two functions? I agree on the structures - but they need not to be
public (they can be static).

For a good example look at how apic_physflat is done.

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:41:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:41:20 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR51c-0002Ao-KA
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR51H-0005N5-Pk; Thu, 17 Nov 2011 08:41:00 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4zk-0005Jp-Vx
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:39:26 -0800
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321547961!4670946!1
X-Originating-IP: [192.134.164.82]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18654 invoked from network); 17 Nov 2011 16:39:21 -0000
Received: from mail1-relais-roc.national.inria.fr (HELO
	mail1-relais-roc.national.inria.fr) (192.134.164.82)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315173600"; d="scan'208";a="131201732"
Received: from nat-inria-bordeaux-53.bordeaux.inria.fr (HELO type.ipv6)
	([194.199.1.53])
	by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES256-SHA;
	17 Nov 2011 17:39:20 +0100
Received: from samy by type.ipv6 with local (Exim 4.77)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1RR4zg-0007J1-FY; Thu, 17 Nov 2011 17:39:20 +0100
Date: Thu, 17 Nov 2011 17:39:20 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Jiageng Yu <yujiageng734@gmail.com>
Message-ID: <20111117163920.GF9627@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Jiageng Yu <yujiageng734@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <CAJ0pt17MtRWNa16NbsXbSm_zuvdYzS5DUZ7wZBeM6b_C+m3MGQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAJ0pt17MtRWNa16NbsXbSm_zuvdYzS5DUZ7wZBeM6b_C+m3MGQ@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "Xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Re: Benchmarks of Linux based stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jiageng Yu, le Fri 18 Nov 2011 00:17:15 +0800, a écrit :
>    Since the periodic achievement is obtained in Linux based stubdom project, I
> am very interesting in the benchmarks of Linux stubdom. To have a good
> comparison with mini-os based stubdom, I want to do the same benchmarks as you
> did in http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf.
> Please offer me the tools and methods you had used to measure the mini-os based
> stubdom. Any details would be thankful.

There is not too much fancy in there :)

- Inb (Kcy) is maybe the fancy part: the measurement was made with
  assembly bits, basically: rdtsc; inb; rdtsc, i.e. something like:

  unsigned long t1, t2;
  __asm__ volatile("rdtsc" : "=A" (t1))
  inb(0x80);
  __asm__ volatile("rdtsc" : "=A" (t2))

- Boot time is from xm create up to "foo login:" prompt.
- Disk performance was measured as seen from the guest, I don't remember
  exactly how, probably with a simple program working on /dev/xvdb
  with O_DIRECT. The CPU% was read from xm top.
- Net performance was measure as seen from the guest, probably with
  netperf. The CPU% was also read from xm top. Note the use of the e1000
  virtual device, which iirc performed best at the time.

Samuel

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:41:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:41:20 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR51c-0002Ao-KA
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR51H-0005N5-Pk; Thu, 17 Nov 2011 08:41:00 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR4zk-0005Jp-Vx
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:39:26 -0800
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321547961!4670946!1
X-Originating-IP: [192.134.164.82]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18654 invoked from network); 17 Nov 2011 16:39:21 -0000
Received: from mail1-relais-roc.national.inria.fr (HELO
	mail1-relais-roc.national.inria.fr) (192.134.164.82)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315173600"; d="scan'208";a="131201732"
Received: from nat-inria-bordeaux-53.bordeaux.inria.fr (HELO type.ipv6)
	([194.199.1.53])
	by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES256-SHA;
	17 Nov 2011 17:39:20 +0100
Received: from samy by type.ipv6 with local (Exim 4.77)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1RR4zg-0007J1-FY; Thu, 17 Nov 2011 17:39:20 +0100
Date: Thu, 17 Nov 2011 17:39:20 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Jiageng Yu <yujiageng734@gmail.com>
Message-ID: <20111117163920.GF9627@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Jiageng Yu <yujiageng734@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <CAJ0pt17MtRWNa16NbsXbSm_zuvdYzS5DUZ7wZBeM6b_C+m3MGQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAJ0pt17MtRWNa16NbsXbSm_zuvdYzS5DUZ7wZBeM6b_C+m3MGQ@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "Xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] Re: Benchmarks of Linux based stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jiageng Yu, le Fri 18 Nov 2011 00:17:15 +0800, a écrit :
>    Since the periodic achievement is obtained in Linux based stubdom project, I
> am very interesting in the benchmarks of Linux stubdom. To have a good
> comparison with mini-os based stubdom, I want to do the same benchmarks as you
> did in http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf.
> Please offer me the tools and methods you had used to measure the mini-os based
> stubdom. Any details would be thankful.

There is not too much fancy in there :)

- Inb (Kcy) is maybe the fancy part: the measurement was made with
  assembly bits, basically: rdtsc; inb; rdtsc, i.e. something like:

  unsigned long t1, t2;
  __asm__ volatile("rdtsc" : "=A" (t1))
  inb(0x80);
  __asm__ volatile("rdtsc" : "=A" (t2))

- Boot time is from xm create up to "foo login:" prompt.
- Disk performance was measured as seen from the guest, I don't remember
  exactly how, probably with a simple program working on /dev/xvdb
  with O_DIRECT. The CPU% was read from xm top.
- Net performance was measure as seen from the guest, probably with
  netperf. The CPU% was also read from xm top. Note the use of the e1000
  virtual device, which iirc performed best at the time.

Samuel

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:46:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:46:44 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR56q-0002B1-2x
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR56S-0005rt-Lb; Thu, 17 Nov 2011 08:46:21 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR56L-0005qq-GA
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:46:13 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321548369!3933340!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30186 invoked from network); 17 Nov 2011 16:46:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:46:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315195200"; d="scan'208";a="19195567"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 11:46:08 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 11:46:08 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 447738ef67ea2690c8ea6684f2e0e0b3528ad446
Message-ID: <447738ef67ea2690c8ea.1321548235@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321548234@cosworth.uk.xensource.com>
References: <patchbomb.1321548234@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 16:43:55 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Move acpi_enabled out of hvm_info_table
	into xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321546881 0
# Node ID 447738ef67ea2690c8ea6684f2e0e0b3528ad446
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Move acpi_enabled out of hvm_info_table into xenstore

Since hvmloader has a xentore client, use a platform key in xenstore
to indicate whether ACPI is enabled or not rather than the shared
hvm_info_table structure.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r dbdc840f8f62 -r 447738ef67ea tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Thu Nov 17 16:21:21 2011 +0000
@@ -423,6 +423,7 @@ int main(void)
     const struct bios_config *bios;
     int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
     uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
+    int acpi_enabled;
 
     /* Initialise hypercall stubs with RET, rendering them no-ops. */
     memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
@@ -506,7 +507,9 @@ int main(void)
                                              option_rom_phys_addr);
     }
 
-    if ( hvm_info->acpi_enabled )
+    acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
+
+    if ( acpi_enabled )
     {
         struct xen_hvm_param p = {
             .domid = DOMID_SELF,
diff -r dbdc840f8f62 -r 447738ef67ea tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxc/xc_hvm_build.c	Thu Nov 17 16:21:21 2011 +0000
@@ -67,7 +67,6 @@ static void build_hvm_info(void *hvm_inf
     hvm_info->length = sizeof(struct hvm_info_table);
 
     /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->acpi_enabled = 1;
     hvm_info->apic_mode = 1;
     hvm_info->nr_vcpus = 1;
     memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
diff -r dbdc840f8f62 -r 447738ef67ea tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_create.c	Thu Nov 17 16:21:21 2011 +0000
@@ -188,6 +188,11 @@ int libxl__domain_build(libxl__gc *gc,
         vments[3] = "hvm";
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+
+        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents[0] = "platform/acpi";
+        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         ret = libxl__build_pv(gc, domid, info, state);
diff -r dbdc840f8f62 -r 447738ef67ea tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Nov 17 16:21:21 2011 +0000
@@ -248,7 +248,6 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = info->u.hvm.acpi;
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
diff -r dbdc840f8f62 -r 447738ef67ea tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Thu Nov 17 16:21:21 2011 +0000
@@ -996,7 +996,6 @@ static PyObject *pyxc_hvm_build(XcObject
     if ( va_map == NULL )
         return PyErr_SetFromErrno(xc_error_obj);
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = acpi;
     va_hvm->apic_mode    = apic;
     va_hvm->nr_vcpus     = vcpus;
     memcpy(va_hvm->vcpu_online, vcpu_avail, sizeof(vcpu_avail));
diff -r dbdc840f8f62 -r 447738ef67ea xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/public/hvm/hvm_info_table.h	Thu Nov 17 16:21:21 2011 +0000
@@ -37,9 +37,6 @@ struct hvm_info_table {
     uint32_t    length;
     uint8_t     checksum;
 
-    /* Should firmware build ACPI tables? */
-    uint8_t     acpi_enabled;
-
     /* Should firmware build APIC descriptors (APIC MADT / MP BIOS)? */
     uint8_t     apic_mode;
 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:46:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:46:44 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR56q-0002B1-2x
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR56S-0005rt-Lb; Thu, 17 Nov 2011 08:46:21 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR56L-0005qq-GA
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:46:13 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321548369!3933340!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30186 invoked from network); 17 Nov 2011 16:46:10 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:46:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315195200"; d="scan'208";a="19195567"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 11:46:08 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 11:46:08 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 447738ef67ea2690c8ea6684f2e0e0b3528ad446
Message-ID: <447738ef67ea2690c8ea.1321548235@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321548234@cosworth.uk.xensource.com>
References: <patchbomb.1321548234@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 16:43:55 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Move acpi_enabled out of hvm_info_table
	into xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321546881 0
# Node ID 447738ef67ea2690c8ea6684f2e0e0b3528ad446
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Move acpi_enabled out of hvm_info_table into xenstore

Since hvmloader has a xentore client, use a platform key in xenstore
to indicate whether ACPI is enabled or not rather than the shared
hvm_info_table structure.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r dbdc840f8f62 -r 447738ef67ea tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Thu Nov 17 16:21:21 2011 +0000
@@ -423,6 +423,7 @@ int main(void)
     const struct bios_config *bios;
     int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
     uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
+    int acpi_enabled;
 
     /* Initialise hypercall stubs with RET, rendering them no-ops. */
     memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
@@ -506,7 +507,9 @@ int main(void)
                                              option_rom_phys_addr);
     }
 
-    if ( hvm_info->acpi_enabled )
+    acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
+
+    if ( acpi_enabled )
     {
         struct xen_hvm_param p = {
             .domid = DOMID_SELF,
diff -r dbdc840f8f62 -r 447738ef67ea tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxc/xc_hvm_build.c	Thu Nov 17 16:21:21 2011 +0000
@@ -67,7 +67,6 @@ static void build_hvm_info(void *hvm_inf
     hvm_info->length = sizeof(struct hvm_info_table);
 
     /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->acpi_enabled = 1;
     hvm_info->apic_mode = 1;
     hvm_info->nr_vcpus = 1;
     memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
diff -r dbdc840f8f62 -r 447738ef67ea tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_create.c	Thu Nov 17 16:21:21 2011 +0000
@@ -188,6 +188,11 @@ int libxl__domain_build(libxl__gc *gc,
         vments[3] = "hvm";
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+
+        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents[0] = "platform/acpi";
+        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         ret = libxl__build_pv(gc, domid, info, state);
diff -r dbdc840f8f62 -r 447738ef67ea tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Nov 17 16:21:21 2011 +0000
@@ -248,7 +248,6 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = info->u.hvm.acpi;
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
diff -r dbdc840f8f62 -r 447738ef67ea tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Thu Nov 17 16:21:21 2011 +0000
@@ -996,7 +996,6 @@ static PyObject *pyxc_hvm_build(XcObject
     if ( va_map == NULL )
         return PyErr_SetFromErrno(xc_error_obj);
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = acpi;
     va_hvm->apic_mode    = apic;
     va_hvm->nr_vcpus     = vcpus;
     memcpy(va_hvm->vcpu_online, vcpu_avail, sizeof(vcpu_avail));
diff -r dbdc840f8f62 -r 447738ef67ea xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/public/hvm/hvm_info_table.h	Thu Nov 17 16:21:21 2011 +0000
@@ -37,9 +37,6 @@ struct hvm_info_table {
     uint32_t    length;
     uint8_t     checksum;
 
-    /* Should firmware build ACPI tables? */
-    uint8_t     acpi_enabled;
-
     /* Should firmware build APIC descriptors (APIC MADT / MP BIOS)? */
     uint8_t     apic_mode;
 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:48:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:48:18 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR58M-0002BF-3R
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR582-0006G0-0g; Thu, 17 Nov 2011 08:47:58 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR56c-0005u1-MT
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:46:31 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321548385!3026094!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24481 invoked from network); 17 Nov 2011 16:46:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:46:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315195200"; d="scan'208";a="171013164"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 11:46:08 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 11:46:08 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321548234@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 16:43:54 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] New ACPI configuration options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:48:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:48:18 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR58M-0002BF-3R
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR582-0006G0-0g; Thu, 17 Nov 2011 08:47:58 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR56c-0005u1-MT
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:46:31 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321548385!3026094!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24481 invoked from network); 17 Nov 2011 16:46:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:46:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315195200"; d="scan'208";a="171013164"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 11:46:08 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 11:46:08 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321548234@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 16:43:54 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] New ACPI configuration options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:49:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:49:11 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR59D-0002BS-2u
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:49:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR58q-0006dB-Nw; Thu, 17 Nov 2011 08:48:48 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR56d-0005uI-Fd
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:46:32 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321548385!3026094!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24513 invoked from network); 17 Nov 2011 16:46:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:46:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315195200"; d="scan'208";a="171013181"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 11:46:09 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 11:46:09 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: c25af1f86de1699ee36684e740a323adbcffdfb5
Message-ID: <c25af1f86de1699ee366.1321548236@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321548234@cosworth.uk.xensource.com>
References: <patchbomb.1321548234@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 16:43:56 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] Add configuration options to selectively
 disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321548043 0
# Node ID c25af1f86de1699ee36684e740a323adbcffdfb5
# Parent  447738ef67ea2690c8ea6684f2e0e0b3528ad446
Add configuration options to selectively disable S3 and S4 ACPI power states.

Introduce acpi_s3 and acpi_s4 configuration options (default=1). When one of these
parameters is 0 it causes removal of the respective package (_S3 or _S4) from the
DSDT thereby disabling that power state in the guest.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Thu Nov 17 16:40:43 2011 +0000
@@ -396,6 +396,8 @@ struct acpi_config {
     int dsdt_anycpu_len;
     unsigned char *dsdt_15cpu;
     int dsdt_15cpu_len;
+    int dsdt_s3_enabled;
+    int dsdt_s4_enabled;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Thu Nov 17 16:40:43 2011 +0000
@@ -274,6 +274,54 @@ static int construct_secondary_tables(un
     return nr_tables;
 }
 
+static uint8_t *find_name(uint8_t *dsdt, const char *prefix)
+{
+    int len = strlen(prefix);
+    int i;
+
+    for ( i = 0; i < ((struct acpi_header *)dsdt)->length - len; i++, dsdt++ )
+    {
+        if ( memcmp(dsdt, prefix, len) == 0 && *(dsdt - 1) == 0x08 )
+            return dsdt - 1;
+    }
+
+    return NULL;
+}
+
+static void remove_package(uint8_t *dsdt, const char *prefix)
+{
+    struct acpi_header *header = (struct acpi_header *)dsdt;
+    uint8_t *start = find_name(dsdt, prefix);
+    uint8_t *end = dsdt + header->length - 1;
+    uint8_t *package;
+    uint8_t *len;
+    uint8_t *next;
+
+    if ( start == NULL )
+        return;
+
+    package = start + 5; /* 1 byte op, 4 bytes payload */
+    if ( package > end )
+        return;
+    if ( *package != 0x12 )
+        return;
+
+    len = package + 1;
+    if ( package > end )
+        return;
+
+    next = package + 1 + *len; /* 1 byte op, len bytes payload */
+    if ( next > end + 1 )
+        return;
+
+    printf("DSDT: removing '%c%c%c%c' (%d bytes)\n",
+           *(start + 1), *(start + 2), *(start + 3), *(start + 4),
+           next - start);
+
+    memcpy(start, next, header->length - (next - dsdt));
+    header->length -= next - start;
+}
+
 void acpi_build_tables(struct acpi_config *config, unsigned int physical)
 {
     struct acpi_info *acpi_info;
@@ -310,19 +358,29 @@ void acpi_build_tables(struct acpi_confi
      */
     if ( hvm_info->nr_vcpus <= 15 && config->dsdt_15cpu)
     {
-        dsdt = mem_alloc(config->dsdt_15cpu_len, 16);
+        dsdt = mem_probe(config->dsdt_15cpu_len, 16);
         if (!dsdt) goto oom;
         memcpy(dsdt, config->dsdt_15cpu, config->dsdt_15cpu_len);
         nr_processor_objects = 15;
     }
     else
     {
-        dsdt = mem_alloc(config->dsdt_anycpu_len, 16);
+        dsdt = mem_probe(config->dsdt_anycpu_len, 16);
         if (!dsdt) goto oom;
         memcpy(dsdt, config->dsdt_anycpu, config->dsdt_anycpu_len);
         nr_processor_objects = HVM_MAX_VCPUS;
     }
 
+    if ( !config->dsdt_s3_enabled)
+        remove_package(dsdt, "_S3");
+    if ( !config->dsdt_s4_enabled)
+        remove_package(dsdt, "_S4");
+
+    set_checksum(dsdt,
+                 offsetof(struct acpi_header, checksum),
+                 ((struct acpi_header*)dsdt)->length);
+    mem_commit(dsdt, ((struct acpi_header*)dsdt)->length);
+
     /*
      * N.B. ACPI 1.0 operating systems may not handle FADT with revision 2
      * or above properly, notably Windows 2000, which tries to copy FADT
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/config.h	Thu Nov 17 16:40:43 2011 +0000
@@ -27,7 +27,7 @@ struct bios_config {
 
     void (*e820_setup)(void);
 
-    void (*acpi_build_tables)(void);
+    void (*acpi_build_tables)(int, int);
     void (*create_mp_tables)(void);
     void (*create_smbios_tables)(void);
     void (*create_pir_tables)(void);
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Thu Nov 17 16:40:43 2011 +0000
@@ -516,11 +516,17 @@ int main(void)
             .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
             .value = 1,
         };
+        int s3_enabled, s4_enabled;
+
+        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1);
+        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1);
 
         if ( bios->acpi_build_tables )
         {
-            printf("Loading ACPI ...\n");
-            bios->acpi_build_tables();
+            printf("Loading ACPI (S3=%s S4=%s) ...\n",
+                   (s3_enabled) ? "ON" : "OFF",
+                   (s4_enabled) ? "ON" : "OFF");
+            bios->acpi_build_tables(s3_enabled, s4_enabled);
         }
 
         acpi_enable_sci();
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/rombios.c
--- a/tools/firmware/hvmloader/rombios.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/rombios.c	Thu Nov 17 16:40:43 2011 +0000
@@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
     *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) = -checksum;
 }
 
-static void rombios_acpi_build_tables(void)
+static void rombios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     struct acpi_config config = {
         .dsdt_anycpu = dsdt_anycpu,
         .dsdt_anycpu_len = dsdt_anycpu_len,
         .dsdt_15cpu = dsdt_15cpu,
         .dsdt_15cpu_len = dsdt_15cpu_len,
+        .dsdt_s3_enabled = s3_enabled,
+        .dsdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/seabios.c
--- a/tools/firmware/hvmloader/seabios.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/seabios.c	Thu Nov 17 16:40:43 2011 +0000
@@ -91,7 +91,7 @@ static void add_table(uint32_t t)
     info->tables_nr++;
 }
 
-static void seabios_acpi_build_tables(void)
+static void seabios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     uint32_t rsdp = (uint32_t)scratch_alloc(sizeof(struct acpi_20_rsdp), 0);
     struct acpi_config config = {
@@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
         .dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
         .dsdt_15cpu = NULL,
         .dsdt_15cpu_len = 0,
+        .dsdt_s3_enabled = s3_enabled,
+        .dsdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, rsdp);
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Thu Nov 17 16:40:43 2011 +0000
@@ -352,28 +352,35 @@ xen_pfn_t mem_hole_alloc(uint32_t nr_mfn
     return hvm_info->reserved_mem_pgstart;
 }
 
-void *mem_alloc(uint32_t size, uint32_t align)
+void *mem_probe(uint32_t size, uint32_t align)
 {
-    uint32_t s, e;
+    uint32_t r, s, e;
+    void *base;
 
     /* Align to at least 16 bytes. */
     if ( align < 16 )
         align = 16;
 
-    s = (reserve + align) & ~(align - 1);
+    r = reserve;
+    s = (r + align) & ~(align - 1);
     e = s + size - 1;
 
+    base = (void *)s;
+
     BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);
 
-    while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
+    while ( (r >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
     {
-        reserve += PAGE_SIZE;
-        mem_hole_populate_ram(reserve >> PAGE_SHIFT, 1);
+        r += PAGE_SIZE;
+        mem_hole_populate_ram(r >> PAGE_SHIFT, 1);
     }
 
-    reserve = e;
+    return (void *)(unsigned long)s;
+}
 
-    return (void *)(unsigned long)s;
+void mem_commit(void *base, uint32_t size)
+{
+    reserve = (uint32_t)base + size;
 }
 
 void *scratch_alloc(uint32_t size, uint32_t align)
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Thu Nov 17 16:40:43 2011 +0000
@@ -172,7 +172,16 @@ void mem_hole_populate_ram(xen_pfn_t mfn
 xen_pfn_t mem_hole_alloc(uint32_t nr_mfns);
 
 /* Allocate memory in a reserved region below 4GB. */
-void *mem_alloc(uint32_t size, uint32_t align);
+void *mem_probe(uint32_t size, uint32_t align);
+void mem_commit(void *base, uint32_t size);
+
+static inline void *mem_alloc(uint32_t size, uint32_t align)
+{
+    void *base = mem_probe(size, align);
+    mem_commit(base, size);
+    return base;
+}
+
 #define virt_to_phys(v) ((unsigned long)(v))
 
 /* Allocate memory in a scratch region */
diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/libxl/libxl_create.c	Thu Nov 17 16:40:43 2011 +0000
@@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
+        b_info->u.hvm.acpi_s3 = 1;
+        b_info->u.hvm.acpi_s4 = 1;
         b_info->u.hvm.nx = 1;
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
@@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[2] = "platform/acpi_s3";
+        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[4] = "platform/acpi_s4";
+        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Nov 17 16:40:43 2011 +0000
@@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
+                                       ("acpi_s3", bool),
+                                       ("acpi_s4", bool),
                                        ("nx", bool),
                                        ("viridian", bool),
                                        ("timeoffset", string),
diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 16:40:43 2011 +0000
@@ -683,6 +683,10 @@ static void parse_config_data(const char
             b_info->u.hvm.apic = l;
         if (!xlu_cfg_get_long (config, "acpi", &l))
             b_info->u.hvm.acpi = l;
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+            b_info->u.hvm.acpi_s3 = l;
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+            b_info->u.hvm.acpi_s4 = l;
         if (!xlu_cfg_get_long (config, "nx", &l))
             b_info->u.hvm.nx = l;
         if (!xlu_cfg_get_long (config, "viridian", &l))

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:49:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:49:11 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR59D-0002BS-2u
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:49:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR58q-0006dB-Nw; Thu, 17 Nov 2011 08:48:48 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR56d-0005uI-Fd
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:46:32 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321548385!3026094!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24513 invoked from network); 17 Nov 2011 16:46:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:46:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315195200"; d="scan'208";a="171013181"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 11:46:09 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 11:46:09 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: c25af1f86de1699ee36684e740a323adbcffdfb5
Message-ID: <c25af1f86de1699ee366.1321548236@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321548234@cosworth.uk.xensource.com>
References: <patchbomb.1321548234@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 17 Nov 2011 16:43:56 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] Add configuration options to selectively
 disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321548043 0
# Node ID c25af1f86de1699ee36684e740a323adbcffdfb5
# Parent  447738ef67ea2690c8ea6684f2e0e0b3528ad446
Add configuration options to selectively disable S3 and S4 ACPI power states.

Introduce acpi_s3 and acpi_s4 configuration options (default=1). When one of these
parameters is 0 it causes removal of the respective package (_S3 or _S4) from the
DSDT thereby disabling that power state in the guest.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Thu Nov 17 16:40:43 2011 +0000
@@ -396,6 +396,8 @@ struct acpi_config {
     int dsdt_anycpu_len;
     unsigned char *dsdt_15cpu;
     int dsdt_15cpu_len;
+    int dsdt_s3_enabled;
+    int dsdt_s4_enabled;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Thu Nov 17 16:40:43 2011 +0000
@@ -274,6 +274,54 @@ static int construct_secondary_tables(un
     return nr_tables;
 }
 
+static uint8_t *find_name(uint8_t *dsdt, const char *prefix)
+{
+    int len = strlen(prefix);
+    int i;
+
+    for ( i = 0; i < ((struct acpi_header *)dsdt)->length - len; i++, dsdt++ )
+    {
+        if ( memcmp(dsdt, prefix, len) == 0 && *(dsdt - 1) == 0x08 )
+            return dsdt - 1;
+    }
+
+    return NULL;
+}
+
+static void remove_package(uint8_t *dsdt, const char *prefix)
+{
+    struct acpi_header *header = (struct acpi_header *)dsdt;
+    uint8_t *start = find_name(dsdt, prefix);
+    uint8_t *end = dsdt + header->length - 1;
+    uint8_t *package;
+    uint8_t *len;
+    uint8_t *next;
+
+    if ( start == NULL )
+        return;
+
+    package = start + 5; /* 1 byte op, 4 bytes payload */
+    if ( package > end )
+        return;
+    if ( *package != 0x12 )
+        return;
+
+    len = package + 1;
+    if ( package > end )
+        return;
+
+    next = package + 1 + *len; /* 1 byte op, len bytes payload */
+    if ( next > end + 1 )
+        return;
+
+    printf("DSDT: removing '%c%c%c%c' (%d bytes)\n",
+           *(start + 1), *(start + 2), *(start + 3), *(start + 4),
+           next - start);
+
+    memcpy(start, next, header->length - (next - dsdt));
+    header->length -= next - start;
+}
+
 void acpi_build_tables(struct acpi_config *config, unsigned int physical)
 {
     struct acpi_info *acpi_info;
@@ -310,19 +358,29 @@ void acpi_build_tables(struct acpi_confi
      */
     if ( hvm_info->nr_vcpus <= 15 && config->dsdt_15cpu)
     {
-        dsdt = mem_alloc(config->dsdt_15cpu_len, 16);
+        dsdt = mem_probe(config->dsdt_15cpu_len, 16);
         if (!dsdt) goto oom;
         memcpy(dsdt, config->dsdt_15cpu, config->dsdt_15cpu_len);
         nr_processor_objects = 15;
     }
     else
     {
-        dsdt = mem_alloc(config->dsdt_anycpu_len, 16);
+        dsdt = mem_probe(config->dsdt_anycpu_len, 16);
         if (!dsdt) goto oom;
         memcpy(dsdt, config->dsdt_anycpu, config->dsdt_anycpu_len);
         nr_processor_objects = HVM_MAX_VCPUS;
     }
 
+    if ( !config->dsdt_s3_enabled)
+        remove_package(dsdt, "_S3");
+    if ( !config->dsdt_s4_enabled)
+        remove_package(dsdt, "_S4");
+
+    set_checksum(dsdt,
+                 offsetof(struct acpi_header, checksum),
+                 ((struct acpi_header*)dsdt)->length);
+    mem_commit(dsdt, ((struct acpi_header*)dsdt)->length);
+
     /*
      * N.B. ACPI 1.0 operating systems may not handle FADT with revision 2
      * or above properly, notably Windows 2000, which tries to copy FADT
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/config.h	Thu Nov 17 16:40:43 2011 +0000
@@ -27,7 +27,7 @@ struct bios_config {
 
     void (*e820_setup)(void);
 
-    void (*acpi_build_tables)(void);
+    void (*acpi_build_tables)(int, int);
     void (*create_mp_tables)(void);
     void (*create_smbios_tables)(void);
     void (*create_pir_tables)(void);
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Thu Nov 17 16:40:43 2011 +0000
@@ -516,11 +516,17 @@ int main(void)
             .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
             .value = 1,
         };
+        int s3_enabled, s4_enabled;
+
+        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1);
+        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1);
 
         if ( bios->acpi_build_tables )
         {
-            printf("Loading ACPI ...\n");
-            bios->acpi_build_tables();
+            printf("Loading ACPI (S3=%s S4=%s) ...\n",
+                   (s3_enabled) ? "ON" : "OFF",
+                   (s4_enabled) ? "ON" : "OFF");
+            bios->acpi_build_tables(s3_enabled, s4_enabled);
         }
 
         acpi_enable_sci();
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/rombios.c
--- a/tools/firmware/hvmloader/rombios.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/rombios.c	Thu Nov 17 16:40:43 2011 +0000
@@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
     *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) = -checksum;
 }
 
-static void rombios_acpi_build_tables(void)
+static void rombios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     struct acpi_config config = {
         .dsdt_anycpu = dsdt_anycpu,
         .dsdt_anycpu_len = dsdt_anycpu_len,
         .dsdt_15cpu = dsdt_15cpu,
         .dsdt_15cpu_len = dsdt_15cpu_len,
+        .dsdt_s3_enabled = s3_enabled,
+        .dsdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/seabios.c
--- a/tools/firmware/hvmloader/seabios.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/seabios.c	Thu Nov 17 16:40:43 2011 +0000
@@ -91,7 +91,7 @@ static void add_table(uint32_t t)
     info->tables_nr++;
 }
 
-static void seabios_acpi_build_tables(void)
+static void seabios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     uint32_t rsdp = (uint32_t)scratch_alloc(sizeof(struct acpi_20_rsdp), 0);
     struct acpi_config config = {
@@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
         .dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
         .dsdt_15cpu = NULL,
         .dsdt_15cpu_len = 0,
+        .dsdt_s3_enabled = s3_enabled,
+        .dsdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, rsdp);
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Thu Nov 17 16:40:43 2011 +0000
@@ -352,28 +352,35 @@ xen_pfn_t mem_hole_alloc(uint32_t nr_mfn
     return hvm_info->reserved_mem_pgstart;
 }
 
-void *mem_alloc(uint32_t size, uint32_t align)
+void *mem_probe(uint32_t size, uint32_t align)
 {
-    uint32_t s, e;
+    uint32_t r, s, e;
+    void *base;
 
     /* Align to at least 16 bytes. */
     if ( align < 16 )
         align = 16;
 
-    s = (reserve + align) & ~(align - 1);
+    r = reserve;
+    s = (r + align) & ~(align - 1);
     e = s + size - 1;
 
+    base = (void *)s;
+
     BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);
 
-    while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
+    while ( (r >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
     {
-        reserve += PAGE_SIZE;
-        mem_hole_populate_ram(reserve >> PAGE_SHIFT, 1);
+        r += PAGE_SIZE;
+        mem_hole_populate_ram(r >> PAGE_SHIFT, 1);
     }
 
-    reserve = e;
+    return (void *)(unsigned long)s;
+}
 
-    return (void *)(unsigned long)s;
+void mem_commit(void *base, uint32_t size)
+{
+    reserve = (uint32_t)base + size;
 }
 
 void *scratch_alloc(uint32_t size, uint32_t align)
diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Thu Nov 17 16:40:43 2011 +0000
@@ -172,7 +172,16 @@ void mem_hole_populate_ram(xen_pfn_t mfn
 xen_pfn_t mem_hole_alloc(uint32_t nr_mfns);
 
 /* Allocate memory in a reserved region below 4GB. */
-void *mem_alloc(uint32_t size, uint32_t align);
+void *mem_probe(uint32_t size, uint32_t align);
+void mem_commit(void *base, uint32_t size);
+
+static inline void *mem_alloc(uint32_t size, uint32_t align)
+{
+    void *base = mem_probe(size, align);
+    mem_commit(base, size);
+    return base;
+}
+
 #define virt_to_phys(v) ((unsigned long)(v))
 
 /* Allocate memory in a scratch region */
diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/libxl/libxl_create.c	Thu Nov 17 16:40:43 2011 +0000
@@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
+        b_info->u.hvm.acpi_s3 = 1;
+        b_info->u.hvm.acpi_s4 = 1;
         b_info->u.hvm.nx = 1;
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
@@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[2] = "platform/acpi_s3";
+        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[4] = "platform/acpi_s4";
+        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Nov 17 16:40:43 2011 +0000
@@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
+                                       ("acpi_s3", bool),
+                                       ("acpi_s4", bool),
                                        ("nx", bool),
                                        ("viridian", bool),
                                        ("timeoffset", string),
diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 17 16:21:21 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 16:40:43 2011 +0000
@@ -683,6 +683,10 @@ static void parse_config_data(const char
             b_info->u.hvm.apic = l;
         if (!xlu_cfg_get_long (config, "acpi", &l))
             b_info->u.hvm.acpi = l;
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+            b_info->u.hvm.acpi_s3 = l;
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+            b_info->u.hvm.acpi_s4 = l;
         if (!xlu_cfg_get_long (config, "nx", &l))
             b_info->u.hvm.nx = l;
         if (!xlu_cfg_get_long (config, "viridian", &l))

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:51:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:51:53 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5Bp-0002Bs-5j
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5BW-0007mv-UO; Thu, 17 Nov 2011 08:51:35 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR57x-0006Ep-0U
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:47:53 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1321548469!3572973!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23067 invoked from network); 17 Nov 2011 16:47:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:47:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315180800"; 
   d="scan'208";a="8995205"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 16:47:49 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 17 Nov 2011
	16:47:49 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Thu, 17 Nov 2011 16:47:56 +0000
Thread-Topic: [PATCH 0 of 2] New ACPI configuration options
Thread-Index: AcylSGhe9e7VYtbdThCUtZYHhXmpFQAACIgQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B4543AB6E9@LONPMAILBOX01.citrite.net>
References: <patchbomb.1321548234@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321548234@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 
Subject: [Xen-devel] RE: [PATCH 0 of 2] New ACPI configuration options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For some reason this email seems to have been sent empty. The test should b=
e:

This patch series adds the ability to selectively disable the S3 and S4 ACP=
I power states for HVM guests.
Since there is a general move towards retiring the hvm_info_table structure=
, the first patch moves the acpi_enabled flag out of the hvm_info_table and=
 into a xenstore key (platform/acpi).
The second patch then introduces the acpi_s3 and acpi_s4 configuration para=
meters to the xl config file (default=3D1). These result in population of n=
ew platform/acpi_s3 and platform/acpi_s4 xenstore keys. hvmloader then read=
s these keys and will remove the respective package(s) from the DSDT if eit=
her/both of them are zero.

Apologies for that.

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 17 November 2011 16:44
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH 0 of 2] New ACPI configuration options
>=20


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:51:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:51:53 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5Bp-0002Bs-5j
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5BW-0007mv-UO; Thu, 17 Nov 2011 08:51:35 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR57x-0006Ep-0U
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:47:53 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1321548469!3572973!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23067 invoked from network); 17 Nov 2011 16:47:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:47:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315180800"; 
   d="scan'208";a="8995205"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 16:47:49 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 17 Nov 2011
	16:47:49 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Thu, 17 Nov 2011 16:47:56 +0000
Thread-Topic: [PATCH 0 of 2] New ACPI configuration options
Thread-Index: AcylSGhe9e7VYtbdThCUtZYHhXmpFQAACIgQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B4543AB6E9@LONPMAILBOX01.citrite.net>
References: <patchbomb.1321548234@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321548234@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 
Subject: [Xen-devel] RE: [PATCH 0 of 2] New ACPI configuration options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For some reason this email seems to have been sent empty. The test should b=
e:

This patch series adds the ability to selectively disable the S3 and S4 ACP=
I power states for HVM guests.
Since there is a general move towards retiring the hvm_info_table structure=
, the first patch moves the acpi_enabled flag out of the hvm_info_table and=
 into a xenstore key (platform/acpi).
The second patch then introduces the acpi_s3 and acpi_s4 configuration para=
meters to the xl config file (default=3D1). These result in population of n=
ew platform/acpi_s3 and platform/acpi_s4 xenstore keys. hvmloader then read=
s these keys and will remove the respective package(s) from the DSDT if eit=
her/both of them are zero.

Apologies for that.

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 17 November 2011 16:44
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH 0 of 2] New ACPI configuration options
>=20


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:52:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:52:36 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5CW-0002C5-Pd
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5CF-0008B7-66; Thu, 17 Nov 2011 08:52:19 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR59Y-0006vL-QH
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:49:33 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321548569!3967421!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4706 invoked from network); 17 Nov 2011 16:49:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 16:49:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 17 Nov 2011 16:50:46 +0000
Message-Id: <4EC549280200007800061AC5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 17 Nov 2011 16:49:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Backport per-device vector map patches to xen
 4.1.3
References: <201110271607.52785.wei.wang2@amd.com>
	<20111117160244.GA6667@phenom.dumpdata.com>
In-Reply-To: <20111117160244.GA6667@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: George@acsinet12.oracle.com, Keir Fraser <keir@xen.org>,
	Dunlap <George.Dunlap@eu.citrix.com>,
	Wei Huang2 <Wei.Huang2@amd.com>, Jacob Shin <Jacob.Shin@amd.com>,
	Wei Wang2 <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.11.11 at 17:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> =
wrote:
> On Thu, Oct 27, 2011 at 04:07:51PM +0200, Wei Wang2 wrote:
>> Recently we found an issue in xen 4.1. Under heavy I/O stress such =
as=20
> running=20
>> bonnie++, Dom0 would lost its hard disk with lots of I/O errors. We =
found=20
>> that some PCI-E devices was using the same vector as SMBus on AMD =
platforms=20
>> and George' patch set that enables per-device vector map can fix =
this=20
>> problem.
>>=20
>> Following patches have been back ported and tested by Jacob and Wei H. =
=20
>> Please apply them to Xen 4.1.3=20
>=20
> Can they be applied please? I've been running these without hiccups =
for=20
> well,
> since they were posted. On both AMD and Intel boxes.
>=20
> So, Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks to Keir, they're already in - c/s 23177:9a38e30e5459.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:52:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:52:36 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5CW-0002C5-Pd
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5CF-0008B7-66; Thu, 17 Nov 2011 08:52:19 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR59Y-0006vL-QH
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:49:33 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321548569!3967421!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4706 invoked from network); 17 Nov 2011 16:49:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 16:49:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 17 Nov 2011 16:50:46 +0000
Message-Id: <4EC549280200007800061AC5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 17 Nov 2011 16:49:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Backport per-device vector map patches to xen
 4.1.3
References: <201110271607.52785.wei.wang2@amd.com>
	<20111117160244.GA6667@phenom.dumpdata.com>
In-Reply-To: <20111117160244.GA6667@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: George@acsinet12.oracle.com, Keir Fraser <keir@xen.org>,
	Dunlap <George.Dunlap@eu.citrix.com>,
	Wei Huang2 <Wei.Huang2@amd.com>, Jacob Shin <Jacob.Shin@amd.com>,
	Wei Wang2 <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.11.11 at 17:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> =
wrote:
> On Thu, Oct 27, 2011 at 04:07:51PM +0200, Wei Wang2 wrote:
>> Recently we found an issue in xen 4.1. Under heavy I/O stress such =
as=20
> running=20
>> bonnie++, Dom0 would lost its hard disk with lots of I/O errors. We =
found=20
>> that some PCI-E devices was using the same vector as SMBus on AMD =
platforms=20
>> and George' patch set that enables per-device vector map can fix =
this=20
>> problem.
>>=20
>> Following patches have been back ported and tested by Jacob and Wei H. =
=20
>> Please apply them to Xen 4.1.3=20
>=20
> Can they be applied please? I've been running these without hiccups =
for=20
> well,
> since they were posted. On both AMD and Intel boxes.
>=20
> So, Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks to Keir, they're already in - c/s 23177:9a38e30e5459.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:53:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:53:23 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5DG-0002CI-RV
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:53:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5Cy-00006b-N1; Thu, 17 Nov 2011 08:53:04 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with smtp (Exim 4.43) id 1RR5CF-0008Af-Pd
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:52:20 -0800
X-Env-Sender: 327801865@qq.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321548735!4638853!1
X-Originating-IP: [64.71.138.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21326 invoked from network); 17 Nov 2011 16:52:16 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-11.tower-21.messagelabs.com with SMTP;
	17 Nov 2011 16:52:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1321548735; bh=3qeZoox1mxIhUL7rgOJz5bjmmRs7Q0DDLBEoRaqyP38=;
	h=X-QQ-SSF:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:X-QQ-STYLE:
	X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=EXDVmL4f3PnOGWX6D99oSS1Q+hBfmaEEUnnwXUAkcen+U+ZoyQbZmC9m0484TFMIP
	/wNEqza/T7Iqw841xxoQ+PAE1O4Zha/iq5cuftV5JpVnc9yeO3GH3jEMuKjCtb8
X-QQ-SSF: 00000000000000F0000000000000000
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 124.205.244.142
X-QQ-STYLE: 
X-QQ-mid: webmail73t1321548733t2113263
From: "=?gbk?B?wu3Sqw==?=" <327801865@qq.com>
To: "=?gbk?B?WGVuLWRldmVs?=" <Xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Fri, 18 Nov 2011 00:52:13 +0800
X-Priority: 3
Message-ID: <tencent_1975194D595A261C1C28650E@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Cc: 
Subject: [Xen-devel] HVM (hypercall_grant_table_op) Problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0261196887=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============0261196887==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EC53BBD_087D72C8_1D2EF2CB"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

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

SGk6DQogICAgIEkgbW9kaWZpZWQgdGhlIG5ldGZvbnQuYyBvZiBMaW51eCBIVk0gZG9tVSBp
bnN0YWxsZWQgUFZvbkhWTS5JbiBpdCwgSSBjYWxsIGh5cGVyY2FsbF9ncmFudF90YWJsZV9v
cA0KIChHTlRUQUJPUF9tYXBfZ3JhbnRfcmVmLi4uKSwgdGhlbiBkb20wIHNodXRkb3duIGFu
ZCByZXN0YXJ0IGF0IG9uY2UuDQogICAgIEknbSBjb25mdXNlZCBhYm91dCB0aGlzLg0KICAg
ICBCZWZvcmUgWGVuIDMuNC4zLCBYZW4vYXJjaC94ODYvSFZNL2h2bS5jIGxvb2sgbGlrZSB0
aGlzOg0KIHN0YXRpYyBsb25nIGh2bV9ncmFudF90YWJsZV9vcCh1bnNpZ25lZCBpbnQgY21k
LCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIHVvcCwgdW5zaWduZWQgaW50IGNvdW50KQ0Kew0K
ICAgIGlmICggKGNtZCAhPSBHTlRUQUJPUF9xdWVyeV9zaXplKSAmJiAoY21kICE9IEdOVFRB
Qk9QX3NldHVwX3RhYmxlKSApDQogICAgICAgIHJldHVybiAtRU5PU1lTOyAvKiBhbGwgb3Ro
ZXIgY29tbWFuZHMgbmVlZCBhdWRpdGluZyAqLw0KICAgIHJldHVybiBkb19ncmFudF90YWJs
ZV9vcChjbWQsIHVvcCwgY291bnQpOw0KfQ0KICAgICBJIGtub3cgaXQgaGFkbid0IHN1cHBv
cnQgYWxsIGdyYW50X3RhYmxlX29wIGJ1dCBvbmx5IHR3bzpHTlRUQUJPUF9xdWVyeV9zaXpl
IGFuZCBHTlRUQUJPUF9zZXR1cF90YWJsZS4NCiAgDQogICAgIE5vdywgYWZ0ZXIgWGVuNC4w
LjAgYW5kIGxhdGVyLCBpdCBsb29rIGxpa2UgYmVsb3c6DQogc3RhdGljIGxvbmcgaHZtX2dy
YW50X3RhYmxlX29wKCB1bnNpZ25lZCBpbnQgY21kLCBYRU5fR1VFU1RfSEFORExFKHZvaWQp
IHVvcCwgdW5zaWduZWQgaW50IGNvdW50KQ0Kew0KICAgIGlmICggIWdyYW50X3RhYmxlX29w
X2lzX2FsbG93ZWQoY21kKSApDQogICAgICAgIHJldHVybiAtRU5PU1lTOyAvKiBhbGwgb3Ro
ZXIgY29tbWFuZHMgbmVlZCBhdWRpdGluZyAqLw0KICAgIHJldHVybiBkb19ncmFudF90YWJs
ZV9vcChjbWQsIHVvcCwgY291bnQpOw0KfQ0KIHN0YXRpYyBpbnQgZ3JhbnRfdGFibGVfb3Bf
aXNfYWxsb3dlZCh1bnNpZ25lZCBpbnQgY21kKQ0Kew0KICAgIHN3aXRjaCAoY21kKSB7DQog
ICAgY2FzZSBHTlRUQUJPUF9xdWVyeV9zaXplOg0KICAgIGNhc2UgR05UVEFCT1Bfc2V0dXBf
dGFibGU6DQogICAgY2FzZSBHTlRUQUJPUF9zZXRfdmVyc2lvbjoNCiAgICBjYXNlIEdOVFRB
Qk9QX2NvcHk6DQogICAgY2FzZSBHTlRUQUJPUF9tYXBfZ3JhbnRfcmVmOg0KICAgIGNhc2Ug
R05UVEFCT1BfdW5tYXBfZ3JhbnRfcmVmOg0KICAgICAgICByZXR1cm4gMTsNCiAgICBkZWZh
dWx0Og0KICAgICAgICAvKiBhbGwgb3RoZXIgY29tbWFuZHMgbmVlZCBhdWRpdGluZyAqLw0K
ICAgICAgICByZXR1cm4gMDsNCiAgICB9DQp9DQogICAgIEZyb20gYWJvdmUsIEkgY29uY2x1
ZGUgdGhhdCBJIGNhbiBtYXAgYSBIVk0ncyBwYWdlIHRvIGFub3RoZXIgSFZNLCBqdXN0IGxp
a2UgdHdvIFBWcy4gDQogQW0gSSB3cm9uZz8gV2hvIGNhbiBnaXZlIG1lIHNvbWUgc3VnZ2Vz
dGlvbj8=

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

PERJVj5IaTo8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgbW9kaWZpZWQgdGhl
IG5ldGZvbnQuYyBvZiBMaW51eCBIVk0gZG9tVSBpbnN0YWxsZWQgUFZvbkhWTS5JbiBpdCwg
SSBjYWxsIGh5cGVyY2FsbF9ncmFudF90YWJsZV9vcDwvRElWPg0KPERJVj4oR05UVEFCT1Bf
bWFwX2dyYW50X3JlZi4uLiksIHRoZW4gZG9tMCBzaHV0ZG93biBhbmQgcmVzdGFydCBhdCBv
bmNlLjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgSSdtIGNvbmZ1c2VkIGFib3V0
IHRoaXMuPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyBCZWZvcmUgWGVuIDMuNC4z
LCBYZW4vYXJjaC94ODYvSFZNL2h2bS5jIGxvb2sgbGlrZSB0aGlzOjwvRElWPg0KPERJVj5z
dGF0aWMgbG9uZyBodm1fZ3JhbnRfdGFibGVfb3AodW5zaWduZWQgaW50IGNtZCwgWEVOX0dV
RVNUX0hBTkRMRSh2b2lkKSB1b3AsIHVuc2lnbmVkIGludCBjb3VudCk8QlI+ezxCUj4mbmJz
cDsmbmJzcDsmbmJzcDsgaWYgKCAoY21kICE9IEdOVFRBQk9QX3F1ZXJ5X3NpemUpICZhbXA7
JmFtcDsgKGNtZCAhPSBHTlRUQUJPUF9zZXR1cF90YWJsZSkgKTxCUj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmV0dXJuIC1FTk9TWVM7IC8qIGFsbCBv
dGhlciBjb21tYW5kcyBuZWVkIGF1ZGl0aW5nICovPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBy
ZXR1cm4gZG9fZ3JhbnRfdGFibGVfb3AoY21kLCB1b3AsIGNvdW50KTs8QlI+fTwvRElWPg0K
PERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgSSBrbm93IGl0IGhhZG4ndCBzdXBwb3J0IGFsbCBn
cmFudF90YWJsZV9vcCBidXQgb25seSB0d286R05UVEFCT1BfcXVlcnlfc2l6ZSBhbmQgR05U
VEFCT1Bfc2V0dXBfdGFibGUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJz
cDsmbmJzcDsmbmJzcDsgTm93LCBhZnRlciBYZW40LjAuMCBhbmQgbGF0ZXIsIGl0IGxvb2sg
bGlrZSBiZWxvdzo8L0RJVj4NCjxESVY+c3RhdGljIGxvbmcgaHZtX2dyYW50X3RhYmxlX29w
KCB1bnNpZ25lZCBpbnQgY21kLCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIHVvcCwgdW5zaWdu
ZWQgaW50IGNvdW50KTxCUj57PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBpZiAoICFncmFudF90
YWJsZV9vcF9pc19hbGxvd2VkKGNtZCkgKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgcmV0dXJuIC1FTk9TWVM7IC8qIGFsbCBvdGhlciBjb21tYW5k
cyBuZWVkIGF1ZGl0aW5nICovPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyByZXR1cm4gZG9fZ3Jh
bnRfdGFibGVfb3AoY21kLCB1b3AsIGNvdW50KTs8QlI+fTwvRElWPg0KPERJVj5zdGF0aWMg
aW50IGdyYW50X3RhYmxlX29wX2lzX2FsbG93ZWQodW5zaWduZWQgaW50IGNtZCk8QlI+ezxC
Uj4mbmJzcDsmbmJzcDsmbmJzcDsgc3dpdGNoIChjbWQpIHs8QlI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGNhc2UgR05UVEFCT1BfcXVlcnlfc2l6ZTo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNh
c2UgR05UVEFCT1Bfc2V0dXBfdGFibGU6PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBjYXNlIEdO
VFRBQk9QX3NldF92ZXJzaW9uOjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgY2FzZSBHTlRUQUJP
UF9jb3B5OjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgY2FzZSBHTlRUQUJPUF9tYXBfZ3JhbnRf
cmVmOjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgY2FzZSBHTlRUQUJPUF91bm1hcF9ncmFudF9y
ZWY6PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXR1
cm4gMTs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmF1bHQ6PEJSPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvKiBhbGwgb3RoZXIgY29tbWFuZHMgbmVl
ZCBhdWRpdGluZyAqLzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgcmV0dXJuIDA7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyB9PEJSPn08L0RJVj4NCjxE
SVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZyb20gYWJvdmUsIEkgY29uY2x1ZGUgdGhhdCBJIGNh
biBtYXAgYSBIVk0ncyBwYWdlIHRvIGFub3RoZXIgSFZNLCBqdXN0IGxpa2UgdHdvIFBWcy4g
PC9ESVY+DQo8RElWPkFtIEkgd3Jvbmc/IFdobyBjYW4gZ2l2ZSBtZSBzb21lIHN1Z2dlc3Rp
b24/PC9ESVY+

------=_NextPart_4EC53BBD_087D72C8_1D2EF2CB--



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

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

--===============0261196887==--



From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:53:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:53:23 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5DG-0002CI-RV
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:53:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5Cy-00006b-N1; Thu, 17 Nov 2011 08:53:04 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with smtp (Exim 4.43) id 1RR5CF-0008Af-Pd
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:52:20 -0800
X-Env-Sender: 327801865@qq.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321548735!4638853!1
X-Originating-IP: [64.71.138.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21326 invoked from network); 17 Nov 2011 16:52:16 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-11.tower-21.messagelabs.com with SMTP;
	17 Nov 2011 16:52:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1321548735; bh=3qeZoox1mxIhUL7rgOJz5bjmmRs7Q0DDLBEoRaqyP38=;
	h=X-QQ-SSF:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:X-QQ-STYLE:
	X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer;
	b=EXDVmL4f3PnOGWX6D99oSS1Q+hBfmaEEUnnwXUAkcen+U+ZoyQbZmC9m0484TFMIP
	/wNEqza/T7Iqw841xxoQ+PAE1O4Zha/iq5cuftV5JpVnc9yeO3GH3jEMuKjCtb8
X-QQ-SSF: 00000000000000F0000000000000000
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 124.205.244.142
X-QQ-STYLE: 
X-QQ-mid: webmail73t1321548733t2113263
From: "=?gbk?B?wu3Sqw==?=" <327801865@qq.com>
To: "=?gbk?B?WGVuLWRldmVs?=" <Xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Fri, 18 Nov 2011 00:52:13 +0800
X-Priority: 3
Message-ID: <tencent_1975194D595A261C1C28650E@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Cc: 
Subject: [Xen-devel] HVM (hypercall_grant_table_op) Problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0261196887=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============0261196887==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4EC53BBD_087D72C8_1D2EF2CB"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

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

SGk6DQogICAgIEkgbW9kaWZpZWQgdGhlIG5ldGZvbnQuYyBvZiBMaW51eCBIVk0gZG9tVSBp
bnN0YWxsZWQgUFZvbkhWTS5JbiBpdCwgSSBjYWxsIGh5cGVyY2FsbF9ncmFudF90YWJsZV9v
cA0KIChHTlRUQUJPUF9tYXBfZ3JhbnRfcmVmLi4uKSwgdGhlbiBkb20wIHNodXRkb3duIGFu
ZCByZXN0YXJ0IGF0IG9uY2UuDQogICAgIEknbSBjb25mdXNlZCBhYm91dCB0aGlzLg0KICAg
ICBCZWZvcmUgWGVuIDMuNC4zLCBYZW4vYXJjaC94ODYvSFZNL2h2bS5jIGxvb2sgbGlrZSB0
aGlzOg0KIHN0YXRpYyBsb25nIGh2bV9ncmFudF90YWJsZV9vcCh1bnNpZ25lZCBpbnQgY21k
LCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIHVvcCwgdW5zaWduZWQgaW50IGNvdW50KQ0Kew0K
ICAgIGlmICggKGNtZCAhPSBHTlRUQUJPUF9xdWVyeV9zaXplKSAmJiAoY21kICE9IEdOVFRB
Qk9QX3NldHVwX3RhYmxlKSApDQogICAgICAgIHJldHVybiAtRU5PU1lTOyAvKiBhbGwgb3Ro
ZXIgY29tbWFuZHMgbmVlZCBhdWRpdGluZyAqLw0KICAgIHJldHVybiBkb19ncmFudF90YWJs
ZV9vcChjbWQsIHVvcCwgY291bnQpOw0KfQ0KICAgICBJIGtub3cgaXQgaGFkbid0IHN1cHBv
cnQgYWxsIGdyYW50X3RhYmxlX29wIGJ1dCBvbmx5IHR3bzpHTlRUQUJPUF9xdWVyeV9zaXpl
IGFuZCBHTlRUQUJPUF9zZXR1cF90YWJsZS4NCiAgDQogICAgIE5vdywgYWZ0ZXIgWGVuNC4w
LjAgYW5kIGxhdGVyLCBpdCBsb29rIGxpa2UgYmVsb3c6DQogc3RhdGljIGxvbmcgaHZtX2dy
YW50X3RhYmxlX29wKCB1bnNpZ25lZCBpbnQgY21kLCBYRU5fR1VFU1RfSEFORExFKHZvaWQp
IHVvcCwgdW5zaWduZWQgaW50IGNvdW50KQ0Kew0KICAgIGlmICggIWdyYW50X3RhYmxlX29w
X2lzX2FsbG93ZWQoY21kKSApDQogICAgICAgIHJldHVybiAtRU5PU1lTOyAvKiBhbGwgb3Ro
ZXIgY29tbWFuZHMgbmVlZCBhdWRpdGluZyAqLw0KICAgIHJldHVybiBkb19ncmFudF90YWJs
ZV9vcChjbWQsIHVvcCwgY291bnQpOw0KfQ0KIHN0YXRpYyBpbnQgZ3JhbnRfdGFibGVfb3Bf
aXNfYWxsb3dlZCh1bnNpZ25lZCBpbnQgY21kKQ0Kew0KICAgIHN3aXRjaCAoY21kKSB7DQog
ICAgY2FzZSBHTlRUQUJPUF9xdWVyeV9zaXplOg0KICAgIGNhc2UgR05UVEFCT1Bfc2V0dXBf
dGFibGU6DQogICAgY2FzZSBHTlRUQUJPUF9zZXRfdmVyc2lvbjoNCiAgICBjYXNlIEdOVFRB
Qk9QX2NvcHk6DQogICAgY2FzZSBHTlRUQUJPUF9tYXBfZ3JhbnRfcmVmOg0KICAgIGNhc2Ug
R05UVEFCT1BfdW5tYXBfZ3JhbnRfcmVmOg0KICAgICAgICByZXR1cm4gMTsNCiAgICBkZWZh
dWx0Og0KICAgICAgICAvKiBhbGwgb3RoZXIgY29tbWFuZHMgbmVlZCBhdWRpdGluZyAqLw0K
ICAgICAgICByZXR1cm4gMDsNCiAgICB9DQp9DQogICAgIEZyb20gYWJvdmUsIEkgY29uY2x1
ZGUgdGhhdCBJIGNhbiBtYXAgYSBIVk0ncyBwYWdlIHRvIGFub3RoZXIgSFZNLCBqdXN0IGxp
a2UgdHdvIFBWcy4gDQogQW0gSSB3cm9uZz8gV2hvIGNhbiBnaXZlIG1lIHNvbWUgc3VnZ2Vz
dGlvbj8=

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

PERJVj5IaTo8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgbW9kaWZpZWQgdGhl
IG5ldGZvbnQuYyBvZiBMaW51eCBIVk0gZG9tVSBpbnN0YWxsZWQgUFZvbkhWTS5JbiBpdCwg
SSBjYWxsIGh5cGVyY2FsbF9ncmFudF90YWJsZV9vcDwvRElWPg0KPERJVj4oR05UVEFCT1Bf
bWFwX2dyYW50X3JlZi4uLiksIHRoZW4gZG9tMCBzaHV0ZG93biBhbmQgcmVzdGFydCBhdCBv
bmNlLjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgSSdtIGNvbmZ1c2VkIGFib3V0
IHRoaXMuPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyBCZWZvcmUgWGVuIDMuNC4z
LCBYZW4vYXJjaC94ODYvSFZNL2h2bS5jIGxvb2sgbGlrZSB0aGlzOjwvRElWPg0KPERJVj5z
dGF0aWMgbG9uZyBodm1fZ3JhbnRfdGFibGVfb3AodW5zaWduZWQgaW50IGNtZCwgWEVOX0dV
RVNUX0hBTkRMRSh2b2lkKSB1b3AsIHVuc2lnbmVkIGludCBjb3VudCk8QlI+ezxCUj4mbmJz
cDsmbmJzcDsmbmJzcDsgaWYgKCAoY21kICE9IEdOVFRBQk9QX3F1ZXJ5X3NpemUpICZhbXA7
JmFtcDsgKGNtZCAhPSBHTlRUQUJPUF9zZXR1cF90YWJsZSkgKTxCUj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmV0dXJuIC1FTk9TWVM7IC8qIGFsbCBv
dGhlciBjb21tYW5kcyBuZWVkIGF1ZGl0aW5nICovPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBy
ZXR1cm4gZG9fZ3JhbnRfdGFibGVfb3AoY21kLCB1b3AsIGNvdW50KTs8QlI+fTwvRElWPg0K
PERJVj4mbmJzcDsmbmJzcDsmbmJzcDsgSSBrbm93IGl0IGhhZG4ndCBzdXBwb3J0IGFsbCBn
cmFudF90YWJsZV9vcCBidXQgb25seSB0d286R05UVEFCT1BfcXVlcnlfc2l6ZSBhbmQgR05U
VEFCT1Bfc2V0dXBfdGFibGUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJz
cDsmbmJzcDsmbmJzcDsgTm93LCBhZnRlciBYZW40LjAuMCBhbmQgbGF0ZXIsIGl0IGxvb2sg
bGlrZSBiZWxvdzo8L0RJVj4NCjxESVY+c3RhdGljIGxvbmcgaHZtX2dyYW50X3RhYmxlX29w
KCB1bnNpZ25lZCBpbnQgY21kLCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIHVvcCwgdW5zaWdu
ZWQgaW50IGNvdW50KTxCUj57PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBpZiAoICFncmFudF90
YWJsZV9vcF9pc19hbGxvd2VkKGNtZCkgKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgcmV0dXJuIC1FTk9TWVM7IC8qIGFsbCBvdGhlciBjb21tYW5k
cyBuZWVkIGF1ZGl0aW5nICovPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyByZXR1cm4gZG9fZ3Jh
bnRfdGFibGVfb3AoY21kLCB1b3AsIGNvdW50KTs8QlI+fTwvRElWPg0KPERJVj5zdGF0aWMg
aW50IGdyYW50X3RhYmxlX29wX2lzX2FsbG93ZWQodW5zaWduZWQgaW50IGNtZCk8QlI+ezxC
Uj4mbmJzcDsmbmJzcDsmbmJzcDsgc3dpdGNoIChjbWQpIHs8QlI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGNhc2UgR05UVEFCT1BfcXVlcnlfc2l6ZTo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNh
c2UgR05UVEFCT1Bfc2V0dXBfdGFibGU6PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBjYXNlIEdO
VFRBQk9QX3NldF92ZXJzaW9uOjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgY2FzZSBHTlRUQUJP
UF9jb3B5OjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgY2FzZSBHTlRUQUJPUF9tYXBfZ3JhbnRf
cmVmOjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgY2FzZSBHTlRUQUJPUF91bm1hcF9ncmFudF9y
ZWY6PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXR1
cm4gMTs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmF1bHQ6PEJSPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvKiBhbGwgb3RoZXIgY29tbWFuZHMgbmVl
ZCBhdWRpdGluZyAqLzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgcmV0dXJuIDA7PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyB9PEJSPn08L0RJVj4NCjxE
SVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZyb20gYWJvdmUsIEkgY29uY2x1ZGUgdGhhdCBJIGNh
biBtYXAgYSBIVk0ncyBwYWdlIHRvIGFub3RoZXIgSFZNLCBqdXN0IGxpa2UgdHdvIFBWcy4g
PC9ESVY+DQo8RElWPkFtIEkgd3Jvbmc/IFdobyBjYW4gZ2l2ZSBtZSBzb21lIHN1Z2dlc3Rp
b24/PC9ESVY+

------=_NextPart_4EC53BBD_087D72C8_1D2EF2CB--



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

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

--===============0261196887==--



From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:56:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:56:32 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5GK-0002CV-C0
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:56:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5G2-0000Y4-Tg; Thu, 17 Nov 2011 08:56:14 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5Fv-0000X9-GT
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:56:08 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1321548964!3905258!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32706 invoked from network); 17 Nov 2011 16:56:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:56:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315180800"; 
   d="scan'208";a="8995430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 16:56:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 16:56:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Thu, 17 Nov 2011 16:55:59 +0000
In-Reply-To: <4EC53119.7060307@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<1321526148.3664.263.camel@zakaz.uk.xensource.com>
	<4EC53119.7060307@oracle.com>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321548960.3664.283.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Durrant <Paul.Durrant@citrix.com>, Paul
Subject: [Xen-devel] Re: [PATCH 1/3] xen/granttable: Introducing grant table
	V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-17 at 16:06 +0000, annie li wrote:
> Thanks for your review, Ian.
> See following,
> > > -       } while ((nflags = sync_cmpxchg(&shared[ref].flags, flags, 0)) != flags);
> > > +       } while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0))
> > > +                       != flags);
> > >     
> > 
> > I think this is one of those cases where strictly adhering to an
> > 80-column rule hurts the readability of the code.
> > 
> > If you had left the static global as "shared" rather than
> > "gnttab_shared" you wouldn't have this issue. If you want a more
> > descriptive name why not just call it "gnttab"?
> > 
> >   
> Actually, whether the name is "gnttab_shared" or "shared" or "gnttab",
> the code line still breaks the 80-column rule.

My point about strictly adhering to the 80-column limit still stands.

> > > return 1;
> > >  }
> > > +
> > > +int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
> > > +{
> > > +       return gnttab_interface.end_foreign_access_ref(ref, readonly);
> > > +}
> > >  EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);
> > > 
> > >  void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
> > > @@ -246,37 +309,45 @@ EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer);
> > >  void gnttab_grant_foreign_transfer_ref(grant_ref_t ref, domid_t domid,
> > >                                        unsigned long pfn)
> > >  {
> > > -       update_grant_entry(ref, domid, pfn, GTF_accept_transfer);
> > > +       gnttab_interface.update_entry(ref, domid, pfn, GTF_accept_transfer);
> > >  }
> > >  EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer_ref);
> > > 
> > > -unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
> > > +static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
> > >  {
> > >         unsigned long frame;
> > >         u16           flags;
> > > +       u16          *pflags;
> > > +
> > > +       pflags = &gnttab_shared.v1[ref].flags;
> > >     
> > 
> > It would be nice if these refactoring bits could be separated out from
> > the more mechanical renaming and abstracting to fn pointer aspects of
> > the patch.
> >   
> I am not so sure about your meaning, do you mean change gnttab_shared
> back to shared?

I mean that this patch combines a bunch of renaming, an abstraction to
function pointers and other refactoring such as this which actually
change behaviour (or might). It's easier to review if the purely
mechanical stuff (like renaming or adding a layer of function pointers)
is split out from changes like this one.

> > > /*
> > >          * If a transfer is not even yet started, try to reclaim the grant
> > >          * reference and return failure (== 0).
> > >          */
> > > -       while (!((flags = shared[ref].flags) & GTF_transfer_committed)) {
> > > -               if (sync_cmpxchg(&shared[ref].flags, flags, 0) == flags)
> > > +       while (!((flags = *pflags) & GTF_transfer_committed)) {
> > > +               if (sync_cmpxchg(pflags, flags, 0) == flags)
> > >                         return 0;
> > >                 cpu_relax();
> > >         }
> > > 
> > >         /* If a transfer is in progress then wait until it is completed. */
> > >         while (!(flags & GTF_transfer_completed)) {
> > > -               flags = shared[ref].flags;
> > > +               flags = *pflags;
> > >                 cpu_relax();
> > >         }
> > > 
> > >         rmb();  /* Read the frame number /after/ reading completion status. */
> > > -       frame = shared[ref].frame;
> > > +       frame = gnttab_shared.v1[ref].frame;
> > >         BUG_ON(frame == 0);
> > > 
> > >         return frame;
> > >  }
> > > +
> > > +unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
> > > +{
> > > +       return gnttab_interface.end_foreign_transfer_ref(ref);
> > > +}
> > >  EXPORT_SYMBOL_GPL(gnttab_end_foreign_transfer_ref);
> > > 
> > >  unsigned long gnttab_end_foreign_transfer(grant_ref_t ref)
> > > @@ -520,6 +591,23 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
> > >  }
> > >  EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
> > > 
> > > +static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
> > > +{
> > > +       int rc;
> > > +
> > > +       rc = arch_gnttab_map_shared(frames, nr_gframes,
> > > +                                   gnttab_max_grant_frames(),
> > > +                                   &gnttab_shared.addr);
> > > +       BUG_ON(rc);
> > > +
> > > +       return 0;
> > > +}
> > > +
> > > +static void gnttab_unmap_frames_v1(void)
> > > +{
> > > +       arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
> > > +}
> > > +
> > >  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
> > >  {
> > >         struct gnttab_setup_table setup;
> > > @@ -567,19 +655,33 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
> > > 
> > >         BUG_ON(rc || setup.status);
> > > 
> > > -       rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
> > > -                                   &shared);
> > > -       BUG_ON(rc);
> > > +       rc = gnttab_interface.map_frames(frames, nr_gframes);
> > >     
> > 
> > Nothing checks rc here now?
> > 
> > In fact the gnttab_map_frames_v1 function has its own BUG_ON(rc) and
> > always returns 0 if it returns at all so perhaps that hook should be
> > returning void?
> >   
> Yes, it should be that if there is only v1 function existing.
> However, I added returns 0 here in order to keep consistence with v2
> function of next patch. The function pointer type is: int
> (*map_frames)(....), and v2 function returning value is meaningful.
> The returning value directly decides returning value of gnttab_map.
> See following code in function gnttab_map of v2 patch:
> 
>         if (rc < 0)
>                 return rc;
>         return 0;

Can rc ever be +ve? Doesn't look like it, in which case this is the same
as "return rc".

> If gnttab_map_frames_v1 returns void here, it is necessary to change
> it back(including "void (*map_frames)"  --> "int (*map_frames)") in
> next v2 implementation patch. So I only added return 0 here.

OK.

> 
> .....
> > > +/*
> > >   * Bitfield values for update_pin_status.flags.
> > >   */
> > >   /* Map the grant entry for access by I/O devices. */
> > > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> > > index 6a6e914..710afe0 100644
> > > --- a/include/xen/interface/xen.h
> > > +++ b/include/xen/interface/xen.h
> > > @@ -523,6 +523,8 @@ struct tmem_op {
> > >         } u;
> > >  };
> > > 
> > > +DEFINE_GUEST_HANDLE(uint64_t);
> > >     
> > 
> > The kernel uses uN style types rather than the uintN_t style ones,
> > although include/xen/interface/grant_table.h seems not to adhere to that
> > at the moment. It might be worth cleaning that up as you go passed.
> >   
> Thanks, I'd like to change it.
> 
> Thanks
> Annie
> > > +
> > >  #else /* __ASSEMBLY__ */
> > > 
> > >  /* In assembly code we cannot use C numeric constant suffixes. */
> > > --
> > > 1.7.6.4
> > > 
> > >     
> > 
> > 
> >   



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 16:56:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 16:56:32 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5GK-0002CV-C0
	for archives@lists.xen.org; Thu, 17 Nov 2011 16:56:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5G2-0000Y4-Tg; Thu, 17 Nov 2011 08:56:14 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5Fv-0000X9-GT
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 08:56:08 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1321548964!3905258!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32706 invoked from network); 17 Nov 2011 16:56:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 16:56:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315180800"; 
   d="scan'208";a="8995430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 16:56:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 16:56:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Thu, 17 Nov 2011 16:55:59 +0000
In-Reply-To: <4EC53119.7060307@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<1321526148.3664.263.camel@zakaz.uk.xensource.com>
	<4EC53119.7060307@oracle.com>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321548960.3664.283.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Durrant <Paul.Durrant@citrix.com>, Paul
Subject: [Xen-devel] Re: [PATCH 1/3] xen/granttable: Introducing grant table
	V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-17 at 16:06 +0000, annie li wrote:
> Thanks for your review, Ian.
> See following,
> > > -       } while ((nflags = sync_cmpxchg(&shared[ref].flags, flags, 0)) != flags);
> > > +       } while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0))
> > > +                       != flags);
> > >     
> > 
> > I think this is one of those cases where strictly adhering to an
> > 80-column rule hurts the readability of the code.
> > 
> > If you had left the static global as "shared" rather than
> > "gnttab_shared" you wouldn't have this issue. If you want a more
> > descriptive name why not just call it "gnttab"?
> > 
> >   
> Actually, whether the name is "gnttab_shared" or "shared" or "gnttab",
> the code line still breaks the 80-column rule.

My point about strictly adhering to the 80-column limit still stands.

> > > return 1;
> > >  }
> > > +
> > > +int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
> > > +{
> > > +       return gnttab_interface.end_foreign_access_ref(ref, readonly);
> > > +}
> > >  EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);
> > > 
> > >  void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
> > > @@ -246,37 +309,45 @@ EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer);
> > >  void gnttab_grant_foreign_transfer_ref(grant_ref_t ref, domid_t domid,
> > >                                        unsigned long pfn)
> > >  {
> > > -       update_grant_entry(ref, domid, pfn, GTF_accept_transfer);
> > > +       gnttab_interface.update_entry(ref, domid, pfn, GTF_accept_transfer);
> > >  }
> > >  EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer_ref);
> > > 
> > > -unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
> > > +static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
> > >  {
> > >         unsigned long frame;
> > >         u16           flags;
> > > +       u16          *pflags;
> > > +
> > > +       pflags = &gnttab_shared.v1[ref].flags;
> > >     
> > 
> > It would be nice if these refactoring bits could be separated out from
> > the more mechanical renaming and abstracting to fn pointer aspects of
> > the patch.
> >   
> I am not so sure about your meaning, do you mean change gnttab_shared
> back to shared?

I mean that this patch combines a bunch of renaming, an abstraction to
function pointers and other refactoring such as this which actually
change behaviour (or might). It's easier to review if the purely
mechanical stuff (like renaming or adding a layer of function pointers)
is split out from changes like this one.

> > > /*
> > >          * If a transfer is not even yet started, try to reclaim the grant
> > >          * reference and return failure (== 0).
> > >          */
> > > -       while (!((flags = shared[ref].flags) & GTF_transfer_committed)) {
> > > -               if (sync_cmpxchg(&shared[ref].flags, flags, 0) == flags)
> > > +       while (!((flags = *pflags) & GTF_transfer_committed)) {
> > > +               if (sync_cmpxchg(pflags, flags, 0) == flags)
> > >                         return 0;
> > >                 cpu_relax();
> > >         }
> > > 
> > >         /* If a transfer is in progress then wait until it is completed. */
> > >         while (!(flags & GTF_transfer_completed)) {
> > > -               flags = shared[ref].flags;
> > > +               flags = *pflags;
> > >                 cpu_relax();
> > >         }
> > > 
> > >         rmb();  /* Read the frame number /after/ reading completion status. */
> > > -       frame = shared[ref].frame;
> > > +       frame = gnttab_shared.v1[ref].frame;
> > >         BUG_ON(frame == 0);
> > > 
> > >         return frame;
> > >  }
> > > +
> > > +unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
> > > +{
> > > +       return gnttab_interface.end_foreign_transfer_ref(ref);
> > > +}
> > >  EXPORT_SYMBOL_GPL(gnttab_end_foreign_transfer_ref);
> > > 
> > >  unsigned long gnttab_end_foreign_transfer(grant_ref_t ref)
> > > @@ -520,6 +591,23 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
> > >  }
> > >  EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
> > > 
> > > +static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
> > > +{
> > > +       int rc;
> > > +
> > > +       rc = arch_gnttab_map_shared(frames, nr_gframes,
> > > +                                   gnttab_max_grant_frames(),
> > > +                                   &gnttab_shared.addr);
> > > +       BUG_ON(rc);
> > > +
> > > +       return 0;
> > > +}
> > > +
> > > +static void gnttab_unmap_frames_v1(void)
> > > +{
> > > +       arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
> > > +}
> > > +
> > >  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
> > >  {
> > >         struct gnttab_setup_table setup;
> > > @@ -567,19 +655,33 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
> > > 
> > >         BUG_ON(rc || setup.status);
> > > 
> > > -       rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
> > > -                                   &shared);
> > > -       BUG_ON(rc);
> > > +       rc = gnttab_interface.map_frames(frames, nr_gframes);
> > >     
> > 
> > Nothing checks rc here now?
> > 
> > In fact the gnttab_map_frames_v1 function has its own BUG_ON(rc) and
> > always returns 0 if it returns at all so perhaps that hook should be
> > returning void?
> >   
> Yes, it should be that if there is only v1 function existing.
> However, I added returns 0 here in order to keep consistence with v2
> function of next patch. The function pointer type is: int
> (*map_frames)(....), and v2 function returning value is meaningful.
> The returning value directly decides returning value of gnttab_map.
> See following code in function gnttab_map of v2 patch:
> 
>         if (rc < 0)
>                 return rc;
>         return 0;

Can rc ever be +ve? Doesn't look like it, in which case this is the same
as "return rc".

> If gnttab_map_frames_v1 returns void here, it is necessary to change
> it back(including "void (*map_frames)"  --> "int (*map_frames)") in
> next v2 implementation patch. So I only added return 0 here.

OK.

> 
> .....
> > > +/*
> > >   * Bitfield values for update_pin_status.flags.
> > >   */
> > >   /* Map the grant entry for access by I/O devices. */
> > > diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> > > index 6a6e914..710afe0 100644
> > > --- a/include/xen/interface/xen.h
> > > +++ b/include/xen/interface/xen.h
> > > @@ -523,6 +523,8 @@ struct tmem_op {
> > >         } u;
> > >  };
> > > 
> > > +DEFINE_GUEST_HANDLE(uint64_t);
> > >     
> > 
> > The kernel uses uN style types rather than the uintN_t style ones,
> > although include/xen/interface/grant_table.h seems not to adhere to that
> > at the moment. It might be worth cleaning that up as you go passed.
> >   
> Thanks, I'd like to change it.
> 
> Thanks
> Annie
> > > +
> > >  #else /* __ASSEMBLY__ */
> > > 
> > >  /* In assembly code we cannot use C numeric constant suffixes. */
> > > --
> > > 1.7.6.4
> > > 
> > >     
> > 
> > 
> >   



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:08:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:08:05 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5RV-0002Ci-PH
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5R6-0001EG-8Q; Thu, 17 Nov 2011 09:07:40 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5PA-0001Ad-7U
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:06:00 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1321549533!3975644!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22481 invoked from network); 17 Nov 2011 17:05:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 17:05:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHH5PG1015945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 17:05:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHH5LoV002823
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 17:05:22 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHH5FNd024081; Thu, 17 Nov 2011 11:05:15 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 09:05:15 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2EA3681489; Thu, 17 Nov 2011 12:05:14 -0500 (EST)
Date: Thu, 17 Nov 2011 12:05:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Backport per-device vector map patches to xen 4.1.3
Message-ID: <20111117170514.GA3017@phenom.dumpdata.com>
References: <201110271607.52785.wei.wang2@amd.com>
	<20111117160244.GA6667@phenom.dumpdata.com>
	<4EC549280200007800061AC5@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EC549280200007800061AC5@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4EC53ED7.000E,ss=1,re=0.000,fgs=0
Cc: George@acsinet12.oracle.com, Keir Fraser <keir@xen.org>,
	Dunlap <George.Dunlap@eu.citrix.com>,
	Wei Huang2 <Wei.Huang2@amd.com>, Jacob Shin <Jacob.Shin@amd.com>,
	Wei Wang2 <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 04:49:28PM +0000, Jan Beulich wrote:
> >>> On 17.11.11 at 17:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Thu, Oct 27, 2011 at 04:07:51PM +0200, Wei Wang2 wrote:
> >> Recently we found an issue in xen 4.1. Under heavy I/O stress such as 
> > running 
> >> bonnie++, Dom0 would lost its hard disk with lots of I/O errors. We found 
> >> that some PCI-E devices was using the same vector as SMBus on AMD platforms 
> >> and George' patch set that enables per-device vector map can fix this 
> >> problem.
> >> 
> >> Following patches have been back ported and tested by Jacob and Wei H.  
> >> Please apply them to Xen 4.1.3 
> > 
> > Can they be applied please? I've been running these without hiccups for 
> > well,
> > since they were posted. On both AMD and Intel boxes.
> > 
> > So, Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Thanks to Keir, they're already in - c/s 23177:9a38e30e5459.

Oh, they are. Hmm, somehow when I looked at xenbits.xen.org I couldn't find them.
Now I see them :-)

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:08:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:08:05 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5RV-0002Ci-PH
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5R6-0001EG-8Q; Thu, 17 Nov 2011 09:07:40 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5PA-0001Ad-7U
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:06:00 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1321549533!3975644!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22481 invoked from network); 17 Nov 2011 17:05:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 17:05:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHH5PG1015945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 17:05:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHH5LoV002823
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 17:05:22 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHH5FNd024081; Thu, 17 Nov 2011 11:05:15 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 09:05:15 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2EA3681489; Thu, 17 Nov 2011 12:05:14 -0500 (EST)
Date: Thu, 17 Nov 2011 12:05:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Backport per-device vector map patches to xen 4.1.3
Message-ID: <20111117170514.GA3017@phenom.dumpdata.com>
References: <201110271607.52785.wei.wang2@amd.com>
	<20111117160244.GA6667@phenom.dumpdata.com>
	<4EC549280200007800061AC5@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EC549280200007800061AC5@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4EC53ED7.000E,ss=1,re=0.000,fgs=0
Cc: George@acsinet12.oracle.com, Keir Fraser <keir@xen.org>,
	Dunlap <George.Dunlap@eu.citrix.com>,
	Wei Huang2 <Wei.Huang2@amd.com>, Jacob Shin <Jacob.Shin@amd.com>,
	Wei Wang2 <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 04:49:28PM +0000, Jan Beulich wrote:
> >>> On 17.11.11 at 17:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Thu, Oct 27, 2011 at 04:07:51PM +0200, Wei Wang2 wrote:
> >> Recently we found an issue in xen 4.1. Under heavy I/O stress such as 
> > running 
> >> bonnie++, Dom0 would lost its hard disk with lots of I/O errors. We found 
> >> that some PCI-E devices was using the same vector as SMBus on AMD platforms 
> >> and George' patch set that enables per-device vector map can fix this 
> >> problem.
> >> 
> >> Following patches have been back ported and tested by Jacob and Wei H.  
> >> Please apply them to Xen 4.1.3 
> > 
> > Can they be applied please? I've been running these without hiccups for 
> > well,
> > since they were posted. On both AMD and Intel boxes.
> > 
> > So, Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Thanks to Keir, they're already in - c/s 23177:9a38e30e5459.

Oh, they are. Hmm, somehow when I looked at xenbits.xen.org I couldn't find them.
Now I see them :-)

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:22:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:22:10 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5f8-0002D1-62
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:22:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5eg-0001vM-FJ; Thu, 17 Nov 2011 09:21:42 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5eT-0001uS-CZ
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:21:32 -0800
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1321550485!3558211!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21488 invoked from network); 17 Nov 2011 17:21:25 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 17:21:25 -0000
Received: by wwp14 with SMTP id 14so2828252wwp.24
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 09:21:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=YPWApM29IkXAkXcDDQs78M+Ij6TGwfw3ZUtkUjNPiw0=;
	b=UvTzYCvbr/87Yoioz9pxWh5v7CfhV00w5D4FXtVCp/f+q4TAG4QvkWdZ+TamVx6stj
	3q0JDPTWuHNN06TNIKCI92ezSC9oHJUdsy/WKq2MO6oftCYyKJOmO2vnImkgfEFwiepL
	u3net3n9vdUUhnbr4ofPEIqiz+oShsB7lJc7M=
Received: by 10.180.7.97 with SMTP id i1mr42028080wia.23.1321550485716;
	Thu, 17 Nov 2011 09:21:25 -0800 (PST)
Received: from [192.168.1.3] (host86-129-245-239.range86-129.btcentralplus.com.
	[86.129.245.239])
	by mx.google.com with ESMTPS id db1sm18770913wib.19.2011.11.17.09.21.16
	(version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 09:21:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 17 Nov 2011 17:21:09 +0000
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
From: Keir Fraser <keir@xen.org>
To: Paul Durrant <paul.durrant@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAEAF305.344BF%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Index: AcylTUvRZV7WF7N3u0mmSwGUSns+jw==
In-Reply-To: <c25af1f86de1699ee366.1321548236@cosworth.uk.xensource.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: 
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/11/2011 16:43, "Paul Durrant" <paul.durrant@citrix.com> wrote:

> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1321548043 0
> # Node ID c25af1f86de1699ee36684e740a323adbcffdfb5
> # Parent  447738ef67ea2690c8ea6684f2e0e0b3528ad446
> Add configuration options to selectively disable S3 and S4 ACPI power states.
> 
> Introduce acpi_s3 and acpi_s4 configuration options (default=1). When one of
> these
> parameters is 0 it causes removal of the respective package (_S3 or _S4) from
> the
> DSDT thereby disabling that power state in the guest.

Yeeees. Brave as binary patching the DSDT is, how about sticking _S3 and _S4
in optional SSDTs? 

 -- Keir

> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/acpi/acpi2_0.h
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:40:43 2011 +0000
> @@ -396,6 +396,8 @@ struct acpi_config {
>      int dsdt_anycpu_len;
>      unsigned char *dsdt_15cpu;
>      int dsdt_15cpu_len;
> +    int dsdt_s3_enabled;
> +    int dsdt_s4_enabled;
>  };
>  
>  void acpi_build_tables(struct acpi_config *config, unsigned int physical);
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:40:43 2011 +0000
> @@ -274,6 +274,54 @@ static int construct_secondary_tables(un
>      return nr_tables;
>  }
>  
> +static uint8_t *find_name(uint8_t *dsdt, const char *prefix)
> +{
> +    int len = strlen(prefix);
> +    int i;
> +
> +    for ( i = 0; i < ((struct acpi_header *)dsdt)->length - len; i++, dsdt++
> )
> +    {
> +        if ( memcmp(dsdt, prefix, len) == 0 && *(dsdt - 1) == 0x08 )
> +            return dsdt - 1;
> +    }
> +
> +    return NULL;
> +}
> +
> +static void remove_package(uint8_t *dsdt, const char *prefix)
> +{
> +    struct acpi_header *header = (struct acpi_header *)dsdt;
> +    uint8_t *start = find_name(dsdt, prefix);
> +    uint8_t *end = dsdt + header->length - 1;
> +    uint8_t *package;
> +    uint8_t *len;
> +    uint8_t *next;
> +
> +    if ( start == NULL )
> +        return;
> +
> +    package = start + 5; /* 1 byte op, 4 bytes payload */
> +    if ( package > end )
> +        return;
> +    if ( *package != 0x12 )
> +        return;
> +
> +    len = package + 1;
> +    if ( package > end )
> +        return;
> +
> +    next = package + 1 + *len; /* 1 byte op, len bytes payload */
> +    if ( next > end + 1 )
> +        return;
> +
> +    printf("DSDT: removing '%c%c%c%c' (%d bytes)\n",
> +           *(start + 1), *(start + 2), *(start + 3), *(start + 4),
> +           next - start);
> +
> +    memcpy(start, next, header->length - (next - dsdt));
> +    header->length -= next - start;
> +}
> +
>  void acpi_build_tables(struct acpi_config *config, unsigned int physical)
>  {
>      struct acpi_info *acpi_info;
> @@ -310,19 +358,29 @@ void acpi_build_tables(struct acpi_confi
>       */
>      if ( hvm_info->nr_vcpus <= 15 && config->dsdt_15cpu)
>      {
> -        dsdt = mem_alloc(config->dsdt_15cpu_len, 16);
> +        dsdt = mem_probe(config->dsdt_15cpu_len, 16);
>          if (!dsdt) goto oom;
>          memcpy(dsdt, config->dsdt_15cpu, config->dsdt_15cpu_len);
>          nr_processor_objects = 15;
>      }
>      else
>      {
> -        dsdt = mem_alloc(config->dsdt_anycpu_len, 16);
> +        dsdt = mem_probe(config->dsdt_anycpu_len, 16);
>          if (!dsdt) goto oom;
>          memcpy(dsdt, config->dsdt_anycpu, config->dsdt_anycpu_len);
>          nr_processor_objects = HVM_MAX_VCPUS;
>      }
>  
> +    if ( !config->dsdt_s3_enabled)
> +        remove_package(dsdt, "_S3");
> +    if ( !config->dsdt_s4_enabled)
> +        remove_package(dsdt, "_S4");
> +
> +    set_checksum(dsdt,
> +                 offsetof(struct acpi_header, checksum),
> +                 ((struct acpi_header*)dsdt)->length);
> +    mem_commit(dsdt, ((struct acpi_header*)dsdt)->length);
> +
>      /*
>       * N.B. ACPI 1.0 operating systems may not handle FADT with revision 2
>       * or above properly, notably Windows 2000, which tries to copy FADT
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/config.h Thu Nov 17 16:40:43 2011 +0000
> @@ -27,7 +27,7 @@ struct bios_config {
>  
>      void (*e820_setup)(void);
>  
> -    void (*acpi_build_tables)(void);
> +    void (*acpi_build_tables)(int, int);
>      void (*create_mp_tables)(void);
>      void (*create_smbios_tables)(void);
>      void (*create_pir_tables)(void);
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:40:43 2011 +0000
> @@ -516,11 +516,17 @@ int main(void)
>              .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
>              .value = 1,
>          };
> +        int s3_enabled, s4_enabled;
> +
> +        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3", "1"), "1",
> 1);
> +        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4", "1"), "1",
> 1);
>  
>          if ( bios->acpi_build_tables )
>          {
> -            printf("Loading ACPI ...\n");
> -            bios->acpi_build_tables();
> +            printf("Loading ACPI (S3=%s S4=%s) ...\n",
> +                   (s3_enabled) ? "ON" : "OFF",
> +                   (s4_enabled) ? "ON" : "OFF");
> +            bios->acpi_build_tables(s3_enabled, s4_enabled);
>          }
>  
>          acpi_enable_sci();
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/rombios.c
> --- a/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:40:43 2011 +0000
> @@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
>      *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) = -checksum;
>  }
>  
> -static void rombios_acpi_build_tables(void)
> +static void rombios_acpi_build_tables(int s3_enabled, int s4_enabled)
>  {
>      struct acpi_config config = {
>          .dsdt_anycpu = dsdt_anycpu,
>          .dsdt_anycpu_len = dsdt_anycpu_len,
>          .dsdt_15cpu = dsdt_15cpu,
>          .dsdt_15cpu_len = dsdt_15cpu_len,
> +        .dsdt_s3_enabled = s3_enabled,
> +        .dsdt_s4_enabled = s4_enabled,
>      };
>  
>      acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/seabios.c
> --- a/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:40:43 2011 +0000
> @@ -91,7 +91,7 @@ static void add_table(uint32_t t)
>      info->tables_nr++;
>  }
>  
> -static void seabios_acpi_build_tables(void)
> +static void seabios_acpi_build_tables(int s3_enabled, int s4_enabled)
>  {
>      uint32_t rsdp = (uint32_t)scratch_alloc(sizeof(struct acpi_20_rsdp), 0);
>      struct acpi_config config = {
> @@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
>          .dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
>          .dsdt_15cpu = NULL,
>          .dsdt_15cpu_len = 0,
> +        .dsdt_s3_enabled = s3_enabled,
> +        .dsdt_s4_enabled = s4_enabled,
>      };
>  
>      acpi_build_tables(&config, rsdp);
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.c
> --- a/tools/firmware/hvmloader/util.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/util.c Thu Nov 17 16:40:43 2011 +0000
> @@ -352,28 +352,35 @@ xen_pfn_t mem_hole_alloc(uint32_t nr_mfn
>      return hvm_info->reserved_mem_pgstart;
>  }
>  
> -void *mem_alloc(uint32_t size, uint32_t align)
> +void *mem_probe(uint32_t size, uint32_t align)
>  {
> -    uint32_t s, e;
> +    uint32_t r, s, e;
> +    void *base;
>  
>      /* Align to at least 16 bytes. */
>      if ( align < 16 )
>          align = 16;
>  
> -    s = (reserve + align) & ~(align - 1);
> +    r = reserve;
> +    s = (r + align) & ~(align - 1);
>      e = s + size - 1;
>  
> +    base = (void *)s;
> +
>      BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);
>  
> -    while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
> +    while ( (r >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
>      {
> -        reserve += PAGE_SIZE;
> -        mem_hole_populate_ram(reserve >> PAGE_SHIFT, 1);
> +        r += PAGE_SIZE;
> +        mem_hole_populate_ram(r >> PAGE_SHIFT, 1);
>      }
>  
> -    reserve = e;
> +    return (void *)(unsigned long)s;
> +}
>  
> -    return (void *)(unsigned long)s;
> +void mem_commit(void *base, uint32_t size)
> +{
> +    reserve = (uint32_t)base + size;
>  }
>  
>  void *scratch_alloc(uint32_t size, uint32_t align)
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.h
> --- a/tools/firmware/hvmloader/util.h Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/util.h Thu Nov 17 16:40:43 2011 +0000
> @@ -172,7 +172,16 @@ void mem_hole_populate_ram(xen_pfn_t mfn
>  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns);
>  
>  /* Allocate memory in a reserved region below 4GB. */
> -void *mem_alloc(uint32_t size, uint32_t align);
> +void *mem_probe(uint32_t size, uint32_t align);
> +void mem_commit(void *base, uint32_t size);
> +
> +static inline void *mem_alloc(uint32_t size, uint32_t align)
> +{
> +    void *base = mem_probe(size, align);
> +    mem_commit(base, size);
> +    return base;
> +}
> +
>  #define virt_to_phys(v) ((unsigned long)(v))
>  
>  /* Allocate memory in a scratch region */
> diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/libxl/libxl_create.c Thu Nov 17 16:40:43 2011 +0000
> @@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
>          b_info->u.hvm.pae = 1;
>          b_info->u.hvm.apic = 1;
>          b_info->u.hvm.acpi = 1;
> +        b_info->u.hvm.acpi_s3 = 1;
> +        b_info->u.hvm.acpi_s4 = 1;
>          b_info->u.hvm.nx = 1;
>          b_info->u.hvm.viridian = 0;
>          b_info->u.hvm.hpet = 1;
> @@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
>          vments[4] = "start_time";
>          vments[5] = libxl__sprintf(gc, "%lu.%02d",
> start_time.tv_sec,(int)start_time.tv_usec/10000);
>  
> -        localents = libxl__calloc(gc, 3, sizeof(char *));
> +        localents = libxl__calloc(gc, 7, sizeof(char *));
>          localents[0] = "platform/acpi";
>          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
> +        localents[2] = "platform/acpi_s3";
> +        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
> +        localents[4] = "platform/acpi_s4";
> +        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
>  
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
> diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/libxl/libxl_types.idl Thu Nov 17 16:40:43 2011 +0000
> @@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
>                                         ("pae", bool),
>                                         ("apic", bool),
>                                         ("acpi", bool),
> +                                       ("acpi_s3", bool),
> +                                       ("acpi_s4", bool),
>                                         ("nx", bool),
>                                         ("viridian", bool),
>                                         ("timeoffset", string),
> diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:40:43 2011 +0000
> @@ -683,6 +683,10 @@ static void parse_config_data(const char
>              b_info->u.hvm.apic = l;
>          if (!xlu_cfg_get_long (config, "acpi", &l))
>              b_info->u.hvm.acpi = l;
> +        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
> +            b_info->u.hvm.acpi_s3 = l;
> +        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
> +            b_info->u.hvm.acpi_s4 = l;
>          if (!xlu_cfg_get_long (config, "nx", &l))
>              b_info->u.hvm.nx = l;
>          if (!xlu_cfg_get_long (config, "viridian", &l))
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:22:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:22:10 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5f8-0002D1-62
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:22:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5eg-0001vM-FJ; Thu, 17 Nov 2011 09:21:42 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5eT-0001uS-CZ
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:21:32 -0800
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1321550485!3558211!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21488 invoked from network); 17 Nov 2011 17:21:25 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 17:21:25 -0000
Received: by wwp14 with SMTP id 14so2828252wwp.24
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 09:21:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=YPWApM29IkXAkXcDDQs78M+Ij6TGwfw3ZUtkUjNPiw0=;
	b=UvTzYCvbr/87Yoioz9pxWh5v7CfhV00w5D4FXtVCp/f+q4TAG4QvkWdZ+TamVx6stj
	3q0JDPTWuHNN06TNIKCI92ezSC9oHJUdsy/WKq2MO6oftCYyKJOmO2vnImkgfEFwiepL
	u3net3n9vdUUhnbr4ofPEIqiz+oShsB7lJc7M=
Received: by 10.180.7.97 with SMTP id i1mr42028080wia.23.1321550485716;
	Thu, 17 Nov 2011 09:21:25 -0800 (PST)
Received: from [192.168.1.3] (host86-129-245-239.range86-129.btcentralplus.com.
	[86.129.245.239])
	by mx.google.com with ESMTPS id db1sm18770913wib.19.2011.11.17.09.21.16
	(version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 09:21:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 17 Nov 2011 17:21:09 +0000
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
From: Keir Fraser <keir@xen.org>
To: Paul Durrant <paul.durrant@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAEAF305.344BF%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Index: AcylTUvRZV7WF7N3u0mmSwGUSns+jw==
In-Reply-To: <c25af1f86de1699ee366.1321548236@cosworth.uk.xensource.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: 
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/11/2011 16:43, "Paul Durrant" <paul.durrant@citrix.com> wrote:

> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1321548043 0
> # Node ID c25af1f86de1699ee36684e740a323adbcffdfb5
> # Parent  447738ef67ea2690c8ea6684f2e0e0b3528ad446
> Add configuration options to selectively disable S3 and S4 ACPI power states.
> 
> Introduce acpi_s3 and acpi_s4 configuration options (default=1). When one of
> these
> parameters is 0 it causes removal of the respective package (_S3 or _S4) from
> the
> DSDT thereby disabling that power state in the guest.

Yeeees. Brave as binary patching the DSDT is, how about sticking _S3 and _S4
in optional SSDTs? 

 -- Keir

> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/acpi/acpi2_0.h
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:40:43 2011 +0000
> @@ -396,6 +396,8 @@ struct acpi_config {
>      int dsdt_anycpu_len;
>      unsigned char *dsdt_15cpu;
>      int dsdt_15cpu_len;
> +    int dsdt_s3_enabled;
> +    int dsdt_s4_enabled;
>  };
>  
>  void acpi_build_tables(struct acpi_config *config, unsigned int physical);
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:40:43 2011 +0000
> @@ -274,6 +274,54 @@ static int construct_secondary_tables(un
>      return nr_tables;
>  }
>  
> +static uint8_t *find_name(uint8_t *dsdt, const char *prefix)
> +{
> +    int len = strlen(prefix);
> +    int i;
> +
> +    for ( i = 0; i < ((struct acpi_header *)dsdt)->length - len; i++, dsdt++
> )
> +    {
> +        if ( memcmp(dsdt, prefix, len) == 0 && *(dsdt - 1) == 0x08 )
> +            return dsdt - 1;
> +    }
> +
> +    return NULL;
> +}
> +
> +static void remove_package(uint8_t *dsdt, const char *prefix)
> +{
> +    struct acpi_header *header = (struct acpi_header *)dsdt;
> +    uint8_t *start = find_name(dsdt, prefix);
> +    uint8_t *end = dsdt + header->length - 1;
> +    uint8_t *package;
> +    uint8_t *len;
> +    uint8_t *next;
> +
> +    if ( start == NULL )
> +        return;
> +
> +    package = start + 5; /* 1 byte op, 4 bytes payload */
> +    if ( package > end )
> +        return;
> +    if ( *package != 0x12 )
> +        return;
> +
> +    len = package + 1;
> +    if ( package > end )
> +        return;
> +
> +    next = package + 1 + *len; /* 1 byte op, len bytes payload */
> +    if ( next > end + 1 )
> +        return;
> +
> +    printf("DSDT: removing '%c%c%c%c' (%d bytes)\n",
> +           *(start + 1), *(start + 2), *(start + 3), *(start + 4),
> +           next - start);
> +
> +    memcpy(start, next, header->length - (next - dsdt));
> +    header->length -= next - start;
> +}
> +
>  void acpi_build_tables(struct acpi_config *config, unsigned int physical)
>  {
>      struct acpi_info *acpi_info;
> @@ -310,19 +358,29 @@ void acpi_build_tables(struct acpi_confi
>       */
>      if ( hvm_info->nr_vcpus <= 15 && config->dsdt_15cpu)
>      {
> -        dsdt = mem_alloc(config->dsdt_15cpu_len, 16);
> +        dsdt = mem_probe(config->dsdt_15cpu_len, 16);
>          if (!dsdt) goto oom;
>          memcpy(dsdt, config->dsdt_15cpu, config->dsdt_15cpu_len);
>          nr_processor_objects = 15;
>      }
>      else
>      {
> -        dsdt = mem_alloc(config->dsdt_anycpu_len, 16);
> +        dsdt = mem_probe(config->dsdt_anycpu_len, 16);
>          if (!dsdt) goto oom;
>          memcpy(dsdt, config->dsdt_anycpu, config->dsdt_anycpu_len);
>          nr_processor_objects = HVM_MAX_VCPUS;
>      }
>  
> +    if ( !config->dsdt_s3_enabled)
> +        remove_package(dsdt, "_S3");
> +    if ( !config->dsdt_s4_enabled)
> +        remove_package(dsdt, "_S4");
> +
> +    set_checksum(dsdt,
> +                 offsetof(struct acpi_header, checksum),
> +                 ((struct acpi_header*)dsdt)->length);
> +    mem_commit(dsdt, ((struct acpi_header*)dsdt)->length);
> +
>      /*
>       * N.B. ACPI 1.0 operating systems may not handle FADT with revision 2
>       * or above properly, notably Windows 2000, which tries to copy FADT
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/config.h Thu Nov 17 16:40:43 2011 +0000
> @@ -27,7 +27,7 @@ struct bios_config {
>  
>      void (*e820_setup)(void);
>  
> -    void (*acpi_build_tables)(void);
> +    void (*acpi_build_tables)(int, int);
>      void (*create_mp_tables)(void);
>      void (*create_smbios_tables)(void);
>      void (*create_pir_tables)(void);
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:40:43 2011 +0000
> @@ -516,11 +516,17 @@ int main(void)
>              .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
>              .value = 1,
>          };
> +        int s3_enabled, s4_enabled;
> +
> +        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3", "1"), "1",
> 1);
> +        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4", "1"), "1",
> 1);
>  
>          if ( bios->acpi_build_tables )
>          {
> -            printf("Loading ACPI ...\n");
> -            bios->acpi_build_tables();
> +            printf("Loading ACPI (S3=%s S4=%s) ...\n",
> +                   (s3_enabled) ? "ON" : "OFF",
> +                   (s4_enabled) ? "ON" : "OFF");
> +            bios->acpi_build_tables(s3_enabled, s4_enabled);
>          }
>  
>          acpi_enable_sci();
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/rombios.c
> --- a/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:40:43 2011 +0000
> @@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
>      *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) = -checksum;
>  }
>  
> -static void rombios_acpi_build_tables(void)
> +static void rombios_acpi_build_tables(int s3_enabled, int s4_enabled)
>  {
>      struct acpi_config config = {
>          .dsdt_anycpu = dsdt_anycpu,
>          .dsdt_anycpu_len = dsdt_anycpu_len,
>          .dsdt_15cpu = dsdt_15cpu,
>          .dsdt_15cpu_len = dsdt_15cpu_len,
> +        .dsdt_s3_enabled = s3_enabled,
> +        .dsdt_s4_enabled = s4_enabled,
>      };
>  
>      acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/seabios.c
> --- a/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:40:43 2011 +0000
> @@ -91,7 +91,7 @@ static void add_table(uint32_t t)
>      info->tables_nr++;
>  }
>  
> -static void seabios_acpi_build_tables(void)
> +static void seabios_acpi_build_tables(int s3_enabled, int s4_enabled)
>  {
>      uint32_t rsdp = (uint32_t)scratch_alloc(sizeof(struct acpi_20_rsdp), 0);
>      struct acpi_config config = {
> @@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
>          .dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
>          .dsdt_15cpu = NULL,
>          .dsdt_15cpu_len = 0,
> +        .dsdt_s3_enabled = s3_enabled,
> +        .dsdt_s4_enabled = s4_enabled,
>      };
>  
>      acpi_build_tables(&config, rsdp);
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.c
> --- a/tools/firmware/hvmloader/util.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/util.c Thu Nov 17 16:40:43 2011 +0000
> @@ -352,28 +352,35 @@ xen_pfn_t mem_hole_alloc(uint32_t nr_mfn
>      return hvm_info->reserved_mem_pgstart;
>  }
>  
> -void *mem_alloc(uint32_t size, uint32_t align)
> +void *mem_probe(uint32_t size, uint32_t align)
>  {
> -    uint32_t s, e;
> +    uint32_t r, s, e;
> +    void *base;
>  
>      /* Align to at least 16 bytes. */
>      if ( align < 16 )
>          align = 16;
>  
> -    s = (reserve + align) & ~(align - 1);
> +    r = reserve;
> +    s = (r + align) & ~(align - 1);
>      e = s + size - 1;
>  
> +    base = (void *)s;
> +
>      BUG_ON((e < s) || (e >> PAGE_SHIFT) >= hvm_info->reserved_mem_pgstart);
>  
> -    while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
> +    while ( (r >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
>      {
> -        reserve += PAGE_SIZE;
> -        mem_hole_populate_ram(reserve >> PAGE_SHIFT, 1);
> +        r += PAGE_SIZE;
> +        mem_hole_populate_ram(r >> PAGE_SHIFT, 1);
>      }
>  
> -    reserve = e;
> +    return (void *)(unsigned long)s;
> +}
>  
> -    return (void *)(unsigned long)s;
> +void mem_commit(void *base, uint32_t size)
> +{
> +    reserve = (uint32_t)base + size;
>  }
>  
>  void *scratch_alloc(uint32_t size, uint32_t align)
> diff -r 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.h
> --- a/tools/firmware/hvmloader/util.h Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/firmware/hvmloader/util.h Thu Nov 17 16:40:43 2011 +0000
> @@ -172,7 +172,16 @@ void mem_hole_populate_ram(xen_pfn_t mfn
>  xen_pfn_t mem_hole_alloc(uint32_t nr_mfns);
>  
>  /* Allocate memory in a reserved region below 4GB. */
> -void *mem_alloc(uint32_t size, uint32_t align);
> +void *mem_probe(uint32_t size, uint32_t align);
> +void mem_commit(void *base, uint32_t size);
> +
> +static inline void *mem_alloc(uint32_t size, uint32_t align)
> +{
> +    void *base = mem_probe(size, align);
> +    mem_commit(base, size);
> +    return base;
> +}
> +
>  #define virt_to_phys(v) ((unsigned long)(v))
>  
>  /* Allocate memory in a scratch region */
> diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/libxl/libxl_create.c Thu Nov 17 16:40:43 2011 +0000
> @@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
>          b_info->u.hvm.pae = 1;
>          b_info->u.hvm.apic = 1;
>          b_info->u.hvm.acpi = 1;
> +        b_info->u.hvm.acpi_s3 = 1;
> +        b_info->u.hvm.acpi_s4 = 1;
>          b_info->u.hvm.nx = 1;
>          b_info->u.hvm.viridian = 0;
>          b_info->u.hvm.hpet = 1;
> @@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
>          vments[4] = "start_time";
>          vments[5] = libxl__sprintf(gc, "%lu.%02d",
> start_time.tv_sec,(int)start_time.tv_usec/10000);
>  
> -        localents = libxl__calloc(gc, 3, sizeof(char *));
> +        localents = libxl__calloc(gc, 7, sizeof(char *));
>          localents[0] = "platform/acpi";
>          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
> +        localents[2] = "platform/acpi_s3";
> +        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
> +        localents[4] = "platform/acpi_s4";
> +        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
>  
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
> diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/libxl/libxl_types.idl Thu Nov 17 16:40:43 2011 +0000
> @@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
>                                         ("pae", bool),
>                                         ("apic", bool),
>                                         ("acpi", bool),
> +                                       ("acpi_s3", bool),
> +                                       ("acpi_s4", bool),
>                                         ("nx", bool),
>                                         ("viridian", bool),
>                                         ("timeoffset", string),
> diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:21:21 2011 +0000
> +++ b/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:40:43 2011 +0000
> @@ -683,6 +683,10 @@ static void parse_config_data(const char
>              b_info->u.hvm.apic = l;
>          if (!xlu_cfg_get_long (config, "acpi", &l))
>              b_info->u.hvm.acpi = l;
> +        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
> +            b_info->u.hvm.acpi_s3 = l;
> +        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
> +            b_info->u.hvm.acpi_s4 = l;
>          if (!xlu_cfg_get_long (config, "nx", &l))
>              b_info->u.hvm.nx = l;
>          if (!xlu_cfg_get_long (config, "viridian", &l))
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:23:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:23:50 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5gk-0002DF-9l
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:23:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5gQ-0002P9-2V; Thu, 17 Nov 2011 09:23:30 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5fv-0002FM-Ci
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:22:59 -0800
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321550562!46085544!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30158 invoked from network); 17 Nov 2011 17:22:42 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 17:22:42 -0000
Received: by wwp14 with SMTP id 14so2830709wwp.24
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 09:22:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ZA/KudHR0hqyqOSH1KD6WOhgwljoTKxHM7EOuKPcnDU=;
	b=NtN1zvpmMCGpT9rY40Wk40dho7U3lxyRiEt0kMbMTXj5ZyN0wjnVVqUn3LZOnU7FLY
	eFBGU93jbFCCgbTCGLlOB5cn1V2f7DV1WNU+fvodgrY1gsw7Da5k9WT9XH5CJhcdkUl+
	AtCGQrurj26TrkG8QNFNitFI67gF8HEOaY44c=
Received: by 10.180.73.130 with SMTP id l2mr12594497wiv.21.1321550576307;
	Thu, 17 Nov 2011 09:22:56 -0800 (PST)
Received: from [192.168.1.3] (host86-129-245-239.range86-129.btcentralplus.com.
	[86.129.245.239])
	by mx.google.com with ESMTPS id e7sm37464443wbh.12.2011.11.17.09.22.47
	(version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 09:22:55 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 17 Nov 2011 17:22:43 +0000
Subject: Re: [Xen-devel] [PATCH] x86/xsave: provide guests with finit-like
	environment
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAEAF363.344CB%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/xsave: provide guests with finit-like
	environment
Thread-Index: AcylTYPYLscmJR1WsUKIcSL+nfczTA==
In-Reply-To: <4EC52B9D020000780006199E@nat28.tlf.novell.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Charles Arnold <CARNOLD@suse.com>, Bruce Rogers <BROGERS@suse.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/11/2011 14:43, "Jan Beulich" <JBeulich@suse.com> wrote:

> Without the use of xsave, guests get their initial floating point
> environment set up with finit. At least NetWare actually depends on
> this (in particular on all exceptions being masked), so to be
> consistent set the same environment also when using xsave. This is
> also in line with all SSE exceptions getting masked initially.
> 
> To avoid further fragile casts in xstate_alloc_save_area() the patch
> also changes xsave_struct's fpu_see member to have actually usable
> fields.
> 
> The patch was tested in its technically identical, but modified-file-
> wise different 4.1.2 version.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Charles Arnold <carnold@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/i387.c
> +++ b/xen/arch/x86/i387.c
> @@ -17,7 +17,6 @@
>  #include <asm/xstate.h>
>  #include <asm/asm_defns.h>
>  
> -#define MXCSR_DEFAULT 0x1f80
>  static void fpu_init(void)
>  {
>      unsigned long val;
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -97,7 +97,7 @@ bool_t xsave_enabled(const struct vcpu *
>  
>  int xstate_alloc_save_area(struct vcpu *v)
>  {
> -    void *save_area;
> +    struct xsave_struct *save_area;
>  
>      if ( !cpu_has_xsave || is_idle_vcpu(v) )
>          return 0;
> @@ -109,8 +109,9 @@ int xstate_alloc_save_area(struct vcpu *
>      if ( save_area == NULL )
>          return -ENOMEM;
>  
> -    ((u32 *)save_area)[6] = 0x1f80;  /* MXCSR */
> -    *(uint64_t *)(save_area + 512) = XSTATE_FP_SSE;  /* XSETBV */
> +    save_area->fpu_sse.fcw = FCW_DEFAULT;
> +    save_area->fpu_sse.mxcsr = MXCSR_DEFAULT;
> +    save_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
>  
>      v->arch.xsave_area = save_area;
>      v->arch.xcr0 = XSTATE_FP_SSE;
> --- a/xen/include/asm-x86/xstate.h
> +++ b/xen/include/asm-x86/xstate.h
> @@ -11,6 +11,9 @@
>  #include <xen/types.h>
>  #include <xen/percpu.h>
>  
> +#define FCW_DEFAULT               0x037f
> +#define MXCSR_DEFAULT             0x1f80
> +
>  #define XSTATE_CPUID              0x0000000d
>  #define XSTATE_FEATURE_XSAVEOPT   (1 << 0)    /* sub-leaf 1, eax[bit 0] */
>  
> @@ -46,7 +49,29 @@ extern u64 xfeature_mask;
>  /* extended state save area */
>  struct xsave_struct
>  {
> -    struct { char x[512]; } fpu_sse;         /* FPU/MMX, SSE */
> +    union {                                  /* FPU/MMX, SSE */
> +        char x[512];
> +        struct {
> +            uint16_t fcw;
> +            uint16_t fsw;
> +            uint8_t ftw;
> +            uint8_t rsvd1;
> +            uint16_t fop;
> +            union {
> +#ifdef __x86_64__
> +                uint64_t addr;
> +#endif
> +                struct {
> +                    uint32_t offs;
> +                    uint16_t sel;
> +                    uint16_t rsvd;
> +                };
> +            } fip, fdp;
> +            uint32_t mxcsr;
> +            uint32_t mxcsr_mask;
> +            /* data registers follow here */
> +        };
> +    } fpu_sse;
>  
>      struct {
>          u64 xstate_bv;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:23:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:23:50 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5gk-0002DF-9l
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:23:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5gQ-0002P9-2V; Thu, 17 Nov 2011 09:23:30 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5fv-0002FM-Ci
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:22:59 -0800
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321550562!46085544!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30158 invoked from network); 17 Nov 2011 17:22:42 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 17:22:42 -0000
Received: by wwp14 with SMTP id 14so2830709wwp.24
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 09:22:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ZA/KudHR0hqyqOSH1KD6WOhgwljoTKxHM7EOuKPcnDU=;
	b=NtN1zvpmMCGpT9rY40Wk40dho7U3lxyRiEt0kMbMTXj5ZyN0wjnVVqUn3LZOnU7FLY
	eFBGU93jbFCCgbTCGLlOB5cn1V2f7DV1WNU+fvodgrY1gsw7Da5k9WT9XH5CJhcdkUl+
	AtCGQrurj26TrkG8QNFNitFI67gF8HEOaY44c=
Received: by 10.180.73.130 with SMTP id l2mr12594497wiv.21.1321550576307;
	Thu, 17 Nov 2011 09:22:56 -0800 (PST)
Received: from [192.168.1.3] (host86-129-245-239.range86-129.btcentralplus.com.
	[86.129.245.239])
	by mx.google.com with ESMTPS id e7sm37464443wbh.12.2011.11.17.09.22.47
	(version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 09:22:55 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 17 Nov 2011 17:22:43 +0000
Subject: Re: [Xen-devel] [PATCH] x86/xsave: provide guests with finit-like
	environment
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAEAF363.344CB%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/xsave: provide guests with finit-like
	environment
Thread-Index: AcylTYPYLscmJR1WsUKIcSL+nfczTA==
In-Reply-To: <4EC52B9D020000780006199E@nat28.tlf.novell.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Charles Arnold <CARNOLD@suse.com>, Bruce Rogers <BROGERS@suse.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/11/2011 14:43, "Jan Beulich" <JBeulich@suse.com> wrote:

> Without the use of xsave, guests get their initial floating point
> environment set up with finit. At least NetWare actually depends on
> this (in particular on all exceptions being masked), so to be
> consistent set the same environment also when using xsave. This is
> also in line with all SSE exceptions getting masked initially.
> 
> To avoid further fragile casts in xstate_alloc_save_area() the patch
> also changes xsave_struct's fpu_see member to have actually usable
> fields.
> 
> The patch was tested in its technically identical, but modified-file-
> wise different 4.1.2 version.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Charles Arnold <carnold@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/i387.c
> +++ b/xen/arch/x86/i387.c
> @@ -17,7 +17,6 @@
>  #include <asm/xstate.h>
>  #include <asm/asm_defns.h>
>  
> -#define MXCSR_DEFAULT 0x1f80
>  static void fpu_init(void)
>  {
>      unsigned long val;
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -97,7 +97,7 @@ bool_t xsave_enabled(const struct vcpu *
>  
>  int xstate_alloc_save_area(struct vcpu *v)
>  {
> -    void *save_area;
> +    struct xsave_struct *save_area;
>  
>      if ( !cpu_has_xsave || is_idle_vcpu(v) )
>          return 0;
> @@ -109,8 +109,9 @@ int xstate_alloc_save_area(struct vcpu *
>      if ( save_area == NULL )
>          return -ENOMEM;
>  
> -    ((u32 *)save_area)[6] = 0x1f80;  /* MXCSR */
> -    *(uint64_t *)(save_area + 512) = XSTATE_FP_SSE;  /* XSETBV */
> +    save_area->fpu_sse.fcw = FCW_DEFAULT;
> +    save_area->fpu_sse.mxcsr = MXCSR_DEFAULT;
> +    save_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
>  
>      v->arch.xsave_area = save_area;
>      v->arch.xcr0 = XSTATE_FP_SSE;
> --- a/xen/include/asm-x86/xstate.h
> +++ b/xen/include/asm-x86/xstate.h
> @@ -11,6 +11,9 @@
>  #include <xen/types.h>
>  #include <xen/percpu.h>
>  
> +#define FCW_DEFAULT               0x037f
> +#define MXCSR_DEFAULT             0x1f80
> +
>  #define XSTATE_CPUID              0x0000000d
>  #define XSTATE_FEATURE_XSAVEOPT   (1 << 0)    /* sub-leaf 1, eax[bit 0] */
>  
> @@ -46,7 +49,29 @@ extern u64 xfeature_mask;
>  /* extended state save area */
>  struct xsave_struct
>  {
> -    struct { char x[512]; } fpu_sse;         /* FPU/MMX, SSE */
> +    union {                                  /* FPU/MMX, SSE */
> +        char x[512];
> +        struct {
> +            uint16_t fcw;
> +            uint16_t fsw;
> +            uint8_t ftw;
> +            uint8_t rsvd1;
> +            uint16_t fop;
> +            union {
> +#ifdef __x86_64__
> +                uint64_t addr;
> +#endif
> +                struct {
> +                    uint32_t offs;
> +                    uint16_t sel;
> +                    uint16_t rsvd;
> +                };
> +            } fip, fdp;
> +            uint32_t mxcsr;
> +            uint32_t mxcsr_mask;
> +            /* data registers follow here */
> +        };
> +    } fpu_sse;
>  
>      struct {
>          u64 xstate_bv;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:31:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:31:02 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5ni-0002Df-Lz
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5nQ-0003aZ-0T; Thu, 17 Nov 2011 09:30:44 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5n7-0003Wb-HO
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:30:27 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321551021!4552718!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23604 invoked from network); 17 Nov 2011 17:30:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 17:30:22 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHHUI1c020303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 17:30:19 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHHUHDS024683
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 17:30:17 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHHUBnb008888; Thu, 17 Nov 2011 11:30:11 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 09:30:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4DCFB81489; Thu, 17 Nov 2011 12:30:10 -0500 (EST)
Date: Thu, 17 Nov 2011 12:30:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben.guthro@virtualcomputer.com>
Subject: Re: [Xen-devel] ioperm problem
Message-ID: <20111117173010.GA3623@phenom.dumpdata.com>
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
	<4EC51292.7000302@virtualcomputer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4EC51292.7000302@virtualcomputer.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4EC544AB.01AA,ss=1,re=0.000,fgs=0
Cc: Pavel =?utf-8?Q?Mat=C4=9Bja?= <pavel@netsafe.cz>,
	xen-devel@lists.xensource.com, tom.goetz@virtualcomputer.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 08:56:34AM -0500, Ben Guthro wrote:
> Attached is our patch to work around issues with the ioports with
> some older nVidia cards.
>=20
> This, admittedly is a bit of a hack, and not exactly something that
> I would see upstream wanting to carry, for a variety of reasons. It
> really should all be predicated on whether the kernel is the initial
> domain, etc.
>=20
> This opens up the legacy VGA ports in the VGA arbiter code.

Was there a userspace program that did this? As in it would
call ioperm?

>=20
> Konrad - I think that you had suggested an alternate way of doing
> this, IIRC, but I can't seem to find it in my inbox. Due to
> competing demands, and my nVidia hardware disappearing, I never went
> back to rework this code.

Ah, I might have some code that I just uncovered from Jeremy's old
git tree.

I've put it up on devel/ioperm - it nicely wraps the ioperm
call to go the native or paravirt.

>=20
> As written, however, it did solve the problem at hand - however
> hacky it may be.

<nods>

Pavel,

Can you try to merge the #devel/ioperm patches in your tree and see
if they fix your problem?

The git tree is at git://git.kernel.org/pub/scm/linux/kernel/git/konrad/x=
en.git
>=20
> /btg
>=20
> On 11/16/2011 09:57 AM, Konrad Rzeszutek Wilk wrote:
> >On Sun, Nov 13, 2011 at 10:19:06PM +0100, Pavel Mat=C4=9Bja wrote:
> >>Hi,
> >>I'm trying to port AMD VGA passthru patch to the latest XEN and vanil=
a kernel
> >>and I got SIGSEGV in
> >>
> >>static void ati_hw_out(uint16_t hport, uint32_t data)
> >>{
> >>     ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 1);
> >>     asm volatile ("out %1, %0"::"Nd"(hport),"a"(data));
> >>     ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 0);
> >>}
> >
> >Does it work under baremetal?
> >
> >What is the host_pio_base?
> >
> >Is the host_pio_base part of the permitted IO ports? (you can
> >see that if you run 'xl debug-keys q' and it should show you something
> >like this:
> >
> >(XEN) Rangesets belonging to domain 1:
> >(XEN)     I/O Ports  { b400-b41f, b800-b81f }
> >(XEN)     Interrupts { 18-19, 54-55 }
> >(XEN)     I/O Memory { fe940-fe9ff }
> >(XEN) Memory pages belonging to domain 1:
> >
> >(you can get that from xm dmesg).
> >
> >As you can see, the b400->b41f are allowed in the domain 1. Is your
> >host_pio_base in there?
> >
> >
> >>
> >>I tried old 2.6.32 XEN kernel and there is no such problem.
> >>It looks related to arch/x86/kernel/ioport.c but I'm not sure.
> >>Is anyone here familiar with that code?
> >
> >Yes, and I think I saw somebody ask me about that too.
> >
> >Lets rope them in this converstation - they got it to work
> >but my memory is foggy at what was required.
> >
> >Ben, Thomas,
> >
> >I remember you guys had a tough time with vd86 which did something sim=
ilar
> >and it ultimately was due to to /dev/mem not passing in VM_IO. But the
> >ioperm/outb sounds familiar too. Was there a missing hypercall when
> >forking/copying the ioperm bitmap?

> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index ace2b16..d488426 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -421,6 +421,50 @@ bail:
>  }
>  EXPORT_SYMBOL(vga_put);
> =20
> +#ifdef CONFIG_XEN
> +#include <xen/xen.h>
> +#include <xen/interface/physdev.h>
> +#include <xen/interface/xen.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +
> +#define IO_BITMAP_BITS 65536
> +#define IO_BITMAP_BYTES (IO_BITMAP_BITS/8)
> +
> +#define VGA_START_PORT 0x3B0
> +#define VGA_END_PORT 0x3DF
> +
> +static void
> +vga_ioport_map(struct pci_dev *pdev)
> +{
> +	unsigned int i, j;
> +	struct physdev_set_iobitmap op;
> +	uint8_t *bitmap;
> +
> +	bitmap =3D kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
> +	memset(bitmap, 0xff, IO_BITMAP_BYTES);
> +
> +	/* PCI io bars */
> +	for (i =3D 0; i < PCI_NUM_RESOURCES; i++)
> +		if (pci_resource_flags(pdev, i) & IORESOURCE_IO)
> +			for (j =3D pci_resource_start(pdev, i);
> +				j <=3D pci_resource_end(pdev, i); j++)
> +				__clear_bit(j, (unsigned long*)bitmap);
> +
> +	/* legacy vga */
> +	for (i =3D VGA_START_PORT; i <=3D VGA_END_PORT; i++)
> +		__clear_bit(i, (unsigned long*)bitmap);
> +
> +	op.bitmap =3D bitmap;
> +	op.nr_ports =3D IO_BITMAP_BITS;
> +	if(HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, &op) !=3D 0)
> +		pr_info("PHYSDEVOP_set_iobitmap failed\n");
> +
> +}
> +#else
> +#define vga_ioport_map(x)
> +#endif
> +
>  /*
>   * Currently, we assume that the "initial" setup of the system is
>   * not sane, that is we come up with conflicting devices and let
> @@ -509,6 +553,7 @@ static bool vga_arbiter_add_pci_device(struct pci_d=
ev *pdev)
>  		vga_iostate_to_str(vgadev->owns),
>  		vga_iostate_to_str(vgadev->locks));
> =20
> +	vga_ioport_map(pdev);
>  	spin_unlock_irqrestore(&vga_lock, flags);
>  	return true;
>  fail:

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


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:31:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:31:02 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5ni-0002Df-Lz
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5nQ-0003aZ-0T; Thu, 17 Nov 2011 09:30:44 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5n7-0003Wb-HO
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:30:27 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321551021!4552718!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23604 invoked from network); 17 Nov 2011 17:30:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 17:30:22 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHHUI1c020303
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 17:30:19 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHHUHDS024683
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 17:30:17 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHHUBnb008888; Thu, 17 Nov 2011 11:30:11 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 09:30:11 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4DCFB81489; Thu, 17 Nov 2011 12:30:10 -0500 (EST)
Date: Thu, 17 Nov 2011 12:30:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben.guthro@virtualcomputer.com>
Subject: Re: [Xen-devel] ioperm problem
Message-ID: <20111117173010.GA3623@phenom.dumpdata.com>
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
	<4EC51292.7000302@virtualcomputer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4EC51292.7000302@virtualcomputer.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4EC544AB.01AA,ss=1,re=0.000,fgs=0
Cc: Pavel =?utf-8?Q?Mat=C4=9Bja?= <pavel@netsafe.cz>,
	xen-devel@lists.xensource.com, tom.goetz@virtualcomputer.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 08:56:34AM -0500, Ben Guthro wrote:
> Attached is our patch to work around issues with the ioports with
> some older nVidia cards.
>=20
> This, admittedly is a bit of a hack, and not exactly something that
> I would see upstream wanting to carry, for a variety of reasons. It
> really should all be predicated on whether the kernel is the initial
> domain, etc.
>=20
> This opens up the legacy VGA ports in the VGA arbiter code.

Was there a userspace program that did this? As in it would
call ioperm?

>=20
> Konrad - I think that you had suggested an alternate way of doing
> this, IIRC, but I can't seem to find it in my inbox. Due to
> competing demands, and my nVidia hardware disappearing, I never went
> back to rework this code.

Ah, I might have some code that I just uncovered from Jeremy's old
git tree.

I've put it up on devel/ioperm - it nicely wraps the ioperm
call to go the native or paravirt.

>=20
> As written, however, it did solve the problem at hand - however
> hacky it may be.

<nods>

Pavel,

Can you try to merge the #devel/ioperm patches in your tree and see
if they fix your problem?

The git tree is at git://git.kernel.org/pub/scm/linux/kernel/git/konrad/x=
en.git
>=20
> /btg
>=20
> On 11/16/2011 09:57 AM, Konrad Rzeszutek Wilk wrote:
> >On Sun, Nov 13, 2011 at 10:19:06PM +0100, Pavel Mat=C4=9Bja wrote:
> >>Hi,
> >>I'm trying to port AMD VGA passthru patch to the latest XEN and vanil=
a kernel
> >>and I got SIGSEGV in
> >>
> >>static void ati_hw_out(uint16_t hport, uint32_t data)
> >>{
> >>     ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 1);
> >>     asm volatile ("out %1, %0"::"Nd"(hport),"a"(data));
> >>     ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 0);
> >>}
> >
> >Does it work under baremetal?
> >
> >What is the host_pio_base?
> >
> >Is the host_pio_base part of the permitted IO ports? (you can
> >see that if you run 'xl debug-keys q' and it should show you something
> >like this:
> >
> >(XEN) Rangesets belonging to domain 1:
> >(XEN)     I/O Ports  { b400-b41f, b800-b81f }
> >(XEN)     Interrupts { 18-19, 54-55 }
> >(XEN)     I/O Memory { fe940-fe9ff }
> >(XEN) Memory pages belonging to domain 1:
> >
> >(you can get that from xm dmesg).
> >
> >As you can see, the b400->b41f are allowed in the domain 1. Is your
> >host_pio_base in there?
> >
> >
> >>
> >>I tried old 2.6.32 XEN kernel and there is no such problem.
> >>It looks related to arch/x86/kernel/ioport.c but I'm not sure.
> >>Is anyone here familiar with that code?
> >
> >Yes, and I think I saw somebody ask me about that too.
> >
> >Lets rope them in this converstation - they got it to work
> >but my memory is foggy at what was required.
> >
> >Ben, Thomas,
> >
> >I remember you guys had a tough time with vd86 which did something sim=
ilar
> >and it ultimately was due to to /dev/mem not passing in VM_IO. But the
> >ioperm/outb sounds familiar too. Was there a missing hypercall when
> >forking/copying the ioperm bitmap?

> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index ace2b16..d488426 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -421,6 +421,50 @@ bail:
>  }
>  EXPORT_SYMBOL(vga_put);
> =20
> +#ifdef CONFIG_XEN
> +#include <xen/xen.h>
> +#include <xen/interface/physdev.h>
> +#include <xen/interface/xen.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +
> +#define IO_BITMAP_BITS 65536
> +#define IO_BITMAP_BYTES (IO_BITMAP_BITS/8)
> +
> +#define VGA_START_PORT 0x3B0
> +#define VGA_END_PORT 0x3DF
> +
> +static void
> +vga_ioport_map(struct pci_dev *pdev)
> +{
> +	unsigned int i, j;
> +	struct physdev_set_iobitmap op;
> +	uint8_t *bitmap;
> +
> +	bitmap =3D kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
> +	memset(bitmap, 0xff, IO_BITMAP_BYTES);
> +
> +	/* PCI io bars */
> +	for (i =3D 0; i < PCI_NUM_RESOURCES; i++)
> +		if (pci_resource_flags(pdev, i) & IORESOURCE_IO)
> +			for (j =3D pci_resource_start(pdev, i);
> +				j <=3D pci_resource_end(pdev, i); j++)
> +				__clear_bit(j, (unsigned long*)bitmap);
> +
> +	/* legacy vga */
> +	for (i =3D VGA_START_PORT; i <=3D VGA_END_PORT; i++)
> +		__clear_bit(i, (unsigned long*)bitmap);
> +
> +	op.bitmap =3D bitmap;
> +	op.nr_ports =3D IO_BITMAP_BITS;
> +	if(HYPERVISOR_physdev_op(PHYSDEVOP_set_iobitmap, &op) !=3D 0)
> +		pr_info("PHYSDEVOP_set_iobitmap failed\n");
> +
> +}
> +#else
> +#define vga_ioport_map(x)
> +#endif
> +
>  /*
>   * Currently, we assume that the "initial" setup of the system is
>   * not sane, that is we come up with conflicting devices and let
> @@ -509,6 +553,7 @@ static bool vga_arbiter_add_pci_device(struct pci_d=
ev *pdev)
>  		vga_iostate_to_str(vgadev->owns),
>  		vga_iostate_to_str(vgadev->locks));
> =20
> +	vga_ioport_map(pdev);
>  	spin_unlock_irqrestore(&vga_lock, flags);
>  	return true;
>  fail:

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


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:33:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:33:19 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5pu-0002Ds-8Q
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5pb-000404-RP; Thu, 17 Nov 2011 09:32:59 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5pX-0003zB-4n
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:32:55 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321551172!4553088!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30121 invoked from network); 17 Nov 2011 17:32:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 17:32:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315180800"; 
   d="scan'208";a="8996308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 17:32:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 17:32:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RR5pT-000766-35;
	Thu, 17 Nov 2011 17:32:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RR5pT-0006CT-2R;
	Thu, 17 Nov 2011 17:32:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9851-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 17 Nov 2011 17:32:51 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9851: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10     fail REGR. vs. 9756
 test-i386-i386-win           14 guest-start.2              fail REGR. vs. 9756

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

version targeted for testing:
 xen                  e73ada19a69d
baseline version:
 xen                  9702967e89dd

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Gianluca Guida <gianluca.guida@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   23189:e73ada19a69d
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:13:25 2011 +0000
    
    Hypercall continuation cancelation in compat mode for XENMEM_get/set_pod_target
    
    If copy_to_guest failed in the compat code after a continuation as
    been done in the native code we need to cancel it so we won't
    reexecute the hypercall but return from the hypercall with the
    appropriate error.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24116:a095cf28f2b6
    xen-unstable date:        Fri Nov 11 10:14:22 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23188:344dddd4160b
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:12:00 2011 +0000
    
    xsm: Add support for HVMOP_track_dirty_vram.
    
    Xen try to inforce the xsm policy when a HVMOP_track_dirty_vram
    is received (xen/arch/x86/hvm/hvm.c:3637). It was failing because
    in flask_hvmcontext, xsm didn't have any case for this operation.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24107:fb1b32c9d03d
    xen-unstable date:        Tue Nov 08 19:41:47 2011 +0000
    
    
changeset:   23187:1bbf2940ef61
user:        Keir Fraser <keir@xen.org>
date:        Thu Nov 17 09:10:07 2011 +0000
    
    Revert 23183:98ba0aceaf30 (xen-unstable:24007:0526644ad2a6).
    
    Locking is broken (calls evtchn_unmask with lock already held).
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23186:51f58b210447
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Nov 16 16:39:02 2011 +0000
    
    x86-64/test_x86_emulate: fix blowfish test
    
    Incorrect register usage in the _start() wrapper caused the 64-bit
    execution emulation to fail.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24149:753b21aa4087
    xen-unstable date:        Wed Nov 16 15:20:25 2011 +0000
    
    
changeset:   23185:efd132eee40c
user:        Gianluca Guida <gianluca.guida@citrix.com>
date:        Wed Nov 16 16:38:27 2011 +0000
    
    [shadow] Disable higher level pagetables early unshadow only when the "process dying" hypercall is used.
    
    This patch fixes a performance problem in fully virtualized guests.
    
    Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>
    Tested-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24148:3ecc8fef4281
    xen-unstable date:        Wed Nov 16 15:19:33 2011 +0000
    
    
changeset:   23184:4a91cf045893
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 16 16:37:49 2011 +0000
    
    xen: avoid crash enabling turbo mode
    
    On a system which has not had P-state information pushed down into the
    hypervisor running "xenpm enable-turbo-mode" will reliably crash the
    host.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24144:cd3ef25f207a
    xen-unstable date:        Tue Nov 15 14:24:38 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23183:98ba0aceaf30
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Wed Nov 16 16:33:58 2011 +0000
    
    x86: re-inject emulated level pirqs in PV on HVM guests if still asserted
    
    PV on HVM guests can loose level interrupts coming from emulated
    devices if they have been remapped onto event channels.  The reason is
    that we are missing the code to inject a pirq again in the guest when
    the guest EOIs it, if it corresponds to an emulated level interrupt
    and the interrupt is still asserted.
    
    Fix this issue and also return error when the guest tries to get the
    irq_status of a non-existing pirq.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24007:0526644ad2a6
    xen-unstable date:        Thu Oct 27 16:07:18 2011 +0100
    
    
changeset:   23182:9702967e89dd
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Sat Nov 12 16:14:02 2011 +0000
    
    Revert c/s 23666:b96f8bdcaa15 KEXEC: disconnect all PCI devices from the PCI bus on crash
    
    It turns out that this causes all mannor of problems on certain
    motherboards (so far with no pattern I can discern)
    
    Problems include:
    * Hanging forever checking hlt instruction.
    * Panics when trying to change switch root device
    * Drivers hanging when trying to check for interrupts.
    
    From: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24137:0844b17df7a9
    xen-unstable date:        Fri Nov 11 18:14:35 2011 +0000
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:33:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:33:19 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5pu-0002Ds-8Q
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5pb-000404-RP; Thu, 17 Nov 2011 09:32:59 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5pX-0003zB-4n
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:32:55 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321551172!4553088!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30121 invoked from network); 17 Nov 2011 17:32:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 17:32:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315180800"; 
   d="scan'208";a="8996308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 17:32:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 17:32:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RR5pT-000766-35;
	Thu, 17 Nov 2011 17:32:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RR5pT-0006CT-2R;
	Thu, 17 Nov 2011 17:32:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9851-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 17 Nov 2011 17:32:51 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9851: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10     fail REGR. vs. 9756
 test-i386-i386-win           14 guest-start.2              fail REGR. vs. 9756

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

version targeted for testing:
 xen                  e73ada19a69d
baseline version:
 xen                  9702967e89dd

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Gianluca Guida <gianluca.guida@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   23189:e73ada19a69d
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:13:25 2011 +0000
    
    Hypercall continuation cancelation in compat mode for XENMEM_get/set_pod_target
    
    If copy_to_guest failed in the compat code after a continuation as
    been done in the native code we need to cancel it so we won't
    reexecute the hypercall but return from the hypercall with the
    appropriate error.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24116:a095cf28f2b6
    xen-unstable date:        Fri Nov 11 10:14:22 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23188:344dddd4160b
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:12:00 2011 +0000
    
    xsm: Add support for HVMOP_track_dirty_vram.
    
    Xen try to inforce the xsm policy when a HVMOP_track_dirty_vram
    is received (xen/arch/x86/hvm/hvm.c:3637). It was failing because
    in flask_hvmcontext, xsm didn't have any case for this operation.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24107:fb1b32c9d03d
    xen-unstable date:        Tue Nov 08 19:41:47 2011 +0000
    
    
changeset:   23187:1bbf2940ef61
user:        Keir Fraser <keir@xen.org>
date:        Thu Nov 17 09:10:07 2011 +0000
    
    Revert 23183:98ba0aceaf30 (xen-unstable:24007:0526644ad2a6).
    
    Locking is broken (calls evtchn_unmask with lock already held).
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23186:51f58b210447
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Nov 16 16:39:02 2011 +0000
    
    x86-64/test_x86_emulate: fix blowfish test
    
    Incorrect register usage in the _start() wrapper caused the 64-bit
    execution emulation to fail.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24149:753b21aa4087
    xen-unstable date:        Wed Nov 16 15:20:25 2011 +0000
    
    
changeset:   23185:efd132eee40c
user:        Gianluca Guida <gianluca.guida@citrix.com>
date:        Wed Nov 16 16:38:27 2011 +0000
    
    [shadow] Disable higher level pagetables early unshadow only when the "process dying" hypercall is used.
    
    This patch fixes a performance problem in fully virtualized guests.
    
    Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>
    Tested-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24148:3ecc8fef4281
    xen-unstable date:        Wed Nov 16 15:19:33 2011 +0000
    
    
changeset:   23184:4a91cf045893
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 16 16:37:49 2011 +0000
    
    xen: avoid crash enabling turbo mode
    
    On a system which has not had P-state information pushed down into the
    hypervisor running "xenpm enable-turbo-mode" will reliably crash the
    host.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24144:cd3ef25f207a
    xen-unstable date:        Tue Nov 15 14:24:38 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23183:98ba0aceaf30
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Wed Nov 16 16:33:58 2011 +0000
    
    x86: re-inject emulated level pirqs in PV on HVM guests if still asserted
    
    PV on HVM guests can loose level interrupts coming from emulated
    devices if they have been remapped onto event channels.  The reason is
    that we are missing the code to inject a pirq again in the guest when
    the guest EOIs it, if it corresponds to an emulated level interrupt
    and the interrupt is still asserted.
    
    Fix this issue and also return error when the guest tries to get the
    irq_status of a non-existing pirq.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24007:0526644ad2a6
    xen-unstable date:        Thu Oct 27 16:07:18 2011 +0100
    
    
changeset:   23182:9702967e89dd
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Sat Nov 12 16:14:02 2011 +0000
    
    Revert c/s 23666:b96f8bdcaa15 KEXEC: disconnect all PCI devices from the PCI bus on crash
    
    It turns out that this causes all mannor of problems on certain
    motherboards (so far with no pattern I can discern)
    
    Problems include:
    * Hanging forever checking hlt instruction.
    * Panics when trying to change switch root device
    * Drivers hanging when trying to check for interrupts.
    
    From: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24137:0844b17df7a9
    xen-unstable date:        Fri Nov 11 18:14:35 2011 +0000
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:36:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:36:59 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5tT-0002E5-Am
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:36:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5tA-0004YR-0l; Thu, 17 Nov 2011 09:36:40 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5t5-0004XQ-Mi
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:36:36 -0800
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321551392!3940516!1
X-Originating-IP: [81.2.110.250]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25750 invoked from network); 17 Nov 2011 17:36:32 -0000
Received: from earthlight.etchedpixels.co.uk (HELO
	earthlight.etchedpixels.co.uk) (81.2.110.250)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 17:36:32 -0000
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by earthlight.etchedpixels.co.uk (8.14.5/8.14.4) with ESMTP id
	pAHHbppP006490; Thu, 17 Nov 2011 17:37:51 GMT
Date: Thu, 17 Nov 2011 17:37:50 +0000
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] ioperm problem
Message-ID: <20111117173750.7461b0b0@lxorguk.ukuu.org.uk>
In-Reply-To: <20111117173010.GA3623@phenom.dumpdata.com>
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
	<4EC51292.7000302@virtualcomputer.com>
	<20111117173010.GA3623@phenom.dumpdata.com>
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.7; x86_64-redhat-linux-gnu)
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII=
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: =?UTF-8?B?YQ==?= <pavel@netsafe.cz>, Pavel, xen-devel@lists.xensource.com,
	tom.goetz@virtualcomputer.com, Ben Guthro <ben.guthro@virtualcomputer.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > This opens up the legacy VGA ports in the VGA arbiter code.
> 
> Was there a userspace program that did this? As in it would
> call ioperm?

Not necessarily there is also a priviledged interface via the console for
historical reasons

For the legacy VGA ports the proper approach is almost certainly to scan
the PCI bus routing data and work out which device they are routed to and
then attach them to that physical device.

That may be a dynamic configuration but you'll see the virtualisation of
the PCI config changes any guest tries to do if so.

Alan

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 17:36:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 17:36:59 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR5tT-0002E5-Am
	for archives@lists.xen.org; Thu, 17 Nov 2011 17:36:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR5tA-0004YR-0l; Thu, 17 Nov 2011 09:36:40 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR5t5-0004XQ-Mi
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 09:36:36 -0800
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321551392!3940516!1
X-Originating-IP: [81.2.110.250]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25750 invoked from network); 17 Nov 2011 17:36:32 -0000
Received: from earthlight.etchedpixels.co.uk (HELO
	earthlight.etchedpixels.co.uk) (81.2.110.250)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 17:36:32 -0000
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by earthlight.etchedpixels.co.uk (8.14.5/8.14.4) with ESMTP id
	pAHHbppP006490; Thu, 17 Nov 2011 17:37:51 GMT
Date: Thu, 17 Nov 2011 17:37:50 +0000
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] ioperm problem
Message-ID: <20111117173750.7461b0b0@lxorguk.ukuu.org.uk>
In-Reply-To: <20111117173010.GA3623@phenom.dumpdata.com>
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
	<4EC51292.7000302@virtualcomputer.com>
	<20111117173010.GA3623@phenom.dumpdata.com>
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.7; x86_64-redhat-linux-gnu)
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWysKsSBQMIAwIZCwj///8wIhxoRDXH9QHCAAABeUlEQVQ4jaXTvW7DIBAAYCQTzz2hdq+rdg494ZmBeE5KYHZjm/d/hJ6NfzBJpp5kRb5PHJwvMPMk2L9As5Y9AmYRBL+HAyJKeOU5aHRhsAAvORQ+UEgAvgddj/lwAXndw2laEDqA4x6KEBhjYRCg9tBFCOuJFxg2OKegbWjbsRTk8PPhKPD7HcRxB7cqhgBRp9Dcqs+B8v4CQvFdqeot3Kov6hBUn0AJitrzY+sgUuiA8i0r7+B3AfqKcN6t8M6HtqQ+AOoELCikgQSbgabKaJW3kn5lBs47JSGDhhLKDUh1UMipwwinMYPTBuIBjEclSaGZUk9hDlTb5sUTYN2SFFQuPe4Gox1X0FZOufjgBiV1Vls7b+GvK3SU4wfmcGo9rPPQzgIabfj4TYQo15k3bTHX9RIw/kniir5YbtJF4jkFG+dsDK1IgE413zAthU/vR2HVMmFUPIHTvF6jWCpFaGw/A3qWgnbxpSm9MSmY5b3pM1gvNc/gQfwBsGwF0VCtxZgAAAAASUVORK5CYII=
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: =?UTF-8?B?YQ==?= <pavel@netsafe.cz>, Pavel, xen-devel@lists.xensource.com,
	tom.goetz@virtualcomputer.com, Ben Guthro <ben.guthro@virtualcomputer.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > This opens up the legacy VGA ports in the VGA arbiter code.
> 
> Was there a userspace program that did this? As in it would
> call ioperm?

Not necessarily there is also a priviledged interface via the console for
historical reasons

For the legacy VGA ports the proper approach is almost certainly to scan
the PCI bus routing data and work out which device they are routed to and
then attach them to that physical device.

That may be a dynamic configuration but you'll see the virtualisation of
the PCI config changes any guest tries to do if so.

Alan

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 18:07:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 18:07:22 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR6Ms-0002EN-NP
	for archives@lists.xen.org; Thu, 17 Nov 2011 18:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR6MV-0005Ud-37; Thu, 17 Nov 2011 10:06:59 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR6Lh-0005TE-RS
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 10:06:12 -0800
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321553062!52660510!1
X-Originating-IP: [74.207.240.146]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21324 invoked from network); 17 Nov 2011 18:04:24 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 18:04:24 -0000
Received: from saboo.goop.org (adsl-69-107-85-166.dsl.pltn13.pacbell.net
	[69.107.85.166]) (Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id EE08091CD;
	Thu, 17 Nov 2011 10:06:03 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 38EB520283;
	Thu, 17 Nov 2011 10:05:57 -0800 (PST)
Message-ID: <4EC54D05.3050308@goop.org>
Date: Thu, 17 Nov 2011 10:05:57 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] ioperm problem
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
	<4EC51292.7000302@virtualcomputer.com>
	<20111117173010.GA3623@phenom.dumpdata.com>
In-Reply-To: <20111117173010.GA3623@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: =?UTF-8?B?amE=?= <pavel@netsafe.cz>, =?UTF-8?B?UGF2ZWwgTWF0xJs=?=,
	xen-devel@lists.xensource.com, tom.goetz@virtualcomputer.com,
	Ben Guthro <ben.guthro@virtualcomputer.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/17/2011 09:30 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 17, 2011 at 08:56:34AM -0500, Ben Guthro wrote:
>> Attached is our patch to work around issues with the ioports with
>> some older nVidia cards.
>>
>> This, admittedly is a bit of a hack, and not exactly something that
>> I would see upstream wanting to carry, for a variety of reasons. It
>> really should all be predicated on whether the kernel is the initial
>> domain, etc.
>>
>> This opens up the legacy VGA ports in the VGA arbiter code.
> Was there a userspace program that did this? As in it would
> call ioperm?
>
>> Konrad - I think that you had suggested an alternate way of doing
>> this, IIRC, but I can't seem to find it in my inbox. Due to
>> competing demands, and my nVidia hardware disappearing, I never went
>> back to rework this code.
> Ah, I might have some code that I just uncovered from Jeremy's old
> git tree.
>
> I've put it up on devel/ioperm - it nicely wraps the ioperm
> call to go the native or paravirt.

Yeah, I'd sort of let that sit, since there's nothing in a "modern"
system which should require it.  Allowing usermode to poke at ioports
from within a domain is inherently suspect, after all.

    J

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 18:07:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 18:07:22 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR6Ms-0002EN-NP
	for archives@lists.xen.org; Thu, 17 Nov 2011 18:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR6MV-0005Ud-37; Thu, 17 Nov 2011 10:06:59 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR6Lh-0005TE-RS
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 10:06:12 -0800
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321553062!52660510!1
X-Originating-IP: [74.207.240.146]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21324 invoked from network); 17 Nov 2011 18:04:24 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 18:04:24 -0000
Received: from saboo.goop.org (adsl-69-107-85-166.dsl.pltn13.pacbell.net
	[69.107.85.166]) (Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id EE08091CD;
	Thu, 17 Nov 2011 10:06:03 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 38EB520283;
	Thu, 17 Nov 2011 10:05:57 -0800 (PST)
Message-ID: <4EC54D05.3050308@goop.org>
Date: Thu, 17 Nov 2011 10:05:57 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] ioperm problem
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
	<4EC51292.7000302@virtualcomputer.com>
	<20111117173010.GA3623@phenom.dumpdata.com>
In-Reply-To: <20111117173010.GA3623@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: =?UTF-8?B?amE=?= <pavel@netsafe.cz>, =?UTF-8?B?UGF2ZWwgTWF0xJs=?=,
	xen-devel@lists.xensource.com, tom.goetz@virtualcomputer.com,
	Ben Guthro <ben.guthro@virtualcomputer.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/17/2011 09:30 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 17, 2011 at 08:56:34AM -0500, Ben Guthro wrote:
>> Attached is our patch to work around issues with the ioports with
>> some older nVidia cards.
>>
>> This, admittedly is a bit of a hack, and not exactly something that
>> I would see upstream wanting to carry, for a variety of reasons. It
>> really should all be predicated on whether the kernel is the initial
>> domain, etc.
>>
>> This opens up the legacy VGA ports in the VGA arbiter code.
> Was there a userspace program that did this? As in it would
> call ioperm?
>
>> Konrad - I think that you had suggested an alternate way of doing
>> this, IIRC, but I can't seem to find it in my inbox. Due to
>> competing demands, and my nVidia hardware disappearing, I never went
>> back to rework this code.
> Ah, I might have some code that I just uncovered from Jeremy's old
> git tree.
>
> I've put it up on devel/ioperm - it nicely wraps the ioperm
> call to go the native or paravirt.

Yeah, I'd sort of let that sit, since there's nothing in a "modern"
system which should require it.  Allowing usermode to poke at ioports
from within a domain is inherently suspect, after all.

    J

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 18:58:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 18:58:32 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR7AO-0002Ep-9q
	for archives@lists.xen.org; Thu, 17 Nov 2011 18:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR79t-0006xh-Bs; Thu, 17 Nov 2011 10:58:07 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR79Z-0006wa-Q0
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 10:57:42 -0800
X-Env-Sender: miche@google.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1321556257!2006617!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30470 invoked from network); 17 Nov 2011 18:57:38 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 18:57:38 -0000
Received: by yenl7 with SMTP id l7so2286419yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 10:57:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=lBoQl2+MCxoulwFrM8aoHDyiQWbblSYeygOGMkKwOPM=;
	b=L976SNFKPsNFIuaa+uJTssBidfsqtjaFJr6LMoETgCgXy0VATAB4gDLmEkD//2dpnH
	lcygvJkFj7qN5eqvLAmA==
Received: by 10.224.215.73 with SMTP id hd9mr23264322qab.94.1321556257255;
	Thu, 17 Nov 2011 10:57:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.215.73 with SMTP id hd9mr23264297qab.94.1321556257111;
	Thu, 17 Nov 2011 10:57:37 -0800 (PST)
Received: by 10.229.175.10 with HTTP; Thu, 17 Nov 2011 10:57:37 -0800 (PST)
In-Reply-To: <874nybqo0o.fsf@rustcorp.com.au>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
Date: Thu, 17 Nov 2011 10:57:37 -0800
Message-ID: <CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Amit Shah <amit.shah@redhat.com>,
	Mike Waychison <mikew@google.com>, ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Eric Northrup <digitaleric@google.com>
Subject: [Xen-devel] Re: [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Rusty, Michael, Stephen, et al,

Thanks for your comments on these patches.

For what I'm trying to do, all three patches are necessary, but maybe
I'm going about it the wrong way. Your input would be appreciated.
I'm in no way claiming that these patches are "right", just that it's
working for me, and that what's in the current pool is not.

What I'm trying to do is:
On X86,
under KVM,
start a virtio console device,
with multiple ports on the device,
at least one of which is also a console (as well as ttyS0).

(Eventually, we want to be able to add virtio console ports on the
fly, and to have multiple virtio console ports be consoles.)

When all three of the patches are in place, this works great. (By
great, I mean that getty's start up on all of ttyS0, hvc0 and hvc1,
and console output goes to ttyS0 and to hvc0.
"who" shows three users: =A0ttyS0, hvc0, and hvc1.
"cat /proc/consoles" shows both ttyS0 and hvc0.
I can use all three getty's, and console output really does appear on
both the consoles.

Based on Rusty's comments, I tried removing each of the patches
individually. Here's what happens today. I've seen other failure modes
depending on what precisely I'm passing the guest.
There's three patches:
1/3 "fix locking of vtermno"
2/3 "enforce one-time initialization with hvc_init
"3/3 "use separate struct console * for each console"

If I remove the "fix locking of vtermno", I only get one virtio
console terminal. =A0"who" shows the ttyS0 and the hvc0, and I can log
into the gettys on both. I don't get the second virtio console getty.
Interestingly, hvc0 shows up in /proc/consoles twice, and in fact the
console output is dumped twice to hvc0 (as you'd expect from looking
at printk.c, each line appears twice, followed by the next line.)

If I remove the "enforce one-time initialization with hvc_init" patch,
which makes sure only a single thread is doing the hvc_init, and gates
anyone from continuing until it has completed, I get different
failures, including hangs, and dereferences of NULL pointers.

If I remove the "use separate struct console * for each console"patch,
what I'm seeing now is that while all of ttyS0, hvc0, and hvc1 are
present with gettys running on them, of the three, only ttyS0 is a
console.

I also re-tried each patch alone:

For either the "fix locking of vtermno" or "use separate struct
console * for each console" patches (in other words, not the "enforce
one-time initialization with hvc_init" patch), I panic during boot
with a null dereference.

For just the "enforce one-time initialization with hvc_init" patch, I
see all of hvc0, hvc1, and ttyS0 in a "who" listing, but only one
getty is available with an hvc.  Also, an echo to *either* "hvc0"
or"hvc1" appears on the single hvc getty. =A0Also, no virtio console
appears in the /proc/consoles list.

Michael, I agree with you about the comment and naming of the mutex
around hvc_init.
Stephen, the duplicate messages are not something I'm seeing. =A0It's
probably the case that there are two "consoles" (registered in printk)
that have the same tty as their target.  I've added a call to
register_console in hvc_alloc, and I'm guessing that something in your
system is making your tty register as a console in hvc_instantiate,
and then it's re-registered in hvc_alloc, but I really am not sure. We
don't have earlyprintk support, so the register_console in
hvc_instantiate is never called.

Miche

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 18:58:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 18:58:32 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR7AO-0002Ep-9q
	for archives@lists.xen.org; Thu, 17 Nov 2011 18:58:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR79t-0006xh-Bs; Thu, 17 Nov 2011 10:58:07 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR79Z-0006wa-Q0
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 10:57:42 -0800
X-Env-Sender: miche@google.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1321556257!2006617!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30470 invoked from network); 17 Nov 2011 18:57:38 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 18:57:38 -0000
Received: by yenl7 with SMTP id l7so2286419yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 10:57:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=lBoQl2+MCxoulwFrM8aoHDyiQWbblSYeygOGMkKwOPM=;
	b=L976SNFKPsNFIuaa+uJTssBidfsqtjaFJr6LMoETgCgXy0VATAB4gDLmEkD//2dpnH
	lcygvJkFj7qN5eqvLAmA==
Received: by 10.224.215.73 with SMTP id hd9mr23264322qab.94.1321556257255;
	Thu, 17 Nov 2011 10:57:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.215.73 with SMTP id hd9mr23264297qab.94.1321556257111;
	Thu, 17 Nov 2011 10:57:37 -0800 (PST)
Received: by 10.229.175.10 with HTTP; Thu, 17 Nov 2011 10:57:37 -0800 (PST)
In-Reply-To: <874nybqo0o.fsf@rustcorp.com.au>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
Date: Thu, 17 Nov 2011 10:57:37 -0800
Message-ID: <CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Amit Shah <amit.shah@redhat.com>,
	Mike Waychison <mikew@google.com>, ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Eric Northrup <digitaleric@google.com>
Subject: [Xen-devel] Re: [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Rusty, Michael, Stephen, et al,

Thanks for your comments on these patches.

For what I'm trying to do, all three patches are necessary, but maybe
I'm going about it the wrong way. Your input would be appreciated.
I'm in no way claiming that these patches are "right", just that it's
working for me, and that what's in the current pool is not.

What I'm trying to do is:
On X86,
under KVM,
start a virtio console device,
with multiple ports on the device,
at least one of which is also a console (as well as ttyS0).

(Eventually, we want to be able to add virtio console ports on the
fly, and to have multiple virtio console ports be consoles.)

When all three of the patches are in place, this works great. (By
great, I mean that getty's start up on all of ttyS0, hvc0 and hvc1,
and console output goes to ttyS0 and to hvc0.
"who" shows three users: =A0ttyS0, hvc0, and hvc1.
"cat /proc/consoles" shows both ttyS0 and hvc0.
I can use all three getty's, and console output really does appear on
both the consoles.

Based on Rusty's comments, I tried removing each of the patches
individually. Here's what happens today. I've seen other failure modes
depending on what precisely I'm passing the guest.
There's three patches:
1/3 "fix locking of vtermno"
2/3 "enforce one-time initialization with hvc_init
"3/3 "use separate struct console * for each console"

If I remove the "fix locking of vtermno", I only get one virtio
console terminal. =A0"who" shows the ttyS0 and the hvc0, and I can log
into the gettys on both. I don't get the second virtio console getty.
Interestingly, hvc0 shows up in /proc/consoles twice, and in fact the
console output is dumped twice to hvc0 (as you'd expect from looking
at printk.c, each line appears twice, followed by the next line.)

If I remove the "enforce one-time initialization with hvc_init" patch,
which makes sure only a single thread is doing the hvc_init, and gates
anyone from continuing until it has completed, I get different
failures, including hangs, and dereferences of NULL pointers.

If I remove the "use separate struct console * for each console"patch,
what I'm seeing now is that while all of ttyS0, hvc0, and hvc1 are
present with gettys running on them, of the three, only ttyS0 is a
console.

I also re-tried each patch alone:

For either the "fix locking of vtermno" or "use separate struct
console * for each console" patches (in other words, not the "enforce
one-time initialization with hvc_init" patch), I panic during boot
with a null dereference.

For just the "enforce one-time initialization with hvc_init" patch, I
see all of hvc0, hvc1, and ttyS0 in a "who" listing, but only one
getty is available with an hvc.  Also, an echo to *either* "hvc0"
or"hvc1" appears on the single hvc getty. =A0Also, no virtio console
appears in the /proc/consoles list.

Michael, I agree with you about the comment and naming of the mutex
around hvc_init.
Stephen, the duplicate messages are not something I'm seeing. =A0It's
probably the case that there are two "consoles" (registered in printk)
that have the same tty as their target.  I've added a call to
register_console in hvc_alloc, and I'm guessing that something in your
system is making your tty register as a console in hvc_instantiate,
and then it's re-registered in hvc_alloc, but I really am not sure. We
don't have earlyprintk support, so the register_console in
hvc_instantiate is never called.

Miche

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 19:03:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 19:03:11 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR7Et-0002F3-92
	for archives@lists.xen.org; Thu, 17 Nov 2011 19:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR7EX-0007Od-QX; Thu, 17 Nov 2011 11:02:49 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with smtp (Exim 4.43) id 1RR7BB-000755-2B
	for Xen-devel@lists.xensource.com; Thu, 17 Nov 2011 10:59:40 -0800
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1321556357!3980775!1
X-Originating-IP: [63.239.65.40]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15163 invoked from network); 17 Nov 2011 18:59:17 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-216.messagelabs.com with SMTP;
	17 Nov 2011 18:59:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAHIxGRv016034
	for <Xen-devel@lists.xensource.com>; Thu, 17 Nov 2011 18:59:16 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAHIxGnq000794; 
	Thu, 17 Nov 2011 13:59:16 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Xen-devel@lists.xensource.com
Date: Thu, 17 Nov 2011 13:59:37 -0500
Message-Id: <1321556377-13335-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.6.4
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] flask: Fix policy build with new checkpolicy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Version 26 of checkpolicy (shipped with Fedora 16) now requires that
roles be declared prior to setting types for a role. Add a declaration
of the system_r role to fix the build of default XSM/FLASK policy.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 0977939..d95a7da 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -151,4 +151,5 @@ sid iomem gen_context(system_u:object_r:iomem_t,s0)
 sid ioport gen_context(system_u:object_r:ioport_t,s0)
 sid device gen_context(system_u:object_r:device_t,s0)
 
+role system_r;
 role system_r types { xen_type domain_type };
-- 
1.7.6.4


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 19:03:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 19:03:11 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR7Et-0002F3-92
	for archives@lists.xen.org; Thu, 17 Nov 2011 19:03:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR7EX-0007Od-QX; Thu, 17 Nov 2011 11:02:49 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with smtp (Exim 4.43) id 1RR7BB-000755-2B
	for Xen-devel@lists.xensource.com; Thu, 17 Nov 2011 10:59:40 -0800
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1321556357!3980775!1
X-Originating-IP: [63.239.65.40]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15163 invoked from network); 17 Nov 2011 18:59:17 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-216.messagelabs.com with SMTP;
	17 Nov 2011 18:59:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAHIxGRv016034
	for <Xen-devel@lists.xensource.com>; Thu, 17 Nov 2011 18:59:16 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAHIxGnq000794; 
	Thu, 17 Nov 2011 13:59:16 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Xen-devel@lists.xensource.com
Date: Thu, 17 Nov 2011 13:59:37 -0500
Message-Id: <1321556377-13335-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.6.4
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] flask: Fix policy build with new checkpolicy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Version 26 of checkpolicy (shipped with Fedora 16) now requires that
roles be declared prior to setting types for a role. Add a declaration
of the system_r role to fix the build of default XSM/FLASK policy.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 0977939..d95a7da 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -151,4 +151,5 @@ sid iomem gen_context(system_u:object_r:iomem_t,s0)
 sid ioport gen_context(system_u:object_r:ioport_t,s0)
 sid device gen_context(system_u:object_r:device_t,s0)
 
+role system_r;
 role system_r types { xen_type domain_type };
-- 
1.7.6.4


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 19:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 19:10:20 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR7Lo-0002GR-7d
	for archives@lists.xen.org; Thu, 17 Nov 2011 19:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR7LR-0007sr-FF; Thu, 17 Nov 2011 11:09:58 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with smtp (Exim 4.43) id 1RR7LA-0007rY-83
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 11:09:40 -0800
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321556976!2010005!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20768 invoked from network); 17 Nov 2011 19:09:36 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	17 Nov 2011 19:09:36 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pAHJ9NWb013773
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 14:09:23 -0500
Received: from localhost (ovpn-113-38.phx2.redhat.com [10.3.113.38])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pAHJ9LBu002860; Thu, 17 Nov 2011 14:09:22 -0500
Date: Fri, 18 Nov 2011 00:39:20 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Message-ID: <20111117190920.GD2873@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214458.28884.86759.stgit@miche.sea.corp.google.com>
	<877h37qo5z.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <877h37qo5z.fsf@rustcorp.com.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Miche Baker-Harvey <miche@google.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Eric Northrup <digitaleric@google.com>
Subject: [Xen-devel] Re: [PATCH v3 1/3] virtio_console: Fix locking of
	vtermno.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Fri) 11 Nov 2011 [14:57:20], Rusty Russell wrote:
> On Tue, 08 Nov 2011 13:44:58 -0800, Miche Baker-Harvey <miche@google.com> wrote:
> > Some modifications of vtermno were not done under the spinlock.
> > 
> > Moved assignment from vtermno and increment of vtermno together,
> > putting both under the spinlock.  Revert vtermno on failure.
> > 
> > Signed-off-by: Miche Baker-Harvey <miche@google.com>
> 
> Does it matter?  It's normal not to lock in a function called
> "init_XXX", since it's not exposed yet.
> 
> Or is it?

Slight misnomer, I suppose.

We do this init_console_port() as part of add_port() if the port is a
console port.  Should it be named 'mark_console_port()'?  Dunno,
doesn't sound like the right name.  init fits closest.

		Amit

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 19:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 19:10:20 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR7Lo-0002GR-7d
	for archives@lists.xen.org; Thu, 17 Nov 2011 19:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR7LR-0007sr-FF; Thu, 17 Nov 2011 11:09:58 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with smtp (Exim 4.43) id 1RR7LA-0007rY-83
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 11:09:40 -0800
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321556976!2010005!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20768 invoked from network); 17 Nov 2011 19:09:36 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	17 Nov 2011 19:09:36 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pAHJ9NWb013773
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 14:09:23 -0500
Received: from localhost (ovpn-113-38.phx2.redhat.com [10.3.113.38])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pAHJ9LBu002860; Thu, 17 Nov 2011 14:09:22 -0500
Date: Fri, 18 Nov 2011 00:39:20 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Message-ID: <20111117190920.GD2873@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214458.28884.86759.stgit@miche.sea.corp.google.com>
	<877h37qo5z.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <877h37qo5z.fsf@rustcorp.com.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Miche Baker-Harvey <miche@google.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Eric Northrup <digitaleric@google.com>
Subject: [Xen-devel] Re: [PATCH v3 1/3] virtio_console: Fix locking of
	vtermno.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Fri) 11 Nov 2011 [14:57:20], Rusty Russell wrote:
> On Tue, 08 Nov 2011 13:44:58 -0800, Miche Baker-Harvey <miche@google.com> wrote:
> > Some modifications of vtermno were not done under the spinlock.
> > 
> > Moved assignment from vtermno and increment of vtermno together,
> > putting both under the spinlock.  Revert vtermno on failure.
> > 
> > Signed-off-by: Miche Baker-Harvey <miche@google.com>
> 
> Does it matter?  It's normal not to lock in a function called
> "init_XXX", since it's not exposed yet.
> 
> Or is it?

Slight misnomer, I suppose.

We do this init_console_port() as part of add_port() if the port is a
console port.  Should it be named 'mark_console_port()'?  Dunno,
doesn't sound like the right name.  init fits closest.

		Amit

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 19:29:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 19:29:07 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR7dy-0002Gf-Vo
	for archives@lists.xen.org; Thu, 17 Nov 2011 19:29:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR7dd-00005C-1d; Thu, 17 Nov 2011 11:28:45 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR7dF-0008Vi-QD
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 11:28:23 -0800
X-Env-Sender: nhorman@tuxdriver.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1321558095!2667813!1
X-Originating-IP: [70.61.120.58]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30719 invoked from network); 17 Nov 2011 19:28:17 -0000
Received: from charlotte.tuxdriver.com (HELO smtp.tuxdriver.com) (70.61.120.58)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 19:28:17 -0000
Received: from hmsreliant.think-freely.org
	([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost)
	by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63)
	(envelope-from <nhorman@tuxdriver.com>)
	id 1RR7bG-0003ta-Vf; Thu, 17 Nov 2011 14:26:30 -0500
Date: Thu, 17 Nov 2011 14:25:35 -0500
From: Neil Horman <nhorman@tuxdriver.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111117192535.GB26847@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1321543238.3664.278.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -1.2 (-)
X-Spam-Status: No
Cc: xen-devel@lists.xensource.com, netdev@vger.kernel.org,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > It was pointed out to me recently that the xen-netfront driver can't safely
> > support shared skbs on transmit, since, while it doesn't maintain skb state
> > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> 
> What are the actual constraints here? The skb is used as a handle to the
> skb->data and shinfo (frags) and to complete at the end. It's actually
> those which are passed to the hypervisor (effectively the same as
> passing those addresses to the h/w for DMA).
> 
> Which parts of the skb are expected/allowed to not remain stable?
> 
> (Appologies if the above seems naive, I seem to have missed the
> introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> 
Its ok, this is the most accurate description from the previous threads on the
subject:
http://lists.openwall.net/netdev/2011/08/22/63

The basic problem boils down the notion that some drivers, when they receive an
skb in their xmit paths, presume to have sole ownership of the skb, and as a
result may do things like add the skb to a list, or otherwise store stateful
data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
holds a reference to the skb, and make make changes without serializing them
against the driver.  So we have to flag those drivers which preform these kinds
of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
an skb, but it does place a pointer to the skb in a data structure here:

np->tx_skbs[id].skb = skb;

Which then gets handed off to the hypervisior.  Since the hypervisor now has
access to that skb pointer, and we can't be sure (from the guest perspective),
what it does with that information, it would be better to be safe by disallowing
shared skbs in this path.

Neil

> Ian.
> 
> > 
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > CC: "David S. Miller" <davem@davemloft.net>
> > CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > CC: xen-devel@lists.xensource.com
> > ---
> >  drivers/net/xen-netfront.c |    6 ++++++
> >  1 files changed, 6 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 226faab..fb1077b 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -1252,6 +1252,12 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
> >  		return ERR_PTR(-ENOMEM);
> >  	}
> >  
> > +	/*
> > +	 * Since frames remain on a queue after a return from xennet_start_xmit,
> > +	 * we can't support tx shared skbs
> > +	 */
> > +	netdev->priv_flags &= ~IFF_TX_SKB_SHARING;
> > +
> >  	np                   = netdev_priv(netdev);
> >  	np->xbdev            = dev;
> >  
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 19:29:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 19:29:07 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR7dy-0002Gf-Vo
	for archives@lists.xen.org; Thu, 17 Nov 2011 19:29:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR7dd-00005C-1d; Thu, 17 Nov 2011 11:28:45 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR7dF-0008Vi-QD
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 11:28:23 -0800
X-Env-Sender: nhorman@tuxdriver.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1321558095!2667813!1
X-Originating-IP: [70.61.120.58]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30719 invoked from network); 17 Nov 2011 19:28:17 -0000
Received: from charlotte.tuxdriver.com (HELO smtp.tuxdriver.com) (70.61.120.58)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 19:28:17 -0000
Received: from hmsreliant.think-freely.org
	([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost)
	by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63)
	(envelope-from <nhorman@tuxdriver.com>)
	id 1RR7bG-0003ta-Vf; Thu, 17 Nov 2011 14:26:30 -0500
Date: Thu, 17 Nov 2011 14:25:35 -0500
From: Neil Horman <nhorman@tuxdriver.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111117192535.GB26847@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1321543238.3664.278.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -1.2 (-)
X-Spam-Status: No
Cc: xen-devel@lists.xensource.com, netdev@vger.kernel.org,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > It was pointed out to me recently that the xen-netfront driver can't safely
> > support shared skbs on transmit, since, while it doesn't maintain skb state
> > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> 
> What are the actual constraints here? The skb is used as a handle to the
> skb->data and shinfo (frags) and to complete at the end. It's actually
> those which are passed to the hypervisor (effectively the same as
> passing those addresses to the h/w for DMA).
> 
> Which parts of the skb are expected/allowed to not remain stable?
> 
> (Appologies if the above seems naive, I seem to have missed the
> introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> 
Its ok, this is the most accurate description from the previous threads on the
subject:
http://lists.openwall.net/netdev/2011/08/22/63

The basic problem boils down the notion that some drivers, when they receive an
skb in their xmit paths, presume to have sole ownership of the skb, and as a
result may do things like add the skb to a list, or otherwise store stateful
data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
holds a reference to the skb, and make make changes without serializing them
against the driver.  So we have to flag those drivers which preform these kinds
of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
an skb, but it does place a pointer to the skb in a data structure here:

np->tx_skbs[id].skb = skb;

Which then gets handed off to the hypervisior.  Since the hypervisor now has
access to that skb pointer, and we can't be sure (from the guest perspective),
what it does with that information, it would be better to be safe by disallowing
shared skbs in this path.

Neil

> Ian.
> 
> > 
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > CC: "David S. Miller" <davem@davemloft.net>
> > CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > CC: xen-devel@lists.xensource.com
> > ---
> >  drivers/net/xen-netfront.c |    6 ++++++
> >  1 files changed, 6 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 226faab..fb1077b 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -1252,6 +1252,12 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
> >  		return ERR_PTR(-ENOMEM);
> >  	}
> >  
> > +	/*
> > +	 * Since frames remain on a queue after a return from xennet_start_xmit,
> > +	 * we can't support tx shared skbs
> > +	 */
> > +	netdev->priv_flags &= ~IFF_TX_SKB_SHARING;
> > +
> >  	np                   = netdev_priv(netdev);
> >  	np->xbdev            = dev;
> >  
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 20:17:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 20:17:39 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR8Ox-0002MS-0j
	for archives@lists.xen.org; Thu, 17 Nov 2011 20:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR8Oc-0001eg-UG; Thu, 17 Nov 2011 12:17:19 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR8BV-0001J0-ND
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 12:03:46 -0800
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321560191!57689770!1
X-Originating-IP: [192.89.123.25]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27174 invoked from network); 17 Nov 2011 20:03:11 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 20:03:11 -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 2F02514FE;
	Thu, 17 Nov 2011 22:03:40 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DE87020058; Thu, 17 Nov 2011 22:03:39 +0200 (EET)
Date: Thu, 17 Nov 2011 22:03:39 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [xen-4.1-testing test] 9805: regressions - FAIL
Message-ID: <20111117200339.GO12984@reaktio.net>
References: <4EC4E1DD.1030309@canonical.com> <CAEA944D.343E5%keir@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEA944D.343E5%keir@xen.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 10:37:01AM +0000, Keir Fraser wrote:
> On 17/11/2011 10:28, "Stefan Bader" <stefan.bader@canonical.com> wrote:
> 
> >>> Hm, yes we should. I am pretty sure I hit that code path often enough,
> >>> Wonder
> >>> why I never saw any dead lock there...
> >> 
> >> Perhaps your dom0 kernel doesn't register a pirq_eoi_map.
> >> 
> > Would be the only explanation. And quite possible. Heck, I would need to know
> > what that is used for anyway. :/ The kernel is 3.0 based the interrupt I was
> > looking at just was a normal apic emulated through events one...
> 
> Our automated tests still use 2.6.32. It wouldn't surprise me if upstream
> Linux 3 doesn't have the pirq_eoi_map stuff; it's an optimisation rather
> than core absolutely-required functionality.
> 
> It's the dom0 PV kernel that matters in this case by the way, not the kernel
> that you are running in HVM mode as a domU.
> 

Yep, I was testing with Linux 3.1 dom0 kernel, 
and there this patch worked OK without problems.

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 20:17:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 20:17:39 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR8Ox-0002MS-0j
	for archives@lists.xen.org; Thu, 17 Nov 2011 20:17:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR8Oc-0001eg-UG; Thu, 17 Nov 2011 12:17:19 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR8BV-0001J0-ND
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 12:03:46 -0800
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321560191!57689770!1
X-Originating-IP: [192.89.123.25]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27174 invoked from network); 17 Nov 2011 20:03:11 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 20:03:11 -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 2F02514FE;
	Thu, 17 Nov 2011 22:03:40 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DE87020058; Thu, 17 Nov 2011 22:03:39 +0200 (EET)
Date: Thu, 17 Nov 2011 22:03:39 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [xen-4.1-testing test] 9805: regressions - FAIL
Message-ID: <20111117200339.GO12984@reaktio.net>
References: <4EC4E1DD.1030309@canonical.com> <CAEA944D.343E5%keir@xen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAEA944D.343E5%keir@xen.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>, Stefan Bader <stefan.bader@canonical.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 10:37:01AM +0000, Keir Fraser wrote:
> On 17/11/2011 10:28, "Stefan Bader" <stefan.bader@canonical.com> wrote:
> 
> >>> Hm, yes we should. I am pretty sure I hit that code path often enough,
> >>> Wonder
> >>> why I never saw any dead lock there...
> >> 
> >> Perhaps your dom0 kernel doesn't register a pirq_eoi_map.
> >> 
> > Would be the only explanation. And quite possible. Heck, I would need to know
> > what that is used for anyway. :/ The kernel is 3.0 based the interrupt I was
> > looking at just was a normal apic emulated through events one...
> 
> Our automated tests still use 2.6.32. It wouldn't surprise me if upstream
> Linux 3 doesn't have the pirq_eoi_map stuff; it's an optimisation rather
> than core absolutely-required functionality.
> 
> It's the dom0 PV kernel that matters in this case by the way, not the kernel
> that you are running in HVM mode as a domU.
> 

Yep, I was testing with Linux 3.1 dom0 kernel, 
and there this patch worked OK without problems.

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 20:19:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 20:19:00 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR8QG-0002Q4-N8
	for archives@lists.xen.org; Thu, 17 Nov 2011 20:19:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR8Py-00022f-8T; Thu, 17 Nov 2011 12:18:42 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR8OQ-0001dA-BW
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 12:17:07 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1321561023!2012346!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22998 invoked from network); 17 Nov 2011 20:17:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 20:17:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315180800"; 
   d="scan'208";a="8998013"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 20:17:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 20:17:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Neil Horman <nhorman@tuxdriver.com>
In-Reply-To: <20111117192535.GB26847@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
Content-Type: text/plain; charset="ISO-8859-1"
Organization: Citrix Systems, Inc.
Date: Thu, 17 Nov 2011 20:17:01 +0000
Message-ID: <1321561021.8866.12.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Content-Transfer-Encoding: 7bit
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > 
> > What are the actual constraints here? The skb is used as a handle to the
> > skb->data and shinfo (frags) and to complete at the end. It's actually
> > those which are passed to the hypervisor (effectively the same as
> > passing those addresses to the h/w for DMA).
> > 
> > Which parts of the skb are expected/allowed to not remain stable?
> > 
> > (Appologies if the above seems naive, I seem to have missed the
> > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > 
> Its ok, this is the most accurate description from the previous threads on the
> subject:
> http://lists.openwall.net/netdev/2011/08/22/63
> 
> The basic problem boils down the notion that some drivers, when they receive an
> skb in their xmit paths, presume to have sole ownership of the skb, and as a
> result may do things like add the skb to a list, or otherwise store stateful
> data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> holds a reference to the skb, and make make changes without serializing them
> against the driver.  So we have to flag those drivers which preform these kinds
> of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> an skb, but it does place a pointer to the skb in a data structure here:
> 
> np->tx_skbs[id].skb = skb;
> 
> Which then gets handed off to the hypervisior.  Since the hypervisor now has
> access to that skb pointer, and we can't be sure (from the guest perspective),
> what it does with that information, it would be better to be safe by disallowing
> shared skbs in this path.

The skb pointer itself doesn't get given to the backend/hypervisor. The
page which skb->data refers to is granted to the backend domain, as are
the pages in the frags.

I think we only need to be sure that the frontend doesn't rely on
anything in the skb itself, right? Does skb->data or shinfo count from
that perspective?

Ian.

> 
> Neil
> 
> > Ian.
> > 
> > > 
> > > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > > CC: "David S. Miller" <davem@davemloft.net>
> > > CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > CC: xen-devel@lists.xensource.com
> > > ---
> > >  drivers/net/xen-netfront.c |    6 ++++++
> > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > > index 226faab..fb1077b 100644
> > > --- a/drivers/net/xen-netfront.c
> > > +++ b/drivers/net/xen-netfront.c
> > > @@ -1252,6 +1252,12 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
> > >  		return ERR_PTR(-ENOMEM);
> > >  	}
> > >  
> > > +	/*
> > > +	 * Since frames remain on a queue after a return from xennet_start_xmit,
> > > +	 * we can't support tx shared skbs
> > > +	 */
> > > +	netdev->priv_flags &= ~IFF_TX_SKB_SHARING;
> > > +
> > >  	np                   = netdev_priv(netdev);
> > >  	np->xbdev            = dev;
> > >  
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 20:19:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 20:19:00 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR8QG-0002Q4-N8
	for archives@lists.xen.org; Thu, 17 Nov 2011 20:19:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR8Py-00022f-8T; Thu, 17 Nov 2011 12:18:42 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR8OQ-0001dA-BW
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 12:17:07 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1321561023!2012346!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22998 invoked from network); 17 Nov 2011 20:17:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 20:17:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,528,1315180800"; 
   d="scan'208";a="8998013"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 20:17:02 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Thu, 17 Nov 2011 20:17:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Neil Horman <nhorman@tuxdriver.com>
In-Reply-To: <20111117192535.GB26847@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
Content-Type: text/plain; charset="ISO-8859-1"
Organization: Citrix Systems, Inc.
Date: Thu, 17 Nov 2011 20:17:01 +0000
Message-ID: <1321561021.8866.12.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Content-Transfer-Encoding: 7bit
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > 
> > What are the actual constraints here? The skb is used as a handle to the
> > skb->data and shinfo (frags) and to complete at the end. It's actually
> > those which are passed to the hypervisor (effectively the same as
> > passing those addresses to the h/w for DMA).
> > 
> > Which parts of the skb are expected/allowed to not remain stable?
> > 
> > (Appologies if the above seems naive, I seem to have missed the
> > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > 
> Its ok, this is the most accurate description from the previous threads on the
> subject:
> http://lists.openwall.net/netdev/2011/08/22/63
> 
> The basic problem boils down the notion that some drivers, when they receive an
> skb in their xmit paths, presume to have sole ownership of the skb, and as a
> result may do things like add the skb to a list, or otherwise store stateful
> data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> holds a reference to the skb, and make make changes without serializing them
> against the driver.  So we have to flag those drivers which preform these kinds
> of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> an skb, but it does place a pointer to the skb in a data structure here:
> 
> np->tx_skbs[id].skb = skb;
> 
> Which then gets handed off to the hypervisior.  Since the hypervisor now has
> access to that skb pointer, and we can't be sure (from the guest perspective),
> what it does with that information, it would be better to be safe by disallowing
> shared skbs in this path.

The skb pointer itself doesn't get given to the backend/hypervisor. The
page which skb->data refers to is granted to the backend domain, as are
the pages in the frags.

I think we only need to be sure that the frontend doesn't rely on
anything in the skb itself, right? Does skb->data or shinfo count from
that perspective?

Ian.

> 
> Neil
> 
> > Ian.
> > 
> > > 
> > > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > > CC: "David S. Miller" <davem@davemloft.net>
> > > CC: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> > > CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > CC: xen-devel@lists.xensource.com
> > > ---
> > >  drivers/net/xen-netfront.c |    6 ++++++
> > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > > index 226faab..fb1077b 100644
> > > --- a/drivers/net/xen-netfront.c
> > > +++ b/drivers/net/xen-netfront.c
> > > @@ -1252,6 +1252,12 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
> > >  		return ERR_PTR(-ENOMEM);
> > >  	}
> > >  
> > > +	/*
> > > +	 * Since frames remain on a queue after a return from xennet_start_xmit,
> > > +	 * we can't support tx shared skbs
> > > +	 */
> > > +	netdev->priv_flags &= ~IFF_TX_SKB_SHARING;
> > > +
> > >  	np                   = netdev_priv(netdev);
> > >  	np->xbdev            = dev;
> > >  
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 



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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 20:29:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 20:29:16 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR8aC-0002Zb-00
	for archives@lists.xen.org; Thu, 17 Nov 2011 20:29:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR8Zq-0002aI-O8; Thu, 17 Nov 2011 12:28:55 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR8Zm-0002ZW-GV
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 12:28:51 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321561726!3601847!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23074 invoked from network); 17 Nov 2011 20:28:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 20:28:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,529,1315180800"; 
   d="scan'208";a="8998160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 20:28: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.137.0; Thu, 17 Nov 2011 20:28:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RR8Zi-00084q-5Y;
	Thu, 17 Nov 2011 20:28:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RR8Zh-0006y1-Ot;
	Thu, 17 Nov 2011 20:28:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9852-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 17 Nov 2011 20:28:45 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9852: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9851 REGR. vs. 9756

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

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

version targeted for testing:
 xen                  e73ada19a69d
baseline version:
 xen                  9702967e89dd

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Gianluca Guida <gianluca.guida@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   23189:e73ada19a69d
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:13:25 2011 +0000
    
    Hypercall continuation cancelation in compat mode for XENMEM_get/set_pod_target
    
    If copy_to_guest failed in the compat code after a continuation as
    been done in the native code we need to cancel it so we won't
    reexecute the hypercall but return from the hypercall with the
    appropriate error.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24116:a095cf28f2b6
    xen-unstable date:        Fri Nov 11 10:14:22 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23188:344dddd4160b
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:12:00 2011 +0000
    
    xsm: Add support for HVMOP_track_dirty_vram.
    
    Xen try to inforce the xsm policy when a HVMOP_track_dirty_vram
    is received (xen/arch/x86/hvm/hvm.c:3637). It was failing because
    in flask_hvmcontext, xsm didn't have any case for this operation.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24107:fb1b32c9d03d
    xen-unstable date:        Tue Nov 08 19:41:47 2011 +0000
    
    
changeset:   23187:1bbf2940ef61
user:        Keir Fraser <keir@xen.org>
date:        Thu Nov 17 09:10:07 2011 +0000
    
    Revert 23183:98ba0aceaf30 (xen-unstable:24007:0526644ad2a6).
    
    Locking is broken (calls evtchn_unmask with lock already held).
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23186:51f58b210447
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Nov 16 16:39:02 2011 +0000
    
    x86-64/test_x86_emulate: fix blowfish test
    
    Incorrect register usage in the _start() wrapper caused the 64-bit
    execution emulation to fail.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24149:753b21aa4087
    xen-unstable date:        Wed Nov 16 15:20:25 2011 +0000
    
    
changeset:   23185:efd132eee40c
user:        Gianluca Guida <gianluca.guida@citrix.com>
date:        Wed Nov 16 16:38:27 2011 +0000
    
    [shadow] Disable higher level pagetables early unshadow only when the "process dying" hypercall is used.
    
    This patch fixes a performance problem in fully virtualized guests.
    
    Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>
    Tested-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24148:3ecc8fef4281
    xen-unstable date:        Wed Nov 16 15:19:33 2011 +0000
    
    
changeset:   23184:4a91cf045893
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 16 16:37:49 2011 +0000
    
    xen: avoid crash enabling turbo mode
    
    On a system which has not had P-state information pushed down into the
    hypervisor running "xenpm enable-turbo-mode" will reliably crash the
    host.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24144:cd3ef25f207a
    xen-unstable date:        Tue Nov 15 14:24:38 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23183:98ba0aceaf30
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Wed Nov 16 16:33:58 2011 +0000
    
    x86: re-inject emulated level pirqs in PV on HVM guests if still asserted
    
    PV on HVM guests can loose level interrupts coming from emulated
    devices if they have been remapped onto event channels.  The reason is
    that we are missing the code to inject a pirq again in the guest when
    the guest EOIs it, if it corresponds to an emulated level interrupt
    and the interrupt is still asserted.
    
    Fix this issue and also return error when the guest tries to get the
    irq_status of a non-existing pirq.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24007:0526644ad2a6
    xen-unstable date:        Thu Oct 27 16:07:18 2011 +0100
    
    
changeset:   23182:9702967e89dd
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Sat Nov 12 16:14:02 2011 +0000
    
    Revert c/s 23666:b96f8bdcaa15 KEXEC: disconnect all PCI devices from the PCI bus on crash
    
    It turns out that this causes all mannor of problems on certain
    motherboards (so far with no pattern I can discern)
    
    Problems include:
    * Hanging forever checking hlt instruction.
    * Panics when trying to change switch root device
    * Drivers hanging when trying to check for interrupts.
    
    From: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24137:0844b17df7a9
    xen-unstable date:        Fri Nov 11 18:14:35 2011 +0000
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 20:29:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 20:29:16 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR8aC-0002Zb-00
	for archives@lists.xen.org; Thu, 17 Nov 2011 20:29:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR8Zq-0002aI-O8; Thu, 17 Nov 2011 12:28:55 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR8Zm-0002ZW-GV
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 12:28:51 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321561726!3601847!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23074 invoked from network); 17 Nov 2011 20:28:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 20:28:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,529,1315180800"; 
   d="scan'208";a="8998160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 20:28: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.137.0; Thu, 17 Nov 2011 20:28:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RR8Zi-00084q-5Y;
	Thu, 17 Nov 2011 20:28:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RR8Zh-0006y1-Ot;
	Thu, 17 Nov 2011 20:28:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9852-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 17 Nov 2011 20:28:45 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9852: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9851 REGR. vs. 9756

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

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

version targeted for testing:
 xen                  e73ada19a69d
baseline version:
 xen                  9702967e89dd

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Gianluca Guida <gianluca.guida@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   23189:e73ada19a69d
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:13:25 2011 +0000
    
    Hypercall continuation cancelation in compat mode for XENMEM_get/set_pod_target
    
    If copy_to_guest failed in the compat code after a continuation as
    been done in the native code we need to cancel it so we won't
    reexecute the hypercall but return from the hypercall with the
    appropriate error.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24116:a095cf28f2b6
    xen-unstable date:        Fri Nov 11 10:14:22 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23188:344dddd4160b
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:12:00 2011 +0000
    
    xsm: Add support for HVMOP_track_dirty_vram.
    
    Xen try to inforce the xsm policy when a HVMOP_track_dirty_vram
    is received (xen/arch/x86/hvm/hvm.c:3637). It was failing because
    in flask_hvmcontext, xsm didn't have any case for this operation.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24107:fb1b32c9d03d
    xen-unstable date:        Tue Nov 08 19:41:47 2011 +0000
    
    
changeset:   23187:1bbf2940ef61
user:        Keir Fraser <keir@xen.org>
date:        Thu Nov 17 09:10:07 2011 +0000
    
    Revert 23183:98ba0aceaf30 (xen-unstable:24007:0526644ad2a6).
    
    Locking is broken (calls evtchn_unmask with lock already held).
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23186:51f58b210447
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Nov 16 16:39:02 2011 +0000
    
    x86-64/test_x86_emulate: fix blowfish test
    
    Incorrect register usage in the _start() wrapper caused the 64-bit
    execution emulation to fail.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24149:753b21aa4087
    xen-unstable date:        Wed Nov 16 15:20:25 2011 +0000
    
    
changeset:   23185:efd132eee40c
user:        Gianluca Guida <gianluca.guida@citrix.com>
date:        Wed Nov 16 16:38:27 2011 +0000
    
    [shadow] Disable higher level pagetables early unshadow only when the "process dying" hypercall is used.
    
    This patch fixes a performance problem in fully virtualized guests.
    
    Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>
    Tested-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24148:3ecc8fef4281
    xen-unstable date:        Wed Nov 16 15:19:33 2011 +0000
    
    
changeset:   23184:4a91cf045893
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 16 16:37:49 2011 +0000
    
    xen: avoid crash enabling turbo mode
    
    On a system which has not had P-state information pushed down into the
    hypervisor running "xenpm enable-turbo-mode" will reliably crash the
    host.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24144:cd3ef25f207a
    xen-unstable date:        Tue Nov 15 14:24:38 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23183:98ba0aceaf30
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Wed Nov 16 16:33:58 2011 +0000
    
    x86: re-inject emulated level pirqs in PV on HVM guests if still asserted
    
    PV on HVM guests can loose level interrupts coming from emulated
    devices if they have been remapped onto event channels.  The reason is
    that we are missing the code to inject a pirq again in the guest when
    the guest EOIs it, if it corresponds to an emulated level interrupt
    and the interrupt is still asserted.
    
    Fix this issue and also return error when the guest tries to get the
    irq_status of a non-existing pirq.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24007:0526644ad2a6
    xen-unstable date:        Thu Oct 27 16:07:18 2011 +0100
    
    
changeset:   23182:9702967e89dd
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Sat Nov 12 16:14:02 2011 +0000
    
    Revert c/s 23666:b96f8bdcaa15 KEXEC: disconnect all PCI devices from the PCI bus on crash
    
    It turns out that this causes all mannor of problems on certain
    motherboards (so far with no pattern I can discern)
    
    Problems include:
    * Hanging forever checking hlt instruction.
    * Panics when trying to change switch root device
    * Drivers hanging when trying to check for interrupts.
    
    From: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24137:0844b17df7a9
    xen-unstable date:        Fri Nov 11 18:14:35 2011 +0000
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 20:30:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 20:30:37 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR8bV-0002a9-HA
	for archives@lists.xen.org; Thu, 17 Nov 2011 20:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR8bD-0002yn-IX; Thu, 17 Nov 2011 12:30:19 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR8af-0002nc-JW
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 12:29:46 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1321561767!55478760!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12478 invoked from network); 17 Nov 2011 20:29:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 20:29:28 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHKTar1025079
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 20:29:36 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHKTYt3028733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 20:29:34 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHKTQtZ000904; Thu, 17 Nov 2011 14:29:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 12:29:26 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A76EB81489; Thu, 17 Nov 2011 15:29:25 -0500 (EST)
Date: Thu, 17 Nov 2011 15:29:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] ioperm problem
Message-ID: <20111117202925.GA9768@phenom.dumpdata.com>
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
	<4EC51292.7000302@virtualcomputer.com>
	<20111117173010.GA3623@phenom.dumpdata.com>
	<4EC54D05.3050308@goop.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EC54D05.3050308@goop.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EC56EB3.00B2,ss=1,re=0.000,fgs=0
Cc: ja <pavel@netsafe.cz>, xen-devel@lists.xensource.com,
	tom.goetz@virtualcomputer.com, Ben Guthro <ben.guthro@virtualcomputer.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 10:05:57AM -0800, Jeremy Fitzhardinge wrote:
> On 11/17/2011 09:30 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 17, 2011 at 08:56:34AM -0500, Ben Guthro wrote:
> >> Attached is our patch to work around issues with the ioports with
> >> some older nVidia cards.
> >>
> >> This, admittedly is a bit of a hack, and not exactly something that
> >> I would see upstream wanting to carry, for a variety of reasons. It
> >> really should all be predicated on whether the kernel is the initial
> >> domain, etc.
> >>
> >> This opens up the legacy VGA ports in the VGA arbiter code.
> > Was there a userspace program that did this? As in it would
> > call ioperm?
> >
> >> Konrad - I think that you had suggested an alternate way of doing
> >> this, IIRC, but I can't seem to find it in my inbox. Due to
> >> competing demands, and my nVidia hardware disappearing, I never went
> >> back to rework this code.
> > Ah, I might have some code that I just uncovered from Jeremy's old
> > git tree.
> >
> > I've put it up on devel/ioperm - it nicely wraps the ioperm
> > call to go the native or paravirt.
> 
> Yeah, I'd sort of let that sit, since there's nothing in a "modern"
> system which should require it.  Allowing usermode to poke at ioports
> from within a domain is inherently suspect, after all.

There are three different cases here:
 - Nvidia and VBE tool. They seem to do a lot of poking and Ben
   needed some way of making it work. Naturally the nouveau driver
   is not doing this.. This is in Dom0.

 - DVB cards. I *think* that the problem some folks have with passing
   in the DVB cards is that the 'scan' tools used to jump frequencies
   poke at those IO-ports. But I am not 100% sure about it, and need
   to look in more details at the drivers itself. The person reporting
   this was running the DVB card in Dom0.

 - Lastly the PCI passthrough of NVidia/ATI card in the guest. I think
   one person is trying to do it while running the guest in paravirtualized
   mode, in which case some help in doing those hypercall is needed.
   But if one were to do this in fully virtualized that means QEMU ends up
   trapping those I/O port accesses and it itself pokes them in the PCI card.
   But since QEMU is running in dom0 and dom0 is PV, that leads back to the
   VGA I/O ports not being allowed to poke as we don't have the ioperm hypercall.

This all sounds right, but in practice it might be something entirely
different..

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 20:30:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 20:30:37 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR8bV-0002a9-HA
	for archives@lists.xen.org; Thu, 17 Nov 2011 20:30:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR8bD-0002yn-IX; Thu, 17 Nov 2011 12:30:19 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR8af-0002nc-JW
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 12:29:46 -0800
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1321561767!55478760!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12478 invoked from network); 17 Nov 2011 20:29:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 20:29:28 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHKTar1025079
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 20:29:36 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHKTYt3028733
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 20:29:34 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHKTQtZ000904; Thu, 17 Nov 2011 14:29:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 12:29:26 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A76EB81489; Thu, 17 Nov 2011 15:29:25 -0500 (EST)
Date: Thu, 17 Nov 2011 15:29:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] ioperm problem
Message-ID: <20111117202925.GA9768@phenom.dumpdata.com>
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
	<4EC51292.7000302@virtualcomputer.com>
	<20111117173010.GA3623@phenom.dumpdata.com>
	<4EC54D05.3050308@goop.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EC54D05.3050308@goop.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4EC56EB3.00B2,ss=1,re=0.000,fgs=0
Cc: ja <pavel@netsafe.cz>, xen-devel@lists.xensource.com,
	tom.goetz@virtualcomputer.com, Ben Guthro <ben.guthro@virtualcomputer.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 10:05:57AM -0800, Jeremy Fitzhardinge wrote:
> On 11/17/2011 09:30 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 17, 2011 at 08:56:34AM -0500, Ben Guthro wrote:
> >> Attached is our patch to work around issues with the ioports with
> >> some older nVidia cards.
> >>
> >> This, admittedly is a bit of a hack, and not exactly something that
> >> I would see upstream wanting to carry, for a variety of reasons. It
> >> really should all be predicated on whether the kernel is the initial
> >> domain, etc.
> >>
> >> This opens up the legacy VGA ports in the VGA arbiter code.
> > Was there a userspace program that did this? As in it would
> > call ioperm?
> >
> >> Konrad - I think that you had suggested an alternate way of doing
> >> this, IIRC, but I can't seem to find it in my inbox. Due to
> >> competing demands, and my nVidia hardware disappearing, I never went
> >> back to rework this code.
> > Ah, I might have some code that I just uncovered from Jeremy's old
> > git tree.
> >
> > I've put it up on devel/ioperm - it nicely wraps the ioperm
> > call to go the native or paravirt.
> 
> Yeah, I'd sort of let that sit, since there's nothing in a "modern"
> system which should require it.  Allowing usermode to poke at ioports
> from within a domain is inherently suspect, after all.

There are three different cases here:
 - Nvidia and VBE tool. They seem to do a lot of poking and Ben
   needed some way of making it work. Naturally the nouveau driver
   is not doing this.. This is in Dom0.

 - DVB cards. I *think* that the problem some folks have with passing
   in the DVB cards is that the 'scan' tools used to jump frequencies
   poke at those IO-ports. But I am not 100% sure about it, and need
   to look in more details at the drivers itself. The person reporting
   this was running the DVB card in Dom0.

 - Lastly the PCI passthrough of NVidia/ATI card in the guest. I think
   one person is trying to do it while running the guest in paravirtualized
   mode, in which case some help in doing those hypercall is needed.
   But if one were to do this in fully virtualized that means QEMU ends up
   trapping those I/O port accesses and it itself pokes them in the PCI card.
   But since QEMU is running in dom0 and dom0 is PV, that leads back to the
   VGA I/O ports not being allowed to poke as we don't have the ioperm hypercall.

This all sounds right, but in practice it might be something entirely
different..

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 21:44:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 21:44:29 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR9kz-0002k8-3b
	for archives@lists.xen.org; Thu, 17 Nov 2011 21:44:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR8qt-0003bS-OF; Thu, 17 Nov 2011 12:46:31 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR8qk-0003ab-BR
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 12:46:22 -0800
X-Env-Sender: nhorman@tuxdriver.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321562777!3991712!1
X-Originating-IP: [70.61.120.58]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7606 invoked from network); 17 Nov 2011 20:46:18 -0000
Received: from charlotte.tuxdriver.com (HELO smtp.tuxdriver.com) (70.61.120.58)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 20:46:18 -0000
Received: from hmsreliant.think-freely.org
	([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost)
	by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63)
	(envelope-from <nhorman@tuxdriver.com>)
	id 1RR8qJ-0004Ei-U2; Thu, 17 Nov 2011 15:46:11 -0500
Date: Thu, 17 Nov 2011 15:45:53 -0500
From: Neil Horman <nhorman@tuxdriver.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111117204553.GD26847@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
	<1321561021.8866.12.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1321561021.8866.12.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -2.6 (--)
X-Spam-Status: No
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > 
> > > What are the actual constraints here? The skb is used as a handle to the
> > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > those which are passed to the hypervisor (effectively the same as
> > > passing those addresses to the h/w for DMA).
> > > 
> > > Which parts of the skb are expected/allowed to not remain stable?
> > > 
> > > (Appologies if the above seems naive, I seem to have missed the
> > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > 
> > Its ok, this is the most accurate description from the previous threads on the
> > subject:
> > http://lists.openwall.net/netdev/2011/08/22/63
> > 
> > The basic problem boils down the notion that some drivers, when they receive an
> > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > result may do things like add the skb to a list, or otherwise store stateful
> > data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> > holds a reference to the skb, and make make changes without serializing them
> > against the driver.  So we have to flag those drivers which preform these kinds
> > of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> > an skb, but it does place a pointer to the skb in a data structure here:
> > 
> > np->tx_skbs[id].skb = skb;
> > 
> > Which then gets handed off to the hypervisior.  Since the hypervisor now has
> > access to that skb pointer, and we can't be sure (from the guest perspective),
> > what it does with that information, it would be better to be safe by disallowing
> > shared skbs in this path.
> 
> The skb pointer itself doesn't get given to the backend/hypervisor. The
> page which skb->data refers to is granted to the backend domain, as are
> the pages in the frags.
> 
> I think we only need to be sure that the frontend doesn't rely on
> anything in the skb itself, right? Does skb->data or shinfo count from
> that perspective?
shinfo is definately a problem, as other devices may make modifications to it.
skb->data is probably safer, but is also potentially suspect (for instance if
another device appends an additional header to the data for instance)
Neil

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 21:44:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 21:44:29 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RR9kz-0002k8-3b
	for archives@lists.xen.org; Thu, 17 Nov 2011 21:44:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RR8qt-0003bS-OF; Thu, 17 Nov 2011 12:46:31 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RR8qk-0003ab-BR
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 12:46:22 -0800
X-Env-Sender: nhorman@tuxdriver.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321562777!3991712!1
X-Originating-IP: [70.61.120.58]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7606 invoked from network); 17 Nov 2011 20:46:18 -0000
Received: from charlotte.tuxdriver.com (HELO smtp.tuxdriver.com) (70.61.120.58)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Nov 2011 20:46:18 -0000
Received: from hmsreliant.think-freely.org
	([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost)
	by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63)
	(envelope-from <nhorman@tuxdriver.com>)
	id 1RR8qJ-0004Ei-U2; Thu, 17 Nov 2011 15:46:11 -0500
Date: Thu, 17 Nov 2011 15:45:53 -0500
From: Neil Horman <nhorman@tuxdriver.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111117204553.GD26847@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
	<1321561021.8866.12.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1321561021.8866.12.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -2.6 (--)
X-Spam-Status: No
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > 
> > > What are the actual constraints here? The skb is used as a handle to the
> > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > those which are passed to the hypervisor (effectively the same as
> > > passing those addresses to the h/w for DMA).
> > > 
> > > Which parts of the skb are expected/allowed to not remain stable?
> > > 
> > > (Appologies if the above seems naive, I seem to have missed the
> > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > 
> > Its ok, this is the most accurate description from the previous threads on the
> > subject:
> > http://lists.openwall.net/netdev/2011/08/22/63
> > 
> > The basic problem boils down the notion that some drivers, when they receive an
> > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > result may do things like add the skb to a list, or otherwise store stateful
> > data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> > holds a reference to the skb, and make make changes without serializing them
> > against the driver.  So we have to flag those drivers which preform these kinds
> > of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> > an skb, but it does place a pointer to the skb in a data structure here:
> > 
> > np->tx_skbs[id].skb = skb;
> > 
> > Which then gets handed off to the hypervisior.  Since the hypervisor now has
> > access to that skb pointer, and we can't be sure (from the guest perspective),
> > what it does with that information, it would be better to be safe by disallowing
> > shared skbs in this path.
> 
> The skb pointer itself doesn't get given to the backend/hypervisor. The
> page which skb->data refers to is granted to the backend domain, as are
> the pages in the frags.
> 
> I think we only need to be sure that the frontend doesn't rely on
> anything in the skb itself, right? Does skb->data or shinfo count from
> that perspective?
shinfo is definately a problem, as other devices may make modifications to it.
skb->data is probably safer, but is also potentially suspect (for instance if
another device appends an additional header to the data for instance)
Neil

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 22:21:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 22:21:12 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRAKW-0002kn-8u
	for archives@lists.xen.org; Thu, 17 Nov 2011 22:21:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRAK9-0006eD-Uk; Thu, 17 Nov 2011 14:20:49 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRAK3-0006dJ-Ar
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 14:20:43 -0800
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321568438!2017056!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4518 invoked from network); 17 Nov 2011 22:20:39 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 22:20:39 -0000
Received: by bkbzt12 with SMTP id zt12so3748358bkb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 14:20:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=6wcln1NOdKZt9CHwhdTptE+zT+q64585HoZRwkmn39E=;
	b=AIV6uFpcjFzWarEV8lgBW9LRyJ7QNnKpIt7xEzPUJl4BdILWXGHgWqg0DJpnWLJv5p
	B7JxbQjG6PwdaFP39hTHKUBKJH+H8p+JrmyFT1BEDKJCey1rI2mQaWQWuLQEmAa3YQCv
	2SnrjIbUwWBUFlJHw1oynShBYlZUjrhru/whE=
MIME-Version: 1.0
Received: by 10.204.156.219 with SMTP id y27mr379304bkw.125.1321568438275;
	Thu, 17 Nov 2011 14:20:38 -0800 (PST)
Received: by 10.223.78.130 with HTTP; Thu, 17 Nov 2011 14:20:37 -0800 (PST)
In-Reply-To: <4EC54D05.3050308@goop.org>
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
	<4EC51292.7000302@virtualcomputer.com>
	<20111117173010.GA3623@phenom.dumpdata.com>
	<4EC54D05.3050308@goop.org>
Date: Thu, 17 Nov 2011 17:20:37 -0500
X-Google-Sender-Auth: Yqu74op_VYOqku4JJfxeE2_Opck
Message-ID: <CAOvdn6W17A7wfujaGdkCmwGDK3fsvnbYWZELSgt_bWSewsOc=A@mail.gmail.com>
Subject: Re: [Xen-devel] ioperm problem
From: Ben Guthro <ben@guthro.net>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ja <pavel@netsafe.cz>, Ben Guthro <ben.guthro@virtualcomputer.com>,
	xen-devel@lists.xensource.com, tom.goetz@virtualcomputer.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Looking back through the bug database, the problem started in uvesafb,
while running in the nVidia closed source driver
The user reported very long boots, and I found the following repeated
over, and over in the syslog:

Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 29.677547] uvesafb:
Getting mode info block for mode 0x106 failed (eax=3D0x4f01, err=3D1)
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 29.685667] v86d[363]
general protection ip:7f0acfdbdb43 sp:7fff100d3748 error:0 in
libx86.so.1[7f0acfdb6000+1f000]

This continues every 5s until:

Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.677745] uvesafb:
Getting mode info block for mode 0x161 failed (eax=3D0x4f01, err=3D1)
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.692267] uvesafb:
VBIOS/hardware doesn't support DDC transfers
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.692275] uvesafb: no
monitor limits have been set, default refresh rate will be used
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.692369] v86d[396]
general protection ip:7ff77908bb43 sp:7fffa8b7e708 error:0 in
libx86.so.1[7ff779084000+1f000]


Chasing this down, I found it all started from drivers/video/uvesafb.c: 506=
:

uvesafb_reset(task);
task->t.regs.eax =3D 0x4f01;
task->t.regs.ecx =3D (u32) *mode;
task->t.flags =3D TF_BUF_RET | TF_BUF_ESDI;
task->t.buf_len =3D sizeof(struct vbe_mode_ib);
task->buf =3D par->vbe_modes + off;

err =3D uvesafb_exec(task);
if (err || (task->t.regs.eax & 0xffff) !=3D 0x004f) {
printk(KERN_WARNING "uvesafb: Getting mode info block "
"for mode 0x%x failed (eax=3D0x%x, err=3D%d)\n",
*mode, (u32)task->t.regs.eax, err);
mode++;
par->vbe_modes_cnt--;
continue;
}

(the same code also exists in testvbe.c - line 55)

This executes in the v86d userspace process
v86d/v86_common.c:
int v86_task(struct uvesafb_task *tsk, u8 *buf)


uvesafb was executing the video BIOS code, as mapped in /dev/mem


However, it was unable to access the ioport, causing a GPF.

uvesafb would loop on that, with a sleep(5)

The end result was a colossally long boot process seen by the end user.



The (albeit hacky) solution to open up the VGA ioports resolved the
seemed hang on this older nVidia card.



Hope this explanation make some semblance of sense.


/btg


On Thu, Nov 17, 2011 at 1:05 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrot=
e:
>
> On 11/17/2011 09:30 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 17, 2011 at 08:56:34AM -0500, Ben Guthro wrote:
> >> Attached is our patch to work around issues with the ioports with
> >> some older nVidia cards.
> >>
> >> This, admittedly is a bit of a hack, and not exactly something that
> >> I would see upstream wanting to carry, for a variety of reasons. It
> >> really should all be predicated on whether the kernel is the initial
> >> domain, etc.
> >>
> >> This opens up the legacy VGA ports in the VGA arbiter code.
> > Was there a userspace program that did this? As in it would
> > call ioperm?
> >
> >> Konrad - I think that you had suggested an alternate way of doing
> >> this, IIRC, but I can't seem to find it in my inbox. Due to
> >> competing demands, and my nVidia hardware disappearing, I never went
> >> back to rework this code.
> > Ah, I might have some code that I just uncovered from Jeremy's old
> > git tree.
> >
> > I've put it up on devel/ioperm - it nicely wraps the ioperm
> > call to go the native or paravirt.
>
> Yeah, I'd sort of let that sit, since there's nothing in a "modern"
> system which should require it. =A0Allowing usermode to poke at ioports
> from within a domain is inherently suspect, after all.
>
> =A0 =A0J
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 22:21:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 22:21:12 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRAKW-0002kn-8u
	for archives@lists.xen.org; Thu, 17 Nov 2011 22:21:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRAK9-0006eD-Uk; Thu, 17 Nov 2011 14:20:49 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRAK3-0006dJ-Ar
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 14:20:43 -0800
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321568438!2017056!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4518 invoked from network); 17 Nov 2011 22:20:39 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 22:20:39 -0000
Received: by bkbzt12 with SMTP id zt12so3748358bkb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 17 Nov 2011 14:20:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=6wcln1NOdKZt9CHwhdTptE+zT+q64585HoZRwkmn39E=;
	b=AIV6uFpcjFzWarEV8lgBW9LRyJ7QNnKpIt7xEzPUJl4BdILWXGHgWqg0DJpnWLJv5p
	B7JxbQjG6PwdaFP39hTHKUBKJH+H8p+JrmyFT1BEDKJCey1rI2mQaWQWuLQEmAa3YQCv
	2SnrjIbUwWBUFlJHw1oynShBYlZUjrhru/whE=
MIME-Version: 1.0
Received: by 10.204.156.219 with SMTP id y27mr379304bkw.125.1321568438275;
	Thu, 17 Nov 2011 14:20:38 -0800 (PST)
Received: by 10.223.78.130 with HTTP; Thu, 17 Nov 2011 14:20:37 -0800 (PST)
In-Reply-To: <4EC54D05.3050308@goop.org>
References: <201111132219.07211.pavel@netsafe.cz>
	<20111116145730.GA11502@phenom.dumpdata.com>
	<4EC51292.7000302@virtualcomputer.com>
	<20111117173010.GA3623@phenom.dumpdata.com>
	<4EC54D05.3050308@goop.org>
Date: Thu, 17 Nov 2011 17:20:37 -0500
X-Google-Sender-Auth: Yqu74op_VYOqku4JJfxeE2_Opck
Message-ID: <CAOvdn6W17A7wfujaGdkCmwGDK3fsvnbYWZELSgt_bWSewsOc=A@mail.gmail.com>
Subject: Re: [Xen-devel] ioperm problem
From: Ben Guthro <ben@guthro.net>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ja <pavel@netsafe.cz>, Ben Guthro <ben.guthro@virtualcomputer.com>,
	xen-devel@lists.xensource.com, tom.goetz@virtualcomputer.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Looking back through the bug database, the problem started in uvesafb,
while running in the nVidia closed source driver
The user reported very long boots, and I found the following repeated
over, and over in the syslog:

Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 29.677547] uvesafb:
Getting mode info block for mode 0x106 failed (eax=3D0x4f01, err=3D1)
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 29.685667] v86d[363]
general protection ip:7f0acfdbdb43 sp:7fff100d3748 error:0 in
libx86.so.1[7f0acfdb6000+1f000]

This continues every 5s until:

Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.677745] uvesafb:
Getting mode info block for mode 0x161 failed (eax=3D0x4f01, err=3D1)
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.692267] uvesafb:
VBIOS/hardware doesn't support DDC transfers
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.692275] uvesafb: no
monitor limits have been set, default refresh rate will be used
Sep 8 20:09:46 Qosmio-X505-1A033757W kernel: [ 84.692369] v86d[396]
general protection ip:7ff77908bb43 sp:7fffa8b7e708 error:0 in
libx86.so.1[7ff779084000+1f000]


Chasing this down, I found it all started from drivers/video/uvesafb.c: 506=
:

uvesafb_reset(task);
task->t.regs.eax =3D 0x4f01;
task->t.regs.ecx =3D (u32) *mode;
task->t.flags =3D TF_BUF_RET | TF_BUF_ESDI;
task->t.buf_len =3D sizeof(struct vbe_mode_ib);
task->buf =3D par->vbe_modes + off;

err =3D uvesafb_exec(task);
if (err || (task->t.regs.eax & 0xffff) !=3D 0x004f) {
printk(KERN_WARNING "uvesafb: Getting mode info block "
"for mode 0x%x failed (eax=3D0x%x, err=3D%d)\n",
*mode, (u32)task->t.regs.eax, err);
mode++;
par->vbe_modes_cnt--;
continue;
}

(the same code also exists in testvbe.c - line 55)

This executes in the v86d userspace process
v86d/v86_common.c:
int v86_task(struct uvesafb_task *tsk, u8 *buf)


uvesafb was executing the video BIOS code, as mapped in /dev/mem


However, it was unable to access the ioport, causing a GPF.

uvesafb would loop on that, with a sleep(5)

The end result was a colossally long boot process seen by the end user.



The (albeit hacky) solution to open up the VGA ioports resolved the
seemed hang on this older nVidia card.



Hope this explanation make some semblance of sense.


/btg


On Thu, Nov 17, 2011 at 1:05 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrot=
e:
>
> On 11/17/2011 09:30 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 17, 2011 at 08:56:34AM -0500, Ben Guthro wrote:
> >> Attached is our patch to work around issues with the ioports with
> >> some older nVidia cards.
> >>
> >> This, admittedly is a bit of a hack, and not exactly something that
> >> I would see upstream wanting to carry, for a variety of reasons. It
> >> really should all be predicated on whether the kernel is the initial
> >> domain, etc.
> >>
> >> This opens up the legacy VGA ports in the VGA arbiter code.
> > Was there a userspace program that did this? As in it would
> > call ioperm?
> >
> >> Konrad - I think that you had suggested an alternate way of doing
> >> this, IIRC, but I can't seem to find it in my inbox. Due to
> >> competing demands, and my nVidia hardware disappearing, I never went
> >> back to rework this code.
> > Ah, I might have some code that I just uncovered from Jeremy's old
> > git tree.
> >
> > I've put it up on devel/ioperm - it nicely wraps the ioperm
> > call to go the native or paravirt.
>
> Yeah, I'd sort of let that sit, since there's nothing in a "modern"
> system which should require it. =A0Allowing usermode to poke at ioports
> from within a domain is inherently suspect, after all.
>
> =A0 =A0J
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 23:24:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 23:24:28 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRBJk-0002tW-4K
	for archives@lists.xen.org; Thu, 17 Nov 2011 23:24:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRBJP-0000WB-9m; Thu, 17 Nov 2011 15:24:08 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRBJF-0000Uh-9L
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 15:23:57 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321572233!2019574!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31938 invoked from network); 17 Nov 2011 23:23:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 23:23:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,529,1315180800"; 
   d="scan'208";a="8999441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 23:23:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 23:23:53 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRBJB-0000et-Gd;
	Thu, 17 Nov 2011 23:23:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRBJB-0007gN-7B;
	Thu, 17 Nov 2011 23:23:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9853-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 17 Nov 2011 23:23:53 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9853: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9851 REGR. vs. 9756

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail pass in 9852
 test-amd64-amd64-xl-sedf     11 guest-localmigrate   fail in 9852 pass in 9851
 test-i386-i386-win           14 guest-start.2        fail in 9851 pass in 9853

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

version targeted for testing:
 xen                  e73ada19a69d
baseline version:
 xen                  9702967e89dd

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Gianluca Guida <gianluca.guida@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   23189:e73ada19a69d
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:13:25 2011 +0000
    
    Hypercall continuation cancelation in compat mode for XENMEM_get/set_pod_target
    
    If copy_to_guest failed in the compat code after a continuation as
    been done in the native code we need to cancel it so we won't
    reexecute the hypercall but return from the hypercall with the
    appropriate error.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24116:a095cf28f2b6
    xen-unstable date:        Fri Nov 11 10:14:22 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23188:344dddd4160b
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:12:00 2011 +0000
    
    xsm: Add support for HVMOP_track_dirty_vram.
    
    Xen try to inforce the xsm policy when a HVMOP_track_dirty_vram
    is received (xen/arch/x86/hvm/hvm.c:3637). It was failing because
    in flask_hvmcontext, xsm didn't have any case for this operation.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24107:fb1b32c9d03d
    xen-unstable date:        Tue Nov 08 19:41:47 2011 +0000
    
    
changeset:   23187:1bbf2940ef61
user:        Keir Fraser <keir@xen.org>
date:        Thu Nov 17 09:10:07 2011 +0000
    
    Revert 23183:98ba0aceaf30 (xen-unstable:24007:0526644ad2a6).
    
    Locking is broken (calls evtchn_unmask with lock already held).
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23186:51f58b210447
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Nov 16 16:39:02 2011 +0000
    
    x86-64/test_x86_emulate: fix blowfish test
    
    Incorrect register usage in the _start() wrapper caused the 64-bit
    execution emulation to fail.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24149:753b21aa4087
    xen-unstable date:        Wed Nov 16 15:20:25 2011 +0000
    
    
changeset:   23185:efd132eee40c
user:        Gianluca Guida <gianluca.guida@citrix.com>
date:        Wed Nov 16 16:38:27 2011 +0000
    
    [shadow] Disable higher level pagetables early unshadow only when the "process dying" hypercall is used.
    
    This patch fixes a performance problem in fully virtualized guests.
    
    Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>
    Tested-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24148:3ecc8fef4281
    xen-unstable date:        Wed Nov 16 15:19:33 2011 +0000
    
    
changeset:   23184:4a91cf045893
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 16 16:37:49 2011 +0000
    
    xen: avoid crash enabling turbo mode
    
    On a system which has not had P-state information pushed down into the
    hypervisor running "xenpm enable-turbo-mode" will reliably crash the
    host.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24144:cd3ef25f207a
    xen-unstable date:        Tue Nov 15 14:24:38 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23183:98ba0aceaf30
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Wed Nov 16 16:33:58 2011 +0000
    
    x86: re-inject emulated level pirqs in PV on HVM guests if still asserted
    
    PV on HVM guests can loose level interrupts coming from emulated
    devices if they have been remapped onto event channels.  The reason is
    that we are missing the code to inject a pirq again in the guest when
    the guest EOIs it, if it corresponds to an emulated level interrupt
    and the interrupt is still asserted.
    
    Fix this issue and also return error when the guest tries to get the
    irq_status of a non-existing pirq.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24007:0526644ad2a6
    xen-unstable date:        Thu Oct 27 16:07:18 2011 +0100
    
    
changeset:   23182:9702967e89dd
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Sat Nov 12 16:14:02 2011 +0000
    
    Revert c/s 23666:b96f8bdcaa15 KEXEC: disconnect all PCI devices from the PCI bus on crash
    
    It turns out that this causes all mannor of problems on certain
    motherboards (so far with no pattern I can discern)
    
    Problems include:
    * Hanging forever checking hlt instruction.
    * Panics when trying to change switch root device
    * Drivers hanging when trying to check for interrupts.
    
    From: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24137:0844b17df7a9
    xen-unstable date:        Fri Nov 11 18:14:35 2011 +0000
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 23:24:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 23:24:28 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRBJk-0002tW-4K
	for archives@lists.xen.org; Thu, 17 Nov 2011 23:24:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRBJP-0000WB-9m; Thu, 17 Nov 2011 15:24:08 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRBJF-0000Uh-9L
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 15:23:57 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321572233!2019574!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31938 invoked from network); 17 Nov 2011 23:23:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Nov 2011 23:23:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,529,1315180800"; 
   d="scan'208";a="8999441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Nov 2011 23:23:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Thu, 17 Nov 2011 23:23:53 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRBJB-0000et-Gd;
	Thu, 17 Nov 2011 23:23:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRBJB-0007gN-7B;
	Thu, 17 Nov 2011 23:23:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9853-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 17 Nov 2011 23:23:53 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9853: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9851 REGR. vs. 9756

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail pass in 9852
 test-amd64-amd64-xl-sedf     11 guest-localmigrate   fail in 9852 pass in 9851
 test-i386-i386-win           14 guest-start.2        fail in 9851 pass in 9853

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

version targeted for testing:
 xen                  e73ada19a69d
baseline version:
 xen                  9702967e89dd

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Gianluca Guida <gianluca.guida@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   23189:e73ada19a69d
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:13:25 2011 +0000
    
    Hypercall continuation cancelation in compat mode for XENMEM_get/set_pod_target
    
    If copy_to_guest failed in the compat code after a continuation as
    been done in the native code we need to cancel it so we won't
    reexecute the hypercall but return from the hypercall with the
    appropriate error.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24116:a095cf28f2b6
    xen-unstable date:        Fri Nov 11 10:14:22 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23188:344dddd4160b
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Thu Nov 17 09:12:00 2011 +0000
    
    xsm: Add support for HVMOP_track_dirty_vram.
    
    Xen try to inforce the xsm policy when a HVMOP_track_dirty_vram
    is received (xen/arch/x86/hvm/hvm.c:3637). It was failing because
    in flask_hvmcontext, xsm didn't have any case for this operation.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24107:fb1b32c9d03d
    xen-unstable date:        Tue Nov 08 19:41:47 2011 +0000
    
    
changeset:   23187:1bbf2940ef61
user:        Keir Fraser <keir@xen.org>
date:        Thu Nov 17 09:10:07 2011 +0000
    
    Revert 23183:98ba0aceaf30 (xen-unstable:24007:0526644ad2a6).
    
    Locking is broken (calls evtchn_unmask with lock already held).
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23186:51f58b210447
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Nov 16 16:39:02 2011 +0000
    
    x86-64/test_x86_emulate: fix blowfish test
    
    Incorrect register usage in the _start() wrapper caused the 64-bit
    execution emulation to fail.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24149:753b21aa4087
    xen-unstable date:        Wed Nov 16 15:20:25 2011 +0000
    
    
changeset:   23185:efd132eee40c
user:        Gianluca Guida <gianluca.guida@citrix.com>
date:        Wed Nov 16 16:38:27 2011 +0000
    
    [shadow] Disable higher level pagetables early unshadow only when the "process dying" hypercall is used.
    
    This patch fixes a performance problem in fully virtualized guests.
    
    Signed-off-by: Gianluca Guida <gianluca.guida@citrix.com>
    Tested-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24148:3ecc8fef4281
    xen-unstable date:        Wed Nov 16 15:19:33 2011 +0000
    
    
changeset:   23184:4a91cf045893
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 16 16:37:49 2011 +0000
    
    xen: avoid crash enabling turbo mode
    
    On a system which has not had P-state information pushed down into the
    hypervisor running "xenpm enable-turbo-mode" will reliably crash the
    host.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24144:cd3ef25f207a
    xen-unstable date:        Tue Nov 15 14:24:38 2011 +0100
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   23183:98ba0aceaf30
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Wed Nov 16 16:33:58 2011 +0000
    
    x86: re-inject emulated level pirqs in PV on HVM guests if still asserted
    
    PV on HVM guests can loose level interrupts coming from emulated
    devices if they have been remapped onto event channels.  The reason is
    that we are missing the code to inject a pirq again in the guest when
    the guest EOIs it, if it corresponds to an emulated level interrupt
    and the interrupt is still asserted.
    
    Fix this issue and also return error when the guest tries to get the
    irq_status of a non-existing pirq.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24007:0526644ad2a6
    xen-unstable date:        Thu Oct 27 16:07:18 2011 +0100
    
    
changeset:   23182:9702967e89dd
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Sat Nov 12 16:14:02 2011 +0000
    
    Revert c/s 23666:b96f8bdcaa15 KEXEC: disconnect all PCI devices from the PCI bus on crash
    
    It turns out that this causes all mannor of problems on certain
    motherboards (so far with no pattern I can discern)
    
    Problems include:
    * Hanging forever checking hlt instruction.
    * Panics when trying to change switch root device
    * Drivers hanging when trying to check for interrupts.
    
    From: Andrew Cooper <andrew.cooper3@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24137:0844b17df7a9
    xen-unstable date:        Fri Nov 11 18:14:35 2011 +0000
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xensource.com Thu Nov 17 23:39:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 23:39:37 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRBYM-0002tk-QK
	for archives@lists.xen.org; Thu, 17 Nov 2011 23:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRBXy-0001HM-45; Thu, 17 Nov 2011 15:39:10 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRBXl-0001Fj-NU
	for Xen-devel@lists.xensource.com; Thu, 17 Nov 2011 15:38:59 -0800
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1321573131!2012017!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14120 invoked from network); 17 Nov 2011 23:38:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 23:38:53 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHNcl4b014166
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 23:38:47 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHNcjWY015860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 23:38:46 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHNceEY005255; Thu, 17 Nov 2011 17:38:40 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 15:38:39 -0800
Date: Thu, 17 Nov 2011 15:38:38 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] HYBRID: PV in HVM container
Message-ID: <20111117153838.04e15aa9@mantra.us.oracle.com>
In-Reply-To: <20110727185828.55099372@mantra.us.oracle.com>
References: <20110627122404.23d2d0ce@mantra.us.oracle.com>
	<20110630185431.3ea308c6@mantra.us.oracle.com>
	<20110708185301.4b040a21@mantra.us.oracle.com>
	<20110727185828.55099372@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="MP_/R.1sMt_LjPbCVVbgRW8Pwbf"
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4EC59B08.00B0,ss=1,re=-15.000,fgs=0
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--MP_/R.1sMt_LjPbCVVbgRW8Pwbf
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Alright, got hybrid with EPT numbers in now from my prototype, it needs
some perf work.. 

Attaching the diffs from my prototype. Linux: 2.6.39. Xen 4.0.2.


Processor, Processes - times in microseconds - smaller is better
------------------------------------------------------------------------------
Host                 OS  Mhz null null      open slct sig  sig  fork exec sh  
                             call  I/O stat clos TCP  inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
PV        Linux 2.6.39f 2639 0.65 0.88 2.14 4.59 3.77 0.79 3.62 535. 1294 3308
Hybrid    Linux 2.6.39f 2639 0.13 0.21 0.89 1.96 3.08 0.24 1.10 529. 1294 3246
HVM       Linux 2.6.39f 2639 0.12 0.21 0.64 1.76 3.04 0.24 3.37 113. 354. 1324
Baremetal Linux 2.6.39+ 2649 0.13 0.23 0.74 1.93 3.46 0.28 1.58 127. 386. 1434
HYB-EPT   Linux 2.6.39f 2639 0.13 0.21 0.68 1.95 3.04 0.25 3.09 145. 452. 1542


Basic integer operations - times in nanoseconds - smaller is better
-------------------------------------------------------------------
Host                 OS  intgr intgr  intgr  intgr  intgr  
                          bit   add    mul    div    mod   
--------- ------------- ------ ------ ------ ------ ------ 
PV        Linux 2.6.39f 0.3800 0.0100 0.1700 9.1000 9.0400
Hybrid    Linux 2.6.39f 0.3800 0.0100 0.1700 9.1100 9.0300
HVM       Linux 2.6.39f 0.3800 0.0100 0.1700 9.1100 9.0600
Baremetal Linux 2.6.39+ 0.3800 0.0100 0.1700 9.0600 8.9800
HYB-EPT   Linux 2.6.39f 0.3800 0.0100 0.1700 9.1200 9.0500


Basic float operations - times in nanoseconds - smaller is better
-----------------------------------------------------------------
Host                 OS  float  float  float  float
                         add    mul    div    bogo
--------- ------------- ------ ------ ------ ------ 
PV        Linux 2.6.39f 1.1300 1.5200 5.6200 5.2900
Hybrid    Linux 2.6.39f 1.1300 1.5200 5.6300 5.2900
HVM       Linux 2.6.39f 1.1400 1.5200 5.6300 5.3000
Baremetal Linux 2.6.39+ 1.1300 1.5100 5.6000 5.2700
HYB-EPT   Linux 2.6.39f 1.1400 1.5200 5.6300 5.3000


Basic double operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS  double double double double
                         add    mul    div    bogo
--------- ------------- ------  ------ ------ ------ 
PV        Linux 2.6.39f 1.1300 1.9000 8.6400 8.3200
Hybrid    Linux 2.6.39f 1.1400 1.9000 8.6600 8.3200
HVM       Linux 2.6.39f 1.1400 1.9000 8.6600 8.3300
Baremetal Linux 2.6.39+ 1.1300 1.8900 8.6100 8.2800
HYB-EPT   Linux 2.6.39f 1.1400 1.9000 8.6600 8.3300


Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                         ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
PV        Linux 2.6.39f 5.2800 5.7600 6.3600 6.3200 7.3600 6.69000 7.46000
Hybrid    Linux 2.6.39f 4.9200 4.9300 5.2200 5.7600 6.9600 6.12000 7.31000
HVM       Linux 2.6.39f 1.3100 1.2200 1.6200 1.9200 3.2600 2.23000 3.48000
Baremetal Linux 2.6.39+ 1.5500 1.4100 2.0600 2.2500 3.3900 2.44000 3.38000
HYB-EPT   Linux 2.6.39f 3.2000 3.6100 4.1700 4.3600 6.1200 4.81000 6.20000


*Local* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
PV        Linux 2.6.39f 5.280  16.6 21.3  25.9  33.7  34.7  41.8  87.
Hybrid    Linux 2.6.39f 4.920  11.2 14.4  19.6  26.1  27.5  32.9  71.
HVM       Linux 2.6.39f 1.310 4.416 6.15 9.386  14.8  15.8  20.1  45.
Baremetal Linux 2.6.39+ 1.550 4.625 7.34  14.3  19.8  21.4  26.4  66.
HYB-EPT   Linux 2.6.39f 3.200 8.669 15.3  17.5  23.5  25.1  30.4  66.


File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
                        Create Delete Create Delete Latency Fault  Fault  selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
PV        Linux 2.6.39f                               24.0K 0.746 3.55870 2.184
Hybrid    Linux 2.6.39f                               24.6K 0.238 4.00100 1.480
HVM       Linux 2.6.39f                              4716.0 0.202 0.96600 1.468
Baremetal Linux 2.6.39+                              6898.0 0.325 0.93610 1.620
HYB-EPT   Linux 2.6.39f                              5321.0 0.347 1.19510 1.480


*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
PV        Linux 2.6.39f 1661 2081 1041 3293.3 5528.3 3106.6 2800.0 4472 5633.
Hybrid    Linux 2.6.39f 1974 2450 1183 3481.5 5529.6 3114.9 2786.6 4470 5672.
HVM       Linux 2.6.39f 3232 2929 1622 3541.3 5527.5 3077.1 2765.6 4453 5634.
Baremetal Linux 2.6.39+ 3320 2800 1666 3523.6 5578.9 3147.0 2841.6 4541 5752.
HYB-EPT   Linux 2.6.39f 2104 2480 1231 3451.5 5503.4 3067.7 2751.0 4438 5636.


Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host                 OS   Mhz   L1 $   L2 $    Main mem    Rand mem    Guesses
--------- -------------   ---   ----   ----    --------    --------    -------
PV        Linux 2.6.39f  2639 1.5160 5.9170   29.7        97.5
Hybrid    Linux 2.6.39f  2639 1.5170 7.5000   29.7        97.4
HVM       Linux 2.6.39f  2639 1.5190 4.0210   29.8       105.4
Baremetal Linux 2.6.39+  2649 1.5090 3.8370   29.2        78.0
HYB-EPT   Linux 2.6.39f  2639 1.5180 4.0060   29.9       109.9


thanks,
Mukesh


On Wed, 27 Jul 2011 18:58:28 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> Hi folks,
> 
> Well, I did some benchmarking and found interesting results. Following
> runs are on a westmere with 2 sockets and 10GB RAM.  Xen was booted
> with maxcpus=2 and entire RAM. All guests were started with 1vcpu and
> 2GB RAM. dom0 started with 1 vcpu and 704MB. Baremetal was booted
> with 2GB and 1 cpu.  HVM guest has EPT enabled. HT is on.
> 
> So, unless the NUMA'ness interfered with results (using some memory
> on remote socket), it appears HVM does very well. To the point that it
> seems a hybrid is not going to be worth it. I am currently running
> tests on a single socket system just to be sure.
> 
> I am attaching my diff's in case any one wants to see what I did. I
> used xen 4.0.2 and linux 2.6.39. 
> 
> thanks,
> Mukesh
> 
>                  L M B E N C H  3 . 0   S U M M A R Y
> 
> Processor, Processes - times in microseconds - smaller is better
> ------------------------------------------------------------------------------

--MP_/R.1sMt_LjPbCVVbgRW8Pwbf
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=lin.diff

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 615e188..7791d31 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -1,7 +1,7 @@
 menu "Kernel hacking"
 
 config TRACE_IRQFLAGS_SUPPORT
-	def_bool y
+	def_bool n
 
 source "lib/Kconfig.debug"
 
diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 91f3e08..bdd7022 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -238,7 +238,8 @@ extern const char * const x86_power_flags[32];
 #define cpu_has_fpu		boot_cpu_has(X86_FEATURE_FPU)
 #define cpu_has_vme		boot_cpu_has(X86_FEATURE_VME)
 #define cpu_has_de		boot_cpu_has(X86_FEATURE_DE)
-#define cpu_has_pse		boot_cpu_has(X86_FEATURE_PSE)
+#define cpu_has_pse		0
+/* #define cpu_has_pse		boot_cpu_has(X86_FEATURE_PSE) */
 #define cpu_has_tsc		boot_cpu_has(X86_FEATURE_TSC)
 #define cpu_has_pae		boot_cpu_has(X86_FEATURE_PAE)
 #define cpu_has_pge		boot_cpu_has(X86_FEATURE_PGE)
diff --git a/arch/x86/include/asm/hypervisor.h b/arch/x86/include/asm/hypervisor.h
index 7a15153..f0bbb51 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -49,6 +49,7 @@ extern const struct hypervisor_x86 *x86_hyper;
 extern const struct hypervisor_x86 x86_hyper_vmware;
 extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
 extern const struct hypervisor_x86 x86_hyper_xen_hvm;
+extern const struct hypervisor_x86 x86_hyper_xen_hybrid;
 
 static inline bool hypervisor_x2apic_available(void)
 {
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 8095f86..5ec8dbb 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -37,6 +37,7 @@ static const __initconst struct hypervisor_x86 * const hypervisors[] =
 #ifdef CONFIG_XEN_PVHVM
 	&x86_hyper_xen_hvm,
 #endif
+        &x86_hyper_xen_hybrid,
 };
 
 const struct hypervisor_x86 *x86_hyper;
diff --git a/arch/x86/pci/direct.c b/arch/x86/pci/direct.c
index bd33620..89bfe86 100644
--- a/arch/x86/pci/direct.c
+++ b/arch/x86/pci/direct.c
@@ -282,6 +282,9 @@ int __init pci_direct_probe(void)
 {
 	struct resource *region, *region2;
 
+        if (xen_hybrid_domain())
+                return 0;
+
 	if ((pci_probe & PCI_PROBE_CONF1) == 0)
 		goto type2;
 	region = request_region(0xCF8, 8, "PCI conf1");
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3c6a06..53ceae0 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -110,7 +110,7 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
  *
  * 0: not available, 1: available
  */
-static int have_vcpu_info_placement = 1;
+static int have_vcpu_info_placement = 0;
 
 static void clamp_max_cpus(void)
 {
@@ -195,6 +195,13 @@ static void __init xen_banner(void)
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
+
+        if (xen_hybrid_domain()) {
+	        printk(KERN_INFO "MUK: is MUK HYBRID domain....");
+		if (xen_feature(XENFEAT_auto_translated_physmap))
+                	printk(KERN_INFO "with EPT...");
+        	printk(KERN_INFO "\n");
+        }
 }
 
 static __read_mostly unsigned int cpuid_leaf1_edx_mask = ~0;
@@ -222,8 +229,10 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		maskebx = 0;
 		break;
 	}
-
-	asm(XEN_EMULATE_PREFIX "cpuid"
+        if (xen_hybrid_domain()) {
+                native_cpuid(ax, bx, cx, dx);
+        } else
+	        asm(XEN_EMULATE_PREFIX "cpuid"
 		: "=a" (*ax),
 		  "=b" (*bx),
 		  "=c" (*cx),
@@ -244,6 +253,7 @@ static __init void xen_init_cpuid_mask(void)
 		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
 		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
 		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+                  (1 << X86_FEATURE_PSE)  |  /* disable 2M pages */
 		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
 
 	if (!xen_initial_domain())
@@ -393,6 +403,10 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
 		make_lowmem_page_readonly(virt);
 	}
 
+        if (xen_hybrid_domain()) {
+                native_load_gdt(dtr);
+                return;
+        }
 	if (HYPERVISOR_set_gdt(frames, size / sizeof(struct desc_struct)))
 		BUG();
 }
@@ -431,6 +445,10 @@ static __init void xen_load_gdt_boot(const struct desc_ptr *dtr)
 		frames[f] = mfn;
 	}
 
+        if (xen_hybrid_domain()) {
+                native_load_gdt(dtr);
+                return;
+        }
 	if (HYPERVISOR_set_gdt(frames, size / sizeof(struct desc_struct)))
 		BUG();
 }
@@ -849,9 +867,11 @@ void xen_setup_shared_info(void)
 
 		HYPERVISOR_shared_info =
 			(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
-	} else
+	} else {
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
+        	return;
+	}
 
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
@@ -944,6 +964,71 @@ static const struct pv_init_ops xen_init_ops __initdata = {
 	.patch = xen_patch,
 };
 
+extern void native_iret(void);
+extern void native_irq_enable_sysexit(void);
+extern void native_usergs_sysret32(void);
+extern void native_usergs_sysret64(void);
+
+static const struct pv_cpu_ops xen_hybrid_cpu_ops __initdata = {
+	.cpuid = xen_cpuid,
+
+	.set_debugreg = xen_set_debugreg,
+	.get_debugreg = xen_get_debugreg,
+
+	.clts = xen_clts,
+
+	.read_cr0 = xen_read_cr0,
+	.write_cr0 = xen_write_cr0,
+
+	.read_cr4 = native_read_cr4,
+	.read_cr4_safe = native_read_cr4_safe,
+	.write_cr4 = native_write_cr4,
+
+	.wbinvd = native_wbinvd,
+
+	.read_msr = native_read_msr_safe,
+	.write_msr = native_write_msr_safe,
+	.read_tsc = native_read_tsc,
+	.read_pmc = native_read_pmc,
+
+	.iret = native_iret,
+	.irq_enable_sysexit = native_irq_enable_sysexit,
+#ifdef CONFIG_X86_64
+	.usergs_sysret32 = native_usergs_sysret32,
+	.usergs_sysret64 = native_usergs_sysret64,
+#endif
+
+	.load_tr_desc = native_load_tr_desc,
+	.set_ldt = native_set_ldt,
+	.load_gdt = native_load_gdt,
+	.load_idt = native_load_idt,
+	.load_tls = native_load_tls,
+#ifdef CONFIG_X86_64
+	.load_gs_index = native_load_gs_index,
+#endif
+
+	.alloc_ldt = paravirt_nop,
+	.free_ldt = paravirt_nop,
+
+	.store_gdt = native_store_gdt,
+	.store_idt = native_store_idt,
+	.store_tr = native_store_tr,
+
+	.write_ldt_entry = native_write_ldt_entry,
+	.write_gdt_entry = native_write_gdt_entry,
+	.write_idt_entry = native_write_idt_entry,
+	.load_sp0 = native_load_sp0,
+
+	.set_iopl_mask = native_set_iopl_mask,
+	.io_delay = xen_io_delay,
+
+	/* Xen takes care of %gs when switching to usermode for us */
+	.swapgs = native_swapgs,
+
+	.start_context_switch = paravirt_start_context_switch,
+	.end_context_switch = xen_end_context_switch,
+};
+
 static const struct pv_cpu_ops xen_cpu_ops __initdata = {
 	.cpuid = xen_cpuid,
 
@@ -1010,6 +1095,11 @@ static const struct pv_apic_ops xen_apic_ops __initdata = {
 #endif
 };
 
+static void __init xen_hybrid_override_autox_cpu_ops(void)
+{
+        pv_cpu_ops.cpuid = xen_cpuid;
+}
+
 static void xen_reboot(int reason)
 {
 	struct sched_shutdown r = { .reason = reason };
@@ -1071,6 +1161,10 @@ static const struct machine_ops __initdata xen_machine_ops = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+        if (xen_hybrid_domain()) {
+                switch_to_new_gdt(0);
+                return;
+        }
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1093,14 +1187,22 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
 
+        if (xen_hybrid_domain()) {
+	        if (xen_feature(XENFEAT_auto_translated_physmap))
+                        xen_hybrid_override_autox_cpu_ops();
+                else
+	        	pv_cpu_ops = xen_hybrid_cpu_ops;
+        } else
+	        pv_cpu_ops = xen_cpu_ops;
+
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
 	x86_init.oem.banner = xen_banner;
@@ -1129,7 +1231,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
 
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
@@ -1214,10 +1315,12 @@ asmlinkage void __init xen_start_kernel(void)
 	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
 	 * which pokes 0xcf8 port.
 	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+        if (!xen_hybrid_domain()) {
+	        set_iopl.iopl = 1;
+	        rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+	        if (rc != 0)
+		        xen_raw_printk("physdev_op failed %d\n", rc);
+        }
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1388,3 +1491,29 @@ const __refconst struct hypervisor_x86 x86_hyper_xen_hvm = {
 };
 EXPORT_SYMBOL(x86_hyper_xen_hvm);
 #endif
+
+static bool __init xen_hybrid_platform_detect(void)
+{
+        return (xen_hybrid_domain());
+}
+
+
+const int xen_hybrid_rsvd_top_frames = 48;    /* 32 for grant + future */
+static void __init xen_hybrid_guest_init(void)
+{
+        if (xen_feature(XENFEAT_hvm_callback_vector))
+                xen_have_vector_callback = 1;
+
+	/* xen_hvm_smp_init(); */   /* <======================== */
+
+        /* adjust iomem_resource set in setup_arch() and reserve some frames
+         * for grant table etc for us */
+        iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1
+                             - xen_hybrid_rsvd_top_frames;
+}
+
+const __refconst struct hypervisor_x86 x86_hyper_xen_hybrid = {
+	.name			= "Xen Hybrid",
+	.detect			= xen_hybrid_platform_detect,
+	.init_platform		= xen_hybrid_guest_init,
+};
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 6a6fe89..1a161db 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -100,6 +100,9 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_irq_enable);
 
 static void xen_safe_halt(void)
 {
+        if (xen_hybrid_domain())
+                local_irq_enable();
+
 	/* Blocking includes an implicit local_irq_enable(). */
 	if (HYPERVISOR_sched_op(SCHEDOP_block, NULL) != 0)
 		BUG();
@@ -113,6 +116,19 @@ static void xen_halt(void)
 		xen_safe_halt();
 }
 
+static const struct pv_irq_ops xen_hybrid_irq_ops __initdata = {
+        .save_fl = __PV_IS_CALLEE_SAVE(native_save_fl),
+        .restore_fl = __PV_IS_CALLEE_SAVE(native_restore_fl),
+        .irq_disable = __PV_IS_CALLEE_SAVE(native_irq_disable),
+        .irq_enable = __PV_IS_CALLEE_SAVE(native_irq_enable),
+
+	.safe_halt = xen_safe_halt,
+	.halt = xen_halt,
+#ifdef CONFIG_X86_64
+	.adjust_exception_frame = paravirt_nop,
+#endif
+};
+
 static const struct pv_irq_ops xen_irq_ops __initdata = {
 	.save_fl = PV_CALLEE_SAVE(xen_save_fl),
 	.restore_fl = PV_CALLEE_SAVE(xen_restore_fl),
@@ -128,6 +144,9 @@ static const struct pv_irq_ops xen_irq_ops __initdata = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+        if (xen_hybrid_domain())
+	        pv_irq_ops = xen_hybrid_irq_ops;
+        else
+	        pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index f298bd7..2c50554 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1294,6 +1294,10 @@ static void xen_post_allocator_init(void);
 static __init void xen_pagetable_setup_done(pgd_t *base)
 {
 	xen_setup_shared_info();
+
+        if (xen_feature(XENFEAT_auto_translated_physmap))
+        	return;
+
 	xen_post_allocator_init();
 }
 
@@ -1685,15 +1689,18 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
-	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+                return;
+        }
+        if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
 
-static __init void xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
+static __init int xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
 {
-	unsigned pmdidx, pteidx;
-	unsigned ident_pte;
-	unsigned long pfn;
+	unsigned int pmdidx, pteidx;
+	unsigned int ident_pte;
+	unsigned int long pfn;
 
 	level1_ident_pgt = extend_brk(sizeof(pte_t) * LEVEL1_IDENT_ENTRIES,
 				      PAGE_SIZE);
@@ -1728,13 +1735,10 @@ static __init void xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
 			pte_page[pteidx] = pte;
 		}
 	}
-
-	for (pteidx = 0; pteidx < ident_pte; pteidx += PTRS_PER_PTE)
-		set_page_prot(&level1_ident_pgt[pteidx], PAGE_KERNEL_RO);
-
-	set_page_prot(pmd, PAGE_KERNEL_RO);
+        return ident_pte;
 }
 
+/* TBD: DON'T NEED THIS FOR HYBRID EPT???? */
 void __init xen_setup_machphys_mapping(void)
 {
 	struct xen_machphys_mapping mapping;
@@ -1775,6 +1779,7 @@ static void convert_pfn_mfn(void *v)
 __init pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd,
 					 unsigned long max_pfn)
 {
+        unsigned int pteidx, ident_ptes;
 	pud_t *l3;
 	pmd_t *l2;
 
@@ -1787,11 +1792,12 @@ __init pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd,
 	/* Zap identity mapping */
 	init_level4_pgt[0] = __pgd(0);
 
-	/* Pre-constructed entries are in pfn, so convert to mfn */
-	convert_pfn_mfn(init_level4_pgt);
-	convert_pfn_mfn(level3_ident_pgt);
-	convert_pfn_mfn(level3_kernel_pgt);
-
+	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+	        /* Pre-constructed entries are in pfn, so convert to mfn */
+	        convert_pfn_mfn(init_level4_pgt);
+	        convert_pfn_mfn(level3_ident_pgt);
+	        convert_pfn_mfn(level3_kernel_pgt);
+        }
 	l3 = m2v(pgd[pgd_index(__START_KERNEL_map)].pgd);
 	l2 = m2v(l3[pud_index(__START_KERNEL_map)].pud);
 
@@ -1803,7 +1809,11 @@ __init pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd,
 	memcpy(level2_fixmap_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);
 
 	/* Set up identity map */
-	xen_map_identity_early(level2_ident_pgt, max_pfn);
+	ident_ptes = xen_map_identity_early(level2_ident_pgt, max_pfn);
+
+	for (pteidx = 0; pteidx < ident_ptes; pteidx += PTRS_PER_PTE)
+		set_page_prot(&level1_ident_pgt[pteidx], PAGE_KERNEL_RO);
+	set_page_prot(level2_ident_pgt, PAGE_KERNEL_RO);
 
 	/* Make pagetable pieces RO */
 	set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
@@ -1813,12 +1823,14 @@ __init pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd,
 	set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
 	set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);
 
-	/* Pin down new L4 */
-	pin_pagetable_pfn(MMUEXT_PIN_L4_TABLE,
-			  PFN_DOWN(__pa_symbol(init_level4_pgt)));
+	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* Pin down new L4 */
+		pin_pagetable_pfn(MMUEXT_PIN_L4_TABLE,
+			  	PFN_DOWN(__pa_symbol(init_level4_pgt)));
 
-	/* Unpin Xen-provided one */
-	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
+		/* Unpin Xen-provided one */
+		pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
+	}
 
 	/* Switch over */
 	pgd = init_level4_pgt;
@@ -1828,9 +1840,13 @@ __init pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd,
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(pgd));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+                native_write_cr3(__pa(pgd));
+        } else {
+	        xen_mc_batch();
+	        __xen_write_cr3(true, __pa(pgd));
+	        xen_mc_issue(PARAVIRT_LAZY_CPU);
+        }
 
 	memblock_x86_reserve_range(__pa(xen_start_info->pt_base),
 		      __pa(xen_start_info->pt_base +
@@ -2117,14 +2133,26 @@ static const struct pv_mmu_ops xen_mmu_ops __initdata = {
 	.set_fixmap = xen_set_fixmap,
 };
 
+static __init void xen_hyb_override_mmu_ops(void)
+{
+        pv_mmu_ops.read_cr2 = native_read_cr2;
+        pv_mmu_ops.write_cr2 = native_write_cr2;
+}
+
 void __init xen_init_mmu_ops(void)
 {
+	memset(dummy_mapping, 0xff, PAGE_SIZE);
+	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+        	return;
+
 	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
-	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
-	pv_mmu_ops = xen_mmu_ops;
+        pv_mmu_ops = xen_mmu_ops;
 
-	memset(dummy_mapping, 0xff, PAGE_SIZE);
+        if (xen_hybrid_domain())      /* hybrid without EPT, ie, pv paging. */
+		xen_hyb_override_mmu_ops();
 }
 
 /* Protected by xen_reservation_lock. */
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index adaf127..9a2a576 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -391,12 +391,9 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+static __init void xen_nonhybrid_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
-	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		HYPERVISOR_vm_assist(VMASST_CMD_enable,
@@ -415,6 +412,14 @@ void __init xen_arch_setup(void)
 		disable_acpi();
 	}
 #endif
+}
+
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
+	if (!xen_hybrid_domain())
+                xen_nonhybrid_arch_setup();
 
 	memcpy(boot_command_line, xen_start_info->cmd_line,
 	       MAX_GUEST_CMDLINE > COMMAND_LINE_SIZE ?
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3061244..0b0464e 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -195,10 +195,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+	   	   old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
diff --git a/drivers/tty/serial/8250.c b/drivers/tty/serial/8250.c
index 6611535..1a3ebbc 100644
--- a/drivers/tty/serial/8250.c
+++ b/drivers/tty/serial/8250.c
@@ -3294,6 +3294,9 @@ static int __init serial8250_init(void)
 {
 	int ret;
 
+	if (xen_hybrid_domain())
+		return -ENODEV;
+
 	if (nr_uarts > UART_NR)
 		nr_uarts = UART_NR;
 
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 14e2d99..631a019 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -99,7 +99,7 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	if (!xen_pv_domain() || xen_hybrid_domain())
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 33167b4..69bad2e 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1632,5 +1632,7 @@ void __init xen_init_IRQ(void)
 		irq_ctx_init(smp_processor_id());
 		if (xen_initial_domain())
 			xen_setup_pirqs();
+                if (xen_hybrid_domain())
+		        xen_callback_vector();
 	}
 }
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 3745a31..ff57b55 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -46,6 +46,8 @@
 #include <xen/interface/memory.h>
 #include <asm/xen/hypercall.h>
 
+#include <asm/page.h>
+#include <asm/tlbflush.h>
 #include <asm/pgtable.h>
 #include <asm/sync_bitops.h>
 
@@ -503,6 +505,56 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static int ptefunc(pte_t *pte, pgtable_t table, unsigned long addr, void *data)
+{
+        pte_t pteval = pfn_pte(virt_to_pfn(addr), PAGE_KERNEL);
+        set_pte(pte, pteval);
+	return 0;
+}
+
+
+extern int xen_hybrid_rsvd_top_frames;
+static int gnttab_map_hyb_autox(unsigned int start_idx, unsigned int end_idx)
+{
+	struct xen_add_to_physmap xatp;
+	unsigned int i = end_idx;
+	unsigned int nr_gframes = end_idx + 1;
+	int rc = 0;
+
+        if (shared == NULL) {
+                unsigned long numgf = gnttab_max_grant_frames();
+                unsigned long maxp = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
+                unsigned long gntpfn = (maxp >> PAGE_SHIFT) - numgf;
+
+                BUG_ON(numgf > xen_hybrid_rsvd_top_frames);
+                shared = __va(gntpfn << PAGE_SHIFT);
+        }
+
+        /* will reinsert entries in shared[0...n-1], but its OK */
+        rc = apply_to_page_range(&init_mm, shared, 
+                                 PAGE_SIZE*nr_gframes, ptefunc, NULL);
+        BUG_ON(rc);
+
+	/*
+	 * Loop backwards, so that the first hypercall has the largest
+	 * index, ensuring that the table will grow only once.
+	 */
+	do {
+		xatp.domid = DOMID_SELF;
+		xatp.idx = i;
+		xatp.space = XENMAPSPACE_grant_table;
+		xatp.gpfn = (virt_to_pfn(shared)) + i;
+		rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+		if (rc != 0) {
+			printk(KERN_WARNING
+			     "grant table add_to_physmap failed, err=%d\n", rc);
+			break;
+		}
+	} while (i-- > start_idx);
+
+        return rc;
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
@@ -510,6 +562,9 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
+        if (xen_hybrid_autoxlate_domain())
+        	return gnttab_map_hyb_autox(start_idx, end_idx);
+
 	if (xen_hvm_domain()) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 7397695..2429d0e 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -737,7 +737,13 @@ static int __init xenbus_init(void)
 
 		xen_store_interface = mfn_to_virt(xen_store_mfn);
 	} else {
-		if (xen_hvm_domain()) {
+		if (xen_hybrid_autoxlate_domain()) {
+                	xen_store_evtchn = xen_start_info->store_evtchn;
+			xen_store_mfn = xen_start_info->store_mfn;  /* pfn */
+			xen_store_interface = __va(xen_store_mfn<<PAGE_SHIFT);
+			xenstored_ready = 1;
+
+		} else if (xen_hvm_domain()) {
 			uint64_t v = 0;
 			err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
 			if (err)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index ee048e7..0758b26 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -1,6 +1,8 @@
 #ifndef __KERNEL_PRINTK__
 #define __KERNEL_PRINTK__
 
+extern void mukchk(unsigned long);
+
 extern const char linux_banner[];
 extern const char linux_proc_banner[];
 
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index b33257b..805eb60 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -452,6 +452,7 @@ struct start_info {
 /* These flags are passed in the 'flags' field of start_info_t. */
 #define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
 #define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
+#define SIF_IS_HYBRID     (1<<3)  /* Is it a PV running in HVM container? */
 
 typedef uint64_t cpumap_t;
 
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a164024..0c3fca1 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -18,7 +18,11 @@ extern enum xen_domain_type xen_domain_type;
 				 xen_domain_type == XEN_PV_DOMAIN)
 #define xen_hvm_domain()	(xen_domain() &&			\
 				 xen_domain_type == XEN_HVM_DOMAIN)
-
+/* xen_pv_domain check is necessary as start_info ptr is null in HVM */
+#define xen_hybrid_domain()     (xen_pv_domain () &&                    \
+                                 (xen_start_info->flags & SIF_IS_HYBRID))
+#define xen_hybrid_autoxlate_domain() (xen_hybrid_domain() &&  \
+                                 (xen_feature(XENFEAT_auto_translated_physmap)))
 #ifdef CONFIG_XEN_DOM0
 #include <xen/interface/xen.h>
 #include <asm/xen/hypervisor.h>

--MP_/R.1sMt_LjPbCVVbgRW8Pwbf
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen.diff

diff -r f2cf898c7ff8 tools/debugger/gdbsx/xg/xg_main.c
--- a/tools/debugger/gdbsx/xg/xg_main.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/debugger/gdbsx/xg/xg_main.c	Thu Nov 17 15:37:30 2011 -0800
@@ -80,6 +80,7 @@ int xgtrc_on = 0;
 struct xen_domctl domctl;         /* just use a global domctl */
 
 static int     _hvm_guest;        /* hvm guest? 32bit HVMs have 64bit context */
+static int     _hybrid_guest;
 static domid_t _dom_id;           /* guest domid */
 static int     _max_vcpu_id;      /* thus max_vcpu_id+1 VCPUs */
 static int     _dom0_fd;          /* fd of /dev/privcmd */
@@ -308,6 +309,8 @@ xg_attach(int domid, int guest_bitness)
 
     _max_vcpu_id = domctl.u.getdomaininfo.max_vcpu_id;
     _hvm_guest = (domctl.u.getdomaininfo.flags & XEN_DOMINF_hvm_guest);
+    _hybrid_guest = (domctl.u.getdomaininfo.flags & XEN_DOMINF_hybrid_guest);
+
     return _max_vcpu_id;
 }
 
@@ -368,7 +371,7 @@ _change_TF(vcpuid_t which_vcpu, int gues
     int sz = sizeof(anyc);
 
     /* first try the MTF for hvm guest. otherwise do manually */
-    if (_hvm_guest) {
+    if (_hvm_guest || _hybrid_guest) {
         domctl.u.debug_op.vcpu = which_vcpu;
         domctl.u.debug_op.op = setit ? XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_ON :
                                        XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_OFF;
diff -r f2cf898c7ff8 tools/libxc/Makefile
--- a/tools/libxc/Makefile	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxc/Makefile	Thu Nov 17 15:37:30 2011 -0800
@@ -58,7 +58,7 @@ GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_i
 -include $(XEN_TARGET_ARCH)/Makefile
 
 CFLAGS   += -Werror -Wmissing-prototypes
-CFLAGS   += $(INCLUDES) -I. -I../xenstore -I../include
+CFLAGS   += $(INCLUDES) -I. -I../xenstore -I../include -g -O0
 
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
diff -r f2cf898c7ff8 tools/libxc/xc_dom.h
--- a/tools/libxc/xc_dom.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxc/xc_dom.h	Thu Nov 17 15:37:30 2011 -0800
@@ -110,6 +110,9 @@ struct xc_dom_image {
     struct xc_dom_arch *arch_hooks;
     /* allocate up to virt_alloc_end */
     int (*allocate) (struct xc_dom_image * dom, xen_vaddr_t up_to);
+
+    /* hybrid flags */
+    char hybrid_hap;
 };
 
 /* --- pluggable kernel loader ------------------------------------- */
@@ -241,7 +244,8 @@ static inline void *xc_dom_vaddr_to_ptr(
 
 static inline int xc_dom_feature_translated(struct xc_dom_image *dom)
 {
-    return elf_xen_feature_get(XENFEAT_auto_translated_physmap, dom->f_active);
+    return(dom->hybrid_hap || 
+           elf_xen_feature_get(XENFEAT_auto_translated_physmap, dom->f_active));
 }
 
 static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
diff -r f2cf898c7ff8 tools/libxc/xc_dom_x86.c
--- a/tools/libxc/xc_dom_x86.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxc/xc_dom_x86.c	Thu Nov 17 15:37:30 2011 -0800
@@ -372,7 +372,8 @@ static int setup_pgtables_x86_64(struct 
         pgpfn = (addr - dom->parms.virt_base) >> PAGE_SHIFT_X86;
         l1tab[l1off] =
             pfn_to_paddr(xc_dom_p2m_guest(dom, pgpfn)) | L1_PROT;
-        if ( (addr >= dom->pgtables_seg.vstart) && 
+        if ( !dom->hybrid_hap                   &&
+             (addr >= dom->pgtables_seg.vstart) && 
              (addr < dom->pgtables_seg.vend) )
             l1tab[l1off] &= ~_PAGE_RW; /* page tables are r/o */
         if ( l1off == (L1_PAGETABLE_ENTRIES_X86_64 - 1) )
@@ -819,7 +820,7 @@ int arch_setup_bootlate(struct xc_dom_im
         }
 
         /* Map grant table frames into guest physmap. */
-        for ( i = 0; ; i++ )
+        for ( i = 0; !dom->hybrid_hap ; i++ )
         {
             xatp.domid = dom->guest_domid;
             xatp.space = XENMAPSPACE_grant_table;
diff -r f2cf898c7ff8 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxl/Makefile	Thu Nov 17 15:37:30 2011 -0800
@@ -12,7 +12,7 @@ XLUMAJOR = 1.0
 XLUMINOR = 0
 
 CFLAGS += -Werror
-CFLAGS += -I. -fPIC
+CFLAGS += -I. -fPIC -g -O0
 CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 
 LIBS = $(LDFLAGS_libxenctrl) $(LDFLAGS_libxenguest) $(LDFLAGS_libxenstore)
diff -r f2cf898c7ff8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxl/libxl.c	Thu Nov 17 15:37:30 2011 -0800
@@ -99,6 +99,7 @@ int libxl_domain_make(struct libxl_ctx *
     if (!uuid_string) return ERROR_NOMEM;
 
     flags = info->hvm ? XEN_DOMCTL_CDF_hvm_guest : 0;
+    flags |= info->hybrid ? XEN_DOMCTL_CDF_hybrid_guest : 0;
     flags |= info->hap ? XEN_DOMCTL_CDF_hap : 0;
     flags |= info->oos ? 0 : XEN_DOMCTL_CDF_oos_off;
     *domid = -1;
diff -r f2cf898c7ff8 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxl/libxl.h	Thu Nov 17 15:37:30 2011 -0800
@@ -78,6 +78,7 @@ const libxl_version_info* libxl_get_vers
 
 typedef struct {
     bool hvm;
+    bool hybrid;
     bool hap;
     bool oos;
     int ssidref;
@@ -97,6 +98,8 @@ typedef struct {
     uint32_t shadow_memkb;
     const char *kernel;
     int hvm;
+    int hybrid;
+    int hybrid_hap;
     union {
         struct {
             bool pae;
diff -r f2cf898c7ff8 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Nov 17 15:37:30 2011 -0800
@@ -69,7 +69,7 @@ int build_pre(struct libxl_ctx *ctx, uin
             (info->max_memkb + info->u.pv.slack_memkb));
     xc_domain_set_tsc_info(ctx->xch, domid, info->tsc_mode, 0, 0, 0);
 
-    if (info->hvm) {
+    if (info->hvm || info->hybrid) {
         unsigned long shadow;
         shadow = (info->shadow_memkb + 1023) / 1024;
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
@@ -139,13 +139,16 @@ int build_pv(struct libxl_ctx *ctx, uint
 {
     struct xc_dom_image *dom;
     int ret;
-    int flags = 0;
+    int flags;               /* start info flags: start_info_x86_64() */
+
+    flags = info->hybrid ? SIF_IS_HYBRID : 0;
 
     dom = xc_dom_allocate(info->u.pv.cmdline, info->u.pv.features);
     if (!dom) {
         XL_LOG_ERRNO(ctx, XL_LOG_ERROR, "xc_dom_allocate failed");
         return -1;
     }
+    dom->hybrid_hap = info->hybrid_hap ? 1 : 0;
     ret = xc_dom_linux_build(ctx->xch, dom, domid, info->target_memkb / 1024,
                                   info->kernel, info->u.pv.ramdisk, flags,
                                   state->store_port, &state->store_mfn,
diff -r f2cf898c7ff8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 15:37:30 2011 -0800
@@ -197,6 +197,11 @@ static void init_build_info(libxl_domain
     } else {
         b_info->u.pv.slack_memkb = 8 * 1024;
     }
+    if (c_info->hybrid) {
+        b_info->hybrid = 1;
+        if (c_info->hap)
+            b_info->hybrid_hap = 1;
+    }
 }
 
 static void init_dm_info(libxl_device_model_info *dm_info,
@@ -469,6 +474,11 @@ static void parse_config_data(const char
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->hvm = 1;
 
+    c_info->hybrid = 0;
+    if (!xlu_cfg_get_long (config, "hybrid", &l))
+        c_info->hybrid = 1;
+
+    c_info->hap = 0;
     if (!xlu_cfg_get_long (config, "hap", &l))
         c_info->hap = l;
 
diff -r f2cf898c7ff8 xen/arch/x86/debug.c
--- a/xen/arch/x86/debug.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/debug.c	Thu Nov 17 15:37:30 2011 -0800
@@ -43,7 +43,6 @@ extern void kdbp(const char *fmt, ...);
 typedef unsigned long dbgva_t;
 typedef unsigned char dbgbyte_t;
 
-
 /* Returns: mfn for the given (hvm guest) vaddr */
 static unsigned long 
 dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr)
@@ -55,6 +54,7 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct dom
     DBGP2("vaddr:%lx domid:%d\n", vaddr, dp->domain_id);
 
     gfn = paging_gva_to_gfn(dp->vcpu[0], vaddr, &pfec);
+
     if ( gfn == INVALID_GFN )
     {
         DBGP2("kdb:bad gfn from gva_to_gfn\n");
@@ -200,7 +200,7 @@ dbg_rw_guest_mem(dbgva_t addr, dbgbyte_t
 
         pagecnt = min_t(long, PAGE_SIZE - (addr & ~PAGE_MASK), len);
 
-        mfn = (dp->is_hvm
+        mfn = ( (is_hvm_domain(dp) || is_hyb_hap_domain(dp))
                ? dbg_hvm_va2mfn(addr, dp, toaddr)
                : dbg_pv_va2mfn(addr, dp, pgd3));
         if ( mfn == INVALID_MFN ) 
@@ -225,7 +225,6 @@ dbg_rw_guest_mem(dbgva_t addr, dbgbyte_t
         buf += pagecnt;
         len -= pagecnt;
     }
-
     return len;
 }
 
diff -r f2cf898c7ff8 xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/domain.c	Thu Nov 17 15:37:30 2011 -0800
@@ -160,6 +160,7 @@ void dump_pageframe_info(struct domain *
         spin_unlock(&d->page_alloc_lock);
     }
 
+    KASSERT(!is_hybrid_domain(d) );
     if ( is_hvm_domain(d) )
     {
         p2m_pod_dump_data(d);
@@ -354,7 +355,7 @@ int vcpu_initialise(struct vcpu *v)
 
     paging_vcpu_init(v);
 
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
     {
         if ( (rc = hvm_vcpu_initialise(v)) != 0 )
             return rc;
@@ -410,7 +411,7 @@ int arch_domain_create(struct domain *d,
     int rc = -ENOMEM;
 
     d->arch.hvm_domain.hap_enabled =
-        is_hvm_domain(d) &&
+        (is_hvm_or_hyb_domain(d)) &&
         hvm_funcs.hap_supported &&
         (domcr_flags & DOMCRF_hap);
     d->arch.hvm_domain.mem_sharing_enabled = 0;
@@ -508,7 +509,7 @@ int arch_domain_create(struct domain *d,
         mce_init_msr(d);
     }
 
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
     {
         if ( (rc = hvm_domain_initialise(d)) != 0 )
         {
@@ -562,7 +563,7 @@ void arch_domain_destroy(struct domain *
     unsigned int i;
 #endif
 
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         hvm_domain_destroy(d);
 
     pci_release_devices(d);
@@ -608,6 +609,8 @@ unsigned long pv_guest_cr4_fixup(unsigne
     return (hv_cr4 & hv_cr4_mask) | (guest_cr4 & ~hv_cr4_mask);
 }
 
+extern void hybrid_update_cr3(struct vcpu *);
+
 /* This is called by arch_final_setup_guest and do_boot_vcpu */
 int arch_set_info_guest(
     struct vcpu *v, vcpu_guest_context_u c)
@@ -628,7 +631,7 @@ int arch_set_info_guest(
 #endif
     flags = c(flags);
 
-    if ( !is_hvm_vcpu(v) )
+    if ( !is_hvm_or_hyb_domain(d) )
     {
         if ( !compat )
         {
@@ -677,7 +680,7 @@ int arch_set_info_guest(
     v->fpu_initialised = !!(flags & VGCF_I387_VALID);
 
     v->arch.flags &= ~TF_kernel_mode;
-    if ( (flags & VGCF_in_kernel) || is_hvm_vcpu(v)/*???*/ )
+    if ( (flags & VGCF_in_kernel) || is_hvm_or_hyb_vcpu(v) )
         v->arch.flags |= TF_kernel_mode;
 
     if ( !compat )
@@ -689,18 +692,13 @@ int arch_set_info_guest(
 
     v->arch.guest_context.user_regs.eflags |= 2;
 
-    if ( is_hvm_vcpu(v) )
+    if ( is_hvm_or_hyb_vcpu(v) )
     {
         hvm_set_info_guest(v);
-        goto out;
+        if ( !is_hybrid_vcpu(v) ) 
+            goto out;
     }
 
-    /* Only CR0.TS is modifiable by guest or admin. */
-    v->arch.guest_context.ctrlreg[0] &= X86_CR0_TS;
-    v->arch.guest_context.ctrlreg[0] |= read_cr0() & ~X86_CR0_TS;
-
-    init_int80_direct_trap(v);
-
     /* IOPL privileges are virtualised. */
     v->arch.iopl = (v->arch.guest_context.user_regs.eflags >> 12) & 3;
     v->arch.guest_context.user_regs.eflags &= ~X86_EFLAGS_IOPL;
@@ -708,38 +706,50 @@ int arch_set_info_guest(
     /* Ensure real hardware interrupts are enabled. */
     v->arch.guest_context.user_regs.eflags |= X86_EFLAGS_IF;
 
-    cr4 = v->arch.guest_context.ctrlreg[4];
-    v->arch.guest_context.ctrlreg[4] = cr4 ? pv_guest_cr4_fixup(cr4) :
-        real_cr4_to_pv_guest_cr4(mmu_cr4_features);
-
     memset(v->arch.guest_context.debugreg, 0,
            sizeof(v->arch.guest_context.debugreg));
     for ( i = 0; i < 8; i++ )
         (void)set_debugreg(v, i, c(debugreg[i]));
 
+    if ( !is_hybrid_vcpu(v) )
+    {
+        /* Only CR0.TS is modifiable by guest or admin. */
+        v->arch.guest_context.ctrlreg[0] &= X86_CR0_TS;
+        v->arch.guest_context.ctrlreg[0] |= read_cr0() & ~X86_CR0_TS;
+
+        init_int80_direct_trap(v);
+
+        cr4 = v->arch.guest_context.ctrlreg[4];
+        v->arch.guest_context.ctrlreg[4] = cr4 ? pv_guest_cr4_fixup(cr4) :
+            real_cr4_to_pv_guest_cr4(mmu_cr4_features);
+    }
+
     if ( v->is_initialised )
         goto out;
 
     if ( v->vcpu_id == 0 )
         d->vm_assist = c(vm_assist);
 
-    if ( !compat )
-        rc = (int)set_gdt(v, c.nat->gdt_frames, c.nat->gdt_ents);
+    if ( !is_hybrid_vcpu(v) )
+    {
+        if ( !compat )
+            rc = (int)set_gdt(v, c.nat->gdt_frames, c.nat->gdt_ents);
 #ifdef CONFIG_COMPAT
-    else
-    {
-        unsigned long gdt_frames[ARRAY_SIZE(c.cmp->gdt_frames)];
-        unsigned int i, n = (c.cmp->gdt_ents + 511) / 512;
+        else
+        {
+            unsigned long gdt_frames[ARRAY_SIZE(c.cmp->gdt_frames)];
+            unsigned int i, n = (c.cmp->gdt_ents + 511) / 512;
 
-        if ( n > ARRAY_SIZE(c.cmp->gdt_frames) )
-            return -EINVAL;
-        for ( i = 0; i < n; ++i )
-            gdt_frames[i] = c.cmp->gdt_frames[i];
-        rc = (int)set_gdt(v, gdt_frames, c.cmp->gdt_ents);
+            if ( n > ARRAY_SIZE(c.cmp->gdt_frames) )
+                return -EINVAL;
+            for ( i = 0; i < n; ++i )
+                gdt_frames[i] = c.cmp->gdt_frames[i];
+            rc = (int)set_gdt(v, gdt_frames, c.cmp->gdt_ents);
+        }
+#endif
+        if ( rc != 0 )
+            return rc;
     }
-#endif
-    if ( rc != 0 )
-        return rc;
 
     if ( !compat )
     {
@@ -751,10 +761,17 @@ int arch_set_info_guest(
               : !get_page_and_type(mfn_to_page(cr3_pfn), d,
                                    PGT_base_page_table)) )
         {
-            destroy_gdt(v);
+            if ( !is_hybrid_vcpu(v) )
+                destroy_gdt(v);
             return -EINVAL;
         }
 
+        if (is_hybrid_vcpu(v) && paging_mode_enabled(d))
+        {
+            v->arch.cr3 = cr3_pfn;
+            v->arch.hvm_vcpu.guest_cr[3] = c.nat->ctrlreg[3];
+        }
+
         v->arch.guest_table = pagetable_from_pfn(cr3_pfn);
 
 #ifdef __x86_64__
@@ -782,7 +799,8 @@ int arch_set_info_guest(
         }
         else if ( !(flags & VGCF_in_kernel) )
         {
-            destroy_gdt(v);
+            if ( !is_hybrid_vcpu(v) )
+                destroy_gdt(v);
             return -EINVAL;
         }
     }
@@ -818,6 +836,13 @@ int arch_set_info_guest(
         paging_update_paging_modes(v);
 
     update_cr3(v);
+    if (is_hybrid_vcpu(v))
+    {
+        if (paging_mode_enabled(d))   /* HAP is enabled */
+            hvm_update_host_cr3(v);   /* GUEST_CR3 updated in update_cr3() */
+        else
+            hybrid_update_cr3(v);
+    }
 
  out:
     if ( flags & VGCF_online )
@@ -1347,10 +1372,10 @@ static void update_runstate_area(struct 
 
 static inline int need_full_gdt(struct vcpu *v)
 {
-    return (!is_hvm_vcpu(v) && !is_idle_vcpu(v));
+    return (!is_hvm_vcpu(v) && !is_idle_vcpu(v) && !is_hybrid_vcpu(v)); 
 }
 
-static void __context_switch(void)
+static noinline void __context_switch(void)
 {
     struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
     unsigned int          cpu = smp_processor_id();
@@ -1475,18 +1500,30 @@ void context_switch(struct vcpu *prev, s
         /* Re-enable interrupts before restoring state which may fault. */
         local_irq_enable();
 
-        if ( !is_hvm_vcpu(next) )
+        if ( !is_hvm_or_hyb_vcpu(next) )
         {
             load_LDT(next);
             load_segments(next);
         }
     }
-
     context_saved(prev);
 
     if (prev != next)
         update_runstate_area(next);
 
+#if 0
+{
+struct vcpu_runstate_info rst; 
+struct vcpu_runstate_info *tp = 
+        (struct vcpu_runstate_info *)(runstate_guest(next)).p;
+if (tp)
+    copy_from_guest(&rst, runstate_guest(next), 1);
+
+kdbtrc(0xeeffee, rst.state, (ulong)next, (ulong)tp, 
+       (ulong)next->runstate.state);
+}
+#endif
+
     schedule_tail(next);
     BUG();
 }
@@ -2034,7 +2071,7 @@ int domain_relinquish_resources(struct d
         BUG();
     }
 
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         hvm_domain_relinquish_resources(d);
 
     return 0;
@@ -2115,7 +2152,7 @@ void vcpu_mark_events_pending(struct vcp
     if ( already_pending )
         return;
 
-    if ( is_hvm_vcpu(v) )
+    if ( is_hvm_or_hyb_vcpu(v) ) 
         hvm_assert_evtchn_irq(v);
     else
         vcpu_kick(v);
diff -r f2cf898c7ff8 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/domctl.c	Thu Nov 17 15:37:30 2011 -0800
@@ -466,6 +466,7 @@ long arch_do_domctl(
             goto sethvmcontext_out;
 
         ret = -EINVAL;
+        KASSERT(!is_hybrid_domain(d));
         if ( !is_hvm_domain(d) ) 
             goto sethvmcontext_out;
 
@@ -503,6 +504,7 @@ long arch_do_domctl(
             goto gethvmcontext_out;
 
         ret = -EINVAL;
+        KASSERT(!is_hybrid_domain(d));
         if ( !is_hvm_domain(d) ) 
             goto gethvmcontext_out;
 
@@ -558,6 +560,7 @@ long arch_do_domctl(
             goto gethvmcontext_partial_out;
 
         ret = -EINVAL;
+        KASSERT(!is_hybrid_domain(d));
         if ( !is_hvm_domain(d) ) 
             goto gethvmcontext_partial_out;
 
@@ -719,6 +722,7 @@ long arch_do_domctl(
         case XEN_DOMCTL_SENDTRIGGER_POWER:
         {
             ret = -EINVAL;
+            KASSERT(!is_hybrid_domain(d));
             if ( is_hvm_domain(d) ) 
             {
                 ret = 0;
@@ -731,6 +735,7 @@ long arch_do_domctl(
         {
             extern void hvm_acpi_sleep_button(struct domain *d);
 
+            KASSERT(!is_hybrid_domain(d));
             ret = -EINVAL;
             if ( is_hvm_domain(d) ) 
             {
@@ -1285,7 +1290,7 @@ long arch_do_domctl(
             goto debug_op_out;
 
         ret = -EINVAL;
-        if ( !is_hvm_domain(d))
+        if ( !is_hvm_or_hyb_domain(d))
             goto debug_op_out;
 
         ret = hvm_debug_op(v, domctl->u.debug_op.op);
@@ -1465,8 +1470,9 @@ void arch_get_info_guest(struct vcpu *v,
         c(flags |= VGCF_i387_valid);
     if ( !test_bit(_VPF_down, &v->pause_flags) )
         c(flags |= VGCF_online);
-
-    if ( is_hvm_vcpu(v) )
+        
+    /* HYBRID TDB: debugregs? Verify this again */
+    if ( is_hvm_or_hyb_vcpu(v) )
     {
         struct segment_register sreg;
         memset(c.nat->ctrlreg, 0, sizeof(c.nat->ctrlreg));
diff -r f2cf898c7ff8 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Thu Nov 17 15:37:30 2011 -0800
@@ -227,6 +227,9 @@ void hvm_do_resume(struct vcpu *v)
 {
     ioreq_t *p;
 
+    if (is_hybrid_vcpu(v))
+        return;
+
     pt_restore_timer(v);
 
     /* NB. Optimised for common case (p->state == STATE_IOREQ_NONE). */
@@ -367,16 +370,21 @@ int hvm_domain_initialise(struct domain 
         return -EINVAL;
     }
 
-    spin_lock_init(&d->arch.hvm_domain.pbuf_lock);
     spin_lock_init(&d->arch.hvm_domain.irq_lock);
-    spin_lock_init(&d->arch.hvm_domain.uc_lock);
-
-    INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
-    spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
-
     hvm_init_guest_time(d);
-
-    d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
+    
+    if (is_hybrid_domain(d)) {
+        if (!d->arch.hvm_domain.hap_enabled)
+            return 0;
+    } else {
+        spin_lock_init(&d->arch.hvm_domain.pbuf_lock);
+        spin_lock_init(&d->arch.hvm_domain.uc_lock);
+
+        INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
+        spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
+
+        d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
+    }
 
     hvm_init_cacheattr_region_list(d);
 
@@ -384,20 +392,22 @@ int hvm_domain_initialise(struct domain 
     if ( rc != 0 )
         goto fail1;
 
-    vpic_init(d);
-
-    rc = vioapic_init(d);
-    if ( rc != 0 )
-        goto fail1;
-
-    stdvga_init(d);
-
-    rtc_init(d);
-
-    hvm_init_ioreq_page(d, &d->arch.hvm_domain.ioreq);
-    hvm_init_ioreq_page(d, &d->arch.hvm_domain.buf_ioreq);
-
-    register_portio_handler(d, 0xe9, 1, hvm_print_line);
+    if (!is_hybrid_domain(d)) {
+        vpic_init(d);
+
+        rc = vioapic_init(d);
+        if ( rc != 0 )
+            goto fail1;
+
+        stdvga_init(d);
+
+        rtc_init(d);
+
+        hvm_init_ioreq_page(d, &d->arch.hvm_domain.ioreq);
+        hvm_init_ioreq_page(d, &d->arch.hvm_domain.buf_ioreq);
+
+        register_portio_handler(d, 0xe9, 1, hvm_print_line);
+    }
 
     rc = hvm_funcs.domain_initialise(d);
     if ( rc != 0 )
@@ -406,9 +416,11 @@ int hvm_domain_initialise(struct domain 
     return 0;
 
  fail2:
-    rtc_deinit(d);
-    stdvga_deinit(d);
-    vioapic_deinit(d);
+    if (!is_hybrid_domain(d)) {
+        rtc_deinit(d);
+        stdvga_deinit(d);
+        vioapic_deinit(d);
+    }
  fail1:
     hvm_destroy_cacheattr_region_list(d);
     return rc;
@@ -418,6 +430,10 @@ extern void msixtbl_pt_cleanup(struct do
 
 void hvm_domain_relinquish_resources(struct domain *d)
 {
+    if (is_hybrid_domain(d)) {
+        printk("MUK: WARN: Hybrid ignoring pit/pmtimer/hpet cleanup\n");
+        return;
+    }
     hvm_destroy_ioreq_page(d, &d->arch.hvm_domain.ioreq);
     hvm_destroy_ioreq_page(d, &d->arch.hvm_domain.buf_ioreq);
 
@@ -436,10 +452,14 @@ void hvm_domain_relinquish_resources(str
 void hvm_domain_destroy(struct domain *d)
 {
     hvm_funcs.domain_destroy(d);
+
+    if (is_hybrid_domain(d))
+        return;
+
+    hvm_destroy_cacheattr_region_list(d);
     rtc_deinit(d);
     stdvga_deinit(d);
     vioapic_deinit(d);
-    hvm_destroy_cacheattr_region_list(d);
 }
 
 static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
@@ -737,13 +757,25 @@ static int hvm_load_cpu_ctxt(struct doma
 HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt, hvm_load_cpu_ctxt,
                           1, HVMSR_PER_VCPU);
 
+static noinline int hybrid_vcpu_finish_init(struct vcpu *v)
+{
+    if ( v->vcpu_id == 0 )
+        hvm_set_guest_tsc(v, 0);
+
+    /* PV guests by default have a 100Hz ticker. */
+    v->periodic_period = MILLISECS(10);  /* ???? */
+
+    return 0;
+}
+
 int hvm_vcpu_initialise(struct vcpu *v)
 {
     int rc;
 
     hvm_asid_flush_vcpu(v);
 
-    if ( cpu_has_xsave )
+    /* HYBRID TBD: investigate xsave/xrestore for hybrid ??? */
+    if ( cpu_has_xsave && !is_hybrid_vcpu(v) )
     {
         /* XSAVE/XRSTOR requires the save area be 64-byte-boundary aligned. */
         void *xsave_area = _xmalloc(xsave_cntxt_size, 64);
@@ -755,12 +787,21 @@ int hvm_vcpu_initialise(struct vcpu *v)
         v->arch.hvm_vcpu.xfeature_mask = XSTATE_FP_SSE;
     }
 
-    if ( (rc = vlapic_init(v)) != 0 )
+    if ( !is_hybrid_vcpu(v) && ((rc = vlapic_init(v)) != 0) )
         goto fail1;
 
     if ( (rc = hvm_funcs.vcpu_initialise(v)) != 0 )
         goto fail2;
 
+    tasklet_init(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet,
+                 (void(*)(unsigned long))hvm_assert_evtchn_irq,
+                 (unsigned long)v);
+
+    v->arch.guest_context.user_regs.eflags = 2;
+
+    if (is_hybrid_vcpu(v))
+        return hybrid_vcpu_finish_init(v);
+
     /* Create ioreq event channel. */
     rc = alloc_unbound_xen_event_channel(v, 0);
     if ( rc < 0 )
@@ -780,12 +821,6 @@ int hvm_vcpu_initialise(struct vcpu *v)
     if ( rc != 0 )
         goto fail3;
 
-    tasklet_init(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet,
-                 (void(*)(unsigned long))hvm_assert_evtchn_irq,
-                 (unsigned long)v);
-
-    v->arch.guest_context.user_regs.eflags = 2;
-
     if ( v->vcpu_id == 0 )
     {
         /* NB. All these really belong in hvm_domain_initialise(). */
@@ -828,6 +863,8 @@ void hvm_vcpu_down(struct vcpu *v)
     struct domain *d = v->domain;
     int online_count = 0;
 
+printk("MUK: hvm_vcpu_down(): kdb trap\n");
+
     /* Doesn't halt us immediately, but we'll never return to guest context. */
     set_bit(_VPF_down, &v->pause_flags);
     vcpu_sleep_nosync(v);
@@ -2222,6 +2259,14 @@ static long hvm_vcpu_op(
     case VCPUOP_stop_singleshot_timer:
         rc = do_vcpu_op(cmd, vcpuid, arg);
         break;
+
+    case VCPUOP_is_up:
+    case VCPUOP_up:
+        if (is_hybrid_vcpu(current)) {
+            rc = do_vcpu_op(cmd, vcpuid, arg);
+            break;
+        }
+
     default:
         rc = -ENOSYS;
         break;
@@ -2292,11 +2337,17 @@ static long hvm_vcpu_op_compat32(
     return rc;
 }
 
-static hvm_hypercall_t *hvm_hypercall64_table[NR_hypercalls] = {
+hvm_hypercall_t *hvm_hypercall64_table[NR_hypercalls] = {
     [ __HYPERVISOR_memory_op ] = (hvm_hypercall_t *)hvm_memory_op,
     [ __HYPERVISOR_grant_table_op ] = (hvm_hypercall_t *)hvm_grant_table_op,
     [ __HYPERVISOR_vcpu_op ] = (hvm_hypercall_t *)hvm_vcpu_op,
+    HYPERCALL(set_debugreg),
+    HYPERCALL(multicall),
+    HYPERCALL(update_va_mapping),
     HYPERCALL(xen_version),
+    HYPERCALL(console_io),
+    HYPERCALL(vm_assist),
+    HYPERCALL(mmuext_op),
     HYPERCALL(event_channel_op),
     HYPERCALL(sched_op),
     HYPERCALL(set_timer_op),
@@ -2321,6 +2372,31 @@ static hvm_hypercall_t *hvm_hypercall32_
 
 #endif /* defined(__x86_64__) */
 
+/* Returns: 1 if hcall is valid, 0 otherwise. */
+static int hcall_valid(uint32_t eax)
+{
+#ifndef __x86_64__
+    if ( unlikely(eax >= NR_hypercalls) || !hvm_hypercall32_table[eax] )
+#else
+    if ( unlikely(eax >= NR_hypercalls) || !hvm_hypercall64_table[eax] ||
+        (!is_hybrid_vcpu(current) && 
+                   ( (eax==__HYPERVISOR_set_trap_table) ||
+                     (eax==__HYPERVISOR_set_debugreg) ||
+                     (eax==__HYPERVISOR_update_descriptor) ||
+                     (eax==__HYPERVISOR_multicall) ||
+                     (eax==__HYPERVISOR_update_va_mapping) ||
+                     (eax==__HYPERVISOR_console_io) ||
+                     (eax==__HYPERVISOR_set_segment_base) ||
+                     (eax==__HYPERVISOR_vm_assist) ||
+                     (eax==__HYPERVISOR_mmuext_op) ) )    ||
+        ((is_hybrid_vcpu(current) && hap_enabled(current->domain)) &&
+                     (eax==__HYPERVISOR_update_va_mapping)) )
+#endif
+        return 0;
+
+    return 1;
+}
+
 int hvm_do_hypercall(struct cpu_user_regs *regs)
 {
     struct vcpu *curr = current;
@@ -2349,8 +2425,7 @@ int hvm_do_hypercall(struct cpu_user_reg
     if ( (eax & 0x80000000) && is_viridian_domain(curr->domain) )
         return viridian_hypercall(regs);
 
-    if ( (eax >= NR_hypercalls) || !hvm_hypercall32_table[eax] )
-    {
+    if ( !hcall_valid(eax)) {
         regs->eax = -ENOSYS;
         return HVM_HCALL_completed;
     }
@@ -2734,12 +2809,46 @@ static int hvmop_flush_tlb_all(void)
     return 0;
 }
 
+static noinline long _do_hybrid_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
+{
+    long rc = -EINVAL;
+    struct xen_hvm_param a;
+    struct domain *d;
+
+    if (op == HVMOP_set_param) {
+        if ( copy_from_guest(&a, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(a.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if (a.index == HVM_PARAM_CALLBACK_IRQ) {
+            struct hvm_irq *hvm_irq = &d->arch.hvm_domain.irq;
+            uint64_t via = a.value;
+            uint8_t via_type = (uint8_t)(via >> 56) + 1;
+
+            if (via_type == HVMIRQ_callback_vector) {
+                hvm_irq->callback_via_type = HVMIRQ_callback_vector;
+                hvm_irq->callback_via.vector = (uint8_t)via;
+                rc = 0;
+            }
+        }
+    }
+    KASSERT(rc == 0);
+    return rc;
+}
+
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
 
 {
     struct domain *curr_d = current->domain;
     long rc = 0;
 
+    if (is_hybrid_domain(curr_d)) {
+        return (_do_hybrid_op(op, arg)); 
+    }
+
     switch ( op )
     {
     case HVMOP_set_param:
diff -r f2cf898c7ff8 xen/arch/x86/hvm/irq.c
--- a/xen/arch/x86/hvm/irq.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/irq.c	Thu Nov 17 15:37:30 2011 -0800
@@ -333,6 +333,9 @@ struct hvm_intack hvm_vcpu_has_pending_i
          && vcpu_info(v, evtchn_upcall_pending) )
         return hvm_intack_vector(plat->irq.callback_via.vector);
 
+    if (is_hybrid_vcpu(v))       /* Hybrid TBD: See NMI / MCE below */
+        return hvm_intack_none;
+
     if ( unlikely(v->nmi_pending) )
         return hvm_intack_nmi;
 
diff -r f2cf898c7ff8 xen/arch/x86/hvm/mtrr.c
--- a/xen/arch/x86/hvm/mtrr.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/mtrr.c	Thu Nov 17 15:37:30 2011 -0800
@@ -573,6 +573,7 @@ int32_t hvm_get_mem_pinned_cacheattr(
     uint32_t *type)
 {
     struct hvm_mem_pinned_cacheattr_range *range;
+    KASSERT(!is_hybrid_domain(d));
 
     *type = 0;
 
@@ -601,6 +602,8 @@ int32_t hvm_set_mem_pinned_cacheattr(
 {
     struct hvm_mem_pinned_cacheattr_range *range;
 
+    KASSERT(!is_hybrid_domain(d));
+
     if ( !((type == PAT_TYPE_UNCACHABLE) ||
            (type == PAT_TYPE_WRCOMB) ||
            (type == PAT_TYPE_WRTHROUGH) ||
diff -r f2cf898c7ff8 xen/arch/x86/hvm/svm/vmcb.c
--- a/xen/arch/x86/hvm/svm/vmcb.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/svm/vmcb.c	Thu Nov 17 15:37:30 2011 -0800
@@ -419,7 +419,7 @@ void kdb_dump_vmcb(domid_t did, int vid)
 
     rcu_read_lock(&domlist_read_lock);
     for_each_domain (dp) {
-        if (!is_hvm_domain(dp) || dp->is_dying)
+        if (!is_hvm_or_hyb_domain(dp) || dp->is_dying)
             continue;
         if (did != 0 && did != dp->domain_id)
             continue;
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vmx/Makefile
--- a/xen/arch/x86/hvm/vmx/Makefile	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/vmx/Makefile	Thu Nov 17 15:37:30 2011 -0800
@@ -5,3 +5,4 @@ obj-y += vmcs.o
 obj-y += vmx.o
 obj-y += vpmu.o
 obj-y += vpmu_core2.o
+obj-y += hybrid.o
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vmx/hybrid.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/arch/x86/hvm/vmx/hybrid.c	Thu Nov 17 15:37:30 2011 -0800
@@ -0,0 +1,576 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/trace.h>
+#include <xen/sched.h>
+#include <xen/irq.h>
+#include <xen/softirq.h>
+#include <xen/domain_page.h>
+#include <xen/hypercall.h>
+#include <xen/perfc.h>
+#include <asm/current.h>
+#include <asm/io.h>
+#include <asm/regs.h>
+#include <asm/cpufeature.h>
+#include <asm/processor.h>
+#include <asm/types.h>
+#include <asm/debugreg.h>
+#include <asm/msr.h>
+#include <asm/spinlock.h>
+#include <asm/paging.h>
+#include <asm/p2m.h>
+#include <asm/mem_sharing.h>
+#include <asm/hvm/emulate.h>
+#include <asm/hvm/hvm.h>
+#include <asm/hvm/support.h>
+#include <asm/hvm/vmx/vmx.h>
+#include <asm/hvm/vmx/vmcs.h>
+#include <public/sched.h>
+#include <public/hvm/ioreq.h>
+#include <asm/hvm/vpic.h>
+#include <asm/hvm/vlapic.h>
+#include <asm/x86_emulate.h>
+#include <asm/hvm/vpt.h>
+#include <public/hvm/save.h>
+#include <asm/hvm/trace.h>
+#include <asm/xenoprof.h>
+#include <asm/debugger.h>
+
+extern void vmx_do_extint(struct cpu_user_regs *regs);
+extern void vmx_do_cpuid(struct cpu_user_regs *regs);
+enum handler_return { HNDL_done, HNDL_unhandled, HNDL_exception_raised };
+extern enum handler_return long_mode_do_msr_read(struct cpu_user_regs *);
+extern enum handler_return long_mode_do_msr_write(struct cpu_user_regs *);
+
+
+volatile int mukprint=0, mukspin=1;
+#define dbgp0(...) dprintk(XENLOG_ERR, __VA_ARGS__);
+#define dbgp1(...) {(mukprint==1) ? kdbp(__VA_ARGS__):0;}
+#define dbgp2(...) {(mukprint==2) ? kdbp(__VA_ARGS__):0;}
+
+
+/* returns : 0 success */
+static noinline int vmxit_msr_read(struct cpu_user_regs *regs)
+{
+    uint inst_len = __get_instruction_length();
+    int rc=1;
+
+    u64 msr_content = 0;
+    switch (regs->ecx)
+    {
+        case MSR_IA32_MISC_ENABLE:
+        {
+            rdmsrl(MSR_IA32_MISC_ENABLE, msr_content);
+            msr_content |= MSR_IA32_MISC_ENABLE_BTS_UNAVAIL |
+                           MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL;
+            break;
+        }
+        default:
+        {
+            rdmsrl(regs->ecx, msr_content);
+            break;
+        }
+    }
+    regs->eax = (uint32_t)msr_content;
+    regs->edx = (uint32_t)(msr_content >> 32);
+    __update_guest_eip(inst_len);
+    rc = 0;
+
+#if 0
+    rc = (long_mode_do_msr_read(regs) == HNDL_done) ? 0 : 1;
+
+    if ( hvm_msr_read_intercept(regs) == X86EMUL_OKAY ) {
+        __update_guest_eip(inst_len);
+        rc = 0;
+    }
+#endif
+
+    dbgp1("msr read c:%lx a:%lx d:%lx RIP:%lx RSP:%lx\n", regs->ecx, regs->eax, 
+          regs->edx, vmr(GUEST_RIP), vmr(GUEST_RSP));
+    return rc;
+}
+
+/* for now just scratch the cpu since nothing else will run on it. eventually
+ * we need to save and restore these MSRs 
+ * returns : 0 success */
+static noinline int vmxit_msr_write(struct cpu_user_regs *regs)
+{
+    uint inst_len = __get_instruction_length();
+    int rc=1;
+#if 0
+    wrmsr(regs->ecx, regs->eax, regs->edx);
+
+    rc = (long_mode_do_msr_write(regs) == HNDL_done) ? 0 : 1;
+    return rc;
+#endif
+
+    dbgp1("MUK: msr write:0x%lx. eax:0x%lx edx:0x%lx\n", regs->ecx, 
+          regs->eax,regs->edx);
+    if ( hvm_msr_write_intercept(regs) == X86EMUL_OKAY ) {
+        __update_guest_eip(inst_len);
+        rc = 0;
+    }
+    return rc;
+}
+
+/* rc == 0: handled the MTF vmexit */
+static noinline int vmxit_mtf(struct cpu_user_regs *regs)
+{
+    struct vcpu *vp = current;
+    int rc=1, ss=vp->arch.hvm_vcpu.single_step; 
+
+    dbgp2("\n");
+    vp->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
+    __vmwrite(CPU_BASED_VM_EXEC_CONTROL, vp->arch.hvm_vmx.exec_control);
+    vp->arch.hvm_vcpu.single_step = 0;
+
+    /* kdb will set hvm_vcpu.single_step again if ss command */
+    if (kdb_handle_trap_entry(TRAP_debug, regs)) { /* TBD: ifdef KDB */
+        rc = 0;
+    } else if ( vp->domain->debugger_attached && ss ) {
+        domain_pause_for_debugger();
+        rc = 0;
+    }
+    return rc;
+}
+
+volatile int mukprintpf;
+/* rc == 0: handled the exception or NMI */
+static noinline int vmxit_exception(struct cpu_user_regs *regs)
+{
+    unsigned int vector = (__vmread(VM_EXIT_INTR_INFO)) & INTR_INFO_VECTOR_MASK;
+    int rc=1; 
+
+    dbgp2(" exception. vec:%d cs:%x\n", vector, vmr(GUEST_CS_SELECTOR));
+    if (vector == TRAP_debug) {
+        if (kdb_handle_trap_entry(vector, regs)) /* TBD: ifdef KDB */
+            rc = 0;
+        else {
+            domain_pause_for_debugger();
+            rc = 0;
+        }
+    } 
+    if (vector == TRAP_int3) {
+        int inst_len = __get_instruction_length();
+        __update_guest_eip(inst_len);
+
+        if (kdb_handle_trap_entry(vector, regs))
+            rc = 0;
+        else {
+            kdbp("[%d]MUK: domain pause for debugger\n", smp_processor_id());
+            current->arch.gdbsx_vcpu_event = TRAP_int3;
+            domain_pause_for_debugger();
+            rc = 0;
+        }
+    } 
+
+    if (vector == TRAP_no_device) {
+        vmx_fpu_dirty_intercept();
+        rc = 0;
+    }
+
+    if (vector == TRAP_gp_fault) {
+        regs->error_code = __vmread(VM_EXIT_INTR_ERROR_CODE);
+        kdbp("MUK: inject GP: errcode:0x%04x RIP:%016lx RSP:%016lx\n", 
+             regs->error_code, (ulong)vmr(GUEST_RIP), 
+             (ulong)vmr(GUEST_RSP));
+
+        kdb_trap_immed(KDB_TRAP_NONFATAL);
+        /* vmx_inject_hw_exception(TRAP_gp_fault, regs->error_code); */
+        rc = 1;
+    }
+
+    if (vector == TRAP_page_fault) {
+        extern int fixup_page_fault(unsigned long , struct cpu_user_regs *);
+        ulong eflags_sav = regs->eflags;
+        unsigned long va = __vmread(EXIT_QUALIFICATION);
+
+        regs->error_code = __vmread(VM_EXIT_INTR_ERROR_CODE);
+
+        if (mukprintpf)
+            kdbp("MUK:PF va:%016lx errcode:0x%04x RIP:%016lx RSP:%016lx", 
+                 va, regs->error_code, (ulong)vmr(GUEST_RIP), 
+                 (ulong)vmr(GUEST_RSP));
+
+        regs->eflags |= X86_EFLAGS_IF;
+        if (fixup_page_fault(va, regs) == 0) {
+            if (mukprintpf)
+                kdbp(" NOT ");
+            current->arch.hvm_vcpu.guest_cr[2] = va;
+            vmx_inject_hw_exception(TRAP_page_fault, regs->error_code);
+        }
+        regs->eflags = eflags_sav;
+        if (mukprintpf)
+            kdbp(" fixedup\n");
+        rc = 0;
+    }
+
+    /* TBD: call do_guest_trap() here */
+    if (rc)
+        kdbp("MUK: Unhandled trap vector:%d\n", vector);
+    return rc;
+}
+
+int vmxit_invlpg(void)
+{
+    int inst_len = __get_instruction_length();
+    ulong vaddr = __vmread(EXIT_QUALIFICATION);
+
+    KASSERT(hap_enabled(current->domain));
+    __update_guest_eip(inst_len);
+    vpid_sync_vcpu_gva(current, vaddr);
+    return 0;
+}
+
+/* rc == 0: success */
+static noinline int vmxit_vmcall(struct cpu_user_regs *regs)
+{
+    extern void *hvm_hypercall64_table[NR_hypercalls];
+    int rc, inst_len=__get_instruction_length();
+
+    if (regs->eax >= NR_hypercalls || hvm_hypercall64_table[regs->eax] ==NULL) {
+        kdbp("MUK: UnImplemented HCALL:%d\n", regs->eax);
+        return 1;
+    }
+    dbgp2("vmxit_vmcall: hcall eax:$%ld\n", regs->eax);
+    if (regs->eax == __HYPERVISOR_sched_op && regs->rdi == SCHEDOP_shutdown) {
+        kdbp("MUK: SCHEDOP_shutdown\n");
+        return 1;
+    }
+
+    rc = hvm_do_hypercall(regs);
+#if 0
+    extern int hybrid_do_hypercall(struct cpu_user_regs *regs);
+    rc = hybrid_do_hypercall(regs);
+#endif
+
+    if (rc != HVM_HCALL_preempted)
+        __update_guest_eip(inst_len);
+
+    if (rc != HVM_HCALL_completed) {
+        printk("hvm_do_hypercall rc:%d\n", rc);
+        rc = 1;
+    } else
+        rc = 0;
+
+    return rc;
+}
+
+static noinline uint64_t *get_gpr_ptr(struct cpu_user_regs *regs, uint gpr)
+{
+    switch (gpr)
+    {
+        case VMX_CONTROL_REG_ACCESS_GPR_EAX:
+            return &regs->eax;
+        case VMX_CONTROL_REG_ACCESS_GPR_ECX:
+            return &regs->ecx;
+        case VMX_CONTROL_REG_ACCESS_GPR_EDX:
+            return &regs->edx;
+        case VMX_CONTROL_REG_ACCESS_GPR_EBX:
+            return &regs->ebx;
+        case VMX_CONTROL_REG_ACCESS_GPR_ESP:
+            return &regs->esp;
+        case VMX_CONTROL_REG_ACCESS_GPR_EBP:
+            return &regs->ebp;
+        case VMX_CONTROL_REG_ACCESS_GPR_ESI:
+            return &regs->esi;
+        case VMX_CONTROL_REG_ACCESS_GPR_EDI:
+            return &regs->edi;
+        case VMX_CONTROL_REG_ACCESS_GPR_R8:
+            return &regs->r8;
+        case VMX_CONTROL_REG_ACCESS_GPR_R9:
+            return &regs->r9;
+        case VMX_CONTROL_REG_ACCESS_GPR_R10:
+            return &regs->r10;
+        case VMX_CONTROL_REG_ACCESS_GPR_R11:
+            return &regs->r11;
+        case VMX_CONTROL_REG_ACCESS_GPR_R12:
+            return &regs->r12;
+        case VMX_CONTROL_REG_ACCESS_GPR_R13:
+            return &regs->r13;
+        case VMX_CONTROL_REG_ACCESS_GPR_R14:
+            return &regs->r14;
+        case VMX_CONTROL_REG_ACCESS_GPR_R15:
+            return &regs->r15;
+        default:
+            return NULL;
+    }
+}
+/* rc == 0: success */
+static noinline int access_cr0(struct cpu_user_regs *regs, uint acc_typ, 
+                               uint64_t *regp)
+{
+    struct vcpu *vp = current;
+
+    if (acc_typ == VMX_CONTROL_REG_ACCESS_TYPE_MOV_TO_CR )
+    {
+        unsigned long new_cr0 = *regp;
+        unsigned long old_cr0 = __vmread(GUEST_CR0);
+
+        dbgp2("MUK:writing to CR0. RIP:%lx val:0x%lx\n", vmr(GUEST_RIP),*regp);
+        if ( (u32)new_cr0 != new_cr0 )
+        {
+            HVM_DBG_LOG(DBG_LEVEL_1, 
+                        "Guest setting upper 32 bits in CR0: %lx", new_cr0);
+            return 1;
+        }
+
+        new_cr0 &= ~HVM_CR0_GUEST_RESERVED_BITS;
+        /* ET is reserved and should be always be 1. */
+        new_cr0 |= X86_CR0_ET;
+
+        /* hybrid cannot change to real mode */
+        if ( (new_cr0 & (X86_CR0_PE|X86_CR0_PG)) != (X86_CR0_PG|X86_CR0_PE) ) {
+            kdbp("Guest attempting to turn off PE/PG. CR0:%lx\n", new_cr0);
+            return 1;
+        }
+        /* TS going from 1 to 0 */
+        if ( (old_cr0 & X86_CR0_TS) && ((new_cr0 & X86_CR0_TS)==0) )
+            vmx_fpu_enter(vp);
+
+        vp->arch.hvm_vcpu.hw_cr[0] = vp->arch.hvm_vcpu.guest_cr[0] = new_cr0;
+        __vmwrite(GUEST_CR0, new_cr0);
+        __vmwrite(CR0_READ_SHADOW, new_cr0);
+    } else {
+        *regp = __vmread(GUEST_CR0);
+    } 
+    return 0;
+}
+
+/* rc == 0: success */
+static noinline int access_cr4(struct cpu_user_regs *regs, uint acc_typ, 
+                               uint64_t *regp)
+{
+    if (acc_typ == VMX_CONTROL_REG_ACCESS_TYPE_MOV_TO_CR )
+    {
+        u64 old_cr4 = __vmread(GUEST_CR4);
+        /* kdbp("MUK:writing to CR4. val:0x%lx\n", *regp); */
+
+        if ( (old_cr4 ^ (*regp)) & (X86_CR4_PSE | X86_CR4_PGE | X86_CR4_PAE) )
+            vpid_sync_all();
+
+        /* hybrid_verify_cr4_wr(*regp)); */
+        __vmwrite(GUEST_CR4, *regp);
+    } else {
+        *regp = __vmread(GUEST_CR4);
+        kdbp("MUK: read cr4. val:0x%lx\n", *regp);
+    } 
+    return 0;
+}
+
+/* rc == 0: success */
+static noinline int vmxit_cr_access(struct cpu_user_regs *regs)
+{
+    unsigned long exit_qualification = __vmread(EXIT_QUALIFICATION);
+    uint inst_len = __get_instruction_length();
+    uint acc_typ = exit_qualification & VMX_CONTROL_REG_ACCESS_TYPE;
+    int cr, rc = 1;
+
+    switch ( acc_typ )
+    {
+        case VMX_CONTROL_REG_ACCESS_TYPE_MOV_TO_CR:
+        case VMX_CONTROL_REG_ACCESS_TYPE_MOV_FROM_CR:
+        {
+            uint gpr = exit_qualification & VMX_CONTROL_REG_ACCESS_GPR;
+            uint64_t *regp = get_gpr_ptr(regs, gpr);
+            cr = exit_qualification & VMX_CONTROL_REG_ACCESS_NUM;
+
+            if (regp == NULL)
+                break;
+
+            /* pl don't embed switch statements */
+            if (cr == 0)
+                rc = access_cr0(regs, acc_typ, regp);
+            else if (cr == 4) 
+                rc = access_cr4(regs, acc_typ, regp);
+
+            if (rc == 0)
+                __update_guest_eip(inst_len);
+            break;
+        }
+        case VMX_CONTROL_REG_ACCESS_TYPE_CLTS:
+        {
+#if 0
+            unsigned long cr0 = __vmread(GUEST_CR0);
+            cr0 &= ~X86_CR0_TS;
+#endif
+            struct vcpu *vp = current;
+            unsigned long cr0 = vp->arch.hvm_vcpu.guest_cr[0] & ~X86_CR0_TS;
+            vp->arch.hvm_vcpu.hw_cr[0] = vp->arch.hvm_vcpu.guest_cr[0] = cr0;
+            vmx_fpu_enter(vp);
+            __vmwrite(GUEST_CR0, cr0);
+            __vmwrite(CR0_READ_SHADOW, cr0);
+            __update_guest_eip(inst_len);
+            rc = 0;
+        }
+    }
+    return rc;
+}
+
+#if 0
+/* emulate write_cr3(read_cr3()) in guest. */
+static noinline int vmxit_invvpid(void)
+{
+    hvm_asid_flush_vcpu(current);
+    return 0;
+}
+#endif
+
+volatile int mukprtsc=1;
+void hybrid_vmx_vmexit_handler(struct cpu_user_regs *regs)
+{
+    unsigned int vector, exit_reason = __vmread(VM_EXIT_REASON);
+    int rc=0, ccpu = smp_processor_id();
+    struct vcpu *vp = current;
+
+    dbgp1("MUK:[%d]left VMCS exitreas:%d RIP:%lx RSP:%lx EFLAGS:%lx CR0:%lx\n", 
+          ccpu, exit_reason, vmr(GUEST_RIP), vmr(GUEST_RSP), regs->rflags, 
+          vmr(GUEST_CR0));
+
+    KASSERT( (vmr(GUEST_CR0)) != 0x8);
+    switch ( (uint16_t)exit_reason )
+    {
+        case EXIT_REASON_EXCEPTION_NMI:      /* 0 */
+            rc = vmxit_exception(regs);
+            break;
+            
+        case EXIT_REASON_EXTERNAL_INTERRUPT: /* 1 */
+        {
+            vector = __vmread(VM_EXIT_INTR_INFO);
+            vector &= INTR_INFO_VECTOR_MASK;
+            dbgp2("MUK: [%d] exit vmcs reas:%d vec:%d cr0:0x%016lx\n", ccpu, 
+                 exit_reason, vector, vmr(GUEST_CR0));
+            vmx_do_extint(regs);
+            break;
+        }
+
+        case EXIT_REASON_TRIPLE_FAULT:  /* 2 */
+        {
+#if 0
+            static int once;
+     if (!once)
+     kdbp("MUK:[%d]left VMCS exitreas:%d RIP:%lx RSP:%lx EFLAGS:%lx CR0:%lx\n",
+          ccpu, exit_reason, vmr(GUEST_RIP), vmr(GUEST_RSP), regs->rflags, 
+          vmr(GUEST_CR0));
+            once = 1;
+            vmx_inject_hw_exception(TRAP_gp_fault, regs->error_code);
+            rc = 0;
+#endif
+     kdbp("MUK:[%d]left VMCS exitreas:%d RIP:%lx RSP:%lx EFLAGS:%lx CR3:%lx\n",
+          ccpu, exit_reason, vmr(GUEST_RIP), vmr(GUEST_RSP), regs->rflags, 
+          vmr(GUEST_CR3));
+
+            __vmwrite(GUEST_CR3, 0x1803000);
+    if ( paging_mode_hap(vp->domain) && hvm_paging_enabled(vp) )
+        vp->arch.hvm_vcpu.guest_cr[3] = vp->arch.hvm_vcpu.hw_cr[3] =
+                                                           __vmread(GUEST_CR3);
+            kdb_trap_immed(KDB_TRAP_NONFATAL);
+            rc = 1;
+            break;
+        }
+        case EXIT_REASON_PENDING_VIRT_INTR:  /* 7 */
+        {
+            struct vcpu *v = current;
+            /* Disable the interrupt window. */
+            v->arch.hvm_vmx.exec_control &= ~CPU_BASED_VIRTUAL_INTR_PENDING;
+            __vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vmx.exec_control);
+            break;
+        }
+
+        case EXIT_REASON_CPUID:              /* 10 */
+        {
+            int ilen=__get_instruction_length();
+            __update_guest_eip(ilen);
+            dbgp2("cpuid:%d RIP:%lx\n", regs->eax, vmr(GUEST_RIP));
+            vmx_do_cpuid(regs);
+            break;
+        }
+
+#if 0
+        case EXIT_REASON_INVLPG:             /* 14 */
+            rc = vmxit_invlpg();
+            break;
+#endif
+        case EXIT_REASON_RDTSC:              /* 16 */
+        {
+#if 0
+            uint64_t tsc;
+            int ilen=__get_instruction_length();
+            rdtscll(tsc);
+            regs->eax = (uint32_t)tsc;
+            regs->edx = (uint32_t)(tsc >> 32);
+#endif
+            rdtsc(regs->eax, regs->edx);
+if (mukprtsc)
+    kdbp(" RDTSC: eax:%lx edx:%lx\n", regs->eax, regs->edx);
+            __update_guest_eip(__get_instruction_length());
+            rc = 0;
+            break;
+        }
+
+        case EXIT_REASON_VMCALL:             /* 18 */
+            rc = vmxit_vmcall(regs);
+            break;
+
+        case EXIT_REASON_CR_ACCESS:          /* 28 */
+            rc = vmxit_cr_access(regs);
+            break;
+
+        case EXIT_REASON_DR_ACCESS:          /* 29 */
+        {
+            unsigned long exit_qualification = __vmread(EXIT_QUALIFICATION);
+            vmx_dr_access(exit_qualification, regs);
+            break;
+        }
+        case EXIT_REASON_MSR_READ:           /* 31 */
+            rc = vmxit_msr_read(regs);
+            break;
+
+        case EXIT_REASON_MSR_WRITE:          /* 32 */
+            rc = vmxit_msr_write(regs);
+            break;
+
+        case EXIT_REASON_MONITOR_TRAP_FLAG:  /* 37 */
+            rc = vmxit_mtf(regs);
+            break;
+#if 0
+        case EXIT_REASON_INVVPID:            /* 53 */
+            rc = vmxit_invvpid();
+            break;
+#endif
+        default: 
+            rc = 1;
+    }
+    if (rc) {
+        unsigned long exit_qualification = __vmread(EXIT_QUALIFICATION);
+        local_irq_enable();
+        kdbp("MUK: [%d] exit_reas:%d 0x%lx qual:%ld 0x%lx cr0:0x%016lx\n", 
+             ccpu, exit_reason, exit_reason, exit_qualification,
+             exit_qualification, vmr(GUEST_CR0));
+        kdbp("MUK: [%d] RIP:%lx RSP:%lx\n", ccpu, 
+             vmr(GUEST_RIP), vmr(GUEST_RSP));
+        domain_crash_synchronous();
+    }
+
+    /*dbgp("MUK: will enter vmcs: cs:%x ss:%x\n", vmr(GUEST_CS_SELECTOR),
+         vmr(GUEST_SS_SELECTOR)); */
+
+    dbgp1("MUK: will enter vmcs:RIP:%lx RSP:%lx cr0:%lx eflags:%lx\n", 
+          vmr(GUEST_RIP), vmr(GUEST_RSP), vmr(GUEST_CR0), regs->rflags);
+
+    local_irq_enable();
+    KASSERT( (vmr(GUEST_CR0)) != 0x8);
+}
+
+void hybrid_flush_tlb(void)
+{
+    vpid_sync_all();
+}
+
+void hybrid_do_invlpg(ulong addr)
+{
+    /* vpid_sync_all(); */
+    vpid_sync_vcpu_gva(current, addr);
+}
+
+
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/vmx/intr.c	Thu Nov 17 15:37:30 2011 -0800
@@ -125,8 +125,9 @@ asmlinkage void vmx_intr_assist(void)
         return;
     }
 
-    /* Crank the handle on interrupt state. */
-    pt_update_irq(v);
+    if (!is_hybrid_vcpu(v))
+        /* Crank the handle on interrupt state. */
+        pt_update_irq(v);
 
     do {
         intack = hvm_vcpu_has_pending_irq(v);
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Thu Nov 17 15:37:30 2011 -0800
@@ -593,6 +593,311 @@ void vmx_disable_intercept_for_msr(struc
     }
 }
 
+
+void hybrid_update_cr3(struct vcpu *v)
+{
+    vmx_vmcs_enter(v);
+    __vmwrite(GUEST_CR3, v->arch.cr3);
+    __vmwrite(HOST_CR3, v->arch.cr3);
+
+    vpid_sync_all();
+    /* hvm_asid_flush_vcpu(v); */
+    vmx_vmcs_exit(v);
+}
+
+static int hybrid_construct_vmcs(struct vcpu *v)
+{
+    struct domain *d = v->domain;
+    uint16_t sysenter_cs;
+    unsigned long sysenter_eip;
+    u32 vmexit_ctl = vmx_vmexit_control;
+    u32 vmentry_ctl = vmx_vmentry_control;
+    u64 u64val;
+
+    vmx_vmcs_enter(v);
+
+    /* VMCS controls. */
+    vmx_pin_based_exec_control &= ~PIN_BASED_VIRTUAL_NMIS;
+    __vmwrite(PIN_BASED_VM_EXEC_CONTROL, vmx_pin_based_exec_control);
+
+    v->arch.hvm_vmx.exec_control = vmx_cpu_based_exec_control;
+
+    if ( v->domain->arch.vtsc )
+        v->arch.hvm_vmx.exec_control &= ~CPU_BASED_RDTSC_EXITING;
+
+    if ( paging_mode_hap(d) )
+    {
+        v->arch.hvm_vmx.exec_control &= ~(CPU_BASED_INVLPG_EXITING |
+                                          CPU_BASED_CR3_LOAD_EXITING |
+                                          CPU_BASED_CR3_STORE_EXITING);
+    }
+    v->arch.hvm_vmx.exec_control |= CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
+    v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
+    v->arch.hvm_vmx.exec_control &= ~CPU_BASED_ACTIVATE_IO_BITMAP; /* ??? */
+    v->arch.hvm_vmx.exec_control |= CPU_BASED_ACTIVATE_MSR_BITMAP;
+    v->arch.hvm_vmx.exec_control &= ~CPU_BASED_TPR_SHADOW;
+    v->arch.hvm_vmx.exec_control &= ~CPU_BASED_VIRTUAL_NMI_PENDING;
+
+    kdbp("MUK: writing proc based exec controls:%x\n", 
+                 v->arch.hvm_vmx.exec_control);
+    __vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vmx.exec_control);
+
+    /* MSR access bitmap. */
+    if ( cpu_has_vmx_msr_bitmap )
+    {
+        unsigned long *msr_bitmap = alloc_xenheap_page();
+
+        if ( msr_bitmap == NULL )
+            return -ENOMEM;
+
+        memset(msr_bitmap, ~0, PAGE_SIZE);
+        v->arch.hvm_vmx.msr_bitmap = msr_bitmap;
+        __vmwrite(MSR_BITMAP, virt_to_maddr(msr_bitmap));
+
+        vmx_disable_intercept_for_msr(v, MSR_FS_BASE);
+        vmx_disable_intercept_for_msr(v, MSR_GS_BASE);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP);
+
+        /* pure hvm doesn't do this. safe? see: long_mode_do_msr_write() */
+#if 0
+        vmx_disable_intercept_for_msr(v, MSR_STAR);
+        vmx_disable_intercept_for_msr(v, MSR_LSTAR);
+        vmx_disable_intercept_for_msr(v, MSR_CSTAR);
+        vmx_disable_intercept_for_msr(v, MSR_SYSCALL_MASK);
+#endif
+        vmx_disable_intercept_for_msr(v, MSR_SHADOW_GS_BASE);
+
+        kdbp("MUK: disabled intercepts for few msrs\n");
+
+    } else {
+        kdbp("MUK: CPU does NOT have msr bitmap\n");
+        for (;;) cpu_relax();
+    }
+
+    if ( !cpu_has_vmx_vpid ) {
+        printk("ERROR: VPID support is required to run PV in HVM container\n");
+        return -ESRCH;
+    }
+
+    v->arch.hvm_vmx.secondary_exec_control = vmx_secondary_exec_control;
+
+    if ( cpu_has_vmx_secondary_exec_control ) {
+        v->arch.hvm_vmx.secondary_exec_control &= ~0x4FF; /* turn off all */
+#if 0
+        v->arch.hvm_vmx.secondary_exec_control &= 
+                                       ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
+        v->arch.hvm_vmx.secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_RDTSCP;
+
+        v->arch.hvm_vmx.secondary_exec_control &= 
+                                             ~SECONDARY_EXEC_UNRESTRICTED_GUEST;
+#endif
+        v->arch.hvm_vmx.secondary_exec_control |= 
+                                              SECONDARY_EXEC_PAUSE_LOOP_EXITING;
+        v->arch.hvm_vmx.secondary_exec_control |= SECONDARY_EXEC_ENABLE_VPID;
+
+        if ( paging_mode_hap(d) )
+            v->arch.hvm_vmx.secondary_exec_control |= SECONDARY_EXEC_ENABLE_EPT;
+
+        kdbp("MUK: muk_construct_vmcs: sec exec:0x%x\n",
+                                        v->arch.hvm_vmx.secondary_exec_control);
+        __vmwrite(SECONDARY_VM_EXEC_CONTROL,
+                  v->arch.hvm_vmx.secondary_exec_control);
+    } else {
+        printk("ERROR: NO Secondary Exec control\n");
+        return -ESRCH;
+    }
+
+    __vmwrite(VIRTUAL_PROCESSOR_ID, v->arch.hvm_vcpu.asid);
+
+    if ( !paging_mode_hap(d) )
+        vmexit_ctl &= ~(VM_EXIT_SAVE_GUEST_PAT | VM_EXIT_LOAD_HOST_PAT);
+    __vmwrite(VM_EXIT_CONTROLS, vmexit_ctl);
+
+    #define VM_ENTRY_LOAD_DEBUG_CTLS 0x4
+    #define VM_ENTRY_LOAD_EFER 0x8000
+    #define GUEST_EFER 0x2806        /* see page 23-20 */
+    #define GUEST_EFER_HIGH 0x2807   /* see page 23-20 */
+    vmentry_ctl &= ~VM_ENTRY_LOAD_DEBUG_CTLS;
+    vmentry_ctl &= ~VM_ENTRY_LOAD_EFER;
+    vmentry_ctl &= ~VM_ENTRY_SMM;
+    vmentry_ctl &= ~VM_ENTRY_DEACT_DUAL_MONITOR;
+    vmentry_ctl |= VM_ENTRY_IA32E_MODE;
+    if ( !paging_mode_hap(d) )
+        vmentry_ctl &= ~VM_ENTRY_LOAD_GUEST_PAT;
+    kdbp("MUK:muk_construct_vmcs(). vmentry_ctl:0x%x\n", vmentry_ctl);
+    __vmwrite(VM_ENTRY_CONTROLS, vmentry_ctl);
+
+    /* MSR intercepts. */
+    __vmwrite(VM_ENTRY_MSR_LOAD_COUNT, 0);
+    __vmwrite(VM_EXIT_MSR_LOAD_COUNT, 0);
+    __vmwrite(VM_EXIT_MSR_STORE_COUNT, 0);
+
+    /* Host data selectors. */
+    __vmwrite(HOST_SS_SELECTOR, __HYPERVISOR_DS);
+    __vmwrite(HOST_DS_SELECTOR, __HYPERVISOR_DS);
+    __vmwrite(HOST_ES_SELECTOR, __HYPERVISOR_DS);
+    __vmwrite(HOST_FS_SELECTOR, 0);
+    __vmwrite(HOST_GS_SELECTOR, 0);
+    __vmwrite(HOST_FS_BASE, 0);
+    __vmwrite(HOST_GS_BASE, 0);
+
+    vmx_set_host_env(v);
+
+    /* Host control registers. */
+    v->arch.hvm_vmx.host_cr0 = read_cr0() | X86_CR0_TS;
+    __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0);
+    __vmwrite(HOST_CR4, mmu_cr4_features|(cpu_has_xsave ? X86_CR4_OSXSAVE : 0));
+
+    /* Host CS:RIP. */
+    __vmwrite(HOST_CS_SELECTOR, __HYPERVISOR_CS);
+    __vmwrite(HOST_RIP, (unsigned long)vmx_asm_vmexit_handler);
+
+    /* Host SYSENTER CS:RIP. */
+    rdmsrl(MSR_IA32_SYSENTER_CS, sysenter_cs);
+    __vmwrite(HOST_SYSENTER_CS, sysenter_cs);
+    rdmsrl(MSR_IA32_SYSENTER_EIP, sysenter_eip);
+    __vmwrite(HOST_SYSENTER_EIP, sysenter_eip);
+
+    __vmwrite(VM_ENTRY_INTR_INFO, 0);
+
+    __vmwrite(CR3_TARGET_COUNT, 0);
+
+    __vmwrite(GUEST_ACTIVITY_STATE, 0);
+
+    __vmwrite(GUEST_CS_BASE, 0);
+    __vmwrite(GUEST_CS_LIMIT, ~0u);
+    __vmwrite(GUEST_CS_AR_BYTES, 0xa09b); /* CS.L == 1 */
+    __vmwrite(GUEST_CS_SELECTOR, 0x10);
+
+    __vmwrite(GUEST_DS_BASE, 0);
+    __vmwrite(GUEST_DS_LIMIT, ~0u);
+    __vmwrite(GUEST_DS_AR_BYTES, 0xc093);
+    __vmwrite(GUEST_DS_SELECTOR, 0x18);
+
+    __vmwrite(GUEST_SS_BASE, 0);         /* use same seg as DS */
+    __vmwrite(GUEST_SS_LIMIT, ~0u);
+    __vmwrite(GUEST_SS_AR_BYTES, 0xc093);
+    __vmwrite(GUEST_SS_SELECTOR, 0x18);
+
+    __vmwrite(GUEST_ES_SELECTOR, 0);
+    __vmwrite(GUEST_FS_SELECTOR, 0);
+    __vmwrite(GUEST_GS_SELECTOR, 0);
+
+    /* Guest segment bases. */
+    __vmwrite(GUEST_ES_BASE, 0);
+    __vmwrite(GUEST_FS_BASE, 0);
+    __vmwrite(GUEST_GS_BASE, 0);
+
+    /* Guest segment limits. */
+    __vmwrite(GUEST_ES_LIMIT, ~0u);
+    __vmwrite(GUEST_FS_LIMIT, ~0u);
+    __vmwrite(GUEST_GS_LIMIT, ~0u);
+
+    /* Guest segment AR bytes. */
+    __vmwrite(GUEST_ES_AR_BYTES, 0xc093); /* read/write, accessed */
+    __vmwrite(GUEST_FS_AR_BYTES, 0xc093);
+    __vmwrite(GUEST_GS_AR_BYTES, 0xc093);
+
+    /* Guest IDT. */
+    __vmwrite(GUEST_GDTR_BASE, 0);
+    __vmwrite(GUEST_GDTR_LIMIT, 0);
+
+    /* Guest LDT. */
+    __vmwrite(GUEST_LDTR_AR_BYTES, 0x82); /* LDT */
+    __vmwrite(GUEST_LDTR_SELECTOR, 0);
+    __vmwrite(GUEST_LDTR_BASE, 0);
+    __vmwrite(GUEST_LDTR_LIMIT, 0);
+
+    /* Guest TSS. */
+    __vmwrite(GUEST_TR_AR_BYTES, 0x8b); /* 32-bit TSS (busy) */
+    __vmwrite(GUEST_TR_BASE, 0);
+    __vmwrite(GUEST_TR_LIMIT, 0xff);
+
+    __vmwrite(GUEST_INTERRUPTIBILITY_INFO, 0);
+    __vmwrite(GUEST_DR7, 0);
+    __vmwrite(VMCS_LINK_POINTER, ~0UL);
+
+    if (paging_mode_hap(d)) {
+        __vmwrite(PAGE_FAULT_ERROR_CODE_MASK, 0);
+        __vmwrite(PAGE_FAULT_ERROR_CODE_MATCH, 0);
+        __vmwrite(EXCEPTION_BITMAP,
+                  HVM_TRAP_MASK | TRAP_debug | 
+                  (1U<<TRAP_int3) | (1U << TRAP_no_device));
+    } else {
+        /* vmexit only on write to protected page, err code: 0x3 */
+        __vmwrite(PAGE_FAULT_ERROR_CODE_MASK, 0xffffffff);
+        __vmwrite(PAGE_FAULT_ERROR_CODE_MATCH, 0x3);
+        __vmwrite(EXCEPTION_BITMAP, 0xffffffff);
+    }
+
+#if 0
+    __vmwrite(EXCEPTION_BITMAP,
+              HVM_TRAP_MASK | TRAP_debug | TRAP_gp_fault |
+              (1U<<TRAP_int3) | (1U << TRAP_page_fault)|(1U << TRAP_no_device));
+#endif
+    __vmwrite(TSC_OFFSET, 0);
+
+#if 0
+    v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_PG | X86_CR0_PE | X86_CR0_ET;
+    hvm_update_guest_cr(v, 0);
+
+    v->arch.hvm_vcpu.guest_cr[4] = 0;
+    hvm_update_guest_cr(v, 4);
+#endif
+
+#if 0
+    u64val = X86_CR0_PG | X86_CR0_PE | X86_CR0_ET | X86_CR0_TS |
+             X86_CR0_NE | X86_CR0_WP;
+#endif
+    /* make sure to set WP bit so rdonly pages are not written from CPL 0 */
+    u64val = X86_CR0_PG | X86_CR0_NE | X86_CR0_PE | X86_CR0_WP;
+    __vmwrite(GUEST_CR0, u64val);
+    __vmwrite(CR0_READ_SHADOW, u64val);
+    v->arch.hvm_vcpu.hw_cr[0] = v->arch.hvm_vcpu.guest_cr[0] = u64val;
+
+    u64val = X86_CR4_PAE | X86_CR4_VMXE;
+    __vmwrite(GUEST_CR4, u64val);
+    __vmwrite(CR4_READ_SHADOW, u64val);
+    v->arch.hvm_vcpu.guest_cr[4] = u64val;
+
+    __vmwrite(CR0_GUEST_HOST_MASK, ~0UL);
+    __vmwrite(CR4_GUEST_HOST_MASK, ~0UL);
+
+     v->arch.hvm_vmx.vmx_realmode = 0;
+
+    if ( paging_mode_hap(d) )
+    {
+        __vmwrite(EPT_POINTER, d->arch.hvm_domain.vmx.ept_control.eptp);
+#ifdef __i386__
+        __vmwrite(EPT_POINTER_HIGH,
+                  d->arch.hvm_domain.vmx.ept_control.eptp >> 32);
+#endif
+    }
+
+    if ( cpu_has_vmx_pat && paging_mode_hap(d) )
+    {
+        u64 host_pat, guest_pat;
+
+        rdmsrl(MSR_IA32_CR_PAT, host_pat);
+        guest_pat = MSR_IA32_CR_PAT_RESET;
+
+        __vmwrite(HOST_PAT, host_pat);
+        __vmwrite(GUEST_PAT, guest_pat);
+#ifdef __i386__
+JUNK
+        __vmwrite(HOST_PAT_HIGH, host_pat >> 32);
+        __vmwrite(GUEST_PAT_HIGH, guest_pat >> 32);
+#endif
+    }
+    vmx_vmcs_exit(v);
+#if 0
+    paging_update_paging_modes(v); /* will update HOST & GUEST_CR3 as reqd */
+#endif
+    return 0;
+}
+
 static int construct_vmcs(struct vcpu *v)
 {
     struct domain *d = v->domain;
@@ -601,6 +906,9 @@ static int construct_vmcs(struct vcpu *v
     u32 vmexit_ctl = vmx_vmexit_control;
     u32 vmentry_ctl = vmx_vmentry_control;
 
+    if (is_hybrid_domain(d))
+        return hybrid_construct_vmcs(v);
+
     vmx_vmcs_enter(v);
 
     /* VMCS controls. */
@@ -1001,8 +1309,10 @@ void vmx_do_resume(struct vcpu *v)
 
         vmx_clear_vmcs(v);
         vmx_load_vmcs(v);
-        hvm_migrate_timers(v);
-        hvm_migrate_pirqs(v);
+        if (!is_hybrid_vcpu(v)) {
+            hvm_migrate_timers(v);
+            hvm_migrate_pirqs(v);
+        }
         vmx_set_host_env(v);
         hvm_asid_flush_vcpu(v);
     }
@@ -1018,14 +1328,6 @@ void vmx_do_resume(struct vcpu *v)
     reset_stack_and_jump(vmx_asm_do_vmentry);
 }
 
-static unsigned long vmr(unsigned long field)
-{
-    int rc;
-    unsigned long val;
-    val = __vmread_safe(field, &rc);
-    return rc ? 0 : val;
-}
-
 static void vmx_dump_sel(char *name, uint32_t selector)
 {
     uint32_t sel, attr, limit;
@@ -1263,6 +1565,8 @@ static void noinline kdb_print_vmcs(stru
     vmx_dump_sel("LDTR", GUEST_LDTR_SELECTOR);
     vmx_dump_sel2("IDTR", GUEST_IDTR_LIMIT);
     vmx_dump_sel("TR", GUEST_TR_SELECTOR);
+    kdbp("Guest EFER = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_EFER_HIGH), (uint32_t)vmr(GUEST_EFER));
     kdbp("Guest PAT = 0x%08x%08x\n",
            (uint32_t)vmr(GUEST_PAT_HIGH), (uint32_t)vmr(GUEST_PAT));
     x  = (unsigned long long)vmr(TSC_OFFSET_HIGH) << 32;
@@ -1276,6 +1580,10 @@ static void noinline kdb_print_vmcs(stru
            (int)vmr(GUEST_INTERRUPTIBILITY_INFO),
            (int)vmr(GUEST_ACTIVITY_STATE));
 
+    kdbp("MSRs: entry_load:$%d exit_load:$%d exit_store:$%d\n",
+         vmr(VM_ENTRY_MSR_LOAD_COUNT), vmr(VM_EXIT_MSR_LOAD_COUNT),
+         vmr(VM_EXIT_MSR_STORE_COUNT));
+
     kdbp("\n*** Host State ***\n");
     kdbp("RSP = 0x%016llx  RIP = 0x%016llx\n", 
            (unsigned long long)vmr(HOST_RSP),
@@ -1316,6 +1624,9 @@ static void noinline kdb_print_vmcs(stru
            (uint32_t)vmr(VM_EXIT_CONTROLS));
     kdbp("ExceptionBitmap=%08x\n",
            (uint32_t)vmr(EXCEPTION_BITMAP));
+    kdbp("PAGE_FAULT_ERROR_CODE  MASK:0x%lx  MATCH:0x%lx\n", 
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MASK),
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MATCH));
     kdbp("VMEntry: intr_info=%08x errcode=%08x ilen=%08x\n",
            (uint32_t)vmr(VM_ENTRY_INTR_INFO),
            (uint32_t)vmr(VM_ENTRY_EXCEPTION_ERROR_CODE),
@@ -1344,8 +1655,7 @@ static void noinline kdb_print_vmcs(stru
  *     do __vmreads. So, the VMCS pointer can't be left cleared.
  *   - Doing __vmpclear will set the vmx state to 'clear', so to resume a
  *     vmlaunch must be done and not vmresume. This means, we must clear 
- *     arch_vmx->launched. Just call __vmx_clear_vmcs(), hopefully it won't keep
- *     changing...
+ *     arch_vmx->launched.
  */
 void kdb_curr_cpu_flush_vmcs(void)
 {
@@ -1358,12 +1668,14 @@ void kdb_curr_cpu_flush_vmcs(void)
     /* looks like we got one. unfortunately, current_vmcs points to vmcs 
      * and not VCPU, so we gotta search the entire list... */
     for_each_domain (dp) {
-        if ( !is_hvm_domain(dp) || dp->is_dying)
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
             continue;
         for_each_vcpu (dp, vp) {
             if (vp->arch.hvm_vmx.active_cpu == smp_processor_id()) {
-                __vmx_clear_vmcs(vp);
+                __vmpclear(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
                 __vmptrld(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                vp->arch.hvm_vmx.launched   = 0;
+                kdbp("KDB:[%d] vmcs flushed\n", smp_processor_id());
             }
         }
     }
@@ -1382,7 +1694,7 @@ void kdb_dump_vmcs(domid_t did, int vid)
     ASSERT(!local_irq_is_enabled());     /* kdb should always run disabled */
 
     for_each_domain (dp) {
-        if ( !is_hvm_domain(dp) || dp->is_dying)
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
             continue;
         if (did != 0 && did != dp->domain_id)
             continue;
@@ -1400,7 +1712,7 @@ void kdb_dump_vmcs(domid_t did, int vid)
         kdbp("\n");
     }
     /* restore orig vmcs pointer for __vmreads in vmx_vmexit_handler() */
-    if (is_hvm_vcpu(current))
+    if (is_hvm_or_hyb_vcpu(current)) 
         __vmptrld(virt_to_maddr(current->arch.hvm_vmx.vmcs));
 }
 #endif
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Nov 17 15:37:30 2011 -0800
@@ -68,7 +68,6 @@ static void vmx_cpuid_intercept(
     unsigned int *eax, unsigned int *ebx,
     unsigned int *ecx, unsigned int *edx);
 static void vmx_wbinvd_intercept(void);
-static void vmx_fpu_dirty_intercept(void);
 static int vmx_msr_read_intercept(struct cpu_user_regs *regs);
 static int vmx_msr_write_intercept(struct cpu_user_regs *regs);
 static void vmx_invlpg_intercept(unsigned long vaddr);
@@ -87,6 +86,8 @@ static int vmx_domain_initialise(struct 
     d->arch.hvm_domain.vmx.ept_control.asr  =
         pagetable_get_pfn(d->arch.phys_table);
 
+    if (is_hybrid_domain(d))
+        return 0;
 
     if ( (rc = vmx_alloc_vlapic_mapping(d)) != 0 )
         return rc;
@@ -98,6 +99,10 @@ static void vmx_domain_destroy(struct do
 {
     if ( d->arch.hvm_domain.hap_enabled )
         on_each_cpu(__ept_sync_domain, d, 1);
+
+    if (is_hybrid_domain(d))
+        return;
+
     vmx_free_vlapic_mapping(d);
 }
 
@@ -119,13 +124,19 @@ static int vmx_vcpu_initialise(struct vc
         return rc;
     }
 
-    vpmu_initialise(v);
-
-    vmx_install_vlapic_mapping(v);
-
-    /* %eax == 1 signals full real-mode support to the guest loader. */
-    if ( v->vcpu_id == 0 )
-        v->arch.guest_context.user_regs.eax = 1;
+    /* Hybrid TBD: pmu */
+    if ( !is_hybrid_vcpu(v)) {
+        vpmu_initialise(v);
+
+        vmx_install_vlapic_mapping(v);
+
+        /* %eax == 1 signals full real-mode support to the guest loader. */
+        if ( v->vcpu_id == 0 )
+            v->arch.guest_context.user_regs.eax = 1;
+    } else {
+        /* for hvm_long_mode_enabled(v) */
+        v->arch.hvm_vcpu.guest_efer = EFER_SCE | EFER_LMA | EFER_LME;
+    }
 
     return 0;
 }
@@ -398,6 +409,9 @@ static int vmx_guest_x86_mode(struct vcp
 {
     unsigned int cs_ar_bytes;
 
+if (is_hybrid_vcpu(v))
+    return 8;
+
     if ( unlikely(!(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE)) )
         return 0;
     if ( unlikely(guest_cpu_user_regs()->eflags & X86_EFLAGS_VM) )
@@ -628,7 +642,7 @@ static int vmx_load_vmcs_ctxt(struct vcp
     return 0;
 }
 
-static void vmx_fpu_enter(struct vcpu *v)
+void vmx_fpu_enter(struct vcpu *v)
 {
     setup_fpu(v);
     __vm_clear_bit(EXCEPTION_BITMAP, TRAP_no_device);
@@ -657,6 +671,7 @@ static void vmx_fpu_leave(struct vcpu *v
     {
         v->arch.hvm_vcpu.hw_cr[0] |= X86_CR0_TS;
         __vmwrite(GUEST_CR0, v->arch.hvm_vcpu.hw_cr[0]);
+KASSERT( (vmr(GUEST_CR0)) != 0x8);
         __vm_set_bit(EXCEPTION_BITMAP, TRAP_no_device);
     }
 }
@@ -1155,6 +1170,7 @@ static void vmx_update_guest_cr(struct v
         v->arch.hvm_vcpu.hw_cr[0] =
             v->arch.hvm_vcpu.guest_cr[0] | hw_cr0_mask;
         __vmwrite(GUEST_CR0, v->arch.hvm_vcpu.hw_cr[0]);
+KASSERT( (vmr(GUEST_CR0)) != 0x8);
         __vmwrite(CR0_READ_SHADOW, v->arch.hvm_vcpu.guest_cr[0]);
         break;
     }
@@ -1299,6 +1315,7 @@ void vmx_inject_hw_exception(int trap, i
     if ( unlikely(intr_info & INTR_INFO_VALID_MASK) &&
          (((intr_info >> 8) & 7) == X86_EVENTTYPE_HW_EXCEPTION) )
     {
+        KASSERT(!is_hybrid_vcpu(curr));
         trap = hvm_combine_hw_exceptions((uint8_t)intr_info, trap);
         if ( trap == TRAP_double_fault )
             error_code = 0;
@@ -1459,38 +1476,7 @@ void start_vmx(void)
     hvm_enable(&vmx_function_table);
 }
 
-/*
- * Not all cases receive valid value in the VM-exit instruction length field.
- * Callers must know what they're doing!
- */
-static int __get_instruction_length(void)
-{
-    int len;
-    len = __vmread(VM_EXIT_INSTRUCTION_LEN); /* Safe: callers audited */
-    BUG_ON((len < 1) || (len > 15));
-    return len;
-}
-
-static void __update_guest_eip(unsigned long inst_len)
-{
-    struct cpu_user_regs *regs = guest_cpu_user_regs();
-    unsigned long x;
-
-    regs->eip += inst_len;
-    regs->eflags &= ~X86_EFLAGS_RF;
-
-    x = __vmread(GUEST_INTERRUPTIBILITY_INFO);
-    if ( x & (VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS) )
-    {
-        x &= ~(VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS);
-        __vmwrite(GUEST_INTERRUPTIBILITY_INFO, x);
-    }
-
-    if ( regs->eflags & X86_EFLAGS_TF )
-        vmx_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
-}
-
-static void vmx_fpu_dirty_intercept(void)
+void vmx_fpu_dirty_intercept(void)
 {
     struct vcpu *curr = current;
 
@@ -1500,6 +1486,7 @@ static void vmx_fpu_dirty_intercept(void
     if ( !(curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_TS) )
     {
         curr->arch.hvm_vcpu.hw_cr[0] &= ~X86_CR0_TS;
+KASSERT( (vmr(GUEST_CR0)) != 0x8);
         __vmwrite(GUEST_CR0, curr->arch.hvm_vcpu.hw_cr[0]);
     }
 }
@@ -1531,7 +1518,7 @@ static void vmx_cpuid_intercept(
     HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
 }
 
-static void vmx_do_cpuid(struct cpu_user_regs *regs)
+void vmx_do_cpuid(struct cpu_user_regs *regs)
 {
     unsigned int eax, ebx, ecx, edx;
 
@@ -1548,7 +1535,7 @@ static void vmx_do_cpuid(struct cpu_user
     regs->edx = edx;
 }
 
-static void vmx_dr_access(unsigned long exit_qualification,
+void vmx_dr_access(unsigned long exit_qualification,
                           struct cpu_user_regs *regs)
 {
     struct vcpu *v = current;
@@ -2037,7 +2024,7 @@ gp_fault:
     return X86EMUL_EXCEPTION;
 }
 
-static void vmx_do_extint(struct cpu_user_regs *regs)
+void vmx_do_extint(struct cpu_user_regs *regs)
 {
     unsigned int vector;
 
@@ -2182,9 +2169,16 @@ static void vmx_failed_vmentry(unsigned 
         break;
     }
 
+#if defined(XEN_KDB_CONFIG)
+    { extern void kdb_dump_vmcs(domid_t did, int vid);
+      printk("\n************* VMCS Area **************\n");
+      kdb_dump_vmcs(curr->domain->domain_id, (curr)->vcpu_id);
+    }
+#else
     printk("************* VMCS Area **************\n");
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
+#endif
 
     domain_crash(curr->domain);
 }
@@ -2268,6 +2262,8 @@ err:
     return -1;
 }
 
+extern void hybrid_vmx_vmexit_handler(struct cpu_user_regs *regs);
+
 asmlinkage void vmx_vmexit_handler(struct cpu_user_regs *regs)
 {
     unsigned int exit_reason, idtv_info, intr_info = 0, vector = 0;
@@ -2278,6 +2274,11 @@ asmlinkage void vmx_vmexit_handler(struc
         v->arch.hvm_vcpu.guest_cr[3] = v->arch.hvm_vcpu.hw_cr[3] =
             __vmread(GUEST_CR3);
 
+    if ( is_hybrid_vcpu(v)) {
+        hybrid_vmx_vmexit_handler(regs);
+        return;
+    }
+
     exit_reason = __vmread(VM_EXIT_REASON);
 
     if ( hvm_long_mode_enabled(v) )
@@ -2632,13 +2633,13 @@ asmlinkage void vmx_vmexit_handler(struc
     case EXIT_REASON_MONITOR_TRAP_FLAG:
         v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
         __vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vmx.exec_control);
-        v->arch.hvm_vcpu.single_step = 0;
 #if defined(XEN_KDB_CONFIG)
         if (kdb_handle_trap_entry(TRAP_debug, regs))
             break;
 #endif
         if ( v->domain->debugger_attached && v->arch.hvm_vcpu.single_step )
             domain_pause_for_debugger();
+        v->arch.hvm_vcpu.single_step = 0;
         break;
 
     case EXIT_REASON_PAUSE_INSTRUCTION:
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/vpt.c	Thu Nov 17 15:37:30 2011 -0800
@@ -289,6 +289,7 @@ void pt_intr_post(struct vcpu *v, struct
     if ( intack.source == hvm_intsrc_vector )
         return;
 
+    KASSERT(!is_hybrid_vcpu(current));
     spin_lock(&v->arch.hvm_vcpu.tm_lock);
 
     pt = is_pt_irq(v, intack);
diff -r f2cf898c7ff8 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm.c	Thu Nov 17 15:37:30 2011 -0800
@@ -490,9 +490,12 @@ void make_cr3(struct vcpu *v, unsigned l
 
 #endif /* !defined(__i386__) */
 
+/* calling hybrid_update_cr3 doesnt work because during context switch
+ * vmcs is not completely setup? */
 void write_ptbase(struct vcpu *v)
 {
-    write_cr3(v->arch.cr3);
+    if (!is_hybrid_vcpu(v))
+        write_cr3(v->arch.cr3);
 }
 
 /*
@@ -2482,6 +2485,7 @@ int get_page_type_preemptible(struct pag
 }
 
 
+extern void hybrid_update_cr3(struct vcpu *v);
 int new_guest_cr3(unsigned long mfn)
 {
     struct vcpu *curr = current;
@@ -2530,6 +2534,9 @@ int new_guest_cr3(unsigned long mfn)
 
     write_ptbase(curr);
 
+    if (is_hybrid_vcpu(curr))
+        hybrid_update_cr3(curr);
+
     if ( likely(old_base_mfn != 0) )
     {
         if ( paging_mode_refcounts(d) )
@@ -2863,10 +2870,23 @@ int do_mmuext_op(
 #endif
         
         case MMUEXT_TLB_FLUSH_LOCAL:
+            /* do this for both, flush_tlb_user and flush_tlb_kernel, for now.
+             * To debug: hvm_asid_flush_vcpu for flush_tlb_user, and
+             * vpid_sync_all for flush_tlb_kernel */
+            if (is_hybrid_domain(d)) {
+                extern void hybrid_flush_tlb(void);
+                hybrid_flush_tlb();
+                break;
+            }
             flush_tlb_local();
             break;
     
         case MMUEXT_INVLPG_LOCAL:
+            if (is_hybrid_domain(d)) {
+                extern void hybrid_do_invlpg(ulong);
+                hybrid_do_invlpg(op.arg1.linear_addr);
+                break;
+            }
             if ( !paging_mode_enabled(d) 
                  || paging_invlpg(curr, op.arg1.linear_addr) != 0 )
                 flush_tlb_one_local(op.arg1.linear_addr);
@@ -2877,6 +2897,10 @@ int do_mmuext_op(
         {
             cpumask_t pmask;
 
+            if (is_hybrid_domain(d)) {
+                printk("MUK:FIX: MMUEXT_TLB_FLUSH_MULTI/MMUEXT_INVLPG_MULTI\n");
+                break;
+            }
             if ( unlikely(vcpumask_to_pcpumask(d, op.arg2.vcpumask, &pmask)) )
             {
                 okay = 0;
@@ -4181,7 +4205,7 @@ long do_update_descriptor(u64 pa, u64 de
     mfn = gmfn_to_mfn(dom, gmfn);
     if ( (((unsigned int)pa % sizeof(struct desc_struct)) != 0) ||
          !mfn_valid(mfn) ||
-         !check_descriptor(dom, &d) )
+         (!is_hybrid_domain(dom) && !check_descriptor(dom, &d)) )
         return -EINVAL;
 
     page = mfn_to_page(mfn);
diff -r f2cf898c7ff8 xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm/hap/hap.c	Thu Nov 17 15:37:30 2011 -0800
@@ -705,8 +705,10 @@ void hap_vcpu_init(struct vcpu *v)
 static int hap_page_fault(struct vcpu *v, unsigned long va,
                           struct cpu_user_regs *regs)
 {
-    HAP_ERROR("Intercepted a guest #PF (%u:%u) with HAP enabled.\n",
-              v->domain->domain_id, v->vcpu_id);
+    HAP_ERROR("Intercepted a guest #PF (%u:%u:VA %016lx IP:%016lx) with "
+              "HAP enabled.\n", v->domain->domain_id, v->vcpu_id,va, regs->rip);
+
+    kdb_trap_immed(KDB_TRAP_NONFATAL);
     domain_crash(v->domain);
     return 0;
 }
diff -r f2cf898c7ff8 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm/mem_event.c	Thu Nov 17 15:37:30 2011 -0800
@@ -216,7 +216,7 @@ int mem_event_domctl(struct domain *d, x
 
             /* Currently only EPT is supported */
             rc = -ENODEV;
-            if ( !(is_hvm_domain(d) && d->arch.hvm_domain.hap_enabled &&
+            if ( !(is_hvm_or_hyb_domain(d) && d->arch.hvm_domain.hap_enabled &&
                   (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)) )
                 break;
 
diff -r f2cf898c7ff8 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm/mem_sharing.c	Thu Nov 17 15:37:30 2011 -0800
@@ -42,9 +42,6 @@ static void mem_sharing_audit(void);
 # define mem_sharing_audit() do {} while(0)
 #endif /* MEM_SHARING_AUDIT */
 
-
-#define hap_enabled(d) \
-    (is_hvm_domain(d) && (d)->arch.hvm_domain.hap_enabled)
 #define mem_sharing_enabled(d) \
     (is_hvm_domain(d) && (d)->arch.hvm_domain.mem_sharing_enabled)
  
diff -r f2cf898c7ff8 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Nov 17 15:37:30 2011 -0800
@@ -1569,7 +1569,7 @@ int p2m_init(struct domain *d)
     p2m->get_entry_current = p2m_gfn_to_mfn_current;
     p2m->change_entry_type_global = p2m_change_type_global;
 
-    if ( is_hvm_domain(d) && d->arch.hvm_domain.hap_enabled &&
+    if ( is_hvm_or_hyb_domain(d) && d->arch.hvm_domain.hap_enabled &&
          (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) )
         ept_p2m_init(d);
 
@@ -1596,7 +1596,7 @@ int set_p2m_entry(struct domain *d, unsi
 
     while ( todo )
     {
-        if ( is_hvm_domain(d) && d->arch.hvm_domain.hap_enabled )
+        if ( is_hvm_or_hyb_domain(d) && d->arch.hvm_domain.hap_enabled )
             order = ((((gfn | mfn_x(mfn) | todo) & (SUPERPAGE_PAGES - 1)) == 0)
                     && hvm_hap_has_2mb(d)) ? 9 : 0;
         else
diff -r f2cf898c7ff8 xen/arch/x86/mm/paging.c
--- a/xen/arch/x86/mm/paging.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm/paging.c	Thu Nov 17 15:37:30 2011 -0800
@@ -29,8 +29,6 @@
 #include <xen/numa.h>
 #include <xsm/xsm.h>
 
-#define hap_enabled(d) (is_hvm_domain(d) && (d)->arch.hvm_domain.hap_enabled)
-
 /* Printouts */
 #define PAGING_PRINTK(_f, _a...)                                     \
     debugtrace_printk("pg: %s(): " _f, __func__, ##_a)
diff -r f2cf898c7ff8 xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/time.c	Thu Nov 17 15:37:30 2011 -0800
@@ -879,7 +879,7 @@ static void __update_vcpu_system_time(st
         _u.tsc_to_system_mul = t->tsc_scale.mul_frac;
         _u.tsc_shift         = (s8)t->tsc_scale.shift;
     }
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         _u.tsc_timestamp += v->arch.hvm_vcpu.cache_tsc_offset;
 
     /* Don't bother unless timestamp record has changed or we are forced. */
@@ -947,7 +947,7 @@ static void update_domain_rtc(void)
     rcu_read_lock(&domlist_read_lock);
 
     for_each_domain ( d )
-        if ( is_hvm_domain(d) )
+        if ( is_hvm_or_hyb_domain(d) )
             rtc_update_clock(d);
 
     rcu_read_unlock(&domlist_read_lock);
@@ -956,7 +956,7 @@ static void update_domain_rtc(void)
 void domain_set_time_offset(struct domain *d, int32_t time_offset_seconds)
 {
     d->time_offset_seconds = time_offset_seconds;
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         rtc_update_clock(d);
 }
 
@@ -1856,7 +1856,6 @@ void tsc_set_info(struct domain *d,
         d->arch.vtsc = 0;
         return;
     }
-
     switch ( d->arch.tsc_mode = tsc_mode )
     {
     case TSC_MODE_NEVER_EMULATE:
@@ -1901,7 +1900,7 @@ void tsc_set_info(struct domain *d,
         break;
     }
     d->arch.incarnation = incarnation + 1;
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         hvm_set_rdtsc_exiting(d, d->arch.vtsc);
 }
 
diff -r f2cf898c7ff8 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/traps.c	Thu Nov 17 15:37:30 2011 -0800
@@ -1217,7 +1217,7 @@ static int spurious_page_fault(
     return is_spurious;
 }
 
-static int fixup_page_fault(unsigned long addr, struct cpu_user_regs *regs)
+int fixup_page_fault(unsigned long addr, struct cpu_user_regs *regs)
 {
     struct vcpu   *v = current;
     struct domain *d = v->domain;
@@ -3228,7 +3228,6 @@ void load_TR(void)
         .base = (long)(this_cpu(gdt_table) - FIRST_RESERVED_GDT_ENTRY),
         .limit = LAST_RESERVED_GDT_BYTE
     };
-
     _set_tssldt_desc(
         this_cpu(gdt_table) + TSS_ENTRY - FIRST_RESERVED_GDT_ENTRY,
         (unsigned long)tss,
diff -r f2cf898c7ff8 xen/arch/x86/x86_64/traps.c
--- a/xen/arch/x86/x86_64/traps.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/x86_64/traps.c	Thu Nov 17 15:37:30 2011 -0800
@@ -617,7 +617,7 @@ static void hypercall_page_initialise_ri
 void hypercall_page_initialise(struct domain *d, void *hypercall_page)
 {
     memset(hypercall_page, 0xCC, PAGE_SIZE);
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         hvm_hypercall_page_initialise(d, hypercall_page);
     else if ( !is_pv_32bit_domain(d) )
         hypercall_page_initialise_ring3_kernel(hypercall_page);
diff -r f2cf898c7ff8 xen/common/domain.c
--- a/xen/common/domain.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/common/domain.c	Thu Nov 17 15:37:30 2011 -0800
@@ -238,8 +238,13 @@ struct domain *domain_create(
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code = -1;
 
-    if ( domcr_flags & DOMCRF_hvm )
+    if ( domcr_flags & DOMCRF_hybrid ) {
+        d->is_hybrid = 1;
+        printk("Hybrid guest with%s ept. Domid:%d\n", 
+               (domcr_flags&DOMCRF_hap) ? "" : " no", domid);
+    } else if ( domcr_flags & DOMCRF_hvm ) {
         d->is_hvm = 1;
+    }
 
     if ( domid == 0 )
     {
@@ -588,7 +593,8 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    if (current->arch.gdbsx_vcpu_event == 0)
+        send_guest_global_virq(dom0, VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
diff -r f2cf898c7ff8 xen/common/domctl.c
--- a/xen/common/domctl.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/common/domctl.c	Thu Nov 17 15:37:30 2011 -0800
@@ -132,6 +132,8 @@ void getdomaininfo(struct domain *d, str
 
     if ( is_hvm_domain(d) )
         info->flags |= XEN_DOMINF_hvm_guest;
+    else if ( is_hybrid_domain(d) )
+        info->flags |= XEN_DOMINF_hybrid_guest;
 
     xsm_security_domaininfo(d, info);
 
@@ -394,7 +396,8 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         if ( supervisor_mode_kernel ||
              (op->u.createdomain.flags &
              ~(XEN_DOMCTL_CDF_hvm_guest | XEN_DOMCTL_CDF_hap |
-               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off)) )
+               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
+               XEN_DOMCTL_CDF_hybrid_guest)) )
             break;
 
         dom = op->domain;
@@ -430,6 +433,8 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
             domcr_flags |= DOMCRF_s3_integrity;
         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
             domcr_flags |= DOMCRF_oos_off;
+        if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_hybrid_guest )
+            domcr_flags |= DOMCRF_hybrid;
 
         ret = -ENOMEM;
         d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref);
diff -r f2cf898c7ff8 xen/common/kernel.c
--- a/xen/common/kernel.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/common/kernel.c	Thu Nov 17 15:37:30 2011 -0800
@@ -239,13 +239,16 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDL
             if ( supervisor_mode_kernel )
                 fi.submap |= 1U << XENFEAT_supervisor_mode_kernel;
 #ifdef CONFIG_X86
-            if ( !is_hvm_vcpu(current) )
+            if ( !is_hvm_vcpu(current) && 
+                 !paging_mode_translate(current->domain) )  /* hybrid */
                 fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
                              (1U << XENFEAT_highmem_assist) |
                              (1U << XENFEAT_gnttab_map_avail_bits);
             else
                 fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
                              (1U << XENFEAT_hvm_callback_vector);
+            if ( is_hybrid_vcpu(current) )
+                fi.submap |= (1U << XENFEAT_hvm_callback_vector);
 #endif
             break;
         default:
diff -r f2cf898c7ff8 xen/common/memory.c
--- a/xen/common/memory.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/common/memory.c	Thu Nov 17 15:37:30 2011 -0800
@@ -89,7 +89,7 @@ static void increase_reservation(struct 
     a->nr_done = i;
 }
 
-static void populate_physmap(struct memop_args *a)
+static noinline void populate_physmap(struct memop_args *a)
 {
     struct page_info *page;
     unsigned long i, j;
@@ -134,6 +134,7 @@ static void populate_physmap(struct memo
             }
 
             mfn = page_to_mfn(page);
+
             guest_physmap_add_page(d, gpfn, mfn, a->extent_order);
 
             if ( !paging_mode_translate(d) )
diff -r f2cf898c7ff8 xen/common/timer.c
--- a/xen/common/timer.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/common/timer.c	Thu Nov 17 15:37:30 2011 -0800
@@ -546,13 +546,20 @@ void kdb_dump_timer_queues(void)
     struct timers *ts;
     unsigned long sz, offs;
     char buf[KSYM_NAME_LEN+1];
-    int            cpu, j;
-    s_time_t       now = NOW();
+    int cpu, j;
+    u64 tsc;
 
     for_each_online_cpu( cpu )
     {
         ts = &per_cpu(timers, cpu);
-        kdbp("CPU[%02d]: NOW:0x%08x%08x\n", cpu, (u32)(now>>32), (u32)now);
+        kdbp("CPU[%02d]:", cpu);
+
+        if (cpu == smp_processor_id()) {
+            s_time_t now = NOW();
+            rdtscll(tsc);
+            kdbp("NOW:0x%08x%08x TSC:0x%016lx\n", (u32)(now>>32),(u32)now, tsc);
+        } else
+            kdbp("\n");
 
         /* timers in the heap */
         for ( j = 1; j <= GET_HEAP_SIZE(ts->heap); j++ ) {
diff -r f2cf898c7ff8 xen/include/asm-x86/desc.h
--- a/xen/include/asm-x86/desc.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/desc.h	Thu Nov 17 15:37:30 2011 -0800
@@ -58,7 +58,8 @@
 #ifndef __ASSEMBLY__
 
 #if defined(__x86_64__)
-#define GUEST_KERNEL_RPL(d) (is_pv_32bit_domain(d) ? 1 : 3)
+#define GUEST_KERNEL_RPL(d) (is_hybrid_domain(d) ? 0 : \
+                      is_pv_32bit_domain(d) ? 1 : 3)
 #elif defined(__i386__)
 #define GUEST_KERNEL_RPL(d) ((void)(d), 1)
 #endif
@@ -67,6 +68,9 @@
 #define __fixup_guest_selector(d, sel)                             \
 ({                                                                 \
     uint16_t _rpl = GUEST_KERNEL_RPL(d);                           \
+    if (d->is_hybrid) {                                      \
+        printk("MUK: hybrid domain fixing up selector\n");          \
+    }                                                              \
     (sel) = (((sel) & 3) >= _rpl) ? (sel) : (((sel) & ~3) | _rpl); \
 })
 
diff -r f2cf898c7ff8 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/domain.h	Thu Nov 17 15:37:30 2011 -0800
@@ -18,7 +18,7 @@
 #endif
 #define is_pv_32on64_vcpu(v)   (is_pv_32on64_domain((v)->domain))
 
-#define is_hvm_pv_evtchn_domain(d) (is_hvm_domain(d) && \
+#define is_hvm_pv_evtchn_domain(d) (is_hvm_or_hyb_domain(d) && \
         d->arch.hvm_domain.irq.callback_via_type == HVMIRQ_callback_vector)
 #define is_hvm_pv_evtchn_vcpu(v) (is_hvm_pv_evtchn_domain(v->domain))
 
diff -r f2cf898c7ff8 xen/include/asm-x86/event.h
--- a/xen/include/asm-x86/event.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/event.h	Thu Nov 17 15:37:30 2011 -0800
@@ -18,7 +18,7 @@ int hvm_local_events_need_delivery(struc
 static inline int local_events_need_delivery(void)
 {
     struct vcpu *v = current;
-    return (is_hvm_vcpu(v) ? hvm_local_events_need_delivery(v) :
+    return ( is_hvm_or_hyb_vcpu(v) ? hvm_local_events_need_delivery(v) :
             (vcpu_info(v, evtchn_upcall_pending) &&
              !vcpu_info(v, evtchn_upcall_mask)));
 }
diff -r f2cf898c7ff8 xen/include/asm-x86/guest_access.h
--- a/xen/include/asm-x86/guest_access.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/guest_access.h	Thu Nov 17 15:37:30 2011 -0800
@@ -14,19 +14,19 @@
 
 /* Raw access functions: no type checking. */
 #define raw_copy_to_guest(dst, src, len)        \
-    (is_hvm_vcpu(current) ?                     \
+    ((is_hvm_vcpu(current) || is_hyb_hap_vcpu(current)) ?  \
      copy_to_user_hvm((dst), (src), (len)) :    \
      copy_to_user((dst), (src), (len)))
 #define raw_copy_from_guest(dst, src, len)      \
-    (is_hvm_vcpu(current) ?                     \
+    ((is_hvm_vcpu(current) || is_hyb_hap_vcpu(current)) ?  \
      copy_from_user_hvm((dst), (src), (len)) :  \
      copy_from_user((dst), (src), (len)))
 #define __raw_copy_to_guest(dst, src, len)      \
-    (is_hvm_vcpu(current) ?                     \
+    ((is_hvm_vcpu(current) || is_hyb_hap_vcpu(current)) ?  \
      copy_to_user_hvm((dst), (src), (len)) :    \
      __copy_to_user((dst), (src), (len)))
 #define __raw_copy_from_guest(dst, src, len)    \
-    (is_hvm_vcpu(current) ?                     \
+    ((is_hvm_vcpu(current) || is_hyb_hap_vcpu(current)) ?  \
      copy_from_user_hvm((dst), (src), (len)) :  \
      __copy_from_user((dst), (src), (len)))
 
diff -r f2cf898c7ff8 xen/include/asm-x86/hvm/domain.h
--- a/xen/include/asm-x86/hvm/domain.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/hvm/domain.h	Thu Nov 17 15:37:30 2011 -0800
@@ -98,5 +98,8 @@ struct hvm_domain {
     };
 };
 
+#define hap_enabled(d)    \
+    (is_hvm_or_hyb_domain(d) && (d)->arch.hvm_domain.hap_enabled)
+
 #endif /* __ASM_X86_HVM_DOMAIN_H__ */
 
diff -r f2cf898c7ff8 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/hvm/hvm.h	Thu Nov 17 15:37:30 2011 -0800
@@ -144,10 +144,12 @@ struct hvm_function_table {
 extern struct hvm_function_table hvm_funcs;
 extern int hvm_enabled;
 
+int hybrid_domain_initialise(struct domain *d);
 int hvm_domain_initialise(struct domain *d);
 void hvm_domain_relinquish_resources(struct domain *d);
 void hvm_domain_destroy(struct domain *d);
 
+int hybrid_vcpu_initialise(struct vcpu *v);
 int hvm_vcpu_initialise(struct vcpu *v);
 void hvm_vcpu_destroy(struct vcpu *v);
 void hvm_vcpu_down(struct vcpu *v);
diff -r f2cf898c7ff8 xen/include/asm-x86/hvm/vmx/vmx.h
--- a/xen/include/asm-x86/hvm/vmx/vmx.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h	Thu Nov 17 15:37:30 2011 -0800
@@ -110,6 +110,7 @@ void vmx_update_debug_state(struct vcpu 
 #define EXIT_REASON_EPT_VIOLATION       48
 #define EXIT_REASON_EPT_MISCONFIG       49
 #define EXIT_REASON_RDTSCP              51
+#define EXIT_REASON_INVVPID             53
 #define EXIT_REASON_WBINVD              54
 #define EXIT_REASON_XSETBV              55
 
@@ -284,6 +285,14 @@ static inline unsigned long __vmread_saf
     return ecx;
 }
 
+static inline unsigned long vmr(unsigned long field)
+{
+    int rc;
+    unsigned long val;
+    val = __vmread_safe(field, &rc);
+    return rc ? 0 : val;
+}
+
 static inline void __vm_set_bit(unsigned long field, unsigned int bit)
 {
     __vmwrite(field, __vmread(field) | (1UL << bit));
@@ -410,6 +419,8 @@ void vmx_inject_nmi(void);
 void ept_p2m_init(struct domain *d);
 void ept_walk_table(struct domain *d, unsigned long gfn);
 
+void hybrid_vmx_vmexit_handler(struct cpu_user_regs *regs);
+
 /* EPT violation qualifications definitions */
 #define _EPT_READ_VIOLATION         0
 #define EPT_READ_VIOLATION          (1UL<<_EPT_READ_VIOLATION)
@@ -430,4 +441,39 @@ void ept_walk_table(struct domain *d, un
 
 #define EPT_PAGETABLE_ENTRIES       512
 
+/*  
+ * Not all cases receive valid value in the VM-exit instruction length field.
+ * Callers must know what they're doing!
+ */ 
+static inline int __get_instruction_length(void)
+{   
+    int len;
+    len = __vmread(VM_EXIT_INSTRUCTION_LEN); /* Safe: callers audited */
+    BUG_ON((len < 1) || (len > 15));
+    return len;
+}
+
+static inline void __update_guest_eip(unsigned long inst_len)
+{
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    unsigned long x;
+    
+    regs->eip += inst_len;
+    regs->eflags &= ~X86_EFLAGS_RF;
+    
+    x = __vmread(GUEST_INTERRUPTIBILITY_INFO);
+    if ( x & (VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS) )
+    {
+        x &= ~(VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS);
+        __vmwrite(GUEST_INTERRUPTIBILITY_INFO, x);
+    }
+    
+    if ( regs->eflags & X86_EFLAGS_TF )
+        vmx_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
+}   
+
+extern void vmx_dr_access(unsigned long, struct cpu_user_regs *);
+extern void vmx_fpu_enter(struct vcpu *v);
+extern void vmx_fpu_dirty_intercept(void);
+
 #endif /* __ASM_X86_HVM_VMX_VMX_H__ */
diff -r f2cf898c7ff8 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/public/domctl.h	Thu Nov 17 15:37:30 2011 -0800
@@ -64,6 +64,9 @@ struct xen_domctl_createdomain {
  /* Disable out-of-sync shadow page tables? */
 #define _XEN_DOMCTL_CDF_oos_off       3
 #define XEN_DOMCTL_CDF_oos_off        (1U<<_XEN_DOMCTL_CDF_oos_off)
+ /* Is this a hybrid guest? */
+#define _XEN_DOMCTL_CDF_hybrid_guest  4
+#define XEN_DOMCTL_CDF_hybrid_guest   (1U<<_XEN_DOMCTL_CDF_hybrid_guest)
 };
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
@@ -93,6 +96,9 @@ struct xen_domctl_getdomaininfo {
  /* Being debugged.  */
 #define _XEN_DOMINF_debugged  6
 #define XEN_DOMINF_debugged   (1U<<_XEN_DOMINF_debugged)
+ /* domain is hybrid */
+#define _XEN_DOMINF_hybrid_guest 7
+#define XEN_DOMINF_hybrid_guest   (1U<<_XEN_DOMINF_hybrid_guest)
  /* XEN_DOMINF_shutdown guest-supplied code.  */
 #define XEN_DOMINF_shutdownmask 255
 #define XEN_DOMINF_shutdownshift 16
diff -r f2cf898c7ff8 xen/include/public/xen.h
--- a/xen/include/public/xen.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/public/xen.h	Thu Nov 17 15:37:30 2011 -0800
@@ -594,6 +594,7 @@ typedef struct start_info start_info_t;
 #define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
 #define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
 #define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
+#define SIF_IS_HYBRID     (1<<3)  /* Is it a PV running in HVM container? */
 #define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
 
 /*
diff -r f2cf898c7ff8 xen/include/xen/lib.h
--- a/xen/include/xen/lib.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/xen/lib.h	Thu Nov 17 15:37:30 2011 -0800
@@ -39,6 +39,17 @@ do {                                    
 #else
 #define ASSERT(p) ((void)0)
 #endif
+#ifdef XEN_KDB_CONFIG
+    #define KASSERT(p)                                                \
+      do { if (!(p)) {                                                \
+               kdbp("KASSERT in %s at %d\n", __FUNCTION__, __LINE__); \
+               kdb_trap_immed(KDB_TRAP_NONFATAL);                     \
+           }                                                          \
+      } while (0)
+#else
+#define KASSERT(p) \
+    do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
+#endif
 
 #define ABS(_x) ({                              \
     typeof(_x) __x = (_x);                      \
@@ -126,6 +137,8 @@ extern void add_taint(unsigned);
 extern void kdb_trap_immed(int);
 extern void kdbtrc(unsigned int, unsigned int, uint64_t, uint64_t, uint64_t);
 extern void kdbp(const char *fmt, ...);
+extern volatile int mukkdbdbg;
+#define mukkdbp(...) {(mukkdbdbg) ? kdbp(__VA_ARGS__):0;}
 #endif
 
 #endif /* __LIB_H__ */
diff -r f2cf898c7ff8 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/xen/sched.h	Thu Nov 17 15:37:30 2011 -0800
@@ -228,6 +228,7 @@ struct domain
 
     /* Is this an HVM guest? */
     bool_t           is_hvm;
+    bool_t           is_hybrid;
     /* Does this guest need iommu mappings? */
     bool_t           need_iommu;
     /* Is this guest fully privileged (aka dom0)? */
@@ -388,6 +389,9 @@ struct domain *domain_create(
  /* DOMCRF_oos_off: dont use out-of-sync optimization for shadow page tables */
 #define _DOMCRF_oos_off         4
 #define DOMCRF_oos_off          (1U<<_DOMCRF_oos_off)
+ /* DOMCRF_hybrid: Create PV domain in HVM container */
+#define _DOMCRF_hybrid          5
+#define DOMCRF_hybrid           (1U<<_DOMCRF_hybrid)
 
 /*
  * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
@@ -590,10 +594,17 @@ uint64_t get_cpu_idle_time(unsigned int 
 
 #define is_hvm_domain(d) ((d)->is_hvm)
 #define is_hvm_vcpu(v)   (is_hvm_domain(v->domain))
+#define is_hybrid_domain(d) ((d)->is_hybrid)
+#define is_hybrid_vcpu(v)   (is_hybrid_domain(v->domain))
+#define is_hvm_or_hyb_domain(d) (is_hvm_domain(d) || is_hybrid_domain(d))
+#define is_hvm_or_hyb_vcpu(v) (is_hvm_or_hyb_domain(v->domain))
 #define is_pinned_vcpu(v) ((v)->domain->is_pinned || \
                            cpus_weight((v)->cpu_affinity) == 1)
 #define need_iommu(d)    ((d)->need_iommu)
 
+#define is_hyb_hap_domain(d) (is_hybrid_domain(d) && hap_enabled(d))
+#define is_hyb_hap_vcpu(v) (is_hyb_hap_domain(v->domain))
+
 void set_vcpu_migration_delay(unsigned int delay);
 unsigned int get_vcpu_migration_delay(void);
 
diff -r f2cf898c7ff8 xen/include/xen/xencomm.h
--- a/xen/include/xen/xencomm.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/xen/xencomm.h	Thu Nov 17 15:37:30 2011 -0800
@@ -79,7 +79,7 @@ static inline unsigned long xencomm_inli
  * Copy an array of objects from guest context via a guest handle.
  * Optionally specify an offset into the guest array.
  */
-#define copy_from_guest_offset(ptr, hnd, idx, nr) \
+#define copy_from_guest_offset(ptr, hnd, idx, nr) \ JUNK
     __copy_from_guest_offset(ptr, hnd, idx, nr)
 
 /* Copy sub-field of a structure from guest context via a guest handle. */
diff -r f2cf898c7ff8 xen/kdb/kdb_cmds.c
--- a/xen/kdb/kdb_cmds.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/kdb/kdb_cmds.c	Thu Nov 17 15:37:30 2011 -0800
@@ -173,7 +173,7 @@ kdb_do_cmds(struct cpu_user_regs *regs)
 
 /* ===================== Util functions  ==================================== */
 
-static int
+int
 kdb_vcpu_valid(struct vcpu *in_vp)
 {
     struct domain *dp;
@@ -298,15 +298,13 @@ kdb_str2domid(const char *domstr, domid_
 }
 
 static struct domain *
-kdb_strdomid2ptr(const char *domstr)
+kdb_strdomid2ptr(const char *domstr, int perror)
 {
-    ulong l;
-    struct domain *dp;
-    if (!kdb_str2ulong(domstr, &l) || !(dp=kdb_domid2ptr((domid_t)l))) {
-        kdbp("Invalid domid:%s\n", domstr);
-        return NULL;
-    } else
-        return dp;
+    domid_t domid;
+    if (kdb_str2domid(domstr, &domid, perror)) {
+        return(kdb_domid2ptr(domid));
+    }
+    return NULL;
 }
 
 /* return a guest bitness: 32 or 64 */
@@ -319,7 +317,7 @@ kdb_guest_bitness(domid_t domid)
 
     if (is_idle_domain(dp))
         retval = HYPSZ;
-    else if (is_hvm_domain(dp))
+    else if (is_hvm_or_hyb_domain(dp))
         retval = (hvm_long_mode_enabled(dp->vcpu[0])) ? HYPSZ : 32;
     else 
         retval = is_pv_32bit_domain(dp) ? 32 : HYPSZ;
@@ -825,7 +823,7 @@ struct  Xgt_desc_struct {
     unsigned long address __attribute__((packed));
 };
 
-static void
+void
 kdb_show_special_regs(struct cpu_user_regs *regs)
 {
     struct Xgt_desc_struct desc;
@@ -958,7 +956,8 @@ kdb_cmdf_ss(int argc, const char **argv,
     #define KDB_HALT_INSTR 0xf4
 
     kdbbyt_t byte;
-    domid_t id = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+    struct domain *dp = current->domain;
+    domid_t id = guest_mode(regs) ? dp->domain_id : DOMID_IDLE;
 
     if (argc > 1 && *argv[1] == '?')
         return kdb_usgf_ss();
@@ -977,16 +976,12 @@ kdb_cmdf_ss(int argc, const char **argv,
         kdbp("kdb: Failed to read byte at: %lx\n", regs->KDBIP);
         return KDB_CPU_MAIN_KDB;
     }
-    if (guest_mode(regs) && is_hvm_vcpu(current))
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current)) {
+        dp->debugger_attached = 1;  /* see svm_do_resume/vmx_do_ */
         current->arch.hvm_vcpu.single_step = 1;
-    else
+    } else
         regs->eflags |= X86_EFLAGS_TF;
-#if 0
-    if (guest_mode(regs) && is_hvm_vcpu(current)) {
-        struct domain *dp = current->domain;
-        dp->debugger_attached = 1;  /* see svm_do_resume/vmx_do_ */
-    }
-#endif
+
     return KDB_CPU_SS;
 }
 
@@ -1052,7 +1047,7 @@ kdb_cmdf_ssb(int argc, const char **argv
         kdbp("%s: regs not available\n", __FUNCTION__);
         return KDB_CPU_MAIN_KDB;
     }
-    if (is_hvm_vcpu(current)) 
+    if (is_hvm_or_hyb_vcpu(current)) 
         current->domain->debugger_attached = 1;        /* vmx/svm_do_resume()*/
 
     regs->eflags |= X86_EFLAGS_TF;
@@ -1640,7 +1635,7 @@ kdb_set_bp(domid_t domid, kdbva_t addr, 
         return KDBMAXSBP;
     }
     /* make sure swbp reporting is enabled in the vmcb/vmcs */
-    if (is_hvm_domain(kdb_domid2ptr(domid))) {
+    if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
         struct domain *dp = kdb_domid2ptr(domid);
         dp->debugger_attached = 1;              /* see svm_do_resume/vmx_do_ */
         KDBGP("debugger_attached set. domid:%d\n", domid);
@@ -1693,7 +1688,7 @@ kdb_cmdf_bp(int argc, const char **argv,
     if (domidstrp && !kdb_str2domid(domidstrp, &domid, 1)) {
         return kdb_usgf_bp();
     }
-    if (argc > 3 && is_hvm_domain(kdb_domid2ptr(domid))) {
+    if (argc > 3 && is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
         kdbp("HVM domain not supported yet for conditional bp\n");
         return KDB_CPU_MAIN_KDB;
     }
@@ -1741,7 +1736,7 @@ kdb_cmdf_btp(int argc, const char **argv
     argsidx = 2;                   /* assume 3rd arg is not domid */
     if (argc > 3 && kdb_str2domid(argv[2], &domid, 0)) {
 
-        if (is_hvm_domain(kdb_domid2ptr(domid))) {
+        if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
             kdbp("HVM domains are not currently supprted\n");
             return KDB_CPU_MAIN_KDB;
         } else
@@ -1893,7 +1888,7 @@ kdb_cmdf_vcpuh(int argc, const char **ar
         return kdb_usgf_vcpuh();
 
     if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp) ||
-        !is_hvm_vcpu(vp)) {
+        !is_hvm_or_hyb_vcpu(vp)) {
 
         kdbp("kdb: Bad VCPU: %s\n", argv[1]);
         return KDB_CPU_MAIN_KDB;
@@ -2042,11 +2037,12 @@ kdb_display_vcpu(struct vcpu *vp)
     kdbp("  cpu_affinity:0x%lx vcpu_dirty_cpumask:0x%lx sched_priv:0x%p\n",
          vp->cpu_affinity.bits[0], vp->vcpu_dirty_cpumask.bits[0],
          vp->sched_priv);
-    kdbp("  &runstate: %p state: %x\n", &vp->runstate, vp->runstate.state);
+    kdbp("  &runstate: %p state: %x guestptr:%p\n", &vp->runstate, 
+         vp->runstate.state, runstate_guest(vp));
     kdbp("\n");
     kdbp("  arch info: (%p)\n", &vp->arch);
     kdbp("    guest_context: VGCF_ flags:%lx", gp->flags); /* VGCF_in_kernel */
-    if (is_hvm_vcpu(vp))
+    if (is_hvm_or_hyb_vcpu(vp))
         kdbp("    (HVM guest: IP, SP, EFLAGS may be stale)");
     kdbp("\n");
     kdb_print_uregs(&gp->user_regs);
@@ -2146,7 +2142,7 @@ static void kdb_pr_dom_pg_modes(struct d
         if ( paging_mode_external(d) )
             kdbp(" external(PG_external) ");
     } else
-        kdbp("disabled");
+        kdbp(" disabled");
     kdbp("\n");
 }
 
@@ -2198,6 +2194,19 @@ static void noinline kdb_print_dom_event
 #endif
 }
 
+static void kdb_prnt_hvm_dom_info(struct domain *dp)
+{
+    kdbp("    HVM info: Hap is%s enabled\n", 
+         dp->arch.hvm_domain.hap_enabled ? "" : " not");
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        struct vmx_domain *vdp = &dp->arch.hvm_domain.vmx;
+        kdbp("    EPT: ept_mt:%x ept_wl:%x asr:%013lx\n", 
+             vdp->ept_control.ept_mt, vdp->ept_control.ept_wl, 
+             vdp->ept_control.asr);
+    }
+}
+
 /* display one domain info */
 static void
 kdb_display_dom(struct domain *dp)
@@ -2240,9 +2249,9 @@ kdb_display_dom(struct domain *dp)
         kdbp("    mapcnt:");
         kdb_print_spin_lock("mapcnt: lk:", &gp->lock, "\n");
     }
-    kdbp("  hvm:%d priv:%d dbg:%d dying:%d paused:%d\n",
-         dp->is_hvm, dp->is_privileged, dp->debugger_attached,
-         dp->is_dying, dp->is_paused_by_controller);
+    kdbp("  hvm:%d hybrid:%d priv:%d dbg:%d dying:%d paused:%d\n",
+         dp->is_hvm, dp->is_hybrid, dp->is_privileged, 
+         dp->debugger_attached, dp->is_dying, dp->is_paused_by_controller);
     kdb_print_spin_lock("  shutdown: lk:", &dp->shutdown_lock, "\n");
     kdbp("  shutn:%d shut:%d code:%d \n", dp->is_shutting_down,
          dp->is_shut_down, dp->shutdown_code);
@@ -2266,7 +2275,10 @@ kdb_display_dom(struct domain *dp)
     kdbp("    &mapchache:0x%xp\n", &ap->mapcache);
 #endif
     kdbp("    ioport:0x%p &hvm_dom:0x%p\n", ap->ioport_caps, &ap->hvm_domain);
-    kdbp("    &pging_dom:%p mode:%lx", &ap->paging, ap->paging.mode); 
+    if (is_hvm_or_hyb_domain(dp))
+        kdb_prnt_hvm_dom_info(dp);
+
+    kdbp("    &pging_dom:%p mode: %lx", &ap->paging, ap->paging.mode); 
     kdb_pr_dom_pg_modes(dp);
     kdbp("    p2m ptr:%p  pages:{%p, %p}\n", ap->p2m, ap->p2m->pages.next,
          KDB_PGLLE(ap->p2m->pages));
@@ -2556,7 +2568,7 @@ kdb_cmdf_didt(int argc, const char **arg
 }
 #endif
 
-struct gdte {
+struct gdte {             /* same for TSS and LDT */
     ulong limit0:16;
     ulong base0:24;       /* linear address base, not pa */
     ulong acctype:4;      /* Type: access rights */
@@ -2576,15 +2588,23 @@ union gdte_u {
     u64 gval;
 };
 
-struct sgdte {           /* system gdte */
+struct call_gdte {
     unsigned short offs0:16;
     unsigned short sel:16;
     unsigned short misc0:16;
     unsigned short offs1:16;
 };
 
+struct idt_gdte {
+    unsigned long offs0:16;
+    unsigned long sel:16;
+    unsigned long ist:3;
+    unsigned long unused0:13;
+    unsigned long offs1:16;
+};
 union sgdte_u {
-    struct sgdte sgdte;
+    struct call_gdte cgdte;
+    struct idt_gdte igdte;
     u64 sgval;
 };
 
@@ -2611,7 +2631,7 @@ static char *kdb_ret_acctype(uint acctyp
 static kdb_cpu_cmd_t
 kdb_usgf_dgdt(void)
 {
-    kdbp("dgdt [gdt-ptr hex-gdt-size] dump GDT table on current cpu or for "
+    kdbp("dgdt [gdt-ptr decimal-byte-size] dump GDT table on current cpu or for"
          "given vcpu\n");
     return KDB_CPU_MAIN_KDB;
 }
@@ -2620,9 +2640,9 @@ kdb_cmdf_dgdt(int argc, const char **arg
 {
     struct Xgt_desc_struct desc;
     union gdte_u u1;
-    ulong addr, end;
+    ulong start_addr, end_addr, taddr=0;
     domid_t domid = DOMID_IDLE;
-    int i;
+    int idx;
 
     if (argc > 1 && *argv[1] == '?')
         return kdb_usgf_dgdt();
@@ -2631,62 +2651,62 @@ kdb_cmdf_dgdt(int argc, const char **arg
         if (argc != 3)
             return kdb_usgf_dgdt();
 
-        if (kdb_str2ulong(argv[1], (ulong *)&addr) && 
-            kdb_str2ulong(argv[2], (ulong *)&end)) {
-            end += addr;
+        if (kdb_str2ulong(argv[1], (ulong *)&start_addr) && 
+            kdb_str2deci(argv[2], (int *)&taddr)) {
+            end_addr = start_addr + taddr;
         } else {
             kdbp("dgdt: Bad arg:%s or %s\n", argv[1], argv[2]);
             return kdb_usgf_dgdt();
         }
     } else {
         __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
-        addr = (ulong)desc.address; 
-        end = (ulong)desc.address + desc.size;
+        start_addr = (ulong)desc.address; 
+        end_addr = (ulong)desc.address + desc.size;
     }
-    kdbp("GDT: Will skip null desc at 0, addr:%lx end:%lx\n", addr, end);
-    addr += 8;         /* skip null descriptor */
-
+    kdbp("GDT: Will skip null desc at 0, start:%lx end:%lx\n", start_addr, 
+         end_addr);
     kdbp("[idx]   sel --- val --------  Accs DPL P AVL L DB G "
          "--Base Addr ----  Limit\n");
     kdbp("                              Type\n");
 
-    for (i=1;  addr < end;  i++, addr += sizeof(ulong)) {
+    /* skip first 8 null bytes */
+    /* the cpu multiplies the index by 8 and adds to GDT.base */
+    for (taddr = start_addr+8; taddr < end_addr;  taddr += sizeof(ulong)) {
 
         /* not all entries are mapped. do this to avoid GP even if hyp */
-        if (!kdb_read_mem(addr, (kdbbyt_t *)&u1, sizeof(u1),domid) || !u1.gval)
+        if (!kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1),domid) || !u1.gval)
             continue;
 
         if (u1.gval == 0xffffffffffffffff || u1.gval == 0x5555555555555555)
             continue;               /* what an effin x86 mess */
 
+        idx = (taddr - start_addr) / 8;
         if (u1.gdte.S == 0) {       /* System Desc are 16 bytes in 64bit mode */
-            addr += sizeof(ulong);
-            i++;
+            taddr += sizeof(ulong);
             continue;
         }
+kdbp("ADDR: %lx\n", taddr);
         kdbp("[%04x] %04x %016lx  %4s  %x  %d  %d  %d  %d %d %016lx  %05x\n",
-             i, (i<<3), u1.gval, kdb_ret_acctype(u1.gdte.acctype), u1.gdte.DPL, 
+             idx, (idx<<3), u1.gval, kdb_ret_acctype(u1.gdte.acctype), 
+             u1.gdte.DPL, 
              u1.gdte.P, u1.gdte.AVL, u1.gdte.L, u1.gdte.DB, u1.gdte.G,  
              (u64)((u64)u1.gdte.base0 | (u64)((u64)u1.gdte.base1<<24)), 
              u1.gdte.limit0 | (u1.gdte.limit1<<16));
     }
 
-    kdbp("\nSystem descriptors (S=0) :\n");
-    addr = (ulong)desc.address + 8;         /* skip null descriptor */
-
-    for (i=1;  addr < end;  i++, addr += sizeof(ulong)) {
-        union sgdte_u u2;
+    kdbp("\nSystem descriptors (S=0) : (skipping 0th entry)\n");
+    for (taddr=start_addr+8;  taddr < end_addr;  taddr += sizeof(ulong)) {
         uint acctype;
-        u64 upper, offs0_64=0, offs32_63=0;
+        u64 upper, addr64=0;
 
         /* not all entries are mapped. do this to avoid GP even if hyp */
-        if (kdb_read_mem(addr, (kdbbyt_t *)&u1, sizeof(u1),domid)==0 || 
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1), domid)==0 || 
             u1.gval == 0 || u1.gdte.S == 1) {
             continue;
         }
-
-        addr += sizeof(ulong);
-        if (kdb_read_mem(addr, (kdbbyt_t *)&upper, 8, domid) == 0) {
+        idx = (taddr - start_addr) / 8;
+        taddr += sizeof(ulong);
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&upper, 8, domid) == 0) {
             kdbp("Could not read upper 8 bytes of system desc\n");
             upper = 0;
         }
@@ -2695,11 +2715,11 @@ kdb_cmdf_dgdt(int argc, const char **arg
             acctype != 14 && acctype != 15)
             continue;
 
-        kdbp("[%04x] %04x  val:%016lx DPL:%x P:%d acctype:%x ",
-             i, (i<<3), u1.gval, u1.gdte.DPL, u1.gdte.P, acctype); 
-
-        u2.sgval = u1.gval;
-        offs32_63 = (u64)((upper & 0xFFFFFFFF)) << 32;
+kdbp("ADDR: %lx\n", taddr);
+        kdbp("[%04x] %04x val:%016lx DPL:%x P:%d type:%x ",
+             idx, (idx<<3), u1.gval, u1.gdte.DPL, u1.gdte.P, acctype); 
+
+        upper = (u64)((u64)(upper & 0xFFFFFFFF) << 32);
 
         /* Vol 3A: table: 3-2  page: 3-19 */
         if (acctype == 2) {
@@ -2722,17 +2742,28 @@ kdb_cmdf_dgdt(int argc, const char **arg
         }
 
         if (acctype == 2 || acctype == 9 || acctype == 11) {
-            kdbp("        AVL:%d L:%d D/B:%d G:%d Base Addr:%016lx Limit:%x\n",
-                 u1.gdte.AVL, u1.gdte.L, u1.gdte.DB, u1.gdte.G,  
-                 u1.gdte.base0 | (u1.gdte.base1<<24) | offs32_63,
-                 u1.gdte.limit0 | (u1.gdte.limit1<<16));
-
-        } else if (acctype == 12 || acctype == 14 || acctype == 15) {
-            offs0_64 = u2.sgdte.offs0 | (u64)u2.sgdte.offs1<<48 | offs32_63;
-            kdbp("        Entry: %04x:%016lx\n", u2.sgdte.sel, offs0_64);
-        }
-
-        i++;
+            kdbp("        AVL:%d G:%d Base Addr:%016lx Limit:%x\n",
+                 u1.gdte.AVL, u1.gdte.G,  
+                 (u64)((u64)u1.gdte.base0 | ((u64)u1.gdte.base1<<24)| upper),
+                 (u32)u1.gdte.limit0 | (u32)((u32)u1.gdte.limit1<<16));
+
+        } else if (acctype == 12) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.cgdte.offs0 | 
+                           (u64)((u64)u2.cgdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx\n", u2.cgdte.sel, addr64);
+        } else if (acctype == 14 || acctype == 15) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.igdte.offs0 | 
+                           (u64)((u64)u2.igdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx ist:%03x\n", u2.igdte.sel, addr64,
+                 u2.igdte.ist);
+        } else 
+            kdbp(" Error: Unrecongized type:%lx\n", acctype);
     }
     return KDB_CPU_MAIN_KDB;
 }
@@ -2781,6 +2812,7 @@ kdb_cmdf_mmu(int argc, const char **argv
     kdbp("CONFIG_PAGING_LEVELS:%d\n", CONFIG_PAGING_LEVELS);
     kdbp("__HYPERVISOR_COMPAT_VIRT_START: %lx\n", 
          (ulong)__HYPERVISOR_COMPAT_VIRT_START);
+    kdbp("&MPT[0] == %016lx\n", &machine_to_phys_mapping[0]);
 
     kdbp("\nFIRST_RESERVED_GDT_PAGE: %x\n", FIRST_RESERVED_GDT_PAGE);
     kdbp("FIRST_RESERVED_GDT_ENTRY: %lx\n", (ulong)FIRST_RESERVED_GDT_ENTRY);
@@ -2794,11 +2826,17 @@ kdb_cmdf_mmu(int argc, const char **argv
         kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(compat_gdt_table, cpu));
     }
     kdbp("\n");
+    kdbp("  Per cpu tss:\n");
+    for_each_online_cpu(cpu) {
+        struct tss_struct *tssp = &per_cpu(init_tss, cpu);
+        kdbp("\tcpu:%d  tss:%p (rsp0:%016lx)\n", cpu, tssp, tssp->rsp0);
+    }
 #ifdef USER_MAPPINGS_ARE_GLOBAL
     kdbp("USER_MAPPINGS_ARE_GLOBAL is defined\n");
 #else
     kdbp("USER_MAPPINGS_ARE_GLOBAL is NOT defined\n");
 #endif
+    kdbp("\n");
     return KDB_CPU_MAIN_KDB;
 }
 
@@ -2873,8 +2911,8 @@ kdb_cmdf_p2m(int argc, const char **argv
     struct domain *dp;
     ulong gpfn;
 
-    if (argc < 3                                ||
-        (dp=kdb_strdomid2ptr(argv[1])) == NULL  ||
+    if (argc < 3                                   ||
+        (dp=kdb_strdomid2ptr(argv[1], 1)) == NULL  ||
         !kdb_str2ulong(argv[2], &gpfn)) {
 
         return kdb_usgf_p2m();
@@ -3408,6 +3446,7 @@ kdb_cmdf_info(int argc, const char **arg
         kdbp(" CONFIG_PAGING_ASSISTANCE");
 #endif
     kdbp("\n");
+    kdbp("MAX_VIRT_CPUS:$%d  MAX_HVM_VCPUS:$%d\n", MAX_VIRT_CPUS,MAX_HVM_VCPUS);
     kdbp("NR_EVENT_CHANNELS: $%d\n", NR_EVENT_CHANNELS);
     kdbp("NR_EVTCHN_BUCKETS: $%d\n", NR_EVTCHN_BUCKETS);
 
diff -r f2cf898c7ff8 xen/kdb/kdb_io.c
--- a/xen/kdb/kdb_io.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/kdb/kdb_io.c	Thu Nov 17 15:37:30 2011 -0800
@@ -39,7 +39,7 @@ kdb_key_valid(int key)
 {
     /* note: isspace() is more than ' ', hence we don't use it here */
     if (isalnum(key) || key == ' ' || key == K_BACKSPACE || key == '\n' ||
-        key == '?' || key == K_UNDERSCORE || key == '=')
+        key == '?' || key == K_UNDERSCORE || key == '=' || key == '!')
             return 1;
     return 0;
 }
diff -r f2cf898c7ff8 xen/kdb/kdbmain.c
--- a/xen/kdb/kdbmain.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/kdb/kdbmain.c	Thu Nov 17 15:37:30 2011 -0800
@@ -258,7 +258,7 @@ kdb_check_dbtrap(kdb_reason_t *reasp, in
                 KDBGP("ccpu:%d trapcpu:%d\n", ccpu, a_trap_cpu);
                 kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
                 *reasp = KDB_REASON_PAUSE_IPI;
-                regs->eflags &= ~X86_EFLAGS_TF;
+                regs->eflags &= ~X86_EFLAGS_TF;  /* hvm: exit handler ss = 0 */
                 kdb_init_cpu = -1;
             } else {
                 kdb_end_session(ccpu, regs);
@@ -364,7 +364,10 @@ kdbmain(kdb_reason_t reason, struct cpu_
             }
         } else if (rc == 2) {        /* one of ours but condition not met */
                 kdb_begin_session();
-                regs->eflags |= X86_EFLAGS_TF;  
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
                 kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
                 goto out;
         }
@@ -401,7 +404,10 @@ kdbmain(kdb_reason_t reason, struct cpu_
             if (!cpus_empty(kdb_cpu_traps)) {
                 /* execute current instruction without 0xcc */
                 kdb_dbg_prnt_ctrps("nempty:", ccpu);
-                regs->eflags |= X86_EFLAGS_TF;  
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
                 kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
                 goto out;
             }
@@ -415,7 +421,10 @@ kdbmain(kdb_reason_t reason, struct cpu_
         if (kdb_swbp_exists()) {
             if (reason == KDB_REASON_BPEXCP) {
                 /* do delayed install */
-                regs->eflags |= X86_EFLAGS_TF;  
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
                 kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
                 goto out;
             } 
@@ -518,9 +527,7 @@ kdb_handle_trap_entry(int vector, struct
          * depending on the hardware. Also, for now assume it's fatal */
         KDBGP("kdbtrp:ccpu:%d vec:%d\n", ccpu, vector);
         rc = kdbmain_fatal(regs, TRAP_nmi);
-    } else {
-        KDBGP("kdbtrp: unhandled trap:ccpu:%d vec:%d\n", ccpu, vector);
-    }
+    } 
     return rc;
 }
 
@@ -659,7 +666,7 @@ kdb_gettrapname(int trapno)
 
 #define KDBTRCMAX 1       /* set this to max number of recs to trace. each rec 
                            * is 32 bytes */
-volatile int kdb_trcon=0; /* turn tracing ON: set here or via the trcon cmd */
+volatile int kdb_trcon=1; /* turn tracing ON: set here or via the trcon cmd */
 
 typedef struct {
     union {
diff -r f2cf898c7ff8 xen/kdb/x86/udis86-1.7/kdb_dis.c
--- a/xen/kdb/x86/udis86-1.7/kdb_dis.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/kdb/x86/udis86-1.7/kdb_dis.c	Thu Nov 17 15:37:30 2011 -0800
@@ -65,11 +65,13 @@ kdb_prnt_addr2sym(domid_t domid, kdbva_t
         p = kdb_guest_addr2sym(addr, domid, &offs);
     } else
         symbols_lookup(addr, &sz, &offs, buf);
+
     snprintf(pbuf, 150, "%s%s+%lx", prefix, p, offs);
     if (*nl != '\n')
         kdbp("%-30s%s", pbuf, nl);  /* prints more than 30 if needed */
     else
         kdbp("%s%s", pbuf, nl);
+
 }
 
 static int

--MP_/R.1sMt_LjPbCVVbgRW8Pwbf
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--MP_/R.1sMt_LjPbCVVbgRW8Pwbf--


From xen-devel-bounces@lists.xensource.com Thu Nov 17 23:39:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 17 Nov 2011 23:39:37 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRBYM-0002tk-QK
	for archives@lists.xen.org; Thu, 17 Nov 2011 23:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRBXy-0001HM-45; Thu, 17 Nov 2011 15:39:10 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRBXl-0001Fj-NU
	for Xen-devel@lists.xensource.com; Thu, 17 Nov 2011 15:38:59 -0800
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1321573131!2012017!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14120 invoked from network); 17 Nov 2011 23:38:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Nov 2011 23:38:53 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAHNcl4b014166
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Nov 2011 23:38:47 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAHNcjWY015860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 17 Nov 2011 23:38:46 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAHNceEY005255; Thu, 17 Nov 2011 17:38:40 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 15:38:39 -0800
Date: Thu, 17 Nov 2011 15:38:38 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] HYBRID: PV in HVM container
Message-ID: <20111117153838.04e15aa9@mantra.us.oracle.com>
In-Reply-To: <20110727185828.55099372@mantra.us.oracle.com>
References: <20110627122404.23d2d0ce@mantra.us.oracle.com>
	<20110630185431.3ea308c6@mantra.us.oracle.com>
	<20110708185301.4b040a21@mantra.us.oracle.com>
	<20110727185828.55099372@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="MP_/R.1sMt_LjPbCVVbgRW8Pwbf"
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4EC59B08.00B0,ss=1,re=-15.000,fgs=0
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--MP_/R.1sMt_LjPbCVVbgRW8Pwbf
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Alright, got hybrid with EPT numbers in now from my prototype, it needs
some perf work.. 

Attaching the diffs from my prototype. Linux: 2.6.39. Xen 4.0.2.


Processor, Processes - times in microseconds - smaller is better
------------------------------------------------------------------------------
Host                 OS  Mhz null null      open slct sig  sig  fork exec sh  
                             call  I/O stat clos TCP  inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
PV        Linux 2.6.39f 2639 0.65 0.88 2.14 4.59 3.77 0.79 3.62 535. 1294 3308
Hybrid    Linux 2.6.39f 2639 0.13 0.21 0.89 1.96 3.08 0.24 1.10 529. 1294 3246
HVM       Linux 2.6.39f 2639 0.12 0.21 0.64 1.76 3.04 0.24 3.37 113. 354. 1324
Baremetal Linux 2.6.39+ 2649 0.13 0.23 0.74 1.93 3.46 0.28 1.58 127. 386. 1434
HYB-EPT   Linux 2.6.39f 2639 0.13 0.21 0.68 1.95 3.04 0.25 3.09 145. 452. 1542


Basic integer operations - times in nanoseconds - smaller is better
-------------------------------------------------------------------
Host                 OS  intgr intgr  intgr  intgr  intgr  
                          bit   add    mul    div    mod   
--------- ------------- ------ ------ ------ ------ ------ 
PV        Linux 2.6.39f 0.3800 0.0100 0.1700 9.1000 9.0400
Hybrid    Linux 2.6.39f 0.3800 0.0100 0.1700 9.1100 9.0300
HVM       Linux 2.6.39f 0.3800 0.0100 0.1700 9.1100 9.0600
Baremetal Linux 2.6.39+ 0.3800 0.0100 0.1700 9.0600 8.9800
HYB-EPT   Linux 2.6.39f 0.3800 0.0100 0.1700 9.1200 9.0500


Basic float operations - times in nanoseconds - smaller is better
-----------------------------------------------------------------
Host                 OS  float  float  float  float
                         add    mul    div    bogo
--------- ------------- ------ ------ ------ ------ 
PV        Linux 2.6.39f 1.1300 1.5200 5.6200 5.2900
Hybrid    Linux 2.6.39f 1.1300 1.5200 5.6300 5.2900
HVM       Linux 2.6.39f 1.1400 1.5200 5.6300 5.3000
Baremetal Linux 2.6.39+ 1.1300 1.5100 5.6000 5.2700
HYB-EPT   Linux 2.6.39f 1.1400 1.5200 5.6300 5.3000


Basic double operations - times in nanoseconds - smaller is better
------------------------------------------------------------------
Host                 OS  double double double double
                         add    mul    div    bogo
--------- ------------- ------  ------ ------ ------ 
PV        Linux 2.6.39f 1.1300 1.9000 8.6400 8.3200
Hybrid    Linux 2.6.39f 1.1400 1.9000 8.6600 8.3200
HVM       Linux 2.6.39f 1.1400 1.9000 8.6600 8.3300
Baremetal Linux 2.6.39+ 1.1300 1.8900 8.6100 8.2800
HYB-EPT   Linux 2.6.39f 1.1400 1.9000 8.6600 8.3300


Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
                         ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
PV        Linux 2.6.39f 5.2800 5.7600 6.3600 6.3200 7.3600 6.69000 7.46000
Hybrid    Linux 2.6.39f 4.9200 4.9300 5.2200 5.7600 6.9600 6.12000 7.31000
HVM       Linux 2.6.39f 1.3100 1.2200 1.6200 1.9200 3.2600 2.23000 3.48000
Baremetal Linux 2.6.39+ 1.5500 1.4100 2.0600 2.2500 3.3900 2.44000 3.38000
HYB-EPT   Linux 2.6.39f 3.2000 3.6100 4.1700 4.3600 6.1200 4.81000 6.20000


*Local* Communication latencies in microseconds - smaller is better
---------------------------------------------------------------------
Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
                        ctxsw       UNIX         UDP         TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
PV        Linux 2.6.39f 5.280  16.6 21.3  25.9  33.7  34.7  41.8  87.
Hybrid    Linux 2.6.39f 4.920  11.2 14.4  19.6  26.1  27.5  32.9  71.
HVM       Linux 2.6.39f 1.310 4.416 6.15 9.386  14.8  15.8  20.1  45.
Baremetal Linux 2.6.39+ 1.550 4.625 7.34  14.3  19.8  21.4  26.4  66.
HYB-EPT   Linux 2.6.39f 3.200 8.669 15.3  17.5  23.5  25.1  30.4  66.


File & VM system latencies in microseconds - smaller is better
-------------------------------------------------------------------------------
Host                 OS   0K File      10K File     Mmap    Prot   Page   100fd
                        Create Delete Create Delete Latency Fault  Fault  selct
--------- ------------- ------ ------ ------ ------ ------- ----- ------- -----
PV        Linux 2.6.39f                               24.0K 0.746 3.55870 2.184
Hybrid    Linux 2.6.39f                               24.6K 0.238 4.00100 1.480
HVM       Linux 2.6.39f                              4716.0 0.202 0.96600 1.468
Baremetal Linux 2.6.39+                              6898.0 0.325 0.93610 1.620
HYB-EPT   Linux 2.6.39f                              5321.0 0.347 1.19510 1.480


*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
PV        Linux 2.6.39f 1661 2081 1041 3293.3 5528.3 3106.6 2800.0 4472 5633.
Hybrid    Linux 2.6.39f 1974 2450 1183 3481.5 5529.6 3114.9 2786.6 4470 5672.
HVM       Linux 2.6.39f 3232 2929 1622 3541.3 5527.5 3077.1 2765.6 4453 5634.
Baremetal Linux 2.6.39+ 3320 2800 1666 3523.6 5578.9 3147.0 2841.6 4541 5752.
HYB-EPT   Linux 2.6.39f 2104 2480 1231 3451.5 5503.4 3067.7 2751.0 4438 5636.


Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
------------------------------------------------------------------------------
Host                 OS   Mhz   L1 $   L2 $    Main mem    Rand mem    Guesses
--------- -------------   ---   ----   ----    --------    --------    -------
PV        Linux 2.6.39f  2639 1.5160 5.9170   29.7        97.5
Hybrid    Linux 2.6.39f  2639 1.5170 7.5000   29.7        97.4
HVM       Linux 2.6.39f  2639 1.5190 4.0210   29.8       105.4
Baremetal Linux 2.6.39+  2649 1.5090 3.8370   29.2        78.0
HYB-EPT   Linux 2.6.39f  2639 1.5180 4.0060   29.9       109.9


thanks,
Mukesh


On Wed, 27 Jul 2011 18:58:28 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> Hi folks,
> 
> Well, I did some benchmarking and found interesting results. Following
> runs are on a westmere with 2 sockets and 10GB RAM.  Xen was booted
> with maxcpus=2 and entire RAM. All guests were started with 1vcpu and
> 2GB RAM. dom0 started with 1 vcpu and 704MB. Baremetal was booted
> with 2GB and 1 cpu.  HVM guest has EPT enabled. HT is on.
> 
> So, unless the NUMA'ness interfered with results (using some memory
> on remote socket), it appears HVM does very well. To the point that it
> seems a hybrid is not going to be worth it. I am currently running
> tests on a single socket system just to be sure.
> 
> I am attaching my diff's in case any one wants to see what I did. I
> used xen 4.0.2 and linux 2.6.39. 
> 
> thanks,
> Mukesh
> 
>                  L M B E N C H  3 . 0   S U M M A R Y
> 
> Processor, Processes - times in microseconds - smaller is better
> ------------------------------------------------------------------------------

--MP_/R.1sMt_LjPbCVVbgRW8Pwbf
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=lin.diff

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 615e188..7791d31 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -1,7 +1,7 @@
 menu "Kernel hacking"
 
 config TRACE_IRQFLAGS_SUPPORT
-	def_bool y
+	def_bool n
 
 source "lib/Kconfig.debug"
 
diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 91f3e08..bdd7022 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -238,7 +238,8 @@ extern const char * const x86_power_flags[32];
 #define cpu_has_fpu		boot_cpu_has(X86_FEATURE_FPU)
 #define cpu_has_vme		boot_cpu_has(X86_FEATURE_VME)
 #define cpu_has_de		boot_cpu_has(X86_FEATURE_DE)
-#define cpu_has_pse		boot_cpu_has(X86_FEATURE_PSE)
+#define cpu_has_pse		0
+/* #define cpu_has_pse		boot_cpu_has(X86_FEATURE_PSE) */
 #define cpu_has_tsc		boot_cpu_has(X86_FEATURE_TSC)
 #define cpu_has_pae		boot_cpu_has(X86_FEATURE_PAE)
 #define cpu_has_pge		boot_cpu_has(X86_FEATURE_PGE)
diff --git a/arch/x86/include/asm/hypervisor.h b/arch/x86/include/asm/hypervisor.h
index 7a15153..f0bbb51 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -49,6 +49,7 @@ extern const struct hypervisor_x86 *x86_hyper;
 extern const struct hypervisor_x86 x86_hyper_vmware;
 extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
 extern const struct hypervisor_x86 x86_hyper_xen_hvm;
+extern const struct hypervisor_x86 x86_hyper_xen_hybrid;
 
 static inline bool hypervisor_x2apic_available(void)
 {
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 8095f86..5ec8dbb 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -37,6 +37,7 @@ static const __initconst struct hypervisor_x86 * const hypervisors[] =
 #ifdef CONFIG_XEN_PVHVM
 	&x86_hyper_xen_hvm,
 #endif
+        &x86_hyper_xen_hybrid,
 };
 
 const struct hypervisor_x86 *x86_hyper;
diff --git a/arch/x86/pci/direct.c b/arch/x86/pci/direct.c
index bd33620..89bfe86 100644
--- a/arch/x86/pci/direct.c
+++ b/arch/x86/pci/direct.c
@@ -282,6 +282,9 @@ int __init pci_direct_probe(void)
 {
 	struct resource *region, *region2;
 
+        if (xen_hybrid_domain())
+                return 0;
+
 	if ((pci_probe & PCI_PROBE_CONF1) == 0)
 		goto type2;
 	region = request_region(0xCF8, 8, "PCI conf1");
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index e3c6a06..53ceae0 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -110,7 +110,7 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
  *
  * 0: not available, 1: available
  */
-static int have_vcpu_info_placement = 1;
+static int have_vcpu_info_placement = 0;
 
 static void clamp_max_cpus(void)
 {
@@ -195,6 +195,13 @@ static void __init xen_banner(void)
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
+
+        if (xen_hybrid_domain()) {
+	        printk(KERN_INFO "MUK: is MUK HYBRID domain....");
+		if (xen_feature(XENFEAT_auto_translated_physmap))
+                	printk(KERN_INFO "with EPT...");
+        	printk(KERN_INFO "\n");
+        }
 }
 
 static __read_mostly unsigned int cpuid_leaf1_edx_mask = ~0;
@@ -222,8 +229,10 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		maskebx = 0;
 		break;
 	}
-
-	asm(XEN_EMULATE_PREFIX "cpuid"
+        if (xen_hybrid_domain()) {
+                native_cpuid(ax, bx, cx, dx);
+        } else
+	        asm(XEN_EMULATE_PREFIX "cpuid"
 		: "=a" (*ax),
 		  "=b" (*bx),
 		  "=c" (*cx),
@@ -244,6 +253,7 @@ static __init void xen_init_cpuid_mask(void)
 		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
 		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
 		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
+                  (1 << X86_FEATURE_PSE)  |  /* disable 2M pages */
 		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
 
 	if (!xen_initial_domain())
@@ -393,6 +403,10 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
 		make_lowmem_page_readonly(virt);
 	}
 
+        if (xen_hybrid_domain()) {
+                native_load_gdt(dtr);
+                return;
+        }
 	if (HYPERVISOR_set_gdt(frames, size / sizeof(struct desc_struct)))
 		BUG();
 }
@@ -431,6 +445,10 @@ static __init void xen_load_gdt_boot(const struct desc_ptr *dtr)
 		frames[f] = mfn;
 	}
 
+        if (xen_hybrid_domain()) {
+                native_load_gdt(dtr);
+                return;
+        }
 	if (HYPERVISOR_set_gdt(frames, size / sizeof(struct desc_struct)))
 		BUG();
 }
@@ -849,9 +867,11 @@ void xen_setup_shared_info(void)
 
 		HYPERVISOR_shared_info =
 			(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
-	} else
+	} else {
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
+        	return;
+	}
 
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
@@ -944,6 +964,71 @@ static const struct pv_init_ops xen_init_ops __initdata = {
 	.patch = xen_patch,
 };
 
+extern void native_iret(void);
+extern void native_irq_enable_sysexit(void);
+extern void native_usergs_sysret32(void);
+extern void native_usergs_sysret64(void);
+
+static const struct pv_cpu_ops xen_hybrid_cpu_ops __initdata = {
+	.cpuid = xen_cpuid,
+
+	.set_debugreg = xen_set_debugreg,
+	.get_debugreg = xen_get_debugreg,
+
+	.clts = xen_clts,
+
+	.read_cr0 = xen_read_cr0,
+	.write_cr0 = xen_write_cr0,
+
+	.read_cr4 = native_read_cr4,
+	.read_cr4_safe = native_read_cr4_safe,
+	.write_cr4 = native_write_cr4,
+
+	.wbinvd = native_wbinvd,
+
+	.read_msr = native_read_msr_safe,
+	.write_msr = native_write_msr_safe,
+	.read_tsc = native_read_tsc,
+	.read_pmc = native_read_pmc,
+
+	.iret = native_iret,
+	.irq_enable_sysexit = native_irq_enable_sysexit,
+#ifdef CONFIG_X86_64
+	.usergs_sysret32 = native_usergs_sysret32,
+	.usergs_sysret64 = native_usergs_sysret64,
+#endif
+
+	.load_tr_desc = native_load_tr_desc,
+	.set_ldt = native_set_ldt,
+	.load_gdt = native_load_gdt,
+	.load_idt = native_load_idt,
+	.load_tls = native_load_tls,
+#ifdef CONFIG_X86_64
+	.load_gs_index = native_load_gs_index,
+#endif
+
+	.alloc_ldt = paravirt_nop,
+	.free_ldt = paravirt_nop,
+
+	.store_gdt = native_store_gdt,
+	.store_idt = native_store_idt,
+	.store_tr = native_store_tr,
+
+	.write_ldt_entry = native_write_ldt_entry,
+	.write_gdt_entry = native_write_gdt_entry,
+	.write_idt_entry = native_write_idt_entry,
+	.load_sp0 = native_load_sp0,
+
+	.set_iopl_mask = native_set_iopl_mask,
+	.io_delay = xen_io_delay,
+
+	/* Xen takes care of %gs when switching to usermode for us */
+	.swapgs = native_swapgs,
+
+	.start_context_switch = paravirt_start_context_switch,
+	.end_context_switch = xen_end_context_switch,
+};
+
 static const struct pv_cpu_ops xen_cpu_ops __initdata = {
 	.cpuid = xen_cpuid,
 
@@ -1010,6 +1095,11 @@ static const struct pv_apic_ops xen_apic_ops __initdata = {
 #endif
 };
 
+static void __init xen_hybrid_override_autox_cpu_ops(void)
+{
+        pv_cpu_ops.cpuid = xen_cpuid;
+}
+
 static void xen_reboot(int reason)
 {
 	struct sched_shutdown r = { .reason = reason };
@@ -1071,6 +1161,10 @@ static const struct machine_ops __initdata xen_machine_ops = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+        if (xen_hybrid_domain()) {
+                switch_to_new_gdt(0);
+                return;
+        }
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1093,14 +1187,22 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
 
+        if (xen_hybrid_domain()) {
+	        if (xen_feature(XENFEAT_auto_translated_physmap))
+                        xen_hybrid_override_autox_cpu_ops();
+                else
+	        	pv_cpu_ops = xen_hybrid_cpu_ops;
+        } else
+	        pv_cpu_ops = xen_cpu_ops;
+
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
 	x86_init.oem.banner = xen_banner;
@@ -1129,7 +1231,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
 
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
@@ -1214,10 +1315,12 @@ asmlinkage void __init xen_start_kernel(void)
 	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
 	 * which pokes 0xcf8 port.
 	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+        if (!xen_hybrid_domain()) {
+	        set_iopl.iopl = 1;
+	        rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+	        if (rc != 0)
+		        xen_raw_printk("physdev_op failed %d\n", rc);
+        }
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1388,3 +1491,29 @@ const __refconst struct hypervisor_x86 x86_hyper_xen_hvm = {
 };
 EXPORT_SYMBOL(x86_hyper_xen_hvm);
 #endif
+
+static bool __init xen_hybrid_platform_detect(void)
+{
+        return (xen_hybrid_domain());
+}
+
+
+const int xen_hybrid_rsvd_top_frames = 48;    /* 32 for grant + future */
+static void __init xen_hybrid_guest_init(void)
+{
+        if (xen_feature(XENFEAT_hvm_callback_vector))
+                xen_have_vector_callback = 1;
+
+	/* xen_hvm_smp_init(); */   /* <======================== */
+
+        /* adjust iomem_resource set in setup_arch() and reserve some frames
+         * for grant table etc for us */
+        iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1
+                             - xen_hybrid_rsvd_top_frames;
+}
+
+const __refconst struct hypervisor_x86 x86_hyper_xen_hybrid = {
+	.name			= "Xen Hybrid",
+	.detect			= xen_hybrid_platform_detect,
+	.init_platform		= xen_hybrid_guest_init,
+};
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 6a6fe89..1a161db 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -100,6 +100,9 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_irq_enable);
 
 static void xen_safe_halt(void)
 {
+        if (xen_hybrid_domain())
+                local_irq_enable();
+
 	/* Blocking includes an implicit local_irq_enable(). */
 	if (HYPERVISOR_sched_op(SCHEDOP_block, NULL) != 0)
 		BUG();
@@ -113,6 +116,19 @@ static void xen_halt(void)
 		xen_safe_halt();
 }
 
+static const struct pv_irq_ops xen_hybrid_irq_ops __initdata = {
+        .save_fl = __PV_IS_CALLEE_SAVE(native_save_fl),
+        .restore_fl = __PV_IS_CALLEE_SAVE(native_restore_fl),
+        .irq_disable = __PV_IS_CALLEE_SAVE(native_irq_disable),
+        .irq_enable = __PV_IS_CALLEE_SAVE(native_irq_enable),
+
+	.safe_halt = xen_safe_halt,
+	.halt = xen_halt,
+#ifdef CONFIG_X86_64
+	.adjust_exception_frame = paravirt_nop,
+#endif
+};
+
 static const struct pv_irq_ops xen_irq_ops __initdata = {
 	.save_fl = PV_CALLEE_SAVE(xen_save_fl),
 	.restore_fl = PV_CALLEE_SAVE(xen_restore_fl),
@@ -128,6 +144,9 @@ static const struct pv_irq_ops xen_irq_ops __initdata = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+        if (xen_hybrid_domain())
+	        pv_irq_ops = xen_hybrid_irq_ops;
+        else
+	        pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index f298bd7..2c50554 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1294,6 +1294,10 @@ static void xen_post_allocator_init(void);
 static __init void xen_pagetable_setup_done(pgd_t *base)
 {
 	xen_setup_shared_info();
+
+        if (xen_feature(XENFEAT_auto_translated_physmap))
+        	return;
+
 	xen_post_allocator_init();
 }
 
@@ -1685,15 +1689,18 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
-	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+                return;
+        }
+        if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
 
-static __init void xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
+static __init int xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
 {
-	unsigned pmdidx, pteidx;
-	unsigned ident_pte;
-	unsigned long pfn;
+	unsigned int pmdidx, pteidx;
+	unsigned int ident_pte;
+	unsigned int long pfn;
 
 	level1_ident_pgt = extend_brk(sizeof(pte_t) * LEVEL1_IDENT_ENTRIES,
 				      PAGE_SIZE);
@@ -1728,13 +1735,10 @@ static __init void xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
 			pte_page[pteidx] = pte;
 		}
 	}
-
-	for (pteidx = 0; pteidx < ident_pte; pteidx += PTRS_PER_PTE)
-		set_page_prot(&level1_ident_pgt[pteidx], PAGE_KERNEL_RO);
-
-	set_page_prot(pmd, PAGE_KERNEL_RO);
+        return ident_pte;
 }
 
+/* TBD: DON'T NEED THIS FOR HYBRID EPT???? */
 void __init xen_setup_machphys_mapping(void)
 {
 	struct xen_machphys_mapping mapping;
@@ -1775,6 +1779,7 @@ static void convert_pfn_mfn(void *v)
 __init pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd,
 					 unsigned long max_pfn)
 {
+        unsigned int pteidx, ident_ptes;
 	pud_t *l3;
 	pmd_t *l2;
 
@@ -1787,11 +1792,12 @@ __init pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd,
 	/* Zap identity mapping */
 	init_level4_pgt[0] = __pgd(0);
 
-	/* Pre-constructed entries are in pfn, so convert to mfn */
-	convert_pfn_mfn(init_level4_pgt);
-	convert_pfn_mfn(level3_ident_pgt);
-	convert_pfn_mfn(level3_kernel_pgt);
-
+	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+	        /* Pre-constructed entries are in pfn, so convert to mfn */
+	        convert_pfn_mfn(init_level4_pgt);
+	        convert_pfn_mfn(level3_ident_pgt);
+	        convert_pfn_mfn(level3_kernel_pgt);
+        }
 	l3 = m2v(pgd[pgd_index(__START_KERNEL_map)].pgd);
 	l2 = m2v(l3[pud_index(__START_KERNEL_map)].pud);
 
@@ -1803,7 +1809,11 @@ __init pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd,
 	memcpy(level2_fixmap_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);
 
 	/* Set up identity map */
-	xen_map_identity_early(level2_ident_pgt, max_pfn);
+	ident_ptes = xen_map_identity_early(level2_ident_pgt, max_pfn);
+
+	for (pteidx = 0; pteidx < ident_ptes; pteidx += PTRS_PER_PTE)
+		set_page_prot(&level1_ident_pgt[pteidx], PAGE_KERNEL_RO);
+	set_page_prot(level2_ident_pgt, PAGE_KERNEL_RO);
 
 	/* Make pagetable pieces RO */
 	set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
@@ -1813,12 +1823,14 @@ __init pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd,
 	set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
 	set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);
 
-	/* Pin down new L4 */
-	pin_pagetable_pfn(MMUEXT_PIN_L4_TABLE,
-			  PFN_DOWN(__pa_symbol(init_level4_pgt)));
+	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* Pin down new L4 */
+		pin_pagetable_pfn(MMUEXT_PIN_L4_TABLE,
+			  	PFN_DOWN(__pa_symbol(init_level4_pgt)));
 
-	/* Unpin Xen-provided one */
-	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
+		/* Unpin Xen-provided one */
+		pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
+	}
 
 	/* Switch over */
 	pgd = init_level4_pgt;
@@ -1828,9 +1840,13 @@ __init pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd,
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(pgd));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+                native_write_cr3(__pa(pgd));
+        } else {
+	        xen_mc_batch();
+	        __xen_write_cr3(true, __pa(pgd));
+	        xen_mc_issue(PARAVIRT_LAZY_CPU);
+        }
 
 	memblock_x86_reserve_range(__pa(xen_start_info->pt_base),
 		      __pa(xen_start_info->pt_base +
@@ -2117,14 +2133,26 @@ static const struct pv_mmu_ops xen_mmu_ops __initdata = {
 	.set_fixmap = xen_set_fixmap,
 };
 
+static __init void xen_hyb_override_mmu_ops(void)
+{
+        pv_mmu_ops.read_cr2 = native_read_cr2;
+        pv_mmu_ops.write_cr2 = native_write_cr2;
+}
+
 void __init xen_init_mmu_ops(void)
 {
+	memset(dummy_mapping, 0xff, PAGE_SIZE);
+	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+        	return;
+
 	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
-	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
-	pv_mmu_ops = xen_mmu_ops;
+        pv_mmu_ops = xen_mmu_ops;
 
-	memset(dummy_mapping, 0xff, PAGE_SIZE);
+        if (xen_hybrid_domain())      /* hybrid without EPT, ie, pv paging. */
+		xen_hyb_override_mmu_ops();
 }
 
 /* Protected by xen_reservation_lock. */
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index adaf127..9a2a576 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -391,12 +391,9 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+static __init void xen_nonhybrid_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
-	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		HYPERVISOR_vm_assist(VMASST_CMD_enable,
@@ -415,6 +412,14 @@ void __init xen_arch_setup(void)
 		disable_acpi();
 	}
 #endif
+}
+
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
+	if (!xen_hybrid_domain())
+                xen_nonhybrid_arch_setup();
 
 	memcpy(boot_command_line, xen_start_info->cmd_line,
 	       MAX_GUEST_CMDLINE > COMMAND_LINE_SIZE ?
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3061244..0b0464e 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -195,10 +195,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+	   	   old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
diff --git a/drivers/tty/serial/8250.c b/drivers/tty/serial/8250.c
index 6611535..1a3ebbc 100644
--- a/drivers/tty/serial/8250.c
+++ b/drivers/tty/serial/8250.c
@@ -3294,6 +3294,9 @@ static int __init serial8250_init(void)
 {
 	int ret;
 
+	if (xen_hybrid_domain())
+		return -ENODEV;
+
 	if (nr_uarts > UART_NR)
 		nr_uarts = UART_NR;
 
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 14e2d99..631a019 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -99,7 +99,7 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	if (!xen_pv_domain() || xen_hybrid_domain())
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 33167b4..69bad2e 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1632,5 +1632,7 @@ void __init xen_init_IRQ(void)
 		irq_ctx_init(smp_processor_id());
 		if (xen_initial_domain())
 			xen_setup_pirqs();
+                if (xen_hybrid_domain())
+		        xen_callback_vector();
 	}
 }
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 3745a31..ff57b55 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -46,6 +46,8 @@
 #include <xen/interface/memory.h>
 #include <asm/xen/hypercall.h>
 
+#include <asm/page.h>
+#include <asm/tlbflush.h>
 #include <asm/pgtable.h>
 #include <asm/sync_bitops.h>
 
@@ -503,6 +505,56 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static int ptefunc(pte_t *pte, pgtable_t table, unsigned long addr, void *data)
+{
+        pte_t pteval = pfn_pte(virt_to_pfn(addr), PAGE_KERNEL);
+        set_pte(pte, pteval);
+	return 0;
+}
+
+
+extern int xen_hybrid_rsvd_top_frames;
+static int gnttab_map_hyb_autox(unsigned int start_idx, unsigned int end_idx)
+{
+	struct xen_add_to_physmap xatp;
+	unsigned int i = end_idx;
+	unsigned int nr_gframes = end_idx + 1;
+	int rc = 0;
+
+        if (shared == NULL) {
+                unsigned long numgf = gnttab_max_grant_frames();
+                unsigned long maxp = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
+                unsigned long gntpfn = (maxp >> PAGE_SHIFT) - numgf;
+
+                BUG_ON(numgf > xen_hybrid_rsvd_top_frames);
+                shared = __va(gntpfn << PAGE_SHIFT);
+        }
+
+        /* will reinsert entries in shared[0...n-1], but its OK */
+        rc = apply_to_page_range(&init_mm, shared, 
+                                 PAGE_SIZE*nr_gframes, ptefunc, NULL);
+        BUG_ON(rc);
+
+	/*
+	 * Loop backwards, so that the first hypercall has the largest
+	 * index, ensuring that the table will grow only once.
+	 */
+	do {
+		xatp.domid = DOMID_SELF;
+		xatp.idx = i;
+		xatp.space = XENMAPSPACE_grant_table;
+		xatp.gpfn = (virt_to_pfn(shared)) + i;
+		rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+		if (rc != 0) {
+			printk(KERN_WARNING
+			     "grant table add_to_physmap failed, err=%d\n", rc);
+			break;
+		}
+	} while (i-- > start_idx);
+
+        return rc;
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
@@ -510,6 +562,9 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
+        if (xen_hybrid_autoxlate_domain())
+        	return gnttab_map_hyb_autox(start_idx, end_idx);
+
 	if (xen_hvm_domain()) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index 7397695..2429d0e 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -737,7 +737,13 @@ static int __init xenbus_init(void)
 
 		xen_store_interface = mfn_to_virt(xen_store_mfn);
 	} else {
-		if (xen_hvm_domain()) {
+		if (xen_hybrid_autoxlate_domain()) {
+                	xen_store_evtchn = xen_start_info->store_evtchn;
+			xen_store_mfn = xen_start_info->store_mfn;  /* pfn */
+			xen_store_interface = __va(xen_store_mfn<<PAGE_SHIFT);
+			xenstored_ready = 1;
+
+		} else if (xen_hvm_domain()) {
 			uint64_t v = 0;
 			err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
 			if (err)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index ee048e7..0758b26 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -1,6 +1,8 @@
 #ifndef __KERNEL_PRINTK__
 #define __KERNEL_PRINTK__
 
+extern void mukchk(unsigned long);
+
 extern const char linux_banner[];
 extern const char linux_proc_banner[];
 
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index b33257b..805eb60 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -452,6 +452,7 @@ struct start_info {
 /* These flags are passed in the 'flags' field of start_info_t. */
 #define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
 #define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
+#define SIF_IS_HYBRID     (1<<3)  /* Is it a PV running in HVM container? */
 
 typedef uint64_t cpumap_t;
 
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a164024..0c3fca1 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -18,7 +18,11 @@ extern enum xen_domain_type xen_domain_type;
 				 xen_domain_type == XEN_PV_DOMAIN)
 #define xen_hvm_domain()	(xen_domain() &&			\
 				 xen_domain_type == XEN_HVM_DOMAIN)
-
+/* xen_pv_domain check is necessary as start_info ptr is null in HVM */
+#define xen_hybrid_domain()     (xen_pv_domain () &&                    \
+                                 (xen_start_info->flags & SIF_IS_HYBRID))
+#define xen_hybrid_autoxlate_domain() (xen_hybrid_domain() &&  \
+                                 (xen_feature(XENFEAT_auto_translated_physmap)))
 #ifdef CONFIG_XEN_DOM0
 #include <xen/interface/xen.h>
 #include <asm/xen/hypervisor.h>

--MP_/R.1sMt_LjPbCVVbgRW8Pwbf
Content-Type: text/x-patch
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen.diff

diff -r f2cf898c7ff8 tools/debugger/gdbsx/xg/xg_main.c
--- a/tools/debugger/gdbsx/xg/xg_main.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/debugger/gdbsx/xg/xg_main.c	Thu Nov 17 15:37:30 2011 -0800
@@ -80,6 +80,7 @@ int xgtrc_on = 0;
 struct xen_domctl domctl;         /* just use a global domctl */
 
 static int     _hvm_guest;        /* hvm guest? 32bit HVMs have 64bit context */
+static int     _hybrid_guest;
 static domid_t _dom_id;           /* guest domid */
 static int     _max_vcpu_id;      /* thus max_vcpu_id+1 VCPUs */
 static int     _dom0_fd;          /* fd of /dev/privcmd */
@@ -308,6 +309,8 @@ xg_attach(int domid, int guest_bitness)
 
     _max_vcpu_id = domctl.u.getdomaininfo.max_vcpu_id;
     _hvm_guest = (domctl.u.getdomaininfo.flags & XEN_DOMINF_hvm_guest);
+    _hybrid_guest = (domctl.u.getdomaininfo.flags & XEN_DOMINF_hybrid_guest);
+
     return _max_vcpu_id;
 }
 
@@ -368,7 +371,7 @@ _change_TF(vcpuid_t which_vcpu, int gues
     int sz = sizeof(anyc);
 
     /* first try the MTF for hvm guest. otherwise do manually */
-    if (_hvm_guest) {
+    if (_hvm_guest || _hybrid_guest) {
         domctl.u.debug_op.vcpu = which_vcpu;
         domctl.u.debug_op.op = setit ? XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_ON :
                                        XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_OFF;
diff -r f2cf898c7ff8 tools/libxc/Makefile
--- a/tools/libxc/Makefile	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxc/Makefile	Thu Nov 17 15:37:30 2011 -0800
@@ -58,7 +58,7 @@ GUEST_SRCS-$(CONFIG_IA64)    += xc_dom_i
 -include $(XEN_TARGET_ARCH)/Makefile
 
 CFLAGS   += -Werror -Wmissing-prototypes
-CFLAGS   += $(INCLUDES) -I. -I../xenstore -I../include
+CFLAGS   += $(INCLUDES) -I. -I../xenstore -I../include -g -O0
 
 # Needed for posix_fadvise64() in xc_linux.c
 CFLAGS-$(CONFIG_Linux) += -D_GNU_SOURCE
diff -r f2cf898c7ff8 tools/libxc/xc_dom.h
--- a/tools/libxc/xc_dom.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxc/xc_dom.h	Thu Nov 17 15:37:30 2011 -0800
@@ -110,6 +110,9 @@ struct xc_dom_image {
     struct xc_dom_arch *arch_hooks;
     /* allocate up to virt_alloc_end */
     int (*allocate) (struct xc_dom_image * dom, xen_vaddr_t up_to);
+
+    /* hybrid flags */
+    char hybrid_hap;
 };
 
 /* --- pluggable kernel loader ------------------------------------- */
@@ -241,7 +244,8 @@ static inline void *xc_dom_vaddr_to_ptr(
 
 static inline int xc_dom_feature_translated(struct xc_dom_image *dom)
 {
-    return elf_xen_feature_get(XENFEAT_auto_translated_physmap, dom->f_active);
+    return(dom->hybrid_hap || 
+           elf_xen_feature_get(XENFEAT_auto_translated_physmap, dom->f_active));
 }
 
 static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t pfn)
diff -r f2cf898c7ff8 tools/libxc/xc_dom_x86.c
--- a/tools/libxc/xc_dom_x86.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxc/xc_dom_x86.c	Thu Nov 17 15:37:30 2011 -0800
@@ -372,7 +372,8 @@ static int setup_pgtables_x86_64(struct 
         pgpfn = (addr - dom->parms.virt_base) >> PAGE_SHIFT_X86;
         l1tab[l1off] =
             pfn_to_paddr(xc_dom_p2m_guest(dom, pgpfn)) | L1_PROT;
-        if ( (addr >= dom->pgtables_seg.vstart) && 
+        if ( !dom->hybrid_hap                   &&
+             (addr >= dom->pgtables_seg.vstart) && 
              (addr < dom->pgtables_seg.vend) )
             l1tab[l1off] &= ~_PAGE_RW; /* page tables are r/o */
         if ( l1off == (L1_PAGETABLE_ENTRIES_X86_64 - 1) )
@@ -819,7 +820,7 @@ int arch_setup_bootlate(struct xc_dom_im
         }
 
         /* Map grant table frames into guest physmap. */
-        for ( i = 0; ; i++ )
+        for ( i = 0; !dom->hybrid_hap ; i++ )
         {
             xatp.domid = dom->guest_domid;
             xatp.space = XENMAPSPACE_grant_table;
diff -r f2cf898c7ff8 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxl/Makefile	Thu Nov 17 15:37:30 2011 -0800
@@ -12,7 +12,7 @@ XLUMAJOR = 1.0
 XLUMINOR = 0
 
 CFLAGS += -Werror
-CFLAGS += -I. -fPIC
+CFLAGS += -I. -fPIC -g -O0
 CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore)
 
 LIBS = $(LDFLAGS_libxenctrl) $(LDFLAGS_libxenguest) $(LDFLAGS_libxenstore)
diff -r f2cf898c7ff8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxl/libxl.c	Thu Nov 17 15:37:30 2011 -0800
@@ -99,6 +99,7 @@ int libxl_domain_make(struct libxl_ctx *
     if (!uuid_string) return ERROR_NOMEM;
 
     flags = info->hvm ? XEN_DOMCTL_CDF_hvm_guest : 0;
+    flags |= info->hybrid ? XEN_DOMCTL_CDF_hybrid_guest : 0;
     flags |= info->hap ? XEN_DOMCTL_CDF_hap : 0;
     flags |= info->oos ? 0 : XEN_DOMCTL_CDF_oos_off;
     *domid = -1;
diff -r f2cf898c7ff8 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxl/libxl.h	Thu Nov 17 15:37:30 2011 -0800
@@ -78,6 +78,7 @@ const libxl_version_info* libxl_get_vers
 
 typedef struct {
     bool hvm;
+    bool hybrid;
     bool hap;
     bool oos;
     int ssidref;
@@ -97,6 +98,8 @@ typedef struct {
     uint32_t shadow_memkb;
     const char *kernel;
     int hvm;
+    int hybrid;
+    int hybrid_hap;
     union {
         struct {
             bool pae;
diff -r f2cf898c7ff8 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Nov 17 15:37:30 2011 -0800
@@ -69,7 +69,7 @@ int build_pre(struct libxl_ctx *ctx, uin
             (info->max_memkb + info->u.pv.slack_memkb));
     xc_domain_set_tsc_info(ctx->xch, domid, info->tsc_mode, 0, 0, 0);
 
-    if (info->hvm) {
+    if (info->hvm || info->hybrid) {
         unsigned long shadow;
         shadow = (info->shadow_memkb + 1023) / 1024;
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
@@ -139,13 +139,16 @@ int build_pv(struct libxl_ctx *ctx, uint
 {
     struct xc_dom_image *dom;
     int ret;
-    int flags = 0;
+    int flags;               /* start info flags: start_info_x86_64() */
+
+    flags = info->hybrid ? SIF_IS_HYBRID : 0;
 
     dom = xc_dom_allocate(info->u.pv.cmdline, info->u.pv.features);
     if (!dom) {
         XL_LOG_ERRNO(ctx, XL_LOG_ERROR, "xc_dom_allocate failed");
         return -1;
     }
+    dom->hybrid_hap = info->hybrid_hap ? 1 : 0;
     ret = xc_dom_linux_build(ctx->xch, dom, domid, info->target_memkb / 1024,
                                   info->kernel, info->u.pv.ramdisk, flags,
                                   state->store_port, &state->store_mfn,
diff -r f2cf898c7ff8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 17 15:37:30 2011 -0800
@@ -197,6 +197,11 @@ static void init_build_info(libxl_domain
     } else {
         b_info->u.pv.slack_memkb = 8 * 1024;
     }
+    if (c_info->hybrid) {
+        b_info->hybrid = 1;
+        if (c_info->hap)
+            b_info->hybrid_hap = 1;
+    }
 }
 
 static void init_dm_info(libxl_device_model_info *dm_info,
@@ -469,6 +474,11 @@ static void parse_config_data(const char
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->hvm = 1;
 
+    c_info->hybrid = 0;
+    if (!xlu_cfg_get_long (config, "hybrid", &l))
+        c_info->hybrid = 1;
+
+    c_info->hap = 0;
     if (!xlu_cfg_get_long (config, "hap", &l))
         c_info->hap = l;
 
diff -r f2cf898c7ff8 xen/arch/x86/debug.c
--- a/xen/arch/x86/debug.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/debug.c	Thu Nov 17 15:37:30 2011 -0800
@@ -43,7 +43,6 @@ extern void kdbp(const char *fmt, ...);
 typedef unsigned long dbgva_t;
 typedef unsigned char dbgbyte_t;
 
-
 /* Returns: mfn for the given (hvm guest) vaddr */
 static unsigned long 
 dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int toaddr)
@@ -55,6 +54,7 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct dom
     DBGP2("vaddr:%lx domid:%d\n", vaddr, dp->domain_id);
 
     gfn = paging_gva_to_gfn(dp->vcpu[0], vaddr, &pfec);
+
     if ( gfn == INVALID_GFN )
     {
         DBGP2("kdb:bad gfn from gva_to_gfn\n");
@@ -200,7 +200,7 @@ dbg_rw_guest_mem(dbgva_t addr, dbgbyte_t
 
         pagecnt = min_t(long, PAGE_SIZE - (addr & ~PAGE_MASK), len);
 
-        mfn = (dp->is_hvm
+        mfn = ( (is_hvm_domain(dp) || is_hyb_hap_domain(dp))
                ? dbg_hvm_va2mfn(addr, dp, toaddr)
                : dbg_pv_va2mfn(addr, dp, pgd3));
         if ( mfn == INVALID_MFN ) 
@@ -225,7 +225,6 @@ dbg_rw_guest_mem(dbgva_t addr, dbgbyte_t
         buf += pagecnt;
         len -= pagecnt;
     }
-
     return len;
 }
 
diff -r f2cf898c7ff8 xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/domain.c	Thu Nov 17 15:37:30 2011 -0800
@@ -160,6 +160,7 @@ void dump_pageframe_info(struct domain *
         spin_unlock(&d->page_alloc_lock);
     }
 
+    KASSERT(!is_hybrid_domain(d) );
     if ( is_hvm_domain(d) )
     {
         p2m_pod_dump_data(d);
@@ -354,7 +355,7 @@ int vcpu_initialise(struct vcpu *v)
 
     paging_vcpu_init(v);
 
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
     {
         if ( (rc = hvm_vcpu_initialise(v)) != 0 )
             return rc;
@@ -410,7 +411,7 @@ int arch_domain_create(struct domain *d,
     int rc = -ENOMEM;
 
     d->arch.hvm_domain.hap_enabled =
-        is_hvm_domain(d) &&
+        (is_hvm_or_hyb_domain(d)) &&
         hvm_funcs.hap_supported &&
         (domcr_flags & DOMCRF_hap);
     d->arch.hvm_domain.mem_sharing_enabled = 0;
@@ -508,7 +509,7 @@ int arch_domain_create(struct domain *d,
         mce_init_msr(d);
     }
 
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
     {
         if ( (rc = hvm_domain_initialise(d)) != 0 )
         {
@@ -562,7 +563,7 @@ void arch_domain_destroy(struct domain *
     unsigned int i;
 #endif
 
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         hvm_domain_destroy(d);
 
     pci_release_devices(d);
@@ -608,6 +609,8 @@ unsigned long pv_guest_cr4_fixup(unsigne
     return (hv_cr4 & hv_cr4_mask) | (guest_cr4 & ~hv_cr4_mask);
 }
 
+extern void hybrid_update_cr3(struct vcpu *);
+
 /* This is called by arch_final_setup_guest and do_boot_vcpu */
 int arch_set_info_guest(
     struct vcpu *v, vcpu_guest_context_u c)
@@ -628,7 +631,7 @@ int arch_set_info_guest(
 #endif
     flags = c(flags);
 
-    if ( !is_hvm_vcpu(v) )
+    if ( !is_hvm_or_hyb_domain(d) )
     {
         if ( !compat )
         {
@@ -677,7 +680,7 @@ int arch_set_info_guest(
     v->fpu_initialised = !!(flags & VGCF_I387_VALID);
 
     v->arch.flags &= ~TF_kernel_mode;
-    if ( (flags & VGCF_in_kernel) || is_hvm_vcpu(v)/*???*/ )
+    if ( (flags & VGCF_in_kernel) || is_hvm_or_hyb_vcpu(v) )
         v->arch.flags |= TF_kernel_mode;
 
     if ( !compat )
@@ -689,18 +692,13 @@ int arch_set_info_guest(
 
     v->arch.guest_context.user_regs.eflags |= 2;
 
-    if ( is_hvm_vcpu(v) )
+    if ( is_hvm_or_hyb_vcpu(v) )
     {
         hvm_set_info_guest(v);
-        goto out;
+        if ( !is_hybrid_vcpu(v) ) 
+            goto out;
     }
 
-    /* Only CR0.TS is modifiable by guest or admin. */
-    v->arch.guest_context.ctrlreg[0] &= X86_CR0_TS;
-    v->arch.guest_context.ctrlreg[0] |= read_cr0() & ~X86_CR0_TS;
-
-    init_int80_direct_trap(v);
-
     /* IOPL privileges are virtualised. */
     v->arch.iopl = (v->arch.guest_context.user_regs.eflags >> 12) & 3;
     v->arch.guest_context.user_regs.eflags &= ~X86_EFLAGS_IOPL;
@@ -708,38 +706,50 @@ int arch_set_info_guest(
     /* Ensure real hardware interrupts are enabled. */
     v->arch.guest_context.user_regs.eflags |= X86_EFLAGS_IF;
 
-    cr4 = v->arch.guest_context.ctrlreg[4];
-    v->arch.guest_context.ctrlreg[4] = cr4 ? pv_guest_cr4_fixup(cr4) :
-        real_cr4_to_pv_guest_cr4(mmu_cr4_features);
-
     memset(v->arch.guest_context.debugreg, 0,
            sizeof(v->arch.guest_context.debugreg));
     for ( i = 0; i < 8; i++ )
         (void)set_debugreg(v, i, c(debugreg[i]));
 
+    if ( !is_hybrid_vcpu(v) )
+    {
+        /* Only CR0.TS is modifiable by guest or admin. */
+        v->arch.guest_context.ctrlreg[0] &= X86_CR0_TS;
+        v->arch.guest_context.ctrlreg[0] |= read_cr0() & ~X86_CR0_TS;
+
+        init_int80_direct_trap(v);
+
+        cr4 = v->arch.guest_context.ctrlreg[4];
+        v->arch.guest_context.ctrlreg[4] = cr4 ? pv_guest_cr4_fixup(cr4) :
+            real_cr4_to_pv_guest_cr4(mmu_cr4_features);
+    }
+
     if ( v->is_initialised )
         goto out;
 
     if ( v->vcpu_id == 0 )
         d->vm_assist = c(vm_assist);
 
-    if ( !compat )
-        rc = (int)set_gdt(v, c.nat->gdt_frames, c.nat->gdt_ents);
+    if ( !is_hybrid_vcpu(v) )
+    {
+        if ( !compat )
+            rc = (int)set_gdt(v, c.nat->gdt_frames, c.nat->gdt_ents);
 #ifdef CONFIG_COMPAT
-    else
-    {
-        unsigned long gdt_frames[ARRAY_SIZE(c.cmp->gdt_frames)];
-        unsigned int i, n = (c.cmp->gdt_ents + 511) / 512;
+        else
+        {
+            unsigned long gdt_frames[ARRAY_SIZE(c.cmp->gdt_frames)];
+            unsigned int i, n = (c.cmp->gdt_ents + 511) / 512;
 
-        if ( n > ARRAY_SIZE(c.cmp->gdt_frames) )
-            return -EINVAL;
-        for ( i = 0; i < n; ++i )
-            gdt_frames[i] = c.cmp->gdt_frames[i];
-        rc = (int)set_gdt(v, gdt_frames, c.cmp->gdt_ents);
+            if ( n > ARRAY_SIZE(c.cmp->gdt_frames) )
+                return -EINVAL;
+            for ( i = 0; i < n; ++i )
+                gdt_frames[i] = c.cmp->gdt_frames[i];
+            rc = (int)set_gdt(v, gdt_frames, c.cmp->gdt_ents);
+        }
+#endif
+        if ( rc != 0 )
+            return rc;
     }
-#endif
-    if ( rc != 0 )
-        return rc;
 
     if ( !compat )
     {
@@ -751,10 +761,17 @@ int arch_set_info_guest(
               : !get_page_and_type(mfn_to_page(cr3_pfn), d,
                                    PGT_base_page_table)) )
         {
-            destroy_gdt(v);
+            if ( !is_hybrid_vcpu(v) )
+                destroy_gdt(v);
             return -EINVAL;
         }
 
+        if (is_hybrid_vcpu(v) && paging_mode_enabled(d))
+        {
+            v->arch.cr3 = cr3_pfn;
+            v->arch.hvm_vcpu.guest_cr[3] = c.nat->ctrlreg[3];
+        }
+
         v->arch.guest_table = pagetable_from_pfn(cr3_pfn);
 
 #ifdef __x86_64__
@@ -782,7 +799,8 @@ int arch_set_info_guest(
         }
         else if ( !(flags & VGCF_in_kernel) )
         {
-            destroy_gdt(v);
+            if ( !is_hybrid_vcpu(v) )
+                destroy_gdt(v);
             return -EINVAL;
         }
     }
@@ -818,6 +836,13 @@ int arch_set_info_guest(
         paging_update_paging_modes(v);
 
     update_cr3(v);
+    if (is_hybrid_vcpu(v))
+    {
+        if (paging_mode_enabled(d))   /* HAP is enabled */
+            hvm_update_host_cr3(v);   /* GUEST_CR3 updated in update_cr3() */
+        else
+            hybrid_update_cr3(v);
+    }
 
  out:
     if ( flags & VGCF_online )
@@ -1347,10 +1372,10 @@ static void update_runstate_area(struct 
 
 static inline int need_full_gdt(struct vcpu *v)
 {
-    return (!is_hvm_vcpu(v) && !is_idle_vcpu(v));
+    return (!is_hvm_vcpu(v) && !is_idle_vcpu(v) && !is_hybrid_vcpu(v)); 
 }
 
-static void __context_switch(void)
+static noinline void __context_switch(void)
 {
     struct cpu_user_regs *stack_regs = guest_cpu_user_regs();
     unsigned int          cpu = smp_processor_id();
@@ -1475,18 +1500,30 @@ void context_switch(struct vcpu *prev, s
         /* Re-enable interrupts before restoring state which may fault. */
         local_irq_enable();
 
-        if ( !is_hvm_vcpu(next) )
+        if ( !is_hvm_or_hyb_vcpu(next) )
         {
             load_LDT(next);
             load_segments(next);
         }
     }
-
     context_saved(prev);
 
     if (prev != next)
         update_runstate_area(next);
 
+#if 0
+{
+struct vcpu_runstate_info rst; 
+struct vcpu_runstate_info *tp = 
+        (struct vcpu_runstate_info *)(runstate_guest(next)).p;
+if (tp)
+    copy_from_guest(&rst, runstate_guest(next), 1);
+
+kdbtrc(0xeeffee, rst.state, (ulong)next, (ulong)tp, 
+       (ulong)next->runstate.state);
+}
+#endif
+
     schedule_tail(next);
     BUG();
 }
@@ -2034,7 +2071,7 @@ int domain_relinquish_resources(struct d
         BUG();
     }
 
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         hvm_domain_relinquish_resources(d);
 
     return 0;
@@ -2115,7 +2152,7 @@ void vcpu_mark_events_pending(struct vcp
     if ( already_pending )
         return;
 
-    if ( is_hvm_vcpu(v) )
+    if ( is_hvm_or_hyb_vcpu(v) ) 
         hvm_assert_evtchn_irq(v);
     else
         vcpu_kick(v);
diff -r f2cf898c7ff8 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/domctl.c	Thu Nov 17 15:37:30 2011 -0800
@@ -466,6 +466,7 @@ long arch_do_domctl(
             goto sethvmcontext_out;
 
         ret = -EINVAL;
+        KASSERT(!is_hybrid_domain(d));
         if ( !is_hvm_domain(d) ) 
             goto sethvmcontext_out;
 
@@ -503,6 +504,7 @@ long arch_do_domctl(
             goto gethvmcontext_out;
 
         ret = -EINVAL;
+        KASSERT(!is_hybrid_domain(d));
         if ( !is_hvm_domain(d) ) 
             goto gethvmcontext_out;
 
@@ -558,6 +560,7 @@ long arch_do_domctl(
             goto gethvmcontext_partial_out;
 
         ret = -EINVAL;
+        KASSERT(!is_hybrid_domain(d));
         if ( !is_hvm_domain(d) ) 
             goto gethvmcontext_partial_out;
 
@@ -719,6 +722,7 @@ long arch_do_domctl(
         case XEN_DOMCTL_SENDTRIGGER_POWER:
         {
             ret = -EINVAL;
+            KASSERT(!is_hybrid_domain(d));
             if ( is_hvm_domain(d) ) 
             {
                 ret = 0;
@@ -731,6 +735,7 @@ long arch_do_domctl(
         {
             extern void hvm_acpi_sleep_button(struct domain *d);
 
+            KASSERT(!is_hybrid_domain(d));
             ret = -EINVAL;
             if ( is_hvm_domain(d) ) 
             {
@@ -1285,7 +1290,7 @@ long arch_do_domctl(
             goto debug_op_out;
 
         ret = -EINVAL;
-        if ( !is_hvm_domain(d))
+        if ( !is_hvm_or_hyb_domain(d))
             goto debug_op_out;
 
         ret = hvm_debug_op(v, domctl->u.debug_op.op);
@@ -1465,8 +1470,9 @@ void arch_get_info_guest(struct vcpu *v,
         c(flags |= VGCF_i387_valid);
     if ( !test_bit(_VPF_down, &v->pause_flags) )
         c(flags |= VGCF_online);
-
-    if ( is_hvm_vcpu(v) )
+        
+    /* HYBRID TDB: debugregs? Verify this again */
+    if ( is_hvm_or_hyb_vcpu(v) )
     {
         struct segment_register sreg;
         memset(c.nat->ctrlreg, 0, sizeof(c.nat->ctrlreg));
diff -r f2cf898c7ff8 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Thu Nov 17 15:37:30 2011 -0800
@@ -227,6 +227,9 @@ void hvm_do_resume(struct vcpu *v)
 {
     ioreq_t *p;
 
+    if (is_hybrid_vcpu(v))
+        return;
+
     pt_restore_timer(v);
 
     /* NB. Optimised for common case (p->state == STATE_IOREQ_NONE). */
@@ -367,16 +370,21 @@ int hvm_domain_initialise(struct domain 
         return -EINVAL;
     }
 
-    spin_lock_init(&d->arch.hvm_domain.pbuf_lock);
     spin_lock_init(&d->arch.hvm_domain.irq_lock);
-    spin_lock_init(&d->arch.hvm_domain.uc_lock);
-
-    INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
-    spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
-
     hvm_init_guest_time(d);
-
-    d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
+    
+    if (is_hybrid_domain(d)) {
+        if (!d->arch.hvm_domain.hap_enabled)
+            return 0;
+    } else {
+        spin_lock_init(&d->arch.hvm_domain.pbuf_lock);
+        spin_lock_init(&d->arch.hvm_domain.uc_lock);
+
+        INIT_LIST_HEAD(&d->arch.hvm_domain.msixtbl_list);
+        spin_lock_init(&d->arch.hvm_domain.msixtbl_list_lock);
+
+        d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
+    }
 
     hvm_init_cacheattr_region_list(d);
 
@@ -384,20 +392,22 @@ int hvm_domain_initialise(struct domain 
     if ( rc != 0 )
         goto fail1;
 
-    vpic_init(d);
-
-    rc = vioapic_init(d);
-    if ( rc != 0 )
-        goto fail1;
-
-    stdvga_init(d);
-
-    rtc_init(d);
-
-    hvm_init_ioreq_page(d, &d->arch.hvm_domain.ioreq);
-    hvm_init_ioreq_page(d, &d->arch.hvm_domain.buf_ioreq);
-
-    register_portio_handler(d, 0xe9, 1, hvm_print_line);
+    if (!is_hybrid_domain(d)) {
+        vpic_init(d);
+
+        rc = vioapic_init(d);
+        if ( rc != 0 )
+            goto fail1;
+
+        stdvga_init(d);
+
+        rtc_init(d);
+
+        hvm_init_ioreq_page(d, &d->arch.hvm_domain.ioreq);
+        hvm_init_ioreq_page(d, &d->arch.hvm_domain.buf_ioreq);
+
+        register_portio_handler(d, 0xe9, 1, hvm_print_line);
+    }
 
     rc = hvm_funcs.domain_initialise(d);
     if ( rc != 0 )
@@ -406,9 +416,11 @@ int hvm_domain_initialise(struct domain 
     return 0;
 
  fail2:
-    rtc_deinit(d);
-    stdvga_deinit(d);
-    vioapic_deinit(d);
+    if (!is_hybrid_domain(d)) {
+        rtc_deinit(d);
+        stdvga_deinit(d);
+        vioapic_deinit(d);
+    }
  fail1:
     hvm_destroy_cacheattr_region_list(d);
     return rc;
@@ -418,6 +430,10 @@ extern void msixtbl_pt_cleanup(struct do
 
 void hvm_domain_relinquish_resources(struct domain *d)
 {
+    if (is_hybrid_domain(d)) {
+        printk("MUK: WARN: Hybrid ignoring pit/pmtimer/hpet cleanup\n");
+        return;
+    }
     hvm_destroy_ioreq_page(d, &d->arch.hvm_domain.ioreq);
     hvm_destroy_ioreq_page(d, &d->arch.hvm_domain.buf_ioreq);
 
@@ -436,10 +452,14 @@ void hvm_domain_relinquish_resources(str
 void hvm_domain_destroy(struct domain *d)
 {
     hvm_funcs.domain_destroy(d);
+
+    if (is_hybrid_domain(d))
+        return;
+
+    hvm_destroy_cacheattr_region_list(d);
     rtc_deinit(d);
     stdvga_deinit(d);
     vioapic_deinit(d);
-    hvm_destroy_cacheattr_region_list(d);
 }
 
 static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
@@ -737,13 +757,25 @@ static int hvm_load_cpu_ctxt(struct doma
 HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt, hvm_load_cpu_ctxt,
                           1, HVMSR_PER_VCPU);
 
+static noinline int hybrid_vcpu_finish_init(struct vcpu *v)
+{
+    if ( v->vcpu_id == 0 )
+        hvm_set_guest_tsc(v, 0);
+
+    /* PV guests by default have a 100Hz ticker. */
+    v->periodic_period = MILLISECS(10);  /* ???? */
+
+    return 0;
+}
+
 int hvm_vcpu_initialise(struct vcpu *v)
 {
     int rc;
 
     hvm_asid_flush_vcpu(v);
 
-    if ( cpu_has_xsave )
+    /* HYBRID TBD: investigate xsave/xrestore for hybrid ??? */
+    if ( cpu_has_xsave && !is_hybrid_vcpu(v) )
     {
         /* XSAVE/XRSTOR requires the save area be 64-byte-boundary aligned. */
         void *xsave_area = _xmalloc(xsave_cntxt_size, 64);
@@ -755,12 +787,21 @@ int hvm_vcpu_initialise(struct vcpu *v)
         v->arch.hvm_vcpu.xfeature_mask = XSTATE_FP_SSE;
     }
 
-    if ( (rc = vlapic_init(v)) != 0 )
+    if ( !is_hybrid_vcpu(v) && ((rc = vlapic_init(v)) != 0) )
         goto fail1;
 
     if ( (rc = hvm_funcs.vcpu_initialise(v)) != 0 )
         goto fail2;
 
+    tasklet_init(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet,
+                 (void(*)(unsigned long))hvm_assert_evtchn_irq,
+                 (unsigned long)v);
+
+    v->arch.guest_context.user_regs.eflags = 2;
+
+    if (is_hybrid_vcpu(v))
+        return hybrid_vcpu_finish_init(v);
+
     /* Create ioreq event channel. */
     rc = alloc_unbound_xen_event_channel(v, 0);
     if ( rc < 0 )
@@ -780,12 +821,6 @@ int hvm_vcpu_initialise(struct vcpu *v)
     if ( rc != 0 )
         goto fail3;
 
-    tasklet_init(&v->arch.hvm_vcpu.assert_evtchn_irq_tasklet,
-                 (void(*)(unsigned long))hvm_assert_evtchn_irq,
-                 (unsigned long)v);
-
-    v->arch.guest_context.user_regs.eflags = 2;
-
     if ( v->vcpu_id == 0 )
     {
         /* NB. All these really belong in hvm_domain_initialise(). */
@@ -828,6 +863,8 @@ void hvm_vcpu_down(struct vcpu *v)
     struct domain *d = v->domain;
     int online_count = 0;
 
+printk("MUK: hvm_vcpu_down(): kdb trap\n");
+
     /* Doesn't halt us immediately, but we'll never return to guest context. */
     set_bit(_VPF_down, &v->pause_flags);
     vcpu_sleep_nosync(v);
@@ -2222,6 +2259,14 @@ static long hvm_vcpu_op(
     case VCPUOP_stop_singleshot_timer:
         rc = do_vcpu_op(cmd, vcpuid, arg);
         break;
+
+    case VCPUOP_is_up:
+    case VCPUOP_up:
+        if (is_hybrid_vcpu(current)) {
+            rc = do_vcpu_op(cmd, vcpuid, arg);
+            break;
+        }
+
     default:
         rc = -ENOSYS;
         break;
@@ -2292,11 +2337,17 @@ static long hvm_vcpu_op_compat32(
     return rc;
 }
 
-static hvm_hypercall_t *hvm_hypercall64_table[NR_hypercalls] = {
+hvm_hypercall_t *hvm_hypercall64_table[NR_hypercalls] = {
     [ __HYPERVISOR_memory_op ] = (hvm_hypercall_t *)hvm_memory_op,
     [ __HYPERVISOR_grant_table_op ] = (hvm_hypercall_t *)hvm_grant_table_op,
     [ __HYPERVISOR_vcpu_op ] = (hvm_hypercall_t *)hvm_vcpu_op,
+    HYPERCALL(set_debugreg),
+    HYPERCALL(multicall),
+    HYPERCALL(update_va_mapping),
     HYPERCALL(xen_version),
+    HYPERCALL(console_io),
+    HYPERCALL(vm_assist),
+    HYPERCALL(mmuext_op),
     HYPERCALL(event_channel_op),
     HYPERCALL(sched_op),
     HYPERCALL(set_timer_op),
@@ -2321,6 +2372,31 @@ static hvm_hypercall_t *hvm_hypercall32_
 
 #endif /* defined(__x86_64__) */
 
+/* Returns: 1 if hcall is valid, 0 otherwise. */
+static int hcall_valid(uint32_t eax)
+{
+#ifndef __x86_64__
+    if ( unlikely(eax >= NR_hypercalls) || !hvm_hypercall32_table[eax] )
+#else
+    if ( unlikely(eax >= NR_hypercalls) || !hvm_hypercall64_table[eax] ||
+        (!is_hybrid_vcpu(current) && 
+                   ( (eax==__HYPERVISOR_set_trap_table) ||
+                     (eax==__HYPERVISOR_set_debugreg) ||
+                     (eax==__HYPERVISOR_update_descriptor) ||
+                     (eax==__HYPERVISOR_multicall) ||
+                     (eax==__HYPERVISOR_update_va_mapping) ||
+                     (eax==__HYPERVISOR_console_io) ||
+                     (eax==__HYPERVISOR_set_segment_base) ||
+                     (eax==__HYPERVISOR_vm_assist) ||
+                     (eax==__HYPERVISOR_mmuext_op) ) )    ||
+        ((is_hybrid_vcpu(current) && hap_enabled(current->domain)) &&
+                     (eax==__HYPERVISOR_update_va_mapping)) )
+#endif
+        return 0;
+
+    return 1;
+}
+
 int hvm_do_hypercall(struct cpu_user_regs *regs)
 {
     struct vcpu *curr = current;
@@ -2349,8 +2425,7 @@ int hvm_do_hypercall(struct cpu_user_reg
     if ( (eax & 0x80000000) && is_viridian_domain(curr->domain) )
         return viridian_hypercall(regs);
 
-    if ( (eax >= NR_hypercalls) || !hvm_hypercall32_table[eax] )
-    {
+    if ( !hcall_valid(eax)) {
         regs->eax = -ENOSYS;
         return HVM_HCALL_completed;
     }
@@ -2734,12 +2809,46 @@ static int hvmop_flush_tlb_all(void)
     return 0;
 }
 
+static noinline long _do_hybrid_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
+{
+    long rc = -EINVAL;
+    struct xen_hvm_param a;
+    struct domain *d;
+
+    if (op == HVMOP_set_param) {
+        if ( copy_from_guest(&a, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(a.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if (a.index == HVM_PARAM_CALLBACK_IRQ) {
+            struct hvm_irq *hvm_irq = &d->arch.hvm_domain.irq;
+            uint64_t via = a.value;
+            uint8_t via_type = (uint8_t)(via >> 56) + 1;
+
+            if (via_type == HVMIRQ_callback_vector) {
+                hvm_irq->callback_via_type = HVMIRQ_callback_vector;
+                hvm_irq->callback_via.vector = (uint8_t)via;
+                rc = 0;
+            }
+        }
+    }
+    KASSERT(rc == 0);
+    return rc;
+}
+
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
 
 {
     struct domain *curr_d = current->domain;
     long rc = 0;
 
+    if (is_hybrid_domain(curr_d)) {
+        return (_do_hybrid_op(op, arg)); 
+    }
+
     switch ( op )
     {
     case HVMOP_set_param:
diff -r f2cf898c7ff8 xen/arch/x86/hvm/irq.c
--- a/xen/arch/x86/hvm/irq.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/irq.c	Thu Nov 17 15:37:30 2011 -0800
@@ -333,6 +333,9 @@ struct hvm_intack hvm_vcpu_has_pending_i
          && vcpu_info(v, evtchn_upcall_pending) )
         return hvm_intack_vector(plat->irq.callback_via.vector);
 
+    if (is_hybrid_vcpu(v))       /* Hybrid TBD: See NMI / MCE below */
+        return hvm_intack_none;
+
     if ( unlikely(v->nmi_pending) )
         return hvm_intack_nmi;
 
diff -r f2cf898c7ff8 xen/arch/x86/hvm/mtrr.c
--- a/xen/arch/x86/hvm/mtrr.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/mtrr.c	Thu Nov 17 15:37:30 2011 -0800
@@ -573,6 +573,7 @@ int32_t hvm_get_mem_pinned_cacheattr(
     uint32_t *type)
 {
     struct hvm_mem_pinned_cacheattr_range *range;
+    KASSERT(!is_hybrid_domain(d));
 
     *type = 0;
 
@@ -601,6 +602,8 @@ int32_t hvm_set_mem_pinned_cacheattr(
 {
     struct hvm_mem_pinned_cacheattr_range *range;
 
+    KASSERT(!is_hybrid_domain(d));
+
     if ( !((type == PAT_TYPE_UNCACHABLE) ||
            (type == PAT_TYPE_WRCOMB) ||
            (type == PAT_TYPE_WRTHROUGH) ||
diff -r f2cf898c7ff8 xen/arch/x86/hvm/svm/vmcb.c
--- a/xen/arch/x86/hvm/svm/vmcb.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/svm/vmcb.c	Thu Nov 17 15:37:30 2011 -0800
@@ -419,7 +419,7 @@ void kdb_dump_vmcb(domid_t did, int vid)
 
     rcu_read_lock(&domlist_read_lock);
     for_each_domain (dp) {
-        if (!is_hvm_domain(dp) || dp->is_dying)
+        if (!is_hvm_or_hyb_domain(dp) || dp->is_dying)
             continue;
         if (did != 0 && did != dp->domain_id)
             continue;
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vmx/Makefile
--- a/xen/arch/x86/hvm/vmx/Makefile	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/vmx/Makefile	Thu Nov 17 15:37:30 2011 -0800
@@ -5,3 +5,4 @@ obj-y += vmcs.o
 obj-y += vmx.o
 obj-y += vpmu.o
 obj-y += vpmu_core2.o
+obj-y += hybrid.o
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vmx/hybrid.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/arch/x86/hvm/vmx/hybrid.c	Thu Nov 17 15:37:30 2011 -0800
@@ -0,0 +1,576 @@
+#include <xen/config.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/trace.h>
+#include <xen/sched.h>
+#include <xen/irq.h>
+#include <xen/softirq.h>
+#include <xen/domain_page.h>
+#include <xen/hypercall.h>
+#include <xen/perfc.h>
+#include <asm/current.h>
+#include <asm/io.h>
+#include <asm/regs.h>
+#include <asm/cpufeature.h>
+#include <asm/processor.h>
+#include <asm/types.h>
+#include <asm/debugreg.h>
+#include <asm/msr.h>
+#include <asm/spinlock.h>
+#include <asm/paging.h>
+#include <asm/p2m.h>
+#include <asm/mem_sharing.h>
+#include <asm/hvm/emulate.h>
+#include <asm/hvm/hvm.h>
+#include <asm/hvm/support.h>
+#include <asm/hvm/vmx/vmx.h>
+#include <asm/hvm/vmx/vmcs.h>
+#include <public/sched.h>
+#include <public/hvm/ioreq.h>
+#include <asm/hvm/vpic.h>
+#include <asm/hvm/vlapic.h>
+#include <asm/x86_emulate.h>
+#include <asm/hvm/vpt.h>
+#include <public/hvm/save.h>
+#include <asm/hvm/trace.h>
+#include <asm/xenoprof.h>
+#include <asm/debugger.h>
+
+extern void vmx_do_extint(struct cpu_user_regs *regs);
+extern void vmx_do_cpuid(struct cpu_user_regs *regs);
+enum handler_return { HNDL_done, HNDL_unhandled, HNDL_exception_raised };
+extern enum handler_return long_mode_do_msr_read(struct cpu_user_regs *);
+extern enum handler_return long_mode_do_msr_write(struct cpu_user_regs *);
+
+
+volatile int mukprint=0, mukspin=1;
+#define dbgp0(...) dprintk(XENLOG_ERR, __VA_ARGS__);
+#define dbgp1(...) {(mukprint==1) ? kdbp(__VA_ARGS__):0;}
+#define dbgp2(...) {(mukprint==2) ? kdbp(__VA_ARGS__):0;}
+
+
+/* returns : 0 success */
+static noinline int vmxit_msr_read(struct cpu_user_regs *regs)
+{
+    uint inst_len = __get_instruction_length();
+    int rc=1;
+
+    u64 msr_content = 0;
+    switch (regs->ecx)
+    {
+        case MSR_IA32_MISC_ENABLE:
+        {
+            rdmsrl(MSR_IA32_MISC_ENABLE, msr_content);
+            msr_content |= MSR_IA32_MISC_ENABLE_BTS_UNAVAIL |
+                           MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL;
+            break;
+        }
+        default:
+        {
+            rdmsrl(regs->ecx, msr_content);
+            break;
+        }
+    }
+    regs->eax = (uint32_t)msr_content;
+    regs->edx = (uint32_t)(msr_content >> 32);
+    __update_guest_eip(inst_len);
+    rc = 0;
+
+#if 0
+    rc = (long_mode_do_msr_read(regs) == HNDL_done) ? 0 : 1;
+
+    if ( hvm_msr_read_intercept(regs) == X86EMUL_OKAY ) {
+        __update_guest_eip(inst_len);
+        rc = 0;
+    }
+#endif
+
+    dbgp1("msr read c:%lx a:%lx d:%lx RIP:%lx RSP:%lx\n", regs->ecx, regs->eax, 
+          regs->edx, vmr(GUEST_RIP), vmr(GUEST_RSP));
+    return rc;
+}
+
+/* for now just scratch the cpu since nothing else will run on it. eventually
+ * we need to save and restore these MSRs 
+ * returns : 0 success */
+static noinline int vmxit_msr_write(struct cpu_user_regs *regs)
+{
+    uint inst_len = __get_instruction_length();
+    int rc=1;
+#if 0
+    wrmsr(regs->ecx, regs->eax, regs->edx);
+
+    rc = (long_mode_do_msr_write(regs) == HNDL_done) ? 0 : 1;
+    return rc;
+#endif
+
+    dbgp1("MUK: msr write:0x%lx. eax:0x%lx edx:0x%lx\n", regs->ecx, 
+          regs->eax,regs->edx);
+    if ( hvm_msr_write_intercept(regs) == X86EMUL_OKAY ) {
+        __update_guest_eip(inst_len);
+        rc = 0;
+    }
+    return rc;
+}
+
+/* rc == 0: handled the MTF vmexit */
+static noinline int vmxit_mtf(struct cpu_user_regs *regs)
+{
+    struct vcpu *vp = current;
+    int rc=1, ss=vp->arch.hvm_vcpu.single_step; 
+
+    dbgp2("\n");
+    vp->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
+    __vmwrite(CPU_BASED_VM_EXEC_CONTROL, vp->arch.hvm_vmx.exec_control);
+    vp->arch.hvm_vcpu.single_step = 0;
+
+    /* kdb will set hvm_vcpu.single_step again if ss command */
+    if (kdb_handle_trap_entry(TRAP_debug, regs)) { /* TBD: ifdef KDB */
+        rc = 0;
+    } else if ( vp->domain->debugger_attached && ss ) {
+        domain_pause_for_debugger();
+        rc = 0;
+    }
+    return rc;
+}
+
+volatile int mukprintpf;
+/* rc == 0: handled the exception or NMI */
+static noinline int vmxit_exception(struct cpu_user_regs *regs)
+{
+    unsigned int vector = (__vmread(VM_EXIT_INTR_INFO)) & INTR_INFO_VECTOR_MASK;
+    int rc=1; 
+
+    dbgp2(" exception. vec:%d cs:%x\n", vector, vmr(GUEST_CS_SELECTOR));
+    if (vector == TRAP_debug) {
+        if (kdb_handle_trap_entry(vector, regs)) /* TBD: ifdef KDB */
+            rc = 0;
+        else {
+            domain_pause_for_debugger();
+            rc = 0;
+        }
+    } 
+    if (vector == TRAP_int3) {
+        int inst_len = __get_instruction_length();
+        __update_guest_eip(inst_len);
+
+        if (kdb_handle_trap_entry(vector, regs))
+            rc = 0;
+        else {
+            kdbp("[%d]MUK: domain pause for debugger\n", smp_processor_id());
+            current->arch.gdbsx_vcpu_event = TRAP_int3;
+            domain_pause_for_debugger();
+            rc = 0;
+        }
+    } 
+
+    if (vector == TRAP_no_device) {
+        vmx_fpu_dirty_intercept();
+        rc = 0;
+    }
+
+    if (vector == TRAP_gp_fault) {
+        regs->error_code = __vmread(VM_EXIT_INTR_ERROR_CODE);
+        kdbp("MUK: inject GP: errcode:0x%04x RIP:%016lx RSP:%016lx\n", 
+             regs->error_code, (ulong)vmr(GUEST_RIP), 
+             (ulong)vmr(GUEST_RSP));
+
+        kdb_trap_immed(KDB_TRAP_NONFATAL);
+        /* vmx_inject_hw_exception(TRAP_gp_fault, regs->error_code); */
+        rc = 1;
+    }
+
+    if (vector == TRAP_page_fault) {
+        extern int fixup_page_fault(unsigned long , struct cpu_user_regs *);
+        ulong eflags_sav = regs->eflags;
+        unsigned long va = __vmread(EXIT_QUALIFICATION);
+
+        regs->error_code = __vmread(VM_EXIT_INTR_ERROR_CODE);
+
+        if (mukprintpf)
+            kdbp("MUK:PF va:%016lx errcode:0x%04x RIP:%016lx RSP:%016lx", 
+                 va, regs->error_code, (ulong)vmr(GUEST_RIP), 
+                 (ulong)vmr(GUEST_RSP));
+
+        regs->eflags |= X86_EFLAGS_IF;
+        if (fixup_page_fault(va, regs) == 0) {
+            if (mukprintpf)
+                kdbp(" NOT ");
+            current->arch.hvm_vcpu.guest_cr[2] = va;
+            vmx_inject_hw_exception(TRAP_page_fault, regs->error_code);
+        }
+        regs->eflags = eflags_sav;
+        if (mukprintpf)
+            kdbp(" fixedup\n");
+        rc = 0;
+    }
+
+    /* TBD: call do_guest_trap() here */
+    if (rc)
+        kdbp("MUK: Unhandled trap vector:%d\n", vector);
+    return rc;
+}
+
+int vmxit_invlpg(void)
+{
+    int inst_len = __get_instruction_length();
+    ulong vaddr = __vmread(EXIT_QUALIFICATION);
+
+    KASSERT(hap_enabled(current->domain));
+    __update_guest_eip(inst_len);
+    vpid_sync_vcpu_gva(current, vaddr);
+    return 0;
+}
+
+/* rc == 0: success */
+static noinline int vmxit_vmcall(struct cpu_user_regs *regs)
+{
+    extern void *hvm_hypercall64_table[NR_hypercalls];
+    int rc, inst_len=__get_instruction_length();
+
+    if (regs->eax >= NR_hypercalls || hvm_hypercall64_table[regs->eax] ==NULL) {
+        kdbp("MUK: UnImplemented HCALL:%d\n", regs->eax);
+        return 1;
+    }
+    dbgp2("vmxit_vmcall: hcall eax:$%ld\n", regs->eax);
+    if (regs->eax == __HYPERVISOR_sched_op && regs->rdi == SCHEDOP_shutdown) {
+        kdbp("MUK: SCHEDOP_shutdown\n");
+        return 1;
+    }
+
+    rc = hvm_do_hypercall(regs);
+#if 0
+    extern int hybrid_do_hypercall(struct cpu_user_regs *regs);
+    rc = hybrid_do_hypercall(regs);
+#endif
+
+    if (rc != HVM_HCALL_preempted)
+        __update_guest_eip(inst_len);
+
+    if (rc != HVM_HCALL_completed) {
+        printk("hvm_do_hypercall rc:%d\n", rc);
+        rc = 1;
+    } else
+        rc = 0;
+
+    return rc;
+}
+
+static noinline uint64_t *get_gpr_ptr(struct cpu_user_regs *regs, uint gpr)
+{
+    switch (gpr)
+    {
+        case VMX_CONTROL_REG_ACCESS_GPR_EAX:
+            return &regs->eax;
+        case VMX_CONTROL_REG_ACCESS_GPR_ECX:
+            return &regs->ecx;
+        case VMX_CONTROL_REG_ACCESS_GPR_EDX:
+            return &regs->edx;
+        case VMX_CONTROL_REG_ACCESS_GPR_EBX:
+            return &regs->ebx;
+        case VMX_CONTROL_REG_ACCESS_GPR_ESP:
+            return &regs->esp;
+        case VMX_CONTROL_REG_ACCESS_GPR_EBP:
+            return &regs->ebp;
+        case VMX_CONTROL_REG_ACCESS_GPR_ESI:
+            return &regs->esi;
+        case VMX_CONTROL_REG_ACCESS_GPR_EDI:
+            return &regs->edi;
+        case VMX_CONTROL_REG_ACCESS_GPR_R8:
+            return &regs->r8;
+        case VMX_CONTROL_REG_ACCESS_GPR_R9:
+            return &regs->r9;
+        case VMX_CONTROL_REG_ACCESS_GPR_R10:
+            return &regs->r10;
+        case VMX_CONTROL_REG_ACCESS_GPR_R11:
+            return &regs->r11;
+        case VMX_CONTROL_REG_ACCESS_GPR_R12:
+            return &regs->r12;
+        case VMX_CONTROL_REG_ACCESS_GPR_R13:
+            return &regs->r13;
+        case VMX_CONTROL_REG_ACCESS_GPR_R14:
+            return &regs->r14;
+        case VMX_CONTROL_REG_ACCESS_GPR_R15:
+            return &regs->r15;
+        default:
+            return NULL;
+    }
+}
+/* rc == 0: success */
+static noinline int access_cr0(struct cpu_user_regs *regs, uint acc_typ, 
+                               uint64_t *regp)
+{
+    struct vcpu *vp = current;
+
+    if (acc_typ == VMX_CONTROL_REG_ACCESS_TYPE_MOV_TO_CR )
+    {
+        unsigned long new_cr0 = *regp;
+        unsigned long old_cr0 = __vmread(GUEST_CR0);
+
+        dbgp2("MUK:writing to CR0. RIP:%lx val:0x%lx\n", vmr(GUEST_RIP),*regp);
+        if ( (u32)new_cr0 != new_cr0 )
+        {
+            HVM_DBG_LOG(DBG_LEVEL_1, 
+                        "Guest setting upper 32 bits in CR0: %lx", new_cr0);
+            return 1;
+        }
+
+        new_cr0 &= ~HVM_CR0_GUEST_RESERVED_BITS;
+        /* ET is reserved and should be always be 1. */
+        new_cr0 |= X86_CR0_ET;
+
+        /* hybrid cannot change to real mode */
+        if ( (new_cr0 & (X86_CR0_PE|X86_CR0_PG)) != (X86_CR0_PG|X86_CR0_PE) ) {
+            kdbp("Guest attempting to turn off PE/PG. CR0:%lx\n", new_cr0);
+            return 1;
+        }
+        /* TS going from 1 to 0 */
+        if ( (old_cr0 & X86_CR0_TS) && ((new_cr0 & X86_CR0_TS)==0) )
+            vmx_fpu_enter(vp);
+
+        vp->arch.hvm_vcpu.hw_cr[0] = vp->arch.hvm_vcpu.guest_cr[0] = new_cr0;
+        __vmwrite(GUEST_CR0, new_cr0);
+        __vmwrite(CR0_READ_SHADOW, new_cr0);
+    } else {
+        *regp = __vmread(GUEST_CR0);
+    } 
+    return 0;
+}
+
+/* rc == 0: success */
+static noinline int access_cr4(struct cpu_user_regs *regs, uint acc_typ, 
+                               uint64_t *regp)
+{
+    if (acc_typ == VMX_CONTROL_REG_ACCESS_TYPE_MOV_TO_CR )
+    {
+        u64 old_cr4 = __vmread(GUEST_CR4);
+        /* kdbp("MUK:writing to CR4. val:0x%lx\n", *regp); */
+
+        if ( (old_cr4 ^ (*regp)) & (X86_CR4_PSE | X86_CR4_PGE | X86_CR4_PAE) )
+            vpid_sync_all();
+
+        /* hybrid_verify_cr4_wr(*regp)); */
+        __vmwrite(GUEST_CR4, *regp);
+    } else {
+        *regp = __vmread(GUEST_CR4);
+        kdbp("MUK: read cr4. val:0x%lx\n", *regp);
+    } 
+    return 0;
+}
+
+/* rc == 0: success */
+static noinline int vmxit_cr_access(struct cpu_user_regs *regs)
+{
+    unsigned long exit_qualification = __vmread(EXIT_QUALIFICATION);
+    uint inst_len = __get_instruction_length();
+    uint acc_typ = exit_qualification & VMX_CONTROL_REG_ACCESS_TYPE;
+    int cr, rc = 1;
+
+    switch ( acc_typ )
+    {
+        case VMX_CONTROL_REG_ACCESS_TYPE_MOV_TO_CR:
+        case VMX_CONTROL_REG_ACCESS_TYPE_MOV_FROM_CR:
+        {
+            uint gpr = exit_qualification & VMX_CONTROL_REG_ACCESS_GPR;
+            uint64_t *regp = get_gpr_ptr(regs, gpr);
+            cr = exit_qualification & VMX_CONTROL_REG_ACCESS_NUM;
+
+            if (regp == NULL)
+                break;
+
+            /* pl don't embed switch statements */
+            if (cr == 0)
+                rc = access_cr0(regs, acc_typ, regp);
+            else if (cr == 4) 
+                rc = access_cr4(regs, acc_typ, regp);
+
+            if (rc == 0)
+                __update_guest_eip(inst_len);
+            break;
+        }
+        case VMX_CONTROL_REG_ACCESS_TYPE_CLTS:
+        {
+#if 0
+            unsigned long cr0 = __vmread(GUEST_CR0);
+            cr0 &= ~X86_CR0_TS;
+#endif
+            struct vcpu *vp = current;
+            unsigned long cr0 = vp->arch.hvm_vcpu.guest_cr[0] & ~X86_CR0_TS;
+            vp->arch.hvm_vcpu.hw_cr[0] = vp->arch.hvm_vcpu.guest_cr[0] = cr0;
+            vmx_fpu_enter(vp);
+            __vmwrite(GUEST_CR0, cr0);
+            __vmwrite(CR0_READ_SHADOW, cr0);
+            __update_guest_eip(inst_len);
+            rc = 0;
+        }
+    }
+    return rc;
+}
+
+#if 0
+/* emulate write_cr3(read_cr3()) in guest. */
+static noinline int vmxit_invvpid(void)
+{
+    hvm_asid_flush_vcpu(current);
+    return 0;
+}
+#endif
+
+volatile int mukprtsc=1;
+void hybrid_vmx_vmexit_handler(struct cpu_user_regs *regs)
+{
+    unsigned int vector, exit_reason = __vmread(VM_EXIT_REASON);
+    int rc=0, ccpu = smp_processor_id();
+    struct vcpu *vp = current;
+
+    dbgp1("MUK:[%d]left VMCS exitreas:%d RIP:%lx RSP:%lx EFLAGS:%lx CR0:%lx\n", 
+          ccpu, exit_reason, vmr(GUEST_RIP), vmr(GUEST_RSP), regs->rflags, 
+          vmr(GUEST_CR0));
+
+    KASSERT( (vmr(GUEST_CR0)) != 0x8);
+    switch ( (uint16_t)exit_reason )
+    {
+        case EXIT_REASON_EXCEPTION_NMI:      /* 0 */
+            rc = vmxit_exception(regs);
+            break;
+            
+        case EXIT_REASON_EXTERNAL_INTERRUPT: /* 1 */
+        {
+            vector = __vmread(VM_EXIT_INTR_INFO);
+            vector &= INTR_INFO_VECTOR_MASK;
+            dbgp2("MUK: [%d] exit vmcs reas:%d vec:%d cr0:0x%016lx\n", ccpu, 
+                 exit_reason, vector, vmr(GUEST_CR0));
+            vmx_do_extint(regs);
+            break;
+        }
+
+        case EXIT_REASON_TRIPLE_FAULT:  /* 2 */
+        {
+#if 0
+            static int once;
+     if (!once)
+     kdbp("MUK:[%d]left VMCS exitreas:%d RIP:%lx RSP:%lx EFLAGS:%lx CR0:%lx\n",
+          ccpu, exit_reason, vmr(GUEST_RIP), vmr(GUEST_RSP), regs->rflags, 
+          vmr(GUEST_CR0));
+            once = 1;
+            vmx_inject_hw_exception(TRAP_gp_fault, regs->error_code);
+            rc = 0;
+#endif
+     kdbp("MUK:[%d]left VMCS exitreas:%d RIP:%lx RSP:%lx EFLAGS:%lx CR3:%lx\n",
+          ccpu, exit_reason, vmr(GUEST_RIP), vmr(GUEST_RSP), regs->rflags, 
+          vmr(GUEST_CR3));
+
+            __vmwrite(GUEST_CR3, 0x1803000);
+    if ( paging_mode_hap(vp->domain) && hvm_paging_enabled(vp) )
+        vp->arch.hvm_vcpu.guest_cr[3] = vp->arch.hvm_vcpu.hw_cr[3] =
+                                                           __vmread(GUEST_CR3);
+            kdb_trap_immed(KDB_TRAP_NONFATAL);
+            rc = 1;
+            break;
+        }
+        case EXIT_REASON_PENDING_VIRT_INTR:  /* 7 */
+        {
+            struct vcpu *v = current;
+            /* Disable the interrupt window. */
+            v->arch.hvm_vmx.exec_control &= ~CPU_BASED_VIRTUAL_INTR_PENDING;
+            __vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vmx.exec_control);
+            break;
+        }
+
+        case EXIT_REASON_CPUID:              /* 10 */
+        {
+            int ilen=__get_instruction_length();
+            __update_guest_eip(ilen);
+            dbgp2("cpuid:%d RIP:%lx\n", regs->eax, vmr(GUEST_RIP));
+            vmx_do_cpuid(regs);
+            break;
+        }
+
+#if 0
+        case EXIT_REASON_INVLPG:             /* 14 */
+            rc = vmxit_invlpg();
+            break;
+#endif
+        case EXIT_REASON_RDTSC:              /* 16 */
+        {
+#if 0
+            uint64_t tsc;
+            int ilen=__get_instruction_length();
+            rdtscll(tsc);
+            regs->eax = (uint32_t)tsc;
+            regs->edx = (uint32_t)(tsc >> 32);
+#endif
+            rdtsc(regs->eax, regs->edx);
+if (mukprtsc)
+    kdbp(" RDTSC: eax:%lx edx:%lx\n", regs->eax, regs->edx);
+            __update_guest_eip(__get_instruction_length());
+            rc = 0;
+            break;
+        }
+
+        case EXIT_REASON_VMCALL:             /* 18 */
+            rc = vmxit_vmcall(regs);
+            break;
+
+        case EXIT_REASON_CR_ACCESS:          /* 28 */
+            rc = vmxit_cr_access(regs);
+            break;
+
+        case EXIT_REASON_DR_ACCESS:          /* 29 */
+        {
+            unsigned long exit_qualification = __vmread(EXIT_QUALIFICATION);
+            vmx_dr_access(exit_qualification, regs);
+            break;
+        }
+        case EXIT_REASON_MSR_READ:           /* 31 */
+            rc = vmxit_msr_read(regs);
+            break;
+
+        case EXIT_REASON_MSR_WRITE:          /* 32 */
+            rc = vmxit_msr_write(regs);
+            break;
+
+        case EXIT_REASON_MONITOR_TRAP_FLAG:  /* 37 */
+            rc = vmxit_mtf(regs);
+            break;
+#if 0
+        case EXIT_REASON_INVVPID:            /* 53 */
+            rc = vmxit_invvpid();
+            break;
+#endif
+        default: 
+            rc = 1;
+    }
+    if (rc) {
+        unsigned long exit_qualification = __vmread(EXIT_QUALIFICATION);
+        local_irq_enable();
+        kdbp("MUK: [%d] exit_reas:%d 0x%lx qual:%ld 0x%lx cr0:0x%016lx\n", 
+             ccpu, exit_reason, exit_reason, exit_qualification,
+             exit_qualification, vmr(GUEST_CR0));
+        kdbp("MUK: [%d] RIP:%lx RSP:%lx\n", ccpu, 
+             vmr(GUEST_RIP), vmr(GUEST_RSP));
+        domain_crash_synchronous();
+    }
+
+    /*dbgp("MUK: will enter vmcs: cs:%x ss:%x\n", vmr(GUEST_CS_SELECTOR),
+         vmr(GUEST_SS_SELECTOR)); */
+
+    dbgp1("MUK: will enter vmcs:RIP:%lx RSP:%lx cr0:%lx eflags:%lx\n", 
+          vmr(GUEST_RIP), vmr(GUEST_RSP), vmr(GUEST_CR0), regs->rflags);
+
+    local_irq_enable();
+    KASSERT( (vmr(GUEST_CR0)) != 0x8);
+}
+
+void hybrid_flush_tlb(void)
+{
+    vpid_sync_all();
+}
+
+void hybrid_do_invlpg(ulong addr)
+{
+    /* vpid_sync_all(); */
+    vpid_sync_vcpu_gva(current, addr);
+}
+
+
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/vmx/intr.c	Thu Nov 17 15:37:30 2011 -0800
@@ -125,8 +125,9 @@ asmlinkage void vmx_intr_assist(void)
         return;
     }
 
-    /* Crank the handle on interrupt state. */
-    pt_update_irq(v);
+    if (!is_hybrid_vcpu(v))
+        /* Crank the handle on interrupt state. */
+        pt_update_irq(v);
 
     do {
         intack = hvm_vcpu_has_pending_irq(v);
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Thu Nov 17 15:37:30 2011 -0800
@@ -593,6 +593,311 @@ void vmx_disable_intercept_for_msr(struc
     }
 }
 
+
+void hybrid_update_cr3(struct vcpu *v)
+{
+    vmx_vmcs_enter(v);
+    __vmwrite(GUEST_CR3, v->arch.cr3);
+    __vmwrite(HOST_CR3, v->arch.cr3);
+
+    vpid_sync_all();
+    /* hvm_asid_flush_vcpu(v); */
+    vmx_vmcs_exit(v);
+}
+
+static int hybrid_construct_vmcs(struct vcpu *v)
+{
+    struct domain *d = v->domain;
+    uint16_t sysenter_cs;
+    unsigned long sysenter_eip;
+    u32 vmexit_ctl = vmx_vmexit_control;
+    u32 vmentry_ctl = vmx_vmentry_control;
+    u64 u64val;
+
+    vmx_vmcs_enter(v);
+
+    /* VMCS controls. */
+    vmx_pin_based_exec_control &= ~PIN_BASED_VIRTUAL_NMIS;
+    __vmwrite(PIN_BASED_VM_EXEC_CONTROL, vmx_pin_based_exec_control);
+
+    v->arch.hvm_vmx.exec_control = vmx_cpu_based_exec_control;
+
+    if ( v->domain->arch.vtsc )
+        v->arch.hvm_vmx.exec_control &= ~CPU_BASED_RDTSC_EXITING;
+
+    if ( paging_mode_hap(d) )
+    {
+        v->arch.hvm_vmx.exec_control &= ~(CPU_BASED_INVLPG_EXITING |
+                                          CPU_BASED_CR3_LOAD_EXITING |
+                                          CPU_BASED_CR3_STORE_EXITING);
+    }
+    v->arch.hvm_vmx.exec_control |= CPU_BASED_ACTIVATE_SECONDARY_CONTROLS;
+    v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
+    v->arch.hvm_vmx.exec_control &= ~CPU_BASED_ACTIVATE_IO_BITMAP; /* ??? */
+    v->arch.hvm_vmx.exec_control |= CPU_BASED_ACTIVATE_MSR_BITMAP;
+    v->arch.hvm_vmx.exec_control &= ~CPU_BASED_TPR_SHADOW;
+    v->arch.hvm_vmx.exec_control &= ~CPU_BASED_VIRTUAL_NMI_PENDING;
+
+    kdbp("MUK: writing proc based exec controls:%x\n", 
+                 v->arch.hvm_vmx.exec_control);
+    __vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vmx.exec_control);
+
+    /* MSR access bitmap. */
+    if ( cpu_has_vmx_msr_bitmap )
+    {
+        unsigned long *msr_bitmap = alloc_xenheap_page();
+
+        if ( msr_bitmap == NULL )
+            return -ENOMEM;
+
+        memset(msr_bitmap, ~0, PAGE_SIZE);
+        v->arch.hvm_vmx.msr_bitmap = msr_bitmap;
+        __vmwrite(MSR_BITMAP, virt_to_maddr(msr_bitmap));
+
+        vmx_disable_intercept_for_msr(v, MSR_FS_BASE);
+        vmx_disable_intercept_for_msr(v, MSR_GS_BASE);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP);
+
+        /* pure hvm doesn't do this. safe? see: long_mode_do_msr_write() */
+#if 0
+        vmx_disable_intercept_for_msr(v, MSR_STAR);
+        vmx_disable_intercept_for_msr(v, MSR_LSTAR);
+        vmx_disable_intercept_for_msr(v, MSR_CSTAR);
+        vmx_disable_intercept_for_msr(v, MSR_SYSCALL_MASK);
+#endif
+        vmx_disable_intercept_for_msr(v, MSR_SHADOW_GS_BASE);
+
+        kdbp("MUK: disabled intercepts for few msrs\n");
+
+    } else {
+        kdbp("MUK: CPU does NOT have msr bitmap\n");
+        for (;;) cpu_relax();
+    }
+
+    if ( !cpu_has_vmx_vpid ) {
+        printk("ERROR: VPID support is required to run PV in HVM container\n");
+        return -ESRCH;
+    }
+
+    v->arch.hvm_vmx.secondary_exec_control = vmx_secondary_exec_control;
+
+    if ( cpu_has_vmx_secondary_exec_control ) {
+        v->arch.hvm_vmx.secondary_exec_control &= ~0x4FF; /* turn off all */
+#if 0
+        v->arch.hvm_vmx.secondary_exec_control &= 
+                                       ~SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
+        v->arch.hvm_vmx.secondary_exec_control &= ~SECONDARY_EXEC_ENABLE_RDTSCP;
+
+        v->arch.hvm_vmx.secondary_exec_control &= 
+                                             ~SECONDARY_EXEC_UNRESTRICTED_GUEST;
+#endif
+        v->arch.hvm_vmx.secondary_exec_control |= 
+                                              SECONDARY_EXEC_PAUSE_LOOP_EXITING;
+        v->arch.hvm_vmx.secondary_exec_control |= SECONDARY_EXEC_ENABLE_VPID;
+
+        if ( paging_mode_hap(d) )
+            v->arch.hvm_vmx.secondary_exec_control |= SECONDARY_EXEC_ENABLE_EPT;
+
+        kdbp("MUK: muk_construct_vmcs: sec exec:0x%x\n",
+                                        v->arch.hvm_vmx.secondary_exec_control);
+        __vmwrite(SECONDARY_VM_EXEC_CONTROL,
+                  v->arch.hvm_vmx.secondary_exec_control);
+    } else {
+        printk("ERROR: NO Secondary Exec control\n");
+        return -ESRCH;
+    }
+
+    __vmwrite(VIRTUAL_PROCESSOR_ID, v->arch.hvm_vcpu.asid);
+
+    if ( !paging_mode_hap(d) )
+        vmexit_ctl &= ~(VM_EXIT_SAVE_GUEST_PAT | VM_EXIT_LOAD_HOST_PAT);
+    __vmwrite(VM_EXIT_CONTROLS, vmexit_ctl);
+
+    #define VM_ENTRY_LOAD_DEBUG_CTLS 0x4
+    #define VM_ENTRY_LOAD_EFER 0x8000
+    #define GUEST_EFER 0x2806        /* see page 23-20 */
+    #define GUEST_EFER_HIGH 0x2807   /* see page 23-20 */
+    vmentry_ctl &= ~VM_ENTRY_LOAD_DEBUG_CTLS;
+    vmentry_ctl &= ~VM_ENTRY_LOAD_EFER;
+    vmentry_ctl &= ~VM_ENTRY_SMM;
+    vmentry_ctl &= ~VM_ENTRY_DEACT_DUAL_MONITOR;
+    vmentry_ctl |= VM_ENTRY_IA32E_MODE;
+    if ( !paging_mode_hap(d) )
+        vmentry_ctl &= ~VM_ENTRY_LOAD_GUEST_PAT;
+    kdbp("MUK:muk_construct_vmcs(). vmentry_ctl:0x%x\n", vmentry_ctl);
+    __vmwrite(VM_ENTRY_CONTROLS, vmentry_ctl);
+
+    /* MSR intercepts. */
+    __vmwrite(VM_ENTRY_MSR_LOAD_COUNT, 0);
+    __vmwrite(VM_EXIT_MSR_LOAD_COUNT, 0);
+    __vmwrite(VM_EXIT_MSR_STORE_COUNT, 0);
+
+    /* Host data selectors. */
+    __vmwrite(HOST_SS_SELECTOR, __HYPERVISOR_DS);
+    __vmwrite(HOST_DS_SELECTOR, __HYPERVISOR_DS);
+    __vmwrite(HOST_ES_SELECTOR, __HYPERVISOR_DS);
+    __vmwrite(HOST_FS_SELECTOR, 0);
+    __vmwrite(HOST_GS_SELECTOR, 0);
+    __vmwrite(HOST_FS_BASE, 0);
+    __vmwrite(HOST_GS_BASE, 0);
+
+    vmx_set_host_env(v);
+
+    /* Host control registers. */
+    v->arch.hvm_vmx.host_cr0 = read_cr0() | X86_CR0_TS;
+    __vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0);
+    __vmwrite(HOST_CR4, mmu_cr4_features|(cpu_has_xsave ? X86_CR4_OSXSAVE : 0));
+
+    /* Host CS:RIP. */
+    __vmwrite(HOST_CS_SELECTOR, __HYPERVISOR_CS);
+    __vmwrite(HOST_RIP, (unsigned long)vmx_asm_vmexit_handler);
+
+    /* Host SYSENTER CS:RIP. */
+    rdmsrl(MSR_IA32_SYSENTER_CS, sysenter_cs);
+    __vmwrite(HOST_SYSENTER_CS, sysenter_cs);
+    rdmsrl(MSR_IA32_SYSENTER_EIP, sysenter_eip);
+    __vmwrite(HOST_SYSENTER_EIP, sysenter_eip);
+
+    __vmwrite(VM_ENTRY_INTR_INFO, 0);
+
+    __vmwrite(CR3_TARGET_COUNT, 0);
+
+    __vmwrite(GUEST_ACTIVITY_STATE, 0);
+
+    __vmwrite(GUEST_CS_BASE, 0);
+    __vmwrite(GUEST_CS_LIMIT, ~0u);
+    __vmwrite(GUEST_CS_AR_BYTES, 0xa09b); /* CS.L == 1 */
+    __vmwrite(GUEST_CS_SELECTOR, 0x10);
+
+    __vmwrite(GUEST_DS_BASE, 0);
+    __vmwrite(GUEST_DS_LIMIT, ~0u);
+    __vmwrite(GUEST_DS_AR_BYTES, 0xc093);
+    __vmwrite(GUEST_DS_SELECTOR, 0x18);
+
+    __vmwrite(GUEST_SS_BASE, 0);         /* use same seg as DS */
+    __vmwrite(GUEST_SS_LIMIT, ~0u);
+    __vmwrite(GUEST_SS_AR_BYTES, 0xc093);
+    __vmwrite(GUEST_SS_SELECTOR, 0x18);
+
+    __vmwrite(GUEST_ES_SELECTOR, 0);
+    __vmwrite(GUEST_FS_SELECTOR, 0);
+    __vmwrite(GUEST_GS_SELECTOR, 0);
+
+    /* Guest segment bases. */
+    __vmwrite(GUEST_ES_BASE, 0);
+    __vmwrite(GUEST_FS_BASE, 0);
+    __vmwrite(GUEST_GS_BASE, 0);
+
+    /* Guest segment limits. */
+    __vmwrite(GUEST_ES_LIMIT, ~0u);
+    __vmwrite(GUEST_FS_LIMIT, ~0u);
+    __vmwrite(GUEST_GS_LIMIT, ~0u);
+
+    /* Guest segment AR bytes. */
+    __vmwrite(GUEST_ES_AR_BYTES, 0xc093); /* read/write, accessed */
+    __vmwrite(GUEST_FS_AR_BYTES, 0xc093);
+    __vmwrite(GUEST_GS_AR_BYTES, 0xc093);
+
+    /* Guest IDT. */
+    __vmwrite(GUEST_GDTR_BASE, 0);
+    __vmwrite(GUEST_GDTR_LIMIT, 0);
+
+    /* Guest LDT. */
+    __vmwrite(GUEST_LDTR_AR_BYTES, 0x82); /* LDT */
+    __vmwrite(GUEST_LDTR_SELECTOR, 0);
+    __vmwrite(GUEST_LDTR_BASE, 0);
+    __vmwrite(GUEST_LDTR_LIMIT, 0);
+
+    /* Guest TSS. */
+    __vmwrite(GUEST_TR_AR_BYTES, 0x8b); /* 32-bit TSS (busy) */
+    __vmwrite(GUEST_TR_BASE, 0);
+    __vmwrite(GUEST_TR_LIMIT, 0xff);
+
+    __vmwrite(GUEST_INTERRUPTIBILITY_INFO, 0);
+    __vmwrite(GUEST_DR7, 0);
+    __vmwrite(VMCS_LINK_POINTER, ~0UL);
+
+    if (paging_mode_hap(d)) {
+        __vmwrite(PAGE_FAULT_ERROR_CODE_MASK, 0);
+        __vmwrite(PAGE_FAULT_ERROR_CODE_MATCH, 0);
+        __vmwrite(EXCEPTION_BITMAP,
+                  HVM_TRAP_MASK | TRAP_debug | 
+                  (1U<<TRAP_int3) | (1U << TRAP_no_device));
+    } else {
+        /* vmexit only on write to protected page, err code: 0x3 */
+        __vmwrite(PAGE_FAULT_ERROR_CODE_MASK, 0xffffffff);
+        __vmwrite(PAGE_FAULT_ERROR_CODE_MATCH, 0x3);
+        __vmwrite(EXCEPTION_BITMAP, 0xffffffff);
+    }
+
+#if 0
+    __vmwrite(EXCEPTION_BITMAP,
+              HVM_TRAP_MASK | TRAP_debug | TRAP_gp_fault |
+              (1U<<TRAP_int3) | (1U << TRAP_page_fault)|(1U << TRAP_no_device));
+#endif
+    __vmwrite(TSC_OFFSET, 0);
+
+#if 0
+    v->arch.hvm_vcpu.guest_cr[0] = X86_CR0_PG | X86_CR0_PE | X86_CR0_ET;
+    hvm_update_guest_cr(v, 0);
+
+    v->arch.hvm_vcpu.guest_cr[4] = 0;
+    hvm_update_guest_cr(v, 4);
+#endif
+
+#if 0
+    u64val = X86_CR0_PG | X86_CR0_PE | X86_CR0_ET | X86_CR0_TS |
+             X86_CR0_NE | X86_CR0_WP;
+#endif
+    /* make sure to set WP bit so rdonly pages are not written from CPL 0 */
+    u64val = X86_CR0_PG | X86_CR0_NE | X86_CR0_PE | X86_CR0_WP;
+    __vmwrite(GUEST_CR0, u64val);
+    __vmwrite(CR0_READ_SHADOW, u64val);
+    v->arch.hvm_vcpu.hw_cr[0] = v->arch.hvm_vcpu.guest_cr[0] = u64val;
+
+    u64val = X86_CR4_PAE | X86_CR4_VMXE;
+    __vmwrite(GUEST_CR4, u64val);
+    __vmwrite(CR4_READ_SHADOW, u64val);
+    v->arch.hvm_vcpu.guest_cr[4] = u64val;
+
+    __vmwrite(CR0_GUEST_HOST_MASK, ~0UL);
+    __vmwrite(CR4_GUEST_HOST_MASK, ~0UL);
+
+     v->arch.hvm_vmx.vmx_realmode = 0;
+
+    if ( paging_mode_hap(d) )
+    {
+        __vmwrite(EPT_POINTER, d->arch.hvm_domain.vmx.ept_control.eptp);
+#ifdef __i386__
+        __vmwrite(EPT_POINTER_HIGH,
+                  d->arch.hvm_domain.vmx.ept_control.eptp >> 32);
+#endif
+    }
+
+    if ( cpu_has_vmx_pat && paging_mode_hap(d) )
+    {
+        u64 host_pat, guest_pat;
+
+        rdmsrl(MSR_IA32_CR_PAT, host_pat);
+        guest_pat = MSR_IA32_CR_PAT_RESET;
+
+        __vmwrite(HOST_PAT, host_pat);
+        __vmwrite(GUEST_PAT, guest_pat);
+#ifdef __i386__
+JUNK
+        __vmwrite(HOST_PAT_HIGH, host_pat >> 32);
+        __vmwrite(GUEST_PAT_HIGH, guest_pat >> 32);
+#endif
+    }
+    vmx_vmcs_exit(v);
+#if 0
+    paging_update_paging_modes(v); /* will update HOST & GUEST_CR3 as reqd */
+#endif
+    return 0;
+}
+
 static int construct_vmcs(struct vcpu *v)
 {
     struct domain *d = v->domain;
@@ -601,6 +906,9 @@ static int construct_vmcs(struct vcpu *v
     u32 vmexit_ctl = vmx_vmexit_control;
     u32 vmentry_ctl = vmx_vmentry_control;
 
+    if (is_hybrid_domain(d))
+        return hybrid_construct_vmcs(v);
+
     vmx_vmcs_enter(v);
 
     /* VMCS controls. */
@@ -1001,8 +1309,10 @@ void vmx_do_resume(struct vcpu *v)
 
         vmx_clear_vmcs(v);
         vmx_load_vmcs(v);
-        hvm_migrate_timers(v);
-        hvm_migrate_pirqs(v);
+        if (!is_hybrid_vcpu(v)) {
+            hvm_migrate_timers(v);
+            hvm_migrate_pirqs(v);
+        }
         vmx_set_host_env(v);
         hvm_asid_flush_vcpu(v);
     }
@@ -1018,14 +1328,6 @@ void vmx_do_resume(struct vcpu *v)
     reset_stack_and_jump(vmx_asm_do_vmentry);
 }
 
-static unsigned long vmr(unsigned long field)
-{
-    int rc;
-    unsigned long val;
-    val = __vmread_safe(field, &rc);
-    return rc ? 0 : val;
-}
-
 static void vmx_dump_sel(char *name, uint32_t selector)
 {
     uint32_t sel, attr, limit;
@@ -1263,6 +1565,8 @@ static void noinline kdb_print_vmcs(stru
     vmx_dump_sel("LDTR", GUEST_LDTR_SELECTOR);
     vmx_dump_sel2("IDTR", GUEST_IDTR_LIMIT);
     vmx_dump_sel("TR", GUEST_TR_SELECTOR);
+    kdbp("Guest EFER = 0x%08x%08x\n",
+           (uint32_t)vmr(GUEST_EFER_HIGH), (uint32_t)vmr(GUEST_EFER));
     kdbp("Guest PAT = 0x%08x%08x\n",
            (uint32_t)vmr(GUEST_PAT_HIGH), (uint32_t)vmr(GUEST_PAT));
     x  = (unsigned long long)vmr(TSC_OFFSET_HIGH) << 32;
@@ -1276,6 +1580,10 @@ static void noinline kdb_print_vmcs(stru
            (int)vmr(GUEST_INTERRUPTIBILITY_INFO),
            (int)vmr(GUEST_ACTIVITY_STATE));
 
+    kdbp("MSRs: entry_load:$%d exit_load:$%d exit_store:$%d\n",
+         vmr(VM_ENTRY_MSR_LOAD_COUNT), vmr(VM_EXIT_MSR_LOAD_COUNT),
+         vmr(VM_EXIT_MSR_STORE_COUNT));
+
     kdbp("\n*** Host State ***\n");
     kdbp("RSP = 0x%016llx  RIP = 0x%016llx\n", 
            (unsigned long long)vmr(HOST_RSP),
@@ -1316,6 +1624,9 @@ static void noinline kdb_print_vmcs(stru
            (uint32_t)vmr(VM_EXIT_CONTROLS));
     kdbp("ExceptionBitmap=%08x\n",
            (uint32_t)vmr(EXCEPTION_BITMAP));
+    kdbp("PAGE_FAULT_ERROR_CODE  MASK:0x%lx  MATCH:0x%lx\n", 
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MASK),
+         (unsigned long)vmr(PAGE_FAULT_ERROR_CODE_MATCH));
     kdbp("VMEntry: intr_info=%08x errcode=%08x ilen=%08x\n",
            (uint32_t)vmr(VM_ENTRY_INTR_INFO),
            (uint32_t)vmr(VM_ENTRY_EXCEPTION_ERROR_CODE),
@@ -1344,8 +1655,7 @@ static void noinline kdb_print_vmcs(stru
  *     do __vmreads. So, the VMCS pointer can't be left cleared.
  *   - Doing __vmpclear will set the vmx state to 'clear', so to resume a
  *     vmlaunch must be done and not vmresume. This means, we must clear 
- *     arch_vmx->launched. Just call __vmx_clear_vmcs(), hopefully it won't keep
- *     changing...
+ *     arch_vmx->launched.
  */
 void kdb_curr_cpu_flush_vmcs(void)
 {
@@ -1358,12 +1668,14 @@ void kdb_curr_cpu_flush_vmcs(void)
     /* looks like we got one. unfortunately, current_vmcs points to vmcs 
      * and not VCPU, so we gotta search the entire list... */
     for_each_domain (dp) {
-        if ( !is_hvm_domain(dp) || dp->is_dying)
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
             continue;
         for_each_vcpu (dp, vp) {
             if (vp->arch.hvm_vmx.active_cpu == smp_processor_id()) {
-                __vmx_clear_vmcs(vp);
+                __vmpclear(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
                 __vmptrld(virt_to_maddr(vp->arch.hvm_vmx.vmcs));
+                vp->arch.hvm_vmx.launched   = 0;
+                kdbp("KDB:[%d] vmcs flushed\n", smp_processor_id());
             }
         }
     }
@@ -1382,7 +1694,7 @@ void kdb_dump_vmcs(domid_t did, int vid)
     ASSERT(!local_irq_is_enabled());     /* kdb should always run disabled */
 
     for_each_domain (dp) {
-        if ( !is_hvm_domain(dp) || dp->is_dying)
+        if ( !(is_hvm_or_hyb_domain(dp)) || dp->is_dying)
             continue;
         if (did != 0 && did != dp->domain_id)
             continue;
@@ -1400,7 +1712,7 @@ void kdb_dump_vmcs(domid_t did, int vid)
         kdbp("\n");
     }
     /* restore orig vmcs pointer for __vmreads in vmx_vmexit_handler() */
-    if (is_hvm_vcpu(current))
+    if (is_hvm_or_hyb_vcpu(current)) 
         __vmptrld(virt_to_maddr(current->arch.hvm_vmx.vmcs));
 }
 #endif
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Nov 17 15:37:30 2011 -0800
@@ -68,7 +68,6 @@ static void vmx_cpuid_intercept(
     unsigned int *eax, unsigned int *ebx,
     unsigned int *ecx, unsigned int *edx);
 static void vmx_wbinvd_intercept(void);
-static void vmx_fpu_dirty_intercept(void);
 static int vmx_msr_read_intercept(struct cpu_user_regs *regs);
 static int vmx_msr_write_intercept(struct cpu_user_regs *regs);
 static void vmx_invlpg_intercept(unsigned long vaddr);
@@ -87,6 +86,8 @@ static int vmx_domain_initialise(struct 
     d->arch.hvm_domain.vmx.ept_control.asr  =
         pagetable_get_pfn(d->arch.phys_table);
 
+    if (is_hybrid_domain(d))
+        return 0;
 
     if ( (rc = vmx_alloc_vlapic_mapping(d)) != 0 )
         return rc;
@@ -98,6 +99,10 @@ static void vmx_domain_destroy(struct do
 {
     if ( d->arch.hvm_domain.hap_enabled )
         on_each_cpu(__ept_sync_domain, d, 1);
+
+    if (is_hybrid_domain(d))
+        return;
+
     vmx_free_vlapic_mapping(d);
 }
 
@@ -119,13 +124,19 @@ static int vmx_vcpu_initialise(struct vc
         return rc;
     }
 
-    vpmu_initialise(v);
-
-    vmx_install_vlapic_mapping(v);
-
-    /* %eax == 1 signals full real-mode support to the guest loader. */
-    if ( v->vcpu_id == 0 )
-        v->arch.guest_context.user_regs.eax = 1;
+    /* Hybrid TBD: pmu */
+    if ( !is_hybrid_vcpu(v)) {
+        vpmu_initialise(v);
+
+        vmx_install_vlapic_mapping(v);
+
+        /* %eax == 1 signals full real-mode support to the guest loader. */
+        if ( v->vcpu_id == 0 )
+            v->arch.guest_context.user_regs.eax = 1;
+    } else {
+        /* for hvm_long_mode_enabled(v) */
+        v->arch.hvm_vcpu.guest_efer = EFER_SCE | EFER_LMA | EFER_LME;
+    }
 
     return 0;
 }
@@ -398,6 +409,9 @@ static int vmx_guest_x86_mode(struct vcp
 {
     unsigned int cs_ar_bytes;
 
+if (is_hybrid_vcpu(v))
+    return 8;
+
     if ( unlikely(!(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE)) )
         return 0;
     if ( unlikely(guest_cpu_user_regs()->eflags & X86_EFLAGS_VM) )
@@ -628,7 +642,7 @@ static int vmx_load_vmcs_ctxt(struct vcp
     return 0;
 }
 
-static void vmx_fpu_enter(struct vcpu *v)
+void vmx_fpu_enter(struct vcpu *v)
 {
     setup_fpu(v);
     __vm_clear_bit(EXCEPTION_BITMAP, TRAP_no_device);
@@ -657,6 +671,7 @@ static void vmx_fpu_leave(struct vcpu *v
     {
         v->arch.hvm_vcpu.hw_cr[0] |= X86_CR0_TS;
         __vmwrite(GUEST_CR0, v->arch.hvm_vcpu.hw_cr[0]);
+KASSERT( (vmr(GUEST_CR0)) != 0x8);
         __vm_set_bit(EXCEPTION_BITMAP, TRAP_no_device);
     }
 }
@@ -1155,6 +1170,7 @@ static void vmx_update_guest_cr(struct v
         v->arch.hvm_vcpu.hw_cr[0] =
             v->arch.hvm_vcpu.guest_cr[0] | hw_cr0_mask;
         __vmwrite(GUEST_CR0, v->arch.hvm_vcpu.hw_cr[0]);
+KASSERT( (vmr(GUEST_CR0)) != 0x8);
         __vmwrite(CR0_READ_SHADOW, v->arch.hvm_vcpu.guest_cr[0]);
         break;
     }
@@ -1299,6 +1315,7 @@ void vmx_inject_hw_exception(int trap, i
     if ( unlikely(intr_info & INTR_INFO_VALID_MASK) &&
          (((intr_info >> 8) & 7) == X86_EVENTTYPE_HW_EXCEPTION) )
     {
+        KASSERT(!is_hybrid_vcpu(curr));
         trap = hvm_combine_hw_exceptions((uint8_t)intr_info, trap);
         if ( trap == TRAP_double_fault )
             error_code = 0;
@@ -1459,38 +1476,7 @@ void start_vmx(void)
     hvm_enable(&vmx_function_table);
 }
 
-/*
- * Not all cases receive valid value in the VM-exit instruction length field.
- * Callers must know what they're doing!
- */
-static int __get_instruction_length(void)
-{
-    int len;
-    len = __vmread(VM_EXIT_INSTRUCTION_LEN); /* Safe: callers audited */
-    BUG_ON((len < 1) || (len > 15));
-    return len;
-}
-
-static void __update_guest_eip(unsigned long inst_len)
-{
-    struct cpu_user_regs *regs = guest_cpu_user_regs();
-    unsigned long x;
-
-    regs->eip += inst_len;
-    regs->eflags &= ~X86_EFLAGS_RF;
-
-    x = __vmread(GUEST_INTERRUPTIBILITY_INFO);
-    if ( x & (VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS) )
-    {
-        x &= ~(VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS);
-        __vmwrite(GUEST_INTERRUPTIBILITY_INFO, x);
-    }
-
-    if ( regs->eflags & X86_EFLAGS_TF )
-        vmx_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
-}
-
-static void vmx_fpu_dirty_intercept(void)
+void vmx_fpu_dirty_intercept(void)
 {
     struct vcpu *curr = current;
 
@@ -1500,6 +1486,7 @@ static void vmx_fpu_dirty_intercept(void
     if ( !(curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_TS) )
     {
         curr->arch.hvm_vcpu.hw_cr[0] &= ~X86_CR0_TS;
+KASSERT( (vmr(GUEST_CR0)) != 0x8);
         __vmwrite(GUEST_CR0, curr->arch.hvm_vcpu.hw_cr[0]);
     }
 }
@@ -1531,7 +1518,7 @@ static void vmx_cpuid_intercept(
     HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
 }
 
-static void vmx_do_cpuid(struct cpu_user_regs *regs)
+void vmx_do_cpuid(struct cpu_user_regs *regs)
 {
     unsigned int eax, ebx, ecx, edx;
 
@@ -1548,7 +1535,7 @@ static void vmx_do_cpuid(struct cpu_user
     regs->edx = edx;
 }
 
-static void vmx_dr_access(unsigned long exit_qualification,
+void vmx_dr_access(unsigned long exit_qualification,
                           struct cpu_user_regs *regs)
 {
     struct vcpu *v = current;
@@ -2037,7 +2024,7 @@ gp_fault:
     return X86EMUL_EXCEPTION;
 }
 
-static void vmx_do_extint(struct cpu_user_regs *regs)
+void vmx_do_extint(struct cpu_user_regs *regs)
 {
     unsigned int vector;
 
@@ -2182,9 +2169,16 @@ static void vmx_failed_vmentry(unsigned 
         break;
     }
 
+#if defined(XEN_KDB_CONFIG)
+    { extern void kdb_dump_vmcs(domid_t did, int vid);
+      printk("\n************* VMCS Area **************\n");
+      kdb_dump_vmcs(curr->domain->domain_id, (curr)->vcpu_id);
+    }
+#else
     printk("************* VMCS Area **************\n");
     vmcs_dump_vcpu(curr);
     printk("**************************************\n");
+#endif
 
     domain_crash(curr->domain);
 }
@@ -2268,6 +2262,8 @@ err:
     return -1;
 }
 
+extern void hybrid_vmx_vmexit_handler(struct cpu_user_regs *regs);
+
 asmlinkage void vmx_vmexit_handler(struct cpu_user_regs *regs)
 {
     unsigned int exit_reason, idtv_info, intr_info = 0, vector = 0;
@@ -2278,6 +2274,11 @@ asmlinkage void vmx_vmexit_handler(struc
         v->arch.hvm_vcpu.guest_cr[3] = v->arch.hvm_vcpu.hw_cr[3] =
             __vmread(GUEST_CR3);
 
+    if ( is_hybrid_vcpu(v)) {
+        hybrid_vmx_vmexit_handler(regs);
+        return;
+    }
+
     exit_reason = __vmread(VM_EXIT_REASON);
 
     if ( hvm_long_mode_enabled(v) )
@@ -2632,13 +2633,13 @@ asmlinkage void vmx_vmexit_handler(struc
     case EXIT_REASON_MONITOR_TRAP_FLAG:
         v->arch.hvm_vmx.exec_control &= ~CPU_BASED_MONITOR_TRAP_FLAG;
         __vmwrite(CPU_BASED_VM_EXEC_CONTROL, v->arch.hvm_vmx.exec_control);
-        v->arch.hvm_vcpu.single_step = 0;
 #if defined(XEN_KDB_CONFIG)
         if (kdb_handle_trap_entry(TRAP_debug, regs))
             break;
 #endif
         if ( v->domain->debugger_attached && v->arch.hvm_vcpu.single_step )
             domain_pause_for_debugger();
+        v->arch.hvm_vcpu.single_step = 0;
         break;
 
     case EXIT_REASON_PAUSE_INSTRUCTION:
diff -r f2cf898c7ff8 xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/hvm/vpt.c	Thu Nov 17 15:37:30 2011 -0800
@@ -289,6 +289,7 @@ void pt_intr_post(struct vcpu *v, struct
     if ( intack.source == hvm_intsrc_vector )
         return;
 
+    KASSERT(!is_hybrid_vcpu(current));
     spin_lock(&v->arch.hvm_vcpu.tm_lock);
 
     pt = is_pt_irq(v, intack);
diff -r f2cf898c7ff8 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm.c	Thu Nov 17 15:37:30 2011 -0800
@@ -490,9 +490,12 @@ void make_cr3(struct vcpu *v, unsigned l
 
 #endif /* !defined(__i386__) */
 
+/* calling hybrid_update_cr3 doesnt work because during context switch
+ * vmcs is not completely setup? */
 void write_ptbase(struct vcpu *v)
 {
-    write_cr3(v->arch.cr3);
+    if (!is_hybrid_vcpu(v))
+        write_cr3(v->arch.cr3);
 }
 
 /*
@@ -2482,6 +2485,7 @@ int get_page_type_preemptible(struct pag
 }
 
 
+extern void hybrid_update_cr3(struct vcpu *v);
 int new_guest_cr3(unsigned long mfn)
 {
     struct vcpu *curr = current;
@@ -2530,6 +2534,9 @@ int new_guest_cr3(unsigned long mfn)
 
     write_ptbase(curr);
 
+    if (is_hybrid_vcpu(curr))
+        hybrid_update_cr3(curr);
+
     if ( likely(old_base_mfn != 0) )
     {
         if ( paging_mode_refcounts(d) )
@@ -2863,10 +2870,23 @@ int do_mmuext_op(
 #endif
         
         case MMUEXT_TLB_FLUSH_LOCAL:
+            /* do this for both, flush_tlb_user and flush_tlb_kernel, for now.
+             * To debug: hvm_asid_flush_vcpu for flush_tlb_user, and
+             * vpid_sync_all for flush_tlb_kernel */
+            if (is_hybrid_domain(d)) {
+                extern void hybrid_flush_tlb(void);
+                hybrid_flush_tlb();
+                break;
+            }
             flush_tlb_local();
             break;
     
         case MMUEXT_INVLPG_LOCAL:
+            if (is_hybrid_domain(d)) {
+                extern void hybrid_do_invlpg(ulong);
+                hybrid_do_invlpg(op.arg1.linear_addr);
+                break;
+            }
             if ( !paging_mode_enabled(d) 
                  || paging_invlpg(curr, op.arg1.linear_addr) != 0 )
                 flush_tlb_one_local(op.arg1.linear_addr);
@@ -2877,6 +2897,10 @@ int do_mmuext_op(
         {
             cpumask_t pmask;
 
+            if (is_hybrid_domain(d)) {
+                printk("MUK:FIX: MMUEXT_TLB_FLUSH_MULTI/MMUEXT_INVLPG_MULTI\n");
+                break;
+            }
             if ( unlikely(vcpumask_to_pcpumask(d, op.arg2.vcpumask, &pmask)) )
             {
                 okay = 0;
@@ -4181,7 +4205,7 @@ long do_update_descriptor(u64 pa, u64 de
     mfn = gmfn_to_mfn(dom, gmfn);
     if ( (((unsigned int)pa % sizeof(struct desc_struct)) != 0) ||
          !mfn_valid(mfn) ||
-         !check_descriptor(dom, &d) )
+         (!is_hybrid_domain(dom) && !check_descriptor(dom, &d)) )
         return -EINVAL;
 
     page = mfn_to_page(mfn);
diff -r f2cf898c7ff8 xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm/hap/hap.c	Thu Nov 17 15:37:30 2011 -0800
@@ -705,8 +705,10 @@ void hap_vcpu_init(struct vcpu *v)
 static int hap_page_fault(struct vcpu *v, unsigned long va,
                           struct cpu_user_regs *regs)
 {
-    HAP_ERROR("Intercepted a guest #PF (%u:%u) with HAP enabled.\n",
-              v->domain->domain_id, v->vcpu_id);
+    HAP_ERROR("Intercepted a guest #PF (%u:%u:VA %016lx IP:%016lx) with "
+              "HAP enabled.\n", v->domain->domain_id, v->vcpu_id,va, regs->rip);
+
+    kdb_trap_immed(KDB_TRAP_NONFATAL);
     domain_crash(v->domain);
     return 0;
 }
diff -r f2cf898c7ff8 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm/mem_event.c	Thu Nov 17 15:37:30 2011 -0800
@@ -216,7 +216,7 @@ int mem_event_domctl(struct domain *d, x
 
             /* Currently only EPT is supported */
             rc = -ENODEV;
-            if ( !(is_hvm_domain(d) && d->arch.hvm_domain.hap_enabled &&
+            if ( !(is_hvm_or_hyb_domain(d) && d->arch.hvm_domain.hap_enabled &&
                   (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)) )
                 break;
 
diff -r f2cf898c7ff8 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm/mem_sharing.c	Thu Nov 17 15:37:30 2011 -0800
@@ -42,9 +42,6 @@ static void mem_sharing_audit(void);
 # define mem_sharing_audit() do {} while(0)
 #endif /* MEM_SHARING_AUDIT */
 
-
-#define hap_enabled(d) \
-    (is_hvm_domain(d) && (d)->arch.hvm_domain.hap_enabled)
 #define mem_sharing_enabled(d) \
     (is_hvm_domain(d) && (d)->arch.hvm_domain.mem_sharing_enabled)
  
diff -r f2cf898c7ff8 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm/p2m.c	Thu Nov 17 15:37:30 2011 -0800
@@ -1569,7 +1569,7 @@ int p2m_init(struct domain *d)
     p2m->get_entry_current = p2m_gfn_to_mfn_current;
     p2m->change_entry_type_global = p2m_change_type_global;
 
-    if ( is_hvm_domain(d) && d->arch.hvm_domain.hap_enabled &&
+    if ( is_hvm_or_hyb_domain(d) && d->arch.hvm_domain.hap_enabled &&
          (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) )
         ept_p2m_init(d);
 
@@ -1596,7 +1596,7 @@ int set_p2m_entry(struct domain *d, unsi
 
     while ( todo )
     {
-        if ( is_hvm_domain(d) && d->arch.hvm_domain.hap_enabled )
+        if ( is_hvm_or_hyb_domain(d) && d->arch.hvm_domain.hap_enabled )
             order = ((((gfn | mfn_x(mfn) | todo) & (SUPERPAGE_PAGES - 1)) == 0)
                     && hvm_hap_has_2mb(d)) ? 9 : 0;
         else
diff -r f2cf898c7ff8 xen/arch/x86/mm/paging.c
--- a/xen/arch/x86/mm/paging.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/mm/paging.c	Thu Nov 17 15:37:30 2011 -0800
@@ -29,8 +29,6 @@
 #include <xen/numa.h>
 #include <xsm/xsm.h>
 
-#define hap_enabled(d) (is_hvm_domain(d) && (d)->arch.hvm_domain.hap_enabled)
-
 /* Printouts */
 #define PAGING_PRINTK(_f, _a...)                                     \
     debugtrace_printk("pg: %s(): " _f, __func__, ##_a)
diff -r f2cf898c7ff8 xen/arch/x86/time.c
--- a/xen/arch/x86/time.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/time.c	Thu Nov 17 15:37:30 2011 -0800
@@ -879,7 +879,7 @@ static void __update_vcpu_system_time(st
         _u.tsc_to_system_mul = t->tsc_scale.mul_frac;
         _u.tsc_shift         = (s8)t->tsc_scale.shift;
     }
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         _u.tsc_timestamp += v->arch.hvm_vcpu.cache_tsc_offset;
 
     /* Don't bother unless timestamp record has changed or we are forced. */
@@ -947,7 +947,7 @@ static void update_domain_rtc(void)
     rcu_read_lock(&domlist_read_lock);
 
     for_each_domain ( d )
-        if ( is_hvm_domain(d) )
+        if ( is_hvm_or_hyb_domain(d) )
             rtc_update_clock(d);
 
     rcu_read_unlock(&domlist_read_lock);
@@ -956,7 +956,7 @@ static void update_domain_rtc(void)
 void domain_set_time_offset(struct domain *d, int32_t time_offset_seconds)
 {
     d->time_offset_seconds = time_offset_seconds;
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         rtc_update_clock(d);
 }
 
@@ -1856,7 +1856,6 @@ void tsc_set_info(struct domain *d,
         d->arch.vtsc = 0;
         return;
     }
-
     switch ( d->arch.tsc_mode = tsc_mode )
     {
     case TSC_MODE_NEVER_EMULATE:
@@ -1901,7 +1900,7 @@ void tsc_set_info(struct domain *d,
         break;
     }
     d->arch.incarnation = incarnation + 1;
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         hvm_set_rdtsc_exiting(d, d->arch.vtsc);
 }
 
diff -r f2cf898c7ff8 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/traps.c	Thu Nov 17 15:37:30 2011 -0800
@@ -1217,7 +1217,7 @@ static int spurious_page_fault(
     return is_spurious;
 }
 
-static int fixup_page_fault(unsigned long addr, struct cpu_user_regs *regs)
+int fixup_page_fault(unsigned long addr, struct cpu_user_regs *regs)
 {
     struct vcpu   *v = current;
     struct domain *d = v->domain;
@@ -3228,7 +3228,6 @@ void load_TR(void)
         .base = (long)(this_cpu(gdt_table) - FIRST_RESERVED_GDT_ENTRY),
         .limit = LAST_RESERVED_GDT_BYTE
     };
-
     _set_tssldt_desc(
         this_cpu(gdt_table) + TSS_ENTRY - FIRST_RESERVED_GDT_ENTRY,
         (unsigned long)tss,
diff -r f2cf898c7ff8 xen/arch/x86/x86_64/traps.c
--- a/xen/arch/x86/x86_64/traps.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/arch/x86/x86_64/traps.c	Thu Nov 17 15:37:30 2011 -0800
@@ -617,7 +617,7 @@ static void hypercall_page_initialise_ri
 void hypercall_page_initialise(struct domain *d, void *hypercall_page)
 {
     memset(hypercall_page, 0xCC, PAGE_SIZE);
-    if ( is_hvm_domain(d) )
+    if ( is_hvm_or_hyb_domain(d) )
         hvm_hypercall_page_initialise(d, hypercall_page);
     else if ( !is_pv_32bit_domain(d) )
         hypercall_page_initialise_ring3_kernel(hypercall_page);
diff -r f2cf898c7ff8 xen/common/domain.c
--- a/xen/common/domain.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/common/domain.c	Thu Nov 17 15:37:30 2011 -0800
@@ -238,8 +238,13 @@ struct domain *domain_create(
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code = -1;
 
-    if ( domcr_flags & DOMCRF_hvm )
+    if ( domcr_flags & DOMCRF_hybrid ) {
+        d->is_hybrid = 1;
+        printk("Hybrid guest with%s ept. Domid:%d\n", 
+               (domcr_flags&DOMCRF_hap) ? "" : " no", domid);
+    } else if ( domcr_flags & DOMCRF_hvm ) {
         d->is_hvm = 1;
+    }
 
     if ( domid == 0 )
     {
@@ -588,7 +593,8 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    if (current->arch.gdbsx_vcpu_event == 0)
+        send_guest_global_virq(dom0, VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
diff -r f2cf898c7ff8 xen/common/domctl.c
--- a/xen/common/domctl.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/common/domctl.c	Thu Nov 17 15:37:30 2011 -0800
@@ -132,6 +132,8 @@ void getdomaininfo(struct domain *d, str
 
     if ( is_hvm_domain(d) )
         info->flags |= XEN_DOMINF_hvm_guest;
+    else if ( is_hybrid_domain(d) )
+        info->flags |= XEN_DOMINF_hybrid_guest;
 
     xsm_security_domaininfo(d, info);
 
@@ -394,7 +396,8 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         if ( supervisor_mode_kernel ||
              (op->u.createdomain.flags &
              ~(XEN_DOMCTL_CDF_hvm_guest | XEN_DOMCTL_CDF_hap |
-               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off)) )
+               XEN_DOMCTL_CDF_s3_integrity | XEN_DOMCTL_CDF_oos_off |
+               XEN_DOMCTL_CDF_hybrid_guest)) )
             break;
 
         dom = op->domain;
@@ -430,6 +433,8 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
             domcr_flags |= DOMCRF_s3_integrity;
         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
             domcr_flags |= DOMCRF_oos_off;
+        if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_hybrid_guest )
+            domcr_flags |= DOMCRF_hybrid;
 
         ret = -ENOMEM;
         d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref);
diff -r f2cf898c7ff8 xen/common/kernel.c
--- a/xen/common/kernel.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/common/kernel.c	Thu Nov 17 15:37:30 2011 -0800
@@ -239,13 +239,16 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDL
             if ( supervisor_mode_kernel )
                 fi.submap |= 1U << XENFEAT_supervisor_mode_kernel;
 #ifdef CONFIG_X86
-            if ( !is_hvm_vcpu(current) )
+            if ( !is_hvm_vcpu(current) && 
+                 !paging_mode_translate(current->domain) )  /* hybrid */
                 fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
                              (1U << XENFEAT_highmem_assist) |
                              (1U << XENFEAT_gnttab_map_avail_bits);
             else
                 fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
                              (1U << XENFEAT_hvm_callback_vector);
+            if ( is_hybrid_vcpu(current) )
+                fi.submap |= (1U << XENFEAT_hvm_callback_vector);
 #endif
             break;
         default:
diff -r f2cf898c7ff8 xen/common/memory.c
--- a/xen/common/memory.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/common/memory.c	Thu Nov 17 15:37:30 2011 -0800
@@ -89,7 +89,7 @@ static void increase_reservation(struct 
     a->nr_done = i;
 }
 
-static void populate_physmap(struct memop_args *a)
+static noinline void populate_physmap(struct memop_args *a)
 {
     struct page_info *page;
     unsigned long i, j;
@@ -134,6 +134,7 @@ static void populate_physmap(struct memo
             }
 
             mfn = page_to_mfn(page);
+
             guest_physmap_add_page(d, gpfn, mfn, a->extent_order);
 
             if ( !paging_mode_translate(d) )
diff -r f2cf898c7ff8 xen/common/timer.c
--- a/xen/common/timer.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/common/timer.c	Thu Nov 17 15:37:30 2011 -0800
@@ -546,13 +546,20 @@ void kdb_dump_timer_queues(void)
     struct timers *ts;
     unsigned long sz, offs;
     char buf[KSYM_NAME_LEN+1];
-    int            cpu, j;
-    s_time_t       now = NOW();
+    int cpu, j;
+    u64 tsc;
 
     for_each_online_cpu( cpu )
     {
         ts = &per_cpu(timers, cpu);
-        kdbp("CPU[%02d]: NOW:0x%08x%08x\n", cpu, (u32)(now>>32), (u32)now);
+        kdbp("CPU[%02d]:", cpu);
+
+        if (cpu == smp_processor_id()) {
+            s_time_t now = NOW();
+            rdtscll(tsc);
+            kdbp("NOW:0x%08x%08x TSC:0x%016lx\n", (u32)(now>>32),(u32)now, tsc);
+        } else
+            kdbp("\n");
 
         /* timers in the heap */
         for ( j = 1; j <= GET_HEAP_SIZE(ts->heap); j++ ) {
diff -r f2cf898c7ff8 xen/include/asm-x86/desc.h
--- a/xen/include/asm-x86/desc.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/desc.h	Thu Nov 17 15:37:30 2011 -0800
@@ -58,7 +58,8 @@
 #ifndef __ASSEMBLY__
 
 #if defined(__x86_64__)
-#define GUEST_KERNEL_RPL(d) (is_pv_32bit_domain(d) ? 1 : 3)
+#define GUEST_KERNEL_RPL(d) (is_hybrid_domain(d) ? 0 : \
+                      is_pv_32bit_domain(d) ? 1 : 3)
 #elif defined(__i386__)
 #define GUEST_KERNEL_RPL(d) ((void)(d), 1)
 #endif
@@ -67,6 +68,9 @@
 #define __fixup_guest_selector(d, sel)                             \
 ({                                                                 \
     uint16_t _rpl = GUEST_KERNEL_RPL(d);                           \
+    if (d->is_hybrid) {                                      \
+        printk("MUK: hybrid domain fixing up selector\n");          \
+    }                                                              \
     (sel) = (((sel) & 3) >= _rpl) ? (sel) : (((sel) & ~3) | _rpl); \
 })
 
diff -r f2cf898c7ff8 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/domain.h	Thu Nov 17 15:37:30 2011 -0800
@@ -18,7 +18,7 @@
 #endif
 #define is_pv_32on64_vcpu(v)   (is_pv_32on64_domain((v)->domain))
 
-#define is_hvm_pv_evtchn_domain(d) (is_hvm_domain(d) && \
+#define is_hvm_pv_evtchn_domain(d) (is_hvm_or_hyb_domain(d) && \
         d->arch.hvm_domain.irq.callback_via_type == HVMIRQ_callback_vector)
 #define is_hvm_pv_evtchn_vcpu(v) (is_hvm_pv_evtchn_domain(v->domain))
 
diff -r f2cf898c7ff8 xen/include/asm-x86/event.h
--- a/xen/include/asm-x86/event.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/event.h	Thu Nov 17 15:37:30 2011 -0800
@@ -18,7 +18,7 @@ int hvm_local_events_need_delivery(struc
 static inline int local_events_need_delivery(void)
 {
     struct vcpu *v = current;
-    return (is_hvm_vcpu(v) ? hvm_local_events_need_delivery(v) :
+    return ( is_hvm_or_hyb_vcpu(v) ? hvm_local_events_need_delivery(v) :
             (vcpu_info(v, evtchn_upcall_pending) &&
              !vcpu_info(v, evtchn_upcall_mask)));
 }
diff -r f2cf898c7ff8 xen/include/asm-x86/guest_access.h
--- a/xen/include/asm-x86/guest_access.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/guest_access.h	Thu Nov 17 15:37:30 2011 -0800
@@ -14,19 +14,19 @@
 
 /* Raw access functions: no type checking. */
 #define raw_copy_to_guest(dst, src, len)        \
-    (is_hvm_vcpu(current) ?                     \
+    ((is_hvm_vcpu(current) || is_hyb_hap_vcpu(current)) ?  \
      copy_to_user_hvm((dst), (src), (len)) :    \
      copy_to_user((dst), (src), (len)))
 #define raw_copy_from_guest(dst, src, len)      \
-    (is_hvm_vcpu(current) ?                     \
+    ((is_hvm_vcpu(current) || is_hyb_hap_vcpu(current)) ?  \
      copy_from_user_hvm((dst), (src), (len)) :  \
      copy_from_user((dst), (src), (len)))
 #define __raw_copy_to_guest(dst, src, len)      \
-    (is_hvm_vcpu(current) ?                     \
+    ((is_hvm_vcpu(current) || is_hyb_hap_vcpu(current)) ?  \
      copy_to_user_hvm((dst), (src), (len)) :    \
      __copy_to_user((dst), (src), (len)))
 #define __raw_copy_from_guest(dst, src, len)    \
-    (is_hvm_vcpu(current) ?                     \
+    ((is_hvm_vcpu(current) || is_hyb_hap_vcpu(current)) ?  \
      copy_from_user_hvm((dst), (src), (len)) :  \
      __copy_from_user((dst), (src), (len)))
 
diff -r f2cf898c7ff8 xen/include/asm-x86/hvm/domain.h
--- a/xen/include/asm-x86/hvm/domain.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/hvm/domain.h	Thu Nov 17 15:37:30 2011 -0800
@@ -98,5 +98,8 @@ struct hvm_domain {
     };
 };
 
+#define hap_enabled(d)    \
+    (is_hvm_or_hyb_domain(d) && (d)->arch.hvm_domain.hap_enabled)
+
 #endif /* __ASM_X86_HVM_DOMAIN_H__ */
 
diff -r f2cf898c7ff8 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/hvm/hvm.h	Thu Nov 17 15:37:30 2011 -0800
@@ -144,10 +144,12 @@ struct hvm_function_table {
 extern struct hvm_function_table hvm_funcs;
 extern int hvm_enabled;
 
+int hybrid_domain_initialise(struct domain *d);
 int hvm_domain_initialise(struct domain *d);
 void hvm_domain_relinquish_resources(struct domain *d);
 void hvm_domain_destroy(struct domain *d);
 
+int hybrid_vcpu_initialise(struct vcpu *v);
 int hvm_vcpu_initialise(struct vcpu *v);
 void hvm_vcpu_destroy(struct vcpu *v);
 void hvm_vcpu_down(struct vcpu *v);
diff -r f2cf898c7ff8 xen/include/asm-x86/hvm/vmx/vmx.h
--- a/xen/include/asm-x86/hvm/vmx/vmx.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h	Thu Nov 17 15:37:30 2011 -0800
@@ -110,6 +110,7 @@ void vmx_update_debug_state(struct vcpu 
 #define EXIT_REASON_EPT_VIOLATION       48
 #define EXIT_REASON_EPT_MISCONFIG       49
 #define EXIT_REASON_RDTSCP              51
+#define EXIT_REASON_INVVPID             53
 #define EXIT_REASON_WBINVD              54
 #define EXIT_REASON_XSETBV              55
 
@@ -284,6 +285,14 @@ static inline unsigned long __vmread_saf
     return ecx;
 }
 
+static inline unsigned long vmr(unsigned long field)
+{
+    int rc;
+    unsigned long val;
+    val = __vmread_safe(field, &rc);
+    return rc ? 0 : val;
+}
+
 static inline void __vm_set_bit(unsigned long field, unsigned int bit)
 {
     __vmwrite(field, __vmread(field) | (1UL << bit));
@@ -410,6 +419,8 @@ void vmx_inject_nmi(void);
 void ept_p2m_init(struct domain *d);
 void ept_walk_table(struct domain *d, unsigned long gfn);
 
+void hybrid_vmx_vmexit_handler(struct cpu_user_regs *regs);
+
 /* EPT violation qualifications definitions */
 #define _EPT_READ_VIOLATION         0
 #define EPT_READ_VIOLATION          (1UL<<_EPT_READ_VIOLATION)
@@ -430,4 +441,39 @@ void ept_walk_table(struct domain *d, un
 
 #define EPT_PAGETABLE_ENTRIES       512
 
+/*  
+ * Not all cases receive valid value in the VM-exit instruction length field.
+ * Callers must know what they're doing!
+ */ 
+static inline int __get_instruction_length(void)
+{   
+    int len;
+    len = __vmread(VM_EXIT_INSTRUCTION_LEN); /* Safe: callers audited */
+    BUG_ON((len < 1) || (len > 15));
+    return len;
+}
+
+static inline void __update_guest_eip(unsigned long inst_len)
+{
+    struct cpu_user_regs *regs = guest_cpu_user_regs();
+    unsigned long x;
+    
+    regs->eip += inst_len;
+    regs->eflags &= ~X86_EFLAGS_RF;
+    
+    x = __vmread(GUEST_INTERRUPTIBILITY_INFO);
+    if ( x & (VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS) )
+    {
+        x &= ~(VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS);
+        __vmwrite(GUEST_INTERRUPTIBILITY_INFO, x);
+    }
+    
+    if ( regs->eflags & X86_EFLAGS_TF )
+        vmx_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE);
+}   
+
+extern void vmx_dr_access(unsigned long, struct cpu_user_regs *);
+extern void vmx_fpu_enter(struct vcpu *v);
+extern void vmx_fpu_dirty_intercept(void);
+
 #endif /* __ASM_X86_HVM_VMX_VMX_H__ */
diff -r f2cf898c7ff8 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/public/domctl.h	Thu Nov 17 15:37:30 2011 -0800
@@ -64,6 +64,9 @@ struct xen_domctl_createdomain {
  /* Disable out-of-sync shadow page tables? */
 #define _XEN_DOMCTL_CDF_oos_off       3
 #define XEN_DOMCTL_CDF_oos_off        (1U<<_XEN_DOMCTL_CDF_oos_off)
+ /* Is this a hybrid guest? */
+#define _XEN_DOMCTL_CDF_hybrid_guest  4
+#define XEN_DOMCTL_CDF_hybrid_guest   (1U<<_XEN_DOMCTL_CDF_hybrid_guest)
 };
 typedef struct xen_domctl_createdomain xen_domctl_createdomain_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_createdomain_t);
@@ -93,6 +96,9 @@ struct xen_domctl_getdomaininfo {
  /* Being debugged.  */
 #define _XEN_DOMINF_debugged  6
 #define XEN_DOMINF_debugged   (1U<<_XEN_DOMINF_debugged)
+ /* domain is hybrid */
+#define _XEN_DOMINF_hybrid_guest 7
+#define XEN_DOMINF_hybrid_guest   (1U<<_XEN_DOMINF_hybrid_guest)
  /* XEN_DOMINF_shutdown guest-supplied code.  */
 #define XEN_DOMINF_shutdownmask 255
 #define XEN_DOMINF_shutdownshift 16
diff -r f2cf898c7ff8 xen/include/public/xen.h
--- a/xen/include/public/xen.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/public/xen.h	Thu Nov 17 15:37:30 2011 -0800
@@ -594,6 +594,7 @@ typedef struct start_info start_info_t;
 #define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
 #define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
 #define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
+#define SIF_IS_HYBRID     (1<<3)  /* Is it a PV running in HVM container? */
 #define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
 
 /*
diff -r f2cf898c7ff8 xen/include/xen/lib.h
--- a/xen/include/xen/lib.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/xen/lib.h	Thu Nov 17 15:37:30 2011 -0800
@@ -39,6 +39,17 @@ do {                                    
 #else
 #define ASSERT(p) ((void)0)
 #endif
+#ifdef XEN_KDB_CONFIG
+    #define KASSERT(p)                                                \
+      do { if (!(p)) {                                                \
+               kdbp("KASSERT in %s at %d\n", __FUNCTION__, __LINE__); \
+               kdb_trap_immed(KDB_TRAP_NONFATAL);                     \
+           }                                                          \
+      } while (0)
+#else
+#define KASSERT(p) \
+    do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
+#endif
 
 #define ABS(_x) ({                              \
     typeof(_x) __x = (_x);                      \
@@ -126,6 +137,8 @@ extern void add_taint(unsigned);
 extern void kdb_trap_immed(int);
 extern void kdbtrc(unsigned int, unsigned int, uint64_t, uint64_t, uint64_t);
 extern void kdbp(const char *fmt, ...);
+extern volatile int mukkdbdbg;
+#define mukkdbp(...) {(mukkdbdbg) ? kdbp(__VA_ARGS__):0;}
 #endif
 
 #endif /* __LIB_H__ */
diff -r f2cf898c7ff8 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/xen/sched.h	Thu Nov 17 15:37:30 2011 -0800
@@ -228,6 +228,7 @@ struct domain
 
     /* Is this an HVM guest? */
     bool_t           is_hvm;
+    bool_t           is_hybrid;
     /* Does this guest need iommu mappings? */
     bool_t           need_iommu;
     /* Is this guest fully privileged (aka dom0)? */
@@ -388,6 +389,9 @@ struct domain *domain_create(
  /* DOMCRF_oos_off: dont use out-of-sync optimization for shadow page tables */
 #define _DOMCRF_oos_off         4
 #define DOMCRF_oos_off          (1U<<_DOMCRF_oos_off)
+ /* DOMCRF_hybrid: Create PV domain in HVM container */
+#define _DOMCRF_hybrid          5
+#define DOMCRF_hybrid           (1U<<_DOMCRF_hybrid)
 
 /*
  * rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
@@ -590,10 +594,17 @@ uint64_t get_cpu_idle_time(unsigned int 
 
 #define is_hvm_domain(d) ((d)->is_hvm)
 #define is_hvm_vcpu(v)   (is_hvm_domain(v->domain))
+#define is_hybrid_domain(d) ((d)->is_hybrid)
+#define is_hybrid_vcpu(v)   (is_hybrid_domain(v->domain))
+#define is_hvm_or_hyb_domain(d) (is_hvm_domain(d) || is_hybrid_domain(d))
+#define is_hvm_or_hyb_vcpu(v) (is_hvm_or_hyb_domain(v->domain))
 #define is_pinned_vcpu(v) ((v)->domain->is_pinned || \
                            cpus_weight((v)->cpu_affinity) == 1)
 #define need_iommu(d)    ((d)->need_iommu)
 
+#define is_hyb_hap_domain(d) (is_hybrid_domain(d) && hap_enabled(d))
+#define is_hyb_hap_vcpu(v) (is_hyb_hap_domain(v->domain))
+
 void set_vcpu_migration_delay(unsigned int delay);
 unsigned int get_vcpu_migration_delay(void);
 
diff -r f2cf898c7ff8 xen/include/xen/xencomm.h
--- a/xen/include/xen/xencomm.h	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/include/xen/xencomm.h	Thu Nov 17 15:37:30 2011 -0800
@@ -79,7 +79,7 @@ static inline unsigned long xencomm_inli
  * Copy an array of objects from guest context via a guest handle.
  * Optionally specify an offset into the guest array.
  */
-#define copy_from_guest_offset(ptr, hnd, idx, nr) \
+#define copy_from_guest_offset(ptr, hnd, idx, nr) \ JUNK
     __copy_from_guest_offset(ptr, hnd, idx, nr)
 
 /* Copy sub-field of a structure from guest context via a guest handle. */
diff -r f2cf898c7ff8 xen/kdb/kdb_cmds.c
--- a/xen/kdb/kdb_cmds.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/kdb/kdb_cmds.c	Thu Nov 17 15:37:30 2011 -0800
@@ -173,7 +173,7 @@ kdb_do_cmds(struct cpu_user_regs *regs)
 
 /* ===================== Util functions  ==================================== */
 
-static int
+int
 kdb_vcpu_valid(struct vcpu *in_vp)
 {
     struct domain *dp;
@@ -298,15 +298,13 @@ kdb_str2domid(const char *domstr, domid_
 }
 
 static struct domain *
-kdb_strdomid2ptr(const char *domstr)
+kdb_strdomid2ptr(const char *domstr, int perror)
 {
-    ulong l;
-    struct domain *dp;
-    if (!kdb_str2ulong(domstr, &l) || !(dp=kdb_domid2ptr((domid_t)l))) {
-        kdbp("Invalid domid:%s\n", domstr);
-        return NULL;
-    } else
-        return dp;
+    domid_t domid;
+    if (kdb_str2domid(domstr, &domid, perror)) {
+        return(kdb_domid2ptr(domid));
+    }
+    return NULL;
 }
 
 /* return a guest bitness: 32 or 64 */
@@ -319,7 +317,7 @@ kdb_guest_bitness(domid_t domid)
 
     if (is_idle_domain(dp))
         retval = HYPSZ;
-    else if (is_hvm_domain(dp))
+    else if (is_hvm_or_hyb_domain(dp))
         retval = (hvm_long_mode_enabled(dp->vcpu[0])) ? HYPSZ : 32;
     else 
         retval = is_pv_32bit_domain(dp) ? 32 : HYPSZ;
@@ -825,7 +823,7 @@ struct  Xgt_desc_struct {
     unsigned long address __attribute__((packed));
 };
 
-static void
+void
 kdb_show_special_regs(struct cpu_user_regs *regs)
 {
     struct Xgt_desc_struct desc;
@@ -958,7 +956,8 @@ kdb_cmdf_ss(int argc, const char **argv,
     #define KDB_HALT_INSTR 0xf4
 
     kdbbyt_t byte;
-    domid_t id = guest_mode(regs) ? current->domain->domain_id : DOMID_IDLE;
+    struct domain *dp = current->domain;
+    domid_t id = guest_mode(regs) ? dp->domain_id : DOMID_IDLE;
 
     if (argc > 1 && *argv[1] == '?')
         return kdb_usgf_ss();
@@ -977,16 +976,12 @@ kdb_cmdf_ss(int argc, const char **argv,
         kdbp("kdb: Failed to read byte at: %lx\n", regs->KDBIP);
         return KDB_CPU_MAIN_KDB;
     }
-    if (guest_mode(regs) && is_hvm_vcpu(current))
+    if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current)) {
+        dp->debugger_attached = 1;  /* see svm_do_resume/vmx_do_ */
         current->arch.hvm_vcpu.single_step = 1;
-    else
+    } else
         regs->eflags |= X86_EFLAGS_TF;
-#if 0
-    if (guest_mode(regs) && is_hvm_vcpu(current)) {
-        struct domain *dp = current->domain;
-        dp->debugger_attached = 1;  /* see svm_do_resume/vmx_do_ */
-    }
-#endif
+
     return KDB_CPU_SS;
 }
 
@@ -1052,7 +1047,7 @@ kdb_cmdf_ssb(int argc, const char **argv
         kdbp("%s: regs not available\n", __FUNCTION__);
         return KDB_CPU_MAIN_KDB;
     }
-    if (is_hvm_vcpu(current)) 
+    if (is_hvm_or_hyb_vcpu(current)) 
         current->domain->debugger_attached = 1;        /* vmx/svm_do_resume()*/
 
     regs->eflags |= X86_EFLAGS_TF;
@@ -1640,7 +1635,7 @@ kdb_set_bp(domid_t domid, kdbva_t addr, 
         return KDBMAXSBP;
     }
     /* make sure swbp reporting is enabled in the vmcb/vmcs */
-    if (is_hvm_domain(kdb_domid2ptr(domid))) {
+    if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
         struct domain *dp = kdb_domid2ptr(domid);
         dp->debugger_attached = 1;              /* see svm_do_resume/vmx_do_ */
         KDBGP("debugger_attached set. domid:%d\n", domid);
@@ -1693,7 +1688,7 @@ kdb_cmdf_bp(int argc, const char **argv,
     if (domidstrp && !kdb_str2domid(domidstrp, &domid, 1)) {
         return kdb_usgf_bp();
     }
-    if (argc > 3 && is_hvm_domain(kdb_domid2ptr(domid))) {
+    if (argc > 3 && is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
         kdbp("HVM domain not supported yet for conditional bp\n");
         return KDB_CPU_MAIN_KDB;
     }
@@ -1741,7 +1736,7 @@ kdb_cmdf_btp(int argc, const char **argv
     argsidx = 2;                   /* assume 3rd arg is not domid */
     if (argc > 3 && kdb_str2domid(argv[2], &domid, 0)) {
 
-        if (is_hvm_domain(kdb_domid2ptr(domid))) {
+        if (is_hvm_or_hyb_domain(kdb_domid2ptr(domid))) {
             kdbp("HVM domains are not currently supprted\n");
             return KDB_CPU_MAIN_KDB;
         } else
@@ -1893,7 +1888,7 @@ kdb_cmdf_vcpuh(int argc, const char **ar
         return kdb_usgf_vcpuh();
 
     if (!kdb_str2ulong(argv[1], (ulong *)&vp) || !kdb_vcpu_valid(vp) ||
-        !is_hvm_vcpu(vp)) {
+        !is_hvm_or_hyb_vcpu(vp)) {
 
         kdbp("kdb: Bad VCPU: %s\n", argv[1]);
         return KDB_CPU_MAIN_KDB;
@@ -2042,11 +2037,12 @@ kdb_display_vcpu(struct vcpu *vp)
     kdbp("  cpu_affinity:0x%lx vcpu_dirty_cpumask:0x%lx sched_priv:0x%p\n",
          vp->cpu_affinity.bits[0], vp->vcpu_dirty_cpumask.bits[0],
          vp->sched_priv);
-    kdbp("  &runstate: %p state: %x\n", &vp->runstate, vp->runstate.state);
+    kdbp("  &runstate: %p state: %x guestptr:%p\n", &vp->runstate, 
+         vp->runstate.state, runstate_guest(vp));
     kdbp("\n");
     kdbp("  arch info: (%p)\n", &vp->arch);
     kdbp("    guest_context: VGCF_ flags:%lx", gp->flags); /* VGCF_in_kernel */
-    if (is_hvm_vcpu(vp))
+    if (is_hvm_or_hyb_vcpu(vp))
         kdbp("    (HVM guest: IP, SP, EFLAGS may be stale)");
     kdbp("\n");
     kdb_print_uregs(&gp->user_regs);
@@ -2146,7 +2142,7 @@ static void kdb_pr_dom_pg_modes(struct d
         if ( paging_mode_external(d) )
             kdbp(" external(PG_external) ");
     } else
-        kdbp("disabled");
+        kdbp(" disabled");
     kdbp("\n");
 }
 
@@ -2198,6 +2194,19 @@ static void noinline kdb_print_dom_event
 #endif
 }
 
+static void kdb_prnt_hvm_dom_info(struct domain *dp)
+{
+    kdbp("    HVM info: Hap is%s enabled\n", 
+         dp->arch.hvm_domain.hap_enabled ? "" : " not");
+
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+        struct vmx_domain *vdp = &dp->arch.hvm_domain.vmx;
+        kdbp("    EPT: ept_mt:%x ept_wl:%x asr:%013lx\n", 
+             vdp->ept_control.ept_mt, vdp->ept_control.ept_wl, 
+             vdp->ept_control.asr);
+    }
+}
+
 /* display one domain info */
 static void
 kdb_display_dom(struct domain *dp)
@@ -2240,9 +2249,9 @@ kdb_display_dom(struct domain *dp)
         kdbp("    mapcnt:");
         kdb_print_spin_lock("mapcnt: lk:", &gp->lock, "\n");
     }
-    kdbp("  hvm:%d priv:%d dbg:%d dying:%d paused:%d\n",
-         dp->is_hvm, dp->is_privileged, dp->debugger_attached,
-         dp->is_dying, dp->is_paused_by_controller);
+    kdbp("  hvm:%d hybrid:%d priv:%d dbg:%d dying:%d paused:%d\n",
+         dp->is_hvm, dp->is_hybrid, dp->is_privileged, 
+         dp->debugger_attached, dp->is_dying, dp->is_paused_by_controller);
     kdb_print_spin_lock("  shutdown: lk:", &dp->shutdown_lock, "\n");
     kdbp("  shutn:%d shut:%d code:%d \n", dp->is_shutting_down,
          dp->is_shut_down, dp->shutdown_code);
@@ -2266,7 +2275,10 @@ kdb_display_dom(struct domain *dp)
     kdbp("    &mapchache:0x%xp\n", &ap->mapcache);
 #endif
     kdbp("    ioport:0x%p &hvm_dom:0x%p\n", ap->ioport_caps, &ap->hvm_domain);
-    kdbp("    &pging_dom:%p mode:%lx", &ap->paging, ap->paging.mode); 
+    if (is_hvm_or_hyb_domain(dp))
+        kdb_prnt_hvm_dom_info(dp);
+
+    kdbp("    &pging_dom:%p mode: %lx", &ap->paging, ap->paging.mode); 
     kdb_pr_dom_pg_modes(dp);
     kdbp("    p2m ptr:%p  pages:{%p, %p}\n", ap->p2m, ap->p2m->pages.next,
          KDB_PGLLE(ap->p2m->pages));
@@ -2556,7 +2568,7 @@ kdb_cmdf_didt(int argc, const char **arg
 }
 #endif
 
-struct gdte {
+struct gdte {             /* same for TSS and LDT */
     ulong limit0:16;
     ulong base0:24;       /* linear address base, not pa */
     ulong acctype:4;      /* Type: access rights */
@@ -2576,15 +2588,23 @@ union gdte_u {
     u64 gval;
 };
 
-struct sgdte {           /* system gdte */
+struct call_gdte {
     unsigned short offs0:16;
     unsigned short sel:16;
     unsigned short misc0:16;
     unsigned short offs1:16;
 };
 
+struct idt_gdte {
+    unsigned long offs0:16;
+    unsigned long sel:16;
+    unsigned long ist:3;
+    unsigned long unused0:13;
+    unsigned long offs1:16;
+};
 union sgdte_u {
-    struct sgdte sgdte;
+    struct call_gdte cgdte;
+    struct idt_gdte igdte;
     u64 sgval;
 };
 
@@ -2611,7 +2631,7 @@ static char *kdb_ret_acctype(uint acctyp
 static kdb_cpu_cmd_t
 kdb_usgf_dgdt(void)
 {
-    kdbp("dgdt [gdt-ptr hex-gdt-size] dump GDT table on current cpu or for "
+    kdbp("dgdt [gdt-ptr decimal-byte-size] dump GDT table on current cpu or for"
          "given vcpu\n");
     return KDB_CPU_MAIN_KDB;
 }
@@ -2620,9 +2640,9 @@ kdb_cmdf_dgdt(int argc, const char **arg
 {
     struct Xgt_desc_struct desc;
     union gdte_u u1;
-    ulong addr, end;
+    ulong start_addr, end_addr, taddr=0;
     domid_t domid = DOMID_IDLE;
-    int i;
+    int idx;
 
     if (argc > 1 && *argv[1] == '?')
         return kdb_usgf_dgdt();
@@ -2631,62 +2651,62 @@ kdb_cmdf_dgdt(int argc, const char **arg
         if (argc != 3)
             return kdb_usgf_dgdt();
 
-        if (kdb_str2ulong(argv[1], (ulong *)&addr) && 
-            kdb_str2ulong(argv[2], (ulong *)&end)) {
-            end += addr;
+        if (kdb_str2ulong(argv[1], (ulong *)&start_addr) && 
+            kdb_str2deci(argv[2], (int *)&taddr)) {
+            end_addr = start_addr + taddr;
         } else {
             kdbp("dgdt: Bad arg:%s or %s\n", argv[1], argv[2]);
             return kdb_usgf_dgdt();
         }
     } else {
         __asm__ __volatile__ ("sgdt  (%0) \n" :: "a"(&desc) : "memory");
-        addr = (ulong)desc.address; 
-        end = (ulong)desc.address + desc.size;
+        start_addr = (ulong)desc.address; 
+        end_addr = (ulong)desc.address + desc.size;
     }
-    kdbp("GDT: Will skip null desc at 0, addr:%lx end:%lx\n", addr, end);
-    addr += 8;         /* skip null descriptor */
-
+    kdbp("GDT: Will skip null desc at 0, start:%lx end:%lx\n", start_addr, 
+         end_addr);
     kdbp("[idx]   sel --- val --------  Accs DPL P AVL L DB G "
          "--Base Addr ----  Limit\n");
     kdbp("                              Type\n");
 
-    for (i=1;  addr < end;  i++, addr += sizeof(ulong)) {
+    /* skip first 8 null bytes */
+    /* the cpu multiplies the index by 8 and adds to GDT.base */
+    for (taddr = start_addr+8; taddr < end_addr;  taddr += sizeof(ulong)) {
 
         /* not all entries are mapped. do this to avoid GP even if hyp */
-        if (!kdb_read_mem(addr, (kdbbyt_t *)&u1, sizeof(u1),domid) || !u1.gval)
+        if (!kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1),domid) || !u1.gval)
             continue;
 
         if (u1.gval == 0xffffffffffffffff || u1.gval == 0x5555555555555555)
             continue;               /* what an effin x86 mess */
 
+        idx = (taddr - start_addr) / 8;
         if (u1.gdte.S == 0) {       /* System Desc are 16 bytes in 64bit mode */
-            addr += sizeof(ulong);
-            i++;
+            taddr += sizeof(ulong);
             continue;
         }
+kdbp("ADDR: %lx\n", taddr);
         kdbp("[%04x] %04x %016lx  %4s  %x  %d  %d  %d  %d %d %016lx  %05x\n",
-             i, (i<<3), u1.gval, kdb_ret_acctype(u1.gdte.acctype), u1.gdte.DPL, 
+             idx, (idx<<3), u1.gval, kdb_ret_acctype(u1.gdte.acctype), 
+             u1.gdte.DPL, 
              u1.gdte.P, u1.gdte.AVL, u1.gdte.L, u1.gdte.DB, u1.gdte.G,  
              (u64)((u64)u1.gdte.base0 | (u64)((u64)u1.gdte.base1<<24)), 
              u1.gdte.limit0 | (u1.gdte.limit1<<16));
     }
 
-    kdbp("\nSystem descriptors (S=0) :\n");
-    addr = (ulong)desc.address + 8;         /* skip null descriptor */
-
-    for (i=1;  addr < end;  i++, addr += sizeof(ulong)) {
-        union sgdte_u u2;
+    kdbp("\nSystem descriptors (S=0) : (skipping 0th entry)\n");
+    for (taddr=start_addr+8;  taddr < end_addr;  taddr += sizeof(ulong)) {
         uint acctype;
-        u64 upper, offs0_64=0, offs32_63=0;
+        u64 upper, addr64=0;
 
         /* not all entries are mapped. do this to avoid GP even if hyp */
-        if (kdb_read_mem(addr, (kdbbyt_t *)&u1, sizeof(u1),domid)==0 || 
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&u1, sizeof(u1), domid)==0 || 
             u1.gval == 0 || u1.gdte.S == 1) {
             continue;
         }
-
-        addr += sizeof(ulong);
-        if (kdb_read_mem(addr, (kdbbyt_t *)&upper, 8, domid) == 0) {
+        idx = (taddr - start_addr) / 8;
+        taddr += sizeof(ulong);
+        if (kdb_read_mem(taddr, (kdbbyt_t *)&upper, 8, domid) == 0) {
             kdbp("Could not read upper 8 bytes of system desc\n");
             upper = 0;
         }
@@ -2695,11 +2715,11 @@ kdb_cmdf_dgdt(int argc, const char **arg
             acctype != 14 && acctype != 15)
             continue;
 
-        kdbp("[%04x] %04x  val:%016lx DPL:%x P:%d acctype:%x ",
-             i, (i<<3), u1.gval, u1.gdte.DPL, u1.gdte.P, acctype); 
-
-        u2.sgval = u1.gval;
-        offs32_63 = (u64)((upper & 0xFFFFFFFF)) << 32;
+kdbp("ADDR: %lx\n", taddr);
+        kdbp("[%04x] %04x val:%016lx DPL:%x P:%d type:%x ",
+             idx, (idx<<3), u1.gval, u1.gdte.DPL, u1.gdte.P, acctype); 
+
+        upper = (u64)((u64)(upper & 0xFFFFFFFF) << 32);
 
         /* Vol 3A: table: 3-2  page: 3-19 */
         if (acctype == 2) {
@@ -2722,17 +2742,28 @@ kdb_cmdf_dgdt(int argc, const char **arg
         }
 
         if (acctype == 2 || acctype == 9 || acctype == 11) {
-            kdbp("        AVL:%d L:%d D/B:%d G:%d Base Addr:%016lx Limit:%x\n",
-                 u1.gdte.AVL, u1.gdte.L, u1.gdte.DB, u1.gdte.G,  
-                 u1.gdte.base0 | (u1.gdte.base1<<24) | offs32_63,
-                 u1.gdte.limit0 | (u1.gdte.limit1<<16));
-
-        } else if (acctype == 12 || acctype == 14 || acctype == 15) {
-            offs0_64 = u2.sgdte.offs0 | (u64)u2.sgdte.offs1<<48 | offs32_63;
-            kdbp("        Entry: %04x:%016lx\n", u2.sgdte.sel, offs0_64);
-        }
-
-        i++;
+            kdbp("        AVL:%d G:%d Base Addr:%016lx Limit:%x\n",
+                 u1.gdte.AVL, u1.gdte.G,  
+                 (u64)((u64)u1.gdte.base0 | ((u64)u1.gdte.base1<<24)| upper),
+                 (u32)u1.gdte.limit0 | (u32)((u32)u1.gdte.limit1<<16));
+
+        } else if (acctype == 12) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.cgdte.offs0 | 
+                           (u64)((u64)u2.cgdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx\n", u2.cgdte.sel, addr64);
+        } else if (acctype == 14 || acctype == 15) {
+            union sgdte_u u2;
+            u2.sgval = u1.gval;
+
+            addr64 = (u64)((u64)u2.igdte.offs0 | 
+                           (u64)((u64)u2.igdte.offs1<<16) | upper);
+            kdbp("        Entry: %04x:%016lx ist:%03x\n", u2.igdte.sel, addr64,
+                 u2.igdte.ist);
+        } else 
+            kdbp(" Error: Unrecongized type:%lx\n", acctype);
     }
     return KDB_CPU_MAIN_KDB;
 }
@@ -2781,6 +2812,7 @@ kdb_cmdf_mmu(int argc, const char **argv
     kdbp("CONFIG_PAGING_LEVELS:%d\n", CONFIG_PAGING_LEVELS);
     kdbp("__HYPERVISOR_COMPAT_VIRT_START: %lx\n", 
          (ulong)__HYPERVISOR_COMPAT_VIRT_START);
+    kdbp("&MPT[0] == %016lx\n", &machine_to_phys_mapping[0]);
 
     kdbp("\nFIRST_RESERVED_GDT_PAGE: %x\n", FIRST_RESERVED_GDT_PAGE);
     kdbp("FIRST_RESERVED_GDT_ENTRY: %lx\n", (ulong)FIRST_RESERVED_GDT_ENTRY);
@@ -2794,11 +2826,17 @@ kdb_cmdf_mmu(int argc, const char **argv
         kdbp("\tcpu:%d  gdt_table:%p\n", cpu, per_cpu(compat_gdt_table, cpu));
     }
     kdbp("\n");
+    kdbp("  Per cpu tss:\n");
+    for_each_online_cpu(cpu) {
+        struct tss_struct *tssp = &per_cpu(init_tss, cpu);
+        kdbp("\tcpu:%d  tss:%p (rsp0:%016lx)\n", cpu, tssp, tssp->rsp0);
+    }
 #ifdef USER_MAPPINGS_ARE_GLOBAL
     kdbp("USER_MAPPINGS_ARE_GLOBAL is defined\n");
 #else
     kdbp("USER_MAPPINGS_ARE_GLOBAL is NOT defined\n");
 #endif
+    kdbp("\n");
     return KDB_CPU_MAIN_KDB;
 }
 
@@ -2873,8 +2911,8 @@ kdb_cmdf_p2m(int argc, const char **argv
     struct domain *dp;
     ulong gpfn;
 
-    if (argc < 3                                ||
-        (dp=kdb_strdomid2ptr(argv[1])) == NULL  ||
+    if (argc < 3                                   ||
+        (dp=kdb_strdomid2ptr(argv[1], 1)) == NULL  ||
         !kdb_str2ulong(argv[2], &gpfn)) {
 
         return kdb_usgf_p2m();
@@ -3408,6 +3446,7 @@ kdb_cmdf_info(int argc, const char **arg
         kdbp(" CONFIG_PAGING_ASSISTANCE");
 #endif
     kdbp("\n");
+    kdbp("MAX_VIRT_CPUS:$%d  MAX_HVM_VCPUS:$%d\n", MAX_VIRT_CPUS,MAX_HVM_VCPUS);
     kdbp("NR_EVENT_CHANNELS: $%d\n", NR_EVENT_CHANNELS);
     kdbp("NR_EVTCHN_BUCKETS: $%d\n", NR_EVTCHN_BUCKETS);
 
diff -r f2cf898c7ff8 xen/kdb/kdb_io.c
--- a/xen/kdb/kdb_io.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/kdb/kdb_io.c	Thu Nov 17 15:37:30 2011 -0800
@@ -39,7 +39,7 @@ kdb_key_valid(int key)
 {
     /* note: isspace() is more than ' ', hence we don't use it here */
     if (isalnum(key) || key == ' ' || key == K_BACKSPACE || key == '\n' ||
-        key == '?' || key == K_UNDERSCORE || key == '=')
+        key == '?' || key == K_UNDERSCORE || key == '=' || key == '!')
             return 1;
     return 0;
 }
diff -r f2cf898c7ff8 xen/kdb/kdbmain.c
--- a/xen/kdb/kdbmain.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/kdb/kdbmain.c	Thu Nov 17 15:37:30 2011 -0800
@@ -258,7 +258,7 @@ kdb_check_dbtrap(kdb_reason_t *reasp, in
                 KDBGP("ccpu:%d trapcpu:%d\n", ccpu, a_trap_cpu);
                 kdb_cpu_cmd[a_trap_cpu] = KDB_CPU_QUIT;
                 *reasp = KDB_REASON_PAUSE_IPI;
-                regs->eflags &= ~X86_EFLAGS_TF;
+                regs->eflags &= ~X86_EFLAGS_TF;  /* hvm: exit handler ss = 0 */
                 kdb_init_cpu = -1;
             } else {
                 kdb_end_session(ccpu, regs);
@@ -364,7 +364,10 @@ kdbmain(kdb_reason_t reason, struct cpu_
             }
         } else if (rc == 2) {        /* one of ours but condition not met */
                 kdb_begin_session();
-                regs->eflags |= X86_EFLAGS_TF;  
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
                 kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
                 goto out;
         }
@@ -401,7 +404,10 @@ kdbmain(kdb_reason_t reason, struct cpu_
             if (!cpus_empty(kdb_cpu_traps)) {
                 /* execute current instruction without 0xcc */
                 kdb_dbg_prnt_ctrps("nempty:", ccpu);
-                regs->eflags |= X86_EFLAGS_TF;  
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
                 kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
                 goto out;
             }
@@ -415,7 +421,10 @@ kdbmain(kdb_reason_t reason, struct cpu_
         if (kdb_swbp_exists()) {
             if (reason == KDB_REASON_BPEXCP) {
                 /* do delayed install */
-                regs->eflags |= X86_EFLAGS_TF;  
+                if (guest_mode(regs) && is_hvm_or_hyb_vcpu(current))
+                    current->arch.hvm_vcpu.single_step = 1;
+                else
+                    regs->eflags |= X86_EFLAGS_TF;  
                 kdb_cpu_cmd[ccpu] = KDB_CPU_INSTALL_BP;
                 goto out;
             } 
@@ -518,9 +527,7 @@ kdb_handle_trap_entry(int vector, struct
          * depending on the hardware. Also, for now assume it's fatal */
         KDBGP("kdbtrp:ccpu:%d vec:%d\n", ccpu, vector);
         rc = kdbmain_fatal(regs, TRAP_nmi);
-    } else {
-        KDBGP("kdbtrp: unhandled trap:ccpu:%d vec:%d\n", ccpu, vector);
-    }
+    } 
     return rc;
 }
 
@@ -659,7 +666,7 @@ kdb_gettrapname(int trapno)
 
 #define KDBTRCMAX 1       /* set this to max number of recs to trace. each rec 
                            * is 32 bytes */
-volatile int kdb_trcon=0; /* turn tracing ON: set here or via the trcon cmd */
+volatile int kdb_trcon=1; /* turn tracing ON: set here or via the trcon cmd */
 
 typedef struct {
     union {
diff -r f2cf898c7ff8 xen/kdb/x86/udis86-1.7/kdb_dis.c
--- a/xen/kdb/x86/udis86-1.7/kdb_dis.c	Fri Jul 15 23:21:24 2011 +0000
+++ b/xen/kdb/x86/udis86-1.7/kdb_dis.c	Thu Nov 17 15:37:30 2011 -0800
@@ -65,11 +65,13 @@ kdb_prnt_addr2sym(domid_t domid, kdbva_t
         p = kdb_guest_addr2sym(addr, domid, &offs);
     } else
         symbols_lookup(addr, &sz, &offs, buf);
+
     snprintf(pbuf, 150, "%s%s+%lx", prefix, p, offs);
     if (*nl != '\n')
         kdbp("%-30s%s", pbuf, nl);  /* prints more than 30 if needed */
     else
         kdbp("%s%s", pbuf, nl);
+
 }
 
 static int

--MP_/R.1sMt_LjPbCVVbgRW8Pwbf
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--MP_/R.1sMt_LjPbCVVbgRW8Pwbf--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 02:56:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 02:56:52 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RREdI-000346-9B
	for archives@lists.xen.org; Fri, 18 Nov 2011 02:56:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RREcx-0001W3-Ob; Thu, 17 Nov 2011 18:56:31 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RREbk-00018X-VG
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 18:55:17 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1321584913!2039073!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15925 invoked from network); 18 Nov 2011 02:55:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 02:55:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,530,1315180800"; 
   d="scan'208";a="9000359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 02:55:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 02:55:13 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RREbg-0001p0-Kl;
	Fri, 18 Nov 2011 02:55:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RREbg-0003wK-Dx;
	Fri, 18 Nov 2011 02:55:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9854-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 18 Nov 2011 02:55:12 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9854: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  e73ada19a69d
baseline version:
 xen                  9702967e89dd

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Gianluca Guida <gianluca.guida@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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


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

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

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


Pushing revision :

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

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 02:56:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 02:56:52 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RREdI-000346-9B
	for archives@lists.xen.org; Fri, 18 Nov 2011 02:56:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RREcx-0001W3-Ob; Thu, 17 Nov 2011 18:56:31 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RREbk-00018X-VG
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 18:55:17 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1321584913!2039073!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15925 invoked from network); 18 Nov 2011 02:55:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 02:55:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,530,1315180800"; 
   d="scan'208";a="9000359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 02:55:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 02:55:13 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RREbg-0001p0-Kl;
	Fri, 18 Nov 2011 02:55:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RREbg-0003wK-Dx;
	Fri, 18 Nov 2011 02:55:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9854-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 18 Nov 2011 02:55:12 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9854: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  e73ada19a69d
baseline version:
 xen                  9702967e89dd

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Gianluca Guida <gianluca.guida@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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


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

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

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


Pushing revision :

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

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 03:09:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 03:09:31 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RREpX-00034J-PW
	for archives@lists.xen.org; Fri, 18 Nov 2011 03:09:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RREpD-00025k-Db; Thu, 17 Nov 2011 19:09:11 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RREp7-00024r-Rn
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 19:09:06 -0800
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1321585740!4663837!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5184 invoked from network); 18 Nov 2011 03:09:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 03:09:02 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAI38trQ029723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 03:08:56 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAI38re9012510
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 03:08:53 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAI38jj0015146; Thu, 17 Nov 2011 21:08:45 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 19:08:45 -0800
Message-ID: <4EC5CC3B.4050808@oracle.com>
Date: Fri, 18 Nov 2011 11:08:43 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Re: [PATCH 1/3] xen/granttable: Introducing grant
	table V2 stucture
References: <4EC3B62F.6080702@oracle.com>	<1321451304-13559-1-git-send-email-annie.li@oracle.com>	<1321526148.3664.263.camel@zakaz.uk.xensource.com>	<4EC53119.7060307@oracle.com>
	<20111117162955.GA6758@phenom.dumpdata.com>
In-Reply-To: <20111117162955.GA6758@phenom.dumpdata.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4EC5CC4A.002B,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-11-18 0:29, Konrad Rzeszutek Wilk wrote:
>>> The more normal way to do this would be to make gnttab_interface a
>>> pointer, define gnttab_v1_ops and do:
>>> 	gnttab_interface =&gnttab_v1_ops;
>>> or if the pointer overhead is significant remove that and just do a
>>> struct assignment:
>>> 	gnttab_interface = gnttab_v1_ops;
>>>
>> If using this way, we need two more public structures(gnttab_v1_ops
>> and gnttab_v2_ops), and two more functions to initialize those two
>> structures and then initialize the pointer gnttab_interface. It is
>> more complicated, am i missing something?
> Why two functions? I agree on the structures - but they need not to be
> public (they can be static).
>
> For a good example look at how apic_physflat is done.
Thanks, static structure is simpler and clean. I am very glad to change 
that.:-)

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

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 03:09:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 03:09:31 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RREpX-00034J-PW
	for archives@lists.xen.org; Fri, 18 Nov 2011 03:09:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RREpD-00025k-Db; Thu, 17 Nov 2011 19:09:11 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RREp7-00024r-Rn
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 19:09:06 -0800
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1321585740!4663837!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5184 invoked from network); 18 Nov 2011 03:09:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 03:09:02 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAI38trQ029723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 03:08:56 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAI38re9012510
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 03:08:53 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAI38jj0015146; Thu, 17 Nov 2011 21:08:45 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 17 Nov 2011 19:08:45 -0800
Message-ID: <4EC5CC3B.4050808@oracle.com>
Date: Fri, 18 Nov 2011 11:08:43 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Re: [PATCH 1/3] xen/granttable: Introducing grant
	table V2 stucture
References: <4EC3B62F.6080702@oracle.com>	<1321451304-13559-1-git-send-email-annie.li@oracle.com>	<1321526148.3664.263.camel@zakaz.uk.xensource.com>	<4EC53119.7060307@oracle.com>
	<20111117162955.GA6758@phenom.dumpdata.com>
In-Reply-To: <20111117162955.GA6758@phenom.dumpdata.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4EC5CC4A.002B,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-11-18 0:29, Konrad Rzeszutek Wilk wrote:
>>> The more normal way to do this would be to make gnttab_interface a
>>> pointer, define gnttab_v1_ops and do:
>>> 	gnttab_interface =&gnttab_v1_ops;
>>> or if the pointer overhead is significant remove that and just do a
>>> struct assignment:
>>> 	gnttab_interface = gnttab_v1_ops;
>>>
>> If using this way, we need two more public structures(gnttab_v1_ops
>> and gnttab_v2_ops), and two more functions to initialize those two
>> structures and then initialize the pointer gnttab_interface. It is
>> more complicated, am i missing something?
> Why two functions? I agree on the structures - but they need not to be
> public (they can be static).
>
> For a good example look at how apic_physflat is done.
Thanks, static structure is simpler and clean. I am very glad to change 
that.:-)

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

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 04:57:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 04:57:21 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRGVs-00035l-Vv
	for archives@lists.xen.org; Fri, 18 Nov 2011 04:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRGVW-0005Yv-IF; Thu, 17 Nov 2011 20:56:58 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRGVS-0005YD-Al
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 20:56:54 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321592210!3623408!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17286 invoked from network); 18 Nov 2011 04:56:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 04:56:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,531,1315180800"; 
   d="scan'208";a="9000655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 04:56:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 04:56:50 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRGVN-0002UU-FE;
	Fri, 18 Nov 2011 04:56:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRGVN-0001QY-7T;
	Fri, 18 Nov 2011 04:56:49 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9855-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 18 Nov 2011 04:56:49 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9855: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail pass in 9832

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

version targeted for testing:
 xen                  dbdc840f8f62
baseline version:
 xen                  dbdc840f8f62

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 04:57:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 04:57:21 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRGVs-00035l-Vv
	for archives@lists.xen.org; Fri, 18 Nov 2011 04:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRGVW-0005Yv-IF; Thu, 17 Nov 2011 20:56:58 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRGVS-0005YD-Al
	for xen-devel@lists.xensource.com; Thu, 17 Nov 2011 20:56:54 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321592210!3623408!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17286 invoked from network); 18 Nov 2011 04:56:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 04:56:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,531,1315180800"; 
   d="scan'208";a="9000655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 04:56:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 04:56:50 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRGVN-0002UU-FE;
	Fri, 18 Nov 2011 04:56:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRGVN-0001QY-7T;
	Fri, 18 Nov 2011 04:56:49 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9855-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 18 Nov 2011 04:56:49 +0000
MIME-Version: 1.0
Content-Type: text/plain
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9855: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail pass in 9832

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

version targeted for testing:
 xen                  dbdc840f8f62
baseline version:
 xen                  dbdc840f8f62

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


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

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

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


Published tested tree is already up to date.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 08:14:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 08:14:47 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRJax-0003Dk-AI
	for archives@lists.xen.org; Fri, 18 Nov 2011 08:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRJab-0001Id-83; Fri, 18 Nov 2011 00:14:25 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with smtp (Exim 4.43) id 1RRJaJ-0001HN-8A
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 00:14:07 -0800
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321604043!2055641!1
X-Originating-IP: [83.223.49.132]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27417 invoked from network); 18 Nov 2011 08:14:03 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-12.tower-174.messagelabs.com with SMTP;
	18 Nov 2011 08:14:03 -0000
Received: (qmail 17814 invoked from network); 18 Nov 2011 09:14:01 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	18 Nov 2011 09:14:01 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] ioperm problem
Date: Fri, 18 Nov 2011 09:13:59 +0100
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201111132219.07211.pavel@netsafe.cz>
	<4EC51292.7000302@virtualcomputer.com>
	<20111117173010.GA3623@phenom.dumpdata.com>
In-Reply-To: <20111117173010.GA3623@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201111180914.00111.pavel@netsafe.cz>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu 17. of November 2011 18:30:10 Konrad Rzeszutek Wilk wrote:
> Pavel,
> 
> Can you try to merge the #devel/ioperm patches in your tree and see
> if they fix your problem?
> 
> The git tree is at
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

Hi Konrad,
yes, it fixed the problem. I can see BSOD during Windows boot now.
Thanks a lot
-- 
Pavel Mateja

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 08:14:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 08:14:47 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRJax-0003Dk-AI
	for archives@lists.xen.org; Fri, 18 Nov 2011 08:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRJab-0001Id-83; Fri, 18 Nov 2011 00:14:25 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with smtp (Exim 4.43) id 1RRJaJ-0001HN-8A
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 00:14:07 -0800
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321604043!2055641!1
X-Originating-IP: [83.223.49.132]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27417 invoked from network); 18 Nov 2011 08:14:03 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-12.tower-174.messagelabs.com with SMTP;
	18 Nov 2011 08:14:03 -0000
Received: (qmail 17814 invoked from network); 18 Nov 2011 09:14:01 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	18 Nov 2011 09:14:01 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] ioperm problem
Date: Fri, 18 Nov 2011 09:13:59 +0100
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201111132219.07211.pavel@netsafe.cz>
	<4EC51292.7000302@virtualcomputer.com>
	<20111117173010.GA3623@phenom.dumpdata.com>
In-Reply-To: <20111117173010.GA3623@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201111180914.00111.pavel@netsafe.cz>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu 17. of November 2011 18:30:10 Konrad Rzeszutek Wilk wrote:
> Pavel,
> 
> Can you try to merge the #devel/ioperm patches in your tree and see
> if they fix your problem?
> 
> The git tree is at
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

Hi Konrad,
yes, it fixed the problem. I can see BSOD during Windows boot now.
Thanks a lot
-- 
Pavel Mateja

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 08:32:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 08:32:13 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRJrp-0003Dx-4R
	for archives@lists.xen.org; Fri, 18 Nov 2011 08:32:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRJrS-0001vg-Hs; Fri, 18 Nov 2011 00:31:50 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRJrJ-0001ub-AM
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 00:31:43 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321605073!45097115!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26924 invoked from network); 18 Nov 2011 08:31:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 08:31:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 18 Nov 2011 08:31:37 +0000
Message-Id: <4EC625F90200007800061BFE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 18 Nov 2011 08:31:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: refine EOI-ing of
	migrating level interrupts
References: <4EC273B40200007800061145@nat28.tlf.novell.com>
	<4EC53288.5010400@citrix.com>
In-Reply-To: <4EC53288.5010400@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.11.11 at 17:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 15/11/11 13:14, Jan Beulich wrote:
>> Rather than going through all IO-APICs and calling io_apic_eoi_vector()
>> for the vector in question, just use eoi_IO_APIC_irq().
>>
>> This in turn allows to eliminate quite a bit of other code.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>=20
> Tested-and-acked-by: Andrew Cooper <andrew.cooper3@citrix.com> (tested
> via backport to xen-4.1.x)

Now that this is in, could you try (again on the offending system)
whether adding e.g. a WARN_ON(vector !=3D desc->arch.old_vector)
prior to the just added call to eoi_IO_APIC_irq() (but inside the
surrounding if()) would ever trigger (obviously you'd want to make
sure that the code path actually gets executed at all - perhaps
counting and printing the count once in a while would be the easiest
thing to do)?

If it does, we obviously need to stay with passing in vector. If not,
we'd need to do another round of code inspection to determine
whether indeed there's no race when relying on just the stored
data.

Thanks, Jan


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 08:32:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 08:32:13 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRJrp-0003Dx-4R
	for archives@lists.xen.org; Fri, 18 Nov 2011 08:32:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRJrS-0001vg-Hs; Fri, 18 Nov 2011 00:31:50 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRJrJ-0001ub-AM
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 00:31:43 -0800
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321605073!45097115!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26924 invoked from network); 18 Nov 2011 08:31:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 08:31:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 18 Nov 2011 08:31:37 +0000
Message-Id: <4EC625F90200007800061BFE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 18 Nov 2011 08:31:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: refine EOI-ing of
	migrating level interrupts
References: <4EC273B40200007800061145@nat28.tlf.novell.com>
	<4EC53288.5010400@citrix.com>
In-Reply-To: <4EC53288.5010400@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.11.11 at 17:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 15/11/11 13:14, Jan Beulich wrote:
>> Rather than going through all IO-APICs and calling io_apic_eoi_vector()
>> for the vector in question, just use eoi_IO_APIC_irq().
>>
>> This in turn allows to eliminate quite a bit of other code.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>=20
> Tested-and-acked-by: Andrew Cooper <andrew.cooper3@citrix.com> (tested
> via backport to xen-4.1.x)

Now that this is in, could you try (again on the offending system)
whether adding e.g. a WARN_ON(vector !=3D desc->arch.old_vector)
prior to the just added call to eoi_IO_APIC_irq() (but inside the
surrounding if()) would ever trigger (obviously you'd want to make
sure that the code path actually gets executed at all - perhaps
counting and printing the count once in a while would be the easiest
thing to do)?

If it does, we obviously need to stay with passing in vector. If not,
we'd need to do another round of code inspection to determine
whether indeed there's no race when relying on just the stored
data.

Thanks, Jan


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 09:01:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 09:01:45 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRKKO-0003Es-PE
	for archives@lists.xen.org; Fri, 18 Nov 2011 09:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRKK4-0002ma-FN; Fri, 18 Nov 2011 01:01:24 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRKHd-0002jH-H8
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 00:59:03 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1321606712!48782568!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14458 invoked from network); 18 Nov 2011 08:58:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 08:58:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9003159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 08:58:50 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 18 Nov 2011
	08:58:50 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Keir (Xen.org)" <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 18 Nov 2011 08:56:38 +0000
Subject: RE: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Topic: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Index: AcylTUvRZV7WF7N3u0mmSwGUSns+jwAgo7/g
Message-ID: <291EDFCB1E9E224A99088639C4762022B4543AB71D@LONPMAILBOX01.citrite.net>
References: <c25af1f86de1699ee366.1321548236@cosworth.uk.xensource.com>
	<CAEAF305.344BF%keir@xen.org>
In-Reply-To: <CAEAF305.344BF%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Not sure whether that will work, but I can give it a try. Windows quite oft=
en has very particular ideas about where things should be.

  Paul

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir
> Fraser
> Sent: 17 November 2011 17:21
> To: Paul Durrant; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
> selectively disable S3 and S4 ACPI power states
>=20
> On 17/11/2011 16:43, "Paul Durrant" <paul.durrant@citrix.com> wrote:
>=20
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1321548043 0
> #
> > Node ID c25af1f86de1699ee36684e740a323adbcffdfb5
> > # Parent  447738ef67ea2690c8ea6684f2e0e0b3528ad446
> > Add configuration options to selectively disable S3 and S4 ACPI
> power states.
> >
> > Introduce acpi_s3 and acpi_s4 configuration options (default=3D1).
> When
> > one of these parameters is 0 it causes removal of the respective
> > package (_S3 or _S4) from the DSDT thereby disabling that power
> state
> > in the guest.
>=20
> Yeeees. Brave as binary patching the DSDT is, how about sticking _S3
> and _S4 in optional SSDTs?
>=20
>  -- Keir
>=20
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >
> > diff -r 447738ef67ea -r c25af1f86de1
> > tools/firmware/hvmloader/acpi/acpi2_0.h
> > --- a/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:21:21
> 2011
> > +0000
> > +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:40:43
> 2011
> > +++ +0000
> > @@ -396,6 +396,8 @@ struct acpi_config {
> >      int dsdt_anycpu_len;
> >      unsigned char *dsdt_15cpu;
> >      int dsdt_15cpu_len;
> > +    int dsdt_s3_enabled;
> > +    int dsdt_s4_enabled;
> >  };
> >
> >  void acpi_build_tables(struct acpi_config *config, unsigned int
> > physical); diff -r 447738ef67ea -r c25af1f86de1
> > tools/firmware/hvmloader/acpi/build.c
> > --- a/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:21:21
> 2011
> > +0000
> > +++ b/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:40:43
> 2011
> > +++ +0000
> > @@ -274,6 +274,54 @@ static int construct_secondary_tables(un
> >      return nr_tables;
> >  }
> >
> > +static uint8_t *find_name(uint8_t *dsdt, const char *prefix) {
> > +    int len =3D strlen(prefix);
> > +    int i;
> > +
> > +    for ( i =3D 0; i < ((struct acpi_header *)dsdt)->length - len;
> i++,
> > + dsdt++
> > )
> > +    {
> > +        if ( memcmp(dsdt, prefix, len) =3D=3D 0 && *(dsdt - 1) =3D=3D
> 0x08 )
> > +            return dsdt - 1;
> > +    }
> > +
> > +    return NULL;
> > +}
> > +
> > +static void remove_package(uint8_t *dsdt, const char *prefix) {
> > +    struct acpi_header *header =3D (struct acpi_header *)dsdt;
> > +    uint8_t *start =3D find_name(dsdt, prefix);
> > +    uint8_t *end =3D dsdt + header->length - 1;
> > +    uint8_t *package;
> > +    uint8_t *len;
> > +    uint8_t *next;
> > +
> > +    if ( start =3D=3D NULL )
> > +        return;
> > +
> > +    package =3D start + 5; /* 1 byte op, 4 bytes payload */
> > +    if ( package > end )
> > +        return;
> > +    if ( *package !=3D 0x12 )
> > +        return;
> > +
> > +    len =3D package + 1;
> > +    if ( package > end )
> > +        return;
> > +
> > +    next =3D package + 1 + *len; /* 1 byte op, len bytes payload */
> > +    if ( next > end + 1 )
> > +        return;
> > +
> > +    printf("DSDT: removing '%c%c%c%c' (%d bytes)\n",
> > +           *(start + 1), *(start + 2), *(start + 3), *(start +
> 4),
> > +           next - start);
> > +
> > +    memcpy(start, next, header->length - (next - dsdt));
> > +    header->length -=3D next - start;
> > +}
> > +
> >  void acpi_build_tables(struct acpi_config *config, unsigned int
> > physical)  {
> >      struct acpi_info *acpi_info;
> > @@ -310,19 +358,29 @@ void acpi_build_tables(struct acpi_confi
> >       */
> >      if ( hvm_info->nr_vcpus <=3D 15 && config->dsdt_15cpu)
> >      {
> > -        dsdt =3D mem_alloc(config->dsdt_15cpu_len, 16);
> > +        dsdt =3D mem_probe(config->dsdt_15cpu_len, 16);
> >          if (!dsdt) goto oom;
> >          memcpy(dsdt, config->dsdt_15cpu, config->dsdt_15cpu_len);
> >          nr_processor_objects =3D 15;
> >      }
> >      else
> >      {
> > -        dsdt =3D mem_alloc(config->dsdt_anycpu_len, 16);
> > +        dsdt =3D mem_probe(config->dsdt_anycpu_len, 16);
> >          if (!dsdt) goto oom;
> >          memcpy(dsdt, config->dsdt_anycpu, config-
> >dsdt_anycpu_len);
> >          nr_processor_objects =3D HVM_MAX_VCPUS;
> >      }
> >
> > +    if ( !config->dsdt_s3_enabled)
> > +        remove_package(dsdt, "_S3");
> > +    if ( !config->dsdt_s4_enabled)
> > +        remove_package(dsdt, "_S4");
> > +
> > +    set_checksum(dsdt,
> > +                 offsetof(struct acpi_header, checksum),
> > +                 ((struct acpi_header*)dsdt)->length);
> > +    mem_commit(dsdt, ((struct acpi_header*)dsdt)->length);
> > +
> >      /*
> >       * N.B. ACPI 1.0 operating systems may not handle FADT with
> revision 2
> >       * or above properly, notably Windows 2000, which tries to
> copy
> > FADT diff -r 447738ef67ea -r c25af1f86de1
> > tools/firmware/hvmloader/config.h
> > --- a/tools/firmware/hvmloader/config.h Thu Nov 17 16:21:21 2011
> +0000
> > +++ b/tools/firmware/hvmloader/config.h Thu Nov 17 16:40:43 2011
> +0000
> > @@ -27,7 +27,7 @@ struct bios_config {
> >
> >      void (*e820_setup)(void);
> >
> > -    void (*acpi_build_tables)(void);
> > +    void (*acpi_build_tables)(int, int);
> >      void (*create_mp_tables)(void);
> >      void (*create_smbios_tables)(void);
> >      void (*create_pir_tables)(void);
> > diff -r 447738ef67ea -r c25af1f86de1
> > tools/firmware/hvmloader/hvmloader.c
> > --- a/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:21:21
> 2011
> > +0000
> > +++ b/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:40:43
> 2011
> > +++ +0000
> > @@ -516,11 +516,17 @@ int main(void)
> >              .index =3D HVM_PARAM_ACPI_IOPORTS_LOCATION,
> >              .value =3D 1,
> >          };
> > +        int s3_enabled, s4_enabled;
> > +
> > +        s3_enabled =3D !strncmp(xenstore_read("platform/acpi_s3",
> "1"),
> > + "1",
> > 1);
> > +        s4_enabled =3D !strncmp(xenstore_read("platform/acpi_s4",
> "1"),
> > + "1",
> > 1);
> >
> >          if ( bios->acpi_build_tables )
> >          {
> > -            printf("Loading ACPI ...\n");
> > -            bios->acpi_build_tables();
> > +            printf("Loading ACPI (S3=3D%s S4=3D%s) ...\n",
> > +                   (s3_enabled) ? "ON" : "OFF",
> > +                   (s4_enabled) ? "ON" : "OFF");
> > +            bios->acpi_build_tables(s3_enabled, s4_enabled);
> >          }
> >
> >          acpi_enable_sci();
> > diff -r 447738ef67ea -r c25af1f86de1
> > tools/firmware/hvmloader/rombios.c
> > --- a/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:21:21 2011
> > +0000
> > +++ b/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:40:43 2011
> > +++ +0000
> > @@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
> >      *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) =3D -
> checksum;  }
> >
> > -static void rombios_acpi_build_tables(void)
> > +static void rombios_acpi_build_tables(int s3_enabled, int
> s4_enabled)
> >  {
> >      struct acpi_config config =3D {
> >          .dsdt_anycpu =3D dsdt_anycpu,
> >          .dsdt_anycpu_len =3D dsdt_anycpu_len,
> >          .dsdt_15cpu =3D dsdt_15cpu,
> >          .dsdt_15cpu_len =3D dsdt_15cpu_len,
> > +        .dsdt_s3_enabled =3D s3_enabled,
> > +        .dsdt_s4_enabled =3D s4_enabled,
> >      };
> >
> >      acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS); diff -r
> > 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/seabios.c
> > --- a/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:21:21 2011
> > +0000
> > +++ b/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:40:43 2011
> > +++ +0000
> > @@ -91,7 +91,7 @@ static void add_table(uint32_t t)
> >      info->tables_nr++;
> >  }
> >
> > -static void seabios_acpi_build_tables(void)
> > +static void seabios_acpi_build_tables(int s3_enabled, int
> s4_enabled)
> >  {
> >      uint32_t rsdp =3D (uint32_t)scratch_alloc(sizeof(struct
> acpi_20_rsdp), 0);
> >      struct acpi_config config =3D {
> > @@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
> >          .dsdt_anycpu_len =3D dsdt_anycpu_qemu_xen_len,
> >          .dsdt_15cpu =3D NULL,
> >          .dsdt_15cpu_len =3D 0,
> > +        .dsdt_s3_enabled =3D s3_enabled,
> > +        .dsdt_s4_enabled =3D s4_enabled,
> >      };
> >
> >      acpi_build_tables(&config, rsdp); diff -r 447738ef67ea -r
> > c25af1f86de1 tools/firmware/hvmloader/util.c
> > --- a/tools/firmware/hvmloader/util.c Thu Nov 17 16:21:21 2011
> +0000
> > +++ b/tools/firmware/hvmloader/util.c Thu Nov 17 16:40:43 2011
> +0000
> > @@ -352,28 +352,35 @@ xen_pfn_t mem_hole_alloc(uint32_t nr_mfn
> >      return hvm_info->reserved_mem_pgstart;  }
> >
> > -void *mem_alloc(uint32_t size, uint32_t align)
> > +void *mem_probe(uint32_t size, uint32_t align)
> >  {
> > -    uint32_t s, e;
> > +    uint32_t r, s, e;
> > +    void *base;
> >
> >      /* Align to at least 16 bytes. */
> >      if ( align < 16 )
> >          align =3D 16;
> >
> > -    s =3D (reserve + align) & ~(align - 1);
> > +    r =3D reserve;
> > +    s =3D (r + align) & ~(align - 1);
> >      e =3D s + size - 1;
> >
> > +    base =3D (void *)s;
> > +
> >      BUG_ON((e < s) || (e >> PAGE_SHIFT) >=3D
> > hvm_info->reserved_mem_pgstart);
> >
> > -    while ( (reserve >> PAGE_SHIFT) !=3D (e >> PAGE_SHIFT) )
> > +    while ( (r >> PAGE_SHIFT) !=3D (e >> PAGE_SHIFT) )
> >      {
> > -        reserve +=3D PAGE_SIZE;
> > -        mem_hole_populate_ram(reserve >> PAGE_SHIFT, 1);
> > +        r +=3D PAGE_SIZE;
> > +        mem_hole_populate_ram(r >> PAGE_SHIFT, 1);
> >      }
> >
> > -    reserve =3D e;
> > +    return (void *)(unsigned long)s;
> > +}
> >
> > -    return (void *)(unsigned long)s;
> > +void mem_commit(void *base, uint32_t size) {
> > +    reserve =3D (uint32_t)base + size;
> >  }
> >
> >  void *scratch_alloc(uint32_t size, uint32_t align) diff -r
> > 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.h
> > --- a/tools/firmware/hvmloader/util.h Thu Nov 17 16:21:21 2011
> +0000
> > +++ b/tools/firmware/hvmloader/util.h Thu Nov 17 16:40:43 2011
> +0000
> > @@ -172,7 +172,16 @@ void mem_hole_populate_ram(xen_pfn_t mfn
> > xen_pfn_t mem_hole_alloc(uint32_t nr_mfns);
> >
> >  /* Allocate memory in a reserved region below 4GB. */ -void
> > *mem_alloc(uint32_t size, uint32_t align);
> > +void *mem_probe(uint32_t size, uint32_t align); void
> mem_commit(void
> > +*base, uint32_t size);
> > +
> > +static inline void *mem_alloc(uint32_t size, uint32_t align) {
> > +    void *base =3D mem_probe(size, align);
> > +    mem_commit(base, size);
> > +    return base;
> > +}
> > +
> >  #define virt_to_phys(v) ((unsigned long)(v))
> >
> >  /* Allocate memory in a scratch region */ diff -r 447738ef67ea -r
> > c25af1f86de1 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c Thu Nov 17 16:21:21 2011 +0000
> > +++ b/tools/libxl/libxl_create.c Thu Nov 17 16:40:43 2011 +0000
> > @@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
> >          b_info->u.hvm.pae =3D 1;
> >          b_info->u.hvm.apic =3D 1;
> >          b_info->u.hvm.acpi =3D 1;
> > +        b_info->u.hvm.acpi_s3 =3D 1;
> > +        b_info->u.hvm.acpi_s4 =3D 1;
> >          b_info->u.hvm.nx =3D 1;
> >          b_info->u.hvm.viridian =3D 0;
> >          b_info->u.hvm.hpet =3D 1;
> > @@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
> >          vments[4] =3D "start_time";
> >          vments[5] =3D libxl__sprintf(gc, "%lu.%02d",
> > start_time.tv_sec,(int)start_time.tv_usec/10000);
> >
> > -        localents =3D libxl__calloc(gc, 3, sizeof(char *));
> > +        localents =3D libxl__calloc(gc, 7, sizeof(char *));
> >          localents[0] =3D "platform/acpi";
> >          localents[1] =3D (info->u.hvm.acpi) ? "1" : "0";
> > +        localents[2] =3D "platform/acpi_s3";
> > +        localents[3] =3D (info->u.hvm.acpi_s3) ? "1" : "0";
> > +        localents[4] =3D "platform/acpi_s4";
> > +        localents[5] =3D (info->u.hvm.acpi_s4) ? "1" : "0";
> >
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> > diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl Thu Nov 17 16:21:21 2011 +0000
> > +++ b/tools/libxl/libxl_types.idl Thu Nov 17 16:40:43 2011 +0000
> > @@ -167,6 +167,8 @@ libxl_domain_build_info =3D Struct("domain
> >                                         ("pae", bool),
> >                                         ("apic", bool),
> >                                         ("acpi", bool),
> > +                                       ("acpi_s3", bool),
> > +                                       ("acpi_s4", bool),
> >                                         ("nx", bool),
> >                                         ("viridian", bool),
> >                                         ("timeoffset", string),
> diff
> > -r 447738ef67ea -r c25af1f86de1 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:21:21 2011 +0000
> > +++ b/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:40:43 2011 +0000
> > @@ -683,6 +683,10 @@ static void parse_config_data(const char
> >              b_info->u.hvm.apic =3D l;
> >          if (!xlu_cfg_get_long (config, "acpi", &l))
> >              b_info->u.hvm.acpi =3D l;
> > +        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
> > +            b_info->u.hvm.acpi_s3 =3D l;
> > +        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
> > +            b_info->u.hvm.acpi_s4 =3D l;
> >          if (!xlu_cfg_get_long (config, "nx", &l))
> >              b_info->u.hvm.nx =3D l;
> >          if (!xlu_cfg_get_long (config, "viridian", &l))
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>=20


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 09:01:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 09:01:45 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRKKO-0003Es-PE
	for archives@lists.xen.org; Fri, 18 Nov 2011 09:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRKK4-0002ma-FN; Fri, 18 Nov 2011 01:01:24 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRKHd-0002jH-H8
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 00:59:03 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1321606712!48782568!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14458 invoked from network); 18 Nov 2011 08:58:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 08:58:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9003159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 08:58:50 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 18 Nov 2011
	08:58:50 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Keir (Xen.org)" <keir@xen.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 18 Nov 2011 08:56:38 +0000
Subject: RE: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Topic: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Index: AcylTUvRZV7WF7N3u0mmSwGUSns+jwAgo7/g
Message-ID: <291EDFCB1E9E224A99088639C4762022B4543AB71D@LONPMAILBOX01.citrite.net>
References: <c25af1f86de1699ee366.1321548236@cosworth.uk.xensource.com>
	<CAEAF305.344BF%keir@xen.org>
In-Reply-To: <CAEAF305.344BF%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Not sure whether that will work, but I can give it a try. Windows quite oft=
en has very particular ideas about where things should be.

  Paul

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir
> Fraser
> Sent: 17 November 2011 17:21
> To: Paul Durrant; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
> selectively disable S3 and S4 ACPI power states
>=20
> On 17/11/2011 16:43, "Paul Durrant" <paul.durrant@citrix.com> wrote:
>=20
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1321548043 0
> #
> > Node ID c25af1f86de1699ee36684e740a323adbcffdfb5
> > # Parent  447738ef67ea2690c8ea6684f2e0e0b3528ad446
> > Add configuration options to selectively disable S3 and S4 ACPI
> power states.
> >
> > Introduce acpi_s3 and acpi_s4 configuration options (default=3D1).
> When
> > one of these parameters is 0 it causes removal of the respective
> > package (_S3 or _S4) from the DSDT thereby disabling that power
> state
> > in the guest.
>=20
> Yeeees. Brave as binary patching the DSDT is, how about sticking _S3
> and _S4 in optional SSDTs?
>=20
>  -- Keir
>=20
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >
> > diff -r 447738ef67ea -r c25af1f86de1
> > tools/firmware/hvmloader/acpi/acpi2_0.h
> > --- a/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:21:21
> 2011
> > +0000
> > +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:40:43
> 2011
> > +++ +0000
> > @@ -396,6 +396,8 @@ struct acpi_config {
> >      int dsdt_anycpu_len;
> >      unsigned char *dsdt_15cpu;
> >      int dsdt_15cpu_len;
> > +    int dsdt_s3_enabled;
> > +    int dsdt_s4_enabled;
> >  };
> >
> >  void acpi_build_tables(struct acpi_config *config, unsigned int
> > physical); diff -r 447738ef67ea -r c25af1f86de1
> > tools/firmware/hvmloader/acpi/build.c
> > --- a/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:21:21
> 2011
> > +0000
> > +++ b/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:40:43
> 2011
> > +++ +0000
> > @@ -274,6 +274,54 @@ static int construct_secondary_tables(un
> >      return nr_tables;
> >  }
> >
> > +static uint8_t *find_name(uint8_t *dsdt, const char *prefix) {
> > +    int len =3D strlen(prefix);
> > +    int i;
> > +
> > +    for ( i =3D 0; i < ((struct acpi_header *)dsdt)->length - len;
> i++,
> > + dsdt++
> > )
> > +    {
> > +        if ( memcmp(dsdt, prefix, len) =3D=3D 0 && *(dsdt - 1) =3D=3D
> 0x08 )
> > +            return dsdt - 1;
> > +    }
> > +
> > +    return NULL;
> > +}
> > +
> > +static void remove_package(uint8_t *dsdt, const char *prefix) {
> > +    struct acpi_header *header =3D (struct acpi_header *)dsdt;
> > +    uint8_t *start =3D find_name(dsdt, prefix);
> > +    uint8_t *end =3D dsdt + header->length - 1;
> > +    uint8_t *package;
> > +    uint8_t *len;
> > +    uint8_t *next;
> > +
> > +    if ( start =3D=3D NULL )
> > +        return;
> > +
> > +    package =3D start + 5; /* 1 byte op, 4 bytes payload */
> > +    if ( package > end )
> > +        return;
> > +    if ( *package !=3D 0x12 )
> > +        return;
> > +
> > +    len =3D package + 1;
> > +    if ( package > end )
> > +        return;
> > +
> > +    next =3D package + 1 + *len; /* 1 byte op, len bytes payload */
> > +    if ( next > end + 1 )
> > +        return;
> > +
> > +    printf("DSDT: removing '%c%c%c%c' (%d bytes)\n",
> > +           *(start + 1), *(start + 2), *(start + 3), *(start +
> 4),
> > +           next - start);
> > +
> > +    memcpy(start, next, header->length - (next - dsdt));
> > +    header->length -=3D next - start;
> > +}
> > +
> >  void acpi_build_tables(struct acpi_config *config, unsigned int
> > physical)  {
> >      struct acpi_info *acpi_info;
> > @@ -310,19 +358,29 @@ void acpi_build_tables(struct acpi_confi
> >       */
> >      if ( hvm_info->nr_vcpus <=3D 15 && config->dsdt_15cpu)
> >      {
> > -        dsdt =3D mem_alloc(config->dsdt_15cpu_len, 16);
> > +        dsdt =3D mem_probe(config->dsdt_15cpu_len, 16);
> >          if (!dsdt) goto oom;
> >          memcpy(dsdt, config->dsdt_15cpu, config->dsdt_15cpu_len);
> >          nr_processor_objects =3D 15;
> >      }
> >      else
> >      {
> > -        dsdt =3D mem_alloc(config->dsdt_anycpu_len, 16);
> > +        dsdt =3D mem_probe(config->dsdt_anycpu_len, 16);
> >          if (!dsdt) goto oom;
> >          memcpy(dsdt, config->dsdt_anycpu, config-
> >dsdt_anycpu_len);
> >          nr_processor_objects =3D HVM_MAX_VCPUS;
> >      }
> >
> > +    if ( !config->dsdt_s3_enabled)
> > +        remove_package(dsdt, "_S3");
> > +    if ( !config->dsdt_s4_enabled)
> > +        remove_package(dsdt, "_S4");
> > +
> > +    set_checksum(dsdt,
> > +                 offsetof(struct acpi_header, checksum),
> > +                 ((struct acpi_header*)dsdt)->length);
> > +    mem_commit(dsdt, ((struct acpi_header*)dsdt)->length);
> > +
> >      /*
> >       * N.B. ACPI 1.0 operating systems may not handle FADT with
> revision 2
> >       * or above properly, notably Windows 2000, which tries to
> copy
> > FADT diff -r 447738ef67ea -r c25af1f86de1
> > tools/firmware/hvmloader/config.h
> > --- a/tools/firmware/hvmloader/config.h Thu Nov 17 16:21:21 2011
> +0000
> > +++ b/tools/firmware/hvmloader/config.h Thu Nov 17 16:40:43 2011
> +0000
> > @@ -27,7 +27,7 @@ struct bios_config {
> >
> >      void (*e820_setup)(void);
> >
> > -    void (*acpi_build_tables)(void);
> > +    void (*acpi_build_tables)(int, int);
> >      void (*create_mp_tables)(void);
> >      void (*create_smbios_tables)(void);
> >      void (*create_pir_tables)(void);
> > diff -r 447738ef67ea -r c25af1f86de1
> > tools/firmware/hvmloader/hvmloader.c
> > --- a/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:21:21
> 2011
> > +0000
> > +++ b/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:40:43
> 2011
> > +++ +0000
> > @@ -516,11 +516,17 @@ int main(void)
> >              .index =3D HVM_PARAM_ACPI_IOPORTS_LOCATION,
> >              .value =3D 1,
> >          };
> > +        int s3_enabled, s4_enabled;
> > +
> > +        s3_enabled =3D !strncmp(xenstore_read("platform/acpi_s3",
> "1"),
> > + "1",
> > 1);
> > +        s4_enabled =3D !strncmp(xenstore_read("platform/acpi_s4",
> "1"),
> > + "1",
> > 1);
> >
> >          if ( bios->acpi_build_tables )
> >          {
> > -            printf("Loading ACPI ...\n");
> > -            bios->acpi_build_tables();
> > +            printf("Loading ACPI (S3=3D%s S4=3D%s) ...\n",
> > +                   (s3_enabled) ? "ON" : "OFF",
> > +                   (s4_enabled) ? "ON" : "OFF");
> > +            bios->acpi_build_tables(s3_enabled, s4_enabled);
> >          }
> >
> >          acpi_enable_sci();
> > diff -r 447738ef67ea -r c25af1f86de1
> > tools/firmware/hvmloader/rombios.c
> > --- a/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:21:21 2011
> > +0000
> > +++ b/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:40:43 2011
> > +++ +0000
> > @@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
> >      *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) =3D -
> checksum;  }
> >
> > -static void rombios_acpi_build_tables(void)
> > +static void rombios_acpi_build_tables(int s3_enabled, int
> s4_enabled)
> >  {
> >      struct acpi_config config =3D {
> >          .dsdt_anycpu =3D dsdt_anycpu,
> >          .dsdt_anycpu_len =3D dsdt_anycpu_len,
> >          .dsdt_15cpu =3D dsdt_15cpu,
> >          .dsdt_15cpu_len =3D dsdt_15cpu_len,
> > +        .dsdt_s3_enabled =3D s3_enabled,
> > +        .dsdt_s4_enabled =3D s4_enabled,
> >      };
> >
> >      acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS); diff -r
> > 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/seabios.c
> > --- a/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:21:21 2011
> > +0000
> > +++ b/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:40:43 2011
> > +++ +0000
> > @@ -91,7 +91,7 @@ static void add_table(uint32_t t)
> >      info->tables_nr++;
> >  }
> >
> > -static void seabios_acpi_build_tables(void)
> > +static void seabios_acpi_build_tables(int s3_enabled, int
> s4_enabled)
> >  {
> >      uint32_t rsdp =3D (uint32_t)scratch_alloc(sizeof(struct
> acpi_20_rsdp), 0);
> >      struct acpi_config config =3D {
> > @@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
> >          .dsdt_anycpu_len =3D dsdt_anycpu_qemu_xen_len,
> >          .dsdt_15cpu =3D NULL,
> >          .dsdt_15cpu_len =3D 0,
> > +        .dsdt_s3_enabled =3D s3_enabled,
> > +        .dsdt_s4_enabled =3D s4_enabled,
> >      };
> >
> >      acpi_build_tables(&config, rsdp); diff -r 447738ef67ea -r
> > c25af1f86de1 tools/firmware/hvmloader/util.c
> > --- a/tools/firmware/hvmloader/util.c Thu Nov 17 16:21:21 2011
> +0000
> > +++ b/tools/firmware/hvmloader/util.c Thu Nov 17 16:40:43 2011
> +0000
> > @@ -352,28 +352,35 @@ xen_pfn_t mem_hole_alloc(uint32_t nr_mfn
> >      return hvm_info->reserved_mem_pgstart;  }
> >
> > -void *mem_alloc(uint32_t size, uint32_t align)
> > +void *mem_probe(uint32_t size, uint32_t align)
> >  {
> > -    uint32_t s, e;
> > +    uint32_t r, s, e;
> > +    void *base;
> >
> >      /* Align to at least 16 bytes. */
> >      if ( align < 16 )
> >          align =3D 16;
> >
> > -    s =3D (reserve + align) & ~(align - 1);
> > +    r =3D reserve;
> > +    s =3D (r + align) & ~(align - 1);
> >      e =3D s + size - 1;
> >
> > +    base =3D (void *)s;
> > +
> >      BUG_ON((e < s) || (e >> PAGE_SHIFT) >=3D
> > hvm_info->reserved_mem_pgstart);
> >
> > -    while ( (reserve >> PAGE_SHIFT) !=3D (e >> PAGE_SHIFT) )
> > +    while ( (r >> PAGE_SHIFT) !=3D (e >> PAGE_SHIFT) )
> >      {
> > -        reserve +=3D PAGE_SIZE;
> > -        mem_hole_populate_ram(reserve >> PAGE_SHIFT, 1);
> > +        r +=3D PAGE_SIZE;
> > +        mem_hole_populate_ram(r >> PAGE_SHIFT, 1);
> >      }
> >
> > -    reserve =3D e;
> > +    return (void *)(unsigned long)s;
> > +}
> >
> > -    return (void *)(unsigned long)s;
> > +void mem_commit(void *base, uint32_t size) {
> > +    reserve =3D (uint32_t)base + size;
> >  }
> >
> >  void *scratch_alloc(uint32_t size, uint32_t align) diff -r
> > 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.h
> > --- a/tools/firmware/hvmloader/util.h Thu Nov 17 16:21:21 2011
> +0000
> > +++ b/tools/firmware/hvmloader/util.h Thu Nov 17 16:40:43 2011
> +0000
> > @@ -172,7 +172,16 @@ void mem_hole_populate_ram(xen_pfn_t mfn
> > xen_pfn_t mem_hole_alloc(uint32_t nr_mfns);
> >
> >  /* Allocate memory in a reserved region below 4GB. */ -void
> > *mem_alloc(uint32_t size, uint32_t align);
> > +void *mem_probe(uint32_t size, uint32_t align); void
> mem_commit(void
> > +*base, uint32_t size);
> > +
> > +static inline void *mem_alloc(uint32_t size, uint32_t align) {
> > +    void *base =3D mem_probe(size, align);
> > +    mem_commit(base, size);
> > +    return base;
> > +}
> > +
> >  #define virt_to_phys(v) ((unsigned long)(v))
> >
> >  /* Allocate memory in a scratch region */ diff -r 447738ef67ea -r
> > c25af1f86de1 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c Thu Nov 17 16:21:21 2011 +0000
> > +++ b/tools/libxl/libxl_create.c Thu Nov 17 16:40:43 2011 +0000
> > @@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
> >          b_info->u.hvm.pae =3D 1;
> >          b_info->u.hvm.apic =3D 1;
> >          b_info->u.hvm.acpi =3D 1;
> > +        b_info->u.hvm.acpi_s3 =3D 1;
> > +        b_info->u.hvm.acpi_s4 =3D 1;
> >          b_info->u.hvm.nx =3D 1;
> >          b_info->u.hvm.viridian =3D 0;
> >          b_info->u.hvm.hpet =3D 1;
> > @@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
> >          vments[4] =3D "start_time";
> >          vments[5] =3D libxl__sprintf(gc, "%lu.%02d",
> > start_time.tv_sec,(int)start_time.tv_usec/10000);
> >
> > -        localents =3D libxl__calloc(gc, 3, sizeof(char *));
> > +        localents =3D libxl__calloc(gc, 7, sizeof(char *));
> >          localents[0] =3D "platform/acpi";
> >          localents[1] =3D (info->u.hvm.acpi) ? "1" : "0";
> > +        localents[2] =3D "platform/acpi_s3";
> > +        localents[3] =3D (info->u.hvm.acpi_s3) ? "1" : "0";
> > +        localents[4] =3D "platform/acpi_s4";
> > +        localents[5] =3D (info->u.hvm.acpi_s4) ? "1" : "0";
> >
> >          break;
> >      case LIBXL_DOMAIN_TYPE_PV:
> > diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_types.idl
> > --- a/tools/libxl/libxl_types.idl Thu Nov 17 16:21:21 2011 +0000
> > +++ b/tools/libxl/libxl_types.idl Thu Nov 17 16:40:43 2011 +0000
> > @@ -167,6 +167,8 @@ libxl_domain_build_info =3D Struct("domain
> >                                         ("pae", bool),
> >                                         ("apic", bool),
> >                                         ("acpi", bool),
> > +                                       ("acpi_s3", bool),
> > +                                       ("acpi_s4", bool),
> >                                         ("nx", bool),
> >                                         ("viridian", bool),
> >                                         ("timeoffset", string),
> diff
> > -r 447738ef67ea -r c25af1f86de1 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:21:21 2011 +0000
> > +++ b/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:40:43 2011 +0000
> > @@ -683,6 +683,10 @@ static void parse_config_data(const char
> >              b_info->u.hvm.apic =3D l;
> >          if (!xlu_cfg_get_long (config, "acpi", &l))
> >              b_info->u.hvm.acpi =3D l;
> > +        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
> > +            b_info->u.hvm.acpi_s3 =3D l;
> > +        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
> > +            b_info->u.hvm.acpi_s4 =3D l;
> >          if (!xlu_cfg_get_long (config, "nx", &l))
> >              b_info->u.hvm.nx =3D l;
> >          if (!xlu_cfg_get_long (config, "viridian", &l))
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>=20


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 09:36:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 09:36:32 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRKs3-0003FS-Ud
	for archives@lists.xen.org; Fri, 18 Nov 2011 09:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRKre-0003kq-Qv; Fri, 18 Nov 2011 01:36:06 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRKrV-0003jP-Sj
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 01:35:58 -0800
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321608954!2067736!1
X-Originating-IP: [74.125.82.41]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26863 invoked from network); 18 Nov 2011 09:35:54 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 09:35:54 -0000
Received: by wwf25 with SMTP id 25so688546wwf.0
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 01:35:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=miM9cwHY94/6rV2v+bqkR68hGTF2mrAJtW8u4d+3Gdc=;
	b=bC/szh+BfyxJlL0ua08Cmz2qJ6NoPgHizKlxUD6JnlC/4z6CfIH/I3UR7fzlza7nNy
	NATjeeqDz41oJizdD2wDc4Ule8dH4pUjCA8FpRFrEvdrJvltcIFvbWP8fDiqyirRzV0t
	JAhE3wtS0Ltn36AZbXX5VoqaCc2/HH+ctIRZE=
Received: by 10.227.197.148 with SMTP id ek20mr1488679wbb.7.1321608954267;
	Fri, 18 Nov 2011 01:35:54 -0800 (PST)
Received: from [192.168.1.3] (host86-129-245-239.range86-129.btcentralplus.com.
	[86.129.245.239])
	by mx.google.com with ESMTPS id dw6sm105399wib.12.2011.11.18.01.35.50
	(version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 01:35:52 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 18 Nov 2011 09:35:42 +0000
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
From: Keir Fraser <keir@xen.org>
To: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAEBD76E.34520%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Index: AcylTUvRZV7WF7N3u0mmSwGUSns+jwAgo7/gAAFlaUc=
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B4543AB71D@LONPMAILBOX01.citrite.net>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: 
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The OSPM shouldn't care. It parses all tables at start of day into one big
homogeneous namespace.

On 18/11/2011 08:56, "Paul Durrant" <Paul.Durrant@citrix.com> wrote:

> Not sure whether that will work, but I can give it a try. Windows quite often
> has very particular ideas about where things should be.
> 
>   Paul
> 
>> -----Original Message-----
>> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir
>> Fraser
>> Sent: 17 November 2011 17:21
>> To: Paul Durrant; xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
>> selectively disable S3 and S4 ACPI power states
>> 
>> On 17/11/2011 16:43, "Paul Durrant" <paul.durrant@citrix.com> wrote:
>> 
>>> # HG changeset patch
>>> # User Paul Durrant <paul.durrant@citrix.com> # Date 1321548043 0
>> #
>>> Node ID c25af1f86de1699ee36684e740a323adbcffdfb5
>>> # Parent  447738ef67ea2690c8ea6684f2e0e0b3528ad446
>>> Add configuration options to selectively disable S3 and S4 ACPI
>> power states.
>>> 
>>> Introduce acpi_s3 and acpi_s4 configuration options (default=1).
>> When
>>> one of these parameters is 0 it causes removal of the respective
>>> package (_S3 or _S4) from the DSDT thereby disabling that power
>> state
>>> in the guest.
>> 
>> Yeeees. Brave as binary patching the DSDT is, how about sticking _S3
>> and _S4 in optional SSDTs?
>> 
>>  -- Keir
>> 
>>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>> 
>>> diff -r 447738ef67ea -r c25af1f86de1
>>> tools/firmware/hvmloader/acpi/acpi2_0.h
>>> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:21:21
>> 2011
>>> +0000
>>> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:40:43
>> 2011
>>> +++ +0000
>>> @@ -396,6 +396,8 @@ struct acpi_config {
>>>      int dsdt_anycpu_len;
>>>      unsigned char *dsdt_15cpu;
>>>      int dsdt_15cpu_len;
>>> +    int dsdt_s3_enabled;
>>> +    int dsdt_s4_enabled;
>>>  };
>>> 
>>>  void acpi_build_tables(struct acpi_config *config, unsigned int
>>> physical); diff -r 447738ef67ea -r c25af1f86de1
>>> tools/firmware/hvmloader/acpi/build.c
>>> --- a/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:21:21
>> 2011
>>> +0000
>>> +++ b/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:40:43
>> 2011
>>> +++ +0000
>>> @@ -274,6 +274,54 @@ static int construct_secondary_tables(un
>>>      return nr_tables;
>>>  }
>>> 
>>> +static uint8_t *find_name(uint8_t *dsdt, const char *prefix) {
>>> +    int len = strlen(prefix);
>>> +    int i;
>>> +
>>> +    for ( i = 0; i < ((struct acpi_header *)dsdt)->length - len;
>> i++,
>>> + dsdt++
>>> )
>>> +    {
>>> +        if ( memcmp(dsdt, prefix, len) == 0 && *(dsdt - 1) ==
>> 0x08 )
>>> +            return dsdt - 1;
>>> +    }
>>> +
>>> +    return NULL;
>>> +}
>>> +
>>> +static void remove_package(uint8_t *dsdt, const char *prefix) {
>>> +    struct acpi_header *header = (struct acpi_header *)dsdt;
>>> +    uint8_t *start = find_name(dsdt, prefix);
>>> +    uint8_t *end = dsdt + header->length - 1;
>>> +    uint8_t *package;
>>> +    uint8_t *len;
>>> +    uint8_t *next;
>>> +
>>> +    if ( start == NULL )
>>> +        return;
>>> +
>>> +    package = start + 5; /* 1 byte op, 4 bytes payload */
>>> +    if ( package > end )
>>> +        return;
>>> +    if ( *package != 0x12 )
>>> +        return;
>>> +
>>> +    len = package + 1;
>>> +    if ( package > end )
>>> +        return;
>>> +
>>> +    next = package + 1 + *len; /* 1 byte op, len bytes payload */
>>> +    if ( next > end + 1 )
>>> +        return;
>>> +
>>> +    printf("DSDT: removing '%c%c%c%c' (%d bytes)\n",
>>> +           *(start + 1), *(start + 2), *(start + 3), *(start +
>> 4),
>>> +           next - start);
>>> +
>>> +    memcpy(start, next, header->length - (next - dsdt));
>>> +    header->length -= next - start;
>>> +}
>>> +
>>>  void acpi_build_tables(struct acpi_config *config, unsigned int
>>> physical)  {
>>>      struct acpi_info *acpi_info;
>>> @@ -310,19 +358,29 @@ void acpi_build_tables(struct acpi_confi
>>>       */
>>>      if ( hvm_info->nr_vcpus <= 15 && config->dsdt_15cpu)
>>>      {
>>> -        dsdt = mem_alloc(config->dsdt_15cpu_len, 16);
>>> +        dsdt = mem_probe(config->dsdt_15cpu_len, 16);
>>>          if (!dsdt) goto oom;
>>>          memcpy(dsdt, config->dsdt_15cpu, config->dsdt_15cpu_len);
>>>          nr_processor_objects = 15;
>>>      }
>>>      else
>>>      {
>>> -        dsdt = mem_alloc(config->dsdt_anycpu_len, 16);
>>> +        dsdt = mem_probe(config->dsdt_anycpu_len, 16);
>>>          if (!dsdt) goto oom;
>>>          memcpy(dsdt, config->dsdt_anycpu, config-
>>> dsdt_anycpu_len);
>>>          nr_processor_objects = HVM_MAX_VCPUS;
>>>      }
>>> 
>>> +    if ( !config->dsdt_s3_enabled)
>>> +        remove_package(dsdt, "_S3");
>>> +    if ( !config->dsdt_s4_enabled)
>>> +        remove_package(dsdt, "_S4");
>>> +
>>> +    set_checksum(dsdt,
>>> +                 offsetof(struct acpi_header, checksum),
>>> +                 ((struct acpi_header*)dsdt)->length);
>>> +    mem_commit(dsdt, ((struct acpi_header*)dsdt)->length);
>>> +
>>>      /*
>>>       * N.B. ACPI 1.0 operating systems may not handle FADT with
>> revision 2
>>>       * or above properly, notably Windows 2000, which tries to
>> copy
>>> FADT diff -r 447738ef67ea -r c25af1f86de1
>>> tools/firmware/hvmloader/config.h
>>> --- a/tools/firmware/hvmloader/config.h Thu Nov 17 16:21:21 2011
>> +0000
>>> +++ b/tools/firmware/hvmloader/config.h Thu Nov 17 16:40:43 2011
>> +0000
>>> @@ -27,7 +27,7 @@ struct bios_config {
>>> 
>>>      void (*e820_setup)(void);
>>> 
>>> -    void (*acpi_build_tables)(void);
>>> +    void (*acpi_build_tables)(int, int);
>>>      void (*create_mp_tables)(void);
>>>      void (*create_smbios_tables)(void);
>>>      void (*create_pir_tables)(void);
>>> diff -r 447738ef67ea -r c25af1f86de1
>>> tools/firmware/hvmloader/hvmloader.c
>>> --- a/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:21:21
>> 2011
>>> +0000
>>> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:40:43
>> 2011
>>> +++ +0000
>>> @@ -516,11 +516,17 @@ int main(void)
>>>              .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
>>>              .value = 1,
>>>          };
>>> +        int s3_enabled, s4_enabled;
>>> +
>>> +        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3",
>> "1"),
>>> + "1",
>>> 1);
>>> +        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4",
>> "1"),
>>> + "1",
>>> 1);
>>> 
>>>          if ( bios->acpi_build_tables )
>>>          {
>>> -            printf("Loading ACPI ...\n");
>>> -            bios->acpi_build_tables();
>>> +            printf("Loading ACPI (S3=%s S4=%s) ...\n",
>>> +                   (s3_enabled) ? "ON" : "OFF",
>>> +                   (s4_enabled) ? "ON" : "OFF");
>>> +            bios->acpi_build_tables(s3_enabled, s4_enabled);
>>>          }
>>> 
>>>          acpi_enable_sci();
>>> diff -r 447738ef67ea -r c25af1f86de1
>>> tools/firmware/hvmloader/rombios.c
>>> --- a/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:21:21 2011
>>> +0000
>>> +++ b/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:40:43 2011
>>> +++ +0000
>>> @@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
>>>      *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) = -
>> checksum;  }
>>> 
>>> -static void rombios_acpi_build_tables(void)
>>> +static void rombios_acpi_build_tables(int s3_enabled, int
>> s4_enabled)
>>>  {
>>>      struct acpi_config config = {
>>>          .dsdt_anycpu = dsdt_anycpu,
>>>          .dsdt_anycpu_len = dsdt_anycpu_len,
>>>          .dsdt_15cpu = dsdt_15cpu,
>>>          .dsdt_15cpu_len = dsdt_15cpu_len,
>>> +        .dsdt_s3_enabled = s3_enabled,
>>> +        .dsdt_s4_enabled = s4_enabled,
>>>      };
>>> 
>>>      acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS); diff -r
>>> 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/seabios.c
>>> --- a/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:21:21 2011
>>> +0000
>>> +++ b/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:40:43 2011
>>> +++ +0000
>>> @@ -91,7 +91,7 @@ static void add_table(uint32_t t)
>>>      info->tables_nr++;
>>>  }
>>> 
>>> -static void seabios_acpi_build_tables(void)
>>> +static void seabios_acpi_build_tables(int s3_enabled, int
>> s4_enabled)
>>>  {
>>>      uint32_t rsdp = (uint32_t)scratch_alloc(sizeof(struct
>> acpi_20_rsdp), 0);
>>>      struct acpi_config config = {
>>> @@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
>>>          .dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
>>>          .dsdt_15cpu = NULL,
>>>          .dsdt_15cpu_len = 0,
>>> +        .dsdt_s3_enabled = s3_enabled,
>>> +        .dsdt_s4_enabled = s4_enabled,
>>>      };
>>> 
>>>      acpi_build_tables(&config, rsdp); diff -r 447738ef67ea -r
>>> c25af1f86de1 tools/firmware/hvmloader/util.c
>>> --- a/tools/firmware/hvmloader/util.c Thu Nov 17 16:21:21 2011
>> +0000
>>> +++ b/tools/firmware/hvmloader/util.c Thu Nov 17 16:40:43 2011
>> +0000
>>> @@ -352,28 +352,35 @@ xen_pfn_t mem_hole_alloc(uint32_t nr_mfn
>>>      return hvm_info->reserved_mem_pgstart;  }
>>> 
>>> -void *mem_alloc(uint32_t size, uint32_t align)
>>> +void *mem_probe(uint32_t size, uint32_t align)
>>>  {
>>> -    uint32_t s, e;
>>> +    uint32_t r, s, e;
>>> +    void *base;
>>> 
>>>      /* Align to at least 16 bytes. */
>>>      if ( align < 16 )
>>>          align = 16;
>>> 
>>> -    s = (reserve + align) & ~(align - 1);
>>> +    r = reserve;
>>> +    s = (r + align) & ~(align - 1);
>>>      e = s + size - 1;
>>> 
>>> +    base = (void *)s;
>>> +
>>>      BUG_ON((e < s) || (e >> PAGE_SHIFT) >=
>>> hvm_info->reserved_mem_pgstart);
>>> 
>>> -    while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
>>> +    while ( (r >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
>>>      {
>>> -        reserve += PAGE_SIZE;
>>> -        mem_hole_populate_ram(reserve >> PAGE_SHIFT, 1);
>>> +        r += PAGE_SIZE;
>>> +        mem_hole_populate_ram(r >> PAGE_SHIFT, 1);
>>>      }
>>> 
>>> -    reserve = e;
>>> +    return (void *)(unsigned long)s;
>>> +}
>>> 
>>> -    return (void *)(unsigned long)s;
>>> +void mem_commit(void *base, uint32_t size) {
>>> +    reserve = (uint32_t)base + size;
>>>  }
>>> 
>>>  void *scratch_alloc(uint32_t size, uint32_t align) diff -r
>>> 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.h
>>> --- a/tools/firmware/hvmloader/util.h Thu Nov 17 16:21:21 2011
>> +0000
>>> +++ b/tools/firmware/hvmloader/util.h Thu Nov 17 16:40:43 2011
>> +0000
>>> @@ -172,7 +172,16 @@ void mem_hole_populate_ram(xen_pfn_t mfn
>>> xen_pfn_t mem_hole_alloc(uint32_t nr_mfns);
>>> 
>>>  /* Allocate memory in a reserved region below 4GB. */ -void
>>> *mem_alloc(uint32_t size, uint32_t align);
>>> +void *mem_probe(uint32_t size, uint32_t align); void
>> mem_commit(void
>>> +*base, uint32_t size);
>>> +
>>> +static inline void *mem_alloc(uint32_t size, uint32_t align) {
>>> +    void *base = mem_probe(size, align);
>>> +    mem_commit(base, size);
>>> +    return base;
>>> +}
>>> +
>>>  #define virt_to_phys(v) ((unsigned long)(v))
>>> 
>>>  /* Allocate memory in a scratch region */ diff -r 447738ef67ea -r
>>> c25af1f86de1 tools/libxl/libxl_create.c
>>> --- a/tools/libxl/libxl_create.c Thu Nov 17 16:21:21 2011 +0000
>>> +++ b/tools/libxl/libxl_create.c Thu Nov 17 16:40:43 2011 +0000
>>> @@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
>>>          b_info->u.hvm.pae = 1;
>>>          b_info->u.hvm.apic = 1;
>>>          b_info->u.hvm.acpi = 1;
>>> +        b_info->u.hvm.acpi_s3 = 1;
>>> +        b_info->u.hvm.acpi_s4 = 1;
>>>          b_info->u.hvm.nx = 1;
>>>          b_info->u.hvm.viridian = 0;
>>>          b_info->u.hvm.hpet = 1;
>>> @@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
>>>          vments[4] = "start_time";
>>>          vments[5] = libxl__sprintf(gc, "%lu.%02d",
>>> start_time.tv_sec,(int)start_time.tv_usec/10000);
>>> 
>>> -        localents = libxl__calloc(gc, 3, sizeof(char *));
>>> +        localents = libxl__calloc(gc, 7, sizeof(char *));
>>>          localents[0] = "platform/acpi";
>>>          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
>>> +        localents[2] = "platform/acpi_s3";
>>> +        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
>>> +        localents[4] = "platform/acpi_s4";
>>> +        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
>>> 
>>>          break;
>>>      case LIBXL_DOMAIN_TYPE_PV:
>>> diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_types.idl
>>> --- a/tools/libxl/libxl_types.idl Thu Nov 17 16:21:21 2011 +0000
>>> +++ b/tools/libxl/libxl_types.idl Thu Nov 17 16:40:43 2011 +0000
>>> @@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
>>>                                         ("pae", bool),
>>>                                         ("apic", bool),
>>>                                         ("acpi", bool),
>>> +                                       ("acpi_s3", bool),
>>> +                                       ("acpi_s4", bool),
>>>                                         ("nx", bool),
>>>                                         ("viridian", bool),
>>>                                         ("timeoffset", string),
>> diff
>>> -r 447738ef67ea -r c25af1f86de1 tools/libxl/xl_cmdimpl.c
>>> --- a/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:21:21 2011 +0000
>>> +++ b/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:40:43 2011 +0000
>>> @@ -683,6 +683,10 @@ static void parse_config_data(const char
>>>              b_info->u.hvm.apic = l;
>>>          if (!xlu_cfg_get_long (config, "acpi", &l))
>>>              b_info->u.hvm.acpi = l;
>>> +        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
>>> +            b_info->u.hvm.acpi_s3 = l;
>>> +        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
>>> +            b_info->u.hvm.acpi_s4 = l;
>>>          if (!xlu_cfg_get_long (config, "nx", &l))
>>>              b_info->u.hvm.nx = l;
>>>          if (!xlu_cfg_get_long (config, "viridian", &l))
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>> 
> 



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 09:36:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 09:36:32 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRKs3-0003FS-Ud
	for archives@lists.xen.org; Fri, 18 Nov 2011 09:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRKre-0003kq-Qv; Fri, 18 Nov 2011 01:36:06 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRKrV-0003jP-Sj
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 01:35:58 -0800
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321608954!2067736!1
X-Originating-IP: [74.125.82.41]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26863 invoked from network); 18 Nov 2011 09:35:54 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 09:35:54 -0000
Received: by wwf25 with SMTP id 25so688546wwf.0
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 01:35:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=miM9cwHY94/6rV2v+bqkR68hGTF2mrAJtW8u4d+3Gdc=;
	b=bC/szh+BfyxJlL0ua08Cmz2qJ6NoPgHizKlxUD6JnlC/4z6CfIH/I3UR7fzlza7nNy
	NATjeeqDz41oJizdD2wDc4Ule8dH4pUjCA8FpRFrEvdrJvltcIFvbWP8fDiqyirRzV0t
	JAhE3wtS0Ltn36AZbXX5VoqaCc2/HH+ctIRZE=
Received: by 10.227.197.148 with SMTP id ek20mr1488679wbb.7.1321608954267;
	Fri, 18 Nov 2011 01:35:54 -0800 (PST)
Received: from [192.168.1.3] (host86-129-245-239.range86-129.btcentralplus.com.
	[86.129.245.239])
	by mx.google.com with ESMTPS id dw6sm105399wib.12.2011.11.18.01.35.50
	(version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 01:35:52 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 18 Nov 2011 09:35:42 +0000
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
From: Keir Fraser <keir@xen.org>
To: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAEBD76E.34520%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Index: AcylTUvRZV7WF7N3u0mmSwGUSns+jwAgo7/gAAFlaUc=
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B4543AB71D@LONPMAILBOX01.citrite.net>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: 
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The OSPM shouldn't care. It parses all tables at start of day into one big
homogeneous namespace.

On 18/11/2011 08:56, "Paul Durrant" <Paul.Durrant@citrix.com> wrote:

> Not sure whether that will work, but I can give it a try. Windows quite often
> has very particular ideas about where things should be.
> 
>   Paul
> 
>> -----Original Message-----
>> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir
>> Fraser
>> Sent: 17 November 2011 17:21
>> To: Paul Durrant; xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
>> selectively disable S3 and S4 ACPI power states
>> 
>> On 17/11/2011 16:43, "Paul Durrant" <paul.durrant@citrix.com> wrote:
>> 
>>> # HG changeset patch
>>> # User Paul Durrant <paul.durrant@citrix.com> # Date 1321548043 0
>> #
>>> Node ID c25af1f86de1699ee36684e740a323adbcffdfb5
>>> # Parent  447738ef67ea2690c8ea6684f2e0e0b3528ad446
>>> Add configuration options to selectively disable S3 and S4 ACPI
>> power states.
>>> 
>>> Introduce acpi_s3 and acpi_s4 configuration options (default=1).
>> When
>>> one of these parameters is 0 it causes removal of the respective
>>> package (_S3 or _S4) from the DSDT thereby disabling that power
>> state
>>> in the guest.
>> 
>> Yeeees. Brave as binary patching the DSDT is, how about sticking _S3
>> and _S4 in optional SSDTs?
>> 
>>  -- Keir
>> 
>>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>> 
>>> diff -r 447738ef67ea -r c25af1f86de1
>>> tools/firmware/hvmloader/acpi/acpi2_0.h
>>> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:21:21
>> 2011
>>> +0000
>>> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h Thu Nov 17 16:40:43
>> 2011
>>> +++ +0000
>>> @@ -396,6 +396,8 @@ struct acpi_config {
>>>      int dsdt_anycpu_len;
>>>      unsigned char *dsdt_15cpu;
>>>      int dsdt_15cpu_len;
>>> +    int dsdt_s3_enabled;
>>> +    int dsdt_s4_enabled;
>>>  };
>>> 
>>>  void acpi_build_tables(struct acpi_config *config, unsigned int
>>> physical); diff -r 447738ef67ea -r c25af1f86de1
>>> tools/firmware/hvmloader/acpi/build.c
>>> --- a/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:21:21
>> 2011
>>> +0000
>>> +++ b/tools/firmware/hvmloader/acpi/build.c Thu Nov 17 16:40:43
>> 2011
>>> +++ +0000
>>> @@ -274,6 +274,54 @@ static int construct_secondary_tables(un
>>>      return nr_tables;
>>>  }
>>> 
>>> +static uint8_t *find_name(uint8_t *dsdt, const char *prefix) {
>>> +    int len = strlen(prefix);
>>> +    int i;
>>> +
>>> +    for ( i = 0; i < ((struct acpi_header *)dsdt)->length - len;
>> i++,
>>> + dsdt++
>>> )
>>> +    {
>>> +        if ( memcmp(dsdt, prefix, len) == 0 && *(dsdt - 1) ==
>> 0x08 )
>>> +            return dsdt - 1;
>>> +    }
>>> +
>>> +    return NULL;
>>> +}
>>> +
>>> +static void remove_package(uint8_t *dsdt, const char *prefix) {
>>> +    struct acpi_header *header = (struct acpi_header *)dsdt;
>>> +    uint8_t *start = find_name(dsdt, prefix);
>>> +    uint8_t *end = dsdt + header->length - 1;
>>> +    uint8_t *package;
>>> +    uint8_t *len;
>>> +    uint8_t *next;
>>> +
>>> +    if ( start == NULL )
>>> +        return;
>>> +
>>> +    package = start + 5; /* 1 byte op, 4 bytes payload */
>>> +    if ( package > end )
>>> +        return;
>>> +    if ( *package != 0x12 )
>>> +        return;
>>> +
>>> +    len = package + 1;
>>> +    if ( package > end )
>>> +        return;
>>> +
>>> +    next = package + 1 + *len; /* 1 byte op, len bytes payload */
>>> +    if ( next > end + 1 )
>>> +        return;
>>> +
>>> +    printf("DSDT: removing '%c%c%c%c' (%d bytes)\n",
>>> +           *(start + 1), *(start + 2), *(start + 3), *(start +
>> 4),
>>> +           next - start);
>>> +
>>> +    memcpy(start, next, header->length - (next - dsdt));
>>> +    header->length -= next - start;
>>> +}
>>> +
>>>  void acpi_build_tables(struct acpi_config *config, unsigned int
>>> physical)  {
>>>      struct acpi_info *acpi_info;
>>> @@ -310,19 +358,29 @@ void acpi_build_tables(struct acpi_confi
>>>       */
>>>      if ( hvm_info->nr_vcpus <= 15 && config->dsdt_15cpu)
>>>      {
>>> -        dsdt = mem_alloc(config->dsdt_15cpu_len, 16);
>>> +        dsdt = mem_probe(config->dsdt_15cpu_len, 16);
>>>          if (!dsdt) goto oom;
>>>          memcpy(dsdt, config->dsdt_15cpu, config->dsdt_15cpu_len);
>>>          nr_processor_objects = 15;
>>>      }
>>>      else
>>>      {
>>> -        dsdt = mem_alloc(config->dsdt_anycpu_len, 16);
>>> +        dsdt = mem_probe(config->dsdt_anycpu_len, 16);
>>>          if (!dsdt) goto oom;
>>>          memcpy(dsdt, config->dsdt_anycpu, config-
>>> dsdt_anycpu_len);
>>>          nr_processor_objects = HVM_MAX_VCPUS;
>>>      }
>>> 
>>> +    if ( !config->dsdt_s3_enabled)
>>> +        remove_package(dsdt, "_S3");
>>> +    if ( !config->dsdt_s4_enabled)
>>> +        remove_package(dsdt, "_S4");
>>> +
>>> +    set_checksum(dsdt,
>>> +                 offsetof(struct acpi_header, checksum),
>>> +                 ((struct acpi_header*)dsdt)->length);
>>> +    mem_commit(dsdt, ((struct acpi_header*)dsdt)->length);
>>> +
>>>      /*
>>>       * N.B. ACPI 1.0 operating systems may not handle FADT with
>> revision 2
>>>       * or above properly, notably Windows 2000, which tries to
>> copy
>>> FADT diff -r 447738ef67ea -r c25af1f86de1
>>> tools/firmware/hvmloader/config.h
>>> --- a/tools/firmware/hvmloader/config.h Thu Nov 17 16:21:21 2011
>> +0000
>>> +++ b/tools/firmware/hvmloader/config.h Thu Nov 17 16:40:43 2011
>> +0000
>>> @@ -27,7 +27,7 @@ struct bios_config {
>>> 
>>>      void (*e820_setup)(void);
>>> 
>>> -    void (*acpi_build_tables)(void);
>>> +    void (*acpi_build_tables)(int, int);
>>>      void (*create_mp_tables)(void);
>>>      void (*create_smbios_tables)(void);
>>>      void (*create_pir_tables)(void);
>>> diff -r 447738ef67ea -r c25af1f86de1
>>> tools/firmware/hvmloader/hvmloader.c
>>> --- a/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:21:21
>> 2011
>>> +0000
>>> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Nov 17 16:40:43
>> 2011
>>> +++ +0000
>>> @@ -516,11 +516,17 @@ int main(void)
>>>              .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
>>>              .value = 1,
>>>          };
>>> +        int s3_enabled, s4_enabled;
>>> +
>>> +        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3",
>> "1"),
>>> + "1",
>>> 1);
>>> +        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4",
>> "1"),
>>> + "1",
>>> 1);
>>> 
>>>          if ( bios->acpi_build_tables )
>>>          {
>>> -            printf("Loading ACPI ...\n");
>>> -            bios->acpi_build_tables();
>>> +            printf("Loading ACPI (S3=%s S4=%s) ...\n",
>>> +                   (s3_enabled) ? "ON" : "OFF",
>>> +                   (s4_enabled) ? "ON" : "OFF");
>>> +            bios->acpi_build_tables(s3_enabled, s4_enabled);
>>>          }
>>> 
>>>          acpi_enable_sci();
>>> diff -r 447738ef67ea -r c25af1f86de1
>>> tools/firmware/hvmloader/rombios.c
>>> --- a/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:21:21 2011
>>> +0000
>>> +++ b/tools/firmware/hvmloader/rombios.c Thu Nov 17 16:40:43 2011
>>> +++ +0000
>>> @@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
>>>      *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) = -
>> checksum;  }
>>> 
>>> -static void rombios_acpi_build_tables(void)
>>> +static void rombios_acpi_build_tables(int s3_enabled, int
>> s4_enabled)
>>>  {
>>>      struct acpi_config config = {
>>>          .dsdt_anycpu = dsdt_anycpu,
>>>          .dsdt_anycpu_len = dsdt_anycpu_len,
>>>          .dsdt_15cpu = dsdt_15cpu,
>>>          .dsdt_15cpu_len = dsdt_15cpu_len,
>>> +        .dsdt_s3_enabled = s3_enabled,
>>> +        .dsdt_s4_enabled = s4_enabled,
>>>      };
>>> 
>>>      acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS); diff -r
>>> 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/seabios.c
>>> --- a/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:21:21 2011
>>> +0000
>>> +++ b/tools/firmware/hvmloader/seabios.c Thu Nov 17 16:40:43 2011
>>> +++ +0000
>>> @@ -91,7 +91,7 @@ static void add_table(uint32_t t)
>>>      info->tables_nr++;
>>>  }
>>> 
>>> -static void seabios_acpi_build_tables(void)
>>> +static void seabios_acpi_build_tables(int s3_enabled, int
>> s4_enabled)
>>>  {
>>>      uint32_t rsdp = (uint32_t)scratch_alloc(sizeof(struct
>> acpi_20_rsdp), 0);
>>>      struct acpi_config config = {
>>> @@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
>>>          .dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
>>>          .dsdt_15cpu = NULL,
>>>          .dsdt_15cpu_len = 0,
>>> +        .dsdt_s3_enabled = s3_enabled,
>>> +        .dsdt_s4_enabled = s4_enabled,
>>>      };
>>> 
>>>      acpi_build_tables(&config, rsdp); diff -r 447738ef67ea -r
>>> c25af1f86de1 tools/firmware/hvmloader/util.c
>>> --- a/tools/firmware/hvmloader/util.c Thu Nov 17 16:21:21 2011
>> +0000
>>> +++ b/tools/firmware/hvmloader/util.c Thu Nov 17 16:40:43 2011
>> +0000
>>> @@ -352,28 +352,35 @@ xen_pfn_t mem_hole_alloc(uint32_t nr_mfn
>>>      return hvm_info->reserved_mem_pgstart;  }
>>> 
>>> -void *mem_alloc(uint32_t size, uint32_t align)
>>> +void *mem_probe(uint32_t size, uint32_t align)
>>>  {
>>> -    uint32_t s, e;
>>> +    uint32_t r, s, e;
>>> +    void *base;
>>> 
>>>      /* Align to at least 16 bytes. */
>>>      if ( align < 16 )
>>>          align = 16;
>>> 
>>> -    s = (reserve + align) & ~(align - 1);
>>> +    r = reserve;
>>> +    s = (r + align) & ~(align - 1);
>>>      e = s + size - 1;
>>> 
>>> +    base = (void *)s;
>>> +
>>>      BUG_ON((e < s) || (e >> PAGE_SHIFT) >=
>>> hvm_info->reserved_mem_pgstart);
>>> 
>>> -    while ( (reserve >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
>>> +    while ( (r >> PAGE_SHIFT) != (e >> PAGE_SHIFT) )
>>>      {
>>> -        reserve += PAGE_SIZE;
>>> -        mem_hole_populate_ram(reserve >> PAGE_SHIFT, 1);
>>> +        r += PAGE_SIZE;
>>> +        mem_hole_populate_ram(r >> PAGE_SHIFT, 1);
>>>      }
>>> 
>>> -    reserve = e;
>>> +    return (void *)(unsigned long)s;
>>> +}
>>> 
>>> -    return (void *)(unsigned long)s;
>>> +void mem_commit(void *base, uint32_t size) {
>>> +    reserve = (uint32_t)base + size;
>>>  }
>>> 
>>>  void *scratch_alloc(uint32_t size, uint32_t align) diff -r
>>> 447738ef67ea -r c25af1f86de1 tools/firmware/hvmloader/util.h
>>> --- a/tools/firmware/hvmloader/util.h Thu Nov 17 16:21:21 2011
>> +0000
>>> +++ b/tools/firmware/hvmloader/util.h Thu Nov 17 16:40:43 2011
>> +0000
>>> @@ -172,7 +172,16 @@ void mem_hole_populate_ram(xen_pfn_t mfn
>>> xen_pfn_t mem_hole_alloc(uint32_t nr_mfns);
>>> 
>>>  /* Allocate memory in a reserved region below 4GB. */ -void
>>> *mem_alloc(uint32_t size, uint32_t align);
>>> +void *mem_probe(uint32_t size, uint32_t align); void
>> mem_commit(void
>>> +*base, uint32_t size);
>>> +
>>> +static inline void *mem_alloc(uint32_t size, uint32_t align) {
>>> +    void *base = mem_probe(size, align);
>>> +    mem_commit(base, size);
>>> +    return base;
>>> +}
>>> +
>>>  #define virt_to_phys(v) ((unsigned long)(v))
>>> 
>>>  /* Allocate memory in a scratch region */ diff -r 447738ef67ea -r
>>> c25af1f86de1 tools/libxl/libxl_create.c
>>> --- a/tools/libxl/libxl_create.c Thu Nov 17 16:21:21 2011 +0000
>>> +++ b/tools/libxl/libxl_create.c Thu Nov 17 16:40:43 2011 +0000
>>> @@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
>>>          b_info->u.hvm.pae = 1;
>>>          b_info->u.hvm.apic = 1;
>>>          b_info->u.hvm.acpi = 1;
>>> +        b_info->u.hvm.acpi_s3 = 1;
>>> +        b_info->u.hvm.acpi_s4 = 1;
>>>          b_info->u.hvm.nx = 1;
>>>          b_info->u.hvm.viridian = 0;
>>>          b_info->u.hvm.hpet = 1;
>>> @@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
>>>          vments[4] = "start_time";
>>>          vments[5] = libxl__sprintf(gc, "%lu.%02d",
>>> start_time.tv_sec,(int)start_time.tv_usec/10000);
>>> 
>>> -        localents = libxl__calloc(gc, 3, sizeof(char *));
>>> +        localents = libxl__calloc(gc, 7, sizeof(char *));
>>>          localents[0] = "platform/acpi";
>>>          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
>>> +        localents[2] = "platform/acpi_s3";
>>> +        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
>>> +        localents[4] = "platform/acpi_s4";
>>> +        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
>>> 
>>>          break;
>>>      case LIBXL_DOMAIN_TYPE_PV:
>>> diff -r 447738ef67ea -r c25af1f86de1 tools/libxl/libxl_types.idl
>>> --- a/tools/libxl/libxl_types.idl Thu Nov 17 16:21:21 2011 +0000
>>> +++ b/tools/libxl/libxl_types.idl Thu Nov 17 16:40:43 2011 +0000
>>> @@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
>>>                                         ("pae", bool),
>>>                                         ("apic", bool),
>>>                                         ("acpi", bool),
>>> +                                       ("acpi_s3", bool),
>>> +                                       ("acpi_s4", bool),
>>>                                         ("nx", bool),
>>>                                         ("viridian", bool),
>>>                                         ("timeoffset", string),
>> diff
>>> -r 447738ef67ea -r c25af1f86de1 tools/libxl/xl_cmdimpl.c
>>> --- a/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:21:21 2011 +0000
>>> +++ b/tools/libxl/xl_cmdimpl.c Thu Nov 17 16:40:43 2011 +0000
>>> @@ -683,6 +683,10 @@ static void parse_config_data(const char
>>>              b_info->u.hvm.apic = l;
>>>          if (!xlu_cfg_get_long (config, "acpi", &l))
>>>              b_info->u.hvm.acpi = l;
>>> +        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
>>> +            b_info->u.hvm.acpi_s3 = l;
>>> +        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
>>> +            b_info->u.hvm.acpi_s4 = l;
>>>          if (!xlu_cfg_get_long (config, "nx", &l))
>>>              b_info->u.hvm.nx = l;
>>>          if (!xlu_cfg_get_long (config, "viridian", &l))
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>> 
> 



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:09:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:09:59 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLOR-0003Fo-0j
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLO4-0004b5-Ci; Fri, 18 Nov 2011 02:09:36 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLMi-0004Z0-WB
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:08:18 -0800
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321610849!63710530!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5860 invoked from network); 18 Nov 2011 10:07:30 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 10:07:30 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIA84tk022626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 10:08:05 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIA7xto015346
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 10:08:00 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIA7pCH021032; Fri, 18 Nov 2011 04:07:52 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 02:07:50 -0800
Message-ID: <4EC62E77.7090007@oracle.com>
Date: Fri, 18 Nov 2011 18:07:51 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	paul.durrant@citrix.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
	V2 stucture
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1321451304-13559-1-git-send-email-annie.li@oracle.com>
Content-Type: multipart/mixed; boundary="------------060201000507000106030009"
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EC62E85.012E,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, jeremy@goop.org,
	konrad.wilk@oracle.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------060201000507000106030009
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi

I split this patch into two, 0001-** is about renaming and abstracting 
to function pointers, 0002-** is for refactoring code.

Thanks
Annie

--------------060201000507000106030009
Content-Type: text/plain;
	name="0001-xen-granttable-Introducing-grant-table-V2-stucture.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename*0="0001-xen-granttable-Introducing-grant-table-V2-stucture.patc";
	filename*1="h"

RnJvbSBjMTBlYjg5NWFiYjU3OWU1MDc1OWJhZmNiZmQ1NGFlODAyMDZiYWIwIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4K
RGF0ZTogRnJpLCAxOCBOb3YgMjAxMSAxNjowNzoxNiArMDgwMApTdWJqZWN0OiBbUEFUQ0gg
MS80XSB4ZW4vZ3JhbnR0YWJsZTogSW50cm9kdWNpbmcgZ3JhbnQgdGFibGUgVjIgc3R1Y3R1
cmUKClRoaXMgcGF0Y2ggaW50cm9kdWNlcyBuZXcgc3RydWN0dXJlcyBvZiBncmFudCB0YWJs
ZSBWMiwgZ3JhbnQgdGFibGUgVjIgaXMgYW4KZXh0ZW5zaW9uIGZyb20gVjEuIEdyYW50IHRh
YmxlIGlzIHNoYXJlZCBiZXR3ZWVuIGd1ZXN0IGFuZCBYZW4sIGFuZCBYZW4gaXMKcmVzcG9u
c2libGUgdG8gZG8gY29ycmVzcG9uZGluZyB3b3JrIGZvciBncmFudCBvcGVyYXRpb25zLCBz
dWNoIGFzOiBmaWd1cmUKb3V0IGd1ZXN0J3MgZ3JhbnQgdGFibGUgdmVyc2lvbiwgcGVyZm9y
bSBkaWZmZXJlbnQgYWN0aW9ucyBiYXNlZCBvbgpkaWZmZXJlbnQgZ3JhbnQgdGFibGUgdmVy
c2lvbiwgZXRjLiBBbHRob3VnaCBmdWxsLXBhZ2Ugc3RydWN0dXJlIG9mIFYyCmlzIGRpZmZl
cmVudCBmcm9tIFYxLCBpdCBwbGF5IHRoZSBzYW1lIHJvbGUgYXMgVjEuCgpTaWduZWQtb2Zm
LWJ5OiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4v
Z3JhbnQtdGFibGUuYyAgICAgICAgICB8ICAgIDcgKy0KIGRyaXZlcnMveGVuL2dyYW50LXRh
YmxlLmMgICAgICAgICAgIHwgIDE4MiArKysrKysrKysrKysrKysrKysrKysrKysrKystLS0t
LS0tLQogaW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUuaCAgICAgICAgICAgfCAgICA0ICstCiBp
bmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaCB8ICAxNjcgKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKy0KIGluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaCAgICAg
ICAgIHwgICAgMiArCiA1IGZpbGVzIGNoYW5nZWQsIDMxMSBpbnNlcnRpb25zKCspLCA1MSBk
ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYyBi
L2FyY2gveDg2L3hlbi9ncmFudC10YWJsZS5jCmluZGV4IDZiYmZkN2EuLmM2YWIyZTcgMTAw
NjQ0Ci0tLSBhL2FyY2gveDg2L3hlbi9ncmFudC10YWJsZS5jCisrKyBiL2FyY2gveDg2L3hl
bi9ncmFudC10YWJsZS5jCkBAIC02NCwxMCArNjQsMTAgQEAgc3RhdGljIGludCB1bm1hcF9w
dGVfZm4ocHRlX3QgKnB0ZSwgc3RydWN0IHBhZ2UgKnBtZF9wYWdlLAogCiBpbnQgYXJjaF9n
bnR0YWJfbWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGxvbmcg
bnJfZ2ZyYW1lcywKIAkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFtZXMsCi0JCQkg
ICBzdHJ1Y3QgZ3JhbnRfZW50cnkgKipfX3NoYXJlZCkKKwkJCSAgIHZvaWQgKipfX3NoYXJl
ZCkKIHsKIAlpbnQgcmM7Ci0Jc3RydWN0IGdyYW50X2VudHJ5ICpzaGFyZWQgPSAqX19zaGFy
ZWQ7CisJdm9pZCAqc2hhcmVkID0gKl9fc2hhcmVkOwogCiAJaWYgKHNoYXJlZCA9PSBOVUxM
KSB7CiAJCXN0cnVjdCB2bV9zdHJ1Y3QgKmFyZWEgPQpAQCAtODMsOCArODMsNyBAQCBpbnQg
YXJjaF9nbnR0YWJfbWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVk
IGxvbmcgbnJfZ2ZyYW1lcywKIAlyZXR1cm4gcmM7CiB9CiAKLXZvaWQgYXJjaF9nbnR0YWJf
dW5tYXBfc2hhcmVkKHN0cnVjdCBncmFudF9lbnRyeSAqc2hhcmVkLAotCQkJICAgICAgdW5z
aWduZWQgbG9uZyBucl9nZnJhbWVzKQordm9pZCBhcmNoX2dudHRhYl91bm1hcF9zaGFyZWQo
dm9pZCAqc2hhcmVkLCB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpCiB7CiAJYXBwbHlfdG9f
cGFnZV9yYW5nZSgmaW5pdF9tbSwgKHVuc2lnbmVkIGxvbmcpc2hhcmVkLAogCQkJICAgIFBB
R0VfU0laRSAqIG5yX2dmcmFtZXMsIHVubWFwX3B0ZV9mbiwgTlVMTCk7CmRpZmYgLS1naXQg
YS9kcml2ZXJzL3hlbi9ncmFudC10YWJsZS5jIGIvZHJpdmVycy94ZW4vZ3JhbnQtdGFibGUu
YwppbmRleCBiZjFjMDk0Li41ZDkzMWI4IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9ncmFu
dC10YWJsZS5jCisrKyBiL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMKQEAgLTUzLDcgKzUz
LDcgQEAKIC8qIEV4dGVybmFsIHRvb2xzIHJlc2VydmUgZmlyc3QgZmV3IGdyYW50IHRhYmxl
IGVudHJpZXMuICovCiAjZGVmaW5lIE5SX1JFU0VSVkVEX0VOVFJJRVMgOAogI2RlZmluZSBH
TlRUQUJfTElTVF9FTkQgMHhmZmZmZmZmZgotI2RlZmluZSBHUkVGU19QRVJfR1JBTlRfRlJB
TUUgKFBBR0VfU0laRSAvIHNpemVvZihzdHJ1Y3QgZ3JhbnRfZW50cnkpKQorI2RlZmluZSBH
UkVGU19QRVJfR1JBTlRfRlJBTUUgKFBBR0VfU0laRSAvIHNpemVvZihzdHJ1Y3QgZ3JhbnRf
ZW50cnlfdjEpKQogCiBzdGF0aWMgZ3JhbnRfcmVmX3QgKipnbnR0YWJfbGlzdDsKIHN0YXRp
YyB1bnNpZ25lZCBpbnQgbnJfZ3JhbnRfZnJhbWVzOwpAQCAtNjQsNyArNjQsNjQgQEAgc3Rh
dGljIERFRklORV9TUElOTE9DSyhnbnR0YWJfbGlzdF9sb2NrKTsKIHVuc2lnbmVkIGxvbmcg
eGVuX2h2bV9yZXN1bWVfZnJhbWVzOwogRVhQT1JUX1NZTUJPTF9HUEwoeGVuX2h2bV9yZXN1
bWVfZnJhbWVzKTsKIAotc3RhdGljIHN0cnVjdCBncmFudF9lbnRyeSAqc2hhcmVkOworc3Rh
dGljIHVuaW9uIHsKKwlzdHJ1Y3QgZ3JhbnRfZW50cnlfdjEgKnYxOworCXZvaWQgKmFkZHI7
Cit9IGdudHRhYl9zaGFyZWQ7CisKKy8qVGhpcyBpcyBhIHN0cnVjdHVyZSBvZiBmdW5jdGlv
biBwb2ludGVycyBmb3IgZ3JhbnQgdGFibGUqLworc3RydWN0IGdudHRhYl9vcHMgeworCS8q
CisJICogTWFwcGluZyBhIGxpc3Qgb2YgZnJhbWVzIGZvciBzdG9yaW5nIGdyYW50IGVudHJp
ZXMuIEZpcnN0IGlucHV0CisJICogcGFyYW1ldGVyIGlzIHVzZWQgdG8gc3RvcmluZyBncmFu
dCB0YWJsZSBhZGRyZXNzIHdoZW4gZ3JhbnQgdGFibGUKKwkgKiBiZWluZyBzZXR1cCwgc2Vj
b25kIHBhcmFtZXRlciBpcyB0aGUgbnVtYmVyIG9mIGZyYW1lcyB0byBtYXAgZ3JhbnQKKwkg
KiB0YWJsZS4gUmV0dXJuaW5nIEdOVFNUX29rYXkgbWVhbnMgc3VjY2VzcyBhbmQgbmVnYXRp
dmUgdmFsdWUgbWVhbnMKKwkgKiBmYWlsdXJlLgorCSAqLworCWludCAoKm1hcF9mcmFtZXMp
KHVuc2lnbmVkIGxvbmcgKiwgdW5zaWduZWQgaW50KTsKKwkvKgorCSAqIFJlbGVhc2UgYSBs
aXN0IG9mIGZyYW1lcyB3aGljaCBhcmUgbWFwcGVkIGluIG1hcF9mcmFtZXMgZm9yIGdyYW50
CisJICogZW50cnkgc3RhdHVzLgorCSAqLworCXZvaWQgKCp1bm1hcF9mcmFtZXMpKHZvaWQp
OworCS8qCisJICogSW50cm9kdWNpbmcgYSB2YWxpZCBlbnRyeSBpbnRvIHRoZSBncmFudCB0
YWJsZSwgZ3JhbnRpbmcgdGhlIGZyYW1lCisJICogb2YgdGhpcyBncmFudCBlbnRyeSB0byBk
b21haW4gZm9yIGFjY2Vzc2luZywgb3IgdHJhbnNmZXJpbmcsIG9yCisJICogdHJhbnNpdGl2
ZWx5IGFjY2Vzc2luZy4gRmlyc3QgaW5wdXQgcGFyYW1ldGVyIGlzIHJlZmVyZW5jZSBvZiB0
aGlzCisJICogaW50cm9kdWNlZCBncmFudCBlbnRyeSwgc2Vjb25kIG9uZSBpcyBkb21pZCBv
ZiBncmFudGVkIGRvbWFpbiwgdGhpcmQKKwkgKiBvbmUgaXMgdGhlIGZyYW1lIHRvIGJlIGdy
YW50ZWQsIGFuZCB0aGUgbGFzdCBvbmUgaXMgc3RhdHVzIG9mIHRoZQorCSAqIGdyYW50IGVu
dHJ5IHRvIGJlIHVwZGF0ZWQuCisJICovCisJdm9pZCAoKnVwZGF0ZV9lbnRyeSkoZ3JhbnRf
cmVmX3QsIGRvbWlkX3QsIHVuc2lnbmVkIGxvbmcsIHVuc2lnbmVkKTsKKwkvKgorCSAqIFN0
b3AgZ3JhbnRpbmcgYSBncmFudCBlbnRyeSB0byBkb21haW4gZm9yIGFjY2Vzc2luZy4gRmly
c3QgaW5wdXQKKwkgKiBwYXJhbWV0ZXIgaXMgcmVmZXJlbmNlIG9mIGEgZ3JhbnQgZW50cnkg
d2hvc2UgZ3JhbnQgYWNjZXNzIHdpbGwgYmUKKwkgKiBzdG9wcGVkLCBzZWNvbmQgb25lIGlz
IG5vdCBpbiB1c2Ugbm93LiBJZiB0aGUgZ3JhbnQgZW50cnkgaXMKKwkgKiBjdXJyZW50bHkg
bWFwcGVkIGZvciByZWFkaW5nIG9yIHdyaXRpbmcsIGp1c3QgcmV0dXJuIGZhaWx1cmUoPT0w
KQorCSAqIGRpcmVjdGx5IGFuZCBkb24ndCB0ZWFyIGRvd24gdGhlIGdyYW50IGFjY2Vzcy4g
T3RoZXJ3aXNlLCBzdG9wIGdyYW50CisJICogYWNjZXNzIGZvciB0aGlzIGVudHJ5IGFuZCBy
ZXR1cm4gc3VjY2Vzcyg9PTEpLgorCSAqLworCWludCAoKmVuZF9mb3JlaWduX2FjY2Vzc19y
ZWYpKGdyYW50X3JlZl90LCBpbnQpOworCS8qCisJICogU3RvcCBncmFudGluZyBhIGdyYW50
IGVudHJ5IHRvIGRvbWFpbiBmb3IgdHJhbnNmZXIuIElmIHRyYW5mZXIgaGFzCisJICogbm90
IHN0YXJ0ZWQsIGp1c3QgcmVjbGFpbSB0aGUgZ3JhbnQgZW50cnkgYW5kIHJldHVybiBmYWls
dXJlKD09MCkuCisJICogT3RoZXJ3aXNlLCB3YWl0IGZvciB0aGUgdHJhbnNmZXIgdG8gY29t
cGxldGUgYW5kIHRoZW4gcmV0dXJuIHRoZQorCSAqIGZyYW1lLgorCSAqLworCXVuc2lnbmVk
IGxvbmcgKCplbmRfZm9yZWlnbl90cmFuc2Zlcl9yZWYpKGdyYW50X3JlZl90KTsKKwkvKgor
CSAqIFF1ZXJ5IHRoZSBzdGF0dXMgb2YgYSBncmFudCBlbnRyeS4gSW5wdXQgcGFyYW1ldGVy
IGlzIHJlZmVyZW5jZSBvZgorCSAqIHF1ZXJpZWQgZ3JhbnQgZW50cnksIHJldHVybiB2YWx1
ZSBpcyB0aGUgc3RhdHVzIG9mIHF1ZXJpZWQgZW50cnkuCisJICogRGV0YWlsZWQgc3RhdHVz
KHdyaXRpbmcvcmVhZGluZykgY2FuIGJlIGdvdHRlbiBmcm9tIHRoZSByZXR1cm4gdmFsdWUK
KwkgKiBieSBiaXQgb3BlcmF0aW9ucy4KKwkgKi8KKwlpbnQgKCpxdWVyeV9mb3JlaWduX2Fj
Y2VzcykoZ3JhbnRfcmVmX3QpOworfTsKKworc3RhdGljIHN0cnVjdCBnbnR0YWJfb3BzIGdu
dHRhYl92MV9vcHM7CitzdGF0aWMgc3RydWN0IGdudHRhYl9vcHMgKmdudHRhYl9pbnRlcmZh
Y2U7CisKK3N0YXRpYyBpbnQgZ3JhbnRfdGFibGVfdmVyc2lvbjsKIAogc3RhdGljIHN0cnVj
dCBnbnR0YWJfZnJlZV9jYWxsYmFjayAqZ250dGFiX2ZyZWVfY2FsbGJhY2tfbGlzdDsKIApA
QCAtMTQyLDIzICsxOTksMjMgQEAgc3RhdGljIHZvaWQgcHV0X2ZyZWVfZW50cnkoZ3JhbnRf
cmVmX3QgcmVmKQogCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmdudHRhYl9saXN0X2xvY2ss
IGZsYWdzKTsKIH0KIAotc3RhdGljIHZvaWQgdXBkYXRlX2dyYW50X2VudHJ5KGdyYW50X3Jl
Zl90IHJlZiwgZG9taWRfdCBkb21pZCwKLQkJCSAgICAgICB1bnNpZ25lZCBsb25nIGZyYW1l
LCB1bnNpZ25lZCBmbGFncykKKy8qCisgKiBJbnRyb2R1Y2luZyBhIHZhbGlkIGVudHJ5IGlu
dG8gdGhlIGdyYW50IHRhYmxlOgorICogIDEuIFdyaXRlIGVudC0+ZG9taWQuCisgKiAgMi4g
V3JpdGUgZW50LT5mcmFtZToKKyAqICAgICAgR1RGX3Blcm1pdF9hY2Nlc3M6ICAgRnJhbWUg
dG8gd2hpY2ggYWNjZXNzIGlzIHBlcm1pdHRlZC4KKyAqICAgICAgR1RGX2FjY2VwdF90cmFu
c2ZlcjogUHNldWRvLXBoeXMgZnJhbWUgc2xvdCBiZWluZyBmaWxsZWQgYnkgbmV3CisgKiAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGZyYW1lLCBvciB6ZXJvIGlmIG5vbmUuCisgKiAg
My4gV3JpdGUgbWVtb3J5IGJhcnJpZXIgKFdNQikuCisgKiAgNC4gV3JpdGUgZW50LT5mbGFn
cywgaW5jLiB2YWxpZCB0eXBlLgorICovCitzdGF0aWMgdm9pZCB1cGRhdGVfZ3JhbnRfZW50
cnlfdjEoZ3JhbnRfcmVmX3QgcmVmLCBkb21pZF90IGRvbWlkLAorCQkJCSAgdW5zaWduZWQg
bG9uZyBmcmFtZSwgdW5zaWduZWQgZmxhZ3MpCiB7Ci0JLyoKLQkgKiBJbnRyb2R1Y2luZyBh
IHZhbGlkIGVudHJ5IGludG8gdGhlIGdyYW50IHRhYmxlOgotCSAqICAxLiBXcml0ZSBlbnQt
PmRvbWlkLgotCSAqICAyLiBXcml0ZSBlbnQtPmZyYW1lOgotCSAqICAgICAgR1RGX3Blcm1p
dF9hY2Nlc3M6ICAgRnJhbWUgdG8gd2hpY2ggYWNjZXNzIGlzIHBlcm1pdHRlZC4KLQkgKiAg
ICAgIEdURl9hY2NlcHRfdHJhbnNmZXI6IFBzZXVkby1waHlzIGZyYW1lIHNsb3QgYmVpbmcg
ZmlsbGVkIGJ5IG5ldwotCSAqICAgICAgICAgICAgICAgICAgICAgICAgICAgZnJhbWUsIG9y
IHplcm8gaWYgbm9uZS4KLQkgKiAgMy4gV3JpdGUgbWVtb3J5IGJhcnJpZXIgKFdNQikuCi0J
ICogIDQuIFdyaXRlIGVudC0+ZmxhZ3MsIGluYy4gdmFsaWQgdHlwZS4KLQkgKi8KLQlzaGFy
ZWRbcmVmXS5mcmFtZSA9IGZyYW1lOwotCXNoYXJlZFtyZWZdLmRvbWlkID0gZG9taWQ7CisJ
Z250dGFiX3NoYXJlZC52MVtyZWZdLmRvbWlkID0gZG9taWQ7CisJZ250dGFiX3NoYXJlZC52
MVtyZWZdLmZyYW1lID0gZnJhbWU7CiAJd21iKCk7Ci0Jc2hhcmVkW3JlZl0uZmxhZ3MgPSBm
bGFnczsKKwlnbnR0YWJfc2hhcmVkLnYxW3JlZl0uZmxhZ3MgPSBmbGFnczsKIH0KIAogLyoK
QEAgLTE2Nyw3ICsyMjQsNyBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfZ3JhbnRfZW50cnkoZ3Jh
bnRfcmVmX3QgcmVmLCBkb21pZF90IGRvbWlkLAogdm9pZCBnbnR0YWJfZ3JhbnRfZm9yZWln
bl9hY2Nlc3NfcmVmKGdyYW50X3JlZl90IHJlZiwgZG9taWRfdCBkb21pZCwKIAkJCQkgICAg
IHVuc2lnbmVkIGxvbmcgZnJhbWUsIGludCByZWFkb25seSkKIHsKLQl1cGRhdGVfZ3JhbnRf
ZW50cnkocmVmLCBkb21pZCwgZnJhbWUsCisJZ250dGFiX2ludGVyZmFjZS0+dXBkYXRlX2Vu
dHJ5KHJlZiwgZG9taWQsIGZyYW1lLAogCQkJICAgR1RGX3Blcm1pdF9hY2Nlc3MgfCAocmVh
ZG9ubHkgPyBHVEZfcmVhZG9ubHkgOiAwKSk7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0
YWJfZ3JhbnRfZm9yZWlnbl9hY2Nlc3NfcmVmKTsKQEAgLTE4NywzMSArMjQ0LDM3IEBAIGlu
dCBnbnR0YWJfZ3JhbnRfZm9yZWlnbl9hY2Nlc3MoZG9taWRfdCBkb21pZCwgdW5zaWduZWQg
bG9uZyBmcmFtZSwKIH0KIEVYUE9SVF9TWU1CT0xfR1BMKGdudHRhYl9ncmFudF9mb3JlaWdu
X2FjY2Vzcyk7CiAKLWludCBnbnR0YWJfcXVlcnlfZm9yZWlnbl9hY2Nlc3MoZ3JhbnRfcmVm
X3QgcmVmKQorc3RhdGljIGludCBnbnR0YWJfcXVlcnlfZm9yZWlnbl9hY2Nlc3NfdjEoZ3Jh
bnRfcmVmX3QgcmVmKQogewotCXUxNiBuZmxhZ3M7Ci0KLQluZmxhZ3MgPSBzaGFyZWRbcmVm
XS5mbGFnczsKKwlyZXR1cm4gZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzICYgKEdURl9y
ZWFkaW5nfEdURl93cml0aW5nKTsKK30KIAotCXJldHVybiBuZmxhZ3MgJiAoR1RGX3JlYWRp
bmd8R1RGX3dyaXRpbmcpOworaW50IGdudHRhYl9xdWVyeV9mb3JlaWduX2FjY2VzcyhncmFu
dF9yZWZfdCByZWYpCit7CisJcmV0dXJuIGdudHRhYl9pbnRlcmZhY2UtPnF1ZXJ5X2ZvcmVp
Z25fYWNjZXNzKHJlZik7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfcXVlcnlfZm9y
ZWlnbl9hY2Nlc3MpOwogCi1pbnQgZ250dGFiX2VuZF9mb3JlaWduX2FjY2Vzc19yZWYoZ3Jh
bnRfcmVmX3QgcmVmLCBpbnQgcmVhZG9ubHkpCitzdGF0aWMgaW50IGdudHRhYl9lbmRfZm9y
ZWlnbl9hY2Nlc3NfcmVmX3YxKGdyYW50X3JlZl90IHJlZiwgaW50IHJlYWRvbmx5KQogewog
CXUxNiBmbGFncywgbmZsYWdzOwogCi0JbmZsYWdzID0gc2hhcmVkW3JlZl0uZmxhZ3M7CisJ
bmZsYWdzID0gZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzOwogCWRvIHsKIAkJZmxhZ3Mg
PSBuZmxhZ3M7CiAJCWlmIChmbGFncyAmIChHVEZfcmVhZGluZ3xHVEZfd3JpdGluZykpIHsK
IAkJCXByaW50ayhLRVJOX0FMRVJUICJXQVJOSU5HOiBnLmUuIHN0aWxsIGluIHVzZSFcbiIp
OwogCQkJcmV0dXJuIDA7CiAJCX0KLQl9IHdoaWxlICgobmZsYWdzID0gc3luY19jbXB4Y2hn
KCZzaGFyZWRbcmVmXS5mbGFncywgZmxhZ3MsIDApKSAhPSBmbGFncyk7CisJfSB3aGlsZSAo
KG5mbGFncyA9IHN5bmNfY21weGNoZygmZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzLCBm
bGFncywgMCkpICE9IGZsYWdzKTsKIAogCXJldHVybiAxOwogfQorCitpbnQgZ250dGFiX2Vu
ZF9mb3JlaWduX2FjY2Vzc19yZWYoZ3JhbnRfcmVmX3QgcmVmLCBpbnQgcmVhZG9ubHkpCit7
CisJcmV0dXJuIGdudHRhYl9pbnRlcmZhY2UtPmVuZF9mb3JlaWduX2FjY2Vzc19yZWYocmVm
LCByZWFkb25seSk7Cit9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfZW5kX2ZvcmVpZ25f
YWNjZXNzX3JlZik7CiAKIHZvaWQgZ250dGFiX2VuZF9mb3JlaWduX2FjY2VzcyhncmFudF9y
ZWZfdCByZWYsIGludCByZWFkb25seSwKQEAgLTI0NiwxMSArMzA5LDExIEBAIEVYUE9SVF9T
WU1CT0xfR1BMKGdudHRhYl9ncmFudF9mb3JlaWduX3RyYW5zZmVyKTsKIHZvaWQgZ250dGFi
X2dyYW50X2ZvcmVpZ25fdHJhbnNmZXJfcmVmKGdyYW50X3JlZl90IHJlZiwgZG9taWRfdCBk
b21pZCwKIAkJCQkgICAgICAgdW5zaWduZWQgbG9uZyBwZm4pCiB7Ci0JdXBkYXRlX2dyYW50
X2VudHJ5KHJlZiwgZG9taWQsIHBmbiwgR1RGX2FjY2VwdF90cmFuc2Zlcik7CisJZ250dGFi
X2ludGVyZmFjZS0+dXBkYXRlX2VudHJ5KHJlZiwgZG9taWQsIHBmbiwgR1RGX2FjY2VwdF90
cmFuc2Zlcik7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfZ3JhbnRfZm9yZWlnbl90
cmFuc2Zlcl9yZWYpOwogCi11bnNpZ25lZCBsb25nIGdudHRhYl9lbmRfZm9yZWlnbl90cmFu
c2Zlcl9yZWYoZ3JhbnRfcmVmX3QgcmVmKQorc3RhdGljIHVuc2lnbmVkIGxvbmcgZ250dGFi
X2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZl92MShncmFudF9yZWZfdCByZWYpCiB7CiAJdW5z
aWduZWQgbG9uZyBmcmFtZTsKIAl1MTYgICAgICAgICAgIGZsYWdzOwpAQCAtMjU5LDI0ICsz
MjIsMjkgQEAgdW5zaWduZWQgbG9uZyBnbnR0YWJfZW5kX2ZvcmVpZ25fdHJhbnNmZXJfcmVm
KGdyYW50X3JlZl90IHJlZikKIAkgKiBJZiBhIHRyYW5zZmVyIGlzIG5vdCBldmVuIHlldCBz
dGFydGVkLCB0cnkgdG8gcmVjbGFpbSB0aGUgZ3JhbnQKIAkgKiByZWZlcmVuY2UgYW5kIHJl
dHVybiBmYWlsdXJlICg9PSAwKS4KIAkgKi8KLQl3aGlsZSAoISgoZmxhZ3MgPSBzaGFyZWRb
cmVmXS5mbGFncykgJiBHVEZfdHJhbnNmZXJfY29tbWl0dGVkKSkgewotCQlpZiAoc3luY19j
bXB4Y2hnKCZzaGFyZWRbcmVmXS5mbGFncywgZmxhZ3MsIDApID09IGZsYWdzKQorCXdoaWxl
ICghKChmbGFncyA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mbGFncykgJiBHVEZfdHJhbnNm
ZXJfY29tbWl0dGVkKSkgeworCQlpZiAoc3luY19jbXB4Y2hnKCZnbnR0YWJfc2hhcmVkLnYx
W3JlZl0uZmxhZ3MsIGZsYWdzLCAwKSA9PSBmbGFncykKIAkJCXJldHVybiAwOwogCQljcHVf
cmVsYXgoKTsKIAl9CiAKIAkvKiBJZiBhIHRyYW5zZmVyIGlzIGluIHByb2dyZXNzIHRoZW4g
d2FpdCB1bnRpbCBpdCBpcyBjb21wbGV0ZWQuICovCiAJd2hpbGUgKCEoZmxhZ3MgJiBHVEZf
dHJhbnNmZXJfY29tcGxldGVkKSkgewotCQlmbGFncyA9IHNoYXJlZFtyZWZdLmZsYWdzOwor
CQlmbGFncyA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mbGFnczsKIAkJY3B1X3JlbGF4KCk7
CiAJfQogCiAJcm1iKCk7CS8qIFJlYWQgdGhlIGZyYW1lIG51bWJlciAvYWZ0ZXIvIHJlYWRp
bmcgY29tcGxldGlvbiBzdGF0dXMuICovCi0JZnJhbWUgPSBzaGFyZWRbcmVmXS5mcmFtZTsK
KwlmcmFtZSA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mcmFtZTsKIAlCVUdfT04oZnJhbWUg
PT0gMCk7CiAKIAlyZXR1cm4gZnJhbWU7CiB9CisKK3Vuc2lnbmVkIGxvbmcgZ250dGFiX2Vu
ZF9mb3JlaWduX3RyYW5zZmVyX3JlZihncmFudF9yZWZfdCByZWYpCit7CisJcmV0dXJuIGdu
dHRhYl9pbnRlcmZhY2UtPmVuZF9mb3JlaWduX3RyYW5zZmVyX3JlZihyZWYpOworfQogRVhQ
T1JUX1NZTUJPTF9HUEwoZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZik7CiAKIHVu
c2lnbmVkIGxvbmcgZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyKGdyYW50X3JlZl90IHJl
ZikKQEAgLTUyMCw2ICs1ODgsMjMgQEAgaW50IGdudHRhYl91bm1hcF9yZWZzKHN0cnVjdCBn
bnR0YWJfdW5tYXBfZ3JhbnRfcmVmICp1bm1hcF9vcHMsCiB9CiBFWFBPUlRfU1lNQk9MX0dQ
TChnbnR0YWJfdW5tYXBfcmVmcyk7CiAKK3N0YXRpYyBpbnQgZ250dGFiX21hcF9mcmFtZXNf
djEodW5zaWduZWQgbG9uZyAqZnJhbWVzLCB1bnNpZ25lZCBpbnQgbnJfZ2ZyYW1lcykKK3sK
KwlpbnQgcmM7CisKKwlyYyA9IGFyY2hfZ250dGFiX21hcF9zaGFyZWQoZnJhbWVzLCBucl9n
ZnJhbWVzLAorCQkJCSAgICBnbnR0YWJfbWF4X2dyYW50X2ZyYW1lcygpLAorCQkJCSAgICAm
Z250dGFiX3NoYXJlZC5hZGRyKTsKKwlCVUdfT04ocmMpOworCisJcmV0dXJuIDA7Cit9CisK
K3N0YXRpYyB2b2lkIGdudHRhYl91bm1hcF9mcmFtZXNfdjEodm9pZCkKK3sKKwlhcmNoX2du
dHRhYl91bm1hcF9zaGFyZWQoZ250dGFiX3NoYXJlZC5hZGRyLCBucl9ncmFudF9mcmFtZXMp
OworfQorCiBzdGF0aWMgaW50IGdudHRhYl9tYXAodW5zaWduZWQgaW50IHN0YXJ0X2lkeCwg
dW5zaWduZWQgaW50IGVuZF9pZHgpCiB7CiAJc3RydWN0IGdudHRhYl9zZXR1cF90YWJsZSBz
ZXR1cDsKQEAgLTU2NywxOSArNjUyLDM1IEBAIHN0YXRpYyBpbnQgZ250dGFiX21hcCh1bnNp
Z25lZCBpbnQgc3RhcnRfaWR4LCB1bnNpZ25lZCBpbnQgZW5kX2lkeCkKIAogCUJVR19PTihy
YyB8fCBzZXR1cC5zdGF0dXMpOwogCi0JcmMgPSBhcmNoX2dudHRhYl9tYXBfc2hhcmVkKGZy
YW1lcywgbnJfZ2ZyYW1lcywgZ250dGFiX21heF9ncmFudF9mcmFtZXMoKSwKLQkJCQkgICAg
JnNoYXJlZCk7Ci0JQlVHX09OKHJjKTsKKwlyYyA9IGdudHRhYl9pbnRlcmZhY2UtPm1hcF9m
cmFtZXMoZnJhbWVzLCBucl9nZnJhbWVzKTsKIAogCWtmcmVlKGZyYW1lcyk7CiAKLQlyZXR1
cm4gMDsKKwlyZXR1cm4gcmM7Cit9CisKK3N0YXRpYyBzdHJ1Y3QgZ250dGFiX29wcyBnbnR0
YWJfdjFfb3BzID0geworCS5tYXBfZnJhbWVzCQkJPSBnbnR0YWJfbWFwX2ZyYW1lc192MSwK
KwkudW5tYXBfZnJhbWVzCQkJPSBnbnR0YWJfdW5tYXBfZnJhbWVzX3YxLAorCS51cGRhdGVf
ZW50cnkJCQk9IHVwZGF0ZV9ncmFudF9lbnRyeV92MSwKKwkuZW5kX2ZvcmVpZ25fYWNjZXNz
X3JlZgkJPSBnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzX3JlZl92MSwKKwkuZW5kX2ZvcmVp
Z25fdHJhbnNmZXJfcmVmCT0gZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZl92MSwK
KwkucXVlcnlfZm9yZWlnbl9hY2Nlc3MJCT0gZ250dGFiX3F1ZXJ5X2ZvcmVpZ25fYWNjZXNz
X3YxLAorfTsKKworc3RhdGljIHZvaWQgZ250dGFiX3JlcXVlc3RfdmVyc2lvbih2b2lkKQor
eworCWdyYW50X3RhYmxlX3ZlcnNpb24gPSAxOworCWdudHRhYl9pbnRlcmZhY2UgPSAmZ250
dGFiX3YxX29wczsKKwlwcmludGsoS0VSTl9JTkZPICJHcmFudCB0YWJsZXMgdXNpbmcgdmVy
c2lvbiAlZCBsYXlvdXQuXG4iLAorCQlncmFudF90YWJsZV92ZXJzaW9uKTsKIH0KIAogaW50
IGdudHRhYl9yZXN1bWUodm9pZCkKIHsKIAl1bnNpZ25lZCBpbnQgbWF4X25yX2dmcmFtZXM7
CiAKKwlnbnR0YWJfcmVxdWVzdF92ZXJzaW9uKCk7CiAJbWF4X25yX2dmcmFtZXMgPSBnbnR0
YWJfbWF4X2dyYW50X2ZyYW1lcygpOwogCWlmIChtYXhfbnJfZ2ZyYW1lcyA8IG5yX2dyYW50
X2ZyYW1lcykKIAkJcmV0dXJuIC1FTk9TWVM7CkBAIC01ODcsOSArNjg4LDEwIEBAIGludCBn
bnR0YWJfcmVzdW1lKHZvaWQpCiAJaWYgKHhlbl9wdl9kb21haW4oKSkKIAkJcmV0dXJuIGdu
dHRhYl9tYXAoMCwgbnJfZ3JhbnRfZnJhbWVzIC0gMSk7CiAKLQlpZiAoIXNoYXJlZCkgewot
CQlzaGFyZWQgPSBpb3JlbWFwKHhlbl9odm1fcmVzdW1lX2ZyYW1lcywgUEFHRV9TSVpFICog
bWF4X25yX2dmcmFtZXMpOwotCQlpZiAoc2hhcmVkID09IE5VTEwpIHsKKwlpZiAoZ250dGFi
X3NoYXJlZC5hZGRyID09IE5VTEwpIHsKKwkJZ250dGFiX3NoYXJlZC5hZGRyID0gaW9yZW1h
cCh4ZW5faHZtX3Jlc3VtZV9mcmFtZXMsCisJCQkJCQlQQUdFX1NJWkUgKiBtYXhfbnJfZ2Zy
YW1lcyk7CisJCWlmIChnbnR0YWJfc2hhcmVkLmFkZHIgPT0gTlVMTCkgewogCQkJcHJpbnRr
KEtFUk5fV0FSTklORwogCQkJCQkiRmFpbGVkIHRvIGlvcmVtYXAgZ250dGFiIHNoYXJlIGZy
YW1lcyEiKTsKIAkJCXJldHVybiAtRU5PTUVNOwpAQCAtNjAzLDcgKzcwNSw3IEBAIGludCBn
bnR0YWJfcmVzdW1lKHZvaWQpCiAKIGludCBnbnR0YWJfc3VzcGVuZCh2b2lkKQogewotCWFy
Y2hfZ250dGFiX3VubWFwX3NoYXJlZChzaGFyZWQsIG5yX2dyYW50X2ZyYW1lcyk7CisJZ250
dGFiX2ludGVyZmFjZS0+dW5tYXBfZnJhbWVzKCk7CiAJcmV0dXJuIDA7CiB9CiAKZGlmZiAt
LWdpdCBhL2luY2x1ZGUveGVuL2dyYW50X3RhYmxlLmggYi9pbmNsdWRlL3hlbi9ncmFudF90
YWJsZS5oCmluZGV4IDExZTJkZmMuLmM3YTQwZjggMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVu
L2dyYW50X3RhYmxlLmgKKysrIGIvaW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUuaApAQCAtMTQ1
LDggKzE0NSw4IEBAIGdudHRhYl9zZXRfdW5tYXBfb3Aoc3RydWN0IGdudHRhYl91bm1hcF9n
cmFudF9yZWYgKnVubWFwLCBwaHlzX2FkZHJfdCBhZGRyLAogCiBpbnQgYXJjaF9nbnR0YWJf
bWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGxvbmcgbnJfZ2Zy
YW1lcywKIAkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFtZXMsCi0JCQkgICBzdHJ1
Y3QgZ3JhbnRfZW50cnkgKipfX3NoYXJlZCk7Ci12b2lkIGFyY2hfZ250dGFiX3VubWFwX3No
YXJlZChzdHJ1Y3QgZ3JhbnRfZW50cnkgKnNoYXJlZCwKKwkJCSAgIHZvaWQgKipfX3NoYXJl
ZCk7Cit2b2lkIGFyY2hfZ250dGFiX3VubWFwX3NoYXJlZCh2b2lkICpzaGFyZWQsCiAJCQkg
ICAgICB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpOwogCiBleHRlcm4gdW5zaWduZWQgbG9u
ZyB4ZW5faHZtX3Jlc3VtZV9mcmFtZXM7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9pbnRl
cmZhY2UvZ3JhbnRfdGFibGUuaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFudF90YWJs
ZS5oCmluZGV4IDM5ZTU3MTcuLmExN2Q4NDQgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2lu
dGVyZmFjZS9ncmFudF90YWJsZS5oCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFu
dF90YWJsZS5oCkBAIC04NSwxMiArODUsMjIgQEAKICAqLwogCiAvKgorICogUmVmZXJlbmNl
IHRvIGEgZ3JhbnQgZW50cnkgaW4gYSBzcGVjaWZpZWQgZG9tYWluJ3MgZ3JhbnQgdGFibGUu
CisgKi8KK3R5cGVkZWYgdWludDMyX3QgZ3JhbnRfcmVmX3Q7CisKKy8qCiAgKiBBIGdyYW50
IHRhYmxlIGNvbXByaXNlcyBhIHBhY2tlZCBhcnJheSBvZiBncmFudCBlbnRyaWVzIGluIG9u
ZSBvciBtb3JlCiAgKiBwYWdlIGZyYW1lcyBzaGFyZWQgYmV0d2VlbiBYZW4gYW5kIGEgZ3Vl
c3QuCiAgKiBbWEVOXTogVGhpcyBmaWVsZCBpcyB3cml0dGVuIGJ5IFhlbiBhbmQgcmVhZCBi
eSB0aGUgc2hhcmluZyBndWVzdC4KICAqIFtHU1RdOiBUaGlzIGZpZWxkIGlzIHdyaXR0ZW4g
YnkgdGhlIGd1ZXN0IGFuZCByZWFkIGJ5IFhlbi4KICAqLwotc3RydWN0IGdyYW50X2VudHJ5
IHsKKworLyoKKyAqIFZlcnNpb24gMSBvZiB0aGUgZ3JhbnQgdGFibGUgZW50cnkgc3RydWN0
dXJlIGlzIG1haW50YWluZWQgcHVyZWx5CisgKiBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxp
dHkuICBOZXcgZ3Vlc3RzIHNob3VsZCB1c2UgdmVyc2lvbiAyLgorICovCitzdHJ1Y3QgZ3Jh
bnRfZW50cnlfdjEgewogICAgIC8qIEdURl94eHg6IHZhcmlvdXMgdHlwZSBhbmQgZmxhZyBp
bmZvcm1hdGlvbi4gIFtYRU4sR1NUXSAqLwogICAgIHVpbnQxNl90IGZsYWdzOwogICAgIC8q
IFRoZSBkb21haW4gYmVpbmcgZ3JhbnRlZCBmb3JlaWduIHByaXZpbGVnZXMuIFtHU1RdICov
CkBAIC0xMDgsMTAgKzExOCwxMyBAQCBzdHJ1Y3QgZ3JhbnRfZW50cnkgewogICogIEdURl9w
ZXJtaXRfYWNjZXNzOiBBbGxvdyBAZG9taWQgdG8gbWFwL2FjY2VzcyBAZnJhbWUuCiAgKiAg
R1RGX2FjY2VwdF90cmFuc2ZlcjogQWxsb3cgQGRvbWlkIHRvIHRyYW5zZmVyIG93bmVyc2hp
cCBvZiBvbmUgcGFnZSBmcmFtZQogICogICAgICAgICAgICAgICAgICAgICAgIHRvIHRoaXMg
Z3Vlc3QuIFhlbiB3cml0ZXMgdGhlIHBhZ2UgbnVtYmVyIHRvIEBmcmFtZS4KKyAqICBHVEZf
dHJhbnNpdGl2ZTogQWxsb3cgQGRvbWlkIHRvIHRyYW5zaXRpdmVseSBhY2Nlc3MgYSBzdWJy
YW5nZSBvZgorICogICAgICAgICAgICAgICAgICBAdHJhbnNfZ3JhbnQgaW4gQHRyYW5zX2Rv
bWlkLiAgTm8gbWFwcGluZ3MgYXJlIGFsbG93ZWQuCiAgKi8KICNkZWZpbmUgR1RGX2ludmFs
aWQgICAgICAgICAoMFU8PDApCiAjZGVmaW5lIEdURl9wZXJtaXRfYWNjZXNzICAgKDFVPDww
KQogI2RlZmluZSBHVEZfYWNjZXB0X3RyYW5zZmVyICgyVTw8MCkKKyNkZWZpbmUgR1RGX3Ry
YW5zaXRpdmUgICAgICAoM1U8PDApCiAjZGVmaW5lIEdURl90eXBlX21hc2sgICAgICAgKDNV
PDwwKQogCiAvKgpAQCAtMTE5LDYgKzEzMiw5IEBAIHN0cnVjdCBncmFudF9lbnRyeSB7CiAg
KiAgR1RGX3JlYWRvbmx5OiBSZXN0cmljdCBAZG9taWQgdG8gcmVhZC1vbmx5IG1hcHBpbmdz
IGFuZCBhY2Nlc3Nlcy4gW0dTVF0KICAqICBHVEZfcmVhZGluZzogR3JhbnQgZW50cnkgaXMg
Y3VycmVudGx5IG1hcHBlZCBmb3IgcmVhZGluZyBieSBAZG9taWQuIFtYRU5dCiAgKiAgR1RG
X3dyaXRpbmc6IEdyYW50IGVudHJ5IGlzIGN1cnJlbnRseSBtYXBwZWQgZm9yIHdyaXRpbmcg
YnkgQGRvbWlkLiBbWEVOXQorICogIEdURl9zdWJfcGFnZTogR3JhbnQgYWNjZXNzIHRvIG9u
bHkgYSBzdWJyYW5nZSBvZiB0aGUgcGFnZS4gIEBkb21pZAorICogICAgICAgICAgICAgICAg
d2lsbCBvbmx5IGJlIGFsbG93ZWQgdG8gY29weSBmcm9tIHRoZSBncmFudCwgYW5kIG5vdAor
ICogICAgICAgICAgICAgICAgbWFwIGl0LiBbR1NUXQogICovCiAjZGVmaW5lIF9HVEZfcmVh
ZG9ubHkgICAgICAgKDIpCiAjZGVmaW5lIEdURl9yZWFkb25seSAgICAgICAgKDFVPDxfR1RG
X3JlYWRvbmx5KQpAQCAtMTI2LDYgKzE0Miw4IEBAIHN0cnVjdCBncmFudF9lbnRyeSB7CiAj
ZGVmaW5lIEdURl9yZWFkaW5nICAgICAgICAgKDFVPDxfR1RGX3JlYWRpbmcpCiAjZGVmaW5l
IF9HVEZfd3JpdGluZyAgICAgICAgKDQpCiAjZGVmaW5lIEdURl93cml0aW5nICAgICAgICAg
KDFVPDxfR1RGX3dyaXRpbmcpCisjZGVmaW5lIF9HVEZfc3ViX3BhZ2UgICAgICAgKDgpCisj
ZGVmaW5lIEdURl9zdWJfcGFnZSAgICAgICAgKDFVPDxfR1RGX3N1Yl9wYWdlKQogCiAvKgog
ICogU3ViZmxhZ3MgZm9yIEdURl9hY2NlcHRfdHJhbnNmZXI6CkBAIC0xNDIsMTUgKzE2MCw4
MSBAQCBzdHJ1Y3QgZ3JhbnRfZW50cnkgewogI2RlZmluZSBfR1RGX3RyYW5zZmVyX2NvbXBs
ZXRlZCAoMykKICNkZWZpbmUgR1RGX3RyYW5zZmVyX2NvbXBsZXRlZCAgKDFVPDxfR1RGX3Ry
YW5zZmVyX2NvbXBsZXRlZCkKIAorLyoKKyAqIFZlcnNpb24gMiBncmFudCB0YWJsZSBlbnRy
aWVzLiAgVGhlc2UgZnVsZmlsIHRoZSBzYW1lIHJvbGUgYXMKKyAqIHZlcnNpb24gMSBlbnRy
aWVzLCBidXQgY2FuIHJlcHJlc2VudCBtb3JlIGNvbXBsaWNhdGVkIG9wZXJhdGlvbnMuCisg
KiBBbnkgZ2l2ZW4gZG9tYWluIHdpbGwgaGF2ZSBlaXRoZXIgYSB2ZXJzaW9uIDEgb3IgYSB2
ZXJzaW9uIDIgdGFibGUsCisgKiBhbmQgZXZlcnkgZW50cnkgaW4gdGhlIHRhYmxlIHdpbGwg
YmUgdGhlIHNhbWUgdmVyc2lvbi4KKyAqCisgKiBUaGUgaW50ZXJmYWNlIGJ5IHdoaWNoIGRv
bWFpbnMgdXNlIGdyYW50IHJlZmVyZW5jZXMgZG9lcyBub3QgZGVwZW5kCisgKiBvbiB0aGUg
Z3JhbnQgdGFibGUgdmVyc2lvbiBpbiB1c2UgYnkgdGhlIG90aGVyIGRvbWFpbi4KKyAqLwog
Ci0vKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKLSAqIEdSQU5UIFRBQkxF
IFFVRVJJRVMgQU5EIFVTRVMKKy8qCisgKiBWZXJzaW9uIDEgYW5kIHZlcnNpb24gMiBncmFu
dCBlbnRyaWVzIHNoYXJlIGEgY29tbW9uIHByZWZpeC4gIFRoZQorICogZmllbGRzIG9mIHRo
ZSBwcmVmaXggYXJlIGRvY3VtZW50ZWQgYXMgcGFydCBvZiBzdHJ1Y3QKKyAqIGdyYW50X2Vu
dHJ5X3YxLgogICovCitzdHJ1Y3QgZ3JhbnRfZW50cnlfaGVhZGVyIHsKKyAgICB1aW50MTZf
dCBmbGFnczsKKyAgICBkb21pZF90ICBkb21pZDsKK307CiAKIC8qCi0gKiBSZWZlcmVuY2Ug
dG8gYSBncmFudCBlbnRyeSBpbiBhIHNwZWNpZmllZCBkb21haW4ncyBncmFudCB0YWJsZS4K
KyAqIFZlcnNpb24gMiBvZiB0aGUgZ3JhbnQgZW50cnkgc3RydWN0dXJlLCBoZXJlIGlzIGFu
IHVuaW9uIGJlY2F1c2UgdGhyZWUKKyAqIGRpZmZlcmVudCB0eXBlcyBhcmUgc3VwcG90dGVk
OiBmdWxsX3BhZ2UsIHN1Yl9wYWdlIGFuZCB0cmFuc2l0aXZlLgorICovCit1bmlvbiBncmFu
dF9lbnRyeV92MiB7CisgICAgc3RydWN0IGdyYW50X2VudHJ5X2hlYWRlciBoZHI7CisKKyAg
ICAvKgorICAgICAqIFRoaXMgbWVtYmVyIGlzIHVzZWQgZm9yIFYxLXN0eWxlIGZ1bGwgcGFn
ZSBncmFudHMsIHdoZXJlIGVpdGhlcjoKKyAgICAgKgorICAgICAqIC0tIGhkci50eXBlIGlz
IEdURl9hY2NlcHRfdHJhbnNmZXIsIG9yCisgICAgICogLS0gaGRyLnR5cGUgaXMgR1RGX3Bl
cm1pdF9hY2Nlc3MgYW5kIEdURl9zdWJfcGFnZSBpcyBub3Qgc2V0LgorICAgICAqCisgICAg
ICogSW4gdGhhdCBjYXNlLCB0aGUgZnJhbWUgZmllbGQgaGFzIHRoZSBzYW1lIHNlbWFudGlj
cyBhcyB0aGUKKyAgICAgKiBmaWVsZCBvZiB0aGUgc2FtZSBuYW1lIGluIHRoZSBWMSBlbnRy
eSBzdHJ1Y3R1cmUuCisgICAgICovCisgICAgc3RydWN0IHsKKwlzdHJ1Y3QgZ3JhbnRfZW50
cnlfaGVhZGVyIGhkcjsKKwl1aW50MzJfdCBwYWQwOworCXVpbnQ2NF90IGZyYW1lOworICAg
IH0gZnVsbF9wYWdlOworCisgICAgLyoKKyAgICAgKiBJZiB0aGUgZ3JhbnQgdHlwZSBpcyBH
VEZfZ3JhbnRfYWNjZXNzIGFuZCBHVEZfc3ViX3BhZ2UgaXMgc2V0LAorICAgICAqIEBkb21p
ZCBpcyBhbGxvd2VkIHRvIGFjY2VzcyBieXRlcyBbQHBhZ2Vfb2ZmLEBwYWdlX29mZitAbGVu
Z3RoKQorICAgICAqIGluIGZyYW1lIEBmcmFtZS4KKyAgICAgKi8KKyAgICBzdHJ1Y3Qgewor
CXN0cnVjdCBncmFudF9lbnRyeV9oZWFkZXIgaGRyOworCXVpbnQxNl90IHBhZ2Vfb2ZmOwor
CXVpbnQxNl90IGxlbmd0aDsKKwl1aW50NjRfdCBmcmFtZTsKKyAgICB9IHN1Yl9wYWdlOwor
CisgICAgLyoKKyAgICAgKiBJZiB0aGUgZ3JhbnQgaXMgR1RGX3RyYW5zaXRpdmUsIEBkb21p
ZCBpcyBhbGxvd2VkIHRvIHVzZSB0aGUKKyAgICAgKiBncmFudCBAZ3JlZiBpbiBkb21haW4g
QHRyYW5zX2RvbWlkLCBhcyBpZiBpdCB3YXMgdGhlIGxvY2FsCisgICAgICogZG9tYWluLiAg
T2J2aW91c2x5LCB0aGUgdHJhbnNpdGl2ZSBhY2Nlc3MgbXVzdCBiZSBjb21wYXRpYmxlCisg
ICAgICogd2l0aCB0aGUgb3JpZ2luYWwgZ3JhbnQuCisgICAgICovCisgICAgc3RydWN0IHsK
KwlzdHJ1Y3QgZ3JhbnRfZW50cnlfaGVhZGVyIGhkcjsKKwlkb21pZF90IHRyYW5zX2RvbWlk
OworCXVpbnQxNl90IHBhZDA7CisJZ3JhbnRfcmVmX3QgZ3JlZjsKKyAgICB9IHRyYW5zaXRp
dmU7CisKKyAgICB1aW50MzJfdCBfX3NwYWNlcls0XTsgLyogUGFkIHRvIGEgcG93ZXIgb2Yg
dHdvICovCit9OworCit0eXBlZGVmIHVpbnQxNl90IGdyYW50X3N0YXR1c190OworCisvKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKyAqIEdSQU5UIFRBQkxFIFFVRVJJ
RVMgQU5EIFVTRVMKICAqLwotdHlwZWRlZiB1aW50MzJfdCBncmFudF9yZWZfdDsKIAogLyoK
ICAqIEhhbmRsZSB0byB0cmFjayBhIG1hcHBpbmcgY3JlYXRlZCB2aWEgYSBncmFudCByZWZl
cmVuY2UuCkBAIC0zMjIsNiArNDA2LDc5IEBAIHN0cnVjdCBnbnR0YWJfcXVlcnlfc2l6ZSB7
CiBERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVChnbnR0YWJfcXVlcnlfc2l6ZSk7CiAKIC8q
CisgKiBHTlRUQUJPUF91bm1hcF9hbmRfcmVwbGFjZTogRGVzdHJveSBvbmUgb3IgbW9yZSBn
cmFudC1yZWZlcmVuY2UgbWFwcGluZ3MKKyAqIHRyYWNrZWQgYnkgPGhhbmRsZT4gYnV0IGF0
b21pY2FsbHkgcmVwbGFjZSB0aGUgcGFnZSB0YWJsZSBlbnRyeSB3aXRoIG9uZQorICogcG9p
bnRpbmcgdG8gdGhlIG1hY2hpbmUgYWRkcmVzcyB1bmRlciA8bmV3X2FkZHI+LiAgPG5ld19h
ZGRyPiB3aWxsIGJlCisgKiByZWRpcmVjdGVkIHRvIHRoZSBudWxsIGVudHJ5LgorICogTk9U
RVM6CisgKiAgMS4gVGhlIGNhbGwgbWF5IGZhaWwgaW4gYW4gdW5kZWZpbmVkIG1hbm5lciBp
ZiBlaXRoZXIgbWFwcGluZyBpcyBub3QKKyAqICAgICB0cmFja2VkIGJ5IDxoYW5kbGU+Lgor
ICogIDIuIEFmdGVyIGV4ZWN1dGluZyBhIGJhdGNoIG9mIHVubWFwcywgaXQgaXMgZ3VhcmFu
dGVlZCB0aGF0IG5vIHN0YWxlCisgKiAgICAgbWFwcGluZ3Mgd2lsbCByZW1haW4gaW4gdGhl
IGRldmljZSBvciBob3N0IFRMQnMuCisgKi8KKyNkZWZpbmUgR05UVEFCT1BfdW5tYXBfYW5k
X3JlcGxhY2UgICAgNworc3RydWN0IGdudHRhYl91bm1hcF9hbmRfcmVwbGFjZSB7CisgICAg
LyogSU4gcGFyYW1ldGVycy4gKi8KKyAgICB1aW50NjRfdCBob3N0X2FkZHI7CisgICAgdWlu
dDY0X3QgbmV3X2FkZHI7CisgICAgZ3JhbnRfaGFuZGxlX3QgaGFuZGxlOworICAgIC8qIE9V
VCBwYXJhbWV0ZXJzLiAqLworICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAgICAgIC8q
IEdOVFNUXyogKi8KK307CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVChnbnR0YWJfdW5t
YXBfYW5kX3JlcGxhY2UpOworCisvKgorICogR05UVEFCT1Bfc2V0X3ZlcnNpb246IFJlcXVl
c3QgYSBwYXJ0aWN1bGFyIHZlcnNpb24gb2YgdGhlIGdyYW50CisgKiB0YWJsZSBzaGFyZWQg
dGFibGUgc3RydWN0dXJlLiAgVGhpcyBvcGVyYXRpb24gY2FuIG9ubHkgYmUgcGVyZm9ybWVk
CisgKiBvbmNlIGluIGFueSBnaXZlbiBkb21haW4uICBJdCBtdXN0IGJlIHBlcmZvcm1lZCBi
ZWZvcmUgYW55IGdyYW50cworICogYXJlIGFjdGl2YXRlZDsgb3RoZXJ3aXNlLCB0aGUgZG9t
YWluIHdpbGwgYmUgc3R1Y2sgd2l0aCB2ZXJzaW9uIDEuCisgKiBUaGUgb25seSBkZWZpbmVk
IHZlcnNpb25zIGFyZSAxIGFuZCAyLgorICovCisjZGVmaW5lIEdOVFRBQk9QX3NldF92ZXJz
aW9uICAgICAgICAgIDgKK3N0cnVjdCBnbnR0YWJfc2V0X3ZlcnNpb24geworICAgIC8qIElO
IHBhcmFtZXRlcnMgKi8KKyAgICB1aW50MzJfdCB2ZXJzaW9uOworfTsKK0RFRklORV9HVUVT
VF9IQU5ETEVfU1RSVUNUKGdudHRhYl9zZXRfdmVyc2lvbik7CisKKy8qCisgKiBHTlRUQUJP
UF9nZXRfc3RhdHVzX2ZyYW1lczogR2V0IHRoZSBsaXN0IG9mIGZyYW1lcyB1c2VkIHRvIHN0
b3JlIGdyYW50CisgKiBzdGF0dXMgZm9yIDxkb20+LiBJbiBncmFudCBmb3JtYXQgdmVyc2lv
biAyLCB0aGUgc3RhdHVzIGlzIHNlcGFyYXRlZAorICogZnJvbSB0aGUgb3RoZXIgc2hhcmVk
IGdyYW50IGZpZWxkcyB0byBhbGxvdyBtb3JlIGVmZmljaWVudCBzeW5jaHJvbml6YXRpb24K
KyAqIHVzaW5nIGJhcnJpZXJzIGluc3RlYWQgb2YgYXRvbWljIGNtcGV4Y2ggb3BlcmF0aW9u
cy4KKyAqIDxucl9mcmFtZXM+IHNwZWNpZnkgdGhlIHNpemUgb2YgdmVjdG9yIDxmcmFtZV9s
aXN0Pi4KKyAqIFRoZSBmcmFtZSBhZGRyZXNzZXMgYXJlIHJldHVybmVkIGluIHRoZSA8ZnJh
bWVfbGlzdD4uCisgKiBPbmx5IDxucl9mcmFtZXM+IGFkZHJlc3NlcyBhcmUgcmV0dXJuZWQs
IGV2ZW4gaWYgdGhlIHRhYmxlIGlzIGxhcmdlci4KKyAqIE5PVEVTOgorICogIDEuIDxkb20+
IG1heSBiZSBzcGVjaWZpZWQgYXMgRE9NSURfU0VMRi4KKyAqICAyLiBPbmx5IGEgc3VmZmlj
aWVudGx5LXByaXZpbGVnZWQgZG9tYWluIG1heSBzcGVjaWZ5IDxkb20+ICE9IERPTUlEX1NF
TEYuCisgKi8KKyNkZWZpbmUgR05UVEFCT1BfZ2V0X3N0YXR1c19mcmFtZXMgICAgIDkKK3N0
cnVjdCBnbnR0YWJfZ2V0X3N0YXR1c19mcmFtZXMgeworICAgIC8qIElOIHBhcmFtZXRlcnMu
ICovCisgICAgdWludDMyX3QgbnJfZnJhbWVzOworICAgIGRvbWlkX3QgIGRvbTsKKyAgICAv
KiBPVVQgcGFyYW1ldGVycy4gKi8KKyAgICBpbnQxNl90ICBzdGF0dXM7ICAgICAgICAgICAg
ICAvKiBHTlRTVF8qICovCisgICAgR1VFU1RfSEFORExFKHVpbnQ2NF90KSBmcmFtZV9saXN0
OworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKGdudHRhYl9nZXRfc3RhdHVzX2Zy
YW1lcyk7CisKKy8qCisgKiBHTlRUQUJPUF9nZXRfdmVyc2lvbjogR2V0IHRoZSBncmFudCB0
YWJsZSB2ZXJzaW9uIHdoaWNoIGlzIGluCisgKiBlZmZlY3QgZm9yIGRvbWFpbiA8ZG9tPi4K
KyAqLworI2RlZmluZSBHTlRUQUJPUF9nZXRfdmVyc2lvbiAgICAgICAgICAxMAorc3RydWN0
IGdudHRhYl9nZXRfdmVyc2lvbiB7CisgICAgLyogSU4gcGFyYW1ldGVycyAqLworICAgIGRv
bWlkX3QgZG9tOworICAgIHVpbnQxNl90IHBhZDsKKyAgICAvKiBPVVQgcGFyYW1ldGVycyAq
LworICAgIHVpbnQzMl90IHZlcnNpb247Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJV
Q1QoZ250dGFiX2dldF92ZXJzaW9uKTsKKworLyoKICAqIEJpdGZpZWxkIHZhbHVlcyBmb3Ig
dXBkYXRlX3Bpbl9zdGF0dXMuZmxhZ3MuCiAgKi8KICAvKiBNYXAgdGhlIGdyYW50IGVudHJ5
IGZvciBhY2Nlc3MgYnkgSS9PIGRldmljZXMuICovCmRpZmYgLS1naXQgYS9pbmNsdWRlL3hl
bi9pbnRlcmZhY2UveGVuLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLmgKaW5kZXgg
NmE2ZTkxNC4uYTg5MDgwNCAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hl
bi5oCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaApAQCAtNTIzLDYgKzUyMyw4
IEBAIHN0cnVjdCB0bWVtX29wIHsKIAl9IHU7CiB9OwogCitERUZJTkVfR1VFU1RfSEFORExF
KHU2NCk7CisKICNlbHNlIC8qIF9fQVNTRU1CTFlfXyAqLwogCiAvKiBJbiBhc3NlbWJseSBj
b2RlIHdlIGNhbm5vdCB1c2UgQyBudW1lcmljIGNvbnN0YW50IHN1ZmZpeGVzLiAqLwotLSAK
MS43LjYuNAoK
--------------060201000507000106030009
Content-Type: text/plain; name="0002-xen-granttable-Refactor-some-code.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0002-xen-granttable-Refactor-some-code.patch"

RnJvbSAzMjc4MDZjYjNlNzg3M2IzZWZmMjI5ZjM3YzRjMTc3MTdjNDAyYzllIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4K
RGF0ZTogRnJpLCAxOCBOb3YgMjAxMSAxNjozMjo1NiArMDgwMApTdWJqZWN0OiBbUEFUQ0gg
Mi80XSB4ZW4vZ3JhbnR0YWJsZTogUmVmYWN0b3Igc29tZSBjb2RlCgpTaWduZWQtb2ZmLWJ5
OiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4KLS0tCiBkcml2ZXJzL3hlbi9ncmFu
dC10YWJsZS5jIHwgICAxNSArKysrKysrKysrLS0tLS0KIDEgZmlsZXMgY2hhbmdlZCwgMTAg
aW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hl
bi9ncmFudC10YWJsZS5jIGIvZHJpdmVycy94ZW4vZ3JhbnQtdGFibGUuYwppbmRleCA1ZDkz
MWI4Li5mMzMwNDFlIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9ncmFudC10YWJsZS5jCisr
KyBiL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMKQEAgLTI1OCwxNSArMjU4LDE3IEBAIEVY
UE9SVF9TWU1CT0xfR1BMKGdudHRhYl9xdWVyeV9mb3JlaWduX2FjY2Vzcyk7CiBzdGF0aWMg
aW50IGdudHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3NfcmVmX3YxKGdyYW50X3JlZl90IHJlZiwg
aW50IHJlYWRvbmx5KQogewogCXUxNiBmbGFncywgbmZsYWdzOworCXUxNiAqcGZsYWdzOwog
Ci0JbmZsYWdzID0gZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzOworCXBmbGFncyA9ICZn
bnR0YWJfc2hhcmVkLnYxW3JlZl0uZmxhZ3M7CisJbmZsYWdzID0gKnBmbGFnczsKIAlkbyB7
CiAJCWZsYWdzID0gbmZsYWdzOwogCQlpZiAoZmxhZ3MgJiAoR1RGX3JlYWRpbmd8R1RGX3dy
aXRpbmcpKSB7CiAJCQlwcmludGsoS0VSTl9BTEVSVCAiV0FSTklORzogZy5lLiBzdGlsbCBp
biB1c2UhXG4iKTsKIAkJCXJldHVybiAwOwogCQl9Ci0JfSB3aGlsZSAoKG5mbGFncyA9IHN5
bmNfY21weGNoZygmZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzLCBmbGFncywgMCkpICE9
IGZsYWdzKTsKKwl9IHdoaWxlICgobmZsYWdzID0gc3luY19jbXB4Y2hnKHBmbGFncywgZmxh
Z3MsIDApKSAhPSBmbGFncyk7CiAKIAlyZXR1cm4gMTsKIH0KQEAgLTMxNywyMCArMzE5LDIz
IEBAIHN0YXRpYyB1bnNpZ25lZCBsb25nIGdudHRhYl9lbmRfZm9yZWlnbl90cmFuc2Zlcl9y
ZWZfdjEoZ3JhbnRfcmVmX3QgcmVmKQogewogCXVuc2lnbmVkIGxvbmcgZnJhbWU7CiAJdTE2
ICAgICAgICAgICBmbGFnczsKKwl1MTYgICAgICAgICAgKnBmbGFnczsKKworCXBmbGFncyA9
ICZnbnR0YWJfc2hhcmVkLnYxW3JlZl0uZmxhZ3M7CiAKIAkvKgogCSAqIElmIGEgdHJhbnNm
ZXIgaXMgbm90IGV2ZW4geWV0IHN0YXJ0ZWQsIHRyeSB0byByZWNsYWltIHRoZSBncmFudAog
CSAqIHJlZmVyZW5jZSBhbmQgcmV0dXJuIGZhaWx1cmUgKD09IDApLgogCSAqLwotCXdoaWxl
ICghKChmbGFncyA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mbGFncykgJiBHVEZfdHJhbnNm
ZXJfY29tbWl0dGVkKSkgewotCQlpZiAoc3luY19jbXB4Y2hnKCZnbnR0YWJfc2hhcmVkLnYx
W3JlZl0uZmxhZ3MsIGZsYWdzLCAwKSA9PSBmbGFncykKKwl3aGlsZSAoISgoZmxhZ3MgPSAq
cGZsYWdzKSAmIEdURl90cmFuc2Zlcl9jb21taXR0ZWQpKSB7CisJCWlmIChzeW5jX2NtcHhj
aGcocGZsYWdzLCBmbGFncywgMCkgPT0gZmxhZ3MpCiAJCQlyZXR1cm4gMDsKIAkJY3B1X3Jl
bGF4KCk7CiAJfQogCiAJLyogSWYgYSB0cmFuc2ZlciBpcyBpbiBwcm9ncmVzcyB0aGVuIHdh
aXQgdW50aWwgaXQgaXMgY29tcGxldGVkLiAqLwogCXdoaWxlICghKGZsYWdzICYgR1RGX3Ry
YW5zZmVyX2NvbXBsZXRlZCkpIHsKLQkJZmxhZ3MgPSBnbnR0YWJfc2hhcmVkLnYxW3JlZl0u
ZmxhZ3M7CisJCWZsYWdzID0gKnBmbGFnczsKIAkJY3B1X3JlbGF4KCk7CiAJfQogCi0tIAox
LjcuNi40Cgo=
--------------060201000507000106030009
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------060201000507000106030009--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:09:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:09:59 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLOR-0003Fo-0j
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLO4-0004b5-Ci; Fri, 18 Nov 2011 02:09:36 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLMi-0004Z0-WB
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:08:18 -0800
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321610849!63710530!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5860 invoked from network); 18 Nov 2011 10:07:30 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 10:07:30 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIA84tk022626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 10:08:05 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIA7xto015346
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 10:08:00 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIA7pCH021032; Fri, 18 Nov 2011 04:07:52 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 02:07:50 -0800
Message-ID: <4EC62E77.7090007@oracle.com>
Date: Fri, 18 Nov 2011 18:07:51 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	paul.durrant@citrix.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
	V2 stucture
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1321451304-13559-1-git-send-email-annie.li@oracle.com>
Content-Type: multipart/mixed; boundary="------------060201000507000106030009"
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4EC62E85.012E,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, jeremy@goop.org,
	konrad.wilk@oracle.com
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------060201000507000106030009
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi

I split this patch into two, 0001-** is about renaming and abstracting 
to function pointers, 0002-** is for refactoring code.

Thanks
Annie

--------------060201000507000106030009
Content-Type: text/plain;
	name="0001-xen-granttable-Introducing-grant-table-V2-stucture.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename*0="0001-xen-granttable-Introducing-grant-table-V2-stucture.patc";
	filename*1="h"

RnJvbSBjMTBlYjg5NWFiYjU3OWU1MDc1OWJhZmNiZmQ1NGFlODAyMDZiYWIwIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4K
RGF0ZTogRnJpLCAxOCBOb3YgMjAxMSAxNjowNzoxNiArMDgwMApTdWJqZWN0OiBbUEFUQ0gg
MS80XSB4ZW4vZ3JhbnR0YWJsZTogSW50cm9kdWNpbmcgZ3JhbnQgdGFibGUgVjIgc3R1Y3R1
cmUKClRoaXMgcGF0Y2ggaW50cm9kdWNlcyBuZXcgc3RydWN0dXJlcyBvZiBncmFudCB0YWJs
ZSBWMiwgZ3JhbnQgdGFibGUgVjIgaXMgYW4KZXh0ZW5zaW9uIGZyb20gVjEuIEdyYW50IHRh
YmxlIGlzIHNoYXJlZCBiZXR3ZWVuIGd1ZXN0IGFuZCBYZW4sIGFuZCBYZW4gaXMKcmVzcG9u
c2libGUgdG8gZG8gY29ycmVzcG9uZGluZyB3b3JrIGZvciBncmFudCBvcGVyYXRpb25zLCBz
dWNoIGFzOiBmaWd1cmUKb3V0IGd1ZXN0J3MgZ3JhbnQgdGFibGUgdmVyc2lvbiwgcGVyZm9y
bSBkaWZmZXJlbnQgYWN0aW9ucyBiYXNlZCBvbgpkaWZmZXJlbnQgZ3JhbnQgdGFibGUgdmVy
c2lvbiwgZXRjLiBBbHRob3VnaCBmdWxsLXBhZ2Ugc3RydWN0dXJlIG9mIFYyCmlzIGRpZmZl
cmVudCBmcm9tIFYxLCBpdCBwbGF5IHRoZSBzYW1lIHJvbGUgYXMgVjEuCgpTaWduZWQtb2Zm
LWJ5OiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4v
Z3JhbnQtdGFibGUuYyAgICAgICAgICB8ICAgIDcgKy0KIGRyaXZlcnMveGVuL2dyYW50LXRh
YmxlLmMgICAgICAgICAgIHwgIDE4MiArKysrKysrKysrKysrKysrKysrKysrKysrKystLS0t
LS0tLQogaW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUuaCAgICAgICAgICAgfCAgICA0ICstCiBp
bmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaCB8ICAxNjcgKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKy0KIGluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaCAgICAg
ICAgIHwgICAgMiArCiA1IGZpbGVzIGNoYW5nZWQsIDMxMSBpbnNlcnRpb25zKCspLCA1MSBk
ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYyBi
L2FyY2gveDg2L3hlbi9ncmFudC10YWJsZS5jCmluZGV4IDZiYmZkN2EuLmM2YWIyZTcgMTAw
NjQ0Ci0tLSBhL2FyY2gveDg2L3hlbi9ncmFudC10YWJsZS5jCisrKyBiL2FyY2gveDg2L3hl
bi9ncmFudC10YWJsZS5jCkBAIC02NCwxMCArNjQsMTAgQEAgc3RhdGljIGludCB1bm1hcF9w
dGVfZm4ocHRlX3QgKnB0ZSwgc3RydWN0IHBhZ2UgKnBtZF9wYWdlLAogCiBpbnQgYXJjaF9n
bnR0YWJfbWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGxvbmcg
bnJfZ2ZyYW1lcywKIAkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFtZXMsCi0JCQkg
ICBzdHJ1Y3QgZ3JhbnRfZW50cnkgKipfX3NoYXJlZCkKKwkJCSAgIHZvaWQgKipfX3NoYXJl
ZCkKIHsKIAlpbnQgcmM7Ci0Jc3RydWN0IGdyYW50X2VudHJ5ICpzaGFyZWQgPSAqX19zaGFy
ZWQ7CisJdm9pZCAqc2hhcmVkID0gKl9fc2hhcmVkOwogCiAJaWYgKHNoYXJlZCA9PSBOVUxM
KSB7CiAJCXN0cnVjdCB2bV9zdHJ1Y3QgKmFyZWEgPQpAQCAtODMsOCArODMsNyBAQCBpbnQg
YXJjaF9nbnR0YWJfbWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVk
IGxvbmcgbnJfZ2ZyYW1lcywKIAlyZXR1cm4gcmM7CiB9CiAKLXZvaWQgYXJjaF9nbnR0YWJf
dW5tYXBfc2hhcmVkKHN0cnVjdCBncmFudF9lbnRyeSAqc2hhcmVkLAotCQkJICAgICAgdW5z
aWduZWQgbG9uZyBucl9nZnJhbWVzKQordm9pZCBhcmNoX2dudHRhYl91bm1hcF9zaGFyZWQo
dm9pZCAqc2hhcmVkLCB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpCiB7CiAJYXBwbHlfdG9f
cGFnZV9yYW5nZSgmaW5pdF9tbSwgKHVuc2lnbmVkIGxvbmcpc2hhcmVkLAogCQkJICAgIFBB
R0VfU0laRSAqIG5yX2dmcmFtZXMsIHVubWFwX3B0ZV9mbiwgTlVMTCk7CmRpZmYgLS1naXQg
YS9kcml2ZXJzL3hlbi9ncmFudC10YWJsZS5jIGIvZHJpdmVycy94ZW4vZ3JhbnQtdGFibGUu
YwppbmRleCBiZjFjMDk0Li41ZDkzMWI4IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9ncmFu
dC10YWJsZS5jCisrKyBiL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMKQEAgLTUzLDcgKzUz
LDcgQEAKIC8qIEV4dGVybmFsIHRvb2xzIHJlc2VydmUgZmlyc3QgZmV3IGdyYW50IHRhYmxl
IGVudHJpZXMuICovCiAjZGVmaW5lIE5SX1JFU0VSVkVEX0VOVFJJRVMgOAogI2RlZmluZSBH
TlRUQUJfTElTVF9FTkQgMHhmZmZmZmZmZgotI2RlZmluZSBHUkVGU19QRVJfR1JBTlRfRlJB
TUUgKFBBR0VfU0laRSAvIHNpemVvZihzdHJ1Y3QgZ3JhbnRfZW50cnkpKQorI2RlZmluZSBH
UkVGU19QRVJfR1JBTlRfRlJBTUUgKFBBR0VfU0laRSAvIHNpemVvZihzdHJ1Y3QgZ3JhbnRf
ZW50cnlfdjEpKQogCiBzdGF0aWMgZ3JhbnRfcmVmX3QgKipnbnR0YWJfbGlzdDsKIHN0YXRp
YyB1bnNpZ25lZCBpbnQgbnJfZ3JhbnRfZnJhbWVzOwpAQCAtNjQsNyArNjQsNjQgQEAgc3Rh
dGljIERFRklORV9TUElOTE9DSyhnbnR0YWJfbGlzdF9sb2NrKTsKIHVuc2lnbmVkIGxvbmcg
eGVuX2h2bV9yZXN1bWVfZnJhbWVzOwogRVhQT1JUX1NZTUJPTF9HUEwoeGVuX2h2bV9yZXN1
bWVfZnJhbWVzKTsKIAotc3RhdGljIHN0cnVjdCBncmFudF9lbnRyeSAqc2hhcmVkOworc3Rh
dGljIHVuaW9uIHsKKwlzdHJ1Y3QgZ3JhbnRfZW50cnlfdjEgKnYxOworCXZvaWQgKmFkZHI7
Cit9IGdudHRhYl9zaGFyZWQ7CisKKy8qVGhpcyBpcyBhIHN0cnVjdHVyZSBvZiBmdW5jdGlv
biBwb2ludGVycyBmb3IgZ3JhbnQgdGFibGUqLworc3RydWN0IGdudHRhYl9vcHMgeworCS8q
CisJICogTWFwcGluZyBhIGxpc3Qgb2YgZnJhbWVzIGZvciBzdG9yaW5nIGdyYW50IGVudHJp
ZXMuIEZpcnN0IGlucHV0CisJICogcGFyYW1ldGVyIGlzIHVzZWQgdG8gc3RvcmluZyBncmFu
dCB0YWJsZSBhZGRyZXNzIHdoZW4gZ3JhbnQgdGFibGUKKwkgKiBiZWluZyBzZXR1cCwgc2Vj
b25kIHBhcmFtZXRlciBpcyB0aGUgbnVtYmVyIG9mIGZyYW1lcyB0byBtYXAgZ3JhbnQKKwkg
KiB0YWJsZS4gUmV0dXJuaW5nIEdOVFNUX29rYXkgbWVhbnMgc3VjY2VzcyBhbmQgbmVnYXRp
dmUgdmFsdWUgbWVhbnMKKwkgKiBmYWlsdXJlLgorCSAqLworCWludCAoKm1hcF9mcmFtZXMp
KHVuc2lnbmVkIGxvbmcgKiwgdW5zaWduZWQgaW50KTsKKwkvKgorCSAqIFJlbGVhc2UgYSBs
aXN0IG9mIGZyYW1lcyB3aGljaCBhcmUgbWFwcGVkIGluIG1hcF9mcmFtZXMgZm9yIGdyYW50
CisJICogZW50cnkgc3RhdHVzLgorCSAqLworCXZvaWQgKCp1bm1hcF9mcmFtZXMpKHZvaWQp
OworCS8qCisJICogSW50cm9kdWNpbmcgYSB2YWxpZCBlbnRyeSBpbnRvIHRoZSBncmFudCB0
YWJsZSwgZ3JhbnRpbmcgdGhlIGZyYW1lCisJICogb2YgdGhpcyBncmFudCBlbnRyeSB0byBk
b21haW4gZm9yIGFjY2Vzc2luZywgb3IgdHJhbnNmZXJpbmcsIG9yCisJICogdHJhbnNpdGl2
ZWx5IGFjY2Vzc2luZy4gRmlyc3QgaW5wdXQgcGFyYW1ldGVyIGlzIHJlZmVyZW5jZSBvZiB0
aGlzCisJICogaW50cm9kdWNlZCBncmFudCBlbnRyeSwgc2Vjb25kIG9uZSBpcyBkb21pZCBv
ZiBncmFudGVkIGRvbWFpbiwgdGhpcmQKKwkgKiBvbmUgaXMgdGhlIGZyYW1lIHRvIGJlIGdy
YW50ZWQsIGFuZCB0aGUgbGFzdCBvbmUgaXMgc3RhdHVzIG9mIHRoZQorCSAqIGdyYW50IGVu
dHJ5IHRvIGJlIHVwZGF0ZWQuCisJICovCisJdm9pZCAoKnVwZGF0ZV9lbnRyeSkoZ3JhbnRf
cmVmX3QsIGRvbWlkX3QsIHVuc2lnbmVkIGxvbmcsIHVuc2lnbmVkKTsKKwkvKgorCSAqIFN0
b3AgZ3JhbnRpbmcgYSBncmFudCBlbnRyeSB0byBkb21haW4gZm9yIGFjY2Vzc2luZy4gRmly
c3QgaW5wdXQKKwkgKiBwYXJhbWV0ZXIgaXMgcmVmZXJlbmNlIG9mIGEgZ3JhbnQgZW50cnkg
d2hvc2UgZ3JhbnQgYWNjZXNzIHdpbGwgYmUKKwkgKiBzdG9wcGVkLCBzZWNvbmQgb25lIGlz
IG5vdCBpbiB1c2Ugbm93LiBJZiB0aGUgZ3JhbnQgZW50cnkgaXMKKwkgKiBjdXJyZW50bHkg
bWFwcGVkIGZvciByZWFkaW5nIG9yIHdyaXRpbmcsIGp1c3QgcmV0dXJuIGZhaWx1cmUoPT0w
KQorCSAqIGRpcmVjdGx5IGFuZCBkb24ndCB0ZWFyIGRvd24gdGhlIGdyYW50IGFjY2Vzcy4g
T3RoZXJ3aXNlLCBzdG9wIGdyYW50CisJICogYWNjZXNzIGZvciB0aGlzIGVudHJ5IGFuZCBy
ZXR1cm4gc3VjY2Vzcyg9PTEpLgorCSAqLworCWludCAoKmVuZF9mb3JlaWduX2FjY2Vzc19y
ZWYpKGdyYW50X3JlZl90LCBpbnQpOworCS8qCisJICogU3RvcCBncmFudGluZyBhIGdyYW50
IGVudHJ5IHRvIGRvbWFpbiBmb3IgdHJhbnNmZXIuIElmIHRyYW5mZXIgaGFzCisJICogbm90
IHN0YXJ0ZWQsIGp1c3QgcmVjbGFpbSB0aGUgZ3JhbnQgZW50cnkgYW5kIHJldHVybiBmYWls
dXJlKD09MCkuCisJICogT3RoZXJ3aXNlLCB3YWl0IGZvciB0aGUgdHJhbnNmZXIgdG8gY29t
cGxldGUgYW5kIHRoZW4gcmV0dXJuIHRoZQorCSAqIGZyYW1lLgorCSAqLworCXVuc2lnbmVk
IGxvbmcgKCplbmRfZm9yZWlnbl90cmFuc2Zlcl9yZWYpKGdyYW50X3JlZl90KTsKKwkvKgor
CSAqIFF1ZXJ5IHRoZSBzdGF0dXMgb2YgYSBncmFudCBlbnRyeS4gSW5wdXQgcGFyYW1ldGVy
IGlzIHJlZmVyZW5jZSBvZgorCSAqIHF1ZXJpZWQgZ3JhbnQgZW50cnksIHJldHVybiB2YWx1
ZSBpcyB0aGUgc3RhdHVzIG9mIHF1ZXJpZWQgZW50cnkuCisJICogRGV0YWlsZWQgc3RhdHVz
KHdyaXRpbmcvcmVhZGluZykgY2FuIGJlIGdvdHRlbiBmcm9tIHRoZSByZXR1cm4gdmFsdWUK
KwkgKiBieSBiaXQgb3BlcmF0aW9ucy4KKwkgKi8KKwlpbnQgKCpxdWVyeV9mb3JlaWduX2Fj
Y2VzcykoZ3JhbnRfcmVmX3QpOworfTsKKworc3RhdGljIHN0cnVjdCBnbnR0YWJfb3BzIGdu
dHRhYl92MV9vcHM7CitzdGF0aWMgc3RydWN0IGdudHRhYl9vcHMgKmdudHRhYl9pbnRlcmZh
Y2U7CisKK3N0YXRpYyBpbnQgZ3JhbnRfdGFibGVfdmVyc2lvbjsKIAogc3RhdGljIHN0cnVj
dCBnbnR0YWJfZnJlZV9jYWxsYmFjayAqZ250dGFiX2ZyZWVfY2FsbGJhY2tfbGlzdDsKIApA
QCAtMTQyLDIzICsxOTksMjMgQEAgc3RhdGljIHZvaWQgcHV0X2ZyZWVfZW50cnkoZ3JhbnRf
cmVmX3QgcmVmKQogCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmdudHRhYl9saXN0X2xvY2ss
IGZsYWdzKTsKIH0KIAotc3RhdGljIHZvaWQgdXBkYXRlX2dyYW50X2VudHJ5KGdyYW50X3Jl
Zl90IHJlZiwgZG9taWRfdCBkb21pZCwKLQkJCSAgICAgICB1bnNpZ25lZCBsb25nIGZyYW1l
LCB1bnNpZ25lZCBmbGFncykKKy8qCisgKiBJbnRyb2R1Y2luZyBhIHZhbGlkIGVudHJ5IGlu
dG8gdGhlIGdyYW50IHRhYmxlOgorICogIDEuIFdyaXRlIGVudC0+ZG9taWQuCisgKiAgMi4g
V3JpdGUgZW50LT5mcmFtZToKKyAqICAgICAgR1RGX3Blcm1pdF9hY2Nlc3M6ICAgRnJhbWUg
dG8gd2hpY2ggYWNjZXNzIGlzIHBlcm1pdHRlZC4KKyAqICAgICAgR1RGX2FjY2VwdF90cmFu
c2ZlcjogUHNldWRvLXBoeXMgZnJhbWUgc2xvdCBiZWluZyBmaWxsZWQgYnkgbmV3CisgKiAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGZyYW1lLCBvciB6ZXJvIGlmIG5vbmUuCisgKiAg
My4gV3JpdGUgbWVtb3J5IGJhcnJpZXIgKFdNQikuCisgKiAgNC4gV3JpdGUgZW50LT5mbGFn
cywgaW5jLiB2YWxpZCB0eXBlLgorICovCitzdGF0aWMgdm9pZCB1cGRhdGVfZ3JhbnRfZW50
cnlfdjEoZ3JhbnRfcmVmX3QgcmVmLCBkb21pZF90IGRvbWlkLAorCQkJCSAgdW5zaWduZWQg
bG9uZyBmcmFtZSwgdW5zaWduZWQgZmxhZ3MpCiB7Ci0JLyoKLQkgKiBJbnRyb2R1Y2luZyBh
IHZhbGlkIGVudHJ5IGludG8gdGhlIGdyYW50IHRhYmxlOgotCSAqICAxLiBXcml0ZSBlbnQt
PmRvbWlkLgotCSAqICAyLiBXcml0ZSBlbnQtPmZyYW1lOgotCSAqICAgICAgR1RGX3Blcm1p
dF9hY2Nlc3M6ICAgRnJhbWUgdG8gd2hpY2ggYWNjZXNzIGlzIHBlcm1pdHRlZC4KLQkgKiAg
ICAgIEdURl9hY2NlcHRfdHJhbnNmZXI6IFBzZXVkby1waHlzIGZyYW1lIHNsb3QgYmVpbmcg
ZmlsbGVkIGJ5IG5ldwotCSAqICAgICAgICAgICAgICAgICAgICAgICAgICAgZnJhbWUsIG9y
IHplcm8gaWYgbm9uZS4KLQkgKiAgMy4gV3JpdGUgbWVtb3J5IGJhcnJpZXIgKFdNQikuCi0J
ICogIDQuIFdyaXRlIGVudC0+ZmxhZ3MsIGluYy4gdmFsaWQgdHlwZS4KLQkgKi8KLQlzaGFy
ZWRbcmVmXS5mcmFtZSA9IGZyYW1lOwotCXNoYXJlZFtyZWZdLmRvbWlkID0gZG9taWQ7CisJ
Z250dGFiX3NoYXJlZC52MVtyZWZdLmRvbWlkID0gZG9taWQ7CisJZ250dGFiX3NoYXJlZC52
MVtyZWZdLmZyYW1lID0gZnJhbWU7CiAJd21iKCk7Ci0Jc2hhcmVkW3JlZl0uZmxhZ3MgPSBm
bGFnczsKKwlnbnR0YWJfc2hhcmVkLnYxW3JlZl0uZmxhZ3MgPSBmbGFnczsKIH0KIAogLyoK
QEAgLTE2Nyw3ICsyMjQsNyBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfZ3JhbnRfZW50cnkoZ3Jh
bnRfcmVmX3QgcmVmLCBkb21pZF90IGRvbWlkLAogdm9pZCBnbnR0YWJfZ3JhbnRfZm9yZWln
bl9hY2Nlc3NfcmVmKGdyYW50X3JlZl90IHJlZiwgZG9taWRfdCBkb21pZCwKIAkJCQkgICAg
IHVuc2lnbmVkIGxvbmcgZnJhbWUsIGludCByZWFkb25seSkKIHsKLQl1cGRhdGVfZ3JhbnRf
ZW50cnkocmVmLCBkb21pZCwgZnJhbWUsCisJZ250dGFiX2ludGVyZmFjZS0+dXBkYXRlX2Vu
dHJ5KHJlZiwgZG9taWQsIGZyYW1lLAogCQkJICAgR1RGX3Blcm1pdF9hY2Nlc3MgfCAocmVh
ZG9ubHkgPyBHVEZfcmVhZG9ubHkgOiAwKSk7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0
YWJfZ3JhbnRfZm9yZWlnbl9hY2Nlc3NfcmVmKTsKQEAgLTE4NywzMSArMjQ0LDM3IEBAIGlu
dCBnbnR0YWJfZ3JhbnRfZm9yZWlnbl9hY2Nlc3MoZG9taWRfdCBkb21pZCwgdW5zaWduZWQg
bG9uZyBmcmFtZSwKIH0KIEVYUE9SVF9TWU1CT0xfR1BMKGdudHRhYl9ncmFudF9mb3JlaWdu
X2FjY2Vzcyk7CiAKLWludCBnbnR0YWJfcXVlcnlfZm9yZWlnbl9hY2Nlc3MoZ3JhbnRfcmVm
X3QgcmVmKQorc3RhdGljIGludCBnbnR0YWJfcXVlcnlfZm9yZWlnbl9hY2Nlc3NfdjEoZ3Jh
bnRfcmVmX3QgcmVmKQogewotCXUxNiBuZmxhZ3M7Ci0KLQluZmxhZ3MgPSBzaGFyZWRbcmVm
XS5mbGFnczsKKwlyZXR1cm4gZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzICYgKEdURl9y
ZWFkaW5nfEdURl93cml0aW5nKTsKK30KIAotCXJldHVybiBuZmxhZ3MgJiAoR1RGX3JlYWRp
bmd8R1RGX3dyaXRpbmcpOworaW50IGdudHRhYl9xdWVyeV9mb3JlaWduX2FjY2VzcyhncmFu
dF9yZWZfdCByZWYpCit7CisJcmV0dXJuIGdudHRhYl9pbnRlcmZhY2UtPnF1ZXJ5X2ZvcmVp
Z25fYWNjZXNzKHJlZik7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfcXVlcnlfZm9y
ZWlnbl9hY2Nlc3MpOwogCi1pbnQgZ250dGFiX2VuZF9mb3JlaWduX2FjY2Vzc19yZWYoZ3Jh
bnRfcmVmX3QgcmVmLCBpbnQgcmVhZG9ubHkpCitzdGF0aWMgaW50IGdudHRhYl9lbmRfZm9y
ZWlnbl9hY2Nlc3NfcmVmX3YxKGdyYW50X3JlZl90IHJlZiwgaW50IHJlYWRvbmx5KQogewog
CXUxNiBmbGFncywgbmZsYWdzOwogCi0JbmZsYWdzID0gc2hhcmVkW3JlZl0uZmxhZ3M7CisJ
bmZsYWdzID0gZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzOwogCWRvIHsKIAkJZmxhZ3Mg
PSBuZmxhZ3M7CiAJCWlmIChmbGFncyAmIChHVEZfcmVhZGluZ3xHVEZfd3JpdGluZykpIHsK
IAkJCXByaW50ayhLRVJOX0FMRVJUICJXQVJOSU5HOiBnLmUuIHN0aWxsIGluIHVzZSFcbiIp
OwogCQkJcmV0dXJuIDA7CiAJCX0KLQl9IHdoaWxlICgobmZsYWdzID0gc3luY19jbXB4Y2hn
KCZzaGFyZWRbcmVmXS5mbGFncywgZmxhZ3MsIDApKSAhPSBmbGFncyk7CisJfSB3aGlsZSAo
KG5mbGFncyA9IHN5bmNfY21weGNoZygmZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzLCBm
bGFncywgMCkpICE9IGZsYWdzKTsKIAogCXJldHVybiAxOwogfQorCitpbnQgZ250dGFiX2Vu
ZF9mb3JlaWduX2FjY2Vzc19yZWYoZ3JhbnRfcmVmX3QgcmVmLCBpbnQgcmVhZG9ubHkpCit7
CisJcmV0dXJuIGdudHRhYl9pbnRlcmZhY2UtPmVuZF9mb3JlaWduX2FjY2Vzc19yZWYocmVm
LCByZWFkb25seSk7Cit9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfZW5kX2ZvcmVpZ25f
YWNjZXNzX3JlZik7CiAKIHZvaWQgZ250dGFiX2VuZF9mb3JlaWduX2FjY2VzcyhncmFudF9y
ZWZfdCByZWYsIGludCByZWFkb25seSwKQEAgLTI0NiwxMSArMzA5LDExIEBAIEVYUE9SVF9T
WU1CT0xfR1BMKGdudHRhYl9ncmFudF9mb3JlaWduX3RyYW5zZmVyKTsKIHZvaWQgZ250dGFi
X2dyYW50X2ZvcmVpZ25fdHJhbnNmZXJfcmVmKGdyYW50X3JlZl90IHJlZiwgZG9taWRfdCBk
b21pZCwKIAkJCQkgICAgICAgdW5zaWduZWQgbG9uZyBwZm4pCiB7Ci0JdXBkYXRlX2dyYW50
X2VudHJ5KHJlZiwgZG9taWQsIHBmbiwgR1RGX2FjY2VwdF90cmFuc2Zlcik7CisJZ250dGFi
X2ludGVyZmFjZS0+dXBkYXRlX2VudHJ5KHJlZiwgZG9taWQsIHBmbiwgR1RGX2FjY2VwdF90
cmFuc2Zlcik7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfZ3JhbnRfZm9yZWlnbl90
cmFuc2Zlcl9yZWYpOwogCi11bnNpZ25lZCBsb25nIGdudHRhYl9lbmRfZm9yZWlnbl90cmFu
c2Zlcl9yZWYoZ3JhbnRfcmVmX3QgcmVmKQorc3RhdGljIHVuc2lnbmVkIGxvbmcgZ250dGFi
X2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZl92MShncmFudF9yZWZfdCByZWYpCiB7CiAJdW5z
aWduZWQgbG9uZyBmcmFtZTsKIAl1MTYgICAgICAgICAgIGZsYWdzOwpAQCAtMjU5LDI0ICsz
MjIsMjkgQEAgdW5zaWduZWQgbG9uZyBnbnR0YWJfZW5kX2ZvcmVpZ25fdHJhbnNmZXJfcmVm
KGdyYW50X3JlZl90IHJlZikKIAkgKiBJZiBhIHRyYW5zZmVyIGlzIG5vdCBldmVuIHlldCBz
dGFydGVkLCB0cnkgdG8gcmVjbGFpbSB0aGUgZ3JhbnQKIAkgKiByZWZlcmVuY2UgYW5kIHJl
dHVybiBmYWlsdXJlICg9PSAwKS4KIAkgKi8KLQl3aGlsZSAoISgoZmxhZ3MgPSBzaGFyZWRb
cmVmXS5mbGFncykgJiBHVEZfdHJhbnNmZXJfY29tbWl0dGVkKSkgewotCQlpZiAoc3luY19j
bXB4Y2hnKCZzaGFyZWRbcmVmXS5mbGFncywgZmxhZ3MsIDApID09IGZsYWdzKQorCXdoaWxl
ICghKChmbGFncyA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mbGFncykgJiBHVEZfdHJhbnNm
ZXJfY29tbWl0dGVkKSkgeworCQlpZiAoc3luY19jbXB4Y2hnKCZnbnR0YWJfc2hhcmVkLnYx
W3JlZl0uZmxhZ3MsIGZsYWdzLCAwKSA9PSBmbGFncykKIAkJCXJldHVybiAwOwogCQljcHVf
cmVsYXgoKTsKIAl9CiAKIAkvKiBJZiBhIHRyYW5zZmVyIGlzIGluIHByb2dyZXNzIHRoZW4g
d2FpdCB1bnRpbCBpdCBpcyBjb21wbGV0ZWQuICovCiAJd2hpbGUgKCEoZmxhZ3MgJiBHVEZf
dHJhbnNmZXJfY29tcGxldGVkKSkgewotCQlmbGFncyA9IHNoYXJlZFtyZWZdLmZsYWdzOwor
CQlmbGFncyA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mbGFnczsKIAkJY3B1X3JlbGF4KCk7
CiAJfQogCiAJcm1iKCk7CS8qIFJlYWQgdGhlIGZyYW1lIG51bWJlciAvYWZ0ZXIvIHJlYWRp
bmcgY29tcGxldGlvbiBzdGF0dXMuICovCi0JZnJhbWUgPSBzaGFyZWRbcmVmXS5mcmFtZTsK
KwlmcmFtZSA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mcmFtZTsKIAlCVUdfT04oZnJhbWUg
PT0gMCk7CiAKIAlyZXR1cm4gZnJhbWU7CiB9CisKK3Vuc2lnbmVkIGxvbmcgZ250dGFiX2Vu
ZF9mb3JlaWduX3RyYW5zZmVyX3JlZihncmFudF9yZWZfdCByZWYpCit7CisJcmV0dXJuIGdu
dHRhYl9pbnRlcmZhY2UtPmVuZF9mb3JlaWduX3RyYW5zZmVyX3JlZihyZWYpOworfQogRVhQ
T1JUX1NZTUJPTF9HUEwoZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZik7CiAKIHVu
c2lnbmVkIGxvbmcgZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyKGdyYW50X3JlZl90IHJl
ZikKQEAgLTUyMCw2ICs1ODgsMjMgQEAgaW50IGdudHRhYl91bm1hcF9yZWZzKHN0cnVjdCBn
bnR0YWJfdW5tYXBfZ3JhbnRfcmVmICp1bm1hcF9vcHMsCiB9CiBFWFBPUlRfU1lNQk9MX0dQ
TChnbnR0YWJfdW5tYXBfcmVmcyk7CiAKK3N0YXRpYyBpbnQgZ250dGFiX21hcF9mcmFtZXNf
djEodW5zaWduZWQgbG9uZyAqZnJhbWVzLCB1bnNpZ25lZCBpbnQgbnJfZ2ZyYW1lcykKK3sK
KwlpbnQgcmM7CisKKwlyYyA9IGFyY2hfZ250dGFiX21hcF9zaGFyZWQoZnJhbWVzLCBucl9n
ZnJhbWVzLAorCQkJCSAgICBnbnR0YWJfbWF4X2dyYW50X2ZyYW1lcygpLAorCQkJCSAgICAm
Z250dGFiX3NoYXJlZC5hZGRyKTsKKwlCVUdfT04ocmMpOworCisJcmV0dXJuIDA7Cit9CisK
K3N0YXRpYyB2b2lkIGdudHRhYl91bm1hcF9mcmFtZXNfdjEodm9pZCkKK3sKKwlhcmNoX2du
dHRhYl91bm1hcF9zaGFyZWQoZ250dGFiX3NoYXJlZC5hZGRyLCBucl9ncmFudF9mcmFtZXMp
OworfQorCiBzdGF0aWMgaW50IGdudHRhYl9tYXAodW5zaWduZWQgaW50IHN0YXJ0X2lkeCwg
dW5zaWduZWQgaW50IGVuZF9pZHgpCiB7CiAJc3RydWN0IGdudHRhYl9zZXR1cF90YWJsZSBz
ZXR1cDsKQEAgLTU2NywxOSArNjUyLDM1IEBAIHN0YXRpYyBpbnQgZ250dGFiX21hcCh1bnNp
Z25lZCBpbnQgc3RhcnRfaWR4LCB1bnNpZ25lZCBpbnQgZW5kX2lkeCkKIAogCUJVR19PTihy
YyB8fCBzZXR1cC5zdGF0dXMpOwogCi0JcmMgPSBhcmNoX2dudHRhYl9tYXBfc2hhcmVkKGZy
YW1lcywgbnJfZ2ZyYW1lcywgZ250dGFiX21heF9ncmFudF9mcmFtZXMoKSwKLQkJCQkgICAg
JnNoYXJlZCk7Ci0JQlVHX09OKHJjKTsKKwlyYyA9IGdudHRhYl9pbnRlcmZhY2UtPm1hcF9m
cmFtZXMoZnJhbWVzLCBucl9nZnJhbWVzKTsKIAogCWtmcmVlKGZyYW1lcyk7CiAKLQlyZXR1
cm4gMDsKKwlyZXR1cm4gcmM7Cit9CisKK3N0YXRpYyBzdHJ1Y3QgZ250dGFiX29wcyBnbnR0
YWJfdjFfb3BzID0geworCS5tYXBfZnJhbWVzCQkJPSBnbnR0YWJfbWFwX2ZyYW1lc192MSwK
KwkudW5tYXBfZnJhbWVzCQkJPSBnbnR0YWJfdW5tYXBfZnJhbWVzX3YxLAorCS51cGRhdGVf
ZW50cnkJCQk9IHVwZGF0ZV9ncmFudF9lbnRyeV92MSwKKwkuZW5kX2ZvcmVpZ25fYWNjZXNz
X3JlZgkJPSBnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzX3JlZl92MSwKKwkuZW5kX2ZvcmVp
Z25fdHJhbnNmZXJfcmVmCT0gZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZl92MSwK
KwkucXVlcnlfZm9yZWlnbl9hY2Nlc3MJCT0gZ250dGFiX3F1ZXJ5X2ZvcmVpZ25fYWNjZXNz
X3YxLAorfTsKKworc3RhdGljIHZvaWQgZ250dGFiX3JlcXVlc3RfdmVyc2lvbih2b2lkKQor
eworCWdyYW50X3RhYmxlX3ZlcnNpb24gPSAxOworCWdudHRhYl9pbnRlcmZhY2UgPSAmZ250
dGFiX3YxX29wczsKKwlwcmludGsoS0VSTl9JTkZPICJHcmFudCB0YWJsZXMgdXNpbmcgdmVy
c2lvbiAlZCBsYXlvdXQuXG4iLAorCQlncmFudF90YWJsZV92ZXJzaW9uKTsKIH0KIAogaW50
IGdudHRhYl9yZXN1bWUodm9pZCkKIHsKIAl1bnNpZ25lZCBpbnQgbWF4X25yX2dmcmFtZXM7
CiAKKwlnbnR0YWJfcmVxdWVzdF92ZXJzaW9uKCk7CiAJbWF4X25yX2dmcmFtZXMgPSBnbnR0
YWJfbWF4X2dyYW50X2ZyYW1lcygpOwogCWlmIChtYXhfbnJfZ2ZyYW1lcyA8IG5yX2dyYW50
X2ZyYW1lcykKIAkJcmV0dXJuIC1FTk9TWVM7CkBAIC01ODcsOSArNjg4LDEwIEBAIGludCBn
bnR0YWJfcmVzdW1lKHZvaWQpCiAJaWYgKHhlbl9wdl9kb21haW4oKSkKIAkJcmV0dXJuIGdu
dHRhYl9tYXAoMCwgbnJfZ3JhbnRfZnJhbWVzIC0gMSk7CiAKLQlpZiAoIXNoYXJlZCkgewot
CQlzaGFyZWQgPSBpb3JlbWFwKHhlbl9odm1fcmVzdW1lX2ZyYW1lcywgUEFHRV9TSVpFICog
bWF4X25yX2dmcmFtZXMpOwotCQlpZiAoc2hhcmVkID09IE5VTEwpIHsKKwlpZiAoZ250dGFi
X3NoYXJlZC5hZGRyID09IE5VTEwpIHsKKwkJZ250dGFiX3NoYXJlZC5hZGRyID0gaW9yZW1h
cCh4ZW5faHZtX3Jlc3VtZV9mcmFtZXMsCisJCQkJCQlQQUdFX1NJWkUgKiBtYXhfbnJfZ2Zy
YW1lcyk7CisJCWlmIChnbnR0YWJfc2hhcmVkLmFkZHIgPT0gTlVMTCkgewogCQkJcHJpbnRr
KEtFUk5fV0FSTklORwogCQkJCQkiRmFpbGVkIHRvIGlvcmVtYXAgZ250dGFiIHNoYXJlIGZy
YW1lcyEiKTsKIAkJCXJldHVybiAtRU5PTUVNOwpAQCAtNjAzLDcgKzcwNSw3IEBAIGludCBn
bnR0YWJfcmVzdW1lKHZvaWQpCiAKIGludCBnbnR0YWJfc3VzcGVuZCh2b2lkKQogewotCWFy
Y2hfZ250dGFiX3VubWFwX3NoYXJlZChzaGFyZWQsIG5yX2dyYW50X2ZyYW1lcyk7CisJZ250
dGFiX2ludGVyZmFjZS0+dW5tYXBfZnJhbWVzKCk7CiAJcmV0dXJuIDA7CiB9CiAKZGlmZiAt
LWdpdCBhL2luY2x1ZGUveGVuL2dyYW50X3RhYmxlLmggYi9pbmNsdWRlL3hlbi9ncmFudF90
YWJsZS5oCmluZGV4IDExZTJkZmMuLmM3YTQwZjggMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVu
L2dyYW50X3RhYmxlLmgKKysrIGIvaW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUuaApAQCAtMTQ1
LDggKzE0NSw4IEBAIGdudHRhYl9zZXRfdW5tYXBfb3Aoc3RydWN0IGdudHRhYl91bm1hcF9n
cmFudF9yZWYgKnVubWFwLCBwaHlzX2FkZHJfdCBhZGRyLAogCiBpbnQgYXJjaF9nbnR0YWJf
bWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGxvbmcgbnJfZ2Zy
YW1lcywKIAkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFtZXMsCi0JCQkgICBzdHJ1
Y3QgZ3JhbnRfZW50cnkgKipfX3NoYXJlZCk7Ci12b2lkIGFyY2hfZ250dGFiX3VubWFwX3No
YXJlZChzdHJ1Y3QgZ3JhbnRfZW50cnkgKnNoYXJlZCwKKwkJCSAgIHZvaWQgKipfX3NoYXJl
ZCk7Cit2b2lkIGFyY2hfZ250dGFiX3VubWFwX3NoYXJlZCh2b2lkICpzaGFyZWQsCiAJCQkg
ICAgICB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpOwogCiBleHRlcm4gdW5zaWduZWQgbG9u
ZyB4ZW5faHZtX3Jlc3VtZV9mcmFtZXM7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9pbnRl
cmZhY2UvZ3JhbnRfdGFibGUuaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFudF90YWJs
ZS5oCmluZGV4IDM5ZTU3MTcuLmExN2Q4NDQgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2lu
dGVyZmFjZS9ncmFudF90YWJsZS5oCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFu
dF90YWJsZS5oCkBAIC04NSwxMiArODUsMjIgQEAKICAqLwogCiAvKgorICogUmVmZXJlbmNl
IHRvIGEgZ3JhbnQgZW50cnkgaW4gYSBzcGVjaWZpZWQgZG9tYWluJ3MgZ3JhbnQgdGFibGUu
CisgKi8KK3R5cGVkZWYgdWludDMyX3QgZ3JhbnRfcmVmX3Q7CisKKy8qCiAgKiBBIGdyYW50
IHRhYmxlIGNvbXByaXNlcyBhIHBhY2tlZCBhcnJheSBvZiBncmFudCBlbnRyaWVzIGluIG9u
ZSBvciBtb3JlCiAgKiBwYWdlIGZyYW1lcyBzaGFyZWQgYmV0d2VlbiBYZW4gYW5kIGEgZ3Vl
c3QuCiAgKiBbWEVOXTogVGhpcyBmaWVsZCBpcyB3cml0dGVuIGJ5IFhlbiBhbmQgcmVhZCBi
eSB0aGUgc2hhcmluZyBndWVzdC4KICAqIFtHU1RdOiBUaGlzIGZpZWxkIGlzIHdyaXR0ZW4g
YnkgdGhlIGd1ZXN0IGFuZCByZWFkIGJ5IFhlbi4KICAqLwotc3RydWN0IGdyYW50X2VudHJ5
IHsKKworLyoKKyAqIFZlcnNpb24gMSBvZiB0aGUgZ3JhbnQgdGFibGUgZW50cnkgc3RydWN0
dXJlIGlzIG1haW50YWluZWQgcHVyZWx5CisgKiBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxp
dHkuICBOZXcgZ3Vlc3RzIHNob3VsZCB1c2UgdmVyc2lvbiAyLgorICovCitzdHJ1Y3QgZ3Jh
bnRfZW50cnlfdjEgewogICAgIC8qIEdURl94eHg6IHZhcmlvdXMgdHlwZSBhbmQgZmxhZyBp
bmZvcm1hdGlvbi4gIFtYRU4sR1NUXSAqLwogICAgIHVpbnQxNl90IGZsYWdzOwogICAgIC8q
IFRoZSBkb21haW4gYmVpbmcgZ3JhbnRlZCBmb3JlaWduIHByaXZpbGVnZXMuIFtHU1RdICov
CkBAIC0xMDgsMTAgKzExOCwxMyBAQCBzdHJ1Y3QgZ3JhbnRfZW50cnkgewogICogIEdURl9w
ZXJtaXRfYWNjZXNzOiBBbGxvdyBAZG9taWQgdG8gbWFwL2FjY2VzcyBAZnJhbWUuCiAgKiAg
R1RGX2FjY2VwdF90cmFuc2ZlcjogQWxsb3cgQGRvbWlkIHRvIHRyYW5zZmVyIG93bmVyc2hp
cCBvZiBvbmUgcGFnZSBmcmFtZQogICogICAgICAgICAgICAgICAgICAgICAgIHRvIHRoaXMg
Z3Vlc3QuIFhlbiB3cml0ZXMgdGhlIHBhZ2UgbnVtYmVyIHRvIEBmcmFtZS4KKyAqICBHVEZf
dHJhbnNpdGl2ZTogQWxsb3cgQGRvbWlkIHRvIHRyYW5zaXRpdmVseSBhY2Nlc3MgYSBzdWJy
YW5nZSBvZgorICogICAgICAgICAgICAgICAgICBAdHJhbnNfZ3JhbnQgaW4gQHRyYW5zX2Rv
bWlkLiAgTm8gbWFwcGluZ3MgYXJlIGFsbG93ZWQuCiAgKi8KICNkZWZpbmUgR1RGX2ludmFs
aWQgICAgICAgICAoMFU8PDApCiAjZGVmaW5lIEdURl9wZXJtaXRfYWNjZXNzICAgKDFVPDww
KQogI2RlZmluZSBHVEZfYWNjZXB0X3RyYW5zZmVyICgyVTw8MCkKKyNkZWZpbmUgR1RGX3Ry
YW5zaXRpdmUgICAgICAoM1U8PDApCiAjZGVmaW5lIEdURl90eXBlX21hc2sgICAgICAgKDNV
PDwwKQogCiAvKgpAQCAtMTE5LDYgKzEzMiw5IEBAIHN0cnVjdCBncmFudF9lbnRyeSB7CiAg
KiAgR1RGX3JlYWRvbmx5OiBSZXN0cmljdCBAZG9taWQgdG8gcmVhZC1vbmx5IG1hcHBpbmdz
IGFuZCBhY2Nlc3Nlcy4gW0dTVF0KICAqICBHVEZfcmVhZGluZzogR3JhbnQgZW50cnkgaXMg
Y3VycmVudGx5IG1hcHBlZCBmb3IgcmVhZGluZyBieSBAZG9taWQuIFtYRU5dCiAgKiAgR1RG
X3dyaXRpbmc6IEdyYW50IGVudHJ5IGlzIGN1cnJlbnRseSBtYXBwZWQgZm9yIHdyaXRpbmcg
YnkgQGRvbWlkLiBbWEVOXQorICogIEdURl9zdWJfcGFnZTogR3JhbnQgYWNjZXNzIHRvIG9u
bHkgYSBzdWJyYW5nZSBvZiB0aGUgcGFnZS4gIEBkb21pZAorICogICAgICAgICAgICAgICAg
d2lsbCBvbmx5IGJlIGFsbG93ZWQgdG8gY29weSBmcm9tIHRoZSBncmFudCwgYW5kIG5vdAor
ICogICAgICAgICAgICAgICAgbWFwIGl0LiBbR1NUXQogICovCiAjZGVmaW5lIF9HVEZfcmVh
ZG9ubHkgICAgICAgKDIpCiAjZGVmaW5lIEdURl9yZWFkb25seSAgICAgICAgKDFVPDxfR1RG
X3JlYWRvbmx5KQpAQCAtMTI2LDYgKzE0Miw4IEBAIHN0cnVjdCBncmFudF9lbnRyeSB7CiAj
ZGVmaW5lIEdURl9yZWFkaW5nICAgICAgICAgKDFVPDxfR1RGX3JlYWRpbmcpCiAjZGVmaW5l
IF9HVEZfd3JpdGluZyAgICAgICAgKDQpCiAjZGVmaW5lIEdURl93cml0aW5nICAgICAgICAg
KDFVPDxfR1RGX3dyaXRpbmcpCisjZGVmaW5lIF9HVEZfc3ViX3BhZ2UgICAgICAgKDgpCisj
ZGVmaW5lIEdURl9zdWJfcGFnZSAgICAgICAgKDFVPDxfR1RGX3N1Yl9wYWdlKQogCiAvKgog
ICogU3ViZmxhZ3MgZm9yIEdURl9hY2NlcHRfdHJhbnNmZXI6CkBAIC0xNDIsMTUgKzE2MCw4
MSBAQCBzdHJ1Y3QgZ3JhbnRfZW50cnkgewogI2RlZmluZSBfR1RGX3RyYW5zZmVyX2NvbXBs
ZXRlZCAoMykKICNkZWZpbmUgR1RGX3RyYW5zZmVyX2NvbXBsZXRlZCAgKDFVPDxfR1RGX3Ry
YW5zZmVyX2NvbXBsZXRlZCkKIAorLyoKKyAqIFZlcnNpb24gMiBncmFudCB0YWJsZSBlbnRy
aWVzLiAgVGhlc2UgZnVsZmlsIHRoZSBzYW1lIHJvbGUgYXMKKyAqIHZlcnNpb24gMSBlbnRy
aWVzLCBidXQgY2FuIHJlcHJlc2VudCBtb3JlIGNvbXBsaWNhdGVkIG9wZXJhdGlvbnMuCisg
KiBBbnkgZ2l2ZW4gZG9tYWluIHdpbGwgaGF2ZSBlaXRoZXIgYSB2ZXJzaW9uIDEgb3IgYSB2
ZXJzaW9uIDIgdGFibGUsCisgKiBhbmQgZXZlcnkgZW50cnkgaW4gdGhlIHRhYmxlIHdpbGwg
YmUgdGhlIHNhbWUgdmVyc2lvbi4KKyAqCisgKiBUaGUgaW50ZXJmYWNlIGJ5IHdoaWNoIGRv
bWFpbnMgdXNlIGdyYW50IHJlZmVyZW5jZXMgZG9lcyBub3QgZGVwZW5kCisgKiBvbiB0aGUg
Z3JhbnQgdGFibGUgdmVyc2lvbiBpbiB1c2UgYnkgdGhlIG90aGVyIGRvbWFpbi4KKyAqLwog
Ci0vKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKLSAqIEdSQU5UIFRBQkxF
IFFVRVJJRVMgQU5EIFVTRVMKKy8qCisgKiBWZXJzaW9uIDEgYW5kIHZlcnNpb24gMiBncmFu
dCBlbnRyaWVzIHNoYXJlIGEgY29tbW9uIHByZWZpeC4gIFRoZQorICogZmllbGRzIG9mIHRo
ZSBwcmVmaXggYXJlIGRvY3VtZW50ZWQgYXMgcGFydCBvZiBzdHJ1Y3QKKyAqIGdyYW50X2Vu
dHJ5X3YxLgogICovCitzdHJ1Y3QgZ3JhbnRfZW50cnlfaGVhZGVyIHsKKyAgICB1aW50MTZf
dCBmbGFnczsKKyAgICBkb21pZF90ICBkb21pZDsKK307CiAKIC8qCi0gKiBSZWZlcmVuY2Ug
dG8gYSBncmFudCBlbnRyeSBpbiBhIHNwZWNpZmllZCBkb21haW4ncyBncmFudCB0YWJsZS4K
KyAqIFZlcnNpb24gMiBvZiB0aGUgZ3JhbnQgZW50cnkgc3RydWN0dXJlLCBoZXJlIGlzIGFu
IHVuaW9uIGJlY2F1c2UgdGhyZWUKKyAqIGRpZmZlcmVudCB0eXBlcyBhcmUgc3VwcG90dGVk
OiBmdWxsX3BhZ2UsIHN1Yl9wYWdlIGFuZCB0cmFuc2l0aXZlLgorICovCit1bmlvbiBncmFu
dF9lbnRyeV92MiB7CisgICAgc3RydWN0IGdyYW50X2VudHJ5X2hlYWRlciBoZHI7CisKKyAg
ICAvKgorICAgICAqIFRoaXMgbWVtYmVyIGlzIHVzZWQgZm9yIFYxLXN0eWxlIGZ1bGwgcGFn
ZSBncmFudHMsIHdoZXJlIGVpdGhlcjoKKyAgICAgKgorICAgICAqIC0tIGhkci50eXBlIGlz
IEdURl9hY2NlcHRfdHJhbnNmZXIsIG9yCisgICAgICogLS0gaGRyLnR5cGUgaXMgR1RGX3Bl
cm1pdF9hY2Nlc3MgYW5kIEdURl9zdWJfcGFnZSBpcyBub3Qgc2V0LgorICAgICAqCisgICAg
ICogSW4gdGhhdCBjYXNlLCB0aGUgZnJhbWUgZmllbGQgaGFzIHRoZSBzYW1lIHNlbWFudGlj
cyBhcyB0aGUKKyAgICAgKiBmaWVsZCBvZiB0aGUgc2FtZSBuYW1lIGluIHRoZSBWMSBlbnRy
eSBzdHJ1Y3R1cmUuCisgICAgICovCisgICAgc3RydWN0IHsKKwlzdHJ1Y3QgZ3JhbnRfZW50
cnlfaGVhZGVyIGhkcjsKKwl1aW50MzJfdCBwYWQwOworCXVpbnQ2NF90IGZyYW1lOworICAg
IH0gZnVsbF9wYWdlOworCisgICAgLyoKKyAgICAgKiBJZiB0aGUgZ3JhbnQgdHlwZSBpcyBH
VEZfZ3JhbnRfYWNjZXNzIGFuZCBHVEZfc3ViX3BhZ2UgaXMgc2V0LAorICAgICAqIEBkb21p
ZCBpcyBhbGxvd2VkIHRvIGFjY2VzcyBieXRlcyBbQHBhZ2Vfb2ZmLEBwYWdlX29mZitAbGVu
Z3RoKQorICAgICAqIGluIGZyYW1lIEBmcmFtZS4KKyAgICAgKi8KKyAgICBzdHJ1Y3Qgewor
CXN0cnVjdCBncmFudF9lbnRyeV9oZWFkZXIgaGRyOworCXVpbnQxNl90IHBhZ2Vfb2ZmOwor
CXVpbnQxNl90IGxlbmd0aDsKKwl1aW50NjRfdCBmcmFtZTsKKyAgICB9IHN1Yl9wYWdlOwor
CisgICAgLyoKKyAgICAgKiBJZiB0aGUgZ3JhbnQgaXMgR1RGX3RyYW5zaXRpdmUsIEBkb21p
ZCBpcyBhbGxvd2VkIHRvIHVzZSB0aGUKKyAgICAgKiBncmFudCBAZ3JlZiBpbiBkb21haW4g
QHRyYW5zX2RvbWlkLCBhcyBpZiBpdCB3YXMgdGhlIGxvY2FsCisgICAgICogZG9tYWluLiAg
T2J2aW91c2x5LCB0aGUgdHJhbnNpdGl2ZSBhY2Nlc3MgbXVzdCBiZSBjb21wYXRpYmxlCisg
ICAgICogd2l0aCB0aGUgb3JpZ2luYWwgZ3JhbnQuCisgICAgICovCisgICAgc3RydWN0IHsK
KwlzdHJ1Y3QgZ3JhbnRfZW50cnlfaGVhZGVyIGhkcjsKKwlkb21pZF90IHRyYW5zX2RvbWlk
OworCXVpbnQxNl90IHBhZDA7CisJZ3JhbnRfcmVmX3QgZ3JlZjsKKyAgICB9IHRyYW5zaXRp
dmU7CisKKyAgICB1aW50MzJfdCBfX3NwYWNlcls0XTsgLyogUGFkIHRvIGEgcG93ZXIgb2Yg
dHdvICovCit9OworCit0eXBlZGVmIHVpbnQxNl90IGdyYW50X3N0YXR1c190OworCisvKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKyAqIEdSQU5UIFRBQkxFIFFVRVJJ
RVMgQU5EIFVTRVMKICAqLwotdHlwZWRlZiB1aW50MzJfdCBncmFudF9yZWZfdDsKIAogLyoK
ICAqIEhhbmRsZSB0byB0cmFjayBhIG1hcHBpbmcgY3JlYXRlZCB2aWEgYSBncmFudCByZWZl
cmVuY2UuCkBAIC0zMjIsNiArNDA2LDc5IEBAIHN0cnVjdCBnbnR0YWJfcXVlcnlfc2l6ZSB7
CiBERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVChnbnR0YWJfcXVlcnlfc2l6ZSk7CiAKIC8q
CisgKiBHTlRUQUJPUF91bm1hcF9hbmRfcmVwbGFjZTogRGVzdHJveSBvbmUgb3IgbW9yZSBn
cmFudC1yZWZlcmVuY2UgbWFwcGluZ3MKKyAqIHRyYWNrZWQgYnkgPGhhbmRsZT4gYnV0IGF0
b21pY2FsbHkgcmVwbGFjZSB0aGUgcGFnZSB0YWJsZSBlbnRyeSB3aXRoIG9uZQorICogcG9p
bnRpbmcgdG8gdGhlIG1hY2hpbmUgYWRkcmVzcyB1bmRlciA8bmV3X2FkZHI+LiAgPG5ld19h
ZGRyPiB3aWxsIGJlCisgKiByZWRpcmVjdGVkIHRvIHRoZSBudWxsIGVudHJ5LgorICogTk9U
RVM6CisgKiAgMS4gVGhlIGNhbGwgbWF5IGZhaWwgaW4gYW4gdW5kZWZpbmVkIG1hbm5lciBp
ZiBlaXRoZXIgbWFwcGluZyBpcyBub3QKKyAqICAgICB0cmFja2VkIGJ5IDxoYW5kbGU+Lgor
ICogIDIuIEFmdGVyIGV4ZWN1dGluZyBhIGJhdGNoIG9mIHVubWFwcywgaXQgaXMgZ3VhcmFu
dGVlZCB0aGF0IG5vIHN0YWxlCisgKiAgICAgbWFwcGluZ3Mgd2lsbCByZW1haW4gaW4gdGhl
IGRldmljZSBvciBob3N0IFRMQnMuCisgKi8KKyNkZWZpbmUgR05UVEFCT1BfdW5tYXBfYW5k
X3JlcGxhY2UgICAgNworc3RydWN0IGdudHRhYl91bm1hcF9hbmRfcmVwbGFjZSB7CisgICAg
LyogSU4gcGFyYW1ldGVycy4gKi8KKyAgICB1aW50NjRfdCBob3N0X2FkZHI7CisgICAgdWlu
dDY0X3QgbmV3X2FkZHI7CisgICAgZ3JhbnRfaGFuZGxlX3QgaGFuZGxlOworICAgIC8qIE9V
VCBwYXJhbWV0ZXJzLiAqLworICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAgICAgIC8q
IEdOVFNUXyogKi8KK307CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVChnbnR0YWJfdW5t
YXBfYW5kX3JlcGxhY2UpOworCisvKgorICogR05UVEFCT1Bfc2V0X3ZlcnNpb246IFJlcXVl
c3QgYSBwYXJ0aWN1bGFyIHZlcnNpb24gb2YgdGhlIGdyYW50CisgKiB0YWJsZSBzaGFyZWQg
dGFibGUgc3RydWN0dXJlLiAgVGhpcyBvcGVyYXRpb24gY2FuIG9ubHkgYmUgcGVyZm9ybWVk
CisgKiBvbmNlIGluIGFueSBnaXZlbiBkb21haW4uICBJdCBtdXN0IGJlIHBlcmZvcm1lZCBi
ZWZvcmUgYW55IGdyYW50cworICogYXJlIGFjdGl2YXRlZDsgb3RoZXJ3aXNlLCB0aGUgZG9t
YWluIHdpbGwgYmUgc3R1Y2sgd2l0aCB2ZXJzaW9uIDEuCisgKiBUaGUgb25seSBkZWZpbmVk
IHZlcnNpb25zIGFyZSAxIGFuZCAyLgorICovCisjZGVmaW5lIEdOVFRBQk9QX3NldF92ZXJz
aW9uICAgICAgICAgIDgKK3N0cnVjdCBnbnR0YWJfc2V0X3ZlcnNpb24geworICAgIC8qIElO
IHBhcmFtZXRlcnMgKi8KKyAgICB1aW50MzJfdCB2ZXJzaW9uOworfTsKK0RFRklORV9HVUVT
VF9IQU5ETEVfU1RSVUNUKGdudHRhYl9zZXRfdmVyc2lvbik7CisKKy8qCisgKiBHTlRUQUJP
UF9nZXRfc3RhdHVzX2ZyYW1lczogR2V0IHRoZSBsaXN0IG9mIGZyYW1lcyB1c2VkIHRvIHN0
b3JlIGdyYW50CisgKiBzdGF0dXMgZm9yIDxkb20+LiBJbiBncmFudCBmb3JtYXQgdmVyc2lv
biAyLCB0aGUgc3RhdHVzIGlzIHNlcGFyYXRlZAorICogZnJvbSB0aGUgb3RoZXIgc2hhcmVk
IGdyYW50IGZpZWxkcyB0byBhbGxvdyBtb3JlIGVmZmljaWVudCBzeW5jaHJvbml6YXRpb24K
KyAqIHVzaW5nIGJhcnJpZXJzIGluc3RlYWQgb2YgYXRvbWljIGNtcGV4Y2ggb3BlcmF0aW9u
cy4KKyAqIDxucl9mcmFtZXM+IHNwZWNpZnkgdGhlIHNpemUgb2YgdmVjdG9yIDxmcmFtZV9s
aXN0Pi4KKyAqIFRoZSBmcmFtZSBhZGRyZXNzZXMgYXJlIHJldHVybmVkIGluIHRoZSA8ZnJh
bWVfbGlzdD4uCisgKiBPbmx5IDxucl9mcmFtZXM+IGFkZHJlc3NlcyBhcmUgcmV0dXJuZWQs
IGV2ZW4gaWYgdGhlIHRhYmxlIGlzIGxhcmdlci4KKyAqIE5PVEVTOgorICogIDEuIDxkb20+
IG1heSBiZSBzcGVjaWZpZWQgYXMgRE9NSURfU0VMRi4KKyAqICAyLiBPbmx5IGEgc3VmZmlj
aWVudGx5LXByaXZpbGVnZWQgZG9tYWluIG1heSBzcGVjaWZ5IDxkb20+ICE9IERPTUlEX1NF
TEYuCisgKi8KKyNkZWZpbmUgR05UVEFCT1BfZ2V0X3N0YXR1c19mcmFtZXMgICAgIDkKK3N0
cnVjdCBnbnR0YWJfZ2V0X3N0YXR1c19mcmFtZXMgeworICAgIC8qIElOIHBhcmFtZXRlcnMu
ICovCisgICAgdWludDMyX3QgbnJfZnJhbWVzOworICAgIGRvbWlkX3QgIGRvbTsKKyAgICAv
KiBPVVQgcGFyYW1ldGVycy4gKi8KKyAgICBpbnQxNl90ICBzdGF0dXM7ICAgICAgICAgICAg
ICAvKiBHTlRTVF8qICovCisgICAgR1VFU1RfSEFORExFKHVpbnQ2NF90KSBmcmFtZV9saXN0
OworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKGdudHRhYl9nZXRfc3RhdHVzX2Zy
YW1lcyk7CisKKy8qCisgKiBHTlRUQUJPUF9nZXRfdmVyc2lvbjogR2V0IHRoZSBncmFudCB0
YWJsZSB2ZXJzaW9uIHdoaWNoIGlzIGluCisgKiBlZmZlY3QgZm9yIGRvbWFpbiA8ZG9tPi4K
KyAqLworI2RlZmluZSBHTlRUQUJPUF9nZXRfdmVyc2lvbiAgICAgICAgICAxMAorc3RydWN0
IGdudHRhYl9nZXRfdmVyc2lvbiB7CisgICAgLyogSU4gcGFyYW1ldGVycyAqLworICAgIGRv
bWlkX3QgZG9tOworICAgIHVpbnQxNl90IHBhZDsKKyAgICAvKiBPVVQgcGFyYW1ldGVycyAq
LworICAgIHVpbnQzMl90IHZlcnNpb247Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJV
Q1QoZ250dGFiX2dldF92ZXJzaW9uKTsKKworLyoKICAqIEJpdGZpZWxkIHZhbHVlcyBmb3Ig
dXBkYXRlX3Bpbl9zdGF0dXMuZmxhZ3MuCiAgKi8KICAvKiBNYXAgdGhlIGdyYW50IGVudHJ5
IGZvciBhY2Nlc3MgYnkgSS9PIGRldmljZXMuICovCmRpZmYgLS1naXQgYS9pbmNsdWRlL3hl
bi9pbnRlcmZhY2UveGVuLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLmgKaW5kZXgg
NmE2ZTkxNC4uYTg5MDgwNCAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hl
bi5oCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaApAQCAtNTIzLDYgKzUyMyw4
IEBAIHN0cnVjdCB0bWVtX29wIHsKIAl9IHU7CiB9OwogCitERUZJTkVfR1VFU1RfSEFORExF
KHU2NCk7CisKICNlbHNlIC8qIF9fQVNTRU1CTFlfXyAqLwogCiAvKiBJbiBhc3NlbWJseSBj
b2RlIHdlIGNhbm5vdCB1c2UgQyBudW1lcmljIGNvbnN0YW50IHN1ZmZpeGVzLiAqLwotLSAK
MS43LjYuNAoK
--------------060201000507000106030009
Content-Type: text/plain; name="0002-xen-granttable-Refactor-some-code.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0002-xen-granttable-Refactor-some-code.patch"

RnJvbSAzMjc4MDZjYjNlNzg3M2IzZWZmMjI5ZjM3YzRjMTc3MTdjNDAyYzllIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4K
RGF0ZTogRnJpLCAxOCBOb3YgMjAxMSAxNjozMjo1NiArMDgwMApTdWJqZWN0OiBbUEFUQ0gg
Mi80XSB4ZW4vZ3JhbnR0YWJsZTogUmVmYWN0b3Igc29tZSBjb2RlCgpTaWduZWQtb2ZmLWJ5
OiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4KLS0tCiBkcml2ZXJzL3hlbi9ncmFu
dC10YWJsZS5jIHwgICAxNSArKysrKysrKysrLS0tLS0KIDEgZmlsZXMgY2hhbmdlZCwgMTAg
aW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hl
bi9ncmFudC10YWJsZS5jIGIvZHJpdmVycy94ZW4vZ3JhbnQtdGFibGUuYwppbmRleCA1ZDkz
MWI4Li5mMzMwNDFlIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9ncmFudC10YWJsZS5jCisr
KyBiL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMKQEAgLTI1OCwxNSArMjU4LDE3IEBAIEVY
UE9SVF9TWU1CT0xfR1BMKGdudHRhYl9xdWVyeV9mb3JlaWduX2FjY2Vzcyk7CiBzdGF0aWMg
aW50IGdudHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3NfcmVmX3YxKGdyYW50X3JlZl90IHJlZiwg
aW50IHJlYWRvbmx5KQogewogCXUxNiBmbGFncywgbmZsYWdzOworCXUxNiAqcGZsYWdzOwog
Ci0JbmZsYWdzID0gZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzOworCXBmbGFncyA9ICZn
bnR0YWJfc2hhcmVkLnYxW3JlZl0uZmxhZ3M7CisJbmZsYWdzID0gKnBmbGFnczsKIAlkbyB7
CiAJCWZsYWdzID0gbmZsYWdzOwogCQlpZiAoZmxhZ3MgJiAoR1RGX3JlYWRpbmd8R1RGX3dy
aXRpbmcpKSB7CiAJCQlwcmludGsoS0VSTl9BTEVSVCAiV0FSTklORzogZy5lLiBzdGlsbCBp
biB1c2UhXG4iKTsKIAkJCXJldHVybiAwOwogCQl9Ci0JfSB3aGlsZSAoKG5mbGFncyA9IHN5
bmNfY21weGNoZygmZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzLCBmbGFncywgMCkpICE9
IGZsYWdzKTsKKwl9IHdoaWxlICgobmZsYWdzID0gc3luY19jbXB4Y2hnKHBmbGFncywgZmxh
Z3MsIDApKSAhPSBmbGFncyk7CiAKIAlyZXR1cm4gMTsKIH0KQEAgLTMxNywyMCArMzE5LDIz
IEBAIHN0YXRpYyB1bnNpZ25lZCBsb25nIGdudHRhYl9lbmRfZm9yZWlnbl90cmFuc2Zlcl9y
ZWZfdjEoZ3JhbnRfcmVmX3QgcmVmKQogewogCXVuc2lnbmVkIGxvbmcgZnJhbWU7CiAJdTE2
ICAgICAgICAgICBmbGFnczsKKwl1MTYgICAgICAgICAgKnBmbGFnczsKKworCXBmbGFncyA9
ICZnbnR0YWJfc2hhcmVkLnYxW3JlZl0uZmxhZ3M7CiAKIAkvKgogCSAqIElmIGEgdHJhbnNm
ZXIgaXMgbm90IGV2ZW4geWV0IHN0YXJ0ZWQsIHRyeSB0byByZWNsYWltIHRoZSBncmFudAog
CSAqIHJlZmVyZW5jZSBhbmQgcmV0dXJuIGZhaWx1cmUgKD09IDApLgogCSAqLwotCXdoaWxl
ICghKChmbGFncyA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mbGFncykgJiBHVEZfdHJhbnNm
ZXJfY29tbWl0dGVkKSkgewotCQlpZiAoc3luY19jbXB4Y2hnKCZnbnR0YWJfc2hhcmVkLnYx
W3JlZl0uZmxhZ3MsIGZsYWdzLCAwKSA9PSBmbGFncykKKwl3aGlsZSAoISgoZmxhZ3MgPSAq
cGZsYWdzKSAmIEdURl90cmFuc2Zlcl9jb21taXR0ZWQpKSB7CisJCWlmIChzeW5jX2NtcHhj
aGcocGZsYWdzLCBmbGFncywgMCkgPT0gZmxhZ3MpCiAJCQlyZXR1cm4gMDsKIAkJY3B1X3Jl
bGF4KCk7CiAJfQogCiAJLyogSWYgYSB0cmFuc2ZlciBpcyBpbiBwcm9ncmVzcyB0aGVuIHdh
aXQgdW50aWwgaXQgaXMgY29tcGxldGVkLiAqLwogCXdoaWxlICghKGZsYWdzICYgR1RGX3Ry
YW5zZmVyX2NvbXBsZXRlZCkpIHsKLQkJZmxhZ3MgPSBnbnR0YWJfc2hhcmVkLnYxW3JlZl0u
ZmxhZ3M7CisJCWZsYWdzID0gKnBmbGFnczsKIAkJY3B1X3JlbGF4KCk7CiAJfQogCi0tIAox
LjcuNi40Cgo=
--------------060201000507000106030009
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------060201000507000106030009--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:14:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:14:44 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLT2-0003GA-5w
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLSg-00057N-9I; Fri, 18 Nov 2011 02:14:22 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLSV-00056A-If
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:14:12 -0800
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321611246!4049192!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25862 invoked from network); 18 Nov 2011 10:14:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 10:14:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIAE3DM029570
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 10:14:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIAE32p012551
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 10:14:03 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIADvA8020680; Fri, 18 Nov 2011 04:13:57 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 02:13:56 -0800
Message-ID: <4EC62FE5.2080608@oracle.com>
Date: Fri, 18 Nov 2011 18:13:57 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1321451372-13596-1-git-send-email-annie.li@oracle.com>
Content-Type: multipart/mixed; boundary="------------080805070607050504050807"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EC62FEC.0137,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] Re: [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------080805070607050504050807
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Defining a function pointer structure gnttab_v2_ops, the changes 
correspond to those in [PATCH 1/3] xen/granttable: Introducing grant 
table V2 stucture.

Thanks
Annie

--------------080805070607050504050807
Content-Type: text/plain;
	name="0003-xen-granttable-Grant-tables-V2-implementation.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0003-xen-granttable-Grant-tables-V2-implementation.patch"

RnJvbSBmYTUwOWY0YTNhODBmZGI4YTYwNGVmZTZkNjhkOWRjOGNlMjU1MTFiIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4K
RGF0ZTogRnJpLCAxOCBOb3YgMjAxMSAxNjo1MzozNyArMDgwMApTdWJqZWN0OiBbUEFUQ0gg
My80XSB4ZW4vZ3JhbnR0YWJsZTogR3JhbnQgdGFibGVzIFYyIGltcGxlbWVudGF0aW9uCgpS
ZWNlaXZlci1zaWRlIGNvcHlpbmcgb2YgcGFja2V0cyBpcyBiYXNlZCBvbiB0aGlzIGltcGxl
bWVudGF0aW9uLCBpdCBnaXZlcwpiZXR0ZXIgcGVyZm9ybWFuY2UgYW5kIGJldHRlciBDUFUg
YWNjb3VudGluZy4gSXQgdG90YWxseSBzdXBwb3J0cyB0aHJlZSB0eXBlczoKZnVsbC1wYWdl
LCBzdWItcGFnZSBhbmQgdHJhbnNpdGl2ZSBncmFudHMuCgpIb3dldmVyIHRoaXMgcGF0Y2gg
ZG9lcyBub3QgY292ZXIgc3ViLXBhZ2UgYW5kIHRyYW5zaXRpdmUgZ3JhbnRzLCBpdCBtYWlu
bHkKZm9jdXMgb24gRnVsbC1wYWdlIHBhcnQgYW5kIGltcGxlbWVudHMgZ3JhbnQgdGFibGUg
VjIgaW50ZXJmYWNlcyBjb3JyZXNwb25kaW5nCnRvIHdoYXQgYWxyZWFkeSBleGlzdHMgaW4g
Z3JhbnQgdGFibGUgVjEsIHN1Y2ggYXM6IGdyYW50IHRhYmxlIFYyCmluaXRpYWxpemF0aW9u
LCBtYXBwaW5nLCByZWxlYXNpbmcgYW5kIGV4cG9ydGVkIGludGVyZmFjZXMuCgpFYWNoIGd1
ZXN0IGNhbiBvbmx5IHN1cHBvcnRzIG9uZSB0eXBlIG9mIGdyYW50IHRhYmxlIHR5cGUsIGV2
ZXJ5IGVudHJ5IGluIGdyYW50CnRhYmxlIHNob3VsZCBiZSB0aGUgc2FtZSB2ZXJzaW9uLiBJ
dCBpcyBuZWNlc3NhcnkgdG8gc2V0IFYxIG9yIFYyIHZlcnNpb24gYmVmb3JlCmluaXRpYWxp
emluZyB0aGUgZ3JhbnQgdGFibGUuCgpHcmFudCB0YWJsZSBleHBvcnRlZCBpbnRlcmZhY2Vz
IG9mIFYyIGFyZSBzYW1lIHdpdGggdGhvc2Ugb2YgVjEsIFhlbiBpcwpyZXNwb25zaWJsZSB0
byBqdWRnZSB3aGF0IGdyYW50IHRhYmxlIHZlcnNpb24gZ3Vlc3RzIGFyZSB1c2luZyBpbiBl
dmVyeSBncmFudApvcGVyYXRpb24uCgpWMiBmdWxmaWxscyB0aGUgc2FtZSByb2xlIG9mIFYx
LCBhbmQgaXQgaXMgdG90YWxseSBiYWNrd2FyZHMgY29tcGl0YWJsZSB3aXRoIFYxLgpJZiBk
b20wIHN1cHBvcnQgZ3JhbnQgdGFibGUgVjIsIHRoZSBndWVzdHMgcnVuaW5nIG9uIGl0IGNh
biBydW4gd2l0aCBlaXRoZXIgVjEKb3IgVjIuCgpTaWduZWQtb2ZmLWJ5OiBBbm5pZSBMaSA8
YW5uaWUubGlAb3JhY2xlLmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYyB8
ICAgMzcgKysrKysrKysrLQogZHJpdmVycy94ZW4vZ3JhbnQtdGFibGUuYyAgfCAgMTc1ICsr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCiBpbmNsdWRlL3hl
bi9ncmFudF90YWJsZS5oICB8ICAgIDYgKy0KIDMgZmlsZXMgY2hhbmdlZCwgMjExIGluc2Vy
dGlvbnMoKyksIDcgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvYXJjaC94ODYveGVuL2dy
YW50LXRhYmxlLmMgYi9hcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYwppbmRleCBjNmFiMmU3
Li41MTBmY2EwIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYworKysg
Yi9hcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYwpAQCAtNTQsNiArNTQsMjAgQEAgc3RhdGlj
IGludCBtYXBfcHRlX2ZuKHB0ZV90ICpwdGUsIHN0cnVjdCBwYWdlICpwbWRfcGFnZSwKIAly
ZXR1cm4gMDsKIH0KIAorLyoKKyAqIFRoaXMgZnVuY3Rpb24gaXMgdXNlZCB0byBtYXAgc2hh
cmVkIGZyYW1lcyB0byBzdG9yZSBncmFudCBzdGF0dXMuIEl0IGlzCisgKiBkaWZmZXJlbnQg
ZnJvbSBtYXBfcHRlX2ZuIGFib3ZlLCB0aGUgZnJhbWVzIHR5cGUgaGVyZSBpcyB1aW50NjRf
dC4KKyAqLworc3RhdGljIGludCBtYXBfcHRlX2ZuX3N0YXR1cyhwdGVfdCAqcHRlLCBzdHJ1
Y3QgcGFnZSAqcG1kX3BhZ2UsCisJCQkgICAgIHVuc2lnbmVkIGxvbmcgYWRkciwgdm9pZCAq
ZGF0YSkKK3sKKwl1aW50NjRfdCAqKmZyYW1lcyA9ICh1aW50NjRfdCAqKilkYXRhOworCisJ
c2V0X3B0ZV9hdCgmaW5pdF9tbSwgYWRkciwgcHRlLCBtZm5fcHRlKCgqZnJhbWVzKVswXSwg
UEFHRV9LRVJORUwpKTsKKwkoKmZyYW1lcykrKzsKKwlyZXR1cm4gMDsKK30KKwogc3RhdGlj
IGludCB1bm1hcF9wdGVfZm4ocHRlX3QgKnB0ZSwgc3RydWN0IHBhZ2UgKnBtZF9wYWdlLAog
CQkJdW5zaWduZWQgbG9uZyBhZGRyLCB2b2lkICpkYXRhKQogewpAQCAtODMsNyArOTcsMjgg
QEAgaW50IGFyY2hfZ250dGFiX21hcF9zaGFyZWQodW5zaWduZWQgbG9uZyAqZnJhbWVzLCB1
bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMsCiAJcmV0dXJuIHJjOwogfQogCi12b2lkIGFyY2hf
Z250dGFiX3VubWFwX3NoYXJlZCh2b2lkICpzaGFyZWQsIHVuc2lnbmVkIGxvbmcgbnJfZ2Zy
YW1lcykKK2ludCBhcmNoX2dudHRhYl9tYXBfc3RhdHVzKHVpbnQ2NF90ICpmcmFtZXMsIHVu
c2lnbmVkIGxvbmcgbnJfZ2ZyYW1lcywKKwkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dm
cmFtZXMsCisJCQkgICBncmFudF9zdGF0dXNfdCAqKl9fc2hhcmVkKQoreworCWludCByYzsK
KwlncmFudF9zdGF0dXNfdCAqc2hhcmVkID0gKl9fc2hhcmVkOworCisJaWYgKHNoYXJlZCA9
PSBOVUxMKSB7CisJCXN0cnVjdCB2bV9zdHJ1Y3QgKmFyZWEgPQorCQkJYWxsb2Nfdm1fYXJl
YShQQUdFX1NJWkUgKiBtYXhfbnJfZ2ZyYW1lcyk7CisJCUJVR19PTihhcmVhID09IE5VTEwp
OworCQlzaGFyZWQgPSBhcmVhLT5hZGRyOworCQkqX19zaGFyZWQgPSBzaGFyZWQ7CisJfQor
CisJcmMgPSBhcHBseV90b19wYWdlX3JhbmdlKCZpbml0X21tLCAodW5zaWduZWQgbG9uZylz
aGFyZWQsCisJCQkJIFBBR0VfU0laRSAqIG5yX2dmcmFtZXMsCisJCQkJIG1hcF9wdGVfZm5f
c3RhdHVzLCAmZnJhbWVzKTsKKwlyZXR1cm4gcmM7Cit9CisKK3ZvaWQgYXJjaF9nbnR0YWJf
dW5tYXAodm9pZCAqc2hhcmVkLCB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpCiB7CiAJYXBw
bHlfdG9fcGFnZV9yYW5nZSgmaW5pdF9tbSwgKHVuc2lnbmVkIGxvbmcpc2hhcmVkLAogCQkJ
ICAgIFBBR0VfU0laRSAqIG5yX2dmcmFtZXMsIHVubWFwX3B0ZV9mbiwgTlVMTCk7CmRpZmYg
LS1naXQgYS9kcml2ZXJzL3hlbi9ncmFudC10YWJsZS5jIGIvZHJpdmVycy94ZW4vZ3JhbnQt
dGFibGUuYwppbmRleCBmMzMwNDFlLi5jYTA3NWU5IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hl
bi9ncmFudC10YWJsZS5jCisrKyBiL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMKQEAgLTQ0
LDYgKzQ0LDcgQEAKICNpbmNsdWRlIDx4ZW4vcGFnZS5oPgogI2luY2x1ZGUgPHhlbi9ncmFu
dF90YWJsZS5oPgogI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvbWVtb3J5Lmg+CisjaW5jbHVk
ZSA8eGVuL2h2Yy1jb25zb2xlLmg+CiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4K
IAogI2luY2x1ZGUgPGFzbS9wZ3RhYmxlLmg+CkBAIC01Myw3ICs1NCwxMCBAQAogLyogRXh0
ZXJuYWwgdG9vbHMgcmVzZXJ2ZSBmaXJzdCBmZXcgZ3JhbnQgdGFibGUgZW50cmllcy4gKi8K
ICNkZWZpbmUgTlJfUkVTRVJWRURfRU5UUklFUyA4CiAjZGVmaW5lIEdOVFRBQl9MSVNUX0VO
RCAweGZmZmZmZmZmCi0jZGVmaW5lIEdSRUZTX1BFUl9HUkFOVF9GUkFNRSAoUEFHRV9TSVpF
IC8gc2l6ZW9mKHN0cnVjdCBncmFudF9lbnRyeV92MSkpCisjZGVmaW5lIEdSRUZTX1BFUl9H
UkFOVF9GUkFNRSBcCisoZ3JhbnRfdGFibGVfdmVyc2lvbiA9PSAxID8gICAgICAgICAgICAg
ICAgICAgICAgXAorIChQQUdFX1NJWkUgLyBzaXplb2Yoc3RydWN0IGdyYW50X2VudHJ5X3Yx
KSkgOiAgIFwKKyAoUEFHRV9TSVpFIC8gc2l6ZW9mKHVuaW9uIGdyYW50X2VudHJ5X3YyKSkp
CiAKIHN0YXRpYyBncmFudF9yZWZfdCAqKmdudHRhYl9saXN0Owogc3RhdGljIHVuc2lnbmVk
IGludCBucl9ncmFudF9mcmFtZXM7CkBAIC02Niw2ICs3MCw3IEBAIEVYUE9SVF9TWU1CT0xf
R1BMKHhlbl9odm1fcmVzdW1lX2ZyYW1lcyk7CiAKIHN0YXRpYyB1bmlvbiB7CiAJc3RydWN0
IGdyYW50X2VudHJ5X3YxICp2MTsKKwl1bmlvbiBncmFudF9lbnRyeV92MiAqdjI7CiAJdm9p
ZCAqYWRkcjsKIH0gZ250dGFiX3NoYXJlZDsKIApAQCAtMTE5LDggKzEyNCwxMiBAQCBzdHJ1
Y3QgZ250dGFiX29wcyB7CiB9OwogCiBzdGF0aWMgc3RydWN0IGdudHRhYl9vcHMgZ250dGFi
X3YxX29wczsKK3N0YXRpYyBzdHJ1Y3QgZ250dGFiX29wcyBnbnR0YWJfdjJfb3BzOwogc3Rh
dGljIHN0cnVjdCBnbnR0YWJfb3BzICpnbnR0YWJfaW50ZXJmYWNlOwogCisvKlRoaXMgcmVm
bGVjdHMgc3RhdHVzIG9mIGdyYW50IGVudHJpZXMsIHNvIGFjdCBhcyBhIGdsb2JhbCB2YWx1
ZSovCitzdGF0aWMgZ3JhbnRfc3RhdHVzX3QgKmdyc3RhdHVzOworCiBzdGF0aWMgaW50IGdy
YW50X3RhYmxlX3ZlcnNpb247CiAKIHN0YXRpYyBzdHJ1Y3QgZ250dGFiX2ZyZWVfY2FsbGJh
Y2sgKmdudHRhYl9mcmVlX2NhbGxiYWNrX2xpc3Q7CkBAIC0xMjgsNiArMTM3LDcgQEAgc3Rh
dGljIHN0cnVjdCBnbnR0YWJfZnJlZV9jYWxsYmFjayAqZ250dGFiX2ZyZWVfY2FsbGJhY2tf
bGlzdDsKIHN0YXRpYyBpbnQgZ250dGFiX2V4cGFuZCh1bnNpZ25lZCBpbnQgcmVxX2VudHJp
ZXMpOwogCiAjZGVmaW5lIFJQUCAoUEFHRV9TSVpFIC8gc2l6ZW9mKGdyYW50X3JlZl90KSkK
KyNkZWZpbmUgU1BQIChQQUdFX1NJWkUgLyBzaXplb2YoZ3JhbnRfc3RhdHVzX3QpKQogCiBz
dGF0aWMgaW5saW5lIGdyYW50X3JlZl90ICpfX2dudHRhYl9lbnRyeShncmFudF9yZWZfdCBl
bnRyeSkKIHsKQEAgLTIwMCw2ICsyMTAsNyBAQCBzdGF0aWMgdm9pZCBwdXRfZnJlZV9lbnRy
eShncmFudF9yZWZfdCByZWYpCiB9CiAKIC8qCisgKiBGb2xsb3dpbmcgY29tbWVudHMgYXBw
bHkgdG8gdXBkYXRlX2dyYW50X2VudHJ5X3YxIGFuZCB1cGRhdGVfZ3JhbnRfZW50cnlfdjIu
CiAgKiBJbnRyb2R1Y2luZyBhIHZhbGlkIGVudHJ5IGludG8gdGhlIGdyYW50IHRhYmxlOgog
ICogIDEuIFdyaXRlIGVudC0+ZG9taWQuCiAgKiAgMi4gV3JpdGUgZW50LT5mcmFtZToKQEAg
LTIxOCw2ICsyMjksMTUgQEAgc3RhdGljIHZvaWQgdXBkYXRlX2dyYW50X2VudHJ5X3YxKGdy
YW50X3JlZl90IHJlZiwgZG9taWRfdCBkb21pZCwKIAlnbnR0YWJfc2hhcmVkLnYxW3JlZl0u
ZmxhZ3MgPSBmbGFnczsKIH0KIAorc3RhdGljIHZvaWQgdXBkYXRlX2dyYW50X2VudHJ5X3Yy
KGdyYW50X3JlZl90IHJlZiwgZG9taWRfdCBkb21pZCwKKwkJCQkgIHVuc2lnbmVkIGxvbmcg
ZnJhbWUsIHVuc2lnbmVkIGZsYWdzKQoreworCWdudHRhYl9zaGFyZWQudjJbcmVmXS5oZHIu
ZG9taWQgPSBkb21pZDsKKwlnbnR0YWJfc2hhcmVkLnYyW3JlZl0uZnVsbF9wYWdlLmZyYW1l
ID0gZnJhbWU7CisJd21iKCk7CisJZ250dGFiX3NoYXJlZC52MltyZWZdLmhkci5mbGFncyA9
IEdURl9wZXJtaXRfYWNjZXNzIHwgZmxhZ3M7Cit9CisKIC8qCiAgKiBQdWJsaWMgZ3JhbnQt
aXNzdWluZyBpbnRlcmZhY2UgZnVuY3Rpb25zCiAgKi8KQEAgLTI0OSw2ICsyNjksMTEgQEAg
c3RhdGljIGludCBnbnR0YWJfcXVlcnlfZm9yZWlnbl9hY2Nlc3NfdjEoZ3JhbnRfcmVmX3Qg
cmVmKQogCXJldHVybiBnbnR0YWJfc2hhcmVkLnYxW3JlZl0uZmxhZ3MgJiAoR1RGX3JlYWRp
bmd8R1RGX3dyaXRpbmcpOwogfQogCitzdGF0aWMgaW50IGdudHRhYl9xdWVyeV9mb3JlaWdu
X2FjY2Vzc192MihncmFudF9yZWZfdCByZWYpCit7CisJcmV0dXJuIGdyc3RhdHVzW3JlZl0g
JiAoR1RGX3JlYWRpbmd8R1RGX3dyaXRpbmcpOworfQorCiBpbnQgZ250dGFiX3F1ZXJ5X2Zv
cmVpZ25fYWNjZXNzKGdyYW50X3JlZl90IHJlZikKIHsKIAlyZXR1cm4gZ250dGFiX2ludGVy
ZmFjZS0+cXVlcnlfZm9yZWlnbl9hY2Nlc3MocmVmKTsKQEAgLTI3Myw2ICsyOTgsMjkgQEAg
c3RhdGljIGludCBnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzX3JlZl92MShncmFudF9yZWZf
dCByZWYsIGludCByZWFkb25seSkKIAlyZXR1cm4gMTsKIH0KIAorc3RhdGljIGludCBnbnR0
YWJfZW5kX2ZvcmVpZ25fYWNjZXNzX3JlZl92MihncmFudF9yZWZfdCByZWYsIGludCByZWFk
b25seSkKK3sKKwlnbnR0YWJfc2hhcmVkLnYyW3JlZl0uaGRyLmZsYWdzID0gMDsKKwltYigp
OworCWlmIChncnN0YXR1c1tyZWZdICYgKEdURl9yZWFkaW5nfEdURl93cml0aW5nKSkgewor
CQlyZXR1cm4gMDsKKwl9IGVsc2UgeworCQkvKiBUaGUgcmVhZCBvZiBncnN0YXR1cyBuZWVk
cyB0byBoYXZlIGFjcXVpcmUKKwkJc2VtYW50aWNzLiAgT24geDg2LCByZWFkcyBhbHJlYWR5
IGhhdmUKKwkJdGhhdCwgYW5kIHdlIGp1c3QgbmVlZCB0byBwcm90ZWN0IGFnYWluc3QKKwkJ
Y29tcGlsZXIgcmVvcmRlcmluZ3MuICBPbiBvdGhlcgorCQlhcmNoaXRlY3R1cmVzIHdlIG1h
eSBuZWVkIGEgZnVsbAorCQliYXJyaWVyLiAqLworI2lmZGVmIENPTkZJR19YODYKKwkJYmFy
cmllcigpOworI2Vsc2UKKwkJbWIoKTsKKyNlbmRpZgorCQl9CisKKwlyZXR1cm4gMTsKK30K
KwogaW50IGdudHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3NfcmVmKGdyYW50X3JlZl90IHJlZiwg
aW50IHJlYWRvbmx5KQogewogCXJldHVybiBnbnR0YWJfaW50ZXJmYWNlLT5lbmRfZm9yZWln
bl9hY2Nlc3NfcmVmKHJlZiwgcmVhZG9ubHkpOwpAQCAtMzQ2LDYgKzM5NCwzNyBAQCBzdGF0
aWMgdW5zaWduZWQgbG9uZyBnbnR0YWJfZW5kX2ZvcmVpZ25fdHJhbnNmZXJfcmVmX3YxKGdy
YW50X3JlZl90IHJlZikKIAlyZXR1cm4gZnJhbWU7CiB9CiAKK3N0YXRpYyB1bnNpZ25lZCBs
b25nIGdudHRhYl9lbmRfZm9yZWlnbl90cmFuc2Zlcl9yZWZfdjIoZ3JhbnRfcmVmX3QgcmVm
KQoreworCXVuc2lnbmVkIGxvbmcgZnJhbWU7CisJdTE2ICAgICAgICAgICBmbGFnczsKKwl1
MTYgICAgICAgICAgKnBmbGFnczsKKworCXBmbGFncyA9ICZnbnR0YWJfc2hhcmVkLnYyW3Jl
Zl0uaGRyLmZsYWdzOworCisJLyoKKwkgKiBJZiBhIHRyYW5zZmVyIGlzIG5vdCBldmVuIHll
dCBzdGFydGVkLCB0cnkgdG8gcmVjbGFpbSB0aGUgZ3JhbnQKKwkgKiByZWZlcmVuY2UgYW5k
IHJldHVybiBmYWlsdXJlICg9PSAwKS4KKwkgKi8KKwl3aGlsZSAoISgoZmxhZ3MgPSAqcGZs
YWdzKSAmIEdURl90cmFuc2Zlcl9jb21taXR0ZWQpKSB7CisJCWlmIChzeW5jX2NtcHhjaGco
cGZsYWdzLCBmbGFncywgMCkgPT0gZmxhZ3MpCisJCQlyZXR1cm4gMDsKKwkJY3B1X3JlbGF4
KCk7CisJfQorCisJLyogSWYgYSB0cmFuc2ZlciBpcyBpbiBwcm9ncmVzcyB0aGVuIHdhaXQg
dW50aWwgaXQgaXMgY29tcGxldGVkLiAqLworCXdoaWxlICghKGZsYWdzICYgR1RGX3RyYW5z
ZmVyX2NvbXBsZXRlZCkpIHsKKwkJZmxhZ3MgPSAqcGZsYWdzOworCQljcHVfcmVsYXgoKTsK
Kwl9CisKKwlybWIoKTsgIC8qIFJlYWQgdGhlIGZyYW1lIG51bWJlciAvYWZ0ZXIvIHJlYWRp
bmcgY29tcGxldGlvbiBzdGF0dXMuICovCisJZnJhbWUgPSBnbnR0YWJfc2hhcmVkLnYyW3Jl
Zl0uZnVsbF9wYWdlLmZyYW1lOworCUJVR19PTihmcmFtZSA9PSAwKTsKKworCXJldHVybiBm
cmFtZTsKK30KKwogdW5zaWduZWQgbG9uZyBnbnR0YWJfZW5kX2ZvcmVpZ25fdHJhbnNmZXJf
cmVmKGdyYW50X3JlZl90IHJlZikKIHsKIAlyZXR1cm4gZ250dGFiX2ludGVyZmFjZS0+ZW5k
X2ZvcmVpZ25fdHJhbnNmZXJfcmVmKHJlZik7CkBAIC01OTMsNiArNjcyLDExIEBAIGludCBn
bnR0YWJfdW5tYXBfcmVmcyhzdHJ1Y3QgZ250dGFiX3VubWFwX2dyYW50X3JlZiAqdW5tYXBf
b3BzLAogfQogRVhQT1JUX1NZTUJPTF9HUEwoZ250dGFiX3VubWFwX3JlZnMpOwogCitzdGF0
aWMgdW5zaWduZWQgbnJfc3RhdHVzX2ZyYW1lcyh1bnNpZ25lZCBucl9ncmFudF9mcmFtZXMp
Cit7CisJcmV0dXJuIChucl9ncmFudF9mcmFtZXMgKiBHUkVGU19QRVJfR1JBTlRfRlJBTUUg
KyBTUFAgLSAxKSAvIFNQUDsKK30KKwogc3RhdGljIGludCBnbnR0YWJfbWFwX2ZyYW1lc192
MSh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGludCBucl9nZnJhbWVzKQogewog
CWludCByYzsKQEAgLTYwNyw3ICs2OTEsNTYgQEAgc3RhdGljIGludCBnbnR0YWJfbWFwX2Zy
YW1lc192MSh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGludCBucl9nZnJhbWVz
KQogCiBzdGF0aWMgdm9pZCBnbnR0YWJfdW5tYXBfZnJhbWVzX3YxKHZvaWQpCiB7Ci0JYXJj
aF9nbnR0YWJfdW5tYXBfc2hhcmVkKGdudHRhYl9zaGFyZWQuYWRkciwgbnJfZ3JhbnRfZnJh
bWVzKTsKKwlhcmNoX2dudHRhYl91bm1hcChnbnR0YWJfc2hhcmVkLmFkZHIsIG5yX2dyYW50
X2ZyYW1lcyk7Cit9CisKK3N0YXRpYyBpbnQgZ250dGFiX21hcF9mcmFtZXNfdjIodW5zaWdu
ZWQgbG9uZyAqZnJhbWVzLCB1bnNpZ25lZCBpbnQgbnJfZ2ZyYW1lcykKK3sKKwl1aW50NjRf
dCAqc2ZyYW1lczsKKwl1bnNpZ25lZCBpbnQgbnJfc2ZyYW1lczsKKwlzdHJ1Y3QgZ250dGFi
X2dldF9zdGF0dXNfZnJhbWVzIGdldGZyYW1lczsKKwlpbnQgcmM7CisKKwlucl9zZnJhbWVz
ID0gbnJfc3RhdHVzX2ZyYW1lcyhucl9nZnJhbWVzKTsKKworCS8qIE5vIG5lZWQgZm9yIGt6
YWxsb2MgYXMgaXQgaXMgaW5pdGlhbGl6ZWQgaW4gZm9sbG93aW5nIGh5cGVyY2FsbAorCSAq
IEdOVFRBQk9QX2dldF9zdGF0dXNfZnJhbWVzLgorCSAqLworCXNmcmFtZXMgPSBrbWFsbG9j
KG5yX3NmcmFtZXMgICogc2l6ZW9mKHVpbnQ2NF90KSwgR0ZQX0FUT01JQyk7CisJaWYgKCFz
ZnJhbWVzKQorCQlyZXR1cm4gLUVOT01FTTsKKworCWdldGZyYW1lcy5kb20gICAgICAgID0g
RE9NSURfU0VMRjsKKwlnZXRmcmFtZXMubnJfZnJhbWVzICA9IG5yX3NmcmFtZXM7CisJc2V0
X3hlbl9ndWVzdF9oYW5kbGUoZ2V0ZnJhbWVzLmZyYW1lX2xpc3QsIHNmcmFtZXMpOworCisJ
cmMgPSBIWVBFUlZJU09SX2dyYW50X3RhYmxlX29wKEdOVFRBQk9QX2dldF9zdGF0dXNfZnJh
bWVzLAorCQkJCSAgICAgICAmZ2V0ZnJhbWVzLCAxKTsKKwlpZiAocmMgPT0gLUVOT1NZUykg
eworCQlrZnJlZShzZnJhbWVzKTsKKwkJcmV0dXJuIC1FTk9TWVM7CisJfQorCisJQlVHX09O
KHJjIHx8IGdldGZyYW1lcy5zdGF0dXMpOworCisJcmMgPSBhcmNoX2dudHRhYl9tYXBfc3Rh
dHVzKHNmcmFtZXMsIG5yX3NmcmFtZXMsCisJCQkJICAgIG5yX3N0YXR1c19mcmFtZXMoZ250
dGFiX21heF9ncmFudF9mcmFtZXMoKSksCisJCQkJICAgICZncnN0YXR1cyk7CisJQlVHX09O
KHJjKTsKKwlrZnJlZShzZnJhbWVzKTsKKworCXJjID0gYXJjaF9nbnR0YWJfbWFwX3NoYXJl
ZChmcmFtZXMsIG5yX2dmcmFtZXMsCisJCQkJICAgIGdudHRhYl9tYXhfZ3JhbnRfZnJhbWVz
KCksCisJCQkJICAgICZnbnR0YWJfc2hhcmVkLmFkZHIpOworCUJVR19PTihyYyk7CisKKwly
ZXR1cm4gMDsKK30KKworc3RhdGljIHZvaWQgZ250dGFiX3VubWFwX2ZyYW1lc192Mih2b2lk
KQoreworCWFyY2hfZ250dGFiX3VubWFwKGdudHRhYl9zaGFyZWQuYWRkciwgbnJfZ3JhbnRf
ZnJhbWVzKTsKKwlhcmNoX2dudHRhYl91bm1hcChncnN0YXR1cywgbnJfc3RhdHVzX2ZyYW1l
cyhucl9ncmFudF9mcmFtZXMpKTsKIH0KIAogc3RhdGljIGludCBnbnR0YWJfbWFwKHVuc2ln
bmVkIGludCBzdGFydF9pZHgsIHVuc2lnbmVkIGludCBlbmRfaWR4KQpAQCAtNjQxLDYgKzc3
NCw5IEBAIHN0YXRpYyBpbnQgZ250dGFiX21hcCh1bnNpZ25lZCBpbnQgc3RhcnRfaWR4LCB1
bnNpZ25lZCBpbnQgZW5kX2lkeCkKIAkJcmV0dXJuIHJjOwogCX0KIAorCS8qIE5vIG5lZWQg
Zm9yIGt6YWxsb2MgYXMgaXQgaXMgaW5pdGlhbGl6ZWQgaW4gZm9sbG93aW5nIGh5cGVyY2Fs
bAorCSAqIEdOVFRBQk9QX3NldHVwX3RhYmxlLgorCSAqLwogCWZyYW1lcyA9IGttYWxsb2Mo
bnJfZ2ZyYW1lcyAqIHNpemVvZih1bnNpZ25lZCBsb25nKSwgR0ZQX0FUT01JQyk7CiAJaWYg
KCFmcmFtZXMpCiAJCXJldHVybiAtRU5PTUVNOwpAQCAtNjczLDEwICs4MDksNDEgQEAgc3Rh
dGljIHN0cnVjdCBnbnR0YWJfb3BzIGdudHRhYl92MV9vcHMgPSB7CiAJLnF1ZXJ5X2ZvcmVp
Z25fYWNjZXNzCQk9IGdudHRhYl9xdWVyeV9mb3JlaWduX2FjY2Vzc192MSwKIH07CiAKK3N0
YXRpYyBzdHJ1Y3QgZ250dGFiX29wcyBnbnR0YWJfdjJfb3BzID0geworCS5tYXBfZnJhbWVz
CQkJPSBnbnR0YWJfbWFwX2ZyYW1lc192MiwKKwkudW5tYXBfZnJhbWVzCQkJPSBnbnR0YWJf
dW5tYXBfZnJhbWVzX3YyLAorCS51cGRhdGVfZW50cnkJCQk9IHVwZGF0ZV9ncmFudF9lbnRy
eV92MiwKKwkuZW5kX2ZvcmVpZ25fYWNjZXNzX3JlZgkJPSBnbnR0YWJfZW5kX2ZvcmVpZ25f
YWNjZXNzX3JlZl92MiwKKwkuZW5kX2ZvcmVpZ25fdHJhbnNmZXJfcmVmCT0gZ250dGFiX2Vu
ZF9mb3JlaWduX3RyYW5zZmVyX3JlZl92MiwKKwkucXVlcnlfZm9yZWlnbl9hY2Nlc3MJCT0g
Z250dGFiX3F1ZXJ5X2ZvcmVpZ25fYWNjZXNzX3YyLAorfTsKKwogc3RhdGljIHZvaWQgZ250
dGFiX3JlcXVlc3RfdmVyc2lvbih2b2lkKQogewotCWdyYW50X3RhYmxlX3ZlcnNpb24gPSAx
OwotCWdudHRhYl9pbnRlcmZhY2UgPSAmZ250dGFiX3YxX29wczsKKwlpbnQgcmM7CisJc3Ry
dWN0IGdudHRhYl9zZXRfdmVyc2lvbiBnc3Y7CisJY29uc3QgY2hhciAqc3RyID0gIndlIG5l
ZWQgZ3JhbnQgdGFibGVzIHZlcnNpb24gMiwgYnV0IG9ubHkgdmVyc2lvbiAxIGlzIGF2YWls
YWJsZVxuIjsKKworCWdzdi52ZXJzaW9uID0gMjsKKwlyYyA9IEhZUEVSVklTT1JfZ3JhbnRf
dGFibGVfb3AoR05UVEFCT1Bfc2V0X3ZlcnNpb24sICZnc3YsIDEpOworCWlmIChyYyA9PSAw
KSB7CisJCWdyYW50X3RhYmxlX3ZlcnNpb24gPSAyOworCQlnbnR0YWJfaW50ZXJmYWNlID0g
JmdudHRhYl92Ml9vcHM7CisJfSBlbHNlIHsKKwkJaWYgKGdyYW50X3RhYmxlX3ZlcnNpb24g
PT0gMikgeworCQkJLyoKKwkJCSAqIElmIHdlJ3ZlIGFscmVhZHkgdXNlZCB2ZXJzaW9uIDIg
ZmVhdHVyZXMsCisJCQkgKiBidXQgdGhlbiBzdWRkZW5seSBkaXNjb3ZlciB0aGF0IHRoZXkn
cmUgbm90CisJCQkgKiBhdmFpbGFibGUgKGUuZy4gbWlncmF0aW5nIHRvIGFuIG9sZGVyCisJ
CQkgKiB2ZXJzaW9uIG9mIFhlbiksIGFsbW9zdCB1bmJvdW5kZWQgYmFkbmVzcworCQkJICog
Y2FuIGhhcHBlbi4KKwkJCSAqLworCQkJeGVuX3Jhd19wcmludGsoc3RyKTsKKwkJCXBhbmlj
KHN0cik7CisJCX0KKwkJZ3JhbnRfdGFibGVfdmVyc2lvbiA9IDE7CisJCWdudHRhYl9pbnRl
cmZhY2UgPSAmZ250dGFiX3YxX29wczsKKwl9CiAJcHJpbnRrKEtFUk5fSU5GTyAiR3JhbnQg
dGFibGVzIHVzaW5nIHZlcnNpb24gJWQgbGF5b3V0LlxuIiwKIAkJZ3JhbnRfdGFibGVfdmVy
c2lvbik7CiB9CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9ncmFudF90YWJsZS5oIGIvaW5j
bHVkZS94ZW4vZ3JhbnRfdGFibGUuaAppbmRleCBjN2E0MGY4Li41NDk0YzQwIDEwMDY0NAot
LS0gYS9pbmNsdWRlL3hlbi9ncmFudF90YWJsZS5oCisrKyBiL2luY2x1ZGUveGVuL2dyYW50
X3RhYmxlLmgKQEAgLTE0Niw4ICsxNDYsMTAgQEAgZ250dGFiX3NldF91bm1hcF9vcChzdHJ1
Y3QgZ250dGFiX3VubWFwX2dyYW50X3JlZiAqdW5tYXAsIHBoeXNfYWRkcl90IGFkZHIsCiBp
bnQgYXJjaF9nbnR0YWJfbWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2ln
bmVkIGxvbmcgbnJfZ2ZyYW1lcywKIAkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFt
ZXMsCiAJCQkgICB2b2lkICoqX19zaGFyZWQpOwotdm9pZCBhcmNoX2dudHRhYl91bm1hcF9z
aGFyZWQodm9pZCAqc2hhcmVkLAotCQkJICAgICAgdW5zaWduZWQgbG9uZyBucl9nZnJhbWVz
KTsKK2ludCBhcmNoX2dudHRhYl9tYXBfc3RhdHVzKHVpbnQ2NF90ICpmcmFtZXMsIHVuc2ln
bmVkIGxvbmcgbnJfZ2ZyYW1lcywKKwkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFt
ZXMsCisJCQkgICBncmFudF9zdGF0dXNfdCAqKl9fc2hhcmVkKTsKK3ZvaWQgYXJjaF9nbnR0
YWJfdW5tYXAodm9pZCAqc2hhcmVkLCB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpOwogCiBl
eHRlcm4gdW5zaWduZWQgbG9uZyB4ZW5faHZtX3Jlc3VtZV9mcmFtZXM7CiB1bnNpZ25lZCBp
bnQgZ250dGFiX21heF9ncmFudF9mcmFtZXModm9pZCk7Ci0tIAoxLjcuNi40Cgo=
--------------080805070607050504050807
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------080805070607050504050807--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:14:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:14:44 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLT2-0003GA-5w
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:14:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLSg-00057N-9I; Fri, 18 Nov 2011 02:14:22 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLSV-00056A-If
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:14:12 -0800
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321611246!4049192!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25862 invoked from network); 18 Nov 2011 10:14:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 10:14:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIAE3DM029570
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 10:14:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIAE32p012551
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 10:14:03 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIADvA8020680; Fri, 18 Nov 2011 04:13:57 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 02:13:56 -0800
Message-ID: <4EC62FE5.2080608@oracle.com>
Date: Fri, 18 Nov 2011 18:13:57 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1321451372-13596-1-git-send-email-annie.li@oracle.com>
Content-Type: multipart/mixed; boundary="------------080805070607050504050807"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EC62FEC.0137,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] Re: [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------080805070607050504050807
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Defining a function pointer structure gnttab_v2_ops, the changes 
correspond to those in [PATCH 1/3] xen/granttable: Introducing grant 
table V2 stucture.

Thanks
Annie

--------------080805070607050504050807
Content-Type: text/plain;
	name="0003-xen-granttable-Grant-tables-V2-implementation.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0003-xen-granttable-Grant-tables-V2-implementation.patch"

RnJvbSBmYTUwOWY0YTNhODBmZGI4YTYwNGVmZTZkNjhkOWRjOGNlMjU1MTFiIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4K
RGF0ZTogRnJpLCAxOCBOb3YgMjAxMSAxNjo1MzozNyArMDgwMApTdWJqZWN0OiBbUEFUQ0gg
My80XSB4ZW4vZ3JhbnR0YWJsZTogR3JhbnQgdGFibGVzIFYyIGltcGxlbWVudGF0aW9uCgpS
ZWNlaXZlci1zaWRlIGNvcHlpbmcgb2YgcGFja2V0cyBpcyBiYXNlZCBvbiB0aGlzIGltcGxl
bWVudGF0aW9uLCBpdCBnaXZlcwpiZXR0ZXIgcGVyZm9ybWFuY2UgYW5kIGJldHRlciBDUFUg
YWNjb3VudGluZy4gSXQgdG90YWxseSBzdXBwb3J0cyB0aHJlZSB0eXBlczoKZnVsbC1wYWdl
LCBzdWItcGFnZSBhbmQgdHJhbnNpdGl2ZSBncmFudHMuCgpIb3dldmVyIHRoaXMgcGF0Y2gg
ZG9lcyBub3QgY292ZXIgc3ViLXBhZ2UgYW5kIHRyYW5zaXRpdmUgZ3JhbnRzLCBpdCBtYWlu
bHkKZm9jdXMgb24gRnVsbC1wYWdlIHBhcnQgYW5kIGltcGxlbWVudHMgZ3JhbnQgdGFibGUg
VjIgaW50ZXJmYWNlcyBjb3JyZXNwb25kaW5nCnRvIHdoYXQgYWxyZWFkeSBleGlzdHMgaW4g
Z3JhbnQgdGFibGUgVjEsIHN1Y2ggYXM6IGdyYW50IHRhYmxlIFYyCmluaXRpYWxpemF0aW9u
LCBtYXBwaW5nLCByZWxlYXNpbmcgYW5kIGV4cG9ydGVkIGludGVyZmFjZXMuCgpFYWNoIGd1
ZXN0IGNhbiBvbmx5IHN1cHBvcnRzIG9uZSB0eXBlIG9mIGdyYW50IHRhYmxlIHR5cGUsIGV2
ZXJ5IGVudHJ5IGluIGdyYW50CnRhYmxlIHNob3VsZCBiZSB0aGUgc2FtZSB2ZXJzaW9uLiBJ
dCBpcyBuZWNlc3NhcnkgdG8gc2V0IFYxIG9yIFYyIHZlcnNpb24gYmVmb3JlCmluaXRpYWxp
emluZyB0aGUgZ3JhbnQgdGFibGUuCgpHcmFudCB0YWJsZSBleHBvcnRlZCBpbnRlcmZhY2Vz
IG9mIFYyIGFyZSBzYW1lIHdpdGggdGhvc2Ugb2YgVjEsIFhlbiBpcwpyZXNwb25zaWJsZSB0
byBqdWRnZSB3aGF0IGdyYW50IHRhYmxlIHZlcnNpb24gZ3Vlc3RzIGFyZSB1c2luZyBpbiBl
dmVyeSBncmFudApvcGVyYXRpb24uCgpWMiBmdWxmaWxscyB0aGUgc2FtZSByb2xlIG9mIFYx
LCBhbmQgaXQgaXMgdG90YWxseSBiYWNrd2FyZHMgY29tcGl0YWJsZSB3aXRoIFYxLgpJZiBk
b20wIHN1cHBvcnQgZ3JhbnQgdGFibGUgVjIsIHRoZSBndWVzdHMgcnVuaW5nIG9uIGl0IGNh
biBydW4gd2l0aCBlaXRoZXIgVjEKb3IgVjIuCgpTaWduZWQtb2ZmLWJ5OiBBbm5pZSBMaSA8
YW5uaWUubGlAb3JhY2xlLmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYyB8
ICAgMzcgKysrKysrKysrLQogZHJpdmVycy94ZW4vZ3JhbnQtdGFibGUuYyAgfCAgMTc1ICsr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystCiBpbmNsdWRlL3hl
bi9ncmFudF90YWJsZS5oICB8ICAgIDYgKy0KIDMgZmlsZXMgY2hhbmdlZCwgMjExIGluc2Vy
dGlvbnMoKyksIDcgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvYXJjaC94ODYveGVuL2dy
YW50LXRhYmxlLmMgYi9hcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYwppbmRleCBjNmFiMmU3
Li41MTBmY2EwIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYworKysg
Yi9hcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYwpAQCAtNTQsNiArNTQsMjAgQEAgc3RhdGlj
IGludCBtYXBfcHRlX2ZuKHB0ZV90ICpwdGUsIHN0cnVjdCBwYWdlICpwbWRfcGFnZSwKIAly
ZXR1cm4gMDsKIH0KIAorLyoKKyAqIFRoaXMgZnVuY3Rpb24gaXMgdXNlZCB0byBtYXAgc2hh
cmVkIGZyYW1lcyB0byBzdG9yZSBncmFudCBzdGF0dXMuIEl0IGlzCisgKiBkaWZmZXJlbnQg
ZnJvbSBtYXBfcHRlX2ZuIGFib3ZlLCB0aGUgZnJhbWVzIHR5cGUgaGVyZSBpcyB1aW50NjRf
dC4KKyAqLworc3RhdGljIGludCBtYXBfcHRlX2ZuX3N0YXR1cyhwdGVfdCAqcHRlLCBzdHJ1
Y3QgcGFnZSAqcG1kX3BhZ2UsCisJCQkgICAgIHVuc2lnbmVkIGxvbmcgYWRkciwgdm9pZCAq
ZGF0YSkKK3sKKwl1aW50NjRfdCAqKmZyYW1lcyA9ICh1aW50NjRfdCAqKilkYXRhOworCisJ
c2V0X3B0ZV9hdCgmaW5pdF9tbSwgYWRkciwgcHRlLCBtZm5fcHRlKCgqZnJhbWVzKVswXSwg
UEFHRV9LRVJORUwpKTsKKwkoKmZyYW1lcykrKzsKKwlyZXR1cm4gMDsKK30KKwogc3RhdGlj
IGludCB1bm1hcF9wdGVfZm4ocHRlX3QgKnB0ZSwgc3RydWN0IHBhZ2UgKnBtZF9wYWdlLAog
CQkJdW5zaWduZWQgbG9uZyBhZGRyLCB2b2lkICpkYXRhKQogewpAQCAtODMsNyArOTcsMjgg
QEAgaW50IGFyY2hfZ250dGFiX21hcF9zaGFyZWQodW5zaWduZWQgbG9uZyAqZnJhbWVzLCB1
bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMsCiAJcmV0dXJuIHJjOwogfQogCi12b2lkIGFyY2hf
Z250dGFiX3VubWFwX3NoYXJlZCh2b2lkICpzaGFyZWQsIHVuc2lnbmVkIGxvbmcgbnJfZ2Zy
YW1lcykKK2ludCBhcmNoX2dudHRhYl9tYXBfc3RhdHVzKHVpbnQ2NF90ICpmcmFtZXMsIHVu
c2lnbmVkIGxvbmcgbnJfZ2ZyYW1lcywKKwkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dm
cmFtZXMsCisJCQkgICBncmFudF9zdGF0dXNfdCAqKl9fc2hhcmVkKQoreworCWludCByYzsK
KwlncmFudF9zdGF0dXNfdCAqc2hhcmVkID0gKl9fc2hhcmVkOworCisJaWYgKHNoYXJlZCA9
PSBOVUxMKSB7CisJCXN0cnVjdCB2bV9zdHJ1Y3QgKmFyZWEgPQorCQkJYWxsb2Nfdm1fYXJl
YShQQUdFX1NJWkUgKiBtYXhfbnJfZ2ZyYW1lcyk7CisJCUJVR19PTihhcmVhID09IE5VTEwp
OworCQlzaGFyZWQgPSBhcmVhLT5hZGRyOworCQkqX19zaGFyZWQgPSBzaGFyZWQ7CisJfQor
CisJcmMgPSBhcHBseV90b19wYWdlX3JhbmdlKCZpbml0X21tLCAodW5zaWduZWQgbG9uZylz
aGFyZWQsCisJCQkJIFBBR0VfU0laRSAqIG5yX2dmcmFtZXMsCisJCQkJIG1hcF9wdGVfZm5f
c3RhdHVzLCAmZnJhbWVzKTsKKwlyZXR1cm4gcmM7Cit9CisKK3ZvaWQgYXJjaF9nbnR0YWJf
dW5tYXAodm9pZCAqc2hhcmVkLCB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpCiB7CiAJYXBw
bHlfdG9fcGFnZV9yYW5nZSgmaW5pdF9tbSwgKHVuc2lnbmVkIGxvbmcpc2hhcmVkLAogCQkJ
ICAgIFBBR0VfU0laRSAqIG5yX2dmcmFtZXMsIHVubWFwX3B0ZV9mbiwgTlVMTCk7CmRpZmYg
LS1naXQgYS9kcml2ZXJzL3hlbi9ncmFudC10YWJsZS5jIGIvZHJpdmVycy94ZW4vZ3JhbnQt
dGFibGUuYwppbmRleCBmMzMwNDFlLi5jYTA3NWU5IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hl
bi9ncmFudC10YWJsZS5jCisrKyBiL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMKQEAgLTQ0
LDYgKzQ0LDcgQEAKICNpbmNsdWRlIDx4ZW4vcGFnZS5oPgogI2luY2x1ZGUgPHhlbi9ncmFu
dF90YWJsZS5oPgogI2luY2x1ZGUgPHhlbi9pbnRlcmZhY2UvbWVtb3J5Lmg+CisjaW5jbHVk
ZSA8eGVuL2h2Yy1jb25zb2xlLmg+CiAjaW5jbHVkZSA8YXNtL3hlbi9oeXBlcmNhbGwuaD4K
IAogI2luY2x1ZGUgPGFzbS9wZ3RhYmxlLmg+CkBAIC01Myw3ICs1NCwxMCBAQAogLyogRXh0
ZXJuYWwgdG9vbHMgcmVzZXJ2ZSBmaXJzdCBmZXcgZ3JhbnQgdGFibGUgZW50cmllcy4gKi8K
ICNkZWZpbmUgTlJfUkVTRVJWRURfRU5UUklFUyA4CiAjZGVmaW5lIEdOVFRBQl9MSVNUX0VO
RCAweGZmZmZmZmZmCi0jZGVmaW5lIEdSRUZTX1BFUl9HUkFOVF9GUkFNRSAoUEFHRV9TSVpF
IC8gc2l6ZW9mKHN0cnVjdCBncmFudF9lbnRyeV92MSkpCisjZGVmaW5lIEdSRUZTX1BFUl9H
UkFOVF9GUkFNRSBcCisoZ3JhbnRfdGFibGVfdmVyc2lvbiA9PSAxID8gICAgICAgICAgICAg
ICAgICAgICAgXAorIChQQUdFX1NJWkUgLyBzaXplb2Yoc3RydWN0IGdyYW50X2VudHJ5X3Yx
KSkgOiAgIFwKKyAoUEFHRV9TSVpFIC8gc2l6ZW9mKHVuaW9uIGdyYW50X2VudHJ5X3YyKSkp
CiAKIHN0YXRpYyBncmFudF9yZWZfdCAqKmdudHRhYl9saXN0Owogc3RhdGljIHVuc2lnbmVk
IGludCBucl9ncmFudF9mcmFtZXM7CkBAIC02Niw2ICs3MCw3IEBAIEVYUE9SVF9TWU1CT0xf
R1BMKHhlbl9odm1fcmVzdW1lX2ZyYW1lcyk7CiAKIHN0YXRpYyB1bmlvbiB7CiAJc3RydWN0
IGdyYW50X2VudHJ5X3YxICp2MTsKKwl1bmlvbiBncmFudF9lbnRyeV92MiAqdjI7CiAJdm9p
ZCAqYWRkcjsKIH0gZ250dGFiX3NoYXJlZDsKIApAQCAtMTE5LDggKzEyNCwxMiBAQCBzdHJ1
Y3QgZ250dGFiX29wcyB7CiB9OwogCiBzdGF0aWMgc3RydWN0IGdudHRhYl9vcHMgZ250dGFi
X3YxX29wczsKK3N0YXRpYyBzdHJ1Y3QgZ250dGFiX29wcyBnbnR0YWJfdjJfb3BzOwogc3Rh
dGljIHN0cnVjdCBnbnR0YWJfb3BzICpnbnR0YWJfaW50ZXJmYWNlOwogCisvKlRoaXMgcmVm
bGVjdHMgc3RhdHVzIG9mIGdyYW50IGVudHJpZXMsIHNvIGFjdCBhcyBhIGdsb2JhbCB2YWx1
ZSovCitzdGF0aWMgZ3JhbnRfc3RhdHVzX3QgKmdyc3RhdHVzOworCiBzdGF0aWMgaW50IGdy
YW50X3RhYmxlX3ZlcnNpb247CiAKIHN0YXRpYyBzdHJ1Y3QgZ250dGFiX2ZyZWVfY2FsbGJh
Y2sgKmdudHRhYl9mcmVlX2NhbGxiYWNrX2xpc3Q7CkBAIC0xMjgsNiArMTM3LDcgQEAgc3Rh
dGljIHN0cnVjdCBnbnR0YWJfZnJlZV9jYWxsYmFjayAqZ250dGFiX2ZyZWVfY2FsbGJhY2tf
bGlzdDsKIHN0YXRpYyBpbnQgZ250dGFiX2V4cGFuZCh1bnNpZ25lZCBpbnQgcmVxX2VudHJp
ZXMpOwogCiAjZGVmaW5lIFJQUCAoUEFHRV9TSVpFIC8gc2l6ZW9mKGdyYW50X3JlZl90KSkK
KyNkZWZpbmUgU1BQIChQQUdFX1NJWkUgLyBzaXplb2YoZ3JhbnRfc3RhdHVzX3QpKQogCiBz
dGF0aWMgaW5saW5lIGdyYW50X3JlZl90ICpfX2dudHRhYl9lbnRyeShncmFudF9yZWZfdCBl
bnRyeSkKIHsKQEAgLTIwMCw2ICsyMTAsNyBAQCBzdGF0aWMgdm9pZCBwdXRfZnJlZV9lbnRy
eShncmFudF9yZWZfdCByZWYpCiB9CiAKIC8qCisgKiBGb2xsb3dpbmcgY29tbWVudHMgYXBw
bHkgdG8gdXBkYXRlX2dyYW50X2VudHJ5X3YxIGFuZCB1cGRhdGVfZ3JhbnRfZW50cnlfdjIu
CiAgKiBJbnRyb2R1Y2luZyBhIHZhbGlkIGVudHJ5IGludG8gdGhlIGdyYW50IHRhYmxlOgog
ICogIDEuIFdyaXRlIGVudC0+ZG9taWQuCiAgKiAgMi4gV3JpdGUgZW50LT5mcmFtZToKQEAg
LTIxOCw2ICsyMjksMTUgQEAgc3RhdGljIHZvaWQgdXBkYXRlX2dyYW50X2VudHJ5X3YxKGdy
YW50X3JlZl90IHJlZiwgZG9taWRfdCBkb21pZCwKIAlnbnR0YWJfc2hhcmVkLnYxW3JlZl0u
ZmxhZ3MgPSBmbGFnczsKIH0KIAorc3RhdGljIHZvaWQgdXBkYXRlX2dyYW50X2VudHJ5X3Yy
KGdyYW50X3JlZl90IHJlZiwgZG9taWRfdCBkb21pZCwKKwkJCQkgIHVuc2lnbmVkIGxvbmcg
ZnJhbWUsIHVuc2lnbmVkIGZsYWdzKQoreworCWdudHRhYl9zaGFyZWQudjJbcmVmXS5oZHIu
ZG9taWQgPSBkb21pZDsKKwlnbnR0YWJfc2hhcmVkLnYyW3JlZl0uZnVsbF9wYWdlLmZyYW1l
ID0gZnJhbWU7CisJd21iKCk7CisJZ250dGFiX3NoYXJlZC52MltyZWZdLmhkci5mbGFncyA9
IEdURl9wZXJtaXRfYWNjZXNzIHwgZmxhZ3M7Cit9CisKIC8qCiAgKiBQdWJsaWMgZ3JhbnQt
aXNzdWluZyBpbnRlcmZhY2UgZnVuY3Rpb25zCiAgKi8KQEAgLTI0OSw2ICsyNjksMTEgQEAg
c3RhdGljIGludCBnbnR0YWJfcXVlcnlfZm9yZWlnbl9hY2Nlc3NfdjEoZ3JhbnRfcmVmX3Qg
cmVmKQogCXJldHVybiBnbnR0YWJfc2hhcmVkLnYxW3JlZl0uZmxhZ3MgJiAoR1RGX3JlYWRp
bmd8R1RGX3dyaXRpbmcpOwogfQogCitzdGF0aWMgaW50IGdudHRhYl9xdWVyeV9mb3JlaWdu
X2FjY2Vzc192MihncmFudF9yZWZfdCByZWYpCit7CisJcmV0dXJuIGdyc3RhdHVzW3JlZl0g
JiAoR1RGX3JlYWRpbmd8R1RGX3dyaXRpbmcpOworfQorCiBpbnQgZ250dGFiX3F1ZXJ5X2Zv
cmVpZ25fYWNjZXNzKGdyYW50X3JlZl90IHJlZikKIHsKIAlyZXR1cm4gZ250dGFiX2ludGVy
ZmFjZS0+cXVlcnlfZm9yZWlnbl9hY2Nlc3MocmVmKTsKQEAgLTI3Myw2ICsyOTgsMjkgQEAg
c3RhdGljIGludCBnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzX3JlZl92MShncmFudF9yZWZf
dCByZWYsIGludCByZWFkb25seSkKIAlyZXR1cm4gMTsKIH0KIAorc3RhdGljIGludCBnbnR0
YWJfZW5kX2ZvcmVpZ25fYWNjZXNzX3JlZl92MihncmFudF9yZWZfdCByZWYsIGludCByZWFk
b25seSkKK3sKKwlnbnR0YWJfc2hhcmVkLnYyW3JlZl0uaGRyLmZsYWdzID0gMDsKKwltYigp
OworCWlmIChncnN0YXR1c1tyZWZdICYgKEdURl9yZWFkaW5nfEdURl93cml0aW5nKSkgewor
CQlyZXR1cm4gMDsKKwl9IGVsc2UgeworCQkvKiBUaGUgcmVhZCBvZiBncnN0YXR1cyBuZWVk
cyB0byBoYXZlIGFjcXVpcmUKKwkJc2VtYW50aWNzLiAgT24geDg2LCByZWFkcyBhbHJlYWR5
IGhhdmUKKwkJdGhhdCwgYW5kIHdlIGp1c3QgbmVlZCB0byBwcm90ZWN0IGFnYWluc3QKKwkJ
Y29tcGlsZXIgcmVvcmRlcmluZ3MuICBPbiBvdGhlcgorCQlhcmNoaXRlY3R1cmVzIHdlIG1h
eSBuZWVkIGEgZnVsbAorCQliYXJyaWVyLiAqLworI2lmZGVmIENPTkZJR19YODYKKwkJYmFy
cmllcigpOworI2Vsc2UKKwkJbWIoKTsKKyNlbmRpZgorCQl9CisKKwlyZXR1cm4gMTsKK30K
KwogaW50IGdudHRhYl9lbmRfZm9yZWlnbl9hY2Nlc3NfcmVmKGdyYW50X3JlZl90IHJlZiwg
aW50IHJlYWRvbmx5KQogewogCXJldHVybiBnbnR0YWJfaW50ZXJmYWNlLT5lbmRfZm9yZWln
bl9hY2Nlc3NfcmVmKHJlZiwgcmVhZG9ubHkpOwpAQCAtMzQ2LDYgKzM5NCwzNyBAQCBzdGF0
aWMgdW5zaWduZWQgbG9uZyBnbnR0YWJfZW5kX2ZvcmVpZ25fdHJhbnNmZXJfcmVmX3YxKGdy
YW50X3JlZl90IHJlZikKIAlyZXR1cm4gZnJhbWU7CiB9CiAKK3N0YXRpYyB1bnNpZ25lZCBs
b25nIGdudHRhYl9lbmRfZm9yZWlnbl90cmFuc2Zlcl9yZWZfdjIoZ3JhbnRfcmVmX3QgcmVm
KQoreworCXVuc2lnbmVkIGxvbmcgZnJhbWU7CisJdTE2ICAgICAgICAgICBmbGFnczsKKwl1
MTYgICAgICAgICAgKnBmbGFnczsKKworCXBmbGFncyA9ICZnbnR0YWJfc2hhcmVkLnYyW3Jl
Zl0uaGRyLmZsYWdzOworCisJLyoKKwkgKiBJZiBhIHRyYW5zZmVyIGlzIG5vdCBldmVuIHll
dCBzdGFydGVkLCB0cnkgdG8gcmVjbGFpbSB0aGUgZ3JhbnQKKwkgKiByZWZlcmVuY2UgYW5k
IHJldHVybiBmYWlsdXJlICg9PSAwKS4KKwkgKi8KKwl3aGlsZSAoISgoZmxhZ3MgPSAqcGZs
YWdzKSAmIEdURl90cmFuc2Zlcl9jb21taXR0ZWQpKSB7CisJCWlmIChzeW5jX2NtcHhjaGco
cGZsYWdzLCBmbGFncywgMCkgPT0gZmxhZ3MpCisJCQlyZXR1cm4gMDsKKwkJY3B1X3JlbGF4
KCk7CisJfQorCisJLyogSWYgYSB0cmFuc2ZlciBpcyBpbiBwcm9ncmVzcyB0aGVuIHdhaXQg
dW50aWwgaXQgaXMgY29tcGxldGVkLiAqLworCXdoaWxlICghKGZsYWdzICYgR1RGX3RyYW5z
ZmVyX2NvbXBsZXRlZCkpIHsKKwkJZmxhZ3MgPSAqcGZsYWdzOworCQljcHVfcmVsYXgoKTsK
Kwl9CisKKwlybWIoKTsgIC8qIFJlYWQgdGhlIGZyYW1lIG51bWJlciAvYWZ0ZXIvIHJlYWRp
bmcgY29tcGxldGlvbiBzdGF0dXMuICovCisJZnJhbWUgPSBnbnR0YWJfc2hhcmVkLnYyW3Jl
Zl0uZnVsbF9wYWdlLmZyYW1lOworCUJVR19PTihmcmFtZSA9PSAwKTsKKworCXJldHVybiBm
cmFtZTsKK30KKwogdW5zaWduZWQgbG9uZyBnbnR0YWJfZW5kX2ZvcmVpZ25fdHJhbnNmZXJf
cmVmKGdyYW50X3JlZl90IHJlZikKIHsKIAlyZXR1cm4gZ250dGFiX2ludGVyZmFjZS0+ZW5k
X2ZvcmVpZ25fdHJhbnNmZXJfcmVmKHJlZik7CkBAIC01OTMsNiArNjcyLDExIEBAIGludCBn
bnR0YWJfdW5tYXBfcmVmcyhzdHJ1Y3QgZ250dGFiX3VubWFwX2dyYW50X3JlZiAqdW5tYXBf
b3BzLAogfQogRVhQT1JUX1NZTUJPTF9HUEwoZ250dGFiX3VubWFwX3JlZnMpOwogCitzdGF0
aWMgdW5zaWduZWQgbnJfc3RhdHVzX2ZyYW1lcyh1bnNpZ25lZCBucl9ncmFudF9mcmFtZXMp
Cit7CisJcmV0dXJuIChucl9ncmFudF9mcmFtZXMgKiBHUkVGU19QRVJfR1JBTlRfRlJBTUUg
KyBTUFAgLSAxKSAvIFNQUDsKK30KKwogc3RhdGljIGludCBnbnR0YWJfbWFwX2ZyYW1lc192
MSh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGludCBucl9nZnJhbWVzKQogewog
CWludCByYzsKQEAgLTYwNyw3ICs2OTEsNTYgQEAgc3RhdGljIGludCBnbnR0YWJfbWFwX2Zy
YW1lc192MSh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGludCBucl9nZnJhbWVz
KQogCiBzdGF0aWMgdm9pZCBnbnR0YWJfdW5tYXBfZnJhbWVzX3YxKHZvaWQpCiB7Ci0JYXJj
aF9nbnR0YWJfdW5tYXBfc2hhcmVkKGdudHRhYl9zaGFyZWQuYWRkciwgbnJfZ3JhbnRfZnJh
bWVzKTsKKwlhcmNoX2dudHRhYl91bm1hcChnbnR0YWJfc2hhcmVkLmFkZHIsIG5yX2dyYW50
X2ZyYW1lcyk7Cit9CisKK3N0YXRpYyBpbnQgZ250dGFiX21hcF9mcmFtZXNfdjIodW5zaWdu
ZWQgbG9uZyAqZnJhbWVzLCB1bnNpZ25lZCBpbnQgbnJfZ2ZyYW1lcykKK3sKKwl1aW50NjRf
dCAqc2ZyYW1lczsKKwl1bnNpZ25lZCBpbnQgbnJfc2ZyYW1lczsKKwlzdHJ1Y3QgZ250dGFi
X2dldF9zdGF0dXNfZnJhbWVzIGdldGZyYW1lczsKKwlpbnQgcmM7CisKKwlucl9zZnJhbWVz
ID0gbnJfc3RhdHVzX2ZyYW1lcyhucl9nZnJhbWVzKTsKKworCS8qIE5vIG5lZWQgZm9yIGt6
YWxsb2MgYXMgaXQgaXMgaW5pdGlhbGl6ZWQgaW4gZm9sbG93aW5nIGh5cGVyY2FsbAorCSAq
IEdOVFRBQk9QX2dldF9zdGF0dXNfZnJhbWVzLgorCSAqLworCXNmcmFtZXMgPSBrbWFsbG9j
KG5yX3NmcmFtZXMgICogc2l6ZW9mKHVpbnQ2NF90KSwgR0ZQX0FUT01JQyk7CisJaWYgKCFz
ZnJhbWVzKQorCQlyZXR1cm4gLUVOT01FTTsKKworCWdldGZyYW1lcy5kb20gICAgICAgID0g
RE9NSURfU0VMRjsKKwlnZXRmcmFtZXMubnJfZnJhbWVzICA9IG5yX3NmcmFtZXM7CisJc2V0
X3hlbl9ndWVzdF9oYW5kbGUoZ2V0ZnJhbWVzLmZyYW1lX2xpc3QsIHNmcmFtZXMpOworCisJ
cmMgPSBIWVBFUlZJU09SX2dyYW50X3RhYmxlX29wKEdOVFRBQk9QX2dldF9zdGF0dXNfZnJh
bWVzLAorCQkJCSAgICAgICAmZ2V0ZnJhbWVzLCAxKTsKKwlpZiAocmMgPT0gLUVOT1NZUykg
eworCQlrZnJlZShzZnJhbWVzKTsKKwkJcmV0dXJuIC1FTk9TWVM7CisJfQorCisJQlVHX09O
KHJjIHx8IGdldGZyYW1lcy5zdGF0dXMpOworCisJcmMgPSBhcmNoX2dudHRhYl9tYXBfc3Rh
dHVzKHNmcmFtZXMsIG5yX3NmcmFtZXMsCisJCQkJICAgIG5yX3N0YXR1c19mcmFtZXMoZ250
dGFiX21heF9ncmFudF9mcmFtZXMoKSksCisJCQkJICAgICZncnN0YXR1cyk7CisJQlVHX09O
KHJjKTsKKwlrZnJlZShzZnJhbWVzKTsKKworCXJjID0gYXJjaF9nbnR0YWJfbWFwX3NoYXJl
ZChmcmFtZXMsIG5yX2dmcmFtZXMsCisJCQkJICAgIGdudHRhYl9tYXhfZ3JhbnRfZnJhbWVz
KCksCisJCQkJICAgICZnbnR0YWJfc2hhcmVkLmFkZHIpOworCUJVR19PTihyYyk7CisKKwly
ZXR1cm4gMDsKK30KKworc3RhdGljIHZvaWQgZ250dGFiX3VubWFwX2ZyYW1lc192Mih2b2lk
KQoreworCWFyY2hfZ250dGFiX3VubWFwKGdudHRhYl9zaGFyZWQuYWRkciwgbnJfZ3JhbnRf
ZnJhbWVzKTsKKwlhcmNoX2dudHRhYl91bm1hcChncnN0YXR1cywgbnJfc3RhdHVzX2ZyYW1l
cyhucl9ncmFudF9mcmFtZXMpKTsKIH0KIAogc3RhdGljIGludCBnbnR0YWJfbWFwKHVuc2ln
bmVkIGludCBzdGFydF9pZHgsIHVuc2lnbmVkIGludCBlbmRfaWR4KQpAQCAtNjQxLDYgKzc3
NCw5IEBAIHN0YXRpYyBpbnQgZ250dGFiX21hcCh1bnNpZ25lZCBpbnQgc3RhcnRfaWR4LCB1
bnNpZ25lZCBpbnQgZW5kX2lkeCkKIAkJcmV0dXJuIHJjOwogCX0KIAorCS8qIE5vIG5lZWQg
Zm9yIGt6YWxsb2MgYXMgaXQgaXMgaW5pdGlhbGl6ZWQgaW4gZm9sbG93aW5nIGh5cGVyY2Fs
bAorCSAqIEdOVFRBQk9QX3NldHVwX3RhYmxlLgorCSAqLwogCWZyYW1lcyA9IGttYWxsb2Mo
bnJfZ2ZyYW1lcyAqIHNpemVvZih1bnNpZ25lZCBsb25nKSwgR0ZQX0FUT01JQyk7CiAJaWYg
KCFmcmFtZXMpCiAJCXJldHVybiAtRU5PTUVNOwpAQCAtNjczLDEwICs4MDksNDEgQEAgc3Rh
dGljIHN0cnVjdCBnbnR0YWJfb3BzIGdudHRhYl92MV9vcHMgPSB7CiAJLnF1ZXJ5X2ZvcmVp
Z25fYWNjZXNzCQk9IGdudHRhYl9xdWVyeV9mb3JlaWduX2FjY2Vzc192MSwKIH07CiAKK3N0
YXRpYyBzdHJ1Y3QgZ250dGFiX29wcyBnbnR0YWJfdjJfb3BzID0geworCS5tYXBfZnJhbWVz
CQkJPSBnbnR0YWJfbWFwX2ZyYW1lc192MiwKKwkudW5tYXBfZnJhbWVzCQkJPSBnbnR0YWJf
dW5tYXBfZnJhbWVzX3YyLAorCS51cGRhdGVfZW50cnkJCQk9IHVwZGF0ZV9ncmFudF9lbnRy
eV92MiwKKwkuZW5kX2ZvcmVpZ25fYWNjZXNzX3JlZgkJPSBnbnR0YWJfZW5kX2ZvcmVpZ25f
YWNjZXNzX3JlZl92MiwKKwkuZW5kX2ZvcmVpZ25fdHJhbnNmZXJfcmVmCT0gZ250dGFiX2Vu
ZF9mb3JlaWduX3RyYW5zZmVyX3JlZl92MiwKKwkucXVlcnlfZm9yZWlnbl9hY2Nlc3MJCT0g
Z250dGFiX3F1ZXJ5X2ZvcmVpZ25fYWNjZXNzX3YyLAorfTsKKwogc3RhdGljIHZvaWQgZ250
dGFiX3JlcXVlc3RfdmVyc2lvbih2b2lkKQogewotCWdyYW50X3RhYmxlX3ZlcnNpb24gPSAx
OwotCWdudHRhYl9pbnRlcmZhY2UgPSAmZ250dGFiX3YxX29wczsKKwlpbnQgcmM7CisJc3Ry
dWN0IGdudHRhYl9zZXRfdmVyc2lvbiBnc3Y7CisJY29uc3QgY2hhciAqc3RyID0gIndlIG5l
ZWQgZ3JhbnQgdGFibGVzIHZlcnNpb24gMiwgYnV0IG9ubHkgdmVyc2lvbiAxIGlzIGF2YWls
YWJsZVxuIjsKKworCWdzdi52ZXJzaW9uID0gMjsKKwlyYyA9IEhZUEVSVklTT1JfZ3JhbnRf
dGFibGVfb3AoR05UVEFCT1Bfc2V0X3ZlcnNpb24sICZnc3YsIDEpOworCWlmIChyYyA9PSAw
KSB7CisJCWdyYW50X3RhYmxlX3ZlcnNpb24gPSAyOworCQlnbnR0YWJfaW50ZXJmYWNlID0g
JmdudHRhYl92Ml9vcHM7CisJfSBlbHNlIHsKKwkJaWYgKGdyYW50X3RhYmxlX3ZlcnNpb24g
PT0gMikgeworCQkJLyoKKwkJCSAqIElmIHdlJ3ZlIGFscmVhZHkgdXNlZCB2ZXJzaW9uIDIg
ZmVhdHVyZXMsCisJCQkgKiBidXQgdGhlbiBzdWRkZW5seSBkaXNjb3ZlciB0aGF0IHRoZXkn
cmUgbm90CisJCQkgKiBhdmFpbGFibGUgKGUuZy4gbWlncmF0aW5nIHRvIGFuIG9sZGVyCisJ
CQkgKiB2ZXJzaW9uIG9mIFhlbiksIGFsbW9zdCB1bmJvdW5kZWQgYmFkbmVzcworCQkJICog
Y2FuIGhhcHBlbi4KKwkJCSAqLworCQkJeGVuX3Jhd19wcmludGsoc3RyKTsKKwkJCXBhbmlj
KHN0cik7CisJCX0KKwkJZ3JhbnRfdGFibGVfdmVyc2lvbiA9IDE7CisJCWdudHRhYl9pbnRl
cmZhY2UgPSAmZ250dGFiX3YxX29wczsKKwl9CiAJcHJpbnRrKEtFUk5fSU5GTyAiR3JhbnQg
dGFibGVzIHVzaW5nIHZlcnNpb24gJWQgbGF5b3V0LlxuIiwKIAkJZ3JhbnRfdGFibGVfdmVy
c2lvbik7CiB9CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9ncmFudF90YWJsZS5oIGIvaW5j
bHVkZS94ZW4vZ3JhbnRfdGFibGUuaAppbmRleCBjN2E0MGY4Li41NDk0YzQwIDEwMDY0NAot
LS0gYS9pbmNsdWRlL3hlbi9ncmFudF90YWJsZS5oCisrKyBiL2luY2x1ZGUveGVuL2dyYW50
X3RhYmxlLmgKQEAgLTE0Niw4ICsxNDYsMTAgQEAgZ250dGFiX3NldF91bm1hcF9vcChzdHJ1
Y3QgZ250dGFiX3VubWFwX2dyYW50X3JlZiAqdW5tYXAsIHBoeXNfYWRkcl90IGFkZHIsCiBp
bnQgYXJjaF9nbnR0YWJfbWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2ln
bmVkIGxvbmcgbnJfZ2ZyYW1lcywKIAkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFt
ZXMsCiAJCQkgICB2b2lkICoqX19zaGFyZWQpOwotdm9pZCBhcmNoX2dudHRhYl91bm1hcF9z
aGFyZWQodm9pZCAqc2hhcmVkLAotCQkJICAgICAgdW5zaWduZWQgbG9uZyBucl9nZnJhbWVz
KTsKK2ludCBhcmNoX2dudHRhYl9tYXBfc3RhdHVzKHVpbnQ2NF90ICpmcmFtZXMsIHVuc2ln
bmVkIGxvbmcgbnJfZ2ZyYW1lcywKKwkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFt
ZXMsCisJCQkgICBncmFudF9zdGF0dXNfdCAqKl9fc2hhcmVkKTsKK3ZvaWQgYXJjaF9nbnR0
YWJfdW5tYXAodm9pZCAqc2hhcmVkLCB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpOwogCiBl
eHRlcm4gdW5zaWduZWQgbG9uZyB4ZW5faHZtX3Jlc3VtZV9mcmFtZXM7CiB1bnNpZ25lZCBp
bnQgZ250dGFiX21heF9ncmFudF9mcmFtZXModm9pZCk7Ci0tIAoxLjcuNi40Cgo=
--------------080805070607050504050807
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------080805070607050504050807--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:18:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:18:14 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLWQ-0003Ga-Lt
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLW6-0006BC-TW; Fri, 18 Nov 2011 02:17:55 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLUg-0005fx-6E
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:16:27 -0800
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1321611380!3654399!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31577 invoked from network); 18 Nov 2011 10:16:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 10:16:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIAGHYs031894
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 10:16:18 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIAGGJ5001790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 10:16:17 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIAGBIl022107; Fri, 18 Nov 2011 04:16:11 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 02:16:10 -0800
Message-ID: <4EC6306B.8070800@oracle.com>
Date: Fri, 18 Nov 2011 18:16:11 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
References: <4EC3B62F.6080702@oracle.com>
	<1321451431-13632-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1321451431-13632-1-git-send-email-annie.li@oracle.com>
Content-Type: multipart/mixed; boundary="------------050905090709060000090701"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4EC63072.00AC,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] Re: [PATCH 3/3] xen/granttable: Keep code format clean
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------050905090709060000090701
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

This patch does not change from the initial one: [PATCH 3/3] 
xen/granttable: Keep code format clean.

Thanks
Annie

--------------050905090709060000090701
Content-Type: text/plain;
	name="0004-xen-granttable-Keep-code-format-clean.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0004-xen-granttable-Keep-code-format-clean.patch"

RnJvbSBmOGI2ZjQzMTExNWQ3YWZlNmM5YjI0ZTY4ZDFiZTdmN2RhOTMzZjlmIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4K
RGF0ZTogRnJpLCAxOCBOb3YgMjAxMSAxNzowOTowOSArMDgwMApTdWJqZWN0OiBbUEFUQ0gg
NC80XSB4ZW4vZ3JhbnR0YWJsZTogS2VlcCBjb2RlIGZvcm1hdCBjbGVhbgoKU2lnbmVkLW9m
Zi1ieTogQW5uaWUgTGkgPGFubmllLmxpQG9yYWNsZS5jb20+Ci0tLQogZHJpdmVycy94ZW4v
Z3JhbnQtdGFibGUuYyB8ICAgIDcgKysrLS0tLQogaW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUu
aCB8ICAgIDIgKy0KIDIgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCA1IGRlbGV0
aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMgYi9kcml2
ZXJzL3hlbi9ncmFudC10YWJsZS5jCmluZGV4IGNhMDc1ZTkuLjJhYWIyZGYgMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMKKysrIGIvZHJpdmVycy94ZW4vZ3JhbnQt
dGFibGUuYwpAQCAtNTAsNyArNTAsNiBAQAogI2luY2x1ZGUgPGFzbS9wZ3RhYmxlLmg+CiAj
aW5jbHVkZSA8YXNtL3N5bmNfYml0b3BzLmg+CiAKLQogLyogRXh0ZXJuYWwgdG9vbHMgcmVz
ZXJ2ZSBmaXJzdCBmZXcgZ3JhbnQgdGFibGUgZW50cmllcy4gKi8KICNkZWZpbmUgTlJfUkVT
RVJWRURfRU5UUklFUyA4CiAjZGVmaW5lIEdOVFRBQl9MSVNUX0VORCAweGZmZmZmZmZmCkBA
IC02MDAsOCArNTk5LDggQEAgdW5zaWduZWQgaW50IGdudHRhYl9tYXhfZ3JhbnRfZnJhbWVz
KHZvaWQpCiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfbWF4X2dyYW50X2ZyYW1lcyk7CiAK
IGludCBnbnR0YWJfbWFwX3JlZnMoc3RydWN0IGdudHRhYl9tYXBfZ3JhbnRfcmVmICptYXBf
b3BzLAotCQkJc3RydWN0IGdudHRhYl9tYXBfZ3JhbnRfcmVmICprbWFwX29wcywKLQkJCXN0
cnVjdCBwYWdlICoqcGFnZXMsIHVuc2lnbmVkIGludCBjb3VudCkKKwkJICAgIHN0cnVjdCBn
bnR0YWJfbWFwX2dyYW50X3JlZiAqa21hcF9vcHMsCisJCSAgICBzdHJ1Y3QgcGFnZSAqKnBh
Z2VzLCB1bnNpZ25lZCBpbnQgY291bnQpCiB7CiAJaW50IGksIHJldDsKIAlwdGVfdCAqcHRl
OwpAQCAtNjUxLDcgKzY1MCw3IEBAIGludCBnbnR0YWJfbWFwX3JlZnMoc3RydWN0IGdudHRh
Yl9tYXBfZ3JhbnRfcmVmICptYXBfb3BzLAogRVhQT1JUX1NZTUJPTF9HUEwoZ250dGFiX21h
cF9yZWZzKTsKIAogaW50IGdudHRhYl91bm1hcF9yZWZzKHN0cnVjdCBnbnR0YWJfdW5tYXBf
Z3JhbnRfcmVmICp1bm1hcF9vcHMsCi0JCXN0cnVjdCBwYWdlICoqcGFnZXMsIHVuc2lnbmVk
IGludCBjb3VudCkKKwkJICAgICAgc3RydWN0IHBhZ2UgKipwYWdlcywgdW5zaWduZWQgaW50
IGNvdW50KQogewogCWludCBpLCByZXQ7CiAKZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2dy
YW50X3RhYmxlLmggYi9pbmNsdWRlL3hlbi9ncmFudF90YWJsZS5oCmluZGV4IDU0OTRjNDAu
LmZlYTQ5NTQgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2dyYW50X3RhYmxlLmgKKysrIGIv
aW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUuaApAQCAtMTU3LDcgKzE1Nyw3IEBAIHVuc2lnbmVk
IGludCBnbnR0YWJfbWF4X2dyYW50X2ZyYW1lcyh2b2lkKTsKICNkZWZpbmUgZ250dGFiX21h
cF92YWRkcihtYXApICgodm9pZCAqKShtYXAuaG9zdF92aXJ0X2FkZHIpKQogCiBpbnQgZ250
dGFiX21hcF9yZWZzKHN0cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiAqbWFwX29wcywKLQkJ
CXN0cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiAqa21hcF9vcHMsCisJCSAgICBzdHJ1Y3Qg
Z250dGFiX21hcF9ncmFudF9yZWYgKmttYXBfb3BzLAogCQkgICAgc3RydWN0IHBhZ2UgKipw
YWdlcywgdW5zaWduZWQgaW50IGNvdW50KTsKIGludCBnbnR0YWJfdW5tYXBfcmVmcyhzdHJ1
Y3QgZ250dGFiX3VubWFwX2dyYW50X3JlZiAqdW5tYXBfb3BzLAogCQkgICAgICBzdHJ1Y3Qg
cGFnZSAqKnBhZ2VzLCB1bnNpZ25lZCBpbnQgY291bnQpOwotLSAKMS43LjYuNAoK
--------------050905090709060000090701
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------050905090709060000090701--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:18:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:18:14 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLWQ-0003Ga-Lt
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLW6-0006BC-TW; Fri, 18 Nov 2011 02:17:55 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLUg-0005fx-6E
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:16:27 -0800
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1321611380!3654399!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31577 invoked from network); 18 Nov 2011 10:16:22 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 10:16:22 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIAGHYs031894
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 10:16:18 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIAGGJ5001790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 10:16:17 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIAGBIl022107; Fri, 18 Nov 2011 04:16:11 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 02:16:10 -0800
Message-ID: <4EC6306B.8070800@oracle.com>
Date: Fri, 18 Nov 2011 18:16:11 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
References: <4EC3B62F.6080702@oracle.com>
	<1321451431-13632-1-git-send-email-annie.li@oracle.com>
In-Reply-To: <1321451431-13632-1-git-send-email-annie.li@oracle.com>
Content-Type: multipart/mixed; boundary="------------050905090709060000090701"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4EC63072.00AC,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com
Subject: [Xen-devel] Re: [PATCH 3/3] xen/granttable: Keep code format clean
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------050905090709060000090701
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

This patch does not change from the initial one: [PATCH 3/3] 
xen/granttable: Keep code format clean.

Thanks
Annie

--------------050905090709060000090701
Content-Type: text/plain;
	name="0004-xen-granttable-Keep-code-format-clean.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0004-xen-granttable-Keep-code-format-clean.patch"

RnJvbSBmOGI2ZjQzMTExNWQ3YWZlNmM5YjI0ZTY4ZDFiZTdmN2RhOTMzZjlmIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4K
RGF0ZTogRnJpLCAxOCBOb3YgMjAxMSAxNzowOTowOSArMDgwMApTdWJqZWN0OiBbUEFUQ0gg
NC80XSB4ZW4vZ3JhbnR0YWJsZTogS2VlcCBjb2RlIGZvcm1hdCBjbGVhbgoKU2lnbmVkLW9m
Zi1ieTogQW5uaWUgTGkgPGFubmllLmxpQG9yYWNsZS5jb20+Ci0tLQogZHJpdmVycy94ZW4v
Z3JhbnQtdGFibGUuYyB8ICAgIDcgKysrLS0tLQogaW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUu
aCB8ICAgIDIgKy0KIDIgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCA1IGRlbGV0
aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMgYi9kcml2
ZXJzL3hlbi9ncmFudC10YWJsZS5jCmluZGV4IGNhMDc1ZTkuLjJhYWIyZGYgMTAwNjQ0Ci0t
LSBhL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMKKysrIGIvZHJpdmVycy94ZW4vZ3JhbnQt
dGFibGUuYwpAQCAtNTAsNyArNTAsNiBAQAogI2luY2x1ZGUgPGFzbS9wZ3RhYmxlLmg+CiAj
aW5jbHVkZSA8YXNtL3N5bmNfYml0b3BzLmg+CiAKLQogLyogRXh0ZXJuYWwgdG9vbHMgcmVz
ZXJ2ZSBmaXJzdCBmZXcgZ3JhbnQgdGFibGUgZW50cmllcy4gKi8KICNkZWZpbmUgTlJfUkVT
RVJWRURfRU5UUklFUyA4CiAjZGVmaW5lIEdOVFRBQl9MSVNUX0VORCAweGZmZmZmZmZmCkBA
IC02MDAsOCArNTk5LDggQEAgdW5zaWduZWQgaW50IGdudHRhYl9tYXhfZ3JhbnRfZnJhbWVz
KHZvaWQpCiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfbWF4X2dyYW50X2ZyYW1lcyk7CiAK
IGludCBnbnR0YWJfbWFwX3JlZnMoc3RydWN0IGdudHRhYl9tYXBfZ3JhbnRfcmVmICptYXBf
b3BzLAotCQkJc3RydWN0IGdudHRhYl9tYXBfZ3JhbnRfcmVmICprbWFwX29wcywKLQkJCXN0
cnVjdCBwYWdlICoqcGFnZXMsIHVuc2lnbmVkIGludCBjb3VudCkKKwkJICAgIHN0cnVjdCBn
bnR0YWJfbWFwX2dyYW50X3JlZiAqa21hcF9vcHMsCisJCSAgICBzdHJ1Y3QgcGFnZSAqKnBh
Z2VzLCB1bnNpZ25lZCBpbnQgY291bnQpCiB7CiAJaW50IGksIHJldDsKIAlwdGVfdCAqcHRl
OwpAQCAtNjUxLDcgKzY1MCw3IEBAIGludCBnbnR0YWJfbWFwX3JlZnMoc3RydWN0IGdudHRh
Yl9tYXBfZ3JhbnRfcmVmICptYXBfb3BzLAogRVhQT1JUX1NZTUJPTF9HUEwoZ250dGFiX21h
cF9yZWZzKTsKIAogaW50IGdudHRhYl91bm1hcF9yZWZzKHN0cnVjdCBnbnR0YWJfdW5tYXBf
Z3JhbnRfcmVmICp1bm1hcF9vcHMsCi0JCXN0cnVjdCBwYWdlICoqcGFnZXMsIHVuc2lnbmVk
IGludCBjb3VudCkKKwkJICAgICAgc3RydWN0IHBhZ2UgKipwYWdlcywgdW5zaWduZWQgaW50
IGNvdW50KQogewogCWludCBpLCByZXQ7CiAKZGlmZiAtLWdpdCBhL2luY2x1ZGUveGVuL2dy
YW50X3RhYmxlLmggYi9pbmNsdWRlL3hlbi9ncmFudF90YWJsZS5oCmluZGV4IDU0OTRjNDAu
LmZlYTQ5NTQgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2dyYW50X3RhYmxlLmgKKysrIGIv
aW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUuaApAQCAtMTU3LDcgKzE1Nyw3IEBAIHVuc2lnbmVk
IGludCBnbnR0YWJfbWF4X2dyYW50X2ZyYW1lcyh2b2lkKTsKICNkZWZpbmUgZ250dGFiX21h
cF92YWRkcihtYXApICgodm9pZCAqKShtYXAuaG9zdF92aXJ0X2FkZHIpKQogCiBpbnQgZ250
dGFiX21hcF9yZWZzKHN0cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiAqbWFwX29wcywKLQkJ
CXN0cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiAqa21hcF9vcHMsCisJCSAgICBzdHJ1Y3Qg
Z250dGFiX21hcF9ncmFudF9yZWYgKmttYXBfb3BzLAogCQkgICAgc3RydWN0IHBhZ2UgKipw
YWdlcywgdW5zaWduZWQgaW50IGNvdW50KTsKIGludCBnbnR0YWJfdW5tYXBfcmVmcyhzdHJ1
Y3QgZ250dGFiX3VubWFwX2dyYW50X3JlZiAqdW5tYXBfb3BzLAogCQkgICAgICBzdHJ1Y3Qg
cGFnZSAqKnBhZ2VzLCB1bnNpZ25lZCBpbnQgY291bnQpOwotLSAKMS43LjYuNAoK
--------------050905090709060000090701
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--------------050905090709060000090701--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:30:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:30:43 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLiV-0003H3-1b
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLiB-0007Qi-If; Fri, 18 Nov 2011 02:30:23 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLi5-0007Pg-F5
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:30:17 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1321612214!4036484!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2727 invoked from network); 18 Nov 2011 10:30:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:30:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9005502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:30:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 10:30:14 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 18 Nov 2011 10:30:13 +0000
In-Reply-To: <20111117204553.GD26847@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
	<1321561021.8866.12.camel@dagon.hellion.org.uk>
	<20111117204553.GD26847@hmsreliant.think-freely.org>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321612213.3664.293.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-17 at 20:45 +0000, Neil Horman wrote:
> On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> > On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > > 
> > > > What are the actual constraints here? The skb is used as a handle to the
> > > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > > those which are passed to the hypervisor (effectively the same as
> > > > passing those addresses to the h/w for DMA).
> > > > 
> > > > Which parts of the skb are expected/allowed to not remain stable?
> > > > 
> > > > (Appologies if the above seems naive, I seem to have missed the
> > > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > > 
> > > Its ok, this is the most accurate description from the previous threads on the
> > > subject:
> > > 2
> > > 
> > > The basic problem boils down the notion that some drivers, when they receive an
> > > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > > result may do things like add the skb to a list, or otherwise store stateful
> > > data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> > > holds a reference to the skb, and make make changes without serializing them
> > > against the driver.  So we have to flag those drivers which preform these kinds
> > > of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> > > an skb, but it does place a pointer to the skb in a data structure here:
> > > 
> > > np->tx_skbs[id].skb = skb;
> > > 
> > > Which then gets handed off to the hypervisior.  Since the hypervisor now has
> > > access to that skb pointer, and we can't be sure (from the guest perspective),
> > > what it does with that information, it would be better to be safe by disallowing
> > > shared skbs in this path.
> > 
> > The skb pointer itself doesn't get given to the backend/hypervisor. The
> > page which skb->data refers to is granted to the backend domain, as are
> > the pages in the frags.
> > 
> > I think we only need to be sure that the frontend doesn't rely on
> > anything in the skb itself, right? Does skb->data or shinfo count from
> > that perspective?
> shinfo is definately a problem, as other devices may make modifications to it.
> skb->data is probably safer, but is also potentially suspect (for instance if
> another device appends an additional header to the data for instance)

A device is allowed to rely on these things being stable while in its
start_xmit, right? (otherwise I don't see how any device can ever
cope...).

netfront only uses shinfo and ->data during start_xmit in order to
create the necessary grant reference (which can be thought of as a DMA
address passed to the virtual hardware). The only use of the stashed skb
pointer outside of this are to dev_kfree_skb on tx completion (from
either tx_buf_gc (normal completion) or release_tx_buf ("hardware"
reset).

Ian.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:30:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:30:43 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLiV-0003H3-1b
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLiB-0007Qi-If; Fri, 18 Nov 2011 02:30:23 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLi5-0007Pg-F5
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:30:17 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1321612214!4036484!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2727 invoked from network); 18 Nov 2011 10:30:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:30:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9005502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:30:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 10:30:14 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 18 Nov 2011 10:30:13 +0000
In-Reply-To: <20111117204553.GD26847@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
	<1321561021.8866.12.camel@dagon.hellion.org.uk>
	<20111117204553.GD26847@hmsreliant.think-freely.org>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321612213.3664.293.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-17 at 20:45 +0000, Neil Horman wrote:
> On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> > On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > > 
> > > > What are the actual constraints here? The skb is used as a handle to the
> > > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > > those which are passed to the hypervisor (effectively the same as
> > > > passing those addresses to the h/w for DMA).
> > > > 
> > > > Which parts of the skb are expected/allowed to not remain stable?
> > > > 
> > > > (Appologies if the above seems naive, I seem to have missed the
> > > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > > 
> > > Its ok, this is the most accurate description from the previous threads on the
> > > subject:
> > > 2
> > > 
> > > The basic problem boils down the notion that some drivers, when they receive an
> > > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > > result may do things like add the skb to a list, or otherwise store stateful
> > > data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> > > holds a reference to the skb, and make make changes without serializing them
> > > against the driver.  So we have to flag those drivers which preform these kinds
> > > of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> > > an skb, but it does place a pointer to the skb in a data structure here:
> > > 
> > > np->tx_skbs[id].skb = skb;
> > > 
> > > Which then gets handed off to the hypervisior.  Since the hypervisor now has
> > > access to that skb pointer, and we can't be sure (from the guest perspective),
> > > what it does with that information, it would be better to be safe by disallowing
> > > shared skbs in this path.
> > 
> > The skb pointer itself doesn't get given to the backend/hypervisor. The
> > page which skb->data refers to is granted to the backend domain, as are
> > the pages in the frags.
> > 
> > I think we only need to be sure that the frontend doesn't rely on
> > anything in the skb itself, right? Does skb->data or shinfo count from
> > that perspective?
> shinfo is definately a problem, as other devices may make modifications to it.
> skb->data is probably safer, but is also potentially suspect (for instance if
> another device appends an additional header to the data for instance)

A device is allowed to rely on these things being stable while in its
start_xmit, right? (otherwise I don't see how any device can ever
cope...).

netfront only uses shinfo and ->data during start_xmit in order to
create the necessary grant reference (which can be thought of as a DMA
address passed to the virtual hardware). The only use of the stashed skb
pointer outside of this are to dev_kfree_skb on tx completion (from
either tx_buf_gc (normal completion) or release_tx_buf ("hardware"
reset).

Ian.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:32:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:32:26 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLkA-0003HG-QW
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:32:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLjp-0007uT-7N; Fri, 18 Nov 2011 02:32:06 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLjJ-0007ks-JD
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:31:34 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321612289!3650999!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26148 invoked from network); 18 Nov 2011 10:31:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:31:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="19219713"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:31:29 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:31:28 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321612139@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:28:59 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Add configuration options to selectively
 disable S3 and S4 (V2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds the ability to selectively disable the S3 and S4 ACPI
power states for HVM guests.

Since there is a general move towards retiring the hvm_info_table structure,
the first patch moves the acpi_enabled flag out of the hvm_info_table and into
a xenstore key (platform/acpi).
The second patch then introduces the acpi_s3 and acpi_s4 configuration
parameters to the xl config file (default=1). These result in population of
new platform/acpi_s3 and platform/acpi_s4 xenstore keys. hvmloader then reads
these keys to determine whether or not to include SSDTs containing the
_S3 and _S4 packages respectively.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:32:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:32:26 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLkA-0003HG-QW
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:32:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLjp-0007uT-7N; Fri, 18 Nov 2011 02:32:06 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLjJ-0007ks-JD
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:31:34 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321612289!3650999!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26148 invoked from network); 18 Nov 2011 10:31:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:31:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="19219713"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:31:29 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:31:28 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321612139@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:28:59 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Add configuration options to selectively
 disable S3 and S4 (V2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds the ability to selectively disable the S3 and S4 ACPI
power states for HVM guests.

Since there is a general move towards retiring the hvm_info_table structure,
the first patch moves the acpi_enabled flag out of the hvm_info_table and into
a xenstore key (platform/acpi).
The second patch then introduces the acpi_s3 and acpi_s4 configuration
parameters to the xl config file (default=1). These result in population of
new platform/acpi_s3 and platform/acpi_s4 xenstore keys. hvmloader then reads
these keys to determine whether or not to include SSDTs containing the
_S3 and _S4 packages respectively.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:33:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:33:42 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLlO-0003HT-14
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLl5-0008J0-9h; Fri, 18 Nov 2011 02:33:23 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLjK-0007l2-6H
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:31:34 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321612258!44448916!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22996 invoked from network); 18 Nov 2011 10:30:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="171120835"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:31:29 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:31:29 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: d22ef0f60497772ac17b086e7f589434a2344fe8
Message-ID: <d22ef0f60497772ac17b.1321612140@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321612139@cosworth.uk.xensource.com>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:29:00 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Move acpi_enabled out of hvm_info_table
	into xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321612132 0
# Node ID d22ef0f60497772ac17b086e7f589434a2344fe8
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Move acpi_enabled out of hvm_info_table into xenstore

Since hvmloader has a xentore client, use a platform key in xenstore
to indicate whether ACPI is enabled or not rather than the shared
hvm_info_table structure.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r dbdc840f8f62 -r d22ef0f60497 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:28:52 2011 +0000
@@ -423,6 +423,7 @@ int main(void)
     const struct bios_config *bios;
     int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
     uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
+    int acpi_enabled;
 
     /* Initialise hypercall stubs with RET, rendering them no-ops. */
     memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
@@ -506,7 +507,9 @@ int main(void)
                                              option_rom_phys_addr);
     }
 
-    if ( hvm_info->acpi_enabled )
+    acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
+
+    if ( acpi_enabled )
     {
         struct xen_hvm_param p = {
             .domid = DOMID_SELF,
diff -r dbdc840f8f62 -r d22ef0f60497 tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxc/xc_hvm_build.c	Fri Nov 18 10:28:52 2011 +0000
@@ -67,7 +67,6 @@ static void build_hvm_info(void *hvm_inf
     hvm_info->length = sizeof(struct hvm_info_table);
 
     /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->acpi_enabled = 1;
     hvm_info->apic_mode = 1;
     hvm_info->nr_vcpus = 1;
     memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
diff -r dbdc840f8f62 -r d22ef0f60497 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:28:52 2011 +0000
@@ -188,6 +188,11 @@ int libxl__domain_build(libxl__gc *gc,
         vments[3] = "hvm";
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+
+        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents[0] = "platform/acpi";
+        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         ret = libxl__build_pv(gc, domid, info, state);
diff -r dbdc840f8f62 -r d22ef0f60497 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Nov 18 10:28:52 2011 +0000
@@ -248,7 +248,6 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = info->u.hvm.acpi;
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
diff -r dbdc840f8f62 -r d22ef0f60497 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Fri Nov 18 10:28:52 2011 +0000
@@ -996,7 +996,6 @@ static PyObject *pyxc_hvm_build(XcObject
     if ( va_map == NULL )
         return PyErr_SetFromErrno(xc_error_obj);
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = acpi;
     va_hvm->apic_mode    = apic;
     va_hvm->nr_vcpus     = vcpus;
     memcpy(va_hvm->vcpu_online, vcpu_avail, sizeof(vcpu_avail));
diff -r dbdc840f8f62 -r d22ef0f60497 xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/public/hvm/hvm_info_table.h	Fri Nov 18 10:28:52 2011 +0000
@@ -37,9 +37,6 @@ struct hvm_info_table {
     uint32_t    length;
     uint8_t     checksum;
 
-    /* Should firmware build ACPI tables? */
-    uint8_t     acpi_enabled;
-
     /* Should firmware build APIC descriptors (APIC MADT / MP BIOS)? */
     uint8_t     apic_mode;
 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:33:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:33:42 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLlO-0003HT-14
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLl5-0008J0-9h; Fri, 18 Nov 2011 02:33:23 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLjK-0007l2-6H
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:31:34 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321612258!44448916!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22996 invoked from network); 18 Nov 2011 10:30:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="171120835"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:31:29 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:31:29 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: d22ef0f60497772ac17b086e7f589434a2344fe8
Message-ID: <d22ef0f60497772ac17b.1321612140@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321612139@cosworth.uk.xensource.com>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:29:00 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Move acpi_enabled out of hvm_info_table
	into xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321612132 0
# Node ID d22ef0f60497772ac17b086e7f589434a2344fe8
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Move acpi_enabled out of hvm_info_table into xenstore

Since hvmloader has a xentore client, use a platform key in xenstore
to indicate whether ACPI is enabled or not rather than the shared
hvm_info_table structure.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r dbdc840f8f62 -r d22ef0f60497 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:28:52 2011 +0000
@@ -423,6 +423,7 @@ int main(void)
     const struct bios_config *bios;
     int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
     uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
+    int acpi_enabled;
 
     /* Initialise hypercall stubs with RET, rendering them no-ops. */
     memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
@@ -506,7 +507,9 @@ int main(void)
                                              option_rom_phys_addr);
     }
 
-    if ( hvm_info->acpi_enabled )
+    acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
+
+    if ( acpi_enabled )
     {
         struct xen_hvm_param p = {
             .domid = DOMID_SELF,
diff -r dbdc840f8f62 -r d22ef0f60497 tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxc/xc_hvm_build.c	Fri Nov 18 10:28:52 2011 +0000
@@ -67,7 +67,6 @@ static void build_hvm_info(void *hvm_inf
     hvm_info->length = sizeof(struct hvm_info_table);
 
     /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->acpi_enabled = 1;
     hvm_info->apic_mode = 1;
     hvm_info->nr_vcpus = 1;
     memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
diff -r dbdc840f8f62 -r d22ef0f60497 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:28:52 2011 +0000
@@ -188,6 +188,11 @@ int libxl__domain_build(libxl__gc *gc,
         vments[3] = "hvm";
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+
+        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents[0] = "platform/acpi";
+        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         ret = libxl__build_pv(gc, domid, info, state);
diff -r dbdc840f8f62 -r d22ef0f60497 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Nov 18 10:28:52 2011 +0000
@@ -248,7 +248,6 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = info->u.hvm.acpi;
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
diff -r dbdc840f8f62 -r d22ef0f60497 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Fri Nov 18 10:28:52 2011 +0000
@@ -996,7 +996,6 @@ static PyObject *pyxc_hvm_build(XcObject
     if ( va_map == NULL )
         return PyErr_SetFromErrno(xc_error_obj);
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = acpi;
     va_hvm->apic_mode    = apic;
     va_hvm->nr_vcpus     = vcpus;
     memcpy(va_hvm->vcpu_online, vcpu_avail, sizeof(vcpu_avail));
diff -r dbdc840f8f62 -r d22ef0f60497 xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/public/hvm/hvm_info_table.h	Fri Nov 18 10:28:52 2011 +0000
@@ -37,9 +37,6 @@ struct hvm_info_table {
     uint32_t    length;
     uint8_t     checksum;
 
-    /* Should firmware build ACPI tables? */
-    uint8_t     acpi_enabled;
-
     /* Should firmware build APIC descriptors (APIC MADT / MP BIOS)? */
     uint8_t     apic_mode;
 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:34:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:34:28 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLm8-0003Hg-Jk
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:34:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLlp-0000Ej-L6; Fri, 18 Nov 2011 02:34:09 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLjK-0007l6-Dw
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:31:35 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321612289!3650999!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26190 invoked from network); 18 Nov 2011 10:31:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:31:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="19219714"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:31:30 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:31:30 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 66bdcb90560f1b996fa34c549834b479a5157cd3
Message-ID: <66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321612139@cosworth.uk.xensource.com>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:29:01 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] Add configuration options to selectively
 disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321612133 0
# Node ID 66bdcb90560f1b996fa34c549834b479a5157cd3
# Parent  d22ef0f60497772ac17b086e7f589434a2344fe8
Add configuration options to selectively disable S3 and S4 ACPI power states.

Introduce acpi_s3 and acpi_s4 configuration options (default=1). The S3 and S4
packages are moved into separate SSDTs and their inclusion is controlled by the
new configuration options.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/Makefile
--- a/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:28:53 2011 +0000
@@ -26,7 +26,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 vpath iasl $(PATH)
 all: acpi.a
 
-ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
+ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 	iasl -vs -p $* -tc $<
 	sed -e 's/AmlCode/$*/g' $*.hex >$@
 	rm -f $*.hex $*.aml
@@ -57,7 +57,7 @@ iasl:
 	@echo 
 	@exit 1
 
-build.o: ssdt_pm.h ssdt_tpm.h
+build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
 
 acpi.a: $(OBJS)
 	$(AR) rc $@ $(OBJS)
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:28:53 2011 +0000
@@ -396,6 +396,8 @@ struct acpi_config {
     int dsdt_anycpu_len;
     unsigned char *dsdt_15cpu;
     int dsdt_15cpu_len;
+    int ssdt_s3_enabled;
+    int ssdt_s4_enabled;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:28:53 2011 +0000
@@ -17,6 +17,9 @@
  */
 
 #include "acpi2_0.h"
+#include "ssdt_s3.h"
+#include "ssdt_s4.h"
+#include "ssdt_s5.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
 #include "../config.h"
@@ -196,7 +199,8 @@ static struct acpi_20_waet *construct_wa
 }
 
 static int construct_secondary_tables(unsigned long *table_ptrs,
-                                      struct acpi_info *info)
+                                      struct acpi_info *info,
+                                      struct acpi_config *config)
 {
     int nr_tables = 0;
     struct acpi_20_madt *madt;
@@ -235,6 +239,22 @@ static int construct_secondary_tables(un
         table_ptrs[nr_tables++] = (unsigned long)ssdt;
     }
 
+    if ( config->ssdt_s3_enabled )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s3), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    }
+
+    if ( config->ssdt_s4_enabled )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s4), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    }
+
     /* TPM TCPA and SSDT. */
     tis_hdr = (uint16_t *)0xFED40F00;
     if ( (tis_hdr[0] == tis_signature[0]) &&
@@ -353,7 +373,8 @@ void acpi_build_tables(struct acpi_confi
                  offsetof(struct acpi_header, checksum),
                  sizeof(struct acpi_20_fadt));
 
-    nr_secondaries = construct_secondary_tables(secondary_tables, acpi_info);
+    nr_secondaries = construct_secondary_tables(secondary_tables, acpi_info,
+                                                config);
     if ( nr_secondaries < 0 )
         goto oom;
 
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:28:53 2011 +0000
@@ -27,24 +27,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
     Name (\APCL, 0x00010000)
     Name (\PUID, 0x00)
 
-    /*
-     * S3 (suspend-to-ram), S4 (suspend-to-disc) and S5 (power-off) type codes:
-     * must match piix4 emulation.
-     */
-    Name (\_S3, Package (0x04)
-    {
-        0x01,  /* PM1a_CNT.SLP_TYP */
-        0x01,  /* PM1b_CNT.SLP_TYP */
-        0x0,   /* reserved */
-        0x0    /* reserved */
-    })
-    Name (\_S4, Package (0x04)
-    {
-        0x00,  /* PM1a_CNT.SLP_TYP */
-        0x00,  /* PM1b_CNT.SLP_TYP */
-        0x00,  /* reserved */
-        0x00   /* reserved */
-    })
+    /* _S3 and _S4 are in separate SSDTs */
     Name (\_S5, Package (0x04)
     {
         0x00,  /* PM1a_CNT.SLP_TYP */
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/ssdt_s3.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s3.asl	Fri Nov 18 10:28:53 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s3.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S3.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S3, Package (0x04)
+    {
+        0x01,  /* PM1a_CNT.SLP_TYP */
+        0x01,  /* PM1b_CNT.SLP_TYP */
+        0x0,   /* reserved */
+        0x0    /* reserved */
+    })
+}
+
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/ssdt_s4.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s4.asl	Fri Nov 18 10:28:53 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s4.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S4.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S4, Package (0x04)
+    {
+        0x00,  /* PM1a_CNT.SLP_TYP */
+        0x00,  /* PM1b_CNT.SLP_TYP */
+        0x00,  /* reserved */
+        0x00   /* reserved */
+    })
+}
+
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/config.h	Fri Nov 18 10:28:53 2011 +0000
@@ -27,7 +27,7 @@ struct bios_config {
 
     void (*e820_setup)(void);
 
-    void (*acpi_build_tables)(void);
+    void (*acpi_build_tables)(int, int);
     void (*create_mp_tables)(void);
     void (*create_smbios_tables)(void);
     void (*create_pir_tables)(void);
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:28:53 2011 +0000
@@ -516,11 +516,17 @@ int main(void)
             .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
             .value = 1,
         };
+        int s3_enabled, s4_enabled;
+
+        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1);
+        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1);
 
         if ( bios->acpi_build_tables )
         {
-            printf("Loading ACPI ...\n");
-            bios->acpi_build_tables();
+            printf("Loading ACPI (S3=%s S4=%s) ...\n",
+                   (s3_enabled) ? "ON" : "OFF",
+                   (s4_enabled) ? "ON" : "OFF");
+            bios->acpi_build_tables(s3_enabled, s4_enabled);
         }
 
         acpi_enable_sci();
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/rombios.c
--- a/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:28:53 2011 +0000
@@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
     *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) = -checksum;
 }
 
-static void rombios_acpi_build_tables(void)
+static void rombios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     struct acpi_config config = {
         .dsdt_anycpu = dsdt_anycpu,
         .dsdt_anycpu_len = dsdt_anycpu_len,
         .dsdt_15cpu = dsdt_15cpu,
         .dsdt_15cpu_len = dsdt_15cpu_len,
+        .ssdt_s3_enabled = s3_enabled,
+        .ssdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/seabios.c
--- a/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:28:53 2011 +0000
@@ -91,7 +91,7 @@ static void add_table(uint32_t t)
     info->tables_nr++;
 }
 
-static void seabios_acpi_build_tables(void)
+static void seabios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     uint32_t rsdp = (uint32_t)scratch_alloc(sizeof(struct acpi_20_rsdp), 0);
     struct acpi_config config = {
@@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
         .dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
         .dsdt_15cpu = NULL,
         .dsdt_15cpu_len = 0,
+        .ssdt_s3_enabled = s3_enabled,
+        .ssdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, rsdp);
diff -r d22ef0f60497 -r 66bdcb90560f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:28:53 2011 +0000
@@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
+        b_info->u.hvm.acpi_s3 = 1;
+        b_info->u.hvm.acpi_s4 = 1;
         b_info->u.hvm.nx = 1;
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
@@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[2] = "platform/acpi_s3";
+        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[4] = "platform/acpi_s4";
+        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r d22ef0f60497 -r 66bdcb90560f tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Nov 18 10:28:53 2011 +0000
@@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
+                                       ("acpi_s3", bool),
+                                       ("acpi_s4", bool),
                                        ("nx", bool),
                                        ("viridian", bool),
                                        ("timeoffset", string),
diff -r d22ef0f60497 -r 66bdcb90560f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:28:53 2011 +0000
@@ -683,6 +683,10 @@ static void parse_config_data(const char
             b_info->u.hvm.apic = l;
         if (!xlu_cfg_get_long (config, "acpi", &l))
             b_info->u.hvm.acpi = l;
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+            b_info->u.hvm.acpi_s3 = l;
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+            b_info->u.hvm.acpi_s4 = l;
         if (!xlu_cfg_get_long (config, "nx", &l))
             b_info->u.hvm.nx = l;
         if (!xlu_cfg_get_long (config, "viridian", &l))

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:34:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:34:28 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLm8-0003Hg-Jk
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:34:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLlp-0000Ej-L6; Fri, 18 Nov 2011 02:34:09 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLjK-0007l6-Dw
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:31:35 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321612289!3650999!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26190 invoked from network); 18 Nov 2011 10:31:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:31:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="19219714"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:31:30 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:31:30 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 66bdcb90560f1b996fa34c549834b479a5157cd3
Message-ID: <66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321612139@cosworth.uk.xensource.com>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:29:01 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] Add configuration options to selectively
 disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321612133 0
# Node ID 66bdcb90560f1b996fa34c549834b479a5157cd3
# Parent  d22ef0f60497772ac17b086e7f589434a2344fe8
Add configuration options to selectively disable S3 and S4 ACPI power states.

Introduce acpi_s3 and acpi_s4 configuration options (default=1). The S3 and S4
packages are moved into separate SSDTs and their inclusion is controlled by the
new configuration options.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/Makefile
--- a/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:28:53 2011 +0000
@@ -26,7 +26,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 vpath iasl $(PATH)
 all: acpi.a
 
-ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
+ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 	iasl -vs -p $* -tc $<
 	sed -e 's/AmlCode/$*/g' $*.hex >$@
 	rm -f $*.hex $*.aml
@@ -57,7 +57,7 @@ iasl:
 	@echo 
 	@exit 1
 
-build.o: ssdt_pm.h ssdt_tpm.h
+build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
 
 acpi.a: $(OBJS)
 	$(AR) rc $@ $(OBJS)
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:28:53 2011 +0000
@@ -396,6 +396,8 @@ struct acpi_config {
     int dsdt_anycpu_len;
     unsigned char *dsdt_15cpu;
     int dsdt_15cpu_len;
+    int ssdt_s3_enabled;
+    int ssdt_s4_enabled;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:28:53 2011 +0000
@@ -17,6 +17,9 @@
  */
 
 #include "acpi2_0.h"
+#include "ssdt_s3.h"
+#include "ssdt_s4.h"
+#include "ssdt_s5.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
 #include "../config.h"
@@ -196,7 +199,8 @@ static struct acpi_20_waet *construct_wa
 }
 
 static int construct_secondary_tables(unsigned long *table_ptrs,
-                                      struct acpi_info *info)
+                                      struct acpi_info *info,
+                                      struct acpi_config *config)
 {
     int nr_tables = 0;
     struct acpi_20_madt *madt;
@@ -235,6 +239,22 @@ static int construct_secondary_tables(un
         table_ptrs[nr_tables++] = (unsigned long)ssdt;
     }
 
+    if ( config->ssdt_s3_enabled )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s3), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    }
+
+    if ( config->ssdt_s4_enabled )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s4), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    }
+
     /* TPM TCPA and SSDT. */
     tis_hdr = (uint16_t *)0xFED40F00;
     if ( (tis_hdr[0] == tis_signature[0]) &&
@@ -353,7 +373,8 @@ void acpi_build_tables(struct acpi_confi
                  offsetof(struct acpi_header, checksum),
                  sizeof(struct acpi_20_fadt));
 
-    nr_secondaries = construct_secondary_tables(secondary_tables, acpi_info);
+    nr_secondaries = construct_secondary_tables(secondary_tables, acpi_info,
+                                                config);
     if ( nr_secondaries < 0 )
         goto oom;
 
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:28:53 2011 +0000
@@ -27,24 +27,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
     Name (\APCL, 0x00010000)
     Name (\PUID, 0x00)
 
-    /*
-     * S3 (suspend-to-ram), S4 (suspend-to-disc) and S5 (power-off) type codes:
-     * must match piix4 emulation.
-     */
-    Name (\_S3, Package (0x04)
-    {
-        0x01,  /* PM1a_CNT.SLP_TYP */
-        0x01,  /* PM1b_CNT.SLP_TYP */
-        0x0,   /* reserved */
-        0x0    /* reserved */
-    })
-    Name (\_S4, Package (0x04)
-    {
-        0x00,  /* PM1a_CNT.SLP_TYP */
-        0x00,  /* PM1b_CNT.SLP_TYP */
-        0x00,  /* reserved */
-        0x00   /* reserved */
-    })
+    /* _S3 and _S4 are in separate SSDTs */
     Name (\_S5, Package (0x04)
     {
         0x00,  /* PM1a_CNT.SLP_TYP */
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/ssdt_s3.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s3.asl	Fri Nov 18 10:28:53 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s3.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S3.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S3, Package (0x04)
+    {
+        0x01,  /* PM1a_CNT.SLP_TYP */
+        0x01,  /* PM1b_CNT.SLP_TYP */
+        0x0,   /* reserved */
+        0x0    /* reserved */
+    })
+}
+
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/acpi/ssdt_s4.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s4.asl	Fri Nov 18 10:28:53 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s4.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S4.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S4, Package (0x04)
+    {
+        0x00,  /* PM1a_CNT.SLP_TYP */
+        0x00,  /* PM1b_CNT.SLP_TYP */
+        0x00,  /* reserved */
+        0x00   /* reserved */
+    })
+}
+
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/config.h	Fri Nov 18 10:28:53 2011 +0000
@@ -27,7 +27,7 @@ struct bios_config {
 
     void (*e820_setup)(void);
 
-    void (*acpi_build_tables)(void);
+    void (*acpi_build_tables)(int, int);
     void (*create_mp_tables)(void);
     void (*create_smbios_tables)(void);
     void (*create_pir_tables)(void);
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:28:53 2011 +0000
@@ -516,11 +516,17 @@ int main(void)
             .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
             .value = 1,
         };
+        int s3_enabled, s4_enabled;
+
+        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1);
+        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1);
 
         if ( bios->acpi_build_tables )
         {
-            printf("Loading ACPI ...\n");
-            bios->acpi_build_tables();
+            printf("Loading ACPI (S3=%s S4=%s) ...\n",
+                   (s3_enabled) ? "ON" : "OFF",
+                   (s4_enabled) ? "ON" : "OFF");
+            bios->acpi_build_tables(s3_enabled, s4_enabled);
         }
 
         acpi_enable_sci();
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/rombios.c
--- a/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:28:53 2011 +0000
@@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
     *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) = -checksum;
 }
 
-static void rombios_acpi_build_tables(void)
+static void rombios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     struct acpi_config config = {
         .dsdt_anycpu = dsdt_anycpu,
         .dsdt_anycpu_len = dsdt_anycpu_len,
         .dsdt_15cpu = dsdt_15cpu,
         .dsdt_15cpu_len = dsdt_15cpu_len,
+        .ssdt_s3_enabled = s3_enabled,
+        .ssdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/seabios.c
--- a/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:28:53 2011 +0000
@@ -91,7 +91,7 @@ static void add_table(uint32_t t)
     info->tables_nr++;
 }
 
-static void seabios_acpi_build_tables(void)
+static void seabios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     uint32_t rsdp = (uint32_t)scratch_alloc(sizeof(struct acpi_20_rsdp), 0);
     struct acpi_config config = {
@@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
         .dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
         .dsdt_15cpu = NULL,
         .dsdt_15cpu_len = 0,
+        .ssdt_s3_enabled = s3_enabled,
+        .ssdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, rsdp);
diff -r d22ef0f60497 -r 66bdcb90560f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:28:53 2011 +0000
@@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
+        b_info->u.hvm.acpi_s3 = 1;
+        b_info->u.hvm.acpi_s4 = 1;
         b_info->u.hvm.nx = 1;
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
@@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[2] = "platform/acpi_s3";
+        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[4] = "platform/acpi_s4";
+        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r d22ef0f60497 -r 66bdcb90560f tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Nov 18 10:28:53 2011 +0000
@@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
+                                       ("acpi_s3", bool),
+                                       ("acpi_s4", bool),
                                        ("nx", bool),
                                        ("viridian", bool),
                                        ("timeoffset", string),
diff -r d22ef0f60497 -r 66bdcb90560f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:28:52 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:28:53 2011 +0000
@@ -683,6 +683,10 @@ static void parse_config_data(const char
             b_info->u.hvm.apic = l;
         if (!xlu_cfg_get_long (config, "acpi", &l))
             b_info->u.hvm.acpi = l;
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+            b_info->u.hvm.acpi_s3 = l;
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+            b_info->u.hvm.acpi_s4 = l;
         if (!xlu_cfg_get_long (config, "nx", &l))
             b_info->u.hvm.nx = l;
         if (!xlu_cfg_get_long (config, "viridian", &l))

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:35:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:35:19 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLmw-0003Ht-WF
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLme-0000c3-DB; Fri, 18 Nov 2011 02:35:00 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLkr-0008EG-11
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:33:09 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1321612385!3670111!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2630 invoked from network); 18 Nov 2011 10:33:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:33:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9005591"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:33:05 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 18 Nov 2011
	10:33:05 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 18 Nov 2011 10:33:05 +0000
Thread-Topic: [PATCH 2 of 2] Add configuration options to selectively
	disable S3 and S4 ACPI power states
Thread-Index: Acyl3TyI9upe11rEQbO8zZC4RKOo5wAACb8A
Message-ID: <291EDFCB1E9E224A99088639C4762022B4543AB749@LONPMAILBOX01.citrite.net>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
	<66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
In-Reply-To: <66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 
Subject: [Xen-devel] RE: [PATCH 2 of 2] Add configuration options to
 selectively disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry, this has one line of extraneous noise in. I will resend.

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 18 November 2011 10:29
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH 2 of 2] Add configuration options to selectively
> disable S3 and S4 ACPI power states
>=20
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1321612133 0 #
> Node ID 66bdcb90560f1b996fa34c549834b479a5157cd3
> # Parent  d22ef0f60497772ac17b086e7f589434a2344fe8
> Add configuration options to selectively disable S3 and S4 ACPI
> power states.
>=20
> Introduce acpi_s3 and acpi_s4 configuration options (default=3D1). The
> S3 and S4 packages are moved into separate SSDTs and their inclusion
> is controlled by the new configuration options.
>=20
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>=20
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/Makefile
> --- a/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:28:52
> 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -26,7 +26,7 @@ CFLAGS +=3D $(CFLAGS_xeninclude)  vpath iasl $(PATH)
>  all: acpi.a
>=20
> -ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
> +ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
>  	iasl -vs -p $* -tc $<
>  	sed -e 's/AmlCode/$*/g' $*.hex >$@
>  	rm -f $*.hex $*.aml
> @@ -57,7 +57,7 @@ iasl:
>  	@echo
>  	@exit 1
>=20
> -build.o: ssdt_pm.h ssdt_tpm.h
> +build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
>=20
>  acpi.a: $(OBJS)
>  	$(AR) rc $@ $(OBJS)
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/acpi2_0.h
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:28:52
> 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -396,6 +396,8 @@ struct acpi_config {
>      int dsdt_anycpu_len;
>      unsigned char *dsdt_15cpu;
>      int dsdt_15cpu_len;
> +    int ssdt_s3_enabled;
> +    int ssdt_s4_enabled;
>  };
>=20
>  void acpi_build_tables(struct acpi_config *config, unsigned int
> physical); diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:28:52
> 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -17,6 +17,9 @@
>   */
>=20
>  #include "acpi2_0.h"
> +#include "ssdt_s3.h"
> +#include "ssdt_s4.h"
> +#include "ssdt_s5.h"
>  #include "ssdt_tpm.h"
>  #include "ssdt_pm.h"
>  #include "../config.h"
> @@ -196,7 +199,8 @@ static struct acpi_20_waet *construct_wa  }
>=20
>  static int construct_secondary_tables(unsigned long *table_ptrs,
> -                                      struct acpi_info *info)
> +                                      struct acpi_info *info,
> +                                      struct acpi_config *config)
>  {
>      int nr_tables =3D 0;
>      struct acpi_20_madt *madt;
> @@ -235,6 +239,22 @@ static int construct_secondary_tables(un
>          table_ptrs[nr_tables++] =3D (unsigned long)ssdt;
>      }
>=20
> +    if ( config->ssdt_s3_enabled )
> +    {
> +        ssdt =3D mem_alloc(sizeof(ssdt_s3), 16);
> +        if (!ssdt) return -1;
> +        memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
> +        table_ptrs[nr_tables++] =3D (unsigned long)ssdt;
> +    }
> +
> +    if ( config->ssdt_s4_enabled )
> +    {
> +        ssdt =3D mem_alloc(sizeof(ssdt_s4), 16);
> +        if (!ssdt) return -1;
> +        memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
> +        table_ptrs[nr_tables++] =3D (unsigned long)ssdt;
> +    }
> +
>      /* TPM TCPA and SSDT. */
>      tis_hdr =3D (uint16_t *)0xFED40F00;
>      if ( (tis_hdr[0] =3D=3D tis_signature[0]) && @@ -353,7 +373,8 @@
> void acpi_build_tables(struct acpi_confi
>                   offsetof(struct acpi_header, checksum),
>                   sizeof(struct acpi_20_fadt));
>=20
> -    nr_secondaries =3D construct_secondary_tables(secondary_tables,
> acpi_info);
> +    nr_secondaries =3D construct_secondary_tables(secondary_tables,
> acpi_info,
> +                                                config);
>      if ( nr_secondaries < 0 )
>          goto oom;
>=20
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/dsdt.asl
> --- a/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:28:52
> 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -27,24 +27,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>      Name (\APCL, 0x00010000)
>      Name (\PUID, 0x00)
>=20
> -    /*
> -     * S3 (suspend-to-ram), S4 (suspend-to-disc) and S5 (power-off)
> type codes:
> -     * must match piix4 emulation.
> -     */
> -    Name (\_S3, Package (0x04)
> -    {
> -        0x01,  /* PM1a_CNT.SLP_TYP */
> -        0x01,  /* PM1b_CNT.SLP_TYP */
> -        0x0,   /* reserved */
> -        0x0    /* reserved */
> -    })
> -    Name (\_S4, Package (0x04)
> -    {
> -        0x00,  /* PM1a_CNT.SLP_TYP */
> -        0x00,  /* PM1b_CNT.SLP_TYP */
> -        0x00,  /* reserved */
> -        0x00   /* reserved */
> -    })
> +    /* _S3 and _S4 are in separate SSDTs */
>      Name (\_S5, Package (0x04)
>      {
>          0x00,  /* PM1a_CNT.SLP_TYP */
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/ssdt_s3.asl
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/hvmloader/acpi/ssdt_s3.asl	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -0,0 +1,32 @@
> +/*
> + * ssdt_s3.asl
> + *
> + * Copyright (c) 2011  Citrix Systems, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License as
> published by
> + * the Free Software Foundation; either version 2 of the License,
> or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-
> 1307
> +USA  */
> +
> +DefinitionBlock ("SSDT_S3.aml", "SSDT", 2, "Xen", "HVM", 0) {
> +    /* Must match piix emulation */
> +    Name (\_S3, Package (0x04)
> +    {
> +        0x01,  /* PM1a_CNT.SLP_TYP */
> +        0x01,  /* PM1b_CNT.SLP_TYP */
> +        0x0,   /* reserved */
> +        0x0    /* reserved */
> +    })
> +}
> +
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/ssdt_s4.asl
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/hvmloader/acpi/ssdt_s4.asl	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -0,0 +1,32 @@
> +/*
> + * ssdt_s4.asl
> + *
> + * Copyright (c) 2011  Citrix Systems, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License as
> published by
> + * the Free Software Foundation; either version 2 of the License,
> or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-
> 1307
> +USA  */
> +
> +DefinitionBlock ("SSDT_S4.aml", "SSDT", 2, "Xen", "HVM", 0) {
> +    /* Must match piix emulation */
> +    Name (\_S4, Package (0x04)
> +    {
> +        0x00,  /* PM1a_CNT.SLP_TYP */
> +        0x00,  /* PM1b_CNT.SLP_TYP */
> +        0x00,  /* reserved */
> +        0x00   /* reserved */
> +    })
> +}
> +
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h	Fri Nov 18 10:28:52 2011
> +0000
> +++ b/tools/firmware/hvmloader/config.h	Fri Nov 18 10:28:53 2011
> +0000
> @@ -27,7 +27,7 @@ struct bios_config {
>=20
>      void (*e820_setup)(void);
>=20
> -    void (*acpi_build_tables)(void);
> +    void (*acpi_build_tables)(int, int);
>      void (*create_mp_tables)(void);
>      void (*create_smbios_tables)(void);
>      void (*create_pir_tables)(void);
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:28:52
> 2011 +0000
> +++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -516,11 +516,17 @@ int main(void)
>              .index =3D HVM_PARAM_ACPI_IOPORTS_LOCATION,
>              .value =3D 1,
>          };
> +        int s3_enabled, s4_enabled;
> +
> +        s3_enabled =3D !strncmp(xenstore_read("platform/acpi_s3",
> "1"), "1", 1);
> +        s4_enabled =3D !strncmp(xenstore_read("platform/acpi_s4",
> "1"),
> + "1", 1);
>=20
>          if ( bios->acpi_build_tables )
>          {
> -            printf("Loading ACPI ...\n");
> -            bios->acpi_build_tables();
> +            printf("Loading ACPI (S3=3D%s S4=3D%s) ...\n",
> +                   (s3_enabled) ? "ON" : "OFF",
> +                   (s4_enabled) ? "ON" : "OFF");
> +            bios->acpi_build_tables(s3_enabled, s4_enabled);
>          }
>=20
>          acpi_enable_sci();
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/rombios.c
> --- a/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:28:52 2011
> +0000
> +++ b/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:28:53 2011
> +0000
> @@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
>      *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) =3D -checksum;
> }
>=20
> -static void rombios_acpi_build_tables(void)
> +static void rombios_acpi_build_tables(int s3_enabled, int
> s4_enabled)
>  {
>      struct acpi_config config =3D {
>          .dsdt_anycpu =3D dsdt_anycpu,
>          .dsdt_anycpu_len =3D dsdt_anycpu_len,
>          .dsdt_15cpu =3D dsdt_15cpu,
>          .dsdt_15cpu_len =3D dsdt_15cpu_len,
> +        .ssdt_s3_enabled =3D s3_enabled,
> +        .ssdt_s4_enabled =3D s4_enabled,
>      };
>=20
>      acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS); diff -r
> d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/seabios.c
> --- a/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:28:52 2011
> +0000
> +++ b/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:28:53 2011
> +0000
> @@ -91,7 +91,7 @@ static void add_table(uint32_t t)
>      info->tables_nr++;
>  }
>=20
> -static void seabios_acpi_build_tables(void)
> +static void seabios_acpi_build_tables(int s3_enabled, int
> s4_enabled)
>  {
>      uint32_t rsdp =3D (uint32_t)scratch_alloc(sizeof(struct
> acpi_20_rsdp), 0);
>      struct acpi_config config =3D {
> @@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
>          .dsdt_anycpu_len =3D dsdt_anycpu_qemu_xen_len,
>          .dsdt_15cpu =3D NULL,
>          .dsdt_15cpu_len =3D 0,
> +        .ssdt_s3_enabled =3D s3_enabled,
> +        .ssdt_s4_enabled =3D s4_enabled,
>      };
>=20
>      acpi_build_tables(&config, rsdp);
> diff -r d22ef0f60497 -r 66bdcb90560f tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Fri Nov 18 10:28:52 2011 +0000
> +++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:28:53 2011 +0000
> @@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
>          b_info->u.hvm.pae =3D 1;
>          b_info->u.hvm.apic =3D 1;
>          b_info->u.hvm.acpi =3D 1;
> +        b_info->u.hvm.acpi_s3 =3D 1;
> +        b_info->u.hvm.acpi_s4 =3D 1;
>          b_info->u.hvm.nx =3D 1;
>          b_info->u.hvm.viridian =3D 0;
>          b_info->u.hvm.hpet =3D 1;
> @@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
>          vments[4] =3D "start_time";
>          vments[5] =3D libxl__sprintf(gc, "%lu.%02d",
> start_time.tv_sec,(int)start_time.tv_usec/10000);
>=20
> -        localents =3D libxl__calloc(gc, 3, sizeof(char *));
> +        localents =3D libxl__calloc(gc, 7, sizeof(char *));
>          localents[0] =3D "platform/acpi";
>          localents[1] =3D (info->u.hvm.acpi) ? "1" : "0";
> +        localents[2] =3D "platform/acpi_s3";
> +        localents[3] =3D (info->u.hvm.acpi_s3) ? "1" : "0";
> +        localents[4] =3D "platform/acpi_s4";
> +        localents[5] =3D (info->u.hvm.acpi_s4) ? "1" : "0";
>=20
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
> diff -r d22ef0f60497 -r 66bdcb90560f tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Fri Nov 18 10:28:52 2011 +0000
> +++ b/tools/libxl/libxl_types.idl	Fri Nov 18 10:28:53 2011 +0000
> @@ -167,6 +167,8 @@ libxl_domain_build_info =3D Struct("domain
>                                         ("pae", bool),
>                                         ("apic", bool),
>                                         ("acpi", bool),
> +                                       ("acpi_s3", bool),
> +                                       ("acpi_s4", bool),
>                                         ("nx", bool),
>                                         ("viridian", bool),
>                                         ("timeoffset", string), diff
> -r d22ef0f60497 -r 66bdcb90560f tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:28:52 2011 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:28:53 2011 +0000
> @@ -683,6 +683,10 @@ static void parse_config_data(const char
>              b_info->u.hvm.apic =3D l;
>          if (!xlu_cfg_get_long (config, "acpi", &l))
>              b_info->u.hvm.acpi =3D l;
> +        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
> +            b_info->u.hvm.acpi_s3 =3D l;
> +        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
> +            b_info->u.hvm.acpi_s4 =3D l;
>          if (!xlu_cfg_get_long (config, "nx", &l))
>              b_info->u.hvm.nx =3D l;
>          if (!xlu_cfg_get_long (config, "viridian", &l))

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:35:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:35:19 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLmw-0003Ht-WF
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLme-0000c3-DB; Fri, 18 Nov 2011 02:35:00 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLkr-0008EG-11
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:33:09 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1321612385!3670111!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2630 invoked from network); 18 Nov 2011 10:33:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:33:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9005591"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:33:05 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 18 Nov 2011
	10:33:05 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 18 Nov 2011 10:33:05 +0000
Thread-Topic: [PATCH 2 of 2] Add configuration options to selectively
	disable S3 and S4 ACPI power states
Thread-Index: Acyl3TyI9upe11rEQbO8zZC4RKOo5wAACb8A
Message-ID: <291EDFCB1E9E224A99088639C4762022B4543AB749@LONPMAILBOX01.citrite.net>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
	<66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
In-Reply-To: <66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 
Subject: [Xen-devel] RE: [PATCH 2 of 2] Add configuration options to
 selectively disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry, this has one line of extraneous noise in. I will resend.

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 18 November 2011 10:29
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH 2 of 2] Add configuration options to selectively
> disable S3 and S4 ACPI power states
>=20
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1321612133 0 #
> Node ID 66bdcb90560f1b996fa34c549834b479a5157cd3
> # Parent  d22ef0f60497772ac17b086e7f589434a2344fe8
> Add configuration options to selectively disable S3 and S4 ACPI
> power states.
>=20
> Introduce acpi_s3 and acpi_s4 configuration options (default=3D1). The
> S3 and S4 packages are moved into separate SSDTs and their inclusion
> is controlled by the new configuration options.
>=20
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>=20
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/Makefile
> --- a/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:28:52
> 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -26,7 +26,7 @@ CFLAGS +=3D $(CFLAGS_xeninclude)  vpath iasl $(PATH)
>  all: acpi.a
>=20
> -ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
> +ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
>  	iasl -vs -p $* -tc $<
>  	sed -e 's/AmlCode/$*/g' $*.hex >$@
>  	rm -f $*.hex $*.aml
> @@ -57,7 +57,7 @@ iasl:
>  	@echo
>  	@exit 1
>=20
> -build.o: ssdt_pm.h ssdt_tpm.h
> +build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
>=20
>  acpi.a: $(OBJS)
>  	$(AR) rc $@ $(OBJS)
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/acpi2_0.h
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:28:52
> 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -396,6 +396,8 @@ struct acpi_config {
>      int dsdt_anycpu_len;
>      unsigned char *dsdt_15cpu;
>      int dsdt_15cpu_len;
> +    int ssdt_s3_enabled;
> +    int ssdt_s4_enabled;
>  };
>=20
>  void acpi_build_tables(struct acpi_config *config, unsigned int
> physical); diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:28:52
> 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -17,6 +17,9 @@
>   */
>=20
>  #include "acpi2_0.h"
> +#include "ssdt_s3.h"
> +#include "ssdt_s4.h"
> +#include "ssdt_s5.h"
>  #include "ssdt_tpm.h"
>  #include "ssdt_pm.h"
>  #include "../config.h"
> @@ -196,7 +199,8 @@ static struct acpi_20_waet *construct_wa  }
>=20
>  static int construct_secondary_tables(unsigned long *table_ptrs,
> -                                      struct acpi_info *info)
> +                                      struct acpi_info *info,
> +                                      struct acpi_config *config)
>  {
>      int nr_tables =3D 0;
>      struct acpi_20_madt *madt;
> @@ -235,6 +239,22 @@ static int construct_secondary_tables(un
>          table_ptrs[nr_tables++] =3D (unsigned long)ssdt;
>      }
>=20
> +    if ( config->ssdt_s3_enabled )
> +    {
> +        ssdt =3D mem_alloc(sizeof(ssdt_s3), 16);
> +        if (!ssdt) return -1;
> +        memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
> +        table_ptrs[nr_tables++] =3D (unsigned long)ssdt;
> +    }
> +
> +    if ( config->ssdt_s4_enabled )
> +    {
> +        ssdt =3D mem_alloc(sizeof(ssdt_s4), 16);
> +        if (!ssdt) return -1;
> +        memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
> +        table_ptrs[nr_tables++] =3D (unsigned long)ssdt;
> +    }
> +
>      /* TPM TCPA and SSDT. */
>      tis_hdr =3D (uint16_t *)0xFED40F00;
>      if ( (tis_hdr[0] =3D=3D tis_signature[0]) && @@ -353,7 +373,8 @@
> void acpi_build_tables(struct acpi_confi
>                   offsetof(struct acpi_header, checksum),
>                   sizeof(struct acpi_20_fadt));
>=20
> -    nr_secondaries =3D construct_secondary_tables(secondary_tables,
> acpi_info);
> +    nr_secondaries =3D construct_secondary_tables(secondary_tables,
> acpi_info,
> +                                                config);
>      if ( nr_secondaries < 0 )
>          goto oom;
>=20
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/dsdt.asl
> --- a/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:28:52
> 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -27,24 +27,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>      Name (\APCL, 0x00010000)
>      Name (\PUID, 0x00)
>=20
> -    /*
> -     * S3 (suspend-to-ram), S4 (suspend-to-disc) and S5 (power-off)
> type codes:
> -     * must match piix4 emulation.
> -     */
> -    Name (\_S3, Package (0x04)
> -    {
> -        0x01,  /* PM1a_CNT.SLP_TYP */
> -        0x01,  /* PM1b_CNT.SLP_TYP */
> -        0x0,   /* reserved */
> -        0x0    /* reserved */
> -    })
> -    Name (\_S4, Package (0x04)
> -    {
> -        0x00,  /* PM1a_CNT.SLP_TYP */
> -        0x00,  /* PM1b_CNT.SLP_TYP */
> -        0x00,  /* reserved */
> -        0x00   /* reserved */
> -    })
> +    /* _S3 and _S4 are in separate SSDTs */
>      Name (\_S5, Package (0x04)
>      {
>          0x00,  /* PM1a_CNT.SLP_TYP */
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/ssdt_s3.asl
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/hvmloader/acpi/ssdt_s3.asl	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -0,0 +1,32 @@
> +/*
> + * ssdt_s3.asl
> + *
> + * Copyright (c) 2011  Citrix Systems, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License as
> published by
> + * the Free Software Foundation; either version 2 of the License,
> or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-
> 1307
> +USA  */
> +
> +DefinitionBlock ("SSDT_S3.aml", "SSDT", 2, "Xen", "HVM", 0) {
> +    /* Must match piix emulation */
> +    Name (\_S3, Package (0x04)
> +    {
> +        0x01,  /* PM1a_CNT.SLP_TYP */
> +        0x01,  /* PM1b_CNT.SLP_TYP */
> +        0x0,   /* reserved */
> +        0x0    /* reserved */
> +    })
> +}
> +
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/acpi/ssdt_s4.asl
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/hvmloader/acpi/ssdt_s4.asl	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -0,0 +1,32 @@
> +/*
> + * ssdt_s4.asl
> + *
> + * Copyright (c) 2011  Citrix Systems, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License as
> published by
> + * the Free Software Foundation; either version 2 of the License,
> or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-
> 1307
> +USA  */
> +
> +DefinitionBlock ("SSDT_S4.aml", "SSDT", 2, "Xen", "HVM", 0) {
> +    /* Must match piix emulation */
> +    Name (\_S4, Package (0x04)
> +    {
> +        0x00,  /* PM1a_CNT.SLP_TYP */
> +        0x00,  /* PM1b_CNT.SLP_TYP */
> +        0x00,  /* reserved */
> +        0x00   /* reserved */
> +    })
> +}
> +
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h	Fri Nov 18 10:28:52 2011
> +0000
> +++ b/tools/firmware/hvmloader/config.h	Fri Nov 18 10:28:53 2011
> +0000
> @@ -27,7 +27,7 @@ struct bios_config {
>=20
>      void (*e820_setup)(void);
>=20
> -    void (*acpi_build_tables)(void);
> +    void (*acpi_build_tables)(int, int);
>      void (*create_mp_tables)(void);
>      void (*create_smbios_tables)(void);
>      void (*create_pir_tables)(void);
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:28:52
> 2011 +0000
> +++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:28:53
> 2011 +0000
> @@ -516,11 +516,17 @@ int main(void)
>              .index =3D HVM_PARAM_ACPI_IOPORTS_LOCATION,
>              .value =3D 1,
>          };
> +        int s3_enabled, s4_enabled;
> +
> +        s3_enabled =3D !strncmp(xenstore_read("platform/acpi_s3",
> "1"), "1", 1);
> +        s4_enabled =3D !strncmp(xenstore_read("platform/acpi_s4",
> "1"),
> + "1", 1);
>=20
>          if ( bios->acpi_build_tables )
>          {
> -            printf("Loading ACPI ...\n");
> -            bios->acpi_build_tables();
> +            printf("Loading ACPI (S3=3D%s S4=3D%s) ...\n",
> +                   (s3_enabled) ? "ON" : "OFF",
> +                   (s4_enabled) ? "ON" : "OFF");
> +            bios->acpi_build_tables(s3_enabled, s4_enabled);
>          }
>=20
>          acpi_enable_sci();
> diff -r d22ef0f60497 -r 66bdcb90560f
> tools/firmware/hvmloader/rombios.c
> --- a/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:28:52 2011
> +0000
> +++ b/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:28:53 2011
> +0000
> @@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
>      *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) =3D -checksum;
> }
>=20
> -static void rombios_acpi_build_tables(void)
> +static void rombios_acpi_build_tables(int s3_enabled, int
> s4_enabled)
>  {
>      struct acpi_config config =3D {
>          .dsdt_anycpu =3D dsdt_anycpu,
>          .dsdt_anycpu_len =3D dsdt_anycpu_len,
>          .dsdt_15cpu =3D dsdt_15cpu,
>          .dsdt_15cpu_len =3D dsdt_15cpu_len,
> +        .ssdt_s3_enabled =3D s3_enabled,
> +        .ssdt_s4_enabled =3D s4_enabled,
>      };
>=20
>      acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS); diff -r
> d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/seabios.c
> --- a/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:28:52 2011
> +0000
> +++ b/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:28:53 2011
> +0000
> @@ -91,7 +91,7 @@ static void add_table(uint32_t t)
>      info->tables_nr++;
>  }
>=20
> -static void seabios_acpi_build_tables(void)
> +static void seabios_acpi_build_tables(int s3_enabled, int
> s4_enabled)
>  {
>      uint32_t rsdp =3D (uint32_t)scratch_alloc(sizeof(struct
> acpi_20_rsdp), 0);
>      struct acpi_config config =3D {
> @@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
>          .dsdt_anycpu_len =3D dsdt_anycpu_qemu_xen_len,
>          .dsdt_15cpu =3D NULL,
>          .dsdt_15cpu_len =3D 0,
> +        .ssdt_s3_enabled =3D s3_enabled,
> +        .ssdt_s4_enabled =3D s4_enabled,
>      };
>=20
>      acpi_build_tables(&config, rsdp);
> diff -r d22ef0f60497 -r 66bdcb90560f tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Fri Nov 18 10:28:52 2011 +0000
> +++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:28:53 2011 +0000
> @@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
>          b_info->u.hvm.pae =3D 1;
>          b_info->u.hvm.apic =3D 1;
>          b_info->u.hvm.acpi =3D 1;
> +        b_info->u.hvm.acpi_s3 =3D 1;
> +        b_info->u.hvm.acpi_s4 =3D 1;
>          b_info->u.hvm.nx =3D 1;
>          b_info->u.hvm.viridian =3D 0;
>          b_info->u.hvm.hpet =3D 1;
> @@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
>          vments[4] =3D "start_time";
>          vments[5] =3D libxl__sprintf(gc, "%lu.%02d",
> start_time.tv_sec,(int)start_time.tv_usec/10000);
>=20
> -        localents =3D libxl__calloc(gc, 3, sizeof(char *));
> +        localents =3D libxl__calloc(gc, 7, sizeof(char *));
>          localents[0] =3D "platform/acpi";
>          localents[1] =3D (info->u.hvm.acpi) ? "1" : "0";
> +        localents[2] =3D "platform/acpi_s3";
> +        localents[3] =3D (info->u.hvm.acpi_s3) ? "1" : "0";
> +        localents[4] =3D "platform/acpi_s4";
> +        localents[5] =3D (info->u.hvm.acpi_s4) ? "1" : "0";
>=20
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
> diff -r d22ef0f60497 -r 66bdcb90560f tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Fri Nov 18 10:28:52 2011 +0000
> +++ b/tools/libxl/libxl_types.idl	Fri Nov 18 10:28:53 2011 +0000
> @@ -167,6 +167,8 @@ libxl_domain_build_info =3D Struct("domain
>                                         ("pae", bool),
>                                         ("apic", bool),
>                                         ("acpi", bool),
> +                                       ("acpi_s3", bool),
> +                                       ("acpi_s4", bool),
>                                         ("nx", bool),
>                                         ("viridian", bool),
>                                         ("timeoffset", string), diff
> -r d22ef0f60497 -r 66bdcb90560f tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:28:52 2011 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:28:53 2011 +0000
> @@ -683,6 +683,10 @@ static void parse_config_data(const char
>              b_info->u.hvm.apic =3D l;
>          if (!xlu_cfg_get_long (config, "acpi", &l))
>              b_info->u.hvm.acpi =3D l;
> +        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
> +            b_info->u.hvm.acpi_s3 =3D l;
> +        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
> +            b_info->u.hvm.acpi_s4 =3D l;
>          if (!xlu_cfg_get_long (config, "nx", &l))
>              b_info->u.hvm.nx =3D l;
>          if (!xlu_cfg_get_long (config, "viridian", &l))

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:36:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:36:35 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLoB-0003I6-8i
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLnq-00015m-DB; Fri, 18 Nov 2011 02:36:14 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLnY-0000zG-8z
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:35:56 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321612537!46165403!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20983 invoked from network); 18 Nov 2011 10:35:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:35:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="171121246"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:35:51 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:35:51 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321612503@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:35:03 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Add configuration options to selectively
 disable S3 and S4 (V3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds the ability to selectively disable the S3 and S4 ACPI
power states for HVM guests.

Since there is a general move towards retiring the hvm_info_table structure,
the first patch moves the acpi_enabled flag out of the hvm_info_table and into
a xenstore key (platform/acpi).
The second patch then introduces the acpi_s3 and acpi_s4 configuration
parameters to the xl config file (default=1). These result in population of
new platform/acpi_s3 and platform/acpi_s4 xenstore keys. hvmloader then reads
these keys to determine whether or not to include SSDTs containing the
_S3 and _S4 packages respectively.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:36:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:36:35 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLoB-0003I6-8i
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLnq-00015m-DB; Fri, 18 Nov 2011 02:36:14 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLnY-0000zG-8z
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:35:56 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321612537!46165403!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20983 invoked from network); 18 Nov 2011 10:35:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:35:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="171121246"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:35:51 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:35:51 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321612503@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:35:03 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Add configuration options to selectively
 disable S3 and S4 (V3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds the ability to selectively disable the S3 and S4 ACPI
power states for HVM guests.

Since there is a general move towards retiring the hvm_info_table structure,
the first patch moves the acpi_enabled flag out of the hvm_info_table and into
a xenstore key (platform/acpi).
The second patch then introduces the acpi_s3 and acpi_s4 configuration
parameters to the xl config file (default=1). These result in population of
new platform/acpi_s3 and platform/acpi_s4 xenstore keys. hvmloader then reads
these keys to determine whether or not to include SSDTs containing the
_S3 and _S4 packages respectively.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:37:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:37:29 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLp2-0003IJ-Rs
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:37:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLoj-0001TQ-KH; Fri, 18 Nov 2011 02:37:09 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLna-000103-4o
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:35:59 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321612553!2078200!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13331 invoked from network); 18 Nov 2011 10:35:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:35:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="19219745"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:35:52 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:35:52 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 8a29891d6a98002b299d73253935c161ecf393a1
Message-ID: <8a29891d6a98002b299d.1321612504@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321612503@cosworth.uk.xensource.com>
References: <patchbomb.1321612503@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:35:04 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Move acpi_enabled out of hvm_info_table
	into xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321612413 0
# Node ID 8a29891d6a98002b299d73253935c161ecf393a1
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Move acpi_enabled out of hvm_info_table into xenstore

Since hvmloader has a xentore client, use a platform key in xenstore
to indicate whether ACPI is enabled or not rather than the shared
hvm_info_table structure.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r dbdc840f8f62 -r 8a29891d6a98 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:33:33 2011 +0000
@@ -423,6 +423,7 @@ int main(void)
     const struct bios_config *bios;
     int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
     uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
+    int acpi_enabled;
 
     /* Initialise hypercall stubs with RET, rendering them no-ops. */
     memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
@@ -506,7 +507,9 @@ int main(void)
                                              option_rom_phys_addr);
     }
 
-    if ( hvm_info->acpi_enabled )
+    acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
+
+    if ( acpi_enabled )
     {
         struct xen_hvm_param p = {
             .domid = DOMID_SELF,
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxc/xc_hvm_build.c	Fri Nov 18 10:33:33 2011 +0000
@@ -67,7 +67,6 @@ static void build_hvm_info(void *hvm_inf
     hvm_info->length = sizeof(struct hvm_info_table);
 
     /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->acpi_enabled = 1;
     hvm_info->apic_mode = 1;
     hvm_info->nr_vcpus = 1;
     memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:33:33 2011 +0000
@@ -188,6 +188,11 @@ int libxl__domain_build(libxl__gc *gc,
         vments[3] = "hvm";
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+
+        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents[0] = "platform/acpi";
+        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         ret = libxl__build_pv(gc, domid, info, state);
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Nov 18 10:33:33 2011 +0000
@@ -248,7 +248,6 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = info->u.hvm.acpi;
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Fri Nov 18 10:33:33 2011 +0000
@@ -996,7 +996,6 @@ static PyObject *pyxc_hvm_build(XcObject
     if ( va_map == NULL )
         return PyErr_SetFromErrno(xc_error_obj);
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = acpi;
     va_hvm->apic_mode    = apic;
     va_hvm->nr_vcpus     = vcpus;
     memcpy(va_hvm->vcpu_online, vcpu_avail, sizeof(vcpu_avail));
diff -r dbdc840f8f62 -r 8a29891d6a98 xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/public/hvm/hvm_info_table.h	Fri Nov 18 10:33:33 2011 +0000
@@ -37,9 +37,6 @@ struct hvm_info_table {
     uint32_t    length;
     uint8_t     checksum;
 
-    /* Should firmware build ACPI tables? */
-    uint8_t     acpi_enabled;
-
     /* Should firmware build APIC descriptors (APIC MADT / MP BIOS)? */
     uint8_t     apic_mode;
 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:37:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:37:29 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLp2-0003IJ-Rs
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:37:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLoj-0001TQ-KH; Fri, 18 Nov 2011 02:37:09 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLna-000103-4o
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:35:59 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321612553!2078200!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13331 invoked from network); 18 Nov 2011 10:35:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:35:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="19219745"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:35:52 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:35:52 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 8a29891d6a98002b299d73253935c161ecf393a1
Message-ID: <8a29891d6a98002b299d.1321612504@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321612503@cosworth.uk.xensource.com>
References: <patchbomb.1321612503@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:35:04 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Move acpi_enabled out of hvm_info_table
	into xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321612413 0
# Node ID 8a29891d6a98002b299d73253935c161ecf393a1
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Move acpi_enabled out of hvm_info_table into xenstore

Since hvmloader has a xentore client, use a platform key in xenstore
to indicate whether ACPI is enabled or not rather than the shared
hvm_info_table structure.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r dbdc840f8f62 -r 8a29891d6a98 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:33:33 2011 +0000
@@ -423,6 +423,7 @@ int main(void)
     const struct bios_config *bios;
     int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
     uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
+    int acpi_enabled;
 
     /* Initialise hypercall stubs with RET, rendering them no-ops. */
     memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
@@ -506,7 +507,9 @@ int main(void)
                                              option_rom_phys_addr);
     }
 
-    if ( hvm_info->acpi_enabled )
+    acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
+
+    if ( acpi_enabled )
     {
         struct xen_hvm_param p = {
             .domid = DOMID_SELF,
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxc/xc_hvm_build.c	Fri Nov 18 10:33:33 2011 +0000
@@ -67,7 +67,6 @@ static void build_hvm_info(void *hvm_inf
     hvm_info->length = sizeof(struct hvm_info_table);
 
     /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->acpi_enabled = 1;
     hvm_info->apic_mode = 1;
     hvm_info->nr_vcpus = 1;
     memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:33:33 2011 +0000
@@ -188,6 +188,11 @@ int libxl__domain_build(libxl__gc *gc,
         vments[3] = "hvm";
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+
+        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents[0] = "platform/acpi";
+        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         ret = libxl__build_pv(gc, domid, info, state);
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Nov 18 10:33:33 2011 +0000
@@ -248,7 +248,6 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = info->u.hvm.acpi;
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Fri Nov 18 10:33:33 2011 +0000
@@ -996,7 +996,6 @@ static PyObject *pyxc_hvm_build(XcObject
     if ( va_map == NULL )
         return PyErr_SetFromErrno(xc_error_obj);
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = acpi;
     va_hvm->apic_mode    = apic;
     va_hvm->nr_vcpus     = vcpus;
     memcpy(va_hvm->vcpu_online, vcpu_avail, sizeof(vcpu_avail));
diff -r dbdc840f8f62 -r 8a29891d6a98 xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/public/hvm/hvm_info_table.h	Fri Nov 18 10:33:33 2011 +0000
@@ -37,9 +37,6 @@ struct hvm_info_table {
     uint32_t    length;
     uint8_t     checksum;
 
-    /* Should firmware build ACPI tables? */
-    uint8_t     acpi_enabled;
-
     /* Should firmware build APIC descriptors (APIC MADT / MP BIOS)? */
     uint8_t     apic_mode;
 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:38:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:38:24 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLpw-0003IW-8D
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLpd-0001qo-3B; Fri, 18 Nov 2011 02:38:05 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLnz-00018r-Ks
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:36:24 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321612578!2078298!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15627 invoked from network); 18 Nov 2011 10:36:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:36:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="171121248"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:35:53 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:35:53 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 3e977aa71278d30aad3d9eb3e5b6413cbcfc0f4e
Message-ID: <3e977aa71278d30aad3d.1321612505@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321612503@cosworth.uk.xensource.com>
References: <patchbomb.1321612503@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:35:05 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] Add configuration options to selectively
 disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321612462 0
# Node ID 3e977aa71278d30aad3d9eb3e5b6413cbcfc0f4e
# Parent  8a29891d6a98002b299d73253935c161ecf393a1
Add configuration options to selectively disable S3 and S4 ACPI power states.

Introduce acpi_s3 and acpi_s4 configuration options (default=1). The S3 and S4
packages are moved into separate SSDTs and their inclusion is controlled by the
new configuration options.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/Makefile
--- a/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:34:22 2011 +0000
@@ -26,7 +26,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 vpath iasl $(PATH)
 all: acpi.a
 
-ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
+ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 	iasl -vs -p $* -tc $<
 	sed -e 's/AmlCode/$*/g' $*.hex >$@
 	rm -f $*.hex $*.aml
@@ -57,7 +57,7 @@ iasl:
 	@echo 
 	@exit 1
 
-build.o: ssdt_pm.h ssdt_tpm.h
+build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
 
 acpi.a: $(OBJS)
 	$(AR) rc $@ $(OBJS)
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:34:22 2011 +0000
@@ -396,6 +396,8 @@ struct acpi_config {
     int dsdt_anycpu_len;
     unsigned char *dsdt_15cpu;
     int dsdt_15cpu_len;
+    int ssdt_s3_enabled;
+    int ssdt_s4_enabled;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:34:22 2011 +0000
@@ -17,6 +17,8 @@
  */
 
 #include "acpi2_0.h"
+#include "ssdt_s3.h"
+#include "ssdt_s4.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
 #include "../config.h"
@@ -196,7 +198,8 @@ static struct acpi_20_waet *construct_wa
 }
 
 static int construct_secondary_tables(unsigned long *table_ptrs,
-                                      struct acpi_info *info)
+                                      struct acpi_info *info,
+                                      struct acpi_config *config)
 {
     int nr_tables = 0;
     struct acpi_20_madt *madt;
@@ -235,6 +238,22 @@ static int construct_secondary_tables(un
         table_ptrs[nr_tables++] = (unsigned long)ssdt;
     }
 
+    if ( config->ssdt_s3_enabled )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s3), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    }
+
+    if ( config->ssdt_s4_enabled )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s4), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    }
+
     /* TPM TCPA and SSDT. */
     tis_hdr = (uint16_t *)0xFED40F00;
     if ( (tis_hdr[0] == tis_signature[0]) &&
@@ -353,7 +372,8 @@ void acpi_build_tables(struct acpi_confi
                  offsetof(struct acpi_header, checksum),
                  sizeof(struct acpi_20_fadt));
 
-    nr_secondaries = construct_secondary_tables(secondary_tables, acpi_info);
+    nr_secondaries = construct_secondary_tables(secondary_tables, acpi_info,
+                                                config);
     if ( nr_secondaries < 0 )
         goto oom;
 
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:34:22 2011 +0000
@@ -27,24 +27,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
     Name (\APCL, 0x00010000)
     Name (\PUID, 0x00)
 
-    /*
-     * S3 (suspend-to-ram), S4 (suspend-to-disc) and S5 (power-off) type codes:
-     * must match piix4 emulation.
-     */
-    Name (\_S3, Package (0x04)
-    {
-        0x01,  /* PM1a_CNT.SLP_TYP */
-        0x01,  /* PM1b_CNT.SLP_TYP */
-        0x0,   /* reserved */
-        0x0    /* reserved */
-    })
-    Name (\_S4, Package (0x04)
-    {
-        0x00,  /* PM1a_CNT.SLP_TYP */
-        0x00,  /* PM1b_CNT.SLP_TYP */
-        0x00,  /* reserved */
-        0x00   /* reserved */
-    })
+    /* _S3 and _S4 are in separate SSDTs */
     Name (\_S5, Package (0x04)
     {
         0x00,  /* PM1a_CNT.SLP_TYP */
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/ssdt_s3.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s3.asl	Fri Nov 18 10:34:22 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s3.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S3.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S3, Package (0x04)
+    {
+        0x01,  /* PM1a_CNT.SLP_TYP */
+        0x01,  /* PM1b_CNT.SLP_TYP */
+        0x0,   /* reserved */
+        0x0    /* reserved */
+    })
+}
+
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/ssdt_s4.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s4.asl	Fri Nov 18 10:34:22 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s4.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S4.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S4, Package (0x04)
+    {
+        0x00,  /* PM1a_CNT.SLP_TYP */
+        0x00,  /* PM1b_CNT.SLP_TYP */
+        0x00,  /* reserved */
+        0x00   /* reserved */
+    })
+}
+
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/config.h	Fri Nov 18 10:34:22 2011 +0000
@@ -27,7 +27,7 @@ struct bios_config {
 
     void (*e820_setup)(void);
 
-    void (*acpi_build_tables)(void);
+    void (*acpi_build_tables)(int, int);
     void (*create_mp_tables)(void);
     void (*create_smbios_tables)(void);
     void (*create_pir_tables)(void);
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:34:22 2011 +0000
@@ -516,11 +516,17 @@ int main(void)
             .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
             .value = 1,
         };
+        int s3_enabled, s4_enabled;
+
+        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1);
+        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1);
 
         if ( bios->acpi_build_tables )
         {
-            printf("Loading ACPI ...\n");
-            bios->acpi_build_tables();
+            printf("Loading ACPI (S3=%s S4=%s) ...\n",
+                   (s3_enabled) ? "ON" : "OFF",
+                   (s4_enabled) ? "ON" : "OFF");
+            bios->acpi_build_tables(s3_enabled, s4_enabled);
         }
 
         acpi_enable_sci();
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/rombios.c
--- a/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:34:22 2011 +0000
@@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
     *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) = -checksum;
 }
 
-static void rombios_acpi_build_tables(void)
+static void rombios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     struct acpi_config config = {
         .dsdt_anycpu = dsdt_anycpu,
         .dsdt_anycpu_len = dsdt_anycpu_len,
         .dsdt_15cpu = dsdt_15cpu,
         .dsdt_15cpu_len = dsdt_15cpu_len,
+        .ssdt_s3_enabled = s3_enabled,
+        .ssdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/seabios.c
--- a/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:34:22 2011 +0000
@@ -91,7 +91,7 @@ static void add_table(uint32_t t)
     info->tables_nr++;
 }
 
-static void seabios_acpi_build_tables(void)
+static void seabios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     uint32_t rsdp = (uint32_t)scratch_alloc(sizeof(struct acpi_20_rsdp), 0);
     struct acpi_config config = {
@@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
         .dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
         .dsdt_15cpu = NULL,
         .dsdt_15cpu_len = 0,
+        .ssdt_s3_enabled = s3_enabled,
+        .ssdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, rsdp);
diff -r 8a29891d6a98 -r 3e977aa71278 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:34:22 2011 +0000
@@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
+        b_info->u.hvm.acpi_s3 = 1;
+        b_info->u.hvm.acpi_s4 = 1;
         b_info->u.hvm.nx = 1;
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
@@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[2] = "platform/acpi_s3";
+        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[4] = "platform/acpi_s4";
+        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 8a29891d6a98 -r 3e977aa71278 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Nov 18 10:34:22 2011 +0000
@@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
+                                       ("acpi_s3", bool),
+                                       ("acpi_s4", bool),
                                        ("nx", bool),
                                        ("viridian", bool),
                                        ("timeoffset", string),
diff -r 8a29891d6a98 -r 3e977aa71278 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:34:22 2011 +0000
@@ -683,6 +683,10 @@ static void parse_config_data(const char
             b_info->u.hvm.apic = l;
         if (!xlu_cfg_get_long (config, "acpi", &l))
             b_info->u.hvm.acpi = l;
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+            b_info->u.hvm.acpi_s3 = l;
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+            b_info->u.hvm.acpi_s4 = l;
         if (!xlu_cfg_get_long (config, "nx", &l))
             b_info->u.hvm.nx = l;
         if (!xlu_cfg_get_long (config, "viridian", &l))

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:38:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:38:24 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLpw-0003IW-8D
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:38:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLpd-0001qo-3B; Fri, 18 Nov 2011 02:38:05 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLnz-00018r-Ks
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:36:24 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321612578!2078298!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15627 invoked from network); 18 Nov 2011 10:36:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:36:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="171121248"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 05:35:53 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 05:35:53 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 3e977aa71278d30aad3d9eb3e5b6413cbcfc0f4e
Message-ID: <3e977aa71278d30aad3d.1321612505@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321612503@cosworth.uk.xensource.com>
References: <patchbomb.1321612503@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 10:35:05 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] Add configuration options to selectively
 disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321612462 0
# Node ID 3e977aa71278d30aad3d9eb3e5b6413cbcfc0f4e
# Parent  8a29891d6a98002b299d73253935c161ecf393a1
Add configuration options to selectively disable S3 and S4 ACPI power states.

Introduce acpi_s3 and acpi_s4 configuration options (default=1). The S3 and S4
packages are moved into separate SSDTs and their inclusion is controlled by the
new configuration options.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/Makefile
--- a/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:34:22 2011 +0000
@@ -26,7 +26,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 vpath iasl $(PATH)
 all: acpi.a
 
-ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
+ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 	iasl -vs -p $* -tc $<
 	sed -e 's/AmlCode/$*/g' $*.hex >$@
 	rm -f $*.hex $*.aml
@@ -57,7 +57,7 @@ iasl:
 	@echo 
 	@exit 1
 
-build.o: ssdt_pm.h ssdt_tpm.h
+build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
 
 acpi.a: $(OBJS)
 	$(AR) rc $@ $(OBJS)
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Nov 18 10:34:22 2011 +0000
@@ -396,6 +396,8 @@ struct acpi_config {
     int dsdt_anycpu_len;
     unsigned char *dsdt_15cpu;
     int dsdt_15cpu_len;
+    int ssdt_s3_enabled;
+    int ssdt_s4_enabled;
 };
 
 void acpi_build_tables(struct acpi_config *config, unsigned int physical);
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:34:22 2011 +0000
@@ -17,6 +17,8 @@
  */
 
 #include "acpi2_0.h"
+#include "ssdt_s3.h"
+#include "ssdt_s4.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
 #include "../config.h"
@@ -196,7 +198,8 @@ static struct acpi_20_waet *construct_wa
 }
 
 static int construct_secondary_tables(unsigned long *table_ptrs,
-                                      struct acpi_info *info)
+                                      struct acpi_info *info,
+                                      struct acpi_config *config)
 {
     int nr_tables = 0;
     struct acpi_20_madt *madt;
@@ -235,6 +238,22 @@ static int construct_secondary_tables(un
         table_ptrs[nr_tables++] = (unsigned long)ssdt;
     }
 
+    if ( config->ssdt_s3_enabled )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s3), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    }
+
+    if ( config->ssdt_s4_enabled )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s4), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    }
+
     /* TPM TCPA and SSDT. */
     tis_hdr = (uint16_t *)0xFED40F00;
     if ( (tis_hdr[0] == tis_signature[0]) &&
@@ -353,7 +372,8 @@ void acpi_build_tables(struct acpi_confi
                  offsetof(struct acpi_header, checksum),
                  sizeof(struct acpi_20_fadt));
 
-    nr_secondaries = construct_secondary_tables(secondary_tables, acpi_info);
+    nr_secondaries = construct_secondary_tables(secondary_tables, acpi_info,
+                                                config);
     if ( nr_secondaries < 0 )
         goto oom;
 
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:34:22 2011 +0000
@@ -27,24 +27,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
     Name (\APCL, 0x00010000)
     Name (\PUID, 0x00)
 
-    /*
-     * S3 (suspend-to-ram), S4 (suspend-to-disc) and S5 (power-off) type codes:
-     * must match piix4 emulation.
-     */
-    Name (\_S3, Package (0x04)
-    {
-        0x01,  /* PM1a_CNT.SLP_TYP */
-        0x01,  /* PM1b_CNT.SLP_TYP */
-        0x0,   /* reserved */
-        0x0    /* reserved */
-    })
-    Name (\_S4, Package (0x04)
-    {
-        0x00,  /* PM1a_CNT.SLP_TYP */
-        0x00,  /* PM1b_CNT.SLP_TYP */
-        0x00,  /* reserved */
-        0x00   /* reserved */
-    })
+    /* _S3 and _S4 are in separate SSDTs */
     Name (\_S5, Package (0x04)
     {
         0x00,  /* PM1a_CNT.SLP_TYP */
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/ssdt_s3.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s3.asl	Fri Nov 18 10:34:22 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s3.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S3.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S3, Package (0x04)
+    {
+        0x01,  /* PM1a_CNT.SLP_TYP */
+        0x01,  /* PM1b_CNT.SLP_TYP */
+        0x0,   /* reserved */
+        0x0    /* reserved */
+    })
+}
+
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/acpi/ssdt_s4.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s4.asl	Fri Nov 18 10:34:22 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s4.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S4.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S4, Package (0x04)
+    {
+        0x00,  /* PM1a_CNT.SLP_TYP */
+        0x00,  /* PM1b_CNT.SLP_TYP */
+        0x00,  /* reserved */
+        0x00   /* reserved */
+    })
+}
+
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/config.h	Fri Nov 18 10:34:22 2011 +0000
@@ -27,7 +27,7 @@ struct bios_config {
 
     void (*e820_setup)(void);
 
-    void (*acpi_build_tables)(void);
+    void (*acpi_build_tables)(int, int);
     void (*create_mp_tables)(void);
     void (*create_smbios_tables)(void);
     void (*create_pir_tables)(void);
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:34:22 2011 +0000
@@ -516,11 +516,17 @@ int main(void)
             .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
             .value = 1,
         };
+        int s3_enabled, s4_enabled;
+
+        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1);
+        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1);
 
         if ( bios->acpi_build_tables )
         {
-            printf("Loading ACPI ...\n");
-            bios->acpi_build_tables();
+            printf("Loading ACPI (S3=%s S4=%s) ...\n",
+                   (s3_enabled) ? "ON" : "OFF",
+                   (s4_enabled) ? "ON" : "OFF");
+            bios->acpi_build_tables(s3_enabled, s4_enabled);
         }
 
         acpi_enable_sci();
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/rombios.c
--- a/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/rombios.c	Fri Nov 18 10:34:22 2011 +0000
@@ -112,13 +112,15 @@ static void reset_bios_checksum(void)
     *((uint8_t *)(ROMBIOS_BEGIN + ROMBIOS_MAXOFFSET)) = -checksum;
 }
 
-static void rombios_acpi_build_tables(void)
+static void rombios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     struct acpi_config config = {
         .dsdt_anycpu = dsdt_anycpu,
         .dsdt_anycpu_len = dsdt_anycpu_len,
         .dsdt_15cpu = dsdt_15cpu,
         .dsdt_15cpu_len = dsdt_15cpu_len,
+        .ssdt_s3_enabled = s3_enabled,
+        .ssdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, ACPI_PHYSICAL_ADDRESS);
diff -r 8a29891d6a98 -r 3e977aa71278 tools/firmware/hvmloader/seabios.c
--- a/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/seabios.c	Fri Nov 18 10:34:22 2011 +0000
@@ -91,7 +91,7 @@ static void add_table(uint32_t t)
     info->tables_nr++;
 }
 
-static void seabios_acpi_build_tables(void)
+static void seabios_acpi_build_tables(int s3_enabled, int s4_enabled)
 {
     uint32_t rsdp = (uint32_t)scratch_alloc(sizeof(struct acpi_20_rsdp), 0);
     struct acpi_config config = {
@@ -99,6 +99,8 @@ static void seabios_acpi_build_tables(vo
         .dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
         .dsdt_15cpu = NULL,
         .dsdt_15cpu_len = 0,
+        .ssdt_s3_enabled = s3_enabled,
+        .ssdt_s4_enabled = s4_enabled,
     };
 
     acpi_build_tables(&config, rsdp);
diff -r 8a29891d6a98 -r 3e977aa71278 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:34:22 2011 +0000
@@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
+        b_info->u.hvm.acpi_s3 = 1;
+        b_info->u.hvm.acpi_s4 = 1;
         b_info->u.hvm.nx = 1;
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
@@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[2] = "platform/acpi_s3";
+        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[4] = "platform/acpi_s4";
+        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 8a29891d6a98 -r 3e977aa71278 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Nov 18 10:34:22 2011 +0000
@@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
+                                       ("acpi_s3", bool),
+                                       ("acpi_s4", bool),
                                        ("nx", bool),
                                        ("viridian", bool),
                                        ("timeoffset", string),
diff -r 8a29891d6a98 -r 3e977aa71278 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:34:22 2011 +0000
@@ -683,6 +683,10 @@ static void parse_config_data(const char
             b_info->u.hvm.apic = l;
         if (!xlu_cfg_get_long (config, "acpi", &l))
             b_info->u.hvm.acpi = l;
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+            b_info->u.hvm.acpi_s3 = l;
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+            b_info->u.hvm.acpi_s4 = l;
         if (!xlu_cfg_get_long (config, "nx", &l))
             b_info->u.hvm.nx = l;
         if (!xlu_cfg_get_long (config, "viridian", &l))

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:39:21 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLqq-0003Ij-Sa
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLqY-0002EH-CJ; Fri, 18 Nov 2011 02:39:02 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLoZ-0001Oj-VT
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:37:01 -0800
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321612616!3670463!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15314 invoked from network); 18 Nov 2011 10:36:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:36:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9005742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:36:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 10:36:55 +0000
Date: Fri, 18 Nov 2011 10:37:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1111181032360.3519@kaball-desktop>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Alexander Graf <agraf@suse.de>, Jan Beulich <JBeulich@novell.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Anthony, Ian,
	Liguori <anthony@codemonkey.ws>
Subject: [Xen-devel] Re: [PATCH V4 00/10] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I start to be happy with this series; I welcome everyone that has an
opinion on PCI passthrough on Xen to give it a read.

Thanks,

Stefano

On Thu, 17 Nov 2011, Anthony PERARD wrote:
> 
> Hi all,
> 
> This patch series introduces the PCI passthrough for Xen.
> 
> First, we have HostPCIDevice that help to access one PCI device of the host.
> 
> Then, there is an additions in the QEMU code, pci_check_bar_overlap.
> 
> There are also several change in pci_ids and pci_regs.
> 
> Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
> (or file), there is one to take care of the initialisation of a passthrough
> device. The second one handle everything about the config address space, there
> are specifics functions for every config register. The third one is to handle
> MSI.
> 
> There is a patch series on xen-devel (applied to xen-unstable) that add the
> support of setting a PCI passthrough device through QMP from libxl (xen tool
> stack). It is just a call to device_add, with the driver parametter
> hostaddr="0000:00:1b.0".
> 
> 
> Change since v3:
>   - host_pci_get_* can now return an error, and take an extra parameter, a
>     pointer to store the wanted value.
>   - The memory_region for the PCI BAR are handled "manualy" because calling
>     pci_default_write_config was not possible, because the XenPT handle the
>     PCIIORegion it self. This make possible to do a device_remove.
>   - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
>     Also, these macro as well as PT_LOG will always print the short BDF of the
>     device in the guest point of view.
>   - PT_ERR is print by default (for all error messages).
>   - Some debug/error message have been improve and should be a bit more useful.
>   - hw_error have been removed from the code, and have been replaced by either
>     a call to qemu_system_shudown_request() (that lead to a domain destroy) or
>     a failed in the initialisation of the device.
>   - Now, every patchs should compile with no error.
> 
> 
> Change v2-v3;
>   - in host-pci-device.c:
>     - Return more usefull error code in get_ressource().
>     - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
>       still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
>       was before, so it's maybe ok.
>   - All use of MSI stuff in two first pci passthrough patch have been removed
>     and move to the last patch.
> 
> 
> Change v1-v2:
>   - fix style issue (checkpatch.pl)
>   - set the original authors, add some missing copyright headers
>   - HostPCIDevice:
>     - introduce HostPCIIORegions (with base_addr, size, flags)
>     - save all flags from ./resource and store it in a separate field.
>     - fix endianess on write
>     - new host_pci_dev_put function
>     - use pci.c like interface host_pci_get/set_byte/word/long (instead of
>       host_pci_read/write_)
>   - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
>   - introduce apic-msidef.h file.
>   - no more run_one_timer, if a pci device is in the middle of a power
>     transition, just "return an error" in config read/write
>   - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
>   - add msitranslate and power-mgmt ad qdev property
> 
> 
> 
> Allen Kay (2):
>   Introduce Xen PCI Passthrough, qdevice (1/3)
>   Introduce Xen PCI Passthrough, PCI config space helpers (2/3)
> 
> Anthony PERARD (6):
>   pci_ids: Add INTEL_82599_VF id.
>   pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
>   pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
>   configure: Introduce --enable-xen-pci-passthrough.
>   Introduce HostPCIDevice to access a pci device on the host.
>   Introduce apic-msidef.h
> 
> Jiang Yunhong (1):
>   Introduce Xen PCI Passthrough, MSI (3/3)
> 
> Yuji Shimada (1):
>   pci.c: Add pci_check_bar_overlap
> 
>  Makefile.target                      |    6 +
>  configure                            |   25 +
>  hw/apic-msidef.h                     |   30 +
>  hw/apic.c                            |   11 +-
>  hw/host-pci-device.c                 |  279 ++++
>  hw/host-pci-device.h                 |   75 +
>  hw/pci.c                             |   47 +
>  hw/pci.h                             |    3 +
>  hw/pci_ids.h                         |    1 +
>  hw/pci_regs.h                        |    3 +-
>  hw/xen_common.h                      |    3 +
>  hw/xen_pci_passthrough.c             |  902 ++++++++++++
>  hw/xen_pci_passthrough.h             |  337 +++++
>  hw/xen_pci_passthrough_config_init.c | 2637 ++++++++++++++++++++++++++++++++++
>  hw/xen_pci_passthrough_msi.c         |  678 +++++++++
>  xen-all.c                            |   12 +
>  16 files changed, 5038 insertions(+), 11 deletions(-)
>  create mode 100644 hw/apic-msidef.h
>  create mode 100644 hw/host-pci-device.c
>  create mode 100644 hw/host-pci-device.h
>  create mode 100644 hw/xen_pci_passthrough.c
>  create mode 100644 hw/xen_pci_passthrough.h
>  create mode 100644 hw/xen_pci_passthrough_config_init.c
>  create mode 100644 hw/xen_pci_passthrough_msi.c
> 
> -- 
> Anthony PERARD
> 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:39:21 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLqq-0003Ij-Sa
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLqY-0002EH-CJ; Fri, 18 Nov 2011 02:39:02 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLoZ-0001Oj-VT
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:37:01 -0800
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321612616!3670463!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15314 invoked from network); 18 Nov 2011 10:36:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:36:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9005742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:36:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 10:36:55 +0000
Date: Fri, 18 Nov 2011 10:37:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1111181032360.3519@kaball-desktop>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Alexander Graf <agraf@suse.de>, Jan Beulich <JBeulich@novell.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Anthony, Ian,
	Liguori <anthony@codemonkey.ws>
Subject: [Xen-devel] Re: [PATCH V4 00/10] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I start to be happy with this series; I welcome everyone that has an
opinion on PCI passthrough on Xen to give it a read.

Thanks,

Stefano

On Thu, 17 Nov 2011, Anthony PERARD wrote:
> 
> Hi all,
> 
> This patch series introduces the PCI passthrough for Xen.
> 
> First, we have HostPCIDevice that help to access one PCI device of the host.
> 
> Then, there is an additions in the QEMU code, pci_check_bar_overlap.
> 
> There are also several change in pci_ids and pci_regs.
> 
> Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
> (or file), there is one to take care of the initialisation of a passthrough
> device. The second one handle everything about the config address space, there
> are specifics functions for every config register. The third one is to handle
> MSI.
> 
> There is a patch series on xen-devel (applied to xen-unstable) that add the
> support of setting a PCI passthrough device through QMP from libxl (xen tool
> stack). It is just a call to device_add, with the driver parametter
> hostaddr="0000:00:1b.0".
> 
> 
> Change since v3:
>   - host_pci_get_* can now return an error, and take an extra parameter, a
>     pointer to store the wanted value.
>   - The memory_region for the PCI BAR are handled "manualy" because calling
>     pci_default_write_config was not possible, because the XenPT handle the
>     PCIIORegion it self. This make possible to do a device_remove.
>   - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
>     Also, these macro as well as PT_LOG will always print the short BDF of the
>     device in the guest point of view.
>   - PT_ERR is print by default (for all error messages).
>   - Some debug/error message have been improve and should be a bit more useful.
>   - hw_error have been removed from the code, and have been replaced by either
>     a call to qemu_system_shudown_request() (that lead to a domain destroy) or
>     a failed in the initialisation of the device.
>   - Now, every patchs should compile with no error.
> 
> 
> Change v2-v3;
>   - in host-pci-device.c:
>     - Return more usefull error code in get_ressource().
>     - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
>       still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
>       was before, so it's maybe ok.
>   - All use of MSI stuff in two first pci passthrough patch have been removed
>     and move to the last patch.
> 
> 
> Change v1-v2:
>   - fix style issue (checkpatch.pl)
>   - set the original authors, add some missing copyright headers
>   - HostPCIDevice:
>     - introduce HostPCIIORegions (with base_addr, size, flags)
>     - save all flags from ./resource and store it in a separate field.
>     - fix endianess on write
>     - new host_pci_dev_put function
>     - use pci.c like interface host_pci_get/set_byte/word/long (instead of
>       host_pci_read/write_)
>   - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
>   - introduce apic-msidef.h file.
>   - no more run_one_timer, if a pci device is in the middle of a power
>     transition, just "return an error" in config read/write
>   - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
>   - add msitranslate and power-mgmt ad qdev property
> 
> 
> 
> Allen Kay (2):
>   Introduce Xen PCI Passthrough, qdevice (1/3)
>   Introduce Xen PCI Passthrough, PCI config space helpers (2/3)
> 
> Anthony PERARD (6):
>   pci_ids: Add INTEL_82599_VF id.
>   pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
>   pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
>   configure: Introduce --enable-xen-pci-passthrough.
>   Introduce HostPCIDevice to access a pci device on the host.
>   Introduce apic-msidef.h
> 
> Jiang Yunhong (1):
>   Introduce Xen PCI Passthrough, MSI (3/3)
> 
> Yuji Shimada (1):
>   pci.c: Add pci_check_bar_overlap
> 
>  Makefile.target                      |    6 +
>  configure                            |   25 +
>  hw/apic-msidef.h                     |   30 +
>  hw/apic.c                            |   11 +-
>  hw/host-pci-device.c                 |  279 ++++
>  hw/host-pci-device.h                 |   75 +
>  hw/pci.c                             |   47 +
>  hw/pci.h                             |    3 +
>  hw/pci_ids.h                         |    1 +
>  hw/pci_regs.h                        |    3 +-
>  hw/xen_common.h                      |    3 +
>  hw/xen_pci_passthrough.c             |  902 ++++++++++++
>  hw/xen_pci_passthrough.h             |  337 +++++
>  hw/xen_pci_passthrough_config_init.c | 2637 ++++++++++++++++++++++++++++++++++
>  hw/xen_pci_passthrough_msi.c         |  678 +++++++++
>  xen-all.c                            |   12 +
>  16 files changed, 5038 insertions(+), 11 deletions(-)
>  create mode 100644 hw/apic-msidef.h
>  create mode 100644 hw/host-pci-device.c
>  create mode 100644 hw/host-pci-device.h
>  create mode 100644 hw/xen_pci_passthrough.c
>  create mode 100644 hw/xen_pci_passthrough.h
>  create mode 100644 hw/xen_pci_passthrough_config_init.c
>  create mode 100644 hw/xen_pci_passthrough_msi.c
> 
> -- 
> Anthony PERARD
> 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:42:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:42:00 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLtQ-0003J4-Ka
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLt6-0002jm-D7; Fri, 18 Nov 2011 02:41:40 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLt1-0002ia-13
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:41:35 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321612891!4720525!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22179 invoked from network); 18 Nov 2011 10:41:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9005885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:41:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 10:41:18 +0000
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Fri, 18 Nov 2011 10:41:18 +0000
In-Reply-To: <66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
	<66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321612878.3664.299.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 10:29 +0000, Paul Durrant wrote:
> diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18 10:28:52 2011 +0000
> +++ b/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18 10:28:53 2011 +0000
> @@ -516,11 +516,17 @@ int main(void)
>              .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
>              .value = 1,
>          };
> +        int s3_enabled, s4_enabled;
> +
> +        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1);
> +        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1);

Is it not possible to do these in the underlying acpi_build_tables and
avoid the need to plumb them right the way through?

>          if ( bios->acpi_build_tables )
>          {
> -            printf("Loading ACPI ...\n");
> -            bios->acpi_build_tables();
> +            printf("Loading ACPI (S3=%s S4=%s) ...\n",
> +                   (s3_enabled) ? "ON" : "OFF",
> +                   (s4_enabled) ? "ON" : "OFF");

If possible this printf could also be pushed down so you can continue to
print the config info.

> +            bios->acpi_build_tables(s3_enabled, s4_enabled);
>          }
> 
>          acpi_enable_sci();

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:42:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:42:00 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRLtQ-0003J4-Ka
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRLt6-0002jm-D7; Fri, 18 Nov 2011 02:41:40 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRLt1-0002ia-13
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:41:35 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321612891!4720525!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22179 invoked from network); 18 Nov 2011 10:41:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9005885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:41:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 10:41:18 +0000
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Fri, 18 Nov 2011 10:41:18 +0000
In-Reply-To: <66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
	<66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321612878.3664.299.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 10:29 +0000, Paul Durrant wrote:
> diff -r d22ef0f60497 -r 66bdcb90560f tools/firmware/hvmloader/hvmloader.c
> --- a/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18 10:28:52 2011 +0000
> +++ b/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18 10:28:53 2011 +0000
> @@ -516,11 +516,17 @@ int main(void)
>              .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
>              .value = 1,
>          };
> +        int s3_enabled, s4_enabled;
> +
> +        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1);
> +        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1);

Is it not possible to do these in the underlying acpi_build_tables and
avoid the need to plumb them right the way through?

>          if ( bios->acpi_build_tables )
>          {
> -            printf("Loading ACPI ...\n");
> -            bios->acpi_build_tables();
> +            printf("Loading ACPI (S3=%s S4=%s) ...\n",
> +                   (s3_enabled) ? "ON" : "OFF",
> +                   (s4_enabled) ? "ON" : "OFF");

If possible this printf could also be pushed down so you can continue to
print the config info.

> +            bios->acpi_build_tables(s3_enabled, s4_enabled);
>          }
> 
>          acpi_enable_sci();

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:51:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:51:13 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM2L-0003JV-5Q
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:51:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM21-0003xG-Pl; Fri, 18 Nov 2011 02:50:54 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM1W-0003nd-DX
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:50:23 -0800
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321613418!3173607!1
X-Originating-IP: [213.199.154.204]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9035 invoked from network); 18 Nov 2011 10:50:18 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.204)
	by server-5.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Nov 2011 10:50:18 -0000
Received: from mail66-am1-R.bigfish.com (10.3.201.240) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:43 +0000
Received: from mail66-am1 (localhost [127.0.0.1])	by mail66-am1-R.bigfish.com
	(Postfix) with ESMTP id AAFC35002D7;
	Fri, 18 Nov 2011 10:49:37 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail66-am1 (localhost.localdomain [127.0.0.1]) by mail66-am1
	(MessageSwitch) id 132161337762941_4415; Fri, 18 Nov 2011 10:49:37 +0000
	(UTC)
Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.249])	by
	mail66-am1.bigfish.com (Postfix) with ESMTP id 095584E0042;
	Fri, 18 Nov 2011 10:49:37 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:42 +0000
X-WSS-ID: 0LUURFR-01-56T-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2C27E1028092;	Fri, 18 Nov 2011 04:50:14 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 18 Nov 2011 04:51:45 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 18 Nov 2011 04:50:14 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 Nov 2011
	05:50:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A7DFC49C625; Fri, 18 Nov 2011
	10:50:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 9B6825940FF; Fri, 18 Nov 2011
	11:50:10 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 9d4fecddb805b0780e2eeab9f1f69cc585eac7b8
Message-ID: <9d4fecddb805b0780e2e.1321612945@gran.amd.com>
In-Reply-To: <patchbomb.1321612941@gran.amd.com>
References: <patchbomb.1321612941@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 18 Nov 2011 11:42:25 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 4] amd iommu: Support INVALIDATE_IOMMU_ALL
	command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1321612881 -3600
# Node ID 9d4fecddb805b0780e2eeab9f1f69cc585eac7b8
# Parent  6ef12cc262fb3ac11f9ea58707afb4f7778017ac
amd iommu: Support INVALIDATE_IOMMU_ALL command.
It is one of the new architectural commands supported by iommu v2.It instructs
iommu to clear all address translation and interrupt remapping caches for all
devices and all domains.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 6ef12cc262fb -r 9d4fecddb805 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Fri Nov 18 11:07:40 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Fri Nov 18 11:41:21 2011 +0100
@@ -277,6 +277,20 @@ static void invalidate_interrupt_table(s
     send_iommu_command(iommu, cmd);
 }
 
+void invalidate_iommu_all(struct amd_iommu *iommu)
+{
+    u32 cmd[4], entry;
+
+    cmd[3] = cmd[2] = cmd[0] = 0;
+
+    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_IOMMU_ALL, 0,
+                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
+                         &entry);
+    cmd[1] = entry;
+
+    send_iommu_command(iommu, cmd);
+}
+
 void amd_iommu_flush_iotlb(struct pci_dev *pdev,
                            uint64_t gaddr, unsigned int order)
 {
@@ -380,3 +394,11 @@ void amd_iommu_flush_intremap(struct amd
     invalidate_interrupt_table(iommu, bdf);
     flush_command_buffer(iommu);
 }
+
+void amd_iommu_flush_all_caches(struct amd_iommu *iommu)
+{
+    ASSERT( spin_is_locked(&iommu->lock) );
+
+    invalidate_iommu_all(iommu);
+    flush_command_buffer(iommu);
+}
diff -r 6ef12cc262fb -r 9d4fecddb805 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Fri Nov 18 11:07:40 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Fri Nov 18 11:41:21 2011 +0100
@@ -598,6 +598,9 @@ static void enable_iommu(struct amd_iomm
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
     set_iommu_translation_control(iommu, IOMMU_CONTROL_ENABLED);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
+        amd_iommu_flush_all_caches(iommu);
+
     iommu->enabled = 1;
     spin_unlock_irqrestore(&iommu->lock, flags);
 
@@ -970,6 +973,9 @@ void amd_iommu_resume(void)
     }
 
     /* flush all cache entries after iommu re-enabled */
-    invalidate_all_devices();
-    invalidate_all_domain_pages();
+    if ( !iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
+    {
+        invalidate_all_devices();
+        invalidate_all_domain_pages();
+    }
 }
diff -r 6ef12cc262fb -r 9d4fecddb805 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Fri Nov 18 11:07:40 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Fri Nov 18 11:41:21 2011 +0100
@@ -192,6 +192,7 @@
 #define IOMMU_CMD_INVALIDATE_IOMMU_PAGES	0x3
 #define IOMMU_CMD_INVALIDATE_IOTLB_PAGES	0x4
 #define IOMMU_CMD_INVALIDATE_INT_TABLE		0x5
+#define IOMMU_CMD_INVALIDATE_IOMMU_ALL      0x8
 
 /* COMPLETION_WAIT command */
 #define IOMMU_COMP_WAIT_DATA_BUFFER_SIZE	8
diff -r 6ef12cc262fb -r 9d4fecddb805 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Fri Nov 18 11:07:40 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Fri Nov 18 11:41:21 2011 +0100
@@ -78,6 +78,7 @@ void amd_iommu_flush_iotlb(struct pci_de
                            unsigned int order);
 void amd_iommu_flush_device(struct amd_iommu *iommu, uint16_t bdf);
 void amd_iommu_flush_intremap(struct amd_iommu *iommu, uint16_t bdf);
+void amd_iommu_flush_all_caches(struct amd_iommu *iommu);
 
 /* find iommu for bdf */
 struct amd_iommu *find_iommu_for_device(int seg, int bdf);


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:51:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:51:13 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM2L-0003JV-5Q
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:51:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM21-0003xG-Pl; Fri, 18 Nov 2011 02:50:54 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM1W-0003nd-DX
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:50:23 -0800
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321613418!3173607!1
X-Originating-IP: [213.199.154.204]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9035 invoked from network); 18 Nov 2011 10:50:18 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.204)
	by server-5.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Nov 2011 10:50:18 -0000
Received: from mail66-am1-R.bigfish.com (10.3.201.240) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:43 +0000
Received: from mail66-am1 (localhost [127.0.0.1])	by mail66-am1-R.bigfish.com
	(Postfix) with ESMTP id AAFC35002D7;
	Fri, 18 Nov 2011 10:49:37 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail66-am1 (localhost.localdomain [127.0.0.1]) by mail66-am1
	(MessageSwitch) id 132161337762941_4415; Fri, 18 Nov 2011 10:49:37 +0000
	(UTC)
Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.249])	by
	mail66-am1.bigfish.com (Postfix) with ESMTP id 095584E0042;
	Fri, 18 Nov 2011 10:49:37 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:42 +0000
X-WSS-ID: 0LUURFR-01-56T-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2C27E1028092;	Fri, 18 Nov 2011 04:50:14 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 18 Nov 2011 04:51:45 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 18 Nov 2011 04:50:14 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 Nov 2011
	05:50:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A7DFC49C625; Fri, 18 Nov 2011
	10:50:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 9B6825940FF; Fri, 18 Nov 2011
	11:50:10 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 9d4fecddb805b0780e2eeab9f1f69cc585eac7b8
Message-ID: <9d4fecddb805b0780e2e.1321612945@gran.amd.com>
In-Reply-To: <patchbomb.1321612941@gran.amd.com>
References: <patchbomb.1321612941@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 18 Nov 2011 11:42:25 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 4] amd iommu: Support INVALIDATE_IOMMU_ALL
	command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1321612881 -3600
# Node ID 9d4fecddb805b0780e2eeab9f1f69cc585eac7b8
# Parent  6ef12cc262fb3ac11f9ea58707afb4f7778017ac
amd iommu: Support INVALIDATE_IOMMU_ALL command.
It is one of the new architectural commands supported by iommu v2.It instructs
iommu to clear all address translation and interrupt remapping caches for all
devices and all domains.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 6ef12cc262fb -r 9d4fecddb805 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Fri Nov 18 11:07:40 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Fri Nov 18 11:41:21 2011 +0100
@@ -277,6 +277,20 @@ static void invalidate_interrupt_table(s
     send_iommu_command(iommu, cmd);
 }
 
+void invalidate_iommu_all(struct amd_iommu *iommu)
+{
+    u32 cmd[4], entry;
+
+    cmd[3] = cmd[2] = cmd[0] = 0;
+
+    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_IOMMU_ALL, 0,
+                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
+                         &entry);
+    cmd[1] = entry;
+
+    send_iommu_command(iommu, cmd);
+}
+
 void amd_iommu_flush_iotlb(struct pci_dev *pdev,
                            uint64_t gaddr, unsigned int order)
 {
@@ -380,3 +394,11 @@ void amd_iommu_flush_intremap(struct amd
     invalidate_interrupt_table(iommu, bdf);
     flush_command_buffer(iommu);
 }
+
+void amd_iommu_flush_all_caches(struct amd_iommu *iommu)
+{
+    ASSERT( spin_is_locked(&iommu->lock) );
+
+    invalidate_iommu_all(iommu);
+    flush_command_buffer(iommu);
+}
diff -r 6ef12cc262fb -r 9d4fecddb805 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Fri Nov 18 11:07:40 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Fri Nov 18 11:41:21 2011 +0100
@@ -598,6 +598,9 @@ static void enable_iommu(struct amd_iomm
     set_iommu_event_log_control(iommu, IOMMU_CONTROL_ENABLED);
     set_iommu_translation_control(iommu, IOMMU_CONTROL_ENABLED);
 
+    if ( iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
+        amd_iommu_flush_all_caches(iommu);
+
     iommu->enabled = 1;
     spin_unlock_irqrestore(&iommu->lock, flags);
 
@@ -970,6 +973,9 @@ void amd_iommu_resume(void)
     }
 
     /* flush all cache entries after iommu re-enabled */
-    invalidate_all_devices();
-    invalidate_all_domain_pages();
+    if ( !iommu_has_feature(iommu, IOMMU_EXT_FEATURE_IASUP_SHIFT) )
+    {
+        invalidate_all_devices();
+        invalidate_all_domain_pages();
+    }
 }
diff -r 6ef12cc262fb -r 9d4fecddb805 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Fri Nov 18 11:07:40 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Fri Nov 18 11:41:21 2011 +0100
@@ -192,6 +192,7 @@
 #define IOMMU_CMD_INVALIDATE_IOMMU_PAGES	0x3
 #define IOMMU_CMD_INVALIDATE_IOTLB_PAGES	0x4
 #define IOMMU_CMD_INVALIDATE_INT_TABLE		0x5
+#define IOMMU_CMD_INVALIDATE_IOMMU_ALL      0x8
 
 /* COMPLETION_WAIT command */
 #define IOMMU_COMP_WAIT_DATA_BUFFER_SIZE	8
diff -r 6ef12cc262fb -r 9d4fecddb805 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Fri Nov 18 11:07:40 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Fri Nov 18 11:41:21 2011 +0100
@@ -78,6 +78,7 @@ void amd_iommu_flush_iotlb(struct pci_de
                            unsigned int order);
 void amd_iommu_flush_device(struct amd_iommu *iommu, uint16_t bdf);
 void amd_iommu_flush_intremap(struct amd_iommu *iommu, uint16_t bdf);
+void amd_iommu_flush_all_caches(struct amd_iommu *iommu);
 
 /* find iommu for bdf */
 struct amd_iommu *find_iommu_for_device(int seg, int bdf);


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:52:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:52:07 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM3D-0003Ji-Ax
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM2u-0004Kj-5q; Fri, 18 Nov 2011 02:51:48 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM1W-0003ns-Ky
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:50:24 -0800
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321613419!4055382!1
X-Originating-IP: [213.199.154.208]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3614 invoked from network); 18 Nov 2011 10:50:19 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Nov 2011 10:50:19 -0000
Received: from mail55-am1-R.bigfish.com (10.3.201.250) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:44 +0000
Received: from mail55-am1 (localhost [127.0.0.1])	by mail55-am1-R.bigfish.com
	(Postfix) with ESMTP id 4EFE2600360;
	Fri, 18 Nov 2011 10:47:39 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail55-am1 (localhost.localdomain [127.0.0.1]) by mail55-am1
	(MessageSwitch) id 132161325941708_6752; Fri, 18 Nov 2011 10:47:39 +0000
	(UTC)
Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.245])	by
	mail55-am1.bigfish.com (Postfix) with ESMTP id EF810700043;
	Fri, 18 Nov 2011 10:47:38 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:43 +0000
X-WSS-ID: 0LUURFR-01-56U-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2789C1028095;	Fri, 18 Nov 2011 04:50:14 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 18 Nov 2011 04:51:44 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 18 Nov 2011 04:50:15 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 Nov 2011
	05:50:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7A4D749C58F; Fri, 18 Nov 2011
	10:50:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 6BED5594882; Fri, 18 Nov 2011
	11:50:10 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: ac472579595524317ab2f7e5ef545e67f4c9c6f0
Message-ID: <ac472579595524317ab2.1321612942@gran.amd.com>
In-Reply-To: <patchbomb.1321612941@gran.amd.com>
References: <patchbomb.1321612941@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 18 Nov 2011 11:42:22 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 4] amd iommu: Advertise iommu extended
	feature bits to xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1321541520 -3600
# Node ID ac472579595524317ab2f7e5ef545e67f4c9c6f0
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
amd iommu: Advertise iommu extended feature bits to xen.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r dbdc840f8f62 -r ac4725795955 xen/drivers/passthrough/amd/iommu_detect.c
--- a/xen/drivers/passthrough/amd/iommu_detect.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/drivers/passthrough/amd/iommu_detect.c	Thu Nov 17 15:52:00 2011 +0100
@@ -62,6 +62,47 @@ static int __init get_iommu_capabilities
     return 0;
 }
 
+void __init get_iommu_features(struct amd_iommu *iommu)
+{
+    u32 low, high;
+    int i = 0 ;
+    char * feature_str[] = {
+        "- Prefetch Pages Command", 
+        "- Peripheral Page Service Request", 
+        "- X2APIC Supported", 
+        "- NX bit Supported", 
+        "- Guest Translation", 
+        "- Reserved bit [5]",
+        "- Invalidate All Command", 
+        "- Guest APIC supported", 
+        "- Hardware Error Registers", 
+        "- Performance Counters", 
+        NULL
+    };
+
+    ASSERT( iommu->mmio_base );
+
+    if ( !iommu_has_cap(iommu, PCI_CAP_EFRSUP_SHIFT) )
+    {
+        iommu->features = 0;
+        return;
+    }
+
+    low = readl(iommu->mmio_base + IOMMU_EXT_FEATURE_MMIO_OFFSET);
+    high = readl(iommu->mmio_base + IOMMU_EXT_FEATURE_MMIO_OFFSET + 4);
+
+    iommu->features = ((u64)high << 32) | low;
+
+    printk("AMD-Vi: IOMMU Extended Features:\n");
+
+    while ( feature_str[i] )
+    {
+        if ( iommu_has_feature(iommu, i) )
+            printk( " %s\n", feature_str[i]);
+        i++;
+    }
+}
+
 int __init amd_iommu_detect_one_acpi(void *ivhd)
 {
     struct amd_iommu *iommu;
diff -r dbdc840f8f62 -r ac4725795955 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Nov 17 15:52:00 2011 +0100
@@ -684,6 +684,8 @@ static int __init amd_iommu_init_one(str
     iommu->dev_table.entries = device_table.entries;
     iommu->dev_table.buffer = device_table.buffer;
 
+    get_iommu_features(iommu);
+
     enable_iommu(iommu);
     printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
     nr_amd_iommus++;
diff -r dbdc840f8f62 -r ac4725795955 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/asm-x86/amd-iommu.h	Thu Nov 17 15:52:00 2011 +0100
@@ -54,6 +54,7 @@ struct amd_iommu {
     iommu_cap_t cap;
 
     u8 ht_flags;
+    u64 features;
 
     void *mmio_base;
     unsigned long mmio_base_phys;
diff -r dbdc840f8f62 -r ac4725795955 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Nov 17 15:52:00 2011 +0100
@@ -54,6 +54,7 @@
 #define PCI_CAP_HT_TUNNEL_SHIFT	25
 #define PCI_CAP_NP_CACHE_MASK	0x04000000
 #define PCI_CAP_NP_CACHE_SHIFT	26
+#define PCI_CAP_EFRSUP_SHIFT    27
 #define PCI_CAP_RESET_MASK	0x80000000
 #define PCI_CAP_RESET_SHIFT	31
 
@@ -327,6 +328,26 @@
 #define IOMMU_EXCLUSION_LIMIT_HIGH_MASK		0xFFFFFFFF
 #define IOMMU_EXCLUSION_LIMIT_HIGH_SHIFT	0
 
+/* Extended Feature Register*/
+#define IOMMU_EXT_FEATURE_MMIO_OFFSET                   0x30
+#define IOMMU_EXT_FEATURE_PREFSUP_SHIFT                 0x0
+#define IOMMU_EXT_FEATURE_PPRSUP_SHIFT                  0x1
+#define IOMMU_EXT_FEATURE_XTSUP_SHIFT                   0x2
+#define IOMMU_EXT_FEATURE_NXSUP_SHIFT                   0x3
+#define IOMMU_EXT_FEATURE_GTSUP_SHIFT                   0x4
+#define IOMMU_EXT_FEATURE_IASUP_SHIFT                   0x6
+#define IOMMU_EXT_FEATURE_GASUP_SHIFT                   0x7
+#define IOMMU_EXT_FEATURE_HESUP_SHIFT                   0x8
+#define IOMMU_EXT_FEATURE_PCSUP_SHIFT                   0x9
+#define IOMMU_EXT_FEATURE_HATS_SHIFT                    0x10
+#define IOMMU_EXT_FEATURE_HATS_MASK                     0x00000C00
+#define IOMMU_EXT_FEATURE_GATS_SHIFT                    0x12
+#define IOMMU_EXT_FEATURE_GATS_MASK                     0x00003000
+#define IOMMU_EXT_FEATURE_GLXSUP                        0x14
+
+#define IOMMU_EXT_FEATURE_PASMAX_SHIFT                  0x0
+#define IOMMU_EXT_FEATURE_PASMAX_MASK                   0x0000001F
+
 /* Status Register*/
 #define IOMMU_STATUS_MMIO_OFFSET		0x2020
 #define IOMMU_STATUS_EVENT_OVERFLOW_MASK	0x00000001
diff -r dbdc840f8f62 -r ac4725795955 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Nov 17 15:52:00 2011 +0100
@@ -43,6 +43,7 @@
 int amd_iommu_get_ivrs_dev_entries(void);
 int amd_iommu_detect_one_acpi(void *ivhd);
 int amd_iommu_detect_acpi(void);
+void get_iommu_features(struct amd_iommu *iommu);
 
 /* amd-iommu-init functions */
 int amd_iommu_init(void);
@@ -187,4 +188,12 @@ static inline int iommu_has_cap(struct a
     return iommu->cap.header & mask;
 }
 
+static inline int iommu_has_feature(struct amd_iommu *iommu, uint32_t bit)
+{
+    if ( iommu_has_cap(iommu, PCI_CAP_EFRSUP_SHIFT) )
+        return  iommu->features & (1U << bit);
+
+    return 0;
+}
+
 #endif /* _ASM_X86_64_AMD_IOMMU_PROTO_H */


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:52:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:52:07 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM3D-0003Ji-Ax
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM2u-0004Kj-5q; Fri, 18 Nov 2011 02:51:48 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM1W-0003ns-Ky
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:50:24 -0800
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321613419!4055382!1
X-Originating-IP: [213.199.154.208]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3614 invoked from network); 18 Nov 2011 10:50:19 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Nov 2011 10:50:19 -0000
Received: from mail55-am1-R.bigfish.com (10.3.201.250) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:44 +0000
Received: from mail55-am1 (localhost [127.0.0.1])	by mail55-am1-R.bigfish.com
	(Postfix) with ESMTP id 4EFE2600360;
	Fri, 18 Nov 2011 10:47:39 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail55-am1 (localhost.localdomain [127.0.0.1]) by mail55-am1
	(MessageSwitch) id 132161325941708_6752; Fri, 18 Nov 2011 10:47:39 +0000
	(UTC)
Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.245])	by
	mail55-am1.bigfish.com (Postfix) with ESMTP id EF810700043;
	Fri, 18 Nov 2011 10:47:38 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:43 +0000
X-WSS-ID: 0LUURFR-01-56U-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2789C1028095;	Fri, 18 Nov 2011 04:50:14 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 18 Nov 2011 04:51:44 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 18 Nov 2011 04:50:15 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 Nov 2011
	05:50:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7A4D749C58F; Fri, 18 Nov 2011
	10:50:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 6BED5594882; Fri, 18 Nov 2011
	11:50:10 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: ac472579595524317ab2f7e5ef545e67f4c9c6f0
Message-ID: <ac472579595524317ab2.1321612942@gran.amd.com>
In-Reply-To: <patchbomb.1321612941@gran.amd.com>
References: <patchbomb.1321612941@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 18 Nov 2011 11:42:22 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 4] amd iommu: Advertise iommu extended
	feature bits to xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1321541520 -3600
# Node ID ac472579595524317ab2f7e5ef545e67f4c9c6f0
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
amd iommu: Advertise iommu extended feature bits to xen.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r dbdc840f8f62 -r ac4725795955 xen/drivers/passthrough/amd/iommu_detect.c
--- a/xen/drivers/passthrough/amd/iommu_detect.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/drivers/passthrough/amd/iommu_detect.c	Thu Nov 17 15:52:00 2011 +0100
@@ -62,6 +62,47 @@ static int __init get_iommu_capabilities
     return 0;
 }
 
+void __init get_iommu_features(struct amd_iommu *iommu)
+{
+    u32 low, high;
+    int i = 0 ;
+    char * feature_str[] = {
+        "- Prefetch Pages Command", 
+        "- Peripheral Page Service Request", 
+        "- X2APIC Supported", 
+        "- NX bit Supported", 
+        "- Guest Translation", 
+        "- Reserved bit [5]",
+        "- Invalidate All Command", 
+        "- Guest APIC supported", 
+        "- Hardware Error Registers", 
+        "- Performance Counters", 
+        NULL
+    };
+
+    ASSERT( iommu->mmio_base );
+
+    if ( !iommu_has_cap(iommu, PCI_CAP_EFRSUP_SHIFT) )
+    {
+        iommu->features = 0;
+        return;
+    }
+
+    low = readl(iommu->mmio_base + IOMMU_EXT_FEATURE_MMIO_OFFSET);
+    high = readl(iommu->mmio_base + IOMMU_EXT_FEATURE_MMIO_OFFSET + 4);
+
+    iommu->features = ((u64)high << 32) | low;
+
+    printk("AMD-Vi: IOMMU Extended Features:\n");
+
+    while ( feature_str[i] )
+    {
+        if ( iommu_has_feature(iommu, i) )
+            printk( " %s\n", feature_str[i]);
+        i++;
+    }
+}
+
 int __init amd_iommu_detect_one_acpi(void *ivhd)
 {
     struct amd_iommu *iommu;
diff -r dbdc840f8f62 -r ac4725795955 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Nov 17 15:52:00 2011 +0100
@@ -684,6 +684,8 @@ static int __init amd_iommu_init_one(str
     iommu->dev_table.entries = device_table.entries;
     iommu->dev_table.buffer = device_table.buffer;
 
+    get_iommu_features(iommu);
+
     enable_iommu(iommu);
     printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
     nr_amd_iommus++;
diff -r dbdc840f8f62 -r ac4725795955 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/asm-x86/amd-iommu.h	Thu Nov 17 15:52:00 2011 +0100
@@ -54,6 +54,7 @@ struct amd_iommu {
     iommu_cap_t cap;
 
     u8 ht_flags;
+    u64 features;
 
     void *mmio_base;
     unsigned long mmio_base_phys;
diff -r dbdc840f8f62 -r ac4725795955 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Nov 17 15:52:00 2011 +0100
@@ -54,6 +54,7 @@
 #define PCI_CAP_HT_TUNNEL_SHIFT	25
 #define PCI_CAP_NP_CACHE_MASK	0x04000000
 #define PCI_CAP_NP_CACHE_SHIFT	26
+#define PCI_CAP_EFRSUP_SHIFT    27
 #define PCI_CAP_RESET_MASK	0x80000000
 #define PCI_CAP_RESET_SHIFT	31
 
@@ -327,6 +328,26 @@
 #define IOMMU_EXCLUSION_LIMIT_HIGH_MASK		0xFFFFFFFF
 #define IOMMU_EXCLUSION_LIMIT_HIGH_SHIFT	0
 
+/* Extended Feature Register*/
+#define IOMMU_EXT_FEATURE_MMIO_OFFSET                   0x30
+#define IOMMU_EXT_FEATURE_PREFSUP_SHIFT                 0x0
+#define IOMMU_EXT_FEATURE_PPRSUP_SHIFT                  0x1
+#define IOMMU_EXT_FEATURE_XTSUP_SHIFT                   0x2
+#define IOMMU_EXT_FEATURE_NXSUP_SHIFT                   0x3
+#define IOMMU_EXT_FEATURE_GTSUP_SHIFT                   0x4
+#define IOMMU_EXT_FEATURE_IASUP_SHIFT                   0x6
+#define IOMMU_EXT_FEATURE_GASUP_SHIFT                   0x7
+#define IOMMU_EXT_FEATURE_HESUP_SHIFT                   0x8
+#define IOMMU_EXT_FEATURE_PCSUP_SHIFT                   0x9
+#define IOMMU_EXT_FEATURE_HATS_SHIFT                    0x10
+#define IOMMU_EXT_FEATURE_HATS_MASK                     0x00000C00
+#define IOMMU_EXT_FEATURE_GATS_SHIFT                    0x12
+#define IOMMU_EXT_FEATURE_GATS_MASK                     0x00003000
+#define IOMMU_EXT_FEATURE_GLXSUP                        0x14
+
+#define IOMMU_EXT_FEATURE_PASMAX_SHIFT                  0x0
+#define IOMMU_EXT_FEATURE_PASMAX_MASK                   0x0000001F
+
 /* Status Register*/
 #define IOMMU_STATUS_MMIO_OFFSET		0x2020
 #define IOMMU_STATUS_EVENT_OVERFLOW_MASK	0x00000001
diff -r dbdc840f8f62 -r ac4725795955 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Nov 17 15:52:00 2011 +0100
@@ -43,6 +43,7 @@
 int amd_iommu_get_ivrs_dev_entries(void);
 int amd_iommu_detect_one_acpi(void *ivhd);
 int amd_iommu_detect_acpi(void);
+void get_iommu_features(struct amd_iommu *iommu);
 
 /* amd-iommu-init functions */
 int amd_iommu_init(void);
@@ -187,4 +188,12 @@ static inline int iommu_has_cap(struct a
     return iommu->cap.header & mask;
 }
 
+static inline int iommu_has_feature(struct amd_iommu *iommu, uint32_t bit)
+{
+    if ( iommu_has_cap(iommu, PCI_CAP_EFRSUP_SHIFT) )
+        return  iommu->features & (1U << bit);
+
+    return 0;
+}
+
 #endif /* _ASM_X86_64_AMD_IOMMU_PROTO_H */


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:52:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:52:54 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM3y-0003Jv-1H
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM3f-0004iK-Bn; Fri, 18 Nov 2011 02:52:35 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM1a-0003p3-Ty
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:50:27 -0800
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1321613423!3642484!1
X-Originating-IP: [213.199.154.207]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1082 invoked from network); 18 Nov 2011 10:50:23 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE004.bigfish.com) (213.199.154.207)
	by server-16.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Nov 2011 10:50:23 -0000
Received: from mail115-am1-R.bigfish.com (10.3.201.251) by
	AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:49 +0000
Received: from mail115-am1 (localhost [127.0.0.1])	by
	mail115-am1-R.bigfish.com (Postfix) with ESMTP id 425AB34034B;
	Fri, 18 Nov 2011 10:51:27 +0000 (UTC)
X-SpamScore: -9
X-BigFish: VPS-9(zz4015Lzz1202hzz5eeeM8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail115-am1 (localhost.localdomain [127.0.0.1]) by mail115-am1
	(MessageSwitch) id 132161348726832_28732;
	Fri, 18 Nov 2011 10:51:27 +0000 (UTC)
Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.242])	by
	mail115-am1.bigfish.com (Postfix) with ESMTP id F3418200043;
	Fri, 18 Nov 2011 10:51:26 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:47 +0000
X-WSS-ID: 0LUURFV-01-56X-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 255461028092;	Fri, 18 Nov 2011 04:50:18 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 18 Nov 2011 04:51:49 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 18 Nov 2011 04:50:19 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 Nov 2011
	05:50:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7685549C0F1; Fri, 18 Nov 2011
	10:50:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 5BE215940FF; Fri, 18 Nov 2011
	11:50:10 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321612941@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 18 Nov 2011 11:42:21 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 4] amd iommu: IOMMUv2 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch set adds basic supports for amd next generation iommu (IOMMUv2) 
hardware. IOMMUv2 supports various new features advertised by iommu 
extended feature register. It introduces guest level IO translation and 
supports state-of-the-art ATS/ATC devices with demand paging capability. 
Please refer to AMD IOMMU Architectural Specification [1] for more details.

Thanks,
Wei

[1] http://support.amd.com/us/Processor_TechDocs/48882.pdf


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:52:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:52:54 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM3y-0003Jv-1H
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM3f-0004iK-Bn; Fri, 18 Nov 2011 02:52:35 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM1a-0003p3-Ty
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:50:27 -0800
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1321613423!3642484!1
X-Originating-IP: [213.199.154.207]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1082 invoked from network); 18 Nov 2011 10:50:23 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE004.bigfish.com) (213.199.154.207)
	by server-16.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Nov 2011 10:50:23 -0000
Received: from mail115-am1-R.bigfish.com (10.3.201.251) by
	AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:49 +0000
Received: from mail115-am1 (localhost [127.0.0.1])	by
	mail115-am1-R.bigfish.com (Postfix) with ESMTP id 425AB34034B;
	Fri, 18 Nov 2011 10:51:27 +0000 (UTC)
X-SpamScore: -9
X-BigFish: VPS-9(zz4015Lzz1202hzz5eeeM8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail115-am1 (localhost.localdomain [127.0.0.1]) by mail115-am1
	(MessageSwitch) id 132161348726832_28732;
	Fri, 18 Nov 2011 10:51:27 +0000 (UTC)
Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.242])	by
	mail115-am1.bigfish.com (Postfix) with ESMTP id F3418200043;
	Fri, 18 Nov 2011 10:51:26 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:47 +0000
X-WSS-ID: 0LUURFV-01-56X-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 255461028092;	Fri, 18 Nov 2011 04:50:18 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 18 Nov 2011 04:51:49 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 18 Nov 2011 04:50:19 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 Nov 2011
	05:50:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7685549C0F1; Fri, 18 Nov 2011
	10:50:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 5BE215940FF; Fri, 18 Nov 2011
	11:50:10 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321612941@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 18 Nov 2011 11:42:21 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 4] amd iommu: IOMMUv2 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch set adds basic supports for amd next generation iommu (IOMMUv2) 
hardware. IOMMUv2 supports various new features advertised by iommu 
extended feature register. It introduces guest level IO translation and 
supports state-of-the-art ATS/ATC devices with demand paging capability. 
Please refer to AMD IOMMU Architectural Specification [1] for more details.

Thanks,
Wei

[1] http://support.amd.com/us/Processor_TechDocs/48882.pdf


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:53:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:53:48 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM4q-0003K8-2v
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM4W-00055q-Lk; Fri, 18 Nov 2011 02:53:28 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM1c-0003pV-7C
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:50:29 -0800
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321613425!4054642!1
X-Originating-IP: [213.199.154.206]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26518 invoked from network); 18 Nov 2011 10:50:25 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.206)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Nov 2011 10:50:25 -0000
Received: from mail48-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:50 +0000
Received: from mail48-am1 (localhost [127.0.0.1])	by mail48-am1-R.bigfish.com
	(Postfix) with ESMTP id 35D7D6A07D0;
	Fri, 18 Nov 2011 10:50:07 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail48-am1 (localhost.localdomain [127.0.0.1]) by mail48-am1
	(MessageSwitch) id 1321613406658081_12743;
	Fri, 18 Nov 2011 10:50:06 +0000 (UTC)
Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.241])	by
	mail48-am1.bigfish.com (Postfix) with ESMTP id 9BB6B200043;
	Fri, 18 Nov 2011 10:50:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:48 +0000
X-WSS-ID: 0LUURFW-01-56Z-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29D901028095;	Fri, 18 Nov 2011 04:50:19 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 18 Nov 2011 04:51:50 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 18 Nov 2011 04:50:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 Nov 2011
	05:50:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8897949C5E5; Fri, 18 Nov 2011
	10:50:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 7A2FC5940FF; Fri, 18 Nov 2011
	11:50:10 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 135678ae1bbc02171294c21e2a5469d898d2a353
Message-ID: <135678ae1bbc02171294.1321612943@gran.amd.com>
In-Reply-To: <patchbomb.1321612941@gran.amd.com>
References: <patchbomb.1321612941@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 18 Nov 2011 11:42:23 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 4] amd iommu: Fix incorrect definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1321541523 -3600
# Node ID 135678ae1bbc02171294c21e2a5469d898d2a353
# Parent  ac472579595524317ab2f7e5ef545e67f4c9c6f0
amd iommu: Fix incorrect definitions.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r ac4725795955 -r 135678ae1bbc xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Nov 17 15:52:00 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Nov 17 15:52:03 2011 +0100
@@ -293,10 +293,8 @@
 #define IOMMU_CONTROL_EVENT_LOG_INT_SHIFT		3
 #define IOMMU_CONTROL_COMP_WAIT_INT_MASK		0x00000010
 #define IOMMU_CONTROL_COMP_WAIT_INT_SHIFT		4
-#define IOMMU_CONTROL_TRANSLATION_CHECK_DISABLE_MASK	0x00000020
-#define IOMMU_CONTROL_TRANSLATION_CHECK_DISABLE_SHIFT	5
-#define IOMMU_CONTROL_INVALIDATION_TIMEOUT_MASK		0x000000C0
-#define IOMMU_CONTROL_INVALIDATION_TIMEOUT_SHIFT	6
+#define IOMMU_CONTROL_INVALIDATION_TIMEOUT_MASK		0x000000E0
+#define IOMMU_CONTROL_INVALIDATION_TIMEOUT_SHIFT	5
 #define IOMMU_CONTROL_PASS_POSTED_WRITE_MASK		0x00000100
 #define IOMMU_CONTROL_PASS_POSTED_WRITE_SHIFT		8
 #define IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_MASK	0x00000200


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:53:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:53:48 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM4q-0003K8-2v
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM4W-00055q-Lk; Fri, 18 Nov 2011 02:53:28 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM1c-0003pV-7C
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:50:29 -0800
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321613425!4054642!1
X-Originating-IP: [213.199.154.206]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26518 invoked from network); 18 Nov 2011 10:50:25 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.206)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Nov 2011 10:50:25 -0000
Received: from mail48-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:50 +0000
Received: from mail48-am1 (localhost [127.0.0.1])	by mail48-am1-R.bigfish.com
	(Postfix) with ESMTP id 35D7D6A07D0;
	Fri, 18 Nov 2011 10:50:07 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail48-am1 (localhost.localdomain [127.0.0.1]) by mail48-am1
	(MessageSwitch) id 1321613406658081_12743;
	Fri, 18 Nov 2011 10:50:06 +0000 (UTC)
Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.241])	by
	mail48-am1.bigfish.com (Postfix) with ESMTP id 9BB6B200043;
	Fri, 18 Nov 2011 10:50:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:48 +0000
X-WSS-ID: 0LUURFW-01-56Z-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 29D901028095;	Fri, 18 Nov 2011 04:50:19 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 18 Nov 2011 04:51:50 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 18 Nov 2011 04:50:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 Nov 2011
	05:50:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8897949C5E5; Fri, 18 Nov 2011
	10:50:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 7A2FC5940FF; Fri, 18 Nov 2011
	11:50:10 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 135678ae1bbc02171294c21e2a5469d898d2a353
Message-ID: <135678ae1bbc02171294.1321612943@gran.amd.com>
In-Reply-To: <patchbomb.1321612941@gran.amd.com>
References: <patchbomb.1321612941@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 18 Nov 2011 11:42:23 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 4] amd iommu: Fix incorrect definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1321541523 -3600
# Node ID 135678ae1bbc02171294c21e2a5469d898d2a353
# Parent  ac472579595524317ab2f7e5ef545e67f4c9c6f0
amd iommu: Fix incorrect definitions.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r ac4725795955 -r 135678ae1bbc xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Nov 17 15:52:00 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Thu Nov 17 15:52:03 2011 +0100
@@ -293,10 +293,8 @@
 #define IOMMU_CONTROL_EVENT_LOG_INT_SHIFT		3
 #define IOMMU_CONTROL_COMP_WAIT_INT_MASK		0x00000010
 #define IOMMU_CONTROL_COMP_WAIT_INT_SHIFT		4
-#define IOMMU_CONTROL_TRANSLATION_CHECK_DISABLE_MASK	0x00000020
-#define IOMMU_CONTROL_TRANSLATION_CHECK_DISABLE_SHIFT	5
-#define IOMMU_CONTROL_INVALIDATION_TIMEOUT_MASK		0x000000C0
-#define IOMMU_CONTROL_INVALIDATION_TIMEOUT_SHIFT	6
+#define IOMMU_CONTROL_INVALIDATION_TIMEOUT_MASK		0x000000E0
+#define IOMMU_CONTROL_INVALIDATION_TIMEOUT_SHIFT	5
 #define IOMMU_CONTROL_PASS_POSTED_WRITE_MASK		0x00000100
 #define IOMMU_CONTROL_PASS_POSTED_WRITE_SHIFT		8
 #define IOMMU_CONTROL_RESP_PASS_POSTED_WRITE_MASK	0x00000200


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:54:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:54:40 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM5g-0003KL-0U
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:54:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM5J-0005TV-Op; Fri, 18 Nov 2011 02:54:18 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM3f-0004hb-Od
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:52:36 -0800
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1321613516!46436176!1
X-Originating-IP: [216.32.180.14]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28636 invoked from network); 18 Nov 2011 10:51:57 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	VA3EHSOBE004.bigfish.com) (216.32.180.14)
	by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Nov 2011 10:51:57 -0000
Received: from mail26-va3-R.bigfish.com (10.7.14.243) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:51:57 +0000
Received: from mail26-va3 (localhost [127.0.0.1])	by mail26-va3-R.bigfish.com
	(Postfix) with ESMTP id 42B9A220176;
	Fri, 18 Nov 2011 10:53:49 +0000 (UTC)
X-SpamScore: 8
X-BigFish: VPS8(z3c23mzc8kzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail26-va3 (localhost.localdomain [127.0.0.1]) by mail26-va3
	(MessageSwitch) id 1321613622462717_19136;
	Fri, 18 Nov 2011 10:53:42 +0000 (UTC)
Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.240])	by
	mail26-va3.bigfish.com (Postfix) with ESMTP id 45F2D580164;
	Fri, 18 Nov 2011 10:51:45 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:50 +0000
X-WSS-ID: 0LUURFW-02-C9E-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DAD7C80CE;	Fri, 18 Nov 2011 04:50:19 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 18 Nov 2011 04:51:50 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 18 Nov 2011 04:50:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 Nov 2011
	05:50:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 9B9B049C623; Fri, 18 Nov 2011
	10:50:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 889BB594882; Fri, 18 Nov 2011
	11:50:10 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 6ef12cc262fb3ac11f9ea58707afb4f7778017ac
Message-ID: <6ef12cc262fb3ac11f9e.1321612944@gran.amd.com>
In-Reply-To: <patchbomb.1321612941@gran.amd.com>
References: <patchbomb.1321612941@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 18 Nov 2011 11:42:24 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 4] amd iommu: Factor out iommu command
	handling functions, 
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1321610860 -3600
# Node ID 6ef12cc262fb3ac11f9ea58707afb4f7778017ac
# Parent  135678ae1bbc02171294c21e2a5469d898d2a353
amd iommu: Factor out iommu command handling functions,
and move them into a new file.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/Makefile
--- a/xen/drivers/passthrough/amd/Makefile	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/drivers/passthrough/amd/Makefile	Fri Nov 18 11:07:40 2011 +0100
@@ -4,3 +4,4 @@ obj-y += iommu_map.o
 obj-y += pci_amd_iommu.o
 obj-bin-y += iommu_acpi.init.o
 obj-y += iommu_intr.o
+obj-y += iommu_cmd.o
diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/iommu_cmd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Fri Nov 18 11:07:40 2011 +0100
@@ -0,0 +1,382 @@
+/*
+ * Copyright (C) 2011 Advanced Micro Devices, Inc.
+ * Author: Leo Duran <leo.duran@amd.com>
+ * Author: Wei Wang <wei.wang2@amd.com> - adapted to xen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ */
+
+#include <xen/sched.h>
+#include <xen/hvm/iommu.h>
+#include <asm/amd-iommu.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
+#include "../ats.h"
+
+static int queue_iommu_command(struct amd_iommu *iommu, u32 cmd[])
+{
+    u32 tail, head, *cmd_buffer;
+    int i;
+
+    tail = iommu->cmd_buffer_tail;
+    if ( ++tail == iommu->cmd_buffer.entries )
+        tail = 0;
+
+    head = get_field_from_reg_u32(readl(iommu->mmio_base + 
+                                        IOMMU_CMD_BUFFER_HEAD_OFFSET),
+                                  IOMMU_CMD_BUFFER_HEAD_MASK,
+                                  IOMMU_CMD_BUFFER_HEAD_SHIFT);
+    if ( head != tail )
+    {
+        cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
+                             (iommu->cmd_buffer_tail *
+                             IOMMU_CMD_BUFFER_ENTRY_SIZE));
+
+        for ( i = 0; i < IOMMU_CMD_BUFFER_U32_PER_ENTRY; i++ )
+            cmd_buffer[i] = cmd[i];
+
+        iommu->cmd_buffer_tail = tail;
+        return 1;
+    }
+
+    return 0;
+}
+
+static void commit_iommu_command_buffer(struct amd_iommu *iommu)
+{
+    u32 tail;
+
+    set_field_in_reg_u32(iommu->cmd_buffer_tail, 0,
+                         IOMMU_CMD_BUFFER_TAIL_MASK,
+                         IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
+    writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
+}
+
+int send_iommu_command(struct amd_iommu *iommu, u32 cmd[])
+{
+    if ( queue_iommu_command(iommu, cmd) )
+    {
+        commit_iommu_command_buffer(iommu);
+        return 1;
+    }
+
+    return 0;
+}
+
+static void flush_command_buffer(struct amd_iommu *iommu)
+{
+    u32 cmd[4], status;
+    int loop_count, comp_wait;
+
+    /* clear 'ComWaitInt' in status register (WIC) */
+    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, 0,
+                         IOMMU_STATUS_COMP_WAIT_INT_MASK,
+                         IOMMU_STATUS_COMP_WAIT_INT_SHIFT, &status);
+    writel(status, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
+    /* send an empty COMPLETION_WAIT command to flush command buffer */
+    cmd[3] = cmd[2] = 0;
+    set_field_in_reg_u32(IOMMU_CMD_COMPLETION_WAIT, 0,
+                         IOMMU_CMD_OPCODE_MASK,
+                         IOMMU_CMD_OPCODE_SHIFT, &cmd[1]);
+    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, 0,
+                         IOMMU_COMP_WAIT_I_FLAG_MASK,
+                         IOMMU_COMP_WAIT_I_FLAG_SHIFT, &cmd[0]);
+    send_iommu_command(iommu, cmd);
+
+    /* Make loop_count long enough for polling completion wait bit */
+    loop_count = 1000;
+    do {
+        status = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+        comp_wait = get_field_from_reg_u32(status,
+                                           IOMMU_STATUS_COMP_WAIT_INT_MASK,
+                                           IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
+        --loop_count;
+    } while ( !comp_wait && loop_count );
+
+    if ( comp_wait )
+    {
+        /* clear 'ComWaitInt' in status register (WIC) */
+        status &= IOMMU_STATUS_COMP_WAIT_INT_MASK;
+        writel(status, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+        return;
+    }
+    AMD_IOMMU_DEBUG("Warning: ComWaitInt bit did not assert!\n");
+}
+
+/* Build low level iommu command messages */
+static void invalidate_iommu_pages(struct amd_iommu *iommu,
+                                   u64 io_addr, u16 domain_id, u16 order)
+{
+    u64 addr_lo, addr_hi;
+    u32 cmd[4], entry;
+    int sflag = 0, pde = 0;
+
+    ASSERT ( order == 0 || order == 9 || order == 18 );
+
+    /* All pages associated with the domainID are invalidated */
+    if ( order || (io_addr == INV_IOMMU_ALL_PAGES_ADDRESS ) )
+    {
+        sflag = 1;
+        pde = 1;
+    }
+
+    /* If sflag == 1, the size of the invalidate command is determined
+     by the first zero bit in the address starting from Address[12] */
+    if ( order )
+    {
+        u64 mask = 1ULL << (order - 1 + PAGE_SHIFT);
+        io_addr &= ~mask;
+        io_addr |= mask - 1;
+    }
+
+    addr_lo = io_addr & DMA_32BIT_MASK;
+    addr_hi = io_addr >> 32;
+
+    set_field_in_reg_u32(domain_id, 0,
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT, &entry);
+    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_IOMMU_PAGES, entry,
+                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
+                         &entry);
+    cmd[1] = entry;
+
+    set_field_in_reg_u32(sflag, 0,
+                         IOMMU_INV_IOMMU_PAGES_S_FLAG_MASK,
+                         IOMMU_INV_IOMMU_PAGES_S_FLAG_SHIFT, &entry);
+    set_field_in_reg_u32(pde, entry,
+                         IOMMU_INV_IOMMU_PAGES_PDE_FLAG_MASK,
+                         IOMMU_INV_IOMMU_PAGES_PDE_FLAG_SHIFT, &entry);
+    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, entry,
+                         IOMMU_INV_IOMMU_PAGES_ADDR_LOW_MASK,
+                         IOMMU_INV_IOMMU_PAGES_ADDR_LOW_SHIFT, &entry);
+    cmd[2] = entry;
+
+    set_field_in_reg_u32((u32)addr_hi, 0,
+                         IOMMU_INV_IOMMU_PAGES_ADDR_HIGH_MASK,
+                         IOMMU_INV_IOMMU_PAGES_ADDR_HIGH_SHIFT, &entry);
+    cmd[3] = entry;
+
+    cmd[0] = 0;
+    send_iommu_command(iommu, cmd);
+}
+
+static void invalidate_iotlb_pages(struct amd_iommu *iommu,
+                                   u16 maxpend, u32 pasid, u16 queueid,
+                                   u64 io_addr, u16 dev_id, u16 order)
+{
+    u64 addr_lo, addr_hi;
+    u32 cmd[4], entry;
+    int sflag = 0;
+
+    ASSERT ( order == 0 || order == 9 || order == 18 );
+
+    if ( order || (io_addr == INV_IOMMU_ALL_PAGES_ADDRESS ) )
+        sflag = 1;
+
+    /* If sflag == 1, the size of the invalidate command is determined
+     by the first zero bit in the address starting from Address[12] */
+    if ( order )
+    {
+        u64 mask = 1ULL << (order - 1 + PAGE_SHIFT);
+        io_addr &= ~mask;
+        io_addr |= mask - 1;
+    }
+
+    addr_lo = io_addr & DMA_32BIT_MASK;
+    addr_hi = io_addr >> 32;
+
+    set_field_in_reg_u32(dev_id, 0,
+                         IOMMU_INV_IOTLB_PAGES_DEVICE_ID_MASK,
+                         IOMMU_INV_IOTLB_PAGES_DEVICE_ID_SHIFT, &entry);
+
+    set_field_in_reg_u32(maxpend, entry,
+                         IOMMU_INV_IOTLB_PAGES_MAXPEND_MASK,
+                         IOMMU_INV_IOTLB_PAGES_MAXPEND_SHIFT, &entry);
+
+    set_field_in_reg_u32(pasid & 0xff, entry,
+                         IOMMU_INV_IOTLB_PAGES_PASID1_MASK,
+                         IOMMU_INV_IOTLB_PAGES_PASID1_SHIFT, &entry);
+    cmd[0] = entry;
+
+    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_IOTLB_PAGES, 0,
+                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
+                         &entry);
+
+    set_field_in_reg_u32(pasid >> 8, entry,
+                         IOMMU_INV_IOTLB_PAGES_PASID2_MASK,
+                         IOMMU_INV_IOTLB_PAGES_PASID2_SHIFT,
+                         &entry);
+
+    set_field_in_reg_u32(queueid, entry,
+                         IOMMU_INV_IOTLB_PAGES_QUEUEID_MASK,
+                         IOMMU_INV_IOTLB_PAGES_QUEUEID_SHIFT,
+                         &entry);
+    cmd[1] = entry;
+
+    set_field_in_reg_u32(sflag, 0,
+                         IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK,
+                         IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK, &entry);
+
+    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, entry,
+                         IOMMU_INV_IOTLB_PAGES_ADDR_LOW_MASK,
+                         IOMMU_INV_IOTLB_PAGES_ADDR_LOW_SHIFT, &entry);
+    cmd[2] = entry;
+
+    set_field_in_reg_u32((u32)addr_hi, 0,
+                         IOMMU_INV_IOTLB_PAGES_ADDR_HIGH_MASK,
+                         IOMMU_INV_IOTLB_PAGES_ADDR_HIGH_SHIFT, &entry);
+    cmd[3] = entry;
+
+    send_iommu_command(iommu, cmd);
+}
+
+static void invalidate_dev_table_entry(struct amd_iommu *iommu,
+                                       u16 device_id)
+{
+    u32 cmd[4], entry;
+
+    cmd[3] = cmd[2] = 0;
+    set_field_in_reg_u32(device_id, 0,
+                         IOMMU_INV_DEVTAB_ENTRY_DEVICE_ID_MASK,
+                         IOMMU_INV_DEVTAB_ENTRY_DEVICE_ID_SHIFT, &entry);
+    cmd[0] = entry;
+
+    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY, 0,
+                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
+                         &entry);
+    cmd[1] = entry;
+
+    send_iommu_command(iommu, cmd);
+}
+
+static void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id)
+{
+    u32 cmd[4], entry;
+
+    cmd[3] = cmd[2] = 0;
+    set_field_in_reg_u32(device_id, 0,
+                         IOMMU_INV_INT_TABLE_DEVICE_ID_MASK,
+                         IOMMU_INV_INT_TABLE_DEVICE_ID_SHIFT, &entry);
+    cmd[0] = entry;
+    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_INT_TABLE, 0,
+                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
+                         &entry);
+    cmd[1] = entry;
+    send_iommu_command(iommu, cmd);
+}
+
+void amd_iommu_flush_iotlb(struct pci_dev *pdev,
+                           uint64_t gaddr, unsigned int order)
+{
+    unsigned long flags;
+    struct amd_iommu *iommu;
+    unsigned int bdf, req_id, queueid, maxpend;
+    struct pci_ats_dev *ats_pdev;
+
+    if ( !ats_enabled )
+        return;
+
+    ats_pdev = get_ats_device(pdev->seg, pdev->bus, pdev->devfn);
+    if ( ats_pdev == NULL )
+        return;
+
+    if ( !pci_ats_enabled(ats_pdev->seg, ats_pdev->bus, ats_pdev->devfn) )
+        return;
+
+    bdf = PCI_BDF2(ats_pdev->bus, ats_pdev->devfn);
+    iommu = find_iommu_for_device(ats_pdev->seg, bdf);
+
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s: Can't find iommu for %04x:%02x:%02x.%u\n",
+                        __func__, ats_pdev->seg, ats_pdev->bus,
+                        PCI_SLOT(ats_pdev->devfn), PCI_FUNC(ats_pdev->devfn));
+        return;
+    }
+
+    if ( !iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
+        return;
+
+    req_id = get_dma_requestor_id(iommu->seg, bdf);
+    queueid = req_id;
+    maxpend = (ats_pdev->ats_queue_depth + 32) & 0xff;
+
+    /* send INVALIDATE_IOTLB_PAGES command */
+    spin_lock_irqsave(&iommu->lock, flags);
+    invalidate_iotlb_pages(iommu, maxpend, 0, queueid, gaddr, req_id, order);
+    flush_command_buffer(iommu);
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
+
+static void amd_iommu_flush_all_iotlbs(struct domain *d, uint64_t gaddr,
+                                       unsigned int order)
+{
+    struct pci_dev *pdev;
+
+    if ( !ats_enabled )
+        return;
+
+    for_each_pdev( d, pdev )
+        amd_iommu_flush_iotlb(pdev, gaddr, order);
+}
+
+/* Flush iommu cache after p2m changes. */
+static void _amd_iommu_flush_pages(struct domain *d,
+                                   uint64_t gaddr, unsigned int order)
+{
+    unsigned long flags;
+    struct amd_iommu *iommu;
+    struct hvm_iommu *hd = domain_hvm_iommu(d);
+    unsigned int dom_id = hd->domain_id;
+
+    /* send INVALIDATE_IOMMU_PAGES command */
+    for_each_amd_iommu ( iommu )
+    {
+        spin_lock_irqsave(&iommu->lock, flags);
+        invalidate_iommu_pages(iommu, gaddr, dom_id, order);
+        flush_command_buffer(iommu);
+        spin_unlock_irqrestore(&iommu->lock, flags);
+    }
+
+    if ( ats_enabled )
+        amd_iommu_flush_all_iotlbs(d, gaddr, order);
+}
+
+void amd_iommu_flush_all_pages(struct domain *d)
+{
+    _amd_iommu_flush_pages(d, INV_IOMMU_ALL_PAGES_ADDRESS, 0);
+}
+
+void amd_iommu_flush_pages(struct domain *d,
+                           unsigned long gfn, unsigned int order)
+{
+    _amd_iommu_flush_pages(d, (uint64_t) gfn << PAGE_SHIFT, order);
+}
+
+void amd_iommu_flush_device(struct amd_iommu *iommu, uint16_t bdf)
+{
+    ASSERT( spin_is_locked(&iommu->lock) );
+
+    invalidate_dev_table_entry(iommu, bdf);
+    flush_command_buffer(iommu);
+}
+
+void amd_iommu_flush_intremap(struct amd_iommu *iommu, uint16_t bdf)
+{
+    ASSERT( spin_is_locked(&iommu->lock) );
+
+    invalidate_interrupt_table(iommu, bdf);
+    flush_command_buffer(iommu);
+}
diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Fri Nov 18 11:07:40 2011 +0100
@@ -933,9 +933,8 @@ static int _invalidate_all_devices(
         if ( iommu )
         {
             spin_lock_irqsave(&iommu->lock, flags);
-            invalidate_dev_table_entry(iommu, req_id);
-            invalidate_interrupt_table(iommu, req_id);
-            flush_command_buffer(iommu);
+            amd_iommu_flush_device(iommu, req_id);
+            amd_iommu_flush_intremap(iommu, req_id);
             spin_unlock_irqrestore(&iommu->lock, flags);
         }
     }
diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/iommu_intr.c
--- a/xen/drivers/passthrough/amd/iommu_intr.c	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_intr.c	Fri Nov 18 11:07:40 2011 +0100
@@ -96,22 +96,6 @@ static void update_intremap_entry(u32* e
                             INT_REMAP_ENTRY_VECTOR_SHIFT, entry);
 }
 
-void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id)
-{
-    u32 cmd[4], entry;
-
-    cmd[3] = cmd[2] = 0;
-    set_field_in_reg_u32(device_id, 0,
-                         IOMMU_INV_INT_TABLE_DEVICE_ID_MASK,
-                         IOMMU_INV_INT_TABLE_DEVICE_ID_SHIFT, &entry);
-    cmd[0] = entry;
-    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_INT_TABLE, 0,
-                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
-                         &entry);
-    cmd[1] = entry;
-    send_iommu_command(iommu, cmd);
-}
-
 static void update_intremap_entry_from_ioapic(
     int bdf,
     struct amd_iommu *iommu,
@@ -144,8 +128,7 @@ static void update_intremap_entry_from_i
     if ( iommu->enabled )
     {
         spin_lock_irqsave(&iommu->lock, flags);
-        invalidate_interrupt_table(iommu, req_id);
-        flush_command_buffer(iommu);
+        amd_iommu_flush_intremap(iommu, req_id);
         spin_unlock_irqrestore(&iommu->lock, flags);
     }
 }
@@ -202,8 +185,7 @@ int __init amd_iommu_setup_ioapic_remapp
             if ( iommu->enabled )
             {
                 spin_lock_irqsave(&iommu->lock, flags);
-                invalidate_interrupt_table(iommu, req_id);
-                flush_command_buffer(iommu);
+                amd_iommu_flush_intremap(iommu, req_id);
                 spin_unlock_irqrestore(&iommu->lock, flags);
             }
         }
@@ -347,10 +329,9 @@ done:
     if ( iommu->enabled )
     {
         spin_lock_irqsave(&iommu->lock, flags);
-        invalidate_interrupt_table(iommu, req_id);
+        amd_iommu_flush_intremap(iommu, req_id);
         if ( alias_id != req_id )
-            invalidate_interrupt_table(iommu, alias_id);
-        flush_command_buffer(iommu);
+            amd_iommu_flush_intremap(iommu, alias_id);
         spin_unlock_irqrestore(&iommu->lock, flags);
     }
 }
diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Fri Nov 18 11:07:40 2011 +0100
@@ -27,220 +27,6 @@
 #include "../ats.h"
 #include <xen/pci.h>
 
-static int queue_iommu_command(struct amd_iommu *iommu, u32 cmd[])
-{
-    u32 tail, head, *cmd_buffer;
-    int i;
-
-    tail = iommu->cmd_buffer_tail;
-    if ( ++tail == iommu->cmd_buffer.entries )
-        tail = 0;
-    head = get_field_from_reg_u32(
-        readl(iommu->mmio_base+IOMMU_CMD_BUFFER_HEAD_OFFSET),
-        IOMMU_CMD_BUFFER_HEAD_MASK,
-        IOMMU_CMD_BUFFER_HEAD_SHIFT);
-    if ( head != tail )
-    {
-        cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
-                             (iommu->cmd_buffer_tail *
-                              IOMMU_CMD_BUFFER_ENTRY_SIZE));
-        for ( i = 0; i < IOMMU_CMD_BUFFER_U32_PER_ENTRY; i++ )
-            cmd_buffer[i] = cmd[i];
-
-        iommu->cmd_buffer_tail = tail;
-        return 1;
-    }
-
-    return 0;
-}
-
-static void commit_iommu_command_buffer(struct amd_iommu *iommu)
-{
-    u32 tail;
-
-    set_field_in_reg_u32(iommu->cmd_buffer_tail, 0,
-                         IOMMU_CMD_BUFFER_TAIL_MASK,
-                         IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
-    writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
-}
-
-int send_iommu_command(struct amd_iommu *iommu, u32 cmd[])
-{
-    if ( queue_iommu_command(iommu, cmd) )
-    {
-        commit_iommu_command_buffer(iommu);
-        return 1;
-    }
-
-    return 0;
-}
-
-static void invalidate_iommu_pages(struct amd_iommu *iommu,
-                                   u64 io_addr, u16 domain_id, u16 order)
-{
-    u64 addr_lo, addr_hi;
-    u32 cmd[4], entry;
-    int sflag = 0, pde = 0;
-
-    ASSERT ( order == 0 || order == 9 || order == 18 );
-
-    /* All pages associated with the domainID are invalidated */
-    if ( order || (io_addr == INV_IOMMU_ALL_PAGES_ADDRESS ) )
-    {
-        sflag = 1;
-        pde = 1;
-    }
-
-    /* If sflag == 1, the size of the invalidate command is determined
-     by the first zero bit in the address starting from Address[12] */
-    if ( order )
-    {
-        u64 mask = 1ULL << (order - 1 + PAGE_SHIFT);
-        io_addr &= ~mask;
-        io_addr |= mask - 1;
-    }
-
-    addr_lo = io_addr & DMA_32BIT_MASK;
-    addr_hi = io_addr >> 32;
-
-    set_field_in_reg_u32(domain_id, 0,
-                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
-                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT, &entry);
-    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_IOMMU_PAGES, entry,
-                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
-                         &entry);
-    cmd[1] = entry;
-
-    set_field_in_reg_u32(sflag, 0,
-                         IOMMU_INV_IOMMU_PAGES_S_FLAG_MASK,
-                         IOMMU_INV_IOMMU_PAGES_S_FLAG_SHIFT, &entry);
-    set_field_in_reg_u32(pde, entry,
-                         IOMMU_INV_IOMMU_PAGES_PDE_FLAG_MASK,
-                         IOMMU_INV_IOMMU_PAGES_PDE_FLAG_SHIFT, &entry);
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, entry,
-                         IOMMU_INV_IOMMU_PAGES_ADDR_LOW_MASK,
-                         IOMMU_INV_IOMMU_PAGES_ADDR_LOW_SHIFT, &entry);
-    cmd[2] = entry;
-
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_INV_IOMMU_PAGES_ADDR_HIGH_MASK,
-                         IOMMU_INV_IOMMU_PAGES_ADDR_HIGH_SHIFT, &entry);
-    cmd[3] = entry;
-
-    cmd[0] = 0;
-    send_iommu_command(iommu, cmd);
-}
-
-static void invalidate_iotlb_pages(struct amd_iommu *iommu,
-                                   u16 maxpend, u32 pasid, u16 queueid,
-                                   u64 io_addr, u16 dev_id, u16 order)
-{
-    u64 addr_lo, addr_hi;
-    u32 cmd[4], entry;
-    int sflag = 0;
-
-    ASSERT ( order == 0 || order == 9 || order == 18 );
-
-    if ( order || (io_addr == INV_IOMMU_ALL_PAGES_ADDRESS ) )
-        sflag = 1;
-
-    /* If sflag == 1, the size of the invalidate command is determined
-     by the first zero bit in the address starting from Address[12] */
-    if ( order )
-    {
-        u64 mask = 1ULL << (order - 1 + PAGE_SHIFT);
-        io_addr &= ~mask;
-        io_addr |= mask - 1;
-    }
-
-    addr_lo = io_addr & DMA_32BIT_MASK;
-    addr_hi = io_addr >> 32;
-
-    set_field_in_reg_u32(dev_id, 0,
-                         IOMMU_INV_IOTLB_PAGES_DEVICE_ID_MASK,
-                         IOMMU_INV_IOTLB_PAGES_DEVICE_ID_SHIFT, &entry);
-
-    set_field_in_reg_u32(maxpend, entry,
-                         IOMMU_INV_IOTLB_PAGES_MAXPEND_MASK,
-                         IOMMU_INV_IOTLB_PAGES_MAXPEND_SHIFT, &entry);
-
-    set_field_in_reg_u32(pasid & 0xff, entry,
-                         IOMMU_INV_IOTLB_PAGES_PASID1_MASK,
-                         IOMMU_INV_IOTLB_PAGES_PASID1_SHIFT, &entry);
-    cmd[0] = entry;
-
-    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_IOTLB_PAGES, 0,
-                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
-                         &entry);
-
-    set_field_in_reg_u32(pasid >> 8, entry,
-                         IOMMU_INV_IOTLB_PAGES_PASID2_MASK,
-                         IOMMU_INV_IOTLB_PAGES_PASID2_SHIFT,
-                         &entry);
-
-    set_field_in_reg_u32(queueid, entry,
-                         IOMMU_INV_IOTLB_PAGES_QUEUEID_MASK,
-                         IOMMU_INV_IOTLB_PAGES_QUEUEID_SHIFT,
-                         &entry);
-    cmd[1] = entry;
-
-    set_field_in_reg_u32(sflag, 0,
-                         IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK,
-                         IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK, &entry);
-
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, entry,
-                         IOMMU_INV_IOTLB_PAGES_ADDR_LOW_MASK,
-                         IOMMU_INV_IOTLB_PAGES_ADDR_LOW_SHIFT, &entry);
-    cmd[2] = entry;
-
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_INV_IOTLB_PAGES_ADDR_HIGH_MASK,
-                         IOMMU_INV_IOTLB_PAGES_ADDR_HIGH_SHIFT, &entry);
-    cmd[3] = entry;
-
-    send_iommu_command(iommu, cmd);
-}
-void flush_command_buffer(struct amd_iommu *iommu)
-{
-    u32 cmd[4], status;
-    int loop_count, comp_wait;
-
-    /* clear 'ComWaitInt' in status register (WIC) */
-    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, 0,
-                         IOMMU_STATUS_COMP_WAIT_INT_MASK,
-                         IOMMU_STATUS_COMP_WAIT_INT_SHIFT, &status);
-    writel(status, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-
-    /* send an empty COMPLETION_WAIT command to flush command buffer */
-    cmd[3] = cmd[2] = 0;
-    set_field_in_reg_u32(IOMMU_CMD_COMPLETION_WAIT, 0,
-                         IOMMU_CMD_OPCODE_MASK,
-                         IOMMU_CMD_OPCODE_SHIFT, &cmd[1]);
-    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, 0,
-                         IOMMU_COMP_WAIT_I_FLAG_MASK,
-                         IOMMU_COMP_WAIT_I_FLAG_SHIFT, &cmd[0]);
-    send_iommu_command(iommu, cmd);
-
-    /* Make loop_count long enough for polling completion wait bit */
-    loop_count = 1000;
-    do {
-        status = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-        comp_wait = get_field_from_reg_u32(status,
-            IOMMU_STATUS_COMP_WAIT_INT_MASK,
-            IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
-        --loop_count;
-    } while ( !comp_wait && loop_count );
-
-    if ( comp_wait )
-    {
-        /* clear 'ComWaitInt' in status register (WIC) */
-        status &= IOMMU_STATUS_COMP_WAIT_INT_MASK;
-        writel(status, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-        return;
-    }
-    AMD_IOMMU_DEBUG("Warning: ComWaitInt bit did not assert!\n");
-}
-
 /* Given pfn and page table level, return pde index */
 static unsigned int pfn_to_pde_idx(unsigned long pfn, unsigned int level)
 {
@@ -480,25 +266,6 @@ static int amd_iommu_is_pte_present(u32 
                                   IOMMU_PDE_PRESENT_SHIFT);
 }
 
-void invalidate_dev_table_entry(struct amd_iommu *iommu,
-                                u16 device_id)
-{
-    u32 cmd[4], entry;
-
-    cmd[3] = cmd[2] = 0;
-    set_field_in_reg_u32(device_id, 0,
-                         IOMMU_INV_DEVTAB_ENTRY_DEVICE_ID_MASK,
-                         IOMMU_INV_DEVTAB_ENTRY_DEVICE_ID_SHIFT, &entry);
-    cmd[0] = entry;
-
-    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY, 0,
-                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
-                         &entry);
-    cmd[1] = entry;
-
-    send_iommu_command(iommu, cmd);
-}
-
 /* For each pde, We use ignored bits (bit 1 - bit 8 and bit 63)
  * to save pde count, pde count = 511 is a candidate of page coalescing.
  */
@@ -809,8 +576,7 @@ static int update_paging_mode(struct dom
                                           hd->domain_id,
                                           hd->paging_mode, 1);
 
-            invalidate_dev_table_entry(iommu, req_id);
-            flush_command_buffer(iommu);
+            amd_iommu_flush_device(iommu, req_id);
             spin_unlock_irqrestore(&iommu->lock, flags);
         }
 
@@ -967,94 +733,6 @@ int amd_iommu_reserve_domain_unity_map(s
     return 0;
 }
 
-void amd_iommu_flush_iotlb(struct pci_dev *pdev,
-                           uint64_t gaddr, unsigned int order)
-{
-    unsigned long flags;
-    struct amd_iommu *iommu;
-    unsigned int bdf, req_id, queueid, maxpend;
-    struct pci_ats_dev *ats_pdev;
-
-    if ( !ats_enabled )
-        return;
-
-    ats_pdev = get_ats_device(pdev->seg, pdev->bus, pdev->devfn);
-    if ( ats_pdev == NULL )
-        return;
-
-    if ( !pci_ats_enabled(ats_pdev->seg, ats_pdev->bus, ats_pdev->devfn) )
-        return;
-
-    bdf = PCI_BDF2(ats_pdev->bus, ats_pdev->devfn);
-    iommu = find_iommu_for_device(ats_pdev->seg, bdf);
-
-    if ( !iommu )
-    {
-        AMD_IOMMU_DEBUG("%s: Can't find iommu for %04x:%02x:%02x.%u\n",
-                        __func__, ats_pdev->seg, ats_pdev->bus,
-                        PCI_SLOT(ats_pdev->devfn), PCI_FUNC(ats_pdev->devfn));
-        return;
-    }
-
-    if ( !iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
-        return;
-
-    req_id = get_dma_requestor_id(iommu->seg, bdf);
-    queueid = req_id;
-    maxpend = (ats_pdev->ats_queue_depth + 32) & 0xff;
-
-    /* send INVALIDATE_IOTLB_PAGES command */
-    spin_lock_irqsave(&iommu->lock, flags);
-    invalidate_iotlb_pages(iommu, maxpend, 0, queueid, gaddr, req_id, order);
-    flush_command_buffer(iommu);
-    spin_unlock_irqrestore(&iommu->lock, flags);
-}
-
-static void amd_iommu_flush_all_iotlbs(struct domain *d, uint64_t gaddr,
-                                       unsigned int order)
-{
-    struct pci_dev *pdev;
-
-    if ( !ats_enabled )
-        return;
-
-    for_each_pdev( d, pdev )
-        amd_iommu_flush_iotlb(pdev, gaddr, order);
-}
-
-/* Flush iommu cache after p2m changes. */
-static void _amd_iommu_flush_pages(struct domain *d,
-                                   uint64_t gaddr, unsigned int order)
-{
-    unsigned long flags;
-    struct amd_iommu *iommu;
-    struct hvm_iommu *hd = domain_hvm_iommu(d);
-    unsigned int dom_id = hd->domain_id;
-
-    /* send INVALIDATE_IOMMU_PAGES command */
-    for_each_amd_iommu ( iommu )
-    {
-        spin_lock_irqsave(&iommu->lock, flags);
-        invalidate_iommu_pages(iommu, gaddr, dom_id, order);
-        flush_command_buffer(iommu);
-        spin_unlock_irqrestore(&iommu->lock, flags);
-    }
-
-    if ( ats_enabled )
-        amd_iommu_flush_all_iotlbs(d, gaddr, order);
-}
-
-void amd_iommu_flush_all_pages(struct domain *d)
-{
-    _amd_iommu_flush_pages(d, INV_IOMMU_ALL_PAGES_ADDRESS, 0);
-}
-
-void amd_iommu_flush_pages(struct domain *d,
-                           unsigned long gfn, unsigned int order)
-{
-    _amd_iommu_flush_pages(d, (uint64_t) gfn << PAGE_SHIFT, order);
-}
-
 /* Share p2m table with iommu. */
 void amd_iommu_share_p2m(struct domain *d)
 {
diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Fri Nov 18 11:07:40 2011 +0100
@@ -118,8 +118,7 @@ static void amd_iommu_setup_domain_devic
              iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
             iommu_dte_set_iotlb((u32 *)dte, dte_i);
 
-        invalidate_dev_table_entry(iommu, req_id);
-        flush_command_buffer(iommu);
+        amd_iommu_flush_device(iommu, req_id);
 
         AMD_IOMMU_DEBUG("Setup I/O page table: device id = 0x%04x, "
                         "root table = 0x%"PRIx64", "
@@ -310,8 +309,8 @@ void amd_iommu_disable_domain_device(str
              iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
             iommu_dte_set_iotlb((u32 *)dte, 0);
 
-        invalidate_dev_table_entry(iommu, req_id);
-        flush_command_buffer(iommu);
+        amd_iommu_flush_device(iommu, req_id);
+
         AMD_IOMMU_DEBUG("Disable: device id = 0x%04x, "
                         "domain = %d, paging mode = %d\n",
                         req_id,  domain_hvm_iommu(domain)->domain_id,
diff -r 135678ae1bbc -r 6ef12cc262fb xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Fri Nov 18 11:07:40 2011 +0100
@@ -53,12 +53,6 @@ int amd_iommu_update_ivrs_mapping_acpi(v
 int amd_iommu_map_page(struct domain *d, unsigned long gfn, unsigned long mfn,
                        unsigned int flags);
 int amd_iommu_unmap_page(struct domain *d, unsigned long gfn);
-void amd_iommu_flush_pages(struct domain *d, unsigned long gfn,
-                           unsigned int order);
-void amd_iommu_flush_all_pages(struct domain *d);
-void amd_iommu_flush_iotlb(struct pci_dev *pdev, uint64_t gaddr,
-                           unsigned int order);
-
 u64 amd_iommu_get_next_table_from_pte(u32 *entry);
 int amd_iommu_reserve_domain_unity_map(struct domain *domain,
                                        u64 phys_addr, unsigned long size,
@@ -75,11 +69,15 @@ void amd_iommu_set_root_page_table(
     u32 *dte, u64 root_ptr, u16 domain_id, u8 paging_mode, u8 valid);
 void iommu_dte_set_iotlb(u32 *dte, u8 i);
 void iommu_dte_add_device_entry(u32 *dte, struct ivrs_mappings *ivrs_dev);
-void invalidate_dev_table_entry(struct amd_iommu *iommu, u16 devic_id);
 
 /* send cmd to iommu */
-int send_iommu_command(struct amd_iommu *iommu, u32 cmd[]);
-void flush_command_buffer(struct amd_iommu *iommu);
+void amd_iommu_flush_all_pages(struct domain *d);
+void amd_iommu_flush_pages(struct domain *d, unsigned long gfn,
+                           unsigned int order);
+void amd_iommu_flush_iotlb(struct pci_dev *pdev, uint64_t gaddr,
+                           unsigned int order);
+void amd_iommu_flush_device(struct amd_iommu *iommu, uint16_t bdf);
+void amd_iommu_flush_intremap(struct amd_iommu *iommu, uint16_t bdf);
 
 /* find iommu for bdf */
 struct amd_iommu *find_iommu_for_device(int seg, int bdf);
@@ -88,7 +86,6 @@ struct amd_iommu *find_iommu_for_device(
 int amd_iommu_setup_ioapic_remapping(void);
 void *amd_iommu_alloc_intremap_table(void);
 int amd_iommu_free_intremap_table(u16 seg, struct ivrs_mappings *);
-void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id);
 void amd_iommu_ioapic_update_ire(
     unsigned int apic, unsigned int reg, unsigned int value);
 void amd_iommu_msi_msg_update_ire(


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:54:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:54:40 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM5g-0003KL-0U
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:54:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM5J-0005TV-Op; Fri, 18 Nov 2011 02:54:18 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM3f-0004hb-Od
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:52:36 -0800
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1321613516!46436176!1
X-Originating-IP: [216.32.180.14]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28636 invoked from network); 18 Nov 2011 10:51:57 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	VA3EHSOBE004.bigfish.com) (216.32.180.14)
	by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Nov 2011 10:51:57 -0000
Received: from mail26-va3-R.bigfish.com (10.7.14.243) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:51:57 +0000
Received: from mail26-va3 (localhost [127.0.0.1])	by mail26-va3-R.bigfish.com
	(Postfix) with ESMTP id 42B9A220176;
	Fri, 18 Nov 2011 10:53:49 +0000 (UTC)
X-SpamScore: 8
X-BigFish: VPS8(z3c23mzc8kzz1202hzz8275bhz2dh668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail26-va3 (localhost.localdomain [127.0.0.1]) by mail26-va3
	(MessageSwitch) id 1321613622462717_19136;
	Fri, 18 Nov 2011 10:53:42 +0000 (UTC)
Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.240])	by
	mail26-va3.bigfish.com (Postfix) with ESMTP id 45F2D580164;
	Fri, 18 Nov 2011 10:51:45 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server id
	14.1.225.22; Fri, 18 Nov 2011 10:49:50 +0000
X-WSS-ID: 0LUURFW-02-C9E-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DAD7C80CE;	Fri, 18 Nov 2011 04:50:19 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 18 Nov 2011 04:51:50 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 18 Nov 2011 04:50:20 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 18 Nov 2011
	05:50:12 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 9B9B049C623; Fri, 18 Nov 2011
	10:50:10 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 889BB594882; Fri, 18 Nov 2011
	11:50:10 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 6ef12cc262fb3ac11f9ea58707afb4f7778017ac
Message-ID: <6ef12cc262fb3ac11f9e.1321612944@gran.amd.com>
In-Reply-To: <patchbomb.1321612941@gran.amd.com>
References: <patchbomb.1321612941@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Fri, 18 Nov 2011 11:42:24 +0100
From: Wei Wang <wei.wang2@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 4] amd iommu: Factor out iommu command
	handling functions, 
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1321610860 -3600
# Node ID 6ef12cc262fb3ac11f9ea58707afb4f7778017ac
# Parent  135678ae1bbc02171294c21e2a5469d898d2a353
amd iommu: Factor out iommu command handling functions,
and move them into a new file.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/Makefile
--- a/xen/drivers/passthrough/amd/Makefile	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/drivers/passthrough/amd/Makefile	Fri Nov 18 11:07:40 2011 +0100
@@ -4,3 +4,4 @@ obj-y += iommu_map.o
 obj-y += pci_amd_iommu.o
 obj-bin-y += iommu_acpi.init.o
 obj-y += iommu_intr.o
+obj-y += iommu_cmd.o
diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/iommu_cmd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Fri Nov 18 11:07:40 2011 +0100
@@ -0,0 +1,382 @@
+/*
+ * Copyright (C) 2011 Advanced Micro Devices, Inc.
+ * Author: Leo Duran <leo.duran@amd.com>
+ * Author: Wei Wang <wei.wang2@amd.com> - adapted to xen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ */
+
+#include <xen/sched.h>
+#include <xen/hvm/iommu.h>
+#include <asm/amd-iommu.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
+#include "../ats.h"
+
+static int queue_iommu_command(struct amd_iommu *iommu, u32 cmd[])
+{
+    u32 tail, head, *cmd_buffer;
+    int i;
+
+    tail = iommu->cmd_buffer_tail;
+    if ( ++tail == iommu->cmd_buffer.entries )
+        tail = 0;
+
+    head = get_field_from_reg_u32(readl(iommu->mmio_base + 
+                                        IOMMU_CMD_BUFFER_HEAD_OFFSET),
+                                  IOMMU_CMD_BUFFER_HEAD_MASK,
+                                  IOMMU_CMD_BUFFER_HEAD_SHIFT);
+    if ( head != tail )
+    {
+        cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
+                             (iommu->cmd_buffer_tail *
+                             IOMMU_CMD_BUFFER_ENTRY_SIZE));
+
+        for ( i = 0; i < IOMMU_CMD_BUFFER_U32_PER_ENTRY; i++ )
+            cmd_buffer[i] = cmd[i];
+
+        iommu->cmd_buffer_tail = tail;
+        return 1;
+    }
+
+    return 0;
+}
+
+static void commit_iommu_command_buffer(struct amd_iommu *iommu)
+{
+    u32 tail;
+
+    set_field_in_reg_u32(iommu->cmd_buffer_tail, 0,
+                         IOMMU_CMD_BUFFER_TAIL_MASK,
+                         IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
+    writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
+}
+
+int send_iommu_command(struct amd_iommu *iommu, u32 cmd[])
+{
+    if ( queue_iommu_command(iommu, cmd) )
+    {
+        commit_iommu_command_buffer(iommu);
+        return 1;
+    }
+
+    return 0;
+}
+
+static void flush_command_buffer(struct amd_iommu *iommu)
+{
+    u32 cmd[4], status;
+    int loop_count, comp_wait;
+
+    /* clear 'ComWaitInt' in status register (WIC) */
+    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, 0,
+                         IOMMU_STATUS_COMP_WAIT_INT_MASK,
+                         IOMMU_STATUS_COMP_WAIT_INT_SHIFT, &status);
+    writel(status, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+
+    /* send an empty COMPLETION_WAIT command to flush command buffer */
+    cmd[3] = cmd[2] = 0;
+    set_field_in_reg_u32(IOMMU_CMD_COMPLETION_WAIT, 0,
+                         IOMMU_CMD_OPCODE_MASK,
+                         IOMMU_CMD_OPCODE_SHIFT, &cmd[1]);
+    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, 0,
+                         IOMMU_COMP_WAIT_I_FLAG_MASK,
+                         IOMMU_COMP_WAIT_I_FLAG_SHIFT, &cmd[0]);
+    send_iommu_command(iommu, cmd);
+
+    /* Make loop_count long enough for polling completion wait bit */
+    loop_count = 1000;
+    do {
+        status = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+        comp_wait = get_field_from_reg_u32(status,
+                                           IOMMU_STATUS_COMP_WAIT_INT_MASK,
+                                           IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
+        --loop_count;
+    } while ( !comp_wait && loop_count );
+
+    if ( comp_wait )
+    {
+        /* clear 'ComWaitInt' in status register (WIC) */
+        status &= IOMMU_STATUS_COMP_WAIT_INT_MASK;
+        writel(status, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+        return;
+    }
+    AMD_IOMMU_DEBUG("Warning: ComWaitInt bit did not assert!\n");
+}
+
+/* Build low level iommu command messages */
+static void invalidate_iommu_pages(struct amd_iommu *iommu,
+                                   u64 io_addr, u16 domain_id, u16 order)
+{
+    u64 addr_lo, addr_hi;
+    u32 cmd[4], entry;
+    int sflag = 0, pde = 0;
+
+    ASSERT ( order == 0 || order == 9 || order == 18 );
+
+    /* All pages associated with the domainID are invalidated */
+    if ( order || (io_addr == INV_IOMMU_ALL_PAGES_ADDRESS ) )
+    {
+        sflag = 1;
+        pde = 1;
+    }
+
+    /* If sflag == 1, the size of the invalidate command is determined
+     by the first zero bit in the address starting from Address[12] */
+    if ( order )
+    {
+        u64 mask = 1ULL << (order - 1 + PAGE_SHIFT);
+        io_addr &= ~mask;
+        io_addr |= mask - 1;
+    }
+
+    addr_lo = io_addr & DMA_32BIT_MASK;
+    addr_hi = io_addr >> 32;
+
+    set_field_in_reg_u32(domain_id, 0,
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
+                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT, &entry);
+    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_IOMMU_PAGES, entry,
+                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
+                         &entry);
+    cmd[1] = entry;
+
+    set_field_in_reg_u32(sflag, 0,
+                         IOMMU_INV_IOMMU_PAGES_S_FLAG_MASK,
+                         IOMMU_INV_IOMMU_PAGES_S_FLAG_SHIFT, &entry);
+    set_field_in_reg_u32(pde, entry,
+                         IOMMU_INV_IOMMU_PAGES_PDE_FLAG_MASK,
+                         IOMMU_INV_IOMMU_PAGES_PDE_FLAG_SHIFT, &entry);
+    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, entry,
+                         IOMMU_INV_IOMMU_PAGES_ADDR_LOW_MASK,
+                         IOMMU_INV_IOMMU_PAGES_ADDR_LOW_SHIFT, &entry);
+    cmd[2] = entry;
+
+    set_field_in_reg_u32((u32)addr_hi, 0,
+                         IOMMU_INV_IOMMU_PAGES_ADDR_HIGH_MASK,
+                         IOMMU_INV_IOMMU_PAGES_ADDR_HIGH_SHIFT, &entry);
+    cmd[3] = entry;
+
+    cmd[0] = 0;
+    send_iommu_command(iommu, cmd);
+}
+
+static void invalidate_iotlb_pages(struct amd_iommu *iommu,
+                                   u16 maxpend, u32 pasid, u16 queueid,
+                                   u64 io_addr, u16 dev_id, u16 order)
+{
+    u64 addr_lo, addr_hi;
+    u32 cmd[4], entry;
+    int sflag = 0;
+
+    ASSERT ( order == 0 || order == 9 || order == 18 );
+
+    if ( order || (io_addr == INV_IOMMU_ALL_PAGES_ADDRESS ) )
+        sflag = 1;
+
+    /* If sflag == 1, the size of the invalidate command is determined
+     by the first zero bit in the address starting from Address[12] */
+    if ( order )
+    {
+        u64 mask = 1ULL << (order - 1 + PAGE_SHIFT);
+        io_addr &= ~mask;
+        io_addr |= mask - 1;
+    }
+
+    addr_lo = io_addr & DMA_32BIT_MASK;
+    addr_hi = io_addr >> 32;
+
+    set_field_in_reg_u32(dev_id, 0,
+                         IOMMU_INV_IOTLB_PAGES_DEVICE_ID_MASK,
+                         IOMMU_INV_IOTLB_PAGES_DEVICE_ID_SHIFT, &entry);
+
+    set_field_in_reg_u32(maxpend, entry,
+                         IOMMU_INV_IOTLB_PAGES_MAXPEND_MASK,
+                         IOMMU_INV_IOTLB_PAGES_MAXPEND_SHIFT, &entry);
+
+    set_field_in_reg_u32(pasid & 0xff, entry,
+                         IOMMU_INV_IOTLB_PAGES_PASID1_MASK,
+                         IOMMU_INV_IOTLB_PAGES_PASID1_SHIFT, &entry);
+    cmd[0] = entry;
+
+    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_IOTLB_PAGES, 0,
+                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
+                         &entry);
+
+    set_field_in_reg_u32(pasid >> 8, entry,
+                         IOMMU_INV_IOTLB_PAGES_PASID2_MASK,
+                         IOMMU_INV_IOTLB_PAGES_PASID2_SHIFT,
+                         &entry);
+
+    set_field_in_reg_u32(queueid, entry,
+                         IOMMU_INV_IOTLB_PAGES_QUEUEID_MASK,
+                         IOMMU_INV_IOTLB_PAGES_QUEUEID_SHIFT,
+                         &entry);
+    cmd[1] = entry;
+
+    set_field_in_reg_u32(sflag, 0,
+                         IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK,
+                         IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK, &entry);
+
+    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, entry,
+                         IOMMU_INV_IOTLB_PAGES_ADDR_LOW_MASK,
+                         IOMMU_INV_IOTLB_PAGES_ADDR_LOW_SHIFT, &entry);
+    cmd[2] = entry;
+
+    set_field_in_reg_u32((u32)addr_hi, 0,
+                         IOMMU_INV_IOTLB_PAGES_ADDR_HIGH_MASK,
+                         IOMMU_INV_IOTLB_PAGES_ADDR_HIGH_SHIFT, &entry);
+    cmd[3] = entry;
+
+    send_iommu_command(iommu, cmd);
+}
+
+static void invalidate_dev_table_entry(struct amd_iommu *iommu,
+                                       u16 device_id)
+{
+    u32 cmd[4], entry;
+
+    cmd[3] = cmd[2] = 0;
+    set_field_in_reg_u32(device_id, 0,
+                         IOMMU_INV_DEVTAB_ENTRY_DEVICE_ID_MASK,
+                         IOMMU_INV_DEVTAB_ENTRY_DEVICE_ID_SHIFT, &entry);
+    cmd[0] = entry;
+
+    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY, 0,
+                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
+                         &entry);
+    cmd[1] = entry;
+
+    send_iommu_command(iommu, cmd);
+}
+
+static void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id)
+{
+    u32 cmd[4], entry;
+
+    cmd[3] = cmd[2] = 0;
+    set_field_in_reg_u32(device_id, 0,
+                         IOMMU_INV_INT_TABLE_DEVICE_ID_MASK,
+                         IOMMU_INV_INT_TABLE_DEVICE_ID_SHIFT, &entry);
+    cmd[0] = entry;
+    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_INT_TABLE, 0,
+                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
+                         &entry);
+    cmd[1] = entry;
+    send_iommu_command(iommu, cmd);
+}
+
+void amd_iommu_flush_iotlb(struct pci_dev *pdev,
+                           uint64_t gaddr, unsigned int order)
+{
+    unsigned long flags;
+    struct amd_iommu *iommu;
+    unsigned int bdf, req_id, queueid, maxpend;
+    struct pci_ats_dev *ats_pdev;
+
+    if ( !ats_enabled )
+        return;
+
+    ats_pdev = get_ats_device(pdev->seg, pdev->bus, pdev->devfn);
+    if ( ats_pdev == NULL )
+        return;
+
+    if ( !pci_ats_enabled(ats_pdev->seg, ats_pdev->bus, ats_pdev->devfn) )
+        return;
+
+    bdf = PCI_BDF2(ats_pdev->bus, ats_pdev->devfn);
+    iommu = find_iommu_for_device(ats_pdev->seg, bdf);
+
+    if ( !iommu )
+    {
+        AMD_IOMMU_DEBUG("%s: Can't find iommu for %04x:%02x:%02x.%u\n",
+                        __func__, ats_pdev->seg, ats_pdev->bus,
+                        PCI_SLOT(ats_pdev->devfn), PCI_FUNC(ats_pdev->devfn));
+        return;
+    }
+
+    if ( !iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
+        return;
+
+    req_id = get_dma_requestor_id(iommu->seg, bdf);
+    queueid = req_id;
+    maxpend = (ats_pdev->ats_queue_depth + 32) & 0xff;
+
+    /* send INVALIDATE_IOTLB_PAGES command */
+    spin_lock_irqsave(&iommu->lock, flags);
+    invalidate_iotlb_pages(iommu, maxpend, 0, queueid, gaddr, req_id, order);
+    flush_command_buffer(iommu);
+    spin_unlock_irqrestore(&iommu->lock, flags);
+}
+
+static void amd_iommu_flush_all_iotlbs(struct domain *d, uint64_t gaddr,
+                                       unsigned int order)
+{
+    struct pci_dev *pdev;
+
+    if ( !ats_enabled )
+        return;
+
+    for_each_pdev( d, pdev )
+        amd_iommu_flush_iotlb(pdev, gaddr, order);
+}
+
+/* Flush iommu cache after p2m changes. */
+static void _amd_iommu_flush_pages(struct domain *d,
+                                   uint64_t gaddr, unsigned int order)
+{
+    unsigned long flags;
+    struct amd_iommu *iommu;
+    struct hvm_iommu *hd = domain_hvm_iommu(d);
+    unsigned int dom_id = hd->domain_id;
+
+    /* send INVALIDATE_IOMMU_PAGES command */
+    for_each_amd_iommu ( iommu )
+    {
+        spin_lock_irqsave(&iommu->lock, flags);
+        invalidate_iommu_pages(iommu, gaddr, dom_id, order);
+        flush_command_buffer(iommu);
+        spin_unlock_irqrestore(&iommu->lock, flags);
+    }
+
+    if ( ats_enabled )
+        amd_iommu_flush_all_iotlbs(d, gaddr, order);
+}
+
+void amd_iommu_flush_all_pages(struct domain *d)
+{
+    _amd_iommu_flush_pages(d, INV_IOMMU_ALL_PAGES_ADDRESS, 0);
+}
+
+void amd_iommu_flush_pages(struct domain *d,
+                           unsigned long gfn, unsigned int order)
+{
+    _amd_iommu_flush_pages(d, (uint64_t) gfn << PAGE_SHIFT, order);
+}
+
+void amd_iommu_flush_device(struct amd_iommu *iommu, uint16_t bdf)
+{
+    ASSERT( spin_is_locked(&iommu->lock) );
+
+    invalidate_dev_table_entry(iommu, bdf);
+    flush_command_buffer(iommu);
+}
+
+void amd_iommu_flush_intremap(struct amd_iommu *iommu, uint16_t bdf)
+{
+    ASSERT( spin_is_locked(&iommu->lock) );
+
+    invalidate_interrupt_table(iommu, bdf);
+    flush_command_buffer(iommu);
+}
diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Fri Nov 18 11:07:40 2011 +0100
@@ -933,9 +933,8 @@ static int _invalidate_all_devices(
         if ( iommu )
         {
             spin_lock_irqsave(&iommu->lock, flags);
-            invalidate_dev_table_entry(iommu, req_id);
-            invalidate_interrupt_table(iommu, req_id);
-            flush_command_buffer(iommu);
+            amd_iommu_flush_device(iommu, req_id);
+            amd_iommu_flush_intremap(iommu, req_id);
             spin_unlock_irqrestore(&iommu->lock, flags);
         }
     }
diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/iommu_intr.c
--- a/xen/drivers/passthrough/amd/iommu_intr.c	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_intr.c	Fri Nov 18 11:07:40 2011 +0100
@@ -96,22 +96,6 @@ static void update_intremap_entry(u32* e
                             INT_REMAP_ENTRY_VECTOR_SHIFT, entry);
 }
 
-void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id)
-{
-    u32 cmd[4], entry;
-
-    cmd[3] = cmd[2] = 0;
-    set_field_in_reg_u32(device_id, 0,
-                         IOMMU_INV_INT_TABLE_DEVICE_ID_MASK,
-                         IOMMU_INV_INT_TABLE_DEVICE_ID_SHIFT, &entry);
-    cmd[0] = entry;
-    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_INT_TABLE, 0,
-                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
-                         &entry);
-    cmd[1] = entry;
-    send_iommu_command(iommu, cmd);
-}
-
 static void update_intremap_entry_from_ioapic(
     int bdf,
     struct amd_iommu *iommu,
@@ -144,8 +128,7 @@ static void update_intremap_entry_from_i
     if ( iommu->enabled )
     {
         spin_lock_irqsave(&iommu->lock, flags);
-        invalidate_interrupt_table(iommu, req_id);
-        flush_command_buffer(iommu);
+        amd_iommu_flush_intremap(iommu, req_id);
         spin_unlock_irqrestore(&iommu->lock, flags);
     }
 }
@@ -202,8 +185,7 @@ int __init amd_iommu_setup_ioapic_remapp
             if ( iommu->enabled )
             {
                 spin_lock_irqsave(&iommu->lock, flags);
-                invalidate_interrupt_table(iommu, req_id);
-                flush_command_buffer(iommu);
+                amd_iommu_flush_intremap(iommu, req_id);
                 spin_unlock_irqrestore(&iommu->lock, flags);
             }
         }
@@ -347,10 +329,9 @@ done:
     if ( iommu->enabled )
     {
         spin_lock_irqsave(&iommu->lock, flags);
-        invalidate_interrupt_table(iommu, req_id);
+        amd_iommu_flush_intremap(iommu, req_id);
         if ( alias_id != req_id )
-            invalidate_interrupt_table(iommu, alias_id);
-        flush_command_buffer(iommu);
+            amd_iommu_flush_intremap(iommu, alias_id);
         spin_unlock_irqrestore(&iommu->lock, flags);
     }
 }
diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Fri Nov 18 11:07:40 2011 +0100
@@ -27,220 +27,6 @@
 #include "../ats.h"
 #include <xen/pci.h>
 
-static int queue_iommu_command(struct amd_iommu *iommu, u32 cmd[])
-{
-    u32 tail, head, *cmd_buffer;
-    int i;
-
-    tail = iommu->cmd_buffer_tail;
-    if ( ++tail == iommu->cmd_buffer.entries )
-        tail = 0;
-    head = get_field_from_reg_u32(
-        readl(iommu->mmio_base+IOMMU_CMD_BUFFER_HEAD_OFFSET),
-        IOMMU_CMD_BUFFER_HEAD_MASK,
-        IOMMU_CMD_BUFFER_HEAD_SHIFT);
-    if ( head != tail )
-    {
-        cmd_buffer = (u32 *)(iommu->cmd_buffer.buffer +
-                             (iommu->cmd_buffer_tail *
-                              IOMMU_CMD_BUFFER_ENTRY_SIZE));
-        for ( i = 0; i < IOMMU_CMD_BUFFER_U32_PER_ENTRY; i++ )
-            cmd_buffer[i] = cmd[i];
-
-        iommu->cmd_buffer_tail = tail;
-        return 1;
-    }
-
-    return 0;
-}
-
-static void commit_iommu_command_buffer(struct amd_iommu *iommu)
-{
-    u32 tail;
-
-    set_field_in_reg_u32(iommu->cmd_buffer_tail, 0,
-                         IOMMU_CMD_BUFFER_TAIL_MASK,
-                         IOMMU_CMD_BUFFER_TAIL_SHIFT, &tail);
-    writel(tail, iommu->mmio_base+IOMMU_CMD_BUFFER_TAIL_OFFSET);
-}
-
-int send_iommu_command(struct amd_iommu *iommu, u32 cmd[])
-{
-    if ( queue_iommu_command(iommu, cmd) )
-    {
-        commit_iommu_command_buffer(iommu);
-        return 1;
-    }
-
-    return 0;
-}
-
-static void invalidate_iommu_pages(struct amd_iommu *iommu,
-                                   u64 io_addr, u16 domain_id, u16 order)
-{
-    u64 addr_lo, addr_hi;
-    u32 cmd[4], entry;
-    int sflag = 0, pde = 0;
-
-    ASSERT ( order == 0 || order == 9 || order == 18 );
-
-    /* All pages associated with the domainID are invalidated */
-    if ( order || (io_addr == INV_IOMMU_ALL_PAGES_ADDRESS ) )
-    {
-        sflag = 1;
-        pde = 1;
-    }
-
-    /* If sflag == 1, the size of the invalidate command is determined
-     by the first zero bit in the address starting from Address[12] */
-    if ( order )
-    {
-        u64 mask = 1ULL << (order - 1 + PAGE_SHIFT);
-        io_addr &= ~mask;
-        io_addr |= mask - 1;
-    }
-
-    addr_lo = io_addr & DMA_32BIT_MASK;
-    addr_hi = io_addr >> 32;
-
-    set_field_in_reg_u32(domain_id, 0,
-                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_MASK,
-                         IOMMU_INV_IOMMU_PAGES_DOMAIN_ID_SHIFT, &entry);
-    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_IOMMU_PAGES, entry,
-                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
-                         &entry);
-    cmd[1] = entry;
-
-    set_field_in_reg_u32(sflag, 0,
-                         IOMMU_INV_IOMMU_PAGES_S_FLAG_MASK,
-                         IOMMU_INV_IOMMU_PAGES_S_FLAG_SHIFT, &entry);
-    set_field_in_reg_u32(pde, entry,
-                         IOMMU_INV_IOMMU_PAGES_PDE_FLAG_MASK,
-                         IOMMU_INV_IOMMU_PAGES_PDE_FLAG_SHIFT, &entry);
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, entry,
-                         IOMMU_INV_IOMMU_PAGES_ADDR_LOW_MASK,
-                         IOMMU_INV_IOMMU_PAGES_ADDR_LOW_SHIFT, &entry);
-    cmd[2] = entry;
-
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_INV_IOMMU_PAGES_ADDR_HIGH_MASK,
-                         IOMMU_INV_IOMMU_PAGES_ADDR_HIGH_SHIFT, &entry);
-    cmd[3] = entry;
-
-    cmd[0] = 0;
-    send_iommu_command(iommu, cmd);
-}
-
-static void invalidate_iotlb_pages(struct amd_iommu *iommu,
-                                   u16 maxpend, u32 pasid, u16 queueid,
-                                   u64 io_addr, u16 dev_id, u16 order)
-{
-    u64 addr_lo, addr_hi;
-    u32 cmd[4], entry;
-    int sflag = 0;
-
-    ASSERT ( order == 0 || order == 9 || order == 18 );
-
-    if ( order || (io_addr == INV_IOMMU_ALL_PAGES_ADDRESS ) )
-        sflag = 1;
-
-    /* If sflag == 1, the size of the invalidate command is determined
-     by the first zero bit in the address starting from Address[12] */
-    if ( order )
-    {
-        u64 mask = 1ULL << (order - 1 + PAGE_SHIFT);
-        io_addr &= ~mask;
-        io_addr |= mask - 1;
-    }
-
-    addr_lo = io_addr & DMA_32BIT_MASK;
-    addr_hi = io_addr >> 32;
-
-    set_field_in_reg_u32(dev_id, 0,
-                         IOMMU_INV_IOTLB_PAGES_DEVICE_ID_MASK,
-                         IOMMU_INV_IOTLB_PAGES_DEVICE_ID_SHIFT, &entry);
-
-    set_field_in_reg_u32(maxpend, entry,
-                         IOMMU_INV_IOTLB_PAGES_MAXPEND_MASK,
-                         IOMMU_INV_IOTLB_PAGES_MAXPEND_SHIFT, &entry);
-
-    set_field_in_reg_u32(pasid & 0xff, entry,
-                         IOMMU_INV_IOTLB_PAGES_PASID1_MASK,
-                         IOMMU_INV_IOTLB_PAGES_PASID1_SHIFT, &entry);
-    cmd[0] = entry;
-
-    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_IOTLB_PAGES, 0,
-                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
-                         &entry);
-
-    set_field_in_reg_u32(pasid >> 8, entry,
-                         IOMMU_INV_IOTLB_PAGES_PASID2_MASK,
-                         IOMMU_INV_IOTLB_PAGES_PASID2_SHIFT,
-                         &entry);
-
-    set_field_in_reg_u32(queueid, entry,
-                         IOMMU_INV_IOTLB_PAGES_QUEUEID_MASK,
-                         IOMMU_INV_IOTLB_PAGES_QUEUEID_SHIFT,
-                         &entry);
-    cmd[1] = entry;
-
-    set_field_in_reg_u32(sflag, 0,
-                         IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK,
-                         IOMMU_INV_IOTLB_PAGES_S_FLAG_MASK, &entry);
-
-    set_field_in_reg_u32((u32)addr_lo >> PAGE_SHIFT, entry,
-                         IOMMU_INV_IOTLB_PAGES_ADDR_LOW_MASK,
-                         IOMMU_INV_IOTLB_PAGES_ADDR_LOW_SHIFT, &entry);
-    cmd[2] = entry;
-
-    set_field_in_reg_u32((u32)addr_hi, 0,
-                         IOMMU_INV_IOTLB_PAGES_ADDR_HIGH_MASK,
-                         IOMMU_INV_IOTLB_PAGES_ADDR_HIGH_SHIFT, &entry);
-    cmd[3] = entry;
-
-    send_iommu_command(iommu, cmd);
-}
-void flush_command_buffer(struct amd_iommu *iommu)
-{
-    u32 cmd[4], status;
-    int loop_count, comp_wait;
-
-    /* clear 'ComWaitInt' in status register (WIC) */
-    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, 0,
-                         IOMMU_STATUS_COMP_WAIT_INT_MASK,
-                         IOMMU_STATUS_COMP_WAIT_INT_SHIFT, &status);
-    writel(status, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-
-    /* send an empty COMPLETION_WAIT command to flush command buffer */
-    cmd[3] = cmd[2] = 0;
-    set_field_in_reg_u32(IOMMU_CMD_COMPLETION_WAIT, 0,
-                         IOMMU_CMD_OPCODE_MASK,
-                         IOMMU_CMD_OPCODE_SHIFT, &cmd[1]);
-    set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, 0,
-                         IOMMU_COMP_WAIT_I_FLAG_MASK,
-                         IOMMU_COMP_WAIT_I_FLAG_SHIFT, &cmd[0]);
-    send_iommu_command(iommu, cmd);
-
-    /* Make loop_count long enough for polling completion wait bit */
-    loop_count = 1000;
-    do {
-        status = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-        comp_wait = get_field_from_reg_u32(status,
-            IOMMU_STATUS_COMP_WAIT_INT_MASK,
-            IOMMU_STATUS_COMP_WAIT_INT_SHIFT);
-        --loop_count;
-    } while ( !comp_wait && loop_count );
-
-    if ( comp_wait )
-    {
-        /* clear 'ComWaitInt' in status register (WIC) */
-        status &= IOMMU_STATUS_COMP_WAIT_INT_MASK;
-        writel(status, iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
-        return;
-    }
-    AMD_IOMMU_DEBUG("Warning: ComWaitInt bit did not assert!\n");
-}
-
 /* Given pfn and page table level, return pde index */
 static unsigned int pfn_to_pde_idx(unsigned long pfn, unsigned int level)
 {
@@ -480,25 +266,6 @@ static int amd_iommu_is_pte_present(u32 
                                   IOMMU_PDE_PRESENT_SHIFT);
 }
 
-void invalidate_dev_table_entry(struct amd_iommu *iommu,
-                                u16 device_id)
-{
-    u32 cmd[4], entry;
-
-    cmd[3] = cmd[2] = 0;
-    set_field_in_reg_u32(device_id, 0,
-                         IOMMU_INV_DEVTAB_ENTRY_DEVICE_ID_MASK,
-                         IOMMU_INV_DEVTAB_ENTRY_DEVICE_ID_SHIFT, &entry);
-    cmd[0] = entry;
-
-    set_field_in_reg_u32(IOMMU_CMD_INVALIDATE_DEVTAB_ENTRY, 0,
-                         IOMMU_CMD_OPCODE_MASK, IOMMU_CMD_OPCODE_SHIFT,
-                         &entry);
-    cmd[1] = entry;
-
-    send_iommu_command(iommu, cmd);
-}
-
 /* For each pde, We use ignored bits (bit 1 - bit 8 and bit 63)
  * to save pde count, pde count = 511 is a candidate of page coalescing.
  */
@@ -809,8 +576,7 @@ static int update_paging_mode(struct dom
                                           hd->domain_id,
                                           hd->paging_mode, 1);
 
-            invalidate_dev_table_entry(iommu, req_id);
-            flush_command_buffer(iommu);
+            amd_iommu_flush_device(iommu, req_id);
             spin_unlock_irqrestore(&iommu->lock, flags);
         }
 
@@ -967,94 +733,6 @@ int amd_iommu_reserve_domain_unity_map(s
     return 0;
 }
 
-void amd_iommu_flush_iotlb(struct pci_dev *pdev,
-                           uint64_t gaddr, unsigned int order)
-{
-    unsigned long flags;
-    struct amd_iommu *iommu;
-    unsigned int bdf, req_id, queueid, maxpend;
-    struct pci_ats_dev *ats_pdev;
-
-    if ( !ats_enabled )
-        return;
-
-    ats_pdev = get_ats_device(pdev->seg, pdev->bus, pdev->devfn);
-    if ( ats_pdev == NULL )
-        return;
-
-    if ( !pci_ats_enabled(ats_pdev->seg, ats_pdev->bus, ats_pdev->devfn) )
-        return;
-
-    bdf = PCI_BDF2(ats_pdev->bus, ats_pdev->devfn);
-    iommu = find_iommu_for_device(ats_pdev->seg, bdf);
-
-    if ( !iommu )
-    {
-        AMD_IOMMU_DEBUG("%s: Can't find iommu for %04x:%02x:%02x.%u\n",
-                        __func__, ats_pdev->seg, ats_pdev->bus,
-                        PCI_SLOT(ats_pdev->devfn), PCI_FUNC(ats_pdev->devfn));
-        return;
-    }
-
-    if ( !iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
-        return;
-
-    req_id = get_dma_requestor_id(iommu->seg, bdf);
-    queueid = req_id;
-    maxpend = (ats_pdev->ats_queue_depth + 32) & 0xff;
-
-    /* send INVALIDATE_IOTLB_PAGES command */
-    spin_lock_irqsave(&iommu->lock, flags);
-    invalidate_iotlb_pages(iommu, maxpend, 0, queueid, gaddr, req_id, order);
-    flush_command_buffer(iommu);
-    spin_unlock_irqrestore(&iommu->lock, flags);
-}
-
-static void amd_iommu_flush_all_iotlbs(struct domain *d, uint64_t gaddr,
-                                       unsigned int order)
-{
-    struct pci_dev *pdev;
-
-    if ( !ats_enabled )
-        return;
-
-    for_each_pdev( d, pdev )
-        amd_iommu_flush_iotlb(pdev, gaddr, order);
-}
-
-/* Flush iommu cache after p2m changes. */
-static void _amd_iommu_flush_pages(struct domain *d,
-                                   uint64_t gaddr, unsigned int order)
-{
-    unsigned long flags;
-    struct amd_iommu *iommu;
-    struct hvm_iommu *hd = domain_hvm_iommu(d);
-    unsigned int dom_id = hd->domain_id;
-
-    /* send INVALIDATE_IOMMU_PAGES command */
-    for_each_amd_iommu ( iommu )
-    {
-        spin_lock_irqsave(&iommu->lock, flags);
-        invalidate_iommu_pages(iommu, gaddr, dom_id, order);
-        flush_command_buffer(iommu);
-        spin_unlock_irqrestore(&iommu->lock, flags);
-    }
-
-    if ( ats_enabled )
-        amd_iommu_flush_all_iotlbs(d, gaddr, order);
-}
-
-void amd_iommu_flush_all_pages(struct domain *d)
-{
-    _amd_iommu_flush_pages(d, INV_IOMMU_ALL_PAGES_ADDRESS, 0);
-}
-
-void amd_iommu_flush_pages(struct domain *d,
-                           unsigned long gfn, unsigned int order)
-{
-    _amd_iommu_flush_pages(d, (uint64_t) gfn << PAGE_SHIFT, order);
-}
-
 /* Share p2m table with iommu. */
 void amd_iommu_share_p2m(struct domain *d)
 {
diff -r 135678ae1bbc -r 6ef12cc262fb xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Fri Nov 18 11:07:40 2011 +0100
@@ -118,8 +118,7 @@ static void amd_iommu_setup_domain_devic
              iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
             iommu_dte_set_iotlb((u32 *)dte, dte_i);
 
-        invalidate_dev_table_entry(iommu, req_id);
-        flush_command_buffer(iommu);
+        amd_iommu_flush_device(iommu, req_id);
 
         AMD_IOMMU_DEBUG("Setup I/O page table: device id = 0x%04x, "
                         "root table = 0x%"PRIx64", "
@@ -310,8 +309,8 @@ void amd_iommu_disable_domain_device(str
              iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
             iommu_dte_set_iotlb((u32 *)dte, 0);
 
-        invalidate_dev_table_entry(iommu, req_id);
-        flush_command_buffer(iommu);
+        amd_iommu_flush_device(iommu, req_id);
+
         AMD_IOMMU_DEBUG("Disable: device id = 0x%04x, "
                         "domain = %d, paging mode = %d\n",
                         req_id,  domain_hvm_iommu(domain)->domain_id,
diff -r 135678ae1bbc -r 6ef12cc262fb xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Thu Nov 17 15:52:03 2011 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Fri Nov 18 11:07:40 2011 +0100
@@ -53,12 +53,6 @@ int amd_iommu_update_ivrs_mapping_acpi(v
 int amd_iommu_map_page(struct domain *d, unsigned long gfn, unsigned long mfn,
                        unsigned int flags);
 int amd_iommu_unmap_page(struct domain *d, unsigned long gfn);
-void amd_iommu_flush_pages(struct domain *d, unsigned long gfn,
-                           unsigned int order);
-void amd_iommu_flush_all_pages(struct domain *d);
-void amd_iommu_flush_iotlb(struct pci_dev *pdev, uint64_t gaddr,
-                           unsigned int order);
-
 u64 amd_iommu_get_next_table_from_pte(u32 *entry);
 int amd_iommu_reserve_domain_unity_map(struct domain *domain,
                                        u64 phys_addr, unsigned long size,
@@ -75,11 +69,15 @@ void amd_iommu_set_root_page_table(
     u32 *dte, u64 root_ptr, u16 domain_id, u8 paging_mode, u8 valid);
 void iommu_dte_set_iotlb(u32 *dte, u8 i);
 void iommu_dte_add_device_entry(u32 *dte, struct ivrs_mappings *ivrs_dev);
-void invalidate_dev_table_entry(struct amd_iommu *iommu, u16 devic_id);
 
 /* send cmd to iommu */
-int send_iommu_command(struct amd_iommu *iommu, u32 cmd[]);
-void flush_command_buffer(struct amd_iommu *iommu);
+void amd_iommu_flush_all_pages(struct domain *d);
+void amd_iommu_flush_pages(struct domain *d, unsigned long gfn,
+                           unsigned int order);
+void amd_iommu_flush_iotlb(struct pci_dev *pdev, uint64_t gaddr,
+                           unsigned int order);
+void amd_iommu_flush_device(struct amd_iommu *iommu, uint16_t bdf);
+void amd_iommu_flush_intremap(struct amd_iommu *iommu, uint16_t bdf);
 
 /* find iommu for bdf */
 struct amd_iommu *find_iommu_for_device(int seg, int bdf);
@@ -88,7 +86,6 @@ struct amd_iommu *find_iommu_for_device(
 int amd_iommu_setup_ioapic_remapping(void);
 void *amd_iommu_alloc_intremap_table(void);
 int amd_iommu_free_intremap_table(u16 seg, struct ivrs_mappings *);
-void invalidate_interrupt_table(struct amd_iommu *iommu, u16 device_id);
 void amd_iommu_ioapic_update_ire(
     unsigned int apic, unsigned int reg, unsigned int value);
 void amd_iommu_msi_msg_update_ire(


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:55:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:55:59 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM6x-0003KY-6x
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM6d-0005w7-25; Fri, 18 Nov 2011 02:55:39 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM5t-0005gH-99
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:54:53 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321613690!4765105!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27500 invoked from network); 18 Nov 2011 10:54:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9006394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:54:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 10:54:49 +0000
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
	V2 stucture
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Fri, 18 Nov 2011 10:54:49 +0000
In-Reply-To: <4EC62E77.7090007@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<4EC62E77.7090007@oracle.com>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321613689.3664.305.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for splitting these up.

On Fri, 2011-11-18 at 10:07 +0000, ANNIE LI wrote:
> [...]

> return value
> +        * by bit operations.
> +        */
> +       int (*query_foreign_access)(grant_ref_t);
> +};
> +
> +static struct gnttab_ops gnttab_v1_ops;

You don't actually need this forward declaration since the struct
definition and usage are ordered correctly.

> +static struct gnttab_ops gnttab_v1_ops = {
> +       .map_frames                     = gnttab_map_frames_v1,
> +       .unmap_frames                   = gnttab_unmap_frames_v1,
> +       .update_entry                   = update_grant_entry_v1,

Any reason this one is not gnttab_foo?

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 10:55:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 10:55:59 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRM6x-0003KY-6x
	for archives@lists.xen.org; Fri, 18 Nov 2011 10:55:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRM6d-0005w7-25; Fri, 18 Nov 2011 02:55:39 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRM5t-0005gH-99
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 02:54:53 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321613690!4765105!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27500 invoked from network); 18 Nov 2011 10:54:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 10:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9006394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:54:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 10:54:49 +0000
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
	V2 stucture
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Fri, 18 Nov 2011 10:54:49 +0000
In-Reply-To: <4EC62E77.7090007@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<4EC62E77.7090007@oracle.com>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321613689.3664.305.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for splitting these up.

On Fri, 2011-11-18 at 10:07 +0000, ANNIE LI wrote:
> [...]

> return value
> +        * by bit operations.
> +        */
> +       int (*query_foreign_access)(grant_ref_t);
> +};
> +
> +static struct gnttab_ops gnttab_v1_ops;

You don't actually need this forward declaration since the struct
definition and usage are ordered correctly.

> +static struct gnttab_ops gnttab_v1_ops = {
> +       .map_frames                     = gnttab_map_frames_v1,
> +       .unmap_frames                   = gnttab_unmap_frames_v1,
> +       .update_entry                   = update_grant_entry_v1,

Any reason this one is not gnttab_foo?

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:05:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:05:20 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMFz-0003Kl-Qd
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:05:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMFe-0006WR-LA; Fri, 18 Nov 2011 03:04:58 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMDa-0006TR-TF
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:03:03 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321614048!44869564!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26237 invoked from network); 18 Nov 2011 11:00:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:00:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9006595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:02:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 11:02:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Fri, 18 Nov 2011 11:02:45 +0000
In-Reply-To: <4EC62FE5.2080608@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321614166.3664.311.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: [Xen-devel] Re: [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 10:13 +0000, ANNIE LI wrote:
> static void gnttab_request_version(void)
>  {
> -       grant_table_version = 1;
> -       gnttab_interface = &gnttab_v1_ops;
> +       int rc;
> +       struct gnttab_set_version gsv;
> +       const char *str = "we need grant tables version 2, but only version 1 is available\n";
> +
> +       gsv.version = 2;
> +       rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
> +       if (rc == 0) {
> +               grant_table_version = 2;
> +               gnttab_interface = &gnttab_v2_ops;
> +       } else {
> +               if (grant_table_version == 2) {

	  } else if (...) {
		panic
	  } else {
		setup v1
	  }

> +                       /*
> +                        * If we've already used version 2 features,
> +                        * but then suddenly discover that they're not
> +                        * available (e.g. migrating to an older
> +                        * version of Xen), almost unbounded badness
> +                        * can happen.
> +                        */
> +                       xen_raw_printk(str);
> +                       panic(str);

I expect you've just copied this style from elsewhere but I really
dislike this duplication of prints. If panic is not useful here we
really ought to address that at the root instead of going around
patching things to print every panic message twice. I thought
earlyprintk was supposed to solve this problem. Perhaps a generic
early_panic_print could be added to the panic code?

If we stick with this (which is fair enough since it is outside the
scope of this series) you should move the const char *str into this code
block so it is near to the use.

> +               }
> +               grant_table_version = 1;
> +               gnttab_interface = &gnttab_v1_ops;
> +       }
>         printk(KERN_INFO "Grant tables using version %d layout.\n",
>                 grant_table_version);
>  } 


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:05:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:05:20 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMFz-0003Kl-Qd
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:05:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMFe-0006WR-LA; Fri, 18 Nov 2011 03:04:58 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMDa-0006TR-TF
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:03:03 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321614048!44869564!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26237 invoked from network); 18 Nov 2011 11:00:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:00:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9006595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:02:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 11:02:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Fri, 18 Nov 2011 11:02:45 +0000
In-Reply-To: <4EC62FE5.2080608@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321614166.3664.311.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: [Xen-devel] Re: [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 10:13 +0000, ANNIE LI wrote:
> static void gnttab_request_version(void)
>  {
> -       grant_table_version = 1;
> -       gnttab_interface = &gnttab_v1_ops;
> +       int rc;
> +       struct gnttab_set_version gsv;
> +       const char *str = "we need grant tables version 2, but only version 1 is available\n";
> +
> +       gsv.version = 2;
> +       rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
> +       if (rc == 0) {
> +               grant_table_version = 2;
> +               gnttab_interface = &gnttab_v2_ops;
> +       } else {
> +               if (grant_table_version == 2) {

	  } else if (...) {
		panic
	  } else {
		setup v1
	  }

> +                       /*
> +                        * If we've already used version 2 features,
> +                        * but then suddenly discover that they're not
> +                        * available (e.g. migrating to an older
> +                        * version of Xen), almost unbounded badness
> +                        * can happen.
> +                        */
> +                       xen_raw_printk(str);
> +                       panic(str);

I expect you've just copied this style from elsewhere but I really
dislike this duplication of prints. If panic is not useful here we
really ought to address that at the root instead of going around
patching things to print every panic message twice. I thought
earlyprintk was supposed to solve this problem. Perhaps a generic
early_panic_print could be added to the panic code?

If we stick with this (which is fair enough since it is outside the
scope of this series) you should move the const char *str into this code
block so it is near to the use.

> +               }
> +               grant_table_version = 1;
> +               gnttab_interface = &gnttab_v1_ops;
> +       }
>         printk(KERN_INFO "Grant tables using version %d layout.\n",
>                 grant_table_version);
>  } 


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:11:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:11:53 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMMK-0003L7-VU
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:11:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMLy-0006z7-Ol; Fri, 18 Nov 2011 03:11:30 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMLm-0006y7-4p
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:11:18 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1321614674!2086728!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5197 invoked from network); 18 Nov 2011 11:11:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:11:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9006811"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:11:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 18 Nov 2011
	11:11:11 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 18 Nov 2011 11:11:10 +0000
Subject: RE: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Topic: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Index: Acyl3pqYjddMj3rUSzS16TqxbCsgEAAA88ew
Message-ID: <291EDFCB1E9E224A99088639C4762022B4543AB75A@LONPMAILBOX01.citrite.net>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
	<66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
	<1321612878.3664.299.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321612878.3664.299.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0298242697=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0298242697==
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJYW4gQ2FtcGJlbGwNCj4gU2Vu
dDogMTggTm92ZW1iZXIgMjAxMSAxMDo0MQ0KPiBUbzogUGF1bCBEdXJyYW50DQo+IENjOiB4ZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQ0KPiBTdWJqZWN0OiBSZTogW1hlbi1kZXZlbF0gW1BB
VENIIDIgb2YgMl0gQWRkIGNvbmZpZ3VyYXRpb24gb3B0aW9ucyB0bw0KPiBzZWxlY3RpdmVseSBk
aXNhYmxlIFMzIGFuZCBTNCBBQ1BJIHBvd2VyIHN0YXRlcw0KPiANCj4gT24gRnJpLCAyMDExLTEx
LTE4IGF0IDEwOjI5ICswMDAwLCBQYXVsIER1cnJhbnQgd3JvdGU6DQo+ID4gZGlmZiAtciBkMjJl
ZjBmNjA0OTcgLXIgNjZiZGNiOTA1NjBmDQo+IHRvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9odm1s
b2FkZXIuYw0KPiA+IC0tLSBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9odm1sb2FkZXIuYyAg
ICAgIEZyaSBOb3YgMTgNCj4gMTA6Mjg6NTIgMjAxMSArMDAwMA0KPiA+ICsrKyBiL3Rvb2xzL2Zp
cm13YXJlL2h2bWxvYWRlci9odm1sb2FkZXIuYyAgICAgIEZyaSBOb3YgMTgNCj4gMTA6Mjg6NTMg
MjAxMSArMDAwMA0KPiA+IEBAIC01MTYsMTEgKzUxNiwxNyBAQCBpbnQgbWFpbih2b2lkKQ0KPiA+
ICAgICAgICAgICAgICAuaW5kZXggPSBIVk1fUEFSQU1fQUNQSV9JT1BPUlRTX0xPQ0FUSU9OLA0K
PiA+ICAgICAgICAgICAgICAudmFsdWUgPSAxLA0KPiA+ICAgICAgICAgIH07DQo+ID4gKyAgICAg
ICAgaW50IHMzX2VuYWJsZWQsIHM0X2VuYWJsZWQ7DQo+ID4gKw0KPiA+ICsgICAgICAgIHMzX2Vu
YWJsZWQgPSAhc3RybmNtcCh4ZW5zdG9yZV9yZWFkKCJwbGF0Zm9ybS9hY3BpX3MzIiwNCj4gIjEi
KSwgIjEiLCAxKTsNCj4gPiArICAgICAgICBzNF9lbmFibGVkID0gIXN0cm5jbXAoeGVuc3RvcmVf
cmVhZCgicGxhdGZvcm0vYWNwaV9zNCIsDQo+ICIxIiksDQo+ID4gKyAiMSIsIDEpOw0KPiANCj4g
SXMgaXQgbm90IHBvc3NpYmxlIHRvIGRvIHRoZXNlIGluIHRoZSB1bmRlcmx5aW5nIGFjcGlfYnVp
bGRfdGFibGVzDQo+IGFuZCBhdm9pZCB0aGUgbmVlZCB0byBwbHVtYiB0aGVtIHJpZ2h0IHRoZSB3
YXkgdGhyb3VnaD8NCj4gDQoNCkkgZ3Vlc3MgdGhhdCB3b3VsZCBiZSBwb3NzaWJsZS4gSXQganVz
dCBzZWVtZWQgbG9naWNhbCB0byBncm91cCB0aGUgYWNwaSBjb25maWcgeGVuc3RvcmUgcmVhZHMg
Y2xvc2UgdG9nZXRoZXIuIElmIHdlJ3JlIGhhcHB5IHRvIGRpc3RyaWJ1dGUgdXNlIG9mIHRoZSB4
ZW5zdG9yZSBjbGllbnQgY29kZSB0byBhbGwgY29ybmVycyBvZiB0aGUgc291cmNlIHRoZW4gSSBj
YW4gY2VydGFpbmx5IGRvIHRoYXQuDQoNCj4gPiAgICAgICAgICBpZiAoIGJpb3MtPmFjcGlfYnVp
bGRfdGFibGVzICkNCj4gPiAgICAgICAgICB7DQo+ID4gLSAgICAgICAgICAgIHByaW50ZigiTG9h
ZGluZyBBQ1BJIC4uLlxuIik7DQo+ID4gLSAgICAgICAgICAgIGJpb3MtPmFjcGlfYnVpbGRfdGFi
bGVzKCk7DQo+ID4gKyAgICAgICAgICAgIHByaW50ZigiTG9hZGluZyBBQ1BJIChTMz0lcyBTND0l
cykgLi4uXG4iLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgKHMzX2VuYWJsZWQpID8gIk9OIiA6
ICJPRkYiLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgKHM0X2VuYWJsZWQpID8gIk9OIiA6ICJP
RkYiKTsNCj4gDQo+IElmIHBvc3NpYmxlIHRoaXMgcHJpbnRmIGNvdWxkIGFsc28gYmUgcHVzaGVk
IGRvd24gc28geW91IGNhbg0KPiBjb250aW51ZSB0byBwcmludCB0aGUgY29uZmlnIGluZm8uDQo+
IA0KDQpXZWxsLCBpZiB0aGUgeGVuc3RvcmUgcmVhZHMgYXJlIHB1c2hlZCBkb3duIHRoZW4gSSdk
IGNsZWFybHkgbmVlZCB0byBkbyB0aGF0IHRvbyA6LSkNCg0KPiA+ICsgICAgICAgICAgICBiaW9z
LT5hY3BpX2J1aWxkX3RhYmxlcyhzM19lbmFibGVkLCBzNF9lbmFibGVkKTsNCj4gPiAgICAgICAg
ICB9DQo+ID4NCj4gPiAgICAgICAgICBhY3BpX2VuYWJsZV9zY2koKTsNCj4gDQo+IElhbi4NCj4g
DQoNCiAgUGF1bA0K


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

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

--===============0298242697==--

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:11:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:11:53 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMMK-0003L7-VU
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:11:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMLy-0006z7-Ol; Fri, 18 Nov 2011 03:11:30 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMLm-0006y7-4p
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:11:18 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1321614674!2086728!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5197 invoked from network); 18 Nov 2011 11:11:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:11:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9006811"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:11:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 18 Nov 2011
	11:11:11 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 18 Nov 2011 11:11:10 +0000
Subject: RE: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Topic: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Index: Acyl3pqYjddMj3rUSzS16TqxbCsgEAAA88ew
Message-ID: <291EDFCB1E9E224A99088639C4762022B4543AB75A@LONPMAILBOX01.citrite.net>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
	<66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
	<1321612878.3664.299.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321612878.3664.299.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0298242697=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0298242697==
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJYW4gQ2FtcGJlbGwNCj4gU2Vu
dDogMTggTm92ZW1iZXIgMjAxMSAxMDo0MQ0KPiBUbzogUGF1bCBEdXJyYW50DQo+IENjOiB4ZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQ0KPiBTdWJqZWN0OiBSZTogW1hlbi1kZXZlbF0gW1BB
VENIIDIgb2YgMl0gQWRkIGNvbmZpZ3VyYXRpb24gb3B0aW9ucyB0bw0KPiBzZWxlY3RpdmVseSBk
aXNhYmxlIFMzIGFuZCBTNCBBQ1BJIHBvd2VyIHN0YXRlcw0KPiANCj4gT24gRnJpLCAyMDExLTEx
LTE4IGF0IDEwOjI5ICswMDAwLCBQYXVsIER1cnJhbnQgd3JvdGU6DQo+ID4gZGlmZiAtciBkMjJl
ZjBmNjA0OTcgLXIgNjZiZGNiOTA1NjBmDQo+IHRvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9odm1s
b2FkZXIuYw0KPiA+IC0tLSBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9odm1sb2FkZXIuYyAg
ICAgIEZyaSBOb3YgMTgNCj4gMTA6Mjg6NTIgMjAxMSArMDAwMA0KPiA+ICsrKyBiL3Rvb2xzL2Zp
cm13YXJlL2h2bWxvYWRlci9odm1sb2FkZXIuYyAgICAgIEZyaSBOb3YgMTgNCj4gMTA6Mjg6NTMg
MjAxMSArMDAwMA0KPiA+IEBAIC01MTYsMTEgKzUxNiwxNyBAQCBpbnQgbWFpbih2b2lkKQ0KPiA+
ICAgICAgICAgICAgICAuaW5kZXggPSBIVk1fUEFSQU1fQUNQSV9JT1BPUlRTX0xPQ0FUSU9OLA0K
PiA+ICAgICAgICAgICAgICAudmFsdWUgPSAxLA0KPiA+ICAgICAgICAgIH07DQo+ID4gKyAgICAg
ICAgaW50IHMzX2VuYWJsZWQsIHM0X2VuYWJsZWQ7DQo+ID4gKw0KPiA+ICsgICAgICAgIHMzX2Vu
YWJsZWQgPSAhc3RybmNtcCh4ZW5zdG9yZV9yZWFkKCJwbGF0Zm9ybS9hY3BpX3MzIiwNCj4gIjEi
KSwgIjEiLCAxKTsNCj4gPiArICAgICAgICBzNF9lbmFibGVkID0gIXN0cm5jbXAoeGVuc3RvcmVf
cmVhZCgicGxhdGZvcm0vYWNwaV9zNCIsDQo+ICIxIiksDQo+ID4gKyAiMSIsIDEpOw0KPiANCj4g
SXMgaXQgbm90IHBvc3NpYmxlIHRvIGRvIHRoZXNlIGluIHRoZSB1bmRlcmx5aW5nIGFjcGlfYnVp
bGRfdGFibGVzDQo+IGFuZCBhdm9pZCB0aGUgbmVlZCB0byBwbHVtYiB0aGVtIHJpZ2h0IHRoZSB3
YXkgdGhyb3VnaD8NCj4gDQoNCkkgZ3Vlc3MgdGhhdCB3b3VsZCBiZSBwb3NzaWJsZS4gSXQganVz
dCBzZWVtZWQgbG9naWNhbCB0byBncm91cCB0aGUgYWNwaSBjb25maWcgeGVuc3RvcmUgcmVhZHMg
Y2xvc2UgdG9nZXRoZXIuIElmIHdlJ3JlIGhhcHB5IHRvIGRpc3RyaWJ1dGUgdXNlIG9mIHRoZSB4
ZW5zdG9yZSBjbGllbnQgY29kZSB0byBhbGwgY29ybmVycyBvZiB0aGUgc291cmNlIHRoZW4gSSBj
YW4gY2VydGFpbmx5IGRvIHRoYXQuDQoNCj4gPiAgICAgICAgICBpZiAoIGJpb3MtPmFjcGlfYnVp
bGRfdGFibGVzICkNCj4gPiAgICAgICAgICB7DQo+ID4gLSAgICAgICAgICAgIHByaW50ZigiTG9h
ZGluZyBBQ1BJIC4uLlxuIik7DQo+ID4gLSAgICAgICAgICAgIGJpb3MtPmFjcGlfYnVpbGRfdGFi
bGVzKCk7DQo+ID4gKyAgICAgICAgICAgIHByaW50ZigiTG9hZGluZyBBQ1BJIChTMz0lcyBTND0l
cykgLi4uXG4iLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgKHMzX2VuYWJsZWQpID8gIk9OIiA6
ICJPRkYiLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgKHM0X2VuYWJsZWQpID8gIk9OIiA6ICJP
RkYiKTsNCj4gDQo+IElmIHBvc3NpYmxlIHRoaXMgcHJpbnRmIGNvdWxkIGFsc28gYmUgcHVzaGVk
IGRvd24gc28geW91IGNhbg0KPiBjb250aW51ZSB0byBwcmludCB0aGUgY29uZmlnIGluZm8uDQo+
IA0KDQpXZWxsLCBpZiB0aGUgeGVuc3RvcmUgcmVhZHMgYXJlIHB1c2hlZCBkb3duIHRoZW4gSSdk
IGNsZWFybHkgbmVlZCB0byBkbyB0aGF0IHRvbyA6LSkNCg0KPiA+ICsgICAgICAgICAgICBiaW9z
LT5hY3BpX2J1aWxkX3RhYmxlcyhzM19lbmFibGVkLCBzNF9lbmFibGVkKTsNCj4gPiAgICAgICAg
ICB9DQo+ID4NCj4gPiAgICAgICAgICBhY3BpX2VuYWJsZV9zY2koKTsNCj4gDQo+IElhbi4NCj4g
DQoNCiAgUGF1bA0K


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

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

--===============0298242697==--

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:12:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:12:59 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMNP-0003LK-2S
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:12:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMN5-0007MI-Go; Fri, 18 Nov 2011 03:12:39 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMN0-0007Ka-N9
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:12:35 -0800
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321614751!3676108!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16418 invoked from network); 18 Nov 2011 11:12:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:12:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9006854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:12:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 11:12:31 +0000
Date: Fri, 18 Nov 2011 11:13:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Cc: Jan Beulich <JBeulich@novell.com>
Subject: [Xen-devel] [PATCH v2] x86: re-inject emulated level pirqs in PV on
 HVM guests if still asserted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch is a backport of CS 24007 for xen-4.1-testing.

PV on HVM guests can loose level interrupts coming from emulated
devices if they have been remapped onto event channels.  The reason is
that we are missing the code to inject a pirq again in the guest when
the guest EOIs it, if it corresponds to an emulated level interrupt
and the interrupt is still asserted.

Fix this issue and also return error when the guest tries to get the
irq_status of a non-existing pirq.


Changes in v2:

- move the spinlock afterward to cover the new code only.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Jan Beulich <JBeulich@suse.com>


diff -r e73ada19a69d xen/arch/x86/physdev.c
--- a/xen/arch/x86/physdev.c	Thu Nov 17 09:13:25 2011 +0000
+++ b/xen/arch/x86/physdev.c	Fri Nov 18 09:42:03 2011 +0000
@@ -268,6 +268,20 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             ret = pirq_guest_eoi(v->domain, eoi.irq);
         else
             ret = 0;
+        spin_lock(&v->domain->event_lock);
+        if ( is_hvm_domain(v->domain) &&
+                domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 )
+        {
+            struct hvm_irq *hvm_irq = &v->domain->arch.hvm_domain.irq;
+            int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq);
+
+            /* if this is a level irq and count > 0, send another
+             * notification */ 
+            if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */
+                    && hvm_irq->gsi_assert_count[gsi] )
+                send_guest_pirq(v->domain, eoi.irq);
+        }
+        spin_unlock(&v->domain->event_lock);
         break;
     }
 
@@ -323,9 +337,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             break;
         irq_status_query.flags = 0;
         if ( is_hvm_domain(v->domain) &&
-             domain_pirq_to_irq(v->domain, irq) <= 0 )
+                domain_pirq_to_irq(v->domain, irq) <= 0 &&
+                domain_pirq_to_emuirq(v->domain, irq) == IRQ_UNBOUND )
         {
-            ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0;
+            ret = -EINVAL;
             break;
         }
 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:12:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:12:59 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMNP-0003LK-2S
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:12:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMN5-0007MI-Go; Fri, 18 Nov 2011 03:12:39 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMN0-0007Ka-N9
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:12:35 -0800
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321614751!3676108!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16418 invoked from network); 18 Nov 2011 11:12:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:12:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9006854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:12:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 11:12:31 +0000
Date: Fri, 18 Nov 2011 11:13:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Cc: Jan Beulich <JBeulich@novell.com>
Subject: [Xen-devel] [PATCH v2] x86: re-inject emulated level pirqs in PV on
 HVM guests if still asserted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch is a backport of CS 24007 for xen-4.1-testing.

PV on HVM guests can loose level interrupts coming from emulated
devices if they have been remapped onto event channels.  The reason is
that we are missing the code to inject a pirq again in the guest when
the guest EOIs it, if it corresponds to an emulated level interrupt
and the interrupt is still asserted.

Fix this issue and also return error when the guest tries to get the
irq_status of a non-existing pirq.


Changes in v2:

- move the spinlock afterward to cover the new code only.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Jan Beulich <JBeulich@suse.com>


diff -r e73ada19a69d xen/arch/x86/physdev.c
--- a/xen/arch/x86/physdev.c	Thu Nov 17 09:13:25 2011 +0000
+++ b/xen/arch/x86/physdev.c	Fri Nov 18 09:42:03 2011 +0000
@@ -268,6 +268,20 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             ret = pirq_guest_eoi(v->domain, eoi.irq);
         else
             ret = 0;
+        spin_lock(&v->domain->event_lock);
+        if ( is_hvm_domain(v->domain) &&
+                domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 )
+        {
+            struct hvm_irq *hvm_irq = &v->domain->arch.hvm_domain.irq;
+            int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq);
+
+            /* if this is a level irq and count > 0, send another
+             * notification */ 
+            if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */
+                    && hvm_irq->gsi_assert_count[gsi] )
+                send_guest_pirq(v->domain, eoi.irq);
+        }
+        spin_unlock(&v->domain->event_lock);
         break;
     }
 
@@ -323,9 +337,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             break;
         irq_status_query.flags = 0;
         if ( is_hvm_domain(v->domain) &&
-             domain_pirq_to_irq(v->domain, irq) <= 0 )
+                domain_pirq_to_irq(v->domain, irq) <= 0 &&
+                domain_pirq_to_emuirq(v->domain, irq) == IRQ_UNBOUND )
         {
-            ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0;
+            ret = -EINVAL;
             break;
         }
 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:21:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:21:53 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMW1-0003LX-Av
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMVg-0007sE-Km; Fri, 18 Nov 2011 03:21:32 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMVU-0007qz-3o
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:21:20 -0800
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1321615276!2077555!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4937 invoked from network); 18 Nov 2011 11:21:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:21:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:21:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 11:21:07 +0000
Date: Fri, 18 Nov 2011 11:21:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jiageng Yu <yujiageng734@gmail.com>
Subject: Re: [Xen-devel] Re: Linux Stubdom Problem
In-Reply-To: <CAJ0pt17qsAjO4YzbNNvNxWsbG0B2ZRrOs1QwS7ueNxpxhpD9Fw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111181055010.3519@kaball-desktop>
References: <alpine.DEB.2.00.1109021401000.12963@kaball-desktop>
	<CA8694A1.20379%keir.xen@gmail.com>
	<CAJ0pt17eoZbEnmziLaSd1Cxi+sU90rJ-c8TSgt+ikE3wZj1jhA@mail.gmail.com>
	<alpine.DEB.2.00.1109151110020.12963@kaball-desktop>
	<CAJ0pt15daSuXGi_8T3NS53E2Xv0bYV90b94100Wi6ajt99gedQ@mail.gmail.com>
	<alpine.DEB.2.00.1111081412270.3519@kaball-desktop>
	<CAJ0pt154u9GY-6x6ZJA2UDyfgE135hZkr27XHnJ2ooaaNtTEmw@mail.gmail.com>
	<alpine.DEB.2.00.1111091340110.3519@kaball-desktop>
	<CAJ0pt15HEYGkXXR00tkyc6FXwt7eGKi-0yGo67y=UeWEuNrbTg@mail.gmail.com>
	<alpine.DEB.2.00.1111091656060.3519@kaball-desktop>
	<CAJ0pt17qsAjO4YzbNNvNxWsbG0B2ZRrOs1QwS7ueNxpxhpD9Fw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-922795263-1321614777=:3519"
Content-ID: <alpine.DEB.2.00.1111181118420.3519@kaball-desktop>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Konrad, Samuel,
	Anthony PERARD <anthony.perard@gmail.com>,
	Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-922795263-1321614777=:3519
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1111181118421.3519@kaball-desktop>

On Thu, 17 Nov 2011, Jiageng Yu wrote:
> 2011/11/10 Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >
> > On Wed, 9 Nov 2011, Jiageng Yu wrote:
> > > The keyboard driver is OK now. I am working on network device. In
> > > linux stubdom, I have udev, ifconfig and brctl tools. After udevd
> > > started, stubdom executes "ifconfig eth0 IPadderss netmask netgate up"
> > > to setup the network. When qemu in stubdom creates a tapxx interface
> > > for hvm guest, � the script should be executed to build a net bridge.
> > >
> > > �  �  �  /sbin/brctl addbr eth0
> > > �  �  �  /sbin/brctl addif eth0 tapXX
> > >
> > > Therefore, the hvm guest has the network device. Is this plan
> > > reasonable? Or have better one?
> >
> > The bridge should be called xenbr0, the stubdom's network interface
> > (that should probably called eth0) should be added to the bridge at boot
> > time.
> >
> > Like you said, when qemu starts is going to create a tap interface, on
> > Linux usually we rely on a udev script to add the tap interface to the
> > bridge. The script is tools/hotplug/Linux/vif-setup, that calls
> > tools/hotplug/Linux/vif-bridge.
> >
> > So at the end you have:
> >
> > xenbr0 (bridge)
> > ||
> > |+-------------------------------+
> > | �  �  �  �  �  �  �  �  �  �  �  �  �  �  �  � |
> > eth0 �  �  �  �  �  �  �  �  �  �  �  �  �  �  |
> > (stubdom network interface) �  �  � tapXX
> > �  �  �  �  �  �  �  �  �  �  �  �  �  �  �  �  (qemu's tap interface)
> 
> 
> Hi Stefano,
> 
> �  � � I have a prototype of network of linux based stubdom, as shown in
> attached figure. I list my design� points, please comment on them.
> 
>     1. Qemu-ifup script in Linux stubdom.
> 
>      Qemu in stubdom invokes qemu-ifup script to setup the
> bridge(net/tap.c). Because the linux stubdom only has nash and can not
> execute the qemu-ifup script, I implement a c version of qemu-ifup
> script. Using the following way, the qemu will invoke qemu-ifup
> program in stubdom.
> 
> diff -r 0f36c2eec2e1 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Thu Jul 28 15:40:54 2011 +0100
> +++ b/tools/libxl/libxl_dm.c	Thu Nov 17 22:41:29 2011 +0000
> @@ -29,9 +29,12 @@
>  #include "libxl.h"
>  #include "flexarray.h"
> 
> -static const char *libxl_tapif_script(libxl__gc *gc)
> +static const char *libxl_tapif_script(libxl__gc *gc,
> +                                      libxl_device_model_info *info)
>  {
>  #ifdef __linux__
> +    if(info->device_model_linux_stubdomain)
> +        return libxl__sprintf(gc, "/bin/qemu-ifup");
>      return libxl__strdup(gc, "no");
>  #else
>      return libxl__sprintf(gc, "%s/qemu-ifup", libxl_xen_script_dir_path());
> 
>      I do not use libxl_xen_script_dir_path() to determine the path of
> qemu-ifup, because we don't want include xen-unstable.hg/Config.mk in
> linux stubdom. Therefore, I hardcoded this path.

That is OK.


>     2. Network tools.
> 
>     Our linux based stubdom do not have the real shell and IP stack,
> so we must custom the network tools. I notice the bridge-utils-1.5
> version creates AF_LOCAL socket, so brctl can be used without
> modification. But ifconfig would not be so luck. I need to rewrite
> ifconfig and make it only support bring up the interfaces.

I think you need to call a couple of ioctl in order to enable a
network interface.


>     3. The mac address.
> 
>     If we declare the mac address in stubdom-cfg file, the eth0 in
> stubdom and eth0 in hvm guest will be set to the same mac address.
> 
>    do_domain_create (or libxl__create_stubdom)
>          -->libxl_device_nic_add
> 
>    As a temporary solution, I hardcoded a static mac address for linux
> stdubom in libxl__create_stubdom().

The mac address of eth0 (and xenbr0) in the stubdom is not
important considering that is never going to be used: all the traffic
should go through the tap interface anyway.
It could even be fe:ff:ff:ff:ff:ff.
--8323329-922795263-1321614777=:3519
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--8323329-922795263-1321614777=:3519--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:21:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:21:53 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMW1-0003LX-Av
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMVg-0007sE-Km; Fri, 18 Nov 2011 03:21:32 -0800
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMVU-0007qz-3o
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:21:20 -0800
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1321615276!2077555!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4937 invoked from network); 18 Nov 2011 11:21:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:21:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:21:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 11:21:07 +0000
Date: Fri, 18 Nov 2011 11:21:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jiageng Yu <yujiageng734@gmail.com>
Subject: Re: [Xen-devel] Re: Linux Stubdom Problem
In-Reply-To: <CAJ0pt17qsAjO4YzbNNvNxWsbG0B2ZRrOs1QwS7ueNxpxhpD9Fw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111181055010.3519@kaball-desktop>
References: <alpine.DEB.2.00.1109021401000.12963@kaball-desktop>
	<CA8694A1.20379%keir.xen@gmail.com>
	<CAJ0pt17eoZbEnmziLaSd1Cxi+sU90rJ-c8TSgt+ikE3wZj1jhA@mail.gmail.com>
	<alpine.DEB.2.00.1109151110020.12963@kaball-desktop>
	<CAJ0pt15daSuXGi_8T3NS53E2Xv0bYV90b94100Wi6ajt99gedQ@mail.gmail.com>
	<alpine.DEB.2.00.1111081412270.3519@kaball-desktop>
	<CAJ0pt154u9GY-6x6ZJA2UDyfgE135hZkr27XHnJ2ooaaNtTEmw@mail.gmail.com>
	<alpine.DEB.2.00.1111091340110.3519@kaball-desktop>
	<CAJ0pt15HEYGkXXR00tkyc6FXwt7eGKi-0yGo67y=UeWEuNrbTg@mail.gmail.com>
	<alpine.DEB.2.00.1111091656060.3519@kaball-desktop>
	<CAJ0pt17qsAjO4YzbNNvNxWsbG0B2ZRrOs1QwS7ueNxpxhpD9Fw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-922795263-1321614777=:3519"
Content-ID: <alpine.DEB.2.00.1111181118420.3519@kaball-desktop>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Konrad, Samuel,
	Anthony PERARD <anthony.perard@gmail.com>,
	Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-922795263-1321614777=:3519
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1111181118421.3519@kaball-desktop>

On Thu, 17 Nov 2011, Jiageng Yu wrote:
> 2011/11/10 Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >
> > On Wed, 9 Nov 2011, Jiageng Yu wrote:
> > > The keyboard driver is OK now. I am working on network device. In
> > > linux stubdom, I have udev, ifconfig and brctl tools. After udevd
> > > started, stubdom executes "ifconfig eth0 IPadderss netmask netgate up"
> > > to setup the network. When qemu in stubdom creates a tapxx interface
> > > for hvm guest, � the script should be executed to build a net bridge.
> > >
> > > �  �  �  /sbin/brctl addbr eth0
> > > �  �  �  /sbin/brctl addif eth0 tapXX
> > >
> > > Therefore, the hvm guest has the network device. Is this plan
> > > reasonable? Or have better one?
> >
> > The bridge should be called xenbr0, the stubdom's network interface
> > (that should probably called eth0) should be added to the bridge at boot
> > time.
> >
> > Like you said, when qemu starts is going to create a tap interface, on
> > Linux usually we rely on a udev script to add the tap interface to the
> > bridge. The script is tools/hotplug/Linux/vif-setup, that calls
> > tools/hotplug/Linux/vif-bridge.
> >
> > So at the end you have:
> >
> > xenbr0 (bridge)
> > ||
> > |+-------------------------------+
> > | �  �  �  �  �  �  �  �  �  �  �  �  �  �  �  � |
> > eth0 �  �  �  �  �  �  �  �  �  �  �  �  �  �  |
> > (stubdom network interface) �  �  � tapXX
> > �  �  �  �  �  �  �  �  �  �  �  �  �  �  �  �  (qemu's tap interface)
> 
> 
> Hi Stefano,
> 
> �  � � I have a prototype of network of linux based stubdom, as shown in
> attached figure. I list my design� points, please comment on them.
> 
>     1. Qemu-ifup script in Linux stubdom.
> 
>      Qemu in stubdom invokes qemu-ifup script to setup the
> bridge(net/tap.c). Because the linux stubdom only has nash and can not
> execute the qemu-ifup script, I implement a c version of qemu-ifup
> script. Using the following way, the qemu will invoke qemu-ifup
> program in stubdom.
> 
> diff -r 0f36c2eec2e1 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Thu Jul 28 15:40:54 2011 +0100
> +++ b/tools/libxl/libxl_dm.c	Thu Nov 17 22:41:29 2011 +0000
> @@ -29,9 +29,12 @@
>  #include "libxl.h"
>  #include "flexarray.h"
> 
> -static const char *libxl_tapif_script(libxl__gc *gc)
> +static const char *libxl_tapif_script(libxl__gc *gc,
> +                                      libxl_device_model_info *info)
>  {
>  #ifdef __linux__
> +    if(info->device_model_linux_stubdomain)
> +        return libxl__sprintf(gc, "/bin/qemu-ifup");
>      return libxl__strdup(gc, "no");
>  #else
>      return libxl__sprintf(gc, "%s/qemu-ifup", libxl_xen_script_dir_path());
> 
>      I do not use libxl_xen_script_dir_path() to determine the path of
> qemu-ifup, because we don't want include xen-unstable.hg/Config.mk in
> linux stubdom. Therefore, I hardcoded this path.

That is OK.


>     2. Network tools.
> 
>     Our linux based stubdom do not have the real shell and IP stack,
> so we must custom the network tools. I notice the bridge-utils-1.5
> version creates AF_LOCAL socket, so brctl can be used without
> modification. But ifconfig would not be so luck. I need to rewrite
> ifconfig and make it only support bring up the interfaces.

I think you need to call a couple of ioctl in order to enable a
network interface.


>     3. The mac address.
> 
>     If we declare the mac address in stubdom-cfg file, the eth0 in
> stubdom and eth0 in hvm guest will be set to the same mac address.
> 
>    do_domain_create (or libxl__create_stubdom)
>          -->libxl_device_nic_add
> 
>    As a temporary solution, I hardcoded a static mac address for linux
> stdubom in libxl__create_stubdom().

The mac address of eth0 (and xenbr0) in the stubdom is not
important considering that is never going to be used: all the traffic
should go through the tap interface anyway.
It could even be fe:ff:ff:ff:ff:ff.
--8323329-922795263-1321614777=:3519
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--8323329-922795263-1321614777=:3519--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:23:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:23:36 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMXg-0003Ll-9n
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:23:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMXM-0008Gw-RS; Fri, 18 Nov 2011 03:23:16 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMVp-0007u1-Co
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:21:41 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321615297!3658945!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11805 invoked from network); 18 Nov 2011 11:21:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:21:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="19220431"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 06:21:36 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 06:21:36 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321615169@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 11:19:29 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Add configuration options to selectively
 disable S3 and S4 (V4)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds the ability to selectively disable the S3 and S4 ACPI
power states for HVM guests.

Since there is a general move towards retiring the hvm_info_table structure,
the first patch moves the acpi_enabled flag out of the hvm_info_table and into
a xenstore key (platform/acpi).
The second patch then introduces the acpi_s3 and acpi_s4 configuration
parameters to the xl config file (default=1). These result in population of
new platform/acpi_s3 and platform/acpi_s4 xenstore keys. hvmloader then reads
these keys to determine whether or not to include SSDTs containing the
_S3 and _S4 packages respectively.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:23:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:23:36 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMXg-0003Ll-9n
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:23:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMXM-0008Gw-RS; Fri, 18 Nov 2011 03:23:16 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMVp-0007u1-Co
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:21:41 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321615297!3658945!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11805 invoked from network); 18 Nov 2011 11:21:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:21:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="19220431"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 06:21:36 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 06:21:36 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <patchbomb.1321615169@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 11:19:29 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] Add configuration options to selectively
 disable S3 and S4 (V4)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds the ability to selectively disable the S3 and S4 ACPI
power states for HVM guests.

Since there is a general move towards retiring the hvm_info_table structure,
the first patch moves the acpi_enabled flag out of the hvm_info_table and into
a xenstore key (platform/acpi).
The second patch then introduces the acpi_s3 and acpi_s4 configuration
parameters to the xl config file (default=1). These result in population of
new platform/acpi_s3 and platform/acpi_s4 xenstore keys. hvmloader then reads
these keys to determine whether or not to include SSDTs containing the
_S3 and _S4 packages respectively.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:24:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:24:34 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMYc-0003M8-4M
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:24:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMYJ-0000Ee-Da; Fri, 18 Nov 2011 03:24:15 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMVq-0007uE-Cg
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:21:43 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321615283!46172424!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11950 invoked from network); 18 Nov 2011 11:21:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:21:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="171124981"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 06:21:37 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 06:21:37 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 8a29891d6a98002b299d73253935c161ecf393a1
Message-ID: <8a29891d6a98002b299d.1321615170@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321615169@cosworth.uk.xensource.com>
References: <patchbomb.1321615169@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 11:19:30 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Move acpi_enabled out of hvm_info_table
	into xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321612413 0
# Node ID 8a29891d6a98002b299d73253935c161ecf393a1
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Move acpi_enabled out of hvm_info_table into xenstore

Since hvmloader has a xentore client, use a platform key in xenstore
to indicate whether ACPI is enabled or not rather than the shared
hvm_info_table structure.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r dbdc840f8f62 -r 8a29891d6a98 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:33:33 2011 +0000
@@ -423,6 +423,7 @@ int main(void)
     const struct bios_config *bios;
     int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
     uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
+    int acpi_enabled;
 
     /* Initialise hypercall stubs with RET, rendering them no-ops. */
     memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
@@ -506,7 +507,9 @@ int main(void)
                                              option_rom_phys_addr);
     }
 
-    if ( hvm_info->acpi_enabled )
+    acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
+
+    if ( acpi_enabled )
     {
         struct xen_hvm_param p = {
             .domid = DOMID_SELF,
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxc/xc_hvm_build.c	Fri Nov 18 10:33:33 2011 +0000
@@ -67,7 +67,6 @@ static void build_hvm_info(void *hvm_inf
     hvm_info->length = sizeof(struct hvm_info_table);
 
     /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->acpi_enabled = 1;
     hvm_info->apic_mode = 1;
     hvm_info->nr_vcpus = 1;
     memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:33:33 2011 +0000
@@ -188,6 +188,11 @@ int libxl__domain_build(libxl__gc *gc,
         vments[3] = "hvm";
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+
+        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents[0] = "platform/acpi";
+        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         ret = libxl__build_pv(gc, domid, info, state);
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Nov 18 10:33:33 2011 +0000
@@ -248,7 +248,6 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = info->u.hvm.acpi;
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Fri Nov 18 10:33:33 2011 +0000
@@ -996,7 +996,6 @@ static PyObject *pyxc_hvm_build(XcObject
     if ( va_map == NULL )
         return PyErr_SetFromErrno(xc_error_obj);
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = acpi;
     va_hvm->apic_mode    = apic;
     va_hvm->nr_vcpus     = vcpus;
     memcpy(va_hvm->vcpu_online, vcpu_avail, sizeof(vcpu_avail));
diff -r dbdc840f8f62 -r 8a29891d6a98 xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/public/hvm/hvm_info_table.h	Fri Nov 18 10:33:33 2011 +0000
@@ -37,9 +37,6 @@ struct hvm_info_table {
     uint32_t    length;
     uint8_t     checksum;
 
-    /* Should firmware build ACPI tables? */
-    uint8_t     acpi_enabled;
-
     /* Should firmware build APIC descriptors (APIC MADT / MP BIOS)? */
     uint8_t     apic_mode;
 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:24:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:24:34 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMYc-0003M8-4M
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:24:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMYJ-0000Ee-Da; Fri, 18 Nov 2011 03:24:15 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMVq-0007uE-Cg
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:21:43 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321615283!46172424!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11950 invoked from network); 18 Nov 2011 11:21:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:21:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="171124981"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 06:21:37 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 06:21:37 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 8a29891d6a98002b299d73253935c161ecf393a1
Message-ID: <8a29891d6a98002b299d.1321615170@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321615169@cosworth.uk.xensource.com>
References: <patchbomb.1321615169@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 11:19:30 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] Move acpi_enabled out of hvm_info_table
	into xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321612413 0
# Node ID 8a29891d6a98002b299d73253935c161ecf393a1
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Move acpi_enabled out of hvm_info_table into xenstore

Since hvmloader has a xentore client, use a platform key in xenstore
to indicate whether ACPI is enabled or not rather than the shared
hvm_info_table structure.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r dbdc840f8f62 -r 8a29891d6a98 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Fri Nov 18 10:33:33 2011 +0000
@@ -423,6 +423,7 @@ int main(void)
     const struct bios_config *bios;
     int option_rom_sz = 0, vgabios_sz = 0, etherboot_sz = 0;
     uint32_t etherboot_phys_addr = 0, option_rom_phys_addr = 0;
+    int acpi_enabled;
 
     /* Initialise hypercall stubs with RET, rendering them no-ops. */
     memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
@@ -506,7 +507,9 @@ int main(void)
                                              option_rom_phys_addr);
     }
 
-    if ( hvm_info->acpi_enabled )
+    acpi_enabled = !strncmp(xenstore_read("platform/acpi", "1"), "1", 1);
+
+    if ( acpi_enabled )
     {
         struct xen_hvm_param p = {
             .domid = DOMID_SELF,
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxc/xc_hvm_build.c	Fri Nov 18 10:33:33 2011 +0000
@@ -67,7 +67,6 @@ static void build_hvm_info(void *hvm_inf
     hvm_info->length = sizeof(struct hvm_info_table);
 
     /* Sensible defaults: these can be overridden by the caller. */
-    hvm_info->acpi_enabled = 1;
     hvm_info->apic_mode = 1;
     hvm_info->nr_vcpus = 1;
     memset(hvm_info->vcpu_online, 0xff, sizeof(hvm_info->vcpu_online));
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 10:33:33 2011 +0000
@@ -188,6 +188,11 @@ int libxl__domain_build(libxl__gc *gc,
         vments[3] = "hvm";
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
+
+        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents[0] = "platform/acpi";
+        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         ret = libxl__build_pv(gc, domid, info, state);
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Nov 18 10:33:33 2011 +0000
@@ -248,7 +248,6 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = info->u.hvm.acpi;
     va_hvm->apic_mode = info->u.hvm.apic;
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
diff -r dbdc840f8f62 -r 8a29891d6a98 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/python/xen/lowlevel/xc/xc.c	Fri Nov 18 10:33:33 2011 +0000
@@ -996,7 +996,6 @@ static PyObject *pyxc_hvm_build(XcObject
     if ( va_map == NULL )
         return PyErr_SetFromErrno(xc_error_obj);
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->acpi_enabled = acpi;
     va_hvm->apic_mode    = apic;
     va_hvm->nr_vcpus     = vcpus;
     memcpy(va_hvm->vcpu_online, vcpu_avail, sizeof(vcpu_avail));
diff -r dbdc840f8f62 -r 8a29891d6a98 xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/include/public/hvm/hvm_info_table.h	Fri Nov 18 10:33:33 2011 +0000
@@ -37,9 +37,6 @@ struct hvm_info_table {
     uint32_t    length;
     uint8_t     checksum;
 
-    /* Should firmware build ACPI tables? */
-    uint8_t     acpi_enabled;
-
     /* Should firmware build APIC descriptors (APIC MADT / MP BIOS)? */
     uint8_t     apic_mode;
 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:26:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:26:26 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMaQ-0003MT-I7
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:26:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMa7-0000je-Fm; Fri, 18 Nov 2011 03:26:07 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMVq-0007uC-1y
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:21:44 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321615297!3658945!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11860 invoked from network); 18 Nov 2011 11:21:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:21:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="19220432"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 06:21:38 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 06:21:38 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 5118aa3562ea7d9a3d8fb742d378f9347ae62836
Message-ID: <5118aa3562ea7d9a3d8f.1321615171@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321615169@cosworth.uk.xensource.com>
References: <patchbomb.1321615169@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 11:19:31 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] Add configuration options to selectively
 disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321615161 0
# Node ID 5118aa3562ea7d9a3d8fb742d378f9347ae62836
# Parent  8a29891d6a98002b299d73253935c161ecf393a1
Add configuration options to selectively disable S3 and S4 ACPI power states.

Introduce acpi_s3 and acpi_s4 configuration options (default=1). The S3 and S4
packages are moved into separate SSDTs and their inclusion is controlled by the
new configuration options.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 8a29891d6a98 -r 5118aa3562ea tools/firmware/hvmloader/acpi/Makefile
--- a/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 11:19:21 2011 +0000
@@ -26,7 +26,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 vpath iasl $(PATH)
 all: acpi.a
 
-ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
+ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 	iasl -vs -p $* -tc $<
 	sed -e 's/AmlCode/$*/g' $*.hex >$@
 	rm -f $*.hex $*.aml
@@ -57,7 +57,7 @@ iasl:
 	@echo 
 	@exit 1
 
-build.o: ssdt_pm.h ssdt_tpm.h
+build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
 
 acpi.a: $(OBJS)
 	$(AR) rc $@ $(OBJS)
diff -r 8a29891d6a98 -r 5118aa3562ea tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 11:19:21 2011 +0000
@@ -17,6 +17,8 @@
  */
 
 #include "acpi2_0.h"
+#include "ssdt_s3.h"
+#include "ssdt_s4.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
 #include "../config.h"
@@ -235,6 +237,26 @@ static int construct_secondary_tables(un
         table_ptrs[nr_tables++] = (unsigned long)ssdt;
     }
 
+    if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1) )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s3), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    } else {
+        printf("S3 disabled\n");
+    }
+
+    if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s4), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    } else {
+        printf("S4 disabled\n");
+    }
+
     /* TPM TCPA and SSDT. */
     tis_hdr = (uint16_t *)0xFED40F00;
     if ( (tis_hdr[0] == tis_signature[0]) &&
diff -r 8a29891d6a98 -r 5118aa3562ea tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 11:19:21 2011 +0000
@@ -27,24 +27,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
     Name (\APCL, 0x00010000)
     Name (\PUID, 0x00)
 
-    /*
-     * S3 (suspend-to-ram), S4 (suspend-to-disc) and S5 (power-off) type codes:
-     * must match piix4 emulation.
-     */
-    Name (\_S3, Package (0x04)
-    {
-        0x01,  /* PM1a_CNT.SLP_TYP */
-        0x01,  /* PM1b_CNT.SLP_TYP */
-        0x0,   /* reserved */
-        0x0    /* reserved */
-    })
-    Name (\_S4, Package (0x04)
-    {
-        0x00,  /* PM1a_CNT.SLP_TYP */
-        0x00,  /* PM1b_CNT.SLP_TYP */
-        0x00,  /* reserved */
-        0x00   /* reserved */
-    })
+    /* _S3 and _S4 are in separate SSDTs */
     Name (\_S5, Package (0x04)
     {
         0x00,  /* PM1a_CNT.SLP_TYP */
diff -r 8a29891d6a98 -r 5118aa3562ea tools/firmware/hvmloader/acpi/ssdt_s3.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s3.asl	Fri Nov 18 11:19:21 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s3.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S3.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S3, Package (0x04)
+    {
+        0x01,  /* PM1a_CNT.SLP_TYP */
+        0x01,  /* PM1b_CNT.SLP_TYP */
+        0x0,   /* reserved */
+        0x0    /* reserved */
+    })
+}
+
diff -r 8a29891d6a98 -r 5118aa3562ea tools/firmware/hvmloader/acpi/ssdt_s4.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s4.asl	Fri Nov 18 11:19:21 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s4.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S4.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S4, Package (0x04)
+    {
+        0x00,  /* PM1a_CNT.SLP_TYP */
+        0x00,  /* PM1b_CNT.SLP_TYP */
+        0x00,  /* reserved */
+        0x00   /* reserved */
+    })
+}
+
diff -r 8a29891d6a98 -r 5118aa3562ea tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 11:19:21 2011 +0000
@@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
+        b_info->u.hvm.acpi_s3 = 1;
+        b_info->u.hvm.acpi_s4 = 1;
         b_info->u.hvm.nx = 1;
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
@@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[2] = "platform/acpi_s3";
+        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[4] = "platform/acpi_s4";
+        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 8a29891d6a98 -r 5118aa3562ea tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Nov 18 11:19:21 2011 +0000
@@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
+                                       ("acpi_s3", bool),
+                                       ("acpi_s4", bool),
                                        ("nx", bool),
                                        ("viridian", bool),
                                        ("timeoffset", string),
diff -r 8a29891d6a98 -r 5118aa3562ea tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 18 11:19:21 2011 +0000
@@ -683,6 +683,10 @@ static void parse_config_data(const char
             b_info->u.hvm.apic = l;
         if (!xlu_cfg_get_long (config, "acpi", &l))
             b_info->u.hvm.acpi = l;
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+            b_info->u.hvm.acpi_s3 = l;
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+            b_info->u.hvm.acpi_s4 = l;
         if (!xlu_cfg_get_long (config, "nx", &l))
             b_info->u.hvm.nx = l;
         if (!xlu_cfg_get_long (config, "viridian", &l))

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:26:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:26:26 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMaQ-0003MT-I7
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:26:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMa7-0000je-Fm; Fri, 18 Nov 2011 03:26:07 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMVq-0007uC-1y
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:21:44 -0800
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321615297!3658945!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11860 invoked from network); 18 Nov 2011 11:21:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:21:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315195200"; d="scan'208";a="19220432"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 06:21:38 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 06:21:38 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 5118aa3562ea7d9a3d8fb742d378f9347ae62836
Message-ID: <5118aa3562ea7d9a3d8f.1321615171@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1321615169@cosworth.uk.xensource.com>
References: <patchbomb.1321615169@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 18 Nov 2011 11:19:31 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] Add configuration options to selectively
 disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321615161 0
# Node ID 5118aa3562ea7d9a3d8fb742d378f9347ae62836
# Parent  8a29891d6a98002b299d73253935c161ecf393a1
Add configuration options to selectively disable S3 and S4 ACPI power states.

Introduce acpi_s3 and acpi_s4 configuration options (default=1). The S3 and S4
packages are moved into separate SSDTs and their inclusion is controlled by the
new configuration options.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 8a29891d6a98 -r 5118aa3562ea tools/firmware/hvmloader/acpi/Makefile
--- a/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/Makefile	Fri Nov 18 11:19:21 2011 +0000
@@ -26,7 +26,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 vpath iasl $(PATH)
 all: acpi.a
 
-ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
+ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
 	iasl -vs -p $* -tc $<
 	sed -e 's/AmlCode/$*/g' $*.hex >$@
 	rm -f $*.hex $*.aml
@@ -57,7 +57,7 @@ iasl:
 	@echo 
 	@exit 1
 
-build.o: ssdt_pm.h ssdt_tpm.h
+build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
 
 acpi.a: $(OBJS)
 	$(AR) rc $@ $(OBJS)
diff -r 8a29891d6a98 -r 5118aa3562ea tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Nov 18 11:19:21 2011 +0000
@@ -17,6 +17,8 @@
  */
 
 #include "acpi2_0.h"
+#include "ssdt_s3.h"
+#include "ssdt_s4.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
 #include "../config.h"
@@ -235,6 +237,26 @@ static int construct_secondary_tables(un
         table_ptrs[nr_tables++] = (unsigned long)ssdt;
     }
 
+    if ( !strncmp(xenstore_read("platform/acpi_s3", "1"), "1", 1) )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s3), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    } else {
+        printf("S3 disabled\n");
+    }
+
+    if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1) )
+    {
+        ssdt = mem_alloc(sizeof(ssdt_s4), 16);
+        if (!ssdt) return -1;
+        memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
+        table_ptrs[nr_tables++] = (unsigned long)ssdt;
+    } else {
+        printf("S4 disabled\n");
+    }
+
     /* TPM TCPA and SSDT. */
     tis_hdr = (uint16_t *)0xFED40F00;
     if ( (tis_hdr[0] == tis_signature[0]) &&
diff -r 8a29891d6a98 -r 5118aa3562ea tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Fri Nov 18 11:19:21 2011 +0000
@@ -27,24 +27,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
     Name (\APCL, 0x00010000)
     Name (\PUID, 0x00)
 
-    /*
-     * S3 (suspend-to-ram), S4 (suspend-to-disc) and S5 (power-off) type codes:
-     * must match piix4 emulation.
-     */
-    Name (\_S3, Package (0x04)
-    {
-        0x01,  /* PM1a_CNT.SLP_TYP */
-        0x01,  /* PM1b_CNT.SLP_TYP */
-        0x0,   /* reserved */
-        0x0    /* reserved */
-    })
-    Name (\_S4, Package (0x04)
-    {
-        0x00,  /* PM1a_CNT.SLP_TYP */
-        0x00,  /* PM1b_CNT.SLP_TYP */
-        0x00,  /* reserved */
-        0x00   /* reserved */
-    })
+    /* _S3 and _S4 are in separate SSDTs */
     Name (\_S5, Package (0x04)
     {
         0x00,  /* PM1a_CNT.SLP_TYP */
diff -r 8a29891d6a98 -r 5118aa3562ea tools/firmware/hvmloader/acpi/ssdt_s3.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s3.asl	Fri Nov 18 11:19:21 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s3.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S3.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S3, Package (0x04)
+    {
+        0x01,  /* PM1a_CNT.SLP_TYP */
+        0x01,  /* PM1b_CNT.SLP_TYP */
+        0x0,   /* reserved */
+        0x0    /* reserved */
+    })
+}
+
diff -r 8a29891d6a98 -r 5118aa3562ea tools/firmware/hvmloader/acpi/ssdt_s4.asl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/acpi/ssdt_s4.asl	Fri Nov 18 11:19:21 2011 +0000
@@ -0,0 +1,32 @@
+/*
+ * ssdt_s4.asl
+ *
+ * Copyright (c) 2011  Citrix Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+DefinitionBlock ("SSDT_S4.aml", "SSDT", 2, "Xen", "HVM", 0)
+{
+    /* Must match piix emulation */
+    Name (\_S4, Package (0x04)
+    {
+        0x00,  /* PM1a_CNT.SLP_TYP */
+        0x00,  /* PM1b_CNT.SLP_TYP */
+        0x00,  /* reserved */
+        0x00   /* reserved */
+    })
+}
+
diff -r 8a29891d6a98 -r 5118aa3562ea tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/libxl_create.c	Fri Nov 18 11:19:21 2011 +0000
@@ -93,6 +93,8 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.pae = 1;
         b_info->u.hvm.apic = 1;
         b_info->u.hvm.acpi = 1;
+        b_info->u.hvm.acpi_s3 = 1;
+        b_info->u.hvm.acpi_s4 = 1;
         b_info->u.hvm.nx = 1;
         b_info->u.hvm.viridian = 0;
         b_info->u.hvm.hpet = 1;
@@ -189,9 +191,13 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 3, sizeof(char *));
+        localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[2] = "platform/acpi_s3";
+        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[4] = "platform/acpi_s4";
+        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 8a29891d6a98 -r 5118aa3562ea tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Nov 18 11:19:21 2011 +0000
@@ -167,6 +167,8 @@ libxl_domain_build_info = Struct("domain
                                        ("pae", bool),
                                        ("apic", bool),
                                        ("acpi", bool),
+                                       ("acpi_s3", bool),
+                                       ("acpi_s4", bool),
                                        ("nx", bool),
                                        ("viridian", bool),
                                        ("timeoffset", string),
diff -r 8a29891d6a98 -r 5118aa3562ea tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 18 10:33:33 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 18 11:19:21 2011 +0000
@@ -683,6 +683,10 @@ static void parse_config_data(const char
             b_info->u.hvm.apic = l;
         if (!xlu_cfg_get_long (config, "acpi", &l))
             b_info->u.hvm.acpi = l;
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+            b_info->u.hvm.acpi_s3 = l;
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+            b_info->u.hvm.acpi_s4 = l;
         if (!xlu_cfg_get_long (config, "nx", &l))
             b_info->u.hvm.nx = l;
         if (!xlu_cfg_get_long (config, "viridian", &l))

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:27:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:27:29 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMbR-0003Ml-DO
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMb7-00017X-Fq; Fri, 18 Nov 2011 03:27:09 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMVz-0007w0-Lt
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:21:52 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321615308!3661986!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6796 invoked from network); 18 Nov 2011 11:21:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:21:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:21:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 11:21:48 +0000
Subject: RE: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Fri, 18 Nov 2011 11:21:47 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B4543AB75A@LONPMAILBOX01.citrite.net>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
	<66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
	<1321612878.3664.299.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B4543AB75A@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321615308.3664.320.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:11 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 18 November 2011 10:41
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
> > selectively disable S3 and S4 ACPI power states
> > 
> > On Fri, 2011-11-18 at 10:29 +0000, Paul Durrant wrote:
> > > diff -r d22ef0f60497 -r 66bdcb90560f
> > tools/firmware/hvmloader/hvmloader.c
> > > --- a/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18
> > 10:28:52 2011 +0000
> > > +++ b/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18
> > 10:28:53 2011 +0000
> > > @@ -516,11 +516,17 @@ int main(void)
> > >              .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
> > >              .value = 1,
> > >          };
> > > +        int s3_enabled, s4_enabled;
> > > +
> > > +        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3",
> > "1"), "1", 1);
> > > +        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4",
> > "1"),
> > > + "1", 1);
> > 
> > Is it not possible to do these in the underlying acpi_build_tables
> > and avoid the need to plumb them right the way through?
> > 
> 
> I guess that would be possible. It just seemed logical to group the
> acpi config xenstore reads close together. If we're happy to
> distribute use of the xenstore client code to all corners of the
> source then I can certainly do that.

FWIW I think that's ok.

if we wanted to keep them together we could push the acpi check itself
down too and just return without doing anything in that case. I don't
think it's worth it though...

> 
> > >          if ( bios->acpi_build_tables )
> > >          {
> > > -            printf("Loading ACPI ...\n");
> > > -            bios->acpi_build_tables();
> > > +            printf("Loading ACPI (S3=%s S4=%s) ...\n",
> > > +                   (s3_enabled) ? "ON" : "OFF",
> > > +                   (s4_enabled) ? "ON" : "OFF");
> > 
> > If possible this printf could also be pushed down so you can
> > continue to print the config info.
> > 
> 
> Well, if the xenstore reads are pushed down then I'd clearly need to do that too :-)

That what I was trying (and failing) to say...

> 
> > > +            bios->acpi_build_tables(s3_enabled, s4_enabled);
> > >          }
> > >
> > >          acpi_enable_sci();
> > 
> > Ian.
> > 
> 
>   Paul



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:27:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:27:29 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMbR-0003Ml-DO
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMb7-00017X-Fq; Fri, 18 Nov 2011 03:27:09 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMVz-0007w0-Lt
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:21:52 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321615308!3661986!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6796 invoked from network); 18 Nov 2011 11:21:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:21:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:21:48 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 11:21:48 +0000
Subject: RE: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Fri, 18 Nov 2011 11:21:47 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B4543AB75A@LONPMAILBOX01.citrite.net>
References: <patchbomb.1321612139@cosworth.uk.xensource.com>
	<66bdcb90560f1b996fa3.1321612141@cosworth.uk.xensource.com>
	<1321612878.3664.299.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B4543AB75A@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321615308.3664.320.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:11 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 18 November 2011 10:41
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
> > selectively disable S3 and S4 ACPI power states
> > 
> > On Fri, 2011-11-18 at 10:29 +0000, Paul Durrant wrote:
> > > diff -r d22ef0f60497 -r 66bdcb90560f
> > tools/firmware/hvmloader/hvmloader.c
> > > --- a/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18
> > 10:28:52 2011 +0000
> > > +++ b/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18
> > 10:28:53 2011 +0000
> > > @@ -516,11 +516,17 @@ int main(void)
> > >              .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
> > >              .value = 1,
> > >          };
> > > +        int s3_enabled, s4_enabled;
> > > +
> > > +        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3",
> > "1"), "1", 1);
> > > +        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4",
> > "1"),
> > > + "1", 1);
> > 
> > Is it not possible to do these in the underlying acpi_build_tables
> > and avoid the need to plumb them right the way through?
> > 
> 
> I guess that would be possible. It just seemed logical to group the
> acpi config xenstore reads close together. If we're happy to
> distribute use of the xenstore client code to all corners of the
> source then I can certainly do that.

FWIW I think that's ok.

if we wanted to keep them together we could push the acpi check itself
down too and just return without doing anything in that case. I don't
think it's worth it though...

> 
> > >          if ( bios->acpi_build_tables )
> > >          {
> > > -            printf("Loading ACPI ...\n");
> > > -            bios->acpi_build_tables();
> > > +            printf("Loading ACPI (S3=%s S4=%s) ...\n",
> > > +                   (s3_enabled) ? "ON" : "OFF",
> > > +                   (s4_enabled) ? "ON" : "OFF");
> > 
> > If possible this printf could also be pushed down so you can
> > continue to print the config info.
> > 
> 
> Well, if the xenstore reads are pushed down then I'd clearly need to do that too :-)

That what I was trying (and failing) to say...

> 
> > > +            bios->acpi_build_tables(s3_enabled, s4_enabled);
> > >          }
> > >
> > >          acpi_enable_sci();
> > 
> > Ian.
> > 
> 
>   Paul



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:45:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:45:06 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMsU-0003Ql-3z
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMs6-0002Ri-9b; Fri, 18 Nov 2011 03:44:42 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMra-0002GO-RN
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:44:11 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1321616647!3651115!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13942 invoked from network); 18 Nov 2011 11:44:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:44:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:44:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 11:44:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RRMrX-0004mE-5R	for xen-devel@lists.xensource.com;
	Fri, 18 Nov 2011 11:44:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RRMrX-0005SU-1N	for
	xen-devel@lists.xensource.com; Fri, 18 Nov 2011 11:44:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20166.17671.31106.347039@mariner.uk.xensource.com>
Date: Fri, 18 Nov 2011 11:44:07 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Test message
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We think we've moved the listserver.  There's no need to reply,
hopefully ...

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:45:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:45:06 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMsU-0003Ql-3z
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMs6-0002Ri-9b; Fri, 18 Nov 2011 03:44:42 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMra-0002GO-RN
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:44:11 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1321616647!3651115!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13942 invoked from network); 18 Nov 2011 11:44:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:44:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:44:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 11:44:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RRMrX-0004mE-5R	for xen-devel@lists.xensource.com;
	Fri, 18 Nov 2011 11:44:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RRMrX-0005SU-1N	for
	xen-devel@lists.xensource.com; Fri, 18 Nov 2011 11:44:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20166.17671.31106.347039@mariner.uk.xensource.com>
Date: Fri, 18 Nov 2011 11:44:07 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Test message
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We think we've moved the listserver.  There's no need to reply,
hopefully ...

Thanks,
Ian.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:46:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:46:06 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMtS-0003Qy-68
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:46:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMt7-0002q2-8s; Fri, 18 Nov 2011 03:45:45 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMt4-0002p8-Gv
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:45:42 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321616715!45129842!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17424 invoked from network); 18 Nov 2011 11:45:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:45:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007732"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:45:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 11:45:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RRMt0-0004mq-Li	for xen-devel@lists.xensource.com;
	Fri, 18 Nov 2011 11:45:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RRMt0-0005T1-Ki	for
	xen-devel@lists.xensource.com; Fri, 18 Nov 2011 11:45:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20166.17762.629323.709358@mariner.uk.xensource.com>
Date: Fri, 18 Nov 2011 11:45:38 +0000
To: xen-devel@lists.xensource.com
In-Reply-To: <20157.22344.959076.649413@mariner.uk.xensource.com>
References: <20157.22344.959076.649413@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Re: xenbits downtime
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("xenbits downtime"):
> As part of this we will be moving xenbits.xen.org aka
> xenbits.xensource.com to new hosting.  The visible effect should be
> that it will be down for an hour or so, hopefully on Monday afternoon
> UK time.  I'll post a more specific announcement when I take the old
> service down and when I bring the new one up.

This was a bit delayed but is about to happen now.  I'll post again
in a bit.

Ian.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:46:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:46:06 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMtS-0003Qy-68
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:46:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMt7-0002q2-8s; Fri, 18 Nov 2011 03:45:45 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMt4-0002p8-Gv
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:45:42 -0800
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321616715!45129842!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17424 invoked from network); 18 Nov 2011 11:45:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:45:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007732"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:45:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 11:45:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RRMt0-0004mq-Li	for xen-devel@lists.xensource.com;
	Fri, 18 Nov 2011 11:45:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RRMt0-0005T1-Ki	for
	xen-devel@lists.xensource.com; Fri, 18 Nov 2011 11:45:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20166.17762.629323.709358@mariner.uk.xensource.com>
Date: Fri, 18 Nov 2011 11:45:38 +0000
To: xen-devel@lists.xensource.com
In-Reply-To: <20157.22344.959076.649413@mariner.uk.xensource.com>
References: <20157.22344.959076.649413@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Re: xenbits downtime
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("xenbits downtime"):
> As part of this we will be moving xenbits.xen.org aka
> xenbits.xensource.com to new hosting.  The visible effect should be
> that it will be down for an hour or so, hopefully on Monday afternoon
> UK time.  I'll post a more specific announcement when I take the old
> service down and when I bring the new one up.

This was a bit delayed but is about to happen now.  I'll post again
in a bit.

Ian.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:46:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:46:51 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMuB-0003RJ-Jh
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:46:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMtr-0003DU-7q; Fri, 18 Nov 2011 03:46:31 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMtd-00035r-BO
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:46:17 -0800
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321616774!3662852!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14828 invoked from network); 18 Nov 2011 11:46:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:46:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:46:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 11:46:03 +0000
Date: Fri, 18 Nov 2011 11:46:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>
	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EC27D0D.3040204@codemonkey.ws>
	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, "agraf@suse.de" <agraf@suse.de>
Subject: [Xen-devel] Re: [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 15 Nov 2011, Stefano Stabellini wrote:
> On Tue, 15 Nov 2011, Anthony Liguori wrote:
> > On 11/15/2011 08:51 AM, stefano.stabellini@eu.citrix.com wrote:
> > > From: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > >
> > > Xen doesn't need full RTC emulation in Qemu because the RTC is already
> > > emulated by the hypervisor. In particular we want to avoid the timers
> > > initialization so that Qemu doesn't need to wake up needlessly.
> > >
> > > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > 
> > Yuck.  There's got to be a better way to do this.
> 
> Yeah, it is pretty ugly, I was hoping in some good suggestions to
> improve this patch :)
> 
> 
> > I think it would be better to name timers and then in Xen specific machine code, 
> > disable the RTC timers.
> 
> Good idea!
> I was thinking that I could implement an rtc_stop function in
> mc146818rtc.c that stops and frees the timers.
> 
> Now the problem is that from xen-all.c I cannot easily find the
> ISADevice instance to pass to rtc_stop. Do you think it would be
> reasonable to call rtc_stop from pc_basic_device_init, inside the same
> if (!xen_available()) introduce by the next patch?
> 
> Otherwise I could implement functions to walk the isa bus, similarly to
> pci_for_each_device.
> 

ping?


> This is just an example:
> 
> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> index 2aaca2f..568c540 100644
> --- a/hw/mc146818rtc.c
> +++ b/hw/mc146818rtc.c
> @@ -667,6 +667,28 @@ ISADevice *rtc_init(int base_year, qemu_irq intercept_irq)
>      return dev;
>  }
>  
> +void rtc_stop(ISADevice *dev)
> +{
> +    RTCState *s = DO_UPCAST(RTCState, dev, dev);
> +
> +    qemu_del_timer(s->periodic_timer);
> +    qemu_del_timer(s->second_timer);
> +    qemu_del_timer(s->second_timer2);
> +#ifdef TARGET_I386
> +    if (rtc_td_hack) {
> +        qemu_del_timer(s->coalesced_timer);
> +    }
> +#endif
> +    qemu_free_timer(s->periodic_timer);
> +    qemu_free_timer(s->second_timer);
> +    qemu_free_timer(s->second_timer2);
> +#ifdef TARGET_I386
> +    if (rtc_td_hack) {
> +        qemu_free_timer(s->coalesced_timer);
> +    }
> +#endif
> +}
> +
>  static ISADeviceInfo mc146818rtc_info = {
>      .qdev.name     = "mc146818rtc",
>      .qdev.size     = sizeof(RTCState),
> diff --git a/hw/mc146818rtc.h b/hw/mc146818rtc.h
> index 575968c..aa2b8ab 100644
> --- a/hw/mc146818rtc.h
> +++ b/hw/mc146818rtc.h
> @@ -8,5 +8,6 @@
>  ISADevice *rtc_init(int base_year, qemu_irq intercept_irq);
>  void rtc_set_memory(ISADevice *dev, int addr, int val);
>  void rtc_set_date(ISADevice *dev, const struct tm *tm);
> +void rtc_stop(ISADevice *dev);
>  
>  #endif /* !MC146818RTC_H */
> diff --git a/hw/pc.c b/hw/pc.c
> index a0ae981..d734f75 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -1145,6 +1145,8 @@ void pc_basic_device_init(qemu_irq *gsi,
>  
>      if (!xen_available()) {
>          pit = pit_init(0x40, 0);
> +    } else {
> +        rtc_stop(*rtc_state);
>      }
>      pcspk_init(pit);
>  
> 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:46:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:46:51 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMuB-0003RJ-Jh
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:46:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMtr-0003DU-7q; Fri, 18 Nov 2011 03:46:31 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMtd-00035r-BO
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:46:17 -0800
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321616774!3662852!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14828 invoked from network); 18 Nov 2011 11:46:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:46:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:46:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 11:46:03 +0000
Date: Fri, 18 Nov 2011 11:46:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>
	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EC27D0D.3040204@codemonkey.ws>
	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, "agraf@suse.de" <agraf@suse.de>
Subject: [Xen-devel] Re: [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 15 Nov 2011, Stefano Stabellini wrote:
> On Tue, 15 Nov 2011, Anthony Liguori wrote:
> > On 11/15/2011 08:51 AM, stefano.stabellini@eu.citrix.com wrote:
> > > From: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > >
> > > Xen doesn't need full RTC emulation in Qemu because the RTC is already
> > > emulated by the hypervisor. In particular we want to avoid the timers
> > > initialization so that Qemu doesn't need to wake up needlessly.
> > >
> > > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > 
> > Yuck.  There's got to be a better way to do this.
> 
> Yeah, it is pretty ugly, I was hoping in some good suggestions to
> improve this patch :)
> 
> 
> > I think it would be better to name timers and then in Xen specific machine code, 
> > disable the RTC timers.
> 
> Good idea!
> I was thinking that I could implement an rtc_stop function in
> mc146818rtc.c that stops and frees the timers.
> 
> Now the problem is that from xen-all.c I cannot easily find the
> ISADevice instance to pass to rtc_stop. Do you think it would be
> reasonable to call rtc_stop from pc_basic_device_init, inside the same
> if (!xen_available()) introduce by the next patch?
> 
> Otherwise I could implement functions to walk the isa bus, similarly to
> pci_for_each_device.
> 

ping?


> This is just an example:
> 
> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> index 2aaca2f..568c540 100644
> --- a/hw/mc146818rtc.c
> +++ b/hw/mc146818rtc.c
> @@ -667,6 +667,28 @@ ISADevice *rtc_init(int base_year, qemu_irq intercept_irq)
>      return dev;
>  }
>  
> +void rtc_stop(ISADevice *dev)
> +{
> +    RTCState *s = DO_UPCAST(RTCState, dev, dev);
> +
> +    qemu_del_timer(s->periodic_timer);
> +    qemu_del_timer(s->second_timer);
> +    qemu_del_timer(s->second_timer2);
> +#ifdef TARGET_I386
> +    if (rtc_td_hack) {
> +        qemu_del_timer(s->coalesced_timer);
> +    }
> +#endif
> +    qemu_free_timer(s->periodic_timer);
> +    qemu_free_timer(s->second_timer);
> +    qemu_free_timer(s->second_timer2);
> +#ifdef TARGET_I386
> +    if (rtc_td_hack) {
> +        qemu_free_timer(s->coalesced_timer);
> +    }
> +#endif
> +}
> +
>  static ISADeviceInfo mc146818rtc_info = {
>      .qdev.name     = "mc146818rtc",
>      .qdev.size     = sizeof(RTCState),
> diff --git a/hw/mc146818rtc.h b/hw/mc146818rtc.h
> index 575968c..aa2b8ab 100644
> --- a/hw/mc146818rtc.h
> +++ b/hw/mc146818rtc.h
> @@ -8,5 +8,6 @@
>  ISADevice *rtc_init(int base_year, qemu_irq intercept_irq);
>  void rtc_set_memory(ISADevice *dev, int addr, int val);
>  void rtc_set_date(ISADevice *dev, const struct tm *tm);
> +void rtc_stop(ISADevice *dev);
>  
>  #endif /* !MC146818RTC_H */
> diff --git a/hw/pc.c b/hw/pc.c
> index a0ae981..d734f75 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -1145,6 +1145,8 @@ void pc_basic_device_init(qemu_irq *gsi,
>  
>      if (!xen_available()) {
>          pit = pit_init(0x40, 0);
> +    } else {
> +        rtc_stop(*rtc_state);
>      }
>      pcspk_init(pit);
>  
> 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:49:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:49:17 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMwX-0003RW-PL
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:49:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMwD-0003d1-LW; Fri, 18 Nov 2011 03:48:57 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMwA-0003by-8C
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:48:54 -0800
X-Env-Sender: nhorman@tuxdriver.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321616930!3681822!1
X-Originating-IP: [70.61.120.58]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21314 invoked from network); 18 Nov 2011 11:48:51 -0000
Received: from charlotte.tuxdriver.com (HELO smtp.tuxdriver.com) (70.61.120.58)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 11:48:51 -0000
Received: from hmsreliant.think-freely.org
	([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost)
	by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63)
	(envelope-from <nhorman@tuxdriver.com>)
	id 1RRMvw-0008FV-1s; Fri, 18 Nov 2011 06:48:42 -0500
Date: Fri, 18 Nov 2011 06:48:39 -0500
From: Neil Horman <nhorman@tuxdriver.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111118114839.GA7907@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
	<1321561021.8866.12.camel@dagon.hellion.org.uk>
	<20111117204553.GD26847@hmsreliant.think-freely.org>
	<1321612213.3664.293.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1321612213.3664.293.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: 0.2 (/)
X-Spam-Status: No
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 10:30:13AM +0000, Ian Campbell wrote:
> On Thu, 2011-11-17 at 20:45 +0000, Neil Horman wrote:
> > On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> > > On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > > > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > > > 
> > > > > What are the actual constraints here? The skb is used as a handle to the
> > > > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > > > those which are passed to the hypervisor (effectively the same as
> > > > > passing those addresses to the h/w for DMA).
> > > > > 
> > > > > Which parts of the skb are expected/allowed to not remain stable?
> > > > > 
> > > > > (Appologies if the above seems naive, I seem to have missed the
> > > > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > > > 
> > > > Its ok, this is the most accurate description from the previous threads on the
> > > > subject:
> > > > 2
> > > > 
> > > > The basic problem boils down the notion that some drivers, when they receive an
> > > > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > > > result may do things like add the skb to a list, or otherwise store stateful
> > > > data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> > > > holds a reference to the skb, and make make changes without serializing them
> > > > against the driver.  So we have to flag those drivers which preform these kinds
> > > > of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> > > > an skb, but it does place a pointer to the skb in a data structure here:
> > > > 
> > > > np->tx_skbs[id].skb = skb;
> > > > 
> > > > Which then gets handed off to the hypervisior.  Since the hypervisor now has
> > > > access to that skb pointer, and we can't be sure (from the guest perspective),
> > > > what it does with that information, it would be better to be safe by disallowing
> > > > shared skbs in this path.
> > > 
> > > The skb pointer itself doesn't get given to the backend/hypervisor. The
> > > page which skb->data refers to is granted to the backend domain, as are
> > > the pages in the frags.
> > > 
> > > I think we only need to be sure that the frontend doesn't rely on
> > > anything in the skb itself, right? Does skb->data or shinfo count from
> > > that perspective?
> > shinfo is definately a problem, as other devices may make modifications to it.
> > skb->data is probably safer, but is also potentially suspect (for instance if
> > another device appends an additional header to the data for instance)
> 
> A device is allowed to rely on these things being stable while in its
> start_xmit, right? (otherwise I don't see how any device can ever
> cope...).
> 
While the start_xmit routine is executing, yes.  Its only after the driver
returns, that it can have no expectation of an skb's data to remain stable.

> netfront only uses shinfo and ->data during start_xmit in order to
> create the necessary grant reference (which can be thought of as a DMA
> address passed to the virtual hardware). The only use of the stashed skb
> pointer outside of this are to dev_kfree_skb on tx completion (from
> either tx_buf_gc (normal completion) or release_tx_buf ("hardware"
> reset).
> 
Ok, if you're certain you can guarantee that the hypervisior makes no inspection
of the skb after the return from the driver, then you're safe
Neil

> Ian.
> 
> 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:49:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:49:17 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRMwX-0003RW-PL
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:49:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRMwD-0003d1-LW; Fri, 18 Nov 2011 03:48:57 -0800
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRMwA-0003by-8C
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:48:54 -0800
X-Env-Sender: nhorman@tuxdriver.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321616930!3681822!1
X-Originating-IP: [70.61.120.58]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21314 invoked from network); 18 Nov 2011 11:48:51 -0000
Received: from charlotte.tuxdriver.com (HELO smtp.tuxdriver.com) (70.61.120.58)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 11:48:51 -0000
Received: from hmsreliant.think-freely.org
	([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost)
	by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63)
	(envelope-from <nhorman@tuxdriver.com>)
	id 1RRMvw-0008FV-1s; Fri, 18 Nov 2011 06:48:42 -0500
Date: Fri, 18 Nov 2011 06:48:39 -0500
From: Neil Horman <nhorman@tuxdriver.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111118114839.GA7907@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
	<1321561021.8866.12.camel@dagon.hellion.org.uk>
	<20111117204553.GD26847@hmsreliant.think-freely.org>
	<1321612213.3664.293.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1321612213.3664.293.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: 0.2 (/)
X-Spam-Status: No
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 10:30:13AM +0000, Ian Campbell wrote:
> On Thu, 2011-11-17 at 20:45 +0000, Neil Horman wrote:
> > On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> > > On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > > > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > > > 
> > > > > What are the actual constraints here? The skb is used as a handle to the
> > > > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > > > those which are passed to the hypervisor (effectively the same as
> > > > > passing those addresses to the h/w for DMA).
> > > > > 
> > > > > Which parts of the skb are expected/allowed to not remain stable?
> > > > > 
> > > > > (Appologies if the above seems naive, I seem to have missed the
> > > > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > > > 
> > > > Its ok, this is the most accurate description from the previous threads on the
> > > > subject:
> > > > 2
> > > > 
> > > > The basic problem boils down the notion that some drivers, when they receive an
> > > > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > > > result may do things like add the skb to a list, or otherwise store stateful
> > > > data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> > > > holds a reference to the skb, and make make changes without serializing them
> > > > against the driver.  So we have to flag those drivers which preform these kinds
> > > > of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> > > > an skb, but it does place a pointer to the skb in a data structure here:
> > > > 
> > > > np->tx_skbs[id].skb = skb;
> > > > 
> > > > Which then gets handed off to the hypervisior.  Since the hypervisor now has
> > > > access to that skb pointer, and we can't be sure (from the guest perspective),
> > > > what it does with that information, it would be better to be safe by disallowing
> > > > shared skbs in this path.
> > > 
> > > The skb pointer itself doesn't get given to the backend/hypervisor. The
> > > page which skb->data refers to is granted to the backend domain, as are
> > > the pages in the frags.
> > > 
> > > I think we only need to be sure that the frontend doesn't rely on
> > > anything in the skb itself, right? Does skb->data or shinfo count from
> > > that perspective?
> > shinfo is definately a problem, as other devices may make modifications to it.
> > skb->data is probably safer, but is also potentially suspect (for instance if
> > another device appends an additional header to the data for instance)
> 
> A device is allowed to rely on these things being stable while in its
> start_xmit, right? (otherwise I don't see how any device can ever
> cope...).
> 
While the start_xmit routine is executing, yes.  Its only after the driver
returns, that it can have no expectation of an skb's data to remain stable.

> netfront only uses shinfo and ->data during start_xmit in order to
> create the necessary grant reference (which can be thought of as a DMA
> address passed to the virtual hardware). The only use of the stashed skb
> pointer outside of this are to dev_kfree_skb on tx completion (from
> either tx_buf_gc (normal completion) or release_tx_buf ("hardware"
> reset).
> 
Ok, if you're certain you can guarantee that the hypervisior makes no inspection
of the skb after the return from the driver, then you're safe
Neil

> Ian.
> 
> 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:53:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:53:36 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRN0i-0003Rj-JA
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:53:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRN0O-0004CA-OC; Fri, 18 Nov 2011 03:53:16 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN0L-0004BH-Gq
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:53:13 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321617190!4064606!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2379 invoked from network); 18 Nov 2011 11:53:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:53:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 11:53:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 18 Nov 2011 11:53:09 +0000
In-Reply-To: <20111118114839.GA7907@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
	<1321561021.8866.12.camel@dagon.hellion.org.uk>
	<20111117204553.GD26847@hmsreliant.think-freely.org>
	<1321612213.3664.293.camel@zakaz.uk.xensource.com>
	<20111118114839.GA7907@hmsreliant.think-freely.org>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321617190.3664.338.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:48 +0000, Neil Horman wrote:
> On Fri, Nov 18, 2011 at 10:30:13AM +0000, Ian Campbell wrote:
> > On Thu, 2011-11-17 at 20:45 +0000, Neil Horman wrote:
> > > On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> > > > On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > > > > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > > > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > > > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > > > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > > > > 
> > > > > > What are the actual constraints here? The skb is used as a handle to the
> > > > > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > > > > those which are passed to the hypervisor (effectively the same as
> > > > > > passing those addresses to the h/w for DMA).
> > > > > > 
> > > > > > Which parts of the skb are expected/allowed to not remain stable?
> > > > > > 
> > > > > > (Appologies if the above seems naive, I seem to have missed the
> > > > > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > > > > 
> > > > > Its ok, this is the most accurate description from the previous threads on the
> > > > > subject:
> > > > > 2
> > > > > 
> > > > > The basic problem boils down the notion that some drivers, when they receive an
> > > > > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > > > > result may do things like add the skb to a list, or otherwise store stateful
> > > > > data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> > > > > holds a reference to the skb, and make make changes without serializing them
> > > > > against the driver.  So we have to flag those drivers which preform these kinds
> > > > > of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> > > > > an skb, but it does place a pointer to the skb in a data structure here:
> > > > > 
> > > > > np->tx_skbs[id].skb = skb;
> > > > > 
> > > > > Which then gets handed off to the hypervisior.  Since the hypervisor now has
> > > > > access to that skb pointer, and we can't be sure (from the guest perspective),
> > > > > what it does with that information, it would be better to be safe by disallowing
> > > > > shared skbs in this path.
> > > > 
> > > > The skb pointer itself doesn't get given to the backend/hypervisor. The
> > > > page which skb->data refers to is granted to the backend domain, as are
> > > > the pages in the frags.
> > > > 
> > > > I think we only need to be sure that the frontend doesn't rely on
> > > > anything in the skb itself, right? Does skb->data or shinfo count from
> > > > that perspective?
> > > shinfo is definately a problem, as other devices may make modifications to it.
> > > skb->data is probably safer, but is also potentially suspect (for instance if
> > > another device appends an additional header to the data for instance)
> > 
> > A device is allowed to rely on these things being stable while in its
> > start_xmit, right? (otherwise I don't see how any device can ever
> > cope...).
> > 
> While the start_xmit routine is executing, yes.  Its only after the driver
> returns, that it can have no expectation of an skb's data to remain stable.
> 
> > netfront only uses shinfo and ->data during start_xmit in order to
> > create the necessary grant reference (which can be thought of as a DMA
> > address passed to the virtual hardware). The only use of the stashed skb
> > pointer outside of this are to dev_kfree_skb on tx completion (from
> > either tx_buf_gc (normal completion) or release_tx_buf ("hardware"
> > reset).
> > 
> Ok, if you're certain you can guarantee that the hypervisior makes no inspection
> of the skb after the return from the driver, then you're safe

I believe this is the case, all that is exposed to the backend is the
pfn, offset and length of the skb->data and frags at the time start_xmit
was called.

> Neil
> 
> > Ian.
> > 
> > 



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 11:53:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 11:53:36 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRN0i-0003Rj-JA
	for archives@lists.xen.org; Fri, 18 Nov 2011 11:53:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRN0O-0004CA-OC; Fri, 18 Nov 2011 03:53:16 -0800
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN0L-0004BH-Gq
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 03:53:13 -0800
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321617190!4064606!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2379 invoked from network); 18 Nov 2011 11:53:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9007926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 11:53:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 11:53:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 18 Nov 2011 11:53:09 +0000
In-Reply-To: <20111118114839.GA7907@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
	<1321561021.8866.12.camel@dagon.hellion.org.uk>
	<20111117204553.GD26847@hmsreliant.think-freely.org>
	<1321612213.3664.293.camel@zakaz.uk.xensource.com>
	<20111118114839.GA7907@hmsreliant.think-freely.org>
Organization: Citrix Systems, Inc.
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3- 
Content-Transfer-Encoding: 7bit
Message-ID: <1321617190.3664.338.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:48 +0000, Neil Horman wrote:
> On Fri, Nov 18, 2011 at 10:30:13AM +0000, Ian Campbell wrote:
> > On Thu, 2011-11-17 at 20:45 +0000, Neil Horman wrote:
> > > On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> > > > On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > > > > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > > > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > > > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > > > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > > > > 
> > > > > > What are the actual constraints here? The skb is used as a handle to the
> > > > > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > > > > those which are passed to the hypervisor (effectively the same as
> > > > > > passing those addresses to the h/w for DMA).
> > > > > > 
> > > > > > Which parts of the skb are expected/allowed to not remain stable?
> > > > > > 
> > > > > > (Appologies if the above seems naive, I seem to have missed the
> > > > > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > > > > 
> > > > > Its ok, this is the most accurate description from the previous threads on the
> > > > > subject:
> > > > > 2
> > > > > 
> > > > > The basic problem boils down the notion that some drivers, when they receive an
> > > > > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > > > > result may do things like add the skb to a list, or otherwise store stateful
> > > > > data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> > > > > holds a reference to the skb, and make make changes without serializing them
> > > > > against the driver.  So we have to flag those drivers which preform these kinds
> > > > > of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> > > > > an skb, but it does place a pointer to the skb in a data structure here:
> > > > > 
> > > > > np->tx_skbs[id].skb = skb;
> > > > > 
> > > > > Which then gets handed off to the hypervisior.  Since the hypervisor now has
> > > > > access to that skb pointer, and we can't be sure (from the guest perspective),
> > > > > what it does with that information, it would be better to be safe by disallowing
> > > > > shared skbs in this path.
> > > > 
> > > > The skb pointer itself doesn't get given to the backend/hypervisor. The
> > > > page which skb->data refers to is granted to the backend domain, as are
> > > > the pages in the frags.
> > > > 
> > > > I think we only need to be sure that the frontend doesn't rely on
> > > > anything in the skb itself, right? Does skb->data or shinfo count from
> > > > that perspective?
> > > shinfo is definately a problem, as other devices may make modifications to it.
> > > skb->data is probably safer, but is also potentially suspect (for instance if
> > > another device appends an additional header to the data for instance)
> > 
> > A device is allowed to rely on these things being stable while in its
> > start_xmit, right? (otherwise I don't see how any device can ever
> > cope...).
> > 
> While the start_xmit routine is executing, yes.  Its only after the driver
> returns, that it can have no expectation of an skb's data to remain stable.
> 
> > netfront only uses shinfo and ->data during start_xmit in order to
> > create the necessary grant reference (which can be thought of as a DMA
> > address passed to the virtual hardware). The only use of the stashed skb
> > pointer outside of this are to dev_kfree_skb on tx completion (from
> > either tx_buf_gc (normal completion) or release_tx_buf ("hardware"
> > reset).
> > 
> Ok, if you're certain you can guarantee that the hypervisior makes no inspection
> of the skb after the return from the driver, then you're safe

I believe this is the case, all that is exposed to the backend is the
pfn, offset and length of the skb->data and frags at the time start_xmit
was called.

> Neil
> 
> > Ian.
> > 
> > 



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:02:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:02:13 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRN92-0003SO-WE
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRN8i-0004iu-84; Fri, 18 Nov 2011 04:01:52 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN76-0004fy-57
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:18 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!1
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11635 invoked from network); 18 Nov 2011 11:59:35 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:35 -0000
Received: by eyb6 with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=irMGGL48qZ49NKgKshCwMqKHvW2ZgM4EOJVrd8lSUcA=;
	b=G8Z/dekrBI5o1+F6mCaM1D9D4n5T0ePdxk2inIPXvOZQIBJ+xGWHK5bvJ1JH0hGkCn
	K041jbo9ONhyY7OBAhPaa5nNW1wgaEOp2EQ9Bu+dtmEOgHa0nREHnTCA9Kq46NRTxSoH
	/92mHPqBuWyJ/2gJNULTCtS9dbX/LU1k2mXJw=
Received: by 10.213.10.10 with SMTP id n10mr969684ebn.114.1321617606810;
	Fri, 18 Nov 2011 04:00:06 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:05 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-Id: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:36 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 9 v2] libxl: add support for hotplug script
 calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for hotplug script calling directly
from libxl, instead of relying on xenbackendd. Also some patches
contain general bug fixes.

Currently Linux hotplug script call functions are empty, so Linux
continues to use udev rules to call hotplug scripts.

Patches 1, 7, 8, 9 are NetBSD specific, and basicaly pave the way for
the application of the bigger changes present in this series.

Patch 2 adds support for mounting raw image files using the vnd
device. Since NetBSD doesn't have qdisk or blktap support, the only
way to use raw images with guests is to mount the image and pass the
block device as a "PHY" backend. To check wheter an OS supports raw
images as "PHY" backends two new files are added to the project, to
avoid using #ifdefs, that contain a helper function. The file
to be included is decided during the compilation process.

Patch 3 adds a generic function to fork the current process and
execute a given file, which will be later used to execute hotplug
scripts synchronously.

Patches 4 and 5 add a new function to wait for a device to reach a
certain state, and replace wait_for_dev_destroy with this more generic
implementation. This function is also used to wait for device
initialization before calling hotplug scripts. The added function will
benefit from a rework after event support is added to libxl.

Finally patch 6 adds the calling of hotplug scripts when devices are
initializated and removed. Two new files are also added to support
hotplug scripts, since Linux and NetBSD hotplug scripts have different
call parameters. The path of the script to execute is retrieved
from xenstore. The file to include is also decided at compile
time.

Please review, Roger.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:02:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:02:13 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRN92-0003SO-WE
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRN8i-0004iu-84; Fri, 18 Nov 2011 04:01:52 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN76-0004fy-57
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:18 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!1
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11635 invoked from network); 18 Nov 2011 11:59:35 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:35 -0000
Received: by eyb6 with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=irMGGL48qZ49NKgKshCwMqKHvW2ZgM4EOJVrd8lSUcA=;
	b=G8Z/dekrBI5o1+F6mCaM1D9D4n5T0ePdxk2inIPXvOZQIBJ+xGWHK5bvJ1JH0hGkCn
	K041jbo9ONhyY7OBAhPaa5nNW1wgaEOp2EQ9Bu+dtmEOgHa0nREHnTCA9Kq46NRTxSoH
	/92mHPqBuWyJ/2gJNULTCtS9dbX/LU1k2mXJw=
Received: by 10.213.10.10 with SMTP id n10mr969684ebn.114.1321617606810;
	Fri, 18 Nov 2011 04:00:06 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:05 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-Id: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:36 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 9 v2] libxl: add support for hotplug script
 calling from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series adds support for hotplug script calling directly
from libxl, instead of relying on xenbackendd. Also some patches
contain general bug fixes.

Currently Linux hotplug script call functions are empty, so Linux
continues to use udev rules to call hotplug scripts.

Patches 1, 7, 8, 9 are NetBSD specific, and basicaly pave the way for
the application of the bigger changes present in this series.

Patch 2 adds support for mounting raw image files using the vnd
device. Since NetBSD doesn't have qdisk or blktap support, the only
way to use raw images with guests is to mount the image and pass the
block device as a "PHY" backend. To check wheter an OS supports raw
images as "PHY" backends two new files are added to the project, to
avoid using #ifdefs, that contain a helper function. The file
to be included is decided during the compilation process.

Patch 3 adds a generic function to fork the current process and
execute a given file, which will be later used to execute hotplug
scripts synchronously.

Patches 4 and 5 add a new function to wait for a device to reach a
certain state, and replace wait_for_dev_destroy with this more generic
implementation. This function is also used to wait for device
initialization before calling hotplug scripts. The added function will
benefit from a rework after event support is added to libxl.

Finally patch 6 adds the calling of hotplug scripts when devices are
initializated and removed. Two new files are also added to support
hotplug scripts, since Linux and NetBSD hotplug scripts have different
call parameters. The path of the script to execute is retrieved
from xenstore. The file to include is also decided at compile
time.

Please review, Roger.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:05:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:05:42 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNCP-0003TH-PS
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNC5-0005AQ-HQ; Fri, 18 Nov 2011 04:05:21 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN77-0004g0-Th
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:19 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!3
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11820 invoked from network); 18 Nov 2011 11:59:39 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:39 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=kDFX6TRaBlhTIEZ31TKIxmd6dRjWCZNeufWrks06dZo=;
	b=gJ9qYR1R5LZIGkIgquXXbdsjlY4SuKNehRX4MWsZAf6QTNSAKx4ecP8g+UZ6Nzuc0l
	SBbvpXmhESEBi+V7zy1aUMgVlIS6i0GWOJ+aXxVJBkh699XUo+vGsyVO2xwkoPkY69Xb
	zVTleH9Nwtt2vy28YPAblC+CO5Z05KZlZwnLs=
Received: by 10.14.3.138 with SMTP id 10mr225549eeh.218.1321617610885;
	Fri, 18 Nov 2011 04:00:10 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:09 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 9e8abd626484f82a95d0edc07834ae287bc9467a
Message-Id: <9e8abd626484f82a95d0.1321617578@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 9 v2] libxl: add support for image files
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 9e8abd626484f82a95d0edc07834ae287bc9467a
# Parent  23578c9942bcc8767adc4e435bb1fd1cd89f5e18
libxl: add support for image files for NetBSD

Created a helper function to detect if the OS is capable of using
image files as phy backends. Create two OS specific files, and
changed the Makefile to choose the correct one at compile time.

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

diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -32,6 +32,12 @@ endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
 
+ifeq ($(CONFIG_NetBSD),y)
+LIBXL_OBJS-y += libxl_phybackend.o
+else
+LIBXL_OBJS-y += libxl_nophybackend.o
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -138,15 +138,14 @@ static int disk_try_backend(disk_try_bac
               a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
             goto bad_format;
         }
-        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
-            !S_ISBLK(a->stab.st_mode)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
-                       " unsuitable as phys path not a block device",
-                       a->disk->vdev);
-            return 0;
-        }
 
-        return backend;
+        if (libxl__try_phy_backend(a->stab.st_mode))
+            return backend;
+
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
+                   " unsuitable as phys path not a block device",
+                   a->disk->vdev);
+        return 0;
 
     case LIBXL_DISK_BACKEND_TAP:
         if (!libxl__blktap_enabled(a->gc)) {
diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -252,6 +252,15 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * libxl__try_phy_backend - Check if there's support for the passed
+ * type of file using the PHY backend
+ * st_mode: mode_t of the file, as returned by stat function
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__try_phy_backend(mode_t st_mode);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_nophybackend.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_nophybackend.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+ 
+#include <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (!S_ISBLK(st_mode)) {
+        return 0;
+    }
+
+    return 1;
+}
diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_phybackend.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_phybackend.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+ 
+#include <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
+        return 1;
+
+    return 0;
+}

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:05:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:05:42 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNCP-0003TH-PS
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNC5-0005AQ-HQ; Fri, 18 Nov 2011 04:05:21 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN77-0004g0-Th
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:19 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!3
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11820 invoked from network); 18 Nov 2011 11:59:39 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:39 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=kDFX6TRaBlhTIEZ31TKIxmd6dRjWCZNeufWrks06dZo=;
	b=gJ9qYR1R5LZIGkIgquXXbdsjlY4SuKNehRX4MWsZAf6QTNSAKx4ecP8g+UZ6Nzuc0l
	SBbvpXmhESEBi+V7zy1aUMgVlIS6i0GWOJ+aXxVJBkh699XUo+vGsyVO2xwkoPkY69Xb
	zVTleH9Nwtt2vy28YPAblC+CO5Z05KZlZwnLs=
Received: by 10.14.3.138 with SMTP id 10mr225549eeh.218.1321617610885;
	Fri, 18 Nov 2011 04:00:10 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:09 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 9e8abd626484f82a95d0edc07834ae287bc9467a
Message-Id: <9e8abd626484f82a95d0.1321617578@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:38 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 9 v2] libxl: add support for image files
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 9e8abd626484f82a95d0edc07834ae287bc9467a
# Parent  23578c9942bcc8767adc4e435bb1fd1cd89f5e18
libxl: add support for image files for NetBSD

Created a helper function to detect if the OS is capable of using
image files as phy backends. Create two OS specific files, and
changed the Makefile to choose the correct one at compile time.

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

diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -32,6 +32,12 @@ endif
 LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
 LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
 
+ifeq ($(CONFIG_NetBSD),y)
+LIBXL_OBJS-y += libxl_phybackend.o
+else
+LIBXL_OBJS-y += libxl_nophybackend.o
+endif
+
 LIBXL_LIBS += -lyajl
 
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -138,15 +138,14 @@ static int disk_try_backend(disk_try_bac
               a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
             goto bad_format;
         }
-        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
-            !S_ISBLK(a->stab.st_mode)) {
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
-                       " unsuitable as phys path not a block device",
-                       a->disk->vdev);
-            return 0;
-        }
 
-        return backend;
+        if (libxl__try_phy_backend(a->stab.st_mode))
+            return backend;
+
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
+                   " unsuitable as phys path not a block device",
+                   a->disk->vdev);
+        return 0;
 
     case LIBXL_DISK_BACKEND_TAP:
         if (!libxl__blktap_enabled(a->gc)) {
diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -252,6 +252,15 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/*
+ * libxl__try_phy_backend - Check if there's support for the passed
+ * type of file using the PHY backend
+ * st_mode: mode_t of the file, as returned by stat function
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__try_phy_backend(mode_t st_mode);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_nophybackend.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_nophybackend.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+ 
+#include <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (!S_ISBLK(st_mode)) {
+        return 0;
+    }
+
+    return 1;
+}
diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_phybackend.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/libxl_phybackend.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+ 
+#include <sys/stat.h>
+
+#include "libxl_internal.h"
+ 
+int libxl__try_phy_backend(mode_t st_mode)
+{
+    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
+        return 1;
+
+    return 0;
+}

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:07:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:07:43 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNEN-0003Tp-O4
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:07:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNE3-0005bC-1k; Fri, 18 Nov 2011 04:07:23 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7C-0004g8-0g
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:20 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!5
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12010 invoked from network); 18 Nov 2011 11:59:43 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:43 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ys1SGhelUQhwBEeNyNN1MlILIG5JkZGn5gj4EJgsv6Y=;
	b=LNCc2Du+6cougpyUnABuul+jAiQt0Q7e18ZqA6WaDvptjTOINqtCRe3qEBwN88Alk9
	avLvW8JvvBspk+RUAI30xWKElp2QSKxseMAey4WORGFNvIJkvolvHqYSUW6WpXlpNRC7
	8kUXH//HQ9u59J7AXzZr1Q1a6u9V3g7rUdyac=
Received: by 10.14.16.37 with SMTP id g37mr239471eeg.43.1321617615012;
	Fri, 18 Nov 2011 04:00:15 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:13 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: a77bba3717402fdf24a72d028ae0f3d482e6f427
Message-Id: <a77bba3717402fdf24a7.1321617580@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:40 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 9 v2] libxl: introduce
	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1321609740 -3600
# Node ID a77bba3717402fdf24a72d028ae0f3d482e6f427
# Parent  ec94a7e4983ad6338db20fa0777a85507b582607
libxl: introduce libxl__wait_for_device_state

This is a generic function, that waits for xs watches to reach a
certain state and then executes the passed helper function. Removed
wait_for_dev_destroy and used this new function instead. This
function will also be used by future patches that need to wait for
the initialization of devices before executing hotplug scripts.

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

diff -r ec94a7e4983a -r a77bba371740 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Nov 18 10:46:54 2011 +0100
+++ b/tools/libxl/libxl_device.c	Fri Nov 18 10:49:00 2011 +0100
@@ -370,7 +370,9 @@ int libxl__device_disk_dev_number(const 
  * Returns 0 if a device is removed, ERROR_* if an error
  * or timeout occurred.
  */
-static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
+int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                 int state,
+                                 libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int nfds, rc;
@@ -395,17 +397,14 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
-                char *state = libxl__xs_read(gc, XBT_NULL,
+                char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
-                if (!state || atoi(state) == 6) {
-                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
-                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
-                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                               "Destroyed device backend at %s",
-                               l1[XS_WATCH_TOKEN]);
-                    rc = 0;
+                if (!sstate || atoi(sstate) == state) {
+                    /* Call handler function if present */
+                    if (handler)
+                        rc = handler(gc, l1, sstate);
                 } else {
-                    /* State is not "disconnected", continue waiting... */
+                    /* State is different than expected, continue waiting... */
                     goto start;
                 }
                 free(l1);
@@ -418,6 +417,23 @@ start:
 }
 
 /*
+ * Handler function for device destruction to be passed to
+ * libxl__wait_for_device_state
+ */
+static int destroy_device(libxl__gc *gc, char **l1, char *state)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    xs_unwatch(ctx->xsh, l1[0], l1[1]);
+    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Destroyed device backend at %s",
+               l1[XS_WATCH_TOKEN]);
+
+    return 0;
+}
+
+/*
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
@@ -458,7 +474,7 @@ retry_transaction:
         struct timeval tv;
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
-        rc = wait_for_dev_destroy(gc, &tv);
+        rc = libxl__wait_for_device_state(gc, &tv, 6, destroy_device);
         if (rc < 0) /* an error or timeout occurred, clear watches */
             xs_unwatch(ctx->xsh, state_path, be_path);
         xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
@@ -566,7 +582,7 @@ int libxl__devices_destroy(libxl__gc *gc
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
         while (n_watches > 0) {
-            if (wait_for_dev_destroy(gc, &tv) < 0) {
+            if (libxl__wait_for_device_state(gc, &tv, 6, destroy_device) < 0) {
                 /* function returned ERROR_* */
                 break;
             } else {
diff -r ec94a7e4983a -r a77bba371740 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Nov 18 10:46:54 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Nov 18 10:49:00 2011 +0100
@@ -20,6 +20,7 @@
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <sys/time.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -252,6 +253,31 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/* Handler for the libxl__wait_for_device_state callback */
+/*
+ * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
+ * gc: allocation pool
+ * l1: array containing the path and token
+ * state: string that contains the state of the device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
+
+/*
+ * libxl__wait_for_device_state - waits a given time for a device to
+ * reach a given state
+ * gc: allocation pool
+ * tv: timeval struct containing the maximum time to wait
+ * state: state to wait for
+ * handler: callback function to execute when state is reached
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                         int state,
+                                         libxl__device_state_handler handler);
+
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
  * type of file using the PHY backend

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:07:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:07:43 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNEN-0003Tp-O4
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:07:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNE3-0005bC-1k; Fri, 18 Nov 2011 04:07:23 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7C-0004g8-0g
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:20 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!5
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12010 invoked from network); 18 Nov 2011 11:59:43 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:43 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=ys1SGhelUQhwBEeNyNN1MlILIG5JkZGn5gj4EJgsv6Y=;
	b=LNCc2Du+6cougpyUnABuul+jAiQt0Q7e18ZqA6WaDvptjTOINqtCRe3qEBwN88Alk9
	avLvW8JvvBspk+RUAI30xWKElp2QSKxseMAey4WORGFNvIJkvolvHqYSUW6WpXlpNRC7
	8kUXH//HQ9u59J7AXzZr1Q1a6u9V3g7rUdyac=
Received: by 10.14.16.37 with SMTP id g37mr239471eeg.43.1321617615012;
	Fri, 18 Nov 2011 04:00:15 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:13 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: a77bba3717402fdf24a72d028ae0f3d482e6f427
Message-Id: <a77bba3717402fdf24a7.1321617580@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:40 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 9 v2] libxl: introduce
	libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1321609740 -3600
# Node ID a77bba3717402fdf24a72d028ae0f3d482e6f427
# Parent  ec94a7e4983ad6338db20fa0777a85507b582607
libxl: introduce libxl__wait_for_device_state

This is a generic function, that waits for xs watches to reach a
certain state and then executes the passed helper function. Removed
wait_for_dev_destroy and used this new function instead. This
function will also be used by future patches that need to wait for
the initialization of devices before executing hotplug scripts.

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

diff -r ec94a7e4983a -r a77bba371740 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Nov 18 10:46:54 2011 +0100
+++ b/tools/libxl/libxl_device.c	Fri Nov 18 10:49:00 2011 +0100
@@ -370,7 +370,9 @@ int libxl__device_disk_dev_number(const 
  * Returns 0 if a device is removed, ERROR_* if an error
  * or timeout occurred.
  */
-static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
+int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                 int state,
+                                 libxl__device_state_handler handler)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int nfds, rc;
@@ -395,17 +397,14 @@ start:
         default:
             l1 = xs_read_watch(ctx->xsh, &n);
             if (l1 != NULL) {
-                char *state = libxl__xs_read(gc, XBT_NULL,
+                char *sstate = libxl__xs_read(gc, XBT_NULL,
                                              l1[XS_WATCH_PATH]);
-                if (!state || atoi(state) == 6) {
-                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
-                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
-                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                               "Destroyed device backend at %s",
-                               l1[XS_WATCH_TOKEN]);
-                    rc = 0;
+                if (!sstate || atoi(sstate) == state) {
+                    /* Call handler function if present */
+                    if (handler)
+                        rc = handler(gc, l1, sstate);
                 } else {
-                    /* State is not "disconnected", continue waiting... */
+                    /* State is different than expected, continue waiting... */
                     goto start;
                 }
                 free(l1);
@@ -418,6 +417,23 @@ start:
 }
 
 /*
+ * Handler function for device destruction to be passed to
+ * libxl__wait_for_device_state
+ */
+static int destroy_device(libxl__gc *gc, char **l1, char *state)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+
+    xs_unwatch(ctx->xsh, l1[0], l1[1]);
+    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Destroyed device backend at %s",
+               l1[XS_WATCH_TOKEN]);
+
+    return 0;
+}
+
+/*
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
@@ -458,7 +474,7 @@ retry_transaction:
         struct timeval tv;
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
-        rc = wait_for_dev_destroy(gc, &tv);
+        rc = libxl__wait_for_device_state(gc, &tv, 6, destroy_device);
         if (rc < 0) /* an error or timeout occurred, clear watches */
             xs_unwatch(ctx->xsh, state_path, be_path);
         xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
@@ -566,7 +582,7 @@ int libxl__devices_destroy(libxl__gc *gc
         tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
         tv.tv_usec = 0;
         while (n_watches > 0) {
-            if (wait_for_dev_destroy(gc, &tv) < 0) {
+            if (libxl__wait_for_device_state(gc, &tv, 6, destroy_device) < 0) {
                 /* function returned ERROR_* */
                 break;
             } else {
diff -r ec94a7e4983a -r a77bba371740 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Nov 18 10:46:54 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Nov 18 10:49:00 2011 +0100
@@ -20,6 +20,7 @@
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <sys/time.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -252,6 +253,31 @@ _hidden int libxl__device_destroy(libxl_
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
+/* Handler for the libxl__wait_for_device_state callback */
+/*
+ * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
+ * gc: allocation pool
+ * l1: array containing the path and token
+ * state: string that contains the state of the device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
+
+/*
+ * libxl__wait_for_device_state - waits a given time for a device to
+ * reach a given state
+ * gc: allocation pool
+ * tv: timeval struct containing the maximum time to wait
+ * state: state to wait for
+ * handler: callback function to execute when state is reached
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
+                                         int state,
+                                         libxl__device_state_handler handler);
+
 /*
  * libxl__try_phy_backend - Check if there's support for the passed
  * type of file using the PHY backend

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:08:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:08:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNET-0003U7-Su; Fri, 18 Nov 2011 12:07:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRNES-0003U2-He
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 12:07:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321618025!45133200!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30453 invoked from network); 18 Nov 2011 12:07:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 12:07:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9008296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 12:07:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 12:07:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RRNE9-0004uY-Cr	for xen-devel@lists.xensource.com;
	Fri, 18 Nov 2011 12:07:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RRNE9-0005V6-Bz	for
	xen-devel@lists.xensource.com; Fri, 18 Nov 2011 12:07:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20166.19073.131745.307079@mariner.uk.xensource.com>
Date: Fri, 18 Nov 2011 12:07:29 +0000
To: xen-devel@lists.xensource.com
In-Reply-To: <20166.17762.629323.709358@mariner.uk.xensource.com>
References: <20157.22344.959076.649413@mariner.uk.xensource.com>
	<20166.17762.629323.709358@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] xenbits downtime
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: xenbits downtime"):
> Ian Jackson writes ("xenbits downtime"):
> > As part of this we will be moving xenbits.xen.org aka
> > xenbits.xensource.com to new hosting.  The visible effect should be
> > that it will be down for an hour or so, hopefully on Monday afternoon
> > UK time.  I'll post a more specific announcement when I take the old
> > service down and when I bring the new one up.
> 
> This was a bit delayed but is about to happen now.  I'll post again
> in a bit.

It is up on the infrastructure again now.  I think I have transferred
across everything relevant, including user accounts, home directories,
cron jobs, etc. etc. etc.

Please let me know if you spot anything wrong.

Ian.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:08:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:08:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNET-0003U7-Su; Fri, 18 Nov 2011 12:07:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRNES-0003U2-He
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 12:07:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321618025!45133200!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30453 invoked from network); 18 Nov 2011 12:07:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 12:07:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9008296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 12:07:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 12:07:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RRNE9-0004uY-Cr	for xen-devel@lists.xensource.com;
	Fri, 18 Nov 2011 12:07:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RRNE9-0005V6-Bz	for
	xen-devel@lists.xensource.com; Fri, 18 Nov 2011 12:07:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20166.19073.131745.307079@mariner.uk.xensource.com>
Date: Fri, 18 Nov 2011 12:07:29 +0000
To: xen-devel@lists.xensource.com
In-Reply-To: <20166.17762.629323.709358@mariner.uk.xensource.com>
References: <20157.22344.959076.649413@mariner.uk.xensource.com>
	<20166.17762.629323.709358@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] xenbits downtime
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: xenbits downtime"):
> Ian Jackson writes ("xenbits downtime"):
> > As part of this we will be moving xenbits.xen.org aka
> > xenbits.xensource.com to new hosting.  The visible effect should be
> > that it will be down for an hour or so, hopefully on Monday afternoon
> > UK time.  I'll post a more specific announcement when I take the old
> > service down and when I bring the new one up.
> 
> This was a bit delayed but is about to happen now.  I'll post again
> in a bit.

It is up on the infrastructure again now.  I think I have transferred
across everything relevant, including user accounts, home directories,
cron jobs, etc. etc. etc.

Please let me know if you spot anything wrong.

Ian.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:09:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:09:07 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNFi-0003WR-VD
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:09:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNFP-0005yu-FX; Fri, 18 Nov 2011 04:08:47 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN76-0004fz-56
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:18 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!2
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11730 invoked from network); 18 Nov 2011 11:59:37 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:37 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=rIJw/yUbhXlo/6JNP9moJYJGk170Fpw5iLZGW2u7Ga8=;
	b=J6ENvvlT1uA9bqXn7kWvNd0RNXMccYyEtZ2dE2y1JQrGvK/ZctPw07kpanDAkFn6Qc
	tr/MjSf9Il3v3ZaDufWs+gt1n3IDjBziwKHjVC92OZDO8pc+ugm2BIsN4HDU93+3aK7q
	7Vil51gbOrk/r/RLYUdntG8+CuhMCuu2VuDl0=
Received: by 10.14.2.2 with SMTP id 2mr240619eee.123.1321617608886;
	Fri, 18 Nov 2011 04:00:08 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:07 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 23578c9942bcc8767adc4e435bb1fd1cd89f5e18
Message-Id: <23578c9942bcc8767adc.1321617577@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:37 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 9 v2] xenbackendd: pass type of block
 device to hotplug script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 23578c9942bcc8767adc4e435bb1fd1cd89f5e18
# Parent  fd3567cafe1c7ccd0ddba0ad7fb067d435e13529
xenbackendd: pass type of block device to hotplug script

Pass the type of block device to attach to the block script instead
of reading it from xenstore, since new Xen versions don't make a
difference between a block device or an image.

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

diff -r fd3567cafe1c -r 23578c9942bc tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Tue Nov 15 14:50:18 2011 +0100
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,7 +19,7 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
+xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
 case $xstatus in
diff -r fd3567cafe1c -r 23578c9942bc tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Tue Nov 15 14:50:18 2011 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -89,15 +89,15 @@ dodebug(const char *fmt, ...)
 }
 
 static void
-doexec(const char *cmd, const char *arg1, const char *arg2)
+doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3)
 {
-	dodebug("exec %s %s %s", cmd, arg1, arg2);
+	dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3);
 	switch(vfork()) {
 	case -1:
 		dolog(LOG_ERR, "can't vfork: %s", strerror(errno));
 		break;
 	case 0:
-		execl(cmd, cmd, arg1, arg2, NULL);
+		execl(cmd, cmd, arg1, arg2, arg3, NULL);
 		dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno));
 		exit(EXIT_FAILURE);
 		/* NOTREACHED */
@@ -145,11 +145,14 @@ xen_setup(void)
 int
 main(int argc, char * const argv[])
 {
+	struct stat stab;
 	char **vec;
 	unsigned int num;
 	char *s;
 	int state;
 	char *sstate;
+	char *stype;
+	char *params;
 	char *p;
 	char buf[80];
 	int type;
@@ -297,11 +300,38 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			doexec(s, vec[XS_WATCH_PATH], sstate, NULL);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			/* check if given file is a block device or a raw image */
+			snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]);
+			params = xs_read(xs, XBT_NULL, buf, 0);
+			if(params == NULL) {
+				dolog(LOG_ERR,
+					"Failed to read %s (%s)", buf, strerror(errno));
+				goto next2;
+			}
+			if (stat(params, &stab) < 0) {
+				dolog(LOG_ERR,
+					"Failed to get info about %s (%s)", params,
+					strerror(errno));
+				goto next3;
+			}
+			stype = NULL;
+			if (S_ISBLK(stab.st_mode))
+				stype = "phy";
+			if (S_ISREG(stab.st_mode))
+				stype = "file";
+			if (stype == NULL) {
+				dolog(LOG_ERR,
+					"Failed to attach %s (not a block device or raw image)",
+					params, strerror(errno));
+				goto next3;
+			}
+			doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype);
+next3:
+			free(params);
 			break;
 
 		default:

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:09:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:09:07 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNFi-0003WR-VD
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:09:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNFP-0005yu-FX; Fri, 18 Nov 2011 04:08:47 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN76-0004fz-56
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:18 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!2
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11730 invoked from network); 18 Nov 2011 11:59:37 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:37 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=rIJw/yUbhXlo/6JNP9moJYJGk170Fpw5iLZGW2u7Ga8=;
	b=J6ENvvlT1uA9bqXn7kWvNd0RNXMccYyEtZ2dE2y1JQrGvK/ZctPw07kpanDAkFn6Qc
	tr/MjSf9Il3v3ZaDufWs+gt1n3IDjBziwKHjVC92OZDO8pc+ugm2BIsN4HDU93+3aK7q
	7Vil51gbOrk/r/RLYUdntG8+CuhMCuu2VuDl0=
Received: by 10.14.2.2 with SMTP id 2mr240619eee.123.1321617608886;
	Fri, 18 Nov 2011 04:00:08 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:07 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 23578c9942bcc8767adc4e435bb1fd1cd89f5e18
Message-Id: <23578c9942bcc8767adc.1321617577@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:37 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 9 v2] xenbackendd: pass type of block
 device to hotplug script
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 23578c9942bcc8767adc4e435bb1fd1cd89f5e18
# Parent  fd3567cafe1c7ccd0ddba0ad7fb067d435e13529
xenbackendd: pass type of block device to hotplug script

Pass the type of block device to attach to the block script instead
of reading it from xenstore, since new Xen versions don't make a
difference between a block device or an image.

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

diff -r fd3567cafe1c -r 23578c9942bc tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Tue Nov 15 14:50:18 2011 +0100
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,7 +19,7 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
+xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
 case $xstatus in
diff -r fd3567cafe1c -r 23578c9942bc tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Tue Nov 15 14:50:18 2011 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -89,15 +89,15 @@ dodebug(const char *fmt, ...)
 }
 
 static void
-doexec(const char *cmd, const char *arg1, const char *arg2)
+doexec(const char *cmd, const char *arg1, const char *arg2, const char *arg3)
 {
-	dodebug("exec %s %s %s", cmd, arg1, arg2);
+	dodebug("exec %s %s %s %s", cmd, arg1, arg2, arg3);
 	switch(vfork()) {
 	case -1:
 		dolog(LOG_ERR, "can't vfork: %s", strerror(errno));
 		break;
 	case 0:
-		execl(cmd, cmd, arg1, arg2, NULL);
+		execl(cmd, cmd, arg1, arg2, arg3, NULL);
 		dolog(LOG_ERR, "can't exec %s: %s", cmd, strerror(errno));
 		exit(EXIT_FAILURE);
 		/* NOTREACHED */
@@ -145,11 +145,14 @@ xen_setup(void)
 int
 main(int argc, char * const argv[])
 {
+	struct stat stab;
 	char **vec;
 	unsigned int num;
 	char *s;
 	int state;
 	char *sstate;
+	char *stype;
+	char *params;
 	char *p;
 	char buf[80];
 	int type;
@@ -297,11 +300,38 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			doexec(s, vec[XS_WATCH_PATH], sstate, NULL);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			/* check if given file is a block device or a raw image */
+			snprintf(buf, sizeof(buf), "%s/params", vec[XS_WATCH_PATH]);
+			params = xs_read(xs, XBT_NULL, buf, 0);
+			if(params == NULL) {
+				dolog(LOG_ERR,
+					"Failed to read %s (%s)", buf, strerror(errno));
+				goto next2;
+			}
+			if (stat(params, &stab) < 0) {
+				dolog(LOG_ERR,
+					"Failed to get info about %s (%s)", params,
+					strerror(errno));
+				goto next3;
+			}
+			stype = NULL;
+			if (S_ISBLK(stab.st_mode))
+				stype = "phy";
+			if (S_ISREG(stab.st_mode))
+				stype = "file";
+			if (stype == NULL) {
+				dolog(LOG_ERR,
+					"Failed to attach %s (not a block device or raw image)",
+					params, strerror(errno));
+				goto next3;
+			}
+			doexec(vbd_script, vec[XS_WATCH_PATH], sstate, stype);
+next3:
+			free(params);
 			break;
 
 		default:

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:10:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:10:09 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNGj-0003YY-DT
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:10:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNGP-0006M0-MU; Fri, 18 Nov 2011 04:09:49 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7E-0004gB-0g
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:23 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!6
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12136 invoked from network); 18 Nov 2011 11:59:45 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:45 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=0sksXj/ub/oIt1pzpz5RlUksYolNxFKjW1fFeox7v64=;
	b=VKGky8cXM+sGAE8NYhTHiNTGMHUU8eq5QdbwBYU1jC8y7S1+QkA5i8U1fOrra3SXrg
	YQt5eXq0XB5wlAaMK8YgKI3/nQMCjhmQ7fCJe9DALLwxOONbqcq7+/AtEHBk3Hq5/16E
	jbONSP7BS93NZcQK+XKSPP6F8PvrqvIkkH/Js=
Received: by 10.14.5.140 with SMTP id 12mr222216eel.167.1321617617018;
	Fri, 18 Nov 2011 04:00:17 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:15 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 4ad998fddb16a299cb230ea23ba944d84adbd2bf
Message-Id: <4ad998fddb16a299cb23.1321617581@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:41 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 9 v2] libxl: wait for devices to initialize
 upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1321612154 -3600
# Node ID 4ad998fddb16a299cb230ea23ba944d84adbd2bf
# Parent  a77bba3717402fdf24a72d028ae0f3d482e6f427
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices to initialize (switch to state 2). This is
necessary because we need to call the hotplug scripts when state is
2, otherwise the execution fails. Make use of the newly introduced
function libxl__wait_for_device_state.

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

diff -r a77bba371740 -r 4ad998fddb16 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Nov 18 10:49:00 2011 +0100
+++ b/tools/libxl/libxl.c	Fri Nov 18 11:29:14 2011 +0100
@@ -971,6 +971,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     libxl__device device;
     int major, minor, rc;
 
@@ -1075,6 +1077,23 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != 2) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, 2, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize disk device: %s\n",
+                       disk->pdev_path);
+            goto out_free;
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1450,6 +1469,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     flexarray_t *back;
     libxl__device device;
     char *dompath, **l;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     unsigned int nb, rc;
 
     front = flexarray_make(16, 1);
@@ -1518,8 +1539,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != 2) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, 2, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s\n",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:10:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:10:09 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNGj-0003YY-DT
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:10:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNGP-0006M0-MU; Fri, 18 Nov 2011 04:09:49 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7E-0004gB-0g
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:23 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!6
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12136 invoked from network); 18 Nov 2011 11:59:45 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:45 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=0sksXj/ub/oIt1pzpz5RlUksYolNxFKjW1fFeox7v64=;
	b=VKGky8cXM+sGAE8NYhTHiNTGMHUU8eq5QdbwBYU1jC8y7S1+QkA5i8U1fOrra3SXrg
	YQt5eXq0XB5wlAaMK8YgKI3/nQMCjhmQ7fCJe9DALLwxOONbqcq7+/AtEHBk3Hq5/16E
	jbONSP7BS93NZcQK+XKSPP6F8PvrqvIkkH/Js=
Received: by 10.14.5.140 with SMTP id 12mr222216eel.167.1321617617018;
	Fri, 18 Nov 2011 04:00:17 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:15 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 4ad998fddb16a299cb230ea23ba944d84adbd2bf
Message-Id: <4ad998fddb16a299cb23.1321617581@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:41 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 9 v2] libxl: wait for devices to initialize
 upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1321612154 -3600
# Node ID 4ad998fddb16a299cb230ea23ba944d84adbd2bf
# Parent  a77bba3717402fdf24a72d028ae0f3d482e6f427
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices to initialize (switch to state 2). This is
necessary because we need to call the hotplug scripts when state is
2, otherwise the execution fails. Make use of the newly introduced
function libxl__wait_for_device_state.

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

diff -r a77bba371740 -r 4ad998fddb16 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Nov 18 10:49:00 2011 +0100
+++ b/tools/libxl/libxl.c	Fri Nov 18 11:29:14 2011 +0100
@@ -971,6 +971,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
     flexarray_t *front;
     flexarray_t *back;
     char *dev;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     libxl__device device;
     int major, minor, rc;
 
@@ -1075,6 +1077,23 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != 2) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, 2, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize disk device: %s\n",
+                       disk->pdev_path);
+            goto out_free;
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1450,6 +1469,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
     flexarray_t *back;
     libxl__device device;
     char *dompath, **l;
+    char *be_path, *state_path, *state;
+    struct timeval tv;
     unsigned int nb, rc;
 
     front = flexarray_make(16, 1);
@@ -1518,8 +1539,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(&gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(&gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(&gc, &device);
+    state_path = libxl__sprintf(&gc, "%s/state", be_path);
+    state = libxl__xs_read(&gc, XBT_NULL, state_path);
+
+    if (atoi(state) != 2) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(&gc, &tv, 2, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s\n",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:12:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:12:14 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNIk-0003cV-D3
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNIR-0006k2-Nb; Fri, 18 Nov 2011 04:11:55 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7A-0004g3-2F
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:19 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!4
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11926 invoked from network); 18 Nov 2011 11:59:41 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:41 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=mGpYHnv55oiwc62uXDM55xpwxUtjwda5mfwku+oeZZE=;
	b=vzOWSoHc+3JpdwMlStlNNb4DKC1LgaZNtBLezyNLm/F3qc61hZnGgduEJMBsR4cptW
	p0aJtmCqpoUbLqSGYQpu+Cf4Q2OjKnlSA8zYqjtr2q6hiLsLWpkKyo3Djk28riwMVHYy
	+XptvuqdxLoMhHiWq8nnwiXY/AGQroo+1rTc4=
Received: by 10.14.1.3 with SMTP id 3mr227740eec.179.1321617612980;
	Fri, 18 Nov 2011 04:00:12 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:11 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: ec94a7e4983ad6338db20fa0777a85507b582607
Message-Id: <ec94a7e4983ad6338db2.1321617579@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:39 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec function
	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1321609614 -3600
# Node ID ec94a7e4983ad6338db20fa0777a85507b582607
# Parent  9e8abd626484f82a95d0edc07834ae287bc9467a
libxl: add libxl__forkexec function to libxl_exec

Add a new function to libxl_exec that performs a fork and executes
the passed arguments using libxl__exec.

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

diff -r 9e8abd626484 -r ec94a7e4983a tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_exec.c	Fri Nov 18 10:46:54 2011 +0100
@@ -450,6 +450,40 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, char **args)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, args[0], args);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "waitpid failed\n");
+                rc = -1;
+                break;
+            }
+        }
+        if (WIFEXITED(status)) {
+            rc = WEXITSTATUS(status);
+        } else {
+            rc = -1;
+        }
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 9e8abd626484 -r ec94a7e4983a tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Nov 18 10:46:54 2011 +0100
@@ -400,6 +400,20 @@ _hidden int libxl__spawn_check(libxl__gc
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * gc: allocation pool
+ * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
+ * args: file to execute and arguments to pass in the following format
+ *      args[0]: file to execute
+ *      args[1]: first argument to pass to the called program
+ *      args[n]: nth argument to pass to the called program
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, char **args);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:12:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:12:14 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNIk-0003cV-D3
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNIR-0006k2-Nb; Fri, 18 Nov 2011 04:11:55 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7A-0004g3-2F
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:19 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!4
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11926 invoked from network); 18 Nov 2011 11:59:41 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:41 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=mGpYHnv55oiwc62uXDM55xpwxUtjwda5mfwku+oeZZE=;
	b=vzOWSoHc+3JpdwMlStlNNb4DKC1LgaZNtBLezyNLm/F3qc61hZnGgduEJMBsR4cptW
	p0aJtmCqpoUbLqSGYQpu+Cf4Q2OjKnlSA8zYqjtr2q6hiLsLWpkKyo3Djk28riwMVHYy
	+XptvuqdxLoMhHiWq8nnwiXY/AGQroo+1rTc4=
Received: by 10.14.1.3 with SMTP id 3mr227740eec.179.1321617612980;
	Fri, 18 Nov 2011 04:00:12 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:11 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: ec94a7e4983ad6338db20fa0777a85507b582607
Message-Id: <ec94a7e4983ad6338db2.1321617579@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:39 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec function
	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1321609614 -3600
# Node ID ec94a7e4983ad6338db20fa0777a85507b582607
# Parent  9e8abd626484f82a95d0edc07834ae287bc9467a
libxl: add libxl__forkexec function to libxl_exec

Add a new function to libxl_exec that performs a fork and executes
the passed arguments using libxl__exec.

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

diff -r 9e8abd626484 -r ec94a7e4983a tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_exec.c	Fri Nov 18 10:46:54 2011 +0100
@@ -450,6 +450,40 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, char **args)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, args[0], args);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "waitpid failed\n");
+                rc = -1;
+                break;
+            }
+        }
+        if (WIFEXITED(status)) {
+            rc = WEXITSTATUS(status);
+        } else {
+            rc = -1;
+        }
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 9e8abd626484 -r ec94a7e4983a tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_internal.h	Fri Nov 18 10:46:54 2011 +0100
@@ -400,6 +400,20 @@ _hidden int libxl__spawn_check(libxl__gc
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * gc: allocation pool
+ * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
+ * args: file to execute and arguments to pass in the following format
+ *      args[0]: file to execute
+ *      args[1]: first argument to pass to the called program
+ *      args[n]: nth argument to pass to the called program
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, char **args);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:13:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:13:46 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNKE-0003dR-6A
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:13:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNJu-00079b-B3; Fri, 18 Nov 2011 04:13:26 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7I-0004gZ-2R
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:26 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!8
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12405 invoked from network); 18 Nov 2011 11:59:49 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:49 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=hia/uE5Q8wyk2e4SImGYrk1Vs/KW3JTrs3m2Jz79UqQ=;
	b=m3cTFXX63jAT/IkJ2T3xqpGqNGF7tK5aRvc6KXl2FkcK5N0cFHIXWAkjhtBOCA2PaV
	sd753NjT5xN+qPdd7XrXXm+VTwGjhwWT/9Oav3zICvM2K5fn4QTjRzs2+FDBdnDxhSLl
	ecMqRoy5W+PJ+ZBpH/7pv8vg8tFOQn3S17S90=
Received: by 10.213.34.202 with SMTP id m10mr1030957ebd.1.1321617621085;
	Fri, 18 Nov 2011 04:00:21 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:20 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: f46cb13d1ee576ed2c98d392356f380f205b587d
Message-Id: <f46cb13d1ee576ed2c98.1321617583@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:43 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 7 of 9 v2] hotplug NetBSD: detach devices when
	state is 5 or 6
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID f46cb13d1ee576ed2c98d392356f380f205b587d
# Parent  1d81d1c4c851c0b07696373304801df56a221e90
hotplug NetBSD: detach devices when state is 5 or 6

With the move of hotplug calls from xenbackendd to libxl, we can
detach devices when the state is 5 or 6.

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

diff -r 1d81d1c4c851 -r f46cb13d1ee5 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -23,7 +23,7 @@ xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
 case $xstatus in
-6)
+5|6)
 	# device removed
 	case $xtype in
 	file)
diff -r 1d81d1c4c851 -r f46cb13d1ee5 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
@@ -14,7 +14,7 @@ xpath=$1
 xstatus=$2
 
 case $xstatus in
-6)
+5|6)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
diff -r 1d81d1c4c851 -r f46cb13d1ee5 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
@@ -14,7 +14,7 @@ xpath=$1
 xstatus=$2
 
 case $xstatus in
-6)
+5|6)
 	# device removed
 	xenstore-rm $xpath
 	exit 0

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:13:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:13:46 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNKE-0003dR-6A
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:13:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNJu-00079b-B3; Fri, 18 Nov 2011 04:13:26 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7I-0004gZ-2R
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:26 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!8
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12405 invoked from network); 18 Nov 2011 11:59:49 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:49 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=hia/uE5Q8wyk2e4SImGYrk1Vs/KW3JTrs3m2Jz79UqQ=;
	b=m3cTFXX63jAT/IkJ2T3xqpGqNGF7tK5aRvc6KXl2FkcK5N0cFHIXWAkjhtBOCA2PaV
	sd753NjT5xN+qPdd7XrXXm+VTwGjhwWT/9Oav3zICvM2K5fn4QTjRzs2+FDBdnDxhSLl
	ecMqRoy5W+PJ+ZBpH/7pv8vg8tFOQn3S17S90=
Received: by 10.213.34.202 with SMTP id m10mr1030957ebd.1.1321617621085;
	Fri, 18 Nov 2011 04:00:21 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:20 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: f46cb13d1ee576ed2c98d392356f380f205b587d
Message-Id: <f46cb13d1ee576ed2c98.1321617583@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:43 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 7 of 9 v2] hotplug NetBSD: detach devices when
	state is 5 or 6
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID f46cb13d1ee576ed2c98d392356f380f205b587d
# Parent  1d81d1c4c851c0b07696373304801df56a221e90
hotplug NetBSD: detach devices when state is 5 or 6

With the move of hotplug calls from xenbackendd to libxl, we can
detach devices when the state is 5 or 6.

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

diff -r 1d81d1c4c851 -r f46cb13d1ee5 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -23,7 +23,7 @@ xtype=$3
 xparams=$(xenstore-read "$xpath/params")
 
 case $xstatus in
-6)
+5|6)
 	# device removed
 	case $xtype in
 	file)
diff -r 1d81d1c4c851 -r f46cb13d1ee5 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
@@ -14,7 +14,7 @@ xpath=$1
 xstatus=$2
 
 case $xstatus in
-6)
+5|6)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
diff -r 1d81d1c4c851 -r f46cb13d1ee5 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
@@ -14,7 +14,7 @@ xpath=$1
 xstatus=$2
 
 case $xstatus in
-6)
+5|6)
 	# device removed
 	xenstore-rm $xpath
 	exit 0

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:14:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:14:57 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNLN-0003eZ-J8
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:14:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNL4-0007Wg-JP; Fri, 18 Nov 2011 04:14:38 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7H-0004gI-3J
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:25 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!7
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12310 invoked from network); 18 Nov 2011 11:59:48 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:48 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=XVUNqzfbqQnCQJN9DQy9UhLEPwVnTUqiLpZGh3O/13g=;
	b=tVrNd80KHNtm1/dM5VDinGViGNq8s83R3zNbZ0YzVp/gX0TmedDeieyVlMrtXy7A+0
	6rTibbi9j2NcmnBE4DvNACOY182oos/R3qgWmrxvLEPJ40tvHNdto8m2+i0jWocCdWsy
	yoahyKBbXPHqVws3sRfJSKdBDNsvcYuA2rDuI=
Received: by 10.213.105.66 with SMTP id s2mr577591ebo.41.1321617619147;
	Fri, 18 Nov 2011 04:00:19 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:18 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 1d81d1c4c851c0b07696373304801df56a221e90
Message-Id: <1d81d1c4c851c0b07696.1321617582@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:42 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
	directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 1d81d1c4c851c0b07696373304801df56a221e90
# Parent  4ad998fddb16a299cb230ea23ba944d84adbd2bf
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. Linux
has empty functions, since the calling of hotplug scripts is still
done using udev.

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

diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Nov 18 11:29:14 2011 +0100
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -34,8 +34,10 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_phybackend.o
+LIBXL_OBJS-y += hotplug_netbsd.o
 else
 LIBXL_OBJS-y += libxl_nophybackend.o
+LIBXL_OBJS-y += hotplug_linux.o
 endif
 
 LIBXL_LIBS += -lyajl
diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/hotplug_linux.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/hotplug_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_internal.h"
+
+int libxl_disk_hotplug(libxl__gc *gc, libxl__device *dev)
+{
+    return 0;
+}
+
+int libxl_nic_hotplug_connect(libxl__gc *gc, libxl__device *dev)
+{
+    return 0;
+}
diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/hotplug_netbsd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/hotplug_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,129 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include <sys/stat.h>
+
+#include "libxl_internal.h"
+
+int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    struct stat stab;
+    char *stype, *sstate, *script, *params;
+    char **args;
+    int nr = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                   be_path);
+        return -1;
+    }
+
+    params = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "params"));
+    if (!params)
+        return -1;
+
+    sstate = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                   be_path);
+        return -1;
+    }
+
+    if (stat(params, &stab) < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to get stat info\n");
+        return -1;
+    }
+    if (S_ISBLK(stab.st_mode))
+        stype = "phy";
+    if (S_ISREG(stab.st_mode))
+        stype = "file";
+    if (stype == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Not block or regular file");
+        return -1;
+    }
+
+    f_args = flexarray_make(5, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, sstate);
+    flexarray_set(f_args, nr++, stype);
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling disk hotplug script: %s %s %s %s",
+               args[0], args[1], args[2], args[3]);
+    if (libxl__forkexec(gc, -1, -1, -1, args) < 0) {
+        free(args);
+        return -1;
+    }
+
+    free(args);
+    return 0;
+}
+
+int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *sstate, *script;
+    char **args;
+    int nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                   be_path);
+        return -1;
+    }
+
+    sstate = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                   be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, sstate);
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling nic hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    if (libxl__forkexec(gc, -1, -1, -1, args) < 0) {
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}
diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Nov 18 11:29:14 2011 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1018,6 +1018,11 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(&gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1094,6 +1099,15 @@ int libxl_device_disk_add(libxl_ctx *ctx
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for disk: %s\n",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1556,6 +1570,15 @@ int libxl_device_nic_add(libxl_ctx *ctx,
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for nic: %s\n",
+                   nic->ifname);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Nov 18 11:29:14 2011 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -68,6 +68,24 @@ int libxl__parse_backend_path(libxl__gc 
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev)
+{
+    int rc = 0;
+
+    switch(dev->kind) {
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__nic_hotplug(gc, dev);
+        break;
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__disk_hotplug(gc, dev);
+        break;
+    default:
+        break;
+    }
+
+    return rc;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
@@ -449,6 +467,7 @@ int libxl__device_remove(libxl__gc *gc, 
     if (!state)
         goto out;
     if (atoi(state) != 4) {
+        libxl__device_execute_hotplug(gc, dev);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
@@ -492,6 +511,12 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
+    /* 
+     * Run hotplug scripts, which will probably not be able to
+     * execute successfully since the device may still be plugged
+     */
+    libxl__device_execute_hotplug(gc, dev);
+
     xs_rm(ctx->xsh, XBT_NULL, be_path);
     xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Nov 18 11:29:14 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -287,6 +287,34 @@ _hidden int libxl__wait_for_device_state
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+/* hotplug functions */
+/*
+ * libxl__device_execute_hotplug - generic function to execute hotplug scripts
+ * gc: allocation pool
+ * dev: reference to the device that executes the hotplug scripts
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev);
+
+/*
+ * libxl__disk_hotplug - execute hotplug script for a disk type device
+ * gc: allocation pool
+ * dev: reference to the disk device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev);
+
+/*
+ * libxl__nic_hotplug - execute hotplug script for a nic type device
+ * gc: allocation pool
+ * dev: reference to the nic device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:14:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:14:57 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNLN-0003eZ-J8
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:14:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNL4-0007Wg-JP; Fri, 18 Nov 2011 04:14:38 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7H-0004gI-3J
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:25 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!7
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12310 invoked from network); 18 Nov 2011 11:59:48 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:48 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=XVUNqzfbqQnCQJN9DQy9UhLEPwVnTUqiLpZGh3O/13g=;
	b=tVrNd80KHNtm1/dM5VDinGViGNq8s83R3zNbZ0YzVp/gX0TmedDeieyVlMrtXy7A+0
	6rTibbi9j2NcmnBE4DvNACOY182oos/R3qgWmrxvLEPJ40tvHNdto8m2+i0jWocCdWsy
	yoahyKBbXPHqVws3sRfJSKdBDNsvcYuA2rDuI=
Received: by 10.213.105.66 with SMTP id s2mr577591ebo.41.1321617619147;
	Fri, 18 Nov 2011 04:00:19 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:18 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 1d81d1c4c851c0b07696373304801df56a221e90
Message-Id: <1d81d1c4c851c0b07696.1321617582@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:42 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
	directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 1d81d1c4c851c0b07696373304801df56a221e90
# Parent  4ad998fddb16a299cb230ea23ba944d84adbd2bf
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. Linux
has empty functions, since the calling of hotplug scripts is still
done using udev.

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

diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Nov 18 11:29:14 2011 +0100
+++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
@@ -34,8 +34,10 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_phybackend.o
+LIBXL_OBJS-y += hotplug_netbsd.o
 else
 LIBXL_OBJS-y += libxl_nophybackend.o
+LIBXL_OBJS-y += hotplug_linux.o
 endif
 
 LIBXL_LIBS += -lyajl
diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/hotplug_linux.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/hotplug_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_internal.h"
+
+int libxl_disk_hotplug(libxl__gc *gc, libxl__device *dev)
+{
+    return 0;
+}
+
+int libxl_nic_hotplug_connect(libxl__gc *gc, libxl__device *dev)
+{
+    return 0;
+}
diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/hotplug_netbsd.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/libxl/hotplug_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,129 @@
+/*
+ * Copyright (C) 2011
+ * Author Roger Pau Monne <roger.pau@entel.upc.edu>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include <sys/stat.h>
+
+#include "libxl_internal.h"
+
+int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    struct stat stab;
+    char *stype, *sstate, *script, *params;
+    char **args;
+    int nr = 0;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                   be_path);
+        return -1;
+    }
+
+    params = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "params"));
+    if (!params)
+        return -1;
+
+    sstate = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                   be_path);
+        return -1;
+    }
+
+    if (stat(params, &stab) < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "failed to get stat info\n");
+        return -1;
+    }
+    if (S_ISBLK(stab.st_mode))
+        stype = "phy";
+    if (S_ISREG(stab.st_mode))
+        stype = "file";
+    if (stype == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Not block or regular file");
+        return -1;
+    }
+
+    f_args = flexarray_make(5, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, sstate);
+    flexarray_set(f_args, nr++, stype);
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling disk hotplug script: %s %s %s %s",
+               args[0], args[1], args[2], args[3]);
+    if (libxl__forkexec(gc, -1, -1, -1, args) < 0) {
+        free(args);
+        return -1;
+    }
+
+    free(args);
+    return 0;
+}
+
+int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *sstate, *script;
+    char **args;
+    int nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                   be_path);
+        return -1;
+    }
+
+    sstate = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", be_path, "state"));
+    if (!sstate) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read state from %s",
+                   be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, sstate);
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Calling nic hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    if (libxl__forkexec(gc, -1, -1, -1, args) < 0) {
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
+}
diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Nov 18 11:29:14 2011 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1018,6 +1018,11 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, "params");
             flexarray_append(back, dev);
 
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(&gc, "%s/%s",
+                                                  libxl_xen_script_dir_path(),
+                                                  "block"));
+
             assert(device.backend_kind == LIBXL__DEVICE_KIND_VBD);
             break;
         case LIBXL_DISK_BACKEND_TAP:
@@ -1094,6 +1099,15 @@ int libxl_device_disk_add(libxl_ctx *ctx
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for disk: %s\n",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1556,6 +1570,15 @@ int libxl_device_nic_add(libxl_ctx *ctx,
             goto out_free;
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_execute_hotplug(&gc, &device) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to execute hotplug script for nic: %s\n",
+                   nic->ifname);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Nov 18 11:29:14 2011 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -68,6 +68,24 @@ int libxl__parse_backend_path(libxl__gc 
     return libxl__device_kind_from_string(strkind, &dev->backend_kind);
 }
 
+int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev)
+{
+    int rc = 0;
+
+    switch(dev->kind) {
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__nic_hotplug(gc, dev);
+        break;
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__disk_hotplug(gc, dev);
+        break;
+    default:
+        break;
+    }
+
+    return rc;
+}
+
 int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
                              char **bents, char **fents)
 {
@@ -449,6 +467,7 @@ int libxl__device_remove(libxl__gc *gc, 
     if (!state)
         goto out;
     if (atoi(state) != 4) {
+        libxl__device_execute_hotplug(gc, dev);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
@@ -492,6 +511,12 @@ int libxl__device_destroy(libxl__gc *gc,
     char *be_path = libxl__device_backend_path(gc, dev);
     char *fe_path = libxl__device_frontend_path(gc, dev);
 
+    /* 
+     * Run hotplug scripts, which will probably not be able to
+     * execute successfully since the device may still be plugged
+     */
+    libxl__device_execute_hotplug(gc, dev);
+
     xs_rm(ctx->xsh, XBT_NULL, be_path);
     xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Nov 18 11:29:14 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -287,6 +287,34 @@ _hidden int libxl__wait_for_device_state
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+/* hotplug functions */
+/*
+ * libxl__device_execute_hotplug - generic function to execute hotplug scripts
+ * gc: allocation pool
+ * dev: reference to the device that executes the hotplug scripts
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev);
+
+/*
+ * libxl__disk_hotplug - execute hotplug script for a disk type device
+ * gc: allocation pool
+ * dev: reference to the disk device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev);
+
+/*
+ * libxl__nic_hotplug - execute hotplug script for a nic type device
+ * gc: allocation pool
+ * dev: reference to the nic device
+ *
+ * Returns 0 on success, and < 0 on error.
+ */
+_hidden int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev);
+
 /* from libxl_pci */
 
 _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:16:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:16:04 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNMS-0003fM-3K
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNM9-0007tN-Fb; Fri, 18 Nov 2011 04:15:45 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7K-0004ga-4e
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:30 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!9
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12594 invoked from network); 18 Nov 2011 11:59:51 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:51 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=aaY27nJqHseF2pe92tn8iqiFQmbsBMoQKAYBVVmgOso=;
	b=Et9uMSNA30MH5d3u0Q895CXbbthEhrmR7qVPx4wSYoV5/YSXmJiGB9SvS/0xsGQ/xw
	XBKYya504pE11m27WbJpPbU0rqoFtA2i5gB7A7Y9Pi5bS0Libwt8LYv0iwz5ZqloIVha
	tXMXjZV7eHvACeDJWHkid2nmRx6dsd7zMQ5UM=
Received: by 10.213.26.195 with SMTP id f3mr916833ebc.122.1321617623144;
	Fri, 18 Nov 2011 04:00:23 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:22 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: d1591841fe963f054cd6b27d6d87ac005cfff29a
Message-Id: <d1591841fe963f054cd6.1321617584@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:44 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 8 of 9 v2] hotplug: remove debug messages from
 NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1321612158 -3600
# Node ID d1591841fe963f054cd6b27d6d87ac005cfff29a
# Parent  f46cb13d1ee576ed2c98d392356f380f205b587d
hotplug: remove debug messages from NetBSD hotplug scripts

Remove unecessary debug messages from NetBSD hotplug scripts, left
error messages only.

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

diff -r f46cb13d1ee5 -r d1591841fe96 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Fri Nov 18 11:29:18 2011 +0100
@@ -64,14 +64,12 @@ 2)
 			if [ "$status" = "free" ] && \
 			    vnconfig /dev/${disk}d $xparams >/dev/null; then
 				device=/dev/${disk}d
-				echo vnconfig /dev/${disk}d $xparams
 				break	
 			fi
 		done
 		if [ x$device = x ] ; then
 			error "no available vnd device"
 		fi
-		echo xenstore-write $xpath/vnd $device
 		xenstore-write $xpath/vnd $device
 		;;
 	phy)
@@ -79,9 +77,7 @@ 2)
 		;;
 	esac
 	physical_device=$(stat -f '%r' "$device")
-	echo xenstore-write $xpath/physical-device $physical_device
 	xenstore-write $xpath/physical-device $physical_device
-	echo xenstore-write $xpath/hotplug-status connected
 	xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
diff -r f46cb13d1ee5 -r d1591841fe96 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Fri Nov 18 11:29:18 2011 +0100
@@ -24,12 +24,9 @@ 2)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface up
 	ifconfig $iface up
 	brconfig $xbridge add $iface
-	echo brconfig $xbridge add $iface
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)
diff -r f46cb13d1ee5 -r d1591841fe96 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Fri Nov 18 11:29:18 2011 +0100
@@ -24,10 +24,8 @@ 2)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface $xip up
 	ifconfig $iface $xip up
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:16:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:16:04 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNMS-0003fM-3K
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:16:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNM9-0007tN-Fb; Fri, 18 Nov 2011 04:15:45 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7K-0004ga-4e
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:30 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!9
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12594 invoked from network); 18 Nov 2011 11:59:51 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:51 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=aaY27nJqHseF2pe92tn8iqiFQmbsBMoQKAYBVVmgOso=;
	b=Et9uMSNA30MH5d3u0Q895CXbbthEhrmR7qVPx4wSYoV5/YSXmJiGB9SvS/0xsGQ/xw
	XBKYya504pE11m27WbJpPbU0rqoFtA2i5gB7A7Y9Pi5bS0Libwt8LYv0iwz5ZqloIVha
	tXMXjZV7eHvACeDJWHkid2nmRx6dsd7zMQ5UM=
Received: by 10.213.26.195 with SMTP id f3mr916833ebc.122.1321617623144;
	Fri, 18 Nov 2011 04:00:23 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:22 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: d1591841fe963f054cd6b27d6d87ac005cfff29a
Message-Id: <d1591841fe963f054cd6.1321617584@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:44 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 8 of 9 v2] hotplug: remove debug messages from
 NetBSD hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1321612158 -3600
# Node ID d1591841fe963f054cd6b27d6d87ac005cfff29a
# Parent  f46cb13d1ee576ed2c98d392356f380f205b587d
hotplug: remove debug messages from NetBSD hotplug scripts

Remove unecessary debug messages from NetBSD hotplug scripts, left
error messages only.

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

diff -r f46cb13d1ee5 -r d1591841fe96 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/block	Fri Nov 18 11:29:18 2011 +0100
@@ -64,14 +64,12 @@ 2)
 			if [ "$status" = "free" ] && \
 			    vnconfig /dev/${disk}d $xparams >/dev/null; then
 				device=/dev/${disk}d
-				echo vnconfig /dev/${disk}d $xparams
 				break	
 			fi
 		done
 		if [ x$device = x ] ; then
 			error "no available vnd device"
 		fi
-		echo xenstore-write $xpath/vnd $device
 		xenstore-write $xpath/vnd $device
 		;;
 	phy)
@@ -79,9 +77,7 @@ 2)
 		;;
 	esac
 	physical_device=$(stat -f '%r' "$device")
-	echo xenstore-write $xpath/physical-device $physical_device
 	xenstore-write $xpath/physical-device $physical_device
-	echo xenstore-write $xpath/hotplug-status connected
 	xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
diff -r f46cb13d1ee5 -r d1591841fe96 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-bridge	Fri Nov 18 11:29:18 2011 +0100
@@ -24,12 +24,9 @@ 2)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface up
 	ifconfig $iface up
 	brconfig $xbridge add $iface
-	echo brconfig $xbridge add $iface
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)
diff -r f46cb13d1ee5 -r d1591841fe96 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/hotplug/NetBSD/vif-ip	Fri Nov 18 11:29:18 2011 +0100
@@ -24,10 +24,8 @@ 2)
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
 	iface=$(xenstore-read "$xpath/vifname")
-	echo ifconfig $iface $xip up
 	ifconfig $iface $xip up
 	xenstore-write $xpath/hotplug-status connected
-	echo xenstore-write $xpath/hotplug-status connected
 	exit 0
 	;;
 *)

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:16:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:16:52 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNNE-0003gH-CV
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:16:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNMu-0008Fz-To; Fri, 18 Nov 2011 04:16:33 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7M-0004gf-Bc
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:32 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!10
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12737 invoked from network); 18 Nov 2011 11:59:53 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:53 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=VhELDb2+slHZ8Cqtdz2qwXJCaODZIzFRsl0DJ7RM2B0=;
	b=oBP1ktkhQ5Rfxe2UtbNckKxP8dCLPGMZmlAL2T5J99AFN5IChh+fIkdIG+bfhV1L7o
	8GZRHuAsrt8IryHSbjsDlPHAujRkMXX3deLVNKrqbTSpLoLyGKDt0cpjb0od/6rC7gtr
	7Gvajf2Q5DtPv+i8qHq3ya1G9vZGzY2T0K/Eg=
Received: by 10.14.5.206 with SMTP id 54mr179195eel.191.1321617625119;
	Fri, 18 Nov 2011 04:00:25 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:24 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 8c77fe3008a486de7062d37053dcd0dbdc92ee0a
Message-Id: <8c77fe3008a486de7062.1321617585@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:45 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 9 of 9 v2] rc.d NetBSD: don't start xenbackendd
 by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 8c77fe3008a486de7062d37053dcd0dbdc92ee0a
# Parent  d1591841fe963f054cd6b27d6d87ac005cfff29a
rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.

With the move of hotplug scripts from xenbackendd to libxl
xenbackendd is no longer needed by libxl, only start it when xend is
started.

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

diff -r d1591841fe96 -r 8c77fe3008a4 tools/hotplug/NetBSD/rc.d/xenbackendd
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/hotplug/NetBSD/rc.d/xenbackendd	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# PROVIDE: xenbackendd
+# REQUIRE: xencommons
+
+. /etc/rc.subr
+
+DIR=$(dirname "$0")
+. "${DIR}/xen-hotplugpath.sh"
+
+LD_LIBRARY_PATH="${LIBDIR}"
+export LD_LIBRARY_PATH PYTHONPATH
+PATH="${PATH}:${SBINDIR}"
+export PATH
+
+name="xenbackendd"
+rcvar=$name
+command="${SBINDIR}/xenbackendd"
+if [ -n "${XENBACKENDD_DEBUG}" ]; then
+	command_args="${XENBACKENDD_ARGS} -d"
+else
+	command_args="${XENBACKENDD_ARGS}"
+fi
+
+load_rc_config $name
+run_rc_command "$1"
+
diff -r d1591841fe96 -r 8c77fe3008a4 tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Fri Nov 18 11:29:18 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r d1591841fe96 -r 8c77fe3008a4 tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Fri Nov 18 11:29:18 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:16:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:16:52 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNNE-0003gH-CV
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:16:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNMu-0008Fz-To; Fri, 18 Nov 2011 04:16:33 -0800
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRN7M-0004gf-Bc
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:00:32 -0800
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321617575!44462776!10
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12737 invoked from network); 18 Nov 2011 11:59:53 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 11:59:53 -0000
Received: by mail-ey0-f171.google.com with SMTP id 6so5431481eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 04:00:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=VhELDb2+slHZ8Cqtdz2qwXJCaODZIzFRsl0DJ7RM2B0=;
	b=oBP1ktkhQ5Rfxe2UtbNckKxP8dCLPGMZmlAL2T5J99AFN5IChh+fIkdIG+bfhV1L7o
	8GZRHuAsrt8IryHSbjsDlPHAujRkMXX3deLVNKrqbTSpLoLyGKDt0cpjb0od/6rC7gtr
	7Gvajf2Q5DtPv+i8qHq3ya1G9vZGzY2T0K/Eg=
Received: by 10.14.5.206 with SMTP id 54mr179195eel.191.1321617625119;
	Fri, 18 Nov 2011 04:00:25 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id 54sm1806861eex.8.2011.11.18.04.00.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 04:00:24 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mercurial-Node: 8c77fe3008a486de7062d37053dcd0dbdc92ee0a
Message-Id: <8c77fe3008a486de7062.1321617585@loki.upc.es>
In-Reply-To: <patchbomb.1321617576@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 18 Nov 2011 12:59:45 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 9 of 9 v2] rc.d NetBSD: don't start xenbackendd
 by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 8c77fe3008a486de7062d37053dcd0dbdc92ee0a
# Parent  d1591841fe963f054cd6b27d6d87ac005cfff29a
rc.d NetBSD: don't start xenbackendd by default, only when xend needs it.

With the move of hotplug scripts from xenbackendd to libxl
xenbackendd is no longer needed by libxl, only start it when xend is
started.

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

diff -r d1591841fe96 -r 8c77fe3008a4 tools/hotplug/NetBSD/rc.d/xenbackendd
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/hotplug/NetBSD/rc.d/xenbackendd	Fri Sep 30 14:38:55 2011 +0200
@@ -0,0 +1,27 @@
+#!/bin/sh
+#
+# PROVIDE: xenbackendd
+# REQUIRE: xencommons
+
+. /etc/rc.subr
+
+DIR=$(dirname "$0")
+. "${DIR}/xen-hotplugpath.sh"
+
+LD_LIBRARY_PATH="${LIBDIR}"
+export LD_LIBRARY_PATH PYTHONPATH
+PATH="${PATH}:${SBINDIR}"
+export PATH
+
+name="xenbackendd"
+rcvar=$name
+command="${SBINDIR}/xenbackendd"
+if [ -n "${XENBACKENDD_DEBUG}" ]; then
+	command_args="${XENBACKENDD_ARGS} -d"
+else
+	command_args="${XENBACKENDD_ARGS}"
+fi
+
+load_rc_config $name
+run_rc_command "$1"
+
diff -r d1591841fe96 -r 8c77fe3008a4 tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Fri Nov 18 11:29:18 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r d1591841fe96 -r 8c77fe3008a4 tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Fri Nov 18 11:29:18 2011 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:19:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:19:57 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNQD-0003jV-EH
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNPt-00012E-PH; Fri, 18 Nov 2011 04:19:37 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRNGr-0006Se-SO
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:10:18 -0800
X-Env-Sender: nhorman@tuxdriver.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1321618207!4664897!1
X-Originating-IP: [70.61.120.58]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26885 invoked from network); 18 Nov 2011 12:10:08 -0000
Received: from charlotte.tuxdriver.com (HELO smtp.tuxdriver.com) (70.61.120.58)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 12:10:08 -0000
Received: from hmsreliant.think-freely.org
	([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost)
	by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63)
	(envelope-from <nhorman@tuxdriver.com>)
	id 1RRNGZ-0008NS-Dx; Fri, 18 Nov 2011 07:10:01 -0500
Date: Fri, 18 Nov 2011 07:09:58 -0500
From: Neil Horman <nhorman@tuxdriver.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111118120958.GD7907@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
	<1321561021.8866.12.camel@dagon.hellion.org.uk>
	<20111117204553.GD26847@hmsreliant.think-freely.org>
	<1321612213.3664.293.camel@zakaz.uk.xensource.com>
	<20111118114839.GA7907@hmsreliant.think-freely.org>
	<1321617190.3664.338.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1321617190.3664.338.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -2.6 (--)
X-Spam-Status: No
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 11:53:09AM +0000, Ian Campbell wrote:
> On Fri, 2011-11-18 at 11:48 +0000, Neil Horman wrote:
> > On Fri, Nov 18, 2011 at 10:30:13AM +0000, Ian Campbell wrote:
> > > On Thu, 2011-11-17 at 20:45 +0000, Neil Horman wrote:
> > > > On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> > > > > On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > > > > > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > > > > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > > > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > > > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > > > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > > > > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > > > > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > > > > > 
> > > > > > > What are the actual constraints here? The skb is used as a handle to the
> > > > > > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > > > > > those which are passed to the hypervisor (effectively the same as
> > > > > > > passing those addresses to the h/w for DMA).
> > > > > > > 
> > > > > > > Which parts of the skb are expected/allowed to not remain stable?
> > > > > > > 
> > > > > > > (Appologies if the above seems naive, I seem to have missed the
> > > > > > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > > > > > 
> > > > > > Its ok, this is the most accurate description from the previous threads on the
> > > > > > subject:
> > > > > > 2
> > > > > > 
> > > > > > The basic problem boils down the notion that some drivers, when they receive an
> > > > > > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > > > > > result may do things like add the skb to a list, or otherwise store stateful
> > > > > > data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> > > > > > holds a reference to the skb, and make make changes without serializing them
> > > > > > against the driver.  So we have to flag those drivers which preform these kinds
> > > > > > of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> > > > > > an skb, but it does place a pointer to the skb in a data structure here:
> > > > > > 
> > > > > > np->tx_skbs[id].skb = skb;
> > > > > > 
> > > > > > Which then gets handed off to the hypervisior.  Since the hypervisor now has
> > > > > > access to that skb pointer, and we can't be sure (from the guest perspective),
> > > > > > what it does with that information, it would be better to be safe by disallowing
> > > > > > shared skbs in this path.
> > > > > 
> > > > > The skb pointer itself doesn't get given to the backend/hypervisor. The
> > > > > page which skb->data refers to is granted to the backend domain, as are
> > > > > the pages in the frags.
> > > > > 
> > > > > I think we only need to be sure that the frontend doesn't rely on
> > > > > anything in the skb itself, right? Does skb->data or shinfo count from
> > > > > that perspective?
> > > > shinfo is definately a problem, as other devices may make modifications to it.
> > > > skb->data is probably safer, but is also potentially suspect (for instance if
> > > > another device appends an additional header to the data for instance)
> > > 
> > > A device is allowed to rely on these things being stable while in its
> > > start_xmit, right? (otherwise I don't see how any device can ever
> > > cope...).
> > > 
> > While the start_xmit routine is executing, yes.  Its only after the driver
> > returns, that it can have no expectation of an skb's data to remain stable.
> > 
> > > netfront only uses shinfo and ->data during start_xmit in order to
> > > create the necessary grant reference (which can be thought of as a DMA
> > > address passed to the virtual hardware). The only use of the stashed skb
> > > pointer outside of this are to dev_kfree_skb on tx completion (from
> > > either tx_buf_gc (normal completion) or release_tx_buf ("hardware"
> > > reset).
> > > 
> > Ok, if you're certain you can guarantee that the hypervisior makes no inspection
> > of the skb after the return from the driver, then you're safe
> 
> I believe this is the case, all that is exposed to the backend is the
> pfn, offset and length of the skb->data and frags at the time start_xmit
> was called.
> 
Ok, if you're sure, than this can be dropped.
Neil


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:19:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:19:57 +0000
Received: from lists.colo.xensource.com ([70.42.241.110] helo=lists.xensource.com)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNQD-0003jV-EH
	for archives@lists.xen.org; Fri, 18 Nov 2011 12:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.colo.xensource.com)
	by lists.xensource.com with esmtp (Exim 4.43)
	id 1RRNPt-00012E-PH; Fri, 18 Nov 2011 04:19:37 -0800
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xensource.com with esmtp (Exim 4.43) id 1RRNGr-0006Se-SO
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 04:10:18 -0800
X-Env-Sender: nhorman@tuxdriver.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1321618207!4664897!1
X-Originating-IP: [70.61.120.58]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26885 invoked from network); 18 Nov 2011 12:10:08 -0000
Received: from charlotte.tuxdriver.com (HELO smtp.tuxdriver.com) (70.61.120.58)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 12:10:08 -0000
Received: from hmsreliant.think-freely.org
	([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost)
	by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63)
	(envelope-from <nhorman@tuxdriver.com>)
	id 1RRNGZ-0008NS-Dx; Fri, 18 Nov 2011 07:10:01 -0500
Date: Fri, 18 Nov 2011 07:09:58 -0500
From: Neil Horman <nhorman@tuxdriver.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111118120958.GD7907@hmsreliant.think-freely.org>
References: <1321298544-16434-1-git-send-email-nhorman@tuxdriver.com>
	<1321543238.3664.278.camel@zakaz.uk.xensource.com>
	<20111117192535.GB26847@hmsreliant.think-freely.org>
	<1321561021.8866.12.camel@dagon.hellion.org.uk>
	<20111117204553.GD26847@hmsreliant.think-freely.org>
	<1321612213.3664.293.camel@zakaz.uk.xensource.com>
	<20111118114839.GA7907@hmsreliant.think-freely.org>
	<1321617190.3664.338.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1321617190.3664.338.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -2.6 (--)
X-Spam-Status: No
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] Re: [PATCH] Don't allow sharing of tx skbs on
	xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 11:53:09AM +0000, Ian Campbell wrote:
> On Fri, 2011-11-18 at 11:48 +0000, Neil Horman wrote:
> > On Fri, Nov 18, 2011 at 10:30:13AM +0000, Ian Campbell wrote:
> > > On Thu, 2011-11-17 at 20:45 +0000, Neil Horman wrote:
> > > > On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> > > > > On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > > > > > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > > > > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > > > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > > > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > > > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > > > > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > > > > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > > > > > 
> > > > > > > What are the actual constraints here? The skb is used as a handle to the
> > > > > > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > > > > > those which are passed to the hypervisor (effectively the same as
> > > > > > > passing those addresses to the h/w for DMA).
> > > > > > > 
> > > > > > > Which parts of the skb are expected/allowed to not remain stable?
> > > > > > > 
> > > > > > > (Appologies if the above seems naive, I seem to have missed the
> > > > > > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > > > > > 
> > > > > > Its ok, this is the most accurate description from the previous threads on the
> > > > > > subject:
> > > > > > 2
> > > > > > 
> > > > > > The basic problem boils down the notion that some drivers, when they receive an
> > > > > > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > > > > > result may do things like add the skb to a list, or otherwise store stateful
> > > > > > data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> > > > > > holds a reference to the skb, and make make changes without serializing them
> > > > > > against the driver.  So we have to flag those drivers which preform these kinds
> > > > > > of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> > > > > > an skb, but it does place a pointer to the skb in a data structure here:
> > > > > > 
> > > > > > np->tx_skbs[id].skb = skb;
> > > > > > 
> > > > > > Which then gets handed off to the hypervisior.  Since the hypervisor now has
> > > > > > access to that skb pointer, and we can't be sure (from the guest perspective),
> > > > > > what it does with that information, it would be better to be safe by disallowing
> > > > > > shared skbs in this path.
> > > > > 
> > > > > The skb pointer itself doesn't get given to the backend/hypervisor. The
> > > > > page which skb->data refers to is granted to the backend domain, as are
> > > > > the pages in the frags.
> > > > > 
> > > > > I think we only need to be sure that the frontend doesn't rely on
> > > > > anything in the skb itself, right? Does skb->data or shinfo count from
> > > > > that perspective?
> > > > shinfo is definately a problem, as other devices may make modifications to it.
> > > > skb->data is probably safer, but is also potentially suspect (for instance if
> > > > another device appends an additional header to the data for instance)
> > > 
> > > A device is allowed to rely on these things being stable while in its
> > > start_xmit, right? (otherwise I don't see how any device can ever
> > > cope...).
> > > 
> > While the start_xmit routine is executing, yes.  Its only after the driver
> > returns, that it can have no expectation of an skb's data to remain stable.
> > 
> > > netfront only uses shinfo and ->data during start_xmit in order to
> > > create the necessary grant reference (which can be thought of as a DMA
> > > address passed to the virtual hardware). The only use of the stashed skb
> > > pointer outside of this are to dev_kfree_skb on tx completion (from
> > > either tx_buf_gc (normal completion) or release_tx_buf ("hardware"
> > > reset).
> > > 
> > Ok, if you're certain you can guarantee that the hypervisior makes no inspection
> > of the skb after the return from the driver, then you're safe
> 
> I believe this is the case, all that is exposed to the backend is the
> pfn, offset and length of the skb->data and frags at the time start_xmit
> was called.
> 
Ok, if you're sure, than this can be dropped.
Neil


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:22:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNRK-0003l6-EM; Fri, 18 Nov 2011 12:21:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RRNRI-0003kw-J9
	for Xen-devel@lists.xensource.com; Fri, 18 Nov 2011 12:21:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321618838!4738685!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7239 invoked from network); 18 Nov 2011 12:20:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 12:20:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9008715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 12:20:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 12:20:37 +0000
Date: Fri, 18 Nov 2011 12:21:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Mukesh Rathor <mukesh.rathor@oracle.com>
In-Reply-To: <20111117153838.04e15aa9@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.00.1111181159150.3519@kaball-desktop>
References: <20110627122404.23d2d0ce@mantra.us.oracle.com>
	<20110630185431.3ea308c6@mantra.us.oracle.com>
	<20110708185301.4b040a21@mantra.us.oracle.com>
	<20110727185828.55099372@mantra.us.oracle.com>
	<20111117153838.04e15aa9@mantra.us.oracle.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] HYBRID: PV in HVM container
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 17 Nov 2011, Mukesh Rathor wrote:
> Alright, got hybrid with EPT numbers in now from my prototype, it needs
> some perf work.. 

Is HVM a PV on HVM guest or a pure HVM guest (no CONFIG_XEN)?


> Processor, Processes - times in microseconds - smaller is better
> ------------------------------------------------------------------------------
> Host                 OS  Mhz null null      open slct sig  sig  fork exec sh  
>                              call  I/O stat clos TCP  inst hndl proc proc proc
> --------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
> PV        Linux 2.6.39f 2639 0.65 0.88 2.14 4.59 3.77 0.79 3.62 535. 1294 3308
> Hybrid    Linux 2.6.39f 2639 0.13 0.21 0.89 1.96 3.08 0.24 1.10 529. 1294 3246
> HVM       Linux 2.6.39f 2639 0.12 0.21 0.64 1.76 3.04 0.24 3.37 113. 354. 1324
> Baremetal Linux 2.6.39+ 2649 0.13 0.23 0.74 1.93 3.46 0.28 1.58 127. 386. 1434
> HYB-EPT   Linux 2.6.39f 2639 0.13 0.21 0.68 1.95 3.04 0.25 3.09 145. 452. 1542

good, hybrid == HVM in this test

[...]
 

> Context switching - times in microseconds - smaller is better
> -------------------------------------------------------------------------
> Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
>                          ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
> --------- ------------- ------ ------ ------ ------ ------ ------- -------
> PV        Linux 2.6.39f 5.2800 5.7600 6.3600 6.3200 7.3600 6.69000 7.46000
> Hybrid    Linux 2.6.39f 4.9200 4.9300 5.2200 5.7600 6.9600 6.12000 7.31000
> HVM       Linux 2.6.39f 1.3100 1.2200 1.6200 1.9200 3.2600 2.23000 3.48000
> Baremetal Linux 2.6.39+ 1.5500 1.4100 2.0600 2.2500 3.3900 2.44000 3.38000
> HYB-EPT   Linux 2.6.39f 3.2000 3.6100 4.1700 4.3600 6.1200 4.81000 6.20000

How is it possible that the HYB-EPT numbers here are so much worse than
HVM? Shouldn't they be the same as in the other tests?


> *Local* Communication latencies in microseconds - smaller is better
> ---------------------------------------------------------------------
> Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
>                         ctxsw       UNIX         UDP         TCP conn
> --------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
> PV        Linux 2.6.39f 5.280  16.6 21.3  25.9  33.7  34.7  41.8  87.
> Hybrid    Linux 2.6.39f 4.920  11.2 14.4  19.6  26.1  27.5  32.9  71.
> HVM       Linux 2.6.39f 1.310 4.416 6.15 9.386  14.8  15.8  20.1  45.
> Baremetal Linux 2.6.39+ 1.550 4.625 7.34  14.3  19.8  21.4  26.4  66.
> HYB-EPT   Linux 2.6.39f 3.200 8.669 15.3  17.5  23.5  25.1  30.4  66.
>
> *Local* Communication bandwidths in MB/s - bigger is better
> -----------------------------------------------------------------------------
> Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
>                              UNIX      reread reread (libc) (hand) read write
> --------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
> PV        Linux 2.6.39f 1661 2081 1041 3293.3 5528.3 3106.6 2800.0 4472 5633.
> Hybrid    Linux 2.6.39f 1974 2450 1183 3481.5 5529.6 3114.9 2786.6 4470 5672.
> HVM       Linux 2.6.39f 3232 2929 1622 3541.3 5527.5 3077.1 2765.6 4453 5634.
> Baremetal Linux 2.6.39+ 3320 2800 1666 3523.6 5578.9 3147.0 2841.6 4541 5752.
> HYB-EPT   Linux 2.6.39f 2104 2480 1231 3451.5 5503.4 3067.7 2751.0 4438 5636.

same on these two tests




> Attaching the diffs from my prototype. Linux: 2.6.39. Xen 4.0.2.

lin.diff:


> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e3c6a06..53ceae0 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -110,7 +110,7 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
>   *
>   * 0: not available, 1: available
>   */
> -static int have_vcpu_info_placement = 1;
> +static int have_vcpu_info_placement = 0;
>  
>  static void clamp_max_cpus(void)
>  {
> @@ -195,6 +195,13 @@ static void __init xen_banner(void)
>  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
>  	       version >> 16, version & 0xffff, extra.extraversion,
>  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
> +
> +        if (xen_hybrid_domain()) {
> +	        printk(KERN_INFO "MUK: is MUK HYBRID domain....");
> +		if (xen_feature(XENFEAT_auto_translated_physmap))
> +                	printk(KERN_INFO "with EPT...");
> +        	printk(KERN_INFO "\n");
> +        }
>  }
>  
>  static __read_mostly unsigned int cpuid_leaf1_edx_mask = ~0;
> @@ -222,8 +229,10 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
>  		maskebx = 0;
>  		break;
>  	}
> -
> -	asm(XEN_EMULATE_PREFIX "cpuid"
> +        if (xen_hybrid_domain()) {
> +                native_cpuid(ax, bx, cx, dx);
> +        } else
> +	        asm(XEN_EMULATE_PREFIX "cpuid"
>  		: "=a" (*ax),
>  		  "=b" (*bx),
>  		  "=c" (*cx),
> @@ -244,6 +253,7 @@ static __init void xen_init_cpuid_mask(void)
>  		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
>  		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
>  		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> +                  (1 << X86_FEATURE_PSE)  |  /* disable 2M pages */
>  		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
>  
>  	if (!xen_initial_domain())
> @@ -393,6 +403,10 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
>  		make_lowmem_page_readonly(virt);
>  	}
>  
> +        if (xen_hybrid_domain()) {
> +                native_load_gdt(dtr);
> +                return;
> +        }
>  	if (HYPERVISOR_set_gdt(frames, size / sizeof(struct desc_struct)))
>  		BUG();
>  }
> @@ -431,6 +445,10 @@ static __init void xen_load_gdt_boot(const struct desc_ptr *dtr)
>  		frames[f] = mfn;
>  	}
>  
> +        if (xen_hybrid_domain()) {
> +                native_load_gdt(dtr);
> +                return;
> +        }
>  	if (HYPERVISOR_set_gdt(frames, size / sizeof(struct desc_struct)))
>  		BUG();
>  }
> @@ -849,9 +867,11 @@ void xen_setup_shared_info(void)
>  
>  		HYPERVISOR_shared_info =
>  			(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
> -	} else
> +	} else {
>  		HYPERVISOR_shared_info =
>  			(struct shared_info *)__va(xen_start_info->shared_info);
> +        	return;
> +	}
>  
>  #ifndef CONFIG_SMP
>  	/* In UP this is as good a place as any to set up shared info */
> @@ -944,6 +964,71 @@ static const struct pv_init_ops xen_init_ops __initdata = {
>  	.patch = xen_patch,
>  };
>  
> +extern void native_iret(void);
> +extern void native_irq_enable_sysexit(void);
> +extern void native_usergs_sysret32(void);
> +extern void native_usergs_sysret64(void);
> +
> +static const struct pv_cpu_ops xen_hybrid_cpu_ops __initdata = {
> +	.cpuid = xen_cpuid,
> +	.set_debugreg = xen_set_debugreg,
> +	.get_debugreg = xen_get_debugreg,
> +
> +	.clts = xen_clts,
> +
> +	.read_cr0 = xen_read_cr0,
> +	.write_cr0 = xen_write_cr0,
> +
> +	.read_cr4 = native_read_cr4,
> +	.read_cr4_safe = native_read_cr4_safe,
> +	.write_cr4 = native_write_cr4,
> +
> +	.wbinvd = native_wbinvd,
> +
> +	.read_msr = native_read_msr_safe,
> +	.write_msr = native_write_msr_safe,
> +	.read_tsc = native_read_tsc,
> +	.read_pmc = native_read_pmc,
> +
> +	.iret = native_iret,
> +	.irq_enable_sysexit = native_irq_enable_sysexit,
> +#ifdef CONFIG_X86_64
> +	.usergs_sysret32 = native_usergs_sysret32,
> +	.usergs_sysret64 = native_usergs_sysret64,
> +#endif
> +
> +	.load_tr_desc = native_load_tr_desc,
> +	.set_ldt = native_set_ldt,
> +	.load_gdt = native_load_gdt,
> +	.load_idt = native_load_idt,
> +	.load_tls = native_load_tls,
> +#ifdef CONFIG_X86_64
> +	.load_gs_index = native_load_gs_index,
> +#endif
> +
> +	.alloc_ldt = paravirt_nop,
> +	.free_ldt = paravirt_nop,
> +
> +	.store_gdt = native_store_gdt,
> +	.store_idt = native_store_idt,
> +	.store_tr = native_store_tr,
> +
> +	.write_ldt_entry = native_write_ldt_entry,
> +	.write_gdt_entry = native_write_gdt_entry,
> +	.write_idt_entry = native_write_idt_entry,
> +	.load_sp0 = native_load_sp0,
> +
> +	.set_iopl_mask = native_set_iopl_mask,
> +	.io_delay = xen_io_delay,
> +
> +	/* Xen takes care of %gs when switching to usermode for us */
> +	.swapgs = native_swapgs,
> +
> +	.start_context_switch = paravirt_start_context_switch,
> +	.end_context_switch = xen_end_context_switch,

why are you using the paravirt version of start_context_switch and
end_context_switch? Is this for the non-autotranslate version?


> +};
> +
>  static const struct pv_cpu_ops xen_cpu_ops __initdata = {
>  	.cpuid = xen_cpuid,
>  
> @@ -1010,6 +1095,11 @@ static const struct pv_apic_ops xen_apic_ops __initdata = {
>  #endif
>  };
>  
> +static void __init xen_hybrid_override_autox_cpu_ops(void)
> +{
> +        pv_cpu_ops.cpuid = xen_cpuid;
> +}
> +
>  static void xen_reboot(int reason)
>  {
>  	struct sched_shutdown r = { .reason = reason };
> @@ -1071,6 +1161,10 @@ static const struct machine_ops __initdata xen_machine_ops = {
>   */
>  static void __init xen_setup_stackprotector(void)
>  {
> +        if (xen_hybrid_domain()) {
> +                switch_to_new_gdt(0);
> +                return;
> +        }
>  	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
>  	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
>  
> @@ -1093,14 +1187,22 @@ asmlinkage void __init xen_start_kernel(void)
>  
>  	xen_domain_type = XEN_PV_DOMAIN;
>  
> +	xen_setup_features();
>  	xen_setup_machphys_mapping();
>  
>  	/* Install Xen paravirt ops */
>  	pv_info = xen_info;
>  	pv_init_ops = xen_init_ops;
> -	pv_cpu_ops = xen_cpu_ops;
>  	pv_apic_ops = xen_apic_ops;
>  
> +        if (xen_hybrid_domain()) {
> +	        if (xen_feature(XENFEAT_auto_translated_physmap))
> +                        xen_hybrid_override_autox_cpu_ops();
> +                else
> +	        	pv_cpu_ops = xen_hybrid_cpu_ops;
> +        } else
> +	        pv_cpu_ops = xen_cpu_ops;

[...]

>  void __init xen_init_mmu_ops(void)
>  {
> +	memset(dummy_mapping, 0xff, PAGE_SIZE);
> +	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +        	return;
> +
>  	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>  	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
> -	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
> -	pv_mmu_ops = xen_mmu_ops;
> +        pv_mmu_ops = xen_mmu_ops;
>  
> -	memset(dummy_mapping, 0xff, PAGE_SIZE);
> +        if (xen_hybrid_domain())      /* hybrid without EPT, ie, pv paging. */
> +		xen_hyb_override_mmu_ops();
>  }
>  
>  /* Protected by xen_reservation_lock. */

So in theory HYB-EPT is running with native_cpu_ops and native_mmu_ops;
in this case I don't understand why the performances are lower than HVM.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:22:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNRK-0003l6-EM; Fri, 18 Nov 2011 12:21:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RRNRI-0003kw-J9
	for Xen-devel@lists.xensource.com; Fri, 18 Nov 2011 12:21:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321618838!4738685!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7239 invoked from network); 18 Nov 2011 12:20:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 12:20:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; 
   d="scan'208";a="9008715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 12:20:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 12:20:37 +0000
Date: Fri, 18 Nov 2011 12:21:19 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Mukesh Rathor <mukesh.rathor@oracle.com>
In-Reply-To: <20111117153838.04e15aa9@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.00.1111181159150.3519@kaball-desktop>
References: <20110627122404.23d2d0ce@mantra.us.oracle.com>
	<20110630185431.3ea308c6@mantra.us.oracle.com>
	<20110708185301.4b040a21@mantra.us.oracle.com>
	<20110727185828.55099372@mantra.us.oracle.com>
	<20111117153838.04e15aa9@mantra.us.oracle.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] HYBRID: PV in HVM container
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 17 Nov 2011, Mukesh Rathor wrote:
> Alright, got hybrid with EPT numbers in now from my prototype, it needs
> some perf work.. 

Is HVM a PV on HVM guest or a pure HVM guest (no CONFIG_XEN)?


> Processor, Processes - times in microseconds - smaller is better
> ------------------------------------------------------------------------------
> Host                 OS  Mhz null null      open slct sig  sig  fork exec sh  
>                              call  I/O stat clos TCP  inst hndl proc proc proc
> --------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
> PV        Linux 2.6.39f 2639 0.65 0.88 2.14 4.59 3.77 0.79 3.62 535. 1294 3308
> Hybrid    Linux 2.6.39f 2639 0.13 0.21 0.89 1.96 3.08 0.24 1.10 529. 1294 3246
> HVM       Linux 2.6.39f 2639 0.12 0.21 0.64 1.76 3.04 0.24 3.37 113. 354. 1324
> Baremetal Linux 2.6.39+ 2649 0.13 0.23 0.74 1.93 3.46 0.28 1.58 127. 386. 1434
> HYB-EPT   Linux 2.6.39f 2639 0.13 0.21 0.68 1.95 3.04 0.25 3.09 145. 452. 1542

good, hybrid == HVM in this test

[...]
 

> Context switching - times in microseconds - smaller is better
> -------------------------------------------------------------------------
> Host                 OS  2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
>                          ctxsw  ctxsw  ctxsw ctxsw  ctxsw   ctxsw   ctxsw
> --------- ------------- ------ ------ ------ ------ ------ ------- -------
> PV        Linux 2.6.39f 5.2800 5.7600 6.3600 6.3200 7.3600 6.69000 7.46000
> Hybrid    Linux 2.6.39f 4.9200 4.9300 5.2200 5.7600 6.9600 6.12000 7.31000
> HVM       Linux 2.6.39f 1.3100 1.2200 1.6200 1.9200 3.2600 2.23000 3.48000
> Baremetal Linux 2.6.39+ 1.5500 1.4100 2.0600 2.2500 3.3900 2.44000 3.38000
> HYB-EPT   Linux 2.6.39f 3.2000 3.6100 4.1700 4.3600 6.1200 4.81000 6.20000

How is it possible that the HYB-EPT numbers here are so much worse than
HVM? Shouldn't they be the same as in the other tests?


> *Local* Communication latencies in microseconds - smaller is better
> ---------------------------------------------------------------------
> Host                 OS 2p/0K  Pipe AF     UDP  RPC/   TCP  RPC/ TCP
>                         ctxsw       UNIX         UDP         TCP conn
> --------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
> PV        Linux 2.6.39f 5.280  16.6 21.3  25.9  33.7  34.7  41.8  87.
> Hybrid    Linux 2.6.39f 4.920  11.2 14.4  19.6  26.1  27.5  32.9  71.
> HVM       Linux 2.6.39f 1.310 4.416 6.15 9.386  14.8  15.8  20.1  45.
> Baremetal Linux 2.6.39+ 1.550 4.625 7.34  14.3  19.8  21.4  26.4  66.
> HYB-EPT   Linux 2.6.39f 3.200 8.669 15.3  17.5  23.5  25.1  30.4  66.
>
> *Local* Communication bandwidths in MB/s - bigger is better
> -----------------------------------------------------------------------------
> Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
>                              UNIX      reread reread (libc) (hand) read write
> --------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
> PV        Linux 2.6.39f 1661 2081 1041 3293.3 5528.3 3106.6 2800.0 4472 5633.
> Hybrid    Linux 2.6.39f 1974 2450 1183 3481.5 5529.6 3114.9 2786.6 4470 5672.
> HVM       Linux 2.6.39f 3232 2929 1622 3541.3 5527.5 3077.1 2765.6 4453 5634.
> Baremetal Linux 2.6.39+ 3320 2800 1666 3523.6 5578.9 3147.0 2841.6 4541 5752.
> HYB-EPT   Linux 2.6.39f 2104 2480 1231 3451.5 5503.4 3067.7 2751.0 4438 5636.

same on these two tests




> Attaching the diffs from my prototype. Linux: 2.6.39. Xen 4.0.2.

lin.diff:


> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index e3c6a06..53ceae0 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -110,7 +110,7 @@ struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
>   *
>   * 0: not available, 1: available
>   */
> -static int have_vcpu_info_placement = 1;
> +static int have_vcpu_info_placement = 0;
>  
>  static void clamp_max_cpus(void)
>  {
> @@ -195,6 +195,13 @@ static void __init xen_banner(void)
>  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
>  	       version >> 16, version & 0xffff, extra.extraversion,
>  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
> +
> +        if (xen_hybrid_domain()) {
> +	        printk(KERN_INFO "MUK: is MUK HYBRID domain....");
> +		if (xen_feature(XENFEAT_auto_translated_physmap))
> +                	printk(KERN_INFO "with EPT...");
> +        	printk(KERN_INFO "\n");
> +        }
>  }
>  
>  static __read_mostly unsigned int cpuid_leaf1_edx_mask = ~0;
> @@ -222,8 +229,10 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
>  		maskebx = 0;
>  		break;
>  	}
> -
> -	asm(XEN_EMULATE_PREFIX "cpuid"
> +        if (xen_hybrid_domain()) {
> +                native_cpuid(ax, bx, cx, dx);
> +        } else
> +	        asm(XEN_EMULATE_PREFIX "cpuid"
>  		: "=a" (*ax),
>  		  "=b" (*bx),
>  		  "=c" (*cx),
> @@ -244,6 +253,7 @@ static __init void xen_init_cpuid_mask(void)
>  		~((1 << X86_FEATURE_MCE)  |  /* disable MCE */
>  		  (1 << X86_FEATURE_MCA)  |  /* disable MCA */
>  		  (1 << X86_FEATURE_MTRR) |  /* disable MTRR */
> +                  (1 << X86_FEATURE_PSE)  |  /* disable 2M pages */
>  		  (1 << X86_FEATURE_ACC));   /* thermal monitoring */
>  
>  	if (!xen_initial_domain())
> @@ -393,6 +403,10 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
>  		make_lowmem_page_readonly(virt);
>  	}
>  
> +        if (xen_hybrid_domain()) {
> +                native_load_gdt(dtr);
> +                return;
> +        }
>  	if (HYPERVISOR_set_gdt(frames, size / sizeof(struct desc_struct)))
>  		BUG();
>  }
> @@ -431,6 +445,10 @@ static __init void xen_load_gdt_boot(const struct desc_ptr *dtr)
>  		frames[f] = mfn;
>  	}
>  
> +        if (xen_hybrid_domain()) {
> +                native_load_gdt(dtr);
> +                return;
> +        }
>  	if (HYPERVISOR_set_gdt(frames, size / sizeof(struct desc_struct)))
>  		BUG();
>  }
> @@ -849,9 +867,11 @@ void xen_setup_shared_info(void)
>  
>  		HYPERVISOR_shared_info =
>  			(struct shared_info *)fix_to_virt(FIX_PARAVIRT_BOOTMAP);
> -	} else
> +	} else {
>  		HYPERVISOR_shared_info =
>  			(struct shared_info *)__va(xen_start_info->shared_info);
> +        	return;
> +	}
>  
>  #ifndef CONFIG_SMP
>  	/* In UP this is as good a place as any to set up shared info */
> @@ -944,6 +964,71 @@ static const struct pv_init_ops xen_init_ops __initdata = {
>  	.patch = xen_patch,
>  };
>  
> +extern void native_iret(void);
> +extern void native_irq_enable_sysexit(void);
> +extern void native_usergs_sysret32(void);
> +extern void native_usergs_sysret64(void);
> +
> +static const struct pv_cpu_ops xen_hybrid_cpu_ops __initdata = {
> +	.cpuid = xen_cpuid,
> +	.set_debugreg = xen_set_debugreg,
> +	.get_debugreg = xen_get_debugreg,
> +
> +	.clts = xen_clts,
> +
> +	.read_cr0 = xen_read_cr0,
> +	.write_cr0 = xen_write_cr0,
> +
> +	.read_cr4 = native_read_cr4,
> +	.read_cr4_safe = native_read_cr4_safe,
> +	.write_cr4 = native_write_cr4,
> +
> +	.wbinvd = native_wbinvd,
> +
> +	.read_msr = native_read_msr_safe,
> +	.write_msr = native_write_msr_safe,
> +	.read_tsc = native_read_tsc,
> +	.read_pmc = native_read_pmc,
> +
> +	.iret = native_iret,
> +	.irq_enable_sysexit = native_irq_enable_sysexit,
> +#ifdef CONFIG_X86_64
> +	.usergs_sysret32 = native_usergs_sysret32,
> +	.usergs_sysret64 = native_usergs_sysret64,
> +#endif
> +
> +	.load_tr_desc = native_load_tr_desc,
> +	.set_ldt = native_set_ldt,
> +	.load_gdt = native_load_gdt,
> +	.load_idt = native_load_idt,
> +	.load_tls = native_load_tls,
> +#ifdef CONFIG_X86_64
> +	.load_gs_index = native_load_gs_index,
> +#endif
> +
> +	.alloc_ldt = paravirt_nop,
> +	.free_ldt = paravirt_nop,
> +
> +	.store_gdt = native_store_gdt,
> +	.store_idt = native_store_idt,
> +	.store_tr = native_store_tr,
> +
> +	.write_ldt_entry = native_write_ldt_entry,
> +	.write_gdt_entry = native_write_gdt_entry,
> +	.write_idt_entry = native_write_idt_entry,
> +	.load_sp0 = native_load_sp0,
> +
> +	.set_iopl_mask = native_set_iopl_mask,
> +	.io_delay = xen_io_delay,
> +
> +	/* Xen takes care of %gs when switching to usermode for us */
> +	.swapgs = native_swapgs,
> +
> +	.start_context_switch = paravirt_start_context_switch,
> +	.end_context_switch = xen_end_context_switch,

why are you using the paravirt version of start_context_switch and
end_context_switch? Is this for the non-autotranslate version?


> +};
> +
>  static const struct pv_cpu_ops xen_cpu_ops __initdata = {
>  	.cpuid = xen_cpuid,
>  
> @@ -1010,6 +1095,11 @@ static const struct pv_apic_ops xen_apic_ops __initdata = {
>  #endif
>  };
>  
> +static void __init xen_hybrid_override_autox_cpu_ops(void)
> +{
> +        pv_cpu_ops.cpuid = xen_cpuid;
> +}
> +
>  static void xen_reboot(int reason)
>  {
>  	struct sched_shutdown r = { .reason = reason };
> @@ -1071,6 +1161,10 @@ static const struct machine_ops __initdata xen_machine_ops = {
>   */
>  static void __init xen_setup_stackprotector(void)
>  {
> +        if (xen_hybrid_domain()) {
> +                switch_to_new_gdt(0);
> +                return;
> +        }
>  	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
>  	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
>  
> @@ -1093,14 +1187,22 @@ asmlinkage void __init xen_start_kernel(void)
>  
>  	xen_domain_type = XEN_PV_DOMAIN;
>  
> +	xen_setup_features();
>  	xen_setup_machphys_mapping();
>  
>  	/* Install Xen paravirt ops */
>  	pv_info = xen_info;
>  	pv_init_ops = xen_init_ops;
> -	pv_cpu_ops = xen_cpu_ops;
>  	pv_apic_ops = xen_apic_ops;
>  
> +        if (xen_hybrid_domain()) {
> +	        if (xen_feature(XENFEAT_auto_translated_physmap))
> +                        xen_hybrid_override_autox_cpu_ops();
> +                else
> +	        	pv_cpu_ops = xen_hybrid_cpu_ops;
> +        } else
> +	        pv_cpu_ops = xen_cpu_ops;

[...]

>  void __init xen_init_mmu_ops(void)
>  {
> +	memset(dummy_mapping, 0xff, PAGE_SIZE);
> +	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +        	return;
> +
>  	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>  	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
> -	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
> -	pv_mmu_ops = xen_mmu_ops;
> +        pv_mmu_ops = xen_mmu_ops;
>  
> -	memset(dummy_mapping, 0xff, PAGE_SIZE);
> +        if (xen_hybrid_domain())      /* hybrid without EPT, ie, pv paging. */
> +		xen_hyb_override_mmu_ops();
>  }
>  
>  /* Protected by xen_reservation_lock. */

So in theory HYB-EPT is running with native_cpu_ops and native_mmu_ops;
in this case I don't understand why the performances are lower than HVM.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:42:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNlm-0004Kn-FK; Fri, 18 Nov 2011 12:42:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RRNll-0004Kb-MZ
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 12:42:13 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321620109!4057963!1
X-Originating-IP: [192.89.123.25]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9275 invoked from network); 18 Nov 2011 12:41:50 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 12:41:50 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 5FFA91C7B;
	Fri, 18 Nov 2011 14:41:49 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 39F4620058; Fri, 18 Nov 2011 14:41:49 +0200 (EET)
Date: Fri, 18 Nov 2011 14:41:49 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111118124148.GP12984@reaktio.net>
References: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] x86: re-inject emulated level pirqs
	in	PV on HVM guests if still asserted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 11:13:13AM +0000, Stefano Stabellini wrote:
> This patch is a backport of CS 24007 for xen-4.1-testing.
> 
> PV on HVM guests can loose level interrupts coming from emulated
> devices if they have been remapped onto event channels.  The reason is
> that we are missing the code to inject a pirq again in the guest when
> the guest EOIs it, if it corresponds to an emulated level interrupt
> and the interrupt is still asserted.
> 

Btw this issue also happens with pure HVM guests using emulated devices.
I was seeing this bug with Linux F16 HVM guest with IDE disk and realtek emulated NIC.
The emulated realtek nic didn't work before applying this patch.

-- Pasi


> Fix this issue and also return error when the guest tries to get the
> irq_status of a non-existing pirq.
> 
> 
> Changes in v2:
> 
> - move the spinlock afterward to cover the new code only.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Jan Beulich <JBeulich@suse.com>
> 
> 
> diff -r e73ada19a69d xen/arch/x86/physdev.c
> --- a/xen/arch/x86/physdev.c	Thu Nov 17 09:13:25 2011 +0000
> +++ b/xen/arch/x86/physdev.c	Fri Nov 18 09:42:03 2011 +0000
> @@ -268,6 +268,20 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              ret = pirq_guest_eoi(v->domain, eoi.irq);
>          else
>              ret = 0;
> +        spin_lock(&v->domain->event_lock);
> +        if ( is_hvm_domain(v->domain) &&
> +                domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 )
> +        {
> +            struct hvm_irq *hvm_irq = &v->domain->arch.hvm_domain.irq;
> +            int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq);
> +
> +            /* if this is a level irq and count > 0, send another
> +             * notification */ 
> +            if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */
> +                    && hvm_irq->gsi_assert_count[gsi] )
> +                send_guest_pirq(v->domain, eoi.irq);
> +        }
> +        spin_unlock(&v->domain->event_lock);
>          break;
>      }
>  
> @@ -323,9 +337,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              break;
>          irq_status_query.flags = 0;
>          if ( is_hvm_domain(v->domain) &&
> -             domain_pirq_to_irq(v->domain, irq) <= 0 )
> +                domain_pirq_to_irq(v->domain, irq) <= 0 &&
> +                domain_pirq_to_emuirq(v->domain, irq) == IRQ_UNBOUND )
>          {
> -            ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0;
> +            ret = -EINVAL;
>              break;
>          }
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 12:42:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 12:42:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRNlm-0004Kn-FK; Fri, 18 Nov 2011 12:42:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RRNll-0004Kb-MZ
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 12:42:13 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321620109!4057963!1
X-Originating-IP: [192.89.123.25]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9275 invoked from network); 18 Nov 2011 12:41:50 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 12:41:50 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 5FFA91C7B;
	Fri, 18 Nov 2011 14:41:49 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 39F4620058; Fri, 18 Nov 2011 14:41:49 +0200 (EET)
Date: Fri, 18 Nov 2011 14:41:49 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111118124148.GP12984@reaktio.net>
References: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] x86: re-inject emulated level pirqs
	in	PV on HVM guests if still asserted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 11:13:13AM +0000, Stefano Stabellini wrote:
> This patch is a backport of CS 24007 for xen-4.1-testing.
> 
> PV on HVM guests can loose level interrupts coming from emulated
> devices if they have been remapped onto event channels.  The reason is
> that we are missing the code to inject a pirq again in the guest when
> the guest EOIs it, if it corresponds to an emulated level interrupt
> and the interrupt is still asserted.
> 

Btw this issue also happens with pure HVM guests using emulated devices.
I was seeing this bug with Linux F16 HVM guest with IDE disk and realtek emulated NIC.
The emulated realtek nic didn't work before applying this patch.

-- Pasi


> Fix this issue and also return error when the guest tries to get the
> irq_status of a non-existing pirq.
> 
> 
> Changes in v2:
> 
> - move the spinlock afterward to cover the new code only.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Jan Beulich <JBeulich@suse.com>
> 
> 
> diff -r e73ada19a69d xen/arch/x86/physdev.c
> --- a/xen/arch/x86/physdev.c	Thu Nov 17 09:13:25 2011 +0000
> +++ b/xen/arch/x86/physdev.c	Fri Nov 18 09:42:03 2011 +0000
> @@ -268,6 +268,20 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              ret = pirq_guest_eoi(v->domain, eoi.irq);
>          else
>              ret = 0;
> +        spin_lock(&v->domain->event_lock);
> +        if ( is_hvm_domain(v->domain) &&
> +                domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 )
> +        {
> +            struct hvm_irq *hvm_irq = &v->domain->arch.hvm_domain.irq;
> +            int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq);
> +
> +            /* if this is a level irq and count > 0, send another
> +             * notification */ 
> +            if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */
> +                    && hvm_irq->gsi_assert_count[gsi] )
> +                send_guest_pirq(v->domain, eoi.irq);
> +        }
> +        spin_unlock(&v->domain->event_lock);
>          break;
>      }
>  
> @@ -323,9 +337,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              break;
>          irq_status_query.flags = 0;
>          if ( is_hvm_domain(v->domain) &&
> -             domain_pirq_to_irq(v->domain, irq) <= 0 )
> +                domain_pirq_to_irq(v->domain, irq) <= 0 &&
> +                domain_pirq_to_emuirq(v->domain, irq) == IRQ_UNBOUND )
>          {
> -            ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0;
> +            ret = -EINVAL;
>              break;
>          }
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:09:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:09:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROB6-0004bR-QI; Fri, 18 Nov 2011 13:08:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RROB5-0004bM-8W
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:08:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321621649!57779350!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29754 invoked from network); 18 Nov 2011 13:07:30 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:07:30 -0000
Received: by yenl7 with SMTP id l7so3638893yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 05:08:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LT/Il3coyztT6czZ7pIlBAK8qypUJtlrxpEmafavLz8=;
	b=WdtxKcJmOsx//mKJTF9NbKQ3jzN2dOZPNB+/ow52iFUSkA90iv/nKUhSuh85E1wKoB
	8iRbcn4hweYgYk6GjB1XdQYnHliqx66CXJDdJxVnbSiV29OfR6mMZlOXOSveaA52f8C+
	JtaZ4ipdSjNs1DtoWz+BxdIbxIZER3PvZJCrI=
Received: by 10.182.44.35 with SMTP id b3mr680001obm.26.1321621678200;
	Fri, 18 Nov 2011 05:07:58 -0800 (PST)
Received: from [192.168.1.151] ([198.162.52.244])
	by mx.google.com with ESMTPS id i6sm566663obl.2.2011.11.18.05.07.54
	(version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 05:07:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 18 Nov 2011 13:07:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAEC0924.251F6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 2] Add configuration options to
	selectively disable S3 and S4 (V2)
Thread-Index: Acyl8xG62VBvBTd9gkmCPAdhU5iD5w==
In-Reply-To: <patchbomb.1321612139@cosworth.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add configuration options to
 selectively disable S3 and S4 (V2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/11/2011 10:28, "Paul Durrant" <paul.durrant@citrix.com> wrote:

> This patch series adds the ability to selectively disable the S3 and S4 ACPI
> power states for HVM guests.
> 
> Since there is a general move towards retiring the hvm_info_table structure,
> the first patch moves the acpi_enabled flag out of the hvm_info_table and into
> a xenstore key (platform/acpi).
> The second patch then introduces the acpi_s3 and acpi_s4 configuration
> parameters to the xl config file (default=1). These result in population of
> new platform/acpi_s3 and platform/acpi_s4 xenstore keys. hvmloader then reads
> these keys to determine whether or not to include SSDTs containing the
> _S3 and _S4 packages respectively.

Way nicer. I'll check these in.

 -- Keir

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



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:09:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:09:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROB6-0004bR-QI; Fri, 18 Nov 2011 13:08:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RROB5-0004bM-8W
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:08:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321621649!57779350!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29754 invoked from network); 18 Nov 2011 13:07:30 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:07:30 -0000
Received: by yenl7 with SMTP id l7so3638893yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 05:08:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LT/Il3coyztT6czZ7pIlBAK8qypUJtlrxpEmafavLz8=;
	b=WdtxKcJmOsx//mKJTF9NbKQ3jzN2dOZPNB+/ow52iFUSkA90iv/nKUhSuh85E1wKoB
	8iRbcn4hweYgYk6GjB1XdQYnHliqx66CXJDdJxVnbSiV29OfR6mMZlOXOSveaA52f8C+
	JtaZ4ipdSjNs1DtoWz+BxdIbxIZER3PvZJCrI=
Received: by 10.182.44.35 with SMTP id b3mr680001obm.26.1321621678200;
	Fri, 18 Nov 2011 05:07:58 -0800 (PST)
Received: from [192.168.1.151] ([198.162.52.244])
	by mx.google.com with ESMTPS id i6sm566663obl.2.2011.11.18.05.07.54
	(version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 05:07:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 18 Nov 2011 13:07:48 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAEC0924.251F6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 2] Add configuration options to
	selectively disable S3 and S4 (V2)
Thread-Index: Acyl8xG62VBvBTd9gkmCPAdhU5iD5w==
In-Reply-To: <patchbomb.1321612139@cosworth.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0 of 2] Add configuration options to
 selectively disable S3 and S4 (V2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/11/2011 10:28, "Paul Durrant" <paul.durrant@citrix.com> wrote:

> This patch series adds the ability to selectively disable the S3 and S4 ACPI
> power states for HVM guests.
> 
> Since there is a general move towards retiring the hvm_info_table structure,
> the first patch moves the acpi_enabled flag out of the hvm_info_table and into
> a xenstore key (platform/acpi).
> The second patch then introduces the acpi_s3 and acpi_s4 configuration
> parameters to the xl config file (default=1). These result in population of
> new platform/acpi_s3 and platform/acpi_s4 xenstore keys. hvmloader then reads
> these keys to determine whether or not to include SSDTs containing the
> _S3 and _S4 packages respectively.

Way nicer. I'll check these in.

 -- Keir

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



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:13:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROFt-0004jj-Hq; Fri, 18 Nov 2011 13:13:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RROFr-0004jb-67
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:13:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1321621974!4769146!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24714 invoked from network); 18 Nov 2011 13:12:55 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:12:55 -0000
Received: by yenl7 with SMTP id l7so3646488yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 05:12:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LklRn6d7mJc3XcOPCKfbf1OhP/PcX/8p/i86VrxO/ao=;
	b=dz06CufL1TBleCFy3Nc9HVD+wUg6TWqzLAHY3aayMUpgmoES0Sk+J3CJ07V+SVCCog
	omVVGFvdU+Glo4UnsljUj/AtYfKQY48ViaWWa6tAN8+etdMur/jEap0ow4yXqTk6wOwr
	M5tI652TuFTIMxq4079CCpzP8WENZpt6tt5G8=
Received: by 10.182.21.134 with SMTP id v6mr675469obe.64.1321621972666;
	Fri, 18 Nov 2011 05:12:52 -0800 (PST)
Received: from [192.168.1.151] ([198.162.52.244])
	by mx.google.com with ESMTPS id y4sm204623obj.10.2011.11.18.05.12.49
	(version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 05:12:51 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 18 Nov 2011 13:12:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paul Durrant <Paul.Durrant@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CAEC0A4B.25205%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Index: Acyl3pqYjddMj3rUSzS16TqxbCsgEAAA88ewAARV9+U=
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B4543AB75A@LONPMAILBOX01.citrite.net>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
 selectively disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/11/2011 11:11, "Paul Durrant" <Paul.Durrant@citrix.com> wrote:

>> -----Original Message-----
>> From: Ian Campbell
>> Sent: 18 November 2011 10:41
>> To: Paul Durrant
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
>> selectively disable S3 and S4 ACPI power states
>> 
>> On Fri, 2011-11-18 at 10:29 +0000, Paul Durrant wrote:
>>> diff -r d22ef0f60497 -r 66bdcb90560f
>> tools/firmware/hvmloader/hvmloader.c
>>> --- a/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18
>> 10:28:52 2011 +0000
>>> +++ b/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18
>> 10:28:53 2011 +0000
>>> @@ -516,11 +516,17 @@ int main(void)
>>>              .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
>>>              .value = 1,
>>>          };
>>> +        int s3_enabled, s4_enabled;
>>> +
>>> +        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3",
>> "1"), "1", 1);
>>> +        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4",
>> "1"),
>>> + "1", 1);
>> 
>> Is it not possible to do these in the underlying acpi_build_tables
>> and avoid the need to plumb them right the way through?
>> 
> 
> I guess that would be possible. It just seemed logical to group the acpi
> config xenstore reads close together. If we're happy to distribute use of the
> xenstore client code to all corners of the source then I can certainly do
> that.

I think distributing the xenstore reads is fine. I will apply the final
patch series that you sent, that includes this change.

 -- Keir

>>>          if ( bios->acpi_build_tables )
>>>          {
>>> -            printf("Loading ACPI ...\n");
>>> -            bios->acpi_build_tables();
>>> +            printf("Loading ACPI (S3=%s S4=%s) ...\n",
>>> +                   (s3_enabled) ? "ON" : "OFF",
>>> +                   (s4_enabled) ? "ON" : "OFF");
>> 
>> If possible this printf could also be pushed down so you can
>> continue to print the config info.
>> 
> 
> Well, if the xenstore reads are pushed down then I'd clearly need to do that
> too :-)
> 
>>> +            bios->acpi_build_tables(s3_enabled, s4_enabled);
>>>          }
>>> 
>>>          acpi_enable_sci();
>> 
>> Ian.
>> 
> 
>   Paul
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:13:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROFt-0004jj-Hq; Fri, 18 Nov 2011 13:13:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RROFr-0004jb-67
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:13:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1321621974!4769146!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24714 invoked from network); 18 Nov 2011 13:12:55 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:12:55 -0000
Received: by yenl7 with SMTP id l7so3646488yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 05:12:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LklRn6d7mJc3XcOPCKfbf1OhP/PcX/8p/i86VrxO/ao=;
	b=dz06CufL1TBleCFy3Nc9HVD+wUg6TWqzLAHY3aayMUpgmoES0Sk+J3CJ07V+SVCCog
	omVVGFvdU+Glo4UnsljUj/AtYfKQY48ViaWWa6tAN8+etdMur/jEap0ow4yXqTk6wOwr
	M5tI652TuFTIMxq4079CCpzP8WENZpt6tt5G8=
Received: by 10.182.21.134 with SMTP id v6mr675469obe.64.1321621972666;
	Fri, 18 Nov 2011 05:12:52 -0800 (PST)
Received: from [192.168.1.151] ([198.162.52.244])
	by mx.google.com with ESMTPS id y4sm204623obj.10.2011.11.18.05.12.49
	(version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 05:12:51 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 18 Nov 2011 13:12:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paul Durrant <Paul.Durrant@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CAEC0A4B.25205%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] Add configuration options to
	selectively disable S3 and S4 ACPI power states
Thread-Index: Acyl3pqYjddMj3rUSzS16TqxbCsgEAAA88ewAARV9+U=
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B4543AB75A@LONPMAILBOX01.citrite.net>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
 selectively disable S3 and S4 ACPI power states
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/11/2011 11:11, "Paul Durrant" <Paul.Durrant@citrix.com> wrote:

>> -----Original Message-----
>> From: Ian Campbell
>> Sent: 18 November 2011 10:41
>> To: Paul Durrant
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH 2 of 2] Add configuration options to
>> selectively disable S3 and S4 ACPI power states
>> 
>> On Fri, 2011-11-18 at 10:29 +0000, Paul Durrant wrote:
>>> diff -r d22ef0f60497 -r 66bdcb90560f
>> tools/firmware/hvmloader/hvmloader.c
>>> --- a/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18
>> 10:28:52 2011 +0000
>>> +++ b/tools/firmware/hvmloader/hvmloader.c      Fri Nov 18
>> 10:28:53 2011 +0000
>>> @@ -516,11 +516,17 @@ int main(void)
>>>              .index = HVM_PARAM_ACPI_IOPORTS_LOCATION,
>>>              .value = 1,
>>>          };
>>> +        int s3_enabled, s4_enabled;
>>> +
>>> +        s3_enabled = !strncmp(xenstore_read("platform/acpi_s3",
>> "1"), "1", 1);
>>> +        s4_enabled = !strncmp(xenstore_read("platform/acpi_s4",
>> "1"),
>>> + "1", 1);
>> 
>> Is it not possible to do these in the underlying acpi_build_tables
>> and avoid the need to plumb them right the way through?
>> 
> 
> I guess that would be possible. It just seemed logical to group the acpi
> config xenstore reads close together. If we're happy to distribute use of the
> xenstore client code to all corners of the source then I can certainly do
> that.

I think distributing the xenstore reads is fine. I will apply the final
patch series that you sent, that includes this change.

 -- Keir

>>>          if ( bios->acpi_build_tables )
>>>          {
>>> -            printf("Loading ACPI ...\n");
>>> -            bios->acpi_build_tables();
>>> +            printf("Loading ACPI (S3=%s S4=%s) ...\n",
>>> +                   (s3_enabled) ? "ON" : "OFF",
>>> +                   (s4_enabled) ? "ON" : "OFF");
>> 
>> If possible this printf could also be pushed down so you can
>> continue to print the config info.
>> 
> 
> Well, if the xenstore reads are pushed down then I'd clearly need to do that
> too :-)
> 
>>> +            bios->acpi_build_tables(s3_enabled, s4_enabled);
>>>          }
>>> 
>>>          acpi_enable_sci();
>> 
>> Ian.
>> 
> 
>   Paul
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:16:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:16:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROI0-0004of-1R; Fri, 18 Nov 2011 13:15:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RROHz-0004oJ-Fc
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:15:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1321622107!3685448!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13970 invoked from network); 18 Nov 2011 13:15:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 13:15:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 18 Nov 2011 13:15:06 +0000
Message-Id: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 18 Nov 2011 13:15:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF1DE744B.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

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

--- a/drivers/xen/netback/netback.c
+++ b/drivers/xen/netback/netback.c
@@ -1155,7 +1155,7 @@ static int netbk_tx_check_mop(struct sk_
 		pending_idx =3D *((u16 *)skb->data);
 		netif_idx_release(pending_idx);
 		for (j =3D start; j < i; j++) {
-			pending_idx =3D (unsigned long)shinfo->frags[i].pag=
e;
+			pending_idx =3D (unsigned long)shinfo->frags[j].pag=
e;
 			netif_idx_release(pending_idx);
 		}
=20




--=__PartF1DE744B.0__=
Content-Type: text/plain; name="xen-netback-check_mop-error.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-netback-check_mop-error.patch"

netback: use correct index for invalidation in netbk_tx_check_mop()=0A=0ASi=
gned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/netback=
/netback.c=0A+++ b/drivers/xen/netback/netback.c=0A@@ -1155,7 +1155,7 @@ =
static int netbk_tx_check_mop(struct sk_=0A 		pending_idx =3D =
*((u16 *)skb->data);=0A 		netif_idx_release(pending_idx);=0A =
		for (j =3D start; j < i; j++) {=0A-			=
pending_idx =3D (unsigned long)shinfo->frags[i].page;=0A+			=
pending_idx =3D (unsigned long)shinfo->frags[j].page;=0A 			=
netif_idx_release(pending_idx);=0A 		}=0A =0A
--=__PartF1DE744B.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__PartF1DE744B.0__=--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:16:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:16:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROI0-0004of-1R; Fri, 18 Nov 2011 13:15:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RROHz-0004oJ-Fc
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:15:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1321622107!3685448!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13970 invoked from network); 18 Nov 2011 13:15:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 13:15:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 18 Nov 2011 13:15:06 +0000
Message-Id: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 18 Nov 2011 13:15:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF1DE744B.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

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

--- a/drivers/xen/netback/netback.c
+++ b/drivers/xen/netback/netback.c
@@ -1155,7 +1155,7 @@ static int netbk_tx_check_mop(struct sk_
 		pending_idx =3D *((u16 *)skb->data);
 		netif_idx_release(pending_idx);
 		for (j =3D start; j < i; j++) {
-			pending_idx =3D (unsigned long)shinfo->frags[i].pag=
e;
+			pending_idx =3D (unsigned long)shinfo->frags[j].pag=
e;
 			netif_idx_release(pending_idx);
 		}
=20




--=__PartF1DE744B.0__=
Content-Type: text/plain; name="xen-netback-check_mop-error.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-netback-check_mop-error.patch"

netback: use correct index for invalidation in netbk_tx_check_mop()=0A=0ASi=
gned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/netback=
/netback.c=0A+++ b/drivers/xen/netback/netback.c=0A@@ -1155,7 +1155,7 @@ =
static int netbk_tx_check_mop(struct sk_=0A 		pending_idx =3D =
*((u16 *)skb->data);=0A 		netif_idx_release(pending_idx);=0A =
		for (j =3D start; j < i; j++) {=0A-			=
pending_idx =3D (unsigned long)shinfo->frags[i].page;=0A+			=
pending_idx =3D (unsigned long)shinfo->frags[j].page;=0A 			=
netif_idx_release(pending_idx);=0A 		}=0A =0A
--=__PartF1DE744B.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__PartF1DE744B.0__=--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:26:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROS5-0005OH-33; Fri, 18 Nov 2011 13:25:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RROS3-0005O5-Sx
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:25:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321622731!4081456!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19382 invoked from network); 18 Nov 2011 13:25:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 13:25:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 18 Nov 2011 13:25:31 +0000
Message-Id: <4EC66ADB0200007800061D74@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 18 Nov 2011 13:25:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>
References: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
In-Reply-To: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 18.11.11 at 14:15, "Jan Beulich" <JBeulich@suse.com> wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/drivers/xen/netback/netback.c
> +++ b/drivers/xen/netback/netback.c
> @@ -1155,7 +1155,7 @@ static int netbk_tx_check_mop(struct sk_
>  		pending_idx = *((u16 *)skb->data);
>  		netif_idx_release(pending_idx);
>  		for (j = start; j < i; j++) {
> -			pending_idx = (unsigned long)shinfo->frags[i].page;
> +			pending_idx = (unsigned long)shinfo->frags[j].page;
>  			netif_idx_release(pending_idx);
>  		}
>  

I'm sure you want to apply the equivalent to xen-netback to (there
it is in function xen_netbk_tx_check_gop()).

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:26:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROS5-0005OH-33; Fri, 18 Nov 2011 13:25:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RROS3-0005O5-Sx
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:25:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321622731!4081456!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19382 invoked from network); 18 Nov 2011 13:25:32 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 13:25:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 18 Nov 2011 13:25:31 +0000
Message-Id: <4EC66ADB0200007800061D74@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 18 Nov 2011 13:25:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@eu.citrix.com>
References: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
In-Reply-To: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 18.11.11 at 14:15, "Jan Beulich" <JBeulich@suse.com> wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/drivers/xen/netback/netback.c
> +++ b/drivers/xen/netback/netback.c
> @@ -1155,7 +1155,7 @@ static int netbk_tx_check_mop(struct sk_
>  		pending_idx = *((u16 *)skb->data);
>  		netif_idx_release(pending_idx);
>  		for (j = start; j < i; j++) {
> -			pending_idx = (unsigned long)shinfo->frags[i].page;
> +			pending_idx = (unsigned long)shinfo->frags[j].page;
>  			netif_idx_release(pending_idx);
>  		}
>  

I'm sure you want to apply the equivalent to xen-netback to (there
it is in function xen_netbk_tx_check_gop()).

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:28:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROUR-0005UQ-LR; Fri, 18 Nov 2011 13:28:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RROUP-0005U9-Re
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:28:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1321622877!3670571!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25757 invoked from network); 18 Nov 2011 13:27:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:27:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9010527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:27:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 13:27:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 13:27:57 +0000
In-Reply-To: <9e8abd626484f82a95d0.1321617578@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<9e8abd626484f82a95d0.1321617578@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321622877.3664.344.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 9 v2] libxl: add support for image
 files for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1317386335 -7200
> # Node ID 9e8abd626484f82a95d0edc07834ae287bc9467a
> # Parent  23578c9942bcc8767adc4e435bb1fd1cd89f5e18
> libxl: add support for image files for NetBSD
> 
> Created a helper function to detect if the OS is capable of using
> image files as phy backends. Create two OS specific files, and
> changed the Makefile to choose the correct one at compile time.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
> +++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
> @@ -32,6 +32,12 @@ endif
>  LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
>  LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
>  
> +ifeq ($(CONFIG_NetBSD),y)
> +LIBXL_OBJS-y += libxl_phybackend.o
> +else
> +LIBXL_OBJS-y += libxl_nophybackend.o

phy vs nophy don't really make sense to me here, since in both cases the
content relates to the phy backend.

Perhaps we need libxl_$(OS).c to contain os specific stuff?

> +endif
> +
>  LIBXL_LIBS += -lyajl
>  
>  LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
> diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
> +++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
> @@ -138,15 +138,14 @@ static int disk_try_backend(disk_try_bac
>                a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
>              goto bad_format;
>          }
> -        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
> -            !S_ISBLK(a->stab.st_mode)) {
> -            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
> -                       " unsuitable as phys path not a block device",
> -                       a->disk->vdev);
> -            return 0;
> -        }
>  
> -        return backend;
> +        if (libxl__try_phy_backend(a->stab.st_mode))
> +            return backend;
> +
> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
> +                   " unsuitable as phys path not a block device",
> +                   a->disk->vdev);
> +        return 0;
>  
>      case LIBXL_DISK_BACKEND_TAP:
>          if (!libxl__blktap_enabled(a->gc)) {
> diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
> +++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
> @@ -252,6 +252,15 @@ _hidden int libxl__device_destroy(libxl_
>  _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
>  _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
>  
> +/*
> + * libxl__try_phy_backend - Check if there's support for the passed
> + * type of file using the PHY backend
> + * st_mode: mode_t of the file, as returned by stat function
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__try_phy_backend(mode_t st_mode);
> +
>  /* from libxl_pci */
>  
>  _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
> diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_nophybackend.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxl/libxl_nophybackend.c	Fri Sep 30 14:38:55 2011 +0200
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (C) 2011
> + * Author Roger Pau Monne <roger.pau@entel.upc.edu>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> + 
> +#include <sys/stat.h>
> +
> +#include "libxl_internal.h"
> + 
> +int libxl__try_phy_backend(mode_t st_mode)
> +{
> +    if (!S_ISBLK(st_mode)) {
> +        return 0;
> +    }
> +
> +    return 1;
> +}
> diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_phybackend.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxl/libxl_phybackend.c	Fri Sep 30 14:38:55 2011 +0200
> @@ -0,0 +1,26 @@
> +/*
> + * Copyright (C) 2011
> + * Author Roger Pau Monne <roger.pau@entel.upc.edu>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> + 
> +#include <sys/stat.h>
> +
> +#include "libxl_internal.h"
> + 
> +int libxl__try_phy_backend(mode_t st_mode)
> +{
> +    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
> +        return 1;
> +
> +    return 0;
> +}
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:28:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROUR-0005UQ-LR; Fri, 18 Nov 2011 13:28:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RROUP-0005U9-Re
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:28:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1321622877!3670571!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25757 invoked from network); 18 Nov 2011 13:27:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:27:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9010527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:27:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 13:27:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 13:27:57 +0000
In-Reply-To: <9e8abd626484f82a95d0.1321617578@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<9e8abd626484f82a95d0.1321617578@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321622877.3664.344.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 9 v2] libxl: add support for image
 files for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1317386335 -7200
> # Node ID 9e8abd626484f82a95d0edc07834ae287bc9467a
> # Parent  23578c9942bcc8767adc4e435bb1fd1cd89f5e18
> libxl: add support for image files for NetBSD
> 
> Created a helper function to detect if the OS is capable of using
> image files as phy backends. Create two OS specific files, and
> changed the Makefile to choose the correct one at compile time.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
> +++ b/tools/libxl/Makefile	Fri Sep 30 14:38:55 2011 +0200
> @@ -32,6 +32,12 @@ endif
>  LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o
>  LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpuid.o
>  
> +ifeq ($(CONFIG_NetBSD),y)
> +LIBXL_OBJS-y += libxl_phybackend.o
> +else
> +LIBXL_OBJS-y += libxl_nophybackend.o

phy vs nophy don't really make sense to me here, since in both cases the
content relates to the phy backend.

Perhaps we need libxl_$(OS).c to contain os specific stuff?

> +endif
> +
>  LIBXL_LIBS += -lyajl
>  
>  LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
> diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
> +++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
> @@ -138,15 +138,14 @@ static int disk_try_backend(disk_try_bac
>                a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
>              goto bad_format;
>          }
> -        if (a->disk->format != LIBXL_DISK_FORMAT_EMPTY &&
> -            !S_ISBLK(a->stab.st_mode)) {
> -            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
> -                       " unsuitable as phys path not a block device",
> -                       a->disk->vdev);
> -            return 0;
> -        }
>  
> -        return backend;
> +        if (libxl__try_phy_backend(a->stab.st_mode))
> +            return backend;
> +
> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
> +                   " unsuitable as phys path not a block device",
> +                   a->disk->vdev);
> +        return 0;
>  
>      case LIBXL_DISK_BACKEND_TAP:
>          if (!libxl__blktap_enabled(a->gc)) {
> diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
> +++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
> @@ -252,6 +252,15 @@ _hidden int libxl__device_destroy(libxl_
>  _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
>  _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
>  
> +/*
> + * libxl__try_phy_backend - Check if there's support for the passed
> + * type of file using the PHY backend
> + * st_mode: mode_t of the file, as returned by stat function
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__try_phy_backend(mode_t st_mode);
> +
>  /* from libxl_pci */
>  
>  _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
> diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_nophybackend.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxl/libxl_nophybackend.c	Fri Sep 30 14:38:55 2011 +0200
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (C) 2011
> + * Author Roger Pau Monne <roger.pau@entel.upc.edu>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> + 
> +#include <sys/stat.h>
> +
> +#include "libxl_internal.h"
> + 
> +int libxl__try_phy_backend(mode_t st_mode)
> +{
> +    if (!S_ISBLK(st_mode)) {
> +        return 0;
> +    }
> +
> +    return 1;
> +}
> diff -r 23578c9942bc -r 9e8abd626484 tools/libxl/libxl_phybackend.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/libxl/libxl_phybackend.c	Fri Sep 30 14:38:55 2011 +0200
> @@ -0,0 +1,26 @@
> +/*
> + * Copyright (C) 2011
> + * Author Roger Pau Monne <roger.pau@entel.upc.edu>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> + 
> +#include <sys/stat.h>
> +
> +#include "libxl_internal.h"
> + 
> +int libxl__try_phy_backend(mode_t st_mode)
> +{
> +    if (S_ISREG(st_mode) || S_ISBLK(st_mode))
> +        return 1;
> +
> +    return 0;
> +}
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:32:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROXt-0005hA-Fp; Fri, 18 Nov 2011 13:31:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RROXr-0005gh-Vu
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:31:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321623091!4747785!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19110 invoked from network); 18 Nov 2011 13:31:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:31:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9010598"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:31:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 13:31:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 13:31:06 +0000
In-Reply-To: <ec94a7e4983ad6338db2.1321617579@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<ec94a7e4983ad6338db2.1321617579@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321623067.3664.346.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec
 function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1321609614 -3600
> # Node ID ec94a7e4983ad6338db20fa0777a85507b582607
> # Parent  9e8abd626484f82a95d0edc07834ae287bc9467a
> libxl: add libxl__forkexec function to libxl_exec
> 
> Add a new function to libxl_exec that performs a fork and executes
> the passed arguments using libxl__exec.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 9e8abd626484 -r ec94a7e4983a tools/libxl/libxl_exec.c
> --- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
> +++ b/tools/libxl/libxl_exec.c	Fri Nov 18 10:46:54 2011 +0100
> @@ -450,6 +450,40 @@ int libxl__spawn_check(libxl__gc *gc, li
>      return ERROR_FAIL;
>  }
>  
> +int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
> +                    int stderrfd, char **args)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    int status;
> +    int rc = 0;
> +    pid_t pid = fork();
> +
> +    switch (pid) {
> +    case -1:
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
> +        rc = -1;
> +        break;
> +    case 0:
> +        libxl__exec(stdinfd, stdoutfd, stderrfd, args[0], args);
> +        /* libxl__exec never returns */
> +    default:
> +        while (waitpid(pid, &status, 0) < 0) {
> +            if (errno != EINTR) {
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "waitpid failed\n");
> +                rc = -1;
> +                break;
> +            }
> +        }
> +        if (WIFEXITED(status)) {
> +            rc = WEXITSTATUS(status);
> +        } else {
> +            rc = -1;
> +        }
> +        break;
> +    }
> +    return rc;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff -r 9e8abd626484 -r ec94a7e4983a tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
> +++ b/tools/libxl/libxl_internal.h	Fri Nov 18 10:46:54 2011 +0100
> @@ -400,6 +400,20 @@ _hidden int libxl__spawn_check(libxl__gc
>  _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
>                 const char *arg0, char **args); // logs errors, never returns
>  
> +/*
> + * libxl__forkexec - Executes a file synchronously
> + * gc: allocation pool
> + * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
> + * args: file to execute and arguments to pass in the following format
> + *      args[0]: file to execute
> + *      args[1]: first argument to pass to the called program
> + *      args[n]: nth argument to pass to the called program

args[n] must be NULL, right?

> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
> +                            int stderrfd, char **args);
> +
>  /* from xl_create */
>  _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
>  _hidden int libxl__domain_build(libxl__gc *gc,
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:32:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROXt-0005hA-Fp; Fri, 18 Nov 2011 13:31:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RROXr-0005gh-Vu
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:31:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321623091!4747785!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19110 invoked from network); 18 Nov 2011 13:31:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:31:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9010598"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:31:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 13:31:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 13:31:06 +0000
In-Reply-To: <ec94a7e4983ad6338db2.1321617579@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<ec94a7e4983ad6338db2.1321617579@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321623067.3664.346.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec
 function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1321609614 -3600
> # Node ID ec94a7e4983ad6338db20fa0777a85507b582607
> # Parent  9e8abd626484f82a95d0edc07834ae287bc9467a
> libxl: add libxl__forkexec function to libxl_exec
> 
> Add a new function to libxl_exec that performs a fork and executes
> the passed arguments using libxl__exec.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 9e8abd626484 -r ec94a7e4983a tools/libxl/libxl_exec.c
> --- a/tools/libxl/libxl_exec.c	Fri Sep 30 14:38:55 2011 +0200
> +++ b/tools/libxl/libxl_exec.c	Fri Nov 18 10:46:54 2011 +0100
> @@ -450,6 +450,40 @@ int libxl__spawn_check(libxl__gc *gc, li
>      return ERROR_FAIL;
>  }
>  
> +int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
> +                    int stderrfd, char **args)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    int status;
> +    int rc = 0;
> +    pid_t pid = fork();
> +
> +    switch (pid) {
> +    case -1:
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
> +        rc = -1;
> +        break;
> +    case 0:
> +        libxl__exec(stdinfd, stdoutfd, stderrfd, args[0], args);
> +        /* libxl__exec never returns */
> +    default:
> +        while (waitpid(pid, &status, 0) < 0) {
> +            if (errno != EINTR) {
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "waitpid failed\n");
> +                rc = -1;
> +                break;
> +            }
> +        }
> +        if (WIFEXITED(status)) {
> +            rc = WEXITSTATUS(status);
> +        } else {
> +            rc = -1;
> +        }
> +        break;
> +    }
> +    return rc;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff -r 9e8abd626484 -r ec94a7e4983a tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
> +++ b/tools/libxl/libxl_internal.h	Fri Nov 18 10:46:54 2011 +0100
> @@ -400,6 +400,20 @@ _hidden int libxl__spawn_check(libxl__gc
>  _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
>                 const char *arg0, char **args); // logs errors, never returns
>  
> +/*
> + * libxl__forkexec - Executes a file synchronously
> + * gc: allocation pool
> + * stdinfd, stdoutfd, stderrfd: fds to pass to libxl__exec
> + * args: file to execute and arguments to pass in the following format
> + *      args[0]: file to execute
> + *      args[1]: first argument to pass to the called program
> + *      args[n]: nth argument to pass to the called program

args[n] must be NULL, right?

> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
> +                            int stderrfd, char **args);
> +
>  /* from xl_create */
>  _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
>  _hidden int libxl__domain_build(libxl__gc *gc,
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROab-0005tC-CX; Fri, 18 Nov 2011 13:34:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RROaZ-0005ss-Pc
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:34:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321623259!4079633!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12086 invoked from network); 18 Nov 2011 13:34:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:34:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9010773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:34:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 13:34:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 13:34:18 +0000
In-Reply-To: <a77bba3717402fdf24a7.1321617580@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<a77bba3717402fdf24a7.1321617580@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321623259.3664.347.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 9 v2] libxl: introduce
 libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1321609740 -3600
> # Node ID a77bba3717402fdf24a72d028ae0f3d482e6f427
> # Parent  ec94a7e4983ad6338db20fa0777a85507b582607
> libxl: introduce libxl__wait_for_device_state
> 
> This is a generic function, that waits for xs watches to reach a
> certain state and then executes the passed helper function. Removed
> wait_for_dev_destroy and used this new function instead. This
> function will also be used by future patches that need to wait for
> the initialization of devices before executing hotplug scripts.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

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

> diff -r ec94a7e4983a -r a77bba371740 tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c	Fri Nov 18 10:46:54 2011 +0100
> +++ b/tools/libxl/libxl_device.c	Fri Nov 18 10:49:00 2011 +0100
> @@ -370,7 +370,9 @@ int libxl__device_disk_dev_number(const 
>   * Returns 0 if a device is removed, ERROR_* if an error
>   * or timeout occurred.
>   */
> -static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
> +int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
> +                                 int state,
> +                                 libxl__device_state_handler handler)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int nfds, rc;
> @@ -395,17 +397,14 @@ start:
>          default:
>              l1 = xs_read_watch(ctx->xsh, &n);
>              if (l1 != NULL) {
> -                char *state = libxl__xs_read(gc, XBT_NULL,
> +                char *sstate = libxl__xs_read(gc, XBT_NULL,
>                                               l1[XS_WATCH_PATH]);
> -                if (!state || atoi(state) == 6) {
> -                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
> -                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
> -                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> -                               "Destroyed device backend at %s",
> -                               l1[XS_WATCH_TOKEN]);
> -                    rc = 0;
> +                if (!sstate || atoi(sstate) == state) {
> +                    /* Call handler function if present */
> +                    if (handler)
> +                        rc = handler(gc, l1, sstate);
>                  } else {
> -                    /* State is not "disconnected", continue waiting... */
> +                    /* State is different than expected, continue waiting... */
>                      goto start;
>                  }
>                  free(l1);
> @@ -418,6 +417,23 @@ start:
>  }
>  
>  /*
> + * Handler function for device destruction to be passed to
> + * libxl__wait_for_device_state
> + */
> +static int destroy_device(libxl__gc *gc, char **l1, char *state)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +
> +    xs_unwatch(ctx->xsh, l1[0], l1[1]);
> +    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +               "Destroyed device backend at %s",
> +               l1[XS_WATCH_TOKEN]);
> +
> +    return 0;
> +}
> +
> +/*
>   * Returns 0 (device already destroyed) or 1 (caller must
>   * wait_for_dev_destroy) on success, ERROR_* on fail.
>   */
> @@ -458,7 +474,7 @@ retry_transaction:
>          struct timeval tv;
>          tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
>          tv.tv_usec = 0;
> -        rc = wait_for_dev_destroy(gc, &tv);
> +        rc = libxl__wait_for_device_state(gc, &tv, 6, destroy_device);
>          if (rc < 0) /* an error or timeout occurred, clear watches */
>              xs_unwatch(ctx->xsh, state_path, be_path);
>          xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
> @@ -566,7 +582,7 @@ int libxl__devices_destroy(libxl__gc *gc
>          tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
>          tv.tv_usec = 0;
>          while (n_watches > 0) {
> -            if (wait_for_dev_destroy(gc, &tv) < 0) {
> +            if (libxl__wait_for_device_state(gc, &tv, 6, destroy_device) < 0) {
>                  /* function returned ERROR_* */
>                  break;
>              } else {
> diff -r ec94a7e4983a -r a77bba371740 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Fri Nov 18 10:46:54 2011 +0100
> +++ b/tools/libxl/libxl_internal.h	Fri Nov 18 10:49:00 2011 +0100
> @@ -20,6 +20,7 @@
>  #include <stdint.h>
>  #include <stdarg.h>
>  #include <stdlib.h>
> +#include <sys/time.h>
>  
>  #include <xs.h>
>  #include <xenctrl.h>
> @@ -252,6 +253,31 @@ _hidden int libxl__device_destroy(libxl_
>  _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
>  _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
>  
> +/* Handler for the libxl__wait_for_device_state callback */
> +/*
> + * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
> + * gc: allocation pool
> + * l1: array containing the path and token
> + * state: string that contains the state of the device
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
> +
> +/*
> + * libxl__wait_for_device_state - waits a given time for a device to
> + * reach a given state
> + * gc: allocation pool
> + * tv: timeval struct containing the maximum time to wait
> + * state: state to wait for
> + * handler: callback function to execute when state is reached
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
> +                                         int state,
> +                                         libxl__device_state_handler handler);
> +
>  /*
>   * libxl__try_phy_backend - Check if there's support for the passed
>   * type of file using the PHY backend
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROab-0005tC-CX; Fri, 18 Nov 2011 13:34:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RROaZ-0005ss-Pc
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:34:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321623259!4079633!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12086 invoked from network); 18 Nov 2011 13:34:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:34:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9010773"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:34:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 13:34:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 13:34:18 +0000
In-Reply-To: <a77bba3717402fdf24a7.1321617580@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<a77bba3717402fdf24a7.1321617580@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321623259.3664.347.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 9 v2] libxl: introduce
 libxl__wait_for_device_state
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1321609740 -3600
> # Node ID a77bba3717402fdf24a72d028ae0f3d482e6f427
> # Parent  ec94a7e4983ad6338db20fa0777a85507b582607
> libxl: introduce libxl__wait_for_device_state
> 
> This is a generic function, that waits for xs watches to reach a
> certain state and then executes the passed helper function. Removed
> wait_for_dev_destroy and used this new function instead. This
> function will also be used by future patches that need to wait for
> the initialization of devices before executing hotplug scripts.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

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

> diff -r ec94a7e4983a -r a77bba371740 tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c	Fri Nov 18 10:46:54 2011 +0100
> +++ b/tools/libxl/libxl_device.c	Fri Nov 18 10:49:00 2011 +0100
> @@ -370,7 +370,9 @@ int libxl__device_disk_dev_number(const 
>   * Returns 0 if a device is removed, ERROR_* if an error
>   * or timeout occurred.
>   */
> -static int wait_for_dev_destroy(libxl__gc *gc, struct timeval *tv)
> +int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
> +                                 int state,
> +                                 libxl__device_state_handler handler)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int nfds, rc;
> @@ -395,17 +397,14 @@ start:
>          default:
>              l1 = xs_read_watch(ctx->xsh, &n);
>              if (l1 != NULL) {
> -                char *state = libxl__xs_read(gc, XBT_NULL,
> +                char *sstate = libxl__xs_read(gc, XBT_NULL,
>                                               l1[XS_WATCH_PATH]);
> -                if (!state || atoi(state) == 6) {
> -                    xs_unwatch(ctx->xsh, l1[0], l1[1]);
> -                    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
> -                    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> -                               "Destroyed device backend at %s",
> -                               l1[XS_WATCH_TOKEN]);
> -                    rc = 0;
> +                if (!sstate || atoi(sstate) == state) {
> +                    /* Call handler function if present */
> +                    if (handler)
> +                        rc = handler(gc, l1, sstate);
>                  } else {
> -                    /* State is not "disconnected", continue waiting... */
> +                    /* State is different than expected, continue waiting... */
>                      goto start;
>                  }
>                  free(l1);
> @@ -418,6 +417,23 @@ start:
>  }
>  
>  /*
> + * Handler function for device destruction to be passed to
> + * libxl__wait_for_device_state
> + */
> +static int destroy_device(libxl__gc *gc, char **l1, char *state)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +
> +    xs_unwatch(ctx->xsh, l1[0], l1[1]);
> +    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +               "Destroyed device backend at %s",
> +               l1[XS_WATCH_TOKEN]);
> +
> +    return 0;
> +}
> +
> +/*
>   * Returns 0 (device already destroyed) or 1 (caller must
>   * wait_for_dev_destroy) on success, ERROR_* on fail.
>   */
> @@ -458,7 +474,7 @@ retry_transaction:
>          struct timeval tv;
>          tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
>          tv.tv_usec = 0;
> -        rc = wait_for_dev_destroy(gc, &tv);
> +        rc = libxl__wait_for_device_state(gc, &tv, 6, destroy_device);
>          if (rc < 0) /* an error or timeout occurred, clear watches */
>              xs_unwatch(ctx->xsh, state_path, be_path);
>          xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
> @@ -566,7 +582,7 @@ int libxl__devices_destroy(libxl__gc *gc
>          tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
>          tv.tv_usec = 0;
>          while (n_watches > 0) {
> -            if (wait_for_dev_destroy(gc, &tv) < 0) {
> +            if (libxl__wait_for_device_state(gc, &tv, 6, destroy_device) < 0) {
>                  /* function returned ERROR_* */
>                  break;
>              } else {
> diff -r ec94a7e4983a -r a77bba371740 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Fri Nov 18 10:46:54 2011 +0100
> +++ b/tools/libxl/libxl_internal.h	Fri Nov 18 10:49:00 2011 +0100
> @@ -20,6 +20,7 @@
>  #include <stdint.h>
>  #include <stdarg.h>
>  #include <stdlib.h>
> +#include <sys/time.h>
>  
>  #include <xs.h>
>  #include <xenctrl.h>
> @@ -252,6 +253,31 @@ _hidden int libxl__device_destroy(libxl_
>  _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid, int force);
>  _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
>  
> +/* Handler for the libxl__wait_for_device_state callback */
> +/*
> + * libxl__device_state_handler - Handler for the libxl__wait_for_device_state
> + * gc: allocation pool
> + * l1: array containing the path and token
> + * state: string that contains the state of the device
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +typedef int libxl__device_state_handler(libxl__gc *gc, char **l1, char *state);
> +
> +/*
> + * libxl__wait_for_device_state - waits a given time for a device to
> + * reach a given state
> + * gc: allocation pool
> + * tv: timeval struct containing the maximum time to wait
> + * state: state to wait for
> + * handler: callback function to execute when state is reached
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
> +                                         int state,
> +                                         libxl__device_state_handler handler);
> +
>  /*
>   * libxl__try_phy_backend - Check if there's support for the passed
>   * type of file using the PHY backend
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:39:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROea-000678-2S; Fri, 18 Nov 2011 13:38:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RROeY-000670-JQ
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:38:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321623408!52764348!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8958 invoked from network); 18 Nov 2011 13:36:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:36:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9010881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:38: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.137.0;
	Fri, 18 Nov 2011 13:38:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 13:38:31 +0000
In-Reply-To: <4ad998fddb16a299cb23.1321617581@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<4ad998fddb16a299cb23.1321617581@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321623511.3664.349.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 9 v2] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1321612154 -3600
> # Node ID 4ad998fddb16a299cb230ea23ba944d84adbd2bf
> # Parent  a77bba3717402fdf24a72d028ae0f3d482e6f427
> libxl: wait for devices to initialize upon addition to the domain.
> 
> Block waiting for devices to initialize (switch to state 2). This is
> necessary because we need to call the hotplug scripts when state is
> 2, otherwise the execution fails. Make use of the newly introduced
> function libxl__wait_for_device_state.

It would be better to use the XenbusStateFoo constants than the numbers.
This also applies to the prviosu patch, I just didn't think of it...

Otherwise this looks good.

I'm a little concerned about the synchronous wait here (since it will
serialise adding all devices). Eventually it should be possible to do
all the adds and then wait for them all but this is dependent on the
event infrastructure.

> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r a77bba371740 -r 4ad998fddb16 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Fri Nov 18 10:49:00 2011 +0100
> +++ b/tools/libxl/libxl.c	Fri Nov 18 11:29:14 2011 +0100
> @@ -971,6 +971,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
>      flexarray_t *front;
>      flexarray_t *back;
>      char *dev;
> +    char *be_path, *state_path, *state;
> +    struct timeval tv;
>      libxl__device device;
>      int major, minor, rc;
>  
> @@ -1075,6 +1077,23 @@ int libxl_device_disk_add(libxl_ctx *ctx
>                               libxl__xs_kvs_of_flexarray(&gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(&gc, front, front->count));
>  
> +    be_path = libxl__device_backend_path(&gc, &device);
> +    state_path = libxl__sprintf(&gc, "%s/state", be_path);
> +    state = libxl__xs_read(&gc, XBT_NULL, state_path);
> +
> +    if (atoi(state) != 2) {
> +        xs_watch(ctx->xsh, state_path, be_path);
> +        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
> +        tv.tv_usec = 0;
> +        rc = libxl__wait_for_device_state(&gc, &tv, 2, NULL);
> +        xs_unwatch(ctx->xsh, state_path, be_path);
> +        if (rc < 0) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "unable to initialize disk device: %s\n",
> +                       disk->pdev_path);
> +            goto out_free;
> +        }
> +    }
>      rc = 0;
>  
>  out_free:
> @@ -1450,6 +1469,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
>      flexarray_t *back;
>      libxl__device device;
>      char *dompath, **l;
> +    char *be_path, *state_path, *state;
> +    struct timeval tv;
>      unsigned int nb, rc;
>  
>      front = flexarray_make(16, 1);
> @@ -1518,8 +1539,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
>                               libxl__xs_kvs_of_flexarray(&gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(&gc, front, front->count));
>  
> -    /* FIXME: wait for plug */
> +    be_path = libxl__device_backend_path(&gc, &device);
> +    state_path = libxl__sprintf(&gc, "%s/state", be_path);
> +    state = libxl__xs_read(&gc, XBT_NULL, state_path);
> +
> +    if (atoi(state) != 2) {
> +        xs_watch(ctx->xsh, state_path, be_path);
> +        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
> +        tv.tv_usec = 0;
> +        rc = libxl__wait_for_device_state(&gc, &tv, 2, NULL);
> +        xs_unwatch(ctx->xsh, state_path, be_path);
> +        if (rc < 0) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "unable to initialize nic device: %s\n",
> +                       nic->ifname);
> +            goto out_free;
> +        }
> +    }
>      rc = 0;
> +
>  out_free:
>      flexarray_free(back);
>      flexarray_free(front);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:39:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROea-000678-2S; Fri, 18 Nov 2011 13:38:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RROeY-000670-JQ
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:38:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321623408!52764348!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8958 invoked from network); 18 Nov 2011 13:36:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:36:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9010881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:38: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.137.0;
	Fri, 18 Nov 2011 13:38:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 13:38:31 +0000
In-Reply-To: <4ad998fddb16a299cb23.1321617581@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<4ad998fddb16a299cb23.1321617581@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321623511.3664.349.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 9 v2] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1321612154 -3600
> # Node ID 4ad998fddb16a299cb230ea23ba944d84adbd2bf
> # Parent  a77bba3717402fdf24a72d028ae0f3d482e6f427
> libxl: wait for devices to initialize upon addition to the domain.
> 
> Block waiting for devices to initialize (switch to state 2). This is
> necessary because we need to call the hotplug scripts when state is
> 2, otherwise the execution fails. Make use of the newly introduced
> function libxl__wait_for_device_state.

It would be better to use the XenbusStateFoo constants than the numbers.
This also applies to the prviosu patch, I just didn't think of it...

Otherwise this looks good.

I'm a little concerned about the synchronous wait here (since it will
serialise adding all devices). Eventually it should be possible to do
all the adds and then wait for them all but this is dependent on the
event infrastructure.

> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r a77bba371740 -r 4ad998fddb16 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Fri Nov 18 10:49:00 2011 +0100
> +++ b/tools/libxl/libxl.c	Fri Nov 18 11:29:14 2011 +0100
> @@ -971,6 +971,8 @@ int libxl_device_disk_add(libxl_ctx *ctx
>      flexarray_t *front;
>      flexarray_t *back;
>      char *dev;
> +    char *be_path, *state_path, *state;
> +    struct timeval tv;
>      libxl__device device;
>      int major, minor, rc;
>  
> @@ -1075,6 +1077,23 @@ int libxl_device_disk_add(libxl_ctx *ctx
>                               libxl__xs_kvs_of_flexarray(&gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(&gc, front, front->count));
>  
> +    be_path = libxl__device_backend_path(&gc, &device);
> +    state_path = libxl__sprintf(&gc, "%s/state", be_path);
> +    state = libxl__xs_read(&gc, XBT_NULL, state_path);
> +
> +    if (atoi(state) != 2) {
> +        xs_watch(ctx->xsh, state_path, be_path);
> +        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
> +        tv.tv_usec = 0;
> +        rc = libxl__wait_for_device_state(&gc, &tv, 2, NULL);
> +        xs_unwatch(ctx->xsh, state_path, be_path);
> +        if (rc < 0) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "unable to initialize disk device: %s\n",
> +                       disk->pdev_path);
> +            goto out_free;
> +        }
> +    }
>      rc = 0;
>  
>  out_free:
> @@ -1450,6 +1469,8 @@ int libxl_device_nic_add(libxl_ctx *ctx,
>      flexarray_t *back;
>      libxl__device device;
>      char *dompath, **l;
> +    char *be_path, *state_path, *state;
> +    struct timeval tv;
>      unsigned int nb, rc;
>  
>      front = flexarray_make(16, 1);
> @@ -1518,8 +1539,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
>                               libxl__xs_kvs_of_flexarray(&gc, back, back->count),
>                               libxl__xs_kvs_of_flexarray(&gc, front, front->count));
>  
> -    /* FIXME: wait for plug */
> +    be_path = libxl__device_backend_path(&gc, &device);
> +    state_path = libxl__sprintf(&gc, "%s/state", be_path);
> +    state = libxl__xs_read(&gc, XBT_NULL, state_path);
> +
> +    if (atoi(state) != 2) {
> +        xs_watch(ctx->xsh, state_path, be_path);
> +        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
> +        tv.tv_usec = 0;
> +        rc = libxl__wait_for_device_state(&gc, &tv, 2, NULL);
> +        xs_unwatch(ctx->xsh, state_path, be_path);
> +        if (rc < 0) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "unable to initialize nic device: %s\n",
> +                       nic->ifname);
> +            goto out_free;
> +        }
> +    }
>      rc = 0;
> +
>  out_free:
>      flexarray_free(back);
>      flexarray_free(front);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:42:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:42:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROiC-0006Kr-Qm; Fri, 18 Nov 2011 13:42:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RROiB-0006Kg-D0
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:42:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321623731!4759339!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6594 invoked from network); 18 Nov 2011 13:42:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:42:11 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9010971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:42:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 13:42:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 13:42:10 +0000
In-Reply-To: <1d81d1c4c851c0b07696.1321617582@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<1d81d1c4c851c0b07696.1321617582@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321623730.3664.352.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1317386335 -7200
> # Node ID 1d81d1c4c851c0b07696373304801df56a221e90
> # Parent  4ad998fddb16a299cb230ea23ba944d84adbd2bf
> libxl: execute hotplug scripts directly from libxl.
> 
> Added the necessary handlers to execute hotplug scripts when necessary
> from libxl. Split NetBSD and Linux hotplug calls into two separate
> files, because parameters for hotplug scripts are different. Linux
> has empty functions, since the calling of hotplug scripts is still
> done using udev.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/Makefile
> --- a/tools/libxl/Makefile      Fri Nov 18 11:29:14 2011 +0100
> +++ b/tools/libxl/Makefile      Fri Sep 30 14:38:55 2011 +0200
> @@ -34,8 +34,10 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu

Should be:

>  ifeq ($(CONFIG_NetBSD),y)
>  LIBXL_OBJS-y += libxl_phybackend.o
> +LIBXL_OBJS-y += hotplug_netbsd.o
   elsif ($(CONFIG_Linux),y)
>  LIBXL_OBJS-y += libxl_nophybackend.o
> +LIBXL_OBJS-y += hotplug_linux.o
   else
   $(error A message of some sort)
>  endif



> diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c        Fri Nov 18 11:29:14 2011 +0100
> +++ b/tools/libxl/libxl_device.c        Fri Sep 30 14:38:55 2011 +0200
> @@ -68,6 +68,24 @@ int libxl__parse_backend_path(libxl__gc
>      return libxl__device_kind_from_string(strkind, &dev->backend_kind);
>  }
> 
> +int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev)

No need for a add/remove type parameter?

> +{
> +    int rc = 0;
> +
> +    switch(dev->kind) {
> +    case LIBXL__DEVICE_KIND_VIF:
> +        rc = libxl__nic_hotplug(gc, dev);
> +        break;
> +    case LIBXL__DEVICE_KIND_VBD:
> +        rc = libxl__disk_hotplug(gc, dev);
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    return rc;
> +}
> +
>  int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
>                               char **bents, char **fents)
>  {
> @@ -449,6 +467,7 @@ int libxl__device_remove(libxl__gc *gc,
>      if (!state)
>          goto out;
>      if (atoi(state) != 4) {
> +        libxl__device_execute_hotplug(gc, dev);
>          libxl__device_destroy_tapdisk(gc, be_path);
>          xs_rm(ctx->xsh, XBT_NULL, be_path);
>          goto out;
> @@ -492,6 +511,12 @@ int libxl__device_destroy(libxl__gc *gc,
>      char *be_path = libxl__device_backend_path(gc, dev);
>      char *fe_path = libxl__device_frontend_path(gc, dev);
> 
> +    /*
> +     * Run hotplug scripts, which will probably not be able to
> +     * execute successfully since the device may still be plugged

What does this mean? If we don't expect it to work why are we calling
them?

> +     */
> +    libxl__device_execute_hotplug(gc, dev);
> +
>      xs_rm(ctx->xsh, XBT_NULL, be_path);
>      xs_rm(ctx->xsh, XBT_NULL, fe_path);
> 
> diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h      Fri Nov 18 11:29:14 2011 +0100
> +++ b/tools/libxl/libxl_internal.h      Fri Sep 30 14:38:55 2011 +0200
> @@ -287,6 +287,34 @@ _hidden int libxl__wait_for_device_state
>   */
>  _hidden int libxl__try_phy_backend(mode_t st_mode);
> 
> +/* hotplug functions */
> +/*
> + * libxl__device_execute_hotplug - generic function to execute hotplug scripts
> + * gc: allocation pool
> + * dev: reference to the device that executes the hotplug scripts
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev);
> +
> +/*
> + * libxl__disk_hotplug - execute hotplug script for a disk type device
> + * gc: allocation pool
> + * dev: reference to the disk device
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev);
> +
> +/*
> + * libxl__nic_hotplug - execute hotplug script for a nic type device
> + * gc: allocation pool
> + * dev: reference to the nic device
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev);
> +
>  /* from libxl_pci */
> 
>  _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:42:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:42:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROiC-0006Kr-Qm; Fri, 18 Nov 2011 13:42:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RROiB-0006Kg-D0
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:42:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321623731!4759339!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6594 invoked from network); 18 Nov 2011 13:42:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:42:11 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9010971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:42:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 13:42:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 13:42:10 +0000
In-Reply-To: <1d81d1c4c851c0b07696.1321617582@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<1d81d1c4c851c0b07696.1321617582@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321623730.3664.352.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1317386335 -7200
> # Node ID 1d81d1c4c851c0b07696373304801df56a221e90
> # Parent  4ad998fddb16a299cb230ea23ba944d84adbd2bf
> libxl: execute hotplug scripts directly from libxl.
> 
> Added the necessary handlers to execute hotplug scripts when necessary
> from libxl. Split NetBSD and Linux hotplug calls into two separate
> files, because parameters for hotplug scripts are different. Linux
> has empty functions, since the calling of hotplug scripts is still
> done using udev.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/Makefile
> --- a/tools/libxl/Makefile      Fri Nov 18 11:29:14 2011 +0100
> +++ b/tools/libxl/Makefile      Fri Sep 30 14:38:55 2011 +0200
> @@ -34,8 +34,10 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu

Should be:

>  ifeq ($(CONFIG_NetBSD),y)
>  LIBXL_OBJS-y += libxl_phybackend.o
> +LIBXL_OBJS-y += hotplug_netbsd.o
   elsif ($(CONFIG_Linux),y)
>  LIBXL_OBJS-y += libxl_nophybackend.o
> +LIBXL_OBJS-y += hotplug_linux.o
   else
   $(error A message of some sort)
>  endif



> diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c        Fri Nov 18 11:29:14 2011 +0100
> +++ b/tools/libxl/libxl_device.c        Fri Sep 30 14:38:55 2011 +0200
> @@ -68,6 +68,24 @@ int libxl__parse_backend_path(libxl__gc
>      return libxl__device_kind_from_string(strkind, &dev->backend_kind);
>  }
> 
> +int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev)

No need for a add/remove type parameter?

> +{
> +    int rc = 0;
> +
> +    switch(dev->kind) {
> +    case LIBXL__DEVICE_KIND_VIF:
> +        rc = libxl__nic_hotplug(gc, dev);
> +        break;
> +    case LIBXL__DEVICE_KIND_VBD:
> +        rc = libxl__disk_hotplug(gc, dev);
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    return rc;
> +}
> +
>  int libxl__device_generic_add(libxl__gc *gc, libxl__device *device,
>                               char **bents, char **fents)
>  {
> @@ -449,6 +467,7 @@ int libxl__device_remove(libxl__gc *gc,
>      if (!state)
>          goto out;
>      if (atoi(state) != 4) {
> +        libxl__device_execute_hotplug(gc, dev);
>          libxl__device_destroy_tapdisk(gc, be_path);
>          xs_rm(ctx->xsh, XBT_NULL, be_path);
>          goto out;
> @@ -492,6 +511,12 @@ int libxl__device_destroy(libxl__gc *gc,
>      char *be_path = libxl__device_backend_path(gc, dev);
>      char *fe_path = libxl__device_frontend_path(gc, dev);
> 
> +    /*
> +     * Run hotplug scripts, which will probably not be able to
> +     * execute successfully since the device may still be plugged

What does this mean? If we don't expect it to work why are we calling
them?

> +     */
> +    libxl__device_execute_hotplug(gc, dev);
> +
>      xs_rm(ctx->xsh, XBT_NULL, be_path);
>      xs_rm(ctx->xsh, XBT_NULL, fe_path);
> 
> diff -r 4ad998fddb16 -r 1d81d1c4c851 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h      Fri Nov 18 11:29:14 2011 +0100
> +++ b/tools/libxl/libxl_internal.h      Fri Sep 30 14:38:55 2011 +0200
> @@ -287,6 +287,34 @@ _hidden int libxl__wait_for_device_state
>   */
>  _hidden int libxl__try_phy_backend(mode_t st_mode);
> 
> +/* hotplug functions */
> +/*
> + * libxl__device_execute_hotplug - generic function to execute hotplug scripts
> + * gc: allocation pool
> + * dev: reference to the device that executes the hotplug scripts
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__device_execute_hotplug(libxl__gc *gc, libxl__device *dev);
> +
> +/*
> + * libxl__disk_hotplug - execute hotplug script for a disk type device
> + * gc: allocation pool
> + * dev: reference to the disk device
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev);
> +
> +/*
> + * libxl__nic_hotplug - execute hotplug script for a nic type device
> + * gc: allocation pool
> + * dev: reference to the nic device
> + *
> + * Returns 0 on success, and < 0 on error.
> + */
> +_hidden int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev);
> +
>  /* from libxl_pci */
> 
>  _hidden int libxl__device_pci_add(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev, int starting);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:53:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:53:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROsK-0006YO-4V; Fri, 18 Nov 2011 13:53:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RROsI-0006YG-2U
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:53:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321624356!2112502!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32034 invoked from network); 18 Nov 2011 13:52:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 13:52:37 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIDqW6n002924
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 13:52:33 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIDqTIv020948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 13:52:30 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIDqNEe002135; Fri, 18 Nov 2011 07:52:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 05:52:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9F35D81489; Fri, 18 Nov 2011 08:52:21 -0500 (EST)
Date: Fri, 18 Nov 2011 08:52:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111118135221.GC12433@phenom.dumpdata.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321614166.3664.311.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4EC66321.00CC,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ANNIE LI <annie.li@oracle.com>, Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
 implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > +                       xen_raw_printk(str);
> > +                       panic(str);
> 
> I expect you've just copied this style from elsewhere but I really
> dislike this duplication of prints. If panic is not useful here we
> really ought to address that at the root instead of going around
> patching things to print every panic message twice. I thought
> earlyprintk was supposed to solve this problem. Perhaps a generic
> early_panic_print could be added to the panic code?

We are using this combo in swiotlb-xen and as well in the xen pci.
We could declere a 'xen_raw_panic' that would do the job?

The problem is that panic() uses the "late" printk mechanism (so
it goes through the buffer that ends up not beign flushed) and the
panic never sees the light. The 'xen_raw_printk' is synchronous..

But I wonder if the panic surfaces if 'earlyprintk=xen' is used?
At which point it might be that the those extra xen_raw_printk
become pointless?

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:53:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:53:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROsK-0006YO-4V; Fri, 18 Nov 2011 13:53:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RROsI-0006YG-2U
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:53:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321624356!2112502!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32034 invoked from network); 18 Nov 2011 13:52:37 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 13:52:37 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIDqW6n002924
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 13:52:33 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIDqTIv020948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 13:52:30 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIDqNEe002135; Fri, 18 Nov 2011 07:52:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 05:52:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9F35D81489; Fri, 18 Nov 2011 08:52:21 -0500 (EST)
Date: Fri, 18 Nov 2011 08:52:21 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111118135221.GC12433@phenom.dumpdata.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321614166.3664.311.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4EC66321.00CC,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ANNIE LI <annie.li@oracle.com>, Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
 implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > +                       xen_raw_printk(str);
> > +                       panic(str);
> 
> I expect you've just copied this style from elsewhere but I really
> dislike this duplication of prints. If panic is not useful here we
> really ought to address that at the root instead of going around
> patching things to print every panic message twice. I thought
> earlyprintk was supposed to solve this problem. Perhaps a generic
> early_panic_print could be added to the panic code?

We are using this combo in swiotlb-xen and as well in the xen pci.
We could declere a 'xen_raw_panic' that would do the job?

The problem is that panic() uses the "late" printk mechanism (so
it goes through the buffer that ends up not beign flushed) and the
panic never sees the light. The 'xen_raw_printk' is synchronous..

But I wonder if the panic surfaces if 'earlyprintk=xen' is used?
At which point it might be that the those extra xen_raw_printk
become pointless?

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:58:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROxg-0006hf-Sc; Fri, 18 Nov 2011 13:58:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RROxg-0006hY-1v
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:58:36 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321624663!44481500!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6805 invoked from network); 18 Nov 2011 13:57:45 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:57:45 -0000
Received: by ghbf1 with SMTP id f1so825875ghb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 05:58:15 -0800 (PST)
Received: by 10.50.140.1 with SMTP id rc1mr3263784igb.25.1321624695126;
	Fri, 18 Nov 2011 05:58:15 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id ew6sm1936612igc.4.2011.11.18.05.58.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 05:58:13 -0800 (PST)
Message-ID: <4EC66472.7020706@codemonkey.ws>
Date: Fri, 18 Nov 2011 07:58:10 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>	<4EC27D0D.3040204@codemonkey.ws>	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
	<alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"agraf@suse.de" <agraf@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 05:46 AM, Stefano Stabellini wrote:
> On Tue, 15 Nov 2011, Stefano Stabellini wrote:
>> On Tue, 15 Nov 2011, Anthony Liguori wrote:
>>> On 11/15/2011 08:51 AM, stefano.stabellini@eu.citrix.com wrote:
>>>> From: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
>>>>
>>>> Xen doesn't need full RTC emulation in Qemu because the RTC is already
>>>> emulated by the hypervisor. In particular we want to avoid the timers
>>>> initialization so that Qemu doesn't need to wake up needlessly.
>>>>
>>>> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
>>>
>>> Yuck.  There's got to be a better way to do this.
>>
>> Yeah, it is pretty ugly, I was hoping in some good suggestions to
>> improve this patch :)
>>
>>
>>> I think it would be better to name timers and then in Xen specific machine code,
>>> disable the RTC timers.
>>
>> Good idea!
>> I was thinking that I could implement an rtc_stop function in
>> mc146818rtc.c that stops and frees the timers.

You could also just stop the rtc_clock.  The rtc is the only device that makes 
use of the rtc_clock.

Regards,

Anthony Liguori

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 13:58:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 13:58:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RROxg-0006hf-Sc; Fri, 18 Nov 2011 13:58:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RROxg-0006hY-1v
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 13:58:36 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321624663!44481500!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6805 invoked from network); 18 Nov 2011 13:57:45 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 13:57:45 -0000
Received: by ghbf1 with SMTP id f1so825875ghb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 05:58:15 -0800 (PST)
Received: by 10.50.140.1 with SMTP id rc1mr3263784igb.25.1321624695126;
	Fri, 18 Nov 2011 05:58:15 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id ew6sm1936612igc.4.2011.11.18.05.58.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 05:58:13 -0800 (PST)
Message-ID: <4EC66472.7020706@codemonkey.ws>
Date: Fri, 18 Nov 2011 07:58:10 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>	<4EC27D0D.3040204@codemonkey.ws>	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
	<alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"agraf@suse.de" <agraf@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 05:46 AM, Stefano Stabellini wrote:
> On Tue, 15 Nov 2011, Stefano Stabellini wrote:
>> On Tue, 15 Nov 2011, Anthony Liguori wrote:
>>> On 11/15/2011 08:51 AM, stefano.stabellini@eu.citrix.com wrote:
>>>> From: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
>>>>
>>>> Xen doesn't need full RTC emulation in Qemu because the RTC is already
>>>> emulated by the hypervisor. In particular we want to avoid the timers
>>>> initialization so that Qemu doesn't need to wake up needlessly.
>>>>
>>>> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
>>>
>>> Yuck.  There's got to be a better way to do this.
>>
>> Yeah, it is pretty ugly, I was hoping in some good suggestions to
>> improve this patch :)
>>
>>
>>> I think it would be better to name timers and then in Xen specific machine code,
>>> disable the RTC timers.
>>
>> Good idea!
>> I was thinking that I could implement an rtc_stop function in
>> mc146818rtc.c that stops and frees the timers.

You could also just stop the rtc_clock.  The rtc is the only device that makes 
use of the rtc_clock.

Regards,

Anthony Liguori

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:01:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:01:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP0b-0006oh-GF; Fri, 18 Nov 2011 14:01:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRP0Z-0006oP-Oc
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:01:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1321624846!53309236!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8656 invoked from network); 18 Nov 2011 14:00:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:00:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9011392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 14:00:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 14:00:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 18 Nov 2011 14:00:44 +0000
In-Reply-To: <20111118135221.GC12433@phenom.dumpdata.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
	<20111118135221.GC12433@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321624845.3664.354.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ANNIE LI <annie.li@oracle.com>, Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
 implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 13:52 +0000, Konrad Rzeszutek Wilk wrote:
> > > +                       xen_raw_printk(str);
> > > +                       panic(str);
> > 
> > I expect you've just copied this style from elsewhere but I really
> > dislike this duplication of prints. If panic is not useful here we
> > really ought to address that at the root instead of going around
> > patching things to print every panic message twice. I thought
> > earlyprintk was supposed to solve this problem. Perhaps a generic
> > early_panic_print could be added to the panic code?
> 
> We are using this combo in swiotlb-xen and as well in the xen pci.
> We could declere a 'xen_raw_panic' that would do the job?
> 
> The problem is that panic() uses the "late" printk mechanism (so
> it goes through the buffer that ends up not beign flushed) and the
> panic never sees the light.

So lets fix that instead of working around it...

>  The 'xen_raw_printk' is synchronous..
> 
> But I wonder if the panic surfaces if 'earlyprintk=xen' is used?
> At which point it might be that the those extra xen_raw_printk
> become pointless?

I think panic's do come out with earlyprintk (unless they are truly
super early).

Ian.




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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:01:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:01:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP0b-0006oh-GF; Fri, 18 Nov 2011 14:01:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRP0Z-0006oP-Oc
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:01:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1321624846!53309236!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8656 invoked from network); 18 Nov 2011 14:00:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:00:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9011392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 14:00:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 14:00:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 18 Nov 2011 14:00:44 +0000
In-Reply-To: <20111118135221.GC12433@phenom.dumpdata.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
	<20111118135221.GC12433@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321624845.3664.354.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ANNIE LI <annie.li@oracle.com>, Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
 implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 13:52 +0000, Konrad Rzeszutek Wilk wrote:
> > > +                       xen_raw_printk(str);
> > > +                       panic(str);
> > 
> > I expect you've just copied this style from elsewhere but I really
> > dislike this duplication of prints. If panic is not useful here we
> > really ought to address that at the root instead of going around
> > patching things to print every panic message twice. I thought
> > earlyprintk was supposed to solve this problem. Perhaps a generic
> > early_panic_print could be added to the panic code?
> 
> We are using this combo in swiotlb-xen and as well in the xen pci.
> We could declere a 'xen_raw_panic' that would do the job?
> 
> The problem is that panic() uses the "late" printk mechanism (so
> it goes through the buffer that ends up not beign flushed) and the
> panic never sees the light.

So lets fix that instead of working around it...

>  The 'xen_raw_printk' is synchronous..
> 
> But I wonder if the panic surfaces if 'earlyprintk=xen' is used?
> At which point it might be that the those extra xen_raw_printk
> become pointless?

I think panic's do come out with earlyprintk (unless they are truly
super early).

Ian.




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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:02:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:02:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP1K-0006tJ-42; Fri, 18 Nov 2011 14:02:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRP1I-0006sR-DC
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:02:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1321624916!5411266!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25319 invoked from network); 18 Nov 2011 14:01:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9011426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 14:01:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 14:01:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 18 Nov 2011 14:01:55 +0000
In-Reply-To: <4EC66ADB0200007800061D74@nat28.tlf.novell.com>
References: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
	<4EC66ADB0200007800061D74@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321624916.3664.355.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 13:25 +0000, Jan Beulich wrote:
> >>> On 18.11.11 at 14:15, "Jan Beulich" <JBeulich@suse.com> wrote:
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > --- a/drivers/xen/netback/netback.c
> > +++ b/drivers/xen/netback/netback.c
> > @@ -1155,7 +1155,7 @@ static int netbk_tx_check_mop(struct sk_
> >  		pending_idx = *((u16 *)skb->data);
> >  		netif_idx_release(pending_idx);
> >  		for (j = start; j < i; j++) {
> > -			pending_idx = (unsigned long)shinfo->frags[i].page;
> > +			pending_idx = (unsigned long)shinfo->frags[j].page;
> >  			netif_idx_release(pending_idx);
> >  		}
> >  
> 
> I'm sure you want to apply the equivalent to xen-netback to (there
> it is in function xen_netbk_tx_check_gop()).

Yes. I'll pick this up. Thanks,
Ian.

> 
> Jan
> 



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:02:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:02:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP1K-0006tJ-42; Fri, 18 Nov 2011 14:02:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRP1I-0006sR-DC
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:02:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1321624916!5411266!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25319 invoked from network); 18 Nov 2011 14:01:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9011426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 14:01:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 14:01:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 18 Nov 2011 14:01:55 +0000
In-Reply-To: <4EC66ADB0200007800061D74@nat28.tlf.novell.com>
References: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
	<4EC66ADB0200007800061D74@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321624916.3664.355.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 13:25 +0000, Jan Beulich wrote:
> >>> On 18.11.11 at 14:15, "Jan Beulich" <JBeulich@suse.com> wrote:
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > --- a/drivers/xen/netback/netback.c
> > +++ b/drivers/xen/netback/netback.c
> > @@ -1155,7 +1155,7 @@ static int netbk_tx_check_mop(struct sk_
> >  		pending_idx = *((u16 *)skb->data);
> >  		netif_idx_release(pending_idx);
> >  		for (j = start; j < i; j++) {
> > -			pending_idx = (unsigned long)shinfo->frags[i].page;
> > +			pending_idx = (unsigned long)shinfo->frags[j].page;
> >  			netif_idx_release(pending_idx);
> >  		}
> >  
> 
> I'm sure you want to apply the equivalent to xen-netback to (there
> it is in function xen_netbk_tx_check_gop()).

Yes. I'll pick this up. Thanks,
Ian.

> 
> Jan
> 



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:04:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:04:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP2p-00072b-NK; Fri, 18 Nov 2011 14:03:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RRP2o-00072B-8d
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:03:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321625010!4051513!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12864 invoked from network); 18 Nov 2011 14:03:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:03:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9011465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 14:03:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 14:03:30 +0000
Date: Fri, 18 Nov 2011 14:04:22 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: xen-devel@lists.xensource.com
Message-ID: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/3] prevent qemu-xen-traditional from waking up
	needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series prevents qemu-xen-traditional from waking up
needlessly several times a second in order to check some timers.

The first patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that qemu doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The second patch stops qemu-xen-traditional from starting some timers
for RTC emulation; they are not needed because the RTC is already
emulated in the hypervisor.

Finally the last patch increases the default select timeout to 1h:
nothing should rely on the select timeout to be 1sec, so we might as
well increase it to 1h.


Stefano Stabellini (3):
      xen: introduce an event channel for buffered io event notifications
      xen: don't initialize the RTC timers if xen is available
      increase minimum timeout to 1h

 hw/mc146818rtc.c  |    2 ++
 i386-dm/helper2.c |   45 +++++++++++++++++++++++++++++++++++++--------
 2 files changed, 39 insertions(+), 8 deletions(-)


Cheers,

Stefano

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:04:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:04:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP2p-00072b-NK; Fri, 18 Nov 2011 14:03:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RRP2o-00072B-8d
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:03:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321625010!4051513!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12864 invoked from network); 18 Nov 2011 14:03:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:03:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9011465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 14:03:30 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 14:03:30 +0000
Date: Fri, 18 Nov 2011 14:04:22 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: xen-devel@lists.xensource.com
Message-ID: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/3] prevent qemu-xen-traditional from waking up
	needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series prevents qemu-xen-traditional from waking up
needlessly several times a second in order to check some timers.

The first patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that qemu doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The second patch stops qemu-xen-traditional from starting some timers
for RTC emulation; they are not needed because the RTC is already
emulated in the hypervisor.

Finally the last patch increases the default select timeout to 1h:
nothing should rely on the select timeout to be 1sec, so we might as
well increase it to 1h.


Stefano Stabellini (3):
      xen: introduce an event channel for buffered io event notifications
      xen: don't initialize the RTC timers if xen is available
      increase minimum timeout to 1h

 hw/mc146818rtc.c  |    2 ++
 i386-dm/helper2.c |   45 +++++++++++++++++++++++++++++++++++++--------
 2 files changed, 39 insertions(+), 8 deletions(-)


Cheers,

Stefano

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:05:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:05:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP41-0007B3-78; Fri, 18 Nov 2011 14:05:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RRP40-0007AG-9M
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:05:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321625083!4070167!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22040 invoked from network); 18 Nov 2011 14:04:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:04:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315195200"; d="scan'208";a="171141836"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 09:04:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 09:04:42 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAIE4ZD5031787;
	Fri, 18 Nov 2011 06:04:36 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 18 Nov 2011 14:05:23 +0000
Message-ID: <1321625125-30726-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] xen: introduce an event channel for
	buffered io event notifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 i386-dm/helper2.c |   41 +++++++++++++++++++++++++++++++++++------
 1 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index 481c620..b121e30 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -111,12 +111,15 @@ int send_vcpu = 0;
 
 //the evtchn port for polling the notification,
 evtchn_port_t *ioreq_local_port;
+/* evtchn local port for buffered io */
+evtchn_port_t bufioreq_local_port;
 
 CPUX86State *cpu_x86_init(const char *cpu_model)
 {
     CPUX86State *env;
     static int inited;
     int i, rc;
+    unsigned long bufioreq_evtchn;
 
     env = qemu_mallocz(sizeof(CPUX86State));
     if (!env)
@@ -154,6 +157,19 @@ CPUX86State *cpu_x86_init(const char *cpu_model)
             }
             ioreq_local_port[i] = rc;
         }
+        rc = xc_get_hvm_param(xc_handle, domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+                &bufioreq_evtchn);
+        if (rc < 0) {
+            fprintf(logfile, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN error=%d\n",
+                    errno);
+            return NULL;
+        }
+        rc = xc_evtchn_bind_interdomain(xce_handle, domid, (uint32_t)bufioreq_evtchn);
+        if (rc == -1) {
+            fprintf(logfile, "bind interdomain ioctl error %d\n", errno);
+            return NULL;
+        }
+        bufioreq_local_port = rc;
     }
 
     return env;
@@ -263,6 +279,12 @@ static ioreq_t *cpu_get_ioreq(void)
     evtchn_port_t port;
 
     port = xc_evtchn_pending(xce_handle);
+    if (port == bufioreq_local_port) {
+        qemu_mod_timer(buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock(rt_clock));
+        return NULL;
+    }
+ 
     if (port != -1) {
         for ( i = 0; i < vcpus; i++ )
             if ( ioreq_local_port[i] == port )
@@ -459,14 +481,16 @@ static void __handle_ioreq(CPUState *env, ioreq_t *req)
     }
 }
 
-static void __handle_buffered_iopage(CPUState *env)
+static int __handle_buffered_iopage(CPUState *env)
 {
     buf_ioreq_t *buf_req = NULL;
     ioreq_t req;
     int qw;
 
     if (!buffered_io_page)
-        return;
+        return 0;
+
+    memset(&req, 0x00, sizeof(req));
 
     while (buffered_io_page->read_pointer !=
            buffered_io_page->write_pointer) {
@@ -493,15 +517,21 @@ static void __handle_buffered_iopage(CPUState *env)
         xen_mb();
         buffered_io_page->read_pointer += qw ? 2 : 1;
     }
+
+    return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
     CPUState *env = opaque;
 
-    __handle_buffered_iopage(env);
-    qemu_mod_timer(buffered_io_timer, BUFFER_IO_MAX_DELAY +
-		   qemu_get_clock(rt_clock));
+    if (__handle_buffered_iopage(env)) {
+        qemu_mod_timer(buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock(rt_clock));
+    } else {
+        qemu_del_timer(buffered_io_timer);
+        xc_evtchn_unmask(xce_handle, bufioreq_local_port);
+    }
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -561,7 +591,6 @@ int main_loop(void)
 
     buffered_io_timer = qemu_new_timer(rt_clock, handle_buffered_io,
 				       cpu_single_env);
-    qemu_mod_timer(buffered_io_timer, qemu_get_clock(rt_clock));
 
     if (evtchn_fd != -1)
         qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, env);
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:05:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:05:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP41-0007B3-78; Fri, 18 Nov 2011 14:05:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RRP40-0007AG-9M
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:05:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321625083!4070167!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22040 invoked from network); 18 Nov 2011 14:04:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:04:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315195200"; d="scan'208";a="171141836"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 09:04:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 09:04:42 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAIE4ZD5031787;
	Fri, 18 Nov 2011 06:04:36 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 18 Nov 2011 14:05:23 +0000
Message-ID: <1321625125-30726-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] xen: introduce an event channel for
	buffered io event notifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 i386-dm/helper2.c |   41 +++++++++++++++++++++++++++++++++++------
 1 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index 481c620..b121e30 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -111,12 +111,15 @@ int send_vcpu = 0;
 
 //the evtchn port for polling the notification,
 evtchn_port_t *ioreq_local_port;
+/* evtchn local port for buffered io */
+evtchn_port_t bufioreq_local_port;
 
 CPUX86State *cpu_x86_init(const char *cpu_model)
 {
     CPUX86State *env;
     static int inited;
     int i, rc;
+    unsigned long bufioreq_evtchn;
 
     env = qemu_mallocz(sizeof(CPUX86State));
     if (!env)
@@ -154,6 +157,19 @@ CPUX86State *cpu_x86_init(const char *cpu_model)
             }
             ioreq_local_port[i] = rc;
         }
+        rc = xc_get_hvm_param(xc_handle, domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+                &bufioreq_evtchn);
+        if (rc < 0) {
+            fprintf(logfile, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN error=%d\n",
+                    errno);
+            return NULL;
+        }
+        rc = xc_evtchn_bind_interdomain(xce_handle, domid, (uint32_t)bufioreq_evtchn);
+        if (rc == -1) {
+            fprintf(logfile, "bind interdomain ioctl error %d\n", errno);
+            return NULL;
+        }
+        bufioreq_local_port = rc;
     }
 
     return env;
@@ -263,6 +279,12 @@ static ioreq_t *cpu_get_ioreq(void)
     evtchn_port_t port;
 
     port = xc_evtchn_pending(xce_handle);
+    if (port == bufioreq_local_port) {
+        qemu_mod_timer(buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock(rt_clock));
+        return NULL;
+    }
+ 
     if (port != -1) {
         for ( i = 0; i < vcpus; i++ )
             if ( ioreq_local_port[i] == port )
@@ -459,14 +481,16 @@ static void __handle_ioreq(CPUState *env, ioreq_t *req)
     }
 }
 
-static void __handle_buffered_iopage(CPUState *env)
+static int __handle_buffered_iopage(CPUState *env)
 {
     buf_ioreq_t *buf_req = NULL;
     ioreq_t req;
     int qw;
 
     if (!buffered_io_page)
-        return;
+        return 0;
+
+    memset(&req, 0x00, sizeof(req));
 
     while (buffered_io_page->read_pointer !=
            buffered_io_page->write_pointer) {
@@ -493,15 +517,21 @@ static void __handle_buffered_iopage(CPUState *env)
         xen_mb();
         buffered_io_page->read_pointer += qw ? 2 : 1;
     }
+
+    return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
     CPUState *env = opaque;
 
-    __handle_buffered_iopage(env);
-    qemu_mod_timer(buffered_io_timer, BUFFER_IO_MAX_DELAY +
-		   qemu_get_clock(rt_clock));
+    if (__handle_buffered_iopage(env)) {
+        qemu_mod_timer(buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock(rt_clock));
+    } else {
+        qemu_del_timer(buffered_io_timer);
+        xc_evtchn_unmask(xce_handle, bufioreq_local_port);
+    }
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -561,7 +591,6 @@ int main_loop(void)
 
     buffered_io_timer = qemu_new_timer(rt_clock, handle_buffered_io,
 				       cpu_single_env);
-    qemu_mod_timer(buffered_io_timer, qemu_get_clock(rt_clock));
 
     if (evtchn_fd != -1)
         qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, env);
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:05:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:05:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP46-0007C8-KM; Fri, 18 Nov 2011 14:05:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RRP45-0007Au-DT
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:05:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321625083!4070167!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22240 invoked from network); 18 Nov 2011 14:04:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315195200"; d="scan'208";a="171141855"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 09:04:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 09:04:48 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAIE4ZD6031787;
	Fri, 18 Nov 2011 06:04:37 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 18 Nov 2011 14:05:24 +0000
Message-ID: <1321625125-30726-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] xen: don't initialize the RTC timers if xen
	is available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Xen doesn't need full RTC emulation in Qemu because the RTC is already
emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
available so that Qemu doesn't need to wake up needlessly.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/mc146818rtc.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index cb3f56b..253b680 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -542,6 +542,7 @@ RTCState *rtc_init(int base, qemu_irq irq, int base_year)
     s->base_year = base_year;
     rtc_set_date_from_host(s);
 
+#ifndef CONFIG_DM
     s->periodic_timer = qemu_new_timer(vm_clock,
                                        rtc_periodic_timer, s);
     s->second_timer = qemu_new_timer(vm_clock,
@@ -551,6 +552,7 @@ RTCState *rtc_init(int base, qemu_irq irq, int base_year)
 
     s->next_second_time = qemu_get_clock(vm_clock) + (ticks_per_sec * 99) / 100;
     qemu_mod_timer(s->second_timer2, s->next_second_time);
+#endif
 
     register_ioport_write(base, 2, 1, cmos_ioport_write, s);
     register_ioport_read(base, 2, 1, cmos_ioport_read, s);
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:05:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:05:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP46-0007C8-KM; Fri, 18 Nov 2011 14:05:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RRP45-0007Au-DT
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:05:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321625083!4070167!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22240 invoked from network); 18 Nov 2011 14:04:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315195200"; d="scan'208";a="171141855"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 09:04:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 09:04:48 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAIE4ZD6031787;
	Fri, 18 Nov 2011 06:04:37 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 18 Nov 2011 14:05:24 +0000
Message-ID: <1321625125-30726-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] xen: don't initialize the RTC timers if xen
	is available
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Xen doesn't need full RTC emulation in Qemu because the RTC is already
emulated by the hypervisor. Hence don't initialize the RTC timers when Xen is
available so that Qemu doesn't need to wake up needlessly.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/mc146818rtc.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index cb3f56b..253b680 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -542,6 +542,7 @@ RTCState *rtc_init(int base, qemu_irq irq, int base_year)
     s->base_year = base_year;
     rtc_set_date_from_host(s);
 
+#ifndef CONFIG_DM
     s->periodic_timer = qemu_new_timer(vm_clock,
                                        rtc_periodic_timer, s);
     s->second_timer = qemu_new_timer(vm_clock,
@@ -551,6 +552,7 @@ RTCState *rtc_init(int base, qemu_irq irq, int base_year)
 
     s->next_second_time = qemu_get_clock(vm_clock) + (ticks_per_sec * 99) / 100;
     qemu_mod_timer(s->second_timer2, s->next_second_time);
+#endif
 
     register_ioport_write(base, 2, 1, cmos_ioport_write, s);
     register_ioport_read(base, 2, 1, cmos_ioport_read, s);
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:05:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP49-0007Ca-1M; Fri, 18 Nov 2011 14:05:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RRP47-0007BJ-G0
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:05:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321625090!3204902!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8962 invoked from network); 18 Nov 2011 14:04:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:04:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315195200"; d="scan'208";a="19224004"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 09:04:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 09:04:49 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAIE4ZD7031787;
	Fri, 18 Nov 2011 06:04:38 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 18 Nov 2011 14:05:25 +0000
Message-ID: <1321625125-30726-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

There is no reason why the minimum timeout should be 10s, it could
easily be 1h and we would save lots of cpu cycles.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 i386-dm/helper2.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index b121e30..c6d049c 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -605,8 +605,8 @@ int main_loop(void)
             /* Wait up to 10 msec. */
             main_loop_wait(10);
 #else
-            /* Wait up to 10s. */
-            main_loop_wait(10000);
+            /* Wait up to 1h. */
+            main_loop_wait(1000*60*60);
 #endif
 
         fprintf(logfile, "device model saving state\n");
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:05:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRP49-0007Ca-1M; Fri, 18 Nov 2011 14:05:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RRP47-0007BJ-G0
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:05:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321625090!3204902!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8962 invoked from network); 18 Nov 2011 14:04:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:04:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315195200"; d="scan'208";a="19224004"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 09:04:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 09:04:49 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAIE4ZD7031787;
	Fri, 18 Nov 2011 06:04:38 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 18 Nov 2011 14:05:25 +0000
Message-ID: <1321625125-30726-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111181351190.3519@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] increase minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

There is no reason why the minimum timeout should be 10s, it could
easily be 1h and we would save lots of cpu cycles.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 i386-dm/helper2.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index b121e30..c6d049c 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -605,8 +605,8 @@ int main_loop(void)
             /* Wait up to 10 msec. */
             main_loop_wait(10);
 #else
-            /* Wait up to 10s. */
-            main_loop_wait(10000);
+            /* Wait up to 1h. */
+            main_loop_wait(1000*60*60);
 #endif
 
         fprintf(logfile, "device model saving state\n");
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPCm-0007tR-4q; Fri, 18 Nov 2011 14:14:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRPCl-0007tM-8E
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:14:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1321625625!2116162!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12267 invoked from network); 18 Nov 2011 14:13:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:13:47 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315195200"; d="scan'208";a="171143274"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 09:13:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 09:13:27 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAIEDJek031833;	Fri, 18 Nov 2011 06:13:20 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Fri, 18 Nov 2011 14:13:19 +0000
Message-ID: <1321625599-3739-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen-netback: use correct index for invalidation
	in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jan Beulich <JBeulich@suse.com>

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 0cb594c..1ae270e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1021,7 +1021,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		pending_idx = *((u16 *)skb->data);
 		xen_netbk_idx_release(netbk, pending_idx);
 		for (j = start; j < i; j++) {
-			pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
+			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
 			xen_netbk_idx_release(netbk, pending_idx);
 		}
 
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPCm-0007tR-4q; Fri, 18 Nov 2011 14:14:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRPCl-0007tM-8E
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:14:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1321625625!2116162!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12267 invoked from network); 18 Nov 2011 14:13:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:13:47 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315195200"; d="scan'208";a="171143274"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 09:13:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 09:13:27 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAIEDJek031833;	Fri, 18 Nov 2011 06:13:20 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Fri, 18 Nov 2011 14:13:19 +0000
Message-ID: <1321625599-3739-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen-netback: use correct index for invalidation
	in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jan Beulich <JBeulich@suse.com>

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 0cb594c..1ae270e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1021,7 +1021,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		pending_idx = *((u16 *)skb->data);
 		xen_netbk_idx_release(netbk, pending_idx);
 		for (j = start; j < i; j++) {
-			pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
+			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
 			xen_netbk_idx_release(netbk, pending_idx);
 		}
 
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:50:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPlb-0008Gu-Uq; Fri, 18 Nov 2011 14:50:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RRPla-0008Go-0g
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:50:10 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1321627784!4793866!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2901 invoked from network); 18 Nov 2011 14:49:46 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:49:46 -0000
Received: by ghbf1 with SMTP id f1so908772ghb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 06:49:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=uh7rh6V4/Yr8Sm50e3aO5OTsjWIFSibs+15BjU9zQlo=;
	b=SeiQlmPtUF3UKzl8e294uYMC1zEoEuOgknHlN04qfx7csdNtmVQbph8LdnPzY6TmTU
	QAyJ3Dpsaygj/Sw4gcNh+KdhB82S2MUIlZb08lCfZQcp8Er7Y5i1IDntugf5HynLK13g
	iuRv1ALGKfChb8Xe5ZvIhZSO8lrdD1qtQgymU=
MIME-Version: 1.0
Received: by 10.68.11.233 with SMTP id t9mr4694983pbb.121.1321627784051; Fri,
	18 Nov 2011 06:49:44 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 18 Nov 2011 06:49:44 -0800 (PST)
In-Reply-To: <1321622877.3664.344.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<9e8abd626484f82a95d0.1321617578@loki.upc.es>
	<1321622877.3664.344.camel@zakaz.uk.xensource.com>
Date: Fri, 18 Nov 2011 15:49:44 +0100
X-Google-Sender-Auth: Sv-B8pChoQhlViTlgcHO3fTwfM0
Message-ID: <CAPLaKK5drHeZPOCsSro0d57z0r8o19p4so3VECcE2R5URAyy5w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 9 v2] libxl: add support for image
 files for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8xOCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBG
cmksIDIwMTEtMTEtMTggYXQgMTE6NTkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzE3Mzg2MzM1IC03MjAwCj4+ICMgTm9kZSBJRCA5
ZThhYmQ2MjY0ODRmODJhOTVkMGVkYzA3ODM0YWUyODdiYzk0NjdhCj4+ICMgUGFyZW50IMKgMjM1
NzhjOTk0MmJjYzg3NjdhZGM0ZTQzNWJiMWZkMWNkODlmNWUxOAo+PiBsaWJ4bDogYWRkIHN1cHBv
cnQgZm9yIGltYWdlIGZpbGVzIGZvciBOZXRCU0QKPj4KPj4gQ3JlYXRlZCBhIGhlbHBlciBmdW5j
dGlvbiB0byBkZXRlY3QgaWYgdGhlIE9TIGlzIGNhcGFibGUgb2YgdXNpbmcKPj4gaW1hZ2UgZmls
ZXMgYXMgcGh5IGJhY2tlbmRzLiBDcmVhdGUgdHdvIE9TIHNwZWNpZmljIGZpbGVzLCBhbmQKPj4g
Y2hhbmdlZCB0aGUgTWFrZWZpbGUgdG8gY2hvb3NlIHRoZSBjb3JyZWN0IG9uZSBhdCBjb21waWxl
IHRpbWUuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+Cj4+Cj4+IGRpZmYgLXIgMjM1NzhjOTk0MmJjIC1yIDllOGFiZDYyNjQ4NCB0
b29scy9saWJ4bC9NYWtlZmlsZQo+PiAtLS0gYS90b29scy9saWJ4bC9NYWtlZmlsZSDCoCDCoEZy
aSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSArMDIwMAo+PiArKysgYi90b29scy9saWJ4bC9NYWtlZmls
ZSDCoCDCoEZyaSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSArMDIwMAo+PiBAQCAtMzIsNiArMzIsMTIg
QEAgZW5kaWYKPj4gwqBMSUJYTF9PQkpTLSQoQ09ORklHX1g4NikgKz0gbGlieGxfY3B1aWQubwo+
PiDCoExJQlhMX09CSlMtJChDT05GSUdfSUE2NCkgKz0gbGlieGxfbm9jcHVpZC5vCj4+Cj4+ICtp
ZmVxICgkKENPTkZJR19OZXRCU0QpLHkpCj4+ICtMSUJYTF9PQkpTLXkgKz0gbGlieGxfcGh5YmFj
a2VuZC5vCj4+ICtlbHNlCj4+ICtMSUJYTF9PQkpTLXkgKz0gbGlieGxfbm9waHliYWNrZW5kLm8K
Pgo+IHBoeSB2cyBub3BoeSBkb24ndCByZWFsbHkgbWFrZSBzZW5zZSB0byBtZSBoZXJlLCBzaW5j
ZSBpbiBib3RoIGNhc2VzIHRoZQo+IGNvbnRlbnQgcmVsYXRlcyB0byB0aGUgcGh5IGJhY2tlbmQu
Cj4KPiBQZXJoYXBzIHdlIG5lZWQgbGlieGxfJChPUykuYyB0byBjb250YWluIG9zIHNwZWNpZmlj
IHN0dWZmPwoKQSBsaWJ4bF8kKE9TKS5jIHNvdW5kcyBpbnRlcmVzdGluZywgSSBjb3VsZCBwdXQg
aG90cGx1ZyBhbmQgYmFja2VuZCBPUwpzcGVjaWZpYyBjb2RlIHRoZXJlLCBidXQgSSdtIGFmcmFp
ZCBpdCBtaWdodCBnZXQgY3Jvd2RlZCBhbmQgYmVjb21lCmRpZmZpY3VsdCB0byB1bmRlcnN0YW5k
LiBJZiBJIGRvbid0IHJlY2VpdmUgYW55IG90aGVyIHN1Z2dlc3Rpb25zLCBJCndpbGwgY3JlYXRl
IGEgbGlieGxfbmV0YnNkLmMgYW5kIGxpYnhsX2xpbnV4LmMgKGFuZCBsaWJ4bF9zb2xhcmlzLmM/
KQphbmQgcGxhY2UgdGhlIGhvdHBsdWcgYW5kIGJhY2tlbmQgaGVscGVyIGZ1bmN0aW9ucyB0aGVy
ZS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:50:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPlb-0008Gu-Uq; Fri, 18 Nov 2011 14:50:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RRPla-0008Go-0g
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:50:10 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1321627784!4793866!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2901 invoked from network); 18 Nov 2011 14:49:46 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:49:46 -0000
Received: by ghbf1 with SMTP id f1so908772ghb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 06:49:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=uh7rh6V4/Yr8Sm50e3aO5OTsjWIFSibs+15BjU9zQlo=;
	b=SeiQlmPtUF3UKzl8e294uYMC1zEoEuOgknHlN04qfx7csdNtmVQbph8LdnPzY6TmTU
	QAyJ3Dpsaygj/Sw4gcNh+KdhB82S2MUIlZb08lCfZQcp8Er7Y5i1IDntugf5HynLK13g
	iuRv1ALGKfChb8Xe5ZvIhZSO8lrdD1qtQgymU=
MIME-Version: 1.0
Received: by 10.68.11.233 with SMTP id t9mr4694983pbb.121.1321627784051; Fri,
	18 Nov 2011 06:49:44 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 18 Nov 2011 06:49:44 -0800 (PST)
In-Reply-To: <1321622877.3664.344.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<9e8abd626484f82a95d0.1321617578@loki.upc.es>
	<1321622877.3664.344.camel@zakaz.uk.xensource.com>
Date: Fri, 18 Nov 2011 15:49:44 +0100
X-Google-Sender-Auth: Sv-B8pChoQhlViTlgcHO3fTwfM0
Message-ID: <CAPLaKK5drHeZPOCsSro0d57z0r8o19p4so3VECcE2R5URAyy5w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 9 v2] libxl: add support for image
 files for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8xOCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBG
cmksIDIwMTEtMTEtMTggYXQgMTE6NTkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzE3Mzg2MzM1IC03MjAwCj4+ICMgTm9kZSBJRCA5
ZThhYmQ2MjY0ODRmODJhOTVkMGVkYzA3ODM0YWUyODdiYzk0NjdhCj4+ICMgUGFyZW50IMKgMjM1
NzhjOTk0MmJjYzg3NjdhZGM0ZTQzNWJiMWZkMWNkODlmNWUxOAo+PiBsaWJ4bDogYWRkIHN1cHBv
cnQgZm9yIGltYWdlIGZpbGVzIGZvciBOZXRCU0QKPj4KPj4gQ3JlYXRlZCBhIGhlbHBlciBmdW5j
dGlvbiB0byBkZXRlY3QgaWYgdGhlIE9TIGlzIGNhcGFibGUgb2YgdXNpbmcKPj4gaW1hZ2UgZmls
ZXMgYXMgcGh5IGJhY2tlbmRzLiBDcmVhdGUgdHdvIE9TIHNwZWNpZmljIGZpbGVzLCBhbmQKPj4g
Y2hhbmdlZCB0aGUgTWFrZWZpbGUgdG8gY2hvb3NlIHRoZSBjb3JyZWN0IG9uZSBhdCBjb21waWxl
IHRpbWUuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+Cj4+Cj4+IGRpZmYgLXIgMjM1NzhjOTk0MmJjIC1yIDllOGFiZDYyNjQ4NCB0
b29scy9saWJ4bC9NYWtlZmlsZQo+PiAtLS0gYS90b29scy9saWJ4bC9NYWtlZmlsZSDCoCDCoEZy
aSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSArMDIwMAo+PiArKysgYi90b29scy9saWJ4bC9NYWtlZmls
ZSDCoCDCoEZyaSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSArMDIwMAo+PiBAQCAtMzIsNiArMzIsMTIg
QEAgZW5kaWYKPj4gwqBMSUJYTF9PQkpTLSQoQ09ORklHX1g4NikgKz0gbGlieGxfY3B1aWQubwo+
PiDCoExJQlhMX09CSlMtJChDT05GSUdfSUE2NCkgKz0gbGlieGxfbm9jcHVpZC5vCj4+Cj4+ICtp
ZmVxICgkKENPTkZJR19OZXRCU0QpLHkpCj4+ICtMSUJYTF9PQkpTLXkgKz0gbGlieGxfcGh5YmFj
a2VuZC5vCj4+ICtlbHNlCj4+ICtMSUJYTF9PQkpTLXkgKz0gbGlieGxfbm9waHliYWNrZW5kLm8K
Pgo+IHBoeSB2cyBub3BoeSBkb24ndCByZWFsbHkgbWFrZSBzZW5zZSB0byBtZSBoZXJlLCBzaW5j
ZSBpbiBib3RoIGNhc2VzIHRoZQo+IGNvbnRlbnQgcmVsYXRlcyB0byB0aGUgcGh5IGJhY2tlbmQu
Cj4KPiBQZXJoYXBzIHdlIG5lZWQgbGlieGxfJChPUykuYyB0byBjb250YWluIG9zIHNwZWNpZmlj
IHN0dWZmPwoKQSBsaWJ4bF8kKE9TKS5jIHNvdW5kcyBpbnRlcmVzdGluZywgSSBjb3VsZCBwdXQg
aG90cGx1ZyBhbmQgYmFja2VuZCBPUwpzcGVjaWZpYyBjb2RlIHRoZXJlLCBidXQgSSdtIGFmcmFp
ZCBpdCBtaWdodCBnZXQgY3Jvd2RlZCBhbmQgYmVjb21lCmRpZmZpY3VsdCB0byB1bmRlcnN0YW5k
LiBJZiBJIGRvbid0IHJlY2VpdmUgYW55IG90aGVyIHN1Z2dlc3Rpb25zLCBJCndpbGwgY3JlYXRl
IGEgbGlieGxfbmV0YnNkLmMgYW5kIGxpYnhsX2xpbnV4LmMgKGFuZCBsaWJ4bF9zb2xhcmlzLmM/
KQphbmQgcGxhY2UgdGhlIGhvdHBsdWcgYW5kIGJhY2tlbmQgaGVscGVyIGZ1bmN0aW9ucyB0aGVy
ZS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:51:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPmX-0008J3-Hw; Fri, 18 Nov 2011 14:51:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RRPmV-0008Il-TH
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:51:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321627842!4760714!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19755 invoked from network); 18 Nov 2011 14:50:43 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:50:43 -0000
Received: by yenl7 with SMTP id l7so3802324yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 06:50:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=HntGyo3yOKLij8sAwn94tAuUTVZJB8Tswf7sVTbuAWY=;
	b=dkKPapAnfsL4fJRLimLL+F6HqaEV6FQ/xnI4K3rFUJnmT0F2NoED4sVHEXyUonKX5I
	Rk60Wxpn3ApvTvQed94emCNk4hF4Fprw73d/Coa6GPdaCavMCsEXBQ6RMLeE93gqn9eP
	cI5ynS+UdTo7XacWAxaiv/ERWs/+RE4C4rHhE=
MIME-Version: 1.0
Received: by 10.68.59.98 with SMTP id y2mr9787033pbq.70.1321627842348; Fri, 18
	Nov 2011 06:50:42 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 18 Nov 2011 06:50:42 -0800 (PST)
In-Reply-To: <1321623067.3664.346.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<ec94a7e4983ad6338db2.1321617579@loki.upc.es>
	<1321623067.3664.346.camel@zakaz.uk.xensource.com>
Date: Fri, 18 Nov 2011 15:50:42 +0100
X-Google-Sender-Auth: 3ZGBoDGUUPtozstOpMcJSoJajYI
Message-ID: <CAPLaKK62Y0wZ=74_78_q+iEX1Xi6qh6cbh-X4DMfZ__9DOgJug@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec
 function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/18 Ian Campbell <Ian.Campbell@citrix.com>:
> args[n] must be NULL, right?

My bad, fixed it already.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:51:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPmX-0008J3-Hw; Fri, 18 Nov 2011 14:51:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RRPmV-0008Il-TH
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:51:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321627842!4760714!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19755 invoked from network); 18 Nov 2011 14:50:43 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:50:43 -0000
Received: by yenl7 with SMTP id l7so3802324yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 06:50:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=HntGyo3yOKLij8sAwn94tAuUTVZJB8Tswf7sVTbuAWY=;
	b=dkKPapAnfsL4fJRLimLL+F6HqaEV6FQ/xnI4K3rFUJnmT0F2NoED4sVHEXyUonKX5I
	Rk60Wxpn3ApvTvQed94emCNk4hF4Fprw73d/Coa6GPdaCavMCsEXBQ6RMLeE93gqn9eP
	cI5ynS+UdTo7XacWAxaiv/ERWs/+RE4C4rHhE=
MIME-Version: 1.0
Received: by 10.68.59.98 with SMTP id y2mr9787033pbq.70.1321627842348; Fri, 18
	Nov 2011 06:50:42 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 18 Nov 2011 06:50:42 -0800 (PST)
In-Reply-To: <1321623067.3664.346.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<ec94a7e4983ad6338db2.1321617579@loki.upc.es>
	<1321623067.3664.346.camel@zakaz.uk.xensource.com>
Date: Fri, 18 Nov 2011 15:50:42 +0100
X-Google-Sender-Auth: 3ZGBoDGUUPtozstOpMcJSoJajYI
Message-ID: <CAPLaKK62Y0wZ=74_78_q+iEX1Xi6qh6cbh-X4DMfZ__9DOgJug@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec
 function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/18 Ian Campbell <Ian.Campbell@citrix.com>:
> args[n] must be NULL, right?

My bad, fixed it already.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:54:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:54:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPpj-0008UD-7q; Fri, 18 Nov 2011 14:54:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RRPph-0008TZ-7Y
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:54:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321628039!2121639!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2616 invoked from network); 18 Nov 2011 14:54:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 14:54:01 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIErtwh027173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 14:53:55 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
	pAIErscQ026287
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 14:53:54 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIErmMq014879; Fri, 18 Nov 2011 08:53:49 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 06:53:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ADD2F81489; Fri, 18 Nov 2011 09:53:47 -0500 (EST)
Date: Fri, 18 Nov 2011 09:53:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111118145347.GA17708@phenom.dumpdata.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
	<1321543033-22090-5-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321543033-22090-5-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4EC67183.00F1,ss=1,re=0.000,fgs=0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V4 04/10] configure: Introduce
 --enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 03:17:07PM +0000, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  Makefile.target |    2 ++
>  configure       |   25 +++++++++++++++++++++++++
>  2 files changed, 27 insertions(+), 0 deletions(-)
> 
> diff --git a/Makefile.target b/Makefile.target
> index a111521..2e881ce 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -219,6 +219,8 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
>  
>  obj-i386-$(CONFIG_XEN) += xen_platform.o
>  
> +# Xen PCI Passthrough
> +

What is this for? Ah, the next patch plucks some contents
there. You might want to move this Makefile change in the next patch.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:54:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:54:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPpj-0008UD-7q; Fri, 18 Nov 2011 14:54:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RRPph-0008TZ-7Y
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:54:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321628039!2121639!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2616 invoked from network); 18 Nov 2011 14:54:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 14:54:01 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIErtwh027173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 14:53:55 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
	pAIErscQ026287
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 14:53:54 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIErmMq014879; Fri, 18 Nov 2011 08:53:49 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 06:53:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ADD2F81489; Fri, 18 Nov 2011 09:53:47 -0500 (EST)
Date: Fri, 18 Nov 2011 09:53:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111118145347.GA17708@phenom.dumpdata.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
	<1321543033-22090-5-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321543033-22090-5-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4EC67183.00F1,ss=1,re=0.000,fgs=0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V4 04/10] configure: Introduce
 --enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 03:17:07PM +0000, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  Makefile.target |    2 ++
>  configure       |   25 +++++++++++++++++++++++++
>  2 files changed, 27 insertions(+), 0 deletions(-)
> 
> diff --git a/Makefile.target b/Makefile.target
> index a111521..2e881ce 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -219,6 +219,8 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
>  
>  obj-i386-$(CONFIG_XEN) += xen_platform.o
>  
> +# Xen PCI Passthrough
> +

What is this for? Ah, the next patch plucks some contents
there. You might want to move this Makefile change in the next patch.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:55:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPqP-000074-W7; Fri, 18 Nov 2011 14:55:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RRPqO-00006U-Ej
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:55:08 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321628083!3689396!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3370 invoked from network); 18 Nov 2011 14:54:44 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:54:44 -0000
Received: by ywn1 with SMTP id 1so3901099ywn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 06:54:43 -0800 (PST)
Received: by 10.50.203.70 with SMTP id ko6mr3201901igc.19.1321628082545;
	Fri, 18 Nov 2011 06:54:42 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id l28sm3952100ibc.3.2011.11.18.06.54.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 06:54:41 -0800 (PST)
Message-ID: <4EC671AF.5030805@codemonkey.ws>
Date: Fri, 18 Nov 2011 08:54:39 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>	<4EC27D0D.3040204@codemonkey.ws>	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
	<alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"agraf@suse.de" <agraf@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 05:46 AM, Stefano Stabellini wrote:
> On Tue, 15 Nov 2011, Stefano Stabellini wrote:
>> On Tue, 15 Nov 2011, Anthony Liguori wrote:
>>> On 11/15/2011 08:51 AM, stefano.stabellini@eu.citrix.com wrote:
>>>> From: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
>>>>
>>>> Xen doesn't need full RTC emulation in Qemu because the RTC is already
>>>> emulated by the hypervisor. In particular we want to avoid the timers
>>>> initialization so that Qemu doesn't need to wake up needlessly.
>>>>
>>>> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
>>>
>>> Yuck.  There's got to be a better way to do this.
>>
>> Yeah, it is pretty ugly, I was hoping in some good suggestions to
>> improve this patch :)
>>
>>
>>> I think it would be better to name timers and then in Xen specific machine code,
>>> disable the RTC timers.
>>
>> Good idea!
>> I was thinking that I could implement an rtc_stop function in
>> mc146818rtc.c that stops and frees the timers.
>>
>> Now the problem is that from xen-all.c I cannot easily find the
>> ISADevice instance to pass to rtc_stop. Do you think it would be
>> reasonable to call rtc_stop from pc_basic_device_init, inside the same
>> if (!xen_available()) introduce by the next patch?
>>
>> Otherwise I could implement functions to walk the isa bus, similarly to
>> pci_for_each_device.
>>
>
> ping?

Thinking more about it, I think this entire line of thinking is wrong (including 
mine) :-)

The problem you're trying to solve is that the RTC fires two 1 second timers 
regardless of whether the guest is reading the wall clock time, right?  And 
since wall clock time is never read from the QEMU RTC in Xen, it's a huge waste?

The Right Solution would be to modify the RTC emulation such that it did a 
qemu_get_clock() during read of the CMOS registers in order to ensure the time 
was up to date (instead of using 1 second timers).

Then the timers wouldn't even exist anymore.

Regards,

Anthony Liguori

>
>
>> This is just an example:
>>
>> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
>> index 2aaca2f..568c540 100644
>> --- a/hw/mc146818rtc.c
>> +++ b/hw/mc146818rtc.c
>> @@ -667,6 +667,28 @@ ISADevice *rtc_init(int base_year, qemu_irq intercept_irq)
>>       return dev;
>>   }
>>
>> +void rtc_stop(ISADevice *dev)
>> +{
>> +    RTCState *s = DO_UPCAST(RTCState, dev, dev);
>> +
>> +    qemu_del_timer(s->periodic_timer);
>> +    qemu_del_timer(s->second_timer);
>> +    qemu_del_timer(s->second_timer2);
>> +#ifdef TARGET_I386
>> +    if (rtc_td_hack) {
>> +        qemu_del_timer(s->coalesced_timer);
>> +    }
>> +#endif
>> +    qemu_free_timer(s->periodic_timer);
>> +    qemu_free_timer(s->second_timer);
>> +    qemu_free_timer(s->second_timer2);
>> +#ifdef TARGET_I386
>> +    if (rtc_td_hack) {
>> +        qemu_free_timer(s->coalesced_timer);
>> +    }
>> +#endif
>> +}
>> +
>>   static ISADeviceInfo mc146818rtc_info = {
>>       .qdev.name     = "mc146818rtc",
>>       .qdev.size     = sizeof(RTCState),
>> diff --git a/hw/mc146818rtc.h b/hw/mc146818rtc.h
>> index 575968c..aa2b8ab 100644
>> --- a/hw/mc146818rtc.h
>> +++ b/hw/mc146818rtc.h
>> @@ -8,5 +8,6 @@
>>   ISADevice *rtc_init(int base_year, qemu_irq intercept_irq);
>>   void rtc_set_memory(ISADevice *dev, int addr, int val);
>>   void rtc_set_date(ISADevice *dev, const struct tm *tm);
>> +void rtc_stop(ISADevice *dev);
>>
>>   #endif /* !MC146818RTC_H */
>> diff --git a/hw/pc.c b/hw/pc.c
>> index a0ae981..d734f75 100644
>> --- a/hw/pc.c
>> +++ b/hw/pc.c
>> @@ -1145,6 +1145,8 @@ void pc_basic_device_init(qemu_irq *gsi,
>>
>>       if (!xen_available()) {
>>           pit = pit_init(0x40, 0);
>> +    } else {
>> +        rtc_stop(*rtc_state);
>>       }
>>       pcspk_init(pit);
>>
>>
>


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:55:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPqP-000074-W7; Fri, 18 Nov 2011 14:55:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RRPqO-00006U-Ej
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:55:08 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321628083!3689396!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3370 invoked from network); 18 Nov 2011 14:54:44 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:54:44 -0000
Received: by ywn1 with SMTP id 1so3901099ywn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 06:54:43 -0800 (PST)
Received: by 10.50.203.70 with SMTP id ko6mr3201901igc.19.1321628082545;
	Fri, 18 Nov 2011 06:54:42 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id l28sm3952100ibc.3.2011.11.18.06.54.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 18 Nov 2011 06:54:41 -0800 (PST)
Message-ID: <4EC671AF.5030805@codemonkey.ws>
Date: Fri, 18 Nov 2011 08:54:39 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>	<4EC27D0D.3040204@codemonkey.ws>	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
	<alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"agraf@suse.de" <agraf@suse.de>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 05:46 AM, Stefano Stabellini wrote:
> On Tue, 15 Nov 2011, Stefano Stabellini wrote:
>> On Tue, 15 Nov 2011, Anthony Liguori wrote:
>>> On 11/15/2011 08:51 AM, stefano.stabellini@eu.citrix.com wrote:
>>>> From: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
>>>>
>>>> Xen doesn't need full RTC emulation in Qemu because the RTC is already
>>>> emulated by the hypervisor. In particular we want to avoid the timers
>>>> initialization so that Qemu doesn't need to wake up needlessly.
>>>>
>>>> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
>>>
>>> Yuck.  There's got to be a better way to do this.
>>
>> Yeah, it is pretty ugly, I was hoping in some good suggestions to
>> improve this patch :)
>>
>>
>>> I think it would be better to name timers and then in Xen specific machine code,
>>> disable the RTC timers.
>>
>> Good idea!
>> I was thinking that I could implement an rtc_stop function in
>> mc146818rtc.c that stops and frees the timers.
>>
>> Now the problem is that from xen-all.c I cannot easily find the
>> ISADevice instance to pass to rtc_stop. Do you think it would be
>> reasonable to call rtc_stop from pc_basic_device_init, inside the same
>> if (!xen_available()) introduce by the next patch?
>>
>> Otherwise I could implement functions to walk the isa bus, similarly to
>> pci_for_each_device.
>>
>
> ping?

Thinking more about it, I think this entire line of thinking is wrong (including 
mine) :-)

The problem you're trying to solve is that the RTC fires two 1 second timers 
regardless of whether the guest is reading the wall clock time, right?  And 
since wall clock time is never read from the QEMU RTC in Xen, it's a huge waste?

The Right Solution would be to modify the RTC emulation such that it did a 
qemu_get_clock() during read of the CMOS registers in order to ensure the time 
was up to date (instead of using 1 second timers).

Then the timers wouldn't even exist anymore.

Regards,

Anthony Liguori

>
>
>> This is just an example:
>>
>> diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
>> index 2aaca2f..568c540 100644
>> --- a/hw/mc146818rtc.c
>> +++ b/hw/mc146818rtc.c
>> @@ -667,6 +667,28 @@ ISADevice *rtc_init(int base_year, qemu_irq intercept_irq)
>>       return dev;
>>   }
>>
>> +void rtc_stop(ISADevice *dev)
>> +{
>> +    RTCState *s = DO_UPCAST(RTCState, dev, dev);
>> +
>> +    qemu_del_timer(s->periodic_timer);
>> +    qemu_del_timer(s->second_timer);
>> +    qemu_del_timer(s->second_timer2);
>> +#ifdef TARGET_I386
>> +    if (rtc_td_hack) {
>> +        qemu_del_timer(s->coalesced_timer);
>> +    }
>> +#endif
>> +    qemu_free_timer(s->periodic_timer);
>> +    qemu_free_timer(s->second_timer);
>> +    qemu_free_timer(s->second_timer2);
>> +#ifdef TARGET_I386
>> +    if (rtc_td_hack) {
>> +        qemu_free_timer(s->coalesced_timer);
>> +    }
>> +#endif
>> +}
>> +
>>   static ISADeviceInfo mc146818rtc_info = {
>>       .qdev.name     = "mc146818rtc",
>>       .qdev.size     = sizeof(RTCState),
>> diff --git a/hw/mc146818rtc.h b/hw/mc146818rtc.h
>> index 575968c..aa2b8ab 100644
>> --- a/hw/mc146818rtc.h
>> +++ b/hw/mc146818rtc.h
>> @@ -8,5 +8,6 @@
>>   ISADevice *rtc_init(int base_year, qemu_irq intercept_irq);
>>   void rtc_set_memory(ISADevice *dev, int addr, int val);
>>   void rtc_set_date(ISADevice *dev, const struct tm *tm);
>> +void rtc_stop(ISADevice *dev);
>>
>>   #endif /* !MC146818RTC_H */
>> diff --git a/hw/pc.c b/hw/pc.c
>> index a0ae981..d734f75 100644
>> --- a/hw/pc.c
>> +++ b/hw/pc.c
>> @@ -1145,6 +1145,8 @@ void pc_basic_device_init(qemu_irq *gsi,
>>
>>       if (!xen_available()) {
>>           pit = pit_init(0x40, 0);
>> +    } else {
>> +        rtc_stop(*rtc_state);
>>       }
>>       pcspk_init(pit);
>>
>>
>


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:59:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:59:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPuO-0000SH-Qk; Fri, 18 Nov 2011 14:59:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RRPuN-0000S0-CM
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:59:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1321628329!2109582!1
X-Originating-IP: [209.85.210.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17805 invoked from network); 18 Nov 2011 14:58:51 -0000
Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com)
	(209.85.210.49)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:58:51 -0000
Received: by pzk6 with SMTP id 6so6537949pzk.8
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 06:58:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=sSVUjiUEUVLy161j5TD+WzBAT4tp6kRAQ+mdLsgVivw=;
	b=X0Oy1jrUg5E0fecdjViGtQCfmeRxFpznePnN3OUGwTa0OuYAkURWSxZ8NpAFljZCfO
	7D/QEXUSsUcErSY2xRArk5lSUNwl/jL7HtLjXc7R8kfFeUYLjBx+4cPU0RK9acfWYoS/
	fFY9smQCTqD6cSPSxTPPdLc6biEuLN9nVWRJI=
MIME-Version: 1.0
Received: by 10.68.11.233 with SMTP id t9mr4757080pbb.121.1321628329213; Fri,
	18 Nov 2011 06:58:49 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 18 Nov 2011 06:58:49 -0800 (PST)
In-Reply-To: <1321623511.3664.349.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<4ad998fddb16a299cb23.1321617581@loki.upc.es>
	<1321623511.3664.349.camel@zakaz.uk.xensource.com>
Date: Fri, 18 Nov 2011 15:58:49 +0100
X-Google-Sender-Auth: PPO_j_F1txme36gAPOkhMn3GPmo
Message-ID: <CAPLaKK6rSRminrKiXm4AFxwfX3xuSM7NS1vkxVEo5uYZwJGq9A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 9 v2] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/18 Ian Campbell <Ian.Campbell@citrix.com>:
> It would be better to use the XenbusStateFoo constants than the numbers.
> This also applies to the prviosu patch, I just didn't think of it...

Done, I had to include xen/io/xenbus.h to libxl_internal.h to be able
to use XenbusState*.

> Otherwise this looks good.
>
> I'm a little concerned about the synchronous wait here (since it will
> serialise adding all devices). Eventually it should be possible to do
> all the adds and then wait for them all but this is dependent on the
> event infrastructure.

When the OS event patch is added to libxl we will be able to call the
hotplug scripts from the event handler, so we should no longer need to
wait for devices to initialize synchronously.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 14:59:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 14:59:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPuO-0000SH-Qk; Fri, 18 Nov 2011 14:59:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RRPuN-0000S0-CM
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 14:59:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1321628329!2109582!1
X-Originating-IP: [209.85.210.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17805 invoked from network); 18 Nov 2011 14:58:51 -0000
Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com)
	(209.85.210.49)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:58:51 -0000
Received: by pzk6 with SMTP id 6so6537949pzk.8
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 06:58:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=sSVUjiUEUVLy161j5TD+WzBAT4tp6kRAQ+mdLsgVivw=;
	b=X0Oy1jrUg5E0fecdjViGtQCfmeRxFpznePnN3OUGwTa0OuYAkURWSxZ8NpAFljZCfO
	7D/QEXUSsUcErSY2xRArk5lSUNwl/jL7HtLjXc7R8kfFeUYLjBx+4cPU0RK9acfWYoS/
	fFY9smQCTqD6cSPSxTPPdLc6biEuLN9nVWRJI=
MIME-Version: 1.0
Received: by 10.68.11.233 with SMTP id t9mr4757080pbb.121.1321628329213; Fri,
	18 Nov 2011 06:58:49 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 18 Nov 2011 06:58:49 -0800 (PST)
In-Reply-To: <1321623511.3664.349.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<4ad998fddb16a299cb23.1321617581@loki.upc.es>
	<1321623511.3664.349.camel@zakaz.uk.xensource.com>
Date: Fri, 18 Nov 2011 15:58:49 +0100
X-Google-Sender-Auth: PPO_j_F1txme36gAPOkhMn3GPmo
Message-ID: <CAPLaKK6rSRminrKiXm4AFxwfX3xuSM7NS1vkxVEo5uYZwJGq9A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5 of 9 v2] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/18 Ian Campbell <Ian.Campbell@citrix.com>:
> It would be better to use the XenbusStateFoo constants than the numbers.
> This also applies to the prviosu patch, I just didn't think of it...

Done, I had to include xen/io/xenbus.h to libxl_internal.h to be able
to use XenbusState*.

> Otherwise this looks good.
>
> I'm a little concerned about the synchronous wait here (since it will
> serialise adding all devices). Eventually it should be possible to do
> all the adds and then wait for them all but this is dependent on the
> event infrastructure.

When the OS event patch is added to libxl we will be able to call the
hotplug scripts from the event handler, so we should no longer need to
wait for devices to initialize synchronously.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:00:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPvK-0000WM-Jm; Fri, 18 Nov 2011 15:00:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RRPvI-0000Vz-W1
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:00:13 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1321628388!4785467!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21481 invoked from network); 18 Nov 2011 14:59:49 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:59:49 -0000
Received: by iaby12 with SMTP id y12so4784615iab.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 06:59:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=XYe0J/X21iv15TI3qXXdKS68macUnFO2vjoB14NKo1I=;
	b=IQOOdjLBsRRLnqN6ngnW/emSAIwy0Dm/cbSE5QQag3EDpfm3VWDiX7+dWav72rdi0j
	htYhsgHc/vg8QnxygHRk/3vaLNwoBXElxgDBqe3vnti+IRw8m/ikECdJJiEXN13dZXlN
	vV3fawmy7kk4xRsUHOjlcdBCblFv9uY8lJxWg=
MIME-Version: 1.0
Received: by 10.42.137.6 with SMTP id w6mr3440343ict.5.1321628387798; Fri, 18
	Nov 2011 06:59:47 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Fri, 18 Nov 2011 06:59:47 -0800 (PST)
In-Reply-To: <patchbomb.1321612941@gran.amd.com>
References: <patchbomb.1321612941@gran.amd.com>
Date: Fri, 18 Nov 2011 14:59:47 +0000
X-Google-Sender-Auth: Ow3BByIhiy8IKaz90-u_ytzfcsA
Message-ID: <CAFLBxZaHB9U2JCMHVw9TT4cvYAUPkCL8W51=3iNJVj1y32_JLQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Cc: xen-devel@lists.xensource.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] amd iommu: IOMMUv2 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 10:42 AM, Wei Wang <wei.wang2@amd.com> wrote:
> This patch set adds basic supports for amd next generation iommu (IOMMUv2)
> hardware. IOMMUv2 supports various new features advertised by iommu
> extended feature register. It introduces guest level IO translation and
> supports state-of-the-art ATS/ATC devices with demand paging capability.
> Please refer to AMD IOMMU Architectural Specification [1] for more details.

Wei,

When is this hardware likely to be in the hands of customers?
 -George

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:00:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:00:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRPvK-0000WM-Jm; Fri, 18 Nov 2011 15:00:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RRPvI-0000Vz-W1
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:00:13 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1321628388!4785467!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21481 invoked from network); 18 Nov 2011 14:59:49 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 14:59:49 -0000
Received: by iaby12 with SMTP id y12so4784615iab.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 06:59:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=XYe0J/X21iv15TI3qXXdKS68macUnFO2vjoB14NKo1I=;
	b=IQOOdjLBsRRLnqN6ngnW/emSAIwy0Dm/cbSE5QQag3EDpfm3VWDiX7+dWav72rdi0j
	htYhsgHc/vg8QnxygHRk/3vaLNwoBXElxgDBqe3vnti+IRw8m/ikECdJJiEXN13dZXlN
	vV3fawmy7kk4xRsUHOjlcdBCblFv9uY8lJxWg=
MIME-Version: 1.0
Received: by 10.42.137.6 with SMTP id w6mr3440343ict.5.1321628387798; Fri, 18
	Nov 2011 06:59:47 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Fri, 18 Nov 2011 06:59:47 -0800 (PST)
In-Reply-To: <patchbomb.1321612941@gran.amd.com>
References: <patchbomb.1321612941@gran.amd.com>
Date: Fri, 18 Nov 2011 14:59:47 +0000
X-Google-Sender-Auth: Ow3BByIhiy8IKaz90-u_ytzfcsA
Message-ID: <CAFLBxZaHB9U2JCMHVw9TT4cvYAUPkCL8W51=3iNJVj1y32_JLQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Wei Wang <wei.wang2@amd.com>
Cc: xen-devel@lists.xensource.com, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 0 of 4] amd iommu: IOMMUv2 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 10:42 AM, Wei Wang <wei.wang2@amd.com> wrote:
> This patch set adds basic supports for amd next generation iommu (IOMMUv2)
> hardware. IOMMUv2 supports various new features advertised by iommu
> extended feature register. It introduces guest level IO translation and
> supports state-of-the-art ATS/ATC devices with demand paging capability.
> Please refer to AMD IOMMU Architectural Specification [1] for more details.

Wei,

When is this hardware likely to be in the hands of customers?
 -George

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:07:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQ1v-0004oF-Pd; Fri, 18 Nov 2011 15:07:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RRQ1t-0004o2-Eo
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:07:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1321628796!4101633!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19425 invoked from network); 18 Nov 2011 15:06:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 15:06:37 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIF6UHE012162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 15:06:30 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIF6ThC026010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 15:06:29 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIF6N0f020913; Fri, 18 Nov 2011 09:06:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 07:06:23 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 213AF81489; Fri, 18 Nov 2011 10:06:22 -0500 (EST)
Date: Fri, 18 Nov 2011 10:06:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111118150622.GB17708@phenom.dumpdata.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
	<1321543033-22090-6-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321543033-22090-6-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EC67478.0027,ss=1,re=0.000,fgs=0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V4 05/10] Introduce HostPCIDevice to access
 a pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 03:17:08PM +0000, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  Makefile.target      |    1 +
>  hw/host-pci-device.c |  279 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  hw/host-pci-device.h |   75 ++++++++++++++
>  3 files changed, 355 insertions(+), 0 deletions(-)
>  create mode 100644 hw/host-pci-device.c
>  create mode 100644 hw/host-pci-device.h
> 
> diff --git a/Makefile.target b/Makefile.target
> index 2e881ce..e527c1b 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -220,6 +220,7 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
>  obj-i386-$(CONFIG_XEN) += xen_platform.o
>  
>  # Xen PCI Passthrough
> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
>  
>  # Inter-VM PCI shared memory
>  CONFIG_IVSHMEM =
> diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
> new file mode 100644
> index 0000000..06f7761
> --- /dev/null
> +++ b/hw/host-pci-device.c
> @@ -0,0 +1,279 @@
> +/*
> + * Copyright (C) 2011       Citrix Ltd.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include "qemu-common.h"
> +#include "host-pci-device.h"
> +
> +#define PCI_MAX_EXT_CAP \
> +    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
> +
> +enum error_code {
> +    ERROR_SYNTAX = 1,
> +};
> +
> +static int path_to(const HostPCIDevice *d,
> +                   const char *name, char *buf, ssize_t size)
> +{
> +    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
> +                    d->domain, d->bus, d->dev, d->func, name);
> +}
> +
> +static int get_resource(HostPCIDevice *d)
> +{
> +    int i, rc = 0;
> +    FILE *f;
> +    char path[PATH_MAX];
> +    unsigned long long start, end, flags, size;
> +
> +    path_to(d, "resource", path, sizeof (path));
> +    f = fopen(path, "r");
> +    if (!f) {
> +        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
> +        return -errno;
> +    }
> +
> +    for (i = 0; i < PCI_NUM_REGIONS; i++) {
> +        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
> +            fprintf(stderr, "Error: Syntax error in %s\n", path);
> +            rc = ERROR_SYNTAX;
> +            break;
> +        }
> +        if (start) {
> +            size = end - start + 1;
> +        } else {
> +            size = 0;
> +        }
> +
> +        if (i < PCI_ROM_SLOT) {
> +            d->io_regions[i].base_addr = start;
> +            d->io_regions[i].size = size;
> +            d->io_regions[i].flags = flags;
> +        } else {
> +            d->rom.base_addr = start;
> +            d->rom.size = size;
> +            d->rom.flags = flags;
> +        }
> +    }
> +
> +    fclose(f);
> +    return rc;
> +}
> +
> +static int get_value(HostPCIDevice *d, const char *name, unsigned long *pvalue)

Perhaps 'get_hex_value'? You are just doing %lx, not %ld, so it has
to have to an exact format to get the contents right.

> +{
> +    char path[PATH_MAX];
> +    FILE *f;
> +    unsigned long value;
> +
> +    path_to(d, name, path, sizeof (path));
> +    f = fopen(path, "r");
> +    if (!f) {
> +        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
> +        return -1;

So the get_resource can return 0, 1, or -errno. This one can return
0, or -1. Would it make sense to duplicate the -errno mechanism
that you employed in get_resources to have uniformity?

> +    }
> +    if (fscanf(f, "%lx\n", &value) != 1) {
> +        fprintf(stderr, "Error: Syntax error in %s\n", path);
> +        return -1;
> +    }
> +    fclose(f);
> +    *pvalue = value;
> +    return 0;
> +}
> +
> +static bool pci_dev_is_virtfn(HostPCIDevice *d)
> +{
> +    int rc;
> +    char path[PATH_MAX];
> +    struct stat buf;
> +
> +    path_to(d, "physfn", path, sizeof (path));
> +    rc = !stat(path, &buf);
> +
> +    return rc;
> +}
> +
> +static int host_pci_config_fd(HostPCIDevice *d)
> +{
> +    char path[PATH_MAX];
> +
> +    if (d->config_fd < 0) {
> +        path_to(d, "config", path, sizeof (path));
> +        d->config_fd = open(path, O_RDWR);
> +        if (d->config_fd < 0) {
> +            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
> +                    path, strerror(errno));
> +        }
> +    }
> +    return d->config_fd;
> +}
> +static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
> +{
> +    int fd = host_pci_config_fd(d);
> +    int res = 0;
> +
> +again:
> +    res = pread(fd, buf, len, pos);
> +    if (res != len) {
> +        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
> +            goto again;
> +        }
> +        fprintf(stderr, "host_pci_config: read failed: %s (fd: %i)\n",

Well, the comment says 'host_pci_config', but that is not the name
of the function. Perhaps replace it with '%s' and use __func__
as one of the parameters?

> +                strerror(errno), fd);
> +        return -errno;
> +    }
> +    return 0;
> +}
> +static int host_pci_config_write(HostPCIDevice *d,
> +                                 int pos, const void *buf, int len)
> +{
> +    int fd = host_pci_config_fd(d);
> +    int res = 0;
> +
> +again:
> +    res = pwrite(fd, buf, len, pos);
> +    if (res != len) {
> +        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
> +            goto again;
> +        }
> +        fprintf(stderr, "host_pci_config: write failed: %s\n",
> +                strerror(errno));
> +        return -errno;
> +    }
> +    return 0;
> +}
> +
> +int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
> +{
> +  uint8_t buf;
> +  if (host_pci_config_read(d, pos, &buf, 1)) {
> +      return -1;

Would it make sense to use the nice enum you decleraed at the
top of the file?  Or not?

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:07:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQ1v-0004oF-Pd; Fri, 18 Nov 2011 15:07:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RRQ1t-0004o2-Eo
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:07:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1321628796!4101633!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19425 invoked from network); 18 Nov 2011 15:06:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 15:06:37 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIF6UHE012162
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 15:06:30 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIF6ThC026010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 15:06:29 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIF6N0f020913; Fri, 18 Nov 2011 09:06:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 07:06:23 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 213AF81489; Fri, 18 Nov 2011 10:06:22 -0500 (EST)
Date: Fri, 18 Nov 2011 10:06:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111118150622.GB17708@phenom.dumpdata.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
	<1321543033-22090-6-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321543033-22090-6-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EC67478.0027,ss=1,re=0.000,fgs=0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V4 05/10] Introduce HostPCIDevice to access
 a pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 17, 2011 at 03:17:08PM +0000, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  Makefile.target      |    1 +
>  hw/host-pci-device.c |  279 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  hw/host-pci-device.h |   75 ++++++++++++++
>  3 files changed, 355 insertions(+), 0 deletions(-)
>  create mode 100644 hw/host-pci-device.c
>  create mode 100644 hw/host-pci-device.h
> 
> diff --git a/Makefile.target b/Makefile.target
> index 2e881ce..e527c1b 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -220,6 +220,7 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
>  obj-i386-$(CONFIG_XEN) += xen_platform.o
>  
>  # Xen PCI Passthrough
> +obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
>  
>  # Inter-VM PCI shared memory
>  CONFIG_IVSHMEM =
> diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
> new file mode 100644
> index 0000000..06f7761
> --- /dev/null
> +++ b/hw/host-pci-device.c
> @@ -0,0 +1,279 @@
> +/*
> + * Copyright (C) 2011       Citrix Ltd.
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2.  See
> + * the COPYING file in the top-level directory.
> + *
> + */
> +
> +#include "qemu-common.h"
> +#include "host-pci-device.h"
> +
> +#define PCI_MAX_EXT_CAP \
> +    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
> +
> +enum error_code {
> +    ERROR_SYNTAX = 1,
> +};
> +
> +static int path_to(const HostPCIDevice *d,
> +                   const char *name, char *buf, ssize_t size)
> +{
> +    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
> +                    d->domain, d->bus, d->dev, d->func, name);
> +}
> +
> +static int get_resource(HostPCIDevice *d)
> +{
> +    int i, rc = 0;
> +    FILE *f;
> +    char path[PATH_MAX];
> +    unsigned long long start, end, flags, size;
> +
> +    path_to(d, "resource", path, sizeof (path));
> +    f = fopen(path, "r");
> +    if (!f) {
> +        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
> +        return -errno;
> +    }
> +
> +    for (i = 0; i < PCI_NUM_REGIONS; i++) {
> +        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
> +            fprintf(stderr, "Error: Syntax error in %s\n", path);
> +            rc = ERROR_SYNTAX;
> +            break;
> +        }
> +        if (start) {
> +            size = end - start + 1;
> +        } else {
> +            size = 0;
> +        }
> +
> +        if (i < PCI_ROM_SLOT) {
> +            d->io_regions[i].base_addr = start;
> +            d->io_regions[i].size = size;
> +            d->io_regions[i].flags = flags;
> +        } else {
> +            d->rom.base_addr = start;
> +            d->rom.size = size;
> +            d->rom.flags = flags;
> +        }
> +    }
> +
> +    fclose(f);
> +    return rc;
> +}
> +
> +static int get_value(HostPCIDevice *d, const char *name, unsigned long *pvalue)

Perhaps 'get_hex_value'? You are just doing %lx, not %ld, so it has
to have to an exact format to get the contents right.

> +{
> +    char path[PATH_MAX];
> +    FILE *f;
> +    unsigned long value;
> +
> +    path_to(d, name, path, sizeof (path));
> +    f = fopen(path, "r");
> +    if (!f) {
> +        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
> +        return -1;

So the get_resource can return 0, 1, or -errno. This one can return
0, or -1. Would it make sense to duplicate the -errno mechanism
that you employed in get_resources to have uniformity?

> +    }
> +    if (fscanf(f, "%lx\n", &value) != 1) {
> +        fprintf(stderr, "Error: Syntax error in %s\n", path);
> +        return -1;
> +    }
> +    fclose(f);
> +    *pvalue = value;
> +    return 0;
> +}
> +
> +static bool pci_dev_is_virtfn(HostPCIDevice *d)
> +{
> +    int rc;
> +    char path[PATH_MAX];
> +    struct stat buf;
> +
> +    path_to(d, "physfn", path, sizeof (path));
> +    rc = !stat(path, &buf);
> +
> +    return rc;
> +}
> +
> +static int host_pci_config_fd(HostPCIDevice *d)
> +{
> +    char path[PATH_MAX];
> +
> +    if (d->config_fd < 0) {
> +        path_to(d, "config", path, sizeof (path));
> +        d->config_fd = open(path, O_RDWR);
> +        if (d->config_fd < 0) {
> +            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
> +                    path, strerror(errno));
> +        }
> +    }
> +    return d->config_fd;
> +}
> +static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
> +{
> +    int fd = host_pci_config_fd(d);
> +    int res = 0;
> +
> +again:
> +    res = pread(fd, buf, len, pos);
> +    if (res != len) {
> +        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
> +            goto again;
> +        }
> +        fprintf(stderr, "host_pci_config: read failed: %s (fd: %i)\n",

Well, the comment says 'host_pci_config', but that is not the name
of the function. Perhaps replace it with '%s' and use __func__
as one of the parameters?

> +                strerror(errno), fd);
> +        return -errno;
> +    }
> +    return 0;
> +}
> +static int host_pci_config_write(HostPCIDevice *d,
> +                                 int pos, const void *buf, int len)
> +{
> +    int fd = host_pci_config_fd(d);
> +    int res = 0;
> +
> +again:
> +    res = pwrite(fd, buf, len, pos);
> +    if (res != len) {
> +        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
> +            goto again;
> +        }
> +        fprintf(stderr, "host_pci_config: write failed: %s\n",
> +                strerror(errno));
> +        return -errno;
> +    }
> +    return 0;
> +}
> +
> +int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
> +{
> +  uint8_t buf;
> +  if (host_pci_config_read(d, pos, &buf, 1)) {
> +      return -1;

Would it make sense to use the nice enum you decleraed at the
top of the file?  Or not?

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:10:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:10:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQ4e-0004vU-Ee; Fri, 18 Nov 2011 15:09:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRQ4d-0004vI-6T
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:09:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321628967!3693436!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21209 invoked from network); 18 Nov 2011 15:09:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 15:09:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9013382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 15:09:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 15:09:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>, <stable@vger.kernel.org>
Date: Fri, 18 Nov 2011 15:09:26 +0000
In-Reply-To: <1321625599-3739-1-git-send-email-ian.campbell@citrix.com>
References: <1321625599-3739-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321628966.3664.363.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan
	Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen-netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 14:13 +0000, Ian Campbell wrote:
> From: Jan Beulich <JBeulich@suse.com>
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

I forgot to CC stable@ here. This applies to 2.6.39 onwards.

> ---
>  drivers/net/xen-netback/netback.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 0cb594c..1ae270e 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1021,7 +1021,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
>  		pending_idx = *((u16 *)skb->data);
>  		xen_netbk_idx_release(netbk, pending_idx);
>  		for (j = start; j < i; j++) {
> -			pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
> +			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
>  			xen_netbk_idx_release(netbk, pending_idx);
>  		}
>  



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:10:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:10:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQ4e-0004vU-Ee; Fri, 18 Nov 2011 15:09:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRQ4d-0004vI-6T
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:09:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321628967!3693436!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21209 invoked from network); 18 Nov 2011 15:09:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 15:09:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9013382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 15:09:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 15:09:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>, <stable@vger.kernel.org>
Date: Fri, 18 Nov 2011 15:09:26 +0000
In-Reply-To: <1321625599-3739-1-git-send-email-ian.campbell@citrix.com>
References: <1321625599-3739-1-git-send-email-ian.campbell@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321628966.3664.363.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan
	Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] xen-netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 14:13 +0000, Ian Campbell wrote:
> From: Jan Beulich <JBeulich@suse.com>
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

I forgot to CC stable@ here. This applies to 2.6.39 onwards.

> ---
>  drivers/net/xen-netback/netback.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 0cb594c..1ae270e 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1021,7 +1021,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
>  		pending_idx = *((u16 *)skb->data);
>  		xen_netbk_idx_release(netbk, pending_idx);
>  		for (j = start; j < i; j++) {
> -			pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
> +			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
>  			xen_netbk_idx_release(netbk, pending_idx);
>  		}
>  



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:20:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:20:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQEx-0005F9-Dg; Fri, 18 Nov 2011 15:20:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRQEv-0005El-Ns
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:20:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1321629570!46476368!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14176 invoked from network); 18 Nov 2011 15:19:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 15:19:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9013632"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 15:20:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 15:20:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 15:20:04 +0000
In-Reply-To: <CAPLaKK5drHeZPOCsSro0d57z0r8o19p4so3VECcE2R5URAyy5w@mail.gmail.com>
References: <patchbomb.1321617576@loki.upc.es>
	<9e8abd626484f82a95d0.1321617578@loki.upc.es>
	<1321622877.3664.344.camel@zakaz.uk.xensource.com>
	<CAPLaKK5drHeZPOCsSro0d57z0r8o19p4so3VECcE2R5URAyy5w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321629605.3664.365.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 9 v2] libxl: add support for image
 files for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTExLTE4IGF0IDE0OjQ5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTEvMTggSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBGcmksIDIwMTEtMTEtMTggYXQgMTE6NTkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90
ZToKPiA+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ID4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+ID4+ICMgRGF0ZSAxMzE3Mzg2MzM1IC03MjAwCj4g
Pj4gIyBOb2RlIElEIDllOGFiZDYyNjQ4NGY4MmE5NWQwZWRjMDc4MzRhZTI4N2JjOTQ2N2EKPiA+
PiAjIFBhcmVudCAgMjM1NzhjOTk0MmJjYzg3NjdhZGM0ZTQzNWJiMWZkMWNkODlmNWUxOAo+ID4+
IGxpYnhsOiBhZGQgc3VwcG9ydCBmb3IgaW1hZ2UgZmlsZXMgZm9yIE5ldEJTRAo+ID4+Cj4gPj4g
Q3JlYXRlZCBhIGhlbHBlciBmdW5jdGlvbiB0byBkZXRlY3QgaWYgdGhlIE9TIGlzIGNhcGFibGUg
b2YgdXNpbmcKPiA+PiBpbWFnZSBmaWxlcyBhcyBwaHkgYmFja2VuZHMuIENyZWF0ZSB0d28gT1Mg
c3BlY2lmaWMgZmlsZXMsIGFuZAo+ID4+IGNoYW5nZWQgdGhlIE1ha2VmaWxlIHRvIGNob29zZSB0
aGUgY29ycmVjdCBvbmUgYXQgY29tcGlsZSB0aW1lLgo+ID4+Cj4gPj4gU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+Pgo+ID4+IGRpZmYg
LXIgMjM1NzhjOTk0MmJjIC1yIDllOGFiZDYyNjQ4NCB0b29scy9saWJ4bC9NYWtlZmlsZQo+ID4+
IC0tLSBhL3Rvb2xzL2xpYnhsL01ha2VmaWxlICAgIEZyaSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSAr
MDIwMAo+ID4+ICsrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlICAgIEZyaSBTZXAgMzAgMTQ6Mzg6
NTUgMjAxMSArMDIwMAo+ID4+IEBAIC0zMiw2ICszMiwxMiBAQCBlbmRpZgo+ID4+ICBMSUJYTF9P
QkpTLSQoQ09ORklHX1g4NikgKz0gbGlieGxfY3B1aWQubwo+ID4+ICBMSUJYTF9PQkpTLSQoQ09O
RklHX0lBNjQpICs9IGxpYnhsX25vY3B1aWQubwo+ID4+Cj4gPj4gK2lmZXEgKCQoQ09ORklHX05l
dEJTRCkseSkKPiA+PiArTElCWExfT0JKUy15ICs9IGxpYnhsX3BoeWJhY2tlbmQubwo+ID4+ICtl
bHNlCj4gPj4gK0xJQlhMX09CSlMteSArPSBsaWJ4bF9ub3BoeWJhY2tlbmQubwo+ID4KPiA+IHBo
eSB2cyBub3BoeSBkb24ndCByZWFsbHkgbWFrZSBzZW5zZSB0byBtZSBoZXJlLCBzaW5jZSBpbiBi
b3RoIGNhc2VzIHRoZQo+ID4gY29udGVudCByZWxhdGVzIHRvIHRoZSBwaHkgYmFja2VuZC4KPiA+
Cj4gPiBQZXJoYXBzIHdlIG5lZWQgbGlieGxfJChPUykuYyB0byBjb250YWluIG9zIHNwZWNpZmlj
IHN0dWZmPwo+IAo+IEEgbGlieGxfJChPUykuYyBzb3VuZHMgaW50ZXJlc3RpbmcsIEkgY291bGQg
cHV0IGhvdHBsdWcgYW5kIGJhY2tlbmQgT1MKPiBzcGVjaWZpYyBjb2RlIHRoZXJlLCBidXQgSSdt
IGFmcmFpZCBpdCBtaWdodCBnZXQgY3Jvd2RlZCBhbmQgYmVjb21lCj4gZGlmZmljdWx0IHRvIHVu
ZGVyc3RhbmQuIElmIEkgZG9uJ3QgcmVjZWl2ZSBhbnkgb3RoZXIgc3VnZ2VzdGlvbnMsIEkKPiB3
aWxsIGNyZWF0ZSBhIGxpYnhsX25ldGJzZC5jIGFuZCBsaWJ4bF9saW51eC5jIChhbmQgbGlieGxf
c29sYXJpcy5jPykKPiBhbmQgcGxhY2UgdGhlIGhvdHBsdWcgYW5kIGJhY2tlbmQgaGVscGVyIGZ1
bmN0aW9ucyB0aGVyZS4KCkknbSByZWFsbHkgbm90IHN1cmUgd2hhdCB0aGUgYmVzdCBhbnN3ZXIg
aXMgaGVyZS4KCkZXSVcgdGhlIFNvbGFyaXMgZG9tMCBzdHVmZiBoYXMgYmVlbiB1bm1haW50YWlu
ZWQgZm9yIGEgZmFpciB3aGlsZSwgSQpkb24ndCB0aGluayB5b3UgbmVlZCB0byBidXJkZW4geW91
cnNlbGYgd2l0aCBpdC4KCklhbi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:20:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:20:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQEx-0005F9-Dg; Fri, 18 Nov 2011 15:20:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRQEv-0005El-Ns
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:20:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1321629570!46476368!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14176 invoked from network); 18 Nov 2011 15:19:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 15:19:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9013632"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 15:20:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 15:20:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 18 Nov 2011 15:20:04 +0000
In-Reply-To: <CAPLaKK5drHeZPOCsSro0d57z0r8o19p4so3VECcE2R5URAyy5w@mail.gmail.com>
References: <patchbomb.1321617576@loki.upc.es>
	<9e8abd626484f82a95d0.1321617578@loki.upc.es>
	<1321622877.3664.344.camel@zakaz.uk.xensource.com>
	<CAPLaKK5drHeZPOCsSro0d57z0r8o19p4so3VECcE2R5URAyy5w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321629605.3664.365.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 9 v2] libxl: add support for image
 files for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTExLTE4IGF0IDE0OjQ5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTEvMTggSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBGcmksIDIwMTEtMTEtMTggYXQgMTE6NTkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90
ZToKPiA+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ID4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+ID4+ICMgRGF0ZSAxMzE3Mzg2MzM1IC03MjAwCj4g
Pj4gIyBOb2RlIElEIDllOGFiZDYyNjQ4NGY4MmE5NWQwZWRjMDc4MzRhZTI4N2JjOTQ2N2EKPiA+
PiAjIFBhcmVudCAgMjM1NzhjOTk0MmJjYzg3NjdhZGM0ZTQzNWJiMWZkMWNkODlmNWUxOAo+ID4+
IGxpYnhsOiBhZGQgc3VwcG9ydCBmb3IgaW1hZ2UgZmlsZXMgZm9yIE5ldEJTRAo+ID4+Cj4gPj4g
Q3JlYXRlZCBhIGhlbHBlciBmdW5jdGlvbiB0byBkZXRlY3QgaWYgdGhlIE9TIGlzIGNhcGFibGUg
b2YgdXNpbmcKPiA+PiBpbWFnZSBmaWxlcyBhcyBwaHkgYmFja2VuZHMuIENyZWF0ZSB0d28gT1Mg
c3BlY2lmaWMgZmlsZXMsIGFuZAo+ID4+IGNoYW5nZWQgdGhlIE1ha2VmaWxlIHRvIGNob29zZSB0
aGUgY29ycmVjdCBvbmUgYXQgY29tcGlsZSB0aW1lLgo+ID4+Cj4gPj4gU2lnbmVkLW9mZi1ieTog
Um9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+Pgo+ID4+IGRpZmYg
LXIgMjM1NzhjOTk0MmJjIC1yIDllOGFiZDYyNjQ4NCB0b29scy9saWJ4bC9NYWtlZmlsZQo+ID4+
IC0tLSBhL3Rvb2xzL2xpYnhsL01ha2VmaWxlICAgIEZyaSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSAr
MDIwMAo+ID4+ICsrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlICAgIEZyaSBTZXAgMzAgMTQ6Mzg6
NTUgMjAxMSArMDIwMAo+ID4+IEBAIC0zMiw2ICszMiwxMiBAQCBlbmRpZgo+ID4+ICBMSUJYTF9P
QkpTLSQoQ09ORklHX1g4NikgKz0gbGlieGxfY3B1aWQubwo+ID4+ICBMSUJYTF9PQkpTLSQoQ09O
RklHX0lBNjQpICs9IGxpYnhsX25vY3B1aWQubwo+ID4+Cj4gPj4gK2lmZXEgKCQoQ09ORklHX05l
dEJTRCkseSkKPiA+PiArTElCWExfT0JKUy15ICs9IGxpYnhsX3BoeWJhY2tlbmQubwo+ID4+ICtl
bHNlCj4gPj4gK0xJQlhMX09CSlMteSArPSBsaWJ4bF9ub3BoeWJhY2tlbmQubwo+ID4KPiA+IHBo
eSB2cyBub3BoeSBkb24ndCByZWFsbHkgbWFrZSBzZW5zZSB0byBtZSBoZXJlLCBzaW5jZSBpbiBi
b3RoIGNhc2VzIHRoZQo+ID4gY29udGVudCByZWxhdGVzIHRvIHRoZSBwaHkgYmFja2VuZC4KPiA+
Cj4gPiBQZXJoYXBzIHdlIG5lZWQgbGlieGxfJChPUykuYyB0byBjb250YWluIG9zIHNwZWNpZmlj
IHN0dWZmPwo+IAo+IEEgbGlieGxfJChPUykuYyBzb3VuZHMgaW50ZXJlc3RpbmcsIEkgY291bGQg
cHV0IGhvdHBsdWcgYW5kIGJhY2tlbmQgT1MKPiBzcGVjaWZpYyBjb2RlIHRoZXJlLCBidXQgSSdt
IGFmcmFpZCBpdCBtaWdodCBnZXQgY3Jvd2RlZCBhbmQgYmVjb21lCj4gZGlmZmljdWx0IHRvIHVu
ZGVyc3RhbmQuIElmIEkgZG9uJ3QgcmVjZWl2ZSBhbnkgb3RoZXIgc3VnZ2VzdGlvbnMsIEkKPiB3
aWxsIGNyZWF0ZSBhIGxpYnhsX25ldGJzZC5jIGFuZCBsaWJ4bF9saW51eC5jIChhbmQgbGlieGxf
c29sYXJpcy5jPykKPiBhbmQgcGxhY2UgdGhlIGhvdHBsdWcgYW5kIGJhY2tlbmQgaGVscGVyIGZ1
bmN0aW9ucyB0aGVyZS4KCkknbSByZWFsbHkgbm90IHN1cmUgd2hhdCB0aGUgYmVzdCBhbnN3ZXIg
aXMgaGVyZS4KCkZXSVcgdGhlIFNvbGFyaXMgZG9tMCBzdHVmZiBoYXMgYmVlbiB1bm1haW50YWlu
ZWQgZm9yIGEgZmFpciB3aGlsZSwgSQpkb24ndCB0aGluayB5b3UgbmVlZCB0byBidXJkZW4geW91
cnNlbGYgd2l0aCBpdC4KCklhbi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:38:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQWV-0005U7-Ix; Fri, 18 Nov 2011 15:38:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRQWU-0005U2-P0
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:38:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1321630694!2106026!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25510 invoked from network); 18 Nov 2011 15:38:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 15:38:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9014127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 15:38:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 15:38:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Date: Fri, 18 Nov 2011 15:38:13 +0000
In-Reply-To: <1321628966.3664.363.camel@zakaz.uk.xensource.com>
References: <1321625599-3739-1-git-send-email-ian.campbell@citrix.com>
	<1321628966.3664.363.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321630693.3664.366.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>, stable@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 15:09 +0000, Ian Campbell wrote:
> On Fri, 2011-11-18 at 14:13 +0000, Ian Campbell wrote:
> > From: Jan Beulich <JBeulich@suse.com>
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I forgot to CC stable@ here. This applies to 2.6.39 onwards.

I also neglected to change the subject line to the correct upstream
function name. Please ignore this patch, I'll try again...

Ian.

> 
> > ---
> >  drivers/net/xen-netback/netback.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 0cb594c..1ae270e 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -1021,7 +1021,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
> >  		pending_idx = *((u16 *)skb->data);
> >  		xen_netbk_idx_release(netbk, pending_idx);
> >  		for (j = start; j < i; j++) {
> > -			pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
> > +			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
> >  			xen_netbk_idx_release(netbk, pending_idx);
> >  		}
> >  
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:38:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQWV-0005U7-Ix; Fri, 18 Nov 2011 15:38:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRQWU-0005U2-P0
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:38:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1321630694!2106026!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25510 invoked from network); 18 Nov 2011 15:38:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 15:38:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9014127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 15:38:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.137.0;
	Fri, 18 Nov 2011 15:38:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Date: Fri, 18 Nov 2011 15:38:13 +0000
In-Reply-To: <1321628966.3664.363.camel@zakaz.uk.xensource.com>
References: <1321625599-3739-1-git-send-email-ian.campbell@citrix.com>
	<1321628966.3664.363.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321630693.3664.366.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>, stable@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 15:09 +0000, Ian Campbell wrote:
> On Fri, 2011-11-18 at 14:13 +0000, Ian Campbell wrote:
> > From: Jan Beulich <JBeulich@suse.com>
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I forgot to CC stable@ here. This applies to 2.6.39 onwards.

I also neglected to change the subject line to the correct upstream
function name. Please ignore this patch, I'll try again...

Ian.

> 
> > ---
> >  drivers/net/xen-netback/netback.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 0cb594c..1ae270e 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -1021,7 +1021,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
> >  		pending_idx = *((u16 *)skb->data);
> >  		xen_netbk_idx_release(netbk, pending_idx);
> >  		for (j = start; j < i; j++) {
> > -			pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
> > +			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
> >  			xen_netbk_idx_release(netbk, pending_idx);
> >  		}
> >  
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:43:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQaO-0005gk-GE; Fri, 18 Nov 2011 15:42:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRQaN-0005gO-Bo
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:42:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321630933!2062232!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4499 invoked from network); 18 Nov 2011 15:42:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 15:42:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315195200"; d="scan'208";a="171157966"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:42:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 10:42:13 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAIFg5cv031993;	Fri, 18 Nov 2011 07:42:06 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Fri, 18 Nov 2011 15:42:05 +0000
Message-ID: <1321630925-13652-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: stable@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen-netback: use correct index for invalidation
	in xen_netbk_tx_check_gop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jan Beulich <JBeulich@suse.com>

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: stable@vger.kernel.org
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 0cb594c..1ae270e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1021,7 +1021,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		pending_idx = *((u16 *)skb->data);
 		xen_netbk_idx_release(netbk, pending_idx);
 		for (j = start; j < i; j++) {
-			pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
+			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
 			xen_netbk_idx_release(netbk, pending_idx);
 		}
 
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 15:43:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 15:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQaO-0005gk-GE; Fri, 18 Nov 2011 15:42:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRQaN-0005gO-Bo
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:42:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321630933!2062232!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4499 invoked from network); 18 Nov 2011 15:42:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 15:42:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315195200"; d="scan'208";a="171157966"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 10:42:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 10:42:13 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAIFg5cv031993;	Fri, 18 Nov 2011 07:42:06 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: netdev@vger.kernel.org
Date: Fri, 18 Nov 2011 15:42:05 +0000
Message-ID: <1321630925-13652-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: stable@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen-netback: use correct index for invalidation
	in xen_netbk_tx_check_gop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jan Beulich <JBeulich@suse.com>

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: stable@vger.kernel.org
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 0cb594c..1ae270e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1021,7 +1021,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		pending_idx = *((u16 *)skb->data);
 		xen_netbk_idx_release(netbk, pending_idx);
 		for (j = start; j < i; j++) {
-			pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
+			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
 			xen_netbk_idx_release(netbk, pending_idx);
 		}
 
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:03:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:03:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQuH-0005zm-J1; Fri, 18 Nov 2011 16:03:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RRQuG-0005zD-8N
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:03:12 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1321632166!4108016!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22212 invoked from network); 18 Nov 2011 16:02:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 16:02:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIG2fU0024385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 16:02:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIG2eH5028181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 16:02:41 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIG2ZXR004515; Fri, 18 Nov 2011 10:02:35 -0600
Received: from [114.240.87.6] (/114.240.87.6)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 08:02:34 -0800
Message-ID: <4EC6818B.3010904@oracle.com>
Date: Sat, 19 Nov 2011 00:02:19 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EC3B62F.6080702@oracle.com>	<1321451304-13559-1-git-send-email-annie.li@oracle.com>	<4EC62E77.7090007@oracle.com>
	<1321613689.3664.305.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321613689.3664.305.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020203.4EC681A3.0105,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
 V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3127504165445532786=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

This is a multi-part message in MIME format.
--------------050509030203060808050700
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 2011-11-18 18:54, Ian Campbell wrote:
> Thanks for splitting these up.
>
> On Fri, 2011-11-18 at 10:07 +0000, ANNIE LI wrote:
>   
>> [...]
>>     
>
>   
>> return value
>> +        * by bit operations.
>> +        */
>> +       int (*query_foreign_access)(grant_ref_t);
>> +};
>> +
>> +static struct gnttab_ops gnttab_v1_ops;
>>     
>
> You don't actually need this forward declaration since the struct
> definition and usage are ordered correctly.
>
>   
Yes, you are right, this line should be removed.
>> +static struct gnttab_ops gnttab_v1_ops = {
>> +       .map_frames                     = gnttab_map_frames_v1,
>> +       .unmap_frames                   = gnttab_unmap_frames_v1,
>> +       .update_entry                   = update_grant_entry_v1,
>>     
>
> Any reason this one is not gnttab_foo?
>   
Actually no, just keep the original name of this function. I'd like to 
change it, maybe gnttab_update_entry_v1 is better?

Thanks
Annie
> Ian.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   

--------------050509030203060808050700
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
On 2011-11-18 18:54, Ian Campbell wrote:
<blockquote cite="mid1321613689.3664.305.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap="">Thanks for splitting these up.

On Fri, 2011-11-18 at 10:07 +0000, ANNIE LI wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">[...]
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">return value
+        * by bit operations.
+        */
+       int (*query_foreign_access)(grant_ref_t);
+};
+
+static struct gnttab_ops gnttab_v1_ops;
    </pre>
  </blockquote>
  <pre wrap=""><!---->
You don't actually need this forward declaration since the struct
definition and usage are ordered correctly.

  </pre>
</blockquote>
Yes, you are right, this line should be removed.<br>
<blockquote cite="mid1321613689.3664.305.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">+static struct gnttab_ops gnttab_v1_ops = {
+       .map_frames                     = gnttab_map_frames_v1,
+       .unmap_frames                   = gnttab_unmap_frames_v1,
+       .update_entry                   = update_grant_entry_v1,
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Any reason this one is not gnttab_foo?
  </pre>
</blockquote>
Actually no, just keep the original name of this function. I'd like to
change it, maybe gnttab_update_entry_v1 is better?<br>
<br>
Thanks<br>
Annie<br>
<blockquote cite="mid1321613689.3664.305.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap="">
Ian.



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

--------------050509030203060808050700--


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

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

--===============3127504165445532786==--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:03:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:03:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRQuH-0005zm-J1; Fri, 18 Nov 2011 16:03:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RRQuG-0005zD-8N
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:03:12 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1321632166!4108016!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22212 invoked from network); 18 Nov 2011 16:02:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 16:02:48 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIG2fU0024385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 16:02:42 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIG2eH5028181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 16:02:41 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIG2ZXR004515; Fri, 18 Nov 2011 10:02:35 -0600
Received: from [114.240.87.6] (/114.240.87.6)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 08:02:34 -0800
Message-ID: <4EC6818B.3010904@oracle.com>
Date: Sat, 19 Nov 2011 00:02:19 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EC3B62F.6080702@oracle.com>	<1321451304-13559-1-git-send-email-annie.li@oracle.com>	<4EC62E77.7090007@oracle.com>
	<1321613689.3664.305.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321613689.3664.305.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020203.4EC681A3.0105,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
 V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3127504165445532786=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

This is a multi-part message in MIME format.
--------------050509030203060808050700
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



On 2011-11-18 18:54, Ian Campbell wrote:
> Thanks for splitting these up.
>
> On Fri, 2011-11-18 at 10:07 +0000, ANNIE LI wrote:
>   
>> [...]
>>     
>
>   
>> return value
>> +        * by bit operations.
>> +        */
>> +       int (*query_foreign_access)(grant_ref_t);
>> +};
>> +
>> +static struct gnttab_ops gnttab_v1_ops;
>>     
>
> You don't actually need this forward declaration since the struct
> definition and usage are ordered correctly.
>
>   
Yes, you are right, this line should be removed.
>> +static struct gnttab_ops gnttab_v1_ops = {
>> +       .map_frames                     = gnttab_map_frames_v1,
>> +       .unmap_frames                   = gnttab_unmap_frames_v1,
>> +       .update_entry                   = update_grant_entry_v1,
>>     
>
> Any reason this one is not gnttab_foo?
>   
Actually no, just keep the original name of this function. I'd like to 
change it, maybe gnttab_update_entry_v1 is better?

Thanks
Annie
> Ian.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   

--------------050509030203060808050700
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
On 2011-11-18 18:54, Ian Campbell wrote:
<blockquote cite="mid1321613689.3664.305.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap="">Thanks for splitting these up.

On Fri, 2011-11-18 at 10:07 +0000, ANNIE LI wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">[...]
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">return value
+        * by bit operations.
+        */
+       int (*query_foreign_access)(grant_ref_t);
+};
+
+static struct gnttab_ops gnttab_v1_ops;
    </pre>
  </blockquote>
  <pre wrap=""><!---->
You don't actually need this forward declaration since the struct
definition and usage are ordered correctly.

  </pre>
</blockquote>
Yes, you are right, this line should be removed.<br>
<blockquote cite="mid1321613689.3664.305.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">+static struct gnttab_ops gnttab_v1_ops = {
+       .map_frames                     = gnttab_map_frames_v1,
+       .unmap_frames                   = gnttab_unmap_frames_v1,
+       .update_entry                   = update_grant_entry_v1,
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Any reason this one is not gnttab_foo?
  </pre>
</blockquote>
Actually no, just keep the original name of this function. I'd like to
change it, maybe gnttab_update_entry_v1 is better?<br>
<br>
Thanks<br>
Annie<br>
<blockquote cite="mid1321613689.3664.305.camel@zakaz.uk.xensource.com"
 type="cite">
  <pre wrap="">
Ian.



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

--------------050509030203060808050700--


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

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

--===============3127504165445532786==--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:05:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16: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 <xen-devel-bounces@lists.xensource.com>)
	id 1RRQvw-0006AG-Pf; Fri, 18 Nov 2011 16:04:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRQvv-00069i-Qd
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:04:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321632271!2126645!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11225 invoked from network); 18 Nov 2011 16:04:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 16:04:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9014685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 16:04: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.137.0;
	Fri, 18 Nov 2011 16:04:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Fri, 18 Nov 2011 16:04:31 +0000
In-Reply-To: <4EC6818B.3010904@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<4EC62E77.7090007@oracle.com>
	<1321613689.3664.305.camel@zakaz.uk.xensource.com>
	<4EC6818B.3010904@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321632271.3664.367.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
 V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> > > +static struct gnttab_ops gnttab_v1_ops = {
> > > +       .map_frames                     = gnttab_map_frames_v1,
> > > +       .unmap_frames                   = gnttab_unmap_frames_v1,
> > > +       .update_entry                   = update_grant_entry_v1,
> > >     
> > 
> > Any reason this one is not gnttab_foo?
> >   
> Actually no, just keep the original name of this function. I'd like to
> change it, maybe gnttab_update_entry_v1 is better?

I think so. Similarly for the v2 variant.

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:05:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16: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 <xen-devel-bounces@lists.xensource.com>)
	id 1RRQvw-0006AG-Pf; Fri, 18 Nov 2011 16:04:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RRQvv-00069i-Qd
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:04:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321632271!2126645!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11225 invoked from network); 18 Nov 2011 16:04:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 16:04:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,533,1315180800"; 
   d="scan'208";a="9014685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 16:04: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.137.0;
	Fri, 18 Nov 2011 16:04:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: annie li <annie.li@oracle.com>
Date: Fri, 18 Nov 2011 16:04:31 +0000
In-Reply-To: <4EC6818B.3010904@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<4EC62E77.7090007@oracle.com>
	<1321613689.3664.305.camel@zakaz.uk.xensource.com>
	<4EC6818B.3010904@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321632271.3664.367.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
 V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> > > +static struct gnttab_ops gnttab_v1_ops = {
> > > +       .map_frames                     = gnttab_map_frames_v1,
> > > +       .unmap_frames                   = gnttab_unmap_frames_v1,
> > > +       .update_entry                   = update_grant_entry_v1,
> > >     
> > 
> > Any reason this one is not gnttab_foo?
> >   
> Actually no, just keep the original name of this function. I'd like to
> change it, maybe gnttab_update_entry_v1 is better?

I think so. Similarly for the v2 variant.

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:11:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:11:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRR2H-0006nH-8l; Fri, 18 Nov 2011 16:11:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RRR2F-0006n9-VB
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:11:28 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321632628!63765175!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20513 invoked from network); 18 Nov 2011 16:10:30 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 16:10:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIGB42K004029
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 16:11:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIGB3Xr003792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 16:11:03 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIGAuYG007265; Fri, 18 Nov 2011 10:10:56 -0600
Received: from [114.240.87.6] (/114.240.87.6)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 08:10:55 -0800
Message-ID: <4EC6837F.1050201@oracle.com>
Date: Sat, 19 Nov 2011 00:10:39 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EC3B62F.6080702@oracle.com>	
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>	
	<4EC62FE5.2080608@oracle.com>	
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>	
	<20111118135221.GC12433@phenom.dumpdata.com>
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321624845.3664.354.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4EC68399.0087,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-11-18 22:00, Ian Campbell wrote:
> On Fri, 2011-11-18 at 13:52 +0000, Konrad Rzeszutek Wilk wrote:
>   
>>>> +                       xen_raw_printk(str);
>>>> +                       panic(str);
>>>>         
>>> I expect you've just copied this style from elsewhere but I really
>>> dislike this duplication of prints. If panic is not useful here we
>>> really ought to address that at the root instead of going around
>>> patching things to print every panic message twice. I thought
>>> earlyprintk was supposed to solve this problem. Perhaps a generic
>>> early_panic_print could be added to the panic code?
>>>       
>> We are using this combo in swiotlb-xen and as well in the xen pci.
>> We could declere a 'xen_raw_panic' that would do the job?
>>
>> The problem is that panic() uses the "late" printk mechanism (so
>> it goes through the buffer that ends up not beign flushed) and the
>> panic never sees the light.
>>     
>
> So lets fix that instead of working around it...
>
>   
>>  The 'xen_raw_printk' is synchronous..
>>
>> But I wonder if the panic surfaces if 'earlyprintk=xen' is used?
>> At which point it might be that the those extra xen_raw_printk
>> become pointless?
>>     
>
> I think panic's do come out with earlyprintk (unless they are truly
> super early).
>   
So we have two candidates:
xen_raw_printk + panic
panic + earlyprintk=xen

If panic does work with earlyprintk, then the latter one is better. 
Otherwise, there will be duplicated string printed out with 
'earlyprintk=xen'.

Thanks
Annie
> Ian.
>
>
>
>   

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:11:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:11:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRR2H-0006nH-8l; Fri, 18 Nov 2011 16:11:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RRR2F-0006n9-VB
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:11:28 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321632628!63765175!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20513 invoked from network); 18 Nov 2011 16:10:30 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 16:10:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAIGB42K004029
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 16:11:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAIGB3Xr003792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 16:11:03 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAIGAuYG007265; Fri, 18 Nov 2011 10:10:56 -0600
Received: from [114.240.87.6] (/114.240.87.6)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 08:10:55 -0800
Message-ID: <4EC6837F.1050201@oracle.com>
Date: Sat, 19 Nov 2011 00:10:39 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EC3B62F.6080702@oracle.com>	
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>	
	<4EC62FE5.2080608@oracle.com>	
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>	
	<20111118135221.GC12433@phenom.dumpdata.com>
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321624845.3664.354.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4EC68399.0087,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-11-18 22:00, Ian Campbell wrote:
> On Fri, 2011-11-18 at 13:52 +0000, Konrad Rzeszutek Wilk wrote:
>   
>>>> +                       xen_raw_printk(str);
>>>> +                       panic(str);
>>>>         
>>> I expect you've just copied this style from elsewhere but I really
>>> dislike this duplication of prints. If panic is not useful here we
>>> really ought to address that at the root instead of going around
>>> patching things to print every panic message twice. I thought
>>> earlyprintk was supposed to solve this problem. Perhaps a generic
>>> early_panic_print could be added to the panic code?
>>>       
>> We are using this combo in swiotlb-xen and as well in the xen pci.
>> We could declere a 'xen_raw_panic' that would do the job?
>>
>> The problem is that panic() uses the "late" printk mechanism (so
>> it goes through the buffer that ends up not beign flushed) and the
>> panic never sees the light.
>>     
>
> So lets fix that instead of working around it...
>
>   
>>  The 'xen_raw_printk' is synchronous..
>>
>> But I wonder if the panic surfaces if 'earlyprintk=xen' is used?
>> At which point it might be that the those extra xen_raw_printk
>> become pointless?
>>     
>
> I think panic's do come out with earlyprintk (unless they are truly
> super early).
>   
So we have two candidates:
xen_raw_printk + panic
panic + earlyprintk=xen

If panic does work with earlyprintk, then the latter one is better. 
Otherwise, there will be duplicated string printed out with 
'earlyprintk=xen'.

Thanks
Annie
> Ian.
>
>
>
>   

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:24:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:24:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRREc-0007Gm-NH; Fri, 18 Nov 2011 16:24:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RRREa-0007Gh-Lw
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:24:12 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1321633428!2130265!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3529 invoked from network); 18 Nov 2011 16:23:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-174.messagelabs.com with SMTP;
	18 Nov 2011 16:23:48 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pAIGNkgd010678
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 11:23:46 -0500
Received: from [10.36.6.52] (vpn1-6-52.ams2.redhat.com [10.36.6.52])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pAIGNi92004281; Fri, 18 Nov 2011 11:23:45 -0500
Message-ID: <4EC686E2.8020209@redhat.com>
Date: Fri, 18 Nov 2011 17:25:06 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14
	Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
In-Reply-To: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On 11/18/11 14:15, Jan Beulich wrote:

> --- a/drivers/xen/netback/netback.c
> +++ b/drivers/xen/netback/netback.c
> @@ -1155,7 +1155,7 @@ static int netbk_tx_check_mop(struct sk_
>   		pending_idx = *((u16 *)skb->data);
>   		netif_idx_release(pending_idx);
>   		for (j = start; j<  i; j++) {
> -			pending_idx = (unsigned long)shinfo->frags[i].page;
> +			pending_idx = (unsigned long)shinfo->frags[j].page;
>   			netif_idx_release(pending_idx);
>   		}

Please excuse the uneducated question: what could be the consequences of using the wrong index here? I notice that with the fix, frags[i].page is never touched, while without the fix, it is the only one that's released.

I'm asking because we have an elusive bug: netloop sometimes crashes in skb_remove_foreign_references(). As of 1125:985b8f62df25, the crash happens on line 118:

   116                  vaddr = kmap_skb_frag(&skb_shinfo(skb)->frags[i]);
   117                  off = skb_shinfo(skb)->frags[i].page_offset;
   118                  memcpy(page_address(page) + off,
   119                         vaddr + off,
   120                         skb_shinfo(skb)->frags[i].size);

because the PTE for the vaddr returned by kmap_skb_frag() for the first frag is 0.

It appears somehow related to NFS and closing/reopening TCP connections for NFS.

Thanks!
Laszlo

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:24:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:24:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRREc-0007Gm-NH; Fri, 18 Nov 2011 16:24:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RRREa-0007Gh-Lw
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:24:12 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1321633428!2130265!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3529 invoked from network); 18 Nov 2011 16:23:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-174.messagelabs.com with SMTP;
	18 Nov 2011 16:23:48 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pAIGNkgd010678
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 11:23:46 -0500
Received: from [10.36.6.52] (vpn1-6-52.ams2.redhat.com [10.36.6.52])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pAIGNi92004281; Fri, 18 Nov 2011 11:23:45 -0500
Message-ID: <4EC686E2.8020209@redhat.com>
Date: Fri, 18 Nov 2011 17:25:06 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14
	Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
In-Reply-To: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On 11/18/11 14:15, Jan Beulich wrote:

> --- a/drivers/xen/netback/netback.c
> +++ b/drivers/xen/netback/netback.c
> @@ -1155,7 +1155,7 @@ static int netbk_tx_check_mop(struct sk_
>   		pending_idx = *((u16 *)skb->data);
>   		netif_idx_release(pending_idx);
>   		for (j = start; j<  i; j++) {
> -			pending_idx = (unsigned long)shinfo->frags[i].page;
> +			pending_idx = (unsigned long)shinfo->frags[j].page;
>   			netif_idx_release(pending_idx);
>   		}

Please excuse the uneducated question: what could be the consequences of using the wrong index here? I notice that with the fix, frags[i].page is never touched, while without the fix, it is the only one that's released.

I'm asking because we have an elusive bug: netloop sometimes crashes in skb_remove_foreign_references(). As of 1125:985b8f62df25, the crash happens on line 118:

   116                  vaddr = kmap_skb_frag(&skb_shinfo(skb)->frags[i]);
   117                  off = skb_shinfo(skb)->frags[i].page_offset;
   118                  memcpy(page_address(page) + off,
   119                         vaddr + off,
   120                         skb_shinfo(skb)->frags[i].size);

because the PTE for the vaddr returned by kmap_skb_frag() for the first frag is 0.

It appears somehow related to NFS and closing/reopening TCP connections for NFS.

Thanks!
Laszlo

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:43:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:43:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRRXI-0007ZM-TA; Fri, 18 Nov 2011 16:43:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hedayati.mo@gmail.com>) id 1RRRXH-0007ZF-Hr
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:43:31 +0000
X-Env-Sender: hedayati.mo@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321634587!3702398!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4248 invoked from network); 18 Nov 2011 16:43:07 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 16:43:07 -0000
Received: by wwp14 with SMTP id 14so4580921wwp.24
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 08:43:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=pqSPeDr8C32fBvaOB3w34PoGbqOih6WP8LVhsVXyeV0=;
	b=DmzVfzs96wXlDOhIDfXk4mAkD86cU9nCViWBOl7bKLLwPeFEhM1vJpTrLJNG51tdnu
	K7Om7xFV/FoSYf5buBq4ZFZoDWDgx6foJNZlPA+TXeaHWMzgrqvI6Wpj97HOEzj3UpPb
	dxmohf1A9kxBhO7B5o1bREior0TbXHi0m2bTI=
Received: by 10.180.85.161 with SMTP id i1mr4105513wiz.17.1321634587122; Fri,
	18 Nov 2011 08:43:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.26.67 with HTTP; Fri, 18 Nov 2011 08:42:27 -0800 (PST)
From: Mohammad Hedayati <hedayati.mo@gmail.com>
Date: Fri, 18 Nov 2011 20:12:27 +0330
Message-ID: <CABA5EEtTH6pU1zzR=0UgPDCNrSEju1P2JWsyBjjNLSbcgh4q5g@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Event Channel & Grant Table Usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Can anyone tell me about the usage of event channel and page grant
mechanisms in Xen? I mean any usage other than split drivers.
Or, I can rephrase it this way, apart from virtual devices, where
would we use Xen's Inter-VM communication?
Thanks,
Mohammad

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:43:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:43:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRRXI-0007ZM-TA; Fri, 18 Nov 2011 16:43:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hedayati.mo@gmail.com>) id 1RRRXH-0007ZF-Hr
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:43:31 +0000
X-Env-Sender: hedayati.mo@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321634587!3702398!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4248 invoked from network); 18 Nov 2011 16:43:07 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 16:43:07 -0000
Received: by wwp14 with SMTP id 14so4580921wwp.24
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 08:43:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=pqSPeDr8C32fBvaOB3w34PoGbqOih6WP8LVhsVXyeV0=;
	b=DmzVfzs96wXlDOhIDfXk4mAkD86cU9nCViWBOl7bKLLwPeFEhM1vJpTrLJNG51tdnu
	K7Om7xFV/FoSYf5buBq4ZFZoDWDgx6foJNZlPA+TXeaHWMzgrqvI6Wpj97HOEzj3UpPb
	dxmohf1A9kxBhO7B5o1bREior0TbXHi0m2bTI=
Received: by 10.180.85.161 with SMTP id i1mr4105513wiz.17.1321634587122; Fri,
	18 Nov 2011 08:43:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.26.67 with HTTP; Fri, 18 Nov 2011 08:42:27 -0800 (PST)
From: Mohammad Hedayati <hedayati.mo@gmail.com>
Date: Fri, 18 Nov 2011 20:12:27 +0330
Message-ID: <CABA5EEtTH6pU1zzR=0UgPDCNrSEju1P2JWsyBjjNLSbcgh4q5g@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Event Channel & Grant Table Usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Can anyone tell me about the usage of event channel and page grant
mechanisms in Xen? I mean any usage other than split drivers.
Or, I can rephrase it this way, apart from virtual devices, where
would we use Xen's Inter-VM communication?
Thanks,
Mohammad

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:46:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:46:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRRaB-0007fk-IP; Fri, 18 Nov 2011 16:46:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RRRaA-0007fa-Bs
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:46:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321634765!4777301!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6832 invoked from network); 18 Nov 2011 16:46:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 16:46:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 18 Nov 2011 16:46:06 +0000
Message-Id: <4EC699DF0200007800061E60@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 18 Nov 2011 16:46:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
	<4EC686E2.8020209@redhat.com>
In-Reply-To: <4EC686E2.8020209@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 18.11.11 at 17:25, Laszlo Ersek <lersek@redhat.com> wrote:
> On 11/18/11 14:15, Jan Beulich wrote:
> 
>> --- a/drivers/xen/netback/netback.c
>> +++ b/drivers/xen/netback/netback.c
>> @@ -1155,7 +1155,7 @@ static int netbk_tx_check_mop(struct sk_
>>   		pending_idx = *((u16 *)skb->data);
>>   		netif_idx_release(pending_idx);
>>   		for (j = start; j<  i; j++) {
>> -			pending_idx = (unsigned long)shinfo->frags[i].page;
>> +			pending_idx = (unsigned long)shinfo->frags[j].page;
>>   			netif_idx_release(pending_idx);
>>   		}
> 
> Please excuse the uneducated question: what could be the consequences of 
> using the wrong index here? I notice that with the fix, frags[i].page is 
> never touched, while without the fix, it is the only one that's released.

The index correlating to i gets released right before the loop. The
consequences of using the wrong index in the loop are - afaict -
that guests may cause netback (and perhaps Dom0 as a whole) to
run out of certain resources (grant table entries come to mind).

> I'm asking because we have an elusive bug: netloop sometimes crashes in 
> skb_remove_foreign_references(). As of 1125:985b8f62df25, the crash happens 
> on line 118:
> 
>    116                  vaddr = kmap_skb_frag(&skb_shinfo(skb)->frags[i]);
>    117                  off = skb_shinfo(skb)->frags[i].page_offset;
>    118                  memcpy(page_address(page) + off,
>    119                         vaddr + off,
>    120                         skb_shinfo(skb)->frags[i].size);
> 
> because the PTE for the vaddr returned by kmap_skb_frag() for the first frag 
> is 0.
> 
> It appears somehow related to NFS and closing/reopening TCP connections for 
> NFS.

Sorry, I don't see any connection to the above, but then again I didn't
find the bug above due to actual misbehavior, but just due to having
worked on that code while moving our patch set forward to 3.2-rc.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:46:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:46:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRRaB-0007fk-IP; Fri, 18 Nov 2011 16:46:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RRRaA-0007fa-Bs
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:46:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321634765!4777301!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6832 invoked from network); 18 Nov 2011 16:46:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 16:46:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 18 Nov 2011 16:46:06 +0000
Message-Id: <4EC699DF0200007800061E60@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 18 Nov 2011 16:46:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <4EC6686B0200007800061D60@nat28.tlf.novell.com>
	<4EC686E2.8020209@redhat.com>
In-Reply-To: <4EC686E2.8020209@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] linux-2.6.18/netback: use correct index for
 invalidation in netbk_tx_check_mop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 18.11.11 at 17:25, Laszlo Ersek <lersek@redhat.com> wrote:
> On 11/18/11 14:15, Jan Beulich wrote:
> 
>> --- a/drivers/xen/netback/netback.c
>> +++ b/drivers/xen/netback/netback.c
>> @@ -1155,7 +1155,7 @@ static int netbk_tx_check_mop(struct sk_
>>   		pending_idx = *((u16 *)skb->data);
>>   		netif_idx_release(pending_idx);
>>   		for (j = start; j<  i; j++) {
>> -			pending_idx = (unsigned long)shinfo->frags[i].page;
>> +			pending_idx = (unsigned long)shinfo->frags[j].page;
>>   			netif_idx_release(pending_idx);
>>   		}
> 
> Please excuse the uneducated question: what could be the consequences of 
> using the wrong index here? I notice that with the fix, frags[i].page is 
> never touched, while without the fix, it is the only one that's released.

The index correlating to i gets released right before the loop. The
consequences of using the wrong index in the loop are - afaict -
that guests may cause netback (and perhaps Dom0 as a whole) to
run out of certain resources (grant table entries come to mind).

> I'm asking because we have an elusive bug: netloop sometimes crashes in 
> skb_remove_foreign_references(). As of 1125:985b8f62df25, the crash happens 
> on line 118:
> 
>    116                  vaddr = kmap_skb_frag(&skb_shinfo(skb)->frags[i]);
>    117                  off = skb_shinfo(skb)->frags[i].page_offset;
>    118                  memcpy(page_address(page) + off,
>    119                         vaddr + off,
>    120                         skb_shinfo(skb)->frags[i].size);
> 
> because the PTE for the vaddr returned by kmap_skb_frag() for the first frag 
> is 0.
> 
> It appears somehow related to NFS and closing/reopening TCP connections for 
> NFS.

Sorry, I don't see any connection to the above, but then again I didn't
find the bug above due to actual misbehavior, but just due to having
worked on that code while moving our patch set forward to 3.2-rc.

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:48:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRRcB-0007n3-CV; Fri, 18 Nov 2011 16:48:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RRRcA-0007md-Ff
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:48:34 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-13.tower-216.messagelabs.com!1321634890!4113325!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28542 invoked from network); 18 Nov 2011 16:48:10 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 16:48:10 -0000
Received: by wwp14 with SMTP id 14so4587847wwp.24
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 08:48:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=9M1jMkm0gvhKWG7WHNxw8SgCDYNFQfNhOhSNthWaQ4o=;
	b=UsBWDKJal9Tyn7DEO/y+9MWQjMN6QGJaTmzaXQILZlpWWyQJHM+59N5TvH8LDob2tO
	oWnmBUjvuCbSucH//mt5OrT8hCTURbdr5J5xsd1P3Jkh3qisHYn82+kUEMqKMZkBrCmG
	fLY7iOW1lzBf3PcEWwMVi34YbG8JuG5G44270=
Received: by 10.216.72.145 with SMTP id t17mr499076wed.88.1321634890062; Fri,
	18 Nov 2011 08:48:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.217.2.202 with HTTP; Fri, 18 Nov 2011 08:47:54 -0800 (PST)
X-Originating-IP: [91.122.177.171]
In-Reply-To: <CABA5EEtTH6pU1zzR=0UgPDCNrSEju1P2JWsyBjjNLSbcgh4q5g@mail.gmail.com>
References: <CABA5EEtTH6pU1zzR=0UgPDCNrSEju1P2JWsyBjjNLSbcgh4q5g@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 18 Nov 2011 20:47:54 +0400
X-Google-Sender-Auth: BXzI9jE280-DbrLF8S6nCnMJ0Ck
Message-ID: <CACaajQv+zCLE=ZGJcQ9OujfQ4khx+UgembidUb90bWeHOTmB8g@mail.gmail.com>
To: Mohammad Hedayati <hedayati.mo@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Event Channel & Grant Table Usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6165866948450677105=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6165866948450677105==
Content-Type: multipart/alternative; boundary=00504502c6fa251c3904b2051ab4

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

2011/11/18 Mohammad Hedayati <hedayati.mo@gmail.com>

> Can anyone tell me about the usage of event channel and page grant
> mechanisms in Xen? I mean any usage other than split drivers.
> Or, I can rephrase it this way, apart from virtual devices, where
> would we use Xen's Inter-VM communication?
> Thanks,
> Mohammad
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


See libxenvchan messages in the list and xen source code.

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

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

<br><br><div class=3D"gmail_quote">2011/11/18 Mohammad Hedayati <span dir=
=3D"ltr">&lt;<a href=3D"mailto:hedayati.mo@gmail.com">hedayati.mo@gmail.com=
</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">

Can anyone tell me about the usage of event channel and page grant<br>
mechanisms in Xen? I mean any usage other than split drivers.<br>
Or, I can rephrase it this way, apart from virtual devices, where<br>
would we use Xen&#39;s Inter-VM communication?<br>
Thanks,<br>
Mohammad<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br><br><div>See libxenvchan messages in the list and xe=
n source code.<br clear=3D"all"><div><br></div>-- <br><span style=3D"border=
-collapse:collapse;color:rgb(136, 136, 136);font-family:arial, sans-serif;f=
ont-size:13px"><div>

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

</div></span><br>
</div>

--00504502c6fa251c3904b2051ab4--


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

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

--===============6165866948450677105==--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:48:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRRcB-0007n3-CV; Fri, 18 Nov 2011 16:48:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RRRcA-0007md-Ff
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:48:34 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-13.tower-216.messagelabs.com!1321634890!4113325!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28542 invoked from network); 18 Nov 2011 16:48:10 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 16:48:10 -0000
Received: by wwp14 with SMTP id 14so4587847wwp.24
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 08:48:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:in-reply-to:references:from
	:date:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=9M1jMkm0gvhKWG7WHNxw8SgCDYNFQfNhOhSNthWaQ4o=;
	b=UsBWDKJal9Tyn7DEO/y+9MWQjMN6QGJaTmzaXQILZlpWWyQJHM+59N5TvH8LDob2tO
	oWnmBUjvuCbSucH//mt5OrT8hCTURbdr5J5xsd1P3Jkh3qisHYn82+kUEMqKMZkBrCmG
	fLY7iOW1lzBf3PcEWwMVi34YbG8JuG5G44270=
Received: by 10.216.72.145 with SMTP id t17mr499076wed.88.1321634890062; Fri,
	18 Nov 2011 08:48:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.217.2.202 with HTTP; Fri, 18 Nov 2011 08:47:54 -0800 (PST)
X-Originating-IP: [91.122.177.171]
In-Reply-To: <CABA5EEtTH6pU1zzR=0UgPDCNrSEju1P2JWsyBjjNLSbcgh4q5g@mail.gmail.com>
References: <CABA5EEtTH6pU1zzR=0UgPDCNrSEju1P2JWsyBjjNLSbcgh4q5g@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 18 Nov 2011 20:47:54 +0400
X-Google-Sender-Auth: BXzI9jE280-DbrLF8S6nCnMJ0Ck
Message-ID: <CACaajQv+zCLE=ZGJcQ9OujfQ4khx+UgembidUb90bWeHOTmB8g@mail.gmail.com>
To: Mohammad Hedayati <hedayati.mo@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Event Channel & Grant Table Usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6165866948450677105=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6165866948450677105==
Content-Type: multipart/alternative; boundary=00504502c6fa251c3904b2051ab4

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

2011/11/18 Mohammad Hedayati <hedayati.mo@gmail.com>

> Can anyone tell me about the usage of event channel and page grant
> mechanisms in Xen? I mean any usage other than split drivers.
> Or, I can rephrase it this way, apart from virtual devices, where
> would we use Xen's Inter-VM communication?
> Thanks,
> Mohammad
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


See libxenvchan messages in the list and xen source code.

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

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

<br><br><div class=3D"gmail_quote">2011/11/18 Mohammad Hedayati <span dir=
=3D"ltr">&lt;<a href=3D"mailto:hedayati.mo@gmail.com">hedayati.mo@gmail.com=
</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">

Can anyone tell me about the usage of event channel and page grant<br>
mechanisms in Xen? I mean any usage other than split drivers.<br>
Or, I can rephrase it this way, apart from virtual devices, where<br>
would we use Xen&#39;s Inter-VM communication?<br>
Thanks,<br>
Mohammad<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br><br><div>See libxenvchan messages in the list and xe=
n source code.<br clear=3D"all"><div><br></div>-- <br><span style=3D"border=
-collapse:collapse;color:rgb(136, 136, 136);font-family:arial, sans-serif;f=
ont-size:13px"><div>

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

</div></span><br>
</div>

--00504502c6fa251c3904b2051ab4--


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

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

--===============6165866948450677105==--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:49:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:49:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRRcQ-0007ov-WA; Fri, 18 Nov 2011 16:48:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RRRcP-0007oE-8l
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:48:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1321634905!3725307!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14313 invoked from network); 18 Nov 2011 16:48:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 16:48:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321634904; l=1440;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=BdTUQ/tJp0/HY8dq04Y5H5e22BE=;
	b=H6fOQPQu+RLc1rcDht1RelCz5wcYm833HM9zghjEk2Lu38mktRPgVq3tFZjhMd0wOqK
	qFqKL/bnCg7FtD0JjH7beUe5iwqsScZ+19DgnunauPrC9gLAvFRxD//lhTX+PxDWWsArq
	Eqgz6g3xFYq0mfTsqEf7Pl0TqKafo3Etx9U=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjoQERIuXQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-109-239.pools.arcor-ip.net [88.65.109.239])
	by smtp.strato.de (cohen mo32) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V04d2anAIEvv5P ;
	Fri, 18 Nov 2011 17:48:15 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 38E3E18637; Fri, 18 Nov 2011 17:48:05 +0100 (CET)
Date: Fri, 18 Nov 2011 17:48:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20111118164805.GA14345@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Add .get_settings function, return fake data so that ethtool can get
enough information. For some application like VCS, this is useful,
otherwise some of application logic will get panic.
The reported data refers to VMWare vmxnet.

Signed-off-by: Xin Wei Hu <xwhu@suse.com>
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 drivers/net/xen-netfront.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

Index: linux-3.2-rc2/drivers/net/xen-netfront.c
===================================================================
--- linux-3.2-rc2.orig/drivers/net/xen-netfront.c
+++ linux-3.2-rc2/drivers/net/xen-netfront.c
@@ -1727,6 +1727,17 @@ static void netback_changed(struct xenbu
 	}
 }
 
+static int xennet_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
+{
+	ecmd->supported = SUPPORTED_1000baseT_Full | SUPPORTED_TP;
+	ecmd->advertising = ADVERTISED_TP;
+	ecmd->port = PORT_TP;
+	ecmd->transceiver = XCVR_INTERNAL;
+	ecmd->speed = SPEED_1000;
+	ecmd->duplex = DUPLEX_FULL;
+	return 0;
+}
+
 static const struct xennet_stat {
 	char name[ETH_GSTRING_LEN];
 	u16 offset;
@@ -1774,6 +1785,7 @@ static const struct ethtool_ops xennet_e
 {
 	.get_link = ethtool_op_get_link,
 
+	.get_settings = xennet_get_settings,
 	.get_sset_count = xennet_get_sset_count,
 	.get_ethtool_stats = xennet_get_ethtool_stats,
 	.get_strings = xennet_get_strings,

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 16:49:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 16:49:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRRcQ-0007ov-WA; Fri, 18 Nov 2011 16:48:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RRRcP-0007oE-8l
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 16:48:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1321634905!3725307!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14313 invoked from network); 18 Nov 2011 16:48:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 16:48:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321634904; l=1440;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=BdTUQ/tJp0/HY8dq04Y5H5e22BE=;
	b=H6fOQPQu+RLc1rcDht1RelCz5wcYm833HM9zghjEk2Lu38mktRPgVq3tFZjhMd0wOqK
	qFqKL/bnCg7FtD0JjH7beUe5iwqsScZ+19DgnunauPrC9gLAvFRxD//lhTX+PxDWWsArq
	Eqgz6g3xFYq0mfTsqEf7Pl0TqKafo3Etx9U=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjoQERIuXQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-109-239.pools.arcor-ip.net [88.65.109.239])
	by smtp.strato.de (cohen mo32) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V04d2anAIEvv5P ;
	Fri, 18 Nov 2011 17:48:15 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 38E3E18637; Fri, 18 Nov 2011 17:48:05 +0100 (CET)
Date: Fri, 18 Nov 2011 17:48:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20111118164805.GA14345@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Add .get_settings function, return fake data so that ethtool can get
enough information. For some application like VCS, this is useful,
otherwise some of application logic will get panic.
The reported data refers to VMWare vmxnet.

Signed-off-by: Xin Wei Hu <xwhu@suse.com>
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 drivers/net/xen-netfront.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

Index: linux-3.2-rc2/drivers/net/xen-netfront.c
===================================================================
--- linux-3.2-rc2.orig/drivers/net/xen-netfront.c
+++ linux-3.2-rc2/drivers/net/xen-netfront.c
@@ -1727,6 +1727,17 @@ static void netback_changed(struct xenbu
 	}
 }
 
+static int xennet_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
+{
+	ecmd->supported = SUPPORTED_1000baseT_Full | SUPPORTED_TP;
+	ecmd->advertising = ADVERTISED_TP;
+	ecmd->port = PORT_TP;
+	ecmd->transceiver = XCVR_INTERNAL;
+	ecmd->speed = SPEED_1000;
+	ecmd->duplex = DUPLEX_FULL;
+	return 0;
+}
+
 static const struct xennet_stat {
 	char name[ETH_GSTRING_LEN];
 	u16 offset;
@@ -1774,6 +1785,7 @@ static const struct ethtool_ops xennet_e
 {
 	.get_link = ethtool_op_get_link,
 
+	.get_settings = xennet_get_settings,
 	.get_sset_count = xennet_get_sset_count,
 	.get_ethtool_stats = xennet_get_ethtool_stats,
 	.get_strings = xennet_get_strings,

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 17:31:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 17:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRSHQ-0000Bp-97; Fri, 18 Nov 2011 17:31:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hedayati.mo@gmail.com>) id 1RRSHO-0000Bk-QY
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 17:31:11 +0000
X-Env-Sender: hedayati.mo@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321637446!2134127!1
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12743 invoked from network); 18 Nov 2011 17:30:46 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 17:30:46 -0000
Received: by eyb6 with SMTP id 6so5978597eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 09:30:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:cc
	:content-type; bh=xJKW0B7IL/erCRqB6vOQf0VK9X2jGyBVq7KdONwZiOY=;
	b=VoqiGXWlPemo9DsAnHv7zLjLZOg+4jeXGkL6BzyW3FQ+PI+HRshAj9SuolQKkJUz1k
	h6H+6dYI50Y2inKlzm1qqU46dAQeNXDcXYlJbKNn/OTZ6K3j3c/OEIYTk966+DaJIdRb
	UrO/mV4b5dLxb0RSUifyJup9uxKxEN4BXyVdA=
Received: by 10.180.14.129 with SMTP id p1mr4299992wic.8.1321637445150; Fri,
	18 Nov 2011 09:30:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.26.67 with HTTP; Fri, 18 Nov 2011 09:30:04 -0800 (PST)
In-Reply-To: <CACaajQv+zCLE=ZGJcQ9OujfQ4khx+UgembidUb90bWeHOTmB8g@mail.gmail.com>
References: <CABA5EEtTH6pU1zzR=0UgPDCNrSEju1P2JWsyBjjNLSbcgh4q5g@mail.gmail.com>
	<CACaajQv+zCLE=ZGJcQ9OujfQ4khx+UgembidUb90bWeHOTmB8g@mail.gmail.com>
From: Mohammad Hedayati <hedayati.mo@gmail.com>
Date: Fri, 18 Nov 2011 21:00:04 +0330
Message-ID: <CABA5EEt0oiRtCyH5e3MAPe03m64HHY3QO=dDM4wACGWofrJABw@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Event Channel & Grant Table Usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 8:17 PM, Vasiliy Tolstov <v.tolstov@selfip.ru> wrote:
>
>
> 2011/11/18 Mohammad Hedayati <hedayati.mo@gmail.com>
>>
>> Can anyone tell me about the usage of event channel and page grant
>> mechanisms in Xen? I mean any usage other than split drivers.
>> Or, I can rephrase it this way, apart from virtual devices, where
>> would we use Xen's Inter-VM communication?
>> Thanks,
>> Mohammad
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
> See libxenvchan messages in the list and xen source code.
>
> --
> Vasiliy Tolstov,
> Clodo.ru
> e-mail: v.tolstov@selfip.ru
> jabber: vase@selfip.ru
>

Thank for reply Vasiliy,
I'm not looking for a way to use Xen's IVMC mechanism, I'm looking for
applications which use it (i.e. its applications). So far I only know
about virtual devices and an MPI implementation which bypasses network
using event channel and grant table mechanisms.
-
Mohammad

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 17:31:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 17:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRSHQ-0000Bp-97; Fri, 18 Nov 2011 17:31:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hedayati.mo@gmail.com>) id 1RRSHO-0000Bk-QY
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 17:31:11 +0000
X-Env-Sender: hedayati.mo@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321637446!2134127!1
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12743 invoked from network); 18 Nov 2011 17:30:46 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 17:30:46 -0000
Received: by eyb6 with SMTP id 6so5978597eyb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 09:30:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:cc
	:content-type; bh=xJKW0B7IL/erCRqB6vOQf0VK9X2jGyBVq7KdONwZiOY=;
	b=VoqiGXWlPemo9DsAnHv7zLjLZOg+4jeXGkL6BzyW3FQ+PI+HRshAj9SuolQKkJUz1k
	h6H+6dYI50Y2inKlzm1qqU46dAQeNXDcXYlJbKNn/OTZ6K3j3c/OEIYTk966+DaJIdRb
	UrO/mV4b5dLxb0RSUifyJup9uxKxEN4BXyVdA=
Received: by 10.180.14.129 with SMTP id p1mr4299992wic.8.1321637445150; Fri,
	18 Nov 2011 09:30:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.26.67 with HTTP; Fri, 18 Nov 2011 09:30:04 -0800 (PST)
In-Reply-To: <CACaajQv+zCLE=ZGJcQ9OujfQ4khx+UgembidUb90bWeHOTmB8g@mail.gmail.com>
References: <CABA5EEtTH6pU1zzR=0UgPDCNrSEju1P2JWsyBjjNLSbcgh4q5g@mail.gmail.com>
	<CACaajQv+zCLE=ZGJcQ9OujfQ4khx+UgembidUb90bWeHOTmB8g@mail.gmail.com>
From: Mohammad Hedayati <hedayati.mo@gmail.com>
Date: Fri, 18 Nov 2011 21:00:04 +0330
Message-ID: <CABA5EEt0oiRtCyH5e3MAPe03m64HHY3QO=dDM4wACGWofrJABw@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Event Channel & Grant Table Usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 8:17 PM, Vasiliy Tolstov <v.tolstov@selfip.ru> wrote:
>
>
> 2011/11/18 Mohammad Hedayati <hedayati.mo@gmail.com>
>>
>> Can anyone tell me about the usage of event channel and page grant
>> mechanisms in Xen? I mean any usage other than split drivers.
>> Or, I can rephrase it this way, apart from virtual devices, where
>> would we use Xen's Inter-VM communication?
>> Thanks,
>> Mohammad
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
> See libxenvchan messages in the list and xen source code.
>
> --
> Vasiliy Tolstov,
> Clodo.ru
> e-mail: v.tolstov@selfip.ru
> jabber: vase@selfip.ru
>

Thank for reply Vasiliy,
I'm not looking for a way to use Xen's IVMC mechanism, I'm looking for
applications which use it (i.e. its applications). So far I only know
about virtual devices and an MPI implementation which bypasses network
using event channel and grant table mechanisms.
-
Mohammad

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 17:47:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 17:47:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRSWo-0000SE-Rr; Fri, 18 Nov 2011 17:47:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bhutchings@solarflare.com>) id 1RRSWm-0000S9-QJ
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 17:47:05 +0000
X-Env-Sender: bhutchings@solarflare.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321638399!2135413!1
X-Originating-IP: [216.237.3.220]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14629 invoked from network); 18 Nov 2011 17:46:40 -0000
Received: from exchange.solarflare.com (HELO exchange.solarflare.com)
	(216.237.3.220) by server-7.tower-174.messagelabs.com with SMTP;
	18 Nov 2011 17:46:40 -0000
Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by
	exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 18 Nov 2011 09:46:37 -0800
Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com
	(10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1;
	Fri, 18 Nov 2011 09:46:37 -0800
From: Ben Hutchings <bhutchings@solarflare.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111118164805.GA14345@aepfle.de>
References: <20111118164805.GA14345@aepfle.de>
Organization: Solarflare Communications
Date: Fri, 18 Nov 2011 17:46:34 +0000
Message-ID: <1321638394.2883.32.camel@bwh-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) 
X-Originating-IP: [10.17.20.137]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18526.005
X-TM-AS-Result: No--8.494300-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-OriginalArrivalTime: 18 Nov 2011 17:46:37.0771 (UTC)
	FILETIME=[057361B0:01CCA61A]
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> Add .get_settings function, return fake data so that ethtool can get
> enough information. For some application like VCS, this is useful,
> otherwise some of application logic will get panic.
> The reported data refers to VMWare vmxnet.
> 
> Signed-off-by: Xin Wei Hu <xwhu@suse.com>
> Signed-off-by: Chunyan Liu <cyliu@suse.com>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

NAK, we should not just make things up.

Ben.

> ---
>  drivers/net/xen-netfront.c |   12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> Index: linux-3.2-rc2/drivers/net/xen-netfront.c
> ===================================================================
> --- linux-3.2-rc2.orig/drivers/net/xen-netfront.c
> +++ linux-3.2-rc2/drivers/net/xen-netfront.c
> @@ -1727,6 +1727,17 @@ static void netback_changed(struct xenbu
>  	}
>  }
>  
> +static int xennet_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
> +{
> +	ecmd->supported = SUPPORTED_1000baseT_Full | SUPPORTED_TP;
> +	ecmd->advertising = ADVERTISED_TP;
> +	ecmd->port = PORT_TP;
> +	ecmd->transceiver = XCVR_INTERNAL;
> +	ecmd->speed = SPEED_1000;
> +	ecmd->duplex = DUPLEX_FULL;
> +	return 0;
> +}
> +
>  static const struct xennet_stat {
>  	char name[ETH_GSTRING_LEN];
>  	u16 offset;
> @@ -1774,6 +1785,7 @@ static const struct ethtool_ops xennet_e
>  {
>  	.get_link = ethtool_op_get_link,
>  
> +	.get_settings = xennet_get_settings,
>  	.get_sset_count = xennet_get_sset_count,
>  	.get_ethtool_stats = xennet_get_ethtool_stats,
>  	.get_strings = xennet_get_strings,
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 17:47:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 17:47:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRSWo-0000SE-Rr; Fri, 18 Nov 2011 17:47:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bhutchings@solarflare.com>) id 1RRSWm-0000S9-QJ
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 17:47:05 +0000
X-Env-Sender: bhutchings@solarflare.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321638399!2135413!1
X-Originating-IP: [216.237.3.220]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14629 invoked from network); 18 Nov 2011 17:46:40 -0000
Received: from exchange.solarflare.com (HELO exchange.solarflare.com)
	(216.237.3.220) by server-7.tower-174.messagelabs.com with SMTP;
	18 Nov 2011 17:46:40 -0000
Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by
	exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 18 Nov 2011 09:46:37 -0800
Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com
	(10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1;
	Fri, 18 Nov 2011 09:46:37 -0800
From: Ben Hutchings <bhutchings@solarflare.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111118164805.GA14345@aepfle.de>
References: <20111118164805.GA14345@aepfle.de>
Organization: Solarflare Communications
Date: Fri, 18 Nov 2011 17:46:34 +0000
Message-ID: <1321638394.2883.32.camel@bwh-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) 
X-Originating-IP: [10.17.20.137]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18526.005
X-TM-AS-Result: No--8.494300-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-OriginalArrivalTime: 18 Nov 2011 17:46:37.0771 (UTC)
	FILETIME=[057361B0:01CCA61A]
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> Add .get_settings function, return fake data so that ethtool can get
> enough information. For some application like VCS, this is useful,
> otherwise some of application logic will get panic.
> The reported data refers to VMWare vmxnet.
> 
> Signed-off-by: Xin Wei Hu <xwhu@suse.com>
> Signed-off-by: Chunyan Liu <cyliu@suse.com>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

NAK, we should not just make things up.

Ben.

> ---
>  drivers/net/xen-netfront.c |   12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> Index: linux-3.2-rc2/drivers/net/xen-netfront.c
> ===================================================================
> --- linux-3.2-rc2.orig/drivers/net/xen-netfront.c
> +++ linux-3.2-rc2/drivers/net/xen-netfront.c
> @@ -1727,6 +1727,17 @@ static void netback_changed(struct xenbu
>  	}
>  }
>  
> +static int xennet_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
> +{
> +	ecmd->supported = SUPPORTED_1000baseT_Full | SUPPORTED_TP;
> +	ecmd->advertising = ADVERTISED_TP;
> +	ecmd->port = PORT_TP;
> +	ecmd->transceiver = XCVR_INTERNAL;
> +	ecmd->speed = SPEED_1000;
> +	ecmd->duplex = DUPLEX_FULL;
> +	return 0;
> +}
> +
>  static const struct xennet_stat {
>  	char name[ETH_GSTRING_LEN];
>  	u16 offset;
> @@ -1774,6 +1785,7 @@ static const struct ethtool_ops xennet_e
>  {
>  	.get_link = ethtool_op_get_link,
>  
> +	.get_settings = xennet_get_settings,
>  	.get_sset_count = xennet_get_sset_count,
>  	.get_ethtool_stats = xennet_get_ethtool_stats,
>  	.get_strings = xennet_get_strings,
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:03:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRSln-0000fq-5u; Fri, 18 Nov 2011 18:02:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RRSll-0000fk-RP
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:02:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321639328!4701003!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7199 invoked from network); 18 Nov 2011 18:02:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 18:02:09 -0000
X-IronPort-AV: E=Sophos;i="4.69,534,1315195200"; d="scan'208";a="171179523"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:01:40 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 18 Nov 2011
	13:01:40 -0500
Message-ID: <4EC69D83.6010704@citrix.com>
Date: Fri, 18 Nov 2011 18:01:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EC273B40200007800061145@nat28.tlf.novell.com>
	<4EC53288.5010400@citrix.com>
	<4EC625F90200007800061BFE@nat28.tlf.novell.com>
In-Reply-To: <4EC625F90200007800061BFE@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: refine EOI-ing of migrating
 level interrupts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/11/11 08:31, Jan Beulich wrote:
> Now that this is in, could you try (again on the offending system)
> whether adding e.g. a WARN_ON(vector != desc->arch.old_vector)
> prior to the just added call to eoi_IO_APIC_irq() (but inside the
> surrounding if()) would ever trigger (obviously you'd want to make
> sure that the code path actually gets executed at all - perhaps
> counting and printing the count once in a while would be the easiest
> thing to do)?
>
> If it does, we obviously need to stay with passing in vector. If not,
> we'd need to do another round of code inspection to determine
> whether indeed there's no race when relying on just the stored
> data.
>
> Thanks, Jan

So long as you also check for arch.old_vector != IRQ_UNASSIGNED_VECTOR,
this appears to be fine.

I will sort out a patch to change this behavior

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


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:03:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRSln-0000fq-5u; Fri, 18 Nov 2011 18:02:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RRSll-0000fk-RP
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:02:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321639328!4701003!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7199 invoked from network); 18 Nov 2011 18:02:09 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 18:02:09 -0000
X-IronPort-AV: E=Sophos;i="4.69,534,1315195200"; d="scan'208";a="171179523"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:01:40 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 18 Nov 2011
	13:01:40 -0500
Message-ID: <4EC69D83.6010704@citrix.com>
Date: Fri, 18 Nov 2011 18:01:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4EC273B40200007800061145@nat28.tlf.novell.com>
	<4EC53288.5010400@citrix.com>
	<4EC625F90200007800061BFE@nat28.tlf.novell.com>
In-Reply-To: <4EC625F90200007800061BFE@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: refine EOI-ing of migrating
 level interrupts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/11/11 08:31, Jan Beulich wrote:
> Now that this is in, could you try (again on the offending system)
> whether adding e.g. a WARN_ON(vector != desc->arch.old_vector)
> prior to the just added call to eoi_IO_APIC_irq() (but inside the
> surrounding if()) would ever trigger (obviously you'd want to make
> sure that the code path actually gets executed at all - perhaps
> counting and printing the count once in a while would be the easiest
> thing to do)?
>
> If it does, we obviously need to stay with passing in vector. If not,
> we'd need to do another round of code inspection to determine
> whether indeed there's no race when relying on just the stored
> data.
>
> Thanks, Jan

So long as you also check for arch.old_vector != IRQ_UNASSIGNED_VECTOR,
this appears to be fine.

I will sort out a patch to change this behavior

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


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:05:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:05:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRSod-0000m9-Rb; Fri, 18 Nov 2011 18:05:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRSoc-0000lu-PZ
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:05:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1321639506!2137273!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26816 invoked from network); 18 Nov 2011 18:05:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 18:05:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,534,1315180800"; 
   d="scan'208";a="9016874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 18:05:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 18:05:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRSoD-0006si-J1;
	Fri, 18 Nov 2011 18:05:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRSoD-00051G-Av;
	Fri, 18 Nov 2011 18:05:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9856-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 18 Nov 2011 18:05:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9856: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  5a00ccfc6391
baseline version:
 xen                  e73ada19a69d

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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


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

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

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


Pushing revision :

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

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:05:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:05:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRSod-0000m9-Rb; Fri, 18 Nov 2011 18:05:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRSoc-0000lu-PZ
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:05:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1321639506!2137273!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26816 invoked from network); 18 Nov 2011 18:05:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 18:05:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,534,1315180800"; 
   d="scan'208";a="9016874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 18:05:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 18:05:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRSoD-0006si-J1;
	Fri, 18 Nov 2011 18:05:05 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRSoD-00051G-Av;
	Fri, 18 Nov 2011 18:05:05 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9856-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 18 Nov 2011 18:05:05 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9856: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  5a00ccfc6391
baseline version:
 xen                  e73ada19a69d

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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


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

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

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


Pushing revision :

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

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:06:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRSop-0000n1-8f; Fri, 18 Nov 2011 18:05:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RRSon-0000mW-UV
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:05:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321639516!4115369!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16044 invoked from network); 18 Nov 2011 18:05:17 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 18:05:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAII5CEG025804
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 18:05:13 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAII59fK010566
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 18:05:10 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAII51Fa022723; Fri, 18 Nov 2011 12:05:02 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 10:05:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AEA2481489; Fri, 18 Nov 2011 13:05:00 -0500 (EST)
Date: Fri, 18 Nov 2011 13:05:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: annie li <annie.li@oracle.com>
Message-ID: <20111118180500.GA19469@phenom.dumpdata.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
	<20111118135221.GC12433@phenom.dumpdata.com>
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>
	<4EC6837F.1050201@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EC6837F.1050201@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4EC69E59.011E,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
 implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> So we have two candidates:
> xen_raw_printk + panic
> panic + earlyprintk=xen
> 
> If panic does work with earlyprintk, then the latter one is better.
> Otherwise, there will be duplicated string printed out with
> 'earlyprintk=xen'.

The idea is just to have one function. Whichever prints the
string and panics the machine. If 'panic' does this properly
(and properly meaning it actually prints data when using
the earlyprintk=xen as well as console=hvc0) printout system
the we cuold just use 'panic' and not worry about it.


But if it does not, then we (and by we I mean you) should 
provide a variant of panic() that prints the data properly using the 
earlprintk mechanism. Preferrabily to make it generic.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:06:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:06:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRSop-0000n1-8f; Fri, 18 Nov 2011 18:05:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RRSon-0000mW-UV
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:05:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321639516!4115369!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16044 invoked from network); 18 Nov 2011 18:05:17 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 18:05:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAII5CEG025804
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 18 Nov 2011 18:05:13 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAII59fK010566
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 18:05:10 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAII51Fa022723; Fri, 18 Nov 2011 12:05:02 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 10:05:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AEA2481489; Fri, 18 Nov 2011 13:05:00 -0500 (EST)
Date: Fri, 18 Nov 2011 13:05:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: annie li <annie.li@oracle.com>
Message-ID: <20111118180500.GA19469@phenom.dumpdata.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
	<20111118135221.GC12433@phenom.dumpdata.com>
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>
	<4EC6837F.1050201@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EC6837F.1050201@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4EC69E59.011E,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
 implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> So we have two candidates:
> xen_raw_printk + panic
> panic + earlyprintk=xen
> 
> If panic does work with earlyprintk, then the latter one is better.
> Otherwise, there will be duplicated string printed out with
> 'earlyprintk=xen'.

The idea is just to have one function. Whichever prints the
string and panics the machine. If 'panic' does this properly
(and properly meaning it actually prints data when using
the earlyprintk=xen as well as console=hvc0) printout system
the we cuold just use 'panic' and not worry about it.


But if it does not, then we (and by we I mean you) should 
provide a variant of panic() that prints the data properly using the 
earlprintk mechanism. Preferrabily to make it generic.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:18:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:18:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRT1K-0001BM-MG; Fri, 18 Nov 2011 18:18:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RRT1J-0001B9-Js
	for Xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:18:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321640293!2137795!1
X-Originating-IP: [63.239.65.39]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19677 invoked from network); 18 Nov 2011 18:18:13 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-174.messagelabs.com with SMTP;
	18 Nov 2011 18:18:13 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAIIICFd014751
	for <Xen-devel@lists.xensource.com>; Fri, 18 Nov 2011 18:18:12 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAIIIBrb004045; 
	Fri, 18 Nov 2011 13:18:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Xen-devel@lists.xensource.com
Date: Fri, 18 Nov 2011 13:18:28 -0500
Message-Id: <1321640308-20885-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.1
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xsm/flask: Use correct flag to detect writable
	grant mappings
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The flags passed to xsm_grant_mapref are the flags from the map
operation (GNTMAP_*), not status flags (GTF_*).

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index e70feda..1cfa621 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -279,7 +279,7 @@ static int flask_grant_mapref(struct domain *d1, struct domain *d2,
 {
     u32 perms = GRANT__MAP_READ;
 
-    if ( flags & GTF_writing )
+    if (!( flags & GNTMAP_readonly))
         perms |= GRANT__MAP_WRITE;
 
     return domain_has_perm(d1, d2, SECCLASS_GRANT, perms);
-- 
1.7.7.1


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:18:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:18:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRT1K-0001BM-MG; Fri, 18 Nov 2011 18:18:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RRT1J-0001B9-Js
	for Xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:18:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321640293!2137795!1
X-Originating-IP: [63.239.65.39]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19677 invoked from network); 18 Nov 2011 18:18:13 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-174.messagelabs.com with SMTP;
	18 Nov 2011 18:18:13 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAIIICFd014751
	for <Xen-devel@lists.xensource.com>; Fri, 18 Nov 2011 18:18:12 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAIIIBrb004045; 
	Fri, 18 Nov 2011 13:18:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Xen-devel@lists.xensource.com
Date: Fri, 18 Nov 2011 13:18:28 -0500
Message-Id: <1321640308-20885-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.1
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xsm/flask: Use correct flag to detect writable
	grant mappings
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The flags passed to xsm_grant_mapref are the flags from the map
operation (GNTMAP_*), not status flags (GTF_*).

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index e70feda..1cfa621 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -279,7 +279,7 @@ static int flask_grant_mapref(struct domain *d1, struct domain *d2,
 {
     u32 perms = GRANT__MAP_READ;
 
-    if ( flags & GTF_writing )
+    if (!( flags & GNTMAP_readonly))
         perms |= GRANT__MAP_WRITE;
 
     return domain_has_perm(d1, d2, SECCLASS_GRANT, perms);
-- 
1.7.7.1


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:44:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTQA-0001YB-Eu; Fri, 18 Nov 2011 18:44:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RRTQ8-0001Y4-Vg
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:44:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1321641832!3705412!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 692 invoked from network); 18 Nov 2011 18:43:53 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 18 Nov 2011 18:43:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321641832; l=322;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=cC3LPqnLoWQlvVQJeH6l234HskE=;
	b=EKXC357jjPHWqc8LLfJCn8NRnCFskbgIJeXmfEcwbeichxUCwH91VIcdjlaVXea4471
	mUgyDhS1DXcWZr/zarcsLeUu6vsJ1B7ggfsbpNoSBxZzkNSC7rXZRjxrZxs25N1XvJW/Y
	Uc2jYqFeBoksYbit0xnnMRahgFaekMkFLhw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjoQERIuXQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-109-239.pools.arcor-ip.net [88.65.109.239])
	by smtp.strato.de (fruni mo64) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t00616nAIHGnTN ;
	Fri, 18 Nov 2011 19:43:40 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A71F118637; Fri, 18 Nov 2011 19:43:36 +0100 (CET)
Date: Fri, 18 Nov 2011 19:43:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ben Hutchings <bhutchings@solarflare.com>
Message-ID: <20111118184336.GA16027@aepfle.de>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321638394.2883.32.camel@bwh-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, Ben Hutchings wrote:

> On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> > The reported data refers to VMWare vmxnet.
> NAK, we should not just make things up.

So how about removing veth_get_settings, vmxnet3_get_settings,
tun_get_settings and other functions that escaped my grep?

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:44:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTQA-0001YB-Eu; Fri, 18 Nov 2011 18:44:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RRTQ8-0001Y4-Vg
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:44:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1321641832!3705412!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 692 invoked from network); 18 Nov 2011 18:43:53 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 18 Nov 2011 18:43:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321641832; l=322;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=cC3LPqnLoWQlvVQJeH6l234HskE=;
	b=EKXC357jjPHWqc8LLfJCn8NRnCFskbgIJeXmfEcwbeichxUCwH91VIcdjlaVXea4471
	mUgyDhS1DXcWZr/zarcsLeUu6vsJ1B7ggfsbpNoSBxZzkNSC7rXZRjxrZxs25N1XvJW/Y
	Uc2jYqFeBoksYbit0xnnMRahgFaekMkFLhw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjoQERIuXQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-109-239.pools.arcor-ip.net [88.65.109.239])
	by smtp.strato.de (fruni mo64) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t00616nAIHGnTN ;
	Fri, 18 Nov 2011 19:43:40 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A71F118637; Fri, 18 Nov 2011 19:43:36 +0100 (CET)
Date: Fri, 18 Nov 2011 19:43:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ben Hutchings <bhutchings@solarflare.com>
Message-ID: <20111118184336.GA16027@aepfle.de>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321638394.2883.32.camel@bwh-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, Ben Hutchings wrote:

> On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> > The reported data refers to VMWare vmxnet.
> NAK, we should not just make things up.

So how about removing veth_get_settings, vmxnet3_get_settings,
tun_get_settings and other functions that escaped my grep?

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:47:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTSh-0001fx-HV; Fri, 18 Nov 2011 18:46:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RRTSg-0001fi-NY
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:46:54 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321641989!4788488!1
X-Originating-IP: [74.207.240.146]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14471 invoked from network); 18 Nov 2011 18:46:30 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 18:46:30 -0000
Received: from saboo.goop.org (c-50-131-57-2.hsd1.ca.comcast.net [50.131.57.2])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 1B0183CC;
	Fri, 18 Nov 2011 10:46:28 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 8E6D92005B;
	Fri, 18 Nov 2011 10:46:26 -0800 (PST)
Message-ID: <4EC6A802.9090805@goop.org>
Date: Fri, 18 Nov 2011 10:46:26 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Rick Jones <rick.jones2@hp.com>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop> <4EC6A778.1000503@hp.com>
In-Reply-To: <4EC6A778.1000503@hp.com>
X-Enigmail-Version: 1.3.3
Cc: Ben Hutchings <bhutchings@solarflare.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 10:44 AM, Rick Jones wrote:
>  It could I suppose, decide 
> based on the physical NIC to which it is attached, so long as folks 
> using the virtual NIC don't expect its attributes to be the same from 
> system to system.

And assuming there's a physical NIC at all.

    J

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:47:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTSh-0001fx-HV; Fri, 18 Nov 2011 18:46:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RRTSg-0001fi-NY
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:46:54 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321641989!4788488!1
X-Originating-IP: [74.207.240.146]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14471 invoked from network); 18 Nov 2011 18:46:30 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 18:46:30 -0000
Received: from saboo.goop.org (c-50-131-57-2.hsd1.ca.comcast.net [50.131.57.2])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 1B0183CC;
	Fri, 18 Nov 2011 10:46:28 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 8E6D92005B;
	Fri, 18 Nov 2011 10:46:26 -0800 (PST)
Message-ID: <4EC6A802.9090805@goop.org>
Date: Fri, 18 Nov 2011 10:46:26 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Rick Jones <rick.jones2@hp.com>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop> <4EC6A778.1000503@hp.com>
In-Reply-To: <4EC6A778.1000503@hp.com>
X-Enigmail-Version: 1.3.3
Cc: Ben Hutchings <bhutchings@solarflare.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 10:44 AM, Rick Jones wrote:
>  It could I suppose, decide 
> based on the physical NIC to which it is attached, so long as folks 
> using the virtual NIC don't expect its attributes to be the same from 
> system to system.

And assuming there's a physical NIC at all.

    J

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:58:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:58:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTdC-0001yf-NB; Fri, 18 Nov 2011 18:57:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RRTdB-0001yT-6U
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:57:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321642639!4789049!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 433 invoked from network); 18 Nov 2011 18:57:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 18:57:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,534,1315195200"; d="scan'208";a="19234224"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:57:19 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 18 Nov 2011
	13:57:19 -0500
Message-ID: <4EC6AA8D.5090607@citrix.com>
Date: Fri, 18 Nov 2011 18:57:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
References: <4EC273B40200007800061145@nat28.tlf.novell.com>	<4EC53288.5010400@citrix.com>	<4EC625F90200007800061BFE@nat28.tlf.novell.com>
	<4EC69D83.6010704@citrix.com>
In-Reply-To: <4EC69D83.6010704@citrix.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: refine EOI-ing of migrating
 level interrupts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/11/11 18:01, Andrew Cooper wrote:
> On 18/11/11 08:31, Jan Beulich wrote:
>> Now that this is in, could you try (again on the offending system)
>> whether adding e.g. a WARN_ON(vector != desc->arch.old_vector)
>> prior to the just added call to eoi_IO_APIC_irq() (but inside the
>> surrounding if()) would ever trigger (obviously you'd want to make
>> sure that the code path actually gets executed at all - perhaps
>> counting and printing the count once in a while would be the easiest
>> thing to do)?
>>
>> If it does, we obviously need to stay with passing in vector. If not,
>> we'd need to do another round of code inspection to determine
>> whether indeed there's no race when relying on just the stored
>> data.
>>
>> Thanks, Jan
> So long as you also check for arch.old_vector != IRQ_UNASSIGNED_VECTOR,
> this appears to be fine.
>
> I will sort out a patch to change this behavior
>

Wait actually not.  It turns out that there is some race condition which
causes this assertion not to hold.  Over the space of 2 hours with
16guests and dom0 each trying to stress their storage over a line level
interrupt, there have been 5 cases where vector != old_vector.

I presume it is some race condition where the scheduler is attempting to
move IRQs between PCPUs while they are already in a half moved state.

I will attempt to work out what is causing this race condition, but I
have some more important bugs to deal with at the moment.

I guess we can do with the kudge involving having the lapic vector
passed into hw_irq_handler.end until the race condition is identified.

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


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 18:58:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 18:58:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTdC-0001yf-NB; Fri, 18 Nov 2011 18:57:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RRTdB-0001yT-6U
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:57:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321642639!4789049!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 433 invoked from network); 18 Nov 2011 18:57:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 18:57:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,534,1315195200"; d="scan'208";a="19234224"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 13:57:19 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.137.0; Fri, 18 Nov 2011
	13:57:19 -0500
Message-ID: <4EC6AA8D.5090607@citrix.com>
Date: Fri, 18 Nov 2011 18:57:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
References: <4EC273B40200007800061145@nat28.tlf.novell.com>	<4EC53288.5010400@citrix.com>	<4EC625F90200007800061BFE@nat28.tlf.novell.com>
	<4EC69D83.6010704@citrix.com>
In-Reply-To: <4EC69D83.6010704@citrix.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: refine EOI-ing of migrating
 level interrupts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/11/11 18:01, Andrew Cooper wrote:
> On 18/11/11 08:31, Jan Beulich wrote:
>> Now that this is in, could you try (again on the offending system)
>> whether adding e.g. a WARN_ON(vector != desc->arch.old_vector)
>> prior to the just added call to eoi_IO_APIC_irq() (but inside the
>> surrounding if()) would ever trigger (obviously you'd want to make
>> sure that the code path actually gets executed at all - perhaps
>> counting and printing the count once in a while would be the easiest
>> thing to do)?
>>
>> If it does, we obviously need to stay with passing in vector. If not,
>> we'd need to do another round of code inspection to determine
>> whether indeed there's no race when relying on just the stored
>> data.
>>
>> Thanks, Jan
> So long as you also check for arch.old_vector != IRQ_UNASSIGNED_VECTOR,
> this appears to be fine.
>
> I will sort out a patch to change this behavior
>

Wait actually not.  It turns out that there is some race condition which
causes this assertion not to hold.  Over the space of 2 hours with
16guests and dom0 each trying to stress their storage over a line level
interrupt, there have been 5 cases where vector != old_vector.

I presume it is some race condition where the scheduler is attempting to
move IRQs between PCPUs while they are already in a half moved state.

I will attempt to work out what is causing this race condition, but I
have some more important bugs to deal with at the moment.

I guess we can do with the kudge involving having the lapic vector
passed into hw_irq_handler.end until the race condition is identified.

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


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:11:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTq2-0002Ch-HM; Fri, 18 Nov 2011 19:11:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bhutchings@solarflare.com>) id 1RRTq1-0002Cc-6s
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:11:01 +0000
X-Env-Sender: bhutchings@solarflare.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321643436!4841946!1
X-Originating-IP: [216.237.3.220]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14302 invoked from network); 18 Nov 2011 19:10:36 -0000
Received: from mail.solarflare.com (HELO exchange.solarflare.com)
	(216.237.3.220) by server-3.tower-21.messagelabs.com with SMTP;
	18 Nov 2011 19:10:36 -0000
Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by
	exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 18 Nov 2011 11:10:34 -0800
Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com
	(10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1;
	Fri, 18 Nov 2011 11:10:34 -0800
From: Ben Hutchings <bhutchings@solarflare.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111118184336.GA16027@aepfle.de>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
	<20111118184336.GA16027@aepfle.de>
Organization: Solarflare Communications
Date: Fri, 18 Nov 2011 19:10:31 +0000
Message-ID: <1321643431.2883.39.camel@bwh-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) 
X-Originating-IP: [10.17.20.137]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18526.005
X-TM-AS-Result: No--17.348900-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-OriginalArrivalTime: 18 Nov 2011 19:10:34.0865 (UTC)
	FILETIME=[BFCAEE10:01CCA625]
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 19:43 +0100, Olaf Hering wrote:
> On Fri, Nov 18, Ben Hutchings wrote:
> 
> > On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> > > The reported data refers to VMWare vmxnet.
> > NAK, we should not just make things up.
> 
> So how about removing veth_get_settings, vmxnet3_get_settings,
> tun_get_settings and other functions that escaped my grep?

If they can't provide meaningful information then maybe they should be
removed.  However, that could result in a regression for existing
working configurations.  (This isn't the same as the case you're trying
to fix, since those applications have never worked with xen-netfront or
many other drivers that don't implement get_settings.)

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:11:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTq2-0002Ch-HM; Fri, 18 Nov 2011 19:11:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bhutchings@solarflare.com>) id 1RRTq1-0002Cc-6s
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:11:01 +0000
X-Env-Sender: bhutchings@solarflare.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321643436!4841946!1
X-Originating-IP: [216.237.3.220]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14302 invoked from network); 18 Nov 2011 19:10:36 -0000
Received: from mail.solarflare.com (HELO exchange.solarflare.com)
	(216.237.3.220) by server-3.tower-21.messagelabs.com with SMTP;
	18 Nov 2011 19:10:36 -0000
Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by
	exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 18 Nov 2011 11:10:34 -0800
Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com
	(10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1;
	Fri, 18 Nov 2011 11:10:34 -0800
From: Ben Hutchings <bhutchings@solarflare.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111118184336.GA16027@aepfle.de>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
	<20111118184336.GA16027@aepfle.de>
Organization: Solarflare Communications
Date: Fri, 18 Nov 2011 19:10:31 +0000
Message-ID: <1321643431.2883.39.camel@bwh-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) 
X-Originating-IP: [10.17.20.137]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18526.005
X-TM-AS-Result: No--17.348900-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-OriginalArrivalTime: 18 Nov 2011 19:10:34.0865 (UTC)
	FILETIME=[BFCAEE10:01CCA625]
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 19:43 +0100, Olaf Hering wrote:
> On Fri, Nov 18, Ben Hutchings wrote:
> 
> > On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> > > The reported data refers to VMWare vmxnet.
> > NAK, we should not just make things up.
> 
> So how about removing veth_get_settings, vmxnet3_get_settings,
> tun_get_settings and other functions that escaped my grep?

If they can't provide meaningful information then maybe they should be
removed.  However, that could result in a regression for existing
working configurations.  (This isn't the same as the case you're trying
to fix, since those applications have never worked with xen-netfront or
many other drivers that don't implement get_settings.)

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:12:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTr2-0002Ho-5v; Fri, 18 Nov 2011 19:12:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1RRTr0-0002Ha-Sm
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:12:03 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-14.tower-21.messagelabs.com!1321643498!4801086!1
X-Originating-IP: [83.223.49.132]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18166 invoked from network); 18 Nov 2011 19:11:38 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-14.tower-21.messagelabs.com with SMTP;
	18 Nov 2011 19:11:38 -0000
Received: (qmail 10890 invoked from network); 18 Nov 2011 20:11:36 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	18 Nov 2011 20:11:36 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Fri, 18 Nov 2011 20:11:31 +0100
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop> <4EC6A778.1000503@hp.com>
In-Reply-To: <4EC6A778.1000503@hp.com>
MIME-Version: 1.0
Message-Id: <201111182011.32318.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri 18. of November 2011 19:44:08 you wrote:
> On 11/18/2011 09:46 AM, Ben Hutchings wrote:
> > On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> >> Add .get_settings function, return fake data so that ethtool can get
> >> enough information. For some application like VCS, this is useful,
> >> otherwise some of application logic will get panic.
> >> The reported data refers to VMWare vmxnet.
> >> 
> >> Signed-off-by: Xin Wei Hu<xwhu@suse.com>
> >> Signed-off-by: Chunyan Liu<cyliu@suse.com>
> >> Signed-off-by: Olaf Hering<olaf@aepfle.de>
> > 
> > NAK, we should not just make things up.
> 
> Which raises an interesting question for a virtual interface that isn't
> pretending to be a specific NIC type. What should the reported speed be?
>   Is it a 10/100 NIC?  A 1 or 10 GbE NIC? 3.14 GbE?  For other emulated
> interfaces, it rather falls-out from the emulation.  We can say that the
> driver may not make stuff up, but it would seem what is running in the
> host/hypervisor/dom0/whatever will have to.  It could I suppose, decide
> based on the physical NIC to which it is attached, so long as folks
> using the virtual NIC don't expect its attributes to be the same from
> system to system.
> 
> rick

Hmm,
two questions from me.
I think there is 10GbE link reported in Windows gplpv 0.11.0.322 driver.
Let say I have two virtual Windows running on XEN and they are in bridge with 
1GbE physical NIC.
Will the Windows talk to each other on 10GbE thru the bridge?
What should I do to give them 10GbE access to local samba server?
-- 
Pavel Mateja

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:12:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:12:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTr2-0002Ho-5v; Fri, 18 Nov 2011 19:12:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1RRTr0-0002Ha-Sm
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:12:03 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-14.tower-21.messagelabs.com!1321643498!4801086!1
X-Originating-IP: [83.223.49.132]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18166 invoked from network); 18 Nov 2011 19:11:38 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-14.tower-21.messagelabs.com with SMTP;
	18 Nov 2011 19:11:38 -0000
Received: (qmail 10890 invoked from network); 18 Nov 2011 20:11:36 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	18 Nov 2011 20:11:36 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Fri, 18 Nov 2011 20:11:31 +0100
User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop> <4EC6A778.1000503@hp.com>
In-Reply-To: <4EC6A778.1000503@hp.com>
MIME-Version: 1.0
Message-Id: <201111182011.32318.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri 18. of November 2011 19:44:08 you wrote:
> On 11/18/2011 09:46 AM, Ben Hutchings wrote:
> > On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> >> Add .get_settings function, return fake data so that ethtool can get
> >> enough information. For some application like VCS, this is useful,
> >> otherwise some of application logic will get panic.
> >> The reported data refers to VMWare vmxnet.
> >> 
> >> Signed-off-by: Xin Wei Hu<xwhu@suse.com>
> >> Signed-off-by: Chunyan Liu<cyliu@suse.com>
> >> Signed-off-by: Olaf Hering<olaf@aepfle.de>
> > 
> > NAK, we should not just make things up.
> 
> Which raises an interesting question for a virtual interface that isn't
> pretending to be a specific NIC type. What should the reported speed be?
>   Is it a 10/100 NIC?  A 1 or 10 GbE NIC? 3.14 GbE?  For other emulated
> interfaces, it rather falls-out from the emulation.  We can say that the
> driver may not make stuff up, but it would seem what is running in the
> host/hypervisor/dom0/whatever will have to.  It could I suppose, decide
> based on the physical NIC to which it is attached, so long as folks
> using the virtual NIC don't expect its attributes to be the same from
> system to system.
> 
> rick

Hmm,
two questions from me.
I think there is 10GbE link reported in Windows gplpv 0.11.0.322 driver.
Let say I have two virtual Windows running on XEN and they are in bridge with 
1GbE physical NIC.
Will the Windows talk to each other on 10GbE thru the bridge?
What should I do to give them 10GbE access to local samba server?
-- 
Pavel Mateja

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:14:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:14:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTsk-0002Oq-UG; Fri, 18 Nov 2011 19:13:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bhutchings@solarflare.com>) id 1RRTsj-0002Ob-43
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:13:49 +0000
X-Env-Sender: bhutchings@solarflare.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321643604!4118204!1
X-Originating-IP: [216.237.3.220]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12889 invoked from network); 18 Nov 2011 19:13:24 -0000
Received: from mail.solarflare.com (HELO exchange.solarflare.com)
	(216.237.3.220) by server-12.tower-216.messagelabs.com with SMTP;
	18 Nov 2011 19:13:24 -0000
Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by
	exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 18 Nov 2011 11:13:22 -0800
Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com
	(10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1;
	Fri, 18 Nov 2011 11:13:22 -0800
From: Ben Hutchings <bhutchings@solarflare.com>
To: Rick Jones <rick.jones2@hp.com>
In-Reply-To: <4EC6AAF3.6080803@hp.com>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop> <4EC6A778.1000503@hp.com>
	<4EC6A802.9090805@goop.org>  <4EC6AAF3.6080803@hp.com>
Organization: Solarflare Communications
Date: Fri, 18 Nov 2011 19:13:19 +0000
Message-ID: <1321643599.2883.42.camel@bwh-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) 
X-Originating-IP: [10.17.20.137]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18526.005
X-TM-AS-Result: No--21.091700-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-OriginalArrivalTime: 18 Nov 2011 19:13:22.0833 (UTC)
	FILETIME=[23E8D010:01CCA626]
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Olaf Hering <olaf@aepfle.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] use a special value of -2 for virtual devices to
 report indeterminate speed?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 10:58 -0800, Rick Jones wrote:
> On 11/18/2011 10:46 AM, Jeremy Fitzhardinge wrote:
> > On 11/18/2011 10:44 AM, Rick Jones wrote:
> >>   It could I suppose, decide
> >> based on the physical NIC to which it is attached, so long as folks
> >> using the virtual NIC don't expect its attributes to be the same from
> >> system to system.
> >
> > And assuming there's a physical NIC at all.
> 
> It sounds like we need a way to specify "Indeterminate" for link speed? 
>   Or some verbiage to that effect. Right now 0 and -1 cause ethtool to 
> report "Unknown!"
> 
>          if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
>                  fprintf(stdout, "Unknown!\n");
>          else
>                  fprintf(stdout, "%uMb/s\n", speed);
> 
> 
> How about -2 for the u32 cast value of speed returning "Indeterminate" 
> or something like that?  Not in "proper" patch format:
> 
> 	if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
> 		fprintf(stdout, "Unknown!\n");
> 	else if (speed == (u32)(-2))
> 		fprintf(stdout, "Indeterminate.");
> 	else
> 		fprintf(stdout, "%uMb/s\n", speed);

I'm open to something like this, but the problem with assigning new
magic numbers is that older versions of ethtool won't know to report
them as special.

We should also consider stacked drivers like bonding (and presumably
team) that expect real numbers when the link is up.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:14:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:14:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTsk-0002Oq-UG; Fri, 18 Nov 2011 19:13:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bhutchings@solarflare.com>) id 1RRTsj-0002Ob-43
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:13:49 +0000
X-Env-Sender: bhutchings@solarflare.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321643604!4118204!1
X-Originating-IP: [216.237.3.220]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12889 invoked from network); 18 Nov 2011 19:13:24 -0000
Received: from mail.solarflare.com (HELO exchange.solarflare.com)
	(216.237.3.220) by server-12.tower-216.messagelabs.com with SMTP;
	18 Nov 2011 19:13:24 -0000
Received: from OCEX02.SolarFlarecom.com ([10.20.40.31]) by
	exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 18 Nov 2011 11:13:22 -0800
Received: from [10.17.20.137] (10.17.20.137) by ocex02.SolarFlarecom.com
	(10.20.40.31) with Microsoft SMTP Server (TLS) id 14.1.339.1;
	Fri, 18 Nov 2011 11:13:22 -0800
From: Ben Hutchings <bhutchings@solarflare.com>
To: Rick Jones <rick.jones2@hp.com>
In-Reply-To: <4EC6AAF3.6080803@hp.com>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop> <4EC6A778.1000503@hp.com>
	<4EC6A802.9090805@goop.org>  <4EC6AAF3.6080803@hp.com>
Organization: Solarflare Communications
Date: Fri, 18 Nov 2011 19:13:19 +0000
Message-ID: <1321643599.2883.42.camel@bwh-desktop>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) 
X-Originating-IP: [10.17.20.137]
X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18526.005
X-TM-AS-Result: No--21.091700-0.000000-31
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-OriginalArrivalTime: 18 Nov 2011 19:13:22.0833 (UTC)
	FILETIME=[23E8D010:01CCA626]
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Olaf Hering <olaf@aepfle.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] use a special value of -2 for virtual devices to
 report indeterminate speed?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-18 at 10:58 -0800, Rick Jones wrote:
> On 11/18/2011 10:46 AM, Jeremy Fitzhardinge wrote:
> > On 11/18/2011 10:44 AM, Rick Jones wrote:
> >>   It could I suppose, decide
> >> based on the physical NIC to which it is attached, so long as folks
> >> using the virtual NIC don't expect its attributes to be the same from
> >> system to system.
> >
> > And assuming there's a physical NIC at all.
> 
> It sounds like we need a way to specify "Indeterminate" for link speed? 
>   Or some verbiage to that effect. Right now 0 and -1 cause ethtool to 
> report "Unknown!"
> 
>          if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
>                  fprintf(stdout, "Unknown!\n");
>          else
>                  fprintf(stdout, "%uMb/s\n", speed);
> 
> 
> How about -2 for the u32 cast value of speed returning "Indeterminate" 
> or something like that?  Not in "proper" patch format:
> 
> 	if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
> 		fprintf(stdout, "Unknown!\n");
> 	else if (speed == (u32)(-2))
> 		fprintf(stdout, "Indeterminate.");
> 	else
> 		fprintf(stdout, "%uMb/s\n", speed);

I'm open to something like this, but the problem with assigning new
magic numbers is that older versions of ethtool won't know to report
them as special.

We should also consider stacked drivers like bonding (and presumably
team) that expect real numbers when the link is up.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:14:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTtI-0002Sx-C4; Fri, 18 Nov 2011 19:14:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RRTtH-0002SE-2h
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:14:23 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321643637!4107423!1
X-Originating-IP: [198.137.202.13]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20895 invoked from network); 18 Nov 2011 19:13:58 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 19:13:58 -0000
Received: from localhost (cpe-66-65-61-233.nyc.res.rr.com [66.65.61.233])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pAIJBoAv031708
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 11:11:50 -0800
Date: Fri, 18 Nov 2011 14:11:49 -0500 (EST)
Message-Id: <20111118.141149.231957666935653299.davem@davemloft.net>
To: bhutchings@solarflare.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1321638394.2883.32.camel@bwh-desktop>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Fri, 18 Nov 2011 11:11:51 -0800 (PST)
Cc: netdev@vger.kernel.org, olaf@aepfle.de, xen-devel@lists.xensource.com,
	jeremy.fitzhardinge@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 18 Nov 2011 17:46:34 +0000

> On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
>> Add .get_settings function, return fake data so that ethtool can get
>> enough information. For some application like VCS, this is useful,
>> otherwise some of application logic will get panic.
>> The reported data refers to VMWare vmxnet.
>> 
>> Signed-off-by: Xin Wei Hu <xwhu@suse.com>
>> Signed-off-by: Chunyan Liu <cyliu@suse.com>
>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> NAK, we should not just make things up.

Agreed, if you cannot determine the values with certainty do not
implement this method.

Fix the tools which cannot function without this information.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:14:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTtI-0002Sx-C4; Fri, 18 Nov 2011 19:14:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RRTtH-0002SE-2h
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:14:23 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321643637!4107423!1
X-Originating-IP: [198.137.202.13]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20895 invoked from network); 18 Nov 2011 19:13:58 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Nov 2011 19:13:58 -0000
Received: from localhost (cpe-66-65-61-233.nyc.res.rr.com [66.65.61.233])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pAIJBoAv031708
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 18 Nov 2011 11:11:50 -0800
Date: Fri, 18 Nov 2011 14:11:49 -0500 (EST)
Message-Id: <20111118.141149.231957666935653299.davem@davemloft.net>
To: bhutchings@solarflare.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1321638394.2883.32.camel@bwh-desktop>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Fri, 18 Nov 2011 11:11:51 -0800 (PST)
Cc: netdev@vger.kernel.org, olaf@aepfle.de, xen-devel@lists.xensource.com,
	jeremy.fitzhardinge@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 18 Nov 2011 17:46:34 +0000

> On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
>> Add .get_settings function, return fake data so that ethtool can get
>> enough information. For some application like VCS, this is useful,
>> otherwise some of application logic will get panic.
>> The reported data refers to VMWare vmxnet.
>> 
>> Signed-off-by: Xin Wei Hu <xwhu@suse.com>
>> Signed-off-by: Chunyan Liu <cyliu@suse.com>
>> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> NAK, we should not just make things up.

Agreed, if you cannot determine the values with certainty do not
implement this method.

Fix the tools which cannot function without this information.

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:18:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTwt-0002p6-3O; Fri, 18 Nov 2011 19:18:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RRTwr-0002oD-MO
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:18:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1321643861!2142484!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3963 invoked from network); 18 Nov 2011 19:17:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 18 Nov 2011 19:17:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321643860; l=975;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=pcTZfPfW3C12XoGr0b6xrrcxZno=;
	b=MipAPcRZLqsWwg+3W6j/Mh2cLrfJBgtB3INzpvuwUTgxan1qbFqja1XH6oSMmzFAkdW
	a0FmD2pmH2UnCRvr+t8WSMrKW3QAVQcHyu1zJ+guR68kPszfoKuZqSust4j3K762A6yCq
	a/ZjQXAq6SMImF9tR2T/L8bgSQ0N5emYuyc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjoQERIuXQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-109-239.pools.arcor-ip.net [88.65.109.239])
	by post.strato.de (mrclete mo32) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id V023e4nAIII8hu ;
	Fri, 18 Nov 2011 20:17:23 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 9FB5C18637; Fri, 18 Nov 2011 20:17:22 +0100 (CET)
Date: Fri, 18 Nov 2011 20:17:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ben Hutchings <bhutchings@solarflare.com>
Message-ID: <20111118191722.GA16429@aepfle.de>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
	<20111118184336.GA16027@aepfle.de>
	<1321643431.2883.39.camel@bwh-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321643431.2883.39.camel@bwh-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, Ben Hutchings wrote:

> On Fri, 2011-11-18 at 19:43 +0100, Olaf Hering wrote:
> > On Fri, Nov 18, Ben Hutchings wrote:
> > 
> > > On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> > > > The reported data refers to VMWare vmxnet.
> > > NAK, we should not just make things up.
> > 
> > So how about removing veth_get_settings, vmxnet3_get_settings,
> > tun_get_settings and other functions that escaped my grep?
> 
> If they can't provide meaningful information then maybe they should be
> removed.  However, that could result in a regression for existing
> working configurations.  (This isn't the same as the case you're trying
> to fix, since those applications have never worked with xen-netfront or
> many other drivers that don't implement get_settings.)

That may be.
How about a new generic ethtool_op_get_settings_veth which returns fake
values for all relevant drivers (virtio, xen-netfront, and the ones
listed above)?

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:18:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRTwt-0002p6-3O; Fri, 18 Nov 2011 19:18:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RRTwr-0002oD-MO
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:18:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1321643861!2142484!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3963 invoked from network); 18 Nov 2011 19:17:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 18 Nov 2011 19:17:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321643860; l=975;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=pcTZfPfW3C12XoGr0b6xrrcxZno=;
	b=MipAPcRZLqsWwg+3W6j/Mh2cLrfJBgtB3INzpvuwUTgxan1qbFqja1XH6oSMmzFAkdW
	a0FmD2pmH2UnCRvr+t8WSMrKW3QAVQcHyu1zJ+guR68kPszfoKuZqSust4j3K762A6yCq
	a/ZjQXAq6SMImF9tR2T/L8bgSQ0N5emYuyc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjoQERIuXQ==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-109-239.pools.arcor-ip.net [88.65.109.239])
	by post.strato.de (mrclete mo32) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id V023e4nAIII8hu ;
	Fri, 18 Nov 2011 20:17:23 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 9FB5C18637; Fri, 18 Nov 2011 20:17:22 +0100 (CET)
Date: Fri, 18 Nov 2011 20:17:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ben Hutchings <bhutchings@solarflare.com>
Message-ID: <20111118191722.GA16429@aepfle.de>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
	<20111118184336.GA16027@aepfle.de>
	<1321643431.2883.39.camel@bwh-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321643431.2883.39.camel@bwh-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, Ben Hutchings wrote:

> On Fri, 2011-11-18 at 19:43 +0100, Olaf Hering wrote:
> > On Fri, Nov 18, Ben Hutchings wrote:
> > 
> > > On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> > > > The reported data refers to VMWare vmxnet.
> > > NAK, we should not just make things up.
> > 
> > So how about removing veth_get_settings, vmxnet3_get_settings,
> > tun_get_settings and other functions that escaped my grep?
> 
> If they can't provide meaningful information then maybe they should be
> removed.  However, that could result in a regression for existing
> working configurations.  (This isn't the same as the case you're trying
> to fix, since those applications have never worked with xen-netfront or
> many other drivers that don't implement get_settings.)

That may be.
How about a new generic ethtool_op_get_settings_veth which returns fake
values for all relevant drivers (virtio, xen-netfront, and the ones
listed above)?

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:37:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:37:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRUFi-000372-EC; Fri, 18 Nov 2011 19:37:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RRUFh-00036x-7C
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:37:33 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-27.messagelabs.com!1321645015!48870617!1
X-Originating-IP: [192.89.123.25]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24664 invoked from network); 18 Nov 2011 19:36:55 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 19:36:55 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 036C72B7B;
	Fri, 18 Nov 2011 21:37:12 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A5A6020058; Fri, 18 Nov 2011 21:37:12 +0200 (EET)
Date: Fri, 18 Nov 2011 21:37:12 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Pavel Mat??ja <pavel@netsafe.cz>
Message-ID: <20111118193712.GQ12984@reaktio.net>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
	<4EC6A778.1000503@hp.com> <201111182011.32318.pavel@netsafe.cz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201111182011.32318.pavel@netsafe.cz>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 08:11:31PM +0100, Pavel Mat??ja wrote:
> On Fri 18. of November 2011 19:44:08 you wrote:
> > On 11/18/2011 09:46 AM, Ben Hutchings wrote:
> > > On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> > >> Add .get_settings function, return fake data so that ethtool can get
> > >> enough information. For some application like VCS, this is useful,
> > >> otherwise some of application logic will get panic.
> > >> The reported data refers to VMWare vmxnet.
> > >> 
> > >> Signed-off-by: Xin Wei Hu<xwhu@suse.com>
> > >> Signed-off-by: Chunyan Liu<cyliu@suse.com>
> > >> Signed-off-by: Olaf Hering<olaf@aepfle.de>
> > > 
> > > NAK, we should not just make things up.
> > 
> > Which raises an interesting question for a virtual interface that isn't
> > pretending to be a specific NIC type. What should the reported speed be?
> >   Is it a 10/100 NIC?  A 1 or 10 GbE NIC? 3.14 GbE?  For other emulated
> > interfaces, it rather falls-out from the emulation.  We can say that the
> > driver may not make stuff up, but it would seem what is running in the
> > host/hypervisor/dom0/whatever will have to.  It could I suppose, decide
> > based on the physical NIC to which it is attached, so long as folks
> > using the virtual NIC don't expect its attributes to be the same from
> > system to system.
> > 
> > rick
> 
> Hmm,
> two questions from me.
> I think there is 10GbE link reported in Windows gplpv 0.11.0.322 driver.
> Let say I have two virtual Windows running on XEN and they are in bridge with 
> 1GbE physical NIC.
> Will the Windows talk to each other on 10GbE thru the bridge?
> What should I do to give them 10GbE access to local samba server?
>

The reported NIC speed in the VM does not mean anything really,
because it's all virtual "hardware", and the reported speed is not any kind of limit.

Even if windows VM says it's 10 Mbit/sec NIC you can still talk
as fast as your system can go.

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 19:37:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 19:37:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRUFi-000372-EC; Fri, 18 Nov 2011 19:37:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RRUFh-00036x-7C
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:37:33 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-27.messagelabs.com!1321645015!48870617!1
X-Originating-IP: [192.89.123.25]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24664 invoked from network); 18 Nov 2011 19:36:55 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 19:36:55 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 036C72B7B;
	Fri, 18 Nov 2011 21:37:12 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A5A6020058; Fri, 18 Nov 2011 21:37:12 +0200 (EET)
Date: Fri, 18 Nov 2011 21:37:12 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Pavel Mat??ja <pavel@netsafe.cz>
Message-ID: <20111118193712.GQ12984@reaktio.net>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
	<4EC6A778.1000503@hp.com> <201111182011.32318.pavel@netsafe.cz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201111182011.32318.pavel@netsafe.cz>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 18, 2011 at 08:11:31PM +0100, Pavel Mat??ja wrote:
> On Fri 18. of November 2011 19:44:08 you wrote:
> > On 11/18/2011 09:46 AM, Ben Hutchings wrote:
> > > On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
> > >> Add .get_settings function, return fake data so that ethtool can get
> > >> enough information. For some application like VCS, this is useful,
> > >> otherwise some of application logic will get panic.
> > >> The reported data refers to VMWare vmxnet.
> > >> 
> > >> Signed-off-by: Xin Wei Hu<xwhu@suse.com>
> > >> Signed-off-by: Chunyan Liu<cyliu@suse.com>
> > >> Signed-off-by: Olaf Hering<olaf@aepfle.de>
> > > 
> > > NAK, we should not just make things up.
> > 
> > Which raises an interesting question for a virtual interface that isn't
> > pretending to be a specific NIC type. What should the reported speed be?
> >   Is it a 10/100 NIC?  A 1 or 10 GbE NIC? 3.14 GbE?  For other emulated
> > interfaces, it rather falls-out from the emulation.  We can say that the
> > driver may not make stuff up, but it would seem what is running in the
> > host/hypervisor/dom0/whatever will have to.  It could I suppose, decide
> > based on the physical NIC to which it is attached, so long as folks
> > using the virtual NIC don't expect its attributes to be the same from
> > system to system.
> > 
> > rick
> 
> Hmm,
> two questions from me.
> I think there is 10GbE link reported in Windows gplpv 0.11.0.322 driver.
> Let say I have two virtual Windows running on XEN and they are in bridge with 
> 1GbE physical NIC.
> Will the Windows talk to each other on 10GbE thru the bridge?
> What should I do to give them 10GbE access to local samba server?
>

The reported NIC speed in the VM does not mean anything really,
because it's all virtual "hardware", and the reported speed is not any kind of limit.

Even if windows VM says it's 10 Mbit/sec NIC you can still talk
as fast as your system can go.

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 20:08:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 20:08:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRUit-0003Sh-H5; Fri, 18 Nov 2011 20:07:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RRUis-0003Sc-52
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 20:07:42 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-182.messagelabs.com!1321646836!3709306!1
X-Originating-IP: [142.103.6.52]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8949 invoked from network); 18 Nov 2011 20:07:17 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 20:07:17 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pAIK7Dkk028989
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Fri, 18 Nov 2011 12:07:14 -0800
Received: by bkbzt12 with SMTP id zt12so5443536bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 12:07:12 -0800 (PST)
Received: by 10.204.141.24 with SMTP id k24mr4683277bku.97.1321646832170; Fri,
	18 Nov 2011 12:07:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.177.19 with HTTP; Fri, 18 Nov 2011 12:06:30 -0800 (PST)
In-Reply-To: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
References: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 18 Nov 2011 12:06:30 -0800
Message-ID: <CAP8mzPO8w3RPtE-y6bzh7x=OZ0PJ+mPWQX+TFVDxY7+v5YXSsw@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 3 V7] libxc: checkpoint compression
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5607964948321725389=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5607964948321725389==
Content-Type: multipart/alternative; boundary=0015175d682af3353d04b207e186

--0015175d682af3353d04b207e186
Content-Type: text/plain; charset=ISO-8859-1

Ian,
 Do you have any other comments for this patch set?

thanks
shriram

On Mon, Nov 14, 2011 at 2:51 PM, <rshriram@cs.ubc.ca> wrote:

> This patch series adds checkpoint compression functionality, while
> running under Remus.
>
> Changes since last version:
> 1. renamed page_aligned_alloc to xc_memalign and declare it as a global
>   function in xenctrl.h, instead of declaring it in xc_private.h
>
> Shriram
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

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

Ian,<br>=A0Do you have any other comments for this patch set?<br><br>thanks=
<br>shriram<br><br><div class=3D"gmail_quote">On Mon, Nov 14, 2011 at 2:51 =
PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@c=
s.ubc.ca</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">This patch series adds checkpoint compressi=
on functionality, while<br>
running under Remus.<br>
<br>
Changes since last version:<br>
1. renamed page_aligned_alloc to xc_memalign and declare it as a global<br>
 =A0 function in xenctrl.h, instead of declaring it in xc_private.h<br>
<br>
Shriram<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>

--0015175d682af3353d04b207e186--


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

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

--===============5607964948321725389==--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 20:08:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 20:08:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRUit-0003Sh-H5; Fri, 18 Nov 2011 20:07:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RRUis-0003Sc-52
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 20:07:42 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-182.messagelabs.com!1321646836!3709306!1
X-Originating-IP: [142.103.6.52]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8949 invoked from network); 18 Nov 2011 20:07:17 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 20:07:17 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pAIK7Dkk028989
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Fri, 18 Nov 2011 12:07:14 -0800
Received: by bkbzt12 with SMTP id zt12so5443536bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 12:07:12 -0800 (PST)
Received: by 10.204.141.24 with SMTP id k24mr4683277bku.97.1321646832170; Fri,
	18 Nov 2011 12:07:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.177.19 with HTTP; Fri, 18 Nov 2011 12:06:30 -0800 (PST)
In-Reply-To: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
References: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 18 Nov 2011 12:06:30 -0800
Message-ID: <CAP8mzPO8w3RPtE-y6bzh7x=OZ0PJ+mPWQX+TFVDxY7+v5YXSsw@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 3 V7] libxc: checkpoint compression
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5607964948321725389=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5607964948321725389==
Content-Type: multipart/alternative; boundary=0015175d682af3353d04b207e186

--0015175d682af3353d04b207e186
Content-Type: text/plain; charset=ISO-8859-1

Ian,
 Do you have any other comments for this patch set?

thanks
shriram

On Mon, Nov 14, 2011 at 2:51 PM, <rshriram@cs.ubc.ca> wrote:

> This patch series adds checkpoint compression functionality, while
> running under Remus.
>
> Changes since last version:
> 1. renamed page_aligned_alloc to xc_memalign and declare it as a global
>   function in xenctrl.h, instead of declaring it in xc_private.h
>
> Shriram
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

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

Ian,<br>=A0Do you have any other comments for this patch set?<br><br>thanks=
<br>shriram<br><br><div class=3D"gmail_quote">On Mon, Nov 14, 2011 at 2:51 =
PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@c=
s.ubc.ca</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">This patch series adds checkpoint compressi=
on functionality, while<br>
running under Remus.<br>
<br>
Changes since last version:<br>
1. renamed page_aligned_alloc to xc_memalign and declare it as a global<br>
 =A0 function in xenctrl.h, instead of declaring it in xc_private.h<br>
<br>
Shriram<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>

--0015175d682af3353d04b207e186--


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

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

--===============5607964948321725389==--


From xen-devel-bounces@lists.xensource.com Fri Nov 18 21:25:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 21:25:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRVvX-0004m6-7Z; Fri, 18 Nov 2011 21:24:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRVvU-0004ln-Tu
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 21:24:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1321651464!3737194!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17715 invoked from network); 18 Nov 2011 21:24:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 21:24:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,535,1315180800"; 
   d="scan'208";a="9018150"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 21:24:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 21:24:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRVv5-0007yT-TB;
	Fri, 18 Nov 2011 21:24:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRVv5-0003Qa-Sm;
	Fri, 18 Nov 2011 21:24:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9857-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 18 Nov 2011 21:24:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9857: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail    like 9855

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 21:25:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 21:25:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRVvX-0004m6-7Z; Fri, 18 Nov 2011 21:24:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRVvU-0004ln-Tu
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 21:24:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1321651464!3737194!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17715 invoked from network); 18 Nov 2011 21:24:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Nov 2011 21:24:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,535,1315180800"; 
   d="scan'208";a="9018150"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Nov 2011 21:24:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.137.0; Fri, 18 Nov 2011 21:24:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRVv5-0007yT-TB;
	Fri, 18 Nov 2011 21:24:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRVv5-0003Qa-Sm;
	Fri, 18 Nov 2011 21:24:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9857-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 18 Nov 2011 21:24:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9857: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail    like 9855

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 22:28:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 22:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRWue-0005CU-SB; Fri, 18 Nov 2011 22:28:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@kroah.com>) id 1RRWuc-0005CL-Jw
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 22:27:58 +0000
X-Env-Sender: greg@kroah.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321655253!4128815!1
X-Originating-IP: [66.111.4.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3631 invoked from network); 18 Nov 2011 22:27:34 -0000
Received: from out2.smtp.messagingengine.com (HELO
	out2.smtp.messagingengine.com) (66.111.4.26)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 22:27:34 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 31C6A2134E
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 17:27:33 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute2.internal (MEProxy); Fri, 18 Nov 2011 17:27:33 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=subject:to:cc:from:date:in-reply-to
	:message-id:mime-version:content-type:content-transfer-encoding;
	s=smtpout; bh=V6jnK67LnwBrDrAgEgSGiiHlBE0=; b=Gr4pD5ii/fKxsYpIf
	Wtaar14xIAUdrXmy1XH6y/n6VlhQ+zruyfri7cX8K2M3B1pipJu/RCq6BNXabi+p
	MhF6LOHJWDr5v08Hup+1QVFFK9pH378qk7QFv2d1LliXgxRc7ru79JA221Q0Keia
	m0+VxYluz8I2dGonH2urwb2l48=
X-Sasl-enc: CB/T7cgE3YQ4d/uWkgkyQa2ZWWRHkiR279/kfnnKqRkV 1321655252
Received: from localhost (c-76-121-69-168.hsd1.wa.comcast.net [76.121.69.168])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 86024482546;
	Fri, 18 Nov 2011 17:27:32 -0500 (EST)
To: Ian.Campbell@citrix.com, gregkh@suse.de, greg@kroah.com,
	ian.campbell@citrix.com, Jeremy.Fitzhardinge@citrix.com,
	jirislaby@gmail.com, jslaby@suse.cz, konrad.wilk@oracle.com,
	linux-kernel.bfrz@manchmal.in-ulm.de, rjw@sisk.pl,
	tglx@linutronix.de, xen-devel@lists.xensource.com
From: <gregkh@suse.de>
Date: Fri, 18 Nov 2011 14:23:54 -0800
In-Reply-To: <1320828790.16747.99.camel@dagon.hellion.org.uk>
Message-ID: <13216550341959@kroah.org>
MIME-Version: 1.0
Cc: stable@vger.kernel.org, stable-commits@vger.kernel.org
Subject: [Xen-devel] Patch "genirq: Add IRQF_RESUME_EARLY and resume such
	IRQs earlier" has been added to the 2.6.32-longterm tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


This is a note to let you know that I've just added the patch titled

    genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier

to the 2.6.32-longterm tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary

The filename of the patch is:
     genirq-add-irqf_resume_early-and-resume-such-irqs-earlier.patch
and it can be found in the queue-2.6.32 subdirectory.

If you, or anyone else, feels it should not be added to the 2.6.32 longterm tree,
please let <stable@vger.kernel.org> know about it.


>From Ian.Campbell@citrix.com  Fri Nov 18 11:33:31 2011
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 9 Nov 2011 08:53:09 +0000
Subject: genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier
To: Greg KH <greg@kroah.com>
Cc: Jiri Slaby <jslaby@suse.cz>, Greg KH <gregkh@suse.de>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>, Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>, linux-kernel@vger.kernel.org, stable@kernel.org, Jiri Slaby <jirislaby@gmail.com>
Message-ID: <1320828790.16747.99.camel@dagon.hellion.org.uk>


From: Ian Campbell <ian.campbell@citrix.com>

commit 9bab0b7fbaceec47d32db51cd9e59c82fb071f5a upstream

This adds a mechanism to resume selected IRQs during syscore_resume
instead of dpm_resume_noirq.

Under Xen we need to resume IRQs associated with IPIs early enough
that the resched IPI is unmasked and we can therefore schedule
ourselves out of the stop_machine where the suspend/resume takes
place.

This issue was introduced by 676dc3cf5bc3 "xen: Use IRQF_FORCE_RESUME".

Back ported to 2.6.32 (which lacks syscore support) by calling the relavant
resume function directly from sysdev_resume).

v2: Fixed non-x86 build errors.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.uk
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/base/sys.c        |    6 ++++++
 drivers/xen/events.c      |    2 +-
 include/linux/interrupt.h |    6 ++++++
 kernel/irq/pm.c           |   35 ++++++++++++++++++++++++++++-------
 4 files changed, 41 insertions(+), 8 deletions(-)

--- a/drivers/base/sys.c
+++ b/drivers/base/sys.c
@@ -471,6 +471,12 @@ int sysdev_resume(void)
 {
 	struct sysdev_class *cls;
 
+	/*
+	 * Called from syscore in mainline but called directly here
+	 * since syscore does not exist in this tree.
+	 */
+	irq_pm_syscore_resume();
+
 	WARN_ONCE(!irqs_disabled(),
 		"Interrupts enabled while resuming system devices\n");
 
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -536,7 +536,7 @@ int bind_ipi_to_irqhandler(enum ipi_vect
 	if (irq < 0)
 		return irq;
 
-	irqflags |= IRQF_NO_SUSPEND | IRQF_FORCE_RESUME;
+	irqflags |= IRQF_NO_SUSPEND | IRQF_FORCE_RESUME | IRQF_EARLY_RESUME;
 	retval = request_irq(irq, handler, irqflags, devname, dev_id);
 	if (retval != 0) {
 		unbind_from_irq(irq);
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -54,6 +54,8 @@
  *                irq line disabled until the threaded handler has been run.
  * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
  * IRQF_FORCE_RESUME - Force enable it on resume even if IRQF_NO_SUSPEND is set
+ * IRQF_EARLY_RESUME - Resume IRQ early during syscore instead of at device
+ *                resume time.
  */
 #define IRQF_DISABLED		0x00000020
 #define IRQF_SAMPLE_RANDOM	0x00000040
@@ -66,6 +68,7 @@
 #define IRQF_ONESHOT		0x00002000
 #define IRQF_NO_SUSPEND		0x00004000
 #define IRQF_FORCE_RESUME	0x00008000
+#define IRQF_EARLY_RESUME	0x00020000
 
 #define IRQF_TIMER		(__IRQF_TIMER | IRQF_NO_SUSPEND)
 
@@ -198,13 +201,16 @@ extern void suspend_device_irqs(void);
 extern void resume_device_irqs(void);
 #ifdef CONFIG_PM_SLEEP
 extern int check_wakeup_irqs(void);
+extern void irq_pm_syscore_resume(void);
 #else
 static inline int check_wakeup_irqs(void) { return 0; }
+static inline void irq_pm_syscore_resume(void) { };
 #endif
 #else
 static inline void suspend_device_irqs(void) { };
 static inline void resume_device_irqs(void) { };
 static inline int check_wakeup_irqs(void) { return 0; }
+static inline void irq_pm_syscore_resume(void) { };
 #endif
 
 #if defined(CONFIG_SMP) && defined(CONFIG_GENERIC_HARDIRQS)
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -39,25 +39,46 @@ void suspend_device_irqs(void)
 }
 EXPORT_SYMBOL_GPL(suspend_device_irqs);
 
-/**
- * resume_device_irqs - enable interrupt lines disabled by suspend_device_irqs()
- *
- * Enable all interrupt lines previously disabled by suspend_device_irqs() that
- * have the IRQ_SUSPENDED flag set.
- */
-void resume_device_irqs(void)
+static void resume_irqs(bool want_early)
 {
 	struct irq_desc *desc;
 	int irq;
 
 	for_each_irq_desc(irq, desc) {
 		unsigned long flags;
+		bool is_early = desc->action &&
+			desc->action->flags & IRQF_EARLY_RESUME;
+
+		if (is_early != want_early)
+			continue;
 
 		spin_lock_irqsave(&desc->lock, flags);
 		__enable_irq(desc, irq, true);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
+
+/**
+ * irq_pm_syscore_ops - enable interrupt lines early
+ *
+ * Enable all interrupt lines with %IRQF_EARLY_RESUME set.
+ */
+void irq_pm_syscore_resume(void)
+{
+	resume_irqs(true);
+}
+
+/**
+ * resume_device_irqs - enable interrupt lines disabled by suspend_device_irqs()
+ *
+ * Enable all non-%IRQF_EARLY_RESUME interrupt lines previously
+ * disabled by suspend_device_irqs() that have the IRQS_SUSPENDED flag
+ * set as well as those with %IRQF_FORCE_RESUME.
+ */
+void resume_device_irqs(void)
+{
+	resume_irqs(false);
+}
 EXPORT_SYMBOL_GPL(resume_device_irqs);
 
 /**


Patches currently in longterm-queue-2.6.32 which might be from Ian.Campbell@citrix.com are

/home/gregkh/linux/longterm/longterm-queue-2.6.32/queue-2.6.32/genirq-add-irqf_resume_early-and-resume-such-irqs-earlier.patch

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 22:28:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 22:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRWue-0005CU-SB; Fri, 18 Nov 2011 22:28:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@kroah.com>) id 1RRWuc-0005CL-Jw
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 22:27:58 +0000
X-Env-Sender: greg@kroah.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321655253!4128815!1
X-Originating-IP: [66.111.4.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3631 invoked from network); 18 Nov 2011 22:27:34 -0000
Received: from out2.smtp.messagingengine.com (HELO
	out2.smtp.messagingengine.com) (66.111.4.26)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 22:27:34 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 31C6A2134E
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 17:27:33 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute2.internal (MEProxy); Fri, 18 Nov 2011 17:27:33 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=subject:to:cc:from:date:in-reply-to
	:message-id:mime-version:content-type:content-transfer-encoding;
	s=smtpout; bh=V6jnK67LnwBrDrAgEgSGiiHlBE0=; b=Gr4pD5ii/fKxsYpIf
	Wtaar14xIAUdrXmy1XH6y/n6VlhQ+zruyfri7cX8K2M3B1pipJu/RCq6BNXabi+p
	MhF6LOHJWDr5v08Hup+1QVFFK9pH378qk7QFv2d1LliXgxRc7ru79JA221Q0Keia
	m0+VxYluz8I2dGonH2urwb2l48=
X-Sasl-enc: CB/T7cgE3YQ4d/uWkgkyQa2ZWWRHkiR279/kfnnKqRkV 1321655252
Received: from localhost (c-76-121-69-168.hsd1.wa.comcast.net [76.121.69.168])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 86024482546;
	Fri, 18 Nov 2011 17:27:32 -0500 (EST)
To: Ian.Campbell@citrix.com, gregkh@suse.de, greg@kroah.com,
	ian.campbell@citrix.com, Jeremy.Fitzhardinge@citrix.com,
	jirislaby@gmail.com, jslaby@suse.cz, konrad.wilk@oracle.com,
	linux-kernel.bfrz@manchmal.in-ulm.de, rjw@sisk.pl,
	tglx@linutronix.de, xen-devel@lists.xensource.com
From: <gregkh@suse.de>
Date: Fri, 18 Nov 2011 14:23:54 -0800
In-Reply-To: <1320828790.16747.99.camel@dagon.hellion.org.uk>
Message-ID: <13216550341959@kroah.org>
MIME-Version: 1.0
Cc: stable@vger.kernel.org, stable-commits@vger.kernel.org
Subject: [Xen-devel] Patch "genirq: Add IRQF_RESUME_EARLY and resume such
	IRQs earlier" has been added to the 2.6.32-longterm tree
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


This is a note to let you know that I've just added the patch titled

    genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier

to the 2.6.32-longterm tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary

The filename of the patch is:
     genirq-add-irqf_resume_early-and-resume-such-irqs-earlier.patch
and it can be found in the queue-2.6.32 subdirectory.

If you, or anyone else, feels it should not be added to the 2.6.32 longterm tree,
please let <stable@vger.kernel.org> know about it.


>From Ian.Campbell@citrix.com  Fri Nov 18 11:33:31 2011
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 9 Nov 2011 08:53:09 +0000
Subject: genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier
To: Greg KH <greg@kroah.com>
Cc: Jiri Slaby <jslaby@suse.cz>, Greg KH <gregkh@suse.de>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>, Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>, linux-kernel@vger.kernel.org, stable@kernel.org, Jiri Slaby <jirislaby@gmail.com>
Message-ID: <1320828790.16747.99.camel@dagon.hellion.org.uk>


From: Ian Campbell <ian.campbell@citrix.com>

commit 9bab0b7fbaceec47d32db51cd9e59c82fb071f5a upstream

This adds a mechanism to resume selected IRQs during syscore_resume
instead of dpm_resume_noirq.

Under Xen we need to resume IRQs associated with IPIs early enough
that the resched IPI is unmasked and we can therefore schedule
ourselves out of the stop_machine where the suspend/resume takes
place.

This issue was introduced by 676dc3cf5bc3 "xen: Use IRQF_FORCE_RESUME".

Back ported to 2.6.32 (which lacks syscore support) by calling the relavant
resume function directly from sysdev_resume).

v2: Fixed non-x86 build errors.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.uk
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/base/sys.c        |    6 ++++++
 drivers/xen/events.c      |    2 +-
 include/linux/interrupt.h |    6 ++++++
 kernel/irq/pm.c           |   35 ++++++++++++++++++++++++++++-------
 4 files changed, 41 insertions(+), 8 deletions(-)

--- a/drivers/base/sys.c
+++ b/drivers/base/sys.c
@@ -471,6 +471,12 @@ int sysdev_resume(void)
 {
 	struct sysdev_class *cls;
 
+	/*
+	 * Called from syscore in mainline but called directly here
+	 * since syscore does not exist in this tree.
+	 */
+	irq_pm_syscore_resume();
+
 	WARN_ONCE(!irqs_disabled(),
 		"Interrupts enabled while resuming system devices\n");
 
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -536,7 +536,7 @@ int bind_ipi_to_irqhandler(enum ipi_vect
 	if (irq < 0)
 		return irq;
 
-	irqflags |= IRQF_NO_SUSPEND | IRQF_FORCE_RESUME;
+	irqflags |= IRQF_NO_SUSPEND | IRQF_FORCE_RESUME | IRQF_EARLY_RESUME;
 	retval = request_irq(irq, handler, irqflags, devname, dev_id);
 	if (retval != 0) {
 		unbind_from_irq(irq);
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -54,6 +54,8 @@
  *                irq line disabled until the threaded handler has been run.
  * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
  * IRQF_FORCE_RESUME - Force enable it on resume even if IRQF_NO_SUSPEND is set
+ * IRQF_EARLY_RESUME - Resume IRQ early during syscore instead of at device
+ *                resume time.
  */
 #define IRQF_DISABLED		0x00000020
 #define IRQF_SAMPLE_RANDOM	0x00000040
@@ -66,6 +68,7 @@
 #define IRQF_ONESHOT		0x00002000
 #define IRQF_NO_SUSPEND		0x00004000
 #define IRQF_FORCE_RESUME	0x00008000
+#define IRQF_EARLY_RESUME	0x00020000
 
 #define IRQF_TIMER		(__IRQF_TIMER | IRQF_NO_SUSPEND)
 
@@ -198,13 +201,16 @@ extern void suspend_device_irqs(void);
 extern void resume_device_irqs(void);
 #ifdef CONFIG_PM_SLEEP
 extern int check_wakeup_irqs(void);
+extern void irq_pm_syscore_resume(void);
 #else
 static inline int check_wakeup_irqs(void) { return 0; }
+static inline void irq_pm_syscore_resume(void) { };
 #endif
 #else
 static inline void suspend_device_irqs(void) { };
 static inline void resume_device_irqs(void) { };
 static inline int check_wakeup_irqs(void) { return 0; }
+static inline void irq_pm_syscore_resume(void) { };
 #endif
 
 #if defined(CONFIG_SMP) && defined(CONFIG_GENERIC_HARDIRQS)
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -39,25 +39,46 @@ void suspend_device_irqs(void)
 }
 EXPORT_SYMBOL_GPL(suspend_device_irqs);
 
-/**
- * resume_device_irqs - enable interrupt lines disabled by suspend_device_irqs()
- *
- * Enable all interrupt lines previously disabled by suspend_device_irqs() that
- * have the IRQ_SUSPENDED flag set.
- */
-void resume_device_irqs(void)
+static void resume_irqs(bool want_early)
 {
 	struct irq_desc *desc;
 	int irq;
 
 	for_each_irq_desc(irq, desc) {
 		unsigned long flags;
+		bool is_early = desc->action &&
+			desc->action->flags & IRQF_EARLY_RESUME;
+
+		if (is_early != want_early)
+			continue;
 
 		spin_lock_irqsave(&desc->lock, flags);
 		__enable_irq(desc, irq, true);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
+
+/**
+ * irq_pm_syscore_ops - enable interrupt lines early
+ *
+ * Enable all interrupt lines with %IRQF_EARLY_RESUME set.
+ */
+void irq_pm_syscore_resume(void)
+{
+	resume_irqs(true);
+}
+
+/**
+ * resume_device_irqs - enable interrupt lines disabled by suspend_device_irqs()
+ *
+ * Enable all non-%IRQF_EARLY_RESUME interrupt lines previously
+ * disabled by suspend_device_irqs() that have the IRQS_SUSPENDED flag
+ * set as well as those with %IRQF_FORCE_RESUME.
+ */
+void resume_device_irqs(void)
+{
+	resume_irqs(false);
+}
 EXPORT_SYMBOL_GPL(resume_device_irqs);
 
 /**


Patches currently in longterm-queue-2.6.32 which might be from Ian.Campbell@citrix.com are

/home/gregkh/linux/longterm/longterm-queue-2.6.32/queue-2.6.32/genirq-add-irqf_resume_early-and-resume-such-irqs-earlier.patch

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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 23:57:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 23:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRYIR-0005kd-JM; Fri, 18 Nov 2011 23:56:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RRYIQ-0005kX-8f
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 23:56:38 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321660572!4119456!1
X-Originating-IP: [74.207.240.146]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29494 invoked from network); 18 Nov 2011 23:56:13 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 23:56:13 -0000
Received: from saboo.goop.org (c-50-131-57-2.hsd1.ca.comcast.net [50.131.57.2])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id F193F8F41;
	Fri, 18 Nov 2011 15:56:10 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id CDE2520B7E;
	Fri, 18 Nov 2011 15:56:06 -0800 (PST)
Message-ID: <4EC6F096.70808@goop.org>
Date: Fri, 18 Nov 2011 15:56:06 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
X-Enigmail-Version: 1.3.3
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] Xen: update MAINTAINER info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No longer at Citrix, still interested in Xen.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f6bc29..1fbf431 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4949,7 +4949,7 @@ F:	drivers/char/ppdev.c
 F:	include/linux/ppdev.h
 
 PARAVIRT_OPS INTERFACE
-M:	Jeremy Fitzhardinge <jeremy@xensource.com>
+M:	Jeremy Fitzhardinge <jeremy@goop.org>
 M:	Chris Wright <chrisw@sous-sol.org>
 M:	Alok Kataria <akataria@vmware.com>
 M:	Rusty Russell <rusty@rustcorp.com.au>
@@ -7401,8 +7401,8 @@ S:	Maintained
 F:	arch/x86/kernel/cpu/mcheck/*
 
 XEN HYPERVISOR INTERFACE
-M:	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
 M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+M:	Jeremy Fitzhardinge <jeremy@goop.org>
 L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
 L:	virtualization@lists.linux-foundation.org
 S:	Supported



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

From xen-devel-bounces@lists.xensource.com Fri Nov 18 23:57:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 18 Nov 2011 23:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRYIR-0005kd-JM; Fri, 18 Nov 2011 23:56:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RRYIQ-0005kX-8f
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 23:56:38 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321660572!4119456!1
X-Originating-IP: [74.207.240.146]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29494 invoked from network); 18 Nov 2011 23:56:13 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 23:56:13 -0000
Received: from saboo.goop.org (c-50-131-57-2.hsd1.ca.comcast.net [50.131.57.2])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id F193F8F41;
	Fri, 18 Nov 2011 15:56:10 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id CDE2520B7E;
	Fri, 18 Nov 2011 15:56:06 -0800 (PST)
Message-ID: <4EC6F096.70808@goop.org>
Date: Fri, 18 Nov 2011 15:56:06 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Linus Torvalds <torvalds@linux-foundation.org>
X-Enigmail-Version: 1.3.3
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] Xen: update MAINTAINER info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

No longer at Citrix, still interested in Xen.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f6bc29..1fbf431 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4949,7 +4949,7 @@ F:	drivers/char/ppdev.c
 F:	include/linux/ppdev.h
 
 PARAVIRT_OPS INTERFACE
-M:	Jeremy Fitzhardinge <jeremy@xensource.com>
+M:	Jeremy Fitzhardinge <jeremy@goop.org>
 M:	Chris Wright <chrisw@sous-sol.org>
 M:	Alok Kataria <akataria@vmware.com>
 M:	Rusty Russell <rusty@rustcorp.com.au>
@@ -7401,8 +7401,8 @@ S:	Maintained
 F:	arch/x86/kernel/cpu/mcheck/*
 
 XEN HYPERVISOR INTERFACE
-M:	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
 M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+M:	Jeremy Fitzhardinge <jeremy@goop.org>
 L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
 L:	virtualization@lists.linux-foundation.org
 S:	Supported



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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 00:18:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 00:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRYcn-0006JN-E1; Sat, 19 Nov 2011 00:17:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RRYcm-0006JI-GQ
	for Xen-devel@lists.xensource.com; Sat, 19 Nov 2011 00:17:40 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1321661809!53358433!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12984 invoked from network); 19 Nov 2011 00:16:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2011 00:16:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAJ0HALw018650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 19 Nov 2011 00:17:10 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAJ0H92D013178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 19 Nov 2011 00:17:09 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAJ0H3kg019218; Fri, 18 Nov 2011 18:17:03 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 16:17:03 -0800
Date: Fri, 18 Nov 2011 16:17:02 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111118161702.05f13ea5@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.00.1111181159150.3519@kaball-desktop>
References: <20110627122404.23d2d0ce@mantra.us.oracle.com>
	<20110630185431.3ea308c6@mantra.us.oracle.com>
	<20110708185301.4b040a21@mantra.us.oracle.com>
	<20110727185828.55099372@mantra.us.oracle.com>
	<20111117153838.04e15aa9@mantra.us.oracle.com>
	<alpine.DEB.2.00.1111181159150.3519@kaball-desktop>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4EC6F587.001E,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] HYBRID: PV in HVM container
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 18 Nov 2011 12:21:19 +0000
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Thu, 17 Nov 2011, Mukesh Rathor wrote:
> > Alright, got hybrid with EPT numbers in now from my prototype, it
> > needs some perf work.. 
> 
> Is HVM a PV on HVM guest or a pure HVM guest (no CONFIG_XEN)?

PV on HVM.


> How is it possible that the HYB-EPT numbers here are so much worse
> than HVM? Shouldn't they be the same as in the other tests?
 
Yeah I know. I wondered that myself. I need to investigate.


> why are you using the paravirt version of start_context_switch and
> end_context_switch? Is this for the non-autotranslate version?

this is for non-autotranslate version.

> 
> So in theory HYB-EPT is running with native_cpu_ops and
> native_mmu_ops; in this case I don't understand why the performances
> are lower than HVM.

Yup, same here. I'll have to investigate to see whats going on. Keep you
posted. I am working on SMP now, then I'll take a look.


thanks,
Mukesh


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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 00:18:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 00:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRYcn-0006JN-E1; Sat, 19 Nov 2011 00:17:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RRYcm-0006JI-GQ
	for Xen-devel@lists.xensource.com; Sat, 19 Nov 2011 00:17:40 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1321661809!53358433!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12984 invoked from network); 19 Nov 2011 00:16:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2011 00:16:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAJ0HALw018650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 19 Nov 2011 00:17:10 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAJ0H92D013178
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 19 Nov 2011 00:17:09 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAJ0H3kg019218; Fri, 18 Nov 2011 18:17:03 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 16:17:03 -0800
Date: Fri, 18 Nov 2011 16:17:02 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111118161702.05f13ea5@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.00.1111181159150.3519@kaball-desktop>
References: <20110627122404.23d2d0ce@mantra.us.oracle.com>
	<20110630185431.3ea308c6@mantra.us.oracle.com>
	<20110708185301.4b040a21@mantra.us.oracle.com>
	<20110727185828.55099372@mantra.us.oracle.com>
	<20111117153838.04e15aa9@mantra.us.oracle.com>
	<alpine.DEB.2.00.1111181159150.3519@kaball-desktop>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4EC6F587.001E,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] HYBRID: PV in HVM container
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 18 Nov 2011 12:21:19 +0000
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Thu, 17 Nov 2011, Mukesh Rathor wrote:
> > Alright, got hybrid with EPT numbers in now from my prototype, it
> > needs some perf work.. 
> 
> Is HVM a PV on HVM guest or a pure HVM guest (no CONFIG_XEN)?

PV on HVM.


> How is it possible that the HYB-EPT numbers here are so much worse
> than HVM? Shouldn't they be the same as in the other tests?
 
Yeah I know. I wondered that myself. I need to investigate.


> why are you using the paravirt version of start_context_switch and
> end_context_switch? Is this for the non-autotranslate version?

this is for non-autotranslate version.

> 
> So in theory HYB-EPT is running with native_cpu_ops and
> native_mmu_ops; in this case I don't understand why the performances
> are lower than HVM.

Yup, same here. I'll have to investigate to see whats going on. Keep you
posted. I am working on SMP now, then I'll take a look.


thanks,
Mukesh


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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 01:19:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 01:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRZa5-0006rs-Lt; Sat, 19 Nov 2011 01:18:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RRZa4-0006rn-Ez
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 01:18:56 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-3.tower-27.messagelabs.com!1321665188!46516682!1
X-Originating-IP: [203.16.207.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2155 invoked from network); 19 Nov 2011 01:13:11 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Nov 2011 01:13:11 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RRZUo-0000vh-Rf; Sat, 19 Nov 2011 12:13:30 +1100
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sat, 19 Nov 2011 12:13:29 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EDFD5F@trantor>
In-Reply-To: <20111118193712.GQ12984@reaktio.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
Thread-Index: AcymKoq1+HC9fLyVRTyGxQVaRqwVRgALYuHQ
References: <20111118164805.GA14345@aepfle.de><1321638394.2883.32.camel@bwh-desktop><4EC6A778.1000503@hp.com>
	<201111182011.32318.pavel@netsafe.cz>
	<20111118193712.GQ12984@reaktio.net>
From: "James Harper" <james.harper@bendigoit.com.au>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>,
	"Pavel Mat??ja" <pavel@netsafe.cz>
X-Really-From-Bendigo-IT: magichashvalue
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> The reported NIC speed in the VM does not mean anything really, because
> it's all virtual "hardware", and the reported speed is not any kind of limit.
> 
> Even if windows VM says it's 10 Mbit/sec NIC you can still talk as fast as your
> system can go.
> 

That's not quite true. Windows or some application might equate 10Mbit == WAN and do things a bit differently. BITS certainly scales back throughput but I think it does that based on actual tested throughput, although it might use the link speed as an indication.

A HVM domain needs to report something because it is emulated hardware. A way to pass that through from Dom0 would be nice, but probably a lot of work for little gain vs just making up a reasonable figure.

James

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 01:19:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 01:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRZa5-0006rs-Lt; Sat, 19 Nov 2011 01:18:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RRZa4-0006rn-Ez
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 01:18:56 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-3.tower-27.messagelabs.com!1321665188!46516682!1
X-Originating-IP: [203.16.207.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2155 invoked from network); 19 Nov 2011 01:13:11 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-3.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Nov 2011 01:13:11 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RRZUo-0000vh-Rf; Sat, 19 Nov 2011 12:13:30 +1100
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sat, 19 Nov 2011 12:13:29 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EDFD5F@trantor>
In-Reply-To: <20111118193712.GQ12984@reaktio.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
Thread-Index: AcymKoq1+HC9fLyVRTyGxQVaRqwVRgALYuHQ
References: <20111118164805.GA14345@aepfle.de><1321638394.2883.32.camel@bwh-desktop><4EC6A778.1000503@hp.com>
	<201111182011.32318.pavel@netsafe.cz>
	<20111118193712.GQ12984@reaktio.net>
From: "James Harper" <james.harper@bendigoit.com.au>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>,
	"Pavel Mat??ja" <pavel@netsafe.cz>
X-Really-From-Bendigo-IT: magichashvalue
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> The reported NIC speed in the VM does not mean anything really, because
> it's all virtual "hardware", and the reported speed is not any kind of limit.
> 
> Even if windows VM says it's 10 Mbit/sec NIC you can still talk as fast as your
> system can go.
> 

That's not quite true. Windows or some application might equate 10Mbit == WAN and do things a bit differently. BITS certainly scales back throughput but I think it does that based on actual tested throughput, although it might use the link speed as an indication.

A HVM domain needs to report something because it is emulated hardware. A way to pass that through from Dom0 would be nice, but probably a lot of work for little gain vs just making up a reasonable figure.

James

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 01:33:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 01:33:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRZnR-00075S-9J; Sat, 19 Nov 2011 01:32:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RRZnQ-00075N-6s
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 01:32:44 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-5.tower-27.messagelabs.com!1321666307!53709505!1
X-Originating-IP: [203.16.224.4]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5860 invoked from network); 19 Nov 2011 01:31:50 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Nov 2011 01:31:50 -0000
Received: from mail.bendigoit.com.au ([203.16.207.99])
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RRZmw-0003oC-FE; Sat, 19 Nov 2011 12:32:14 +1100
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sat, 19 Nov 2011 12:32:09 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EDFD60@trantor>
In-Reply-To: <201111182011.32318.pavel@netsafe.cz>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
Thread-Index: AcymJo1u1SAE0c4NSsafuQtppLhp7QAMe4sA
References: <20111118164805.GA14345@aepfle.de><1321638394.2883.32.camel@bwh-desktop>
	<4EC6A778.1000503@hp.com> <201111182011.32318.pavel@netsafe.cz>
From: "James Harper" <james.harper@bendigoit.com.au>
To: =?utf-8?B?UGF2ZWwgTWF0xJtqYQ==?= <pavel@netsafe.cz>,
	<xen-devel@lists.xensource.com>
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 
> Hmm,
> two questions from me.
> I think there is 10GbE link reported in Windows gplpv 0.11.0.322 driver.
> Let say I have two virtual Windows running on XEN and they are in bridge
> with 1GbE physical NIC.
> Will the Windows talk to each other on 10GbE thru the bridge?
> What should I do to give them 10GbE access to local samba server?

I've never had GPLPV talking at 10Gb, but it can easily do 2-4Gb to Dom0 or another DomU, so reporting a 1Gb figure is aiming a little low. Windows basically demands that you give a value, and Hyper-V reports 10Gb so I do too.

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 01:33:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 01:33:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRZnR-00075S-9J; Sat, 19 Nov 2011 01:32:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RRZnQ-00075N-6s
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 01:32:44 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-5.tower-27.messagelabs.com!1321666307!53709505!1
X-Originating-IP: [203.16.224.4]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5860 invoked from network); 19 Nov 2011 01:31:50 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Nov 2011 01:31:50 -0000
Received: from mail.bendigoit.com.au ([203.16.207.99])
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RRZmw-0003oC-FE; Sat, 19 Nov 2011 12:32:14 +1100
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sat, 19 Nov 2011 12:32:09 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EDFD60@trantor>
In-Reply-To: <201111182011.32318.pavel@netsafe.cz>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
Thread-Index: AcymJo1u1SAE0c4NSsafuQtppLhp7QAMe4sA
References: <20111118164805.GA14345@aepfle.de><1321638394.2883.32.camel@bwh-desktop>
	<4EC6A778.1000503@hp.com> <201111182011.32318.pavel@netsafe.cz>
From: "James Harper" <james.harper@bendigoit.com.au>
To: =?utf-8?B?UGF2ZWwgTWF0xJtqYQ==?= <pavel@netsafe.cz>,
	<xen-devel@lists.xensource.com>
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 
> Hmm,
> two questions from me.
> I think there is 10GbE link reported in Windows gplpv 0.11.0.322 driver.
> Let say I have two virtual Windows running on XEN and they are in bridge
> with 1GbE physical NIC.
> Will the Windows talk to each other on 10GbE thru the bridge?
> What should I do to give them 10GbE access to local samba server?

I've never had GPLPV talking at 10Gb, but it can easily do 2-4Gb to Dom0 or another DomU, so reporting a 1Gb figure is aiming a little low. Windows basically demands that you give a value, and Hyper-V reports 10Gb so I do too.

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 02:49:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 02:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRayj-0008IQ-0C; Sat, 19 Nov 2011 02:48:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRayg-0008IL-Vn
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 02:48:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321670882!4130827!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23367 invoked from network); 19 Nov 2011 02:48:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 02:48:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,537,1315180800"; 
   d="scan'208";a="9019276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Nov 2011 02:48: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.137.0; Sat, 19 Nov 2011 02:48:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRayH-0001aY-LT;
	Sat, 19 Nov 2011 02:48:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRayH-00083r-LA;
	Sat, 19 Nov 2011 02:48:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9860-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 19 Nov 2011 02:48:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9860: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 02:49:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 02:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRayj-0008IQ-0C; Sat, 19 Nov 2011 02:48:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRayg-0008IL-Vn
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 02:48:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321670882!4130827!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23367 invoked from network); 19 Nov 2011 02:48:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 02:48:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,537,1315180800"; 
   d="scan'208";a="9019276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Nov 2011 02:48: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.137.0; Sat, 19 Nov 2011 02:48:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRayH-0001aY-LT;
	Sat, 19 Nov 2011 02:48:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRayH-00083r-LA;
	Sat, 19 Nov 2011 02:48:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9860-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 19 Nov 2011 02:48:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9860: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 03:38:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 03:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRbkU-0000Gp-Ur; Sat, 19 Nov 2011 03:37:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RRbkS-0000Gg-Kw
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 03:37:48 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321673842!3741078!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29906 invoked from network); 19 Nov 2011 03:37:23 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2011 03:37:23 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAJ3bIt8005359
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 19 Nov 2011 03:37:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAJ3bHcX000980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 19 Nov 2011 03:37:18 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAJ3bAtw000593; Fri, 18 Nov 2011 21:37:10 -0600
Received: from [123.123.0.208] (/123.123.0.208)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 19:37:10 -0800
Message-ID: <4EC72454.8000502@oracle.com>
Date: Sat, 19 Nov 2011 11:36:52 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
	<20111118135221.GC12433@phenom.dumpdata.com>
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>
	<4EC6837F.1050201@oracle.com>
	<20111118180500.GA19469@phenom.dumpdata.com>
In-Reply-To: <20111118180500.GA19469@phenom.dumpdata.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4EC7246F.00D9,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-11-19 2:05, Konrad Rzeszutek Wilk wrote:
>> So we have two candidates:
>> xen_raw_printk + panic
>> panic + earlyprintk=xen
>>
>> If panic does work with earlyprintk, then the latter one is better.
>> Otherwise, there will be duplicated string printed out with
>> 'earlyprintk=xen'.
>>     
>
> The idea is just to have one function. Whichever prints the
> string and panics the machine. If 'panic' does this properly
> (and properly meaning it actually prints data when using
> the earlyprintk=xen as well as console=hvc0) printout system
> the we cuold just use 'panic' and not worry about it.
>
>   
Ok.
> But if it does not, then we (and by we I mean you) should 
> provide a variant of panic() that prints the data properly using the 
> earlprintk mechanism. Preferrabily to make it generic.
>   
So this work depends on whether panic works well with earlyprink=xen, I 
will do some test on panic first.

Thanks
Annie

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 03:38:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 03:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRbkU-0000Gp-Ur; Sat, 19 Nov 2011 03:37:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RRbkS-0000Gg-Kw
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 03:37:48 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321673842!3741078!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29906 invoked from network); 19 Nov 2011 03:37:23 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2011 03:37:23 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAJ3bIt8005359
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 19 Nov 2011 03:37:19 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAJ3bHcX000980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 19 Nov 2011 03:37:18 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAJ3bAtw000593; Fri, 18 Nov 2011 21:37:10 -0600
Received: from [123.123.0.208] (/123.123.0.208)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 18 Nov 2011 19:37:10 -0800
Message-ID: <4EC72454.8000502@oracle.com>
Date: Sat, 19 Nov 2011 11:36:52 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
	<20111118135221.GC12433@phenom.dumpdata.com>
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>
	<4EC6837F.1050201@oracle.com>
	<20111118180500.GA19469@phenom.dumpdata.com>
In-Reply-To: <20111118180500.GA19469@phenom.dumpdata.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4EC7246F.00D9,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-11-19 2:05, Konrad Rzeszutek Wilk wrote:
>> So we have two candidates:
>> xen_raw_printk + panic
>> panic + earlyprintk=xen
>>
>> If panic does work with earlyprintk, then the latter one is better.
>> Otherwise, there will be duplicated string printed out with
>> 'earlyprintk=xen'.
>>     
>
> The idea is just to have one function. Whichever prints the
> string and panics the machine. If 'panic' does this properly
> (and properly meaning it actually prints data when using
> the earlyprintk=xen as well as console=hvc0) printout system
> the we cuold just use 'panic' and not worry about it.
>
>   
Ok.
> But if it does not, then we (and by we I mean you) should 
> provide a variant of panic() that prints the data properly using the 
> earlprintk mechanism. Preferrabily to make it generic.
>   
So this work depends on whether panic works well with earlyprink=xen, I 
will do some test on panic first.

Thanks
Annie

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 07:25:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 07:25:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRfI6-0001V5-AO; Sat, 19 Nov 2011 07:24:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRfI3-0001V0-V6
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 07:24:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321687340!44961262!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27848 invoked from network); 19 Nov 2011 07:22:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 07:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,537,1315180800"; 
   d="scan'208";a="9019906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Nov 2011 07:24:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 19 Nov 2011 07:24:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRfHe-0003Zv-8k;
	Sat, 19 Nov 2011 07:24:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRfHe-0006Ly-2K;
	Sat, 19 Nov 2011 07:24:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9864-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 19 Nov 2011 07:24:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9864: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 9860 REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 9860 REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 9860 REGR. vs. 9855
 test-i386-i386-win            7 windows-install    fail in 9860 REGR. vs. 9855
 test-amd64-i386-win           7 windows-install    fail in 9860 REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 9860 REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install    fail in 9860 REGR. vs. 9855

Tests which are failing intermittently (not blocking):
 build-i386-pvops              4 kernel-build                 fail pass in 9860
 build-amd64-oldkern           4 xen-build                    fail pass in 9860

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 07:25:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 07:25:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRfI6-0001V5-AO; Sat, 19 Nov 2011 07:24:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRfI3-0001V0-V6
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 07:24:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321687340!44961262!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27848 invoked from network); 19 Nov 2011 07:22:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 07:22:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,537,1315180800"; 
   d="scan'208";a="9019906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Nov 2011 07:24:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 19 Nov 2011 07:24:18 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRfHe-0003Zv-8k;
	Sat, 19 Nov 2011 07:24:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRfHe-0006Ly-2K;
	Sat, 19 Nov 2011 07:24:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9864-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 19 Nov 2011 07:24:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9864: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-intel  7 redhat-install   fail in 9860 REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 9860 REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 9860 REGR. vs. 9855
 test-i386-i386-win            7 windows-install    fail in 9860 REGR. vs. 9855
 test-amd64-i386-win           7 windows-install    fail in 9860 REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install   fail in 9860 REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install    fail in 9860 REGR. vs. 9855

Tests which are failing intermittently (not blocking):
 build-i386-pvops              4 kernel-build                 fail pass in 9860
 build-amd64-oldkern           4 xen-build                    fail pass in 9860

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 12:09:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 12:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRjii-0002zX-4Q; Sat, 19 Nov 2011 12:08:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRjig-0002zS-Gx
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 12:08:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321704485!4160725!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17060 invoked from network); 19 Nov 2011 12:08:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 12:08:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,538,1315180800"; 
   d="scan'208";a="9021254"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Nov 2011 12:08:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 19 Nov 2011 12:08:04 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRjiG-00052A-NY;
	Sat, 19 Nov 2011 12:08:04 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRjiG-0002pa-Bf;
	Sat, 19 Nov 2011 12:08:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9868-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 19 Nov 2011 12:08:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9868: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9817
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 12:09:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 12:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRjii-0002zX-4Q; Sat, 19 Nov 2011 12:08:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRjig-0002zS-Gx
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 12:08:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321704485!4160725!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17060 invoked from network); 19 Nov 2011 12:08:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 12:08:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,538,1315180800"; 
   d="scan'208";a="9021254"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Nov 2011 12:08:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 19 Nov 2011 12:08:04 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRjiG-00052A-NY;
	Sat, 19 Nov 2011 12:08:04 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRjiG-0002pa-Bf;
	Sat, 19 Nov 2011 12:08:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9868-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 19 Nov 2011 12:08:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9868: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9817
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 17:27:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 17:27:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRoh2-0005XN-9u; Sat, 19 Nov 2011 17:27:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRoh0-0005XI-HE
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 17:27:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321723601!4181161!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22929 invoked from network); 19 Nov 2011 17:26:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 17:26:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,539,1315180800"; 
   d="scan'208";a="9023045"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Nov 2011 17:26:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 19 Nov 2011 17:26:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRoga-0006n3-Ao;
	Sat, 19 Nov 2011 17:26:40 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRoga-0007KU-7U;
	Sat, 19 Nov 2011 17:26:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9872-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 19 Nov 2011 17:26:40 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9872: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2   10 guest-saverestore            fail pass in 9868

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                fail in 9868 like 9817

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-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-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 17:27:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 17:27:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRoh2-0005XN-9u; Sat, 19 Nov 2011 17:27:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRoh0-0005XI-HE
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 17:27:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321723601!4181161!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22929 invoked from network); 19 Nov 2011 17:26:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 17:26:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,539,1315180800"; 
   d="scan'208";a="9023045"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Nov 2011 17:26:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 19 Nov 2011 17:26:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRoga-0006n3-Ao;
	Sat, 19 Nov 2011 17:26:40 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRoga-0007KU-7U;
	Sat, 19 Nov 2011 17:26:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9872-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 19 Nov 2011 17:26:40 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9872: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2   10 guest-saverestore            fail pass in 9868

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf      5 xen-boot                fail in 9868 like 9817

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-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-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 22:00:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 22:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRswL-0007fW-Ta; Sat, 19 Nov 2011 21:59:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RRswJ-0007fR-Pq
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 21:59:12 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321739926!4895235!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13024 invoked from network); 19 Nov 2011 21:58:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2011 21:58:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321739925; l=350;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=enMOkY0NoG2Zc+B9Jjel9WhPdFo=;
	b=l5JftXEvlVC5kTSiEkr9Ecg4hydXvQcZ/xJcds0DT53hBTnqMbcRSk1gE+NqvOSX444
	oWqV5peSBpxll0z3CMavyz0RtEKligSKye7us20ZNpsvPZ7cI+qxTs0FfbHv2jNmlXg9q
	purKVACyOp9Xis2KdcCYWNvQbGw3OPmYQac=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0MED60
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-233.pools.arcor-ip.net [88.65.94.233])
	by smtp.strato.de (cohen mo23) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I0460anAJLCFVO ;
	Sat, 19 Nov 2011 22:58:34 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5834B18637; Sat, 19 Nov 2011 22:58:33 +0100 (CET)
Date: Sat, 19 Nov 2011 22:58:33 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <20111119215832.GA27626@aepfle.de>
References: <1321471508-31633-1-git-send-email-jean.guyader@eu.citrix.com>
	<1321471508-31633-2-git-send-email-jean.guyader@eu.citrix.com>
	<1321471508-31633-3-git-send-email-jean.guyader@eu.citrix.com>
	<1321471508-31633-4-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321471508-31633-4-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: allen.m.kay@intel.com, keir@xen.org, xen-devel@lists.xensource.com,
	tim@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
 XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 16, Jean Guyader wrote:

> Move the code for the XENMEM_add_to_physmap case into it's own
> function (xenmem_add_to_physmap).

This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite failures.
(XEN) Assertion '!in_atomic()' failed at softirq.c:61

preempt_count is like fffffc52 or fffffc00 in my testing.

Olaf

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 22:00:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 22:00:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRswL-0007fW-Ta; Sat, 19 Nov 2011 21:59:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RRswJ-0007fR-Pq
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 21:59:12 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321739926!4895235!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13024 invoked from network); 19 Nov 2011 21:58:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Nov 2011 21:58:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321739925; l=350;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=enMOkY0NoG2Zc+B9Jjel9WhPdFo=;
	b=l5JftXEvlVC5kTSiEkr9Ecg4hydXvQcZ/xJcds0DT53hBTnqMbcRSk1gE+NqvOSX444
	oWqV5peSBpxll0z3CMavyz0RtEKligSKye7us20ZNpsvPZ7cI+qxTs0FfbHv2jNmlXg9q
	purKVACyOp9Xis2KdcCYWNvQbGw3OPmYQac=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0MED60
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-233.pools.arcor-ip.net [88.65.94.233])
	by smtp.strato.de (cohen mo23) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I0460anAJLCFVO ;
	Sat, 19 Nov 2011 22:58:34 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5834B18637; Sat, 19 Nov 2011 22:58:33 +0100 (CET)
Date: Sat, 19 Nov 2011 22:58:33 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <20111119215832.GA27626@aepfle.de>
References: <1321471508-31633-1-git-send-email-jean.guyader@eu.citrix.com>
	<1321471508-31633-2-git-send-email-jean.guyader@eu.citrix.com>
	<1321471508-31633-3-git-send-email-jean.guyader@eu.citrix.com>
	<1321471508-31633-4-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1321471508-31633-4-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: allen.m.kay@intel.com, keir@xen.org, xen-devel@lists.xensource.com,
	tim@xen.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
 XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 16, Jean Guyader wrote:

> Move the code for the XENMEM_add_to_physmap case into it's own
> function (xenmem_add_to_physmap).

This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite failures.
(XEN) Assertion '!in_atomic()' failed at softirq.c:61

preempt_count is like fffffc52 or fffffc00 in my testing.

Olaf

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 22:15:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 22:15:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRtBG-0007tq-Jm; Sat, 19 Nov 2011 22:14:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jxinpku@gmail.com>) id 1RRtBF-0007tl-Qc
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 22:14:38 +0000
X-Env-Sender: jxinpku@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321740851!4884841!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12618 invoked from network); 19 Nov 2011 22:14:12 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 22:14:12 -0000
Received: by yenm6 with SMTP id m6so19909yen.30
	for <xen-devel@lists.xensource.com>;
	Sat, 19 Nov 2011 14:14:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=BfWe7uiJG/Tiv9Zou6S7dGFOdCq3wUEeVZ98B+YWfEA=;
	b=hYg5cDOWinEVZxXIlzwo1qoqkYN6h24jfyi9BQe5kOG1swkC7Do+lIRfwvSATgrEgR
	b+2u4/dB9CLN7X/9SP5eAqbTnd+kZ/8Dcvc//qXMGK3cL8qFcFdsTIoCfy5iUN8A3UAS
	Vv2TDsk2LyOX+DOXWhXmCnI0Xe54O/ksr7Thw=
MIME-Version: 1.0
Received: by 10.68.22.228 with SMTP id h4mr16693466pbf.10.1321740850193; Sat,
	19 Nov 2011 14:14:10 -0800 (PST)
Received: by 10.143.8.14 with HTTP; Sat, 19 Nov 2011 14:14:10 -0800 (PST)
Date: Sat, 19 Nov 2011 17:14:10 -0500
Message-ID: <CAKpDea=XvoXUUKrnyWpJSU_1F3qhWVt3KF9E2fcnzFsuEvDOwg@mail.gmail.com>
From: Xin Jin <jxinpku@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Cannot get a shared page in domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5889706399892130943=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5889706399892130943==
Content-Type: multipart/alternative; boundary=bcaec5215bb3dc653704b21dc513

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

Hi, I cannot get a shared page in domU.

In a domU, I used the folloing code to grant a page to another domU.
share_mem = (share_mem_desp *) __get_free_page(GFP_KERNEL);
share_mem->gref = gnttab_grant_foreign_access(domid_remote,
virt_to_mfn(share_mem), 0);

In another domU, I used the folloing code to get the shared page.
share_vmarea = alloc_vm_area(PAGE_SIZE);
gnttab_set_map_op( &map_op, (unsigned long)share_vmarea->addr,
GNTMAP_host_map, gref, domid_remote );
HYPERVISOR_grant_table_op( GNTTABOP_map_grant_ref, &map_op, 1 );
(While using the exactly same code to get the shared page in dom0, it woks
all well. But it cannot work in domU.)
In domU, when I use insmod to insert the kernel module, it cause kernel
crash "Unable to handle kernel paging request at ffffc900000d800c".

I use Xen 4.1.2 and fedora 14 ( linux 3.1.0 both for dom0 and domU ).

Can anyone help me?

Thanks!

--Xin

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

<span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); font-fami=
ly: arial, sans-serif; font-size: 16px; background-color: rgba(255, 255, 25=
5, 0.917969); ">Hi, I cannot get a shared page in domU.</span><div style=3D=
"color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 16px; b=
ackground-color: rgba(255, 255, 255, 0.917969); ">
<br></div><div style=3D"color: rgb(34, 34, 34); font-family: arial, sans-se=
rif; font-size: 16px; background-color: rgba(255, 255, 255, 0.917969); ">In=
 a domU, I used the folloing code to grant a page to another domU.</div><di=
v style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif; backgrou=
nd-color: rgba(255, 255, 255, 0.917969); ">
<div style=3D"font-size: 16px; ">share_mem =3D (share_mem_desp *) __get_fre=
e_page(GFP_KERNEL);</div><div style=3D"font-size: 16px; ">share_mem-&gt;gre=
f =3D gnttab_grant_foreign_access(domid_remote, virt_to_mfn(share_mem), 0);=
</div>
<div style=3D"font-size: 16px; "><br></div><div style=3D"font-size: 16px; "=
>In another domU, I used the folloing code to get the shared page.</div><di=
v style=3D"font-size: 16px; "><div>share_vmarea =3D alloc_vm_area(PAGE_SIZE=
);</div>
<div>gnttab_set_map_op( &amp;map_op, (unsigned long)share_vmarea-&gt;addr, =
GNTMAP_host_map, gref, domid_remote );</div><div>HYPERVISOR_grant_table_op(=
 GNTTABOP_map_grant_ref, &amp;map_op, 1 );</div></div><div style=3D"font-si=
ze: 16px; ">
(While using the exactly same code to get the shared page in dom0, it woks =
all well. But it cannot work in domU.)</div><div><font class=3D"Apple-style=
-span" size=3D"4">In domU, when I use insmod to insert the kernel module, i=
t cause kernel crash &quot;Unable to handle kernel paging request at ffffc9=
00000d800c&quot;.</font></div>
<div style=3D"font-size: 16px; "><br></div><div style=3D"font-size: 16px; "=
>I use Xen 4.1.2 and fedora 14 ( linux 3.1.0 both for dom0 and domU ).</div=
><div style=3D"font-size: 16px; "><br></div><div style=3D"font-size: 16px; =
">Can anyone help me?</div>
<div style=3D"font-size: 16px; "><br></div><div style=3D"font-size: 16px; "=
>Thanks!</div></div><div><br></div>--Xin<br><br>

--bcaec5215bb3dc653704b21dc513--


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

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

--===============5889706399892130943==--


From xen-devel-bounces@lists.xensource.com Sat Nov 19 22:15:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 22:15:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRtBG-0007tq-Jm; Sat, 19 Nov 2011 22:14:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jxinpku@gmail.com>) id 1RRtBF-0007tl-Qc
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 22:14:38 +0000
X-Env-Sender: jxinpku@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321740851!4884841!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12618 invoked from network); 19 Nov 2011 22:14:12 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 22:14:12 -0000
Received: by yenm6 with SMTP id m6so19909yen.30
	for <xen-devel@lists.xensource.com>;
	Sat, 19 Nov 2011 14:14:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=BfWe7uiJG/Tiv9Zou6S7dGFOdCq3wUEeVZ98B+YWfEA=;
	b=hYg5cDOWinEVZxXIlzwo1qoqkYN6h24jfyi9BQe5kOG1swkC7Do+lIRfwvSATgrEgR
	b+2u4/dB9CLN7X/9SP5eAqbTnd+kZ/8Dcvc//qXMGK3cL8qFcFdsTIoCfy5iUN8A3UAS
	Vv2TDsk2LyOX+DOXWhXmCnI0Xe54O/ksr7Thw=
MIME-Version: 1.0
Received: by 10.68.22.228 with SMTP id h4mr16693466pbf.10.1321740850193; Sat,
	19 Nov 2011 14:14:10 -0800 (PST)
Received: by 10.143.8.14 with HTTP; Sat, 19 Nov 2011 14:14:10 -0800 (PST)
Date: Sat, 19 Nov 2011 17:14:10 -0500
Message-ID: <CAKpDea=XvoXUUKrnyWpJSU_1F3qhWVt3KF9E2fcnzFsuEvDOwg@mail.gmail.com>
From: Xin Jin <jxinpku@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Cannot get a shared page in domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5889706399892130943=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5889706399892130943==
Content-Type: multipart/alternative; boundary=bcaec5215bb3dc653704b21dc513

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

Hi, I cannot get a shared page in domU.

In a domU, I used the folloing code to grant a page to another domU.
share_mem = (share_mem_desp *) __get_free_page(GFP_KERNEL);
share_mem->gref = gnttab_grant_foreign_access(domid_remote,
virt_to_mfn(share_mem), 0);

In another domU, I used the folloing code to get the shared page.
share_vmarea = alloc_vm_area(PAGE_SIZE);
gnttab_set_map_op( &map_op, (unsigned long)share_vmarea->addr,
GNTMAP_host_map, gref, domid_remote );
HYPERVISOR_grant_table_op( GNTTABOP_map_grant_ref, &map_op, 1 );
(While using the exactly same code to get the shared page in dom0, it woks
all well. But it cannot work in domU.)
In domU, when I use insmod to insert the kernel module, it cause kernel
crash "Unable to handle kernel paging request at ffffc900000d800c".

I use Xen 4.1.2 and fedora 14 ( linux 3.1.0 both for dom0 and domU ).

Can anyone help me?

Thanks!

--Xin

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

<span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); font-fami=
ly: arial, sans-serif; font-size: 16px; background-color: rgba(255, 255, 25=
5, 0.917969); ">Hi, I cannot get a shared page in domU.</span><div style=3D=
"color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 16px; b=
ackground-color: rgba(255, 255, 255, 0.917969); ">
<br></div><div style=3D"color: rgb(34, 34, 34); font-family: arial, sans-se=
rif; font-size: 16px; background-color: rgba(255, 255, 255, 0.917969); ">In=
 a domU, I used the folloing code to grant a page to another domU.</div><di=
v style=3D"color: rgb(34, 34, 34); font-family: arial, sans-serif; backgrou=
nd-color: rgba(255, 255, 255, 0.917969); ">
<div style=3D"font-size: 16px; ">share_mem =3D (share_mem_desp *) __get_fre=
e_page(GFP_KERNEL);</div><div style=3D"font-size: 16px; ">share_mem-&gt;gre=
f =3D gnttab_grant_foreign_access(domid_remote, virt_to_mfn(share_mem), 0);=
</div>
<div style=3D"font-size: 16px; "><br></div><div style=3D"font-size: 16px; "=
>In another domU, I used the folloing code to get the shared page.</div><di=
v style=3D"font-size: 16px; "><div>share_vmarea =3D alloc_vm_area(PAGE_SIZE=
);</div>
<div>gnttab_set_map_op( &amp;map_op, (unsigned long)share_vmarea-&gt;addr, =
GNTMAP_host_map, gref, domid_remote );</div><div>HYPERVISOR_grant_table_op(=
 GNTTABOP_map_grant_ref, &amp;map_op, 1 );</div></div><div style=3D"font-si=
ze: 16px; ">
(While using the exactly same code to get the shared page in dom0, it woks =
all well. But it cannot work in domU.)</div><div><font class=3D"Apple-style=
-span" size=3D"4">In domU, when I use insmod to insert the kernel module, i=
t cause kernel crash &quot;Unable to handle kernel paging request at ffffc9=
00000d800c&quot;.</font></div>
<div style=3D"font-size: 16px; "><br></div><div style=3D"font-size: 16px; "=
>I use Xen 4.1.2 and fedora 14 ( linux 3.1.0 both for dom0 and domU ).</div=
><div style=3D"font-size: 16px; "><br></div><div style=3D"font-size: 16px; =
">Can anyone help me?</div>
<div style=3D"font-size: 16px; "><br></div><div style=3D"font-size: 16px; "=
>Thanks!</div></div><div><br></div>--Xin<br><br>

--bcaec5215bb3dc653704b21dc513--


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

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

--===============5889706399892130943==--


From xen-devel-bounces@lists.xensource.com Sat Nov 19 22:15:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 22:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRtBz-0007v9-2Q; Sat, 19 Nov 2011 22:15:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RRtBx-0007up-BA
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 22:15:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321740895!4937963!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31491 invoked from network); 19 Nov 2011 22:14:56 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 22:14:56 -0000
Received: by wwp14 with SMTP id 14so6210590wwp.24
	for <xen-devel@lists.xensource.com>;
	Sat, 19 Nov 2011 14:14:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=AEVEzRAIh0Yi7tvIZT1yTqpTMKN47ZdgRrewWAJhnaM=;
	b=RRSes52oE/tG+KS9ZHGkQ0GBTbGt4gp8L+0bdezgSTQNCiQwx8SF1J/orCxlRXXYwO
	zBqC3AtDMhBzYaQPG4E4rg0M2nbT+7M3ILdiKMZIoIJFAKdrPQVTCcRPVko5B9GU1d9+
	8asoU2rtgWzFnQ8LIRATwYe9tlYWfYhh9uc9A=
Received: by 10.180.4.167 with SMTP id l7mr8456120wil.51.1321740895576;
	Sat, 19 Nov 2011 14:14:55 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id ht10sm2599383wib.6.2011.11.19.14.14.45
	(version=SSLv3 cipher=OTHER); Sat, 19 Nov 2011 14:14:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Sat, 19 Nov 2011 22:14:44 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>,
	Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <CAEDDAD4.253D7%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
	XENMEM_add_to_physmap
Thread-Index: AcynCKQAunjvfpht0Emc0DNxzPcCiw==
In-Reply-To: <20111119215832.GA27626@aepfle.de>
Mime-version: 1.0
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com, tim@xen.org,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
 XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Wed, Nov 16, Jean Guyader wrote:
> 
>> Move the code for the XENMEM_add_to_physmap case into it's own
>> function (xenmem_add_to_physmap).
> 
> This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite
> failures.
> (XEN) Assertion '!in_atomic()' failed at softirq.c:61
> 
> preempt_count is like fffffc52 or fffffc00 in my testing.

Thanks, hopefully fixed by c/s 24167.

 -- keir

> Olaf



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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 22:15:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 22:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRtBz-0007v9-2Q; Sat, 19 Nov 2011 22:15:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RRtBx-0007up-BA
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 22:15:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321740895!4937963!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31491 invoked from network); 19 Nov 2011 22:14:56 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 22:14:56 -0000
Received: by wwp14 with SMTP id 14so6210590wwp.24
	for <xen-devel@lists.xensource.com>;
	Sat, 19 Nov 2011 14:14:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=AEVEzRAIh0Yi7tvIZT1yTqpTMKN47ZdgRrewWAJhnaM=;
	b=RRSes52oE/tG+KS9ZHGkQ0GBTbGt4gp8L+0bdezgSTQNCiQwx8SF1J/orCxlRXXYwO
	zBqC3AtDMhBzYaQPG4E4rg0M2nbT+7M3ILdiKMZIoIJFAKdrPQVTCcRPVko5B9GU1d9+
	8asoU2rtgWzFnQ8LIRATwYe9tlYWfYhh9uc9A=
Received: by 10.180.4.167 with SMTP id l7mr8456120wil.51.1321740895576;
	Sat, 19 Nov 2011 14:14:55 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id ht10sm2599383wib.6.2011.11.19.14.14.45
	(version=SSLv3 cipher=OTHER); Sat, 19 Nov 2011 14:14:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Sat, 19 Nov 2011 22:14:44 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>,
	Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <CAEDDAD4.253D7%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
	XENMEM_add_to_physmap
Thread-Index: AcynCKQAunjvfpht0Emc0DNxzPcCiw==
In-Reply-To: <20111119215832.GA27626@aepfle.de>
Mime-version: 1.0
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com, tim@xen.org,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
 XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Wed, Nov 16, Jean Guyader wrote:
> 
>> Move the code for the XENMEM_add_to_physmap case into it's own
>> function (xenmem_add_to_physmap).
> 
> This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite
> failures.
> (XEN) Assertion '!in_atomic()' failed at softirq.c:61
> 
> preempt_count is like fffffc52 or fffffc00 in my testing.

Thanks, hopefully fixed by c/s 24167.

 -- keir

> Olaf



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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 22:38:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 22:38:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRtY6-0008OY-D6; Sat, 19 Nov 2011 22:38:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RRtY5-0008OP-I4
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 22:38:13 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321742267!4207728!1
X-Originating-IP: [209.85.220.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13431 invoked from network); 19 Nov 2011 22:37:48 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 22:37:48 -0000
Received: by vcbfl15 with SMTP id fl15so1704030vcb.30
	for <xen-devel@lists.xensource.com>;
	Sat, 19 Nov 2011 14:37:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=BLx8sPcyjJnGF6VzvjsjnXVynRbJ3c7y6qah5A6QIEM=;
	b=x+0u3cj5Nn0AiSDQFBHkQ3h6tKKfmjVqoz8Z3vnDsxqauioqE/MERC6tUZSQxXubTi
	2Vr858zhhnN3bNNCEtOXSGPE/hcbj9WClXDeupTc5CsEfeYvIQ7pdyaBi448kUPp73Yi
	CkNjuvaxjH2wiNTEnp0VdHnJO9yCesFsg4w1E=
Received: by 10.52.95.164 with SMTP id dl4mr9366826vdb.72.1321742266618; Sat,
	19 Nov 2011 14:37:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Sat, 19 Nov 2011 14:37:24 -0800 (PST)
In-Reply-To: <CAEDDAD4.253D7%keir.xen@gmail.com>
References: <20111119215832.GA27626@aepfle.de>
	<CAEDDAD4.253D7%keir.xen@gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Sat, 19 Nov 2011 14:37:24 -0800
Message-ID: <CAEBdQ91YJ0Qhgbn5vk67yo5-AOCsvcJG4h8Ki7eyBk-svOFvpw@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	allen.m.kay@intel.com, tim@xen.org,
	Jean Guyader <jean.guyader@eu.citrix.com>, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
	XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 19 November 2011 14:14, Keir Fraser <keir.xen@gmail.com> wrote:
> On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de> wrote:
>
>> On Wed, Nov 16, Jean Guyader wrote:
>>
>>> Move the code for the XENMEM_add_to_physmap case into it's own
>>> function (xenmem_add_to_physmap).
>>
>> This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite
>> failures.
>> (XEN) Assertion '!in_atomic()' failed at softirq.c:61
>>
>> preempt_count is like fffffc52 or fffffc00 in my testing.
>
> Thanks, hopefully fixed by c/s 24167.
>

Thanks, sorry about that.

Jean

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 22:38:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 22:38:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRtY6-0008OY-D6; Sat, 19 Nov 2011 22:38:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RRtY5-0008OP-I4
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 22:38:13 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321742267!4207728!1
X-Originating-IP: [209.85.220.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13431 invoked from network); 19 Nov 2011 22:37:48 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 22:37:48 -0000
Received: by vcbfl15 with SMTP id fl15so1704030vcb.30
	for <xen-devel@lists.xensource.com>;
	Sat, 19 Nov 2011 14:37:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=BLx8sPcyjJnGF6VzvjsjnXVynRbJ3c7y6qah5A6QIEM=;
	b=x+0u3cj5Nn0AiSDQFBHkQ3h6tKKfmjVqoz8Z3vnDsxqauioqE/MERC6tUZSQxXubTi
	2Vr858zhhnN3bNNCEtOXSGPE/hcbj9WClXDeupTc5CsEfeYvIQ7pdyaBi448kUPp73Yi
	CkNjuvaxjH2wiNTEnp0VdHnJO9yCesFsg4w1E=
Received: by 10.52.95.164 with SMTP id dl4mr9366826vdb.72.1321742266618; Sat,
	19 Nov 2011 14:37:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Sat, 19 Nov 2011 14:37:24 -0800 (PST)
In-Reply-To: <CAEDDAD4.253D7%keir.xen@gmail.com>
References: <20111119215832.GA27626@aepfle.de>
	<CAEDDAD4.253D7%keir.xen@gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Sat, 19 Nov 2011 14:37:24 -0800
Message-ID: <CAEBdQ91YJ0Qhgbn5vk67yo5-AOCsvcJG4h8Ki7eyBk-svOFvpw@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	allen.m.kay@intel.com, tim@xen.org,
	Jean Guyader <jean.guyader@eu.citrix.com>, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
	XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 19 November 2011 14:14, Keir Fraser <keir.xen@gmail.com> wrote:
> On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de> wrote:
>
>> On Wed, Nov 16, Jean Guyader wrote:
>>
>>> Move the code for the XENMEM_add_to_physmap case into it's own
>>> function (xenmem_add_to_physmap).
>>
>> This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite
>> failures.
>> (XEN) Assertion '!in_atomic()' failed at softirq.c:61
>>
>> preempt_count is like fffffc52 or fffffc00 in my testing.
>
> Thanks, hopefully fixed by c/s 24167.
>

Thanks, sorry about that.

Jean

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 23:03:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 23:03:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRtwA-0000Hl-1R; Sat, 19 Nov 2011 23:03:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRtw8-0000Hg-5H
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 23:03:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321743758!3337717!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17568 invoked from network); 19 Nov 2011 23:02:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 23:02:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,540,1315180800"; 
   d="scan'208";a="9024005"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Nov 2011 23:02:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 19 Nov 2011 23:02:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRtvh-0000BN-2J;
	Sat, 19 Nov 2011 23:02:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRtvg-0004MN-UO;
	Sat, 19 Nov 2011 23:02:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9878-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 19 Nov 2011 23:02:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9878: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install               fail pass in 9872
 test-amd64-i386-xl-credit2   10 guest-saverestore    fail in 9872 pass in 9878

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sat Nov 19 23:03:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 19 Nov 2011 23:03:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRtwA-0000Hl-1R; Sat, 19 Nov 2011 23:03:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRtw8-0000Hg-5H
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 23:03:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321743758!3337717!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17568 invoked from network); 19 Nov 2011 23:02:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 23:02:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,540,1315180800"; 
   d="scan'208";a="9024005"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Nov 2011 23:02:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 19 Nov 2011 23:02:37 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRtvh-0000BN-2J;
	Sat, 19 Nov 2011 23:02:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRtvg-0004MN-UO;
	Sat, 19 Nov 2011 23:02:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9878-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 19 Nov 2011 23:02:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9878: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install               fail pass in 9872
 test-amd64-i386-xl-credit2   10 guest-saverestore    fail in 9872 pass in 9878

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  fe3e9d0c123c
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24166:fe3e9d0c123c
tag:         tip
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 00:41:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 00:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRvSE-00010D-K9; Sun, 20 Nov 2011 00:40:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1RRvSD-000106-1h
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 00:40:17 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321749590!2243578!1
X-Originating-IP: [98.139.44.150]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12668 invoked from network); 20 Nov 2011 00:39:51 -0000
Received: from nm23.access.bullet.mail.sp2.yahoo.com (HELO
	nm23.access.bullet.mail.sp2.yahoo.com) (98.139.44.150)
	by server-15.tower-174.messagelabs.com with SMTP;
	20 Nov 2011 00:39:51 -0000
Received: from [98.139.44.106] by nm23.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 20 Nov 2011 00:39:50 -0000
Received: from [98.139.44.73] by tm11.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 20 Nov 2011 00:39:50 -0000
Received: from [127.0.0.1] by omp1010.access.mail.sp2.yahoo.com with NNFMP;
	20 Nov 2011 00:39:50 -0000
X-Yahoo-Newman-Id: 389909.52577.bm@omp1010.access.mail.sp2.yahoo.com
Received: (qmail 36529 invoked from network); 20 Nov 2011 00:39:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1321749589; bh=CTPaipimsDjOz/6tX/oSjUU8X6vCu65H9ecgdWr+mqc=;
	h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Transfer-Encoding:Content-Type;
	b=D64v/u+PzBM5IoCzWHtn/xfi+WmFga04GmzhEdF2Nurd/1ieSxBt9v9bMZlGd+dYIryaJnX5w/QYxSwOX3sxQ+pSK+zE6oVQLL1ti4FZxKGyCw0DXTAPBgdoVUZGaAwAqdgOvXH2+wYzcq29+pEESRwTbKxDo+U646NOPKcoaBI=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: UWgu0sIVM1nNmwuNG3Plr8Di6O0tEQ9zYiJEZP4fpsrxhsH
	P2OyP9uVOMNRunNAbbBr03is220hXXN0GxFLLeuAzXQwQM97HPFvpRKAdzoZ
	cSAmkBFYzMyQLn1a9df577QT_Tbgrozn9JlsunwVl8N7IjbqI.FWHzKgTh4x
	7AlnOOvOW3uKW6pr1HY0JYnaXcZJqp_qcOvL__2zFaFsOvSAicgr2ero.SJh
	KxeFnzK7GfcZdiy3tfZ8hDwQQnebVsljDfKFHN.dtKJFnf0m6mds.C_aiw1e
	IS6OxXCNGZVp3OZWlsZZ89KfxDwr2VnQBOpEeFXJrwlLWO18bAwN_WHHLEzD
	Ve_oFerLVMpWXWrNanCe_Mh8p_4IZ57BeOBiOsqVePWiTBKIQ.QDmhz5ijpf
	wPq3WZUY9PnCK5Pb79mtclRMySQ_5_O2fsPJu
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@72.145.175.45 with plain)
	by smtp105.sbc.mail.ne1.yahoo.com with SMTP;
	19 Nov 2011 16:39:49 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xensource.com
Date: Sat, 19 Nov 2011 19:39:41 -0500
Message-ID: <1934026.TeqnqBJFlp@dell4550>
User-Agent: KMail/4.7.3 (Linux/2.6.37.6-0.9-default; KDE/4.7.3; i686; ; )
MIME-Version: 1.0
Subject: [Xen-devel] cirrusfb disabled in latest fedora rawhide 3.2.0-rc2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hey guys - someone might want to talk to fedora about this. Between 
3.2.0-0.rc2.git3.1.fc17 & 3.2.0-0.rc2.git1.1.fc17, fedora's changelog says:

< * Fri Nov 18 2011 Josh Boyer <jwboyer@redhat.com> 3.2.0-0.rc2.git3.1
< - Linux 3.2-rc2-git3
< - Disable various fb and drm drivers that don't have xorg equivalents per 
ajax
< - Other minor config cleanup

resulting in:

root@insp6400 11/19/11  7:19PM:/boot/grub
[504] > grep CIRR ../config-3.2.0-*
../config-3.2.0-0.rc2.git1.1.fc17.x86_64:CONFIG_FB_CIRRUS=m
../config-3.2.0-0.rc2.git1.1.fc17.x86_64:CONFIG_SND_HDA_CODEC_CIRRUS=y
../config-3.2.0-0.rc2.git3.1.fc17.x86_64:# CONFIG_FB_CIRRUS is not set
../config-3.2.0-0.rc2.git3.1.fc17.x86_64:CONFIG_SND_HDA_CODEC_CIRRUS=y

The funny thing is, xorg does have an "equivalent" cirrus driver to match the 
kernel driver.


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 00:41:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 00:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRvSE-00010D-K9; Sun, 20 Nov 2011 00:40:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1RRvSD-000106-1h
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 00:40:17 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321749590!2243578!1
X-Originating-IP: [98.139.44.150]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12668 invoked from network); 20 Nov 2011 00:39:51 -0000
Received: from nm23.access.bullet.mail.sp2.yahoo.com (HELO
	nm23.access.bullet.mail.sp2.yahoo.com) (98.139.44.150)
	by server-15.tower-174.messagelabs.com with SMTP;
	20 Nov 2011 00:39:51 -0000
Received: from [98.139.44.106] by nm23.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 20 Nov 2011 00:39:50 -0000
Received: from [98.139.44.73] by tm11.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 20 Nov 2011 00:39:50 -0000
Received: from [127.0.0.1] by omp1010.access.mail.sp2.yahoo.com with NNFMP;
	20 Nov 2011 00:39:50 -0000
X-Yahoo-Newman-Id: 389909.52577.bm@omp1010.access.mail.sp2.yahoo.com
Received: (qmail 36529 invoked from network); 20 Nov 2011 00:39:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1321749589; bh=CTPaipimsDjOz/6tX/oSjUU8X6vCu65H9ecgdWr+mqc=;
	h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Transfer-Encoding:Content-Type;
	b=D64v/u+PzBM5IoCzWHtn/xfi+WmFga04GmzhEdF2Nurd/1ieSxBt9v9bMZlGd+dYIryaJnX5w/QYxSwOX3sxQ+pSK+zE6oVQLL1ti4FZxKGyCw0DXTAPBgdoVUZGaAwAqdgOvXH2+wYzcq29+pEESRwTbKxDo+U646NOPKcoaBI=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: UWgu0sIVM1nNmwuNG3Plr8Di6O0tEQ9zYiJEZP4fpsrxhsH
	P2OyP9uVOMNRunNAbbBr03is220hXXN0GxFLLeuAzXQwQM97HPFvpRKAdzoZ
	cSAmkBFYzMyQLn1a9df577QT_Tbgrozn9JlsunwVl8N7IjbqI.FWHzKgTh4x
	7AlnOOvOW3uKW6pr1HY0JYnaXcZJqp_qcOvL__2zFaFsOvSAicgr2ero.SJh
	KxeFnzK7GfcZdiy3tfZ8hDwQQnebVsljDfKFHN.dtKJFnf0m6mds.C_aiw1e
	IS6OxXCNGZVp3OZWlsZZ89KfxDwr2VnQBOpEeFXJrwlLWO18bAwN_WHHLEzD
	Ve_oFerLVMpWXWrNanCe_Mh8p_4IZ57BeOBiOsqVePWiTBKIQ.QDmhz5ijpf
	wPq3WZUY9PnCK5Pb79mtclRMySQ_5_O2fsPJu
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@72.145.175.45 with plain)
	by smtp105.sbc.mail.ne1.yahoo.com with SMTP;
	19 Nov 2011 16:39:49 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xensource.com
Date: Sat, 19 Nov 2011 19:39:41 -0500
Message-ID: <1934026.TeqnqBJFlp@dell4550>
User-Agent: KMail/4.7.3 (Linux/2.6.37.6-0.9-default; KDE/4.7.3; i686; ; )
MIME-Version: 1.0
Subject: [Xen-devel] cirrusfb disabled in latest fedora rawhide 3.2.0-rc2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hey guys - someone might want to talk to fedora about this. Between 
3.2.0-0.rc2.git3.1.fc17 & 3.2.0-0.rc2.git1.1.fc17, fedora's changelog says:

< * Fri Nov 18 2011 Josh Boyer <jwboyer@redhat.com> 3.2.0-0.rc2.git3.1
< - Linux 3.2-rc2-git3
< - Disable various fb and drm drivers that don't have xorg equivalents per 
ajax
< - Other minor config cleanup

resulting in:

root@insp6400 11/19/11  7:19PM:/boot/grub
[504] > grep CIRR ../config-3.2.0-*
../config-3.2.0-0.rc2.git1.1.fc17.x86_64:CONFIG_FB_CIRRUS=m
../config-3.2.0-0.rc2.git1.1.fc17.x86_64:CONFIG_SND_HDA_CODEC_CIRRUS=y
../config-3.2.0-0.rc2.git3.1.fc17.x86_64:# CONFIG_FB_CIRRUS is not set
../config-3.2.0-0.rc2.git3.1.fc17.x86_64:CONFIG_SND_HDA_CODEC_CIRRUS=y

The funny thing is, xorg does have an "equivalent" cirrus driver to match the 
kernel driver.


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 01:00:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 01:00:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRvlP-0001IL-AJ; Sun, 20 Nov 2011 01:00:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvlN-0001IG-Iq
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:00:05 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321750779!4809156!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18318 invoked from network); 20 Nov 2011 00:59:39 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-9.tower-21.messagelabs.com with SMTP;
	20 Nov 2011 00:59:39 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvkw-0002w0-L7
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 00:59:38 +0000
Received: from mail-yx0-f176.google.com ([209.85.213.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvkw-0002vq-As for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Sun, 20 Nov 2011 00:59:38 +0000
Received: by yenq10 with SMTP id q10so4323853yen.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Sat, 19 Nov 2011 16:59:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=svTDf8l0/Y+Fwe0+6DyqnGjs5Qk6wYASLxoCq1Khwfg=;
	b=IulSDhKLv8wFCEISnhidYL4lFWOpmAELlkklVuiXcm44oODrC5yMvBozupUMhmKJd4
	OIemEnTJLledARPIH8a3kk3eRleQFcK85FmoXOllY2zQJzx5k1EGz5PPB0Vi47qToZ7p
	Dme0kZP20/IimHuGJufYrgGuAhVWQ64RcFPW0=
MIME-Version: 1.0
Received: by 10.182.188.34 with SMTP id fx2mr1926169obc.31.1321750777840; Sat,
	19 Nov 2011 16:59:37 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Sat, 19 Nov 2011 16:59:37 -0800 (PST)
Date: Sat, 19 Nov 2011 16:59:37 -0800
Message-ID: <CACm5R6Ru1z+-5NshOkRWE4dduvrEpG9NFfX0QgyP2ffpvX-WjQ@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Hello
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've just begun contributing to the Xen wiki, http://wiki.xen.org/wiki/Main_Page
I've provided my relevant background on my User: page,
http://wiki.xen.org/wiki/User:GarveyPatrickD
I'll try to maintain that, but don't count on it.
Most of what I can do at the moment is catch the typos, but I hope to
grow my knowledge such that I can contribute knowledgeable information
and quality code.


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 01:00:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 01:00:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRvlP-0001IL-AJ; Sun, 20 Nov 2011 01:00:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvlN-0001IG-Iq
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:00:05 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321750779!4809156!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18318 invoked from network); 20 Nov 2011 00:59:39 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-9.tower-21.messagelabs.com with SMTP;
	20 Nov 2011 00:59:39 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvkw-0002w0-L7
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 00:59:38 +0000
Received: from mail-yx0-f176.google.com ([209.85.213.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvkw-0002vq-As for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Sun, 20 Nov 2011 00:59:38 +0000
Received: by yenq10 with SMTP id q10so4323853yen.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Sat, 19 Nov 2011 16:59:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=svTDf8l0/Y+Fwe0+6DyqnGjs5Qk6wYASLxoCq1Khwfg=;
	b=IulSDhKLv8wFCEISnhidYL4lFWOpmAELlkklVuiXcm44oODrC5yMvBozupUMhmKJd4
	OIemEnTJLledARPIH8a3kk3eRleQFcK85FmoXOllY2zQJzx5k1EGz5PPB0Vi47qToZ7p
	Dme0kZP20/IimHuGJufYrgGuAhVWQ64RcFPW0=
MIME-Version: 1.0
Received: by 10.182.188.34 with SMTP id fx2mr1926169obc.31.1321750777840; Sat,
	19 Nov 2011 16:59:37 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Sat, 19 Nov 2011 16:59:37 -0800 (PST)
Date: Sat, 19 Nov 2011 16:59:37 -0800
Message-ID: <CACm5R6Ru1z+-5NshOkRWE4dduvrEpG9NFfX0QgyP2ffpvX-WjQ@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Hello
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've just begun contributing to the Xen wiki, http://wiki.xen.org/wiki/Main_Page
I've provided my relevant background on my User: page,
http://wiki.xen.org/wiki/User:GarveyPatrickD
I'll try to maintain that, but don't count on it.
Most of what I can do at the moment is catch the typos, but I hope to
grow my knowledge such that I can contribute knowledgeable information
and quality code.


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 01:03:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 01:03:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRvoT-0001OE-VZ; Sun, 20 Nov 2011 01:03:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvoS-0001O7-Du
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:03:16 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-4.tower-27.messagelabs.com!1321750947!49145090!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11989 invoked from network); 20 Nov 2011 01:02:27 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-4.tower-27.messagelabs.com with SMTP;
	20 Nov 2011 01:02:27 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvo6-0003Ny-SB
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:02:54 +0000
Received: from mail-gy0-f176.google.com ([209.85.160.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvo6-0003Nk-LH for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Sun, 20 Nov 2011 01:02:54 +0000
Received: by ghbg2 with SMTP id g2so2210146ghb.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Sat, 19 Nov 2011 17:02:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=K9YUrr4GHE1alK7d6fRhMLQAjAxvpcQ/Q+EyS4ZzJJc=;
	b=xVG70NyYuREl1IrGuss/0k9LgQn7sjVeIYc+N+LXtVIlfLZu92Wj293JnWZbQk+CLx
	nuaX4zvNxlv27l3Y81SR0uwTDvrmUeLUG9su7e3K1Ha1sVUcE1SPP2r3cLy/ywNGC0Tj
	QlGcD0wAbTMHMoEBmnC32QfzqGEuIY95kpoo0=
MIME-Version: 1.0
Received: by 10.182.92.97 with SMTP id cl1mr1911468obb.21.1321750972797; Sat,
	19 Nov 2011 17:02:52 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Sat, 19 Nov 2011 17:02:52 -0800 (PST)
Date: Sat, 19 Nov 2011 17:02:52 -0800
Message-ID: <CACm5R6T-=sKMAfMoHBZ65KD0o+-ODrHd_mNC0tZ21+eBxHgsiw@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] HTML in wikitext
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

According to https://secure.wikimedia.org/wikipedia/en/wiki/Help:HTML_in_wikitext#Permitted_HTML
<abbr title="abbreviation">abbr.</abbr> should be parsed as HTML by
the wiki server.

According to my experiment,
http://wiki.xen.org/wiki/User:GarveyPatrickD/Abbreviations
the Xen wiki doesn't seem to have this feature enabled.


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 01:03:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 01:03:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRvoT-0001OE-VZ; Sun, 20 Nov 2011 01:03:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvoS-0001O7-Du
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:03:16 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-4.tower-27.messagelabs.com!1321750947!49145090!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11989 invoked from network); 20 Nov 2011 01:02:27 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-4.tower-27.messagelabs.com with SMTP;
	20 Nov 2011 01:02:27 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvo6-0003Ny-SB
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:02:54 +0000
Received: from mail-gy0-f176.google.com ([209.85.160.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvo6-0003Nk-LH for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Sun, 20 Nov 2011 01:02:54 +0000
Received: by ghbg2 with SMTP id g2so2210146ghb.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Sat, 19 Nov 2011 17:02:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=K9YUrr4GHE1alK7d6fRhMLQAjAxvpcQ/Q+EyS4ZzJJc=;
	b=xVG70NyYuREl1IrGuss/0k9LgQn7sjVeIYc+N+LXtVIlfLZu92Wj293JnWZbQk+CLx
	nuaX4zvNxlv27l3Y81SR0uwTDvrmUeLUG9su7e3K1Ha1sVUcE1SPP2r3cLy/ywNGC0Tj
	QlGcD0wAbTMHMoEBmnC32QfzqGEuIY95kpoo0=
MIME-Version: 1.0
Received: by 10.182.92.97 with SMTP id cl1mr1911468obb.21.1321750972797; Sat,
	19 Nov 2011 17:02:52 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Sat, 19 Nov 2011 17:02:52 -0800 (PST)
Date: Sat, 19 Nov 2011 17:02:52 -0800
Message-ID: <CACm5R6T-=sKMAfMoHBZ65KD0o+-ODrHd_mNC0tZ21+eBxHgsiw@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] HTML in wikitext
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

According to https://secure.wikimedia.org/wikipedia/en/wiki/Help:HTML_in_wikitext#Permitted_HTML
<abbr title="abbreviation">abbr.</abbr> should be parsed as HTML by
the wiki server.

According to my experiment,
http://wiki.xen.org/wiki/User:GarveyPatrickD/Abbreviations
the Xen wiki doesn't seem to have this feature enabled.


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 01:10:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 01:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRvvA-0001bM-W3; Sun, 20 Nov 2011 01:10:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvv9-0001bA-Ap
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:10:11 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-6.tower-21.messagelabs.com!1321751385!4927717!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14392 invoked from network); 20 Nov 2011 01:09:45 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-6.tower-21.messagelabs.com with SMTP;
	20 Nov 2011 01:09:45 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvuj-0007cR-3l
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:09:45 +0000
Received: from mail-gx0-f176.google.com ([209.85.161.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvui-0007cL-Ta for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Sun, 20 Nov 2011 01:09:44 +0000
Received: by ggnp1 with SMTP id p1so4330576ggn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Sat, 19 Nov 2011 17:09:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=aqrVa8vo6ZuOTUjqcKppM++MREe4aOKue4q3J0J+NNo=;
	b=uePI97hUzC+HM64m14F4dZmvRVLIr3MkFFKiKl9JSwiKXmtQUobs9oJu16dxzCBJkz
	8nA58hovbtZmtGHKchkWsV6Tr9IrkvJkvKi+tldX6QxOWxa1rR/Ew4mGMcLj2sBRWVHb
	mxLCZogNsj6BhvQzVAtujg6eAT1iPkUEw/cRk=
MIME-Version: 1.0
Received: by 10.182.217.73 with SMTP id ow9mr1926579obc.11.1321751384418; Sat,
	19 Nov 2011 17:09:44 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Sat, 19 Nov 2011 17:09:44 -0800 (PST)
Date: Sat, 19 Nov 2011 17:09:44 -0800
Message-ID: <CACm5R6SkCiQC7153x-B6=kd96TKHC8uLvjY5gm8_QyefJ4LX+Q@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] wiki.xen.org Page structure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Browsing through wiki.xen.org, I see several pages formatted like
http://wiki.xen.org/wiki/AskingXenDevelQuestions
It has one first level header and several second level headers.  The
first level header also seems more appropriate as the page title,
especially when it is a paraphrase of the page file name.  It seems to
me, "How to get your question answered on xen-devel" is better English
than "AskingXenDevelQuestions".

May I move such pages to their first header as a file name and
eliminate the first level of headers on such pages?  Maybe we can
follow that with the elimination of the original file that will have
become a mere redirect with the move?


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 01:10:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 01:10:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRvvA-0001bM-W3; Sun, 20 Nov 2011 01:10:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvv9-0001bA-Ap
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:10:11 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-6.tower-21.messagelabs.com!1321751385!4927717!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14392 invoked from network); 20 Nov 2011 01:09:45 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-6.tower-21.messagelabs.com with SMTP;
	20 Nov 2011 01:09:45 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvuj-0007cR-3l
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:09:45 +0000
Received: from mail-gx0-f176.google.com ([209.85.161.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvui-0007cL-Ta for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Sun, 20 Nov 2011 01:09:44 +0000
Received: by ggnp1 with SMTP id p1so4330576ggn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Sat, 19 Nov 2011 17:09:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=aqrVa8vo6ZuOTUjqcKppM++MREe4aOKue4q3J0J+NNo=;
	b=uePI97hUzC+HM64m14F4dZmvRVLIr3MkFFKiKl9JSwiKXmtQUobs9oJu16dxzCBJkz
	8nA58hovbtZmtGHKchkWsV6Tr9IrkvJkvKi+tldX6QxOWxa1rR/Ew4mGMcLj2sBRWVHb
	mxLCZogNsj6BhvQzVAtujg6eAT1iPkUEw/cRk=
MIME-Version: 1.0
Received: by 10.182.217.73 with SMTP id ow9mr1926579obc.11.1321751384418; Sat,
	19 Nov 2011 17:09:44 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Sat, 19 Nov 2011 17:09:44 -0800 (PST)
Date: Sat, 19 Nov 2011 17:09:44 -0800
Message-ID: <CACm5R6SkCiQC7153x-B6=kd96TKHC8uLvjY5gm8_QyefJ4LX+Q@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] wiki.xen.org Page structure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Browsing through wiki.xen.org, I see several pages formatted like
http://wiki.xen.org/wiki/AskingXenDevelQuestions
It has one first level header and several second level headers.  The
first level header also seems more appropriate as the page title,
especially when it is a paraphrase of the page file name.  It seems to
me, "How to get your question answered on xen-devel" is better English
than "AskingXenDevelQuestions".

May I move such pages to their first header as a file name and
eliminate the first level of headers on such pages?  Maybe we can
follow that with the elimination of the original file that will have
become a mere redirect with the move?


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 01:12:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 01:12:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRvwr-0001gH-Hs; Sun, 20 Nov 2011 01:11:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvwp-0001gB-TY
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:11:56 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-9.tower-27.messagelabs.com!1321751467!53430376!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11230 invoked from network); 20 Nov 2011 01:11:07 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-9.tower-27.messagelabs.com with SMTP;
	20 Nov 2011 01:11:07 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvwU-0007pT-H0
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:11:34 +0000
Received: from mail-gy0-f176.google.com ([209.85.160.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvwU-0007pO-Ah for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Sun, 20 Nov 2011 01:11:34 +0000
Received: by ghbg2 with SMTP id g2so2214380ghb.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Sat, 19 Nov 2011 17:11:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=AUWFGaJKxA4FuHrgBpIS7vP8aTSnY8jWReEoNzkT3nY=;
	b=i3GYq7ySu3r17wLr896ylrhlwarTIr2WJsWbtHfEYqMW8bI4UQzVeaLDtZw16tYca4
	l5fxTBY25KIQGhONQPhcq0FTzMsLTgpjKdQhRA4GKoOeO10VEt2fdNFHqFqh97E/l/UE
	qfEMmer2mQfQO2cG3jgvcHq8ud1osS60hjMZs=
MIME-Version: 1.0
Received: by 10.182.92.97 with SMTP id cl1mr1915258obb.21.1321751493751; Sat,
	19 Nov 2011 17:11:33 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Sat, 19 Nov 2011 17:11:33 -0800 (PST)
Date: Sat, 19 Nov 2011 17:11:33 -0800
Message-ID: <CACm5R6TEeA1AiRwZ9xRvobSkKLzeOLbFfai6vibakpDOXQBZUw@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_module
contains a link to the University of Cambridge Computer Laboratory
copy of the Xen User Manual
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03231300000000000000
that responds, "Forbidden
You don't have permission to access
/research/srg/netos/xen/readmes/user/user.html on this server."

Does Xen.org have the right to copy the Xen User Manual onto its own server?


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 01:12:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 01:12:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRvwr-0001gH-Hs; Sun, 20 Nov 2011 01:11:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvwp-0001gB-TY
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:11:56 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-9.tower-27.messagelabs.com!1321751467!53430376!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11230 invoked from network); 20 Nov 2011 01:11:07 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-9.tower-27.messagelabs.com with SMTP;
	20 Nov 2011 01:11:07 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvwU-0007pT-H0
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 01:11:34 +0000
Received: from mail-gy0-f176.google.com ([209.85.160.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRvwU-0007pO-Ah for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Sun, 20 Nov 2011 01:11:34 +0000
Received: by ghbg2 with SMTP id g2so2214380ghb.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Sat, 19 Nov 2011 17:11:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=AUWFGaJKxA4FuHrgBpIS7vP8aTSnY8jWReEoNzkT3nY=;
	b=i3GYq7ySu3r17wLr896ylrhlwarTIr2WJsWbtHfEYqMW8bI4UQzVeaLDtZw16tYca4
	l5fxTBY25KIQGhONQPhcq0FTzMsLTgpjKdQhRA4GKoOeO10VEt2fdNFHqFqh97E/l/UE
	qfEMmer2mQfQO2cG3jgvcHq8ud1osS60hjMZs=
MIME-Version: 1.0
Received: by 10.182.92.97 with SMTP id cl1mr1915258obb.21.1321751493751; Sat,
	19 Nov 2011 17:11:33 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Sat, 19 Nov 2011 17:11:33 -0800 (PST)
Date: Sat, 19 Nov 2011 17:11:33 -0800
Message-ID: <CACm5R6TEeA1AiRwZ9xRvobSkKLzeOLbFfai6vibakpDOXQBZUw@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_module
contains a link to the University of Cambridge Computer Laboratory
copy of the Xen User Manual
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03231300000000000000
that responds, "Forbidden
You don't have permission to access
/research/srg/netos/xen/readmes/user/user.html on this server."

Does Xen.org have the right to copy the Xen User Manual onto its own server?


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 04:30:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 04:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRz1j-0004fD-7y; Sun, 20 Nov 2011 04:29:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRz1h-0004f8-Me
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 04:29:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321763323!3820797!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20190 invoked from network); 20 Nov 2011 04:28:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 04:28:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,541,1315180800"; 
   d="scan'208";a="9024726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Nov 2011 04:28:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 20 Nov 2011 04:28:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRz1G-000204-Lo;
	Sun, 20 Nov 2011 04:28:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRz1G-0001EG-FF;
	Sun, 20 Nov 2011 04:28:42 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9884-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 20 Nov 2011 04:28:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9884: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail    like 9855
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 04:30:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 04:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RRz1j-0004fD-7y; Sun, 20 Nov 2011 04:29:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RRz1h-0004f8-Me
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 04:29:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321763323!3820797!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20190 invoked from network); 20 Nov 2011 04:28:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 04:28:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,541,1315180800"; 
   d="scan'208";a="9024726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Nov 2011 04:28:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 20 Nov 2011 04:28:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RRz1G-000204-Lo;
	Sun, 20 Nov 2011 04:28:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RRz1G-0001EG-FF;
	Sun, 20 Nov 2011 04:28:42 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9884-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 20 Nov 2011 04:28:42 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9884: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail    like 9855
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 09:13:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 09:13:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RS3Rl-0006jV-VX; Sun, 20 Nov 2011 09:12:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RS3Rk-0006jQ-I9
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 09:12:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321780314!2261193!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19056 invoked from network); 20 Nov 2011 09:11:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 09:11:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,542,1315180800"; 
   d="scan'208";a="9025845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Nov 2011 09:11:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 20 Nov 2011 09:11:53 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RS3RJ-0003iC-Le;
	Sun, 20 Nov 2011 09:11:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RS3RI-00085E-PM;
	Sun, 20 Nov 2011 09:11:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9893-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 20 Nov 2011 09:11:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9893: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 09:13:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 09:13:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RS3Rl-0006jV-VX; Sun, 20 Nov 2011 09:12:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RS3Rk-0006jQ-I9
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 09:12:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321780314!2261193!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19056 invoked from network); 20 Nov 2011 09:11:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 09:11:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,542,1315180800"; 
   d="scan'208";a="9025845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Nov 2011 09:11:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 20 Nov 2011 09:11:53 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RS3RJ-0003iC-Le;
	Sun, 20 Nov 2011 09:11:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RS3RI-00085E-PM;
	Sun, 20 Nov 2011 09:11:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9893-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 20 Nov 2011 09:11:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9893: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 13:26:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 13:26:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RS7P2-0000AQ-Mh; Sun, 20 Nov 2011 13:25:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RS7P1-0000AL-4l
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 13:25:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321795520!4255296!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 724 invoked from network); 20 Nov 2011 13:25:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 13:25:20 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321795520; l=843;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=l9vD+yA22/BkejrtU7efdFZna7k=;
	b=KiHFEw509Mdb/sU4KUPojxt20Cwx6ytFp4uU7AGf24cFX9s7Hmo12DScKfSo0Ed+H2c
	FaAOhW3UPvb5NJmi6ce03tuIuOLnTLU0ndd//mptAnURMdBOwLJvAAuem7wdIJ8xxtbE1
	HQZbREcxoGPqPk8X5B0ZbBTvb/Opxq211ps=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo21) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 601cc0nAKCjVvq ;
	Sun, 20 Nov 2011 14:25:12 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3DF5518637; Sun, 20 Nov 2011 14:25:12 +0100 (CET)
Date: Sun, 20 Nov 2011 14:25:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111120132512.GA31844@aepfle.de>
References: <20111119215832.GA27626@aepfle.de>
	<CAEDDAD4.253D7%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEDDAD4.253D7%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com, tim@xen.org,
	Jean Guyader <jean.guyader@eu.citrix.com>, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
 XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Nov 19, Keir Fraser wrote:

> On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> > On Wed, Nov 16, Jean Guyader wrote:
> > 
> >> Move the code for the XENMEM_add_to_physmap case into it's own
> >> function (xenmem_add_to_physmap).
> > 
> > This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite
> > failures.
> > (XEN) Assertion '!in_atomic()' failed at softirq.c:61
> > 
> > preempt_count is like fffffc52 or fffffc00 in my testing.
> 
> Thanks, hopefully fixed by c/s 24167.

Yes, the ASSERT does not trigger anymore.

The remaining issue is this:

Nov 20 06:21:11.744519 (XEN) hvm.c:2312:d1 guest attempted write to read-only memory page. gfn=0xc0, mfn=0x201979

See
http://www.chiark.greenend.org.uk/~xensrcts/logs/9893/test-amd64-i386-rhel6hvm-amd/serial-potato-beetle.log

Olaf

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 13:26:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 13:26:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RS7P2-0000AQ-Mh; Sun, 20 Nov 2011 13:25:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RS7P1-0000AL-4l
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 13:25:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321795520!4255296!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 724 invoked from network); 20 Nov 2011 13:25:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 13:25:20 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321795520; l=843;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=l9vD+yA22/BkejrtU7efdFZna7k=;
	b=KiHFEw509Mdb/sU4KUPojxt20Cwx6ytFp4uU7AGf24cFX9s7Hmo12DScKfSo0Ed+H2c
	FaAOhW3UPvb5NJmi6ce03tuIuOLnTLU0ndd//mptAnURMdBOwLJvAAuem7wdIJ8xxtbE1
	HQZbREcxoGPqPk8X5B0ZbBTvb/Opxq211ps=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo21) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 601cc0nAKCjVvq ;
	Sun, 20 Nov 2011 14:25:12 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3DF5518637; Sun, 20 Nov 2011 14:25:12 +0100 (CET)
Date: Sun, 20 Nov 2011 14:25:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111120132512.GA31844@aepfle.de>
References: <20111119215832.GA27626@aepfle.de>
	<CAEDDAD4.253D7%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEDDAD4.253D7%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com, tim@xen.org,
	Jean Guyader <jean.guyader@eu.citrix.com>, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
 XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Nov 19, Keir Fraser wrote:

> On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> > On Wed, Nov 16, Jean Guyader wrote:
> > 
> >> Move the code for the XENMEM_add_to_physmap case into it's own
> >> function (xenmem_add_to_physmap).
> > 
> > This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite
> > failures.
> > (XEN) Assertion '!in_atomic()' failed at softirq.c:61
> > 
> > preempt_count is like fffffc52 or fffffc00 in my testing.
> 
> Thanks, hopefully fixed by c/s 24167.

Yes, the ASSERT does not trigger anymore.

The remaining issue is this:

Nov 20 06:21:11.744519 (XEN) hvm.c:2312:d1 guest attempted write to read-only memory page. gfn=0xc0, mfn=0x201979

See
http://www.chiark.greenend.org.uk/~xensrcts/logs/9893/test-amd64-i386-rhel6hvm-amd/serial-potato-beetle.log

Olaf

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 13:33:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 13:33:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RS7VJ-0000Jn-MN; Sun, 20 Nov 2011 13:32:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RS7VH-0000Jd-Sy
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 13:32:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321795909!3316641!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2447 invoked from network); 20 Nov 2011 13:31:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 13:31:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,542,1315180800"; 
   d="scan'208";a="9026930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Nov 2011 13:31:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 20 Nov 2011 13:31:49 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RS7Uq-000544-VM;
	Sun, 20 Nov 2011 13:31:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RS7Uq-0005mo-P4;
	Sun, 20 Nov 2011 13:31:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9901-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 20 Nov 2011 13:31:48 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9901: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail    like 9855
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 13:33:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 13:33:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RS7VJ-0000Jn-MN; Sun, 20 Nov 2011 13:32:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RS7VH-0000Jd-Sy
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 13:32:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321795909!3316641!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2447 invoked from network); 20 Nov 2011 13:31:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 13:31:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,542,1315180800"; 
   d="scan'208";a="9026930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Nov 2011 13:31:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 20 Nov 2011 13:31:49 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RS7Uq-000544-VM;
	Sun, 20 Nov 2011 13:31:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RS7Uq-0005mo-P4;
	Sun, 20 Nov 2011 13:31:48 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9901-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 20 Nov 2011 13:31:48 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9901: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail    like 9855
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

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


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

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

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


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 14:55:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 14:55:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RS8ma-0000zM-8l; Sun, 20 Nov 2011 14:54:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RS8mY-0000zH-Uc
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 14:54:11 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1321800824!3862085!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24832 invoked from network); 20 Nov 2011 14:53:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	20 Nov 2011 14:53:44 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pAKErcqP012469
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 20 Nov 2011 09:53:38 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pAKErYVN028833; Sun, 20 Nov 2011 09:53:35 -0500
Message-ID: <4EC9146E.1070608@redhat.com>
Date: Sun, 20 Nov 2011 16:53:34 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>	<4EC27D0D.3040204@codemonkey.ws>	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
	<alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
	<4EC671AF.5030805@codemonkey.ws>
In-Reply-To: <4EC671AF.5030805@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: "agraf@suse.de" <agraf@suse.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 04:54 PM, Anthony Liguori wrote:
>
> Thinking more about it, I think this entire line of thinking is wrong
> (including mine) :-)
>
> The problem you're trying to solve is that the RTC fires two 1 second
> timers regardless of whether the guest is reading the wall clock time,
> right?  And since wall clock time is never read from the QEMU RTC in
> Xen, it's a huge waste?
>
> The Right Solution would be to modify the RTC emulation such that it
> did a qemu_get_clock() during read of the CMOS registers in order to
> ensure the time was up to date (instead of using 1 second timers).
>
> Then the timers wouldn't even exist anymore.

That would make host time adjustments (suspend/resume) be reflected in
the guest.

Not sure if that's good or bad, but it's different.

-- 
error compiling committee.c: too many arguments to function


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 14:55:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 14:55:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RS8ma-0000zM-8l; Sun, 20 Nov 2011 14:54:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1RS8mY-0000zH-Uc
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 14:54:11 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1321800824!3862085!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24832 invoked from network); 20 Nov 2011 14:53:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	20 Nov 2011 14:53:44 -0000
Received: from int-mx01.intmail.prod.int.phx2.redhat.com
	(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pAKErcqP012469
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 20 Nov 2011 09:53:38 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pAKErYVN028833; Sun, 20 Nov 2011 09:53:35 -0500
Message-ID: <4EC9146E.1070608@redhat.com>
Date: Sun, 20 Nov 2011 16:53:34 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>	<4EC27D0D.3040204@codemonkey.ws>	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
	<alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
	<4EC671AF.5030805@codemonkey.ws>
In-Reply-To: <4EC671AF.5030805@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: "agraf@suse.de" <agraf@suse.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 04:54 PM, Anthony Liguori wrote:
>
> Thinking more about it, I think this entire line of thinking is wrong
> (including mine) :-)
>
> The problem you're trying to solve is that the RTC fires two 1 second
> timers regardless of whether the guest is reading the wall clock time,
> right?  And since wall clock time is never read from the QEMU RTC in
> Xen, it's a huge waste?
>
> The Right Solution would be to modify the RTC emulation such that it
> did a qemu_get_clock() during read of the CMOS registers in order to
> ensure the time was up to date (instead of using 1 second timers).
>
> Then the timers wouldn't even exist anymore.

That would make host time adjustments (suspend/resume) be reflected in
the guest.

Not sure if that's good or bad, but it's different.

-- 
error compiling committee.c: too many arguments to function


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:31:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:31:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCA7-0002Ru-HC; Sun, 20 Nov 2011 18:30:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCA6-0002Ro-Az
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:30:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321813815!2306590!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21366 invoked from network); 20 Nov 2011 18:30:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-4.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:30:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321813815; l=838;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=5Ml2SIE4cweYawQEYzpeZxxGST8=;
	b=sGhroh1E97TxOI2L4VX4GgswMLmiPrdqQZNIXIcJ69zYVdnaWuy9XUdT9qhVTOMzXmE
	OA8qch51eDonD3Ic2IERE6s8NKmy1Mr8NOcmDDBCUF3tzAfizZysVVo1O/L1bX2x46T+/
	InVT9RxwQdQ1owDZ2SmFtXttYc3roMAImDg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (klopstock mo64) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t05b52nAKFJr53 ;
	Sun, 20 Nov 2011 19:29:52 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 13ABF18637; Sun, 20 Nov 2011 19:29:51 +0100 (CET)
Date: Sun, 20 Nov 2011 19:29:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111120182951.GA4830@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 07, Stefano Stabellini wrote:

> On Mon, 7 Nov 2011, Olaf Hering wrote:
> > > If tot_memkb is the pod target of the domain, we should be coherent and
> > > set it equal to target_memkb when paging is inactive.
> > 
> > So far PoD and paging are unrelated and mean different things.
> > I think the difference between max_memkb and tot_memkb could be the
> > trigger to start paging.
> 
> Yes, I think it would be better.

I have to disagree here.

After looking at the code in parse_config_data(), tot_memkb is only set
if actmem= is listed in the configfile. And if actmem= is set, its the
trigger to run xenpaging and let it work toward the specified number.
So checking for a non-null tot_memkb in create_xenpaging() looks like
the correct way to me to decide wether xenpaging should be started.


Olaf

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:31:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:31:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCA7-0002Ru-HC; Sun, 20 Nov 2011 18:30:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCA6-0002Ro-Az
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:30:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321813815!2306590!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21366 invoked from network); 20 Nov 2011 18:30:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-4.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:30:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321813815; l=838;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=5Ml2SIE4cweYawQEYzpeZxxGST8=;
	b=sGhroh1E97TxOI2L4VX4GgswMLmiPrdqQZNIXIcJ69zYVdnaWuy9XUdT9qhVTOMzXmE
	OA8qch51eDonD3Ic2IERE6s8NKmy1Mr8NOcmDDBCUF3tzAfizZysVVo1O/L1bX2x46T+/
	InVT9RxwQdQ1owDZ2SmFtXttYc3roMAImDg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (klopstock mo64) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t05b52nAKFJr53 ;
	Sun, 20 Nov 2011 19:29:52 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 13ABF18637; Sun, 20 Nov 2011 19:29:51 +0100 (CET)
Date: Sun, 20 Nov 2011 19:29:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111120182951.GA4830@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 07, Stefano Stabellini wrote:

> On Mon, 7 Nov 2011, Olaf Hering wrote:
> > > If tot_memkb is the pod target of the domain, we should be coherent and
> > > set it equal to target_memkb when paging is inactive.
> > 
> > So far PoD and paging are unrelated and mean different things.
> > I think the difference between max_memkb and tot_memkb could be the
> > trigger to start paging.
> 
> Yes, I think it would be better.

I have to disagree here.

After looking at the code in parse_config_data(), tot_memkb is only set
if actmem= is listed in the configfile. And if actmem= is set, its the
trigger to run xenpaging and let it work toward the specified number.
So checking for a non-null tot_memkb in create_xenpaging() looks like
the correct way to me to decide wether xenpaging should be started.


Olaf

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE6-0002fz-Ej; Sun, 20 Nov 2011 18:34:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE4-0002bI-IJ
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1321814061!3882506!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25497 invoked from network); 20 Nov 2011 18:34:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2011 18:34:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814061; l=1256;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=6t1U4iK0UoLI+aADRpr5bHpSGg0=;
	b=myHDpAeHJZx2i0a+bk5pxwYwFvYOSV5bmSetDdhoWmt6TJufav7SxEKzcKTlV6lTZEi
	4BaVWdNDzSpxFj+iFobk8TM2s+XHKWQ+jGWCoPXkF19rQQY1a3B7+vcrQaqkUOgbP4pad
	bsIx8E5FgjjJo+nMjRGvNSZxzG0XLn/Vg9Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (jimi mo30) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n0439anAKFpUlG ;
	Sun, 20 Nov 2011 19:34:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 7268018637;
	Sun, 20 Nov 2011 19:34:06 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b80e53a0d6f06ac6084765961127319990371dca
Message-Id: <b80e53a0d6f06ac60847.1321814046@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01 of 20] xenpaging: remove filename from comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804875 -3600
# Node ID b80e53a0d6f06ac6084765961127319990371dca
# Parent  335e8273a3f34a5e2972643a028f83684609f1c1
xenpaging: remove filename from comment

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 335e8273a3f3 -r b80e53a0d6f0 tools/xenpaging/file_ops.c
--- a/tools/xenpaging/file_ops.c
+++ b/tools/xenpaging/file_ops.c
@@ -1,5 +1,4 @@
 /******************************************************************************
- * tools/xenpaging/file_ops.c
  *
  * Common file operations.
  *
diff -r 335e8273a3f3 -r b80e53a0d6f0 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -1,5 +1,4 @@
 /******************************************************************************
- * tools/xenpaging/policy.c
  *
  * Xen domain paging default policy.
  *
diff -r 335e8273a3f3 -r b80e53a0d6f0 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -1,5 +1,4 @@
 /******************************************************************************
- * tools/xenpaging/xenpaging.c
  *
  * Domain paging. 
  * Copyright (c) 2009 by Citrix Systems, Inc. (Patrick Colp)

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEA-0002kf-RA; Sun, 20 Nov 2011 18:34:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE7-0002dL-WC
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321814050!46368782!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23088 invoked from network); 20 Nov 2011 18:34:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:34:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814065; l=759;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=JuMnRArH6P+sXAsJ4rlRU489qC0=;
	b=Ddr9ee0eaoWOmyxhiXzivQY+ckQ/m3vE7eux1g0U7U65KHoNalutsAwFXsB2liChnJX
	PFIkA7kMZa39qLBVCwksO6HjumpJkN1Xjkm1w02xfxSgh1PFA5uQKPiBWk+QLkEwpK6QK
	BrZAyJCHcuMC+ZsFBx6c2rkj0V4S942Y02k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (cohen mo29) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u04a6enAKHAfzs ;
	Sun, 20 Nov 2011 19:34:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5D7E818636;
	Sun, 20 Nov 2011 19:34:13 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 47fd37efc3738f6c75af73ccbed0e87eb12ab31f
Message-Id: <47fd37efc3738f6c75af.1321814064@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19 of 20] xenpaging: add debug to show received
	watch event
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321809975 -3600
# Node ID 47fd37efc3738f6c75af73ccbed0e87eb12ab31f
# Parent  ba84a323f2dfbdfd2430d3897e616a0e1dd1e4d7
xenpaging: add debug to show received watch event.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r ba84a323f2df -r 47fd37efc373 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -108,6 +108,7 @@ static int xenpaging_wait_for_event_or_t
         vec = xs_read_watch(paging->xs_handle, &num);
         if ( vec )
         {
+            DPRINTF("path '%s' token '%s'\n", vec[XS_WATCH_PATH], vec[XS_WATCH_TOKEN]);
             if ( strcmp(vec[XS_WATCH_TOKEN], watch_token) == 0 )
             {
                 /* If our guest disappeared, set interrupt flag and fall through */

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE6-0002fz-Ej; Sun, 20 Nov 2011 18:34:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE4-0002bI-IJ
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1321814061!3882506!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25497 invoked from network); 20 Nov 2011 18:34:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2011 18:34:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814061; l=1256;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=6t1U4iK0UoLI+aADRpr5bHpSGg0=;
	b=myHDpAeHJZx2i0a+bk5pxwYwFvYOSV5bmSetDdhoWmt6TJufav7SxEKzcKTlV6lTZEi
	4BaVWdNDzSpxFj+iFobk8TM2s+XHKWQ+jGWCoPXkF19rQQY1a3B7+vcrQaqkUOgbP4pad
	bsIx8E5FgjjJo+nMjRGvNSZxzG0XLn/Vg9Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (jimi mo30) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n0439anAKFpUlG ;
	Sun, 20 Nov 2011 19:34:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 7268018637;
	Sun, 20 Nov 2011 19:34:06 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b80e53a0d6f06ac6084765961127319990371dca
Message-Id: <b80e53a0d6f06ac60847.1321814046@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01 of 20] xenpaging: remove filename from comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804875 -3600
# Node ID b80e53a0d6f06ac6084765961127319990371dca
# Parent  335e8273a3f34a5e2972643a028f83684609f1c1
xenpaging: remove filename from comment

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 335e8273a3f3 -r b80e53a0d6f0 tools/xenpaging/file_ops.c
--- a/tools/xenpaging/file_ops.c
+++ b/tools/xenpaging/file_ops.c
@@ -1,5 +1,4 @@
 /******************************************************************************
- * tools/xenpaging/file_ops.c
  *
  * Common file operations.
  *
diff -r 335e8273a3f3 -r b80e53a0d6f0 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -1,5 +1,4 @@
 /******************************************************************************
- * tools/xenpaging/policy.c
  *
  * Xen domain paging default policy.
  *
diff -r 335e8273a3f3 -r b80e53a0d6f0 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -1,5 +1,4 @@
 /******************************************************************************
- * tools/xenpaging/xenpaging.c
  *
  * Domain paging. 
  * Copyright (c) 2009 by Citrix Systems, Inc. (Patrick Colp)

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEA-0002kf-RA; Sun, 20 Nov 2011 18:34:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE7-0002dL-WC
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321814050!46368782!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23088 invoked from network); 20 Nov 2011 18:34:11 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:34:11 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814065; l=759;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=JuMnRArH6P+sXAsJ4rlRU489qC0=;
	b=Ddr9ee0eaoWOmyxhiXzivQY+ckQ/m3vE7eux1g0U7U65KHoNalutsAwFXsB2liChnJX
	PFIkA7kMZa39qLBVCwksO6HjumpJkN1Xjkm1w02xfxSgh1PFA5uQKPiBWk+QLkEwpK6QK
	BrZAyJCHcuMC+ZsFBx6c2rkj0V4S942Y02k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (cohen mo29) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u04a6enAKHAfzs ;
	Sun, 20 Nov 2011 19:34:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5D7E818636;
	Sun, 20 Nov 2011 19:34:13 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 47fd37efc3738f6c75af73ccbed0e87eb12ab31f
Message-Id: <47fd37efc3738f6c75af.1321814064@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19 of 20] xenpaging: add debug to show received
	watch event
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321809975 -3600
# Node ID 47fd37efc3738f6c75af73ccbed0e87eb12ab31f
# Parent  ba84a323f2dfbdfd2430d3897e616a0e1dd1e4d7
xenpaging: add debug to show received watch event.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r ba84a323f2df -r 47fd37efc373 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -108,6 +108,7 @@ static int xenpaging_wait_for_event_or_t
         vec = xs_read_watch(paging->xs_handle, &num);
         if ( vec )
         {
+            DPRINTF("path '%s' token '%s'\n", vec[XS_WATCH_PATH], vec[XS_WATCH_TOKEN]);
             if ( strcmp(vec[XS_WATCH_TOKEN], watch_token) == 0 )
             {
                 /* If our guest disappeared, set interrupt flag and fall through */

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEG-0002rv-Kx; Sun, 20 Nov 2011 18:35:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCEE-0002pH-IR
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321813957!45066352!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31018 invoked from network); 20 Nov 2011 18:32:38 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:32:38 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814076; l=705;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=PA3bxm6y0lxQb/L0MtKoCdYwc/Q=;
	b=ID7L9emo8fAGKlHSkxd9LfY//gjox/JjqK8qC7B4kA1Jkd7cZOxzUQ/opl0ZNj2j7Ij
	0mi4GFcwD+/arTHTwdW+W7/1MrixPDW1AY8qWgrQoYZuqpF7HKQMrtxabAVP1a+EF/L54
	jwNcc2It/yuf3CMUuKCtqBwpr8pUph3B1Uw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo40) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L02818nAKIBq9E ;
	Sun, 20 Nov 2011 19:34:17 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 1F59618638;
	Sun, 20 Nov 2011 19:34:14 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9f0156c725381ee25d96637aa5b486443b2641e5
Message-Id: <9f0156c725381ee25d96.1321814065@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:25 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20 of 20] xenpaging: restrict pagefile
	permissions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321809976 -3600
# Node ID 9f0156c725381ee25d96637aa5b486443b2641e5
# Parent  47fd37efc3738f6c75af73ccbed0e87eb12ab31f
xenpaging: restrict pagefile permissions

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 47fd37efc373 -r 9f0156c72538 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -795,7 +795,7 @@ int main(int argc, char *argv[])
     xc_interface *xch;
 
     int open_flags = O_CREAT | O_TRUNC | O_RDWR;
-    mode_t open_mode = S_IRUSR | S_IRGRP | S_IROTH | S_IWUSR | S_IWGRP | S_IWOTH;
+    mode_t open_mode = S_IRUSR | S_IWUSR;
     int fd;
 
     /* Initialise domain paging */

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCDx-0002at-O6; Sun, 20 Nov 2011 18:34:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDw-0002ZQ-4R
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1321814053!2296893!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3530 invoked from network); 20 Nov 2011 18:34:13 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814053; l=4562;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=e8nkQdFqhdLKqYRD46sSvhfUzHo=;
	b=xV61n60NpDf0shnVcC/MODakOF3SPMErUg37YaI9PGtMaGYvvYAYaQgG0Xg3dyi5FC3
	PvTtG6GwyZLDrNT/0kj2vlGm0qi/kqKavaQDFoN09QWi8CcGHW0fIYs26B/HHQYk2fv33
	+XwnlDmlayE+TlNWKgFip8cbnlQFkQNlWPM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo48) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R02c54nAKI1qw3 ;
	Sun, 20 Nov 2011 19:34:09 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0F53418639;
	Sun, 20 Nov 2011 19:34:08 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 35a65cd961e7ba04350ce0fe539f677dd4722b93
Message-Id: <35a65cd961e7ba04350c.1321814054@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:14 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09 of 20] xenpaging: move page add/resume loops
 into its own function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804959 -3600
# Node ID 35a65cd961e7ba04350ce0fe539f677dd4722b93
# Parent  927af61e2c89bf70c3e873140750aa897fb575e9
xenpaging: move page add/resume loops into its own function.

Move page resume loop into its own function.
Move page eviction loop into its own function.
Allocate all possible slots in a paging file to allow growing and
shrinking of the number of paged-out pages. Adjust other places to
iterate over all slots.

This change is required by subsequent patches.

v2:
 - check if victims allocation succeeded

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 927af61e2c89 -r 35a65cd961e7 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -553,6 +553,27 @@ static int xenpaging_populate_page(xenpa
     return ret;
 }
 
+/* Trigger a page-in for a batch of pages */
+static void resume_pages(xenpaging_t *paging, int num_pages)
+{
+    xc_interface *xch = paging->xc_handle;
+    int i, num = 0;
+
+    for ( i = 0; i < paging->max_pages && num < num_pages; i++ )
+    {
+        if ( test_bit(i, paging->bitmap) )
+        {
+            paging->pagein_queue[num] = i;
+            num++;
+            if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
+                break;
+        }
+    }
+    /* num may be less than num_pages, caller has to try again */
+    if ( num )
+        page_in_trigger();
+}
+
 static int evict_victim(xenpaging_t *paging,
                         xenpaging_victim_t *victim, int fd, int i)
 {
@@ -596,6 +617,30 @@ static int evict_victim(xenpaging_t *pag
     return ret;
 }
 
+/* Evict a batch of pages and write them to a free slot in the paging file */
+static int evict_pages(xenpaging_t *paging, int fd, xenpaging_victim_t *victims, int num_pages)
+{
+    xc_interface *xch = paging->xc_handle;
+    int rc, slot, num = 0;
+
+    for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
+    {
+        /* Slot is allocated */
+        if ( victims[slot].gfn != INVALID_MFN )
+            continue;
+
+        rc = evict_victim(paging, &victims[slot], fd, slot);
+        if ( rc == -ENOSPC )
+            break;
+        if ( rc == -EINTR )
+            break;
+        if ( num && num % 100 == 0 )
+            DPRINTF("%d pages evicted\n", num);
+        num++;
+    }
+    return num;
+}
+
 int main(int argc, char *argv[])
 {
     struct sigaction act;
@@ -638,7 +683,14 @@ int main(int argc, char *argv[])
         return 2;
     }
 
-    victims = calloc(paging->num_pages, sizeof(xenpaging_victim_t));
+    /* Allocate upper limit of pages to allow growing and shrinking */
+    victims = calloc(paging->max_pages, sizeof(xenpaging_victim_t));
+    if ( !victims )
+        goto out;
+
+    /* Mark all slots as unallocated */
+    for ( i = 0; i < paging->max_pages; i++ )
+        victims[i].gfn = INVALID_MFN;
 
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
@@ -652,18 +704,7 @@ int main(int argc, char *argv[])
     /* listen for page-in events to stop pager */
     create_page_in_thread(paging);
 
-    /* Evict pages */
-    for ( i = 0; i < paging->num_pages; i++ )
-    {
-        rc = evict_victim(paging, &victims[i], fd, i);
-        if ( rc == -ENOSPC )
-            break;
-        if ( rc == -EINTR )
-            break;
-        if ( i % 100 == 0 )
-            DPRINTF("%d pages evicted\n", i);
-    }
-
+    i = evict_pages(paging, fd, victims, paging->num_pages);
     DPRINTF("%d pages evicted. Done.\n", i);
 
     /* Swap pages in and out */
@@ -689,13 +730,13 @@ int main(int argc, char *argv[])
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->num_pages; i++ )
+                for ( i = 0; i < paging->max_pages; i++ )
                 {
                     if ( victims[i].gfn == req.gfn )
                         break;
                 }
     
-                if ( i >= paging->num_pages )
+                if ( i >= paging->max_pages )
                 {
                     DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
                     goto out;
@@ -767,25 +808,12 @@ int main(int argc, char *argv[])
         /* Write all pages back into the guest */
         if ( interrupted == SIGTERM || interrupted == SIGINT )
         {
-            int num = 0;
-            for ( i = 0; i < paging->max_pages; i++ )
-            {
-                if ( test_bit(i, paging->bitmap) )
-                {
-                    paging->pagein_queue[num] = i;
-                    num++;
-                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
-                        break;
-                }
-            }
-            /*
-             * One more round if there are still pages to process.
-             * If no more pages to process, exit loop.
-             */
-            if ( num )
-                page_in_trigger();
-            else if ( i == paging->max_pages )
+            /* If no more pages to process, exit loop. */
+            if ( !paging->num_paged_out )
                 break;
+            
+            /* One more round if there are still pages to process. */
+            resume_pages(paging, paging->num_paged_out);
         }
         else
         {

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEB-0002lO-86; Sun, 20 Nov 2011 18:34:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE8-0002dR-9Q
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321814064!3870840!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21135 invoked from network); 20 Nov 2011 18:34:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:34:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814064; l=3690;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=XFQ0E7+jP/uD5G0p/+M7IImuBoo=;
	b=aGP/TIOF0iGgbhjRl+KDdPcExSVLYThV6WTuQKxyrdsrGC1LFU/AJx9uRFxkmrVopEq
	aVslZoQ9xvLwRj0AvOq/CgTzfaV8Nj2nmKJbsC2Z8kPFF6fvOZGtflluESKx24c25Z8Pf
	/9+Crsozl/RTLepYQUVF2Z+oEOHzdXQtt0Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (cohen mo32) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V04d2anAKGHZqy ;
	Sun, 20 Nov 2011 19:34:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 7BA6918639;
	Sun, 20 Nov 2011 19:34:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: ba84a323f2dfbdfd2430d3897e616a0e1dd1e4d7
Message-Id: <ba84a323f2dfbdfd2430.1321814063@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18 of 20] xenpaging: improve policy mru list
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804970 -3600
# Node ID ba84a323f2dfbdfd2430d3897e616a0e1dd1e4d7
# Parent  deb016f351e55e924274b4ccfbb80cb71543fc3e
xenpaging: improve policy mru list handling

Without this change it is not possible to page-out all guest pages, then
trigger a page-in for all pages, and then page-out everything once
again. All pages in the mru list can not be paged out because they
remain active in the internal bitmap of paged pages.

Use the mru list only if the number of paged-out pages is larger than
the mru list. If the number is smaller, start to clear the mru list. In
case the number of paged-out pages drops to zero the mru list and the
internal bitmap will be empty as well.

Also add a new interface for dropped pages. If a gfn was dropped there
is no need to adjust the mru list because dropping a page is not usage
of a page.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r deb016f351e5 -r ba84a323f2df tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -32,6 +32,8 @@ int policy_init(xenpaging_t *paging);
 int policy_choose_victim(xenpaging_t *paging, xenpaging_victim_t *victim);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
+void policy_notify_paged_in_nomru(unsigned long gfn);
+void policy_notify_dropped(unsigned long gfn);
 
 #endif // __XEN_PAGING_POLICY_H__
 
diff -r deb016f351e5 -r ba84a323f2df tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -57,7 +57,7 @@ int policy_init(xenpaging_t *paging)
     if ( paging->policy_mru_size > 0 )
         mru_size = paging->policy_mru_size;
     else
-        mru_size = DEFAULT_MRU_SIZE;
+        mru_size = paging->policy_mru_size = DEFAULT_MRU_SIZE;
 
     mru = malloc(sizeof(*mru) * mru_size);
     if ( mru == NULL )
@@ -120,17 +120,38 @@ void policy_notify_paged_out(unsigned lo
     clear_bit(gfn, unconsumed);
 }
 
-void policy_notify_paged_in(unsigned long gfn)
+static void policy_handle_paged_in(unsigned long gfn, int do_mru)
 {
     unsigned long old_gfn = mru[i_mru & (mru_size - 1)];
 
     if ( old_gfn != INVALID_MFN )
         clear_bit(old_gfn, bitmap);
     
-    mru[i_mru & (mru_size - 1)] = gfn;
+    if (do_mru) {
+        mru[i_mru & (mru_size - 1)] = gfn;
+    } else {
+        clear_bit(gfn, bitmap);
+        mru[i_mru & (mru_size - 1)] = INVALID_MFN;
+    }
+
     i_mru++;
 }
 
+void policy_notify_paged_in(unsigned long gfn)
+{
+    policy_handle_paged_in(gfn, 1);
+}
+
+void policy_notify_paged_in_nomru(unsigned long gfn)
+{
+    policy_handle_paged_in(gfn, 0);
+}
+
+void policy_notify_dropped(unsigned long gfn)
+{
+    clear_bit(gfn, bitmap);
+}
+
 
 /*
  * Local variables:
diff -r deb016f351e5 -r ba84a323f2df tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -615,7 +615,14 @@ static int xenpaging_resume_page(xenpagi
     /* Notify policy of page being paged in */
     if ( notify_policy )
     {
-        policy_notify_paged_in(rsp->gfn);
+        /*
+         * Do not add gfn to mru list if the target is lower than mru size.
+         * This allows page-out of these gfns if the target grows again.
+         */
+        if (paging->num_paged_out > paging->policy_mru_size)
+            policy_notify_paged_in(rsp->gfn);
+        else
+            policy_notify_paged_in_nomru(rsp->gfn);
 
        /* Record number of resumed pages */
        paging->num_paged_out--;
@@ -869,7 +876,7 @@ int main(int argc, char *argv[])
                 {
                     DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, i);
                     /* Notify policy of page being dropped */
-                    policy_notify_paged_in(req.gfn);
+                    policy_notify_dropped(req.gfn);
                 }
                 else
                 {

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEG-0002rv-Kx; Sun, 20 Nov 2011 18:35:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCEE-0002pH-IR
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321813957!45066352!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31018 invoked from network); 20 Nov 2011 18:32:38 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:32:38 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814076; l=705;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=PA3bxm6y0lxQb/L0MtKoCdYwc/Q=;
	b=ID7L9emo8fAGKlHSkxd9LfY//gjox/JjqK8qC7B4kA1Jkd7cZOxzUQ/opl0ZNj2j7Ij
	0mi4GFcwD+/arTHTwdW+W7/1MrixPDW1AY8qWgrQoYZuqpF7HKQMrtxabAVP1a+EF/L54
	jwNcc2It/yuf3CMUuKCtqBwpr8pUph3B1Uw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo40) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L02818nAKIBq9E ;
	Sun, 20 Nov 2011 19:34:17 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 1F59618638;
	Sun, 20 Nov 2011 19:34:14 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9f0156c725381ee25d96637aa5b486443b2641e5
Message-Id: <9f0156c725381ee25d96.1321814065@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:25 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20 of 20] xenpaging: restrict pagefile
	permissions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321809976 -3600
# Node ID 9f0156c725381ee25d96637aa5b486443b2641e5
# Parent  47fd37efc3738f6c75af73ccbed0e87eb12ab31f
xenpaging: restrict pagefile permissions

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 47fd37efc373 -r 9f0156c72538 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -795,7 +795,7 @@ int main(int argc, char *argv[])
     xc_interface *xch;
 
     int open_flags = O_CREAT | O_TRUNC | O_RDWR;
-    mode_t open_mode = S_IRUSR | S_IRGRP | S_IROTH | S_IWUSR | S_IWGRP | S_IWOTH;
+    mode_t open_mode = S_IRUSR | S_IWUSR;
     int fd;
 
     /* Initialise domain paging */

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCDx-0002at-O6; Sun, 20 Nov 2011 18:34:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDw-0002ZQ-4R
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1321814053!2296893!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3530 invoked from network); 20 Nov 2011 18:34:13 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814053; l=4562;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=e8nkQdFqhdLKqYRD46sSvhfUzHo=;
	b=xV61n60NpDf0shnVcC/MODakOF3SPMErUg37YaI9PGtMaGYvvYAYaQgG0Xg3dyi5FC3
	PvTtG6GwyZLDrNT/0kj2vlGm0qi/kqKavaQDFoN09QWi8CcGHW0fIYs26B/HHQYk2fv33
	+XwnlDmlayE+TlNWKgFip8cbnlQFkQNlWPM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo48) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R02c54nAKI1qw3 ;
	Sun, 20 Nov 2011 19:34:09 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0F53418639;
	Sun, 20 Nov 2011 19:34:08 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 35a65cd961e7ba04350ce0fe539f677dd4722b93
Message-Id: <35a65cd961e7ba04350c.1321814054@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:14 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09 of 20] xenpaging: move page add/resume loops
 into its own function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804959 -3600
# Node ID 35a65cd961e7ba04350ce0fe539f677dd4722b93
# Parent  927af61e2c89bf70c3e873140750aa897fb575e9
xenpaging: move page add/resume loops into its own function.

Move page resume loop into its own function.
Move page eviction loop into its own function.
Allocate all possible slots in a paging file to allow growing and
shrinking of the number of paged-out pages. Adjust other places to
iterate over all slots.

This change is required by subsequent patches.

v2:
 - check if victims allocation succeeded

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 927af61e2c89 -r 35a65cd961e7 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -553,6 +553,27 @@ static int xenpaging_populate_page(xenpa
     return ret;
 }
 
+/* Trigger a page-in for a batch of pages */
+static void resume_pages(xenpaging_t *paging, int num_pages)
+{
+    xc_interface *xch = paging->xc_handle;
+    int i, num = 0;
+
+    for ( i = 0; i < paging->max_pages && num < num_pages; i++ )
+    {
+        if ( test_bit(i, paging->bitmap) )
+        {
+            paging->pagein_queue[num] = i;
+            num++;
+            if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
+                break;
+        }
+    }
+    /* num may be less than num_pages, caller has to try again */
+    if ( num )
+        page_in_trigger();
+}
+
 static int evict_victim(xenpaging_t *paging,
                         xenpaging_victim_t *victim, int fd, int i)
 {
@@ -596,6 +617,30 @@ static int evict_victim(xenpaging_t *pag
     return ret;
 }
 
+/* Evict a batch of pages and write them to a free slot in the paging file */
+static int evict_pages(xenpaging_t *paging, int fd, xenpaging_victim_t *victims, int num_pages)
+{
+    xc_interface *xch = paging->xc_handle;
+    int rc, slot, num = 0;
+
+    for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
+    {
+        /* Slot is allocated */
+        if ( victims[slot].gfn != INVALID_MFN )
+            continue;
+
+        rc = evict_victim(paging, &victims[slot], fd, slot);
+        if ( rc == -ENOSPC )
+            break;
+        if ( rc == -EINTR )
+            break;
+        if ( num && num % 100 == 0 )
+            DPRINTF("%d pages evicted\n", num);
+        num++;
+    }
+    return num;
+}
+
 int main(int argc, char *argv[])
 {
     struct sigaction act;
@@ -638,7 +683,14 @@ int main(int argc, char *argv[])
         return 2;
     }
 
-    victims = calloc(paging->num_pages, sizeof(xenpaging_victim_t));
+    /* Allocate upper limit of pages to allow growing and shrinking */
+    victims = calloc(paging->max_pages, sizeof(xenpaging_victim_t));
+    if ( !victims )
+        goto out;
+
+    /* Mark all slots as unallocated */
+    for ( i = 0; i < paging->max_pages; i++ )
+        victims[i].gfn = INVALID_MFN;
 
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
@@ -652,18 +704,7 @@ int main(int argc, char *argv[])
     /* listen for page-in events to stop pager */
     create_page_in_thread(paging);
 
-    /* Evict pages */
-    for ( i = 0; i < paging->num_pages; i++ )
-    {
-        rc = evict_victim(paging, &victims[i], fd, i);
-        if ( rc == -ENOSPC )
-            break;
-        if ( rc == -EINTR )
-            break;
-        if ( i % 100 == 0 )
-            DPRINTF("%d pages evicted\n", i);
-    }
-
+    i = evict_pages(paging, fd, victims, paging->num_pages);
     DPRINTF("%d pages evicted. Done.\n", i);
 
     /* Swap pages in and out */
@@ -689,13 +730,13 @@ int main(int argc, char *argv[])
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->num_pages; i++ )
+                for ( i = 0; i < paging->max_pages; i++ )
                 {
                     if ( victims[i].gfn == req.gfn )
                         break;
                 }
     
-                if ( i >= paging->num_pages )
+                if ( i >= paging->max_pages )
                 {
                     DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
                     goto out;
@@ -767,25 +808,12 @@ int main(int argc, char *argv[])
         /* Write all pages back into the guest */
         if ( interrupted == SIGTERM || interrupted == SIGINT )
         {
-            int num = 0;
-            for ( i = 0; i < paging->max_pages; i++ )
-            {
-                if ( test_bit(i, paging->bitmap) )
-                {
-                    paging->pagein_queue[num] = i;
-                    num++;
-                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
-                        break;
-                }
-            }
-            /*
-             * One more round if there are still pages to process.
-             * If no more pages to process, exit loop.
-             */
-            if ( num )
-                page_in_trigger();
-            else if ( i == paging->max_pages )
+            /* If no more pages to process, exit loop. */
+            if ( !paging->num_paged_out )
                 break;
+            
+            /* One more round if there are still pages to process. */
+            resume_pages(paging, paging->num_paged_out);
         }
         else
         {

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEB-0002lO-86; Sun, 20 Nov 2011 18:34:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE8-0002dR-9Q
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321814064!3870840!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21135 invoked from network); 20 Nov 2011 18:34:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:34:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814064; l=3690;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=XFQ0E7+jP/uD5G0p/+M7IImuBoo=;
	b=aGP/TIOF0iGgbhjRl+KDdPcExSVLYThV6WTuQKxyrdsrGC1LFU/AJx9uRFxkmrVopEq
	aVslZoQ9xvLwRj0AvOq/CgTzfaV8Nj2nmKJbsC2Z8kPFF6fvOZGtflluESKx24c25Z8Pf
	/9+Crsozl/RTLepYQUVF2Z+oEOHzdXQtt0Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (cohen mo32) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id V04d2anAKGHZqy ;
	Sun, 20 Nov 2011 19:34:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 7BA6918639;
	Sun, 20 Nov 2011 19:34:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: ba84a323f2dfbdfd2430d3897e616a0e1dd1e4d7
Message-Id: <ba84a323f2dfbdfd2430.1321814063@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18 of 20] xenpaging: improve policy mru list
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804970 -3600
# Node ID ba84a323f2dfbdfd2430d3897e616a0e1dd1e4d7
# Parent  deb016f351e55e924274b4ccfbb80cb71543fc3e
xenpaging: improve policy mru list handling

Without this change it is not possible to page-out all guest pages, then
trigger a page-in for all pages, and then page-out everything once
again. All pages in the mru list can not be paged out because they
remain active in the internal bitmap of paged pages.

Use the mru list only if the number of paged-out pages is larger than
the mru list. If the number is smaller, start to clear the mru list. In
case the number of paged-out pages drops to zero the mru list and the
internal bitmap will be empty as well.

Also add a new interface for dropped pages. If a gfn was dropped there
is no need to adjust the mru list because dropping a page is not usage
of a page.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r deb016f351e5 -r ba84a323f2df tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -32,6 +32,8 @@ int policy_init(xenpaging_t *paging);
 int policy_choose_victim(xenpaging_t *paging, xenpaging_victim_t *victim);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
+void policy_notify_paged_in_nomru(unsigned long gfn);
+void policy_notify_dropped(unsigned long gfn);
 
 #endif // __XEN_PAGING_POLICY_H__
 
diff -r deb016f351e5 -r ba84a323f2df tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -57,7 +57,7 @@ int policy_init(xenpaging_t *paging)
     if ( paging->policy_mru_size > 0 )
         mru_size = paging->policy_mru_size;
     else
-        mru_size = DEFAULT_MRU_SIZE;
+        mru_size = paging->policy_mru_size = DEFAULT_MRU_SIZE;
 
     mru = malloc(sizeof(*mru) * mru_size);
     if ( mru == NULL )
@@ -120,17 +120,38 @@ void policy_notify_paged_out(unsigned lo
     clear_bit(gfn, unconsumed);
 }
 
-void policy_notify_paged_in(unsigned long gfn)
+static void policy_handle_paged_in(unsigned long gfn, int do_mru)
 {
     unsigned long old_gfn = mru[i_mru & (mru_size - 1)];
 
     if ( old_gfn != INVALID_MFN )
         clear_bit(old_gfn, bitmap);
     
-    mru[i_mru & (mru_size - 1)] = gfn;
+    if (do_mru) {
+        mru[i_mru & (mru_size - 1)] = gfn;
+    } else {
+        clear_bit(gfn, bitmap);
+        mru[i_mru & (mru_size - 1)] = INVALID_MFN;
+    }
+
     i_mru++;
 }
 
+void policy_notify_paged_in(unsigned long gfn)
+{
+    policy_handle_paged_in(gfn, 1);
+}
+
+void policy_notify_paged_in_nomru(unsigned long gfn)
+{
+    policy_handle_paged_in(gfn, 0);
+}
+
+void policy_notify_dropped(unsigned long gfn)
+{
+    clear_bit(gfn, bitmap);
+}
+
 
 /*
  * Local variables:
diff -r deb016f351e5 -r ba84a323f2df tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -615,7 +615,14 @@ static int xenpaging_resume_page(xenpagi
     /* Notify policy of page being paged in */
     if ( notify_policy )
     {
-        policy_notify_paged_in(rsp->gfn);
+        /*
+         * Do not add gfn to mru list if the target is lower than mru size.
+         * This allows page-out of these gfns if the target grows again.
+         */
+        if (paging->num_paged_out > paging->policy_mru_size)
+            policy_notify_paged_in(rsp->gfn);
+        else
+            policy_notify_paged_in_nomru(rsp->gfn);
 
        /* Record number of resumed pages */
        paging->num_paged_out--;
@@ -869,7 +876,7 @@ int main(int argc, char *argv[])
                 {
                     DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, i);
                     /* Notify policy of page being dropped */
-                    policy_notify_paged_in(req.gfn);
+                    policy_notify_dropped(req.gfn);
                 }
                 else
                 {

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCDq-0002ZM-LO; Sun, 20 Nov 2011 18:34:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDp-0002ZF-Ab
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321814036!46368770!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22907 invoked from network); 20 Nov 2011 18:33:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:33:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814051; l=7449;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=PlZGLIIVWGNfYxHaWvfSlLOZX4E=;
	b=AkB2MyxVvp+0niwi4LmInTO0daBfboexwhJqBwbey/T8ENomtMTR2n0aQgSy42KKnrO
	njI10iyc6Tqozz2MNBSsPuD+YBsdDv9pld2V3fgxpSGQzU+apETQ9dTw4TAdBS+gaKkwm
	0O/Zyg2YMJOj2eEWBOIE6qh22QHr0BAx6OY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo56) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 503191nAKFpAwc ;
	Sun, 20 Nov 2011 19:34:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B8D7218639;
	Sun, 20 Nov 2011 19:34:06 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b6c4a6f4f1f77b2471e4aa5fd23b375761691f79
Message-Id: <b6c4a6f4f1f77b2471e4.1321814048@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03 of 20] xenpaging: use PERROR to print errno
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804892 -3600
# Node ID b6c4a6f4f1f77b2471e4aa5fd23b375761691f79
# Parent  00f6e1294ae25a13820af1582170305b27eb69aa
xenpaging: use PERROR to print errno

v3:
 - adjust arguments for xc_mem_paging_enable() failures
v2:
 - move changes to file_op() to different patch

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 00f6e1294ae2 -r b6c4a6f4f1f7 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -90,7 +90,7 @@ static int xenpaging_wait_for_event_or_t
         if (errno == EINTR)
             return 0;
 
-        ERROR("Poll exited with an error");
+        PERROR("Poll exited with an error");
         return -errno;
     }
 
@@ -121,7 +121,7 @@ static int xenpaging_wait_for_event_or_t
         port = xc_evtchn_pending(xce);
         if ( port == -1 )
         {
-            ERROR("Failed to read port from event channel");
+            PERROR("Failed to read port from event channel");
             rc = -1;
             goto err;
         }
@@ -129,7 +129,7 @@ static int xenpaging_wait_for_event_or_t
         rc = xc_evtchn_unmask(xce, port);
         if ( rc < 0 )
         {
-            ERROR("Failed to unmask event channel port");
+            PERROR("Failed to unmask event channel port");
         }
     }
 err:
@@ -185,7 +185,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->xs_handle = xs_open(0);
     if ( paging->xs_handle == NULL )
     {
-        ERROR("Error initialising xenstore connection");
+        PERROR("Error initialising xenstore connection");
         goto err;
     }
 
@@ -193,7 +193,7 @@ static xenpaging_t *xenpaging_init(domid
     snprintf(watch_token, sizeof(watch_token), "%u", domain_id);
     if ( xs_watch(paging->xs_handle, "@releaseDomain", watch_token) == false )
     {
-        ERROR("Could not bind to shutdown watch\n");
+        PERROR("Could not bind to shutdown watch\n");
         goto err;
     }
 
@@ -214,7 +214,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->mem_event.shared_page = init_page();
     if ( paging->mem_event.shared_page == NULL )
     {
-        ERROR("Error initialising shared page");
+        PERROR("Error initialising shared page");
         goto err;
     }
 
@@ -222,7 +222,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->mem_event.ring_page = init_page();
     if ( paging->mem_event.ring_page == NULL )
     {
-        ERROR("Error initialising ring page");
+        PERROR("Error initialising ring page");
         goto err;
     }
 
@@ -249,7 +249,7 @@ static xenpaging_t *xenpaging_init(domid
                 ERROR("xenpaging not supported in a PoD guest");
                 break;
             default:
-                ERROR("Error initialising shared page: %s", strerror(errno));
+                PERROR("Error initialising shared page");
                 break;
         }
         goto err;
@@ -259,7 +259,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
     if ( paging->mem_event.xce_handle == NULL )
     {
-        ERROR("Failed to open event channel");
+        PERROR("Failed to open event channel");
         goto err;
     }
 
@@ -269,7 +269,7 @@ static xenpaging_t *xenpaging_init(domid
                                     paging->mem_event.shared_page->port);
     if ( rc < 0 )
     {
-        ERROR("Failed to bind event channel");
+        PERROR("Failed to bind event channel");
         goto err;
     }
 
@@ -279,7 +279,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->domain_info = malloc(sizeof(xc_domaininfo_t));
     if ( paging->domain_info == NULL )
     {
-        ERROR("Error allocating memory for domain info");
+        PERROR("Error allocating memory for domain info");
         goto err;
     }
 
@@ -287,7 +287,7 @@ static xenpaging_t *xenpaging_init(domid
                                paging->domain_info);
     if ( rc != 1 )
     {
-        ERROR("Error getting domain info");
+        PERROR("Error getting domain info");
         goto err;
     }
 
@@ -295,7 +295,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->bitmap = bitmap_alloc(paging->domain_info->max_pages);
     if ( !paging->bitmap )
     {
-        ERROR("Error allocating bitmap");
+        PERROR("Error allocating bitmap");
         goto err;
     }
     DPRINTF("max_pages = %"PRIx64"\n", paging->domain_info->max_pages);
@@ -311,7 +311,7 @@ static xenpaging_t *xenpaging_init(domid
     rc = policy_init(paging);
     if ( rc != 0 )
     {
-        ERROR("Error initialising policy");
+        PERROR("Error initialising policy");
         goto err;
     }
 
@@ -358,14 +358,14 @@ static int xenpaging_teardown(xenpaging_
     rc = xc_mem_paging_disable(xch, paging->mem_event.domain_id);
     if ( rc != 0 )
     {
-        ERROR("Error tearing down domain paging in xen");
+        PERROR("Error tearing down domain paging in xen");
     }
 
     /* Unbind VIRQ */
     rc = xc_evtchn_unbind(paging->mem_event.xce_handle, paging->mem_event.port);
     if ( rc != 0 )
     {
-        ERROR("Error unbinding event port");
+        PERROR("Error unbinding event port");
     }
     paging->mem_event.port = -1;
 
@@ -373,7 +373,7 @@ static int xenpaging_teardown(xenpaging_
     rc = xc_evtchn_close(paging->mem_event.xce_handle);
     if ( rc != 0 )
     {
-        ERROR("Error closing event channel");
+        PERROR("Error closing event channel");
     }
     paging->mem_event.xce_handle = NULL;
     
@@ -384,7 +384,7 @@ static int xenpaging_teardown(xenpaging_
     rc = xc_interface_close(xch);
     if ( rc != 0 )
     {
-        ERROR("Error closing connection to xen");
+        PERROR("Error closing connection to xen");
     }
 
     return 0;
@@ -444,7 +444,7 @@ static int xenpaging_evict_page(xenpagin
                                 PROT_READ | PROT_WRITE, &gfn, 1);
     if ( page == NULL )
     {
-        ERROR("Error mapping page");
+        PERROR("Error mapping page");
         goto out;
     }
 
@@ -452,8 +452,8 @@ static int xenpaging_evict_page(xenpagin
     ret = write_page(fd, page, i);
     if ( ret != 0 )
     {
+        PERROR("Error copying page");
         munmap(page, PAGE_SIZE);
-        ERROR("Error copying page");
         goto out;
     }
 
@@ -464,7 +464,7 @@ static int xenpaging_evict_page(xenpagin
                               victim->gfn);
     if ( ret != 0 )
     {
-        ERROR("Error evicting page");
+        PERROR("Error evicting page");
         goto out;
     }
 
@@ -520,7 +520,7 @@ static int xenpaging_populate_page(xenpa
                 sleep(1);
                 continue;
             }
-            ERROR("Error preparing for page in");
+            PERROR("Error preparing for page in");
             goto out_map;
         }
     }
@@ -532,7 +532,7 @@ static int xenpaging_populate_page(xenpa
                                 PROT_READ | PROT_WRITE, &gfn, 1);
     if ( page == NULL )
     {
-        ERROR("Error mapping page: page is null");
+        PERROR("Error mapping page: page is null");
         goto out_map;
     }
 
@@ -540,7 +540,7 @@ static int xenpaging_populate_page(xenpa
     ret = read_page(fd, page, i);
     if ( ret != 0 )
     {
-        ERROR("Error reading page");
+        PERROR("Error reading page");
         goto out;
     }
 
@@ -579,7 +579,7 @@ static int evict_victim(xenpaging_t *pag
         {
             if ( j++ % 1000 == 0 )
                 if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
-                    ERROR("Error flushing ioemu cache");
+                    PERROR("Error flushing ioemu cache");
         }
     }
     while ( ret );
@@ -670,7 +670,7 @@ int main(int argc, char *argv[])
         rc = xenpaging_wait_for_event_or_timeout(paging);
         if ( rc < 0 )
         {
-            ERROR("Error getting event");
+            PERROR("Error getting event");
             goto out;
         }
         else if ( rc != 0 )
@@ -710,7 +710,7 @@ int main(int argc, char *argv[])
                     rc = xenpaging_populate_page(paging, req.gfn, fd, i);
                     if ( rc != 0 )
                     {
-                        ERROR("Error populating page");
+                        PERROR("Error populating page");
                         goto out;
                     }
                 }
@@ -723,7 +723,7 @@ int main(int argc, char *argv[])
                 rc = xenpaging_resume_page(paging, &rsp, 1);
                 if ( rc != 0 )
                 {
-                    ERROR("Error resuming page");
+                    PERROR("Error resuming page");
                     goto out;
                 }
 
@@ -754,7 +754,7 @@ int main(int argc, char *argv[])
                     rc = xenpaging_resume_page(paging, &rsp, 0);
                     if ( rc != 0 )
                     {
-                        ERROR("Error resuming");
+                        PERROR("Error resuming");
                         goto out;
                     }
                 }

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE0-0002bw-Lu; Sun, 20 Nov 2011 18:34:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDz-0002Zk-1r
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1321814056!4941123!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17866 invoked from network); 20 Nov 2011 18:34:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:34:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814055; l=1499;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=maYKzWunQF74SnYdaCNblwiv/Uw=;
	b=Dj5iODbPKVfhC3pQrRwvrrXDdW5xA2SxtDW9BWF18g7idtLojPMlG8sgzhBha8HdJhN
	tjaqvt+ylStWjvJqHlEEKTxKyeDnb6B/pwzvXYYnkeDF+OiFE9qj70RZFo12/V5d6gBOG
	YmdW74htKkAwdkhXur41MN090COBO0Xni5E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (cohen mo11) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 003d5fnAKGd40q ;
	Sun, 20 Nov 2011 19:34:09 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CFF301863B;
	Sun, 20 Nov 2011 19:34:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 927af61e2c89bf70c3e873140750aa897fb575e9
Message-Id: <927af61e2c89bf70c3e8.1321814053@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:13 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08 of 20] xenpaging: track the number of
	paged-out pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804958 -3600
# Node ID 927af61e2c89bf70c3e873140750aa897fb575e9
# Parent  98c0a058f05634833ccb9fb6671ee94cde444fa1
xenpaging: track the number of paged-out pages

This change is required by subsequent changes.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 98c0a058f056 -r 927af61e2c89 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -467,6 +467,9 @@ static int xenpaging_evict_page(xenpagin
     /* Notify policy of page being paged out */
     policy_notify_paged_out(victim->gfn);
 
+    /* Record number of evicted pages */
+    paging->num_paged_out++;
+
  out:
     return ret;
 }
@@ -480,8 +483,13 @@ static int xenpaging_resume_page(xenpagi
 
     /* Notify policy of page being paged in */
     if ( notify_policy )
+    {
         policy_notify_paged_in(rsp->gfn);
 
+       /* Record number of resumed pages */
+       paging->num_paged_out--;
+    }
+
     /* Tell Xen page is ready */
     ret = xc_mem_paging_resume(paging->xc_handle, paging->mem_event.domain_id,
                                rsp->gfn);
diff -r 98c0a058f056 -r 927af61e2c89 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -49,6 +49,7 @@ typedef struct xenpaging {
     mem_event_t mem_event;
     /* number of pages for which data structures were allocated */
     int max_pages;
+    int num_paged_out;
     int num_pages;
     int policy_mru_size;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEB-0002mI-Oi; Sun, 20 Nov 2011 18:34:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCEB-0002fP-48
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321814068!4274337!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26765 invoked from network); 20 Nov 2011 18:34:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:34:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814068; l=2472;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=jprWPiXTvcZlUH3TSDmAsRERKoQ=;
	b=V9JDFE+NIIA7XuZKYp5zS1k330G9Q0T0YQXSWDuCJ5EhOMyKv0AH63AZwmZWMANrPrt
	SLTH6LuGA0CRyV7KKiKiXOvHdTjwKJRSIe8M7FX3wQSyoqzPf9KFdQJj8zwzNXXFrq9b1
	ixnwlSb5kZoR4QYVQykALaNvKZOnbqZaNX4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (cohen mo63) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 2063cbnAKHfalQ ;
	Sun, 20 Nov 2011 19:34:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 18E6018636;
	Sun, 20 Nov 2011 19:34:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c0c01de70558deca53a338b8c0956b56900c2257
Message-Id: <c0c01de70558deca53a3.1321814050@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05 of 20] xenpaging: print gfn in failure case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804901 -3600
# Node ID c0c01de70558deca53a338b8c0956b56900c2257
# Parent  0bc6eb35c8bf6d09dc13f1fedb70874c1962f95d
xenpaging: print gfn in failure case

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0bc6eb35c8bf -r c0c01de70558 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -444,7 +444,7 @@ static int xenpaging_evict_page(xenpagin
                                 PROT_READ | PROT_WRITE, &gfn, 1);
     if ( page == NULL )
     {
-        PERROR("Error mapping page");
+        PERROR("Error mapping page %lx", victim->gfn);
         goto out;
     }
 
@@ -452,7 +452,7 @@ static int xenpaging_evict_page(xenpagin
     ret = write_page(fd, page, i);
     if ( ret != 0 )
     {
-        PERROR("Error copying page");
+        PERROR("Error copying page %lx", victim->gfn);
         munmap(page, PAGE_SIZE);
         goto out;
     }
@@ -464,7 +464,7 @@ static int xenpaging_evict_page(xenpagin
                               victim->gfn);
     if ( ret != 0 )
     {
-        PERROR("Error evicting page");
+        PERROR("Error evicting page %lx", victim->gfn);
         goto out;
     }
 
@@ -520,7 +520,7 @@ static int xenpaging_populate_page(xenpa
                 sleep(1);
                 continue;
             }
-            PERROR("Error preparing for page in");
+            PERROR("Error preparing %"PRI_xen_pfn" for page-in", gfn);
             goto out_map;
         }
     }
@@ -532,7 +532,7 @@ static int xenpaging_populate_page(xenpa
                                 PROT_READ | PROT_WRITE, &gfn, 1);
     if ( page == NULL )
     {
-        PERROR("Error mapping page: page is null");
+        PERROR("Error mapping page %"PRI_xen_pfn": page is null", gfn);
         goto out_map;
     }
 
@@ -540,7 +540,7 @@ static int xenpaging_populate_page(xenpa
     ret = read_page(fd, page, i);
     if ( ret != 0 )
     {
-        PERROR("Error reading page");
+        PERROR("Error reading page %"PRI_xen_pfn"", gfn);
         goto out;
     }
 
@@ -710,7 +710,7 @@ int main(int argc, char *argv[])
                     rc = xenpaging_populate_page(paging, req.gfn, fd, i);
                     if ( rc != 0 )
                     {
-                        PERROR("Error populating page");
+                        PERROR("Error populating page %"PRIx64"", req.gfn);
                         goto out;
                     }
                 }
@@ -723,7 +723,7 @@ int main(int argc, char *argv[])
                 rc = xenpaging_resume_page(paging, &rsp, 1);
                 if ( rc != 0 )
                 {
-                    PERROR("Error resuming page");
+                    PERROR("Error resuming page %"PRIx64"", req.gfn);
                     goto out;
                 }
 
@@ -754,7 +754,7 @@ int main(int argc, char *argv[])
                     rc = xenpaging_resume_page(paging, &rsp, 0);
                     if ( rc != 0 )
                     {
-                        PERROR("Error resuming");
+                        PERROR("Error resuming page %"PRIx64"", req.gfn);
                         goto out;
                     }
                 }

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCDq-0002ZM-LO; Sun, 20 Nov 2011 18:34:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDp-0002ZF-Ab
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321814036!46368770!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22907 invoked from network); 20 Nov 2011 18:33:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:33:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814051; l=7449;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=PlZGLIIVWGNfYxHaWvfSlLOZX4E=;
	b=AkB2MyxVvp+0niwi4LmInTO0daBfboexwhJqBwbey/T8ENomtMTR2n0aQgSy42KKnrO
	njI10iyc6Tqozz2MNBSsPuD+YBsdDv9pld2V3fgxpSGQzU+apETQ9dTw4TAdBS+gaKkwm
	0O/Zyg2YMJOj2eEWBOIE6qh22QHr0BAx6OY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo56) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 503191nAKFpAwc ;
	Sun, 20 Nov 2011 19:34:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B8D7218639;
	Sun, 20 Nov 2011 19:34:06 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b6c4a6f4f1f77b2471e4aa5fd23b375761691f79
Message-Id: <b6c4a6f4f1f77b2471e4.1321814048@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03 of 20] xenpaging: use PERROR to print errno
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804892 -3600
# Node ID b6c4a6f4f1f77b2471e4aa5fd23b375761691f79
# Parent  00f6e1294ae25a13820af1582170305b27eb69aa
xenpaging: use PERROR to print errno

v3:
 - adjust arguments for xc_mem_paging_enable() failures
v2:
 - move changes to file_op() to different patch

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 00f6e1294ae2 -r b6c4a6f4f1f7 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -90,7 +90,7 @@ static int xenpaging_wait_for_event_or_t
         if (errno == EINTR)
             return 0;
 
-        ERROR("Poll exited with an error");
+        PERROR("Poll exited with an error");
         return -errno;
     }
 
@@ -121,7 +121,7 @@ static int xenpaging_wait_for_event_or_t
         port = xc_evtchn_pending(xce);
         if ( port == -1 )
         {
-            ERROR("Failed to read port from event channel");
+            PERROR("Failed to read port from event channel");
             rc = -1;
             goto err;
         }
@@ -129,7 +129,7 @@ static int xenpaging_wait_for_event_or_t
         rc = xc_evtchn_unmask(xce, port);
         if ( rc < 0 )
         {
-            ERROR("Failed to unmask event channel port");
+            PERROR("Failed to unmask event channel port");
         }
     }
 err:
@@ -185,7 +185,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->xs_handle = xs_open(0);
     if ( paging->xs_handle == NULL )
     {
-        ERROR("Error initialising xenstore connection");
+        PERROR("Error initialising xenstore connection");
         goto err;
     }
 
@@ -193,7 +193,7 @@ static xenpaging_t *xenpaging_init(domid
     snprintf(watch_token, sizeof(watch_token), "%u", domain_id);
     if ( xs_watch(paging->xs_handle, "@releaseDomain", watch_token) == false )
     {
-        ERROR("Could not bind to shutdown watch\n");
+        PERROR("Could not bind to shutdown watch\n");
         goto err;
     }
 
@@ -214,7 +214,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->mem_event.shared_page = init_page();
     if ( paging->mem_event.shared_page == NULL )
     {
-        ERROR("Error initialising shared page");
+        PERROR("Error initialising shared page");
         goto err;
     }
 
@@ -222,7 +222,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->mem_event.ring_page = init_page();
     if ( paging->mem_event.ring_page == NULL )
     {
-        ERROR("Error initialising ring page");
+        PERROR("Error initialising ring page");
         goto err;
     }
 
@@ -249,7 +249,7 @@ static xenpaging_t *xenpaging_init(domid
                 ERROR("xenpaging not supported in a PoD guest");
                 break;
             default:
-                ERROR("Error initialising shared page: %s", strerror(errno));
+                PERROR("Error initialising shared page");
                 break;
         }
         goto err;
@@ -259,7 +259,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
     if ( paging->mem_event.xce_handle == NULL )
     {
-        ERROR("Failed to open event channel");
+        PERROR("Failed to open event channel");
         goto err;
     }
 
@@ -269,7 +269,7 @@ static xenpaging_t *xenpaging_init(domid
                                     paging->mem_event.shared_page->port);
     if ( rc < 0 )
     {
-        ERROR("Failed to bind event channel");
+        PERROR("Failed to bind event channel");
         goto err;
     }
 
@@ -279,7 +279,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->domain_info = malloc(sizeof(xc_domaininfo_t));
     if ( paging->domain_info == NULL )
     {
-        ERROR("Error allocating memory for domain info");
+        PERROR("Error allocating memory for domain info");
         goto err;
     }
 
@@ -287,7 +287,7 @@ static xenpaging_t *xenpaging_init(domid
                                paging->domain_info);
     if ( rc != 1 )
     {
-        ERROR("Error getting domain info");
+        PERROR("Error getting domain info");
         goto err;
     }
 
@@ -295,7 +295,7 @@ static xenpaging_t *xenpaging_init(domid
     paging->bitmap = bitmap_alloc(paging->domain_info->max_pages);
     if ( !paging->bitmap )
     {
-        ERROR("Error allocating bitmap");
+        PERROR("Error allocating bitmap");
         goto err;
     }
     DPRINTF("max_pages = %"PRIx64"\n", paging->domain_info->max_pages);
@@ -311,7 +311,7 @@ static xenpaging_t *xenpaging_init(domid
     rc = policy_init(paging);
     if ( rc != 0 )
     {
-        ERROR("Error initialising policy");
+        PERROR("Error initialising policy");
         goto err;
     }
 
@@ -358,14 +358,14 @@ static int xenpaging_teardown(xenpaging_
     rc = xc_mem_paging_disable(xch, paging->mem_event.domain_id);
     if ( rc != 0 )
     {
-        ERROR("Error tearing down domain paging in xen");
+        PERROR("Error tearing down domain paging in xen");
     }
 
     /* Unbind VIRQ */
     rc = xc_evtchn_unbind(paging->mem_event.xce_handle, paging->mem_event.port);
     if ( rc != 0 )
     {
-        ERROR("Error unbinding event port");
+        PERROR("Error unbinding event port");
     }
     paging->mem_event.port = -1;
 
@@ -373,7 +373,7 @@ static int xenpaging_teardown(xenpaging_
     rc = xc_evtchn_close(paging->mem_event.xce_handle);
     if ( rc != 0 )
     {
-        ERROR("Error closing event channel");
+        PERROR("Error closing event channel");
     }
     paging->mem_event.xce_handle = NULL;
     
@@ -384,7 +384,7 @@ static int xenpaging_teardown(xenpaging_
     rc = xc_interface_close(xch);
     if ( rc != 0 )
     {
-        ERROR("Error closing connection to xen");
+        PERROR("Error closing connection to xen");
     }
 
     return 0;
@@ -444,7 +444,7 @@ static int xenpaging_evict_page(xenpagin
                                 PROT_READ | PROT_WRITE, &gfn, 1);
     if ( page == NULL )
     {
-        ERROR("Error mapping page");
+        PERROR("Error mapping page");
         goto out;
     }
 
@@ -452,8 +452,8 @@ static int xenpaging_evict_page(xenpagin
     ret = write_page(fd, page, i);
     if ( ret != 0 )
     {
+        PERROR("Error copying page");
         munmap(page, PAGE_SIZE);
-        ERROR("Error copying page");
         goto out;
     }
 
@@ -464,7 +464,7 @@ static int xenpaging_evict_page(xenpagin
                               victim->gfn);
     if ( ret != 0 )
     {
-        ERROR("Error evicting page");
+        PERROR("Error evicting page");
         goto out;
     }
 
@@ -520,7 +520,7 @@ static int xenpaging_populate_page(xenpa
                 sleep(1);
                 continue;
             }
-            ERROR("Error preparing for page in");
+            PERROR("Error preparing for page in");
             goto out_map;
         }
     }
@@ -532,7 +532,7 @@ static int xenpaging_populate_page(xenpa
                                 PROT_READ | PROT_WRITE, &gfn, 1);
     if ( page == NULL )
     {
-        ERROR("Error mapping page: page is null");
+        PERROR("Error mapping page: page is null");
         goto out_map;
     }
 
@@ -540,7 +540,7 @@ static int xenpaging_populate_page(xenpa
     ret = read_page(fd, page, i);
     if ( ret != 0 )
     {
-        ERROR("Error reading page");
+        PERROR("Error reading page");
         goto out;
     }
 
@@ -579,7 +579,7 @@ static int evict_victim(xenpaging_t *pag
         {
             if ( j++ % 1000 == 0 )
                 if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
-                    ERROR("Error flushing ioemu cache");
+                    PERROR("Error flushing ioemu cache");
         }
     }
     while ( ret );
@@ -670,7 +670,7 @@ int main(int argc, char *argv[])
         rc = xenpaging_wait_for_event_or_timeout(paging);
         if ( rc < 0 )
         {
-            ERROR("Error getting event");
+            PERROR("Error getting event");
             goto out;
         }
         else if ( rc != 0 )
@@ -710,7 +710,7 @@ int main(int argc, char *argv[])
                     rc = xenpaging_populate_page(paging, req.gfn, fd, i);
                     if ( rc != 0 )
                     {
-                        ERROR("Error populating page");
+                        PERROR("Error populating page");
                         goto out;
                     }
                 }
@@ -723,7 +723,7 @@ int main(int argc, char *argv[])
                 rc = xenpaging_resume_page(paging, &rsp, 1);
                 if ( rc != 0 )
                 {
-                    ERROR("Error resuming page");
+                    PERROR("Error resuming page");
                     goto out;
                 }
 
@@ -754,7 +754,7 @@ int main(int argc, char *argv[])
                     rc = xenpaging_resume_page(paging, &rsp, 0);
                     if ( rc != 0 )
                     {
-                        ERROR("Error resuming");
+                        PERROR("Error resuming");
                         goto out;
                     }
                 }

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE0-0002bw-Lu; Sun, 20 Nov 2011 18:34:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDz-0002Zk-1r
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1321814056!4941123!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17866 invoked from network); 20 Nov 2011 18:34:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:34:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814055; l=1499;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=maYKzWunQF74SnYdaCNblwiv/Uw=;
	b=Dj5iODbPKVfhC3pQrRwvrrXDdW5xA2SxtDW9BWF18g7idtLojPMlG8sgzhBha8HdJhN
	tjaqvt+ylStWjvJqHlEEKTxKyeDnb6B/pwzvXYYnkeDF+OiFE9qj70RZFo12/V5d6gBOG
	YmdW74htKkAwdkhXur41MN090COBO0Xni5E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (cohen mo11) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 003d5fnAKGd40q ;
	Sun, 20 Nov 2011 19:34:09 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CFF301863B;
	Sun, 20 Nov 2011 19:34:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 927af61e2c89bf70c3e873140750aa897fb575e9
Message-Id: <927af61e2c89bf70c3e8.1321814053@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:13 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08 of 20] xenpaging: track the number of
	paged-out pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804958 -3600
# Node ID 927af61e2c89bf70c3e873140750aa897fb575e9
# Parent  98c0a058f05634833ccb9fb6671ee94cde444fa1
xenpaging: track the number of paged-out pages

This change is required by subsequent changes.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 98c0a058f056 -r 927af61e2c89 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -467,6 +467,9 @@ static int xenpaging_evict_page(xenpagin
     /* Notify policy of page being paged out */
     policy_notify_paged_out(victim->gfn);
 
+    /* Record number of evicted pages */
+    paging->num_paged_out++;
+
  out:
     return ret;
 }
@@ -480,8 +483,13 @@ static int xenpaging_resume_page(xenpagi
 
     /* Notify policy of page being paged in */
     if ( notify_policy )
+    {
         policy_notify_paged_in(rsp->gfn);
 
+       /* Record number of resumed pages */
+       paging->num_paged_out--;
+    }
+
     /* Tell Xen page is ready */
     ret = xc_mem_paging_resume(paging->xc_handle, paging->mem_event.domain_id,
                                rsp->gfn);
diff -r 98c0a058f056 -r 927af61e2c89 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -49,6 +49,7 @@ typedef struct xenpaging {
     mem_event_t mem_event;
     /* number of pages for which data structures were allocated */
     int max_pages;
+    int num_paged_out;
     int num_pages;
     int policy_mru_size;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE6-0002gZ-SB; Sun, 20 Nov 2011 18:34:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE5-0002bd-3o
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321814029!44653316!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6018 invoked from network); 20 Nov 2011 18:33:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:33:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814062; l=5383;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=q35pXBsrAYgTCXYoW5nH+AhcNmQ=;
	b=n6sxXB1jp7hu79DNN0NRAJjJimf9KMbXFVnqdRf81LZizVUwcLFOSOOoPB8+snb0NKs
	qbdI91oP4TS/atOwnaiIVhYShryj5XjCrHh11MIa/wnxIcpwWIPwbac6RK/c1OygwHYXY
	IbCqwd9nMAXRObOHnmyEfZF9zeWAjk/qBY4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (cohen mo10) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 903c94nAKEUCMz ;
	Sun, 20 Nov 2011 19:34:13 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DC3C118637;
	Sun, 20 Nov 2011 19:34:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 827fcaf0d610dd0c54d3f1f305b2b8f12bd4240a
Message-Id: <827fcaf0d610dd0c54d3.1321814060@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15 of 20] xenpaging: use guests tot_pages as
	working target
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804965 -3600
# Node ID 827fcaf0d610dd0c54d3f1f305b2b8f12bd4240a
# Parent  303d1521463bda6431cc0001d8755dd681e67a0d
xenpaging: use guests tot_pages as working target

This change reverses the task of xenpaging. Before this change a fixed number
of pages was paged out. With this change the guest will not have access to
more than the given number of pages at the same time.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 303d1521463b -r 827fcaf0d610 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -71,7 +71,6 @@ int policy_init(xenpaging_t *paging)
 
     /* Start in the middle to avoid paging during BIOS startup */
     current_gfn = max_pages / 2;
-    current_gfn -= paging->num_pages / 2;
 
     rc = 0;
  out:
diff -r 303d1521463b -r 827fcaf0d610 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -136,6 +136,21 @@ err:
     return rc;
 }
 
+static int xenpaging_get_tot_pages(xenpaging_t *paging)
+{
+    xc_interface *xch = paging->xc_handle;
+    xc_domaininfo_t domain_info;
+    int rc;
+
+    rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1, &domain_info);
+    if ( rc != 1 )
+    {
+        PERROR("Error getting domain info");
+        return -1;
+    }
+    return domain_info.tot_pages;
+}
+
 static void *init_page(void)
 {
     void *buffer;
@@ -161,7 +176,7 @@ static void *init_page(void)
     return NULL;
 }
 
-static xenpaging_t *xenpaging_init(domid_t domain_id, int num_pages)
+static xenpaging_t *xenpaging_init(domid_t domain_id, int target_tot_pages)
 {
     xenpaging_t *paging;
     xc_domaininfo_t domain_info;
@@ -296,12 +311,7 @@ static xenpaging_t *xenpaging_init(domid
     }
     DPRINTF("max_pages = %d\n", paging->max_pages);
 
-    if ( num_pages < 0 || num_pages > paging->max_pages )
-    {
-        num_pages = paging->max_pages;
-        DPRINTF("setting num_pages to %d\n", num_pages);
-    }
-    paging->num_pages = num_pages;
+    paging->target_tot_pages = target_tot_pages;
 
     /* Initialise policy */
     rc = policy_init(paging);
@@ -648,7 +658,9 @@ int main(int argc, char *argv[])
     xenpaging_victim_t *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
+    int num, prev_num = 0;
     int i;
+    int tot_pages;
     int rc = -1;
     int rc1;
     xc_interface *xch;
@@ -659,7 +671,7 @@ int main(int argc, char *argv[])
 
     if ( argc != 3 )
     {
-        fprintf(stderr, "Usage: %s <domain_id> <num_pages>\n", argv[0]);
+        fprintf(stderr, "Usage: %s <domain_id> <tot_pages>\n", argv[0]);
         return -1;
     }
 
@@ -672,7 +684,7 @@ int main(int argc, char *argv[])
     }
     xch = paging->xc_handle;
 
-    DPRINTF("starting %s %u %d\n", argv[0], paging->mem_event.domain_id, paging->num_pages);
+    DPRINTF("starting %s %u %d\n", argv[0], paging->mem_event.domain_id, paging->target_tot_pages);
 
     /* Open file */
     sprintf(filename, "page_cache_%u", paging->mem_event.domain_id);
@@ -704,9 +716,6 @@ int main(int argc, char *argv[])
     /* listen for page-in events to stop pager */
     create_page_in_thread(paging);
 
-    i = evict_pages(paging, fd, victims, paging->num_pages);
-    DPRINTF("%d pages evicted. Done.\n", i);
-
     /* Swap pages in and out */
     while ( 1 )
     {
@@ -771,12 +780,8 @@ int main(int argc, char *argv[])
                     goto out;
                 }
 
-                /* Evict a new page to replace the one we just paged in,
-                 * or clear this pagefile slot on exit */
-                if ( interrupted )
-                    victims[i].gfn = INVALID_MFN;
-                else
-                    evict_victim(paging, &victims[i], fd, i);
+                /* Clear this pagefile slot */
+                victims[i].gfn = INVALID_MFN;
             }
             else
             {
@@ -823,6 +828,43 @@ int main(int argc, char *argv[])
         if ( interrupted )
             break;
 
+        /* Check if the target has been reached already */
+        tot_pages = xenpaging_get_tot_pages(paging);
+        if ( tot_pages < 0 )
+            goto out;
+
+        /* Resume all pages if paging is disabled or no target was set */
+        if ( paging->target_tot_pages == 0 )
+        {
+            if ( paging->num_paged_out )
+                resume_pages(paging, paging->num_paged_out);
+        }
+        /* Evict more pages if target not reached */
+        else if ( tot_pages > paging->target_tot_pages )
+        {
+            num = tot_pages - paging->target_tot_pages;
+            if ( num != prev_num )
+            {
+                DPRINTF("Need to evict %d pages to reach %d target_tot_pages\n", num, paging->target_tot_pages);
+                prev_num = num;
+            }
+            /* Limit the number of evicts to be able to process page-in requests */
+            if ( num > 42 )
+                num = 42;
+            evict_pages(paging, fd, victims, num);
+        }
+        /* Resume some pages if target not reached */
+        else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
+        {
+            num = paging->target_tot_pages - tot_pages;
+            if ( num != prev_num )
+            {
+                DPRINTF("Need to resume %d pages to reach %d target_tot_pages\n", num, paging->target_tot_pages);
+                prev_num = num;
+            }
+            resume_pages(paging, num);
+        }
+
     }
     DPRINTF("xenpaging got signal %d\n", interrupted);
 
diff -r 303d1521463b -r 827fcaf0d610 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -50,7 +50,7 @@ typedef struct xenpaging {
     /* number of pages for which data structures were allocated */
     int max_pages;
     int num_paged_out;
-    int num_pages;
+    int target_tot_pages;
     int policy_mru_size;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 } xenpaging_t;

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEB-0002mI-Oi; Sun, 20 Nov 2011 18:34:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCEB-0002fP-48
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1321814068!4274337!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26765 invoked from network); 20 Nov 2011 18:34:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:34:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814068; l=2472;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=jprWPiXTvcZlUH3TSDmAsRERKoQ=;
	b=V9JDFE+NIIA7XuZKYp5zS1k330G9Q0T0YQXSWDuCJ5EhOMyKv0AH63AZwmZWMANrPrt
	SLTH6LuGA0CRyV7KKiKiXOvHdTjwKJRSIe8M7FX3wQSyoqzPf9KFdQJj8zwzNXXFrq9b1
	ixnwlSb5kZoR4QYVQykALaNvKZOnbqZaNX4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (cohen mo63) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 2063cbnAKHfalQ ;
	Sun, 20 Nov 2011 19:34:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 18E6018636;
	Sun, 20 Nov 2011 19:34:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: c0c01de70558deca53a338b8c0956b56900c2257
Message-Id: <c0c01de70558deca53a3.1321814050@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05 of 20] xenpaging: print gfn in failure case
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804901 -3600
# Node ID c0c01de70558deca53a338b8c0956b56900c2257
# Parent  0bc6eb35c8bf6d09dc13f1fedb70874c1962f95d
xenpaging: print gfn in failure case

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0bc6eb35c8bf -r c0c01de70558 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -444,7 +444,7 @@ static int xenpaging_evict_page(xenpagin
                                 PROT_READ | PROT_WRITE, &gfn, 1);
     if ( page == NULL )
     {
-        PERROR("Error mapping page");
+        PERROR("Error mapping page %lx", victim->gfn);
         goto out;
     }
 
@@ -452,7 +452,7 @@ static int xenpaging_evict_page(xenpagin
     ret = write_page(fd, page, i);
     if ( ret != 0 )
     {
-        PERROR("Error copying page");
+        PERROR("Error copying page %lx", victim->gfn);
         munmap(page, PAGE_SIZE);
         goto out;
     }
@@ -464,7 +464,7 @@ static int xenpaging_evict_page(xenpagin
                               victim->gfn);
     if ( ret != 0 )
     {
-        PERROR("Error evicting page");
+        PERROR("Error evicting page %lx", victim->gfn);
         goto out;
     }
 
@@ -520,7 +520,7 @@ static int xenpaging_populate_page(xenpa
                 sleep(1);
                 continue;
             }
-            PERROR("Error preparing for page in");
+            PERROR("Error preparing %"PRI_xen_pfn" for page-in", gfn);
             goto out_map;
         }
     }
@@ -532,7 +532,7 @@ static int xenpaging_populate_page(xenpa
                                 PROT_READ | PROT_WRITE, &gfn, 1);
     if ( page == NULL )
     {
-        PERROR("Error mapping page: page is null");
+        PERROR("Error mapping page %"PRI_xen_pfn": page is null", gfn);
         goto out_map;
     }
 
@@ -540,7 +540,7 @@ static int xenpaging_populate_page(xenpa
     ret = read_page(fd, page, i);
     if ( ret != 0 )
     {
-        PERROR("Error reading page");
+        PERROR("Error reading page %"PRI_xen_pfn"", gfn);
         goto out;
     }
 
@@ -710,7 +710,7 @@ int main(int argc, char *argv[])
                     rc = xenpaging_populate_page(paging, req.gfn, fd, i);
                     if ( rc != 0 )
                     {
-                        PERROR("Error populating page");
+                        PERROR("Error populating page %"PRIx64"", req.gfn);
                         goto out;
                     }
                 }
@@ -723,7 +723,7 @@ int main(int argc, char *argv[])
                 rc = xenpaging_resume_page(paging, &rsp, 1);
                 if ( rc != 0 )
                 {
-                    PERROR("Error resuming page");
+                    PERROR("Error resuming page %"PRIx64"", req.gfn);
                     goto out;
                 }
 
@@ -754,7 +754,7 @@ int main(int argc, char *argv[])
                     rc = xenpaging_resume_page(paging, &rsp, 0);
                     if ( rc != 0 )
                     {
-                        PERROR("Error resuming");
+                        PERROR("Error resuming page %"PRIx64"", req.gfn);
                         goto out;
                     }
                 }

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCDo-0002Z6-7o; Sun, 20 Nov 2011 18:34:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDm-0002Yz-My
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321814034!46368765!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22857 invoked from network); 20 Nov 2011 18:33:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:33:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814048; l=821;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=G+9aoDJOVJeurO3zcMsdSo5Jd7c=;
	b=pIDx9JjUYJ3buXJ+rABL+2TV/sLIp6o82817ERam36OiHDSttzKfdmp163HywTNDasM
	iPMSPE6XstJ9T4ZzYqBaKgpXlhXHnZeIxsrfyce4BDXel/fAKxnTzjx5dTRgzRpILaF4m
	RI6BA6QHXaI5+U9KyE0Rl7MiBMNcI76BtV8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (klopstock mo4) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id h04ccfnAKI5xeY ;
	Sun, 20 Nov 2011 19:34:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 95F2818638;
	Sun, 20 Nov 2011 19:34:06 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 00f6e1294ae25a13820af1582170305b27eb69aa
Message-Id: <00f6e1294ae25a13820a.1321814047@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02 of 20] xenpaging: remove obsolete comment in
	resume path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804880 -3600
# Node ID 00f6e1294ae25a13820af1582170305b27eb69aa
# Parent  b80e53a0d6f06ac6084765961127319990371dca
xenpaging: remove obsolete comment in resume path

Remove stale comment.
If a page was populated several times the vcpu is paused and
xenpaging has to unpause it again.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b80e53a0d6f0 -r 00f6e1294ae2 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -744,7 +744,6 @@ int main(int argc, char *argv[])
                         !!(req.flags & MEM_EVENT_FLAG_EVICT_FAIL) );
 
                 /* Tell Xen to resume the vcpu */
-                /* XXX: Maybe just check if the vcpu was paused? */
                 if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
                 {
                     /* Prepare the response */

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCDz-0002bJ-6b; Sun, 20 Nov 2011 18:34:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDx-0002ao-WD
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321814028!57961600!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19776 invoked from network); 20 Nov 2011 18:33:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:33:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814060; l=849;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=eoEuiGJwGrn0cX5KZAMxYLCoi/s=;
	b=rCH8OAG8+jVwIUEBh+RSr6tOThzAeF6NIwqfYFb89VVGf1dN97UfsTQKUvwu1J14euW
	aCt3+4T8hmAMnC8dPMyYzzWVu9bEBAaafPeGqyLEOWCpfbmTRRatCvSJthLHQg4YGOZ7t
	FtbrblP1pNCSrXx/OKwjDcwDpDnXuFWAzAY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo60) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x03418nAKG4bw9 ;
	Sun, 20 Nov 2011 19:34:12 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3747518639;
	Sun, 20 Nov 2011 19:34:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3fe020b22882c369855dab3f3ebb88c02568e917
Message-Id: <3fe020b22882c369855d.1321814058@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13 of 20] xenpaging: install into LIBEXEC dir
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804962 -3600
# Node ID 3fe020b22882c369855dab3f3ebb88c02568e917
# Parent  1e343a57860ea0d75d862076eec695b81219092e
xenpaging: install into LIBEXEC dir

In preparation of upcoming libxl integration,
move xenpaging binary from /usr/sbin/ to /usr/lib/xen/bin/

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1e343a57860e -r 3fe020b22882 tools/xenpaging/Makefile
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -24,8 +24,8 @@ xenpaging: $(OBJS)
 
 install: all
 	$(INSTALL_DIR) $(DESTDIR)/var/lib/xen/xenpaging
-	$(INSTALL_DIR) $(DESTDIR)$(SBINDIR)
-	$(INSTALL_PROG) $(IBINS) $(DESTDIR)$(SBINDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)
+	$(INSTALL_PROG) $(IBINS) $(DESTDIR)$(LIBEXEC)
 
 clean:
 	rm -f *.o *~ $(DEPS) xen TAGS $(IBINS) $(LIB)

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE5-0002fZ-W8; Sun, 20 Nov 2011 18:34:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE4-0002e2-AK
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321814024!57533831!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29619 invoked from network); 20 Nov 2011 18:33:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:33:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814066; l=1217;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=NmMJoJfIgMnIJ36ar58ow7N6dQQ=;
	b=oZDZkP9hL9oEsetuhWHbOL4rF9W0i9ZInpTSeOJep/UkqPM2ENyiyfTKoKRxLe0JDT+
	c5Ev1gRboVgoer1SKvFtapFGdYdb4sMhGtuTO7RPXCR7Qrj1hdneg5mU6gQf0NFe27hdD
	qwDa+35ihPNJJLrYAp04kPPYLUSOt22ZEHw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (klopstock mo16) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L03f11nAKEkfte ;
	Sun, 20 Nov 2011 19:34:10 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 377F818636;
	Sun, 20 Nov 2011 19:34:08 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: cc72e36fa9c3a6a467ad12188551f6f233185fc9
Message-Id: <cc72e36fa9c3a6a467ad.1321814055@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:15 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10 of 20] xenpaging: improve mainloop exit
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804959 -3600
# Node ID cc72e36fa9c3a6a467ad12188551f6f233185fc9
# Parent  35a65cd961e7ba04350ce0fe539f677dd4722b93
xenpaging: improve mainloop exit handling

Remove the if/else logic to exit from the in case a signal arrives.
Update comments.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 35a65cd961e7 -r cc72e36fa9c3 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -805,7 +805,7 @@ int main(int argc, char *argv[])
             }
         }
 
-        /* Write all pages back into the guest */
+        /* If interrupted, write all pages back into the guest */
         if ( interrupted == SIGTERM || interrupted == SIGINT )
         {
             /* If no more pages to process, exit loop. */
@@ -814,13 +814,15 @@ int main(int argc, char *argv[])
             
             /* One more round if there are still pages to process. */
             resume_pages(paging, paging->num_paged_out);
+
+            /* Resume main loop */
+            continue;
         }
-        else
-        {
-            /* Exit on any other signal */
-            if ( interrupted )
-                break;
-        }
+
+        /* Exit main loop on any other signal */
+        if ( interrupted )
+            break;
+
     }
     DPRINTF("xenpaging got signal %d\n", interrupted);
 

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE3-0002dq-IS; Sun, 20 Nov 2011 18:34:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE2-0002aZ-0L
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1321814059!5601622!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9675 invoked from network); 20 Nov 2011 18:34:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:34:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814059; l=1853;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=pETxxtZ1PQL7DFoZq2T22c7XQbI=;
	b=bgSyIK6Ja6Q+9U3Tk3sJX+w8lf25uYQBWfbdTDFfcsjdw8UrnicpbdqFARdTIrlxp3K
	sFJIhvkIroGvGXnqDq2CJooPE9LCVsSao0WKYgMhUQQ7HuAuBT7Sa0TiF8pDs+81A/Xgv
	bU/3OzzlzKn8ATpN5MUYr1hjfdPSjuanlyI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (jimi mo29) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u04229nAKEWeJt ;
	Sun, 20 Nov 2011 19:34:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E5E321863A;
	Sun, 20 Nov 2011 19:34:06 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 0bc6eb35c8bf6d09dc13f1fedb70874c1962f95d
Message-Id: <0bc6eb35c8bf6d09dc13.1321814049@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04 of 20] xenpaging: simplify file_op
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804899 -3600
# Node ID 0bc6eb35c8bf6d09dc13f1fedb70874c1962f95d
# Parent  b6c4a6f4f1f77b2471e4aa5fd23b375761691f79
xenpaging: simplify file_op

Catch lseek() errors.
Use -1 as return value and let caller read errno.
Remove const casts from buffer pointers, the page is writeable.
Use wrapper for write() which matches the read() prototype.
Remove unused stdarg.h inclusion.
Remove unused macro.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b6c4a6f4f1f7 -r 0bc6eb35c8bf tools/xenpaging/file_ops.c
--- a/tools/xenpaging/file_ops.c
+++ b/tools/xenpaging/file_ops.c
@@ -21,55 +21,44 @@
 
 
 #include <unistd.h>
-#include <stdarg.h>
 #include <xc_private.h>
 
-
-#define page_offset(_pfn)     (((off_t)(_pfn)) << PAGE_SHIFT)
-
-
 static int file_op(int fd, void *page, int i,
-                   ssize_t (*fn)(int, const void *, size_t))
+                   ssize_t (*fn)(int, void *, size_t))
 {
     off_t seek_ret;
-    int total;
+    int total = 0;
     int bytes;
-    int ret;
 
     seek_ret = lseek(fd, i << PAGE_SHIFT, SEEK_SET);
+    if ( seek_ret == (off_t)-1 )
+        return -1;
 
-    total = 0;
     while ( total < PAGE_SIZE )
     {
         bytes = fn(fd, page + total, PAGE_SIZE - total);
         if ( bytes <= 0 )
-        {
-            ret = -errno;
-            goto err;
-        }
+            return -1;
 
         total += bytes;
     }
 
     return 0;
-
- err:
-    return ret;
 }
 
-static ssize_t my_read(int fd, const void *buf, size_t count)
+static ssize_t my_write(int fd, void *buf, size_t count)
 {
-    return read(fd, (void *)buf, count);
+    return write(fd, buf, count);
 }
 
 int read_page(int fd, void *page, int i)
 {
-    return file_op(fd, page, i, &my_read);
+    return file_op(fd, page, i, &read);
 }
 
 int write_page(int fd, void *page, int i)
 {
-    return file_op(fd, page, i, &write);
+    return file_op(fd, page, i, &my_write);
 }
 
 

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE6-0002gZ-SB; Sun, 20 Nov 2011 18:34:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE5-0002bd-3o
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321814029!44653316!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6018 invoked from network); 20 Nov 2011 18:33:50 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:33:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814062; l=5383;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=q35pXBsrAYgTCXYoW5nH+AhcNmQ=;
	b=n6sxXB1jp7hu79DNN0NRAJjJimf9KMbXFVnqdRf81LZizVUwcLFOSOOoPB8+snb0NKs
	qbdI91oP4TS/atOwnaiIVhYShryj5XjCrHh11MIa/wnxIcpwWIPwbac6RK/c1OygwHYXY
	IbCqwd9nMAXRObOHnmyEfZF9zeWAjk/qBY4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (cohen mo10) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 903c94nAKEUCMz ;
	Sun, 20 Nov 2011 19:34:13 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DC3C118637;
	Sun, 20 Nov 2011 19:34:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 827fcaf0d610dd0c54d3f1f305b2b8f12bd4240a
Message-Id: <827fcaf0d610dd0c54d3.1321814060@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15 of 20] xenpaging: use guests tot_pages as
	working target
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804965 -3600
# Node ID 827fcaf0d610dd0c54d3f1f305b2b8f12bd4240a
# Parent  303d1521463bda6431cc0001d8755dd681e67a0d
xenpaging: use guests tot_pages as working target

This change reverses the task of xenpaging. Before this change a fixed number
of pages was paged out. With this change the guest will not have access to
more than the given number of pages at the same time.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 303d1521463b -r 827fcaf0d610 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -71,7 +71,6 @@ int policy_init(xenpaging_t *paging)
 
     /* Start in the middle to avoid paging during BIOS startup */
     current_gfn = max_pages / 2;
-    current_gfn -= paging->num_pages / 2;
 
     rc = 0;
  out:
diff -r 303d1521463b -r 827fcaf0d610 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -136,6 +136,21 @@ err:
     return rc;
 }
 
+static int xenpaging_get_tot_pages(xenpaging_t *paging)
+{
+    xc_interface *xch = paging->xc_handle;
+    xc_domaininfo_t domain_info;
+    int rc;
+
+    rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1, &domain_info);
+    if ( rc != 1 )
+    {
+        PERROR("Error getting domain info");
+        return -1;
+    }
+    return domain_info.tot_pages;
+}
+
 static void *init_page(void)
 {
     void *buffer;
@@ -161,7 +176,7 @@ static void *init_page(void)
     return NULL;
 }
 
-static xenpaging_t *xenpaging_init(domid_t domain_id, int num_pages)
+static xenpaging_t *xenpaging_init(domid_t domain_id, int target_tot_pages)
 {
     xenpaging_t *paging;
     xc_domaininfo_t domain_info;
@@ -296,12 +311,7 @@ static xenpaging_t *xenpaging_init(domid
     }
     DPRINTF("max_pages = %d\n", paging->max_pages);
 
-    if ( num_pages < 0 || num_pages > paging->max_pages )
-    {
-        num_pages = paging->max_pages;
-        DPRINTF("setting num_pages to %d\n", num_pages);
-    }
-    paging->num_pages = num_pages;
+    paging->target_tot_pages = target_tot_pages;
 
     /* Initialise policy */
     rc = policy_init(paging);
@@ -648,7 +658,9 @@ int main(int argc, char *argv[])
     xenpaging_victim_t *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
+    int num, prev_num = 0;
     int i;
+    int tot_pages;
     int rc = -1;
     int rc1;
     xc_interface *xch;
@@ -659,7 +671,7 @@ int main(int argc, char *argv[])
 
     if ( argc != 3 )
     {
-        fprintf(stderr, "Usage: %s <domain_id> <num_pages>\n", argv[0]);
+        fprintf(stderr, "Usage: %s <domain_id> <tot_pages>\n", argv[0]);
         return -1;
     }
 
@@ -672,7 +684,7 @@ int main(int argc, char *argv[])
     }
     xch = paging->xc_handle;
 
-    DPRINTF("starting %s %u %d\n", argv[0], paging->mem_event.domain_id, paging->num_pages);
+    DPRINTF("starting %s %u %d\n", argv[0], paging->mem_event.domain_id, paging->target_tot_pages);
 
     /* Open file */
     sprintf(filename, "page_cache_%u", paging->mem_event.domain_id);
@@ -704,9 +716,6 @@ int main(int argc, char *argv[])
     /* listen for page-in events to stop pager */
     create_page_in_thread(paging);
 
-    i = evict_pages(paging, fd, victims, paging->num_pages);
-    DPRINTF("%d pages evicted. Done.\n", i);
-
     /* Swap pages in and out */
     while ( 1 )
     {
@@ -771,12 +780,8 @@ int main(int argc, char *argv[])
                     goto out;
                 }
 
-                /* Evict a new page to replace the one we just paged in,
-                 * or clear this pagefile slot on exit */
-                if ( interrupted )
-                    victims[i].gfn = INVALID_MFN;
-                else
-                    evict_victim(paging, &victims[i], fd, i);
+                /* Clear this pagefile slot */
+                victims[i].gfn = INVALID_MFN;
             }
             else
             {
@@ -823,6 +828,43 @@ int main(int argc, char *argv[])
         if ( interrupted )
             break;
 
+        /* Check if the target has been reached already */
+        tot_pages = xenpaging_get_tot_pages(paging);
+        if ( tot_pages < 0 )
+            goto out;
+
+        /* Resume all pages if paging is disabled or no target was set */
+        if ( paging->target_tot_pages == 0 )
+        {
+            if ( paging->num_paged_out )
+                resume_pages(paging, paging->num_paged_out);
+        }
+        /* Evict more pages if target not reached */
+        else if ( tot_pages > paging->target_tot_pages )
+        {
+            num = tot_pages - paging->target_tot_pages;
+            if ( num != prev_num )
+            {
+                DPRINTF("Need to evict %d pages to reach %d target_tot_pages\n", num, paging->target_tot_pages);
+                prev_num = num;
+            }
+            /* Limit the number of evicts to be able to process page-in requests */
+            if ( num > 42 )
+                num = 42;
+            evict_pages(paging, fd, victims, num);
+        }
+        /* Resume some pages if target not reached */
+        else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
+        {
+            num = paging->target_tot_pages - tot_pages;
+            if ( num != prev_num )
+            {
+                DPRINTF("Need to resume %d pages to reach %d target_tot_pages\n", num, paging->target_tot_pages);
+                prev_num = num;
+            }
+            resume_pages(paging, num);
+        }
+
     }
     DPRINTF("xenpaging got signal %d\n", interrupted);
 
diff -r 303d1521463b -r 827fcaf0d610 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -50,7 +50,7 @@ typedef struct xenpaging {
     /* number of pages for which data structures were allocated */
     int max_pages;
     int num_paged_out;
-    int num_pages;
+    int target_tot_pages;
     int policy_mru_size;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 } xenpaging_t;

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCDw-0002aP-B5; Sun, 20 Nov 2011 18:34:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDu-0002ZG-Jg
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1321814051!3866918!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16888 invoked from network); 20 Nov 2011 18:34:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814051; l=3990;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=1YOG8WAHGZE//OmsIfQu7qC26vk=;
	b=VWLKiOFyzY3czW+51dViUVyqK1xtOnBljRhO71Fyw8zgqi8dnb7pJ802s6aAq0iPz8x
	7tE2cuZLcJPcjBLw4PNYzBJ1mjsr04Rdj806RAhzLrqvW88y8DpCFaqVu2EUo6KvznswZ
	GiBhNZ8Qb8roxvFXHJtYxdD/3Eo5/n9yLfk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (fruni mo19) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C05945nAKILLO5 ;
	Sun, 20 Nov 2011 19:34:08 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 88DA418638;
	Sun, 20 Nov 2011 19:34:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 98c0a058f05634833ccb9fb6671ee94cde444fa1
Message-Id: <98c0a058f05634833ccb.1321814052@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07 of 20] xenpaging: remove xc_dominfo_t from
	paging_t
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804956 -3600
# Node ID 98c0a058f05634833ccb9fb6671ee94cde444fa1
# Parent  3c4e8b05da8b15d399f6813cf5f9f365dd0b9a17
xenpaging: remove xc_dominfo_t from paging_t

Remove xc_dominfo_t from paging_t, record only max_pages.
This value is used to setup internal data structures.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3c4e8b05da8b -r 98c0a058f056 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -41,17 +41,17 @@ int policy_init(xenpaging_t *paging)
     int i;
     int rc = -ENOMEM;
 
+    max_pages = paging->max_pages;
+
     /* Allocate bitmap for pages not to page out */
-    bitmap = bitmap_alloc(paging->domain_info->max_pages);
+    bitmap = bitmap_alloc(max_pages);
     if ( !bitmap )
         goto out;
     /* Allocate bitmap to track unusable pages */
-    unconsumed = bitmap_alloc(paging->domain_info->max_pages);
+    unconsumed = bitmap_alloc(max_pages);
     if ( !unconsumed )
         goto out;
 
-    max_pages = paging->domain_info->max_pages;
-
     /* Initialise MRU list of paged in pages */
     if ( paging->policy_mru_size > 0 )
         mru_size = paging->policy_mru_size;
diff -r 3c4e8b05da8b -r 98c0a058f056 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -164,6 +164,7 @@ static void *init_page(void)
 static xenpaging_t *xenpaging_init(domid_t domain_id, int num_pages)
 {
     xenpaging_t *paging;
+    xc_domaininfo_t domain_info;
     xc_interface *xch;
     xentoollog_logger *dbg = NULL;
     char *p;
@@ -275,34 +276,29 @@ static xenpaging_t *xenpaging_init(domid
 
     paging->mem_event.port = rc;
 
-    /* Get domaininfo */
-    paging->domain_info = malloc(sizeof(xc_domaininfo_t));
-    if ( paging->domain_info == NULL )
-    {
-        PERROR("Error allocating memory for domain info");
-        goto err;
-    }
-
     rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1,
-                               paging->domain_info);
+                               &domain_info);
     if ( rc != 1 )
     {
         PERROR("Error getting domain info");
         goto err;
     }
 
+    /* Record number of max_pages */
+    paging->max_pages = domain_info.max_pages;
+
     /* Allocate bitmap for tracking pages that have been paged out */
-    paging->bitmap = bitmap_alloc(paging->domain_info->max_pages);
+    paging->bitmap = bitmap_alloc(paging->max_pages);
     if ( !paging->bitmap )
     {
         PERROR("Error allocating bitmap");
         goto err;
     }
-    DPRINTF("max_pages = %"PRIx64"\n", paging->domain_info->max_pages);
+    DPRINTF("max_pages = %d\n", paging->max_pages);
 
-    if ( num_pages < 0 || num_pages > paging->domain_info->max_pages )
+    if ( num_pages < 0 || num_pages > paging->max_pages )
     {
-        num_pages = paging->domain_info->max_pages;
+        num_pages = paging->max_pages;
         DPRINTF("setting num_pages to %d\n", num_pages);
     }
     paging->num_pages = num_pages;
@@ -337,7 +333,6 @@ static xenpaging_t *xenpaging_init(domid
         }
 
         free(paging->bitmap);
-        free(paging->domain_info);
         free(paging);
     }
 
@@ -765,7 +760,7 @@ int main(int argc, char *argv[])
         if ( interrupted == SIGTERM || interrupted == SIGINT )
         {
             int num = 0;
-            for ( i = 0; i < paging->domain_info->max_pages; i++ )
+            for ( i = 0; i < paging->max_pages; i++ )
             {
                 if ( test_bit(i, paging->bitmap) )
                 {
@@ -781,7 +776,7 @@ int main(int argc, char *argv[])
              */
             if ( num )
                 page_in_trigger();
-            else if ( i == paging->domain_info->max_pages )
+            else if ( i == paging->max_pages )
                 break;
         }
         else
diff -r 3c4e8b05da8b -r 98c0a058f056 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -44,11 +44,11 @@ typedef struct xenpaging {
     xc_interface *xc_handle;
     struct xs_handle *xs_handle;
 
-    xc_domaininfo_t    *domain_info;
-
     unsigned long *bitmap;
 
     mem_event_t mem_event;
+    /* number of pages for which data structures were allocated */
+    int max_pages;
     int num_pages;
     int policy_mru_size;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCDo-0002Z6-7o; Sun, 20 Nov 2011 18:34:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDm-0002Yz-My
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321814034!46368765!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22857 invoked from network); 20 Nov 2011 18:33:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:33:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814048; l=821;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=G+9aoDJOVJeurO3zcMsdSo5Jd7c=;
	b=pIDx9JjUYJ3buXJ+rABL+2TV/sLIp6o82817ERam36OiHDSttzKfdmp163HywTNDasM
	iPMSPE6XstJ9T4ZzYqBaKgpXlhXHnZeIxsrfyce4BDXel/fAKxnTzjx5dTRgzRpILaF4m
	RI6BA6QHXaI5+U9KyE0Rl7MiBMNcI76BtV8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (klopstock mo4) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id h04ccfnAKI5xeY ;
	Sun, 20 Nov 2011 19:34:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 95F2818638;
	Sun, 20 Nov 2011 19:34:06 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 00f6e1294ae25a13820af1582170305b27eb69aa
Message-Id: <00f6e1294ae25a13820a.1321814047@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02 of 20] xenpaging: remove obsolete comment in
	resume path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804880 -3600
# Node ID 00f6e1294ae25a13820af1582170305b27eb69aa
# Parent  b80e53a0d6f06ac6084765961127319990371dca
xenpaging: remove obsolete comment in resume path

Remove stale comment.
If a page was populated several times the vcpu is paused and
xenpaging has to unpause it again.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b80e53a0d6f0 -r 00f6e1294ae2 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -744,7 +744,6 @@ int main(int argc, char *argv[])
                         !!(req.flags & MEM_EVENT_FLAG_EVICT_FAIL) );
 
                 /* Tell Xen to resume the vcpu */
-                /* XXX: Maybe just check if the vcpu was paused? */
                 if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
                 {
                     /* Prepare the response */

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCDz-0002bJ-6b; Sun, 20 Nov 2011 18:34:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDx-0002ao-WD
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1321814028!57961600!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19776 invoked from network); 20 Nov 2011 18:33:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:33:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814060; l=849;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=eoEuiGJwGrn0cX5KZAMxYLCoi/s=;
	b=rCH8OAG8+jVwIUEBh+RSr6tOThzAeF6NIwqfYFb89VVGf1dN97UfsTQKUvwu1J14euW
	aCt3+4T8hmAMnC8dPMyYzzWVu9bEBAaafPeGqyLEOWCpfbmTRRatCvSJthLHQg4YGOZ7t
	FtbrblP1pNCSrXx/OKwjDcwDpDnXuFWAzAY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo60) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x03418nAKG4bw9 ;
	Sun, 20 Nov 2011 19:34:12 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3747518639;
	Sun, 20 Nov 2011 19:34:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3fe020b22882c369855dab3f3ebb88c02568e917
Message-Id: <3fe020b22882c369855d.1321814058@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13 of 20] xenpaging: install into LIBEXEC dir
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804962 -3600
# Node ID 3fe020b22882c369855dab3f3ebb88c02568e917
# Parent  1e343a57860ea0d75d862076eec695b81219092e
xenpaging: install into LIBEXEC dir

In preparation of upcoming libxl integration,
move xenpaging binary from /usr/sbin/ to /usr/lib/xen/bin/

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1e343a57860e -r 3fe020b22882 tools/xenpaging/Makefile
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -24,8 +24,8 @@ xenpaging: $(OBJS)
 
 install: all
 	$(INSTALL_DIR) $(DESTDIR)/var/lib/xen/xenpaging
-	$(INSTALL_DIR) $(DESTDIR)$(SBINDIR)
-	$(INSTALL_PROG) $(IBINS) $(DESTDIR)$(SBINDIR)
+	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)
+	$(INSTALL_PROG) $(IBINS) $(DESTDIR)$(LIBEXEC)
 
 clean:
 	rm -f *.o *~ $(DEPS) xen TAGS $(IBINS) $(LIB)

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE5-0002fZ-W8; Sun, 20 Nov 2011 18:34:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE4-0002e2-AK
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321814024!57533831!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29619 invoked from network); 20 Nov 2011 18:33:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:33:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814066; l=1217;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=NmMJoJfIgMnIJ36ar58ow7N6dQQ=;
	b=oZDZkP9hL9oEsetuhWHbOL4rF9W0i9ZInpTSeOJep/UkqPM2ENyiyfTKoKRxLe0JDT+
	c5Ev1gRboVgoer1SKvFtapFGdYdb4sMhGtuTO7RPXCR7Qrj1hdneg5mU6gQf0NFe27hdD
	qwDa+35ihPNJJLrYAp04kPPYLUSOt22ZEHw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (klopstock mo16) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L03f11nAKEkfte ;
	Sun, 20 Nov 2011 19:34:10 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 377F818636;
	Sun, 20 Nov 2011 19:34:08 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: cc72e36fa9c3a6a467ad12188551f6f233185fc9
Message-Id: <cc72e36fa9c3a6a467ad.1321814055@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:15 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10 of 20] xenpaging: improve mainloop exit
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804959 -3600
# Node ID cc72e36fa9c3a6a467ad12188551f6f233185fc9
# Parent  35a65cd961e7ba04350ce0fe539f677dd4722b93
xenpaging: improve mainloop exit handling

Remove the if/else logic to exit from the in case a signal arrives.
Update comments.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 35a65cd961e7 -r cc72e36fa9c3 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -805,7 +805,7 @@ int main(int argc, char *argv[])
             }
         }
 
-        /* Write all pages back into the guest */
+        /* If interrupted, write all pages back into the guest */
         if ( interrupted == SIGTERM || interrupted == SIGINT )
         {
             /* If no more pages to process, exit loop. */
@@ -814,13 +814,15 @@ int main(int argc, char *argv[])
             
             /* One more round if there are still pages to process. */
             resume_pages(paging, paging->num_paged_out);
+
+            /* Resume main loop */
+            continue;
         }
-        else
-        {
-            /* Exit on any other signal */
-            if ( interrupted )
-                break;
-        }
+
+        /* Exit main loop on any other signal */
+        if ( interrupted )
+            break;
+
     }
     DPRINTF("xenpaging got signal %d\n", interrupted);
 

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE3-0002dq-IS; Sun, 20 Nov 2011 18:34:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE2-0002aZ-0L
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1321814059!5601622!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9675 invoked from network); 20 Nov 2011 18:34:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:34:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814059; l=1853;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=pETxxtZ1PQL7DFoZq2T22c7XQbI=;
	b=bgSyIK6Ja6Q+9U3Tk3sJX+w8lf25uYQBWfbdTDFfcsjdw8UrnicpbdqFARdTIrlxp3K
	sFJIhvkIroGvGXnqDq2CJooPE9LCVsSao0WKYgMhUQQ7HuAuBT7Sa0TiF8pDs+81A/Xgv
	bU/3OzzlzKn8ATpN5MUYr1hjfdPSjuanlyI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (jimi mo29) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u04229nAKEWeJt ;
	Sun, 20 Nov 2011 19:34:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E5E321863A;
	Sun, 20 Nov 2011 19:34:06 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 0bc6eb35c8bf6d09dc13f1fedb70874c1962f95d
Message-Id: <0bc6eb35c8bf6d09dc13.1321814049@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:09 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04 of 20] xenpaging: simplify file_op
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804899 -3600
# Node ID 0bc6eb35c8bf6d09dc13f1fedb70874c1962f95d
# Parent  b6c4a6f4f1f77b2471e4aa5fd23b375761691f79
xenpaging: simplify file_op

Catch lseek() errors.
Use -1 as return value and let caller read errno.
Remove const casts from buffer pointers, the page is writeable.
Use wrapper for write() which matches the read() prototype.
Remove unused stdarg.h inclusion.
Remove unused macro.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b6c4a6f4f1f7 -r 0bc6eb35c8bf tools/xenpaging/file_ops.c
--- a/tools/xenpaging/file_ops.c
+++ b/tools/xenpaging/file_ops.c
@@ -21,55 +21,44 @@
 
 
 #include <unistd.h>
-#include <stdarg.h>
 #include <xc_private.h>
 
-
-#define page_offset(_pfn)     (((off_t)(_pfn)) << PAGE_SHIFT)
-
-
 static int file_op(int fd, void *page, int i,
-                   ssize_t (*fn)(int, const void *, size_t))
+                   ssize_t (*fn)(int, void *, size_t))
 {
     off_t seek_ret;
-    int total;
+    int total = 0;
     int bytes;
-    int ret;
 
     seek_ret = lseek(fd, i << PAGE_SHIFT, SEEK_SET);
+    if ( seek_ret == (off_t)-1 )
+        return -1;
 
-    total = 0;
     while ( total < PAGE_SIZE )
     {
         bytes = fn(fd, page + total, PAGE_SIZE - total);
         if ( bytes <= 0 )
-        {
-            ret = -errno;
-            goto err;
-        }
+            return -1;
 
         total += bytes;
     }
 
     return 0;
-
- err:
-    return ret;
 }
 
-static ssize_t my_read(int fd, const void *buf, size_t count)
+static ssize_t my_write(int fd, void *buf, size_t count)
 {
-    return read(fd, (void *)buf, count);
+    return write(fd, buf, count);
 }
 
 int read_page(int fd, void *page, int i)
 {
-    return file_op(fd, page, i, &my_read);
+    return file_op(fd, page, i, &read);
 }
 
 int write_page(int fd, void *page, int i)
 {
-    return file_op(fd, page, i, &write);
+    return file_op(fd, page, i, &my_write);
 }
 
 

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCDw-0002aP-B5; Sun, 20 Nov 2011 18:34:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDu-0002ZG-Jg
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1321814051!3866918!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16888 invoked from network); 20 Nov 2011 18:34:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814051; l=3990;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=1YOG8WAHGZE//OmsIfQu7qC26vk=;
	b=VWLKiOFyzY3czW+51dViUVyqK1xtOnBljRhO71Fyw8zgqi8dnb7pJ802s6aAq0iPz8x
	7tE2cuZLcJPcjBLw4PNYzBJ1mjsr04Rdj806RAhzLrqvW88y8DpCFaqVu2EUo6KvznswZ
	GiBhNZ8Qb8roxvFXHJtYxdD/3Eo5/n9yLfk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (fruni mo19) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C05945nAKILLO5 ;
	Sun, 20 Nov 2011 19:34:08 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 88DA418638;
	Sun, 20 Nov 2011 19:34:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 98c0a058f05634833ccb9fb6671ee94cde444fa1
Message-Id: <98c0a058f05634833ccb.1321814052@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07 of 20] xenpaging: remove xc_dominfo_t from
	paging_t
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804956 -3600
# Node ID 98c0a058f05634833ccb9fb6671ee94cde444fa1
# Parent  3c4e8b05da8b15d399f6813cf5f9f365dd0b9a17
xenpaging: remove xc_dominfo_t from paging_t

Remove xc_dominfo_t from paging_t, record only max_pages.
This value is used to setup internal data structures.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3c4e8b05da8b -r 98c0a058f056 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -41,17 +41,17 @@ int policy_init(xenpaging_t *paging)
     int i;
     int rc = -ENOMEM;
 
+    max_pages = paging->max_pages;
+
     /* Allocate bitmap for pages not to page out */
-    bitmap = bitmap_alloc(paging->domain_info->max_pages);
+    bitmap = bitmap_alloc(max_pages);
     if ( !bitmap )
         goto out;
     /* Allocate bitmap to track unusable pages */
-    unconsumed = bitmap_alloc(paging->domain_info->max_pages);
+    unconsumed = bitmap_alloc(max_pages);
     if ( !unconsumed )
         goto out;
 
-    max_pages = paging->domain_info->max_pages;
-
     /* Initialise MRU list of paged in pages */
     if ( paging->policy_mru_size > 0 )
         mru_size = paging->policy_mru_size;
diff -r 3c4e8b05da8b -r 98c0a058f056 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -164,6 +164,7 @@ static void *init_page(void)
 static xenpaging_t *xenpaging_init(domid_t domain_id, int num_pages)
 {
     xenpaging_t *paging;
+    xc_domaininfo_t domain_info;
     xc_interface *xch;
     xentoollog_logger *dbg = NULL;
     char *p;
@@ -275,34 +276,29 @@ static xenpaging_t *xenpaging_init(domid
 
     paging->mem_event.port = rc;
 
-    /* Get domaininfo */
-    paging->domain_info = malloc(sizeof(xc_domaininfo_t));
-    if ( paging->domain_info == NULL )
-    {
-        PERROR("Error allocating memory for domain info");
-        goto err;
-    }
-
     rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1,
-                               paging->domain_info);
+                               &domain_info);
     if ( rc != 1 )
     {
         PERROR("Error getting domain info");
         goto err;
     }
 
+    /* Record number of max_pages */
+    paging->max_pages = domain_info.max_pages;
+
     /* Allocate bitmap for tracking pages that have been paged out */
-    paging->bitmap = bitmap_alloc(paging->domain_info->max_pages);
+    paging->bitmap = bitmap_alloc(paging->max_pages);
     if ( !paging->bitmap )
     {
         PERROR("Error allocating bitmap");
         goto err;
     }
-    DPRINTF("max_pages = %"PRIx64"\n", paging->domain_info->max_pages);
+    DPRINTF("max_pages = %d\n", paging->max_pages);
 
-    if ( num_pages < 0 || num_pages > paging->domain_info->max_pages )
+    if ( num_pages < 0 || num_pages > paging->max_pages )
     {
-        num_pages = paging->domain_info->max_pages;
+        num_pages = paging->max_pages;
         DPRINTF("setting num_pages to %d\n", num_pages);
     }
     paging->num_pages = num_pages;
@@ -337,7 +333,6 @@ static xenpaging_t *xenpaging_init(domid
         }
 
         free(paging->bitmap);
-        free(paging->domain_info);
         free(paging);
     }
 
@@ -765,7 +760,7 @@ int main(int argc, char *argv[])
         if ( interrupted == SIGTERM || interrupted == SIGINT )
         {
             int num = 0;
-            for ( i = 0; i < paging->domain_info->max_pages; i++ )
+            for ( i = 0; i < paging->max_pages; i++ )
             {
                 if ( test_bit(i, paging->bitmap) )
                 {
@@ -781,7 +776,7 @@ int main(int argc, char *argv[])
              */
             if ( num )
                 page_in_trigger();
-            else if ( i == paging->domain_info->max_pages )
+            else if ( i == paging->max_pages )
                 break;
         }
         else
diff -r 3c4e8b05da8b -r 98c0a058f056 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -44,11 +44,11 @@ typedef struct xenpaging {
     xc_interface *xc_handle;
     struct xs_handle *xs_handle;
 
-    xc_domaininfo_t    *domain_info;
-
     unsigned long *bitmap;
 
     mem_event_t mem_event;
+    /* number of pages for which data structures were allocated */
+    int max_pages;
     int num_pages;
     int policy_mru_size;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE1-0002c9-20; Sun, 20 Nov 2011 18:34:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDz-0002Zn-3R
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321814041!46368775!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22981 invoked from network); 20 Nov 2011 18:34:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814056; l=2333;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=zkAHJIljiOKuwMYKxA1eNZrsqUQ=;
	b=F/o0Az6QO6MeFZcNhJTCdOUoQ13cMCwIISadDsxHTbiENdeQOc95c5UJtOF309Zp7hd
	0yWWeq8f/rgFwfq2ZNPfIhD8CMdmdPbp6KYlF/jigPzBm2fIobfyaQm2z1JE5JrajEROO
	mPZwnt/Q5uJTrQ4z7VSxcjpGCs0rjEy88S8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (fruni mo52) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id B07275nAKGUCuA ;
	Sun, 20 Nov 2011 19:34:12 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 94CBE18636;
	Sun, 20 Nov 2011 19:34:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 303d1521463bda6431cc0001d8755dd681e67a0d
Message-Id: <303d1521463bda6431cc.1321814059@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14 of 20] xenpaging: add XEN_PAGING_DIR /
 libxl_xenpaging_dir_path()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804963 -3600
# Node ID 303d1521463bda6431cc0001d8755dd681e67a0d
# Parent  3fe020b22882c369855dab3f3ebb88c02568e917
xenpaging: add XEN_PAGING_DIR / libxl_xenpaging_dir_path()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3fe020b22882 -r 303d1521463b Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -142,7 +142,7 @@ define buildmakevars2file-closure
 	$(foreach var,                                                      \
 	          SBINDIR BINDIR LIBEXEC LIBDIR SHAREDIR PRIVATE_BINDIR     \
 	          XENFIRMWAREDIR XEN_CONFIG_DIR XEN_SCRIPT_DIR XEN_LOCK_DIR \
-	          XEN_RUN_DIR,                                              \
+	          XEN_RUN_DIR XEN_PAGING_DIR,                               \
 	          echo "$(var)=\"$($(var))\"" >>$(1).tmp;)        \
 	$(call move-if-changed,$(1).tmp,$(1))
 endef
diff -r 3fe020b22882 -r 303d1521463b config/StdGNU.mk
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -53,10 +53,12 @@ ifeq ($(PREFIX),/usr)
 CONFIG_DIR = /etc
 XEN_LOCK_DIR = /var/lock
 XEN_RUN_DIR = /var/run/xen
+XEN_PAGING_DIR = /var/lib/xen/xenpaging
 else
 CONFIG_DIR = $(PREFIX)/etc
 XEN_LOCK_DIR = $(PREFIX)/var/lock
 XEN_RUN_DIR = $(PREFIX)/var/run/xen
+XEN_PAGING_DIR = $(PREFIX)/var/lib/xen/xenpaging
 endif
 
 SYSCONFIG_DIR = $(CONFIG_DIR)/$(CONFIG_LEAF_DIR)
diff -r 3fe020b22882 -r 303d1521463b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -633,6 +633,7 @@ const char *libxl_xen_config_dir_path(vo
 const char *libxl_xen_script_dir_path(void);
 const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
+const char *libxl_xenpaging_dir_path(void);
 
 #endif /* LIBXL_H */
 
diff -r 3fe020b22882 -r 303d1521463b tools/libxl/libxl_paths.c
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -70,6 +70,11 @@ const char *libxl_run_dir_path(void)
     return XEN_RUN_DIR;
 }
 
+const char *libxl_xenpaging_dir_path(void)
+{
+    return XEN_PAGING_DIR;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 3fe020b22882 -r 303d1521463b tools/xenpaging/Makefile
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -23,7 +23,7 @@ xenpaging: $(OBJS)
 	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) $(APPEND_LDFLAGS)
 
 install: all
-	$(INSTALL_DIR) $(DESTDIR)/var/lib/xen/xenpaging
+	$(INSTALL_DIR) $(DESTDIR)$(XEN_PAGING_DIR)
 	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)
 	$(INSTALL_PROG) $(IBINS) $(DESTDIR)$(LIBEXEC)
 

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE1-0002cV-FS; Sun, 20 Nov 2011 18:34:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDz-0002Zz-Ug
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321814057!3870831!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21024 invoked from network); 20 Nov 2011 18:34:17 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814056; l=7611;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=Bbzr8USnodc3tKYwzhbhe7GsGEE=;
	b=FtaVAl4GTh4dwOrht0HXR1vK47ZO4Tvc0AhTAlkG+YOw46BiWv7JGOugWoOcRuOqTdb
	bA5lIuxjwqhUABZr/cvloTGIjDXfIHgvGCeWdhCykwEc7luJqdsI9BIVUeSUwUwUVVS7U
	cNUJnImPX+vlc6+Rg5ug12WfvoKjvzYug/c=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (fruni mo30) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id n061f7nAKFZlMK ;
	Sun, 20 Nov 2011 19:34:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2BA201863A;
	Sun, 20 Nov 2011 19:34:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: deb016f351e55e924274b4ccfbb80cb71543fc3e
Message-Id: <deb016f351e55e924274.1321814062@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17 of 20] xenpaging: add cmdline interface for
	pager
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804968 -3600
# Node ID deb016f351e55e924274b4ccfbb80cb71543fc3e
# Parent  bbe679f21208fd8f3341e2d8556469c7b1e29d57
xenpaging: add cmdline interface for pager

Introduce a cmdline handling for the pager. This simplifies libxl support,
debug and mru_size are not passed via the environment anymore.
The new interface looks like this:

xenpaging [options] -f <pagefile> -d <domain_id>
options:
 -d <domid>     --domain=<domid>         numerical domain_id of guest. This option is required.
 -f <file>      --pagefile=<file>        pagefile to use. This option is required.
 -m <max_memkb> --max_memkb=<max_memkb>  maximum amount of memory to handle.
 -r <num>       --mru_size=<num>         number of paged-in pages to keep in memory.
 -d             --debug                  enable debug output.
 -h             --help                   this output.


Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r bbe679f21208 -r deb016f351e5 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -31,6 +31,7 @@
 #include <poll.h>
 #include <xc_private.h>
 #include <xs.h>
+#include <getopt.h>
 
 #include "xc_bitops.h"
 #include "file_ops.h"
@@ -42,12 +43,12 @@
 static char *watch_target_tot_pages;
 static char *dom_path;
 static char watch_token[16];
-static char filename[80];
+static char *filename;
 static int interrupted;
 
 static void unlink_pagefile(void)
 {
-    if ( filename[0] )
+    if ( filename && filename[0] )
     {
         unlink(filename);
         filename[0] = '\0';
@@ -201,11 +202,85 @@ static void *init_page(void)
     return NULL;
 }
 
-static xenpaging_t *xenpaging_init(domid_t domain_id, int target_tot_pages)
+static void usage(void)
+{
+    printf("usage:\n\n");
+
+    printf("  xenpaging [options] -f <pagefile> -d <domain_id>\n\n");
+
+    printf("options:\n");
+    printf(" -d <domid>     --domain=<domid>         numerical domain_id of guest. This option is required.\n");
+    printf(" -f <file>      --pagefile=<file>        pagefile to use. This option is required.\n");
+    printf(" -m <max_memkb> --max_memkb=<max_memkb>  maximum amount of memory to handle.\n");
+    printf(" -r <num>       --mru_size=<num>         number of paged-in pages to keep in memory.\n");
+    printf(" -v             --verbose                enable debug output.\n");
+    printf(" -h             --help                   this output.\n");
+}
+
+static int xenpaging_getopts(xenpaging_t *paging, int argc, char *argv[])
+{
+    int ch;
+    static const char sopts[] = "hvd:f:m:r:";
+    static const struct option lopts[] = {
+        {"help", 0, NULL, 'h'},
+        {"verbose", 0, NULL, 'v'},
+        {"domain", 1, NULL, 'd'},
+        {"pagefile", 1, NULL, 'f'},
+        {"mru_size", 1, NULL, 'm'},
+        { }
+    };
+
+    while ((ch = getopt_long(argc, argv, sopts, lopts, NULL)) != -1)
+    {
+        switch(ch) {
+        case 'd':
+            paging->mem_event.domain_id = atoi(optarg);
+            break;
+        case 'f':
+            filename = strdup(optarg);
+            break;
+        case 'm':
+            /* KiB to pages */
+            paging->max_pages = atoi(optarg) >> 2;
+            break;
+        case 'r':
+            paging->policy_mru_size = atoi(optarg);
+            break;
+        case 'v':
+            paging->debug = 1;
+            break;
+        case 'h':
+        case '?':
+            usage();
+            return 1;
+        }
+    }
+
+    argv += optind; argc -= optind;
+    
+    /* Path to pagefile is required */
+    if ( !filename )
+    {
+        printf("Filename for pagefile missing!\n");
+        usage();
+        return 1;
+    }
+
+    /* Set domain id */
+    if ( !paging->mem_event.domain_id )
+    {
+        printf("Numerical <domain_id> missing!\n");
+        return 1;
+    }
+
+    return 0;
+}
+
+static xenpaging_t *xenpaging_init(int argc, char *argv[])
 {
     xenpaging_t *paging;
     xc_domaininfo_t domain_info;
-    xc_interface *xch;
+    xc_interface *xch = NULL;
     xentoollog_logger *dbg = NULL;
     char *p;
     int rc;
@@ -215,7 +290,12 @@ static xenpaging_t *xenpaging_init(domid
     if ( !paging )
         goto err;
 
-    if ( getenv("XENPAGING_DEBUG") )
+    /* Get cmdline options and domain_id */
+    if ( xenpaging_getopts(paging, argc, argv) )
+        goto err;
+
+    /* Enable debug output */
+    if ( paging->debug )
         dbg = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
 
     /* Open connection to xen */
@@ -234,7 +314,7 @@ static xenpaging_t *xenpaging_init(domid
     }
 
     /* write domain ID to watch so we can ignore other domain shutdowns */
-    snprintf(watch_token, sizeof(watch_token), "%u", domain_id);
+    snprintf(watch_token, sizeof(watch_token), "%u", paging->mem_event.domain_id);
     if ( xs_watch(paging->xs_handle, "@releaseDomain", watch_token) == false )
     {
         PERROR("Could not bind to shutdown watch\n");
@@ -242,7 +322,7 @@ static xenpaging_t *xenpaging_init(domid
     }
 
     /* Watch xenpagings working target */
-    dom_path = xs_get_domain_path(paging->xs_handle, domain_id);
+    dom_path = xs_get_domain_path(paging->xs_handle, paging->mem_event.domain_id);
     if ( !dom_path )
     {
         PERROR("Could not find domain path\n");
@@ -260,16 +340,6 @@ static xenpaging_t *xenpaging_init(domid
         goto err;
     }
 
-    p = getenv("XENPAGING_POLICY_MRU_SIZE");
-    if ( p && *p )
-    {
-         paging->policy_mru_size = atoi(p);
-         DPRINTF("Setting policy mru_size to %d\n", paging->policy_mru_size);
-    }
-
-    /* Set domain id */
-    paging->mem_event.domain_id = domain_id;
-
     /* Initialise shared page */
     paging->mem_event.shared_page = init_page();
     if ( paging->mem_event.shared_page == NULL )
@@ -335,17 +405,21 @@ static xenpaging_t *xenpaging_init(domid
 
     paging->mem_event.port = rc;
 
-    rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1,
-                               &domain_info);
-    if ( rc != 1 )
+    /* Get max_pages from guest if not provided via cmdline */
+    if ( !paging->max_pages )
     {
-        PERROR("Error getting domain info");
-        goto err;
+        rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1,
+                                   &domain_info);
+        if ( rc != 1 )
+        {
+            PERROR("Error getting domain info");
+            goto err;
+        }
+
+        /* Record number of max_pages */
+        paging->max_pages = domain_info.max_pages;
     }
 
-    /* Record number of max_pages */
-    paging->max_pages = domain_info.max_pages;
-
     /* Allocate bitmap for tracking pages that have been paged out */
     paging->bitmap = bitmap_alloc(paging->max_pages);
     if ( !paging->bitmap )
@@ -355,8 +429,6 @@ static xenpaging_t *xenpaging_init(domid
     }
     DPRINTF("max_pages = %d\n", paging->max_pages);
 
-    paging->target_tot_pages = target_tot_pages;
-
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -718,25 +790,18 @@ int main(int argc, char *argv[])
     mode_t open_mode = S_IRUSR | S_IRGRP | S_IROTH | S_IWUSR | S_IWGRP | S_IWOTH;
     int fd;
 
-    if ( argc != 3 )
-    {
-        fprintf(stderr, "Usage: %s <domain_id> <tot_pages>\n", argv[0]);
-        return -1;
-    }
-
     /* Initialise domain paging */
-    paging = xenpaging_init(atoi(argv[1]), atoi(argv[2]));
+    paging = xenpaging_init(argc, argv);
     if ( paging == NULL )
     {
-        fprintf(stderr, "Error initialising paging");
+        fprintf(stderr, "Error initialising paging\n");
         return 1;
     }
     xch = paging->xc_handle;
 
-    DPRINTF("starting %s %u %d\n", argv[0], paging->mem_event.domain_id, paging->target_tot_pages);
+    DPRINTF("starting %s for domain_id %u with pagefile %s\n", argv[0], paging->mem_event.domain_id, filename);
 
     /* Open file */
-    sprintf(filename, "page_cache_%u", paging->mem_event.domain_id);
     fd = open(filename, open_flags, open_mode);
     if ( fd < 0 )
     {
diff -r bbe679f21208 -r deb016f351e5 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -52,6 +52,7 @@ typedef struct xenpaging {
     int num_paged_out;
     int target_tot_pages;
     int policy_mru_size;
+    int debug;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 } xenpaging_t;
 

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEA-0002k1-DO; Sun, 20 Nov 2011 18:34:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE7-0002cq-ME
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1321814064!2300321!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11041 invoked from network); 20 Nov 2011 18:34:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2011 18:34:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814064; l=3253;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=fJz66PdKjPezfaiRFiYrTtdKT4o=;
	b=JNNPRepcWvwAfoQMelCjeFsd/1lnjbwbWQaLwhlTy70Wx6T4pMirON8wQXnVFMnx6ER
	LaLeHhCS6j07Lj1tu4d/bG5eKu9U29moxvNoO++rodjcA8kAoeFzGNToxyB8Ommqi/tSO
	pLHm9WKtDsOjDBnBnZ6LLp50Js1G7JWYEfA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (jimi mo6) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z0590enAKFfxG2 ;
	Sun, 20 Nov 2011 19:34:13 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3942218638;
	Sun, 20 Nov 2011 19:34:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bbe679f21208fd8f3341e2d8556469c7b1e29d57
Message-Id: <bbe679f21208fd8f3341.1321814061@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16 of 20] xenpaging: watch the guests
 memory/target-tot_pages xenstore value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804967 -3600
# Node ID bbe679f21208fd8f3341e2d8556469c7b1e29d57
# Parent  827fcaf0d610dd0c54d3f1f305b2b8f12bd4240a
xenpaging: watch the guests memory/target-tot_pages xenstore value

Subsequent patches will use xenstored to store the numbers of pages
xenpaging is suppose to page-out.
Remove num_pages and use target_pages instead.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 827fcaf0d610 -r bbe679f21208 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -19,8 +19,10 @@
  */
 
 #define _XOPEN_SOURCE	600
+#define _GNU_SOURCE
 
 #include <inttypes.h>
+#include <stdio.h>
 #include <stdlib.h>
 #include <stdarg.h>
 #include <time.h>
@@ -35,6 +37,10 @@
 #include "policy.h"
 #include "xenpaging.h"
 
+/* Defines number of mfns a guest should use at a time, in KiB */
+#define WATCH_TARGETPAGES "memory/target-tot_pages"
+static char *watch_target_tot_pages;
+static char *dom_path;
 static char watch_token[16];
 static char filename[80];
 static int interrupted;
@@ -72,7 +78,7 @@ static int xenpaging_wait_for_event_or_t
 {
     xc_interface *xch = paging->xc_handle;
     xc_evtchn *xce = paging->mem_event.xce_handle;
-    char **vec;
+    char **vec, *val;
     unsigned int num;
     struct pollfd fd[2];
     int port;
@@ -111,6 +117,25 @@ static int xenpaging_wait_for_event_or_t
                     rc = 0;
                 }
             }
+            else if ( strcmp(vec[XS_WATCH_PATH], watch_target_tot_pages) == 0 )
+            {
+                int ret, target_tot_pages;
+                val = xs_read(paging->xs_handle, XBT_NULL, vec[XS_WATCH_PATH], NULL);
+                if ( val )
+                {
+                    ret = sscanf(val, "%d", &target_tot_pages);
+                    if ( ret > 0 )
+                    {
+                        /* KiB to pages */
+                        target_tot_pages >>= 2;
+                        if ( target_tot_pages < 0 || target_tot_pages > paging->max_pages )
+                            target_tot_pages = paging->max_pages;
+                        paging->target_tot_pages = target_tot_pages;
+                        DPRINTF("new target_tot_pages %d\n", target_tot_pages);
+                    }
+                    free(val);
+                }
+            }
             free(vec);
         }
     }
@@ -216,6 +241,25 @@ static xenpaging_t *xenpaging_init(domid
         goto err;
     }
 
+    /* Watch xenpagings working target */
+    dom_path = xs_get_domain_path(paging->xs_handle, domain_id);
+    if ( !dom_path )
+    {
+        PERROR("Could not find domain path\n");
+        goto err;
+    }
+    if ( asprintf(&watch_target_tot_pages, "%s/%s", dom_path, WATCH_TARGETPAGES) < 0 )
+    {
+        PERROR("Could not alloc watch path\n");
+        goto err;
+    }
+    DPRINTF("watching '%s'\n", watch_target_tot_pages);
+    if ( xs_watch(paging->xs_handle, watch_target_tot_pages, "") == false )
+    {
+        PERROR("Could not bind to xenpaging watch\n");
+        goto err;
+    }
+
     p = getenv("XENPAGING_POLICY_MRU_SIZE");
     if ( p && *p )
     {
@@ -342,6 +386,8 @@ static xenpaging_t *xenpaging_init(domid
             free(paging->mem_event.ring_page);
         }
 
+        free(dom_path);
+        free(watch_target_tot_pages);
         free(paging->bitmap);
         free(paging);
     }
@@ -357,6 +403,9 @@ static int xenpaging_teardown(xenpaging_
     if ( paging == NULL )
         return 0;
 
+    xs_unwatch(paging->xs_handle, watch_target_tot_pages, "");
+    xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
+
     xch = paging->xc_handle;
     paging->xc_handle = NULL;
     /* Tear down domain paging in Xen */

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEF-0002qS-7L; Sun, 20 Nov 2011 18:34:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCED-0002jj-Jq
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1321814058!55748707!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2181 invoked from network); 20 Nov 2011 18:34:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814072; l=982;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=zlZvnDsHzu+CvagaghTSfWdyrzM=;
	b=Y73GxQHhqxwHEEWSRhd/fLVYI1fpiMYkn7QFIJbavDPYG42PzJRLcFCrnUBkioZtG8n
	fFRuhs8qzx6szRZwi2ym/jbN//SB0Z67uEHnHxUrcb08vFYpNYqyXs+IGG8Xje+wDuKrp
	nGrPi6EUxdsb/m+gD4FUKDacUWDXOaK+pd4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo38) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j0264fnAKIFFLM ;
	Sun, 20 Nov 2011 19:34:10 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C8A5B18637;
	Sun, 20 Nov 2011 19:34:08 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e74c938d38518f6f6344c9bcc6b7c8916a073594
Message-Id: <e74c938d38518f6f6344.1321814056@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11 of 20] libxc: add bitmap_clear function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804960 -3600
# Node ID e74c938d38518f6f6344c9bcc6b7c8916a073594
# Parent  cc72e36fa9c3a6a467ad12188551f6f233185fc9
libxc: add bitmap_clear function

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r cc72e36fa9c3 -r e74c938d3851 tools/libxc/xc_bitops.h
--- a/tools/libxc/xc_bitops.h
+++ b/tools/libxc/xc_bitops.h
@@ -4,6 +4,7 @@
 /* bitmap operations for single threaded access */
 
 #include <stdlib.h>
+#include <string.h>
 
 #define BITS_PER_LONG (sizeof(unsigned long) * 8)
 #define ORDER_LONG (sizeof(unsigned long) == 4 ? 5 : 6)
@@ -25,6 +26,11 @@ static inline unsigned long *bitmap_allo
     return calloc(1, bitmap_size(nr_bits));
 }
 
+static inline void bitmap_clear(unsigned long *addr, int nr_bits)
+{
+    memset(addr, 0, bitmap_size(nr_bits));
+}
+
 static inline int test_bit(int nr, volatile unsigned long *addr)
 {
     return (BITMAP_ENTRY(nr, addr) >> BITMAP_SHIFT(nr)) & 1;

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE1-0002c9-20; Sun, 20 Nov 2011 18:34:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDz-0002Zn-3R
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321814041!46368775!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22981 invoked from network); 20 Nov 2011 18:34:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814056; l=2333;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=zkAHJIljiOKuwMYKxA1eNZrsqUQ=;
	b=F/o0Az6QO6MeFZcNhJTCdOUoQ13cMCwIISadDsxHTbiENdeQOc95c5UJtOF309Zp7hd
	0yWWeq8f/rgFwfq2ZNPfIhD8CMdmdPbp6KYlF/jigPzBm2fIobfyaQm2z1JE5JrajEROO
	mPZwnt/Q5uJTrQ4z7VSxcjpGCs0rjEy88S8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (fruni mo52) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id B07275nAKGUCuA ;
	Sun, 20 Nov 2011 19:34:12 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 94CBE18636;
	Sun, 20 Nov 2011 19:34:10 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 303d1521463bda6431cc0001d8755dd681e67a0d
Message-Id: <303d1521463bda6431cc.1321814059@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14 of 20] xenpaging: add XEN_PAGING_DIR /
 libxl_xenpaging_dir_path()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804963 -3600
# Node ID 303d1521463bda6431cc0001d8755dd681e67a0d
# Parent  3fe020b22882c369855dab3f3ebb88c02568e917
xenpaging: add XEN_PAGING_DIR / libxl_xenpaging_dir_path()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3fe020b22882 -r 303d1521463b Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -142,7 +142,7 @@ define buildmakevars2file-closure
 	$(foreach var,                                                      \
 	          SBINDIR BINDIR LIBEXEC LIBDIR SHAREDIR PRIVATE_BINDIR     \
 	          XENFIRMWAREDIR XEN_CONFIG_DIR XEN_SCRIPT_DIR XEN_LOCK_DIR \
-	          XEN_RUN_DIR,                                              \
+	          XEN_RUN_DIR XEN_PAGING_DIR,                               \
 	          echo "$(var)=\"$($(var))\"" >>$(1).tmp;)        \
 	$(call move-if-changed,$(1).tmp,$(1))
 endef
diff -r 3fe020b22882 -r 303d1521463b config/StdGNU.mk
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -53,10 +53,12 @@ ifeq ($(PREFIX),/usr)
 CONFIG_DIR = /etc
 XEN_LOCK_DIR = /var/lock
 XEN_RUN_DIR = /var/run/xen
+XEN_PAGING_DIR = /var/lib/xen/xenpaging
 else
 CONFIG_DIR = $(PREFIX)/etc
 XEN_LOCK_DIR = $(PREFIX)/var/lock
 XEN_RUN_DIR = $(PREFIX)/var/run/xen
+XEN_PAGING_DIR = $(PREFIX)/var/lib/xen/xenpaging
 endif
 
 SYSCONFIG_DIR = $(CONFIG_DIR)/$(CONFIG_LEAF_DIR)
diff -r 3fe020b22882 -r 303d1521463b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -633,6 +633,7 @@ const char *libxl_xen_config_dir_path(vo
 const char *libxl_xen_script_dir_path(void);
 const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
+const char *libxl_xenpaging_dir_path(void);
 
 #endif /* LIBXL_H */
 
diff -r 3fe020b22882 -r 303d1521463b tools/libxl/libxl_paths.c
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -70,6 +70,11 @@ const char *libxl_run_dir_path(void)
     return XEN_RUN_DIR;
 }
 
+const char *libxl_xenpaging_dir_path(void)
+{
+    return XEN_PAGING_DIR;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 3fe020b22882 -r 303d1521463b tools/xenpaging/Makefile
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -23,7 +23,7 @@ xenpaging: $(OBJS)
 	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) $(APPEND_LDFLAGS)
 
 install: all
-	$(INSTALL_DIR) $(DESTDIR)/var/lib/xen/xenpaging
+	$(INSTALL_DIR) $(DESTDIR)$(XEN_PAGING_DIR)
 	$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)
 	$(INSTALL_PROG) $(IBINS) $(DESTDIR)$(LIBEXEC)
 

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE7-0002hB-Ao; Sun, 20 Nov 2011 18:34:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE6-0002dJ-26
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1321814037!49196987!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15772 invoked from network); 20 Nov 2011 18:33:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:33:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814065; l=586;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/xZEi7PMUPQszbYJVdSF0w/si6Q=;
	b=G2mqARQl+4MypDVyQnX7FYjcPmSy/AIm/0Hf9HkxqzB+ACMCZHTkP3cc4JNOR2aWJ+p
	KCWP5JXTPpW7Enl3XW78O2GVPCZ1aFa51/fVye9yhWKiwbOXJh4zf+/S+BZeUQ68TR9qb
	6Rlr8XUWMG+I+EPxo8uqXmE0JZ0n1M2q5t4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (jimi mo19) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C03ae4nAKGMSym ;
	Sun, 20 Nov 2011 19:34:06 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3E14018636;
	Sun, 20 Nov 2011 19:34:06 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 00 of 20] tools/xenpaging changes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


The following changes contains non-controversial changes for xenpaging.
They were sent out twice earlier already.

Please apply.


Olaf


 Config.mk                        |    2 
 config/StdGNU.mk                 |    2 
 tools/libxc/xc_bitops.h          |    6 
 tools/libxl/libxl.h              |    1 
 tools/libxl/libxl_paths.c        |    5 
 tools/xenpaging/Makefile         |    6 
 tools/xenpaging/file_ops.c       |   30 --
 tools/xenpaging/policy.h         |    2 
 tools/xenpaging/policy_default.c |   51 +++-
 tools/xenpaging/xenpaging.c      |  463 +++++++++++++++++++++++++++------------
 tools/xenpaging/xenpaging.h      |    8 
 11 files changed, 405 insertions(+), 171 deletions(-)


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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE1-0002cf-S8; Sun, 20 Nov 2011 18:34:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE0-0002aC-RL
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321814058!3333781!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24076 invoked from network); 20 Nov 2011 18:34:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814057; l=1916;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=Sa7TMcgQhmARcx+MLEIQMDQswBc=;
	b=evnMwFBwhZj/0N4qMPtbqYOiiBoQllDaeavy1GT0fkkCycADubLVa/RwnVHkxvAlrdM
	PGjDBs5tAhMOjAryEFDA4RUfPpvdISQVUwL9TURN4+4xiUDFLSrIL7Uq4TwOZmobHpLo/
	UZYzsX2etd1pSEm3obM1AJiqDAl6n4O24Wc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (klopstock mo63) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 205b10nAKHDjTw ;
	Sun, 20 Nov 2011 19:34:08 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5896018637;
	Sun, 20 Nov 2011 19:34:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3c4e8b05da8b15d399f6813cf5f9f365dd0b9a17
Message-Id: <3c4e8b05da8b15d399f6.1321814051@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06 of 20] xenpaging: update xenpaging_init
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804942 -3600
# Node ID 3c4e8b05da8b15d399f6813cf5f9f365dd0b9a17
# Parent  c0c01de70558deca53a338b8c0956b56900c2257
xenpaging: update xenpaging_init

Move comment about xc_handle to the right place.
Allocate paging early and use calloc.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r c0c01de70558 -r 3c4e8b05da8b tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -169,18 +169,21 @@ static xenpaging_t *xenpaging_init(domid
     char *p;
     int rc;
 
+    /* Allocate memory */
+    paging = calloc(1, sizeof(xenpaging_t));
+    if ( !paging )
+        goto err;
+
     if ( getenv("XENPAGING_DEBUG") )
         dbg = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
-    xch = xc_interface_open(dbg, NULL, 0);
+
+    /* Open connection to xen */
+    paging->xc_handle = xch = xc_interface_open(dbg, NULL, 0);
     if ( !xch )
-        goto err_iface;
+        goto err;
 
     DPRINTF("xenpaging init\n");
 
-    /* Allocate memory */
-    paging = malloc(sizeof(xenpaging_t));
-    memset(paging, 0, sizeof(xenpaging_t));
-
     /* Open connection to xenstore */
     paging->xs_handle = xs_open(0);
     if ( paging->xs_handle == NULL )
@@ -204,9 +207,6 @@ static xenpaging_t *xenpaging_init(domid
          DPRINTF("Setting policy mru_size to %d\n", paging->policy_mru_size);
     }
 
-    /* Open connection to xen */
-    paging->xc_handle = xch;
-
     /* Set domain id */
     paging->mem_event.domain_id = domain_id;
 
@@ -322,7 +322,8 @@ static xenpaging_t *xenpaging_init(domid
     {
         if ( paging->xs_handle )
             xs_close(paging->xs_handle);
-        xc_interface_close(xch);
+        if ( xch )
+            xc_interface_close(xch);
         if ( paging->mem_event.shared_page )
         {
             munlock(paging->mem_event.shared_page, PAGE_SIZE);
@@ -340,7 +341,6 @@ static xenpaging_t *xenpaging_init(domid
         free(paging);
     }
 
- err_iface: 
     return NULL;
 }
 

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE7-0002ha-OZ; Sun, 20 Nov 2011 18:34:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE6-0002c7-CW
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321814063!2306900!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26930 invoked from network); 20 Nov 2011 18:34:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814063; l=1476;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=9tWZPlbFYfUEqa0BQ/LGhZACj9M=;
	b=KGKHJ4zYXu/Mnga1Ps2ntaU2Od1hhW4M/AxpbUnaGPC6gQvsUFtTsAgdGbyFz2a6lQu
	UaOl4I61ny72sFazdUnX9xTNrubi0W91nsZqyfxReTmYg2GEMrQAHsBRBZEfPEWGtnbPA
	tNVrWwpq/4XbymUXEhuAQAa0kNLAJH0rdI4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo19) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C01b3bnAKHXS6q ;
	Sun, 20 Nov 2011 19:34:11 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 77E2718638;
	Sun, 20 Nov 2011 19:34:09 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1e343a57860ea0d75d862076eec695b81219092e
Message-Id: <1e343a57860ea0d75d86.1321814057@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12 of 20] xenpaging: retry unpageable gfns
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804961 -3600
# Node ID 1e343a57860ea0d75d862076eec695b81219092e
# Parent  e74c938d38518f6f6344c9bcc6b7c8916a073594
xenpaging: retry unpageable gfns

Nomination of gfns can fail, but may succeed later.
Thats the case for a guest that starts ballooned.

v2:
 - print debug when clearing uncosumed happens

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e74c938d3851 -r 1e343a57860e tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -32,6 +32,7 @@ static unsigned int i_mru;
 static unsigned int mru_size;
 static unsigned long *bitmap;
 static unsigned long *unconsumed;
+static unsigned int unconsumed_cleared;
 static unsigned long current_gfn;
 static unsigned long max_pages;
 
@@ -87,8 +88,21 @@ int policy_choose_victim(xenpaging_t *pa
         current_gfn++;
         if ( current_gfn >= max_pages )
             current_gfn = 0;
+        /* Could not nominate any gfn */
         if ( wrap == current_gfn )
         {
+            /* Count wrap arounds */
+            unconsumed_cleared++;
+            /* Force retry every few seconds (depends on poll() timeout) */
+            if ( unconsumed_cleared > 123)
+            {
+                /* Force retry of unconsumed gfns */
+                bitmap_clear(unconsumed, max_pages);
+                unconsumed_cleared = 0;
+                DPRINTF("clearing unconsumed, wrap %lx", wrap);
+                /* One more round before returning ENOSPC */
+                continue;
+            }
             victim->gfn = INVALID_MFN;
             return -ENOSPC;
         }

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEA-0002k1-DO; Sun, 20 Nov 2011 18:34:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE7-0002cq-ME
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1321814064!2300321!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11041 invoked from network); 20 Nov 2011 18:34:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Nov 2011 18:34:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814064; l=3253;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=fJz66PdKjPezfaiRFiYrTtdKT4o=;
	b=JNNPRepcWvwAfoQMelCjeFsd/1lnjbwbWQaLwhlTy70Wx6T4pMirON8wQXnVFMnx6ER
	LaLeHhCS6j07Lj1tu4d/bG5eKu9U29moxvNoO++rodjcA8kAoeFzGNToxyB8Ommqi/tSO
	pLHm9WKtDsOjDBnBnZ6LLp50Js1G7JWYEfA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (jimi mo6) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id z0590enAKFfxG2 ;
	Sun, 20 Nov 2011 19:34:13 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3942218638;
	Sun, 20 Nov 2011 19:34:11 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bbe679f21208fd8f3341e2d8556469c7b1e29d57
Message-Id: <bbe679f21208fd8f3341.1321814061@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16 of 20] xenpaging: watch the guests
 memory/target-tot_pages xenstore value
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804967 -3600
# Node ID bbe679f21208fd8f3341e2d8556469c7b1e29d57
# Parent  827fcaf0d610dd0c54d3f1f305b2b8f12bd4240a
xenpaging: watch the guests memory/target-tot_pages xenstore value

Subsequent patches will use xenstored to store the numbers of pages
xenpaging is suppose to page-out.
Remove num_pages and use target_pages instead.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 827fcaf0d610 -r bbe679f21208 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -19,8 +19,10 @@
  */
 
 #define _XOPEN_SOURCE	600
+#define _GNU_SOURCE
 
 #include <inttypes.h>
+#include <stdio.h>
 #include <stdlib.h>
 #include <stdarg.h>
 #include <time.h>
@@ -35,6 +37,10 @@
 #include "policy.h"
 #include "xenpaging.h"
 
+/* Defines number of mfns a guest should use at a time, in KiB */
+#define WATCH_TARGETPAGES "memory/target-tot_pages"
+static char *watch_target_tot_pages;
+static char *dom_path;
 static char watch_token[16];
 static char filename[80];
 static int interrupted;
@@ -72,7 +78,7 @@ static int xenpaging_wait_for_event_or_t
 {
     xc_interface *xch = paging->xc_handle;
     xc_evtchn *xce = paging->mem_event.xce_handle;
-    char **vec;
+    char **vec, *val;
     unsigned int num;
     struct pollfd fd[2];
     int port;
@@ -111,6 +117,25 @@ static int xenpaging_wait_for_event_or_t
                     rc = 0;
                 }
             }
+            else if ( strcmp(vec[XS_WATCH_PATH], watch_target_tot_pages) == 0 )
+            {
+                int ret, target_tot_pages;
+                val = xs_read(paging->xs_handle, XBT_NULL, vec[XS_WATCH_PATH], NULL);
+                if ( val )
+                {
+                    ret = sscanf(val, "%d", &target_tot_pages);
+                    if ( ret > 0 )
+                    {
+                        /* KiB to pages */
+                        target_tot_pages >>= 2;
+                        if ( target_tot_pages < 0 || target_tot_pages > paging->max_pages )
+                            target_tot_pages = paging->max_pages;
+                        paging->target_tot_pages = target_tot_pages;
+                        DPRINTF("new target_tot_pages %d\n", target_tot_pages);
+                    }
+                    free(val);
+                }
+            }
             free(vec);
         }
     }
@@ -216,6 +241,25 @@ static xenpaging_t *xenpaging_init(domid
         goto err;
     }
 
+    /* Watch xenpagings working target */
+    dom_path = xs_get_domain_path(paging->xs_handle, domain_id);
+    if ( !dom_path )
+    {
+        PERROR("Could not find domain path\n");
+        goto err;
+    }
+    if ( asprintf(&watch_target_tot_pages, "%s/%s", dom_path, WATCH_TARGETPAGES) < 0 )
+    {
+        PERROR("Could not alloc watch path\n");
+        goto err;
+    }
+    DPRINTF("watching '%s'\n", watch_target_tot_pages);
+    if ( xs_watch(paging->xs_handle, watch_target_tot_pages, "") == false )
+    {
+        PERROR("Could not bind to xenpaging watch\n");
+        goto err;
+    }
+
     p = getenv("XENPAGING_POLICY_MRU_SIZE");
     if ( p && *p )
     {
@@ -342,6 +386,8 @@ static xenpaging_t *xenpaging_init(domid
             free(paging->mem_event.ring_page);
         }
 
+        free(dom_path);
+        free(watch_target_tot_pages);
         free(paging->bitmap);
         free(paging);
     }
@@ -357,6 +403,9 @@ static int xenpaging_teardown(xenpaging_
     if ( paging == NULL )
         return 0;
 
+    xs_unwatch(paging->xs_handle, watch_target_tot_pages, "");
+    xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
+
     xch = paging->xc_handle;
     paging->xc_handle = NULL;
     /* Tear down domain paging in Xen */

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCEF-0002qS-7L; Sun, 20 Nov 2011 18:34:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCED-0002jj-Jq
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1321814058!55748707!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2181 invoked from network); 20 Nov 2011 18:34:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814072; l=982;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=zlZvnDsHzu+CvagaghTSfWdyrzM=;
	b=Y73GxQHhqxwHEEWSRhd/fLVYI1fpiMYkn7QFIJbavDPYG42PzJRLcFCrnUBkioZtG8n
	fFRuhs8qzx6szRZwi2ym/jbN//SB0Z67uEHnHxUrcb08vFYpNYqyXs+IGG8Xje+wDuKrp
	nGrPi6EUxdsb/m+gD4FUKDacUWDXOaK+pd4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo38) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j0264fnAKIFFLM ;
	Sun, 20 Nov 2011 19:34:10 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C8A5B18637;
	Sun, 20 Nov 2011 19:34:08 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e74c938d38518f6f6344c9bcc6b7c8916a073594
Message-Id: <e74c938d38518f6f6344.1321814056@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11 of 20] libxc: add bitmap_clear function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804960 -3600
# Node ID e74c938d38518f6f6344c9bcc6b7c8916a073594
# Parent  cc72e36fa9c3a6a467ad12188551f6f233185fc9
libxc: add bitmap_clear function

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r cc72e36fa9c3 -r e74c938d3851 tools/libxc/xc_bitops.h
--- a/tools/libxc/xc_bitops.h
+++ b/tools/libxc/xc_bitops.h
@@ -4,6 +4,7 @@
 /* bitmap operations for single threaded access */
 
 #include <stdlib.h>
+#include <string.h>
 
 #define BITS_PER_LONG (sizeof(unsigned long) * 8)
 #define ORDER_LONG (sizeof(unsigned long) == 4 ? 5 : 6)
@@ -25,6 +26,11 @@ static inline unsigned long *bitmap_allo
     return calloc(1, bitmap_size(nr_bits));
 }
 
+static inline void bitmap_clear(unsigned long *addr, int nr_bits)
+{
+    memset(addr, 0, bitmap_size(nr_bits));
+}
+
 static inline int test_bit(int nr, volatile unsigned long *addr)
 {
     return (BITMAP_ENTRY(nr, addr) >> BITMAP_SHIFT(nr)) & 1;

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

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE1-0002cV-FS; Sun, 20 Nov 2011 18:34:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCDz-0002Zz-Ug
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321814057!3870831!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21024 invoked from network); 20 Nov 2011 18:34:17 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:17 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814056; l=7611;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=Bbzr8USnodc3tKYwzhbhe7GsGEE=;
	b=FtaVAl4GTh4dwOrht0HXR1vK47ZO4Tvc0AhTAlkG+YOw46BiWv7JGOugWoOcRuOqTdb
	bA5lIuxjwqhUABZr/cvloTGIjDXfIHgvGCeWdhCykwEc7luJqdsI9BIVUeSUwUwUVVS7U
	cNUJnImPX+vlc6+Rg5ug12WfvoKjvzYug/c=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (fruni mo30) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id n061f7nAKFZlMK ;
	Sun, 20 Nov 2011 19:34:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2BA201863A;
	Sun, 20 Nov 2011 19:34:12 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: deb016f351e55e924274b4ccfbb80cb71543fc3e
Message-Id: <deb016f351e55e924274.1321814062@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17 of 20] xenpaging: add cmdline interface for
	pager
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804968 -3600
# Node ID deb016f351e55e924274b4ccfbb80cb71543fc3e
# Parent  bbe679f21208fd8f3341e2d8556469c7b1e29d57
xenpaging: add cmdline interface for pager

Introduce a cmdline handling for the pager. This simplifies libxl support,
debug and mru_size are not passed via the environment anymore.
The new interface looks like this:

xenpaging [options] -f <pagefile> -d <domain_id>
options:
 -d <domid>     --domain=<domid>         numerical domain_id of guest. This option is required.
 -f <file>      --pagefile=<file>        pagefile to use. This option is required.
 -m <max_memkb> --max_memkb=<max_memkb>  maximum amount of memory to handle.
 -r <num>       --mru_size=<num>         number of paged-in pages to keep in memory.
 -d             --debug                  enable debug output.
 -h             --help                   this output.


Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r bbe679f21208 -r deb016f351e5 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -31,6 +31,7 @@
 #include <poll.h>
 #include <xc_private.h>
 #include <xs.h>
+#include <getopt.h>
 
 #include "xc_bitops.h"
 #include "file_ops.h"
@@ -42,12 +43,12 @@
 static char *watch_target_tot_pages;
 static char *dom_path;
 static char watch_token[16];
-static char filename[80];
+static char *filename;
 static int interrupted;
 
 static void unlink_pagefile(void)
 {
-    if ( filename[0] )
+    if ( filename && filename[0] )
     {
         unlink(filename);
         filename[0] = '\0';
@@ -201,11 +202,85 @@ static void *init_page(void)
     return NULL;
 }
 
-static xenpaging_t *xenpaging_init(domid_t domain_id, int target_tot_pages)
+static void usage(void)
+{
+    printf("usage:\n\n");
+
+    printf("  xenpaging [options] -f <pagefile> -d <domain_id>\n\n");
+
+    printf("options:\n");
+    printf(" -d <domid>     --domain=<domid>         numerical domain_id of guest. This option is required.\n");
+    printf(" -f <file>      --pagefile=<file>        pagefile to use. This option is required.\n");
+    printf(" -m <max_memkb> --max_memkb=<max_memkb>  maximum amount of memory to handle.\n");
+    printf(" -r <num>       --mru_size=<num>         number of paged-in pages to keep in memory.\n");
+    printf(" -v             --verbose                enable debug output.\n");
+    printf(" -h             --help                   this output.\n");
+}
+
+static int xenpaging_getopts(xenpaging_t *paging, int argc, char *argv[])
+{
+    int ch;
+    static const char sopts[] = "hvd:f:m:r:";
+    static const struct option lopts[] = {
+        {"help", 0, NULL, 'h'},
+        {"verbose", 0, NULL, 'v'},
+        {"domain", 1, NULL, 'd'},
+        {"pagefile", 1, NULL, 'f'},
+        {"mru_size", 1, NULL, 'm'},
+        { }
+    };
+
+    while ((ch = getopt_long(argc, argv, sopts, lopts, NULL)) != -1)
+    {
+        switch(ch) {
+        case 'd':
+            paging->mem_event.domain_id = atoi(optarg);
+            break;
+        case 'f':
+            filename = strdup(optarg);
+            break;
+        case 'm':
+            /* KiB to pages */
+            paging->max_pages = atoi(optarg) >> 2;
+            break;
+        case 'r':
+            paging->policy_mru_size = atoi(optarg);
+            break;
+        case 'v':
+            paging->debug = 1;
+            break;
+        case 'h':
+        case '?':
+            usage();
+            return 1;
+        }
+    }
+
+    argv += optind; argc -= optind;
+    
+    /* Path to pagefile is required */
+    if ( !filename )
+    {
+        printf("Filename for pagefile missing!\n");
+        usage();
+        return 1;
+    }
+
+    /* Set domain id */
+    if ( !paging->mem_event.domain_id )
+    {
+        printf("Numerical <domain_id> missing!\n");
+        return 1;
+    }
+
+    return 0;
+}
+
+static xenpaging_t *xenpaging_init(int argc, char *argv[])
 {
     xenpaging_t *paging;
     xc_domaininfo_t domain_info;
-    xc_interface *xch;
+    xc_interface *xch = NULL;
     xentoollog_logger *dbg = NULL;
     char *p;
     int rc;
@@ -215,7 +290,12 @@ static xenpaging_t *xenpaging_init(domid
     if ( !paging )
         goto err;
 
-    if ( getenv("XENPAGING_DEBUG") )
+    /* Get cmdline options and domain_id */
+    if ( xenpaging_getopts(paging, argc, argv) )
+        goto err;
+
+    /* Enable debug output */
+    if ( paging->debug )
         dbg = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
 
     /* Open connection to xen */
@@ -234,7 +314,7 @@ static xenpaging_t *xenpaging_init(domid
     }
 
     /* write domain ID to watch so we can ignore other domain shutdowns */
-    snprintf(watch_token, sizeof(watch_token), "%u", domain_id);
+    snprintf(watch_token, sizeof(watch_token), "%u", paging->mem_event.domain_id);
     if ( xs_watch(paging->xs_handle, "@releaseDomain", watch_token) == false )
     {
         PERROR("Could not bind to shutdown watch\n");
@@ -242,7 +322,7 @@ static xenpaging_t *xenpaging_init(domid
     }
 
     /* Watch xenpagings working target */
-    dom_path = xs_get_domain_path(paging->xs_handle, domain_id);
+    dom_path = xs_get_domain_path(paging->xs_handle, paging->mem_event.domain_id);
     if ( !dom_path )
     {
         PERROR("Could not find domain path\n");
@@ -260,16 +340,6 @@ static xenpaging_t *xenpaging_init(domid
         goto err;
     }
 
-    p = getenv("XENPAGING_POLICY_MRU_SIZE");
-    if ( p && *p )
-    {
-         paging->policy_mru_size = atoi(p);
-         DPRINTF("Setting policy mru_size to %d\n", paging->policy_mru_size);
-    }
-
-    /* Set domain id */
-    paging->mem_event.domain_id = domain_id;
-
     /* Initialise shared page */
     paging->mem_event.shared_page = init_page();
     if ( paging->mem_event.shared_page == NULL )
@@ -335,17 +405,21 @@ static xenpaging_t *xenpaging_init(domid
 
     paging->mem_event.port = rc;
 
-    rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1,
-                               &domain_info);
-    if ( rc != 1 )
+    /* Get max_pages from guest if not provided via cmdline */
+    if ( !paging->max_pages )
     {
-        PERROR("Error getting domain info");
-        goto err;
+        rc = xc_domain_getinfolist(xch, paging->mem_event.domain_id, 1,
+                                   &domain_info);
+        if ( rc != 1 )
+        {
+            PERROR("Error getting domain info");
+            goto err;
+        }
+
+        /* Record number of max_pages */
+        paging->max_pages = domain_info.max_pages;
     }
 
-    /* Record number of max_pages */
-    paging->max_pages = domain_info.max_pages;
-
     /* Allocate bitmap for tracking pages that have been paged out */
     paging->bitmap = bitmap_alloc(paging->max_pages);
     if ( !paging->bitmap )
@@ -355,8 +429,6 @@ static xenpaging_t *xenpaging_init(domid
     }
     DPRINTF("max_pages = %d\n", paging->max_pages);
 
-    paging->target_tot_pages = target_tot_pages;
-
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -718,25 +790,18 @@ int main(int argc, char *argv[])
     mode_t open_mode = S_IRUSR | S_IRGRP | S_IROTH | S_IWUSR | S_IWGRP | S_IWOTH;
     int fd;
 
-    if ( argc != 3 )
-    {
-        fprintf(stderr, "Usage: %s <domain_id> <tot_pages>\n", argv[0]);
-        return -1;
-    }
-
     /* Initialise domain paging */
-    paging = xenpaging_init(atoi(argv[1]), atoi(argv[2]));
+    paging = xenpaging_init(argc, argv);
     if ( paging == NULL )
     {
-        fprintf(stderr, "Error initialising paging");
+        fprintf(stderr, "Error initialising paging\n");
         return 1;
     }
     xch = paging->xc_handle;
 
-    DPRINTF("starting %s %u %d\n", argv[0], paging->mem_event.domain_id, paging->target_tot_pages);
+    DPRINTF("starting %s for domain_id %u with pagefile %s\n", argv[0], paging->mem_event.domain_id, filename);
 
     /* Open file */
-    sprintf(filename, "page_cache_%u", paging->mem_event.domain_id);
     fd = open(filename, open_flags, open_mode);
     if ( fd < 0 )
     {
diff -r bbe679f21208 -r deb016f351e5 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -52,6 +52,7 @@ typedef struct xenpaging {
     int num_paged_out;
     int target_tot_pages;
     int policy_mru_size;
+    int debug;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 } xenpaging_t;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE7-0002hB-Ao; Sun, 20 Nov 2011 18:34:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE6-0002dJ-26
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1321814037!49196987!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15772 invoked from network); 20 Nov 2011 18:33:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Nov 2011 18:33:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814065; l=586;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/xZEi7PMUPQszbYJVdSF0w/si6Q=;
	b=G2mqARQl+4MypDVyQnX7FYjcPmSy/AIm/0Hf9HkxqzB+ACMCZHTkP3cc4JNOR2aWJ+p
	KCWP5JXTPpW7Enl3XW78O2GVPCZ1aFa51/fVye9yhWKiwbOXJh4zf+/S+BZeUQ68TR9qb
	6Rlr8XUWMG+I+EPxo8uqXmE0JZ0n1M2q5t4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (jimi mo19) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id C03ae4nAKGMSym ;
	Sun, 20 Nov 2011 19:34:06 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3E14018636;
	Sun, 20 Nov 2011 19:34:06 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 00 of 20] tools/xenpaging changes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


The following changes contains non-controversial changes for xenpaging.
They were sent out twice earlier already.

Please apply.


Olaf


 Config.mk                        |    2 
 config/StdGNU.mk                 |    2 
 tools/libxc/xc_bitops.h          |    6 
 tools/libxl/libxl.h              |    1 
 tools/libxl/libxl_paths.c        |    5 
 tools/xenpaging/Makefile         |    6 
 tools/xenpaging/file_ops.c       |   30 --
 tools/xenpaging/policy.h         |    2 
 tools/xenpaging/policy_default.c |   51 +++-
 tools/xenpaging/xenpaging.c      |  463 +++++++++++++++++++++++++++------------
 tools/xenpaging/xenpaging.h      |    8 
 11 files changed, 405 insertions(+), 171 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE7-0002ha-OZ; Sun, 20 Nov 2011 18:34:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE6-0002c7-CW
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321814063!2306900!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26930 invoked from network); 20 Nov 2011 18:34:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814063; l=1476;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=9tWZPlbFYfUEqa0BQ/LGhZACj9M=;
	b=KGKHJ4zYXu/Mnga1Ps2ntaU2Od1hhW4M/AxpbUnaGPC6gQvsUFtTsAgdGbyFz2a6lQu
	UaOl4I61ny72sFazdUnX9xTNrubi0W91nsZqyfxReTmYg2GEMrQAHsBRBZEfPEWGtnbPA
	tNVrWwpq/4XbymUXEhuAQAa0kNLAJH0rdI4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by post.strato.de (mrclete mo19) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C01b3bnAKHXS6q ;
	Sun, 20 Nov 2011 19:34:11 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 77E2718638;
	Sun, 20 Nov 2011 19:34:09 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1e343a57860ea0d75d862076eec695b81219092e
Message-Id: <1e343a57860ea0d75d86.1321814057@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12 of 20] xenpaging: retry unpageable gfns
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804961 -3600
# Node ID 1e343a57860ea0d75d862076eec695b81219092e
# Parent  e74c938d38518f6f6344c9bcc6b7c8916a073594
xenpaging: retry unpageable gfns

Nomination of gfns can fail, but may succeed later.
Thats the case for a guest that starts ballooned.

v2:
 - print debug when clearing uncosumed happens

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e74c938d3851 -r 1e343a57860e tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -32,6 +32,7 @@ static unsigned int i_mru;
 static unsigned int mru_size;
 static unsigned long *bitmap;
 static unsigned long *unconsumed;
+static unsigned int unconsumed_cleared;
 static unsigned long current_gfn;
 static unsigned long max_pages;
 
@@ -87,8 +88,21 @@ int policy_choose_victim(xenpaging_t *pa
         current_gfn++;
         if ( current_gfn >= max_pages )
             current_gfn = 0;
+        /* Could not nominate any gfn */
         if ( wrap == current_gfn )
         {
+            /* Count wrap arounds */
+            unconsumed_cleared++;
+            /* Force retry every few seconds (depends on poll() timeout) */
+            if ( unconsumed_cleared > 123)
+            {
+                /* Force retry of unconsumed gfns */
+                bitmap_clear(unconsumed, max_pages);
+                unconsumed_cleared = 0;
+                DPRINTF("clearing unconsumed, wrap %lx", wrap);
+                /* One more round before returning ENOSPC */
+                continue;
+            }
             victim->gfn = INVALID_MFN;
             return -ENOSPC;
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:35:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:35:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCE1-0002cf-S8; Sun, 20 Nov 2011 18:34:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSCE0-0002aC-RL
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:34:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321814058!3333781!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24076 invoked from network); 20 Nov 2011 18:34:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 20 Nov 2011 18:34:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321814057; l=1916;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=Sa7TMcgQhmARcx+MLEIQMDQswBc=;
	b=evnMwFBwhZj/0N4qMPtbqYOiiBoQllDaeavy1GT0fkkCycADubLVa/RwnVHkxvAlrdM
	PGjDBs5tAhMOjAryEFDA4RUfPpvdISQVUwL9TURN4+4xiUDFLSrIL7Uq4TwOZmobHpLo/
	UZYzsX2etd1pSEm3obM1AJiqDAl6n4O24Wc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJji0PESsg
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-070-128.pools.arcor-ip.net [88.65.70.128])
	by smtp.strato.de (klopstock mo63) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 205b10nAKHDjTw ;
	Sun, 20 Nov 2011 19:34:08 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5896018637;
	Sun, 20 Nov 2011 19:34:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3c4e8b05da8b15d399f6813cf5f9f365dd0b9a17
Message-Id: <3c4e8b05da8b15d399f6.1321814051@probook.site>
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 20 Nov 2011 19:34:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06 of 20] xenpaging: update xenpaging_init
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321804942 -3600
# Node ID 3c4e8b05da8b15d399f6813cf5f9f365dd0b9a17
# Parent  c0c01de70558deca53a338b8c0956b56900c2257
xenpaging: update xenpaging_init

Move comment about xc_handle to the right place.
Allocate paging early and use calloc.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r c0c01de70558 -r 3c4e8b05da8b tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -169,18 +169,21 @@ static xenpaging_t *xenpaging_init(domid
     char *p;
     int rc;
 
+    /* Allocate memory */
+    paging = calloc(1, sizeof(xenpaging_t));
+    if ( !paging )
+        goto err;
+
     if ( getenv("XENPAGING_DEBUG") )
         dbg = (xentoollog_logger *)xtl_createlogger_stdiostream(stderr, XTL_DEBUG, 0);
-    xch = xc_interface_open(dbg, NULL, 0);
+
+    /* Open connection to xen */
+    paging->xc_handle = xch = xc_interface_open(dbg, NULL, 0);
     if ( !xch )
-        goto err_iface;
+        goto err;
 
     DPRINTF("xenpaging init\n");
 
-    /* Allocate memory */
-    paging = malloc(sizeof(xenpaging_t));
-    memset(paging, 0, sizeof(xenpaging_t));
-
     /* Open connection to xenstore */
     paging->xs_handle = xs_open(0);
     if ( paging->xs_handle == NULL )
@@ -204,9 +207,6 @@ static xenpaging_t *xenpaging_init(domid
          DPRINTF("Setting policy mru_size to %d\n", paging->policy_mru_size);
     }
 
-    /* Open connection to xen */
-    paging->xc_handle = xch;
-
     /* Set domain id */
     paging->mem_event.domain_id = domain_id;
 
@@ -322,7 +322,8 @@ static xenpaging_t *xenpaging_init(domid
     {
         if ( paging->xs_handle )
             xs_close(paging->xs_handle);
-        xc_interface_close(xch);
+        if ( xch )
+            xc_interface_close(xch);
         if ( paging->mem_event.shared_page )
         {
             munlock(paging->mem_event.shared_page, PAGE_SIZE);
@@ -340,7 +341,6 @@ static xenpaging_t *xenpaging_init(domid
         free(paging);
     }
 
- err_iface: 
     return NULL;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:53:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:53:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCVn-0006Iu-Tm; Sun, 20 Nov 2011 18:53:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSCVm-0006Ip-66
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:53:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1321815159!2298586!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31519 invoked from network); 20 Nov 2011 18:52:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 18:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,543,1315180800"; 
   d="scan'208";a="9028414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Nov 2011 18:52:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 20 Nov 2011 18:52:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSCVK-0006sU-9S;
	Sun, 20 Nov 2011 18:52:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSCVK-0002UQ-5w;
	Sun, 20 Nov 2011 18:52:38 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9906-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 20 Nov 2011 18:52:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9906: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9906 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9906/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install               fail pass in 9901

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10  fail in 9901 like 9855

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 20 18:53:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 18:53:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSCVn-0006Iu-Tm; Sun, 20 Nov 2011 18:53:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSCVm-0006Ip-66
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 18:53:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1321815159!2298586!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31519 invoked from network); 20 Nov 2011 18:52:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 18:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,543,1315180800"; 
   d="scan'208";a="9028414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Nov 2011 18:52:38 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 20 Nov 2011 18:52:38 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSCVK-0006sU-9S;
	Sun, 20 Nov 2011 18:52:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSCVK-0002UQ-5w;
	Sun, 20 Nov 2011 18:52:38 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9906-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 20 Nov 2011 18:52:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9906: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9906 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9906/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install               fail pass in 9901

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10  fail in 9901 like 9855

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 20 20:00:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 20:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSDYQ-0007Aj-RC; Sun, 20 Nov 2011 19:59:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSDYQ-0007Ae-2m
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 19:59:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1321819167!3866501!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30294 invoked from network); 20 Nov 2011 19:59:27 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 19:59:27 -0000
Received: by wwp14 with SMTP id 14so7210879wwp.24
	for <xen-devel@lists.xensource.com>;
	Sun, 20 Nov 2011 11:59:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=5aCZlFNum4aExd9RBQGmyethUMl3WNU+oPqz2nzJr5w=;
	b=Cr12v2yxdl2qDdJINSawF43LUOhbeBIxDUsjjqYv2vYhy/rNcgu85OlGPhz7aA6lG7
	y1uS0QZlXbK4ev70OG1VEIuiHY2JwP9HR7mh3v9+R/Kn9pD4vOMaiO+p1aC4b32VYEuH
	RjdEt+bh1BIiDZ0wvm2yd8HBUuED06G2U/vf0=
Received: by 10.227.197.145 with SMTP id ek17mr7040166wbb.19.1321819167349;
	Sun, 20 Nov 2011 11:59:27 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id n2sm4038519wiz.16.2011.11.20.11.59.23
	(version=SSLv3 cipher=OTHER); Sun, 20 Nov 2011 11:59:25 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Sun, 20 Nov 2011 19:59:14 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAEF0C92.25446%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
	XENMEM_add_to_physmap
Thread-Index: AcynvuCP4zz8BJXkGUaseT8p0ENGWg==
In-Reply-To: <20111120132512.GA31844@aepfle.de>
Mime-version: 1.0
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com, tim@xen.org,
	Jean Guyader <jean.guyader@eu.citrix.com>, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
 XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/11/2011 13:25, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Sat, Nov 19, Keir Fraser wrote:
> 
>> On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>>> On Wed, Nov 16, Jean Guyader wrote:
>>> 
>>>> Move the code for the XENMEM_add_to_physmap case into it's own
>>>> function (xenmem_add_to_physmap).
>>> 
>>> This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite
>>> failures.
>>> (XEN) Assertion '!in_atomic()' failed at softirq.c:61
>>> 
>>> preempt_count is like fffffc52 or fffffc00 in my testing.
>> 
>> Thanks, hopefully fixed by c/s 24167.
> 
> Yes, the ASSERT does not trigger anymore.
> 
> The remaining issue is this:
> 
> Nov 20 06:21:11.744519 (XEN) hvm.c:2312:d1 guest attempted write to read-only
> memory page. gfn=0xc0, mfn=0x201979

Is that new behaviour? It may be unrelated to whatever HVM test failure
we're seeing, or else be a mere symptom of a guest gone haywire for other
reasons (we write-protect that memory range because it is supposed to be
ROM).

 -- Keir

> See
> http://www.chiark.greenend.org.uk/~xensrcts/logs/9893/test-amd64-i386-rhel6hvm
> -amd/serial-potato-beetle.log
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 20 20:00:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 20:00:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSDYQ-0007Aj-RC; Sun, 20 Nov 2011 19:59:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSDYQ-0007Ae-2m
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 19:59:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1321819167!3866501!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30294 invoked from network); 20 Nov 2011 19:59:27 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 19:59:27 -0000
Received: by wwp14 with SMTP id 14so7210879wwp.24
	for <xen-devel@lists.xensource.com>;
	Sun, 20 Nov 2011 11:59:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=5aCZlFNum4aExd9RBQGmyethUMl3WNU+oPqz2nzJr5w=;
	b=Cr12v2yxdl2qDdJINSawF43LUOhbeBIxDUsjjqYv2vYhy/rNcgu85OlGPhz7aA6lG7
	y1uS0QZlXbK4ev70OG1VEIuiHY2JwP9HR7mh3v9+R/Kn9pD4vOMaiO+p1aC4b32VYEuH
	RjdEt+bh1BIiDZ0wvm2yd8HBUuED06G2U/vf0=
Received: by 10.227.197.145 with SMTP id ek17mr7040166wbb.19.1321819167349;
	Sun, 20 Nov 2011 11:59:27 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id n2sm4038519wiz.16.2011.11.20.11.59.23
	(version=SSLv3 cipher=OTHER); Sun, 20 Nov 2011 11:59:25 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Sun, 20 Nov 2011 19:59:14 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAEF0C92.25446%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
	XENMEM_add_to_physmap
Thread-Index: AcynvuCP4zz8BJXkGUaseT8p0ENGWg==
In-Reply-To: <20111120132512.GA31844@aepfle.de>
Mime-version: 1.0
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com, tim@xen.org,
	Jean Guyader <jean.guyader@eu.citrix.com>, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
 XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/11/2011 13:25, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Sat, Nov 19, Keir Fraser wrote:
> 
>> On 19/11/2011 21:58, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>>> On Wed, Nov 16, Jean Guyader wrote:
>>> 
>>>> Move the code for the XENMEM_add_to_physmap case into it's own
>>>> function (xenmem_add_to_physmap).
>>> 
>>> This changeset 24163:7a9a1261a6b0 seems to cause the current testsuite
>>> failures.
>>> (XEN) Assertion '!in_atomic()' failed at softirq.c:61
>>> 
>>> preempt_count is like fffffc52 or fffffc00 in my testing.
>> 
>> Thanks, hopefully fixed by c/s 24167.
> 
> Yes, the ASSERT does not trigger anymore.
> 
> The remaining issue is this:
> 
> Nov 20 06:21:11.744519 (XEN) hvm.c:2312:d1 guest attempted write to read-only
> memory page. gfn=0xc0, mfn=0x201979

Is that new behaviour? It may be unrelated to whatever HVM test failure
we're seeing, or else be a mere symptom of a guest gone haywire for other
reasons (we write-protect that memory range because it is supposed to be
ROM).

 -- Keir

> See
> http://www.chiark.greenend.org.uk/~xensrcts/logs/9893/test-amd64-i386-rhel6hvm
> -amd/serial-potato-beetle.log
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 20 23:40:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 23:40:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSGz7-0000oF-UN; Sun, 20 Nov 2011 23:39:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSGz6-0000o9-0u
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 23:39:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321832353!3889855!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4042 invoked from network); 20 Nov 2011 23:39:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 23:39:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,544,1315180800"; 
   d="scan'208";a="9029299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Nov 2011 23:39:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 20 Nov 2011 23:39:12 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSGye-0008TG-2m;
	Sun, 20 Nov 2011 23:39:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSGyd-0002mb-SN;
	Sun, 20 Nov 2011 23:39:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9915-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 20 Nov 2011 23:39:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9915: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9915 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9915/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9817
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 20 23:40:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 20 Nov 2011 23:40:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSGz7-0000oF-UN; Sun, 20 Nov 2011 23:39:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSGz6-0000o9-0u
	for xen-devel@lists.xensource.com; Sun, 20 Nov 2011 23:39:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321832353!3889855!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4042 invoked from network); 20 Nov 2011 23:39:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Nov 2011 23:39:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,544,1315180800"; 
   d="scan'208";a="9029299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Nov 2011 23:39:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 20 Nov 2011 23:39:12 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSGye-0008TG-2m;
	Sun, 20 Nov 2011 23:39:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSGyd-0002mb-SN;
	Sun, 20 Nov 2011 23:39:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9915-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 20 Nov 2011 23:39:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9915: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9915 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9915/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9817
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 00:02:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 00:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSHKP-0001Dv-K4; Mon, 21 Nov 2011 00:01:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1RSHKO-0001Dd-A6
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 00:01:40 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321833672!4987243!1
X-Originating-IP: [98.139.44.146]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26147 invoked from network); 21 Nov 2011 00:01:13 -0000
Received: from nm19.access.bullet.mail.sp2.yahoo.com (HELO
	nm19.access.bullet.mail.sp2.yahoo.com) (98.139.44.146)
	by server-11.tower-21.messagelabs.com with SMTP;
	21 Nov 2011 00:01:13 -0000
Received: from [98.139.44.101] by nm19.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 21 Nov 2011 00:01:11 -0000
Received: from [98.139.44.88] by tm6.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 21 Nov 2011 00:01:11 -0000
Received: from [127.0.0.1] by omp1025.access.mail.sp2.yahoo.com with NNFMP;
	21 Nov 2011 00:01:11 -0000
X-Yahoo-Newman-Id: 661049.9804.bm@omp1025.access.mail.sp2.yahoo.com
Received: (qmail 89290 invoked from network); 21 Nov 2011 00:01:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1321833671; bh=PYELQoqRkx5nHcuckLhh3qhCSa1Gf59yH37NgO90Opo=;
	h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type;
	b=q2/xGf1oA9vN/4WI/c3xdrlNeAlb3wn3WAinbbkErtvvsTZkuVtgKM7l+f4dJXF6hVOlWsKurHTtOitRJCsSxVpcUyEiLNcRiXVLvLizVHtoMqt8CQ0q2aHYFFMt6DibMD8Yqees344PzNQOUcua4nmutBR55eCuVYbbTmitUiU=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: Q4Ioz7kVM1nVGK7yUy7XErplWiIVTwjFjTXtNz8lVuD2bmZ
	edfwytNb5.6JSWtgmMwTPmHHkyID7_KU7JKpjncnQpS4LmFCFToWc_pAYYa3
	TaFAOe57ICbOF14jbmnUoxRRKg.Not2ne2iQZZCMbJeAiCo6gtlzUGQdRHDI
	V5gAyXOPQLgMf09HWaZ4YgGDOt2iEKG3h.rPgM19t7HhlOWsZW4B18m3hvqR
	x.GiSB4LuYfIvgfh51sSe4hOL_0UfZKq3j5gk3AEymrhHMiWso4tXkbt3rw4
	MGLqZf00Ni_9..CbAj_8uI5X_eIICwDFFY6o3Dls15yHSOpr_3ENrbTNrB3g
	0eFHQQAZ1XCBjRL2lNencTuad_1Fd64LCmeoxNDi1y0eLDISDhxErma7Js5N
	1gsiMQGNoD8LX9C7VktBU1OIJ2tXu2hRhchma9YmdMQXxpm0f9Zf5fN9wvAd
	bAe25X.wt
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@72.145.175.45 with plain)
	by smtp107.sbc.mail.gq1.yahoo.com with SMTP;
	20 Nov 2011 16:01:10 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xensource.com
Date: Sun, 20 Nov 2011 19:01:03 -0500
Message-ID: <2050647.nVkWu3Gdog@dell4550>
User-Agent: KMail/4.7.3 (Linux/2.6.37.6-0.9-default; KDE/4.7.3; i686; ; )
In-Reply-To: <4EC4E44002000078000617F9@nat28.tlf.novell.com>
References: <7877809.94pu0BOf0I@dell4550> <1474452.Ubr0mjN0Wq@dell4550>
	<4EC4E44002000078000617F9@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Flavio <fbcyborg@gmail.com>, xen-users@lists.xensource.com,
	"Fajar A. Nugraha" <list@fajar.net>
Subject: Re: [Xen-devel] BAR 0: cirrusfb load errors prevent hvm domu from
	getting resolutions above 800x600
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu November 17 2011, 9:38:56 AM, Jan Beulich wrote:
> >>> On 17.11.11 at 09:31, jim burns <jim_burn@bellsouth.net> wrote:
> > On Thu November 17 2011, 8:10:08 AM, Jan Beulich wrote:
> >> >>> On 17.11.11 at 00:28, jim burns <jim_burn@bellsouth.net> wrote:
> >> Sounds more like a kernel problem.
> >> 
> >> > <4>[    0.629101] vesafb: cannot reserve video memory at
> >> > 0xf0000000
> >> 
> >> This doesn't tell what component did the reservation before this
> >> point,
> >> but that's what he/you will need to find out. And then compare with
> >> the cirrusfb case.
> > 
> > I thought that's what this meant:
> > 
> > [    0.667812] vesafb: framebuffer at 0xf0000000, mapped to
> > 0xffffc90000580000, using 1875k, total 4096k
> > 
> > Looks like vesafb reserved it.
> 
> No - the absence of the former message means it reserved it. But its
> presence does not provide information on what, in that case, managed
> to reserve it before. But that's what you want to hunt down.

Oops - didn't catch this right away. The 'cannot reserve video memory' message 
(and all messages in my post that have <num> in front) is actually from the 
bare metal case that worked (with radeon). No such message occurs in the 
cirrus case.

I generated the cirrus case extract by searching dmesg for anything about 
'0000:00:02.0', 'cirrus', 'vga', or 'vesa'.

> >> One significant difference of course is the DRM base fb driver in the
> >> radeon case - to compare apples with apples, DRM should really be
> >> removed from the picture.
> > 
> > True. I was just pointing out that there is a mechanism for vesafb
> > handing off
> > control to another video driver:
> > 
> > <3>[  259.974310] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
> > removing generic driver
> > 
> > Any ideas where to go from here? Thanx.
> 
> You could have looked at this easily yourself - cirrusfb_register() (which
> is what calls register_framebuffer(), which is where above message
> originates from) gets called from cirrusfb_pci_register() only *after*
> that function tried to reserve its resources via pci_request_regions().
> (This is in 3.2-rc2, so even the most current driver isn't capable of
> doing this sort of handshake, and afaict that's no different on native,
> so not a Xen issue at all.)

I meant is a BAR 0: error a commonly understood problem with common steps to 
find and fix the *configuration* problem, not where can I tinker with kernel 
code. I would think suse's 2.6.37.1-1.2-desktop kernel would work as is in an 
hvm domain. Or should he be using a different suse kernel 'flavor'? (-
default?) Although, since it doesn't work for his hand-compiled 3.1 either, 
this looks more like a filesystem / sysconfig configuration problem.

> Btw., looking at the title again - I don't think you need cirrusfb to
> get higher resolutions, at least not if you're talking about X (only if
> you merely care about the text consoles this would be the case),
> as long as a respective X driver is present.

Actually, he is loading the xorg cirrus module. It loads two candidates - vesa 
& cirrus. Then it unloads vesa in favor of the better cirrus candidate. 
Unfortunately, after running through all the possible modes, it only accepts:

[    33.240] (--) CIRRUS(0): Virtual size is 800x600 (pitch 1024)
[    33.240] (**) CIRRUS(0): *Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 
Hz
[    33.240] (II) CIRRUS(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  
600 601 605 628 +hsync +vsync (37.9 kHz)
[    33.240] (**) CIRRUS(0): *Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 
Hz
[    33.240] (II) CIRRUS(0): Modeline "800x600"x56.2   36.00  800 824 896 1024  
600 601 603 625 +hsync +vsync (35.2 kHz)
[    33.240] (**) CIRRUS(0): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 59.9 
Hz
[    33.240] (II) CIRRUS(0): Modeline "640x480"x59.9   25.18  640 656 752 800  
480 490 492 525 -hsync -vsync (31.5 kHz)
[    33.240] (==) CIRRUS(0): DPI set to (96, 96)

Xorg.0.log: http://pastebin.com/d49wcUxD

I would be grateful for nay clues you can give me & Flavio. Thanx.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 00:02:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 00:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSHKP-0001Dv-K4; Mon, 21 Nov 2011 00:01:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jim_burn@bellsouth.net>) id 1RSHKO-0001Dd-A6
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 00:01:40 +0000
X-Env-Sender: jim_burn@bellsouth.net
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321833672!4987243!1
X-Originating-IP: [98.139.44.146]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26147 invoked from network); 21 Nov 2011 00:01:13 -0000
Received: from nm19.access.bullet.mail.sp2.yahoo.com (HELO
	nm19.access.bullet.mail.sp2.yahoo.com) (98.139.44.146)
	by server-11.tower-21.messagelabs.com with SMTP;
	21 Nov 2011 00:01:13 -0000
Received: from [98.139.44.101] by nm19.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 21 Nov 2011 00:01:11 -0000
Received: from [98.139.44.88] by tm6.access.bullet.mail.sp2.yahoo.com with
	NNFMP; 21 Nov 2011 00:01:11 -0000
Received: from [127.0.0.1] by omp1025.access.mail.sp2.yahoo.com with NNFMP;
	21 Nov 2011 00:01:11 -0000
X-Yahoo-Newman-Id: 661049.9804.bm@omp1025.access.mail.sp2.yahoo.com
Received: (qmail 89290 invoked from network); 21 Nov 2011 00:01:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024;
	t=1321833671; bh=PYELQoqRkx5nHcuckLhh3qhCSa1Gf59yH37NgO90Opo=;
	h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:Subject:Date:Message-ID:User-Agent:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type;
	b=q2/xGf1oA9vN/4WI/c3xdrlNeAlb3wn3WAinbbkErtvvsTZkuVtgKM7l+f4dJXF6hVOlWsKurHTtOitRJCsSxVpcUyEiLNcRiXVLvLizVHtoMqt8CQ0q2aHYFFMt6DibMD8Yqees344PzNQOUcua4nmutBR55eCuVYbbTmitUiU=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: Q4Ioz7kVM1nVGK7yUy7XErplWiIVTwjFjTXtNz8lVuD2bmZ
	edfwytNb5.6JSWtgmMwTPmHHkyID7_KU7JKpjncnQpS4LmFCFToWc_pAYYa3
	TaFAOe57ICbOF14jbmnUoxRRKg.Not2ne2iQZZCMbJeAiCo6gtlzUGQdRHDI
	V5gAyXOPQLgMf09HWaZ4YgGDOt2iEKG3h.rPgM19t7HhlOWsZW4B18m3hvqR
	x.GiSB4LuYfIvgfh51sSe4hOL_0UfZKq3j5gk3AEymrhHMiWso4tXkbt3rw4
	MGLqZf00Ni_9..CbAj_8uI5X_eIICwDFFY6o3Dls15yHSOpr_3ENrbTNrB3g
	0eFHQQAZ1XCBjRL2lNencTuad_1Fd64LCmeoxNDi1y0eLDISDhxErma7Js5N
	1gsiMQGNoD8LX9C7VktBU1OIJ2tXu2hRhchma9YmdMQXxpm0f9Zf5fN9wvAd
	bAe25X.wt
X-Yahoo-SMTP: g0AhWW2swBA2djJKuhuwxPlPqLrHlDrycdPnfR9kZNrpKCA-
Received: from dell4550.localnet (jim_burn@72.145.175.45 with plain)
	by smtp107.sbc.mail.gq1.yahoo.com with SMTP;
	20 Nov 2011 16:01:10 -0800 PST
From: jim burns <jim_burn@bellsouth.net>
To: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xensource.com
Date: Sun, 20 Nov 2011 19:01:03 -0500
Message-ID: <2050647.nVkWu3Gdog@dell4550>
User-Agent: KMail/4.7.3 (Linux/2.6.37.6-0.9-default; KDE/4.7.3; i686; ; )
In-Reply-To: <4EC4E44002000078000617F9@nat28.tlf.novell.com>
References: <7877809.94pu0BOf0I@dell4550> <1474452.Ubr0mjN0Wq@dell4550>
	<4EC4E44002000078000617F9@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Flavio <fbcyborg@gmail.com>, xen-users@lists.xensource.com,
	"Fajar A. Nugraha" <list@fajar.net>
Subject: Re: [Xen-devel] BAR 0: cirrusfb load errors prevent hvm domu from
	getting resolutions above 800x600
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu November 17 2011, 9:38:56 AM, Jan Beulich wrote:
> >>> On 17.11.11 at 09:31, jim burns <jim_burn@bellsouth.net> wrote:
> > On Thu November 17 2011, 8:10:08 AM, Jan Beulich wrote:
> >> >>> On 17.11.11 at 00:28, jim burns <jim_burn@bellsouth.net> wrote:
> >> Sounds more like a kernel problem.
> >> 
> >> > <4>[    0.629101] vesafb: cannot reserve video memory at
> >> > 0xf0000000
> >> 
> >> This doesn't tell what component did the reservation before this
> >> point,
> >> but that's what he/you will need to find out. And then compare with
> >> the cirrusfb case.
> > 
> > I thought that's what this meant:
> > 
> > [    0.667812] vesafb: framebuffer at 0xf0000000, mapped to
> > 0xffffc90000580000, using 1875k, total 4096k
> > 
> > Looks like vesafb reserved it.
> 
> No - the absence of the former message means it reserved it. But its
> presence does not provide information on what, in that case, managed
> to reserve it before. But that's what you want to hunt down.

Oops - didn't catch this right away. The 'cannot reserve video memory' message 
(and all messages in my post that have <num> in front) is actually from the 
bare metal case that worked (with radeon). No such message occurs in the 
cirrus case.

I generated the cirrus case extract by searching dmesg for anything about 
'0000:00:02.0', 'cirrus', 'vga', or 'vesa'.

> >> One significant difference of course is the DRM base fb driver in the
> >> radeon case - to compare apples with apples, DRM should really be
> >> removed from the picture.
> > 
> > True. I was just pointing out that there is a mechanism for vesafb
> > handing off
> > control to another video driver:
> > 
> > <3>[  259.974310] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
> > removing generic driver
> > 
> > Any ideas where to go from here? Thanx.
> 
> You could have looked at this easily yourself - cirrusfb_register() (which
> is what calls register_framebuffer(), which is where above message
> originates from) gets called from cirrusfb_pci_register() only *after*
> that function tried to reserve its resources via pci_request_regions().
> (This is in 3.2-rc2, so even the most current driver isn't capable of
> doing this sort of handshake, and afaict that's no different on native,
> so not a Xen issue at all.)

I meant is a BAR 0: error a commonly understood problem with common steps to 
find and fix the *configuration* problem, not where can I tinker with kernel 
code. I would think suse's 2.6.37.1-1.2-desktop kernel would work as is in an 
hvm domain. Or should he be using a different suse kernel 'flavor'? (-
default?) Although, since it doesn't work for his hand-compiled 3.1 either, 
this looks more like a filesystem / sysconfig configuration problem.

> Btw., looking at the title again - I don't think you need cirrusfb to
> get higher resolutions, at least not if you're talking about X (only if
> you merely care about the text consoles this would be the case),
> as long as a respective X driver is present.

Actually, he is loading the xorg cirrus module. It loads two candidates - vesa 
& cirrus. Then it unloads vesa in favor of the better cirrus candidate. 
Unfortunately, after running through all the possible modes, it only accepts:

[    33.240] (--) CIRRUS(0): Virtual size is 800x600 (pitch 1024)
[    33.240] (**) CIRRUS(0): *Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 
Hz
[    33.240] (II) CIRRUS(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  
600 601 605 628 +hsync +vsync (37.9 kHz)
[    33.240] (**) CIRRUS(0): *Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 
Hz
[    33.240] (II) CIRRUS(0): Modeline "800x600"x56.2   36.00  800 824 896 1024  
600 601 603 625 +hsync +vsync (35.2 kHz)
[    33.240] (**) CIRRUS(0): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 59.9 
Hz
[    33.240] (II) CIRRUS(0): Modeline "640x480"x59.9   25.18  640 656 752 800  
480 490 492 525 -hsync -vsync (31.5 kHz)
[    33.240] (==) CIRRUS(0): DPI set to (96, 96)

Xorg.0.log: http://pastebin.com/d49wcUxD

I would be grateful for nay clues you can give me & Flavio. Thanx.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 00:47:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 00:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSI27-0001zE-FK; Mon, 21 Nov 2011 00:46:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>)
	id 1RSI25-0001z6-Rl; Mon, 21 Nov 2011 00:46:50 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1321836382!4910662!1
X-Originating-IP: [216.33.127.80]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29516 invoked from network); 21 Nov 2011 00:46:22 -0000
Received: from mta11.charter.net (HELO mta11.charter.net) (216.33.127.80)
	by server-10.tower-21.messagelabs.com with SMTP;
	21 Nov 2011 00:46:22 -0000
Received: from imp09 ([10.20.200.9]) by mta11.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111121004621.ODAJ4019.mta11.charter.net@imp09>;
	Sun, 20 Nov 2011 19:46:21 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp09 with smtp.charter.net
	id zcmM1h00946xN4z05cmMhQ; Sun, 20 Nov 2011 19:46:21 -0500
X-Authority-Analysis: v=1.1 cv=6DnK9SlspjQUafU6MzYmZAt1wpB1MUaNH28Mo/Kfxqk=
	c=1 sm=1 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10 a=YBs1tj9y_9UA:10
	a=kj9zAlcOel0A:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17
	a=aNc6OGhn0MZy8IbZ0toA:9
	a=CjuIK1q_8ugA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id ED83B203C8;
	Mon, 21 Nov 2011 00:46:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id iYCv7v8ApP9r; Sun, 20 Nov 2011 19:46:25 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id 2D80920348;
	Sun, 20 Nov 2011 19:46:25 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <xen-devel@lists.xensource.com>
Date: Sun, 20 Nov 2011 19:45:53 -0500
Message-ID: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Acyn5enxryJDOn9PS06sxbfGL/GyGw==
Content-Language: en-us
Cc: xen-users@lists.xensource.com
Subject: [Xen-devel] BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I noticed recently that there is no real easy way to get the kernel driver
for blktap working in mainline.  I've pulled down the source from Daniel
Stodden's linux git tree on xensource, but it looks like it's for debian and
I'm running Fedora 14, so I'm trying to sort it out.  I run the 3.1.x kernel
and don't want to go back to the 2.6.32 that Jeremy has, which has the
blktap driver in it.  Is there anything out there that will patch a 3.1.x
mainline kernel to include the blktap driver?  I want to try out drbd/remus,
but it's not going anywhere at the moment.  Thanks.
Mike


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 00:47:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 00:47:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSI27-0001zE-FK; Mon, 21 Nov 2011 00:46:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>)
	id 1RSI25-0001z6-Rl; Mon, 21 Nov 2011 00:46:50 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1321836382!4910662!1
X-Originating-IP: [216.33.127.80]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29516 invoked from network); 21 Nov 2011 00:46:22 -0000
Received: from mta11.charter.net (HELO mta11.charter.net) (216.33.127.80)
	by server-10.tower-21.messagelabs.com with SMTP;
	21 Nov 2011 00:46:22 -0000
Received: from imp09 ([10.20.200.9]) by mta11.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111121004621.ODAJ4019.mta11.charter.net@imp09>;
	Sun, 20 Nov 2011 19:46:21 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp09 with smtp.charter.net
	id zcmM1h00946xN4z05cmMhQ; Sun, 20 Nov 2011 19:46:21 -0500
X-Authority-Analysis: v=1.1 cv=6DnK9SlspjQUafU6MzYmZAt1wpB1MUaNH28Mo/Kfxqk=
	c=1 sm=1 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10 a=YBs1tj9y_9UA:10
	a=kj9zAlcOel0A:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17
	a=aNc6OGhn0MZy8IbZ0toA:9
	a=CjuIK1q_8ugA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id ED83B203C8;
	Mon, 21 Nov 2011 00:46:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id iYCv7v8ApP9r; Sun, 20 Nov 2011 19:46:25 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id 2D80920348;
	Sun, 20 Nov 2011 19:46:25 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <xen-devel@lists.xensource.com>
Date: Sun, 20 Nov 2011 19:45:53 -0500
Message-ID: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Acyn5enxryJDOn9PS06sxbfGL/GyGw==
Content-Language: en-us
Cc: xen-users@lists.xensource.com
Subject: [Xen-devel] BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I noticed recently that there is no real easy way to get the kernel driver
for blktap working in mainline.  I've pulled down the source from Daniel
Stodden's linux git tree on xensource, but it looks like it's for debian and
I'm running Fedora 14, so I'm trying to sort it out.  I run the 3.1.x kernel
and don't want to go back to the 2.6.32 that Jeremy has, which has the
blktap driver in it.  Is there anything out there that will patch a 3.1.x
mainline kernel to include the blktap driver?  I want to try out drbd/remus,
but it's not going anywhere at the moment.  Thanks.
Mike


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 03:31:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 03:31:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSKam-0003Dl-GF; Mon, 21 Nov 2011 03:30:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jxinpku@gmail.com>) id 1RSKak-0003Dg-TO
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 03:30:47 +0000
X-Env-Sender: jxinpku@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321846218!5039808!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22550 invoked from network); 21 Nov 2011 03:30:19 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 03:30:19 -0000
Received: by ghbf1 with SMTP id f1so3737870ghb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 20 Nov 2011 19:30:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=fqRkRuzd0k1eT/pDgU6Ung/jd2LptafspArq/+X6nEI=;
	b=rm6EYd39GnJSZY2slVxKQOJaxpk7oP5/IIFKGXrZWyx/f50X3z0LaweYtaoI1NYT+n
	b0axuSb800LDT2gwCuGDOwzFrnyLCvV39Zm20p8/udreS9nUx7N6BWnexuytVxjnE/7+
	Z6eI09FrdK0qzcDavcLYPlfAPF1SpvF7T5VSg=
MIME-Version: 1.0
Received: by 10.68.72.33 with SMTP id a1mr32362362pbv.44.1321846217404; Sun,
	20 Nov 2011 19:30:17 -0800 (PST)
Received: by 10.143.8.14 with HTTP; Sun, 20 Nov 2011 19:30:17 -0800 (PST)
Date: Sun, 20 Nov 2011 22:30:17 -0500
Message-ID: <CAKpDea=ZVyz2Oza8p0UHijuspfkMCpQjSD_Kc_yDz8ftrrrucw@mail.gmail.com>
From: Xin Jin <jxinpku@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel]  Create shared memory between HVM domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6347439374767312986=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6347439374767312986==
Content-Type: multipart/alternative; boundary=f46d0417011f3c703404b2364eed

--f46d0417011f3c703404b2364eed
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I just want to know if it is possible to use grant table to create shared
memory between HVM domU.

I tried in Xen 4.1.1 with Linux kernel 3.1.1.
It seems that I cannot create it.

Cannot we do that between HVM domU now?

--f46d0417011f3c703404b2364eed
Content-Type: text/html; charset=ISO-8859-1

Hi,<div><br></div><div>I just want to know if it is possible to use grant table to create shared memory between HVM domU.</div><div><br></div><div>I tried in Xen 4.1.1 with Linux kernel 3.1.1.</div><div>It seems that I cannot create it.</div>
<div><br></div><div>Cannot we do that between HVM domU now?<br><br>
</div>

--f46d0417011f3c703404b2364eed--


--===============6347439374767312986==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6347439374767312986==--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 03:31:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 03:31:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSKam-0003Dl-GF; Mon, 21 Nov 2011 03:30:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jxinpku@gmail.com>) id 1RSKak-0003Dg-TO
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 03:30:47 +0000
X-Env-Sender: jxinpku@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321846218!5039808!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22550 invoked from network); 21 Nov 2011 03:30:19 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 03:30:19 -0000
Received: by ghbf1 with SMTP id f1so3737870ghb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 20 Nov 2011 19:30:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=fqRkRuzd0k1eT/pDgU6Ung/jd2LptafspArq/+X6nEI=;
	b=rm6EYd39GnJSZY2slVxKQOJaxpk7oP5/IIFKGXrZWyx/f50X3z0LaweYtaoI1NYT+n
	b0axuSb800LDT2gwCuGDOwzFrnyLCvV39Zm20p8/udreS9nUx7N6BWnexuytVxjnE/7+
	Z6eI09FrdK0qzcDavcLYPlfAPF1SpvF7T5VSg=
MIME-Version: 1.0
Received: by 10.68.72.33 with SMTP id a1mr32362362pbv.44.1321846217404; Sun,
	20 Nov 2011 19:30:17 -0800 (PST)
Received: by 10.143.8.14 with HTTP; Sun, 20 Nov 2011 19:30:17 -0800 (PST)
Date: Sun, 20 Nov 2011 22:30:17 -0500
Message-ID: <CAKpDea=ZVyz2Oza8p0UHijuspfkMCpQjSD_Kc_yDz8ftrrrucw@mail.gmail.com>
From: Xin Jin <jxinpku@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel]  Create shared memory between HVM domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6347439374767312986=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6347439374767312986==
Content-Type: multipart/alternative; boundary=f46d0417011f3c703404b2364eed

--f46d0417011f3c703404b2364eed
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I just want to know if it is possible to use grant table to create shared
memory between HVM domU.

I tried in Xen 4.1.1 with Linux kernel 3.1.1.
It seems that I cannot create it.

Cannot we do that between HVM domU now?

--f46d0417011f3c703404b2364eed
Content-Type: text/html; charset=ISO-8859-1

Hi,<div><br></div><div>I just want to know if it is possible to use grant table to create shared memory between HVM domU.</div><div><br></div><div>I tried in Xen 4.1.1 with Linux kernel 3.1.1.</div><div>It seems that I cannot create it.</div>
<div><br></div><div>Cannot we do that between HVM domU now?<br><br>
</div>

--f46d0417011f3c703404b2364eed--


--===============6347439374767312986==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6347439374767312986==--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 03:42:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 03:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSKlY-0003Ry-BM; Mon, 21 Nov 2011 03:41:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSKlW-0003Rt-1c
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 03:41:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321846886!4305992!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23379 invoked from network); 21 Nov 2011 03:41:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 03:41:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,544,1315180800"; 
   d="scan'208";a="9029969"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 03:40:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 03:40:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSKkd-0001OZ-2J;
	Mon, 21 Nov 2011 03:40:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSKkc-0002KL-LB;
	Mon, 21 Nov 2011 03:40:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RSKkc-0002KL-LB@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 21 Nov 2011 03:40:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-intel
test redhat-install

Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  7a9a1261a6b0
  Bug not present: 9a1a71f7bef2


  changeset:   24163:7a9a1261a6b0
  user:        Jean Guyader <jean.guyader@eu.citrix.com>
  date:        Fri Nov 18 13:41:33 2011 +0000
      
      add_to_physmap: Move the code for XENMEM_add_to_physmap
      
      Move the code for the XENMEM_add_to_physmap case into it's own
      function (xenmem_add_to_physmap).
      
      Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 9915 fail [host=field-cricket] / 9855 [host=itch-mite] 9832 [host=gall-mite] 9817 ok.
Failure / basis pass flights: 9915 / 9817
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 335e8273a3f3
Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 dbdc840f8f62
Generating revisions with ./adhoc-revtuple-generator  git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#52834188eedfbbca5636fd869d4c86b3b3044439-52834188eedfbbca5636fd869d4c86b3b3044439 http://xenbits.xen.org/staging/xen-unstable.hg#dbdc840f8f62-335e8273a3f3
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 107 nodes in revision graph
Searching for test results:
 9817 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 dbdc840f8f62
 9866 [host=gall-mite]
 9878 [host=bush-cricket]
 9864 []
 9867 [host=gall-mite]
 9832 [host=gall-mite]
 9883 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 7a9a1261a6b0
 9919 [host=gall-mite]
 9868 [host=itch-mite]
 9895 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 335e8273a3f3
 9855 [host=itch-mite]
 9885 [host=bush-cricket]
 9873 [host=itch-mite]
 9857 [host=bush-cricket]
 9874 [host=itch-mite]
 9859 [host=bush-cricket]
 9911 [host=itch-mite]
 9887 [host=bush-cricket]
 9861 [host=bush-cricket]
 9860 [host=gall-mite]
 9897 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 aeb628c5af3f
 9888 [host=bush-cricket]
 9862 [host=bush-cricket]
 9875 [host=itch-mite]
 9865 [host=gall-mite]
 9901 [host=itch-mite]
 9872 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 fe3e9d0c123c
 9889 [host=bush-cricket]
 9877 [host=itch-mite]
 9898 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 9a1a71f7bef2
 9879 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 dbdc840f8f62
 9890 [host=bush-cricket]
 9881 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 fe3e9d0c123c
 9899 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 7a9a1261a6b0
 9882 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 d7e6bfa114d0
 9891 [host=bush-cricket]
 9904 [host=bush-cricket]
 9884 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 335e8273a3f3
 9893 [host=bush-cricket]
 9892 [host=bush-cricket]
 9912 [host=itch-mite]
 9894 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 dbdc840f8f62
 9907 [host=itch-mite]
 9900 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 9a1a71f7bef2
 9902 [host=bush-cricket]
 9927 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 7a9a1261a6b0
 9903 [host=bush-cricket]
 9913 [host=itch-mite]
 9922 [host=gall-mite]
 9908 [host=itch-mite]
 9916 [host=gall-mite]
 9910 [host=itch-mite]
 9906 [host=gall-mite]
 9920 [host=gall-mite]
 9914 [host=itch-mite]
 9918 [host=gall-mite]
 9923 [host=gall-mite]
 9925 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 7a9a1261a6b0
 9921 [host=gall-mite]
 9915 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 335e8273a3f3
 9926 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 9a1a71f7bef2
Searching for interesting versions
 Result found: flight 9817 (pass), for basis pass
 Result found: flight 9884 (fail), for basis failure
 Repro found: flight 9894 (pass), for basis pass
 Repro found: flight 9895 (fail), for basis failure
 0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 9a1a71f7bef2
No revisions left to test, checking graph state.
 Result found: flight 9898 (pass), for last pass
 Result found: flight 9899 (fail), for first failure
 Repro found: flight 9900 (pass), for last pass
 Repro found: flight 9925 (fail), for first failure
 Repro found: flight 9926 (pass), for last pass
 Repro found: flight 9927 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  7a9a1261a6b0
  Bug not present: 9a1a71f7bef2

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24163:7a9a1261a6b0
  user:        Jean Guyader <jean.guyader@eu.citrix.com>
  date:        Fri Nov 18 13:41:33 2011 +0000
      
      add_to_physmap: Move the code for XENMEM_add_to_physmap
      
      Move the code for the XENMEM_add_to_physmap case into it's own
      function (xenmem_add_to_physmap).
      
      Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.{dot,ps,png,html}.
----------------------------------------
9927: ALL FAIL

flight 9927 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9927/


jobs:
 test-amd64-i386-rhel6hvm-intel                               fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 03:42:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 03:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSKlY-0003Ry-BM; Mon, 21 Nov 2011 03:41:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSKlW-0003Rt-1c
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 03:41:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321846886!4305992!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23379 invoked from network); 21 Nov 2011 03:41:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 03:41:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,544,1315180800"; 
   d="scan'208";a="9029969"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 03:40:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 03:40:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSKkd-0001OZ-2J;
	Mon, 21 Nov 2011 03:40:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSKkc-0002KL-LB;
	Mon, 21 Nov 2011 03:40:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RSKkc-0002KL-LB@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 21 Nov 2011 03:40:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-intel
test redhat-install

Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  7a9a1261a6b0
  Bug not present: 9a1a71f7bef2


  changeset:   24163:7a9a1261a6b0
  user:        Jean Guyader <jean.guyader@eu.citrix.com>
  date:        Fri Nov 18 13:41:33 2011 +0000
      
      add_to_physmap: Move the code for XENMEM_add_to_physmap
      
      Move the code for the XENMEM_add_to_physmap case into it's own
      function (xenmem_add_to_physmap).
      
      Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 9915 fail [host=field-cricket] / 9855 [host=itch-mite] 9832 [host=gall-mite] 9817 ok.
Failure / basis pass flights: 9915 / 9817
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 335e8273a3f3
Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 dbdc840f8f62
Generating revisions with ./adhoc-revtuple-generator  git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#52834188eedfbbca5636fd869d4c86b3b3044439-52834188eedfbbca5636fd869d4c86b3b3044439 http://xenbits.xen.org/staging/xen-unstable.hg#dbdc840f8f62-335e8273a3f3
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 107 nodes in revision graph
Searching for test results:
 9817 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 dbdc840f8f62
 9866 [host=gall-mite]
 9878 [host=bush-cricket]
 9864 []
 9867 [host=gall-mite]
 9832 [host=gall-mite]
 9883 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 7a9a1261a6b0
 9919 [host=gall-mite]
 9868 [host=itch-mite]
 9895 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 335e8273a3f3
 9855 [host=itch-mite]
 9885 [host=bush-cricket]
 9873 [host=itch-mite]
 9857 [host=bush-cricket]
 9874 [host=itch-mite]
 9859 [host=bush-cricket]
 9911 [host=itch-mite]
 9887 [host=bush-cricket]
 9861 [host=bush-cricket]
 9860 [host=gall-mite]
 9897 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 aeb628c5af3f
 9888 [host=bush-cricket]
 9862 [host=bush-cricket]
 9875 [host=itch-mite]
 9865 [host=gall-mite]
 9901 [host=itch-mite]
 9872 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 fe3e9d0c123c
 9889 [host=bush-cricket]
 9877 [host=itch-mite]
 9898 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 9a1a71f7bef2
 9879 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 dbdc840f8f62
 9890 [host=bush-cricket]
 9881 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 fe3e9d0c123c
 9899 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 7a9a1261a6b0
 9882 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 d7e6bfa114d0
 9891 [host=bush-cricket]
 9904 [host=bush-cricket]
 9884 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 335e8273a3f3
 9893 [host=bush-cricket]
 9892 [host=bush-cricket]
 9912 [host=itch-mite]
 9894 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 dbdc840f8f62
 9907 [host=itch-mite]
 9900 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 9a1a71f7bef2
 9902 [host=bush-cricket]
 9927 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 7a9a1261a6b0
 9903 [host=bush-cricket]
 9913 [host=itch-mite]
 9922 [host=gall-mite]
 9908 [host=itch-mite]
 9916 [host=gall-mite]
 9910 [host=itch-mite]
 9906 [host=gall-mite]
 9920 [host=gall-mite]
 9914 [host=itch-mite]
 9918 [host=gall-mite]
 9923 [host=gall-mite]
 9925 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 7a9a1261a6b0
 9921 [host=gall-mite]
 9915 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 335e8273a3f3
 9926 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 9a1a71f7bef2
Searching for interesting versions
 Result found: flight 9817 (pass), for basis pass
 Result found: flight 9884 (fail), for basis failure
 Repro found: flight 9894 (pass), for basis pass
 Repro found: flight 9895 (fail), for basis failure
 0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 52834188eedfbbca5636fd869d4c86b3b3044439 9a1a71f7bef2
No revisions left to test, checking graph state.
 Result found: flight 9898 (pass), for last pass
 Result found: flight 9899 (fail), for first failure
 Repro found: flight 9900 (pass), for last pass
 Repro found: flight 9925 (fail), for first failure
 Repro found: flight 9926 (pass), for last pass
 Repro found: flight 9927 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  7a9a1261a6b0
  Bug not present: 9a1a71f7bef2

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24163:7a9a1261a6b0
  user:        Jean Guyader <jean.guyader@eu.citrix.com>
  date:        Fri Nov 18 13:41:33 2011 +0000
      
      add_to_physmap: Move the code for XENMEM_add_to_physmap
      
      Move the code for the XENMEM_add_to_physmap case into it's own
      function (xenmem_add_to_physmap).
      
      Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.{dot,ps,png,html}.
----------------------------------------
9927: ALL FAIL

flight 9927 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9927/


jobs:
 test-amd64-i386-rhel6hvm-intel                               fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 04:34:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 04:34:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSLZX-0003oN-TR; Mon, 21 Nov 2011 04:33:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSLZW-0003oI-BT
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 04:33:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1321849987!3897285!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20008 invoked from network); 21 Nov 2011 04:33:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 04:33:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,545,1315180800"; 
   d="scan'208";a="9030132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 04:33:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 04:33:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSLZ4-0001gs-66;
	Mon, 21 Nov 2011 04:33:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSLZ4-00035S-5N;
	Mon, 21 Nov 2011 04:33:06 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9924-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 21 Nov 2011 04:33:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9924: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9924 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9924/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 04:34:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 04:34:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSLZX-0003oN-TR; Mon, 21 Nov 2011 04:33:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSLZW-0003oI-BT
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 04:33:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1321849987!3897285!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20008 invoked from network); 21 Nov 2011 04:33:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 04:33:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,545,1315180800"; 
   d="scan'208";a="9030132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 04:33:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 04:33:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSLZ4-0001gs-66;
	Mon, 21 Nov 2011 04:33:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSLZ4-00035S-5N;
	Mon, 21 Nov 2011 04:33:06 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9924-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 21 Nov 2011 04:33:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9924: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9924 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9924/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 05:05:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 05:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSM3L-000451-O1; Mon, 21 Nov 2011 05:04:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>)
	id 1RSM3K-00044t-Gu; Mon, 21 Nov 2011 05:04:22 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321851833!4312984!1
X-Originating-IP: [142.103.6.52]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8487 invoked from network); 21 Nov 2011 05:03:54 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 05:03:54 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pAL53ohO026782
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL);
	Sun, 20 Nov 2011 21:03:51 -0800
Received: by bkbzt12 with SMTP id zt12so8878887bkb.30
	for <multiple recipients>; Sun, 20 Nov 2011 21:03:49 -0800 (PST)
Received: by 10.204.141.24 with SMTP id k24mr11322346bku.97.1321851829140;
	Sun, 20 Nov 2011 21:03:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.177.19 with HTTP; Sun, 20 Nov 2011 21:03:08 -0800 (PST)
In-Reply-To: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Sun, 20 Nov 2011 21:03:08 -0800
Message-ID: <CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
To: "Michael A. Collins" <mike.a.collins@ark-net.org>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2976937535460564963=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2976937535460564963==
Content-Type: multipart/alternative; boundary=0015175d682ab8be8c04b2379c71

--0015175d682ab8be8c04b2379c71
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Nov 20, 2011 at 4:45 PM, Michael A. Collins <
mike.a.collins@ark-net.org> wrote:

> I noticed recently that there is no real easy way to get the kernel driver
> for blktap working in mainline.  I've pulled down the source from Daniel
> Stodden's linux git tree on xensource, but it looks like it's for debian
> and
> I'm running Fedora 14, so I'm trying to sort it out.  I run the 3.1.x
> kernel
> and don't want to go back to the 2.6.32 that Jeremy has, which has the
> blktap driver in it.  Is there anything out there that will patch a 3.1.x
> mainline kernel to include the blktap driver?  I want to try out
> drbd/remus,
>

drbd/remus - why  do you need blktap ?

shriram

> but it's not going anywhere at the moment.  Thanks.
> Mike
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--0015175d682ab8be8c04b2379c71
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, Nov 20, 2011 at 4:45 PM, Michael=
 A. Collins <span dir=3D"ltr">&lt;<a href=3D"mailto:mike.a.collins@ark-net.=
org">mike.a.collins@ark-net.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">

I noticed recently that there is no real easy way to get the kernel driver<=
br>
for blktap working in mainline. =A0I&#39;ve pulled down the source from Dan=
iel<br>
Stodden&#39;s linux git tree on xensource, but it looks like it&#39;s for d=
ebian and<br>
I&#39;m running Fedora 14, so I&#39;m trying to sort it out. =A0I run the 3=
.1.x kernel<br>
and don&#39;t want to go back to the 2.6.32 that Jeremy has, which has the<=
br>
blktap driver in it. =A0Is there anything out there that will patch a 3.1.x=
<br>
mainline kernel to include the blktap driver? =A0I want to try out drbd/rem=
us,<br></blockquote><div><br>drbd/remus - why=A0 do you need blktap ?<br><b=
r>shriram<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0=
pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;=
">


but it&#39;s not going anywhere at the moment. =A0Thanks.<br>
Mike<br>
<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>

--0015175d682ab8be8c04b2379c71--


--===============2976937535460564963==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2976937535460564963==--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 05:05:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 05:05:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSM3L-000451-O1; Mon, 21 Nov 2011 05:04:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>)
	id 1RSM3K-00044t-Gu; Mon, 21 Nov 2011 05:04:22 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321851833!4312984!1
X-Originating-IP: [142.103.6.52]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8487 invoked from network); 21 Nov 2011 05:03:54 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 05:03:54 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pAL53ohO026782
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL);
	Sun, 20 Nov 2011 21:03:51 -0800
Received: by bkbzt12 with SMTP id zt12so8878887bkb.30
	for <multiple recipients>; Sun, 20 Nov 2011 21:03:49 -0800 (PST)
Received: by 10.204.141.24 with SMTP id k24mr11322346bku.97.1321851829140;
	Sun, 20 Nov 2011 21:03:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.177.19 with HTTP; Sun, 20 Nov 2011 21:03:08 -0800 (PST)
In-Reply-To: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Sun, 20 Nov 2011 21:03:08 -0800
Message-ID: <CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
To: "Michael A. Collins" <mike.a.collins@ark-net.org>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2976937535460564963=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2976937535460564963==
Content-Type: multipart/alternative; boundary=0015175d682ab8be8c04b2379c71

--0015175d682ab8be8c04b2379c71
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Nov 20, 2011 at 4:45 PM, Michael A. Collins <
mike.a.collins@ark-net.org> wrote:

> I noticed recently that there is no real easy way to get the kernel driver
> for blktap working in mainline.  I've pulled down the source from Daniel
> Stodden's linux git tree on xensource, but it looks like it's for debian
> and
> I'm running Fedora 14, so I'm trying to sort it out.  I run the 3.1.x
> kernel
> and don't want to go back to the 2.6.32 that Jeremy has, which has the
> blktap driver in it.  Is there anything out there that will patch a 3.1.x
> mainline kernel to include the blktap driver?  I want to try out
> drbd/remus,
>

drbd/remus - why  do you need blktap ?

shriram

> but it's not going anywhere at the moment.  Thanks.
> Mike
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

--0015175d682ab8be8c04b2379c71
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, Nov 20, 2011 at 4:45 PM, Michael=
 A. Collins <span dir=3D"ltr">&lt;<a href=3D"mailto:mike.a.collins@ark-net.=
org">mike.a.collins@ark-net.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">

I noticed recently that there is no real easy way to get the kernel driver<=
br>
for blktap working in mainline. =A0I&#39;ve pulled down the source from Dan=
iel<br>
Stodden&#39;s linux git tree on xensource, but it looks like it&#39;s for d=
ebian and<br>
I&#39;m running Fedora 14, so I&#39;m trying to sort it out. =A0I run the 3=
.1.x kernel<br>
and don&#39;t want to go back to the 2.6.32 that Jeremy has, which has the<=
br>
blktap driver in it. =A0Is there anything out there that will patch a 3.1.x=
<br>
mainline kernel to include the blktap driver? =A0I want to try out drbd/rem=
us,<br></blockquote><div><br>drbd/remus - why=A0 do you need blktap ?<br><b=
r>shriram<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0=
pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;=
">


but it&#39;s not going anywhere at the moment. =A0Thanks.<br>
Mike<br>
<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>

--0015175d682ab8be8c04b2379c71--


--===============2976937535460564963==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2976937535460564963==--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 05:22:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 05:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSMKl-0004lW-Ea; Mon, 21 Nov 2011 05:22:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rusty@ozlabs.org>) id 1RSMKi-0004lK-Mj
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 05:22:20 +0000
X-Env-Sender: rusty@ozlabs.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1321852900!55781878!1
X-Originating-IP: [203.10.76.45]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30755 invoked from network); 21 Nov 2011 05:21:43 -0000
Received: from ozlabs.org (HELO ozlabs.org) (203.10.76.45)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 05:21:43 -0000
Received: by ozlabs.org (Postfix, from userid 1011)
	id D33E2B7217; Mon, 21 Nov 2011 16:21:51 +1100 (EST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Miche Baker-Harvey <miche@google.com>
In-Reply-To: <CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
User-Agent: Notmuch/0.6.1-1 (http://notmuchmail.org) Emacs/23.3.1
	(i686-pc-linux-gnu)
Date: Mon, 21 Nov 2011 15:31:04 +1030
Message-ID: <87lira9ii7.fsf@rustcorp.com.au>
MIME-Version: 1.0
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Amit Shah <amit.shah@redhat.com>,
	Mike Waychison <mikew@google.com>, ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 17 Nov 2011 10:57:37 -0800, Miche Baker-Harvey <miche@google.com> wrote:
> Rusty, Michael, Stephen, et al,
> 
> Thanks for your comments on these patches.
> 
> For what I'm trying to do, all three patches are necessary, but maybe
> I'm going about it the wrong way. Your input would be appreciated.
> I'm in no way claiming that these patches are "right", just that it's
> working for me, and that what's in the current pool is not.

We have to *understand* the code.  If we don't, we need to rewrite the
code so we *do* understand it, or make way for someone who does.

I'm looking at the kvm man page to try to figure out how to have virtio
console, and it's deeply unclear.  What kvm commandline are you using?
I'll try to debug it here, and see what I learn about hvc_console.

Cheers,
Rusty.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 05:22:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 05:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSMKl-0004lW-Ea; Mon, 21 Nov 2011 05:22:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rusty@ozlabs.org>) id 1RSMKi-0004lK-Mj
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 05:22:20 +0000
X-Env-Sender: rusty@ozlabs.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1321852900!55781878!1
X-Originating-IP: [203.10.76.45]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30755 invoked from network); 21 Nov 2011 05:21:43 -0000
Received: from ozlabs.org (HELO ozlabs.org) (203.10.76.45)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 05:21:43 -0000
Received: by ozlabs.org (Postfix, from userid 1011)
	id D33E2B7217; Mon, 21 Nov 2011 16:21:51 +1100 (EST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Miche Baker-Harvey <miche@google.com>
In-Reply-To: <CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
User-Agent: Notmuch/0.6.1-1 (http://notmuchmail.org) Emacs/23.3.1
	(i686-pc-linux-gnu)
Date: Mon, 21 Nov 2011 15:31:04 +1030
Message-ID: <87lira9ii7.fsf@rustcorp.com.au>
MIME-Version: 1.0
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Amit Shah <amit.shah@redhat.com>,
	Mike Waychison <mikew@google.com>, ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 17 Nov 2011 10:57:37 -0800, Miche Baker-Harvey <miche@google.com> wrote:
> Rusty, Michael, Stephen, et al,
> 
> Thanks for your comments on these patches.
> 
> For what I'm trying to do, all three patches are necessary, but maybe
> I'm going about it the wrong way. Your input would be appreciated.
> I'm in no way claiming that these patches are "right", just that it's
> working for me, and that what's in the current pool is not.

We have to *understand* the code.  If we don't, we need to rewrite the
code so we *do* understand it, or make way for someone who does.

I'm looking at the kvm man page to try to figure out how to have virtio
console, and it's deeply unclear.  What kvm commandline are you using?
I'll try to debug it here, and see what I learn about hvc_console.

Cheers,
Rusty.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:05:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:05:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSOsP-0006Ni-7H; Mon, 21 Nov 2011 08:05:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSOsO-0006Nd-LR
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:05:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321862649!57580173!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1090 invoked from network); 21 Nov 2011 08:04:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 08:04:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 21 Nov 2011 08:04:50 +0000
Message-Id: <4ECA142D0200007800062066@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 21 Nov 2011 08:04:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "jim burns" <jim_burn@bellsouth.net>
References: <7877809.94pu0BOf0I@dell4550> <1474452.Ubr0mjN0Wq@dell4550>
	<4EC4E44002000078000617F9@nat28.tlf.novell.com>
	<2050647.nVkWu3Gdog@dell4550>
In-Reply-To: <2050647.nVkWu3Gdog@dell4550>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Flavio <fbcyborg@gmail.com>, xen-devel@lists.xensource.com,
	"Fajar A. Nugraha" <list@fajar.net>
Subject: Re: [Xen-devel] BAR 0: cirrusfb load errors prevent hvm domu from
 getting resolutions above 800x600
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.11.11 at 01:01, jim burns <jim_burn@bellsouth.net> wrote:
> I meant is a BAR 0: error a commonly understood problem with common steps to 
> find and fix the *configuration* problem, not where can I tinker with kernel 
> code. I would think suse's 2.6.37.1-1.2-desktop kernel would work as is in an 
> hvm domain. Or should he be using a different suse kernel 'flavor'? (-
> default?) Although, since it doesn't work for his hand-compiled 3.1 either, 
> this looks more like a filesystem / sysconfig configuration problem.

Using any fb driver other than VESA and the DRM base ones is - afaik -
uncommon, if not unsupported.

> Actually, he is loading the xorg cirrus module. It loads two candidates - 
> vesa 
> & cirrus. Then it unloads vesa in favor of the better cirrus candidate. 
> Unfortunately, after running through all the possible modes, it only 
> accepts:
> 
> [    33.240] (--) CIRRUS(0): Virtual size is 800x600 (pitch 1024)
> [    33.240] (**) CIRRUS(0): *Default mode "800x600": 40.0 MHz, 37.9 kHz, 
> 60.3 
> Hz
> [    33.240] (II) CIRRUS(0): Modeline "800x600"x60.3   40.00  800 840 968 
> 1056  
> 600 601 605 628 +hsync +vsync (37.9 kHz)
> [    33.240] (**) CIRRUS(0): *Default mode "800x600": 36.0 MHz, 35.2 kHz, 
> 56.2 
> Hz
> [    33.240] (II) CIRRUS(0): Modeline "800x600"x56.2   36.00  800 824 896 
> 1024  
> 600 601 603 625 +hsync +vsync (35.2 kHz)
> [    33.240] (**) CIRRUS(0): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 
> 59.9 
> Hz
> [    33.240] (II) CIRRUS(0): Modeline "640x480"x59.9   25.18  640 656 752 
> 800  
> 480 490 492 525 -hsync -vsync (31.5 kHz)
> [    33.240] (==) CIRRUS(0): DPI set to (96, 96)

That's something that may need looking at from the X side then. And
again, it may well be that 800x600 is all that's supposed to be
supported for a HVM guest here (i.e. anything beyond might be
considered a feature request rather than a bug, but it may also be
that all you need is some extension to the default monitor definition
[which admittedly shouldn't be really meaningful in a virtual environment]).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:05:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:05:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSOsP-0006Ni-7H; Mon, 21 Nov 2011 08:05:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSOsO-0006Nd-LR
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:05:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321862649!57580173!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1090 invoked from network); 21 Nov 2011 08:04:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 08:04:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 21 Nov 2011 08:04:50 +0000
Message-Id: <4ECA142D0200007800062066@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 21 Nov 2011 08:04:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "jim burns" <jim_burn@bellsouth.net>
References: <7877809.94pu0BOf0I@dell4550> <1474452.Ubr0mjN0Wq@dell4550>
	<4EC4E44002000078000617F9@nat28.tlf.novell.com>
	<2050647.nVkWu3Gdog@dell4550>
In-Reply-To: <2050647.nVkWu3Gdog@dell4550>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Flavio <fbcyborg@gmail.com>, xen-devel@lists.xensource.com,
	"Fajar A. Nugraha" <list@fajar.net>
Subject: Re: [Xen-devel] BAR 0: cirrusfb load errors prevent hvm domu from
 getting resolutions above 800x600
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.11.11 at 01:01, jim burns <jim_burn@bellsouth.net> wrote:
> I meant is a BAR 0: error a commonly understood problem with common steps to 
> find and fix the *configuration* problem, not where can I tinker with kernel 
> code. I would think suse's 2.6.37.1-1.2-desktop kernel would work as is in an 
> hvm domain. Or should he be using a different suse kernel 'flavor'? (-
> default?) Although, since it doesn't work for his hand-compiled 3.1 either, 
> this looks more like a filesystem / sysconfig configuration problem.

Using any fb driver other than VESA and the DRM base ones is - afaik -
uncommon, if not unsupported.

> Actually, he is loading the xorg cirrus module. It loads two candidates - 
> vesa 
> & cirrus. Then it unloads vesa in favor of the better cirrus candidate. 
> Unfortunately, after running through all the possible modes, it only 
> accepts:
> 
> [    33.240] (--) CIRRUS(0): Virtual size is 800x600 (pitch 1024)
> [    33.240] (**) CIRRUS(0): *Default mode "800x600": 40.0 MHz, 37.9 kHz, 
> 60.3 
> Hz
> [    33.240] (II) CIRRUS(0): Modeline "800x600"x60.3   40.00  800 840 968 
> 1056  
> 600 601 605 628 +hsync +vsync (37.9 kHz)
> [    33.240] (**) CIRRUS(0): *Default mode "800x600": 36.0 MHz, 35.2 kHz, 
> 56.2 
> Hz
> [    33.240] (II) CIRRUS(0): Modeline "800x600"x56.2   36.00  800 824 896 
> 1024  
> 600 601 603 625 +hsync +vsync (35.2 kHz)
> [    33.240] (**) CIRRUS(0): *Default mode "640x480": 25.2 MHz, 31.5 kHz, 
> 59.9 
> Hz
> [    33.240] (II) CIRRUS(0): Modeline "640x480"x59.9   25.18  640 656 752 
> 800  
> 480 490 492 525 -hsync -vsync (31.5 kHz)
> [    33.240] (==) CIRRUS(0): DPI set to (96, 96)

That's something that may need looking at from the X side then. And
again, it may well be that 800x600 is all that's supposed to be
supported for a HVM guest here (i.e. anything beyond might be
considered a feature request rather than a bug, but it may also be
that all you need is some extension to the default monitor definition
[which admittedly shouldn't be really meaningful in a virtual environment]).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:18:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSP4s-0006cC-Bz; Mon, 21 Nov 2011 08:18:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSP4q-0006bW-DM
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:18:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1321863460!3913337!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13915 invoked from network); 21 Nov 2011 08:17:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 08:17:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 21 Nov 2011 08:17:40 +0000
Message-Id: <4ECA17310200007800062083@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 21 Nov 2011 08:17:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD4FB5D31.1__="
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when switching
 RTE to edge triggered mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartD4FB5D31.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Xen itself (as much as Linux) relies on this behavior, so it should
also emulate it properly. Not doing so reportedly gets in the way of
kexec inside a HVM guest.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Olaf Hering <olaf@aepfle.de>

--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -154,8 +154,9 @@ static void vioapic_write_redirent(
     {
         vlapic_adjust_i8259_target(d);
     }
-    else if ( (ent.fields.trig_mode =3D=3D VIOAPIC_LEVEL_TRIG) &&
-              !ent.fields.mask &&
+    else if ( ent.fields.trig_mode =3D=3D VIOAPIC_EDGE_TRIG )
+        pent->fields.remote_irr =3D 0;
+    else if ( !ent.fields.mask &&
               !ent.fields.remote_irr &&
               hvm_irq->gsi_assert_count[idx] )
     {




--=__PartD4FB5D31.1__=
Content-Type: text/plain; name="x86-vioapic-clear-remote_irr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vioapic-clear-remote_irr.patch"

x86/vioapic: clear remote IRR when switching RTE to edge triggered =
mode=0A=0AXen itself (as much as Linux) relies on this behavior, so it =
should=0Aalso emulate it properly. Not doing so reportedly gets in the way =
of=0Akexec inside a HVM guest.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0ATested-by: Olaf Hering <olaf@aepfle.de>=0A=0A--- a/xen/arch/x86/h=
vm/vioapic.c=0A+++ b/xen/arch/x86/hvm/vioapic.c=0A@@ -154,8 +154,9 @@ =
static void vioapic_write_redirent(=0A     {=0A         vlapic_adjust_i8259=
_target(d);=0A     }=0A-    else if ( (ent.fields.trig_mode =3D=3D =
VIOAPIC_LEVEL_TRIG) &&=0A-              !ent.fields.mask &&=0A+    else if =
( ent.fields.trig_mode =3D=3D VIOAPIC_EDGE_TRIG )=0A+        pent->fields.r=
emote_irr =3D 0;=0A+    else if ( !ent.fields.mask &&=0A               =
!ent.fields.remote_irr &&=0A               hvm_irq->gsi_assert_count[idx] =
)=0A     {=0A
--=__PartD4FB5D31.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartD4FB5D31.1__=--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:18:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:18:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSP4s-0006cC-Bz; Mon, 21 Nov 2011 08:18:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSP4q-0006bW-DM
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:18:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1321863460!3913337!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13915 invoked from network); 21 Nov 2011 08:17:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 08:17:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 21 Nov 2011 08:17:40 +0000
Message-Id: <4ECA17310200007800062083@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 21 Nov 2011 08:17:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD4FB5D31.1__="
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when switching
 RTE to edge triggered mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartD4FB5D31.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Xen itself (as much as Linux) relies on this behavior, so it should
also emulate it properly. Not doing so reportedly gets in the way of
kexec inside a HVM guest.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Olaf Hering <olaf@aepfle.de>

--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -154,8 +154,9 @@ static void vioapic_write_redirent(
     {
         vlapic_adjust_i8259_target(d);
     }
-    else if ( (ent.fields.trig_mode =3D=3D VIOAPIC_LEVEL_TRIG) &&
-              !ent.fields.mask &&
+    else if ( ent.fields.trig_mode =3D=3D VIOAPIC_EDGE_TRIG )
+        pent->fields.remote_irr =3D 0;
+    else if ( !ent.fields.mask &&
               !ent.fields.remote_irr &&
               hvm_irq->gsi_assert_count[idx] )
     {




--=__PartD4FB5D31.1__=
Content-Type: text/plain; name="x86-vioapic-clear-remote_irr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vioapic-clear-remote_irr.patch"

x86/vioapic: clear remote IRR when switching RTE to edge triggered =
mode=0A=0AXen itself (as much as Linux) relies on this behavior, so it =
should=0Aalso emulate it properly. Not doing so reportedly gets in the way =
of=0Akexec inside a HVM guest.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0ATested-by: Olaf Hering <olaf@aepfle.de>=0A=0A--- a/xen/arch/x86/h=
vm/vioapic.c=0A+++ b/xen/arch/x86/hvm/vioapic.c=0A@@ -154,8 +154,9 @@ =
static void vioapic_write_redirent(=0A     {=0A         vlapic_adjust_i8259=
_target(d);=0A     }=0A-    else if ( (ent.fields.trig_mode =3D=3D =
VIOAPIC_LEVEL_TRIG) &&=0A-              !ent.fields.mask &&=0A+    else if =
( ent.fields.trig_mode =3D=3D VIOAPIC_EDGE_TRIG )=0A+        pent->fields.r=
emote_irr =3D 0;=0A+    else if ( !ent.fields.mask &&=0A               =
!ent.fields.remote_irr &&=0A               hvm_irq->gsi_assert_count[idx] =
)=0A     {=0A
--=__PartD4FB5D31.1__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartD4FB5D31.1__=--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:26:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSPC8-0006ze-EI; Mon, 21 Nov 2011 08:25:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSPC7-0006zO-AQ
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:25:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1321863911!3030160!1
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23935 invoked from network); 21 Nov 2011 08:25:11 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 08:25:11 -0000
Received: by eyb6 with SMTP id 6so8709823eyb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 00:25:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=n7SxCsWuPgv/dBIgTDWFD9vw7eUzqbLxEJQlj4ZG83A=;
	b=Ld53+Sa7v9mkX7TngHtvyqABUAmRXhKHhx2g/fm4o2ZtaL1Q1LpgEOoJjsYT7C2dVF
	k9bUzn3ra2XnYmeIZij13Rk17caeQxsA5MDIfgXd5E1QqhlYCP5mAPOgUEzJP/tGiUqQ
	ckpcfzi3mUI4xPH7pf2gIgHSJscFysbp6qdcM=
Received: by 10.180.84.33 with SMTP id v1mr13026332wiy.4.1321863911060;
	Mon, 21 Nov 2011 00:25:11 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id co5sm4801399wib.8.2011.11.21.00.25.10
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 00:25:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 08:25:07 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAEFBB63.2546D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when switching
	RTE to edge triggered mode
Thread-Index: AcyoJxNs19Ge/rSU/EmeD1++55dbuw==
In-Reply-To: <4ECA17310200007800062083@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>
Subject: Re: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when
 switching RTE to edge triggered mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 08:17, "Jan Beulich" <JBeulich@suse.com> wrote:

> Xen itself (as much as Linux) relies on this behavior, so it should
> also emulate it properly. Not doing so reportedly gets in the way of
> kexec inside a HVM guest.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -154,8 +154,9 @@ static void vioapic_write_redirent(
>      {
>          vlapic_adjust_i8259_target(d);
>      }
> -    else if ( (ent.fields.trig_mode == VIOAPIC_LEVEL_TRIG) &&
> -              !ent.fields.mask &&
> +    else if ( ent.fields.trig_mode == VIOAPIC_EDGE_TRIG )
> +        pent->fields.remote_irr = 0;
> +    else if ( !ent.fields.mask &&
>                !ent.fields.remote_irr &&
>                hvm_irq->gsi_assert_count[idx] )
>      {
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:26:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSPC8-0006ze-EI; Mon, 21 Nov 2011 08:25:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSPC7-0006zO-AQ
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:25:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1321863911!3030160!1
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23935 invoked from network); 21 Nov 2011 08:25:11 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 08:25:11 -0000
Received: by eyb6 with SMTP id 6so8709823eyb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 00:25:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=n7SxCsWuPgv/dBIgTDWFD9vw7eUzqbLxEJQlj4ZG83A=;
	b=Ld53+Sa7v9mkX7TngHtvyqABUAmRXhKHhx2g/fm4o2ZtaL1Q1LpgEOoJjsYT7C2dVF
	k9bUzn3ra2XnYmeIZij13Rk17caeQxsA5MDIfgXd5E1QqhlYCP5mAPOgUEzJP/tGiUqQ
	ckpcfzi3mUI4xPH7pf2gIgHSJscFysbp6qdcM=
Received: by 10.180.84.33 with SMTP id v1mr13026332wiy.4.1321863911060;
	Mon, 21 Nov 2011 00:25:11 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id co5sm4801399wib.8.2011.11.21.00.25.10
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 00:25:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 08:25:07 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAEFBB63.2546D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when switching
	RTE to edge triggered mode
Thread-Index: AcyoJxNs19Ge/rSU/EmeD1++55dbuw==
In-Reply-To: <4ECA17310200007800062083@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>
Subject: Re: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when
 switching RTE to edge triggered mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 08:17, "Jan Beulich" <JBeulich@suse.com> wrote:

> Xen itself (as much as Linux) relies on this behavior, so it should
> also emulate it properly. Not doing so reportedly gets in the way of
> kexec inside a HVM guest.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -154,8 +154,9 @@ static void vioapic_write_redirent(
>      {
>          vlapic_adjust_i8259_target(d);
>      }
> -    else if ( (ent.fields.trig_mode == VIOAPIC_LEVEL_TRIG) &&
> -              !ent.fields.mask &&
> +    else if ( ent.fields.trig_mode == VIOAPIC_EDGE_TRIG )
> +        pent->fields.remote_irr = 0;
> +    else if ( !ent.fields.mask &&
>                !ent.fields.remote_irr &&
>                hvm_irq->gsi_assert_count[idx] )
>      {
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:31:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSPHf-0007Fn-TF; Mon, 21 Nov 2011 08:31:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSPHe-0007FZ-BN
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:31:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321864140!45116227!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31577 invoked from network); 21 Nov 2011 08:29:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 08:29:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 21 Nov 2011 08:30:59 +0000
Message-Id: <4ECA1A510200007800062090@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 21 Nov 2011 08:30:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4ECA17310200007800062083@nat28.tlf.novell.com>
	<CAEFBB63.2546D%keir.xen@gmail.com>
In-Reply-To: <CAEFBB63.2546D%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when
 switching RTE to edge triggered mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.11.11 at 09:25, Keir Fraser <keir.xen@gmail.com> wrote:
> On 21/11/2011 08:17, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Xen itself (as much as Linux) relies on this behavior, so it should
>> also emulate it properly. Not doing so reportedly gets in the way of
>> kexec inside a HVM guest.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Olaf Hering <olaf@aepfle.de>
> 
> Acked-by: Keir Fraser <keir@xen.org>

Committed. Could that also be added to the older maintained trees,
please (once it made it though stage testing)?

Thanks, Jan

>> --- a/xen/arch/x86/hvm/vioapic.c
>> +++ b/xen/arch/x86/hvm/vioapic.c
>> @@ -154,8 +154,9 @@ static void vioapic_write_redirent(
>>      {
>>          vlapic_adjust_i8259_target(d);
>>      }
>> -    else if ( (ent.fields.trig_mode == VIOAPIC_LEVEL_TRIG) &&
>> -              !ent.fields.mask &&
>> +    else if ( ent.fields.trig_mode == VIOAPIC_EDGE_TRIG )
>> +        pent->fields.remote_irr = 0;
>> +    else if ( !ent.fields.mask &&
>>                !ent.fields.remote_irr &&
>>                hvm_irq->gsi_assert_count[idx] )
>>      {
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:31:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:31:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSPHf-0007Fn-TF; Mon, 21 Nov 2011 08:31:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSPHe-0007FZ-BN
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:31:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321864140!45116227!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31577 invoked from network); 21 Nov 2011 08:29:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 08:29:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 21 Nov 2011 08:30:59 +0000
Message-Id: <4ECA1A510200007800062090@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 21 Nov 2011 08:30:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <4ECA17310200007800062083@nat28.tlf.novell.com>
	<CAEFBB63.2546D%keir.xen@gmail.com>
In-Reply-To: <CAEFBB63.2546D%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when
 switching RTE to edge triggered mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 21.11.11 at 09:25, Keir Fraser <keir.xen@gmail.com> wrote:
> On 21/11/2011 08:17, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Xen itself (as much as Linux) relies on this behavior, so it should
>> also emulate it properly. Not doing so reportedly gets in the way of
>> kexec inside a HVM guest.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> Tested-by: Olaf Hering <olaf@aepfle.de>
> 
> Acked-by: Keir Fraser <keir@xen.org>

Committed. Could that also be added to the older maintained trees,
please (once it made it though stage testing)?

Thanks, Jan

>> --- a/xen/arch/x86/hvm/vioapic.c
>> +++ b/xen/arch/x86/hvm/vioapic.c
>> @@ -154,8 +154,9 @@ static void vioapic_write_redirent(
>>      {
>>          vlapic_adjust_i8259_target(d);
>>      }
>> -    else if ( (ent.fields.trig_mode == VIOAPIC_LEVEL_TRIG) &&
>> -              !ent.fields.mask &&
>> +    else if ( ent.fields.trig_mode == VIOAPIC_EDGE_TRIG )
>> +        pent->fields.remote_irr = 0;
>> +    else if ( !ent.fields.mask &&
>>                !ent.fields.remote_irr &&
>>                hvm_irq->gsi_assert_count[idx] )
>>      {
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:40:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSPQ1-0007kU-0m; Mon, 21 Nov 2011 08:40:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSPPz-0007kN-Fc
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:39:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1321864772!3913001!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3033 invoked from network); 21 Nov 2011 08:39:32 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 08:39:32 -0000
Received: by wwp14 with SMTP id 14so7940566wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 00:39:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=XLoqs0r1Ulvsg3T3tV9OvZhM2F0dhhqyMTAjH8MvSTI=;
	b=CTTMrDpaneiTVVmXYEz/12uMZKt6H6aaGRcDEMCAACmFjdFhKnoSb3lENnS+NcUO7d
	Db+KGfKw/kK43P30R0i4P+P3FaNpI7ikM1/ehmSTrY+4ZYcEcFzLR99S4x3XgVWlm4/r
	W2xOqUtS752yQhmnYtaBNlt5BWar/QfFULrxg=
Received: by 10.216.230.97 with SMTP id i75mr2065334weq.68.1321864772219;
	Mon, 21 Nov 2011 00:39:32 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id v6sm4825793wix.1.2011.11.21.00.39.30
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 00:39:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 08:39:27 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CAEFBEBF.25471%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when switching
	RTE to edge triggered mode
Thread-Index: AcyoKRQGOqT6ULKhJ0qXPxzo2UY4wA==
In-Reply-To: <4ECA1A510200007800062090@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when
 switching RTE to edge triggered mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 08:30, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 21.11.11 at 09:25, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 21/11/2011 08:17, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> Xen itself (as much as Linux) relies on this behavior, so it should
>>> also emulate it properly. Not doing so reportedly gets in the way of
>>> kexec inside a HVM guest.
>>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> Tested-by: Olaf Hering <olaf@aepfle.de>
>> 
>> Acked-by: Keir Fraser <keir@xen.org>
> 
> Committed. Could that also be added to the older maintained trees,
> please (once it made it though stage testing)?

Will do. I think we're still having test problems, possibly another
regression from Jean's patch series.

> Thanks, Jan
> 
>>> --- a/xen/arch/x86/hvm/vioapic.c
>>> +++ b/xen/arch/x86/hvm/vioapic.c
>>> @@ -154,8 +154,9 @@ static void vioapic_write_redirent(
>>>      {
>>>          vlapic_adjust_i8259_target(d);
>>>      }
>>> -    else if ( (ent.fields.trig_mode == VIOAPIC_LEVEL_TRIG) &&
>>> -              !ent.fields.mask &&
>>> +    else if ( ent.fields.trig_mode == VIOAPIC_EDGE_TRIG )
>>> +        pent->fields.remote_irr = 0;
>>> +    else if ( !ent.fields.mask &&
>>>                !ent.fields.remote_irr &&
>>>                hvm_irq->gsi_assert_count[idx] )
>>>      {
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:40:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSPQ1-0007kU-0m; Mon, 21 Nov 2011 08:40:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSPPz-0007kN-Fc
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:39:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1321864772!3913001!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3033 invoked from network); 21 Nov 2011 08:39:32 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 08:39:32 -0000
Received: by wwp14 with SMTP id 14so7940566wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 00:39:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=XLoqs0r1Ulvsg3T3tV9OvZhM2F0dhhqyMTAjH8MvSTI=;
	b=CTTMrDpaneiTVVmXYEz/12uMZKt6H6aaGRcDEMCAACmFjdFhKnoSb3lENnS+NcUO7d
	Db+KGfKw/kK43P30R0i4P+P3FaNpI7ikM1/ehmSTrY+4ZYcEcFzLR99S4x3XgVWlm4/r
	W2xOqUtS752yQhmnYtaBNlt5BWar/QfFULrxg=
Received: by 10.216.230.97 with SMTP id i75mr2065334weq.68.1321864772219;
	Mon, 21 Nov 2011 00:39:32 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id v6sm4825793wix.1.2011.11.21.00.39.30
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 00:39:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 08:39:27 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CAEFBEBF.25471%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when switching
	RTE to edge triggered mode
Thread-Index: AcyoKRQGOqT6ULKhJ0qXPxzo2UY4wA==
In-Reply-To: <4ECA1A510200007800062090@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/vioapic: clear remote IRR when
 switching RTE to edge triggered mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 08:30, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 21.11.11 at 09:25, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 21/11/2011 08:17, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> Xen itself (as much as Linux) relies on this behavior, so it should
>>> also emulate it properly. Not doing so reportedly gets in the way of
>>> kexec inside a HVM guest.
>>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> Tested-by: Olaf Hering <olaf@aepfle.de>
>> 
>> Acked-by: Keir Fraser <keir@xen.org>
> 
> Committed. Could that also be added to the older maintained trees,
> please (once it made it though stage testing)?

Will do. I think we're still having test problems, possibly another
regression from Jean's patch series.

> Thanks, Jan
> 
>>> --- a/xen/arch/x86/hvm/vioapic.c
>>> +++ b/xen/arch/x86/hvm/vioapic.c
>>> @@ -154,8 +154,9 @@ static void vioapic_write_redirent(
>>>      {
>>>          vlapic_adjust_i8259_target(d);
>>>      }
>>> -    else if ( (ent.fields.trig_mode == VIOAPIC_LEVEL_TRIG) &&
>>> -              !ent.fields.mask &&
>>> +    else if ( ent.fields.trig_mode == VIOAPIC_EDGE_TRIG )
>>> +        pent->fields.remote_irr = 0;
>>> +    else if ( !ent.fields.mask &&
>>>                !ent.fields.remote_irr &&
>>>                hvm_irq->gsi_assert_count[idx] )
>>>      {
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:40:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSPQR-0007mP-Fk; Mon, 21 Nov 2011 08:40:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSPQP-0007lZ-TR
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:40:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321864798!3924396!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28860 invoked from network); 21 Nov 2011 08:39:58 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 08:39:58 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321864798; l=489;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=RvNnmO6Zf/2tJ4jpc2IiWy8ATTw=;
	b=sDW2tc0zxrRJmcH20u1KP+adJ4oJQUU51YA++EdYqqmP/qlHLQSpoqt9H+1EHcn9Lh4
	xZLjrsKP2zgMtwoD4jkV/tRB5NC08BtiRLGy55OMytCCggQSvXboB+LwgnaBasAQYTlqS
	d7bq84CGp9GTmHZOpVAW2//R8b7z/99U/6Q=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0PFtsQ
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-150.pools.arcor-ip.net [88.65.73.150])
	by smtp.strato.de (jimi mo44) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j04d73nAL7rTXD ;
	Mon, 21 Nov 2011 09:39:40 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 35F3B18637; Mon, 21 Nov 2011 09:39:40 +0100 (CET)
Date: Mon, 21 Nov 2011 09:39:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111121083940.GA19892@aepfle.de>
References: <20111120132512.GA31844@aepfle.de>
	<CAEF0C92.25446%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEF0C92.25446%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com, tim@xen.org,
	Jean Guyader <jean.guyader@eu.citrix.com>, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
 XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 20, Keir Fraser wrote:

> > Nov 20 06:21:11.744519 (XEN) hvm.c:2312:d1 guest attempted write to read-only
> > memory page. gfn=0xc0, mfn=0x201979
> 
> Is that new behaviour? It may be unrelated to whatever HVM test failure
> we're seeing, or else be a mere symptom of a guest gone haywire for other
> reasons (we write-protect that memory range because it is supposed to be
> ROM).

The message does not trigger with changeset 24162, but it does with
24167.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 08:40:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 08:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSPQR-0007mP-Fk; Mon, 21 Nov 2011 08:40:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSPQP-0007lZ-TR
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 08:40:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321864798!3924396!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28860 invoked from network); 21 Nov 2011 08:39:58 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 08:39:58 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321864798; l=489;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=RvNnmO6Zf/2tJ4jpc2IiWy8ATTw=;
	b=sDW2tc0zxrRJmcH20u1KP+adJ4oJQUU51YA++EdYqqmP/qlHLQSpoqt9H+1EHcn9Lh4
	xZLjrsKP2zgMtwoD4jkV/tRB5NC08BtiRLGy55OMytCCggQSvXboB+LwgnaBasAQYTlqS
	d7bq84CGp9GTmHZOpVAW2//R8b7z/99U/6Q=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0PFtsQ
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-150.pools.arcor-ip.net [88.65.73.150])
	by smtp.strato.de (jimi mo44) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j04d73nAL7rTXD ;
	Mon, 21 Nov 2011 09:39:40 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 35F3B18637; Mon, 21 Nov 2011 09:39:40 +0100 (CET)
Date: Mon, 21 Nov 2011 09:39:40 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111121083940.GA19892@aepfle.de>
References: <20111120132512.GA31844@aepfle.de>
	<CAEF0C92.25446%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEF0C92.25446%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com, tim@xen.org,
	Jean Guyader <jean.guyader@eu.citrix.com>, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 3/6] add_to_physmap: Move the code for
 XENMEM_add_to_physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 20, Keir Fraser wrote:

> > Nov 20 06:21:11.744519 (XEN) hvm.c:2312:d1 guest attempted write to read-only
> > memory page. gfn=0xc0, mfn=0x201979
> 
> Is that new behaviour? It may be unrelated to whatever HVM test failure
> we're seeing, or else be a mere symptom of a guest gone haywire for other
> reasons (we write-protect that memory range because it is supposed to be
> ROM).

The message does not trigger with changeset 24162, but it does with
24167.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:19:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQ1Y-0000kI-Dr; Mon, 21 Nov 2011 09:18:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSQ1W-0000jv-8K
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 09:18:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1321867098!3924274!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27571 invoked from network); 21 Nov 2011 09:18:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 09:18:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9033376"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 09:18:18 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 09:18:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel.GarveyPatrickD@OrdinaryAmerican.net"
	<xen-devel.GarveyPatrickD@OrdinaryAmerican.net>
In-Reply-To: <CACm5R6TEeA1AiRwZ9xRvobSkKLzeOLbFfai6vibakpDOXQBZUw@mail.gmail.com>
References: <CACm5R6TEeA1AiRwZ9xRvobSkKLzeOLbFfai6vibakpDOXQBZUw@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Mon, 21 Nov 2011 09:18:17 +0000
Message-ID: <1321867097.8866.86.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-11-20 at 01:11 +0000,
xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
> http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_module
> contains a link to the University of Cambridge Computer Laboratory
> copy of the Xen User Manual
> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03231300000000000000
> that responds, "Forbidden
> You don't have permission to access
> /research/srg/netos/xen/readmes/user/user.html on this server."
> 
> Does Xen.org have the right to copy the Xen User Manual onto its own server?

That documentation is built from the Xen source tree (try installing
latex2html then"make docs") and appears to be covered by the GPL so I
think so.

However that particular doc is not well maintained (although the
particular section which is referenced doesn't look so bad). IMHO it
would be better to move the information onto the wiki itself (assuming
it isn't already duplicated somewhere).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:19:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQ1Y-0000kI-Dr; Mon, 21 Nov 2011 09:18:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSQ1W-0000jv-8K
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 09:18:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1321867098!3924274!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27571 invoked from network); 21 Nov 2011 09:18:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 09:18:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9033376"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 09:18:18 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 09:18:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel.GarveyPatrickD@OrdinaryAmerican.net"
	<xen-devel.GarveyPatrickD@OrdinaryAmerican.net>
In-Reply-To: <CACm5R6TEeA1AiRwZ9xRvobSkKLzeOLbFfai6vibakpDOXQBZUw@mail.gmail.com>
References: <CACm5R6TEeA1AiRwZ9xRvobSkKLzeOLbFfai6vibakpDOXQBZUw@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Mon, 21 Nov 2011 09:18:17 +0000
Message-ID: <1321867097.8866.86.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-11-20 at 01:11 +0000,
xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
> http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_module
> contains a link to the University of Cambridge Computer Laboratory
> copy of the Xen User Manual
> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03231300000000000000
> that responds, "Forbidden
> You don't have permission to access
> /research/srg/netos/xen/readmes/user/user.html on this server."
> 
> Does Xen.org have the right to copy the Xen User Manual onto its own server?

That documentation is built from the Xen source tree (try installing
latex2html then"make docs") and appears to be covered by the GPL so I
think so.

However that particular doc is not well maintained (although the
particular section which is referenced doesn't look so bad). IMHO it
would be better to move the information onto the wiki itself (assuming
it isn't already duplicated somewhere).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:21:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQ46-00016L-0Y; Mon, 21 Nov 2011 09:21:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSQ44-00015R-Q9
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 09:21:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1321867257!2361314!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7769 invoked from network); 21 Nov 2011 09:20:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 09:20:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9033464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 09:20:56 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 09:20:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel.GarveyPatrickD@OrdinaryAmerican.net"
	<xen-devel.GarveyPatrickD@OrdinaryAmerican.net>
In-Reply-To: <CACm5R6SkCiQC7153x-B6=kd96TKHC8uLvjY5gm8_QyefJ4LX+Q@mail.gmail.com>
References: <CACm5R6SkCiQC7153x-B6=kd96TKHC8uLvjY5gm8_QyefJ4LX+Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Mon, 21 Nov 2011 09:20:56 +0000
Message-ID: <1321867256.8866.88.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] wiki.xen.org Page structure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-11-20 at 01:09 +0000,
xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
> Browsing through wiki.xen.org, I see several pages formatted like
> http://wiki.xen.org/wiki/AskingXenDevelQuestions
> It has one first level header and several second level headers.  The
> first level header also seems more appropriate as the page title,
> especially when it is a paraphrase of the page file name.  It seems to
> me, "How to get your question answered on xen-devel" is better English
> than "AskingXenDevelQuestions".
> 
> May I move such pages to their first header as a file name and
> eliminate the first level of headers on such pages?

Sounds reasonable to me.

> Maybe we can
> follow that with the elimination of the original file that will have
> become a mere redirect with the move?

The URLs have generally been posted around the place a fair bit (e.g.
they will be in the ML archives, google finds them etc) and I don't
think the redirect is doing any harm -- we should keep them IMHO.

Ian.

> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:21:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQ46-00016L-0Y; Mon, 21 Nov 2011 09:21:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSQ44-00015R-Q9
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 09:21:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1321867257!2361314!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7769 invoked from network); 21 Nov 2011 09:20:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 09:20:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9033464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 09:20:56 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 09:20:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel.GarveyPatrickD@OrdinaryAmerican.net"
	<xen-devel.GarveyPatrickD@OrdinaryAmerican.net>
In-Reply-To: <CACm5R6SkCiQC7153x-B6=kd96TKHC8uLvjY5gm8_QyefJ4LX+Q@mail.gmail.com>
References: <CACm5R6SkCiQC7153x-B6=kd96TKHC8uLvjY5gm8_QyefJ4LX+Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Mon, 21 Nov 2011 09:20:56 +0000
Message-ID: <1321867256.8866.88.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] wiki.xen.org Page structure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-11-20 at 01:09 +0000,
xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
> Browsing through wiki.xen.org, I see several pages formatted like
> http://wiki.xen.org/wiki/AskingXenDevelQuestions
> It has one first level header and several second level headers.  The
> first level header also seems more appropriate as the page title,
> especially when it is a paraphrase of the page file name.  It seems to
> me, "How to get your question answered on xen-devel" is better English
> than "AskingXenDevelQuestions".
> 
> May I move such pages to their first header as a file name and
> eliminate the first level of headers on such pages?

Sounds reasonable to me.

> Maybe we can
> follow that with the elimination of the original file that will have
> become a mere redirect with the move?

The URLs have generally been posted around the place a fair bit (e.g.
they will be in the ML archives, google finds them etc) and I don't
think the redirect is doing any harm -- we should keep them IMHO.

Ian.

> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:49:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:49:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQV0-0002q9-Bi; Mon, 21 Nov 2011 09:49:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fbcyborg@gmail.com>)
	id 1RSQUy-0002px-PF; Mon, 21 Nov 2011 09:49:12 +0000
X-Env-Sender: fbcyborg@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1321868924!3924500!1
X-Originating-IP: [209.85.212.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16743 invoked from network); 21 Nov 2011 09:48:45 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 09:48:45 -0000
Received: by vbbfk1 with SMTP id fk1so3475412vbb.30
	for <multiple recipients>; Mon, 21 Nov 2011 01:48:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=cCF+lhMChQAK83eNMkLuY3+CLpLB5xw8Fxl+gnE56xU=;
	b=n+wpfsyTPDnt0Yt+uo9zWBsLzpoqYm1Oz9wLVJeuCvunXBukMbUI5n9eM1LuXYacs1
	a9WvVOqeGOHGnX36ExcKG2IfQdaq49PkKYhQvfLNdJEJuA4dvMU9Vq1+hk2YpI/sYU4R
	Wx5AfvimKtcrH4HoO2B5zhlKb7kBI2/4tn7bI=
Received: by 10.52.89.206 with SMTP id bq14mr14680008vdb.39.1321868924042;
	Mon, 21 Nov 2011 01:48:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.185.231 with HTTP; Mon, 21 Nov 2011 01:48:23 -0800 (PST)
In-Reply-To: <2050647.nVkWu3Gdog@dell4550>
References: <7877809.94pu0BOf0I@dell4550> <1474452.Ubr0mjN0Wq@dell4550>
	<4EC4E44002000078000617F9@nat28.tlf.novell.com>
	<2050647.nVkWu3Gdog@dell4550>
From: Flavio <fbcyborg@gmail.com>
Date: Mon, 21 Nov 2011 10:48:23 +0100
Message-ID: <CAP8Jb=od=gv-bP9iJtaPtmSp6ORov50b+5+gMApj-1Z6E_CH-A@mail.gmail.com>
To: jim burns <jim_burn@bellsouth.net>
Cc: xen-users@lists.xensource.com, xen-devel@lists.xensource.com,
	Jan Beulich <JBeulich@suse.com>, "Fajar A. Nugraha" <list@fajar.net>
Subject: Re: [Xen-devel] BAR 0: cirrusfb load errors prevent hvm domu from
 getting resolutions above 800x600
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21 November 2011 01:01, jim burns <jim_burn@bellsouth.net> wrote:
> I meant is a BAR 0: error a commonly understood problem with common steps to
> find and fix the *configuration* problem, not where can I tinker with kernel
> code. I would think suse's 2.6.37.1-1.2-desktop kernel would work as is in an
> hvm domain. Or should he be using a different suse kernel 'flavor'? (-
> default?) Although, since it doesn't work for his hand-compiled 3.1 either,
> this looks more like a filesystem / sysconfig configuration problem.
Just to make some precisation here: I took the configuration file from /boot
(i.e. the config file of 2.6.37.1-1.2-desktop kernel which comes bundled with
the installation) and copied into the 3.1 source kernel directory and compiled
again the kernel. I even modified something about XEN, making it domU capable
(like if it was a PV domU and not a hvm domU).

Thank you so much for your support,

-- 
Flavio

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:49:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:49:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQV0-0002q9-Bi; Mon, 21 Nov 2011 09:49:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fbcyborg@gmail.com>)
	id 1RSQUy-0002px-PF; Mon, 21 Nov 2011 09:49:12 +0000
X-Env-Sender: fbcyborg@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1321868924!3924500!1
X-Originating-IP: [209.85.212.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16743 invoked from network); 21 Nov 2011 09:48:45 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 09:48:45 -0000
Received: by vbbfk1 with SMTP id fk1so3475412vbb.30
	for <multiple recipients>; Mon, 21 Nov 2011 01:48:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=cCF+lhMChQAK83eNMkLuY3+CLpLB5xw8Fxl+gnE56xU=;
	b=n+wpfsyTPDnt0Yt+uo9zWBsLzpoqYm1Oz9wLVJeuCvunXBukMbUI5n9eM1LuXYacs1
	a9WvVOqeGOHGnX36ExcKG2IfQdaq49PkKYhQvfLNdJEJuA4dvMU9Vq1+hk2YpI/sYU4R
	Wx5AfvimKtcrH4HoO2B5zhlKb7kBI2/4tn7bI=
Received: by 10.52.89.206 with SMTP id bq14mr14680008vdb.39.1321868924042;
	Mon, 21 Nov 2011 01:48:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.185.231 with HTTP; Mon, 21 Nov 2011 01:48:23 -0800 (PST)
In-Reply-To: <2050647.nVkWu3Gdog@dell4550>
References: <7877809.94pu0BOf0I@dell4550> <1474452.Ubr0mjN0Wq@dell4550>
	<4EC4E44002000078000617F9@nat28.tlf.novell.com>
	<2050647.nVkWu3Gdog@dell4550>
From: Flavio <fbcyborg@gmail.com>
Date: Mon, 21 Nov 2011 10:48:23 +0100
Message-ID: <CAP8Jb=od=gv-bP9iJtaPtmSp6ORov50b+5+gMApj-1Z6E_CH-A@mail.gmail.com>
To: jim burns <jim_burn@bellsouth.net>
Cc: xen-users@lists.xensource.com, xen-devel@lists.xensource.com,
	Jan Beulich <JBeulich@suse.com>, "Fajar A. Nugraha" <list@fajar.net>
Subject: Re: [Xen-devel] BAR 0: cirrusfb load errors prevent hvm domu from
 getting resolutions above 800x600
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21 November 2011 01:01, jim burns <jim_burn@bellsouth.net> wrote:
> I meant is a BAR 0: error a commonly understood problem with common steps to
> find and fix the *configuration* problem, not where can I tinker with kernel
> code. I would think suse's 2.6.37.1-1.2-desktop kernel would work as is in an
> hvm domain. Or should he be using a different suse kernel 'flavor'? (-
> default?) Although, since it doesn't work for his hand-compiled 3.1 either,
> this looks more like a filesystem / sysconfig configuration problem.
Just to make some precisation here: I took the configuration file from /boot
(i.e. the config file of 2.6.37.1-1.2-desktop kernel which comes bundled with
the installation) and copied into the 3.1 source kernel directory and compiled
again the kernel. I even modified something about XEN, making it domU capable
(like if it was a PV domU and not a hvm domU).

Thank you so much for your support,

-- 
Flavio

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:50:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQVw-0002vq-IU; Mon, 21 Nov 2011 09:50:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSQVt-0002ul-Uh
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 09:50:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321868982!3937285!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1891 invoked from network); 21 Nov 2011 09:49:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 09:49:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9034381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 09:49:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 09:49:41 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSQVR-0003ZE-Op;
	Mon, 21 Nov 2011 09:49:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSQVR-00045N-OQ;
	Mon, 21 Nov 2011 09:49:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9931-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 21 Nov 2011 09:49:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9931: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9931 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9931/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail    like 9855
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:50:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:50:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQVw-0002vq-IU; Mon, 21 Nov 2011 09:50:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSQVt-0002ul-Uh
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 09:50:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321868982!3937285!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1891 invoked from network); 21 Nov 2011 09:49:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 09:49:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9034381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 09:49:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 09:49:41 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSQVR-0003ZE-Op;
	Mon, 21 Nov 2011 09:49:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSQVR-00045N-OQ;
	Mon, 21 Nov 2011 09:49:41 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9931-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 21 Nov 2011 09:49:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9931: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9931 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9931/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail    like 9855
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  335e8273a3f3
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24167:335e8273a3f3
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:51:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQXB-00039e-2w; Mon, 21 Nov 2011 09:51:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSQX9-00039C-BF
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 09:51:27 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321869048!46434933!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12218 invoked from network); 21 Nov 2011 09:50:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 09:50:49 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAL9oxlR004082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 21 Nov 2011 09:51:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAL9owjk026460
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 21 Nov 2011 09:50:58 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAL9oqaL008596; Mon, 21 Nov 2011 03:50:52 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 01:50:52 -0800
Message-ID: <4ECA1F13.3060903@oracle.com>
Date: Mon, 21 Nov 2011 17:51:15 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
	<20111118135221.GC12433@phenom.dumpdata.com>
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>
	<4EC6837F.1050201@oracle.com>
	<20111118180500.GA19469@phenom.dumpdata.com>
In-Reply-To: <20111118180500.GA19469@phenom.dumpdata.com>
Content-Type: multipart/mixed; boundary="------------050906020008090403000009"
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4ECA1F05.007C,ss=1,re=-2.300,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------050906020008090403000009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


> The idea is just to have one function. Whichever prints the
> string and panics the machine. If 'panic' does this properly
> (and properly meaning it actually prints data when using
> the earlyprintk=xen as well as console=hvc0) printout system
> the we cuold just use 'panic' and not worry about it.
>
>
> But if it does not, then we (and by we I mean you) should
> provide a variant of panic() that prints the data properly using the
> earlprintk mechanism. Preferrabily to make it generic.
I did a simple test, a serial cable was connected,  and console=hvc0 was 
added in grub.conf.
Whether earlyprintk=xen is set or not, both panic() and xen_raw_printk 
all can print out strings in gnttab_request_version of grant-table.c.

So I changed the

xen_raw_printk();
panic();

back to

panic();

Other change is the re-arrange "else if" format in 
gnttab_request_version function.

Please refer to the patch attached.

Thanks
Annie

--------------050906020008090403000009
Content-Type: text/plain;
 name="0003-xen-granttable-Grant-tables-V2-implementation.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0003-xen-granttable-Grant-tables-V2-implementation.patch"

>From fa509f4a3a80fdb8a604efe6d68d9dc8ce25511b Mon Sep 17 00:00:00 2001
From: Annie Li <annie.li@oracle.com>
Date: Fri, 18 Nov 2011 16:53:37 +0800
Subject: [PATCH 3/4] xen/granttable: Grant tables V2 implementation

Receiver-side copying of packets is based on this implementation, it gives
better performance and better CPU accounting. It totally supports three types:
full-page, sub-page and transitive grants.

However this patch does not cover sub-page and transitive grants, it mainly
focus on Full-page part and implements grant table V2 interfaces corresponding
to what already exists in grant table V1, such as: grant table V2
initialization, mapping, releasing and exported interfaces.

Each guest can only supports one type of grant table type, every entry in grant
table should be the same version. It is necessary to set V1 or V2 version before
initializing the grant table.

Grant table exported interfaces of V2 are same with those of V1, Xen is
responsible to judge what grant table version guests are using in every grant
operation.

V2 fulfills the same role of V1, and it is totally backwards compitable with V1.
If dom0 support grant table V2, the guests runing on it can run with either V1
or V2.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 arch/x86/xen/grant-table.c |   37 +++++++++-
 drivers/xen/grant-table.c  |  175 +++++++++++++++++++++++++++++++++++++++++++-
 include/xen/grant_table.h  |    6 +-
 3 files changed, 211 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index c6ab2e7..510fca0 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -54,6 +54,20 @@ static int map_pte_fn(pte_t *pte, struct page *pmd_page,
 	return 0;
 }
 
+/*
+ * This function is used to map shared frames to store grant status. It is
+ * different from map_pte_fn above, the frames type here is uint64_t.
+ */
+static int map_pte_fn_status(pte_t *pte, struct page *pmd_page,
+			     unsigned long addr, void *data)
+{
+	uint64_t **frames = (uint64_t **)data;
+
+	set_pte_at(&init_mm, addr, pte, mfn_pte((*frames)[0], PAGE_KERNEL));
+	(*frames)++;
+	return 0;
+}
+
 static int unmap_pte_fn(pte_t *pte, struct page *pmd_page,
 			unsigned long addr, void *data)
 {
@@ -83,7 +97,28 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 	return rc;
 }
 
-void arch_gnttab_unmap_shared(void *shared, unsigned long nr_gframes)
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared)
+{
+	int rc;
+	grant_status_t *shared = *__shared;
+
+	if (shared == NULL) {
+		struct vm_struct *area =
+			alloc_vm_area(PAGE_SIZE * max_nr_gframes);
+		BUG_ON(area == NULL);
+		shared = area->addr;
+		*__shared = shared;
+	}
+
+	rc = apply_to_page_range(&init_mm, (unsigned long)shared,
+				 PAGE_SIZE * nr_gframes,
+				 map_pte_fn_status, &frames);
+	return rc;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
 {
 	apply_to_page_range(&init_mm, (unsigned long)shared,
 			    PAGE_SIZE * nr_gframes, unmap_pte_fn, NULL);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index f33041e..ca075e9 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -44,6 +44,7 @@
 #include <xen/page.h>
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
+#include <xen/hvc-console.h>
 #include <asm/xen/hypercall.h>
 
 #include <asm/pgtable.h>
@@ -53,7 +54,10 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry_v1))
+#define GREFS_PER_GRANT_FRAME \
+(grant_table_version == 1 ?                      \
+ (PAGE_SIZE / sizeof(struct grant_entry_v1)) :   \
+ (PAGE_SIZE / sizeof(union grant_entry_v2)))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -66,6 +70,7 @@ EXPORT_SYMBOL_GPL(xen_hvm_resume_frames);
 
 static union {
 	struct grant_entry_v1 *v1;
+	union grant_entry_v2 *v2;
 	void *addr;
 } gnttab_shared;
 
@@ -119,8 +124,12 @@ struct gnttab_ops {
 };
 
 static struct gnttab_ops gnttab_v1_ops;
+static struct gnttab_ops gnttab_v2_ops;
 static struct gnttab_ops *gnttab_interface;
 
+/*This reflects status of grant entries, so act as a global value*/
+static grant_status_t *grstatus;
+
 static int grant_table_version;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
@@ -128,6 +137,7 @@ static struct gnttab_free_callback *gnttab_free_callback_list;
 static int gnttab_expand(unsigned int req_entries);
 
 #define RPP (PAGE_SIZE / sizeof(grant_ref_t))
+#define SPP (PAGE_SIZE / sizeof(grant_status_t))
 
 static inline grant_ref_t *__gnttab_entry(grant_ref_t entry)
 {
@@ -200,6 +210,7 @@ static void put_free_entry(grant_ref_t ref)
 }
 
 /*
+ * Following comments apply to update_grant_entry_v1 and update_grant_entry_v2.
  * Introducing a valid entry into the grant table:
  *  1. Write ent->domid.
  *  2. Write ent->frame:
@@ -218,6 +229,15 @@ static void update_grant_entry_v1(grant_ref_t ref, domid_t domid,
 	gnttab_shared.v1[ref].flags = flags;
 }
 
+static void update_grant_entry_v2(grant_ref_t ref, domid_t domid,
+				  unsigned long frame, unsigned flags)
+{
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	gnttab_shared.v2[ref].full_page.frame = frame;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags = GTF_permit_access | flags;
+}
+
 /*
  * Public grant-issuing interface functions
  */
@@ -249,6 +269,11 @@ static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
 }
 
+static int gnttab_query_foreign_access_v2(grant_ref_t ref)
+{
+	return grstatus[ref] & (GTF_reading|GTF_writing);
+}
+
 int gnttab_query_foreign_access(grant_ref_t ref)
 {
 	return gnttab_interface->query_foreign_access(ref);
@@ -273,6 +298,29 @@ static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 	return 1;
 }
 
+static int gnttab_end_foreign_access_ref_v2(grant_ref_t ref, int readonly)
+{
+	gnttab_shared.v2[ref].hdr.flags = 0;
+	mb();
+	if (grstatus[ref] & (GTF_reading|GTF_writing)) {
+		return 0;
+	} else {
+		/* The read of grstatus needs to have acquire
+		semantics.  On x86, reads already have
+		that, and we just need to protect against
+		compiler reorderings.  On other
+		architectures we may need a full
+		barrier. */
+#ifdef CONFIG_X86
+		barrier();
+#else
+		mb();
+#endif
+		}
+
+	return 1;
+}
+
 int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
 {
 	return gnttab_interface->end_foreign_access_ref(ref, readonly);
@@ -346,6 +394,37 @@ static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 	return frame;
 }
 
+static unsigned long gnttab_end_foreign_transfer_ref_v2(grant_ref_t ref)
+{
+	unsigned long frame;
+	u16           flags;
+	u16          *pflags;
+
+	pflags = &gnttab_shared.v2[ref].hdr.flags;
+
+	/*
+	 * If a transfer is not even yet started, try to reclaim the grant
+	 * reference and return failure (== 0).
+	 */
+	while (!((flags = *pflags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(pflags, flags, 0) == flags)
+			return 0;
+		cpu_relax();
+	}
+
+	/* If a transfer is in progress then wait until it is completed. */
+	while (!(flags & GTF_transfer_completed)) {
+		flags = *pflags;
+		cpu_relax();
+	}
+
+	rmb();  /* Read the frame number /after/ reading completion status. */
+	frame = gnttab_shared.v2[ref].full_page.frame;
+	BUG_ON(frame == 0);
+
+	return frame;
+}
+
 unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
 {
 	return gnttab_interface->end_foreign_transfer_ref(ref);
@@ -593,6 +672,11 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static unsigned nr_status_frames(unsigned nr_grant_frames)
+{
+	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
+}
+
 static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 {
 	int rc;
@@ -607,7 +691,56 @@ static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 
 static void gnttab_unmap_frames_v1(void)
 {
-	arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+}
+
+static int gnttab_map_frames_v2(unsigned long *frames, unsigned int nr_gframes)
+{
+	uint64_t *sframes;
+	unsigned int nr_sframes;
+	struct gnttab_get_status_frames getframes;
+	int rc;
+
+	nr_sframes = nr_status_frames(nr_gframes);
+
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_get_status_frames.
+	 */
+	sframes = kmalloc(nr_sframes  * sizeof(uint64_t), GFP_ATOMIC);
+	if (!sframes)
+		return -ENOMEM;
+
+	getframes.dom        = DOMID_SELF;
+	getframes.nr_frames  = nr_sframes;
+	set_xen_guest_handle(getframes.frame_list, sframes);
+
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_get_status_frames,
+				       &getframes, 1);
+	if (rc == -ENOSYS) {
+		kfree(sframes);
+		return -ENOSYS;
+	}
+
+	BUG_ON(rc || getframes.status);
+
+	rc = arch_gnttab_map_status(sframes, nr_sframes,
+				    nr_status_frames(gnttab_max_grant_frames()),
+				    &grstatus);
+	BUG_ON(rc);
+	kfree(sframes);
+
+	rc = arch_gnttab_map_shared(frames, nr_gframes,
+				    gnttab_max_grant_frames(),
+				    &gnttab_shared.addr);
+	BUG_ON(rc);
+
+	return 0;
+}
+
+static void gnttab_unmap_frames_v2(void)
+{
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(grstatus, nr_status_frames(nr_grant_frames));
 }
 
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
@@ -641,6 +774,9 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		return rc;
 	}
 
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_setup_table.
+	 */
 	frames = kmalloc(nr_gframes * sizeof(unsigned long), GFP_ATOMIC);
 	if (!frames)
 		return -ENOMEM;
@@ -673,10 +809,41 @@ static struct gnttab_ops gnttab_v1_ops = {
 	.query_foreign_access		= gnttab_query_foreign_access_v1,
 };
 
+static struct gnttab_ops gnttab_v2_ops = {
+	.map_frames			= gnttab_map_frames_v2,
+	.unmap_frames			= gnttab_unmap_frames_v2,
+	.update_entry			= update_grant_entry_v2,
+	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
+	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
+	.query_foreign_access		= gnttab_query_foreign_access_v2,
+};
+
 static void gnttab_request_version(void)
 {
-	grant_table_version = 1;
-	gnttab_interface = &gnttab_v1_ops;
+	int rc;
+	struct gnttab_set_version gsv;
+	const char *str = "we need grant tables version 2, but only version 1 is available\n";
+
+	gsv.version = 2;
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
+	if (rc == 0) {
+		grant_table_version = 2;
+		gnttab_interface = &gnttab_v2_ops;
+	} else {
+		if (grant_table_version == 2) {
+			/*
+			 * If we've already used version 2 features,
+			 * but then suddenly discover that they're not
+			 * available (e.g. migrating to an older
+			 * version of Xen), almost unbounded badness
+			 * can happen.
+			 */
+			xen_raw_printk(str);
+			panic(str);
+		}
+		grant_table_version = 1;
+		gnttab_interface = &gnttab_v1_ops;
+	}
 	printk(KERN_INFO "Grant tables using version %d layout.\n",
 		grant_table_version);
 }
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index c7a40f8..5494c40 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -146,8 +146,10 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
 			   void **__shared);
-void arch_gnttab_unmap_shared(void *shared,
-			      unsigned long nr_gframes);
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared);
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes);
 
 extern unsigned long xen_hvm_resume_frames;
 unsigned int gnttab_max_grant_frames(void);
-- 
1.7.6.4


--------------050906020008090403000009
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------050906020008090403000009--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:51:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:51:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQXB-00039e-2w; Mon, 21 Nov 2011 09:51:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSQX9-00039C-BF
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 09:51:27 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321869048!46434933!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12218 invoked from network); 21 Nov 2011 09:50:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 09:50:49 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAL9oxlR004082
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 21 Nov 2011 09:51:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAL9owjk026460
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 21 Nov 2011 09:50:58 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAL9oqaL008596; Mon, 21 Nov 2011 03:50:52 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 01:50:52 -0800
Message-ID: <4ECA1F13.3060903@oracle.com>
Date: Mon, 21 Nov 2011 17:51:15 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
	<20111118135221.GC12433@phenom.dumpdata.com>
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>
	<4EC6837F.1050201@oracle.com>
	<20111118180500.GA19469@phenom.dumpdata.com>
In-Reply-To: <20111118180500.GA19469@phenom.dumpdata.com>
Content-Type: multipart/mixed; boundary="------------050906020008090403000009"
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4ECA1F05.007C,ss=1,re=-2.300,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------050906020008090403000009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


> The idea is just to have one function. Whichever prints the
> string and panics the machine. If 'panic' does this properly
> (and properly meaning it actually prints data when using
> the earlyprintk=xen as well as console=hvc0) printout system
> the we cuold just use 'panic' and not worry about it.
>
>
> But if it does not, then we (and by we I mean you) should
> provide a variant of panic() that prints the data properly using the
> earlprintk mechanism. Preferrabily to make it generic.
I did a simple test, a serial cable was connected,  and console=hvc0 was 
added in grub.conf.
Whether earlyprintk=xen is set or not, both panic() and xen_raw_printk 
all can print out strings in gnttab_request_version of grant-table.c.

So I changed the

xen_raw_printk();
panic();

back to

panic();

Other change is the re-arrange "else if" format in 
gnttab_request_version function.

Please refer to the patch attached.

Thanks
Annie

--------------050906020008090403000009
Content-Type: text/plain;
 name="0003-xen-granttable-Grant-tables-V2-implementation.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0003-xen-granttable-Grant-tables-V2-implementation.patch"

>From fa509f4a3a80fdb8a604efe6d68d9dc8ce25511b Mon Sep 17 00:00:00 2001
From: Annie Li <annie.li@oracle.com>
Date: Fri, 18 Nov 2011 16:53:37 +0800
Subject: [PATCH 3/4] xen/granttable: Grant tables V2 implementation

Receiver-side copying of packets is based on this implementation, it gives
better performance and better CPU accounting. It totally supports three types:
full-page, sub-page and transitive grants.

However this patch does not cover sub-page and transitive grants, it mainly
focus on Full-page part and implements grant table V2 interfaces corresponding
to what already exists in grant table V1, such as: grant table V2
initialization, mapping, releasing and exported interfaces.

Each guest can only supports one type of grant table type, every entry in grant
table should be the same version. It is necessary to set V1 or V2 version before
initializing the grant table.

Grant table exported interfaces of V2 are same with those of V1, Xen is
responsible to judge what grant table version guests are using in every grant
operation.

V2 fulfills the same role of V1, and it is totally backwards compitable with V1.
If dom0 support grant table V2, the guests runing on it can run with either V1
or V2.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 arch/x86/xen/grant-table.c |   37 +++++++++-
 drivers/xen/grant-table.c  |  175 +++++++++++++++++++++++++++++++++++++++++++-
 include/xen/grant_table.h  |    6 +-
 3 files changed, 211 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index c6ab2e7..510fca0 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -54,6 +54,20 @@ static int map_pte_fn(pte_t *pte, struct page *pmd_page,
 	return 0;
 }
 
+/*
+ * This function is used to map shared frames to store grant status. It is
+ * different from map_pte_fn above, the frames type here is uint64_t.
+ */
+static int map_pte_fn_status(pte_t *pte, struct page *pmd_page,
+			     unsigned long addr, void *data)
+{
+	uint64_t **frames = (uint64_t **)data;
+
+	set_pte_at(&init_mm, addr, pte, mfn_pte((*frames)[0], PAGE_KERNEL));
+	(*frames)++;
+	return 0;
+}
+
 static int unmap_pte_fn(pte_t *pte, struct page *pmd_page,
 			unsigned long addr, void *data)
 {
@@ -83,7 +97,28 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 	return rc;
 }
 
-void arch_gnttab_unmap_shared(void *shared, unsigned long nr_gframes)
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared)
+{
+	int rc;
+	grant_status_t *shared = *__shared;
+
+	if (shared == NULL) {
+		struct vm_struct *area =
+			alloc_vm_area(PAGE_SIZE * max_nr_gframes);
+		BUG_ON(area == NULL);
+		shared = area->addr;
+		*__shared = shared;
+	}
+
+	rc = apply_to_page_range(&init_mm, (unsigned long)shared,
+				 PAGE_SIZE * nr_gframes,
+				 map_pte_fn_status, &frames);
+	return rc;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
 {
 	apply_to_page_range(&init_mm, (unsigned long)shared,
 			    PAGE_SIZE * nr_gframes, unmap_pte_fn, NULL);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index f33041e..ca075e9 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -44,6 +44,7 @@
 #include <xen/page.h>
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
+#include <xen/hvc-console.h>
 #include <asm/xen/hypercall.h>
 
 #include <asm/pgtable.h>
@@ -53,7 +54,10 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry_v1))
+#define GREFS_PER_GRANT_FRAME \
+(grant_table_version == 1 ?                      \
+ (PAGE_SIZE / sizeof(struct grant_entry_v1)) :   \
+ (PAGE_SIZE / sizeof(union grant_entry_v2)))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -66,6 +70,7 @@ EXPORT_SYMBOL_GPL(xen_hvm_resume_frames);
 
 static union {
 	struct grant_entry_v1 *v1;
+	union grant_entry_v2 *v2;
 	void *addr;
 } gnttab_shared;
 
@@ -119,8 +124,12 @@ struct gnttab_ops {
 };
 
 static struct gnttab_ops gnttab_v1_ops;
+static struct gnttab_ops gnttab_v2_ops;
 static struct gnttab_ops *gnttab_interface;
 
+/*This reflects status of grant entries, so act as a global value*/
+static grant_status_t *grstatus;
+
 static int grant_table_version;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
@@ -128,6 +137,7 @@ static struct gnttab_free_callback *gnttab_free_callback_list;
 static int gnttab_expand(unsigned int req_entries);
 
 #define RPP (PAGE_SIZE / sizeof(grant_ref_t))
+#define SPP (PAGE_SIZE / sizeof(grant_status_t))
 
 static inline grant_ref_t *__gnttab_entry(grant_ref_t entry)
 {
@@ -200,6 +210,7 @@ static void put_free_entry(grant_ref_t ref)
 }
 
 /*
+ * Following comments apply to update_grant_entry_v1 and update_grant_entry_v2.
  * Introducing a valid entry into the grant table:
  *  1. Write ent->domid.
  *  2. Write ent->frame:
@@ -218,6 +229,15 @@ static void update_grant_entry_v1(grant_ref_t ref, domid_t domid,
 	gnttab_shared.v1[ref].flags = flags;
 }
 
+static void update_grant_entry_v2(grant_ref_t ref, domid_t domid,
+				  unsigned long frame, unsigned flags)
+{
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	gnttab_shared.v2[ref].full_page.frame = frame;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags = GTF_permit_access | flags;
+}
+
 /*
  * Public grant-issuing interface functions
  */
@@ -249,6 +269,11 @@ static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
 }
 
+static int gnttab_query_foreign_access_v2(grant_ref_t ref)
+{
+	return grstatus[ref] & (GTF_reading|GTF_writing);
+}
+
 int gnttab_query_foreign_access(grant_ref_t ref)
 {
 	return gnttab_interface->query_foreign_access(ref);
@@ -273,6 +298,29 @@ static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 	return 1;
 }
 
+static int gnttab_end_foreign_access_ref_v2(grant_ref_t ref, int readonly)
+{
+	gnttab_shared.v2[ref].hdr.flags = 0;
+	mb();
+	if (grstatus[ref] & (GTF_reading|GTF_writing)) {
+		return 0;
+	} else {
+		/* The read of grstatus needs to have acquire
+		semantics.  On x86, reads already have
+		that, and we just need to protect against
+		compiler reorderings.  On other
+		architectures we may need a full
+		barrier. */
+#ifdef CONFIG_X86
+		barrier();
+#else
+		mb();
+#endif
+		}
+
+	return 1;
+}
+
 int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
 {
 	return gnttab_interface->end_foreign_access_ref(ref, readonly);
@@ -346,6 +394,37 @@ static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 	return frame;
 }
 
+static unsigned long gnttab_end_foreign_transfer_ref_v2(grant_ref_t ref)
+{
+	unsigned long frame;
+	u16           flags;
+	u16          *pflags;
+
+	pflags = &gnttab_shared.v2[ref].hdr.flags;
+
+	/*
+	 * If a transfer is not even yet started, try to reclaim the grant
+	 * reference and return failure (== 0).
+	 */
+	while (!((flags = *pflags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(pflags, flags, 0) == flags)
+			return 0;
+		cpu_relax();
+	}
+
+	/* If a transfer is in progress then wait until it is completed. */
+	while (!(flags & GTF_transfer_completed)) {
+		flags = *pflags;
+		cpu_relax();
+	}
+
+	rmb();  /* Read the frame number /after/ reading completion status. */
+	frame = gnttab_shared.v2[ref].full_page.frame;
+	BUG_ON(frame == 0);
+
+	return frame;
+}
+
 unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
 {
 	return gnttab_interface->end_foreign_transfer_ref(ref);
@@ -593,6 +672,11 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static unsigned nr_status_frames(unsigned nr_grant_frames)
+{
+	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
+}
+
 static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 {
 	int rc;
@@ -607,7 +691,56 @@ static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 
 static void gnttab_unmap_frames_v1(void)
 {
-	arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+}
+
+static int gnttab_map_frames_v2(unsigned long *frames, unsigned int nr_gframes)
+{
+	uint64_t *sframes;
+	unsigned int nr_sframes;
+	struct gnttab_get_status_frames getframes;
+	int rc;
+
+	nr_sframes = nr_status_frames(nr_gframes);
+
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_get_status_frames.
+	 */
+	sframes = kmalloc(nr_sframes  * sizeof(uint64_t), GFP_ATOMIC);
+	if (!sframes)
+		return -ENOMEM;
+
+	getframes.dom        = DOMID_SELF;
+	getframes.nr_frames  = nr_sframes;
+	set_xen_guest_handle(getframes.frame_list, sframes);
+
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_get_status_frames,
+				       &getframes, 1);
+	if (rc == -ENOSYS) {
+		kfree(sframes);
+		return -ENOSYS;
+	}
+
+	BUG_ON(rc || getframes.status);
+
+	rc = arch_gnttab_map_status(sframes, nr_sframes,
+				    nr_status_frames(gnttab_max_grant_frames()),
+				    &grstatus);
+	BUG_ON(rc);
+	kfree(sframes);
+
+	rc = arch_gnttab_map_shared(frames, nr_gframes,
+				    gnttab_max_grant_frames(),
+				    &gnttab_shared.addr);
+	BUG_ON(rc);
+
+	return 0;
+}
+
+static void gnttab_unmap_frames_v2(void)
+{
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(grstatus, nr_status_frames(nr_grant_frames));
 }
 
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
@@ -641,6 +774,9 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		return rc;
 	}
 
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_setup_table.
+	 */
 	frames = kmalloc(nr_gframes * sizeof(unsigned long), GFP_ATOMIC);
 	if (!frames)
 		return -ENOMEM;
@@ -673,10 +809,41 @@ static struct gnttab_ops gnttab_v1_ops = {
 	.query_foreign_access		= gnttab_query_foreign_access_v1,
 };
 
+static struct gnttab_ops gnttab_v2_ops = {
+	.map_frames			= gnttab_map_frames_v2,
+	.unmap_frames			= gnttab_unmap_frames_v2,
+	.update_entry			= update_grant_entry_v2,
+	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
+	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
+	.query_foreign_access		= gnttab_query_foreign_access_v2,
+};
+
 static void gnttab_request_version(void)
 {
-	grant_table_version = 1;
-	gnttab_interface = &gnttab_v1_ops;
+	int rc;
+	struct gnttab_set_version gsv;
+	const char *str = "we need grant tables version 2, but only version 1 is available\n";
+
+	gsv.version = 2;
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
+	if (rc == 0) {
+		grant_table_version = 2;
+		gnttab_interface = &gnttab_v2_ops;
+	} else {
+		if (grant_table_version == 2) {
+			/*
+			 * If we've already used version 2 features,
+			 * but then suddenly discover that they're not
+			 * available (e.g. migrating to an older
+			 * version of Xen), almost unbounded badness
+			 * can happen.
+			 */
+			xen_raw_printk(str);
+			panic(str);
+		}
+		grant_table_version = 1;
+		gnttab_interface = &gnttab_v1_ops;
+	}
 	printk(KERN_INFO "Grant tables using version %d layout.\n",
 		grant_table_version);
 }
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index c7a40f8..5494c40 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -146,8 +146,10 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
 			   void **__shared);
-void arch_gnttab_unmap_shared(void *shared,
-			      unsigned long nr_gframes);
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared);
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes);
 
 extern unsigned long xen_hvm_resume_frames;
 unsigned int gnttab_max_grant_frames(void);
-- 
1.7.6.4


--------------050906020008090403000009
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------050906020008090403000009--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:51:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:51:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQXE-0003Af-OI; Mon, 21 Nov 2011 09:51:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSQXC-00038w-U9
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 09:51:31 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1321869061!3947385!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29248 invoked from network); 21 Nov 2011 09:51:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 09:51:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAL9ov9C004065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 21 Nov 2011 09:50:58 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAL9osVK007648
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 21 Nov 2011 09:50:55 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAL9oltb024374; Mon, 21 Nov 2011 03:50:47 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 01:50:46 -0800
Message-ID: <4ECA1F0D.5070303@oracle.com>
Date: Mon, 21 Nov 2011 17:51:09 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EC3B62F.6080702@oracle.com>	
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>	
	<4EC62E77.7090007@oracle.com>	
	<1321613689.3664.305.camel@zakaz.uk.xensource.com>	
	<4EC6818B.3010904@oracle.com>
	<1321632271.3664.367.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321632271.3664.367.camel@zakaz.uk.xensource.com>
Content-Type: multipart/mixed; boundary="------------050700040602000504040002"
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4ECA1F03.005D,ss=1,re=-2.300,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
 V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------050700040602000504040002
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

This patch changes two places from the last one,
* removing gnttab_v1_ops
* change update_grant_entry_v1 into gnttab_update_entry_v1

Thanks
Annie

On 2011-11-19 0:04, Ian Campbell wrote:
>>>> +static struct gnttab_ops gnttab_v1_ops = {
>>>> +       .map_frames                     = gnttab_map_frames_v1,
>>>> +       .unmap_frames                   = gnttab_unmap_frames_v1,
>>>> +       .update_entry                   = update_grant_entry_v1,
>>>>
>>> Any reason this one is not gnttab_foo?
>>>
>> Actually no, just keep the original name of this function. I'd like to
>> change it, maybe gnttab_update_entry_v1 is better?
> I think so. Similarly for the v2 variant.
>
> Ian.
>
>

--------------050700040602000504040002
Content-Type: text/plain;
 name="0001-xen-granttable-Introducing-grant-table-V2-stucture.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0="0001-xen-granttable-Introducing-grant-table-V2-stucture.patc";
 filename*1="h"

RnJvbSBjMTBlYjg5NWFiYjU3OWU1MDc1OWJhZmNiZmQ1NGFlODAyMDZiYWIwIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4K
RGF0ZTogRnJpLCAxOCBOb3YgMjAxMSAxNjowNzoxNiArMDgwMApTdWJqZWN0OiBbUEFUQ0gg
MS80XSB4ZW4vZ3JhbnR0YWJsZTogSW50cm9kdWNpbmcgZ3JhbnQgdGFibGUgVjIgc3R1Y3R1
cmUKClRoaXMgcGF0Y2ggaW50cm9kdWNlcyBuZXcgc3RydWN0dXJlcyBvZiBncmFudCB0YWJs
ZSBWMiwgZ3JhbnQgdGFibGUgVjIgaXMgYW4KZXh0ZW5zaW9uIGZyb20gVjEuIEdyYW50IHRh
YmxlIGlzIHNoYXJlZCBiZXR3ZWVuIGd1ZXN0IGFuZCBYZW4sIGFuZCBYZW4gaXMKcmVzcG9u
c2libGUgdG8gZG8gY29ycmVzcG9uZGluZyB3b3JrIGZvciBncmFudCBvcGVyYXRpb25zLCBz
dWNoIGFzOiBmaWd1cmUKb3V0IGd1ZXN0J3MgZ3JhbnQgdGFibGUgdmVyc2lvbiwgcGVyZm9y
bSBkaWZmZXJlbnQgYWN0aW9ucyBiYXNlZCBvbgpkaWZmZXJlbnQgZ3JhbnQgdGFibGUgdmVy
c2lvbiwgZXRjLiBBbHRob3VnaCBmdWxsLXBhZ2Ugc3RydWN0dXJlIG9mIFYyCmlzIGRpZmZl
cmVudCBmcm9tIFYxLCBpdCBwbGF5IHRoZSBzYW1lIHJvbGUgYXMgVjEuCgpTaWduZWQtb2Zm
LWJ5OiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4v
Z3JhbnQtdGFibGUuYyAgICAgICAgICB8ICAgIDcgKy0KIGRyaXZlcnMveGVuL2dyYW50LXRh
YmxlLmMgICAgICAgICAgIHwgIDE4MiArKysrKysrKysrKysrKysrKysrKysrKysrKystLS0t
LS0tLQogaW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUuaCAgICAgICAgICAgfCAgICA0ICstCiBp
bmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaCB8ICAxNjcgKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKy0KIGluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaCAgICAg
ICAgIHwgICAgMiArCiA1IGZpbGVzIGNoYW5nZWQsIDMxMSBpbnNlcnRpb25zKCspLCA1MSBk
ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYyBi
L2FyY2gveDg2L3hlbi9ncmFudC10YWJsZS5jCmluZGV4IDZiYmZkN2EuLmM2YWIyZTcgMTAw
NjQ0Ci0tLSBhL2FyY2gveDg2L3hlbi9ncmFudC10YWJsZS5jCisrKyBiL2FyY2gveDg2L3hl
bi9ncmFudC10YWJsZS5jCkBAIC02NCwxMCArNjQsMTAgQEAgc3RhdGljIGludCB1bm1hcF9w
dGVfZm4ocHRlX3QgKnB0ZSwgc3RydWN0IHBhZ2UgKnBtZF9wYWdlLAogCiBpbnQgYXJjaF9n
bnR0YWJfbWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGxvbmcg
bnJfZ2ZyYW1lcywKIAkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFtZXMsCi0JCQkg
ICBzdHJ1Y3QgZ3JhbnRfZW50cnkgKipfX3NoYXJlZCkKKwkJCSAgIHZvaWQgKipfX3NoYXJl
ZCkKIHsKIAlpbnQgcmM7Ci0Jc3RydWN0IGdyYW50X2VudHJ5ICpzaGFyZWQgPSAqX19zaGFy
ZWQ7CisJdm9pZCAqc2hhcmVkID0gKl9fc2hhcmVkOwogCiAJaWYgKHNoYXJlZCA9PSBOVUxM
KSB7CiAJCXN0cnVjdCB2bV9zdHJ1Y3QgKmFyZWEgPQpAQCAtODMsOCArODMsNyBAQCBpbnQg
YXJjaF9nbnR0YWJfbWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVk
IGxvbmcgbnJfZ2ZyYW1lcywKIAlyZXR1cm4gcmM7CiB9CiAKLXZvaWQgYXJjaF9nbnR0YWJf
dW5tYXBfc2hhcmVkKHN0cnVjdCBncmFudF9lbnRyeSAqc2hhcmVkLAotCQkJICAgICAgdW5z
aWduZWQgbG9uZyBucl9nZnJhbWVzKQordm9pZCBhcmNoX2dudHRhYl91bm1hcF9zaGFyZWQo
dm9pZCAqc2hhcmVkLCB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpCiB7CiAJYXBwbHlfdG9f
cGFnZV9yYW5nZSgmaW5pdF9tbSwgKHVuc2lnbmVkIGxvbmcpc2hhcmVkLAogCQkJICAgIFBB
R0VfU0laRSAqIG5yX2dmcmFtZXMsIHVubWFwX3B0ZV9mbiwgTlVMTCk7CmRpZmYgLS1naXQg
YS9kcml2ZXJzL3hlbi9ncmFudC10YWJsZS5jIGIvZHJpdmVycy94ZW4vZ3JhbnQtdGFibGUu
YwppbmRleCBiZjFjMDk0Li41ZDkzMWI4IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9ncmFu
dC10YWJsZS5jCisrKyBiL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMKQEAgLTUzLDcgKzUz
LDcgQEAKIC8qIEV4dGVybmFsIHRvb2xzIHJlc2VydmUgZmlyc3QgZmV3IGdyYW50IHRhYmxl
IGVudHJpZXMuICovCiAjZGVmaW5lIE5SX1JFU0VSVkVEX0VOVFJJRVMgOAogI2RlZmluZSBH
TlRUQUJfTElTVF9FTkQgMHhmZmZmZmZmZgotI2RlZmluZSBHUkVGU19QRVJfR1JBTlRfRlJB
TUUgKFBBR0VfU0laRSAvIHNpemVvZihzdHJ1Y3QgZ3JhbnRfZW50cnkpKQorI2RlZmluZSBH
UkVGU19QRVJfR1JBTlRfRlJBTUUgKFBBR0VfU0laRSAvIHNpemVvZihzdHJ1Y3QgZ3JhbnRf
ZW50cnlfdjEpKQogCiBzdGF0aWMgZ3JhbnRfcmVmX3QgKipnbnR0YWJfbGlzdDsKIHN0YXRp
YyB1bnNpZ25lZCBpbnQgbnJfZ3JhbnRfZnJhbWVzOwpAQCAtNjQsNyArNjQsNjQgQEAgc3Rh
dGljIERFRklORV9TUElOTE9DSyhnbnR0YWJfbGlzdF9sb2NrKTsKIHVuc2lnbmVkIGxvbmcg
eGVuX2h2bV9yZXN1bWVfZnJhbWVzOwogRVhQT1JUX1NZTUJPTF9HUEwoeGVuX2h2bV9yZXN1
bWVfZnJhbWVzKTsKIAotc3RhdGljIHN0cnVjdCBncmFudF9lbnRyeSAqc2hhcmVkOworc3Rh
dGljIHVuaW9uIHsKKwlzdHJ1Y3QgZ3JhbnRfZW50cnlfdjEgKnYxOworCXZvaWQgKmFkZHI7
Cit9IGdudHRhYl9zaGFyZWQ7CisKKy8qVGhpcyBpcyBhIHN0cnVjdHVyZSBvZiBmdW5jdGlv
biBwb2ludGVycyBmb3IgZ3JhbnQgdGFibGUqLworc3RydWN0IGdudHRhYl9vcHMgeworCS8q
CisJICogTWFwcGluZyBhIGxpc3Qgb2YgZnJhbWVzIGZvciBzdG9yaW5nIGdyYW50IGVudHJp
ZXMuIEZpcnN0IGlucHV0CisJICogcGFyYW1ldGVyIGlzIHVzZWQgdG8gc3RvcmluZyBncmFu
dCB0YWJsZSBhZGRyZXNzIHdoZW4gZ3JhbnQgdGFibGUKKwkgKiBiZWluZyBzZXR1cCwgc2Vj
b25kIHBhcmFtZXRlciBpcyB0aGUgbnVtYmVyIG9mIGZyYW1lcyB0byBtYXAgZ3JhbnQKKwkg
KiB0YWJsZS4gUmV0dXJuaW5nIEdOVFNUX29rYXkgbWVhbnMgc3VjY2VzcyBhbmQgbmVnYXRp
dmUgdmFsdWUgbWVhbnMKKwkgKiBmYWlsdXJlLgorCSAqLworCWludCAoKm1hcF9mcmFtZXMp
KHVuc2lnbmVkIGxvbmcgKiwgdW5zaWduZWQgaW50KTsKKwkvKgorCSAqIFJlbGVhc2UgYSBs
aXN0IG9mIGZyYW1lcyB3aGljaCBhcmUgbWFwcGVkIGluIG1hcF9mcmFtZXMgZm9yIGdyYW50
CisJICogZW50cnkgc3RhdHVzLgorCSAqLworCXZvaWQgKCp1bm1hcF9mcmFtZXMpKHZvaWQp
OworCS8qCisJICogSW50cm9kdWNpbmcgYSB2YWxpZCBlbnRyeSBpbnRvIHRoZSBncmFudCB0
YWJsZSwgZ3JhbnRpbmcgdGhlIGZyYW1lCisJICogb2YgdGhpcyBncmFudCBlbnRyeSB0byBk
b21haW4gZm9yIGFjY2Vzc2luZywgb3IgdHJhbnNmZXJpbmcsIG9yCisJICogdHJhbnNpdGl2
ZWx5IGFjY2Vzc2luZy4gRmlyc3QgaW5wdXQgcGFyYW1ldGVyIGlzIHJlZmVyZW5jZSBvZiB0
aGlzCisJICogaW50cm9kdWNlZCBncmFudCBlbnRyeSwgc2Vjb25kIG9uZSBpcyBkb21pZCBv
ZiBncmFudGVkIGRvbWFpbiwgdGhpcmQKKwkgKiBvbmUgaXMgdGhlIGZyYW1lIHRvIGJlIGdy
YW50ZWQsIGFuZCB0aGUgbGFzdCBvbmUgaXMgc3RhdHVzIG9mIHRoZQorCSAqIGdyYW50IGVu
dHJ5IHRvIGJlIHVwZGF0ZWQuCisJICovCisJdm9pZCAoKnVwZGF0ZV9lbnRyeSkoZ3JhbnRf
cmVmX3QsIGRvbWlkX3QsIHVuc2lnbmVkIGxvbmcsIHVuc2lnbmVkKTsKKwkvKgorCSAqIFN0
b3AgZ3JhbnRpbmcgYSBncmFudCBlbnRyeSB0byBkb21haW4gZm9yIGFjY2Vzc2luZy4gRmly
c3QgaW5wdXQKKwkgKiBwYXJhbWV0ZXIgaXMgcmVmZXJlbmNlIG9mIGEgZ3JhbnQgZW50cnkg
d2hvc2UgZ3JhbnQgYWNjZXNzIHdpbGwgYmUKKwkgKiBzdG9wcGVkLCBzZWNvbmQgb25lIGlz
IG5vdCBpbiB1c2Ugbm93LiBJZiB0aGUgZ3JhbnQgZW50cnkgaXMKKwkgKiBjdXJyZW50bHkg
bWFwcGVkIGZvciByZWFkaW5nIG9yIHdyaXRpbmcsIGp1c3QgcmV0dXJuIGZhaWx1cmUoPT0w
KQorCSAqIGRpcmVjdGx5IGFuZCBkb24ndCB0ZWFyIGRvd24gdGhlIGdyYW50IGFjY2Vzcy4g
T3RoZXJ3aXNlLCBzdG9wIGdyYW50CisJICogYWNjZXNzIGZvciB0aGlzIGVudHJ5IGFuZCBy
ZXR1cm4gc3VjY2Vzcyg9PTEpLgorCSAqLworCWludCAoKmVuZF9mb3JlaWduX2FjY2Vzc19y
ZWYpKGdyYW50X3JlZl90LCBpbnQpOworCS8qCisJICogU3RvcCBncmFudGluZyBhIGdyYW50
IGVudHJ5IHRvIGRvbWFpbiBmb3IgdHJhbnNmZXIuIElmIHRyYW5mZXIgaGFzCisJICogbm90
IHN0YXJ0ZWQsIGp1c3QgcmVjbGFpbSB0aGUgZ3JhbnQgZW50cnkgYW5kIHJldHVybiBmYWls
dXJlKD09MCkuCisJICogT3RoZXJ3aXNlLCB3YWl0IGZvciB0aGUgdHJhbnNmZXIgdG8gY29t
cGxldGUgYW5kIHRoZW4gcmV0dXJuIHRoZQorCSAqIGZyYW1lLgorCSAqLworCXVuc2lnbmVk
IGxvbmcgKCplbmRfZm9yZWlnbl90cmFuc2Zlcl9yZWYpKGdyYW50X3JlZl90KTsKKwkvKgor
CSAqIFF1ZXJ5IHRoZSBzdGF0dXMgb2YgYSBncmFudCBlbnRyeS4gSW5wdXQgcGFyYW1ldGVy
IGlzIHJlZmVyZW5jZSBvZgorCSAqIHF1ZXJpZWQgZ3JhbnQgZW50cnksIHJldHVybiB2YWx1
ZSBpcyB0aGUgc3RhdHVzIG9mIHF1ZXJpZWQgZW50cnkuCisJICogRGV0YWlsZWQgc3RhdHVz
KHdyaXRpbmcvcmVhZGluZykgY2FuIGJlIGdvdHRlbiBmcm9tIHRoZSByZXR1cm4gdmFsdWUK
KwkgKiBieSBiaXQgb3BlcmF0aW9ucy4KKwkgKi8KKwlpbnQgKCpxdWVyeV9mb3JlaWduX2Fj
Y2VzcykoZ3JhbnRfcmVmX3QpOworfTsKKworc3RhdGljIHN0cnVjdCBnbnR0YWJfb3BzIGdu
dHRhYl92MV9vcHM7CitzdGF0aWMgc3RydWN0IGdudHRhYl9vcHMgKmdudHRhYl9pbnRlcmZh
Y2U7CisKK3N0YXRpYyBpbnQgZ3JhbnRfdGFibGVfdmVyc2lvbjsKIAogc3RhdGljIHN0cnVj
dCBnbnR0YWJfZnJlZV9jYWxsYmFjayAqZ250dGFiX2ZyZWVfY2FsbGJhY2tfbGlzdDsKIApA
QCAtMTQyLDIzICsxOTksMjMgQEAgc3RhdGljIHZvaWQgcHV0X2ZyZWVfZW50cnkoZ3JhbnRf
cmVmX3QgcmVmKQogCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmdudHRhYl9saXN0X2xvY2ss
IGZsYWdzKTsKIH0KIAotc3RhdGljIHZvaWQgdXBkYXRlX2dyYW50X2VudHJ5KGdyYW50X3Jl
Zl90IHJlZiwgZG9taWRfdCBkb21pZCwKLQkJCSAgICAgICB1bnNpZ25lZCBsb25nIGZyYW1l
LCB1bnNpZ25lZCBmbGFncykKKy8qCisgKiBJbnRyb2R1Y2luZyBhIHZhbGlkIGVudHJ5IGlu
dG8gdGhlIGdyYW50IHRhYmxlOgorICogIDEuIFdyaXRlIGVudC0+ZG9taWQuCisgKiAgMi4g
V3JpdGUgZW50LT5mcmFtZToKKyAqICAgICAgR1RGX3Blcm1pdF9hY2Nlc3M6ICAgRnJhbWUg
dG8gd2hpY2ggYWNjZXNzIGlzIHBlcm1pdHRlZC4KKyAqICAgICAgR1RGX2FjY2VwdF90cmFu
c2ZlcjogUHNldWRvLXBoeXMgZnJhbWUgc2xvdCBiZWluZyBmaWxsZWQgYnkgbmV3CisgKiAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGZyYW1lLCBvciB6ZXJvIGlmIG5vbmUuCisgKiAg
My4gV3JpdGUgbWVtb3J5IGJhcnJpZXIgKFdNQikuCisgKiAgNC4gV3JpdGUgZW50LT5mbGFn
cywgaW5jLiB2YWxpZCB0eXBlLgorICovCitzdGF0aWMgdm9pZCB1cGRhdGVfZ3JhbnRfZW50
cnlfdjEoZ3JhbnRfcmVmX3QgcmVmLCBkb21pZF90IGRvbWlkLAorCQkJCSAgdW5zaWduZWQg
bG9uZyBmcmFtZSwgdW5zaWduZWQgZmxhZ3MpCiB7Ci0JLyoKLQkgKiBJbnRyb2R1Y2luZyBh
IHZhbGlkIGVudHJ5IGludG8gdGhlIGdyYW50IHRhYmxlOgotCSAqICAxLiBXcml0ZSBlbnQt
PmRvbWlkLgotCSAqICAyLiBXcml0ZSBlbnQtPmZyYW1lOgotCSAqICAgICAgR1RGX3Blcm1p
dF9hY2Nlc3M6ICAgRnJhbWUgdG8gd2hpY2ggYWNjZXNzIGlzIHBlcm1pdHRlZC4KLQkgKiAg
ICAgIEdURl9hY2NlcHRfdHJhbnNmZXI6IFBzZXVkby1waHlzIGZyYW1lIHNsb3QgYmVpbmcg
ZmlsbGVkIGJ5IG5ldwotCSAqICAgICAgICAgICAgICAgICAgICAgICAgICAgZnJhbWUsIG9y
IHplcm8gaWYgbm9uZS4KLQkgKiAgMy4gV3JpdGUgbWVtb3J5IGJhcnJpZXIgKFdNQikuCi0J
ICogIDQuIFdyaXRlIGVudC0+ZmxhZ3MsIGluYy4gdmFsaWQgdHlwZS4KLQkgKi8KLQlzaGFy
ZWRbcmVmXS5mcmFtZSA9IGZyYW1lOwotCXNoYXJlZFtyZWZdLmRvbWlkID0gZG9taWQ7CisJ
Z250dGFiX3NoYXJlZC52MVtyZWZdLmRvbWlkID0gZG9taWQ7CisJZ250dGFiX3NoYXJlZC52
MVtyZWZdLmZyYW1lID0gZnJhbWU7CiAJd21iKCk7Ci0Jc2hhcmVkW3JlZl0uZmxhZ3MgPSBm
bGFnczsKKwlnbnR0YWJfc2hhcmVkLnYxW3JlZl0uZmxhZ3MgPSBmbGFnczsKIH0KIAogLyoK
QEAgLTE2Nyw3ICsyMjQsNyBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfZ3JhbnRfZW50cnkoZ3Jh
bnRfcmVmX3QgcmVmLCBkb21pZF90IGRvbWlkLAogdm9pZCBnbnR0YWJfZ3JhbnRfZm9yZWln
bl9hY2Nlc3NfcmVmKGdyYW50X3JlZl90IHJlZiwgZG9taWRfdCBkb21pZCwKIAkJCQkgICAg
IHVuc2lnbmVkIGxvbmcgZnJhbWUsIGludCByZWFkb25seSkKIHsKLQl1cGRhdGVfZ3JhbnRf
ZW50cnkocmVmLCBkb21pZCwgZnJhbWUsCisJZ250dGFiX2ludGVyZmFjZS0+dXBkYXRlX2Vu
dHJ5KHJlZiwgZG9taWQsIGZyYW1lLAogCQkJICAgR1RGX3Blcm1pdF9hY2Nlc3MgfCAocmVh
ZG9ubHkgPyBHVEZfcmVhZG9ubHkgOiAwKSk7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0
YWJfZ3JhbnRfZm9yZWlnbl9hY2Nlc3NfcmVmKTsKQEAgLTE4NywzMSArMjQ0LDM3IEBAIGlu
dCBnbnR0YWJfZ3JhbnRfZm9yZWlnbl9hY2Nlc3MoZG9taWRfdCBkb21pZCwgdW5zaWduZWQg
bG9uZyBmcmFtZSwKIH0KIEVYUE9SVF9TWU1CT0xfR1BMKGdudHRhYl9ncmFudF9mb3JlaWdu
X2FjY2Vzcyk7CiAKLWludCBnbnR0YWJfcXVlcnlfZm9yZWlnbl9hY2Nlc3MoZ3JhbnRfcmVm
X3QgcmVmKQorc3RhdGljIGludCBnbnR0YWJfcXVlcnlfZm9yZWlnbl9hY2Nlc3NfdjEoZ3Jh
bnRfcmVmX3QgcmVmKQogewotCXUxNiBuZmxhZ3M7Ci0KLQluZmxhZ3MgPSBzaGFyZWRbcmVm
XS5mbGFnczsKKwlyZXR1cm4gZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzICYgKEdURl9y
ZWFkaW5nfEdURl93cml0aW5nKTsKK30KIAotCXJldHVybiBuZmxhZ3MgJiAoR1RGX3JlYWRp
bmd8R1RGX3dyaXRpbmcpOworaW50IGdudHRhYl9xdWVyeV9mb3JlaWduX2FjY2VzcyhncmFu
dF9yZWZfdCByZWYpCit7CisJcmV0dXJuIGdudHRhYl9pbnRlcmZhY2UtPnF1ZXJ5X2ZvcmVp
Z25fYWNjZXNzKHJlZik7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfcXVlcnlfZm9y
ZWlnbl9hY2Nlc3MpOwogCi1pbnQgZ250dGFiX2VuZF9mb3JlaWduX2FjY2Vzc19yZWYoZ3Jh
bnRfcmVmX3QgcmVmLCBpbnQgcmVhZG9ubHkpCitzdGF0aWMgaW50IGdudHRhYl9lbmRfZm9y
ZWlnbl9hY2Nlc3NfcmVmX3YxKGdyYW50X3JlZl90IHJlZiwgaW50IHJlYWRvbmx5KQogewog
CXUxNiBmbGFncywgbmZsYWdzOwogCi0JbmZsYWdzID0gc2hhcmVkW3JlZl0uZmxhZ3M7CisJ
bmZsYWdzID0gZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzOwogCWRvIHsKIAkJZmxhZ3Mg
PSBuZmxhZ3M7CiAJCWlmIChmbGFncyAmIChHVEZfcmVhZGluZ3xHVEZfd3JpdGluZykpIHsK
IAkJCXByaW50ayhLRVJOX0FMRVJUICJXQVJOSU5HOiBnLmUuIHN0aWxsIGluIHVzZSFcbiIp
OwogCQkJcmV0dXJuIDA7CiAJCX0KLQl9IHdoaWxlICgobmZsYWdzID0gc3luY19jbXB4Y2hn
KCZzaGFyZWRbcmVmXS5mbGFncywgZmxhZ3MsIDApKSAhPSBmbGFncyk7CisJfSB3aGlsZSAo
KG5mbGFncyA9IHN5bmNfY21weGNoZygmZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzLCBm
bGFncywgMCkpICE9IGZsYWdzKTsKIAogCXJldHVybiAxOwogfQorCitpbnQgZ250dGFiX2Vu
ZF9mb3JlaWduX2FjY2Vzc19yZWYoZ3JhbnRfcmVmX3QgcmVmLCBpbnQgcmVhZG9ubHkpCit7
CisJcmV0dXJuIGdudHRhYl9pbnRlcmZhY2UtPmVuZF9mb3JlaWduX2FjY2Vzc19yZWYocmVm
LCByZWFkb25seSk7Cit9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfZW5kX2ZvcmVpZ25f
YWNjZXNzX3JlZik7CiAKIHZvaWQgZ250dGFiX2VuZF9mb3JlaWduX2FjY2VzcyhncmFudF9y
ZWZfdCByZWYsIGludCByZWFkb25seSwKQEAgLTI0NiwxMSArMzA5LDExIEBAIEVYUE9SVF9T
WU1CT0xfR1BMKGdudHRhYl9ncmFudF9mb3JlaWduX3RyYW5zZmVyKTsKIHZvaWQgZ250dGFi
X2dyYW50X2ZvcmVpZ25fdHJhbnNmZXJfcmVmKGdyYW50X3JlZl90IHJlZiwgZG9taWRfdCBk
b21pZCwKIAkJCQkgICAgICAgdW5zaWduZWQgbG9uZyBwZm4pCiB7Ci0JdXBkYXRlX2dyYW50
X2VudHJ5KHJlZiwgZG9taWQsIHBmbiwgR1RGX2FjY2VwdF90cmFuc2Zlcik7CisJZ250dGFi
X2ludGVyZmFjZS0+dXBkYXRlX2VudHJ5KHJlZiwgZG9taWQsIHBmbiwgR1RGX2FjY2VwdF90
cmFuc2Zlcik7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfZ3JhbnRfZm9yZWlnbl90
cmFuc2Zlcl9yZWYpOwogCi11bnNpZ25lZCBsb25nIGdudHRhYl9lbmRfZm9yZWlnbl90cmFu
c2Zlcl9yZWYoZ3JhbnRfcmVmX3QgcmVmKQorc3RhdGljIHVuc2lnbmVkIGxvbmcgZ250dGFi
X2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZl92MShncmFudF9yZWZfdCByZWYpCiB7CiAJdW5z
aWduZWQgbG9uZyBmcmFtZTsKIAl1MTYgICAgICAgICAgIGZsYWdzOwpAQCAtMjU5LDI0ICsz
MjIsMjkgQEAgdW5zaWduZWQgbG9uZyBnbnR0YWJfZW5kX2ZvcmVpZ25fdHJhbnNmZXJfcmVm
KGdyYW50X3JlZl90IHJlZikKIAkgKiBJZiBhIHRyYW5zZmVyIGlzIG5vdCBldmVuIHlldCBz
dGFydGVkLCB0cnkgdG8gcmVjbGFpbSB0aGUgZ3JhbnQKIAkgKiByZWZlcmVuY2UgYW5kIHJl
dHVybiBmYWlsdXJlICg9PSAwKS4KIAkgKi8KLQl3aGlsZSAoISgoZmxhZ3MgPSBzaGFyZWRb
cmVmXS5mbGFncykgJiBHVEZfdHJhbnNmZXJfY29tbWl0dGVkKSkgewotCQlpZiAoc3luY19j
bXB4Y2hnKCZzaGFyZWRbcmVmXS5mbGFncywgZmxhZ3MsIDApID09IGZsYWdzKQorCXdoaWxl
ICghKChmbGFncyA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mbGFncykgJiBHVEZfdHJhbnNm
ZXJfY29tbWl0dGVkKSkgeworCQlpZiAoc3luY19jbXB4Y2hnKCZnbnR0YWJfc2hhcmVkLnYx
W3JlZl0uZmxhZ3MsIGZsYWdzLCAwKSA9PSBmbGFncykKIAkJCXJldHVybiAwOwogCQljcHVf
cmVsYXgoKTsKIAl9CiAKIAkvKiBJZiBhIHRyYW5zZmVyIGlzIGluIHByb2dyZXNzIHRoZW4g
d2FpdCB1bnRpbCBpdCBpcyBjb21wbGV0ZWQuICovCiAJd2hpbGUgKCEoZmxhZ3MgJiBHVEZf
dHJhbnNmZXJfY29tcGxldGVkKSkgewotCQlmbGFncyA9IHNoYXJlZFtyZWZdLmZsYWdzOwor
CQlmbGFncyA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mbGFnczsKIAkJY3B1X3JlbGF4KCk7
CiAJfQogCiAJcm1iKCk7CS8qIFJlYWQgdGhlIGZyYW1lIG51bWJlciAvYWZ0ZXIvIHJlYWRp
bmcgY29tcGxldGlvbiBzdGF0dXMuICovCi0JZnJhbWUgPSBzaGFyZWRbcmVmXS5mcmFtZTsK
KwlmcmFtZSA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mcmFtZTsKIAlCVUdfT04oZnJhbWUg
PT0gMCk7CiAKIAlyZXR1cm4gZnJhbWU7CiB9CisKK3Vuc2lnbmVkIGxvbmcgZ250dGFiX2Vu
ZF9mb3JlaWduX3RyYW5zZmVyX3JlZihncmFudF9yZWZfdCByZWYpCit7CisJcmV0dXJuIGdu
dHRhYl9pbnRlcmZhY2UtPmVuZF9mb3JlaWduX3RyYW5zZmVyX3JlZihyZWYpOworfQogRVhQ
T1JUX1NZTUJPTF9HUEwoZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZik7CiAKIHVu
c2lnbmVkIGxvbmcgZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyKGdyYW50X3JlZl90IHJl
ZikKQEAgLTUyMCw2ICs1ODgsMjMgQEAgaW50IGdudHRhYl91bm1hcF9yZWZzKHN0cnVjdCBn
bnR0YWJfdW5tYXBfZ3JhbnRfcmVmICp1bm1hcF9vcHMsCiB9CiBFWFBPUlRfU1lNQk9MX0dQ
TChnbnR0YWJfdW5tYXBfcmVmcyk7CiAKK3N0YXRpYyBpbnQgZ250dGFiX21hcF9mcmFtZXNf
djEodW5zaWduZWQgbG9uZyAqZnJhbWVzLCB1bnNpZ25lZCBpbnQgbnJfZ2ZyYW1lcykKK3sK
KwlpbnQgcmM7CisKKwlyYyA9IGFyY2hfZ250dGFiX21hcF9zaGFyZWQoZnJhbWVzLCBucl9n
ZnJhbWVzLAorCQkJCSAgICBnbnR0YWJfbWF4X2dyYW50X2ZyYW1lcygpLAorCQkJCSAgICAm
Z250dGFiX3NoYXJlZC5hZGRyKTsKKwlCVUdfT04ocmMpOworCisJcmV0dXJuIDA7Cit9CisK
K3N0YXRpYyB2b2lkIGdudHRhYl91bm1hcF9mcmFtZXNfdjEodm9pZCkKK3sKKwlhcmNoX2du
dHRhYl91bm1hcF9zaGFyZWQoZ250dGFiX3NoYXJlZC5hZGRyLCBucl9ncmFudF9mcmFtZXMp
OworfQorCiBzdGF0aWMgaW50IGdudHRhYl9tYXAodW5zaWduZWQgaW50IHN0YXJ0X2lkeCwg
dW5zaWduZWQgaW50IGVuZF9pZHgpCiB7CiAJc3RydWN0IGdudHRhYl9zZXR1cF90YWJsZSBz
ZXR1cDsKQEAgLTU2NywxOSArNjUyLDM1IEBAIHN0YXRpYyBpbnQgZ250dGFiX21hcCh1bnNp
Z25lZCBpbnQgc3RhcnRfaWR4LCB1bnNpZ25lZCBpbnQgZW5kX2lkeCkKIAogCUJVR19PTihy
YyB8fCBzZXR1cC5zdGF0dXMpOwogCi0JcmMgPSBhcmNoX2dudHRhYl9tYXBfc2hhcmVkKGZy
YW1lcywgbnJfZ2ZyYW1lcywgZ250dGFiX21heF9ncmFudF9mcmFtZXMoKSwKLQkJCQkgICAg
JnNoYXJlZCk7Ci0JQlVHX09OKHJjKTsKKwlyYyA9IGdudHRhYl9pbnRlcmZhY2UtPm1hcF9m
cmFtZXMoZnJhbWVzLCBucl9nZnJhbWVzKTsKIAogCWtmcmVlKGZyYW1lcyk7CiAKLQlyZXR1
cm4gMDsKKwlyZXR1cm4gcmM7Cit9CisKK3N0YXRpYyBzdHJ1Y3QgZ250dGFiX29wcyBnbnR0
YWJfdjFfb3BzID0geworCS5tYXBfZnJhbWVzCQkJPSBnbnR0YWJfbWFwX2ZyYW1lc192MSwK
KwkudW5tYXBfZnJhbWVzCQkJPSBnbnR0YWJfdW5tYXBfZnJhbWVzX3YxLAorCS51cGRhdGVf
ZW50cnkJCQk9IHVwZGF0ZV9ncmFudF9lbnRyeV92MSwKKwkuZW5kX2ZvcmVpZ25fYWNjZXNz
X3JlZgkJPSBnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzX3JlZl92MSwKKwkuZW5kX2ZvcmVp
Z25fdHJhbnNmZXJfcmVmCT0gZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZl92MSwK
KwkucXVlcnlfZm9yZWlnbl9hY2Nlc3MJCT0gZ250dGFiX3F1ZXJ5X2ZvcmVpZ25fYWNjZXNz
X3YxLAorfTsKKworc3RhdGljIHZvaWQgZ250dGFiX3JlcXVlc3RfdmVyc2lvbih2b2lkKQor
eworCWdyYW50X3RhYmxlX3ZlcnNpb24gPSAxOworCWdudHRhYl9pbnRlcmZhY2UgPSAmZ250
dGFiX3YxX29wczsKKwlwcmludGsoS0VSTl9JTkZPICJHcmFudCB0YWJsZXMgdXNpbmcgdmVy
c2lvbiAlZCBsYXlvdXQuXG4iLAorCQlncmFudF90YWJsZV92ZXJzaW9uKTsKIH0KIAogaW50
IGdudHRhYl9yZXN1bWUodm9pZCkKIHsKIAl1bnNpZ25lZCBpbnQgbWF4X25yX2dmcmFtZXM7
CiAKKwlnbnR0YWJfcmVxdWVzdF92ZXJzaW9uKCk7CiAJbWF4X25yX2dmcmFtZXMgPSBnbnR0
YWJfbWF4X2dyYW50X2ZyYW1lcygpOwogCWlmIChtYXhfbnJfZ2ZyYW1lcyA8IG5yX2dyYW50
X2ZyYW1lcykKIAkJcmV0dXJuIC1FTk9TWVM7CkBAIC01ODcsOSArNjg4LDEwIEBAIGludCBn
bnR0YWJfcmVzdW1lKHZvaWQpCiAJaWYgKHhlbl9wdl9kb21haW4oKSkKIAkJcmV0dXJuIGdu
dHRhYl9tYXAoMCwgbnJfZ3JhbnRfZnJhbWVzIC0gMSk7CiAKLQlpZiAoIXNoYXJlZCkgewot
CQlzaGFyZWQgPSBpb3JlbWFwKHhlbl9odm1fcmVzdW1lX2ZyYW1lcywgUEFHRV9TSVpFICog
bWF4X25yX2dmcmFtZXMpOwotCQlpZiAoc2hhcmVkID09IE5VTEwpIHsKKwlpZiAoZ250dGFi
X3NoYXJlZC5hZGRyID09IE5VTEwpIHsKKwkJZ250dGFiX3NoYXJlZC5hZGRyID0gaW9yZW1h
cCh4ZW5faHZtX3Jlc3VtZV9mcmFtZXMsCisJCQkJCQlQQUdFX1NJWkUgKiBtYXhfbnJfZ2Zy
YW1lcyk7CisJCWlmIChnbnR0YWJfc2hhcmVkLmFkZHIgPT0gTlVMTCkgewogCQkJcHJpbnRr
KEtFUk5fV0FSTklORwogCQkJCQkiRmFpbGVkIHRvIGlvcmVtYXAgZ250dGFiIHNoYXJlIGZy
YW1lcyEiKTsKIAkJCXJldHVybiAtRU5PTUVNOwpAQCAtNjAzLDcgKzcwNSw3IEBAIGludCBn
bnR0YWJfcmVzdW1lKHZvaWQpCiAKIGludCBnbnR0YWJfc3VzcGVuZCh2b2lkKQogewotCWFy
Y2hfZ250dGFiX3VubWFwX3NoYXJlZChzaGFyZWQsIG5yX2dyYW50X2ZyYW1lcyk7CisJZ250
dGFiX2ludGVyZmFjZS0+dW5tYXBfZnJhbWVzKCk7CiAJcmV0dXJuIDA7CiB9CiAKZGlmZiAt
LWdpdCBhL2luY2x1ZGUveGVuL2dyYW50X3RhYmxlLmggYi9pbmNsdWRlL3hlbi9ncmFudF90
YWJsZS5oCmluZGV4IDExZTJkZmMuLmM3YTQwZjggMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVu
L2dyYW50X3RhYmxlLmgKKysrIGIvaW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUuaApAQCAtMTQ1
LDggKzE0NSw4IEBAIGdudHRhYl9zZXRfdW5tYXBfb3Aoc3RydWN0IGdudHRhYl91bm1hcF9n
cmFudF9yZWYgKnVubWFwLCBwaHlzX2FkZHJfdCBhZGRyLAogCiBpbnQgYXJjaF9nbnR0YWJf
bWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGxvbmcgbnJfZ2Zy
YW1lcywKIAkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFtZXMsCi0JCQkgICBzdHJ1
Y3QgZ3JhbnRfZW50cnkgKipfX3NoYXJlZCk7Ci12b2lkIGFyY2hfZ250dGFiX3VubWFwX3No
YXJlZChzdHJ1Y3QgZ3JhbnRfZW50cnkgKnNoYXJlZCwKKwkJCSAgIHZvaWQgKipfX3NoYXJl
ZCk7Cit2b2lkIGFyY2hfZ250dGFiX3VubWFwX3NoYXJlZCh2b2lkICpzaGFyZWQsCiAJCQkg
ICAgICB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpOwogCiBleHRlcm4gdW5zaWduZWQgbG9u
ZyB4ZW5faHZtX3Jlc3VtZV9mcmFtZXM7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9pbnRl
cmZhY2UvZ3JhbnRfdGFibGUuaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFudF90YWJs
ZS5oCmluZGV4IDM5ZTU3MTcuLmExN2Q4NDQgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2lu
dGVyZmFjZS9ncmFudF90YWJsZS5oCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFu
dF90YWJsZS5oCkBAIC04NSwxMiArODUsMjIgQEAKICAqLwogCiAvKgorICogUmVmZXJlbmNl
IHRvIGEgZ3JhbnQgZW50cnkgaW4gYSBzcGVjaWZpZWQgZG9tYWluJ3MgZ3JhbnQgdGFibGUu
CisgKi8KK3R5cGVkZWYgdWludDMyX3QgZ3JhbnRfcmVmX3Q7CisKKy8qCiAgKiBBIGdyYW50
IHRhYmxlIGNvbXByaXNlcyBhIHBhY2tlZCBhcnJheSBvZiBncmFudCBlbnRyaWVzIGluIG9u
ZSBvciBtb3JlCiAgKiBwYWdlIGZyYW1lcyBzaGFyZWQgYmV0d2VlbiBYZW4gYW5kIGEgZ3Vl
c3QuCiAgKiBbWEVOXTogVGhpcyBmaWVsZCBpcyB3cml0dGVuIGJ5IFhlbiBhbmQgcmVhZCBi
eSB0aGUgc2hhcmluZyBndWVzdC4KICAqIFtHU1RdOiBUaGlzIGZpZWxkIGlzIHdyaXR0ZW4g
YnkgdGhlIGd1ZXN0IGFuZCByZWFkIGJ5IFhlbi4KICAqLwotc3RydWN0IGdyYW50X2VudHJ5
IHsKKworLyoKKyAqIFZlcnNpb24gMSBvZiB0aGUgZ3JhbnQgdGFibGUgZW50cnkgc3RydWN0
dXJlIGlzIG1haW50YWluZWQgcHVyZWx5CisgKiBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxp
dHkuICBOZXcgZ3Vlc3RzIHNob3VsZCB1c2UgdmVyc2lvbiAyLgorICovCitzdHJ1Y3QgZ3Jh
bnRfZW50cnlfdjEgewogICAgIC8qIEdURl94eHg6IHZhcmlvdXMgdHlwZSBhbmQgZmxhZyBp
bmZvcm1hdGlvbi4gIFtYRU4sR1NUXSAqLwogICAgIHVpbnQxNl90IGZsYWdzOwogICAgIC8q
IFRoZSBkb21haW4gYmVpbmcgZ3JhbnRlZCBmb3JlaWduIHByaXZpbGVnZXMuIFtHU1RdICov
CkBAIC0xMDgsMTAgKzExOCwxMyBAQCBzdHJ1Y3QgZ3JhbnRfZW50cnkgewogICogIEdURl9w
ZXJtaXRfYWNjZXNzOiBBbGxvdyBAZG9taWQgdG8gbWFwL2FjY2VzcyBAZnJhbWUuCiAgKiAg
R1RGX2FjY2VwdF90cmFuc2ZlcjogQWxsb3cgQGRvbWlkIHRvIHRyYW5zZmVyIG93bmVyc2hp
cCBvZiBvbmUgcGFnZSBmcmFtZQogICogICAgICAgICAgICAgICAgICAgICAgIHRvIHRoaXMg
Z3Vlc3QuIFhlbiB3cml0ZXMgdGhlIHBhZ2UgbnVtYmVyIHRvIEBmcmFtZS4KKyAqICBHVEZf
dHJhbnNpdGl2ZTogQWxsb3cgQGRvbWlkIHRvIHRyYW5zaXRpdmVseSBhY2Nlc3MgYSBzdWJy
YW5nZSBvZgorICogICAgICAgICAgICAgICAgICBAdHJhbnNfZ3JhbnQgaW4gQHRyYW5zX2Rv
bWlkLiAgTm8gbWFwcGluZ3MgYXJlIGFsbG93ZWQuCiAgKi8KICNkZWZpbmUgR1RGX2ludmFs
aWQgICAgICAgICAoMFU8PDApCiAjZGVmaW5lIEdURl9wZXJtaXRfYWNjZXNzICAgKDFVPDww
KQogI2RlZmluZSBHVEZfYWNjZXB0X3RyYW5zZmVyICgyVTw8MCkKKyNkZWZpbmUgR1RGX3Ry
YW5zaXRpdmUgICAgICAoM1U8PDApCiAjZGVmaW5lIEdURl90eXBlX21hc2sgICAgICAgKDNV
PDwwKQogCiAvKgpAQCAtMTE5LDYgKzEzMiw5IEBAIHN0cnVjdCBncmFudF9lbnRyeSB7CiAg
KiAgR1RGX3JlYWRvbmx5OiBSZXN0cmljdCBAZG9taWQgdG8gcmVhZC1vbmx5IG1hcHBpbmdz
IGFuZCBhY2Nlc3Nlcy4gW0dTVF0KICAqICBHVEZfcmVhZGluZzogR3JhbnQgZW50cnkgaXMg
Y3VycmVudGx5IG1hcHBlZCBmb3IgcmVhZGluZyBieSBAZG9taWQuIFtYRU5dCiAgKiAgR1RG
X3dyaXRpbmc6IEdyYW50IGVudHJ5IGlzIGN1cnJlbnRseSBtYXBwZWQgZm9yIHdyaXRpbmcg
YnkgQGRvbWlkLiBbWEVOXQorICogIEdURl9zdWJfcGFnZTogR3JhbnQgYWNjZXNzIHRvIG9u
bHkgYSBzdWJyYW5nZSBvZiB0aGUgcGFnZS4gIEBkb21pZAorICogICAgICAgICAgICAgICAg
d2lsbCBvbmx5IGJlIGFsbG93ZWQgdG8gY29weSBmcm9tIHRoZSBncmFudCwgYW5kIG5vdAor
ICogICAgICAgICAgICAgICAgbWFwIGl0LiBbR1NUXQogICovCiAjZGVmaW5lIF9HVEZfcmVh
ZG9ubHkgICAgICAgKDIpCiAjZGVmaW5lIEdURl9yZWFkb25seSAgICAgICAgKDFVPDxfR1RG
X3JlYWRvbmx5KQpAQCAtMTI2LDYgKzE0Miw4IEBAIHN0cnVjdCBncmFudF9lbnRyeSB7CiAj
ZGVmaW5lIEdURl9yZWFkaW5nICAgICAgICAgKDFVPDxfR1RGX3JlYWRpbmcpCiAjZGVmaW5l
IF9HVEZfd3JpdGluZyAgICAgICAgKDQpCiAjZGVmaW5lIEdURl93cml0aW5nICAgICAgICAg
KDFVPDxfR1RGX3dyaXRpbmcpCisjZGVmaW5lIF9HVEZfc3ViX3BhZ2UgICAgICAgKDgpCisj
ZGVmaW5lIEdURl9zdWJfcGFnZSAgICAgICAgKDFVPDxfR1RGX3N1Yl9wYWdlKQogCiAvKgog
ICogU3ViZmxhZ3MgZm9yIEdURl9hY2NlcHRfdHJhbnNmZXI6CkBAIC0xNDIsMTUgKzE2MCw4
MSBAQCBzdHJ1Y3QgZ3JhbnRfZW50cnkgewogI2RlZmluZSBfR1RGX3RyYW5zZmVyX2NvbXBs
ZXRlZCAoMykKICNkZWZpbmUgR1RGX3RyYW5zZmVyX2NvbXBsZXRlZCAgKDFVPDxfR1RGX3Ry
YW5zZmVyX2NvbXBsZXRlZCkKIAorLyoKKyAqIFZlcnNpb24gMiBncmFudCB0YWJsZSBlbnRy
aWVzLiAgVGhlc2UgZnVsZmlsIHRoZSBzYW1lIHJvbGUgYXMKKyAqIHZlcnNpb24gMSBlbnRy
aWVzLCBidXQgY2FuIHJlcHJlc2VudCBtb3JlIGNvbXBsaWNhdGVkIG9wZXJhdGlvbnMuCisg
KiBBbnkgZ2l2ZW4gZG9tYWluIHdpbGwgaGF2ZSBlaXRoZXIgYSB2ZXJzaW9uIDEgb3IgYSB2
ZXJzaW9uIDIgdGFibGUsCisgKiBhbmQgZXZlcnkgZW50cnkgaW4gdGhlIHRhYmxlIHdpbGwg
YmUgdGhlIHNhbWUgdmVyc2lvbi4KKyAqCisgKiBUaGUgaW50ZXJmYWNlIGJ5IHdoaWNoIGRv
bWFpbnMgdXNlIGdyYW50IHJlZmVyZW5jZXMgZG9lcyBub3QgZGVwZW5kCisgKiBvbiB0aGUg
Z3JhbnQgdGFibGUgdmVyc2lvbiBpbiB1c2UgYnkgdGhlIG90aGVyIGRvbWFpbi4KKyAqLwog
Ci0vKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKLSAqIEdSQU5UIFRBQkxF
IFFVRVJJRVMgQU5EIFVTRVMKKy8qCisgKiBWZXJzaW9uIDEgYW5kIHZlcnNpb24gMiBncmFu
dCBlbnRyaWVzIHNoYXJlIGEgY29tbW9uIHByZWZpeC4gIFRoZQorICogZmllbGRzIG9mIHRo
ZSBwcmVmaXggYXJlIGRvY3VtZW50ZWQgYXMgcGFydCBvZiBzdHJ1Y3QKKyAqIGdyYW50X2Vu
dHJ5X3YxLgogICovCitzdHJ1Y3QgZ3JhbnRfZW50cnlfaGVhZGVyIHsKKyAgICB1aW50MTZf
dCBmbGFnczsKKyAgICBkb21pZF90ICBkb21pZDsKK307CiAKIC8qCi0gKiBSZWZlcmVuY2Ug
dG8gYSBncmFudCBlbnRyeSBpbiBhIHNwZWNpZmllZCBkb21haW4ncyBncmFudCB0YWJsZS4K
KyAqIFZlcnNpb24gMiBvZiB0aGUgZ3JhbnQgZW50cnkgc3RydWN0dXJlLCBoZXJlIGlzIGFu
IHVuaW9uIGJlY2F1c2UgdGhyZWUKKyAqIGRpZmZlcmVudCB0eXBlcyBhcmUgc3VwcG90dGVk
OiBmdWxsX3BhZ2UsIHN1Yl9wYWdlIGFuZCB0cmFuc2l0aXZlLgorICovCit1bmlvbiBncmFu
dF9lbnRyeV92MiB7CisgICAgc3RydWN0IGdyYW50X2VudHJ5X2hlYWRlciBoZHI7CisKKyAg
ICAvKgorICAgICAqIFRoaXMgbWVtYmVyIGlzIHVzZWQgZm9yIFYxLXN0eWxlIGZ1bGwgcGFn
ZSBncmFudHMsIHdoZXJlIGVpdGhlcjoKKyAgICAgKgorICAgICAqIC0tIGhkci50eXBlIGlz
IEdURl9hY2NlcHRfdHJhbnNmZXIsIG9yCisgICAgICogLS0gaGRyLnR5cGUgaXMgR1RGX3Bl
cm1pdF9hY2Nlc3MgYW5kIEdURl9zdWJfcGFnZSBpcyBub3Qgc2V0LgorICAgICAqCisgICAg
ICogSW4gdGhhdCBjYXNlLCB0aGUgZnJhbWUgZmllbGQgaGFzIHRoZSBzYW1lIHNlbWFudGlj
cyBhcyB0aGUKKyAgICAgKiBmaWVsZCBvZiB0aGUgc2FtZSBuYW1lIGluIHRoZSBWMSBlbnRy
eSBzdHJ1Y3R1cmUuCisgICAgICovCisgICAgc3RydWN0IHsKKwlzdHJ1Y3QgZ3JhbnRfZW50
cnlfaGVhZGVyIGhkcjsKKwl1aW50MzJfdCBwYWQwOworCXVpbnQ2NF90IGZyYW1lOworICAg
IH0gZnVsbF9wYWdlOworCisgICAgLyoKKyAgICAgKiBJZiB0aGUgZ3JhbnQgdHlwZSBpcyBH
VEZfZ3JhbnRfYWNjZXNzIGFuZCBHVEZfc3ViX3BhZ2UgaXMgc2V0LAorICAgICAqIEBkb21p
ZCBpcyBhbGxvd2VkIHRvIGFjY2VzcyBieXRlcyBbQHBhZ2Vfb2ZmLEBwYWdlX29mZitAbGVu
Z3RoKQorICAgICAqIGluIGZyYW1lIEBmcmFtZS4KKyAgICAgKi8KKyAgICBzdHJ1Y3Qgewor
CXN0cnVjdCBncmFudF9lbnRyeV9oZWFkZXIgaGRyOworCXVpbnQxNl90IHBhZ2Vfb2ZmOwor
CXVpbnQxNl90IGxlbmd0aDsKKwl1aW50NjRfdCBmcmFtZTsKKyAgICB9IHN1Yl9wYWdlOwor
CisgICAgLyoKKyAgICAgKiBJZiB0aGUgZ3JhbnQgaXMgR1RGX3RyYW5zaXRpdmUsIEBkb21p
ZCBpcyBhbGxvd2VkIHRvIHVzZSB0aGUKKyAgICAgKiBncmFudCBAZ3JlZiBpbiBkb21haW4g
QHRyYW5zX2RvbWlkLCBhcyBpZiBpdCB3YXMgdGhlIGxvY2FsCisgICAgICogZG9tYWluLiAg
T2J2aW91c2x5LCB0aGUgdHJhbnNpdGl2ZSBhY2Nlc3MgbXVzdCBiZSBjb21wYXRpYmxlCisg
ICAgICogd2l0aCB0aGUgb3JpZ2luYWwgZ3JhbnQuCisgICAgICovCisgICAgc3RydWN0IHsK
KwlzdHJ1Y3QgZ3JhbnRfZW50cnlfaGVhZGVyIGhkcjsKKwlkb21pZF90IHRyYW5zX2RvbWlk
OworCXVpbnQxNl90IHBhZDA7CisJZ3JhbnRfcmVmX3QgZ3JlZjsKKyAgICB9IHRyYW5zaXRp
dmU7CisKKyAgICB1aW50MzJfdCBfX3NwYWNlcls0XTsgLyogUGFkIHRvIGEgcG93ZXIgb2Yg
dHdvICovCit9OworCit0eXBlZGVmIHVpbnQxNl90IGdyYW50X3N0YXR1c190OworCisvKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKyAqIEdSQU5UIFRBQkxFIFFVRVJJ
RVMgQU5EIFVTRVMKICAqLwotdHlwZWRlZiB1aW50MzJfdCBncmFudF9yZWZfdDsKIAogLyoK
ICAqIEhhbmRsZSB0byB0cmFjayBhIG1hcHBpbmcgY3JlYXRlZCB2aWEgYSBncmFudCByZWZl
cmVuY2UuCkBAIC0zMjIsNiArNDA2LDc5IEBAIHN0cnVjdCBnbnR0YWJfcXVlcnlfc2l6ZSB7
CiBERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVChnbnR0YWJfcXVlcnlfc2l6ZSk7CiAKIC8q
CisgKiBHTlRUQUJPUF91bm1hcF9hbmRfcmVwbGFjZTogRGVzdHJveSBvbmUgb3IgbW9yZSBn
cmFudC1yZWZlcmVuY2UgbWFwcGluZ3MKKyAqIHRyYWNrZWQgYnkgPGhhbmRsZT4gYnV0IGF0
b21pY2FsbHkgcmVwbGFjZSB0aGUgcGFnZSB0YWJsZSBlbnRyeSB3aXRoIG9uZQorICogcG9p
bnRpbmcgdG8gdGhlIG1hY2hpbmUgYWRkcmVzcyB1bmRlciA8bmV3X2FkZHI+LiAgPG5ld19h
ZGRyPiB3aWxsIGJlCisgKiByZWRpcmVjdGVkIHRvIHRoZSBudWxsIGVudHJ5LgorICogTk9U
RVM6CisgKiAgMS4gVGhlIGNhbGwgbWF5IGZhaWwgaW4gYW4gdW5kZWZpbmVkIG1hbm5lciBp
ZiBlaXRoZXIgbWFwcGluZyBpcyBub3QKKyAqICAgICB0cmFja2VkIGJ5IDxoYW5kbGU+Lgor
ICogIDIuIEFmdGVyIGV4ZWN1dGluZyBhIGJhdGNoIG9mIHVubWFwcywgaXQgaXMgZ3VhcmFu
dGVlZCB0aGF0IG5vIHN0YWxlCisgKiAgICAgbWFwcGluZ3Mgd2lsbCByZW1haW4gaW4gdGhl
IGRldmljZSBvciBob3N0IFRMQnMuCisgKi8KKyNkZWZpbmUgR05UVEFCT1BfdW5tYXBfYW5k
X3JlcGxhY2UgICAgNworc3RydWN0IGdudHRhYl91bm1hcF9hbmRfcmVwbGFjZSB7CisgICAg
LyogSU4gcGFyYW1ldGVycy4gKi8KKyAgICB1aW50NjRfdCBob3N0X2FkZHI7CisgICAgdWlu
dDY0X3QgbmV3X2FkZHI7CisgICAgZ3JhbnRfaGFuZGxlX3QgaGFuZGxlOworICAgIC8qIE9V
VCBwYXJhbWV0ZXJzLiAqLworICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAgICAgIC8q
IEdOVFNUXyogKi8KK307CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVChnbnR0YWJfdW5t
YXBfYW5kX3JlcGxhY2UpOworCisvKgorICogR05UVEFCT1Bfc2V0X3ZlcnNpb246IFJlcXVl
c3QgYSBwYXJ0aWN1bGFyIHZlcnNpb24gb2YgdGhlIGdyYW50CisgKiB0YWJsZSBzaGFyZWQg
dGFibGUgc3RydWN0dXJlLiAgVGhpcyBvcGVyYXRpb24gY2FuIG9ubHkgYmUgcGVyZm9ybWVk
CisgKiBvbmNlIGluIGFueSBnaXZlbiBkb21haW4uICBJdCBtdXN0IGJlIHBlcmZvcm1lZCBi
ZWZvcmUgYW55IGdyYW50cworICogYXJlIGFjdGl2YXRlZDsgb3RoZXJ3aXNlLCB0aGUgZG9t
YWluIHdpbGwgYmUgc3R1Y2sgd2l0aCB2ZXJzaW9uIDEuCisgKiBUaGUgb25seSBkZWZpbmVk
IHZlcnNpb25zIGFyZSAxIGFuZCAyLgorICovCisjZGVmaW5lIEdOVFRBQk9QX3NldF92ZXJz
aW9uICAgICAgICAgIDgKK3N0cnVjdCBnbnR0YWJfc2V0X3ZlcnNpb24geworICAgIC8qIElO
IHBhcmFtZXRlcnMgKi8KKyAgICB1aW50MzJfdCB2ZXJzaW9uOworfTsKK0RFRklORV9HVUVT
VF9IQU5ETEVfU1RSVUNUKGdudHRhYl9zZXRfdmVyc2lvbik7CisKKy8qCisgKiBHTlRUQUJP
UF9nZXRfc3RhdHVzX2ZyYW1lczogR2V0IHRoZSBsaXN0IG9mIGZyYW1lcyB1c2VkIHRvIHN0
b3JlIGdyYW50CisgKiBzdGF0dXMgZm9yIDxkb20+LiBJbiBncmFudCBmb3JtYXQgdmVyc2lv
biAyLCB0aGUgc3RhdHVzIGlzIHNlcGFyYXRlZAorICogZnJvbSB0aGUgb3RoZXIgc2hhcmVk
IGdyYW50IGZpZWxkcyB0byBhbGxvdyBtb3JlIGVmZmljaWVudCBzeW5jaHJvbml6YXRpb24K
KyAqIHVzaW5nIGJhcnJpZXJzIGluc3RlYWQgb2YgYXRvbWljIGNtcGV4Y2ggb3BlcmF0aW9u
cy4KKyAqIDxucl9mcmFtZXM+IHNwZWNpZnkgdGhlIHNpemUgb2YgdmVjdG9yIDxmcmFtZV9s
aXN0Pi4KKyAqIFRoZSBmcmFtZSBhZGRyZXNzZXMgYXJlIHJldHVybmVkIGluIHRoZSA8ZnJh
bWVfbGlzdD4uCisgKiBPbmx5IDxucl9mcmFtZXM+IGFkZHJlc3NlcyBhcmUgcmV0dXJuZWQs
IGV2ZW4gaWYgdGhlIHRhYmxlIGlzIGxhcmdlci4KKyAqIE5PVEVTOgorICogIDEuIDxkb20+
IG1heSBiZSBzcGVjaWZpZWQgYXMgRE9NSURfU0VMRi4KKyAqICAyLiBPbmx5IGEgc3VmZmlj
aWVudGx5LXByaXZpbGVnZWQgZG9tYWluIG1heSBzcGVjaWZ5IDxkb20+ICE9IERPTUlEX1NF
TEYuCisgKi8KKyNkZWZpbmUgR05UVEFCT1BfZ2V0X3N0YXR1c19mcmFtZXMgICAgIDkKK3N0
cnVjdCBnbnR0YWJfZ2V0X3N0YXR1c19mcmFtZXMgeworICAgIC8qIElOIHBhcmFtZXRlcnMu
ICovCisgICAgdWludDMyX3QgbnJfZnJhbWVzOworICAgIGRvbWlkX3QgIGRvbTsKKyAgICAv
KiBPVVQgcGFyYW1ldGVycy4gKi8KKyAgICBpbnQxNl90ICBzdGF0dXM7ICAgICAgICAgICAg
ICAvKiBHTlRTVF8qICovCisgICAgR1VFU1RfSEFORExFKHVpbnQ2NF90KSBmcmFtZV9saXN0
OworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKGdudHRhYl9nZXRfc3RhdHVzX2Zy
YW1lcyk7CisKKy8qCisgKiBHTlRUQUJPUF9nZXRfdmVyc2lvbjogR2V0IHRoZSBncmFudCB0
YWJsZSB2ZXJzaW9uIHdoaWNoIGlzIGluCisgKiBlZmZlY3QgZm9yIGRvbWFpbiA8ZG9tPi4K
KyAqLworI2RlZmluZSBHTlRUQUJPUF9nZXRfdmVyc2lvbiAgICAgICAgICAxMAorc3RydWN0
IGdudHRhYl9nZXRfdmVyc2lvbiB7CisgICAgLyogSU4gcGFyYW1ldGVycyAqLworICAgIGRv
bWlkX3QgZG9tOworICAgIHVpbnQxNl90IHBhZDsKKyAgICAvKiBPVVQgcGFyYW1ldGVycyAq
LworICAgIHVpbnQzMl90IHZlcnNpb247Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJV
Q1QoZ250dGFiX2dldF92ZXJzaW9uKTsKKworLyoKICAqIEJpdGZpZWxkIHZhbHVlcyBmb3Ig
dXBkYXRlX3Bpbl9zdGF0dXMuZmxhZ3MuCiAgKi8KICAvKiBNYXAgdGhlIGdyYW50IGVudHJ5
IGZvciBhY2Nlc3MgYnkgSS9PIGRldmljZXMuICovCmRpZmYgLS1naXQgYS9pbmNsdWRlL3hl
bi9pbnRlcmZhY2UveGVuLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLmgKaW5kZXgg
NmE2ZTkxNC4uYTg5MDgwNCAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hl
bi5oCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaApAQCAtNTIzLDYgKzUyMyw4
IEBAIHN0cnVjdCB0bWVtX29wIHsKIAl9IHU7CiB9OwogCitERUZJTkVfR1VFU1RfSEFORExF
KHU2NCk7CisKICNlbHNlIC8qIF9fQVNTRU1CTFlfXyAqLwogCiAvKiBJbiBhc3NlbWJseSBj
b2RlIHdlIGNhbm5vdCB1c2UgQyBudW1lcmljIGNvbnN0YW50IHN1ZmZpeGVzLiAqLwotLSAK
MS43LjYuNAoK
--------------050700040602000504040002
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------050700040602000504040002--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 09:51:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 09:51:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQXE-0003Af-OI; Mon, 21 Nov 2011 09:51:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSQXC-00038w-U9
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 09:51:31 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1321869061!3947385!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29248 invoked from network); 21 Nov 2011 09:51:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 09:51:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAL9ov9C004065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 21 Nov 2011 09:50:58 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAL9osVK007648
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 21 Nov 2011 09:50:55 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAL9oltb024374; Mon, 21 Nov 2011 03:50:47 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 01:50:46 -0800
Message-ID: <4ECA1F0D.5070303@oracle.com>
Date: Mon, 21 Nov 2011 17:51:09 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EC3B62F.6080702@oracle.com>	
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>	
	<4EC62E77.7090007@oracle.com>	
	<1321613689.3664.305.camel@zakaz.uk.xensource.com>	
	<4EC6818B.3010904@oracle.com>
	<1321632271.3664.367.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321632271.3664.367.camel@zakaz.uk.xensource.com>
Content-Type: multipart/mixed; boundary="------------050700040602000504040002"
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4ECA1F03.005D,ss=1,re=-2.300,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
 V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------050700040602000504040002
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

This patch changes two places from the last one,
* removing gnttab_v1_ops
* change update_grant_entry_v1 into gnttab_update_entry_v1

Thanks
Annie

On 2011-11-19 0:04, Ian Campbell wrote:
>>>> +static struct gnttab_ops gnttab_v1_ops = {
>>>> +       .map_frames                     = gnttab_map_frames_v1,
>>>> +       .unmap_frames                   = gnttab_unmap_frames_v1,
>>>> +       .update_entry                   = update_grant_entry_v1,
>>>>
>>> Any reason this one is not gnttab_foo?
>>>
>> Actually no, just keep the original name of this function. I'd like to
>> change it, maybe gnttab_update_entry_v1 is better?
> I think so. Similarly for the v2 variant.
>
> Ian.
>
>

--------------050700040602000504040002
Content-Type: text/plain;
 name="0001-xen-granttable-Introducing-grant-table-V2-stucture.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0="0001-xen-granttable-Introducing-grant-table-V2-stucture.patc";
 filename*1="h"

RnJvbSBjMTBlYjg5NWFiYjU3OWU1MDc1OWJhZmNiZmQ1NGFlODAyMDZiYWIwIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4K
RGF0ZTogRnJpLCAxOCBOb3YgMjAxMSAxNjowNzoxNiArMDgwMApTdWJqZWN0OiBbUEFUQ0gg
MS80XSB4ZW4vZ3JhbnR0YWJsZTogSW50cm9kdWNpbmcgZ3JhbnQgdGFibGUgVjIgc3R1Y3R1
cmUKClRoaXMgcGF0Y2ggaW50cm9kdWNlcyBuZXcgc3RydWN0dXJlcyBvZiBncmFudCB0YWJs
ZSBWMiwgZ3JhbnQgdGFibGUgVjIgaXMgYW4KZXh0ZW5zaW9uIGZyb20gVjEuIEdyYW50IHRh
YmxlIGlzIHNoYXJlZCBiZXR3ZWVuIGd1ZXN0IGFuZCBYZW4sIGFuZCBYZW4gaXMKcmVzcG9u
c2libGUgdG8gZG8gY29ycmVzcG9uZGluZyB3b3JrIGZvciBncmFudCBvcGVyYXRpb25zLCBz
dWNoIGFzOiBmaWd1cmUKb3V0IGd1ZXN0J3MgZ3JhbnQgdGFibGUgdmVyc2lvbiwgcGVyZm9y
bSBkaWZmZXJlbnQgYWN0aW9ucyBiYXNlZCBvbgpkaWZmZXJlbnQgZ3JhbnQgdGFibGUgdmVy
c2lvbiwgZXRjLiBBbHRob3VnaCBmdWxsLXBhZ2Ugc3RydWN0dXJlIG9mIFYyCmlzIGRpZmZl
cmVudCBmcm9tIFYxLCBpdCBwbGF5IHRoZSBzYW1lIHJvbGUgYXMgVjEuCgpTaWduZWQtb2Zm
LWJ5OiBBbm5pZSBMaSA8YW5uaWUubGlAb3JhY2xlLmNvbT4KLS0tCiBhcmNoL3g4Ni94ZW4v
Z3JhbnQtdGFibGUuYyAgICAgICAgICB8ICAgIDcgKy0KIGRyaXZlcnMveGVuL2dyYW50LXRh
YmxlLmMgICAgICAgICAgIHwgIDE4MiArKysrKysrKysrKysrKysrKysrKysrKysrKystLS0t
LS0tLQogaW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUuaCAgICAgICAgICAgfCAgICA0ICstCiBp
bmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaCB8ICAxNjcgKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKy0KIGluY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaCAgICAg
ICAgIHwgICAgMiArCiA1IGZpbGVzIGNoYW5nZWQsIDMxMSBpbnNlcnRpb25zKCspLCA1MSBk
ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94ZW4vZ3JhbnQtdGFibGUuYyBi
L2FyY2gveDg2L3hlbi9ncmFudC10YWJsZS5jCmluZGV4IDZiYmZkN2EuLmM2YWIyZTcgMTAw
NjQ0Ci0tLSBhL2FyY2gveDg2L3hlbi9ncmFudC10YWJsZS5jCisrKyBiL2FyY2gveDg2L3hl
bi9ncmFudC10YWJsZS5jCkBAIC02NCwxMCArNjQsMTAgQEAgc3RhdGljIGludCB1bm1hcF9w
dGVfZm4ocHRlX3QgKnB0ZSwgc3RydWN0IHBhZ2UgKnBtZF9wYWdlLAogCiBpbnQgYXJjaF9n
bnR0YWJfbWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGxvbmcg
bnJfZ2ZyYW1lcywKIAkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFtZXMsCi0JCQkg
ICBzdHJ1Y3QgZ3JhbnRfZW50cnkgKipfX3NoYXJlZCkKKwkJCSAgIHZvaWQgKipfX3NoYXJl
ZCkKIHsKIAlpbnQgcmM7Ci0Jc3RydWN0IGdyYW50X2VudHJ5ICpzaGFyZWQgPSAqX19zaGFy
ZWQ7CisJdm9pZCAqc2hhcmVkID0gKl9fc2hhcmVkOwogCiAJaWYgKHNoYXJlZCA9PSBOVUxM
KSB7CiAJCXN0cnVjdCB2bV9zdHJ1Y3QgKmFyZWEgPQpAQCAtODMsOCArODMsNyBAQCBpbnQg
YXJjaF9nbnR0YWJfbWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVk
IGxvbmcgbnJfZ2ZyYW1lcywKIAlyZXR1cm4gcmM7CiB9CiAKLXZvaWQgYXJjaF9nbnR0YWJf
dW5tYXBfc2hhcmVkKHN0cnVjdCBncmFudF9lbnRyeSAqc2hhcmVkLAotCQkJICAgICAgdW5z
aWduZWQgbG9uZyBucl9nZnJhbWVzKQordm9pZCBhcmNoX2dudHRhYl91bm1hcF9zaGFyZWQo
dm9pZCAqc2hhcmVkLCB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpCiB7CiAJYXBwbHlfdG9f
cGFnZV9yYW5nZSgmaW5pdF9tbSwgKHVuc2lnbmVkIGxvbmcpc2hhcmVkLAogCQkJICAgIFBB
R0VfU0laRSAqIG5yX2dmcmFtZXMsIHVubWFwX3B0ZV9mbiwgTlVMTCk7CmRpZmYgLS1naXQg
YS9kcml2ZXJzL3hlbi9ncmFudC10YWJsZS5jIGIvZHJpdmVycy94ZW4vZ3JhbnQtdGFibGUu
YwppbmRleCBiZjFjMDk0Li41ZDkzMWI4IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9ncmFu
dC10YWJsZS5jCisrKyBiL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMKQEAgLTUzLDcgKzUz
LDcgQEAKIC8qIEV4dGVybmFsIHRvb2xzIHJlc2VydmUgZmlyc3QgZmV3IGdyYW50IHRhYmxl
IGVudHJpZXMuICovCiAjZGVmaW5lIE5SX1JFU0VSVkVEX0VOVFJJRVMgOAogI2RlZmluZSBH
TlRUQUJfTElTVF9FTkQgMHhmZmZmZmZmZgotI2RlZmluZSBHUkVGU19QRVJfR1JBTlRfRlJB
TUUgKFBBR0VfU0laRSAvIHNpemVvZihzdHJ1Y3QgZ3JhbnRfZW50cnkpKQorI2RlZmluZSBH
UkVGU19QRVJfR1JBTlRfRlJBTUUgKFBBR0VfU0laRSAvIHNpemVvZihzdHJ1Y3QgZ3JhbnRf
ZW50cnlfdjEpKQogCiBzdGF0aWMgZ3JhbnRfcmVmX3QgKipnbnR0YWJfbGlzdDsKIHN0YXRp
YyB1bnNpZ25lZCBpbnQgbnJfZ3JhbnRfZnJhbWVzOwpAQCAtNjQsNyArNjQsNjQgQEAgc3Rh
dGljIERFRklORV9TUElOTE9DSyhnbnR0YWJfbGlzdF9sb2NrKTsKIHVuc2lnbmVkIGxvbmcg
eGVuX2h2bV9yZXN1bWVfZnJhbWVzOwogRVhQT1JUX1NZTUJPTF9HUEwoeGVuX2h2bV9yZXN1
bWVfZnJhbWVzKTsKIAotc3RhdGljIHN0cnVjdCBncmFudF9lbnRyeSAqc2hhcmVkOworc3Rh
dGljIHVuaW9uIHsKKwlzdHJ1Y3QgZ3JhbnRfZW50cnlfdjEgKnYxOworCXZvaWQgKmFkZHI7
Cit9IGdudHRhYl9zaGFyZWQ7CisKKy8qVGhpcyBpcyBhIHN0cnVjdHVyZSBvZiBmdW5jdGlv
biBwb2ludGVycyBmb3IgZ3JhbnQgdGFibGUqLworc3RydWN0IGdudHRhYl9vcHMgeworCS8q
CisJICogTWFwcGluZyBhIGxpc3Qgb2YgZnJhbWVzIGZvciBzdG9yaW5nIGdyYW50IGVudHJp
ZXMuIEZpcnN0IGlucHV0CisJICogcGFyYW1ldGVyIGlzIHVzZWQgdG8gc3RvcmluZyBncmFu
dCB0YWJsZSBhZGRyZXNzIHdoZW4gZ3JhbnQgdGFibGUKKwkgKiBiZWluZyBzZXR1cCwgc2Vj
b25kIHBhcmFtZXRlciBpcyB0aGUgbnVtYmVyIG9mIGZyYW1lcyB0byBtYXAgZ3JhbnQKKwkg
KiB0YWJsZS4gUmV0dXJuaW5nIEdOVFNUX29rYXkgbWVhbnMgc3VjY2VzcyBhbmQgbmVnYXRp
dmUgdmFsdWUgbWVhbnMKKwkgKiBmYWlsdXJlLgorCSAqLworCWludCAoKm1hcF9mcmFtZXMp
KHVuc2lnbmVkIGxvbmcgKiwgdW5zaWduZWQgaW50KTsKKwkvKgorCSAqIFJlbGVhc2UgYSBs
aXN0IG9mIGZyYW1lcyB3aGljaCBhcmUgbWFwcGVkIGluIG1hcF9mcmFtZXMgZm9yIGdyYW50
CisJICogZW50cnkgc3RhdHVzLgorCSAqLworCXZvaWQgKCp1bm1hcF9mcmFtZXMpKHZvaWQp
OworCS8qCisJICogSW50cm9kdWNpbmcgYSB2YWxpZCBlbnRyeSBpbnRvIHRoZSBncmFudCB0
YWJsZSwgZ3JhbnRpbmcgdGhlIGZyYW1lCisJICogb2YgdGhpcyBncmFudCBlbnRyeSB0byBk
b21haW4gZm9yIGFjY2Vzc2luZywgb3IgdHJhbnNmZXJpbmcsIG9yCisJICogdHJhbnNpdGl2
ZWx5IGFjY2Vzc2luZy4gRmlyc3QgaW5wdXQgcGFyYW1ldGVyIGlzIHJlZmVyZW5jZSBvZiB0
aGlzCisJICogaW50cm9kdWNlZCBncmFudCBlbnRyeSwgc2Vjb25kIG9uZSBpcyBkb21pZCBv
ZiBncmFudGVkIGRvbWFpbiwgdGhpcmQKKwkgKiBvbmUgaXMgdGhlIGZyYW1lIHRvIGJlIGdy
YW50ZWQsIGFuZCB0aGUgbGFzdCBvbmUgaXMgc3RhdHVzIG9mIHRoZQorCSAqIGdyYW50IGVu
dHJ5IHRvIGJlIHVwZGF0ZWQuCisJICovCisJdm9pZCAoKnVwZGF0ZV9lbnRyeSkoZ3JhbnRf
cmVmX3QsIGRvbWlkX3QsIHVuc2lnbmVkIGxvbmcsIHVuc2lnbmVkKTsKKwkvKgorCSAqIFN0
b3AgZ3JhbnRpbmcgYSBncmFudCBlbnRyeSB0byBkb21haW4gZm9yIGFjY2Vzc2luZy4gRmly
c3QgaW5wdXQKKwkgKiBwYXJhbWV0ZXIgaXMgcmVmZXJlbmNlIG9mIGEgZ3JhbnQgZW50cnkg
d2hvc2UgZ3JhbnQgYWNjZXNzIHdpbGwgYmUKKwkgKiBzdG9wcGVkLCBzZWNvbmQgb25lIGlz
IG5vdCBpbiB1c2Ugbm93LiBJZiB0aGUgZ3JhbnQgZW50cnkgaXMKKwkgKiBjdXJyZW50bHkg
bWFwcGVkIGZvciByZWFkaW5nIG9yIHdyaXRpbmcsIGp1c3QgcmV0dXJuIGZhaWx1cmUoPT0w
KQorCSAqIGRpcmVjdGx5IGFuZCBkb24ndCB0ZWFyIGRvd24gdGhlIGdyYW50IGFjY2Vzcy4g
T3RoZXJ3aXNlLCBzdG9wIGdyYW50CisJICogYWNjZXNzIGZvciB0aGlzIGVudHJ5IGFuZCBy
ZXR1cm4gc3VjY2Vzcyg9PTEpLgorCSAqLworCWludCAoKmVuZF9mb3JlaWduX2FjY2Vzc19y
ZWYpKGdyYW50X3JlZl90LCBpbnQpOworCS8qCisJICogU3RvcCBncmFudGluZyBhIGdyYW50
IGVudHJ5IHRvIGRvbWFpbiBmb3IgdHJhbnNmZXIuIElmIHRyYW5mZXIgaGFzCisJICogbm90
IHN0YXJ0ZWQsIGp1c3QgcmVjbGFpbSB0aGUgZ3JhbnQgZW50cnkgYW5kIHJldHVybiBmYWls
dXJlKD09MCkuCisJICogT3RoZXJ3aXNlLCB3YWl0IGZvciB0aGUgdHJhbnNmZXIgdG8gY29t
cGxldGUgYW5kIHRoZW4gcmV0dXJuIHRoZQorCSAqIGZyYW1lLgorCSAqLworCXVuc2lnbmVk
IGxvbmcgKCplbmRfZm9yZWlnbl90cmFuc2Zlcl9yZWYpKGdyYW50X3JlZl90KTsKKwkvKgor
CSAqIFF1ZXJ5IHRoZSBzdGF0dXMgb2YgYSBncmFudCBlbnRyeS4gSW5wdXQgcGFyYW1ldGVy
IGlzIHJlZmVyZW5jZSBvZgorCSAqIHF1ZXJpZWQgZ3JhbnQgZW50cnksIHJldHVybiB2YWx1
ZSBpcyB0aGUgc3RhdHVzIG9mIHF1ZXJpZWQgZW50cnkuCisJICogRGV0YWlsZWQgc3RhdHVz
KHdyaXRpbmcvcmVhZGluZykgY2FuIGJlIGdvdHRlbiBmcm9tIHRoZSByZXR1cm4gdmFsdWUK
KwkgKiBieSBiaXQgb3BlcmF0aW9ucy4KKwkgKi8KKwlpbnQgKCpxdWVyeV9mb3JlaWduX2Fj
Y2VzcykoZ3JhbnRfcmVmX3QpOworfTsKKworc3RhdGljIHN0cnVjdCBnbnR0YWJfb3BzIGdu
dHRhYl92MV9vcHM7CitzdGF0aWMgc3RydWN0IGdudHRhYl9vcHMgKmdudHRhYl9pbnRlcmZh
Y2U7CisKK3N0YXRpYyBpbnQgZ3JhbnRfdGFibGVfdmVyc2lvbjsKIAogc3RhdGljIHN0cnVj
dCBnbnR0YWJfZnJlZV9jYWxsYmFjayAqZ250dGFiX2ZyZWVfY2FsbGJhY2tfbGlzdDsKIApA
QCAtMTQyLDIzICsxOTksMjMgQEAgc3RhdGljIHZvaWQgcHV0X2ZyZWVfZW50cnkoZ3JhbnRf
cmVmX3QgcmVmKQogCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmdudHRhYl9saXN0X2xvY2ss
IGZsYWdzKTsKIH0KIAotc3RhdGljIHZvaWQgdXBkYXRlX2dyYW50X2VudHJ5KGdyYW50X3Jl
Zl90IHJlZiwgZG9taWRfdCBkb21pZCwKLQkJCSAgICAgICB1bnNpZ25lZCBsb25nIGZyYW1l
LCB1bnNpZ25lZCBmbGFncykKKy8qCisgKiBJbnRyb2R1Y2luZyBhIHZhbGlkIGVudHJ5IGlu
dG8gdGhlIGdyYW50IHRhYmxlOgorICogIDEuIFdyaXRlIGVudC0+ZG9taWQuCisgKiAgMi4g
V3JpdGUgZW50LT5mcmFtZToKKyAqICAgICAgR1RGX3Blcm1pdF9hY2Nlc3M6ICAgRnJhbWUg
dG8gd2hpY2ggYWNjZXNzIGlzIHBlcm1pdHRlZC4KKyAqICAgICAgR1RGX2FjY2VwdF90cmFu
c2ZlcjogUHNldWRvLXBoeXMgZnJhbWUgc2xvdCBiZWluZyBmaWxsZWQgYnkgbmV3CisgKiAg
ICAgICAgICAgICAgICAgICAgICAgICAgIGZyYW1lLCBvciB6ZXJvIGlmIG5vbmUuCisgKiAg
My4gV3JpdGUgbWVtb3J5IGJhcnJpZXIgKFdNQikuCisgKiAgNC4gV3JpdGUgZW50LT5mbGFn
cywgaW5jLiB2YWxpZCB0eXBlLgorICovCitzdGF0aWMgdm9pZCB1cGRhdGVfZ3JhbnRfZW50
cnlfdjEoZ3JhbnRfcmVmX3QgcmVmLCBkb21pZF90IGRvbWlkLAorCQkJCSAgdW5zaWduZWQg
bG9uZyBmcmFtZSwgdW5zaWduZWQgZmxhZ3MpCiB7Ci0JLyoKLQkgKiBJbnRyb2R1Y2luZyBh
IHZhbGlkIGVudHJ5IGludG8gdGhlIGdyYW50IHRhYmxlOgotCSAqICAxLiBXcml0ZSBlbnQt
PmRvbWlkLgotCSAqICAyLiBXcml0ZSBlbnQtPmZyYW1lOgotCSAqICAgICAgR1RGX3Blcm1p
dF9hY2Nlc3M6ICAgRnJhbWUgdG8gd2hpY2ggYWNjZXNzIGlzIHBlcm1pdHRlZC4KLQkgKiAg
ICAgIEdURl9hY2NlcHRfdHJhbnNmZXI6IFBzZXVkby1waHlzIGZyYW1lIHNsb3QgYmVpbmcg
ZmlsbGVkIGJ5IG5ldwotCSAqICAgICAgICAgICAgICAgICAgICAgICAgICAgZnJhbWUsIG9y
IHplcm8gaWYgbm9uZS4KLQkgKiAgMy4gV3JpdGUgbWVtb3J5IGJhcnJpZXIgKFdNQikuCi0J
ICogIDQuIFdyaXRlIGVudC0+ZmxhZ3MsIGluYy4gdmFsaWQgdHlwZS4KLQkgKi8KLQlzaGFy
ZWRbcmVmXS5mcmFtZSA9IGZyYW1lOwotCXNoYXJlZFtyZWZdLmRvbWlkID0gZG9taWQ7CisJ
Z250dGFiX3NoYXJlZC52MVtyZWZdLmRvbWlkID0gZG9taWQ7CisJZ250dGFiX3NoYXJlZC52
MVtyZWZdLmZyYW1lID0gZnJhbWU7CiAJd21iKCk7Ci0Jc2hhcmVkW3JlZl0uZmxhZ3MgPSBm
bGFnczsKKwlnbnR0YWJfc2hhcmVkLnYxW3JlZl0uZmxhZ3MgPSBmbGFnczsKIH0KIAogLyoK
QEAgLTE2Nyw3ICsyMjQsNyBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfZ3JhbnRfZW50cnkoZ3Jh
bnRfcmVmX3QgcmVmLCBkb21pZF90IGRvbWlkLAogdm9pZCBnbnR0YWJfZ3JhbnRfZm9yZWln
bl9hY2Nlc3NfcmVmKGdyYW50X3JlZl90IHJlZiwgZG9taWRfdCBkb21pZCwKIAkJCQkgICAg
IHVuc2lnbmVkIGxvbmcgZnJhbWUsIGludCByZWFkb25seSkKIHsKLQl1cGRhdGVfZ3JhbnRf
ZW50cnkocmVmLCBkb21pZCwgZnJhbWUsCisJZ250dGFiX2ludGVyZmFjZS0+dXBkYXRlX2Vu
dHJ5KHJlZiwgZG9taWQsIGZyYW1lLAogCQkJICAgR1RGX3Blcm1pdF9hY2Nlc3MgfCAocmVh
ZG9ubHkgPyBHVEZfcmVhZG9ubHkgOiAwKSk7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0
YWJfZ3JhbnRfZm9yZWlnbl9hY2Nlc3NfcmVmKTsKQEAgLTE4NywzMSArMjQ0LDM3IEBAIGlu
dCBnbnR0YWJfZ3JhbnRfZm9yZWlnbl9hY2Nlc3MoZG9taWRfdCBkb21pZCwgdW5zaWduZWQg
bG9uZyBmcmFtZSwKIH0KIEVYUE9SVF9TWU1CT0xfR1BMKGdudHRhYl9ncmFudF9mb3JlaWdu
X2FjY2Vzcyk7CiAKLWludCBnbnR0YWJfcXVlcnlfZm9yZWlnbl9hY2Nlc3MoZ3JhbnRfcmVm
X3QgcmVmKQorc3RhdGljIGludCBnbnR0YWJfcXVlcnlfZm9yZWlnbl9hY2Nlc3NfdjEoZ3Jh
bnRfcmVmX3QgcmVmKQogewotCXUxNiBuZmxhZ3M7Ci0KLQluZmxhZ3MgPSBzaGFyZWRbcmVm
XS5mbGFnczsKKwlyZXR1cm4gZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzICYgKEdURl9y
ZWFkaW5nfEdURl93cml0aW5nKTsKK30KIAotCXJldHVybiBuZmxhZ3MgJiAoR1RGX3JlYWRp
bmd8R1RGX3dyaXRpbmcpOworaW50IGdudHRhYl9xdWVyeV9mb3JlaWduX2FjY2VzcyhncmFu
dF9yZWZfdCByZWYpCit7CisJcmV0dXJuIGdudHRhYl9pbnRlcmZhY2UtPnF1ZXJ5X2ZvcmVp
Z25fYWNjZXNzKHJlZik7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfcXVlcnlfZm9y
ZWlnbl9hY2Nlc3MpOwogCi1pbnQgZ250dGFiX2VuZF9mb3JlaWduX2FjY2Vzc19yZWYoZ3Jh
bnRfcmVmX3QgcmVmLCBpbnQgcmVhZG9ubHkpCitzdGF0aWMgaW50IGdudHRhYl9lbmRfZm9y
ZWlnbl9hY2Nlc3NfcmVmX3YxKGdyYW50X3JlZl90IHJlZiwgaW50IHJlYWRvbmx5KQogewog
CXUxNiBmbGFncywgbmZsYWdzOwogCi0JbmZsYWdzID0gc2hhcmVkW3JlZl0uZmxhZ3M7CisJ
bmZsYWdzID0gZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzOwogCWRvIHsKIAkJZmxhZ3Mg
PSBuZmxhZ3M7CiAJCWlmIChmbGFncyAmIChHVEZfcmVhZGluZ3xHVEZfd3JpdGluZykpIHsK
IAkJCXByaW50ayhLRVJOX0FMRVJUICJXQVJOSU5HOiBnLmUuIHN0aWxsIGluIHVzZSFcbiIp
OwogCQkJcmV0dXJuIDA7CiAJCX0KLQl9IHdoaWxlICgobmZsYWdzID0gc3luY19jbXB4Y2hn
KCZzaGFyZWRbcmVmXS5mbGFncywgZmxhZ3MsIDApKSAhPSBmbGFncyk7CisJfSB3aGlsZSAo
KG5mbGFncyA9IHN5bmNfY21weGNoZygmZ250dGFiX3NoYXJlZC52MVtyZWZdLmZsYWdzLCBm
bGFncywgMCkpICE9IGZsYWdzKTsKIAogCXJldHVybiAxOwogfQorCitpbnQgZ250dGFiX2Vu
ZF9mb3JlaWduX2FjY2Vzc19yZWYoZ3JhbnRfcmVmX3QgcmVmLCBpbnQgcmVhZG9ubHkpCit7
CisJcmV0dXJuIGdudHRhYl9pbnRlcmZhY2UtPmVuZF9mb3JlaWduX2FjY2Vzc19yZWYocmVm
LCByZWFkb25seSk7Cit9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfZW5kX2ZvcmVpZ25f
YWNjZXNzX3JlZik7CiAKIHZvaWQgZ250dGFiX2VuZF9mb3JlaWduX2FjY2VzcyhncmFudF9y
ZWZfdCByZWYsIGludCByZWFkb25seSwKQEAgLTI0NiwxMSArMzA5LDExIEBAIEVYUE9SVF9T
WU1CT0xfR1BMKGdudHRhYl9ncmFudF9mb3JlaWduX3RyYW5zZmVyKTsKIHZvaWQgZ250dGFi
X2dyYW50X2ZvcmVpZ25fdHJhbnNmZXJfcmVmKGdyYW50X3JlZl90IHJlZiwgZG9taWRfdCBk
b21pZCwKIAkJCQkgICAgICAgdW5zaWduZWQgbG9uZyBwZm4pCiB7Ci0JdXBkYXRlX2dyYW50
X2VudHJ5KHJlZiwgZG9taWQsIHBmbiwgR1RGX2FjY2VwdF90cmFuc2Zlcik7CisJZ250dGFi
X2ludGVyZmFjZS0+dXBkYXRlX2VudHJ5KHJlZiwgZG9taWQsIHBmbiwgR1RGX2FjY2VwdF90
cmFuc2Zlcik7CiB9CiBFWFBPUlRfU1lNQk9MX0dQTChnbnR0YWJfZ3JhbnRfZm9yZWlnbl90
cmFuc2Zlcl9yZWYpOwogCi11bnNpZ25lZCBsb25nIGdudHRhYl9lbmRfZm9yZWlnbl90cmFu
c2Zlcl9yZWYoZ3JhbnRfcmVmX3QgcmVmKQorc3RhdGljIHVuc2lnbmVkIGxvbmcgZ250dGFi
X2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZl92MShncmFudF9yZWZfdCByZWYpCiB7CiAJdW5z
aWduZWQgbG9uZyBmcmFtZTsKIAl1MTYgICAgICAgICAgIGZsYWdzOwpAQCAtMjU5LDI0ICsz
MjIsMjkgQEAgdW5zaWduZWQgbG9uZyBnbnR0YWJfZW5kX2ZvcmVpZ25fdHJhbnNmZXJfcmVm
KGdyYW50X3JlZl90IHJlZikKIAkgKiBJZiBhIHRyYW5zZmVyIGlzIG5vdCBldmVuIHlldCBz
dGFydGVkLCB0cnkgdG8gcmVjbGFpbSB0aGUgZ3JhbnQKIAkgKiByZWZlcmVuY2UgYW5kIHJl
dHVybiBmYWlsdXJlICg9PSAwKS4KIAkgKi8KLQl3aGlsZSAoISgoZmxhZ3MgPSBzaGFyZWRb
cmVmXS5mbGFncykgJiBHVEZfdHJhbnNmZXJfY29tbWl0dGVkKSkgewotCQlpZiAoc3luY19j
bXB4Y2hnKCZzaGFyZWRbcmVmXS5mbGFncywgZmxhZ3MsIDApID09IGZsYWdzKQorCXdoaWxl
ICghKChmbGFncyA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mbGFncykgJiBHVEZfdHJhbnNm
ZXJfY29tbWl0dGVkKSkgeworCQlpZiAoc3luY19jbXB4Y2hnKCZnbnR0YWJfc2hhcmVkLnYx
W3JlZl0uZmxhZ3MsIGZsYWdzLCAwKSA9PSBmbGFncykKIAkJCXJldHVybiAwOwogCQljcHVf
cmVsYXgoKTsKIAl9CiAKIAkvKiBJZiBhIHRyYW5zZmVyIGlzIGluIHByb2dyZXNzIHRoZW4g
d2FpdCB1bnRpbCBpdCBpcyBjb21wbGV0ZWQuICovCiAJd2hpbGUgKCEoZmxhZ3MgJiBHVEZf
dHJhbnNmZXJfY29tcGxldGVkKSkgewotCQlmbGFncyA9IHNoYXJlZFtyZWZdLmZsYWdzOwor
CQlmbGFncyA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mbGFnczsKIAkJY3B1X3JlbGF4KCk7
CiAJfQogCiAJcm1iKCk7CS8qIFJlYWQgdGhlIGZyYW1lIG51bWJlciAvYWZ0ZXIvIHJlYWRp
bmcgY29tcGxldGlvbiBzdGF0dXMuICovCi0JZnJhbWUgPSBzaGFyZWRbcmVmXS5mcmFtZTsK
KwlmcmFtZSA9IGdudHRhYl9zaGFyZWQudjFbcmVmXS5mcmFtZTsKIAlCVUdfT04oZnJhbWUg
PT0gMCk7CiAKIAlyZXR1cm4gZnJhbWU7CiB9CisKK3Vuc2lnbmVkIGxvbmcgZ250dGFiX2Vu
ZF9mb3JlaWduX3RyYW5zZmVyX3JlZihncmFudF9yZWZfdCByZWYpCit7CisJcmV0dXJuIGdu
dHRhYl9pbnRlcmZhY2UtPmVuZF9mb3JlaWduX3RyYW5zZmVyX3JlZihyZWYpOworfQogRVhQ
T1JUX1NZTUJPTF9HUEwoZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZik7CiAKIHVu
c2lnbmVkIGxvbmcgZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyKGdyYW50X3JlZl90IHJl
ZikKQEAgLTUyMCw2ICs1ODgsMjMgQEAgaW50IGdudHRhYl91bm1hcF9yZWZzKHN0cnVjdCBn
bnR0YWJfdW5tYXBfZ3JhbnRfcmVmICp1bm1hcF9vcHMsCiB9CiBFWFBPUlRfU1lNQk9MX0dQ
TChnbnR0YWJfdW5tYXBfcmVmcyk7CiAKK3N0YXRpYyBpbnQgZ250dGFiX21hcF9mcmFtZXNf
djEodW5zaWduZWQgbG9uZyAqZnJhbWVzLCB1bnNpZ25lZCBpbnQgbnJfZ2ZyYW1lcykKK3sK
KwlpbnQgcmM7CisKKwlyYyA9IGFyY2hfZ250dGFiX21hcF9zaGFyZWQoZnJhbWVzLCBucl9n
ZnJhbWVzLAorCQkJCSAgICBnbnR0YWJfbWF4X2dyYW50X2ZyYW1lcygpLAorCQkJCSAgICAm
Z250dGFiX3NoYXJlZC5hZGRyKTsKKwlCVUdfT04ocmMpOworCisJcmV0dXJuIDA7Cit9CisK
K3N0YXRpYyB2b2lkIGdudHRhYl91bm1hcF9mcmFtZXNfdjEodm9pZCkKK3sKKwlhcmNoX2du
dHRhYl91bm1hcF9zaGFyZWQoZ250dGFiX3NoYXJlZC5hZGRyLCBucl9ncmFudF9mcmFtZXMp
OworfQorCiBzdGF0aWMgaW50IGdudHRhYl9tYXAodW5zaWduZWQgaW50IHN0YXJ0X2lkeCwg
dW5zaWduZWQgaW50IGVuZF9pZHgpCiB7CiAJc3RydWN0IGdudHRhYl9zZXR1cF90YWJsZSBz
ZXR1cDsKQEAgLTU2NywxOSArNjUyLDM1IEBAIHN0YXRpYyBpbnQgZ250dGFiX21hcCh1bnNp
Z25lZCBpbnQgc3RhcnRfaWR4LCB1bnNpZ25lZCBpbnQgZW5kX2lkeCkKIAogCUJVR19PTihy
YyB8fCBzZXR1cC5zdGF0dXMpOwogCi0JcmMgPSBhcmNoX2dudHRhYl9tYXBfc2hhcmVkKGZy
YW1lcywgbnJfZ2ZyYW1lcywgZ250dGFiX21heF9ncmFudF9mcmFtZXMoKSwKLQkJCQkgICAg
JnNoYXJlZCk7Ci0JQlVHX09OKHJjKTsKKwlyYyA9IGdudHRhYl9pbnRlcmZhY2UtPm1hcF9m
cmFtZXMoZnJhbWVzLCBucl9nZnJhbWVzKTsKIAogCWtmcmVlKGZyYW1lcyk7CiAKLQlyZXR1
cm4gMDsKKwlyZXR1cm4gcmM7Cit9CisKK3N0YXRpYyBzdHJ1Y3QgZ250dGFiX29wcyBnbnR0
YWJfdjFfb3BzID0geworCS5tYXBfZnJhbWVzCQkJPSBnbnR0YWJfbWFwX2ZyYW1lc192MSwK
KwkudW5tYXBfZnJhbWVzCQkJPSBnbnR0YWJfdW5tYXBfZnJhbWVzX3YxLAorCS51cGRhdGVf
ZW50cnkJCQk9IHVwZGF0ZV9ncmFudF9lbnRyeV92MSwKKwkuZW5kX2ZvcmVpZ25fYWNjZXNz
X3JlZgkJPSBnbnR0YWJfZW5kX2ZvcmVpZ25fYWNjZXNzX3JlZl92MSwKKwkuZW5kX2ZvcmVp
Z25fdHJhbnNmZXJfcmVmCT0gZ250dGFiX2VuZF9mb3JlaWduX3RyYW5zZmVyX3JlZl92MSwK
KwkucXVlcnlfZm9yZWlnbl9hY2Nlc3MJCT0gZ250dGFiX3F1ZXJ5X2ZvcmVpZ25fYWNjZXNz
X3YxLAorfTsKKworc3RhdGljIHZvaWQgZ250dGFiX3JlcXVlc3RfdmVyc2lvbih2b2lkKQor
eworCWdyYW50X3RhYmxlX3ZlcnNpb24gPSAxOworCWdudHRhYl9pbnRlcmZhY2UgPSAmZ250
dGFiX3YxX29wczsKKwlwcmludGsoS0VSTl9JTkZPICJHcmFudCB0YWJsZXMgdXNpbmcgdmVy
c2lvbiAlZCBsYXlvdXQuXG4iLAorCQlncmFudF90YWJsZV92ZXJzaW9uKTsKIH0KIAogaW50
IGdudHRhYl9yZXN1bWUodm9pZCkKIHsKIAl1bnNpZ25lZCBpbnQgbWF4X25yX2dmcmFtZXM7
CiAKKwlnbnR0YWJfcmVxdWVzdF92ZXJzaW9uKCk7CiAJbWF4X25yX2dmcmFtZXMgPSBnbnR0
YWJfbWF4X2dyYW50X2ZyYW1lcygpOwogCWlmIChtYXhfbnJfZ2ZyYW1lcyA8IG5yX2dyYW50
X2ZyYW1lcykKIAkJcmV0dXJuIC1FTk9TWVM7CkBAIC01ODcsOSArNjg4LDEwIEBAIGludCBn
bnR0YWJfcmVzdW1lKHZvaWQpCiAJaWYgKHhlbl9wdl9kb21haW4oKSkKIAkJcmV0dXJuIGdu
dHRhYl9tYXAoMCwgbnJfZ3JhbnRfZnJhbWVzIC0gMSk7CiAKLQlpZiAoIXNoYXJlZCkgewot
CQlzaGFyZWQgPSBpb3JlbWFwKHhlbl9odm1fcmVzdW1lX2ZyYW1lcywgUEFHRV9TSVpFICog
bWF4X25yX2dmcmFtZXMpOwotCQlpZiAoc2hhcmVkID09IE5VTEwpIHsKKwlpZiAoZ250dGFi
X3NoYXJlZC5hZGRyID09IE5VTEwpIHsKKwkJZ250dGFiX3NoYXJlZC5hZGRyID0gaW9yZW1h
cCh4ZW5faHZtX3Jlc3VtZV9mcmFtZXMsCisJCQkJCQlQQUdFX1NJWkUgKiBtYXhfbnJfZ2Zy
YW1lcyk7CisJCWlmIChnbnR0YWJfc2hhcmVkLmFkZHIgPT0gTlVMTCkgewogCQkJcHJpbnRr
KEtFUk5fV0FSTklORwogCQkJCQkiRmFpbGVkIHRvIGlvcmVtYXAgZ250dGFiIHNoYXJlIGZy
YW1lcyEiKTsKIAkJCXJldHVybiAtRU5PTUVNOwpAQCAtNjAzLDcgKzcwNSw3IEBAIGludCBn
bnR0YWJfcmVzdW1lKHZvaWQpCiAKIGludCBnbnR0YWJfc3VzcGVuZCh2b2lkKQogewotCWFy
Y2hfZ250dGFiX3VubWFwX3NoYXJlZChzaGFyZWQsIG5yX2dyYW50X2ZyYW1lcyk7CisJZ250
dGFiX2ludGVyZmFjZS0+dW5tYXBfZnJhbWVzKCk7CiAJcmV0dXJuIDA7CiB9CiAKZGlmZiAt
LWdpdCBhL2luY2x1ZGUveGVuL2dyYW50X3RhYmxlLmggYi9pbmNsdWRlL3hlbi9ncmFudF90
YWJsZS5oCmluZGV4IDExZTJkZmMuLmM3YTQwZjggMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVu
L2dyYW50X3RhYmxlLmgKKysrIGIvaW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUuaApAQCAtMTQ1
LDggKzE0NSw4IEBAIGdudHRhYl9zZXRfdW5tYXBfb3Aoc3RydWN0IGdudHRhYl91bm1hcF9n
cmFudF9yZWYgKnVubWFwLCBwaHlzX2FkZHJfdCBhZGRyLAogCiBpbnQgYXJjaF9nbnR0YWJf
bWFwX3NoYXJlZCh1bnNpZ25lZCBsb25nICpmcmFtZXMsIHVuc2lnbmVkIGxvbmcgbnJfZ2Zy
YW1lcywKIAkJCSAgIHVuc2lnbmVkIGxvbmcgbWF4X25yX2dmcmFtZXMsCi0JCQkgICBzdHJ1
Y3QgZ3JhbnRfZW50cnkgKipfX3NoYXJlZCk7Ci12b2lkIGFyY2hfZ250dGFiX3VubWFwX3No
YXJlZChzdHJ1Y3QgZ3JhbnRfZW50cnkgKnNoYXJlZCwKKwkJCSAgIHZvaWQgKipfX3NoYXJl
ZCk7Cit2b2lkIGFyY2hfZ250dGFiX3VubWFwX3NoYXJlZCh2b2lkICpzaGFyZWQsCiAJCQkg
ICAgICB1bnNpZ25lZCBsb25nIG5yX2dmcmFtZXMpOwogCiBleHRlcm4gdW5zaWduZWQgbG9u
ZyB4ZW5faHZtX3Jlc3VtZV9mcmFtZXM7CmRpZmYgLS1naXQgYS9pbmNsdWRlL3hlbi9pbnRl
cmZhY2UvZ3JhbnRfdGFibGUuaCBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFudF90YWJs
ZS5oCmluZGV4IDM5ZTU3MTcuLmExN2Q4NDQgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUveGVuL2lu
dGVyZmFjZS9ncmFudF90YWJsZS5oCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS9ncmFu
dF90YWJsZS5oCkBAIC04NSwxMiArODUsMjIgQEAKICAqLwogCiAvKgorICogUmVmZXJlbmNl
IHRvIGEgZ3JhbnQgZW50cnkgaW4gYSBzcGVjaWZpZWQgZG9tYWluJ3MgZ3JhbnQgdGFibGUu
CisgKi8KK3R5cGVkZWYgdWludDMyX3QgZ3JhbnRfcmVmX3Q7CisKKy8qCiAgKiBBIGdyYW50
IHRhYmxlIGNvbXByaXNlcyBhIHBhY2tlZCBhcnJheSBvZiBncmFudCBlbnRyaWVzIGluIG9u
ZSBvciBtb3JlCiAgKiBwYWdlIGZyYW1lcyBzaGFyZWQgYmV0d2VlbiBYZW4gYW5kIGEgZ3Vl
c3QuCiAgKiBbWEVOXTogVGhpcyBmaWVsZCBpcyB3cml0dGVuIGJ5IFhlbiBhbmQgcmVhZCBi
eSB0aGUgc2hhcmluZyBndWVzdC4KICAqIFtHU1RdOiBUaGlzIGZpZWxkIGlzIHdyaXR0ZW4g
YnkgdGhlIGd1ZXN0IGFuZCByZWFkIGJ5IFhlbi4KICAqLwotc3RydWN0IGdyYW50X2VudHJ5
IHsKKworLyoKKyAqIFZlcnNpb24gMSBvZiB0aGUgZ3JhbnQgdGFibGUgZW50cnkgc3RydWN0
dXJlIGlzIG1haW50YWluZWQgcHVyZWx5CisgKiBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxp
dHkuICBOZXcgZ3Vlc3RzIHNob3VsZCB1c2UgdmVyc2lvbiAyLgorICovCitzdHJ1Y3QgZ3Jh
bnRfZW50cnlfdjEgewogICAgIC8qIEdURl94eHg6IHZhcmlvdXMgdHlwZSBhbmQgZmxhZyBp
bmZvcm1hdGlvbi4gIFtYRU4sR1NUXSAqLwogICAgIHVpbnQxNl90IGZsYWdzOwogICAgIC8q
IFRoZSBkb21haW4gYmVpbmcgZ3JhbnRlZCBmb3JlaWduIHByaXZpbGVnZXMuIFtHU1RdICov
CkBAIC0xMDgsMTAgKzExOCwxMyBAQCBzdHJ1Y3QgZ3JhbnRfZW50cnkgewogICogIEdURl9w
ZXJtaXRfYWNjZXNzOiBBbGxvdyBAZG9taWQgdG8gbWFwL2FjY2VzcyBAZnJhbWUuCiAgKiAg
R1RGX2FjY2VwdF90cmFuc2ZlcjogQWxsb3cgQGRvbWlkIHRvIHRyYW5zZmVyIG93bmVyc2hp
cCBvZiBvbmUgcGFnZSBmcmFtZQogICogICAgICAgICAgICAgICAgICAgICAgIHRvIHRoaXMg
Z3Vlc3QuIFhlbiB3cml0ZXMgdGhlIHBhZ2UgbnVtYmVyIHRvIEBmcmFtZS4KKyAqICBHVEZf
dHJhbnNpdGl2ZTogQWxsb3cgQGRvbWlkIHRvIHRyYW5zaXRpdmVseSBhY2Nlc3MgYSBzdWJy
YW5nZSBvZgorICogICAgICAgICAgICAgICAgICBAdHJhbnNfZ3JhbnQgaW4gQHRyYW5zX2Rv
bWlkLiAgTm8gbWFwcGluZ3MgYXJlIGFsbG93ZWQuCiAgKi8KICNkZWZpbmUgR1RGX2ludmFs
aWQgICAgICAgICAoMFU8PDApCiAjZGVmaW5lIEdURl9wZXJtaXRfYWNjZXNzICAgKDFVPDww
KQogI2RlZmluZSBHVEZfYWNjZXB0X3RyYW5zZmVyICgyVTw8MCkKKyNkZWZpbmUgR1RGX3Ry
YW5zaXRpdmUgICAgICAoM1U8PDApCiAjZGVmaW5lIEdURl90eXBlX21hc2sgICAgICAgKDNV
PDwwKQogCiAvKgpAQCAtMTE5LDYgKzEzMiw5IEBAIHN0cnVjdCBncmFudF9lbnRyeSB7CiAg
KiAgR1RGX3JlYWRvbmx5OiBSZXN0cmljdCBAZG9taWQgdG8gcmVhZC1vbmx5IG1hcHBpbmdz
IGFuZCBhY2Nlc3Nlcy4gW0dTVF0KICAqICBHVEZfcmVhZGluZzogR3JhbnQgZW50cnkgaXMg
Y3VycmVudGx5IG1hcHBlZCBmb3IgcmVhZGluZyBieSBAZG9taWQuIFtYRU5dCiAgKiAgR1RG
X3dyaXRpbmc6IEdyYW50IGVudHJ5IGlzIGN1cnJlbnRseSBtYXBwZWQgZm9yIHdyaXRpbmcg
YnkgQGRvbWlkLiBbWEVOXQorICogIEdURl9zdWJfcGFnZTogR3JhbnQgYWNjZXNzIHRvIG9u
bHkgYSBzdWJyYW5nZSBvZiB0aGUgcGFnZS4gIEBkb21pZAorICogICAgICAgICAgICAgICAg
d2lsbCBvbmx5IGJlIGFsbG93ZWQgdG8gY29weSBmcm9tIHRoZSBncmFudCwgYW5kIG5vdAor
ICogICAgICAgICAgICAgICAgbWFwIGl0LiBbR1NUXQogICovCiAjZGVmaW5lIF9HVEZfcmVh
ZG9ubHkgICAgICAgKDIpCiAjZGVmaW5lIEdURl9yZWFkb25seSAgICAgICAgKDFVPDxfR1RG
X3JlYWRvbmx5KQpAQCAtMTI2LDYgKzE0Miw4IEBAIHN0cnVjdCBncmFudF9lbnRyeSB7CiAj
ZGVmaW5lIEdURl9yZWFkaW5nICAgICAgICAgKDFVPDxfR1RGX3JlYWRpbmcpCiAjZGVmaW5l
IF9HVEZfd3JpdGluZyAgICAgICAgKDQpCiAjZGVmaW5lIEdURl93cml0aW5nICAgICAgICAg
KDFVPDxfR1RGX3dyaXRpbmcpCisjZGVmaW5lIF9HVEZfc3ViX3BhZ2UgICAgICAgKDgpCisj
ZGVmaW5lIEdURl9zdWJfcGFnZSAgICAgICAgKDFVPDxfR1RGX3N1Yl9wYWdlKQogCiAvKgog
ICogU3ViZmxhZ3MgZm9yIEdURl9hY2NlcHRfdHJhbnNmZXI6CkBAIC0xNDIsMTUgKzE2MCw4
MSBAQCBzdHJ1Y3QgZ3JhbnRfZW50cnkgewogI2RlZmluZSBfR1RGX3RyYW5zZmVyX2NvbXBs
ZXRlZCAoMykKICNkZWZpbmUgR1RGX3RyYW5zZmVyX2NvbXBsZXRlZCAgKDFVPDxfR1RGX3Ry
YW5zZmVyX2NvbXBsZXRlZCkKIAorLyoKKyAqIFZlcnNpb24gMiBncmFudCB0YWJsZSBlbnRy
aWVzLiAgVGhlc2UgZnVsZmlsIHRoZSBzYW1lIHJvbGUgYXMKKyAqIHZlcnNpb24gMSBlbnRy
aWVzLCBidXQgY2FuIHJlcHJlc2VudCBtb3JlIGNvbXBsaWNhdGVkIG9wZXJhdGlvbnMuCisg
KiBBbnkgZ2l2ZW4gZG9tYWluIHdpbGwgaGF2ZSBlaXRoZXIgYSB2ZXJzaW9uIDEgb3IgYSB2
ZXJzaW9uIDIgdGFibGUsCisgKiBhbmQgZXZlcnkgZW50cnkgaW4gdGhlIHRhYmxlIHdpbGwg
YmUgdGhlIHNhbWUgdmVyc2lvbi4KKyAqCisgKiBUaGUgaW50ZXJmYWNlIGJ5IHdoaWNoIGRv
bWFpbnMgdXNlIGdyYW50IHJlZmVyZW5jZXMgZG9lcyBub3QgZGVwZW5kCisgKiBvbiB0aGUg
Z3JhbnQgdGFibGUgdmVyc2lvbiBpbiB1c2UgYnkgdGhlIG90aGVyIGRvbWFpbi4KKyAqLwog
Ci0vKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKLSAqIEdSQU5UIFRBQkxF
IFFVRVJJRVMgQU5EIFVTRVMKKy8qCisgKiBWZXJzaW9uIDEgYW5kIHZlcnNpb24gMiBncmFu
dCBlbnRyaWVzIHNoYXJlIGEgY29tbW9uIHByZWZpeC4gIFRoZQorICogZmllbGRzIG9mIHRo
ZSBwcmVmaXggYXJlIGRvY3VtZW50ZWQgYXMgcGFydCBvZiBzdHJ1Y3QKKyAqIGdyYW50X2Vu
dHJ5X3YxLgogICovCitzdHJ1Y3QgZ3JhbnRfZW50cnlfaGVhZGVyIHsKKyAgICB1aW50MTZf
dCBmbGFnczsKKyAgICBkb21pZF90ICBkb21pZDsKK307CiAKIC8qCi0gKiBSZWZlcmVuY2Ug
dG8gYSBncmFudCBlbnRyeSBpbiBhIHNwZWNpZmllZCBkb21haW4ncyBncmFudCB0YWJsZS4K
KyAqIFZlcnNpb24gMiBvZiB0aGUgZ3JhbnQgZW50cnkgc3RydWN0dXJlLCBoZXJlIGlzIGFu
IHVuaW9uIGJlY2F1c2UgdGhyZWUKKyAqIGRpZmZlcmVudCB0eXBlcyBhcmUgc3VwcG90dGVk
OiBmdWxsX3BhZ2UsIHN1Yl9wYWdlIGFuZCB0cmFuc2l0aXZlLgorICovCit1bmlvbiBncmFu
dF9lbnRyeV92MiB7CisgICAgc3RydWN0IGdyYW50X2VudHJ5X2hlYWRlciBoZHI7CisKKyAg
ICAvKgorICAgICAqIFRoaXMgbWVtYmVyIGlzIHVzZWQgZm9yIFYxLXN0eWxlIGZ1bGwgcGFn
ZSBncmFudHMsIHdoZXJlIGVpdGhlcjoKKyAgICAgKgorICAgICAqIC0tIGhkci50eXBlIGlz
IEdURl9hY2NlcHRfdHJhbnNmZXIsIG9yCisgICAgICogLS0gaGRyLnR5cGUgaXMgR1RGX3Bl
cm1pdF9hY2Nlc3MgYW5kIEdURl9zdWJfcGFnZSBpcyBub3Qgc2V0LgorICAgICAqCisgICAg
ICogSW4gdGhhdCBjYXNlLCB0aGUgZnJhbWUgZmllbGQgaGFzIHRoZSBzYW1lIHNlbWFudGlj
cyBhcyB0aGUKKyAgICAgKiBmaWVsZCBvZiB0aGUgc2FtZSBuYW1lIGluIHRoZSBWMSBlbnRy
eSBzdHJ1Y3R1cmUuCisgICAgICovCisgICAgc3RydWN0IHsKKwlzdHJ1Y3QgZ3JhbnRfZW50
cnlfaGVhZGVyIGhkcjsKKwl1aW50MzJfdCBwYWQwOworCXVpbnQ2NF90IGZyYW1lOworICAg
IH0gZnVsbF9wYWdlOworCisgICAgLyoKKyAgICAgKiBJZiB0aGUgZ3JhbnQgdHlwZSBpcyBH
VEZfZ3JhbnRfYWNjZXNzIGFuZCBHVEZfc3ViX3BhZ2UgaXMgc2V0LAorICAgICAqIEBkb21p
ZCBpcyBhbGxvd2VkIHRvIGFjY2VzcyBieXRlcyBbQHBhZ2Vfb2ZmLEBwYWdlX29mZitAbGVu
Z3RoKQorICAgICAqIGluIGZyYW1lIEBmcmFtZS4KKyAgICAgKi8KKyAgICBzdHJ1Y3Qgewor
CXN0cnVjdCBncmFudF9lbnRyeV9oZWFkZXIgaGRyOworCXVpbnQxNl90IHBhZ2Vfb2ZmOwor
CXVpbnQxNl90IGxlbmd0aDsKKwl1aW50NjRfdCBmcmFtZTsKKyAgICB9IHN1Yl9wYWdlOwor
CisgICAgLyoKKyAgICAgKiBJZiB0aGUgZ3JhbnQgaXMgR1RGX3RyYW5zaXRpdmUsIEBkb21p
ZCBpcyBhbGxvd2VkIHRvIHVzZSB0aGUKKyAgICAgKiBncmFudCBAZ3JlZiBpbiBkb21haW4g
QHRyYW5zX2RvbWlkLCBhcyBpZiBpdCB3YXMgdGhlIGxvY2FsCisgICAgICogZG9tYWluLiAg
T2J2aW91c2x5LCB0aGUgdHJhbnNpdGl2ZSBhY2Nlc3MgbXVzdCBiZSBjb21wYXRpYmxlCisg
ICAgICogd2l0aCB0aGUgb3JpZ2luYWwgZ3JhbnQuCisgICAgICovCisgICAgc3RydWN0IHsK
KwlzdHJ1Y3QgZ3JhbnRfZW50cnlfaGVhZGVyIGhkcjsKKwlkb21pZF90IHRyYW5zX2RvbWlk
OworCXVpbnQxNl90IHBhZDA7CisJZ3JhbnRfcmVmX3QgZ3JlZjsKKyAgICB9IHRyYW5zaXRp
dmU7CisKKyAgICB1aW50MzJfdCBfX3NwYWNlcls0XTsgLyogUGFkIHRvIGEgcG93ZXIgb2Yg
dHdvICovCit9OworCit0eXBlZGVmIHVpbnQxNl90IGdyYW50X3N0YXR1c190OworCisvKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKKyAqIEdSQU5UIFRBQkxFIFFVRVJJ
RVMgQU5EIFVTRVMKICAqLwotdHlwZWRlZiB1aW50MzJfdCBncmFudF9yZWZfdDsKIAogLyoK
ICAqIEhhbmRsZSB0byB0cmFjayBhIG1hcHBpbmcgY3JlYXRlZCB2aWEgYSBncmFudCByZWZl
cmVuY2UuCkBAIC0zMjIsNiArNDA2LDc5IEBAIHN0cnVjdCBnbnR0YWJfcXVlcnlfc2l6ZSB7
CiBERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVChnbnR0YWJfcXVlcnlfc2l6ZSk7CiAKIC8q
CisgKiBHTlRUQUJPUF91bm1hcF9hbmRfcmVwbGFjZTogRGVzdHJveSBvbmUgb3IgbW9yZSBn
cmFudC1yZWZlcmVuY2UgbWFwcGluZ3MKKyAqIHRyYWNrZWQgYnkgPGhhbmRsZT4gYnV0IGF0
b21pY2FsbHkgcmVwbGFjZSB0aGUgcGFnZSB0YWJsZSBlbnRyeSB3aXRoIG9uZQorICogcG9p
bnRpbmcgdG8gdGhlIG1hY2hpbmUgYWRkcmVzcyB1bmRlciA8bmV3X2FkZHI+LiAgPG5ld19h
ZGRyPiB3aWxsIGJlCisgKiByZWRpcmVjdGVkIHRvIHRoZSBudWxsIGVudHJ5LgorICogTk9U
RVM6CisgKiAgMS4gVGhlIGNhbGwgbWF5IGZhaWwgaW4gYW4gdW5kZWZpbmVkIG1hbm5lciBp
ZiBlaXRoZXIgbWFwcGluZyBpcyBub3QKKyAqICAgICB0cmFja2VkIGJ5IDxoYW5kbGU+Lgor
ICogIDIuIEFmdGVyIGV4ZWN1dGluZyBhIGJhdGNoIG9mIHVubWFwcywgaXQgaXMgZ3VhcmFu
dGVlZCB0aGF0IG5vIHN0YWxlCisgKiAgICAgbWFwcGluZ3Mgd2lsbCByZW1haW4gaW4gdGhl
IGRldmljZSBvciBob3N0IFRMQnMuCisgKi8KKyNkZWZpbmUgR05UVEFCT1BfdW5tYXBfYW5k
X3JlcGxhY2UgICAgNworc3RydWN0IGdudHRhYl91bm1hcF9hbmRfcmVwbGFjZSB7CisgICAg
LyogSU4gcGFyYW1ldGVycy4gKi8KKyAgICB1aW50NjRfdCBob3N0X2FkZHI7CisgICAgdWlu
dDY0X3QgbmV3X2FkZHI7CisgICAgZ3JhbnRfaGFuZGxlX3QgaGFuZGxlOworICAgIC8qIE9V
VCBwYXJhbWV0ZXJzLiAqLworICAgIGludDE2X3QgIHN0YXR1czsgICAgICAgICAgICAgIC8q
IEdOVFNUXyogKi8KK307CitERUZJTkVfR1VFU1RfSEFORExFX1NUUlVDVChnbnR0YWJfdW5t
YXBfYW5kX3JlcGxhY2UpOworCisvKgorICogR05UVEFCT1Bfc2V0X3ZlcnNpb246IFJlcXVl
c3QgYSBwYXJ0aWN1bGFyIHZlcnNpb24gb2YgdGhlIGdyYW50CisgKiB0YWJsZSBzaGFyZWQg
dGFibGUgc3RydWN0dXJlLiAgVGhpcyBvcGVyYXRpb24gY2FuIG9ubHkgYmUgcGVyZm9ybWVk
CisgKiBvbmNlIGluIGFueSBnaXZlbiBkb21haW4uICBJdCBtdXN0IGJlIHBlcmZvcm1lZCBi
ZWZvcmUgYW55IGdyYW50cworICogYXJlIGFjdGl2YXRlZDsgb3RoZXJ3aXNlLCB0aGUgZG9t
YWluIHdpbGwgYmUgc3R1Y2sgd2l0aCB2ZXJzaW9uIDEuCisgKiBUaGUgb25seSBkZWZpbmVk
IHZlcnNpb25zIGFyZSAxIGFuZCAyLgorICovCisjZGVmaW5lIEdOVFRBQk9QX3NldF92ZXJz
aW9uICAgICAgICAgIDgKK3N0cnVjdCBnbnR0YWJfc2V0X3ZlcnNpb24geworICAgIC8qIElO
IHBhcmFtZXRlcnMgKi8KKyAgICB1aW50MzJfdCB2ZXJzaW9uOworfTsKK0RFRklORV9HVUVT
VF9IQU5ETEVfU1RSVUNUKGdudHRhYl9zZXRfdmVyc2lvbik7CisKKy8qCisgKiBHTlRUQUJP
UF9nZXRfc3RhdHVzX2ZyYW1lczogR2V0IHRoZSBsaXN0IG9mIGZyYW1lcyB1c2VkIHRvIHN0
b3JlIGdyYW50CisgKiBzdGF0dXMgZm9yIDxkb20+LiBJbiBncmFudCBmb3JtYXQgdmVyc2lv
biAyLCB0aGUgc3RhdHVzIGlzIHNlcGFyYXRlZAorICogZnJvbSB0aGUgb3RoZXIgc2hhcmVk
IGdyYW50IGZpZWxkcyB0byBhbGxvdyBtb3JlIGVmZmljaWVudCBzeW5jaHJvbml6YXRpb24K
KyAqIHVzaW5nIGJhcnJpZXJzIGluc3RlYWQgb2YgYXRvbWljIGNtcGV4Y2ggb3BlcmF0aW9u
cy4KKyAqIDxucl9mcmFtZXM+IHNwZWNpZnkgdGhlIHNpemUgb2YgdmVjdG9yIDxmcmFtZV9s
aXN0Pi4KKyAqIFRoZSBmcmFtZSBhZGRyZXNzZXMgYXJlIHJldHVybmVkIGluIHRoZSA8ZnJh
bWVfbGlzdD4uCisgKiBPbmx5IDxucl9mcmFtZXM+IGFkZHJlc3NlcyBhcmUgcmV0dXJuZWQs
IGV2ZW4gaWYgdGhlIHRhYmxlIGlzIGxhcmdlci4KKyAqIE5PVEVTOgorICogIDEuIDxkb20+
IG1heSBiZSBzcGVjaWZpZWQgYXMgRE9NSURfU0VMRi4KKyAqICAyLiBPbmx5IGEgc3VmZmlj
aWVudGx5LXByaXZpbGVnZWQgZG9tYWluIG1heSBzcGVjaWZ5IDxkb20+ICE9IERPTUlEX1NF
TEYuCisgKi8KKyNkZWZpbmUgR05UVEFCT1BfZ2V0X3N0YXR1c19mcmFtZXMgICAgIDkKK3N0
cnVjdCBnbnR0YWJfZ2V0X3N0YXR1c19mcmFtZXMgeworICAgIC8qIElOIHBhcmFtZXRlcnMu
ICovCisgICAgdWludDMyX3QgbnJfZnJhbWVzOworICAgIGRvbWlkX3QgIGRvbTsKKyAgICAv
KiBPVVQgcGFyYW1ldGVycy4gKi8KKyAgICBpbnQxNl90ICBzdGF0dXM7ICAgICAgICAgICAg
ICAvKiBHTlRTVF8qICovCisgICAgR1VFU1RfSEFORExFKHVpbnQ2NF90KSBmcmFtZV9saXN0
OworfTsKK0RFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKGdudHRhYl9nZXRfc3RhdHVzX2Zy
YW1lcyk7CisKKy8qCisgKiBHTlRUQUJPUF9nZXRfdmVyc2lvbjogR2V0IHRoZSBncmFudCB0
YWJsZSB2ZXJzaW9uIHdoaWNoIGlzIGluCisgKiBlZmZlY3QgZm9yIGRvbWFpbiA8ZG9tPi4K
KyAqLworI2RlZmluZSBHTlRUQUJPUF9nZXRfdmVyc2lvbiAgICAgICAgICAxMAorc3RydWN0
IGdudHRhYl9nZXRfdmVyc2lvbiB7CisgICAgLyogSU4gcGFyYW1ldGVycyAqLworICAgIGRv
bWlkX3QgZG9tOworICAgIHVpbnQxNl90IHBhZDsKKyAgICAvKiBPVVQgcGFyYW1ldGVycyAq
LworICAgIHVpbnQzMl90IHZlcnNpb247Cit9OworREVGSU5FX0dVRVNUX0hBTkRMRV9TVFJV
Q1QoZ250dGFiX2dldF92ZXJzaW9uKTsKKworLyoKICAqIEJpdGZpZWxkIHZhbHVlcyBmb3Ig
dXBkYXRlX3Bpbl9zdGF0dXMuZmxhZ3MuCiAgKi8KICAvKiBNYXAgdGhlIGdyYW50IGVudHJ5
IGZvciBhY2Nlc3MgYnkgSS9PIGRldmljZXMuICovCmRpZmYgLS1naXQgYS9pbmNsdWRlL3hl
bi9pbnRlcmZhY2UveGVuLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVuLmgKaW5kZXgg
NmE2ZTkxNC4uYTg5MDgwNCAxMDA2NDQKLS0tIGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNlL3hl
bi5oCisrKyBiL2luY2x1ZGUveGVuL2ludGVyZmFjZS94ZW4uaApAQCAtNTIzLDYgKzUyMyw4
IEBAIHN0cnVjdCB0bWVtX29wIHsKIAl9IHU7CiB9OwogCitERUZJTkVfR1VFU1RfSEFORExF
KHU2NCk7CisKICNlbHNlIC8qIF9fQVNTRU1CTFlfXyAqLwogCiAvKiBJbiBhc3NlbWJseSBj
b2RlIHdlIGNhbm5vdCB1c2UgQyBudW1lcmljIGNvbnN0YW50IHN1ZmZpeGVzLiAqLwotLSAK
MS43LjYuNAoK
--------------050700040602000504040002
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------050700040602000504040002--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 10:19:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 10:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQy2-0004Se-DF; Mon, 21 Nov 2011 10:19:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pankaj.kumarbiswas@citrix.com>) id 1RSQy0-0004SZ-QC
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 10:19:13 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321870686!63989080!1
X-Originating-IP: [203.166.19.134]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29972 invoked from network); 21 Nov 2011 10:18:10 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 10:18:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; d="scan'208,217";a="9361307"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 10:18:45 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.72]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Mon, 21 Nov 2011
	15:48:44 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 21 Nov 2011 15:48:43 +0530
Thread-Topic: Re: netdev watchdog timeout and FTQ dump
Thread-Index: AcyoNubCIvlJ84xsRxCx6UzZFXJmlQ==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F442904127@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] netdev watchdog timeout and FTQ dump
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5435395389758834695=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5435395389758834695==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904127BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904127BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Team,

Due to heavy network traffic I can see the following warnings  in xenserver=
 logs. As I understand the first one is the watchdog time out and second on=
e is FTQ dump.


Sep 12 06:43:20 XENHOST05 kernel: WARNING: at net/sched/sch_generic.c:261 d=
ev_watchdog+0x241/0x250()

Sep 12 06:43:20 XENHOST05 kernel: Hardware name: ProLiant DL385 G7

Sep 12 06:43:20 XENHOST05 kernel: NETDEV WATCHDOG: eth0 (bnx2): transmit qu=
eue 7 timed out


&&


bnx2: eth0: BNX2_RV2P_PFTQ_CTL 10000
bnx2: eth0: BNX2_RV2P_TFTQ_CTL 20000
bnx2: eth0: BNX2_RV2P_MFTQ_CTL 4000
bnx2: eth0: BNX2_TBDR_FTQ_CTL 4002
bnx2: eth0: BNX2_TDMA_FTQ_CTL 10002
bnx2: eth0: BNX2_TXP_FTQ_CTL 10000


Is this the problem because of  cpu states enabled in intel processor (as a=
ddressed earlier) or there is something related to Broadcom driver bnx2 as =
well.
Can I get a patch or any information regarding this.






Thanks & Regards,
PANKAJ KUMAR BISWAS

Software Maintenance Engineer | XenServer India | Citrix Systems Inc.
Ext. 41225 | Email:  pankaj.kumarbiswas@citrix.com


--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904127BANPMAILBOX01_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Cambria;
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Hi Team,<o:p></o=
:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Due t=
o heavy network traffic I can see the following warnings &nbsp;in xenserver=
 logs. As I understand the first one is the watchdog time out and second on=
e is FTQ dump. <o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><pr=
e style=3D'line-height:15.6pt;background:#F0F0F0'><span style=3D'color:blac=
k'>Sep 12 06:43:20 XENHOST05 kernel: WARNING: at net/sched/sch_generic.c:26=
1 dev_watchdog+0x241/0x250()<o:p></o:p></span></pre><pre style=3D'line-heig=
ht:15.6pt;background:#F0F0F0'><span style=3D'color:black'>Sep 12 06:43:20 X=
ENHOST05 kernel: Hardware name: ProLiant DL385 G7<o:p></o:p></span></pre><p=
re style=3D'line-height:15.6pt;background:#F0F0F0'><span style=3D'color:bla=
ck'>Sep 12 06:43:20 XENHOST05 kernel: NETDEV WATCHDOG: eth0 (bnx2): transmi=
t queue 7 timed out<o:p></o:p></span></pre><p class=3DMsoNormal><span style=
=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><o:p=
>&nbsp;</o:p></p><p class=3DMsoNormal>&amp;&amp;<o:p></o:p></p><p class=3DM=
soNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal style=3D'line-height:15.6pt;background:#F0F0F0'><span sty=
le=3D'font-size:10.0pt;font-family:"Courier New";color:black'>bnx2: eth0: B=
NX2_RV2P_PFTQ_CTL 10000<o:p></o:p></span></p><p class=3DMsoNormal style=3D'=
line-height:15.6pt;background:#F0F0F0'><span style=3D'font-size:10.0pt;font=
-family:"Courier New";color:black'>bnx2: eth0: BNX2_RV2P_TFTQ_CTL 20000<o:p=
></o:p></span></p><p class=3DMsoNormal style=3D'line-height:15.6pt;backgrou=
nd:#F0F0F0'><span style=3D'font-size:10.0pt;font-family:"Courier New";color=
:black'>bnx2: eth0: BNX2_RV2P_MFTQ_CTL 4000<o:p></o:p></span></p><p class=
=3DMsoNormal style=3D'line-height:15.6pt;background:#F0F0F0'><span style=3D=
'font-size:10.0pt;font-family:"Courier New";color:black'>bnx2: eth0: BNX2_T=
BDR_FTQ_CTL 4002<o:p></o:p></span></p><p class=3DMsoNormal style=3D'line-he=
ight:15.6pt;background:#F0F0F0'><span style=3D'font-size:10.0pt;font-family=
:"Courier New";color:black'>bnx2: eth0: BNX2_TDMA_FTQ_CTL 10002<o:p></o:p><=
/span></p><p class=3DMsoNormal style=3D'line-height:15.6pt;background:#F0F0=
F0'><span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>=
bnx2: eth0: BNX2_TXP_FTQ_CTL 10000<o:p></o:p></span></p><p class=3DMsoNorma=
l><b><span style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></b></p><p cl=
ass=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Is this the probl=
em because of &nbsp;cpu states enabled in intel processor (as addressed ear=
lier) or there is something related to Broadcom driver bnx2 as well.<o:p></=
o:p></p><p class=3DMsoNormal>Can I get a patch or any information regarding=
 this.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DM=
soNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:=
p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><b><sp=
an style=3D'font-family:"Cambria","serif"'>Thanks &amp; Regards,<o:p></o:p>=
</span></b></p><p class=3DMsoNormal><b><span style=3D'font-family:"Cambria"=
,"serif"'>PANKAJ KUMAR BISWAS<o:p></o:p></span></b></p><p class=3DMsoNormal=
><b><span style=3D'font-family:"Cambria","serif"'><o:p>&nbsp;</o:p></span><=
/b></p><p class=3DMsoNormal><b><span style=3D'font-family:"Cambria","serif"=
'>Software Maintenance Engineer | XenServer India | Citrix Systems Inc.<o:p=
></o:p></span></b></p><p class=3DMsoNormal><b><span style=3D'font-family:"C=
ambria","serif"'>Ext. 41225 | Email:&nbsp; pankaj.kumarbiswas@citrix.com<o:=
p></o:p></span></b></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></bo=
dy></html>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904127BANPMAILBOX01_--


--===============5435395389758834695==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5435395389758834695==--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 10:19:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 10:19:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSQy2-0004Se-DF; Mon, 21 Nov 2011 10:19:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pankaj.kumarbiswas@citrix.com>) id 1RSQy0-0004SZ-QC
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 10:19:13 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321870686!63989080!1
X-Originating-IP: [203.166.19.134]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29972 invoked from network); 21 Nov 2011 10:18:10 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 10:18:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; d="scan'208,217";a="9361307"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 10:18:45 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.72]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Mon, 21 Nov 2011
	15:48:44 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 21 Nov 2011 15:48:43 +0530
Thread-Topic: Re: netdev watchdog timeout and FTQ dump
Thread-Index: AcyoNubCIvlJ84xsRxCx6UzZFXJmlQ==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F442904127@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] netdev watchdog timeout and FTQ dump
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5435395389758834695=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5435395389758834695==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904127BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904127BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Team,

Due to heavy network traffic I can see the following warnings  in xenserver=
 logs. As I understand the first one is the watchdog time out and second on=
e is FTQ dump.


Sep 12 06:43:20 XENHOST05 kernel: WARNING: at net/sched/sch_generic.c:261 d=
ev_watchdog+0x241/0x250()

Sep 12 06:43:20 XENHOST05 kernel: Hardware name: ProLiant DL385 G7

Sep 12 06:43:20 XENHOST05 kernel: NETDEV WATCHDOG: eth0 (bnx2): transmit qu=
eue 7 timed out


&&


bnx2: eth0: BNX2_RV2P_PFTQ_CTL 10000
bnx2: eth0: BNX2_RV2P_TFTQ_CTL 20000
bnx2: eth0: BNX2_RV2P_MFTQ_CTL 4000
bnx2: eth0: BNX2_TBDR_FTQ_CTL 4002
bnx2: eth0: BNX2_TDMA_FTQ_CTL 10002
bnx2: eth0: BNX2_TXP_FTQ_CTL 10000


Is this the problem because of  cpu states enabled in intel processor (as a=
ddressed earlier) or there is something related to Broadcom driver bnx2 as =
well.
Can I get a patch or any information regarding this.






Thanks & Regards,
PANKAJ KUMAR BISWAS

Software Maintenance Engineer | XenServer India | Citrix Systems Inc.
Ext. 41225 | Email:  pankaj.kumarbiswas@citrix.com


--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904127BANPMAILBOX01_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Cambria;
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Hi Team,<o:p></o=
:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Due t=
o heavy network traffic I can see the following warnings &nbsp;in xenserver=
 logs. As I understand the first one is the watchdog time out and second on=
e is FTQ dump. <o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><pr=
e style=3D'line-height:15.6pt;background:#F0F0F0'><span style=3D'color:blac=
k'>Sep 12 06:43:20 XENHOST05 kernel: WARNING: at net/sched/sch_generic.c:26=
1 dev_watchdog+0x241/0x250()<o:p></o:p></span></pre><pre style=3D'line-heig=
ht:15.6pt;background:#F0F0F0'><span style=3D'color:black'>Sep 12 06:43:20 X=
ENHOST05 kernel: Hardware name: ProLiant DL385 G7<o:p></o:p></span></pre><p=
re style=3D'line-height:15.6pt;background:#F0F0F0'><span style=3D'color:bla=
ck'>Sep 12 06:43:20 XENHOST05 kernel: NETDEV WATCHDOG: eth0 (bnx2): transmi=
t queue 7 timed out<o:p></o:p></span></pre><p class=3DMsoNormal><span style=
=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><o:p=
>&nbsp;</o:p></p><p class=3DMsoNormal>&amp;&amp;<o:p></o:p></p><p class=3DM=
soNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal style=3D'line-height:15.6pt;background:#F0F0F0'><span sty=
le=3D'font-size:10.0pt;font-family:"Courier New";color:black'>bnx2: eth0: B=
NX2_RV2P_PFTQ_CTL 10000<o:p></o:p></span></p><p class=3DMsoNormal style=3D'=
line-height:15.6pt;background:#F0F0F0'><span style=3D'font-size:10.0pt;font=
-family:"Courier New";color:black'>bnx2: eth0: BNX2_RV2P_TFTQ_CTL 20000<o:p=
></o:p></span></p><p class=3DMsoNormal style=3D'line-height:15.6pt;backgrou=
nd:#F0F0F0'><span style=3D'font-size:10.0pt;font-family:"Courier New";color=
:black'>bnx2: eth0: BNX2_RV2P_MFTQ_CTL 4000<o:p></o:p></span></p><p class=
=3DMsoNormal style=3D'line-height:15.6pt;background:#F0F0F0'><span style=3D=
'font-size:10.0pt;font-family:"Courier New";color:black'>bnx2: eth0: BNX2_T=
BDR_FTQ_CTL 4002<o:p></o:p></span></p><p class=3DMsoNormal style=3D'line-he=
ight:15.6pt;background:#F0F0F0'><span style=3D'font-size:10.0pt;font-family=
:"Courier New";color:black'>bnx2: eth0: BNX2_TDMA_FTQ_CTL 10002<o:p></o:p><=
/span></p><p class=3DMsoNormal style=3D'line-height:15.6pt;background:#F0F0=
F0'><span style=3D'font-size:10.0pt;font-family:"Courier New";color:black'>=
bnx2: eth0: BNX2_TXP_FTQ_CTL 10000<o:p></o:p></span></p><p class=3DMsoNorma=
l><b><span style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></b></p><p cl=
ass=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Is this the probl=
em because of &nbsp;cpu states enabled in intel processor (as addressed ear=
lier) or there is something related to Broadcom driver bnx2 as well.<o:p></=
o:p></p><p class=3DMsoNormal>Can I get a patch or any information regarding=
 this.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DM=
soNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:=
p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><b><sp=
an style=3D'font-family:"Cambria","serif"'>Thanks &amp; Regards,<o:p></o:p>=
</span></b></p><p class=3DMsoNormal><b><span style=3D'font-family:"Cambria"=
,"serif"'>PANKAJ KUMAR BISWAS<o:p></o:p></span></b></p><p class=3DMsoNormal=
><b><span style=3D'font-family:"Cambria","serif"'><o:p>&nbsp;</o:p></span><=
/b></p><p class=3DMsoNormal><b><span style=3D'font-family:"Cambria","serif"=
'>Software Maintenance Engineer | XenServer India | Citrix Systems Inc.<o:p=
></o:p></span></b></p><p class=3DMsoNormal><b><span style=3D'font-family:"C=
ambria","serif"'>Ext. 41225 | Email:&nbsp; pankaj.kumarbiswas@citrix.com<o:=
p></o:p></span></b></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></bo=
dy></html>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904127BANPMAILBOX01_--


--===============5435395389758834695==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5435395389758834695==--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 10:36:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 10:36:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSREY-0004tR-J5; Mon, 21 Nov 2011 10:36:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSREX-0004tH-Eu
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 10:36:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1321871749!2379764!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11192 invoked from network); 21 Nov 2011 10:35:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 10:35:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9035860"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 10:35:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 10:35:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Mon, 21 Nov 2011 10:35:48 +0000
In-Reply-To: <4ECA1F13.3060903@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
	<20111118135221.GC12433@phenom.dumpdata.com>
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>
	<4EC6837F.1050201@oracle.com>
	<20111118180500.GA19469@phenom.dumpdata.com>
	<4ECA1F13.3060903@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321871748.3664.375.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
 implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-21 at 09:51 +0000, ANNIE LI wrote:
> > The idea is just to have one function. Whichever prints the
> > string and panics the machine. If 'panic' does this properly
> > (and properly meaning it actually prints data when using
> > the earlyprintk=xen as well as console=hvc0) printout system
> > the we cuold just use 'panic' and not worry about it.
> >
> >
> > But if it does not, then we (and by we I mean you) should
> > provide a variant of panic() that prints the data properly using the
> > earlprintk mechanism. Preferrabily to make it generic.
> I did a simple test, a serial cable was connected,  and console=hvc0 was 
> added in grub.conf.
> Whether earlyprintk=xen is set or not, both panic() and xen_raw_printk 
> all can print out strings in gnttab_request_version of grant-table.c.
> 
> So I changed the
> 
> xen_raw_printk();
> panic();
> 
> back to
> 
> panic();

> Other change is the re-arrange "else if" format in 
> gnttab_request_version function.

Neither of these changes are in the attached patch, did you resend an
old one by mistake?

I think a fresh reposting of the series is in order, at least I've
rather lost track of which patches are the most recent ones in this
thread.

Ian.

> 
> Please refer to the patch attached.
> 
> Thanks
> Annie



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 10:36:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 10:36:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSREY-0004tR-J5; Mon, 21 Nov 2011 10:36:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSREX-0004tH-Eu
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 10:36:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1321871749!2379764!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11192 invoked from network); 21 Nov 2011 10:35:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 10:35:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9035860"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 10:35:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 10:35:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Mon, 21 Nov 2011 10:35:48 +0000
In-Reply-To: <4ECA1F13.3060903@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>
	<4EC62FE5.2080608@oracle.com>
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>
	<20111118135221.GC12433@phenom.dumpdata.com>
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>
	<4EC6837F.1050201@oracle.com>
	<20111118180500.GA19469@phenom.dumpdata.com>
	<4ECA1F13.3060903@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321871748.3664.375.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
 implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-21 at 09:51 +0000, ANNIE LI wrote:
> > The idea is just to have one function. Whichever prints the
> > string and panics the machine. If 'panic' does this properly
> > (and properly meaning it actually prints data when using
> > the earlyprintk=xen as well as console=hvc0) printout system
> > the we cuold just use 'panic' and not worry about it.
> >
> >
> > But if it does not, then we (and by we I mean you) should
> > provide a variant of panic() that prints the data properly using the
> > earlprintk mechanism. Preferrabily to make it generic.
> I did a simple test, a serial cable was connected,  and console=hvc0 was 
> added in grub.conf.
> Whether earlyprintk=xen is set or not, both panic() and xen_raw_printk 
> all can print out strings in gnttab_request_version of grant-table.c.
> 
> So I changed the
> 
> xen_raw_printk();
> panic();
> 
> back to
> 
> panic();

> Other change is the re-arrange "else if" format in 
> gnttab_request_version function.

Neither of these changes are in the attached patch, did you resend an
old one by mistake?

I think a fresh reposting of the series is in order, at least I've
rather lost track of which patches are the most recent ones in this
thread.

Ian.

> 
> Please refer to the patch attached.
> 
> Thanks
> Annie



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 10:37:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 10:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSRFR-0004ww-2M; Mon, 21 Nov 2011 10:37:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSRFP-0004wY-Nm
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 10:37:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1321871804!5058796!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10947 invoked from network); 21 Nov 2011 10:36:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 10:36:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9035893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 10:36:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 10:36:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Mon, 21 Nov 2011 10:36:36 +0000
In-Reply-To: <4ECA1F0D.5070303@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<4EC62E77.7090007@oracle.com>
	<1321613689.3664.305.camel@zakaz.uk.xensource.com>
	<4EC6818B.3010904@oracle.com>
	<1321632271.3664.367.camel@zakaz.uk.xensource.com>
	<4ECA1F0D.5070303@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321871797.3664.376.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
 V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-21 at 09:51 +0000, ANNIE LI wrote:
> This patch changes two places from the last one,
> * removing gnttab_v1_ops
> * change update_grant_entry_v1 into gnttab_update_entry_v1

The attached patch didn't have those changes.

Ian.

> 
> Thanks
> Annie
> 
> On 2011-11-19 0:04, Ian Campbell wrote:
> >>>> +static struct gnttab_ops gnttab_v1_ops = {
> >>>> +       .map_frames                     = gnttab_map_frames_v1,
> >>>> +       .unmap_frames                   = gnttab_unmap_frames_v1,
> >>>> +       .update_entry                   = update_grant_entry_v1,
> >>>>
> >>> Any reason this one is not gnttab_foo?
> >>>
> >> Actually no, just keep the original name of this function. I'd like to
> >> change it, maybe gnttab_update_entry_v1 is better?
> > I think so. Similarly for the v2 variant.
> >
> > Ian.
> >
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 10:37:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 10:37:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSRFR-0004ww-2M; Mon, 21 Nov 2011 10:37:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSRFP-0004wY-Nm
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 10:37:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1321871804!5058796!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10947 invoked from network); 21 Nov 2011 10:36:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 10:36:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9035893"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 10:36:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 10:36:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: ANNIE LI <annie.li@oracle.com>
Date: Mon, 21 Nov 2011 10:36:36 +0000
In-Reply-To: <4ECA1F0D.5070303@oracle.com>
References: <4EC3B62F.6080702@oracle.com>
	<1321451304-13559-1-git-send-email-annie.li@oracle.com>
	<4EC62E77.7090007@oracle.com>
	<1321613689.3664.305.camel@zakaz.uk.xensource.com>
	<4EC6818B.3010904@oracle.com>
	<1321632271.3664.367.camel@zakaz.uk.xensource.com>
	<4ECA1F0D.5070303@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321871797.3664.376.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xen/granttable: Introducing grant table
 V2 stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-21 at 09:51 +0000, ANNIE LI wrote:
> This patch changes two places from the last one,
> * removing gnttab_v1_ops
> * change update_grant_entry_v1 into gnttab_update_entry_v1

The attached patch didn't have those changes.

Ian.

> 
> Thanks
> Annie
> 
> On 2011-11-19 0:04, Ian Campbell wrote:
> >>>> +static struct gnttab_ops gnttab_v1_ops = {
> >>>> +       .map_frames                     = gnttab_map_frames_v1,
> >>>> +       .unmap_frames                   = gnttab_unmap_frames_v1,
> >>>> +       .update_entry                   = update_grant_entry_v1,
> >>>>
> >>> Any reason this one is not gnttab_foo?
> >>>
> >> Actually no, just keep the original name of this function. I'd like to
> >> change it, maybe gnttab_update_entry_v1 is better?
> > I think so. Similarly for the v2 variant.
> >
> > Ian.
> >
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 10:53:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 10:53:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSRUu-0005Oc-SR; Mon, 21 Nov 2011 10:53:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RSRUs-0005OX-Vz
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 10:53:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321872763!5090520!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13513 invoked from network); 21 Nov 2011 10:52:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 10:52:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9036505"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 10:52:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 10:52:43 +0000
Date: Mon, 21 Nov 2011 10:53:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111120182951.GA4830@aepfle.de>
Message-ID: <alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 20 Nov 2011, Olaf Hering wrote:
> On Mon, Nov 07, Stefano Stabellini wrote:
> 
> > On Mon, 7 Nov 2011, Olaf Hering wrote:
> > > > If tot_memkb is the pod target of the domain, we should be coherent and
> > > > set it equal to target_memkb when paging is inactive.
> > > 
> > > So far PoD and paging are unrelated and mean different things.
> > > I think the difference between max_memkb and tot_memkb could be the
> > > trigger to start paging.
> > 
> > Yes, I think it would be better.
> 
> I have to disagree here.
> 
> After looking at the code in parse_config_data(), tot_memkb is only set
> if actmem= is listed in the configfile. And if actmem= is set, its the
> trigger to run xenpaging and let it work toward the specified number.
> So checking for a non-null tot_memkb in create_xenpaging() looks like
> the correct way to me to decide wether xenpaging should be started.

what if tot_memkb is bigger than target_memkb? Or even bigger than
max_memkb?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 10:53:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 10:53:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSRUu-0005Oc-SR; Mon, 21 Nov 2011 10:53:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RSRUs-0005OX-Vz
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 10:53:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321872763!5090520!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13513 invoked from network); 21 Nov 2011 10:52:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 10:52:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9036505"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 10:52:43 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 10:52:43 +0000
Date: Mon, 21 Nov 2011 10:53:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111120182951.GA4830@aepfle.de>
Message-ID: <alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 20 Nov 2011, Olaf Hering wrote:
> On Mon, Nov 07, Stefano Stabellini wrote:
> 
> > On Mon, 7 Nov 2011, Olaf Hering wrote:
> > > > If tot_memkb is the pod target of the domain, we should be coherent and
> > > > set it equal to target_memkb when paging is inactive.
> > > 
> > > So far PoD and paging are unrelated and mean different things.
> > > I think the difference between max_memkb and tot_memkb could be the
> > > trigger to start paging.
> > 
> > Yes, I think it would be better.
> 
> I have to disagree here.
> 
> After looking at the code in parse_config_data(), tot_memkb is only set
> if actmem= is listed in the configfile. And if actmem= is set, its the
> trigger to run xenpaging and let it work toward the specified number.
> So checking for a non-null tot_memkb in create_xenpaging() looks like
> the correct way to me to decide wether xenpaging should be started.

what if tot_memkb is bigger than target_memkb? Or even bigger than
max_memkb?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 10:53:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 10:53:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSRVK-0005Pd-Ap; Mon, 21 Nov 2011 10:53:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSRVI-0005PL-Jm
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 10:53:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1321872789!5075040!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6734 invoked from network); 21 Nov 2011 10:53:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 10:53:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 21 Nov 2011 10:53:08 +0000
Message-Id: <4ECA3BA002000078000620FC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 21 Nov 2011 10:53:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] x86: re-inject emulated level pirqs in
 PV on HVM guests if still asserted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 18.11.11 at 12:13, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> This patch is a backport of CS 24007 for xen-4.1-testing.
> 
> PV on HVM guests can loose level interrupts coming from emulated
> devices if they have been remapped onto event channels.  The reason is
> that we are missing the code to inject a pirq again in the guest when
> the guest EOIs it, if it corresponds to an emulated level interrupt
> and the interrupt is still asserted.
> 
> Fix this issue and also return error when the guest tries to get the
> irq_status of a non-existing pirq.
> 
> 
> Changes in v2:
> 
> - move the spinlock afterward to cover the new code only.

This, as expected, doesn't hang anymore with kernels making use of
the PIRQ EOI map.

Jan

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Jan Beulich <JBeulich@suse.com>
> 
> 
> diff -r e73ada19a69d xen/arch/x86/physdev.c
> --- a/xen/arch/x86/physdev.c	Thu Nov 17 09:13:25 2011 +0000
> +++ b/xen/arch/x86/physdev.c	Fri Nov 18 09:42:03 2011 +0000
> @@ -268,6 +268,20 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              ret = pirq_guest_eoi(v->domain, eoi.irq);
>          else
>              ret = 0;
> +        spin_lock(&v->domain->event_lock);
> +        if ( is_hvm_domain(v->domain) &&
> +                domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 )
> +        {
> +            struct hvm_irq *hvm_irq = &v->domain->arch.hvm_domain.irq;
> +            int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq);
> +
> +            /* if this is a level irq and count > 0, send another
> +             * notification */ 
> +            if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */
> +                    && hvm_irq->gsi_assert_count[gsi] )
> +                send_guest_pirq(v->domain, eoi.irq);
> +        }
> +        spin_unlock(&v->domain->event_lock);
>          break;
>      }
>  
> @@ -323,9 +337,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              break;
>          irq_status_query.flags = 0;
>          if ( is_hvm_domain(v->domain) &&
> -             domain_pirq_to_irq(v->domain, irq) <= 0 )
> +                domain_pirq_to_irq(v->domain, irq) <= 0 &&
> +                domain_pirq_to_emuirq(v->domain, irq) == IRQ_UNBOUND )
>          {
> -            ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0;
> +            ret = -EINVAL;
>              break;
>          }
>  




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 10:53:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 10:53:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSRVK-0005Pd-Ap; Mon, 21 Nov 2011 10:53:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSRVI-0005PL-Jm
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 10:53:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1321872789!5075040!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6734 invoked from network); 21 Nov 2011 10:53:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 10:53:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 21 Nov 2011 10:53:08 +0000
Message-Id: <4ECA3BA002000078000620FC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 21 Nov 2011 10:53:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] x86: re-inject emulated level pirqs in
 PV on HVM guests if still asserted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 18.11.11 at 12:13, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> This patch is a backport of CS 24007 for xen-4.1-testing.
> 
> PV on HVM guests can loose level interrupts coming from emulated
> devices if they have been remapped onto event channels.  The reason is
> that we are missing the code to inject a pirq again in the guest when
> the guest EOIs it, if it corresponds to an emulated level interrupt
> and the interrupt is still asserted.
> 
> Fix this issue and also return error when the guest tries to get the
> irq_status of a non-existing pirq.
> 
> 
> Changes in v2:
> 
> - move the spinlock afterward to cover the new code only.

This, as expected, doesn't hang anymore with kernels making use of
the PIRQ EOI map.

Jan

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Jan Beulich <JBeulich@suse.com>
> 
> 
> diff -r e73ada19a69d xen/arch/x86/physdev.c
> --- a/xen/arch/x86/physdev.c	Thu Nov 17 09:13:25 2011 +0000
> +++ b/xen/arch/x86/physdev.c	Fri Nov 18 09:42:03 2011 +0000
> @@ -268,6 +268,20 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              ret = pirq_guest_eoi(v->domain, eoi.irq);
>          else
>              ret = 0;
> +        spin_lock(&v->domain->event_lock);
> +        if ( is_hvm_domain(v->domain) &&
> +                domain_pirq_to_emuirq(v->domain, eoi.irq) > 0 )
> +        {
> +            struct hvm_irq *hvm_irq = &v->domain->arch.hvm_domain.irq;
> +            int gsi = domain_pirq_to_emuirq(v->domain, eoi.irq);
> +
> +            /* if this is a level irq and count > 0, send another
> +             * notification */ 
> +            if ( gsi >= NR_ISAIRQS /* ISA irqs are edge triggered */
> +                    && hvm_irq->gsi_assert_count[gsi] )
> +                send_guest_pirq(v->domain, eoi.irq);
> +        }
> +        spin_unlock(&v->domain->event_lock);
>          break;
>      }
>  
> @@ -323,9 +337,10 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              break;
>          irq_status_query.flags = 0;
>          if ( is_hvm_domain(v->domain) &&
> -             domain_pirq_to_irq(v->domain, irq) <= 0 )
> +                domain_pirq_to_irq(v->domain, irq) <= 0 &&
> +                domain_pirq_to_emuirq(v->domain, irq) == IRQ_UNBOUND )
>          {
> -            ret = copy_to_guest(arg, &irq_status_query, 1) ? -EFAULT : 0;
> +            ret = -EINVAL;
>              break;
>          }
>  




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:05:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSRgO-0005kf-I8; Mon, 21 Nov 2011 11:05:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RSRgN-0005ka-G7
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:05:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1321873475!3939976!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23366 invoked from network); 21 Nov 2011 11:04:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:04:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9036827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 11:04:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 11:04:35 +0000
Date: Mon, 21 Nov 2011 11:05:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony Liguori <anthony@codemonkey.ws>
In-Reply-To: <4EC671AF.5030805@codemonkey.ws>
Message-ID: <alpine.DEB.2.00.1111211054500.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>
	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EC27D0D.3040204@codemonkey.ws>
	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
	<alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
	<4EC671AF.5030805@codemonkey.ws>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "agraf@suse.de" <agraf@suse.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 18 Nov 2011, Anthony Liguori wrote:
> On 11/18/2011 05:46 AM, Stefano Stabellini wrote:
> > On Tue, 15 Nov 2011, Stefano Stabellini wrote:
> >> On Tue, 15 Nov 2011, Anthony Liguori wrote:
> >>> On 11/15/2011 08:51 AM, stefano.stabellini@eu.citrix.com wrote:
> >>>> From: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> >>>>
> >>>> Xen doesn't need full RTC emulation in Qemu because the RTC is already
> >>>> emulated by the hypervisor. In particular we want to avoid the timers
> >>>> initialization so that Qemu doesn't need to wake up needlessly.
> >>>>
> >>>> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> >>>
> >>> Yuck.  There's got to be a better way to do this.
> >>
> >> Yeah, it is pretty ugly, I was hoping in some good suggestions to
> >> improve this patch :)
> >>
> >>
> >>> I think it would be better to name timers and then in Xen specific machine code,
> >>> disable the RTC timers.
> >>
> >> Good idea!
> >> I was thinking that I could implement an rtc_stop function in
> >> mc146818rtc.c that stops and frees the timers.
> >>
> >> Now the problem is that from xen-all.c I cannot easily find the
> >> ISADevice instance to pass to rtc_stop. Do you think it would be
> >> reasonable to call rtc_stop from pc_basic_device_init, inside the same
> >> if (!xen_available()) introduce by the next patch?
> >>
> >> Otherwise I could implement functions to walk the isa bus, similarly to
> >> pci_for_each_device.
> >>
> >
> > ping?
> 
> Thinking more about it, I think this entire line of thinking is wrong (including 
> mine) :-)

Actually I quite liked your suggestion of stopping the rtc_clock: the
patch becomes a one-liner in xen-all!


> The problem you're trying to solve is that the RTC fires two 1 second timers 
> regardless of whether the guest is reading the wall clock time, right?  And 
> since wall clock time is never read from the QEMU RTC in Xen, it's a huge waste?

The real problem I am trying to solve is that I don't need an RTC clock
in Qemu. However it is not easy to disentangle the RTC emulation from
the rest of the system (see rtc_state in pc.c and pc_piix.c). So I would
be happy enough with just getting rid of the timers.


> The Right Solution would be to modify the RTC emulation such that it did a 
> qemu_get_clock() during read of the CMOS registers in order to ensure the time 
> was up to date (instead of using 1 second timers).
> 
> Then the timers wouldn't even exist anymore.

That would be one way of doing it, however the timers don't only update
a clock variable, so removing them is certainly non-trivial and could
have unintended consequences. I am not sure it is worth it in this
context.
BTW the RTC emulation in Xen also has two timers.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:05:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:05:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSRgO-0005kf-I8; Mon, 21 Nov 2011 11:05:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RSRgN-0005ka-G7
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:05:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1321873475!3939976!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23366 invoked from network); 21 Nov 2011 11:04:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:04:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9036827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 11:04:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 11:04:35 +0000
Date: Mon, 21 Nov 2011 11:05:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony Liguori <anthony@codemonkey.ws>
In-Reply-To: <4EC671AF.5030805@codemonkey.ws>
Message-ID: <alpine.DEB.2.00.1111211054500.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>
	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EC27D0D.3040204@codemonkey.ws>
	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>
	<alpine.DEB.2.00.1111181145500.3519@kaball-desktop>
	<4EC671AF.5030805@codemonkey.ws>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "agraf@suse.de" <agraf@suse.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 18 Nov 2011, Anthony Liguori wrote:
> On 11/18/2011 05:46 AM, Stefano Stabellini wrote:
> > On Tue, 15 Nov 2011, Stefano Stabellini wrote:
> >> On Tue, 15 Nov 2011, Anthony Liguori wrote:
> >>> On 11/15/2011 08:51 AM, stefano.stabellini@eu.citrix.com wrote:
> >>>> From: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> >>>>
> >>>> Xen doesn't need full RTC emulation in Qemu because the RTC is already
> >>>> emulated by the hypervisor. In particular we want to avoid the timers
> >>>> initialization so that Qemu doesn't need to wake up needlessly.
> >>>>
> >>>> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> >>>
> >>> Yuck.  There's got to be a better way to do this.
> >>
> >> Yeah, it is pretty ugly, I was hoping in some good suggestions to
> >> improve this patch :)
> >>
> >>
> >>> I think it would be better to name timers and then in Xen specific machine code,
> >>> disable the RTC timers.
> >>
> >> Good idea!
> >> I was thinking that I could implement an rtc_stop function in
> >> mc146818rtc.c that stops and frees the timers.
> >>
> >> Now the problem is that from xen-all.c I cannot easily find the
> >> ISADevice instance to pass to rtc_stop. Do you think it would be
> >> reasonable to call rtc_stop from pc_basic_device_init, inside the same
> >> if (!xen_available()) introduce by the next patch?
> >>
> >> Otherwise I could implement functions to walk the isa bus, similarly to
> >> pci_for_each_device.
> >>
> >
> > ping?
> 
> Thinking more about it, I think this entire line of thinking is wrong (including 
> mine) :-)

Actually I quite liked your suggestion of stopping the rtc_clock: the
patch becomes a one-liner in xen-all!


> The problem you're trying to solve is that the RTC fires two 1 second timers 
> regardless of whether the guest is reading the wall clock time, right?  And 
> since wall clock time is never read from the QEMU RTC in Xen, it's a huge waste?

The real problem I am trying to solve is that I don't need an RTC clock
in Qemu. However it is not easy to disentangle the RTC emulation from
the rest of the system (see rtc_state in pc.c and pc_piix.c). So I would
be happy enough with just getting rid of the timers.


> The Right Solution would be to modify the RTC emulation such that it did a 
> qemu_get_clock() during read of the CMOS registers in order to ensure the time 
> was up to date (instead of using 1 second timers).
> 
> Then the timers wouldn't even exist anymore.

That would be one way of doing it, however the timers don't only update
a clock variable, so removing them is certainly non-trivial and could
have unintended consequences. I am not sure it is worth it in this
context.
BTW the RTC emulation in Xen also has two timers.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:06:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:06:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSRhg-0005pu-6w; Mon, 21 Nov 2011 11:06:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RSRhe-0005pT-Nd
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:06:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1321873555!2387499!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16224 invoked from network); 21 Nov 2011 11:05:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:05:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9036868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 11:05:54 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 11:05:54 +0000
Date: Mon, 21 Nov 2011 11:06:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4ECA3BA002000078000620FC@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1111211106110.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
	<4ECA3BA002000078000620FC@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] x86: re-inject emulated level pirqs in
 PV on HVM guests if still asserted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 21 Nov 2011, Jan Beulich wrote:
> >>> On 18.11.11 at 12:13, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > This patch is a backport of CS 24007 for xen-4.1-testing.
> > 
> > PV on HVM guests can loose level interrupts coming from emulated
> > devices if they have been remapped onto event channels.  The reason is
> > that we are missing the code to inject a pirq again in the guest when
> > the guest EOIs it, if it corresponds to an emulated level interrupt
> > and the interrupt is still asserted.
> > 
> > Fix this issue and also return error when the guest tries to get the
> > irq_status of a non-existing pirq.
> > 
> > 
> > Changes in v2:
> > 
> > - move the spinlock afterward to cover the new code only.
> 
> This, as expected, doesn't hang anymore with kernels making use of
> the PIRQ EOI map.

Thanks for testing!
Keir, are you happy with the patch?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:06:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:06:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSRhg-0005pu-6w; Mon, 21 Nov 2011 11:06:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RSRhe-0005pT-Nd
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:06:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1321873555!2387499!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16224 invoked from network); 21 Nov 2011 11:05:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:05:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9036868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 11:05:54 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 11:05:54 +0000
Date: Mon, 21 Nov 2011 11:06:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4ECA3BA002000078000620FC@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1111211106110.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111180943260.3519@kaball-desktop>
	<4ECA3BA002000078000620FC@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] x86: re-inject emulated level pirqs in
 PV on HVM guests if still asserted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 21 Nov 2011, Jan Beulich wrote:
> >>> On 18.11.11 at 12:13, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> wrote:
> > This patch is a backport of CS 24007 for xen-4.1-testing.
> > 
> > PV on HVM guests can loose level interrupts coming from emulated
> > devices if they have been remapped onto event channels.  The reason is
> > that we are missing the code to inject a pirq again in the guest when
> > the guest EOIs it, if it corresponds to an emulated level interrupt
> > and the interrupt is still asserted.
> > 
> > Fix this issue and also return error when the guest tries to get the
> > irq_status of a non-existing pirq.
> > 
> > 
> > Changes in v2:
> > 
> > - move the spinlock afterward to cover the new code only.
> 
> This, as expected, doesn't hang anymore with kernels making use of
> the PIRQ EOI map.

Thanks for testing!
Keir, are you happy with the patch?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:38:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:38:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSBx-0006Qc-U8; Mon, 21 Nov 2011 11:37:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSSBv-0006QX-S5
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:37:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1321875432!2391210!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15463 invoked from network); 21 Nov 2011 11:37:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:37:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9037860"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 11:37:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 11:37:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSSBT-000460-1w; Mon, 21 Nov 2011 11:37:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSSBT-0008Qe-19;
	Mon, 21 Nov 2011 11:37:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20170.14311.24009.221731@mariner.uk.xensource.com>
Date: Mon, 21 Nov 2011 11:37:11 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	(Xen.org)" <keir@xen.org>, Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <E1RSKkc-0002KL-LB@woking.xci-test.com>
References: <E1RSKkc-0002KL-LB@woking.xci-test.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel"):
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-rhel6hvm-intel
> test redhat-install
> 
> Tree: linux git://github.com/jsgf/linux-xen.git
> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>   Bug introduced:  7a9a1261a6b0
>   Bug not present: 9a1a71f7bef2

This seems to have completely broken HVM ...

>   changeset:   24163:7a9a1261a6b0
>   user:        Jean Guyader <jean.guyader@eu.citrix.com>
>   date:        Fri Nov 18 13:41:33 2011 +0000
>       
>       add_to_physmap: Move the code for XENMEM_add_to_physmap
>       
>       Move the code for the XENMEM_add_to_physmap case into it's own
>       function (xenmem_add_to_physmap).
>       
>       Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>       Committed-by: Keir Fraser <keir@xen.org>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:38:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:38:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSBx-0006Qc-U8; Mon, 21 Nov 2011 11:37:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSSBv-0006QX-S5
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:37:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1321875432!2391210!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15463 invoked from network); 21 Nov 2011 11:37:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:37:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,546,1315180800"; 
   d="scan'208";a="9037860"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 11:37:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 11:37:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSSBT-000460-1w; Mon, 21 Nov 2011 11:37:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSSBT-0008Qe-19;
	Mon, 21 Nov 2011 11:37:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20170.14311.24009.221731@mariner.uk.xensource.com>
Date: Mon, 21 Nov 2011 11:37:11 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	(Xen.org)" <keir@xen.org>, Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <E1RSKkc-0002KL-LB@woking.xci-test.com>
References: <E1RSKkc-0002KL-LB@woking.xci-test.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel"):
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-rhel6hvm-intel
> test redhat-install
> 
> Tree: linux git://github.com/jsgf/linux-xen.git
> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>   Bug introduced:  7a9a1261a6b0
>   Bug not present: 9a1a71f7bef2

This seems to have completely broken HVM ...

>   changeset:   24163:7a9a1261a6b0
>   user:        Jean Guyader <jean.guyader@eu.citrix.com>
>   date:        Fri Nov 18 13:41:33 2011 +0000
>       
>       add_to_physmap: Move the code for XENMEM_add_to_physmap
>       
>       Move the code for the XENMEM_add_to_physmap case into it's own
>       function (xenmem_add_to_physmap).
>       
>       Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>       Committed-by: Keir Fraser <keir@xen.org>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:42:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:42:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSGe-0006er-PK; Mon, 21 Nov 2011 11:42:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RSSGd-0006dt-Fp
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:42:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1321875721!2376134!1
X-Originating-IP: [209.85.210.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9811 invoked from network); 21 Nov 2011 11:42:03 -0000
Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com)
	(209.85.210.49)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:42:03 -0000
Received: by pzk6 with SMTP id 6so15267538pzk.8
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 03:42:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ZIJ7GWT2ka6ycOm8hexOYYPoqmQ6BLqMRwrNzA+WCbg=;
	b=slc2RCWkGlS74OgCwUtVLvj81F5+Z40Ff2mifljoO78Hzdxqm0/DrmxrauQenXXq3b
	k2cBPr67KDk17B9fGhFQ7t4mp0SCfpYBeDD13CaR8LxIUJpzEqDYP71Nl3pOmR8wAR0A
	0CUs0qqxy37Njk4jI9Sa2aYr9l0k38TEPIi9o=
MIME-Version: 1.0
Received: by 10.68.25.198 with SMTP id e6mr30369945pbg.19.1321875721584; Mon,
	21 Nov 2011 03:42:01 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Mon, 21 Nov 2011 03:42:01 -0800 (PST)
In-Reply-To: <1321623730.3664.352.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<1d81d1c4c851c0b07696.1321617582@loki.upc.es>
	<1321623730.3664.352.camel@zakaz.uk.xensource.com>
Date: Mon, 21 Nov 2011 12:42:01 +0100
X-Google-Sender-Auth: M4fsclsIA9QolLed-Q1BjgJQvig
Message-ID: <CAPLaKK5JF1NeXkq4zkZtaSjvOfY=VrsrvJ-YHE+aFXd1+pkAgw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8xOCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBG
cmksIDIwMTEtMTEtMTggYXQgMTE6NTkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzE3Mzg2MzM1IC03MjAwCj4+ICMgTm9kZSBJRCAx
ZDgxZDFjNGM4NTFjMGIwNzY5NjM3MzMwNDgwMWRmNTZhMjIxZTkwCj4+ICMgUGFyZW50IMKgNGFk
OTk4ZmRkYjE2YTI5OWNiMjMwZWEyM2JhOTQ0ZDg0YWRiZDJiZgo+PiBsaWJ4bDogZXhlY3V0ZSBo
b3RwbHVnIHNjcmlwdHMgZGlyZWN0bHkgZnJvbSBsaWJ4bC4KPj4KPj4gQWRkZWQgdGhlIG5lY2Vz
c2FyeSBoYW5kbGVycyB0byBleGVjdXRlIGhvdHBsdWcgc2NyaXB0cyB3aGVuIG5lY2Vzc2FyeQo+
PiBmcm9tIGxpYnhsLiBTcGxpdCBOZXRCU0QgYW5kIExpbnV4IGhvdHBsdWcgY2FsbHMgaW50byB0
d28gc2VwYXJhdGUKPj4gZmlsZXMsIGJlY2F1c2UgcGFyYW1ldGVycyBmb3IgaG90cGx1ZyBzY3Jp
cHRzIGFyZSBkaWZmZXJlbnQuIExpbnV4Cj4+IGhhcyBlbXB0eSBmdW5jdGlvbnMsIHNpbmNlIHRo
ZSBjYWxsaW5nIG9mIGhvdHBsdWcgc2NyaXB0cyBpcyBzdGlsbAo+PiBkb25lIHVzaW5nIHVkZXYu
Cj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVw
Yy5lZHU+Cj4+Cj4+IGRpZmYgLXIgNGFkOTk4ZmRkYjE2IC1yIDFkODFkMWM0Yzg1MSB0b29scy9s
aWJ4bC9NYWtlZmlsZQo+PiAtLS0gYS90b29scy9saWJ4bC9NYWtlZmlsZSDCoCDCoCDCoEZyaSBO
b3YgMTggMTE6Mjk6MTQgMjAxMSArMDEwMAo+PiArKysgYi90b29scy9saWJ4bC9NYWtlZmlsZSDC
oCDCoCDCoEZyaSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSArMDIwMAo+PiBAQCAtMzQsOCArMzQsMTAg
QEAgTElCWExfT0JKUy0kKENPTkZJR19JQTY0KSArPSBsaWJ4bF9ub2NwdQo+Cj4gU2hvdWxkIGJl
Ogo+Cj4+IMKgaWZlcSAoJChDT05GSUdfTmV0QlNEKSx5KQo+PiDCoExJQlhMX09CSlMteSArPSBs
aWJ4bF9waHliYWNrZW5kLm8KPj4gK0xJQlhMX09CSlMteSArPSBob3RwbHVnX25ldGJzZC5vCj4g
wqAgZWxzaWYgKCQoQ09ORklHX0xpbnV4KSx5KQo+PiDCoExJQlhMX09CSlMteSArPSBsaWJ4bF9u
b3BoeWJhY2tlbmQubwo+PiArTElCWExfT0JKUy15ICs9IGhvdHBsdWdfbGludXgubwo+IMKgIGVs
c2UKPiDCoCAkKGVycm9yIEEgbWVzc2FnZSBvZiBzb21lIHNvcnQpCj4+IMKgZW5kaWYKCkRvbmUs
IEkndmUgbW92ZWQgUEhZIGJhY2tlbmQgc2VsZWN0aW9uIGFuZCBob3RwbHVnIHNwZWNpZmljIGZ1
bmN0aW9ucwp0byBsaWJ4bF9uZXRic2QuYyBhbmQgbGlieGxfbGludXguYywgYW5kIGFkZGVkIGFu
IGVycm9yIG1lc3NhZ2UgaW4KY2FzZSBzb21lb25lIHRyaWVzIHRvIHVzZSBhIGRpZmZlcmVudCBP
Uy4KCj4+IGRpZmYgLXIgNGFkOTk4ZmRkYjE2IC1yIDFkODFkMWM0Yzg1MSB0b29scy9saWJ4bC9s
aWJ4bF9kZXZpY2UuYwo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYyDCoCDCoCDC
oCDCoEZyaSBOb3YgMTggMTE6Mjk6MTQgMjAxMSArMDEwMAo+PiArKysgYi90b29scy9saWJ4bC9s
aWJ4bF9kZXZpY2UuYyDCoCDCoCDCoCDCoEZyaSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSArMDIwMAo+
PiBAQCAtNjgsNiArNjgsMjQgQEAgaW50IGxpYnhsX19wYXJzZV9iYWNrZW5kX3BhdGgobGlieGxf
X2djCj4+IMKgIMKgIMKgcmV0dXJuIGxpYnhsX19kZXZpY2Vfa2luZF9mcm9tX3N0cmluZyhzdHJr
aW5kLCAmZGV2LT5iYWNrZW5kX2tpbmQpOwo+PiDCoH0KPj4KPj4gK2ludCBsaWJ4bF9fZGV2aWNl
X2V4ZWN1dGVfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdjLCBsaWJ4bF9fZGV2aWNlICpkZXYpCj4KPiBO
byBuZWVkIGZvciBhIGFkZC9yZW1vdmUgdHlwZSBwYXJhbWV0ZXI/CgpBbHRob3VnaCB5b3UgY291
bGQgcGFzcyB0aGlzIGtpbmQgb2YgcGFyYW1ldGVyLCB0aGUgYWN0aW9uIHRvIHBlcmZvcm0KaXMg
YmFzZWQgb24gdGhlIHN0YXRlIG9mIHRoZSBkZXZpY2UgaW4gdGhlIGNvcnJlc3BvbmRpbmcgeGVu
c3RvcmUKZW50cnkuIFN0YXRlIDIgbWVhbnMgdGhhdCB0aGUgZGV2aWNlIHNob3VsZCBiZSBjb25u
ZWN0ZWQsIHN0YXRlIDYKbWVhbnMgdGhlIGRldmljZSBzaG91bGQgYmUgZGlzY29ubmVjdGVkLgoK
Pj4gK3sKPj4gKyDCoCDCoGludCByYyA9IDA7Cj4+ICsKPj4gKyDCoCDCoHN3aXRjaChkZXYtPmtp
bmQpIHsKPj4gKyDCoCDCoGNhc2UgTElCWExfX0RFVklDRV9LSU5EX1ZJRjoKPj4gKyDCoCDCoCDC
oCDCoHJjID0gbGlieGxfX25pY19ob3RwbHVnKGdjLCBkZXYpOwo+PiArIMKgIMKgIMKgIMKgYnJl
YWs7Cj4+ICsgwqAgwqBjYXNlIExJQlhMX19ERVZJQ0VfS0lORF9WQkQ6Cj4+ICsgwqAgwqAgwqAg
wqByYyA9IGxpYnhsX19kaXNrX2hvdHBsdWcoZ2MsIGRldik7Cj4+ICsgwqAgwqAgwqAgwqBicmVh
azsKPj4gKyDCoCDCoGRlZmF1bHQ6Cj4+ICsgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoH0K
Pj4gKwo+PiArIMKgIMKgcmV0dXJuIHJjOwo+PiArfQo+PiArCj4+IMKgaW50IGxpYnhsX19kZXZp
Y2VfZ2VuZXJpY19hZGQobGlieGxfX2djICpnYywgbGlieGxfX2RldmljZSAqZGV2aWNlLAo+PiDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjaGFyICoqYmVudHMs
IGNoYXIgKipmZW50cykKPj4gwqB7Cj4+IEBAIC00NDksNiArNDY3LDcgQEAgaW50IGxpYnhsX19k
ZXZpY2VfcmVtb3ZlKGxpYnhsX19nYyAqZ2MsCj4+IMKgIMKgIMKgaWYgKCFzdGF0ZSkKPj4gwqAg
wqAgwqAgwqAgwqBnb3RvIG91dDsKPj4gwqAgwqAgwqBpZiAoYXRvaShzdGF0ZSkgIT0gNCkgewo+
PiArIMKgIMKgIMKgIMKgbGlieGxfX2RldmljZV9leGVjdXRlX2hvdHBsdWcoZ2MsIGRldik7Cj4+
IMKgIMKgIMKgIMKgIMKgbGlieGxfX2RldmljZV9kZXN0cm95X3RhcGRpc2soZ2MsIGJlX3BhdGgp
Owo+PiDCoCDCoCDCoCDCoCDCoHhzX3JtKGN0eC0+eHNoLCBYQlRfTlVMTCwgYmVfcGF0aCk7Cj4+
IMKgIMKgIMKgIMKgIMKgZ290byBvdXQ7Cj4+IEBAIC00OTIsNiArNTExLDEyIEBAIGludCBsaWJ4
bF9fZGV2aWNlX2Rlc3Ryb3kobGlieGxfX2djICpnYywKPj4gwqAgwqAgwqBjaGFyICpiZV9wYXRo
ID0gbGlieGxfX2RldmljZV9iYWNrZW5kX3BhdGgoZ2MsIGRldik7Cj4+IMKgIMKgIMKgY2hhciAq
ZmVfcGF0aCA9IGxpYnhsX19kZXZpY2VfZnJvbnRlbmRfcGF0aChnYywgZGV2KTsKPj4KPj4gKyDC
oCDCoC8qCj4+ICsgwqAgwqAgKiBSdW4gaG90cGx1ZyBzY3JpcHRzLCB3aGljaCB3aWxsIHByb2Jh
Ymx5IG5vdCBiZSBhYmxlIHRvCj4+ICsgwqAgwqAgKiBleGVjdXRlIHN1Y2Nlc3NmdWxseSBzaW5j
ZSB0aGUgZGV2aWNlIG1heSBzdGlsbCBiZSBwbHVnZ2VkCj4KPiBXaGF0IGRvZXMgdGhpcyBtZWFu
PyBJZiB3ZSBkb24ndCBleHBlY3QgaXQgdG8gd29yayB3aHkgYXJlIHdlIGNhbGxpbmcKPiB0aGVt
PwoKSWYgeW91IGNhbGwgdGhlIGxpYnhsX2RvbWFpbl9kZXN0cm95IGZ1bmN0aW9uIHdpdGggZm9y
Y2UgPT0gMSwgdGhlCmRlc3Ryb3kgcHJvY2VzcyBkb2Vzbid0IHdhaXQgZm9yIGRldmljZXMgdG8g
YmUgZGlzY29ubmVjdGVkLCBidXQgd2UKbWlnaHQgYXMgd2VsbCB0cnkgdG8gZXhlY3V0ZSBob3Rw
bHVnIHNjcmlwdHMsIHNpbmNlIHdlIGRvbid0IGtub3cgdGhlCmFjdHVhbCBzdGF0ZSBvZiB0aGUg
ZGV2aWNlLiBJZiB3ZSBhcmUgbHVja3ksIHRoZSBkZXZpY2UgbWlnaHQgYmUKZGlzY29ubmVjdGVk
IChzdGF0ZSA9PSA2KSwgYW5kIHdlIHNob3VsZCBiZSBhYmxlIHRvIGV4ZWN1dGUgaG90cGx1Zwpz
Y3JpcHRzIHN1Y2Nlc3NmdWxseS4KCj4+ICsgwqAgwqAgKi8KPj4gKyDCoCDCoGxpYnhsX19kZXZp
Y2VfZXhlY3V0ZV9ob3RwbHVnKGdjLCBkZXYpOwo+PiArCj4+IMKgIMKgIMKgeHNfcm0oY3R4LT54
c2gsIFhCVF9OVUxMLCBiZV9wYXRoKTsKPj4gwqAgwqAgwqB4c19ybShjdHgtPnhzaCwgWEJUX05V
TEwsIGZlX3BhdGgpOwo+Pgo+PiBkaWZmIC1yIDRhZDk5OGZkZGIxNiAtciAxZDgxZDFjNGM4NTEg
dG9vbHMvbGlieGwvbGlieGxfaW50ZXJuYWwuaAo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9p
bnRlcm5hbC5oIMKgIMKgIMKgRnJpIE5vdiAxOCAxMToyOToxNCAyMDExICswMTAwCj4+ICsrKyBi
L3Rvb2xzL2xpYnhsL2xpYnhsX2ludGVybmFsLmggwqAgwqAgwqBGcmkgU2VwIDMwIDE0OjM4OjU1
IDIwMTEgKzAyMDAKPj4gQEAgLTI4Nyw2ICsyODcsMzQgQEAgX2hpZGRlbiBpbnQgbGlieGxfX3dh
aXRfZm9yX2RldmljZV9zdGF0ZQo+PiDCoCAqLwo+PiDCoF9oaWRkZW4gaW50IGxpYnhsX190cnlf
cGh5X2JhY2tlbmQobW9kZV90IHN0X21vZGUpOwo+Pgo+PiArLyogaG90cGx1ZyBmdW5jdGlvbnMg
Ki8KPj4gKy8qCj4+ICsgKiBsaWJ4bF9fZGV2aWNlX2V4ZWN1dGVfaG90cGx1ZyAtIGdlbmVyaWMg
ZnVuY3Rpb24gdG8gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdHMKPj4gKyAqIGdjOiBhbGxvY2F0aW9u
IHBvb2wKPj4gKyAqIGRldjogcmVmZXJlbmNlIHRvIHRoZSBkZXZpY2UgdGhhdCBleGVjdXRlcyB0
aGUgaG90cGx1ZyBzY3JpcHRzCj4+ICsgKgo+PiArICogUmV0dXJucyAwIG9uIHN1Y2Nlc3MsIGFu
ZCA8IDAgb24gZXJyb3IuCj4+ICsgKi8KPj4gK19oaWRkZW4gaW50IGxpYnhsX19kZXZpY2VfZXhl
Y3V0ZV9ob3RwbHVnKGxpYnhsX19nYyAqZ2MsIGxpYnhsX19kZXZpY2UgKmRldik7Cj4+ICsKPj4g
Ky8qCj4+ICsgKiBsaWJ4bF9fZGlza19ob3RwbHVnIC0gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdCBm
b3IgYSBkaXNrIHR5cGUgZGV2aWNlCj4+ICsgKiBnYzogYWxsb2NhdGlvbiBwb29sCj4+ICsgKiBk
ZXY6IHJlZmVyZW5jZSB0byB0aGUgZGlzayBkZXZpY2UKPj4gKyAqCj4+ICsgKiBSZXR1cm5zIDAg
b24gc3VjY2VzcywgYW5kIDwgMCBvbiBlcnJvci4KPj4gKyAqLwo+PiArX2hpZGRlbiBpbnQgbGli
eGxfX2Rpc2tfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdjLCBsaWJ4bF9fZGV2aWNlICpkZXYpOwo+PiAr
Cj4+ICsvKgo+PiArICogbGlieGxfX25pY19ob3RwbHVnIC0gZXhlY3V0ZSBob3RwbHVnIHNjcmlw
dCBmb3IgYSBuaWMgdHlwZSBkZXZpY2UKPj4gKyAqIGdjOiBhbGxvY2F0aW9uIHBvb2wKPj4gKyAq
IGRldjogcmVmZXJlbmNlIHRvIHRoZSBuaWMgZGV2aWNlCj4+ICsgKgo+PiArICogUmV0dXJucyAw
IG9uIHN1Y2Nlc3MsIGFuZCA8IDAgb24gZXJyb3IuCj4+ICsgKi8KPj4gK19oaWRkZW4gaW50IGxp
YnhsX19uaWNfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdjLCBsaWJ4bF9fZGV2aWNlICpkZXYpOwo+PiAr
Cj4+IMKgLyogZnJvbSBsaWJ4bF9wY2kgKi8KPj4KPj4gwqBfaGlkZGVuIGludCBsaWJ4bF9fZGV2
aWNlX3BjaV9hZGQobGlieGxfX2djICpnYywgdWludDMyX3QgZG9taWQsIGxpYnhsX2RldmljZV9w
Y2kgKnBjaWRldiwgaW50IHN0YXJ0aW5nKTsKPj4KPj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+PiBYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+PiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwKPgo+Cj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:42:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:42:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSGe-0006er-PK; Mon, 21 Nov 2011 11:42:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RSSGd-0006dt-Fp
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:42:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1321875721!2376134!1
X-Originating-IP: [209.85.210.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9811 invoked from network); 21 Nov 2011 11:42:03 -0000
Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com)
	(209.85.210.49)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:42:03 -0000
Received: by pzk6 with SMTP id 6so15267538pzk.8
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 03:42:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ZIJ7GWT2ka6ycOm8hexOYYPoqmQ6BLqMRwrNzA+WCbg=;
	b=slc2RCWkGlS74OgCwUtVLvj81F5+Z40Ff2mifljoO78Hzdxqm0/DrmxrauQenXXq3b
	k2cBPr67KDk17B9fGhFQ7t4mp0SCfpYBeDD13CaR8LxIUJpzEqDYP71Nl3pOmR8wAR0A
	0CUs0qqxy37Njk4jI9Sa2aYr9l0k38TEPIi9o=
MIME-Version: 1.0
Received: by 10.68.25.198 with SMTP id e6mr30369945pbg.19.1321875721584; Mon,
	21 Nov 2011 03:42:01 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Mon, 21 Nov 2011 03:42:01 -0800 (PST)
In-Reply-To: <1321623730.3664.352.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321617576@loki.upc.es>
	<1d81d1c4c851c0b07696.1321617582@loki.upc.es>
	<1321623730.3664.352.camel@zakaz.uk.xensource.com>
Date: Mon, 21 Nov 2011 12:42:01 +0100
X-Google-Sender-Auth: M4fsclsIA9QolLed-Q1BjgJQvig
Message-ID: <CAPLaKK5JF1NeXkq4zkZtaSjvOfY=VrsrvJ-YHE+aFXd1+pkAgw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8xOCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiBPbiBG
cmksIDIwMTEtMTEtMTggYXQgMTE6NTkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzE3Mzg2MzM1IC03MjAwCj4+ICMgTm9kZSBJRCAx
ZDgxZDFjNGM4NTFjMGIwNzY5NjM3MzMwNDgwMWRmNTZhMjIxZTkwCj4+ICMgUGFyZW50IMKgNGFk
OTk4ZmRkYjE2YTI5OWNiMjMwZWEyM2JhOTQ0ZDg0YWRiZDJiZgo+PiBsaWJ4bDogZXhlY3V0ZSBo
b3RwbHVnIHNjcmlwdHMgZGlyZWN0bHkgZnJvbSBsaWJ4bC4KPj4KPj4gQWRkZWQgdGhlIG5lY2Vz
c2FyeSBoYW5kbGVycyB0byBleGVjdXRlIGhvdHBsdWcgc2NyaXB0cyB3aGVuIG5lY2Vzc2FyeQo+
PiBmcm9tIGxpYnhsLiBTcGxpdCBOZXRCU0QgYW5kIExpbnV4IGhvdHBsdWcgY2FsbHMgaW50byB0
d28gc2VwYXJhdGUKPj4gZmlsZXMsIGJlY2F1c2UgcGFyYW1ldGVycyBmb3IgaG90cGx1ZyBzY3Jp
cHRzIGFyZSBkaWZmZXJlbnQuIExpbnV4Cj4+IGhhcyBlbXB0eSBmdW5jdGlvbnMsIHNpbmNlIHRo
ZSBjYWxsaW5nIG9mIGhvdHBsdWcgc2NyaXB0cyBpcyBzdGlsbAo+PiBkb25lIHVzaW5nIHVkZXYu
Cj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVw
Yy5lZHU+Cj4+Cj4+IGRpZmYgLXIgNGFkOTk4ZmRkYjE2IC1yIDFkODFkMWM0Yzg1MSB0b29scy9s
aWJ4bC9NYWtlZmlsZQo+PiAtLS0gYS90b29scy9saWJ4bC9NYWtlZmlsZSDCoCDCoCDCoEZyaSBO
b3YgMTggMTE6Mjk6MTQgMjAxMSArMDEwMAo+PiArKysgYi90b29scy9saWJ4bC9NYWtlZmlsZSDC
oCDCoCDCoEZyaSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSArMDIwMAo+PiBAQCAtMzQsOCArMzQsMTAg
QEAgTElCWExfT0JKUy0kKENPTkZJR19JQTY0KSArPSBsaWJ4bF9ub2NwdQo+Cj4gU2hvdWxkIGJl
Ogo+Cj4+IMKgaWZlcSAoJChDT05GSUdfTmV0QlNEKSx5KQo+PiDCoExJQlhMX09CSlMteSArPSBs
aWJ4bF9waHliYWNrZW5kLm8KPj4gK0xJQlhMX09CSlMteSArPSBob3RwbHVnX25ldGJzZC5vCj4g
wqAgZWxzaWYgKCQoQ09ORklHX0xpbnV4KSx5KQo+PiDCoExJQlhMX09CSlMteSArPSBsaWJ4bF9u
b3BoeWJhY2tlbmQubwo+PiArTElCWExfT0JKUy15ICs9IGhvdHBsdWdfbGludXgubwo+IMKgIGVs
c2UKPiDCoCAkKGVycm9yIEEgbWVzc2FnZSBvZiBzb21lIHNvcnQpCj4+IMKgZW5kaWYKCkRvbmUs
IEkndmUgbW92ZWQgUEhZIGJhY2tlbmQgc2VsZWN0aW9uIGFuZCBob3RwbHVnIHNwZWNpZmljIGZ1
bmN0aW9ucwp0byBsaWJ4bF9uZXRic2QuYyBhbmQgbGlieGxfbGludXguYywgYW5kIGFkZGVkIGFu
IGVycm9yIG1lc3NhZ2UgaW4KY2FzZSBzb21lb25lIHRyaWVzIHRvIHVzZSBhIGRpZmZlcmVudCBP
Uy4KCj4+IGRpZmYgLXIgNGFkOTk4ZmRkYjE2IC1yIDFkODFkMWM0Yzg1MSB0b29scy9saWJ4bC9s
aWJ4bF9kZXZpY2UuYwo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9kZXZpY2UuYyDCoCDCoCDC
oCDCoEZyaSBOb3YgMTggMTE6Mjk6MTQgMjAxMSArMDEwMAo+PiArKysgYi90b29scy9saWJ4bC9s
aWJ4bF9kZXZpY2UuYyDCoCDCoCDCoCDCoEZyaSBTZXAgMzAgMTQ6Mzg6NTUgMjAxMSArMDIwMAo+
PiBAQCAtNjgsNiArNjgsMjQgQEAgaW50IGxpYnhsX19wYXJzZV9iYWNrZW5kX3BhdGgobGlieGxf
X2djCj4+IMKgIMKgIMKgcmV0dXJuIGxpYnhsX19kZXZpY2Vfa2luZF9mcm9tX3N0cmluZyhzdHJr
aW5kLCAmZGV2LT5iYWNrZW5kX2tpbmQpOwo+PiDCoH0KPj4KPj4gK2ludCBsaWJ4bF9fZGV2aWNl
X2V4ZWN1dGVfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdjLCBsaWJ4bF9fZGV2aWNlICpkZXYpCj4KPiBO
byBuZWVkIGZvciBhIGFkZC9yZW1vdmUgdHlwZSBwYXJhbWV0ZXI/CgpBbHRob3VnaCB5b3UgY291
bGQgcGFzcyB0aGlzIGtpbmQgb2YgcGFyYW1ldGVyLCB0aGUgYWN0aW9uIHRvIHBlcmZvcm0KaXMg
YmFzZWQgb24gdGhlIHN0YXRlIG9mIHRoZSBkZXZpY2UgaW4gdGhlIGNvcnJlc3BvbmRpbmcgeGVu
c3RvcmUKZW50cnkuIFN0YXRlIDIgbWVhbnMgdGhhdCB0aGUgZGV2aWNlIHNob3VsZCBiZSBjb25u
ZWN0ZWQsIHN0YXRlIDYKbWVhbnMgdGhlIGRldmljZSBzaG91bGQgYmUgZGlzY29ubmVjdGVkLgoK
Pj4gK3sKPj4gKyDCoCDCoGludCByYyA9IDA7Cj4+ICsKPj4gKyDCoCDCoHN3aXRjaChkZXYtPmtp
bmQpIHsKPj4gKyDCoCDCoGNhc2UgTElCWExfX0RFVklDRV9LSU5EX1ZJRjoKPj4gKyDCoCDCoCDC
oCDCoHJjID0gbGlieGxfX25pY19ob3RwbHVnKGdjLCBkZXYpOwo+PiArIMKgIMKgIMKgIMKgYnJl
YWs7Cj4+ICsgwqAgwqBjYXNlIExJQlhMX19ERVZJQ0VfS0lORF9WQkQ6Cj4+ICsgwqAgwqAgwqAg
wqByYyA9IGxpYnhsX19kaXNrX2hvdHBsdWcoZ2MsIGRldik7Cj4+ICsgwqAgwqAgwqAgwqBicmVh
azsKPj4gKyDCoCDCoGRlZmF1bHQ6Cj4+ICsgwqAgwqAgwqAgwqBicmVhazsKPj4gKyDCoCDCoH0K
Pj4gKwo+PiArIMKgIMKgcmV0dXJuIHJjOwo+PiArfQo+PiArCj4+IMKgaW50IGxpYnhsX19kZXZp
Y2VfZ2VuZXJpY19hZGQobGlieGxfX2djICpnYywgbGlieGxfX2RldmljZSAqZGV2aWNlLAo+PiDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjaGFyICoqYmVudHMs
IGNoYXIgKipmZW50cykKPj4gwqB7Cj4+IEBAIC00NDksNiArNDY3LDcgQEAgaW50IGxpYnhsX19k
ZXZpY2VfcmVtb3ZlKGxpYnhsX19nYyAqZ2MsCj4+IMKgIMKgIMKgaWYgKCFzdGF0ZSkKPj4gwqAg
wqAgwqAgwqAgwqBnb3RvIG91dDsKPj4gwqAgwqAgwqBpZiAoYXRvaShzdGF0ZSkgIT0gNCkgewo+
PiArIMKgIMKgIMKgIMKgbGlieGxfX2RldmljZV9leGVjdXRlX2hvdHBsdWcoZ2MsIGRldik7Cj4+
IMKgIMKgIMKgIMKgIMKgbGlieGxfX2RldmljZV9kZXN0cm95X3RhcGRpc2soZ2MsIGJlX3BhdGgp
Owo+PiDCoCDCoCDCoCDCoCDCoHhzX3JtKGN0eC0+eHNoLCBYQlRfTlVMTCwgYmVfcGF0aCk7Cj4+
IMKgIMKgIMKgIMKgIMKgZ290byBvdXQ7Cj4+IEBAIC00OTIsNiArNTExLDEyIEBAIGludCBsaWJ4
bF9fZGV2aWNlX2Rlc3Ryb3kobGlieGxfX2djICpnYywKPj4gwqAgwqAgwqBjaGFyICpiZV9wYXRo
ID0gbGlieGxfX2RldmljZV9iYWNrZW5kX3BhdGgoZ2MsIGRldik7Cj4+IMKgIMKgIMKgY2hhciAq
ZmVfcGF0aCA9IGxpYnhsX19kZXZpY2VfZnJvbnRlbmRfcGF0aChnYywgZGV2KTsKPj4KPj4gKyDC
oCDCoC8qCj4+ICsgwqAgwqAgKiBSdW4gaG90cGx1ZyBzY3JpcHRzLCB3aGljaCB3aWxsIHByb2Jh
Ymx5IG5vdCBiZSBhYmxlIHRvCj4+ICsgwqAgwqAgKiBleGVjdXRlIHN1Y2Nlc3NmdWxseSBzaW5j
ZSB0aGUgZGV2aWNlIG1heSBzdGlsbCBiZSBwbHVnZ2VkCj4KPiBXaGF0IGRvZXMgdGhpcyBtZWFu
PyBJZiB3ZSBkb24ndCBleHBlY3QgaXQgdG8gd29yayB3aHkgYXJlIHdlIGNhbGxpbmcKPiB0aGVt
PwoKSWYgeW91IGNhbGwgdGhlIGxpYnhsX2RvbWFpbl9kZXN0cm95IGZ1bmN0aW9uIHdpdGggZm9y
Y2UgPT0gMSwgdGhlCmRlc3Ryb3kgcHJvY2VzcyBkb2Vzbid0IHdhaXQgZm9yIGRldmljZXMgdG8g
YmUgZGlzY29ubmVjdGVkLCBidXQgd2UKbWlnaHQgYXMgd2VsbCB0cnkgdG8gZXhlY3V0ZSBob3Rw
bHVnIHNjcmlwdHMsIHNpbmNlIHdlIGRvbid0IGtub3cgdGhlCmFjdHVhbCBzdGF0ZSBvZiB0aGUg
ZGV2aWNlLiBJZiB3ZSBhcmUgbHVja3ksIHRoZSBkZXZpY2UgbWlnaHQgYmUKZGlzY29ubmVjdGVk
IChzdGF0ZSA9PSA2KSwgYW5kIHdlIHNob3VsZCBiZSBhYmxlIHRvIGV4ZWN1dGUgaG90cGx1Zwpz
Y3JpcHRzIHN1Y2Nlc3NmdWxseS4KCj4+ICsgwqAgwqAgKi8KPj4gKyDCoCDCoGxpYnhsX19kZXZp
Y2VfZXhlY3V0ZV9ob3RwbHVnKGdjLCBkZXYpOwo+PiArCj4+IMKgIMKgIMKgeHNfcm0oY3R4LT54
c2gsIFhCVF9OVUxMLCBiZV9wYXRoKTsKPj4gwqAgwqAgwqB4c19ybShjdHgtPnhzaCwgWEJUX05V
TEwsIGZlX3BhdGgpOwo+Pgo+PiBkaWZmIC1yIDRhZDk5OGZkZGIxNiAtciAxZDgxZDFjNGM4NTEg
dG9vbHMvbGlieGwvbGlieGxfaW50ZXJuYWwuaAo+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9p
bnRlcm5hbC5oIMKgIMKgIMKgRnJpIE5vdiAxOCAxMToyOToxNCAyMDExICswMTAwCj4+ICsrKyBi
L3Rvb2xzL2xpYnhsL2xpYnhsX2ludGVybmFsLmggwqAgwqAgwqBGcmkgU2VwIDMwIDE0OjM4OjU1
IDIwMTEgKzAyMDAKPj4gQEAgLTI4Nyw2ICsyODcsMzQgQEAgX2hpZGRlbiBpbnQgbGlieGxfX3dh
aXRfZm9yX2RldmljZV9zdGF0ZQo+PiDCoCAqLwo+PiDCoF9oaWRkZW4gaW50IGxpYnhsX190cnlf
cGh5X2JhY2tlbmQobW9kZV90IHN0X21vZGUpOwo+Pgo+PiArLyogaG90cGx1ZyBmdW5jdGlvbnMg
Ki8KPj4gKy8qCj4+ICsgKiBsaWJ4bF9fZGV2aWNlX2V4ZWN1dGVfaG90cGx1ZyAtIGdlbmVyaWMg
ZnVuY3Rpb24gdG8gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdHMKPj4gKyAqIGdjOiBhbGxvY2F0aW9u
IHBvb2wKPj4gKyAqIGRldjogcmVmZXJlbmNlIHRvIHRoZSBkZXZpY2UgdGhhdCBleGVjdXRlcyB0
aGUgaG90cGx1ZyBzY3JpcHRzCj4+ICsgKgo+PiArICogUmV0dXJucyAwIG9uIHN1Y2Nlc3MsIGFu
ZCA8IDAgb24gZXJyb3IuCj4+ICsgKi8KPj4gK19oaWRkZW4gaW50IGxpYnhsX19kZXZpY2VfZXhl
Y3V0ZV9ob3RwbHVnKGxpYnhsX19nYyAqZ2MsIGxpYnhsX19kZXZpY2UgKmRldik7Cj4+ICsKPj4g
Ky8qCj4+ICsgKiBsaWJ4bF9fZGlza19ob3RwbHVnIC0gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdCBm
b3IgYSBkaXNrIHR5cGUgZGV2aWNlCj4+ICsgKiBnYzogYWxsb2NhdGlvbiBwb29sCj4+ICsgKiBk
ZXY6IHJlZmVyZW5jZSB0byB0aGUgZGlzayBkZXZpY2UKPj4gKyAqCj4+ICsgKiBSZXR1cm5zIDAg
b24gc3VjY2VzcywgYW5kIDwgMCBvbiBlcnJvci4KPj4gKyAqLwo+PiArX2hpZGRlbiBpbnQgbGli
eGxfX2Rpc2tfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdjLCBsaWJ4bF9fZGV2aWNlICpkZXYpOwo+PiAr
Cj4+ICsvKgo+PiArICogbGlieGxfX25pY19ob3RwbHVnIC0gZXhlY3V0ZSBob3RwbHVnIHNjcmlw
dCBmb3IgYSBuaWMgdHlwZSBkZXZpY2UKPj4gKyAqIGdjOiBhbGxvY2F0aW9uIHBvb2wKPj4gKyAq
IGRldjogcmVmZXJlbmNlIHRvIHRoZSBuaWMgZGV2aWNlCj4+ICsgKgo+PiArICogUmV0dXJucyAw
IG9uIHN1Y2Nlc3MsIGFuZCA8IDAgb24gZXJyb3IuCj4+ICsgKi8KPj4gK19oaWRkZW4gaW50IGxp
YnhsX19uaWNfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdjLCBsaWJ4bF9fZGV2aWNlICpkZXYpOwo+PiAr
Cj4+IMKgLyogZnJvbSBsaWJ4bF9wY2kgKi8KPj4KPj4gwqBfaGlkZGVuIGludCBsaWJ4bF9fZGV2
aWNlX3BjaV9hZGQobGlieGxfX2djICpnYywgdWludDMyX3QgZG9taWQsIGxpYnhsX2RldmljZV9w
Y2kgKnBjaWRldiwgaW50IHN0YXJ0aW5nKTsKPj4KPj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+PiBYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+PiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwKPgo+Cj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:43:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSHK-0006ih-Bh; Mon, 21 Nov 2011 11:43:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSSHI-0006iF-Pp
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:43:13 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1321875764!3949167!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2868 invoked from network); 21 Nov 2011 11:42:45 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 11:42:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pALBgbgt009664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 21 Nov 2011 11:42:38 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pALBgXW3022617
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 21 Nov 2011 11:42:34 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pALBgQUP021334; Mon, 21 Nov 2011 05:42:26 -0600
Received: from [123.113.103.235] (/123.113.103.235)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 03:42:25 -0800
Message-ID: <4ECA3914.4050401@oracle.com>
Date: Mon, 21 Nov 2011 19:42:12 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EC3B62F.6080702@oracle.com>	
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>	
	<4EC62FE5.2080608@oracle.com>	
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>	
	<20111118135221.GC12433@phenom.dumpdata.com>	
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>	
	<4EC6837F.1050201@oracle.com>
	<20111118180500.GA19469@phenom.dumpdata.com>	
	<4ECA1F13.3060903@oracle.com>
	<1321871748.3664.375.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321871748.3664.375.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4ECA392E.013B,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> Neither of these changes are in the attached patch, did you resend an
> old one by mistake?
>   
Sorry, I sent the old ones by mistake. :(
> I think a fresh reposting of the series is in order, at least I've
> rather lost track of which patches are the most recent ones in this
> thread.
>   
OK, I will repost the patches in a new thread.

Thanks
Annie
> Ian.
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:43:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSHK-0006ih-Bh; Mon, 21 Nov 2011 11:43:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSSHI-0006iF-Pp
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:43:13 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1321875764!3949167!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2868 invoked from network); 21 Nov 2011 11:42:45 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 11:42:45 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pALBgbgt009664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 21 Nov 2011 11:42:38 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pALBgXW3022617
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 21 Nov 2011 11:42:34 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pALBgQUP021334; Mon, 21 Nov 2011 05:42:26 -0600
Received: from [123.113.103.235] (/123.113.103.235)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 03:42:25 -0800
Message-ID: <4ECA3914.4050401@oracle.com>
Date: Mon, 21 Nov 2011 19:42:12 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4EC3B62F.6080702@oracle.com>	
	<1321451372-13596-1-git-send-email-annie.li@oracle.com>	
	<4EC62FE5.2080608@oracle.com>	
	<1321614166.3664.311.camel@zakaz.uk.xensource.com>	
	<20111118135221.GC12433@phenom.dumpdata.com>	
	<1321624845.3664.354.camel@zakaz.uk.xensource.com>	
	<4EC6837F.1050201@oracle.com>
	<20111118180500.GA19469@phenom.dumpdata.com>	
	<4ECA1F13.3060903@oracle.com>
	<1321871748.3664.375.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321871748.3664.375.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4ECA392E.013B,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> Neither of these changes are in the attached patch, did you resend an
> old one by mistake?
>   
Sorry, I sent the old ones by mistake. :(
> I think a fresh reposting of the series is in order, at least I've
> rather lost track of which patches are the most recent ones in this
> thread.
>   
OK, I will repost the patches in a new thread.

Thanks
Annie
> Ian.
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:55:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:55:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSSn-0007He-Ka; Mon, 21 Nov 2011 11:55:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSSSm-0007HQ-E8
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:55:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1321876476!2381335!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20859 invoked from network); 21 Nov 2011 11:54:37 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:54:37 -0000
Received: by wwp14 with SMTP id 14so8193670wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 03:54:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=yNOPZUstaZBJG/+PdBW/bcQIBbaFtDVI8ycTlHs0ZVE=;
	b=I+TIGE1gNntJIbgtT+DHRKEweBU89OgOoPMf32qZSrpfweQ7ahtlLEt/lCvfQ/CCcq
	hlKtM2OP6h9on2JLltSZVf8RXYNOQjvWnpHecJ8kyYfXuIkkRWQzzuQgAKpFpVMfl2tE
	fSaaxi87JtzXt6xkZ4CwW5WAlfhoQUi+sWr8Q=
Received: by 10.216.19.139 with SMTP id n11mr32082wen.47.1321876476375;
	Mon, 21 Nov 2011 03:54:36 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id k5sm5031055wiz.9.2011.11.21.03.54.35
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 03:54:35 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 11:54:32 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CAEFEC78.2549A%keir.xen@gmail.com>
Thread-Topic: [PATCH v2] x86: re-inject emulated level pirqs in PV on HVM
	guests if still asserted
Thread-Index: AcyoRFS/1Hm/4tG/K0eO9TWEiSm+Ww==
In-Reply-To: <alpine.DEB.2.00.1111211106110.31179@kaball-desktop>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] x86: re-inject emulated level pirqs in
 PV on HVM guests if still asserted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 11:06, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

> On Mon, 21 Nov 2011, Jan Beulich wrote:
>>>>> On 18.11.11 at 12:13, Stefano Stabellini
>>>>> <stefano.stabellini@eu.citrix.com>
>> wrote:
>>> This patch is a backport of CS 24007 for xen-4.1-testing.
>>> 
>>> PV on HVM guests can loose level interrupts coming from emulated
>>> devices if they have been remapped onto event channels.  The reason is
>>> that we are missing the code to inject a pirq again in the guest when
>>> the guest EOIs it, if it corresponds to an emulated level interrupt
>>> and the interrupt is still asserted.
>>> 
>>> Fix this issue and also return error when the guest tries to get the
>>> irq_status of a non-existing pirq.
>>> 
>>> 
>>> Changes in v2:
>>> 
>>> - move the spinlock afterward to cover the new code only.
>> 
>> This, as expected, doesn't hang anymore with kernels making use of
>> the PIRQ EOI map.
> 
> Thanks for testing!
> Keir, are you happy with the patch?

Yes, I applied it already.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:55:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:55:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSSn-0007He-Ka; Mon, 21 Nov 2011 11:55:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSSSm-0007HQ-E8
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:55:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1321876476!2381335!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20859 invoked from network); 21 Nov 2011 11:54:37 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:54:37 -0000
Received: by wwp14 with SMTP id 14so8193670wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 03:54:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=yNOPZUstaZBJG/+PdBW/bcQIBbaFtDVI8ycTlHs0ZVE=;
	b=I+TIGE1gNntJIbgtT+DHRKEweBU89OgOoPMf32qZSrpfweQ7ahtlLEt/lCvfQ/CCcq
	hlKtM2OP6h9on2JLltSZVf8RXYNOQjvWnpHecJ8kyYfXuIkkRWQzzuQgAKpFpVMfl2tE
	fSaaxi87JtzXt6xkZ4CwW5WAlfhoQUi+sWr8Q=
Received: by 10.216.19.139 with SMTP id n11mr32082wen.47.1321876476375;
	Mon, 21 Nov 2011 03:54:36 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id k5sm5031055wiz.9.2011.11.21.03.54.35
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 03:54:35 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 11:54:32 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CAEFEC78.2549A%keir.xen@gmail.com>
Thread-Topic: [PATCH v2] x86: re-inject emulated level pirqs in PV on HVM
	guests if still asserted
Thread-Index: AcyoRFS/1Hm/4tG/K0eO9TWEiSm+Ww==
In-Reply-To: <alpine.DEB.2.00.1111211106110.31179@kaball-desktop>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] x86: re-inject emulated level pirqs in
 PV on HVM guests if still asserted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 11:06, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

> On Mon, 21 Nov 2011, Jan Beulich wrote:
>>>>> On 18.11.11 at 12:13, Stefano Stabellini
>>>>> <stefano.stabellini@eu.citrix.com>
>> wrote:
>>> This patch is a backport of CS 24007 for xen-4.1-testing.
>>> 
>>> PV on HVM guests can loose level interrupts coming from emulated
>>> devices if they have been remapped onto event channels.  The reason is
>>> that we are missing the code to inject a pirq again in the guest when
>>> the guest EOIs it, if it corresponds to an emulated level interrupt
>>> and the interrupt is still asserted.
>>> 
>>> Fix this issue and also return error when the guest tries to get the
>>> irq_status of a non-existing pirq.
>>> 
>>> 
>>> Changes in v2:
>>> 
>>> - move the spinlock afterward to cover the new code only.
>> 
>> This, as expected, doesn't hang anymore with kernels making use of
>> the PIRQ EOI map.
> 
> Thanks for testing!
> Keir, are you happy with the patch?

Yes, I applied it already.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:56:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSTh-0007LZ-4l; Mon, 21 Nov 2011 11:56:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSSTf-0007Kx-9Q
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:55:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1321876531!5074391!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6167 invoked from network); 21 Nov 2011 11:55:31 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:55:31 -0000
Received: by wwp14 with SMTP id 14so8194842wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 03:55:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=CFduOz8Nmxn8Lo/U8dXBo8BYu95UGUXK6xvHT1k0PPM=;
	b=XEywF4YKxewgWsOQRcOv6fJOJszgqeNKyR6+uKhPwIkB5HT1wchv42wgc5yFlq+lb2
	7OSHAtKjevfOe38s1EBzPRjx9wE48k8/s6sT/78hRcWkZtPFaoeUgCQjdQvRLLg2/FDD
	Wtwkpx1TIIIVl38hwiPRBtZ9jtI5MnZ9fyibU=
Received: by 10.216.138.223 with SMTP id a73mr2014731wej.50.1321876530257;
	Mon, 21 Nov 2011 03:55:30 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id dy1sm5024612wib.18.2011.11.21.03.55.28
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 03:55:29 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 11:55:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <CAEFECAE.2549B%keir.xen@gmail.com>
Thread-Topic: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel
Thread-Index: AcyoRHTvsBS6PpBQWUeP73gvHOZGeQ==
In-Reply-To: <20170.14311.24009.221731@mariner.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 11:37, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> xen.org writes ("[xen-unstable bisection] complete
> test-amd64-i386-rhel6hvm-intel"):
>> branch xen-unstable
>> xen branch xen-unstable
>> job test-amd64-i386-rhel6hvm-intel
>> test redhat-install
>> 
>> Tree: linux git://github.com/jsgf/linux-xen.git
>> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
>> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
>> 
>> *** Found and reproduced problem changeset ***
>> 
>>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>>   Bug introduced:  7a9a1261a6b0
>>   Bug not present: 9a1a71f7bef2
> 
> This seems to have completely broken HVM ...

I'll revert if there's no fix forthcoming.

 -- Keir

>>   changeset:   24163:7a9a1261a6b0
>>   user:        Jean Guyader <jean.guyader@eu.citrix.com>
>>   date:        Fri Nov 18 13:41:33 2011 +0000
>>       
>>       add_to_physmap: Move the code for XENMEM_add_to_physmap
>>       
>>       Move the code for the XENMEM_add_to_physmap case into it's own
>>       function (xenmem_add_to_physmap).
>>       
>>       Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>       Committed-by: Keir Fraser <keir@xen.org>
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 11:56:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 11:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSTh-0007LZ-4l; Mon, 21 Nov 2011 11:56:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSSTf-0007Kx-9Q
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 11:55:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1321876531!5074391!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6167 invoked from network); 21 Nov 2011 11:55:31 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 11:55:31 -0000
Received: by wwp14 with SMTP id 14so8194842wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 03:55:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=CFduOz8Nmxn8Lo/U8dXBo8BYu95UGUXK6xvHT1k0PPM=;
	b=XEywF4YKxewgWsOQRcOv6fJOJszgqeNKyR6+uKhPwIkB5HT1wchv42wgc5yFlq+lb2
	7OSHAtKjevfOe38s1EBzPRjx9wE48k8/s6sT/78hRcWkZtPFaoeUgCQjdQvRLLg2/FDD
	Wtwkpx1TIIIVl38hwiPRBtZ9jtI5MnZ9fyibU=
Received: by 10.216.138.223 with SMTP id a73mr2014731wej.50.1321876530257;
	Mon, 21 Nov 2011 03:55:30 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id dy1sm5024612wib.18.2011.11.21.03.55.28
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 03:55:29 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 11:55:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <CAEFECAE.2549B%keir.xen@gmail.com>
Thread-Topic: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel
Thread-Index: AcyoRHTvsBS6PpBQWUeP73gvHOZGeQ==
In-Reply-To: <20170.14311.24009.221731@mariner.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 11:37, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> xen.org writes ("[xen-unstable bisection] complete
> test-amd64-i386-rhel6hvm-intel"):
>> branch xen-unstable
>> xen branch xen-unstable
>> job test-amd64-i386-rhel6hvm-intel
>> test redhat-install
>> 
>> Tree: linux git://github.com/jsgf/linux-xen.git
>> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
>> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
>> 
>> *** Found and reproduced problem changeset ***
>> 
>>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>>   Bug introduced:  7a9a1261a6b0
>>   Bug not present: 9a1a71f7bef2
> 
> This seems to have completely broken HVM ...

I'll revert if there's no fix forthcoming.

 -- Keir

>>   changeset:   24163:7a9a1261a6b0
>>   user:        Jean Guyader <jean.guyader@eu.citrix.com>
>>   date:        Fri Nov 18 13:41:33 2011 +0000
>>       
>>       add_to_physmap: Move the code for XENMEM_add_to_physmap
>>       
>>       Move the code for the XENMEM_add_to_physmap case into it's own
>>       function (xenmem_add_to_physmap).
>>       
>>       Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>       Committed-by: Keir Fraser <keir@xen.org>
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 12:19:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 12:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSpl-0007we-G8; Mon, 21 Nov 2011 12:18:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSSpk-0007wZ-0d
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 12:18:48 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321877899!4370771!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10711 invoked from network); 21 Nov 2011 12:18:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 12:18:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pALCIEi1017498
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 21 Nov 2011 12:18:15 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pALCID6m016682
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 21 Nov 2011 12:18:14 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pALCI7eM012660; Mon, 21 Nov 2011 06:18:07 -0600
Received: from [123.113.103.235] (/123.113.103.235)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 04:18:06 -0800
Message-ID: <4ECA416D.90602@oracle.com>
Date: Mon, 21 Nov 2011 20:17:49 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"jeremy@goop.org" <jeremy@goop.org>, Ian Campbell <Ian.Campbell@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4ECA4187.00D0,ss=1,re=0.000,fgs=0
Cc: KURT HACKEL <kurt.hackel@oracle.com>, ANNIE LI <annie.li@oracle.com>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: [Xen-devel] Third version patches for upstreaming grant table
	version 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

The following patches introduce and implement grant table version 2. 
This is the third version patches, and based on v3.2.0-rc1+. Changes 
from the previous patches are following:

Patch 1:
* removing gnttab_v1_ops declaration
* renaming update_grant_entry_v1 to gnttab_update_entry_v1

Patch3:
* changing following code

xen_raw_printk();
panic();

back to

panic();
* re-arrange "else if" format in gnttab_request_version function.


Descriptions for those patches:

1. In those patches, the grant table code supports both grant table v1 and v2 version, v2 is an extension from v1. Grant table of guest domain can be either v1 or v2 version, and every grant table entry on one guest should be the same version. 

2. Full page structure of grant table v2 play the same role as grant table v1. Although full page structure is different from v1, grant table 2 is totally backwards compatible with v1. Grant table is shared between guest and Xen, domu and dom0 all have their own grant table shared with Xen, and their grant table version should be set before any grants are activated. When domu grants an entry to dom0 to map a frame,following are steps: 
* domu introduces a grant entry by reference 
* domu informs dom0 the gref 
* dom0 sends hypercall to map frame through this reference, Xen copy shared entry to active entry and update frame 
* dom0 does its work and release the frame, Xen releases the entry. 
* domu redo those steps for a new cycle. 
Xen mapping process can be found in function __gnttab_map_grant_ref in Xen code: xen/common/grant_table.c

3. If dom0 supports grant table v2, guests run on it can either supports v1 or v2. Xen is responsible to judge what  version the guests are using. This is implemented in Xen code: xen/common/grant_table.c. Key word is:  rd->grant_table->gt_version. 

4. Grant table v2 has been supported by Xen for a long time, and receiver-side copying mechanism bases on this implementation. Netback and netfront driver can pick up this new feature to get better network performance and better CPU accounting.


Diff:

 arch/x86/xen/grant-table.c          |   42 ++++-
 drivers/xen/grant-table.c           |  354 
++++++++++++++++++++++++++++++-----
 include/xen/grant_table.h           |   10 +-
 include/xen/interface/grant_table.h |  167 ++++++++++++++++-
 include/xen/interface/xen.h         |    2 +
 5 files changed, 519 insertions(+), 56 deletions(-)

Shortlog:
Annie Li (4):
      xen/granttable: Introducing grant table V2 stucture
      xen/granttable: Refactor some code
      xen/granttable: Grant tables V2 implementation
      xen/granttable: Keep code format clean

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 12:19:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 12:19:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSSpl-0007we-G8; Mon, 21 Nov 2011 12:18:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSSpk-0007wZ-0d
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 12:18:48 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1321877899!4370771!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10711 invoked from network); 21 Nov 2011 12:18:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 12:18:20 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pALCIEi1017498
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 21 Nov 2011 12:18:15 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pALCID6m016682
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 21 Nov 2011 12:18:14 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pALCI7eM012660; Mon, 21 Nov 2011 06:18:07 -0600
Received: from [123.113.103.235] (/123.113.103.235)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 04:18:06 -0800
Message-ID: <4ECA416D.90602@oracle.com>
Date: Mon, 21 Nov 2011 20:17:49 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"jeremy@goop.org" <jeremy@goop.org>, Ian Campbell <Ian.Campbell@citrix.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4ECA4187.00D0,ss=1,re=0.000,fgs=0
Cc: KURT HACKEL <kurt.hackel@oracle.com>, ANNIE LI <annie.li@oracle.com>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: [Xen-devel] Third version patches for upstreaming grant table
	version 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

The following patches introduce and implement grant table version 2. 
This is the third version patches, and based on v3.2.0-rc1+. Changes 
from the previous patches are following:

Patch 1:
* removing gnttab_v1_ops declaration
* renaming update_grant_entry_v1 to gnttab_update_entry_v1

Patch3:
* changing following code

xen_raw_printk();
panic();

back to

panic();
* re-arrange "else if" format in gnttab_request_version function.


Descriptions for those patches:

1. In those patches, the grant table code supports both grant table v1 and v2 version, v2 is an extension from v1. Grant table of guest domain can be either v1 or v2 version, and every grant table entry on one guest should be the same version. 

2. Full page structure of grant table v2 play the same role as grant table v1. Although full page structure is different from v1, grant table 2 is totally backwards compatible with v1. Grant table is shared between guest and Xen, domu and dom0 all have their own grant table shared with Xen, and their grant table version should be set before any grants are activated. When domu grants an entry to dom0 to map a frame,following are steps: 
* domu introduces a grant entry by reference 
* domu informs dom0 the gref 
* dom0 sends hypercall to map frame through this reference, Xen copy shared entry to active entry and update frame 
* dom0 does its work and release the frame, Xen releases the entry. 
* domu redo those steps for a new cycle. 
Xen mapping process can be found in function __gnttab_map_grant_ref in Xen code: xen/common/grant_table.c

3. If dom0 supports grant table v2, guests run on it can either supports v1 or v2. Xen is responsible to judge what  version the guests are using. This is implemented in Xen code: xen/common/grant_table.c. Key word is:  rd->grant_table->gt_version. 

4. Grant table v2 has been supported by Xen for a long time, and receiver-side copying mechanism bases on this implementation. Netback and netfront driver can pick up this new feature to get better network performance and better CPU accounting.


Diff:

 arch/x86/xen/grant-table.c          |   42 ++++-
 drivers/xen/grant-table.c           |  354 
++++++++++++++++++++++++++++++-----
 include/xen/grant_table.h           |   10 +-
 include/xen/interface/grant_table.h |  167 ++++++++++++++++-
 include/xen/interface/xen.h         |    2 +
 5 files changed, 519 insertions(+), 56 deletions(-)

Shortlog:
Annie Li (4):
      xen/granttable: Introducing grant table V2 stucture
      xen/granttable: Refactor some code
      xen/granttable: Grant tables V2 implementation
      xen/granttable: Keep code format clean

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 13:10:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 13:10:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSTcp-0008RO-5X; Mon, 21 Nov 2011 13:09:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RSTcn-0008RJ-E8
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 13:09:29 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321880940!3974521!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30892 invoked from network); 21 Nov 2011 13:09:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 13:09:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,547,1315195200"; d="scan'208";a="19271900"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 08:09:00 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 08:09:00 -0500
MIME-Version: 1.0
X-Mercurial-Node: ff6518e294a7daa552e33c4d40be7597667c67db
Message-ID: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 21 Nov 2011 13:07:19 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321880835 0
# Node ID ff6518e294a7daa552e33c4d40be7597667c67db
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Add missing modprobe to xencommons

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r dbdc840f8f62 -r ff6518e294a7 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/hotplug/Linux/init.d/xencommons	Mon Nov 21 13:07:15 2011 +0000
@@ -52,6 +52,7 @@ do_start () {
 		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 
 		echo -n Starting xenstored...
+		modprobe xen-evtchn
 		xenstored --pid-file=/var/run/xenstored.pid $XENSTORED_ARGS
 
 		# Wait for xenstored to actually come up, timing out after 30 seconds

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 13:10:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 13:10:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSTcp-0008RO-5X; Mon, 21 Nov 2011 13:09:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RSTcn-0008RJ-E8
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 13:09:29 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321880940!3974521!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30892 invoked from network); 21 Nov 2011 13:09:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 13:09:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,547,1315195200"; d="scan'208";a="19271900"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 08:09:00 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 08:09:00 -0500
MIME-Version: 1.0
X-Mercurial-Node: ff6518e294a7daa552e33c4d40be7597667c67db
Message-ID: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 21 Nov 2011 13:07:19 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1321880835 0
# Node ID ff6518e294a7daa552e33c4d40be7597667c67db
# Parent  dbdc840f8f62db58321b5009e5e0f7833066386f
Add missing modprobe to xencommons

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r dbdc840f8f62 -r ff6518e294a7 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/hotplug/Linux/init.d/xencommons	Mon Nov 21 13:07:15 2011 +0000
@@ -52,6 +52,7 @@ do_start () {
 		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 
 		echo -n Starting xenstored...
+		modprobe xen-evtchn
 		xenstored --pid-file=/var/run/xenstored.pid $XENSTORED_ARGS
 
 		# Wait for xenstored to actually come up, timing out after 30 seconds

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 13:50:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 13:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSUGD-0000lU-Ru; Mon, 21 Nov 2011 13:50:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSUGC-0000lK-7U
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 13:50:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321883384!2404516!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18983 invoked from network); 21 Nov 2011 13:49:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 13:49:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,547,1315180800"; 
   d="scan'208";a="9041707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 13:49:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 13:49:43 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSUFj-0004or-H3;
	Mon, 21 Nov 2011 13:49:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSUFj-0004BX-Ay;
	Mon, 21 Nov 2011 13:49:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9936-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 21 Nov 2011 13:49:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9936: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9936 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9936/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate         fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  9c350ab8d3ea
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24168:9c350ab8d3ea
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Nov 21 09:29:31 2011 +0100
    
    x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
    
    Xen itself (as much as Linux) relies on this behavior, so it should
    also emulate it properly. Not doing so reportedly gets in the way of
    kexec inside a HVM guest.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24167:335e8273a3f3
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 13:50:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 13:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSUGD-0000lU-Ru; Mon, 21 Nov 2011 13:50:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSUGC-0000lK-7U
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 13:50:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321883384!2404516!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18983 invoked from network); 21 Nov 2011 13:49:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 13:49:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,547,1315180800"; 
   d="scan'208";a="9041707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 13:49:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 13:49:43 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSUFj-0004or-H3;
	Mon, 21 Nov 2011 13:49:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSUFj-0004BX-Ay;
	Mon, 21 Nov 2011 13:49:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9936-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 21 Nov 2011 13:49:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9936: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9936 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9936/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate         fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  9c350ab8d3ea
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24168:9c350ab8d3ea
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Nov 21 09:29:31 2011 +0100
    
    x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
    
    Xen itself (as much as Linux) relies on this behavior, so it should
    also emulate it properly. Not doing so reportedly gets in the way of
    kexec inside a HVM guest.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24167:335e8273a3f3
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 14:37:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 14:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSUzi-00031k-1L; Mon, 21 Nov 2011 14:37:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSUzf-00031c-Uy
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 14:37:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321886204!3987658!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16288 invoked from network); 21 Nov 2011 14:36:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 14:36:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,547,1315180800"; 
   d="scan'208";a="9043269"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 14:36:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 14:36:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 21 Nov 2011 14:36:43 +0000
In-Reply-To: <CAPLaKK5JF1NeXkq4zkZtaSjvOfY=VrsrvJ-YHE+aFXd1+pkAgw@mail.gmail.com>
References: <patchbomb.1321617576@loki.upc.es>
	<1d81d1c4c851c0b07696.1321617582@loki.upc.es>
	<1321623730.3664.352.camel@zakaz.uk.xensource.com>
	<CAPLaKK5JF1NeXkq4zkZtaSjvOfY=VrsrvJ-YHE+aFXd1+pkAgw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321886203.3664.395.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTExLTIxIGF0IDExOjQyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTEvMTggSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBGcmksIDIwMTEtMTEtMTggYXQgMTE6NTkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90
ZToKPiA+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ID4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+ID4+ICMgRGF0ZSAxMzE3Mzg2MzM1IC03MjAwCj4g
Pj4gIyBOb2RlIElEIDFkODFkMWM0Yzg1MWMwYjA3Njk2MzczMzA0ODAxZGY1NmEyMjFlOTAKPiA+
PiAjIFBhcmVudCAgNGFkOTk4ZmRkYjE2YTI5OWNiMjMwZWEyM2JhOTQ0ZDg0YWRiZDJiZgo+ID4+
IGxpYnhsOiBleGVjdXRlIGhvdHBsdWcgc2NyaXB0cyBkaXJlY3RseSBmcm9tIGxpYnhsLgo+ID4+
Cj4gPj4gQWRkZWQgdGhlIG5lY2Vzc2FyeSBoYW5kbGVycyB0byBleGVjdXRlIGhvdHBsdWcgc2Ny
aXB0cyB3aGVuIG5lY2Vzc2FyeQo+ID4+IGZyb20gbGlieGwuIFNwbGl0IE5ldEJTRCBhbmQgTGlu
dXggaG90cGx1ZyBjYWxscyBpbnRvIHR3byBzZXBhcmF0ZQo+ID4+IGZpbGVzLCBiZWNhdXNlIHBh
cmFtZXRlcnMgZm9yIGhvdHBsdWcgc2NyaXB0cyBhcmUgZGlmZmVyZW50LiBMaW51eAo+ID4+IGhh
cyBlbXB0eSBmdW5jdGlvbnMsIHNpbmNlIHRoZSBjYWxsaW5nIG9mIGhvdHBsdWcgc2NyaXB0cyBp
cyBzdGlsbAo+ID4+IGRvbmUgdXNpbmcgdWRldi4KPiA+Pgo+ID4+IFNpZ25lZC1vZmYtYnk6IFJv
Z2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4gPj4KPiA+PiBkaWZmIC1y
IDRhZDk5OGZkZGIxNiAtciAxZDgxZDFjNGM4NTEgdG9vbHMvbGlieGwvTWFrZWZpbGUKPiA+PiAt
LS0gYS90b29scy9saWJ4bC9NYWtlZmlsZSAgICAgIEZyaSBOb3YgMTggMTE6Mjk6MTQgMjAxMSAr
MDEwMAo+ID4+ICsrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlICAgICAgRnJpIFNlcCAzMCAxNDoz
ODo1NSAyMDExICswMjAwCj4gPj4gQEAgLTM0LDggKzM0LDEwIEBAIExJQlhMX09CSlMtJChDT05G
SUdfSUE2NCkgKz0gbGlieGxfbm9jcHUKPiA+Cj4gPiBTaG91bGQgYmU6Cj4gPgo+ID4+ICBpZmVx
ICgkKENPTkZJR19OZXRCU0QpLHkpCj4gPj4gIExJQlhMX09CSlMteSArPSBsaWJ4bF9waHliYWNr
ZW5kLm8KPiA+PiArTElCWExfT0JKUy15ICs9IGhvdHBsdWdfbmV0YnNkLm8KPiA+ICAgZWxzaWYg
KCQoQ09ORklHX0xpbnV4KSx5KQo+ID4+ICBMSUJYTF9PQkpTLXkgKz0gbGlieGxfbm9waHliYWNr
ZW5kLm8KPiA+PiArTElCWExfT0JKUy15ICs9IGhvdHBsdWdfbGludXgubwo+ID4gICBlbHNlCj4g
PiAgICQoZXJyb3IgQSBtZXNzYWdlIG9mIHNvbWUgc29ydCkKPiA+PiAgZW5kaWYKPiAKPiBEb25l
LCBJJ3ZlIG1vdmVkIFBIWSBiYWNrZW5kIHNlbGVjdGlvbiBhbmQgaG90cGx1ZyBzcGVjaWZpYyBm
dW5jdGlvbnMKPiB0byBsaWJ4bF9uZXRic2QuYyBhbmQgbGlieGxfbGludXguYywgYW5kIGFkZGVk
IGFuIGVycm9yIG1lc3NhZ2UgaW4KPiBjYXNlIHNvbWVvbmUgdHJpZXMgdG8gdXNlIGEgZGlmZmVy
ZW50IE9TLgo+IAo+ID4+IGRpZmYgLXIgNGFkOTk4ZmRkYjE2IC1yIDFkODFkMWM0Yzg1MSB0b29s
cy9saWJ4bC9saWJ4bF9kZXZpY2UuYwo+ID4+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2Rldmlj
ZS5jICAgICAgICBGcmkgTm92IDE4IDExOjI5OjE0IDIwMTEgKzAxMDAKPiA+PiArKysgYi90b29s
cy9saWJ4bC9saWJ4bF9kZXZpY2UuYyAgICAgICAgRnJpIFNlcCAzMCAxNDozODo1NSAyMDExICsw
MjAwCj4gPj4gQEAgLTY4LDYgKzY4LDI0IEBAIGludCBsaWJ4bF9fcGFyc2VfYmFja2VuZF9wYXRo
KGxpYnhsX19nYwo+ID4+ICAgICAgcmV0dXJuIGxpYnhsX19kZXZpY2Vfa2luZF9mcm9tX3N0cmlu
ZyhzdHJraW5kLCAmZGV2LT5iYWNrZW5kX2tpbmQpOwo+ID4+ICB9Cj4gPj4KPiA+PiAraW50IGxp
YnhsX19kZXZpY2VfZXhlY3V0ZV9ob3RwbHVnKGxpYnhsX19nYyAqZ2MsIGxpYnhsX19kZXZpY2Ug
KmRldikKPiA+Cj4gPiBObyBuZWVkIGZvciBhIGFkZC9yZW1vdmUgdHlwZSBwYXJhbWV0ZXI/Cj4g
Cj4gQWx0aG91Z2ggeW91IGNvdWxkIHBhc3MgdGhpcyBraW5kIG9mIHBhcmFtZXRlciwgdGhlIGFj
dGlvbiB0byBwZXJmb3JtCj4gaXMgYmFzZWQgb24gdGhlIHN0YXRlIG9mIHRoZSBkZXZpY2UgaW4g
dGhlIGNvcnJlc3BvbmRpbmcgeGVuc3RvcmUKPiBlbnRyeS4gU3RhdGUgMiBtZWFucyB0aGF0IHRo
ZSBkZXZpY2Ugc2hvdWxkIGJlIGNvbm5lY3RlZCwgc3RhdGUgNgo+IG1lYW5zIHRoZSBkZXZpY2Ug
c2hvdWxkIGJlIGRpc2Nvbm5lY3RlZC4KClRoaXMgc2VlbXMgYSBsaXR0bGUgZnJhZ2lsZSBpbiB0
aGUgZmFjZSBvZiB3ZWlyZCBlcnJvcnMgaGFwcGVuaW5nCmFzeW5jaHJvbm91c2x5IGFuZCBjb3Vs
ZCBhbHNvIGJlIHJhY3kgaW4gdGhlIG5vcm1hbCBjYXNlLiBJIHRoaW5rIHlvdQpzaG91bGQgcGFz
cyBpbiB0aGUgYWN0aW9uIHRvIGJlIHBlcmZvcm1lZCBhbmQsIGlmIG5lY2Vzc2FyeSwgY29uZmly
bQp0aGF0IHRoZSBzdGF0ZSBpcyBjb3JyZWN0LiBJZiBwb3NzaWJsZSB5b3Ugc2hvdWxkIGp1c3Qg
cGVyZm9ybSB0aGUKcmVxdWVzdGVkIGFjdGlvbiBpcnJlc3BlY3RpdmUgb2YgdGhlIGJhY2tlbmQg
c3RhdGUuCgo+IAo+ID4+ICt7Cj4gPj4gKyAgICBpbnQgcmMgPSAwOwo+ID4+ICsKPiA+PiArICAg
IHN3aXRjaChkZXYtPmtpbmQpIHsKPiA+PiArICAgIGNhc2UgTElCWExfX0RFVklDRV9LSU5EX1ZJ
RjoKPiA+PiArICAgICAgICByYyA9IGxpYnhsX19uaWNfaG90cGx1ZyhnYywgZGV2KTsKPiA+PiAr
ICAgICAgICBicmVhazsKPiA+PiArICAgIGNhc2UgTElCWExfX0RFVklDRV9LSU5EX1ZCRDoKPiA+
PiArICAgICAgICByYyA9IGxpYnhsX19kaXNrX2hvdHBsdWcoZ2MsIGRldik7Cj4gPj4gKyAgICAg
ICAgYnJlYWs7Cj4gPj4gKyAgICBkZWZhdWx0Ogo+ID4+ICsgICAgICAgIGJyZWFrOwo+ID4+ICsg
ICAgfQo+ID4+ICsKPiA+PiArICAgIHJldHVybiByYzsKPiA+PiArfQo+ID4+ICsKPiA+PiAgaW50
IGxpYnhsX19kZXZpY2VfZ2VuZXJpY19hZGQobGlieGxfX2djICpnYywgbGlieGxfX2RldmljZSAq
ZGV2aWNlLAo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNoYXIgKipiZW50cywg
Y2hhciAqKmZlbnRzKQo+ID4+ICB7Cj4gPj4gQEAgLTQ0OSw2ICs0NjcsNyBAQCBpbnQgbGlieGxf
X2RldmljZV9yZW1vdmUobGlieGxfX2djICpnYywKPiA+PiAgICAgIGlmICghc3RhdGUpCj4gPj4g
ICAgICAgICAgZ290byBvdXQ7Cj4gPj4gICAgICBpZiAoYXRvaShzdGF0ZSkgIT0gNCkgewo+ID4+
ICsgICAgICAgIGxpYnhsX19kZXZpY2VfZXhlY3V0ZV9ob3RwbHVnKGdjLCBkZXYpOwo+ID4+ICAg
ICAgICAgIGxpYnhsX19kZXZpY2VfZGVzdHJveV90YXBkaXNrKGdjLCBiZV9wYXRoKTsKPiA+PiAg
ICAgICAgICB4c19ybShjdHgtPnhzaCwgWEJUX05VTEwsIGJlX3BhdGgpOwo+ID4+ICAgICAgICAg
IGdvdG8gb3V0Owo+ID4+IEBAIC00OTIsNiArNTExLDEyIEBAIGludCBsaWJ4bF9fZGV2aWNlX2Rl
c3Ryb3kobGlieGxfX2djICpnYywKPiA+PiAgICAgIGNoYXIgKmJlX3BhdGggPSBsaWJ4bF9fZGV2
aWNlX2JhY2tlbmRfcGF0aChnYywgZGV2KTsKPiA+PiAgICAgIGNoYXIgKmZlX3BhdGggPSBsaWJ4
bF9fZGV2aWNlX2Zyb250ZW5kX3BhdGgoZ2MsIGRldik7Cj4gPj4KPiA+PiArICAgIC8qCj4gPj4g
KyAgICAgKiBSdW4gaG90cGx1ZyBzY3JpcHRzLCB3aGljaCB3aWxsIHByb2JhYmx5IG5vdCBiZSBh
YmxlIHRvCj4gPj4gKyAgICAgKiBleGVjdXRlIHN1Y2Nlc3NmdWxseSBzaW5jZSB0aGUgZGV2aWNl
IG1heSBzdGlsbCBiZSBwbHVnZ2VkCj4gPgo+ID4gV2hhdCBkb2VzIHRoaXMgbWVhbj8gSWYgd2Ug
ZG9uJ3QgZXhwZWN0IGl0IHRvIHdvcmsgd2h5IGFyZSB3ZSBjYWxsaW5nCj4gPiB0aGVtPwo+IAo+
IElmIHlvdSBjYWxsIHRoZSBsaWJ4bF9kb21haW5fZGVzdHJveSBmdW5jdGlvbiB3aXRoIGZvcmNl
ID09IDEsIHRoZQo+IGRlc3Ryb3kgcHJvY2VzcyBkb2Vzbid0IHdhaXQgZm9yIGRldmljZXMgdG8g
YmUgZGlzY29ubmVjdGVkLCBidXQgd2UKPiBtaWdodCBhcyB3ZWxsIHRyeSB0byBleGVjdXRlIGhv
dHBsdWcgc2NyaXB0cywgc2luY2Ugd2UgZG9uJ3Qga25vdyB0aGUKPiBhY3R1YWwgc3RhdGUgb2Yg
dGhlIGRldmljZS4gSWYgd2UgYXJlIGx1Y2t5LCB0aGUgZGV2aWNlIG1pZ2h0IGJlCj4gZGlzY29u
bmVjdGVkIChzdGF0ZSA9PSA2KSwgYW5kIHdlIHNob3VsZCBiZSBhYmxlIHRvIGV4ZWN1dGUgaG90
cGx1Zwo+IHNjcmlwdHMgc3VjY2Vzc2Z1bGx5LgoKSWYgeW91IHBhc3MgdGhlIGFjdGlvbiB0byBi
ZSBwZXJmb3JtZWQgcmF0aGVyIHRoYW4gcmVseWluZyBvbiB0aGUgZGV2aWNlCnN0YXRlIHRoZW4g
cGVyaGFwcyB0aGUgc2NyaXB0cyBoYXZlIGEgYmV0dGVyIGNoYW5jZSBvZiB3b3JraW5nLgoKSG93
ZXZlciBpZiB0aGUgc2NyaXB0IGNhbm5vdCBydW4gcmVsaWFibHkgZm9yIGEgZm9yY2VkIHNodXRk
b3duCihwcmVzdW1hYmx5IHlvdSBjYW5ub3QgdGVhcmRvd24gdGhlIGxvb3AgZGV2aWNlIGlmIGl0
IGlzIHN0aWxsIGluIHVzZSBieQp0aGUgYmFja2VuZD8pIHRoZW4gd2UgbmVlZCB0byBzb2x2ZSB0
aGF0IHNvbWVob3cgcmF0aGVyIHRoYW4gbGVha2luZyB0aGUKcmVzb3VyY2UuCgpJYW4uCgo+IAo+
ID4+ICsgICAgICovCj4gPj4gKyAgICBsaWJ4bF9fZGV2aWNlX2V4ZWN1dGVfaG90cGx1ZyhnYywg
ZGV2KTsKPiA+PiArCj4gPj4gICAgICB4c19ybShjdHgtPnhzaCwgWEJUX05VTEwsIGJlX3BhdGgp
Owo+ID4+ICAgICAgeHNfcm0oY3R4LT54c2gsIFhCVF9OVUxMLCBmZV9wYXRoKTsKPiA+Pgo+ID4+
IGRpZmYgLXIgNGFkOTk4ZmRkYjE2IC1yIDFkODFkMWM0Yzg1MSB0b29scy9saWJ4bC9saWJ4bF9p
bnRlcm5hbC5oCj4gPj4gLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfaW50ZXJuYWwuaCAgICAgIEZy
aSBOb3YgMTggMTE6Mjk6MTQgMjAxMSArMDEwMAo+ID4+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhs
X2ludGVybmFsLmggICAgICBGcmkgU2VwIDMwIDE0OjM4OjU1IDIwMTEgKzAyMDAKPiA+PiBAQCAt
Mjg3LDYgKzI4NywzNCBAQCBfaGlkZGVuIGludCBsaWJ4bF9fd2FpdF9mb3JfZGV2aWNlX3N0YXRl
Cj4gPj4gICAqLwo+ID4+ICBfaGlkZGVuIGludCBsaWJ4bF9fdHJ5X3BoeV9iYWNrZW5kKG1vZGVf
dCBzdF9tb2RlKTsKPiA+Pgo+ID4+ICsvKiBob3RwbHVnIGZ1bmN0aW9ucyAqLwo+ID4+ICsvKgo+
ID4+ICsgKiBsaWJ4bF9fZGV2aWNlX2V4ZWN1dGVfaG90cGx1ZyAtIGdlbmVyaWMgZnVuY3Rpb24g
dG8gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdHMKPiA+PiArICogZ2M6IGFsbG9jYXRpb24gcG9vbAo+
ID4+ICsgKiBkZXY6IHJlZmVyZW5jZSB0byB0aGUgZGV2aWNlIHRoYXQgZXhlY3V0ZXMgdGhlIGhv
dHBsdWcgc2NyaXB0cwo+ID4+ICsgKgo+ID4+ICsgKiBSZXR1cm5zIDAgb24gc3VjY2VzcywgYW5k
IDwgMCBvbiBlcnJvci4KPiA+PiArICovCj4gPj4gK19oaWRkZW4gaW50IGxpYnhsX19kZXZpY2Vf
ZXhlY3V0ZV9ob3RwbHVnKGxpYnhsX19nYyAqZ2MsIGxpYnhsX19kZXZpY2UgKmRldik7Cj4gPj4g
Kwo+ID4+ICsvKgo+ID4+ICsgKiBsaWJ4bF9fZGlza19ob3RwbHVnIC0gZXhlY3V0ZSBob3RwbHVn
IHNjcmlwdCBmb3IgYSBkaXNrIHR5cGUgZGV2aWNlCj4gPj4gKyAqIGdjOiBhbGxvY2F0aW9uIHBv
b2wKPiA+PiArICogZGV2OiByZWZlcmVuY2UgdG8gdGhlIGRpc2sgZGV2aWNlCj4gPj4gKyAqCj4g
Pj4gKyAqIFJldHVybnMgMCBvbiBzdWNjZXNzLCBhbmQgPCAwIG9uIGVycm9yLgo+ID4+ICsgKi8K
PiA+PiArX2hpZGRlbiBpbnQgbGlieGxfX2Rpc2tfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdjLCBsaWJ4
bF9fZGV2aWNlICpkZXYpOwo+ID4+ICsKPiA+PiArLyoKPiA+PiArICogbGlieGxfX25pY19ob3Rw
bHVnIC0gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdCBmb3IgYSBuaWMgdHlwZSBkZXZpY2UKPiA+PiAr
ICogZ2M6IGFsbG9jYXRpb24gcG9vbAo+ID4+ICsgKiBkZXY6IHJlZmVyZW5jZSB0byB0aGUgbmlj
IGRldmljZQo+ID4+ICsgKgo+ID4+ICsgKiBSZXR1cm5zIDAgb24gc3VjY2VzcywgYW5kIDwgMCBv
biBlcnJvci4KPiA+PiArICovCj4gPj4gK19oaWRkZW4gaW50IGxpYnhsX19uaWNfaG90cGx1Zyhs
aWJ4bF9fZ2MgKmdjLCBsaWJ4bF9fZGV2aWNlICpkZXYpOwo+ID4+ICsKPiA+PiAgLyogZnJvbSBs
aWJ4bF9wY2kgKi8KPiA+Pgo+ID4+ICBfaGlkZGVuIGludCBsaWJ4bF9fZGV2aWNlX3BjaV9hZGQo
bGlieGxfX2djICpnYywgdWludDMyX3QgZG9taWQsIGxpYnhsX2RldmljZV9wY2kgKnBjaWRldiwg
aW50IHN0YXJ0aW5nKTsKPiA+Pgo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fCj4gPj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+ID4+IFhlbi1kZXZl
bEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gPj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCj4gPgo+ID4KPiA+CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Nov 21 14:37:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 14:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSUzi-00031k-1L; Mon, 21 Nov 2011 14:37:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSUzf-00031c-Uy
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 14:37:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321886204!3987658!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16288 invoked from network); 21 Nov 2011 14:36:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 14:36:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,547,1315180800"; 
   d="scan'208";a="9043269"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 14:36:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 14:36:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 21 Nov 2011 14:36:43 +0000
In-Reply-To: <CAPLaKK5JF1NeXkq4zkZtaSjvOfY=VrsrvJ-YHE+aFXd1+pkAgw@mail.gmail.com>
References: <patchbomb.1321617576@loki.upc.es>
	<1d81d1c4c851c0b07696.1321617582@loki.upc.es>
	<1321623730.3664.352.camel@zakaz.uk.xensource.com>
	<CAPLaKK5JF1NeXkq4zkZtaSjvOfY=VrsrvJ-YHE+aFXd1+pkAgw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321886203.3664.395.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDExLTExLTIxIGF0IDExOjQyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTEvMTggSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiBPbiBGcmksIDIwMTEtMTEtMTggYXQgMTE6NTkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90
ZToKPiA+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ID4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+ID4+ICMgRGF0ZSAxMzE3Mzg2MzM1IC03MjAwCj4g
Pj4gIyBOb2RlIElEIDFkODFkMWM0Yzg1MWMwYjA3Njk2MzczMzA0ODAxZGY1NmEyMjFlOTAKPiA+
PiAjIFBhcmVudCAgNGFkOTk4ZmRkYjE2YTI5OWNiMjMwZWEyM2JhOTQ0ZDg0YWRiZDJiZgo+ID4+
IGxpYnhsOiBleGVjdXRlIGhvdHBsdWcgc2NyaXB0cyBkaXJlY3RseSBmcm9tIGxpYnhsLgo+ID4+
Cj4gPj4gQWRkZWQgdGhlIG5lY2Vzc2FyeSBoYW5kbGVycyB0byBleGVjdXRlIGhvdHBsdWcgc2Ny
aXB0cyB3aGVuIG5lY2Vzc2FyeQo+ID4+IGZyb20gbGlieGwuIFNwbGl0IE5ldEJTRCBhbmQgTGlu
dXggaG90cGx1ZyBjYWxscyBpbnRvIHR3byBzZXBhcmF0ZQo+ID4+IGZpbGVzLCBiZWNhdXNlIHBh
cmFtZXRlcnMgZm9yIGhvdHBsdWcgc2NyaXB0cyBhcmUgZGlmZmVyZW50LiBMaW51eAo+ID4+IGhh
cyBlbXB0eSBmdW5jdGlvbnMsIHNpbmNlIHRoZSBjYWxsaW5nIG9mIGhvdHBsdWcgc2NyaXB0cyBp
cyBzdGlsbAo+ID4+IGRvbmUgdXNpbmcgdWRldi4KPiA+Pgo+ID4+IFNpZ25lZC1vZmYtYnk6IFJv
Z2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4gPj4KPiA+PiBkaWZmIC1y
IDRhZDk5OGZkZGIxNiAtciAxZDgxZDFjNGM4NTEgdG9vbHMvbGlieGwvTWFrZWZpbGUKPiA+PiAt
LS0gYS90b29scy9saWJ4bC9NYWtlZmlsZSAgICAgIEZyaSBOb3YgMTggMTE6Mjk6MTQgMjAxMSAr
MDEwMAo+ID4+ICsrKyBiL3Rvb2xzL2xpYnhsL01ha2VmaWxlICAgICAgRnJpIFNlcCAzMCAxNDoz
ODo1NSAyMDExICswMjAwCj4gPj4gQEAgLTM0LDggKzM0LDEwIEBAIExJQlhMX09CSlMtJChDT05G
SUdfSUE2NCkgKz0gbGlieGxfbm9jcHUKPiA+Cj4gPiBTaG91bGQgYmU6Cj4gPgo+ID4+ICBpZmVx
ICgkKENPTkZJR19OZXRCU0QpLHkpCj4gPj4gIExJQlhMX09CSlMteSArPSBsaWJ4bF9waHliYWNr
ZW5kLm8KPiA+PiArTElCWExfT0JKUy15ICs9IGhvdHBsdWdfbmV0YnNkLm8KPiA+ICAgZWxzaWYg
KCQoQ09ORklHX0xpbnV4KSx5KQo+ID4+ICBMSUJYTF9PQkpTLXkgKz0gbGlieGxfbm9waHliYWNr
ZW5kLm8KPiA+PiArTElCWExfT0JKUy15ICs9IGhvdHBsdWdfbGludXgubwo+ID4gICBlbHNlCj4g
PiAgICQoZXJyb3IgQSBtZXNzYWdlIG9mIHNvbWUgc29ydCkKPiA+PiAgZW5kaWYKPiAKPiBEb25l
LCBJJ3ZlIG1vdmVkIFBIWSBiYWNrZW5kIHNlbGVjdGlvbiBhbmQgaG90cGx1ZyBzcGVjaWZpYyBm
dW5jdGlvbnMKPiB0byBsaWJ4bF9uZXRic2QuYyBhbmQgbGlieGxfbGludXguYywgYW5kIGFkZGVk
IGFuIGVycm9yIG1lc3NhZ2UgaW4KPiBjYXNlIHNvbWVvbmUgdHJpZXMgdG8gdXNlIGEgZGlmZmVy
ZW50IE9TLgo+IAo+ID4+IGRpZmYgLXIgNGFkOTk4ZmRkYjE2IC1yIDFkODFkMWM0Yzg1MSB0b29s
cy9saWJ4bC9saWJ4bF9kZXZpY2UuYwo+ID4+IC0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2Rldmlj
ZS5jICAgICAgICBGcmkgTm92IDE4IDExOjI5OjE0IDIwMTEgKzAxMDAKPiA+PiArKysgYi90b29s
cy9saWJ4bC9saWJ4bF9kZXZpY2UuYyAgICAgICAgRnJpIFNlcCAzMCAxNDozODo1NSAyMDExICsw
MjAwCj4gPj4gQEAgLTY4LDYgKzY4LDI0IEBAIGludCBsaWJ4bF9fcGFyc2VfYmFja2VuZF9wYXRo
KGxpYnhsX19nYwo+ID4+ICAgICAgcmV0dXJuIGxpYnhsX19kZXZpY2Vfa2luZF9mcm9tX3N0cmlu
ZyhzdHJraW5kLCAmZGV2LT5iYWNrZW5kX2tpbmQpOwo+ID4+ICB9Cj4gPj4KPiA+PiAraW50IGxp
YnhsX19kZXZpY2VfZXhlY3V0ZV9ob3RwbHVnKGxpYnhsX19nYyAqZ2MsIGxpYnhsX19kZXZpY2Ug
KmRldikKPiA+Cj4gPiBObyBuZWVkIGZvciBhIGFkZC9yZW1vdmUgdHlwZSBwYXJhbWV0ZXI/Cj4g
Cj4gQWx0aG91Z2ggeW91IGNvdWxkIHBhc3MgdGhpcyBraW5kIG9mIHBhcmFtZXRlciwgdGhlIGFj
dGlvbiB0byBwZXJmb3JtCj4gaXMgYmFzZWQgb24gdGhlIHN0YXRlIG9mIHRoZSBkZXZpY2UgaW4g
dGhlIGNvcnJlc3BvbmRpbmcgeGVuc3RvcmUKPiBlbnRyeS4gU3RhdGUgMiBtZWFucyB0aGF0IHRo
ZSBkZXZpY2Ugc2hvdWxkIGJlIGNvbm5lY3RlZCwgc3RhdGUgNgo+IG1lYW5zIHRoZSBkZXZpY2Ug
c2hvdWxkIGJlIGRpc2Nvbm5lY3RlZC4KClRoaXMgc2VlbXMgYSBsaXR0bGUgZnJhZ2lsZSBpbiB0
aGUgZmFjZSBvZiB3ZWlyZCBlcnJvcnMgaGFwcGVuaW5nCmFzeW5jaHJvbm91c2x5IGFuZCBjb3Vs
ZCBhbHNvIGJlIHJhY3kgaW4gdGhlIG5vcm1hbCBjYXNlLiBJIHRoaW5rIHlvdQpzaG91bGQgcGFz
cyBpbiB0aGUgYWN0aW9uIHRvIGJlIHBlcmZvcm1lZCBhbmQsIGlmIG5lY2Vzc2FyeSwgY29uZmly
bQp0aGF0IHRoZSBzdGF0ZSBpcyBjb3JyZWN0LiBJZiBwb3NzaWJsZSB5b3Ugc2hvdWxkIGp1c3Qg
cGVyZm9ybSB0aGUKcmVxdWVzdGVkIGFjdGlvbiBpcnJlc3BlY3RpdmUgb2YgdGhlIGJhY2tlbmQg
c3RhdGUuCgo+IAo+ID4+ICt7Cj4gPj4gKyAgICBpbnQgcmMgPSAwOwo+ID4+ICsKPiA+PiArICAg
IHN3aXRjaChkZXYtPmtpbmQpIHsKPiA+PiArICAgIGNhc2UgTElCWExfX0RFVklDRV9LSU5EX1ZJ
RjoKPiA+PiArICAgICAgICByYyA9IGxpYnhsX19uaWNfaG90cGx1ZyhnYywgZGV2KTsKPiA+PiAr
ICAgICAgICBicmVhazsKPiA+PiArICAgIGNhc2UgTElCWExfX0RFVklDRV9LSU5EX1ZCRDoKPiA+
PiArICAgICAgICByYyA9IGxpYnhsX19kaXNrX2hvdHBsdWcoZ2MsIGRldik7Cj4gPj4gKyAgICAg
ICAgYnJlYWs7Cj4gPj4gKyAgICBkZWZhdWx0Ogo+ID4+ICsgICAgICAgIGJyZWFrOwo+ID4+ICsg
ICAgfQo+ID4+ICsKPiA+PiArICAgIHJldHVybiByYzsKPiA+PiArfQo+ID4+ICsKPiA+PiAgaW50
IGxpYnhsX19kZXZpY2VfZ2VuZXJpY19hZGQobGlieGxfX2djICpnYywgbGlieGxfX2RldmljZSAq
ZGV2aWNlLAo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNoYXIgKipiZW50cywg
Y2hhciAqKmZlbnRzKQo+ID4+ICB7Cj4gPj4gQEAgLTQ0OSw2ICs0NjcsNyBAQCBpbnQgbGlieGxf
X2RldmljZV9yZW1vdmUobGlieGxfX2djICpnYywKPiA+PiAgICAgIGlmICghc3RhdGUpCj4gPj4g
ICAgICAgICAgZ290byBvdXQ7Cj4gPj4gICAgICBpZiAoYXRvaShzdGF0ZSkgIT0gNCkgewo+ID4+
ICsgICAgICAgIGxpYnhsX19kZXZpY2VfZXhlY3V0ZV9ob3RwbHVnKGdjLCBkZXYpOwo+ID4+ICAg
ICAgICAgIGxpYnhsX19kZXZpY2VfZGVzdHJveV90YXBkaXNrKGdjLCBiZV9wYXRoKTsKPiA+PiAg
ICAgICAgICB4c19ybShjdHgtPnhzaCwgWEJUX05VTEwsIGJlX3BhdGgpOwo+ID4+ICAgICAgICAg
IGdvdG8gb3V0Owo+ID4+IEBAIC00OTIsNiArNTExLDEyIEBAIGludCBsaWJ4bF9fZGV2aWNlX2Rl
c3Ryb3kobGlieGxfX2djICpnYywKPiA+PiAgICAgIGNoYXIgKmJlX3BhdGggPSBsaWJ4bF9fZGV2
aWNlX2JhY2tlbmRfcGF0aChnYywgZGV2KTsKPiA+PiAgICAgIGNoYXIgKmZlX3BhdGggPSBsaWJ4
bF9fZGV2aWNlX2Zyb250ZW5kX3BhdGgoZ2MsIGRldik7Cj4gPj4KPiA+PiArICAgIC8qCj4gPj4g
KyAgICAgKiBSdW4gaG90cGx1ZyBzY3JpcHRzLCB3aGljaCB3aWxsIHByb2JhYmx5IG5vdCBiZSBh
YmxlIHRvCj4gPj4gKyAgICAgKiBleGVjdXRlIHN1Y2Nlc3NmdWxseSBzaW5jZSB0aGUgZGV2aWNl
IG1heSBzdGlsbCBiZSBwbHVnZ2VkCj4gPgo+ID4gV2hhdCBkb2VzIHRoaXMgbWVhbj8gSWYgd2Ug
ZG9uJ3QgZXhwZWN0IGl0IHRvIHdvcmsgd2h5IGFyZSB3ZSBjYWxsaW5nCj4gPiB0aGVtPwo+IAo+
IElmIHlvdSBjYWxsIHRoZSBsaWJ4bF9kb21haW5fZGVzdHJveSBmdW5jdGlvbiB3aXRoIGZvcmNl
ID09IDEsIHRoZQo+IGRlc3Ryb3kgcHJvY2VzcyBkb2Vzbid0IHdhaXQgZm9yIGRldmljZXMgdG8g
YmUgZGlzY29ubmVjdGVkLCBidXQgd2UKPiBtaWdodCBhcyB3ZWxsIHRyeSB0byBleGVjdXRlIGhv
dHBsdWcgc2NyaXB0cywgc2luY2Ugd2UgZG9uJ3Qga25vdyB0aGUKPiBhY3R1YWwgc3RhdGUgb2Yg
dGhlIGRldmljZS4gSWYgd2UgYXJlIGx1Y2t5LCB0aGUgZGV2aWNlIG1pZ2h0IGJlCj4gZGlzY29u
bmVjdGVkIChzdGF0ZSA9PSA2KSwgYW5kIHdlIHNob3VsZCBiZSBhYmxlIHRvIGV4ZWN1dGUgaG90
cGx1Zwo+IHNjcmlwdHMgc3VjY2Vzc2Z1bGx5LgoKSWYgeW91IHBhc3MgdGhlIGFjdGlvbiB0byBi
ZSBwZXJmb3JtZWQgcmF0aGVyIHRoYW4gcmVseWluZyBvbiB0aGUgZGV2aWNlCnN0YXRlIHRoZW4g
cGVyaGFwcyB0aGUgc2NyaXB0cyBoYXZlIGEgYmV0dGVyIGNoYW5jZSBvZiB3b3JraW5nLgoKSG93
ZXZlciBpZiB0aGUgc2NyaXB0IGNhbm5vdCBydW4gcmVsaWFibHkgZm9yIGEgZm9yY2VkIHNodXRk
b3duCihwcmVzdW1hYmx5IHlvdSBjYW5ub3QgdGVhcmRvd24gdGhlIGxvb3AgZGV2aWNlIGlmIGl0
IGlzIHN0aWxsIGluIHVzZSBieQp0aGUgYmFja2VuZD8pIHRoZW4gd2UgbmVlZCB0byBzb2x2ZSB0
aGF0IHNvbWVob3cgcmF0aGVyIHRoYW4gbGVha2luZyB0aGUKcmVzb3VyY2UuCgpJYW4uCgo+IAo+
ID4+ICsgICAgICovCj4gPj4gKyAgICBsaWJ4bF9fZGV2aWNlX2V4ZWN1dGVfaG90cGx1ZyhnYywg
ZGV2KTsKPiA+PiArCj4gPj4gICAgICB4c19ybShjdHgtPnhzaCwgWEJUX05VTEwsIGJlX3BhdGgp
Owo+ID4+ICAgICAgeHNfcm0oY3R4LT54c2gsIFhCVF9OVUxMLCBmZV9wYXRoKTsKPiA+Pgo+ID4+
IGRpZmYgLXIgNGFkOTk4ZmRkYjE2IC1yIDFkODFkMWM0Yzg1MSB0b29scy9saWJ4bC9saWJ4bF9p
bnRlcm5hbC5oCj4gPj4gLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfaW50ZXJuYWwuaCAgICAgIEZy
aSBOb3YgMTggMTE6Mjk6MTQgMjAxMSArMDEwMAo+ID4+ICsrKyBiL3Rvb2xzL2xpYnhsL2xpYnhs
X2ludGVybmFsLmggICAgICBGcmkgU2VwIDMwIDE0OjM4OjU1IDIwMTEgKzAyMDAKPiA+PiBAQCAt
Mjg3LDYgKzI4NywzNCBAQCBfaGlkZGVuIGludCBsaWJ4bF9fd2FpdF9mb3JfZGV2aWNlX3N0YXRl
Cj4gPj4gICAqLwo+ID4+ICBfaGlkZGVuIGludCBsaWJ4bF9fdHJ5X3BoeV9iYWNrZW5kKG1vZGVf
dCBzdF9tb2RlKTsKPiA+Pgo+ID4+ICsvKiBob3RwbHVnIGZ1bmN0aW9ucyAqLwo+ID4+ICsvKgo+
ID4+ICsgKiBsaWJ4bF9fZGV2aWNlX2V4ZWN1dGVfaG90cGx1ZyAtIGdlbmVyaWMgZnVuY3Rpb24g
dG8gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdHMKPiA+PiArICogZ2M6IGFsbG9jYXRpb24gcG9vbAo+
ID4+ICsgKiBkZXY6IHJlZmVyZW5jZSB0byB0aGUgZGV2aWNlIHRoYXQgZXhlY3V0ZXMgdGhlIGhv
dHBsdWcgc2NyaXB0cwo+ID4+ICsgKgo+ID4+ICsgKiBSZXR1cm5zIDAgb24gc3VjY2VzcywgYW5k
IDwgMCBvbiBlcnJvci4KPiA+PiArICovCj4gPj4gK19oaWRkZW4gaW50IGxpYnhsX19kZXZpY2Vf
ZXhlY3V0ZV9ob3RwbHVnKGxpYnhsX19nYyAqZ2MsIGxpYnhsX19kZXZpY2UgKmRldik7Cj4gPj4g
Kwo+ID4+ICsvKgo+ID4+ICsgKiBsaWJ4bF9fZGlza19ob3RwbHVnIC0gZXhlY3V0ZSBob3RwbHVn
IHNjcmlwdCBmb3IgYSBkaXNrIHR5cGUgZGV2aWNlCj4gPj4gKyAqIGdjOiBhbGxvY2F0aW9uIHBv
b2wKPiA+PiArICogZGV2OiByZWZlcmVuY2UgdG8gdGhlIGRpc2sgZGV2aWNlCj4gPj4gKyAqCj4g
Pj4gKyAqIFJldHVybnMgMCBvbiBzdWNjZXNzLCBhbmQgPCAwIG9uIGVycm9yLgo+ID4+ICsgKi8K
PiA+PiArX2hpZGRlbiBpbnQgbGlieGxfX2Rpc2tfaG90cGx1ZyhsaWJ4bF9fZ2MgKmdjLCBsaWJ4
bF9fZGV2aWNlICpkZXYpOwo+ID4+ICsKPiA+PiArLyoKPiA+PiArICogbGlieGxfX25pY19ob3Rw
bHVnIC0gZXhlY3V0ZSBob3RwbHVnIHNjcmlwdCBmb3IgYSBuaWMgdHlwZSBkZXZpY2UKPiA+PiAr
ICogZ2M6IGFsbG9jYXRpb24gcG9vbAo+ID4+ICsgKiBkZXY6IHJlZmVyZW5jZSB0byB0aGUgbmlj
IGRldmljZQo+ID4+ICsgKgo+ID4+ICsgKiBSZXR1cm5zIDAgb24gc3VjY2VzcywgYW5kIDwgMCBv
biBlcnJvci4KPiA+PiArICovCj4gPj4gK19oaWRkZW4gaW50IGxpYnhsX19uaWNfaG90cGx1Zyhs
aWJ4bF9fZ2MgKmdjLCBsaWJ4bF9fZGV2aWNlICpkZXYpOwo+ID4+ICsKPiA+PiAgLyogZnJvbSBs
aWJ4bF9wY2kgKi8KPiA+Pgo+ID4+ICBfaGlkZGVuIGludCBsaWJ4bF9fZGV2aWNlX3BjaV9hZGQo
bGlieGxfX2djICpnYywgdWludDMyX3QgZG9taWQsIGxpYnhsX2RldmljZV9wY2kgKnBjaWRldiwg
aW50IHN0YXJ0aW5nKTsKPiA+Pgo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fCj4gPj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+ID4+IFhlbi1kZXZl
bEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gPj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCj4gPgo+ID4KPiA+CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Nov 21 15:15:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 15:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSVZx-0003WX-3P; Mon, 21 Nov 2011 15:14:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSVZv-0003WO-VY
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 15:14:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1321888451!4004431!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1502 invoked from network); 21 Nov 2011 15:14:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 15:14:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321888451; l=542;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=uUGt/IcxAYdfjGbl0NGrhnlWVkA=;
	b=WDcsrT9Z4a5gCyfHT0wqycztO/+J+E6KbrpUo4qfLqhNW1a4oOhFoeBIgzhKHs4h93D
	y5JmrZi10kMVPSg88FymUUkSsPAIWyRgkeTetNJbuwHxOwkWEnaG5UcZ2jzwZwVBJkrPG
	EEHYteha8xqMDCsb7IME4MpbJ20L3fjZ6lY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0PFtsQ
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-150.pools.arcor-ip.net [88.65.73.150])
	by smtp.strato.de (cohen mo36) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x04ff6nALEdjtW ;
	Mon, 21 Nov 2011 16:13:59 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4C29918637; Mon, 21 Nov 2011 16:13:59 +0100 (CET)
Date: Mon, 21 Nov 2011 16:13:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111121151359.GA22981@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 21, Stefano Stabellini wrote:

> what if tot_memkb is bigger than target_memkb? Or even bigger than
> max_memkb?

tot_memkb is unrelated to target_memkb, also somewhat unrelated to
max_memkb.

xenpaging will look at tot_memkb value (at "memory/target-tot_pages" to
be precise) and try to reach that number of domain->tot_pages. If the
tot_memkb number is larger than max_memkb nothing will happen.


Right now there is not much checking anyway, memory=1024 maxmem=1 in the
config is accepted in my testing.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 15:15:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 15:15:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSVZx-0003WX-3P; Mon, 21 Nov 2011 15:14:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSVZv-0003WO-VY
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 15:14:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1321888451!4004431!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1502 invoked from network); 21 Nov 2011 15:14:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 15:14:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321888451; l=542;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=uUGt/IcxAYdfjGbl0NGrhnlWVkA=;
	b=WDcsrT9Z4a5gCyfHT0wqycztO/+J+E6KbrpUo4qfLqhNW1a4oOhFoeBIgzhKHs4h93D
	y5JmrZi10kMVPSg88FymUUkSsPAIWyRgkeTetNJbuwHxOwkWEnaG5UcZ2jzwZwVBJkrPG
	EEHYteha8xqMDCsb7IME4MpbJ20L3fjZ6lY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0PFtsQ
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-150.pools.arcor-ip.net [88.65.73.150])
	by smtp.strato.de (cohen mo36) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x04ff6nALEdjtW ;
	Mon, 21 Nov 2011 16:13:59 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4C29918637; Mon, 21 Nov 2011 16:13:59 +0100 (CET)
Date: Mon, 21 Nov 2011 16:13:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111121151359.GA22981@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 21, Stefano Stabellini wrote:

> what if tot_memkb is bigger than target_memkb? Or even bigger than
> max_memkb?

tot_memkb is unrelated to target_memkb, also somewhat unrelated to
max_memkb.

xenpaging will look at tot_memkb value (at "memory/target-tot_pages" to
be precise) and try to reach that number of domain->tot_pages. If the
tot_memkb number is larger than max_memkb nothing will happen.


Right now there is not much checking anyway, memory=1024 maxmem=1 in the
config is accepted in my testing.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 15:16:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 15:16:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSVan-0003ZP-Oc; Mon, 21 Nov 2011 15:15:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSVam-0003Z1-5r
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 15:15:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321888504!5138765!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27162 invoked from network); 21 Nov 2011 15:15:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 15:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,547,1315180800"; 
   d="scan'208";a="9044515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 15:15:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 15:15:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSVaJ-0005TT-VK; Mon, 21 Nov 2011 15:15:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSVaJ-0000Ht-Ub;
	Mon, 21 Nov 2011 15:15:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20170.27383.935924.977643@mariner.uk.xensource.com>
Date: Mon, 21 Nov 2011 15:15:03 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EBA6CF7020000780005FD1E@nat28.tlf.novell.com>
References: <osstest-9733-mainreport@xen.org>
	<4EBA6CF7020000780005FD1E@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 9733: regressions -	 trouble:
 blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 9733: regressions -	 trouble: blocked/broken/fail/pass"):
> Repeating a reply to an earlier regression report - earwig continues to
> be on c/s 24069:
> 
> Nov  9 02:07:03.138530 (XEN) Xen version 4.2-unstable (osstest@cam.xci-test.com) (gcc version 4.4.5 (Debian 4.4.5-8) ) Thu Nov  3 20:23:16 GMT 2011
> Nov  9 02:07:03.158495 (XEN) Latest ChangeSet: Thu Nov 03 17:28:41 2011 +0100 24069:801ca6c0fbfa
> 
> Which continues to block the regression fixes (24081 and 24108) from
> getting validated/pushed (or useful data - for analysis - to be produced).

Thanks for this report.  Sorry about the delay replying, I've been
busy migrating our services to the new hosting and I have an enormous
email backlog now.

This failure occurred on earwig.  I took earwig out of the test pool a
few weeks ago.

>  build-amd64                   2 host-install(2)              broken

And, the changeset discrepancy is because:
  - earwig is busted and will no longer boot from the network
  - its last serial console message therefore always shows the
    last version of Xen installed on its hard disk
  - none of this involves the xen that was built as part of this
    flight; the failure here is at the point of installing
    Debian native.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 15:16:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 15:16:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSVan-0003ZP-Oc; Mon, 21 Nov 2011 15:15:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSVam-0003Z1-5r
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 15:15:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1321888504!5138765!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27162 invoked from network); 21 Nov 2011 15:15:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 15:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,547,1315180800"; 
   d="scan'208";a="9044515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 15:15:04 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 15:15:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSVaJ-0005TT-VK; Mon, 21 Nov 2011 15:15:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSVaJ-0000Ht-Ub;
	Mon, 21 Nov 2011 15:15:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20170.27383.935924.977643@mariner.uk.xensource.com>
Date: Mon, 21 Nov 2011 15:15:03 +0000
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EBA6CF7020000780005FD1E@nat28.tlf.novell.com>
References: <osstest-9733-mainreport@xen.org>
	<4EBA6CF7020000780005FD1E@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 9733: regressions -	 trouble:
 blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 9733: regressions -	 trouble: blocked/broken/fail/pass"):
> Repeating a reply to an earlier regression report - earwig continues to
> be on c/s 24069:
> 
> Nov  9 02:07:03.138530 (XEN) Xen version 4.2-unstable (osstest@cam.xci-test.com) (gcc version 4.4.5 (Debian 4.4.5-8) ) Thu Nov  3 20:23:16 GMT 2011
> Nov  9 02:07:03.158495 (XEN) Latest ChangeSet: Thu Nov 03 17:28:41 2011 +0100 24069:801ca6c0fbfa
> 
> Which continues to block the regression fixes (24081 and 24108) from
> getting validated/pushed (or useful data - for analysis - to be produced).

Thanks for this report.  Sorry about the delay replying, I've been
busy migrating our services to the new hosting and I have an enormous
email backlog now.

This failure occurred on earwig.  I took earwig out of the test pool a
few weeks ago.

>  build-amd64                   2 host-install(2)              broken

And, the changeset discrepancy is because:
  - earwig is busted and will no longer boot from the network
  - its last serial console message therefore always shows the
    last version of Xen installed on its hard disk
  - none of this involves the xen that was built as part of this
    flight; the failure here is at the point of installing
    Debian native.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 16:42:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 16:42:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSWvs-0004SO-R5; Mon, 21 Nov 2011 16:41:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RSWvr-0004S4-DS
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 16:41:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321893654!4411260!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13442 invoked from network); 21 Nov 2011 16:40:55 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 16:40:55 -0000
Received: by ggnr4 with SMTP id r4so1972353ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 08:40:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=KALcwst1GvP23VliDUdM6IKBGOz2dfAj3XPss9HcT3Q=;
	b=dK0bkZ8vrS02bAech/7G05oCwMieJQbWpbSGMApHi58Oxm01zyEOf+5PGLYTUXve0r
	Jor1aJR2fUt5ZHNA6RkPotnuDcafWcOQ09rXZzJ6nu59LZK52w2Y+9+qrKsZnAzj6Std
	FsjXd5VfbbSEgk8F2RCsrkTbmokSgdS/f/hiw=
MIME-Version: 1.0
Received: by 10.50.169.1 with SMTP id aa1mr15454045igc.9.1321893654311; Mon,
	21 Nov 2011 08:40:54 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Mon, 21 Nov 2011 08:40:54 -0800 (PST)
In-Reply-To: <20111121151359.GA22981@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
Date: Mon, 21 Nov 2011 16:40:54 +0000
X-Google-Sender-Auth: hx95lDRhkb5rkyURoaVogqtssG4
Message-ID: <CAFLBxZYMmjH7cXcTyHzxN+xBcXVi=ThS16U=qX=4BgV_V0G1iA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 21, 2011 at 3:13 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Nov 21, Stefano Stabellini wrote:
>
>> what if tot_memkb is bigger than target_memkb? Or even bigger than
>> max_memkb?
>
> tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> max_memkb.

I'd love to contribute to this discussion, but I don't know what these
different names mean.  I think what we need to talk about is all of
the different memory parameters we need, and then what each of the
individual names mean -- what they currently map to, and then what we
want them to map to.  At very least they should be in a comment
somewhere.

>
> xenpaging will look at tot_memkb value (at "memory/target-tot_pages" to
> be precise) and try to reach that number of domain->tot_pages. If the
> tot_memkb number is larger than max_memkb nothing will happen.
>
>
> Right now there is not much checking anyway, memory=1024 maxmem=1 in the
> config is accepted in my testing.
>
> Olaf
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 16:42:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 16:42:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSWvs-0004SO-R5; Mon, 21 Nov 2011 16:41:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RSWvr-0004S4-DS
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 16:41:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321893654!4411260!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13442 invoked from network); 21 Nov 2011 16:40:55 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 16:40:55 -0000
Received: by ggnr4 with SMTP id r4so1972353ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 08:40:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=KALcwst1GvP23VliDUdM6IKBGOz2dfAj3XPss9HcT3Q=;
	b=dK0bkZ8vrS02bAech/7G05oCwMieJQbWpbSGMApHi58Oxm01zyEOf+5PGLYTUXve0r
	Jor1aJR2fUt5ZHNA6RkPotnuDcafWcOQ09rXZzJ6nu59LZK52w2Y+9+qrKsZnAzj6Std
	FsjXd5VfbbSEgk8F2RCsrkTbmokSgdS/f/hiw=
MIME-Version: 1.0
Received: by 10.50.169.1 with SMTP id aa1mr15454045igc.9.1321893654311; Mon,
	21 Nov 2011 08:40:54 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Mon, 21 Nov 2011 08:40:54 -0800 (PST)
In-Reply-To: <20111121151359.GA22981@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
Date: Mon, 21 Nov 2011 16:40:54 +0000
X-Google-Sender-Auth: hx95lDRhkb5rkyURoaVogqtssG4
Message-ID: <CAFLBxZYMmjH7cXcTyHzxN+xBcXVi=ThS16U=qX=4BgV_V0G1iA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 21, 2011 at 3:13 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Nov 21, Stefano Stabellini wrote:
>
>> what if tot_memkb is bigger than target_memkb? Or even bigger than
>> max_memkb?
>
> tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> max_memkb.

I'd love to contribute to this discussion, but I don't know what these
different names mean.  I think what we need to talk about is all of
the different memory parameters we need, and then what each of the
individual names mean -- what they currently map to, and then what we
want them to map to.  At very least they should be in a comment
somewhere.

>
> xenpaging will look at tot_memkb value (at "memory/target-tot_pages" to
> be precise) and try to reach that number of domain->tot_pages. If the
> tot_memkb number is larger than max_memkb nothing will happen.
>
>
> Right now there is not much checking anyway, memory=1024 maxmem=1 in the
> config is accepted in my testing.
>
> Olaf
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 16:43:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 16:43:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSWxP-0004YY-Hr; Mon, 21 Nov 2011 16:42:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSWxO-0004YG-AD
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 16:42:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1321893749!2443064!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22410 invoked from network); 21 Nov 2011 16:42:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 16:42:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 21 Nov 2011 16:42:29 +0000
Message-Id: <4ECA8D8302000078000622EA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 21 Nov 2011 16:42:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF0DF7963.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/backends: remove version specific
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartF0DF7963.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Backends, other than frontends and come parts of core code, aren't
meant to be built against multiple Linux versions (and they wouldn't
really build anyway), so remove the code dealing with this case.

This really is mostly the removal of pointless inclusions of
linux/version.h, but in the case of blktap also includes some dead
code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/blkback/common.h
+++ b/drivers/xen/blkback/common.h
@@ -27,7 +27,6 @@
 #ifndef __BLKIF__BACKEND__COMMON_H__
 #define __BLKIF__BACKEND__COMMON_H__
=20
-#include <linux/version.h>
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/slab.h>
--- a/drivers/xen/blktap/common.h
+++ b/drivers/xen/blktap/common.h
@@ -27,7 +27,6 @@
 #ifndef __BLKIF__BACKEND__COMMON_H__
 #define __BLKIF__BACKEND__COMMON_H__
=20
-#include <linux/version.h>
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/slab.h>
--- a/drivers/xen/blktap2/device.c
+++ b/drivers/xen/blktap2/device.c
@@ -93,27 +93,6 @@ blktap_device_ioctl(struct inode *inode,
 		      command, (long)argument, inode->i_rdev);
=20
 	switch (command) {
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)
-	case HDIO_GETGEO: {
-		struct block_device *bd =3D inode->i_bdev;
-		struct hd_geometry geo;
-		int ret;
-
-                if (!argument)
-                        return -EINVAL;
-
-		geo.start =3D get_start_sect(bd);
-		ret =3D blktap_device_getgeo(bd, &geo);
-		if (ret)
-			return ret;
-
-		if (copy_to_user((struct hd_geometry __user *)argument, =
&geo,
-				 sizeof(geo)))
-                        return -EFAULT;
-
-                return 0;
-	}
-#endif
 	case CDROMMULTISESSION:
 		BTDBG("FIXME: support multisession CDs later\n");
 		for (i =3D 0; i < sizeof(struct cdrom_multisession); i++)
@@ -146,9 +125,7 @@ static struct block_device_operations bl
 	.open      =3D blktap_device_open,
 	.release   =3D blktap_device_release,
 	.ioctl     =3D blktap_device_ioctl,
-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,16)
 	.getgeo    =3D blktap_device_getgeo
-#endif
 };
=20
 static int
@@ -1135,11 +1112,7 @@ blktap_device_create(struct blktap *tap)
 	if (!rq)
 		goto error;
=20
-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)
 	elevator_init(rq, "noop");
-#else
-	elevator_init(rq, &elevator_noop);
-#endif
=20
 	gd->queue     =3D rq;
 	rq->queuedata =3D dev;
--- a/drivers/xen/netback/common.h
+++ b/drivers/xen/netback/common.h
@@ -29,7 +29,6 @@
 #ifndef __NETIF__BACKEND__COMMON_H__
 #define __NETIF__BACKEND__COMMON_H__
=20
-#include <linux/version.h>
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/slab.h>
--- a/drivers/xen/pcifront/pci_op.c
+++ b/drivers/xen/pcifront/pci_op.c
@@ -4,7 +4,6 @@
  *   Author: Ryan Wilson <hap9@epoch.ncsc.mil>
  */
 #include <linux/module.h>
-#include <linux/version.h>
 #include <linux/init.h>
 #include <linux/pci.h>
 #include <linux/spinlock.h>
--- a/drivers/xen/scsiback/common.h
+++ b/drivers/xen/scsiback/common.h
@@ -31,7 +31,6 @@
 #ifndef __SCSIIF__BACKEND__COMMON_H__
 #define __SCSIIF__BACKEND__COMMON_H__
=20
-#include <linux/version.h>
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/slab.h>
--- a/drivers/xen/tpmback/common.h
+++ b/drivers/xen/tpmback/common.h
@@ -5,7 +5,6 @@
 #ifndef __TPM__BACKEND__COMMON_H__
 #define __TPM__BACKEND__COMMON_H__
=20
-#include <linux/version.h>
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/mm.h>




--=__PartF0DF7963.0__=
Content-Type: text/plain; name="xen-no-linux-version.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-no-linux-version.patch"

backends: remove version specific code=0A=0ABackends, other than frontends =
and come parts of core code, aren't=0Ameant to be built against multiple =
Linux versions (and they wouldn't=0Areally build anyway), so remove the =
code dealing with this case.=0A=0AThis really is mostly the removal of =
pointless inclusions of=0Alinux/version.h, but in the case of blktap also =
includes some dead=0Acode.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.c=
om>=0A=0A--- a/drivers/xen/blkback/common.h=0A+++ b/drivers/xen/blkback/com=
mon.h=0A@@ -27,7 +27,6 @@=0A #ifndef __BLKIF__BACKEND__COMMON_H__=0A =
#define __BLKIF__BACKEND__COMMON_H__=0A =0A-#include <linux/version.h>=0A =
#include <linux/module.h>=0A #include <linux/interrupt.h>=0A #include =
<linux/slab.h>=0A--- a/drivers/xen/blktap/common.h=0A+++ b/drivers/xen/blkt=
ap/common.h=0A@@ -27,7 +27,6 @@=0A #ifndef __BLKIF__BACKEND__COMMON_H__=0A =
#define __BLKIF__BACKEND__COMMON_H__=0A =0A-#include <linux/version.h>=0A =
#include <linux/module.h>=0A #include <linux/interrupt.h>=0A #include =
<linux/slab.h>=0A--- a/drivers/xen/blktap2/device.c=0A+++ b/drivers/xen/blk=
tap2/device.c=0A@@ -93,27 +93,6 @@ blktap_device_ioctl(struct inode =
*inode,=0A 		      command, (long)argument, inode->i_rdev);=0A =
=0A 	switch (command) {=0A-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,1=
6)=0A-	case HDIO_GETGEO: {=0A-		struct block_device *bd =3D =
inode->i_bdev;=0A-		struct hd_geometry geo;=0A-		=
int ret;=0A-=0A-                if (!argument)=0A-                        =
return -EINVAL;=0A-=0A-		geo.start =3D get_start_sect(bd);=0A-		=
ret =3D blktap_device_getgeo(bd, &geo);=0A-		if (ret)=0A-		=
	return ret;=0A-=0A-		if (copy_to_user((struct hd_geometr=
y __user *)argument, &geo,=0A-				 sizeof(geo)))=0A- =
                       return -EFAULT;=0A-=0A-                return =
0;=0A-	}=0A-#endif=0A 	case CDROMMULTISESSION:=0A 		BTDBG("FIXM=
E: support multisession CDs later\n");=0A 		for (i =3D 0; i < =
sizeof(struct cdrom_multisession); i++)=0A@@ -146,9 +125,7 @@ static =
struct block_device_operations bl=0A 	.open      =3D blktap_device_open,=
=0A 	.release   =3D blktap_device_release,=0A 	.ioctl     =3D =
blktap_device_ioctl,=0A-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,16)=
=0A 	.getgeo    =3D blktap_device_getgeo=0A-#endif=0A };=0A =0A static =
int=0A@@ -1135,11 +1112,7 @@ blktap_device_create(struct blktap *tap)=0A 	=
if (!rq)=0A 		goto error;=0A =0A-#if LINUX_VERSION_CODE >=3D =
KERNEL_VERSION(2,6,10)=0A 	elevator_init(rq, "noop");=0A-#else=0A-	=
elevator_init(rq, &elevator_noop);=0A-#endif=0A =0A 	gd->queue     =3D =
rq;=0A 	rq->queuedata =3D dev;=0A--- a/drivers/xen/netback/common.h=0A+++ =
b/drivers/xen/netback/common.h=0A@@ -29,7 +29,6 @@=0A #ifndef __NETIF__BACK=
END__COMMON_H__=0A #define __NETIF__BACKEND__COMMON_H__=0A =0A-#include =
<linux/version.h>=0A #include <linux/module.h>=0A #include <linux/interrupt=
.h>=0A #include <linux/slab.h>=0A--- a/drivers/xen/pcifront/pci_op.c=0A+++ =
b/drivers/xen/pcifront/pci_op.c=0A@@ -4,7 +4,6 @@=0A  *   Author: Ryan =
Wilson <hap9@epoch.ncsc.mil>=0A  */=0A #include <linux/module.h>=0A-#includ=
e <linux/version.h>=0A #include <linux/init.h>=0A #include <linux/pci.h>=0A=
 #include <linux/spinlock.h>=0A--- a/drivers/xen/scsiback/common.h=0A+++ =
b/drivers/xen/scsiback/common.h=0A@@ -31,7 +31,6 @@=0A #ifndef __SCSIIF__BA=
CKEND__COMMON_H__=0A #define __SCSIIF__BACKEND__COMMON_H__=0A =0A-#include =
<linux/version.h>=0A #include <linux/module.h>=0A #include <linux/interrupt=
.h>=0A #include <linux/slab.h>=0A--- a/drivers/xen/tpmback/common.h=0A+++ =
b/drivers/xen/tpmback/common.h=0A@@ -5,7 +5,6 @@=0A #ifndef __TPM__BACKEND_=
_COMMON_H__=0A #define __TPM__BACKEND__COMMON_H__=0A =0A-#include =
<linux/version.h>=0A #include <linux/module.h>=0A #include <linux/interrupt=
.h>=0A #include <linux/mm.h>=0A
--=__PartF0DF7963.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartF0DF7963.0__=--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 16:43:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 16:43:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSWxP-0004YY-Hr; Mon, 21 Nov 2011 16:42:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSWxO-0004YG-AD
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 16:42:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1321893749!2443064!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22410 invoked from network); 21 Nov 2011 16:42:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Nov 2011 16:42:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 21 Nov 2011 16:42:29 +0000
Message-Id: <4ECA8D8302000078000622EA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 21 Nov 2011 16:42:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF0DF7963.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/backends: remove version specific
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartF0DF7963.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Backends, other than frontends and come parts of core code, aren't
meant to be built against multiple Linux versions (and they wouldn't
really build anyway), so remove the code dealing with this case.

This really is mostly the removal of pointless inclusions of
linux/version.h, but in the case of blktap also includes some dead
code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/blkback/common.h
+++ b/drivers/xen/blkback/common.h
@@ -27,7 +27,6 @@
 #ifndef __BLKIF__BACKEND__COMMON_H__
 #define __BLKIF__BACKEND__COMMON_H__
=20
-#include <linux/version.h>
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/slab.h>
--- a/drivers/xen/blktap/common.h
+++ b/drivers/xen/blktap/common.h
@@ -27,7 +27,6 @@
 #ifndef __BLKIF__BACKEND__COMMON_H__
 #define __BLKIF__BACKEND__COMMON_H__
=20
-#include <linux/version.h>
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/slab.h>
--- a/drivers/xen/blktap2/device.c
+++ b/drivers/xen/blktap2/device.c
@@ -93,27 +93,6 @@ blktap_device_ioctl(struct inode *inode,
 		      command, (long)argument, inode->i_rdev);
=20
 	switch (command) {
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)
-	case HDIO_GETGEO: {
-		struct block_device *bd =3D inode->i_bdev;
-		struct hd_geometry geo;
-		int ret;
-
-                if (!argument)
-                        return -EINVAL;
-
-		geo.start =3D get_start_sect(bd);
-		ret =3D blktap_device_getgeo(bd, &geo);
-		if (ret)
-			return ret;
-
-		if (copy_to_user((struct hd_geometry __user *)argument, =
&geo,
-				 sizeof(geo)))
-                        return -EFAULT;
-
-                return 0;
-	}
-#endif
 	case CDROMMULTISESSION:
 		BTDBG("FIXME: support multisession CDs later\n");
 		for (i =3D 0; i < sizeof(struct cdrom_multisession); i++)
@@ -146,9 +125,7 @@ static struct block_device_operations bl
 	.open      =3D blktap_device_open,
 	.release   =3D blktap_device_release,
 	.ioctl     =3D blktap_device_ioctl,
-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,16)
 	.getgeo    =3D blktap_device_getgeo
-#endif
 };
=20
 static int
@@ -1135,11 +1112,7 @@ blktap_device_create(struct blktap *tap)
 	if (!rq)
 		goto error;
=20
-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,10)
 	elevator_init(rq, "noop");
-#else
-	elevator_init(rq, &elevator_noop);
-#endif
=20
 	gd->queue     =3D rq;
 	rq->queuedata =3D dev;
--- a/drivers/xen/netback/common.h
+++ b/drivers/xen/netback/common.h
@@ -29,7 +29,6 @@
 #ifndef __NETIF__BACKEND__COMMON_H__
 #define __NETIF__BACKEND__COMMON_H__
=20
-#include <linux/version.h>
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/slab.h>
--- a/drivers/xen/pcifront/pci_op.c
+++ b/drivers/xen/pcifront/pci_op.c
@@ -4,7 +4,6 @@
  *   Author: Ryan Wilson <hap9@epoch.ncsc.mil>
  */
 #include <linux/module.h>
-#include <linux/version.h>
 #include <linux/init.h>
 #include <linux/pci.h>
 #include <linux/spinlock.h>
--- a/drivers/xen/scsiback/common.h
+++ b/drivers/xen/scsiback/common.h
@@ -31,7 +31,6 @@
 #ifndef __SCSIIF__BACKEND__COMMON_H__
 #define __SCSIIF__BACKEND__COMMON_H__
=20
-#include <linux/version.h>
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/slab.h>
--- a/drivers/xen/tpmback/common.h
+++ b/drivers/xen/tpmback/common.h
@@ -5,7 +5,6 @@
 #ifndef __TPM__BACKEND__COMMON_H__
 #define __TPM__BACKEND__COMMON_H__
=20
-#include <linux/version.h>
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/mm.h>




--=__PartF0DF7963.0__=
Content-Type: text/plain; name="xen-no-linux-version.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-no-linux-version.patch"

backends: remove version specific code=0A=0ABackends, other than frontends =
and come parts of core code, aren't=0Ameant to be built against multiple =
Linux versions (and they wouldn't=0Areally build anyway), so remove the =
code dealing with this case.=0A=0AThis really is mostly the removal of =
pointless inclusions of=0Alinux/version.h, but in the case of blktap also =
includes some dead=0Acode.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.c=
om>=0A=0A--- a/drivers/xen/blkback/common.h=0A+++ b/drivers/xen/blkback/com=
mon.h=0A@@ -27,7 +27,6 @@=0A #ifndef __BLKIF__BACKEND__COMMON_H__=0A =
#define __BLKIF__BACKEND__COMMON_H__=0A =0A-#include <linux/version.h>=0A =
#include <linux/module.h>=0A #include <linux/interrupt.h>=0A #include =
<linux/slab.h>=0A--- a/drivers/xen/blktap/common.h=0A+++ b/drivers/xen/blkt=
ap/common.h=0A@@ -27,7 +27,6 @@=0A #ifndef __BLKIF__BACKEND__COMMON_H__=0A =
#define __BLKIF__BACKEND__COMMON_H__=0A =0A-#include <linux/version.h>=0A =
#include <linux/module.h>=0A #include <linux/interrupt.h>=0A #include =
<linux/slab.h>=0A--- a/drivers/xen/blktap2/device.c=0A+++ b/drivers/xen/blk=
tap2/device.c=0A@@ -93,27 +93,6 @@ blktap_device_ioctl(struct inode =
*inode,=0A 		      command, (long)argument, inode->i_rdev);=0A =
=0A 	switch (command) {=0A-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,1=
6)=0A-	case HDIO_GETGEO: {=0A-		struct block_device *bd =3D =
inode->i_bdev;=0A-		struct hd_geometry geo;=0A-		=
int ret;=0A-=0A-                if (!argument)=0A-                        =
return -EINVAL;=0A-=0A-		geo.start =3D get_start_sect(bd);=0A-		=
ret =3D blktap_device_getgeo(bd, &geo);=0A-		if (ret)=0A-		=
	return ret;=0A-=0A-		if (copy_to_user((struct hd_geometr=
y __user *)argument, &geo,=0A-				 sizeof(geo)))=0A- =
                       return -EFAULT;=0A-=0A-                return =
0;=0A-	}=0A-#endif=0A 	case CDROMMULTISESSION:=0A 		BTDBG("FIXM=
E: support multisession CDs later\n");=0A 		for (i =3D 0; i < =
sizeof(struct cdrom_multisession); i++)=0A@@ -146,9 +125,7 @@ static =
struct block_device_operations bl=0A 	.open      =3D blktap_device_open,=
=0A 	.release   =3D blktap_device_release,=0A 	.ioctl     =3D =
blktap_device_ioctl,=0A-#if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,16)=
=0A 	.getgeo    =3D blktap_device_getgeo=0A-#endif=0A };=0A =0A static =
int=0A@@ -1135,11 +1112,7 @@ blktap_device_create(struct blktap *tap)=0A 	=
if (!rq)=0A 		goto error;=0A =0A-#if LINUX_VERSION_CODE >=3D =
KERNEL_VERSION(2,6,10)=0A 	elevator_init(rq, "noop");=0A-#else=0A-	=
elevator_init(rq, &elevator_noop);=0A-#endif=0A =0A 	gd->queue     =3D =
rq;=0A 	rq->queuedata =3D dev;=0A--- a/drivers/xen/netback/common.h=0A+++ =
b/drivers/xen/netback/common.h=0A@@ -29,7 +29,6 @@=0A #ifndef __NETIF__BACK=
END__COMMON_H__=0A #define __NETIF__BACKEND__COMMON_H__=0A =0A-#include =
<linux/version.h>=0A #include <linux/module.h>=0A #include <linux/interrupt=
.h>=0A #include <linux/slab.h>=0A--- a/drivers/xen/pcifront/pci_op.c=0A+++ =
b/drivers/xen/pcifront/pci_op.c=0A@@ -4,7 +4,6 @@=0A  *   Author: Ryan =
Wilson <hap9@epoch.ncsc.mil>=0A  */=0A #include <linux/module.h>=0A-#includ=
e <linux/version.h>=0A #include <linux/init.h>=0A #include <linux/pci.h>=0A=
 #include <linux/spinlock.h>=0A--- a/drivers/xen/scsiback/common.h=0A+++ =
b/drivers/xen/scsiback/common.h=0A@@ -31,7 +31,6 @@=0A #ifndef __SCSIIF__BA=
CKEND__COMMON_H__=0A #define __SCSIIF__BACKEND__COMMON_H__=0A =0A-#include =
<linux/version.h>=0A #include <linux/module.h>=0A #include <linux/interrupt=
.h>=0A #include <linux/slab.h>=0A--- a/drivers/xen/tpmback/common.h=0A+++ =
b/drivers/xen/tpmback/common.h=0A@@ -5,7 +5,6 @@=0A #ifndef __TPM__BACKEND_=
_COMMON_H__=0A #define __TPM__BACKEND__COMMON_H__=0A =0A-#include =
<linux/version.h>=0A #include <linux/module.h>=0A #include <linux/interrupt=
.h>=0A #include <linux/mm.h>=0A
--=__PartF0DF7963.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartF0DF7963.0__=--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 18:49:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 18:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSYuo-0006OC-Px; Mon, 21 Nov 2011 18:48:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSYun-0006O7-2A
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 18:48:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1321901276!4380963!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26992 invoked from network); 21 Nov 2011 18:47:57 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 18:47:57 -0000
Received: by wwp14 with SMTP id 14so8768869wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 10:47:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=RgShx9E5dOQRCz0oVFWqcybWRKezyb6NWikjE0BBwgc=;
	b=J7HasJ2YVVJ1Kx/cXftXYTln+P7WayUAXOdXYR+pFVLCejSe6GeYIEPkfJ30NCUjUR
	1PAYn7G8Kh+zmaVLhSNEFVAYDCz5iGK99hgVW91RebtS4lFXN6B3UfTJBp4SbJ9bxTcU
	6Cp2dHqqUa3QFxWBR9p8oYUJ1ae0SINkvaE+U=
Received: by 10.227.5.205 with SMTP id 13mr290708wbw.5.1321901276632;
	Mon, 21 Nov 2011 10:47:56 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id v6sm5507821wix.1.2011.11.21.10.47.51
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 10:47:54 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 18:47:45 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <CAF04D51.2551E%keir.xen@gmail.com>
Thread-Topic: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel
Thread-Index: AcyoRHTvsBS6PpBQWUeP73gvHOZGeQAOZmZ5
In-Reply-To: <CAEFECAE.2549B%keir.xen@gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 11:55, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 21/11/2011 11:37, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> 
>> xen.org writes ("[xen-unstable bisection] complete
>> test-amd64-i386-rhel6hvm-intel"):
>>> branch xen-unstable
>>> xen branch xen-unstable
>>> job test-amd64-i386-rhel6hvm-intel
>>> test redhat-install
>>> 
>>> Tree: linux git://github.com/jsgf/linux-xen.git
>>> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
>>> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
>>> 
>>> *** Found and reproduced problem changeset ***
>>> 
>>>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>>>   Bug introduced:  7a9a1261a6b0
>>>   Bug not present: 9a1a71f7bef2
>> 
>> This seems to have completely broken HVM ...
> 
> I'll revert if there's no fix forthcoming.

I hear silence so I will revert the series tomorrow morning.

>  -- Keir
> 
>>>   changeset:   24163:7a9a1261a6b0
>>>   user:        Jean Guyader <jean.guyader@eu.citrix.com>
>>>   date:        Fri Nov 18 13:41:33 2011 +0000
>>>       
>>>       add_to_physmap: Move the code for XENMEM_add_to_physmap
>>>       
>>>       Move the code for the XENMEM_add_to_physmap case into it's own
>>>       function (xenmem_add_to_physmap).
>>>       
>>>       Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>>       Committed-by: Keir Fraser <keir@xen.org>
>> 
>> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 18:49:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 18:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSYuo-0006OC-Px; Mon, 21 Nov 2011 18:48:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSYun-0006O7-2A
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 18:48:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1321901276!4380963!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26992 invoked from network); 21 Nov 2011 18:47:57 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 18:47:57 -0000
Received: by wwp14 with SMTP id 14so8768869wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 10:47:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=RgShx9E5dOQRCz0oVFWqcybWRKezyb6NWikjE0BBwgc=;
	b=J7HasJ2YVVJ1Kx/cXftXYTln+P7WayUAXOdXYR+pFVLCejSe6GeYIEPkfJ30NCUjUR
	1PAYn7G8Kh+zmaVLhSNEFVAYDCz5iGK99hgVW91RebtS4lFXN6B3UfTJBp4SbJ9bxTcU
	6Cp2dHqqUa3QFxWBR9p8oYUJ1ae0SINkvaE+U=
Received: by 10.227.5.205 with SMTP id 13mr290708wbw.5.1321901276632;
	Mon, 21 Nov 2011 10:47:56 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id v6sm5507821wix.1.2011.11.21.10.47.51
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 10:47:54 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 18:47:45 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <CAF04D51.2551E%keir.xen@gmail.com>
Thread-Topic: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-intel
Thread-Index: AcyoRHTvsBS6PpBQWUeP73gvHOZGeQAOZmZ5
In-Reply-To: <CAEFECAE.2549B%keir.xen@gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 11:55, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 21/11/2011 11:37, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> 
>> xen.org writes ("[xen-unstable bisection] complete
>> test-amd64-i386-rhel6hvm-intel"):
>>> branch xen-unstable
>>> xen branch xen-unstable
>>> job test-amd64-i386-rhel6hvm-intel
>>> test redhat-install
>>> 
>>> Tree: linux git://github.com/jsgf/linux-xen.git
>>> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
>>> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
>>> 
>>> *** Found and reproduced problem changeset ***
>>> 
>>>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>>>   Bug introduced:  7a9a1261a6b0
>>>   Bug not present: 9a1a71f7bef2
>> 
>> This seems to have completely broken HVM ...
> 
> I'll revert if there's no fix forthcoming.

I hear silence so I will revert the series tomorrow morning.

>  -- Keir
> 
>>>   changeset:   24163:7a9a1261a6b0
>>>   user:        Jean Guyader <jean.guyader@eu.citrix.com>
>>>   date:        Fri Nov 18 13:41:33 2011 +0000
>>>       
>>>       add_to_physmap: Move the code for XENMEM_add_to_physmap
>>>       
>>>       Move the code for the XENMEM_add_to_physmap case into it's own
>>>       function (xenmem_add_to_physmap).
>>>       
>>>       Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>>       Committed-by: Keir Fraser <keir@xen.org>
>> 
>> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 18:50:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 18:50:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSYwO-0006RP-BK; Mon, 21 Nov 2011 18:50:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RSYwN-0006RH-62
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 18:50:03 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321901374!4405010!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32431 invoked from network); 21 Nov 2011 18:49:35 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-6.tower-216.messagelabs.com with SMTP;
	21 Nov 2011 18:49:35 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RSYvu-0005QC-G6
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 18:49:34 +0000
Received: from mail-vw0-f48.google.com ([209.85.212.48])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RSYvu-0005PQ-0w for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Mon, 21 Nov 2011 18:49:34 +0000
Received: by vbnl22 with SMTP id l22so45632vbn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Mon, 21 Nov 2011 10:49:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=JFAjgVVchZi0kfxWVUwxk3eM0tD0YVS06RCN5ngNYlU=;
	b=Hkty7Xu5TjHBjzswY/qKhae7Wcjq3AIBvhBUc63KUt8xv9GKxXZvlEeoRIrN0mJUs9
	QBaD4AEYGeiHFjDL1kPsN8mdFOtUN+P6TBIMfa2J9L/2PUDIoiAeCd8Uho837j9tzGhU
	31dbNN/qUeA4tR8QsM0V+e3G4efBb3fOlBsfM=
MIME-Version: 1.0
Received: by 10.182.220.7 with SMTP id ps7mr766299obc.51.1321901373304; Mon,
	21 Nov 2011 10:49:33 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Mon, 21 Nov 2011 10:49:33 -0800 (PST)
Date: Mon, 21 Nov 2011 10:49:33 -0800
Message-ID: <CACm5R6Q6fue34RjeLbY_sQPNZtzJWpE3OK412o-O4hdXEh_4xg@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Xen ReadMe's Was:  Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 21, 2011 at 1:18 AM, Ian Campbell - Ian.Campbell@citrix.com wrote:
> On Sun, 2011-11-20 at 01:11 +0000,
> xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
>> http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_module
>> contains a link to the University of Cambridge Computer Laboratory
>> copy of the Xen User Manual
>> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03231300000000000000
>> that responds, "Forbidden
>> You don't have permission to access
>> /research/srg/netos/xen/readmes/user/user.html on this server."
>>
>> Does Xen.org have the right to copy the Xen User Manual onto its own server?
>
> That documentation is built from the Xen source tree (try installing
> latex2html then"make docs") and appears to be covered by the GPL so I
> think so.

Does anyone know if the contents of
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/
is stored anywhere within the xen.org domain?

I don't, yet, have an installed copy of Xen nor, as noted, access to
the Computer Lab copy of the ReadMe's, so I can't generate a
significant search string to help me locate them within Xen.org
domain.

> However that particular doc is not well maintained (although the
> particular section which is referenced doesn't look so bad). IMHO it
> would be better to move the information onto the wiki itself (assuming
> it isn't already duplicated somewhere).

As to maintaining the ReadMe's, is there anyone actively attempting to
maintain them?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 18:50:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 18:50:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSYwO-0006RP-BK; Mon, 21 Nov 2011 18:50:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RSYwN-0006RH-62
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 18:50:03 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321901374!4405010!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32431 invoked from network); 21 Nov 2011 18:49:35 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-6.tower-216.messagelabs.com with SMTP;
	21 Nov 2011 18:49:35 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RSYvu-0005QC-G6
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 18:49:34 +0000
Received: from mail-vw0-f48.google.com ([209.85.212.48])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RSYvu-0005PQ-0w for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Mon, 21 Nov 2011 18:49:34 +0000
Received: by vbnl22 with SMTP id l22so45632vbn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Mon, 21 Nov 2011 10:49:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=JFAjgVVchZi0kfxWVUwxk3eM0tD0YVS06RCN5ngNYlU=;
	b=Hkty7Xu5TjHBjzswY/qKhae7Wcjq3AIBvhBUc63KUt8xv9GKxXZvlEeoRIrN0mJUs9
	QBaD4AEYGeiHFjDL1kPsN8mdFOtUN+P6TBIMfa2J9L/2PUDIoiAeCd8Uho837j9tzGhU
	31dbNN/qUeA4tR8QsM0V+e3G4efBb3fOlBsfM=
MIME-Version: 1.0
Received: by 10.182.220.7 with SMTP id ps7mr766299obc.51.1321901373304; Mon,
	21 Nov 2011 10:49:33 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Mon, 21 Nov 2011 10:49:33 -0800 (PST)
Date: Mon, 21 Nov 2011 10:49:33 -0800
Message-ID: <CACm5R6Q6fue34RjeLbY_sQPNZtzJWpE3OK412o-O4hdXEh_4xg@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Xen ReadMe's Was:  Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 21, 2011 at 1:18 AM, Ian Campbell - Ian.Campbell@citrix.com wrote:
> On Sun, 2011-11-20 at 01:11 +0000,
> xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
>> http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_module
>> contains a link to the University of Cambridge Computer Laboratory
>> copy of the Xen User Manual
>> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03231300000000000000
>> that responds, "Forbidden
>> You don't have permission to access
>> /research/srg/netos/xen/readmes/user/user.html on this server."
>>
>> Does Xen.org have the right to copy the Xen User Manual onto its own server?
>
> That documentation is built from the Xen source tree (try installing
> latex2html then"make docs") and appears to be covered by the GPL so I
> think so.

Does anyone know if the contents of
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/
is stored anywhere within the xen.org domain?

I don't, yet, have an installed copy of Xen nor, as noted, access to
the Computer Lab copy of the ReadMe's, so I can't generate a
significant search string to help me locate them within Xen.org
domain.

> However that particular doc is not well maintained (although the
> particular section which is referenced doesn't look so bad). IMHO it
> would be better to move the information onto the wiki itself (assuming
> it isn't already duplicated somewhere).

As to maintaining the ReadMe's, is there anyone actively attempting to
maintain them?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 18:54:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 18:54:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSYzn-0006cE-0h; Mon, 21 Nov 2011 18:53:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSYzl-0006c6-Mr
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 18:53:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321901576!46524085!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21655 invoked from network); 21 Nov 2011 18:52:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 18:52:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,548,1315180800"; 
   d="scan'208";a="9049746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 18:53:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 18:53:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSYzO-0006gp-A7;
	Mon, 21 Nov 2011 18:53:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSYzO-0004QL-9W;
	Mon, 21 Nov 2011 18:53:10 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9941-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 21 Nov 2011 18:53:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9941: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9941 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9941/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  9c350ab8d3ea
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24168:9c350ab8d3ea
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Nov 21 09:29:31 2011 +0100
    
    x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
    
    Xen itself (as much as Linux) relies on this behavior, so it should
    also emulate it properly. Not doing so reportedly gets in the way of
    kexec inside a HVM guest.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24167:335e8273a3f3
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 18:54:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 18:54:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSYzn-0006cE-0h; Mon, 21 Nov 2011 18:53:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSYzl-0006c6-Mr
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 18:53:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321901576!46524085!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21655 invoked from network); 21 Nov 2011 18:52:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 18:52:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,548,1315180800"; 
   d="scan'208";a="9049746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 18:53:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 18:53:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSYzO-0006gp-A7;
	Mon, 21 Nov 2011 18:53:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSYzO-0004QL-9W;
	Mon, 21 Nov 2011 18:53:10 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9941-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 21 Nov 2011 18:53:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9941: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9941 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9941/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  9c350ab8d3ea
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24168:9c350ab8d3ea
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Nov 21 09:29:31 2011 +0100
    
    x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
    
    Xen itself (as much as Linux) relies on this behavior, so it should
    also emulate it properly. Not doing so reportedly gets in the way of
    kexec inside a HVM guest.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24167:335e8273a3f3
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 19:25:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 19:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSZUb-00078m-4I; Mon, 21 Nov 2011 19:25:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evandro.abreu@gmail.com>) id 1RSZUY-00078b-MJ
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 19:25:22 +0000
X-Env-Sender: evandro.abreu@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321903493!2460821!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15372 invoked from network); 21 Nov 2011 19:24:54 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 19:24:54 -0000
Received: by ggnr4 with SMTP id r4so2223985ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 11:24:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Db3/XJ4axG8meB5rj8vKnxzezsKT7H1Azc/ynvox0rA=;
	b=hlVABnL4xX4yQkqoGE31odRZcgtFT7vfqkQc43v6gfnyPJoWrefYX6tIOg0qIDNO8d
	CYtQzCHn8hyLzsNcVsF08D0gJPY4R9ptv2AjaQwXS+NUSQbTajn5M5d1z/gdib7x6YaT
	2vI1Jj135Fk1bIrKU5QqfTbE+HJWR1Zwf3edg=
MIME-Version: 1.0
Received: by 10.68.11.233 with SMTP id t9mr33152245pbb.121.1321903493266; Mon,
	21 Nov 2011 11:24:53 -0800 (PST)
Received: by 10.68.39.105 with HTTP; Mon, 21 Nov 2011 11:24:53 -0800 (PST)
Date: Mon, 21 Nov 2011 16:24:53 -0300
Message-ID: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
From: Evandro Abreu <evandro.abreu@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] virtualization of desktop applications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4726896347571649352=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4726896347571649352==
Content-Type: multipart/alternative; boundary=bcaec5314a2724bcd704b243a419

--bcaec5314a2724bcd704b243a419
Content-Type: text/plain; charset=ISO-8859-1

I'm starting to study with virtualization of desktop applications and would
like tips on how to display a virtual machine in the browser. Could anyone
give me tips or links.

Thank you.

-- 

Evandro Abreu.
MSc Student / Recife Center for Advanced Studies - C.E.S.A.R
Recife, Brazil
Talk: evandro.abreu
Twitter: http://twitter.com/abreu_evandro
MSN: abreu_evandro@hotmail.com
Skype: evandro_abreu
Phone:(86)8814-5000 / (81)9846-8011

--bcaec5314a2724bcd704b243a419
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I&#39;m starting to study with virtualization of desktop applications and w=
ould like tips on how to display a virtual machine in the browser. Could an=
yone give me tips or links.=A0<div><br></div><div>Thank you.<br clear=3D"al=
l">
<div><br></div>-- <br><br><div><div>Evandro Abreu.<div><span style=3D"borde=
r-collapse:collapse;font-family:arial, sans-serif;font-size:13px">MSc Stude=
nt / Recife Center for Advanced Studies - C.E.S.A.R<br></span><span style=
=3D"border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">=
Recife, Brazil</span></div>
<div><font face=3D"arial, sans-serif"><span style=3D"border-collapse:collap=
se">Talk: evandro.abreu<br></span></font>Twitter: <a href=3D"http://twitter=
.com/abreu_evandro" target=3D"_blank">http://twitter.com/abreu_evandro</a><=
br></div>
</div><div>MSN: <a href=3D"mailto:abreu_evandro@hotmail.com" target=3D"_bla=
nk">abreu_evandro@hotmail.com</a></div><div>Skype: evandro_abreu</div><div>=
Phone:(86)8814-5000 / (81)9846-8011</div><div><br></div></div><br>
</div>

--bcaec5314a2724bcd704b243a419--


--===============4726896347571649352==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4726896347571649352==--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 19:25:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 19:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSZUb-00078m-4I; Mon, 21 Nov 2011 19:25:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <evandro.abreu@gmail.com>) id 1RSZUY-00078b-MJ
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 19:25:22 +0000
X-Env-Sender: evandro.abreu@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1321903493!2460821!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15372 invoked from network); 21 Nov 2011 19:24:54 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 19:24:54 -0000
Received: by ggnr4 with SMTP id r4so2223985ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 11:24:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Db3/XJ4axG8meB5rj8vKnxzezsKT7H1Azc/ynvox0rA=;
	b=hlVABnL4xX4yQkqoGE31odRZcgtFT7vfqkQc43v6gfnyPJoWrefYX6tIOg0qIDNO8d
	CYtQzCHn8hyLzsNcVsF08D0gJPY4R9ptv2AjaQwXS+NUSQbTajn5M5d1z/gdib7x6YaT
	2vI1Jj135Fk1bIrKU5QqfTbE+HJWR1Zwf3edg=
MIME-Version: 1.0
Received: by 10.68.11.233 with SMTP id t9mr33152245pbb.121.1321903493266; Mon,
	21 Nov 2011 11:24:53 -0800 (PST)
Received: by 10.68.39.105 with HTTP; Mon, 21 Nov 2011 11:24:53 -0800 (PST)
Date: Mon, 21 Nov 2011 16:24:53 -0300
Message-ID: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
From: Evandro Abreu <evandro.abreu@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] virtualization of desktop applications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4726896347571649352=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4726896347571649352==
Content-Type: multipart/alternative; boundary=bcaec5314a2724bcd704b243a419

--bcaec5314a2724bcd704b243a419
Content-Type: text/plain; charset=ISO-8859-1

I'm starting to study with virtualization of desktop applications and would
like tips on how to display a virtual machine in the browser. Could anyone
give me tips or links.

Thank you.

-- 

Evandro Abreu.
MSc Student / Recife Center for Advanced Studies - C.E.S.A.R
Recife, Brazil
Talk: evandro.abreu
Twitter: http://twitter.com/abreu_evandro
MSN: abreu_evandro@hotmail.com
Skype: evandro_abreu
Phone:(86)8814-5000 / (81)9846-8011

--bcaec5314a2724bcd704b243a419
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I&#39;m starting to study with virtualization of desktop applications and w=
ould like tips on how to display a virtual machine in the browser. Could an=
yone give me tips or links.=A0<div><br></div><div>Thank you.<br clear=3D"al=
l">
<div><br></div>-- <br><br><div><div>Evandro Abreu.<div><span style=3D"borde=
r-collapse:collapse;font-family:arial, sans-serif;font-size:13px">MSc Stude=
nt / Recife Center for Advanced Studies - C.E.S.A.R<br></span><span style=
=3D"border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">=
Recife, Brazil</span></div>
<div><font face=3D"arial, sans-serif"><span style=3D"border-collapse:collap=
se">Talk: evandro.abreu<br></span></font>Twitter: <a href=3D"http://twitter=
.com/abreu_evandro" target=3D"_blank">http://twitter.com/abreu_evandro</a><=
br></div>
</div><div>MSN: <a href=3D"mailto:abreu_evandro@hotmail.com" target=3D"_bla=
nk">abreu_evandro@hotmail.com</a></div><div>Skype: evandro_abreu</div><div>=
Phone:(86)8814-5000 / (81)9846-8011</div><div><br></div></div><br>
</div>

--bcaec5314a2724bcd704b243a419--


--===============4726896347571649352==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4726896347571649352==--


From xen-devel-bounces@lists.xensource.com Mon Nov 21 19:32:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 19:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSZau-0007V9-2V; Mon, 21 Nov 2011 19:31:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSZat-0007Uy-2m
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 19:31:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321903859!44812478!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6943 invoked from network); 21 Nov 2011 19:30:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 19:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,548,1315180800"; 
   d="scan'208";a="9050079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 19:31:23 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 19:31:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel.GarveyPatrickD@OrdinaryAmerican.net"
	<xen-devel.GarveyPatrickD@OrdinaryAmerican.net>
In-Reply-To: <CACm5R6Q6fue34RjeLbY_sQPNZtzJWpE3OK412o-O4hdXEh_4xg@mail.gmail.com>
References: <CACm5R6Q6fue34RjeLbY_sQPNZtzJWpE3OK412o-O4hdXEh_4xg@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Mon, 21 Nov 2011 19:31:22 +0000
Message-ID: <1321903882.20464.5.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen ReadMe's Was:  Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please don't break threading.

On Mon, 2011-11-21 at 18:49 +0000,
xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
> On Mon, Nov 21, 2011 at 1:18 AM, Ian Campbell - Ian.Campbell@citrix.com wrote:
> > On Sun, 2011-11-20 at 01:11 +0000,
> > xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
> >> http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_module
> >> contains a link to the University of Cambridge Computer Laboratory
> >> copy of the Xen User Manual
> >> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03231300000000000000
> >> that responds, "Forbidden
> >> You don't have permission to access
> >> /research/srg/netos/xen/readmes/user/user.html on this server."
> >>
> >> Does Xen.org have the right to copy the Xen User Manual onto its own server?
> >
> > That documentation is built from the Xen source tree (try installing
> > latex2html then"make docs") and appears to be covered by the GPL so I
> > think so.
> 
> Does anyone know if the contents of
> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/
> is stored anywhere within the xen.org domain?

Not as far as I know.

> I don't, yet, have an installed copy of Xen

You do not need to install Xen, you can simply build the docs in tree as
I described above and point a browser or pdf read at them.

>  nor, as noted, access to
> the Computer Lab copy of the ReadMe's, so I can't generate a
> significant search string to help me locate them within Xen.org
> domain.
> 
> > However that particular doc is not well maintained (although the
> > particular section which is referenced doesn't look so bad). IMHO it
> > would be better to move the information onto the wiki itself (assuming
> > it isn't already duplicated somewhere).
> 
> As to maintaining the ReadMe's, is there anyone actively attempting to
> maintain them?

They have been pretty much unmaintained for many years now. They aren't
actually README, despite the CL URL, they are most like reference
manuals.

The general feeling is that they should be replaced with a combination
of wiki pages and in-tree documentation in some more friendly mark up
language than tex, general preference seems to be markdown for regular
documents or pod for manpages.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 19:32:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 19:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSZau-0007V9-2V; Mon, 21 Nov 2011 19:31:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSZat-0007Uy-2m
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 19:31:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321903859!44812478!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6943 invoked from network); 21 Nov 2011 19:30:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 19:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,548,1315180800"; 
   d="scan'208";a="9050079"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 19:31:23 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 21 Nov 2011 19:31:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel.GarveyPatrickD@OrdinaryAmerican.net"
	<xen-devel.GarveyPatrickD@OrdinaryAmerican.net>
In-Reply-To: <CACm5R6Q6fue34RjeLbY_sQPNZtzJWpE3OK412o-O4hdXEh_4xg@mail.gmail.com>
References: <CACm5R6Q6fue34RjeLbY_sQPNZtzJWpE3OK412o-O4hdXEh_4xg@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Mon, 21 Nov 2011 19:31:22 +0000
Message-ID: <1321903882.20464.5.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen ReadMe's Was:  Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please don't break threading.

On Mon, 2011-11-21 at 18:49 +0000,
xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
> On Mon, Nov 21, 2011 at 1:18 AM, Ian Campbell - Ian.Campbell@citrix.com wrote:
> > On Sun, 2011-11-20 at 01:11 +0000,
> > xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
> >> http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_module
> >> contains a link to the University of Cambridge Computer Laboratory
> >> copy of the Xen User Manual
> >> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03231300000000000000
> >> that responds, "Forbidden
> >> You don't have permission to access
> >> /research/srg/netos/xen/readmes/user/user.html on this server."
> >>
> >> Does Xen.org have the right to copy the Xen User Manual onto its own server?
> >
> > That documentation is built from the Xen source tree (try installing
> > latex2html then"make docs") and appears to be covered by the GPL so I
> > think so.
> 
> Does anyone know if the contents of
> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/
> is stored anywhere within the xen.org domain?

Not as far as I know.

> I don't, yet, have an installed copy of Xen

You do not need to install Xen, you can simply build the docs in tree as
I described above and point a browser or pdf read at them.

>  nor, as noted, access to
> the Computer Lab copy of the ReadMe's, so I can't generate a
> significant search string to help me locate them within Xen.org
> domain.
> 
> > However that particular doc is not well maintained (although the
> > particular section which is referenced doesn't look so bad). IMHO it
> > would be better to move the information onto the wiki itself (assuming
> > it isn't already duplicated somewhere).
> 
> As to maintaining the ReadMe's, is there anyone actively attempting to
> maintain them?

They have been pretty much unmaintained for many years now. They aren't
actually README, despite the CL URL, they are most like reference
manuals.

The general feeling is that they should be replaced with a combination
of wiki pages and in-tree documentation in some more friendly mark up
language than tex, general preference seems to be markdown for regular
documents or pod for manpages.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 19:44:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 19:44:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSZmR-0007yI-Nz; Mon, 21 Nov 2011 19:43:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RSZmQ-0007yD-5g
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 19:43:50 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321904581!45480695!1
X-Originating-IP: [209.85.220.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32612 invoked from network); 21 Nov 2011 19:43:02 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 19:43:02 -0000
Received: by vcbfo1 with SMTP id fo1so1552032vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 11:43:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=zSwH1tp32/kSI6ieJhoP+kTDntXa39NxJ0hi3AjE6zI=;
	b=LBHdnFYYJsTLmwe4bVZS4MZKygwiLedwjserof5V0u06GhicNNvyBQMkwuEFimCqie
	3ISs10bsrmBNR5t8b3vuRfVufnvSCAadhpRXe/Usr4CS3/Fiu9oFYpfO3+dNLmWvwEc0
	RiwZk2hL260Qu6xq8wfqiuv8rAD/rkKAMQ1kM=
Received: by 10.52.21.148 with SMTP id v20mr14717993vde.89.1321904606158; Mon,
	21 Nov 2011 11:43:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Mon, 21 Nov 2011 11:43:05 -0800 (PST)
In-Reply-To: <CAF04D51.2551E%keir.xen@gmail.com>
References: <CAEFECAE.2549B%keir.xen@gmail.com>
	<CAF04D51.2551E%keir.xen@gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 21 Nov 2011 19:43:05 +0000
Message-ID: <CAEBdQ90hBQOzVoQXH6Lg1omkTs=JRUM=Qz4_6u09D-Pa=DAQAA@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21 November 2011 18:47, Keir Fraser <keir.xen@gmail.com> wrote:
> On 21/11/2011 11:55, "Keir Fraser" <keir.xen@gmail.com> wrote:
>
>> On 21/11/2011 11:37, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
>>
>>> xen.org writes ("[xen-unstable bisection] complete
>>> test-amd64-i386-rhel6hvm-intel"):
>>>> branch xen-unstable
>>>> xen branch xen-unstable
>>>> job test-amd64-i386-rhel6hvm-intel
>>>> test redhat-install
>>>>
>>>> Tree: linux git://github.com/jsgf/linux-xen.git
>>>> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
>>>> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
>>>>
>>>> *** Found and reproduced problem changeset ***
>>>>
>>>> =A0 Bug is in tree: =A0xen http://xenbits.xen.org/staging/xen-unstable=
.hg
>>>> =A0 Bug introduced: =A07a9a1261a6b0
>>>> =A0 Bug not present: 9a1a71f7bef2
>>>
>>> This seems to have completely broken HVM ...
>>
>> I'll revert if there's no fix forthcoming.
>
> I hear silence so I will revert the series tomorrow morning.
>

Ok. I didn't managed to replicate the issue yet.

Jean

>> =A0-- Keir
>>
>>>> =A0 changeset: =A0 24163:7a9a1261a6b0
>>>> =A0 user: =A0 =A0 =A0 =A0Jean Guyader <jean.guyader@eu.citrix.com>
>>>> =A0 date: =A0 =A0 =A0 =A0Fri Nov 18 13:41:33 2011 +0000
>>>>
>>>> =A0 =A0 =A0 add_to_physmap: Move the code for XENMEM_add_to_physmap
>>>>
>>>> =A0 =A0 =A0 Move the code for the XENMEM_add_to_physmap case into it's=
 own
>>>> =A0 =A0 =A0 function (xenmem_add_to_physmap).
>>>>
>>>> =A0 =A0 =A0 Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>>> =A0 =A0 =A0 Committed-by: Keir Fraser <keir@xen.org>
>>>
>>> Ian.
>>
>>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 19:44:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 19:44:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSZmR-0007yI-Nz; Mon, 21 Nov 2011 19:43:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RSZmQ-0007yD-5g
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 19:43:50 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321904581!45480695!1
X-Originating-IP: [209.85.220.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32612 invoked from network); 21 Nov 2011 19:43:02 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 19:43:02 -0000
Received: by vcbfo1 with SMTP id fo1so1552032vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 11:43:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=zSwH1tp32/kSI6ieJhoP+kTDntXa39NxJ0hi3AjE6zI=;
	b=LBHdnFYYJsTLmwe4bVZS4MZKygwiLedwjserof5V0u06GhicNNvyBQMkwuEFimCqie
	3ISs10bsrmBNR5t8b3vuRfVufnvSCAadhpRXe/Usr4CS3/Fiu9oFYpfO3+dNLmWvwEc0
	RiwZk2hL260Qu6xq8wfqiuv8rAD/rkKAMQ1kM=
Received: by 10.52.21.148 with SMTP id v20mr14717993vde.89.1321904606158; Mon,
	21 Nov 2011 11:43:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Mon, 21 Nov 2011 11:43:05 -0800 (PST)
In-Reply-To: <CAF04D51.2551E%keir.xen@gmail.com>
References: <CAEFECAE.2549B%keir.xen@gmail.com>
	<CAF04D51.2551E%keir.xen@gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 21 Nov 2011 19:43:05 +0000
Message-ID: <CAEBdQ90hBQOzVoQXH6Lg1omkTs=JRUM=Qz4_6u09D-Pa=DAQAA@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21 November 2011 18:47, Keir Fraser <keir.xen@gmail.com> wrote:
> On 21/11/2011 11:55, "Keir Fraser" <keir.xen@gmail.com> wrote:
>
>> On 21/11/2011 11:37, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
>>
>>> xen.org writes ("[xen-unstable bisection] complete
>>> test-amd64-i386-rhel6hvm-intel"):
>>>> branch xen-unstable
>>>> xen branch xen-unstable
>>>> job test-amd64-i386-rhel6hvm-intel
>>>> test redhat-install
>>>>
>>>> Tree: linux git://github.com/jsgf/linux-xen.git
>>>> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
>>>> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
>>>>
>>>> *** Found and reproduced problem changeset ***
>>>>
>>>> =A0 Bug is in tree: =A0xen http://xenbits.xen.org/staging/xen-unstable=
.hg
>>>> =A0 Bug introduced: =A07a9a1261a6b0
>>>> =A0 Bug not present: 9a1a71f7bef2
>>>
>>> This seems to have completely broken HVM ...
>>
>> I'll revert if there's no fix forthcoming.
>
> I hear silence so I will revert the series tomorrow morning.
>

Ok. I didn't managed to replicate the issue yet.

Jean

>> =A0-- Keir
>>
>>>> =A0 changeset: =A0 24163:7a9a1261a6b0
>>>> =A0 user: =A0 =A0 =A0 =A0Jean Guyader <jean.guyader@eu.citrix.com>
>>>> =A0 date: =A0 =A0 =A0 =A0Fri Nov 18 13:41:33 2011 +0000
>>>>
>>>> =A0 =A0 =A0 add_to_physmap: Move the code for XENMEM_add_to_physmap
>>>>
>>>> =A0 =A0 =A0 Move the code for the XENMEM_add_to_physmap case into it's=
 own
>>>> =A0 =A0 =A0 function (xenmem_add_to_physmap).
>>>>
>>>> =A0 =A0 =A0 Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>>> =A0 =A0 =A0 Committed-by: Keir Fraser <keir@xen.org>
>>>
>>> Ian.
>>
>>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 20:33:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 20:33:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSaYK-0000ku-5W; Mon, 21 Nov 2011 20:33:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RSaYI-0000ki-DD
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 20:33:18 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321907568!3571452!1
X-Originating-IP: [198.137.202.13]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18875 invoked from network); 21 Nov 2011 20:32:50 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 20:32:50 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pALKWg6q003345
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 21 Nov 2011 12:32:43 -0800
Date: Mon, 21 Nov 2011 15:32:42 -0500 (EST)
Message-Id: <20111121.153242.32677392378823093.davem@davemloft.net>
To: ian.campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1321630925-13652-1-git-send-email-ian.campbell@citrix.com>
References: <1321630925-13652-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: Mew version 6.4 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Mon, 21 Nov 2011 12:32:44 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	stable@vger.kernel.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH] xen-netback: use correct index for
 invalidation in xen_netbk_tx_check_gop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 18 Nov 2011 15:42:05 +0000

> From: Jan Beulich <JBeulich@suse.com>
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: stable@vger.kernel.org

Applied, and I left the CC: in there so that it automatically gets picked up by
-stable.

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 20:33:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 20:33:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSaYK-0000ku-5W; Mon, 21 Nov 2011 20:33:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RSaYI-0000ki-DD
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 20:33:18 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321907568!3571452!1
X-Originating-IP: [198.137.202.13]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18875 invoked from network); 21 Nov 2011 20:32:50 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Nov 2011 20:32:50 -0000
Received: from localhost (nat-pool-rdu.redhat.com [66.187.233.202])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id pALKWg6q003345
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 21 Nov 2011 12:32:43 -0800
Date: Mon, 21 Nov 2011 15:32:42 -0500 (EST)
Message-Id: <20111121.153242.32677392378823093.davem@davemloft.net>
To: ian.campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1321630925-13652-1-git-send-email-ian.campbell@citrix.com>
References: <1321630925-13652-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: Mew version 6.4 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6
	(shards.monkeyblade.net [198.137.202.13]);
	Mon, 21 Nov 2011 12:32:44 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	stable@vger.kernel.org, JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH] xen-netback: use correct index for
 invalidation in xen_netbk_tx_check_gop()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 18 Nov 2011 15:42:05 +0000

> From: Jan Beulich <JBeulich@suse.com>
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: stable@vger.kernel.org

Applied, and I left the CC: in there so that it automatically gets picked up by
-stable.

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 20:50:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 20:50:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSaoY-0001Ph-3F; Mon, 21 Nov 2011 20:50:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RSaoX-0001PU-0e
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 20:50:05 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321908576!4420749!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13931 invoked from network); 21 Nov 2011 20:49:37 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 20:49:37 -0000
Received: by yenm6 with SMTP id m6so2466017yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 12:49:36 -0800 (PST)
Received: by 10.147.116.9 with SMTP id t9mr3116556yam.5.1321908575952;
	Mon, 21 Nov 2011 12:49:35 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id a38sm15877124yhk.22.2011.11.21.12.49.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 21 Nov 2011 12:49:34 -0800 (PST)
Message-ID: <4ECAB95C.5010304@codemonkey.ws>
Date: Mon, 21 Nov 2011 14:49:32 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>	<4EC27D0D.3040204@codemonkey.ws>	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>	<alpine.DEB.2.00.1111181145500.3519@kaball-desktop>	<4EC671AF.5030805@codemonkey.ws>
	<4EC9146E.1070608@redhat.com>
In-Reply-To: <4EC9146E.1070608@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"agraf@suse.de" <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/20/2011 08:53 AM, Avi Kivity wrote:
> On 11/18/2011 04:54 PM, Anthony Liguori wrote:
>>
>> Thinking more about it, I think this entire line of thinking is wrong
>> (including mine) :-)
>>
>> The problem you're trying to solve is that the RTC fires two 1 second
>> timers regardless of whether the guest is reading the wall clock time,
>> right?  And since wall clock time is never read from the QEMU RTC in
>> Xen, it's a huge waste?
>>
>> The Right Solution would be to modify the RTC emulation such that it
>> did a qemu_get_clock() during read of the CMOS registers in order to
>> ensure the time was up to date (instead of using 1 second timers).
>>
>> Then the timers wouldn't even exist anymore.
>
> That would make host time adjustments (suspend/resume) be reflected in
> the guest.

qemu_get_clock(rtc_clock)

It depends on what clock rtc_clock is tied too.  If it's tied to vm_clock, it 
won't be affected.

> Not sure if that's good or bad, but it's different.

Doing this wouldn't change the behavior.  I presume you were confusing 
qemu_get_clock() with qemu_get_timedate().

But our current default behavior has the characteristic that you're concerned 
about.  It's was a conscious decision.  See:

commit 6875204c782e7c9aa5c28f96b2583fd31c50468f
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Tue Sep 15 13:36:04 2009 +0200

     Enable host-clock-based RTC

Regards,

Anthony Liguori

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 20:50:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 20:50:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSaoY-0001Ph-3F; Mon, 21 Nov 2011 20:50:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RSaoX-0001PU-0e
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 20:50:05 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321908576!4420749!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13931 invoked from network); 21 Nov 2011 20:49:37 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 20:49:37 -0000
Received: by yenm6 with SMTP id m6so2466017yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 12:49:36 -0800 (PST)
Received: by 10.147.116.9 with SMTP id t9mr3116556yam.5.1321908575952;
	Mon, 21 Nov 2011 12:49:35 -0800 (PST)
Received: from [192.168.0.103] (cpe-70-123-132-139.austin.res.rr.com.
	[70.123.132.139])
	by mx.google.com with ESMTPS id a38sm15877124yhk.22.2011.11.21.12.49.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 21 Nov 2011 12:49:34 -0800 (PST)
Message-ID: <4ECAB95C.5010304@codemonkey.ws>
Date: Mon, 21 Nov 2011 14:49:32 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <alpine.DEB.2.00.1111151354000.3519@kaball-desktop>	<1321368671-1134-1-git-send-email-stefano.stabellini@eu.citrix.com>	<4EC27D0D.3040204@codemonkey.ws>	<alpine.DEB.2.00.1111151457450.3519@kaball-desktop>	<alpine.DEB.2.00.1111181145500.3519@kaball-desktop>	<4EC671AF.5030805@codemonkey.ws>
	<4EC9146E.1070608@redhat.com>
In-Reply-To: <4EC9146E.1070608@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"agraf@suse.de" <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/4] xen: introduce
	mc146818rtcxen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/20/2011 08:53 AM, Avi Kivity wrote:
> On 11/18/2011 04:54 PM, Anthony Liguori wrote:
>>
>> Thinking more about it, I think this entire line of thinking is wrong
>> (including mine) :-)
>>
>> The problem you're trying to solve is that the RTC fires two 1 second
>> timers regardless of whether the guest is reading the wall clock time,
>> right?  And since wall clock time is never read from the QEMU RTC in
>> Xen, it's a huge waste?
>>
>> The Right Solution would be to modify the RTC emulation such that it
>> did a qemu_get_clock() during read of the CMOS registers in order to
>> ensure the time was up to date (instead of using 1 second timers).
>>
>> Then the timers wouldn't even exist anymore.
>
> That would make host time adjustments (suspend/resume) be reflected in
> the guest.

qemu_get_clock(rtc_clock)

It depends on what clock rtc_clock is tied too.  If it's tied to vm_clock, it 
won't be affected.

> Not sure if that's good or bad, but it's different.

Doing this wouldn't change the behavior.  I presume you were confusing 
qemu_get_clock() with qemu_get_timedate().

But our current default behavior has the characteristic that you're concerned 
about.  It's was a conscious decision.  See:

commit 6875204c782e7c9aa5c28f96b2583fd31c50468f
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Tue Sep 15 13:36:04 2009 +0200

     Enable host-clock-based RTC

Regards,

Anthony Liguori

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 21:34:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 21:34:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSbUT-0002AQ-Oq; Mon, 21 Nov 2011 21:33:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSbUS-0002AF-94
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 21:33:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1321911176!4027214!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32268 invoked from network); 21 Nov 2011 21:32:56 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 21:32:56 -0000
Received: by wwp14 with SMTP id 14so8956200wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 13:32:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=AV8xyEX+koVn5yU9cAJZsy9XX2IQdkEnJYLxw7dmGuI=;
	b=AgYO2IFU7s9fnSZg6c63ExPeoxTts779ng82/w7XAqUHhqPzupHrmXVYIjd9BaYFiD
	W9kNzkTH5FQZpGjNm98fJw9mBTKMlhD6qIQesigR0W/jZLUVFUoeS2f+78Le/6ZtPPgD
	yqE9n/8nPfsLl9PMTygsDItNyS77clOePs4Tg=
Received: by 10.227.208.149 with SMTP id gc21mr10089910wbb.10.1321911176222;
	Mon, 21 Nov 2011 13:32:56 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id z5sm5710415wix.5.2011.11.21.13.32.53
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 13:32:54 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 21:32:51 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jean Guyader <jean.guyader@gmail.com>
Message-ID: <CAF07403.2553D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
Thread-Index: AcyolR734MpwGSKWB0Sun9NeWdVjsg==
In-Reply-To: <CAEBdQ90hBQOzVoQXH6Lg1omkTs=JRUM=Qz4_6u09D-Pa=DAQAA@mail.gmail.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 19:43, "Jean Guyader" <jean.guyader@gmail.com> wrote:

> On 21 November 2011 18:47, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 21/11/2011 11:55, "Keir Fraser" <keir.xen@gmail.com> wrote:
>> =

>>> On 21/11/2011 11:37, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
>>> =

>>>> xen.org writes ("[xen-unstable bisection] complete
>>>> test-amd64-i386-rhel6hvm-intel"):
>>>>> branch xen-unstable
>>>>> xen branch xen-unstable
>>>>> job test-amd64-i386-rhel6hvm-intel
>>>>> test redhat-install
>>>>> =

>>>>> Tree: linux git://github.com/jsgf/linux-xen.git
>>>>> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
>>>>> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
>>>>> =

>>>>> *** Found and reproduced problem changeset ***
>>>>> =

>>>>> =A0 Bug is in tree: =A0xen http://xenbits.xen.org/staging/xen-unstabl=
e.hg
>>>>> =A0 Bug introduced: =A07a9a1261a6b0
>>>>> =A0 Bug not present: 9a1a71f7bef2
>>>> =

>>>> This seems to have completely broken HVM ...
>>> =

>>> I'll revert if there's no fix forthcoming.
>> =

>> I hear silence so I will revert the series tomorrow morning.
>> =

> =

> Ok. I didn't managed to replicate the issue yet.

Actually, it wasn't too hard to work out. This bisection is misleading
though, as it's zeroed in on the RCU locking bug, which is already fixed.
The bug is actually in a later changeset which modifies hvmloader.

Looking at the hvmloader/pci.c changes, the unconditional assignment to
low_mem_pgend after the loop is obviously wrong. As is removing the handling
for high_mem_pgend=3D=3D0. I checked in a reworked version that is closer t=
o the
original code. =


Hopefully our tests will work again now.

 -- Keir

> Jean
> =

>>> =A0-- Keir
>>> =

>>>>> =A0 changeset: =A0 24163:7a9a1261a6b0
>>>>> =A0 user: =A0 =A0 =A0 =A0Jean Guyader <jean.guyader@eu.citrix.com>
>>>>> =A0 date: =A0 =A0 =A0 =A0Fri Nov 18 13:41:33 2011 +0000
>>>>> =

>>>>> =A0 =A0 =A0 add_to_physmap: Move the code for XENMEM_add_to_physmap
>>>>> =

>>>>> =A0 =A0 =A0 Move the code for the XENMEM_add_to_physmap case into it'=
s own
>>>>> =A0 =A0 =A0 function (xenmem_add_to_physmap).
>>>>> =

>>>>> =A0 =A0 =A0 Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>>>> =A0 =A0 =A0 Committed-by: Keir Fraser <keir@xen.org>
>>>> =

>>>> Ian.
>>> =

>>> =

>> =

>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 21:34:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 21:34:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSbUT-0002AQ-Oq; Mon, 21 Nov 2011 21:33:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSbUS-0002AF-94
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 21:33:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1321911176!4027214!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32268 invoked from network); 21 Nov 2011 21:32:56 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 21:32:56 -0000
Received: by wwp14 with SMTP id 14so8956200wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 13:32:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=AV8xyEX+koVn5yU9cAJZsy9XX2IQdkEnJYLxw7dmGuI=;
	b=AgYO2IFU7s9fnSZg6c63ExPeoxTts779ng82/w7XAqUHhqPzupHrmXVYIjd9BaYFiD
	W9kNzkTH5FQZpGjNm98fJw9mBTKMlhD6qIQesigR0W/jZLUVFUoeS2f+78Le/6ZtPPgD
	yqE9n/8nPfsLl9PMTygsDItNyS77clOePs4Tg=
Received: by 10.227.208.149 with SMTP id gc21mr10089910wbb.10.1321911176222;
	Mon, 21 Nov 2011 13:32:56 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-245-239.range86-129.btcentralplus.com. [86.129.245.239])
	by mx.google.com with ESMTPS id z5sm5710415wix.5.2011.11.21.13.32.53
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 13:32:54 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 21:32:51 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jean Guyader <jean.guyader@gmail.com>
Message-ID: <CAF07403.2553D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete
	test-amd64-i386-rhel6hvm-intel
Thread-Index: AcyolR734MpwGSKWB0Sun9NeWdVjsg==
In-Reply-To: <CAEBdQ90hBQOzVoQXH6Lg1omkTs=JRUM=Qz4_6u09D-Pa=DAQAA@mail.gmail.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11/2011 19:43, "Jean Guyader" <jean.guyader@gmail.com> wrote:

> On 21 November 2011 18:47, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 21/11/2011 11:55, "Keir Fraser" <keir.xen@gmail.com> wrote:
>> =

>>> On 21/11/2011 11:37, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
>>> =

>>>> xen.org writes ("[xen-unstable bisection] complete
>>>> test-amd64-i386-rhel6hvm-intel"):
>>>>> branch xen-unstable
>>>>> xen branch xen-unstable
>>>>> job test-amd64-i386-rhel6hvm-intel
>>>>> test redhat-install
>>>>> =

>>>>> Tree: linux git://github.com/jsgf/linux-xen.git
>>>>> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
>>>>> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
>>>>> =

>>>>> *** Found and reproduced problem changeset ***
>>>>> =

>>>>> =A0 Bug is in tree: =A0xen http://xenbits.xen.org/staging/xen-unstabl=
e.hg
>>>>> =A0 Bug introduced: =A07a9a1261a6b0
>>>>> =A0 Bug not present: 9a1a71f7bef2
>>>> =

>>>> This seems to have completely broken HVM ...
>>> =

>>> I'll revert if there's no fix forthcoming.
>> =

>> I hear silence so I will revert the series tomorrow morning.
>> =

> =

> Ok. I didn't managed to replicate the issue yet.

Actually, it wasn't too hard to work out. This bisection is misleading
though, as it's zeroed in on the RCU locking bug, which is already fixed.
The bug is actually in a later changeset which modifies hvmloader.

Looking at the hvmloader/pci.c changes, the unconditional assignment to
low_mem_pgend after the loop is obviously wrong. As is removing the handling
for high_mem_pgend=3D=3D0. I checked in a reworked version that is closer t=
o the
original code. =


Hopefully our tests will work again now.

 -- Keir

> Jean
> =

>>> =A0-- Keir
>>> =

>>>>> =A0 changeset: =A0 24163:7a9a1261a6b0
>>>>> =A0 user: =A0 =A0 =A0 =A0Jean Guyader <jean.guyader@eu.citrix.com>
>>>>> =A0 date: =A0 =A0 =A0 =A0Fri Nov 18 13:41:33 2011 +0000
>>>>> =

>>>>> =A0 =A0 =A0 add_to_physmap: Move the code for XENMEM_add_to_physmap
>>>>> =

>>>>> =A0 =A0 =A0 Move the code for the XENMEM_add_to_physmap case into it'=
s own
>>>>> =A0 =A0 =A0 function (xenmem_add_to_physmap).
>>>>> =

>>>>> =A0 =A0 =A0 Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>>>> =A0 =A0 =A0 Committed-by: Keir Fraser <keir@xen.org>
>>>> =

>>>> Ian.
>>> =

>>> =

>> =

>> =

>> =

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 21:52:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 21:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSbmd-0002PB-IR; Mon, 21 Nov 2011 21:52:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RSbmc-0002P6-3S
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 21:52:10 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321912203!53104088!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 496 invoked from network); 21 Nov 2011 21:50:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 21:50:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,549,1315180800"; 
   d="scan'208";a="9051227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 21:51:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 21:51:46 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RSbmE-0007eG-QZ;
	Mon, 21 Nov 2011 21:51:46 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RSbm1-0000fc-Vr;
	Mon, 21 Nov 2011 21:51:34 +0000
Date: Mon, 21 Nov 2011 21:51:33 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111121215133.GA2540@spongy.cam.xci-test.com>
References: <CAEBdQ90hBQOzVoQXH6Lg1omkTs=JRUM=Qz4_6u09D-Pa=DAQAA@mail.gmail.com>
	<CAF07403.2553D%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF07403.2553D%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11 09:32, Keir Fraser wrote:
> On 21/11/2011 19:43, "Jean Guyader" <jean.guyader@gmail.com> wrote:
> 
> > On 21 November 2011 18:47, Keir Fraser <keir.xen@gmail.com> wrote:
> >> On 21/11/2011 11:55, "Keir Fraser" <keir.xen@gmail.com> wrote:
> >> 
> >>> On 21/11/2011 11:37, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> >>> 
> >>>> xen.org writes ("[xen-unstable bisection] complete
> >>>> test-amd64-i386-rhel6hvm-intel"):
> >>>>> branch xen-unstable
> >>>>> xen branch xen-unstable
> >>>>> job test-amd64-i386-rhel6hvm-intel
> >>>>> test redhat-install
> >>>>> 
> >>>>> Tree: linux git://github.com/jsgf/linux-xen.git
> >>>>> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
> >>>>> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> >>>>> 
> >>>>> *** Found and reproduced problem changeset ***
> >>>>> 
> >>>>> ? Bug is in tree: ?xen http://xenbits.xen.org/staging/xen-unstable.hg
> >>>>> ? Bug introduced: ?7a9a1261a6b0
> >>>>> ? Bug not present: 9a1a71f7bef2
> >>>> 
> >>>> This seems to have completely broken HVM ...
> >>> 
> >>> I'll revert if there's no fix forthcoming.
> >> 
> >> I hear silence so I will revert the series tomorrow morning.
> >> 
> > 
> > Ok. I didn't managed to replicate the issue yet.
> 
> Actually, it wasn't too hard to work out. This bisection is misleading
> though, as it's zeroed in on the RCU locking bug, which is already fixed.
> The bug is actually in a later changeset which modifies hvmloader.
> 
> Looking at the hvmloader/pci.c changes, the unconditional assignment to
> low_mem_pgend after the loop is obviously wrong. As is removing the handling
> for high_mem_pgend==0. I checked in a reworked version that is closer to the
> original code. 
> 
> Hopefully our tests will work again now.
> 

Thanks for looking into it. I would like this serie to get applied in 4.1
but I think that the code have changed a bit. I'll send a version for 4.1
similar to the one we have in xen-unstable.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 21:52:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 21:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSbmd-0002PB-IR; Mon, 21 Nov 2011 21:52:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RSbmc-0002P6-3S
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 21:52:10 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321912203!53104088!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 496 invoked from network); 21 Nov 2011 21:50:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 21:50:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,549,1315180800"; 
   d="scan'208";a="9051227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Nov 2011 21:51:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 21 Nov 2011 21:51:46 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RSbmE-0007eG-QZ;
	Mon, 21 Nov 2011 21:51:46 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RSbm1-0000fc-Vr;
	Mon, 21 Nov 2011 21:51:34 +0000
Date: Mon, 21 Nov 2011 21:51:33 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111121215133.GA2540@spongy.cam.xci-test.com>
References: <CAEBdQ90hBQOzVoQXH6Lg1omkTs=JRUM=Qz4_6u09D-Pa=DAQAA@mail.gmail.com>
	<CAF07403.2553D%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF07403.2553D%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete
 test-amd64-i386-rhel6hvm-intel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 21/11 09:32, Keir Fraser wrote:
> On 21/11/2011 19:43, "Jean Guyader" <jean.guyader@gmail.com> wrote:
> 
> > On 21 November 2011 18:47, Keir Fraser <keir.xen@gmail.com> wrote:
> >> On 21/11/2011 11:55, "Keir Fraser" <keir.xen@gmail.com> wrote:
> >> 
> >>> On 21/11/2011 11:37, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> >>> 
> >>>> xen.org writes ("[xen-unstable bisection] complete
> >>>> test-amd64-i386-rhel6hvm-intel"):
> >>>>> branch xen-unstable
> >>>>> xen branch xen-unstable
> >>>>> job test-amd64-i386-rhel6hvm-intel
> >>>>> test redhat-install
> >>>>> 
> >>>>> Tree: linux git://github.com/jsgf/linux-xen.git
> >>>>> Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
> >>>>> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> >>>>> 
> >>>>> *** Found and reproduced problem changeset ***
> >>>>> 
> >>>>> ? Bug is in tree: ?xen http://xenbits.xen.org/staging/xen-unstable.hg
> >>>>> ? Bug introduced: ?7a9a1261a6b0
> >>>>> ? Bug not present: 9a1a71f7bef2
> >>>> 
> >>>> This seems to have completely broken HVM ...
> >>> 
> >>> I'll revert if there's no fix forthcoming.
> >> 
> >> I hear silence so I will revert the series tomorrow morning.
> >> 
> > 
> > Ok. I didn't managed to replicate the issue yet.
> 
> Actually, it wasn't too hard to work out. This bisection is misleading
> though, as it's zeroed in on the RCU locking bug, which is already fixed.
> The bug is actually in a later changeset which modifies hvmloader.
> 
> Looking at the hvmloader/pci.c changes, the unconditional assignment to
> low_mem_pgend after the loop is obviously wrong. As is removing the handling
> for high_mem_pgend==0. I checked in a reworked version that is closer to the
> original code. 
> 
> Hopefully our tests will work again now.
> 

Thanks for looking into it. I would like this serie to get applied in 4.1
but I think that the code have changed a bit. I'll send a version for 4.1
similar to the one we have in xen-unstable.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 22:17:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 22:17:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RScAn-00031G-PM; Mon, 21 Nov 2011 22:17:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RScAm-000317-4t
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 22:17:08 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321913799!5048240!1
X-Originating-IP: [209.85.216.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1817 invoked from network); 21 Nov 2011 22:16:40 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 22:16:40 -0000
Received: by qam2 with SMTP id 2so768741qam.9
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 14:16:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=cgfXkrOA8fIZNY8yi2iHjL7Ie+XgaRkBqXyKnM1A6LA=;
	b=BS9moo6uS4Fzwe9qddSd7bBYd3DX48+dhkR2q8TjH5G+Y6DS9vurLieQYXtfRYyQxu
	gt3n+zidYthIBSbHRQdw==
Received: by 10.224.180.207 with SMTP id bv15mr6983939qab.36.1321913799166;
	Mon, 21 Nov 2011 14:16:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.180.207 with SMTP id bv15mr6983907qab.36.1321913799013;
	Mon, 21 Nov 2011 14:16:39 -0800 (PST)
Received: by 10.229.208.20 with HTTP; Mon, 21 Nov 2011 14:16:38 -0800 (PST)
In-Reply-To: <87lira9ii7.fsf@rustcorp.com.au>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<87lira9ii7.fsf@rustcorp.com.au>
Date: Mon, 21 Nov 2011 14:16:38 -0800
Message-ID: <CAB8Rdaqno9kVHB8wsbH5=zs_ppUkd1G=siywFFfH3Ud21qK3FA@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Rusty Russell <rusty@rustcorp.com.au>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Amit Shah <amit.shah@redhat.com>,
	Mike Waychison <mikew@google.com>, ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks, Rusty.  I'm not using QEMU though, just KVM.   I create the device,=
 wait
for the message from the guest that the device is ready, and then add ports.

Miche

On Sun, Nov 20, 2011 at 9:01 PM, Rusty Russell <rusty@rustcorp.com.au> wrot=
e:
> On Thu, 17 Nov 2011 10:57:37 -0800, Miche Baker-Harvey <miche@google.com>=
 wrote:
>> Rusty, Michael, Stephen, et al,
>>
>> Thanks for your comments on these patches.
>>
>> For what I'm trying to do, all three patches are necessary, but maybe
>> I'm going about it the wrong way. Your input would be appreciated.
>> I'm in no way claiming that these patches are "right", just that it's
>> working for me, and that what's in the current pool is not.
>
> We have to *understand* the code. =A0If we don't, we need to rewrite the
> code so we *do* understand it, or make way for someone who does.
>
> I'm looking at the kvm man page to try to figure out how to have virtio
> console, and it's deeply unclear. =A0What kvm commandline are you using?
> I'll try to debug it here, and see what I learn about hvc_console.
>
> Cheers,
> Rusty.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 22:17:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 22:17:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RScAn-00031G-PM; Mon, 21 Nov 2011 22:17:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RScAm-000317-4t
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 22:17:08 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321913799!5048240!1
X-Originating-IP: [209.85.216.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1817 invoked from network); 21 Nov 2011 22:16:40 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Nov 2011 22:16:40 -0000
Received: by qam2 with SMTP id 2so768741qam.9
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 14:16:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=cgfXkrOA8fIZNY8yi2iHjL7Ie+XgaRkBqXyKnM1A6LA=;
	b=BS9moo6uS4Fzwe9qddSd7bBYd3DX48+dhkR2q8TjH5G+Y6DS9vurLieQYXtfRYyQxu
	gt3n+zidYthIBSbHRQdw==
Received: by 10.224.180.207 with SMTP id bv15mr6983939qab.36.1321913799166;
	Mon, 21 Nov 2011 14:16:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.180.207 with SMTP id bv15mr6983907qab.36.1321913799013;
	Mon, 21 Nov 2011 14:16:39 -0800 (PST)
Received: by 10.229.208.20 with HTTP; Mon, 21 Nov 2011 14:16:38 -0800 (PST)
In-Reply-To: <87lira9ii7.fsf@rustcorp.com.au>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<87lira9ii7.fsf@rustcorp.com.au>
Date: Mon, 21 Nov 2011 14:16:38 -0800
Message-ID: <CAB8Rdaqno9kVHB8wsbH5=zs_ppUkd1G=siywFFfH3Ud21qK3FA@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Rusty Russell <rusty@rustcorp.com.au>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Amit Shah <amit.shah@redhat.com>,
	Mike Waychison <mikew@google.com>, ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks, Rusty.  I'm not using QEMU though, just KVM.   I create the device,=
 wait
for the message from the guest that the device is ready, and then add ports.

Miche

On Sun, Nov 20, 2011 at 9:01 PM, Rusty Russell <rusty@rustcorp.com.au> wrot=
e:
> On Thu, 17 Nov 2011 10:57:37 -0800, Miche Baker-Harvey <miche@google.com>=
 wrote:
>> Rusty, Michael, Stephen, et al,
>>
>> Thanks for your comments on these patches.
>>
>> For what I'm trying to do, all three patches are necessary, but maybe
>> I'm going about it the wrong way. Your input would be appreciated.
>> I'm in no way claiming that these patches are "right", just that it's
>> working for me, and that what's in the current pool is not.
>
> We have to *understand* the code. =A0If we don't, we need to rewrite the
> code so we *do* understand it, or make way for someone who does.
>
> I'm looking at the kvm man page to try to figure out how to have virtio
> console, and it's deeply unclear. =A0What kvm commandline are you using?
> I'll try to debug it here, and see what I learn about hvc_console.
>
> Cheers,
> Rusty.
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 22:23:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 22:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RScGk-0003EC-7D; Mon, 21 Nov 2011 22:23:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RScGh-0003E7-Vi
	for Xen-devel@lists.xensource.com; Mon, 21 Nov 2011 22:23:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321914158!46537863!1
X-Originating-IP: [63.239.65.39]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26069 invoked from network); 21 Nov 2011 22:22:38 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-27.messagelabs.com with SMTP;
	21 Nov 2011 22:22:38 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pALMMpdg016626
	for <Xen-devel@lists.xensource.com>; Mon, 21 Nov 2011 22:22:52 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pALMMp4b031998; 
	Mon, 21 Nov 2011 17:22:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Xen-devel@lists.xensource.com
Date: Mon, 21 Nov 2011 17:21:59 -0500
Message-Id: <1321914119-28767-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xsm/flask: fix resource list range checks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The FLASK security checks for resource ranges were not implemented
correctly - only the permissions on the endpoints of a range were
checked, instead of all items contained in the range. This would allow
certain resources (I/O ports, I/O memory) to be used by domains in
contravention to security policy.

This also corrects a bug where adding overlapping resource ranges did
not trigger an error.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c            |  119 +++++++++++++++---------------
 xen/xsm/flask/include/security.h |    8 ++
 xen/xsm/flask/ss/services.c      |  151 ++++++++++++++++++++++++++++++++------
 3 files changed, 196 insertions(+), 82 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index e70feda..de7f249 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -664,42 +664,47 @@ static int irq_has_perm(struct domain *d, uint8_t pirq, uint8_t access)
         return rc;
 }
 
-static int iomem_has_perm(struct domain *d, unsigned long mfn, uint8_t access)
-{
+struct iomem_has_perm_data {
+    struct domain_security_struct *ssec, *tsec;
     u32 perm;
-    u32 rsid;
-    int rc = -EPERM;
+};
 
-    struct domain_security_struct *ssec, *tsec;
+static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long end)
+{
+    struct iomem_has_perm_data *data = v;
     struct avc_audit_data ad;
+    int rc = -EPERM;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
-    if ( rc )
-        return rc;
-
-    if ( access )
-        perm = RESOURCE__ADD_IOMEM;
-    else
-        perm = RESOURCE__REMOVE_IOMEM;
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = start;
 
-    ssec = current->domain->ssid;
-    tsec = d->ssid;
+    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
-    rc = security_iomem_sid(mfn, &rsid);
     if ( rc )
         return rc;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = mfn;
+    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+}
 
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+static int iomem_has_perm(struct domain *d, unsigned long start, unsigned long end, uint8_t access)
+{
+    struct iomem_has_perm_data data;
+    int rc;
 
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+                         resource_to_perm(access));
     if ( rc )
         return rc;
 
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
-                        RESOURCE__USE, &ad);
+    if ( access )
+        data.perm = RESOURCE__ADD_IOMEM;
+    else
+        data.perm = RESOURCE__REMOVE_IOMEM;
+
+    data.ssec = current->domain->ssid;
+    data.tsec = d->ssid;
+
+    return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
 static int flask_perfcontrol(void)
@@ -736,45 +741,49 @@ static int flask_shadow_control(struct domain *d, uint32_t op)
     return domain_has_perm(current->domain, d, SECCLASS_SHADOW, perm);
 }
 
-static int ioport_has_perm(struct domain *d, uint32_t ioport, uint8_t access)
-{
+struct ioport_has_perm_data {
+    struct domain_security_struct *ssec, *tsec;
     u32 perm;
-    u32 rsid;
-    int rc = -EPERM;
+};
 
+static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long end)
+{
+    struct ioport_has_perm_data *data = v;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec, *tsec;
+    int rc;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = start;
+
+    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    if ( access )
-        perm = RESOURCE__ADD_IOPORT;
-    else
-        perm = RESOURCE__REMOVE_IOPORT;
+    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+}
 
-    ssec = current->domain->ssid;
-    tsec = d->ssid;
 
-    rc = security_ioport_sid(ioport, &rsid);
-    if ( rc )
-        return rc;
+static int ioport_has_perm(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+{
+    int rc;
+    struct ioport_has_perm_data data;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = ioport;
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+                         resource_to_perm(access));
 
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
     if ( rc )
         return rc;
 
     if ( access )
-        return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
-                            RESOURCE__USE, &ad);
+        data.perm = RESOURCE__ADD_IOPORT;
     else
-        return rc;
+        data.perm = RESOURCE__REMOVE_IOPORT;
+
+    data.ssec = current->domain->ssid;
+    data.tsec = d->ssid;
+
+    return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
 
 static int flask_getpageframeinfo(struct page_info *page)
@@ -1184,31 +1193,25 @@ static int io_has_perm(struct domain *d, char *name, unsigned long s,
 
     if ( strcmp(name, "I/O Memory") == 0 )
     {
-        rc = iomem_has_perm(d, s, access);
+        rc = iomem_has_perm(d, s, e, access);
         if ( rc )
             return rc;
-
-        if ( s != e )
-            rc = iomem_has_perm(d, e, access);
     }
     else if ( strcmp(name, "Interrupts") == 0 )
     {
-        rc = irq_has_perm(d, s, access);
-        if ( rc )
-            return rc;
-
-        if ( s != e )
-            rc = irq_has_perm(d, e, access);
+        while (s <= e) {
+            rc = irq_has_perm(d, s, access);
+            if ( rc )
+                return rc;
+            s++;
+        }
     }
 #ifdef CONFIG_X86
     else if ( strcmp(name, "I/O Ports") == 0 )
     {
-        rc = ioport_has_perm(d, s, access);
+        rc = ioport_has_perm(d, s, e, access);
         if ( rc )
             return rc;
-
-        if ( s != e )
-            rc = ioport_has_perm(d, e, access);
     }
 #endif
 
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 8a64b0a..0dc21c8 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -82,6 +82,14 @@ int security_device_sid(u32 device, u32 *out_sid);
 int security_validate_transition(u32 oldsid, u32 newsid, u32 tasksid,
                                                                     u16 tclass);
 
+typedef int (*security_iterate_fn)(void *data, u32 sid, unsigned long start,
+                                                        unsigned long end);
+int security_iterate_iomem_sids(unsigned long start, unsigned long end,
+                                security_iterate_fn fn, void *data);
+
+int security_iterate_ioport_sids(u32 start, u32 end,
+                                security_iterate_fn fn, void *data);
+
 int security_ocontext_add(char *ocontext, unsigned long low,
                            unsigned long high, u32 sid);
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 6e72800..b880762 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1594,6 +1594,53 @@ out:
     return rc;
 }
 
+int security_iterate_iomem_sids(unsigned long start, unsigned long end,
+                                security_iterate_fn fn, void *data)
+{
+    struct ocontext *c;
+    int rc = 0;
+
+    POLICY_RDLOCK;
+
+    c = policydb.ocontexts[OCON_IOMEM];
+    while (c && c->u.iomem.high_iomem < start)
+        c = c->next;
+
+    while (c && c->u.iomem.low_iomem <= end) {
+        if (!c->sid[0])
+        {
+            rc = sidtab_context_to_sid(&sidtab, &c->context[0], &c->sid[0]);
+            if ( rc )
+                goto out;
+        }
+        if (start < c->u.iomem.low_iomem) {
+            /* found a gap */
+            rc = fn(data, SECINITSID_IOMEM, start, c->u.iomem.low_iomem - 1);
+            if (rc)
+                goto out;
+            start = c->u.iomem.low_iomem;
+        }
+        if (end <= c->u.iomem.high_iomem) {
+            /* iteration ends in the middle of this range */
+            rc = fn(data, c->sid[0], start, end);
+            goto out;
+        }
+
+        rc = fn(data, c->sid[0], start, c->u.iomem.high_iomem);
+        if (rc)
+            goto out;
+        start = c->u.iomem.high_iomem + 1;
+
+        c = c->next;
+    }
+
+    rc = fn(data, SECINITSID_IOMEM, start, end);
+
+out:
+    POLICY_RDUNLOCK;
+    return rc;
+}
+
 /**
  * security_ioport_sid - Obtain the SID for an ioport.
  * @ioport: ioport
@@ -1635,6 +1682,53 @@ out:
     return rc;
 }
 
+int security_iterate_ioport_sids(u32 start, u32 end,
+                                security_iterate_fn fn, void *data)
+{
+    struct ocontext *c;
+    int rc = 0;
+
+    POLICY_RDLOCK;
+
+    c = policydb.ocontexts[OCON_IOPORT];
+    while (c && c->u.ioport.high_ioport < start)
+        c = c->next;
+
+    while (c && c->u.ioport.low_ioport <= end) {
+        if (!c->sid[0])
+        {
+            rc = sidtab_context_to_sid(&sidtab, &c->context[0], &c->sid[0]);
+            if ( rc )
+                goto out;
+        }
+        if (start < c->u.ioport.low_ioport) {
+            /* found a gap */
+            rc = fn(data, SECINITSID_IOPORT, start, c->u.ioport.low_ioport - 1);
+            if (rc)
+                goto out;
+            start = c->u.ioport.low_ioport;
+        }
+        if (end <= c->u.ioport.high_ioport) {
+            /* iteration ends in the middle of this range */
+            rc = fn(data, c->sid[0], start, end);
+            goto out;
+        }
+
+        rc = fn(data, c->sid[0], start, c->u.ioport.high_ioport);
+        if (rc)
+            goto out;
+        start = c->u.ioport.high_ioport + 1;
+
+        c = c->next;
+    }
+
+    rc = fn(data, SECINITSID_IOPORT, start, end);
+
+out:
+    POLICY_RDUNLOCK;
+    return rc;
+}
+
 /**
  * security_device_sid - Obtain the SID for a PCI device.
  * @ioport: device
@@ -1963,6 +2057,7 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
     int ret = 0;
     int ocon = 0;
     struct ocontext *c;
+    struct ocontext *prev;
     struct ocontext *add;
 
     if ( (ocon = determine_ocontext(ocontext)) < 0 )
@@ -2006,23 +2101,27 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
         add->u.ioport.low_ioport = low;
         add->u.ioport.high_ioport = high;
 
+        prev = NULL;
         c = policydb.ocontexts[OCON_IOPORT];
-        while ( c )
-        {
-            if ( c->u.ioport.low_ioport <= add->u.ioport.high_ioport &&
-                 add->u.ioport.low_ioport <= c->u.ioport.high_ioport )
-            {
-                printk("%s: IO Port overlap with entry 0x%x - 0x%x\n",
-                       __FUNCTION__, c->u.ioport.low_ioport,
-                       c->u.ioport.high_ioport);
-                ret = -EINVAL;
-                break;
-            }
+
+        while ( c && c->u.ioport.high_ioport < low ) {
+            prev = c;
             c = c->next;
         }
 
-        if ( ret == 0 )
+        if (c && c->u.ioport.low_ioport <= high)
         {
+            printk("%s: IO Port overlap with entry 0x%x - 0x%x\n",
+                   __FUNCTION__, c->u.ioport.low_ioport,
+                   c->u.ioport.high_ioport);
+            ret = -EINVAL;
+            break;
+        }
+
+        if (prev) {
+            add->next = prev->next;
+            prev->next = add;
+        } else {
             add->next = policydb.ocontexts[OCON_IOPORT];
             policydb.ocontexts[OCON_IOPORT] = add;
         }
@@ -2032,23 +2131,27 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
         add->u.iomem.low_iomem = low;
         add->u.iomem.high_iomem = high;
 
+        prev = NULL;
         c = policydb.ocontexts[OCON_IOMEM];
-        while ( c )
-        {
-            if ( c->u.iomem.low_iomem <= add->u.iomem.high_iomem &&
-                 add->u.iomem.low_iomem <= c->u.iomem.high_iomem )
-            {
-                printk("%s: IO Memory overlap with entry 0x%x - 0x%x\n",
-                       __FUNCTION__, c->u.iomem.low_iomem,
-                       c->u.iomem.high_iomem);
-                ret = -EINVAL;
-                break;
-            }
+
+        while ( c && c->u.iomem.high_iomem < low ) {
+            prev = c;
             c = c->next;
         }
 
-        if ( ret == 0 )
+        if (c && c->u.iomem.low_iomem <= high)
         {
+            printk("%s: IO Memory overlap with entry 0x%x - 0x%x\n",
+                   __FUNCTION__, c->u.iomem.low_iomem,
+                   c->u.iomem.high_iomem);
+            ret = -EINVAL;
+            break;
+        }
+
+        if (prev) {
+            add->next = prev->next;
+            prev->next = add;
+        } else {
             add->next = policydb.ocontexts[OCON_IOMEM];
             policydb.ocontexts[OCON_IOMEM] = add;
         }
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 22:23:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 22:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RScGk-0003EC-7D; Mon, 21 Nov 2011 22:23:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RScGh-0003E7-Vi
	for Xen-devel@lists.xensource.com; Mon, 21 Nov 2011 22:23:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321914158!46537863!1
X-Originating-IP: [63.239.65.39]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26069 invoked from network); 21 Nov 2011 22:22:38 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-27.messagelabs.com with SMTP;
	21 Nov 2011 22:22:38 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pALMMpdg016626
	for <Xen-devel@lists.xensource.com>; Mon, 21 Nov 2011 22:22:52 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pALMMp4b031998; 
	Mon, 21 Nov 2011 17:22:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Xen-devel@lists.xensource.com
Date: Mon, 21 Nov 2011 17:21:59 -0500
Message-Id: <1321914119-28767-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xsm/flask: fix resource list range checks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The FLASK security checks for resource ranges were not implemented
correctly - only the permissions on the endpoints of a range were
checked, instead of all items contained in the range. This would allow
certain resources (I/O ports, I/O memory) to be used by domains in
contravention to security policy.

This also corrects a bug where adding overlapping resource ranges did
not trigger an error.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c            |  119 +++++++++++++++---------------
 xen/xsm/flask/include/security.h |    8 ++
 xen/xsm/flask/ss/services.c      |  151 ++++++++++++++++++++++++++++++++------
 3 files changed, 196 insertions(+), 82 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index e70feda..de7f249 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -664,42 +664,47 @@ static int irq_has_perm(struct domain *d, uint8_t pirq, uint8_t access)
         return rc;
 }
 
-static int iomem_has_perm(struct domain *d, unsigned long mfn, uint8_t access)
-{
+struct iomem_has_perm_data {
+    struct domain_security_struct *ssec, *tsec;
     u32 perm;
-    u32 rsid;
-    int rc = -EPERM;
+};
 
-    struct domain_security_struct *ssec, *tsec;
+static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long end)
+{
+    struct iomem_has_perm_data *data = v;
     struct avc_audit_data ad;
+    int rc = -EPERM;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
-    if ( rc )
-        return rc;
-
-    if ( access )
-        perm = RESOURCE__ADD_IOMEM;
-    else
-        perm = RESOURCE__REMOVE_IOMEM;
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = start;
 
-    ssec = current->domain->ssid;
-    tsec = d->ssid;
+    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
-    rc = security_iomem_sid(mfn, &rsid);
     if ( rc )
         return rc;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = mfn;
+    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+}
 
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+static int iomem_has_perm(struct domain *d, unsigned long start, unsigned long end, uint8_t access)
+{
+    struct iomem_has_perm_data data;
+    int rc;
 
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+                         resource_to_perm(access));
     if ( rc )
         return rc;
 
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
-                        RESOURCE__USE, &ad);
+    if ( access )
+        data.perm = RESOURCE__ADD_IOMEM;
+    else
+        data.perm = RESOURCE__REMOVE_IOMEM;
+
+    data.ssec = current->domain->ssid;
+    data.tsec = d->ssid;
+
+    return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
 static int flask_perfcontrol(void)
@@ -736,45 +741,49 @@ static int flask_shadow_control(struct domain *d, uint32_t op)
     return domain_has_perm(current->domain, d, SECCLASS_SHADOW, perm);
 }
 
-static int ioport_has_perm(struct domain *d, uint32_t ioport, uint8_t access)
-{
+struct ioport_has_perm_data {
+    struct domain_security_struct *ssec, *tsec;
     u32 perm;
-    u32 rsid;
-    int rc = -EPERM;
+};
 
+static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long end)
+{
+    struct ioport_has_perm_data *data = v;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec, *tsec;
+    int rc;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = start;
+
+    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    if ( access )
-        perm = RESOURCE__ADD_IOPORT;
-    else
-        perm = RESOURCE__REMOVE_IOPORT;
+    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+}
 
-    ssec = current->domain->ssid;
-    tsec = d->ssid;
 
-    rc = security_ioport_sid(ioport, &rsid);
-    if ( rc )
-        return rc;
+static int ioport_has_perm(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+{
+    int rc;
+    struct ioport_has_perm_data data;
 
-    AVC_AUDIT_DATA_INIT(&ad, DEV);
-    ad.device = ioport;
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+                         resource_to_perm(access));
 
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
     if ( rc )
         return rc;
 
     if ( access )
-        return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
-                            RESOURCE__USE, &ad);
+        data.perm = RESOURCE__ADD_IOPORT;
     else
-        return rc;
+        data.perm = RESOURCE__REMOVE_IOPORT;
+
+    data.ssec = current->domain->ssid;
+    data.tsec = d->ssid;
+
+    return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
 
 static int flask_getpageframeinfo(struct page_info *page)
@@ -1184,31 +1193,25 @@ static int io_has_perm(struct domain *d, char *name, unsigned long s,
 
     if ( strcmp(name, "I/O Memory") == 0 )
     {
-        rc = iomem_has_perm(d, s, access);
+        rc = iomem_has_perm(d, s, e, access);
         if ( rc )
             return rc;
-
-        if ( s != e )
-            rc = iomem_has_perm(d, e, access);
     }
     else if ( strcmp(name, "Interrupts") == 0 )
     {
-        rc = irq_has_perm(d, s, access);
-        if ( rc )
-            return rc;
-
-        if ( s != e )
-            rc = irq_has_perm(d, e, access);
+        while (s <= e) {
+            rc = irq_has_perm(d, s, access);
+            if ( rc )
+                return rc;
+            s++;
+        }
     }
 #ifdef CONFIG_X86
     else if ( strcmp(name, "I/O Ports") == 0 )
     {
-        rc = ioport_has_perm(d, s, access);
+        rc = ioport_has_perm(d, s, e, access);
         if ( rc )
             return rc;
-
-        if ( s != e )
-            rc = ioport_has_perm(d, e, access);
     }
 #endif
 
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 8a64b0a..0dc21c8 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -82,6 +82,14 @@ int security_device_sid(u32 device, u32 *out_sid);
 int security_validate_transition(u32 oldsid, u32 newsid, u32 tasksid,
                                                                     u16 tclass);
 
+typedef int (*security_iterate_fn)(void *data, u32 sid, unsigned long start,
+                                                        unsigned long end);
+int security_iterate_iomem_sids(unsigned long start, unsigned long end,
+                                security_iterate_fn fn, void *data);
+
+int security_iterate_ioport_sids(u32 start, u32 end,
+                                security_iterate_fn fn, void *data);
+
 int security_ocontext_add(char *ocontext, unsigned long low,
                            unsigned long high, u32 sid);
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 6e72800..b880762 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1594,6 +1594,53 @@ out:
     return rc;
 }
 
+int security_iterate_iomem_sids(unsigned long start, unsigned long end,
+                                security_iterate_fn fn, void *data)
+{
+    struct ocontext *c;
+    int rc = 0;
+
+    POLICY_RDLOCK;
+
+    c = policydb.ocontexts[OCON_IOMEM];
+    while (c && c->u.iomem.high_iomem < start)
+        c = c->next;
+
+    while (c && c->u.iomem.low_iomem <= end) {
+        if (!c->sid[0])
+        {
+            rc = sidtab_context_to_sid(&sidtab, &c->context[0], &c->sid[0]);
+            if ( rc )
+                goto out;
+        }
+        if (start < c->u.iomem.low_iomem) {
+            /* found a gap */
+            rc = fn(data, SECINITSID_IOMEM, start, c->u.iomem.low_iomem - 1);
+            if (rc)
+                goto out;
+            start = c->u.iomem.low_iomem;
+        }
+        if (end <= c->u.iomem.high_iomem) {
+            /* iteration ends in the middle of this range */
+            rc = fn(data, c->sid[0], start, end);
+            goto out;
+        }
+
+        rc = fn(data, c->sid[0], start, c->u.iomem.high_iomem);
+        if (rc)
+            goto out;
+        start = c->u.iomem.high_iomem + 1;
+
+        c = c->next;
+    }
+
+    rc = fn(data, SECINITSID_IOMEM, start, end);
+
+out:
+    POLICY_RDUNLOCK;
+    return rc;
+}
+
 /**
  * security_ioport_sid - Obtain the SID for an ioport.
  * @ioport: ioport
@@ -1635,6 +1682,53 @@ out:
     return rc;
 }
 
+int security_iterate_ioport_sids(u32 start, u32 end,
+                                security_iterate_fn fn, void *data)
+{
+    struct ocontext *c;
+    int rc = 0;
+
+    POLICY_RDLOCK;
+
+    c = policydb.ocontexts[OCON_IOPORT];
+    while (c && c->u.ioport.high_ioport < start)
+        c = c->next;
+
+    while (c && c->u.ioport.low_ioport <= end) {
+        if (!c->sid[0])
+        {
+            rc = sidtab_context_to_sid(&sidtab, &c->context[0], &c->sid[0]);
+            if ( rc )
+                goto out;
+        }
+        if (start < c->u.ioport.low_ioport) {
+            /* found a gap */
+            rc = fn(data, SECINITSID_IOPORT, start, c->u.ioport.low_ioport - 1);
+            if (rc)
+                goto out;
+            start = c->u.ioport.low_ioport;
+        }
+        if (end <= c->u.ioport.high_ioport) {
+            /* iteration ends in the middle of this range */
+            rc = fn(data, c->sid[0], start, end);
+            goto out;
+        }
+
+        rc = fn(data, c->sid[0], start, c->u.ioport.high_ioport);
+        if (rc)
+            goto out;
+        start = c->u.ioport.high_ioport + 1;
+
+        c = c->next;
+    }
+
+    rc = fn(data, SECINITSID_IOPORT, start, end);
+
+out:
+    POLICY_RDUNLOCK;
+    return rc;
+}
+
 /**
  * security_device_sid - Obtain the SID for a PCI device.
  * @ioport: device
@@ -1963,6 +2057,7 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
     int ret = 0;
     int ocon = 0;
     struct ocontext *c;
+    struct ocontext *prev;
     struct ocontext *add;
 
     if ( (ocon = determine_ocontext(ocontext)) < 0 )
@@ -2006,23 +2101,27 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
         add->u.ioport.low_ioport = low;
         add->u.ioport.high_ioport = high;
 
+        prev = NULL;
         c = policydb.ocontexts[OCON_IOPORT];
-        while ( c )
-        {
-            if ( c->u.ioport.low_ioport <= add->u.ioport.high_ioport &&
-                 add->u.ioport.low_ioport <= c->u.ioport.high_ioport )
-            {
-                printk("%s: IO Port overlap with entry 0x%x - 0x%x\n",
-                       __FUNCTION__, c->u.ioport.low_ioport,
-                       c->u.ioport.high_ioport);
-                ret = -EINVAL;
-                break;
-            }
+
+        while ( c && c->u.ioport.high_ioport < low ) {
+            prev = c;
             c = c->next;
         }
 
-        if ( ret == 0 )
+        if (c && c->u.ioport.low_ioport <= high)
         {
+            printk("%s: IO Port overlap with entry 0x%x - 0x%x\n",
+                   __FUNCTION__, c->u.ioport.low_ioport,
+                   c->u.ioport.high_ioport);
+            ret = -EINVAL;
+            break;
+        }
+
+        if (prev) {
+            add->next = prev->next;
+            prev->next = add;
+        } else {
             add->next = policydb.ocontexts[OCON_IOPORT];
             policydb.ocontexts[OCON_IOPORT] = add;
         }
@@ -2032,23 +2131,27 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
         add->u.iomem.low_iomem = low;
         add->u.iomem.high_iomem = high;
 
+        prev = NULL;
         c = policydb.ocontexts[OCON_IOMEM];
-        while ( c )
-        {
-            if ( c->u.iomem.low_iomem <= add->u.iomem.high_iomem &&
-                 add->u.iomem.low_iomem <= c->u.iomem.high_iomem )
-            {
-                printk("%s: IO Memory overlap with entry 0x%x - 0x%x\n",
-                       __FUNCTION__, c->u.iomem.low_iomem,
-                       c->u.iomem.high_iomem);
-                ret = -EINVAL;
-                break;
-            }
+
+        while ( c && c->u.iomem.high_iomem < low ) {
+            prev = c;
             c = c->next;
         }
 
-        if ( ret == 0 )
+        if (c && c->u.iomem.low_iomem <= high)
         {
+            printk("%s: IO Memory overlap with entry 0x%x - 0x%x\n",
+                   __FUNCTION__, c->u.iomem.low_iomem,
+                   c->u.iomem.high_iomem);
+            ret = -EINVAL;
+            break;
+        }
+
+        if (prev) {
+            add->next = prev->next;
+            prev->next = add;
+        } else {
             add->next = policydb.ocontexts[OCON_IOMEM];
             policydb.ocontexts[OCON_IOMEM] = add;
         }
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 22:45:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 22:45:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RScc1-0003VB-RD; Mon, 21 Nov 2011 22:45:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RScc0-0003V3-Jx
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 22:45:16 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321915485!5173455!1
X-Originating-IP: [203.16.207.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31516 invoked from network); 21 Nov 2011 22:44:48 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-8.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Nov 2011 22:44:48 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RScbR-0004HT-4R; Tue, 22 Nov 2011 09:44:41 +1100
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 22 Nov 2011 09:44:39 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EDFDB9@trantor>
In-Reply-To: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] virtualization of desktop applications
Thread-Index: AcyohGBwNtMoDi5+QjSKLJPvbERXwAAGp69Q
References: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
From: "James Harper" <james.harper@bendigoit.com.au>
To: "Evandro Abreu" <evandro.abreu@gmail.com>, <xen-devel@lists.xensource.com>
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] virtualization of desktop applications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> I'm starting to study with virtualization of desktop applications and
would like
> tips on how to display a virtual machine in the browser. Could anyone
give
> me tips or links.
> 

A java based vnc applet should run in a browser. That might be a good
place to start. If you google for "vnc applet" you might find something
useful.

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 21 22:45:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 21 Nov 2011 22:45:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RScc1-0003VB-RD; Mon, 21 Nov 2011 22:45:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RScc0-0003V3-Jx
	for xen-devel@lists.xensource.com; Mon, 21 Nov 2011 22:45:16 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321915485!5173455!1
X-Originating-IP: [203.16.207.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31516 invoked from network); 21 Nov 2011 22:44:48 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-8.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Nov 2011 22:44:48 -0000
Received: from trantor.int.sbss.com.au ([192.168.200.206]
	helo=mail.bendigoit.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RScbR-0004HT-4R; Tue, 22 Nov 2011 09:44:41 +1100
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 22 Nov 2011 09:44:39 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EDFDB9@trantor>
In-Reply-To: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] virtualization of desktop applications
Thread-Index: AcyohGBwNtMoDi5+QjSKLJPvbERXwAAGp69Q
References: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
From: "James Harper" <james.harper@bendigoit.com.au>
To: "Evandro Abreu" <evandro.abreu@gmail.com>, <xen-devel@lists.xensource.com>
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] virtualization of desktop applications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> I'm starting to study with virtualization of desktop applications and
would like
> tips on how to display a virtual machine in the browser. Could anyone
give
> me tips or links.
> 

A java based vnc applet should run in a browser. That might be a good
place to start. If you google for "vnc applet" you might find something
useful.

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 00:23:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 00:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSe8T-0005Vh-Fz; Tue, 22 Nov 2011 00:22:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSe8R-0005Vc-7h
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 00:22:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321921305!57707308!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3057 invoked from network); 22 Nov 2011 00:21:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 00:21:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,550,1315180800"; 
   d="scan'208";a="9052417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 00:22:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 00:22:27 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSe83-0008Ra-A1;
	Tue, 22 Nov 2011 00:22:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSe83-0002lm-9L;
	Tue, 22 Nov 2011 00:22:27 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9946-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 00:22:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9946: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9946 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9946/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9817
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  9c350ab8d3ea
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24168:9c350ab8d3ea
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Nov 21 09:29:31 2011 +0100
    
    x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
    
    Xen itself (as much as Linux) relies on this behavior, so it should
    also emulate it properly. Not doing so reportedly gets in the way of
    kexec inside a HVM guest.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24167:335e8273a3f3
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 00:23:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 00:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSe8T-0005Vh-Fz; Tue, 22 Nov 2011 00:22:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSe8R-0005Vc-7h
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 00:22:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321921305!57707308!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3057 invoked from network); 22 Nov 2011 00:21:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 00:21:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,550,1315180800"; 
   d="scan'208";a="9052417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 00:22:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 00:22:27 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSe83-0008Ra-A1;
	Tue, 22 Nov 2011 00:22:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSe83-0002lm-9L;
	Tue, 22 Nov 2011 00:22:27 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9946-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 00:22:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9946: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9946 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9946/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9855
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9855
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win-vcpus1    7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-win           7 windows-install            fail REGR. vs. 9855
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9855
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9855
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9855
 test-amd64-amd64-win          7 windows-install            fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9817
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass

version targeted for testing:
 xen                  9c350ab8d3ea
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24168:9c350ab8d3ea
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Nov 21 09:29:31 2011 +0100
    
    x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
    
    Xen itself (as much as Linux) relies on this behavior, so it should
    also emulate it properly. Not doing so reportedly gets in the way of
    kexec inside a HVM guest.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24167:335e8273a3f3
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 00:35:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 00:35:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSeJh-0005kK-2h; Tue, 22 Nov 2011 00:34:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSeJf-0005kF-QH
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 00:34:28 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321921924!45239570!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9580 invoked from network); 22 Nov 2011 00:32:05 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 00:32:05 -0000
Received: by ghbz2 with SMTP id z2so173537ghb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 16:34:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=uJpNqUHhm2hSlYmfjnfGM/BgEga6BqP/15dATClyQTc=;
	b=gMAkpjcGAp7j2nBSY18iK+v6X6Tu3h7fqDMgifauitETte/qM+dt/gikfL/RjjJ1Ip
	cQSdVn1PSJSlgkUdUVgU89chgtPcmaiKDrDFeQRss81fN9RGCr/G2E3q9l5GQhCo4vHV
	BoRfVKUJnTUiC184xvABAhACWDQSzzsik/VLA=
MIME-Version: 1.0
Received: by 10.68.16.5 with SMTP id b5mr35322379pbd.95.1321922043041; Mon, 21
	Nov 2011 16:34:03 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Mon, 21 Nov 2011 16:34:03 -0800 (PST)
Date: Tue, 22 Nov 2011 08:34:03 +0800
Message-ID: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target new
 target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

This is to report that using xl create hvm domains will fail with the
below error:

libxl: error: libxl.c:2150:libxl_set_memory_target new target 0 for
dom0 is below the minimum threshold

However using xm create hvm domain is working fine.

Information about xen version:

hg_root = http://xenbits.xensource.com/staging/xen-4.1-testing.hg
hg_changeset = 23190

dom0 kernel information:

git url = git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
git branch = xen/next-2.6.32
git commit = faa0ece5eb2f2bc4d9b149bc46b677b1df05d332

Last known working changeset for xen-4.1-testing before upgrade is
23110 and I don't have chance to test other changeset.  Sorry.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 00:35:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 00:35:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSeJh-0005kK-2h; Tue, 22 Nov 2011 00:34:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSeJf-0005kF-QH
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 00:34:28 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321921924!45239570!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9580 invoked from network); 22 Nov 2011 00:32:05 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 00:32:05 -0000
Received: by ghbz2 with SMTP id z2so173537ghb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 16:34:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=uJpNqUHhm2hSlYmfjnfGM/BgEga6BqP/15dATClyQTc=;
	b=gMAkpjcGAp7j2nBSY18iK+v6X6Tu3h7fqDMgifauitETte/qM+dt/gikfL/RjjJ1Ip
	cQSdVn1PSJSlgkUdUVgU89chgtPcmaiKDrDFeQRss81fN9RGCr/G2E3q9l5GQhCo4vHV
	BoRfVKUJnTUiC184xvABAhACWDQSzzsik/VLA=
MIME-Version: 1.0
Received: by 10.68.16.5 with SMTP id b5mr35322379pbd.95.1321922043041; Mon, 21
	Nov 2011 16:34:03 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Mon, 21 Nov 2011 16:34:03 -0800 (PST)
Date: Tue, 22 Nov 2011 08:34:03 +0800
Message-ID: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target new
 target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

This is to report that using xl create hvm domains will fail with the
below error:

libxl: error: libxl.c:2150:libxl_set_memory_target new target 0 for
dom0 is below the minimum threshold

However using xm create hvm domain is working fine.

Information about xen version:

hg_root = http://xenbits.xensource.com/staging/xen-4.1-testing.hg
hg_changeset = 23190

dom0 kernel information:

git url = git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
git branch = xen/next-2.6.32
git commit = faa0ece5eb2f2bc4d9b149bc46b677b1df05d332

Last known working changeset for xen-4.1-testing before upgrade is
23110 and I don't have chance to test other changeset.  Sorry.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 01:01:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 01:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSeit-0000iK-LD; Tue, 22 Nov 2011 01:00:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rusty@ozlabs.org>) id 1RSeir-0008V1-Rn
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 01:00:30 +0000
X-Env-Sender: rusty@ozlabs.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1321923598!4052509!1
X-Originating-IP: [203.10.76.45]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16944 invoked from network); 22 Nov 2011 01:00:01 -0000
Received: from ozlabs.org (HELO ozlabs.org) (203.10.76.45)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 01:00:01 -0000
Received: by ozlabs.org (Postfix, from userid 1011)
	id 48F2A1007D4; Tue, 22 Nov 2011 11:59:55 +1100 (EST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Miche Baker-Harvey <miche@google.com>
In-Reply-To: <CAB8Rdaqno9kVHB8wsbH5=zs_ppUkd1G=siywFFfH3Ud21qK3FA@mail.gmail.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<87lira9ii7.fsf@rustcorp.com.au>
	<CAB8Rdaqno9kVHB8wsbH5=zs_ppUkd1G=siywFFfH3Ud21qK3FA@mail.gmail.com>
User-Agent: Notmuch/0.6.1-1 (http://notmuchmail.org) Emacs/23.3.1
	(i686-pc-linux-gnu)
Date: Tue, 22 Nov 2011 11:28:09 +1030
Message-ID: <877h2tx9b2.fsf@rustcorp.com.au>
MIME-Version: 1.0
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Amit Shah <amit.shah@redhat.com>,
	Mike Waychison <mikew@google.com>, ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 21 Nov 2011 14:16:38 -0800, Miche Baker-Harvey <miche@google.com> wrote:
> Thanks, Rusty.  I'm not using QEMU though, just KVM.   I create the device, wait
> for the message from the guest that the device is ready, and then add ports.
> 
> Miche

OK, since Amit was the one who implemented multi-port console, I'm going
to hand this to him.

I'm sure he's been looking for excuses to dive back into the console
code!

Cheers,
Rusty.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 01:01:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 01:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSeit-0000iK-LD; Tue, 22 Nov 2011 01:00:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rusty@ozlabs.org>) id 1RSeir-0008V1-Rn
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 01:00:30 +0000
X-Env-Sender: rusty@ozlabs.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1321923598!4052509!1
X-Originating-IP: [203.10.76.45]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16944 invoked from network); 22 Nov 2011 01:00:01 -0000
Received: from ozlabs.org (HELO ozlabs.org) (203.10.76.45)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 01:00:01 -0000
Received: by ozlabs.org (Postfix, from userid 1011)
	id 48F2A1007D4; Tue, 22 Nov 2011 11:59:55 +1100 (EST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Miche Baker-Harvey <miche@google.com>
In-Reply-To: <CAB8Rdaqno9kVHB8wsbH5=zs_ppUkd1G=siywFFfH3Ud21qK3FA@mail.gmail.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<87lira9ii7.fsf@rustcorp.com.au>
	<CAB8Rdaqno9kVHB8wsbH5=zs_ppUkd1G=siywFFfH3Ud21qK3FA@mail.gmail.com>
User-Agent: Notmuch/0.6.1-1 (http://notmuchmail.org) Emacs/23.3.1
	(i686-pc-linux-gnu)
Date: Tue, 22 Nov 2011 11:28:09 +1030
Message-ID: <877h2tx9b2.fsf@rustcorp.com.au>
MIME-Version: 1.0
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Amit Shah <amit.shah@redhat.com>,
	Mike Waychison <mikew@google.com>, ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 21 Nov 2011 14:16:38 -0800, Miche Baker-Harvey <miche@google.com> wrote:
> Thanks, Rusty.  I'm not using QEMU though, just KVM.   I create the device, wait
> for the message from the guest that the device is ready, and then add ports.
> 
> Miche

OK, since Amit was the one who implemented multi-port console, I'm going
to hand this to him.

I'm sure he's been looking for excuses to dive back into the console
code!

Cheers,
Rusty.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 01:59:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 01:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSfdK-0001ju-Ey; Tue, 22 Nov 2011 01:58:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSfdI-0001jo-I1
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 01:58:49 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1321927098!5777244!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8786 invoked from network); 22 Nov 2011 01:58:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 01:58:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAM1wE1K005727
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 01:58:14 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAM1wC7l019031
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 01:58:12 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAM1w4IR024020; Mon, 21 Nov 2011 19:58:04 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 17:58:04 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 09:58:06 +0800
Message-Id: <1321927086-3917-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECA416D.90602@oracle.com>
References: <4ECA416D.90602@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4ECB01B8.002A,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/4] xen/granttable: Introducing grant table V2
	stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

This patch introduces new structures of grant table V2, grant table V2 is an
extension from V1. Grant table is shared between guest and Xen, and Xen is
responsible to do corresponding work for grant operations, such as: figure
out guest's grant table version, perform different actions based on
different grant table version, etc. Although full-page structure of V2
is different from V1, it play the same role as V1.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 arch/x86/xen/grant-table.c          |    7 +-
 drivers/xen/grant-table.c           |  181 +++++++++++++++++++++++++++--------
 include/xen/grant_table.h           |    4 +-
 include/xen/interface/grant_table.h |  167 +++++++++++++++++++++++++++++++-
 include/xen/interface/xen.h         |    2 +
 5 files changed, 310 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index 6bbfd7a..c6ab2e7 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -64,10 +64,10 @@ static int unmap_pte_fn(pte_t *pte, struct page *pmd_page,
 
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
-			   struct grant_entry **__shared)
+			   void **__shared)
 {
 	int rc;
-	struct grant_entry *shared = *__shared;
+	void *shared = *__shared;
 
 	if (shared == NULL) {
 		struct vm_struct *area =
@@ -83,8 +83,7 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 	return rc;
 }
 
-void arch_gnttab_unmap_shared(struct grant_entry *shared,
-			      unsigned long nr_gframes)
+void arch_gnttab_unmap_shared(void *shared, unsigned long nr_gframes)
 {
 	apply_to_page_range(&init_mm, (unsigned long)shared,
 			    PAGE_SIZE * nr_gframes, unmap_pte_fn, NULL);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..18355a5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -53,7 +53,7 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry))
+#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry_v1))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -64,7 +64,63 @@ static DEFINE_SPINLOCK(gnttab_list_lock);
 unsigned long xen_hvm_resume_frames;
 EXPORT_SYMBOL_GPL(xen_hvm_resume_frames);
 
-static struct grant_entry *shared;
+static union {
+	struct grant_entry_v1 *v1;
+	void *addr;
+} gnttab_shared;
+
+/*This is a structure of function pointers for grant table*/
+struct gnttab_ops {
+	/*
+	 * Mapping a list of frames for storing grant entries. First input
+	 * parameter is used to storing grant table address when grant table
+	 * being setup, second parameter is the number of frames to map grant
+	 * table. Returning GNTST_okay means success and negative value means
+	 * failure.
+	 */
+	int (*map_frames)(unsigned long *, unsigned int);
+	/*
+	 * Release a list of frames which are mapped in map_frames for grant
+	 * entry status.
+	 */
+	void (*unmap_frames)(void);
+	/*
+	 * Introducing a valid entry into the grant table, granting the frame
+	 * of this grant entry to domain for accessing, or transfering, or
+	 * transitively accessing. First input parameter is reference of this
+	 * introduced grant entry, second one is domid of granted domain, third
+	 * one is the frame to be granted, and the last one is status of the
+	 * grant entry to be updated.
+	 */
+	void (*update_entry)(grant_ref_t, domid_t, unsigned long, unsigned);
+	/*
+	 * Stop granting a grant entry to domain for accessing. First input
+	 * parameter is reference of a grant entry whose grant access will be
+	 * stopped, second one is not in use now. If the grant entry is
+	 * currently mapped for reading or writing, just return failure(==0)
+	 * directly and don't tear down the grant access. Otherwise, stop grant
+	 * access for this entry and return success(==1).
+	 */
+	int (*end_foreign_access_ref)(grant_ref_t, int);
+	/*
+	 * Stop granting a grant entry to domain for transfer. If tranfer has
+	 * not started, just reclaim the grant entry and return failure(==0).
+	 * Otherwise, wait for the transfer to complete and then return the
+	 * frame.
+	 */
+	unsigned long (*end_foreign_transfer_ref)(grant_ref_t);
+	/*
+	 * Query the status of a grant entry. Input parameter is reference of
+	 * queried grant entry, return value is the status of queried entry.
+	 * Detailed status(writing/reading) can be gotten from the return value
+	 * by bit operations.
+	 */
+	int (*query_foreign_access)(grant_ref_t);
+};
+
+static struct gnttab_ops *gnttab_interface;
+
+static int grant_table_version;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
 
@@ -142,23 +198,23 @@ static void put_free_entry(grant_ref_t ref)
 	spin_unlock_irqrestore(&gnttab_list_lock, flags);
 }
 
-static void update_grant_entry(grant_ref_t ref, domid_t domid,
-			       unsigned long frame, unsigned flags)
+/*
+ * Introducing a valid entry into the grant table:
+ *  1. Write ent->domid.
+ *  2. Write ent->frame:
+ *      GTF_permit_access:   Frame to which access is permitted.
+ *      GTF_accept_transfer: Pseudo-phys frame slot being filled by new
+ *                           frame, or zero if none.
+ *  3. Write memory barrier (WMB).
+ *  4. Write ent->flags, inc. valid type.
+ */
+static void gnttab_update_entry_v1(grant_ref_t ref, domid_t domid,
+				   unsigned long frame, unsigned flags)
 {
-	/*
-	 * Introducing a valid entry into the grant table:
-	 *  1. Write ent->domid.
-	 *  2. Write ent->frame:
-	 *      GTF_permit_access:   Frame to which access is permitted.
-	 *      GTF_accept_transfer: Pseudo-phys frame slot being filled by new
-	 *                           frame, or zero if none.
-	 *  3. Write memory barrier (WMB).
-	 *  4. Write ent->flags, inc. valid type.
-	 */
-	shared[ref].frame = frame;
-	shared[ref].domid = domid;
+	gnttab_shared.v1[ref].domid = domid;
+	gnttab_shared.v1[ref].frame = frame;
 	wmb();
-	shared[ref].flags = flags;
+	gnttab_shared.v1[ref].flags = flags;
 }
 
 /*
@@ -167,7 +223,7 @@ static void update_grant_entry(grant_ref_t ref, domid_t domid,
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly)
 {
-	update_grant_entry(ref, domid, frame,
+	gnttab_interface->update_entry(ref, domid, frame,
 			   GTF_permit_access | (readonly ? GTF_readonly : 0));
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref);
@@ -187,31 +243,37 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
-int gnttab_query_foreign_access(grant_ref_t ref)
+static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
-	u16 nflags;
-
-	nflags = shared[ref].flags;
+	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
+}
 
-	return nflags & (GTF_reading|GTF_writing);
+int gnttab_query_foreign_access(grant_ref_t ref)
+{
+	return gnttab_interface->query_foreign_access(ref);
 }
 EXPORT_SYMBOL_GPL(gnttab_query_foreign_access);
 
-int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 {
 	u16 flags, nflags;
 
-	nflags = shared[ref].flags;
+	nflags = gnttab_shared.v1[ref].flags;
 	do {
 		flags = nflags;
 		if (flags & (GTF_reading|GTF_writing)) {
 			printk(KERN_ALERT "WARNING: g.e. still in use!\n");
 			return 0;
 		}
-	} while ((nflags = sync_cmpxchg(&shared[ref].flags, flags, 0)) != flags);
+	} while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0)) != flags);
 
 	return 1;
 }
+
+int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+{
+	return gnttab_interface->end_foreign_access_ref(ref, readonly);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);
 
 void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
@@ -246,11 +308,11 @@ EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer);
 void gnttab_grant_foreign_transfer_ref(grant_ref_t ref, domid_t domid,
 				       unsigned long pfn)
 {
-	update_grant_entry(ref, domid, pfn, GTF_accept_transfer);
+	gnttab_interface->update_entry(ref, domid, pfn, GTF_accept_transfer);
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer_ref);
 
-unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 {
 	unsigned long frame;
 	u16           flags;
@@ -259,24 +321,29 @@ unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
 	 * If a transfer is not even yet started, try to reclaim the grant
 	 * reference and return failure (== 0).
 	 */
-	while (!((flags = shared[ref].flags) & GTF_transfer_committed)) {
-		if (sync_cmpxchg(&shared[ref].flags, flags, 0) == flags)
+	while (!((flags = gnttab_shared.v1[ref].flags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0) == flags)
 			return 0;
 		cpu_relax();
 	}
 
 	/* If a transfer is in progress then wait until it is completed. */
 	while (!(flags & GTF_transfer_completed)) {
-		flags = shared[ref].flags;
+		flags = gnttab_shared.v1[ref].flags;
 		cpu_relax();
 	}
 
 	rmb();	/* Read the frame number /after/ reading completion status. */
-	frame = shared[ref].frame;
+	frame = gnttab_shared.v1[ref].frame;
 	BUG_ON(frame == 0);
 
 	return frame;
 }
+
+unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+{
+	return gnttab_interface->end_foreign_transfer_ref(ref);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_transfer_ref);
 
 unsigned long gnttab_end_foreign_transfer(grant_ref_t ref)
@@ -520,6 +587,23 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
+{
+	int rc;
+
+	rc = arch_gnttab_map_shared(frames, nr_gframes,
+				    gnttab_max_grant_frames(),
+				    &gnttab_shared.addr);
+	BUG_ON(rc);
+
+	return 0;
+}
+
+static void gnttab_unmap_frames_v1(void)
+{
+	arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
@@ -567,19 +651,35 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 
 	BUG_ON(rc || setup.status);
 
-	rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
-				    &shared);
-	BUG_ON(rc);
+	rc = gnttab_interface->map_frames(frames, nr_gframes);
 
 	kfree(frames);
 
-	return 0;
+	return rc;
+}
+
+static struct gnttab_ops gnttab_v1_ops = {
+	.map_frames			= gnttab_map_frames_v1,
+	.unmap_frames			= gnttab_unmap_frames_v1,
+	.update_entry			= gnttab_update_entry_v1,
+	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v1,
+	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v1,
+	.query_foreign_access		= gnttab_query_foreign_access_v1,
+};
+
+static void gnttab_request_version(void)
+{
+	grant_table_version = 1;
+	gnttab_interface = &gnttab_v1_ops;
+	printk(KERN_INFO "Grant tables using version %d layout.\n",
+		grant_table_version);
 }
 
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
 
+	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
@@ -587,9 +687,10 @@ int gnttab_resume(void)
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-	if (!shared) {
-		shared = ioremap(xen_hvm_resume_frames, PAGE_SIZE * max_nr_gframes);
-		if (shared == NULL) {
+	if (gnttab_shared.addr == NULL) {
+		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
+						PAGE_SIZE * max_nr_gframes);
+		if (gnttab_shared.addr == NULL) {
 			printk(KERN_WARNING
 					"Failed to ioremap gnttab share frames!");
 			return -ENOMEM;
@@ -603,7 +704,7 @@ int gnttab_resume(void)
 
 int gnttab_suspend(void)
 {
-	arch_gnttab_unmap_shared(shared, nr_grant_frames);
+	gnttab_interface->unmap_frames();
 	return 0;
 }
 
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e2dfc..c7a40f8 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -145,8 +145,8 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
-			   struct grant_entry **__shared);
-void arch_gnttab_unmap_shared(struct grant_entry *shared,
+			   void **__shared);
+void arch_gnttab_unmap_shared(void *shared,
 			      unsigned long nr_gframes);
 
 extern unsigned long xen_hvm_resume_frames;
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index 39e5717..a17d844 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -85,12 +85,22 @@
  */
 
 /*
+ * Reference to a grant entry in a specified domain's grant table.
+ */
+typedef uint32_t grant_ref_t;
+
+/*
  * A grant table comprises a packed array of grant entries in one or more
  * page frames shared between Xen and a guest.
  * [XEN]: This field is written by Xen and read by the sharing guest.
  * [GST]: This field is written by the guest and read by Xen.
  */
-struct grant_entry {
+
+/*
+ * Version 1 of the grant table entry structure is maintained purely
+ * for backwards compatibility.  New guests should use version 2.
+ */
+struct grant_entry_v1 {
     /* GTF_xxx: various type and flag information.  [XEN,GST] */
     uint16_t flags;
     /* The domain being granted foreign privileges. [GST] */
@@ -108,10 +118,13 @@ struct grant_entry {
  *  GTF_permit_access: Allow @domid to map/access @frame.
  *  GTF_accept_transfer: Allow @domid to transfer ownership of one page frame
  *                       to this guest. Xen writes the page number to @frame.
+ *  GTF_transitive: Allow @domid to transitively access a subrange of
+ *                  @trans_grant in @trans_domid.  No mappings are allowed.
  */
 #define GTF_invalid         (0U<<0)
 #define GTF_permit_access   (1U<<0)
 #define GTF_accept_transfer (2U<<0)
+#define GTF_transitive      (3U<<0)
 #define GTF_type_mask       (3U<<0)
 
 /*
@@ -119,6 +132,9 @@ struct grant_entry {
  *  GTF_readonly: Restrict @domid to read-only mappings and accesses. [GST]
  *  GTF_reading: Grant entry is currently mapped for reading by @domid. [XEN]
  *  GTF_writing: Grant entry is currently mapped for writing by @domid. [XEN]
+ *  GTF_sub_page: Grant access to only a subrange of the page.  @domid
+ *                will only be allowed to copy from the grant, and not
+ *                map it. [GST]
  */
 #define _GTF_readonly       (2)
 #define GTF_readonly        (1U<<_GTF_readonly)
@@ -126,6 +142,8 @@ struct grant_entry {
 #define GTF_reading         (1U<<_GTF_reading)
 #define _GTF_writing        (4)
 #define GTF_writing         (1U<<_GTF_writing)
+#define _GTF_sub_page       (8)
+#define GTF_sub_page        (1U<<_GTF_sub_page)
 
 /*
  * Subflags for GTF_accept_transfer:
@@ -142,15 +160,81 @@ struct grant_entry {
 #define _GTF_transfer_completed (3)
 #define GTF_transfer_completed  (1U<<_GTF_transfer_completed)
 
+/*
+ * Version 2 grant table entries.  These fulfil the same role as
+ * version 1 entries, but can represent more complicated operations.
+ * Any given domain will have either a version 1 or a version 2 table,
+ * and every entry in the table will be the same version.
+ *
+ * The interface by which domains use grant references does not depend
+ * on the grant table version in use by the other domain.
+ */
 
-/***********************************
- * GRANT TABLE QUERIES AND USES
+/*
+ * Version 1 and version 2 grant entries share a common prefix.  The
+ * fields of the prefix are documented as part of struct
+ * grant_entry_v1.
  */
+struct grant_entry_header {
+    uint16_t flags;
+    domid_t  domid;
+};
 
 /*
- * Reference to a grant entry in a specified domain's grant table.
+ * Version 2 of the grant entry structure, here is an union because three
+ * different types are suppotted: full_page, sub_page and transitive.
+ */
+union grant_entry_v2 {
+    struct grant_entry_header hdr;
+
+    /*
+     * This member is used for V1-style full page grants, where either:
+     *
+     * -- hdr.type is GTF_accept_transfer, or
+     * -- hdr.type is GTF_permit_access and GTF_sub_page is not set.
+     *
+     * In that case, the frame field has the same semantics as the
+     * field of the same name in the V1 entry structure.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	uint32_t pad0;
+	uint64_t frame;
+    } full_page;
+
+    /*
+     * If the grant type is GTF_grant_access and GTF_sub_page is set,
+     * @domid is allowed to access bytes [@page_off,@page_off+@length)
+     * in frame @frame.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	uint16_t page_off;
+	uint16_t length;
+	uint64_t frame;
+    } sub_page;
+
+    /*
+     * If the grant is GTF_transitive, @domid is allowed to use the
+     * grant @gref in domain @trans_domid, as if it was the local
+     * domain.  Obviously, the transitive access must be compatible
+     * with the original grant.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	domid_t trans_domid;
+	uint16_t pad0;
+	grant_ref_t gref;
+    } transitive;
+
+    uint32_t __spacer[4]; /* Pad to a power of two */
+};
+
+typedef uint16_t grant_status_t;
+
+/***********************************
+ * GRANT TABLE QUERIES AND USES
  */
-typedef uint32_t grant_ref_t;
 
 /*
  * Handle to track a mapping created via a grant reference.
@@ -322,6 +406,79 @@ struct gnttab_query_size {
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
 
 /*
+ * GNTTABOP_unmap_and_replace: Destroy one or more grant-reference mappings
+ * tracked by <handle> but atomically replace the page table entry with one
+ * pointing to the machine address under <new_addr>.  <new_addr> will be
+ * redirected to the null entry.
+ * NOTES:
+ *  1. The call may fail in an undefined manner if either mapping is not
+ *     tracked by <handle>.
+ *  2. After executing a batch of unmaps, it is guaranteed that no stale
+ *     mappings will remain in the device or host TLBs.
+ */
+#define GNTTABOP_unmap_and_replace    7
+struct gnttab_unmap_and_replace {
+    /* IN parameters. */
+    uint64_t host_addr;
+    uint64_t new_addr;
+    grant_handle_t handle;
+    /* OUT parameters. */
+    int16_t  status;              /* GNTST_* */
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_unmap_and_replace);
+
+/*
+ * GNTTABOP_set_version: Request a particular version of the grant
+ * table shared table structure.  This operation can only be performed
+ * once in any given domain.  It must be performed before any grants
+ * are activated; otherwise, the domain will be stuck with version 1.
+ * The only defined versions are 1 and 2.
+ */
+#define GNTTABOP_set_version          8
+struct gnttab_set_version {
+    /* IN parameters */
+    uint32_t version;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_set_version);
+
+/*
+ * GNTTABOP_get_status_frames: Get the list of frames used to store grant
+ * status for <dom>. In grant format version 2, the status is separated
+ * from the other shared grant fields to allow more efficient synchronization
+ * using barriers instead of atomic cmpexch operations.
+ * <nr_frames> specify the size of vector <frame_list>.
+ * The frame addresses are returned in the <frame_list>.
+ * Only <nr_frames> addresses are returned, even if the table is larger.
+ * NOTES:
+ *  1. <dom> may be specified as DOMID_SELF.
+ *  2. Only a sufficiently-privileged domain may specify <dom> != DOMID_SELF.
+ */
+#define GNTTABOP_get_status_frames     9
+struct gnttab_get_status_frames {
+    /* IN parameters. */
+    uint32_t nr_frames;
+    domid_t  dom;
+    /* OUT parameters. */
+    int16_t  status;              /* GNTST_* */
+    GUEST_HANDLE(uint64_t) frame_list;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_status_frames);
+
+/*
+ * GNTTABOP_get_version: Get the grant table version which is in
+ * effect for domain <dom>.
+ */
+#define GNTTABOP_get_version          10
+struct gnttab_get_version {
+    /* IN parameters */
+    domid_t dom;
+    uint16_t pad;
+    /* OUT parameters */
+    uint32_t version;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_version);
+
+/*
  * Bitfield values for update_pin_status.flags.
  */
  /* Map the grant entry for access by I/O devices. */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..a890804 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -523,6 +523,8 @@ struct tmem_op {
 	} u;
 };
 
+DEFINE_GUEST_HANDLE(u64);
+
 #else /* __ASSEMBLY__ */
 
 /* In assembly code we cannot use C numeric constant suffixes. */
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 01:59:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 01:59:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSfdK-0001ju-Ey; Tue, 22 Nov 2011 01:58:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSfdI-0001jo-I1
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 01:58:49 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1321927098!5777244!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8786 invoked from network); 22 Nov 2011 01:58:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 01:58:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAM1wE1K005727
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 01:58:14 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAM1wC7l019031
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 01:58:12 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAM1w4IR024020; Mon, 21 Nov 2011 19:58:04 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 17:58:04 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 09:58:06 +0800
Message-Id: <1321927086-3917-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECA416D.90602@oracle.com>
References: <4ECA416D.90602@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4ECB01B8.002A,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/4] xen/granttable: Introducing grant table V2
	stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

This patch introduces new structures of grant table V2, grant table V2 is an
extension from V1. Grant table is shared between guest and Xen, and Xen is
responsible to do corresponding work for grant operations, such as: figure
out guest's grant table version, perform different actions based on
different grant table version, etc. Although full-page structure of V2
is different from V1, it play the same role as V1.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 arch/x86/xen/grant-table.c          |    7 +-
 drivers/xen/grant-table.c           |  181 +++++++++++++++++++++++++++--------
 include/xen/grant_table.h           |    4 +-
 include/xen/interface/grant_table.h |  167 +++++++++++++++++++++++++++++++-
 include/xen/interface/xen.h         |    2 +
 5 files changed, 310 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index 6bbfd7a..c6ab2e7 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -64,10 +64,10 @@ static int unmap_pte_fn(pte_t *pte, struct page *pmd_page,
 
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
-			   struct grant_entry **__shared)
+			   void **__shared)
 {
 	int rc;
-	struct grant_entry *shared = *__shared;
+	void *shared = *__shared;
 
 	if (shared == NULL) {
 		struct vm_struct *area =
@@ -83,8 +83,7 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 	return rc;
 }
 
-void arch_gnttab_unmap_shared(struct grant_entry *shared,
-			      unsigned long nr_gframes)
+void arch_gnttab_unmap_shared(void *shared, unsigned long nr_gframes)
 {
 	apply_to_page_range(&init_mm, (unsigned long)shared,
 			    PAGE_SIZE * nr_gframes, unmap_pte_fn, NULL);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..18355a5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -53,7 +53,7 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry))
+#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry_v1))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -64,7 +64,63 @@ static DEFINE_SPINLOCK(gnttab_list_lock);
 unsigned long xen_hvm_resume_frames;
 EXPORT_SYMBOL_GPL(xen_hvm_resume_frames);
 
-static struct grant_entry *shared;
+static union {
+	struct grant_entry_v1 *v1;
+	void *addr;
+} gnttab_shared;
+
+/*This is a structure of function pointers for grant table*/
+struct gnttab_ops {
+	/*
+	 * Mapping a list of frames for storing grant entries. First input
+	 * parameter is used to storing grant table address when grant table
+	 * being setup, second parameter is the number of frames to map grant
+	 * table. Returning GNTST_okay means success and negative value means
+	 * failure.
+	 */
+	int (*map_frames)(unsigned long *, unsigned int);
+	/*
+	 * Release a list of frames which are mapped in map_frames for grant
+	 * entry status.
+	 */
+	void (*unmap_frames)(void);
+	/*
+	 * Introducing a valid entry into the grant table, granting the frame
+	 * of this grant entry to domain for accessing, or transfering, or
+	 * transitively accessing. First input parameter is reference of this
+	 * introduced grant entry, second one is domid of granted domain, third
+	 * one is the frame to be granted, and the last one is status of the
+	 * grant entry to be updated.
+	 */
+	void (*update_entry)(grant_ref_t, domid_t, unsigned long, unsigned);
+	/*
+	 * Stop granting a grant entry to domain for accessing. First input
+	 * parameter is reference of a grant entry whose grant access will be
+	 * stopped, second one is not in use now. If the grant entry is
+	 * currently mapped for reading or writing, just return failure(==0)
+	 * directly and don't tear down the grant access. Otherwise, stop grant
+	 * access for this entry and return success(==1).
+	 */
+	int (*end_foreign_access_ref)(grant_ref_t, int);
+	/*
+	 * Stop granting a grant entry to domain for transfer. If tranfer has
+	 * not started, just reclaim the grant entry and return failure(==0).
+	 * Otherwise, wait for the transfer to complete and then return the
+	 * frame.
+	 */
+	unsigned long (*end_foreign_transfer_ref)(grant_ref_t);
+	/*
+	 * Query the status of a grant entry. Input parameter is reference of
+	 * queried grant entry, return value is the status of queried entry.
+	 * Detailed status(writing/reading) can be gotten from the return value
+	 * by bit operations.
+	 */
+	int (*query_foreign_access)(grant_ref_t);
+};
+
+static struct gnttab_ops *gnttab_interface;
+
+static int grant_table_version;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
 
@@ -142,23 +198,23 @@ static void put_free_entry(grant_ref_t ref)
 	spin_unlock_irqrestore(&gnttab_list_lock, flags);
 }
 
-static void update_grant_entry(grant_ref_t ref, domid_t domid,
-			       unsigned long frame, unsigned flags)
+/*
+ * Introducing a valid entry into the grant table:
+ *  1. Write ent->domid.
+ *  2. Write ent->frame:
+ *      GTF_permit_access:   Frame to which access is permitted.
+ *      GTF_accept_transfer: Pseudo-phys frame slot being filled by new
+ *                           frame, or zero if none.
+ *  3. Write memory barrier (WMB).
+ *  4. Write ent->flags, inc. valid type.
+ */
+static void gnttab_update_entry_v1(grant_ref_t ref, domid_t domid,
+				   unsigned long frame, unsigned flags)
 {
-	/*
-	 * Introducing a valid entry into the grant table:
-	 *  1. Write ent->domid.
-	 *  2. Write ent->frame:
-	 *      GTF_permit_access:   Frame to which access is permitted.
-	 *      GTF_accept_transfer: Pseudo-phys frame slot being filled by new
-	 *                           frame, or zero if none.
-	 *  3. Write memory barrier (WMB).
-	 *  4. Write ent->flags, inc. valid type.
-	 */
-	shared[ref].frame = frame;
-	shared[ref].domid = domid;
+	gnttab_shared.v1[ref].domid = domid;
+	gnttab_shared.v1[ref].frame = frame;
 	wmb();
-	shared[ref].flags = flags;
+	gnttab_shared.v1[ref].flags = flags;
 }
 
 /*
@@ -167,7 +223,7 @@ static void update_grant_entry(grant_ref_t ref, domid_t domid,
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly)
 {
-	update_grant_entry(ref, domid, frame,
+	gnttab_interface->update_entry(ref, domid, frame,
 			   GTF_permit_access | (readonly ? GTF_readonly : 0));
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref);
@@ -187,31 +243,37 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
-int gnttab_query_foreign_access(grant_ref_t ref)
+static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
-	u16 nflags;
-
-	nflags = shared[ref].flags;
+	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
+}
 
-	return nflags & (GTF_reading|GTF_writing);
+int gnttab_query_foreign_access(grant_ref_t ref)
+{
+	return gnttab_interface->query_foreign_access(ref);
 }
 EXPORT_SYMBOL_GPL(gnttab_query_foreign_access);
 
-int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 {
 	u16 flags, nflags;
 
-	nflags = shared[ref].flags;
+	nflags = gnttab_shared.v1[ref].flags;
 	do {
 		flags = nflags;
 		if (flags & (GTF_reading|GTF_writing)) {
 			printk(KERN_ALERT "WARNING: g.e. still in use!\n");
 			return 0;
 		}
-	} while ((nflags = sync_cmpxchg(&shared[ref].flags, flags, 0)) != flags);
+	} while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0)) != flags);
 
 	return 1;
 }
+
+int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+{
+	return gnttab_interface->end_foreign_access_ref(ref, readonly);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);
 
 void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
@@ -246,11 +308,11 @@ EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer);
 void gnttab_grant_foreign_transfer_ref(grant_ref_t ref, domid_t domid,
 				       unsigned long pfn)
 {
-	update_grant_entry(ref, domid, pfn, GTF_accept_transfer);
+	gnttab_interface->update_entry(ref, domid, pfn, GTF_accept_transfer);
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer_ref);
 
-unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 {
 	unsigned long frame;
 	u16           flags;
@@ -259,24 +321,29 @@ unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
 	 * If a transfer is not even yet started, try to reclaim the grant
 	 * reference and return failure (== 0).
 	 */
-	while (!((flags = shared[ref].flags) & GTF_transfer_committed)) {
-		if (sync_cmpxchg(&shared[ref].flags, flags, 0) == flags)
+	while (!((flags = gnttab_shared.v1[ref].flags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0) == flags)
 			return 0;
 		cpu_relax();
 	}
 
 	/* If a transfer is in progress then wait until it is completed. */
 	while (!(flags & GTF_transfer_completed)) {
-		flags = shared[ref].flags;
+		flags = gnttab_shared.v1[ref].flags;
 		cpu_relax();
 	}
 
 	rmb();	/* Read the frame number /after/ reading completion status. */
-	frame = shared[ref].frame;
+	frame = gnttab_shared.v1[ref].frame;
 	BUG_ON(frame == 0);
 
 	return frame;
 }
+
+unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+{
+	return gnttab_interface->end_foreign_transfer_ref(ref);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_transfer_ref);
 
 unsigned long gnttab_end_foreign_transfer(grant_ref_t ref)
@@ -520,6 +587,23 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
+{
+	int rc;
+
+	rc = arch_gnttab_map_shared(frames, nr_gframes,
+				    gnttab_max_grant_frames(),
+				    &gnttab_shared.addr);
+	BUG_ON(rc);
+
+	return 0;
+}
+
+static void gnttab_unmap_frames_v1(void)
+{
+	arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
@@ -567,19 +651,35 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 
 	BUG_ON(rc || setup.status);
 
-	rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
-				    &shared);
-	BUG_ON(rc);
+	rc = gnttab_interface->map_frames(frames, nr_gframes);
 
 	kfree(frames);
 
-	return 0;
+	return rc;
+}
+
+static struct gnttab_ops gnttab_v1_ops = {
+	.map_frames			= gnttab_map_frames_v1,
+	.unmap_frames			= gnttab_unmap_frames_v1,
+	.update_entry			= gnttab_update_entry_v1,
+	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v1,
+	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v1,
+	.query_foreign_access		= gnttab_query_foreign_access_v1,
+};
+
+static void gnttab_request_version(void)
+{
+	grant_table_version = 1;
+	gnttab_interface = &gnttab_v1_ops;
+	printk(KERN_INFO "Grant tables using version %d layout.\n",
+		grant_table_version);
 }
 
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
 
+	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
@@ -587,9 +687,10 @@ int gnttab_resume(void)
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-	if (!shared) {
-		shared = ioremap(xen_hvm_resume_frames, PAGE_SIZE * max_nr_gframes);
-		if (shared == NULL) {
+	if (gnttab_shared.addr == NULL) {
+		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
+						PAGE_SIZE * max_nr_gframes);
+		if (gnttab_shared.addr == NULL) {
 			printk(KERN_WARNING
 					"Failed to ioremap gnttab share frames!");
 			return -ENOMEM;
@@ -603,7 +704,7 @@ int gnttab_resume(void)
 
 int gnttab_suspend(void)
 {
-	arch_gnttab_unmap_shared(shared, nr_grant_frames);
+	gnttab_interface->unmap_frames();
 	return 0;
 }
 
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e2dfc..c7a40f8 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -145,8 +145,8 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
-			   struct grant_entry **__shared);
-void arch_gnttab_unmap_shared(struct grant_entry *shared,
+			   void **__shared);
+void arch_gnttab_unmap_shared(void *shared,
 			      unsigned long nr_gframes);
 
 extern unsigned long xen_hvm_resume_frames;
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index 39e5717..a17d844 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -85,12 +85,22 @@
  */
 
 /*
+ * Reference to a grant entry in a specified domain's grant table.
+ */
+typedef uint32_t grant_ref_t;
+
+/*
  * A grant table comprises a packed array of grant entries in one or more
  * page frames shared between Xen and a guest.
  * [XEN]: This field is written by Xen and read by the sharing guest.
  * [GST]: This field is written by the guest and read by Xen.
  */
-struct grant_entry {
+
+/*
+ * Version 1 of the grant table entry structure is maintained purely
+ * for backwards compatibility.  New guests should use version 2.
+ */
+struct grant_entry_v1 {
     /* GTF_xxx: various type and flag information.  [XEN,GST] */
     uint16_t flags;
     /* The domain being granted foreign privileges. [GST] */
@@ -108,10 +118,13 @@ struct grant_entry {
  *  GTF_permit_access: Allow @domid to map/access @frame.
  *  GTF_accept_transfer: Allow @domid to transfer ownership of one page frame
  *                       to this guest. Xen writes the page number to @frame.
+ *  GTF_transitive: Allow @domid to transitively access a subrange of
+ *                  @trans_grant in @trans_domid.  No mappings are allowed.
  */
 #define GTF_invalid         (0U<<0)
 #define GTF_permit_access   (1U<<0)
 #define GTF_accept_transfer (2U<<0)
+#define GTF_transitive      (3U<<0)
 #define GTF_type_mask       (3U<<0)
 
 /*
@@ -119,6 +132,9 @@ struct grant_entry {
  *  GTF_readonly: Restrict @domid to read-only mappings and accesses. [GST]
  *  GTF_reading: Grant entry is currently mapped for reading by @domid. [XEN]
  *  GTF_writing: Grant entry is currently mapped for writing by @domid. [XEN]
+ *  GTF_sub_page: Grant access to only a subrange of the page.  @domid
+ *                will only be allowed to copy from the grant, and not
+ *                map it. [GST]
  */
 #define _GTF_readonly       (2)
 #define GTF_readonly        (1U<<_GTF_readonly)
@@ -126,6 +142,8 @@ struct grant_entry {
 #define GTF_reading         (1U<<_GTF_reading)
 #define _GTF_writing        (4)
 #define GTF_writing         (1U<<_GTF_writing)
+#define _GTF_sub_page       (8)
+#define GTF_sub_page        (1U<<_GTF_sub_page)
 
 /*
  * Subflags for GTF_accept_transfer:
@@ -142,15 +160,81 @@ struct grant_entry {
 #define _GTF_transfer_completed (3)
 #define GTF_transfer_completed  (1U<<_GTF_transfer_completed)
 
+/*
+ * Version 2 grant table entries.  These fulfil the same role as
+ * version 1 entries, but can represent more complicated operations.
+ * Any given domain will have either a version 1 or a version 2 table,
+ * and every entry in the table will be the same version.
+ *
+ * The interface by which domains use grant references does not depend
+ * on the grant table version in use by the other domain.
+ */
 
-/***********************************
- * GRANT TABLE QUERIES AND USES
+/*
+ * Version 1 and version 2 grant entries share a common prefix.  The
+ * fields of the prefix are documented as part of struct
+ * grant_entry_v1.
  */
+struct grant_entry_header {
+    uint16_t flags;
+    domid_t  domid;
+};
 
 /*
- * Reference to a grant entry in a specified domain's grant table.
+ * Version 2 of the grant entry structure, here is an union because three
+ * different types are suppotted: full_page, sub_page and transitive.
+ */
+union grant_entry_v2 {
+    struct grant_entry_header hdr;
+
+    /*
+     * This member is used for V1-style full page grants, where either:
+     *
+     * -- hdr.type is GTF_accept_transfer, or
+     * -- hdr.type is GTF_permit_access and GTF_sub_page is not set.
+     *
+     * In that case, the frame field has the same semantics as the
+     * field of the same name in the V1 entry structure.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	uint32_t pad0;
+	uint64_t frame;
+    } full_page;
+
+    /*
+     * If the grant type is GTF_grant_access and GTF_sub_page is set,
+     * @domid is allowed to access bytes [@page_off,@page_off+@length)
+     * in frame @frame.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	uint16_t page_off;
+	uint16_t length;
+	uint64_t frame;
+    } sub_page;
+
+    /*
+     * If the grant is GTF_transitive, @domid is allowed to use the
+     * grant @gref in domain @trans_domid, as if it was the local
+     * domain.  Obviously, the transitive access must be compatible
+     * with the original grant.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	domid_t trans_domid;
+	uint16_t pad0;
+	grant_ref_t gref;
+    } transitive;
+
+    uint32_t __spacer[4]; /* Pad to a power of two */
+};
+
+typedef uint16_t grant_status_t;
+
+/***********************************
+ * GRANT TABLE QUERIES AND USES
  */
-typedef uint32_t grant_ref_t;
 
 /*
  * Handle to track a mapping created via a grant reference.
@@ -322,6 +406,79 @@ struct gnttab_query_size {
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
 
 /*
+ * GNTTABOP_unmap_and_replace: Destroy one or more grant-reference mappings
+ * tracked by <handle> but atomically replace the page table entry with one
+ * pointing to the machine address under <new_addr>.  <new_addr> will be
+ * redirected to the null entry.
+ * NOTES:
+ *  1. The call may fail in an undefined manner if either mapping is not
+ *     tracked by <handle>.
+ *  2. After executing a batch of unmaps, it is guaranteed that no stale
+ *     mappings will remain in the device or host TLBs.
+ */
+#define GNTTABOP_unmap_and_replace    7
+struct gnttab_unmap_and_replace {
+    /* IN parameters. */
+    uint64_t host_addr;
+    uint64_t new_addr;
+    grant_handle_t handle;
+    /* OUT parameters. */
+    int16_t  status;              /* GNTST_* */
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_unmap_and_replace);
+
+/*
+ * GNTTABOP_set_version: Request a particular version of the grant
+ * table shared table structure.  This operation can only be performed
+ * once in any given domain.  It must be performed before any grants
+ * are activated; otherwise, the domain will be stuck with version 1.
+ * The only defined versions are 1 and 2.
+ */
+#define GNTTABOP_set_version          8
+struct gnttab_set_version {
+    /* IN parameters */
+    uint32_t version;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_set_version);
+
+/*
+ * GNTTABOP_get_status_frames: Get the list of frames used to store grant
+ * status for <dom>. In grant format version 2, the status is separated
+ * from the other shared grant fields to allow more efficient synchronization
+ * using barriers instead of atomic cmpexch operations.
+ * <nr_frames> specify the size of vector <frame_list>.
+ * The frame addresses are returned in the <frame_list>.
+ * Only <nr_frames> addresses are returned, even if the table is larger.
+ * NOTES:
+ *  1. <dom> may be specified as DOMID_SELF.
+ *  2. Only a sufficiently-privileged domain may specify <dom> != DOMID_SELF.
+ */
+#define GNTTABOP_get_status_frames     9
+struct gnttab_get_status_frames {
+    /* IN parameters. */
+    uint32_t nr_frames;
+    domid_t  dom;
+    /* OUT parameters. */
+    int16_t  status;              /* GNTST_* */
+    GUEST_HANDLE(uint64_t) frame_list;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_status_frames);
+
+/*
+ * GNTTABOP_get_version: Get the grant table version which is in
+ * effect for domain <dom>.
+ */
+#define GNTTABOP_get_version          10
+struct gnttab_get_version {
+    /* IN parameters */
+    domid_t dom;
+    uint16_t pad;
+    /* OUT parameters */
+    uint32_t version;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_version);
+
+/*
  * Bitfield values for update_pin_status.flags.
  */
  /* Map the grant entry for access by I/O devices. */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..a890804 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -523,6 +523,8 @@ struct tmem_op {
 	} u;
 };
 
+DEFINE_GUEST_HANDLE(u64);
+
 #else /* __ASSEMBLY__ */
 
 /* In assembly code we cannot use C numeric constant suffixes. */
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 01:59:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 01:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSfdp-0001l7-TX; Tue, 22 Nov 2011 01:59:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSfdo-0001kn-A2
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 01:59:20 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1321927130!4047675!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15872 invoked from network); 22 Nov 2011 01:58:52 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 01:58:52 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAM1wl9U004910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 01:58:47 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAM1wjgw004222
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 01:58:45 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAM1wdLK019501; Mon, 21 Nov 2011 19:58:39 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 17:58:39 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 09:58:47 +0800
Message-Id: <1321927127-3958-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECA416D.90602@oracle.com>
References: <4ECA416D.90602@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4ECB01D8.0073,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2/4] xen/granttable: Refactor some code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 18355a5..0518d04 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -257,15 +257,17 @@ EXPORT_SYMBOL_GPL(gnttab_query_foreign_access);
 static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 {
 	u16 flags, nflags;
+	u16 *pflags;
 
-	nflags = gnttab_shared.v1[ref].flags;
+	pflags = &gnttab_shared.v1[ref].flags;
+	nflags = *pflags;
 	do {
 		flags = nflags;
 		if (flags & (GTF_reading|GTF_writing)) {
 			printk(KERN_ALERT "WARNING: g.e. still in use!\n");
 			return 0;
 		}
-	} while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0)) != flags);
+	} while ((nflags = sync_cmpxchg(pflags, flags, 0)) != flags);
 
 	return 1;
 }
@@ -316,20 +318,23 @@ static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 {
 	unsigned long frame;
 	u16           flags;
+	u16          *pflags;
+
+	pflags = &gnttab_shared.v1[ref].flags;
 
 	/*
 	 * If a transfer is not even yet started, try to reclaim the grant
 	 * reference and return failure (== 0).
 	 */
-	while (!((flags = gnttab_shared.v1[ref].flags) & GTF_transfer_committed)) {
-		if (sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0) == flags)
+	while (!((flags = *pflags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(pflags, flags, 0) == flags)
 			return 0;
 		cpu_relax();
 	}
 
 	/* If a transfer is in progress then wait until it is completed. */
 	while (!(flags & GTF_transfer_completed)) {
-		flags = gnttab_shared.v1[ref].flags;
+		flags = *pflags;
 		cpu_relax();
 	}
 
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 01:59:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 01:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSfdp-0001l7-TX; Tue, 22 Nov 2011 01:59:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSfdo-0001kn-A2
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 01:59:20 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1321927130!4047675!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15872 invoked from network); 22 Nov 2011 01:58:52 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 01:58:52 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAM1wl9U004910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 01:58:47 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAM1wjgw004222
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 01:58:45 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAM1wdLK019501; Mon, 21 Nov 2011 19:58:39 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 17:58:39 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 09:58:47 +0800
Message-Id: <1321927127-3958-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECA416D.90602@oracle.com>
References: <4ECA416D.90602@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4ECB01D8.0073,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2/4] xen/granttable: Refactor some code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 18355a5..0518d04 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -257,15 +257,17 @@ EXPORT_SYMBOL_GPL(gnttab_query_foreign_access);
 static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 {
 	u16 flags, nflags;
+	u16 *pflags;
 
-	nflags = gnttab_shared.v1[ref].flags;
+	pflags = &gnttab_shared.v1[ref].flags;
+	nflags = *pflags;
 	do {
 		flags = nflags;
 		if (flags & (GTF_reading|GTF_writing)) {
 			printk(KERN_ALERT "WARNING: g.e. still in use!\n");
 			return 0;
 		}
-	} while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0)) != flags);
+	} while ((nflags = sync_cmpxchg(pflags, flags, 0)) != flags);
 
 	return 1;
 }
@@ -316,20 +318,23 @@ static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 {
 	unsigned long frame;
 	u16           flags;
+	u16          *pflags;
+
+	pflags = &gnttab_shared.v1[ref].flags;
 
 	/*
 	 * If a transfer is not even yet started, try to reclaim the grant
 	 * reference and return failure (== 0).
 	 */
-	while (!((flags = gnttab_shared.v1[ref].flags) & GTF_transfer_committed)) {
-		if (sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0) == flags)
+	while (!((flags = *pflags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(pflags, flags, 0) == flags)
 			return 0;
 		cpu_relax();
 	}
 
 	/* If a transfer is in progress then wait until it is completed. */
 	while (!(flags & GTF_transfer_completed)) {
-		flags = gnttab_shared.v1[ref].flags;
+		flags = *pflags;
 		cpu_relax();
 	}
 
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 02:00:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 02:00:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSfeL-0001oY-IP; Tue, 22 Nov 2011 01:59:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSfeK-0001no-AT
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 01:59:52 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321927162!4047807!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16755 invoked from network); 22 Nov 2011 01:59:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 01:59:24 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAM1xJUn006735
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 01:59:20 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAM1xIaP004648
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 01:59:19 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAM1xD15024609; Mon, 21 Nov 2011 19:59:13 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 17:59:12 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 09:59:21 +0800
Message-Id: <1321927161-3987-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECA416D.90602@oracle.com>
References: <4ECA416D.90602@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4ECB01F8.0085,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 3/4] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Receiver-side copying of packets is based on this implementation, it gives
better performance and better CPU accounting. It totally supports three types:
full-page, sub-page and transitive grants.

However this patch does not cover sub-page and transitive grants, it mainly
focus on Full-page part and implements grant table V2 interfaces corresponding
to what already exists in grant table V1, such as: grant table V2
initialization, mapping, releasing and exported interfaces.

Each guest can only supports one type of grant table type, every entry in grant
table should be the same version. It is necessary to set V1 or V2 version before
initializing the grant table.

Grant table exported interfaces of V2 are same with those of V1, Xen is
responsible to judge what grant table version guests are using in every grant
operation.

V2 fulfills the same role of V1, and it is totally backwards compitable with V1.
If dom0 support grant table V2, the guests runing on it can run with either V1
or V2.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 arch/x86/xen/grant-table.c |   37 +++++++++-
 drivers/xen/grant-table.c  |  171 ++++++++++++++++++++++++++++++++++++++++++-
 include/xen/grant_table.h  |    6 +-
 3 files changed, 207 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index c6ab2e7..510fca0 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -54,6 +54,20 @@ static int map_pte_fn(pte_t *pte, struct page *pmd_page,
 	return 0;
 }
 
+/*
+ * This function is used to map shared frames to store grant status. It is
+ * different from map_pte_fn above, the frames type here is uint64_t.
+ */
+static int map_pte_fn_status(pte_t *pte, struct page *pmd_page,
+			     unsigned long addr, void *data)
+{
+	uint64_t **frames = (uint64_t **)data;
+
+	set_pte_at(&init_mm, addr, pte, mfn_pte((*frames)[0], PAGE_KERNEL));
+	(*frames)++;
+	return 0;
+}
+
 static int unmap_pte_fn(pte_t *pte, struct page *pmd_page,
 			unsigned long addr, void *data)
 {
@@ -83,7 +97,28 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 	return rc;
 }
 
-void arch_gnttab_unmap_shared(void *shared, unsigned long nr_gframes)
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared)
+{
+	int rc;
+	grant_status_t *shared = *__shared;
+
+	if (shared == NULL) {
+		struct vm_struct *area =
+			alloc_vm_area(PAGE_SIZE * max_nr_gframes);
+		BUG_ON(area == NULL);
+		shared = area->addr;
+		*__shared = shared;
+	}
+
+	rc = apply_to_page_range(&init_mm, (unsigned long)shared,
+				 PAGE_SIZE * nr_gframes,
+				 map_pte_fn_status, &frames);
+	return rc;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
 {
 	apply_to_page_range(&init_mm, (unsigned long)shared,
 			    PAGE_SIZE * nr_gframes, unmap_pte_fn, NULL);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0518d04..77a060c 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -44,6 +44,7 @@
 #include <xen/page.h>
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
+#include <xen/hvc-console.h>
 #include <asm/xen/hypercall.h>
 
 #include <asm/pgtable.h>
@@ -53,7 +54,10 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry_v1))
+#define GREFS_PER_GRANT_FRAME \
+(grant_table_version == 1 ?                      \
+ (PAGE_SIZE / sizeof(struct grant_entry_v1)) :   \
+ (PAGE_SIZE / sizeof(union grant_entry_v2)))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -66,6 +70,7 @@ EXPORT_SYMBOL_GPL(xen_hvm_resume_frames);
 
 static union {
 	struct grant_entry_v1 *v1;
+	union grant_entry_v2 *v2;
 	void *addr;
 } gnttab_shared;
 
@@ -120,6 +125,9 @@ struct gnttab_ops {
 
 static struct gnttab_ops *gnttab_interface;
 
+/*This reflects status of grant entries, so act as a global value*/
+static grant_status_t *grstatus;
+
 static int grant_table_version;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
@@ -127,6 +135,7 @@ static struct gnttab_free_callback *gnttab_free_callback_list;
 static int gnttab_expand(unsigned int req_entries);
 
 #define RPP (PAGE_SIZE / sizeof(grant_ref_t))
+#define SPP (PAGE_SIZE / sizeof(grant_status_t))
 
 static inline grant_ref_t *__gnttab_entry(grant_ref_t entry)
 {
@@ -199,6 +208,7 @@ static void put_free_entry(grant_ref_t ref)
 }
 
 /*
+ * Following applies to gnttab_update_entry_v1 and gnttab_update_entry_v2.
  * Introducing a valid entry into the grant table:
  *  1. Write ent->domid.
  *  2. Write ent->frame:
@@ -217,6 +227,15 @@ static void gnttab_update_entry_v1(grant_ref_t ref, domid_t domid,
 	gnttab_shared.v1[ref].flags = flags;
 }
 
+static void gnttab_update_entry_v2(grant_ref_t ref, domid_t domid,
+				   unsigned long frame, unsigned flags)
+{
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	gnttab_shared.v2[ref].full_page.frame = frame;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags = GTF_permit_access | flags;
+}
+
 /*
  * Public grant-issuing interface functions
  */
@@ -248,6 +267,11 @@ static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
 }
 
+static int gnttab_query_foreign_access_v2(grant_ref_t ref)
+{
+	return grstatus[ref] & (GTF_reading|GTF_writing);
+}
+
 int gnttab_query_foreign_access(grant_ref_t ref)
 {
 	return gnttab_interface->query_foreign_access(ref);
@@ -272,6 +296,29 @@ static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 	return 1;
 }
 
+static int gnttab_end_foreign_access_ref_v2(grant_ref_t ref, int readonly)
+{
+	gnttab_shared.v2[ref].hdr.flags = 0;
+	mb();
+	if (grstatus[ref] & (GTF_reading|GTF_writing)) {
+		return 0;
+	} else {
+		/* The read of grstatus needs to have acquire
+		semantics.  On x86, reads already have
+		that, and we just need to protect against
+		compiler reorderings.  On other
+		architectures we may need a full
+		barrier. */
+#ifdef CONFIG_X86
+		barrier();
+#else
+		mb();
+#endif
+		}
+
+	return 1;
+}
+
 int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
 {
 	return gnttab_interface->end_foreign_access_ref(ref, readonly);
@@ -345,6 +392,37 @@ static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 	return frame;
 }
 
+static unsigned long gnttab_end_foreign_transfer_ref_v2(grant_ref_t ref)
+{
+	unsigned long frame;
+	u16           flags;
+	u16          *pflags;
+
+	pflags = &gnttab_shared.v2[ref].hdr.flags;
+
+	/*
+	 * If a transfer is not even yet started, try to reclaim the grant
+	 * reference and return failure (== 0).
+	 */
+	while (!((flags = *pflags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(pflags, flags, 0) == flags)
+			return 0;
+		cpu_relax();
+	}
+
+	/* If a transfer is in progress then wait until it is completed. */
+	while (!(flags & GTF_transfer_completed)) {
+		flags = *pflags;
+		cpu_relax();
+	}
+
+	rmb();  /* Read the frame number /after/ reading completion status. */
+	frame = gnttab_shared.v2[ref].full_page.frame;
+	BUG_ON(frame == 0);
+
+	return frame;
+}
+
 unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
 {
 	return gnttab_interface->end_foreign_transfer_ref(ref);
@@ -592,6 +670,11 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static unsigned nr_status_frames(unsigned nr_grant_frames)
+{
+	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
+}
+
 static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 {
 	int rc;
@@ -606,7 +689,56 @@ static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 
 static void gnttab_unmap_frames_v1(void)
 {
-	arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+}
+
+static int gnttab_map_frames_v2(unsigned long *frames, unsigned int nr_gframes)
+{
+	uint64_t *sframes;
+	unsigned int nr_sframes;
+	struct gnttab_get_status_frames getframes;
+	int rc;
+
+	nr_sframes = nr_status_frames(nr_gframes);
+
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_get_status_frames.
+	 */
+	sframes = kmalloc(nr_sframes  * sizeof(uint64_t), GFP_ATOMIC);
+	if (!sframes)
+		return -ENOMEM;
+
+	getframes.dom        = DOMID_SELF;
+	getframes.nr_frames  = nr_sframes;
+	set_xen_guest_handle(getframes.frame_list, sframes);
+
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_get_status_frames,
+				       &getframes, 1);
+	if (rc == -ENOSYS) {
+		kfree(sframes);
+		return -ENOSYS;
+	}
+
+	BUG_ON(rc || getframes.status);
+
+	rc = arch_gnttab_map_status(sframes, nr_sframes,
+				    nr_status_frames(gnttab_max_grant_frames()),
+				    &grstatus);
+	BUG_ON(rc);
+	kfree(sframes);
+
+	rc = arch_gnttab_map_shared(frames, nr_gframes,
+				    gnttab_max_grant_frames(),
+				    &gnttab_shared.addr);
+	BUG_ON(rc);
+
+	return 0;
+}
+
+static void gnttab_unmap_frames_v2(void)
+{
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(grstatus, nr_status_frames(nr_grant_frames));
 }
 
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
@@ -640,6 +772,9 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		return rc;
 	}
 
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_setup_table.
+	 */
 	frames = kmalloc(nr_gframes * sizeof(unsigned long), GFP_ATOMIC);
 	if (!frames)
 		return -ENOMEM;
@@ -672,10 +807,38 @@ static struct gnttab_ops gnttab_v1_ops = {
 	.query_foreign_access		= gnttab_query_foreign_access_v1,
 };
 
+static struct gnttab_ops gnttab_v2_ops = {
+	.map_frames			= gnttab_map_frames_v2,
+	.unmap_frames			= gnttab_unmap_frames_v2,
+	.update_entry			= gnttab_update_entry_v2,
+	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
+	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
+	.query_foreign_access		= gnttab_query_foreign_access_v2,
+};
+
 static void gnttab_request_version(void)
 {
-	grant_table_version = 1;
-	gnttab_interface = &gnttab_v1_ops;
+	int rc;
+	struct gnttab_set_version gsv;
+
+	gsv.version = 2;
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
+	if (rc == 0) {
+		grant_table_version = 2;
+		gnttab_interface = &gnttab_v2_ops;
+	} else if (grant_table_version == 2) {
+		/*
+		 * If we've already used version 2 features,
+		 * but then suddenly discover that they're not
+		 * available (e.g. migrating to an older
+		 * version of Xen), almost unbounded badness
+		 * can happen.
+		 */
+		panic("we need grant tables version 2, but only version 1 is available");
+	} else {
+		grant_table_version = 1;
+		gnttab_interface = &gnttab_v1_ops;
+	}
 	printk(KERN_INFO "Grant tables using version %d layout.\n",
 		grant_table_version);
 }
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index c7a40f8..5494c40 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -146,8 +146,10 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
 			   void **__shared);
-void arch_gnttab_unmap_shared(void *shared,
-			      unsigned long nr_gframes);
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared);
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes);
 
 extern unsigned long xen_hvm_resume_frames;
 unsigned int gnttab_max_grant_frames(void);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 02:00:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 02:00:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSfeL-0001oY-IP; Tue, 22 Nov 2011 01:59:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSfeK-0001no-AT
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 01:59:52 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1321927162!4047807!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16755 invoked from network); 22 Nov 2011 01:59:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 01:59:24 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAM1xJUn006735
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 01:59:20 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAM1xIaP004648
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 01:59:19 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAM1xD15024609; Mon, 21 Nov 2011 19:59:13 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 17:59:12 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 09:59:21 +0800
Message-Id: <1321927161-3987-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECA416D.90602@oracle.com>
References: <4ECA416D.90602@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4ECB01F8.0085,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 3/4] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Receiver-side copying of packets is based on this implementation, it gives
better performance and better CPU accounting. It totally supports three types:
full-page, sub-page and transitive grants.

However this patch does not cover sub-page and transitive grants, it mainly
focus on Full-page part and implements grant table V2 interfaces corresponding
to what already exists in grant table V1, such as: grant table V2
initialization, mapping, releasing and exported interfaces.

Each guest can only supports one type of grant table type, every entry in grant
table should be the same version. It is necessary to set V1 or V2 version before
initializing the grant table.

Grant table exported interfaces of V2 are same with those of V1, Xen is
responsible to judge what grant table version guests are using in every grant
operation.

V2 fulfills the same role of V1, and it is totally backwards compitable with V1.
If dom0 support grant table V2, the guests runing on it can run with either V1
or V2.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 arch/x86/xen/grant-table.c |   37 +++++++++-
 drivers/xen/grant-table.c  |  171 ++++++++++++++++++++++++++++++++++++++++++-
 include/xen/grant_table.h  |    6 +-
 3 files changed, 207 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index c6ab2e7..510fca0 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -54,6 +54,20 @@ static int map_pte_fn(pte_t *pte, struct page *pmd_page,
 	return 0;
 }
 
+/*
+ * This function is used to map shared frames to store grant status. It is
+ * different from map_pte_fn above, the frames type here is uint64_t.
+ */
+static int map_pte_fn_status(pte_t *pte, struct page *pmd_page,
+			     unsigned long addr, void *data)
+{
+	uint64_t **frames = (uint64_t **)data;
+
+	set_pte_at(&init_mm, addr, pte, mfn_pte((*frames)[0], PAGE_KERNEL));
+	(*frames)++;
+	return 0;
+}
+
 static int unmap_pte_fn(pte_t *pte, struct page *pmd_page,
 			unsigned long addr, void *data)
 {
@@ -83,7 +97,28 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 	return rc;
 }
 
-void arch_gnttab_unmap_shared(void *shared, unsigned long nr_gframes)
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared)
+{
+	int rc;
+	grant_status_t *shared = *__shared;
+
+	if (shared == NULL) {
+		struct vm_struct *area =
+			alloc_vm_area(PAGE_SIZE * max_nr_gframes);
+		BUG_ON(area == NULL);
+		shared = area->addr;
+		*__shared = shared;
+	}
+
+	rc = apply_to_page_range(&init_mm, (unsigned long)shared,
+				 PAGE_SIZE * nr_gframes,
+				 map_pte_fn_status, &frames);
+	return rc;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
 {
 	apply_to_page_range(&init_mm, (unsigned long)shared,
 			    PAGE_SIZE * nr_gframes, unmap_pte_fn, NULL);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0518d04..77a060c 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -44,6 +44,7 @@
 #include <xen/page.h>
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
+#include <xen/hvc-console.h>
 #include <asm/xen/hypercall.h>
 
 #include <asm/pgtable.h>
@@ -53,7 +54,10 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry_v1))
+#define GREFS_PER_GRANT_FRAME \
+(grant_table_version == 1 ?                      \
+ (PAGE_SIZE / sizeof(struct grant_entry_v1)) :   \
+ (PAGE_SIZE / sizeof(union grant_entry_v2)))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -66,6 +70,7 @@ EXPORT_SYMBOL_GPL(xen_hvm_resume_frames);
 
 static union {
 	struct grant_entry_v1 *v1;
+	union grant_entry_v2 *v2;
 	void *addr;
 } gnttab_shared;
 
@@ -120,6 +125,9 @@ struct gnttab_ops {
 
 static struct gnttab_ops *gnttab_interface;
 
+/*This reflects status of grant entries, so act as a global value*/
+static grant_status_t *grstatus;
+
 static int grant_table_version;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
@@ -127,6 +135,7 @@ static struct gnttab_free_callback *gnttab_free_callback_list;
 static int gnttab_expand(unsigned int req_entries);
 
 #define RPP (PAGE_SIZE / sizeof(grant_ref_t))
+#define SPP (PAGE_SIZE / sizeof(grant_status_t))
 
 static inline grant_ref_t *__gnttab_entry(grant_ref_t entry)
 {
@@ -199,6 +208,7 @@ static void put_free_entry(grant_ref_t ref)
 }
 
 /*
+ * Following applies to gnttab_update_entry_v1 and gnttab_update_entry_v2.
  * Introducing a valid entry into the grant table:
  *  1. Write ent->domid.
  *  2. Write ent->frame:
@@ -217,6 +227,15 @@ static void gnttab_update_entry_v1(grant_ref_t ref, domid_t domid,
 	gnttab_shared.v1[ref].flags = flags;
 }
 
+static void gnttab_update_entry_v2(grant_ref_t ref, domid_t domid,
+				   unsigned long frame, unsigned flags)
+{
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	gnttab_shared.v2[ref].full_page.frame = frame;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags = GTF_permit_access | flags;
+}
+
 /*
  * Public grant-issuing interface functions
  */
@@ -248,6 +267,11 @@ static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
 }
 
+static int gnttab_query_foreign_access_v2(grant_ref_t ref)
+{
+	return grstatus[ref] & (GTF_reading|GTF_writing);
+}
+
 int gnttab_query_foreign_access(grant_ref_t ref)
 {
 	return gnttab_interface->query_foreign_access(ref);
@@ -272,6 +296,29 @@ static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 	return 1;
 }
 
+static int gnttab_end_foreign_access_ref_v2(grant_ref_t ref, int readonly)
+{
+	gnttab_shared.v2[ref].hdr.flags = 0;
+	mb();
+	if (grstatus[ref] & (GTF_reading|GTF_writing)) {
+		return 0;
+	} else {
+		/* The read of grstatus needs to have acquire
+		semantics.  On x86, reads already have
+		that, and we just need to protect against
+		compiler reorderings.  On other
+		architectures we may need a full
+		barrier. */
+#ifdef CONFIG_X86
+		barrier();
+#else
+		mb();
+#endif
+		}
+
+	return 1;
+}
+
 int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
 {
 	return gnttab_interface->end_foreign_access_ref(ref, readonly);
@@ -345,6 +392,37 @@ static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 	return frame;
 }
 
+static unsigned long gnttab_end_foreign_transfer_ref_v2(grant_ref_t ref)
+{
+	unsigned long frame;
+	u16           flags;
+	u16          *pflags;
+
+	pflags = &gnttab_shared.v2[ref].hdr.flags;
+
+	/*
+	 * If a transfer is not even yet started, try to reclaim the grant
+	 * reference and return failure (== 0).
+	 */
+	while (!((flags = *pflags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(pflags, flags, 0) == flags)
+			return 0;
+		cpu_relax();
+	}
+
+	/* If a transfer is in progress then wait until it is completed. */
+	while (!(flags & GTF_transfer_completed)) {
+		flags = *pflags;
+		cpu_relax();
+	}
+
+	rmb();  /* Read the frame number /after/ reading completion status. */
+	frame = gnttab_shared.v2[ref].full_page.frame;
+	BUG_ON(frame == 0);
+
+	return frame;
+}
+
 unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
 {
 	return gnttab_interface->end_foreign_transfer_ref(ref);
@@ -592,6 +670,11 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static unsigned nr_status_frames(unsigned nr_grant_frames)
+{
+	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
+}
+
 static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 {
 	int rc;
@@ -606,7 +689,56 @@ static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 
 static void gnttab_unmap_frames_v1(void)
 {
-	arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+}
+
+static int gnttab_map_frames_v2(unsigned long *frames, unsigned int nr_gframes)
+{
+	uint64_t *sframes;
+	unsigned int nr_sframes;
+	struct gnttab_get_status_frames getframes;
+	int rc;
+
+	nr_sframes = nr_status_frames(nr_gframes);
+
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_get_status_frames.
+	 */
+	sframes = kmalloc(nr_sframes  * sizeof(uint64_t), GFP_ATOMIC);
+	if (!sframes)
+		return -ENOMEM;
+
+	getframes.dom        = DOMID_SELF;
+	getframes.nr_frames  = nr_sframes;
+	set_xen_guest_handle(getframes.frame_list, sframes);
+
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_get_status_frames,
+				       &getframes, 1);
+	if (rc == -ENOSYS) {
+		kfree(sframes);
+		return -ENOSYS;
+	}
+
+	BUG_ON(rc || getframes.status);
+
+	rc = arch_gnttab_map_status(sframes, nr_sframes,
+				    nr_status_frames(gnttab_max_grant_frames()),
+				    &grstatus);
+	BUG_ON(rc);
+	kfree(sframes);
+
+	rc = arch_gnttab_map_shared(frames, nr_gframes,
+				    gnttab_max_grant_frames(),
+				    &gnttab_shared.addr);
+	BUG_ON(rc);
+
+	return 0;
+}
+
+static void gnttab_unmap_frames_v2(void)
+{
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(grstatus, nr_status_frames(nr_grant_frames));
 }
 
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
@@ -640,6 +772,9 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		return rc;
 	}
 
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_setup_table.
+	 */
 	frames = kmalloc(nr_gframes * sizeof(unsigned long), GFP_ATOMIC);
 	if (!frames)
 		return -ENOMEM;
@@ -672,10 +807,38 @@ static struct gnttab_ops gnttab_v1_ops = {
 	.query_foreign_access		= gnttab_query_foreign_access_v1,
 };
 
+static struct gnttab_ops gnttab_v2_ops = {
+	.map_frames			= gnttab_map_frames_v2,
+	.unmap_frames			= gnttab_unmap_frames_v2,
+	.update_entry			= gnttab_update_entry_v2,
+	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
+	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
+	.query_foreign_access		= gnttab_query_foreign_access_v2,
+};
+
 static void gnttab_request_version(void)
 {
-	grant_table_version = 1;
-	gnttab_interface = &gnttab_v1_ops;
+	int rc;
+	struct gnttab_set_version gsv;
+
+	gsv.version = 2;
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
+	if (rc == 0) {
+		grant_table_version = 2;
+		gnttab_interface = &gnttab_v2_ops;
+	} else if (grant_table_version == 2) {
+		/*
+		 * If we've already used version 2 features,
+		 * but then suddenly discover that they're not
+		 * available (e.g. migrating to an older
+		 * version of Xen), almost unbounded badness
+		 * can happen.
+		 */
+		panic("we need grant tables version 2, but only version 1 is available");
+	} else {
+		grant_table_version = 1;
+		gnttab_interface = &gnttab_v1_ops;
+	}
 	printk(KERN_INFO "Grant tables using version %d layout.\n",
 		grant_table_version);
 }
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index c7a40f8..5494c40 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -146,8 +146,10 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
 			   void **__shared);
-void arch_gnttab_unmap_shared(void *shared,
-			      unsigned long nr_gframes);
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared);
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes);
 
 extern unsigned long xen_hvm_resume_frames;
 unsigned int gnttab_max_grant_frames(void);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 02:00:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 02:00:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSfew-0001xK-3O; Tue, 22 Nov 2011 02:00:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSfeu-0001wR-2u
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 02:00:28 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321927158!64096965!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3211 invoked from network); 22 Nov 2011 01:59:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 01:59:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAM1xtJP005894
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 01:59:56 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAM1xsRx020523
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 01:59:55 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAM1xnW8016445; Mon, 21 Nov 2011 19:59:49 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 17:59:48 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 09:59:56 +0800
Message-Id: <1321927196-4022-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECA416D.90602@oracle.com>
References: <4ECA416D.90602@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4ECB021C.0068,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 4/4] xen/granttable: Keep code format clean
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |    7 +++----
 include/xen/grant_table.h |    2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 77a060c..b76f419 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -50,7 +50,6 @@
 #include <asm/pgtable.h>
 #include <asm/sync_bitops.h>
 
-
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
@@ -598,8 +597,8 @@ unsigned int gnttab_max_grant_frames(void)
 EXPORT_SYMBOL_GPL(gnttab_max_grant_frames);
 
 int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
-			struct gnttab_map_grant_ref *kmap_ops,
-			struct page **pages, unsigned int count)
+		    struct gnttab_map_grant_ref *kmap_ops,
+		    struct page **pages, unsigned int count)
 {
 	int i, ret;
 	pte_t *pte;
@@ -649,7 +648,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		struct page **pages, unsigned int count)
+		      struct page **pages, unsigned int count)
 {
 	int i, ret;
 
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 5494c40..fea4954 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -157,7 +157,7 @@ unsigned int gnttab_max_grant_frames(void);
 #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr))
 
 int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
-			struct gnttab_map_grant_ref *kmap_ops,
+		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		      struct page **pages, unsigned int count);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 02:00:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 02:00:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSfew-0001xK-3O; Tue, 22 Nov 2011 02:00:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSfeu-0001wR-2u
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 02:00:28 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321927158!64096965!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3211 invoked from network); 22 Nov 2011 01:59:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 01:59:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAM1xtJP005894
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 01:59:56 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAM1xsRx020523
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 01:59:55 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAM1xnW8016445; Mon, 21 Nov 2011 19:59:49 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 17:59:48 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 09:59:56 +0800
Message-Id: <1321927196-4022-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECA416D.90602@oracle.com>
References: <4ECA416D.90602@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4ECB021C.0068,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 4/4] xen/granttable: Keep code format clean
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |    7 +++----
 include/xen/grant_table.h |    2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 77a060c..b76f419 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -50,7 +50,6 @@
 #include <asm/pgtable.h>
 #include <asm/sync_bitops.h>
 
-
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
@@ -598,8 +597,8 @@ unsigned int gnttab_max_grant_frames(void)
 EXPORT_SYMBOL_GPL(gnttab_max_grant_frames);
 
 int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
-			struct gnttab_map_grant_ref *kmap_ops,
-			struct page **pages, unsigned int count)
+		    struct gnttab_map_grant_ref *kmap_ops,
+		    struct page **pages, unsigned int count)
 {
 	int i, ret;
 	pte_t *pte;
@@ -649,7 +648,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		struct page **pages, unsigned int count)
+		      struct page **pages, unsigned int count)
 {
 	int i, ret;
 
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 5494c40..fea4954 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -157,7 +157,7 @@ unsigned int gnttab_max_grant_frames(void);
 #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr))
 
 int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
-			struct gnttab_map_grant_ref *kmap_ops,
+		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		      struct page **pages, unsigned int count);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 02:06:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 02:06:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSfkD-0002bj-1I; Tue, 22 Nov 2011 02:05:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>)
	id 1RSfkB-0002bC-Kj; Tue, 22 Nov 2011 02:05:55 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1321927526!4455641!1
X-Originating-IP: [216.33.127.80]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31870 invoked from network); 22 Nov 2011 02:05:27 -0000
Received: from mta11.charter.net (HELO mta11.charter.net) (216.33.127.80)
	by server-9.tower-216.messagelabs.com with SMTP;
	22 Nov 2011 02:05:27 -0000
Received: from imp11 ([10.20.200.11]) by mta11.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111122020525.MKVD4019.mta11.charter.net@imp11>;
	Mon, 21 Nov 2011 21:05:25 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp11 with smtp.charter.net
	id 025R1i00A46xN4z0525RKw; Mon, 21 Nov 2011 21:05:25 -0500
X-Authority-Analysis: v=1.1 cv=3kn4snR/2TdwuYXvh+wm0CPnSGzQFWY7ukd303aPFv0=
	c=1 sm=1 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10 a=YBs1tj9y_9UA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=SEF7xSSsAAAA:8 a=CLmBUu0YAAAA:8
	a=E30Xxlqe7tXLmJksZFAA:9 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8
	a=SSmOFEACAAAA:8
	a=oQYKKuTH0n69eIl8ERoA:9 a=aCheMCz5NNoXwfhrANoA:7 a=gKO2Hq4RSVkA:10
	a=hTZeC7Yk6K0A:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id E48C8203CF;
	Tue, 22 Nov 2011 02:05:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id fLfyb5cBmpeQ; Mon, 21 Nov 2011 21:05:19 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id 37C0B20394;
	Mon, 21 Nov 2011 21:05:19 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <rshriram@cs.ubc.ca>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
In-Reply-To: <CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
Date: Mon, 21 Nov 2011 21:04:51 -0500
Message-ID: <000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHz9rrfjVKWk68JYGli49Qz4ZFl0gJhPW6SlVZprIA=
Content-Language: en-us
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3190548398993086071=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multipart message in MIME format.

--===============3190548398993086071==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0004_01CCA891.35E9A290"
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0004_01CCA891.35E9A290
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

From: Shriram Rajagopalan [mailto:rshriram@cs.ubc.ca] 
Sent: Monday, November 21, 2011 12:03 AM
To: Michael A. Collins
Cc: xen-devel@lists.xensource.com; xen-users@lists.xensource.com
Subject: Re: [Xen-devel] BLKTAP

 

.


drbd/remus - why  do you need blktap ?

shriram

 

>From my readings, I have found only a few examples of using remus.  Most of
them refer to using the following stanza in the disk section of a VM's cfg
file:

tap2:remus:backuphost:anyfreeport|

 

That doesn't work for xl, but even using it with xm causes issues, since
there isn't a tap device without the kernel module.  So I also found out
that drbd uses a tap device to handle the hook in with Xen, so if you want
to have automagic working with block-drbd xen scripts then you have to use
tap.  With all that said and done, I'm currently running drbd 8.3.11 since
that's the version of the kernel module included with Linux 3.1, but I'm
just using Xen's phy handler for the disk section of my VM's cfg file.

 

I see that there is a nice howto for debian on remusha.wikidot.com, but
again it uses a 2.6.32 kernel from Jeremy's git repo, which has the tap
kernel module.  I again assert that currently there is very little out there
that would help to get someone started using remus with drbd in the linux
3.1.x world.  I run remus at work, but it's using shared storage and have no
need to use it with drbd, but at home I don't really want to set that up, so
I thought drbd would be a nice start.

 

I've started diffing the 8.3.9 branch of drbd with your changes for remus
and will see how hard it is to get that in the 8.3.11 version I'm using. 

 

With that being said, I mostly use xl for everything at home, I don't even
have the xend service running, which makes matters worse, since I'm sure
that most of remus uses the xend service and not the API to do the magic.  I
am willing to document my steps and post to the wiki, so that others could
benefit from it!

Mike


------=_NextPart_000_0004_01CCA891.35E9A290
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
Shriram Rajagopalan <a =
href=3D"mailto:[mailto:rshriram@cs.ubc.ca]">[mailto:rshriram@cs.ubc.ca]</=
a> <br><b>Sent:</b> Monday, November 21, 2011 12:03 AM<br><b>To:</b> =
Michael A. Collins<br><b>Cc:</b> <a =
href=3D"mailto:xen-devel@lists.xensource.com">xen-devel@lists.xensource.c=
om</a>; <a =
href=3D"mailto:xen-users@lists.xensource.com">xen-users@lists.xensource.c=
om</a><br><b>Subject:</b> Re: [Xen-devel] BLKTAP<o:p></o:p></span></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><div><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'>&#8230;<o:p></o:p></span></p><p =
class=3DMsoNormal><br>drbd/remus - why&nbsp; do you need blktap =
?<br><br>shriram<span style=3D'color:#1F497D'><o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>From my readings, I have found only a few examples of using =
remus.&nbsp; Most of them refer to using the following stanza in the =
disk section of a VM&#8217;s cfg file:<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>tap2:remus:backuphost:anyfreeport|<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>That doesn&#8217;t work for xl, but even using it with xm causes =
issues, since there isn&#8217;t a tap device without the kernel =
module.&nbsp; So I also found out that drbd uses a tap device to handle =
the hook in with Xen, so if you want to have automagic working with =
block-drbd xen scripts then you have to use tap.&nbsp; With all that =
said and done, I&#8217;m currently running drbd 8.3.11 since =
that&#8217;s the version of the kernel module included with Linux 3.1, =
but I&#8217;m just using Xen&#8217;s phy handler for the disk section of =
my VM&#8217;s cfg file.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>I see that there is a nice howto for debian on remusha.wikidot.com, =
but again it uses a 2.6.32 kernel from Jeremy&#8217;s git repo, which =
has the tap kernel module.&nbsp; I again assert that currently there is =
very little out there that would help to get someone started using remus =
with drbd in the linux 3.1.x world.&nbsp; I run remus at work, but =
it&#8217;s using shared storage and have no need to use it with drbd, =
but at home I don&#8217;t really want to set that up, so I thought drbd =
would be a nice start.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>I&#8217;ve started diffing the 8.3.9 branch of drbd with your changes =
for remus and will see how hard it is to get that in the 8.3.11 version =
I&#8217;m using. <o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>With that being said, I mostly use xl for everything at home, I =
don&#8217;t even have the xend service running, which makes matters =
worse, since I&#8217;m sure that most of remus uses the xend service and =
not the API to do the magic.&nbsp; I am willing to document my steps and =
post to the wiki, so that others could benefit from =
it!<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Mike<o:p></o:p></span></p></div></div></div></body></html>
------=_NextPart_000_0004_01CCA891.35E9A290--



--===============3190548398993086071==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3190548398993086071==--



From xen-devel-bounces@lists.xensource.com Tue Nov 22 02:06:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 02:06:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSfkD-0002bj-1I; Tue, 22 Nov 2011 02:05:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>)
	id 1RSfkB-0002bC-Kj; Tue, 22 Nov 2011 02:05:55 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1321927526!4455641!1
X-Originating-IP: [216.33.127.80]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31870 invoked from network); 22 Nov 2011 02:05:27 -0000
Received: from mta11.charter.net (HELO mta11.charter.net) (216.33.127.80)
	by server-9.tower-216.messagelabs.com with SMTP;
	22 Nov 2011 02:05:27 -0000
Received: from imp11 ([10.20.200.11]) by mta11.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111122020525.MKVD4019.mta11.charter.net@imp11>;
	Mon, 21 Nov 2011 21:05:25 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp11 with smtp.charter.net
	id 025R1i00A46xN4z0525RKw; Mon, 21 Nov 2011 21:05:25 -0500
X-Authority-Analysis: v=1.1 cv=3kn4snR/2TdwuYXvh+wm0CPnSGzQFWY7ukd303aPFv0=
	c=1 sm=1 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10 a=YBs1tj9y_9UA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=SEF7xSSsAAAA:8 a=CLmBUu0YAAAA:8
	a=E30Xxlqe7tXLmJksZFAA:9 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8
	a=SSmOFEACAAAA:8
	a=oQYKKuTH0n69eIl8ERoA:9 a=aCheMCz5NNoXwfhrANoA:7 a=gKO2Hq4RSVkA:10
	a=hTZeC7Yk6K0A:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id E48C8203CF;
	Tue, 22 Nov 2011 02:05:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id fLfyb5cBmpeQ; Mon, 21 Nov 2011 21:05:19 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id 37C0B20394;
	Mon, 21 Nov 2011 21:05:19 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <rshriram@cs.ubc.ca>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
In-Reply-To: <CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
Date: Mon, 21 Nov 2011 21:04:51 -0500
Message-ID: <000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHz9rrfjVKWk68JYGli49Qz4ZFl0gJhPW6SlVZprIA=
Content-Language: en-us
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3190548398993086071=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multipart message in MIME format.

--===============3190548398993086071==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0004_01CCA891.35E9A290"
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0004_01CCA891.35E9A290
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

From: Shriram Rajagopalan [mailto:rshriram@cs.ubc.ca] 
Sent: Monday, November 21, 2011 12:03 AM
To: Michael A. Collins
Cc: xen-devel@lists.xensource.com; xen-users@lists.xensource.com
Subject: Re: [Xen-devel] BLKTAP

 

.


drbd/remus - why  do you need blktap ?

shriram

 

>From my readings, I have found only a few examples of using remus.  Most of
them refer to using the following stanza in the disk section of a VM's cfg
file:

tap2:remus:backuphost:anyfreeport|

 

That doesn't work for xl, but even using it with xm causes issues, since
there isn't a tap device without the kernel module.  So I also found out
that drbd uses a tap device to handle the hook in with Xen, so if you want
to have automagic working with block-drbd xen scripts then you have to use
tap.  With all that said and done, I'm currently running drbd 8.3.11 since
that's the version of the kernel module included with Linux 3.1, but I'm
just using Xen's phy handler for the disk section of my VM's cfg file.

 

I see that there is a nice howto for debian on remusha.wikidot.com, but
again it uses a 2.6.32 kernel from Jeremy's git repo, which has the tap
kernel module.  I again assert that currently there is very little out there
that would help to get someone started using remus with drbd in the linux
3.1.x world.  I run remus at work, but it's using shared storage and have no
need to use it with drbd, but at home I don't really want to set that up, so
I thought drbd would be a nice start.

 

I've started diffing the 8.3.9 branch of drbd with your changes for remus
and will see how hard it is to get that in the 8.3.11 version I'm using. 

 

With that being said, I mostly use xl for everything at home, I don't even
have the xend service running, which makes matters worse, since I'm sure
that most of remus uses the xend service and not the API to do the magic.  I
am willing to document my steps and post to the wiki, so that others could
benefit from it!

Mike


------=_NextPart_000_0004_01CCA891.35E9A290
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
Shriram Rajagopalan <a =
href=3D"mailto:[mailto:rshriram@cs.ubc.ca]">[mailto:rshriram@cs.ubc.ca]</=
a> <br><b>Sent:</b> Monday, November 21, 2011 12:03 AM<br><b>To:</b> =
Michael A. Collins<br><b>Cc:</b> <a =
href=3D"mailto:xen-devel@lists.xensource.com">xen-devel@lists.xensource.c=
om</a>; <a =
href=3D"mailto:xen-users@lists.xensource.com">xen-users@lists.xensource.c=
om</a><br><b>Subject:</b> Re: [Xen-devel] BLKTAP<o:p></o:p></span></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><div><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'>&#8230;<o:p></o:p></span></p><p =
class=3DMsoNormal><br>drbd/remus - why&nbsp; do you need blktap =
?<br><br>shriram<span style=3D'color:#1F497D'><o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>From my readings, I have found only a few examples of using =
remus.&nbsp; Most of them refer to using the following stanza in the =
disk section of a VM&#8217;s cfg file:<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>tap2:remus:backuphost:anyfreeport|<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>That doesn&#8217;t work for xl, but even using it with xm causes =
issues, since there isn&#8217;t a tap device without the kernel =
module.&nbsp; So I also found out that drbd uses a tap device to handle =
the hook in with Xen, so if you want to have automagic working with =
block-drbd xen scripts then you have to use tap.&nbsp; With all that =
said and done, I&#8217;m currently running drbd 8.3.11 since =
that&#8217;s the version of the kernel module included with Linux 3.1, =
but I&#8217;m just using Xen&#8217;s phy handler for the disk section of =
my VM&#8217;s cfg file.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>I see that there is a nice howto for debian on remusha.wikidot.com, =
but again it uses a 2.6.32 kernel from Jeremy&#8217;s git repo, which =
has the tap kernel module.&nbsp; I again assert that currently there is =
very little out there that would help to get someone started using remus =
with drbd in the linux 3.1.x world.&nbsp; I run remus at work, but =
it&#8217;s using shared storage and have no need to use it with drbd, =
but at home I don&#8217;t really want to set that up, so I thought drbd =
would be a nice start.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>I&#8217;ve started diffing the 8.3.9 branch of drbd with your changes =
for remus and will see how hard it is to get that in the 8.3.11 version =
I&#8217;m using. <o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>With that being said, I mostly use xl for everything at home, I =
don&#8217;t even have the xend service running, which makes matters =
worse, since I&#8217;m sure that most of remus uses the xend service and =
not the API to do the magic.&nbsp; I am willing to document my steps and =
post to the wiki, so that others could benefit from =
it!<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Mike<o:p></o:p></span></p></div></div></div></body></html>
------=_NextPart_000_0004_01CCA891.35E9A290--



--===============3190548398993086071==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3190548398993086071==--



From xen-devel-bounces@lists.xensource.com Tue Nov 22 02:48:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 02:48:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSgPC-0003tY-Pl; Tue, 22 Nov 2011 02:48:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RSgPB-0003tQ-CA
	for Xen-devel@lists.xensource.com; Tue, 22 Nov 2011 02:48:17 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321930040!44835356!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26009 invoked from network); 22 Nov 2011 02:47:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 02:47:21 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAM2loTl017851
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 02:47:51 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAM2ln7l010233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 02:47:50 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAM2ligb017261; Mon, 21 Nov 2011 20:47:44 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 18:47:44 -0800
Date: Mon, 21 Nov 2011 18:47:43 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Keir
	Fraser <keir.xen@gmail.com>
Message-ID: <20111121184743.281f8364@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4ECB0D57.005A,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] __vmptrst() broken...
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Keir,

__vmptrst() seems broken. It is:

static inline void __vmptrst(u64 addr)
{
    asm volatile ( VMPTRST_OPCODE
                   MODRM_EAX_07
                   :
                   : "a" (&addr)
                   : "memory");
}


should be:

static inline void __vmptrst(u64 *addr) 
{           
    asm volatile ( VMPTRST_OPCODE
                   MODRM_EAX_07 
                   :
                   : "a" (addr)
                   : "memory");
}   



Do you think you can just fix it in one of your changes without 
official patch?

thanks much,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 02:48:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 02:48:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSgPC-0003tY-Pl; Tue, 22 Nov 2011 02:48:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RSgPB-0003tQ-CA
	for Xen-devel@lists.xensource.com; Tue, 22 Nov 2011 02:48:17 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321930040!44835356!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26009 invoked from network); 22 Nov 2011 02:47:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 02:47:21 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAM2loTl017851
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 02:47:51 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAM2ln7l010233
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 02:47:50 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAM2ligb017261; Mon, 21 Nov 2011 20:47:44 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 21 Nov 2011 18:47:44 -0800
Date: Mon, 21 Nov 2011 18:47:43 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Keir
	Fraser <keir.xen@gmail.com>
Message-ID: <20111121184743.281f8364@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4ECB0D57.005A,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] __vmptrst() broken...
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Keir,

__vmptrst() seems broken. It is:

static inline void __vmptrst(u64 addr)
{
    asm volatile ( VMPTRST_OPCODE
                   MODRM_EAX_07
                   :
                   : "a" (&addr)
                   : "memory");
}


should be:

static inline void __vmptrst(u64 *addr) 
{           
    asm volatile ( VMPTRST_OPCODE
                   MODRM_EAX_07 
                   :
                   : "a" (addr)
                   : "memory");
}   



Do you think you can just fix it in one of your changes without 
official patch?

thanks much,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 03:45:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 03:45:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RShI0-0004G2-8m; Tue, 22 Nov 2011 03:44:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1RShHy-0004Fx-GK
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 03:44:54 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1321933466!4043123!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31987 invoked from network); 22 Nov 2011 03:44:26 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 03:44:26 -0000
Received: by bkbzt12 with SMTP id zt12so10637379bkb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 19:44:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=KNjmSErjBKDF0Kt/4/8V25CQM+m/4LeIxND4eEo0PDk=;
	b=MQGh7luc+SLeS9OoBQl6LpN/Pph7AtHLpvoR7fqWRLmIFksVOaD+C69o05I0bQXqpO
	Y0yxnv6EtDYJn+quQwAi5Tv60L1NtOQyct3iJKZWYGwERpAjimnZ8e7ywCfkXYTuUmhB
	FU+38JQdKQ+VlBqROePisjVyY+hFqxxA4d8Hw=
MIME-Version: 1.0
Received: by 10.204.152.87 with SMTP id f23mr17213857bkw.18.1321933465442;
	Mon, 21 Nov 2011 19:44:25 -0800 (PST)
Received: by 10.204.66.77 with HTTP; Mon, 21 Nov 2011 19:44:25 -0800 (PST)
In-Reply-To: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
References: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
Date: Mon, 21 Nov 2011 21:44:25 -0600
Message-ID: <CAKLFbfzqPA867ZFSuF=m2JYqOh9qmb2Vq3LXx94ndWTpPamirw@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: Evandro Abreu <evandro.abreu@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] virtualization of desktop applications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2957014472460784744=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2957014472460784744==
Content-Type: multipart/alternative; boundary=0015175cffa69fdae704b24a9e64

--0015175cffa69fdae704b24a9e64
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 21, 2011 at 1:24 PM, Evandro Abreu <evandro.abreu@gmail.com>wrote:

> I'm starting to study with virtualization of desktop applications and
> would like tips on how to display a virtual machine in the browser. Could
> anyone give me tips or links.
>
> Thank you.
>
> --
>
> Evandro Abreu.
> MSc Student / Recife Center for Advanced Studies - C.E.S.A.R
> Recife, Brazil
> Talk: evandro.abreu
> Twitter: http://twitter.com/abreu_evandro
> MSN: abreu_evandro@hotmail.com
> Skype: evandro_abreu
> Phone:(86)8814-5000 / (81)9846-8011
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
See: http://stackvm.com/

~ SDK

--0015175cffa69fdae704b24a9e64
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Nov 21, 2011 at 1:24 PM, Evandro Abreu <=
span dir=3D"ltr">&lt;<a href=3D"mailto:evandro.abreu@gmail.com">evandro.abr=
eu@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I&#39;m starting to study with virtualization of desktop applications and w=
ould like tips on how to display a virtual machine in the browser. Could an=
yone give me tips or links.=A0<div><br></div><div>Thank you.<br clear=3D"al=
l">
<font color=3D"#888888">
<div><br></div>-- <br><br><div><div>Evandro Abreu.<div><span style=3D"borde=
r-collapse:collapse;font-family:arial,sans-serif;font-size:13px">MSc Studen=
t / Recife Center for Advanced Studies - C.E.S.A.R<br></span><span style=3D=
"border-collapse:collapse;font-family:arial,sans-serif;font-size:13px">Reci=
fe, Brazil</span></div>

<div><font face=3D"arial, sans-serif"><span style=3D"border-collapse:collap=
se">Talk: evandro.abreu<br></span></font>Twitter: <a href=3D"http://twitter=
.com/abreu_evandro" target=3D"_blank">http://twitter.com/abreu_evandro</a><=
br>
</div>
</div><div>MSN: <a href=3D"mailto:abreu_evandro@hotmail.com" target=3D"_bla=
nk">abreu_evandro@hotmail.com</a></div><div>Skype: evandro_abreu</div><div>=
Phone:(86)8814-5000 / <a href=3D"tel:%2881%299846-8011" value=3D"+181984680=
11" target=3D"_blank">(81)9846-8011</a></div>
<div><br></div></div><br>
</font></div>
<br>_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br><div>See:=A0<a href=3D"http://stackvm.com/">http=
://stackvm.com/</a></div><div><br></div><div>~ SDK</div>

--0015175cffa69fdae704b24a9e64--


--===============2957014472460784744==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2957014472460784744==--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 03:45:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 03:45:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RShI0-0004G2-8m; Tue, 22 Nov 2011 03:44:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1RShHy-0004Fx-GK
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 03:44:54 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1321933466!4043123!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31987 invoked from network); 22 Nov 2011 03:44:26 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 03:44:26 -0000
Received: by bkbzt12 with SMTP id zt12so10637379bkb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 19:44:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=KNjmSErjBKDF0Kt/4/8V25CQM+m/4LeIxND4eEo0PDk=;
	b=MQGh7luc+SLeS9OoBQl6LpN/Pph7AtHLpvoR7fqWRLmIFksVOaD+C69o05I0bQXqpO
	Y0yxnv6EtDYJn+quQwAi5Tv60L1NtOQyct3iJKZWYGwERpAjimnZ8e7ywCfkXYTuUmhB
	FU+38JQdKQ+VlBqROePisjVyY+hFqxxA4d8Hw=
MIME-Version: 1.0
Received: by 10.204.152.87 with SMTP id f23mr17213857bkw.18.1321933465442;
	Mon, 21 Nov 2011 19:44:25 -0800 (PST)
Received: by 10.204.66.77 with HTTP; Mon, 21 Nov 2011 19:44:25 -0800 (PST)
In-Reply-To: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
References: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
Date: Mon, 21 Nov 2011 21:44:25 -0600
Message-ID: <CAKLFbfzqPA867ZFSuF=m2JYqOh9qmb2Vq3LXx94ndWTpPamirw@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: Evandro Abreu <evandro.abreu@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] virtualization of desktop applications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2957014472460784744=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2957014472460784744==
Content-Type: multipart/alternative; boundary=0015175cffa69fdae704b24a9e64

--0015175cffa69fdae704b24a9e64
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 21, 2011 at 1:24 PM, Evandro Abreu <evandro.abreu@gmail.com>wrote:

> I'm starting to study with virtualization of desktop applications and
> would like tips on how to display a virtual machine in the browser. Could
> anyone give me tips or links.
>
> Thank you.
>
> --
>
> Evandro Abreu.
> MSc Student / Recife Center for Advanced Studies - C.E.S.A.R
> Recife, Brazil
> Talk: evandro.abreu
> Twitter: http://twitter.com/abreu_evandro
> MSN: abreu_evandro@hotmail.com
> Skype: evandro_abreu
> Phone:(86)8814-5000 / (81)9846-8011
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
See: http://stackvm.com/

~ SDK

--0015175cffa69fdae704b24a9e64
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Nov 21, 2011 at 1:24 PM, Evandro Abreu <=
span dir=3D"ltr">&lt;<a href=3D"mailto:evandro.abreu@gmail.com">evandro.abr=
eu@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I&#39;m starting to study with virtualization of desktop applications and w=
ould like tips on how to display a virtual machine in the browser. Could an=
yone give me tips or links.=A0<div><br></div><div>Thank you.<br clear=3D"al=
l">
<font color=3D"#888888">
<div><br></div>-- <br><br><div><div>Evandro Abreu.<div><span style=3D"borde=
r-collapse:collapse;font-family:arial,sans-serif;font-size:13px">MSc Studen=
t / Recife Center for Advanced Studies - C.E.S.A.R<br></span><span style=3D=
"border-collapse:collapse;font-family:arial,sans-serif;font-size:13px">Reci=
fe, Brazil</span></div>

<div><font face=3D"arial, sans-serif"><span style=3D"border-collapse:collap=
se">Talk: evandro.abreu<br></span></font>Twitter: <a href=3D"http://twitter=
.com/abreu_evandro" target=3D"_blank">http://twitter.com/abreu_evandro</a><=
br>
</div>
</div><div>MSN: <a href=3D"mailto:abreu_evandro@hotmail.com" target=3D"_bla=
nk">abreu_evandro@hotmail.com</a></div><div>Skype: evandro_abreu</div><div>=
Phone:(86)8814-5000 / <a href=3D"tel:%2881%299846-8011" value=3D"+181984680=
11" target=3D"_blank">(81)9846-8011</a></div>
<div><br></div></div><br>
</font></div>
<br>_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br><div>See:=A0<a href=3D"http://stackvm.com/">http=
://stackvm.com/</a></div><div><br></div><div>~ SDK</div>

--0015175cffa69fdae704b24a9e64--


--===============2957014472460784744==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2957014472460784744==--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 03:59:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 03:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RShV3-0004RU-Oe; Tue, 22 Nov 2011 03:58:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RShV1-0004R8-Ok
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 03:58:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1321934275!2463026!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9198 invoked from network); 22 Nov 2011 03:57:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 03:57:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,551,1315180800"; 
   d="scan'208";a="9053358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 03:57:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 03:57:54 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RShUY-00018s-Hc;
	Tue, 22 Nov 2011 03:57:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RShUY-0005uz-FD;
	Tue, 22 Nov 2011 03:57:54 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9951-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 03:57:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9951: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9951 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9951/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate         fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  0a0c02a61676
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24169:0a0c02a61676
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24168:9c350ab8d3ea
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Nov 21 09:29:31 2011 +0100
    
    x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
    
    Xen itself (as much as Linux) relies on this behavior, so it should
    also emulate it properly. Not doing so reportedly gets in the way of
    kexec inside a HVM guest.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24167:335e8273a3f3
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 03:59:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 03:59:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RShV3-0004RU-Oe; Tue, 22 Nov 2011 03:58:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RShV1-0004R8-Ok
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 03:58:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1321934275!2463026!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9198 invoked from network); 22 Nov 2011 03:57:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 03:57:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,551,1315180800"; 
   d="scan'208";a="9053358"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 03:57:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 03:57:54 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RShUY-00018s-Hc;
	Tue, 22 Nov 2011 03:57:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RShUY-0005uz-FD;
	Tue, 22 Nov 2011 03:57:54 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9951-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 03:57:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9951: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9951 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9951/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate         fail REGR. vs. 9855

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  0a0c02a61676
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24169:0a0c02a61676
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24168:9c350ab8d3ea
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Nov 21 09:29:31 2011 +0100
    
    x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
    
    Xen itself (as much as Linux) relies on this behavior, so it should
    also emulate it properly. Not doing so reportedly gets in the way of
    kexec inside a HVM guest.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24167:335e8273a3f3
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 04:19:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 04:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RShom-0004iX-PY; Tue, 22 Nov 2011 04:18:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RShol-0004iS-Lm
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 04:18:47 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321935498!5163591!1
X-Originating-IP: [216.33.127.80]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24781 invoked from network); 22 Nov 2011 04:18:19 -0000
Received: from mta11.charter.net (HELO mta11.charter.net) (216.33.127.80)
	by server-11.tower-21.messagelabs.com with SMTP;
	22 Nov 2011 04:18:19 -0000
Received: from imp11 ([10.20.200.11]) by mta11.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111122041818.OUNU4019.mta11.charter.net@imp11>;
	Mon, 21 Nov 2011 23:18:18 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp11 with smtp.charter.net
	id 04JJ1i00546xN4z054JJSq; Mon, 21 Nov 2011 23:18:18 -0500
X-Authority-Analysis: v=1.1 cv=3kn4snR/2TdwuYXvh+wm0CPnSGzQFWY7ukd303aPFv0=
	c=1 sm=1 a=WRI_wB_09dkA:10 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10
	a=YBs1tj9y_9UA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=SEF7xSSsAAAA:8
	a=pGLkceISAAAA:8 a=JqEG_dyiAAAA:8 a=69EAbJreAAAA:8 a=Zopq5lrnAAAA:8
	a=NEAV23lmAAAA:8 a=r1tbr-tZ3aWFOAtfn1wA:9 a=rHW_PaZkFxYOrotg8AkA:7
	a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=EfJqPEOeqlMA:10
	a=Tdx5OyTQvKcfSvVF:21
	a=Tzh1_3WbM5lXOCB7:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8
	a=WPM8BQ3sRitW_BjoJoIA:9 a=t8MiKCpNk7vqNY0hZ84A:7 a=gKO2Hq4RSVkA:10
	a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id E1241203CF;
	Tue, 22 Nov 2011 04:18:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id WIOM28EKz+f9; Mon, 21 Nov 2011 23:18:14 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id 86CF720394;
	Mon, 21 Nov 2011 23:18:14 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: "'Srujan Kotikela'" <ksrujandas@gmail.com>,
	"'Evandro Abreu'" <evandro.abreu@gmail.com>
References: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
	<CAKLFbfzqPA867ZFSuF=m2JYqOh9qmb2Vq3LXx94ndWTpPamirw@mail.gmail.com>
In-Reply-To: <CAKLFbfzqPA867ZFSuF=m2JYqOh9qmb2Vq3LXx94ndWTpPamirw@mail.gmail.com>
Date: Mon, 21 Nov 2011 23:17:46 -0500
Message-ID: <000601cca8cd$b0350ad0$109f2070$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJnLwkETeUbnNLkkMnT2QCbsUB/7QL+yc7BlGtGvuA=
Content-Language: en-us
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] virtualization of desktop applications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0914891693694412569=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multipart message in MIME format.

--===============0914891693694412569==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0007_01CCA8A3.C75F02D0"
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0007_01CCA8A3.C75F02D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Srujan Kotikela
Sent: Monday, November 21, 2011 10:44 PM
To: Evandro Abreu
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] virtualization of desktop applications

 

On Mon, Nov 21, 2011 at 1:24 PM, Evandro Abreu <evandro.abreu@gmail.com>
wrote:

I'm starting to study with virtualization of desktop applications and would
like tips on how to display a virtual machine in the browser. Could anyone
give me tips or links. 

 

Thank you.


 

-- 

Evandro Abreu.

MSc Student / Recife Center for Advanced Studies - C.E.S.A.R
Recife, Brazil

Talk: evandro.abreu
Twitter: http://twitter.com/abreu_evandro

MSN: abreu_evandro@hotmail.com

Skype: evandro_abreu

Phone:(86)8814-5000 / (81)9846-8011 <tel:%2881%299846-8011> 

 

 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

 

See: http://stackvm.com/

 

~ SDK

 

NoVNC is another option: http://kanaka.github.com/noVNC/


------=_NextPart_000_0007_01CCA8A3.C75F02D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
xen-devel-bounces@lists.xensource.com =
[mailto:xen-devel-bounces@lists.xensource.com] <b>On Behalf Of =
</b>Srujan Kotikela<br><b>Sent:</b> Monday, November 21, 2011 10:44 =
PM<br><b>To:</b> Evandro Abreu<br><b>Cc:</b> =
xen-devel@lists.xensource.com<br><b>Subject:</b> Re: [Xen-devel] =
virtualization of desktop applications<o:p></o:p></span></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal>On Mon, =
Nov 21, 2011 at 1:24 PM, Evandro Abreu &lt;<a =
href=3D"mailto:evandro.abreu@gmail.com">evandro.abreu@gmail.com</a>&gt; =
wrote:<o:p></o:p></p><p class=3DMsoNormal>I'm starting to study with =
virtualization of desktop applications and would like tips on how to =
display a virtual machine in the browser. Could anyone give me tips or =
links.&nbsp;<o:p></o:p></p><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Thank you.<br clear=3Dall><span =
style=3D'color:#888888'><o:p></o:p></span></p><div><p =
class=3DMsoNormal><span =
style=3D'color:#888888'><o:p>&nbsp;</o:p></span></p></div><p =
class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'color:#888888'>-- <o:p></o:p></span></p><div><div><p =
class=3DMsoNormal><span style=3D'color:#888888'>Evandro =
Abreu.<o:p></o:p></span></p><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#888888'=
>MSc Student / Recife Center for Advanced Studies - C.E.S.A.R<br>Recife, =
Brazil</span><span =
style=3D'color:#888888'><o:p></o:p></span></p></div><div><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#888888'>Talk: =
evandro.abreu<br></span><span style=3D'color:#888888'>Twitter: <a =
href=3D"http://twitter.com/abreu_evandro" =
target=3D"_blank">http://twitter.com/abreu_evandro</a><o:p></o:p></span><=
/p></div></div><div><p class=3DMsoNormal><span =
style=3D'color:#888888'>MSN: <a =
href=3D"mailto:abreu_evandro@hotmail.com" =
target=3D"_blank">abreu_evandro@hotmail.com</a><o:p></o:p></span></p></di=
v><div><p class=3DMsoNormal><span style=3D'color:#888888'>Skype: =
evandro_abreu<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span =
style=3D'color:#888888'>Phone:(86)8814-5000 / <a =
href=3D"tel:%2881%299846-8011" =
target=3D"_blank">(81)9846-8011</a><o:p></o:p></span></p></div><div><p =
class=3DMsoNormal><span =
style=3D'color:#888888'><o:p>&nbsp;</o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><br>______________________________________=
_________<br>Xen-devel mailing list<br><a =
href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.c=
om</a><br><a href=3D"http://lists.xensource.com/xen-devel" =
target=3D"_blank">http://lists.xensource.com/xen-devel</a><o:p></o:p></p>=
</div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p =
class=3DMsoNormal>See:&nbsp;<a =
href=3D"http://stackvm.com/">http://stackvm.com/</a><o:p></o:p></p></div>=
<div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>~ SDK<o:p></o:p></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>NoVNC is another option: =
http://kanaka.github.com/noVNC/<o:p></o:p></span></p></div></div></body><=
/html>
------=_NextPart_000_0007_01CCA8A3.C75F02D0--



--===============0914891693694412569==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0914891693694412569==--



From xen-devel-bounces@lists.xensource.com Tue Nov 22 04:19:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 04:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RShom-0004iX-PY; Tue, 22 Nov 2011 04:18:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>) id 1RShol-0004iS-Lm
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 04:18:47 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321935498!5163591!1
X-Originating-IP: [216.33.127.80]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24781 invoked from network); 22 Nov 2011 04:18:19 -0000
Received: from mta11.charter.net (HELO mta11.charter.net) (216.33.127.80)
	by server-11.tower-21.messagelabs.com with SMTP;
	22 Nov 2011 04:18:19 -0000
Received: from imp11 ([10.20.200.11]) by mta11.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111122041818.OUNU4019.mta11.charter.net@imp11>;
	Mon, 21 Nov 2011 23:18:18 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp11 with smtp.charter.net
	id 04JJ1i00546xN4z054JJSq; Mon, 21 Nov 2011 23:18:18 -0500
X-Authority-Analysis: v=1.1 cv=3kn4snR/2TdwuYXvh+wm0CPnSGzQFWY7ukd303aPFv0=
	c=1 sm=1 a=WRI_wB_09dkA:10 a=VCxxn1A5iYMA:10 a=wPDyFdB5xvgA:10
	a=YBs1tj9y_9UA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=SEF7xSSsAAAA:8
	a=pGLkceISAAAA:8 a=JqEG_dyiAAAA:8 a=69EAbJreAAAA:8 a=Zopq5lrnAAAA:8
	a=NEAV23lmAAAA:8 a=r1tbr-tZ3aWFOAtfn1wA:9 a=rHW_PaZkFxYOrotg8AkA:7
	a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=EfJqPEOeqlMA:10
	a=Tdx5OyTQvKcfSvVF:21
	a=Tzh1_3WbM5lXOCB7:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8
	a=WPM8BQ3sRitW_BjoJoIA:9 a=t8MiKCpNk7vqNY0hZ84A:7 a=gKO2Hq4RSVkA:10
	a=hTZeC7Yk6K0A:10 a=tXsnliwV7b4A:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id E1241203CF;
	Tue, 22 Nov 2011 04:18:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id WIOM28EKz+f9; Mon, 21 Nov 2011 23:18:14 -0500 (EST)
Received: from mikePC (unknown [192.168.1.172])
	by mail.ark-net.org (Postfix) with ESMTP id 86CF720394;
	Mon, 21 Nov 2011 23:18:14 -0500 (EST)
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: "'Srujan Kotikela'" <ksrujandas@gmail.com>,
	"'Evandro Abreu'" <evandro.abreu@gmail.com>
References: <CAHaazJfdjqjwt_c0-rYGWScKuaEr9kfgKMMaR7ZrRQZHjuHC5A@mail.gmail.com>
	<CAKLFbfzqPA867ZFSuF=m2JYqOh9qmb2Vq3LXx94ndWTpPamirw@mail.gmail.com>
In-Reply-To: <CAKLFbfzqPA867ZFSuF=m2JYqOh9qmb2Vq3LXx94ndWTpPamirw@mail.gmail.com>
Date: Mon, 21 Nov 2011 23:17:46 -0500
Message-ID: <000601cca8cd$b0350ad0$109f2070$@ark-net.org>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJnLwkETeUbnNLkkMnT2QCbsUB/7QL+yc7BlGtGvuA=
Content-Language: en-us
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] virtualization of desktop applications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0914891693694412569=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multipart message in MIME format.

--===============0914891693694412569==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0007_01CCA8A3.C75F02D0"
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0007_01CCA8A3.C75F02D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Srujan Kotikela
Sent: Monday, November 21, 2011 10:44 PM
To: Evandro Abreu
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] virtualization of desktop applications

 

On Mon, Nov 21, 2011 at 1:24 PM, Evandro Abreu <evandro.abreu@gmail.com>
wrote:

I'm starting to study with virtualization of desktop applications and would
like tips on how to display a virtual machine in the browser. Could anyone
give me tips or links. 

 

Thank you.


 

-- 

Evandro Abreu.

MSc Student / Recife Center for Advanced Studies - C.E.S.A.R
Recife, Brazil

Talk: evandro.abreu
Twitter: http://twitter.com/abreu_evandro

MSN: abreu_evandro@hotmail.com

Skype: evandro_abreu

Phone:(86)8814-5000 / (81)9846-8011 <tel:%2881%299846-8011> 

 

 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

 

See: http://stackvm.com/

 

~ SDK

 

NoVNC is another option: http://kanaka.github.com/noVNC/


------=_NextPart_000_0007_01CCA8A3.C75F02D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
xen-devel-bounces@lists.xensource.com =
[mailto:xen-devel-bounces@lists.xensource.com] <b>On Behalf Of =
</b>Srujan Kotikela<br><b>Sent:</b> Monday, November 21, 2011 10:44 =
PM<br><b>To:</b> Evandro Abreu<br><b>Cc:</b> =
xen-devel@lists.xensource.com<br><b>Subject:</b> Re: [Xen-devel] =
virtualization of desktop applications<o:p></o:p></span></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal>On Mon, =
Nov 21, 2011 at 1:24 PM, Evandro Abreu &lt;<a =
href=3D"mailto:evandro.abreu@gmail.com">evandro.abreu@gmail.com</a>&gt; =
wrote:<o:p></o:p></p><p class=3DMsoNormal>I'm starting to study with =
virtualization of desktop applications and would like tips on how to =
display a virtual machine in the browser. Could anyone give me tips or =
links.&nbsp;<o:p></o:p></p><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Thank you.<br clear=3Dall><span =
style=3D'color:#888888'><o:p></o:p></span></p><div><p =
class=3DMsoNormal><span =
style=3D'color:#888888'><o:p>&nbsp;</o:p></span></p></div><p =
class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'color:#888888'>-- <o:p></o:p></span></p><div><div><p =
class=3DMsoNormal><span style=3D'color:#888888'>Evandro =
Abreu.<o:p></o:p></span></p><div><p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#888888'=
>MSc Student / Recife Center for Advanced Studies - C.E.S.A.R<br>Recife, =
Brazil</span><span =
style=3D'color:#888888'><o:p></o:p></span></p></div><div><p =
class=3DMsoNormal><span =
style=3D'font-family:"Arial","sans-serif";color:#888888'>Talk: =
evandro.abreu<br></span><span style=3D'color:#888888'>Twitter: <a =
href=3D"http://twitter.com/abreu_evandro" =
target=3D"_blank">http://twitter.com/abreu_evandro</a><o:p></o:p></span><=
/p></div></div><div><p class=3DMsoNormal><span =
style=3D'color:#888888'>MSN: <a =
href=3D"mailto:abreu_evandro@hotmail.com" =
target=3D"_blank">abreu_evandro@hotmail.com</a><o:p></o:p></span></p></di=
v><div><p class=3DMsoNormal><span style=3D'color:#888888'>Skype: =
evandro_abreu<o:p></o:p></span></p></div><div><p class=3DMsoNormal><span =
style=3D'color:#888888'>Phone:(86)8814-5000 / <a =
href=3D"tel:%2881%299846-8011" =
target=3D"_blank">(81)9846-8011</a><o:p></o:p></span></p></div><div><p =
class=3DMsoNormal><span =
style=3D'color:#888888'><o:p>&nbsp;</o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><br>______________________________________=
_________<br>Xen-devel mailing list<br><a =
href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.c=
om</a><br><a href=3D"http://lists.xensource.com/xen-devel" =
target=3D"_blank">http://lists.xensource.com/xen-devel</a><o:p></o:p></p>=
</div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p =
class=3DMsoNormal>See:&nbsp;<a =
href=3D"http://stackvm.com/">http://stackvm.com/</a><o:p></o:p></p></div>=
<div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>~ SDK<o:p></o:p></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>NoVNC is another option: =
http://kanaka.github.com/noVNC/<o:p></o:p></span></p></div></div></body><=
/html>
------=_NextPart_000_0007_01CCA8A3.C75F02D0--



--===============0914891693694412569==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0914891693694412569==--



From xen-devel-bounces@lists.xensource.com Tue Nov 22 06:58:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 06:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSkIv-0006Ps-Oq; Tue, 22 Nov 2011 06:58:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>)
	id 1RSkIt-0006Pg-Tm; Tue, 22 Nov 2011 06:58:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-182.messagelabs.com!1321945053!4055884!1
X-Originating-IP: [142.103.6.52]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23293 invoked from network); 22 Nov 2011 06:57:34 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 06:57:34 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pAM6vTx7019293
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL);
	Mon, 21 Nov 2011 22:57:30 -0800
Received: by bkbzt12 with SMTP id zt12so10824519bkb.30
	for <multiple recipients>; Mon, 21 Nov 2011 22:57:28 -0800 (PST)
Received: by 10.205.121.133 with SMTP id gc5mr4369661bkc.25.1321945048188;
	Mon, 21 Nov 2011 22:57:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.177.19 with HTTP; Mon, 21 Nov 2011 22:56:47 -0800 (PST)
In-Reply-To: <000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
	<000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 21 Nov 2011 22:56:47 -0800
Message-ID: <CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
To: "Michael A. Collins" <mike.a.collins@ark-net.org>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4758066349544042571=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4758066349544042571==
Content-Type: multipart/alternative; boundary=000e0ce0cd600288e504b24d51fc

--000e0ce0cd600288e504b24d51fc
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 21, 2011 at 6:04 PM, Michael A. Collins <
mike.a.collins@ark-net.org> wrote:

> *From:* Shriram Rajagopalan [mailto:rshriram@cs.ubc.ca]
> *Sent:* Monday, November 21, 2011 12:03 AM
> *To:* Michael A. Collins
> *Cc:* xen-devel@lists.xensource.com; xen-users@lists.xensource.com
> *Subject:* Re: [Xen-devel] BLKTAP****
>
> ** **
>
> =85****
>
>
> drbd/remus - why  do you need blktap ?
>
> shriram****
>
> ** **
>
> From my readings, I have found only a few examples of using remus.  Most
> of them refer to using the following stanza in the disk section of a VM=
=92s
> cfg file:****
>
> tap2:remus:backuphost:anyfreeport|****
>
> **
>

Not sure if tap2 is the right syntax.. there was some issue a while ago,
between tap & tap2
syntaxes.


> **
>
> That doesn=92t work for xl, but even using it with xm causes issues, sinc=
e
> there isn=92t a tap device without the kernel module.
>

correct - so far/

>   So I also found out that drbd uses a tap device to handle the hook in
> with Xen, so if you want to have automagic working with block-drbd xen
> scripts then you have to use tap.
>

eh? I dont think so. with drbd based backend for xen VMs (with or without
remus),
you just use the drbd:<resourceName> syntax (much like phy:...).
And then the block-drbd script in /etc/xen/scripts/ takes care of the rest
of the magic.
There is no tapdisk involved in this procedure.

In essence, the block-drbd script just
1. parses the drbd:<resourceName> syntax to determine which one of
 the /dev/drbd[X] devices belong to the <resourceName>,
2. does some sanity checks
3. promotes <resourceName> in the host to "Primary" and then

the rest of the control flow happens akin to a phy device, with
/dev/drbd[X] being
supplied as the path to the disk backend.

You could do this manually too in two simple steps.
 1. On the host where you want to launch the VM, promote the drbd disk to
Primary
 (ensure that the other end is in secondary state)
 2. change the VM's disk config to
 phy:/dev/drbd/by-res/<resourceName>
  and you are good to go.
  [Though with remus, you ll have to hack the
tools/python/xen/remus/device.py script to
  recognize the /dev/drbd/* URI.]

With all that said and done, I=92m currently running drbd 8.3.11 since that=
=92s
> the version of the kernel module included with Linux 3.1, but I=92m just
> using Xen=92s phy handler for the disk section of my VM=92s cfg file.****
>
> ** **
>
> I see that there is a nice howto for debian on remusha.wikidot.com, but
> again it uses a 2.6.32 kernel from Jeremy=92s git repo, which has the tap
> kernel module.  I again assert that currently there is very little out
> there that would help to get someone started using remus with drbd in the
> linux 3.1.x world.  I run remus at work, but it=92s using shared storage =
and
> have no need to use it with drbd, but at home I don=92t really want to se=
t
> that up, so I thought drbd would be a nice start.****
>
> ** **
>
> I=92ve started diffing the 8.3.9 branch of drbd with your changes for rem=
us
> and will see how hard it is to get that in the 8.3.11 version I=92m using=
. *
> ***
>
> **
>

Is the remusified drbd (8.3.9) not compiling under the 3.1.x kernel anymore
or are you interested in
the latest version of DRBD + the remus stuff ?


>  **
>
> With that being said, I mostly use xl for everything at home, I don=92t e=
ven
> have the xend service running, which makes matters worse, since I=92m sur=
e
> that most of remus uses the xend service and not the API to do the magic.
> I am willing to document my steps and post to the wiki, so that others
> could benefit from it!****
>
> Mike****
>

shriram

--000e0ce0cd600288e504b24d51fc
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Nov 21, 2011 at 6:04 PM, Michael A. Coll=
ins <span dir=3D"ltr">&lt;<a href=3D"mailto:mike.a.collins@ark-net.org">mik=
e.a.collins@ark-net.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex;">

<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNorm=
al"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot=
;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;font-fam=
ily:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Shriram Rajagopalan <a href=
=3D"mailto:[mailto:rshriram@cs.ubc.ca]" target=3D"_blank">[mailto:rshriram@=
cs.ubc.ca]</a> <br>

<b>Sent:</b> Monday, November 21, 2011 12:03 AM<br><b>To:</b> Michael A. Co=
llins<br><b>Cc:</b> <a href=3D"mailto:xen-devel@lists.xensource.com" target=
=3D"_blank">xen-devel@lists.xensource.com</a>; <a href=3D"mailto:xen-users@=
lists.xensource.com" target=3D"_blank">xen-users@lists.xensource.com</a><br=
>

<b>Subject:</b> Re: [Xen-devel] BLKTAP<u></u><u></u></span></p><p class=3D"=
MsoNormal"><u></u>=A0<u></u></p><div><div><div class=3D"im"><p class=3D"Mso=
Normal"><span style=3D"color:#1f497d">=85<u></u><u></u></span></p><p class=
=3D"MsoNormal">

<br>drbd/remus - why=A0 do you need blktap ?<br><br>shriram<span style=3D"c=
olor:#1f497d"><u></u><u></u></span></p><p class=3D"MsoNormal"><span style=
=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
;color:#1f497d"><u></u>=A0<u></u></span></p>

</div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">From my readings, I=
 have found only a few examples of using remus.=A0 Most of them refer to us=
ing the following stanza in the disk section of a VM=92s cfg file:<u></u><u=
></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">tap2:remus:backuphost:any=
freeport|<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"fon=
t-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:=
#1f497d"><u></u>=A0</span></p>

</div></div></div></div></blockquote><div><br>Not sure if tap2 is the right=
 syntax.. there was some issue a while ago, between tap &amp; tap2<br>synta=
xes.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt=
 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1e=
x;">

<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><div><div><p class=
=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: &quot;Calibri&q=
uot;,&quot;sans-serif&quot;; color: rgb(31, 73, 125);"><u></u></span></p><p=
 class=3D"MsoNormal">

<span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1f497d">That doesn=92t work for xl, but even using it wi=
th xm causes issues, since there isn=92t a tap device without the kernel mo=
dule.</span></p>

</div></div></div></div></blockquote><div><br>correct - so far/ <br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div link=3D"blue"=
 vlink=3D"purple" lang=3D"EN-US">

<div><div><div><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-=
family: &quot;Calibri&quot;,&quot;sans-serif&quot;; color: rgb(31, 73, 125)=
;">=A0 So I also found out that drbd uses a tap device to handle the hook i=
n with Xen, so if you want to have automagic working with block-drbd xen sc=
ripts then you have to use tap.=A0 </span></p>

</div></div></div></div></blockquote><div><br>eh? I dont think so. with drb=
d based backend for xen VMs (with or without remus),<br>you just use the dr=
bd:&lt;resourceName&gt; syntax (much like phy:...). <br>And then the block-=
drbd script in /etc/xen/scripts/ takes care of the rest of the magic.<br>

There is no tapdisk involved in this procedure. <br><br>In essence, the blo=
ck-drbd script just <br>1. parses the drbd:&lt;resourceName&gt; syntax to d=
etermine which one of <br>=A0the /dev/drbd[X] devices belong to the &lt;res=
ourceName&gt;,<br>

2. does some sanity checks<br>3. promotes &lt;resourceName&gt; in the host =
to &quot;Primary&quot; and then <br><br>the rest of the control flow happen=
s akin to a phy device, with /dev/drbd[X] being<br>supplied as the path to =
the disk backend.<br>

<br>You could do this manually too in two simple steps.<br>=A01. On the hos=
t where you want to launch the VM, promote the drbd disk to Primary<br>=A0(=
ensure that the other end is in secondary state)<br>=A02. change the VM&#39=
;s disk config to<br>

=A0phy:/dev/drbd/by-res/&lt;resourceName&gt;<br>=A0 and you are good to go.=
<br>=A0 [Though with remus, you ll have to hack the tools/python/xen/remus/=
device.py script to<br>=A0 recognize the /dev/drbd/* URI.]<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><div><div><p class=
=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: &quot;Calibri&q=
uot;,&quot;sans-serif&quot;; color: rgb(31, 73, 125);">With all that said a=
nd done, I=92m currently running drbd 8.3.11 since that=92s the version of =
the kernel module included with Linux 3.1, but I=92m just using Xen=92s phy=
 handler for the disk section of my VM=92s cfg file.<u></u><u></u></span></=
p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=
/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I see that there is a =
nice howto for debian on <a href=3D"http://remusha.wikidot.com" target=3D"_=
blank">remusha.wikidot.com</a>, but again it uses a 2.6.32 kernel from Jere=
my=92s git repo, which has the tap kernel module.=A0 I again assert that cu=
rrently there is very little out there that would help to get someone start=
ed using remus with drbd in the linux 3.1.x world.=A0 I run remus at work, =
but it=92s using shared storage and have no need to use it with drbd, but a=
t home I don=92t really want to set that up, so I thought drbd would be a n=
ice start.<u></u><u></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=
/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I=92ve started diffing=
 the 8.3.9 branch of drbd with your changes for remus and will see how hard=
 it is to get that in the 8.3.11 version I=92m using. <u></u><u></u></span>=
</p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u></span></p></div><=
/div></div></div></blockquote><div><br>Is the remusified drbd (8.3.9) not c=
ompiling under the 3.1.x kernel anymore or are you interested in<br>

the latest version of DRBD + the remus stuff ?<br>=A0<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px =
solid rgb(204, 204, 204); padding-left: 1ex;"><div link=3D"blue" vlink=3D"p=
urple" lang=3D"EN-US">

<div><div><div><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-=
family: &quot;Calibri&quot;,&quot;sans-serif&quot;; color: rgb(31, 73, 125)=
;">=A0<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.=
0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">W=
ith that being said, I mostly use xl for everything at home, I don=92t even=
 have the xend service running, which makes matters worse, since I=92m sure=
 that most of remus uses the xend service and not the API to do the magic.=
=A0 I am willing to document my steps and post to the wiki, so that others =
could benefit from it!<u></u><u></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Mike<u></u><u></u></span>=
</p></div></div></div></div></blockquote></div><br>shriram<br>

--000e0ce0cd600288e504b24d51fc--


--===============4758066349544042571==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4758066349544042571==--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 06:58:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 06:58:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSkIv-0006Ps-Oq; Tue, 22 Nov 2011 06:58:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>)
	id 1RSkIt-0006Pg-Tm; Tue, 22 Nov 2011 06:58:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-182.messagelabs.com!1321945053!4055884!1
X-Originating-IP: [142.103.6.52]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23293 invoked from network); 22 Nov 2011 06:57:34 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 06:57:34 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pAM6vTx7019293
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL);
	Mon, 21 Nov 2011 22:57:30 -0800
Received: by bkbzt12 with SMTP id zt12so10824519bkb.30
	for <multiple recipients>; Mon, 21 Nov 2011 22:57:28 -0800 (PST)
Received: by 10.205.121.133 with SMTP id gc5mr4369661bkc.25.1321945048188;
	Mon, 21 Nov 2011 22:57:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.177.19 with HTTP; Mon, 21 Nov 2011 22:56:47 -0800 (PST)
In-Reply-To: <000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
	<000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 21 Nov 2011 22:56:47 -0800
Message-ID: <CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
To: "Michael A. Collins" <mike.a.collins@ark-net.org>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4758066349544042571=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4758066349544042571==
Content-Type: multipart/alternative; boundary=000e0ce0cd600288e504b24d51fc

--000e0ce0cd600288e504b24d51fc
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 21, 2011 at 6:04 PM, Michael A. Collins <
mike.a.collins@ark-net.org> wrote:

> *From:* Shriram Rajagopalan [mailto:rshriram@cs.ubc.ca]
> *Sent:* Monday, November 21, 2011 12:03 AM
> *To:* Michael A. Collins
> *Cc:* xen-devel@lists.xensource.com; xen-users@lists.xensource.com
> *Subject:* Re: [Xen-devel] BLKTAP****
>
> ** **
>
> =85****
>
>
> drbd/remus - why  do you need blktap ?
>
> shriram****
>
> ** **
>
> From my readings, I have found only a few examples of using remus.  Most
> of them refer to using the following stanza in the disk section of a VM=
=92s
> cfg file:****
>
> tap2:remus:backuphost:anyfreeport|****
>
> **
>

Not sure if tap2 is the right syntax.. there was some issue a while ago,
between tap & tap2
syntaxes.


> **
>
> That doesn=92t work for xl, but even using it with xm causes issues, sinc=
e
> there isn=92t a tap device without the kernel module.
>

correct - so far/

>   So I also found out that drbd uses a tap device to handle the hook in
> with Xen, so if you want to have automagic working with block-drbd xen
> scripts then you have to use tap.
>

eh? I dont think so. with drbd based backend for xen VMs (with or without
remus),
you just use the drbd:<resourceName> syntax (much like phy:...).
And then the block-drbd script in /etc/xen/scripts/ takes care of the rest
of the magic.
There is no tapdisk involved in this procedure.

In essence, the block-drbd script just
1. parses the drbd:<resourceName> syntax to determine which one of
 the /dev/drbd[X] devices belong to the <resourceName>,
2. does some sanity checks
3. promotes <resourceName> in the host to "Primary" and then

the rest of the control flow happens akin to a phy device, with
/dev/drbd[X] being
supplied as the path to the disk backend.

You could do this manually too in two simple steps.
 1. On the host where you want to launch the VM, promote the drbd disk to
Primary
 (ensure that the other end is in secondary state)
 2. change the VM's disk config to
 phy:/dev/drbd/by-res/<resourceName>
  and you are good to go.
  [Though with remus, you ll have to hack the
tools/python/xen/remus/device.py script to
  recognize the /dev/drbd/* URI.]

With all that said and done, I=92m currently running drbd 8.3.11 since that=
=92s
> the version of the kernel module included with Linux 3.1, but I=92m just
> using Xen=92s phy handler for the disk section of my VM=92s cfg file.****
>
> ** **
>
> I see that there is a nice howto for debian on remusha.wikidot.com, but
> again it uses a 2.6.32 kernel from Jeremy=92s git repo, which has the tap
> kernel module.  I again assert that currently there is very little out
> there that would help to get someone started using remus with drbd in the
> linux 3.1.x world.  I run remus at work, but it=92s using shared storage =
and
> have no need to use it with drbd, but at home I don=92t really want to se=
t
> that up, so I thought drbd would be a nice start.****
>
> ** **
>
> I=92ve started diffing the 8.3.9 branch of drbd with your changes for rem=
us
> and will see how hard it is to get that in the 8.3.11 version I=92m using=
. *
> ***
>
> **
>

Is the remusified drbd (8.3.9) not compiling under the 3.1.x kernel anymore
or are you interested in
the latest version of DRBD + the remus stuff ?


>  **
>
> With that being said, I mostly use xl for everything at home, I don=92t e=
ven
> have the xend service running, which makes matters worse, since I=92m sur=
e
> that most of remus uses the xend service and not the API to do the magic.
> I am willing to document my steps and post to the wiki, so that others
> could benefit from it!****
>
> Mike****
>

shriram

--000e0ce0cd600288e504b24d51fc
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Nov 21, 2011 at 6:04 PM, Michael A. Coll=
ins <span dir=3D"ltr">&lt;<a href=3D"mailto:mike.a.collins@ark-net.org">mik=
e.a.collins@ark-net.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex;">

<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNorm=
al"><b><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot=
;sans-serif&quot;">From:</span></b><span style=3D"font-size:10.0pt;font-fam=
ily:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Shriram Rajagopalan <a href=
=3D"mailto:[mailto:rshriram@cs.ubc.ca]" target=3D"_blank">[mailto:rshriram@=
cs.ubc.ca]</a> <br>

<b>Sent:</b> Monday, November 21, 2011 12:03 AM<br><b>To:</b> Michael A. Co=
llins<br><b>Cc:</b> <a href=3D"mailto:xen-devel@lists.xensource.com" target=
=3D"_blank">xen-devel@lists.xensource.com</a>; <a href=3D"mailto:xen-users@=
lists.xensource.com" target=3D"_blank">xen-users@lists.xensource.com</a><br=
>

<b>Subject:</b> Re: [Xen-devel] BLKTAP<u></u><u></u></span></p><p class=3D"=
MsoNormal"><u></u>=A0<u></u></p><div><div><div class=3D"im"><p class=3D"Mso=
Normal"><span style=3D"color:#1f497d">=85<u></u><u></u></span></p><p class=
=3D"MsoNormal">

<br>drbd/remus - why=A0 do you need blktap ?<br><br>shriram<span style=3D"c=
olor:#1f497d"><u></u><u></u></span></p><p class=3D"MsoNormal"><span style=
=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;=
;color:#1f497d"><u></u>=A0<u></u></span></p>

</div><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">From my readings, I=
 have found only a few examples of using remus.=A0 Most of them refer to us=
ing the following stanza in the disk section of a VM=92s cfg file:<u></u><u=
></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">tap2:remus:backuphost:any=
freeport|<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"fon=
t-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:=
#1f497d"><u></u>=A0</span></p>

</div></div></div></div></blockquote><div><br>Not sure if tap2 is the right=
 syntax.. there was some issue a while ago, between tap &amp; tap2<br>synta=
xes.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt=
 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1e=
x;">

<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><div><div><p class=
=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: &quot;Calibri&q=
uot;,&quot;sans-serif&quot;; color: rgb(31, 73, 125);"><u></u></span></p><p=
 class=3D"MsoNormal">

<span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-=
serif&quot;;color:#1f497d">That doesn=92t work for xl, but even using it wi=
th xm causes issues, since there isn=92t a tap device without the kernel mo=
dule.</span></p>

</div></div></div></div></blockquote><div><br>correct - so far/ <br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div link=3D"blue"=
 vlink=3D"purple" lang=3D"EN-US">

<div><div><div><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-=
family: &quot;Calibri&quot;,&quot;sans-serif&quot;; color: rgb(31, 73, 125)=
;">=A0 So I also found out that drbd uses a tap device to handle the hook i=
n with Xen, so if you want to have automagic working with block-drbd xen sc=
ripts then you have to use tap.=A0 </span></p>

</div></div></div></div></blockquote><div><br>eh? I dont think so. with drb=
d based backend for xen VMs (with or without remus),<br>you just use the dr=
bd:&lt;resourceName&gt; syntax (much like phy:...). <br>And then the block-=
drbd script in /etc/xen/scripts/ takes care of the rest of the magic.<br>

There is no tapdisk involved in this procedure. <br><br>In essence, the blo=
ck-drbd script just <br>1. parses the drbd:&lt;resourceName&gt; syntax to d=
etermine which one of <br>=A0the /dev/drbd[X] devices belong to the &lt;res=
ourceName&gt;,<br>

2. does some sanity checks<br>3. promotes &lt;resourceName&gt; in the host =
to &quot;Primary&quot; and then <br><br>the rest of the control flow happen=
s akin to a phy device, with /dev/drbd[X] being<br>supplied as the path to =
the disk backend.<br>

<br>You could do this manually too in two simple steps.<br>=A01. On the hos=
t where you want to launch the VM, promote the drbd disk to Primary<br>=A0(=
ensure that the other end is in secondary state)<br>=A02. change the VM&#39=
;s disk config to<br>

=A0phy:/dev/drbd/by-res/&lt;resourceName&gt;<br>=A0 and you are good to go.=
<br>=A0 [Though with remus, you ll have to hack the tools/python/xen/remus/=
device.py script to<br>=A0 recognize the /dev/drbd/* URI.]<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><div><div><p class=
=3D"MsoNormal"><span style=3D"font-size: 11pt; font-family: &quot;Calibri&q=
uot;,&quot;sans-serif&quot;; color: rgb(31, 73, 125);">With all that said a=
nd done, I=92m currently running drbd 8.3.11 since that=92s the version of =
the kernel module included with Linux 3.1, but I=92m just using Xen=92s phy=
 handler for the disk section of my VM=92s cfg file.<u></u><u></u></span></=
p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=
/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I see that there is a =
nice howto for debian on <a href=3D"http://remusha.wikidot.com" target=3D"_=
blank">remusha.wikidot.com</a>, but again it uses a 2.6.32 kernel from Jere=
my=92s git repo, which has the tap kernel module.=A0 I again assert that cu=
rrently there is very little out there that would help to get someone start=
ed using remus with drbd in the linux 3.1.x world.=A0 I run remus at work, =
but it=92s using shared storage and have no need to use it with drbd, but a=
t home I don=92t really want to set that up, so I thought drbd would be a n=
ice start.<u></u><u></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=
/p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I=92ve started diffing=
 the 8.3.9 branch of drbd with your changes for remus and will see how hard=
 it is to get that in the 8.3.11 version I=92m using. <u></u><u></u></span>=
</p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u></span></p></div><=
/div></div></div></blockquote><div><br>Is the remusified drbd (8.3.9) not c=
ompiling under the 3.1.x kernel anymore or are you interested in<br>

the latest version of DRBD + the remus stuff ?<br>=A0<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px =
solid rgb(204, 204, 204); padding-left: 1ex;"><div link=3D"blue" vlink=3D"p=
urple" lang=3D"EN-US">

<div><div><div><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; font-=
family: &quot;Calibri&quot;,&quot;sans-serif&quot;; color: rgb(31, 73, 125)=
;">=A0<u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11.=
0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">W=
ith that being said, I mostly use xl for everything at home, I don=92t even=
 have the xend service running, which makes matters worse, since I=92m sure=
 that most of remus uses the xend service and not the API to do the magic.=
=A0 I am willing to document my steps and post to the wiki, so that others =
could benefit from it!<u></u><u></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Mike<u></u><u></u></span>=
</p></div></div></div></div></blockquote></div><br>shriram<br>

--000e0ce0cd600288e504b24d51fc--


--===============4758066349544042571==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4758066349544042571==--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 07:18:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 07:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSkbo-0007BW-FJ; Tue, 22 Nov 2011 07:17:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSkbm-0007BR-Hy
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 07:17:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1321946216!55940826!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32228 invoked from network); 22 Nov 2011 07:16:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 07:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,551,1315180800"; 
   d="scan'208";a="9054487"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 07:17:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 07:17:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSkbO-0002L5-I9;
	Tue, 22 Nov 2011 07:17:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSkbN-0004Ma-Pv;
	Tue, 22 Nov 2011 07:17:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9955-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 07:17:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9955 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9955/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 9951 REGR. vs. 9855

Tests which are failing intermittently (not blocking):
 test-i386-i386-win           14 guest-start.2                fail pass in 9951

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9817
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check       fail in 9951 never pass

version targeted for testing:
 xen                  0a0c02a61676
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24169:0a0c02a61676
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24168:9c350ab8d3ea
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Nov 21 09:29:31 2011 +0100
    
    x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
    
    Xen itself (as much as Linux) relies on this behavior, so it should
    also emulate it properly. Not doing so reportedly gets in the way of
    kexec inside a HVM guest.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24167:335e8273a3f3
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 07:18:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 07:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSkbo-0007BW-FJ; Tue, 22 Nov 2011 07:17:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSkbm-0007BR-Hy
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 07:17:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1321946216!55940826!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32228 invoked from network); 22 Nov 2011 07:16:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 07:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,551,1315180800"; 
   d="scan'208";a="9054487"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 07:17:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 07:17:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSkbO-0002L5-I9;
	Tue, 22 Nov 2011 07:17:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSkbN-0004Ma-Pv;
	Tue, 22 Nov 2011 07:17:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9955-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 07:17:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9955 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9955/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 9951 REGR. vs. 9855

Tests which are failing intermittently (not blocking):
 test-i386-i386-win           14 guest-start.2                fail pass in 9951

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9817
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check       fail in 9951 never pass

version targeted for testing:
 xen                  0a0c02a61676
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24169:0a0c02a61676
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24168:9c350ab8d3ea
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Nov 21 09:29:31 2011 +0100
    
    x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
    
    Xen itself (as much as Linux) relies on this behavior, so it should
    also emulate it properly. Not doing so reportedly gets in the way of
    kexec inside a HVM guest.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    
    
changeset:   24167:335e8273a3f3
user:        Keir Fraser <keir@xen.org>
date:        Sat Nov 19 22:13:51 2011 +0000
    
    x86: Fix RCU locking in XENMEM_add_to_physmap.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24166:fe3e9d0c123c
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:43:26 2011 +0000
    
    iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid unnecessary iotlb flush
    
    Add cpu flag that will be checked by the iommu low level code
    to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24165:89a4d97731c5
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:46 2011 +0000
    
    hvmloader: Change memory relocation loop when overlap with PCI hole
    
    Change the way we relocate the memory page if they overlap with pci
    hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
    into xen.
    
    This code usually get triggered when a device is pass through to a
    guest and the PCI hole has to be extended to have enough room to map
    the device BARs.  The PCI hole will starts lower and it might overlap
    with some RAM that has been alocated for the guest. That usually
    happen if the guest has more than 4G of RAM.  We have to relocate
    those pages in high mem otherwise they won't be accessible.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
    
    mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
    a range of pages. The size of the range is defined in a new field.
    
    This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24163:7a9a1261a6b0
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:41:33 2011 +0000
    
    add_to_physmap: Move the code for XENMEM_add_to_physmap
    
    Move the code for the XENMEM_add_to_physmap case into it's own
    function (xenmem_add_to_physmap).
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24162:9a1a71f7bef2
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:56 2011 +0000
    
    iommu: Introduce iommu_flush and iommu_flush_all.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24161:aeb628c5af3f
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:40:19 2011 +0000
    
    vtd: Refactor iotlb flush code
    
    Factorize the iotlb flush code from map_page and unmap_page into
    it's own function.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24160:d7e6bfa114d0
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Nov 18 13:34:43 2011 +0000
    
    sched_sedf: Avoid panic when adjusting sedf parameters
    
    When using sedf scheduler in a cpupool the system might panic when
    setting sedf scheduling parameters for a domain.  Introduces
    for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
    appropriate locking in cpupool_unassign_cpu().
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24159:0965e589fdcc
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:32:50 2011 +0000
    
    hvmloader: Add configuration options to selectively disable S3 and S4 ACPI power states.
    
    Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
    S3 and S4 packages are moved into separate SSDTs and their inclusion
    is controlled by the new configuration options.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24158:4fa1c13f8bb1
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Fri Nov 18 13:31:43 2011 +0000
    
    hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
    
    Since hvmloader has a xentore client, use a platform key in xenstore
    to indicate whether ACPI is enabled or not rather than the shared
    hvm_info_table structure.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24157:7b5e1cb94bfa
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:22:45 2011 +0100
    
    x86/xsave: provide guests with finit-like environment
    
    Without the use of xsave, guests get their initial floating point
    environment set up with finit. At least NetWare actually depends on
    this (in particular on all exceptions being masked), so to be
    consistent set the same environment also when using xsave. This is
    also in line with all SSE exceptions getting masked initially.
    
    To avoid further fragile casts in xstate_alloc_save_area() the patch
    also changes xsave_struct's fpu_see member to have actually usable
    fields.
    
    The patch was tested in its technically identical, but modified-file-
    wise different 4.1.2 version.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Charles Arnold <carnold@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24156:f29b5bd6e25f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:21:24 2011 +0100
    
    x86/IRQ: prevent vector sharing within IO-APICs
    
    Following the prevention of vector sharing for MSIs, this change
    enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
    as their identifying device under the AMD IOMMU (and just like for
    MSIs, only the identifying device is used to remap interrupts here,
    with no regard to an interrupt's destination).
    
    Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
    use only the vector for identifying which interrupts to end. While this
    generally causes no significant problem (at worst an interrupt would be
    re-raised without a new interrupt event actually having occurred), it
    still seems better to avoid the situation.
    
    For this second aspect, a distinction is being made between the
    traditional and the directed-EOI cases: In the former, vectors should
    not be shared throughout all IO-APICs in the system, while in the
    latter case only individual IO-APICs need to be contrained (or, if the
    firmware indicates so, sub- groups of them having the same GSI appear
    at multiple pins).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24155:0d50e704834f
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Nov 18 09:18:41 2011 +0100
    
    x86/IO-APIC: refine EOI-ing of migrating level interrupts
    
    Rather than going through all IO-APICs and calling io_apic_eoi_vector()
    for the vector in question, just use eoi_IO_APIC_irq().
    
    This in turn allows to eliminate quite a bit of other code.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
    
    
changeset:   24154:dbdc840f8f62
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 16 18:21:14 2011 +0000
    
    elf: Fix Elf64 types and structs to match the specification.
    
    The layouts were actually correct, but the type names were a bit
    messed up.
    
    Original patch by Volker Eckert <volker.eckert@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 07:22:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 07:22:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSkgB-0007Lh-Cf; Tue, 22 Nov 2011 07:22:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSkg9-0007LQ-8x
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 07:22:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1321946496!4463489!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15379 invoked from network); 22 Nov 2011 07:21:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 07:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,551,1315180800"; 
   d="scan'208";a="9054639"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 07:21:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 07:21:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Tue, 22 Nov 2011 07:21:09 +0000
Message-ID: <1321946469.20464.12.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 00:34 +0000, Teck Choon Giam wrote:
> Hi,
> 
> This is to report that using xl create hvm domains will fail with the
> below error:
> 
> libxl: error: libxl.c:2150:libxl_set_memory_target new target 0 for
> dom0 is below the minimum threshold
> 
> However using xm create hvm domain is working fine.

Please provide you guest configuration file.

How much RAM does the host system have? What are your hypervisor and
dom0 command lines.

What is the last changeset which worked for you?

Ian.

> 
> Information about xen version:
> 
> hg_root = http://xenbits.xensource.com/staging/xen-4.1-testing.hg
> hg_changeset = 23190
> 
> dom0 kernel information:
> 
> git url = git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> git branch = xen/next-2.6.32
> git commit = faa0ece5eb2f2bc4d9b149bc46b677b1df05d332
> 
> Last known working changeset for xen-4.1-testing before upgrade is
> 23110 and I don't have chance to test other changeset.  Sorry.
> 
> Thanks.
> 
> Kindest regards,
> Giam Teck Choon
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 07:22:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 07:22:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSkgB-0007Lh-Cf; Tue, 22 Nov 2011 07:22:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSkg9-0007LQ-8x
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 07:22:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1321946496!4463489!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15379 invoked from network); 22 Nov 2011 07:21:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 07:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,551,1315180800"; 
   d="scan'208";a="9054639"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 07:21:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 07:21:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Tue, 22 Nov 2011 07:21:09 +0000
Message-ID: <1321946469.20464.12.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 00:34 +0000, Teck Choon Giam wrote:
> Hi,
> 
> This is to report that using xl create hvm domains will fail with the
> below error:
> 
> libxl: error: libxl.c:2150:libxl_set_memory_target new target 0 for
> dom0 is below the minimum threshold
> 
> However using xm create hvm domain is working fine.

Please provide you guest configuration file.

How much RAM does the host system have? What are your hypervisor and
dom0 command lines.

What is the last changeset which worked for you?

Ian.

> 
> Information about xen version:
> 
> hg_root = http://xenbits.xensource.com/staging/xen-4.1-testing.hg
> hg_changeset = 23190
> 
> dom0 kernel information:
> 
> git url = git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> git branch = xen/next-2.6.32
> git commit = faa0ece5eb2f2bc4d9b149bc46b677b1df05d332
> 
> Last known working changeset for xen-4.1-testing before upgrade is
> 23110 and I don't have chance to test other changeset.  Sorry.
> 
> Thanks.
> 
> Kindest regards,
> Giam Teck Choon
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 07:43:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 07:43:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSl05-0007fr-3H; Tue, 22 Nov 2011 07:42:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSl02-0007fm-Tw
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 07:42:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321947616!45265090!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10032 invoked from network); 22 Nov 2011 07:40:16 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 07:40:16 -0000
Received: by wwp14 with SMTP id 14so9536077wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 23:42:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Wyb2w2zBwYVu4Fwx4tRwfEXmy3Fq1HVj9hy8eqgG/40=;
	b=F2Y1fDf5zdtsUF6Haanep5SaYI/DzpsDCzDHmnvXM+u0wCln1FYxNLvTWIsd1GOfwy
	YJClNVSe7nJBrwBonkB4za6iUis0wRTz9HKhBsG4cCIZR0cYreuMqfg2QMTSSTH4HpWV
	au8DESyzLBPUzRv49h3+YEOhncPeKKIaMWjjY=
Received: by 10.227.206.147 with SMTP id fu19mr11112786wbb.22.1321947735036;
	Mon, 21 Nov 2011 23:42:15 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id 6sm2800747wby.22.2011.11.21.23.42.11
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 23:42:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 07:42:05 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAF102CD.2555F%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
Thread-Index: Acyo6jrYtMPIGC2EzECu0WLoxtRNCw==
In-Reply-To: <osstest-9955-mainreport@xen.org>
Mime-version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 07:17, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> flight 9955 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/9955/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 9951 REGR. vs.
> 9855

Could c/s 24160 be to blame?

 -- Keir

> Tests which are failing intermittently (not blocking):
>  test-i386-i386-win           14 guest-start.2                fail pass in
> 9951
> 
> Tests which did not succeed, but are not blocking,
> including regressions (tests previously passed) regarded as allowable:
>  test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like
> 9817
>  test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never
> pass
>  test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never
> pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never
> pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never
> pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never
> pass
>  test-amd64-i386-win          16 leak-check/check             fail   never
> pass
>  test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never
> pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never
> pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never
> pass
>  test-i386-i386-win           16 leak-check/check       fail in 9951 never
> pass
> 
> version targeted for testing:
>  xen                  0a0c02a61676
> baseline version:
>  xen                  dbdc840f8f62
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Andrew Cooper <andrew.cooper3@citrix.com>
>   Charles Arnold <carnold@suse.com>
>   Ian Campbell <ian.campbell@citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Jean Guyader <jean.guyader@eu.citrix.com>
>   Juergen Gross <juergen.gross@ts.fujitsu.com>
>   Keir Fraser <keir@xen.org>
>   Olaf Hering <olaf@aepfle.de>
>   Paul Durrant <paul.durrant@citrix.com>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass
>  build-i386                                                   pass
>  build-amd64-oldkern                                          pass
>  build-i386-oldkern                                           pass
>  build-amd64-pvops                                            pass
>  build-i386-pvops                                             pass
>  test-amd64-amd64-xl                                          pass
>  test-amd64-i386-xl                                           pass
>  test-i386-i386-xl                                            pass
>  test-amd64-i386-rhel6hvm-amd                                 fail
>  test-amd64-i386-xl-credit2                                   pass
>  test-amd64-amd64-xl-pcipt-intel                              fail
>  test-amd64-i386-rhel6hvm-intel                               fail
>  test-amd64-i386-xl-multivcpu                                 pass
>  test-amd64-amd64-pair                                        pass
>  test-amd64-i386-pair                                         pass
>  test-i386-i386-pair                                          pass
>  test-amd64-amd64-pv                                          pass
>  test-amd64-i386-pv                                           pass
>  test-i386-i386-pv                                            pass
>  test-amd64-amd64-xl-sedf                                     fail
>  test-amd64-i386-win-vcpus1                                   fail
>  test-amd64-i386-xl-win-vcpus1                                fail
>  test-amd64-amd64-win                                         fail
>  test-amd64-i386-win                                          fail
>  test-i386-i386-win                                           fail
>  test-amd64-amd64-xl-win                                      fail
>  test-i386-i386-xl-win                                        fail
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> ------------------------------------------------------------
> changeset:   24169:0a0c02a61676
> tag:         tip
> user:        Keir Fraser <keir@xen.org>
> date:        Mon Nov 21 21:28:34 2011 +0000
>     
>     hvmloader: Fix memory relocation loop.
>     
>     Signed-off-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24168:9c350ab8d3ea
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Mon Nov 21 09:29:31 2011 +0100
>     
>     x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
>     
>     Xen itself (as much as Linux) relies on this behavior, so it should
>     also emulate it properly. Not doing so reportedly gets in the way of
>     kexec inside a HVM guest.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Tested-by: Olaf Hering <olaf@aepfle.de>
>     
>     
> changeset:   24167:335e8273a3f3
> user:        Keir Fraser <keir@xen.org>
> date:        Sat Nov 19 22:13:51 2011 +0000
>     
>     x86: Fix RCU locking in XENMEM_add_to_physmap.
>     
>     Signed-off-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24166:fe3e9d0c123c
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:43:26 2011 +0000
>     
>     iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid
> unnecessary iotlb flush
>     
>     Add cpu flag that will be checked by the iommu low level code
>     to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24165:89a4d97731c5
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:42:46 2011 +0000
>     
>     hvmloader: Change memory relocation loop when overlap with PCI hole
>     
>     Change the way we relocate the memory page if they overlap with pci
>     hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
>     into xen.
>     
>     This code usually get triggered when a device is pass through to a
>     guest and the PCI hole has to be extended to have enough room to map
>     the device BARs.  The PCI hole will starts lower and it might overlap
>     with some RAM that has been alocated for the guest. That usually
>     happen if the guest has more than 4G of RAM.  We have to relocate
>     those pages in high mem otherwise they won't be accessible.
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24164:707d27fe03e7
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:42:08 2011 +0000
>     
>     mm: New XENMEM space, XENMAPSPACE_gmfn_range
>     
>     XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
>     a range of pages. The size of the range is defined in a new field.
>     
>     This new field .size is located in the 16 bits padding between .domid
>     and .space in struct xen_add_to_physmap to stay compatible with older
>     versions.
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24163:7a9a1261a6b0
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:41:33 2011 +0000
>     
>     add_to_physmap: Move the code for XENMEM_add_to_physmap
>     
>     Move the code for the XENMEM_add_to_physmap case into it's own
>     function (xenmem_add_to_physmap).
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24162:9a1a71f7bef2
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:40:56 2011 +0000
>     
>     iommu: Introduce iommu_flush and iommu_flush_all.
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24161:aeb628c5af3f
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:40:19 2011 +0000
>     
>     vtd: Refactor iotlb flush code
>     
>     Factorize the iotlb flush code from map_page and unmap_page into
>     it's own function.
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24160:d7e6bfa114d0
> user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
> date:        Fri Nov 18 13:34:43 2011 +0000
>     
>     sched_sedf: Avoid panic when adjusting sedf parameters
>     
>     When using sedf scheduler in a cpupool the system might panic when
>     setting sedf scheduling parameters for a domain.  Introduces
>     for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
>     appropriate locking in cpupool_unassign_cpu().
>     
>     Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24159:0965e589fdcc
> user:        Paul Durrant <paul.durrant@citrix.com>
> date:        Fri Nov 18 13:32:50 2011 +0000
>     
>     hvmloader: Add configuration options to selectively disable S3 and S4 ACPI
> power states.
>     
>     Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
>     S3 and S4 packages are moved into separate SSDTs and their inclusion
>     is controlled by the new configuration options.
>     
>     Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24158:4fa1c13f8bb1
> user:        Paul Durrant <paul.durrant@citrix.com>
> date:        Fri Nov 18 13:31:43 2011 +0000
>     
>     hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
>     
>     Since hvmloader has a xentore client, use a platform key in xenstore
>     to indicate whether ACPI is enabled or not rather than the shared
>     hvm_info_table structure.
>     
>     Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24157:7b5e1cb94bfa
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Nov 18 09:22:45 2011 +0100
>     
>     x86/xsave: provide guests with finit-like environment
>     
>     Without the use of xsave, guests get their initial floating point
>     environment set up with finit. At least NetWare actually depends on
>     this (in particular on all exceptions being masked), so to be
>     consistent set the same environment also when using xsave. This is
>     also in line with all SSE exceptions getting masked initially.
>     
>     To avoid further fragile casts in xstate_alloc_save_area() the patch
>     also changes xsave_struct's fpu_see member to have actually usable
>     fields.
>     
>     The patch was tested in its technically identical, but modified-file-
>     wise different 4.1.2 version.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Tested-by: Charles Arnold <carnold@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24156:f29b5bd6e25f
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Nov 18 09:21:24 2011 +0100
>     
>     x86/IRQ: prevent vector sharing within IO-APICs
>     
>     Following the prevention of vector sharing for MSIs, this change
>     enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
>     as their identifying device under the AMD IOMMU (and just like for
>     MSIs, only the identifying device is used to remap interrupts here,
>     with no regard to an interrupt's destination).
>     
>     Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
>     use only the vector for identifying which interrupts to end. While this
>     generally causes no significant problem (at worst an interrupt would be
>     re-raised without a new interrupt event actually having occurred), it
>     still seems better to avoid the situation.
>     
>     For this second aspect, a distinction is being made between the
>     traditional and the directed-EOI cases: In the former, vectors should
>     not be shared throughout all IO-APICs in the system, while in the
>     latter case only individual IO-APICs need to be contrained (or, if the
>     firmware indicates so, sub- groups of them having the same GSI appear
>     at multiple pins).
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>     
>     
> changeset:   24155:0d50e704834f
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Nov 18 09:18:41 2011 +0100
>     
>     x86/IO-APIC: refine EOI-ing of migrating level interrupts
>     
>     Rather than going through all IO-APICs and calling io_apic_eoi_vector()
>     for the vector in question, just use eoi_IO_APIC_irq().
>     
>     This in turn allows to eliminate quite a bit of other code.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>     Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>     
>     
> changeset:   24154:dbdc840f8f62
> user:        Keir Fraser <keir@xen.org>
> date:        Wed Nov 16 18:21:14 2011 +0000
>     
>     elf: Fix Elf64 types and structs to match the specification.
>     
>     The layouts were actually correct, but the type names were a bit
>     messed up.
>     
>     Original patch by Volker Eckert <volker.eckert@citrix.com>
>     Signed-off-by: Keir Fraser <keir@xen.org>
>     
>     
> ========================================
> commit 52834188eedfbbca5636fd869d4c86b3b3044439
> Author: Ian Campbell <ian.campbell@citrix.com>
> Date:   Tue Nov 1 18:42:55 2011 +0000
> 
>     qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
>     
>     I have just proposed a patch to add this to xen-unstable.hg as
>     docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where
> people
>     look for docs, plus we are transitioning to upstream qemu.
>     
>     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 07:43:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 07:43:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSl05-0007fr-3H; Tue, 22 Nov 2011 07:42:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSl02-0007fm-Tw
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 07:42:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321947616!45265090!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10032 invoked from network); 22 Nov 2011 07:40:16 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 07:40:16 -0000
Received: by wwp14 with SMTP id 14so9536077wwp.24
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 23:42:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Wyb2w2zBwYVu4Fwx4tRwfEXmy3Fq1HVj9hy8eqgG/40=;
	b=F2Y1fDf5zdtsUF6Haanep5SaYI/DzpsDCzDHmnvXM+u0wCln1FYxNLvTWIsd1GOfwy
	YJClNVSe7nJBrwBonkB4za6iUis0wRTz9HKhBsG4cCIZR0cYreuMqfg2QMTSSTH4HpWV
	au8DESyzLBPUzRv49h3+YEOhncPeKKIaMWjjY=
Received: by 10.227.206.147 with SMTP id fu19mr11112786wbb.22.1321947735036;
	Mon, 21 Nov 2011 23:42:15 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id 6sm2800747wby.22.2011.11.21.23.42.11
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 23:42:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 07:42:05 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAF102CD.2555F%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
Thread-Index: Acyo6jrYtMPIGC2EzECu0WLoxtRNCw==
In-Reply-To: <osstest-9955-mainreport@xen.org>
Mime-version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 07:17, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> flight 9955 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/9955/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 9951 REGR. vs.
> 9855

Could c/s 24160 be to blame?

 -- Keir

> Tests which are failing intermittently (not blocking):
>  test-i386-i386-win           14 guest-start.2                fail pass in
> 9951
> 
> Tests which did not succeed, but are not blocking,
> including regressions (tests previously passed) regarded as allowable:
>  test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like
> 9817
>  test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never
> pass
>  test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never
> pass
>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never
> pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never
> pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never
> pass
>  test-amd64-i386-win          16 leak-check/check             fail   never
> pass
>  test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never
> pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never
> pass
>  test-amd64-amd64-win         16 leak-check/check             fail   never
> pass
>  test-i386-i386-win           16 leak-check/check       fail in 9951 never
> pass
> 
> version targeted for testing:
>  xen                  0a0c02a61676
> baseline version:
>  xen                  dbdc840f8f62
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Andrew Cooper <andrew.cooper3@citrix.com>
>   Charles Arnold <carnold@suse.com>
>   Ian Campbell <ian.campbell@citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Jean Guyader <jean.guyader@eu.citrix.com>
>   Juergen Gross <juergen.gross@ts.fujitsu.com>
>   Keir Fraser <keir@xen.org>
>   Olaf Hering <olaf@aepfle.de>
>   Paul Durrant <paul.durrant@citrix.com>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  pass
>  build-i386                                                   pass
>  build-amd64-oldkern                                          pass
>  build-i386-oldkern                                           pass
>  build-amd64-pvops                                            pass
>  build-i386-pvops                                             pass
>  test-amd64-amd64-xl                                          pass
>  test-amd64-i386-xl                                           pass
>  test-i386-i386-xl                                            pass
>  test-amd64-i386-rhel6hvm-amd                                 fail
>  test-amd64-i386-xl-credit2                                   pass
>  test-amd64-amd64-xl-pcipt-intel                              fail
>  test-amd64-i386-rhel6hvm-intel                               fail
>  test-amd64-i386-xl-multivcpu                                 pass
>  test-amd64-amd64-pair                                        pass
>  test-amd64-i386-pair                                         pass
>  test-i386-i386-pair                                          pass
>  test-amd64-amd64-pv                                          pass
>  test-amd64-i386-pv                                           pass
>  test-i386-i386-pv                                            pass
>  test-amd64-amd64-xl-sedf                                     fail
>  test-amd64-i386-win-vcpus1                                   fail
>  test-amd64-i386-xl-win-vcpus1                                fail
>  test-amd64-amd64-win                                         fail
>  test-amd64-i386-win                                          fail
>  test-i386-i386-win                                           fail
>  test-amd64-amd64-xl-win                                      fail
>  test-i386-i386-xl-win                                        fail
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> ------------------------------------------------------------
> changeset:   24169:0a0c02a61676
> tag:         tip
> user:        Keir Fraser <keir@xen.org>
> date:        Mon Nov 21 21:28:34 2011 +0000
>     
>     hvmloader: Fix memory relocation loop.
>     
>     Signed-off-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24168:9c350ab8d3ea
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Mon Nov 21 09:29:31 2011 +0100
>     
>     x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
>     
>     Xen itself (as much as Linux) relies on this behavior, so it should
>     also emulate it properly. Not doing so reportedly gets in the way of
>     kexec inside a HVM guest.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Tested-by: Olaf Hering <olaf@aepfle.de>
>     
>     
> changeset:   24167:335e8273a3f3
> user:        Keir Fraser <keir@xen.org>
> date:        Sat Nov 19 22:13:51 2011 +0000
>     
>     x86: Fix RCU locking in XENMEM_add_to_physmap.
>     
>     Signed-off-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24166:fe3e9d0c123c
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:43:26 2011 +0000
>     
>     iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid
> unnecessary iotlb flush
>     
>     Add cpu flag that will be checked by the iommu low level code
>     to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24165:89a4d97731c5
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:42:46 2011 +0000
>     
>     hvmloader: Change memory relocation loop when overlap with PCI hole
>     
>     Change the way we relocate the memory page if they overlap with pci
>     hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
>     into xen.
>     
>     This code usually get triggered when a device is pass through to a
>     guest and the PCI hole has to be extended to have enough room to map
>     the device BARs.  The PCI hole will starts lower and it might overlap
>     with some RAM that has been alocated for the guest. That usually
>     happen if the guest has more than 4G of RAM.  We have to relocate
>     those pages in high mem otherwise they won't be accessible.
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24164:707d27fe03e7
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:42:08 2011 +0000
>     
>     mm: New XENMEM space, XENMAPSPACE_gmfn_range
>     
>     XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
>     a range of pages. The size of the range is defined in a new field.
>     
>     This new field .size is located in the 16 bits padding between .domid
>     and .space in struct xen_add_to_physmap to stay compatible with older
>     versions.
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24163:7a9a1261a6b0
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:41:33 2011 +0000
>     
>     add_to_physmap: Move the code for XENMEM_add_to_physmap
>     
>     Move the code for the XENMEM_add_to_physmap case into it's own
>     function (xenmem_add_to_physmap).
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24162:9a1a71f7bef2
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:40:56 2011 +0000
>     
>     iommu: Introduce iommu_flush and iommu_flush_all.
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24161:aeb628c5af3f
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:40:19 2011 +0000
>     
>     vtd: Refactor iotlb flush code
>     
>     Factorize the iotlb flush code from map_page and unmap_page into
>     it's own function.
>     
>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24160:d7e6bfa114d0
> user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
> date:        Fri Nov 18 13:34:43 2011 +0000
>     
>     sched_sedf: Avoid panic when adjusting sedf parameters
>     
>     When using sedf scheduler in a cpupool the system might panic when
>     setting sedf scheduling parameters for a domain.  Introduces
>     for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
>     appropriate locking in cpupool_unassign_cpu().
>     
>     Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24159:0965e589fdcc
> user:        Paul Durrant <paul.durrant@citrix.com>
> date:        Fri Nov 18 13:32:50 2011 +0000
>     
>     hvmloader: Add configuration options to selectively disable S3 and S4 ACPI
> power states.
>     
>     Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
>     S3 and S4 packages are moved into separate SSDTs and their inclusion
>     is controlled by the new configuration options.
>     
>     Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24158:4fa1c13f8bb1
> user:        Paul Durrant <paul.durrant@citrix.com>
> date:        Fri Nov 18 13:31:43 2011 +0000
>     
>     hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
>     
>     Since hvmloader has a xentore client, use a platform key in xenstore
>     to indicate whether ACPI is enabled or not rather than the shared
>     hvm_info_table structure.
>     
>     Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24157:7b5e1cb94bfa
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Nov 18 09:22:45 2011 +0100
>     
>     x86/xsave: provide guests with finit-like environment
>     
>     Without the use of xsave, guests get their initial floating point
>     environment set up with finit. At least NetWare actually depends on
>     this (in particular on all exceptions being masked), so to be
>     consistent set the same environment also when using xsave. This is
>     also in line with all SSE exceptions getting masked initially.
>     
>     To avoid further fragile casts in xstate_alloc_save_area() the patch
>     also changes xsave_struct's fpu_see member to have actually usable
>     fields.
>     
>     The patch was tested in its technically identical, but modified-file-
>     wise different 4.1.2 version.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Tested-by: Charles Arnold <carnold@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   24156:f29b5bd6e25f
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Nov 18 09:21:24 2011 +0100
>     
>     x86/IRQ: prevent vector sharing within IO-APICs
>     
>     Following the prevention of vector sharing for MSIs, this change
>     enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
>     as their identifying device under the AMD IOMMU (and just like for
>     MSIs, only the identifying device is used to remap interrupts here,
>     with no regard to an interrupt's destination).
>     
>     Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
>     use only the vector for identifying which interrupts to end. While this
>     generally causes no significant problem (at worst an interrupt would be
>     re-raised without a new interrupt event actually having occurred), it
>     still seems better to avoid the situation.
>     
>     For this second aspect, a distinction is being made between the
>     traditional and the directed-EOI cases: In the former, vectors should
>     not be shared throughout all IO-APICs in the system, while in the
>     latter case only individual IO-APICs need to be contrained (or, if the
>     firmware indicates so, sub- groups of them having the same GSI appear
>     at multiple pins).
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>     
>     
> changeset:   24155:0d50e704834f
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Nov 18 09:18:41 2011 +0100
>     
>     x86/IO-APIC: refine EOI-ing of migrating level interrupts
>     
>     Rather than going through all IO-APICs and calling io_apic_eoi_vector()
>     for the vector in question, just use eoi_IO_APIC_irq().
>     
>     This in turn allows to eliminate quite a bit of other code.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>     Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>     
>     
> changeset:   24154:dbdc840f8f62
> user:        Keir Fraser <keir@xen.org>
> date:        Wed Nov 16 18:21:14 2011 +0000
>     
>     elf: Fix Elf64 types and structs to match the specification.
>     
>     The layouts were actually correct, but the type names were a bit
>     messed up.
>     
>     Original patch by Volker Eckert <volker.eckert@citrix.com>
>     Signed-off-by: Keir Fraser <keir@xen.org>
>     
>     
> ========================================
> commit 52834188eedfbbca5636fd869d4c86b3b3044439
> Author: Ian Campbell <ian.campbell@citrix.com>
> Date:   Tue Nov 1 18:42:55 2011 +0000
> 
>     qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
>     
>     I have just proposed a patch to add this to xen-unstable.hg as
>     docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where
> people
>     look for docs, plus we are transitioning to upstream qemu.
>     
>     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 07:47:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 07:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSl42-0007nP-UN; Tue, 22 Nov 2011 07:46:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSl41-0007n7-4v
	for Xen-devel@lists.xensource.com; Tue, 22 Nov 2011 07:46:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321947976!4074430!1
X-Originating-IP: [74.125.82.41]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15702 invoked from network); 22 Nov 2011 07:46:16 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 07:46:16 -0000
Received: by wwf25 with SMTP id 25so6673727wwf.0
	for <Xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 23:46:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ubBpZ+oVDy9Ig0PU8e2ibIjJ3v2OyaJxiGwgFwPFeAQ=;
	b=hAwVSZ1A6Hk8tkRvXJqAH8KVu93jjOrhLoZDxqJn1gje4z/Z57IcE6Z+calPfPtBKK
	LGR2oEuSnFvCBT5rn9nfe6q4bP2bbg20hWfmdAoV5P3T7tywoGTmq0zPUliVFRNU/EEu
	/QnBo5UfmIUVmc6FwsJWSwuu6p94S0BRAMhqE=
Received: by 10.216.132.208 with SMTP id o58mr1811884wei.9.1321947976281;
	Mon, 21 Nov 2011 23:46:16 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id c2sm15694181wbo.3.2011.11.21.23.46.11
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 23:46:15 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 07:46:09 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <CAF103C1.25562%keir.xen@gmail.com>
Thread-Topic: __vmptrst() broken...
Thread-Index: Acyo6sxInBAY8KlwZkKIYBCxViZS8w==
In-Reply-To: <20111121184743.281f8364@mantra.us.oracle.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] __vmptrst() broken...
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 02:47, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> Hi Keir,
> 
> __vmptrst() seems broken. It is:
> 
> static inline void __vmptrst(u64 addr)
> {
>     asm volatile ( VMPTRST_OPCODE
>                    MODRM_EAX_07
>                    :
>                    : "a" (&addr)
>                    : "memory");
> }
> 
> 
> should be:
> 
> static inline void __vmptrst(u64 *addr)
> {           
>     asm volatile ( VMPTRST_OPCODE
>                    MODRM_EAX_07
>                    :
>                    : "a" (addr)
>                    : "memory");
> }   
> 
> 
> 
> Do you think you can just fix it in one of your changes without
> official patch?

It's obviously not used. It's probably not even useful (we know what VMCS we
last loaded). I'll just remove it.

 -- Keir

> thanks much,
> Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 07:47:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 07:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSl42-0007nP-UN; Tue, 22 Nov 2011 07:46:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSl41-0007n7-4v
	for Xen-devel@lists.xensource.com; Tue, 22 Nov 2011 07:46:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321947976!4074430!1
X-Originating-IP: [74.125.82.41]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15702 invoked from network); 22 Nov 2011 07:46:16 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 07:46:16 -0000
Received: by wwf25 with SMTP id 25so6673727wwf.0
	for <Xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 23:46:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ubBpZ+oVDy9Ig0PU8e2ibIjJ3v2OyaJxiGwgFwPFeAQ=;
	b=hAwVSZ1A6Hk8tkRvXJqAH8KVu93jjOrhLoZDxqJn1gje4z/Z57IcE6Z+calPfPtBKK
	LGR2oEuSnFvCBT5rn9nfe6q4bP2bbg20hWfmdAoV5P3T7tywoGTmq0zPUliVFRNU/EEu
	/QnBo5UfmIUVmc6FwsJWSwuu6p94S0BRAMhqE=
Received: by 10.216.132.208 with SMTP id o58mr1811884wei.9.1321947976281;
	Mon, 21 Nov 2011 23:46:16 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id c2sm15694181wbo.3.2011.11.21.23.46.11
	(version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 23:46:15 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 07:46:09 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <CAF103C1.25562%keir.xen@gmail.com>
Thread-Topic: __vmptrst() broken...
Thread-Index: Acyo6sxInBAY8KlwZkKIYBCxViZS8w==
In-Reply-To: <20111121184743.281f8364@mantra.us.oracle.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] __vmptrst() broken...
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 02:47, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:

> Hi Keir,
> 
> __vmptrst() seems broken. It is:
> 
> static inline void __vmptrst(u64 addr)
> {
>     asm volatile ( VMPTRST_OPCODE
>                    MODRM_EAX_07
>                    :
>                    : "a" (&addr)
>                    : "memory");
> }
> 
> 
> should be:
> 
> static inline void __vmptrst(u64 *addr)
> {           
>     asm volatile ( VMPTRST_OPCODE
>                    MODRM_EAX_07
>                    :
>                    : "a" (addr)
>                    : "memory");
> }   
> 
> 
> 
> Do you think you can just fix it in one of your changes without
> official patch?

It's obviously not used. It's probably not even useful (we know what VMCS we
last loaded). I'll just remove it.

 -- Keir

> thanks much,
> Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 07:57:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 07:57:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlDs-00080r-4Z; Tue, 22 Nov 2011 07:56:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSlDq-00080m-Ev
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 07:56:54 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321948561!45524266!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12668 invoked from network); 22 Nov 2011 07:56:03 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 07:56:03 -0000
Received: by ghbz2 with SMTP id z2so577802ghb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 23:56:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=SadhgwtdoEPsbUU3NDrYMl5UINujlOJCyuWvP6iuyss=;
	b=o/3QjFm0Cl9Sw6az6d0yPGvGi8AM7XeeBrdVnF4d7Vd+u5Jz075fnGw04VezNaJJHf
	AUOMLEHpOP2TkVNZmpXq4VN24TyGU/lueYZcaN+tabYRojhj4SQ1U3srb/oWAw7nKUku
	LtIX1D6bR9br1u5ah3C7GCOnKBwiWeq6TKQmI=
MIME-Version: 1.0
Received: by 10.68.12.97 with SMTP id x1mr43095609pbb.78.1321948585006; Mon,
	21 Nov 2011 23:56:25 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Mon, 21 Nov 2011 23:56:24 -0800 (PST)
In-Reply-To: <1321946469.20464.12.camel@dagon.hellion.org.uk>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
Date: Tue, 22 Nov 2011 15:56:24 +0800
Message-ID: <CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian,

Thanks for your prompt reply.

On Tue, Nov 22, 2011 at 3:21 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Tue, 2011-11-22 at 00:34 +0000, Teck Choon Giam wrote:
>> Hi,
>>
>> This is to report that using xl create hvm domains will fail with the
>> below error:
>>
>> libxl: error: libxl.c:2150:libxl_set_memory_target new target 0 for
>> dom0 is below the minimum threshold
>>
>> However using xm create hvm domain is working fine.
>
> Please provide you guest configuration file.

Example as below as I just replace those with X:

kernel =3D "/usr/lib/xen/boot/hvmloader"
builder =3D 'hvm'
shadow_memory =3D 32
memory =3D 15360
maxmem =3D 15360
name =3D "XXX"
vif =3D [ 'type=3Dioemu,mac=3DXX:XX:XX:XX:XX:XX,bridge=3Dxenbr0,ip=3DXXX.XX=
X.XXX.XXX',
'type=3Dioemu,mac=3DXX:XX:XX:XX:XX:XX,bridge=3Dxenbr1,ip=3DXXX.XXX.XXX.XXX'=
 ]
disk =3D [ 'phy:/dev/XenGroup/XXX,ioemu:hda,w' ]
vmid=3D1
vcpus=3D4
ne2000=3D0
boot=3D'cd'
sdl=3D0
vncviewer=3D0
vncpasswd=3D'XXXXXXX'
vnclisten=3D"XXX.XXX.XXX.XXX"
vnc=3D1
vncdisplay=3D1
vncunused=3D0
usbdevice=3D'tablet'
acpi=3D1
viridian=3D1
localtime=3D1


>
> How much RAM does the host system have? What are your hypervisor and
> dom0 command lines.

16GB RAM.

title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
	root (hd0,0)
	kernel /xen.gz dom0_mem=3D512M loglvl=3Dall guest_loglvl=3Dall cpuidle=3D0=
 cpufreq=3Dnone
	module /vmlinuz-2.6.32.47-0.xen.pvops.choon.sl6 ro
root=3DUUID=3D154127e6-9469-4124-9a42-1f6c6160adf4
rd_MD_UUID=3Dd5126687:736a76db:5d5f597f:8b16fad4 rd_NO_LUKS rd_NO_LVM
rd_NO_DM LANG=3Den_US.UTF-8 SYSFONT=3Dlatarcyrheb-sun16 KEYBOARDTYPE=3Dpc
KEYTABLE=3Dus crashkernel=3Dauto rhgb quiet panic=3D5 panic_timeout=3D10
	module /initramfs-2.6.32.47-0.xen.pvops.choon.sl6.img

>
> What is the last changeset which worked for you?

I did provide last working changeset is 23110 in my initial email.

>
> Ian.

Thanks.

Kindest regards,
Giam Teck Choon

>
>>
>> Information about xen version:
>>
>> hg_root =3D http://xenbits.xensource.com/staging/xen-4.1-testing.hg
>> hg_changeset =3D 23190
>>
>> dom0 kernel information:
>>
>> git url =3D git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
>> git branch =3D xen/next-2.6.32
>> git commit =3D faa0ece5eb2f2bc4d9b149bc46b677b1df05d332
>>
>> Last known working changeset for xen-4.1-testing before upgrade is
>> 23110 and I don't have chance to test other changeset. =A0Sorry.
>>
>> Thanks.
>>
>> Kindest regards,
>> Giam Teck Choon
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 07:57:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 07:57:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlDs-00080r-4Z; Tue, 22 Nov 2011 07:56:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSlDq-00080m-Ev
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 07:56:54 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321948561!45524266!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12668 invoked from network); 22 Nov 2011 07:56:03 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 07:56:03 -0000
Received: by ghbz2 with SMTP id z2so577802ghb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 23:56:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=SadhgwtdoEPsbUU3NDrYMl5UINujlOJCyuWvP6iuyss=;
	b=o/3QjFm0Cl9Sw6az6d0yPGvGi8AM7XeeBrdVnF4d7Vd+u5Jz075fnGw04VezNaJJHf
	AUOMLEHpOP2TkVNZmpXq4VN24TyGU/lueYZcaN+tabYRojhj4SQ1U3srb/oWAw7nKUku
	LtIX1D6bR9br1u5ah3C7GCOnKBwiWeq6TKQmI=
MIME-Version: 1.0
Received: by 10.68.12.97 with SMTP id x1mr43095609pbb.78.1321948585006; Mon,
	21 Nov 2011 23:56:25 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Mon, 21 Nov 2011 23:56:24 -0800 (PST)
In-Reply-To: <1321946469.20464.12.camel@dagon.hellion.org.uk>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
Date: Tue, 22 Nov 2011 15:56:24 +0800
Message-ID: <CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian,

Thanks for your prompt reply.

On Tue, Nov 22, 2011 at 3:21 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Tue, 2011-11-22 at 00:34 +0000, Teck Choon Giam wrote:
>> Hi,
>>
>> This is to report that using xl create hvm domains will fail with the
>> below error:
>>
>> libxl: error: libxl.c:2150:libxl_set_memory_target new target 0 for
>> dom0 is below the minimum threshold
>>
>> However using xm create hvm domain is working fine.
>
> Please provide you guest configuration file.

Example as below as I just replace those with X:

kernel =3D "/usr/lib/xen/boot/hvmloader"
builder =3D 'hvm'
shadow_memory =3D 32
memory =3D 15360
maxmem =3D 15360
name =3D "XXX"
vif =3D [ 'type=3Dioemu,mac=3DXX:XX:XX:XX:XX:XX,bridge=3Dxenbr0,ip=3DXXX.XX=
X.XXX.XXX',
'type=3Dioemu,mac=3DXX:XX:XX:XX:XX:XX,bridge=3Dxenbr1,ip=3DXXX.XXX.XXX.XXX'=
 ]
disk =3D [ 'phy:/dev/XenGroup/XXX,ioemu:hda,w' ]
vmid=3D1
vcpus=3D4
ne2000=3D0
boot=3D'cd'
sdl=3D0
vncviewer=3D0
vncpasswd=3D'XXXXXXX'
vnclisten=3D"XXX.XXX.XXX.XXX"
vnc=3D1
vncdisplay=3D1
vncunused=3D0
usbdevice=3D'tablet'
acpi=3D1
viridian=3D1
localtime=3D1


>
> How much RAM does the host system have? What are your hypervisor and
> dom0 command lines.

16GB RAM.

title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
	root (hd0,0)
	kernel /xen.gz dom0_mem=3D512M loglvl=3Dall guest_loglvl=3Dall cpuidle=3D0=
 cpufreq=3Dnone
	module /vmlinuz-2.6.32.47-0.xen.pvops.choon.sl6 ro
root=3DUUID=3D154127e6-9469-4124-9a42-1f6c6160adf4
rd_MD_UUID=3Dd5126687:736a76db:5d5f597f:8b16fad4 rd_NO_LUKS rd_NO_LVM
rd_NO_DM LANG=3Den_US.UTF-8 SYSFONT=3Dlatarcyrheb-sun16 KEYBOARDTYPE=3Dpc
KEYTABLE=3Dus crashkernel=3Dauto rhgb quiet panic=3D5 panic_timeout=3D10
	module /initramfs-2.6.32.47-0.xen.pvops.choon.sl6.img

>
> What is the last changeset which worked for you?

I did provide last working changeset is 23110 in my initial email.

>
> Ian.

Thanks.

Kindest regards,
Giam Teck Choon

>
>>
>> Information about xen version:
>>
>> hg_root =3D http://xenbits.xensource.com/staging/xen-4.1-testing.hg
>> hg_changeset =3D 23190
>>
>> dom0 kernel information:
>>
>> git url =3D git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
>> git branch =3D xen/next-2.6.32
>> git commit =3D faa0ece5eb2f2bc4d9b149bc46b677b1df05d332
>>
>> Last known working changeset for xen-4.1-testing before upgrade is
>> 23110 and I don't have chance to test other changeset. =A0Sorry.
>>
>> Thanks.
>>
>> Kindest regards,
>> Giam Teck Choon
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:14:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlUl-0000Ft-OJ; Tue, 22 Nov 2011 08:14:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSlUk-0000Fk-9j
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:14:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321949633!4095579!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30950 invoked from network); 22 Nov 2011 08:13:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 08:13:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 22 Nov 2011 08:13:53 +0000
Message-Id: <4ECB67CF0200007800062465@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 22 Nov 2011 08:13:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <osstest-9955-mainreport@xen.org>
	<CAF102CD.2555F%keir.xen@gmail.com>
In-Reply-To: <CAF102CD.2555F%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 08:42, Keir Fraser <keir.xen@gmail.com> wrote:
> On 22/11/2011 07:17, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> 
>> flight 9955 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/9955/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking:
>>  test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 9951 REGR. vs.
>> 9855
> 
> Could c/s 24160 be to blame?

I don't think so - the sedf thing (with varying sub-tests iirc) has been
(inconsistently) failing for quite a long while.

Further, here this test wasn't even run because xen-boot (below)
failed. And no matter how many times I looked at the respective
logs, I wasn't able to spot what it really is that fails here. I can only
assume that Dom0 is hung, but my sedf knowledge doesn't go far
enough to tell that for sure from the dumped data.

Jan

>> Tests which are failing intermittently (not blocking):
>>  test-i386-i386-win           14 guest-start.2                fail pass in
>> 9951
>> 
>> Tests which did not succeed, but are not blocking,
>> including regressions (tests previously passed) regarded as allowable:
>>  test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like
>> 9817
>>  test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never
>> pass
>>  test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never
>> pass
>>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never
>> pass
>>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never
>> pass
>>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never
>> pass
>>  test-amd64-i386-win          16 leak-check/check             fail   never
>> pass
>>  test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never
>> pass
>>  test-i386-i386-xl-win        13 guest-stop                   fail   never
>> pass
>>  test-amd64-amd64-win         16 leak-check/check             fail   never
>> pass
>>  test-i386-i386-win           16 leak-check/check       fail in 9951 never
>> pass
>> 
>> version targeted for testing:
>>  xen                  0a0c02a61676
>> baseline version:
>>  xen                  dbdc840f8f62
>> 
>> ------------------------------------------------------------
>> People who touched revisions under test:
>>   Andrew Cooper <andrew.cooper3@citrix.com>
>>   Charles Arnold <carnold@suse.com>
>>   Ian Campbell <ian.campbell@citrix.com>
>>   Jan Beulich <jbeulich@suse.com>
>>   Jean Guyader <jean.guyader@eu.citrix.com>
>>   Juergen Gross <juergen.gross@ts.fujitsu.com>
>>   Keir Fraser <keir@xen.org>
>>   Olaf Hering <olaf@aepfle.de>
>>   Paul Durrant <paul.durrant@citrix.com>
>> ------------------------------------------------------------
>> 
>> jobs:
>>  build-amd64                                                  pass
>>  build-i386                                                   pass
>>  build-amd64-oldkern                                          pass
>>  build-i386-oldkern                                           pass
>>  build-amd64-pvops                                            pass
>>  build-i386-pvops                                             pass
>>  test-amd64-amd64-xl                                          pass
>>  test-amd64-i386-xl                                           pass
>>  test-i386-i386-xl                                            pass
>>  test-amd64-i386-rhel6hvm-amd                                 fail
>>  test-amd64-i386-xl-credit2                                   pass
>>  test-amd64-amd64-xl-pcipt-intel                              fail
>>  test-amd64-i386-rhel6hvm-intel                               fail
>>  test-amd64-i386-xl-multivcpu                                 pass
>>  test-amd64-amd64-pair                                        pass
>>  test-amd64-i386-pair                                         pass
>>  test-i386-i386-pair                                          pass
>>  test-amd64-amd64-pv                                          pass
>>  test-amd64-i386-pv                                           pass
>>  test-i386-i386-pv                                            pass
>>  test-amd64-amd64-xl-sedf                                     fail
>>  test-amd64-i386-win-vcpus1                                   fail
>>  test-amd64-i386-xl-win-vcpus1                                fail
>>  test-amd64-amd64-win                                         fail
>>  test-amd64-i386-win                                          fail
>>  test-i386-i386-win                                           fail
>>  test-amd64-amd64-xl-win                                      fail
>>  test-i386-i386-xl-win                                        fail
>> 
>> 
>> ------------------------------------------------------------
>> sg-report-flight on woking.cam.xci-test.com
>> logs: /home/xc_osstest/logs
>> images: /home/xc_osstest/images
>> 
>> Logs, config files, etc. are available at
>>     http://www.chiark.greenend.org.uk/~xensrcts/logs 
>> 
>> Test harness code can be found at
>>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary 
>> 
>> 
>> Not pushing.
>> 
>> ------------------------------------------------------------
>> changeset:   24169:0a0c02a61676
>> tag:         tip
>> user:        Keir Fraser <keir@xen.org>
>> date:        Mon Nov 21 21:28:34 2011 +0000
>>     
>>     hvmloader: Fix memory relocation loop.
>>     
>>     Signed-off-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24168:9c350ab8d3ea
>> user:        Jan Beulich <jbeulich@suse.com>
>> date:        Mon Nov 21 09:29:31 2011 +0100
>>     
>>     x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
>>     
>>     Xen itself (as much as Linux) relies on this behavior, so it should
>>     also emulate it properly. Not doing so reportedly gets in the way of
>>     kexec inside a HVM guest.
>>     
>>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>     Tested-by: Olaf Hering <olaf@aepfle.de>
>>     
>>     
>> changeset:   24167:335e8273a3f3
>> user:        Keir Fraser <keir@xen.org>
>> date:        Sat Nov 19 22:13:51 2011 +0000
>>     
>>     x86: Fix RCU locking in XENMEM_add_to_physmap.
>>     
>>     Signed-off-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24166:fe3e9d0c123c
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:43:26 2011 +0000
>>     
>>     iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid
>> unnecessary iotlb flush
>>     
>>     Add cpu flag that will be checked by the iommu low level code
>>     to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24165:89a4d97731c5
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:42:46 2011 +0000
>>     
>>     hvmloader: Change memory relocation loop when overlap with PCI hole
>>     
>>     Change the way we relocate the memory page if they overlap with pci
>>     hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
>>     into xen.
>>     
>>     This code usually get triggered when a device is pass through to a
>>     guest and the PCI hole has to be extended to have enough room to map
>>     the device BARs.  The PCI hole will starts lower and it might overlap
>>     with some RAM that has been alocated for the guest. That usually
>>     happen if the guest has more than 4G of RAM.  We have to relocate
>>     those pages in high mem otherwise they won't be accessible.
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24164:707d27fe03e7
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:42:08 2011 +0000
>>     
>>     mm: New XENMEM space, XENMAPSPACE_gmfn_range
>>     
>>     XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
>>     a range of pages. The size of the range is defined in a new field.
>>     
>>     This new field .size is located in the 16 bits padding between .domid
>>     and .space in struct xen_add_to_physmap to stay compatible with older
>>     versions.
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24163:7a9a1261a6b0
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:41:33 2011 +0000
>>     
>>     add_to_physmap: Move the code for XENMEM_add_to_physmap
>>     
>>     Move the code for the XENMEM_add_to_physmap case into it's own
>>     function (xenmem_add_to_physmap).
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24162:9a1a71f7bef2
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:40:56 2011 +0000
>>     
>>     iommu: Introduce iommu_flush and iommu_flush_all.
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24161:aeb628c5af3f
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:40:19 2011 +0000
>>     
>>     vtd: Refactor iotlb flush code
>>     
>>     Factorize the iotlb flush code from map_page and unmap_page into
>>     it's own function.
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24160:d7e6bfa114d0
>> user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
>> date:        Fri Nov 18 13:34:43 2011 +0000
>>     
>>     sched_sedf: Avoid panic when adjusting sedf parameters
>>     
>>     When using sedf scheduler in a cpupool the system might panic when
>>     setting sedf scheduling parameters for a domain.  Introduces
>>     for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
>>     appropriate locking in cpupool_unassign_cpu().
>>     
>>     Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24159:0965e589fdcc
>> user:        Paul Durrant <paul.durrant@citrix.com>
>> date:        Fri Nov 18 13:32:50 2011 +0000
>>     
>>     hvmloader: Add configuration options to selectively disable S3 and S4 
> ACPI
>> power states.
>>     
>>     Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
>>     S3 and S4 packages are moved into separate SSDTs and their inclusion
>>     is controlled by the new configuration options.
>>     
>>     Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24158:4fa1c13f8bb1
>> user:        Paul Durrant <paul.durrant@citrix.com>
>> date:        Fri Nov 18 13:31:43 2011 +0000
>>     
>>     hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
>>     
>>     Since hvmloader has a xentore client, use a platform key in xenstore
>>     to indicate whether ACPI is enabled or not rather than the shared
>>     hvm_info_table structure.
>>     
>>     Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24157:7b5e1cb94bfa
>> user:        Jan Beulich <jbeulich@suse.com>
>> date:        Fri Nov 18 09:22:45 2011 +0100
>>     
>>     x86/xsave: provide guests with finit-like environment
>>     
>>     Without the use of xsave, guests get their initial floating point
>>     environment set up with finit. At least NetWare actually depends on
>>     this (in particular on all exceptions being masked), so to be
>>     consistent set the same environment also when using xsave. This is
>>     also in line with all SSE exceptions getting masked initially.
>>     
>>     To avoid further fragile casts in xstate_alloc_save_area() the patch
>>     also changes xsave_struct's fpu_see member to have actually usable
>>     fields.
>>     
>>     The patch was tested in its technically identical, but modified-file-
>>     wise different 4.1.2 version.
>>     
>>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>     Tested-by: Charles Arnold <carnold@suse.com>
>>     Acked-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24156:f29b5bd6e25f
>> user:        Jan Beulich <jbeulich@suse.com>
>> date:        Fri Nov 18 09:21:24 2011 +0100
>>     
>>     x86/IRQ: prevent vector sharing within IO-APICs
>>     
>>     Following the prevention of vector sharing for MSIs, this change
>>     enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
>>     as their identifying device under the AMD IOMMU (and just like for
>>     MSIs, only the identifying device is used to remap interrupts here,
>>     with no regard to an interrupt's destination).
>>     
>>     Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
>>     use only the vector for identifying which interrupts to end. While this
>>     generally causes no significant problem (at worst an interrupt would be
>>     re-raised without a new interrupt event actually having occurred), it
>>     still seems better to avoid the situation.
>>     
>>     For this second aspect, a distinction is being made between the
>>     traditional and the directed-EOI cases: In the former, vectors should
>>     not be shared throughout all IO-APICs in the system, while in the
>>     latter case only individual IO-APICs need to be contrained (or, if the
>>     firmware indicates so, sub- groups of them having the same GSI appear
>>     at multiple pins).
>>     
>>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>     Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>     
>>     
>> changeset:   24155:0d50e704834f
>> user:        Jan Beulich <jbeulich@suse.com>
>> date:        Fri Nov 18 09:18:41 2011 +0100
>>     
>>     x86/IO-APIC: refine EOI-ing of migrating level interrupts
>>     
>>     Rather than going through all IO-APICs and calling io_apic_eoi_vector()
>>     for the vector in question, just use eoi_IO_APIC_irq().
>>     
>>     This in turn allows to eliminate quite a bit of other code.
>>     
>>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>     Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>     Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>     
>>     
>> changeset:   24154:dbdc840f8f62
>> user:        Keir Fraser <keir@xen.org>
>> date:        Wed Nov 16 18:21:14 2011 +0000
>>     
>>     elf: Fix Elf64 types and structs to match the specification.
>>     
>>     The layouts were actually correct, but the type names were a bit
>>     messed up.
>>     
>>     Original patch by Volker Eckert <volker.eckert@citrix.com>
>>     Signed-off-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> ========================================
>> commit 52834188eedfbbca5636fd869d4c86b3b3044439
>> Author: Ian Campbell <ian.campbell@citrix.com>
>> Date:   Tue Nov 1 18:42:55 2011 +0000
>> 
>>     qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
>>     
>>     I have just proposed a patch to add this to xen-unstable.hg as
>>     docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where
>> people
>>     look for docs, plus we are transitioning to upstream qemu.
>>     
>>     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:14:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlUl-0000Ft-OJ; Tue, 22 Nov 2011 08:14:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSlUk-0000Fk-9j
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:14:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321949633!4095579!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30950 invoked from network); 22 Nov 2011 08:13:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 08:13:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 22 Nov 2011 08:13:53 +0000
Message-Id: <4ECB67CF0200007800062465@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 22 Nov 2011 08:13:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <osstest-9955-mainreport@xen.org>
	<CAF102CD.2555F%keir.xen@gmail.com>
In-Reply-To: <CAF102CD.2555F%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xensource.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 08:42, Keir Fraser <keir.xen@gmail.com> wrote:
> On 22/11/2011 07:17, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> 
>> flight 9955 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/9955/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking:
>>  test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 9951 REGR. vs.
>> 9855
> 
> Could c/s 24160 be to blame?

I don't think so - the sedf thing (with varying sub-tests iirc) has been
(inconsistently) failing for quite a long while.

Further, here this test wasn't even run because xen-boot (below)
failed. And no matter how many times I looked at the respective
logs, I wasn't able to spot what it really is that fails here. I can only
assume that Dom0 is hung, but my sedf knowledge doesn't go far
enough to tell that for sure from the dumped data.

Jan

>> Tests which are failing intermittently (not blocking):
>>  test-i386-i386-win           14 guest-start.2                fail pass in
>> 9951
>> 
>> Tests which did not succeed, but are not blocking,
>> including regressions (tests previously passed) regarded as allowable:
>>  test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like
>> 9817
>>  test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never
>> pass
>>  test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never
>> pass
>>  test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never
>> pass
>>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never
>> pass
>>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never
>> pass
>>  test-amd64-i386-win          16 leak-check/check             fail   never
>> pass
>>  test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never
>> pass
>>  test-i386-i386-xl-win        13 guest-stop                   fail   never
>> pass
>>  test-amd64-amd64-win         16 leak-check/check             fail   never
>> pass
>>  test-i386-i386-win           16 leak-check/check       fail in 9951 never
>> pass
>> 
>> version targeted for testing:
>>  xen                  0a0c02a61676
>> baseline version:
>>  xen                  dbdc840f8f62
>> 
>> ------------------------------------------------------------
>> People who touched revisions under test:
>>   Andrew Cooper <andrew.cooper3@citrix.com>
>>   Charles Arnold <carnold@suse.com>
>>   Ian Campbell <ian.campbell@citrix.com>
>>   Jan Beulich <jbeulich@suse.com>
>>   Jean Guyader <jean.guyader@eu.citrix.com>
>>   Juergen Gross <juergen.gross@ts.fujitsu.com>
>>   Keir Fraser <keir@xen.org>
>>   Olaf Hering <olaf@aepfle.de>
>>   Paul Durrant <paul.durrant@citrix.com>
>> ------------------------------------------------------------
>> 
>> jobs:
>>  build-amd64                                                  pass
>>  build-i386                                                   pass
>>  build-amd64-oldkern                                          pass
>>  build-i386-oldkern                                           pass
>>  build-amd64-pvops                                            pass
>>  build-i386-pvops                                             pass
>>  test-amd64-amd64-xl                                          pass
>>  test-amd64-i386-xl                                           pass
>>  test-i386-i386-xl                                            pass
>>  test-amd64-i386-rhel6hvm-amd                                 fail
>>  test-amd64-i386-xl-credit2                                   pass
>>  test-amd64-amd64-xl-pcipt-intel                              fail
>>  test-amd64-i386-rhel6hvm-intel                               fail
>>  test-amd64-i386-xl-multivcpu                                 pass
>>  test-amd64-amd64-pair                                        pass
>>  test-amd64-i386-pair                                         pass
>>  test-i386-i386-pair                                          pass
>>  test-amd64-amd64-pv                                          pass
>>  test-amd64-i386-pv                                           pass
>>  test-i386-i386-pv                                            pass
>>  test-amd64-amd64-xl-sedf                                     fail
>>  test-amd64-i386-win-vcpus1                                   fail
>>  test-amd64-i386-xl-win-vcpus1                                fail
>>  test-amd64-amd64-win                                         fail
>>  test-amd64-i386-win                                          fail
>>  test-i386-i386-win                                           fail
>>  test-amd64-amd64-xl-win                                      fail
>>  test-i386-i386-xl-win                                        fail
>> 
>> 
>> ------------------------------------------------------------
>> sg-report-flight on woking.cam.xci-test.com
>> logs: /home/xc_osstest/logs
>> images: /home/xc_osstest/images
>> 
>> Logs, config files, etc. are available at
>>     http://www.chiark.greenend.org.uk/~xensrcts/logs 
>> 
>> Test harness code can be found at
>>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary 
>> 
>> 
>> Not pushing.
>> 
>> ------------------------------------------------------------
>> changeset:   24169:0a0c02a61676
>> tag:         tip
>> user:        Keir Fraser <keir@xen.org>
>> date:        Mon Nov 21 21:28:34 2011 +0000
>>     
>>     hvmloader: Fix memory relocation loop.
>>     
>>     Signed-off-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24168:9c350ab8d3ea
>> user:        Jan Beulich <jbeulich@suse.com>
>> date:        Mon Nov 21 09:29:31 2011 +0100
>>     
>>     x86/vioapic: clear remote IRR when switching RTE to edge triggered mode
>>     
>>     Xen itself (as much as Linux) relies on this behavior, so it should
>>     also emulate it properly. Not doing so reportedly gets in the way of
>>     kexec inside a HVM guest.
>>     
>>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>     Tested-by: Olaf Hering <olaf@aepfle.de>
>>     
>>     
>> changeset:   24167:335e8273a3f3
>> user:        Keir Fraser <keir@xen.org>
>> date:        Sat Nov 19 22:13:51 2011 +0000
>>     
>>     x86: Fix RCU locking in XENMEM_add_to_physmap.
>>     
>>     Signed-off-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24166:fe3e9d0c123c
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:43:26 2011 +0000
>>     
>>     iommu: Introduce per cpu flag (iommu_dont_flush_iotlb) to avoid
>> unnecessary iotlb flush
>>     
>>     Add cpu flag that will be checked by the iommu low level code
>>     to skip iotlb flushes. iommu_iotlb_flush shall be called explicitly.
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24165:89a4d97731c5
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:42:46 2011 +0000
>>     
>>     hvmloader: Change memory relocation loop when overlap with PCI hole
>>     
>>     Change the way we relocate the memory page if they overlap with pci
>>     hole.  Use new map space (XENMAPSPACE_gmfn_range) to move the loop
>>     into xen.
>>     
>>     This code usually get triggered when a device is pass through to a
>>     guest and the PCI hole has to be extended to have enough room to map
>>     the device BARs.  The PCI hole will starts lower and it might overlap
>>     with some RAM that has been alocated for the guest. That usually
>>     happen if the guest has more than 4G of RAM.  We have to relocate
>>     those pages in high mem otherwise they won't be accessible.
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24164:707d27fe03e7
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:42:08 2011 +0000
>>     
>>     mm: New XENMEM space, XENMAPSPACE_gmfn_range
>>     
>>     XENMAPSPACE_gmfn_range is like XENMAPSPACE_gmfn but it runs on
>>     a range of pages. The size of the range is defined in a new field.
>>     
>>     This new field .size is located in the 16 bits padding between .domid
>>     and .space in struct xen_add_to_physmap to stay compatible with older
>>     versions.
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24163:7a9a1261a6b0
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:41:33 2011 +0000
>>     
>>     add_to_physmap: Move the code for XENMEM_add_to_physmap
>>     
>>     Move the code for the XENMEM_add_to_physmap case into it's own
>>     function (xenmem_add_to_physmap).
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24162:9a1a71f7bef2
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:40:56 2011 +0000
>>     
>>     iommu: Introduce iommu_flush and iommu_flush_all.
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24161:aeb628c5af3f
>> user:        Jean Guyader <jean.guyader@eu.citrix.com>
>> date:        Fri Nov 18 13:40:19 2011 +0000
>>     
>>     vtd: Refactor iotlb flush code
>>     
>>     Factorize the iotlb flush code from map_page and unmap_page into
>>     it's own function.
>>     
>>     Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24160:d7e6bfa114d0
>> user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
>> date:        Fri Nov 18 13:34:43 2011 +0000
>>     
>>     sched_sedf: Avoid panic when adjusting sedf parameters
>>     
>>     When using sedf scheduler in a cpupool the system might panic when
>>     setting sedf scheduling parameters for a domain.  Introduces
>>     for_each_domain_in_cpupool macro as it is usable 4 times now.  Add
>>     appropriate locking in cpupool_unassign_cpu().
>>     
>>     Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24159:0965e589fdcc
>> user:        Paul Durrant <paul.durrant@citrix.com>
>> date:        Fri Nov 18 13:32:50 2011 +0000
>>     
>>     hvmloader: Add configuration options to selectively disable S3 and S4 
> ACPI
>> power states.
>>     
>>     Introduce acpi_s3 and acpi_s4 configuration options (default=1). The
>>     S3 and S4 packages are moved into separate SSDTs and their inclusion
>>     is controlled by the new configuration options.
>>     
>>     Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24158:4fa1c13f8bb1
>> user:        Paul Durrant <paul.durrant@citrix.com>
>> date:        Fri Nov 18 13:31:43 2011 +0000
>>     
>>     hvmloader: Move acpi_enabled out of hvm_info_table into xenstore
>>     
>>     Since hvmloader has a xentore client, use a platform key in xenstore
>>     to indicate whether ACPI is enabled or not rather than the shared
>>     hvm_info_table structure.
>>     
>>     Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>>     Committed-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24157:7b5e1cb94bfa
>> user:        Jan Beulich <jbeulich@suse.com>
>> date:        Fri Nov 18 09:22:45 2011 +0100
>>     
>>     x86/xsave: provide guests with finit-like environment
>>     
>>     Without the use of xsave, guests get their initial floating point
>>     environment set up with finit. At least NetWare actually depends on
>>     this (in particular on all exceptions being masked), so to be
>>     consistent set the same environment also when using xsave. This is
>>     also in line with all SSE exceptions getting masked initially.
>>     
>>     To avoid further fragile casts in xstate_alloc_save_area() the patch
>>     also changes xsave_struct's fpu_see member to have actually usable
>>     fields.
>>     
>>     The patch was tested in its technically identical, but modified-file-
>>     wise different 4.1.2 version.
>>     
>>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>     Tested-by: Charles Arnold <carnold@suse.com>
>>     Acked-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> changeset:   24156:f29b5bd6e25f
>> user:        Jan Beulich <jbeulich@suse.com>
>> date:        Fri Nov 18 09:21:24 2011 +0100
>>     
>>     x86/IRQ: prevent vector sharing within IO-APICs
>>     
>>     Following the prevention of vector sharing for MSIs, this change
>>     enforces the same within IO-APICs: Pin based interrupts use the IO-APIC
>>     as their identifying device under the AMD IOMMU (and just like for
>>     MSIs, only the identifying device is used to remap interrupts here,
>>     with no regard to an interrupt's destination).
>>     
>>     Additionally, LAPIC initiated EOIs (for level triggered interrupts) too
>>     use only the vector for identifying which interrupts to end. While this
>>     generally causes no significant problem (at worst an interrupt would be
>>     re-raised without a new interrupt event actually having occurred), it
>>     still seems better to avoid the situation.
>>     
>>     For this second aspect, a distinction is being made between the
>>     traditional and the directed-EOI cases: In the former, vectors should
>>     not be shared throughout all IO-APICs in the system, while in the
>>     latter case only individual IO-APICs need to be contrained (or, if the
>>     firmware indicates so, sub- groups of them having the same GSI appear
>>     at multiple pins).
>>     
>>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>     Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>     
>>     
>> changeset:   24155:0d50e704834f
>> user:        Jan Beulich <jbeulich@suse.com>
>> date:        Fri Nov 18 09:18:41 2011 +0100
>>     
>>     x86/IO-APIC: refine EOI-ing of migrating level interrupts
>>     
>>     Rather than going through all IO-APICs and calling io_apic_eoi_vector()
>>     for the vector in question, just use eoi_IO_APIC_irq().
>>     
>>     This in turn allows to eliminate quite a bit of other code.
>>     
>>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>     Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>     Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>     
>>     
>> changeset:   24154:dbdc840f8f62
>> user:        Keir Fraser <keir@xen.org>
>> date:        Wed Nov 16 18:21:14 2011 +0000
>>     
>>     elf: Fix Elf64 types and structs to match the specification.
>>     
>>     The layouts were actually correct, but the type names were a bit
>>     messed up.
>>     
>>     Original patch by Volker Eckert <volker.eckert@citrix.com>
>>     Signed-off-by: Keir Fraser <keir@xen.org>
>>     
>>     
>> ========================================
>> commit 52834188eedfbbca5636fd869d4c86b3b3044439
>> Author: Ian Campbell <ian.campbell@citrix.com>
>> Date:   Tue Nov 1 18:42:55 2011 +0000
>> 
>>     qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
>>     
>>     I have just proposed a patch to add this to xen-unstable.hg as
>>     docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where
>> people
>>     look for docs, plus we are transitioning to upstream qemu.
>>     
>>     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:19:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlZ8-0000Q4-OC; Tue, 22 Nov 2011 08:18:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSlZ7-0000Ps-HQ
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:18:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321949904!4444375!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6680 invoked from network); 22 Nov 2011 08:18:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 08:18:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9055535"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 08:18:24 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 08:18:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Tue, 22 Nov 2011 08:18:23 +0000
Message-ID: <1321949903.20464.19.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
[...]
> memory = 15360
> maxmem = 15360
[...]
> How much RAM does the host system have? What are your hypervisor and
> > dom0 command lines.
> 
> 16GB RAM.

So you are assigning 15GB out of a total of 16GB to the guest which
necessitates ballooning dom0 from 16GB down to 1GB.

> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
> 	root (hd0,0)
> 	kernel /xen.gz dom0_mem=512M loglvl=all guest_loglvl=all cpuidle=0 cpufreq=none

But you have already forced the dom0_mem to 512M. I suspect this is
colluding with the above ballooning to make it look as if dom0 should be
ballooned to <128M, which causes xl to print a warning message. Perhaps
someone who understands this stuff can comment on whether or not this
should be the case.

Can you try setting "autoballoon=0" in /etc/xl.cfg.

I can't see anything in the range 23110:23190 which might have caused a
change in behaviour here though.

> 	module /vmlinuz-2.6.32.47-0.xen.pvops.choon.sl6 ro
> root=UUID=154127e6-9469-4124-9a42-1f6c6160adf4
> rd_MD_UUID=d5126687:736a76db:5d5f597f:8b16fad4 rd_NO_LUKS rd_NO_LVM
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
> KEYTABLE=us crashkernel=auto rhgb quiet panic=5 panic_timeout=10
> 	module /initramfs-2.6.32.47-0.xen.pvops.choon.sl6.img
> 
> >
> > What is the last changeset which worked for you?
> 
> I did provide last working changeset is 23110 in my initial email.

So you did, sorry I missed it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:19:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:19:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlZ8-0000Q4-OC; Tue, 22 Nov 2011 08:18:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSlZ7-0000Ps-HQ
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:18:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321949904!4444375!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6680 invoked from network); 22 Nov 2011 08:18:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 08:18:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9055535"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 08:18:24 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 08:18:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Tue, 22 Nov 2011 08:18:23 +0000
Message-ID: <1321949903.20464.19.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
[...]
> memory = 15360
> maxmem = 15360
[...]
> How much RAM does the host system have? What are your hypervisor and
> > dom0 command lines.
> 
> 16GB RAM.

So you are assigning 15GB out of a total of 16GB to the guest which
necessitates ballooning dom0 from 16GB down to 1GB.

> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
> 	root (hd0,0)
> 	kernel /xen.gz dom0_mem=512M loglvl=all guest_loglvl=all cpuidle=0 cpufreq=none

But you have already forced the dom0_mem to 512M. I suspect this is
colluding with the above ballooning to make it look as if dom0 should be
ballooned to <128M, which causes xl to print a warning message. Perhaps
someone who understands this stuff can comment on whether or not this
should be the case.

Can you try setting "autoballoon=0" in /etc/xl.cfg.

I can't see anything in the range 23110:23190 which might have caused a
change in behaviour here though.

> 	module /vmlinuz-2.6.32.47-0.xen.pvops.choon.sl6 ro
> root=UUID=154127e6-9469-4124-9a42-1f6c6160adf4
> rd_MD_UUID=d5126687:736a76db:5d5f597f:8b16fad4 rd_NO_LUKS rd_NO_LVM
> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
> KEYTABLE=us crashkernel=auto rhgb quiet panic=5 panic_timeout=10
> 	module /initramfs-2.6.32.47-0.xen.pvops.choon.sl6.img
> 
> >
> > What is the last changeset which worked for you?
> 
> I did provide last working changeset is 23110 in my initial email.

So you did, sorry I missed it.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:31:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:31:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlkb-0000wp-0W; Tue, 22 Nov 2011 08:30:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSlkZ-0000wc-Hg
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:30:43 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1321950613!4383274!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26179 invoked from network); 22 Nov 2011 08:30:15 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 08:30:15 -0000
Received: by ywn1 with SMTP id 1so8995924ywn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 00:30:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Uxgaxq/HlR1H0PzqIxxShOX6XJ4WII1u425cWaoWtUM=;
	b=JneKRRaBvgJyZKBgMhhbhLcckPtkeTBOI675SvMVcZRA3eQZXQbLZDZgC0q+S8bMFb
	diFVB141ti4O2P6eWxjZv039QMbEFhiSXBeL9E9Hp3N8B1ZLib2YAI5BS2AN2/1vfJnX
	DtdrMeGsTX7bT3LZ/2C9LjccE34F3lXOJ5b/w=
MIME-Version: 1.0
Received: by 10.68.208.194 with SMTP id mg2mr38185406pbc.112.1321950613030;
	Tue, 22 Nov 2011 00:30:13 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Tue, 22 Nov 2011 00:30:12 -0800 (PST)
In-Reply-To: <1321949903.20464.19.camel@dagon.hellion.org.uk>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
Date: Tue, 22 Nov 2011 16:30:12 +0800
Message-ID: <CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
> [...]
>> memory =3D 15360
>> maxmem =3D 15360
> [...]
>> How much RAM does the host system have? What are your hypervisor and
>> > dom0 command lines.
>>
>> 16GB RAM.
>
> So you are assigning 15GB out of a total of 16GB to the guest which
> necessitates ballooning dom0 from 16GB down to 1GB.

I actually set dom0-min-mem 512 in xend-config.sxp as well.

>
>> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
>> =A0 =A0 =A0 root (hd0,0)
>> =A0 =A0 =A0 kernel /xen.gz dom0_mem=3D512M loglvl=3Dall guest_loglvl=3Da=
ll cpuidle=3D0 cpufreq=3Dnone
>
> But you have already forced the dom0_mem to 512M. I suspect this is
> colluding with the above ballooning to make it look as if dom0 should be
> ballooned to <128M, which causes xl to print a warning message. Perhaps
> someone who understands this stuff can comment on whether or not this
> should be the case.
>
> Can you try setting "autoballoon=3D0" in /etc/xl.cfg.

You mean /etc/xen/xl.conf?  I have done so and guess what?  IT WORKS!!! :)

>
> I can't see anything in the range 23110:23190 which might have caused a
> change in behaviour here though.
>
>> =A0 =A0 =A0 module /vmlinuz-2.6.32.47-0.xen.pvops.choon.sl6 ro
>> root=3DUUID=3D154127e6-9469-4124-9a42-1f6c6160adf4
>> rd_MD_UUID=3Dd5126687:736a76db:5d5f597f:8b16fad4 rd_NO_LUKS rd_NO_LVM
>> rd_NO_DM LANG=3Den_US.UTF-8 SYSFONT=3Dlatarcyrheb-sun16 KEYBOARDTYPE=3Dpc
>> KEYTABLE=3Dus crashkernel=3Dauto rhgb quiet panic=3D5 panic_timeout=3D10
>> =A0 =A0 =A0 module /initramfs-2.6.32.47-0.xen.pvops.choon.sl6.img
>>
>> >
>> > What is the last changeset which worked for you?
>>
>> I did provide last working changeset is 23110 in my initial email.
>
> So you did, sorry I missed it.
>
> Ian.

You do not need to say sorry as without your assistance I can't even
possible play with Xen for so long and having fun ;)

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:31:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:31:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlkb-0000wp-0W; Tue, 22 Nov 2011 08:30:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSlkZ-0000wc-Hg
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:30:43 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1321950613!4383274!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26179 invoked from network); 22 Nov 2011 08:30:15 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 08:30:15 -0000
Received: by ywn1 with SMTP id 1so8995924ywn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 00:30:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Uxgaxq/HlR1H0PzqIxxShOX6XJ4WII1u425cWaoWtUM=;
	b=JneKRRaBvgJyZKBgMhhbhLcckPtkeTBOI675SvMVcZRA3eQZXQbLZDZgC0q+S8bMFb
	diFVB141ti4O2P6eWxjZv039QMbEFhiSXBeL9E9Hp3N8B1ZLib2YAI5BS2AN2/1vfJnX
	DtdrMeGsTX7bT3LZ/2C9LjccE34F3lXOJ5b/w=
MIME-Version: 1.0
Received: by 10.68.208.194 with SMTP id mg2mr38185406pbc.112.1321950613030;
	Tue, 22 Nov 2011 00:30:13 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Tue, 22 Nov 2011 00:30:12 -0800 (PST)
In-Reply-To: <1321949903.20464.19.camel@dagon.hellion.org.uk>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
Date: Tue, 22 Nov 2011 16:30:12 +0800
Message-ID: <CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
> [...]
>> memory =3D 15360
>> maxmem =3D 15360
> [...]
>> How much RAM does the host system have? What are your hypervisor and
>> > dom0 command lines.
>>
>> 16GB RAM.
>
> So you are assigning 15GB out of a total of 16GB to the guest which
> necessitates ballooning dom0 from 16GB down to 1GB.

I actually set dom0-min-mem 512 in xend-config.sxp as well.

>
>> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
>> =A0 =A0 =A0 root (hd0,0)
>> =A0 =A0 =A0 kernel /xen.gz dom0_mem=3D512M loglvl=3Dall guest_loglvl=3Da=
ll cpuidle=3D0 cpufreq=3Dnone
>
> But you have already forced the dom0_mem to 512M. I suspect this is
> colluding with the above ballooning to make it look as if dom0 should be
> ballooned to <128M, which causes xl to print a warning message. Perhaps
> someone who understands this stuff can comment on whether or not this
> should be the case.
>
> Can you try setting "autoballoon=3D0" in /etc/xl.cfg.

You mean /etc/xen/xl.conf?  I have done so and guess what?  IT WORKS!!! :)

>
> I can't see anything in the range 23110:23190 which might have caused a
> change in behaviour here though.
>
>> =A0 =A0 =A0 module /vmlinuz-2.6.32.47-0.xen.pvops.choon.sl6 ro
>> root=3DUUID=3D154127e6-9469-4124-9a42-1f6c6160adf4
>> rd_MD_UUID=3Dd5126687:736a76db:5d5f597f:8b16fad4 rd_NO_LUKS rd_NO_LVM
>> rd_NO_DM LANG=3Den_US.UTF-8 SYSFONT=3Dlatarcyrheb-sun16 KEYBOARDTYPE=3Dpc
>> KEYTABLE=3Dus crashkernel=3Dauto rhgb quiet panic=3D5 panic_timeout=3D10
>> =A0 =A0 =A0 module /initramfs-2.6.32.47-0.xen.pvops.choon.sl6.img
>>
>> >
>> > What is the last changeset which worked for you?
>>
>> I did provide last working changeset is 23110 in my initial email.
>
> So you did, sorry I missed it.
>
> Ian.

You do not need to say sorry as without your assistance I can't even
possible play with Xen for so long and having fun ;)

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:32:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSllz-00011I-I7; Tue, 22 Nov 2011 08:32:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSlly-000114-BR
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:32:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1321950701!4089056!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29802 invoked from network); 22 Nov 2011 08:31:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 08:31:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9055826"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 08:31:21 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 08:31:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Tue, 22 Nov 2011 08:31:20 +0000
Message-ID: <1321950680.20464.20.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
> > [...]
> >> memory = 15360
> >> maxmem = 15360
> > [...]
> >> How much RAM does the host system have? What are your hypervisor and
> >> > dom0 command lines.
> >>
> >> 16GB RAM.
> >
> > So you are assigning 15GB out of a total of 16GB to the guest which
> > necessitates ballooning dom0 from 16GB down to 1GB.
> 
> I actually set dom0-min-mem 512 in xend-config.sxp as well.

xl/libxl don't use this configuration file.

> 
> >
> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
> >>       root (hd0,0)
> >>       kernel /xen.gz dom0_mem=512M loglvl=all guest_loglvl=all cpuidle=0 cpufreq=none
> >
> > But you have already forced the dom0_mem to 512M. I suspect this is
> > colluding with the above ballooning to make it look as if dom0 should be
> > ballooned to <128M, which causes xl to print a warning message. Perhaps
> > someone who understands this stuff can comment on whether or not this
> > should be the case.
> >
> > Can you try setting "autoballoon=0" in /etc/xl.cfg.
> 
> You mean /etc/xen/xl.conf?  I have done so and guess what?  IT WORKS!!! :)

Great.

Ian.

> 
> >
> > I can't see anything in the range 23110:23190 which might have caused a
> > change in behaviour here though.
> >
> >>       module /vmlinuz-2.6.32.47-0.xen.pvops.choon.sl6 ro
> >> root=UUID=154127e6-9469-4124-9a42-1f6c6160adf4
> >> rd_MD_UUID=d5126687:736a76db:5d5f597f:8b16fad4 rd_NO_LUKS rd_NO_LVM
> >> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
> >> KEYTABLE=us crashkernel=auto rhgb quiet panic=5 panic_timeout=10
> >>       module /initramfs-2.6.32.47-0.xen.pvops.choon.sl6.img
> >>
> >> >
> >> > What is the last changeset which worked for you?
> >>
> >> I did provide last working changeset is 23110 in my initial email.
> >
> > So you did, sorry I missed it.
> >
> > Ian.
> 
> You do not need to say sorry as without your assistance I can't even
> possible play with Xen for so long and having fun ;)
> 
> Thanks.
> 
> Kindest regards,
> Giam Teck Choon



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:32:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:32:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSllz-00011I-I7; Tue, 22 Nov 2011 08:32:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSlly-000114-BR
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:32:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1321950701!4089056!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29802 invoked from network); 22 Nov 2011 08:31:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 08:31:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9055826"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 08:31:21 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 08:31:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Tue, 22 Nov 2011 08:31:20 +0000
Message-ID: <1321950680.20464.20.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
> > [...]
> >> memory = 15360
> >> maxmem = 15360
> > [...]
> >> How much RAM does the host system have? What are your hypervisor and
> >> > dom0 command lines.
> >>
> >> 16GB RAM.
> >
> > So you are assigning 15GB out of a total of 16GB to the guest which
> > necessitates ballooning dom0 from 16GB down to 1GB.
> 
> I actually set dom0-min-mem 512 in xend-config.sxp as well.

xl/libxl don't use this configuration file.

> 
> >
> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
> >>       root (hd0,0)
> >>       kernel /xen.gz dom0_mem=512M loglvl=all guest_loglvl=all cpuidle=0 cpufreq=none
> >
> > But you have already forced the dom0_mem to 512M. I suspect this is
> > colluding with the above ballooning to make it look as if dom0 should be
> > ballooned to <128M, which causes xl to print a warning message. Perhaps
> > someone who understands this stuff can comment on whether or not this
> > should be the case.
> >
> > Can you try setting "autoballoon=0" in /etc/xl.cfg.
> 
> You mean /etc/xen/xl.conf?  I have done so and guess what?  IT WORKS!!! :)

Great.

Ian.

> 
> >
> > I can't see anything in the range 23110:23190 which might have caused a
> > change in behaviour here though.
> >
> >>       module /vmlinuz-2.6.32.47-0.xen.pvops.choon.sl6 ro
> >> root=UUID=154127e6-9469-4124-9a42-1f6c6160adf4
> >> rd_MD_UUID=d5126687:736a76db:5d5f597f:8b16fad4 rd_NO_LUKS rd_NO_LVM
> >> rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
> >> KEYTABLE=us crashkernel=auto rhgb quiet panic=5 panic_timeout=10
> >>       module /initramfs-2.6.32.47-0.xen.pvops.choon.sl6.img
> >>
> >> >
> >> > What is the last changeset which worked for you?
> >>
> >> I did provide last working changeset is 23110 in my initial email.
> >
> > So you did, sorry I missed it.
> >
> > Ian.
> 
> You do not need to say sorry as without your assistance I can't even
> possible play with Xen for so long and having fun ;)
> 
> Thanks.
> 
> Kindest regards,
> Giam Teck Choon



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:33:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlmX-00014I-0o; Tue, 22 Nov 2011 08:32:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RSlmU-00013d-Iv
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:32:42 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321950733!3544545!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10606 invoked from network); 22 Nov 2011 08:32:14 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 08:32:14 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=eyJPBPuG7j8i62m6eRS2uGnYlE0HjKwCndzKQEU1vYjM2qL6UOg83DQL
	dEWeiywUGIsEKV6XiTqanX6pwB6KtWkI+qiNfDNN2DU7GlGBzgXyICZFY
	FsoFNXqCaHCwrghrkWxC9KbhWf29dYcOjuF737EuPqKWzskV0wjWyJdR6
	+ebUjrRzfpohKBLLETRmPbh4192DmvVyYcZWTXAHyoGf5UdlFpn7l/G3n
	MA6qB/r2asEtKB7nMhCwtStqYyKVK;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321950734; x=1353486734;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=+rh4KTg6P+hjtSyczoC3IIsiGGx0IFCCABuH6Trpgcs=;
	b=fZMfPPLxYYuM76hyDmTcGnTw/hj9sF3AX6qxgf7IacVkBs2V1jtAtceG
	K6j9E8f/+qi2sefYtThHH+BTbVXBou10sO9KaHiqLwRmKsrIpRlXQmGFA
	iMNyJ2F5Eu2MhSHEkcwHugoZsrHPe7kvtcsWrmXJlsCo/8CPVUYn5kdoA
	DFCs4blBEwDiCN6p8/o7at/xjs04U6OplXBI48lGHCyMs1Brh+osLQVld
	/Yo66vbvuVPCjEulb4CB6o1wsVUzA;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,551,1315173600"; d="scan'208";a="79569516"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 22 Nov 2011 09:32:13 +0100
X-IronPort-AV: E=Sophos;i="4.69,551,1315173600"; d="scan'208";a="123902581"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 22 Nov 2011 09:32:13 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 4EFD376B4BE;
	Tue, 22 Nov 2011 09:32:13 +0100 (CET)
Message-ID: <4ECB5E0D.9020407@ts.fujitsu.com>
Date: Tue, 22 Nov 2011 09:32:13 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CAF102CD.2555F%keir.xen@gmail.com>
In-Reply-To: <CAF102CD.2555F%keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/22/2011 08:42 AM, Keir Fraser wrote:
> On 22/11/2011 07:17, "Ian Jackson"<Ian.Jackson@eu.citrix.com>  wrote:
>
>> flight 9955 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/9955/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking:
>>   test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 9951 REGR. vs.
>> 9855
> Could c/s 24160 be to blame?
>
>   -- Keir

As Jan already wrote: booting failed with sched=sedf. It works on my machine
(4 core Nehalem) with cs 24269.

Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:33:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlmX-00014I-0o; Tue, 22 Nov 2011 08:32:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RSlmU-00013d-Iv
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:32:42 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321950733!3544545!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10606 invoked from network); 22 Nov 2011 08:32:14 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 08:32:14 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=eyJPBPuG7j8i62m6eRS2uGnYlE0HjKwCndzKQEU1vYjM2qL6UOg83DQL
	dEWeiywUGIsEKV6XiTqanX6pwB6KtWkI+qiNfDNN2DU7GlGBzgXyICZFY
	FsoFNXqCaHCwrghrkWxC9KbhWf29dYcOjuF737EuPqKWzskV0wjWyJdR6
	+ebUjrRzfpohKBLLETRmPbh4192DmvVyYcZWTXAHyoGf5UdlFpn7l/G3n
	MA6qB/r2asEtKB7nMhCwtStqYyKVK;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1321950734; x=1353486734;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=+rh4KTg6P+hjtSyczoC3IIsiGGx0IFCCABuH6Trpgcs=;
	b=fZMfPPLxYYuM76hyDmTcGnTw/hj9sF3AX6qxgf7IacVkBs2V1jtAtceG
	K6j9E8f/+qi2sefYtThHH+BTbVXBou10sO9KaHiqLwRmKsrIpRlXQmGFA
	iMNyJ2F5Eu2MhSHEkcwHugoZsrHPe7kvtcsWrmXJlsCo/8CPVUYn5kdoA
	DFCs4blBEwDiCN6p8/o7at/xjs04U6OplXBI48lGHCyMs1Brh+osLQVld
	/Yo66vbvuVPCjEulb4CB6o1wsVUzA;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,551,1315173600"; d="scan'208";a="79569516"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 22 Nov 2011 09:32:13 +0100
X-IronPort-AV: E=Sophos;i="4.69,551,1315173600"; d="scan'208";a="123902581"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 22 Nov 2011 09:32:13 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 4EFD376B4BE;
	Tue, 22 Nov 2011 09:32:13 +0100 (CET)
Message-ID: <4ECB5E0D.9020407@ts.fujitsu.com>
Date: Tue, 22 Nov 2011 09:32:13 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CAF102CD.2555F%keir.xen@gmail.com>
In-Reply-To: <CAF102CD.2555F%keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/22/2011 08:42 AM, Keir Fraser wrote:
> On 22/11/2011 07:17, "Ian Jackson"<Ian.Jackson@eu.citrix.com>  wrote:
>
>> flight 9955 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/9955/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking:
>>   test-amd64-amd64-xl-sedf     11 guest-localmigrate fail in 9951 REGR. vs.
>> 9855
> Could c/s 24160 be to blame?
>
>   -- Keir

As Jan already wrote: booting failed with sched=sedf. It works on my machine
(4 core Nehalem) with cs 24269.

Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:39:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlsb-0001WE-Nx; Tue, 22 Nov 2011 08:39:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSlsa-0001Vt-Pe
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:39:01 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1321951110!4075671!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14156 invoked from network); 22 Nov 2011 08:38:32 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 08:38:32 -0000
Received: by yenm6 with SMTP id m6so3182662yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 00:38:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=KGhCzC+0SihucudLvXhJlmpc6lXT1K75bPgxmv8QIUw=;
	b=BjHPpvtTWH4w9cvy2KR1V8+JXGuP3yoKbYkeNRmL0SlkwYWEPGOvrxLBd+H7iU0IPH
	gqfVw+hwXhQI6WslcY8Rz0cObf1pc2mIZsiZMpKRjrAuFpjitIc2FuOiQDOxBXmyxD0l
	BoOG1Vr0RmX12Wr+4tdYeP3L9zJLgHQvHM6Ag=
MIME-Version: 1.0
Received: by 10.68.12.97 with SMTP id x1mr43381648pbb.78.1321951110295; Tue,
	22 Nov 2011 00:38:30 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Tue, 22 Nov 2011 00:38:30 -0800 (PST)
In-Reply-To: <1321950680.20464.20.camel@dagon.hellion.org.uk>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
Date: Tue, 22 Nov 2011 16:38:30 +0800
Message-ID: <CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 4:31 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
>> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
>> > [...]
>> >> memory =3D 15360
>> >> maxmem =3D 15360
>> > [...]
>> >> How much RAM does the host system have? What are your hypervisor and
>> >> > dom0 command lines.
>> >>
>> >> 16GB RAM.
>> >
>> > So you are assigning 15GB out of a total of 16GB to the guest which
>> > necessitates ballooning dom0 from 16GB down to 1GB.
>>
>> I actually set dom0-min-mem 512 in xend-config.sxp as well.
>
> xl/libxl don't use this configuration file.

Oh... now then I know.  I always test with both xl and xm for my
testing machine(s) to see any differences as there are... ...

>
>>
>> >
>> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
>> >> =A0 =A0 =A0 root (hd0,0)
>> >> =A0 =A0 =A0 kernel /xen.gz dom0_mem=3D512M loglvl=3Dall guest_loglvl=
=3Dall cpuidle=3D0 cpufreq=3Dnone
>> >
>> > But you have already forced the dom0_mem to 512M. I suspect this is
>> > colluding with the above ballooning to make it look as if dom0 should =
be
>> > ballooned to <128M, which causes xl to print a warning message. Perhaps
>> > someone who understands this stuff can comment on whether or not this
>> > should be the case.
>> >
>> > Can you try setting "autoballoon=3D0" in /etc/xl.cfg.
>>
>> You mean /etc/xen/xl.conf? =A0I have done so and guess what? =A0IT WORKS=
!!! :)
>
> Great.

That means default value changed if it is unset for autoballoon?
Original one is commented with #autoballoon =3D 1 in /etc/xen/xl.conf so
it is unset I guess so the default value for autoballoon for c/s 23110
is autoballoon=3D0 where c/s 23190 is autoballoon=3D1?  Just some
guessing... ...

>
> Ian.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 08:39:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 08:39:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSlsb-0001WE-Nx; Tue, 22 Nov 2011 08:39:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSlsa-0001Vt-Pe
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 08:39:01 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1321951110!4075671!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14156 invoked from network); 22 Nov 2011 08:38:32 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 08:38:32 -0000
Received: by yenm6 with SMTP id m6so3182662yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 00:38:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=KGhCzC+0SihucudLvXhJlmpc6lXT1K75bPgxmv8QIUw=;
	b=BjHPpvtTWH4w9cvy2KR1V8+JXGuP3yoKbYkeNRmL0SlkwYWEPGOvrxLBd+H7iU0IPH
	gqfVw+hwXhQI6WslcY8Rz0cObf1pc2mIZsiZMpKRjrAuFpjitIc2FuOiQDOxBXmyxD0l
	BoOG1Vr0RmX12Wr+4tdYeP3L9zJLgHQvHM6Ag=
MIME-Version: 1.0
Received: by 10.68.12.97 with SMTP id x1mr43381648pbb.78.1321951110295; Tue,
	22 Nov 2011 00:38:30 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Tue, 22 Nov 2011 00:38:30 -0800 (PST)
In-Reply-To: <1321950680.20464.20.camel@dagon.hellion.org.uk>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
Date: Tue, 22 Nov 2011 16:38:30 +0800
Message-ID: <CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 4:31 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
>> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
>> > [...]
>> >> memory =3D 15360
>> >> maxmem =3D 15360
>> > [...]
>> >> How much RAM does the host system have? What are your hypervisor and
>> >> > dom0 command lines.
>> >>
>> >> 16GB RAM.
>> >
>> > So you are assigning 15GB out of a total of 16GB to the guest which
>> > necessitates ballooning dom0 from 16GB down to 1GB.
>>
>> I actually set dom0-min-mem 512 in xend-config.sxp as well.
>
> xl/libxl don't use this configuration file.

Oh... now then I know.  I always test with both xl and xm for my
testing machine(s) to see any differences as there are... ...

>
>>
>> >
>> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
>> >> =A0 =A0 =A0 root (hd0,0)
>> >> =A0 =A0 =A0 kernel /xen.gz dom0_mem=3D512M loglvl=3Dall guest_loglvl=
=3Dall cpuidle=3D0 cpufreq=3Dnone
>> >
>> > But you have already forced the dom0_mem to 512M. I suspect this is
>> > colluding with the above ballooning to make it look as if dom0 should =
be
>> > ballooned to <128M, which causes xl to print a warning message. Perhaps
>> > someone who understands this stuff can comment on whether or not this
>> > should be the case.
>> >
>> > Can you try setting "autoballoon=3D0" in /etc/xl.cfg.
>>
>> You mean /etc/xen/xl.conf? =A0I have done so and guess what? =A0IT WORKS=
!!! :)
>
> Great.

That means default value changed if it is unset for autoballoon?
Original one is commented with #autoballoon =3D 1 in /etc/xen/xl.conf so
it is unset I guess so the default value for autoballoon for c/s 23110
is autoballoon=3D0 where c/s 23190 is autoballoon=3D1?  Just some
guessing... ...

>
> Ian.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:06:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmIp-000298-EW; Tue, 22 Nov 2011 09:06:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSmIn-000293-Iz
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 09:06:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321952736!5182369!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31003 invoked from network); 22 Nov 2011 09:05:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 09:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9056926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 09:05:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 09:05:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 22 Nov 2011 09:05:35 +0000
In-Reply-To: <CAFLBxZYMmjH7cXcTyHzxN+xBcXVi=ThS16U=qX=4BgV_V0G1iA@mail.gmail.com>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZYMmjH7cXcTyHzxN+xBcXVi=ThS16U=qX=4BgV_V0G1iA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321952736.3664.398.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-21 at 16:40 +0000, George Dunlap wrote:
> On Mon, Nov 21, 2011 at 3:13 PM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Mon, Nov 21, Stefano Stabellini wrote:
> >
> >> what if tot_memkb is bigger than target_memkb? Or even bigger than
> >> max_memkb?
> >
> > tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> > max_memkb.
> 
> I'd love to contribute to this discussion, but I don't know what these
> different names mean.  I think what we need to talk about is all of
> the different memory parameters we need, and then what each of the
> individual names mean -- what they currently map to, and then what we
> want them to map to.  At very least they should be in a comment
> somewhere.

tools/libxl/libxl_memory.txt covers some of that (and Olaf patched it
IIRC) although it is not so clear on the mapping to xl configuration
keys.

Ian.

> 
> >
> > xenpaging will look at tot_memkb value (at "memory/target-tot_pages" to
> > be precise) and try to reach that number of domain->tot_pages. If the
> > tot_memkb number is larger than max_memkb nothing will happen.
> >
> >
> > Right now there is not much checking anyway, memory=1024 maxmem=1 in the
> > config is accepted in my testing.
> >
> > Olaf
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:06:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:06:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmIp-000298-EW; Tue, 22 Nov 2011 09:06:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSmIn-000293-Iz
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 09:06:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321952736!5182369!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31003 invoked from network); 22 Nov 2011 09:05:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 09:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9056926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 09:05:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 09:05:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 22 Nov 2011 09:05:35 +0000
In-Reply-To: <CAFLBxZYMmjH7cXcTyHzxN+xBcXVi=ThS16U=qX=4BgV_V0G1iA@mail.gmail.com>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZYMmjH7cXcTyHzxN+xBcXVi=ThS16U=qX=4BgV_V0G1iA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321952736.3664.398.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-21 at 16:40 +0000, George Dunlap wrote:
> On Mon, Nov 21, 2011 at 3:13 PM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Mon, Nov 21, Stefano Stabellini wrote:
> >
> >> what if tot_memkb is bigger than target_memkb? Or even bigger than
> >> max_memkb?
> >
> > tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> > max_memkb.
> 
> I'd love to contribute to this discussion, but I don't know what these
> different names mean.  I think what we need to talk about is all of
> the different memory parameters we need, and then what each of the
> individual names mean -- what they currently map to, and then what we
> want them to map to.  At very least they should be in a comment
> somewhere.

tools/libxl/libxl_memory.txt covers some of that (and Olaf patched it
IIRC) although it is not so clear on the mapping to xl configuration
keys.

Ian.

> 
> >
> > xenpaging will look at tot_memkb value (at "memory/target-tot_pages" to
> > be precise) and try to reach that number of domain->tot_pages. If the
> > tot_memkb number is larger than max_memkb nothing will happen.
> >
> >
> > Right now there is not much checking anyway, memory=1024 maxmem=1 in the
> > config is accepted in my testing.
> >
> > Olaf
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMj-0002SI-HH; Tue, 22 Nov 2011 09:10:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <garvey.patrickd@gmail.com>) id 1RSfsM-0003XO-Lg
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 02:14:22 +0000
X-Env-Sender: garvey.patrickd@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1321928010!53660960!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21249 invoked from network); 22 Nov 2011 02:13:31 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 02:13:31 -0000
Received: by yenm6 with SMTP id m6so2846842yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 18:13:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=q73CYqSxGl2DzUQRceoX3onCLNHiQBR4Ry9Pi4RPcsg=;
	b=QmryQdCQl+6bGaAoYzbm+MBXiZwGMiLxd71Augr/wgyOOwHcoRx18KLZCAJsLrY6jA
	IjjOOEr0+mfudbeMF9qRkdf0E/pC8CbpVCknurFKFVYdo+NKIW9mu8Ch2je2UgcWOgEm
	W5SYcVIiq96/eAXvPMG1wXCU5uGvipdmHs4Vk=
MIME-Version: 1.0
Received: by 10.182.117.103 with SMTP id kd7mr3542450obb.61.1321928038204;
	Mon, 21 Nov 2011 18:13:58 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Mon, 21 Nov 2011 18:13:58 -0800 (PST)
In-Reply-To: <1321903882.20464.5.camel@dagon.hellion.org.uk>
References: <CACm5R6Q6fue34RjeLbY_sQPNZtzJWpE3OK412o-O4hdXEh_4xg@mail.gmail.com>
	<1321903882.20464.5.camel@dagon.hellion.org.uk>
Date: Mon, 21 Nov 2011 18:13:58 -0800
Message-ID: <CACm5R6TdgSKHy_UAmF1y69y9sN1D-VXxKE9hS-HP7kyvzzjgLQ@mail.gmail.com>
From: "Patrick D. Garvey" <garvey.patrickd@gmail.com>
To: "Ian Campbell - Ian.Campbell@citrix.com"
	<+xen-devel+garveypatrickd+b6ec266a21.Ian.Campbell#citrix.com@spamgourmet.com>
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-devel.GarveyPatrickD@OrdinaryAmerican.net"
	<xen-devel.GarveyPatrickD@ordinaryamerican.net>
Subject: Re: [Xen-devel] Xen ReadMe's Was: Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 21, 2011 at 11:31 AM, Ian Campbell - Ian.Campbell@citrix.com wr=
ote:
> Please don't break threading.

My apologies, I thought the topic had changed sufficiently the subject
should be updated.  I won't be so quick to make such a change in the
future.

>
> On Mon, 2011-11-21 at 18:49 +0000,
> xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
>> On Mon, Nov 21, 2011 at 1:18 AM, Ian Campbell - Ian.Campbell@citrix.com =
wrote:
>> > On Sun, 2011-11-20 at 01:11 +0000,
>> > xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
>> >> http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_modu=
le
>> >> contains a link to the University of Cambridge Computer Laboratory
>> >> copy of the Xen User Manual
>> >> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html=
#SECTION03231300000000000000
>> >> that responds, "Forbidden
>> >> You don't have permission to access
>> >> /research/srg/netos/xen/readmes/user/user.html on this server."
>> >>
>> >> Does Xen.org have the right to copy the Xen User Manual onto its own =
server?
>> >
>> > That documentation is built from the Xen source tree (try installing
>> > latex2html then"make docs") and appears to be covered by the GPL so I
>> > think so.
>>
>> Does anyone know if the contents of
>> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/
>> is stored anywhere within the xen.org domain?
>
> Not as far as I know.
>
>> I don't, yet, have an installed copy of Xen
>
> You do not need to install Xen, you can simply build the docs in tree as
> I described above and point a browser or pdf read at them.
>

I believe this statement presumes I am operating from a system for
which "build the docs in tree" is a meaningful phrase and I know how
to perform such an action.  For the record, I am running a Dell
Inspiron 1300 on Windows XP Professional Service Pack 2 and working my
way to owning a lab machine where I can explore the depths of the *nix
family of operating systems. (I have the hardware set aside.)  At the
moment, I am qualified to work as a copy editor of such resources as a
project's wiki.  I find that's usually a gentle introduction to the
community knowledge and a valued contribution to the project.

>> =A0nor, as noted, access to
>> the Computer Lab copy of the ReadMe's, so I can't generate a
>> significant search string to help me locate them within Xen.org
>> domain.
>>
>> > However that particular doc is not well maintained (although the
>> > particular section which is referenced doesn't look so bad). IMHO it
>> > would be better to move the information onto the wiki itself (assuming
>> > it isn't already duplicated somewhere).
>>
>> As to maintaining the ReadMe's, is there anyone actively attempting to
>> maintain them?
>
> They have been pretty much unmaintained for many years now. They aren't
> actually README, despite the CL URL, they are most like reference
> manuals.
>
> The general feeling is that they should be replaced with a combination
> of wiki pages and in-tree documentation in some more friendly mark up
> language than tex, general preference seems to be markdown for regular
> documents or pod for manpages.
>
> Ian.

Well, until I am capable of reading tex, markdown, and pod and using
tools such as emacs or vi to manipulate them, it might be nice if
someone could place the reference manuals in a more accessible file
system so interested, potential project participants can read them for
the clues they may provide.

I'm going to assume it would be best for me to read the xen-devel
archives to derive my own understanding of what the project community
favors for the documents' format and make a proposal as to what I am
willing to do when I'm more capable of doing it.

Until then, I'll go back to participating in the migration of the Xen wiki.

Thank you for your assistance, Ian.

Patrick.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMh-0002RA-8v; Tue, 22 Nov 2011 09:10:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rick.jones2@hp.com>) id 1RRTQl-0001aO-NS
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:44:55 +0000
X-Env-Sender: rick.jones2@hp.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1321641870!4112856!1
X-Originating-IP: [15.193.32.62]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12106 invoked from network); 18 Nov 2011 18:44:31 -0000
Received: from g6t0185.atlanta.hp.com (HELO g6t0185.atlanta.hp.com)
	(15.193.32.62)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 18:44:31 -0000
Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141])
	by g6t0185.atlanta.hp.com (Postfix) with ESMTP id 526F6241B1;
	Fri, 18 Nov 2011 18:44:12 +0000 (UTC)
Received: from [16.89.64.213] (tardy.cup.hp.com [16.89.64.213])
	by g5t0029.atlanta.hp.com (Postfix) with ESMTP id 8694020046;
	Fri, 18 Nov 2011 18:44:11 +0000 (UTC)
Message-ID: <4EC6A778.1000503@hp.com>
Date: Fri, 18 Nov 2011 10:44:08 -0800
From: Rick Jones <rick.jones2@hp.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ben Hutchings <bhutchings@solarflare.com>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
In-Reply-To: <1321638394.2883.32.camel@bwh-desktop>
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Cc: netdev@vger.kernel.org, Olaf Hering <olaf@aepfle.de>,
	xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 09:46 AM, Ben Hutchings wrote:
> On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
>> Add .get_settings function, return fake data so that ethtool can get
>> enough information. For some application like VCS, this is useful,
>> otherwise some of application logic will get panic.
>> The reported data refers to VMWare vmxnet.
>>
>> Signed-off-by: Xin Wei Hu<xwhu@suse.com>
>> Signed-off-by: Chunyan Liu<cyliu@suse.com>
>> Signed-off-by: Olaf Hering<olaf@aepfle.de>
>
> NAK, we should not just make things up.

Which raises an interesting question for a virtual interface that isn't 
pretending to be a specific NIC type. What should the reported speed be? 
  Is it a 10/100 NIC?  A 1 or 10 GbE NIC? 3.14 GbE?  For other emulated 
interfaces, it rather falls-out from the emulation.  We can say that the 
driver may not make stuff up, but it would seem what is running in the 
host/hypervisor/dom0/whatever will have to.  It could I suppose, decide 
based on the physical NIC to which it is attached, so long as folks 
using the virtual NIC don't expect its attributes to be the same from 
system to system.

rick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMi-0002Rd-5l; Tue, 22 Nov 2011 09:10:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRUPh-0003N2-GB
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:47:53 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321645649!4120430!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9110 invoked from network); 18 Nov 2011 19:47:29 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-12.tower-216.messagelabs.com with SMTP;
	18 Nov 2011 19:47:29 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRUPI-0004uq-Th
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:47:28 +0000
Received: from mail-gx0-f176.google.com ([209.85.161.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRUPI-0004uk-NI for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Fri, 18 Nov 2011 19:47:28 +0000
Received: by ggnp1 with SMTP id p1so3243932ggn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Fri, 18 Nov 2011 11:47:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=AUWFGaJKxA4FuHrgBpIS7vP8aTSnY8jWReEoNzkT3nY=;
	b=bu1DdLebfD4I+2zDArZBcSHxG8TFIuGCYpeK9gTLKgaTQC9gGpFdgWtgRQkWkRLxOz
	HbHVC9jUX/KUoDek8XHP5VeCVjHIN9V+PS/9+81q3Zn5n40t1C/DNgm+VtxtYAh1vQQw
	aSzjMsjq0e1Orr0rK0jXZL/yggDAjl1Sk1GJU=
MIME-Version: 1.0
Received: by 10.182.217.73 with SMTP id ow9mr1041448obc.11.1321645648186; Fri,
	18 Nov 2011 11:47:28 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Fri, 18 Nov 2011 11:47:28 -0800 (PST)
Date: Fri, 18 Nov 2011 11:47:28 -0800
Message-ID: <CACm5R6To1kQnDZzqEVVo=afVSAeW-tDHGy3vznBpdxameJ+K8w@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Subject: [Xen-devel] Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_module
contains a link to the University of Cambridge Computer Laboratory
copy of the Xen User Manual
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03231300000000000000
that responds, "Forbidden
You don't have permission to access
/research/srg/netos/xen/readmes/user/user.html on this server."

Does Xen.org have the right to copy the Xen User Manual onto its own server?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMj-0002SI-HH; Tue, 22 Nov 2011 09:10:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <garvey.patrickd@gmail.com>) id 1RSfsM-0003XO-Lg
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 02:14:22 +0000
X-Env-Sender: garvey.patrickd@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1321928010!53660960!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21249 invoked from network); 22 Nov 2011 02:13:31 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 02:13:31 -0000
Received: by yenm6 with SMTP id m6so2846842yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 21 Nov 2011 18:13:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=q73CYqSxGl2DzUQRceoX3onCLNHiQBR4Ry9Pi4RPcsg=;
	b=QmryQdCQl+6bGaAoYzbm+MBXiZwGMiLxd71Augr/wgyOOwHcoRx18KLZCAJsLrY6jA
	IjjOOEr0+mfudbeMF9qRkdf0E/pC8CbpVCknurFKFVYdo+NKIW9mu8Ch2je2UgcWOgEm
	W5SYcVIiq96/eAXvPMG1wXCU5uGvipdmHs4Vk=
MIME-Version: 1.0
Received: by 10.182.117.103 with SMTP id kd7mr3542450obb.61.1321928038204;
	Mon, 21 Nov 2011 18:13:58 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Mon, 21 Nov 2011 18:13:58 -0800 (PST)
In-Reply-To: <1321903882.20464.5.camel@dagon.hellion.org.uk>
References: <CACm5R6Q6fue34RjeLbY_sQPNZtzJWpE3OK412o-O4hdXEh_4xg@mail.gmail.com>
	<1321903882.20464.5.camel@dagon.hellion.org.uk>
Date: Mon, 21 Nov 2011 18:13:58 -0800
Message-ID: <CACm5R6TdgSKHy_UAmF1y69y9sN1D-VXxKE9hS-HP7kyvzzjgLQ@mail.gmail.com>
From: "Patrick D. Garvey" <garvey.patrickd@gmail.com>
To: "Ian Campbell - Ian.Campbell@citrix.com"
	<+xen-devel+garveypatrickd+b6ec266a21.Ian.Campbell#citrix.com@spamgourmet.com>
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-devel.GarveyPatrickD@OrdinaryAmerican.net"
	<xen-devel.GarveyPatrickD@ordinaryamerican.net>
Subject: Re: [Xen-devel] Xen ReadMe's Was: Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 21, 2011 at 11:31 AM, Ian Campbell - Ian.Campbell@citrix.com wr=
ote:
> Please don't break threading.

My apologies, I thought the topic had changed sufficiently the subject
should be updated.  I won't be so quick to make such a change in the
future.

>
> On Mon, 2011-11-21 at 18:49 +0000,
> xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
>> On Mon, Nov 21, 2011 at 1:18 AM, Ian Campbell - Ian.Campbell@citrix.com =
wrote:
>> > On Sun, 2011-11-20 at 01:11 +0000,
>> > xen-devel.GarveyPatrickD@OrdinaryAmerican.net wrote:
>> >> http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_modu=
le
>> >> contains a link to the University of Cambridge Computer Laboratory
>> >> copy of the Xen User Manual
>> >> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html=
#SECTION03231300000000000000
>> >> that responds, "Forbidden
>> >> You don't have permission to access
>> >> /research/srg/netos/xen/readmes/user/user.html on this server."
>> >>
>> >> Does Xen.org have the right to copy the Xen User Manual onto its own =
server?
>> >
>> > That documentation is built from the Xen source tree (try installing
>> > latex2html then"make docs") and appears to be covered by the GPL so I
>> > think so.
>>
>> Does anyone know if the contents of
>> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/
>> is stored anywhere within the xen.org domain?
>
> Not as far as I know.
>
>> I don't, yet, have an installed copy of Xen
>
> You do not need to install Xen, you can simply build the docs in tree as
> I described above and point a browser or pdf read at them.
>

I believe this statement presumes I am operating from a system for
which "build the docs in tree" is a meaningful phrase and I know how
to perform such an action.  For the record, I am running a Dell
Inspiron 1300 on Windows XP Professional Service Pack 2 and working my
way to owning a lab machine where I can explore the depths of the *nix
family of operating systems. (I have the hardware set aside.)  At the
moment, I am qualified to work as a copy editor of such resources as a
project's wiki.  I find that's usually a gentle introduction to the
community knowledge and a valued contribution to the project.

>> =A0nor, as noted, access to
>> the Computer Lab copy of the ReadMe's, so I can't generate a
>> significant search string to help me locate them within Xen.org
>> domain.
>>
>> > However that particular doc is not well maintained (although the
>> > particular section which is referenced doesn't look so bad). IMHO it
>> > would be better to move the information onto the wiki itself (assuming
>> > it isn't already duplicated somewhere).
>>
>> As to maintaining the ReadMe's, is there anyone actively attempting to
>> maintain them?
>
> They have been pretty much unmaintained for many years now. They aren't
> actually README, despite the CL URL, they are most like reference
> manuals.
>
> The general feeling is that they should be replaced with a combination
> of wiki pages and in-tree documentation in some more friendly mark up
> language than tex, general preference seems to be markdown for regular
> documents or pod for manpages.
>
> Ian.

Well, until I am capable of reading tex, markdown, and pod and using
tools such as emacs or vi to manipulate them, it might be nice if
someone could place the reference manuals in a more accessible file
system so interested, potential project participants can read them for
the clues they may provide.

I'm going to assume it would be best for me to read the xen-devel
archives to derive my own understanding of what the project community
favors for the documents' format and make a proposal as to what I am
willing to do when I'm more capable of doing it.

Until then, I'll go back to participating in the migration of the Xen wiki.

Thank you for your assistance, Ian.

Patrick.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMh-0002RA-8v; Tue, 22 Nov 2011 09:10:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rick.jones2@hp.com>) id 1RRTQl-0001aO-NS
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:44:55 +0000
X-Env-Sender: rick.jones2@hp.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1321641870!4112856!1
X-Originating-IP: [15.193.32.62]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12106 invoked from network); 18 Nov 2011 18:44:31 -0000
Received: from g6t0185.atlanta.hp.com (HELO g6t0185.atlanta.hp.com)
	(15.193.32.62)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 18:44:31 -0000
Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141])
	by g6t0185.atlanta.hp.com (Postfix) with ESMTP id 526F6241B1;
	Fri, 18 Nov 2011 18:44:12 +0000 (UTC)
Received: from [16.89.64.213] (tardy.cup.hp.com [16.89.64.213])
	by g5t0029.atlanta.hp.com (Postfix) with ESMTP id 8694020046;
	Fri, 18 Nov 2011 18:44:11 +0000 (UTC)
Message-ID: <4EC6A778.1000503@hp.com>
Date: Fri, 18 Nov 2011 10:44:08 -0800
From: Rick Jones <rick.jones2@hp.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ben Hutchings <bhutchings@solarflare.com>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
In-Reply-To: <1321638394.2883.32.camel@bwh-desktop>
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Cc: netdev@vger.kernel.org, Olaf Hering <olaf@aepfle.de>,
	xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: report link speed to ethtool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 09:46 AM, Ben Hutchings wrote:
> On Fri, 2011-11-18 at 17:48 +0100, Olaf Hering wrote:
>> Add .get_settings function, return fake data so that ethtool can get
>> enough information. For some application like VCS, this is useful,
>> otherwise some of application logic will get panic.
>> The reported data refers to VMWare vmxnet.
>>
>> Signed-off-by: Xin Wei Hu<xwhu@suse.com>
>> Signed-off-by: Chunyan Liu<cyliu@suse.com>
>> Signed-off-by: Olaf Hering<olaf@aepfle.de>
>
> NAK, we should not just make things up.

Which raises an interesting question for a virtual interface that isn't 
pretending to be a specific NIC type. What should the reported speed be? 
  Is it a 10/100 NIC?  A 1 or 10 GbE NIC? 3.14 GbE?  For other emulated 
interfaces, it rather falls-out from the emulation.  We can say that the 
driver may not make stuff up, but it would seem what is running in the 
host/hypervisor/dom0/whatever will have to.  It could I suppose, decide 
based on the physical NIC to which it is attached, so long as folks 
using the virtual NIC don't expect its attributes to be the same from 
system to system.

rick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMi-0002Rd-5l; Tue, 22 Nov 2011 09:10:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRUPh-0003N2-GB
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:47:53 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321645649!4120430!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9110 invoked from network); 18 Nov 2011 19:47:29 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-12.tower-216.messagelabs.com with SMTP;
	18 Nov 2011 19:47:29 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRUPI-0004uq-Th
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 19:47:28 +0000
Received: from mail-gx0-f176.google.com ([209.85.161.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRUPI-0004uk-NI for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Fri, 18 Nov 2011 19:47:28 +0000
Received: by ggnp1 with SMTP id p1so3243932ggn.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Fri, 18 Nov 2011 11:47:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=AUWFGaJKxA4FuHrgBpIS7vP8aTSnY8jWReEoNzkT3nY=;
	b=bu1DdLebfD4I+2zDArZBcSHxG8TFIuGCYpeK9gTLKgaTQC9gGpFdgWtgRQkWkRLxOz
	HbHVC9jUX/KUoDek8XHP5VeCVjHIN9V+PS/9+81q3Zn5n40t1C/DNgm+VtxtYAh1vQQw
	aSzjMsjq0e1Orr0rK0jXZL/yggDAjl1Sk1GJU=
MIME-Version: 1.0
Received: by 10.182.217.73 with SMTP id ow9mr1041448obc.11.1321645648186; Fri,
	18 Nov 2011 11:47:28 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Fri, 18 Nov 2011 11:47:28 -0800 (PST)
Date: Fri, 18 Nov 2011 11:47:28 -0800
Message-ID: <CACm5R6To1kQnDZzqEVVo=afVSAeW-tDHGy3vznBpdxameJ+K8w@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Subject: [Xen-devel] Inaccessible link
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

http://wiki.xen.org/wiki/Assign_Hardware_to_DomU_with_PCIBack_as_module
contains a link to the University of Cambridge Computer Laboratory
copy of the Xen User Manual
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03231300000000000000
that responds, "Forbidden
You don't have permission to access
/research/srg/netos/xen/readmes/user/user.html on this server."

Does Xen.org have the right to copy the Xen User Manual onto its own server?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMi-0002Rp-Kb; Tue, 22 Nov 2011 09:10:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shuklin@selectel.ru>) id 1RRblu-0000JA-A2
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 03:39:18 +0000
X-Env-Sender: shuklin@selectel.ru
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321673933!4144064!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14811 invoked from network); 19 Nov 2011 03:38:53 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 03:38:53 -0000
Received: by bkbzt12 with SMTP id zt12so5923761bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 19:38:53 -0800 (PST)
Received: by 10.204.152.25 with SMTP id e25mr6021607bkw.51.1321673933245;
	Fri, 18 Nov 2011 19:38:53 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id e8sm2165980bkd.7.2011.11.18.19.38.51
	(version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 19:38:52 -0800 (PST)
Message-ID: <4EC724CA.7040609@selectel.ru>
Date: Sat, 19 Nov 2011 07:38:50 +0400
From: George Shuklin <shuklin@selectel.ru>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111107 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Subject: [Xen-devel] pvgrub --> kexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Good day.

Right now we have pvgrub and pygrub as loaders. Pygrub is more mature, 
pvgrub is safer and  more 'right' stuff to have.

But even the pvgrub is still have one real problem: we need to write our 
own domU operating system with support of bunch of filesystems, hardly 
to create interactivity, limited network capabilities (...yep, I can be 
nice to have networking at boot time).

How about different approach? If we run linux with specially crafted 
initrd, which will look around, see correct partition, mount it (in 
domU!), get kernel, show menu, do networking and prepare the coffee for 
admin.  After that it will to kexec to found kernel with found initrd 
with required argument.

No any dangerous dom0 manipulation with VDI, no more modules 
synchronization problem (in case 'external' kernel loading). Easy to 
create menus (just any ncurses application), ideal pre-boot 
configuration environment for appliances (I ask user about settings and 
boot real kernel with asked parameters).

The single problem: kexec is not supporting xen.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMg-0002R1-Rs; Tue, 22 Nov 2011 09:10:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRTM3-0001TG-Sz
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:40:04 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321641579!4787416!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20164 invoked from network); 18 Nov 2011 18:39:39 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-16.tower-21.messagelabs.com with SMTP;
	18 Nov 2011 18:39:39 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRTLf-0002Hx-4u
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:39:39 +0000
Received: from mail-yw0-f48.google.com ([209.85.213.48])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRTLe-0002H1-NG for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Fri, 18 Nov 2011 18:39:38 +0000
Received: by ywb26 with SMTP id 26so3169128ywb.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Fri, 18 Nov 2011 10:39:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=aqrVa8vo6ZuOTUjqcKppM++MREe4aOKue4q3J0J+NNo=;
	b=cgKSs32ndw30B3vo60YVlcuoxOMGhgTXxYoMh0OnPs++ZySlhmVtLU5bZVok//AKxZ
	t+Cy8WccpE1fkTe9XCBQBI611FEENUPC9blRXKEA44jbTNbOjnlmj0qkkASWIhHGLZHF
	K+UKk/oMaZaK2t82RtHRrftF4Se0weZ2TWpZo=
MIME-Version: 1.0
Received: by 10.182.37.71 with SMTP id w7mr978142obj.41.1321641578189; Fri, 18
	Nov 2011 10:39:38 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Fri, 18 Nov 2011 10:39:38 -0800 (PST)
Date: Fri, 18 Nov 2011 10:39:38 -0800
Message-ID: <CACm5R6QthEEJH6R0_jEaoLe4C_tzNLC4ajK=Xd-StsYCm6Ua+Q@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Subject: [Xen-devel] wiki.xen.org Page structure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Browsing through wiki.xen.org, I see several pages formatted like
http://wiki.xen.org/wiki/AskingXenDevelQuestions
It has one first level header and several second level headers.  The
first level header also seems more appropriate as the page title,
especially when it is a paraphrase of the page file name.  It seems to
me, "How to get your question answered on xen-devel" is better English
than "AskingXenDevelQuestions".

May I move such pages to their first header as a file name and
eliminate the first level of headers on such pages?  Maybe we can
follow that with the elimination of the original file that will have
become a mere redirect with the move?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMi-0002Rp-Kb; Tue, 22 Nov 2011 09:10:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shuklin@selectel.ru>) id 1RRblu-0000JA-A2
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 03:39:18 +0000
X-Env-Sender: shuklin@selectel.ru
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321673933!4144064!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14811 invoked from network); 19 Nov 2011 03:38:53 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Nov 2011 03:38:53 -0000
Received: by bkbzt12 with SMTP id zt12so5923761bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 18 Nov 2011 19:38:53 -0800 (PST)
Received: by 10.204.152.25 with SMTP id e25mr6021607bkw.51.1321673933245;
	Fri, 18 Nov 2011 19:38:53 -0800 (PST)
Received: from [192.168.0.220] (desunote.ru. [95.161.2.76])
	by mx.google.com with ESMTPS id e8sm2165980bkd.7.2011.11.18.19.38.51
	(version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 19:38:52 -0800 (PST)
Message-ID: <4EC724CA.7040609@selectel.ru>
Date: Sat, 19 Nov 2011 07:38:50 +0400
From: George Shuklin <shuklin@selectel.ru>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111107 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Subject: [Xen-devel] pvgrub --> kexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Good day.

Right now we have pvgrub and pygrub as loaders. Pygrub is more mature, 
pvgrub is safer and  more 'right' stuff to have.

But even the pvgrub is still have one real problem: we need to write our 
own domU operating system with support of bunch of filesystems, hardly 
to create interactivity, limited network capabilities (...yep, I can be 
nice to have networking at boot time).

How about different approach? If we run linux with specially crafted 
initrd, which will look around, see correct partition, mount it (in 
domU!), get kernel, show menu, do networking and prepare the coffee for 
admin.  After that it will to kexec to found kernel with found initrd 
with required argument.

No any dangerous dom0 manipulation with VDI, no more modules 
synchronization problem (in case 'external' kernel loading). Easy to 
create menus (just any ncurses application), ideal pre-boot 
configuration environment for appliances (I ask user about settings and 
boot real kernel with asked parameters).

The single problem: kexec is not supporting xen.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMg-0002R1-Rs; Tue, 22 Nov 2011 09:10:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRTM3-0001TG-Sz
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:40:04 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321641579!4787416!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20164 invoked from network); 18 Nov 2011 18:39:39 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-16.tower-21.messagelabs.com with SMTP;
	18 Nov 2011 18:39:39 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRTLf-0002Hx-4u
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:39:39 +0000
Received: from mail-yw0-f48.google.com ([209.85.213.48])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRTLe-0002H1-NG for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Fri, 18 Nov 2011 18:39:38 +0000
Received: by ywb26 with SMTP id 26so3169128ywb.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Fri, 18 Nov 2011 10:39:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=aqrVa8vo6ZuOTUjqcKppM++MREe4aOKue4q3J0J+NNo=;
	b=cgKSs32ndw30B3vo60YVlcuoxOMGhgTXxYoMh0OnPs++ZySlhmVtLU5bZVok//AKxZ
	t+Cy8WccpE1fkTe9XCBQBI611FEENUPC9blRXKEA44jbTNbOjnlmj0qkkASWIhHGLZHF
	K+UKk/oMaZaK2t82RtHRrftF4Se0weZ2TWpZo=
MIME-Version: 1.0
Received: by 10.182.37.71 with SMTP id w7mr978142obj.41.1321641578189; Fri, 18
	Nov 2011 10:39:38 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Fri, 18 Nov 2011 10:39:38 -0800 (PST)
Date: Fri, 18 Nov 2011 10:39:38 -0800
Message-ID: <CACm5R6QthEEJH6R0_jEaoLe4C_tzNLC4ajK=Xd-StsYCm6Ua+Q@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Subject: [Xen-devel] wiki.xen.org Page structure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Browsing through wiki.xen.org, I see several pages formatted like
http://wiki.xen.org/wiki/AskingXenDevelQuestions
It has one first level header and several second level headers.  The
first level header also seems more appropriate as the page title,
especially when it is a paraphrase of the page file name.  It seems to
me, "How to get your question answered on xen-devel" is better English
than "AskingXenDevelQuestions".

May I move such pages to their first header as a file name and
eliminate the first level of headers on such pages?  Maybe we can
follow that with the elimination of the original file that will have
become a mere redirect with the move?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMh-0002RN-Mg; Tue, 22 Nov 2011 09:10:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rick.jones2@hp.com>) id 1RRTfJ-00022v-TN
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:59:58 +0000
X-Env-Sender: rick.jones2@hp.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321642772!2138515!1
X-Originating-IP: [15.193.32.62]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29527 invoked from network); 18 Nov 2011 18:59:33 -0000
Received: from g6t0185.atlanta.hp.com (HELO g6t0185.atlanta.hp.com)
	(15.193.32.62)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 18:59:33 -0000
Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141])
	by g6t0185.atlanta.hp.com (Postfix) with ESMTP id B834524B5C;
	Fri, 18 Nov 2011 18:59:01 +0000 (UTC)
Received: from [16.89.64.213] (tardy.cup.hp.com [16.89.64.213])
	by g5t0029.atlanta.hp.com (Postfix) with ESMTP id 780D42001C;
	Fri, 18 Nov 2011 18:59:00 +0000 (UTC)
Message-ID: <4EC6AAF3.6080803@hp.com>
Date: Fri, 18 Nov 2011 10:58:59 -0800
From: Rick Jones <rick.jones2@hp.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
	<4EC6A778.1000503@hp.com> <4EC6A802.9090805@goop.org>
In-Reply-To: <4EC6A802.9090805@goop.org>
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Cc: Ben Hutchings <bhutchings@solarflare.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] use a special value of -2 for virtual devices to report
 indeterminate speed?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 10:46 AM, Jeremy Fitzhardinge wrote:
> On 11/18/2011 10:44 AM, Rick Jones wrote:
>>   It could I suppose, decide
>> based on the physical NIC to which it is attached, so long as folks
>> using the virtual NIC don't expect its attributes to be the same from
>> system to system.
>
> And assuming there's a physical NIC at all.

It sounds like we need a way to specify "Indeterminate" for link speed? 
  Or some verbiage to that effect. Right now 0 and -1 cause ethtool to 
report "Unknown!"

         if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
                 fprintf(stdout, "Unknown!\n");
         else
                 fprintf(stdout, "%uMb/s\n", speed);


How about -2 for the u32 cast value of speed returning "Indeterminate" 
or something like that?  Not in "proper" patch format:

	if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
		fprintf(stdout, "Unknown!\n");
	else if (speed == (u32)(-2))
		fprintf(stdout, "Indeterminate.");
	else
		fprintf(stdout, "%uMb/s\n", speed);

Signed-off-by: Rick Jones <rick.jones2@hp.com>	

rick jones

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMg-0002Qt-EW; Tue, 22 Nov 2011 09:10:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRQkJ-0005v9-MY
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:52:55 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321631551!4084919!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7460 invoked from network); 18 Nov 2011 15:52:31 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-6.tower-216.messagelabs.com with SMTP;
	18 Nov 2011 15:52:31 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRQju-0008Hu-PC
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:52:30 +0000
Received: from mail-yx0-f176.google.com ([209.85.213.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRQju-0008HX-FF for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Fri, 18 Nov 2011 15:52:30 +0000
Received: by yenq10 with SMTP id q10so2951943yen.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Fri, 18 Nov 2011 07:52:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=K9YUrr4GHE1alK7d6fRhMLQAjAxvpcQ/Q+EyS4ZzJJc=;
	b=aRZHtRn7j1gnAaM78D/Y3FHjHGDhPe8Bjr7BR4pesTe+FYbJ7L2GcsdaDmIhP2EkA4
	2nroOcfSvwZcaTfSBdBxc/YR0xP8UdeZnrVWsOTceSOjPNQoL219CsiJNPM3C6lF0kHg
	uOH0koP2TDVMOp4D8xN6ZHh95AiOvhRqanZ70=
MIME-Version: 1.0
Received: by 10.182.37.71 with SMTP id w7mr815465obj.41.1321631549877; Fri, 18
	Nov 2011 07:52:29 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Fri, 18 Nov 2011 07:52:29 -0800 (PST)
Date: Fri, 18 Nov 2011 07:52:29 -0800
Message-ID: <CACm5R6QtG3LYGkUw-Js6w3G5Gj61Cox0LrN0Cay=q_Z0k5fL4Q@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Subject: [Xen-devel] HTML in wikitext
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

According to https://secure.wikimedia.org/wikipedia/en/wiki/Help:HTML_in_wikitext#Permitted_HTML
<abbr title="abbreviation">abbr.</abbr> should be parsed as HTML by
the wiki server.

According to my experiment,
http://wiki.xen.org/wiki/User:GarveyPatrickD/Abbreviations
the Xen wiki doesn't seem to have this feature enabled.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMj-0002S2-4D; Tue, 22 Nov 2011 09:10:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olivier.beeckmans@gmail.com>) id 1RRjaj-0002xQ-4w
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 12:00:17 +0000
X-Env-Sender: olivier.beeckmans@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321703953!63828919!1
X-Originating-IP: [216.139.236.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4512 invoked from network); 19 Nov 2011 11:59:14 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Nov 2011 11:59:14 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <olivier.beeckmans@gmail.com>) id 1RRjaJ-0003DM-Of
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 03:59:51 -0800
Date: Sat, 19 Nov 2011 03:59:51 -0800 (PST)
From: "beeckmans.o" <olivier.beeckmans@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1321703991752-5006651.post@n5.nabble.com>
In-Reply-To: <20101119065730.GQ2754@reaktio.net>
References: <20101118200025.GH2754@reaktio.net> <4CE5FD53.8060804@alteeve.com>
	<20101119065730.GQ2754@reaktio.net>
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Subject: Re: [Xen-devel] [Xen-users] [HOWTO] Running Xen 4.0 host (dom0)
 with Redhat Enterprise Linux 6 (RHEL6)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2553548064518413243=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2553548064518413243==
Content-Type: multipart/alternative; 
	boundary="----=_Part_124505_17660024.1321703991759"

------=_Part_124505_17660024.1321703991759
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks Digimer for this respons.

I've booted in non xen environement. And the xencapstest PASS now

Many Thanks

Olivier

--
View this message in context: http://xen.1045712.n5.nabble.com/HOWTO-Running-Xen-4-0-host-dom0-with-Redhat-Enterprise-Linux-6-RHEL6-tp3271407p5006651.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_124505_17660024.1321703991759
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks Digimer for this respons.

I've booted in non xen environement. And the xencapstest PASS now

Many Thanks

Olivier
	
<br/><hr align="left" width="300" />
View this message in context: <a href="http://xen.1045712.n5.nabble.com/HOWTO-Running-Xen-4-0-host-dom0-with-Redhat-Enterprise-Linux-6-RHEL6-tp3271407p5006651.html">Re: [Xen-users] [HOWTO] Running Xen 4.0 host (dom0) with Redhat Enterprise Linux 6 (RHEL6)</a><br/>
Sent from the <a href="http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.html">Xen - Dev mailing list archive</a> at Nabble.com.<br/>
------=_Part_124505_17660024.1321703991759--


--===============2553548064518413243==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2553548064518413243==--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMg-0002Qt-EW; Tue, 22 Nov 2011 09:10:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRQkJ-0005v9-MY
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:52:55 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321631551!4084919!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7460 invoked from network); 18 Nov 2011 15:52:31 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-6.tower-216.messagelabs.com with SMTP;
	18 Nov 2011 15:52:31 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRQju-0008Hu-PC
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 15:52:30 +0000
Received: from mail-yx0-f176.google.com ([209.85.213.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RRQju-0008HX-FF for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Fri, 18 Nov 2011 15:52:30 +0000
Received: by yenq10 with SMTP id q10so2951943yen.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Fri, 18 Nov 2011 07:52:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=K9YUrr4GHE1alK7d6fRhMLQAjAxvpcQ/Q+EyS4ZzJJc=;
	b=aRZHtRn7j1gnAaM78D/Y3FHjHGDhPe8Bjr7BR4pesTe+FYbJ7L2GcsdaDmIhP2EkA4
	2nroOcfSvwZcaTfSBdBxc/YR0xP8UdeZnrVWsOTceSOjPNQoL219CsiJNPM3C6lF0kHg
	uOH0koP2TDVMOp4D8xN6ZHh95AiOvhRqanZ70=
MIME-Version: 1.0
Received: by 10.182.37.71 with SMTP id w7mr815465obj.41.1321631549877; Fri, 18
	Nov 2011 07:52:29 -0800 (PST)
Received: by 10.182.55.194 with HTTP; Fri, 18 Nov 2011 07:52:29 -0800 (PST)
Date: Fri, 18 Nov 2011 07:52:29 -0800
Message-ID: <CACm5R6QtG3LYGkUw-Js6w3G5Gj61Cox0LrN0Cay=q_Z0k5fL4Q@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Subject: [Xen-devel] HTML in wikitext
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

According to https://secure.wikimedia.org/wikipedia/en/wiki/Help:HTML_in_wikitext#Permitted_HTML
<abbr title="abbreviation">abbr.</abbr> should be parsed as HTML by
the wiki server.

According to my experiment,
http://wiki.xen.org/wiki/User:GarveyPatrickD/Abbreviations
the Xen wiki doesn't seem to have this feature enabled.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMj-0002S2-4D; Tue, 22 Nov 2011 09:10:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olivier.beeckmans@gmail.com>) id 1RRjaj-0002xQ-4w
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 12:00:17 +0000
X-Env-Sender: olivier.beeckmans@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321703953!63828919!1
X-Originating-IP: [216.139.236.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4512 invoked from network); 19 Nov 2011 11:59:14 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	19 Nov 2011 11:59:14 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <olivier.beeckmans@gmail.com>) id 1RRjaJ-0003DM-Of
	for xen-devel@lists.xensource.com; Sat, 19 Nov 2011 03:59:51 -0800
Date: Sat, 19 Nov 2011 03:59:51 -0800 (PST)
From: "beeckmans.o" <olivier.beeckmans@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1321703991752-5006651.post@n5.nabble.com>
In-Reply-To: <20101119065730.GQ2754@reaktio.net>
References: <20101118200025.GH2754@reaktio.net> <4CE5FD53.8060804@alteeve.com>
	<20101119065730.GQ2754@reaktio.net>
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Subject: Re: [Xen-devel] [Xen-users] [HOWTO] Running Xen 4.0 host (dom0)
 with Redhat Enterprise Linux 6 (RHEL6)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2553548064518413243=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2553548064518413243==
Content-Type: multipart/alternative; 
	boundary="----=_Part_124505_17660024.1321703991759"

------=_Part_124505_17660024.1321703991759
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks Digimer for this respons.

I've booted in non xen environement. And the xencapstest PASS now

Many Thanks

Olivier

--
View this message in context: http://xen.1045712.n5.nabble.com/HOWTO-Running-Xen-4-0-host-dom0-with-Redhat-Enterprise-Linux-6-RHEL6-tp3271407p5006651.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_124505_17660024.1321703991759
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks Digimer for this respons.

I've booted in non xen environement. And the xencapstest PASS now

Many Thanks

Olivier
	
<br/><hr align="left" width="300" />
View this message in context: <a href="http://xen.1045712.n5.nabble.com/HOWTO-Running-Xen-4-0-host-dom0-with-Redhat-Enterprise-Linux-6-RHEL6-tp3271407p5006651.html">Re: [Xen-users] [HOWTO] Running Xen 4.0 host (dom0) with Redhat Enterprise Linux 6 (RHEL6)</a><br/>
Sent from the <a href="http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.html">Xen - Dev mailing list archive</a> at Nabble.com.<br/>
------=_Part_124505_17660024.1321703991759--


--===============2553548064518413243==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2553548064518413243==--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmMh-0002RN-Mg; Tue, 22 Nov 2011 09:10:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rick.jones2@hp.com>) id 1RRTfJ-00022v-TN
	for xen-devel@lists.xensource.com; Fri, 18 Nov 2011 18:59:58 +0000
X-Env-Sender: rick.jones2@hp.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321642772!2138515!1
X-Originating-IP: [15.193.32.62]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29527 invoked from network); 18 Nov 2011 18:59:33 -0000
Received: from g6t0185.atlanta.hp.com (HELO g6t0185.atlanta.hp.com)
	(15.193.32.62)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Nov 2011 18:59:33 -0000
Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141])
	by g6t0185.atlanta.hp.com (Postfix) with ESMTP id B834524B5C;
	Fri, 18 Nov 2011 18:59:01 +0000 (UTC)
Received: from [16.89.64.213] (tardy.cup.hp.com [16.89.64.213])
	by g5t0029.atlanta.hp.com (Postfix) with ESMTP id 780D42001C;
	Fri, 18 Nov 2011 18:59:00 +0000 (UTC)
Message-ID: <4EC6AAF3.6080803@hp.com>
Date: Fri, 18 Nov 2011 10:58:59 -0800
From: Rick Jones <rick.jones2@hp.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>
References: <20111118164805.GA14345@aepfle.de>
	<1321638394.2883.32.camel@bwh-desktop>
	<4EC6A778.1000503@hp.com> <4EC6A802.9090805@goop.org>
In-Reply-To: <4EC6A802.9090805@goop.org>
X-Mailman-Approved-At: Tue, 22 Nov 2011 09:10:05 +0000
Cc: Ben Hutchings <bhutchings@solarflare.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] use a special value of -2 for virtual devices to report
 indeterminate speed?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/18/2011 10:46 AM, Jeremy Fitzhardinge wrote:
> On 11/18/2011 10:44 AM, Rick Jones wrote:
>>   It could I suppose, decide
>> based on the physical NIC to which it is attached, so long as folks
>> using the virtual NIC don't expect its attributes to be the same from
>> system to system.
>
> And assuming there's a physical NIC at all.

It sounds like we need a way to specify "Indeterminate" for link speed? 
  Or some verbiage to that effect. Right now 0 and -1 cause ethtool to 
report "Unknown!"

         if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
                 fprintf(stdout, "Unknown!\n");
         else
                 fprintf(stdout, "%uMb/s\n", speed);


How about -2 for the u32 cast value of speed returning "Indeterminate" 
or something like that?  Not in "proper" patch format:

	if (speed == 0 || speed == (u16)(-1) || speed == (u32)(-1))
		fprintf(stdout, "Unknown!\n");
	else if (speed == (u32)(-2))
		fprintf(stdout, "Indeterminate.");
	else
		fprintf(stdout, "%uMb/s\n", speed);

Signed-off-by: Rick Jones <rick.jones2@hp.com>	

rick jones

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmN1-0002fL-7F; Tue, 22 Nov 2011 09:10:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSmN0-0002ZZ-17
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 09:10:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321952997!2455329!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7990 invoked from network); 22 Nov 2011 09:09:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 09:09:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9057084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 09:09:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 09:09:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Tue, 22 Nov 2011 09:09:56 +0000
In-Reply-To: <CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321952996.3664.401.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 08:38 +0000, Teck Choon Giam wrote:
> On Tue, Nov 22, 2011 at 4:31 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
> >> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
> >> > [...]
> >> >> memory = 15360
> >> >> maxmem = 15360
> >> > [...]
> >> >> How much RAM does the host system have? What are your hypervisor and
> >> >> > dom0 command lines.
> >> >>
> >> >> 16GB RAM.
> >> >
> >> > So you are assigning 15GB out of a total of 16GB to the guest which
> >> > necessitates ballooning dom0 from 16GB down to 1GB.
> >>
> >> I actually set dom0-min-mem 512 in xend-config.sxp as well.
> >
> > xl/libxl don't use this configuration file.
> 
> Oh... now then I know.  I always test with both xl and xm for my
> testing machine(s) to see any differences as there are... ...

I believe xend and xl do behave slightly differently wrt dom0 auto
ballooning.

> 
> >
> >>
> >> >
> >> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
> >> >>       root (hd0,0)
> >> >>       kernel /xen.gz dom0_mem=512M loglvl=all guest_loglvl=all cpuidle=0 cpufreq=none
> >> >
> >> > But you have already forced the dom0_mem to 512M. I suspect this is
> >> > colluding with the above ballooning to make it look as if dom0 should be
> >> > ballooned to <128M, which causes xl to print a warning message. Perhaps
> >> > someone who understands this stuff can comment on whether or not this
> >> > should be the case.
> >> >
> >> > Can you try setting "autoballoon=0" in /etc/xl.cfg.
> >>
> >> You mean /etc/xen/xl.conf?  I have done so and guess what?  IT WORKS!!! :)
> >
> > Great.
> 
> That means default value changed if it is unset for autoballoon?
> Original one is commented with #autoballoon = 1 in /etc/xen/xl.conf so
> it is unset I guess so the default value for autoballoon for c/s 23110
> is autoballoon=0 where c/s 23190 is autoballoon=1?  Just some
> guessing... ...

Can you give the full changeset numbers of what you see as 23110 and
23190 please, the short numbers are not globally stable and in my
version that file is identical in both.

Ian.
 
> 
> >
> > Ian.
> 
> Thanks.
> 
> Kindest regards,
> Giam Teck Choon



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:10:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:10:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmN1-0002fL-7F; Tue, 22 Nov 2011 09:10:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSmN0-0002ZZ-17
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 09:10:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1321952997!2455329!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7990 invoked from network); 22 Nov 2011 09:09:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 09:09:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9057084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 09:09:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 09:09:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Tue, 22 Nov 2011 09:09:56 +0000
In-Reply-To: <CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321952996.3664.401.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 08:38 +0000, Teck Choon Giam wrote:
> On Tue, Nov 22, 2011 at 4:31 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
> >> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
> >> > [...]
> >> >> memory = 15360
> >> >> maxmem = 15360
> >> > [...]
> >> >> How much RAM does the host system have? What are your hypervisor and
> >> >> > dom0 command lines.
> >> >>
> >> >> 16GB RAM.
> >> >
> >> > So you are assigning 15GB out of a total of 16GB to the guest which
> >> > necessitates ballooning dom0 from 16GB down to 1GB.
> >>
> >> I actually set dom0-min-mem 512 in xend-config.sxp as well.
> >
> > xl/libxl don't use this configuration file.
> 
> Oh... now then I know.  I always test with both xl and xm for my
> testing machine(s) to see any differences as there are... ...

I believe xend and xl do behave slightly differently wrt dom0 auto
ballooning.

> 
> >
> >>
> >> >
> >> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
> >> >>       root (hd0,0)
> >> >>       kernel /xen.gz dom0_mem=512M loglvl=all guest_loglvl=all cpuidle=0 cpufreq=none
> >> >
> >> > But you have already forced the dom0_mem to 512M. I suspect this is
> >> > colluding with the above ballooning to make it look as if dom0 should be
> >> > ballooned to <128M, which causes xl to print a warning message. Perhaps
> >> > someone who understands this stuff can comment on whether or not this
> >> > should be the case.
> >> >
> >> > Can you try setting "autoballoon=0" in /etc/xl.cfg.
> >>
> >> You mean /etc/xen/xl.conf?  I have done so and guess what?  IT WORKS!!! :)
> >
> > Great.
> 
> That means default value changed if it is unset for autoballoon?
> Original one is commented with #autoballoon = 1 in /etc/xen/xl.conf so
> it is unset I guess so the default value for autoballoon for c/s 23110
> is autoballoon=0 where c/s 23190 is autoballoon=1?  Just some
> guessing... ...

Can you give the full changeset numbers of what you see as 23110 and
23190 please, the short numbers are not globally stable and in my
version that file is identical in both.

Ian.
 
> 
> >
> > Ian.
> 
> Thanks.
> 
> Kindest regards,
> Giam Teck Choon



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:30:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:30:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmgC-0004WG-Le; Tue, 22 Nov 2011 09:30:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSmgB-0004W8-Gf
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 09:30:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321954187!5188489!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3343 invoked from network); 22 Nov 2011 09:29:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 09:29:47 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9057711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 09:29:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 09:29:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "annie.li@oracle.com" <annie.li@oracle.com>
Date: Tue, 22 Nov 2011 09:29:46 +0000
In-Reply-To: <1321927161-3987-1-git-send-email-annie.li@oracle.com>
References: <4ECA416D.90602@oracle.com>
	<1321927161-3987-1-git-send-email-annie.li@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321954186.3664.403.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 01:59 +0000, annie.li@oracle.com wrote:
[...]
> +#ifdef CONFIG_X86
> +		barrier();
> +#else
> +		mb();
> +#endif
> +		}

Niggle: Indentation of this final } is off.

Otherwise all 4 patches:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

[...]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:30:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:30:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmgC-0004WG-Le; Tue, 22 Nov 2011 09:30:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSmgB-0004W8-Gf
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 09:30:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321954187!5188489!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3343 invoked from network); 22 Nov 2011 09:29:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 09:29:47 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9057711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 09:29:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 09:29:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "annie.li@oracle.com" <annie.li@oracle.com>
Date: Tue, 22 Nov 2011 09:29:46 +0000
In-Reply-To: <1321927161-3987-1-git-send-email-annie.li@oracle.com>
References: <4ECA416D.90602@oracle.com>
	<1321927161-3987-1-git-send-email-annie.li@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1321954186.3664.403.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 01:59 +0000, annie.li@oracle.com wrote:
[...]
> +#ifdef CONFIG_X86
> +		barrier();
> +#else
> +		mb();
> +#endif
> +		}

Niggle: Indentation of this final } is off.

Otherwise all 4 patches:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

[...]


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:44:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:44:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmtd-0004lz-7p; Tue, 22 Nov 2011 09:44:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSmtc-0004lu-46
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 09:44:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321954991!44876087!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27902 invoked from network); 22 Nov 2011 09:43:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 09:43:11 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9058104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 09:43:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 09:43:43 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSmtD-00036h-Jg;
	Tue, 22 Nov 2011 09:43:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSmtD-0003To-FH;
	Tue, 22 Nov 2011 09:43:43 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9956-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 09:43:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9956: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9956 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9956/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  0a0c02a61676
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=0a0c02a61676
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 0a0c02a61676
+ branch=xen-unstable
+ revision=0a0c02a61676
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 0a0c02a61676 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 15 changesets with 42 changes to 32 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 09:44:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 09:44:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSmtd-0004lz-7p; Tue, 22 Nov 2011 09:44:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSmtc-0004lu-46
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 09:44:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321954991!44876087!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27902 invoked from network); 22 Nov 2011 09:43:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 09:43:11 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9058104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 09:43:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 09:43:43 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSmtD-00036h-Jg;
	Tue, 22 Nov 2011 09:43:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSmtD-0003To-FH;
	Tue, 22 Nov 2011 09:43:43 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-9956-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 09:43:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9956: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9956 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9956/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  0a0c02a61676
baseline version:
 xen                  dbdc840f8f62

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Charles Arnold <carnold@suse.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=0a0c02a61676
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 0a0c02a61676
+ branch=xen-unstable
+ revision=0a0c02a61676
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 0a0c02a61676 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 15 changesets with 42 changes to 32 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:03:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnBg-0006Cn-RX; Tue, 22 Nov 2011 10:02:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnBf-0006CV-J8
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:02:47 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321956137!4095940!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11622 invoked from network); 22 Nov 2011 10:02:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:02:18 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMA2DKn030681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:02:14 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMA2DCl007843
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:02:13 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMA27P3007993; Tue, 22 Nov 2011 04:02:07 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:02:06 -0800
Message-ID: <4ECB7324.9080008@oracle.com>
Date: Tue, 22 Nov 2011 18:02:12 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4ECA416D.90602@oracle.com>	
	<1321927161-3987-1-git-send-email-annie.li@oracle.com>
	<1321954186.3664.403.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321954186.3664.403.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4ECB7327.0037,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-11-22 17:29, Ian Campbell wrote:
> On Tue, 2011-11-22 at 01:59 +0000, annie.li@oracle.com wrote:
> [...]
>> +#ifdef CONFIG_X86
>> +		barrier();
>> +#else
>> +		mb();
>> +#endif
>> +		}
> Niggle: Indentation of this final } is off.
Sorry, I did not notice that.
> Otherwise all 4 patches:
> Acked-by: Ian Campbell<ian.campbell@citrix.com>
>
> [...]
Thanks, I will resend those patches after above indentation issue is fixed.

Thanks.

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:03:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnBg-0006Cn-RX; Tue, 22 Nov 2011 10:02:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnBf-0006CV-J8
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:02:47 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321956137!4095940!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11622 invoked from network); 22 Nov 2011 10:02:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:02:18 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMA2DKn030681
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:02:14 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMA2DCl007843
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:02:13 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMA27P3007993; Tue, 22 Nov 2011 04:02:07 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:02:06 -0800
Message-ID: <4ECB7324.9080008@oracle.com>
Date: Tue, 22 Nov 2011 18:02:12 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4ECA416D.90602@oracle.com>	
	<1321927161-3987-1-git-send-email-annie.li@oracle.com>
	<1321954186.3664.403.camel@zakaz.uk.xensource.com>
In-Reply-To: <1321954186.3664.403.camel@zakaz.uk.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4ECB7327.0037,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-11-22 17:29, Ian Campbell wrote:
> On Tue, 2011-11-22 at 01:59 +0000, annie.li@oracle.com wrote:
> [...]
>> +#ifdef CONFIG_X86
>> +		barrier();
>> +#else
>> +		mb();
>> +#endif
>> +		}
> Niggle: Indentation of this final } is off.
Sorry, I did not notice that.
> Otherwise all 4 patches:
> Acked-by: Ian Campbell<ian.campbell@citrix.com>
>
> [...]
Thanks, I will resend those patches after above indentation issue is fixed.

Thanks.

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnUX-0006cn-CQ; Tue, 22 Nov 2011 10:22:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnUV-0006cf-U6
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:22:16 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321957268!57764417!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30699 invoked from network); 22 Nov 2011 10:21:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:21:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMALkhL027107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:21:47 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMALjfY000577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:21:46 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMALdpu022532; Tue, 22 Nov 2011 04:21:40 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:21:38 -0800
Message-ID: <4ECB77BB.9090401@oracle.com>
Date: Tue, 22 Nov 2011 18:21:47 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"jeremy@goop.org" <jeremy@goop.org>, Ian Campbell <Ian.Campbell@citrix.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4ECB77BC.0070,ss=1,re=0.000,fgs=0
Cc: Kurt Hackel <Kurt.Hackel@oracle.com>, ANNIE LI <annie.li@oracle.com>,
	Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] Forth version patches for upstreaming grant table
	version 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

The following patches introduce and implement grant table version 2. 
This is the forth version patches, and based on v3.2.0-rc1+. Changes 
from the previous patches are following:

* Fix an indentation issue of the code.

Descriptions for those patches:

1. In those patches, the grant table code supports both grant table v1 
and v2 version, v2 is an extension from v1. Grant table of guest domain 
can be either v1 or v2 version, and every grant table entry on one guest 
should be the same version.
2. Full page structure of grant table v2 play the same role as grant 
table v1. Although full page structure is different from v1, grant table 
2 is totally backwards compatible with v1. Grant table is shared between 
guest and Xen, domu and dom0 all have their own grant table shared with 
Xen, and their grant table version should be set before any grants are 
activated. When domu grants an entry to dom0 to map a frame,following 
are steps: * domu introduces a grant entry by reference * domu informs 
dom0 the gref * dom0 sends hypercall to map frame through this 
reference, Xen copy shared entry to active entry and update frame * dom0 
does its work and release the frame, Xen releases the entry. * domu redo 
those steps for a new cycle. Xen mapping process can be found in 
function __gnttab_map_grant_ref in Xen code: xen/common/grant_table.c

3. If dom0 supports grant table v2, guests run on it can either supports 
v1 or v2. Xen is responsible to judge what  version the guests are 
using. This is implemented in Xen code: xen/common/grant_table.c. Key 
word is:  rd->grant_table->gt_version.
4. Grant table v2 has been supported by Xen for a long time, and 
receiver-side copying mechanism bases on this implementation. Netback 
and netfront driver can pick up this new feature to get better network 
performance and better CPU accounting.

Diff:

  arch/x86/xen/grant-table.c          |   42 ++++-
  drivers/xen/grant-table.c           |  354 
++++++++++++++++++++++++++++++-----
  include/xen/grant_table.h           |   10 +-
  include/xen/interface/grant_table.h |  167 ++++++++++++++++-
  include/xen/interface/xen.h         |    2 +
  5 files changed, 519 insertions(+), 56 deletions(-)

Shortlog:

Annie Li (4):
       xen/granttable: Introducing grant table V2 stucture
       xen/granttable: Refactor some code
       xen/granttable: Grant tables V2 implementation
       xen/granttable: Keep code format clean

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnUX-0006cn-CQ; Tue, 22 Nov 2011 10:22:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnUV-0006cf-U6
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:22:16 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321957268!57764417!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30699 invoked from network); 22 Nov 2011 10:21:09 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:21:09 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMALkhL027107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:21:47 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMALjfY000577
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:21:46 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMALdpu022532; Tue, 22 Nov 2011 04:21:40 -0600
Received: from [10.182.39.81] (/10.182.39.81)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:21:38 -0800
Message-ID: <4ECB77BB.9090401@oracle.com>
Date: Tue, 22 Nov 2011 18:21:47 +0800
From: ANNIE LI <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"jeremy@goop.org" <jeremy@goop.org>, Ian Campbell <Ian.Campbell@citrix.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4ECB77BC.0070,ss=1,re=0.000,fgs=0
Cc: Kurt Hackel <Kurt.Hackel@oracle.com>, ANNIE LI <annie.li@oracle.com>,
	Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] Forth version patches for upstreaming grant table
	version 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

The following patches introduce and implement grant table version 2. 
This is the forth version patches, and based on v3.2.0-rc1+. Changes 
from the previous patches are following:

* Fix an indentation issue of the code.

Descriptions for those patches:

1. In those patches, the grant table code supports both grant table v1 
and v2 version, v2 is an extension from v1. Grant table of guest domain 
can be either v1 or v2 version, and every grant table entry on one guest 
should be the same version.
2. Full page structure of grant table v2 play the same role as grant 
table v1. Although full page structure is different from v1, grant table 
2 is totally backwards compatible with v1. Grant table is shared between 
guest and Xen, domu and dom0 all have their own grant table shared with 
Xen, and their grant table version should be set before any grants are 
activated. When domu grants an entry to dom0 to map a frame,following 
are steps: * domu introduces a grant entry by reference * domu informs 
dom0 the gref * dom0 sends hypercall to map frame through this 
reference, Xen copy shared entry to active entry and update frame * dom0 
does its work and release the frame, Xen releases the entry. * domu redo 
those steps for a new cycle. Xen mapping process can be found in 
function __gnttab_map_grant_ref in Xen code: xen/common/grant_table.c

3. If dom0 supports grant table v2, guests run on it can either supports 
v1 or v2. Xen is responsible to judge what  version the guests are 
using. This is implemented in Xen code: xen/common/grant_table.c. Key 
word is:  rd->grant_table->gt_version.
4. Grant table v2 has been supported by Xen for a long time, and 
receiver-side copying mechanism bases on this implementation. Netback 
and netfront driver can pick up this new feature to get better network 
performance and better CPU accounting.

Diff:

  arch/x86/xen/grant-table.c          |   42 ++++-
  drivers/xen/grant-table.c           |  354 
++++++++++++++++++++++++++++++-----
  include/xen/grant_table.h           |   10 +-
  include/xen/interface/grant_table.h |  167 ++++++++++++++++-
  include/xen/interface/xen.h         |    2 +
  5 files changed, 519 insertions(+), 56 deletions(-)

Shortlog:

Annie Li (4):
       xen/granttable: Introducing grant table V2 stucture
       xen/granttable: Refactor some code
       xen/granttable: Grant tables V2 implementation
       xen/granttable: Keep code format clean

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:24:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnWk-0006hx-0B; Tue, 22 Nov 2011 10:24:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <niall.fleming@webanywhere.co.uk>) id 1RSnWi-0006hp-FC
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:24:32 +0000
X-Env-Sender: niall.fleming@webanywhere.co.uk
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321957344!53168094!1
X-Originating-IP: [212.227.126.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26861 invoked from network); 22 Nov 2011 10:22:24 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171) by server-8.tower-27.messagelabs.com with SMTP;
	22 Nov 2011 10:22:24 -0000
Received: from [192.168.80.60] (host81-130-85-157.in-addr.btopenworld.com
	[81.130.85.157])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0MANKs-1RYo3E1Pqs-00B6GX; Tue, 22 Nov 2011 11:23:54 +0100
Message-ID: <4ECB7839.3080303@webanywhere.co.uk>
Date: Tue, 22 Nov 2011 10:23:53 +0000
From: Niall Fleming <niall.fleming@webanywhere.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>
	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
In-Reply-To: <20111116142604.GA7476@phenom.dumpdata.com>
X-Provags-ID: V02:K0:Th+M8nCPS9fN67bdonInm6uN8xxH5JbpDruJZcwl2of
	vTwytX3kg6gipUA7TZ6ebaudhlf3lIIHQWwk/LRzspci/b6X7s
	yeWwzhpSsJJAheSsPeqy4qoiPbKDeGCA1Ea2KrSFlWwIvAy7eU
	eQF1+6sSLPdsIOekjxQAR+Z2yrPb4TLqpMzePzxImrsBargCkQ
	x16f5YbIkPdsDyN+ujLzjrByg5UFHvHgc58xsMOtyEZDxAgJeA
	KPuASmqv0P1xVXOWgfCwCyYX7ezU60fBbIuOFvRh0z4lIHO80V
	GnVpfUdazMV1DeKBgwup2OocMxoOpp4V7c+KTwxbb2RUXStcoF
	aDksgSbpxW57f3ezCbFaibUyYDD1mNW/MtimFJylu
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	keir.xen@gmail.com, Jan Beulich <JBeulich@suse.com>,
	pbonzini@redhat.com, lersek@redhat.com
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1837351187173924483=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============1837351187173924483==
Content-Type: multipart/alternative;
 boundary="------------030706060704040901080303"

This is a multi-part message in MIME format.
--------------030706060704040901080303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

ping?

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>> Right. With those patches too (he used the xen-settime patch set which has it).
>>> The hypercall is done (and the do_settime gets called) and the results are saved
>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>
>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>> existing guests.
>>>
>>> If you launch a new guest after the 'hwclock', the new guests
>>> retains the old wallclock time.
>> Existing (pvops) guests shouldn't see updated wallclock time, because
>> they never look at the hypervisor's wallclock after boot time.
>>
>> It's surprising that new guests don't see the updated wallclock though.
>> That sounds like a Xen issue.
> <nods>  That is what I think is happening here.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

--------------030706060704040901080303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    ping?<br>
    <div class="moz-signature"><br>
      <b>Niall Fleming BSc. (Hons)</b><br>
      Systems Administrator<br>
      Webanywhere Limited<br>
      <br>
      Phone: 0800 862 0131 Ext: 203<br>
      Web: <a class="moz-txt-link-freetext" href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a><br>
      <br>
      Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB<br>
      Registered in England with company number 4881346</div>
    <br>
    On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
    <blockquote cite="mid:20111116142604.GA7476@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Right. With those patches too (he used the xen-settime patch set which has it).
The hypercall is done (and the do_settime gets called) and the results are saved
in the RTC. And the wc_sec and wc_nsec are updated and propagated.

The problem is that wc_sec and wc_nsec are only propagated to the
existing guests.

If you launch a new guest after the 'hwclock', the new guests
retains the old wallclock time.
</pre>
        </blockquote>
        <pre wrap="">
Existing (pvops) guests shouldn't see updated wallclock time, because
they never look at the hypervisor's wallclock after boot time.

It's surprising that new guests don't see the updated wallclock though. 
That sounds like a Xen issue.
</pre>
      </blockquote>
      <pre wrap="">
&lt;nods&gt; That is what I think is happening here.

_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
<a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>
</pre>
    </blockquote>
  </body>
</html>

--------------030706060704040901080303--


--===============1837351187173924483==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1837351187173924483==--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:24:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnWk-0006hx-0B; Tue, 22 Nov 2011 10:24:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <niall.fleming@webanywhere.co.uk>) id 1RSnWi-0006hp-FC
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:24:32 +0000
X-Env-Sender: niall.fleming@webanywhere.co.uk
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321957344!53168094!1
X-Originating-IP: [212.227.126.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26861 invoked from network); 22 Nov 2011 10:22:24 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171) by server-8.tower-27.messagelabs.com with SMTP;
	22 Nov 2011 10:22:24 -0000
Received: from [192.168.80.60] (host81-130-85-157.in-addr.btopenworld.com
	[81.130.85.157])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0MANKs-1RYo3E1Pqs-00B6GX; Tue, 22 Nov 2011 11:23:54 +0100
Message-ID: <4ECB7839.3080303@webanywhere.co.uk>
Date: Tue, 22 Nov 2011 10:23:53 +0000
From: Niall Fleming <niall.fleming@webanywhere.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>
	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
In-Reply-To: <20111116142604.GA7476@phenom.dumpdata.com>
X-Provags-ID: V02:K0:Th+M8nCPS9fN67bdonInm6uN8xxH5JbpDruJZcwl2of
	vTwytX3kg6gipUA7TZ6ebaudhlf3lIIHQWwk/LRzspci/b6X7s
	yeWwzhpSsJJAheSsPeqy4qoiPbKDeGCA1Ea2KrSFlWwIvAy7eU
	eQF1+6sSLPdsIOekjxQAR+Z2yrPb4TLqpMzePzxImrsBargCkQ
	x16f5YbIkPdsDyN+ujLzjrByg5UFHvHgc58xsMOtyEZDxAgJeA
	KPuASmqv0P1xVXOWgfCwCyYX7ezU60fBbIuOFvRh0z4lIHO80V
	GnVpfUdazMV1DeKBgwup2OocMxoOpp4V7c+KTwxbb2RUXStcoF
	aDksgSbpxW57f3ezCbFaibUyYDD1mNW/MtimFJylu
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	keir.xen@gmail.com, Jan Beulich <JBeulich@suse.com>,
	pbonzini@redhat.com, lersek@redhat.com
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1837351187173924483=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============1837351187173924483==
Content-Type: multipart/alternative;
 boundary="------------030706060704040901080303"

This is a multi-part message in MIME format.
--------------030706060704040901080303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

ping?

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>> Right. With those patches too (he used the xen-settime patch set which has it).
>>> The hypercall is done (and the do_settime gets called) and the results are saved
>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>
>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>> existing guests.
>>>
>>> If you launch a new guest after the 'hwclock', the new guests
>>> retains the old wallclock time.
>> Existing (pvops) guests shouldn't see updated wallclock time, because
>> they never look at the hypervisor's wallclock after boot time.
>>
>> It's surprising that new guests don't see the updated wallclock though.
>> That sounds like a Xen issue.
> <nods>  That is what I think is happening here.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

--------------030706060704040901080303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    ping?<br>
    <div class="moz-signature"><br>
      <b>Niall Fleming BSc. (Hons)</b><br>
      Systems Administrator<br>
      Webanywhere Limited<br>
      <br>
      Phone: 0800 862 0131 Ext: 203<br>
      Web: <a class="moz-txt-link-freetext" href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a><br>
      <br>
      Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB<br>
      Registered in England with company number 4881346</div>
    <br>
    On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
    <blockquote cite="mid:20111116142604.GA7476@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Right. With those patches too (he used the xen-settime patch set which has it).
The hypercall is done (and the do_settime gets called) and the results are saved
in the RTC. And the wc_sec and wc_nsec are updated and propagated.

The problem is that wc_sec and wc_nsec are only propagated to the
existing guests.

If you launch a new guest after the 'hwclock', the new guests
retains the old wallclock time.
</pre>
        </blockquote>
        <pre wrap="">
Existing (pvops) guests shouldn't see updated wallclock time, because
they never look at the hypervisor's wallclock after boot time.

It's surprising that new guests don't see the updated wallclock though. 
That sounds like a Xen issue.
</pre>
      </blockquote>
      <pre wrap="">
&lt;nods&gt; That is what I think is happening here.

_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
<a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>
</pre>
    </blockquote>
  </body>
</html>

--------------030706060704040901080303--


--===============1837351187173924483==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1837351187173924483==--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:27:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:27:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnYs-0006pu-Ie; Tue, 22 Nov 2011 10:26:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnYq-0006pM-Ob
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:26:45 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1321957574!5179401!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5155 invoked from network); 22 Nov 2011 10:26:15 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:26:15 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMAQBA6032650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:26:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMAQA42016212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:26:11 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMAQ5bc021336; Tue, 22 Nov 2011 04:26:05 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:26:05 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 18:25:55 +0800
Message-Id: <1321957555-10210-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECB77BB.9090401@oracle.com>
References: <4ECB77BB.9090401@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4ECB78C4.018D,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/4] xen/granttable: Introducing grant table V2
	stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

This patch introduces new structures of grant table V2, grant table V2 is an
extension from V1. Grant table is shared between guest and Xen, and Xen is
responsible to do corresponding work for grant operations, such as: figure
out guest's grant table version, perform different actions based on
different grant table version, etc. Although full-page structure of V2
is different from V1, it play the same role as V1.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 arch/x86/xen/grant-table.c          |    7 +-
 drivers/xen/grant-table.c           |  181 +++++++++++++++++++++++++++--------
 include/xen/grant_table.h           |    4 +-
 include/xen/interface/grant_table.h |  167 +++++++++++++++++++++++++++++++-
 include/xen/interface/xen.h         |    2 +
 5 files changed, 310 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index 6bbfd7a..c6ab2e7 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -64,10 +64,10 @@ static int unmap_pte_fn(pte_t *pte, struct page *pmd_page,
 
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
-			   struct grant_entry **__shared)
+			   void **__shared)
 {
 	int rc;
-	struct grant_entry *shared = *__shared;
+	void *shared = *__shared;
 
 	if (shared == NULL) {
 		struct vm_struct *area =
@@ -83,8 +83,7 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 	return rc;
 }
 
-void arch_gnttab_unmap_shared(struct grant_entry *shared,
-			      unsigned long nr_gframes)
+void arch_gnttab_unmap_shared(void *shared, unsigned long nr_gframes)
 {
 	apply_to_page_range(&init_mm, (unsigned long)shared,
 			    PAGE_SIZE * nr_gframes, unmap_pte_fn, NULL);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..18355a5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -53,7 +53,7 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry))
+#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry_v1))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -64,7 +64,63 @@ static DEFINE_SPINLOCK(gnttab_list_lock);
 unsigned long xen_hvm_resume_frames;
 EXPORT_SYMBOL_GPL(xen_hvm_resume_frames);
 
-static struct grant_entry *shared;
+static union {
+	struct grant_entry_v1 *v1;
+	void *addr;
+} gnttab_shared;
+
+/*This is a structure of function pointers for grant table*/
+struct gnttab_ops {
+	/*
+	 * Mapping a list of frames for storing grant entries. First input
+	 * parameter is used to storing grant table address when grant table
+	 * being setup, second parameter is the number of frames to map grant
+	 * table. Returning GNTST_okay means success and negative value means
+	 * failure.
+	 */
+	int (*map_frames)(unsigned long *, unsigned int);
+	/*
+	 * Release a list of frames which are mapped in map_frames for grant
+	 * entry status.
+	 */
+	void (*unmap_frames)(void);
+	/*
+	 * Introducing a valid entry into the grant table, granting the frame
+	 * of this grant entry to domain for accessing, or transfering, or
+	 * transitively accessing. First input parameter is reference of this
+	 * introduced grant entry, second one is domid of granted domain, third
+	 * one is the frame to be granted, and the last one is status of the
+	 * grant entry to be updated.
+	 */
+	void (*update_entry)(grant_ref_t, domid_t, unsigned long, unsigned);
+	/*
+	 * Stop granting a grant entry to domain for accessing. First input
+	 * parameter is reference of a grant entry whose grant access will be
+	 * stopped, second one is not in use now. If the grant entry is
+	 * currently mapped for reading or writing, just return failure(==0)
+	 * directly and don't tear down the grant access. Otherwise, stop grant
+	 * access for this entry and return success(==1).
+	 */
+	int (*end_foreign_access_ref)(grant_ref_t, int);
+	/*
+	 * Stop granting a grant entry to domain for transfer. If tranfer has
+	 * not started, just reclaim the grant entry and return failure(==0).
+	 * Otherwise, wait for the transfer to complete and then return the
+	 * frame.
+	 */
+	unsigned long (*end_foreign_transfer_ref)(grant_ref_t);
+	/*
+	 * Query the status of a grant entry. Input parameter is reference of
+	 * queried grant entry, return value is the status of queried entry.
+	 * Detailed status(writing/reading) can be gotten from the return value
+	 * by bit operations.
+	 */
+	int (*query_foreign_access)(grant_ref_t);
+};
+
+static struct gnttab_ops *gnttab_interface;
+
+static int grant_table_version;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
 
@@ -142,23 +198,23 @@ static void put_free_entry(grant_ref_t ref)
 	spin_unlock_irqrestore(&gnttab_list_lock, flags);
 }
 
-static void update_grant_entry(grant_ref_t ref, domid_t domid,
-			       unsigned long frame, unsigned flags)
+/*
+ * Introducing a valid entry into the grant table:
+ *  1. Write ent->domid.
+ *  2. Write ent->frame:
+ *      GTF_permit_access:   Frame to which access is permitted.
+ *      GTF_accept_transfer: Pseudo-phys frame slot being filled by new
+ *                           frame, or zero if none.
+ *  3. Write memory barrier (WMB).
+ *  4. Write ent->flags, inc. valid type.
+ */
+static void gnttab_update_entry_v1(grant_ref_t ref, domid_t domid,
+				   unsigned long frame, unsigned flags)
 {
-	/*
-	 * Introducing a valid entry into the grant table:
-	 *  1. Write ent->domid.
-	 *  2. Write ent->frame:
-	 *      GTF_permit_access:   Frame to which access is permitted.
-	 *      GTF_accept_transfer: Pseudo-phys frame slot being filled by new
-	 *                           frame, or zero if none.
-	 *  3. Write memory barrier (WMB).
-	 *  4. Write ent->flags, inc. valid type.
-	 */
-	shared[ref].frame = frame;
-	shared[ref].domid = domid;
+	gnttab_shared.v1[ref].domid = domid;
+	gnttab_shared.v1[ref].frame = frame;
 	wmb();
-	shared[ref].flags = flags;
+	gnttab_shared.v1[ref].flags = flags;
 }
 
 /*
@@ -167,7 +223,7 @@ static void update_grant_entry(grant_ref_t ref, domid_t domid,
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly)
 {
-	update_grant_entry(ref, domid, frame,
+	gnttab_interface->update_entry(ref, domid, frame,
 			   GTF_permit_access | (readonly ? GTF_readonly : 0));
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref);
@@ -187,31 +243,37 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
-int gnttab_query_foreign_access(grant_ref_t ref)
+static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
-	u16 nflags;
-
-	nflags = shared[ref].flags;
+	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
+}
 
-	return nflags & (GTF_reading|GTF_writing);
+int gnttab_query_foreign_access(grant_ref_t ref)
+{
+	return gnttab_interface->query_foreign_access(ref);
 }
 EXPORT_SYMBOL_GPL(gnttab_query_foreign_access);
 
-int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 {
 	u16 flags, nflags;
 
-	nflags = shared[ref].flags;
+	nflags = gnttab_shared.v1[ref].flags;
 	do {
 		flags = nflags;
 		if (flags & (GTF_reading|GTF_writing)) {
 			printk(KERN_ALERT "WARNING: g.e. still in use!\n");
 			return 0;
 		}
-	} while ((nflags = sync_cmpxchg(&shared[ref].flags, flags, 0)) != flags);
+	} while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0)) != flags);
 
 	return 1;
 }
+
+int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+{
+	return gnttab_interface->end_foreign_access_ref(ref, readonly);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);
 
 void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
@@ -246,11 +308,11 @@ EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer);
 void gnttab_grant_foreign_transfer_ref(grant_ref_t ref, domid_t domid,
 				       unsigned long pfn)
 {
-	update_grant_entry(ref, domid, pfn, GTF_accept_transfer);
+	gnttab_interface->update_entry(ref, domid, pfn, GTF_accept_transfer);
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer_ref);
 
-unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 {
 	unsigned long frame;
 	u16           flags;
@@ -259,24 +321,29 @@ unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
 	 * If a transfer is not even yet started, try to reclaim the grant
 	 * reference and return failure (== 0).
 	 */
-	while (!((flags = shared[ref].flags) & GTF_transfer_committed)) {
-		if (sync_cmpxchg(&shared[ref].flags, flags, 0) == flags)
+	while (!((flags = gnttab_shared.v1[ref].flags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0) == flags)
 			return 0;
 		cpu_relax();
 	}
 
 	/* If a transfer is in progress then wait until it is completed. */
 	while (!(flags & GTF_transfer_completed)) {
-		flags = shared[ref].flags;
+		flags = gnttab_shared.v1[ref].flags;
 		cpu_relax();
 	}
 
 	rmb();	/* Read the frame number /after/ reading completion status. */
-	frame = shared[ref].frame;
+	frame = gnttab_shared.v1[ref].frame;
 	BUG_ON(frame == 0);
 
 	return frame;
 }
+
+unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+{
+	return gnttab_interface->end_foreign_transfer_ref(ref);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_transfer_ref);
 
 unsigned long gnttab_end_foreign_transfer(grant_ref_t ref)
@@ -520,6 +587,23 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
+{
+	int rc;
+
+	rc = arch_gnttab_map_shared(frames, nr_gframes,
+				    gnttab_max_grant_frames(),
+				    &gnttab_shared.addr);
+	BUG_ON(rc);
+
+	return 0;
+}
+
+static void gnttab_unmap_frames_v1(void)
+{
+	arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
@@ -567,19 +651,35 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 
 	BUG_ON(rc || setup.status);
 
-	rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
-				    &shared);
-	BUG_ON(rc);
+	rc = gnttab_interface->map_frames(frames, nr_gframes);
 
 	kfree(frames);
 
-	return 0;
+	return rc;
+}
+
+static struct gnttab_ops gnttab_v1_ops = {
+	.map_frames			= gnttab_map_frames_v1,
+	.unmap_frames			= gnttab_unmap_frames_v1,
+	.update_entry			= gnttab_update_entry_v1,
+	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v1,
+	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v1,
+	.query_foreign_access		= gnttab_query_foreign_access_v1,
+};
+
+static void gnttab_request_version(void)
+{
+	grant_table_version = 1;
+	gnttab_interface = &gnttab_v1_ops;
+	printk(KERN_INFO "Grant tables using version %d layout.\n",
+		grant_table_version);
 }
 
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
 
+	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
@@ -587,9 +687,10 @@ int gnttab_resume(void)
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-	if (!shared) {
-		shared = ioremap(xen_hvm_resume_frames, PAGE_SIZE * max_nr_gframes);
-		if (shared == NULL) {
+	if (gnttab_shared.addr == NULL) {
+		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
+						PAGE_SIZE * max_nr_gframes);
+		if (gnttab_shared.addr == NULL) {
 			printk(KERN_WARNING
 					"Failed to ioremap gnttab share frames!");
 			return -ENOMEM;
@@ -603,7 +704,7 @@ int gnttab_resume(void)
 
 int gnttab_suspend(void)
 {
-	arch_gnttab_unmap_shared(shared, nr_grant_frames);
+	gnttab_interface->unmap_frames();
 	return 0;
 }
 
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e2dfc..c7a40f8 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -145,8 +145,8 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
-			   struct grant_entry **__shared);
-void arch_gnttab_unmap_shared(struct grant_entry *shared,
+			   void **__shared);
+void arch_gnttab_unmap_shared(void *shared,
 			      unsigned long nr_gframes);
 
 extern unsigned long xen_hvm_resume_frames;
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index 39e5717..a17d844 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -85,12 +85,22 @@
  */
 
 /*
+ * Reference to a grant entry in a specified domain's grant table.
+ */
+typedef uint32_t grant_ref_t;
+
+/*
  * A grant table comprises a packed array of grant entries in one or more
  * page frames shared between Xen and a guest.
  * [XEN]: This field is written by Xen and read by the sharing guest.
  * [GST]: This field is written by the guest and read by Xen.
  */
-struct grant_entry {
+
+/*
+ * Version 1 of the grant table entry structure is maintained purely
+ * for backwards compatibility.  New guests should use version 2.
+ */
+struct grant_entry_v1 {
     /* GTF_xxx: various type and flag information.  [XEN,GST] */
     uint16_t flags;
     /* The domain being granted foreign privileges. [GST] */
@@ -108,10 +118,13 @@ struct grant_entry {
  *  GTF_permit_access: Allow @domid to map/access @frame.
  *  GTF_accept_transfer: Allow @domid to transfer ownership of one page frame
  *                       to this guest. Xen writes the page number to @frame.
+ *  GTF_transitive: Allow @domid to transitively access a subrange of
+ *                  @trans_grant in @trans_domid.  No mappings are allowed.
  */
 #define GTF_invalid         (0U<<0)
 #define GTF_permit_access   (1U<<0)
 #define GTF_accept_transfer (2U<<0)
+#define GTF_transitive      (3U<<0)
 #define GTF_type_mask       (3U<<0)
 
 /*
@@ -119,6 +132,9 @@ struct grant_entry {
  *  GTF_readonly: Restrict @domid to read-only mappings and accesses. [GST]
  *  GTF_reading: Grant entry is currently mapped for reading by @domid. [XEN]
  *  GTF_writing: Grant entry is currently mapped for writing by @domid. [XEN]
+ *  GTF_sub_page: Grant access to only a subrange of the page.  @domid
+ *                will only be allowed to copy from the grant, and not
+ *                map it. [GST]
  */
 #define _GTF_readonly       (2)
 #define GTF_readonly        (1U<<_GTF_readonly)
@@ -126,6 +142,8 @@ struct grant_entry {
 #define GTF_reading         (1U<<_GTF_reading)
 #define _GTF_writing        (4)
 #define GTF_writing         (1U<<_GTF_writing)
+#define _GTF_sub_page       (8)
+#define GTF_sub_page        (1U<<_GTF_sub_page)
 
 /*
  * Subflags for GTF_accept_transfer:
@@ -142,15 +160,81 @@ struct grant_entry {
 #define _GTF_transfer_completed (3)
 #define GTF_transfer_completed  (1U<<_GTF_transfer_completed)
 
+/*
+ * Version 2 grant table entries.  These fulfil the same role as
+ * version 1 entries, but can represent more complicated operations.
+ * Any given domain will have either a version 1 or a version 2 table,
+ * and every entry in the table will be the same version.
+ *
+ * The interface by which domains use grant references does not depend
+ * on the grant table version in use by the other domain.
+ */
 
-/***********************************
- * GRANT TABLE QUERIES AND USES
+/*
+ * Version 1 and version 2 grant entries share a common prefix.  The
+ * fields of the prefix are documented as part of struct
+ * grant_entry_v1.
  */
+struct grant_entry_header {
+    uint16_t flags;
+    domid_t  domid;
+};
 
 /*
- * Reference to a grant entry in a specified domain's grant table.
+ * Version 2 of the grant entry structure, here is an union because three
+ * different types are suppotted: full_page, sub_page and transitive.
+ */
+union grant_entry_v2 {
+    struct grant_entry_header hdr;
+
+    /*
+     * This member is used for V1-style full page grants, where either:
+     *
+     * -- hdr.type is GTF_accept_transfer, or
+     * -- hdr.type is GTF_permit_access and GTF_sub_page is not set.
+     *
+     * In that case, the frame field has the same semantics as the
+     * field of the same name in the V1 entry structure.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	uint32_t pad0;
+	uint64_t frame;
+    } full_page;
+
+    /*
+     * If the grant type is GTF_grant_access and GTF_sub_page is set,
+     * @domid is allowed to access bytes [@page_off,@page_off+@length)
+     * in frame @frame.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	uint16_t page_off;
+	uint16_t length;
+	uint64_t frame;
+    } sub_page;
+
+    /*
+     * If the grant is GTF_transitive, @domid is allowed to use the
+     * grant @gref in domain @trans_domid, as if it was the local
+     * domain.  Obviously, the transitive access must be compatible
+     * with the original grant.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	domid_t trans_domid;
+	uint16_t pad0;
+	grant_ref_t gref;
+    } transitive;
+
+    uint32_t __spacer[4]; /* Pad to a power of two */
+};
+
+typedef uint16_t grant_status_t;
+
+/***********************************
+ * GRANT TABLE QUERIES AND USES
  */
-typedef uint32_t grant_ref_t;
 
 /*
  * Handle to track a mapping created via a grant reference.
@@ -322,6 +406,79 @@ struct gnttab_query_size {
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
 
 /*
+ * GNTTABOP_unmap_and_replace: Destroy one or more grant-reference mappings
+ * tracked by <handle> but atomically replace the page table entry with one
+ * pointing to the machine address under <new_addr>.  <new_addr> will be
+ * redirected to the null entry.
+ * NOTES:
+ *  1. The call may fail in an undefined manner if either mapping is not
+ *     tracked by <handle>.
+ *  2. After executing a batch of unmaps, it is guaranteed that no stale
+ *     mappings will remain in the device or host TLBs.
+ */
+#define GNTTABOP_unmap_and_replace    7
+struct gnttab_unmap_and_replace {
+    /* IN parameters. */
+    uint64_t host_addr;
+    uint64_t new_addr;
+    grant_handle_t handle;
+    /* OUT parameters. */
+    int16_t  status;              /* GNTST_* */
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_unmap_and_replace);
+
+/*
+ * GNTTABOP_set_version: Request a particular version of the grant
+ * table shared table structure.  This operation can only be performed
+ * once in any given domain.  It must be performed before any grants
+ * are activated; otherwise, the domain will be stuck with version 1.
+ * The only defined versions are 1 and 2.
+ */
+#define GNTTABOP_set_version          8
+struct gnttab_set_version {
+    /* IN parameters */
+    uint32_t version;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_set_version);
+
+/*
+ * GNTTABOP_get_status_frames: Get the list of frames used to store grant
+ * status for <dom>. In grant format version 2, the status is separated
+ * from the other shared grant fields to allow more efficient synchronization
+ * using barriers instead of atomic cmpexch operations.
+ * <nr_frames> specify the size of vector <frame_list>.
+ * The frame addresses are returned in the <frame_list>.
+ * Only <nr_frames> addresses are returned, even if the table is larger.
+ * NOTES:
+ *  1. <dom> may be specified as DOMID_SELF.
+ *  2. Only a sufficiently-privileged domain may specify <dom> != DOMID_SELF.
+ */
+#define GNTTABOP_get_status_frames     9
+struct gnttab_get_status_frames {
+    /* IN parameters. */
+    uint32_t nr_frames;
+    domid_t  dom;
+    /* OUT parameters. */
+    int16_t  status;              /* GNTST_* */
+    GUEST_HANDLE(uint64_t) frame_list;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_status_frames);
+
+/*
+ * GNTTABOP_get_version: Get the grant table version which is in
+ * effect for domain <dom>.
+ */
+#define GNTTABOP_get_version          10
+struct gnttab_get_version {
+    /* IN parameters */
+    domid_t dom;
+    uint16_t pad;
+    /* OUT parameters */
+    uint32_t version;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_version);
+
+/*
  * Bitfield values for update_pin_status.flags.
  */
  /* Map the grant entry for access by I/O devices. */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..a890804 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -523,6 +523,8 @@ struct tmem_op {
 	} u;
 };
 
+DEFINE_GUEST_HANDLE(u64);
+
 #else /* __ASSEMBLY__ */
 
 /* In assembly code we cannot use C numeric constant suffixes. */
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:27:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:27:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnYs-0006pu-Ie; Tue, 22 Nov 2011 10:26:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnYq-0006pM-Ob
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:26:45 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1321957574!5179401!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5155 invoked from network); 22 Nov 2011 10:26:15 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:26:15 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMAQBA6032650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:26:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMAQA42016212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:26:11 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMAQ5bc021336; Tue, 22 Nov 2011 04:26:05 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:26:05 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 18:25:55 +0800
Message-Id: <1321957555-10210-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECB77BB.9090401@oracle.com>
References: <4ECB77BB.9090401@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4ECB78C4.018D,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1/4] xen/granttable: Introducing grant table V2
	stucture
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

This patch introduces new structures of grant table V2, grant table V2 is an
extension from V1. Grant table is shared between guest and Xen, and Xen is
responsible to do corresponding work for grant operations, such as: figure
out guest's grant table version, perform different actions based on
different grant table version, etc. Although full-page structure of V2
is different from V1, it play the same role as V1.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 arch/x86/xen/grant-table.c          |    7 +-
 drivers/xen/grant-table.c           |  181 +++++++++++++++++++++++++++--------
 include/xen/grant_table.h           |    4 +-
 include/xen/interface/grant_table.h |  167 +++++++++++++++++++++++++++++++-
 include/xen/interface/xen.h         |    2 +
 5 files changed, 310 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index 6bbfd7a..c6ab2e7 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -64,10 +64,10 @@ static int unmap_pte_fn(pte_t *pte, struct page *pmd_page,
 
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
-			   struct grant_entry **__shared)
+			   void **__shared)
 {
 	int rc;
-	struct grant_entry *shared = *__shared;
+	void *shared = *__shared;
 
 	if (shared == NULL) {
 		struct vm_struct *area =
@@ -83,8 +83,7 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 	return rc;
 }
 
-void arch_gnttab_unmap_shared(struct grant_entry *shared,
-			      unsigned long nr_gframes)
+void arch_gnttab_unmap_shared(void *shared, unsigned long nr_gframes)
 {
 	apply_to_page_range(&init_mm, (unsigned long)shared,
 			    PAGE_SIZE * nr_gframes, unmap_pte_fn, NULL);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..18355a5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -53,7 +53,7 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry))
+#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry_v1))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -64,7 +64,63 @@ static DEFINE_SPINLOCK(gnttab_list_lock);
 unsigned long xen_hvm_resume_frames;
 EXPORT_SYMBOL_GPL(xen_hvm_resume_frames);
 
-static struct grant_entry *shared;
+static union {
+	struct grant_entry_v1 *v1;
+	void *addr;
+} gnttab_shared;
+
+/*This is a structure of function pointers for grant table*/
+struct gnttab_ops {
+	/*
+	 * Mapping a list of frames for storing grant entries. First input
+	 * parameter is used to storing grant table address when grant table
+	 * being setup, second parameter is the number of frames to map grant
+	 * table. Returning GNTST_okay means success and negative value means
+	 * failure.
+	 */
+	int (*map_frames)(unsigned long *, unsigned int);
+	/*
+	 * Release a list of frames which are mapped in map_frames for grant
+	 * entry status.
+	 */
+	void (*unmap_frames)(void);
+	/*
+	 * Introducing a valid entry into the grant table, granting the frame
+	 * of this grant entry to domain for accessing, or transfering, or
+	 * transitively accessing. First input parameter is reference of this
+	 * introduced grant entry, second one is domid of granted domain, third
+	 * one is the frame to be granted, and the last one is status of the
+	 * grant entry to be updated.
+	 */
+	void (*update_entry)(grant_ref_t, domid_t, unsigned long, unsigned);
+	/*
+	 * Stop granting a grant entry to domain for accessing. First input
+	 * parameter is reference of a grant entry whose grant access will be
+	 * stopped, second one is not in use now. If the grant entry is
+	 * currently mapped for reading or writing, just return failure(==0)
+	 * directly and don't tear down the grant access. Otherwise, stop grant
+	 * access for this entry and return success(==1).
+	 */
+	int (*end_foreign_access_ref)(grant_ref_t, int);
+	/*
+	 * Stop granting a grant entry to domain for transfer. If tranfer has
+	 * not started, just reclaim the grant entry and return failure(==0).
+	 * Otherwise, wait for the transfer to complete and then return the
+	 * frame.
+	 */
+	unsigned long (*end_foreign_transfer_ref)(grant_ref_t);
+	/*
+	 * Query the status of a grant entry. Input parameter is reference of
+	 * queried grant entry, return value is the status of queried entry.
+	 * Detailed status(writing/reading) can be gotten from the return value
+	 * by bit operations.
+	 */
+	int (*query_foreign_access)(grant_ref_t);
+};
+
+static struct gnttab_ops *gnttab_interface;
+
+static int grant_table_version;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
 
@@ -142,23 +198,23 @@ static void put_free_entry(grant_ref_t ref)
 	spin_unlock_irqrestore(&gnttab_list_lock, flags);
 }
 
-static void update_grant_entry(grant_ref_t ref, domid_t domid,
-			       unsigned long frame, unsigned flags)
+/*
+ * Introducing a valid entry into the grant table:
+ *  1. Write ent->domid.
+ *  2. Write ent->frame:
+ *      GTF_permit_access:   Frame to which access is permitted.
+ *      GTF_accept_transfer: Pseudo-phys frame slot being filled by new
+ *                           frame, or zero if none.
+ *  3. Write memory barrier (WMB).
+ *  4. Write ent->flags, inc. valid type.
+ */
+static void gnttab_update_entry_v1(grant_ref_t ref, domid_t domid,
+				   unsigned long frame, unsigned flags)
 {
-	/*
-	 * Introducing a valid entry into the grant table:
-	 *  1. Write ent->domid.
-	 *  2. Write ent->frame:
-	 *      GTF_permit_access:   Frame to which access is permitted.
-	 *      GTF_accept_transfer: Pseudo-phys frame slot being filled by new
-	 *                           frame, or zero if none.
-	 *  3. Write memory barrier (WMB).
-	 *  4. Write ent->flags, inc. valid type.
-	 */
-	shared[ref].frame = frame;
-	shared[ref].domid = domid;
+	gnttab_shared.v1[ref].domid = domid;
+	gnttab_shared.v1[ref].frame = frame;
 	wmb();
-	shared[ref].flags = flags;
+	gnttab_shared.v1[ref].flags = flags;
 }
 
 /*
@@ -167,7 +223,7 @@ static void update_grant_entry(grant_ref_t ref, domid_t domid,
 void gnttab_grant_foreign_access_ref(grant_ref_t ref, domid_t domid,
 				     unsigned long frame, int readonly)
 {
-	update_grant_entry(ref, domid, frame,
+	gnttab_interface->update_entry(ref, domid, frame,
 			   GTF_permit_access | (readonly ? GTF_readonly : 0));
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access_ref);
@@ -187,31 +243,37 @@ int gnttab_grant_foreign_access(domid_t domid, unsigned long frame,
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_access);
 
-int gnttab_query_foreign_access(grant_ref_t ref)
+static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 {
-	u16 nflags;
-
-	nflags = shared[ref].flags;
+	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
+}
 
-	return nflags & (GTF_reading|GTF_writing);
+int gnttab_query_foreign_access(grant_ref_t ref)
+{
+	return gnttab_interface->query_foreign_access(ref);
 }
 EXPORT_SYMBOL_GPL(gnttab_query_foreign_access);
 
-int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 {
 	u16 flags, nflags;
 
-	nflags = shared[ref].flags;
+	nflags = gnttab_shared.v1[ref].flags;
 	do {
 		flags = nflags;
 		if (flags & (GTF_reading|GTF_writing)) {
 			printk(KERN_ALERT "WARNING: g.e. still in use!\n");
 			return 0;
 		}
-	} while ((nflags = sync_cmpxchg(&shared[ref].flags, flags, 0)) != flags);
+	} while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0)) != flags);
 
 	return 1;
 }
+
+int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
+{
+	return gnttab_interface->end_foreign_access_ref(ref, readonly);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_access_ref);
 
 void gnttab_end_foreign_access(grant_ref_t ref, int readonly,
@@ -246,11 +308,11 @@ EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer);
 void gnttab_grant_foreign_transfer_ref(grant_ref_t ref, domid_t domid,
 				       unsigned long pfn)
 {
-	update_grant_entry(ref, domid, pfn, GTF_accept_transfer);
+	gnttab_interface->update_entry(ref, domid, pfn, GTF_accept_transfer);
 }
 EXPORT_SYMBOL_GPL(gnttab_grant_foreign_transfer_ref);
 
-unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 {
 	unsigned long frame;
 	u16           flags;
@@ -259,24 +321,29 @@ unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
 	 * If a transfer is not even yet started, try to reclaim the grant
 	 * reference and return failure (== 0).
 	 */
-	while (!((flags = shared[ref].flags) & GTF_transfer_committed)) {
-		if (sync_cmpxchg(&shared[ref].flags, flags, 0) == flags)
+	while (!((flags = gnttab_shared.v1[ref].flags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0) == flags)
 			return 0;
 		cpu_relax();
 	}
 
 	/* If a transfer is in progress then wait until it is completed. */
 	while (!(flags & GTF_transfer_completed)) {
-		flags = shared[ref].flags;
+		flags = gnttab_shared.v1[ref].flags;
 		cpu_relax();
 	}
 
 	rmb();	/* Read the frame number /after/ reading completion status. */
-	frame = shared[ref].frame;
+	frame = gnttab_shared.v1[ref].frame;
 	BUG_ON(frame == 0);
 
 	return frame;
 }
+
+unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
+{
+	return gnttab_interface->end_foreign_transfer_ref(ref);
+}
 EXPORT_SYMBOL_GPL(gnttab_end_foreign_transfer_ref);
 
 unsigned long gnttab_end_foreign_transfer(grant_ref_t ref)
@@ -520,6 +587,23 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
+{
+	int rc;
+
+	rc = arch_gnttab_map_shared(frames, nr_gframes,
+				    gnttab_max_grant_frames(),
+				    &gnttab_shared.addr);
+	BUG_ON(rc);
+
+	return 0;
+}
+
+static void gnttab_unmap_frames_v1(void)
+{
+	arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+}
+
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
@@ -567,19 +651,35 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 
 	BUG_ON(rc || setup.status);
 
-	rc = arch_gnttab_map_shared(frames, nr_gframes, gnttab_max_grant_frames(),
-				    &shared);
-	BUG_ON(rc);
+	rc = gnttab_interface->map_frames(frames, nr_gframes);
 
 	kfree(frames);
 
-	return 0;
+	return rc;
+}
+
+static struct gnttab_ops gnttab_v1_ops = {
+	.map_frames			= gnttab_map_frames_v1,
+	.unmap_frames			= gnttab_unmap_frames_v1,
+	.update_entry			= gnttab_update_entry_v1,
+	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v1,
+	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v1,
+	.query_foreign_access		= gnttab_query_foreign_access_v1,
+};
+
+static void gnttab_request_version(void)
+{
+	grant_table_version = 1;
+	gnttab_interface = &gnttab_v1_ops;
+	printk(KERN_INFO "Grant tables using version %d layout.\n",
+		grant_table_version);
 }
 
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
 
+	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
@@ -587,9 +687,10 @@ int gnttab_resume(void)
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-	if (!shared) {
-		shared = ioremap(xen_hvm_resume_frames, PAGE_SIZE * max_nr_gframes);
-		if (shared == NULL) {
+	if (gnttab_shared.addr == NULL) {
+		gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
+						PAGE_SIZE * max_nr_gframes);
+		if (gnttab_shared.addr == NULL) {
 			printk(KERN_WARNING
 					"Failed to ioremap gnttab share frames!");
 			return -ENOMEM;
@@ -603,7 +704,7 @@ int gnttab_resume(void)
 
 int gnttab_suspend(void)
 {
-	arch_gnttab_unmap_shared(shared, nr_grant_frames);
+	gnttab_interface->unmap_frames();
 	return 0;
 }
 
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e2dfc..c7a40f8 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -145,8 +145,8 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
-			   struct grant_entry **__shared);
-void arch_gnttab_unmap_shared(struct grant_entry *shared,
+			   void **__shared);
+void arch_gnttab_unmap_shared(void *shared,
 			      unsigned long nr_gframes);
 
 extern unsigned long xen_hvm_resume_frames;
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index 39e5717..a17d844 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -85,12 +85,22 @@
  */
 
 /*
+ * Reference to a grant entry in a specified domain's grant table.
+ */
+typedef uint32_t grant_ref_t;
+
+/*
  * A grant table comprises a packed array of grant entries in one or more
  * page frames shared between Xen and a guest.
  * [XEN]: This field is written by Xen and read by the sharing guest.
  * [GST]: This field is written by the guest and read by Xen.
  */
-struct grant_entry {
+
+/*
+ * Version 1 of the grant table entry structure is maintained purely
+ * for backwards compatibility.  New guests should use version 2.
+ */
+struct grant_entry_v1 {
     /* GTF_xxx: various type and flag information.  [XEN,GST] */
     uint16_t flags;
     /* The domain being granted foreign privileges. [GST] */
@@ -108,10 +118,13 @@ struct grant_entry {
  *  GTF_permit_access: Allow @domid to map/access @frame.
  *  GTF_accept_transfer: Allow @domid to transfer ownership of one page frame
  *                       to this guest. Xen writes the page number to @frame.
+ *  GTF_transitive: Allow @domid to transitively access a subrange of
+ *                  @trans_grant in @trans_domid.  No mappings are allowed.
  */
 #define GTF_invalid         (0U<<0)
 #define GTF_permit_access   (1U<<0)
 #define GTF_accept_transfer (2U<<0)
+#define GTF_transitive      (3U<<0)
 #define GTF_type_mask       (3U<<0)
 
 /*
@@ -119,6 +132,9 @@ struct grant_entry {
  *  GTF_readonly: Restrict @domid to read-only mappings and accesses. [GST]
  *  GTF_reading: Grant entry is currently mapped for reading by @domid. [XEN]
  *  GTF_writing: Grant entry is currently mapped for writing by @domid. [XEN]
+ *  GTF_sub_page: Grant access to only a subrange of the page.  @domid
+ *                will only be allowed to copy from the grant, and not
+ *                map it. [GST]
  */
 #define _GTF_readonly       (2)
 #define GTF_readonly        (1U<<_GTF_readonly)
@@ -126,6 +142,8 @@ struct grant_entry {
 #define GTF_reading         (1U<<_GTF_reading)
 #define _GTF_writing        (4)
 #define GTF_writing         (1U<<_GTF_writing)
+#define _GTF_sub_page       (8)
+#define GTF_sub_page        (1U<<_GTF_sub_page)
 
 /*
  * Subflags for GTF_accept_transfer:
@@ -142,15 +160,81 @@ struct grant_entry {
 #define _GTF_transfer_completed (3)
 #define GTF_transfer_completed  (1U<<_GTF_transfer_completed)
 
+/*
+ * Version 2 grant table entries.  These fulfil the same role as
+ * version 1 entries, but can represent more complicated operations.
+ * Any given domain will have either a version 1 or a version 2 table,
+ * and every entry in the table will be the same version.
+ *
+ * The interface by which domains use grant references does not depend
+ * on the grant table version in use by the other domain.
+ */
 
-/***********************************
- * GRANT TABLE QUERIES AND USES
+/*
+ * Version 1 and version 2 grant entries share a common prefix.  The
+ * fields of the prefix are documented as part of struct
+ * grant_entry_v1.
  */
+struct grant_entry_header {
+    uint16_t flags;
+    domid_t  domid;
+};
 
 /*
- * Reference to a grant entry in a specified domain's grant table.
+ * Version 2 of the grant entry structure, here is an union because three
+ * different types are suppotted: full_page, sub_page and transitive.
+ */
+union grant_entry_v2 {
+    struct grant_entry_header hdr;
+
+    /*
+     * This member is used for V1-style full page grants, where either:
+     *
+     * -- hdr.type is GTF_accept_transfer, or
+     * -- hdr.type is GTF_permit_access and GTF_sub_page is not set.
+     *
+     * In that case, the frame field has the same semantics as the
+     * field of the same name in the V1 entry structure.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	uint32_t pad0;
+	uint64_t frame;
+    } full_page;
+
+    /*
+     * If the grant type is GTF_grant_access and GTF_sub_page is set,
+     * @domid is allowed to access bytes [@page_off,@page_off+@length)
+     * in frame @frame.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	uint16_t page_off;
+	uint16_t length;
+	uint64_t frame;
+    } sub_page;
+
+    /*
+     * If the grant is GTF_transitive, @domid is allowed to use the
+     * grant @gref in domain @trans_domid, as if it was the local
+     * domain.  Obviously, the transitive access must be compatible
+     * with the original grant.
+     */
+    struct {
+	struct grant_entry_header hdr;
+	domid_t trans_domid;
+	uint16_t pad0;
+	grant_ref_t gref;
+    } transitive;
+
+    uint32_t __spacer[4]; /* Pad to a power of two */
+};
+
+typedef uint16_t grant_status_t;
+
+/***********************************
+ * GRANT TABLE QUERIES AND USES
  */
-typedef uint32_t grant_ref_t;
 
 /*
  * Handle to track a mapping created via a grant reference.
@@ -322,6 +406,79 @@ struct gnttab_query_size {
 DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
 
 /*
+ * GNTTABOP_unmap_and_replace: Destroy one or more grant-reference mappings
+ * tracked by <handle> but atomically replace the page table entry with one
+ * pointing to the machine address under <new_addr>.  <new_addr> will be
+ * redirected to the null entry.
+ * NOTES:
+ *  1. The call may fail in an undefined manner if either mapping is not
+ *     tracked by <handle>.
+ *  2. After executing a batch of unmaps, it is guaranteed that no stale
+ *     mappings will remain in the device or host TLBs.
+ */
+#define GNTTABOP_unmap_and_replace    7
+struct gnttab_unmap_and_replace {
+    /* IN parameters. */
+    uint64_t host_addr;
+    uint64_t new_addr;
+    grant_handle_t handle;
+    /* OUT parameters. */
+    int16_t  status;              /* GNTST_* */
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_unmap_and_replace);
+
+/*
+ * GNTTABOP_set_version: Request a particular version of the grant
+ * table shared table structure.  This operation can only be performed
+ * once in any given domain.  It must be performed before any grants
+ * are activated; otherwise, the domain will be stuck with version 1.
+ * The only defined versions are 1 and 2.
+ */
+#define GNTTABOP_set_version          8
+struct gnttab_set_version {
+    /* IN parameters */
+    uint32_t version;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_set_version);
+
+/*
+ * GNTTABOP_get_status_frames: Get the list of frames used to store grant
+ * status for <dom>. In grant format version 2, the status is separated
+ * from the other shared grant fields to allow more efficient synchronization
+ * using barriers instead of atomic cmpexch operations.
+ * <nr_frames> specify the size of vector <frame_list>.
+ * The frame addresses are returned in the <frame_list>.
+ * Only <nr_frames> addresses are returned, even if the table is larger.
+ * NOTES:
+ *  1. <dom> may be specified as DOMID_SELF.
+ *  2. Only a sufficiently-privileged domain may specify <dom> != DOMID_SELF.
+ */
+#define GNTTABOP_get_status_frames     9
+struct gnttab_get_status_frames {
+    /* IN parameters. */
+    uint32_t nr_frames;
+    domid_t  dom;
+    /* OUT parameters. */
+    int16_t  status;              /* GNTST_* */
+    GUEST_HANDLE(uint64_t) frame_list;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_status_frames);
+
+/*
+ * GNTTABOP_get_version: Get the grant table version which is in
+ * effect for domain <dom>.
+ */
+#define GNTTABOP_get_version          10
+struct gnttab_get_version {
+    /* IN parameters */
+    domid_t dom;
+    uint16_t pad;
+    /* OUT parameters */
+    uint32_t version;
+};
+DEFINE_GUEST_HANDLE_STRUCT(gnttab_get_version);
+
+/*
  * Bitfield values for update_pin_status.flags.
  */
  /* Map the grant entry for access by I/O devices. */
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 6a6e914..a890804 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -523,6 +523,8 @@ struct tmem_op {
 	} u;
 };
 
+DEFINE_GUEST_HANDLE(u64);
+
 #else /* __ASSEMBLY__ */
 
 /* In assembly code we cannot use C numeric constant suffixes. */
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:27:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnZQ-0006t9-7l; Tue, 22 Nov 2011 10:27:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnZO-0006sn-HJ
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:27:18 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321957608!5198782!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6009 invoked from network); 22 Nov 2011 10:26:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:26:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMAQjMQ027824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:26:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMAQiEp017018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:26:44 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMAQdZd021680; Tue, 22 Nov 2011 04:26:39 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:26:38 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 18:26:46 +0800
Message-Id: <1321957606-10253-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECB77BB.9090401@oracle.com>
References: <4ECB77BB.9090401@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4ECB78E6.007A,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2/4] xen/granttable: Refactor some code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 18355a5..0518d04 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -257,15 +257,17 @@ EXPORT_SYMBOL_GPL(gnttab_query_foreign_access);
 static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 {
 	u16 flags, nflags;
+	u16 *pflags;
 
-	nflags = gnttab_shared.v1[ref].flags;
+	pflags = &gnttab_shared.v1[ref].flags;
+	nflags = *pflags;
 	do {
 		flags = nflags;
 		if (flags & (GTF_reading|GTF_writing)) {
 			printk(KERN_ALERT "WARNING: g.e. still in use!\n");
 			return 0;
 		}
-	} while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0)) != flags);
+	} while ((nflags = sync_cmpxchg(pflags, flags, 0)) != flags);
 
 	return 1;
 }
@@ -316,20 +318,23 @@ static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 {
 	unsigned long frame;
 	u16           flags;
+	u16          *pflags;
+
+	pflags = &gnttab_shared.v1[ref].flags;
 
 	/*
 	 * If a transfer is not even yet started, try to reclaim the grant
 	 * reference and return failure (== 0).
 	 */
-	while (!((flags = gnttab_shared.v1[ref].flags) & GTF_transfer_committed)) {
-		if (sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0) == flags)
+	while (!((flags = *pflags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(pflags, flags, 0) == flags)
 			return 0;
 		cpu_relax();
 	}
 
 	/* If a transfer is in progress then wait until it is completed. */
 	while (!(flags & GTF_transfer_completed)) {
-		flags = gnttab_shared.v1[ref].flags;
+		flags = *pflags;
 		cpu_relax();
 	}
 
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:27:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnZQ-0006t9-7l; Tue, 22 Nov 2011 10:27:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnZO-0006sn-HJ
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:27:18 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1321957608!5198782!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6009 invoked from network); 22 Nov 2011 10:26:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:26:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMAQjMQ027824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:26:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMAQiEp017018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:26:44 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMAQdZd021680; Tue, 22 Nov 2011 04:26:39 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:26:38 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 18:26:46 +0800
Message-Id: <1321957606-10253-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECB77BB.9090401@oracle.com>
References: <4ECB77BB.9090401@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4ECB78E6.007A,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2/4] xen/granttable: Refactor some code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 18355a5..0518d04 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -257,15 +257,17 @@ EXPORT_SYMBOL_GPL(gnttab_query_foreign_access);
 static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 {
 	u16 flags, nflags;
+	u16 *pflags;
 
-	nflags = gnttab_shared.v1[ref].flags;
+	pflags = &gnttab_shared.v1[ref].flags;
+	nflags = *pflags;
 	do {
 		flags = nflags;
 		if (flags & (GTF_reading|GTF_writing)) {
 			printk(KERN_ALERT "WARNING: g.e. still in use!\n");
 			return 0;
 		}
-	} while ((nflags = sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0)) != flags);
+	} while ((nflags = sync_cmpxchg(pflags, flags, 0)) != flags);
 
 	return 1;
 }
@@ -316,20 +318,23 @@ static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 {
 	unsigned long frame;
 	u16           flags;
+	u16          *pflags;
+
+	pflags = &gnttab_shared.v1[ref].flags;
 
 	/*
 	 * If a transfer is not even yet started, try to reclaim the grant
 	 * reference and return failure (== 0).
 	 */
-	while (!((flags = gnttab_shared.v1[ref].flags) & GTF_transfer_committed)) {
-		if (sync_cmpxchg(&gnttab_shared.v1[ref].flags, flags, 0) == flags)
+	while (!((flags = *pflags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(pflags, flags, 0) == flags)
 			return 0;
 		cpu_relax();
 	}
 
 	/* If a transfer is in progress then wait until it is completed. */
 	while (!(flags & GTF_transfer_completed)) {
-		flags = gnttab_shared.v1[ref].flags;
+		flags = *pflags;
 		cpu_relax();
 	}
 
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:28:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnZz-0006yq-MI; Tue, 22 Nov 2011 10:27:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnZy-0006xv-RT
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:27:55 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321957644!4100891!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26327 invoked from network); 22 Nov 2011 10:27:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:27:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMARLZA001515
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:27:21 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
	pAMARKr8011538
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:27:21 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMARFU1022155; Tue, 22 Nov 2011 04:27:15 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:27:15 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 18:27:23 +0800
Message-Id: <1321957643-10282-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECB77BB.9090401@oracle.com>
References: <4ECB77BB.9090401@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4ECB790A.0075,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 3/4] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Receiver-side copying of packets is based on this implementation, it gives
better performance and better CPU accounting. It totally supports three types:
full-page, sub-page and transitive grants.

However this patch does not cover sub-page and transitive grants, it mainly
focus on Full-page part and implements grant table V2 interfaces corresponding
to what already exists in grant table V1, such as: grant table V2
initialization, mapping, releasing and exported interfaces.

Each guest can only supports one type of grant table type, every entry in grant
table should be the same version. It is necessary to set V1 or V2 version before
initializing the grant table.

Grant table exported interfaces of V2 are same with those of V1, Xen is
responsible to judge what grant table version guests are using in every grant
operation.

V2 fulfills the same role of V1, and it is totally backwards compitable with V1.
If dom0 support grant table V2, the guests runing on it can run with either V1
or V2.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 arch/x86/xen/grant-table.c |   37 +++++++++-
 drivers/xen/grant-table.c  |  171 ++++++++++++++++++++++++++++++++++++++++++-
 include/xen/grant_table.h  |    6 +-
 3 files changed, 207 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index c6ab2e7..510fca0 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -54,6 +54,20 @@ static int map_pte_fn(pte_t *pte, struct page *pmd_page,
 	return 0;
 }
 
+/*
+ * This function is used to map shared frames to store grant status. It is
+ * different from map_pte_fn above, the frames type here is uint64_t.
+ */
+static int map_pte_fn_status(pte_t *pte, struct page *pmd_page,
+			     unsigned long addr, void *data)
+{
+	uint64_t **frames = (uint64_t **)data;
+
+	set_pte_at(&init_mm, addr, pte, mfn_pte((*frames)[0], PAGE_KERNEL));
+	(*frames)++;
+	return 0;
+}
+
 static int unmap_pte_fn(pte_t *pte, struct page *pmd_page,
 			unsigned long addr, void *data)
 {
@@ -83,7 +97,28 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 	return rc;
 }
 
-void arch_gnttab_unmap_shared(void *shared, unsigned long nr_gframes)
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared)
+{
+	int rc;
+	grant_status_t *shared = *__shared;
+
+	if (shared == NULL) {
+		struct vm_struct *area =
+			alloc_vm_area(PAGE_SIZE * max_nr_gframes);
+		BUG_ON(area == NULL);
+		shared = area->addr;
+		*__shared = shared;
+	}
+
+	rc = apply_to_page_range(&init_mm, (unsigned long)shared,
+				 PAGE_SIZE * nr_gframes,
+				 map_pte_fn_status, &frames);
+	return rc;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
 {
 	apply_to_page_range(&init_mm, (unsigned long)shared,
 			    PAGE_SIZE * nr_gframes, unmap_pte_fn, NULL);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0518d04..94831b8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -44,6 +44,7 @@
 #include <xen/page.h>
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
+#include <xen/hvc-console.h>
 #include <asm/xen/hypercall.h>
 
 #include <asm/pgtable.h>
@@ -53,7 +54,10 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry_v1))
+#define GREFS_PER_GRANT_FRAME \
+(grant_table_version == 1 ?                      \
+ (PAGE_SIZE / sizeof(struct grant_entry_v1)) :   \
+ (PAGE_SIZE / sizeof(union grant_entry_v2)))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -66,6 +70,7 @@ EXPORT_SYMBOL_GPL(xen_hvm_resume_frames);
 
 static union {
 	struct grant_entry_v1 *v1;
+	union grant_entry_v2 *v2;
 	void *addr;
 } gnttab_shared;
 
@@ -120,6 +125,9 @@ struct gnttab_ops {
 
 static struct gnttab_ops *gnttab_interface;
 
+/*This reflects status of grant entries, so act as a global value*/
+static grant_status_t *grstatus;
+
 static int grant_table_version;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
@@ -127,6 +135,7 @@ static struct gnttab_free_callback *gnttab_free_callback_list;
 static int gnttab_expand(unsigned int req_entries);
 
 #define RPP (PAGE_SIZE / sizeof(grant_ref_t))
+#define SPP (PAGE_SIZE / sizeof(grant_status_t))
 
 static inline grant_ref_t *__gnttab_entry(grant_ref_t entry)
 {
@@ -199,6 +208,7 @@ static void put_free_entry(grant_ref_t ref)
 }
 
 /*
+ * Following applies to gnttab_update_entry_v1 and gnttab_update_entry_v2.
  * Introducing a valid entry into the grant table:
  *  1. Write ent->domid.
  *  2. Write ent->frame:
@@ -217,6 +227,15 @@ static void gnttab_update_entry_v1(grant_ref_t ref, domid_t domid,
 	gnttab_shared.v1[ref].flags = flags;
 }
 
+static void gnttab_update_entry_v2(grant_ref_t ref, domid_t domid,
+				   unsigned long frame, unsigned flags)
+{
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	gnttab_shared.v2[ref].full_page.frame = frame;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags = GTF_permit_access | flags;
+}
+
 /*
  * Public grant-issuing interface functions
  */
@@ -248,6 +267,11 @@ static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
 }
 
+static int gnttab_query_foreign_access_v2(grant_ref_t ref)
+{
+	return grstatus[ref] & (GTF_reading|GTF_writing);
+}
+
 int gnttab_query_foreign_access(grant_ref_t ref)
 {
 	return gnttab_interface->query_foreign_access(ref);
@@ -272,6 +296,29 @@ static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 	return 1;
 }
 
+static int gnttab_end_foreign_access_ref_v2(grant_ref_t ref, int readonly)
+{
+	gnttab_shared.v2[ref].hdr.flags = 0;
+	mb();
+	if (grstatus[ref] & (GTF_reading|GTF_writing)) {
+		return 0;
+	} else {
+		/* The read of grstatus needs to have acquire
+		semantics.  On x86, reads already have
+		that, and we just need to protect against
+		compiler reorderings.  On other
+		architectures we may need a full
+		barrier. */
+#ifdef CONFIG_X86
+		barrier();
+#else
+		mb();
+#endif
+	}
+
+	return 1;
+}
+
 int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
 {
 	return gnttab_interface->end_foreign_access_ref(ref, readonly);
@@ -345,6 +392,37 @@ static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 	return frame;
 }
 
+static unsigned long gnttab_end_foreign_transfer_ref_v2(grant_ref_t ref)
+{
+	unsigned long frame;
+	u16           flags;
+	u16          *pflags;
+
+	pflags = &gnttab_shared.v2[ref].hdr.flags;
+
+	/*
+	 * If a transfer is not even yet started, try to reclaim the grant
+	 * reference and return failure (== 0).
+	 */
+	while (!((flags = *pflags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(pflags, flags, 0) == flags)
+			return 0;
+		cpu_relax();
+	}
+
+	/* If a transfer is in progress then wait until it is completed. */
+	while (!(flags & GTF_transfer_completed)) {
+		flags = *pflags;
+		cpu_relax();
+	}
+
+	rmb();  /* Read the frame number /after/ reading completion status. */
+	frame = gnttab_shared.v2[ref].full_page.frame;
+	BUG_ON(frame == 0);
+
+	return frame;
+}
+
 unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
 {
 	return gnttab_interface->end_foreign_transfer_ref(ref);
@@ -592,6 +670,11 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static unsigned nr_status_frames(unsigned nr_grant_frames)
+{
+	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
+}
+
 static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 {
 	int rc;
@@ -606,7 +689,56 @@ static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 
 static void gnttab_unmap_frames_v1(void)
 {
-	arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+}
+
+static int gnttab_map_frames_v2(unsigned long *frames, unsigned int nr_gframes)
+{
+	uint64_t *sframes;
+	unsigned int nr_sframes;
+	struct gnttab_get_status_frames getframes;
+	int rc;
+
+	nr_sframes = nr_status_frames(nr_gframes);
+
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_get_status_frames.
+	 */
+	sframes = kmalloc(nr_sframes  * sizeof(uint64_t), GFP_ATOMIC);
+	if (!sframes)
+		return -ENOMEM;
+
+	getframes.dom        = DOMID_SELF;
+	getframes.nr_frames  = nr_sframes;
+	set_xen_guest_handle(getframes.frame_list, sframes);
+
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_get_status_frames,
+				       &getframes, 1);
+	if (rc == -ENOSYS) {
+		kfree(sframes);
+		return -ENOSYS;
+	}
+
+	BUG_ON(rc || getframes.status);
+
+	rc = arch_gnttab_map_status(sframes, nr_sframes,
+				    nr_status_frames(gnttab_max_grant_frames()),
+				    &grstatus);
+	BUG_ON(rc);
+	kfree(sframes);
+
+	rc = arch_gnttab_map_shared(frames, nr_gframes,
+				    gnttab_max_grant_frames(),
+				    &gnttab_shared.addr);
+	BUG_ON(rc);
+
+	return 0;
+}
+
+static void gnttab_unmap_frames_v2(void)
+{
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(grstatus, nr_status_frames(nr_grant_frames));
 }
 
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
@@ -640,6 +772,9 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		return rc;
 	}
 
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_setup_table.
+	 */
 	frames = kmalloc(nr_gframes * sizeof(unsigned long), GFP_ATOMIC);
 	if (!frames)
 		return -ENOMEM;
@@ -672,10 +807,38 @@ static struct gnttab_ops gnttab_v1_ops = {
 	.query_foreign_access		= gnttab_query_foreign_access_v1,
 };
 
+static struct gnttab_ops gnttab_v2_ops = {
+	.map_frames			= gnttab_map_frames_v2,
+	.unmap_frames			= gnttab_unmap_frames_v2,
+	.update_entry			= gnttab_update_entry_v2,
+	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
+	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
+	.query_foreign_access		= gnttab_query_foreign_access_v2,
+};
+
 static void gnttab_request_version(void)
 {
-	grant_table_version = 1;
-	gnttab_interface = &gnttab_v1_ops;
+	int rc;
+	struct gnttab_set_version gsv;
+
+	gsv.version = 2;
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
+	if (rc == 0) {
+		grant_table_version = 2;
+		gnttab_interface = &gnttab_v2_ops;
+	} else if (grant_table_version == 2) {
+		/*
+		 * If we've already used version 2 features,
+		 * but then suddenly discover that they're not
+		 * available (e.g. migrating to an older
+		 * version of Xen), almost unbounded badness
+		 * can happen.
+		 */
+		panic("we need grant tables version 2, but only version 1 is available");
+	} else {
+		grant_table_version = 1;
+		gnttab_interface = &gnttab_v1_ops;
+	}
 	printk(KERN_INFO "Grant tables using version %d layout.\n",
 		grant_table_version);
 }
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index c7a40f8..5494c40 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -146,8 +146,10 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
 			   void **__shared);
-void arch_gnttab_unmap_shared(void *shared,
-			      unsigned long nr_gframes);
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared);
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes);
 
 extern unsigned long xen_hvm_resume_frames;
 unsigned int gnttab_max_grant_frames(void);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:28:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnZz-0006yq-MI; Tue, 22 Nov 2011 10:27:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnZy-0006xv-RT
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:27:55 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1321957644!4100891!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26327 invoked from network); 22 Nov 2011 10:27:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:27:25 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMARLZA001515
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:27:21 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
	pAMARKr8011538
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:27:21 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMARFU1022155; Tue, 22 Nov 2011 04:27:15 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:27:15 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 18:27:23 +0800
Message-Id: <1321957643-10282-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECB77BB.9090401@oracle.com>
References: <4ECB77BB.9090401@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4ECB790A.0075,ss=1,re=-2.300,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 3/4] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Receiver-side copying of packets is based on this implementation, it gives
better performance and better CPU accounting. It totally supports three types:
full-page, sub-page and transitive grants.

However this patch does not cover sub-page and transitive grants, it mainly
focus on Full-page part and implements grant table V2 interfaces corresponding
to what already exists in grant table V1, such as: grant table V2
initialization, mapping, releasing and exported interfaces.

Each guest can only supports one type of grant table type, every entry in grant
table should be the same version. It is necessary to set V1 or V2 version before
initializing the grant table.

Grant table exported interfaces of V2 are same with those of V1, Xen is
responsible to judge what grant table version guests are using in every grant
operation.

V2 fulfills the same role of V1, and it is totally backwards compitable with V1.
If dom0 support grant table V2, the guests runing on it can run with either V1
or V2.

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 arch/x86/xen/grant-table.c |   37 +++++++++-
 drivers/xen/grant-table.c  |  171 ++++++++++++++++++++++++++++++++++++++++++-
 include/xen/grant_table.h  |    6 +-
 3 files changed, 207 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index c6ab2e7..510fca0 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -54,6 +54,20 @@ static int map_pte_fn(pte_t *pte, struct page *pmd_page,
 	return 0;
 }
 
+/*
+ * This function is used to map shared frames to store grant status. It is
+ * different from map_pte_fn above, the frames type here is uint64_t.
+ */
+static int map_pte_fn_status(pte_t *pte, struct page *pmd_page,
+			     unsigned long addr, void *data)
+{
+	uint64_t **frames = (uint64_t **)data;
+
+	set_pte_at(&init_mm, addr, pte, mfn_pte((*frames)[0], PAGE_KERNEL));
+	(*frames)++;
+	return 0;
+}
+
 static int unmap_pte_fn(pte_t *pte, struct page *pmd_page,
 			unsigned long addr, void *data)
 {
@@ -83,7 +97,28 @@ int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 	return rc;
 }
 
-void arch_gnttab_unmap_shared(void *shared, unsigned long nr_gframes)
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared)
+{
+	int rc;
+	grant_status_t *shared = *__shared;
+
+	if (shared == NULL) {
+		struct vm_struct *area =
+			alloc_vm_area(PAGE_SIZE * max_nr_gframes);
+		BUG_ON(area == NULL);
+		shared = area->addr;
+		*__shared = shared;
+	}
+
+	rc = apply_to_page_range(&init_mm, (unsigned long)shared,
+				 PAGE_SIZE * nr_gframes,
+				 map_pte_fn_status, &frames);
+	return rc;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
 {
 	apply_to_page_range(&init_mm, (unsigned long)shared,
 			    PAGE_SIZE * nr_gframes, unmap_pte_fn, NULL);
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0518d04..94831b8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -44,6 +44,7 @@
 #include <xen/page.h>
 #include <xen/grant_table.h>
 #include <xen/interface/memory.h>
+#include <xen/hvc-console.h>
 #include <asm/xen/hypercall.h>
 
 #include <asm/pgtable.h>
@@ -53,7 +54,10 @@
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
-#define GREFS_PER_GRANT_FRAME (PAGE_SIZE / sizeof(struct grant_entry_v1))
+#define GREFS_PER_GRANT_FRAME \
+(grant_table_version == 1 ?                      \
+ (PAGE_SIZE / sizeof(struct grant_entry_v1)) :   \
+ (PAGE_SIZE / sizeof(union grant_entry_v2)))
 
 static grant_ref_t **gnttab_list;
 static unsigned int nr_grant_frames;
@@ -66,6 +70,7 @@ EXPORT_SYMBOL_GPL(xen_hvm_resume_frames);
 
 static union {
 	struct grant_entry_v1 *v1;
+	union grant_entry_v2 *v2;
 	void *addr;
 } gnttab_shared;
 
@@ -120,6 +125,9 @@ struct gnttab_ops {
 
 static struct gnttab_ops *gnttab_interface;
 
+/*This reflects status of grant entries, so act as a global value*/
+static grant_status_t *grstatus;
+
 static int grant_table_version;
 
 static struct gnttab_free_callback *gnttab_free_callback_list;
@@ -127,6 +135,7 @@ static struct gnttab_free_callback *gnttab_free_callback_list;
 static int gnttab_expand(unsigned int req_entries);
 
 #define RPP (PAGE_SIZE / sizeof(grant_ref_t))
+#define SPP (PAGE_SIZE / sizeof(grant_status_t))
 
 static inline grant_ref_t *__gnttab_entry(grant_ref_t entry)
 {
@@ -199,6 +208,7 @@ static void put_free_entry(grant_ref_t ref)
 }
 
 /*
+ * Following applies to gnttab_update_entry_v1 and gnttab_update_entry_v2.
  * Introducing a valid entry into the grant table:
  *  1. Write ent->domid.
  *  2. Write ent->frame:
@@ -217,6 +227,15 @@ static void gnttab_update_entry_v1(grant_ref_t ref, domid_t domid,
 	gnttab_shared.v1[ref].flags = flags;
 }
 
+static void gnttab_update_entry_v2(grant_ref_t ref, domid_t domid,
+				   unsigned long frame, unsigned flags)
+{
+	gnttab_shared.v2[ref].hdr.domid = domid;
+	gnttab_shared.v2[ref].full_page.frame = frame;
+	wmb();
+	gnttab_shared.v2[ref].hdr.flags = GTF_permit_access | flags;
+}
+
 /*
  * Public grant-issuing interface functions
  */
@@ -248,6 +267,11 @@ static int gnttab_query_foreign_access_v1(grant_ref_t ref)
 	return gnttab_shared.v1[ref].flags & (GTF_reading|GTF_writing);
 }
 
+static int gnttab_query_foreign_access_v2(grant_ref_t ref)
+{
+	return grstatus[ref] & (GTF_reading|GTF_writing);
+}
+
 int gnttab_query_foreign_access(grant_ref_t ref)
 {
 	return gnttab_interface->query_foreign_access(ref);
@@ -272,6 +296,29 @@ static int gnttab_end_foreign_access_ref_v1(grant_ref_t ref, int readonly)
 	return 1;
 }
 
+static int gnttab_end_foreign_access_ref_v2(grant_ref_t ref, int readonly)
+{
+	gnttab_shared.v2[ref].hdr.flags = 0;
+	mb();
+	if (grstatus[ref] & (GTF_reading|GTF_writing)) {
+		return 0;
+	} else {
+		/* The read of grstatus needs to have acquire
+		semantics.  On x86, reads already have
+		that, and we just need to protect against
+		compiler reorderings.  On other
+		architectures we may need a full
+		barrier. */
+#ifdef CONFIG_X86
+		barrier();
+#else
+		mb();
+#endif
+	}
+
+	return 1;
+}
+
 int gnttab_end_foreign_access_ref(grant_ref_t ref, int readonly)
 {
 	return gnttab_interface->end_foreign_access_ref(ref, readonly);
@@ -345,6 +392,37 @@ static unsigned long gnttab_end_foreign_transfer_ref_v1(grant_ref_t ref)
 	return frame;
 }
 
+static unsigned long gnttab_end_foreign_transfer_ref_v2(grant_ref_t ref)
+{
+	unsigned long frame;
+	u16           flags;
+	u16          *pflags;
+
+	pflags = &gnttab_shared.v2[ref].hdr.flags;
+
+	/*
+	 * If a transfer is not even yet started, try to reclaim the grant
+	 * reference and return failure (== 0).
+	 */
+	while (!((flags = *pflags) & GTF_transfer_committed)) {
+		if (sync_cmpxchg(pflags, flags, 0) == flags)
+			return 0;
+		cpu_relax();
+	}
+
+	/* If a transfer is in progress then wait until it is completed. */
+	while (!(flags & GTF_transfer_completed)) {
+		flags = *pflags;
+		cpu_relax();
+	}
+
+	rmb();  /* Read the frame number /after/ reading completion status. */
+	frame = gnttab_shared.v2[ref].full_page.frame;
+	BUG_ON(frame == 0);
+
+	return frame;
+}
+
 unsigned long gnttab_end_foreign_transfer_ref(grant_ref_t ref)
 {
 	return gnttab_interface->end_foreign_transfer_ref(ref);
@@ -592,6 +670,11 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 }
 EXPORT_SYMBOL_GPL(gnttab_unmap_refs);
 
+static unsigned nr_status_frames(unsigned nr_grant_frames)
+{
+	return (nr_grant_frames * GREFS_PER_GRANT_FRAME + SPP - 1) / SPP;
+}
+
 static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 {
 	int rc;
@@ -606,7 +689,56 @@ static int gnttab_map_frames_v1(unsigned long *frames, unsigned int nr_gframes)
 
 static void gnttab_unmap_frames_v1(void)
 {
-	arch_gnttab_unmap_shared(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+}
+
+static int gnttab_map_frames_v2(unsigned long *frames, unsigned int nr_gframes)
+{
+	uint64_t *sframes;
+	unsigned int nr_sframes;
+	struct gnttab_get_status_frames getframes;
+	int rc;
+
+	nr_sframes = nr_status_frames(nr_gframes);
+
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_get_status_frames.
+	 */
+	sframes = kmalloc(nr_sframes  * sizeof(uint64_t), GFP_ATOMIC);
+	if (!sframes)
+		return -ENOMEM;
+
+	getframes.dom        = DOMID_SELF;
+	getframes.nr_frames  = nr_sframes;
+	set_xen_guest_handle(getframes.frame_list, sframes);
+
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_get_status_frames,
+				       &getframes, 1);
+	if (rc == -ENOSYS) {
+		kfree(sframes);
+		return -ENOSYS;
+	}
+
+	BUG_ON(rc || getframes.status);
+
+	rc = arch_gnttab_map_status(sframes, nr_sframes,
+				    nr_status_frames(gnttab_max_grant_frames()),
+				    &grstatus);
+	BUG_ON(rc);
+	kfree(sframes);
+
+	rc = arch_gnttab_map_shared(frames, nr_gframes,
+				    gnttab_max_grant_frames(),
+				    &gnttab_shared.addr);
+	BUG_ON(rc);
+
+	return 0;
+}
+
+static void gnttab_unmap_frames_v2(void)
+{
+	arch_gnttab_unmap(gnttab_shared.addr, nr_grant_frames);
+	arch_gnttab_unmap(grstatus, nr_status_frames(nr_grant_frames));
 }
 
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
@@ -640,6 +772,9 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 		return rc;
 	}
 
+	/* No need for kzalloc as it is initialized in following hypercall
+	 * GNTTABOP_setup_table.
+	 */
 	frames = kmalloc(nr_gframes * sizeof(unsigned long), GFP_ATOMIC);
 	if (!frames)
 		return -ENOMEM;
@@ -672,10 +807,38 @@ static struct gnttab_ops gnttab_v1_ops = {
 	.query_foreign_access		= gnttab_query_foreign_access_v1,
 };
 
+static struct gnttab_ops gnttab_v2_ops = {
+	.map_frames			= gnttab_map_frames_v2,
+	.unmap_frames			= gnttab_unmap_frames_v2,
+	.update_entry			= gnttab_update_entry_v2,
+	.end_foreign_access_ref		= gnttab_end_foreign_access_ref_v2,
+	.end_foreign_transfer_ref	= gnttab_end_foreign_transfer_ref_v2,
+	.query_foreign_access		= gnttab_query_foreign_access_v2,
+};
+
 static void gnttab_request_version(void)
 {
-	grant_table_version = 1;
-	gnttab_interface = &gnttab_v1_ops;
+	int rc;
+	struct gnttab_set_version gsv;
+
+	gsv.version = 2;
+	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
+	if (rc == 0) {
+		grant_table_version = 2;
+		gnttab_interface = &gnttab_v2_ops;
+	} else if (grant_table_version == 2) {
+		/*
+		 * If we've already used version 2 features,
+		 * but then suddenly discover that they're not
+		 * available (e.g. migrating to an older
+		 * version of Xen), almost unbounded badness
+		 * can happen.
+		 */
+		panic("we need grant tables version 2, but only version 1 is available");
+	} else {
+		grant_table_version = 1;
+		gnttab_interface = &gnttab_v1_ops;
+	}
 	printk(KERN_INFO "Grant tables using version %d layout.\n",
 		grant_table_version);
 }
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index c7a40f8..5494c40 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -146,8 +146,10 @@ gnttab_set_unmap_op(struct gnttab_unmap_grant_ref *unmap, phys_addr_t addr,
 int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
 			   unsigned long max_nr_gframes,
 			   void **__shared);
-void arch_gnttab_unmap_shared(void *shared,
-			      unsigned long nr_gframes);
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared);
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes);
 
 extern unsigned long xen_hvm_resume_frames;
 unsigned int gnttab_max_grant_frames(void);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:28:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSna4-0006zd-40; Tue, 22 Nov 2011 10:28:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RSna2-0006yJ-7t
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:27:58 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321957649!4482140!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26722 invoked from network); 22 Nov 2011 10:27:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-216.messagelabs.com with SMTP;
	22 Nov 2011 10:27:29 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73342607; Tue, 22 Nov 2011 11:27:28 +0100
Message-ID: <1321957647.4878.5.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 22 Nov 2011 11:27:27 +0100
In-Reply-To: <4ECB67CF0200007800062465@nat28.tlf.novell.com>
References: <osstest-9955-mainreport@xen.org>
	<CAF102CD.2555F%keir.xen@gmail.com>
	<4ECB67CF0200007800062465@nat28.tlf.novell.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.1 (3.2.1-2.fc16) 
Mime-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6878282231039371348=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6878282231039371348==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-+whaJ6ZrU7OnWq37vJYi"


--=-+whaJ6ZrU7OnWq37vJYi
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-11-22 at 08:13 +0000, Jan Beulich wrote:
> I don't think so - the sedf thing (with varying sub-tests iirc) has been
> (inconsistently) failing for quite a long while.
>=20
Indeed, and I'm starting looking into this to see if we can figure out
what's causing these tests to fail every now and then.

> Further, here this test wasn't even run because xen-boot (below)
> failed. And no matter how many times I looked at the respective
> logs, I wasn't able to spot what it really is that fails here. I can only
> assume that Dom0 is hung, but my sedf knowledge doesn't go far
> enough to tell that for sure from the dumped data.
>=20
Yes, Dom0 hangs rock solid, and hung task detection fires if it is
compiled into Linux, otherwise, I see RCU periodically reporting stall
on some CPU in the system. I'm quite in an interesting situation for
debugging this, since it fails _reliably_ on my 12 cores testbox... The
only thing I'm missing is a serial console cable, but I'm trying to get
around this! :-P

I'll dig this in the next days and let the list know.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)




--=-+whaJ6ZrU7OnWq37vJYi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7LeQ8ACgkQk4XaBE3IOsTauwCfQwtW2wIGFMmEkABviPe+gJsA
id8An3NF4vvkydo/uO3U/a7LY/LLaG8f
=/pN6
-----END PGP SIGNATURE-----

--=-+whaJ6ZrU7OnWq37vJYi--



--===============6878282231039371348==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6878282231039371348==--



From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:28:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSna4-0006zd-40; Tue, 22 Nov 2011 10:28:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RSna2-0006yJ-7t
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:27:58 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321957649!4482140!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26722 invoked from network); 22 Nov 2011 10:27:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-216.messagelabs.com with SMTP;
	22 Nov 2011 10:27:29 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73342607; Tue, 22 Nov 2011 11:27:28 +0100
Message-ID: <1321957647.4878.5.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 22 Nov 2011 11:27:27 +0100
In-Reply-To: <4ECB67CF0200007800062465@nat28.tlf.novell.com>
References: <osstest-9955-mainreport@xen.org>
	<CAF102CD.2555F%keir.xen@gmail.com>
	<4ECB67CF0200007800062465@nat28.tlf.novell.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.1 (3.2.1-2.fc16) 
Mime-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6878282231039371348=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6878282231039371348==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-+whaJ6ZrU7OnWq37vJYi"


--=-+whaJ6ZrU7OnWq37vJYi
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-11-22 at 08:13 +0000, Jan Beulich wrote:
> I don't think so - the sedf thing (with varying sub-tests iirc) has been
> (inconsistently) failing for quite a long while.
>=20
Indeed, and I'm starting looking into this to see if we can figure out
what's causing these tests to fail every now and then.

> Further, here this test wasn't even run because xen-boot (below)
> failed. And no matter how many times I looked at the respective
> logs, I wasn't able to spot what it really is that fails here. I can only
> assume that Dom0 is hung, but my sedf knowledge doesn't go far
> enough to tell that for sure from the dumped data.
>=20
Yes, Dom0 hangs rock solid, and hung task detection fires if it is
compiled into Linux, otherwise, I see RCU periodically reporting stall
on some CPU in the system. I'm quite in an interesting situation for
debugging this, since it fails _reliably_ on my 12 cores testbox... The
only thing I'm missing is a serial console cable, but I'm trying to get
around this! :-P

I'll dig this in the next days and let the list know.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)




--=-+whaJ6ZrU7OnWq37vJYi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7LeQ8ACgkQk4XaBE3IOsTauwCfQwtW2wIGFMmEkABviPe+gJsA
id8An3NF4vvkydo/uO3U/a7LY/LLaG8f
=/pN6
-----END PGP SIGNATURE-----

--=-+whaJ6ZrU7OnWq37vJYi--



--===============6878282231039371348==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6878282231039371348==--



From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:28:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:28:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnaT-00076F-Sf; Tue, 22 Nov 2011 10:28:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnaR-00074t-GY
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:28:23 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321957673!2525605!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29510 invoked from network); 22 Nov 2011 10:27:54 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:27:54 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMARoQG029098
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:27:51 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMARnEI018778
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:27:50 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMARiTo022476; Tue, 22 Nov 2011 04:27:44 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:27:43 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 18:27:52 +0800
Message-Id: <1321957672-10317-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECB77BB.9090401@oracle.com>
References: <4ECB77BB.9090401@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4ECB7927.00E5,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 4/4] xen/granttable: Keep code format clean
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |    7 +++----
 include/xen/grant_table.h |    2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 94831b8..d747cf3 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -50,7 +50,6 @@
 #include <asm/pgtable.h>
 #include <asm/sync_bitops.h>
 
-
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
@@ -598,8 +597,8 @@ unsigned int gnttab_max_grant_frames(void)
 EXPORT_SYMBOL_GPL(gnttab_max_grant_frames);
 
 int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
-			struct gnttab_map_grant_ref *kmap_ops,
-			struct page **pages, unsigned int count)
+		    struct gnttab_map_grant_ref *kmap_ops,
+		    struct page **pages, unsigned int count)
 {
 	int i, ret;
 	pte_t *pte;
@@ -649,7 +648,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		struct page **pages, unsigned int count)
+		      struct page **pages, unsigned int count)
 {
 	int i, ret;
 
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 5494c40..fea4954 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -157,7 +157,7 @@ unsigned int gnttab_max_grant_frames(void);
 #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr))
 
 int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
-			struct gnttab_map_grant_ref *kmap_ops,
+		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		      struct page **pages, unsigned int count);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:28:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:28:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnaT-00076F-Sf; Tue, 22 Nov 2011 10:28:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RSnaR-00074t-GY
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:28:23 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321957673!2525605!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29510 invoked from network); 22 Nov 2011 10:27:54 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 10:27:54 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMARoQG029098
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 10:27:51 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMARnEI018778
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 10:27:50 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMARiTo022476; Tue, 22 Nov 2011 04:27:44 -0600
Received: from annie2.cn.oracle.com.com (/10.182.37.169)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 02:27:43 -0800
From: annie.li@oracle.com
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, jeremy@goop.org
Date: Tue, 22 Nov 2011 18:27:52 +0800
Message-Id: <1321957672-10317-1-git-send-email-annie.li@oracle.com>
X-Mailer: git-send-email 1.7.6.4
In-Reply-To: <4ECB77BB.9090401@oracle.com>
References: <4ECB77BB.9090401@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4ECB7927.00E5,ss=1,re=0.000,fgs=0
Cc: kurt.hackel@oracle.com, annie.li@oracle.com, paul.durrant@citrix.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 4/4] xen/granttable: Keep code format clean
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Annie Li <annie.li@oracle.com>

Signed-off-by: Annie Li <annie.li@oracle.com>
---
 drivers/xen/grant-table.c |    7 +++----
 include/xen/grant_table.h |    2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 94831b8..d747cf3 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -50,7 +50,6 @@
 #include <asm/pgtable.h>
 #include <asm/sync_bitops.h>
 
-
 /* External tools reserve first few grant table entries. */
 #define NR_RESERVED_ENTRIES 8
 #define GNTTAB_LIST_END 0xffffffff
@@ -598,8 +597,8 @@ unsigned int gnttab_max_grant_frames(void)
 EXPORT_SYMBOL_GPL(gnttab_max_grant_frames);
 
 int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
-			struct gnttab_map_grant_ref *kmap_ops,
-			struct page **pages, unsigned int count)
+		    struct gnttab_map_grant_ref *kmap_ops,
+		    struct page **pages, unsigned int count)
 {
 	int i, ret;
 	pte_t *pte;
@@ -649,7 +648,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		struct page **pages, unsigned int count)
+		      struct page **pages, unsigned int count)
 {
 	int i, ret;
 
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 5494c40..fea4954 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -157,7 +157,7 @@ unsigned int gnttab_max_grant_frames(void);
 #define gnttab_map_vaddr(map) ((void *)(map.host_virt_addr))
 
 int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
-			struct gnttab_map_grant_ref *kmap_ops,
+		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		      struct page **pages, unsigned int count);
-- 
1.7.6.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:28:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:28:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnaW-00076p-9i; Tue, 22 Nov 2011 10:28:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RSnaV-00075g-9Z
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:28:27 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321957678!5212112!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9323 invoked from network); 22 Nov 2011 10:27:58 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-21.messagelabs.com with SMTP;
	22 Nov 2011 10:27:58 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73342614; Tue, 22 Nov 2011 11:27:57 +0100
Message-ID: <1321957676.4878.6.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Tue, 22 Nov 2011 11:27:56 +0100
In-Reply-To: <4ECB5E0D.9020407@ts.fujitsu.com>
References: <CAF102CD.2555F%keir.xen@gmail.com>
	<4ECB5E0D.9020407@ts.fujitsu.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.1 (3.2.1-2.fc16) 
Mime-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3238306759301684749=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3238306759301684749==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-+lDN6Tt+53N22fQ0SfIZ"


--=-+lDN6Tt+53N22fQ0SfIZ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-11-22 at 09:32 +0100, Juergen Gross wrote:
> As Jan already wrote: booting failed with sched=3Dsedf. It works on my ma=
chine
> (4 core Nehalem) with cs 24269.
>=20
As said, it hangs on the 16 Xeon cores (did I say 12 in the other mail?
Bha!) I hve here, while it boots on a very similar --still 16 cores
Xeon-- I use remotely! :-O

I'll let you know when I will have something...

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

--=-+lDN6Tt+53N22fQ0SfIZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7LeS0ACgkQk4XaBE3IOsRsswCgh6K0VDd7zwUpC0jhx/6FPqmA
45EAoIBvSoMm1yY5pP5JVTqRpNUJWLGl
=TIrV
-----END PGP SIGNATURE-----

--=-+lDN6Tt+53N22fQ0SfIZ--



--===============3238306759301684749==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3238306759301684749==--



From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:28:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:28:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnaW-00076p-9i; Tue, 22 Nov 2011 10:28:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RSnaV-00075g-9Z
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:28:27 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321957678!5212112!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9323 invoked from network); 22 Nov 2011 10:27:58 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-21.messagelabs.com with SMTP;
	22 Nov 2011 10:27:58 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73342614; Tue, 22 Nov 2011 11:27:57 +0100
Message-ID: <1321957676.4878.6.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Tue, 22 Nov 2011 11:27:56 +0100
In-Reply-To: <4ECB5E0D.9020407@ts.fujitsu.com>
References: <CAF102CD.2555F%keir.xen@gmail.com>
	<4ECB5E0D.9020407@ts.fujitsu.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.1 (3.2.1-2.fc16) 
Mime-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3238306759301684749=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3238306759301684749==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-+lDN6Tt+53N22fQ0SfIZ"


--=-+lDN6Tt+53N22fQ0SfIZ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-11-22 at 09:32 +0100, Juergen Gross wrote:
> As Jan already wrote: booting failed with sched=3Dsedf. It works on my ma=
chine
> (4 core Nehalem) with cs 24269.
>=20
As said, it hangs on the 16 Xeon cores (did I say 12 in the other mail?
Bha!) I hve here, while it boots on a very similar --still 16 cores
Xeon-- I use remotely! :-O

I'll let you know when I will have something...

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

--=-+lDN6Tt+53N22fQ0SfIZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7LeS0ACgkQk4XaBE3IOsRsswCgh6K0VDd7zwUpC0jhx/6FPqmA
45EAoIBvSoMm1yY5pP5JVTqRpNUJWLGl
=TIrV
-----END PGP SIGNATURE-----

--=-+lDN6Tt+53N22fQ0SfIZ--



--===============3238306759301684749==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3238306759301684749==--



From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:36:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnhs-0007xY-L7; Tue, 22 Nov 2011 10:36:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSnhr-0007xT-7x
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:36:03 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1321958133!2521484!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27400 invoked from network); 22 Nov 2011 10:35:34 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 10:35:34 -0000
Received: by iaby12 with SMTP id y12so11461679iab.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 02:35:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=zfjqAI2itejYOHAzVu/JMK5y9EW2GKq90HitVOnRYCE=;
	b=qNq+taFOnfa/v1oOAB1tCd+1cz+1Dw2vlHFAulkChxieLsjb7xh8hJNISOGmXcjP8Q
	2kuw4xl+yF4KNGelHNj0I/0V+hty5ciBeHiOmdlpsEf/nWtV02cYtntJQOp+5n4lSvPc
	UG+Xxp8snxml9qYwEoJjJsOqZPVIBKd2zzJL0=
MIME-Version: 1.0
Received: by 10.231.50.202 with SMTP id a10mr4749157ibg.39.1321958132833; Tue,
	22 Nov 2011 02:35:32 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Tue, 22 Nov 2011 02:35:32 -0800 (PST)
In-Reply-To: <1321952996.3664.401.camel@zakaz.uk.xensource.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
Date: Tue, 22 Nov 2011 18:35:32 +0800
Message-ID: <CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 5:09 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Tue, 2011-11-22 at 08:38 +0000, Teck Choon Giam wrote:
>> On Tue, Nov 22, 2011 at 4:31 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> > On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
>> >> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.co=
m> wrote:
>> >> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
>> >> > [...]
>> >> >> memory =3D 15360
>> >> >> maxmem =3D 15360
>> >> > [...]
>> >> >> How much RAM does the host system have? What are your hypervisor a=
nd
>> >> >> > dom0 command lines.
>> >> >>
>> >> >> 16GB RAM.
>> >> >
>> >> > So you are assigning 15GB out of a total of 16GB to the guest which
>> >> > necessitates ballooning dom0 from 16GB down to 1GB.
>> >>
>> >> I actually set dom0-min-mem 512 in xend-config.sxp as well.
>> >
>> > xl/libxl don't use this configuration file.
>>
>> Oh... now then I know. =A0I always test with both xl and xm for my
>> testing machine(s) to see any differences as there are... ...
>
> I believe xend and xl do behave slightly differently wrt dom0 auto
> ballooning.
>
>>
>> >
>> >>
>> >> >
>> >> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
>> >> >> =A0 =A0 =A0 root (hd0,0)
>> >> >> =A0 =A0 =A0 kernel /xen.gz dom0_mem=3D512M loglvl=3Dall guest_logl=
vl=3Dall cpuidle=3D0 cpufreq=3Dnone
>> >> >
>> >> > But you have already forced the dom0_mem to 512M. I suspect this is
>> >> > colluding with the above ballooning to make it look as if dom0 shou=
ld be
>> >> > ballooned to <128M, which causes xl to print a warning message. Per=
haps
>> >> > someone who understands this stuff can comment on whether or not th=
is
>> >> > should be the case.
>> >> >
>> >> > Can you try setting "autoballoon=3D0" in /etc/xl.cfg.
>> >>
>> >> You mean /etc/xen/xl.conf? =A0I have done so and guess what? =A0IT WO=
RKS!!! :)
>> >
>> > Great.
>>
>> That means default value changed if it is unset for autoballoon?
>> Original one is commented with #autoballoon =3D 1 in /etc/xen/xl.conf so
>> it is unset I guess so the default value for autoballoon for c/s 23110
>> is autoballoon=3D0 where c/s 23190 is autoballoon=3D1? =A0Just some
>> guessing... ...
>
> Can you give the full changeset numbers of what you see as 23110 and
> 23190 please, the short numbers are not globally stable and in my
> version that file is identical in both.

Both changeset of that file is the same I believe:

cat xen-4.1-testing.hg/tools/examples/xl.conf
## Global XL config file ##

# automatically balloon down dom0 when xen doesn't have enough free
# memory to create a domain
#autoballoon=3D1

# full path of the lockfile used by xl during domain creation
#lockfile=3D"/var/lock/xl"

# default vif script
#vifscript=3D"vif-bridge"

My previous comment about it is since autoballoon is not set for both
changeset in xl.conf but xl create hvm domain behaves differently
hence guessing of the difference might be related to the default value
of autoballoon (if not set in xl.conf file since it is commented).

> Ian.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:36:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSnhs-0007xY-L7; Tue, 22 Nov 2011 10:36:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSnhr-0007xT-7x
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:36:03 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1321958133!2521484!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27400 invoked from network); 22 Nov 2011 10:35:34 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 10:35:34 -0000
Received: by iaby12 with SMTP id y12so11461679iab.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 02:35:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=zfjqAI2itejYOHAzVu/JMK5y9EW2GKq90HitVOnRYCE=;
	b=qNq+taFOnfa/v1oOAB1tCd+1cz+1Dw2vlHFAulkChxieLsjb7xh8hJNISOGmXcjP8Q
	2kuw4xl+yF4KNGelHNj0I/0V+hty5ciBeHiOmdlpsEf/nWtV02cYtntJQOp+5n4lSvPc
	UG+Xxp8snxml9qYwEoJjJsOqZPVIBKd2zzJL0=
MIME-Version: 1.0
Received: by 10.231.50.202 with SMTP id a10mr4749157ibg.39.1321958132833; Tue,
	22 Nov 2011 02:35:32 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Tue, 22 Nov 2011 02:35:32 -0800 (PST)
In-Reply-To: <1321952996.3664.401.camel@zakaz.uk.xensource.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
Date: Tue, 22 Nov 2011 18:35:32 +0800
Message-ID: <CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 5:09 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Tue, 2011-11-22 at 08:38 +0000, Teck Choon Giam wrote:
>> On Tue, Nov 22, 2011 at 4:31 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> > On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
>> >> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.co=
m> wrote:
>> >> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
>> >> > [...]
>> >> >> memory =3D 15360
>> >> >> maxmem =3D 15360
>> >> > [...]
>> >> >> How much RAM does the host system have? What are your hypervisor a=
nd
>> >> >> > dom0 command lines.
>> >> >>
>> >> >> 16GB RAM.
>> >> >
>> >> > So you are assigning 15GB out of a total of 16GB to the guest which
>> >> > necessitates ballooning dom0 from 16GB down to 1GB.
>> >>
>> >> I actually set dom0-min-mem 512 in xend-config.sxp as well.
>> >
>> > xl/libxl don't use this configuration file.
>>
>> Oh... now then I know. =A0I always test with both xl and xm for my
>> testing machine(s) to see any differences as there are... ...
>
> I believe xend and xl do behave slightly differently wrt dom0 auto
> ballooning.
>
>>
>> >
>> >>
>> >> >
>> >> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
>> >> >> =A0 =A0 =A0 root (hd0,0)
>> >> >> =A0 =A0 =A0 kernel /xen.gz dom0_mem=3D512M loglvl=3Dall guest_logl=
vl=3Dall cpuidle=3D0 cpufreq=3Dnone
>> >> >
>> >> > But you have already forced the dom0_mem to 512M. I suspect this is
>> >> > colluding with the above ballooning to make it look as if dom0 shou=
ld be
>> >> > ballooned to <128M, which causes xl to print a warning message. Per=
haps
>> >> > someone who understands this stuff can comment on whether or not th=
is
>> >> > should be the case.
>> >> >
>> >> > Can you try setting "autoballoon=3D0" in /etc/xl.cfg.
>> >>
>> >> You mean /etc/xen/xl.conf? =A0I have done so and guess what? =A0IT WO=
RKS!!! :)
>> >
>> > Great.
>>
>> That means default value changed if it is unset for autoballoon?
>> Original one is commented with #autoballoon =3D 1 in /etc/xen/xl.conf so
>> it is unset I guess so the default value for autoballoon for c/s 23110
>> is autoballoon=3D0 where c/s 23190 is autoballoon=3D1? =A0Just some
>> guessing... ...
>
> Can you give the full changeset numbers of what you see as 23110 and
> 23190 please, the short numbers are not globally stable and in my
> version that file is identical in both.

Both changeset of that file is the same I believe:

cat xen-4.1-testing.hg/tools/examples/xl.conf
## Global XL config file ##

# automatically balloon down dom0 when xen doesn't have enough free
# memory to create a domain
#autoballoon=3D1

# full path of the lockfile used by xl during domain creation
#lockfile=3D"/var/lock/xl"

# default vif script
#vifscript=3D"vif-bridge"

My previous comment about it is since autoballoon is not set for both
changeset in xl.conf but xl create hvm domain behaves differently
hence guessing of the difference might be related to the default value
of autoballoon (if not set in xl.conf file since it is commented).

> Ian.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:58:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSo39-0008HI-VL; Tue, 22 Nov 2011 10:58:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RSo38-0008HD-Ig
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:58:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321959454!3652016!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30749 invoked from network); 22 Nov 2011 10:57:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 10:57:34 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9060294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 10:57:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 10:57:34 +0000
Date: Tue, 22 Nov 2011 10:58:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111121151359.GA22981@aepfle.de>
Message-ID: <alpine.DEB.2.00.1111221029570.31179@kaball-desktop>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 21 Nov 2011, Olaf Hering wrote:
> On Mon, Nov 21, Stefano Stabellini wrote:
> 
> > what if tot_memkb is bigger than target_memkb? Or even bigger than
> > max_memkb?
> 
> tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> max_memkb.

At build time ballooning is not active yet and target_memkb represents
the amount of memory available to the VM plus the videoram (see
libxl__build_hvm).
As a consequence I think that tot_memkb cannot be higher than
target_memkb - videoram_memkb (that is build_start in the diagram). 

So, what is going to happen if tot_memkb is higher than target_memkb -
videoram_memkb?
Also, what is going to happen if it is lower?


> xenpaging will look at tot_memkb value (at "memory/target-tot_pages" to
> be precise) and try to reach that number of domain->tot_pages. If the
> tot_memkb number is larger than max_memkb nothing will happen.

How is it going to reach the tot_pages target? Where is it going to take
the memory from? Is it going to automatically page out memory from other
VMs?

 
> Right now there is not much checking anyway, memory=1024 maxmem=1 in the
> config is accepted in my testing.
 
That is a correct configuration: it means that the domain has 1024MB of
RAM but it cannot allocate any more (maximum allocation limit being 1MB).
maxmem doesn't influence the current memory of the VM, only future
allocations.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 10:58:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 10:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSo39-0008HI-VL; Tue, 22 Nov 2011 10:58:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RSo38-0008HD-Ig
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:58:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321959454!3652016!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30749 invoked from network); 22 Nov 2011 10:57:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 10:57:34 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9060294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 10:57:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 10:57:34 +0000
Date: Tue, 22 Nov 2011 10:58:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111121151359.GA22981@aepfle.de>
Message-ID: <alpine.DEB.2.00.1111221029570.31179@kaball-desktop>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 21 Nov 2011, Olaf Hering wrote:
> On Mon, Nov 21, Stefano Stabellini wrote:
> 
> > what if tot_memkb is bigger than target_memkb? Or even bigger than
> > max_memkb?
> 
> tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> max_memkb.

At build time ballooning is not active yet and target_memkb represents
the amount of memory available to the VM plus the videoram (see
libxl__build_hvm).
As a consequence I think that tot_memkb cannot be higher than
target_memkb - videoram_memkb (that is build_start in the diagram). 

So, what is going to happen if tot_memkb is higher than target_memkb -
videoram_memkb?
Also, what is going to happen if it is lower?


> xenpaging will look at tot_memkb value (at "memory/target-tot_pages" to
> be precise) and try to reach that number of domain->tot_pages. If the
> tot_memkb number is larger than max_memkb nothing will happen.

How is it going to reach the tot_pages target? Where is it going to take
the memory from? Is it going to automatically page out memory from other
VMs?

 
> Right now there is not much checking anyway, memory=1024 maxmem=1 in the
> config is accepted in my testing.
 
That is a correct configuration: it means that the domain has 1024MB of
RAM but it cannot allocate any more (maximum allocation limit being 1MB).
maxmem doesn't influence the current memory of the VM, only future
allocations.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 11:18:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 11:18:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSoMV-0000Qz-MN; Tue, 22 Nov 2011 11:18:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RSoMU-0000Qs-9w
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 11:18:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321960653!5126530!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18618 invoked from network); 22 Nov 2011 11:17:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 11:17:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9060840"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 11:17:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 11:17:33 +0000
Date: Tue, 22 Nov 2011 11:18:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-196215385-1321960715=:31179"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-196215385-1321960715=:31179
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Tue, 22 Nov 2011, Teck Choon Giam wrote:
> On Tue, Nov 22, 2011 at 5:09 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2011-11-22 at 08:38 +0000, Teck Choon Giam wrote:
> >> On Tue, Nov 22, 2011 at 4:31 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
> >> >> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
> >> >> > [...]
> >> >> >> memory = 15360
> >> >> >> maxmem = 15360
> >> >> > [...]
> >> >> >> How much RAM does the host system have? What are your hypervisor and
> >> >> >> > dom0 command lines.
> >> >> >>
> >> >> >> 16GB RAM.
> >> >> >
> >> >> > So you are assigning 15GB out of a total of 16GB to the guest which
> >> >> > necessitates ballooning dom0 from 16GB down to 1GB.
> >> >>
> >> >> I actually set dom0-min-mem 512 in xend-config.sxp as well.
> >> >
> >> > xl/libxl don't use this configuration file.
> >>
> >> Oh... now then I know.  I always test with both xl and xm for my
> >> testing machine(s) to see any differences as there are... ...
> >
> > I believe xend and xl do behave slightly differently wrt dom0 auto
> > ballooning.
> >
> >>
> >> >
> >> >>
> >> >> >
> >> >> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
> >> >> >>       root (hd0,0)
> >> >> >>       kernel /xen.gz dom0_mem=512M loglvl=all guest_loglvl=all cpuidle=0 cpufreq=none
> >> >> >
> >> >> > But you have already forced the dom0_mem to 512M. I suspect this is
> >> >> > colluding with the above ballooning to make it look as if dom0 should be
> >> >> > ballooned to <128M, which causes xl to print a warning message. Perhaps
> >> >> > someone who understands this stuff can comment on whether or not this
> >> >> > should be the case.
> >> >> >
> >> >> > Can you try setting "autoballoon=0" in /etc/xl.cfg.
> >> >>
> >> >> You mean /etc/xen/xl.conf?  I have done so and guess what?  IT WORKS!!! :)
> >> >
> >> > Great.
> >>
> >> That means default value changed if it is unset for autoballoon?
> >> Original one is commented with #autoballoon = 1 in /etc/xen/xl.conf so
> >> it is unset I guess so the default value for autoballoon for c/s 23110
> >> is autoballoon=0 where c/s 23190 is autoballoon=1?  Just some
> >> guessing... ...

Autoballoon and dom0_mem are incompatible.
I don't think there are any relevant differences between 23110 and 23190
on xen-unstable, maybe you used to start dom0 without dom0_mem before?
--8323329-196215385-1321960715=:31179
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-196215385-1321960715=:31179--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 11:18:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 11:18:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSoMV-0000Qz-MN; Tue, 22 Nov 2011 11:18:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RSoMU-0000Qs-9w
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 11:18:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1321960653!5126530!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18618 invoked from network); 22 Nov 2011 11:17:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 11:17:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'208";a="9060840"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 11:17:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 11:17:33 +0000
Date: Tue, 22 Nov 2011 11:18:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-196215385-1321960715=:31179"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-196215385-1321960715=:31179
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Tue, 22 Nov 2011, Teck Choon Giam wrote:
> On Tue, Nov 22, 2011 at 5:09 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Tue, 2011-11-22 at 08:38 +0000, Teck Choon Giam wrote:
> >> On Tue, Nov 22, 2011 at 4:31 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
> >> >> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> >> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
> >> >> > [...]
> >> >> >> memory = 15360
> >> >> >> maxmem = 15360
> >> >> > [...]
> >> >> >> How much RAM does the host system have? What are your hypervisor and
> >> >> >> > dom0 command lines.
> >> >> >>
> >> >> >> 16GB RAM.
> >> >> >
> >> >> > So you are assigning 15GB out of a total of 16GB to the guest which
> >> >> > necessitates ballooning dom0 from 16GB down to 1GB.
> >> >>
> >> >> I actually set dom0-min-mem 512 in xend-config.sxp as well.
> >> >
> >> > xl/libxl don't use this configuration file.
> >>
> >> Oh... now then I know.  I always test with both xl and xm for my
> >> testing machine(s) to see any differences as there are... ...
> >
> > I believe xend and xl do behave slightly differently wrt dom0 auto
> > ballooning.
> >
> >>
> >> >
> >> >>
> >> >> >
> >> >> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
> >> >> >>       root (hd0,0)
> >> >> >>       kernel /xen.gz dom0_mem=512M loglvl=all guest_loglvl=all cpuidle=0 cpufreq=none
> >> >> >
> >> >> > But you have already forced the dom0_mem to 512M. I suspect this is
> >> >> > colluding with the above ballooning to make it look as if dom0 should be
> >> >> > ballooned to <128M, which causes xl to print a warning message. Perhaps
> >> >> > someone who understands this stuff can comment on whether or not this
> >> >> > should be the case.
> >> >> >
> >> >> > Can you try setting "autoballoon=0" in /etc/xl.cfg.
> >> >>
> >> >> You mean /etc/xen/xl.conf?  I have done so and guess what?  IT WORKS!!! :)
> >> >
> >> > Great.
> >>
> >> That means default value changed if it is unset for autoballoon?
> >> Original one is commented with #autoballoon = 1 in /etc/xen/xl.conf so
> >> it is unset I guess so the default value for autoballoon for c/s 23110
> >> is autoballoon=0 where c/s 23190 is autoballoon=1?  Just some
> >> guessing... ...

Autoballoon and dom0_mem are incompatible.
I don't think there are any relevant differences between 23110 and 23190
on xen-unstable, maybe you used to start dom0 without dom0_mem before?
--8323329-196215385-1321960715=:31179
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-196215385-1321960715=:31179--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 11:23:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 11:23:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSoRi-0000u9-1e; Tue, 22 Nov 2011 11:23:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSoRg-0000tn-QQ
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 11:23:25 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321960975!5251997!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9891 invoked from network); 22 Nov 2011 11:22:56 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 11:22:56 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321960975; l=2425;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=LwDjV2tNX+k65JZMpJ65a/DjfRw=;
	b=YNJYQNkSD030bwRddQnMqJTQKpdpjqW+ZKLsRns5jBom9SQOgx+qE0w+Dm6Lxk1pwoi
	4DGFjL0OOroTcCZ2YkzdvN1+QjzhPPKh8RYwv+qdiozsbpMwOTHC4M3O6DNm9GjcHLrC+
	nhpM78wttcyHBQcayec2cVPzXWlnvE5NLBE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (fruni mo55) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y0743cnAM9QfKJ ;
	Tue, 22 Nov 2011 12:22:48 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 874CC18637; Tue, 22 Nov 2011 12:22:48 +0100 (CET)
Date: Tue, 22 Nov 2011 12:22:48 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111122112248.GA28172@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<alpine.DEB.2.00.1111221029570.31179@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111221029570.31179@kaball-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Stefano Stabellini wrote:

> On Mon, 21 Nov 2011, Olaf Hering wrote:
> > On Mon, Nov 21, Stefano Stabellini wrote:
> > 
> > > what if tot_memkb is bigger than target_memkb? Or even bigger than
> > > max_memkb?
> > 
> > tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> > max_memkb.
> 
> At build time ballooning is not active yet and target_memkb represents
> the amount of memory available to the VM plus the videoram (see
> libxl__build_hvm).
> As a consequence I think that tot_memkb cannot be higher than
> target_memkb - videoram_memkb (that is build_start in the diagram). 

It can because with xenpaging the target_memkb turns from real memory
into virtual memory, and tot_memkb is the new amount of real memory.

The actual checking wether the tot_memkb/target_memkb/max_memkb are sane
can be either done when they are changed with xl mem-XY like its done
now. Or we add new code to do such checking already during config
parsing.

> So, what is going to happen if tot_memkb is higher than target_memkb -
> videoram_memkb?

Nothing happens, since xenpaging is the only consumer of that variable
(via xenstore). See below.

> Also, what is going to happen if it is lower?

If its lower, xenpaging will page-out some pages, adds them back if the
guest happens to access them and page-out some other pages. The guest
still has access to all memory it thinks it has (target_memkb).

> > xenpaging will look at tot_memkb value (at "memory/target-tot_pages" to
> > be precise) and try to reach that number of domain->tot_pages. If the
> > tot_memkb number is larger than max_memkb nothing will happen.
> 
> How is it going to reach the tot_pages target? Where is it going to take
> the memory from? Is it going to automatically page out memory from other
> VMs?

xenpaging does not add new memory. If it has no pages to page-in and
tot_pages is still higher, it will do nothing.

> > Right now there is not much checking anyway, memory=1024 maxmem=1 in the
> > config is accepted in my testing.
>  
> That is a correct configuration: it means that the domain has 1024MB of
> RAM but it cannot allocate any more (maximum allocation limit being 1MB).
> maxmem doesn't influence the current memory of the VM, only future
> allocations.

It causes stall in the host, perhaps due to an interger overflow (I have
not analyzed it yet).

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 11:23:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 11:23:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSoRi-0000u9-1e; Tue, 22 Nov 2011 11:23:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSoRg-0000tn-QQ
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 11:23:25 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321960975!5251997!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9891 invoked from network); 22 Nov 2011 11:22:56 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-8.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 11:22:56 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321960975; l=2425;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=LwDjV2tNX+k65JZMpJ65a/DjfRw=;
	b=YNJYQNkSD030bwRddQnMqJTQKpdpjqW+ZKLsRns5jBom9SQOgx+qE0w+Dm6Lxk1pwoi
	4DGFjL0OOroTcCZ2YkzdvN1+QjzhPPKh8RYwv+qdiozsbpMwOTHC4M3O6DNm9GjcHLrC+
	nhpM78wttcyHBQcayec2cVPzXWlnvE5NLBE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (fruni mo55) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y0743cnAM9QfKJ ;
	Tue, 22 Nov 2011 12:22:48 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 874CC18637; Tue, 22 Nov 2011 12:22:48 +0100 (CET)
Date: Tue, 22 Nov 2011 12:22:48 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111122112248.GA28172@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<alpine.DEB.2.00.1111221029570.31179@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111221029570.31179@kaball-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Stefano Stabellini wrote:

> On Mon, 21 Nov 2011, Olaf Hering wrote:
> > On Mon, Nov 21, Stefano Stabellini wrote:
> > 
> > > what if tot_memkb is bigger than target_memkb? Or even bigger than
> > > max_memkb?
> > 
> > tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> > max_memkb.
> 
> At build time ballooning is not active yet and target_memkb represents
> the amount of memory available to the VM plus the videoram (see
> libxl__build_hvm).
> As a consequence I think that tot_memkb cannot be higher than
> target_memkb - videoram_memkb (that is build_start in the diagram). 

It can because with xenpaging the target_memkb turns from real memory
into virtual memory, and tot_memkb is the new amount of real memory.

The actual checking wether the tot_memkb/target_memkb/max_memkb are sane
can be either done when they are changed with xl mem-XY like its done
now. Or we add new code to do such checking already during config
parsing.

> So, what is going to happen if tot_memkb is higher than target_memkb -
> videoram_memkb?

Nothing happens, since xenpaging is the only consumer of that variable
(via xenstore). See below.

> Also, what is going to happen if it is lower?

If its lower, xenpaging will page-out some pages, adds them back if the
guest happens to access them and page-out some other pages. The guest
still has access to all memory it thinks it has (target_memkb).

> > xenpaging will look at tot_memkb value (at "memory/target-tot_pages" to
> > be precise) and try to reach that number of domain->tot_pages. If the
> > tot_memkb number is larger than max_memkb nothing will happen.
> 
> How is it going to reach the tot_pages target? Where is it going to take
> the memory from? Is it going to automatically page out memory from other
> VMs?

xenpaging does not add new memory. If it has no pages to page-in and
tot_pages is still higher, it will do nothing.

> > Right now there is not much checking anyway, memory=1024 maxmem=1 in the
> > config is accepted in my testing.
>  
> That is a correct configuration: it means that the domain has 1024MB of
> RAM but it cannot allocate any more (maximum allocation limit being 1MB).
> maxmem doesn't influence the current memory of the VM, only future
> allocations.

It causes stall in the host, perhaps due to an interger overflow (I have
not analyzed it yet).

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 11:36:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 11:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSodm-0001FX-Bj; Tue, 22 Nov 2011 11:35:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSodk-0001FS-P3
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 11:35:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1321961723!2531975!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20122 invoked from network); 22 Nov 2011 11:35:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 11:35:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321961723; l=1011;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=EUsIBVBqCRrFvwf+DpT5ouYo7Ew=;
	b=s6FQLp9qDtSd6OTeaEfO7NU7Bc/AuzC944DB5v0pzK3OKlveCn2wsF9/C2xWUeLJIko
	0NYDFhHMcHwRJFD3N+SSy0NZZ1YtAgEyO1lFIVRk99M6CZgVsT+zFLweYPAu9RZnWbyco
	hw/eY2+ZjuhguOVtW4tci5o0nQA9fqFgNHI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (cohen mo44) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j0555fnAMB2OrC
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 12:35:10 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E72AD18637; Tue, 22 Nov 2011 12:35:07 +0100 (CET)
Date: Tue, 22 Nov 2011 12:35:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20111122113507.GA28412@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: [Xen-devel] [PATCH] use ncurses-config to find all curses related
	libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After a split of libtinfo from libncurses in openSuSE Factory the tools
will not link anymore. In the URL below it was suggested to use
'ncurses-config --libs' to find the correct linker options. But
ncurses-config does not exist neither in SLES11 nor in openSuSE. So
check for both ncurses5-config and ncurses-config, if the latter happens
to exist in other environments.

With this change xen-unstable tools build succeeds again in SLES11 and
the latest openSuSE development branch.

http://lists.opensuse.org/opensuse-packaging/2011-11/msg00055.html

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0b1ac7b3ee4d config/StdGNU.mk
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -67,7 +67,7 @@ XEN_CONFIG_DIR = $(CONFIG_DIR)/xen
 XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
-CURSES_LIBS = -lncurses
+CURSES_LIBS = $(shell if ! ncurses5-config --libs 2>/dev/null ; then ncurses-config --libs ; fi)
 PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 11:36:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 11:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSodm-0001FX-Bj; Tue, 22 Nov 2011 11:35:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSodk-0001FS-P3
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 11:35:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1321961723!2531975!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20122 invoked from network); 22 Nov 2011 11:35:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 11:35:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321961723; l=1011;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=EUsIBVBqCRrFvwf+DpT5ouYo7Ew=;
	b=s6FQLp9qDtSd6OTeaEfO7NU7Bc/AuzC944DB5v0pzK3OKlveCn2wsF9/C2xWUeLJIko
	0NYDFhHMcHwRJFD3N+SSy0NZZ1YtAgEyO1lFIVRk99M6CZgVsT+zFLweYPAu9RZnWbyco
	hw/eY2+ZjuhguOVtW4tci5o0nQA9fqFgNHI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (cohen mo44) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j0555fnAMB2OrC
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 12:35:10 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E72AD18637; Tue, 22 Nov 2011 12:35:07 +0100 (CET)
Date: Tue, 22 Nov 2011 12:35:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20111122113507.GA28412@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: [Xen-devel] [PATCH] use ncurses-config to find all curses related
	libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After a split of libtinfo from libncurses in openSuSE Factory the tools
will not link anymore. In the URL below it was suggested to use
'ncurses-config --libs' to find the correct linker options. But
ncurses-config does not exist neither in SLES11 nor in openSuSE. So
check for both ncurses5-config and ncurses-config, if the latter happens
to exist in other environments.

With this change xen-unstable tools build succeeds again in SLES11 and
the latest openSuSE development branch.

http://lists.opensuse.org/opensuse-packaging/2011-11/msg00055.html

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 0b1ac7b3ee4d config/StdGNU.mk
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -67,7 +67,7 @@ XEN_CONFIG_DIR = $(CONFIG_DIR)/xen
 XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
-CURSES_LIBS = -lncurses
+CURSES_LIBS = $(shell if ! ncurses5-config --libs 2>/dev/null ; then ncurses-config --libs ; fi)
 PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 11:41:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 11:41:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSojB-0001Ss-Pv; Tue, 22 Nov 2011 11:41:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSojA-0001Sd-2M
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 11:41:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321962059!3581007!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 576 invoked from network); 22 Nov 2011 11:40:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 11:40:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321962058; l=5643;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Rv8/OGyqvDrAkSfDQdAd3fO2qjA=;
	b=rnePOjIgPUl7YylUfCS2/3kMxcw5IGYKVyGWc0qyfVJYHqynD2eP9oJpZYdVcpvBeIm
	OuxgEm1lE2M8qvks9ZU6YrhXutruskqGhqgmB1Jk26S9KLB3s1Y6Ii0UHzJ34Ylzyj96z
	hPzyFTpipEk1je2ZXdlflB55Hw6daSNB8rA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (klopstock mo43) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Q04ef6nAM9u36z ;
	Tue, 22 Nov 2011 12:40:57 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 47BF518637; Tue, 22 Nov 2011 12:40:57 +0100 (CET)
Date: Tue, 22 Nov 2011 12:40:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111122114057.GA28583@aepfle.de>
References: <20111111225646.GA9332@aepfle.de>
	<CAE3CA1B.24BD2%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE3CA1B.24BD2%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Nov 12, Keir Fraser wrote:

> On 11/11/2011 22:56, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> > Keir,
> > 
> > just do dump my findings to the list:
> > 
> > On Tue, Nov 08, Keir Fraser wrote:
> > 
> >> Tbh I wonder anyway whether stale hypercall context would be likely to cause
> >> a silent machine reboot. Booting with max_cpus=1 would eliminate moving
> >> between CPUs as a cause of inconsistencies, or pin the guest under test.
> >> Another problem could be sleeping with locks held, but we do test for that
> >> (in debug builds at least) and I'd expect crash/hang rather than silent
> >> reboot. Another problem could be if the vcpu has its own state in an
> >> inconsistent/invalid state temporarily (e.g., its pagetable base pointers)
> >> which then is attempted to be restored during a waitqueue wakeup. That could
> >> certainly cause a reboot, but I don't know of an example where this might
> >> happen.
> > 
> > The crashes also happen with maxcpus=1 and a single guest cpu.
> > Today I added wait_event to ept_get_entry and this works.
> > 
> > But at some point the codepath below is executed, after that wake_up the
> > host hangs hard. I will trace it further next week, maybe the backtrace
> > gives a glue what the cause could be.
> 
> So you run with a single CPU, and with wait_event() in one location, and
> that works for a while (actually doing full waitqueue work: executing wait()
> and wake_up()), but then hangs? That's weird, but pretty interesting if I've
> understood correctly.

Yes, thats what happens with single cpu in dom0 and domU.
I have added some more debug. After the backtrace below I see one more
call to check_wakeup_from_wait() for dom0, then the host hangs hard.

> > Also, the 3K stacksize is still too small, this path uses 3096.
> 
> I'll allocate a whole page for the stack then.

Thanks.


Olaf

> > (XEN) prep 127a 30 0
> > (XEN) wake 127a 30
> > (XEN) prep 1cf71 30 0
> > (XEN) wake 1cf71 30
> > (XEN) prep 1cf72 30 0
> > (XEN) wake 1cf72 30
> > (XEN) prep 1cee9 30 0
> > (XEN) wake 1cee9 30
> > (XEN) prep 121a 30 0
> > (XEN) wake 121a 30
> > 
> > (This means 'gfn  (p2m_unshare << 4) in_atomic)'
> > 
> > (XEN) prep 1ee61 20 0
> > (XEN) max stacksize c18
> > (XEN) Xen WARN at wait.c:126
> > (XEN) ----[ Xen-4.2.24114-20111111.221356  x86_64  debug=y  Tainted:    C
> > ]----
> > (XEN) CPU:    0
> > (XEN) RIP:    e008:[<ffff82c48012b85e>] prepare_to_wait+0x178/0x1b2
> > (XEN) RFLAGS: 0000000000010286   CONTEXT: hypervisor
> > (XEN) rax: 0000000000000000   rbx: ffff830201f76000   rcx: 0000000000000000
> > (XEN) rdx: ffff82c4802b7f18   rsi: 000000000000000a   rdi: ffff82c4802673f0
> > (XEN) rbp: ffff82c4802b73a8   rsp: ffff82c4802b7378   r8:  0000000000000000
> > (XEN) r9:  ffff82c480221da0   r10: 00000000fffffffa   r11: 0000000000000003
> > (XEN) r12: ffff82c4802b7f18   r13: ffff830201f76000   r14: ffff83003ea5c000
> > (XEN) r15: 000000000001ee61   cr0: 000000008005003b   cr4: 00000000000026f0
> > (XEN) cr3: 000000020336d000   cr2: 00007fa88ac42000
> > (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> > (XEN) Xen stack trace from rsp=ffff82c4802b7378:
> > (XEN)    0000000000000020 000000000001ee61 0000000000000002 ffff830201aa9e90
> > (XEN)    ffff830201aa9f60 0000000000000020 ffff82c4802b7428 ffff82c4801e02f9
> > (XEN)    ffff830000000002 0000000000000000 ffff82c4802b73f8 ffff82c4802b73f4
> > (XEN)    0000000000000000 ffff82c4802b74e0 ffff82c4802b74e4 0000000101aa9e90
> > (XEN)    000000ffffffffff ffff830201aa9e90 000000000001ee61 ffff82c4802b74e4
> > (XEN)    0000000000000002 0000000000000000 ffff82c4802b7468 ffff82c4801d810f
> > (XEN)    ffff82c4802b74e0 000000000001ee61 ffff830201aa9e90 ffff82c4802b75bc
> > (XEN)    00000000002167f5 ffff88001ee61900 ffff82c4802b7518 ffff82c480211b80
> > (XEN)    ffff8302167f5000 ffff82c4801c168c 0000000000000000 ffff83003ea5c000
> > (XEN)    ffff88001ee61900 0000000001805063 0000000001809063 000000001ee001e3
> > (XEN)    000000001ee61067 00000000002167f5 000000000022ee70 000000000022ed10
> > (XEN)    ffffffffffffffff 0000000a00000007 0000000000000004 ffff82c48025db80
> > (XEN)    ffff83003ea5c000 ffff82c4802b75bc ffff88001ee61900 ffff830201aa9e90
> > (XEN)    ffff82c4802b7528 ffff82c480211cb1 ffff82c4802b7568 ffff82c4801da97f
> > (XEN)    ffff82c4801be053 0000000000000008 ffff82c4802b7b58 ffff88001ee61900
> > (XEN)    0000000000000000 ffff82c4802b78b0 ffff82c4802b75f8 ffff82c4801aaec8
> > (XEN)    0000000000000003 ffff88001ee61900 ffff82c4802b78b0 ffff82c4802b7640
> > (XEN)    ffff83003ea5c000 00000000000000a0 0000000000000900 0000000000000008
> > (XEN)    00000003802b7650 0000000000000004 00000003802b7668 0000000000000000
> > (XEN)    ffff82c4802b7b58 0000000000000001 0000000000000003 ffff82c4802b78b0
> > (XEN) Xen call trace:
> > (XEN)    [<ffff82c48012b85e>] prepare_to_wait+0x178/0x1b2
> > (XEN)    [<ffff82c4801e02f9>] ept_get_entry+0x81/0xd8
> > (XEN)    [<ffff82c4801d810f>] gfn_to_mfn_type_p2m+0x55/0x114
> > (XEN)    [<ffff82c480211b80>] hap_p2m_ga_to_gfn_4_levels+0x1c4/0x2d6
> > (XEN)    [<ffff82c480211cb1>] hap_gva_to_gfn_4_levels+0x1f/0x2e
> > (XEN)    [<ffff82c4801da97f>] paging_gva_to_gfn+0xae/0xc4
> > (XEN)    [<ffff82c4801aaec8>] hvmemul_linear_to_phys+0xf1/0x25c
> > (XEN)    [<ffff82c4801ab762>] hvmemul_rep_movs+0xe8/0x31a
> > (XEN)    [<ffff82c48018de07>] x86_emulate+0x4e01/0x10fde
> > (XEN)    [<ffff82c4801aab3c>] hvm_emulate_one+0x12d/0x1c5
> > (XEN)    [<ffff82c4801b68a9>] handle_mmio+0x4e/0x1d8
> > (XEN)    [<ffff82c4801b3a1e>] hvm_hap_nested_page_fault+0x1e7/0x302
> > (XEN)    [<ffff82c4801d1ff6>] vmx_vmexit_handler+0x12cf/0x1594
> > (XEN)
> > (XEN) wake 1ee61 20
> > 
> > 
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 11:41:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 11:41:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSojB-0001Ss-Pv; Tue, 22 Nov 2011 11:41:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSojA-0001Sd-2M
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 11:41:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1321962059!3581007!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 576 invoked from network); 22 Nov 2011 11:40:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 11:40:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321962058; l=5643;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=Rv8/OGyqvDrAkSfDQdAd3fO2qjA=;
	b=rnePOjIgPUl7YylUfCS2/3kMxcw5IGYKVyGWc0qyfVJYHqynD2eP9oJpZYdVcpvBeIm
	OuxgEm1lE2M8qvks9ZU6YrhXutruskqGhqgmB1Jk26S9KLB3s1Y6Ii0UHzJ34Ylzyj96z
	hPzyFTpipEk1je2ZXdlflB55Hw6daSNB8rA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (klopstock mo43) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Q04ef6nAM9u36z ;
	Tue, 22 Nov 2011 12:40:57 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 47BF518637; Tue, 22 Nov 2011 12:40:57 +0100 (CET)
Date: Tue, 22 Nov 2011 12:40:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111122114057.GA28583@aepfle.de>
References: <20111111225646.GA9332@aepfle.de>
	<CAE3CA1B.24BD2%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE3CA1B.24BD2%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Nov 12, Keir Fraser wrote:

> On 11/11/2011 22:56, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> > Keir,
> > 
> > just do dump my findings to the list:
> > 
> > On Tue, Nov 08, Keir Fraser wrote:
> > 
> >> Tbh I wonder anyway whether stale hypercall context would be likely to cause
> >> a silent machine reboot. Booting with max_cpus=1 would eliminate moving
> >> between CPUs as a cause of inconsistencies, or pin the guest under test.
> >> Another problem could be sleeping with locks held, but we do test for that
> >> (in debug builds at least) and I'd expect crash/hang rather than silent
> >> reboot. Another problem could be if the vcpu has its own state in an
> >> inconsistent/invalid state temporarily (e.g., its pagetable base pointers)
> >> which then is attempted to be restored during a waitqueue wakeup. That could
> >> certainly cause a reboot, but I don't know of an example where this might
> >> happen.
> > 
> > The crashes also happen with maxcpus=1 and a single guest cpu.
> > Today I added wait_event to ept_get_entry and this works.
> > 
> > But at some point the codepath below is executed, after that wake_up the
> > host hangs hard. I will trace it further next week, maybe the backtrace
> > gives a glue what the cause could be.
> 
> So you run with a single CPU, and with wait_event() in one location, and
> that works for a while (actually doing full waitqueue work: executing wait()
> and wake_up()), but then hangs? That's weird, but pretty interesting if I've
> understood correctly.

Yes, thats what happens with single cpu in dom0 and domU.
I have added some more debug. After the backtrace below I see one more
call to check_wakeup_from_wait() for dom0, then the host hangs hard.

> > Also, the 3K stacksize is still too small, this path uses 3096.
> 
> I'll allocate a whole page for the stack then.

Thanks.


Olaf

> > (XEN) prep 127a 30 0
> > (XEN) wake 127a 30
> > (XEN) prep 1cf71 30 0
> > (XEN) wake 1cf71 30
> > (XEN) prep 1cf72 30 0
> > (XEN) wake 1cf72 30
> > (XEN) prep 1cee9 30 0
> > (XEN) wake 1cee9 30
> > (XEN) prep 121a 30 0
> > (XEN) wake 121a 30
> > 
> > (This means 'gfn  (p2m_unshare << 4) in_atomic)'
> > 
> > (XEN) prep 1ee61 20 0
> > (XEN) max stacksize c18
> > (XEN) Xen WARN at wait.c:126
> > (XEN) ----[ Xen-4.2.24114-20111111.221356  x86_64  debug=y  Tainted:    C
> > ]----
> > (XEN) CPU:    0
> > (XEN) RIP:    e008:[<ffff82c48012b85e>] prepare_to_wait+0x178/0x1b2
> > (XEN) RFLAGS: 0000000000010286   CONTEXT: hypervisor
> > (XEN) rax: 0000000000000000   rbx: ffff830201f76000   rcx: 0000000000000000
> > (XEN) rdx: ffff82c4802b7f18   rsi: 000000000000000a   rdi: ffff82c4802673f0
> > (XEN) rbp: ffff82c4802b73a8   rsp: ffff82c4802b7378   r8:  0000000000000000
> > (XEN) r9:  ffff82c480221da0   r10: 00000000fffffffa   r11: 0000000000000003
> > (XEN) r12: ffff82c4802b7f18   r13: ffff830201f76000   r14: ffff83003ea5c000
> > (XEN) r15: 000000000001ee61   cr0: 000000008005003b   cr4: 00000000000026f0
> > (XEN) cr3: 000000020336d000   cr2: 00007fa88ac42000
> > (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> > (XEN) Xen stack trace from rsp=ffff82c4802b7378:
> > (XEN)    0000000000000020 000000000001ee61 0000000000000002 ffff830201aa9e90
> > (XEN)    ffff830201aa9f60 0000000000000020 ffff82c4802b7428 ffff82c4801e02f9
> > (XEN)    ffff830000000002 0000000000000000 ffff82c4802b73f8 ffff82c4802b73f4
> > (XEN)    0000000000000000 ffff82c4802b74e0 ffff82c4802b74e4 0000000101aa9e90
> > (XEN)    000000ffffffffff ffff830201aa9e90 000000000001ee61 ffff82c4802b74e4
> > (XEN)    0000000000000002 0000000000000000 ffff82c4802b7468 ffff82c4801d810f
> > (XEN)    ffff82c4802b74e0 000000000001ee61 ffff830201aa9e90 ffff82c4802b75bc
> > (XEN)    00000000002167f5 ffff88001ee61900 ffff82c4802b7518 ffff82c480211b80
> > (XEN)    ffff8302167f5000 ffff82c4801c168c 0000000000000000 ffff83003ea5c000
> > (XEN)    ffff88001ee61900 0000000001805063 0000000001809063 000000001ee001e3
> > (XEN)    000000001ee61067 00000000002167f5 000000000022ee70 000000000022ed10
> > (XEN)    ffffffffffffffff 0000000a00000007 0000000000000004 ffff82c48025db80
> > (XEN)    ffff83003ea5c000 ffff82c4802b75bc ffff88001ee61900 ffff830201aa9e90
> > (XEN)    ffff82c4802b7528 ffff82c480211cb1 ffff82c4802b7568 ffff82c4801da97f
> > (XEN)    ffff82c4801be053 0000000000000008 ffff82c4802b7b58 ffff88001ee61900
> > (XEN)    0000000000000000 ffff82c4802b78b0 ffff82c4802b75f8 ffff82c4801aaec8
> > (XEN)    0000000000000003 ffff88001ee61900 ffff82c4802b78b0 ffff82c4802b7640
> > (XEN)    ffff83003ea5c000 00000000000000a0 0000000000000900 0000000000000008
> > (XEN)    00000003802b7650 0000000000000004 00000003802b7668 0000000000000000
> > (XEN)    ffff82c4802b7b58 0000000000000001 0000000000000003 ffff82c4802b78b0
> > (XEN) Xen call trace:
> > (XEN)    [<ffff82c48012b85e>] prepare_to_wait+0x178/0x1b2
> > (XEN)    [<ffff82c4801e02f9>] ept_get_entry+0x81/0xd8
> > (XEN)    [<ffff82c4801d810f>] gfn_to_mfn_type_p2m+0x55/0x114
> > (XEN)    [<ffff82c480211b80>] hap_p2m_ga_to_gfn_4_levels+0x1c4/0x2d6
> > (XEN)    [<ffff82c480211cb1>] hap_gva_to_gfn_4_levels+0x1f/0x2e
> > (XEN)    [<ffff82c4801da97f>] paging_gva_to_gfn+0xae/0xc4
> > (XEN)    [<ffff82c4801aaec8>] hvmemul_linear_to_phys+0xf1/0x25c
> > (XEN)    [<ffff82c4801ab762>] hvmemul_rep_movs+0xe8/0x31a
> > (XEN)    [<ffff82c48018de07>] x86_emulate+0x4e01/0x10fde
> > (XEN)    [<ffff82c4801aab3c>] hvm_emulate_one+0x12d/0x1c5
> > (XEN)    [<ffff82c4801b68a9>] handle_mmio+0x4e/0x1d8
> > (XEN)    [<ffff82c4801b3a1e>] hvm_hap_nested_page_fault+0x1e7/0x302
> > (XEN)    [<ffff82c4801d1ff6>] vmx_vmexit_handler+0x12cf/0x1594
> > (XEN)
> > (XEN) wake 1ee61 20
> > 
> > 
> > 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 13:05:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 13:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSq24-0002Mr-Ep; Tue, 22 Nov 2011 13:05:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSq23-0002Mm-7Z
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 13:05:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321967074!5228804!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25704 invoked from network); 22 Nov 2011 13:04:34 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 13:04:34 -0000
Received: by wwp14 with SMTP id 14so244350wwp.24
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 05:04:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=s6LbFPnWovqUvnCGVrXP8N1Em+EZl6/znx2Qi7nxDyo=;
	b=u5hb310FzfR/S+X8oLzzR4YuiT4tuAZffvKP6b4wkt6wisJKk/Qa7QiC9xQ3Y/hPw3
	F0WEqAkMuXYk9tn9Pu9wM//97OsgUwxN5rA8/yxLhCWP1jRjKs8JiJujuIaut8ryLAmU
	dxwrB+/DS+SdVw60cDYF2671gKVCA3ibjftF8=
Received: by 10.227.206.82 with SMTP id ft18mr11955591wbb.21.1321967074295;
	Tue, 22 Nov 2011 05:04:34 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id f18sm6661880wiv.14.2011.11.22.05.04.30
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 05:04:33 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 13:04:25 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF14E59.346B7%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypF0Ji5R3pCR/rvkeQss537WxSjA==
In-Reply-To: <20111122114057.GA28583@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 11:40, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Sat, Nov 12, Keir Fraser wrote:
> 
>> On 11/11/2011 22:56, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>> So you run with a single CPU, and with wait_event() in one location, and
>> that works for a while (actually doing full waitqueue work: executing wait()
>> and wake_up()), but then hangs? That's weird, but pretty interesting if I've
>> understood correctly.
> 
> Yes, thats what happens with single cpu in dom0 and domU.
> I have added some more debug. After the backtrace below I see one more
> call to check_wakeup_from_wait() for dom0, then the host hangs hard.

I think I checked before, but: also unresponsive to serial debug keys?

And dom0 isn't getting put on a waitqueue I assume? Since I guess dom0 is
doing the work to wake things from the waitqueue, that couldn't go well. :-)

>>> Also, the 3K stacksize is still too small, this path uses 3096.
>> 
>> I'll allocate a whole page for the stack then.
> 
> Thanks.

Forgot about it. Done now!

 -- Keir

> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 13:05:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 13:05:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSq24-0002Mr-Ep; Tue, 22 Nov 2011 13:05:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSq23-0002Mm-7Z
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 13:05:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1321967074!5228804!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25704 invoked from network); 22 Nov 2011 13:04:34 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 13:04:34 -0000
Received: by wwp14 with SMTP id 14so244350wwp.24
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 05:04:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=s6LbFPnWovqUvnCGVrXP8N1Em+EZl6/znx2Qi7nxDyo=;
	b=u5hb310FzfR/S+X8oLzzR4YuiT4tuAZffvKP6b4wkt6wisJKk/Qa7QiC9xQ3Y/hPw3
	F0WEqAkMuXYk9tn9Pu9wM//97OsgUwxN5rA8/yxLhCWP1jRjKs8JiJujuIaut8ryLAmU
	dxwrB+/DS+SdVw60cDYF2671gKVCA3ibjftF8=
Received: by 10.227.206.82 with SMTP id ft18mr11955591wbb.21.1321967074295;
	Tue, 22 Nov 2011 05:04:34 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id f18sm6661880wiv.14.2011.11.22.05.04.30
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 05:04:33 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 13:04:25 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF14E59.346B7%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypF0Ji5R3pCR/rvkeQss537WxSjA==
In-Reply-To: <20111122114057.GA28583@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 11:40, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Sat, Nov 12, Keir Fraser wrote:
> 
>> On 11/11/2011 22:56, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>> So you run with a single CPU, and with wait_event() in one location, and
>> that works for a while (actually doing full waitqueue work: executing wait()
>> and wake_up()), but then hangs? That's weird, but pretty interesting if I've
>> understood correctly.
> 
> Yes, thats what happens with single cpu in dom0 and domU.
> I have added some more debug. After the backtrace below I see one more
> call to check_wakeup_from_wait() for dom0, then the host hangs hard.

I think I checked before, but: also unresponsive to serial debug keys?

And dom0 isn't getting put on a waitqueue I assume? Since I guess dom0 is
doing the work to wake things from the waitqueue, that couldn't go well. :-)

>>> Also, the 3K stacksize is still too small, this path uses 3096.
>> 
>> I'll allocate a whole page for the stack then.
> 
> Thanks.

Forgot about it. Done now!

 -- Keir

> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 13:29:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 13:29:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSqPQ-0002dP-Pd; Tue, 22 Nov 2011 13:29:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>)
	id 1RSqPP-0002dF-2j; Tue, 22 Nov 2011 13:29:11 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321968496!45584850!1
X-Originating-IP: [216.33.127.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11985 invoked from network); 22 Nov 2011 13:28:17 -0000
Received: from mta21.charter.net (HELO mta21.charter.net) (216.33.127.81)
	by server-12.tower-27.messagelabs.com with SMTP;
	22 Nov 2011 13:28:17 -0000
Received: from imp10 ([10.20.200.15]) by mta21.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111122132841.FWDP23071.mta21.charter.net@imp10>;
	Tue, 22 Nov 2011 08:28:41 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp10 with smtp.charter.net
	id 0DUg1i00Q46xN4z05DUgnN; Tue, 22 Nov 2011 08:28:41 -0500
X-Authority-Analysis: v=1.1 cv=CKBBFOpPYfBSFfEY1Rl9efxuAv/fdt7oFsWUUq3BrLQ=
	c=1 sm=1 a=0bCt-fb661UA:10 a=VCxxn1A5iYMA:10 a=NqYyV4q_xg0A:10
	a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17
	a=CLmBUu0YAAAA:8 a=lJbt222t43nNLlHmsZEA:9 a=2C0K6jlpVBWZdjzQxmgA:7
	a=QEXdDO2ut3YA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 40263203CD;
	Tue, 22 Nov 2011 13:28:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id LcpWb0DuofGn; Tue, 22 Nov 2011 08:27:58 -0500 (EST)
Received: from www.ark-net.org (unknown [192.168.1.12])
	by mail.ark-net.org (Postfix) with ESMTP id 01F0520394;
	Tue, 22 Nov 2011 08:27:57 -0500 (EST)
MIME-Version: 1.0
Date: Tue, 22 Nov 2011 08:33:01 -0500
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <rshriram@cs.ubc.ca>
Mail-Reply-To: <mike.a.collins@ark-net.org>
In-Reply-To: <CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
	<000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
	<CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
Message-ID: <eddb8c9332cad034094fae78cc1b7549@www.ark-net.org>
X-Sender: mike.a.collins@ark-net.org
User-Agent: Roundcube Webmail/0.6-beta
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: mike.a.collins@ark-net.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMjIuMTEuMjAxMSAwMTo1NiwgU2hyaXJhbSBSYWphZ29wYWxhbiB3cm90ZToKCj4gZWg/IEkg
ZG9udCB0aGluayBzby4gd2l0aCBkcmJkIGJhc2VkIGJhY2tlbmQgZm9yIHhlbiBWTXMgKHdpdGgg
b3IgCj4gd2l0aG91dCByZW11cyksCj4geW91IGp1c3QgdXNlIHRoZSBkcmJkOjxyZXNvdXJjZU5h
bWU+IHN5bnRheCAobXVjaCBsaWtlIHBoeTouLi4pLgo+IEFuZCB0aGVuIHRoZSBibG9jay1kcmJk
IHNjcmlwdCBpbiAvZXRjL3hlbi9zY3JpcHRzLyB0YWtlcyBjYXJlIG9mIHRoZSAKPiByZXN0IG9m
IHRoZSBtYWdpYy4KPiBUaGVyZSBpcyBubyB0YXBkaXNrIGludm9sdmVkIGluIHRoaXMgcHJvY2Vk
dXJlLgoKPiBJbiBlc3NlbmNlLCB0aGUgYmxvY2stZHJiZCBzY3JpcHQganVzdAo+IDEuIHBhcnNl
cyB0aGUgZHJiZDo8cmVzb3VyY2VOYW1lPiBzeW50YXggdG8gZGV0ZXJtaW5lIHdoaWNoIG9uZSBv
Zgo+ICB0aGUgL2Rldi9kcmJkW1hdIGRldmljZXMgYmVsb25nIHRvIHRoZSA8cmVzb3VyY2VOYW1l
PiwKPiAyLiBkb2VzIHNvbWUgc2FuaXR5IGNoZWNrcwo+IDMuIHByb21vdGVzIDxyZXNvdXJjZU5h
bWU+IGluIHRoZSBob3N0IHRvICJQcmltYXJ5IiBhbmQgdGhlbgoKPiB0aGUgcmVzdCBvZiB0aGUg
Y29udHJvbCBmbG93IGhhcHBlbnMgYWtpbiB0byBhIHBoeSBkZXZpY2UsIHdpdGggCj4gL2Rldi9k
cmJkW1hdIGJlaW5nCj4gc3VwcGxpZWQgYXMgdGhlIHBhdGggdG8gdGhlIGRpc2sgYmFja2VuZC4K
Pgo+IFlvdSBjb3VsZCBkbyB0aGlzIG1hbnVhbGx5IHRvbyBpbiB0d28gc2ltcGxlIHN0ZXBzLgo+
ICAxLiBPbiB0aGUgaG9zdCB3aGVyZSB5b3Ugd2FudCB0byBsYXVuY2ggdGhlIFZNLCBwcm9tb3Rl
IHRoZSBkcmJkIAo+IGRpc2sgdG8gUHJpbWFyeQo+ICAoZW5zdXJlIHRoYXQgdGhlIG90aGVyIGVu
ZCBpcyBpbiBzZWNvbmRhcnkgc3RhdGUpCj4gIDIuIGNoYW5nZSB0aGUgVk0ncyBkaXNrIGNvbmZp
ZyB0byAKPiBwaHk6L2Rldi9kcmJkL2J5LXJlcy88cmVzb3VyY2VOYW1lPgo+ICBhbmQgeW91IGFy
ZSBnb29kIHRvIGdvLgo+ICBbVGhvdWdoIHdpdGggcmVtdXMsIHlvdSBsbCBoYXZlIHRvIGhhY2sg
dGhlIAo+IHRvb2xzL3B5dGhvbi94ZW4vcmVtdXMvZGV2aWNlLnB5IHNjcmlwdCB0bwo+ICByZWNv
Z25pemUgdGhlIC9kZXYvZHJiZC8qIFVSSS5dPgoKVGhlIGRyYmQ6PHJlc291cmNlPiBzeW50YXgg
d29ya3MgZm9yIHhtLCBidXQgbm90IGZvciB4bC4gIEknbGwgaGF2ZSB0byAKd29yayBvbiB0aGF0
LiAgQmVsb3cgaXMgd2hhdCB4bCBzcGl0cyBvdXQgdHJ5aW5nIHRvIGNyZWF0ZSB0aGUgZG9tYWlu
LgoKZGMueGw6IGNvbmZpZyBwYXJzaW5nIGVycm9yIGluIGRpc2sgc3BlY2lmaWNhdGlvbjogdW5r
bm93biB2YWx1ZSBmb3IgCmZvcm1hdDogbmVhciBgeHZkYScgaW4gYGRyYmQ6ZGMseHZkYSx3JwoK
PiBXaXRoIGFsbCB0aGF0IHNhaWQgYW5kIGRvbmUsIEnigJltIGN1cnJlbnRseSBydW5uaW5nIGRy
YmQgOC4zLjExIHNpbmNlCj4gdGhhdOKAmXMgdGhlIHZlcnNpb24gb2YgdGhlIGtlcm5lbCBtb2R1
bGUgaW5jbHVkZWQgd2l0aCBMaW51eCAzLjEsIGJ1dAo+IEnigJltIGp1c3QgdXNpbmcgWGVu4oCZ
cyBwaHkgaGFuZGxlciBmb3IgdGhlIGRpc2sgc2VjdGlvbiBvZiBteSBWTeKAmXMKPiBjZmcgZmls
ZS4KPgo+IMKgCj4KPiBJIHNlZSB0aGF0IHRoZXJlIGlzIGEgbmljZSBob3d0byBmb3IgZGViaWFu
IG9uIHJlbXVzaGEud2lraWRvdC5jb20KPiBbNV0sIGJ1dCBhZ2FpbiBpdCB1c2VzIGEgMi42LjMy
IGtlcm5lbCBmcm9tIEplcmVteeKAmXMgZ2l0IHJlcG8sIHdoaWNoCj4gaGFzIHRoZSB0YXAga2Vy
bmVsIG1vZHVsZS7CoCBJIGFnYWluIGFzc2VydCB0aGF0IGN1cnJlbnRseSB0aGVyZSBpcwo+IHZl
cnkgbGl0dGxlIG91dCB0aGVyZSB0aGF0IHdvdWxkIGhlbHAgdG8gZ2V0IHNvbWVvbmUgc3RhcnRl
ZCB1c2luZwo+IHJlbXVzIHdpdGggZHJiZCBpbiB0aGUgbGludXggMy4xLnggd29ybGQuwqAgSSBy
dW4gcmVtdXMgYXQgd29yaywgYnV0Cj4gaXTigJlzIHVzaW5nIHNoYXJlZCBzdG9yYWdlIGFuZCBo
YXZlIG5vIG5lZWQgdG8gdXNlIGl0IHdpdGggZHJiZCwgYnV0Cj4gYXQgaG9tZSBJIGRvbuKAmXQg
cmVhbGx5IHdhbnQgdG8gc2V0IHRoYXQgdXAsIHNvIEkgdGhvdWdodCBkcmJkIHdvdWxkCj4gYmUg
YSBuaWNlIHN0YXJ0Lgo+Cj4gwqAKPgo+IEnigJl2ZSBzdGFydGVkIGRpZmZpbmcgdGhlIDguMy45
IGJyYW5jaCBvZiBkcmJkIHdpdGggeW91ciBjaGFuZ2VzIGZvcgo+IHJlbXVzIGFuZCB3aWxsIHNl
ZSBob3cgaGFyZCBpdCBpcyB0byBnZXQgdGhhdCBpbiB0aGUgOC4zLjExIHZlcnNpb24KPgo+Pgo+
PiBJcyB0aGUgcmVtdXNpZmllZCBkcmJkICg4LjMuOSkgbm90IGNvbXBpbGluZyB1bmRlciB0aGUg
My4xLngga2VybmVsCj4+IGFueW1vcmUgb3IgYXJlIHlvdSBpbnRlcmVzdGVkIGluCj4+IHRoZSBs
YXRlc3QgdmVyc2lvbiBvZiBEUkJEICsgdGhlIHJlbXVzIHN0dWZmID8KPj4gwqAKPj4KPj4gc2hy
aXJhbQoKSSBhbSBpbnRlcmVzdGVkIGluIHJ1bm5pbmcgdGhlIGxhdGVzdCBkcmJkIGNoYW5nZXMg
d2l0aCByZW11cy4gIEJ1dCBJIAphbSBpbnRlcmVzdGVkIGluIGdldHRpbmcgdGhpcyB0byB3b3Jr
IHRocm91Z2ggdGhlIHhsIGludGVyZmFjZSBtb3JlIHRoYW4gCmFueXRoaW5nLgoKCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Nov 22 13:29:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 13:29:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSqPQ-0002dP-Pd; Tue, 22 Nov 2011 13:29:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>)
	id 1RSqPP-0002dF-2j; Tue, 22 Nov 2011 13:29:11 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1321968496!45584850!1
X-Originating-IP: [216.33.127.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11985 invoked from network); 22 Nov 2011 13:28:17 -0000
Received: from mta21.charter.net (HELO mta21.charter.net) (216.33.127.81)
	by server-12.tower-27.messagelabs.com with SMTP;
	22 Nov 2011 13:28:17 -0000
Received: from imp10 ([10.20.200.15]) by mta21.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111122132841.FWDP23071.mta21.charter.net@imp10>;
	Tue, 22 Nov 2011 08:28:41 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp10 with smtp.charter.net
	id 0DUg1i00Q46xN4z05DUgnN; Tue, 22 Nov 2011 08:28:41 -0500
X-Authority-Analysis: v=1.1 cv=CKBBFOpPYfBSFfEY1Rl9efxuAv/fdt7oFsWUUq3BrLQ=
	c=1 sm=1 a=0bCt-fb661UA:10 a=VCxxn1A5iYMA:10 a=NqYyV4q_xg0A:10
	a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:17
	a=CLmBUu0YAAAA:8 a=lJbt222t43nNLlHmsZEA:9 a=2C0K6jlpVBWZdjzQxmgA:7
	a=QEXdDO2ut3YA:10 a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 40263203CD;
	Tue, 22 Nov 2011 13:28:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id LcpWb0DuofGn; Tue, 22 Nov 2011 08:27:58 -0500 (EST)
Received: from www.ark-net.org (unknown [192.168.1.12])
	by mail.ark-net.org (Postfix) with ESMTP id 01F0520394;
	Tue, 22 Nov 2011 08:27:57 -0500 (EST)
MIME-Version: 1.0
Date: Tue, 22 Nov 2011 08:33:01 -0500
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <rshriram@cs.ubc.ca>
Mail-Reply-To: <mike.a.collins@ark-net.org>
In-Reply-To: <CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
	<000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
	<CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
Message-ID: <eddb8c9332cad034094fae78cc1b7549@www.ark-net.org>
X-Sender: mike.a.collins@ark-net.org
User-Agent: Roundcube Webmail/0.6-beta
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: mike.a.collins@ark-net.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMjIuMTEuMjAxMSAwMTo1NiwgU2hyaXJhbSBSYWphZ29wYWxhbiB3cm90ZToKCj4gZWg/IEkg
ZG9udCB0aGluayBzby4gd2l0aCBkcmJkIGJhc2VkIGJhY2tlbmQgZm9yIHhlbiBWTXMgKHdpdGgg
b3IgCj4gd2l0aG91dCByZW11cyksCj4geW91IGp1c3QgdXNlIHRoZSBkcmJkOjxyZXNvdXJjZU5h
bWU+IHN5bnRheCAobXVjaCBsaWtlIHBoeTouLi4pLgo+IEFuZCB0aGVuIHRoZSBibG9jay1kcmJk
IHNjcmlwdCBpbiAvZXRjL3hlbi9zY3JpcHRzLyB0YWtlcyBjYXJlIG9mIHRoZSAKPiByZXN0IG9m
IHRoZSBtYWdpYy4KPiBUaGVyZSBpcyBubyB0YXBkaXNrIGludm9sdmVkIGluIHRoaXMgcHJvY2Vk
dXJlLgoKPiBJbiBlc3NlbmNlLCB0aGUgYmxvY2stZHJiZCBzY3JpcHQganVzdAo+IDEuIHBhcnNl
cyB0aGUgZHJiZDo8cmVzb3VyY2VOYW1lPiBzeW50YXggdG8gZGV0ZXJtaW5lIHdoaWNoIG9uZSBv
Zgo+ICB0aGUgL2Rldi9kcmJkW1hdIGRldmljZXMgYmVsb25nIHRvIHRoZSA8cmVzb3VyY2VOYW1l
PiwKPiAyLiBkb2VzIHNvbWUgc2FuaXR5IGNoZWNrcwo+IDMuIHByb21vdGVzIDxyZXNvdXJjZU5h
bWU+IGluIHRoZSBob3N0IHRvICJQcmltYXJ5IiBhbmQgdGhlbgoKPiB0aGUgcmVzdCBvZiB0aGUg
Y29udHJvbCBmbG93IGhhcHBlbnMgYWtpbiB0byBhIHBoeSBkZXZpY2UsIHdpdGggCj4gL2Rldi9k
cmJkW1hdIGJlaW5nCj4gc3VwcGxpZWQgYXMgdGhlIHBhdGggdG8gdGhlIGRpc2sgYmFja2VuZC4K
Pgo+IFlvdSBjb3VsZCBkbyB0aGlzIG1hbnVhbGx5IHRvbyBpbiB0d28gc2ltcGxlIHN0ZXBzLgo+
ICAxLiBPbiB0aGUgaG9zdCB3aGVyZSB5b3Ugd2FudCB0byBsYXVuY2ggdGhlIFZNLCBwcm9tb3Rl
IHRoZSBkcmJkIAo+IGRpc2sgdG8gUHJpbWFyeQo+ICAoZW5zdXJlIHRoYXQgdGhlIG90aGVyIGVu
ZCBpcyBpbiBzZWNvbmRhcnkgc3RhdGUpCj4gIDIuIGNoYW5nZSB0aGUgVk0ncyBkaXNrIGNvbmZp
ZyB0byAKPiBwaHk6L2Rldi9kcmJkL2J5LXJlcy88cmVzb3VyY2VOYW1lPgo+ICBhbmQgeW91IGFy
ZSBnb29kIHRvIGdvLgo+ICBbVGhvdWdoIHdpdGggcmVtdXMsIHlvdSBsbCBoYXZlIHRvIGhhY2sg
dGhlIAo+IHRvb2xzL3B5dGhvbi94ZW4vcmVtdXMvZGV2aWNlLnB5IHNjcmlwdCB0bwo+ICByZWNv
Z25pemUgdGhlIC9kZXYvZHJiZC8qIFVSSS5dPgoKVGhlIGRyYmQ6PHJlc291cmNlPiBzeW50YXgg
d29ya3MgZm9yIHhtLCBidXQgbm90IGZvciB4bC4gIEknbGwgaGF2ZSB0byAKd29yayBvbiB0aGF0
LiAgQmVsb3cgaXMgd2hhdCB4bCBzcGl0cyBvdXQgdHJ5aW5nIHRvIGNyZWF0ZSB0aGUgZG9tYWlu
LgoKZGMueGw6IGNvbmZpZyBwYXJzaW5nIGVycm9yIGluIGRpc2sgc3BlY2lmaWNhdGlvbjogdW5r
bm93biB2YWx1ZSBmb3IgCmZvcm1hdDogbmVhciBgeHZkYScgaW4gYGRyYmQ6ZGMseHZkYSx3JwoK
PiBXaXRoIGFsbCB0aGF0IHNhaWQgYW5kIGRvbmUsIEnigJltIGN1cnJlbnRseSBydW5uaW5nIGRy
YmQgOC4zLjExIHNpbmNlCj4gdGhhdOKAmXMgdGhlIHZlcnNpb24gb2YgdGhlIGtlcm5lbCBtb2R1
bGUgaW5jbHVkZWQgd2l0aCBMaW51eCAzLjEsIGJ1dAo+IEnigJltIGp1c3QgdXNpbmcgWGVu4oCZ
cyBwaHkgaGFuZGxlciBmb3IgdGhlIGRpc2sgc2VjdGlvbiBvZiBteSBWTeKAmXMKPiBjZmcgZmls
ZS4KPgo+IMKgCj4KPiBJIHNlZSB0aGF0IHRoZXJlIGlzIGEgbmljZSBob3d0byBmb3IgZGViaWFu
IG9uIHJlbXVzaGEud2lraWRvdC5jb20KPiBbNV0sIGJ1dCBhZ2FpbiBpdCB1c2VzIGEgMi42LjMy
IGtlcm5lbCBmcm9tIEplcmVteeKAmXMgZ2l0IHJlcG8sIHdoaWNoCj4gaGFzIHRoZSB0YXAga2Vy
bmVsIG1vZHVsZS7CoCBJIGFnYWluIGFzc2VydCB0aGF0IGN1cnJlbnRseSB0aGVyZSBpcwo+IHZl
cnkgbGl0dGxlIG91dCB0aGVyZSB0aGF0IHdvdWxkIGhlbHAgdG8gZ2V0IHNvbWVvbmUgc3RhcnRl
ZCB1c2luZwo+IHJlbXVzIHdpdGggZHJiZCBpbiB0aGUgbGludXggMy4xLnggd29ybGQuwqAgSSBy
dW4gcmVtdXMgYXQgd29yaywgYnV0Cj4gaXTigJlzIHVzaW5nIHNoYXJlZCBzdG9yYWdlIGFuZCBo
YXZlIG5vIG5lZWQgdG8gdXNlIGl0IHdpdGggZHJiZCwgYnV0Cj4gYXQgaG9tZSBJIGRvbuKAmXQg
cmVhbGx5IHdhbnQgdG8gc2V0IHRoYXQgdXAsIHNvIEkgdGhvdWdodCBkcmJkIHdvdWxkCj4gYmUg
YSBuaWNlIHN0YXJ0Lgo+Cj4gwqAKPgo+IEnigJl2ZSBzdGFydGVkIGRpZmZpbmcgdGhlIDguMy45
IGJyYW5jaCBvZiBkcmJkIHdpdGggeW91ciBjaGFuZ2VzIGZvcgo+IHJlbXVzIGFuZCB3aWxsIHNl
ZSBob3cgaGFyZCBpdCBpcyB0byBnZXQgdGhhdCBpbiB0aGUgOC4zLjExIHZlcnNpb24KPgo+Pgo+
PiBJcyB0aGUgcmVtdXNpZmllZCBkcmJkICg4LjMuOSkgbm90IGNvbXBpbGluZyB1bmRlciB0aGUg
My4xLngga2VybmVsCj4+IGFueW1vcmUgb3IgYXJlIHlvdSBpbnRlcmVzdGVkIGluCj4+IHRoZSBs
YXRlc3QgdmVyc2lvbiBvZiBEUkJEICsgdGhlIHJlbXVzIHN0dWZmID8KPj4gwqAKPj4KPj4gc2hy
aXJhbQoKSSBhbSBpbnRlcmVzdGVkIGluIHJ1bm5pbmcgdGhlIGxhdGVzdCBkcmJkIGNoYW5nZXMg
d2l0aCByZW11cy4gIEJ1dCBJIAphbSBpbnRlcmVzdGVkIGluIGdldHRpbmcgdGhpcyB0byB3b3Jr
IHRocm91Z2ggdGhlIHhsIGludGVyZmFjZSBtb3JlIHRoYW4gCmFueXRoaW5nLgoKCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Nov 22 13:54:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 13:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSqnq-0003gq-Jm; Tue, 22 Nov 2011 13:54:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RSqnp-0003gl-9g
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 13:54:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321970022!46638882!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13504 invoked from network); 22 Nov 2011 13:53:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 13:53:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMDrLo6023532
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 13:53:22 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMDrIqG009096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 13:53:20 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMDr9aj005238; Tue, 22 Nov 2011 07:53:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 05:53:09 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id F3CC340290;
	Tue, 22 Nov 2011 08:46:16 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAMDkClY029744;
	Tue, 22 Nov 2011 08:46:12 -0500
Date: Tue, 22 Nov 2011 08:46:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Message-ID: <20111122134612.GA29668@phenom.dumpdata.com>
References: <1320786914-10541-1-git-send-email-konrad.wilk@oracle.com>
	<1320786914-10541-2-git-send-email-konrad.wilk@oracle.com>
	<4EBA53C5.9040603@linux.vnet.ibm.com>
	<20111109144440.GB8410@phenom.dumpdata.com>
	<4EBD09FF.4030002@linux.vnet.ibm.com>
	<20111115144004.GE22675@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111115144004.GE22675@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4ECBA953.0141,ss=1,re=0.000,fgs=0
Cc: len.brown@intel.com, jeremy@goop.org, xen-devel@lists.xensource.com,
	x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org,
	mingo@redhat.com, bp@alien8.de, hpa@zytor.com, tj@kernel.org,
	tglx@linutronix.de, trenn@suse.de
Subject: Re: [Xen-devel] [PATCH 1/3] cpuidle: If disable_cpuidle() is called,
 set pm_idle to default_idle.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 15, 2011 at 09:40:04AM -0500, Konrad Rzeszutek Wilk wrote:
> > Well I was with a view that if cpuidle is disabled, mwait and arm_e400
> > would take precedence over default_idle. But if is ok to have default_idle instead,
> > then go ahead. 
> > 
> > > Perhaps there is another way do this is:
> > > 
> > > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> > > index becd6d9..04b10a4 100644
> > > --- a/drivers/cpuidle/cpuidle.c
> > > +++ b/drivers/cpuidle/cpuidle.c
> > > @@ -38,6 +38,7 @@ int cpuidle_disabled(void)
> > >  void disable_cpuidle(void)
> > >  {
> > >  	off = 1;
> > > +	pm_idle = default_idle;
> > >  }
> > > 
> > Brining pm_idle pointer back to cpuidle code is going a step back coz
> > we wanted to complete remove using pm_idle going forward. As having 
> > a pointer exported into various files is not a good thing. That's the 
> > reason we started the clean up in the first place :) 
> 
> Perhaps then something along these lines, where we still set default_idle
> but don't fiddle with the pm_idle (and can still rip out the
> EXPORT_SYMBOL_GPL(default_idle) in 2012):
> 
> (Hadn't tested this yet).

Now have tested it.

> 
> diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
> index c2ff2a1..2d2f01c 100644
> --- a/arch/x86/include/asm/system.h
> +++ b/arch/x86/include/asm/system.h
> @@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
>  extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
>  
>  void default_idle(void);
> +bool set_pm_idle_to_default(void);
>  
>  void stop_this_cpu(void *dummy);
>  
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index e7e3b01..bfb113f 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -403,6 +403,14 @@ void default_idle(void)
>  EXPORT_SYMBOL(default_idle);
>  #endif
>  
> +bool set_pm_idle_to_default()
> +{
> +	if (!pm_idle) {
> +		pm_idle = default_idle;
> +		return true;
> +	}
> +	return false;
> +}
>  void stop_this_cpu(void *dummy)
>  {
>  	local_irq_disable();
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 46d6d21..7506181 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
>  #endif
>  	disable_cpuidle();
>  	boot_option_idle_override = IDLE_HALT;
> -
> +	WARN_ON(!set_pm_idle_to_default());
>  	fiddle_vdso();
>  }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 13:54:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 13:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSqnq-0003gq-Jm; Tue, 22 Nov 2011 13:54:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RSqnp-0003gl-9g
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 13:54:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321970022!46638882!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13504 invoked from network); 22 Nov 2011 13:53:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 13:53:43 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMDrLo6023532
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 13:53:22 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMDrIqG009096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 13:53:20 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMDr9aj005238; Tue, 22 Nov 2011 07:53:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 05:53:09 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id F3CC340290;
	Tue, 22 Nov 2011 08:46:16 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAMDkClY029744;
	Tue, 22 Nov 2011 08:46:12 -0500
Date: Tue, 22 Nov 2011 08:46:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
Message-ID: <20111122134612.GA29668@phenom.dumpdata.com>
References: <1320786914-10541-1-git-send-email-konrad.wilk@oracle.com>
	<1320786914-10541-2-git-send-email-konrad.wilk@oracle.com>
	<4EBA53C5.9040603@linux.vnet.ibm.com>
	<20111109144440.GB8410@phenom.dumpdata.com>
	<4EBD09FF.4030002@linux.vnet.ibm.com>
	<20111115144004.GE22675@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111115144004.GE22675@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4ECBA953.0141,ss=1,re=0.000,fgs=0
Cc: len.brown@intel.com, jeremy@goop.org, xen-devel@lists.xensource.com,
	x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org,
	mingo@redhat.com, bp@alien8.de, hpa@zytor.com, tj@kernel.org,
	tglx@linutronix.de, trenn@suse.de
Subject: Re: [Xen-devel] [PATCH 1/3] cpuidle: If disable_cpuidle() is called,
 set pm_idle to default_idle.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 15, 2011 at 09:40:04AM -0500, Konrad Rzeszutek Wilk wrote:
> > Well I was with a view that if cpuidle is disabled, mwait and arm_e400
> > would take precedence over default_idle. But if is ok to have default_idle instead,
> > then go ahead. 
> > 
> > > Perhaps there is another way do this is:
> > > 
> > > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> > > index becd6d9..04b10a4 100644
> > > --- a/drivers/cpuidle/cpuidle.c
> > > +++ b/drivers/cpuidle/cpuidle.c
> > > @@ -38,6 +38,7 @@ int cpuidle_disabled(void)
> > >  void disable_cpuidle(void)
> > >  {
> > >  	off = 1;
> > > +	pm_idle = default_idle;
> > >  }
> > > 
> > Brining pm_idle pointer back to cpuidle code is going a step back coz
> > we wanted to complete remove using pm_idle going forward. As having 
> > a pointer exported into various files is not a good thing. That's the 
> > reason we started the clean up in the first place :) 
> 
> Perhaps then something along these lines, where we still set default_idle
> but don't fiddle with the pm_idle (and can still rip out the
> EXPORT_SYMBOL_GPL(default_idle) in 2012):
> 
> (Hadn't tested this yet).

Now have tested it.

> 
> diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
> index c2ff2a1..2d2f01c 100644
> --- a/arch/x86/include/asm/system.h
> +++ b/arch/x86/include/asm/system.h
> @@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
>  extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
>  
>  void default_idle(void);
> +bool set_pm_idle_to_default(void);
>  
>  void stop_this_cpu(void *dummy);
>  
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index e7e3b01..bfb113f 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -403,6 +403,14 @@ void default_idle(void)
>  EXPORT_SYMBOL(default_idle);
>  #endif
>  
> +bool set_pm_idle_to_default()
> +{
> +	if (!pm_idle) {
> +		pm_idle = default_idle;
> +		return true;
> +	}
> +	return false;
> +}
>  void stop_this_cpu(void *dummy)
>  {
>  	local_irq_disable();
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 46d6d21..7506181 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
>  #endif
>  	disable_cpuidle();
>  	boot_option_idle_override = IDLE_HALT;
> -
> +	WARN_ON(!set_pm_idle_to_default());
>  	fiddle_vdso();
>  }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 13:55:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 13:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSqoO-0003iI-17; Tue, 22 Nov 2011 13:55:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSqoM-0003ht-D8
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 13:54:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1321970069!4473089!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20831 invoked from network); 22 Nov 2011 13:54:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 13:54:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321970069; l=376;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ifKeYLj44/C8MPN8H2fJJyIUQU4=;
	b=Jssa43GiTtC2kTQCq+ivMhcsIJ1BGwh0S3BaCdS6qenoY4CFs2Yolkcv5F9wWfrx80f
	//sbhRnt0tdOW8R6oWChME+PbYHsJ/EkOtEOIz/eMcEYFXIV1YIxaAL+2CRxfPKqUSF3s
	h/wjKDswqH6qQ7xlSo8QrtVA0elksjTwefA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (klopstock mo12) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N03cdcnAMCh6cz ;
	Tue, 22 Nov 2011 14:54:14 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A90F518637; Tue, 22 Nov 2011 14:54:13 +0100 (CET)
Date: Tue, 22 Nov 2011 14:54:13 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir@xen.org>
Message-ID: <20111122135413.GA16364@aepfle.de>
References: <20111122114057.GA28583@aepfle.de>
 <CAF14E59.346B7%keir@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF14E59.346B7%keir@xen.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Keir Fraser wrote:

> I think I checked before, but: also unresponsive to serial debug keys?

Good point, I will check that. So far I havent used these keys.

> Forgot about it. Done now!

What about domain_crash() instead of BUG_ON() in __prepare_to_wait()?
If the stacksize would be checked before its copied the hypervisor could
survive.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 13:55:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 13:55:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSqoO-0003iI-17; Tue, 22 Nov 2011 13:55:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSqoM-0003ht-D8
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 13:54:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1321970069!4473089!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20831 invoked from network); 22 Nov 2011 13:54:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 13:54:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321970069; l=376;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ifKeYLj44/C8MPN8H2fJJyIUQU4=;
	b=Jssa43GiTtC2kTQCq+ivMhcsIJ1BGwh0S3BaCdS6qenoY4CFs2Yolkcv5F9wWfrx80f
	//sbhRnt0tdOW8R6oWChME+PbYHsJ/EkOtEOIz/eMcEYFXIV1YIxaAL+2CRxfPKqUSF3s
	h/wjKDswqH6qQ7xlSo8QrtVA0elksjTwefA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (klopstock mo12) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N03cdcnAMCh6cz ;
	Tue, 22 Nov 2011 14:54:14 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A90F518637; Tue, 22 Nov 2011 14:54:13 +0100 (CET)
Date: Tue, 22 Nov 2011 14:54:13 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir@xen.org>
Message-ID: <20111122135413.GA16364@aepfle.de>
References: <20111122114057.GA28583@aepfle.de>
 <CAF14E59.346B7%keir@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF14E59.346B7%keir@xen.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Keir Fraser wrote:

> I think I checked before, but: also unresponsive to serial debug keys?

Good point, I will check that. So far I havent used these keys.

> Forgot about it. Done now!

What about domain_crash() instead of BUG_ON() in __prepare_to_wait()?
If the stacksize would be checked before its copied the hypervisor could
survive.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 14:25:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 14:25:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSrHe-0004AD-Mf; Tue, 22 Nov 2011 14:25:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSrHd-0004A7-K1
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 14:25:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321971884!4163600!1
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32488 invoked from network); 22 Nov 2011 14:24:44 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 14:24:44 -0000
Received: by eyb6 with SMTP id 6so306095eyb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 06:24:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=zMj5lehgmrh1SeyF9/OEV7QmIOww3yUvNliClxOijNA=;
	b=jiK2FOFGXlEFUniqXTC/ANkxPKwjlEvHbKyq5OE9a907JbBJGuw/ZoPE1lcmEDOdnp
	tXP5lIzYe3HP9TQtV/SIlZFuKjC+iVWj6o0m4BUfNSvjEqqyON3WYdTketG67FHuGvGe
	J1dfoeaIBr2Y3JJtg6VD92Dts6kXepLLP3EN8=
Received: by 10.180.77.42 with SMTP id p10mr19194950wiw.66.1321971884449;
	Tue, 22 Nov 2011 06:24:44 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id fq9sm12244241wbb.5.2011.11.22.06.24.42
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 06:24:43 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 14:24:32 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF16122.346C0%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypInOUm7ng835ms0WqMzrmg9W5CQ==
In-Reply-To: <20111122135413.GA16364@aepfle.de>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3404816682_118765095"
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3404816682_118765095
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 22/11/2011 13:54, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Keir Fraser wrote:
> 
>> I think I checked before, but: also unresponsive to serial debug keys?
> 
> Good point, I will check that. So far I havent used these keys.

If they work then 'd' will give you a backtrace on every CPU, and 'q' will
dump domain and vcpu states. That should make things easier!

>> Forgot about it. Done now!
> 
> What about domain_crash() instead of BUG_ON() in __prepare_to_wait()?
> If the stacksize would be checked before its copied the hypervisor could
> survive.

Try the attached patch (please also try reducing the size of the new
parameter to the inline asm from PAGE_SIZE down to e.g. 2000 to force the
domain-crashing path).

 -- Keir

> Olaf


--B_3404816682_118765095
Content-type: application/octet-stream; name="00-prep-to-wait-dom-crash"
Content-disposition: attachment;
	filename="00-prep-to-wait-dom-crash"
Content-transfer-encoding: base64


ZGlmZiAtciBkMzg1OWUzNDg5NTEgeGVuL2NvbW1vbi93YWl0LmMKLS0tIGEveGVuL2NvbW1v
bi93YWl0LmMJVHVlIE5vdiAyMiAxMzoyOTo0OCAyMDExICswMDAwCisrKyBiL3hlbi9jb21t
b24vd2FpdC5jCVR1ZSBOb3YgMjIgMTQ6MjE6NDIgMjAxMSArMDAwMApAQCAtMTA2LDEzICsx
MDYsMTYgQEAgdm9pZCB3YWtlX3VwKHN0cnVjdCB3YWl0cXVldWVfaGVhZCAqd3EpCiBzdGF0
aWMgdm9pZCBfX3ByZXBhcmVfdG9fd2FpdChzdHJ1Y3Qgd2FpdHF1ZXVlX3ZjcHUgKndxdikK
IHsKICAgICBjaGFyICpjcHVfaW5mbyA9IChjaGFyICopZ2V0X2NwdV9pbmZvKCk7CisKICAg
ICBhc20gdm9sYXRpbGUgKAogI2lmZGVmIENPTkZJR19YODZfNjQKICAgICAgICAgInB1c2gg
JSVyYXg7IHB1c2ggJSVyYng7IHB1c2ggJSVyY3g7IHB1c2ggJSVyZHg7IHB1c2ggJSVyZGk7
ICIKICAgICAgICAgInB1c2ggJSVyYnA7IHB1c2ggJSVyODsgcHVzaCAlJXI5OyBwdXNoICUl
cjEwOyBwdXNoICUlcjExOyAiCiAgICAgICAgICJwdXNoICUlcjEyOyBwdXNoICUlcjEzOyBw
dXNoICUlcjE0OyBwdXNoICUlcjE1OyBjYWxsIDFmOyAiCiAgICAgICAgICIxOiBtb3YgODAo
JSVyc3ApLCUlcmRpOyBtb3YgOTYoJSVyc3ApLCUlcmN4OyBtb3YgJSVyc3AsJSVyc2k7ICIK
LSAgICAgICAgInN1YiAlJXJzaSwlJXJjeDsgcmVwIG1vdnNiOyBtb3YgJSVyc3AsJSVyc2k7
IHBvcCAlJXJheDsgIgorICAgICAgICAic3ViICUlcnNpLCUlcmN4OyBjbXAgJTMsJSVyY3g7
IGphIDJmOyAiCisgICAgICAgICJ4b3IgJSVlc2ksJSVlc2k7IGptcCAzZjsgIgorICAgICAg
ICAiMjogcmVwIG1vdnNiOyBtb3YgJSVyc3AsJSVyc2k7IDM6IHBvcCAlJXJheDsgIgogICAg
ICAgICAicG9wICUlcjE1OyBwb3AgJSVyMTQ7IHBvcCAlJXIxMzsgcG9wICUlcjEyOyAiCiAg
ICAgICAgICJwb3AgJSVyMTE7IHBvcCAlJXIxMDsgcG9wICUlcjk7IHBvcCAlJXI4OyAiCiAg
ICAgICAgICJwb3AgJSVyYnA7IHBvcCAlJXJkaTsgcG9wICUlcmR4OyBwb3AgJSVyY3g7IHBv
cCAlJXJieDsgcG9wICUlcmF4IgpAQCAtMTIwLDEzICsxMjMsMjAgQEAgc3RhdGljIHZvaWQg
X19wcmVwYXJlX3RvX3dhaXQoc3RydWN0IHdhaQogICAgICAgICAicHVzaCAlJWVheDsgcHVz
aCAlJWVieDsgcHVzaCAlJWVjeDsgcHVzaCAlJWVkeDsgcHVzaCAlJWVkaTsgIgogICAgICAg
ICAicHVzaCAlJWVicDsgY2FsbCAxZjsgIgogICAgICAgICAiMTogbW92IDgoJSVlc3ApLCUl
ZWRpOyBtb3YgMTYoJSVlc3ApLCUlZWN4OyBtb3YgJSVlc3AsJSVlc2k7ICIKLSAgICAgICAg
InN1YiAlJWVzaSwlJWVjeDsgcmVwIG1vdnNiOyBtb3YgJSVlc3AsJSVlc2k7IHBvcCAlJWVh
eDsgIgorICAgICAgICAic3ViICUlZXNpLCUlZWN4OyBjbXAgJTMsJSVlY3g7IGphIDJmOyAi
CisgICAgICAgICJ4b3IgJSVlc2ksJSVlc2k7IGptcCAzZjsgIgorICAgICAgICAiMjogcmVw
IG1vdnNiOyBtb3YgJSVlc3AsJSVlc2k7IDM6IHBvcCAlJWVheDsgIgogICAgICAgICAicG9w
ICUlZWJwOyBwb3AgJSVlZGk7IHBvcCAlJWVkeDsgcG9wICUlZWN4OyBwb3AgJSVlYng7IHBv
cCAlJWVheCIKICNlbmRpZgogICAgICAgICA6ICI9UyIgKHdxdi0+ZXNwKQotICAgICAgICA6
ICJjIiAoY3B1X2luZm8pLCAiRCIgKHdxdi0+c3RhY2spCisgICAgICAgIDogImMiIChjcHVf
aW5mbyksICJEIiAod3F2LT5zdGFjayksICJpIiAoUEFHRV9TSVpFKQogICAgICAgICA6ICJt
ZW1vcnkiICk7Ci0gICAgQlVHX09OKChjcHVfaW5mbyAtIChjaGFyICopd3F2LT5lc3ApID4g
UEFHRV9TSVpFKTsKKworICAgIGlmICggdW5saWtlbHkod3F2LT5lc3AgPT0gMCkgKQorICAg
IHsKKyAgICAgICAgZ2RwcmludGsoWEVOTE9HX0VSUiwgIlN0YWNrIHRvbyBsYXJnZSBpbiAl
c1xuIiwgX19GVU5DVElPTl9fKTsKKyAgICAgICAgZG9tYWluX2NyYXNoX3N5bmNocm9ub3Vz
KCk7CisgICAgfQogfQogCiBzdGF0aWMgdm9pZCBfX2ZpbmlzaF93YWl0KHN0cnVjdCB3YWl0
cXVldWVfdmNwdSAqd3F2KQpAQCAtMTYyLDYgKzE3Miw3IEBAIHZvaWQgcHJlcGFyZV90b193
YWl0KHN0cnVjdCB3YWl0cXVldWVfaGUKICAgICBzdHJ1Y3QgdmNwdSAqY3VyciA9IGN1cnJl
bnQ7CiAgICAgc3RydWN0IHdhaXRxdWV1ZV92Y3B1ICp3cXYgPSBjdXJyLT53YWl0cXVldWVf
dmNwdTsKIAorICAgIEFTU0VSVCghaW5fYXRvbWljKCkpOwogICAgIEFTU0VSVChsaXN0X2Vt
cHR5KCZ3cXYtPmxpc3QpKTsKIAogICAgIHNwaW5fbG9jaygmd3EtPmxvY2spOwo=
--B_3404816682_118765095
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--B_3404816682_118765095--




From xen-devel-bounces@lists.xensource.com Tue Nov 22 14:25:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 14:25:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSrHe-0004AD-Mf; Tue, 22 Nov 2011 14:25:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSrHd-0004A7-K1
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 14:25:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1321971884!4163600!1
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32488 invoked from network); 22 Nov 2011 14:24:44 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 14:24:44 -0000
Received: by eyb6 with SMTP id 6so306095eyb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 06:24:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=zMj5lehgmrh1SeyF9/OEV7QmIOww3yUvNliClxOijNA=;
	b=jiK2FOFGXlEFUniqXTC/ANkxPKwjlEvHbKyq5OE9a907JbBJGuw/ZoPE1lcmEDOdnp
	tXP5lIzYe3HP9TQtV/SIlZFuKjC+iVWj6o0m4BUfNSvjEqqyON3WYdTketG67FHuGvGe
	J1dfoeaIBr2Y3JJtg6VD92Dts6kXepLLP3EN8=
Received: by 10.180.77.42 with SMTP id p10mr19194950wiw.66.1321971884449;
	Tue, 22 Nov 2011 06:24:44 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id fq9sm12244241wbb.5.2011.11.22.06.24.42
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 06:24:43 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 14:24:32 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF16122.346C0%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypInOUm7ng835ms0WqMzrmg9W5CQ==
In-Reply-To: <20111122135413.GA16364@aepfle.de>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3404816682_118765095"
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3404816682_118765095
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 22/11/2011 13:54, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Keir Fraser wrote:
> 
>> I think I checked before, but: also unresponsive to serial debug keys?
> 
> Good point, I will check that. So far I havent used these keys.

If they work then 'd' will give you a backtrace on every CPU, and 'q' will
dump domain and vcpu states. That should make things easier!

>> Forgot about it. Done now!
> 
> What about domain_crash() instead of BUG_ON() in __prepare_to_wait()?
> If the stacksize would be checked before its copied the hypervisor could
> survive.

Try the attached patch (please also try reducing the size of the new
parameter to the inline asm from PAGE_SIZE down to e.g. 2000 to force the
domain-crashing path).

 -- Keir

> Olaf


--B_3404816682_118765095
Content-type: application/octet-stream; name="00-prep-to-wait-dom-crash"
Content-disposition: attachment;
	filename="00-prep-to-wait-dom-crash"
Content-transfer-encoding: base64


ZGlmZiAtciBkMzg1OWUzNDg5NTEgeGVuL2NvbW1vbi93YWl0LmMKLS0tIGEveGVuL2NvbW1v
bi93YWl0LmMJVHVlIE5vdiAyMiAxMzoyOTo0OCAyMDExICswMDAwCisrKyBiL3hlbi9jb21t
b24vd2FpdC5jCVR1ZSBOb3YgMjIgMTQ6MjE6NDIgMjAxMSArMDAwMApAQCAtMTA2LDEzICsx
MDYsMTYgQEAgdm9pZCB3YWtlX3VwKHN0cnVjdCB3YWl0cXVldWVfaGVhZCAqd3EpCiBzdGF0
aWMgdm9pZCBfX3ByZXBhcmVfdG9fd2FpdChzdHJ1Y3Qgd2FpdHF1ZXVlX3ZjcHUgKndxdikK
IHsKICAgICBjaGFyICpjcHVfaW5mbyA9IChjaGFyICopZ2V0X2NwdV9pbmZvKCk7CisKICAg
ICBhc20gdm9sYXRpbGUgKAogI2lmZGVmIENPTkZJR19YODZfNjQKICAgICAgICAgInB1c2gg
JSVyYXg7IHB1c2ggJSVyYng7IHB1c2ggJSVyY3g7IHB1c2ggJSVyZHg7IHB1c2ggJSVyZGk7
ICIKICAgICAgICAgInB1c2ggJSVyYnA7IHB1c2ggJSVyODsgcHVzaCAlJXI5OyBwdXNoICUl
cjEwOyBwdXNoICUlcjExOyAiCiAgICAgICAgICJwdXNoICUlcjEyOyBwdXNoICUlcjEzOyBw
dXNoICUlcjE0OyBwdXNoICUlcjE1OyBjYWxsIDFmOyAiCiAgICAgICAgICIxOiBtb3YgODAo
JSVyc3ApLCUlcmRpOyBtb3YgOTYoJSVyc3ApLCUlcmN4OyBtb3YgJSVyc3AsJSVyc2k7ICIK
LSAgICAgICAgInN1YiAlJXJzaSwlJXJjeDsgcmVwIG1vdnNiOyBtb3YgJSVyc3AsJSVyc2k7
IHBvcCAlJXJheDsgIgorICAgICAgICAic3ViICUlcnNpLCUlcmN4OyBjbXAgJTMsJSVyY3g7
IGphIDJmOyAiCisgICAgICAgICJ4b3IgJSVlc2ksJSVlc2k7IGptcCAzZjsgIgorICAgICAg
ICAiMjogcmVwIG1vdnNiOyBtb3YgJSVyc3AsJSVyc2k7IDM6IHBvcCAlJXJheDsgIgogICAg
ICAgICAicG9wICUlcjE1OyBwb3AgJSVyMTQ7IHBvcCAlJXIxMzsgcG9wICUlcjEyOyAiCiAg
ICAgICAgICJwb3AgJSVyMTE7IHBvcCAlJXIxMDsgcG9wICUlcjk7IHBvcCAlJXI4OyAiCiAg
ICAgICAgICJwb3AgJSVyYnA7IHBvcCAlJXJkaTsgcG9wICUlcmR4OyBwb3AgJSVyY3g7IHBv
cCAlJXJieDsgcG9wICUlcmF4IgpAQCAtMTIwLDEzICsxMjMsMjAgQEAgc3RhdGljIHZvaWQg
X19wcmVwYXJlX3RvX3dhaXQoc3RydWN0IHdhaQogICAgICAgICAicHVzaCAlJWVheDsgcHVz
aCAlJWVieDsgcHVzaCAlJWVjeDsgcHVzaCAlJWVkeDsgcHVzaCAlJWVkaTsgIgogICAgICAg
ICAicHVzaCAlJWVicDsgY2FsbCAxZjsgIgogICAgICAgICAiMTogbW92IDgoJSVlc3ApLCUl
ZWRpOyBtb3YgMTYoJSVlc3ApLCUlZWN4OyBtb3YgJSVlc3AsJSVlc2k7ICIKLSAgICAgICAg
InN1YiAlJWVzaSwlJWVjeDsgcmVwIG1vdnNiOyBtb3YgJSVlc3AsJSVlc2k7IHBvcCAlJWVh
eDsgIgorICAgICAgICAic3ViICUlZXNpLCUlZWN4OyBjbXAgJTMsJSVlY3g7IGphIDJmOyAi
CisgICAgICAgICJ4b3IgJSVlc2ksJSVlc2k7IGptcCAzZjsgIgorICAgICAgICAiMjogcmVw
IG1vdnNiOyBtb3YgJSVlc3AsJSVlc2k7IDM6IHBvcCAlJWVheDsgIgogICAgICAgICAicG9w
ICUlZWJwOyBwb3AgJSVlZGk7IHBvcCAlJWVkeDsgcG9wICUlZWN4OyBwb3AgJSVlYng7IHBv
cCAlJWVheCIKICNlbmRpZgogICAgICAgICA6ICI9UyIgKHdxdi0+ZXNwKQotICAgICAgICA6
ICJjIiAoY3B1X2luZm8pLCAiRCIgKHdxdi0+c3RhY2spCisgICAgICAgIDogImMiIChjcHVf
aW5mbyksICJEIiAod3F2LT5zdGFjayksICJpIiAoUEFHRV9TSVpFKQogICAgICAgICA6ICJt
ZW1vcnkiICk7Ci0gICAgQlVHX09OKChjcHVfaW5mbyAtIChjaGFyICopd3F2LT5lc3ApID4g
UEFHRV9TSVpFKTsKKworICAgIGlmICggdW5saWtlbHkod3F2LT5lc3AgPT0gMCkgKQorICAg
IHsKKyAgICAgICAgZ2RwcmludGsoWEVOTE9HX0VSUiwgIlN0YWNrIHRvbyBsYXJnZSBpbiAl
c1xuIiwgX19GVU5DVElPTl9fKTsKKyAgICAgICAgZG9tYWluX2NyYXNoX3N5bmNocm9ub3Vz
KCk7CisgICAgfQogfQogCiBzdGF0aWMgdm9pZCBfX2ZpbmlzaF93YWl0KHN0cnVjdCB3YWl0
cXVldWVfdmNwdSAqd3F2KQpAQCAtMTYyLDYgKzE3Miw3IEBAIHZvaWQgcHJlcGFyZV90b193
YWl0KHN0cnVjdCB3YWl0cXVldWVfaGUKICAgICBzdHJ1Y3QgdmNwdSAqY3VyciA9IGN1cnJl
bnQ7CiAgICAgc3RydWN0IHdhaXRxdWV1ZV92Y3B1ICp3cXYgPSBjdXJyLT53YWl0cXVldWVf
dmNwdTsKIAorICAgIEFTU0VSVCghaW5fYXRvbWljKCkpOwogICAgIEFTU0VSVChsaXN0X2Vt
cHR5KCZ3cXYtPmxpc3QpKTsKIAogICAgIHNwaW5fbG9jaygmd3EtPmxvY2spOwo=
--B_3404816682_118765095
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--B_3404816682_118765095--




From xen-devel-bounces@lists.xensource.com Tue Nov 22 14:35:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 14:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSrRI-0005Ox-B3; Tue, 22 Nov 2011 14:35:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RSrRH-0005Om-Mp
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 14:35:11 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321972481!5286788!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2195 invoked from network); 22 Nov 2011 14:34:42 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 14:34:42 -0000
Received: by ywn1 with SMTP id 1so313397ywn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 06:34:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=SroR35VI8xCUC8zkFiyeH6eOqFLEt+tOZLLU4RfbEkc=;
	b=Y3Q+BaqJs6v/QXYW8ET1aE55rGCq0nDUGxlJg/3BU3Ops6jn+JxA5YmO/mlwDLSuai
	s6boSq0nJFyKLjNtWBAvisGOV1Njmx6gPBzwYLaTjXcS/JvncZG76OUWYK9aqkV3dp81
	GKjLhJvX+I84ukKQ1C2nYsubBbz5DgggxSkDE=
MIME-Version: 1.0
Received: by 10.50.216.167 with SMTP id or7mr21790244igc.22.1321972481438;
	Tue, 22 Nov 2011 06:34:41 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Tue, 22 Nov 2011 06:34:41 -0800 (PST)
In-Reply-To: <7e96f2129a4c9ecbd10073c9c0f6da48.squirrel@webmail.lagarcavilla.org>
References: <20111108224414.83985CF73A@homiemail-mx7.g.dreamhost.com>
	<3c097da8e49a42af1210e4ffcd39fd48.squirrel@webmail.lagarcavilla.org>
	<20111109070927.GB26154@aepfle.de>
	<7e96f2129a4c9ecbd10073c9c0f6da48.squirrel@webmail.lagarcavilla.org>
Date: Tue, 22 Nov 2011 14:34:41 +0000
X-Google-Sender-Auth: NLJguXukVs-O1UyNNV0BJHqsbdk
Message-ID: <CAFLBxZZ=j-ft9J-1UmKGBJBoQYuku2xMLGZuM2Rm9DaNh8yOcQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: andres@lagarcavilla.org
Cc: Olaf Hering <olaf@aepfle.de>, keir.xen@gmail.com,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 9, 2011 at 9:21 PM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
> PoD also does emergency sweeps under memory pressure to identify zeroes,
> that can be easily implemented by a user-space utility.

PoD is certainly a special-case, hypervisor-handled version of paging.
 The main question is whether a user-space version can be made to
perform well enough.  My guess is that it can, but it's far from
certain.  If it can, I'm all in favor of making the paging handle PoD.

> The hypervisor code keeps a list of 2M superpages -- that feature would be
> lost.

This is actually pretty important; Windows scrubs memory on boot, so
it's guaranteed that the majority of the memory will be touched and
re-populated.

> But I doubt this would fly anyways: PoD works for non-ept modes, which I
> guess don't want to lose that functionality.

Is there a particular reason we can't do paging on shadow code? I
thought it was just that doing HAP was simpler to get started with.
That would be another blocker to getting rid of PoD, really.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 14:35:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 14:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSrRI-0005Ox-B3; Tue, 22 Nov 2011 14:35:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RSrRH-0005Om-Mp
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 14:35:11 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321972481!5286788!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2195 invoked from network); 22 Nov 2011 14:34:42 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 14:34:42 -0000
Received: by ywn1 with SMTP id 1so313397ywn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 06:34:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=SroR35VI8xCUC8zkFiyeH6eOqFLEt+tOZLLU4RfbEkc=;
	b=Y3Q+BaqJs6v/QXYW8ET1aE55rGCq0nDUGxlJg/3BU3Ops6jn+JxA5YmO/mlwDLSuai
	s6boSq0nJFyKLjNtWBAvisGOV1Njmx6gPBzwYLaTjXcS/JvncZG76OUWYK9aqkV3dp81
	GKjLhJvX+I84ukKQ1C2nYsubBbz5DgggxSkDE=
MIME-Version: 1.0
Received: by 10.50.216.167 with SMTP id or7mr21790244igc.22.1321972481438;
	Tue, 22 Nov 2011 06:34:41 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Tue, 22 Nov 2011 06:34:41 -0800 (PST)
In-Reply-To: <7e96f2129a4c9ecbd10073c9c0f6da48.squirrel@webmail.lagarcavilla.org>
References: <20111108224414.83985CF73A@homiemail-mx7.g.dreamhost.com>
	<3c097da8e49a42af1210e4ffcd39fd48.squirrel@webmail.lagarcavilla.org>
	<20111109070927.GB26154@aepfle.de>
	<7e96f2129a4c9ecbd10073c9c0f6da48.squirrel@webmail.lagarcavilla.org>
Date: Tue, 22 Nov 2011 14:34:41 +0000
X-Google-Sender-Auth: NLJguXukVs-O1UyNNV0BJHqsbdk
Message-ID: <CAFLBxZZ=j-ft9J-1UmKGBJBoQYuku2xMLGZuM2Rm9DaNh8yOcQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: andres@lagarcavilla.org
Cc: Olaf Hering <olaf@aepfle.de>, keir.xen@gmail.com,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 9, 2011 at 9:21 PM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
> PoD also does emergency sweeps under memory pressure to identify zeroes,
> that can be easily implemented by a user-space utility.

PoD is certainly a special-case, hypervisor-handled version of paging.
 The main question is whether a user-space version can be made to
perform well enough.  My guess is that it can, but it's far from
certain.  If it can, I'm all in favor of making the paging handle PoD.

> The hypervisor code keeps a list of 2M superpages -- that feature would be
> lost.

This is actually pretty important; Windows scrubs memory on boot, so
it's guaranteed that the majority of the memory will be touched and
re-populated.

> But I doubt this would fly anyways: PoD works for non-ept modes, which I
> guess don't want to lose that functionality.

Is there a particular reason we can't do paging on shadow code? I
thought it was just that doing HAP was simpler to get started with.
That would be another blocker to getting rid of PoD, really.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:27:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:27:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsFm-00079V-DL; Tue, 22 Nov 2011 15:27:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSsFl-00079O-6A
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:27:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321975494!45354759!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7465 invoked from network); 22 Nov 2011 15:24:55 -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;
	22 Nov 2011 15:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9068330"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 15:26:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 15:26:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSsFA-00055M-Fc	for xen-devel@lists.xensource.com;
	Tue, 22 Nov 2011 15:26:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSsFA-00028B-Es	for
	xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:26:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.48948.448220.476211@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 15:26:44 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Temporary list outage, sorry
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I made an ill-advised change to the mta configuration on
lists.xen.org.  If you got messages like:

 50.57.142.19 does not like recipient.
 Remote host said: 550 Unrouteable address

This should now be fixed.

Sorry,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:27:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:27:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsFm-00079V-DL; Tue, 22 Nov 2011 15:27:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSsFl-00079O-6A
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:27:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1321975494!45354759!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7465 invoked from network); 22 Nov 2011 15:24:55 -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;
	22 Nov 2011 15:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9068330"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 15:26:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 15:26:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSsFA-00055M-Fc	for xen-devel@lists.xensource.com;
	Tue, 22 Nov 2011 15:26:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSsFA-00028B-Es	for
	xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:26:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.48948.448220.476211@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 15:26:44 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] Temporary list outage, sorry
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I made an ill-advised change to the mta configuration on
lists.xen.org.  If you got messages like:

 50.57.142.19 does not like recipient.
 Remote host said: 550 Unrouteable address

This should now be fixed.

Sorry,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:30:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsIW-00080C-AM; Tue, 22 Nov 2011 15:30:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>)
	id 1RSsIV-0007ll-1o; Tue, 22 Nov 2011 15:30:11 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321975780!4545250!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6606 invoked from network); 22 Nov 2011 15:29:42 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 15:29:42 -0000
Received: by ghbz2 with SMTP id z2so389545ghb.30
	for <multiple recipients>; Tue, 22 Nov 2011 07:29:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=mWMgfW+RGUrEU5KGARW8CR2aI6co8gRGaZx9ETVQoqs=;
	b=jmoHWnGPvm5AAxTbYMonu13mk5XaaVwF5ooCjrhIT56rjKPnKE1ZMNoDGQ87+/nYYE
	Ux8O3caO6aH0+sidX57VI7E8/fSCzUm8xxYARuihO6ocJxfWdw8LuP7PFscR5SywjLHL
	8HpSIWs+RTM6XXVPPw0rbNsCgJqvqfzArEAoM=
MIME-Version: 1.0
Received: by 10.50.197.167 with SMTP id iv7mr21699443igc.46.1321975779759;
	Tue, 22 Nov 2011 07:29:39 -0800 (PST)
Received: by 10.231.62.1 with HTTP; Tue, 22 Nov 2011 07:29:39 -0800 (PST)
In-Reply-To: <eddb8c9332cad034094fae78cc1b7549@www.ark-net.org>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
	<000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
	<CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
	<eddb8c9332cad034094fae78cc1b7549@www.ark-net.org>
Date: Tue, 22 Nov 2011 16:29:39 +0100
Message-ID: <CAFivhP==_ivB=1i-Evv0xYP73EwtBeL3OY4DNDWNUnZBtWLJtA@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: mike.a.collins@ark-net.org
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/22 Michael A. Collins <mike.a.collins@ark-net.org>:
> On 22.11.2011 01:56, Shriram Rajagopalan wrote:
>
>> eh? I dont think so. with drbd based backend for xen VMs (with or without
>> remus),
>> you just use the drbd:<resourceName> syntax (much like phy:...).
> The drbd:<resource> syntax works for xm, but not for xl. =A0I'll have to =
work

That's what I ended up with, too

>> With all that said and done, I=92m currently running drbd 8.3.11 since
>> that=92s the version of the kernel module included with Linux 3.1, but
>> I=92m just using Xen=92s phy handler for the disk section of my VM=92s
>> cfg file.

wasn't there something in remus that demands you have a drbd: device
if you're not using blktap?

>> I see that there is a nice howto for debian on remusha.wikidot.com
>> [5], but again it uses a 2.6.32 kernel from Jeremy=92s git repo, which
>> has the tap kernel module.=A0 I again assert that currently there is
>> very little out there that would help to get someone started using
>> remus with drbd in the linux 3.1.x world.=A0 I run remus at work, but
>> it=92s using shared storage and have no need to use it with drbd, but
>> at home I don=92t really want to set that up, so I thought drbd would
>> be a nice start.
>>
>>
>>
>> I=92ve started diffing the 8.3.9 branch of drbd with your changes for
>> remus and will see how hard it is to get that in the 8.3.11 version
>>
>>>
>>> Is the remusified drbd (8.3.9) not compiling under the 3.1.x kernel
>>> anymore or are you interested in
>>> the latest version of DRBD + the remus stuff ?
>>>
>>>
>>> shriram
>
> I am interested in running the latest drbd changes with remus. =A0But I am
> interested in getting this to work through the xl interface more than
> anything.

Currently there's no alternate reality available in which one can run Remus?
blktap - not really there (and it would have other nice features)
dr:bd - doesn't play with xl
xm - not supposed to use that any more
older distros - will not take remus patches i guess
older howtos - broken since Remus is already part of Xen by now

(And I don't think it will get better by pointing at a workaround else
if one thing that should work isn't working.
Instead, soon, it will no longer work at all)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:30:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsIW-00080C-AM; Tue, 22 Nov 2011 15:30:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>)
	id 1RSsIV-0007ll-1o; Tue, 22 Nov 2011 15:30:11 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321975780!4545250!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6606 invoked from network); 22 Nov 2011 15:29:42 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 15:29:42 -0000
Received: by ghbz2 with SMTP id z2so389545ghb.30
	for <multiple recipients>; Tue, 22 Nov 2011 07:29:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=mWMgfW+RGUrEU5KGARW8CR2aI6co8gRGaZx9ETVQoqs=;
	b=jmoHWnGPvm5AAxTbYMonu13mk5XaaVwF5ooCjrhIT56rjKPnKE1ZMNoDGQ87+/nYYE
	Ux8O3caO6aH0+sidX57VI7E8/fSCzUm8xxYARuihO6ocJxfWdw8LuP7PFscR5SywjLHL
	8HpSIWs+RTM6XXVPPw0rbNsCgJqvqfzArEAoM=
MIME-Version: 1.0
Received: by 10.50.197.167 with SMTP id iv7mr21699443igc.46.1321975779759;
	Tue, 22 Nov 2011 07:29:39 -0800 (PST)
Received: by 10.231.62.1 with HTTP; Tue, 22 Nov 2011 07:29:39 -0800 (PST)
In-Reply-To: <eddb8c9332cad034094fae78cc1b7549@www.ark-net.org>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
	<000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
	<CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
	<eddb8c9332cad034094fae78cc1b7549@www.ark-net.org>
Date: Tue, 22 Nov 2011 16:29:39 +0100
Message-ID: <CAFivhP==_ivB=1i-Evv0xYP73EwtBeL3OY4DNDWNUnZBtWLJtA@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: mike.a.collins@ark-net.org
Cc: rshriram@cs.ubc.ca, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/22 Michael A. Collins <mike.a.collins@ark-net.org>:
> On 22.11.2011 01:56, Shriram Rajagopalan wrote:
>
>> eh? I dont think so. with drbd based backend for xen VMs (with or without
>> remus),
>> you just use the drbd:<resourceName> syntax (much like phy:...).
> The drbd:<resource> syntax works for xm, but not for xl. =A0I'll have to =
work

That's what I ended up with, too

>> With all that said and done, I=92m currently running drbd 8.3.11 since
>> that=92s the version of the kernel module included with Linux 3.1, but
>> I=92m just using Xen=92s phy handler for the disk section of my VM=92s
>> cfg file.

wasn't there something in remus that demands you have a drbd: device
if you're not using blktap?

>> I see that there is a nice howto for debian on remusha.wikidot.com
>> [5], but again it uses a 2.6.32 kernel from Jeremy=92s git repo, which
>> has the tap kernel module.=A0 I again assert that currently there is
>> very little out there that would help to get someone started using
>> remus with drbd in the linux 3.1.x world.=A0 I run remus at work, but
>> it=92s using shared storage and have no need to use it with drbd, but
>> at home I don=92t really want to set that up, so I thought drbd would
>> be a nice start.
>>
>>
>>
>> I=92ve started diffing the 8.3.9 branch of drbd with your changes for
>> remus and will see how hard it is to get that in the 8.3.11 version
>>
>>>
>>> Is the remusified drbd (8.3.9) not compiling under the 3.1.x kernel
>>> anymore or are you interested in
>>> the latest version of DRBD + the remus stuff ?
>>>
>>>
>>> shriram
>
> I am interested in running the latest drbd changes with remus. =A0But I am
> interested in getting this to work through the xl interface more than
> anything.

Currently there's no alternate reality available in which one can run Remus?
blktap - not really there (and it would have other nice features)
dr:bd - doesn't play with xl
xm - not supposed to use that any more
older distros - will not take remus patches i guess
older howtos - broken since Remus is already part of Xen by now

(And I don't think it will get better by pointing at a workaround else
if one thing that should work isn't working.
Instead, soon, it will no longer work at all)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:41:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:41:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsTL-0000Nn-IF; Tue, 22 Nov 2011 15:41:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSsTJ-0000Nd-I1
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:41:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321976442!46662555!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4254 invoked from network); 22 Nov 2011 15:40:43 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 15:40:43 -0000
Received: by wwo1 with SMTP id 1so144240wwo.24
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 07:40:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VjtCJ6CDeM7PvYcWFKPJCuBnTF41xGW/hJzXRpIQ4D4=;
	b=QEc+H200ruc/CU7H3lKWiZU70gn0TxW4L8OIrfbe0UnfgTzn7UkG4VKypUu+9K2/eC
	E3ZvxKi7sGL/LJvpMuax25P5yuJjrrSXf21nIOwIHgsjzs1rO2z2VO41bpSTxZ6mcpwH
	3BD1dEqomXIii7GvlhTajVRWRh+1tlQElvOZs=
Received: by 10.227.197.199 with SMTP id el7mr12432188wbb.12.1321976457382;
	Tue, 22 Nov 2011 07:40:57 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id l2sm17027574wbn.0.2011.11.22.07.40.55
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 07:40:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 15:40:47 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF172FF.34839%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypLRp+H++qVDYAZUCIJIH3e6jgTA==
In-Reply-To: <20111122150755.GA18727@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 15:07, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Keir Fraser wrote:
> 
>> On 22/11/2011 13:54, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>>> On Tue, Nov 22, Keir Fraser wrote:
>>> 
>>>> I think I checked before, but: also unresponsive to serial debug keys?
>>> 
>>> Good point, I will check that. So far I havent used these keys.
>> 
>> If they work then 'd' will give you a backtrace on every CPU, and 'q' will
>> dump domain and vcpu states. That should make things easier!
> 
> They do indeed work. The backtrace below is from another system.
> Looks like hpet_broadcast_exit() is involved.
> 
> Does that output below give any good hints?

It tells us that the hypervisor itself is in good shape. The deterministic
RIP in hpet_broadcast_exit() is simply because the serial rx interrupt is
always waking us from the idle loop. That RIP value will simply be the first
possible interruption point after the HLT instruction.

I have a new theory, which is that if we go round the for-loop in
wait_event() more than once, the vcpu's pause counter gets messed up and
goes negative, condemning it to sleep forever.

I have *just* pushed a change to the debug 'q' key (ignore the changeset
comment referring to 'd' key, I got that wrong!) which will print per-vcpu
and per-domain pause_count values. Please get the system stuck again, and
send the output from 'q' key with that new changeset (c/s 24178).

Finally, I don't really know what the prep/wake/done messages from your logs
mean, as you didn't send the patch that prints them.

 -- Keir 

>> Try the attached patch (please also try reducing the size of the new
>> parameter to the inline asm from PAGE_SIZE down to e.g. 2000 to force the
>> domain-crashing path).
> 
> Thanks, I will try it.
> 
> 
> Olaf
> 
> 
> ..........
> 
> (XEN) 'q' pressed -> dumping domain info (now=0x5E:F50D77F8)
> (XEN) General information for domain 0:
> (XEN)     refcnt=3 dying=0 nr_pages=1852873 xenheap_pages=5 dirty_cpus={}
> max_pages=4294967295
> (XEN)     handle=00000000-0000-0000-0000-000000000000 vm_assist=00000004
> (XEN) Rangesets belonging to domain 0:
> (XEN)     I/O Ports  { 0-1f, 22-3f, 44-60, 62-9f, a2-3f7, 400-807, 80c-cfb,
> d00-ffff }
> (XEN)     Interrupts { 0-207 }
> (XEN)     I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff }
> (XEN) Memory pages belonging to domain 0:
> (XEN)     DomPage list too long to display
> (XEN)     XenPage 000000000021e6d9: caf=c000000000000002, taf=7400000000000002
> (XEN)     XenPage 000000000021e6d8: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000021e6d7: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000021e6d6: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 00000000000db2fe: caf=c000000000000002, taf=7400000000000002
> (XEN) VCPU information and callbacks for domain 0:
> (XEN)     VCPU0: CPU0 [has=F] flags=0 poll=0 upcall_pend = 01, upcall_mask =
> 00 dirty_cpus={} cpu_affinity={0}
> (XEN)     250 Hz periodic timer (period 4 ms)
> (XEN) General information for domain 1:
> (XEN)     refcnt=3 dying=0 nr_pages=3645 xenheap_pages=6 dirty_cpus={}
> max_pages=131328
> (XEN)     handle=d80155e4-8f8b-94e1-8382-94084b7f1e51 vm_assist=00000000
> (XEN)     paging assistance: hap refcounts log_dirty translate external
> (XEN) Rangesets belonging to domain 1:
> (XEN)     I/O Ports  { }
> (XEN)     Interrupts { }
> (XEN)     I/O Memory { }
> (XEN) Memory pages belonging to domain 1:
> (XEN)     DomPage list too long to display
> (XEN)     PoD entries=0 cachesize=0
> (XEN)     XenPage 000000000020df70: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020e045: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020c58c: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020c5a4: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 0000000000019f1e: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020eb23: caf=c000000000000001, taf=7400000000000001
> (XEN) VCPU information and callbacks for domain 1:
> (XEN)     VCPU0: CPU0 [has=F] flags=4 poll=0 upcall_pend = 00, upcall_mask =
> 00 dirty_cpus={} cpu_affinity={0}
> (XEN)     paging assistance: hap, 4 levels
> (XEN)     No periodic timer
> (XEN) Notifying guest 0:0 (virq 1, port 0, stat 0/-1/-1)
> (XEN) Notifying guest 1:0 (virq 1, port 0, stat 0/0/0)
> (XEN) 'q' pressed -> dumping domain info (now=0x60:A7DD8B08)
> (XEN) General information for domain 0:
> (XEN)     refcnt=3 dying=0 nr_pages=1852873 xenheap_pages=5 dirty_cpus={}
> max_pages=4294967295
> (XEN)     handle=00000000-0000-0000-0000-000000000000 vm_assist=00000004
> (XEN) Rangesets belonging to domain 0:
> (XEN)     I/O Ports  { 0-1f, 22-3f, 44-60, 62-9f, a2-3f7, 400-807, 80c-cfb,
> d00-ffff }
> (XEN)     Interrupts { 0-207 }
> (XEN)     I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff }
> (XEN) Memory pages belonging to domain 0:
> (XEN)     DomPage list too long to display
> (XEN)     XenPage 000000000021e6d9: caf=c000000000000002, taf=7400000000000002
> (XEN)     XenPage 000000000021e6d8: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000021e6d7: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000021e6d6: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 00000000000db2fe: caf=c000000000000002, taf=7400000000000002
> (XEN) VCPU information and callbacks for domain 0:
> (XEN)     VCPU0: CPU0 [has=F] flags=0 poll=0 upcall_pend = 01, upcall_mask =
> 00 dirty_cpus={} cpu_affinity={0}
> (XEN)     250 Hz periodic timer (period 4 ms)
> (XEN) General information for domain 1:
> (XEN)     refcnt=3 dying=0 nr_pages=3645 xenheap_pages=6 dirty_cpus={}
> max_pages=131328
> (XEN)     handle=d80155e4-8f8b-94e1-8382-94084b7f1e51 vm_assist=00000000
> (XEN)     paging assistance: hap refcounts log_dirty translate external
> (XEN) Rangesets belonging to domain 1:
> (XEN)     I/O Ports  { }
> (XEN)     Interrupts { }
> (XEN)     I/O Memory { }
> (XEN) Memory pages belonging to domain 1:
> (XEN)     DomPage list too long to display
> (XEN)     PoD entries=0 cachesize=0
> (XEN)     XenPage 000000000020df70: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020e045: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020c58c: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020c5a4: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 0000000000019f1e: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020eb23: caf=c000000000000001, taf=7400000000000001
> (XEN) VCPU information and callbacks for domain 1:
> (XEN)     VCPU0: CPU0 [has=F] flags=4 poll=0 upcall_pend = 00, upcall_mask =
> 00 dirty_cpus={} cpu_affinity={0}
> (XEN)     paging assistance: hap, 4 levels
> (XEN)     No periodic timer
> (XEN) Notifying guest 0:0 (virq 1, port 0, stat 0/-1/-1)
> (XEN) Notifying guest 1:0 (virq 1, port 0, stat 0/0/0)
> (XEN) 'd' pressed -> dumping registers
> (XEN)
> (XEN) *** Dumping CPU0 host state: ***
> (XEN) ----[ Xen-4.2.24169-20111122.144218  x86_64  debug=y  Tainted:    C
> ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82c48019bfe6>] hpet_broadcast_exit+0x0/0x1f9
> (XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
> (XEN) rax: 0000000000003b40   rbx: 000000674742e72d   rcx: 0000000000000001
> (XEN) rdx: 0000000000000000   rsi: ffff82c48030f000   rdi: ffff82c4802bfea0
> (XEN) rbp: ffff82c4802bfee0   rsp: ffff82c4802bfe78   r8:  000000008c858211
> (XEN) r9:  0000000000000003   r10: ffff82c4803064e0   r11: 000000676bf885a3
> (XEN) r12: ffff83021e70e840   r13: ffff83021e70e8d0   r14: 00000067471bdb62
> (XEN) r15: ffff82c48030e440   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 00000000db4c4000   cr2: 0000000000beb000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=ffff82c4802bfe78:
> (XEN)    ffff82c48019f0ca ffff82c4802bff18 ffffffffffffffff ffff82c4802bfed0
> (XEN)    0000000180124b57 0000000000000000 0000000000000000 ffff82c48025b200
> (XEN)    0000152900006fe3 ffff82c4802bff18 ffff82c48025b200 ffff82c4802bff18
> (XEN)    ffff82c48030e468 ffff82c4802bff10 ffff82c48015a88d 0000000000000000
> (XEN)    ffff8300db6c6000 ffff8300db6c6000 ffffffffffffffff ffff82c4802bfe00
> (XEN)    0000000000000000 0000000000001000 0000000000001000 0000000000000000
> (XEN)    8000000000000427 ffff8801d8579010 0000000000000246 00000000deadbeef
> (XEN)    ffff8801d8579000 ffff8801d8579000 00000000fffffffe ffffffff8000302a
> (XEN)    00000000deadbeef 00000000deadbeef 00000000deadbeef 0000010000000000
> (XEN)    ffffffff8000302a 000000000000e033 0000000000000246 ffff8801a515bd10
> (XEN)    000000000000e02b 000000000000beef 000000000000beef 000000000000beef
> (XEN)    000000000000beef 0000000000000000 ffff8300db6c6000 0000000000000000
> (XEN)    0000000000000000
> (XEN) Xen call trace:
> (XEN)    [<ffff82c48019bfe6>] hpet_broadcast_exit+0x0/0x1f9
> (XEN)    [<ffff82c48015a88d>] idle_loop+0x6c/0x7b
> (XEN)
> (XEN) 'd' pressed -> dumping registers
> (XEN)
> (XEN) *** Dumping CPU0 host state: ***
> (XEN) ----[ Xen-4.2.24169-20111122.144218  x86_64  debug=y  Tainted:    C
> ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82c48019bfe6>] hpet_broadcast_exit+0x0/0x1f9
> (XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
> (XEN) rax: 0000000000003b40   rbx: 00000078f4fbe7ed   rcx: 0000000000000001
> (XEN) rdx: 0000000000000000   rsi: ffff82c48030f000   rdi: ffff82c4802bfea0
> (XEN) rbp: ffff82c4802bfee0   rsp: ffff82c4802bfe78   r8:  00000000cd4f8db6
> (XEN) r9:  0000000000000002   r10: ffff82c480308780   r11: 000000790438291d
> (XEN) r12: ffff83021e70e840   r13: ffff83021e70e8d0   r14: 00000078f412a61c
> (XEN) r15: ffff82c48030e440   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 00000000db4c4000   cr2: 0000000000beb000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=ffff82c4802bfe78:
> (XEN)    ffff82c48019f0ca ffff82c4802bff18 ffffffffffffffff ffff82c4802bfed0
> (XEN)    0000000180124b57 0000000000000000 0000000000000000 ffff82c48025b200
> (XEN)    0000239e00007657 ffff82c4802bff18 ffff82c48025b200 ffff82c4802bff18
> (XEN)    ffff82c48030e468 ffff82c4802bff10 ffff82c48015a88d 0000000000000000
> (XEN)    ffff8300db6c6000 ffff8300db6c6000 ffffffffffffffff ffff82c4802bfe00
> (XEN)    0000000000000000 0000000000001000 0000000000001000 0000000000000000
> (XEN)    8000000000000427 ffff8801d8579010 0000000000000246 00000000deadbeef
> (XEN)    ffff8801d8579000 ffff8801d8579000 00000000fffffffe ffffffff8000302a
> (XEN)    00000000deadbeef 00000000deadbeef 00000000deadbeef 0000010000000000
> (XEN)    ffffffff8000302a 000000000000e033 0000000000000246 ffff8801a515bd10
> (XEN)    000000000000e02b 000000000000beef 000000000000beef 000000000000beef
> (XEN)    000000000000beef 0000000000000000 ffff8300db6c6000 0000000000000000
> (XEN)    0000000000000000
> (XEN) Xen call trace:
> (XEN)    [<ffff82c48019bfe6>] hpet_broadcast_exit+0x0/0x1f9
> (XEN)    [<ffff82c48015a88d>] idle_loop+0x6c/0x7b
> (XEN)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:41:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:41:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsTL-0000Nn-IF; Tue, 22 Nov 2011 15:41:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSsTJ-0000Nd-I1
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:41:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321976442!46662555!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4254 invoked from network); 22 Nov 2011 15:40:43 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 15:40:43 -0000
Received: by wwo1 with SMTP id 1so144240wwo.24
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 07:40:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VjtCJ6CDeM7PvYcWFKPJCuBnTF41xGW/hJzXRpIQ4D4=;
	b=QEc+H200ruc/CU7H3lKWiZU70gn0TxW4L8OIrfbe0UnfgTzn7UkG4VKypUu+9K2/eC
	E3ZvxKi7sGL/LJvpMuax25P5yuJjrrSXf21nIOwIHgsjzs1rO2z2VO41bpSTxZ6mcpwH
	3BD1dEqomXIii7GvlhTajVRWRh+1tlQElvOZs=
Received: by 10.227.197.199 with SMTP id el7mr12432188wbb.12.1321976457382;
	Tue, 22 Nov 2011 07:40:57 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id l2sm17027574wbn.0.2011.11.22.07.40.55
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 07:40:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 15:40:47 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF172FF.34839%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypLRp+H++qVDYAZUCIJIH3e6jgTA==
In-Reply-To: <20111122150755.GA18727@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 15:07, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Keir Fraser wrote:
> 
>> On 22/11/2011 13:54, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>>> On Tue, Nov 22, Keir Fraser wrote:
>>> 
>>>> I think I checked before, but: also unresponsive to serial debug keys?
>>> 
>>> Good point, I will check that. So far I havent used these keys.
>> 
>> If they work then 'd' will give you a backtrace on every CPU, and 'q' will
>> dump domain and vcpu states. That should make things easier!
> 
> They do indeed work. The backtrace below is from another system.
> Looks like hpet_broadcast_exit() is involved.
> 
> Does that output below give any good hints?

It tells us that the hypervisor itself is in good shape. The deterministic
RIP in hpet_broadcast_exit() is simply because the serial rx interrupt is
always waking us from the idle loop. That RIP value will simply be the first
possible interruption point after the HLT instruction.

I have a new theory, which is that if we go round the for-loop in
wait_event() more than once, the vcpu's pause counter gets messed up and
goes negative, condemning it to sleep forever.

I have *just* pushed a change to the debug 'q' key (ignore the changeset
comment referring to 'd' key, I got that wrong!) which will print per-vcpu
and per-domain pause_count values. Please get the system stuck again, and
send the output from 'q' key with that new changeset (c/s 24178).

Finally, I don't really know what the prep/wake/done messages from your logs
mean, as you didn't send the patch that prints them.

 -- Keir 

>> Try the attached patch (please also try reducing the size of the new
>> parameter to the inline asm from PAGE_SIZE down to e.g. 2000 to force the
>> domain-crashing path).
> 
> Thanks, I will try it.
> 
> 
> Olaf
> 
> 
> ..........
> 
> (XEN) 'q' pressed -> dumping domain info (now=0x5E:F50D77F8)
> (XEN) General information for domain 0:
> (XEN)     refcnt=3 dying=0 nr_pages=1852873 xenheap_pages=5 dirty_cpus={}
> max_pages=4294967295
> (XEN)     handle=00000000-0000-0000-0000-000000000000 vm_assist=00000004
> (XEN) Rangesets belonging to domain 0:
> (XEN)     I/O Ports  { 0-1f, 22-3f, 44-60, 62-9f, a2-3f7, 400-807, 80c-cfb,
> d00-ffff }
> (XEN)     Interrupts { 0-207 }
> (XEN)     I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff }
> (XEN) Memory pages belonging to domain 0:
> (XEN)     DomPage list too long to display
> (XEN)     XenPage 000000000021e6d9: caf=c000000000000002, taf=7400000000000002
> (XEN)     XenPage 000000000021e6d8: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000021e6d7: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000021e6d6: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 00000000000db2fe: caf=c000000000000002, taf=7400000000000002
> (XEN) VCPU information and callbacks for domain 0:
> (XEN)     VCPU0: CPU0 [has=F] flags=0 poll=0 upcall_pend = 01, upcall_mask =
> 00 dirty_cpus={} cpu_affinity={0}
> (XEN)     250 Hz periodic timer (period 4 ms)
> (XEN) General information for domain 1:
> (XEN)     refcnt=3 dying=0 nr_pages=3645 xenheap_pages=6 dirty_cpus={}
> max_pages=131328
> (XEN)     handle=d80155e4-8f8b-94e1-8382-94084b7f1e51 vm_assist=00000000
> (XEN)     paging assistance: hap refcounts log_dirty translate external
> (XEN) Rangesets belonging to domain 1:
> (XEN)     I/O Ports  { }
> (XEN)     Interrupts { }
> (XEN)     I/O Memory { }
> (XEN) Memory pages belonging to domain 1:
> (XEN)     DomPage list too long to display
> (XEN)     PoD entries=0 cachesize=0
> (XEN)     XenPage 000000000020df70: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020e045: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020c58c: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020c5a4: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 0000000000019f1e: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020eb23: caf=c000000000000001, taf=7400000000000001
> (XEN) VCPU information and callbacks for domain 1:
> (XEN)     VCPU0: CPU0 [has=F] flags=4 poll=0 upcall_pend = 00, upcall_mask =
> 00 dirty_cpus={} cpu_affinity={0}
> (XEN)     paging assistance: hap, 4 levels
> (XEN)     No periodic timer
> (XEN) Notifying guest 0:0 (virq 1, port 0, stat 0/-1/-1)
> (XEN) Notifying guest 1:0 (virq 1, port 0, stat 0/0/0)
> (XEN) 'q' pressed -> dumping domain info (now=0x60:A7DD8B08)
> (XEN) General information for domain 0:
> (XEN)     refcnt=3 dying=0 nr_pages=1852873 xenheap_pages=5 dirty_cpus={}
> max_pages=4294967295
> (XEN)     handle=00000000-0000-0000-0000-000000000000 vm_assist=00000004
> (XEN) Rangesets belonging to domain 0:
> (XEN)     I/O Ports  { 0-1f, 22-3f, 44-60, 62-9f, a2-3f7, 400-807, 80c-cfb,
> d00-ffff }
> (XEN)     Interrupts { 0-207 }
> (XEN)     I/O Memory { 0-febff, fec01-fedff, fee01-ffffffffffffffff }
> (XEN) Memory pages belonging to domain 0:
> (XEN)     DomPage list too long to display
> (XEN)     XenPage 000000000021e6d9: caf=c000000000000002, taf=7400000000000002
> (XEN)     XenPage 000000000021e6d8: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000021e6d7: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000021e6d6: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 00000000000db2fe: caf=c000000000000002, taf=7400000000000002
> (XEN) VCPU information and callbacks for domain 0:
> (XEN)     VCPU0: CPU0 [has=F] flags=0 poll=0 upcall_pend = 01, upcall_mask =
> 00 dirty_cpus={} cpu_affinity={0}
> (XEN)     250 Hz periodic timer (period 4 ms)
> (XEN) General information for domain 1:
> (XEN)     refcnt=3 dying=0 nr_pages=3645 xenheap_pages=6 dirty_cpus={}
> max_pages=131328
> (XEN)     handle=d80155e4-8f8b-94e1-8382-94084b7f1e51 vm_assist=00000000
> (XEN)     paging assistance: hap refcounts log_dirty translate external
> (XEN) Rangesets belonging to domain 1:
> (XEN)     I/O Ports  { }
> (XEN)     Interrupts { }
> (XEN)     I/O Memory { }
> (XEN) Memory pages belonging to domain 1:
> (XEN)     DomPage list too long to display
> (XEN)     PoD entries=0 cachesize=0
> (XEN)     XenPage 000000000020df70: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020e045: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020c58c: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020c5a4: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 0000000000019f1e: caf=c000000000000001, taf=7400000000000001
> (XEN)     XenPage 000000000020eb23: caf=c000000000000001, taf=7400000000000001
> (XEN) VCPU information and callbacks for domain 1:
> (XEN)     VCPU0: CPU0 [has=F] flags=4 poll=0 upcall_pend = 00, upcall_mask =
> 00 dirty_cpus={} cpu_affinity={0}
> (XEN)     paging assistance: hap, 4 levels
> (XEN)     No periodic timer
> (XEN) Notifying guest 0:0 (virq 1, port 0, stat 0/-1/-1)
> (XEN) Notifying guest 1:0 (virq 1, port 0, stat 0/0/0)
> (XEN) 'd' pressed -> dumping registers
> (XEN)
> (XEN) *** Dumping CPU0 host state: ***
> (XEN) ----[ Xen-4.2.24169-20111122.144218  x86_64  debug=y  Tainted:    C
> ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82c48019bfe6>] hpet_broadcast_exit+0x0/0x1f9
> (XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
> (XEN) rax: 0000000000003b40   rbx: 000000674742e72d   rcx: 0000000000000001
> (XEN) rdx: 0000000000000000   rsi: ffff82c48030f000   rdi: ffff82c4802bfea0
> (XEN) rbp: ffff82c4802bfee0   rsp: ffff82c4802bfe78   r8:  000000008c858211
> (XEN) r9:  0000000000000003   r10: ffff82c4803064e0   r11: 000000676bf885a3
> (XEN) r12: ffff83021e70e840   r13: ffff83021e70e8d0   r14: 00000067471bdb62
> (XEN) r15: ffff82c48030e440   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 00000000db4c4000   cr2: 0000000000beb000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=ffff82c4802bfe78:
> (XEN)    ffff82c48019f0ca ffff82c4802bff18 ffffffffffffffff ffff82c4802bfed0
> (XEN)    0000000180124b57 0000000000000000 0000000000000000 ffff82c48025b200
> (XEN)    0000152900006fe3 ffff82c4802bff18 ffff82c48025b200 ffff82c4802bff18
> (XEN)    ffff82c48030e468 ffff82c4802bff10 ffff82c48015a88d 0000000000000000
> (XEN)    ffff8300db6c6000 ffff8300db6c6000 ffffffffffffffff ffff82c4802bfe00
> (XEN)    0000000000000000 0000000000001000 0000000000001000 0000000000000000
> (XEN)    8000000000000427 ffff8801d8579010 0000000000000246 00000000deadbeef
> (XEN)    ffff8801d8579000 ffff8801d8579000 00000000fffffffe ffffffff8000302a
> (XEN)    00000000deadbeef 00000000deadbeef 00000000deadbeef 0000010000000000
> (XEN)    ffffffff8000302a 000000000000e033 0000000000000246 ffff8801a515bd10
> (XEN)    000000000000e02b 000000000000beef 000000000000beef 000000000000beef
> (XEN)    000000000000beef 0000000000000000 ffff8300db6c6000 0000000000000000
> (XEN)    0000000000000000
> (XEN) Xen call trace:
> (XEN)    [<ffff82c48019bfe6>] hpet_broadcast_exit+0x0/0x1f9
> (XEN)    [<ffff82c48015a88d>] idle_loop+0x6c/0x7b
> (XEN)
> (XEN) 'd' pressed -> dumping registers
> (XEN)
> (XEN) *** Dumping CPU0 host state: ***
> (XEN) ----[ Xen-4.2.24169-20111122.144218  x86_64  debug=y  Tainted:    C
> ]----
> (XEN) CPU:    0
> (XEN) RIP:    e008:[<ffff82c48019bfe6>] hpet_broadcast_exit+0x0/0x1f9
> (XEN) RFLAGS: 0000000000000246   CONTEXT: hypervisor
> (XEN) rax: 0000000000003b40   rbx: 00000078f4fbe7ed   rcx: 0000000000000001
> (XEN) rdx: 0000000000000000   rsi: ffff82c48030f000   rdi: ffff82c4802bfea0
> (XEN) rbp: ffff82c4802bfee0   rsp: ffff82c4802bfe78   r8:  00000000cd4f8db6
> (XEN) r9:  0000000000000002   r10: ffff82c480308780   r11: 000000790438291d
> (XEN) r12: ffff83021e70e840   r13: ffff83021e70e8d0   r14: 00000078f412a61c
> (XEN) r15: ffff82c48030e440   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 00000000db4c4000   cr2: 0000000000beb000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=ffff82c4802bfe78:
> (XEN)    ffff82c48019f0ca ffff82c4802bff18 ffffffffffffffff ffff82c4802bfed0
> (XEN)    0000000180124b57 0000000000000000 0000000000000000 ffff82c48025b200
> (XEN)    0000239e00007657 ffff82c4802bff18 ffff82c48025b200 ffff82c4802bff18
> (XEN)    ffff82c48030e468 ffff82c4802bff10 ffff82c48015a88d 0000000000000000
> (XEN)    ffff8300db6c6000 ffff8300db6c6000 ffffffffffffffff ffff82c4802bfe00
> (XEN)    0000000000000000 0000000000001000 0000000000001000 0000000000000000
> (XEN)    8000000000000427 ffff8801d8579010 0000000000000246 00000000deadbeef
> (XEN)    ffff8801d8579000 ffff8801d8579000 00000000fffffffe ffffffff8000302a
> (XEN)    00000000deadbeef 00000000deadbeef 00000000deadbeef 0000010000000000
> (XEN)    ffffffff8000302a 000000000000e033 0000000000000246 ffff8801a515bd10
> (XEN)    000000000000e02b 000000000000beef 000000000000beef 000000000000beef
> (XEN)    000000000000beef 0000000000000000 ffff8300db6c6000 0000000000000000
> (XEN)    0000000000000000
> (XEN) Xen call trace:
> (XEN)    [<ffff82c48019bfe6>] hpet_broadcast_exit+0x0/0x1f9
> (XEN)    [<ffff82c48015a88d>] idle_loop+0x6c/0x7b
> (XEN)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:49:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:49:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsbB-0000gf-DB; Tue, 22 Nov 2011 15:49:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RSsbA-0000gC-5l
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:49:28 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321976938!4548940!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19259 invoked from network); 22 Nov 2011 15:48:59 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 15:48:59 -0000
Received: by iaby12 with SMTP id y12so402807iab.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 07:48:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=5v1aRFysEf7Wp4egGvv65Vb2B0TJZdm86p+tjlb0XLQ=;
	b=I9nOiNWpAPdTGCrpy3m5Hly4ZnYkVTkeGItxaAHMgsdN9cudhuxkk2h3hXrKIjV766
	GGTlVXtII/ItBIViSzWPJNZFF/OGRMVzfXJI39OLh0H1wDPDCBDUMJF2pJz5WvHOkbdD
	ZhyYqXIiRgqAE61bAgEvrBQ3n04btkBopsF+s=
MIME-Version: 1.0
Received: by 10.231.67.80 with SMTP id q16mr5036515ibi.86.1321976937876; Tue,
	22 Nov 2011 07:48:57 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Tue, 22 Nov 2011 07:48:57 -0800 (PST)
In-Reply-To: <20111121151359.GA22981@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
Date: Tue, 22 Nov 2011 15:48:57 +0000
X-Google-Sender-Auth: eLByntLpaGrbpwS1j9mQAkhGKWU
Message-ID: <CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 21, 2011 at 3:13 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Nov 21, Stefano Stabellini wrote:
>
>> what if tot_memkb is bigger than target_memkb? Or even bigger than
>> max_memkb?
>
> tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> max_memkb.

It seems to me the opposite: tot_memkb (as you're describing here) and
target_memkb both mean, "How much Xen memory the administrator wants
allocated to the VM."  Before either paging or PoD, the only way to
modify the amount of memory allocated to a VM was via the balloon
driver.  PoD introduced a mechanism that allows the domain builder to
start a VM with less memory than static_max, and allow the VM to run
until balloon driver can normalize things.    Paging introduces a
separate mechanism for the administrator to modify the amount of
memory allocated to the VM.

It seems to me like paging and ballooning should both use
target_memkb.  We just need to figure out how to make sure that paging
only comes on when it's needed.  When it might be needed includes:
* For guests that don't have a balloon driver
* For guests whose balloon driver is not meeting target_memkb (either
because it's unresponsive, rebellious, or because it can't get more
memory from the guest OS)
* Potentially, between domain creation and the time the balloon driver
comes up (i.e., replacing PoD).

It seems like having some kind of a flag or setting would be better.
Various factors:
* Do we start the paging daemon?
* Do we use paging during boot?  Only matters if max_memkb !=
target_memkb.  If no, the domain builder uses PoD mode.  If yes, the
domain builder will fill in target_memkb worth of guest memory, and
then fill the rest with swapped-out entries.  (If max_memkb ==
target_memkb, domain builder fills in all entries.)
* When does the paging daemon respond to changes to target_memkb?
This could be:
 - Immediately (assume no balloon driver)
 - PoD mode: Start immediately, but when you notice the balloon driver
reaching the initial target_memkb, turn off, or switch into the next
mode
 - Fallback mode: Pay attention to changes in target_memkb, but don't
act immediately.  Wait for paging_delay secs for the balloon driver to
handle it; if it doesn't respond, then start paging (and perhaps
switch to "Immediately" mode).

What do you think?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:49:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:49:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsbB-0000gf-DB; Tue, 22 Nov 2011 15:49:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RSsbA-0000gC-5l
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:49:28 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321976938!4548940!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19259 invoked from network); 22 Nov 2011 15:48:59 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 15:48:59 -0000
Received: by iaby12 with SMTP id y12so402807iab.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 07:48:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=5v1aRFysEf7Wp4egGvv65Vb2B0TJZdm86p+tjlb0XLQ=;
	b=I9nOiNWpAPdTGCrpy3m5Hly4ZnYkVTkeGItxaAHMgsdN9cudhuxkk2h3hXrKIjV766
	GGTlVXtII/ItBIViSzWPJNZFF/OGRMVzfXJI39OLh0H1wDPDCBDUMJF2pJz5WvHOkbdD
	ZhyYqXIiRgqAE61bAgEvrBQ3n04btkBopsF+s=
MIME-Version: 1.0
Received: by 10.231.67.80 with SMTP id q16mr5036515ibi.86.1321976937876; Tue,
	22 Nov 2011 07:48:57 -0800 (PST)
Received: by 10.231.169.13 with HTTP; Tue, 22 Nov 2011 07:48:57 -0800 (PST)
In-Reply-To: <20111121151359.GA22981@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
Date: Tue, 22 Nov 2011 15:48:57 +0000
X-Google-Sender-Auth: eLByntLpaGrbpwS1j9mQAkhGKWU
Message-ID: <CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 21, 2011 at 3:13 PM, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Nov 21, Stefano Stabellini wrote:
>
>> what if tot_memkb is bigger than target_memkb? Or even bigger than
>> max_memkb?
>
> tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> max_memkb.

It seems to me the opposite: tot_memkb (as you're describing here) and
target_memkb both mean, "How much Xen memory the administrator wants
allocated to the VM."  Before either paging or PoD, the only way to
modify the amount of memory allocated to a VM was via the balloon
driver.  PoD introduced a mechanism that allows the domain builder to
start a VM with less memory than static_max, and allow the VM to run
until balloon driver can normalize things.    Paging introduces a
separate mechanism for the administrator to modify the amount of
memory allocated to the VM.

It seems to me like paging and ballooning should both use
target_memkb.  We just need to figure out how to make sure that paging
only comes on when it's needed.  When it might be needed includes:
* For guests that don't have a balloon driver
* For guests whose balloon driver is not meeting target_memkb (either
because it's unresponsive, rebellious, or because it can't get more
memory from the guest OS)
* Potentially, between domain creation and the time the balloon driver
comes up (i.e., replacing PoD).

It seems like having some kind of a flag or setting would be better.
Various factors:
* Do we start the paging daemon?
* Do we use paging during boot?  Only matters if max_memkb !=
target_memkb.  If no, the domain builder uses PoD mode.  If yes, the
domain builder will fill in target_memkb worth of guest memory, and
then fill the rest with swapped-out entries.  (If max_memkb ==
target_memkb, domain builder fills in all entries.)
* When does the paging daemon respond to changes to target_memkb?
This could be:
 - Immediately (assume no balloon driver)
 - PoD mode: Start immediately, but when you notice the balloon driver
reaching the initial target_memkb, turn off, or switch into the next
mode
 - Fallback mode: Pay attention to changes in target_memkb, but don't
act immediately.  Wait for paging_delay secs for the balloon driver to
handle it; if it doesn't respond, then start paging (and perhaps
switch to "Immediately" mode).

What do you think?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:54:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsfl-00011j-4F; Tue, 22 Nov 2011 15:54:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSsfj-00011V-4Z
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:54:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1321977221!5293588!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14902 invoked from network); 22 Nov 2011 15:53:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 15:53:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 22 Nov 2011 15:53:41 +0000
Message-Id: <4ECBD3920200007800062617@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 22 Nov 2011 15:53:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH] move pci_find_ext_capability() into common PCI
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There's nothing architecture specific about it. It requires, however,
that x86-32's pci_conf_read32() tolerates register accesses above 255
(for consistency the adjustment is done to all pci_conf_readNN()
functions).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/xen/pci.c
+++ b/xen/arch/ia64/xen/pci.c
@@ -135,8 +135,3 @@ void pci_conf_write32(
     BUG_ON((seg > 65535) || (bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
     pci_sal_write(seg, bus, (dev<<3)|func, reg, 4, data);
 }
-
-int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
-{
-    return 0;
-}
--- a/xen/arch/x86/x86_32/pci.c
+++ b/xen/arch/x86/x86_32/pci.c
@@ -15,9 +15,9 @@ uint8_t pci_conf_read8(
     unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
     unsigned int reg)
 {
-    if ( seg )
+    if ( seg || (reg > 255) )
         return ~0;
-    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
+    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
     return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 3, 1);
 }
 
@@ -25,9 +25,9 @@ uint16_t pci_conf_read16(
     unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
     unsigned int reg)
 {
-    if ( seg )
+    if ( seg || (reg > 255) )
         return ~0;
-    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
+    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
     return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 2, 2);
 }
 
@@ -35,9 +35,9 @@ uint32_t pci_conf_read32(
     unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
     unsigned int reg)
 {
-    if ( seg )
+    if ( seg || (reg > 255) )
         return ~0;
-    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
+    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
     return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4);
 }
 
@@ -70,8 +70,3 @@ void pci_conf_write32(
     BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
     pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
 }
-
-int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
-{
-    return 0;
-}
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -450,43 +450,3 @@ int pci_mmcfg_reserved(uint64_t address,
 
     return -ENODEV;
 }
-
-/**
- * pci_find_ext_capability - Find an extended capability
- * @dev: PCI device to query
- * @cap: capability code
- *
- * Returns the address of the requested extended capability structure
- * within the device's PCI configuration space or 0 if the device does
- * not support it.  Possible values for @cap:
- *
- *  %PCI_EXT_CAP_ID_ERR         Advanced Error Reporting
- *  %PCI_EXT_CAP_ID_VC          Virtual Channel
- *  %PCI_EXT_CAP_ID_DSN         Device Serial Number
- *  %PCI_EXT_CAP_ID_PWR         Power Budgeting
- */
-int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
-{
-    u32 header;
-    int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */
-    int pos = 0x100;
-
-    header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos);
-
-    /*
-     * If we have no capabilities, this is indicated by cap ID,
-     * cap version and next pointer all being 0.
-     */
-    if ( (header == 0) || (header == -1) )
-        return 0;
-
-    while ( ttl-- > 0 ) {
-        if ( PCI_EXT_CAP_ID(header) == cap )
-            return pos;
-        pos = PCI_EXT_CAP_NEXT(header);
-        if ( pos < 0x100 )
-            break;
-        header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos);
-    }
-    return 0;
-}
--- a/xen/drivers/pci/pci.c
+++ b/xen/drivers/pci/pci.c
@@ -62,3 +62,43 @@ int pci_find_next_cap(u16 seg, u8 bus, u
     }
     return 0;
 }
+
+/**
+ * pci_find_ext_capability - Find an extended capability
+ * @dev: PCI device to query
+ * @cap: capability code
+ *
+ * Returns the address of the requested extended capability structure
+ * within the device's PCI configuration space or 0 if the device does
+ * not support it.  Possible values for @cap:
+ *
+ *  %PCI_EXT_CAP_ID_ERR         Advanced Error Reporting
+ *  %PCI_EXT_CAP_ID_VC          Virtual Channel
+ *  %PCI_EXT_CAP_ID_DSN         Device Serial Number
+ *  %PCI_EXT_CAP_ID_PWR         Power Budgeting
+ */
+int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
+{
+    u32 header;
+    int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */
+    int pos = 0x100;
+
+    header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos);
+
+    /*
+     * If we have no capabilities, this is indicated by cap ID,
+     * cap version and next pointer all being 0.
+     */
+    if ( (header == 0) || (header == -1) )
+        return 0;
+
+    while ( ttl-- > 0 ) {
+        if ( PCI_EXT_CAP_ID(header) == cap )
+            return pos;
+        pos = PCI_EXT_CAP_NEXT(header);
+        if ( pos < 0x100 )
+            break;
+        header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos);
+    }
+    return 0;
+}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:54:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsfl-00011j-4F; Tue, 22 Nov 2011 15:54:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSsfj-00011V-4Z
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:54:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1321977221!5293588!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14902 invoked from network); 22 Nov 2011 15:53:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 15:53:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 22 Nov 2011 15:53:41 +0000
Message-Id: <4ECBD3920200007800062617@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 22 Nov 2011 15:53:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH] move pci_find_ext_capability() into common PCI
	code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There's nothing architecture specific about it. It requires, however,
that x86-32's pci_conf_read32() tolerates register accesses above 255
(for consistency the adjustment is done to all pci_conf_readNN()
functions).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/xen/pci.c
+++ b/xen/arch/ia64/xen/pci.c
@@ -135,8 +135,3 @@ void pci_conf_write32(
     BUG_ON((seg > 65535) || (bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
     pci_sal_write(seg, bus, (dev<<3)|func, reg, 4, data);
 }
-
-int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
-{
-    return 0;
-}
--- a/xen/arch/x86/x86_32/pci.c
+++ b/xen/arch/x86/x86_32/pci.c
@@ -15,9 +15,9 @@ uint8_t pci_conf_read8(
     unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
     unsigned int reg)
 {
-    if ( seg )
+    if ( seg || (reg > 255) )
         return ~0;
-    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
+    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
     return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 3, 1);
 }
 
@@ -25,9 +25,9 @@ uint16_t pci_conf_read16(
     unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
     unsigned int reg)
 {
-    if ( seg )
+    if ( seg || (reg > 255) )
         return ~0;
-    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
+    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
     return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 2, 2);
 }
 
@@ -35,9 +35,9 @@ uint32_t pci_conf_read32(
     unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
     unsigned int reg)
 {
-    if ( seg )
+    if ( seg || (reg > 255) )
         return ~0;
-    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
+    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
     return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4);
 }
 
@@ -70,8 +70,3 @@ void pci_conf_write32(
     BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
     pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
 }
-
-int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
-{
-    return 0;
-}
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -450,43 +450,3 @@ int pci_mmcfg_reserved(uint64_t address,
 
     return -ENODEV;
 }
-
-/**
- * pci_find_ext_capability - Find an extended capability
- * @dev: PCI device to query
- * @cap: capability code
- *
- * Returns the address of the requested extended capability structure
- * within the device's PCI configuration space or 0 if the device does
- * not support it.  Possible values for @cap:
- *
- *  %PCI_EXT_CAP_ID_ERR         Advanced Error Reporting
- *  %PCI_EXT_CAP_ID_VC          Virtual Channel
- *  %PCI_EXT_CAP_ID_DSN         Device Serial Number
- *  %PCI_EXT_CAP_ID_PWR         Power Budgeting
- */
-int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
-{
-    u32 header;
-    int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */
-    int pos = 0x100;
-
-    header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos);
-
-    /*
-     * If we have no capabilities, this is indicated by cap ID,
-     * cap version and next pointer all being 0.
-     */
-    if ( (header == 0) || (header == -1) )
-        return 0;
-
-    while ( ttl-- > 0 ) {
-        if ( PCI_EXT_CAP_ID(header) == cap )
-            return pos;
-        pos = PCI_EXT_CAP_NEXT(header);
-        if ( pos < 0x100 )
-            break;
-        header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos);
-    }
-    return 0;
-}
--- a/xen/drivers/pci/pci.c
+++ b/xen/drivers/pci/pci.c
@@ -62,3 +62,43 @@ int pci_find_next_cap(u16 seg, u8 bus, u
     }
     return 0;
 }
+
+/**
+ * pci_find_ext_capability - Find an extended capability
+ * @dev: PCI device to query
+ * @cap: capability code
+ *
+ * Returns the address of the requested extended capability structure
+ * within the device's PCI configuration space or 0 if the device does
+ * not support it.  Possible values for @cap:
+ *
+ *  %PCI_EXT_CAP_ID_ERR         Advanced Error Reporting
+ *  %PCI_EXT_CAP_ID_VC          Virtual Channel
+ *  %PCI_EXT_CAP_ID_DSN         Device Serial Number
+ *  %PCI_EXT_CAP_ID_PWR         Power Budgeting
+ */
+int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
+{
+    u32 header;
+    int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */
+    int pos = 0x100;
+
+    header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos);
+
+    /*
+     * If we have no capabilities, this is indicated by cap ID,
+     * cap version and next pointer all being 0.
+     */
+    if ( (header == 0) || (header == -1) )
+        return 0;
+
+    while ( ttl-- > 0 ) {
+        if ( PCI_EXT_CAP_ID(header) == cap )
+            return pos;
+        pos = PCI_EXT_CAP_NEXT(header);
+        if ( pos < 0x100 )
+            break;
+        header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), pos);
+    }
+    return 0;
+}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:55:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:55:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsgw-00018C-PT; Tue, 22 Nov 2011 15:55:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSsgu-00017l-H4
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:55:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1321977295!4159522!1
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9247 invoked from network); 22 Nov 2011 15:54:55 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 15:54:55 -0000
Received: by eyb6 with SMTP id 6so458310eyb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 07:54:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nbC++iTdL6LN08533qhz6kiAYxSxhpN/mzWWhkQW3nk=;
	b=TsaKCEDmtMX0LhttDRe4CEP4VMIZmr8BF2hBFG9O+Mytw/nFbh3I8NuJZiVk9SPQMo
	4ZADZQiH6LqqiO5QMaZ18fh+Dr+qvs5Wwkt16QMk0+TYlUIt+87StQtOYQZorUMYfhpw
	9YQa18/HuJeen3s1o4vzXqutq1zo05iY8pUTk=
Received: by 10.180.104.35 with SMTP id gb3mr20099157wib.11.1321977295186;
	Tue, 22 Nov 2011 07:54:55 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id ht10sm6866581wib.6.2011.11.22.07.54.53
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 07:54:54 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 15:54:44 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF17644.34841%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypLRp+H++qVDYAZUCIJIH3e6jgTAAAfLlJ
In-Reply-To: <CAF172FF.34839%keir@xen.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 15:40, "Keir Fraser" <keir@xen.org> wrote:

> I have a new theory, which is that if we go round the for-loop in
> wait_event() more than once, the vcpu's pause counter gets messed up and
> goes negative, condemning it to sleep forever.

Further to this, can you please try moving the call to __prepare_to_wait()
from just after the spinlock region to just before (i.e., immediately after
the ASSERT), in prepare_to_wait(). That could well makes things work better.
On UP at least -- for SMP systems I will also need to fix the broken usage
of wqv->esp...

 -- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:55:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:55:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsgw-00018C-PT; Tue, 22 Nov 2011 15:55:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSsgu-00017l-H4
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:55:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1321977295!4159522!1
X-Originating-IP: [209.85.215.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9247 invoked from network); 22 Nov 2011 15:54:55 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 15:54:55 -0000
Received: by eyb6 with SMTP id 6so458310eyb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 07:54:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nbC++iTdL6LN08533qhz6kiAYxSxhpN/mzWWhkQW3nk=;
	b=TsaKCEDmtMX0LhttDRe4CEP4VMIZmr8BF2hBFG9O+Mytw/nFbh3I8NuJZiVk9SPQMo
	4ZADZQiH6LqqiO5QMaZ18fh+Dr+qvs5Wwkt16QMk0+TYlUIt+87StQtOYQZorUMYfhpw
	9YQa18/HuJeen3s1o4vzXqutq1zo05iY8pUTk=
Received: by 10.180.104.35 with SMTP id gb3mr20099157wib.11.1321977295186;
	Tue, 22 Nov 2011 07:54:55 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id ht10sm6866581wib.6.2011.11.22.07.54.53
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 07:54:54 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 15:54:44 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF17644.34841%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypLRp+H++qVDYAZUCIJIH3e6jgTAAAfLlJ
In-Reply-To: <CAF172FF.34839%keir@xen.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 15:40, "Keir Fraser" <keir@xen.org> wrote:

> I have a new theory, which is that if we go round the for-loop in
> wait_event() more than once, the vcpu's pause counter gets messed up and
> goes negative, condemning it to sleep forever.

Further to this, can you please try moving the call to __prepare_to_wait()
from just after the spinlock region to just before (i.e., immediately after
the ASSERT), in prepare_to_wait(). That could well makes things work better.
On UP at least -- for SMP systems I will also need to fix the broken usage
of wqv->esp...

 -- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:57:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:57:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsih-0001Jq-IY; Tue, 22 Nov 2011 15:57:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSsif-0001JE-K2
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:57:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1321977404!5240812!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21097 invoked from network); 22 Nov 2011 15:56:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 15:56:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 22 Nov 2011 15:56:44 +0000
Message-Id: <4ECBD44A020000780006261B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 22 Nov 2011 15:56:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part012E892A.2__="
Cc: Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part012E892A.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This undoes a single change from c/s 24136:3622d7fae14d
(common/grant_table.c) and several from c/s 24100:be8daf78856a
(common/memory.c). It also completes the former with two previously
missing ia64 specific code adjustments. Authors Cc-ed.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -173,7 +173,7 @@ static int __get_paged_frame(unsigned lo
        rc =3D GNTST_bad_page;
     }
 #else
-    *frame =3D readonly ? get_gfn_untyped(rd, gfn) : gfn_to_mfn_private(rd=
, gfn);
+    *frame =3D readonly ? gmfn_to_mfn(rd, gfn) : gfn_to_mfn_private(rd, =
gfn);
 #endif
=20
     return rc;
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -165,7 +165,7 @@ int guest_remove_page(struct domain *d,=20
     mfn =3D mfn_x(get_gfn(d, gmfn, &p2mt));=20
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
-        guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
+        guest_physmap_remove_page(d, gmfn, mfn, 0);
         p2m_mem_paging_drop_page(d, gmfn);
         put_gfn(d, gmfn);
         return 1;
@@ -188,7 +188,7 @@ int guest_remove_page(struct domain *d,=20
     if(p2m_is_shared(p2mt))
     {
         put_page_and_type(page);
-        guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
+        guest_physmap_remove_page(d, gmfn, mfn, 0);
         put_gfn(d, gmfn);
         return 1;
     }
@@ -207,7 +207,7 @@ int guest_remove_page(struct domain *d,=20
     if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
         put_page(page);
=20
-    guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
+    guest_physmap_remove_page(d, gmfn, mfn, 0);
=20
     put_page(page);
     put_gfn(d, gmfn);
@@ -427,7 +427,7 @@ static long memory_exchange(XEN_GUEST_HA
             gfn =3D mfn_to_gmfn(d, mfn);
             /* Pages were unshared above */
             BUG_ON(SHARED_M2P(gfn));
-            guest_physmap_remove_page(d, gfn, mfn, PAGE_ORDER_4K);
+            guest_physmap_remove_page(d, gfn, mfn, 0);
             put_page(page);
         }
=20
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -95,7 +95,7 @@ static inline void *cli_get_page(tmem_cl
     return NULL;
 }
=20
-static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
+static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t =
*cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     ASSERT(0);
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -532,6 +532,7 @@ extern u64 translate_domain_pte(u64 ptev
 				u64* itir, struct p2m_entry* entry);
 #define machine_to_phys_mapping	mpt_table
=20
+#define INVALID_GFN              (~0UL)
 #define INVALID_M2P_ENTRY        (~0UL)
 #define VALID_M2P(_e)            (!((_e) & (1UL<<63)))
 #define SHARED_M2P(_e)           0




--=__Part012E892A.2__=
Content-Type: text/plain; name="ia64-build.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ia64-build.patch"

ia64: build fixes (again)=0A=0AThis undoes a single change from c/s =
24136:3622d7fae14d=0A(common/grant_table.c) and several from c/s 24100:be8d=
af78856a=0A(common/memory.c). It also completes the former with two =
previously=0Amissing ia64 specific code adjustments. Authors Cc-ed.=0A=0ASi=
gned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/grant_ta=
ble.c=0A+++ b/xen/common/grant_table.c=0A@@ -173,7 +173,7 @@ static int =
__get_paged_frame(unsigned lo=0A        rc =3D GNTST_bad_page;=0A     }=0A =
#else=0A-    *frame =3D readonly ? get_gfn_untyped(rd, gfn) : gfn_to_mfn_pr=
ivate(rd, gfn);=0A+    *frame =3D readonly ? gmfn_to_mfn(rd, gfn) : =
gfn_to_mfn_private(rd, gfn);=0A #endif=0A =0A     return rc;=0A--- =
a/xen/common/memory.c=0A+++ b/xen/common/memory.c=0A@@ -165,7 +165,7 @@ =
int guest_remove_page(struct domain *d, =0A     mfn =3D mfn_x(get_gfn(d, =
gmfn, &p2mt)); =0A     if ( unlikely(p2m_is_paging(p2mt)) )=0A     {=0A-   =
     guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);=0A+        =
guest_physmap_remove_page(d, gmfn, mfn, 0);=0A         p2m_mem_paging_drop_=
page(d, gmfn);=0A         put_gfn(d, gmfn);=0A         return 1;=0A@@ =
-188,7 +188,7 @@ int guest_remove_page(struct domain *d, =0A     if(p2m_is_=
shared(p2mt))=0A     {=0A         put_page_and_type(page);=0A-        =
guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);=0A+        =
guest_physmap_remove_page(d, gmfn, mfn, 0);=0A         put_gfn(d, =
gmfn);=0A         return 1;=0A     }=0A@@ -207,7 +207,7 @@ int guest_remove=
_page(struct domain *d, =0A     if ( test_and_clear_bit(_PGC_allocated, =
&page->count_info) )=0A         put_page(page);=0A =0A-    guest_physmap_re=
move_page(d, gmfn, mfn, PAGE_ORDER_4K);=0A+    guest_physmap_remove_page(d,=
 gmfn, mfn, 0);=0A =0A     put_page(page);=0A     put_gfn(d, gmfn);=0A@@ =
-427,7 +427,7 @@ static long memory_exchange(XEN_GUEST_HA=0A             =
gfn =3D mfn_to_gmfn(d, mfn);=0A             /* Pages were unshared above =
*/=0A             BUG_ON(SHARED_M2P(gfn));=0A-            guest_physmap_rem=
ove_page(d, gfn, mfn, PAGE_ORDER_4K);=0A+            guest_physmap_remove_p=
age(d, gfn, mfn, 0);=0A             put_page(page);=0A         }=0A =0A--- =
a/xen/common/tmem_xen.c=0A+++ b/xen/common/tmem_xen.c=0A@@ -95,7 +95,7 @@ =
static inline void *cli_get_page(tmem_cl=0A     return NULL;=0A }=0A =
=0A-static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,=0A+static=
 inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t =
*cli_pfp,=0A                                 unsigned long cli_mfn, bool_t =
mark_dirty)=0A {=0A     ASSERT(0);=0A--- a/xen/include/asm-ia64/mm.h=0A+++ =
b/xen/include/asm-ia64/mm.h=0A@@ -532,6 +532,7 @@ extern u64 translate_doma=
in_pte(u64 ptev=0A 				u64* itir, struct =
p2m_entry* entry);=0A #define machine_to_phys_mapping	mpt_table=0A =
=0A+#define INVALID_GFN              (~0UL)=0A #define INVALID_M2P_ENTRY   =
     (~0UL)=0A #define VALID_M2P(_e)            (!((_e) & (1UL<<63)))=0A =
#define SHARED_M2P(_e)           0=0A
--=__Part012E892A.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part012E892A.2__=--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 15:57:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 15:57:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsih-0001Jq-IY; Tue, 22 Nov 2011 15:57:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSsif-0001JE-K2
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 15:57:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1321977404!5240812!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21097 invoked from network); 22 Nov 2011 15:56:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 15:56:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 22 Nov 2011 15:56:44 +0000
Message-Id: <4ECBD44A020000780006261B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 22 Nov 2011 15:56:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part012E892A.2__="
Cc: Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part012E892A.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This undoes a single change from c/s 24136:3622d7fae14d
(common/grant_table.c) and several from c/s 24100:be8daf78856a
(common/memory.c). It also completes the former with two previously
missing ia64 specific code adjustments. Authors Cc-ed.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -173,7 +173,7 @@ static int __get_paged_frame(unsigned lo
        rc =3D GNTST_bad_page;
     }
 #else
-    *frame =3D readonly ? get_gfn_untyped(rd, gfn) : gfn_to_mfn_private(rd=
, gfn);
+    *frame =3D readonly ? gmfn_to_mfn(rd, gfn) : gfn_to_mfn_private(rd, =
gfn);
 #endif
=20
     return rc;
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -165,7 +165,7 @@ int guest_remove_page(struct domain *d,=20
     mfn =3D mfn_x(get_gfn(d, gmfn, &p2mt));=20
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
-        guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
+        guest_physmap_remove_page(d, gmfn, mfn, 0);
         p2m_mem_paging_drop_page(d, gmfn);
         put_gfn(d, gmfn);
         return 1;
@@ -188,7 +188,7 @@ int guest_remove_page(struct domain *d,=20
     if(p2m_is_shared(p2mt))
     {
         put_page_and_type(page);
-        guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
+        guest_physmap_remove_page(d, gmfn, mfn, 0);
         put_gfn(d, gmfn);
         return 1;
     }
@@ -207,7 +207,7 @@ int guest_remove_page(struct domain *d,=20
     if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
         put_page(page);
=20
-    guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
+    guest_physmap_remove_page(d, gmfn, mfn, 0);
=20
     put_page(page);
     put_gfn(d, gmfn);
@@ -427,7 +427,7 @@ static long memory_exchange(XEN_GUEST_HA
             gfn =3D mfn_to_gmfn(d, mfn);
             /* Pages were unshared above */
             BUG_ON(SHARED_M2P(gfn));
-            guest_physmap_remove_page(d, gfn, mfn, PAGE_ORDER_4K);
+            guest_physmap_remove_page(d, gfn, mfn, 0);
             put_page(page);
         }
=20
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -95,7 +95,7 @@ static inline void *cli_get_page(tmem_cl
     return NULL;
 }
=20
-static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
+static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t =
*cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     ASSERT(0);
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -532,6 +532,7 @@ extern u64 translate_domain_pte(u64 ptev
 				u64* itir, struct p2m_entry* entry);
 #define machine_to_phys_mapping	mpt_table
=20
+#define INVALID_GFN              (~0UL)
 #define INVALID_M2P_ENTRY        (~0UL)
 #define VALID_M2P(_e)            (!((_e) & (1UL<<63)))
 #define SHARED_M2P(_e)           0




--=__Part012E892A.2__=
Content-Type: text/plain; name="ia64-build.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ia64-build.patch"

ia64: build fixes (again)=0A=0AThis undoes a single change from c/s =
24136:3622d7fae14d=0A(common/grant_table.c) and several from c/s 24100:be8d=
af78856a=0A(common/memory.c). It also completes the former with two =
previously=0Amissing ia64 specific code adjustments. Authors Cc-ed.=0A=0ASi=
gned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/grant_ta=
ble.c=0A+++ b/xen/common/grant_table.c=0A@@ -173,7 +173,7 @@ static int =
__get_paged_frame(unsigned lo=0A        rc =3D GNTST_bad_page;=0A     }=0A =
#else=0A-    *frame =3D readonly ? get_gfn_untyped(rd, gfn) : gfn_to_mfn_pr=
ivate(rd, gfn);=0A+    *frame =3D readonly ? gmfn_to_mfn(rd, gfn) : =
gfn_to_mfn_private(rd, gfn);=0A #endif=0A =0A     return rc;=0A--- =
a/xen/common/memory.c=0A+++ b/xen/common/memory.c=0A@@ -165,7 +165,7 @@ =
int guest_remove_page(struct domain *d, =0A     mfn =3D mfn_x(get_gfn(d, =
gmfn, &p2mt)); =0A     if ( unlikely(p2m_is_paging(p2mt)) )=0A     {=0A-   =
     guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);=0A+        =
guest_physmap_remove_page(d, gmfn, mfn, 0);=0A         p2m_mem_paging_drop_=
page(d, gmfn);=0A         put_gfn(d, gmfn);=0A         return 1;=0A@@ =
-188,7 +188,7 @@ int guest_remove_page(struct domain *d, =0A     if(p2m_is_=
shared(p2mt))=0A     {=0A         put_page_and_type(page);=0A-        =
guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);=0A+        =
guest_physmap_remove_page(d, gmfn, mfn, 0);=0A         put_gfn(d, =
gmfn);=0A         return 1;=0A     }=0A@@ -207,7 +207,7 @@ int guest_remove=
_page(struct domain *d, =0A     if ( test_and_clear_bit(_PGC_allocated, =
&page->count_info) )=0A         put_page(page);=0A =0A-    guest_physmap_re=
move_page(d, gmfn, mfn, PAGE_ORDER_4K);=0A+    guest_physmap_remove_page(d,=
 gmfn, mfn, 0);=0A =0A     put_page(page);=0A     put_gfn(d, gmfn);=0A@@ =
-427,7 +427,7 @@ static long memory_exchange(XEN_GUEST_HA=0A             =
gfn =3D mfn_to_gmfn(d, mfn);=0A             /* Pages were unshared above =
*/=0A             BUG_ON(SHARED_M2P(gfn));=0A-            guest_physmap_rem=
ove_page(d, gfn, mfn, PAGE_ORDER_4K);=0A+            guest_physmap_remove_p=
age(d, gfn, mfn, 0);=0A             put_page(page);=0A         }=0A =0A--- =
a/xen/common/tmem_xen.c=0A+++ b/xen/common/tmem_xen.c=0A@@ -95,7 +95,7 @@ =
static inline void *cli_get_page(tmem_cl=0A     return NULL;=0A }=0A =
=0A-static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,=0A+static=
 inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t =
*cli_pfp,=0A                                 unsigned long cli_mfn, bool_t =
mark_dirty)=0A {=0A     ASSERT(0);=0A--- a/xen/include/asm-ia64/mm.h=0A+++ =
b/xen/include/asm-ia64/mm.h=0A@@ -532,6 +532,7 @@ extern u64 translate_doma=
in_pte(u64 ptev=0A 				u64* itir, struct =
p2m_entry* entry);=0A #define machine_to_phys_mapping	mpt_table=0A =
=0A+#define INVALID_GFN              (~0UL)=0A #define INVALID_M2P_ENTRY   =
     (~0UL)=0A #define VALID_M2P(_e)            (!((_e) & (1UL<<63)))=0A =
#define SHARED_M2P(_e)           0=0A
--=__Part012E892A.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part012E892A.2__=--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:04:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:04:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSspw-00028u-Lg; Tue, 22 Nov 2011 16:04:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSspv-00028g-Qq
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:04:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321977854!4162232!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6201 invoked from network); 22 Nov 2011 16:04:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:04:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9069436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 16:04:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 16:04:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSspS-0005Hu-FD; Tue, 22 Nov 2011 16:04:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSspS-0005hp-9Q;
	Tue, 22 Nov 2011 16:04:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.51198.221057.507056@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 16:04:14 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK511W3q3YA+wFv=AJxqFQAFyaChRXuBCd_Sh=kMz6yQ8Q@mail.gmail.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1320055865.23193.45.camel@zakaz.uk.xensource.com>
	<CAPLaKK511W3q3YA+wFv=AJxqFQAFyaChRXuBCd_Sh=kMz6yQ8Q@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 00/13] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH RFC v2 00/13] New event A=
PI"):
> I'm sorry to ask such a noobish question... I'm trying to import this
> patches into my source tree, but mimport seems to be unable to
> correctly sort them (maybe because they seem to be in git format).
> What's the best way to import them directly from my mailbox?

I'm afraid I don't know.  With my upstream hat on, for applying
patches, I have an absolutely hideous script.  (Below but don't read
it if you want to keep your lunch.)  With my contributor hat on I
almost always use git.

Ian.


#!/bin/bash
set -e

file=3D$1

perl -pe <$file >$file.mangled '
        BEGIN { $nl=3D""; }
        if (m/^\S/ || m/^$/) {
                if (defined $subj) {
                        die "$subj ?" if $subj =3D~ m/rfc/i;
                        $subj =3D~ s/\[xen-devel\]//i;
                        $subj =3D~ s/\[patch[ 0-9a-z,]*\]//i;
                        $subj =3D~ s/\s+/ /g;
                        $subj =3D~ s/^\s+//; $subj =3D~ s/\s+$//;
                        print "Subject: $subj\n";
                        $subj=3D undef;
                        $nl=3D "\n";
                }
        }
        if (m/^subject:\s+/i) {
                $subj=3D $'\'';
        } elsif (defined $subj) {
                $subj .=3D $_;
        }
        if (m/^$/) {
                print $nl;
                $nl=3D "";
        }
        $_=3D"" if defined $subj;
        if ($last =3D~ m/^signed-off-by/i && !m/^signed-off-by/i) {
                print <<END or die $!;
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
END
#Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
#
#Acked-by: Ian Campbell <ian.campbell@citrix.com>
        }
        $last=3D $_;
'


formail -s hg import - < $file.mangled

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:04:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:04:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSspw-00028u-Lg; Tue, 22 Nov 2011 16:04:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSspv-00028g-Qq
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:04:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321977854!4162232!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6201 invoked from network); 22 Nov 2011 16:04:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:04:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9069436"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 16:04:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 16:04:14 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSspS-0005Hu-FD; Tue, 22 Nov 2011 16:04:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSspS-0005hp-9Q;
	Tue, 22 Nov 2011 16:04:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.51198.221057.507056@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 16:04:14 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK511W3q3YA+wFv=AJxqFQAFyaChRXuBCd_Sh=kMz6yQ8Q@mail.gmail.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1320055865.23193.45.camel@zakaz.uk.xensource.com>
	<CAPLaKK511W3q3YA+wFv=AJxqFQAFyaChRXuBCd_Sh=kMz6yQ8Q@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 00/13] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH RFC v2 00/13] New event A=
PI"):
> I'm sorry to ask such a noobish question... I'm trying to import this
> patches into my source tree, but mimport seems to be unable to
> correctly sort them (maybe because they seem to be in git format).
> What's the best way to import them directly from my mailbox?

I'm afraid I don't know.  With my upstream hat on, for applying
patches, I have an absolutely hideous script.  (Below but don't read
it if you want to keep your lunch.)  With my contributor hat on I
almost always use git.

Ian.


#!/bin/bash
set -e

file=3D$1

perl -pe <$file >$file.mangled '
        BEGIN { $nl=3D""; }
        if (m/^\S/ || m/^$/) {
                if (defined $subj) {
                        die "$subj ?" if $subj =3D~ m/rfc/i;
                        $subj =3D~ s/\[xen-devel\]//i;
                        $subj =3D~ s/\[patch[ 0-9a-z,]*\]//i;
                        $subj =3D~ s/\s+/ /g;
                        $subj =3D~ s/^\s+//; $subj =3D~ s/\s+$//;
                        print "Subject: $subj\n";
                        $subj=3D undef;
                        $nl=3D "\n";
                }
        }
        if (m/^subject:\s+/i) {
                $subj=3D $'\'';
        } elsif (defined $subj) {
                $subj .=3D $_;
        }
        if (m/^$/) {
                print $nl;
                $nl=3D "";
        }
        $_=3D"" if defined $subj;
        if ($last =3D~ m/^signed-off-by/i && !m/^signed-off-by/i) {
                print <<END or die $!;
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
END
#Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
#
#Acked-by: Ian Campbell <ian.campbell@citrix.com>
        }
        $last=3D $_;
'


formail -s hg import - < $file.mangled

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:13:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsyb-0002Lv-63; Tue, 22 Nov 2011 16:13:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSsyZ-0002Lo-V1
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:13:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321978348!57831432!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 560 invoked from network); 22 Nov 2011 16:12:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:12:28 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9069739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 16:13:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 16:13:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSsy6-0005L6-8e; Tue, 22 Nov 2011 16:13:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSsy6-0006Pt-7w;
	Tue, 22 Nov 2011 16:13:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.51734.234722.838125@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 16:13:10 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111071715450.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111071715450.3519@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] qemu-xen: add vkbd support for PV on HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] qemu-xen: add vkbd support for PV on HVM guests"):
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Applied, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:13:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSsyb-0002Lv-63; Tue, 22 Nov 2011 16:13:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSsyZ-0002Lo-V1
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:13:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321978348!57831432!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 560 invoked from network); 22 Nov 2011 16:12:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:12:28 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9069739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 16:13:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 16:13:10 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSsy6-0005L6-8e; Tue, 22 Nov 2011 16:13:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSsy6-0006Pt-7w;
	Tue, 22 Nov 2011 16:13:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.51734.234722.838125@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 16:13:10 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111071715450.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111071715450.3519@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] qemu-xen: add vkbd support for PV on HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] qemu-xen: add vkbd support for PV on HVM guests"):
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Applied, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:14:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSszC-0002Nz-Jf; Tue, 22 Nov 2011 16:14:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSszB-0002Ni-9L
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:14:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321978428!4526487!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22841 invoked from network); 22 Nov 2011 16:13:48 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:13:48 -0000
Received: by faan24 with SMTP id n24so767816faa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 08:13:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=fJzeSYEN91n0NpUUnYNicBVOTWnI1+GJBmb1GCWdjQ8=;
	b=fy/cXRegy6syXzVvDN6jQjLTvsSqvr/suZ4us0GvCcK/glwU7l1wsp1ffoR7Sajanp
	MdG0veyDqG1gpHNj2HIainAmpgR6syAaqFf98PFcOVMd25UcqjE+Wa8ENDqoe50ijk+i
	cAVNSUQH8ZWgONvlVXKrlotchZG1Q+u8ZK7Z8=
Received: by 10.180.91.137 with SMTP id ce9mr8764489wib.5.1321978428231;
	Tue, 22 Nov 2011 08:13:48 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id y3sm6891806wiy.3.2011.11.22.08.13.42
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 08:13:48 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 16:13:40 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAF17AB4.34848%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] move pci_find_ext_capability() into common
	PCI code
Thread-Index: AcypMbJ+PQVCrVsaFUiLSpi5sM/sFw==
In-Reply-To: <4ECBD3920200007800062617@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] move pci_find_ext_capability() into common
 PCI code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:

> There's nothing architecture specific about it. It requires, however,
> that x86-32's pci_conf_read32() tolerates register accesses above 255
> (for consistency the adjustment is done to all pci_conf_readNN()
> functions).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/ia64/xen/pci.c
> +++ b/xen/arch/ia64/xen/pci.c
> @@ -135,8 +135,3 @@ void pci_conf_write32(
>      BUG_ON((seg > 65535) || (bus > 255) || (dev > 31) || (func > 7) || (reg >
> 255));
>      pci_sal_write(seg, bus, (dev<<3)|func, reg, 4, data);
>  }
> -
> -int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
> -{
> -    return 0;
> -}
> --- a/xen/arch/x86/x86_32/pci.c
> +++ b/xen/arch/x86/x86_32/pci.c
> @@ -15,9 +15,9 @@ uint8_t pci_conf_read8(
>      unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
>      unsigned int reg)
>  {
> -    if ( seg )
> +    if ( seg || (reg > 255) )
>          return ~0;
> -    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
> +    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
>      return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 3, 1);
>  }
>  
> @@ -25,9 +25,9 @@ uint16_t pci_conf_read16(
>      unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
>      unsigned int reg)
>  {
> -    if ( seg )
> +    if ( seg || (reg > 255) )
>          return ~0;
> -    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
> +    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
>      return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 2, 2);
>  }
>  
> @@ -35,9 +35,9 @@ uint32_t pci_conf_read32(
>      unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
>      unsigned int reg)
>  {
> -    if ( seg )
> +    if ( seg || (reg > 255) )
>          return ~0;
> -    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
> +    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
>      return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4);
>  }
>  
> @@ -70,8 +70,3 @@ void pci_conf_write32(
>      BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
>      pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
>  }
> -
> -int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
> -{
> -    return 0;
> -}
> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
> +++ b/xen/arch/x86/x86_64/mmconfig-shared.c
> @@ -450,43 +450,3 @@ int pci_mmcfg_reserved(uint64_t address,
>  
>      return -ENODEV;
>  }
> -
> -/**
> - * pci_find_ext_capability - Find an extended capability
> - * @dev: PCI device to query
> - * @cap: capability code
> - *
> - * Returns the address of the requested extended capability structure
> - * within the device's PCI configuration space or 0 if the device does
> - * not support it.  Possible values for @cap:
> - *
> - *  %PCI_EXT_CAP_ID_ERR         Advanced Error Reporting
> - *  %PCI_EXT_CAP_ID_VC          Virtual Channel
> - *  %PCI_EXT_CAP_ID_DSN         Device Serial Number
> - *  %PCI_EXT_CAP_ID_PWR         Power Budgeting
> - */
> -int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
> -{
> -    u32 header;
> -    int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */
> -    int pos = 0x100;
> -
> -    header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> pos);
> -
> -    /*
> -     * If we have no capabilities, this is indicated by cap ID,
> -     * cap version and next pointer all being 0.
> -     */
> -    if ( (header == 0) || (header == -1) )
> -        return 0;
> -
> -    while ( ttl-- > 0 ) {
> -        if ( PCI_EXT_CAP_ID(header) == cap )
> -            return pos;
> -        pos = PCI_EXT_CAP_NEXT(header);
> -        if ( pos < 0x100 )
> -            break;
> -        header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> pos);
> -    }
> -    return 0;
> -}
> --- a/xen/drivers/pci/pci.c
> +++ b/xen/drivers/pci/pci.c
> @@ -62,3 +62,43 @@ int pci_find_next_cap(u16 seg, u8 bus, u
>      }
>      return 0;
>  }
> +
> +/**
> + * pci_find_ext_capability - Find an extended capability
> + * @dev: PCI device to query
> + * @cap: capability code
> + *
> + * Returns the address of the requested extended capability structure
> + * within the device's PCI configuration space or 0 if the device does
> + * not support it.  Possible values for @cap:
> + *
> + *  %PCI_EXT_CAP_ID_ERR         Advanced Error Reporting
> + *  %PCI_EXT_CAP_ID_VC          Virtual Channel
> + *  %PCI_EXT_CAP_ID_DSN         Device Serial Number
> + *  %PCI_EXT_CAP_ID_PWR         Power Budgeting
> + */
> +int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
> +{
> +    u32 header;
> +    int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */
> +    int pos = 0x100;
> +
> +    header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> pos);
> +
> +    /*
> +     * If we have no capabilities, this is indicated by cap ID,
> +     * cap version and next pointer all being 0.
> +     */
> +    if ( (header == 0) || (header == -1) )
> +        return 0;
> +
> +    while ( ttl-- > 0 ) {
> +        if ( PCI_EXT_CAP_ID(header) == cap )
> +            return pos;
> +        pos = PCI_EXT_CAP_NEXT(header);
> +        if ( pos < 0x100 )
> +            break;
> +        header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> pos);
> +    }
> +    return 0;
> +}
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:14:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:14:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSszC-0002Nz-Jf; Tue, 22 Nov 2011 16:14:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSszB-0002Ni-9L
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:14:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1321978428!4526487!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22841 invoked from network); 22 Nov 2011 16:13:48 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:13:48 -0000
Received: by faan24 with SMTP id n24so767816faa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 08:13:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=fJzeSYEN91n0NpUUnYNicBVOTWnI1+GJBmb1GCWdjQ8=;
	b=fy/cXRegy6syXzVvDN6jQjLTvsSqvr/suZ4us0GvCcK/glwU7l1wsp1ffoR7Sajanp
	MdG0veyDqG1gpHNj2HIainAmpgR6syAaqFf98PFcOVMd25UcqjE+Wa8ENDqoe50ijk+i
	cAVNSUQH8ZWgONvlVXKrlotchZG1Q+u8ZK7Z8=
Received: by 10.180.91.137 with SMTP id ce9mr8764489wib.5.1321978428231;
	Tue, 22 Nov 2011 08:13:48 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id y3sm6891806wiy.3.2011.11.22.08.13.42
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 08:13:48 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 16:13:40 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAF17AB4.34848%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] move pci_find_ext_capability() into common
	PCI code
Thread-Index: AcypMbJ+PQVCrVsaFUiLSpi5sM/sFw==
In-Reply-To: <4ECBD3920200007800062617@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] move pci_find_ext_capability() into common
 PCI code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 15:53, "Jan Beulich" <JBeulich@suse.com> wrote:

> There's nothing architecture specific about it. It requires, however,
> that x86-32's pci_conf_read32() tolerates register accesses above 255
> (for consistency the adjustment is done to all pci_conf_readNN()
> functions).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/ia64/xen/pci.c
> +++ b/xen/arch/ia64/xen/pci.c
> @@ -135,8 +135,3 @@ void pci_conf_write32(
>      BUG_ON((seg > 65535) || (bus > 255) || (dev > 31) || (func > 7) || (reg >
> 255));
>      pci_sal_write(seg, bus, (dev<<3)|func, reg, 4, data);
>  }
> -
> -int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
> -{
> -    return 0;
> -}
> --- a/xen/arch/x86/x86_32/pci.c
> +++ b/xen/arch/x86/x86_32/pci.c
> @@ -15,9 +15,9 @@ uint8_t pci_conf_read8(
>      unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
>      unsigned int reg)
>  {
> -    if ( seg )
> +    if ( seg || (reg > 255) )
>          return ~0;
> -    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
> +    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
>      return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 3, 1);
>  }
>  
> @@ -25,9 +25,9 @@ uint16_t pci_conf_read16(
>      unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
>      unsigned int reg)
>  {
> -    if ( seg )
> +    if ( seg || (reg > 255) )
>          return ~0;
> -    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
> +    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
>      return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), reg & 2, 2);
>  }
>  
> @@ -35,9 +35,9 @@ uint32_t pci_conf_read32(
>      unsigned int seg, unsigned int bus, unsigned int dev, unsigned int func,
>      unsigned int reg)
>  {
> -    if ( seg )
> +    if ( seg || (reg > 255) )
>          return ~0;
> -    BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
> +    BUG_ON((bus > 255) || (dev > 31) || (func > 7));
>      return pci_conf_read(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4);
>  }
>  
> @@ -70,8 +70,3 @@ void pci_conf_write32(
>      BUG_ON((bus > 255) || (dev > 31) || (func > 7) || (reg > 255));
>      pci_conf_write(PCI_CONF_ADDRESS(bus, dev, func, reg), 0, 4, data);
>  }
> -
> -int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
> -{
> -    return 0;
> -}
> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
> +++ b/xen/arch/x86/x86_64/mmconfig-shared.c
> @@ -450,43 +450,3 @@ int pci_mmcfg_reserved(uint64_t address,
>  
>      return -ENODEV;
>  }
> -
> -/**
> - * pci_find_ext_capability - Find an extended capability
> - * @dev: PCI device to query
> - * @cap: capability code
> - *
> - * Returns the address of the requested extended capability structure
> - * within the device's PCI configuration space or 0 if the device does
> - * not support it.  Possible values for @cap:
> - *
> - *  %PCI_EXT_CAP_ID_ERR         Advanced Error Reporting
> - *  %PCI_EXT_CAP_ID_VC          Virtual Channel
> - *  %PCI_EXT_CAP_ID_DSN         Device Serial Number
> - *  %PCI_EXT_CAP_ID_PWR         Power Budgeting
> - */
> -int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
> -{
> -    u32 header;
> -    int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */
> -    int pos = 0x100;
> -
> -    header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> pos);
> -
> -    /*
> -     * If we have no capabilities, this is indicated by cap ID,
> -     * cap version and next pointer all being 0.
> -     */
> -    if ( (header == 0) || (header == -1) )
> -        return 0;
> -
> -    while ( ttl-- > 0 ) {
> -        if ( PCI_EXT_CAP_ID(header) == cap )
> -            return pos;
> -        pos = PCI_EXT_CAP_NEXT(header);
> -        if ( pos < 0x100 )
> -            break;
> -        header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> pos);
> -    }
> -    return 0;
> -}
> --- a/xen/drivers/pci/pci.c
> +++ b/xen/drivers/pci/pci.c
> @@ -62,3 +62,43 @@ int pci_find_next_cap(u16 seg, u8 bus, u
>      }
>      return 0;
>  }
> +
> +/**
> + * pci_find_ext_capability - Find an extended capability
> + * @dev: PCI device to query
> + * @cap: capability code
> + *
> + * Returns the address of the requested extended capability structure
> + * within the device's PCI configuration space or 0 if the device does
> + * not support it.  Possible values for @cap:
> + *
> + *  %PCI_EXT_CAP_ID_ERR         Advanced Error Reporting
> + *  %PCI_EXT_CAP_ID_VC          Virtual Channel
> + *  %PCI_EXT_CAP_ID_DSN         Device Serial Number
> + *  %PCI_EXT_CAP_ID_PWR         Power Budgeting
> + */
> +int pci_find_ext_capability(int seg, int bus, int devfn, int cap)
> +{
> +    u32 header;
> +    int ttl = 480; /* 3840 bytes, minimum 8 bytes per capability */
> +    int pos = 0x100;
> +
> +    header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> pos);
> +
> +    /*
> +     * If we have no capabilities, this is indicated by cap ID,
> +     * cap version and next pointer all being 0.
> +     */
> +    if ( (header == 0) || (header == -1) )
> +        return 0;
> +
> +    while ( ttl-- > 0 ) {
> +        if ( PCI_EXT_CAP_ID(header) == cap )
> +            return pos;
> +        pos = PCI_EXT_CAP_NEXT(header);
> +        if ( pos < 0x100 )
> +            break;
> +        header = pci_conf_read32(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> pos);
> +    }
> +    return 0;
> +}
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:15:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:15:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSt0T-0002Tp-2X; Tue, 22 Nov 2011 16:15:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSt0Q-0002TJ-Nt
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:15:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321978505!2592742!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27720 invoked from network); 22 Nov 2011 16:15:05 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:15:05 -0000
Received: by wwo1 with SMTP id 1so193928wwo.24
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 08:15:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7qC5Pn50qZkXUqSMywkn0EAAFQPZ4KqZaDAlrjKPDZA=;
	b=RYMhq9Ha+3J498yphfcTWX3UA35CB5nrBvNs/w0WrfB+qm4jdEzIqbCD7+OLdJwEww
	z8kNRRc2tlzebxhUcUMbRDBuL9LkpSfLqY1LxyxNthcHHs6xEKGrXD4TZgvXIZypW9jq
	99RXbdhSezTHGAKOB273sDpUndATGcvqooJRo=
Received: by 10.227.205.135 with SMTP id fq7mr12504657wbb.19.1321978505397;
	Tue, 22 Nov 2011 08:15:05 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id y3sm6893385wiy.3.2011.11.22.08.15.04
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 08:15:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 16:15:02 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAF17B06.34849%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ia64: build fixes (again)
Thread-Index: AcypMeNeDyaGO0YKgUKmmgL2ejN+3g==
In-Reply-To: <4ECBD44A020000780006261B@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:

> This undoes a single change from c/s 24136:3622d7fae14d
> (common/grant_table.c) and several from c/s 24100:be8daf78856a
> (common/memory.c). It also completes the former with two previously
> missing ia64 specific code adjustments. Authors Cc-ed.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I'm not going to Ack IA64 patches. Unless there is someone on the IA64 side
to do so (which apparently there isn't) you can just go ahead and check
these fixup patches in, unless you think a specific patch needs someone
else's Ack.

 -- Keir

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -173,7 +173,7 @@ static int __get_paged_frame(unsigned lo
>         rc = GNTST_bad_page;
>      }
>  #else
> -    *frame = readonly ? get_gfn_untyped(rd, gfn) : gfn_to_mfn_private(rd,
> gfn);
> +    *frame = readonly ? gmfn_to_mfn(rd, gfn) : gfn_to_mfn_private(rd, gfn);
>  #endif
>  
>      return rc;
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -165,7 +165,7 @@ int guest_remove_page(struct domain *d,
>      mfn = mfn_x(get_gfn(d, gmfn, &p2mt));
>      if ( unlikely(p2m_is_paging(p2mt)) )
>      {
> -        guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
> +        guest_physmap_remove_page(d, gmfn, mfn, 0);
>          p2m_mem_paging_drop_page(d, gmfn);
>          put_gfn(d, gmfn);
>          return 1;
> @@ -188,7 +188,7 @@ int guest_remove_page(struct domain *d,
>      if(p2m_is_shared(p2mt))
>      {
>          put_page_and_type(page);
> -        guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
> +        guest_physmap_remove_page(d, gmfn, mfn, 0);
>          put_gfn(d, gmfn);
>          return 1;
>      }
> @@ -207,7 +207,7 @@ int guest_remove_page(struct domain *d,
>      if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
>          put_page(page);
>  
> -    guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
> +    guest_physmap_remove_page(d, gmfn, mfn, 0);
>  
>      put_page(page);
>      put_gfn(d, gmfn);
> @@ -427,7 +427,7 @@ static long memory_exchange(XEN_GUEST_HA
>              gfn = mfn_to_gmfn(d, mfn);
>              /* Pages were unshared above */
>              BUG_ON(SHARED_M2P(gfn));
> -            guest_physmap_remove_page(d, gfn, mfn, PAGE_ORDER_4K);
> +            guest_physmap_remove_page(d, gfn, mfn, 0);
>              put_page(page);
>          }
>  
> --- a/xen/common/tmem_xen.c
> +++ b/xen/common/tmem_xen.c
> @@ -95,7 +95,7 @@ static inline void *cli_get_page(tmem_cl
>      return NULL;
>  }
>  
> -static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
> +static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t
> *cli_pfp,
>                                  unsigned long cli_mfn, bool_t mark_dirty)
>  {
>      ASSERT(0);
> --- a/xen/include/asm-ia64/mm.h
> +++ b/xen/include/asm-ia64/mm.h
> @@ -532,6 +532,7 @@ extern u64 translate_domain_pte(u64 ptev
> u64* itir, struct p2m_entry* entry);
>  #define machine_to_phys_mapping mpt_table
>  
> +#define INVALID_GFN              (~0UL)
>  #define INVALID_M2P_ENTRY        (~0UL)
>  #define VALID_M2P(_e)            (!((_e) & (1UL<<63)))
>  #define SHARED_M2P(_e)           0
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:15:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:15:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSt0T-0002Tp-2X; Tue, 22 Nov 2011 16:15:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSt0Q-0002TJ-Nt
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:15:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321978505!2592742!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27720 invoked from network); 22 Nov 2011 16:15:05 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:15:05 -0000
Received: by wwo1 with SMTP id 1so193928wwo.24
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 08:15:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7qC5Pn50qZkXUqSMywkn0EAAFQPZ4KqZaDAlrjKPDZA=;
	b=RYMhq9Ha+3J498yphfcTWX3UA35CB5nrBvNs/w0WrfB+qm4jdEzIqbCD7+OLdJwEww
	z8kNRRc2tlzebxhUcUMbRDBuL9LkpSfLqY1LxyxNthcHHs6xEKGrXD4TZgvXIZypW9jq
	99RXbdhSezTHGAKOB273sDpUndATGcvqooJRo=
Received: by 10.227.205.135 with SMTP id fq7mr12504657wbb.19.1321978505397;
	Tue, 22 Nov 2011 08:15:05 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id y3sm6893385wiy.3.2011.11.22.08.15.04
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 08:15:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 16:15:02 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAF17B06.34849%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ia64: build fixes (again)
Thread-Index: AcypMeNeDyaGO0YKgUKmmgL2ejN+3g==
In-Reply-To: <4ECBD44A020000780006261B@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:

> This undoes a single change from c/s 24136:3622d7fae14d
> (common/grant_table.c) and several from c/s 24100:be8daf78856a
> (common/memory.c). It also completes the former with two previously
> missing ia64 specific code adjustments. Authors Cc-ed.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I'm not going to Ack IA64 patches. Unless there is someone on the IA64 side
to do so (which apparently there isn't) you can just go ahead and check
these fixup patches in, unless you think a specific patch needs someone
else's Ack.

 -- Keir

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -173,7 +173,7 @@ static int __get_paged_frame(unsigned lo
>         rc = GNTST_bad_page;
>      }
>  #else
> -    *frame = readonly ? get_gfn_untyped(rd, gfn) : gfn_to_mfn_private(rd,
> gfn);
> +    *frame = readonly ? gmfn_to_mfn(rd, gfn) : gfn_to_mfn_private(rd, gfn);
>  #endif
>  
>      return rc;
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -165,7 +165,7 @@ int guest_remove_page(struct domain *d,
>      mfn = mfn_x(get_gfn(d, gmfn, &p2mt));
>      if ( unlikely(p2m_is_paging(p2mt)) )
>      {
> -        guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
> +        guest_physmap_remove_page(d, gmfn, mfn, 0);
>          p2m_mem_paging_drop_page(d, gmfn);
>          put_gfn(d, gmfn);
>          return 1;
> @@ -188,7 +188,7 @@ int guest_remove_page(struct domain *d,
>      if(p2m_is_shared(p2mt))
>      {
>          put_page_and_type(page);
> -        guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
> +        guest_physmap_remove_page(d, gmfn, mfn, 0);
>          put_gfn(d, gmfn);
>          return 1;
>      }
> @@ -207,7 +207,7 @@ int guest_remove_page(struct domain *d,
>      if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
>          put_page(page);
>  
> -    guest_physmap_remove_page(d, gmfn, mfn, PAGE_ORDER_4K);
> +    guest_physmap_remove_page(d, gmfn, mfn, 0);
>  
>      put_page(page);
>      put_gfn(d, gmfn);
> @@ -427,7 +427,7 @@ static long memory_exchange(XEN_GUEST_HA
>              gfn = mfn_to_gmfn(d, mfn);
>              /* Pages were unshared above */
>              BUG_ON(SHARED_M2P(gfn));
> -            guest_physmap_remove_page(d, gfn, mfn, PAGE_ORDER_4K);
> +            guest_physmap_remove_page(d, gfn, mfn, 0);
>              put_page(page);
>          }
>  
> --- a/xen/common/tmem_xen.c
> +++ b/xen/common/tmem_xen.c
> @@ -95,7 +95,7 @@ static inline void *cli_get_page(tmem_cl
>      return NULL;
>  }
>  
> -static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
> +static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t
> *cli_pfp,
>                                  unsigned long cli_mfn, bool_t mark_dirty)
>  {
>      ASSERT(0);
> --- a/xen/include/asm-ia64/mm.h
> +++ b/xen/include/asm-ia64/mm.h
> @@ -532,6 +532,7 @@ extern u64 translate_domain_pte(u64 ptev
> u64* itir, struct p2m_entry* entry);
>  #define machine_to_phys_mapping mpt_table
>  
> +#define INVALID_GFN              (~0UL)
>  #define INVALID_M2P_ENTRY        (~0UL)
>  #define VALID_M2P(_e)            (!((_e) & (1UL<<63)))
>  #define SHARED_M2P(_e)           0
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:20:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSt57-0002nS-2U; Tue, 22 Nov 2011 16:20:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSt56-0002nC-0n
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:20:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321978795!4165333!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29197 invoked from network); 22 Nov 2011 16:19:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:19:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9069926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 16:19:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 16:19:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSt4c-0005NY-AT; Tue, 22 Nov 2011 16:19:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSt4c-0006Te-9l;
	Tue, 22 Nov 2011 16:19:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.52138.290758.909099@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 16:19:54 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111081216030.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111081216030.3519@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add a vkbd frontend/backend pair for HVM
	guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH] Add a vkbd frontend/backend pair for HVM guests"):
> Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend pair
> for HVM guests by default.
> It is useful because it doesn't require frequent qemu wakeups as the usb
> keyboard/mouse does.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:20:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSt57-0002nS-2U; Tue, 22 Nov 2011 16:20:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSt56-0002nC-0n
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:20:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321978795!4165333!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29197 invoked from network); 22 Nov 2011 16:19:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:19:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9069926"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 16:19:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 16:19:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSt4c-0005NY-AT; Tue, 22 Nov 2011 16:19:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSt4c-0006Te-9l;
	Tue, 22 Nov 2011 16:19:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.52138.290758.909099@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 16:19:54 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111081216030.3519@kaball-desktop>
References: <alpine.DEB.2.00.1111081216030.3519@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add a vkbd frontend/backend pair for HVM
	guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("[Xen-devel] [PATCH] Add a vkbd frontend/backend pair for HVM guests"):
> Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend pair
> for HVM guests by default.
> It is useful because it doesn't require frequent qemu wakeups as the usb
> keyboard/mouse does.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:21:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:21:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSt5y-0002rk-H7; Tue, 22 Nov 2011 16:21:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSt5x-0002r3-68
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:21:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1321978847!5277909!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11180 invoked from network); 22 Nov 2011 16:20:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 16:20:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 22 Nov 2011 16:20:47 +0000
Message-Id: <4ECBD9EC020000780006266C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 22 Nov 2011 16:20:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4ECBD44A020000780006261B@nat28.tlf.novell.com>
	<CAF17B06.34849%keir@xen.org>
In-Reply-To: <CAF17B06.34849%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 17:15, Keir Fraser <keir@xen.org> wrote:
> On 22/11/2011 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> This undoes a single change from c/s 24136:3622d7fae14d
>> (common/grant_table.c) and several from c/s 24100:be8daf78856a
>> (common/memory.c). It also completes the former with two previously
>> missing ia64 specific code adjustments. Authors Cc-ed.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> I'm not going to Ack IA64 patches. Unless there is someone on the IA64 side
> to do so (which apparently there isn't) you can just go ahead and check
> these fixup patches in, unless you think a specific patch needs someone
> else's Ack.

Okay. In this case, as I'm undoing changes done recently, I'll wait
a day or two to see whether either of the authors has any comments
on this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:21:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:21:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSt5y-0002rk-H7; Tue, 22 Nov 2011 16:21:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RSt5x-0002r3-68
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:21:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1321978847!5277909!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11180 invoked from network); 22 Nov 2011 16:20:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 16:20:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 22 Nov 2011 16:20:47 +0000
Message-Id: <4ECBD9EC020000780006266C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 22 Nov 2011 16:20:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <4ECBD44A020000780006261B@nat28.tlf.novell.com>
	<CAF17B06.34849%keir@xen.org>
In-Reply-To: <CAF17B06.34849%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 17:15, Keir Fraser <keir@xen.org> wrote:
> On 22/11/2011 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> This undoes a single change from c/s 24136:3622d7fae14d
>> (common/grant_table.c) and several from c/s 24100:be8daf78856a
>> (common/memory.c). It also completes the former with two previously
>> missing ia64 specific code adjustments. Authors Cc-ed.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> I'm not going to Ack IA64 patches. Unless there is someone on the IA64 side
> to do so (which apparently there isn't) you can just go ahead and check
> these fixup patches in, unless you think a specific patch needs someone
> else's Ack.

Okay. In this case, as I'm undoing changes done recently, I'll wait
a day or two to see whether either of the authors has any comments
on this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:28:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RStCJ-0003Dc-PH; Tue, 22 Nov 2011 16:27:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RStCI-0003DW-I0
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:27:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1321979241!4558512!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19063 invoked from network); 22 Nov 2011 16:27:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 16:27:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 22 Nov 2011 16:27:21 +0000
Message-Id: <4ECBDB750200007800062680@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 22 Nov 2011 16:27:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
 "Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 17:15, Keir Fraser <keir@xen.org> wrote:
> On 22/11/2011 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> This undoes a single change from c/s 24136:3622d7fae14d
>> (common/grant_table.c) and several from c/s 24100:be8daf78856a
>> (common/memory.c). It also completes the former with two previously
>> missing ia64 specific code adjustments. Authors Cc-ed.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> I'm not going to Ack IA64 patches. Unless there is someone on the IA64 side
> to do so (which apparently there isn't) you can just go ahead and check
> these fixup patches in, unless you think a specific patch needs someone
> else's Ack.

Oh, one more thing - would it be possible to add an ia64 build-only
test to the stage testing logic?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:28:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RStCJ-0003Dc-PH; Tue, 22 Nov 2011 16:27:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RStCI-0003DW-I0
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:27:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1321979241!4558512!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19063 invoked from network); 22 Nov 2011 16:27:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Nov 2011 16:27:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 22 Nov 2011 16:27:21 +0000
Message-Id: <4ECBDB750200007800062680@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 22 Nov 2011 16:27:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>,
 "Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 17:15, Keir Fraser <keir@xen.org> wrote:
> On 22/11/2011 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> This undoes a single change from c/s 24136:3622d7fae14d
>> (common/grant_table.c) and several from c/s 24100:be8daf78856a
>> (common/memory.c). It also completes the former with two previously
>> missing ia64 specific code adjustments. Authors Cc-ed.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> I'm not going to Ack IA64 patches. Unless there is someone on the IA64 side
> to do so (which apparently there isn't) you can just go ahead and check
> these fixup patches in, unless you think a specific patch needs someone
> else's Ack.

Oh, one more thing - would it be possible to add an ia64 build-only
test to the stage testing logic?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:33:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:33:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RStHi-0003OB-MR; Tue, 22 Nov 2011 16:33:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>)
	id 1RStHh-0003Ny-WD; Tue, 22 Nov 2011 16:33:26 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321979476!53239745!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13631 invoked from network); 22 Nov 2011 16:31:18 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:31:18 -0000
Received: by ggnr4 with SMTP id r4so554698ggn.30
	for <multiple recipients>; Tue, 22 Nov 2011 08:33:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=pr9WwiUKSg+TbJEV40OKoXsZs9oWLigla2UecvZnMng=;
	b=Lnq1YGKwi7KTQUgI9xL2akvXNIimuXPe4rCoiM3qgxwenR9fddTRQrQ6tEMCZABzGJ
	vrPP0n/0WpdFWhFzy2ttG6vJkQEUdF3vi5fAZ7e7QraAdrOktV1xzjC8EStGW4AsaPW0
	ShXflyo9u+UzqhcPhfmx4y0WRfCEyJdo67yDk=
MIME-Version: 1.0
Received: by 10.50.185.232 with SMTP id ff8mr22685160igc.32.1321979580142;
	Tue, 22 Nov 2011 08:33:00 -0800 (PST)
Received: by 10.231.62.1 with HTTP; Tue, 22 Nov 2011 08:33:00 -0800 (PST)
Date: Tue, 22 Nov 2011 17:33:00 +0100
Message-ID: <CAFivhPnnWLsrZ8sWbJUsOYbHfqEirNR2ODeL7xrYkWpSJksBpw@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: Xen Users <xen-users@lists.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] CentOS 5.4 jumps in time and shows 9999.99% CPU -
	anyone.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

(repost: the mailer daemon just ated the mail as described. I hope it was yummy)

I spend half an hour asking myself if this is for xen-users or -devel.
Since I can't decide I'll cross-post a little, hoping that the topic
catches only people who happend to have or fix this issue.:

I'm pretty amazed by one bug that I can't seem to pinpoint or get rid
of right now:
This is using old CentOS 5.4 with the 3.x Xen version that came with it.

Sometimes, without much reason, a domU will make a jump in time to the
future, by like 30 minutes to an hour.
This, as you could expect, breaks the OS quite badly. It stops most
processing until that point in time is reached and then
happily continues to work.
You can recognize it when all processes in top end up at 9999.99% cpu
usage, or by issueing date (examples follow)

There are NO related errors in dmesg or on the host. No others either.
reboot -f  inside the VM will not work any more once this happened, a
crash via sysrq does work.

There have been old reports of this issue, some, but not all in
combination with live migration, which we're not using.
In that case the restore functions overwrote the timer information, I
seem to be getting broken information instead. (wtf)
So live migration issue == fixed. Other issue == i don't know

If you look at this and ignore the comments from other people that
didn't have the same issue (i.e. they have a vmware timeacceleration
platform) then it makes me think this is something introduced with 5.4
https://www.centos.org/modules/newbb/viewtopic.php?topic_id=23402
(timmsteve and the thread starter)


I would like to fix the issue instead of switching to independent wallclock.
Reasons:
running independent wallclock uses up CPU time for nothing.
having one all VMs run using the time of one shared perfectly synced
clock just makes a lot more sense.

Backporting a patch to old Xen wouldn't worry me too much, I just need
to get a solution somehow.

I'm not sure what the bigger problem is right now:
Not finding a way to fix it, or not being able to reproduce it at will.
Either of this would make me glad right now.


OS CentOS 5.4
Upgrading the hosts would is possible, upgrading the VMs is *not*.

Real time:
Tue Nov 22 16:37:29  2011


Time / top displayed on the system, almost 20 minutes in the future.

top - 16:52:04 up 8 days,  3:41,  2 users,  load average: 0.25, 0.08, 0.02
Tasks:  87 total,   1 running,  86 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.9%us,  0.7%sy,  0.0%ni, 97.7%id,  0.1%wa,  0.0%hi,  0.1%si,  0.5%st
Mem:    524464k total,   514608k used,     9856k free,    53556k buffers
Swap:   522104k total,       52k used,   522052k free,    60292k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1380 xxx       15   0  194m  24m  12m S 9999.0  4.7  17:17.77 xxxx
   1 root      15   0  2088  732  628 S 9999.0  0.1   0:00.11 init
   2 root      RT  -5     0    0    0 S 9999.0  0.0   0:02.50
migration/0
   3 root      34  19     0    0    0 S 9999.0  0.0   0:00.00
ksoftirqd/0
   4 root      RT  -5     0    0    0 S 9999.0  0.0   0:00.00
watchdog/0
   5 root      10  -5     0    0    0 S 9999.0  0.0   0:00.05
events/0
   6 root      14  -5     0    0    0 S 9999.0  0.0   0:00.21 khelper
   7 root      11  -5     0    0    0 S 9999.0  0.0   0:00.00 kthread


Current Clocksource = jiffies
Independent wallclock = 0
permitted_clock_jitter = 10000000


Did anybody who had this issue *fix* it?
Is it *definitely* gone with indepent clocks?
Does CentOS / RedHat really have a QA team? :)

Going to read through the kernel-xen patches in 5.7 now :/

Thanks for reading / any help,
Florian

-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 16:33:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 16:33:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RStHi-0003OB-MR; Tue, 22 Nov 2011 16:33:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>)
	id 1RStHh-0003Ny-WD; Tue, 22 Nov 2011 16:33:26 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321979476!53239745!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13631 invoked from network); 22 Nov 2011 16:31:18 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:31:18 -0000
Received: by ggnr4 with SMTP id r4so554698ggn.30
	for <multiple recipients>; Tue, 22 Nov 2011 08:33:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:cc:content-type;
	bh=pr9WwiUKSg+TbJEV40OKoXsZs9oWLigla2UecvZnMng=;
	b=Lnq1YGKwi7KTQUgI9xL2akvXNIimuXPe4rCoiM3qgxwenR9fddTRQrQ6tEMCZABzGJ
	vrPP0n/0WpdFWhFzy2ttG6vJkQEUdF3vi5fAZ7e7QraAdrOktV1xzjC8EStGW4AsaPW0
	ShXflyo9u+UzqhcPhfmx4y0WRfCEyJdo67yDk=
MIME-Version: 1.0
Received: by 10.50.185.232 with SMTP id ff8mr22685160igc.32.1321979580142;
	Tue, 22 Nov 2011 08:33:00 -0800 (PST)
Received: by 10.231.62.1 with HTTP; Tue, 22 Nov 2011 08:33:00 -0800 (PST)
Date: Tue, 22 Nov 2011 17:33:00 +0100
Message-ID: <CAFivhPnnWLsrZ8sWbJUsOYbHfqEirNR2ODeL7xrYkWpSJksBpw@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: Xen Users <xen-users@lists.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] CentOS 5.4 jumps in time and shows 9999.99% CPU -
	anyone.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

(repost: the mailer daemon just ated the mail as described. I hope it was yummy)

I spend half an hour asking myself if this is for xen-users or -devel.
Since I can't decide I'll cross-post a little, hoping that the topic
catches only people who happend to have or fix this issue.:

I'm pretty amazed by one bug that I can't seem to pinpoint or get rid
of right now:
This is using old CentOS 5.4 with the 3.x Xen version that came with it.

Sometimes, without much reason, a domU will make a jump in time to the
future, by like 30 minutes to an hour.
This, as you could expect, breaks the OS quite badly. It stops most
processing until that point in time is reached and then
happily continues to work.
You can recognize it when all processes in top end up at 9999.99% cpu
usage, or by issueing date (examples follow)

There are NO related errors in dmesg or on the host. No others either.
reboot -f  inside the VM will not work any more once this happened, a
crash via sysrq does work.

There have been old reports of this issue, some, but not all in
combination with live migration, which we're not using.
In that case the restore functions overwrote the timer information, I
seem to be getting broken information instead. (wtf)
So live migration issue == fixed. Other issue == i don't know

If you look at this and ignore the comments from other people that
didn't have the same issue (i.e. they have a vmware timeacceleration
platform) then it makes me think this is something introduced with 5.4
https://www.centos.org/modules/newbb/viewtopic.php?topic_id=23402
(timmsteve and the thread starter)


I would like to fix the issue instead of switching to independent wallclock.
Reasons:
running independent wallclock uses up CPU time for nothing.
having one all VMs run using the time of one shared perfectly synced
clock just makes a lot more sense.

Backporting a patch to old Xen wouldn't worry me too much, I just need
to get a solution somehow.

I'm not sure what the bigger problem is right now:
Not finding a way to fix it, or not being able to reproduce it at will.
Either of this would make me glad right now.


OS CentOS 5.4
Upgrading the hosts would is possible, upgrading the VMs is *not*.

Real time:
Tue Nov 22 16:37:29  2011


Time / top displayed on the system, almost 20 minutes in the future.

top - 16:52:04 up 8 days,  3:41,  2 users,  load average: 0.25, 0.08, 0.02
Tasks:  87 total,   1 running,  86 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.9%us,  0.7%sy,  0.0%ni, 97.7%id,  0.1%wa,  0.0%hi,  0.1%si,  0.5%st
Mem:    524464k total,   514608k used,     9856k free,    53556k buffers
Swap:   522104k total,       52k used,   522052k free,    60292k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1380 xxx       15   0  194m  24m  12m S 9999.0  4.7  17:17.77 xxxx
   1 root      15   0  2088  732  628 S 9999.0  0.1   0:00.11 init
   2 root      RT  -5     0    0    0 S 9999.0  0.0   0:02.50
migration/0
   3 root      34  19     0    0    0 S 9999.0  0.0   0:00.00
ksoftirqd/0
   4 root      RT  -5     0    0    0 S 9999.0  0.0   0:00.00
watchdog/0
   5 root      10  -5     0    0    0 S 9999.0  0.0   0:00.05
events/0
   6 root      14  -5     0    0    0 S 9999.0  0.0   0:00.21 khelper
   7 root      11  -5     0    0    0 S 9999.0  0.0   0:00.00 kthread


Current Clocksource = jiffies
Independent wallclock = 0
permitted_clock_jitter = 10000000


Did anybody who had this issue *fix* it?
Is it *definitely* gone with indepent clocks?
Does CentOS / RedHat really have a QA team? :)

Going to read through the kernel-xen patches in 5.7 now :/

Thanks for reading / any help,
Florian

-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:09:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:09:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RStqQ-0004Ly-2I; Tue, 22 Nov 2011 17:09:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RStqO-0004Lr-TU
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:09:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321981728!4574215!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18851 invoked from network); 22 Nov 2011 17:08:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:08:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9071083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 17:08:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 17:08:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RStpv-0005fL-KA; Tue, 22 Nov 2011 17:08:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RStpv-0006c4-Hl;
	Tue, 22 Nov 2011 17:08:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.55071.538723.960939@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 17:08:47 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1320954713.16747.117.camel@dagon.hellion.org.uk>
References: <1320862287-11787-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1320862287-11787-2-git-send-email-dgdegra@tycho.nsa.gov>
	<1320954713.16747.117.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xenstat: Use local domain names
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2/2] xenstat: Use local domain names"):
> I wondered what xend does and it seems that it also creates
> both /local/domain/N/name and /vm/UUID/name but only updates the latter
> on "xm rename". So it seems that xend and xl behave exactly opposite wrt
> which one they change on rename. Leaving aside that it seems buggy to a)
> record the name twice and b) only update one copy on rename I think "xl
> rename" should either do the same thing as "xm rename" or it should
> update both names in xenstore (or maybe we should drop one).

I think libxl should store the name only in /local/domain/$domid.
In libxl we identify domains by domid, in general, not uuid.

Since libxl is becoming the preferred toolstack I think we should
change xenstat to look in the libxl location - ie, apply Daniel's
2/2.  But I'll wait for further comments.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:09:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:09:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RStqQ-0004Ly-2I; Tue, 22 Nov 2011 17:09:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RStqO-0004Lr-TU
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:09:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1321981728!4574215!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18851 invoked from network); 22 Nov 2011 17:08:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:08:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9071083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 17:08:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 17:08:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RStpv-0005fL-KA; Tue, 22 Nov 2011 17:08:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RStpv-0006c4-Hl;
	Tue, 22 Nov 2011 17:08:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.55071.538723.960939@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 17:08:47 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1320954713.16747.117.camel@dagon.hellion.org.uk>
References: <1320862287-11787-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1320862287-11787-2-git-send-email-dgdegra@tycho.nsa.gov>
	<1320954713.16747.117.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xenstat: Use local domain names
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2/2] xenstat: Use local domain names"):
> I wondered what xend does and it seems that it also creates
> both /local/domain/N/name and /vm/UUID/name but only updates the latter
> on "xm rename". So it seems that xend and xl behave exactly opposite wrt
> which one they change on rename. Leaving aside that it seems buggy to a)
> record the name twice and b) only update one copy on rename I think "xl
> rename" should either do the same thing as "xm rename" or it should
> update both names in xenstore (or maybe we should drop one).

I think libxl should store the name only in /local/domain/$domid.
In libxl we identify domains by domid, in general, not uuid.

Since libxl is becoming the preferred toolstack I think we should
change xenstat to look in the libxl location - ie, apply Daniel's
2/2.  But I'll wait for further comments.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:22:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:22:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSu2p-0004q2-Oz; Tue, 22 Nov 2011 17:22:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSu2o-0004pp-58
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:22:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1321982497!5288056!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21901 invoked from network); 22 Nov 2011 17:21:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9071317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 17:21:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 17:21:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSu2F-0005kE-90; Tue, 22 Nov 2011 17:21:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSu2F-0006ec-8A;
	Tue, 22 Nov 2011 17:21:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.55835.240381.351382@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 17:21:31 +0000
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default>
References: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
	output	ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dan Magenheimer writes ("[Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness"):
> (This should apply cleanly to 4.0, 4.1, and unstable.  It would
> be nice to apply to the next dot release of 4.0 and 4.1, but
> please definitely apply at least to unstable.)
> 
> Fix ugly parse output for xen-tmem-list-parse
> 
> This program parses the output of xm/xl tmem-list into
> human-readable format.  A missing NULL terminator sometimes
> causes garbage to be spewed where the two-letter pool type
> should be printed.
> 
> Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> 
> diff -r 54a5e994a241 tools/misc/xen-tmem-list-parse.c
> --- a/tools/misc/xen-tmem-list-parse.c	Wed Nov 02 17:09:09 2011 +0000
> +++ b/tools/misc/xen-tmem-list-parse.c	Wed Nov 09 14:28:40 2011 -0700
> @@ -64,6 +64,7 @@
>          return;
>      for ( i = 0; i < len; i++ )
>          *buf++ = *s1++;
> +    *buf = '\0';
>  }

This has a buffer overrun AFAICT.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:22:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:22:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSu2p-0004q2-Oz; Tue, 22 Nov 2011 17:22:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSu2o-0004pp-58
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:22:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1321982497!5288056!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21901 invoked from network); 22 Nov 2011 17:21:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; 
   d="scan'208";a="9071317"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 17:21:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 17:21:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSu2F-0005kE-90; Tue, 22 Nov 2011 17:21:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSu2F-0006ec-8A;
	Tue, 22 Nov 2011 17:21:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.55835.240381.351382@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 17:21:31 +0000
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default>
References: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
	output	ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dan Magenheimer writes ("[Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness"):
> (This should apply cleanly to 4.0, 4.1, and unstable.  It would
> be nice to apply to the next dot release of 4.0 and 4.1, but
> please definitely apply at least to unstable.)
> 
> Fix ugly parse output for xen-tmem-list-parse
> 
> This program parses the output of xm/xl tmem-list into
> human-readable format.  A missing NULL terminator sometimes
> causes garbage to be spewed where the two-letter pool type
> should be printed.
> 
> Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> 
> diff -r 54a5e994a241 tools/misc/xen-tmem-list-parse.c
> --- a/tools/misc/xen-tmem-list-parse.c	Wed Nov 02 17:09:09 2011 +0000
> +++ b/tools/misc/xen-tmem-list-parse.c	Wed Nov 09 14:28:40 2011 -0700
> @@ -64,6 +64,7 @@
>          return;
>      for ( i = 0; i < len; i++ )
>          *buf++ = *s1++;
> +    *buf = '\0';
>  }

This has a buffer overrun AFAICT.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:25:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:25:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSu68-0004zg-H9; Tue, 22 Nov 2011 17:25:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSu66-0004zH-M4
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:25:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1321982701!4566282!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2204 invoked from network); 22 Nov 2011 17:25:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:25:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9071371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 17:25:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 17:25:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSu5d-0005ln-FT; Tue, 22 Nov 2011 17:25:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSu5d-00012S-Ek;
	Tue, 22 Nov 2011 17:25:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.56045.424348.234756@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 17:25:01 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ecf11c010610c30e8be0.1320919973@cosworth.uk.xensource.com>
References: <ecf11c010610c30e8be0.1320919973@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: waldi@debian.org, ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools: use system installed libaio by
	default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] tools: use system installed libaio by default"):
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1320919937 0
> # Node ID ecf11c010610c30e8be0f3f567e417680c51e527
> # Parent  31eee4e06a2010c16750fc51f74459542a0b12a4
> tools: use system installed libaio by default.
...
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:25:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:25:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSu68-0004zg-H9; Tue, 22 Nov 2011 17:25:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSu66-0004zH-M4
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:25:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1321982701!4566282!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2204 invoked from network); 22 Nov 2011 17:25:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:25:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9071371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 17:25:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 17:25:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSu5d-0005ln-FT; Tue, 22 Nov 2011 17:25:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSu5d-00012S-Ek;
	Tue, 22 Nov 2011 17:25:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.56045.424348.234756@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 17:25:01 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ecf11c010610c30e8be0.1320919973@cosworth.uk.xensource.com>
References: <ecf11c010610c30e8be0.1320919973@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: waldi@debian.org, ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools: use system installed libaio by
	default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] tools: use system installed libaio by default"):
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1320919937 0
> # Node ID ecf11c010610c30e8be0f3f567e417680c51e527
> # Parent  31eee4e06a2010c16750fc51f74459542a0b12a4
> tools: use system installed libaio by default.
...
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:28:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSu8t-0005AE-7J; Tue, 22 Nov 2011 17:28:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>)
	id 1RSu8r-00059b-Li; Tue, 22 Nov 2011 17:28:21 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-216.messagelabs.com!1321982870!4572673!1
X-Originating-IP: [142.103.6.52]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30166 invoked from network); 22 Nov 2011 17:27:52 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 17:27:52 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pAMHRllT018347
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL);
	Tue, 22 Nov 2011 09:27:48 -0800
Received: by bkbzt12 with SMTP id zt12so645603bkb.30
	for <multiple recipients>; Tue, 22 Nov 2011 09:27:46 -0800 (PST)
Received: by 10.204.133.197 with SMTP id g5mr19119218bkt.43.1321982866185;
	Tue, 22 Nov 2011 09:27:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.177.19 with HTTP; Tue, 22 Nov 2011 09:27:05 -0800 (PST)
In-Reply-To: <CAFivhP==_ivB=1i-Evv0xYP73EwtBeL3OY4DNDWNUnZBtWLJtA@mail.gmail.com>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
	<000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
	<CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
	<eddb8c9332cad034094fae78cc1b7549@www.ark-net.org>
	<CAFivhP==_ivB=1i-Evv0xYP73EwtBeL3OY4DNDWNUnZBtWLJtA@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 22 Nov 2011 09:27:05 -0800
Message-ID: <CAP8mzPPPew7SgsUUVUqA=vmrRR=uUWsUW+yVqw5TfnXFEaZfYg@mail.gmail.com>
To: Florian Heigl <florian.heigl@gmail.com>
Cc: xen-devel@lists.xensource.com, mike.a.collins@ark-net.org,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4847160566875914243=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4847160566875914243==
Content-Type: multipart/alternative; boundary=00151761c92a235d3a04b2561f87

--00151761c92a235d3a04b2561f87
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 22, 2011 at 7:29 AM, Florian Heigl <florian.heigl@gmail.com>wro=
te:

> 2011/11/22 Michael A. Collins <mike.a.collins@ark-net.org>:
> > On 22.11.2011 01:56, Shriram Rajagopalan wrote:
> >
> >> eh? I dont think so. with drbd based backend for xen VMs (with or
> without
> >> remus),
> >> you just use the drbd:<resourceName> syntax (much like phy:...).
> > The drbd:<resource> syntax works for xm, but not for xl.  I'll have to
> work
>
> That's what I ended up with, too
>
> >> With all that said and done, I=92m currently running drbd 8.3.11 since
> >> that=92s the version of the kernel module included with Linux 3.1, but
> >> I=92m just using Xen=92s phy handler for the disk section of my VM=92s
> >> cfg file.
>
> wasn't there something in remus that demands you have a drbd: device
> if you're not using blktap?
>
> >> I see that there is a nice howto for debian on remusha.wikidot.com
> >> [5], but again it uses a 2.6.32 kernel from Jeremy=92s git repo, which
> >> has the tap kernel module.  I again assert that currently there is
> >> very little out there that would help to get someone started using
> >> remus with drbd in the linux 3.1.x world.  I run remus at work, but
> >> it=92s using shared storage and have no need to use it with drbd, but
> >> at home I don=92t really want to set that up, so I thought drbd would
> >> be a nice start.
> >>
> >>
> >>
> >> I=92ve started diffing the 8.3.9 branch of drbd with your changes for
> >> remus and will see how hard it is to get that in the 8.3.11 version
> >>
> >>>
> >>> Is the remusified drbd (8.3.9) not compiling under the 3.1.x kernel
> >>> anymore or are you interested in
> >>> the latest version of DRBD + the remus stuff ?
> >>>
> >>>
> >>> shriram
> >
> > I am interested in running the latest drbd changes with remus.  But I a=
m
> > interested in getting this to work through the xl interface more than
> > anything.
>
>
Well, there is no xl support for remus as of yet. The main barrier being
the disk specification issue (mentioned below) and libnetlink interface to
manipulate
the VM's network interface. Am working on that.


> Currently there's no alternate reality available in which one can run
> Remus?
> blktap - not really there (and it would have other nice features)
> dr:bd - doesn't play with xl
>

its drbd btw :).
can u just start a domain with drbd backend disk? (no remus) or anything.
I mean using the drbd:<resourceName> syntax (as described in the DRBD
website)
or using the "script=3Ddrbd,backendtype=3Dphy,format=3Draw,target=3Dresourc=
eName"
syntax in xl.

 I have tried and it doesnt work. xl defaults (hardcoded?) to tap backend.
doing a grep in the tools/libxl directory, I can see that there is no
implementation
for invoking the script supplied as part of disk spec.

if (disk->script) {
        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
                   " not yet supported, sorry");
        rc =3D ERROR_INVAL;
        goto out_free;
    }




> xm - not supposed to use that any more
> older distros - will not take remus patches i guess
> older howtos - broken since Remus is already part of Xen by now
>
> (And I don't think it will get better by pointing at a workaround else
> if one thing that should work isn't working.
> Instead, soon, it will no longer work at all)
>
>

--00151761c92a235d3a04b2561f87
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Nov 22, 2011 at 7:29 AM, Florian Heigl <=
span dir=3D"ltr">&lt;<a href=3D"mailto:florian.heigl@gmail.com">florian.hei=
gl@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

2011/11/22 Michael A. Collins &lt;<a href=3D"mailto:mike.a.collins@ark-net.=
org">mike.a.collins@ark-net.org</a>&gt;:<br>
<div class=3D"im">&gt; On 22.11.2011 01:56, Shriram Rajagopalan wrote:<br>
&gt;<br>
&gt;&gt; eh? I dont think so. with drbd based backend for xen VMs (with or =
without<br>
&gt;&gt; remus),<br>
&gt;&gt; you just use the drbd:&lt;resourceName&gt; syntax (much like phy:.=
..).<br>
</div><div class=3D"im">&gt; The drbd:&lt;resource&gt; syntax works for xm,=
 but not for xl. =A0I&#39;ll have to work<br>
<br>
</div>That&#39;s what I ended up with, too<br>
<div class=3D"im"><br>
&gt;&gt; With all that said and done, I=92m currently running drbd 8.3.11 s=
ince<br>
&gt;&gt; that=92s the version of the kernel module included with Linux 3.1,=
 but<br>
&gt;&gt; I=92m just using Xen=92s phy handler for the disk section of my VM=
=92s<br>
&gt;&gt; cfg file.<br>
<br>
</div>wasn&#39;t there something in remus that demands you have a drbd: dev=
ice<br>
if you&#39;re not using blktap?<br>
<div class=3D"im"><br>
&gt;&gt; I see that there is a nice howto for debian on <a href=3D"http://r=
emusha.wikidot.com" target=3D"_blank">remusha.wikidot.com</a><br>
&gt;&gt; [5], but again it uses a 2.6.32 kernel from Jeremy=92s git repo, w=
hich<br>
&gt;&gt; has the tap kernel module.=A0 I again assert that currently there =
is<br>
&gt;&gt; very little out there that would help to get someone started using=
<br>
&gt;&gt; remus with drbd in the linux 3.1.x world.=A0 I run remus at work, =
but<br>
&gt;&gt; it=92s using shared storage and have no need to use it with drbd, =
but<br>
&gt;&gt; at home I don=92t really want to set that up, so I thought drbd wo=
uld<br>
&gt;&gt; be a nice start.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I=92ve started diffing the 8.3.9 branch of drbd with your changes =
for<br>
&gt;&gt; remus and will see how hard it is to get that in the 8.3.11 versio=
n<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Is the remusified drbd (8.3.9) not compiling under the 3.1.x k=
ernel<br>
&gt;&gt;&gt; anymore or are you interested in<br>
&gt;&gt;&gt; the latest version of DRBD + the remus stuff ?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; shriram<br>
&gt;<br>
&gt; I am interested in running the latest drbd changes with remus. =A0But =
I am<br>
&gt; interested in getting this to work through the xl interface more than<=
br>
&gt; anything.<br>
<br></div></blockquote><div><br>Well, there is no xl support for remus as o=
f yet. The main barrier being<br>the disk specification issue (mentioned be=
low) and libnetlink interface to manipulate<br>the VM&#39;s network interfa=
ce. Am working on that.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt=
 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div=
 class=3D"im">
</div>Currently there&#39;s no alternate reality available in which one can=
 run Remus?<br>
blktap - not really there (and it would have other nice features)<br>
dr:bd - doesn&#39;t play with xl<br></blockquote><div><br>its drbd btw :).<=
br>can u just start a domain with drbd backend disk? (no remus) or anything=
.<br>I mean using the drbd:&lt;resourceName&gt; syntax (as described in the=
 DRBD website)<br>

or using the &quot;script=3Ddrbd,backendtype=3Dphy,format=3Draw,target=3Dre=
sourceName&quot; syntax in xl.<br>=A0<br>=A0I have tried and it doesnt work=
. xl defaults (hardcoded?) to tap backend.<br>doing a grep in the tools/lib=
xl directory, I can see that there is no implementation<br>

for invoking the script supplied as part of disk spec.<br><br>if (disk-&gt;=
script) {<br>=A0=A0=A0=A0=A0=A0=A0 LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;=
External block scripts&quot;<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 &quot; not yet supported, sorry&quot;);<br>

=A0=A0=A0=A0=A0=A0=A0 rc =3D ERROR_INVAL;<br>=A0=A0=A0=A0=A0=A0=A0 goto out=
_free;<br>=A0=A0=A0 }<br><br><br>=A0<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 20=
4, 204); padding-left: 1ex;">
xm - not supposed to use that any more<br>
older distros - will not take remus patches i guess<br>
older howtos - broken since Remus is already part of Xen by now<br>
<br>
(And I don&#39;t think it will get better by pointing at a workaround else<=
br>
if one thing that should work isn&#39;t working.<br>
Instead, soon, it will no longer work at all)<br>
<br>
</blockquote></div><br>

--00151761c92a235d3a04b2561f87--


--===============4847160566875914243==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4847160566875914243==--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:28:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSu8t-0005AE-7J; Tue, 22 Nov 2011 17:28:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>)
	id 1RSu8r-00059b-Li; Tue, 22 Nov 2011 17:28:21 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-216.messagelabs.com!1321982870!4572673!1
X-Originating-IP: [142.103.6.52]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30166 invoked from network); 22 Nov 2011 17:27:52 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 17:27:52 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pAMHRllT018347
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL);
	Tue, 22 Nov 2011 09:27:48 -0800
Received: by bkbzt12 with SMTP id zt12so645603bkb.30
	for <multiple recipients>; Tue, 22 Nov 2011 09:27:46 -0800 (PST)
Received: by 10.204.133.197 with SMTP id g5mr19119218bkt.43.1321982866185;
	Tue, 22 Nov 2011 09:27:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.177.19 with HTTP; Tue, 22 Nov 2011 09:27:05 -0800 (PST)
In-Reply-To: <CAFivhP==_ivB=1i-Evv0xYP73EwtBeL3OY4DNDWNUnZBtWLJtA@mail.gmail.com>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
	<000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
	<CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
	<eddb8c9332cad034094fae78cc1b7549@www.ark-net.org>
	<CAFivhP==_ivB=1i-Evv0xYP73EwtBeL3OY4DNDWNUnZBtWLJtA@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 22 Nov 2011 09:27:05 -0800
Message-ID: <CAP8mzPPPew7SgsUUVUqA=vmrRR=uUWsUW+yVqw5TfnXFEaZfYg@mail.gmail.com>
To: Florian Heigl <florian.heigl@gmail.com>
Cc: xen-devel@lists.xensource.com, mike.a.collins@ark-net.org,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4847160566875914243=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4847160566875914243==
Content-Type: multipart/alternative; boundary=00151761c92a235d3a04b2561f87

--00151761c92a235d3a04b2561f87
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 22, 2011 at 7:29 AM, Florian Heigl <florian.heigl@gmail.com>wro=
te:

> 2011/11/22 Michael A. Collins <mike.a.collins@ark-net.org>:
> > On 22.11.2011 01:56, Shriram Rajagopalan wrote:
> >
> >> eh? I dont think so. with drbd based backend for xen VMs (with or
> without
> >> remus),
> >> you just use the drbd:<resourceName> syntax (much like phy:...).
> > The drbd:<resource> syntax works for xm, but not for xl.  I'll have to
> work
>
> That's what I ended up with, too
>
> >> With all that said and done, I=92m currently running drbd 8.3.11 since
> >> that=92s the version of the kernel module included with Linux 3.1, but
> >> I=92m just using Xen=92s phy handler for the disk section of my VM=92s
> >> cfg file.
>
> wasn't there something in remus that demands you have a drbd: device
> if you're not using blktap?
>
> >> I see that there is a nice howto for debian on remusha.wikidot.com
> >> [5], but again it uses a 2.6.32 kernel from Jeremy=92s git repo, which
> >> has the tap kernel module.  I again assert that currently there is
> >> very little out there that would help to get someone started using
> >> remus with drbd in the linux 3.1.x world.  I run remus at work, but
> >> it=92s using shared storage and have no need to use it with drbd, but
> >> at home I don=92t really want to set that up, so I thought drbd would
> >> be a nice start.
> >>
> >>
> >>
> >> I=92ve started diffing the 8.3.9 branch of drbd with your changes for
> >> remus and will see how hard it is to get that in the 8.3.11 version
> >>
> >>>
> >>> Is the remusified drbd (8.3.9) not compiling under the 3.1.x kernel
> >>> anymore or are you interested in
> >>> the latest version of DRBD + the remus stuff ?
> >>>
> >>>
> >>> shriram
> >
> > I am interested in running the latest drbd changes with remus.  But I a=
m
> > interested in getting this to work through the xl interface more than
> > anything.
>
>
Well, there is no xl support for remus as of yet. The main barrier being
the disk specification issue (mentioned below) and libnetlink interface to
manipulate
the VM's network interface. Am working on that.


> Currently there's no alternate reality available in which one can run
> Remus?
> blktap - not really there (and it would have other nice features)
> dr:bd - doesn't play with xl
>

its drbd btw :).
can u just start a domain with drbd backend disk? (no remus) or anything.
I mean using the drbd:<resourceName> syntax (as described in the DRBD
website)
or using the "script=3Ddrbd,backendtype=3Dphy,format=3Draw,target=3Dresourc=
eName"
syntax in xl.

 I have tried and it doesnt work. xl defaults (hardcoded?) to tap backend.
doing a grep in the tools/libxl directory, I can see that there is no
implementation
for invoking the script supplied as part of disk spec.

if (disk->script) {
        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "External block scripts"
                   " not yet supported, sorry");
        rc =3D ERROR_INVAL;
        goto out_free;
    }




> xm - not supposed to use that any more
> older distros - will not take remus patches i guess
> older howtos - broken since Remus is already part of Xen by now
>
> (And I don't think it will get better by pointing at a workaround else
> if one thing that should work isn't working.
> Instead, soon, it will no longer work at all)
>
>

--00151761c92a235d3a04b2561f87
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Nov 22, 2011 at 7:29 AM, Florian Heigl <=
span dir=3D"ltr">&lt;<a href=3D"mailto:florian.heigl@gmail.com">florian.hei=
gl@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

2011/11/22 Michael A. Collins &lt;<a href=3D"mailto:mike.a.collins@ark-net.=
org">mike.a.collins@ark-net.org</a>&gt;:<br>
<div class=3D"im">&gt; On 22.11.2011 01:56, Shriram Rajagopalan wrote:<br>
&gt;<br>
&gt;&gt; eh? I dont think so. with drbd based backend for xen VMs (with or =
without<br>
&gt;&gt; remus),<br>
&gt;&gt; you just use the drbd:&lt;resourceName&gt; syntax (much like phy:.=
..).<br>
</div><div class=3D"im">&gt; The drbd:&lt;resource&gt; syntax works for xm,=
 but not for xl. =A0I&#39;ll have to work<br>
<br>
</div>That&#39;s what I ended up with, too<br>
<div class=3D"im"><br>
&gt;&gt; With all that said and done, I=92m currently running drbd 8.3.11 s=
ince<br>
&gt;&gt; that=92s the version of the kernel module included with Linux 3.1,=
 but<br>
&gt;&gt; I=92m just using Xen=92s phy handler for the disk section of my VM=
=92s<br>
&gt;&gt; cfg file.<br>
<br>
</div>wasn&#39;t there something in remus that demands you have a drbd: dev=
ice<br>
if you&#39;re not using blktap?<br>
<div class=3D"im"><br>
&gt;&gt; I see that there is a nice howto for debian on <a href=3D"http://r=
emusha.wikidot.com" target=3D"_blank">remusha.wikidot.com</a><br>
&gt;&gt; [5], but again it uses a 2.6.32 kernel from Jeremy=92s git repo, w=
hich<br>
&gt;&gt; has the tap kernel module.=A0 I again assert that currently there =
is<br>
&gt;&gt; very little out there that would help to get someone started using=
<br>
&gt;&gt; remus with drbd in the linux 3.1.x world.=A0 I run remus at work, =
but<br>
&gt;&gt; it=92s using shared storage and have no need to use it with drbd, =
but<br>
&gt;&gt; at home I don=92t really want to set that up, so I thought drbd wo=
uld<br>
&gt;&gt; be a nice start.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I=92ve started diffing the 8.3.9 branch of drbd with your changes =
for<br>
&gt;&gt; remus and will see how hard it is to get that in the 8.3.11 versio=
n<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Is the remusified drbd (8.3.9) not compiling under the 3.1.x k=
ernel<br>
&gt;&gt;&gt; anymore or are you interested in<br>
&gt;&gt;&gt; the latest version of DRBD + the remus stuff ?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; shriram<br>
&gt;<br>
&gt; I am interested in running the latest drbd changes with remus. =A0But =
I am<br>
&gt; interested in getting this to work through the xl interface more than<=
br>
&gt; anything.<br>
<br></div></blockquote><div><br>Well, there is no xl support for remus as o=
f yet. The main barrier being<br>the disk specification issue (mentioned be=
low) and libnetlink interface to manipulate<br>the VM&#39;s network interfa=
ce. Am working on that.<br>

=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt=
 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div=
 class=3D"im">
</div>Currently there&#39;s no alternate reality available in which one can=
 run Remus?<br>
blktap - not really there (and it would have other nice features)<br>
dr:bd - doesn&#39;t play with xl<br></blockquote><div><br>its drbd btw :).<=
br>can u just start a domain with drbd backend disk? (no remus) or anything=
.<br>I mean using the drbd:&lt;resourceName&gt; syntax (as described in the=
 DRBD website)<br>

or using the &quot;script=3Ddrbd,backendtype=3Dphy,format=3Draw,target=3Dre=
sourceName&quot; syntax in xl.<br>=A0<br>=A0I have tried and it doesnt work=
. xl defaults (hardcoded?) to tap backend.<br>doing a grep in the tools/lib=
xl directory, I can see that there is no implementation<br>

for invoking the script supplied as part of disk spec.<br><br>if (disk-&gt;=
script) {<br>=A0=A0=A0=A0=A0=A0=A0 LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;=
External block scripts&quot;<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 &quot; not yet supported, sorry&quot;);<br>

=A0=A0=A0=A0=A0=A0=A0 rc =3D ERROR_INVAL;<br>=A0=A0=A0=A0=A0=A0=A0 goto out=
_free;<br>=A0=A0=A0 }<br><br><br>=A0<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 20=
4, 204); padding-left: 1ex;">
xm - not supposed to use that any more<br>
older distros - will not take remus patches i guess<br>
older howtos - broken since Remus is already part of Xen by now<br>
<br>
(And I don&#39;t think it will get better by pointing at a workaround else<=
br>
if one thing that should work isn&#39;t working.<br>
Instead, soon, it will no longer work at all)<br>
<br>
</blockquote></div><br>

--00151761c92a235d3a04b2561f87--


--===============4847160566875914243==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4847160566875914243==--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:34:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:34:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSuEi-0005kd-20; Tue, 22 Nov 2011 17:34:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSuEh-0005kG-84
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:34:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321983196!64231097!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5928 invoked from network); 22 Nov 2011 17:33:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:33:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9071526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 17:33:56 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 17:33:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
In-Reply-To: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default>
References: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default>
Organization: Citrix Systems, Inc.
Date: Tue, 22 Nov 2011 17:33:55 +0000
Message-ID: <1321983235.20464.32.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-09 at 21:40 +0000, Dan Magenheimer wrote:
> (This should apply cleanly to 4.0, 4.1, and unstable.  It would
> be nice to apply to the next dot release of 4.0 and 4.1, but
> please definitely apply at least to unstable.)
> 
> Fix ugly parse output for xen-tmem-list-parse
> 
> This program parses the output of xm/xl tmem-list into
> human-readable format.

Why does xm/xl not just have a human readable output option (or more
likely, default)?

>   A missing NULL terminator sometimes
> causes garbage to be spewed where the two-letter pool type
> should be printed.
> 
> Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> 
> diff -r 54a5e994a241 tools/misc/xen-tmem-list-parse.c
> --- a/tools/misc/xen-tmem-list-parse.c	Wed Nov 02 17:09:09 2011 +0000
> +++ b/tools/misc/xen-tmem-list-parse.c	Wed Nov 09 14:28:40 2011 -0700
> @@ -64,6 +64,7 @@
>          return;
>      for ( i = 0; i < len; i++ )
>          *buf++ = *s1++;
> +    *buf = '\0';
>  }
>  
>  void parse_sharers(char *s, char *match, char *buf, int len)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:34:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:34:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSuEi-0005kd-20; Tue, 22 Nov 2011 17:34:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RSuEh-0005kG-84
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:34:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1321983196!64231097!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5928 invoked from network); 22 Nov 2011 17:33:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:33:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9071526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 17:33:56 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 17:33:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
In-Reply-To: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default>
References: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default>
Organization: Citrix Systems, Inc.
Date: Tue, 22 Nov 2011 17:33:55 +0000
Message-ID: <1321983235.20464.32.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-09 at 21:40 +0000, Dan Magenheimer wrote:
> (This should apply cleanly to 4.0, 4.1, and unstable.  It would
> be nice to apply to the next dot release of 4.0 and 4.1, but
> please definitely apply at least to unstable.)
> 
> Fix ugly parse output for xen-tmem-list-parse
> 
> This program parses the output of xm/xl tmem-list into
> human-readable format.

Why does xm/xl not just have a human readable output option (or more
likely, default)?

>   A missing NULL terminator sometimes
> causes garbage to be spewed where the two-letter pool type
> should be printed.
> 
> Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> 
> diff -r 54a5e994a241 tools/misc/xen-tmem-list-parse.c
> --- a/tools/misc/xen-tmem-list-parse.c	Wed Nov 02 17:09:09 2011 +0000
> +++ b/tools/misc/xen-tmem-list-parse.c	Wed Nov 09 14:28:40 2011 -0700
> @@ -64,6 +64,7 @@
>          return;
>      for ( i = 0; i < len; i++ )
>          *buf++ = *s1++;
> +    *buf = '\0';
>  }
>  
>  void parse_sharers(char *s, char *match, char *buf, int len)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:37:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:37:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSuHD-0005tc-KX; Tue, 22 Nov 2011 17:36:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSuHC-0005tV-5J
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:36:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1321983362!53788926!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23558 invoked from network); 22 Nov 2011 17:36:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 17:36:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321983390; l=3252;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=BAXtKi3JRfDrdHQ74DnvfgpeRSE=;
	b=JvODpOX4w6GFI9tN9DHNgkXDDo48T30wxip4erLM2C4Bmy4s3nbF8/vMOSoNwfNUvvf
	7AqZxkhiHCkn+3zvtFSHUytYPB6wq/JcKHa/pXGsdPNUjQHRQQaA1zmK8GAN99XOWNhN/
	SOvqGYMZx6miwUgWqAiQJNp5VI3JKvbn6Ew=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (fruni mo25) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 205da8nAMGexQm ;
	Tue, 22 Nov 2011 18:36:19 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2562818637; Tue, 22 Nov 2011 18:36:19 +0100 (CET)
Date: Tue, 22 Nov 2011 18:36:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir@xen.org>
Message-ID: <20111122173618.GA1304@aepfle.de>
References: <20111122150755.GA18727@aepfle.de>
 <CAF172FF.34839%keir@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF172FF.34839%keir@xen.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Keir Fraser wrote:

> I have a new theory, which is that if we go round the for-loop in
> wait_event() more than once, the vcpu's pause counter gets messed up and
> goes negative, condemning it to sleep forever.

I have added a check for that, its not negative.
 
> I have *just* pushed a change to the debug 'q' key (ignore the changeset
> comment referring to 'd' key, I got that wrong!) which will print per-vcpu
> and per-domain pause_count values. Please get the system stuck again, and
> send the output from 'q' key with that new changeset (c/s 24178).

To me it looks like dom0 gets paused, perhaps due to some uneven pause/unpause calls.
I will see if I can figure it out.

Olaf

(XEN) 'q' pressed -> dumping domain info (now=0xA1:4BC733CC)
(XEN) General information for domain 0:
(XEN)     refcnt=3 dying=0 pause_count=0
(XEN)     nr_pages=5991502 xenheap_pages=5 dirty_cpus={} max_pages=4294967295
(XEN)     handle=00000000-0000-0000-0000-000000000000 vm_assist=00000004
(XEN) Rangesets belonging to domain 0:
(XEN)     I/O Ports  { 0-1f, 22-3f, 44-60, 62-9f, a2-3f7, 400-407, 40c-cfb, d00-ffff }
(XEN)     Interrupts { 0-303 }
(XEN)     I/O Memory { 0-febff, fec01-fec8f, fec91-fedff, fee01-ffffffffffffffff }
(XEN) Memory pages belonging to domain 0:
(XEN)     DomPage list too long to display
(XEN)     XenPage 000000000036ff8d: caf=c000000000000002, taf=7400000000000002
(XEN)     XenPage 000000000036ff8c: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000036ff8b: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000036ff8a: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000008befd: caf=c000000000000002, taf=7400000000000002
(XEN) VCPU information and callbacks for domain 0:
(XEN)     VCPU0: CPU0 [has=F] poll=0 upcall_pend = 01, upcall_mask = 00 dirty_cpus={} cpu_affinity={0}
(XEN)     pause_count=1 pause_flags=0
(XEN)     250 Hz periodic timer (period 4 ms)
(XEN) General information for domain 1:
(XEN)     refcnt=3 dying=0 pause_count=0
(XEN)     nr_pages=17549 xenheap_pages=6 dirty_cpus={} max_pages=131328
(XEN)     handle=5499728e-7f38-dbb0-b6cc-22866a6864f3 vm_assist=00000000
(XEN)     paging assistance: hap refcounts translate external
(XEN) Rangesets belonging to domain 1:
(XEN)     I/O Ports  { }
(XEN)     Interrupts { }
(XEN)     I/O Memory { }
(XEN) Memory pages belonging to domain 1:
(XEN)     DomPage list too long to display
(XEN)     PoD entries=0 cachesize=0
(XEN)     XenPage 0000000000200b7c: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 0000000000203bfe: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 0000000000200b48: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000021291d: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000003ebfc: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 0000000000202ef4: caf=c000000000000001, taf=7400000000000001
(XEN) VCPU information and callbacks for domain 1:
(XEN)     VCPU0: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0}
(XEN)     pause_count=0 pause_flags=4
(XEN)     paging assistance: hap, 4 levels
(XEN)     No periodic timer
(XEN) Notifying guest 0:0 (virq 1, port 0, stat 0/-1/-1)
(XEN) Notifying guest 1:0 (virq 1, port 0, stat 0/0/0)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:37:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:37:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSuHD-0005tc-KX; Tue, 22 Nov 2011 17:36:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSuHC-0005tV-5J
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:36:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1321983362!53788926!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23558 invoked from network); 22 Nov 2011 17:36:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 17:36:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321983390; l=3252;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=BAXtKi3JRfDrdHQ74DnvfgpeRSE=;
	b=JvODpOX4w6GFI9tN9DHNgkXDDo48T30wxip4erLM2C4Bmy4s3nbF8/vMOSoNwfNUvvf
	7AqZxkhiHCkn+3zvtFSHUytYPB6wq/JcKHa/pXGsdPNUjQHRQQaA1zmK8GAN99XOWNhN/
	SOvqGYMZx6miwUgWqAiQJNp5VI3JKvbn6Ew=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (fruni mo25) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 205da8nAMGexQm ;
	Tue, 22 Nov 2011 18:36:19 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2562818637; Tue, 22 Nov 2011 18:36:19 +0100 (CET)
Date: Tue, 22 Nov 2011 18:36:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir@xen.org>
Message-ID: <20111122173618.GA1304@aepfle.de>
References: <20111122150755.GA18727@aepfle.de>
 <CAF172FF.34839%keir@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF172FF.34839%keir@xen.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Keir Fraser wrote:

> I have a new theory, which is that if we go round the for-loop in
> wait_event() more than once, the vcpu's pause counter gets messed up and
> goes negative, condemning it to sleep forever.

I have added a check for that, its not negative.
 
> I have *just* pushed a change to the debug 'q' key (ignore the changeset
> comment referring to 'd' key, I got that wrong!) which will print per-vcpu
> and per-domain pause_count values. Please get the system stuck again, and
> send the output from 'q' key with that new changeset (c/s 24178).

To me it looks like dom0 gets paused, perhaps due to some uneven pause/unpause calls.
I will see if I can figure it out.

Olaf

(XEN) 'q' pressed -> dumping domain info (now=0xA1:4BC733CC)
(XEN) General information for domain 0:
(XEN)     refcnt=3 dying=0 pause_count=0
(XEN)     nr_pages=5991502 xenheap_pages=5 dirty_cpus={} max_pages=4294967295
(XEN)     handle=00000000-0000-0000-0000-000000000000 vm_assist=00000004
(XEN) Rangesets belonging to domain 0:
(XEN)     I/O Ports  { 0-1f, 22-3f, 44-60, 62-9f, a2-3f7, 400-407, 40c-cfb, d00-ffff }
(XEN)     Interrupts { 0-303 }
(XEN)     I/O Memory { 0-febff, fec01-fec8f, fec91-fedff, fee01-ffffffffffffffff }
(XEN) Memory pages belonging to domain 0:
(XEN)     DomPage list too long to display
(XEN)     XenPage 000000000036ff8d: caf=c000000000000002, taf=7400000000000002
(XEN)     XenPage 000000000036ff8c: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000036ff8b: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000036ff8a: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000008befd: caf=c000000000000002, taf=7400000000000002
(XEN) VCPU information and callbacks for domain 0:
(XEN)     VCPU0: CPU0 [has=F] poll=0 upcall_pend = 01, upcall_mask = 00 dirty_cpus={} cpu_affinity={0}
(XEN)     pause_count=1 pause_flags=0
(XEN)     250 Hz periodic timer (period 4 ms)
(XEN) General information for domain 1:
(XEN)     refcnt=3 dying=0 pause_count=0
(XEN)     nr_pages=17549 xenheap_pages=6 dirty_cpus={} max_pages=131328
(XEN)     handle=5499728e-7f38-dbb0-b6cc-22866a6864f3 vm_assist=00000000
(XEN)     paging assistance: hap refcounts translate external
(XEN) Rangesets belonging to domain 1:
(XEN)     I/O Ports  { }
(XEN)     Interrupts { }
(XEN)     I/O Memory { }
(XEN) Memory pages belonging to domain 1:
(XEN)     DomPage list too long to display
(XEN)     PoD entries=0 cachesize=0
(XEN)     XenPage 0000000000200b7c: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 0000000000203bfe: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 0000000000200b48: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000021291d: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000003ebfc: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 0000000000202ef4: caf=c000000000000001, taf=7400000000000001
(XEN) VCPU information and callbacks for domain 1:
(XEN)     VCPU0: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0}
(XEN)     pause_count=0 pause_flags=4
(XEN)     paging assistance: hap, 4 levels
(XEN)     No periodic timer
(XEN) Notifying guest 0:0 (virq 1, port 0, stat 0/-1/-1)
(XEN) Notifying guest 1:0 (virq 1, port 0, stat 0/0/0)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:41:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:41:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSuLW-0006Aj-DQ; Tue, 22 Nov 2011 17:41:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1RSuLV-0006AR-L1
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:41:25 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321983656!2602202!1
X-Originating-IP: [74.125.82.41]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13866 invoked from network); 22 Nov 2011 17:40:56 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:40:56 -0000
Received: by wwf25 with SMTP id 25so7438046wwf.0
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 09:40:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=xbjQF0iyfJXMYQxVBaFqboPpDfKxctn7JD0ASPmhrCk=;
	b=jsWePr5F+gKmZBZ7/jXJJd0SpnVL8ve/FVUjtClHLlsKucDuA50rRusXMuQrpR00ZV
	AiU8Z5vk+xOp9L8OC5GzI57mbI0n+cQccPfNPwrbjdXLp4aQ0oMl9X04wY1tEqfHKqHB
	oEGlz63SMxqii3G4Pb5hpc9qOZeREwgDdEiYU=
MIME-Version: 1.0
Received: by 10.227.197.148 with SMTP id ek20mr12743381wbb.7.1321983656390;
	Tue, 22 Nov 2011 09:40:56 -0800 (PST)
Received: by 10.216.153.39 with HTTP; Tue, 22 Nov 2011 09:40:56 -0800 (PST)
Date: Tue, 22 Nov 2011 12:40:56 -0500
Message-ID: <CAMTrTqVYqJLmU-vhN=28Sv16_sdXO5V5SRQtbQCvnvb9QNNUWg@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] what is the max number of page can be granted and
	mapped between two domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,
I am trying to share some memory pages between a domU and dom0.
The domU calls gnttab_grant_foreign_access(domid, mfn, 0); to grant the its
pages for accessing by dom0, and then dom0 calls

gnttab_set_map_op(... remoteDomain) and HYPERVISOR_grant_table_op(...)
to map the pages from domU.
Everying works fine when the number of granted page is < 533
However, when the number of granted page is >= 533, dom0 can not map
the granted pages.
The function HYPERVISOR_grant_table_op returns error.

My question is whether the max number of mapped page is 533. If it is
how can I changed this limit. Or if there is any bettter way to
sharing a large chunk of memory (about 20MB) page between two domains.
Thanks.

- Steven

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:41:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:41:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSuLW-0006Aj-DQ; Tue, 22 Nov 2011 17:41:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1RSuLV-0006AR-L1
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:41:25 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1321983656!2602202!1
X-Originating-IP: [74.125.82.41]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13866 invoked from network); 22 Nov 2011 17:40:56 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:40:56 -0000
Received: by wwf25 with SMTP id 25so7438046wwf.0
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 09:40:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=xbjQF0iyfJXMYQxVBaFqboPpDfKxctn7JD0ASPmhrCk=;
	b=jsWePr5F+gKmZBZ7/jXJJd0SpnVL8ve/FVUjtClHLlsKucDuA50rRusXMuQrpR00ZV
	AiU8Z5vk+xOp9L8OC5GzI57mbI0n+cQccPfNPwrbjdXLp4aQ0oMl9X04wY1tEqfHKqHB
	oEGlz63SMxqii3G4Pb5hpc9qOZeREwgDdEiYU=
MIME-Version: 1.0
Received: by 10.227.197.148 with SMTP id ek20mr12743381wbb.7.1321983656390;
	Tue, 22 Nov 2011 09:40:56 -0800 (PST)
Received: by 10.216.153.39 with HTTP; Tue, 22 Nov 2011 09:40:56 -0800 (PST)
Date: Tue, 22 Nov 2011 12:40:56 -0500
Message-ID: <CAMTrTqVYqJLmU-vhN=28Sv16_sdXO5V5SRQtbQCvnvb9QNNUWg@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] what is the max number of page can be granted and
	mapped between two domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,
I am trying to share some memory pages between a domU and dom0.
The domU calls gnttab_grant_foreign_access(domid, mfn, 0); to grant the its
pages for accessing by dom0, and then dom0 calls

gnttab_set_map_op(... remoteDomain) and HYPERVISOR_grant_table_op(...)
to map the pages from domU.
Everying works fine when the number of granted page is < 533
However, when the number of granted page is >= 533, dom0 can not map
the granted pages.
The function HYPERVISOR_grant_table_op returns error.

My question is whether the max number of mapped page is 533. If it is
how can I changed this limit. Or if there is any bettter way to
sharing a large chunk of memory (about 20MB) page between two domains.
Thanks.

- Steven

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:43:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:43:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSuMx-0006HI-4N; Tue, 22 Nov 2011 17:42:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSuMw-0006Gx-Et
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:42:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321983745!4565366!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23350 invoked from network); 22 Nov 2011 17:42:25 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:42:25 -0000
Received: by wwo1 with SMTP id 1so320838wwo.24
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 09:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LVSmOh+wjdZYPH1iF65/x58LDaXh5IHNTOS3OmLVlhs=;
	b=mdgmCJNuyCXHvjCBMpgTXSUUS9VOJZiBrbQOWVjYAgRD+LTGWA0ZZBdjcR0KCR5JRc
	zOpgXx5j8lnIBrLNKs6x/vp0Fp8Af7UGSs+Vb67cJ4l1GNOKM+LaQXhnz0tjvrmB/NkB
	rOsrf8p/HdbJ+VBDzfU1egcH+V6iTUJHHEw38=
Received: by 10.227.203.148 with SMTP id fi20mr12699951wbb.27.1321983745414;
	Tue, 22 Nov 2011 09:42:25 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id ej7sm1521864wib.0.2011.11.22.09.42.23
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 09:42:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 17:42:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF18F7C.255E4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypPhV1cLJwH5NqnEmhVovLFFTAEA==
In-Reply-To: <20111122173618.GA1304@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 17:36, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Keir Fraser wrote:
> 
>> I have a new theory, which is that if we go round the for-loop in
>> wait_event() more than once, the vcpu's pause counter gets messed up and
>> goes negative, condemning it to sleep forever.
> 
> I have added a check for that, its not negative.
>  
>> I have *just* pushed a change to the debug 'q' key (ignore the changeset
>> comment referring to 'd' key, I got that wrong!) which will print per-vcpu
>> and per-domain pause_count values. Please get the system stuck again, and
>> send the output from 'q' key with that new changeset (c/s 24178).
> 
> To me it looks like dom0 gets paused, perhaps due to some uneven pause/unpause
> calls.
> I will see if I can figure it out.

Could it have ended up on the waitqueue?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 17:43:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 17:43:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSuMx-0006HI-4N; Tue, 22 Nov 2011 17:42:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSuMw-0006Gx-Et
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 17:42:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1321983745!4565366!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23350 invoked from network); 22 Nov 2011 17:42:25 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 17:42:25 -0000
Received: by wwo1 with SMTP id 1so320838wwo.24
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 09:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=LVSmOh+wjdZYPH1iF65/x58LDaXh5IHNTOS3OmLVlhs=;
	b=mdgmCJNuyCXHvjCBMpgTXSUUS9VOJZiBrbQOWVjYAgRD+LTGWA0ZZBdjcR0KCR5JRc
	zOpgXx5j8lnIBrLNKs6x/vp0Fp8Af7UGSs+Vb67cJ4l1GNOKM+LaQXhnz0tjvrmB/NkB
	rOsrf8p/HdbJ+VBDzfU1egcH+V6iTUJHHEw38=
Received: by 10.227.203.148 with SMTP id fi20mr12699951wbb.27.1321983745414;
	Tue, 22 Nov 2011 09:42:25 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id ej7sm1521864wib.0.2011.11.22.09.42.23
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 09:42:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 17:42:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF18F7C.255E4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypPhV1cLJwH5NqnEmhVovLFFTAEA==
In-Reply-To: <20111122173618.GA1304@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 17:36, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Keir Fraser wrote:
> 
>> I have a new theory, which is that if we go round the for-loop in
>> wait_event() more than once, the vcpu's pause counter gets messed up and
>> goes negative, condemning it to sleep forever.
> 
> I have added a check for that, its not negative.
>  
>> I have *just* pushed a change to the debug 'q' key (ignore the changeset
>> comment referring to 'd' key, I got that wrong!) which will print per-vcpu
>> and per-domain pause_count values. Please get the system stuck again, and
>> send the output from 'q' key with that new changeset (c/s 24178).
> 
> To me it looks like dom0 gets paused, perhaps due to some uneven pause/unpause
> calls.
> I will see if I can figure it out.

Could it have ended up on the waitqueue?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:05:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSui9-0006kr-C4; Tue, 22 Nov 2011 18:04:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSui7-0006km-Th
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:04:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321985043!46684429!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26947 invoked from network); 22 Nov 2011 18:04:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 18:04:04 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321985058; l=143;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=tC8RsTTZtnPSCHunewycZZ0kOCU=;
	b=vvFNzQ51yFmVFUra8wXyWaF0D2i05lODvyjUQ2Skvb27imyGUXbZzOurs6yfhGIo0J+
	yqK3a9RHFTL69OudVvKBm/d8OXh+J/ub18+4OFIorkOKTCW7nzT9mUXAclLp7FyGK8c7p
	n81YeEUYvUGBW5yZb5RmBMhT/Ck6KiVnk0Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (fruni mo4) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id h068a2nAMG7BND ;
	Tue, 22 Nov 2011 19:04:02 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6F8DF18637; Tue, 22 Nov 2011 19:04:01 +0100 (CET)
Date: Tue, 22 Nov 2011 19:04:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111122180401.GA2555@aepfle.de>
References: <20111122173618.GA1304@aepfle.de>
	<CAF18F7C.255E4%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF18F7C.255E4%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Keir Fraser wrote:

> Could it have ended up on the waitqueue?

Unlikely, but I will add checks for that as well.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:05:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:05:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSui9-0006kr-C4; Tue, 22 Nov 2011 18:04:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSui7-0006km-Th
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:04:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1321985043!46684429!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26947 invoked from network); 22 Nov 2011 18:04:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 18:04:04 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321985058; l=143;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=tC8RsTTZtnPSCHunewycZZ0kOCU=;
	b=vvFNzQ51yFmVFUra8wXyWaF0D2i05lODvyjUQ2Skvb27imyGUXbZzOurs6yfhGIo0J+
	yqK3a9RHFTL69OudVvKBm/d8OXh+J/ub18+4OFIorkOKTCW7nzT9mUXAclLp7FyGK8c7p
	n81YeEUYvUGBW5yZb5RmBMhT/Ck6KiVnk0Y=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (fruni mo4) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id h068a2nAMG7BND ;
	Tue, 22 Nov 2011 19:04:02 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6F8DF18637; Tue, 22 Nov 2011 19:04:01 +0100 (CET)
Date: Tue, 22 Nov 2011 19:04:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111122180401.GA2555@aepfle.de>
References: <20111122173618.GA1304@aepfle.de>
	<CAF18F7C.255E4%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF18F7C.255E4%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Keir Fraser wrote:

> Could it have ended up on the waitqueue?

Unlikely, but I will add checks for that as well.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:11:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:11:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSuoC-0006xX-6X; Tue, 22 Nov 2011 18:11:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>)
	id 1RSuoA-0006xF-W7; Tue, 22 Nov 2011 18:11:03 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1321985433!2612296!1
X-Originating-IP: [216.33.127.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17437 invoked from network); 22 Nov 2011 18:10:33 -0000
Received: from mta21.charter.net (HELO mta21.charter.net) (216.33.127.81)
	by server-9.tower-174.messagelabs.com with SMTP;
	22 Nov 2011 18:10:33 -0000
Received: from imp09 ([10.20.200.9]) by mta21.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111122181032.MSKH23071.mta21.charter.net@imp09>;
	Tue, 22 Nov 2011 13:10:32 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp09 with smtp.charter.net
	id 0JAY1i00B46xN4z05JAY8t; Tue, 22 Nov 2011 13:10:32 -0500
X-Authority-Analysis: v=1.1 cv=6DnK9SlspjQUafU6MzYmZAt1wpB1MUaNH28Mo/Kfxqk=
	c=1 sm=1 a=0bCt-fb661UA:10 a=5BFIHP_PH3cA:10 a=VCxxn1A5iYMA:10
	a=NqYyV4q_xg0A:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=tlGuAqFHBJIYjHh2u8MA:9
	a=5EvdL3w8R7cUlR10KN8A:7 a=QEXdDO2ut3YA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 54D1D203CF;
	Tue, 22 Nov 2011 18:10:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id VSQlwWcjPS7g; Tue, 22 Nov 2011 13:10:15 -0500 (EST)
Received: from www.ark-net.org (unknown [192.168.1.12])
	by mail.ark-net.org (Postfix) with ESMTP id C243820394;
	Tue, 22 Nov 2011 13:10:15 -0500 (EST)
MIME-Version: 1.0
Date: Tue, 22 Nov 2011 13:15:18 -0500
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <rshriram@cs.ubc.ca>
Mail-Reply-To: <mike.a.collins@ark-net.org>
In-Reply-To: <CAP8mzPPPew7SgsUUVUqA=vmrRR=uUWsUW+yVqw5TfnXFEaZfYg@mail.gmail.com>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
	<000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
	<CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
	<eddb8c9332cad034094fae78cc1b7549@www.ark-net.org>
	<CAFivhP==_ivB=1i-Evv0xYP73EwtBeL3OY4DNDWNUnZBtWLJtA@mail.gmail.com>
	<CAP8mzPPPew7SgsUUVUqA=vmrRR=uUWsUW+yVqw5TfnXFEaZfYg@mail.gmail.com>
Message-ID: <de93b8c085fcfc733a33f465939626a4@www.ark-net.org>
X-Sender: mike.a.collins@ark-net.org
User-Agent: Roundcube Webmail/0.6-beta
Cc: Florian Heigl <florian.heigl@gmail.com>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: mike.a.collins@ark-net.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMjIuMTEuMjAxMSAxMjoyNywgU2hyaXJhbSBSYWphZ29wYWxhbiB3cm90ZToKPgo+IGl0cyBk
cmJkIGJ0dyA6KS4KPiBjYW4gdSBqdXN0IHN0YXJ0IGEgZG9tYWluIHdpdGggZHJiZCBiYWNrZW5k
IGRpc2s/IChubyByZW11cykgb3IKPiBhbnl0aGluZy4KPiBJIG1lYW4gdXNpbmcgdGhlIGRyYmQ6
IHN5bnRheCAoYXMgZGVzY3JpYmVkIGluIHRoZSBEUkJEIHdlYnNpdGUpCj4gIG9yIHVzaW5nIHRo
ZQo+ICJzY3JpcHQ9ZHJiZCxiYWNrZW5kdHlwZT1waHksZm9ybWF0PXJhdyx0YXJnZXQ9cmVzb3Vy
Y2VOYW1lIiBzeW50YXggCj4gaW4KPiB4bC4KPiDCoAo+IMKgSSBoYXZlIHRyaWVkIGFuZCBpdCBk
b2VzbnQgd29yay4geGwgZGVmYXVsdHMgKGhhcmRjb2RlZD8pIHRvIHRhcAo+IGJhY2tlbmQuCj4g
ZG9pbmcgYSBncmVwIGluIHRoZSB0b29scy9saWJ4bCBkaXJlY3RvcnksIEkgY2FuIHNlZSB0aGF0
IHRoZXJlIGlzIG5vCj4gaW1wbGVtZW50YXRpb24KPiAgZm9yIGludm9raW5nIHRoZSBzY3JpcHQg
c3VwcGxpZWQgYXMgcGFydCBvZiBkaXNrIHNwZWMuCj4KPiBpZiAoZGlzay0+c2NyaXB0KSB7Cj4g
wqDCoMKgwqDCoMKgwqAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJFeHRlcm5h
bCBibG9jawo+IHNjcmlwdHMiCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
ICIgbm90IHlldCBzdXBwb3J0ZWQsIHNvcnJ5Iik7Cj4gIMKgwqDCoMKgwqDCoMKgIHJjID0gRVJS
T1JfSU5WQUw7Cj4gwqDCoMKgwqDCoMKgwqAgZ290byBvdXRfZnJlZTsKPiDCoMKgwqAgfQo+Cj4g
wqAKCgpUaGF0J3MgY29vbCwgYW5kIGV4cGxhaW5zIGFsb3QuICBJIGhhZCBub3QgZmlndXJlZCB0
aGF0IGxpYnhsIGRpZG4ndCAKaGF2ZSB0aGUgY2FwYWJpbGl0eSBvZiBleGVjdXRpbmcgYmxvY2sg
c2NyaXB0cy4gIEkgd2lsbCB3YWl0IHBhdGllbnRseSAKYW5kIHRyeSB0byBhc3Npc3QgaW4gYW55
IHdheSB0byB0ZXN0IGFueSBjaGFuZ2VzIG5lZWRlZCB0byBwcm92aWRlIGxpYnhsIApzdXBwb3J0
IHRvIHJlbXVzLgpNaWtlCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:11:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:11:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSuoC-0006xX-6X; Tue, 22 Nov 2011 18:11:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike.a.collins@ark-net.org>)
	id 1RSuoA-0006xF-W7; Tue, 22 Nov 2011 18:11:03 +0000
X-Env-Sender: mike.a.collins@ark-net.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1321985433!2612296!1
X-Originating-IP: [216.33.127.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17437 invoked from network); 22 Nov 2011 18:10:33 -0000
Received: from mta21.charter.net (HELO mta21.charter.net) (216.33.127.81)
	by server-9.tower-174.messagelabs.com with SMTP;
	22 Nov 2011 18:10:33 -0000
Received: from imp09 ([10.20.200.9]) by mta21.charter.net
	(InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP
	id <20111122181032.MSKH23071.mta21.charter.net@imp09>;
	Tue, 22 Nov 2011 13:10:32 -0500
Received: from mail.ark-net.org ([75.138.196.190])
	by imp09 with smtp.charter.net
	id 0JAY1i00B46xN4z05JAY8t; Tue, 22 Nov 2011 13:10:32 -0500
X-Authority-Analysis: v=1.1 cv=6DnK9SlspjQUafU6MzYmZAt1wpB1MUaNH28Mo/Kfxqk=
	c=1 sm=1 a=0bCt-fb661UA:10 a=5BFIHP_PH3cA:10 a=VCxxn1A5iYMA:10
	a=NqYyV4q_xg0A:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:17 a=tlGuAqFHBJIYjHh2u8MA:9
	a=5EvdL3w8R7cUlR10KN8A:7 a=QEXdDO2ut3YA:10
	a=vtmAIxR7S4RyHMe0h/1GdA==:117
Received: from localhost (unknown [127.0.0.1])
	by mail.ark-net.org (Postfix) with ESMTP id 54D1D203CF;
	Tue, 22 Nov 2011 18:10:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at ark-net.org
Received: from mail.ark-net.org ([127.0.0.1])
	by localhost (mail.ark-net.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id VSQlwWcjPS7g; Tue, 22 Nov 2011 13:10:15 -0500 (EST)
Received: from www.ark-net.org (unknown [192.168.1.12])
	by mail.ark-net.org (Postfix) with ESMTP id C243820394;
	Tue, 22 Nov 2011 13:10:15 -0500 (EST)
MIME-Version: 1.0
Date: Tue, 22 Nov 2011 13:15:18 -0500
From: "Michael A. Collins" <mike.a.collins@ark-net.org>
To: <rshriram@cs.ubc.ca>
Mail-Reply-To: <mike.a.collins@ark-net.org>
In-Reply-To: <CAP8mzPPPew7SgsUUVUqA=vmrRR=uUWsUW+yVqw5TfnXFEaZfYg@mail.gmail.com>
References: <002401cca7e6$ec135b70$c43a1250$@ark-net.org>
	<CAP8mzPPfHBA+nq_y7QxiwLJGa0P+eyaHFhJbFNZR_uL-D_zyZA@mail.gmail.com>
	<000301cca8bb$1ebfaa90$5c3effb0$@ark-net.org>
	<CAP8mzPMeW5N+iia5UudX5PCQUApKww2MCazZtx7HcweNG=FUSA@mail.gmail.com>
	<eddb8c9332cad034094fae78cc1b7549@www.ark-net.org>
	<CAFivhP==_ivB=1i-Evv0xYP73EwtBeL3OY4DNDWNUnZBtWLJtA@mail.gmail.com>
	<CAP8mzPPPew7SgsUUVUqA=vmrRR=uUWsUW+yVqw5TfnXFEaZfYg@mail.gmail.com>
Message-ID: <de93b8c085fcfc733a33f465939626a4@www.ark-net.org>
X-Sender: mike.a.collins@ark-net.org
User-Agent: Roundcube Webmail/0.6-beta
Cc: Florian Heigl <florian.heigl@gmail.com>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  BLKTAP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: mike.a.collins@ark-net.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gMjIuMTEuMjAxMSAxMjoyNywgU2hyaXJhbSBSYWphZ29wYWxhbiB3cm90ZToKPgo+IGl0cyBk
cmJkIGJ0dyA6KS4KPiBjYW4gdSBqdXN0IHN0YXJ0IGEgZG9tYWluIHdpdGggZHJiZCBiYWNrZW5k
IGRpc2s/IChubyByZW11cykgb3IKPiBhbnl0aGluZy4KPiBJIG1lYW4gdXNpbmcgdGhlIGRyYmQ6
IHN5bnRheCAoYXMgZGVzY3JpYmVkIGluIHRoZSBEUkJEIHdlYnNpdGUpCj4gIG9yIHVzaW5nIHRo
ZQo+ICJzY3JpcHQ9ZHJiZCxiYWNrZW5kdHlwZT1waHksZm9ybWF0PXJhdyx0YXJnZXQ9cmVzb3Vy
Y2VOYW1lIiBzeW50YXggCj4gaW4KPiB4bC4KPiDCoAo+IMKgSSBoYXZlIHRyaWVkIGFuZCBpdCBk
b2VzbnQgd29yay4geGwgZGVmYXVsdHMgKGhhcmRjb2RlZD8pIHRvIHRhcAo+IGJhY2tlbmQuCj4g
ZG9pbmcgYSBncmVwIGluIHRoZSB0b29scy9saWJ4bCBkaXJlY3RvcnksIEkgY2FuIHNlZSB0aGF0
IHRoZXJlIGlzIG5vCj4gaW1wbGVtZW50YXRpb24KPiAgZm9yIGludm9raW5nIHRoZSBzY3JpcHQg
c3VwcGxpZWQgYXMgcGFydCBvZiBkaXNrIHNwZWMuCj4KPiBpZiAoZGlzay0+c2NyaXB0KSB7Cj4g
wqDCoMKgwqDCoMKgwqAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJFeHRlcm5h
bCBibG9jawo+IHNjcmlwdHMiCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
ICIgbm90IHlldCBzdXBwb3J0ZWQsIHNvcnJ5Iik7Cj4gIMKgwqDCoMKgwqDCoMKgIHJjID0gRVJS
T1JfSU5WQUw7Cj4gwqDCoMKgwqDCoMKgwqAgZ290byBvdXRfZnJlZTsKPiDCoMKgwqAgfQo+Cj4g
wqAKCgpUaGF0J3MgY29vbCwgYW5kIGV4cGxhaW5zIGFsb3QuICBJIGhhZCBub3QgZmlndXJlZCB0
aGF0IGxpYnhsIGRpZG4ndCAKaGF2ZSB0aGUgY2FwYWJpbGl0eSBvZiBleGVjdXRpbmcgYmxvY2sg
c2NyaXB0cy4gIEkgd2lsbCB3YWl0IHBhdGllbnRseSAKYW5kIHRyeSB0byBhc3Npc3QgaW4gYW55
IHdheSB0byB0ZXN0IGFueSBjaGFuZ2VzIG5lZWRlZCB0byBwcm92aWRlIGxpYnhsIApzdXBwb3J0
IHRvIHJlbXVzLgpNaWtlCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:48:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvNt-0007iT-8n; Tue, 22 Nov 2011 18:47:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RSvNs-0007iL-GD
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:47:56 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321987646!2611855!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3797 invoked from network); 22 Nov 2011 18:47:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 18:47:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 18:47:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 18:47:26 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RSvNO-0006HX-E2;
	Tue, 22 Nov 2011 18:47:26 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RSvNB-0003Qj-AR;
	Tue, 22 Nov 2011 18:47:13 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 22 Nov 2011 18:47:12 +0000
Message-ID: <1321987632-13156-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Ian.Jackson@eu.citrix.com, Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen: Don't redefine libpci (3.1.7) defines.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


These values are already defined by the libpci heders in the version
3.1.7.

PCI_STATUS_66MHZ
PCI_STATUS_RESERVED2
PCI_STATUS_FAST_BACK
PCI_MSIX_TABSIZE

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pci.h    |    6 ++++++
 hw/pt-msi.h |    2 ++
 2 files changed, 8 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-qemu-xen-Don-t-redefine-libpci-3.1.7-defines.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-qemu-xen-Don-t-redefine-libpci-3.1.7-defines.patch"

diff --git a/hw/pci.h b/hw/pci.h
index e4cc79a..e2c1fd8 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -177,9 +177,15 @@ typedef struct PCIIORegion {
 #define PCI_STATUS_RESERVED1	0x007
 #define PCI_STATUS_INT_STATUS	0x008
 #define PCI_STATUS_CAPABILITIES	0x010
+#ifndef PCI_STATUS_66MHZ
 #define PCI_STATUS_66MHZ	0x020
+#endif
+#ifndef PCI_STATUS_RESERVED2
 #define PCI_STATUS_RESERVED2	0x040
+#endif
+#ifndef PCI_STATUS_FAST_BACK
 #define PCI_STATUS_FAST_BACK	0x080
+#endif
 #define PCI_STATUS_DEVSEL	0x600
 
 #define PCI_STATUS_RESERVED_MASK_LO (PCI_STATUS_RESERVED1 | \
diff --git a/hw/pt-msi.h b/hw/pt-msi.h
index 9664f89..108ac8e 100644
--- a/hw/pt-msi.h
+++ b/hw/pt-msi.h
@@ -26,7 +26,9 @@
 /* MSI-X */
 #define  PCI_MSIX_ENABLE    0x8000
 #define  PCI_MSIX_MASK      0x4000
+#ifndef PCI_MSIX_TABSIZE
 #define  PCI_MSIX_TABSIZE   0x03ff
+#endif
 #define PCI_MSIX_TABLE      4
 #define PCI_MSIX_PBA        8
 #define  PCI_MSIX_BIR       0x7

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:48:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvNt-0007iT-8n; Tue, 22 Nov 2011 18:47:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RSvNs-0007iL-GD
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:47:56 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1321987646!2611855!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3797 invoked from network); 22 Nov 2011 18:47:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 18:47:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 18:47:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 18:47:26 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RSvNO-0006HX-E2;
	Tue, 22 Nov 2011 18:47:26 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RSvNB-0003Qj-AR;
	Tue, 22 Nov 2011 18:47:13 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 22 Nov 2011 18:47:12 +0000
Message-ID: <1321987632-13156-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Ian.Jackson@eu.citrix.com, Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen: Don't redefine libpci (3.1.7) defines.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


These values are already defined by the libpci heders in the version
3.1.7.

PCI_STATUS_66MHZ
PCI_STATUS_RESERVED2
PCI_STATUS_FAST_BACK
PCI_MSIX_TABSIZE

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pci.h    |    6 ++++++
 hw/pt-msi.h |    2 ++
 2 files changed, 8 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-qemu-xen-Don-t-redefine-libpci-3.1.7-defines.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-qemu-xen-Don-t-redefine-libpci-3.1.7-defines.patch"

diff --git a/hw/pci.h b/hw/pci.h
index e4cc79a..e2c1fd8 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -177,9 +177,15 @@ typedef struct PCIIORegion {
 #define PCI_STATUS_RESERVED1	0x007
 #define PCI_STATUS_INT_STATUS	0x008
 #define PCI_STATUS_CAPABILITIES	0x010
+#ifndef PCI_STATUS_66MHZ
 #define PCI_STATUS_66MHZ	0x020
+#endif
+#ifndef PCI_STATUS_RESERVED2
 #define PCI_STATUS_RESERVED2	0x040
+#endif
+#ifndef PCI_STATUS_FAST_BACK
 #define PCI_STATUS_FAST_BACK	0x080
+#endif
 #define PCI_STATUS_DEVSEL	0x600
 
 #define PCI_STATUS_RESERVED_MASK_LO (PCI_STATUS_RESERVED1 | \
diff --git a/hw/pt-msi.h b/hw/pt-msi.h
index 9664f89..108ac8e 100644
--- a/hw/pt-msi.h
+++ b/hw/pt-msi.h
@@ -26,7 +26,9 @@
 /* MSI-X */
 #define  PCI_MSIX_ENABLE    0x8000
 #define  PCI_MSIX_MASK      0x4000
+#ifndef PCI_MSIX_TABSIZE
 #define  PCI_MSIX_TABSIZE   0x03ff
+#endif
 #define PCI_MSIX_TABLE      4
 #define PCI_MSIX_PBA        8
 #define  PCI_MSIX_BIR       0x7

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:48:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvOX-0007kF-Mi; Tue, 22 Nov 2011 18:48:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSvOW-0007jp-5I
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:48:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1321987687!4484347!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24696 invoked from network); 22 Nov 2011 18:48:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 18:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072408"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 18:48:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 18:48:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSvO2-0006Hn-TV; Tue, 22 Nov 2011 18:48:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSvO2-0001Fs-Ru;
	Tue, 22 Nov 2011 18:48:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.61030.71499.197458@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 18:48:06 +0000
To: Jonathan Davies <jonathan.davies@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during
	some	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jonathan Davies writes ("[Xen-devel] [PATCH] [OCaml] Release the global lock during some hypercalls"):
> Since libxc is re-entrant, there is no need for the OCaml bindings to prevent more than one thread from entering libxc concurrently.

Well, libxc is supposed to be re-entrant apart from certain calls,
yes.

As the main user of the ocaml bindings is xapi, can you confirm that
you've run this change through a good test of xapi (eg, the Citrix
XenRT suite) ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:48:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvOX-0007kF-Mi; Tue, 22 Nov 2011 18:48:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSvOW-0007jp-5I
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:48:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1321987687!4484347!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24696 invoked from network); 22 Nov 2011 18:48:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 18:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072408"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 18:48:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 18:48:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSvO2-0006Hn-TV; Tue, 22 Nov 2011 18:48:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSvO2-0001Fs-Ru;
	Tue, 22 Nov 2011 18:48:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.61030.71499.197458@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 18:48:06 +0000
To: Jonathan Davies <jonathan.davies@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during
	some	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jonathan Davies writes ("[Xen-devel] [PATCH] [OCaml] Release the global lock during some hypercalls"):
> Since libxc is re-entrant, there is no need for the OCaml bindings to prevent more than one thread from entering libxc concurrently.

Well, libxc is supposed to be re-entrant apart from certain calls,
yes.

As the main user of the ocaml bindings is xapi, can you confirm that
you've run this change through a good test of xapi (eg, the Citrix
XenRT suite) ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:50:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:50:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvQ4-0007sA-CU; Tue, 22 Nov 2011 18:50:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSvQ2-0007rV-Nu
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:50:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321987781!2616749!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5785 invoked from network); 22 Nov 2011 18:49:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 18:49:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 18:49:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 18:49:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSvPY-0006IR-Qc; Tue, 22 Nov 2011 18:49:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSvPY-0001m0-Pv;
	Tue, 22 Nov 2011 18:49:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.61124.781634.106748@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 18:49:40 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1321987632-13156-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1321987632-13156-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Don't redefine libpci (3.1.7)
	defines.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jean Guyader writes ("[PATCH] qemu-xen: Don't redefine libpci (3.1.7) defines."):
> These values are already defined by the libpci heders in the version
> 3.1.7.

Applied, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:50:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:50:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvQ4-0007sA-CU; Tue, 22 Nov 2011 18:50:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSvQ2-0007rV-Nu
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:50:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1321987781!2616749!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5785 invoked from network); 22 Nov 2011 18:49:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 18:49:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 18:49:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 18:49:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSvPY-0006IR-Qc; Tue, 22 Nov 2011 18:49:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSvPY-0001m0-Pv;
	Tue, 22 Nov 2011 18:49:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.61124.781634.106748@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 18:49:40 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1321987632-13156-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1321987632-13156-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Don't redefine libpci (3.1.7)
	defines.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jean Guyader writes ("[PATCH] qemu-xen: Don't redefine libpci (3.1.7) defines."):
> These values are already defined by the libpci heders in the version
> 3.1.7.

Applied, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:52:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvRv-00082x-Ul; Tue, 22 Nov 2011 18:52:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSvRu-00082b-Nh
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:52:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1321987897!2616531!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29472 invoked from network); 22 Nov 2011 18:51:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 18:51:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 18:51:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 18:51:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSvRF-0006J6-Jm; Tue, 22 Nov 2011 18:51:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSvRF-0001pi-J6;
	Tue, 22 Nov 2011 18:51:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.61229.579587.902978@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 18:51:25 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0bb3127d015a55802644.1321270494@cosworth.uk.xensource.com>
References: <0bb3127d015a55802644.1321270494@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] docs: remove some fatally out of
	date	documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] docs: remove some fatally out of date documentation"):
> docs: remove some fatally out of date documentation

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:52:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvRv-00082x-Ul; Tue, 22 Nov 2011 18:52:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSvRu-00082b-Nh
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:52:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1321987897!2616531!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29472 invoked from network); 22 Nov 2011 18:51:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 18:51:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 18:51:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 18:51:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSvRF-0006J6-Jm; Tue, 22 Nov 2011 18:51:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSvRF-0001pi-J6;
	Tue, 22 Nov 2011 18:51:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.61229.579587.902978@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 18:51:25 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0bb3127d015a55802644.1321270494@cosworth.uk.xensource.com>
References: <0bb3127d015a55802644.1321270494@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] docs: remove some fatally out of
	date	documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] docs: remove some fatally out of date documentation"):
> docs: remove some fatally out of date documentation

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:59:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvZ9-0008Oz-Tw; Tue, 22 Nov 2011 18:59:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RSvZ8-0008On-Do
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:59:34 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1321988345!2619601!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20909 invoked from network); 22 Nov 2011 18:59:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 18:59:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 18:59:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 18:59:05 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RSvYe-0006M2-Sa;
	Tue, 22 Nov 2011 18:59:04 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RSvYR-0003Ry-LT;
	Tue, 22 Nov 2011 18:58:51 +0000
Date: Tue, 22 Nov 2011 18:58:51 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111122185851.GB12317@spongy.cam.xci-test.com>
References: <1321987632-13156-1-git-send-email-jean.guyader@eu.citrix.com>
	<20171.61124.781634.106748@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20171.61124.781634.106748@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Don't redefine libpci (3.1.7)
	defines.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11 06:49, Ian Jackson wrote:
> Jean Guyader writes ("[PATCH] qemu-xen: Don't redefine libpci (3.1.7) defines."):
> > These values are already defined by the libpci heders in the version
> > 3.1.7.
> 
> Applied, thanks.
> 

Can it go to 4.1 as well?

Thanks,
Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 18:59:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 18:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvZ9-0008Oz-Tw; Tue, 22 Nov 2011 18:59:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RSvZ8-0008On-Do
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 18:59:34 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1321988345!2619601!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20909 invoked from network); 22 Nov 2011 18:59:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 18:59:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 18:59:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 18:59:05 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RSvYe-0006M2-Sa;
	Tue, 22 Nov 2011 18:59:04 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RSvYR-0003Ry-LT;
	Tue, 22 Nov 2011 18:58:51 +0000
Date: Tue, 22 Nov 2011 18:58:51 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111122185851.GB12317@spongy.cam.xci-test.com>
References: <1321987632-13156-1-git-send-email-jean.guyader@eu.citrix.com>
	<20171.61124.781634.106748@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20171.61124.781634.106748@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Don't redefine libpci (3.1.7)
	defines.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11 06:49, Ian Jackson wrote:
> Jean Guyader writes ("[PATCH] qemu-xen: Don't redefine libpci (3.1.7) defines."):
> > These values are already defined by the libpci heders in the version
> > 3.1.7.
> 
> Applied, thanks.
> 

Can it go to 4.1 as well?

Thanks,
Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 19:04:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 19:04:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvdK-00008v-N6; Tue, 22 Nov 2011 19:03:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSvdK-00008q-1x
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 19:03:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1321988581!49515013!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20587 invoked from network); 22 Nov 2011 19:03:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 19:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 19:03:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 19:03:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSvcv-0006Nn-Kh; Tue, 22 Nov 2011 19:03:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSvcv-0001sN-Ju;
	Tue, 22 Nov 2011 19:03:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.61953.605564.862292@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 19:03:29 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <20111122185851.GB12317@spongy.cam.xci-test.com>
References: <1321987632-13156-1-git-send-email-jean.guyader@eu.citrix.com>
	<20171.61124.781634.106748@mariner.uk.xensource.com>
	<20111122185851.GB12317@spongy.cam.xci-test.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Don't redefine libpci (3.1.7)
	defines.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jean Guyader writes ("Re: [PATCH] qemu-xen: Don't redefine libpci (3.1.7) defines."):
> Can it go to 4.1 as well?

Sure.  I have pushed it to qemu-xen-4.1-testing.git and updated the
QEMU_TAG in xen-4.1-testing.hg.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 19:04:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 19:04:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSvdK-00008v-N6; Tue, 22 Nov 2011 19:03:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSvdK-00008q-1x
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 19:03:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1321988581!49515013!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20587 invoked from network); 22 Nov 2011 19:03:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 19:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 19:03:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 19:03:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RSvcv-0006Nn-Kh; Tue, 22 Nov 2011 19:03:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RSvcv-0001sN-Ju;
	Tue, 22 Nov 2011 19:03:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20171.61953.605564.862292@mariner.uk.xensource.com>
Date: Tue, 22 Nov 2011 19:03:29 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <20111122185851.GB12317@spongy.cam.xci-test.com>
References: <1321987632-13156-1-git-send-email-jean.guyader@eu.citrix.com>
	<20171.61124.781634.106748@mariner.uk.xensource.com>
	<20111122185851.GB12317@spongy.cam.xci-test.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Don't redefine libpci (3.1.7)
	defines.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jean Guyader writes ("Re: [PATCH] qemu-xen: Don't redefine libpci (3.1.7) defines."):
> Can it go to 4.1 as well?

Sure.  I have pushed it to qemu-xen-4.1-testing.git and updated the
QEMU_TAG in xen-4.1-testing.hg.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 19:28:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 19:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSw0S-0000TF-4T; Tue, 22 Nov 2011 19:27:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSw0Q-0000T5-Fj
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 19:27:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1321990037!2594644!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20914 invoked from network); 22 Nov 2011 19:27:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 19:27:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 19:27:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 19:27:16 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSvzw-0006XH-HJ;
	Tue, 22 Nov 2011 19:27:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSvzw-0000ST-4u;
	Tue, 22 Nov 2011 19:27:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9958-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 19:27:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9958: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9958 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9958/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     10 guest-saverestore          fail REGR. vs. 9956
 test-amd64-amd64-win         14 guest-start.2              fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d3859e348951
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Keir Fraser <keir@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24177:d3859e348951
tag:         tip
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 19:28:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 19:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSw0S-0000TF-4T; Tue, 22 Nov 2011 19:27:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSw0Q-0000T5-Fj
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 19:27:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1321990037!2594644!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20914 invoked from network); 22 Nov 2011 19:27:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 19:27:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9072949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 19:27:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 19:27:16 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSvzw-0006XH-HJ;
	Tue, 22 Nov 2011 19:27:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSvzw-0000ST-4u;
	Tue, 22 Nov 2011 19:27:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9958-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 19:27:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9958: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9958 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9958/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     10 guest-saverestore          fail REGR. vs. 9956
 test-amd64-amd64-win         14 guest-start.2              fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d3859e348951
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Keir Fraser <keir@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24177:d3859e348951
tag:         tip
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 52834188eedfbbca5636fd869d4c86b3b3044439
Author: Ian Campbell <ian.campbell@citrix.com>
Date:   Tue Nov 1 18:42:55 2011 +0000

    qemu-xen: remove i386-dm/README.hvm-pv-magic-ioport-disable
    
    I have just proposed a patch to add this to xen-unstable.hg as
    docs/misc/hvm-emulated-unplug.markdown. This repo is not a place where people
    look for docs, plus we are transitioning to upstream qemu.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 19:36:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 19:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSw8g-0000gC-8W; Tue, 22 Nov 2011 19:36:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSw8e-0000g4-Mc
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 19:36:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1321990547!2615969!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26549 invoked from network); 22 Nov 2011 19:35:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 19:35:47 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9073048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 19:35:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 19:35:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSw8A-0006aQ-Dz;
	Tue, 22 Nov 2011 19:35:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSw8A-00009z-DL;
	Tue, 22 Nov 2011 19:35:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9957-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 19:35:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9957: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9957 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9957/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4f4763690d74
baseline version:
 xen                  5a00ccfc6391

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=4f4763690d74
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 4f4763690d74
+ branch=xen-4.1-testing
+ revision=4f4763690d74
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 4f4763690d74 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 6 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 19:36:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 19:36:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSw8g-0000gC-8W; Tue, 22 Nov 2011 19:36:18 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSw8e-0000g4-Mc
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 19:36:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1321990547!2615969!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26549 invoked from network); 22 Nov 2011 19:35:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 19:35:47 -0000
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; 
   d="scan'208";a="9073048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 19:35:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 19:35:46 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSw8A-0006aQ-Dz;
	Tue, 22 Nov 2011 19:35:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSw8A-00009z-DL;
	Tue, 22 Nov 2011 19:35:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9957-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 19:35:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9957: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9957 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9957/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4f4763690d74
baseline version:
 xen                  5a00ccfc6391

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=4f4763690d74
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing 4f4763690d74
+ branch=xen-4.1-testing
+ revision=4f4763690d74
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 4f4763690d74 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 6 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 19:53:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 19:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSwOs-00016i-CO; Tue, 22 Nov 2011 19:53:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1RSwOq-00016d-Ja
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 19:53:00 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321991551!4189700!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21824 invoked from network); 22 Nov 2011 19:52:31 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 19:52:31 -0000
Received: by fanq24 with SMTP id q24so45939fan.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 11:52:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=4Udz8qIKSuF1PzfOgEtJqKTKfrx/MZQ9/FmT/pqBvDs=;
	b=HdqRbwZ6vt6RQh6Rq1lMVm++Knf1X0DP+jB26LjmDejiePaz3ACU+BkLt/jexEHFjv
	bdmTjHA3c3SrLlUG74pGZNB15lPnBf4vgODuimrGPBDbf0b90XgORaY0jU52AzpsxqoF
	GOeMXN1pQo/el5/0YFABu3O8GnnTXTcbbCjw0=
MIME-Version: 1.0
Received: by 10.181.12.39 with SMTP id en7mr20416400wid.40.1321991551255; Tue,
	22 Nov 2011 11:52:31 -0800 (PST)
Received: by 10.216.153.39 with HTTP; Tue, 22 Nov 2011 11:52:31 -0800 (PST)
In-Reply-To: <CAMTrTqVYqJLmU-vhN=28Sv16_sdXO5V5SRQtbQCvnvb9QNNUWg@mail.gmail.com>
References: <CAMTrTqVYqJLmU-vhN=28Sv16_sdXO5V5SRQtbQCvnvb9QNNUWg@mail.gmail.com>
Date: Tue, 22 Nov 2011 14:52:31 -0500
Message-ID: <CAMTrTqVg9iAcfv+bL5=n0W+GDDbxH5ZPupa=_23FN6UnML7-zQ@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] what is the max number of page can be granted and
 mapped between two domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

By the way, the error message from Xen by xm dmesg is

(XEN) grant_table.c:266:d0 Bad flags (0) or dom (0). (expected dom 0)

Thanks.



On Tue, Nov 22, 2011 at 12:40 PM, Steven <wangwangkang@gmail.com> wrote:
> Hi,
> I am trying to share some memory pages between a domU and dom0.
> The domU calls gnttab_grant_foreign_access(domid, mfn, 0); to grant the its
> pages for accessing by dom0, and then dom0 calls
>
> gnttab_set_map_op(... remoteDomain) and HYPERVISOR_grant_table_op(...)
> to map the pages from domU.
> Everying works fine when the number of granted page is < 533
> However, when the number of granted page is >= 533, dom0 can not map
> the granted pages.
> The function HYPERVISOR_grant_table_op returns error.
>
> My question is whether the max number of mapped page is 533. If it is
> how can I changed this limit. Or if there is any bettter way to
> sharing a large chunk of memory (about 20MB) page between two domains.
> Thanks.
>
> - Steven
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 19:53:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 19:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSwOs-00016i-CO; Tue, 22 Nov 2011 19:53:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1RSwOq-00016d-Ja
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 19:53:00 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1321991551!4189700!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21824 invoked from network); 22 Nov 2011 19:52:31 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 19:52:31 -0000
Received: by fanq24 with SMTP id q24so45939fan.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 11:52:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=4Udz8qIKSuF1PzfOgEtJqKTKfrx/MZQ9/FmT/pqBvDs=;
	b=HdqRbwZ6vt6RQh6Rq1lMVm++Knf1X0DP+jB26LjmDejiePaz3ACU+BkLt/jexEHFjv
	bdmTjHA3c3SrLlUG74pGZNB15lPnBf4vgODuimrGPBDbf0b90XgORaY0jU52AzpsxqoF
	GOeMXN1pQo/el5/0YFABu3O8GnnTXTcbbCjw0=
MIME-Version: 1.0
Received: by 10.181.12.39 with SMTP id en7mr20416400wid.40.1321991551255; Tue,
	22 Nov 2011 11:52:31 -0800 (PST)
Received: by 10.216.153.39 with HTTP; Tue, 22 Nov 2011 11:52:31 -0800 (PST)
In-Reply-To: <CAMTrTqVYqJLmU-vhN=28Sv16_sdXO5V5SRQtbQCvnvb9QNNUWg@mail.gmail.com>
References: <CAMTrTqVYqJLmU-vhN=28Sv16_sdXO5V5SRQtbQCvnvb9QNNUWg@mail.gmail.com>
Date: Tue, 22 Nov 2011 14:52:31 -0500
Message-ID: <CAMTrTqVg9iAcfv+bL5=n0W+GDDbxH5ZPupa=_23FN6UnML7-zQ@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] what is the max number of page can be granted and
 mapped between two domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

By the way, the error message from Xen by xm dmesg is

(XEN) grant_table.c:266:d0 Bad flags (0) or dom (0). (expected dom 0)

Thanks.



On Tue, Nov 22, 2011 at 12:40 PM, Steven <wangwangkang@gmail.com> wrote:
> Hi,
> I am trying to share some memory pages between a domU and dom0.
> The domU calls gnttab_grant_foreign_access(domid, mfn, 0); to grant the its
> pages for accessing by dom0, and then dom0 calls
>
> gnttab_set_map_op(... remoteDomain) and HYPERVISOR_grant_table_op(...)
> to map the pages from domU.
> Everying works fine when the number of granted page is < 533
> However, when the number of granted page is >= 533, dom0 can not map
> the granted pages.
> The function HYPERVISOR_grant_table_op returns error.
>
> My question is whether the max number of mapped page is 533. If it is
> how can I changed this limit. Or if there is any bettter way to
> sharing a large chunk of memory (about 20MB) page between two domains.
> Thanks.
>
> - Steven
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 20:26:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 20:26:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSwv8-0001e3-6r; Tue, 22 Nov 2011 20:26:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSwv6-0001dr-S5
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 20:26:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321993551!4196129!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13116 invoked from network); 22 Nov 2011 20:25:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 20:25:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,555,1315180800"; 
   d="scan'208";a="9073700"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 20:25:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 20:25:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSwuc-0006uj-Ob;
	Tue, 22 Nov 2011 20:25:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSwuc-0007xK-O8;
	Tue, 22 Nov 2011 20:25:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9959-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 20:25:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9959: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9959 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9959/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  4ecd3615e726
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24184:4ecd3615e726
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 20:26:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 20:26:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSwv8-0001e3-6r; Tue, 22 Nov 2011 20:26:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSwv6-0001dr-S5
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 20:26:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1321993551!4196129!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13116 invoked from network); 22 Nov 2011 20:25:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 20:25:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,555,1315180800"; 
   d="scan'208";a="9073700"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 20:25:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 20:25:51 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSwuc-0006uj-Ob;
	Tue, 22 Nov 2011 20:25:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSwuc-0007xK-O8;
	Tue, 22 Nov 2011 20:25:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9959-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 20:25:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9959: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9959 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9959/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  4ecd3615e726
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24184:4ecd3615e726
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:02:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxTF-00024O-EI; Tue, 22 Nov 2011 21:01:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSxTD-00024J-H7
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:01:35 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1321995664!2623134!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29393 invoked from network); 22 Nov 2011 21:01:05 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 21:01:05 -0000
Received: by qyk31 with SMTP id 31so710183qyk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 13:01:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=GymJa3GrnoJBKX4E62khexkkYEAex5qMug2L/o9zYsQ=;
	b=sHXRsUIL4rXHpV9ik8eH4PEUSIBttFaRQo58IVOOtoAJaxig3XWSfTVttqcmIMQzth
	2idk/U3uxJobXXCFWseH9HDxCxezAVLRu8pFCr3xnX00WYyKidM/eq+sN/WgJkqcaFVd
	Ypmwyd1tRrRiL99lkoKc/AgWT89fwBJA8tJs0=
MIME-Version: 1.0
Received: by 10.68.15.232 with SMTP id a8mr1371650pbd.129.1321995663645; Tue,
	22 Nov 2011 13:01:03 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Tue, 22 Nov 2011 13:01:03 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
Date: Wed, 23 Nov 2011 05:01:03 +0800
Message-ID: <CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 7:18 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 22 Nov 2011, Teck Choon Giam wrote:
>> On Tue, Nov 22, 2011 at 5:09 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> > On Tue, 2011-11-22 at 08:38 +0000, Teck Choon Giam wrote:
>> >> On Tue, Nov 22, 2011 at 4:31 PM, Ian Campbell <Ian.Campbell@citrix.co=
m> wrote:
>> >> > On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
>> >> >> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix=
.com> wrote:
>> >> >> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
>> >> >> > [...]
>> >> >> >> memory =3D 15360
>> >> >> >> maxmem =3D 15360
>> >> >> > [...]
>> >> >> >> How much RAM does the host system have? What are your hyperviso=
r and
>> >> >> >> > dom0 command lines.
>> >> >> >>
>> >> >> >> 16GB RAM.
>> >> >> >
>> >> >> > So you are assigning 15GB out of a total of 16GB to the guest wh=
ich
>> >> >> > necessitates ballooning dom0 from 16GB down to 1GB.
>> >> >>
>> >> >> I actually set dom0-min-mem 512 in xend-config.sxp as well.
>> >> >
>> >> > xl/libxl don't use this configuration file.
>> >>
>> >> Oh... now then I know. =A0I always test with both xl and xm for my
>> >> testing machine(s) to see any differences as there are... ...
>> >
>> > I believe xend and xl do behave slightly differently wrt dom0 auto
>> > ballooning.
>> >
>> >>
>> >> >
>> >> >>
>> >> >> >
>> >> >> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
>> >> >> >> =A0 =A0 =A0 root (hd0,0)
>> >> >> >> =A0 =A0 =A0 kernel /xen.gz dom0_mem=3D512M loglvl=3Dall guest_l=
oglvl=3Dall cpuidle=3D0 cpufreq=3Dnone
>> >> >> >
>> >> >> > But you have already forced the dom0_mem to 512M. I suspect this=
 is
>> >> >> > colluding with the above ballooning to make it look as if dom0 s=
hould be
>> >> >> > ballooned to <128M, which causes xl to print a warning message. =
Perhaps
>> >> >> > someone who understands this stuff can comment on whether or not=
 this
>> >> >> > should be the case.
>> >> >> >
>> >> >> > Can you try setting "autoballoon=3D0" in /etc/xl.cfg.
>> >> >>
>> >> >> You mean /etc/xen/xl.conf? =A0I have done so and guess what? =A0IT=
 WORKS!!! :)
>> >> >
>> >> > Great.
>> >>
>> >> That means default value changed if it is unset for autoballoon?
>> >> Original one is commented with #autoballoon =3D 1 in /etc/xen/xl.conf=
 so
>> >> it is unset I guess so the default value for autoballoon for c/s 23110
>> >> is autoballoon=3D0 where c/s 23190 is autoballoon=3D1? =A0Just some
>> >> guessing... ...
>
> Autoballoon and dom0_mem are incompatible.
> I don't think there are any relevant differences between 23110 and 23190
> on xen-unstable, maybe you used to start dom0 without dom0_mem before?

Nope... all my servers will always have those dom0_mem set.  It is
from xen-4.1-testing not xen-unstable for the two changeset.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:02:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:02:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxTF-00024O-EI; Tue, 22 Nov 2011 21:01:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RSxTD-00024J-H7
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:01:35 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1321995664!2623134!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29393 invoked from network); 22 Nov 2011 21:01:05 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 21:01:05 -0000
Received: by qyk31 with SMTP id 31so710183qyk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 13:01:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=GymJa3GrnoJBKX4E62khexkkYEAex5qMug2L/o9zYsQ=;
	b=sHXRsUIL4rXHpV9ik8eH4PEUSIBttFaRQo58IVOOtoAJaxig3XWSfTVttqcmIMQzth
	2idk/U3uxJobXXCFWseH9HDxCxezAVLRu8pFCr3xnX00WYyKidM/eq+sN/WgJkqcaFVd
	Ypmwyd1tRrRiL99lkoKc/AgWT89fwBJA8tJs0=
MIME-Version: 1.0
Received: by 10.68.15.232 with SMTP id a8mr1371650pbd.129.1321995663645; Tue,
	22 Nov 2011 13:01:03 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Tue, 22 Nov 2011 13:01:03 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
Date: Wed, 23 Nov 2011 05:01:03 +0800
Message-ID: <CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 7:18 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Tue, 22 Nov 2011, Teck Choon Giam wrote:
>> On Tue, Nov 22, 2011 at 5:09 PM, Ian Campbell <Ian.Campbell@citrix.com> =
wrote:
>> > On Tue, 2011-11-22 at 08:38 +0000, Teck Choon Giam wrote:
>> >> On Tue, Nov 22, 2011 at 4:31 PM, Ian Campbell <Ian.Campbell@citrix.co=
m> wrote:
>> >> > On Tue, 2011-11-22 at 08:30 +0000, Teck Choon Giam wrote:
>> >> >> On Tue, Nov 22, 2011 at 4:18 PM, Ian Campbell <Ian.Campbell@citrix=
.com> wrote:
>> >> >> > On Tue, 2011-11-22 at 07:56 +0000, Teck Choon Giam wrote:
>> >> >> > [...]
>> >> >> >> memory =3D 15360
>> >> >> >> maxmem =3D 15360
>> >> >> > [...]
>> >> >> >> How much RAM does the host system have? What are your hyperviso=
r and
>> >> >> >> > dom0 command lines.
>> >> >> >>
>> >> >> >> 16GB RAM.
>> >> >> >
>> >> >> > So you are assigning 15GB out of a total of 16GB to the guest wh=
ich
>> >> >> > necessitates ballooning dom0 from 16GB down to 1GB.
>> >> >>
>> >> >> I actually set dom0-min-mem 512 in xend-config.sxp as well.
>> >> >
>> >> > xl/libxl don't use this configuration file.
>> >>
>> >> Oh... now then I know. =A0I always test with both xl and xm for my
>> >> testing machine(s) to see any differences as there are... ...
>> >
>> > I believe xend and xl do behave slightly differently wrt dom0 auto
>> > ballooning.
>> >
>> >>
>> >> >
>> >> >>
>> >> >> >
>> >> >> >> title Scientific Linux (2.6.32.47-0.xen.pvops.choon.sl6)
>> >> >> >> =A0 =A0 =A0 root (hd0,0)
>> >> >> >> =A0 =A0 =A0 kernel /xen.gz dom0_mem=3D512M loglvl=3Dall guest_l=
oglvl=3Dall cpuidle=3D0 cpufreq=3Dnone
>> >> >> >
>> >> >> > But you have already forced the dom0_mem to 512M. I suspect this=
 is
>> >> >> > colluding with the above ballooning to make it look as if dom0 s=
hould be
>> >> >> > ballooned to <128M, which causes xl to print a warning message. =
Perhaps
>> >> >> > someone who understands this stuff can comment on whether or not=
 this
>> >> >> > should be the case.
>> >> >> >
>> >> >> > Can you try setting "autoballoon=3D0" in /etc/xl.cfg.
>> >> >>
>> >> >> You mean /etc/xen/xl.conf? =A0I have done so and guess what? =A0IT=
 WORKS!!! :)
>> >> >
>> >> > Great.
>> >>
>> >> That means default value changed if it is unset for autoballoon?
>> >> Original one is commented with #autoballoon =3D 1 in /etc/xen/xl.conf=
 so
>> >> it is unset I guess so the default value for autoballoon for c/s 23110
>> >> is autoballoon=3D0 where c/s 23190 is autoballoon=3D1? =A0Just some
>> >> guessing... ...
>
> Autoballoon and dom0_mem are incompatible.
> I don't think there are any relevant differences between 23110 and 23190
> on xen-unstable, maybe you used to start dom0 without dom0_mem before?

Nope... all my servers will always have those dom0_mem set.  It is
from xen-4.1-testing not xen-unstable for the two changeset.

Thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxfD-0002KF-PK; Tue, 22 Nov 2011 21:13:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSxfB-0002K9-UL
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:13:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321996408!4573179!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11312 invoked from network); 22 Nov 2011 21:13:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 21:13:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321996408; l=644;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=WFK5rBS2heG4uZic74H+/VSx49M=;
	b=oawt9Adh2jQ5Ccg8ybiUOpbiQ4PD7SjSL9sMe4VeV5DfrcMMa5ULnlsBkwA4w36Srwi
	sluGjgCL+W26iFdlCJe8XxRROjx2tDti6p5rvTDAI+/dwEl4MPI4PHPbyY4gJafGeSnjh
	0ThSC1RuoJSjaiKUevWyL4Au19nudOMzNVo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (klopstock mo12) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N03cdcnAMICT9Q
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:24 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 8EA7A18636
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:23 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1321996402@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 22 Nov 2011 22:13:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 3] RFC: wait queue usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


The following series is my current state of an attempt to use wait queues for
xenpaging and mem_event handling. I post it here for review and comments.

Olaf


 xen/arch/x86/hvm/hvm.c          |    6 +-
 xen/arch/x86/mm/mem_event.c     |   82 +++++++++++++++++++++++++++++++++-------
 xen/arch/x86/mm/mem_sharing.c   |   31 +++++----------
 xen/arch/x86/mm/p2m-ept.c       |   46 +++++++++++++++++++---
 xen/arch/x86/mm/p2m.c           |   56 ++++++++++++++-------------
 xen/common/domain.c             |    5 ++
 xen/include/asm-x86/mem_event.h |    4 -
 xen/include/asm-x86/p2m.h       |    1 
 xen/include/xen/sched.h         |   32 +++++++++++----
 9 files changed, 183 insertions(+), 80 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:14:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:14:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxfD-0002KF-PK; Tue, 22 Nov 2011 21:13:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSxfB-0002K9-UL
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:13:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1321996408!4573179!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11312 invoked from network); 22 Nov 2011 21:13:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 21:13:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321996408; l=644;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=WFK5rBS2heG4uZic74H+/VSx49M=;
	b=oawt9Adh2jQ5Ccg8ybiUOpbiQ4PD7SjSL9sMe4VeV5DfrcMMa5ULnlsBkwA4w36Srwi
	sluGjgCL+W26iFdlCJe8XxRROjx2tDti6p5rvTDAI+/dwEl4MPI4PHPbyY4gJafGeSnjh
	0ThSC1RuoJSjaiKUevWyL4Au19nudOMzNVo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (klopstock mo12) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N03cdcnAMICT9Q
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:24 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 8EA7A18636
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:23 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1321996402@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 22 Nov 2011 22:13:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 3] RFC: wait queue usage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


The following series is my current state of an attempt to use wait queues for
xenpaging and mem_event handling. I post it here for review and comments.

Olaf


 xen/arch/x86/hvm/hvm.c          |    6 +-
 xen/arch/x86/mm/mem_event.c     |   82 +++++++++++++++++++++++++++++++++-------
 xen/arch/x86/mm/mem_sharing.c   |   31 +++++----------
 xen/arch/x86/mm/p2m-ept.c       |   46 +++++++++++++++++++---
 xen/arch/x86/mm/p2m.c           |   56 ++++++++++++++-------------
 xen/common/domain.c             |    5 ++
 xen/include/asm-x86/mem_event.h |    4 -
 xen/include/asm-x86/p2m.h       |    1 
 xen/include/xen/sched.h         |   32 +++++++++++----
 9 files changed, 183 insertions(+), 80 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxfI-0002KS-9A; Tue, 22 Nov 2011 21:14:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSxfG-0002KA-6h
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:14:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321996412!2621127!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22955 invoked from network); 22 Nov 2011 21:13:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 21:13:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321996412; l=7301;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=q35aN+boVe96uPRfvpFBGGTp3PY=;
	b=cyEhSMkkX4KP4rrFdijf+mtGZ/nEbfKiYDFxYtoJc4XBUYtR51rtskLz/7KdsaavHI1
	zD4fnrYc7HScLW3w2DLKVhxyPw6JwKXIsLHyWMKrUKqynmVlS1/UCMPbpV0vvw2qpmsdy
	aPXRQHUev0lF/wDE1Du7GLQdIF49EdHMius=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (cohen mo5) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y059c4nAMJkWNK
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:24 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C19CA18637
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:23 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d347a8a36d2e7951f98a3d22866dce004484d95f
Message-Id: <d347a8a36d2e7951f98a.1321996403@probook.site>
In-Reply-To: <patchbomb.1321996402@probook.site>
References: <patchbomb.1321996402@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 22 Nov 2011 22:13:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 3] mem_event: move mem_event_domain out of
	struct domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321996135 -3600
# Node ID d347a8a36d2e7951f98a3d22866dce004484d95f
# Parent  d3859e348951cde6b211c5afb610ac1f12a909ec
mem_event: move mem_event_domain out of struct domain

An upcoming change increases the size of mem_event_domain. The result is a
build failure because struct domain gets larger than a page. Allocate the room
for the three mem_event_domain members at runtime.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4098,7 +4098,7 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_access);
+    rc = mem_event_check_ring(d, &d->mem_event->mem_access);
     if ( rc )
         return rc;
     
@@ -4121,7 +4121,7 @@ static int hvm_memory_event_traps(long p
         req.gla_valid = 1;
     }
     
-    mem_event_put_request(d, &d->mem_access, &req);
+    mem_event_put_request(d, &d->mem_event->mem_access, &req);
     
     return 1;
 }
diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -265,7 +265,7 @@ int mem_event_domctl(struct domain *d, x
     {
     case XEN_DOMCTL_MEM_EVENT_OP_PAGING:
     {
-        struct mem_event_domain *med = &d->mem_paging;
+        struct mem_event_domain *med = &d->mem_event->mem_paging;
         rc = -EINVAL;
 
         switch( mec->op )
@@ -310,7 +310,7 @@ int mem_event_domctl(struct domain *d, x
 
     case XEN_DOMCTL_MEM_EVENT_OP_ACCESS: 
     {
-        struct mem_event_domain *med = &d->mem_access;
+        struct mem_event_domain *med = &d->mem_event->mem_access;
         rc = -EINVAL;
 
         switch( mec->op )
@@ -333,7 +333,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(&d->mem_access);
+                rc = mem_event_disable(med);
         }
         break;
 
diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -281,12 +281,12 @@ static struct page_info* mem_sharing_all
     vcpu_pause_nosync(v);
     req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
 
-    if(mem_event_check_ring(d, &d->mem_share)) return page;
+    if(mem_event_check_ring(d, &d->mem_event->mem_share)) return page;
 
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
-    mem_event_put_request(d, &d->mem_share, &req);
+    mem_event_put_request(d, &d->mem_event->mem_share, &req);
 
     return page;
 }
@@ -301,7 +301,7 @@ int mem_sharing_sharing_resume(struct do
     mem_event_response_t rsp;
 
     /* Get request off the ring */
-    mem_event_get_response(&d->mem_share, &rsp);
+    mem_event_get_response(&d->mem_event->mem_share, &rsp);
 
     /* Unpause domain/vcpu */
     if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -885,7 +885,7 @@ void p2m_mem_paging_drop_page(struct dom
     mem_event_request_t req;
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_paging) == 0)
+    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) == 0)
     {
         /* Send release notification to pager */
         memset(&req, 0, sizeof(req));
@@ -893,7 +893,7 @@ void p2m_mem_paging_drop_page(struct dom
         req.gfn = gfn;
         req.vcpu_id = v->vcpu_id;
 
-        mem_event_put_request(d, &d->mem_paging, &req);
+        mem_event_put_request(d, &d->mem_event->mem_paging, &req);
     }
 }
 
@@ -928,7 +928,7 @@ void p2m_mem_paging_populate(struct doma
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_paging) )
+    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) )
         return;
 
     memset(&req, 0, sizeof(req));
@@ -959,7 +959,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_paging);
+        mem_event_put_req_producers(&d->mem_event->mem_paging);
         return;
     }
 
@@ -968,7 +968,7 @@ void p2m_mem_paging_populate(struct doma
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_paging, &req);
+    mem_event_put_request(d, &d->mem_event->mem_paging, &req);
 }
 
 /**
@@ -1048,7 +1048,7 @@ void p2m_mem_paging_resume(struct domain
     mfn_t mfn;
 
     /* Pull the response off the ring */
-    mem_event_get_response(&d->mem_paging, &rsp);
+    mem_event_get_response(&d->mem_event->mem_paging, &rsp);
 
     /* Fix p2m entry if the page was not dropped */
     if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
@@ -1101,7 +1101,7 @@ void p2m_mem_access_check(unsigned long 
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_access);
+    res = mem_event_check_ring(d, &d->mem_event->mem_access);
     if ( res < 0 ) 
     {
         /* No listener */
@@ -1145,7 +1145,7 @@ void p2m_mem_access_check(unsigned long 
     
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_access, &req);
+    mem_event_put_request(d, &d->mem_event->mem_access, &req);
 
     /* VCPU paused, mem event request sent */
 }
@@ -1155,7 +1155,7 @@ void p2m_mem_access_resume(struct p2m_do
     struct domain *d = p2m->domain;
     mem_event_response_t rsp;
 
-    mem_event_get_response(&d->mem_access, &rsp);
+    mem_event_get_response(&d->mem_event->mem_access, &rsp);
 
     /* Unpause domain */
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
diff -r d3859e348951 -r d347a8a36d2e xen/common/domain.c
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -304,6 +304,10 @@ struct domain *domain_create(
         init_status |= INIT_gnttab;
 
         poolid = 0;
+
+        d->mem_event = xzalloc(struct mem_event_per_domain);
+        if ( !d->mem_event )
+            goto fail;
     }
 
     if ( arch_domain_create(d, domcr_flags) != 0 )
@@ -335,6 +339,7 @@ struct domain *domain_create(
  fail:
     d->is_dying = DOMDYING_dead;
     atomic_set(&d->refcnt, DOMAIN_DESTROYED);
+    xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
     if ( init_status & INIT_gnttab )
diff -r d3859e348951 -r d347a8a36d2e xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -194,6 +194,16 @@ struct mem_event_domain
     int xen_port;
 };
 
+struct mem_event_per_domain
+{
+    /* Memory sharing support */
+    struct mem_event_domain mem_share;
+    /* Memory paging support */
+    struct mem_event_domain mem_paging;
+    /* Memory access support */
+    struct mem_event_domain mem_access;
+};
+
 struct domain
 {
     domid_t          domain_id;
@@ -318,12 +328,8 @@ struct domain
     /* Non-migratable and non-restoreable? */
     bool_t disable_migrate;
 
-    /* Memory sharing support */
-    struct mem_event_domain mem_share;
-    /* Memory paging support */
-    struct mem_event_domain mem_paging;
-    /* Memory access support */
-    struct mem_event_domain mem_access;
+    /* Various mem_events */
+    struct mem_event_per_domain *mem_event;
 
     /* Currently computed from union of all vcpu cpu-affinity masks. */
     nodemask_t node_affinity;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:14:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxfI-0002KS-9A; Tue, 22 Nov 2011 21:14:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSxfG-0002KA-6h
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:14:02 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1321996412!2621127!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22955 invoked from network); 22 Nov 2011 21:13:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 21:13:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321996412; l=7301;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=q35aN+boVe96uPRfvpFBGGTp3PY=;
	b=cyEhSMkkX4KP4rrFdijf+mtGZ/nEbfKiYDFxYtoJc4XBUYtR51rtskLz/7KdsaavHI1
	zD4fnrYc7HScLW3w2DLKVhxyPw6JwKXIsLHyWMKrUKqynmVlS1/UCMPbpV0vvw2qpmsdy
	aPXRQHUev0lF/wDE1Du7GLQdIF49EdHMius=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (cohen mo5) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y059c4nAMJkWNK
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:24 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C19CA18637
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:23 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: d347a8a36d2e7951f98a3d22866dce004484d95f
Message-Id: <d347a8a36d2e7951f98a.1321996403@probook.site>
In-Reply-To: <patchbomb.1321996402@probook.site>
References: <patchbomb.1321996402@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 22 Nov 2011 22:13:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 3] mem_event: move mem_event_domain out of
	struct domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321996135 -3600
# Node ID d347a8a36d2e7951f98a3d22866dce004484d95f
# Parent  d3859e348951cde6b211c5afb610ac1f12a909ec
mem_event: move mem_event_domain out of struct domain

An upcoming change increases the size of mem_event_domain. The result is a
build failure because struct domain gets larger than a page. Allocate the room
for the three mem_event_domain members at runtime.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4098,7 +4098,7 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_access);
+    rc = mem_event_check_ring(d, &d->mem_event->mem_access);
     if ( rc )
         return rc;
     
@@ -4121,7 +4121,7 @@ static int hvm_memory_event_traps(long p
         req.gla_valid = 1;
     }
     
-    mem_event_put_request(d, &d->mem_access, &req);
+    mem_event_put_request(d, &d->mem_event->mem_access, &req);
     
     return 1;
 }
diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -265,7 +265,7 @@ int mem_event_domctl(struct domain *d, x
     {
     case XEN_DOMCTL_MEM_EVENT_OP_PAGING:
     {
-        struct mem_event_domain *med = &d->mem_paging;
+        struct mem_event_domain *med = &d->mem_event->mem_paging;
         rc = -EINVAL;
 
         switch( mec->op )
@@ -310,7 +310,7 @@ int mem_event_domctl(struct domain *d, x
 
     case XEN_DOMCTL_MEM_EVENT_OP_ACCESS: 
     {
-        struct mem_event_domain *med = &d->mem_access;
+        struct mem_event_domain *med = &d->mem_event->mem_access;
         rc = -EINVAL;
 
         switch( mec->op )
@@ -333,7 +333,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(&d->mem_access);
+                rc = mem_event_disable(med);
         }
         break;
 
diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -281,12 +281,12 @@ static struct page_info* mem_sharing_all
     vcpu_pause_nosync(v);
     req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
 
-    if(mem_event_check_ring(d, &d->mem_share)) return page;
+    if(mem_event_check_ring(d, &d->mem_event->mem_share)) return page;
 
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
-    mem_event_put_request(d, &d->mem_share, &req);
+    mem_event_put_request(d, &d->mem_event->mem_share, &req);
 
     return page;
 }
@@ -301,7 +301,7 @@ int mem_sharing_sharing_resume(struct do
     mem_event_response_t rsp;
 
     /* Get request off the ring */
-    mem_event_get_response(&d->mem_share, &rsp);
+    mem_event_get_response(&d->mem_event->mem_share, &rsp);
 
     /* Unpause domain/vcpu */
     if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -885,7 +885,7 @@ void p2m_mem_paging_drop_page(struct dom
     mem_event_request_t req;
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_paging) == 0)
+    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) == 0)
     {
         /* Send release notification to pager */
         memset(&req, 0, sizeof(req));
@@ -893,7 +893,7 @@ void p2m_mem_paging_drop_page(struct dom
         req.gfn = gfn;
         req.vcpu_id = v->vcpu_id;
 
-        mem_event_put_request(d, &d->mem_paging, &req);
+        mem_event_put_request(d, &d->mem_event->mem_paging, &req);
     }
 }
 
@@ -928,7 +928,7 @@ void p2m_mem_paging_populate(struct doma
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_paging) )
+    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) )
         return;
 
     memset(&req, 0, sizeof(req));
@@ -959,7 +959,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_paging);
+        mem_event_put_req_producers(&d->mem_event->mem_paging);
         return;
     }
 
@@ -968,7 +968,7 @@ void p2m_mem_paging_populate(struct doma
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_paging, &req);
+    mem_event_put_request(d, &d->mem_event->mem_paging, &req);
 }
 
 /**
@@ -1048,7 +1048,7 @@ void p2m_mem_paging_resume(struct domain
     mfn_t mfn;
 
     /* Pull the response off the ring */
-    mem_event_get_response(&d->mem_paging, &rsp);
+    mem_event_get_response(&d->mem_event->mem_paging, &rsp);
 
     /* Fix p2m entry if the page was not dropped */
     if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
@@ -1101,7 +1101,7 @@ void p2m_mem_access_check(unsigned long 
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_access);
+    res = mem_event_check_ring(d, &d->mem_event->mem_access);
     if ( res < 0 ) 
     {
         /* No listener */
@@ -1145,7 +1145,7 @@ void p2m_mem_access_check(unsigned long 
     
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_access, &req);
+    mem_event_put_request(d, &d->mem_event->mem_access, &req);
 
     /* VCPU paused, mem event request sent */
 }
@@ -1155,7 +1155,7 @@ void p2m_mem_access_resume(struct p2m_do
     struct domain *d = p2m->domain;
     mem_event_response_t rsp;
 
-    mem_event_get_response(&d->mem_access, &rsp);
+    mem_event_get_response(&d->mem_event->mem_access, &rsp);
 
     /* Unpause domain */
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
diff -r d3859e348951 -r d347a8a36d2e xen/common/domain.c
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -304,6 +304,10 @@ struct domain *domain_create(
         init_status |= INIT_gnttab;
 
         poolid = 0;
+
+        d->mem_event = xzalloc(struct mem_event_per_domain);
+        if ( !d->mem_event )
+            goto fail;
     }
 
     if ( arch_domain_create(d, domcr_flags) != 0 )
@@ -335,6 +339,7 @@ struct domain *domain_create(
  fail:
     d->is_dying = DOMDYING_dead;
     atomic_set(&d->refcnt, DOMAIN_DESTROYED);
+    xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
     if ( init_status & INIT_gnttab )
diff -r d3859e348951 -r d347a8a36d2e xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -194,6 +194,16 @@ struct mem_event_domain
     int xen_port;
 };
 
+struct mem_event_per_domain
+{
+    /* Memory sharing support */
+    struct mem_event_domain mem_share;
+    /* Memory paging support */
+    struct mem_event_domain mem_paging;
+    /* Memory access support */
+    struct mem_event_domain mem_access;
+};
+
 struct domain
 {
     domid_t          domain_id;
@@ -318,12 +328,8 @@ struct domain
     /* Non-migratable and non-restoreable? */
     bool_t disable_migrate;
 
-    /* Memory sharing support */
-    struct mem_event_domain mem_share;
-    /* Memory paging support */
-    struct mem_event_domain mem_paging;
-    /* Memory access support */
-    struct mem_event_domain mem_access;
+    /* Various mem_events */
+    struct mem_event_per_domain *mem_event;
 
     /* Currently computed from union of all vcpu cpu-affinity masks. */
     nodemask_t node_affinity;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:14:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxfL-0002Kw-4F; Tue, 22 Nov 2011 21:14:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSxfJ-0002Kk-VA
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:14:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321996317!53268124!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10804 invoked from network); 22 Nov 2011 21:11:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 21:11:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321996421; l=3723;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=5UK7dRgDd+yNkCDzVPEIVZWEPsE=;
	b=YdLB8FsV4byXFWHM3T2SFS5azXkmjEcaj9KoJZhkhpbY5bxR++zLij3EZBiTvdGUwp0
	Fe3yi8eah6MIgxxTBzR4itwYKxvKMjKgS2vs1todZlJw3zdFTA83QrffPFuEHHFCKab69
	JlT3N9dvrTxVCkq77wfIECz1YoRcGgSr5as=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by post.strato.de (mrclete mo16) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L01996nAMJh3oO
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:25 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 41BB118639
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9d63ecd3969bb7a2e39841f6c859b4c23f750642
Message-Id: <9d63ecd3969bb7a2e398.1321996405@probook.site>
In-Reply-To: <patchbomb.1321996402@probook.site>
References: <patchbomb.1321996402@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 22 Nov 2011 22:13:25 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in ept_get
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321996199 -3600
# Node ID 9d63ecd3969bb7a2e39841f6c859b4c23f750642
# Parent  de6860cb9205b68d1287482288d1b7b9d0255609
RFC: xenpaging: use waitqueue in ept_get

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r de6860cb9205 -r 9d63ecd3969b xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -505,7 +505,7 @@ out:
 }
 
 /* Read ept p2m entries */
-static mfn_t ept_get_entry(struct p2m_domain *p2m,
+static unsigned long _ept_get_entry(struct p2m_domain *p2m,
                            unsigned long gfn, p2m_type_t *t, p2m_access_t* a,
                            p2m_query_t q, unsigned int *page_order)
 {
@@ -516,7 +516,7 @@ static mfn_t ept_get_entry(struct p2m_do
     u32 index;
     int i;
     int ret = 0;
-    mfn_t mfn = _mfn(INVALID_MFN);
+    unsigned long mfn = INVALID_MFN;
 
     *t = p2m_mmio_dm;
     *a = p2m_access_n;
@@ -582,17 +582,14 @@ static mfn_t ept_get_entry(struct p2m_do
         *t = ept_entry->sa_p2mt;
         *a = ept_entry->access;
 
-        mfn = _mfn(ept_entry->mfn);
+        mfn = ept_entry->mfn;
         if ( i )
         {
             /* 
              * We may meet super pages, and to split into 4k pages
              * to emulate p2m table
              */
-            unsigned long split_mfn = mfn_x(mfn) +
-                (gfn_remainder &
-                 ((1 << (i * EPT_TABLE_ORDER)) - 1));
-            mfn = _mfn(split_mfn);
+            mfn += (gfn_remainder & ((1 << (i * EPT_TABLE_ORDER)) - 1));
         }
 
         if ( page_order )
@@ -604,6 +601,41 @@ out:
     return mfn;
 }
 
+static int
+ept_get_entry_wait(unsigned long *mfn, int *populated,
+               struct p2m_domain *p2m, unsigned long gfn, 
+               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+               unsigned int *page_order)
+{
+    int ret = 1;
+    *mfn = _ept_get_entry(p2m, gfn, t, a, q, page_order);
+
+    /* No further action in case of query */
+    if ( q == p2m_query )
+        goto done;
+
+    /* Populate the page once in case of guest access, then go to sleep */
+    if ( p2m_is_paging(*t) && current->domain == p2m->domain ) {
+        if ( *populated == 0 ) {
+            *populated = 1;
+            p2m_mem_paging_populate(p2m->domain, gfn);
+        }
+        ret = 0;
+    }
+done:
+    return ret;
+}
+static mfn_t
+ept_get_entry(struct p2m_domain *p2m, unsigned long gfn, 
+               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+               unsigned int *page_order)
+{
+    unsigned long mfn;
+    int populated = 0;
+    wait_event(p2m->wq, ept_get_entry_wait(&mfn, &populated, p2m, gfn, t, a, q, page_order));
+    return _mfn(mfn);
+}
+
 /* WARNING: Only caller doesn't care about PoD pages.  So this function will
  * always return 0 for PoD pages, not populate them.  If that becomes necessary,
  * pass a p2m_query_t type along to distinguish. */
diff -r de6860cb9205 -r 9d63ecd3969b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -76,6 +76,7 @@ static void p2m_initialise(struct domain
     INIT_PAGE_LIST_HEAD(&p2m->pages);
     INIT_PAGE_LIST_HEAD(&p2m->pod.super);
     INIT_PAGE_LIST_HEAD(&p2m->pod.single);
+    init_waitqueue_head(&p2m->wq);
 
     p2m->domain = d;
     p2m->default_access = p2m_access_rwx;
@@ -1072,6 +1073,8 @@ void p2m_mem_paging_resume(struct domain
 
     /* Unpause all vcpus that were paused because the ring was full */
     wake_up(&d->mem_event->mem_paging.wq);
+    /* Unpause all vcpus that were paused because the gfn was paged */
+    wake_up(&p2m->wq);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
diff -r de6860cb9205 -r 9d63ecd3969b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -286,6 +286,7 @@ struct p2m_domain {
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
     } pod;
+    struct waitqueue_head wq;
 };
 
 /* get host p2m table */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:14:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxfL-0002Kw-4F; Tue, 22 Nov 2011 21:14:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSxfJ-0002Kk-VA
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:14:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1321996317!53268124!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10804 invoked from network); 22 Nov 2011 21:11:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-8.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 21:11:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321996421; l=3723;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=5UK7dRgDd+yNkCDzVPEIVZWEPsE=;
	b=YdLB8FsV4byXFWHM3T2SFS5azXkmjEcaj9KoJZhkhpbY5bxR++zLij3EZBiTvdGUwp0
	Fe3yi8eah6MIgxxTBzR4itwYKxvKMjKgS2vs1todZlJw3zdFTA83QrffPFuEHHFCKab69
	JlT3N9dvrTxVCkq77wfIECz1YoRcGgSr5as=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by post.strato.de (mrclete mo16) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L01996nAMJh3oO
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:25 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 41BB118639
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9d63ecd3969bb7a2e39841f6c859b4c23f750642
Message-Id: <9d63ecd3969bb7a2e398.1321996405@probook.site>
In-Reply-To: <patchbomb.1321996402@probook.site>
References: <patchbomb.1321996402@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 22 Nov 2011 22:13:25 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in ept_get
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321996199 -3600
# Node ID 9d63ecd3969bb7a2e39841f6c859b4c23f750642
# Parent  de6860cb9205b68d1287482288d1b7b9d0255609
RFC: xenpaging: use waitqueue in ept_get

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r de6860cb9205 -r 9d63ecd3969b xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -505,7 +505,7 @@ out:
 }
 
 /* Read ept p2m entries */
-static mfn_t ept_get_entry(struct p2m_domain *p2m,
+static unsigned long _ept_get_entry(struct p2m_domain *p2m,
                            unsigned long gfn, p2m_type_t *t, p2m_access_t* a,
                            p2m_query_t q, unsigned int *page_order)
 {
@@ -516,7 +516,7 @@ static mfn_t ept_get_entry(struct p2m_do
     u32 index;
     int i;
     int ret = 0;
-    mfn_t mfn = _mfn(INVALID_MFN);
+    unsigned long mfn = INVALID_MFN;
 
     *t = p2m_mmio_dm;
     *a = p2m_access_n;
@@ -582,17 +582,14 @@ static mfn_t ept_get_entry(struct p2m_do
         *t = ept_entry->sa_p2mt;
         *a = ept_entry->access;
 
-        mfn = _mfn(ept_entry->mfn);
+        mfn = ept_entry->mfn;
         if ( i )
         {
             /* 
              * We may meet super pages, and to split into 4k pages
              * to emulate p2m table
              */
-            unsigned long split_mfn = mfn_x(mfn) +
-                (gfn_remainder &
-                 ((1 << (i * EPT_TABLE_ORDER)) - 1));
-            mfn = _mfn(split_mfn);
+            mfn += (gfn_remainder & ((1 << (i * EPT_TABLE_ORDER)) - 1));
         }
 
         if ( page_order )
@@ -604,6 +601,41 @@ out:
     return mfn;
 }
 
+static int
+ept_get_entry_wait(unsigned long *mfn, int *populated,
+               struct p2m_domain *p2m, unsigned long gfn, 
+               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+               unsigned int *page_order)
+{
+    int ret = 1;
+    *mfn = _ept_get_entry(p2m, gfn, t, a, q, page_order);
+
+    /* No further action in case of query */
+    if ( q == p2m_query )
+        goto done;
+
+    /* Populate the page once in case of guest access, then go to sleep */
+    if ( p2m_is_paging(*t) && current->domain == p2m->domain ) {
+        if ( *populated == 0 ) {
+            *populated = 1;
+            p2m_mem_paging_populate(p2m->domain, gfn);
+        }
+        ret = 0;
+    }
+done:
+    return ret;
+}
+static mfn_t
+ept_get_entry(struct p2m_domain *p2m, unsigned long gfn, 
+               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
+               unsigned int *page_order)
+{
+    unsigned long mfn;
+    int populated = 0;
+    wait_event(p2m->wq, ept_get_entry_wait(&mfn, &populated, p2m, gfn, t, a, q, page_order));
+    return _mfn(mfn);
+}
+
 /* WARNING: Only caller doesn't care about PoD pages.  So this function will
  * always return 0 for PoD pages, not populate them.  If that becomes necessary,
  * pass a p2m_query_t type along to distinguish. */
diff -r de6860cb9205 -r 9d63ecd3969b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -76,6 +76,7 @@ static void p2m_initialise(struct domain
     INIT_PAGE_LIST_HEAD(&p2m->pages);
     INIT_PAGE_LIST_HEAD(&p2m->pod.super);
     INIT_PAGE_LIST_HEAD(&p2m->pod.single);
+    init_waitqueue_head(&p2m->wq);
 
     p2m->domain = d;
     p2m->default_access = p2m_access_rwx;
@@ -1072,6 +1073,8 @@ void p2m_mem_paging_resume(struct domain
 
     /* Unpause all vcpus that were paused because the ring was full */
     wake_up(&d->mem_event->mem_paging.wq);
+    /* Unpause all vcpus that were paused because the gfn was paged */
+    wake_up(&p2m->wq);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
diff -r de6860cb9205 -r 9d63ecd3969b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -286,6 +286,7 @@ struct p2m_domain {
         unsigned         reclaim_single; /* Last gpfn of a scan */
         unsigned         max_guest;    /* gpfn of max guest demand-populate */
     } pod;
+    struct waitqueue_head wq;
 };
 
 /* get host p2m table */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:14:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxfS-0002M1-Qm; Tue, 22 Nov 2011 21:14:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSxfQ-0002Kr-6y
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:14:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321996422!5314300!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30101 invoked from network); 22 Nov 2011 21:13:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 21:13:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321996422; l=14299;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=AEjeY7igNmnNjZJ0vM73SsUUgc0=;
	b=xyX9gw9xYjYuOYg7Ar0nViUBbx1vL0cYX4pFC6g7lHqIviJlGA994s6kKN2t9ufGGsK
	QaxccTp/kbJsr7+S8OdJlQP059h2U0cnobc4Ub6zDEYA7zq5I9ZfWTLLJDfA9cyu593DM
	6l2T4grIE0MDgMeYkpbHR4mxevCNvDIMw5k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by post.strato.de (mrclete mo15) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id U018bbnAMK4HAe
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:24 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0A3DA18638
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: de6860cb9205b68d1287482288d1b7b9d0255609
Message-Id: <de6860cb9205b68d1287.1321996404@probook.site>
In-Reply-To: <patchbomb.1321996402@probook.site>
References: <patchbomb.1321996402@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 22 Nov 2011 22:13:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when ring
	is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321996145 -3600
# Node ID de6860cb9205b68d1287482288d1b7b9d0255609
# Parent  d347a8a36d2e7951f98a3d22866dce004484d95f
RFC: mem_event: use wait queue when ring is full

CAUTION: while the patch by itself is supposed to be complete,
the added usage of waitqueues will lead to sudden host reboots!


This change is based on an idea/patch from Adin Scannell.

If the ring is full, put the current vcpu to sleep if it belongs to the
target domain. The wakeup happens in the p2m_*_resume functions.
A request from another domain will use the existing ->req_producers
functionality because sleeping is not possible if the vcpu does not
belong to the target domain.

This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
full ring will lead to harmless inconsistency in the pager,

v2:
 - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise the
   vcpu will not wake_up after a wait_event because the pause_count was
   increased twice. Fixes guest hangs.
 - update free space check in _mem_event_put_request()
 - simplify mem_event_put_request()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4099,7 +4099,7 @@ static int hvm_memory_event_traps(long p
         return 1;
     
     rc = mem_event_check_ring(d, &d->mem_event->mem_access);
-    if ( rc )
+    if ( rc < 0 )
         return rc;
     
     memset(&req, 0, sizeof(req));
diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -23,6 +23,7 @@
 
 #include <asm/domain.h>
 #include <xen/event.h>
+#include <xen/wait.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -39,6 +40,7 @@
 
 static int mem_event_enable(struct domain *d,
                             xen_domctl_mem_event_op_t *mec,
+                            int mem_event_bit,
                             struct mem_event_domain *med)
 {
     int rc;
@@ -107,8 +109,12 @@ static int mem_event_enable(struct domai
 
     mem_event_ring_lock_init(med);
 
+    med->mem_event_bit = mem_event_bit;
+
+    init_waitqueue_head(&med->wq);
+
     /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, med);
 
     return 0;
 
@@ -124,6 +130,9 @@ static int mem_event_enable(struct domai
 
 static int mem_event_disable(struct mem_event_domain *med)
 {
+    if (!list_empty(&med->wq.list))
+        return -EBUSY;
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -133,13 +142,21 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static int _mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_requests;
     RING_IDX req_prod;
 
     mem_event_ring_lock(med);
 
+    free_requests = RING_FREE_REQUESTS(&med->front_ring);
+    /* A request was eventually claimed in mem_event_check_ring() */
+    if ((current->domain == d && free_requests <= med->req_producers) || !free_requests) {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
@@ -155,6 +172,20 @@ void mem_event_put_request(struct domain
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return 1;
+}
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+{
+    /* Go to sleep if request came from guest */
+    if (current->domain == d) {
+        wait_event(med->wq, _mem_event_put_request(d, med, req));
+        return;
+    }
+    /* Ring was full anyway, unable to sleep in non-guest context */
+    if (!_mem_event_put_request(d, med, req))
+        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id, req->type, req->flags, (unsigned long)req->gfn);
 }
 
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -178,21 +209,27 @@ void mem_event_get_response(struct mem_e
     mem_event_ring_unlock(med);
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med)
 {
     struct vcpu *v;
 
     for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+        if ( test_and_clear_bit(med->mem_event_bit, &v->pause_flags) )
             vcpu_wake(v);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
+    set_bit(med->mem_event_bit, &v->pause_flags);
     vcpu_sleep_nosync(v);
 }
 
+/**
+ * mem_event_put_req_producers - Release a claimed slot
+ * @med: mem_event ring
+ *
+ * mem_event_put_req_producers() releases a claimed slot in the mem_event ring.
+ */
 void mem_event_put_req_producers(struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
@@ -200,9 +237,26 @@ void mem_event_put_req_producers(struct 
     mem_event_ring_unlock(med);
 }
 
+/**
+ * mem_event_check_ring - Check state of a mem_event ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * Return codes: < 0: the ring is not yet configured
+ *                 0: the ring has some room
+ *               > 0: the ring is full
+ *
+ * mem_event_check_ring() checks the state of the given mem_event ring.
+ * If the current vcpu belongs to the guest domain, the function assumes that
+ * mem_event_put_request() will sleep until the ring has room again.
+ *
+ * If the current vcpu does not belong to the target domain the caller must try
+ * again until there is room. A slot is claimed and the caller can place a
+ * request. If the caller does not need to send a request, the claimed slot has
+ * to be released with mem_event_put_req_producers().
+ */
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
     int free_requests;
     int ring_full = 1;
 
@@ -218,8 +272,8 @@ int mem_event_check_ring(struct domain *
         ring_full = 0;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
+    if ( current->domain == d )
+        ring_full = 0;
 
     mem_event_ring_unlock(med);
 
@@ -287,7 +341,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_me_mem_paging, med);
         }
         break;
 
@@ -326,7 +380,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_me_mem_access, med);
         }
         break;
 
diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -253,19 +253,11 @@ static void mem_sharing_audit(void)
 #endif
 
 
-static struct page_info* mem_sharing_alloc_page(struct domain *d, 
-                                                unsigned long gfn)
+static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
-    struct page_info* page;
     struct vcpu *v = current;
     mem_event_request_t req;
 
-    page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
-
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_SHARED;
-
     if ( v->domain != d )
     {
         /* XXX This path needs some attention.  For now, just fail foreign 
@@ -275,20 +267,20 @@ static struct page_info* mem_sharing_all
         gdprintk(XENLOG_ERR, 
                  "Failed alloc on unshare path for foreign (%d) lookup\n",
                  d->domain_id);
-        return page;
+        return;
     }
 
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    if (mem_event_check_ring(d, &d->mem_event->mem_share) < 0)
+        return;
 
-    if(mem_event_check_ring(d, &d->mem_event->mem_share)) return page;
-
+    memset(&req, 0, sizeof(req));
+    req.type = MEM_EVENT_TYPE_SHARED;
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->mem_share, &req);
-
-    return page;
+    vcpu_pause_nosync(v);
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -653,7 +645,7 @@ gfn_found:
     if(ret == 0) goto private_page_found;
         
     old_page = page;
-    page = mem_sharing_alloc_page(d, gfn);
+    page = alloc_domheap_page(d, 0); 
     if(!page) 
     {
         /* We've failed to obtain memory for private page. Need to re-add the
@@ -661,6 +653,7 @@ gfn_found:
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
+        mem_sharing_notify_helper(d, gfn);
         return -ENOMEM;
     }
 
diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -884,17 +884,13 @@ void p2m_mem_paging_drop_page(struct dom
     struct vcpu *v = current;
     mem_event_request_t req;
 
-    /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) == 0)
-    {
-        /* Send release notification to pager */
-        memset(&req, 0, sizeof(req));
-        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
-        req.gfn = gfn;
-        req.vcpu_id = v->vcpu_id;
+    /* Send release notification to pager */
+    memset(&req, 0, sizeof(req));
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
+    req.gfn = gfn;
+    req.vcpu_id = v->vcpu_id;
 
-        mem_event_put_request(d, &d->mem_event->mem_paging, &req);
-    }
+    mem_event_put_request(d, &d->mem_event->mem_paging, &req);
 }
 
 /**
@@ -952,7 +948,6 @@ void p2m_mem_paging_populate(struct doma
     /* Pause domain if request came from guest and gfn has paging type */
     if (  p2m_is_paging(p2mt) && v->domain == d )
     {
-        vcpu_pause_nosync(v);
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
     }
     /* No need to inform pager if the gfn is not in the page-out path */
@@ -969,6 +964,10 @@ void p2m_mem_paging_populate(struct doma
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_event->mem_paging, &req);
+
+    /* Pause guest after put_request to allow wake_up after wait_event */
+    if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+        vcpu_pause_nosync(v);
 }
 
 /**
@@ -1071,8 +1070,8 @@ void p2m_mem_paging_resume(struct domain
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    /* Unpause all vcpus that were paused because the ring was full */
+    wake_up(&d->mem_event->mem_paging.wq);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1111,7 +1110,7 @@ void p2m_mem_access_check(unsigned long 
                    "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
                    v->vcpu_id, d->domain_id);
 
-            mem_event_mark_and_pause(v);
+            mem_event_mark_and_pause(v, &d->mem_event->mem_access);
         }
         else
         {
@@ -1131,8 +1130,7 @@ void p2m_mem_access_check(unsigned long 
     req.reason = MEM_EVENT_REASON_VIOLATION;
 
     /* Pause the current VCPU unconditionally */
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;    
 
     /* Send request to mem event */
     req.gfn = gfn;
@@ -1148,6 +1146,7 @@ void p2m_mem_access_check(unsigned long 
     mem_event_put_request(d, &d->mem_event->mem_access, &req);
 
     /* VCPU paused, mem event request sent */
+    vcpu_pause_nosync(v);
 }
 
 void p2m_mem_access_resume(struct p2m_domain *p2m)
@@ -1161,9 +1160,11 @@ void p2m_mem_access_resume(struct p2m_do
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full or no listener 
-     * was available */
-    mem_event_unpause_vcpus(d);
+    /* Wakeup all vcpus waiting because the ring was full */
+    wake_up(&d->mem_event->mem_access.wq);
+
+    /* Unpause all vcpus that were paused because no listener was available */
+    mem_event_unpause_vcpus(d, &d->mem_event->mem_access);
 }
 
 
diff -r d347a8a36d2e -r de6860cb9205 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -25,12 +25,12 @@
 #define __MEM_EVENT_H__
 
 /* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med);
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_req_producers(struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r d347a8a36d2e -r de6860cb9205 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,7 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
@@ -192,6 +193,10 @@ struct mem_event_domain
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
+    /* mem_event bit for vcpu->pause_flags */
+    int mem_event_bit;
+    /* list of vcpus waiting for room in the ring */
+    struct waitqueue_head wq;
 };
 
 struct mem_event_per_domain
@@ -615,9 +620,12 @@ static inline struct domain *next_domain
  /* VCPU affinity has changed: migrating to a new CPU. */
 #define _VPF_migrating       3
 #define VPF_migrating        (1UL<<_VPF_migrating)
- /* VCPU is blocked on memory-event ring. */
-#define _VPF_mem_event       4
-#define VPF_mem_event        (1UL<<_VPF_mem_event)
+ /* VCPU is blocked on mem_paging ring. */
+#define _VPF_me_mem_paging   4
+#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
+ /* VCPU is blocked on mem_access ring. */
+#define _VPF_me_mem_access   5
+#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)
 
 static inline int vcpu_runnable(struct vcpu *v)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:14:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxfS-0002M1-Qm; Tue, 22 Nov 2011 21:14:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSxfQ-0002Kr-6y
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:14:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1321996422!5314300!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30101 invoked from network); 22 Nov 2011 21:13:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 22 Nov 2011 21:13:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321996422; l=14299;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=AEjeY7igNmnNjZJ0vM73SsUUgc0=;
	b=xyX9gw9xYjYuOYg7Ar0nViUBbx1vL0cYX4pFC6g7lHqIviJlGA994s6kKN2t9ufGGsK
	QaxccTp/kbJsr7+S8OdJlQP059h2U0cnobc4Ub6zDEYA7zq5I9ZfWTLLJDfA9cyu593DM
	6l2T4grIE0MDgMeYkpbHR4mxevCNvDIMw5k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by post.strato.de (mrclete mo15) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id U018bbnAMK4HAe
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:24 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0A3DA18638
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 22:13:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: de6860cb9205b68d1287482288d1b7b9d0255609
Message-Id: <de6860cb9205b68d1287.1321996404@probook.site>
In-Reply-To: <patchbomb.1321996402@probook.site>
References: <patchbomb.1321996402@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 22 Nov 2011 22:13:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when ring
	is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1321996145 -3600
# Node ID de6860cb9205b68d1287482288d1b7b9d0255609
# Parent  d347a8a36d2e7951f98a3d22866dce004484d95f
RFC: mem_event: use wait queue when ring is full

CAUTION: while the patch by itself is supposed to be complete,
the added usage of waitqueues will lead to sudden host reboots!


This change is based on an idea/patch from Adin Scannell.

If the ring is full, put the current vcpu to sleep if it belongs to the
target domain. The wakeup happens in the p2m_*_resume functions.
A request from another domain will use the existing ->req_producers
functionality because sleeping is not possible if the vcpu does not
belong to the target domain.

This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
full ring will lead to harmless inconsistency in the pager,

v2:
 - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise the
   vcpu will not wake_up after a wait_event because the pause_count was
   increased twice. Fixes guest hangs.
 - update free space check in _mem_event_put_request()
 - simplify mem_event_put_request()

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4099,7 +4099,7 @@ static int hvm_memory_event_traps(long p
         return 1;
     
     rc = mem_event_check_ring(d, &d->mem_event->mem_access);
-    if ( rc )
+    if ( rc < 0 )
         return rc;
     
     memset(&req, 0, sizeof(req));
diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -23,6 +23,7 @@
 
 #include <asm/domain.h>
 #include <xen/event.h>
+#include <xen/wait.h>
 #include <asm/p2m.h>
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
@@ -39,6 +40,7 @@
 
 static int mem_event_enable(struct domain *d,
                             xen_domctl_mem_event_op_t *mec,
+                            int mem_event_bit,
                             struct mem_event_domain *med)
 {
     int rc;
@@ -107,8 +109,12 @@ static int mem_event_enable(struct domai
 
     mem_event_ring_lock_init(med);
 
+    med->mem_event_bit = mem_event_bit;
+
+    init_waitqueue_head(&med->wq);
+
     /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, med);
 
     return 0;
 
@@ -124,6 +130,9 @@ static int mem_event_enable(struct domai
 
 static int mem_event_disable(struct mem_event_domain *med)
 {
+    if (!list_empty(&med->wq.list))
+        return -EBUSY;
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -133,13 +142,21 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static int _mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_requests;
     RING_IDX req_prod;
 
     mem_event_ring_lock(med);
 
+    free_requests = RING_FREE_REQUESTS(&med->front_ring);
+    /* A request was eventually claimed in mem_event_check_ring() */
+    if ((current->domain == d && free_requests <= med->req_producers) || !free_requests) {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     front_ring = &med->front_ring;
     req_prod = front_ring->req_prod_pvt;
 
@@ -155,6 +172,20 @@ void mem_event_put_request(struct domain
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return 1;
+}
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+{
+    /* Go to sleep if request came from guest */
+    if (current->domain == d) {
+        wait_event(med->wq, _mem_event_put_request(d, med, req));
+        return;
+    }
+    /* Ring was full anyway, unable to sleep in non-guest context */
+    if (!_mem_event_put_request(d, med, req))
+        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n", d->domain_id, req->type, req->flags, (unsigned long)req->gfn);
 }
 
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
@@ -178,21 +209,27 @@ void mem_event_get_response(struct mem_e
     mem_event_ring_unlock(med);
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med)
 {
     struct vcpu *v;
 
     for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+        if ( test_and_clear_bit(med->mem_event_bit, &v->pause_flags) )
             vcpu_wake(v);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
+    set_bit(med->mem_event_bit, &v->pause_flags);
     vcpu_sleep_nosync(v);
 }
 
+/**
+ * mem_event_put_req_producers - Release a claimed slot
+ * @med: mem_event ring
+ *
+ * mem_event_put_req_producers() releases a claimed slot in the mem_event ring.
+ */
 void mem_event_put_req_producers(struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
@@ -200,9 +237,26 @@ void mem_event_put_req_producers(struct 
     mem_event_ring_unlock(med);
 }
 
+/**
+ * mem_event_check_ring - Check state of a mem_event ring
+ * @d: guest domain
+ * @med: mem_event ring
+ *
+ * Return codes: < 0: the ring is not yet configured
+ *                 0: the ring has some room
+ *               > 0: the ring is full
+ *
+ * mem_event_check_ring() checks the state of the given mem_event ring.
+ * If the current vcpu belongs to the guest domain, the function assumes that
+ * mem_event_put_request() will sleep until the ring has room again.
+ *
+ * If the current vcpu does not belong to the target domain the caller must try
+ * again until there is room. A slot is claimed and the caller can place a
+ * request. If the caller does not need to send a request, the claimed slot has
+ * to be released with mem_event_put_req_producers().
+ */
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
     int free_requests;
     int ring_full = 1;
 
@@ -218,8 +272,8 @@ int mem_event_check_ring(struct domain *
         ring_full = 0;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
+    if ( current->domain == d )
+        ring_full = 0;
 
     mem_event_ring_unlock(med);
 
@@ -287,7 +341,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_me_mem_paging, med);
         }
         break;
 
@@ -326,7 +380,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, _VPF_me_mem_access, med);
         }
         break;
 
diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -253,19 +253,11 @@ static void mem_sharing_audit(void)
 #endif
 
 
-static struct page_info* mem_sharing_alloc_page(struct domain *d, 
-                                                unsigned long gfn)
+static void mem_sharing_notify_helper(struct domain *d, unsigned long gfn)
 {
-    struct page_info* page;
     struct vcpu *v = current;
     mem_event_request_t req;
 
-    page = alloc_domheap_page(d, 0); 
-    if(page != NULL) return page;
-
-    memset(&req, 0, sizeof(req));
-    req.type = MEM_EVENT_TYPE_SHARED;
-
     if ( v->domain != d )
     {
         /* XXX This path needs some attention.  For now, just fail foreign 
@@ -275,20 +267,20 @@ static struct page_info* mem_sharing_all
         gdprintk(XENLOG_ERR, 
                  "Failed alloc on unshare path for foreign (%d) lookup\n",
                  d->domain_id);
-        return page;
+        return;
     }
 
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    if (mem_event_check_ring(d, &d->mem_event->mem_share) < 0)
+        return;
 
-    if(mem_event_check_ring(d, &d->mem_event->mem_share)) return page;
-
+    memset(&req, 0, sizeof(req));
+    req.type = MEM_EVENT_TYPE_SHARED;
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
     mem_event_put_request(d, &d->mem_event->mem_share, &req);
-
-    return page;
+    vcpu_pause_nosync(v);
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -653,7 +645,7 @@ gfn_found:
     if(ret == 0) goto private_page_found;
         
     old_page = page;
-    page = mem_sharing_alloc_page(d, gfn);
+    page = alloc_domheap_page(d, 0); 
     if(!page) 
     {
         /* We've failed to obtain memory for private page. Need to re-add the
@@ -661,6 +653,7 @@ gfn_found:
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
         shr_unlock();
+        mem_sharing_notify_helper(d, gfn);
         return -ENOMEM;
     }
 
diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -884,17 +884,13 @@ void p2m_mem_paging_drop_page(struct dom
     struct vcpu *v = current;
     mem_event_request_t req;
 
-    /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) == 0)
-    {
-        /* Send release notification to pager */
-        memset(&req, 0, sizeof(req));
-        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
-        req.gfn = gfn;
-        req.vcpu_id = v->vcpu_id;
+    /* Send release notification to pager */
+    memset(&req, 0, sizeof(req));
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
+    req.gfn = gfn;
+    req.vcpu_id = v->vcpu_id;
 
-        mem_event_put_request(d, &d->mem_event->mem_paging, &req);
-    }
+    mem_event_put_request(d, &d->mem_event->mem_paging, &req);
 }
 
 /**
@@ -952,7 +948,6 @@ void p2m_mem_paging_populate(struct doma
     /* Pause domain if request came from guest and gfn has paging type */
     if (  p2m_is_paging(p2mt) && v->domain == d )
     {
-        vcpu_pause_nosync(v);
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
     }
     /* No need to inform pager if the gfn is not in the page-out path */
@@ -969,6 +964,10 @@ void p2m_mem_paging_populate(struct doma
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_event->mem_paging, &req);
+
+    /* Pause guest after put_request to allow wake_up after wait_event */
+    if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+        vcpu_pause_nosync(v);
 }
 
 /**
@@ -1071,8 +1070,8 @@ void p2m_mem_paging_resume(struct domain
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    /* Unpause all vcpus that were paused because the ring was full */
+    wake_up(&d->mem_event->mem_paging.wq);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1111,7 +1110,7 @@ void p2m_mem_access_check(unsigned long 
                    "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
                    v->vcpu_id, d->domain_id);
 
-            mem_event_mark_and_pause(v);
+            mem_event_mark_and_pause(v, &d->mem_event->mem_access);
         }
         else
         {
@@ -1131,8 +1130,7 @@ void p2m_mem_access_check(unsigned long 
     req.reason = MEM_EVENT_REASON_VIOLATION;
 
     /* Pause the current VCPU unconditionally */
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;    
 
     /* Send request to mem event */
     req.gfn = gfn;
@@ -1148,6 +1146,7 @@ void p2m_mem_access_check(unsigned long 
     mem_event_put_request(d, &d->mem_event->mem_access, &req);
 
     /* VCPU paused, mem event request sent */
+    vcpu_pause_nosync(v);
 }
 
 void p2m_mem_access_resume(struct p2m_domain *p2m)
@@ -1161,9 +1160,11 @@ void p2m_mem_access_resume(struct p2m_do
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
         vcpu_unpause(d->vcpu[rsp.vcpu_id]);
 
-    /* Unpause any domains that were paused because the ring was full or no listener 
-     * was available */
-    mem_event_unpause_vcpus(d);
+    /* Wakeup all vcpus waiting because the ring was full */
+    wake_up(&d->mem_event->mem_access.wq);
+
+    /* Unpause all vcpus that were paused because no listener was available */
+    mem_event_unpause_vcpus(d, &d->mem_event->mem_access);
 }
 
 
diff -r d347a8a36d2e -r de6860cb9205 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -25,12 +25,12 @@
 #define __MEM_EVENT_H__
 
 /* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med);
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
 void mem_event_put_req_producers(struct mem_event_domain *med);
 void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
 void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r d347a8a36d2e -r de6860cb9205 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -14,6 +14,7 @@
 #include <xen/nodemask.h>
 #include <xen/radix-tree.h>
 #include <xen/multicall.h>
+#include <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.h>
 #include <public/sysctl.h>
@@ -192,6 +193,10 @@ struct mem_event_domain
     mem_event_front_ring_t front_ring;
     /* event channel port (vcpu0 only) */
     int xen_port;
+    /* mem_event bit for vcpu->pause_flags */
+    int mem_event_bit;
+    /* list of vcpus waiting for room in the ring */
+    struct waitqueue_head wq;
 };
 
 struct mem_event_per_domain
@@ -615,9 +620,12 @@ static inline struct domain *next_domain
  /* VCPU affinity has changed: migrating to a new CPU. */
 #define _VPF_migrating       3
 #define VPF_migrating        (1UL<<_VPF_migrating)
- /* VCPU is blocked on memory-event ring. */
-#define _VPF_mem_event       4
-#define VPF_mem_event        (1UL<<_VPF_mem_event)
+ /* VCPU is blocked on mem_paging ring. */
+#define _VPF_me_mem_paging   4
+#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
+ /* VCPU is blocked on mem_access ring. */
+#define _VPF_me_mem_access   5
+#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)
 
 static inline int vcpu_runnable(struct vcpu *v)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:16:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxgz-0002aB-Dz; Tue, 22 Nov 2011 21:15:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSxgx-0002Zr-Lq
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:15:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321996480!57861330!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21312 invoked from network); 22 Nov 2011 21:14:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 21:14:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321996523; l=378;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=hM7qBKhcqceG3nIUBjLjVt1dZMg=;
	b=ZhdEQbb0dd7idzVBeW5qUYtseul+iNFXDh5Wrh49jKjsLeYXEvCJTQAWAIWg58qlLmu
	+VfIncIZq0AJKsjiv9CYQ8TgOU+08wXBQwKUPBkMoy05cYAjHnilPZfuoMe+c0aLEEq2D
	aBXv8VCO/iePyIu2+KU7n0A3OA+s8HrKiwA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (jimi mo13) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y03710nAMJ01eK ;
	Tue, 22 Nov 2011 22:15:20 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 877AF18637; Tue, 22 Nov 2011 22:15:19 +0100 (CET)
Date: Tue, 22 Nov 2011 22:15:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111122211519.GA1039@aepfle.de>
References: <20111122173618.GA1304@aepfle.de>
	<CAF18F7C.255E4%keir.xen@gmail.com>
	<20111122180401.GA2555@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111122180401.GA2555@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Olaf Hering wrote:

> On Tue, Nov 22, Keir Fraser wrote:
> 
> > Could it have ended up on the waitqueue?
> 
> Unlikely, but I will add checks for that as well.

I posted three changes which make use of the wait queues.
For some reason the code at the very end of p2m_mem_paging_populate()
triggers when d is dom0, so its vcpu is put to sleep.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:16:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSxgz-0002aB-Dz; Tue, 22 Nov 2011 21:15:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RSxgx-0002Zr-Lq
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:15:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1321996480!57861330!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21312 invoked from network); 22 Nov 2011 21:14:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 21:14:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1321996523; l=378;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=hM7qBKhcqceG3nIUBjLjVt1dZMg=;
	b=ZhdEQbb0dd7idzVBeW5qUYtseul+iNFXDh5Wrh49jKjsLeYXEvCJTQAWAIWg58qlLmu
	+VfIncIZq0AJKsjiv9CYQ8TgOU+08wXBQwKUPBkMoy05cYAjHnilPZfuoMe+c0aLEEq2D
	aBXv8VCO/iePyIu2+KU7n0A3OA+s8HrKiwA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFIhi0PEdZL
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-068-121.pools.arcor-ip.net [88.65.68.121])
	by smtp.strato.de (jimi mo13) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y03710nAMJ01eK ;
	Tue, 22 Nov 2011 22:15:20 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 877AF18637; Tue, 22 Nov 2011 22:15:19 +0100 (CET)
Date: Tue, 22 Nov 2011 22:15:19 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111122211519.GA1039@aepfle.de>
References: <20111122173618.GA1304@aepfle.de>
	<CAF18F7C.255E4%keir.xen@gmail.com>
	<20111122180401.GA2555@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111122180401.GA2555@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Olaf Hering wrote:

> On Tue, Nov 22, Keir Fraser wrote:
> 
> > Could it have ended up on the waitqueue?
> 
> Unlikely, but I will add checks for that as well.

I posted three changes which make use of the wait queues.
For some reason the code at the very end of p2m_mem_paging_populate()
triggers when d is dom0, so its vcpu is put to sleep.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:54:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:54:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSyI8-0003QP-Dq; Tue, 22 Nov 2011 21:54:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSyI6-0003QG-To
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:54:11 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1321998821!5922357!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31734 invoked from network); 22 Nov 2011 21:53:41 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 21:53:41 -0000
Received: by fanq24 with SMTP id q24so194864fan.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 13:53:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=PQvMmB+AcD3Nbrs7YCJPVk3SM5rRGqIMesq1qTfHIZk=;
	b=EUsDRp4Ina28x0CLH4GCSH8wLr/I5m2Rv2nWHtZMeqXPD6QngxHYdiOmHw60Wepp8y
	lDoCJnEwEXNTBNyhDSr/hDsvcuSA81RjO631J1meJaCab+ag7YwT/t7wjzSyMuaMyC8V
	7vKHDtBewLAZu2IgcCBRrNoXHwIU24f0d6sjM=
Received: by 10.180.103.170 with SMTP id fx10mr20647433wib.56.1321998821553;
	Tue, 22 Nov 2011 13:53:41 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id fq9sm13543930wbb.5.2011.11.22.13.53.38
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 13:53:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 21:53:35 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF1CA5F.2560C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypYS7cDW30+diST0uKBavmWG9UHA==
In-Reply-To: <20111122211519.GA1039@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 21:15, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Olaf Hering wrote:
> 
>> On Tue, Nov 22, Keir Fraser wrote:
>> 
>>> Could it have ended up on the waitqueue?
>> 
>> Unlikely, but I will add checks for that as well.
> 
> I posted three changes which make use of the wait queues.
> For some reason the code at the very end of p2m_mem_paging_populate()
> triggers when d is dom0, so its vcpu is put to sleep.

We obviously can't have dom0 going to sleep on paging work. This, at least,
isn't a wait-queue bug.

> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 21:54:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 21:54:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSyI8-0003QP-Dq; Tue, 22 Nov 2011 21:54:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RSyI6-0003QG-To
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 21:54:11 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1321998821!5922357!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31734 invoked from network); 22 Nov 2011 21:53:41 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 21:53:41 -0000
Received: by fanq24 with SMTP id q24so194864fan.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 13:53:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=PQvMmB+AcD3Nbrs7YCJPVk3SM5rRGqIMesq1qTfHIZk=;
	b=EUsDRp4Ina28x0CLH4GCSH8wLr/I5m2Rv2nWHtZMeqXPD6QngxHYdiOmHw60Wepp8y
	lDoCJnEwEXNTBNyhDSr/hDsvcuSA81RjO631J1meJaCab+ag7YwT/t7wjzSyMuaMyC8V
	7vKHDtBewLAZu2IgcCBRrNoXHwIU24f0d6sjM=
Received: by 10.180.103.170 with SMTP id fx10mr20647433wib.56.1321998821553;
	Tue, 22 Nov 2011 13:53:41 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id fq9sm13543930wbb.5.2011.11.22.13.53.38
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 13:53:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 21:53:35 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF1CA5F.2560C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcypYS7cDW30+diST0uKBavmWG9UHA==
In-Reply-To: <20111122211519.GA1039@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 22/11/2011 21:15, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Olaf Hering wrote:
> 
>> On Tue, Nov 22, Keir Fraser wrote:
>> 
>>> Could it have ended up on the waitqueue?
>> 
>> Unlikely, but I will add checks for that as well.
> 
> I posted three changes which make use of the wait queues.
> For some reason the code at the very end of p2m_mem_paging_populate()
> triggers when d is dom0, so its vcpu is put to sleep.

We obviously can't have dom0 going to sleep on paging work. This, at least,
isn't a wait-queue bug.

> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 22:20:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 22:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSygu-0003rE-T9; Tue, 22 Nov 2011 22:19:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSygs-0003r9-QA
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 22:19:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322000317!64255064!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8175 invoked from network); 22 Nov 2011 22:18:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 22:18:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,555,1315180800"; 
   d="scan'208";a="9074611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 22:19:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 22:19:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSygO-0007gH-Ur;
	Tue, 22 Nov 2011 22:19:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSygO-0001mw-Tb;
	Tue, 22 Nov 2011 22:19:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9962-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 22:19:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9962: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9962 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9962/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  4ecd3615e726
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24184:4ecd3615e726
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 22:20:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 22:20:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RSygu-0003rE-T9; Tue, 22 Nov 2011 22:19:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RSygs-0003r9-QA
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 22:19:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322000317!64255064!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8175 invoked from network); 22 Nov 2011 22:18:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 22:18:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,555,1315180800"; 
   d="scan'208";a="9074611"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 22:19:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 22:19:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RSygO-0007gH-Ur;
	Tue, 22 Nov 2011 22:19:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RSygO-0001mw-Tb;
	Tue, 22 Nov 2011 22:19:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9962-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 22:19:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9962: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9962 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9962/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  4ecd3615e726
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24184:4ecd3615e726
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 23:57:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 23:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT0D5-0005Ff-Jo; Tue, 22 Nov 2011 23:57:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT0D3-0005FP-VT
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 23:57:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322006196!4225837!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20047 invoked from network); 22 Nov 2011 23:56:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 23:56:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,556,1315180800"; 
   d="scan'208";a="9075085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 23:56:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 23:56:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT0CO-0008IN-7k;
	Tue, 22 Nov 2011 23:56:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT0CO-0000JM-6z;
	Tue, 22 Nov 2011 23:56:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9960-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 23:56:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9960: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9960 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9960/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10     fail REGR. vs. 9957
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9957

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-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                  c613d436ca09
baseline version:
 xen                  4f4763690d74

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23195:c613d436ca09
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 19:03:04 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   23194:4f4763690d74
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:37:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24177:d3859e348951
    xen-unstable date:        Tue Nov 22 13:29:48 2011 +0000
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 22 23:57:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 22 Nov 2011 23:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT0D5-0005Ff-Jo; Tue, 22 Nov 2011 23:57:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT0D3-0005FP-VT
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 23:57:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322006196!4225837!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20047 invoked from network); 22 Nov 2011 23:56:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 23:56:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,556,1315180800"; 
   d="scan'208";a="9075085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 23:56:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 22 Nov 2011 23:56:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT0CO-0008IN-7k;
	Tue, 22 Nov 2011 23:56:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT0CO-0000JM-6z;
	Tue, 22 Nov 2011 23:56:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9960-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 22 Nov 2011 23:56:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9960: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9960 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9960/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10     fail REGR. vs. 9957
 test-i386-i386-win            7 windows-install            fail REGR. vs. 9957

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-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                  c613d436ca09
baseline version:
 xen                  4f4763690d74

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23195:c613d436ca09
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 19:03:04 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   23194:4f4763690d74
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:37:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24177:d3859e348951
    xen-unstable date:        Tue Nov 22 13:29:48 2011 +0000
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 00:25:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 00:25:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT0dx-00068W-7M; Wed, 23 Nov 2011 00:24:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT0dv-00068R-PY
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 00:24:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322007862!2576838!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23996 invoked from network); 23 Nov 2011 00:24:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 00:24:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,556,1315180800"; 
   d="scan'208";a="9075254"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 00:24:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 00:24:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT0dQ-0008TX-TH;
	Wed, 23 Nov 2011 00:24:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT0dQ-0000Pb-Oy;
	Wed, 23 Nov 2011 00:24:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RT0dQ-0000Pb-Oy@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 00:24:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-amd64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job build-amd64
test xen-build

Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08


  changeset:   24184:4ecd3615e726
  tag:         tip
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 9962 fail [host=moss-bug] / 9958 ok.
Failure / basis pass flights: 9962 / 9958
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
Basis pass 52834188eedfbbca5636fd869d4c86b3b3044439 d3859e348951
Generating revisions with ./adhoc-revtuple-generator  git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#52834188eedfbbca5636fd869d4c86b3b3044439-9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 http://xenbits.xen.org/staging/xen-unstable.hg#d3859e348951-4ecd3615e726
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1008 nodes in revision graph
Searching for test results:
 9968 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 9969 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9970 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 9971 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9972 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 9974 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9958 pass 52834188eedfbbca5636fd869d4c86b3b3044439 d3859e348951
 9959 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9961 pass irrelevant
 9963 pass 52834188eedfbbca5636fd869d4c86b3b3044439 d3859e348951
 9962 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9964 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9965 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 8edcd2e3f3f1
 9966 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 99a567be1978
 9967 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 2b5c6fff0e5b
Searching for interesting versions
 Result found: flight 9958 (pass), for basis pass
 Result found: flight 9959 (fail), for basis failure
 Repro found: flight 9963 (pass), for basis pass
 Repro found: flight 9964 (fail), for basis failure
 0 revisions at 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
No revisions left to test, checking graph state.
 Result found: flight 9968 (pass), for last pass
 Result found: flight 9969 (fail), for first failure
 Repro found: flight 9970 (pass), for last pass
 Repro found: flight 9971 (fail), for first failure
 Repro found: flight 9972 (pass), for last pass
 Repro found: flight 9974 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24184:4ecd3615e726
  tag:         tip
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64.xen-build.{dot,ps,png,html}.
----------------------------------------
9974: ALL FAIL

flight 9974 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9974/


jobs:
 build-amd64                                                  fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 00:25:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 00:25:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT0dx-00068W-7M; Wed, 23 Nov 2011 00:24:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT0dv-00068R-PY
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 00:24:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322007862!2576838!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23996 invoked from network); 23 Nov 2011 00:24:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 00:24:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,556,1315180800"; 
   d="scan'208";a="9075254"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 00:24:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 00:24:21 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT0dQ-0008TX-TH;
	Wed, 23 Nov 2011 00:24:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT0dQ-0000Pb-Oy;
	Wed, 23 Nov 2011 00:24:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RT0dQ-0000Pb-Oy@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 00:24:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-amd64
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job build-amd64
test xen-build

Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08


  changeset:   24184:4ecd3615e726
  tag:         tip
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 9962 fail [host=moss-bug] / 9958 ok.
Failure / basis pass flights: 9962 / 9958
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
Basis pass 52834188eedfbbca5636fd869d4c86b3b3044439 d3859e348951
Generating revisions with ./adhoc-revtuple-generator  git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#52834188eedfbbca5636fd869d4c86b3b3044439-9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 http://xenbits.xen.org/staging/xen-unstable.hg#d3859e348951-4ecd3615e726
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1008 nodes in revision graph
Searching for test results:
 9968 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 9969 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9970 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 9971 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9972 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 9974 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9958 pass 52834188eedfbbca5636fd869d4c86b3b3044439 d3859e348951
 9959 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9961 pass irrelevant
 9963 pass 52834188eedfbbca5636fd869d4c86b3b3044439 d3859e348951
 9962 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9964 fail 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9965 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 8edcd2e3f3f1
 9966 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 99a567be1978
 9967 pass 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 2b5c6fff0e5b
Searching for interesting versions
 Result found: flight 9958 (pass), for basis pass
 Result found: flight 9959 (fail), for basis failure
 Repro found: flight 9963 (pass), for basis pass
 Repro found: flight 9964 (fail), for basis failure
 0 revisions at 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
No revisions left to test, checking graph state.
 Result found: flight 9968 (pass), for last pass
 Result found: flight 9969 (fail), for first failure
 Repro found: flight 9970 (pass), for last pass
 Repro found: flight 9971 (fail), for first failure
 Repro found: flight 9972 (pass), for last pass
 Repro found: flight 9974 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24184:4ecd3615e726
  tag:         tip
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64.xen-build.{dot,ps,png,html}.
----------------------------------------
9974: ALL FAIL

flight 9974 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9974/


jobs:
 build-amd64                                                  fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 00:34:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 00:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT0mX-0006PX-RQ; Wed, 23 Nov 2011 00:33:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@suse.de>) id 1RT0mW-0006PS-NM
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 00:33:44 +0000
X-Env-Sender: gregkh@suse.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322008371!49536543!1
X-Originating-IP: [195.135.220.15]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26786 invoked from network); 23 Nov 2011 00:32:52 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 00:32:52 -0000
Received: from relay1.suse.de (nat.nue.novell.com [195.135.221.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id EFEFB8AD27;
	Wed, 23 Nov 2011 01:33:19 +0100 (CET)
X-Mailbox-Line: From gregkh@clark.kroah.org Tue Nov 22 16:22:08 2011
Message-Id: <20111123002208.396541245@clark.kroah.org>
User-Agent: quilt/0.48-20.1.2
Date: Tue, 22 Nov 2011 16:21:05 -0800
From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org, Greg KH <greg@kroah.com>
In-Reply-To: <20111123002222.GA2376@kroah.com>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	xen-devel <xen-devel@lists.xensource.com>,
	Thomas Gleixner <tglx@linutronix.de>, akpm@linux-foundation.org,
	torvalds@linux-foundation.org, stable-review@kernel.org,
	alan@lxorguk.ukuu.org.uk
Subject: [Xen-devel] [15/25] genirq: Add IRQF_RESUME_EARLY and resume such
	IRQs earlier
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

------------------
Content-Length: 4751
Lines: 154


From: Ian Campbell <ian.campbell@citrix.com>

commit 9bab0b7fbaceec47d32db51cd9e59c82fb071f5a upstream

This adds a mechanism to resume selected IRQs during syscore_resume
instead of dpm_resume_noirq.

Under Xen we need to resume IRQs associated with IPIs early enough
that the resched IPI is unmasked and we can therefore schedule
ourselves out of the stop_machine where the suspend/resume takes
place.

This issue was introduced by 676dc3cf5bc3 "xen: Use IRQF_FORCE_RESUME".

Back ported to 2.6.32 (which lacks syscore support) by calling the relavant
resume function directly from sysdev_resume).

v2: Fixed non-x86 build errors.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.uk
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/base/sys.c        |    6 ++++++
 drivers/xen/events.c      |    2 +-
 include/linux/interrupt.h |    6 ++++++
 kernel/irq/pm.c           |   35 ++++++++++++++++++++++++++++-------
 4 files changed, 41 insertions(+), 8 deletions(-)

--- a/drivers/base/sys.c
+++ b/drivers/base/sys.c
@@ -471,6 +471,12 @@ int sysdev_resume(void)
 {
 	struct sysdev_class *cls;
 
+	/*
+	 * Called from syscore in mainline but called directly here
+	 * since syscore does not exist in this tree.
+	 */
+	irq_pm_syscore_resume();
+
 	WARN_ONCE(!irqs_disabled(),
 		"Interrupts enabled while resuming system devices\n");
 
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -536,7 +536,7 @@ int bind_ipi_to_irqhandler(enum ipi_vect
 	if (irq < 0)
 		return irq;
 
-	irqflags |= IRQF_NO_SUSPEND | IRQF_FORCE_RESUME;
+	irqflags |= IRQF_NO_SUSPEND | IRQF_FORCE_RESUME | IRQF_EARLY_RESUME;
 	retval = request_irq(irq, handler, irqflags, devname, dev_id);
 	if (retval != 0) {
 		unbind_from_irq(irq);
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -54,6 +54,8 @@
  *                irq line disabled until the threaded handler has been run.
  * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
  * IRQF_FORCE_RESUME - Force enable it on resume even if IRQF_NO_SUSPEND is set
+ * IRQF_EARLY_RESUME - Resume IRQ early during syscore instead of at device
+ *                resume time.
  */
 #define IRQF_DISABLED		0x00000020
 #define IRQF_SAMPLE_RANDOM	0x00000040
@@ -66,6 +68,7 @@
 #define IRQF_ONESHOT		0x00002000
 #define IRQF_NO_SUSPEND		0x00004000
 #define IRQF_FORCE_RESUME	0x00008000
+#define IRQF_EARLY_RESUME	0x00020000
 
 #define IRQF_TIMER		(__IRQF_TIMER | IRQF_NO_SUSPEND)
 
@@ -198,13 +201,16 @@ extern void suspend_device_irqs(void);
 extern void resume_device_irqs(void);
 #ifdef CONFIG_PM_SLEEP
 extern int check_wakeup_irqs(void);
+extern void irq_pm_syscore_resume(void);
 #else
 static inline int check_wakeup_irqs(void) { return 0; }
+static inline void irq_pm_syscore_resume(void) { };
 #endif
 #else
 static inline void suspend_device_irqs(void) { };
 static inline void resume_device_irqs(void) { };
 static inline int check_wakeup_irqs(void) { return 0; }
+static inline void irq_pm_syscore_resume(void) { };
 #endif
 
 #if defined(CONFIG_SMP) && defined(CONFIG_GENERIC_HARDIRQS)
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -39,25 +39,46 @@ void suspend_device_irqs(void)
 }
 EXPORT_SYMBOL_GPL(suspend_device_irqs);
 
-/**
- * resume_device_irqs - enable interrupt lines disabled by suspend_device_irqs()
- *
- * Enable all interrupt lines previously disabled by suspend_device_irqs() that
- * have the IRQ_SUSPENDED flag set.
- */
-void resume_device_irqs(void)
+static void resume_irqs(bool want_early)
 {
 	struct irq_desc *desc;
 	int irq;
 
 	for_each_irq_desc(irq, desc) {
 		unsigned long flags;
+		bool is_early = desc->action &&
+			desc->action->flags & IRQF_EARLY_RESUME;
+
+		if (is_early != want_early)
+			continue;
 
 		spin_lock_irqsave(&desc->lock, flags);
 		__enable_irq(desc, irq, true);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
+
+/**
+ * irq_pm_syscore_ops - enable interrupt lines early
+ *
+ * Enable all interrupt lines with %IRQF_EARLY_RESUME set.
+ */
+void irq_pm_syscore_resume(void)
+{
+	resume_irqs(true);
+}
+
+/**
+ * resume_device_irqs - enable interrupt lines disabled by suspend_device_irqs()
+ *
+ * Enable all non-%IRQF_EARLY_RESUME interrupt lines previously
+ * disabled by suspend_device_irqs() that have the IRQS_SUSPENDED flag
+ * set as well as those with %IRQF_FORCE_RESUME.
+ */
+void resume_device_irqs(void)
+{
+	resume_irqs(false);
+}
 EXPORT_SYMBOL_GPL(resume_device_irqs);
 
 /**



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 00:34:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 00:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT0mX-0006PX-RQ; Wed, 23 Nov 2011 00:33:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@suse.de>) id 1RT0mW-0006PS-NM
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 00:33:44 +0000
X-Env-Sender: gregkh@suse.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322008371!49536543!1
X-Originating-IP: [195.135.220.15]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26786 invoked from network); 23 Nov 2011 00:32:52 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 00:32:52 -0000
Received: from relay1.suse.de (nat.nue.novell.com [195.135.221.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id EFEFB8AD27;
	Wed, 23 Nov 2011 01:33:19 +0100 (CET)
X-Mailbox-Line: From gregkh@clark.kroah.org Tue Nov 22 16:22:08 2011
Message-Id: <20111123002208.396541245@clark.kroah.org>
User-Agent: quilt/0.48-20.1.2
Date: Tue, 22 Nov 2011 16:21:05 -0800
From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org, Greg KH <greg@kroah.com>
In-Reply-To: <20111123002222.GA2376@kroah.com>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	xen-devel <xen-devel@lists.xensource.com>,
	Thomas Gleixner <tglx@linutronix.de>, akpm@linux-foundation.org,
	torvalds@linux-foundation.org, stable-review@kernel.org,
	alan@lxorguk.ukuu.org.uk
Subject: [Xen-devel] [15/25] genirq: Add IRQF_RESUME_EARLY and resume such
	IRQs earlier
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2.6.32-longterm review patch.  If anyone has any objections, please let me know.

------------------
Content-Length: 4751
Lines: 154


From: Ian Campbell <ian.campbell@citrix.com>

commit 9bab0b7fbaceec47d32db51cd9e59c82fb071f5a upstream

This adds a mechanism to resume selected IRQs during syscore_resume
instead of dpm_resume_noirq.

Under Xen we need to resume IRQs associated with IPIs early enough
that the resched IPI is unmasked and we can therefore schedule
ourselves out of the stop_machine where the suspend/resume takes
place.

This issue was introduced by 676dc3cf5bc3 "xen: Use IRQF_FORCE_RESUME".

Back ported to 2.6.32 (which lacks syscore support) by calling the relavant
resume function directly from sysdev_resume).

v2: Fixed non-x86 build errors.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.uk
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
 drivers/base/sys.c        |    6 ++++++
 drivers/xen/events.c      |    2 +-
 include/linux/interrupt.h |    6 ++++++
 kernel/irq/pm.c           |   35 ++++++++++++++++++++++++++++-------
 4 files changed, 41 insertions(+), 8 deletions(-)

--- a/drivers/base/sys.c
+++ b/drivers/base/sys.c
@@ -471,6 +471,12 @@ int sysdev_resume(void)
 {
 	struct sysdev_class *cls;
 
+	/*
+	 * Called from syscore in mainline but called directly here
+	 * since syscore does not exist in this tree.
+	 */
+	irq_pm_syscore_resume();
+
 	WARN_ONCE(!irqs_disabled(),
 		"Interrupts enabled while resuming system devices\n");
 
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -536,7 +536,7 @@ int bind_ipi_to_irqhandler(enum ipi_vect
 	if (irq < 0)
 		return irq;
 
-	irqflags |= IRQF_NO_SUSPEND | IRQF_FORCE_RESUME;
+	irqflags |= IRQF_NO_SUSPEND | IRQF_FORCE_RESUME | IRQF_EARLY_RESUME;
 	retval = request_irq(irq, handler, irqflags, devname, dev_id);
 	if (retval != 0) {
 		unbind_from_irq(irq);
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -54,6 +54,8 @@
  *                irq line disabled until the threaded handler has been run.
  * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
  * IRQF_FORCE_RESUME - Force enable it on resume even if IRQF_NO_SUSPEND is set
+ * IRQF_EARLY_RESUME - Resume IRQ early during syscore instead of at device
+ *                resume time.
  */
 #define IRQF_DISABLED		0x00000020
 #define IRQF_SAMPLE_RANDOM	0x00000040
@@ -66,6 +68,7 @@
 #define IRQF_ONESHOT		0x00002000
 #define IRQF_NO_SUSPEND		0x00004000
 #define IRQF_FORCE_RESUME	0x00008000
+#define IRQF_EARLY_RESUME	0x00020000
 
 #define IRQF_TIMER		(__IRQF_TIMER | IRQF_NO_SUSPEND)
 
@@ -198,13 +201,16 @@ extern void suspend_device_irqs(void);
 extern void resume_device_irqs(void);
 #ifdef CONFIG_PM_SLEEP
 extern int check_wakeup_irqs(void);
+extern void irq_pm_syscore_resume(void);
 #else
 static inline int check_wakeup_irqs(void) { return 0; }
+static inline void irq_pm_syscore_resume(void) { };
 #endif
 #else
 static inline void suspend_device_irqs(void) { };
 static inline void resume_device_irqs(void) { };
 static inline int check_wakeup_irqs(void) { return 0; }
+static inline void irq_pm_syscore_resume(void) { };
 #endif
 
 #if defined(CONFIG_SMP) && defined(CONFIG_GENERIC_HARDIRQS)
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -39,25 +39,46 @@ void suspend_device_irqs(void)
 }
 EXPORT_SYMBOL_GPL(suspend_device_irqs);
 
-/**
- * resume_device_irqs - enable interrupt lines disabled by suspend_device_irqs()
- *
- * Enable all interrupt lines previously disabled by suspend_device_irqs() that
- * have the IRQ_SUSPENDED flag set.
- */
-void resume_device_irqs(void)
+static void resume_irqs(bool want_early)
 {
 	struct irq_desc *desc;
 	int irq;
 
 	for_each_irq_desc(irq, desc) {
 		unsigned long flags;
+		bool is_early = desc->action &&
+			desc->action->flags & IRQF_EARLY_RESUME;
+
+		if (is_early != want_early)
+			continue;
 
 		spin_lock_irqsave(&desc->lock, flags);
 		__enable_irq(desc, irq, true);
 		spin_unlock_irqrestore(&desc->lock, flags);
 	}
 }
+
+/**
+ * irq_pm_syscore_ops - enable interrupt lines early
+ *
+ * Enable all interrupt lines with %IRQF_EARLY_RESUME set.
+ */
+void irq_pm_syscore_resume(void)
+{
+	resume_irqs(true);
+}
+
+/**
+ * resume_device_irqs - enable interrupt lines disabled by suspend_device_irqs()
+ *
+ * Enable all non-%IRQF_EARLY_RESUME interrupt lines previously
+ * disabled by suspend_device_irqs() that have the IRQS_SUSPENDED flag
+ * set as well as those with %IRQF_FORCE_RESUME.
+ */
+void resume_device_irqs(void)
+{
+	resume_irqs(false);
+}
 EXPORT_SYMBOL_GPL(resume_device_irqs);
 
 /**



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 00:47:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 00:47:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT0zL-0006he-Ni; Wed, 23 Nov 2011 00:46:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RT0zK-0006hZ-Q8
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 00:46:59 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322009187!4508894!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4045 invoked from network); 23 Nov 2011 00:46:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 00:46:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAN0kNfI018127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 00:46:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAN0kKKL001997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 23 Nov 2011 00:46:21 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAN0kDBV017647; Tue, 22 Nov 2011 18:46:13 -0600
Received: from [10.154.42.199] (/10.154.42.199)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 16:46:12 -0800
Message-ID: <4ECC424F.6070009@oracle.com>
Date: Wed, 23 Nov 2011 08:46:07 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4ECB77BB.9090401@oracle.com>
	<20111122143220.GB3430@phenom.dumpdata.com>
In-Reply-To: <20111122143220.GB3430@phenom.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020202.4ECC4261.006C,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <paul.durrant@citrix.com>
Subject: Re: [Xen-devel] Forth version patches for upstreaming grant table
	version 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-11-22 22:32, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 22, 2011 at 06:21:47PM +0800, ANNIE LI wrote:
>   
>> Hi
>>
>> The following patches introduce and implement grant table version 2.
>> This is the forth version patches, and based on v3.2.0-rc1+. Changes
>> from the previous patches are following:
>>
>> * Fix an indentation issue of the code.
>>     
>
> I've put your patches in my queue for 3.3. They should show up in my #linux-next
> tonight if there are no outstanding compile/test issues.
>   
Thanks, Konrad.
Tons of thanks to you guys for your reviewing on these patches, the 
patches were improved so much with your helps.

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 00:47:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 00:47:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT0zL-0006he-Ni; Wed, 23 Nov 2011 00:46:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <annie.li@oracle.com>) id 1RT0zK-0006hZ-Q8
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 00:46:59 +0000
X-Env-Sender: annie.li@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322009187!4508894!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4045 invoked from network); 23 Nov 2011 00:46:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 00:46:29 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAN0kNfI018127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 00:46:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAN0kKKL001997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 23 Nov 2011 00:46:21 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAN0kDBV017647; Tue, 22 Nov 2011 18:46:13 -0600
Received: from [10.154.42.199] (/10.154.42.199)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 16:46:12 -0800
Message-ID: <4ECC424F.6070009@oracle.com>
Date: Wed, 23 Nov 2011 08:46:07 +0800
From: annie li <annie.li@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4ECB77BB.9090401@oracle.com>
	<20111122143220.GB3430@phenom.dumpdata.com>
In-Reply-To: <20111122143220.GB3430@phenom.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020202.4ECC4261.006C,ss=1,re=0.000,fgs=0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <paul.durrant@citrix.com>
Subject: Re: [Xen-devel] Forth version patches for upstreaming grant table
	version 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2011-11-22 22:32, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 22, 2011 at 06:21:47PM +0800, ANNIE LI wrote:
>   
>> Hi
>>
>> The following patches introduce and implement grant table version 2.
>> This is the forth version patches, and based on v3.2.0-rc1+. Changes
>> from the previous patches are following:
>>
>> * Fix an indentation issue of the code.
>>     
>
> I've put your patches in my queue for 3.3. They should show up in my #linux-next
> tonight if there are no outstanding compile/test issues.
>   
Thanks, Konrad.
Tons of thanks to you guys for your reviewing on these patches, the 
patches were improved so much with your helps.

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 01:40:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 01:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT1oG-0002YT-Gv; Wed, 23 Nov 2011 01:39:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RT1oF-0002YJ-6Q
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 01:39:35 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322012330!56084599!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12809 invoked from network); 23 Nov 2011 01:38:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 01:38:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAN1cxH1030597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 01:39:00 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAN1cwQs009740
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 23 Nov 2011 01:38:59 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAN1crOs015765; Tue, 22 Nov 2011 19:38:53 -0600
MIME-Version: 1.0
Message-ID: <2b60cfe7-2c97-45ef-bf89-88cd01cff1d3@default>
Date: Tue, 22 Nov 2011 17:38:46 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default
	20171.55835.240381.351382@mariner.uk.xensource.com>
In-Reply-To: <20171.55835.240381.351382@mariner.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0  (410211) [OL
	12.0.6607.1000]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4ECC4EB4.0072,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Tuesday, November 22, 2011 10:22 AM
> To: Dan Magenheimer
> Cc: stefano.stabellini@eu.citrix.com; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness
> 
> Dan Magenheimer writes ("[Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness"):
> > (This should apply cleanly to 4.0, 4.1, and unstable.  It would
> > be nice to apply to the next dot release of 4.0 and 4.1, but
> > please definitely apply at least to unstable.)
> >
> > Fix ugly parse output for xen-tmem-list-parse
> >
> > This program parses the output of xm/xl tmem-list into
> > human-readable format.  A missing NULL terminator sometimes
> > causes garbage to be spewed where the two-letter pool type
> > should be printed.
> >
> > Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> >
> > diff -r 54a5e994a241 tools/misc/xen-tmem-list-parse.c
> > --- a/tools/misc/xen-tmem-list-parse.c	Wed Nov 02 17:09:09 2011 +0000
> > +++ b/tools/misc/xen-tmem-list-parse.c	Wed Nov 09 14:28:40 2011 -0700
> > @@ -64,6 +64,7 @@
> >          return;
> >      for ( i = 0; i < len; i++ )
> >          *buf++ = *s1++;
> > +    *buf = '\0';
> >  }
> 
> This has a buffer overrun AFAICT.
> 
> Ian.

No, it doesn't.  I agree it *could* if parse_string is
used/called differently.  The caller simply needs to
ensure that the declared buffer is at least one larger
than the data to be matched which is true for both
callers.

P.S. Please note that I am still not receiving email
from the xen-devel reflector (and am on vacation this
week so probably won't be looking into it... my best
guess is that the Oracle spam filter isn't happy with
the new source of the xen-devel messages, as some
other Oracle folk are having problems too).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 01:40:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 01:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT1oG-0002YT-Gv; Wed, 23 Nov 2011 01:39:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RT1oF-0002YJ-6Q
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 01:39:35 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322012330!56084599!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12809 invoked from network); 23 Nov 2011 01:38:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 01:38:51 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAN1cxH1030597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 01:39:00 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAN1cwQs009740
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 23 Nov 2011 01:38:59 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAN1crOs015765; Tue, 22 Nov 2011 19:38:53 -0600
MIME-Version: 1.0
Message-ID: <2b60cfe7-2c97-45ef-bf89-88cd01cff1d3@default>
Date: Tue, 22 Nov 2011 17:38:46 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default
	20171.55835.240381.351382@mariner.uk.xensource.com>
In-Reply-To: <20171.55835.240381.351382@mariner.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0  (410211) [OL
	12.0.6607.1000]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4ECC4EB4.0072,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Tuesday, November 22, 2011 10:22 AM
> To: Dan Magenheimer
> Cc: stefano.stabellini@eu.citrix.com; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness
> 
> Dan Magenheimer writes ("[Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness"):
> > (This should apply cleanly to 4.0, 4.1, and unstable.  It would
> > be nice to apply to the next dot release of 4.0 and 4.1, but
> > please definitely apply at least to unstable.)
> >
> > Fix ugly parse output for xen-tmem-list-parse
> >
> > This program parses the output of xm/xl tmem-list into
> > human-readable format.  A missing NULL terminator sometimes
> > causes garbage to be spewed where the two-letter pool type
> > should be printed.
> >
> > Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> >
> > diff -r 54a5e994a241 tools/misc/xen-tmem-list-parse.c
> > --- a/tools/misc/xen-tmem-list-parse.c	Wed Nov 02 17:09:09 2011 +0000
> > +++ b/tools/misc/xen-tmem-list-parse.c	Wed Nov 09 14:28:40 2011 -0700
> > @@ -64,6 +64,7 @@
> >          return;
> >      for ( i = 0; i < len; i++ )
> >          *buf++ = *s1++;
> > +    *buf = '\0';
> >  }
> 
> This has a buffer overrun AFAICT.
> 
> Ian.

No, it doesn't.  I agree it *could* if parse_string is
used/called differently.  The caller simply needs to
ensure that the declared buffer is at least one larger
than the data to be matched which is true for both
callers.

P.S. Please note that I am still not receiving email
from the xen-devel reflector (and am on vacation this
week so probably won't be looking into it... my best
guess is that the Oracle spam filter isn't happy with
the new source of the xen-devel messages, as some
other Oracle folk are having problems too).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 01:48:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 01:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT1w9-0002ko-LR; Wed, 23 Nov 2011 01:47:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RT1w7-0002ke-Qk
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 01:47:44 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322012833!4200980!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16969 invoked from network); 23 Nov 2011 01:47:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 01:47:14 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAN1l7uh026272
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 01:47:08 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAN1l6D5016361
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 23 Nov 2011 01:47:07 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAN1l1S6019639; Tue, 22 Nov 2011 19:47:01 -0600
MIME-Version: 1.0
Message-ID: <8c1f172a-1a4e-4b8e-aaa9-46bf03a8632a@default>
Date: Tue, 22 Nov 2011 17:46:53 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default
	1321983235.20464.32.camel@dagon.hellion.org.uk>
In-Reply-To: <1321983235.20464.32.camel@dagon.hellion.org.uk>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0  (410211) [OL
	12.0.6607.1000]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4ECC509C.011E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, November 22, 2011 10:34 AM
> To: Dan Magenheimer
> Cc: Ian Jackson; Stefano Stabellini; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness
> 
> On Wed, 2011-11-09 at 21:40 +0000, Dan Magenheimer wrote:
> > (This should apply cleanly to 4.0, 4.1, and unstable.  It would
> > be nice to apply to the next dot release of 4.0 and 4.1, but
> > please definitely apply at least to unstable.)
> >
> > Fix ugly parse output for xen-tmem-list-parse
> >
> > This program parses the output of xm/xl tmem-list into
> > human-readable format.
> 
> Why does xm/xl not just have a human readable output option (or more
> likely, default)?

The raw data originates in the hypervisor in an ASCII format
that was designed to be forward/backward compatible because it
was unclear how much it would need to change over time.
The end consumer is a higher-level management tool; xm/xl
simply pass the data through.  xen-tmem-list-parse acts
as "documentation" for the format and is useful for those
experimenting with tmem.  It didn't seem to make
sense to create an additional dependency for parsing
the format in xm/xl.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 01:48:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 01:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT1w9-0002ko-LR; Wed, 23 Nov 2011 01:47:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RT1w7-0002ke-Qk
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 01:47:44 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322012833!4200980!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16969 invoked from network); 23 Nov 2011 01:47:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 01:47:14 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAN1l7uh026272
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 01:47:08 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAN1l6D5016361
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 23 Nov 2011 01:47:07 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAN1l1S6019639; Tue, 22 Nov 2011 19:47:01 -0600
MIME-Version: 1.0
Message-ID: <8c1f172a-1a4e-4b8e-aaa9-46bf03a8632a@default>
Date: Tue, 22 Nov 2011 17:46:53 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <ead5b75a-55db-43ba-9db9-c8302d4d7edc@default
	1321983235.20464.32.camel@dagon.hellion.org.uk>
In-Reply-To: <1321983235.20464.32.camel@dagon.hellion.org.uk>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0  (410211) [OL
	12.0.6607.1000]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4ECC509C.011E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, November 22, 2011 10:34 AM
> To: Dan Magenheimer
> Cc: Ian Jackson; Stefano Stabellini; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness
> 
> On Wed, 2011-11-09 at 21:40 +0000, Dan Magenheimer wrote:
> > (This should apply cleanly to 4.0, 4.1, and unstable.  It would
> > be nice to apply to the next dot release of 4.0 and 4.1, but
> > please definitely apply at least to unstable.)
> >
> > Fix ugly parse output for xen-tmem-list-parse
> >
> > This program parses the output of xm/xl tmem-list into
> > human-readable format.
> 
> Why does xm/xl not just have a human readable output option (or more
> likely, default)?

The raw data originates in the hypervisor in an ASCII format
that was designed to be forward/backward compatible because it
was unclear how much it would need to change over time.
The end consumer is a higher-level management tool; xm/xl
simply pass the data through.  xen-tmem-list-parse acts
as "documentation" for the format and is useful for those
experimenting with tmem.  It didn't seem to make
sense to create an additional dependency for parsing
the format in xm/xl.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:46:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2qX-0003eY-Vl; Wed, 23 Nov 2011 02:46:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT2qW-0003eT-Jt
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 02:46:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322016307!53824679!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15199 invoked from network); 23 Nov 2011 02:45:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 02:45:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,556,1315180800"; 
   d="scan'208";a="9075923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 02:45:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 02:45:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT2q7-0000wW-DR;
	Wed, 23 Nov 2011 02:45:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT2q7-0002is-D6;
	Wed, 23 Nov 2011 02:45:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9978-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 02:45:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9978: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9978 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9978/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  4ecd3615e726
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24184:4ecd3615e726
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:46:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2qX-0003eY-Vl; Wed, 23 Nov 2011 02:46:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT2qW-0003eT-Jt
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 02:46:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322016307!53824679!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15199 invoked from network); 23 Nov 2011 02:45:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 02:45:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,556,1315180800"; 
   d="scan'208";a="9075923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 02:45:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 02:45:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT2q7-0000wW-DR;
	Wed, 23 Nov 2011 02:45:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT2q7-0002is-D6;
	Wed, 23 Nov 2011 02:45:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9978-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 02:45:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 9978: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9978 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9978/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  4ecd3615e726
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24184:4ecd3615e726
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:48:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2sA-0003jS-Mf; Wed, 23 Nov 2011 02:47:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT2s8-0003j3-HB
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 02:47:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322016404!49542820!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25730 invoked from network); 23 Nov 2011 02:46:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 02:46:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,556,1315180800"; 
   d="scan'208";a="9075928"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 02:47:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 02:47:13 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT2rg-0000xN-QX;
	Wed, 23 Nov 2011 02:47:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT2rg-0002wJ-Pv;
	Wed, 23 Nov 2011 02:47:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9973-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 02:47:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9973: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9973 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9973/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9960 REGR. vs. 9957

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail pass in 9960
 test-i386-i386-win            7 windows-install      fail in 9960 pass in 9973

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-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
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  c613d436ca09
baseline version:
 xen                  4f4763690d74

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23195:c613d436ca09
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 19:03:04 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   23194:4f4763690d74
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:37:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24177:d3859e348951
    xen-unstable date:        Tue Nov 22 13:29:48 2011 +0000
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:48:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2sA-0003jS-Mf; Wed, 23 Nov 2011 02:47:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT2s8-0003j3-HB
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 02:47:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322016404!49542820!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25730 invoked from network); 23 Nov 2011 02:46:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 02:46:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,556,1315180800"; 
   d="scan'208";a="9075928"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 02:47:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 02:47:13 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT2rg-0000xN-QX;
	Wed, 23 Nov 2011 02:47:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT2rg-0002wJ-Pv;
	Wed, 23 Nov 2011 02:47:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9973-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 02:47:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9973: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9973 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9973/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9960 REGR. vs. 9957

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      9 guest-start                  fail pass in 9960
 test-i386-i386-win            7 windows-install      fail in 9960 pass in 9973

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-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
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  c613d436ca09
baseline version:
 xen                  4f4763690d74

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23195:c613d436ca09
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 19:03:04 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   23194:4f4763690d74
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:37:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24177:d3859e348951
    xen-unstable date:        Tue Nov 22 13:29:48 2011 +0000
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wR-0003xa-K3; Wed, 23 Nov 2011 02:52:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RSrOG-0004vb-7M
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 14:32:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321972266!44929494!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17505 invoked from network); 22 Nov 2011 14:31:07 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 14:31:07 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMEVav8011412
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 14:31:36 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
	pAMEVZX3014183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 14:31:35 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMEVS75031972; Tue, 22 Nov 2011 08:31:28 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 06:31:27 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 988E540290;
	Tue, 22 Nov 2011 09:31:23 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAMEVNCW008089;
	Tue, 22 Nov 2011 09:31:23 -0500
Date: Tue, 22 Nov 2011 09:31:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ANNIE LI <annie.li@oracle.com>
Message-ID: <20111122143123.GA3430@phenom.dumpdata.com>
References: <4ECA416D.90602@oracle.com>
	<1321927161-3987-1-git-send-email-annie.li@oracle.com>
	<1321954186.3664.403.camel@zakaz.uk.xensource.com>
	<4ECB7324.9080008@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ECB7324.9080008@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4ECBB249.0016,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 06:02:12PM +0800, ANNIE LI wrote:
> 
> 
> On 2011-11-22 17:29, Ian Campbell wrote:
> >On Tue, 2011-11-22 at 01:59 +0000, annie.li@oracle.com wrote:
> >[...]
> >>+#ifdef CONFIG_X86
> >>+		barrier();
> >>+#else
> >>+		mb();
> >>+#endif
> >>+		}
> >Niggle: Indentation of this final } is off.
> Sorry, I did not notice that.
> >Otherwise all 4 patches:
> >Acked-by: Ian Campbell<ian.campbell@citrix.com>
> >
> >[...]
> Thanks, I will resend those patches after above indentation issue is fixed.

That is OK. I can modify them.
> 
> Thanks.
> 
> Thanks
> Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wR-0003xa-K3; Wed, 23 Nov 2011 02:52:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RSrOG-0004vb-7M
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 14:32:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321972266!44929494!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17505 invoked from network); 22 Nov 2011 14:31:07 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 14:31:07 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMEVav8011412
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 14:31:36 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
	pAMEVZX3014183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 14:31:35 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMEVS75031972; Tue, 22 Nov 2011 08:31:28 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 06:31:27 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 988E540290;
	Tue, 22 Nov 2011 09:31:23 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAMEVNCW008089;
	Tue, 22 Nov 2011 09:31:23 -0500
Date: Tue, 22 Nov 2011 09:31:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ANNIE LI <annie.li@oracle.com>
Message-ID: <20111122143123.GA3430@phenom.dumpdata.com>
References: <4ECA416D.90602@oracle.com>
	<1321927161-3987-1-git-send-email-annie.li@oracle.com>
	<1321954186.3664.403.camel@zakaz.uk.xensource.com>
	<4ECB7324.9080008@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ECB7324.9080008@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4ECBB249.0016,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"kurt.hackel@oracle.com" <kurt.hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen/granttable: Grant tables V2
	implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 06:02:12PM +0800, ANNIE LI wrote:
> 
> 
> On 2011-11-22 17:29, Ian Campbell wrote:
> >On Tue, 2011-11-22 at 01:59 +0000, annie.li@oracle.com wrote:
> >[...]
> >>+#ifdef CONFIG_X86
> >>+		barrier();
> >>+#else
> >>+		mb();
> >>+#endif
> >>+		}
> >Niggle: Indentation of this final } is off.
> Sorry, I did not notice that.
> >Otherwise all 4 patches:
> >Acked-by: Ian Campbell<ian.campbell@citrix.com>
> >
> >[...]
> Thanks, I will resend those patches after above indentation issue is fixed.

That is OK. I can modify them.
> 
> Thanks.
> 
> Thanks
> Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wR-0003xS-6Y; Wed, 23 Nov 2011 02:52:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1RSnNo-0006XO-C3
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:15:20 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321956860!44882476!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4273 invoked from network); 22 Nov 2011 10:14:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 10:14:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'";a="9059000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 10:14:53 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 10:14:53 +0000
Message-ID: <1321956891.4878.4.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 22 Nov 2011 11:14:51 +0100
In-Reply-To: <4ECB67CF0200007800062465@nat28.tlf.novell.com>
References: <osstest-9955-mainreport@xen.org>
	<CAF102CD.2555F%keir.xen@gmail.com>
	<4ECB67CF0200007800062465@nat28.tlf.novell.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.1 (3.2.1-2.fc16) 
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3689681052065571108=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3689681052065571108==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-EmhykqptGCO/D5qLClSg"

--=-EmhykqptGCO/D5qLClSg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-11-22 at 08:13 +0000, Jan Beulich wrote:
> I don't think so - the sedf thing (with varying sub-tests iirc) has been
> (inconsistently) failing for quite a long while.
>=20
Indeed, and I'm starting looking into this to see if we can figure out
what's causing these tests to fail every now and then.

> Further, here this test wasn't even run because xen-boot (below)
> failed. And no matter how many times I looked at the respective
> logs, I wasn't able to spot what it really is that fails here. I can only
> assume that Dom0 is hung, but my sedf knowledge doesn't go far
> enough to tell that for sure from the dumped data.
>=20
Yes, Dom0 hangs rock solid, and hung task detection fires if it is
compiled into Linux, otherwise, I see RCU periodically reporting stall
on some CPU in the system. I'm quite in an interesting situation for
debugging this, since it fails _reliably_ on my 12 cores testbox... The
only thing I'm missing is a serial console cable, but I'm trying to get
around this! :-P

I'll dig this in the next days and let the list know.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)



--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

--=-EmhykqptGCO/D5qLClSg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7LdhsACgkQk4XaBE3IOsSt3QCgjy0kqjEW5qudKLJdpj+6RbZo
fBIAn0Zoc7CiFstIkI3wC0HyQ4/68/4F
=RFuQ
-----END PGP SIGNATURE-----

--=-EmhykqptGCO/D5qLClSg--


--===============3689681052065571108==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3689681052065571108==--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wR-0003xS-6Y; Wed, 23 Nov 2011 02:52:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1RSnNo-0006XO-C3
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:15:20 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1321956860!44882476!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4273 invoked from network); 22 Nov 2011 10:14:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 10:14:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'";a="9059000"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 10:14:53 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 10:14:53 +0000
Message-ID: <1321956891.4878.4.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 22 Nov 2011 11:14:51 +0100
In-Reply-To: <4ECB67CF0200007800062465@nat28.tlf.novell.com>
References: <osstest-9955-mainreport@xen.org>
	<CAF102CD.2555F%keir.xen@gmail.com>
	<4ECB67CF0200007800062465@nat28.tlf.novell.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.1 (3.2.1-2.fc16) 
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3689681052065571108=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3689681052065571108==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-EmhykqptGCO/D5qLClSg"

--=-EmhykqptGCO/D5qLClSg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-11-22 at 08:13 +0000, Jan Beulich wrote:
> I don't think so - the sedf thing (with varying sub-tests iirc) has been
> (inconsistently) failing for quite a long while.
>=20
Indeed, and I'm starting looking into this to see if we can figure out
what's causing these tests to fail every now and then.

> Further, here this test wasn't even run because xen-boot (below)
> failed. And no matter how many times I looked at the respective
> logs, I wasn't able to spot what it really is that fails here. I can only
> assume that Dom0 is hung, but my sedf knowledge doesn't go far
> enough to tell that for sure from the dumped data.
>=20
Yes, Dom0 hangs rock solid, and hung task detection fires if it is
compiled into Linux, otherwise, I see RCU periodically reporting stall
on some CPU in the system. I'm quite in an interesting situation for
debugging this, since it fails _reliably_ on my 12 cores testbox... The
only thing I'm missing is a serial console cable, but I'm trying to get
around this! :-P

I'll dig this in the next days and let the list know.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)



--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

--=-EmhykqptGCO/D5qLClSg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7LdhsACgkQk4XaBE3IOsSt3QCgjy0kqjEW5qudKLJdpj+6RbZo
fBIAn0Zoc7CiFstIkI3wC0HyQ4/68/4F
=RFuQ
-----END PGP SIGNATURE-----

--=-EmhykqptGCO/D5qLClSg--


--===============3689681052065571108==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3689681052065571108==--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wQ-0003xL-Ph; Wed, 23 Nov 2011 02:52:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1RSnNQ-0006Wu-9R
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:14:56 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321956867!3643574!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29266 invoked from network); 22 Nov 2011 10:14:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 10:14:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'";a="9058987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 10:14:26 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 10:14:26 +0000
Message-ID: <1321956856.4878.3.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Tue, 22 Nov 2011 11:14:16 +0100
In-Reply-To: <4ECB5E0D.9020407@ts.fujitsu.com>
References: <CAF102CD.2555F%keir.xen@gmail.com>
	<4ECB5E0D.9020407@ts.fujitsu.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.1 (3.2.1-2.fc16) 
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: Keir Fraser <keir.xen@gmail.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2111038034446826916=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2111038034446826916==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Zf8MZ+b8ilKzXrZiy/bQ"

--=-Zf8MZ+b8ilKzXrZiy/bQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-11-22 at 09:32 +0100, Juergen Gross wrote:
> As Jan already wrote: booting failed with sched=3Dsedf. It works on my ma=
chine
> (4 core Nehalem) with cs 24269.
>=20
As said, it hangs on the 16 Xeon cores (did I say 12 in the other mail?
Bha!) I hve here, while it boots on a very similar --still 16 cores
Xeon-- I use remotely! :-O

I'll let you know when I will have something...

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

--=-Zf8MZ+b8ilKzXrZiy/bQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7LdfkACgkQk4XaBE3IOsRoYwCfWlaz2y/G7fzsMVbxm0SvtDo3
19QAoIC9qytj0yfspAHGmDL+3mdUZEtQ
=KeAD
-----END PGP SIGNATURE-----

--=-Zf8MZ+b8ilKzXrZiy/bQ--


--===============2111038034446826916==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2111038034446826916==--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wQ-0003xL-Ph; Wed, 23 Nov 2011 02:52:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1RSnNQ-0006Wu-9R
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:14:56 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1321956867!3643574!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29266 invoked from network); 22 Nov 2011 10:14:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 10:14:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,552,1315180800"; 
   d="scan'";a="9058987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Nov 2011 10:14:26 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 22 Nov 2011 10:14:26 +0000
Message-ID: <1321956856.4878.3.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Tue, 22 Nov 2011 11:14:16 +0100
In-Reply-To: <4ECB5E0D.9020407@ts.fujitsu.com>
References: <CAF102CD.2555F%keir.xen@gmail.com>
	<4ECB5E0D.9020407@ts.fujitsu.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.1 (3.2.1-2.fc16) 
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: Keir Fraser <keir.xen@gmail.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2111038034446826916=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2111038034446826916==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-Zf8MZ+b8ilKzXrZiy/bQ"

--=-Zf8MZ+b8ilKzXrZiy/bQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2011-11-22 at 09:32 +0100, Juergen Gross wrote:
> As Jan already wrote: booting failed with sched=3Dsedf. It works on my ma=
chine
> (4 core Nehalem) with cs 24269.
>=20
As said, it hangs on the 16 Xeon cores (did I say 12 in the other mail?
Bha!) I hve here, while it boots on a very similar --still 16 cores
Xeon-- I use remotely! :-O

I'll let you know when I will have something...

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

--=-Zf8MZ+b8ilKzXrZiy/bQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7LdfkACgkQk4XaBE3IOsRoYwCfWlaz2y/G7fzsMVbxm0SvtDo3
19QAoIC9qytj0yfspAHGmDL+3mdUZEtQ
=KeAD
-----END PGP SIGNATURE-----

--=-Zf8MZ+b8ilKzXrZiy/bQ--


--===============2111038034446826916==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2111038034446826916==--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wQ-0003xD-CW; Wed, 23 Nov 2011 02:52:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1RSnIl-0006TO-8Z
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:10:07 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1321956578!4106756!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2819 invoked from network); 22 Nov 2011 10:09:38 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 10:09:38 -0000
Received: by bkbzt12 with SMTP id zt12so18029bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 02:09:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references:face
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=qE6Vu9DlN4rdrKxFmGicKrA2BO4YvKLuucmbci+HtzY=;
	b=XoKbNQZv2Cjo7+0zGeY6uP+1nTwiuKTyVHI1LKKwOzMzQlKnixUsPYsk3vzsa1ojcb
	fRGrP/whK5HTWDLymFFAJGGtcToOPooH6wHjzfZSeODZdVBNMlwfu5Fsb2T3S2OGXzlt
	YqEiJr7aP2srDV+X0nDvDU/3Nje7AF7ReItBQ=
Received: by 10.204.199.132 with SMTP id es4mr4106546bkb.4.1321956578410;
	Tue, 22 Nov 2011 02:09:38 -0800 (PST)
Received: from [192.168.0.20] (ip-142-149.sn1.eutelia.it. [62.94.142.149])
	by mx.google.com with ESMTPS id c8sm18380751fai.19.2011.11.22.02.09.33
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 02:09:36 -0800 (PST)
Message-ID: <1321956572.4878.0.camel@Abyss>
From: Dario Faggioli <raistlin.df@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 22 Nov 2011 11:09:32 +0100
In-Reply-To: <4ECB67CF0200007800062465@nat28.tlf.novell.com>
References: <osstest-9955-mainreport@xen.org>
	<CAF102CD.2555F%keir.xen@gmail.com>
	<4ECB67CF0200007800062465@nat28.tlf.novell.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.1 (3.2.1-2.fc16) 
Mime-Version: 1.0
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 08:13 +0000, Jan Beulich wrote:
> I don't think so - the sedf thing (with varying sub-tests iirc) has been
> (inconsistently) failing for quite a long while.
> 
Indeed, and I'm starting looking into this to see if we can figure out
what's causing these tests to fail every now and then.

> Further, here this test wasn't even run because xen-boot (below)
> failed. And no matter how many times I looked at the respective
> logs, I wasn't able to spot what it really is that fails here. I can only
> assume that Dom0 is hung, but my sedf knowledge doesn't go far
> enough to tell that for sure from the dumped data.
> 
Yes, Dom0 hangs rock solid, and hung task detection fires if it is
compiled into Linux, otherwise, I see RCU periodically reporting stall
on some CPU in the system. I'm quite in an interesting situation for
debugging this, since it fails _reliably_ on my 12 cores testbox... The
only thing I'm missing is a serial console cable, but I'm trying to get
around this! :-P

I'll dig this in the next days and let the list know.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wQ-0003xD-CW; Wed, 23 Nov 2011 02:52:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1RSnIl-0006TO-8Z
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 10:10:07 +0000
X-Env-Sender: raistlin.df@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1321956578!4106756!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2819 invoked from network); 22 Nov 2011 10:09:38 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 10:09:38 -0000
Received: by bkbzt12 with SMTP id zt12so18029bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 02:09:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=message-id:subject:from:to:cc:date:in-reply-to:references:face
	:content-type:x-mailer:content-transfer-encoding:mime-version;
	bh=qE6Vu9DlN4rdrKxFmGicKrA2BO4YvKLuucmbci+HtzY=;
	b=XoKbNQZv2Cjo7+0zGeY6uP+1nTwiuKTyVHI1LKKwOzMzQlKnixUsPYsk3vzsa1ojcb
	fRGrP/whK5HTWDLymFFAJGGtcToOPooH6wHjzfZSeODZdVBNMlwfu5Fsb2T3S2OGXzlt
	YqEiJr7aP2srDV+X0nDvDU/3Nje7AF7ReItBQ=
Received: by 10.204.199.132 with SMTP id es4mr4106546bkb.4.1321956578410;
	Tue, 22 Nov 2011 02:09:38 -0800 (PST)
Received: from [192.168.0.20] (ip-142-149.sn1.eutelia.it. [62.94.142.149])
	by mx.google.com with ESMTPS id c8sm18380751fai.19.2011.11.22.02.09.33
	(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 02:09:36 -0800 (PST)
Message-ID: <1321956572.4878.0.camel@Abyss>
From: Dario Faggioli <raistlin.df@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 22 Nov 2011 11:09:32 +0100
In-Reply-To: <4ECB67CF0200007800062465@nat28.tlf.novell.com>
References: <osstest-9955-mainreport@xen.org>
	<CAF102CD.2555F%keir.xen@gmail.com>
	<4ECB67CF0200007800062465@nat28.tlf.novell.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.1 (3.2.1-2.fc16) 
Mime-Version: 1.0
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Keir Fraser <keir.xen@gmail.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 9955: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 08:13 +0000, Jan Beulich wrote:
> I don't think so - the sedf thing (with varying sub-tests iirc) has been
> (inconsistently) failing for quite a long while.
> 
Indeed, and I'm starting looking into this to see if we can figure out
what's causing these tests to fail every now and then.

> Further, here this test wasn't even run because xen-boot (below)
> failed. And no matter how many times I looked at the respective
> logs, I wasn't able to spot what it really is that fails here. I can only
> assume that Dom0 is hung, but my sedf knowledge doesn't go far
> enough to tell that for sure from the dumped data.
> 
Yes, Dom0 hangs rock solid, and hung task detection fires if it is
compiled into Linux, otherwise, I see RCU periodically reporting stall
on some CPU in the system. I'm quite in an interesting situation for
debugging this, since it fails _reliably_ on my 12 cores testbox... The
only thing I'm missing is a serial console cable, but I'm trying to get
around this! :-P

I'll dig this in the next days and let the list know.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wS-0003xo-Fp; Wed, 23 Nov 2011 02:52:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1RStBs-0003Cv-Fk
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:27:25 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321979214!5309545!1
X-Originating-IP: [209.85.212.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12777 invoked from network); 22 Nov 2011 16:26:55 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:26:55 -0000
Received: by vbbfq11 with SMTP id fq11so181631vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 08:26:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=T4y6RD3WdErN/NrtStU7MRng2NovhqGnIUWp/2/Xo2k=;
	b=Uub1QPgB5QEM9Pb/Mgxe3McqYYR182RvXgsMfNhww6fbKYeIgid8VQilqGiQ7WHYyC
	zt6iEuU/+o86cqstcRuNp+CNGC0e6jw8KqBXi7be/RFR5VOtHr7Oh+bUDeLXnKNRZt2K
	0Rx9b0NI8WM5bUETfDX70tOLUdOBV08qkXE3s=
Received: by 10.52.32.73 with SMTP id g9mr20701499vdi.125.1321979214444;
	Tue, 22 Nov 2011 08:26:54 -0800 (PST)
Received: from [192.168.5.144] ([206.223.182.18])
	by mx.google.com with ESMTPS id df14sm5783246vdb.0.2011.11.22.08.26.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 22 Nov 2011 08:26:53 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <4ECBD9EC020000780006266C@nat28.tlf.novell.com>
Date: Tue, 22 Nov 2011 11:26:52 -0500
Message-Id: <4F6F8FA6-05BC-4EEB-8F7E-4C7AF1AECFA7@gmail.com>
References: <4ECBD44A020000780006261B@nat28.tlf.novell.com>
	<CAF17B06.34849%keir@xen.org>
	<4ECBD9EC020000780006266C@nat28.tlf.novell.com>
To: "Jan Beulich" <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1251.1)
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Looks good to me.
Andres
On Nov 22, 2011, at 11:20 AM, Jan Beulich wrote:

>>>> On 22.11.11 at 17:15, Keir Fraser <keir@xen.org> wrote:
>> On 22/11/2011 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> This undoes a single change from c/s 24136:3622d7fae14d
>>> (common/grant_table.c) and several from c/s 24100:be8daf78856a
>>> (common/memory.c). It also completes the former with two previously
>>> missing ia64 specific code adjustments. Authors Cc-ed.
>>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> I'm not going to Ack IA64 patches. Unless there is someone on the IA64 side
>> to do so (which apparently there isn't) you can just go ahead and check
>> these fixup patches in, unless you think a specific patch needs someone
>> else's Ack.
> 
> Okay. In this case, as I'm undoing changes done recently, I'll wait
> a day or two to see whether either of the authors has any comments
> on this.
> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wS-0003xo-Fp; Wed, 23 Nov 2011 02:52:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1RStBs-0003Cv-Fk
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 16:27:25 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1321979214!5309545!1
X-Originating-IP: [209.85.212.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12777 invoked from network); 22 Nov 2011 16:26:55 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Nov 2011 16:26:55 -0000
Received: by vbbfq11 with SMTP id fq11so181631vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 08:26:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=T4y6RD3WdErN/NrtStU7MRng2NovhqGnIUWp/2/Xo2k=;
	b=Uub1QPgB5QEM9Pb/Mgxe3McqYYR182RvXgsMfNhww6fbKYeIgid8VQilqGiQ7WHYyC
	zt6iEuU/+o86cqstcRuNp+CNGC0e6jw8KqBXi7be/RFR5VOtHr7Oh+bUDeLXnKNRZt2K
	0Rx9b0NI8WM5bUETfDX70tOLUdOBV08qkXE3s=
Received: by 10.52.32.73 with SMTP id g9mr20701499vdi.125.1321979214444;
	Tue, 22 Nov 2011 08:26:54 -0800 (PST)
Received: from [192.168.5.144] ([206.223.182.18])
	by mx.google.com with ESMTPS id df14sm5783246vdb.0.2011.11.22.08.26.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 22 Nov 2011 08:26:53 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <4ECBD9EC020000780006266C@nat28.tlf.novell.com>
Date: Tue, 22 Nov 2011 11:26:52 -0500
Message-Id: <4F6F8FA6-05BC-4EEB-8F7E-4C7AF1AECFA7@gmail.com>
References: <4ECBD44A020000780006261B@nat28.tlf.novell.com>
	<CAF17B06.34849%keir@xen.org>
	<4ECBD9EC020000780006266C@nat28.tlf.novell.com>
To: "Jan Beulich" <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1251.1)
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Jean Guyader <jean.guyader@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Looks good to me.
Andres
On Nov 22, 2011, at 11:20 AM, Jan Beulich wrote:

>>>> On 22.11.11 at 17:15, Keir Fraser <keir@xen.org> wrote:
>> On 22/11/2011 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> This undoes a single change from c/s 24136:3622d7fae14d
>>> (common/grant_table.c) and several from c/s 24100:be8daf78856a
>>> (common/memory.c). It also completes the former with two previously
>>> missing ia64 specific code adjustments. Authors Cc-ed.
>>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> I'm not going to Ack IA64 patches. Unless there is someone on the IA64 side
>> to do so (which apparently there isn't) you can just go ahead and check
>> these fixup patches in, unless you think a specific patch needs someone
>> else's Ack.
> 
> Okay. In this case, as I'm undoing changes done recently, I'll wait
> a day or two to see whether either of the authors has any comments
> on this.
> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wS-0003xh-1c; Wed, 23 Nov 2011 02:52:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RSrPF-0004zT-RG
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 14:33:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1321972355!5256886!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26898 invoked from network); 22 Nov 2011 14:32:36 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 14:32:36 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMEWUs5006870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 14:32:31 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMEWURF006762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 14:32:30 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMEWOSq000318; Tue, 22 Nov 2011 08:32:24 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 06:32:24 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 7E8C740290;
	Tue, 22 Nov 2011 09:32:20 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAMEWKFM017318;
	Tue, 22 Nov 2011 09:32:20 -0500
Date: Tue, 22 Nov 2011 09:32:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ANNIE LI <annie.li@oracle.com>
Message-ID: <20111122143220.GB3430@phenom.dumpdata.com>
References: <4ECB77BB.9090401@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ECB77BB.9090401@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4ECBB280.0061,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <paul.durrant@citrix.com>
Subject: Re: [Xen-devel] Forth version patches for upstreaming grant table
	version 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 06:21:47PM +0800, ANNIE LI wrote:
> Hi
> 
> The following patches introduce and implement grant table version 2.
> This is the forth version patches, and based on v3.2.0-rc1+. Changes
> from the previous patches are following:
> 
> * Fix an indentation issue of the code.

I've put your patches in my queue for 3.3. They should show up in my #linux-next
tonight if there are no outstanding compile/test issues.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 02:52:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 02:52:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT2wS-0003xh-1c; Wed, 23 Nov 2011 02:52:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RSrPF-0004zT-RG
	for xen-devel@lists.xensource.com; Tue, 22 Nov 2011 14:33:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1321972355!5256886!1
X-Originating-IP: [148.87.113.117]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26898 invoked from network); 22 Nov 2011 14:32:36 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Nov 2011 14:32:36 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAMEWUs5006870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 22 Nov 2011 14:32:31 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAMEWURF006762
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 22 Nov 2011 14:32:30 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAMEWOSq000318; Tue, 22 Nov 2011 08:32:24 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 22 Nov 2011 06:32:24 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 7E8C740290;
	Tue, 22 Nov 2011 09:32:20 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAMEWKFM017318;
	Tue, 22 Nov 2011 09:32:20 -0500
Date: Tue, 22 Nov 2011 09:32:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ANNIE LI <annie.li@oracle.com>
Message-ID: <20111122143220.GB3430@phenom.dumpdata.com>
References: <4ECB77BB.9090401@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ECB77BB.9090401@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4ECBB280.0061,ss=1,re=0.000,fgs=0
X-Mailman-Approved-At: Wed, 23 Nov 2011 02:52:06 +0000
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Kurt Hackel <Kurt.Hackel@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Durrant <paul.durrant@citrix.com>
Subject: Re: [Xen-devel] Forth version patches for upstreaming grant table
	version 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 06:21:47PM +0800, ANNIE LI wrote:
> Hi
> 
> The following patches introduce and implement grant table version 2.
> This is the forth version patches, and based on v3.2.0-rc1+. Changes
> from the previous patches are following:
> 
> * Fix an indentation issue of the code.

I've put your patches in my queue for 3.3. They should show up in my #linux-next
tonight if there are no outstanding compile/test issues.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 03:40:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 03:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT3gv-0005NT-Qw; Wed, 23 Nov 2011 03:40:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1RT3gu-0005NO-E6
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 03:40:08 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322019579!4228347!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5122 invoked from network); 23 Nov 2011 03:39:39 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 03:39:39 -0000
Received: by wwo1 with SMTP id 1so923579wwo.24
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 19:39:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=4TlDhO/r8luIIfgT4I0kEZrMNbwWt+SvVYL36JBacJg=;
	b=b1ahwwqwvq1Txv+Oc65MsDggNzDK9Q48TeZNmvzdzmnBrjpELdEeqblHyCJzX1AqeW
	oh3JckRgMGrseHMLbTRZZ/AaiQDOq+mCby1AIWE7BodESx4y5VL/RHoDMYS02Yv96YpV
	3zr1PNalffCp+bo8vTjhdpuW7mt6gsRnMqr2s=
MIME-Version: 1.0
Received: by 10.181.12.39 with SMTP id en7mr21672307wid.40.1322019578854; Tue,
	22 Nov 2011 19:39:38 -0800 (PST)
Received: by 10.216.153.39 with HTTP; Tue, 22 Nov 2011 19:39:38 -0800 (PST)
Date: Tue, 22 Nov 2011 22:39:38 -0500
Message-ID: <CAMTrTqWRw+5==adNRrhrq57j8+yZ+WKeekQTrNH=axLyahHjvQ@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Max number of mapped pages by grant table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, All
I am trying to share about 20MB data between dom0 and domU, which is
about  5120 pages. After looking into different sharing mechanisms
between domains, grant table seems a suitable option to me.
I have a question about the max number of mapped page via grant table
from dom0 to dom0. When the number of granted page is <= 532, dom0
succeeds in mapping the pages.
However, when the number of granted pages is > 532, dom0 fails to map
the pages which are from the 533th page. The error message is that
    (XEN) grant_table.c:266:d0 Bad flags (0) or dom (0). (expected dom 0)

I am using xen-4.0.1, and dom0 kernel is 2.6.32.33. Is there any
limitation on the number of mapped pages? Any solution to this?
Thanks.


- Steven

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 03:40:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 03:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT3gv-0005NT-Qw; Wed, 23 Nov 2011 03:40:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wangwangkang@gmail.com>) id 1RT3gu-0005NO-E6
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 03:40:08 +0000
X-Env-Sender: wangwangkang@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322019579!4228347!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5122 invoked from network); 23 Nov 2011 03:39:39 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 03:39:39 -0000
Received: by wwo1 with SMTP id 1so923579wwo.24
	for <xen-devel@lists.xensource.com>;
	Tue, 22 Nov 2011 19:39:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=4TlDhO/r8luIIfgT4I0kEZrMNbwWt+SvVYL36JBacJg=;
	b=b1ahwwqwvq1Txv+Oc65MsDggNzDK9Q48TeZNmvzdzmnBrjpELdEeqblHyCJzX1AqeW
	oh3JckRgMGrseHMLbTRZZ/AaiQDOq+mCby1AIWE7BodESx4y5VL/RHoDMYS02Yv96YpV
	3zr1PNalffCp+bo8vTjhdpuW7mt6gsRnMqr2s=
MIME-Version: 1.0
Received: by 10.181.12.39 with SMTP id en7mr21672307wid.40.1322019578854; Tue,
	22 Nov 2011 19:39:38 -0800 (PST)
Received: by 10.216.153.39 with HTTP; Tue, 22 Nov 2011 19:39:38 -0800 (PST)
Date: Tue, 22 Nov 2011 22:39:38 -0500
Message-ID: <CAMTrTqWRw+5==adNRrhrq57j8+yZ+WKeekQTrNH=axLyahHjvQ@mail.gmail.com>
From: Steven <wangwangkang@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Max number of mapped pages by grant table
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, All
I am trying to share about 20MB data between dom0 and domU, which is
about  5120 pages. After looking into different sharing mechanisms
between domains, grant table seems a suitable option to me.
I have a question about the max number of mapped page via grant table
from dom0 to dom0. When the number of granted page is <= 532, dom0
succeeds in mapping the pages.
However, when the number of granted pages is > 532, dom0 fails to map
the pages which are from the 533th page. The error message is that
    (XEN) grant_table.c:266:d0 Bad flags (0) or dom (0). (expected dom 0)

I am using xen-4.0.1, and dom0 kernel is 2.6.32.33. Is there any
limitation on the number of mapped pages? Any solution to this?
Thanks.


- Steven

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 04:17:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 04:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT4GS-0005qd-0X; Wed, 23 Nov 2011 04:16:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RT4GQ-0005qY-EG
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 04:16:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322021780!3770393!1
X-Originating-IP: [208.97.132.145]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2482 invoked from network); 23 Nov 2011 04:16:20 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.145) by server-5.tower-21.messagelabs.com with SMTP;
	23 Nov 2011 04:16:20 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 4C3DE1A8069;
	Tue, 22 Nov 2011 20:16:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=AspTri4sxQkZrZeYmDrH23Ju6wmQQgWCMq8V40vpDwac
	QhShRWmsND+bpaJijKfuzLYhdbIYZupH6eoqEP1g0dukw8BtsyHqzrx+vqfdYwp4
	cyZAGIJUcMflcEMDxR6AJEtwhWfr0Su7CygNZ79BYlkS/L195PoTVdtuV7fGm1w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=GPp4q8ppU1sfqMlaaVNN7Ui31EU=; b=qimdkHLS
	SHDYFVAAJXhmNv3LCqmoU5j99ZxxqzSrQkHsxpSuSJqf1tSR/Czah3tjNWB2oY+8
	FXR8hWeAQVke00eNTsSTaaytUxIakPdrBGnaS4VykXXjhM91t4026Ky66oaJ8ihb
	F1mjMitKAzFjCr/moA1liS3zkES4Rp+AsGo=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id BB9F61A8063; 
	Tue, 22 Nov 2011 20:16:18 -0800 (PST)
Received: from 75.119.228.217 (proxying for 75.119.228.217)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 22 Nov 2011 20:16:19 -0800
Message-ID: <547ec0a99f6c8f891cd2b526f2e09ff2.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4ECBD9EC020000780006266C@nat28.tlf.novell.com>
References: <4ECBD44A020000780006261B@nat28.tlf.novell.com>
	<CAF17B06.34849%keir@xen.org>
	<4ECBD9EC020000780006266C@nat28.tlf.novell.com>
Date: Tue, 22 Nov 2011 20:16:19 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Jean Guyader <jean.guyader@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

(cc'ing list ....)
Andres

>>>> On 22.11.11 at 17:15, Keir Fraser <keir@xen.org> wrote:
>> On 22/11/2011 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>>> This undoes a single change from c/s 24136:3622d7fae14d
>>> (common/grant_table.c) and several from c/s 24100:be8daf78856a
>>> (common/memory.c). It also completes the former with two previously
>>> missing ia64 specific code adjustments. Authors Cc-ed.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> I'm not going to Ack IA64 patches. Unless there is someone on the IA64
>> side
>> to do so (which apparently there isn't) you can just go ahead and check
>> these fixup patches in, unless you think a specific patch needs someone
>> else's Ack.
>
> Okay. In this case, as I'm undoing changes done recently, I'll wait
> a day or two to see whether either of the authors has any comments
> on this.
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 04:17:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 04:17:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT4GS-0005qd-0X; Wed, 23 Nov 2011 04:16:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RT4GQ-0005qY-EG
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 04:16:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322021780!3770393!1
X-Originating-IP: [208.97.132.145]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2482 invoked from network); 23 Nov 2011 04:16:20 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.145) by server-5.tower-21.messagelabs.com with SMTP;
	23 Nov 2011 04:16:20 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 4C3DE1A8069;
	Tue, 22 Nov 2011 20:16:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=AspTri4sxQkZrZeYmDrH23Ju6wmQQgWCMq8V40vpDwac
	QhShRWmsND+bpaJijKfuzLYhdbIYZupH6eoqEP1g0dukw8BtsyHqzrx+vqfdYwp4
	cyZAGIJUcMflcEMDxR6AJEtwhWfr0Su7CygNZ79BYlkS/L195PoTVdtuV7fGm1w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=GPp4q8ppU1sfqMlaaVNN7Ui31EU=; b=qimdkHLS
	SHDYFVAAJXhmNv3LCqmoU5j99ZxxqzSrQkHsxpSuSJqf1tSR/Czah3tjNWB2oY+8
	FXR8hWeAQVke00eNTsSTaaytUxIakPdrBGnaS4VykXXjhM91t4026Ky66oaJ8ihb
	F1mjMitKAzFjCr/moA1liS3zkES4Rp+AsGo=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id BB9F61A8063; 
	Tue, 22 Nov 2011 20:16:18 -0800 (PST)
Received: from 75.119.228.217 (proxying for 75.119.228.217)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 22 Nov 2011 20:16:19 -0800
Message-ID: <547ec0a99f6c8f891cd2b526f2e09ff2.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4ECBD9EC020000780006266C@nat28.tlf.novell.com>
References: <4ECBD44A020000780006261B@nat28.tlf.novell.com>
	<CAF17B06.34849%keir@xen.org>
	<4ECBD9EC020000780006266C@nat28.tlf.novell.com>
Date: Tue, 22 Nov 2011 20:16:19 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Jean Guyader <jean.guyader@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] ia64: build fixes (again)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

(cc'ing list ....)
Andres

>>>> On 22.11.11 at 17:15, Keir Fraser <keir@xen.org> wrote:
>> On 22/11/2011 15:56, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>>> This undoes a single change from c/s 24136:3622d7fae14d
>>> (common/grant_table.c) and several from c/s 24100:be8daf78856a
>>> (common/memory.c). It also completes the former with two previously
>>> missing ia64 specific code adjustments. Authors Cc-ed.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> I'm not going to Ack IA64 patches. Unless there is someone on the IA64
>> side
>> to do so (which apparently there isn't) you can just go ahead and check
>> these fixup patches in, unless you think a specific patch needs someone
>> else's Ack.
>
> Okay. In this case, as I'm undoing changes done recently, I'll wait
> a day or two to see whether either of the authors has any comments
> on this.
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 04:53:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 04:53:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT4pV-0006I2-7X; Wed, 23 Nov 2011 04:53:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RT4pT-0006Hs-Js
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 04:53:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322023953!5316547!1
X-Originating-IP: [208.97.132.207]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14092 invoked from network); 23 Nov 2011 04:52:33 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.207) by server-12.tower-21.messagelabs.com with SMTP;
	23 Nov 2011 04:52:33 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 7407533406A;
	Tue, 22 Nov 2011 20:52:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=RVRNuUPVSBVxxosXJaPfOzqZo6SgNXEgu80w/7DB3OLS
	cZxhu7TVLqHx8Bdr23Fb9qe2Sl6iUfeBdgD/NbT8ltIZiQg+O5Gsp0MTLOAWIqrH
	wbk60ba6rei7W+899MuZtetQ80JGU9qG+fbJETms68xhcroIDvvl6EzB7nSu6D8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; s=
	lagarcavilla.org; bh=K1KqM17HYZw/k6Z/JScFIEfeHRU=; b=GJjv/t5lFZa
	llNBPpRfHhCCab86OIyA7xqrY8PamQUHYAHISymdp8TI/eolMEAfQ80XslR8M46z
	tXKwEiV+JzjYXs8LyYyY0xw8QlcVQ2ryjs5DawIUbs5xUw22mquvhnh5uQbeDWa0
	QE0iXxCfx4QZOb6596TaAJrbqWkowF1U=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id 41F11334069; 
	Tue, 22 Nov 2011 20:52:32 -0800 (PST)
Received: from 75.119.228.217 (proxying for 75.119.228.217)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 22 Nov 2011 20:52:32 -0800
Message-ID: <b9f83375b8bf452e866311e3ec3fbbc0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
References: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
Date: Tue, 22 Nov 2011 20:52:32 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>,
 xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in
	ept_get
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Olaf,

thanks for posting these RFC patches, great work!

I have several comments. Most importantly, I want to hash out the
interactions between these wait queues and the work I've been doing on p2m
synchronization. I've been runnning Xen with synchronized (i.e. locking)
p2m lookups for a few weeks now with little/no trouble. You can refer to a
patch I posted to the list previously, which I can resend. (I'm waiting on
feedback on some previous patches I sent to keep pushing on this work)

- I think the waitqueue should be part of struct arch_domain. It is an x86
construct that applies only to the base level p2m of the domain, not every
possible p2m in a nested setting.

- The same could be said of the p2m.pod struct, by the way, and that's a
patch I want to get upstreamed too.

- The right place to wait is not ept->get_entry, imho, but rather the
implementation-independent caller (get_gfn_type_access). More p2m
implementations could be added in the future (however unlikely that may
be) that can also perform paging.

- With locking p2m lookups, one needs to be careful about in_atomic. I
haven't performed a full audit of all callers, but this is what I can say:
1. there are no code paths that perform recursive p2m lookups, *on
different gfns*, with p2m_query_t != p2m_query
2. there are recursive lookups of different gfns, with p2m_query_t ==
p2m_query, most notably pod sweeps. These do not represent a problem here,
since those paths will skip over gfns that are paged.

Why is this important? Because we need to be in a position where a code
snippet such as

get_gfn_type_access(gfn) {
retry:
   p2m_lock()
   mfn = p2m->get_entry(gfn, &p2mt)
   if (p2mt == paging) {
       p2m_unlock()
       sleep_on_waitqueue()
       goto retry;
   }

works. This will get us a non-racy p2m that sends vcpu's to sleep without
holding locks. Makes sense?

- What is the plan for grant operations for pv-on-hvm drivers? Those will
enter get_gfn* holding the domain lock, and thus in an atomic context.

Andres
> Date: Tue, 22 Nov 2011 22:13:25 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in
> 	ept_get
> Message-ID: <9d63ecd3969bb7a2e398.1321996405@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1321996199 -3600
> # Node ID 9d63ecd3969bb7a2e39841f6c859b4c23f750642
> # Parent  de6860cb9205b68d1287482288d1b7b9d0255609
> RFC: xenpaging: use waitqueue in ept_get
> %0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 04:53:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 04:53:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT4pV-0006I2-7X; Wed, 23 Nov 2011 04:53:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RT4pT-0006Hs-Js
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 04:53:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322023953!5316547!1
X-Originating-IP: [208.97.132.207]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14092 invoked from network); 23 Nov 2011 04:52:33 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.207) by server-12.tower-21.messagelabs.com with SMTP;
	23 Nov 2011 04:52:33 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 7407533406A;
	Tue, 22 Nov 2011 20:52:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=RVRNuUPVSBVxxosXJaPfOzqZo6SgNXEgu80w/7DB3OLS
	cZxhu7TVLqHx8Bdr23Fb9qe2Sl6iUfeBdgD/NbT8ltIZiQg+O5Gsp0MTLOAWIqrH
	wbk60ba6rei7W+899MuZtetQ80JGU9qG+fbJETms68xhcroIDvvl6EzB7nSu6D8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; s=
	lagarcavilla.org; bh=K1KqM17HYZw/k6Z/JScFIEfeHRU=; b=GJjv/t5lFZa
	llNBPpRfHhCCab86OIyA7xqrY8PamQUHYAHISymdp8TI/eolMEAfQ80XslR8M46z
	tXKwEiV+JzjYXs8LyYyY0xw8QlcVQ2ryjs5DawIUbs5xUw22mquvhnh5uQbeDWa0
	QE0iXxCfx4QZOb6596TaAJrbqWkowF1U=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id 41F11334069; 
	Tue, 22 Nov 2011 20:52:32 -0800 (PST)
Received: from 75.119.228.217 (proxying for 75.119.228.217)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 22 Nov 2011 20:52:32 -0800
Message-ID: <b9f83375b8bf452e866311e3ec3fbbc0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
References: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
Date: Tue, 22 Nov 2011 20:52:32 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>,
 xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in
	ept_get
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Olaf,

thanks for posting these RFC patches, great work!

I have several comments. Most importantly, I want to hash out the
interactions between these wait queues and the work I've been doing on p2m
synchronization. I've been runnning Xen with synchronized (i.e. locking)
p2m lookups for a few weeks now with little/no trouble. You can refer to a
patch I posted to the list previously, which I can resend. (I'm waiting on
feedback on some previous patches I sent to keep pushing on this work)

- I think the waitqueue should be part of struct arch_domain. It is an x86
construct that applies only to the base level p2m of the domain, not every
possible p2m in a nested setting.

- The same could be said of the p2m.pod struct, by the way, and that's a
patch I want to get upstreamed too.

- The right place to wait is not ept->get_entry, imho, but rather the
implementation-independent caller (get_gfn_type_access). More p2m
implementations could be added in the future (however unlikely that may
be) that can also perform paging.

- With locking p2m lookups, one needs to be careful about in_atomic. I
haven't performed a full audit of all callers, but this is what I can say:
1. there are no code paths that perform recursive p2m lookups, *on
different gfns*, with p2m_query_t != p2m_query
2. there are recursive lookups of different gfns, with p2m_query_t ==
p2m_query, most notably pod sweeps. These do not represent a problem here,
since those paths will skip over gfns that are paged.

Why is this important? Because we need to be in a position where a code
snippet such as

get_gfn_type_access(gfn) {
retry:
   p2m_lock()
   mfn = p2m->get_entry(gfn, &p2mt)
   if (p2mt == paging) {
       p2m_unlock()
       sleep_on_waitqueue()
       goto retry;
   }

works. This will get us a non-racy p2m that sends vcpu's to sleep without
holding locks. Makes sense?

- What is the plan for grant operations for pv-on-hvm drivers? Those will
enter get_gfn* holding the domain lock, and thus in an atomic context.

Andres
> Date: Tue, 22 Nov 2011 22:13:25 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in
> 	ept_get
> Message-ID: <9d63ecd3969bb7a2e398.1321996405@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1321996199 -3600
> # Node ID 9d63ecd3969bb7a2e39841f6c859b4c23f750642
> # Parent  de6860cb9205b68d1287482288d1b7b9d0255609
> RFC: xenpaging: use waitqueue in ept_get
> %0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 04:59:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 04:59:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT4uo-0006RG-6a; Wed, 23 Nov 2011 04:58:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RT4um-0006R9-DE
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 04:58:32 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322024272!46723298!1
X-Originating-IP: [208.97.132.66]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13808 invoked from network); 23 Nov 2011 04:57:52 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.66) by server-11.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 04:57:52 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 4E3D725006B;
	Tue, 22 Nov 2011 20:58:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=GD051V78W5Uql2sYQEq9RhW9d5oXbUp/OblndD8oSDLG
	zbVjJoV9R39QVvl4tzW3PWpHnmPoPSHqjcPvqwXEDK0+r5jEPnstl+6unWeaT75m
	dm3H0CDnkUXb0wjUMr6rxqKkXiHrUWOo3jfvocFCRmqPBwPM3tBSRLomyV69Gz0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=nHxmHZlcF2YWUkTEnUaKcitw/nE=; b=BakB2FSs
	jL8to/EMQY0fUCGxp0aa8tWymaNddaE9N/5kNb2tPBC3EFcuCrrpN742UOk3Sv7r
	KuhXzHBkZLGGNslVPUztZ4pugb4i3wC1yZiIFys4KxOxcraj+a+4IIuLVFZ5TI4u
	dUPML0+vKY0kGGorKiApX7EexlQhIEJpyJY=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id 156EE250069; 
	Tue, 22 Nov 2011 20:58:06 -0800 (PST)
Received: from 75.119.228.217 (proxying for 75.119.228.217)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 22 Nov 2011 20:58:06 -0800
Message-ID: <6c2682114a95a003123344f552a2c64c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
References: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
Date: Tue, 22 Nov 2011 20:58:06 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>,
 xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: adin@gridncetric.ca
Subject: Re: [Xen-devel] RFC: mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf, two questions here

- do you have any insight for events caused by foreign mappings? Those
will be lost with a full ring, with or without wait queues

- we have posted a patch (twice) previously, with changes to ring
management, most importantly sending guest vcpus to sleep when space in
the ring is < d->max_vcpus. I see these two patches as complementary. What
is your take?

Thanks,
Andres

> Date: Tue, 22 Nov 2011 22:13:24 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue
> 	when ring	is full
> Message-ID: <de6860cb9205b68d1287.1321996404@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1321996145 -3600
> # Node ID de6860cb9205b68d1287482288d1b7b9d0255609
> # Parent  d347a8a36d2e7951f98a3d22866dce004484d95f
> RFC: mem_event: use wait queue when ring is full
>
> CAUTION: while the patch by itself is supposed to be complete,
> the added usage of waitqueues will lead to sudden host reboots!
>
>
> This change is based on an idea/patch from Adin Scannell.
>
> If the ring is full, put the current vcpu to sleep if it belongs to the
> target domain. The wakeup happens in the p2m_*_resume functions.
> A request from another domain will use the existing ->req_producers
> functionality because sleeping is not possible if the vcpu does not
> belong to the target domain.
>
> This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
> full ring will lead to harmless inconsistency in the pager,
>
> v2:
>  - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise
> the
>    vcpu will not wake_up after a wait_event because the pause_count was
>    increased twice. Fixes guest hangs.
>  - update free space check in _mem_event_put_request()
>  - simplify mem_event_put_request()
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4099,7 +4099,7 @@ static int hvm_memory_event_traps(long p
>          return 1;
>
>      rc = mem_event_check_ring(d, &d->mem_event->mem_access);
> -    if ( rc )
> +    if ( rc < 0 )
>          return rc;
>
>      memset(&req, 0, sizeof(req));
> diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -23,6 +23,7 @@
>
>  #include <asm/domain.h>
>  #include <xen/event.h>
> +#include <xen/wait.h>
>  #include <asm/p2m.h>
>  #include <asm/mem_event.h>
>  #include <asm/mem_paging.h>
> @@ -39,6 +40,7 @@
>
>  static int mem_event_enable(struct domain *d,
>                              xen_domctl_mem_event_op_t *mec,
> +                            int mem_event_bit,
>                              struct mem_event_domain *med)
>  {
>      int rc;
> @@ -107,8 +109,12 @@ static int mem_event_enable(struct domai
>
>      mem_event_ring_lock_init(med);
>
> +    med->mem_event_bit = mem_event_bit;
> +
> +    init_waitqueue_head(&med->wq);
> +
>      /* Wake any VCPUs paused for memory events */
> -    mem_event_unpause_vcpus(d);
> +    mem_event_unpause_vcpus(d, med);
>
>      return 0;
>
> @@ -124,6 +130,9 @@ static int mem_event_enable(struct domai
>
>  static int mem_event_disable(struct mem_event_domain *med)
>  {
> +    if (!list_empty(&med->wq.list))
> +        return -EBUSY;
> +
>      unmap_domain_page(med->ring_page);
>      med->ring_page = NULL;
>
> @@ -133,13 +142,21 @@ static int mem_event_disable(struct mem_
>      return 0;
>  }
>
> -void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req)
> +static int _mem_event_put_request(struct domain *d, struct
> mem_event_domain *med, mem_event_request_t *req)
>  {
>      mem_event_front_ring_t *front_ring;
> +    int free_requests;
>      RING_IDX req_prod;
>
>      mem_event_ring_lock(med);
>
> +    free_requests = RING_FREE_REQUESTS(&med->front_ring);
> +    /* A request was eventually claimed in mem_event_check_ring() */
> +    if ((current->domain == d && free_requests <= med->req_producers) ||
> !free_requests) {
> +        mem_event_ring_unlock(med);
> +        return 0;
> +    }
> +
>      front_ring = &med->front_ring;
>      req_prod = front_ring->req_prod_pvt;
>
> @@ -155,6 +172,20 @@ void mem_event_put_request(struct domain
>      mem_event_ring_unlock(med);
>
>      notify_via_xen_event_channel(d, med->xen_port);
> +
> +    return 1;
> +}
> +
> +void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req)
> +{
> +    /* Go to sleep if request came from guest */
> +    if (current->domain == d) {
> +        wait_event(med->wq, _mem_event_put_request(d, med, req));
> +        return;
> +    }
> +    /* Ring was full anyway, unable to sleep in non-guest context */
> +    if (!_mem_event_put_request(d, med, req))
> +        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n",
> d->domain_id, req->type, req->flags, (unsigned long)req->gfn);
>  }
>
>  void mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp)
> @@ -178,21 +209,27 @@ void mem_event_get_response(struct mem_e
>      mem_event_ring_unlock(med);
>  }
>
> -void mem_event_unpause_vcpus(struct domain *d)
> +void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain
> *med)
>  {
>      struct vcpu *v;
>
>      for_each_vcpu ( d, v )
> -        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
> +        if ( test_and_clear_bit(med->mem_event_bit, &v->pause_flags) )
>              vcpu_wake(v);
>  }
>
> -void mem_event_mark_and_pause(struct vcpu *v)
> +void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain
> *med)
>  {
> -    set_bit(_VPF_mem_event, &v->pause_flags);
> +    set_bit(med->mem_event_bit, &v->pause_flags);
>      vcpu_sleep_nosync(v);
>  }
>
> +/**
> + * mem_event_put_req_producers - Release a claimed slot
> + * @med: mem_event ring
> + *
> + * mem_event_put_req_producers() releases a claimed slot in the mem_event
> ring.
> + */
>  void mem_event_put_req_producers(struct mem_event_domain *med)
>  {
>      mem_event_ring_lock(med);
> @@ -200,9 +237,26 @@ void mem_event_put_req_producers(struct
>      mem_event_ring_unlock(med);
>  }
>
> +/**
> + * mem_event_check_ring - Check state of a mem_event ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * Return codes: < 0: the ring is not yet configured
> + *                 0: the ring has some room
> + *               > 0: the ring is full
> + *
> + * mem_event_check_ring() checks the state of the given mem_event ring.
> + * If the current vcpu belongs to the guest domain, the function assumes
> that
> + * mem_event_put_request() will sleep until the ring has room again.
> + *
> + * If the current vcpu does not belong to the target domain the caller
> must try
> + * again until there is room. A slot is claimed and the caller can place
> a
> + * request. If the caller does not need to send a request, the claimed
> slot has
> + * to be released with mem_event_put_req_producers().
> + */
>  int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
>  {
> -    struct vcpu *curr = current;
>      int free_requests;
>      int ring_full = 1;
>
> @@ -218,8 +272,8 @@ int mem_event_check_ring(struct domain *
>          ring_full = 0;
>      }
>
> -    if ( ring_full && (curr->domain == d) )
> -        mem_event_mark_and_pause(curr);
> +    if ( current->domain == d )
> +        ring_full = 0;
>
>      mem_event_ring_unlock(med);
>
> @@ -287,7 +341,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( p2m->pod.entry_count )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med);
> +            rc = mem_event_enable(d, mec, _VPF_me_mem_paging, med);
>          }
>          break;
>
> @@ -326,7 +380,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med);
> +            rc = mem_event_enable(d, mec, _VPF_me_mem_access, med);
>          }
>          break;
>
> diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -253,19 +253,11 @@ static void mem_sharing_audit(void)
>  #endif
>
>
> -static struct page_info* mem_sharing_alloc_page(struct domain *d,
> -                                                unsigned long gfn)
> +static void mem_sharing_notify_helper(struct domain *d, unsigned long
> gfn)
>  {
> -    struct page_info* page;
>      struct vcpu *v = current;
>      mem_event_request_t req;
>
> -    page = alloc_domheap_page(d, 0);
> -    if(page != NULL) return page;
> -
> -    memset(&req, 0, sizeof(req));
> -    req.type = MEM_EVENT_TYPE_SHARED;
> -
>      if ( v->domain != d )
>      {
>          /* XXX This path needs some attention.  For now, just fail
> foreign
> @@ -275,20 +267,20 @@ static struct page_info* mem_sharing_all
>          gdprintk(XENLOG_ERR,
>                   "Failed alloc on unshare path for foreign (%d)
> lookup\n",
>                   d->domain_id);
> -        return page;
> +        return;
>      }
>
> -    vcpu_pause_nosync(v);
> -    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> +    if (mem_event_check_ring(d, &d->mem_event->mem_share) < 0)
> +        return;
>
> -    if(mem_event_check_ring(d, &d->mem_event->mem_share)) return page;
> -
> +    memset(&req, 0, sizeof(req));
> +    req.type = MEM_EVENT_TYPE_SHARED;
> +    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
>      req.gfn = gfn;
>      req.p2mt = p2m_ram_shared;
>      req.vcpu_id = v->vcpu_id;
>      mem_event_put_request(d, &d->mem_event->mem_share, &req);
> -
> -    return page;
> +    vcpu_pause_nosync(v);
>  }
>
>  unsigned int mem_sharing_get_nr_saved_mfns(void)
> @@ -653,7 +645,7 @@ gfn_found:
>      if(ret == 0) goto private_page_found;
>
>      old_page = page;
> -    page = mem_sharing_alloc_page(d, gfn);
> +    page = alloc_domheap_page(d, 0);
>      if(!page)
>      {
>          /* We've failed to obtain memory for private page. Need to re-add
> the
> @@ -661,6 +653,7 @@ gfn_found:
>          list_add(&gfn_info->list, &hash_entry->gfns);
>          put_gfn(d, gfn);
>          shr_unlock();
> +        mem_sharing_notify_helper(d, gfn);
>          return -ENOMEM;
>      }
>
> diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -884,17 +884,13 @@ void p2m_mem_paging_drop_page(struct dom
>      struct vcpu *v = current;
>      mem_event_request_t req;
>
> -    /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) == 0)
> -    {
> -        /* Send release notification to pager */
> -        memset(&req, 0, sizeof(req));
> -        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
> -        req.gfn = gfn;
> -        req.vcpu_id = v->vcpu_id;
> +    /* Send release notification to pager */
> +    memset(&req, 0, sizeof(req));
> +    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
> +    req.gfn = gfn;
> +    req.vcpu_id = v->vcpu_id;
>
> -        mem_event_put_request(d, &d->mem_event->mem_paging, &req);
> -    }
> +    mem_event_put_request(d, &d->mem_event->mem_paging, &req);
>  }
>
>  /**
> @@ -952,7 +948,6 @@ void p2m_mem_paging_populate(struct doma
>      /* Pause domain if request came from guest and gfn has paging type */
>      if (  p2m_is_paging(p2mt) && v->domain == d )
>      {
> -        vcpu_pause_nosync(v);
>          req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
>      }
>      /* No need to inform pager if the gfn is not in the page-out path */
> @@ -969,6 +964,10 @@ void p2m_mem_paging_populate(struct doma
>      req.vcpu_id = v->vcpu_id;
>
>      mem_event_put_request(d, &d->mem_event->mem_paging, &req);
> +
> +    /* Pause guest after put_request to allow wake_up after wait_event */
> +    if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> +        vcpu_pause_nosync(v);
>  }
>
>  /**
> @@ -1071,8 +1070,8 @@ void p2m_mem_paging_resume(struct domain
>      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>
> -    /* Unpause any domains that were paused because the ring was full */
> -    mem_event_unpause_vcpus(d);
> +    /* Unpause all vcpus that were paused because the ring was full */
> +    wake_up(&d->mem_event->mem_paging.wq);
>  }
>
>  void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
> long gla,
> @@ -1111,7 +1110,7 @@ void p2m_mem_access_check(unsigned long
>                     "Memory access permissions failure, no mem_event
> listener: pausing VCPU %d, dom %d\n",
>                     v->vcpu_id, d->domain_id);
>
> -            mem_event_mark_and_pause(v);
> +            mem_event_mark_and_pause(v, &d->mem_event->mem_access);
>          }
>          else
>          {
> @@ -1131,8 +1130,7 @@ void p2m_mem_access_check(unsigned long
>      req.reason = MEM_EVENT_REASON_VIOLATION;
>
>      /* Pause the current VCPU unconditionally */
> -    vcpu_pause_nosync(v);
> -    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> +    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
>
>      /* Send request to mem event */
>      req.gfn = gfn;
> @@ -1148,6 +1146,7 @@ void p2m_mem_access_check(unsigned long
>      mem_event_put_request(d, &d->mem_event->mem_access, &req);
>
>      /* VCPU paused, mem event request sent */
> +    vcpu_pause_nosync(v);
>  }
>
>  void p2m_mem_access_resume(struct p2m_domain *p2m)
> @@ -1161,9 +1160,11 @@ void p2m_mem_access_resume(struct p2m_do
>      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>
> -    /* Unpause any domains that were paused because the ring was full or
> no listener
> -     * was available */
> -    mem_event_unpause_vcpus(d);
> +    /* Wakeup all vcpus waiting because the ring was full */
> +    wake_up(&d->mem_event->mem_access.wq);
> +
> +    /* Unpause all vcpus that were paused because no listener was
> available */
> +    mem_event_unpause_vcpus(d, &d->mem_event->mem_access);
>  }
>
>
> diff -r d347a8a36d2e -r de6860cb9205 xen/include/asm-x86/mem_event.h
> --- a/xen/include/asm-x86/mem_event.h
> +++ b/xen/include/asm-x86/mem_event.h
> @@ -25,12 +25,12 @@
>  #define __MEM_EVENT_H__
>
>  /* Pauses VCPU while marking pause flag for mem event */
> -void mem_event_mark_and_pause(struct vcpu *v);
> +void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain
> *med);
>  int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
>  void mem_event_put_req_producers(struct mem_event_domain *med);
>  void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req);
>  void mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp);
> -void mem_event_unpause_vcpus(struct domain *d);
> +void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain
> *med);
>
>  int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
>                       XEN_GUEST_HANDLE(void) u_domctl);
> diff -r d347a8a36d2e -r de6860cb9205 xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -14,6 +14,7 @@
>  #include <xen/nodemask.h>
>  #include <xen/radix-tree.h>
>  #include <xen/multicall.h>
> +#include <xen/wait.h>
>  #include <public/xen.h>
>  #include <public/domctl.h>
>  #include <public/sysctl.h>
> @@ -192,6 +193,10 @@ struct mem_event_domain
>      mem_event_front_ring_t front_ring;
>      /* event channel port (vcpu0 only) */
>      int xen_port;
> +    /* mem_event bit for vcpu->pause_flags */
> +    int mem_event_bit;
> +    /* list of vcpus waiting for room in the ring */
> +    struct waitqueue_head wq;
>  };
>
>  struct mem_event_per_domain
> @@ -615,9 +620,12 @@ static inline struct domain *next_domain
>   /* VCPU affinity has changed: migrating to a new CPU. */
>  #define _VPF_migrating       3
>  #define VPF_migrating        (1UL<<_VPF_migrating)
> - /* VCPU is blocked on memory-event ring. */
> -#define _VPF_mem_event       4
> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
> + /* VCPU is blocked on mem_paging ring. */
> +#define _VPF_me_mem_paging   4
> +#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
> + /* VCPU is blocked on mem_access ring. */
> +#define _VPF_me_mem_access   5
> +#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)
>
>  static inline int vcpu_runnable(struct vcpu *v)
>  {
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 22 Nov 2011 22:15:19 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: Keir Fraser <keir.xen@gmail.com>
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue
> 	feature
> Message-ID: <20111122211519.GA1039@aepfle.de>
> Content-Type: text/plain; charset=utf-8
>
> On Tue, Nov 22, Olaf Hering wrote:
>
>> On Tue, Nov 22, Keir Fraser wrote:
>>
>> > Could it have ended up on the waitqueue?
>>
>> Unlikely, but I will add checks for that as well.
>
> I posted three changes which make use of the wait queues.
> For some reason the code at the very end of p2m_mem_paging_populate()
> triggers when d is dom0, so its vcpu is put to sleep.
>
>
> Olaf
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 22 Nov 2011 21:53:35 +0000
> From: Keir Fraser <keir.xen@gmail.com>
> To: Olaf Hering <olaf@aepfle.de>
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue
> 	feature
> Message-ID: <CAF1CA5F.2560C%keir.xen@gmail.com>
> Content-Type: text/plain;	charset="US-ASCII"
>
> On 22/11/2011 21:15, "Olaf Hering" <olaf@aepfle.de> wrote:
>
>> On Tue, Nov 22, Olaf Hering wrote:
>>
>>> On Tue, Nov 22, Keir Fraser wrote:
>>>
>>>> Could it have ended up on the waitqueue?
>>>
>>> Unlikely, but I will add checks for that as well.
>>
>> I posted three changes which make use of the wait queues.
>> For some reason the code at the very end of p2m_mem_paging_populate()
>> triggers when d is dom0, so its vcpu is put to sleep.
>
> We obviously can't have dom0 going to sleep on paging work. This, at
> least,
> isn't a wait-queue bug.
>
>> Olaf
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 81, Issue 296
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 04:59:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 04:59:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT4uo-0006RG-6a; Wed, 23 Nov 2011 04:58:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RT4um-0006R9-DE
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 04:58:32 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322024272!46723298!1
X-Originating-IP: [208.97.132.66]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13808 invoked from network); 23 Nov 2011 04:57:52 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.66) by server-11.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 04:57:52 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 4E3D725006B;
	Tue, 22 Nov 2011 20:58:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=GD051V78W5Uql2sYQEq9RhW9d5oXbUp/OblndD8oSDLG
	zbVjJoV9R39QVvl4tzW3PWpHnmPoPSHqjcPvqwXEDK0+r5jEPnstl+6unWeaT75m
	dm3H0CDnkUXb0wjUMr6rxqKkXiHrUWOo3jfvocFCRmqPBwPM3tBSRLomyV69Gz0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=nHxmHZlcF2YWUkTEnUaKcitw/nE=; b=BakB2FSs
	jL8to/EMQY0fUCGxp0aa8tWymaNddaE9N/5kNb2tPBC3EFcuCrrpN742UOk3Sv7r
	KuhXzHBkZLGGNslVPUztZ4pugb4i3wC1yZiIFys4KxOxcraj+a+4IIuLVFZ5TI4u
	dUPML0+vKY0kGGorKiApX7EexlQhIEJpyJY=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id 156EE250069; 
	Tue, 22 Nov 2011 20:58:06 -0800 (PST)
Received: from 75.119.228.217 (proxying for 75.119.228.217)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 22 Nov 2011 20:58:06 -0800
Message-ID: <6c2682114a95a003123344f552a2c64c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
References: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
Date: Tue, 22 Nov 2011 20:58:06 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>,
 xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: adin@gridncetric.ca
Subject: Re: [Xen-devel] RFC: mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf, two questions here

- do you have any insight for events caused by foreign mappings? Those
will be lost with a full ring, with or without wait queues

- we have posted a patch (twice) previously, with changes to ring
management, most importantly sending guest vcpus to sleep when space in
the ring is < d->max_vcpus. I see these two patches as complementary. What
is your take?

Thanks,
Andres

> Date: Tue, 22 Nov 2011 22:13:24 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue
> 	when ring	is full
> Message-ID: <de6860cb9205b68d1287.1321996404@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1321996145 -3600
> # Node ID de6860cb9205b68d1287482288d1b7b9d0255609
> # Parent  d347a8a36d2e7951f98a3d22866dce004484d95f
> RFC: mem_event: use wait queue when ring is full
>
> CAUTION: while the patch by itself is supposed to be complete,
> the added usage of waitqueues will lead to sudden host reboots!
>
>
> This change is based on an idea/patch from Adin Scannell.
>
> If the ring is full, put the current vcpu to sleep if it belongs to the
> target domain. The wakeup happens in the p2m_*_resume functions.
> A request from another domain will use the existing ->req_producers
> functionality because sleeping is not possible if the vcpu does not
> belong to the target domain.
>
> This change fixes also a bug in p2m_mem_paging_drop_page(). Up to now a
> full ring will lead to harmless inconsistency in the pager,
>
> v2:
>  - p2m_mem_paging_populate: move vcpu_pause after put_request, otherwise
> the
>    vcpu will not wake_up after a wait_event because the pause_count was
>    increased twice. Fixes guest hangs.
>  - update free space check in _mem_event_put_request()
>  - simplify mem_event_put_request()
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4099,7 +4099,7 @@ static int hvm_memory_event_traps(long p
>          return 1;
>
>      rc = mem_event_check_ring(d, &d->mem_event->mem_access);
> -    if ( rc )
> +    if ( rc < 0 )
>          return rc;
>
>      memset(&req, 0, sizeof(req));
> diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -23,6 +23,7 @@
>
>  #include <asm/domain.h>
>  #include <xen/event.h>
> +#include <xen/wait.h>
>  #include <asm/p2m.h>
>  #include <asm/mem_event.h>
>  #include <asm/mem_paging.h>
> @@ -39,6 +40,7 @@
>
>  static int mem_event_enable(struct domain *d,
>                              xen_domctl_mem_event_op_t *mec,
> +                            int mem_event_bit,
>                              struct mem_event_domain *med)
>  {
>      int rc;
> @@ -107,8 +109,12 @@ static int mem_event_enable(struct domai
>
>      mem_event_ring_lock_init(med);
>
> +    med->mem_event_bit = mem_event_bit;
> +
> +    init_waitqueue_head(&med->wq);
> +
>      /* Wake any VCPUs paused for memory events */
> -    mem_event_unpause_vcpus(d);
> +    mem_event_unpause_vcpus(d, med);
>
>      return 0;
>
> @@ -124,6 +130,9 @@ static int mem_event_enable(struct domai
>
>  static int mem_event_disable(struct mem_event_domain *med)
>  {
> +    if (!list_empty(&med->wq.list))
> +        return -EBUSY;
> +
>      unmap_domain_page(med->ring_page);
>      med->ring_page = NULL;
>
> @@ -133,13 +142,21 @@ static int mem_event_disable(struct mem_
>      return 0;
>  }
>
> -void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req)
> +static int _mem_event_put_request(struct domain *d, struct
> mem_event_domain *med, mem_event_request_t *req)
>  {
>      mem_event_front_ring_t *front_ring;
> +    int free_requests;
>      RING_IDX req_prod;
>
>      mem_event_ring_lock(med);
>
> +    free_requests = RING_FREE_REQUESTS(&med->front_ring);
> +    /* A request was eventually claimed in mem_event_check_ring() */
> +    if ((current->domain == d && free_requests <= med->req_producers) ||
> !free_requests) {
> +        mem_event_ring_unlock(med);
> +        return 0;
> +    }
> +
>      front_ring = &med->front_ring;
>      req_prod = front_ring->req_prod_pvt;
>
> @@ -155,6 +172,20 @@ void mem_event_put_request(struct domain
>      mem_event_ring_unlock(med);
>
>      notify_via_xen_event_channel(d, med->xen_port);
> +
> +    return 1;
> +}
> +
> +void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req)
> +{
> +    /* Go to sleep if request came from guest */
> +    if (current->domain == d) {
> +        wait_event(med->wq, _mem_event_put_request(d, med, req));
> +        return;
> +    }
> +    /* Ring was full anyway, unable to sleep in non-guest context */
> +    if (!_mem_event_put_request(d, med, req))
> +        printk("Failed to put memreq: d %u t %x f %x gfn %lx\n",
> d->domain_id, req->type, req->flags, (unsigned long)req->gfn);
>  }
>
>  void mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp)
> @@ -178,21 +209,27 @@ void mem_event_get_response(struct mem_e
>      mem_event_ring_unlock(med);
>  }
>
> -void mem_event_unpause_vcpus(struct domain *d)
> +void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain
> *med)
>  {
>      struct vcpu *v;
>
>      for_each_vcpu ( d, v )
> -        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
> +        if ( test_and_clear_bit(med->mem_event_bit, &v->pause_flags) )
>              vcpu_wake(v);
>  }
>
> -void mem_event_mark_and_pause(struct vcpu *v)
> +void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain
> *med)
>  {
> -    set_bit(_VPF_mem_event, &v->pause_flags);
> +    set_bit(med->mem_event_bit, &v->pause_flags);
>      vcpu_sleep_nosync(v);
>  }
>
> +/**
> + * mem_event_put_req_producers - Release a claimed slot
> + * @med: mem_event ring
> + *
> + * mem_event_put_req_producers() releases a claimed slot in the mem_event
> ring.
> + */
>  void mem_event_put_req_producers(struct mem_event_domain *med)
>  {
>      mem_event_ring_lock(med);
> @@ -200,9 +237,26 @@ void mem_event_put_req_producers(struct
>      mem_event_ring_unlock(med);
>  }
>
> +/**
> + * mem_event_check_ring - Check state of a mem_event ring
> + * @d: guest domain
> + * @med: mem_event ring
> + *
> + * Return codes: < 0: the ring is not yet configured
> + *                 0: the ring has some room
> + *               > 0: the ring is full
> + *
> + * mem_event_check_ring() checks the state of the given mem_event ring.
> + * If the current vcpu belongs to the guest domain, the function assumes
> that
> + * mem_event_put_request() will sleep until the ring has room again.
> + *
> + * If the current vcpu does not belong to the target domain the caller
> must try
> + * again until there is room. A slot is claimed and the caller can place
> a
> + * request. If the caller does not need to send a request, the claimed
> slot has
> + * to be released with mem_event_put_req_producers().
> + */
>  int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
>  {
> -    struct vcpu *curr = current;
>      int free_requests;
>      int ring_full = 1;
>
> @@ -218,8 +272,8 @@ int mem_event_check_ring(struct domain *
>          ring_full = 0;
>      }
>
> -    if ( ring_full && (curr->domain == d) )
> -        mem_event_mark_and_pause(curr);
> +    if ( current->domain == d )
> +        ring_full = 0;
>
>      mem_event_ring_unlock(med);
>
> @@ -287,7 +341,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( p2m->pod.entry_count )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med);
> +            rc = mem_event_enable(d, mec, _VPF_me_mem_paging, med);
>          }
>          break;
>
> @@ -326,7 +380,7 @@ int mem_event_domctl(struct domain *d, x
>              if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
>                  break;
>
> -            rc = mem_event_enable(d, mec, med);
> +            rc = mem_event_enable(d, mec, _VPF_me_mem_access, med);
>          }
>          break;
>
> diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -253,19 +253,11 @@ static void mem_sharing_audit(void)
>  #endif
>
>
> -static struct page_info* mem_sharing_alloc_page(struct domain *d,
> -                                                unsigned long gfn)
> +static void mem_sharing_notify_helper(struct domain *d, unsigned long
> gfn)
>  {
> -    struct page_info* page;
>      struct vcpu *v = current;
>      mem_event_request_t req;
>
> -    page = alloc_domheap_page(d, 0);
> -    if(page != NULL) return page;
> -
> -    memset(&req, 0, sizeof(req));
> -    req.type = MEM_EVENT_TYPE_SHARED;
> -
>      if ( v->domain != d )
>      {
>          /* XXX This path needs some attention.  For now, just fail
> foreign
> @@ -275,20 +267,20 @@ static struct page_info* mem_sharing_all
>          gdprintk(XENLOG_ERR,
>                   "Failed alloc on unshare path for foreign (%d)
> lookup\n",
>                   d->domain_id);
> -        return page;
> +        return;
>      }
>
> -    vcpu_pause_nosync(v);
> -    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> +    if (mem_event_check_ring(d, &d->mem_event->mem_share) < 0)
> +        return;
>
> -    if(mem_event_check_ring(d, &d->mem_event->mem_share)) return page;
> -
> +    memset(&req, 0, sizeof(req));
> +    req.type = MEM_EVENT_TYPE_SHARED;
> +    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
>      req.gfn = gfn;
>      req.p2mt = p2m_ram_shared;
>      req.vcpu_id = v->vcpu_id;
>      mem_event_put_request(d, &d->mem_event->mem_share, &req);
> -
> -    return page;
> +    vcpu_pause_nosync(v);
>  }
>
>  unsigned int mem_sharing_get_nr_saved_mfns(void)
> @@ -653,7 +645,7 @@ gfn_found:
>      if(ret == 0) goto private_page_found;
>
>      old_page = page;
> -    page = mem_sharing_alloc_page(d, gfn);
> +    page = alloc_domheap_page(d, 0);
>      if(!page)
>      {
>          /* We've failed to obtain memory for private page. Need to re-add
> the
> @@ -661,6 +653,7 @@ gfn_found:
>          list_add(&gfn_info->list, &hash_entry->gfns);
>          put_gfn(d, gfn);
>          shr_unlock();
> +        mem_sharing_notify_helper(d, gfn);
>          return -ENOMEM;
>      }
>
> diff -r d347a8a36d2e -r de6860cb9205 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -884,17 +884,13 @@ void p2m_mem_paging_drop_page(struct dom
>      struct vcpu *v = current;
>      mem_event_request_t req;
>
> -    /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) == 0)
> -    {
> -        /* Send release notification to pager */
> -        memset(&req, 0, sizeof(req));
> -        req.flags |= MEM_EVENT_FLAG_DROP_PAGE;
> -        req.gfn = gfn;
> -        req.vcpu_id = v->vcpu_id;
> +    /* Send release notification to pager */
> +    memset(&req, 0, sizeof(req));
> +    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
> +    req.gfn = gfn;
> +    req.vcpu_id = v->vcpu_id;
>
> -        mem_event_put_request(d, &d->mem_event->mem_paging, &req);
> -    }
> +    mem_event_put_request(d, &d->mem_event->mem_paging, &req);
>  }
>
>  /**
> @@ -952,7 +948,6 @@ void p2m_mem_paging_populate(struct doma
>      /* Pause domain if request came from guest and gfn has paging type */
>      if (  p2m_is_paging(p2mt) && v->domain == d )
>      {
> -        vcpu_pause_nosync(v);
>          req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
>      }
>      /* No need to inform pager if the gfn is not in the page-out path */
> @@ -969,6 +964,10 @@ void p2m_mem_paging_populate(struct doma
>      req.vcpu_id = v->vcpu_id;
>
>      mem_event_put_request(d, &d->mem_event->mem_paging, &req);
> +
> +    /* Pause guest after put_request to allow wake_up after wait_event */
> +    if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> +        vcpu_pause_nosync(v);
>  }
>
>  /**
> @@ -1071,8 +1070,8 @@ void p2m_mem_paging_resume(struct domain
>      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>
> -    /* Unpause any domains that were paused because the ring was full */
> -    mem_event_unpause_vcpus(d);
> +    /* Unpause all vcpus that were paused because the ring was full */
> +    wake_up(&d->mem_event->mem_paging.wq);
>  }
>
>  void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned
> long gla,
> @@ -1111,7 +1110,7 @@ void p2m_mem_access_check(unsigned long
>                     "Memory access permissions failure, no mem_event
> listener: pausing VCPU %d, dom %d\n",
>                     v->vcpu_id, d->domain_id);
>
> -            mem_event_mark_and_pause(v);
> +            mem_event_mark_and_pause(v, &d->mem_event->mem_access);
>          }
>          else
>          {
> @@ -1131,8 +1130,7 @@ void p2m_mem_access_check(unsigned long
>      req.reason = MEM_EVENT_REASON_VIOLATION;
>
>      /* Pause the current VCPU unconditionally */
> -    vcpu_pause_nosync(v);
> -    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
> +    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
>
>      /* Send request to mem event */
>      req.gfn = gfn;
> @@ -1148,6 +1146,7 @@ void p2m_mem_access_check(unsigned long
>      mem_event_put_request(d, &d->mem_event->mem_access, &req);
>
>      /* VCPU paused, mem event request sent */
> +    vcpu_pause_nosync(v);
>  }
>
>  void p2m_mem_access_resume(struct p2m_domain *p2m)
> @@ -1161,9 +1160,11 @@ void p2m_mem_access_resume(struct p2m_do
>      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
>          vcpu_unpause(d->vcpu[rsp.vcpu_id]);
>
> -    /* Unpause any domains that were paused because the ring was full or
> no listener
> -     * was available */
> -    mem_event_unpause_vcpus(d);
> +    /* Wakeup all vcpus waiting because the ring was full */
> +    wake_up(&d->mem_event->mem_access.wq);
> +
> +    /* Unpause all vcpus that were paused because no listener was
> available */
> +    mem_event_unpause_vcpus(d, &d->mem_event->mem_access);
>  }
>
>
> diff -r d347a8a36d2e -r de6860cb9205 xen/include/asm-x86/mem_event.h
> --- a/xen/include/asm-x86/mem_event.h
> +++ b/xen/include/asm-x86/mem_event.h
> @@ -25,12 +25,12 @@
>  #define __MEM_EVENT_H__
>
>  /* Pauses VCPU while marking pause flag for mem event */
> -void mem_event_mark_and_pause(struct vcpu *v);
> +void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain
> *med);
>  int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
>  void mem_event_put_req_producers(struct mem_event_domain *med);
>  void mem_event_put_request(struct domain *d, struct mem_event_domain
> *med, mem_event_request_t *req);
>  void mem_event_get_response(struct mem_event_domain *med,
> mem_event_response_t *rsp);
> -void mem_event_unpause_vcpus(struct domain *d);
> +void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain
> *med);
>
>  int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
>                       XEN_GUEST_HANDLE(void) u_domctl);
> diff -r d347a8a36d2e -r de6860cb9205 xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -14,6 +14,7 @@
>  #include <xen/nodemask.h>
>  #include <xen/radix-tree.h>
>  #include <xen/multicall.h>
> +#include <xen/wait.h>
>  #include <public/xen.h>
>  #include <public/domctl.h>
>  #include <public/sysctl.h>
> @@ -192,6 +193,10 @@ struct mem_event_domain
>      mem_event_front_ring_t front_ring;
>      /* event channel port (vcpu0 only) */
>      int xen_port;
> +    /* mem_event bit for vcpu->pause_flags */
> +    int mem_event_bit;
> +    /* list of vcpus waiting for room in the ring */
> +    struct waitqueue_head wq;
>  };
>
>  struct mem_event_per_domain
> @@ -615,9 +620,12 @@ static inline struct domain *next_domain
>   /* VCPU affinity has changed: migrating to a new CPU. */
>  #define _VPF_migrating       3
>  #define VPF_migrating        (1UL<<_VPF_migrating)
> - /* VCPU is blocked on memory-event ring. */
> -#define _VPF_mem_event       4
> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
> + /* VCPU is blocked on mem_paging ring. */
> +#define _VPF_me_mem_paging   4
> +#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
> + /* VCPU is blocked on mem_access ring. */
> +#define _VPF_me_mem_access   5
> +#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)
>
>  static inline int vcpu_runnable(struct vcpu *v)
>  {
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 22 Nov 2011 22:15:19 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: Keir Fraser <keir.xen@gmail.com>
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue
> 	feature
> Message-ID: <20111122211519.GA1039@aepfle.de>
> Content-Type: text/plain; charset=utf-8
>
> On Tue, Nov 22, Olaf Hering wrote:
>
>> On Tue, Nov 22, Keir Fraser wrote:
>>
>> > Could it have ended up on the waitqueue?
>>
>> Unlikely, but I will add checks for that as well.
>
> I posted three changes which make use of the wait queues.
> For some reason the code at the very end of p2m_mem_paging_populate()
> triggers when d is dom0, so its vcpu is put to sleep.
>
>
> Olaf
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 22 Nov 2011 21:53:35 +0000
> From: Keir Fraser <keir.xen@gmail.com>
> To: Olaf Hering <olaf@aepfle.de>
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue
> 	feature
> Message-ID: <CAF1CA5F.2560C%keir.xen@gmail.com>
> Content-Type: text/plain;	charset="US-ASCII"
>
> On 22/11/2011 21:15, "Olaf Hering" <olaf@aepfle.de> wrote:
>
>> On Tue, Nov 22, Olaf Hering wrote:
>>
>>> On Tue, Nov 22, Keir Fraser wrote:
>>>
>>>> Could it have ended up on the waitqueue?
>>>
>>> Unlikely, but I will add checks for that as well.
>>
>> I posted three changes which make use of the wait queues.
>> For some reason the code at the very end of p2m_mem_paging_populate()
>> triggers when d is dom0, so its vcpu is put to sleep.
>
> We obviously can't have dom0 going to sleep on paging work. This, at
> least,
> isn't a wait-queue bug.
>
>> Olaf
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 81, Issue 296
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 06:02:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 06:02:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT5uO-0007Kf-Uw; Wed, 23 Nov 2011 06:02:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT5uM-0007Ka-Hr
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 06:02:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322028101!5309051!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9138 invoked from network); 23 Nov 2011 06:01:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 06:01:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,557,1315180800"; 
   d="scan'208";a="9076977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 06:01:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 06:01:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT5ts-0002Ae-7r;
	Wed, 23 Nov 2011 06:01:40 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT5ts-00042o-3C;
	Wed, 23 Nov 2011 06:01:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9980-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 06:01:40 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9980: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9980 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9980/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9960 REGR. vs. 9957

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore            fail pass in 9960
 test-i386-i386-win            7 windows-install      fail in 9960 pass in 9980

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-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
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  c613d436ca09
baseline version:
 xen                  4f4763690d74

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23195:c613d436ca09
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 19:03:04 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   23194:4f4763690d74
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:37:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24177:d3859e348951
    xen-unstable date:        Tue Nov 22 13:29:48 2011 +0000
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 06:02:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 06:02:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT5uO-0007Kf-Uw; Wed, 23 Nov 2011 06:02:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT5uM-0007Ka-Hr
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 06:02:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322028101!5309051!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9138 invoked from network); 23 Nov 2011 06:01:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 06:01:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,557,1315180800"; 
   d="scan'208";a="9076977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 06:01:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 06:01:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT5ts-0002Ae-7r;
	Wed, 23 Nov 2011 06:01:40 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT5ts-00042o-3C;
	Wed, 23 Nov 2011 06:01:40 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-9980-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 06:01:40 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 9980: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 9980 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9980/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 9960 REGR. vs. 9957

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore            fail pass in 9960
 test-i386-i386-win            7 windows-install      fail in 9960 pass in 9980

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-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
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  c613d436ca09
baseline version:
 xen                  4f4763690d74

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23195:c613d436ca09
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 19:03:04 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   23194:4f4763690d74
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:37:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24177:d3859e348951
    xen-unstable date:        Tue Nov 22 13:29:48 2011 +0000
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 07:22:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 07:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT79q-00089R-4X; Wed, 23 Nov 2011 07:22:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT79n-00089I-OU
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 07:22:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322032901!2659256!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8990 invoked from network); 23 Nov 2011 07:21:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 07:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,557,1315180800"; 
   d="scan'208";a="9077855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 07:21:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 07:21:13 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT78r-0002sL-5f;
	Wed, 23 Nov 2011 07:21:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT78r-0002z5-53;
	Wed, 23 Nov 2011 07:21:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RT78r-0002z5-53@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 07:21:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-i386
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job build-i386
test xen-build

Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08


  changeset:   24184:4ecd3615e726
  tag:         tip
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 9978 fail [host=leaf-beetle] / 9958 ok.
Failure / basis pass flights: 9978 / 9958
(tree in basispass but not in latest: qemu)
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 4ecd3615e726
Basis pass d3859e348951
Generating revisions with ./adhoc-revtuple-generator  http://xenbits.xen.org/staging/xen-unstable.hg#d3859e348951-4ecd3615e726
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1001 nodes in revision graph
Searching for test results:
 9988 pass 53bec838bb08
 9989 fail 4ecd3615e726
 9990 pass 53bec838bb08
 9991 fail 4ecd3615e726
 9958 pass d3859e348951
 9992 pass 53bec838bb08
 9959 fail 4ecd3615e726
 9993 fail 4ecd3615e726
 9978 fail 4ecd3615e726
 9962 fail 4ecd3615e726
 9983 pass d3859e348951
 9984 fail 4ecd3615e726
 9985 pass 8edcd2e3f3f1
 9986 pass b21b6c91c1f4
 9987 pass 2b5c6fff0e5b
Searching for interesting versions
 Result found: flight 9958 (pass), for basis pass
 Result found: flight 9959 (fail), for basis failure
 Repro found: flight 9983 (pass), for basis pass
 Repro found: flight 9984 (fail), for basis failure
 0 revisions at 53bec838bb08
No revisions left to test, checking graph state.
 Result found: flight 9988 (pass), for last pass
 Result found: flight 9989 (fail), for first failure
 Repro found: flight 9990 (pass), for last pass
 Repro found: flight 9991 (fail), for first failure
 Repro found: flight 9992 (pass), for last pass
 Repro found: flight 9993 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24184:4ecd3615e726
  tag:         tip
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386.xen-build.{dot,ps,png,html}.
----------------------------------------
9993: ALL FAIL

flight 9993 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9993/


jobs:
 build-i386                                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 07:22:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 07:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT79q-00089R-4X; Wed, 23 Nov 2011 07:22:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RT79n-00089I-OU
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 07:22:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322032901!2659256!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8990 invoked from network); 23 Nov 2011 07:21:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 07:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,557,1315180800"; 
   d="scan'208";a="9077855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 07:21:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 07:21:13 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RT78r-0002sL-5f;
	Wed, 23 Nov 2011 07:21:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RT78r-0002z5-53;
	Wed, 23 Nov 2011 07:21:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RT78r-0002z5-53@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 07:21:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-i386
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job build-i386
test xen-build

Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08


  changeset:   24184:4ecd3615e726
  tag:         tip
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 9978 fail [host=leaf-beetle] / 9958 ok.
Failure / basis pass flights: 9978 / 9958
(tree in basispass but not in latest: qemu)
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 4ecd3615e726
Basis pass d3859e348951
Generating revisions with ./adhoc-revtuple-generator  http://xenbits.xen.org/staging/xen-unstable.hg#d3859e348951-4ecd3615e726
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 1001 nodes in revision graph
Searching for test results:
 9988 pass 53bec838bb08
 9989 fail 4ecd3615e726
 9990 pass 53bec838bb08
 9991 fail 4ecd3615e726
 9958 pass d3859e348951
 9992 pass 53bec838bb08
 9959 fail 4ecd3615e726
 9993 fail 4ecd3615e726
 9978 fail 4ecd3615e726
 9962 fail 4ecd3615e726
 9983 pass d3859e348951
 9984 fail 4ecd3615e726
 9985 pass 8edcd2e3f3f1
 9986 pass b21b6c91c1f4
 9987 pass 2b5c6fff0e5b
Searching for interesting versions
 Result found: flight 9958 (pass), for basis pass
 Result found: flight 9959 (fail), for basis failure
 Repro found: flight 9983 (pass), for basis pass
 Repro found: flight 9984 (fail), for basis failure
 0 revisions at 53bec838bb08
No revisions left to test, checking graph state.
 Result found: flight 9988 (pass), for last pass
 Result found: flight 9989 (fail), for first failure
 Repro found: flight 9990 (pass), for last pass
 Repro found: flight 9991 (fail), for first failure
 Repro found: flight 9992 (pass), for last pass
 Repro found: flight 9993 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24184:4ecd3615e726
  tag:         tip
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386.xen-build.{dot,ps,png,html}.
----------------------------------------
9993: ALL FAIL

flight 9993 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9993/


jobs:
 build-i386                                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 08:12:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 08:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT7wG-0000ZM-UD; Wed, 23 Nov 2011 08:12:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1RT7wF-0000ZF-CC
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 08:12:15 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322035785!45433390!1
X-Originating-IP: [89.174.63.77]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12414 invoked from network); 23 Nov 2011 08:09:46 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Nov 2011 08:09:46 -0000
Received: (from localhost user: 'dkiper' uid#4000 fake: STDIN
	(dkiper@router-fw.net-space.pl)) by router-fw-old.local.net-space.pl
	id S1600093Ab1KWILo (ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Wed, 23 Nov 2011 09:11:44 +0100
Date: Wed, 23 Nov 2011 09:11:44 +0100
From: Daniel Kiper <dkiper@net-space.pl>
To: George Shuklin <shuklin@selectel.ru>
Message-ID: <20111123081144.GA26773@router-fw-old.local.net-space.pl>
References: <4EC724CA.7040609@selectel.ru>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EC724CA.7040609@selectel.ru>
User-Agent: Mutt/1.3.28i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] pvgrub --> kexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Nov 19, 2011 at 07:38:50AM +0400, George Shuklin wrote:
> Good day.
>
> Right now we have pvgrub and pygrub as loaders. Pygrub is more mature,
> pvgrub is safer and  more 'right' stuff to have.
>
> But even the pvgrub is still have one real problem: we need to write our
> own domU operating system with support of bunch of filesystems, hardly
> to create interactivity, limited network capabilities (...yep, I can be
> nice to have networking at boot time).
>
> How about different approach? If we run linux with specially crafted
> initrd, which will look around, see correct partition, mount it (in
> domU!), get kernel, show menu, do networking and prepare the coffee for
> admin.  After that it will to kexec to found kernel with found initrd
> with required argument.
>
> No any dangerous dom0 manipulation with VDI, no more modules
> synchronization problem (in case 'external' kernel loading). Easy to
> create menus (just any ncurses application), ideal pre-boot
> configuration environment for appliances (I ask user about settings and
> boot real kernel with asked parameters).
>
> The single problem: kexec is not supporting xen.

kexec/kdump is partialy supported by Xen. Xenlinux Ver. 2.6.18
supports kexec/kdump in dom0. As I know Olaf Hering works (still ???)
on support for kexec/kdump for PV-on-HVM domains. Currently my work
focuses on kexec/kdump support for domU for Xenlinux Ver. 2.6.18.
Later it will be ported to mainline kernel. I am going to publish
this about Feb 2012. Additionally, I am going to prepare kexec/kdump
support for dom0 for mainline kernel.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 08:12:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 08:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT7wG-0000ZM-UD; Wed, 23 Nov 2011 08:12:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dkiper@net-space.pl>) id 1RT7wF-0000ZF-CC
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 08:12:15 +0000
X-Env-Sender: dkiper@net-space.pl
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322035785!45433390!1
X-Originating-IP: [89.174.63.77]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12414 invoked from network); 23 Nov 2011 08:09:46 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Nov 2011 08:09:46 -0000
Received: (from localhost user: 'dkiper' uid#4000 fake: STDIN
	(dkiper@router-fw.net-space.pl)) by router-fw-old.local.net-space.pl
	id S1600093Ab1KWILo (ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Wed, 23 Nov 2011 09:11:44 +0100
Date: Wed, 23 Nov 2011 09:11:44 +0100
From: Daniel Kiper <dkiper@net-space.pl>
To: George Shuklin <shuklin@selectel.ru>
Message-ID: <20111123081144.GA26773@router-fw-old.local.net-space.pl>
References: <4EC724CA.7040609@selectel.ru>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EC724CA.7040609@selectel.ru>
User-Agent: Mutt/1.3.28i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] pvgrub --> kexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Nov 19, 2011 at 07:38:50AM +0400, George Shuklin wrote:
> Good day.
>
> Right now we have pvgrub and pygrub as loaders. Pygrub is more mature,
> pvgrub is safer and  more 'right' stuff to have.
>
> But even the pvgrub is still have one real problem: we need to write our
> own domU operating system with support of bunch of filesystems, hardly
> to create interactivity, limited network capabilities (...yep, I can be
> nice to have networking at boot time).
>
> How about different approach? If we run linux with specially crafted
> initrd, which will look around, see correct partition, mount it (in
> domU!), get kernel, show menu, do networking and prepare the coffee for
> admin.  After that it will to kexec to found kernel with found initrd
> with required argument.
>
> No any dangerous dom0 manipulation with VDI, no more modules
> synchronization problem (in case 'external' kernel loading). Easy to
> create menus (just any ncurses application), ideal pre-boot
> configuration environment for appliances (I ask user about settings and
> boot real kernel with asked parameters).
>
> The single problem: kexec is not supporting xen.

kexec/kdump is partialy supported by Xen. Xenlinux Ver. 2.6.18
supports kexec/kdump in dom0. As I know Olaf Hering works (still ???)
on support for kexec/kdump for PV-on-HVM domains. Currently my work
focuses on kexec/kdump support for domU for Xenlinux Ver. 2.6.18.
Later it will be ported to mainline kernel. I am going to publish
this about Feb 2012. Additionally, I am going to prepare kexec/kdump
support for dom0 for mainline kernel.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 08:42:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 08:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8Oj-0000wh-US; Wed, 23 Nov 2011 08:41:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RT8Oi-0000wV-LJ
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 08:41:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322037670!5349404!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30124 invoked from network); 23 Nov 2011 08:41:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 08:41:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 08:41:10 +0000
Message-Id: <4ECCBFB2020000780006286B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 08:41:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <patchbomb.1321996402@probook.site>
	<d347a8a36d2e7951f98a.1321996403@probook.site>
In-Reply-To: <d347a8a36d2e7951f98a.1321996403@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 3] mem_event: move mem_event_domain out
 of struct domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 22:13, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1321996135 -3600
> # Node ID d347a8a36d2e7951f98a3d22866dce004484d95f
> # Parent  d3859e348951cde6b211c5afb610ac1f12a909ec
> mem_event: move mem_event_domain out of struct domain
> 
> An upcoming change increases the size of mem_event_domain. The result is a
> build failure because struct domain gets larger than a page. Allocate the 
> room
> for the three mem_event_domain members at runtime.

This looks like a good general cleanup thing to me. One comment
below.

> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4098,7 +4098,7 @@ static int hvm_memory_event_traps(long p
>      if ( (p & HVMPME_onchangeonly) && (value == old) )
>          return 1;
>      
> -    rc = mem_event_check_ring(d, &d->mem_access);
> +    rc = mem_event_check_ring(d, &d->mem_event->mem_access);
>      if ( rc )
>          return rc;
>      
> @@ -4121,7 +4121,7 @@ static int hvm_memory_event_traps(long p
>          req.gla_valid = 1;
>      }
>      
> -    mem_event_put_request(d, &d->mem_access, &req);
> +    mem_event_put_request(d, &d->mem_event->mem_access, &req);
>      
>      return 1;
>  }
> diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -265,7 +265,7 @@ int mem_event_domctl(struct domain *d, x
>      {
>      case XEN_DOMCTL_MEM_EVENT_OP_PAGING:
>      {
> -        struct mem_event_domain *med = &d->mem_paging;
> +        struct mem_event_domain *med = &d->mem_event->mem_paging;
>          rc = -EINVAL;
>  
>          switch( mec->op )
> @@ -310,7 +310,7 @@ int mem_event_domctl(struct domain *d, x
>  
>      case XEN_DOMCTL_MEM_EVENT_OP_ACCESS: 
>      {
> -        struct mem_event_domain *med = &d->mem_access;
> +        struct mem_event_domain *med = &d->mem_event->mem_access;
>          rc = -EINVAL;
>  
>          switch( mec->op )
> @@ -333,7 +333,7 @@ int mem_event_domctl(struct domain *d, x
>          case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
>          {
>              if ( med->ring_page )
> -                rc = mem_event_disable(&d->mem_access);
> +                rc = mem_event_disable(med);
>          }
>          break;
>  
> diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -281,12 +281,12 @@ static struct page_info* mem_sharing_all
>      vcpu_pause_nosync(v);
>      req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
>  
> -    if(mem_event_check_ring(d, &d->mem_share)) return page;
> +    if(mem_event_check_ring(d, &d->mem_event->mem_share)) return page;
>  
>      req.gfn = gfn;
>      req.p2mt = p2m_ram_shared;
>      req.vcpu_id = v->vcpu_id;
> -    mem_event_put_request(d, &d->mem_share, &req);
> +    mem_event_put_request(d, &d->mem_event->mem_share, &req);
>  
>      return page;
>  }
> @@ -301,7 +301,7 @@ int mem_sharing_sharing_resume(struct do
>      mem_event_response_t rsp;
>  
>      /* Get request off the ring */
> -    mem_event_get_response(&d->mem_share, &rsp);
> +    mem_event_get_response(&d->mem_event->mem_share, &rsp);
>  
>      /* Unpause domain/vcpu */
>      if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -885,7 +885,7 @@ void p2m_mem_paging_drop_page(struct dom
>      mem_event_request_t req;
>  
>      /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_paging) == 0)
> +    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) == 0)
>      {
>          /* Send release notification to pager */
>          memset(&req, 0, sizeof(req));
> @@ -893,7 +893,7 @@ void p2m_mem_paging_drop_page(struct dom
>          req.gfn = gfn;
>          req.vcpu_id = v->vcpu_id;
>  
> -        mem_event_put_request(d, &d->mem_paging, &req);
> +        mem_event_put_request(d, &d->mem_event->mem_paging, &req);
>      }
>  }
>  
> @@ -928,7 +928,7 @@ void p2m_mem_paging_populate(struct doma
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>  
>      /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_paging) )
> +    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) )
>          return;
>  
>      memset(&req, 0, sizeof(req));
> @@ -959,7 +959,7 @@ void p2m_mem_paging_populate(struct doma
>      else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
>      {
>          /* gfn is already on its way back and vcpu is not paused */
> -        mem_event_put_req_producers(&d->mem_paging);
> +        mem_event_put_req_producers(&d->mem_event->mem_paging);
>          return;
>      }
>  
> @@ -968,7 +968,7 @@ void p2m_mem_paging_populate(struct doma
>      req.p2mt = p2mt;
>      req.vcpu_id = v->vcpu_id;
>  
> -    mem_event_put_request(d, &d->mem_paging, &req);
> +    mem_event_put_request(d, &d->mem_event->mem_paging, &req);
>  }
>  
>  /**
> @@ -1048,7 +1048,7 @@ void p2m_mem_paging_resume(struct domain
>      mfn_t mfn;
>  
>      /* Pull the response off the ring */
> -    mem_event_get_response(&d->mem_paging, &rsp);
> +    mem_event_get_response(&d->mem_event->mem_paging, &rsp);
>  
>      /* Fix p2m entry if the page was not dropped */
>      if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
> @@ -1101,7 +1101,7 @@ void p2m_mem_access_check(unsigned long 
>      p2m_unlock(p2m);
>  
>      /* Otherwise, check if there is a memory event listener, and send the 
> message along */
> -    res = mem_event_check_ring(d, &d->mem_access);
> +    res = mem_event_check_ring(d, &d->mem_event->mem_access);
>      if ( res < 0 ) 
>      {
>          /* No listener */
> @@ -1145,7 +1145,7 @@ void p2m_mem_access_check(unsigned long 
>      
>      req.vcpu_id = v->vcpu_id;
>  
> -    mem_event_put_request(d, &d->mem_access, &req);
> +    mem_event_put_request(d, &d->mem_event->mem_access, &req);
>  
>      /* VCPU paused, mem event request sent */
>  }
> @@ -1155,7 +1155,7 @@ void p2m_mem_access_resume(struct p2m_do
>      struct domain *d = p2m->domain;
>      mem_event_response_t rsp;
>  
> -    mem_event_get_response(&d->mem_access, &rsp);
> +    mem_event_get_response(&d->mem_event->mem_access, &rsp);
>  
>      /* Unpause domain */
>      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> diff -r d3859e348951 -r d347a8a36d2e xen/common/domain.c
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -304,6 +304,10 @@ struct domain *domain_create(
>          init_status |= INIT_gnttab;
>  
>          poolid = 0;
> +
> +        d->mem_event = xzalloc(struct mem_event_per_domain);
> +        if ( !d->mem_event )
> +            goto fail;
>      }
>  
>      if ( arch_domain_create(d, domcr_flags) != 0 )
> @@ -335,6 +339,7 @@ struct domain *domain_create(
>   fail:
>      d->is_dying = DOMDYING_dead;
>      atomic_set(&d->refcnt, DOMAIN_DESTROYED);
> +    xfree(d->mem_event);
>      if ( init_status & INIT_arch )
>          arch_domain_destroy(d);
>      if ( init_status & INIT_gnttab )
> diff -r d3859e348951 -r d347a8a36d2e xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -194,6 +194,16 @@ struct mem_event_domain
>      int xen_port;
>  };
>  
> +struct mem_event_per_domain
> +{
> +    /* Memory sharing support */
> +    struct mem_event_domain mem_share;
> +    /* Memory paging support */
> +    struct mem_event_domain mem_paging;
> +    /* Memory access support */
> +    struct mem_event_domain mem_access;

Could we drop the mem_ prefixes here? Reduces typing as well as line
wrapping pressure.

Jan

> +};
> +
>  struct domain
>  {
>      domid_t          domain_id;
> @@ -318,12 +328,8 @@ struct domain
>      /* Non-migratable and non-restoreable? */
>      bool_t disable_migrate;
>  
> -    /* Memory sharing support */
> -    struct mem_event_domain mem_share;
> -    /* Memory paging support */
> -    struct mem_event_domain mem_paging;
> -    /* Memory access support */
> -    struct mem_event_domain mem_access;
> +    /* Various mem_events */
> +    struct mem_event_per_domain *mem_event;
>  
>      /* Currently computed from union of all vcpu cpu-affinity masks. */
>      nodemask_t node_affinity;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 08:42:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 08:42:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8Oj-0000wh-US; Wed, 23 Nov 2011 08:41:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RT8Oi-0000wV-LJ
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 08:41:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322037670!5349404!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30124 invoked from network); 23 Nov 2011 08:41:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 08:41:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 08:41:10 +0000
Message-Id: <4ECCBFB2020000780006286B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 08:41:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <patchbomb.1321996402@probook.site>
	<d347a8a36d2e7951f98a.1321996403@probook.site>
In-Reply-To: <d347a8a36d2e7951f98a.1321996403@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 3] mem_event: move mem_event_domain out
 of struct domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 22:13, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1321996135 -3600
> # Node ID d347a8a36d2e7951f98a3d22866dce004484d95f
> # Parent  d3859e348951cde6b211c5afb610ac1f12a909ec
> mem_event: move mem_event_domain out of struct domain
> 
> An upcoming change increases the size of mem_event_domain. The result is a
> build failure because struct domain gets larger than a page. Allocate the 
> room
> for the three mem_event_domain members at runtime.

This looks like a good general cleanup thing to me. One comment
below.

> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4098,7 +4098,7 @@ static int hvm_memory_event_traps(long p
>      if ( (p & HVMPME_onchangeonly) && (value == old) )
>          return 1;
>      
> -    rc = mem_event_check_ring(d, &d->mem_access);
> +    rc = mem_event_check_ring(d, &d->mem_event->mem_access);
>      if ( rc )
>          return rc;
>      
> @@ -4121,7 +4121,7 @@ static int hvm_memory_event_traps(long p
>          req.gla_valid = 1;
>      }
>      
> -    mem_event_put_request(d, &d->mem_access, &req);
> +    mem_event_put_request(d, &d->mem_event->mem_access, &req);
>      
>      return 1;
>  }
> diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -265,7 +265,7 @@ int mem_event_domctl(struct domain *d, x
>      {
>      case XEN_DOMCTL_MEM_EVENT_OP_PAGING:
>      {
> -        struct mem_event_domain *med = &d->mem_paging;
> +        struct mem_event_domain *med = &d->mem_event->mem_paging;
>          rc = -EINVAL;
>  
>          switch( mec->op )
> @@ -310,7 +310,7 @@ int mem_event_domctl(struct domain *d, x
>  
>      case XEN_DOMCTL_MEM_EVENT_OP_ACCESS: 
>      {
> -        struct mem_event_domain *med = &d->mem_access;
> +        struct mem_event_domain *med = &d->mem_event->mem_access;
>          rc = -EINVAL;
>  
>          switch( mec->op )
> @@ -333,7 +333,7 @@ int mem_event_domctl(struct domain *d, x
>          case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
>          {
>              if ( med->ring_page )
> -                rc = mem_event_disable(&d->mem_access);
> +                rc = mem_event_disable(med);
>          }
>          break;
>  
> diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -281,12 +281,12 @@ static struct page_info* mem_sharing_all
>      vcpu_pause_nosync(v);
>      req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
>  
> -    if(mem_event_check_ring(d, &d->mem_share)) return page;
> +    if(mem_event_check_ring(d, &d->mem_event->mem_share)) return page;
>  
>      req.gfn = gfn;
>      req.p2mt = p2m_ram_shared;
>      req.vcpu_id = v->vcpu_id;
> -    mem_event_put_request(d, &d->mem_share, &req);
> +    mem_event_put_request(d, &d->mem_event->mem_share, &req);
>  
>      return page;
>  }
> @@ -301,7 +301,7 @@ int mem_sharing_sharing_resume(struct do
>      mem_event_response_t rsp;
>  
>      /* Get request off the ring */
> -    mem_event_get_response(&d->mem_share, &rsp);
> +    mem_event_get_response(&d->mem_event->mem_share, &rsp);
>  
>      /* Unpause domain/vcpu */
>      if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> diff -r d3859e348951 -r d347a8a36d2e xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -885,7 +885,7 @@ void p2m_mem_paging_drop_page(struct dom
>      mem_event_request_t req;
>  
>      /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_paging) == 0)
> +    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) == 0)
>      {
>          /* Send release notification to pager */
>          memset(&req, 0, sizeof(req));
> @@ -893,7 +893,7 @@ void p2m_mem_paging_drop_page(struct dom
>          req.gfn = gfn;
>          req.vcpu_id = v->vcpu_id;
>  
> -        mem_event_put_request(d, &d->mem_paging, &req);
> +        mem_event_put_request(d, &d->mem_event->mem_paging, &req);
>      }
>  }
>  
> @@ -928,7 +928,7 @@ void p2m_mem_paging_populate(struct doma
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>  
>      /* Check that there's space on the ring for this request */
> -    if ( mem_event_check_ring(d, &d->mem_paging) )
> +    if ( mem_event_check_ring(d, &d->mem_event->mem_paging) )
>          return;
>  
>      memset(&req, 0, sizeof(req));
> @@ -959,7 +959,7 @@ void p2m_mem_paging_populate(struct doma
>      else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
>      {
>          /* gfn is already on its way back and vcpu is not paused */
> -        mem_event_put_req_producers(&d->mem_paging);
> +        mem_event_put_req_producers(&d->mem_event->mem_paging);
>          return;
>      }
>  
> @@ -968,7 +968,7 @@ void p2m_mem_paging_populate(struct doma
>      req.p2mt = p2mt;
>      req.vcpu_id = v->vcpu_id;
>  
> -    mem_event_put_request(d, &d->mem_paging, &req);
> +    mem_event_put_request(d, &d->mem_event->mem_paging, &req);
>  }
>  
>  /**
> @@ -1048,7 +1048,7 @@ void p2m_mem_paging_resume(struct domain
>      mfn_t mfn;
>  
>      /* Pull the response off the ring */
> -    mem_event_get_response(&d->mem_paging, &rsp);
> +    mem_event_get_response(&d->mem_event->mem_paging, &rsp);
>  
>      /* Fix p2m entry if the page was not dropped */
>      if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
> @@ -1101,7 +1101,7 @@ void p2m_mem_access_check(unsigned long 
>      p2m_unlock(p2m);
>  
>      /* Otherwise, check if there is a memory event listener, and send the 
> message along */
> -    res = mem_event_check_ring(d, &d->mem_access);
> +    res = mem_event_check_ring(d, &d->mem_event->mem_access);
>      if ( res < 0 ) 
>      {
>          /* No listener */
> @@ -1145,7 +1145,7 @@ void p2m_mem_access_check(unsigned long 
>      
>      req.vcpu_id = v->vcpu_id;
>  
> -    mem_event_put_request(d, &d->mem_access, &req);
> +    mem_event_put_request(d, &d->mem_event->mem_access, &req);
>  
>      /* VCPU paused, mem event request sent */
>  }
> @@ -1155,7 +1155,7 @@ void p2m_mem_access_resume(struct p2m_do
>      struct domain *d = p2m->domain;
>      mem_event_response_t rsp;
>  
> -    mem_event_get_response(&d->mem_access, &rsp);
> +    mem_event_get_response(&d->mem_event->mem_access, &rsp);
>  
>      /* Unpause domain */
>      if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> diff -r d3859e348951 -r d347a8a36d2e xen/common/domain.c
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -304,6 +304,10 @@ struct domain *domain_create(
>          init_status |= INIT_gnttab;
>  
>          poolid = 0;
> +
> +        d->mem_event = xzalloc(struct mem_event_per_domain);
> +        if ( !d->mem_event )
> +            goto fail;
>      }
>  
>      if ( arch_domain_create(d, domcr_flags) != 0 )
> @@ -335,6 +339,7 @@ struct domain *domain_create(
>   fail:
>      d->is_dying = DOMDYING_dead;
>      atomic_set(&d->refcnt, DOMAIN_DESTROYED);
> +    xfree(d->mem_event);
>      if ( init_status & INIT_arch )
>          arch_domain_destroy(d);
>      if ( init_status & INIT_gnttab )
> diff -r d3859e348951 -r d347a8a36d2e xen/include/xen/sched.h
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -194,6 +194,16 @@ struct mem_event_domain
>      int xen_port;
>  };
>  
> +struct mem_event_per_domain
> +{
> +    /* Memory sharing support */
> +    struct mem_event_domain mem_share;
> +    /* Memory paging support */
> +    struct mem_event_domain mem_paging;
> +    /* Memory access support */
> +    struct mem_event_domain mem_access;

Could we drop the mem_ prefixes here? Reduces typing as well as line
wrapping pressure.

Jan

> +};
> +
>  struct domain
>  {
>      domid_t          domain_id;
> @@ -318,12 +328,8 @@ struct domain
>      /* Non-migratable and non-restoreable? */
>      bool_t disable_migrate;
>  
> -    /* Memory sharing support */
> -    struct mem_event_domain mem_share;
> -    /* Memory paging support */
> -    struct mem_event_domain mem_paging;
> -    /* Memory access support */
> -    struct mem_event_domain mem_access;
> +    /* Various mem_events */
> +    struct mem_event_per_domain *mem_event;
>  
>      /* Currently computed from union of all vcpu cpu-affinity masks. */
>      nodemask_t node_affinity;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 08:50:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 08:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8WW-00017P-Vz; Wed, 23 Nov 2011 08:49:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RT8WV-00017C-4I
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 08:49:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322038153!5381446!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18294 invoked from network); 23 Nov 2011 08:49:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 08:49:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 08:49:13 +0000
Message-Id: <4ECCC1970200007800062875@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 08:49:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <patchbomb.1321996402@probook.site>
	<de6860cb9205b68d1287.1321996404@probook.site>
In-Reply-To: <de6860cb9205b68d1287.1321996404@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
 ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 22:13, Olaf Hering <olaf@aepfle.de> wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -14,6 +14,7 @@
>  #include <xen/nodemask.h>
>  #include <xen/radix-tree.h>
>  #include <xen/multicall.h>
> +#include <xen/wait.h>
>  #include <public/xen.h>
>  #include <public/domctl.h>
>  #include <public/sysctl.h>
> @@ -192,6 +193,10 @@ struct mem_event_domain
>      mem_event_front_ring_t front_ring;
>      /* event channel port (vcpu0 only) */
>      int xen_port;
> +    /* mem_event bit for vcpu->pause_flags */
> +    int mem_event_bit;

Perhaps pause_bit would be a better name here? Or at least, as for
the first patch, the mem_ prefix should go away (or really the
mem_event_ one, but that would just leave "bit", which is how I got
to the above proposal).

> +    /* list of vcpus waiting for room in the ring */
> +    struct waitqueue_head wq;
>  };
>  
>  struct mem_event_per_domain
> @@ -615,9 +620,12 @@ static inline struct domain *next_domain
>   /* VCPU affinity has changed: migrating to a new CPU. */
>  #define _VPF_migrating       3
>  #define VPF_migrating        (1UL<<_VPF_migrating)
> - /* VCPU is blocked on memory-event ring. */
> -#define _VPF_mem_event       4
> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
> + /* VCPU is blocked on mem_paging ring. */
> +#define _VPF_me_mem_paging   4
> +#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
> + /* VCPU is blocked on mem_access ring. */
> +#define _VPF_me_mem_access   5
> +#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)

Same here - the mem_ seems superfluous.

Jan

>  
>  static inline int vcpu_runnable(struct vcpu *v)
>  {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 08:50:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 08:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8WW-00017P-Vz; Wed, 23 Nov 2011 08:49:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RT8WV-00017C-4I
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 08:49:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322038153!5381446!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18294 invoked from network); 23 Nov 2011 08:49:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 08:49:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 08:49:13 +0000
Message-Id: <4ECCC1970200007800062875@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 08:49:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <patchbomb.1321996402@probook.site>
	<de6860cb9205b68d1287.1321996404@probook.site>
In-Reply-To: <de6860cb9205b68d1287.1321996404@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
 ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 22:13, Olaf Hering <olaf@aepfle.de> wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -14,6 +14,7 @@
>  #include <xen/nodemask.h>
>  #include <xen/radix-tree.h>
>  #include <xen/multicall.h>
> +#include <xen/wait.h>
>  #include <public/xen.h>
>  #include <public/domctl.h>
>  #include <public/sysctl.h>
> @@ -192,6 +193,10 @@ struct mem_event_domain
>      mem_event_front_ring_t front_ring;
>      /* event channel port (vcpu0 only) */
>      int xen_port;
> +    /* mem_event bit for vcpu->pause_flags */
> +    int mem_event_bit;

Perhaps pause_bit would be a better name here? Or at least, as for
the first patch, the mem_ prefix should go away (or really the
mem_event_ one, but that would just leave "bit", which is how I got
to the above proposal).

> +    /* list of vcpus waiting for room in the ring */
> +    struct waitqueue_head wq;
>  };
>  
>  struct mem_event_per_domain
> @@ -615,9 +620,12 @@ static inline struct domain *next_domain
>   /* VCPU affinity has changed: migrating to a new CPU. */
>  #define _VPF_migrating       3
>  #define VPF_migrating        (1UL<<_VPF_migrating)
> - /* VCPU is blocked on memory-event ring. */
> -#define _VPF_mem_event       4
> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
> + /* VCPU is blocked on mem_paging ring. */
> +#define _VPF_me_mem_paging   4
> +#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
> + /* VCPU is blocked on mem_access ring. */
> +#define _VPF_me_mem_access   5
> +#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)

Same here - the mem_ seems superfluous.

Jan

>  
>  static inline int vcpu_runnable(struct vcpu *v)
>  {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 08:55:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 08:55:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8bM-0001IW-Tk; Wed, 23 Nov 2011 08:54:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RT8bM-0001IR-18
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 08:54:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322038444!46745915!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13018 invoked from network); 23 Nov 2011 08:54:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 08:54:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 08:54:19 +0000
Message-Id: <4ECCC2C7020000780006287F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 08:54:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <patchbomb.1321996402@probook.site>
	<9d63ecd3969bb7a2e398.1321996405@probook.site>
In-Reply-To: <9d63ecd3969bb7a2e398.1321996405@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in
 ept_get
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 22:13, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1321996199 -3600
> # Node ID 9d63ecd3969bb7a2e39841f6c859b4c23f750642
> # Parent  de6860cb9205b68d1287482288d1b7b9d0255609
> RFC: xenpaging: use waitqueue in ept_get
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r de6860cb9205 -r 9d63ecd3969b xen/arch/x86/mm/p2m-ept.c
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -505,7 +505,7 @@ out:
>  }
>  
>  /* Read ept p2m entries */
> -static mfn_t ept_get_entry(struct p2m_domain *p2m,
> +static unsigned long _ept_get_entry(struct p2m_domain *p2m,

Looking at the rest of the patch I can't see why the type change here
and below is necessary. It is my understanding that the wrapped
types exist to reduce the chance of mistakes, so they should be kept
whenever possible.

Jan

>                             unsigned long gfn, p2m_type_t *t, p2m_access_t* a,
>                             p2m_query_t q, unsigned int *page_order)
>  {
> @@ -516,7 +516,7 @@ static mfn_t ept_get_entry(struct p2m_do
>      u32 index;
>      int i;
>      int ret = 0;
> -    mfn_t mfn = _mfn(INVALID_MFN);
> +    unsigned long mfn = INVALID_MFN;
>  
>      *t = p2m_mmio_dm;
>      *a = p2m_access_n;
> @@ -582,17 +582,14 @@ static mfn_t ept_get_entry(struct p2m_do
>          *t = ept_entry->sa_p2mt;
>          *a = ept_entry->access;
>  
> -        mfn = _mfn(ept_entry->mfn);
> +        mfn = ept_entry->mfn;
>          if ( i )
>          {
>              /* 
>               * We may meet super pages, and to split into 4k pages
>               * to emulate p2m table
>               */
> -            unsigned long split_mfn = mfn_x(mfn) +
> -                (gfn_remainder &
> -                 ((1 << (i * EPT_TABLE_ORDER)) - 1));
> -            mfn = _mfn(split_mfn);
> +            mfn += (gfn_remainder & ((1 << (i * EPT_TABLE_ORDER)) - 1));
>          }
>  
>          if ( page_order )
> @@ -604,6 +601,41 @@ out:
>      return mfn;
>  }
>  
> +static int
> +ept_get_entry_wait(unsigned long *mfn, int *populated,
> +               struct p2m_domain *p2m, unsigned long gfn, 
> +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
> +               unsigned int *page_order)
> +{
> +    int ret = 1;
> +    *mfn = _ept_get_entry(p2m, gfn, t, a, q, page_order);
> +
> +    /* No further action in case of query */
> +    if ( q == p2m_query )
> +        goto done;
> +
> +    /* Populate the page once in case of guest access, then go to sleep */
> +    if ( p2m_is_paging(*t) && current->domain == p2m->domain ) {
> +        if ( *populated == 0 ) {
> +            *populated = 1;
> +            p2m_mem_paging_populate(p2m->domain, gfn);
> +        }
> +        ret = 0;
> +    }
> +done:
> +    return ret;
> +}
> +static mfn_t
> +ept_get_entry(struct p2m_domain *p2m, unsigned long gfn, 
> +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
> +               unsigned int *page_order)
> +{
> +    unsigned long mfn;
> +    int populated = 0;
> +    wait_event(p2m->wq, ept_get_entry_wait(&mfn, &populated, p2m, gfn, t, a, q, 
> page_order));
> +    return _mfn(mfn);
> +}
> +
>  /* WARNING: Only caller doesn't care about PoD pages.  So this function 
> will
>   * always return 0 for PoD pages, not populate them.  If that becomes 
> necessary,
>   * pass a p2m_query_t type along to distinguish. */
> diff -r de6860cb9205 -r 9d63ecd3969b xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -76,6 +76,7 @@ static void p2m_initialise(struct domain
>      INIT_PAGE_LIST_HEAD(&p2m->pages);
>      INIT_PAGE_LIST_HEAD(&p2m->pod.super);
>      INIT_PAGE_LIST_HEAD(&p2m->pod.single);
> +    init_waitqueue_head(&p2m->wq);
>  
>      p2m->domain = d;
>      p2m->default_access = p2m_access_rwx;
> @@ -1072,6 +1073,8 @@ void p2m_mem_paging_resume(struct domain
>  
>      /* Unpause all vcpus that were paused because the ring was full */
>      wake_up(&d->mem_event->mem_paging.wq);
> +    /* Unpause all vcpus that were paused because the gfn was paged */
> +    wake_up(&p2m->wq);
>  }
>  
>  void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned 
> long gla, 
> diff -r de6860cb9205 -r 9d63ecd3969b xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -286,6 +286,7 @@ struct p2m_domain {
>          unsigned         reclaim_single; /* Last gpfn of a scan */
>          unsigned         max_guest;    /* gpfn of max guest demand-populate 
> */
>      } pod;
> +    struct waitqueue_head wq;
>  };
>  
>  /* get host p2m table */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 08:55:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 08:55:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8bM-0001IW-Tk; Wed, 23 Nov 2011 08:54:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RT8bM-0001IR-18
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 08:54:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322038444!46745915!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13018 invoked from network); 23 Nov 2011 08:54:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 08:54:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 08:54:19 +0000
Message-Id: <4ECCC2C7020000780006287F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 08:54:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <patchbomb.1321996402@probook.site>
	<9d63ecd3969bb7a2e398.1321996405@probook.site>
In-Reply-To: <9d63ecd3969bb7a2e398.1321996405@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in
 ept_get
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 22.11.11 at 22:13, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1321996199 -3600
> # Node ID 9d63ecd3969bb7a2e39841f6c859b4c23f750642
> # Parent  de6860cb9205b68d1287482288d1b7b9d0255609
> RFC: xenpaging: use waitqueue in ept_get
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r de6860cb9205 -r 9d63ecd3969b xen/arch/x86/mm/p2m-ept.c
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -505,7 +505,7 @@ out:
>  }
>  
>  /* Read ept p2m entries */
> -static mfn_t ept_get_entry(struct p2m_domain *p2m,
> +static unsigned long _ept_get_entry(struct p2m_domain *p2m,

Looking at the rest of the patch I can't see why the type change here
and below is necessary. It is my understanding that the wrapped
types exist to reduce the chance of mistakes, so they should be kept
whenever possible.

Jan

>                             unsigned long gfn, p2m_type_t *t, p2m_access_t* a,
>                             p2m_query_t q, unsigned int *page_order)
>  {
> @@ -516,7 +516,7 @@ static mfn_t ept_get_entry(struct p2m_do
>      u32 index;
>      int i;
>      int ret = 0;
> -    mfn_t mfn = _mfn(INVALID_MFN);
> +    unsigned long mfn = INVALID_MFN;
>  
>      *t = p2m_mmio_dm;
>      *a = p2m_access_n;
> @@ -582,17 +582,14 @@ static mfn_t ept_get_entry(struct p2m_do
>          *t = ept_entry->sa_p2mt;
>          *a = ept_entry->access;
>  
> -        mfn = _mfn(ept_entry->mfn);
> +        mfn = ept_entry->mfn;
>          if ( i )
>          {
>              /* 
>               * We may meet super pages, and to split into 4k pages
>               * to emulate p2m table
>               */
> -            unsigned long split_mfn = mfn_x(mfn) +
> -                (gfn_remainder &
> -                 ((1 << (i * EPT_TABLE_ORDER)) - 1));
> -            mfn = _mfn(split_mfn);
> +            mfn += (gfn_remainder & ((1 << (i * EPT_TABLE_ORDER)) - 1));
>          }
>  
>          if ( page_order )
> @@ -604,6 +601,41 @@ out:
>      return mfn;
>  }
>  
> +static int
> +ept_get_entry_wait(unsigned long *mfn, int *populated,
> +               struct p2m_domain *p2m, unsigned long gfn, 
> +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
> +               unsigned int *page_order)
> +{
> +    int ret = 1;
> +    *mfn = _ept_get_entry(p2m, gfn, t, a, q, page_order);
> +
> +    /* No further action in case of query */
> +    if ( q == p2m_query )
> +        goto done;
> +
> +    /* Populate the page once in case of guest access, then go to sleep */
> +    if ( p2m_is_paging(*t) && current->domain == p2m->domain ) {
> +        if ( *populated == 0 ) {
> +            *populated = 1;
> +            p2m_mem_paging_populate(p2m->domain, gfn);
> +        }
> +        ret = 0;
> +    }
> +done:
> +    return ret;
> +}
> +static mfn_t
> +ept_get_entry(struct p2m_domain *p2m, unsigned long gfn, 
> +               p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
> +               unsigned int *page_order)
> +{
> +    unsigned long mfn;
> +    int populated = 0;
> +    wait_event(p2m->wq, ept_get_entry_wait(&mfn, &populated, p2m, gfn, t, a, q, 
> page_order));
> +    return _mfn(mfn);
> +}
> +
>  /* WARNING: Only caller doesn't care about PoD pages.  So this function 
> will
>   * always return 0 for PoD pages, not populate them.  If that becomes 
> necessary,
>   * pass a p2m_query_t type along to distinguish. */
> diff -r de6860cb9205 -r 9d63ecd3969b xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -76,6 +76,7 @@ static void p2m_initialise(struct domain
>      INIT_PAGE_LIST_HEAD(&p2m->pages);
>      INIT_PAGE_LIST_HEAD(&p2m->pod.super);
>      INIT_PAGE_LIST_HEAD(&p2m->pod.single);
> +    init_waitqueue_head(&p2m->wq);
>  
>      p2m->domain = d;
>      p2m->default_access = p2m_access_rwx;
> @@ -1072,6 +1073,8 @@ void p2m_mem_paging_resume(struct domain
>  
>      /* Unpause all vcpus that were paused because the ring was full */
>      wake_up(&d->mem_event->mem_paging.wq);
> +    /* Unpause all vcpus that were paused because the gfn was paged */
> +    wake_up(&p2m->wq);
>  }
>  
>  void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned 
> long gla, 
> diff -r de6860cb9205 -r 9d63ecd3969b xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -286,6 +286,7 @@ struct p2m_domain {
>          unsigned         reclaim_single; /* Last gpfn of a scan */
>          unsigned         max_guest;    /* gpfn of max guest demand-populate 
> */
>      } pod;
> +    struct waitqueue_head wq;
>  };
>  
>  /* get host p2m table */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:02:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8iR-0001Xt-Vi; Wed, 23 Nov 2011 09:02:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RT8iQ-0001Xo-Qa
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:02:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322038893!5365685!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9234 invoked from network); 23 Nov 2011 09:01:33 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:01:33 -0000
Received: by bkbzt12 with SMTP id zt12so1785436bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 01:01:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=aiTegzw78YUVIn9It/2g/cecGrRxCnrn+5fjP2cQDCU=;
	b=WvU878azbF/2DGC+bOagEGVOeG1x72T1SjswggrZoudztlH0H7ONy1oeW6u4Bqwc8Y
	vzIYP2v1L/RFbOHClFuusykhfdQoKAxkht181dQFLzHyPQ378QxXxyIQcaQfo2FM/k/5
	izz6sPZm6HRP2N2tPVZB8NK7BNMdrrmd8O9ik=
Received: by 10.205.126.13 with SMTP id gu13mr23117542bkc.114.1322038889628;
	Wed, 23 Nov 2011 01:01:29 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id o7sm12232232bkw.16.2011.11.23.01.01.27
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 01:01:28 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 09:01:19 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF266DF.3489F%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
	ring is full
Thread-Index: Acypvnbdii1ONf9Yk0iaOWR0NjmHsg==
In-Reply-To: <4ECCC1970200007800062875@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
 ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 08:49, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 22.11.11 at 22:13, Olaf Hering <olaf@aepfle.de> wrote:
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -14,6 +14,7 @@
>>  #include <xen/nodemask.h>
>>  #include <xen/radix-tree.h>
>>  #include <xen/multicall.h>
>> +#include <xen/wait.h>
>>  #include <public/xen.h>
>>  #include <public/domctl.h>
>>  #include <public/sysctl.h>
>> @@ -192,6 +193,10 @@ struct mem_event_domain
>>      mem_event_front_ring_t front_ring;
>>      /* event channel port (vcpu0 only) */
>>      int xen_port;
>> +    /* mem_event bit for vcpu->pause_flags */
>> +    int mem_event_bit;
> 
> Perhaps pause_bit would be a better name here? Or at least, as for
> the first patch, the mem_ prefix should go away (or really the
> mem_event_ one, but that would just leave "bit", which is how I got
> to the above proposal).

Yes, mem_event_bit is a lazy name here. Doesn't really describe what the bit
is actually for. It's obviously mem_event related because of the struct it
is a member of.

>> +    /* list of vcpus waiting for room in the ring */
>> +    struct waitqueue_head wq;
>>  };
>>  
>>  struct mem_event_per_domain
>> @@ -615,9 +620,12 @@ static inline struct domain *next_domain
>>   /* VCPU affinity has changed: migrating to a new CPU. */
>>  #define _VPF_migrating       3
>>  #define VPF_migrating        (1UL<<_VPF_migrating)
>> - /* VCPU is blocked on memory-event ring. */
>> -#define _VPF_mem_event       4
>> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
>> + /* VCPU is blocked on mem_paging ring. */
>> +#define _VPF_me_mem_paging   4
>> +#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
>> + /* VCPU is blocked on mem_access ring. */
>> +#define _VPF_me_mem_access   5
>> +#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)
> 
> Same here - the mem_ seems superfluous.

Mem_event-related flags in a more general grouping do require a mem_ prefix
imo. The names need to stand on their own and still be descriptive.

 -- Keir

> Jan
> 
>>  
>>  static inline int vcpu_runnable(struct vcpu *v)
>>  {
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:02:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8iR-0001Xt-Vi; Wed, 23 Nov 2011 09:02:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RT8iQ-0001Xo-Qa
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:02:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322038893!5365685!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9234 invoked from network); 23 Nov 2011 09:01:33 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:01:33 -0000
Received: by bkbzt12 with SMTP id zt12so1785436bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 01:01:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=aiTegzw78YUVIn9It/2g/cecGrRxCnrn+5fjP2cQDCU=;
	b=WvU878azbF/2DGC+bOagEGVOeG1x72T1SjswggrZoudztlH0H7ONy1oeW6u4Bqwc8Y
	vzIYP2v1L/RFbOHClFuusykhfdQoKAxkht181dQFLzHyPQ378QxXxyIQcaQfo2FM/k/5
	izz6sPZm6HRP2N2tPVZB8NK7BNMdrrmd8O9ik=
Received: by 10.205.126.13 with SMTP id gu13mr23117542bkc.114.1322038889628;
	Wed, 23 Nov 2011 01:01:29 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id o7sm12232232bkw.16.2011.11.23.01.01.27
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 01:01:28 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 09:01:19 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF266DF.3489F%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
	ring is full
Thread-Index: Acypvnbdii1ONf9Yk0iaOWR0NjmHsg==
In-Reply-To: <4ECCC1970200007800062875@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
 ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 08:49, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 22.11.11 at 22:13, Olaf Hering <olaf@aepfle.de> wrote:
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -14,6 +14,7 @@
>>  #include <xen/nodemask.h>
>>  #include <xen/radix-tree.h>
>>  #include <xen/multicall.h>
>> +#include <xen/wait.h>
>>  #include <public/xen.h>
>>  #include <public/domctl.h>
>>  #include <public/sysctl.h>
>> @@ -192,6 +193,10 @@ struct mem_event_domain
>>      mem_event_front_ring_t front_ring;
>>      /* event channel port (vcpu0 only) */
>>      int xen_port;
>> +    /* mem_event bit for vcpu->pause_flags */
>> +    int mem_event_bit;
> 
> Perhaps pause_bit would be a better name here? Or at least, as for
> the first patch, the mem_ prefix should go away (or really the
> mem_event_ one, but that would just leave "bit", which is how I got
> to the above proposal).

Yes, mem_event_bit is a lazy name here. Doesn't really describe what the bit
is actually for. It's obviously mem_event related because of the struct it
is a member of.

>> +    /* list of vcpus waiting for room in the ring */
>> +    struct waitqueue_head wq;
>>  };
>>  
>>  struct mem_event_per_domain
>> @@ -615,9 +620,12 @@ static inline struct domain *next_domain
>>   /* VCPU affinity has changed: migrating to a new CPU. */
>>  #define _VPF_migrating       3
>>  #define VPF_migrating        (1UL<<_VPF_migrating)
>> - /* VCPU is blocked on memory-event ring. */
>> -#define _VPF_mem_event       4
>> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
>> + /* VCPU is blocked on mem_paging ring. */
>> +#define _VPF_me_mem_paging   4
>> +#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
>> + /* VCPU is blocked on mem_access ring. */
>> +#define _VPF_me_mem_access   5
>> +#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)
> 
> Same here - the mem_ seems superfluous.

Mem_event-related flags in a more general grouping do require a mem_ prefix
imo. The names need to stand on their own and still be descriptive.

 -- Keir

> Jan
> 
>>  
>>  static inline int vcpu_runnable(struct vcpu *v)
>>  {
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:12:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:12:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8s0-0001jT-Hg; Wed, 23 Nov 2011 09:11:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RT8ry-0001jO-9c
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:11:54 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322039460!45697657!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11619 invoked from network); 23 Nov 2011 09:11:01 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 09:11:01 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73372461; Wed, 23 Nov 2011 10:11:25 +0100
Message-ID: <1322039476.23989.6.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Wed, 23 Nov 2011 10:11:16 +0100
In-Reply-To: <patchbomb.1321531234@nehalem1>
References: <patchbomb.1321531234@nehalem1>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7554655697852157446=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7554655697852157446==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-TRfwk7qUxW0CdJT+FtT6"


--=-TRfwk7qUxW0CdJT+FtT6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2011-11-17 at 13:00 +0100, Juergen Gross wrote:
> This patch series enhances scheduler support of xl.
>=20
Hi Juergen,

I applied your series to test some changes I'm doing in sched_adjust,
but here's what I'm getting when I boot with sched=3Dcredit2.

# xl sched-credit2
Cpupool Pool-0:
Name                                ID Weight
xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_domain_g=
et

`xl sched-credit' seems to work fine (sedf I can't test, does not boot
on my box).

Could that be my fault? Can I do anything else to help you debug/fix
this?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

--=-TRfwk7qUxW0CdJT+FtT6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7MuLQACgkQk4XaBE3IOsTufACghWIOTIyOdJxaxZ6BUr6h8+Re
c0IAn07/RKu2b0l5Jy+WOeUicQ0foG/E
=beSe
-----END PGP SIGNATURE-----

--=-TRfwk7qUxW0CdJT+FtT6--



--===============7554655697852157446==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7554655697852157446==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:12:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:12:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8s0-0001jT-Hg; Wed, 23 Nov 2011 09:11:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RT8ry-0001jO-9c
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:11:54 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322039460!45697657!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11619 invoked from network); 23 Nov 2011 09:11:01 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 09:11:01 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73372461; Wed, 23 Nov 2011 10:11:25 +0100
Message-ID: <1322039476.23989.6.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Wed, 23 Nov 2011 10:11:16 +0100
In-Reply-To: <patchbomb.1321531234@nehalem1>
References: <patchbomb.1321531234@nehalem1>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7554655697852157446=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7554655697852157446==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-TRfwk7qUxW0CdJT+FtT6"


--=-TRfwk7qUxW0CdJT+FtT6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2011-11-17 at 13:00 +0100, Juergen Gross wrote:
> This patch series enhances scheduler support of xl.
>=20
Hi Juergen,

I applied your series to test some changes I'm doing in sched_adjust,
but here's what I'm getting when I boot with sched=3Dcredit2.

# xl sched-credit2
Cpupool Pool-0:
Name                                ID Weight
xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_domain_g=
et

`xl sched-credit' seems to work fine (sedf I can't test, does not boot
on my box).

Could that be my fault? Can I do anything else to help you debug/fix
this?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

--=-TRfwk7qUxW0CdJT+FtT6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7MuLQACgkQk4XaBE3IOsTufACghWIOTIyOdJxaxZ6BUr6h8+Re
c0IAn07/RKu2b0l5Jy+WOeUicQ0foG/E
=beSe
-----END PGP SIGNATURE-----

--=-TRfwk7qUxW0CdJT+FtT6--



--===============7554655697852157446==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7554655697852157446==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:17:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:17:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8wY-0001qv-9A; Wed, 23 Nov 2011 09:16:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RT8wX-0001qj-FT
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:16:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322039767!2683191!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15990 invoked from network); 23 Nov 2011 09:16:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:16:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9080949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 09:16:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 09:16:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 09:16:06 +0000
In-Reply-To: <E1RT78r-0002z5-53@woking.xci-test.com>
References: <E1RT78r-0002z5-53@woking.xci-test.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322039766.1005.0.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete build-i386
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 07:21 +0000, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job build-i386
> test xen-build
> 
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>   Bug introduced:  4ecd3615e726
>   Bug not present: 53bec838bb08
> 
> 
>   changeset:   24184:4ecd3615e726
>   tag:         tip
>   user:        Ian Campbell <ian.campbell@citrix.com>
>   date:        Tue Nov 22 17:24:51 2011 +0000
>       
>       tools: use system installed libaio by default.

I somehow didn't see this in my testing but it's pretty obvious that
tools/blktap needs the same treatment as tools/blktap2. Patch is
forthcoming.

Ian.

>       
>       I could have sworn I did this years ago.
>       
>       IIRC the need for our own copy was due to the use of io_set_eventfd which is
>       not present in version 0.3.106. However it is in 0.3.107 the first version of
>       which was uploaded to Debian in June 2008 (I can't find a better reference for
>       the release date).
>       
>       The necessary version is available in Debian Lenny onwards and is in at least
>       RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
>       available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
>       version.
>       
>       This is based on tools-system-libaio.diff from the Debian packaging although I
>       have made it optional (but default on).
>       
>       Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       
>       
> 
> 
> For bisection revision-tuple graph see:
>    http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386.xen-build.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> ----------------------------------------
> Searching for failure / basis pass:
>  9978 fail [host=leaf-beetle] / 9958 ok.
> Failure / basis pass flights: 9978 / 9958
> (tree in basispass but not in latest: qemu)
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> Latest 4ecd3615e726
> Basis pass d3859e348951
> Generating revisions with ./adhoc-revtuple-generator  http://xenbits.xen.org/staging/xen-unstable.hg#d3859e348951-4ecd3615e726
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> Loaded 1001 nodes in revision graph
> Searching for test results:
>  9988 pass 53bec838bb08
>  9989 fail 4ecd3615e726
>  9990 pass 53bec838bb08
>  9991 fail 4ecd3615e726
>  9958 pass d3859e348951
>  9992 pass 53bec838bb08
>  9959 fail 4ecd3615e726
>  9993 fail 4ecd3615e726
>  9978 fail 4ecd3615e726
>  9962 fail 4ecd3615e726
>  9983 pass d3859e348951
>  9984 fail 4ecd3615e726
>  9985 pass 8edcd2e3f3f1
>  9986 pass b21b6c91c1f4
>  9987 pass 2b5c6fff0e5b
> Searching for interesting versions
>  Result found: flight 9958 (pass), for basis pass
>  Result found: flight 9959 (fail), for basis failure
>  Repro found: flight 9983 (pass), for basis pass
>  Repro found: flight 9984 (fail), for basis failure
>  0 revisions at 53bec838bb08
> No revisions left to test, checking graph state.
>  Result found: flight 9988 (pass), for last pass
>  Result found: flight 9989 (fail), for first failure
>  Repro found: flight 9990 (pass), for last pass
>  Repro found: flight 9991 (fail), for first failure
>  Repro found: flight 9992 (pass), for last pass
>  Repro found: flight 9993 (fail), for first failure
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>   Bug introduced:  4ecd3615e726
>   Bug not present: 53bec838bb08
> 
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> 
>   changeset:   24184:4ecd3615e726
>   tag:         tip
>   user:        Ian Campbell <ian.campbell@citrix.com>
>   date:        Tue Nov 22 17:24:51 2011 +0000
>       
>       tools: use system installed libaio by default.
>       
>       I could have sworn I did this years ago.
>       
>       IIRC the need for our own copy was due to the use of io_set_eventfd which is
>       not present in version 0.3.106. However it is in 0.3.107 the first version of
>       which was uploaded to Debian in June 2008 (I can't find a better reference for
>       the release date).
>       
>       The necessary version is available in Debian Lenny onwards and is in at least
>       RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
>       available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
>       version.
>       
>       This is based on tools-system-libaio.diff from the Debian packaging although I
>       have made it optional (but default on).
>       
>       Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       
>       
> 
> Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386.xen-build.{dot,ps,png,html}.
> ----------------------------------------
> 9993: ALL FAIL
> 
> flight 9993 xen-unstable real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/9993/
> 
> 
> jobs:
>  build-i386                                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:17:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:17:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT8wY-0001qv-9A; Wed, 23 Nov 2011 09:16:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RT8wX-0001qj-FT
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:16:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322039767!2683191!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15990 invoked from network); 23 Nov 2011 09:16:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:16:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9080949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 09:16:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 09:16:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 09:16:06 +0000
In-Reply-To: <E1RT78r-0002z5-53@woking.xci-test.com>
References: <E1RT78r-0002z5-53@woking.xci-test.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322039766.1005.0.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete build-i386
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 07:21 +0000, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job build-i386
> test xen-build
> 
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>   Bug introduced:  4ecd3615e726
>   Bug not present: 53bec838bb08
> 
> 
>   changeset:   24184:4ecd3615e726
>   tag:         tip
>   user:        Ian Campbell <ian.campbell@citrix.com>
>   date:        Tue Nov 22 17:24:51 2011 +0000
>       
>       tools: use system installed libaio by default.

I somehow didn't see this in my testing but it's pretty obvious that
tools/blktap needs the same treatment as tools/blktap2. Patch is
forthcoming.

Ian.

>       
>       I could have sworn I did this years ago.
>       
>       IIRC the need for our own copy was due to the use of io_set_eventfd which is
>       not present in version 0.3.106. However it is in 0.3.107 the first version of
>       which was uploaded to Debian in June 2008 (I can't find a better reference for
>       the release date).
>       
>       The necessary version is available in Debian Lenny onwards and is in at least
>       RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
>       available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
>       version.
>       
>       This is based on tools-system-libaio.diff from the Debian packaging although I
>       have made it optional (but default on).
>       
>       Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       
>       
> 
> 
> For bisection revision-tuple graph see:
>    http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386.xen-build.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> ----------------------------------------
> Searching for failure / basis pass:
>  9978 fail [host=leaf-beetle] / 9958 ok.
> Failure / basis pass flights: 9978 / 9958
> (tree in basispass but not in latest: qemu)
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> Latest 4ecd3615e726
> Basis pass d3859e348951
> Generating revisions with ./adhoc-revtuple-generator  http://xenbits.xen.org/staging/xen-unstable.hg#d3859e348951-4ecd3615e726
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> Loaded 1001 nodes in revision graph
> Searching for test results:
>  9988 pass 53bec838bb08
>  9989 fail 4ecd3615e726
>  9990 pass 53bec838bb08
>  9991 fail 4ecd3615e726
>  9958 pass d3859e348951
>  9992 pass 53bec838bb08
>  9959 fail 4ecd3615e726
>  9993 fail 4ecd3615e726
>  9978 fail 4ecd3615e726
>  9962 fail 4ecd3615e726
>  9983 pass d3859e348951
>  9984 fail 4ecd3615e726
>  9985 pass 8edcd2e3f3f1
>  9986 pass b21b6c91c1f4
>  9987 pass 2b5c6fff0e5b
> Searching for interesting versions
>  Result found: flight 9958 (pass), for basis pass
>  Result found: flight 9959 (fail), for basis failure
>  Repro found: flight 9983 (pass), for basis pass
>  Repro found: flight 9984 (fail), for basis failure
>  0 revisions at 53bec838bb08
> No revisions left to test, checking graph state.
>  Result found: flight 9988 (pass), for last pass
>  Result found: flight 9989 (fail), for first failure
>  Repro found: flight 9990 (pass), for last pass
>  Repro found: flight 9991 (fail), for first failure
>  Repro found: flight 9992 (pass), for last pass
>  Repro found: flight 9993 (fail), for first failure
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>   Bug introduced:  4ecd3615e726
>   Bug not present: 53bec838bb08
> 
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> 
>   changeset:   24184:4ecd3615e726
>   tag:         tip
>   user:        Ian Campbell <ian.campbell@citrix.com>
>   date:        Tue Nov 22 17:24:51 2011 +0000
>       
>       tools: use system installed libaio by default.
>       
>       I could have sworn I did this years ago.
>       
>       IIRC the need for our own copy was due to the use of io_set_eventfd which is
>       not present in version 0.3.106. However it is in 0.3.107 the first version of
>       which was uploaded to Debian in June 2008 (I can't find a better reference for
>       the release date).
>       
>       The necessary version is available in Debian Lenny onwards and is in at least
>       RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
>       available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
>       version.
>       
>       This is based on tools-system-libaio.diff from the Debian packaging although I
>       have made it optional (but default on).
>       
>       Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>       Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>       
>       
> 
> Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386.xen-build.{dot,ps,png,html}.
> ----------------------------------------
> 9993: ALL FAIL
> 
> flight 9993 xen-unstable real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/9993/
> 
> 
> jobs:
>  build-i386                                                   fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:22:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT91Z-00024n-8I; Wed, 23 Nov 2011 09:21:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RT91X-00024d-9T
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:21:47 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322040040!47015856!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31261 invoked from network); 23 Nov 2011 09:20:40 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:20:40 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=L4aPCocuSXYuQNwRNcW6ZftlE0zmVK0tHjzicKfGPBLOQFIs5UW0Vb9/
	oDGcgmlIBdLsfCduAkRD931YhMr3XqifANKFweIlXFK8COu+jJ4782Dso
	0kzGGJhAqwEJxH5S6MqFN2J4cSo4dnK6mezm46vVo+Mh1ha5eGXm8eReQ
	g0bG9mpRdh9eLqMiZhga9yugoxyPnSLBb7Kc12r7lTHNrI2RlrtL1SJ5m
	a86XKRDjbIAefV1zKJNZ8446fL/so;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322040077; x=1353576077;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=VdzRDlBFGMyXCa80GsvK4tHoHHILLAWkVg0UqbGXTPk=;
	b=QStB3B3zOYI8qGUsx6wBSEQswmAv/P1W21roLtHAypfN9Lyo4N6tLSO5
	SEI3hLiY5DqcuBWEWa0omZieUcrqdQvMD6nSm3T2SqzU4c+bZUFP4raOM
	8xHOvghgALUh9YQFB2aYS/fbI9awfcOKon/cqZWC/Z46vbn8KMyFxgsGJ
	7YK5ep8CuACZO7X7U7fZyvykxXmO6uyWZArGDC5E7baHu5smQ54fOOfIA
	vC7LKe5xQkT+CthgcC4S6hhFa3GPU;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,557,1315173600"; d="scan'208";a="79681445"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 23 Nov 2011 10:21:17 +0100
X-IronPort-AV: E=Sophos;i="4.69,557,1315173600"; d="scan'208";a="123619416"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 23 Nov 2011 10:21:15 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id B80BA76C7F3;
	Wed, 23 Nov 2011 10:21:15 +0100 (CET)
Message-ID: <4ECCBB0B.8020703@ts.fujitsu.com>
Date: Wed, 23 Nov 2011 10:21:15 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
In-Reply-To: <1322039476.23989.6.camel@Abyss>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Dario,

On 11/23/2011 10:11 AM, Dario Faggioli wrote:
> On Thu, 2011-11-17 at 13:00 +0100, Juergen Gross wrote:
>> This patch series enhances scheduler support of xl.
>>
> Hi Juergen,
>
> I applied your series to test some changes I'm doing in sched_adjust,
> but here's what I'm getting when I boot with sched=credit2.
>
> # xl sched-credit2
> Cpupool Pool-0:
> Name                                ID Weight
> xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_domain_get
>
> `xl sched-credit' seems to work fine (sedf I can't test, does not boot
> on my box).
>
> Could that be my fault? Can I do anything else to help you debug/fix
> this?

Are you sure the patches applied completely? libxl_sched_credit2_domain_get()
is added in the third patch to libxl.c, the usage in xl_cmdimpl.c is in the
same patch. I tested it on my box and all worked fine.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:22:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT91Z-00024n-8I; Wed, 23 Nov 2011 09:21:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RT91X-00024d-9T
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:21:47 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322040040!47015856!1
X-Originating-IP: [80.70.172.51]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31261 invoked from network); 23 Nov 2011 09:20:40 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:20:40 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=L4aPCocuSXYuQNwRNcW6ZftlE0zmVK0tHjzicKfGPBLOQFIs5UW0Vb9/
	oDGcgmlIBdLsfCduAkRD931YhMr3XqifANKFweIlXFK8COu+jJ4782Dso
	0kzGGJhAqwEJxH5S6MqFN2J4cSo4dnK6mezm46vVo+Mh1ha5eGXm8eReQ
	g0bG9mpRdh9eLqMiZhga9yugoxyPnSLBb7Kc12r7lTHNrI2RlrtL1SJ5m
	a86XKRDjbIAefV1zKJNZ8446fL/so;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322040077; x=1353576077;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=VdzRDlBFGMyXCa80GsvK4tHoHHILLAWkVg0UqbGXTPk=;
	b=QStB3B3zOYI8qGUsx6wBSEQswmAv/P1W21roLtHAypfN9Lyo4N6tLSO5
	SEI3hLiY5DqcuBWEWa0omZieUcrqdQvMD6nSm3T2SqzU4c+bZUFP4raOM
	8xHOvghgALUh9YQFB2aYS/fbI9awfcOKon/cqZWC/Z46vbn8KMyFxgsGJ
	7YK5ep8CuACZO7X7U7fZyvykxXmO6uyWZArGDC5E7baHu5smQ54fOOfIA
	vC7LKe5xQkT+CthgcC4S6hhFa3GPU;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,557,1315173600"; d="scan'208";a="79681445"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 23 Nov 2011 10:21:17 +0100
X-IronPort-AV: E=Sophos;i="4.69,557,1315173600"; d="scan'208";a="123619416"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 23 Nov 2011 10:21:15 +0100
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id B80BA76C7F3;
	Wed, 23 Nov 2011 10:21:15 +0100 (CET)
Message-ID: <4ECCBB0B.8020703@ts.fujitsu.com>
Date: Wed, 23 Nov 2011 10:21:15 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
In-Reply-To: <1322039476.23989.6.camel@Abyss>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Dario,

On 11/23/2011 10:11 AM, Dario Faggioli wrote:
> On Thu, 2011-11-17 at 13:00 +0100, Juergen Gross wrote:
>> This patch series enhances scheduler support of xl.
>>
> Hi Juergen,
>
> I applied your series to test some changes I'm doing in sched_adjust,
> but here's what I'm getting when I boot with sched=credit2.
>
> # xl sched-credit2
> Cpupool Pool-0:
> Name                                ID Weight
> xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_domain_get
>
> `xl sched-credit' seems to work fine (sedf I can't test, does not boot
> on my box).
>
> Could that be my fault? Can I do anything else to help you debug/fix
> this?

Are you sure the patches applied completely? libxl_sched_credit2_domain_get()
is added in the third patch to libxl.c, the usage in xl_cmdimpl.c is in the
same patch. I tested it on my box and all worked fine.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:25:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT94U-0002Cg-Tp; Wed, 23 Nov 2011 09:24:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RT94T-0002CR-2I
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:24:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322040259!2672805!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3321 invoked from network); 23 Nov 2011 09:24:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:24:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9081166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 09:24:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 09:24:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 23 Nov 2011 09:24:18 +0000
In-Reply-To: <1322039476.23989.6.camel@Abyss>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322040258.1005.1.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 09:11 +0000, Dario Faggioli wrote:
> On Thu, 2011-11-17 at 13:00 +0100, Juergen Gross wrote:
> > This patch series enhances scheduler support of xl.
> > 
> Hi Juergen,
> 
> I applied your series to test some changes I'm doing in sched_adjust,
> but here's what I'm getting when I boot with sched=credit2.
> 
> # xl sched-credit2
> Cpupool Pool-0:
> Name                                ID Weight
> xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_domain_get

Is there a chance you are picking up an older version of libxl from
somewhere?

> 
> `xl sched-credit' seems to work fine (sedf I can't test, does not boot
> on my box).
> 
> Could that be my fault? Can I do anything else to help you debug/fix
> this?
> 
> Thanks and Regards,
> Dario
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:25:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT94U-0002Cg-Tp; Wed, 23 Nov 2011 09:24:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RT94T-0002CR-2I
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:24:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322040259!2672805!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3321 invoked from network); 23 Nov 2011 09:24:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:24:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9081166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 09:24:18 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 09:24:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 23 Nov 2011 09:24:18 +0000
In-Reply-To: <1322039476.23989.6.camel@Abyss>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322040258.1005.1.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 09:11 +0000, Dario Faggioli wrote:
> On Thu, 2011-11-17 at 13:00 +0100, Juergen Gross wrote:
> > This patch series enhances scheduler support of xl.
> > 
> Hi Juergen,
> 
> I applied your series to test some changes I'm doing in sched_adjust,
> but here's what I'm getting when I boot with sched=credit2.
> 
> # xl sched-credit2
> Cpupool Pool-0:
> Name                                ID Weight
> xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_domain_get

Is there a chance you are picking up an older version of libxl from
somewhere?

> 
> `xl sched-credit' seems to work fine (sedf I can't test, does not boot
> on my box).
> 
> Could that be my fault? Can I do anything else to help you debug/fix
> this?
> 
> Thanks and Regards,
> Dario
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:32:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:32:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9Br-0002Sx-4h; Wed, 23 Nov 2011 09:32:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RT9Bo-0002Sp-Ou
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:32:25 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322040681!4605255!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 465 invoked from network); 23 Nov 2011 09:31:22 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:31:22 -0000
Received: by qyk31 with SMTP id 31so1279202qyk.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 01:31:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=kZoXYGohc2Sa+D0U/mXFvHiuI6d4uqT7kMrevza7QlM=;
	b=Uz1URLb8XjU2MNVxQCaIT0X7/CrCIlqnx0BY6ZDp5z1yqINLpywOVXbsxjLk8I98lO
	hqrcdMYtvB3kOwc9JJEk3NlwbtH9fddvWTb7OAuWL8QltgYNJXQR9We2qN2hpxF2oeL1
	4UHLykQVk7/bzZv5DIhhk+t97hlv9m3CF9X2Y=
MIME-Version: 1.0
Received: by 10.229.30.70 with SMTP id t6mr2533362qcc.169.1322040681203; Wed,
	23 Nov 2011 01:31:21 -0800 (PST)
Received: by 10.229.192.198 with HTTP; Wed, 23 Nov 2011 01:31:21 -0800 (PST)
In-Reply-To: <20171.51198.221057.507056@mariner.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1320055865.23193.45.camel@zakaz.uk.xensource.com>
	<CAPLaKK511W3q3YA+wFv=AJxqFQAFyaChRXuBCd_Sh=kMz6yQ8Q@mail.gmail.com>
	<20171.51198.221057.507056@mariner.uk.xensource.com>
Date: Wed, 23 Nov 2011 10:31:21 +0100
X-Google-Sender-Auth: KPcJQbQlZWmBUq0ulJp3NKaiTP0
Message-ID: <CAPLaKK6QsoZtpqitdOjeD6MgYhVB6k3cVQYbiaprdMo5ui3HyQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 00/13] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8yMiBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gSSdt
IGFmcmFpZCBJIGRvbid0IGtub3cuIMKgV2l0aCBteSB1cHN0cmVhbSBoYXQgb24sIGZvciBhcHBs
eWluZwo+IHBhdGNoZXMsIEkgaGF2ZSBhbiBhYnNvbHV0ZWx5IGhpZGVvdXMgc2NyaXB0LiDCoChC
ZWxvdyBidXQgZG9uJ3QgcmVhZAo+IGl0IGlmIHlvdSB3YW50IHRvIGtlZXAgeW91ciBsdW5jaC4p
IMKgV2l0aCBteSBjb250cmlidXRvciBoYXQgb24gSQo+IGFsbW9zdCBhbHdheXMgdXNlIGdpdC4K
ClRoYW5rcyBmb3IgdGhlIHNjcmlwdCwgSSB3aWxsIHRyeSB0byBpbXBvcnQgdGhpcyBzZXJpZXMg
bGF0ZXIgdGhpcwp3ZWVrIGlmIEkgY2FuIGdldCBteSBoYW5kcyBvbiBhbiB1bnVzZWQgdmlydHVh
bGl6YXRpb24gc2VydmVyIChyaWdodApub3cgYWxsIG15IGF2YWlsYWJsZSBzZXJ2ZXJzIGFyZSBi
dXN5KS4gU2hvdWxkbid0IHdlIGFncmVlIG9uIGhhdmluZwpvbmx5IG9uZSByZXBvc2l0b3J5IGZv
cm1hdD8gRWl0aGVyIGdpdCBvciBtZXJjdXJpYWwgaXMgZmluZSBmb3IgbWUsCmJ1dCBpdCB3aWxs
IGF2b2lkIHRoaXMga2luZCBvZiBzaXR1YXRpb25zLgoKUmVnYXJkcywgUm9nZXIuCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:32:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:32:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9Br-0002Sx-4h; Wed, 23 Nov 2011 09:32:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RT9Bo-0002Sp-Ou
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:32:25 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322040681!4605255!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 465 invoked from network); 23 Nov 2011 09:31:22 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:31:22 -0000
Received: by qyk31 with SMTP id 31so1279202qyk.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 01:31:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=kZoXYGohc2Sa+D0U/mXFvHiuI6d4uqT7kMrevza7QlM=;
	b=Uz1URLb8XjU2MNVxQCaIT0X7/CrCIlqnx0BY6ZDp5z1yqINLpywOVXbsxjLk8I98lO
	hqrcdMYtvB3kOwc9JJEk3NlwbtH9fddvWTb7OAuWL8QltgYNJXQR9We2qN2hpxF2oeL1
	4UHLykQVk7/bzZv5DIhhk+t97hlv9m3CF9X2Y=
MIME-Version: 1.0
Received: by 10.229.30.70 with SMTP id t6mr2533362qcc.169.1322040681203; Wed,
	23 Nov 2011 01:31:21 -0800 (PST)
Received: by 10.229.192.198 with HTTP; Wed, 23 Nov 2011 01:31:21 -0800 (PST)
In-Reply-To: <20171.51198.221057.507056@mariner.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1320055865.23193.45.camel@zakaz.uk.xensource.com>
	<CAPLaKK511W3q3YA+wFv=AJxqFQAFyaChRXuBCd_Sh=kMz6yQ8Q@mail.gmail.com>
	<20171.51198.221057.507056@mariner.uk.xensource.com>
Date: Wed, 23 Nov 2011 10:31:21 +0100
X-Google-Sender-Auth: KPcJQbQlZWmBUq0ulJp3NKaiTP0
Message-ID: <CAPLaKK6QsoZtpqitdOjeD6MgYhVB6k3cVQYbiaprdMo5ui3HyQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 00/13] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8yMiBJYW4gSmFja3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gSSdt
IGFmcmFpZCBJIGRvbid0IGtub3cuIMKgV2l0aCBteSB1cHN0cmVhbSBoYXQgb24sIGZvciBhcHBs
eWluZwo+IHBhdGNoZXMsIEkgaGF2ZSBhbiBhYnNvbHV0ZWx5IGhpZGVvdXMgc2NyaXB0LiDCoChC
ZWxvdyBidXQgZG9uJ3QgcmVhZAo+IGl0IGlmIHlvdSB3YW50IHRvIGtlZXAgeW91ciBsdW5jaC4p
IMKgV2l0aCBteSBjb250cmlidXRvciBoYXQgb24gSQo+IGFsbW9zdCBhbHdheXMgdXNlIGdpdC4K
ClRoYW5rcyBmb3IgdGhlIHNjcmlwdCwgSSB3aWxsIHRyeSB0byBpbXBvcnQgdGhpcyBzZXJpZXMg
bGF0ZXIgdGhpcwp3ZWVrIGlmIEkgY2FuIGdldCBteSBoYW5kcyBvbiBhbiB1bnVzZWQgdmlydHVh
bGl6YXRpb24gc2VydmVyIChyaWdodApub3cgYWxsIG15IGF2YWlsYWJsZSBzZXJ2ZXJzIGFyZSBi
dXN5KS4gU2hvdWxkbid0IHdlIGFncmVlIG9uIGhhdmluZwpvbmx5IG9uZSByZXBvc2l0b3J5IGZv
cm1hdD8gRWl0aGVyIGdpdCBvciBtZXJjdXJpYWwgaXMgZmluZSBmb3IgbWUsCmJ1dCBpdCB3aWxs
IGF2b2lkIHRoaXMga2luZCBvZiBzaXR1YXRpb25zLgoKUmVnYXJkcywgUm9nZXIuCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:40:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:40:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9JI-0002sM-JC; Wed, 23 Nov 2011 09:40:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RT9JG-0002rq-Ar
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:40:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322041176!2687214!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13704 invoked from network); 23 Nov 2011 09:39:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:39:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9081551"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 09:39:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 09:39:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 09:39:35 +0000
In-Reply-To: <1322039766.1005.0.camel@zakaz.uk.xensource.com>
References: <E1RT78r-0002z5-53@woking.xci-test.com>
	<1322039766.1005.0.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322041175.1005.8.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete build-i386
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 09:16 +0000, Ian Campbell wrote:
> On Wed, 2011-11-23 at 07:21 +0000, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job build-i386
> > test xen-build
> > 
> > Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> > 
> > *** Found and reproduced problem changeset ***
> > 
> >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
> >   Bug introduced:  4ecd3615e726
> >   Bug not present: 53bec838bb08
> > 
> > 
> >   changeset:   24184:4ecd3615e726
> >   tag:         tip
> >   user:        Ian Campbell <ian.campbell@citrix.com>
> >   date:        Tue Nov 22 17:24:51 2011 +0000
> >       
> >       tools: use system installed libaio by default.
> 
> I somehow didn't see this in my testing

Testing with a .config with CONFIG_SYSTEM_LIBAIO=n in it can't have
helped. Oops!

>  but it's pretty obvious that
> tools/blktap needs the same treatment as tools/blktap2. Patch is
> forthcoming.

8<------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322041076 0
# Node ID c6286bb841ea754fb30319aea6c3d663a06dce19
# Parent  f883f41eb18ec2259afd8a2be43c7d3f2278ce93
tools: use system libaio for blktap1 as well.

24184:4ecd3615e726 missed this because I was accidentally testing with a
.config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
without this. There were no other issues.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f883f41eb18e -r c6286bb841ea tools/blktap/drivers/Makefile
--- a/tools/blktap/drivers/Makefile	Wed Nov 23 09:20:52 2011 +0000
+++ b/tools/blktap/drivers/Makefile	Wed Nov 23 09:37:56 2011 +0000
@@ -3,7 +3,6 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 IBIN         = blktapctrl tapdisk
 QCOW_UTIL    = img2qcow qcow2raw qcow-create
-LIBAIO_DIR   = ../../libaio/src
 MEMSHR_DIR   = ../../memshr
 
 CFLAGS   += -Werror
@@ -11,7 +10,6 @@ CFLAGS   += -Wno-unused
 CFLAGS   += -I../lib
 CFLAGS   += $(CFLAGS_libxenctrl)
 CFLAGS   += $(CFLAGS_libxenstore)
-CFLAGS   += -I $(LIBAIO_DIR)
 CFLAGS   += -I $(MEMSHR_DIR)
 CFLAGS   += -D_GNU_SOURCE
 
@@ -29,8 +27,16 @@ CFLAGS += -DMEMSHR
 MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
 endif
 
+ifneq ($(CONFIG_SYSTEM_LIBAIO),y)
+LIBAIO_DIR   = ../../libaio/src
+CFLAGS      += -I $(LIBAIO_DIR)
+AIOLIBS     := $(LIBAIO_DIR)/libaio.a
+else
+AIOLIBS     := -laio
+endif
+
 LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm -lpthread
-LDLIBS_img := $(LIBAIO_DIR)/libaio.a $(CRYPT_LIB) -lpthread -lz
+LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) -lpthread -lz
 
 BLK-OBJS-y  := block-aio.o
 BLK-OBJS-y  += block-sync.o



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:40:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:40:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9JI-0002sM-JC; Wed, 23 Nov 2011 09:40:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RT9JG-0002rq-Ar
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:40:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322041176!2687214!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13704 invoked from network); 23 Nov 2011 09:39:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:39:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9081551"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 09:39:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 09:39:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 09:39:35 +0000
In-Reply-To: <1322039766.1005.0.camel@zakaz.uk.xensource.com>
References: <E1RT78r-0002z5-53@woking.xci-test.com>
	<1322039766.1005.0.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322041175.1005.8.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete build-i386
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 09:16 +0000, Ian Campbell wrote:
> On Wed, 2011-11-23 at 07:21 +0000, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job build-i386
> > test xen-build
> > 
> > Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> > 
> > *** Found and reproduced problem changeset ***
> > 
> >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
> >   Bug introduced:  4ecd3615e726
> >   Bug not present: 53bec838bb08
> > 
> > 
> >   changeset:   24184:4ecd3615e726
> >   tag:         tip
> >   user:        Ian Campbell <ian.campbell@citrix.com>
> >   date:        Tue Nov 22 17:24:51 2011 +0000
> >       
> >       tools: use system installed libaio by default.
> 
> I somehow didn't see this in my testing

Testing with a .config with CONFIG_SYSTEM_LIBAIO=n in it can't have
helped. Oops!

>  but it's pretty obvious that
> tools/blktap needs the same treatment as tools/blktap2. Patch is
> forthcoming.

8<------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322041076 0
# Node ID c6286bb841ea754fb30319aea6c3d663a06dce19
# Parent  f883f41eb18ec2259afd8a2be43c7d3f2278ce93
tools: use system libaio for blktap1 as well.

24184:4ecd3615e726 missed this because I was accidentally testing with a
.config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
without this. There were no other issues.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f883f41eb18e -r c6286bb841ea tools/blktap/drivers/Makefile
--- a/tools/blktap/drivers/Makefile	Wed Nov 23 09:20:52 2011 +0000
+++ b/tools/blktap/drivers/Makefile	Wed Nov 23 09:37:56 2011 +0000
@@ -3,7 +3,6 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 IBIN         = blktapctrl tapdisk
 QCOW_UTIL    = img2qcow qcow2raw qcow-create
-LIBAIO_DIR   = ../../libaio/src
 MEMSHR_DIR   = ../../memshr
 
 CFLAGS   += -Werror
@@ -11,7 +10,6 @@ CFLAGS   += -Wno-unused
 CFLAGS   += -I../lib
 CFLAGS   += $(CFLAGS_libxenctrl)
 CFLAGS   += $(CFLAGS_libxenstore)
-CFLAGS   += -I $(LIBAIO_DIR)
 CFLAGS   += -I $(MEMSHR_DIR)
 CFLAGS   += -D_GNU_SOURCE
 
@@ -29,8 +27,16 @@ CFLAGS += -DMEMSHR
 MEMSHRLIBS += $(MEMSHR_DIR)/libmemshr.a
 endif
 
+ifneq ($(CONFIG_SYSTEM_LIBAIO),y)
+LIBAIO_DIR   = ../../libaio/src
+CFLAGS      += -I $(LIBAIO_DIR)
+AIOLIBS     := $(LIBAIO_DIR)/libaio.a
+else
+AIOLIBS     := -laio
+endif
+
 LDLIBS_blktapctrl := $(MEMSHRLIBS) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) -L../lib -lblktap -lrt -lm -lpthread
-LDLIBS_img := $(LIBAIO_DIR)/libaio.a $(CRYPT_LIB) -lpthread -lz
+LDLIBS_img := $(AIOLIBS) $(CRYPT_LIB) -lpthread -lz
 
 BLK-OBJS-y  := block-aio.o
 BLK-OBJS-y  += block-sync.o



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:45:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9OX-00038I-Un; Wed, 23 Nov 2011 09:45:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RT9OV-000384-Tz
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:45:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322041501!5349505!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20533 invoked from network); 23 Nov 2011 09:45:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 09:45:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 09:45:00 +0000
Message-Id: <4ECCCEA902000078000628DE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 09:44:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>,"Keir Fraser" <keir@xen.org>
References: <4ECCC1970200007800062875@nat28.tlf.novell.com>
	<CAF266DF.3489F%keir@xen.org>
In-Reply-To: <CAF266DF.3489F%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
 ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.11.11 at 10:01, Keir Fraser <keir@xen.org> wrote:
> On 23/11/2011 08:49, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 22.11.11 at 22:13, Olaf Hering <olaf@aepfle.de> wrote:
>>> @@ -615,9 +620,12 @@ static inline struct domain *next_domain
>>>   /* VCPU affinity has changed: migrating to a new CPU. */
>>>  #define _VPF_migrating       3
>>>  #define VPF_migrating        (1UL<<_VPF_migrating)
>>> - /* VCPU is blocked on memory-event ring. */
>>> -#define _VPF_mem_event       4
>>> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
>>> + /* VCPU is blocked on mem_paging ring. */
>>> +#define _VPF_me_mem_paging   4
>>> +#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
>>> + /* VCPU is blocked on mem_access ring. */
>>> +#define _VPF_me_mem_access   5
>>> +#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)
>> 
>> Same here - the mem_ seems superfluous.
> 
> Mem_event-related flags in a more general grouping do require a mem_ prefix
> imo. The names need to stand on their own and still be descriptive.

But me_mem_ is still bogus - I thought the me_ stands for "mem event",
and then the subsequent mem_ is unnecessary.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:45:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9OX-00038I-Un; Wed, 23 Nov 2011 09:45:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RT9OV-000384-Tz
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:45:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322041501!5349505!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20533 invoked from network); 23 Nov 2011 09:45:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 09:45:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 09:45:00 +0000
Message-Id: <4ECCCEA902000078000628DE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 09:44:57 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>,"Keir Fraser" <keir@xen.org>
References: <4ECCC1970200007800062875@nat28.tlf.novell.com>
	<CAF266DF.3489F%keir@xen.org>
In-Reply-To: <CAF266DF.3489F%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
 ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.11.11 at 10:01, Keir Fraser <keir@xen.org> wrote:
> On 23/11/2011 08:49, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 22.11.11 at 22:13, Olaf Hering <olaf@aepfle.de> wrote:
>>> @@ -615,9 +620,12 @@ static inline struct domain *next_domain
>>>   /* VCPU affinity has changed: migrating to a new CPU. */
>>>  #define _VPF_migrating       3
>>>  #define VPF_migrating        (1UL<<_VPF_migrating)
>>> - /* VCPU is blocked on memory-event ring. */
>>> -#define _VPF_mem_event       4
>>> -#define VPF_mem_event        (1UL<<_VPF_mem_event)
>>> + /* VCPU is blocked on mem_paging ring. */
>>> +#define _VPF_me_mem_paging   4
>>> +#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
>>> + /* VCPU is blocked on mem_access ring. */
>>> +#define _VPF_me_mem_access   5
>>> +#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)
>> 
>> Same here - the mem_ seems superfluous.
> 
> Mem_event-related flags in a more general grouping do require a mem_ prefix
> imo. The names need to stand on their own and still be descriptive.

But me_mem_ is still bogus - I thought the me_ stands for "mem event",
and then the subsequent mem_ is unnecessary.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:46:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:46:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9Pd-0003BU-3M; Wed, 23 Nov 2011 09:46:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RT9Pb-0003B7-N7
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:46:39 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322041568!2676164!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24873 invoked from network); 23 Nov 2011 09:46:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315195200"; d="scan'208";a="19342499"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 04:46:07 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 04:46:07 -0500
MIME-Version: 1.0
X-Mercurial-Node: 3341e3e990568f459ae984cd9d2cac2d546eaa4e
Message-ID: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 23 Nov 2011 09:45:36 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322041530 0
# Node ID 3341e3e990568f459ae984cd9d2cac2d546eaa4e
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Prevent xl save from segfaulting when control/shutdown key is removed

To acknowledge the tools' setting of control/shutdown it is normal for PV drivers
to rm the key. This leads to libxl__xs_read() returning NULL and thus a subsequent
strcmp on the return value will cause a segfault.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r 3341e3e99056 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Nov 23 09:45:30 2011 +0000
@@ -444,6 +444,7 @@ static int libxl__domain_suspend_common_
             usleep(100000);
 
             state = libxl__xs_read(si->gc, XBT_NULL, path);
+            if (!state) state = "";
 
             watchdog--;
         }
@@ -463,6 +464,7 @@ static int libxl__domain_suspend_common_
             t = xs_transaction_start(ctx->xsh);
 
             state = libxl__xs_read(si->gc, t, path);
+            if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
                 libxl__xs_write(si->gc, t, path, "");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:46:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:46:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9Pd-0003BU-3M; Wed, 23 Nov 2011 09:46:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RT9Pb-0003B7-N7
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:46:39 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322041568!2676164!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24873 invoked from network); 23 Nov 2011 09:46:09 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315195200"; d="scan'208";a="19342499"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 04:46:07 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 04:46:07 -0500
MIME-Version: 1.0
X-Mercurial-Node: 3341e3e990568f459ae984cd9d2cac2d546eaa4e
Message-ID: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 23 Nov 2011 09:45:36 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322041530 0
# Node ID 3341e3e990568f459ae984cd9d2cac2d546eaa4e
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Prevent xl save from segfaulting when control/shutdown key is removed

To acknowledge the tools' setting of control/shutdown it is normal for PV drivers
to rm the key. This leads to libxl__xs_read() returning NULL and thus a subsequent
strcmp on the return value will cause a segfault.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r 3341e3e99056 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Nov 23 09:45:30 2011 +0000
@@ -444,6 +444,7 @@ static int libxl__domain_suspend_common_
             usleep(100000);
 
             state = libxl__xs_read(si->gc, XBT_NULL, path);
+            if (!state) state = "";
 
             watchdog--;
         }
@@ -463,6 +464,7 @@ static int libxl__domain_suspend_common_
             t = xs_transaction_start(ctx->xsh);
 
             state = libxl__xs_read(si->gc, t, path);
+            if (!state) state = "";
 
             if (!strcmp(state, "suspend"))
                 libxl__xs_write(si->gc, t, path, "");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:47:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9QK-0003Fh-3Q; Wed, 23 Nov 2011 09:47:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RT9QH-0003Ei-DD
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:47:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322041583!53861201!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2933 invoked from network); 23 Nov 2011 09:46:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9081726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 09:46: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, 23 Nov 2011 09:46:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 09:46:51 +0000
In-Reply-To: <20171.61030.71499.197458@mariner.uk.xensource.com>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322041611.1005.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jonathan Davies <Jonathan.Davies@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during	some
 hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 18:48 +0000, Ian Jackson wrote:
> Jonathan Davies writes ("[Xen-devel] [PATCH] [OCaml] Release the global lock during some hypercalls"):
> > Since libxc is re-entrant, there is no need for the OCaml bindings to prevent more than one thread from entering libxc concurrently.
> 
> Well, libxc is supposed to be re-entrant apart from certain calls,
> yes.

Which ones aren't? Either I'm grepping the wrong thing in xenctrl.h or
it is documented somewhere else (OK, I admit it, there's a third, more
likely, option...)

> 
> As the main user of the ocaml bindings is xapi, can you confirm that
> you've run this change through a good test of xapi (eg, the Citrix
> XenRT suite) ?
> 
> Thanks,
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:47:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9QK-0003Fh-3Q; Wed, 23 Nov 2011 09:47:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RT9QH-0003Ei-DD
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:47:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322041583!53861201!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2933 invoked from network); 23 Nov 2011 09:46:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9081726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 09:46: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, 23 Nov 2011 09:46:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 09:46:51 +0000
In-Reply-To: <20171.61030.71499.197458@mariner.uk.xensource.com>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322041611.1005.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jonathan Davies <Jonathan.Davies@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during	some
 hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-22 at 18:48 +0000, Ian Jackson wrote:
> Jonathan Davies writes ("[Xen-devel] [PATCH] [OCaml] Release the global lock during some hypercalls"):
> > Since libxc is re-entrant, there is no need for the OCaml bindings to prevent more than one thread from entering libxc concurrently.
> 
> Well, libxc is supposed to be re-entrant apart from certain calls,
> yes.

Which ones aren't? Either I'm grepping the wrong thing in xenctrl.h or
it is documented somewhere else (OK, I admit it, there's a third, more
likely, option...)

> 
> As the main user of the ocaml bindings is xapi, can you confirm that
> you've run this change through a good test of xapi (eg, the Citrix
> XenRT suite) ?
> 
> Thanks,
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:50:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9TI-0003Yg-TF; Wed, 23 Nov 2011 09:50:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RT9TH-0003YG-6G
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:50:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322041797!2681896!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26863 invoked from network); 23 Nov 2011 09:49:57 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:49:57 -0000
Received: by bkbzt12 with SMTP id zt12so1845009bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 01:49:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HDKO8YChFt0mV2s91dRNm2tWZzv4y3l2KQEO1eH9/HI=;
	b=s9KlG0MGLVEEJpht3iV+6+iWcGkUFpHzGG31voLKOhziOgTc6eIzH1XLUyWJpii7p1
	VFrre0ReEaLz7qLggjLDTThRfIEniWk3nuh8sSN1P3bZiWCd2lGqJbIDXsyylMorYiHN
	/42EILjEVLANVQwO6qqxRr/R4gWOFqygoAeVk=
Received: by 10.204.34.148 with SMTP id l20mr17796117bkd.55.1322041797216;
	Wed, 23 Nov 2011 01:49:57 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id cc2sm12363595bkb.8.2011.11.23.01.49.55
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 01:49:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 09:49:51 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF2723F.34A91%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
	ring is full
Thread-Index: AcypxT6NP6mORVscU0SwxgrsysvnHA==
In-Reply-To: <4ECCCEA902000078000628DE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
 ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 09:44, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> + /* VCPU is blocked on mem_paging ring. */
>>>> +#define _VPF_me_mem_paging   4
>>>> +#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
>>>> + /* VCPU is blocked on mem_access ring. */
>>>> +#define _VPF_me_mem_access   5
>>>> +#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)
>>> 
>>> Same here - the mem_ seems superfluous.
>> 
>> Mem_event-related flags in a more general grouping do require a mem_ prefix
>> imo. The names need to stand on their own and still be descriptive.
> 
> But me_mem_ is still bogus - I thought the me_ stands for "mem event",
> and then the subsequent mem_ is unnecessary.

I'd get rid of the me_ rather than the mem_. The me_ is too short to be
meaningful really.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 09:50:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 09:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9TI-0003Yg-TF; Wed, 23 Nov 2011 09:50:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RT9TH-0003YG-6G
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:50:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322041797!2681896!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26863 invoked from network); 23 Nov 2011 09:49:57 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:49:57 -0000
Received: by bkbzt12 with SMTP id zt12so1845009bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 01:49:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HDKO8YChFt0mV2s91dRNm2tWZzv4y3l2KQEO1eH9/HI=;
	b=s9KlG0MGLVEEJpht3iV+6+iWcGkUFpHzGG31voLKOhziOgTc6eIzH1XLUyWJpii7p1
	VFrre0ReEaLz7qLggjLDTThRfIEniWk3nuh8sSN1P3bZiWCd2lGqJbIDXsyylMorYiHN
	/42EILjEVLANVQwO6qqxRr/R4gWOFqygoAeVk=
Received: by 10.204.34.148 with SMTP id l20mr17796117bkd.55.1322041797216;
	Wed, 23 Nov 2011 01:49:57 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id cc2sm12363595bkb.8.2011.11.23.01.49.55
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 01:49:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 09:49:51 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF2723F.34A91%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
	ring is full
Thread-Index: AcypxT6NP6mORVscU0SwxgrsysvnHA==
In-Reply-To: <4ECCCEA902000078000628DE@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] RFC: mem_event: use wait queue when
 ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 09:44, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> + /* VCPU is blocked on mem_paging ring. */
>>>> +#define _VPF_me_mem_paging   4
>>>> +#define VPF_me_mem_paging    (1UL<<_VPF_me_mem_paging)
>>>> + /* VCPU is blocked on mem_access ring. */
>>>> +#define _VPF_me_mem_access   5
>>>> +#define VPF_me_mem_access    (1UL<<_VPF_me_mem_access)
>>> 
>>> Same here - the mem_ seems superfluous.
>> 
>> Mem_event-related flags in a more general grouping do require a mem_ prefix
>> imo. The names need to stand on their own and still be descriptive.
> 
> But me_mem_ is still bogus - I thought the me_ stands for "mem event",
> and then the subsequent mem_ is unnecessary.

I'd get rid of the me_ rather than the mem_. The me_ is too short to be
meaningful really.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:13:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9pO-0004ag-BB; Wed, 23 Nov 2011 10:13:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RT9pM-0004aU-83
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:13:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322043166!4645234!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19363 invoked from network); 23 Nov 2011 10:12:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 10:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9082489"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 10:12:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 10:12:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Wed, 23 Nov 2011 10:12:46 +0000
In-Reply-To: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322043166.1005.27.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 09:45 +0000, Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322041530 0
> # Node ID 3341e3e990568f459ae984cd9d2cac2d546eaa4e
> # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> Prevent xl save from segfaulting when control/shutdown key is removed
> 
> To acknowledge the tools' setting of control/shutdown it is normal for PV drivers
> to rm the key. This leads to libxl__xs_read() returning NULL and thus a subsequent
> strcmp on the return value will cause a segfault.

The Linux PV drivers actually write "" rather than removing the key
which is how this didn't get spotted already. We should be robust to PV
drivers which remove it as well.

At start of day .../control is created ro (to the guest)
whereas .../control/shutdown is created rw. Can you confirm that a
second operation still succeeds if the guest rm's the node on the first
action?

My concern is that while the first time the round the node will be rw
the second time round the write will actually re-create the node
(without setting the permissions) which might result in the node being
ro for the guest (xenstore perms confuse me, but I think new nodes
inherit the parent permissions).

That's assuming there's any chance of a second operation. I'm thinking
of a wedged reboot followed by an attempt to shutdown instead or
something like that. Perhaps in practice that wouldn't work anyway.

Apart form the above this change improves the robustness of the code so:

> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>



> 
> diff -r 0a0c02a61676 -r 3341e3e99056 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxl/libxl_dom.c	Wed Nov 23 09:45:30 2011 +0000
> @@ -444,6 +444,7 @@ static int libxl__domain_suspend_common_
>              usleep(100000);
>  
>              state = libxl__xs_read(si->gc, XBT_NULL, path);
> +            if (!state) state = "";
>  
>              watchdog--;
>          }
> @@ -463,6 +464,7 @@ static int libxl__domain_suspend_common_
>              t = xs_transaction_start(ctx->xsh);
>  
>              state = libxl__xs_read(si->gc, t, path);
> +            if (!state) state = "";
>  
>              if (!strcmp(state, "suspend"))
>                  libxl__xs_write(si->gc, t, path, "");
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:13:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9pO-0004ag-BB; Wed, 23 Nov 2011 10:13:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RT9pM-0004aU-83
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:13:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322043166!4645234!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19363 invoked from network); 23 Nov 2011 10:12:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 10:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9082489"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 10:12:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 10:12:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Wed, 23 Nov 2011 10:12:46 +0000
In-Reply-To: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322043166.1005.27.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 09:45 +0000, Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322041530 0
> # Node ID 3341e3e990568f459ae984cd9d2cac2d546eaa4e
> # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> Prevent xl save from segfaulting when control/shutdown key is removed
> 
> To acknowledge the tools' setting of control/shutdown it is normal for PV drivers
> to rm the key. This leads to libxl__xs_read() returning NULL and thus a subsequent
> strcmp on the return value will cause a segfault.

The Linux PV drivers actually write "" rather than removing the key
which is how this didn't get spotted already. We should be robust to PV
drivers which remove it as well.

At start of day .../control is created ro (to the guest)
whereas .../control/shutdown is created rw. Can you confirm that a
second operation still succeeds if the guest rm's the node on the first
action?

My concern is that while the first time the round the node will be rw
the second time round the write will actually re-create the node
(without setting the permissions) which might result in the node being
ro for the guest (xenstore perms confuse me, but I think new nodes
inherit the parent permissions).

That's assuming there's any chance of a second operation. I'm thinking
of a wedged reboot followed by an attempt to shutdown instead or
something like that. Perhaps in practice that wouldn't work anyway.

Apart form the above this change improves the robustness of the code so:

> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>



> 
> diff -r 0a0c02a61676 -r 3341e3e99056 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxl/libxl_dom.c	Wed Nov 23 09:45:30 2011 +0000
> @@ -444,6 +444,7 @@ static int libxl__domain_suspend_common_
>              usleep(100000);
>  
>              state = libxl__xs_read(si->gc, XBT_NULL, path);
> +            if (!state) state = "";
>  
>              watchdog--;
>          }
> @@ -463,6 +464,7 @@ static int libxl__domain_suspend_common_
>              t = xs_transaction_start(ctx->xsh);
>  
>              state = libxl__xs_read(si->gc, t, path);
> +            if (!state) state = "";
>  
>              if (!strcmp(state, "suspend"))
>                  libxl__xs_write(si->gc, t, path, "");
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:24:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:24:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9zY-0004vK-Rn; Wed, 23 Nov 2011 10:23:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RT9zW-0004vE-Gl
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:23:46 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322043796!4649002!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20993 invoked from network); 23 Nov 2011 10:23:16 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 10:23:16 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73375296; Wed, 23 Nov 2011 11:23:16 +0100
Message-ID: <1322043789.24897.23.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Wed, 23 Nov 2011 11:23:09 +0100
In-Reply-To: <4ECCBB0B.8020703@ts.fujitsu.com>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
	<4ECCBB0B.8020703@ts.fujitsu.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3209019553064371002=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3209019553064371002==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-CsyPtzMontgcQq5Ed5VA"


--=-CsyPtzMontgcQq5Ed5VA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-11-23 at 10:21 +0100, Juergen Gross wrote:
> Hi Dario,
>=20
Hi,

> > Could that be my fault? Can I do anything else to help you debug/fix
> > this?
>=20
> Are you sure the patches applied completely? libxl_sched_credit2_domain_g=
et()
> is added in the third patch to libxl.c, the usage in xl_cmdimpl.c is in t=
he
> same patch. I tested it on my box and all worked fine.
>=20
I double checked that, but I guess so:

$ grep libxl_sched_credit2_domain_get * -R
Binary file dist/install/usr/sbin/xl matches
Binary file dist/install/usr/lib64/libxenlight.so.2.0.0 matches
Binary file dist/install/usr/lib64/libxenlight.so.2.0 matches
Binary file dist/install/usr/lib64/libxenlight.a matches
Binary file dist/install/usr/lib64/libxenlight.so matches
dist/install/usr/include/libxl.h:int libxl_sched_credit2_domain_get(libxl_c=
tx *ctx, uint32_t domid,
Binary file tools/libxl/xl_cmdimpl.o matches
tools/libxl/xl_cmdimpl.c:    rc =3D libxl_sched_credit2_domain_get(ctx, dom=
id, scinfo);
tools/libxl/xl_cmdimpl.c:        fprintf(stderr, "libxl_sched_credit2_domai=
n_get failed.\n");
Binary file tools/libxl/libxenlight.so.2.0.0 matches
Binary file tools/libxl/xl matches
Binary file tools/libxl/libxenlight.so.2.0 matches
Binary file tools/libxl/libxl.o matches
Binary file tools/libxl/libxenlight.a matches
Binary file tools/libxl/libxenlight.so matches
tools/libxl/libxl.c:int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint=
32_t domid, libxl_sched_credit2 *scinfo)
tools/libxl/xl_cmdimpl.c.orig:    rc =3D libxl_sched_credit2_domain_get(ctx=
, domid, scinfo);
tools/libxl/xl_cmdimpl.c.orig:        fprintf(stderr, "libxl_sched_credit2_=
domain_get failed.\n");
tools/libxl/libxl.h:int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint=
32_t domid,

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-CsyPtzMontgcQq5Ed5VA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7MyY0ACgkQk4XaBE3IOsSCuwCggKUjuUFogmy54r8PmGneHswZ
AeAAnjS7y1/4wQntUINhQcJv07/7HVna
=eswE
-----END PGP SIGNATURE-----

--=-CsyPtzMontgcQq5Ed5VA--



--===============3209019553064371002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3209019553064371002==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:24:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:24:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RT9zY-0004vK-Rn; Wed, 23 Nov 2011 10:23:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RT9zW-0004vE-Gl
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:23:46 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322043796!4649002!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20993 invoked from network); 23 Nov 2011 10:23:16 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 10:23:16 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73375296; Wed, 23 Nov 2011 11:23:16 +0100
Message-ID: <1322043789.24897.23.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Wed, 23 Nov 2011 11:23:09 +0100
In-Reply-To: <4ECCBB0B.8020703@ts.fujitsu.com>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
	<4ECCBB0B.8020703@ts.fujitsu.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3209019553064371002=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3209019553064371002==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-CsyPtzMontgcQq5Ed5VA"


--=-CsyPtzMontgcQq5Ed5VA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-11-23 at 10:21 +0100, Juergen Gross wrote:
> Hi Dario,
>=20
Hi,

> > Could that be my fault? Can I do anything else to help you debug/fix
> > this?
>=20
> Are you sure the patches applied completely? libxl_sched_credit2_domain_g=
et()
> is added in the third patch to libxl.c, the usage in xl_cmdimpl.c is in t=
he
> same patch. I tested it on my box and all worked fine.
>=20
I double checked that, but I guess so:

$ grep libxl_sched_credit2_domain_get * -R
Binary file dist/install/usr/sbin/xl matches
Binary file dist/install/usr/lib64/libxenlight.so.2.0.0 matches
Binary file dist/install/usr/lib64/libxenlight.so.2.0 matches
Binary file dist/install/usr/lib64/libxenlight.a matches
Binary file dist/install/usr/lib64/libxenlight.so matches
dist/install/usr/include/libxl.h:int libxl_sched_credit2_domain_get(libxl_c=
tx *ctx, uint32_t domid,
Binary file tools/libxl/xl_cmdimpl.o matches
tools/libxl/xl_cmdimpl.c:    rc =3D libxl_sched_credit2_domain_get(ctx, dom=
id, scinfo);
tools/libxl/xl_cmdimpl.c:        fprintf(stderr, "libxl_sched_credit2_domai=
n_get failed.\n");
Binary file tools/libxl/libxenlight.so.2.0.0 matches
Binary file tools/libxl/xl matches
Binary file tools/libxl/libxenlight.so.2.0 matches
Binary file tools/libxl/libxl.o matches
Binary file tools/libxl/libxenlight.a matches
Binary file tools/libxl/libxenlight.so matches
tools/libxl/libxl.c:int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint=
32_t domid, libxl_sched_credit2 *scinfo)
tools/libxl/xl_cmdimpl.c.orig:    rc =3D libxl_sched_credit2_domain_get(ctx=
, domid, scinfo);
tools/libxl/xl_cmdimpl.c.orig:        fprintf(stderr, "libxl_sched_credit2_=
domain_get failed.\n");
tools/libxl/libxl.h:int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint=
32_t domid,

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-CsyPtzMontgcQq5Ed5VA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7MyY0ACgkQk4XaBE3IOsSCuwCggKUjuUFogmy54r8PmGneHswZ
AeAAnjS7y1/4wQntUINhQcJv07/7HVna
=eswE
-----END PGP SIGNATURE-----

--=-CsyPtzMontgcQq5Ed5VA--



--===============3209019553064371002==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3209019553064371002==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:25:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:25:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTA0q-0004yO-CX; Wed, 23 Nov 2011 10:25:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTA0o-0004xw-Uk
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:25:07 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322043876!5366586!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23474 invoked from network); 23 Nov 2011 10:24:37 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-21.messagelabs.com with SMTP;
	23 Nov 2011 10:24:37 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73375309; Wed, 23 Nov 2011 11:24:36 +0100
Message-ID: <1322043870.24897.25.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 11:24:30 +0100
In-Reply-To: <1322040258.1005.1.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
	<1322040258.1005.1.camel@zakaz.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2211718373742174491=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2211718373742174491==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-KNK78e6C8pWTVepuTDYG"


--=-KNK78e6C8pWTVepuTDYG
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-11-23 at 09:24 +0000, Ian Campbell wrote:
> > # xl sched-credit2
> > Cpupool Pool-0:
> > Name                                ID Weight
> > xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_doma=
in_get
>=20
> Is there a chance you are picking up an older version of libxl from
> somewhere?
>=20
More than once... That should be the culprit for me too, but I'm still
trying to figure out how... :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-KNK78e6C8pWTVepuTDYG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7Myd4ACgkQk4XaBE3IOsRnZACeKBsjaWBYrNtJdaExQIt+MnWk
74wAmwYIp3Gp63WVzxJg4gBraJI8gaCq
=W9ot
-----END PGP SIGNATURE-----

--=-KNK78e6C8pWTVepuTDYG--



--===============2211718373742174491==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2211718373742174491==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:25:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:25:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTA0q-0004yO-CX; Wed, 23 Nov 2011 10:25:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTA0o-0004xw-Uk
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:25:07 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322043876!5366586!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23474 invoked from network); 23 Nov 2011 10:24:37 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-21.messagelabs.com with SMTP;
	23 Nov 2011 10:24:37 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73375309; Wed, 23 Nov 2011 11:24:36 +0100
Message-ID: <1322043870.24897.25.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 11:24:30 +0100
In-Reply-To: <1322040258.1005.1.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
	<1322040258.1005.1.camel@zakaz.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2211718373742174491=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2211718373742174491==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-KNK78e6C8pWTVepuTDYG"


--=-KNK78e6C8pWTVepuTDYG
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-11-23 at 09:24 +0000, Ian Campbell wrote:
> > # xl sched-credit2
> > Cpupool Pool-0:
> > Name                                ID Weight
> > xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_doma=
in_get
>=20
> Is there a chance you are picking up an older version of libxl from
> somewhere?
>=20
More than once... That should be the culprit for me too, but I'm still
trying to figure out how... :-)

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-KNK78e6C8pWTVepuTDYG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7Myd4ACgkQk4XaBE3IOsRnZACeKBsjaWBYrNtJdaExQIt+MnWk
74wAmwYIp3Gp63WVzxJg4gBraJI8gaCq
=W9ot
-----END PGP SIGNATURE-----

--=-KNK78e6C8pWTVepuTDYG--



--===============2211718373742174491==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2211718373742174491==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAEt-0005WV-1u; Wed, 23 Nov 2011 10:39:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RTAEs-0005WH-CL
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:39:38 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322044719!53871134!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23778 invoked from network); 23 Nov 2011 10:38:39 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 10:38:39 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pANAcvdt027483
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 05:38:57 -0500
Received: from localhost ([10.3.113.10])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pANAcrQi032220; Wed, 23 Nov 2011 05:38:55 -0500
Date: Wed, 23 Nov 2011 16:08:52 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111123103852.GG16665@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Thu) 17 Nov 2011 [10:57:37], Miche Baker-Harvey wrote:
> Rusty, Michael, Stephen, et al,
> =

> Thanks for your comments on these patches.
> =

> For what I'm trying to do, all three patches are necessary, but maybe
> I'm going about it the wrong way. Your input would be appreciated.
> I'm in no way claiming that these patches are "right", just that it's
> working for me, and that what's in the current pool is not.
> =

> What I'm trying to do is:
> On X86,
> under KVM,
> start a virtio console device,
> with multiple ports on the device,
> at least one of which is also a console (as well as ttyS0).
> =

> (Eventually, we want to be able to add virtio console ports on the
> fly, and to have multiple virtio console ports be consoles.)

Are you using kvm-tool to do this?  QEMU can already hot-plug ports
and virtio-console (virtio-serial) devices.

> When all three of the patches are in place, this works great. (By
> great, I mean that getty's start up on all of ttyS0, hvc0 and hvc1,
> and console output goes to ttyS0 and to hvc0.
> "who" shows three users: =A0ttyS0, hvc0, and hvc1.
> "cat /proc/consoles" shows both ttyS0 and hvc0.
> I can use all three getty's, and console output really does appear on
> both the consoles.
> =

> Based on Rusty's comments, I tried removing each of the patches
> individually. Here's what happens today. I've seen other failure modes
> depending on what precisely I'm passing the guest.
> There's three patches:
> 1/3 "fix locking of vtermno"
> 2/3 "enforce one-time initialization with hvc_init
> "3/3 "use separate struct console * for each console"
> =

> If I remove the "fix locking of vtermno", I only get one virtio
> console terminal. =A0"who" shows the ttyS0 and the hvc0, and I can log
> into the gettys on both. I don't get the second virtio console getty.
> Interestingly, hvc0 shows up in /proc/consoles twice, and in fact the
> console output is dumped twice to hvc0 (as you'd expect from looking
> at printk.c, each line appears twice, followed by the next line.)

I don't really understand why.  "fix locking of vtermno" adds locks in
init_port_console(), which is called from add_port(), which should be
serialised due to port additions being on work items on the same
workqueue.  I don't see a race here.

> If I remove the "enforce one-time initialization with hvc_init" patch,
> which makes sure only a single thread is doing the hvc_init, and gates
> anyone from continuing until it has completed, I get different
> failures, including hangs, and dereferences of NULL pointers.
> =

> If I remove the "use separate struct console * for each console"patch,
> what I'm seeing now is that while all of ttyS0, hvc0, and hvc1 are
> present with gettys running on them, of the three, only ttyS0 is a
> console.

I don't see any difference in my testing with and without these
patches.

This is how I tested with qemu:

./x86_64-softmmu/qemu-system-x86_64 -m 512 -smp 2 -chardev
socket,path=3D/tmp/foo,server,nowait,id=3Dfoo -chardev
socket,path=3D/tmp/bar,server,nowait,id=3Dbar -device virtio-serial
-device virtconsole,chardev=3Dfoo,nr=3D4 -device
virtconsole,chardev=3Dbar,nr=3D3 -net none  -kernel
/home/amit/src/linux/arch/x86/boot/bzImage -append 'root=3D/dev/sda1
console=3Dtty0 console=3DttyS0' -initrd /tmp/initramfs.img
/guests/f14-nolvm.qcow2 -enable-kvm -snapshot

With this setup, with and without patches, I can spawn two consoles
via:

/sbin/agetty /dev/hvc0 9600 vt100
/sbin/agetty /dev/hvc1 9600 vt100

(Strange thing is, the second one gives a 'password incorrect' error
on login attempts, while the first one logs in fine.  I do remember
testing multiple consoles just fine a year and a half back, so no idea
why this isn't behaving as expected -- but it mostly looks like a
userspace issue rather than kernel one.)

As mentioned earlier, I've not looked at the hvc code, but given my
testing results, I'd like to first understand what you're seeing and
what your environment is.

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAEt-0005WV-1u; Wed, 23 Nov 2011 10:39:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RTAEs-0005WH-CL
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:39:38 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322044719!53871134!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23778 invoked from network); 23 Nov 2011 10:38:39 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 10:38:39 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pANAcvdt027483
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 05:38:57 -0500
Received: from localhost ([10.3.113.10])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pANAcrQi032220; Wed, 23 Nov 2011 05:38:55 -0500
Date: Wed, 23 Nov 2011 16:08:52 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111123103852.GG16665@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Thu) 17 Nov 2011 [10:57:37], Miche Baker-Harvey wrote:
> Rusty, Michael, Stephen, et al,
> =

> Thanks for your comments on these patches.
> =

> For what I'm trying to do, all three patches are necessary, but maybe
> I'm going about it the wrong way. Your input would be appreciated.
> I'm in no way claiming that these patches are "right", just that it's
> working for me, and that what's in the current pool is not.
> =

> What I'm trying to do is:
> On X86,
> under KVM,
> start a virtio console device,
> with multiple ports on the device,
> at least one of which is also a console (as well as ttyS0).
> =

> (Eventually, we want to be able to add virtio console ports on the
> fly, and to have multiple virtio console ports be consoles.)

Are you using kvm-tool to do this?  QEMU can already hot-plug ports
and virtio-console (virtio-serial) devices.

> When all three of the patches are in place, this works great. (By
> great, I mean that getty's start up on all of ttyS0, hvc0 and hvc1,
> and console output goes to ttyS0 and to hvc0.
> "who" shows three users: =A0ttyS0, hvc0, and hvc1.
> "cat /proc/consoles" shows both ttyS0 and hvc0.
> I can use all three getty's, and console output really does appear on
> both the consoles.
> =

> Based on Rusty's comments, I tried removing each of the patches
> individually. Here's what happens today. I've seen other failure modes
> depending on what precisely I'm passing the guest.
> There's three patches:
> 1/3 "fix locking of vtermno"
> 2/3 "enforce one-time initialization with hvc_init
> "3/3 "use separate struct console * for each console"
> =

> If I remove the "fix locking of vtermno", I only get one virtio
> console terminal. =A0"who" shows the ttyS0 and the hvc0, and I can log
> into the gettys on both. I don't get the second virtio console getty.
> Interestingly, hvc0 shows up in /proc/consoles twice, and in fact the
> console output is dumped twice to hvc0 (as you'd expect from looking
> at printk.c, each line appears twice, followed by the next line.)

I don't really understand why.  "fix locking of vtermno" adds locks in
init_port_console(), which is called from add_port(), which should be
serialised due to port additions being on work items on the same
workqueue.  I don't see a race here.

> If I remove the "enforce one-time initialization with hvc_init" patch,
> which makes sure only a single thread is doing the hvc_init, and gates
> anyone from continuing until it has completed, I get different
> failures, including hangs, and dereferences of NULL pointers.
> =

> If I remove the "use separate struct console * for each console"patch,
> what I'm seeing now is that while all of ttyS0, hvc0, and hvc1 are
> present with gettys running on them, of the three, only ttyS0 is a
> console.

I don't see any difference in my testing with and without these
patches.

This is how I tested with qemu:

./x86_64-softmmu/qemu-system-x86_64 -m 512 -smp 2 -chardev
socket,path=3D/tmp/foo,server,nowait,id=3Dfoo -chardev
socket,path=3D/tmp/bar,server,nowait,id=3Dbar -device virtio-serial
-device virtconsole,chardev=3Dfoo,nr=3D4 -device
virtconsole,chardev=3Dbar,nr=3D3 -net none  -kernel
/home/amit/src/linux/arch/x86/boot/bzImage -append 'root=3D/dev/sda1
console=3Dtty0 console=3DttyS0' -initrd /tmp/initramfs.img
/guests/f14-nolvm.qcow2 -enable-kvm -snapshot

With this setup, with and without patches, I can spawn two consoles
via:

/sbin/agetty /dev/hvc0 9600 vt100
/sbin/agetty /dev/hvc1 9600 vt100

(Strange thing is, the second one gives a 'password incorrect' error
on login attempts, while the first one logs in fine.  I do remember
testing multiple consoles just fine a year and a half back, so no idea
why this isn't behaving as expected -- but it mostly looks like a
userspace issue rather than kernel one.)

As mentioned earlier, I've not looked at the hvc code, but given my
testing results, I'd like to first understand what you're seeing and
what your environment is.

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:46:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:46:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTALV-0005kn-1O; Wed, 23 Nov 2011 10:46:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <spri1987@foxmail.com>) id 1RTALT-0005kS-AW
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:46:27 +0000
X-Env-Sender: spri1987@foxmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322045154!5372720!1
X-Originating-IP: [64.71.138.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8259 invoked from network); 23 Nov 2011 10:45:54 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-15.tower-21.messagelabs.com with SMTP;
	23 Nov 2011 10:45:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1322045153; bh=w5pBKB2WQ5hZl/+IvB++eSfN5ZWMBlbfqB4PtSWatxs=;
	h=X-QQ-SSF:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:X-QQ-STYLE:
	X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer:X-QQ-ESMTPACCOUNT;
	b=J2qX89K194AFZpXqZj7dMHG6OUBUPjSSAJGNR64dz16OR15UMlqZPrf759WqTaO6V
	pR1Qqwwggs4WcWwZCmAJzQf564ZJNBqG/r7/KYs4NhMuVTldBztEurKHLo7qCbb
X-QQ-SSF: 00000000000000F0000000000000000
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 211.69.71.130
X-QQ-STYLE: 
X-QQ-mid: webmail215t1322045148t7955861
From: "=?gbk?B?zfXHvw==?=" <qw.hust@gmail.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Wed, 23 Nov 2011 18:45:48 +0800
X-Priority: 3
Message-ID: <tencent_554A54CA09C7312770B7D8F7@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ESMTPACCOUNT: qw.hust@gmail.com
Subject: [Xen-devel] how to unplug a physical cpu?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0637803935250236498=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============0637803935250236498==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4ECCCEDC_086E7F68_64F36947"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4ECCCEDC_086E7F68_64F36947
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

aSB0cmllZCB0aGUgY29tbWFuZCAiZWNobyAwID4gL3N5cy9kZXZpY2VzL3N5c3RlbS9jcHUv
Y3B1MS9vbmxpbmUiLA0KIGJ1dCBhZnRlciB0aGF0IHRoZSBjb25zb2xlIHdhcyBoYWx0LCBh
bmQgc29tZXRpbWVzIHN5c3RlbSB3YXMgaGFsdC4NCiBubyBtZXNzYWdlIGxlZnQgaW4gInht
IGRtZXNnIiAiZG1lc2ciICIvdmFyL2xvZy94ZW4veGVuLWhvdHBsdWcubG9nIg0KICANCiB4
ZW4gdmVyc2lvbiBpIHVzZWQgaXMgNC4wLjEtcmMyLCB0aGUgZG9tVSBrZXJuZWwgaXMgeGVu
aWZpZWQgbGludXgtMi42LjMxLjgNCiAgDQogYW5kIGFsc28gaSBkaWQgYW4gZXhwZXJpbWVu
dCB3aXRob3V0IHhlbiBvbiBsaW51eC0yLjYuMzEuOCh0aGUgY29uZmlnIGlzIGp1c3Qgd2l0
aG91dCB4ZW4gb3B0aW9ucyksIHRoZSBjb21tYW5kIGFib3ZlIGNhbiB3b3JrDQogIA0KIGhv
dyBjYW4gaSB1bnBsdWcgYSBwaHlzaWNhbCBjcHUgb24geGVuPyBpcyB0aGF0IG5vdCBzdXBw
b3J0ZWQgYnkgeGVuIHlldD8NCiAgDQogaSdtIGEgbmV3ZXIgdG8gdGhpcyBmaWVsZCwgbWF5
YmUganVzdCBhIHNpbXBsZSBxdWVzdGlvbiwgcGxlYXNlIGhlbHANCiAgDQogIC0tLS0tLS0t
LS0tLS0tLS0tLQ0KIHFpYW5nd2FuZw0KS2V5IExhYm9yYXRvcnkgb2YgU2VydmljZSBDb21w
dXRpbmcgVGVjaG5vbG9neSBhbmQgU3lzdGVtDQpLZXkgTGFib3JhdG9yeSBvZiBDbHVzdGVy
IGFuZCBHcmlkIENvbXB1dGluZyBTY2hvb2wgb2YgQ29tcHV0ZXIgU2NpZW5jZSBhbmQgVGVj
aG5vbG9neQ0KSHVhemhvbmcgVW5pdmVyc2l0eSBvZiBTY2llbmNlIGFuZCBUZWNobm9sb2d5
DQpXdWhhbiwgNDMwMDc0LCBQLlIuIENoaW5hIA0KDQpFLW1haWw6cXcuaHVzdEBnbWFpbC5j
b20=

------=_NextPart_4ECCCEDC_086E7F68_64F36947
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6y87M5Ttmb250LXNpemU6bWVkaXVtOzsiPjxESVY+
aSB0cmllZCB0aGUgY29tbWFuZCAiZWNobyAwICZndDsgL3N5cy9kZXZpY2VzL3N5c3RlbS9j
cHUvY3B1MS9vbmxpbmUiLDwvRElWPg0KPERJVj5idXQgYWZ0ZXImbmJzcDt0aGF0IHRoZSBj
b25zb2xlIHdhcyBoYWx0LCBhbmQgc29tZXRpbWVzIHN5c3RlbSB3YXMgaGFsdC48L0RJVj4N
CjxESVY+bm8gbWVzc2FnZSBsZWZ0IGluICJ4bSBkbWVzZyImbmJzcDsiZG1lc2ciICIvdmFy
L2xvZy94ZW4veGVuLWhvdHBsdWcubG9nIjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE
SVY+eGVuIHZlcnNpb24gaSB1c2VkIGlzIDQuMC4xLXJjMiwgdGhlIGRvbVUga2VybmVsIGlz
IHhlbmlmaWVkIGxpbnV4LTIuNi4zMS44PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ
Vj5hbmQgYWxzbyBpIGRpZCBhbiBleHBlcmltZW50IHdpdGhvdXQgeGVuIG9uIGxpbnV4LTIu
Ni4zMS44KHRoZSBjb25maWcgaXMganVzdCB3aXRob3V0IHhlbiBvcHRpb25zKSwgdGhlIGNv
bW1hbmQgYWJvdmUgY2FuIHdvcms8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmhv
dyBjYW4gaSB1bnBsdWcgYSBwaHlzaWNhbCBjcHUgb24geGVuPyBpcyB0aGF0IG5vdCZuYnNw
O3N1cHBvcnRlZCBieSB4ZW4geWV0PzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+
aSdtIGEgbmV3ZXImbmJzcDt0byB0aGlzIGZpZWxkLCBtYXliZSBqdXN0IGEgc2ltcGxlIHF1
ZXN0aW9uLCBwbGVhc2UgaGVscDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PHNp
Z24gc2lnbmlkPSIyIj4NCjxESVYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCBOYXJyb3c7
IENPTE9SOiAjOTA5MDkwOyBGT05ULVNJWkU6IDEycHgiPi0tLS0tLS0tLS0tLS0tLS0tLTwv
RElWPg0KPERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiAjMDAwOyBG
T05ULVNJWkU6IDE0cHgiPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+cWlhbmd3
YW5nPC9TUEFOPjxCUj5LZXkgTGFib3JhdG9yeSBvZiBTZXJ2aWNlIENvbXB1dGluZyBUZWNo
bm9sb2d5IGFuZCBTeXN0ZW08QlI+S2V5IExhYm9yYXRvcnkgb2YgQ2x1c3RlciBhbmQgR3Jp
ZCBDb21wdXRpbmcgU2Nob29sIG9mIENvbXB1dGVyIFNjaWVuY2UgYW5kIFRlY2hub2xvZ3k8
QlI+SHVhemhvbmcgVW5pdmVyczxGT05UIHNpemU9MyBmYWNlPcvOzOU+PEZPTlQgc2l6ZT0y
IGZhY2U9y87M5T48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9MyBmYWNlPcvOzOU+PFNQQU4+
aXR5IG9mIFNjaWVuY2UgYW5kIFRlY2hub2xvZ3k8QlI+V3VoYW4sIDQzMDA3NCwgUC5SLiBD
aGluYSA8QlI+PEJSPkUtbWFpbDpxdy5odXN0QGdtYWlsLmNvbTwvU1BBTj48L0ZPTlQ+PC9G
T05UPjwvRk9OVD48QlI+PC9ESVY+PC9zaWduPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj48
L2Rpdj4=

------=_NextPart_4ECCCEDC_086E7F68_64F36947--



--===============0637803935250236498==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0637803935250236498==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:46:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:46:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTALV-0005kn-1O; Wed, 23 Nov 2011 10:46:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <spri1987@foxmail.com>) id 1RTALT-0005kS-AW
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:46:27 +0000
X-Env-Sender: spri1987@foxmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322045154!5372720!1
X-Originating-IP: [64.71.138.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8259 invoked from network); 23 Nov 2011 10:45:54 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-15.tower-21.messagelabs.com with SMTP;
	23 Nov 2011 10:45:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1322045153; bh=w5pBKB2WQ5hZl/+IvB++eSfN5ZWMBlbfqB4PtSWatxs=;
	h=X-QQ-SSF:X-QQ-BUSINESS-ORIGIN:X-Originating-IP:X-QQ-STYLE:
	X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:
	Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME:
	X-Mailer:X-QQ-Mailer:X-QQ-ESMTPACCOUNT;
	b=J2qX89K194AFZpXqZj7dMHG6OUBUPjSSAJGNR64dz16OR15UMlqZPrf759WqTaO6V
	pR1Qqwwggs4WcWwZCmAJzQf564ZJNBqG/r7/KYs4NhMuVTldBztEurKHLo7qCbb
X-QQ-SSF: 00000000000000F0000000000000000
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 211.69.71.130
X-QQ-STYLE: 
X-QQ-mid: webmail215t1322045148t7955861
From: "=?gbk?B?zfXHvw==?=" <qw.hust@gmail.com>
To: "=?gbk?B?eGVuLWRldmVs?=" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Date: Wed, 23 Nov 2011 18:45:48 +0800
X-Priority: 3
Message-ID: <tencent_554A54CA09C7312770B7D8F7@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ESMTPACCOUNT: qw.hust@gmail.com
Subject: [Xen-devel] how to unplug a physical cpu?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0637803935250236498=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============0637803935250236498==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4ECCCEDC_086E7F68_64F36947"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4ECCCEDC_086E7F68_64F36947
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

aSB0cmllZCB0aGUgY29tbWFuZCAiZWNobyAwID4gL3N5cy9kZXZpY2VzL3N5c3RlbS9jcHUv
Y3B1MS9vbmxpbmUiLA0KIGJ1dCBhZnRlciB0aGF0IHRoZSBjb25zb2xlIHdhcyBoYWx0LCBh
bmQgc29tZXRpbWVzIHN5c3RlbSB3YXMgaGFsdC4NCiBubyBtZXNzYWdlIGxlZnQgaW4gInht
IGRtZXNnIiAiZG1lc2ciICIvdmFyL2xvZy94ZW4veGVuLWhvdHBsdWcubG9nIg0KICANCiB4
ZW4gdmVyc2lvbiBpIHVzZWQgaXMgNC4wLjEtcmMyLCB0aGUgZG9tVSBrZXJuZWwgaXMgeGVu
aWZpZWQgbGludXgtMi42LjMxLjgNCiAgDQogYW5kIGFsc28gaSBkaWQgYW4gZXhwZXJpbWVu
dCB3aXRob3V0IHhlbiBvbiBsaW51eC0yLjYuMzEuOCh0aGUgY29uZmlnIGlzIGp1c3Qgd2l0
aG91dCB4ZW4gb3B0aW9ucyksIHRoZSBjb21tYW5kIGFib3ZlIGNhbiB3b3JrDQogIA0KIGhv
dyBjYW4gaSB1bnBsdWcgYSBwaHlzaWNhbCBjcHUgb24geGVuPyBpcyB0aGF0IG5vdCBzdXBw
b3J0ZWQgYnkgeGVuIHlldD8NCiAgDQogaSdtIGEgbmV3ZXIgdG8gdGhpcyBmaWVsZCwgbWF5
YmUganVzdCBhIHNpbXBsZSBxdWVzdGlvbiwgcGxlYXNlIGhlbHANCiAgDQogIC0tLS0tLS0t
LS0tLS0tLS0tLQ0KIHFpYW5nd2FuZw0KS2V5IExhYm9yYXRvcnkgb2YgU2VydmljZSBDb21w
dXRpbmcgVGVjaG5vbG9neSBhbmQgU3lzdGVtDQpLZXkgTGFib3JhdG9yeSBvZiBDbHVzdGVy
IGFuZCBHcmlkIENvbXB1dGluZyBTY2hvb2wgb2YgQ29tcHV0ZXIgU2NpZW5jZSBhbmQgVGVj
aG5vbG9neQ0KSHVhemhvbmcgVW5pdmVyc2l0eSBvZiBTY2llbmNlIGFuZCBUZWNobm9sb2d5
DQpXdWhhbiwgNDMwMDc0LCBQLlIuIENoaW5hIA0KDQpFLW1haWw6cXcuaHVzdEBnbWFpbC5j
b20=

------=_NextPart_4ECCCEDC_086E7F68_64F36947
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6y87M5Ttmb250LXNpemU6bWVkaXVtOzsiPjxESVY+
aSB0cmllZCB0aGUgY29tbWFuZCAiZWNobyAwICZndDsgL3N5cy9kZXZpY2VzL3N5c3RlbS9j
cHUvY3B1MS9vbmxpbmUiLDwvRElWPg0KPERJVj5idXQgYWZ0ZXImbmJzcDt0aGF0IHRoZSBj
b25zb2xlIHdhcyBoYWx0LCBhbmQgc29tZXRpbWVzIHN5c3RlbSB3YXMgaGFsdC48L0RJVj4N
CjxESVY+bm8gbWVzc2FnZSBsZWZ0IGluICJ4bSBkbWVzZyImbmJzcDsiZG1lc2ciICIvdmFy
L2xvZy94ZW4veGVuLWhvdHBsdWcubG9nIjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE
SVY+eGVuIHZlcnNpb24gaSB1c2VkIGlzIDQuMC4xLXJjMiwgdGhlIGRvbVUga2VybmVsIGlz
IHhlbmlmaWVkIGxpbnV4LTIuNi4zMS44PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ
Vj5hbmQgYWxzbyBpIGRpZCBhbiBleHBlcmltZW50IHdpdGhvdXQgeGVuIG9uIGxpbnV4LTIu
Ni4zMS44KHRoZSBjb25maWcgaXMganVzdCB3aXRob3V0IHhlbiBvcHRpb25zKSwgdGhlIGNv
bW1hbmQgYWJvdmUgY2FuIHdvcms8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPmhv
dyBjYW4gaSB1bnBsdWcgYSBwaHlzaWNhbCBjcHUgb24geGVuPyBpcyB0aGF0IG5vdCZuYnNw
O3N1cHBvcnRlZCBieSB4ZW4geWV0PzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+
aSdtIGEgbmV3ZXImbmJzcDt0byB0aGlzIGZpZWxkLCBtYXliZSBqdXN0IGEgc2ltcGxlIHF1
ZXN0aW9uLCBwbGVhc2UgaGVscDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PHNp
Z24gc2lnbmlkPSIyIj4NCjxESVYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCBOYXJyb3c7
IENPTE9SOiAjOTA5MDkwOyBGT05ULVNJWkU6IDEycHgiPi0tLS0tLS0tLS0tLS0tLS0tLTwv
RElWPg0KPERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiAjMDAwOyBG
T05ULVNJWkU6IDE0cHgiPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+cWlhbmd3
YW5nPC9TUEFOPjxCUj5LZXkgTGFib3JhdG9yeSBvZiBTZXJ2aWNlIENvbXB1dGluZyBUZWNo
bm9sb2d5IGFuZCBTeXN0ZW08QlI+S2V5IExhYm9yYXRvcnkgb2YgQ2x1c3RlciBhbmQgR3Jp
ZCBDb21wdXRpbmcgU2Nob29sIG9mIENvbXB1dGVyIFNjaWVuY2UgYW5kIFRlY2hub2xvZ3k8
QlI+SHVhemhvbmcgVW5pdmVyczxGT05UIHNpemU9MyBmYWNlPcvOzOU+PEZPTlQgc2l6ZT0y
IGZhY2U9y87M5T48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9MyBmYWNlPcvOzOU+PFNQQU4+
aXR5IG9mIFNjaWVuY2UgYW5kIFRlY2hub2xvZ3k8QlI+V3VoYW4sIDQzMDA3NCwgUC5SLiBD
aGluYSA8QlI+PEJSPkUtbWFpbDpxdy5odXN0QGdtYWlsLmNvbTwvU1BBTj48L0ZPTlQ+PC9G
T05UPjwvRk9OVD48QlI+PC9ESVY+PC9zaWduPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj48
L2Rpdj4=

------=_NextPart_4ECCCEDC_086E7F68_64F36947--



--===============0637803935250236498==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0637803935250236498==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:55:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTATo-00064B-8U; Wed, 23 Nov 2011 10:55:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <omogbai@gmail.com>) id 1RTATm-000644-Pu
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:55:03 +0000
X-Env-Sender: omogbai@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322045671!4655032!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10991 invoked from network); 23 Nov 2011 10:54:33 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 10:54:33 -0000
Received: by ghbz2 with SMTP id z2so1835328ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 02:54:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:date:message-id:subject:from:to:content-type;
	bh=dz/W0k7Sy24X22+j3Sv/b0M1jQAtrdY1u7DZWC3tD44=;
	b=NjtpXNOV4wAJZCymEWUAlyT8up9iS5uALHsW3Q2b2qkpIie1zHbmKwEdZ7z5UYRFXn
	HhTc+iQtZVL3WQ1aKTICoHGJW62yFusWQ+huZpSZQyclTDL43ybIitpVZoCJWiLoBIQE
	T/7QXHJjj85bgymyTb2iOjuT+wffk1wv9DJts=
MIME-Version: 1.0
Received: by 10.236.156.5 with SMTP id l5mr32816722yhk.29.1322045671236; Wed,
	23 Nov 2011 02:54:31 -0800 (PST)
Received: by 10.100.167.1 with HTTP; Wed, 23 Nov 2011 02:54:31 -0800 (PST)
Date: Wed, 23 Nov 2011 11:54:31 +0100
Message-ID: <CAK8ZZBm5UWxk6wvQgQn5tEC7_uTaY671QWNJQjcssDG32+47hw@mail.gmail.com>
From: "ehiwere.matthew@ieee.org" <omogbai@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] netconsole failed in getting target on a guest node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: ehiwere.matthew@ieee.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0435883866753179672=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0435883866753179672==
Content-Type: multipart/alternative; boundary=20cf30426d989c629704b264bea9

--20cf30426d989c629704b264bea9
Content-Type: text/plain; charset=UTF-8

When i configure netconsole on my domU,it failed in getting the target.


The following lines show up in /var/log/messages:
kernel: [ 1428.983221] netconsole: local port 6665
kernel: [ 1428.983227] netconsole: local IP 0.0.0.0
 kernel: [ 1428.983230] netconsole: interface eth2
 kernel: [ 1428.983234] netconsole: remote port 8008
 kernel: [ 1428.983237] netconsole: remote IP XXX.XXX.XX.XX
 kernel: [ 1428.983240] netconsole: remote ethernet address
00:15:72:3f:0e:5e
 kernel: [ 1428.983246] netconsole: eth2 doesn't support polling, aborting.


--

--20cf30426d989c629704b264bea9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

When i configure netconsole on my domU,it failed in getting the target.<br>=
<br><br>The=C2=A0following lines show up in /var/log/messages:
<br>kernel: [ 1428.983221] netconsole: local port 6665 <br>kernel: [ 1428.9=
83227] netconsole: local IP 0.0.0.0
<br>=C2=A0kernel: [ 1428.983230] netconsole: interface eth2
<br>=C2=A0kernel: [ 1428.983234] netconsole: remote port 8008
<br>=C2=A0kernel: [ 1428.983237] netconsole: remote IP XXX.XXX.XX.XX
<br>=C2=A0kernel: [ 1428.983240] netconsole: remote ethernet address 00:15:=
72:3f:0e:5e<br>=C2=A0kernel: [ 1428.983246] netconsole: eth2 doesn&#39;t su=
pport polling, aborting.
<br>
<br clear=3D"all"><br>-- <br><br>

--20cf30426d989c629704b264bea9--


--===============0435883866753179672==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0435883866753179672==--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:55:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTATo-00064B-8U; Wed, 23 Nov 2011 10:55:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <omogbai@gmail.com>) id 1RTATm-000644-Pu
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:55:03 +0000
X-Env-Sender: omogbai@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322045671!4655032!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10991 invoked from network); 23 Nov 2011 10:54:33 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 10:54:33 -0000
Received: by ghbz2 with SMTP id z2so1835328ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 02:54:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:reply-to:date:message-id:subject:from:to:content-type;
	bh=dz/W0k7Sy24X22+j3Sv/b0M1jQAtrdY1u7DZWC3tD44=;
	b=NjtpXNOV4wAJZCymEWUAlyT8up9iS5uALHsW3Q2b2qkpIie1zHbmKwEdZ7z5UYRFXn
	HhTc+iQtZVL3WQ1aKTICoHGJW62yFusWQ+huZpSZQyclTDL43ybIitpVZoCJWiLoBIQE
	T/7QXHJjj85bgymyTb2iOjuT+wffk1wv9DJts=
MIME-Version: 1.0
Received: by 10.236.156.5 with SMTP id l5mr32816722yhk.29.1322045671236; Wed,
	23 Nov 2011 02:54:31 -0800 (PST)
Received: by 10.100.167.1 with HTTP; Wed, 23 Nov 2011 02:54:31 -0800 (PST)
Date: Wed, 23 Nov 2011 11:54:31 +0100
Message-ID: <CAK8ZZBm5UWxk6wvQgQn5tEC7_uTaY671QWNJQjcssDG32+47hw@mail.gmail.com>
From: "ehiwere.matthew@ieee.org" <omogbai@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] netconsole failed in getting target on a guest node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: ehiwere.matthew@ieee.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0435883866753179672=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0435883866753179672==
Content-Type: multipart/alternative; boundary=20cf30426d989c629704b264bea9

--20cf30426d989c629704b264bea9
Content-Type: text/plain; charset=UTF-8

When i configure netconsole on my domU,it failed in getting the target.


The following lines show up in /var/log/messages:
kernel: [ 1428.983221] netconsole: local port 6665
kernel: [ 1428.983227] netconsole: local IP 0.0.0.0
 kernel: [ 1428.983230] netconsole: interface eth2
 kernel: [ 1428.983234] netconsole: remote port 8008
 kernel: [ 1428.983237] netconsole: remote IP XXX.XXX.XX.XX
 kernel: [ 1428.983240] netconsole: remote ethernet address
00:15:72:3f:0e:5e
 kernel: [ 1428.983246] netconsole: eth2 doesn't support polling, aborting.


--

--20cf30426d989c629704b264bea9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

When i configure netconsole on my domU,it failed in getting the target.<br>=
<br><br>The=C2=A0following lines show up in /var/log/messages:
<br>kernel: [ 1428.983221] netconsole: local port 6665 <br>kernel: [ 1428.9=
83227] netconsole: local IP 0.0.0.0
<br>=C2=A0kernel: [ 1428.983230] netconsole: interface eth2
<br>=C2=A0kernel: [ 1428.983234] netconsole: remote port 8008
<br>=C2=A0kernel: [ 1428.983237] netconsole: remote IP XXX.XXX.XX.XX
<br>=C2=A0kernel: [ 1428.983240] netconsole: remote ethernet address 00:15:=
72:3f:0e:5e<br>=C2=A0kernel: [ 1428.983246] netconsole: eth2 doesn&#39;t su=
pport polling, aborting.
<br>
<br clear=3D"all"><br>-- <br><br>

--20cf30426d989c629704b264bea9--


--===============0435883866753179672==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0435883866753179672==--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:55:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:55:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAUO-00065m-N4; Wed, 23 Nov 2011 10:55:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTAUN-00065L-Ol
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:55:40 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322045709!2689031!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1402 invoked from network); 23 Nov 2011 10:55:09 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 10:55:09 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73376982; Wed, 23 Nov 2011 11:55:08 +0100
Message-ID: <1322045702.24897.32.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 11:55:02 +0100
In-Reply-To: <1322043870.24897.25.camel@Abyss>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
	<1322040258.1005.1.camel@zakaz.uk.xensource.com>
	<1322043870.24897.25.camel@Abyss>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7444898854613988174=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7444898854613988174==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-4FjZ4eSsrN6AWIM4WnWE"


--=-4FjZ4eSsrN6AWIM4WnWE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-11-23 at 11:24 +0100, Dario Faggioli wrote:
> On Wed, 2011-11-23 at 09:24 +0000, Ian Campbell wrote:
> > > # xl sched-credit2
> > > Cpupool Pool-0:
> > > Name                                ID Weight
> > > xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_do=
main_get
> >=20
> > Is there a chance you are picking up an older version of libxl from
> > somewhere?
> >=20
> More than once... That should be the culprit for me too, but I'm still
> trying to figure out how... :-)
>=20
Ok, found! Sorry for having bothered you in the first place.

The thing is I'm running Debian Sid on the testbox, and there seems to
be no '/usr/lib64' there (neither as a real directory nor as a symlink
to '/usr/lib'), while build system put the libraries in
'dist/install/usr/lib64'. Installing the xen distribution (which is
basically unpacking an archive here) created '/ust/lib64', but it does
not appear to be on the search path for shared libraries on such
distro... Could that be an issue?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-4FjZ4eSsrN6AWIM4WnWE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7M0QYACgkQk4XaBE3IOsRNpwCfZ6+4zOgWq+BfrhkbW/WE6RkZ
X2YAnRi0Wdw9bBHMjBRhZTm+mpQ6k8h7
=c41b
-----END PGP SIGNATURE-----

--=-4FjZ4eSsrN6AWIM4WnWE--



--===============7444898854613988174==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7444898854613988174==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:55:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:55:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAUO-00065m-N4; Wed, 23 Nov 2011 10:55:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTAUN-00065L-Ol
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:55:40 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322045709!2689031!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1402 invoked from network); 23 Nov 2011 10:55:09 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 10:55:09 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73376982; Wed, 23 Nov 2011 11:55:08 +0100
Message-ID: <1322045702.24897.32.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 11:55:02 +0100
In-Reply-To: <1322043870.24897.25.camel@Abyss>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
	<1322040258.1005.1.camel@zakaz.uk.xensource.com>
	<1322043870.24897.25.camel@Abyss>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7444898854613988174=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7444898854613988174==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-4FjZ4eSsrN6AWIM4WnWE"


--=-4FjZ4eSsrN6AWIM4WnWE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-11-23 at 11:24 +0100, Dario Faggioli wrote:
> On Wed, 2011-11-23 at 09:24 +0000, Ian Campbell wrote:
> > > # xl sched-credit2
> > > Cpupool Pool-0:
> > > Name                                ID Weight
> > > xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_do=
main_get
> >=20
> > Is there a chance you are picking up an older version of libxl from
> > somewhere?
> >=20
> More than once... That should be the culprit for me too, but I'm still
> trying to figure out how... :-)
>=20
Ok, found! Sorry for having bothered you in the first place.

The thing is I'm running Debian Sid on the testbox, and there seems to
be no '/usr/lib64' there (neither as a real directory nor as a symlink
to '/usr/lib'), while build system put the libraries in
'dist/install/usr/lib64'. Installing the xen distribution (which is
basically unpacking an archive here) created '/ust/lib64', but it does
not appear to be on the search path for shared libraries on such
distro... Could that be an issue?

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-4FjZ4eSsrN6AWIM4WnWE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7M0QYACgkQk4XaBE3IOsRNpwCfZ6+4zOgWq+BfrhkbW/WE6RkZ
X2YAnRi0Wdw9bBHMjBRhZTm+mpQ6k8h7
=c41b
-----END PGP SIGNATURE-----

--=-4FjZ4eSsrN6AWIM4WnWE--



--===============7444898854613988174==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7444898854613988174==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:56:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:56:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAVC-0006A8-6G; Wed, 23 Nov 2011 10:56:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTAVB-00069g-15
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:56:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322045759!4269398!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17115 invoked from network); 23 Nov 2011 10:55:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 10:55:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9084026"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 10:55:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 10:55:58 +0000
Date: Wed, 23 Nov 2011 10:56:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1770525608-1322045793=:31179"
Content-ID: <alpine.DEB.2.00.1111231056370.31179@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1770525608-1322045793=:31179
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1111231056371.31179@kaball-desktop>

On Tue, 22 Nov 2011, Teck Choon Giam wrote:
> >> >> That means default value changed if it is unset for autoballoon?
> >> >> Original one is commented with #autoballoon = 1 in /etc/xen/xl.conf so
> >> >> it is unset I guess so the default value for autoballoon for c/s 23110
> >> >> is autoballoon=0 where c/s 23190 is autoballoon=1? � Just some
> >> >> guessing... ...
> >
> > Autoballoon and dom0_mem are incompatible.
> > I don't think there are any relevant differences between 23110 and 23190
> > on xen-unstable, maybe you used to start dom0 without dom0_mem before?
> 
> Nope... all my servers will always have those dom0_mem set.  It is
> from xen-4.1-testing not xen-unstable for the two changeset.

I still cannot see anything in that range. However as I said before, it
is expected that with dom0_mem set autoballoon needs to be disabled.

Maybe it is worth documenting this somewhere, any suggestions where?
--8323329-1770525608-1322045793=:31179
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1770525608-1322045793=:31179--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 10:56:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 10:56:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAVC-0006A8-6G; Wed, 23 Nov 2011 10:56:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTAVB-00069g-15
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 10:56:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322045759!4269398!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17115 invoked from network); 23 Nov 2011 10:55:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 10:55:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9084026"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 10:55:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 10:55:58 +0000
Date: Wed, 23 Nov 2011 10:56:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Teck Choon Giam <giamteckchoon@gmail.com>
In-Reply-To: <CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1770525608-1322045793=:31179"
Content-ID: <alpine.DEB.2.00.1111231056370.31179@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1770525608-1322045793=:31179
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1111231056371.31179@kaball-desktop>

On Tue, 22 Nov 2011, Teck Choon Giam wrote:
> >> >> That means default value changed if it is unset for autoballoon?
> >> >> Original one is commented with #autoballoon = 1 in /etc/xen/xl.conf so
> >> >> it is unset I guess so the default value for autoballoon for c/s 23110
> >> >> is autoballoon=0 where c/s 23190 is autoballoon=1? � Just some
> >> >> guessing... ...
> >
> > Autoballoon and dom0_mem are incompatible.
> > I don't think there are any relevant differences between 23110 and 23190
> > on xen-unstable, maybe you used to start dom0 without dom0_mem before?
> 
> Nope... all my servers will always have those dom0_mem set.  It is
> from xen-4.1-testing not xen-unstable for the two changeset.

I still cannot see anything in that range. However as I said before, it
is expected that with dom0_mem set autoballoon needs to be disabled.

Maybe it is worth documenting this somewhere, any suggestions where?
--8323329-1770525608-1322045793=:31179
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1770525608-1322045793=:31179--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:07:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:07:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAfh-0006eg-Dw; Wed, 23 Nov 2011 11:07:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <deepthi@linux.vnet.ibm.com>) id 1RTAff-0006eZ-Bq
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:07:19 +0000
X-Env-Sender: deepthi@linux.vnet.ibm.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322046396!56141228!1
X-Originating-IP: [202.81.31.140]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22501 invoked from network); 23 Nov 2011 11:06:39 -0000
Received: from e23smtp07.au.ibm.com (HELO e23smtp07.au.ibm.com) (202.81.31.140)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 11:06:39 -0000
Received: from /spool/local
	by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <deepthi@linux.vnet.ibm.com>; 
	Wed, 23 Nov 2011 11:04:43 +1000
Received: from d23relay03.au.ibm.com ([202.81.31.245])
	by e23smtp07.au.ibm.com ([202.81.31.204]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 23 Nov 2011 11:04:36 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pANB6Tfq3248186
	for <xen-devel@lists.xensource.com>; Wed, 23 Nov 2011 22:06:31 +1100
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pANB6SHm024675
	for <xen-devel@lists.xensource.com>; Wed, 23 Nov 2011 22:06:28 +1100
Received: from [9.124.35.189] (deepthi-thinkpad-t420.in.ibm.com [9.124.35.189])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pANB6PfN024616; Wed, 23 Nov 2011 22:06:25 +1100
Message-ID: <4ECCD3B0.2010207@linux.vnet.ibm.com>
Date: Wed, 23 Nov 2011 16:36:24 +0530
From: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1320786914-10541-1-git-send-email-konrad.wilk@oracle.com>
	<1320786914-10541-2-git-send-email-konrad.wilk@oracle.com>
	<4EBA53C5.9040603@linux.vnet.ibm.com>
	<20111109144440.GB8410@phenom.dumpdata.com>
	<4EBD09FF.4030002@linux.vnet.ibm.com>
	<20111115144004.GE22675@phenom.dumpdata.com>
	<20111122134612.GA29668@phenom.dumpdata.com>
In-Reply-To: <20111122134612.GA29668@phenom.dumpdata.com>
x-cbid: 11112301-0260-0000-0000-000000187AB7
Cc: len.brown@intel.com, jeremy@goop.org, xen-devel@lists.xensource.com,
	x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org,
	mingo@redhat.com, bp@alien8.de, hpa@zytor.com, tj@kernel.org,
	tglx@linutronix.de, trenn@suse.de
Subject: Re: [Xen-devel] [PATCH 1/3] cpuidle: If disable_cpuidle() is called,
 set pm_idle to default_idle.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3808524714696937928=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============3808524714696937928==
Content-Type: multipart/alternative;
 boundary="------------020707000304080803020504"

This is a multi-part message in MIME format.
--------------020707000304080803020504
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Konrad,

On 11/22/2011 07:16 PM, Konrad Rzeszutek Wilk wrote:

> On Tue, Nov 15, 2011 at 09:40:04AM -0500, Konrad Rzeszutek Wilk wrote:
>>> Well I was with a view that if cpuidle is disabled, mwait and arm_e400
>>> would take precedence over default_idle. But if is ok to have default_idle instead,
>>> then go ahead. 
>>>
>>>> Perhaps there is another way do this is:
>>>>
>>>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>>>> index becd6d9..04b10a4 100644
>>>> --- a/drivers/cpuidle/cpuidle.c
>>>> +++ b/drivers/cpuidle/cpuidle.c
>>>> @@ -38,6 +38,7 @@ int cpuidle_disabled(void)
>>>>  void disable_cpuidle(void)
>>>>  {
>>>>  	off = 1;
>>>> +	pm_idle = default_idle;
>>>>  }
>>>>
>>> Brining pm_idle pointer back to cpuidle code is going a step back coz
>>> we wanted to complete remove using pm_idle going forward. As having 
>>> a pointer exported into various files is not a good thing. That's the 
>>> reason we started the clean up in the first place :) 
>>
>> Perhaps then something along these lines, where we still set default_idle
>> but don't fiddle with the pm_idle (and can still rip out the
>> EXPORT_SYMBOL_GPL(default_idle) in 2012):
>>
>> (Hadn't tested this yet).
>
> Now have tested it.
>



As long as you dont bring back exporting pm_idle and using it in cpuidle
code
it should be ok.  So one should not use pm_idle in disable_cpuidle function.

>>
>> diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
>> index c2ff2a1..2d2f01c 100644
>> --- a/arch/x86/include/asm/system.h
>> +++ b/arch/x86/include/asm/system.h
>> @@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
>>  extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
>>  
>>  void default_idle(void);
>> +bool set_pm_idle_to_default(void);
>>  
>>  void stop_this_cpu(void *dummy);
>>  
>> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
>> index e7e3b01..bfb113f 100644
>> --- a/arch/x86/kernel/process.c
>> +++ b/arch/x86/kernel/process.c
>> @@ -403,6 +403,14 @@ void default_idle(void)
>>  EXPORT_SYMBOL(default_idle);
>>  #endif
>>  
>> +bool set_pm_idle_to_default()
>> +{
>> +	if (!pm_idle) {
>> +		pm_idle = default_idle;
>> +		return true;
>> +	}
>> +	return false;
>> +}
>>  void stop_this_cpu(void *dummy)
>>  {
>>  	local_irq_disable();
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 46d6d21..7506181 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
>>  #endif
>>  	disable_cpuidle();
>>  	boot_option_idle_override = IDLE_HALT;
>> -
>> +	WARN_ON(!set_pm_idle_to_default());
>>  	fiddle_vdso();
>>  }
>>



This looks good, where we see setting of default_idle only  in
Xen setup code and not the in the generic cpuidle code path.
This would allow other architectures to use mwait or arm_e400
to be enabled when cpuidle is disabled.

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>



Cheers,
Deepthi


--------------020707000304080803020504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    <small><small>Hi Konrad,<br>
        <br>
        On 11/22/2011 07:16 PM, Konrad Rzeszutek Wilk wrote:<br>
        <br>
        <pre style="margin: 0pt 0pt 0pt 0px;">&gt; On Tue, Nov 15, 2011 at 09:40:04AM -0500, Konrad Rzeszutek Wilk wrote:
&gt;&gt;&gt; Well I was with a view that if cpuidle is disabled, mwait and arm_e400
&gt;&gt;&gt; would take precedence over default_idle. But if is ok to have default_idle instead,
&gt;&gt;&gt; then go ahead. 
&gt;&gt;&gt;
&gt;&gt;&gt;&gt; Perhaps there is another way do this is:
&gt;&gt;&gt;&gt;
&gt;&gt;&gt;&gt; diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
&gt;&gt;&gt;&gt; index becd6d9..04b10a4 100644
&gt;&gt;&gt;&gt; --- a/drivers/cpuidle/cpuidle.c
&gt;&gt;&gt;&gt; +++ b/drivers/cpuidle/cpuidle.c
&gt;&gt;&gt;&gt; @@ -38,6 +38,7 @@ int cpuidle_disabled(void)
&gt;&gt;&gt;&gt;  void disable_cpuidle(void)
&gt;&gt;&gt;&gt;  {
&gt;&gt;&gt;&gt;  	off = 1;
&gt;&gt;&gt;&gt; +	pm_idle = default_idle;
&gt;&gt;&gt;&gt;  }
&gt;&gt;&gt;&gt;
&gt;&gt;&gt; Brining pm_idle pointer back to cpuidle code is going a step back coz
&gt;&gt;&gt; we wanted to complete remove using pm_idle going forward. As having 
&gt;&gt;&gt; a pointer exported into various files is not a good thing. That's the 
&gt;&gt;&gt; reason we started the clean up in the first place :) 
&gt;&gt;
&gt;&gt; Perhaps then something along these lines, where we still set default_idle
&gt;&gt; but don't fiddle with the pm_idle (and can still rip out the
&gt;&gt; EXPORT_SYMBOL_GPL(default_idle) in 2012):
&gt;&gt;
&gt;&gt; (Hadn't tested this yet).
&gt;
&gt; Now have tested it.
&gt;</pre>
        <br>
        <br>
        As long as you dont bring back exporting pm_idle and using it in
        cpuidle code<br>
        it should be ok.&nbsp; So one should not use pm_idle in
        disable_cpuidle function.<br>
        <br>
        <pre style="margin: 0pt 0pt 0pt 0px;">&gt;&gt;
&gt;&gt; diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
&gt;&gt; index c2ff2a1..2d2f01c 100644
&gt;&gt; --- a/arch/x86/include/asm/system.h
&gt;&gt; +++ b/arch/x86/include/asm/system.h
&gt;&gt; @@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
&gt;&gt;  extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
&gt;&gt;  
&gt;&gt;  void default_idle(void);
&gt;&gt; +bool set_pm_idle_to_default(void);
&gt;&gt;  
&gt;&gt;  void stop_this_cpu(void *dummy);
&gt;&gt;  
&gt;&gt; diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
&gt;&gt; index e7e3b01..bfb113f 100644
&gt;&gt; --- a/arch/x86/kernel/process.c
&gt;&gt; +++ b/arch/x86/kernel/process.c
&gt;&gt; @@ -403,6 +403,14 @@ void default_idle(void)
&gt;&gt;  EXPORT_SYMBOL(default_idle);
&gt;&gt;  #endif
&gt;&gt;  
&gt;&gt; +bool set_pm_idle_to_default()
&gt;&gt; +{
&gt;&gt; +	if (!pm_idle) {
&gt;&gt; +		pm_idle = default_idle;
&gt;&gt; +		return true;
&gt;&gt; +	}
&gt;&gt; +	return false;
&gt;&gt; +}
&gt;&gt;  void stop_this_cpu(void *dummy)
&gt;&gt;  {
&gt;&gt;  	local_irq_disable();
&gt;&gt; diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
&gt;&gt; index 46d6d21..7506181 100644
&gt;&gt; --- a/arch/x86/xen/setup.c
&gt;&gt; +++ b/arch/x86/xen/setup.c
&gt;&gt; @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
&gt;&gt;  #endif
&gt;&gt;  	disable_cpuidle();
&gt;&gt;  	boot_option_idle_override = IDLE_HALT;
&gt;&gt; -
&gt;&gt; +	WARN_ON(!set_pm_idle_to_default());
&gt;&gt;  	fiddle_vdso();
&gt;&gt;  }
&gt;&gt;</pre>
        <br>
        <br>
        This looks good, where we see setting of default_idle only&nbsp; in<br>
        Xen setup code and not the in the generic cpuidle code path.<br>
        This would allow other architectures to use mwait or arm_e400<br>
        to be enabled when cpuidle is disabled.<br>
        <br>
        <pre style="margin: 0pt 0pt 0pt 0px;">&gt;&gt; _______________________________________________
&gt;&gt; Xen-devel mailing list
&gt;&gt; <a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
&gt;&gt; <a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>
&gt;</pre>
        <br>
        <br>
        Cheers,<br>
        Deepthi<br>
        <br>
      </small></small>
  </body>
</html>

--------------020707000304080803020504--



--===============3808524714696937928==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3808524714696937928==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:07:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:07:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAfh-0006eg-Dw; Wed, 23 Nov 2011 11:07:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <deepthi@linux.vnet.ibm.com>) id 1RTAff-0006eZ-Bq
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:07:19 +0000
X-Env-Sender: deepthi@linux.vnet.ibm.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322046396!56141228!1
X-Originating-IP: [202.81.31.140]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22501 invoked from network); 23 Nov 2011 11:06:39 -0000
Received: from e23smtp07.au.ibm.com (HELO e23smtp07.au.ibm.com) (202.81.31.140)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 11:06:39 -0000
Received: from /spool/local
	by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <deepthi@linux.vnet.ibm.com>; 
	Wed, 23 Nov 2011 11:04:43 +1000
Received: from d23relay03.au.ibm.com ([202.81.31.245])
	by e23smtp07.au.ibm.com ([202.81.31.204]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 23 Nov 2011 11:04:36 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pANB6Tfq3248186
	for <xen-devel@lists.xensource.com>; Wed, 23 Nov 2011 22:06:31 +1100
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pANB6SHm024675
	for <xen-devel@lists.xensource.com>; Wed, 23 Nov 2011 22:06:28 +1100
Received: from [9.124.35.189] (deepthi-thinkpad-t420.in.ibm.com [9.124.35.189])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pANB6PfN024616; Wed, 23 Nov 2011 22:06:25 +1100
Message-ID: <4ECCD3B0.2010207@linux.vnet.ibm.com>
Date: Wed, 23 Nov 2011 16:36:24 +0530
From: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1320786914-10541-1-git-send-email-konrad.wilk@oracle.com>
	<1320786914-10541-2-git-send-email-konrad.wilk@oracle.com>
	<4EBA53C5.9040603@linux.vnet.ibm.com>
	<20111109144440.GB8410@phenom.dumpdata.com>
	<4EBD09FF.4030002@linux.vnet.ibm.com>
	<20111115144004.GE22675@phenom.dumpdata.com>
	<20111122134612.GA29668@phenom.dumpdata.com>
In-Reply-To: <20111122134612.GA29668@phenom.dumpdata.com>
x-cbid: 11112301-0260-0000-0000-000000187AB7
Cc: len.brown@intel.com, jeremy@goop.org, xen-devel@lists.xensource.com,
	x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org,
	mingo@redhat.com, bp@alien8.de, hpa@zytor.com, tj@kernel.org,
	tglx@linutronix.de, trenn@suse.de
Subject: Re: [Xen-devel] [PATCH 1/3] cpuidle: If disable_cpuidle() is called,
 set pm_idle to default_idle.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3808524714696937928=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============3808524714696937928==
Content-Type: multipart/alternative;
 boundary="------------020707000304080803020504"

This is a multi-part message in MIME format.
--------------020707000304080803020504
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Konrad,

On 11/22/2011 07:16 PM, Konrad Rzeszutek Wilk wrote:

> On Tue, Nov 15, 2011 at 09:40:04AM -0500, Konrad Rzeszutek Wilk wrote:
>>> Well I was with a view that if cpuidle is disabled, mwait and arm_e400
>>> would take precedence over default_idle. But if is ok to have default_idle instead,
>>> then go ahead. 
>>>
>>>> Perhaps there is another way do this is:
>>>>
>>>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>>>> index becd6d9..04b10a4 100644
>>>> --- a/drivers/cpuidle/cpuidle.c
>>>> +++ b/drivers/cpuidle/cpuidle.c
>>>> @@ -38,6 +38,7 @@ int cpuidle_disabled(void)
>>>>  void disable_cpuidle(void)
>>>>  {
>>>>  	off = 1;
>>>> +	pm_idle = default_idle;
>>>>  }
>>>>
>>> Brining pm_idle pointer back to cpuidle code is going a step back coz
>>> we wanted to complete remove using pm_idle going forward. As having 
>>> a pointer exported into various files is not a good thing. That's the 
>>> reason we started the clean up in the first place :) 
>>
>> Perhaps then something along these lines, where we still set default_idle
>> but don't fiddle with the pm_idle (and can still rip out the
>> EXPORT_SYMBOL_GPL(default_idle) in 2012):
>>
>> (Hadn't tested this yet).
>
> Now have tested it.
>



As long as you dont bring back exporting pm_idle and using it in cpuidle
code
it should be ok.  So one should not use pm_idle in disable_cpuidle function.

>>
>> diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
>> index c2ff2a1..2d2f01c 100644
>> --- a/arch/x86/include/asm/system.h
>> +++ b/arch/x86/include/asm/system.h
>> @@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
>>  extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
>>  
>>  void default_idle(void);
>> +bool set_pm_idle_to_default(void);
>>  
>>  void stop_this_cpu(void *dummy);
>>  
>> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
>> index e7e3b01..bfb113f 100644
>> --- a/arch/x86/kernel/process.c
>> +++ b/arch/x86/kernel/process.c
>> @@ -403,6 +403,14 @@ void default_idle(void)
>>  EXPORT_SYMBOL(default_idle);
>>  #endif
>>  
>> +bool set_pm_idle_to_default()
>> +{
>> +	if (!pm_idle) {
>> +		pm_idle = default_idle;
>> +		return true;
>> +	}
>> +	return false;
>> +}
>>  void stop_this_cpu(void *dummy)
>>  {
>>  	local_irq_disable();
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 46d6d21..7506181 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
>>  #endif
>>  	disable_cpuidle();
>>  	boot_option_idle_override = IDLE_HALT;
>> -
>> +	WARN_ON(!set_pm_idle_to_default());
>>  	fiddle_vdso();
>>  }
>>



This looks good, where we see setting of default_idle only  in
Xen setup code and not the in the generic cpuidle code path.
This would allow other architectures to use mwait or arm_e400
to be enabled when cpuidle is disabled.

>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>



Cheers,
Deepthi


--------------020707000304080803020504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    <small><small>Hi Konrad,<br>
        <br>
        On 11/22/2011 07:16 PM, Konrad Rzeszutek Wilk wrote:<br>
        <br>
        <pre style="margin: 0pt 0pt 0pt 0px;">&gt; On Tue, Nov 15, 2011 at 09:40:04AM -0500, Konrad Rzeszutek Wilk wrote:
&gt;&gt;&gt; Well I was with a view that if cpuidle is disabled, mwait and arm_e400
&gt;&gt;&gt; would take precedence over default_idle. But if is ok to have default_idle instead,
&gt;&gt;&gt; then go ahead. 
&gt;&gt;&gt;
&gt;&gt;&gt;&gt; Perhaps there is another way do this is:
&gt;&gt;&gt;&gt;
&gt;&gt;&gt;&gt; diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
&gt;&gt;&gt;&gt; index becd6d9..04b10a4 100644
&gt;&gt;&gt;&gt; --- a/drivers/cpuidle/cpuidle.c
&gt;&gt;&gt;&gt; +++ b/drivers/cpuidle/cpuidle.c
&gt;&gt;&gt;&gt; @@ -38,6 +38,7 @@ int cpuidle_disabled(void)
&gt;&gt;&gt;&gt;  void disable_cpuidle(void)
&gt;&gt;&gt;&gt;  {
&gt;&gt;&gt;&gt;  	off = 1;
&gt;&gt;&gt;&gt; +	pm_idle = default_idle;
&gt;&gt;&gt;&gt;  }
&gt;&gt;&gt;&gt;
&gt;&gt;&gt; Brining pm_idle pointer back to cpuidle code is going a step back coz
&gt;&gt;&gt; we wanted to complete remove using pm_idle going forward. As having 
&gt;&gt;&gt; a pointer exported into various files is not a good thing. That's the 
&gt;&gt;&gt; reason we started the clean up in the first place :) 
&gt;&gt;
&gt;&gt; Perhaps then something along these lines, where we still set default_idle
&gt;&gt; but don't fiddle with the pm_idle (and can still rip out the
&gt;&gt; EXPORT_SYMBOL_GPL(default_idle) in 2012):
&gt;&gt;
&gt;&gt; (Hadn't tested this yet).
&gt;
&gt; Now have tested it.
&gt;</pre>
        <br>
        <br>
        As long as you dont bring back exporting pm_idle and using it in
        cpuidle code<br>
        it should be ok.&nbsp; So one should not use pm_idle in
        disable_cpuidle function.<br>
        <br>
        <pre style="margin: 0pt 0pt 0pt 0px;">&gt;&gt;
&gt;&gt; diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
&gt;&gt; index c2ff2a1..2d2f01c 100644
&gt;&gt; --- a/arch/x86/include/asm/system.h
&gt;&gt; +++ b/arch/x86/include/asm/system.h
&gt;&gt; @@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
&gt;&gt;  extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
&gt;&gt;  
&gt;&gt;  void default_idle(void);
&gt;&gt; +bool set_pm_idle_to_default(void);
&gt;&gt;  
&gt;&gt;  void stop_this_cpu(void *dummy);
&gt;&gt;  
&gt;&gt; diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
&gt;&gt; index e7e3b01..bfb113f 100644
&gt;&gt; --- a/arch/x86/kernel/process.c
&gt;&gt; +++ b/arch/x86/kernel/process.c
&gt;&gt; @@ -403,6 +403,14 @@ void default_idle(void)
&gt;&gt;  EXPORT_SYMBOL(default_idle);
&gt;&gt;  #endif
&gt;&gt;  
&gt;&gt; +bool set_pm_idle_to_default()
&gt;&gt; +{
&gt;&gt; +	if (!pm_idle) {
&gt;&gt; +		pm_idle = default_idle;
&gt;&gt; +		return true;
&gt;&gt; +	}
&gt;&gt; +	return false;
&gt;&gt; +}
&gt;&gt;  void stop_this_cpu(void *dummy)
&gt;&gt;  {
&gt;&gt;  	local_irq_disable();
&gt;&gt; diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
&gt;&gt; index 46d6d21..7506181 100644
&gt;&gt; --- a/arch/x86/xen/setup.c
&gt;&gt; +++ b/arch/x86/xen/setup.c
&gt;&gt; @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
&gt;&gt;  #endif
&gt;&gt;  	disable_cpuidle();
&gt;&gt;  	boot_option_idle_override = IDLE_HALT;
&gt;&gt; -
&gt;&gt; +	WARN_ON(!set_pm_idle_to_default());
&gt;&gt;  	fiddle_vdso();
&gt;&gt;  }
&gt;&gt;</pre>
        <br>
        <br>
        This looks good, where we see setting of default_idle only&nbsp; in<br>
        Xen setup code and not the in the generic cpuidle code path.<br>
        This would allow other architectures to use mwait or arm_e400<br>
        to be enabled when cpuidle is disabled.<br>
        <br>
        <pre style="margin: 0pt 0pt 0pt 0px;">&gt;&gt; _______________________________________________
&gt;&gt; Xen-devel mailing list
&gt;&gt; <a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
&gt;&gt; <a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>
&gt;</pre>
        <br>
        <br>
        Cheers,<br>
        Deepthi<br>
        <br>
      </small></small>
  </body>
</html>

--------------020707000304080803020504--



--===============3808524714696937928==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3808524714696937928==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:08:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAgB-0006h0-2I; Wed, 23 Nov 2011 11:07:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTAg9-0006gJ-Mw
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:07:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322046439!3821629!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17426 invoked from network); 23 Nov 2011 11:07:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:07:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9084331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:07:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:07:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 23 Nov 2011 11:07:17 +0000
In-Reply-To: <alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322046437.1005.62.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTIzIGF0IDEwOjU2ICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gT24gVHVlLCAyMiBOb3YgMjAxMSwgVGVjayBDaG9vbiBHaWFtIHdyb3RlOgo+ID4gPj4g
Pj4gVGhhdCBtZWFucyBkZWZhdWx0IHZhbHVlIGNoYW5nZWQgaWYgaXQgaXMgdW5zZXQgZm9yIGF1
dG9iYWxsb29uPwo+ID4gPj4gPj4gT3JpZ2luYWwgb25lIGlzIGNvbW1lbnRlZCB3aXRoICNhdXRv
YmFsbG9vbiA9IDEgaW4gL2V0Yy94ZW4veGwuY29uZiBzbwo+ID4gPj4gPj4gaXQgaXMgdW5zZXQg
SSBndWVzcyBzbyB0aGUgZGVmYXVsdCB2YWx1ZSBmb3IgYXV0b2JhbGxvb24gZm9yIGMvcyAyMzEx
MAo+ID4gPj4gPj4gaXMgYXV0b2JhbGxvb249MCB3aGVyZSBjL3MgMjMxOTAgaXMgYXV0b2JhbGxv
b249MT8gw4PGkj/Dg+KAmsOCIEp1c3Qgc29tZQo+ID4gPj4gPj4gZ3Vlc3NpbmcuLi4gLi4uCj4g
PiA+Cj4gPiA+IEF1dG9iYWxsb29uIGFuZCBkb20wX21lbSBhcmUgaW5jb21wYXRpYmxlLgo+ID4g
PiBJIGRvbid0IHRoaW5rIHRoZXJlIGFyZSBhbnkgcmVsZXZhbnQgZGlmZmVyZW5jZXMgYmV0d2Vl
biAyMzExMCBhbmQgMjMxOTAKPiA+ID4gb24geGVuLXVuc3RhYmxlLCBtYXliZSB5b3UgdXNlZCB0
byBzdGFydCBkb20wIHdpdGhvdXQgZG9tMF9tZW0gYmVmb3JlPwo+ID4gCj4gPiBOb3BlLi4uIGFs
bCBteSBzZXJ2ZXJzIHdpbGwgYWx3YXlzIGhhdmUgdGhvc2UgZG9tMF9tZW0gc2V0LiAgSXQgaXMK
PiA+IGZyb20geGVuLTQuMS10ZXN0aW5nIG5vdCB4ZW4tdW5zdGFibGUgZm9yIHRoZSB0d28gY2hh
bmdlc2V0Lgo+IAo+IEkgc3RpbGwgY2Fubm90IHNlZSBhbnl0aGluZyBpbiB0aGF0IHJhbmdlLiBI
b3dldmVyIGFzIEkgc2FpZCBiZWZvcmUsIGl0Cj4gaXMgZXhwZWN0ZWQgdGhhdCB3aXRoIGRvbTBf
bWVtIHNldCBhdXRvYmFsbG9vbiBuZWVkcyB0byBiZSBkaXNhYmxlZC4KCldlIHN0aWxsIGhhdmVu
J3Qgc2VlbiB0aGUgZnVsbCBub2RlIElEcyBvZiB0aGUgY2hhbmdlc2V0cyB3aGljaCBJIGFza2Vk
CmZvciBzbyBpdCBpcyBub3Qgb2J2aW91cyB0aGF0IHdlIGFyZSBhY3R1YWxseSBsb29raW5nIGF0
IHRoZSBzYW1lIHJhbmdlCm9mIGNoYW5nZXNldHMuLi4KCj4gTWF5YmUgaXQgaXMgd29ydGggZG9j
dW1lbnRpbmcgdGhpcyBzb21ld2hlcmUsIGFueSBzdWdnZXN0aW9ucyB3aGVyZT8KCnhsIG1hbiBw
YWdlPyBQZXJoYXBzIHdlIGFsc28gbmVlZCBhIHNlcGFyYXRlIC9ldGMveGwuY2ZnIChvciB3aGF0
ZXZlcgp0aGUgcGF0aCBpcykgcGFnZT8KCklmIHRoZXJlIGlzIGFueXdoZXJlIG9uIHRoZSB3aWtp
IHdoaWNoIHJlY29tbWVuZHMgZG9tMF9tZW09IChhbmQgdGhlcmUKc2hvdWxkIGJlKSBpdCBzaG91
bGQgc2ltdWx0YW5lb3VzbHkgbWVudGlvbiB0aGlzIHNldHRpbmcuIEFzIHNob3VsZCBhbnkKImdl
dHRpbmcgc3RhcnRlZCIgcGFnZS4KCk9uIHRoZSBvdGhlciBoYW5kIEknbSBub3Qgc3VyZSB3aHkg
YXV0b2JhbGxvb24gYW5kIGRvbTBfbWVtIHBsYXkgc28KYmFkbHkgdG9nZXRoZXIuIFN1cmVseSBp
ZiBkb20wX21lbSBpcyB1c2VkIGF1dG9iYWxsb24gc2hvdWxkIGp1c3Qgc2VlCnRoYXQgdGhlcmUg
aXMgcGxlbnR5IG9mIGZyZWUgUkFNIGluIHRoZSBzeXN0ZW0gYW5kIG5vdCBkbyBhbnl0aGluZz8K
Cklhbi4KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:08:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAgB-0006h0-2I; Wed, 23 Nov 2011 11:07:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTAg9-0006gJ-Mw
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:07:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322046439!3821629!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17426 invoked from network); 23 Nov 2011 11:07:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:07:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9084331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:07:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:07:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 23 Nov 2011 11:07:17 +0000
In-Reply-To: <alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322046437.1005.62.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTIzIGF0IDEwOjU2ICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gT24gVHVlLCAyMiBOb3YgMjAxMSwgVGVjayBDaG9vbiBHaWFtIHdyb3RlOgo+ID4gPj4g
Pj4gVGhhdCBtZWFucyBkZWZhdWx0IHZhbHVlIGNoYW5nZWQgaWYgaXQgaXMgdW5zZXQgZm9yIGF1
dG9iYWxsb29uPwo+ID4gPj4gPj4gT3JpZ2luYWwgb25lIGlzIGNvbW1lbnRlZCB3aXRoICNhdXRv
YmFsbG9vbiA9IDEgaW4gL2V0Yy94ZW4veGwuY29uZiBzbwo+ID4gPj4gPj4gaXQgaXMgdW5zZXQg
SSBndWVzcyBzbyB0aGUgZGVmYXVsdCB2YWx1ZSBmb3IgYXV0b2JhbGxvb24gZm9yIGMvcyAyMzEx
MAo+ID4gPj4gPj4gaXMgYXV0b2JhbGxvb249MCB3aGVyZSBjL3MgMjMxOTAgaXMgYXV0b2JhbGxv
b249MT8gw4PGkj/Dg+KAmsOCIEp1c3Qgc29tZQo+ID4gPj4gPj4gZ3Vlc3NpbmcuLi4gLi4uCj4g
PiA+Cj4gPiA+IEF1dG9iYWxsb29uIGFuZCBkb20wX21lbSBhcmUgaW5jb21wYXRpYmxlLgo+ID4g
PiBJIGRvbid0IHRoaW5rIHRoZXJlIGFyZSBhbnkgcmVsZXZhbnQgZGlmZmVyZW5jZXMgYmV0d2Vl
biAyMzExMCBhbmQgMjMxOTAKPiA+ID4gb24geGVuLXVuc3RhYmxlLCBtYXliZSB5b3UgdXNlZCB0
byBzdGFydCBkb20wIHdpdGhvdXQgZG9tMF9tZW0gYmVmb3JlPwo+ID4gCj4gPiBOb3BlLi4uIGFs
bCBteSBzZXJ2ZXJzIHdpbGwgYWx3YXlzIGhhdmUgdGhvc2UgZG9tMF9tZW0gc2V0LiAgSXQgaXMK
PiA+IGZyb20geGVuLTQuMS10ZXN0aW5nIG5vdCB4ZW4tdW5zdGFibGUgZm9yIHRoZSB0d28gY2hh
bmdlc2V0Lgo+IAo+IEkgc3RpbGwgY2Fubm90IHNlZSBhbnl0aGluZyBpbiB0aGF0IHJhbmdlLiBI
b3dldmVyIGFzIEkgc2FpZCBiZWZvcmUsIGl0Cj4gaXMgZXhwZWN0ZWQgdGhhdCB3aXRoIGRvbTBf
bWVtIHNldCBhdXRvYmFsbG9vbiBuZWVkcyB0byBiZSBkaXNhYmxlZC4KCldlIHN0aWxsIGhhdmVu
J3Qgc2VlbiB0aGUgZnVsbCBub2RlIElEcyBvZiB0aGUgY2hhbmdlc2V0cyB3aGljaCBJIGFza2Vk
CmZvciBzbyBpdCBpcyBub3Qgb2J2aW91cyB0aGF0IHdlIGFyZSBhY3R1YWxseSBsb29raW5nIGF0
IHRoZSBzYW1lIHJhbmdlCm9mIGNoYW5nZXNldHMuLi4KCj4gTWF5YmUgaXQgaXMgd29ydGggZG9j
dW1lbnRpbmcgdGhpcyBzb21ld2hlcmUsIGFueSBzdWdnZXN0aW9ucyB3aGVyZT8KCnhsIG1hbiBw
YWdlPyBQZXJoYXBzIHdlIGFsc28gbmVlZCBhIHNlcGFyYXRlIC9ldGMveGwuY2ZnIChvciB3aGF0
ZXZlcgp0aGUgcGF0aCBpcykgcGFnZT8KCklmIHRoZXJlIGlzIGFueXdoZXJlIG9uIHRoZSB3aWtp
IHdoaWNoIHJlY29tbWVuZHMgZG9tMF9tZW09IChhbmQgdGhlcmUKc2hvdWxkIGJlKSBpdCBzaG91
bGQgc2ltdWx0YW5lb3VzbHkgbWVudGlvbiB0aGlzIHNldHRpbmcuIEFzIHNob3VsZCBhbnkKImdl
dHRpbmcgc3RhcnRlZCIgcGFnZS4KCk9uIHRoZSBvdGhlciBoYW5kIEknbSBub3Qgc3VyZSB3aHkg
YXV0b2JhbGxvb24gYW5kIGRvbTBfbWVtIHBsYXkgc28KYmFkbHkgdG9nZXRoZXIuIFN1cmVseSBp
ZiBkb20wX21lbSBpcyB1c2VkIGF1dG9iYWxsb24gc2hvdWxkIGp1c3Qgc2VlCnRoYXQgdGhlcmUg
aXMgcGxlbnR5IG9mIGZyZWUgUkFNIGluIHRoZSBzeXN0ZW0gYW5kIG5vdCBkbyBhbnl0aGluZz8K
Cklhbi4KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:12:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:12:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAkS-00070c-U6; Wed, 23 Nov 2011 11:12:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RTAkS-0006zz-3k
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:12:16 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322046706!4285561!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30986 invoked from network); 23 Nov 2011 11:11:46 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 11:11:46 -0000
Received: from [192.168.100.16] (unknown [109.231.64.198])
	by mail.avalus.com (Postfix) with ESMTPSA id 9ADB8C56109;
	Wed, 23 Nov 2011 11:11:45 +0000 (GMT)
Date: Wed, 23 Nov 2011 11:11:44 +0000
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel@lists.xensource.com
Message-ID: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] Minimum python version for xen-4.1.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Does xen-4.1.1 really require python 2.7 (as per Ubuntu packaging) or
will it actually work on python 2.6? I am trying to backport it to
an Ubuntu LTS version and would rather not have to bring in Python 2.7
if possible.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:12:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:12:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAkS-00070c-U6; Wed, 23 Nov 2011 11:12:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RTAkS-0006zz-3k
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:12:16 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322046706!4285561!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30986 invoked from network); 23 Nov 2011 11:11:46 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 11:11:46 -0000
Received: from [192.168.100.16] (unknown [109.231.64.198])
	by mail.avalus.com (Postfix) with ESMTPSA id 9ADB8C56109;
	Wed, 23 Nov 2011 11:11:45 +0000 (GMT)
Date: Wed, 23 Nov 2011 11:11:44 +0000
From: Alex Bligh <alex@alex.org.uk>
To: xen-devel@lists.xensource.com
Message-ID: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: Alex Bligh <alex@alex.org.uk>
Subject: [Xen-devel] Minimum python version for xen-4.1.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Does xen-4.1.1 really require python 2.7 (as per Ubuntu packaging) or
will it actually work on python 2.6? I am trying to backport it to
an Ubuntu LTS version and would rather not have to bring in Python 2.7
if possible.

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:12:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:12:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAkW-000712-BB; Wed, 23 Nov 2011 11:12:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RTAkU-00070K-Dl
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:12:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322046707!4278496!1
X-Originating-IP: [209.85.216.50]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17741 invoked from network); 23 Nov 2011 11:11:48 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:11:48 -0000
Received: by qadb12 with SMTP id b12so1468429qad.9
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 03:11:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=RYJ3wEQ8HT0xZomhsOvtWEyw2U38DyuN8yjY+RKbVUY=;
	b=YeeRGO3FUg86w28xC9ZoqlAPk6JUTCeorUrqdnD/C9aE3SzMuvu2vijvS9aIrLqp0K
	c0vlAp7OO1Xxhzt67teN2/hRDvl869cs7aR8qRUrDoaUV0I6HDu0eK/h9ewZdcP39u7J
	Er5xd3LXH7GDSp7NzHLzVO/rl2telh0V4U/N4=
MIME-Version: 1.0
Received: by 10.68.2.138 with SMTP id 10mr7220916pbu.55.1322046705337; Wed, 23
	Nov 2011 03:11:45 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Wed, 23 Nov 2011 03:11:44 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
Date: Wed, 23 Nov 2011 12:11:44 +0100
X-Google-Sender-Auth: gHCkfmKnjn02rZvxOPSnbzUeEpM
Message-ID: <CAPLaKK6hpSPTfoQ0gxCCV5bADeSo49F2C7XVmu7TmjL58cGAbA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/23 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> Maybe it is worth documenting this somewhere, any suggestions where?

A note should be added here:
http://wiki.xen.org/xenwiki/XenBooting.html (I can't find this page on
the new wiki, but this should be migrated).

Also in the xm/xl config file and probably in the man page for xl.cfg
and xend-config.sxp.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:12:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:12:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAkW-000712-BB; Wed, 23 Nov 2011 11:12:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RTAkU-00070K-Dl
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:12:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322046707!4278496!1
X-Originating-IP: [209.85.216.50]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17741 invoked from network); 23 Nov 2011 11:11:48 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:11:48 -0000
Received: by qadb12 with SMTP id b12so1468429qad.9
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 03:11:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=RYJ3wEQ8HT0xZomhsOvtWEyw2U38DyuN8yjY+RKbVUY=;
	b=YeeRGO3FUg86w28xC9ZoqlAPk6JUTCeorUrqdnD/C9aE3SzMuvu2vijvS9aIrLqp0K
	c0vlAp7OO1Xxhzt67teN2/hRDvl869cs7aR8qRUrDoaUV0I6HDu0eK/h9ewZdcP39u7J
	Er5xd3LXH7GDSp7NzHLzVO/rl2telh0V4U/N4=
MIME-Version: 1.0
Received: by 10.68.2.138 with SMTP id 10mr7220916pbu.55.1322046705337; Wed, 23
	Nov 2011 03:11:45 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Wed, 23 Nov 2011 03:11:44 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
Date: Wed, 23 Nov 2011 12:11:44 +0100
X-Google-Sender-Auth: gHCkfmKnjn02rZvxOPSnbzUeEpM
Message-ID: <CAPLaKK6hpSPTfoQ0gxCCV5bADeSo49F2C7XVmu7TmjL58cGAbA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/23 Stefano Stabellini <stefano.stabellini@eu.citrix.com>:
> Maybe it is worth documenting this somewhere, any suggestions where?

A note should be added here:
http://wiki.xen.org/xenwiki/XenBooting.html (I can't find this page on
the new wiki, but this should be migrated).

Also in the xm/xl config file and probably in the man page for xl.cfg
and xend-config.sxp.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:15:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:15:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAnC-0007HC-UP; Wed, 23 Nov 2011 11:15:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RTAnA-0007GH-Vq
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:15:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322046874!5388393!1
X-Originating-IP: [209.85.216.50]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29172 invoked from network); 23 Nov 2011 11:14:35 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:14:35 -0000
Received: by qadb12 with SMTP id b12so1471391qad.9
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 03:14:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=lTYV7NpHYBvAGX2bHJD3y5EAbofc9kb2jRUHJCbdoe8=;
	b=hjW8qggLDDfkFZAdbtJbnxHadi3nmrVTC+T+44q96xIcNHT9eNkXVpZXboIXO666gM
	eRTUkgBUbL19byQQPOO1YW0Gsjs1kkKarTPvUSFIF50fcy25rX0Wht84ddBSviSQaTuP
	oad+n+pJiG7pUgCdZvc836YLNPlC/BXnhfBuI=
MIME-Version: 1.0
Received: by 10.68.72.36 with SMTP id a4mr7200412pbv.4.1322046873255; Wed, 23
	Nov 2011 03:14:33 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Wed, 23 Nov 2011 03:14:33 -0800 (PST)
In-Reply-To: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
References: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
Date: Wed, 23 Nov 2011 12:14:33 +0100
X-Google-Sender-Auth: KHOvDVSYEL56rzdD2GpzKDfwe6A
Message-ID: <CAPLaKK6h8Q50sJ6JUoL68VOpk70HOLeoOGFcJ1giWx=D3rjUpg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Alex Bligh <alex@alex.org.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Minimum python version for xen-4.1.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've been using it so far without any problems with Python 2.6.1 (not
on Ubuntu although).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:15:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:15:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAnC-0007HC-UP; Wed, 23 Nov 2011 11:15:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RTAnA-0007GH-Vq
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:15:05 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322046874!5388393!1
X-Originating-IP: [209.85.216.50]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29172 invoked from network); 23 Nov 2011 11:14:35 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:14:35 -0000
Received: by qadb12 with SMTP id b12so1471391qad.9
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 03:14:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=lTYV7NpHYBvAGX2bHJD3y5EAbofc9kb2jRUHJCbdoe8=;
	b=hjW8qggLDDfkFZAdbtJbnxHadi3nmrVTC+T+44q96xIcNHT9eNkXVpZXboIXO666gM
	eRTUkgBUbL19byQQPOO1YW0Gsjs1kkKarTPvUSFIF50fcy25rX0Wht84ddBSviSQaTuP
	oad+n+pJiG7pUgCdZvc836YLNPlC/BXnhfBuI=
MIME-Version: 1.0
Received: by 10.68.72.36 with SMTP id a4mr7200412pbv.4.1322046873255; Wed, 23
	Nov 2011 03:14:33 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Wed, 23 Nov 2011 03:14:33 -0800 (PST)
In-Reply-To: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
References: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
Date: Wed, 23 Nov 2011 12:14:33 +0100
X-Google-Sender-Auth: KHOvDVSYEL56rzdD2GpzKDfwe6A
Message-ID: <CAPLaKK6h8Q50sJ6JUoL68VOpk70HOLeoOGFcJ1giWx=D3rjUpg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Alex Bligh <alex@alex.org.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Minimum python version for xen-4.1.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've been using it so far without any problems with Python 2.6.1 (not
on Ubuntu although).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:19:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:19:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAqv-0007Ux-KR; Wed, 23 Nov 2011 11:18:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTAqu-0007Uo-3I
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:18:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322047106!4265253!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5678 invoked from network); 23 Nov 2011 11:18:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:18:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9085183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:18:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:18:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Date: Wed, 23 Nov 2011 11:18:25 +0000
In-Reply-To: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
References: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322047105.1005.69.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Minimum python version for xen-4.1.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 11:11 +0000, Alex Bligh wrote:
> Does xen-4.1.1 really require python 2.7 (as per Ubuntu packaging) or
> will it actually work on python 2.6? I am trying to backport it to
> an Ubuntu LTS version and would rather not have to bring in Python 2.7
> if possible.

The README says 2.3 or later. I don't think we rely on 2.7 specifically
and we would take patches to fix it for earlier versions as necessary
(although perhaps we would bump the 2.3 to e.g. 2.4 or 2.5 if that
turned out to be easier, depends on the prevalence of 2.4+ in distro
stable releases).

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:19:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:19:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAqv-0007Ux-KR; Wed, 23 Nov 2011 11:18:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTAqu-0007Uo-3I
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:18:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322047106!4265253!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5678 invoked from network); 23 Nov 2011 11:18:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:18:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9085183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:18:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:18:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Alex Bligh <alex@alex.org.uk>
Date: Wed, 23 Nov 2011 11:18:25 +0000
In-Reply-To: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
References: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322047105.1005.69.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Minimum python version for xen-4.1.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 11:11 +0000, Alex Bligh wrote:
> Does xen-4.1.1 really require python 2.7 (as per Ubuntu packaging) or
> will it actually work on python 2.6? I am trying to backport it to
> an Ubuntu LTS version and would rather not have to bring in Python 2.7
> if possible.

The README says 2.3 or later. I don't think we rely on 2.7 specifically
and we would take patches to fix it for earlier versions as necessary
(although perhaps we would bump the 2.3 to e.g. 2.4 or 2.5 if that
turned out to be easier, depends on the prevalence of 2.4+ in distro
stable releases).

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:20:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTArm-0007YQ-2i; Wed, 23 Nov 2011 11:19:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTArl-0007YG-5Y
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:19:49 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322047135!49598965!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7690 invoked from network); 23 Nov 2011 11:18:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:18:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9085279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:19:24 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 23 Nov 2011
	11:19:24 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 11:19:31 +0000
Thread-Topic: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
	control/shutdown key is removed
Thread-Index: AcypyHKEEN/euYZ/T6yuzcmhiSLotQACM0bA
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322043166.1005.27.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 23 November 2011 10:13
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting
> when control/shutdown key is removed
> 
> On Wed, 2011-11-23 at 09:45 +0000, Paul Durrant wrote:
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1322041530 0
> #
> > Node ID 3341e3e990568f459ae984cd9d2cac2d546eaa4e
> > # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> > Prevent xl save from segfaulting when control/shutdown key is
> removed
> >
> > To acknowledge the tools' setting of control/shutdown it is normal
> for
> > PV drivers to rm the key. This leads to libxl__xs_read() returning
> > NULL and thus a subsequent strcmp on the return value will cause a
> segfault.
> 
> The Linux PV drivers actually write "" rather than removing the key
> which is how this didn't get spotted already. We should be robust to
> PV drivers which remove it as well.
> 
> At start of day .../control is created ro (to the guest) whereas
> .../control/shutdown is created rw. Can you confirm that a second
> operation still succeeds if the guest rm's the node on the first
> action?
> 

At the moment I can't. I'm getting a complete VM wedge-up on restore somewhere in the region of re-connecting to store. I'll check the subsequent suspend behaviour once I can get the Vm to actually come back.
BTW what is the reason for creating control ro to the guest? In XenServer we allow the guest to write the control key to advertise feature-shutdown, feature-suspend etc. so that the tools know what values of control/shutdown the guest will respond to.

  Paul

> My concern is that while the first time the round the node will be
> rw the second time round the write will actually re-create the node
> (without setting the permissions) which might result in the node
> being ro for the guest (xenstore perms confuse me, but I think new
> nodes inherit the parent permissions).
> 
> That's assuming there's any chance of a second operation. I'm
> thinking of a wedged reboot followed by an attempt to shutdown
> instead or something like that. Perhaps in practice that wouldn't
> work anyway.
> 
> Apart form the above this change improves the robustness of the code
> so:
> 
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> 
> 
> >
> > diff -r 0a0c02a61676 -r 3341e3e99056 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c	Mon Nov 21 21:28:34 2011 +0000
> > +++ b/tools/libxl/libxl_dom.c	Wed Nov 23 09:45:30 2011 +0000
> > @@ -444,6 +444,7 @@ static int libxl__domain_suspend_common_
> >              usleep(100000);
> >
> >              state = libxl__xs_read(si->gc, XBT_NULL, path);
> > +            if (!state) state = "";
> >
> >              watchdog--;
> >          }
> > @@ -463,6 +464,7 @@ static int libxl__domain_suspend_common_
> >              t = xs_transaction_start(ctx->xsh);
> >
> >              state = libxl__xs_read(si->gc, t, path);
> > +            if (!state) state = "";
> >
> >              if (!strcmp(state, "suspend"))
> >                  libxl__xs_write(si->gc, t, path, "");
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:20:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:20:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTArm-0007YQ-2i; Wed, 23 Nov 2011 11:19:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTArl-0007YG-5Y
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:19:49 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322047135!49598965!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7690 invoked from network); 23 Nov 2011 11:18:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:18:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9085279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:19:24 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 23 Nov 2011
	11:19:24 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 11:19:31 +0000
Thread-Topic: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
	control/shutdown key is removed
Thread-Index: AcypyHKEEN/euYZ/T6yuzcmhiSLotQACM0bA
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322043166.1005.27.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 23 November 2011 10:13
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting
> when control/shutdown key is removed
> 
> On Wed, 2011-11-23 at 09:45 +0000, Paul Durrant wrote:
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1322041530 0
> #
> > Node ID 3341e3e990568f459ae984cd9d2cac2d546eaa4e
> > # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> > Prevent xl save from segfaulting when control/shutdown key is
> removed
> >
> > To acknowledge the tools' setting of control/shutdown it is normal
> for
> > PV drivers to rm the key. This leads to libxl__xs_read() returning
> > NULL and thus a subsequent strcmp on the return value will cause a
> segfault.
> 
> The Linux PV drivers actually write "" rather than removing the key
> which is how this didn't get spotted already. We should be robust to
> PV drivers which remove it as well.
> 
> At start of day .../control is created ro (to the guest) whereas
> .../control/shutdown is created rw. Can you confirm that a second
> operation still succeeds if the guest rm's the node on the first
> action?
> 

At the moment I can't. I'm getting a complete VM wedge-up on restore somewhere in the region of re-connecting to store. I'll check the subsequent suspend behaviour once I can get the Vm to actually come back.
BTW what is the reason for creating control ro to the guest? In XenServer we allow the guest to write the control key to advertise feature-shutdown, feature-suspend etc. so that the tools know what values of control/shutdown the guest will respond to.

  Paul

> My concern is that while the first time the round the node will be
> rw the second time round the write will actually re-create the node
> (without setting the permissions) which might result in the node
> being ro for the guest (xenstore perms confuse me, but I think new
> nodes inherit the parent permissions).
> 
> That's assuming there's any chance of a second operation. I'm
> thinking of a wedged reboot followed by an attempt to shutdown
> instead or something like that. Perhaps in practice that wouldn't
> work anyway.
> 
> Apart form the above this change improves the robustness of the code
> so:
> 
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> 
> 
> >
> > diff -r 0a0c02a61676 -r 3341e3e99056 tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c	Mon Nov 21 21:28:34 2011 +0000
> > +++ b/tools/libxl/libxl_dom.c	Wed Nov 23 09:45:30 2011 +0000
> > @@ -444,6 +444,7 @@ static int libxl__domain_suspend_common_
> >              usleep(100000);
> >
> >              state = libxl__xs_read(si->gc, XBT_NULL, path);
> > +            if (!state) state = "";
> >
> >              watchdog--;
> >          }
> > @@ -463,6 +464,7 @@ static int libxl__domain_suspend_common_
> >              t = xs_transaction_start(ctx->xsh);
> >
> >              state = libxl__xs_read(si->gc, t, path);
> > +            if (!state) state = "";
> >
> >              if (!strcmp(state, "suspend"))
> >                  libxl__xs_write(si->gc, t, path, "");
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:23:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:23:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAvI-0007oc-Sc; Wed, 23 Nov 2011 11:23:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTAvH-0007oJ-H9
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:23:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322047377!4673550!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12469 invoked from network); 23 Nov 2011 11:22:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:22:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9085631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:22:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 11:22:57 +0000
Date: Wed, 23 Nov 2011 11:23:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322046437.1005.62.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk> 
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com> 
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-90971075-1322047440=:31179"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-90971075-1322047440=:31179
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Wed, 23 Nov 2011, Ian Campbell wrote:
> On Wed, 2011-11-23 at 10:56 +0000, Stefano Stabellini wrote:
> > On Tue, 22 Nov 2011, Teck Choon Giam wrote:
> > > >> >> That means default value changed if it is unset for autoballoon?
> > > >> >> Original one is commented with #autoballoon = 1 in /etc/xen/xl.conf so
> > > >> >> it is unset I guess so the default value for autoballoon for c/s 23110
> > > >> >> is autoballoon=0 where c/s 23190 is autoballoon=1? � Just some
> > > >> >> guessing... ...
> > > >
> > > > Autoballoon and dom0_mem are incompatible.
> > > > I don't think there are any relevant differences between 23110 and 23190
> > > > on xen-unstable, maybe you used to start dom0 without dom0_mem before?
> > > 
> > > Nope... all my servers will always have those dom0_mem set.  It is
> > > from xen-4.1-testing not xen-unstable for the two changeset.
> > 
> > I still cannot see anything in that range. However as I said before, it
> > is expected that with dom0_mem set autoballoon needs to be disabled.
> 
> We still haven't seen the full node IDs of the changesets which I asked
> for so it is not obvious that we are actually looking at the same range
> of changesets...
> 
> > Maybe it is worth documenting this somewhere, any suggestions where?
> 
> xl man page? Perhaps we also need a separate /etc/xl.cfg (or whatever
> the path is) page?
> 
> If there is anywhere on the wiki which recommends dom0_mem= (and there
> should be) it should simultaneously mention this setting. As should any
> "getting started" page.
> 
> On the other hand I'm not sure why autoballoon and dom0_mem play so
> badly together. Surely if dom0_mem is used autoballon should just see
> that there is plenty of free RAM in the system and not do anything?
 
Because one of the "memory slack" paramters needed by autoballoon is

totalmemory - dom0_memory_at_boot

fortunately libxl is smart enough to trim it to 15% of the total memory
of the system, just in case a user forgot to disable autoballon but set
dom0_mem.
Ah! Now that you make me think about it, I bet the failure comes from a
system that is missing:

libxl: Introduce a maximum limit for free_mem_slack (re (dom0) ballooning)
    
    This fixes this message:
     libxl: error: libxl.c:2921:libxl_set_memory_target new target
                   for dom0 is below the minimum threshold
    which can occur spuriously if dom0_mem is specified and xl
    autoballoning is left turned on.
--8323329-90971075-1322047440=:31179
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-90971075-1322047440=:31179--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:23:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:23:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAvI-0007oc-Sc; Wed, 23 Nov 2011 11:23:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTAvH-0007oJ-H9
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:23:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322047377!4673550!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12469 invoked from network); 23 Nov 2011 11:22:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:22:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9085631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:22:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 11:22:57 +0000
Date: Wed, 23 Nov 2011 11:23:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322046437.1005.62.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk> 
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com> 
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-90971075-1322047440=:31179"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-90971075-1322047440=:31179
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Wed, 23 Nov 2011, Ian Campbell wrote:
> On Wed, 2011-11-23 at 10:56 +0000, Stefano Stabellini wrote:
> > On Tue, 22 Nov 2011, Teck Choon Giam wrote:
> > > >> >> That means default value changed if it is unset for autoballoon?
> > > >> >> Original one is commented with #autoballoon = 1 in /etc/xen/xl.conf so
> > > >> >> it is unset I guess so the default value for autoballoon for c/s 23110
> > > >> >> is autoballoon=0 where c/s 23190 is autoballoon=1? � Just some
> > > >> >> guessing... ...
> > > >
> > > > Autoballoon and dom0_mem are incompatible.
> > > > I don't think there are any relevant differences between 23110 and 23190
> > > > on xen-unstable, maybe you used to start dom0 without dom0_mem before?
> > > 
> > > Nope... all my servers will always have those dom0_mem set.  It is
> > > from xen-4.1-testing not xen-unstable for the two changeset.
> > 
> > I still cannot see anything in that range. However as I said before, it
> > is expected that with dom0_mem set autoballoon needs to be disabled.
> 
> We still haven't seen the full node IDs of the changesets which I asked
> for so it is not obvious that we are actually looking at the same range
> of changesets...
> 
> > Maybe it is worth documenting this somewhere, any suggestions where?
> 
> xl man page? Perhaps we also need a separate /etc/xl.cfg (or whatever
> the path is) page?
> 
> If there is anywhere on the wiki which recommends dom0_mem= (and there
> should be) it should simultaneously mention this setting. As should any
> "getting started" page.
> 
> On the other hand I'm not sure why autoballoon and dom0_mem play so
> badly together. Surely if dom0_mem is used autoballon should just see
> that there is plenty of free RAM in the system and not do anything?
 
Because one of the "memory slack" paramters needed by autoballoon is

totalmemory - dom0_memory_at_boot

fortunately libxl is smart enough to trim it to 15% of the total memory
of the system, just in case a user forgot to disable autoballon but set
dom0_mem.
Ah! Now that you make me think about it, I bet the failure comes from a
system that is missing:

libxl: Introduce a maximum limit for free_mem_slack (re (dom0) ballooning)
    
    This fixes this message:
     libxl: error: libxl.c:2921:libxl_set_memory_target new target
                   for dom0 is below the minimum threshold
    which can occur spuriously if dom0_mem is specified and xl
    autoballoning is left turned on.
--8323329-90971075-1322047440=:31179
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-90971075-1322047440=:31179--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:24:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAvz-0007s8-A8; Wed, 23 Nov 2011 11:24:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTAvy-0007rM-0F
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:24:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322047420!4266134!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26036 invoked from network); 23 Nov 2011 11:23:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:23:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9085715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:23:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:23:39 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 23 Nov 2011 11:23:39 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322047419.1005.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 11:19 +0000, Paul Durrant wrote:
> what is the reason for creating control ro to the guest?

In general libxl prefers to whitelist paths which the guest can write
too, just to prevent a complete free for all, keep things somewhat under
control and to help avoid situations where tools might inadvertently
rely on a guest-writeable key in an unsafe way..

>  In XenServer we allow the guest to write the control key to advertise
> feature-shutdown, feature-suspend etc. so that the tools know what
> values of control/shutdown the guest will respond to.

The libxl way would be to create these at build time (perhaps empty)
with the appropriate permissions.

It's not clear how that functionality can be added in a way which is
compatible with existing guests though, e.g. no Linux guest writes those
but many can be suspended etc.

Ian.

> 
>   Paul
> 
> > My concern is that while the first time the round the node will be
> > rw the second time round the write will actually re-create the node
> > (without setting the permissions) which might result in the node
> > being ro for the guest (xenstore perms confuse me, but I think new
> > nodes inherit the parent permissions).
> > 
> > That's assuming there's any chance of a second operation. I'm
> > thinking of a wedged reboot followed by an attempt to shutdown
> > instead or something like that. Perhaps in practice that wouldn't
> > work anyway.
> > 
> > Apart form the above this change improves the robustness of the code
> > so:
> > 
> > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > 
> > 
> > >
> > > diff -r 0a0c02a61676 -r 3341e3e99056 tools/libxl/libxl_dom.c
> > > --- a/tools/libxl/libxl_dom.c	Mon Nov 21 21:28:34 2011 +0000
> > > +++ b/tools/libxl/libxl_dom.c	Wed Nov 23 09:45:30 2011 +0000
> > > @@ -444,6 +444,7 @@ static int libxl__domain_suspend_common_
> > >              usleep(100000);
> > >
> > >              state = libxl__xs_read(si->gc, XBT_NULL, path);
> > > +            if (!state) state = "";
> > >
> > >              watchdog--;
> > >          }
> > > @@ -463,6 +464,7 @@ static int libxl__domain_suspend_common_
> > >              t = xs_transaction_start(ctx->xsh);
> > >
> > >              state = libxl__xs_read(si->gc, t, path);
> > > +            if (!state) state = "";
> > >
> > >              if (!strcmp(state, "suspend"))
> > >                  libxl__xs_write(si->gc, t, path, "");
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:24:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTAvz-0007s8-A8; Wed, 23 Nov 2011 11:24:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTAvy-0007rM-0F
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:24:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322047420!4266134!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26036 invoked from network); 23 Nov 2011 11:23:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:23:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9085715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:23:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:23:39 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 23 Nov 2011 11:23:39 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322047419.1005.72.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 11:19 +0000, Paul Durrant wrote:
> what is the reason for creating control ro to the guest?

In general libxl prefers to whitelist paths which the guest can write
too, just to prevent a complete free for all, keep things somewhat under
control and to help avoid situations where tools might inadvertently
rely on a guest-writeable key in an unsafe way..

>  In XenServer we allow the guest to write the control key to advertise
> feature-shutdown, feature-suspend etc. so that the tools know what
> values of control/shutdown the guest will respond to.

The libxl way would be to create these at build time (perhaps empty)
with the appropriate permissions.

It's not clear how that functionality can be added in a way which is
compatible with existing guests though, e.g. no Linux guest writes those
but many can be suspended etc.

Ian.

> 
>   Paul
> 
> > My concern is that while the first time the round the node will be
> > rw the second time round the write will actually re-create the node
> > (without setting the permissions) which might result in the node
> > being ro for the guest (xenstore perms confuse me, but I think new
> > nodes inherit the parent permissions).
> > 
> > That's assuming there's any chance of a second operation. I'm
> > thinking of a wedged reboot followed by an attempt to shutdown
> > instead or something like that. Perhaps in practice that wouldn't
> > work anyway.
> > 
> > Apart form the above this change improves the robustness of the code
> > so:
> > 
> > > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > 
> > 
> > >
> > > diff -r 0a0c02a61676 -r 3341e3e99056 tools/libxl/libxl_dom.c
> > > --- a/tools/libxl/libxl_dom.c	Mon Nov 21 21:28:34 2011 +0000
> > > +++ b/tools/libxl/libxl_dom.c	Wed Nov 23 09:45:30 2011 +0000
> > > @@ -444,6 +444,7 @@ static int libxl__domain_suspend_common_
> > >              usleep(100000);
> > >
> > >              state = libxl__xs_read(si->gc, XBT_NULL, path);
> > > +            if (!state) state = "";
> > >
> > >              watchdog--;
> > >          }
> > > @@ -463,6 +464,7 @@ static int libxl__domain_suspend_common_
> > >              t = xs_transaction_start(ctx->xsh);
> > >
> > >              state = libxl__xs_read(si->gc, t, path);
> > > +            if (!state) state = "";
> > >
> > >              if (!strcmp(state, "suspend"))
> > >                  libxl__xs_write(si->gc, t, path, "");
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:30:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:30:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTB2C-0008EF-CH; Wed, 23 Nov 2011 11:30:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RTB2A-0008DR-M2
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:30:34 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322047803!4648601!1
X-Originating-IP: [209.85.216.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12232 invoked from network); 23 Nov 2011 11:30:04 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:30:04 -0000
Received: by qadz2 with SMTP id z2so43447qad.9
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 03:30:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=bnJI6ZmwY3qAMrEVDWJCJKBYEa85atdU3cT2F7LP3zk=;
	b=XpxfXWJXGXH1zkUfltdqkpZFpirz+9AnLiRqJ8d23x64YfWAK1PxykgIFPsqtQ2Lcx
	Ows+Fchm8Owyxii2YWz3sFGFOg3RhjEIAExLeA/dCs8/Xlt0ItmtqEVxSVaeGxFKjweU
	03yvYZoiIGpxsGCgL6x1bt5Y1U0He7a/tjHzg=
MIME-Version: 1.0
Received: by 10.68.22.228 with SMTP id h4mr7399414pbf.10.1322047803212; Wed,
	23 Nov 2011 03:30:03 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Wed, 23 Nov 2011 03:30:03 -0800 (PST)
In-Reply-To: <1322046437.1005.62.camel@zakaz.uk.xensource.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
Date: Wed, 23 Nov 2011 19:30:03 +0800
Message-ID: <CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBOb3YgMjMsIDIwMTEgYXQgNzowNyBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gT24gV2VkLCAyMDExLTExLTIzIGF0IDEwOjU2ICswMDAw
LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6Cj4+IE9uIFR1ZSwgMjIgTm92IDIwMTEsIFRlY2sg
Q2hvb24gR2lhbSB3cm90ZToKPj4gPiA+PiA+PiBUaGF0IG1lYW5zIGRlZmF1bHQgdmFsdWUgY2hh
bmdlZCBpZiBpdCBpcyB1bnNldCBmb3IgYXV0b2JhbGxvb24/Cj4+ID4gPj4gPj4gT3JpZ2luYWwg
b25lIGlzIGNvbW1lbnRlZCB3aXRoICNhdXRvYmFsbG9vbiA9IDEgaW4gL2V0Yy94ZW4veGwuY29u
ZiBzbwo+PiA+ID4+ID4+IGl0IGlzIHVuc2V0IEkgZ3Vlc3Mgc28gdGhlIGRlZmF1bHQgdmFsdWUg
Zm9yIGF1dG9iYWxsb29uIGZvciBjL3MgMjMxMTAKPj4gPiA+PiA+PiBpcyBhdXRvYmFsbG9vbj0w
IHdoZXJlIGMvcyAyMzE5MCBpcyBhdXRvYmFsbG9vbj0xPyDDg8aSP8OD4oCaw4IgSnVzdCBzb21l
Cj4+ID4gPj4gPj4gZ3Vlc3NpbmcuLi4gLi4uCj4+ID4gPgo+PiA+ID4gQXV0b2JhbGxvb24gYW5k
IGRvbTBfbWVtIGFyZSBpbmNvbXBhdGlibGUuCj4+ID4gPiBJIGRvbid0IHRoaW5rIHRoZXJlIGFy
ZSBhbnkgcmVsZXZhbnQgZGlmZmVyZW5jZXMgYmV0d2VlbiAyMzExMCBhbmQgMjMxOTAKPj4gPiA+
IG9uIHhlbi11bnN0YWJsZSwgbWF5YmUgeW91IHVzZWQgdG8gc3RhcnQgZG9tMCB3aXRob3V0IGRv
bTBfbWVtIGJlZm9yZT8KPj4gPgo+PiA+IE5vcGUuLi4gYWxsIG15IHNlcnZlcnMgd2lsbCBhbHdh
eXMgaGF2ZSB0aG9zZSBkb20wX21lbSBzZXQuIMKgSXQgaXMKPj4gPiBmcm9tIHhlbi00LjEtdGVz
dGluZyBub3QgeGVuLXVuc3RhYmxlIGZvciB0aGUgdHdvIGNoYW5nZXNldC4KPj4KPj4gSSBzdGls
bCBjYW5ub3Qgc2VlIGFueXRoaW5nIGluIHRoYXQgcmFuZ2UuIEhvd2V2ZXIgYXMgSSBzYWlkIGJl
Zm9yZSwgaXQKPj4gaXMgZXhwZWN0ZWQgdGhhdCB3aXRoIGRvbTBfbWVtIHNldCBhdXRvYmFsbG9v
biBuZWVkcyB0byBiZSBkaXNhYmxlZC4KPgo+IFdlIHN0aWxsIGhhdmVuJ3Qgc2VlbiB0aGUgZnVs
bCBub2RlIElEcyBvZiB0aGUgY2hhbmdlc2V0cyB3aGljaCBJIGFza2VkCj4gZm9yIHNvIGl0IGlz
IG5vdCBvYnZpb3VzIHRoYXQgd2UgYXJlIGFjdHVhbGx5IGxvb2tpbmcgYXQgdGhlIHNhbWUgcmFu
Z2UKPiBvZiBjaGFuZ2VzZXRzLi4uCgpTb3JyeSwgSSBhbSBhY3R1YWxseSBub3Qgc3VyZSB3aGF0
IElEIHlvdSBhcmUgYXNraW5nIDooCgpDaGFuZ2VzZXRzIGRldGFpbHMgYXMgYmVsb3c6CgpjaGFu
Z2VzZXQ6ICAgMjMxMTA6NGQ1Yzc2MjQ4ZGUzCnVzZXI6ICAgICAgICBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PgpkYXRlOiAgICAgICAgU2F0IEp1bCAyMyAwOTowMToy
NSAyMDExICswMTAwCnN1bW1hcnk6ICAgICB4ZW5kOiByZW1vdmUgUENJIGRldmljZSBsaXN0aW5n
IGZyb20gTmV0QlNELCBzaW5jZSBpdCdzIExpbnV4CgpjaGFuZ2VzZXQ6ICAgMjMxOTA6NWEwMGNj
ZmM2MzkxCnVzZXI6ICAgICAgICBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGlu
aUBldS5jaXRyaXguY29tPgpkYXRlOiAgICAgICAgRnJpIE5vdiAxOCAxMzozODowNSAyMDExICsw
MDAwCnN1bW1hcnk6ICAgICB4ODY6IHJlLWluamVjdCBlbXVsYXRlZCBsZXZlbCBwaXJxcyBpbiBQ
ViBvbiBIVk0gZ3Vlc3RzCmlmIHN0aWxsIGFzc2VydGVkCgoKPgo+PiBNYXliZSBpdCBpcyB3b3J0
aCBkb2N1bWVudGluZyB0aGlzIHNvbWV3aGVyZSwgYW55IHN1Z2dlc3Rpb25zIHdoZXJlPwo+Cj4g
eGwgbWFuIHBhZ2U/IFBlcmhhcHMgd2UgYWxzbyBuZWVkIGEgc2VwYXJhdGUgL2V0Yy94bC5jZmcg
KG9yIHdoYXRldmVyCj4gdGhlIHBhdGggaXMpIHBhZ2U/CgpTaG91bGRuJ3QgaXQgYmUgeGwuY29u
ZiBpbnN0ZWFkIG9mIHhsLmNmZz8gIHhsIG1hbiBwYWdlIHdpbGwgaGVscHMgYQpsb3QgZXNwZWNp
YWxseSBmb3IgdGhvc2Ugb2YgdXMgc3dpdGNoaW5nIGZyb20geG0gdG8geGwuCgo+Cj4gSWYgdGhl
cmUgaXMgYW55d2hlcmUgb24gdGhlIHdpa2kgd2hpY2ggcmVjb21tZW5kcyBkb20wX21lbT0gKGFu
ZCB0aGVyZQo+IHNob3VsZCBiZSkgaXQgc2hvdWxkIHNpbXVsdGFuZW91c2x5IG1lbnRpb24gdGhp
cyBzZXR0aW5nLiBBcyBzaG91bGQgYW55Cj4gImdldHRpbmcgc3RhcnRlZCIgcGFnZS4KPgo+IE9u
IHRoZSBvdGhlciBoYW5kIEknbSBub3Qgc3VyZSB3aHkgYXV0b2JhbGxvb24gYW5kIGRvbTBfbWVt
IHBsYXkgc28KPiBiYWRseSB0b2dldGhlci4gU3VyZWx5IGlmIGRvbTBfbWVtIGlzIHVzZWQgYXV0
b2JhbGxvbiBzaG91bGQganVzdCBzZWUKPiB0aGF0IHRoZXJlIGlzIHBsZW50eSBvZiBmcmVlIFJB
TSBpbiB0aGUgc3lzdGVtIGFuZCBub3QgZG8gYW55dGhpbmc/Cj4KPiBJYW4uCgpGcm9tIHRoaXMg
ZXhwZXJpZW5jZSwgYXQgbGVhc3QgSSBsZWFybiBtb3JlIGFib3V0IHhsIGFuZCB3aGF0CmNvbmZp
Z3VyYXRpb24gc2hvdWxkIGJlIHNldCBmb3IgbXkgdXNhZ2UvZW52aXJvbm1lbnQuICBMaWtlIGZv
cgpleGFtcGxlLCB3aGVuIEkgdXNlZCB4bCBjcmVhdGUgaHZtZG9tYWluLi4uIHRob3NlIGlwdGFi
bGVzIGZvcndhcmQKcnVsZSBjaGFpbnMgYXJlIGNyZWF0ZWQgYXMgd2VsbCBmb3IgaXRzIHZpZiBh
bmQgdGFwIGJ1dCB3aGVuIHhsCnRyaWdnZXIgaHZtZG9tYWluIHBvd2VyIG9yIHhsIHNodXRkb3du
IGh2bWRvbWFpbi4uLiB0aG9zZSBpcHRhYmxlcwpmb3J3YXJkIHJ1bGUgY2hhaW5zIGFyZSBzdGls
bCBsZWZ0IGludGFjdCA6KCAgVGhpcyBpc24ndCBiaWcgaXNzdWUgZm9yCm1lIGFzIEkgaGF2ZSBj
cmVhdGVkIHNjcmlwdCB0byByZW1vdmUgdGhvc2UgdGhvdWdoLiAgQW55d2F5LCBJIHdpbGwKYnJp
bmcgdGhpcyB1cCB3aGVuIHlvdSBndXlzIGdvaW5nIHRvIHJlbGVhc2UgeGVuLTQuMi1yYy4uLiAu
Li4gYXMgdGhpcwp0aHJlYWQgaXMgbm90IGZvciBtZSBJIGtub3cuCgpUaGFua3MgYWxsIDspCgpL
aW5kZXN0IHJlZ2FyZHMsCkdpYW0gVGVjayBDaG9vbgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:30:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:30:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTB2C-0008EF-CH; Wed, 23 Nov 2011 11:30:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RTB2A-0008DR-M2
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:30:34 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322047803!4648601!1
X-Originating-IP: [209.85.216.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12232 invoked from network); 23 Nov 2011 11:30:04 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:30:04 -0000
Received: by qadz2 with SMTP id z2so43447qad.9
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 03:30:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=bnJI6ZmwY3qAMrEVDWJCJKBYEa85atdU3cT2F7LP3zk=;
	b=XpxfXWJXGXH1zkUfltdqkpZFpirz+9AnLiRqJ8d23x64YfWAK1PxykgIFPsqtQ2Lcx
	Ows+Fchm8Owyxii2YWz3sFGFOg3RhjEIAExLeA/dCs8/Xlt0ItmtqEVxSVaeGxFKjweU
	03yvYZoiIGpxsGCgL6x1bt5Y1U0He7a/tjHzg=
MIME-Version: 1.0
Received: by 10.68.22.228 with SMTP id h4mr7399414pbf.10.1322047803212; Wed,
	23 Nov 2011 03:30:03 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Wed, 23 Nov 2011 03:30:03 -0800 (PST)
In-Reply-To: <1322046437.1005.62.camel@zakaz.uk.xensource.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
Date: Wed, 23 Nov 2011 19:30:03 +0800
Message-ID: <CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBOb3YgMjMsIDIwMTEgYXQgNzowNyBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gT24gV2VkLCAyMDExLTExLTIzIGF0IDEwOjU2ICswMDAw
LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6Cj4+IE9uIFR1ZSwgMjIgTm92IDIwMTEsIFRlY2sg
Q2hvb24gR2lhbSB3cm90ZToKPj4gPiA+PiA+PiBUaGF0IG1lYW5zIGRlZmF1bHQgdmFsdWUgY2hh
bmdlZCBpZiBpdCBpcyB1bnNldCBmb3IgYXV0b2JhbGxvb24/Cj4+ID4gPj4gPj4gT3JpZ2luYWwg
b25lIGlzIGNvbW1lbnRlZCB3aXRoICNhdXRvYmFsbG9vbiA9IDEgaW4gL2V0Yy94ZW4veGwuY29u
ZiBzbwo+PiA+ID4+ID4+IGl0IGlzIHVuc2V0IEkgZ3Vlc3Mgc28gdGhlIGRlZmF1bHQgdmFsdWUg
Zm9yIGF1dG9iYWxsb29uIGZvciBjL3MgMjMxMTAKPj4gPiA+PiA+PiBpcyBhdXRvYmFsbG9vbj0w
IHdoZXJlIGMvcyAyMzE5MCBpcyBhdXRvYmFsbG9vbj0xPyDDg8aSP8OD4oCaw4IgSnVzdCBzb21l
Cj4+ID4gPj4gPj4gZ3Vlc3NpbmcuLi4gLi4uCj4+ID4gPgo+PiA+ID4gQXV0b2JhbGxvb24gYW5k
IGRvbTBfbWVtIGFyZSBpbmNvbXBhdGlibGUuCj4+ID4gPiBJIGRvbid0IHRoaW5rIHRoZXJlIGFy
ZSBhbnkgcmVsZXZhbnQgZGlmZmVyZW5jZXMgYmV0d2VlbiAyMzExMCBhbmQgMjMxOTAKPj4gPiA+
IG9uIHhlbi11bnN0YWJsZSwgbWF5YmUgeW91IHVzZWQgdG8gc3RhcnQgZG9tMCB3aXRob3V0IGRv
bTBfbWVtIGJlZm9yZT8KPj4gPgo+PiA+IE5vcGUuLi4gYWxsIG15IHNlcnZlcnMgd2lsbCBhbHdh
eXMgaGF2ZSB0aG9zZSBkb20wX21lbSBzZXQuIMKgSXQgaXMKPj4gPiBmcm9tIHhlbi00LjEtdGVz
dGluZyBub3QgeGVuLXVuc3RhYmxlIGZvciB0aGUgdHdvIGNoYW5nZXNldC4KPj4KPj4gSSBzdGls
bCBjYW5ub3Qgc2VlIGFueXRoaW5nIGluIHRoYXQgcmFuZ2UuIEhvd2V2ZXIgYXMgSSBzYWlkIGJl
Zm9yZSwgaXQKPj4gaXMgZXhwZWN0ZWQgdGhhdCB3aXRoIGRvbTBfbWVtIHNldCBhdXRvYmFsbG9v
biBuZWVkcyB0byBiZSBkaXNhYmxlZC4KPgo+IFdlIHN0aWxsIGhhdmVuJ3Qgc2VlbiB0aGUgZnVs
bCBub2RlIElEcyBvZiB0aGUgY2hhbmdlc2V0cyB3aGljaCBJIGFza2VkCj4gZm9yIHNvIGl0IGlz
IG5vdCBvYnZpb3VzIHRoYXQgd2UgYXJlIGFjdHVhbGx5IGxvb2tpbmcgYXQgdGhlIHNhbWUgcmFu
Z2UKPiBvZiBjaGFuZ2VzZXRzLi4uCgpTb3JyeSwgSSBhbSBhY3R1YWxseSBub3Qgc3VyZSB3aGF0
IElEIHlvdSBhcmUgYXNraW5nIDooCgpDaGFuZ2VzZXRzIGRldGFpbHMgYXMgYmVsb3c6CgpjaGFu
Z2VzZXQ6ICAgMjMxMTA6NGQ1Yzc2MjQ4ZGUzCnVzZXI6ICAgICAgICBSb2dlciBQYXUgTW9ubmUg
PHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PgpkYXRlOiAgICAgICAgU2F0IEp1bCAyMyAwOTowMToy
NSAyMDExICswMTAwCnN1bW1hcnk6ICAgICB4ZW5kOiByZW1vdmUgUENJIGRldmljZSBsaXN0aW5n
IGZyb20gTmV0QlNELCBzaW5jZSBpdCdzIExpbnV4CgpjaGFuZ2VzZXQ6ICAgMjMxOTA6NWEwMGNj
ZmM2MzkxCnVzZXI6ICAgICAgICBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGlu
aUBldS5jaXRyaXguY29tPgpkYXRlOiAgICAgICAgRnJpIE5vdiAxOCAxMzozODowNSAyMDExICsw
MDAwCnN1bW1hcnk6ICAgICB4ODY6IHJlLWluamVjdCBlbXVsYXRlZCBsZXZlbCBwaXJxcyBpbiBQ
ViBvbiBIVk0gZ3Vlc3RzCmlmIHN0aWxsIGFzc2VydGVkCgoKPgo+PiBNYXliZSBpdCBpcyB3b3J0
aCBkb2N1bWVudGluZyB0aGlzIHNvbWV3aGVyZSwgYW55IHN1Z2dlc3Rpb25zIHdoZXJlPwo+Cj4g
eGwgbWFuIHBhZ2U/IFBlcmhhcHMgd2UgYWxzbyBuZWVkIGEgc2VwYXJhdGUgL2V0Yy94bC5jZmcg
KG9yIHdoYXRldmVyCj4gdGhlIHBhdGggaXMpIHBhZ2U/CgpTaG91bGRuJ3QgaXQgYmUgeGwuY29u
ZiBpbnN0ZWFkIG9mIHhsLmNmZz8gIHhsIG1hbiBwYWdlIHdpbGwgaGVscHMgYQpsb3QgZXNwZWNp
YWxseSBmb3IgdGhvc2Ugb2YgdXMgc3dpdGNoaW5nIGZyb20geG0gdG8geGwuCgo+Cj4gSWYgdGhl
cmUgaXMgYW55d2hlcmUgb24gdGhlIHdpa2kgd2hpY2ggcmVjb21tZW5kcyBkb20wX21lbT0gKGFu
ZCB0aGVyZQo+IHNob3VsZCBiZSkgaXQgc2hvdWxkIHNpbXVsdGFuZW91c2x5IG1lbnRpb24gdGhp
cyBzZXR0aW5nLiBBcyBzaG91bGQgYW55Cj4gImdldHRpbmcgc3RhcnRlZCIgcGFnZS4KPgo+IE9u
IHRoZSBvdGhlciBoYW5kIEknbSBub3Qgc3VyZSB3aHkgYXV0b2JhbGxvb24gYW5kIGRvbTBfbWVt
IHBsYXkgc28KPiBiYWRseSB0b2dldGhlci4gU3VyZWx5IGlmIGRvbTBfbWVtIGlzIHVzZWQgYXV0
b2JhbGxvbiBzaG91bGQganVzdCBzZWUKPiB0aGF0IHRoZXJlIGlzIHBsZW50eSBvZiBmcmVlIFJB
TSBpbiB0aGUgc3lzdGVtIGFuZCBub3QgZG8gYW55dGhpbmc/Cj4KPiBJYW4uCgpGcm9tIHRoaXMg
ZXhwZXJpZW5jZSwgYXQgbGVhc3QgSSBsZWFybiBtb3JlIGFib3V0IHhsIGFuZCB3aGF0CmNvbmZp
Z3VyYXRpb24gc2hvdWxkIGJlIHNldCBmb3IgbXkgdXNhZ2UvZW52aXJvbm1lbnQuICBMaWtlIGZv
cgpleGFtcGxlLCB3aGVuIEkgdXNlZCB4bCBjcmVhdGUgaHZtZG9tYWluLi4uIHRob3NlIGlwdGFi
bGVzIGZvcndhcmQKcnVsZSBjaGFpbnMgYXJlIGNyZWF0ZWQgYXMgd2VsbCBmb3IgaXRzIHZpZiBh
bmQgdGFwIGJ1dCB3aGVuIHhsCnRyaWdnZXIgaHZtZG9tYWluIHBvd2VyIG9yIHhsIHNodXRkb3du
IGh2bWRvbWFpbi4uLiB0aG9zZSBpcHRhYmxlcwpmb3J3YXJkIHJ1bGUgY2hhaW5zIGFyZSBzdGls
bCBsZWZ0IGludGFjdCA6KCAgVGhpcyBpc24ndCBiaWcgaXNzdWUgZm9yCm1lIGFzIEkgaGF2ZSBj
cmVhdGVkIHNjcmlwdCB0byByZW1vdmUgdGhvc2UgdGhvdWdoLiAgQW55d2F5LCBJIHdpbGwKYnJp
bmcgdGhpcyB1cCB3aGVuIHlvdSBndXlzIGdvaW5nIHRvIHJlbGVhc2UgeGVuLTQuMi1yYy4uLiAu
Li4gYXMgdGhpcwp0aHJlYWQgaXMgbm90IGZvciBtZSBJIGtub3cuCgpUaGFua3MgYWxsIDspCgpL
aW5kZXN0IHJlZ2FyZHMsCkdpYW0gVGVjayBDaG9vbgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:31:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:31:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTB2T-0008Fs-RJ; Wed, 23 Nov 2011 11:30:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTB2R-0008F5-Qx
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:30:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322047821!4282011!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2502 invoked from network); 23 Nov 2011 11:30:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:30:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9086240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:30:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:30:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 23 Nov 2011 11:30:21 +0000
In-Reply-To: <alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322047821.1005.77.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTIzIGF0IDExOjIzICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gT24gV2VkLCAyMyBOb3YgMjAxMSwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gV2Vk
LCAyMDExLTExLTIzIGF0IDEwOjU2ICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6Cj4g
PiA+IE9uIFR1ZSwgMjIgTm92IDIwMTEsIFRlY2sgQ2hvb24gR2lhbSB3cm90ZToKPiA+ID4gPiA+
PiA+PiBUaGF0IG1lYW5zIGRlZmF1bHQgdmFsdWUgY2hhbmdlZCBpZiBpdCBpcyB1bnNldCBmb3Ig
YXV0b2JhbGxvb24/Cj4gPiA+ID4gPj4gPj4gT3JpZ2luYWwgb25lIGlzIGNvbW1lbnRlZCB3aXRo
ICNhdXRvYmFsbG9vbiA9IDEgaW4gL2V0Yy94ZW4veGwuY29uZiBzbwo+ID4gPiA+ID4+ID4+IGl0
IGlzIHVuc2V0IEkgZ3Vlc3Mgc28gdGhlIGRlZmF1bHQgdmFsdWUgZm9yIGF1dG9iYWxsb29uIGZv
ciBjL3MgMjMxMTAKPiA+ID4gPiA+PiA+PiBpcyBhdXRvYmFsbG9vbj0wIHdoZXJlIGMvcyAyMzE5
MCBpcyBhdXRvYmFsbG9vbj0xPyDDg8aSw4bigJk/w4PGksOi4oKsxaHDg+KAmiBKdXN0IHNvbWUK
PiA+ID4gPiA+PiA+PiBndWVzc2luZy4uLiAuLi4KPiA+ID4gPiA+Cj4gPiA+ID4gPiBBdXRvYmFs
bG9vbiBhbmQgZG9tMF9tZW0gYXJlIGluY29tcGF0aWJsZS4KPiA+ID4gPiA+IEkgZG9uJ3QgdGhp
bmsgdGhlcmUgYXJlIGFueSByZWxldmFudCBkaWZmZXJlbmNlcyBiZXR3ZWVuIDIzMTEwIGFuZCAy
MzE5MAo+ID4gPiA+ID4gb24geGVuLXVuc3RhYmxlLCBtYXliZSB5b3UgdXNlZCB0byBzdGFydCBk
b20wIHdpdGhvdXQgZG9tMF9tZW0gYmVmb3JlPwo+ID4gPiA+IAo+ID4gPiA+IE5vcGUuLi4gYWxs
IG15IHNlcnZlcnMgd2lsbCBhbHdheXMgaGF2ZSB0aG9zZSBkb20wX21lbSBzZXQuICBJdCBpcwo+
ID4gPiA+IGZyb20geGVuLTQuMS10ZXN0aW5nIG5vdCB4ZW4tdW5zdGFibGUgZm9yIHRoZSB0d28g
Y2hhbmdlc2V0Lgo+ID4gPiAKPiA+ID4gSSBzdGlsbCBjYW5ub3Qgc2VlIGFueXRoaW5nIGluIHRo
YXQgcmFuZ2UuIEhvd2V2ZXIgYXMgSSBzYWlkIGJlZm9yZSwgaXQKPiA+ID4gaXMgZXhwZWN0ZWQg
dGhhdCB3aXRoIGRvbTBfbWVtIHNldCBhdXRvYmFsbG9vbiBuZWVkcyB0byBiZSBkaXNhYmxlZC4K
PiA+IAo+ID4gV2Ugc3RpbGwgaGF2ZW4ndCBzZWVuIHRoZSBmdWxsIG5vZGUgSURzIG9mIHRoZSBj
aGFuZ2VzZXRzIHdoaWNoIEkgYXNrZWQKPiA+IGZvciBzbyBpdCBpcyBub3Qgb2J2aW91cyB0aGF0
IHdlIGFyZSBhY3R1YWxseSBsb29raW5nIGF0IHRoZSBzYW1lIHJhbmdlCj4gPiBvZiBjaGFuZ2Vz
ZXRzLi4uCj4gPiAKPiA+ID4gTWF5YmUgaXQgaXMgd29ydGggZG9jdW1lbnRpbmcgdGhpcyBzb21l
d2hlcmUsIGFueSBzdWdnZXN0aW9ucyB3aGVyZT8KPiA+IAo+ID4geGwgbWFuIHBhZ2U/IFBlcmhh
cHMgd2UgYWxzbyBuZWVkIGEgc2VwYXJhdGUgL2V0Yy94bC5jZmcgKG9yIHdoYXRldmVyCj4gPiB0
aGUgcGF0aCBpcykgcGFnZT8KPiA+IAo+ID4gSWYgdGhlcmUgaXMgYW55d2hlcmUgb24gdGhlIHdp
a2kgd2hpY2ggcmVjb21tZW5kcyBkb20wX21lbT0gKGFuZCB0aGVyZQo+ID4gc2hvdWxkIGJlKSBp
dCBzaG91bGQgc2ltdWx0YW5lb3VzbHkgbWVudGlvbiB0aGlzIHNldHRpbmcuIEFzIHNob3VsZCBh
bnkKPiA+ICJnZXR0aW5nIHN0YXJ0ZWQiIHBhZ2UuCj4gPiAKPiA+IE9uIHRoZSBvdGhlciBoYW5k
IEknbSBub3Qgc3VyZSB3aHkgYXV0b2JhbGxvb24gYW5kIGRvbTBfbWVtIHBsYXkgc28KPiA+IGJh
ZGx5IHRvZ2V0aGVyLiBTdXJlbHkgaWYgZG9tMF9tZW0gaXMgdXNlZCBhdXRvYmFsbG9uIHNob3Vs
ZCBqdXN0IHNlZQo+ID4gdGhhdCB0aGVyZSBpcyBwbGVudHkgb2YgZnJlZSBSQU0gaW4gdGhlIHN5
c3RlbSBhbmQgbm90IGRvIGFueXRoaW5nPwo+ICAKPiBCZWNhdXNlIG9uZSBvZiB0aGUgIm1lbW9y
eSBzbGFjayIgcGFyYW10ZXJzIG5lZWRlZCBieSBhdXRvYmFsbG9vbiBpcwo+IAo+IHRvdGFsbWVt
b3J5IC0gZG9tMF9tZW1vcnlfYXRfYm9vdAoKbGlieGwgZ2V0cyBkb20wX21lbW9yeV9hdF9ib290
IHZpYSB0aGUgZG9taW5mbyAoaW4KbGlieGxfX2ZpbGxfZG9tMF9tZW1vcnlfaW5mbyB3aGljaCBJ
IGFzc3VtZSBoYXBwZW5zIGJlZm9yZSBhbnkKcG90ZW50aWFsbHkgYXV0b2JhbGxvb25pbmcpIHdo
aWNoIHNob3VsZCB0YWtlIGRvbTBfbWVtIGludG8gYWNjb3VudCwKZG9lc24ndCBpdD8KCj4gZm9y
dHVuYXRlbHkgbGlieGwgaXMgc21hcnQgZW5vdWdoIHRvIHRyaW0gaXQgdG8gMTUlIG9mIHRoZSB0
b3RhbCBtZW1vcnkKPiBvZiB0aGUgc3lzdGVtLCBqdXN0IGluIGNhc2UgYSB1c2VyIGZvcmdvdCB0
byBkaXNhYmxlIGF1dG9iYWxsb24gYnV0IHNldAo+IGRvbTBfbWVtLgo+IEFoISBOb3cgdGhhdCB5
b3UgbWFrZSBtZSB0aGluayBhYm91dCBpdCwgSSBiZXQgdGhlIGZhaWx1cmUgY29tZXMgZnJvbSBh
Cj4gc3lzdGVtIHRoYXQgaXMgbWlzc2luZzoKPiAKPiBsaWJ4bDogSW50cm9kdWNlIGEgbWF4aW11
bSBsaW1pdCBmb3IgZnJlZV9tZW1fc2xhY2sgKHJlIChkb20wKSBiYWxsb29uaW5nKQo+ICAgICAK
PiAgICAgVGhpcyBmaXhlcyB0aGlzIG1lc3NhZ2U6Cj4gICAgICBsaWJ4bDogZXJyb3I6IGxpYnhs
LmM6MjkyMTpsaWJ4bF9zZXRfbWVtb3J5X3RhcmdldCBuZXcgdGFyZ2V0Cj4gICAgICAgICAgICAg
ICAgICAgIGZvciBkb20wIGlzIGJlbG93IHRoZSBtaW5pbXVtIHRocmVzaG9sZAo+ICAgICB3aGlj
aCBjYW4gb2NjdXIgc3B1cmlvdXNseSBpZiBkb20wX21lbSBpcyBzcGVjaWZpZWQgYW5kIHhsCj4g
ICAgIGF1dG9iYWxsb25pbmcgaXMgbGVmdCB0dXJuZWQgb24uCgpJdCdzIGluIDQuMS10ZXN0aW5n
IGFzIDIyMjEwOjRkOTUxOTJiMmZjOC4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:31:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:31:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTB2T-0008Fs-RJ; Wed, 23 Nov 2011 11:30:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTB2R-0008F5-Qx
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:30:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322047821!4282011!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2502 invoked from network); 23 Nov 2011 11:30:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:30:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9086240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:30:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:30:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 23 Nov 2011 11:30:21 +0000
In-Reply-To: <alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322047821.1005.77.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTIzIGF0IDExOjIzICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gT24gV2VkLCAyMyBOb3YgMjAxMSwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gV2Vk
LCAyMDExLTExLTIzIGF0IDEwOjU2ICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6Cj4g
PiA+IE9uIFR1ZSwgMjIgTm92IDIwMTEsIFRlY2sgQ2hvb24gR2lhbSB3cm90ZToKPiA+ID4gPiA+
PiA+PiBUaGF0IG1lYW5zIGRlZmF1bHQgdmFsdWUgY2hhbmdlZCBpZiBpdCBpcyB1bnNldCBmb3Ig
YXV0b2JhbGxvb24/Cj4gPiA+ID4gPj4gPj4gT3JpZ2luYWwgb25lIGlzIGNvbW1lbnRlZCB3aXRo
ICNhdXRvYmFsbG9vbiA9IDEgaW4gL2V0Yy94ZW4veGwuY29uZiBzbwo+ID4gPiA+ID4+ID4+IGl0
IGlzIHVuc2V0IEkgZ3Vlc3Mgc28gdGhlIGRlZmF1bHQgdmFsdWUgZm9yIGF1dG9iYWxsb29uIGZv
ciBjL3MgMjMxMTAKPiA+ID4gPiA+PiA+PiBpcyBhdXRvYmFsbG9vbj0wIHdoZXJlIGMvcyAyMzE5
MCBpcyBhdXRvYmFsbG9vbj0xPyDDg8aSw4bigJk/w4PGksOi4oKsxaHDg+KAmiBKdXN0IHNvbWUK
PiA+ID4gPiA+PiA+PiBndWVzc2luZy4uLiAuLi4KPiA+ID4gPiA+Cj4gPiA+ID4gPiBBdXRvYmFs
bG9vbiBhbmQgZG9tMF9tZW0gYXJlIGluY29tcGF0aWJsZS4KPiA+ID4gPiA+IEkgZG9uJ3QgdGhp
bmsgdGhlcmUgYXJlIGFueSByZWxldmFudCBkaWZmZXJlbmNlcyBiZXR3ZWVuIDIzMTEwIGFuZCAy
MzE5MAo+ID4gPiA+ID4gb24geGVuLXVuc3RhYmxlLCBtYXliZSB5b3UgdXNlZCB0byBzdGFydCBk
b20wIHdpdGhvdXQgZG9tMF9tZW0gYmVmb3JlPwo+ID4gPiA+IAo+ID4gPiA+IE5vcGUuLi4gYWxs
IG15IHNlcnZlcnMgd2lsbCBhbHdheXMgaGF2ZSB0aG9zZSBkb20wX21lbSBzZXQuICBJdCBpcwo+
ID4gPiA+IGZyb20geGVuLTQuMS10ZXN0aW5nIG5vdCB4ZW4tdW5zdGFibGUgZm9yIHRoZSB0d28g
Y2hhbmdlc2V0Lgo+ID4gPiAKPiA+ID4gSSBzdGlsbCBjYW5ub3Qgc2VlIGFueXRoaW5nIGluIHRo
YXQgcmFuZ2UuIEhvd2V2ZXIgYXMgSSBzYWlkIGJlZm9yZSwgaXQKPiA+ID4gaXMgZXhwZWN0ZWQg
dGhhdCB3aXRoIGRvbTBfbWVtIHNldCBhdXRvYmFsbG9vbiBuZWVkcyB0byBiZSBkaXNhYmxlZC4K
PiA+IAo+ID4gV2Ugc3RpbGwgaGF2ZW4ndCBzZWVuIHRoZSBmdWxsIG5vZGUgSURzIG9mIHRoZSBj
aGFuZ2VzZXRzIHdoaWNoIEkgYXNrZWQKPiA+IGZvciBzbyBpdCBpcyBub3Qgb2J2aW91cyB0aGF0
IHdlIGFyZSBhY3R1YWxseSBsb29raW5nIGF0IHRoZSBzYW1lIHJhbmdlCj4gPiBvZiBjaGFuZ2Vz
ZXRzLi4uCj4gPiAKPiA+ID4gTWF5YmUgaXQgaXMgd29ydGggZG9jdW1lbnRpbmcgdGhpcyBzb21l
d2hlcmUsIGFueSBzdWdnZXN0aW9ucyB3aGVyZT8KPiA+IAo+ID4geGwgbWFuIHBhZ2U/IFBlcmhh
cHMgd2UgYWxzbyBuZWVkIGEgc2VwYXJhdGUgL2V0Yy94bC5jZmcgKG9yIHdoYXRldmVyCj4gPiB0
aGUgcGF0aCBpcykgcGFnZT8KPiA+IAo+ID4gSWYgdGhlcmUgaXMgYW55d2hlcmUgb24gdGhlIHdp
a2kgd2hpY2ggcmVjb21tZW5kcyBkb20wX21lbT0gKGFuZCB0aGVyZQo+ID4gc2hvdWxkIGJlKSBp
dCBzaG91bGQgc2ltdWx0YW5lb3VzbHkgbWVudGlvbiB0aGlzIHNldHRpbmcuIEFzIHNob3VsZCBh
bnkKPiA+ICJnZXR0aW5nIHN0YXJ0ZWQiIHBhZ2UuCj4gPiAKPiA+IE9uIHRoZSBvdGhlciBoYW5k
IEknbSBub3Qgc3VyZSB3aHkgYXV0b2JhbGxvb24gYW5kIGRvbTBfbWVtIHBsYXkgc28KPiA+IGJh
ZGx5IHRvZ2V0aGVyLiBTdXJlbHkgaWYgZG9tMF9tZW0gaXMgdXNlZCBhdXRvYmFsbG9uIHNob3Vs
ZCBqdXN0IHNlZQo+ID4gdGhhdCB0aGVyZSBpcyBwbGVudHkgb2YgZnJlZSBSQU0gaW4gdGhlIHN5
c3RlbSBhbmQgbm90IGRvIGFueXRoaW5nPwo+ICAKPiBCZWNhdXNlIG9uZSBvZiB0aGUgIm1lbW9y
eSBzbGFjayIgcGFyYW10ZXJzIG5lZWRlZCBieSBhdXRvYmFsbG9vbiBpcwo+IAo+IHRvdGFsbWVt
b3J5IC0gZG9tMF9tZW1vcnlfYXRfYm9vdAoKbGlieGwgZ2V0cyBkb20wX21lbW9yeV9hdF9ib290
IHZpYSB0aGUgZG9taW5mbyAoaW4KbGlieGxfX2ZpbGxfZG9tMF9tZW1vcnlfaW5mbyB3aGljaCBJ
IGFzc3VtZSBoYXBwZW5zIGJlZm9yZSBhbnkKcG90ZW50aWFsbHkgYXV0b2JhbGxvb25pbmcpIHdo
aWNoIHNob3VsZCB0YWtlIGRvbTBfbWVtIGludG8gYWNjb3VudCwKZG9lc24ndCBpdD8KCj4gZm9y
dHVuYXRlbHkgbGlieGwgaXMgc21hcnQgZW5vdWdoIHRvIHRyaW0gaXQgdG8gMTUlIG9mIHRoZSB0
b3RhbCBtZW1vcnkKPiBvZiB0aGUgc3lzdGVtLCBqdXN0IGluIGNhc2UgYSB1c2VyIGZvcmdvdCB0
byBkaXNhYmxlIGF1dG9iYWxsb24gYnV0IHNldAo+IGRvbTBfbWVtLgo+IEFoISBOb3cgdGhhdCB5
b3UgbWFrZSBtZSB0aGluayBhYm91dCBpdCwgSSBiZXQgdGhlIGZhaWx1cmUgY29tZXMgZnJvbSBh
Cj4gc3lzdGVtIHRoYXQgaXMgbWlzc2luZzoKPiAKPiBsaWJ4bDogSW50cm9kdWNlIGEgbWF4aW11
bSBsaW1pdCBmb3IgZnJlZV9tZW1fc2xhY2sgKHJlIChkb20wKSBiYWxsb29uaW5nKQo+ICAgICAK
PiAgICAgVGhpcyBmaXhlcyB0aGlzIG1lc3NhZ2U6Cj4gICAgICBsaWJ4bDogZXJyb3I6IGxpYnhs
LmM6MjkyMTpsaWJ4bF9zZXRfbWVtb3J5X3RhcmdldCBuZXcgdGFyZ2V0Cj4gICAgICAgICAgICAg
ICAgICAgIGZvciBkb20wIGlzIGJlbG93IHRoZSBtaW5pbXVtIHRocmVzaG9sZAo+ICAgICB3aGlj
aCBjYW4gb2NjdXIgc3B1cmlvdXNseSBpZiBkb20wX21lbSBpcyBzcGVjaWZpZWQgYW5kIHhsCj4g
ICAgIGF1dG9iYWxsb25pbmcgaXMgbGVmdCB0dXJuZWQgb24uCgpJdCdzIGluIDQuMS10ZXN0aW5n
IGFzIDIyMjEwOjRkOTUxOTJiMmZjOC4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:35:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:35:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTB6i-0008VF-IV; Wed, 23 Nov 2011 11:35:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTB6h-0008Up-KN
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:35:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322048085!4673225!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15985 invoked from network); 23 Nov 2011 11:34:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:34:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9086344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:34:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:34:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Wed, 23 Nov 2011 11:34:44 +0000
In-Reply-To: <CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322048085.1005.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTIzIGF0IDExOjMwICswMDAwLCBUZWNrIENob29uIEdpYW0gd3JvdGU6
Cj4gT24gV2VkLCBOb3YgMjMsIDIwMTEgYXQgNzowNyBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2Ft
cGJlbGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gPiBPbiBXZWQsIDIwMTEtMTEtMjMgYXQgMTA6NTYg
KzAwMDAsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToKPiA+PiBPbiBUdWUsIDIyIE5vdiAyMDEx
LCBUZWNrIENob29uIEdpYW0gd3JvdGU6Cj4gPj4gPiA+PiA+PiBUaGF0IG1lYW5zIGRlZmF1bHQg
dmFsdWUgY2hhbmdlZCBpZiBpdCBpcyB1bnNldCBmb3IgYXV0b2JhbGxvb24/Cj4gPj4gPiA+PiA+
PiBPcmlnaW5hbCBvbmUgaXMgY29tbWVudGVkIHdpdGggI2F1dG9iYWxsb29uID0gMSBpbiAvZXRj
L3hlbi94bC5jb25mIHNvCj4gPj4gPiA+PiA+PiBpdCBpcyB1bnNldCBJIGd1ZXNzIHNvIHRoZSBk
ZWZhdWx0IHZhbHVlIGZvciBhdXRvYmFsbG9vbiBmb3IgYy9zIDIzMTEwCj4gPj4gPiA+PiA+PiBp
cyBhdXRvYmFsbG9vbj0wIHdoZXJlIGMvcyAyMzE5MCBpcyBhdXRvYmFsbG9vbj0xPyDDg8aSP8OD
4oCaw4IgSnVzdCBzb21lCj4gPj4gPiA+PiA+PiBndWVzc2luZy4uLiAuLi4KPiA+PiA+ID4KPiA+
PiA+ID4gQXV0b2JhbGxvb24gYW5kIGRvbTBfbWVtIGFyZSBpbmNvbXBhdGlibGUuCj4gPj4gPiA+
IEkgZG9uJ3QgdGhpbmsgdGhlcmUgYXJlIGFueSByZWxldmFudCBkaWZmZXJlbmNlcyBiZXR3ZWVu
IDIzMTEwIGFuZCAyMzE5MAo+ID4+ID4gPiBvbiB4ZW4tdW5zdGFibGUsIG1heWJlIHlvdSB1c2Vk
IHRvIHN0YXJ0IGRvbTAgd2l0aG91dCBkb20wX21lbSBiZWZvcmU/Cj4gPj4gPgo+ID4+ID4gTm9w
ZS4uLiBhbGwgbXkgc2VydmVycyB3aWxsIGFsd2F5cyBoYXZlIHRob3NlIGRvbTBfbWVtIHNldC4g
IEl0IGlzCj4gPj4gPiBmcm9tIHhlbi00LjEtdGVzdGluZyBub3QgeGVuLXVuc3RhYmxlIGZvciB0
aGUgdHdvIGNoYW5nZXNldC4KPiA+Pgo+ID4+IEkgc3RpbGwgY2Fubm90IHNlZSBhbnl0aGluZyBp
biB0aGF0IHJhbmdlLiBIb3dldmVyIGFzIEkgc2FpZCBiZWZvcmUsIGl0Cj4gPj4gaXMgZXhwZWN0
ZWQgdGhhdCB3aXRoIGRvbTBfbWVtIHNldCBhdXRvYmFsbG9vbiBuZWVkcyB0byBiZSBkaXNhYmxl
ZC4KPiA+Cj4gPiBXZSBzdGlsbCBoYXZlbid0IHNlZW4gdGhlIGZ1bGwgbm9kZSBJRHMgb2YgdGhl
IGNoYW5nZXNldHMgd2hpY2ggSSBhc2tlZAo+ID4gZm9yIHNvIGl0IGlzIG5vdCBvYnZpb3VzIHRo
YXQgd2UgYXJlIGFjdHVhbGx5IGxvb2tpbmcgYXQgdGhlIHNhbWUgcmFuZ2UKPiA+IG9mIGNoYW5n
ZXNldHMuLi4KPiAKPiBTb3JyeSwgSSBhbSBhY3R1YWxseSBub3Qgc3VyZSB3aGF0IElEIHlvdSBh
cmUgYXNraW5nIDooCj4gCj4gQ2hhbmdlc2V0cyBkZXRhaWxzIGFzIGJlbG93Ogo+IAo+IGNoYW5n
ZXNldDogICAyMzExMDo0ZDVjNzYyNDhkZTMKClRoZSAiMjMxMTAiIGJpdCBoZXJlIGlzIG9ubHkg
bG9jYWxseSByZWxldmFudCB0byB0aGUgcmVwbyB5b3UgYXJlCmxvb2tpbmcgYXQgc28geW91IGNh
bm5vdCByZWxpYWJseSBpZGVudGlmeSBhIGNoYW5nZXNldCB0byBzb21lb25lIGVsc2UKdXNpbmcg
dGhhdCBudW1iZXIuIE9ubHkgdGhlICI0ZDVjNzYyNDhkZTMiIGlzIGEgZ2xvYmFsIGlkZW50aWZp
ZXIgYW5kCmNhbiB0aGVyZWZvcmUgYmUgZXhjaGFuZ2VkLgoKPiB1c2VyOiAgICAgICAgUm9nZXIg
UGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiBkYXRlOiAgICAgICAgU2F0IEp1
bCAyMyAwOTowMToyNSAyMDExICswMTAwCj4gc3VtbWFyeTogICAgIHhlbmQ6IHJlbW92ZSBQQ0kg
ZGV2aWNlIGxpc3RpbmcgZnJvbSBOZXRCU0QsIHNpbmNlIGl0J3MgTGludXgKPiAKPiBjaGFuZ2Vz
ZXQ6ICAgMjMxOTA6NWEwMGNjZmM2MzkxCj4gdXNlcjogICAgICAgIFN0ZWZhbm8gU3RhYmVsbGlu
aSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+Cj4gZGF0ZTogICAgICAgIEZyaSBO
b3YgMTggMTM6Mzg6MDUgMjAxMSArMDAwMAo+IHN1bW1hcnk6ICAgICB4ODY6IHJlLWluamVjdCBl
bXVsYXRlZCBsZXZlbCBwaXJxcyBpbiBQViBvbiBIVk0gZ3Vlc3RzCj4gaWYgc3RpbGwgYXNzZXJ0
ZWQKCgpVbmZvcnR1bmF0ZWx5IEkgc3RpbGwgZG9uJ3Qgc2VlIGFueXRoaW5nIHJlbGV2YW50IGJl
dHdlZW4gdGhlc2UKY2hhbmdlc2V0cyBzbyBJJ3ZlIG5vIGlkZWEgd2h5IHRoaXMgc2VlbXMgdG8g
YmUgYSBuZXcgaXNzdWUuIEFyZSB5b3UKX3Bvc2l0aXZlXyB0aGF0IHlvdSBkaWRuJ3QgY2hhbmdl
IGFueXRoaW5nIGVsc2UgYWJvdXQgeW91ciBzeXN0ZW0KY29uZmlndXJhdGlvbiBvbiB1cGdyYWRl
PwoKPiA+PiBNYXliZSBpdCBpcyB3b3J0aCBkb2N1bWVudGluZyB0aGlzIHNvbWV3aGVyZSwgYW55
IHN1Z2dlc3Rpb25zIHdoZXJlPwo+ID4KPiA+IHhsIG1hbiBwYWdlPyBQZXJoYXBzIHdlIGFsc28g
bmVlZCBhIHNlcGFyYXRlIC9ldGMveGwuY2ZnIChvciB3aGF0ZXZlcgo+ID4gdGhlIHBhdGggaXMp
IHBhZ2U/Cj4gCj4gU2hvdWxkbid0IGl0IGJlIHhsLmNvbmYgaW5zdGVhZCBvZiB4bC5jZmc/ICB4
bCBtYW4gcGFnZSB3aWxsIGhlbHBzIGEKPiBsb3QgZXNwZWNpYWxseSBmb3IgdGhvc2Ugb2YgdXMg
c3dpdGNoaW5nIGZyb20geG0gdG8geGwuCgpJdCBzaG91bGQgbWF0Y2ggdGhlIGFjdHVhbCBmaWxl
bmFtZSB3aGljaCBkb2VzIGFwcGVhciB0byBiZSB4bC5jb25mIG5vdApjZmcuCgo+IAo+ID4KPiA+
IElmIHRoZXJlIGlzIGFueXdoZXJlIG9uIHRoZSB3aWtpIHdoaWNoIHJlY29tbWVuZHMgZG9tMF9t
ZW09IChhbmQgdGhlcmUKPiA+IHNob3VsZCBiZSkgaXQgc2hvdWxkIHNpbXVsdGFuZW91c2x5IG1l
bnRpb24gdGhpcyBzZXR0aW5nLiBBcyBzaG91bGQgYW55Cj4gPiAiZ2V0dGluZyBzdGFydGVkIiBw
YWdlLgo+ID4KPiA+IE9uIHRoZSBvdGhlciBoYW5kIEknbSBub3Qgc3VyZSB3aHkgYXV0b2JhbGxv
b24gYW5kIGRvbTBfbWVtIHBsYXkgc28KPiA+IGJhZGx5IHRvZ2V0aGVyLiBTdXJlbHkgaWYgZG9t
MF9tZW0gaXMgdXNlZCBhdXRvYmFsbG9uIHNob3VsZCBqdXN0IHNlZQo+ID4gdGhhdCB0aGVyZSBp
cyBwbGVudHkgb2YgZnJlZSBSQU0gaW4gdGhlIHN5c3RlbSBhbmQgbm90IGRvIGFueXRoaW5nPwo+
ID4KPiA+IElhbi4KPiAKPiBGcm9tIHRoaXMgZXhwZXJpZW5jZSwgYXQgbGVhc3QgSSBsZWFybiBt
b3JlIGFib3V0IHhsIGFuZCB3aGF0Cj4gY29uZmlndXJhdGlvbiBzaG91bGQgYmUgc2V0IGZvciBt
eSB1c2FnZS9lbnZpcm9ubWVudC4gIExpa2UgZm9yCj4gZXhhbXBsZSwgd2hlbiBJIHVzZWQgeGwg
Y3JlYXRlIGh2bWRvbWFpbi4uLiB0aG9zZSBpcHRhYmxlcyBmb3J3YXJkCj4gcnVsZSBjaGFpbnMg
YXJlIGNyZWF0ZWQgYXMgd2VsbCBmb3IgaXRzIHZpZiBhbmQgdGFwIGJ1dCB3aGVuIHhsCj4gdHJp
Z2dlciBodm1kb21haW4gcG93ZXIgb3IgeGwgc2h1dGRvd24gaHZtZG9tYWluLi4uIHRob3NlIGlw
dGFibGVzCj4gZm9yd2FyZCBydWxlIGNoYWlucyBhcmUgc3RpbGwgbGVmdCBpbnRhY3QgOiggIFRo
aXMgaXNuJ3QgYmlnIGlzc3VlIGZvcgo+IG1lIGFzIEkgaGF2ZSBjcmVhdGVkIHNjcmlwdCB0byBy
ZW1vdmUgdGhvc2UgdGhvdWdoLiAgQW55d2F5LCBJIHdpbGwKPiBicmluZyB0aGlzIHVwIHdoZW4g
eW91IGd1eXMgZ29pbmcgdG8gcmVsZWFzZSB4ZW4tNC4yLXJjLi4uIC4uLiBhcyB0aGlzCj4gdGhy
ZWFkIGlzIG5vdCBmb3IgbWUgSSBrbm93LgoKVGhhdCBzb3VuZHMgbGlrZSBhIGJ1ZywgdGhlcmUn
cyBubyBuZWVkIHRvIHdhaXQgZm9yIGFuIHJjIHJlbGVhc2UgdG8KcmVwb3J0IGEgYnVnLgoKSWFu
LgoKPiAKPiBUaGFua3MgYWxsIDspCj4gCj4gS2luZGVzdCByZWdhcmRzLAo+IEdpYW0gVGVjayBD
aG9vbgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:35:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:35:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTB6i-0008VF-IV; Wed, 23 Nov 2011 11:35:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTB6h-0008Up-KN
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:35:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322048085!4673225!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15985 invoked from network); 23 Nov 2011 11:34:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:34:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9086344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:34:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:34:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Wed, 23 Nov 2011 11:34:44 +0000
In-Reply-To: <CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322048085.1005.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTIzIGF0IDExOjMwICswMDAwLCBUZWNrIENob29uIEdpYW0gd3JvdGU6
Cj4gT24gV2VkLCBOb3YgMjMsIDIwMTEgYXQgNzowNyBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2Ft
cGJlbGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gPiBPbiBXZWQsIDIwMTEtMTEtMjMgYXQgMTA6NTYg
KzAwMDAsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToKPiA+PiBPbiBUdWUsIDIyIE5vdiAyMDEx
LCBUZWNrIENob29uIEdpYW0gd3JvdGU6Cj4gPj4gPiA+PiA+PiBUaGF0IG1lYW5zIGRlZmF1bHQg
dmFsdWUgY2hhbmdlZCBpZiBpdCBpcyB1bnNldCBmb3IgYXV0b2JhbGxvb24/Cj4gPj4gPiA+PiA+
PiBPcmlnaW5hbCBvbmUgaXMgY29tbWVudGVkIHdpdGggI2F1dG9iYWxsb29uID0gMSBpbiAvZXRj
L3hlbi94bC5jb25mIHNvCj4gPj4gPiA+PiA+PiBpdCBpcyB1bnNldCBJIGd1ZXNzIHNvIHRoZSBk
ZWZhdWx0IHZhbHVlIGZvciBhdXRvYmFsbG9vbiBmb3IgYy9zIDIzMTEwCj4gPj4gPiA+PiA+PiBp
cyBhdXRvYmFsbG9vbj0wIHdoZXJlIGMvcyAyMzE5MCBpcyBhdXRvYmFsbG9vbj0xPyDDg8aSP8OD
4oCaw4IgSnVzdCBzb21lCj4gPj4gPiA+PiA+PiBndWVzc2luZy4uLiAuLi4KPiA+PiA+ID4KPiA+
PiA+ID4gQXV0b2JhbGxvb24gYW5kIGRvbTBfbWVtIGFyZSBpbmNvbXBhdGlibGUuCj4gPj4gPiA+
IEkgZG9uJ3QgdGhpbmsgdGhlcmUgYXJlIGFueSByZWxldmFudCBkaWZmZXJlbmNlcyBiZXR3ZWVu
IDIzMTEwIGFuZCAyMzE5MAo+ID4+ID4gPiBvbiB4ZW4tdW5zdGFibGUsIG1heWJlIHlvdSB1c2Vk
IHRvIHN0YXJ0IGRvbTAgd2l0aG91dCBkb20wX21lbSBiZWZvcmU/Cj4gPj4gPgo+ID4+ID4gTm9w
ZS4uLiBhbGwgbXkgc2VydmVycyB3aWxsIGFsd2F5cyBoYXZlIHRob3NlIGRvbTBfbWVtIHNldC4g
IEl0IGlzCj4gPj4gPiBmcm9tIHhlbi00LjEtdGVzdGluZyBub3QgeGVuLXVuc3RhYmxlIGZvciB0
aGUgdHdvIGNoYW5nZXNldC4KPiA+Pgo+ID4+IEkgc3RpbGwgY2Fubm90IHNlZSBhbnl0aGluZyBp
biB0aGF0IHJhbmdlLiBIb3dldmVyIGFzIEkgc2FpZCBiZWZvcmUsIGl0Cj4gPj4gaXMgZXhwZWN0
ZWQgdGhhdCB3aXRoIGRvbTBfbWVtIHNldCBhdXRvYmFsbG9vbiBuZWVkcyB0byBiZSBkaXNhYmxl
ZC4KPiA+Cj4gPiBXZSBzdGlsbCBoYXZlbid0IHNlZW4gdGhlIGZ1bGwgbm9kZSBJRHMgb2YgdGhl
IGNoYW5nZXNldHMgd2hpY2ggSSBhc2tlZAo+ID4gZm9yIHNvIGl0IGlzIG5vdCBvYnZpb3VzIHRo
YXQgd2UgYXJlIGFjdHVhbGx5IGxvb2tpbmcgYXQgdGhlIHNhbWUgcmFuZ2UKPiA+IG9mIGNoYW5n
ZXNldHMuLi4KPiAKPiBTb3JyeSwgSSBhbSBhY3R1YWxseSBub3Qgc3VyZSB3aGF0IElEIHlvdSBh
cmUgYXNraW5nIDooCj4gCj4gQ2hhbmdlc2V0cyBkZXRhaWxzIGFzIGJlbG93Ogo+IAo+IGNoYW5n
ZXNldDogICAyMzExMDo0ZDVjNzYyNDhkZTMKClRoZSAiMjMxMTAiIGJpdCBoZXJlIGlzIG9ubHkg
bG9jYWxseSByZWxldmFudCB0byB0aGUgcmVwbyB5b3UgYXJlCmxvb2tpbmcgYXQgc28geW91IGNh
bm5vdCByZWxpYWJseSBpZGVudGlmeSBhIGNoYW5nZXNldCB0byBzb21lb25lIGVsc2UKdXNpbmcg
dGhhdCBudW1iZXIuIE9ubHkgdGhlICI0ZDVjNzYyNDhkZTMiIGlzIGEgZ2xvYmFsIGlkZW50aWZp
ZXIgYW5kCmNhbiB0aGVyZWZvcmUgYmUgZXhjaGFuZ2VkLgoKPiB1c2VyOiAgICAgICAgUm9nZXIg
UGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiBkYXRlOiAgICAgICAgU2F0IEp1
bCAyMyAwOTowMToyNSAyMDExICswMTAwCj4gc3VtbWFyeTogICAgIHhlbmQ6IHJlbW92ZSBQQ0kg
ZGV2aWNlIGxpc3RpbmcgZnJvbSBOZXRCU0QsIHNpbmNlIGl0J3MgTGludXgKPiAKPiBjaGFuZ2Vz
ZXQ6ICAgMjMxOTA6NWEwMGNjZmM2MzkxCj4gdXNlcjogICAgICAgIFN0ZWZhbm8gU3RhYmVsbGlu
aSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+Cj4gZGF0ZTogICAgICAgIEZyaSBO
b3YgMTggMTM6Mzg6MDUgMjAxMSArMDAwMAo+IHN1bW1hcnk6ICAgICB4ODY6IHJlLWluamVjdCBl
bXVsYXRlZCBsZXZlbCBwaXJxcyBpbiBQViBvbiBIVk0gZ3Vlc3RzCj4gaWYgc3RpbGwgYXNzZXJ0
ZWQKCgpVbmZvcnR1bmF0ZWx5IEkgc3RpbGwgZG9uJ3Qgc2VlIGFueXRoaW5nIHJlbGV2YW50IGJl
dHdlZW4gdGhlc2UKY2hhbmdlc2V0cyBzbyBJJ3ZlIG5vIGlkZWEgd2h5IHRoaXMgc2VlbXMgdG8g
YmUgYSBuZXcgaXNzdWUuIEFyZSB5b3UKX3Bvc2l0aXZlXyB0aGF0IHlvdSBkaWRuJ3QgY2hhbmdl
IGFueXRoaW5nIGVsc2UgYWJvdXQgeW91ciBzeXN0ZW0KY29uZmlndXJhdGlvbiBvbiB1cGdyYWRl
PwoKPiA+PiBNYXliZSBpdCBpcyB3b3J0aCBkb2N1bWVudGluZyB0aGlzIHNvbWV3aGVyZSwgYW55
IHN1Z2dlc3Rpb25zIHdoZXJlPwo+ID4KPiA+IHhsIG1hbiBwYWdlPyBQZXJoYXBzIHdlIGFsc28g
bmVlZCBhIHNlcGFyYXRlIC9ldGMveGwuY2ZnIChvciB3aGF0ZXZlcgo+ID4gdGhlIHBhdGggaXMp
IHBhZ2U/Cj4gCj4gU2hvdWxkbid0IGl0IGJlIHhsLmNvbmYgaW5zdGVhZCBvZiB4bC5jZmc/ICB4
bCBtYW4gcGFnZSB3aWxsIGhlbHBzIGEKPiBsb3QgZXNwZWNpYWxseSBmb3IgdGhvc2Ugb2YgdXMg
c3dpdGNoaW5nIGZyb20geG0gdG8geGwuCgpJdCBzaG91bGQgbWF0Y2ggdGhlIGFjdHVhbCBmaWxl
bmFtZSB3aGljaCBkb2VzIGFwcGVhciB0byBiZSB4bC5jb25mIG5vdApjZmcuCgo+IAo+ID4KPiA+
IElmIHRoZXJlIGlzIGFueXdoZXJlIG9uIHRoZSB3aWtpIHdoaWNoIHJlY29tbWVuZHMgZG9tMF9t
ZW09IChhbmQgdGhlcmUKPiA+IHNob3VsZCBiZSkgaXQgc2hvdWxkIHNpbXVsdGFuZW91c2x5IG1l
bnRpb24gdGhpcyBzZXR0aW5nLiBBcyBzaG91bGQgYW55Cj4gPiAiZ2V0dGluZyBzdGFydGVkIiBw
YWdlLgo+ID4KPiA+IE9uIHRoZSBvdGhlciBoYW5kIEknbSBub3Qgc3VyZSB3aHkgYXV0b2JhbGxv
b24gYW5kIGRvbTBfbWVtIHBsYXkgc28KPiA+IGJhZGx5IHRvZ2V0aGVyLiBTdXJlbHkgaWYgZG9t
MF9tZW0gaXMgdXNlZCBhdXRvYmFsbG9uIHNob3VsZCBqdXN0IHNlZQo+ID4gdGhhdCB0aGVyZSBp
cyBwbGVudHkgb2YgZnJlZSBSQU0gaW4gdGhlIHN5c3RlbSBhbmQgbm90IGRvIGFueXRoaW5nPwo+
ID4KPiA+IElhbi4KPiAKPiBGcm9tIHRoaXMgZXhwZXJpZW5jZSwgYXQgbGVhc3QgSSBsZWFybiBt
b3JlIGFib3V0IHhsIGFuZCB3aGF0Cj4gY29uZmlndXJhdGlvbiBzaG91bGQgYmUgc2V0IGZvciBt
eSB1c2FnZS9lbnZpcm9ubWVudC4gIExpa2UgZm9yCj4gZXhhbXBsZSwgd2hlbiBJIHVzZWQgeGwg
Y3JlYXRlIGh2bWRvbWFpbi4uLiB0aG9zZSBpcHRhYmxlcyBmb3J3YXJkCj4gcnVsZSBjaGFpbnMg
YXJlIGNyZWF0ZWQgYXMgd2VsbCBmb3IgaXRzIHZpZiBhbmQgdGFwIGJ1dCB3aGVuIHhsCj4gdHJp
Z2dlciBodm1kb21haW4gcG93ZXIgb3IgeGwgc2h1dGRvd24gaHZtZG9tYWluLi4uIHRob3NlIGlw
dGFibGVzCj4gZm9yd2FyZCBydWxlIGNoYWlucyBhcmUgc3RpbGwgbGVmdCBpbnRhY3QgOiggIFRo
aXMgaXNuJ3QgYmlnIGlzc3VlIGZvcgo+IG1lIGFzIEkgaGF2ZSBjcmVhdGVkIHNjcmlwdCB0byBy
ZW1vdmUgdGhvc2UgdGhvdWdoLiAgQW55d2F5LCBJIHdpbGwKPiBicmluZyB0aGlzIHVwIHdoZW4g
eW91IGd1eXMgZ29pbmcgdG8gcmVsZWFzZSB4ZW4tNC4yLXJjLi4uIC4uLiBhcyB0aGlzCj4gdGhy
ZWFkIGlzIG5vdCBmb3IgbWUgSSBrbm93LgoKVGhhdCBzb3VuZHMgbGlrZSBhIGJ1ZywgdGhlcmUn
cyBubyBuZWVkIHRvIHdhaXQgZm9yIGFuIHJjIHJlbGVhc2UgdG8KcmVwb3J0IGEgYnVnLgoKSWFu
LgoKPiAKPiBUaGFua3MgYWxsIDspCj4gCj4gS2luZGVzdCByZWdhcmRzLAo+IEdpYW0gVGVjayBD
aG9vbgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:38:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBA7-0000FU-99; Wed, 23 Nov 2011 11:38:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTBA5-0000FL-L9
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:38:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322048253!57937010!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7363 invoked from network); 23 Nov 2011 11:37:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:37:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9086442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:38:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:38:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 23 Nov 2011 11:38:15 +0000
In-Reply-To: <1322045702.24897.32.camel@Abyss>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
	<1322040258.1005.1.camel@zakaz.uk.xensource.com>
	<1322043870.24897.25.camel@Abyss> <1322045702.24897.32.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322048295.1005.82.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 10:55 +0000, Dario Faggioli wrote:
> On Wed, 2011-11-23 at 11:24 +0100, Dario Faggioli wrote:
> > On Wed, 2011-11-23 at 09:24 +0000, Ian Campbell wrote:
> > > > # xl sched-credit2
> > > > Cpupool Pool-0:
> > > > Name                                ID Weight
> > > > xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_domain_get
> > > 
> > > Is there a chance you are picking up an older version of libxl from
> > > somewhere?
> > > 
> > More than once... That should be the culprit for me too, but I'm still
> > trying to figure out how... :-)
> > 
> Ok, found! Sorry for having bothered you in the first place.
> 
> The thing is I'm running Debian Sid on the testbox, and there seems to
> be no '/usr/lib64' there (neither as a real directory nor as a symlink
> to '/usr/lib'), while build system put the libraries in
> 'dist/install/usr/lib64'. Installing the xen distribution (which is
> basically unpacking an archive here) created '/ust/lib64', but it does
> not appear to be on the search path for shared libraries on such
> distro... Could that be an issue?

/usr/lib64 used to be a symlink to /usr/lib on Debian but that has gone
away due to the beginnings of multiarch support.

It's not clear to me if this is a bug of sorts in multiarch (or at least
in the transition) or if we ought to be doing something to work with
such systems. My build/test machines are all Debian Stable so I haven't
had to think about it too hard yet since multiarch-ification is only
going on in unstable (perhaps testing too, I don't know).

Short term you can edit config/StdGNU.mk to change LIBLEAFDIR_x86_64.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:38:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBA7-0000FU-99; Wed, 23 Nov 2011 11:38:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTBA5-0000FL-L9
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:38:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322048253!57937010!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7363 invoked from network); 23 Nov 2011 11:37:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:37:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9086442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:38:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:38:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 23 Nov 2011 11:38:15 +0000
In-Reply-To: <1322045702.24897.32.camel@Abyss>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
	<1322040258.1005.1.camel@zakaz.uk.xensource.com>
	<1322043870.24897.25.camel@Abyss> <1322045702.24897.32.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322048295.1005.82.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 10:55 +0000, Dario Faggioli wrote:
> On Wed, 2011-11-23 at 11:24 +0100, Dario Faggioli wrote:
> > On Wed, 2011-11-23 at 09:24 +0000, Ian Campbell wrote:
> > > > # xl sched-credit2
> > > > Cpupool Pool-0:
> > > > Name                                ID Weight
> > > > xl: symbol lookup error: xl: undefined symbol: libxl_sched_credit2_domain_get
> > > 
> > > Is there a chance you are picking up an older version of libxl from
> > > somewhere?
> > > 
> > More than once... That should be the culprit for me too, but I'm still
> > trying to figure out how... :-)
> > 
> Ok, found! Sorry for having bothered you in the first place.
> 
> The thing is I'm running Debian Sid on the testbox, and there seems to
> be no '/usr/lib64' there (neither as a real directory nor as a symlink
> to '/usr/lib'), while build system put the libraries in
> 'dist/install/usr/lib64'. Installing the xen distribution (which is
> basically unpacking an archive here) created '/ust/lib64', but it does
> not appear to be on the search path for shared libraries on such
> distro... Could that be an issue?

/usr/lib64 used to be a symlink to /usr/lib on Debian but that has gone
away due to the beginnings of multiarch support.

It's not clear to me if this is a bug of sorts in multiarch (or at least
in the transition) or if we ought to be doing something to work with
such systems. My build/test machines are all Debian Stable so I haven't
had to think about it too hard yet since multiarch-ification is only
going on in unstable (perhaps testing too, I don't know).

Short term you can edit config/StdGNU.mk to change LIBLEAFDIR_x86_64.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:47:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:47:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBIF-0000Sx-9R; Wed, 23 Nov 2011 11:47:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RTBID-0000Ss-Cp
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:47:09 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322048798!2700284!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17486 invoked from network); 23 Nov 2011 11:46:39 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:46:39 -0000
Received: by qyk31 with SMTP id 31so1444415qyk.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 03:46:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=rzKKeJfqtN6fhmKVvsjsg6kCNdpri+6zXij8K5CjYZw=;
	b=SN6AwQgwmv0AvqR1gidzECT8CIVIv0riH/w3IGQ56kL33zF5iaAvKtpKKPLLwSZITC
	sRH6B7h4PTH77JBFTItZhaS6ZLsVctISSYLXCBnTRRds10OPGZ3o8AtYzBaQksKR2N6c
	9lGsxNbr1s4Zz4X1XIWZZ4AbGMWsMYFceKJ5Q=
MIME-Version: 1.0
Received: by 10.68.20.234 with SMTP id q10mr7521925pbe.27.1322048797587; Wed,
	23 Nov 2011 03:46:37 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Wed, 23 Nov 2011 03:46:37 -0800 (PST)
In-Reply-To: <1322048085.1005.81.camel@zakaz.uk.xensource.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
	<1322048085.1005.81.camel@zakaz.uk.xensource.com>
Date: Wed, 23 Nov 2011 19:46:37 +0800
Message-ID: <CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBOb3YgMjMsIDIwMTEgYXQgNzozNCBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gT24gV2VkLCAyMDExLTExLTIzIGF0IDExOjMwICswMDAw
LCBUZWNrIENob29uIEdpYW0gd3JvdGU6Cj4+IE9uIFdlZCwgTm92IDIzLCAyMDExIGF0IDc6MDcg
UE0sIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+IHdyb3RlOgo+PiA+IE9u
IFdlZCwgMjAxMS0xMS0yMyBhdCAxMDo1NiArMDAwMCwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3Rl
Ogo+PiA+PiBPbiBUdWUsIDIyIE5vdiAyMDExLCBUZWNrIENob29uIEdpYW0gd3JvdGU6Cj4+ID4+
ID4gPj4gPj4gVGhhdCBtZWFucyBkZWZhdWx0IHZhbHVlIGNoYW5nZWQgaWYgaXQgaXMgdW5zZXQg
Zm9yIGF1dG9iYWxsb29uPwo+PiA+PiA+ID4+ID4+IE9yaWdpbmFsIG9uZSBpcyBjb21tZW50ZWQg
d2l0aCAjYXV0b2JhbGxvb24gPSAxIGluIC9ldGMveGVuL3hsLmNvbmYgc28KPj4gPj4gPiA+PiA+
PiBpdCBpcyB1bnNldCBJIGd1ZXNzIHNvIHRoZSBkZWZhdWx0IHZhbHVlIGZvciBhdXRvYmFsbG9v
biBmb3IgYy9zIDIzMTEwCj4+ID4+ID4gPj4gPj4gaXMgYXV0b2JhbGxvb249MCB3aGVyZSBjL3Mg
MjMxOTAgaXMgYXV0b2JhbGxvb249MT8gw4PGkj/Dg+KAmsOCIEp1c3Qgc29tZQo+PiA+PiA+ID4+
ID4+IGd1ZXNzaW5nLi4uIC4uLgo+PiA+PiA+ID4KPj4gPj4gPiA+IEF1dG9iYWxsb29uIGFuZCBk
b20wX21lbSBhcmUgaW5jb21wYXRpYmxlLgo+PiA+PiA+ID4gSSBkb24ndCB0aGluayB0aGVyZSBh
cmUgYW55IHJlbGV2YW50IGRpZmZlcmVuY2VzIGJldHdlZW4gMjMxMTAgYW5kIDIzMTkwCj4+ID4+
ID4gPiBvbiB4ZW4tdW5zdGFibGUsIG1heWJlIHlvdSB1c2VkIHRvIHN0YXJ0IGRvbTAgd2l0aG91
dCBkb20wX21lbSBiZWZvcmU/Cj4+ID4+ID4KPj4gPj4gPiBOb3BlLi4uIGFsbCBteSBzZXJ2ZXJz
IHdpbGwgYWx3YXlzIGhhdmUgdGhvc2UgZG9tMF9tZW0gc2V0LiDCoEl0IGlzCj4+ID4+ID4gZnJv
bSB4ZW4tNC4xLXRlc3Rpbmcgbm90IHhlbi11bnN0YWJsZSBmb3IgdGhlIHR3byBjaGFuZ2VzZXQu
Cj4+ID4+Cj4+ID4+IEkgc3RpbGwgY2Fubm90IHNlZSBhbnl0aGluZyBpbiB0aGF0IHJhbmdlLiBI
b3dldmVyIGFzIEkgc2FpZCBiZWZvcmUsIGl0Cj4+ID4+IGlzIGV4cGVjdGVkIHRoYXQgd2l0aCBk
b20wX21lbSBzZXQgYXV0b2JhbGxvb24gbmVlZHMgdG8gYmUgZGlzYWJsZWQuCj4+ID4KPj4gPiBX
ZSBzdGlsbCBoYXZlbid0IHNlZW4gdGhlIGZ1bGwgbm9kZSBJRHMgb2YgdGhlIGNoYW5nZXNldHMg
d2hpY2ggSSBhc2tlZAo+PiA+IGZvciBzbyBpdCBpcyBub3Qgb2J2aW91cyB0aGF0IHdlIGFyZSBh
Y3R1YWxseSBsb29raW5nIGF0IHRoZSBzYW1lIHJhbmdlCj4+ID4gb2YgY2hhbmdlc2V0cy4uLgo+
Pgo+PiBTb3JyeSwgSSBhbSBhY3R1YWxseSBub3Qgc3VyZSB3aGF0IElEIHlvdSBhcmUgYXNraW5n
IDooCj4+Cj4+IENoYW5nZXNldHMgZGV0YWlscyBhcyBiZWxvdzoKPj4KPj4gY2hhbmdlc2V0OiDC
oCAyMzExMDo0ZDVjNzYyNDhkZTMKPgo+IFRoZSAiMjMxMTAiIGJpdCBoZXJlIGlzIG9ubHkgbG9j
YWxseSByZWxldmFudCB0byB0aGUgcmVwbyB5b3UgYXJlCj4gbG9va2luZyBhdCBzbyB5b3UgY2Fu
bm90IHJlbGlhYmx5IGlkZW50aWZ5IGEgY2hhbmdlc2V0IHRvIHNvbWVvbmUgZWxzZQo+IHVzaW5n
IHRoYXQgbnVtYmVyLiBPbmx5IHRoZSAiNGQ1Yzc2MjQ4ZGUzIiBpcyBhIGdsb2JhbCBpZGVudGlm
aWVyIGFuZAo+IGNhbiB0aGVyZWZvcmUgYmUgZXhjaGFuZ2VkLgoKVW5kZXJzdG9vZCA6KQoKPgo+
PiB1c2VyOiDCoCDCoCDCoCDCoFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5l
ZHU+Cj4+IGRhdGU6IMKgIMKgIMKgIMKgU2F0IEp1bCAyMyAwOTowMToyNSAyMDExICswMTAwCj4+
IHN1bW1hcnk6IMKgIMKgIHhlbmQ6IHJlbW92ZSBQQ0kgZGV2aWNlIGxpc3RpbmcgZnJvbSBOZXRC
U0QsIHNpbmNlIGl0J3MgTGludXgKPj4KPj4gY2hhbmdlc2V0OiDCoCAyMzE5MDo1YTAwY2NmYzYz
OTEKPj4gdXNlcjogwqAgwqAgwqAgwqBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVs
bGluaUBldS5jaXRyaXguY29tPgo+PiBkYXRlOiDCoCDCoCDCoCDCoEZyaSBOb3YgMTggMTM6Mzg6
MDUgMjAxMSArMDAwMAo+PiBzdW1tYXJ5OiDCoCDCoCB4ODY6IHJlLWluamVjdCBlbXVsYXRlZCBs
ZXZlbCBwaXJxcyBpbiBQViBvbiBIVk0gZ3Vlc3RzCj4+IGlmIHN0aWxsIGFzc2VydGVkCj4KPgo+
IFVuZm9ydHVuYXRlbHkgSSBzdGlsbCBkb24ndCBzZWUgYW55dGhpbmcgcmVsZXZhbnQgYmV0d2Vl
biB0aGVzZQo+IGNoYW5nZXNldHMgc28gSSd2ZSBubyBpZGVhIHdoeSB0aGlzIHNlZW1zIHRvIGJl
IGEgbmV3IGlzc3VlLiBBcmUgeW91Cj4gX3Bvc2l0aXZlXyB0aGF0IHlvdSBkaWRuJ3QgY2hhbmdl
IGFueXRoaW5nIGVsc2UgYWJvdXQgeW91ciBzeXN0ZW0KPiBjb25maWd1cmF0aW9uIG9uIHVwZ3Jh
ZGU/CgpJIGRvbid0IGNoYW5nZSBzZXR0aW5ncyBvbmNlIGl0IGlzIGRlcGxveWVkIGFuZCBpbiBw
cm9kdWN0aW9uIHVzZSBmb3IKeGVuIHNlcnZlcnMuICBJbiBmYWN0LCBhbGwgd2lsbCBiZSBpZGVu
dGljYWwganVzdCB0aGUgYW1vdW50IG9mIG1lbW9yeQp0byBhbGxvY2F0ZSB0byBkb20wIGFyZSBk
aWZmZXJlbnQgZGVwZW5kaW5nIG9uIHRoZSBzZXJ2ZXIgdG90YWwgYW1vdW50Cm9mIFJBTS4KCj4K
Pj4gPj4gTWF5YmUgaXQgaXMgd29ydGggZG9jdW1lbnRpbmcgdGhpcyBzb21ld2hlcmUsIGFueSBz
dWdnZXN0aW9ucyB3aGVyZT8KPj4gPgo+PiA+IHhsIG1hbiBwYWdlPyBQZXJoYXBzIHdlIGFsc28g
bmVlZCBhIHNlcGFyYXRlIC9ldGMveGwuY2ZnIChvciB3aGF0ZXZlcgo+PiA+IHRoZSBwYXRoIGlz
KSBwYWdlPwo+Pgo+PiBTaG91bGRuJ3QgaXQgYmUgeGwuY29uZiBpbnN0ZWFkIG9mIHhsLmNmZz8g
wqB4bCBtYW4gcGFnZSB3aWxsIGhlbHBzIGEKPj4gbG90IGVzcGVjaWFsbHkgZm9yIHRob3NlIG9m
IHVzIHN3aXRjaGluZyBmcm9tIHhtIHRvIHhsLgo+Cj4gSXQgc2hvdWxkIG1hdGNoIHRoZSBhY3R1
YWwgZmlsZW5hbWUgd2hpY2ggZG9lcyBhcHBlYXIgdG8gYmUgeGwuY29uZiBub3QKPiBjZmcuCgpP
aCBvay4gIEluIGZhY3QsIGlmIGdvdCBhZGRpdGlvbmFsIGxpa2UgbWFuIHhsLmNvbmYgd2lsbCBi
ZSBiZXR0ZXIgOnAKCj4KPj4KPj4gPgo+PiA+IElmIHRoZXJlIGlzIGFueXdoZXJlIG9uIHRoZSB3
aWtpIHdoaWNoIHJlY29tbWVuZHMgZG9tMF9tZW09IChhbmQgdGhlcmUKPj4gPiBzaG91bGQgYmUp
IGl0IHNob3VsZCBzaW11bHRhbmVvdXNseSBtZW50aW9uIHRoaXMgc2V0dGluZy4gQXMgc2hvdWxk
IGFueQo+PiA+ICJnZXR0aW5nIHN0YXJ0ZWQiIHBhZ2UuCj4+ID4KPj4gPiBPbiB0aGUgb3RoZXIg
aGFuZCBJJ20gbm90IHN1cmUgd2h5IGF1dG9iYWxsb29uIGFuZCBkb20wX21lbSBwbGF5IHNvCj4+
ID4gYmFkbHkgdG9nZXRoZXIuIFN1cmVseSBpZiBkb20wX21lbSBpcyB1c2VkIGF1dG9iYWxsb24g
c2hvdWxkIGp1c3Qgc2VlCj4+ID4gdGhhdCB0aGVyZSBpcyBwbGVudHkgb2YgZnJlZSBSQU0gaW4g
dGhlIHN5c3RlbSBhbmQgbm90IGRvIGFueXRoaW5nPwo+PiA+Cj4+ID4gSWFuLgo+Pgo+PiBGcm9t
IHRoaXMgZXhwZXJpZW5jZSwgYXQgbGVhc3QgSSBsZWFybiBtb3JlIGFib3V0IHhsIGFuZCB3aGF0
Cj4+IGNvbmZpZ3VyYXRpb24gc2hvdWxkIGJlIHNldCBmb3IgbXkgdXNhZ2UvZW52aXJvbm1lbnQu
IMKgTGlrZSBmb3IKPj4gZXhhbXBsZSwgd2hlbiBJIHVzZWQgeGwgY3JlYXRlIGh2bWRvbWFpbi4u
LiB0aG9zZSBpcHRhYmxlcyBmb3J3YXJkCj4+IHJ1bGUgY2hhaW5zIGFyZSBjcmVhdGVkIGFzIHdl
bGwgZm9yIGl0cyB2aWYgYW5kIHRhcCBidXQgd2hlbiB4bAo+PiB0cmlnZ2VyIGh2bWRvbWFpbiBw
b3dlciBvciB4bCBzaHV0ZG93biBodm1kb21haW4uLi4gdGhvc2UgaXB0YWJsZXMKPj4gZm9yd2Fy
ZCBydWxlIGNoYWlucyBhcmUgc3RpbGwgbGVmdCBpbnRhY3QgOiggwqBUaGlzIGlzbid0IGJpZyBp
c3N1ZSBmb3IKPj4gbWUgYXMgSSBoYXZlIGNyZWF0ZWQgc2NyaXB0IHRvIHJlbW92ZSB0aG9zZSB0
aG91Z2guIMKgQW55d2F5LCBJIHdpbGwKPj4gYnJpbmcgdGhpcyB1cCB3aGVuIHlvdSBndXlzIGdv
aW5nIHRvIHJlbGVhc2UgeGVuLTQuMi1yYy4uLiAuLi4gYXMgdGhpcwo+PiB0aHJlYWQgaXMgbm90
IGZvciBtZSBJIGtub3cuCj4KPiBUaGF0IHNvdW5kcyBsaWtlIGEgYnVnLCB0aGVyZSdzIG5vIG5l
ZWQgdG8gd2FpdCBmb3IgYW4gcmMgcmVsZWFzZSB0bwo+IHJlcG9ydCBhIGJ1Zy4KCkkgdGhpbmsg
SSByZXBvcnRlZCBvbmNlIGJlZm9yZS4uLiBsZXQgc2VlLi4uIGhlcmU6Cmh0dHA6Ly9vbGQtbGlz
dC1hcmNoaXZlcy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTEtMDQvbXNnMDA5
NzIuaHRtbAoKVGhhbmtzLgoKS2luZGVzdCByZWdhcmRzLApHaWFtIFRlY2sgQ2hvb24KCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNv
dXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:47:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:47:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBIF-0000Sx-9R; Wed, 23 Nov 2011 11:47:11 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RTBID-0000Ss-Cp
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:47:09 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322048798!2700284!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17486 invoked from network); 23 Nov 2011 11:46:39 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:46:39 -0000
Received: by qyk31 with SMTP id 31so1444415qyk.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 03:46:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=rzKKeJfqtN6fhmKVvsjsg6kCNdpri+6zXij8K5CjYZw=;
	b=SN6AwQgwmv0AvqR1gidzECT8CIVIv0riH/w3IGQ56kL33zF5iaAvKtpKKPLLwSZITC
	sRH6B7h4PTH77JBFTItZhaS6ZLsVctISSYLXCBnTRRds10OPGZ3o8AtYzBaQksKR2N6c
	9lGsxNbr1s4Zz4X1XIWZZ4AbGMWsMYFceKJ5Q=
MIME-Version: 1.0
Received: by 10.68.20.234 with SMTP id q10mr7521925pbe.27.1322048797587; Wed,
	23 Nov 2011 03:46:37 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Wed, 23 Nov 2011 03:46:37 -0800 (PST)
In-Reply-To: <1322048085.1005.81.camel@zakaz.uk.xensource.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
	<1322048085.1005.81.camel@zakaz.uk.xensource.com>
Date: Wed, 23 Nov 2011 19:46:37 +0800
Message-ID: <CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBOb3YgMjMsIDIwMTEgYXQgNzozNCBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gT24gV2VkLCAyMDExLTExLTIzIGF0IDExOjMwICswMDAw
LCBUZWNrIENob29uIEdpYW0gd3JvdGU6Cj4+IE9uIFdlZCwgTm92IDIzLCAyMDExIGF0IDc6MDcg
UE0sIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+IHdyb3RlOgo+PiA+IE9u
IFdlZCwgMjAxMS0xMS0yMyBhdCAxMDo1NiArMDAwMCwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3Rl
Ogo+PiA+PiBPbiBUdWUsIDIyIE5vdiAyMDExLCBUZWNrIENob29uIEdpYW0gd3JvdGU6Cj4+ID4+
ID4gPj4gPj4gVGhhdCBtZWFucyBkZWZhdWx0IHZhbHVlIGNoYW5nZWQgaWYgaXQgaXMgdW5zZXQg
Zm9yIGF1dG9iYWxsb29uPwo+PiA+PiA+ID4+ID4+IE9yaWdpbmFsIG9uZSBpcyBjb21tZW50ZWQg
d2l0aCAjYXV0b2JhbGxvb24gPSAxIGluIC9ldGMveGVuL3hsLmNvbmYgc28KPj4gPj4gPiA+PiA+
PiBpdCBpcyB1bnNldCBJIGd1ZXNzIHNvIHRoZSBkZWZhdWx0IHZhbHVlIGZvciBhdXRvYmFsbG9v
biBmb3IgYy9zIDIzMTEwCj4+ID4+ID4gPj4gPj4gaXMgYXV0b2JhbGxvb249MCB3aGVyZSBjL3Mg
MjMxOTAgaXMgYXV0b2JhbGxvb249MT8gw4PGkj/Dg+KAmsOCIEp1c3Qgc29tZQo+PiA+PiA+ID4+
ID4+IGd1ZXNzaW5nLi4uIC4uLgo+PiA+PiA+ID4KPj4gPj4gPiA+IEF1dG9iYWxsb29uIGFuZCBk
b20wX21lbSBhcmUgaW5jb21wYXRpYmxlLgo+PiA+PiA+ID4gSSBkb24ndCB0aGluayB0aGVyZSBh
cmUgYW55IHJlbGV2YW50IGRpZmZlcmVuY2VzIGJldHdlZW4gMjMxMTAgYW5kIDIzMTkwCj4+ID4+
ID4gPiBvbiB4ZW4tdW5zdGFibGUsIG1heWJlIHlvdSB1c2VkIHRvIHN0YXJ0IGRvbTAgd2l0aG91
dCBkb20wX21lbSBiZWZvcmU/Cj4+ID4+ID4KPj4gPj4gPiBOb3BlLi4uIGFsbCBteSBzZXJ2ZXJz
IHdpbGwgYWx3YXlzIGhhdmUgdGhvc2UgZG9tMF9tZW0gc2V0LiDCoEl0IGlzCj4+ID4+ID4gZnJv
bSB4ZW4tNC4xLXRlc3Rpbmcgbm90IHhlbi11bnN0YWJsZSBmb3IgdGhlIHR3byBjaGFuZ2VzZXQu
Cj4+ID4+Cj4+ID4+IEkgc3RpbGwgY2Fubm90IHNlZSBhbnl0aGluZyBpbiB0aGF0IHJhbmdlLiBI
b3dldmVyIGFzIEkgc2FpZCBiZWZvcmUsIGl0Cj4+ID4+IGlzIGV4cGVjdGVkIHRoYXQgd2l0aCBk
b20wX21lbSBzZXQgYXV0b2JhbGxvb24gbmVlZHMgdG8gYmUgZGlzYWJsZWQuCj4+ID4KPj4gPiBX
ZSBzdGlsbCBoYXZlbid0IHNlZW4gdGhlIGZ1bGwgbm9kZSBJRHMgb2YgdGhlIGNoYW5nZXNldHMg
d2hpY2ggSSBhc2tlZAo+PiA+IGZvciBzbyBpdCBpcyBub3Qgb2J2aW91cyB0aGF0IHdlIGFyZSBh
Y3R1YWxseSBsb29raW5nIGF0IHRoZSBzYW1lIHJhbmdlCj4+ID4gb2YgY2hhbmdlc2V0cy4uLgo+
Pgo+PiBTb3JyeSwgSSBhbSBhY3R1YWxseSBub3Qgc3VyZSB3aGF0IElEIHlvdSBhcmUgYXNraW5n
IDooCj4+Cj4+IENoYW5nZXNldHMgZGV0YWlscyBhcyBiZWxvdzoKPj4KPj4gY2hhbmdlc2V0OiDC
oCAyMzExMDo0ZDVjNzYyNDhkZTMKPgo+IFRoZSAiMjMxMTAiIGJpdCBoZXJlIGlzIG9ubHkgbG9j
YWxseSByZWxldmFudCB0byB0aGUgcmVwbyB5b3UgYXJlCj4gbG9va2luZyBhdCBzbyB5b3UgY2Fu
bm90IHJlbGlhYmx5IGlkZW50aWZ5IGEgY2hhbmdlc2V0IHRvIHNvbWVvbmUgZWxzZQo+IHVzaW5n
IHRoYXQgbnVtYmVyLiBPbmx5IHRoZSAiNGQ1Yzc2MjQ4ZGUzIiBpcyBhIGdsb2JhbCBpZGVudGlm
aWVyIGFuZAo+IGNhbiB0aGVyZWZvcmUgYmUgZXhjaGFuZ2VkLgoKVW5kZXJzdG9vZCA6KQoKPgo+
PiB1c2VyOiDCoCDCoCDCoCDCoFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5l
ZHU+Cj4+IGRhdGU6IMKgIMKgIMKgIMKgU2F0IEp1bCAyMyAwOTowMToyNSAyMDExICswMTAwCj4+
IHN1bW1hcnk6IMKgIMKgIHhlbmQ6IHJlbW92ZSBQQ0kgZGV2aWNlIGxpc3RpbmcgZnJvbSBOZXRC
U0QsIHNpbmNlIGl0J3MgTGludXgKPj4KPj4gY2hhbmdlc2V0OiDCoCAyMzE5MDo1YTAwY2NmYzYz
OTEKPj4gdXNlcjogwqAgwqAgwqAgwqBTdGVmYW5vIFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVs
bGluaUBldS5jaXRyaXguY29tPgo+PiBkYXRlOiDCoCDCoCDCoCDCoEZyaSBOb3YgMTggMTM6Mzg6
MDUgMjAxMSArMDAwMAo+PiBzdW1tYXJ5OiDCoCDCoCB4ODY6IHJlLWluamVjdCBlbXVsYXRlZCBs
ZXZlbCBwaXJxcyBpbiBQViBvbiBIVk0gZ3Vlc3RzCj4+IGlmIHN0aWxsIGFzc2VydGVkCj4KPgo+
IFVuZm9ydHVuYXRlbHkgSSBzdGlsbCBkb24ndCBzZWUgYW55dGhpbmcgcmVsZXZhbnQgYmV0d2Vl
biB0aGVzZQo+IGNoYW5nZXNldHMgc28gSSd2ZSBubyBpZGVhIHdoeSB0aGlzIHNlZW1zIHRvIGJl
IGEgbmV3IGlzc3VlLiBBcmUgeW91Cj4gX3Bvc2l0aXZlXyB0aGF0IHlvdSBkaWRuJ3QgY2hhbmdl
IGFueXRoaW5nIGVsc2UgYWJvdXQgeW91ciBzeXN0ZW0KPiBjb25maWd1cmF0aW9uIG9uIHVwZ3Jh
ZGU/CgpJIGRvbid0IGNoYW5nZSBzZXR0aW5ncyBvbmNlIGl0IGlzIGRlcGxveWVkIGFuZCBpbiBw
cm9kdWN0aW9uIHVzZSBmb3IKeGVuIHNlcnZlcnMuICBJbiBmYWN0LCBhbGwgd2lsbCBiZSBpZGVu
dGljYWwganVzdCB0aGUgYW1vdW50IG9mIG1lbW9yeQp0byBhbGxvY2F0ZSB0byBkb20wIGFyZSBk
aWZmZXJlbnQgZGVwZW5kaW5nIG9uIHRoZSBzZXJ2ZXIgdG90YWwgYW1vdW50Cm9mIFJBTS4KCj4K
Pj4gPj4gTWF5YmUgaXQgaXMgd29ydGggZG9jdW1lbnRpbmcgdGhpcyBzb21ld2hlcmUsIGFueSBz
dWdnZXN0aW9ucyB3aGVyZT8KPj4gPgo+PiA+IHhsIG1hbiBwYWdlPyBQZXJoYXBzIHdlIGFsc28g
bmVlZCBhIHNlcGFyYXRlIC9ldGMveGwuY2ZnIChvciB3aGF0ZXZlcgo+PiA+IHRoZSBwYXRoIGlz
KSBwYWdlPwo+Pgo+PiBTaG91bGRuJ3QgaXQgYmUgeGwuY29uZiBpbnN0ZWFkIG9mIHhsLmNmZz8g
wqB4bCBtYW4gcGFnZSB3aWxsIGhlbHBzIGEKPj4gbG90IGVzcGVjaWFsbHkgZm9yIHRob3NlIG9m
IHVzIHN3aXRjaGluZyBmcm9tIHhtIHRvIHhsLgo+Cj4gSXQgc2hvdWxkIG1hdGNoIHRoZSBhY3R1
YWwgZmlsZW5hbWUgd2hpY2ggZG9lcyBhcHBlYXIgdG8gYmUgeGwuY29uZiBub3QKPiBjZmcuCgpP
aCBvay4gIEluIGZhY3QsIGlmIGdvdCBhZGRpdGlvbmFsIGxpa2UgbWFuIHhsLmNvbmYgd2lsbCBi
ZSBiZXR0ZXIgOnAKCj4KPj4KPj4gPgo+PiA+IElmIHRoZXJlIGlzIGFueXdoZXJlIG9uIHRoZSB3
aWtpIHdoaWNoIHJlY29tbWVuZHMgZG9tMF9tZW09IChhbmQgdGhlcmUKPj4gPiBzaG91bGQgYmUp
IGl0IHNob3VsZCBzaW11bHRhbmVvdXNseSBtZW50aW9uIHRoaXMgc2V0dGluZy4gQXMgc2hvdWxk
IGFueQo+PiA+ICJnZXR0aW5nIHN0YXJ0ZWQiIHBhZ2UuCj4+ID4KPj4gPiBPbiB0aGUgb3RoZXIg
aGFuZCBJJ20gbm90IHN1cmUgd2h5IGF1dG9iYWxsb29uIGFuZCBkb20wX21lbSBwbGF5IHNvCj4+
ID4gYmFkbHkgdG9nZXRoZXIuIFN1cmVseSBpZiBkb20wX21lbSBpcyB1c2VkIGF1dG9iYWxsb24g
c2hvdWxkIGp1c3Qgc2VlCj4+ID4gdGhhdCB0aGVyZSBpcyBwbGVudHkgb2YgZnJlZSBSQU0gaW4g
dGhlIHN5c3RlbSBhbmQgbm90IGRvIGFueXRoaW5nPwo+PiA+Cj4+ID4gSWFuLgo+Pgo+PiBGcm9t
IHRoaXMgZXhwZXJpZW5jZSwgYXQgbGVhc3QgSSBsZWFybiBtb3JlIGFib3V0IHhsIGFuZCB3aGF0
Cj4+IGNvbmZpZ3VyYXRpb24gc2hvdWxkIGJlIHNldCBmb3IgbXkgdXNhZ2UvZW52aXJvbm1lbnQu
IMKgTGlrZSBmb3IKPj4gZXhhbXBsZSwgd2hlbiBJIHVzZWQgeGwgY3JlYXRlIGh2bWRvbWFpbi4u
LiB0aG9zZSBpcHRhYmxlcyBmb3J3YXJkCj4+IHJ1bGUgY2hhaW5zIGFyZSBjcmVhdGVkIGFzIHdl
bGwgZm9yIGl0cyB2aWYgYW5kIHRhcCBidXQgd2hlbiB4bAo+PiB0cmlnZ2VyIGh2bWRvbWFpbiBw
b3dlciBvciB4bCBzaHV0ZG93biBodm1kb21haW4uLi4gdGhvc2UgaXB0YWJsZXMKPj4gZm9yd2Fy
ZCBydWxlIGNoYWlucyBhcmUgc3RpbGwgbGVmdCBpbnRhY3QgOiggwqBUaGlzIGlzbid0IGJpZyBp
c3N1ZSBmb3IKPj4gbWUgYXMgSSBoYXZlIGNyZWF0ZWQgc2NyaXB0IHRvIHJlbW92ZSB0aG9zZSB0
aG91Z2guIMKgQW55d2F5LCBJIHdpbGwKPj4gYnJpbmcgdGhpcyB1cCB3aGVuIHlvdSBndXlzIGdv
aW5nIHRvIHJlbGVhc2UgeGVuLTQuMi1yYy4uLiAuLi4gYXMgdGhpcwo+PiB0aHJlYWQgaXMgbm90
IGZvciBtZSBJIGtub3cuCj4KPiBUaGF0IHNvdW5kcyBsaWtlIGEgYnVnLCB0aGVyZSdzIG5vIG5l
ZWQgdG8gd2FpdCBmb3IgYW4gcmMgcmVsZWFzZSB0bwo+IHJlcG9ydCBhIGJ1Zy4KCkkgdGhpbmsg
SSByZXBvcnRlZCBvbmNlIGJlZm9yZS4uLiBsZXQgc2VlLi4uIGhlcmU6Cmh0dHA6Ly9vbGQtbGlz
dC1hcmNoaXZlcy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMTEtMDQvbXNnMDA5
NzIuaHRtbAoKVGhhbmtzLgoKS2luZGVzdCByZWdhcmRzLApHaWFtIFRlY2sgQ2hvb24KCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNv
dXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:55:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:55:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBPx-0000h1-DG; Wed, 23 Nov 2011 11:55:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTBPv-0000gv-RX
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:55:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322049257!45730206!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27585 invoked from network); 23 Nov 2011 11:54:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:54:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9087322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:54:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:54:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Wed, 23 Nov 2011 11:54:42 +0000
In-Reply-To: <CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
	<1322048085.1005.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322049282.1005.90.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTIzIGF0IDExOjQ2ICswMDAwLCBUZWNrIENob29uIEdpYW0gd3JvdGU6
Cj4gT24gV2VkLCBOb3YgMjMsIDIwMTEgYXQgNzozNCBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2Ft
cGJlbGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gPiBPbiBXZWQsIDIwMTEtMTEtMjMgYXQgMTE6MzAg
KzAwMDAsIFRlY2sgQ2hvb24gR2lhbSB3cm90ZToKPiA+PiBPbiBXZWQsIE5vdiAyMywgMjAxMSBh
dCA3OjA3IFBNLCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPiB3cm90ZToK
PiA+PiA+IE9uIFdlZCwgMjAxMS0xMS0yMyBhdCAxMDo1NiArMDAwMCwgU3RlZmFubyBTdGFiZWxs
aW5pIHdyb3RlOgo+ID4+ID4+IE9uIFR1ZSwgMjIgTm92IDIwMTEsIFRlY2sgQ2hvb24gR2lhbSB3
cm90ZToKPiA+PiA+PiA+ID4+ID4+IFRoYXQgbWVhbnMgZGVmYXVsdCB2YWx1ZSBjaGFuZ2VkIGlm
IGl0IGlzIHVuc2V0IGZvciBhdXRvYmFsbG9vbj8KPiA+PiA+PiA+ID4+ID4+IE9yaWdpbmFsIG9u
ZSBpcyBjb21tZW50ZWQgd2l0aCAjYXV0b2JhbGxvb24gPSAxIGluIC9ldGMveGVuL3hsLmNvbmYg
c28KPiA+PiA+PiA+ID4+ID4+IGl0IGlzIHVuc2V0IEkgZ3Vlc3Mgc28gdGhlIGRlZmF1bHQgdmFs
dWUgZm9yIGF1dG9iYWxsb29uIGZvciBjL3MgMjMxMTAKPiA+PiA+PiA+ID4+ID4+IGlzIGF1dG9i
YWxsb29uPTAgd2hlcmUgYy9zIDIzMTkwIGlzIGF1dG9iYWxsb29uPTE/IMODxpI/w4PigJrDgiBK
dXN0IHNvbWUKPiA+PiA+PiA+ID4+ID4+IGd1ZXNzaW5nLi4uIC4uLgo+ID4+ID4+ID4gPgo+ID4+
ID4+ID4gPiBBdXRvYmFsbG9vbiBhbmQgZG9tMF9tZW0gYXJlIGluY29tcGF0aWJsZS4KPiA+PiA+
PiA+ID4gSSBkb24ndCB0aGluayB0aGVyZSBhcmUgYW55IHJlbGV2YW50IGRpZmZlcmVuY2VzIGJl
dHdlZW4gMjMxMTAgYW5kIDIzMTkwCj4gPj4gPj4gPiA+IG9uIHhlbi11bnN0YWJsZSwgbWF5YmUg
eW91IHVzZWQgdG8gc3RhcnQgZG9tMCB3aXRob3V0IGRvbTBfbWVtIGJlZm9yZT8KPiA+PiA+PiA+
Cj4gPj4gPj4gPiBOb3BlLi4uIGFsbCBteSBzZXJ2ZXJzIHdpbGwgYWx3YXlzIGhhdmUgdGhvc2Ug
ZG9tMF9tZW0gc2V0LiAgSXQgaXMKPiA+PiA+PiA+IGZyb20geGVuLTQuMS10ZXN0aW5nIG5vdCB4
ZW4tdW5zdGFibGUgZm9yIHRoZSB0d28gY2hhbmdlc2V0Lgo+ID4+ID4+Cj4gPj4gPj4gSSBzdGls
bCBjYW5ub3Qgc2VlIGFueXRoaW5nIGluIHRoYXQgcmFuZ2UuIEhvd2V2ZXIgYXMgSSBzYWlkIGJl
Zm9yZSwgaXQKPiA+PiA+PiBpcyBleHBlY3RlZCB0aGF0IHdpdGggZG9tMF9tZW0gc2V0IGF1dG9i
YWxsb29uIG5lZWRzIHRvIGJlIGRpc2FibGVkLgo+ID4+ID4KPiA+PiA+IFdlIHN0aWxsIGhhdmVu
J3Qgc2VlbiB0aGUgZnVsbCBub2RlIElEcyBvZiB0aGUgY2hhbmdlc2V0cyB3aGljaCBJIGFza2Vk
Cj4gPj4gPiBmb3Igc28gaXQgaXMgbm90IG9idmlvdXMgdGhhdCB3ZSBhcmUgYWN0dWFsbHkgbG9v
a2luZyBhdCB0aGUgc2FtZSByYW5nZQo+ID4+ID4gb2YgY2hhbmdlc2V0cy4uLgo+ID4+Cj4gPj4g
U29ycnksIEkgYW0gYWN0dWFsbHkgbm90IHN1cmUgd2hhdCBJRCB5b3UgYXJlIGFza2luZyA6KAo+
ID4+Cj4gPj4gQ2hhbmdlc2V0cyBkZXRhaWxzIGFzIGJlbG93Ogo+ID4+Cj4gPj4gY2hhbmdlc2V0
OiAgIDIzMTEwOjRkNWM3NjI0OGRlMwo+ID4KPiA+IFRoZSAiMjMxMTAiIGJpdCBoZXJlIGlzIG9u
bHkgbG9jYWxseSByZWxldmFudCB0byB0aGUgcmVwbyB5b3UgYXJlCj4gPiBsb29raW5nIGF0IHNv
IHlvdSBjYW5ub3QgcmVsaWFibHkgaWRlbnRpZnkgYSBjaGFuZ2VzZXQgdG8gc29tZW9uZSBlbHNl
Cj4gPiB1c2luZyB0aGF0IG51bWJlci4gT25seSB0aGUgIjRkNWM3NjI0OGRlMyIgaXMgYSBnbG9i
YWwgaWRlbnRpZmllciBhbmQKPiA+IGNhbiB0aGVyZWZvcmUgYmUgZXhjaGFuZ2VkLgo+IAo+IFVu
ZGVyc3Rvb2QgOikKPiAKPiA+Cj4gPj4gdXNlcjogICAgICAgIFJvZ2VyIFBhdSBNb25uZSA8cm9n
ZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4gPj4gZGF0ZTogICAgICAgIFNhdCBKdWwgMjMgMDk6MDE6
MjUgMjAxMSArMDEwMAo+ID4+IHN1bW1hcnk6ICAgICB4ZW5kOiByZW1vdmUgUENJIGRldmljZSBs
aXN0aW5nIGZyb20gTmV0QlNELCBzaW5jZSBpdCdzIExpbnV4Cj4gPj4KPiA+PiBjaGFuZ2VzZXQ6
ICAgMjMxOTA6NWEwMGNjZmM2MzkxCj4gPj4gdXNlcjogICAgICAgIFN0ZWZhbm8gU3RhYmVsbGlu
aSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+Cj4gPj4gZGF0ZTogICAgICAgIEZy
aSBOb3YgMTggMTM6Mzg6MDUgMjAxMSArMDAwMAo+ID4+IHN1bW1hcnk6ICAgICB4ODY6IHJlLWlu
amVjdCBlbXVsYXRlZCBsZXZlbCBwaXJxcyBpbiBQViBvbiBIVk0gZ3Vlc3RzCj4gPj4gaWYgc3Rp
bGwgYXNzZXJ0ZWQKPiA+Cj4gPgo+ID4gVW5mb3J0dW5hdGVseSBJIHN0aWxsIGRvbid0IHNlZSBh
bnl0aGluZyByZWxldmFudCBiZXR3ZWVuIHRoZXNlCj4gPiBjaGFuZ2VzZXRzIHNvIEkndmUgbm8g
aWRlYSB3aHkgdGhpcyBzZWVtcyB0byBiZSBhIG5ldyBpc3N1ZS4gQXJlIHlvdQo+ID4gX3Bvc2l0
aXZlXyB0aGF0IHlvdSBkaWRuJ3QgY2hhbmdlIGFueXRoaW5nIGVsc2UgYWJvdXQgeW91ciBzeXN0
ZW0KPiA+IGNvbmZpZ3VyYXRpb24gb24gdXBncmFkZT8KPiAKPiBJIGRvbid0IGNoYW5nZSBzZXR0
aW5ncyBvbmNlIGl0IGlzIGRlcGxveWVkIGFuZCBpbiBwcm9kdWN0aW9uIHVzZSBmb3IKPiB4ZW4g
c2VydmVycy4gIEluIGZhY3QsIGFsbCB3aWxsIGJlIGlkZW50aWNhbCBqdXN0IHRoZSBhbW91bnQg
b2YgbWVtb3J5Cj4gdG8gYWxsb2NhdGUgdG8gZG9tMCBhcmUgZGlmZmVyZW50IGRlcGVuZGluZyBv
biB0aGUgc2VydmVyIHRvdGFsIGFtb3VudAo+IG9mIFJBTS4KClRoZSBtZXNzYWdlIGlzIChJIHRo
aW5rKSB0cmlnZ2VyZWQgYmFzZWQgb24gdGhlICVhZ2Ugb2YgbWVtb3J5IGFsbG9jYXRlZAp0byBk
b20wIHNvIGlmIGRpZmZlcmVudCBtYWNoaW5lcyBhcmUgZGlmZmVyZW50IHNpemVzIGFuZCB0aGVy
ZWZvcmUgaGF2ZQpkaWZmZXJlbnQgdGhyZXNob2xkcyB0aGF0IG1pZ2h0IGV4cGxhaW4gd2h5IGl0
IGlzIG9ubHkgc2VlbiBzb21ldGltZXMuCgo+ID4gVGhhdCBzb3VuZHMgbGlrZSBhIGJ1ZywgdGhl
cmUncyBubyBuZWVkIHRvIHdhaXQgZm9yIGFuIHJjIHJlbGVhc2UgdG8KPiA+IHJlcG9ydCBhIGJ1
Zy4KPiAKPiBJIHRoaW5rIEkgcmVwb3J0ZWQgb25jZSBiZWZvcmUuLi4gbGV0IHNlZS4uLiBoZXJl
Ogo+IGh0dHA6Ly9vbGQtbGlzdC1hcmNoaXZlcy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRl
dmVsLzIwMTEtMDQvbXNnMDA5NzIuaHRtbAoKSSdtIHNvcnJ5IHRoaXMgYXBwZWFycyB0byBoYXZl
IHNsaXBwZWQgdW5kZXIgdGhlIHJhZGFyIGF0IHRoZSB0aW1lLiBJCnRoaW5rIGl0IHdvdWxkIGJl
IHdvcnRoIHJlcG9zdGluZyBpbiBhIG5ldyB0aHJlYWQuCgpJYW4uCgo+IAo+IFRoYW5rcy4KPiAK
PiBLaW5kZXN0IHJlZ2FyZHMsCj4gR2lhbSBUZWNrIENob29uCgoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Nov 23 11:55:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 11:55:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBPx-0000h1-DG; Wed, 23 Nov 2011 11:55:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTBPv-0000gv-RX
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 11:55:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322049257!45730206!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27585 invoked from network); 23 Nov 2011 11:54:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:54:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9087322"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 11:54:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 11:54:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Wed, 23 Nov 2011 11:54:42 +0000
In-Reply-To: <CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
	<1322048085.1005.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322049282.1005.90.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDExLTExLTIzIGF0IDExOjQ2ICswMDAwLCBUZWNrIENob29uIEdpYW0gd3JvdGU6
Cj4gT24gV2VkLCBOb3YgMjMsIDIwMTEgYXQgNzozNCBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2Ft
cGJlbGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gPiBPbiBXZWQsIDIwMTEtMTEtMjMgYXQgMTE6MzAg
KzAwMDAsIFRlY2sgQ2hvb24gR2lhbSB3cm90ZToKPiA+PiBPbiBXZWQsIE5vdiAyMywgMjAxMSBh
dCA3OjA3IFBNLCBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPiB3cm90ZToK
PiA+PiA+IE9uIFdlZCwgMjAxMS0xMS0yMyBhdCAxMDo1NiArMDAwMCwgU3RlZmFubyBTdGFiZWxs
aW5pIHdyb3RlOgo+ID4+ID4+IE9uIFR1ZSwgMjIgTm92IDIwMTEsIFRlY2sgQ2hvb24gR2lhbSB3
cm90ZToKPiA+PiA+PiA+ID4+ID4+IFRoYXQgbWVhbnMgZGVmYXVsdCB2YWx1ZSBjaGFuZ2VkIGlm
IGl0IGlzIHVuc2V0IGZvciBhdXRvYmFsbG9vbj8KPiA+PiA+PiA+ID4+ID4+IE9yaWdpbmFsIG9u
ZSBpcyBjb21tZW50ZWQgd2l0aCAjYXV0b2JhbGxvb24gPSAxIGluIC9ldGMveGVuL3hsLmNvbmYg
c28KPiA+PiA+PiA+ID4+ID4+IGl0IGlzIHVuc2V0IEkgZ3Vlc3Mgc28gdGhlIGRlZmF1bHQgdmFs
dWUgZm9yIGF1dG9iYWxsb29uIGZvciBjL3MgMjMxMTAKPiA+PiA+PiA+ID4+ID4+IGlzIGF1dG9i
YWxsb29uPTAgd2hlcmUgYy9zIDIzMTkwIGlzIGF1dG9iYWxsb29uPTE/IMODxpI/w4PigJrDgiBK
dXN0IHNvbWUKPiA+PiA+PiA+ID4+ID4+IGd1ZXNzaW5nLi4uIC4uLgo+ID4+ID4+ID4gPgo+ID4+
ID4+ID4gPiBBdXRvYmFsbG9vbiBhbmQgZG9tMF9tZW0gYXJlIGluY29tcGF0aWJsZS4KPiA+PiA+
PiA+ID4gSSBkb24ndCB0aGluayB0aGVyZSBhcmUgYW55IHJlbGV2YW50IGRpZmZlcmVuY2VzIGJl
dHdlZW4gMjMxMTAgYW5kIDIzMTkwCj4gPj4gPj4gPiA+IG9uIHhlbi11bnN0YWJsZSwgbWF5YmUg
eW91IHVzZWQgdG8gc3RhcnQgZG9tMCB3aXRob3V0IGRvbTBfbWVtIGJlZm9yZT8KPiA+PiA+PiA+
Cj4gPj4gPj4gPiBOb3BlLi4uIGFsbCBteSBzZXJ2ZXJzIHdpbGwgYWx3YXlzIGhhdmUgdGhvc2Ug
ZG9tMF9tZW0gc2V0LiAgSXQgaXMKPiA+PiA+PiA+IGZyb20geGVuLTQuMS10ZXN0aW5nIG5vdCB4
ZW4tdW5zdGFibGUgZm9yIHRoZSB0d28gY2hhbmdlc2V0Lgo+ID4+ID4+Cj4gPj4gPj4gSSBzdGls
bCBjYW5ub3Qgc2VlIGFueXRoaW5nIGluIHRoYXQgcmFuZ2UuIEhvd2V2ZXIgYXMgSSBzYWlkIGJl
Zm9yZSwgaXQKPiA+PiA+PiBpcyBleHBlY3RlZCB0aGF0IHdpdGggZG9tMF9tZW0gc2V0IGF1dG9i
YWxsb29uIG5lZWRzIHRvIGJlIGRpc2FibGVkLgo+ID4+ID4KPiA+PiA+IFdlIHN0aWxsIGhhdmVu
J3Qgc2VlbiB0aGUgZnVsbCBub2RlIElEcyBvZiB0aGUgY2hhbmdlc2V0cyB3aGljaCBJIGFza2Vk
Cj4gPj4gPiBmb3Igc28gaXQgaXMgbm90IG9idmlvdXMgdGhhdCB3ZSBhcmUgYWN0dWFsbHkgbG9v
a2luZyBhdCB0aGUgc2FtZSByYW5nZQo+ID4+ID4gb2YgY2hhbmdlc2V0cy4uLgo+ID4+Cj4gPj4g
U29ycnksIEkgYW0gYWN0dWFsbHkgbm90IHN1cmUgd2hhdCBJRCB5b3UgYXJlIGFza2luZyA6KAo+
ID4+Cj4gPj4gQ2hhbmdlc2V0cyBkZXRhaWxzIGFzIGJlbG93Ogo+ID4+Cj4gPj4gY2hhbmdlc2V0
OiAgIDIzMTEwOjRkNWM3NjI0OGRlMwo+ID4KPiA+IFRoZSAiMjMxMTAiIGJpdCBoZXJlIGlzIG9u
bHkgbG9jYWxseSByZWxldmFudCB0byB0aGUgcmVwbyB5b3UgYXJlCj4gPiBsb29raW5nIGF0IHNv
IHlvdSBjYW5ub3QgcmVsaWFibHkgaWRlbnRpZnkgYSBjaGFuZ2VzZXQgdG8gc29tZW9uZSBlbHNl
Cj4gPiB1c2luZyB0aGF0IG51bWJlci4gT25seSB0aGUgIjRkNWM3NjI0OGRlMyIgaXMgYSBnbG9i
YWwgaWRlbnRpZmllciBhbmQKPiA+IGNhbiB0aGVyZWZvcmUgYmUgZXhjaGFuZ2VkLgo+IAo+IFVu
ZGVyc3Rvb2QgOikKPiAKPiA+Cj4gPj4gdXNlcjogICAgICAgIFJvZ2VyIFBhdSBNb25uZSA8cm9n
ZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4gPj4gZGF0ZTogICAgICAgIFNhdCBKdWwgMjMgMDk6MDE6
MjUgMjAxMSArMDEwMAo+ID4+IHN1bW1hcnk6ICAgICB4ZW5kOiByZW1vdmUgUENJIGRldmljZSBs
aXN0aW5nIGZyb20gTmV0QlNELCBzaW5jZSBpdCdzIExpbnV4Cj4gPj4KPiA+PiBjaGFuZ2VzZXQ6
ICAgMjMxOTA6NWEwMGNjZmM2MzkxCj4gPj4gdXNlcjogICAgICAgIFN0ZWZhbm8gU3RhYmVsbGlu
aSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+Cj4gPj4gZGF0ZTogICAgICAgIEZy
aSBOb3YgMTggMTM6Mzg6MDUgMjAxMSArMDAwMAo+ID4+IHN1bW1hcnk6ICAgICB4ODY6IHJlLWlu
amVjdCBlbXVsYXRlZCBsZXZlbCBwaXJxcyBpbiBQViBvbiBIVk0gZ3Vlc3RzCj4gPj4gaWYgc3Rp
bGwgYXNzZXJ0ZWQKPiA+Cj4gPgo+ID4gVW5mb3J0dW5hdGVseSBJIHN0aWxsIGRvbid0IHNlZSBh
bnl0aGluZyByZWxldmFudCBiZXR3ZWVuIHRoZXNlCj4gPiBjaGFuZ2VzZXRzIHNvIEkndmUgbm8g
aWRlYSB3aHkgdGhpcyBzZWVtcyB0byBiZSBhIG5ldyBpc3N1ZS4gQXJlIHlvdQo+ID4gX3Bvc2l0
aXZlXyB0aGF0IHlvdSBkaWRuJ3QgY2hhbmdlIGFueXRoaW5nIGVsc2UgYWJvdXQgeW91ciBzeXN0
ZW0KPiA+IGNvbmZpZ3VyYXRpb24gb24gdXBncmFkZT8KPiAKPiBJIGRvbid0IGNoYW5nZSBzZXR0
aW5ncyBvbmNlIGl0IGlzIGRlcGxveWVkIGFuZCBpbiBwcm9kdWN0aW9uIHVzZSBmb3IKPiB4ZW4g
c2VydmVycy4gIEluIGZhY3QsIGFsbCB3aWxsIGJlIGlkZW50aWNhbCBqdXN0IHRoZSBhbW91bnQg
b2YgbWVtb3J5Cj4gdG8gYWxsb2NhdGUgdG8gZG9tMCBhcmUgZGlmZmVyZW50IGRlcGVuZGluZyBv
biB0aGUgc2VydmVyIHRvdGFsIGFtb3VudAo+IG9mIFJBTS4KClRoZSBtZXNzYWdlIGlzIChJIHRo
aW5rKSB0cmlnZ2VyZWQgYmFzZWQgb24gdGhlICVhZ2Ugb2YgbWVtb3J5IGFsbG9jYXRlZAp0byBk
b20wIHNvIGlmIGRpZmZlcmVudCBtYWNoaW5lcyBhcmUgZGlmZmVyZW50IHNpemVzIGFuZCB0aGVy
ZWZvcmUgaGF2ZQpkaWZmZXJlbnQgdGhyZXNob2xkcyB0aGF0IG1pZ2h0IGV4cGxhaW4gd2h5IGl0
IGlzIG9ubHkgc2VlbiBzb21ldGltZXMuCgo+ID4gVGhhdCBzb3VuZHMgbGlrZSBhIGJ1ZywgdGhl
cmUncyBubyBuZWVkIHRvIHdhaXQgZm9yIGFuIHJjIHJlbGVhc2UgdG8KPiA+IHJlcG9ydCBhIGJ1
Zy4KPiAKPiBJIHRoaW5rIEkgcmVwb3J0ZWQgb25jZSBiZWZvcmUuLi4gbGV0IHNlZS4uLiBoZXJl
Ogo+IGh0dHA6Ly9vbGQtbGlzdC1hcmNoaXZlcy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRl
dmVsLzIwMTEtMDQvbXNnMDA5NzIuaHRtbAoKSSdtIHNvcnJ5IHRoaXMgYXBwZWFycyB0byBoYXZl
IHNsaXBwZWQgdW5kZXIgdGhlIHJhZGFyIGF0IHRoZSB0aW1lLiBJCnRoaW5rIGl0IHdvdWxkIGJl
IHdvcnRoIHJlcG9zdGluZyBpbiBhIG5ldyB0aHJlYWQuCgpJYW4uCgo+IAo+IFRoYW5rcy4KPiAK
PiBLaW5kZXN0IHJlZ2FyZHMsCj4gR2lhbSBUZWNrIENob29uCgoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:00:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBV5-0000uu-Ov; Wed, 23 Nov 2011 12:00:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RTBV3-0000uc-Tw
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:00:26 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322049594!2647568!1
X-Originating-IP: [209.85.216.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1614 invoked from network); 23 Nov 2011 11:59:55 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:59:55 -0000
Received: by qadz2 with SMTP id z2so74078qad.9
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 03:59:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=g/BIuQQMEO3kK23aZmwz+RHqg4jzTQiMKSOgn1XvTd0=;
	b=ZQJ9lIBlZWJT8wDwax6kcJXk1RvqVKgPcsk7Lj9R24mkpFbK/o7CBsyAhQs9toZOgM
	MqVzCiJrvAtSq4CYYAMDCNdkLEX8iklv2hT3LKMz+g9nX7QlwzlNVS/eahUXbWkWeTQY
	hEMOya/lkOLc8v2XafSIe5RStjlzCgKs27oBQ=
MIME-Version: 1.0
Received: by 10.68.16.5 with SMTP id b5mr7442387pbd.95.1322049593026; Wed, 23
	Nov 2011 03:59:53 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Wed, 23 Nov 2011 03:59:52 -0800 (PST)
In-Reply-To: <1322049282.1005.90.camel@zakaz.uk.xensource.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
	<1322048085.1005.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
	<1322049282.1005.90.camel@zakaz.uk.xensource.com>
Date: Wed, 23 Nov 2011 19:59:52 +0800
Message-ID: <CAEwRVpOVmfKGzL7jFd8k9mH06Ct0tXhb6rZeYnrVpgR3x+mC1Q@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBOb3YgMjMsIDIwMTEgYXQgNzo1NCBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gT24gV2VkLCAyMDExLTExLTIzIGF0IDExOjQ2ICswMDAw
LCBUZWNrIENob29uIEdpYW0gd3JvdGU6Cj4+IE9uIFdlZCwgTm92IDIzLCAyMDExIGF0IDc6MzQg
UE0sIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+IHdyb3RlOgo+PiA+IE9u
IFdlZCwgMjAxMS0xMS0yMyBhdCAxMTozMCArMDAwMCwgVGVjayBDaG9vbiBHaWFtIHdyb3RlOgo+
PiA+PiBPbiBXZWQsIE5vdiAyMywgMjAxMSBhdCA3OjA3IFBNLCBJYW4gQ2FtcGJlbGwgPElhbi5D
YW1wYmVsbEBjaXRyaXguY29tPiB3cm90ZToKPj4gPj4gPiBPbiBXZWQsIDIwMTEtMTEtMjMgYXQg
MTA6NTYgKzAwMDAsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToKPj4gPj4gPj4gT24gVHVlLCAy
MiBOb3YgMjAxMSwgVGVjayBDaG9vbiBHaWFtIHdyb3RlOgo+PiA+PiA+PiA+ID4+ID4+IFRoYXQg
bWVhbnMgZGVmYXVsdCB2YWx1ZSBjaGFuZ2VkIGlmIGl0IGlzIHVuc2V0IGZvciBhdXRvYmFsbG9v
bj8KPj4gPj4gPj4gPiA+PiA+PiBPcmlnaW5hbCBvbmUgaXMgY29tbWVudGVkIHdpdGggI2F1dG9i
YWxsb29uID0gMSBpbiAvZXRjL3hlbi94bC5jb25mIHNvCj4+ID4+ID4+ID4gPj4gPj4gaXQgaXMg
dW5zZXQgSSBndWVzcyBzbyB0aGUgZGVmYXVsdCB2YWx1ZSBmb3IgYXV0b2JhbGxvb24gZm9yIGMv
cyAyMzExMAo+PiA+PiA+PiA+ID4+ID4+IGlzIGF1dG9iYWxsb29uPTAgd2hlcmUgYy9zIDIzMTkw
IGlzIGF1dG9iYWxsb29uPTE/IMODxpI/w4PigJrDgiBKdXN0IHNvbWUKPj4gPj4gPj4gPiA+PiA+
PiBndWVzc2luZy4uLiAuLi4KPj4gPj4gPj4gPiA+Cj4+ID4+ID4+ID4gPiBBdXRvYmFsbG9vbiBh
bmQgZG9tMF9tZW0gYXJlIGluY29tcGF0aWJsZS4KPj4gPj4gPj4gPiA+IEkgZG9uJ3QgdGhpbmsg
dGhlcmUgYXJlIGFueSByZWxldmFudCBkaWZmZXJlbmNlcyBiZXR3ZWVuIDIzMTEwIGFuZCAyMzE5
MAo+PiA+PiA+PiA+ID4gb24geGVuLXVuc3RhYmxlLCBtYXliZSB5b3UgdXNlZCB0byBzdGFydCBk
b20wIHdpdGhvdXQgZG9tMF9tZW0gYmVmb3JlPwo+PiA+PiA+PiA+Cj4+ID4+ID4+ID4gTm9wZS4u
LiBhbGwgbXkgc2VydmVycyB3aWxsIGFsd2F5cyBoYXZlIHRob3NlIGRvbTBfbWVtIHNldC4gwqBJ
dCBpcwo+PiA+PiA+PiA+IGZyb20geGVuLTQuMS10ZXN0aW5nIG5vdCB4ZW4tdW5zdGFibGUgZm9y
IHRoZSB0d28gY2hhbmdlc2V0Lgo+PiA+PiA+Pgo+PiA+PiA+PiBJIHN0aWxsIGNhbm5vdCBzZWUg
YW55dGhpbmcgaW4gdGhhdCByYW5nZS4gSG93ZXZlciBhcyBJIHNhaWQgYmVmb3JlLCBpdAo+PiA+
PiA+PiBpcyBleHBlY3RlZCB0aGF0IHdpdGggZG9tMF9tZW0gc2V0IGF1dG9iYWxsb29uIG5lZWRz
IHRvIGJlIGRpc2FibGVkLgo+PiA+PiA+Cj4+ID4+ID4gV2Ugc3RpbGwgaGF2ZW4ndCBzZWVuIHRo
ZSBmdWxsIG5vZGUgSURzIG9mIHRoZSBjaGFuZ2VzZXRzIHdoaWNoIEkgYXNrZWQKPj4gPj4gPiBm
b3Igc28gaXQgaXMgbm90IG9idmlvdXMgdGhhdCB3ZSBhcmUgYWN0dWFsbHkgbG9va2luZyBhdCB0
aGUgc2FtZSByYW5nZQo+PiA+PiA+IG9mIGNoYW5nZXNldHMuLi4KPj4gPj4KPj4gPj4gU29ycnks
IEkgYW0gYWN0dWFsbHkgbm90IHN1cmUgd2hhdCBJRCB5b3UgYXJlIGFza2luZyA6KAo+PiA+Pgo+
PiA+PiBDaGFuZ2VzZXRzIGRldGFpbHMgYXMgYmVsb3c6Cj4+ID4+Cj4+ID4+IGNoYW5nZXNldDog
wqAgMjMxMTA6NGQ1Yzc2MjQ4ZGUzCj4+ID4KPj4gPiBUaGUgIjIzMTEwIiBiaXQgaGVyZSBpcyBv
bmx5IGxvY2FsbHkgcmVsZXZhbnQgdG8gdGhlIHJlcG8geW91IGFyZQo+PiA+IGxvb2tpbmcgYXQg
c28geW91IGNhbm5vdCByZWxpYWJseSBpZGVudGlmeSBhIGNoYW5nZXNldCB0byBzb21lb25lIGVs
c2UKPj4gPiB1c2luZyB0aGF0IG51bWJlci4gT25seSB0aGUgIjRkNWM3NjI0OGRlMyIgaXMgYSBn
bG9iYWwgaWRlbnRpZmllciBhbmQKPj4gPiBjYW4gdGhlcmVmb3JlIGJlIGV4Y2hhbmdlZC4KPj4K
Pj4gVW5kZXJzdG9vZCA6KQo+Pgo+PiA+Cj4+ID4+IHVzZXI6IMKgIMKgIMKgIMKgUm9nZXIgUGF1
IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4gPj4gZGF0ZTogwqAgwqAgwqAgwqBT
YXQgSnVsIDIzIDA5OjAxOjI1IDIwMTEgKzAxMDAKPj4gPj4gc3VtbWFyeTogwqAgwqAgeGVuZDog
cmVtb3ZlIFBDSSBkZXZpY2UgbGlzdGluZyBmcm9tIE5ldEJTRCwgc2luY2UgaXQncyBMaW51eAo+
PiA+Pgo+PiA+PiBjaGFuZ2VzZXQ6IMKgIDIzMTkwOjVhMDBjY2ZjNjM5MQo+PiA+PiB1c2VyOiDC
oCDCoCDCoCDCoFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20+Cj4+ID4+IGRhdGU6IMKgIMKgIMKgIMKgRnJpIE5vdiAxOCAxMzozODowNSAyMDExICsw
MDAwCj4+ID4+IHN1bW1hcnk6IMKgIMKgIHg4NjogcmUtaW5qZWN0IGVtdWxhdGVkIGxldmVsIHBp
cnFzIGluIFBWIG9uIEhWTSBndWVzdHMKPj4gPj4gaWYgc3RpbGwgYXNzZXJ0ZWQKPj4gPgo+PiA+
Cj4+ID4gVW5mb3J0dW5hdGVseSBJIHN0aWxsIGRvbid0IHNlZSBhbnl0aGluZyByZWxldmFudCBi
ZXR3ZWVuIHRoZXNlCj4+ID4gY2hhbmdlc2V0cyBzbyBJJ3ZlIG5vIGlkZWEgd2h5IHRoaXMgc2Vl
bXMgdG8gYmUgYSBuZXcgaXNzdWUuIEFyZSB5b3UKPj4gPiBfcG9zaXRpdmVfIHRoYXQgeW91IGRp
ZG4ndCBjaGFuZ2UgYW55dGhpbmcgZWxzZSBhYm91dCB5b3VyIHN5c3RlbQo+PiA+IGNvbmZpZ3Vy
YXRpb24gb24gdXBncmFkZT8KPj4KPj4gSSBkb24ndCBjaGFuZ2Ugc2V0dGluZ3Mgb25jZSBpdCBp
cyBkZXBsb3llZCBhbmQgaW4gcHJvZHVjdGlvbiB1c2UgZm9yCj4+IHhlbiBzZXJ2ZXJzLiDCoElu
IGZhY3QsIGFsbCB3aWxsIGJlIGlkZW50aWNhbCBqdXN0IHRoZSBhbW91bnQgb2YgbWVtb3J5Cj4+
IHRvIGFsbG9jYXRlIHRvIGRvbTAgYXJlIGRpZmZlcmVudCBkZXBlbmRpbmcgb24gdGhlIHNlcnZl
ciB0b3RhbCBhbW91bnQKPj4gb2YgUkFNLgo+Cj4gVGhlIG1lc3NhZ2UgaXMgKEkgdGhpbmspIHRy
aWdnZXJlZCBiYXNlZCBvbiB0aGUgJWFnZSBvZiBtZW1vcnkgYWxsb2NhdGVkCj4gdG8gZG9tMCBz
byBpZiBkaWZmZXJlbnQgbWFjaGluZXMgYXJlIGRpZmZlcmVudCBzaXplcyBhbmQgdGhlcmVmb3Jl
IGhhdmUKPiBkaWZmZXJlbnQgdGhyZXNob2xkcyB0aGF0IG1pZ2h0IGV4cGxhaW4gd2h5IGl0IGlz
IG9ubHkgc2VlbiBzb21ldGltZXMuCgpPay4KCj4+ID4gVGhhdCBzb3VuZHMgbGlrZSBhIGJ1Zywg
dGhlcmUncyBubyBuZWVkIHRvIHdhaXQgZm9yIGFuIHJjIHJlbGVhc2UgdG8KPj4gPiByZXBvcnQg
YSBidWcuCj4+Cj4+IEkgdGhpbmsgSSByZXBvcnRlZCBvbmNlIGJlZm9yZS4uLiBsZXQgc2VlLi4u
IGhlcmU6Cj4+IGh0dHA6Ly9vbGQtbGlzdC1hcmNoaXZlcy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwv
eGVuLWRldmVsLzIwMTEtMDQvbXNnMDA5NzIuaHRtbAo+Cj4gSSdtIHNvcnJ5IHRoaXMgYXBwZWFy
cyB0byBoYXZlIHNsaXBwZWQgdW5kZXIgdGhlIHJhZGFyIGF0IHRoZSB0aW1lLiBJCj4gdGhpbmsg
aXQgd291bGQgYmUgd29ydGggcmVwb3N0aW5nIGluIGEgbmV3IHRocmVhZC4KCkkgd2lsbCByZXBv
c3QgbGF0ZXIuICBKdXN0IG9uZSBxdWVzdGlvbi4uLiAuLi4gZG8geW91IGd1eXMgcHJlZmVyIHN1
Y2gKcmVwb3J0cyB0byBiZSBwb3N0ZWQgaW4geGVuLXVzZXJzIG9yIHhlbi1kZXZlbCBtYWlsaW5n
IGxpc3Q/ClNvbWV0aW1lcyBJIHdvbmRlciB3aGljaCBvbmUgaXMgbW9yZSBzdWl0YWJsZS4uLiAu
Li4KClRoYW5rcy4KCktpbmRlc3QgcmVnYXJkcywKR2lhbSBUZWNrIENob29uCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:00:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:00:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBV5-0000uu-Ov; Wed, 23 Nov 2011 12:00:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RTBV3-0000uc-Tw
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:00:26 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322049594!2647568!1
X-Originating-IP: [209.85.216.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1614 invoked from network); 23 Nov 2011 11:59:55 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 11:59:55 -0000
Received: by qadz2 with SMTP id z2so74078qad.9
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 03:59:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=g/BIuQQMEO3kK23aZmwz+RHqg4jzTQiMKSOgn1XvTd0=;
	b=ZQJ9lIBlZWJT8wDwax6kcJXk1RvqVKgPcsk7Lj9R24mkpFbK/o7CBsyAhQs9toZOgM
	MqVzCiJrvAtSq4CYYAMDCNdkLEX8iklv2hT3LKMz+g9nX7QlwzlNVS/eahUXbWkWeTQY
	hEMOya/lkOLc8v2XafSIe5RStjlzCgKs27oBQ=
MIME-Version: 1.0
Received: by 10.68.16.5 with SMTP id b5mr7442387pbd.95.1322049593026; Wed, 23
	Nov 2011 03:59:53 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Wed, 23 Nov 2011 03:59:52 -0800 (PST)
In-Reply-To: <1322049282.1005.90.camel@zakaz.uk.xensource.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
	<1322048085.1005.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
	<1322049282.1005.90.camel@zakaz.uk.xensource.com>
Date: Wed, 23 Nov 2011 19:59:52 +0800
Message-ID: <CAEwRVpOVmfKGzL7jFd8k9mH06Ct0tXhb6rZeYnrVpgR3x+mC1Q@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBOb3YgMjMsIDIwMTEgYXQgNzo1NCBQTSwgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJl
bGxAY2l0cml4LmNvbT4gd3JvdGU6Cj4gT24gV2VkLCAyMDExLTExLTIzIGF0IDExOjQ2ICswMDAw
LCBUZWNrIENob29uIEdpYW0gd3JvdGU6Cj4+IE9uIFdlZCwgTm92IDIzLCAyMDExIGF0IDc6MzQg
UE0sIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+IHdyb3RlOgo+PiA+IE9u
IFdlZCwgMjAxMS0xMS0yMyBhdCAxMTozMCArMDAwMCwgVGVjayBDaG9vbiBHaWFtIHdyb3RlOgo+
PiA+PiBPbiBXZWQsIE5vdiAyMywgMjAxMSBhdCA3OjA3IFBNLCBJYW4gQ2FtcGJlbGwgPElhbi5D
YW1wYmVsbEBjaXRyaXguY29tPiB3cm90ZToKPj4gPj4gPiBPbiBXZWQsIDIwMTEtMTEtMjMgYXQg
MTA6NTYgKzAwMDAsIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToKPj4gPj4gPj4gT24gVHVlLCAy
MiBOb3YgMjAxMSwgVGVjayBDaG9vbiBHaWFtIHdyb3RlOgo+PiA+PiA+PiA+ID4+ID4+IFRoYXQg
bWVhbnMgZGVmYXVsdCB2YWx1ZSBjaGFuZ2VkIGlmIGl0IGlzIHVuc2V0IGZvciBhdXRvYmFsbG9v
bj8KPj4gPj4gPj4gPiA+PiA+PiBPcmlnaW5hbCBvbmUgaXMgY29tbWVudGVkIHdpdGggI2F1dG9i
YWxsb29uID0gMSBpbiAvZXRjL3hlbi94bC5jb25mIHNvCj4+ID4+ID4+ID4gPj4gPj4gaXQgaXMg
dW5zZXQgSSBndWVzcyBzbyB0aGUgZGVmYXVsdCB2YWx1ZSBmb3IgYXV0b2JhbGxvb24gZm9yIGMv
cyAyMzExMAo+PiA+PiA+PiA+ID4+ID4+IGlzIGF1dG9iYWxsb29uPTAgd2hlcmUgYy9zIDIzMTkw
IGlzIGF1dG9iYWxsb29uPTE/IMODxpI/w4PigJrDgiBKdXN0IHNvbWUKPj4gPj4gPj4gPiA+PiA+
PiBndWVzc2luZy4uLiAuLi4KPj4gPj4gPj4gPiA+Cj4+ID4+ID4+ID4gPiBBdXRvYmFsbG9vbiBh
bmQgZG9tMF9tZW0gYXJlIGluY29tcGF0aWJsZS4KPj4gPj4gPj4gPiA+IEkgZG9uJ3QgdGhpbmsg
dGhlcmUgYXJlIGFueSByZWxldmFudCBkaWZmZXJlbmNlcyBiZXR3ZWVuIDIzMTEwIGFuZCAyMzE5
MAo+PiA+PiA+PiA+ID4gb24geGVuLXVuc3RhYmxlLCBtYXliZSB5b3UgdXNlZCB0byBzdGFydCBk
b20wIHdpdGhvdXQgZG9tMF9tZW0gYmVmb3JlPwo+PiA+PiA+PiA+Cj4+ID4+ID4+ID4gTm9wZS4u
LiBhbGwgbXkgc2VydmVycyB3aWxsIGFsd2F5cyBoYXZlIHRob3NlIGRvbTBfbWVtIHNldC4gwqBJ
dCBpcwo+PiA+PiA+PiA+IGZyb20geGVuLTQuMS10ZXN0aW5nIG5vdCB4ZW4tdW5zdGFibGUgZm9y
IHRoZSB0d28gY2hhbmdlc2V0Lgo+PiA+PiA+Pgo+PiA+PiA+PiBJIHN0aWxsIGNhbm5vdCBzZWUg
YW55dGhpbmcgaW4gdGhhdCByYW5nZS4gSG93ZXZlciBhcyBJIHNhaWQgYmVmb3JlLCBpdAo+PiA+
PiA+PiBpcyBleHBlY3RlZCB0aGF0IHdpdGggZG9tMF9tZW0gc2V0IGF1dG9iYWxsb29uIG5lZWRz
IHRvIGJlIGRpc2FibGVkLgo+PiA+PiA+Cj4+ID4+ID4gV2Ugc3RpbGwgaGF2ZW4ndCBzZWVuIHRo
ZSBmdWxsIG5vZGUgSURzIG9mIHRoZSBjaGFuZ2VzZXRzIHdoaWNoIEkgYXNrZWQKPj4gPj4gPiBm
b3Igc28gaXQgaXMgbm90IG9idmlvdXMgdGhhdCB3ZSBhcmUgYWN0dWFsbHkgbG9va2luZyBhdCB0
aGUgc2FtZSByYW5nZQo+PiA+PiA+IG9mIGNoYW5nZXNldHMuLi4KPj4gPj4KPj4gPj4gU29ycnks
IEkgYW0gYWN0dWFsbHkgbm90IHN1cmUgd2hhdCBJRCB5b3UgYXJlIGFza2luZyA6KAo+PiA+Pgo+
PiA+PiBDaGFuZ2VzZXRzIGRldGFpbHMgYXMgYmVsb3c6Cj4+ID4+Cj4+ID4+IGNoYW5nZXNldDog
wqAgMjMxMTA6NGQ1Yzc2MjQ4ZGUzCj4+ID4KPj4gPiBUaGUgIjIzMTEwIiBiaXQgaGVyZSBpcyBv
bmx5IGxvY2FsbHkgcmVsZXZhbnQgdG8gdGhlIHJlcG8geW91IGFyZQo+PiA+IGxvb2tpbmcgYXQg
c28geW91IGNhbm5vdCByZWxpYWJseSBpZGVudGlmeSBhIGNoYW5nZXNldCB0byBzb21lb25lIGVs
c2UKPj4gPiB1c2luZyB0aGF0IG51bWJlci4gT25seSB0aGUgIjRkNWM3NjI0OGRlMyIgaXMgYSBn
bG9iYWwgaWRlbnRpZmllciBhbmQKPj4gPiBjYW4gdGhlcmVmb3JlIGJlIGV4Y2hhbmdlZC4KPj4K
Pj4gVW5kZXJzdG9vZCA6KQo+Pgo+PiA+Cj4+ID4+IHVzZXI6IMKgIMKgIMKgIMKgUm9nZXIgUGF1
IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4gPj4gZGF0ZTogwqAgwqAgwqAgwqBT
YXQgSnVsIDIzIDA5OjAxOjI1IDIwMTEgKzAxMDAKPj4gPj4gc3VtbWFyeTogwqAgwqAgeGVuZDog
cmVtb3ZlIFBDSSBkZXZpY2UgbGlzdGluZyBmcm9tIE5ldEJTRCwgc2luY2UgaXQncyBMaW51eAo+
PiA+Pgo+PiA+PiBjaGFuZ2VzZXQ6IMKgIDIzMTkwOjVhMDBjY2ZjNjM5MQo+PiA+PiB1c2VyOiDC
oCDCoCDCoCDCoFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20+Cj4+ID4+IGRhdGU6IMKgIMKgIMKgIMKgRnJpIE5vdiAxOCAxMzozODowNSAyMDExICsw
MDAwCj4+ID4+IHN1bW1hcnk6IMKgIMKgIHg4NjogcmUtaW5qZWN0IGVtdWxhdGVkIGxldmVsIHBp
cnFzIGluIFBWIG9uIEhWTSBndWVzdHMKPj4gPj4gaWYgc3RpbGwgYXNzZXJ0ZWQKPj4gPgo+PiA+
Cj4+ID4gVW5mb3J0dW5hdGVseSBJIHN0aWxsIGRvbid0IHNlZSBhbnl0aGluZyByZWxldmFudCBi
ZXR3ZWVuIHRoZXNlCj4+ID4gY2hhbmdlc2V0cyBzbyBJJ3ZlIG5vIGlkZWEgd2h5IHRoaXMgc2Vl
bXMgdG8gYmUgYSBuZXcgaXNzdWUuIEFyZSB5b3UKPj4gPiBfcG9zaXRpdmVfIHRoYXQgeW91IGRp
ZG4ndCBjaGFuZ2UgYW55dGhpbmcgZWxzZSBhYm91dCB5b3VyIHN5c3RlbQo+PiA+IGNvbmZpZ3Vy
YXRpb24gb24gdXBncmFkZT8KPj4KPj4gSSBkb24ndCBjaGFuZ2Ugc2V0dGluZ3Mgb25jZSBpdCBp
cyBkZXBsb3llZCBhbmQgaW4gcHJvZHVjdGlvbiB1c2UgZm9yCj4+IHhlbiBzZXJ2ZXJzLiDCoElu
IGZhY3QsIGFsbCB3aWxsIGJlIGlkZW50aWNhbCBqdXN0IHRoZSBhbW91bnQgb2YgbWVtb3J5Cj4+
IHRvIGFsbG9jYXRlIHRvIGRvbTAgYXJlIGRpZmZlcmVudCBkZXBlbmRpbmcgb24gdGhlIHNlcnZl
ciB0b3RhbCBhbW91bnQKPj4gb2YgUkFNLgo+Cj4gVGhlIG1lc3NhZ2UgaXMgKEkgdGhpbmspIHRy
aWdnZXJlZCBiYXNlZCBvbiB0aGUgJWFnZSBvZiBtZW1vcnkgYWxsb2NhdGVkCj4gdG8gZG9tMCBz
byBpZiBkaWZmZXJlbnQgbWFjaGluZXMgYXJlIGRpZmZlcmVudCBzaXplcyBhbmQgdGhlcmVmb3Jl
IGhhdmUKPiBkaWZmZXJlbnQgdGhyZXNob2xkcyB0aGF0IG1pZ2h0IGV4cGxhaW4gd2h5IGl0IGlz
IG9ubHkgc2VlbiBzb21ldGltZXMuCgpPay4KCj4+ID4gVGhhdCBzb3VuZHMgbGlrZSBhIGJ1Zywg
dGhlcmUncyBubyBuZWVkIHRvIHdhaXQgZm9yIGFuIHJjIHJlbGVhc2UgdG8KPj4gPiByZXBvcnQg
YSBidWcuCj4+Cj4+IEkgdGhpbmsgSSByZXBvcnRlZCBvbmNlIGJlZm9yZS4uLiBsZXQgc2VlLi4u
IGhlcmU6Cj4+IGh0dHA6Ly9vbGQtbGlzdC1hcmNoaXZlcy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwv
eGVuLWRldmVsLzIwMTEtMDQvbXNnMDA5NzIuaHRtbAo+Cj4gSSdtIHNvcnJ5IHRoaXMgYXBwZWFy
cyB0byBoYXZlIHNsaXBwZWQgdW5kZXIgdGhlIHJhZGFyIGF0IHRoZSB0aW1lLiBJCj4gdGhpbmsg
aXQgd291bGQgYmUgd29ydGggcmVwb3N0aW5nIGluIGEgbmV3IHRocmVhZC4KCkkgd2lsbCByZXBv
c3QgbGF0ZXIuICBKdXN0IG9uZSBxdWVzdGlvbi4uLiAuLi4gZG8geW91IGd1eXMgcHJlZmVyIHN1
Y2gKcmVwb3J0cyB0byBiZSBwb3N0ZWQgaW4geGVuLXVzZXJzIG9yIHhlbi1kZXZlbCBtYWlsaW5n
IGxpc3Q/ClNvbWV0aW1lcyBJIHdvbmRlciB3aGljaCBvbmUgaXMgbW9yZSBzdWl0YWJsZS4uLiAu
Li4KClRoYW5rcy4KCktpbmRlc3QgcmVnYXJkcywKR2lhbSBUZWNrIENob29uCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:04:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBYq-0001CQ-G7; Wed, 23 Nov 2011 12:04:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTBYo-0001C1-N4
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:04:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322049828!3830862!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28442 invoked from network); 23 Nov 2011 12:03:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 12:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9087544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:03:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 12:03:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTBYJ-0004Vu-Dj; Wed, 23 Nov 2011 12:03:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTBYJ-00030J-Cl;
	Wed, 23 Nov 2011 12:03:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20172.57635.382497.752110@mariner.uk.xensource.com>
Date: Wed, 23 Nov 2011 12:03:47 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("[Xen-devel] [PATCH] Prevent xl save from segfaulting when control/shutdown key is removed"):
> Prevent xl save from segfaulting when control/shutdown key is removed

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:04:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:04:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBYq-0001CQ-G7; Wed, 23 Nov 2011 12:04:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTBYo-0001C1-N4
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:04:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322049828!3830862!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28442 invoked from network); 23 Nov 2011 12:03:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 12:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9087544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:03:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 12:03:47 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTBYJ-0004Vu-Dj; Wed, 23 Nov 2011 12:03:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTBYJ-00030J-Cl;
	Wed, 23 Nov 2011 12:03:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20172.57635.382497.752110@mariner.uk.xensource.com>
Date: Wed, 23 Nov 2011 12:03:47 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("[Xen-devel] [PATCH] Prevent xl save from segfaulting when control/shutdown key is removed"):
> Prevent xl save from segfaulting when control/shutdown key is removed

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:08:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBcU-0001O2-5Y; Wed, 23 Nov 2011 12:08:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTBcS-0001Ng-FL
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:08:04 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322050054!4269776!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24351 invoked from network); 23 Nov 2011 12:07:34 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 12:07:34 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73379900; Wed, 23 Nov 2011 13:07:32 +0100
Message-ID: <1322050046.24897.40.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 13:07:26 +0100
In-Reply-To: <1322048295.1005.82.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
	<1322040258.1005.1.camel@zakaz.uk.xensource.com>
	<1322043870.24897.25.camel@Abyss> <1322045702.24897.32.camel@Abyss>
	<1322048295.1005.82.camel@zakaz.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3204066372254937752=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3204066372254937752==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-rVch5BMpfVtSkj7mzhji"


--=-rVch5BMpfVtSkj7mzhji
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-11-23 at 11:38 +0000, Ian Campbell wrote:
> /usr/lib64 used to be a symlink to /usr/lib on Debian but that has gone
> away due to the beginnings of multiarch support.
>=20
Yep. I was thinking I've messed up something, but then I saw no symlink
on my workstation (still Sid) at all. :-)

> It's not clear to me if this is a bug of sorts in multiarch (or at least
> in the transition) or if we ought to be doing something to work with
> such systems. My build/test machines are all Debian Stable so I haven't
> had to think about it too hard yet since multiarch-ification is only
> going on in unstable (perhaps testing too, I don't know).
>=20
Ok, that's exactly why I fired the question.

> Short term you can edit config/StdGNU.mk to change LIBLEAFDIR_x86_64.
>=20
Nice. I've already put something in my scripts to cope with that, I'll
see which solution better fits my needs.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-rVch5BMpfVtSkj7mzhji
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7M4f4ACgkQk4XaBE3IOsQk+gCgkn7W9TecNYR0rrWA52FEhqMs
xasAnjdXeU/CXutN+ONDpfZvwk3wo+8f
=bzmZ
-----END PGP SIGNATURE-----

--=-rVch5BMpfVtSkj7mzhji--



--===============3204066372254937752==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3204066372254937752==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:08:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBcU-0001O2-5Y; Wed, 23 Nov 2011 12:08:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTBcS-0001Ng-FL
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:08:04 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322050054!4269776!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24351 invoked from network); 23 Nov 2011 12:07:34 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 12:07:34 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73379900; Wed, 23 Nov 2011 13:07:32 +0100
Message-ID: <1322050046.24897.40.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 13:07:26 +0100
In-Reply-To: <1322048295.1005.82.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321531234@nehalem1> <1322039476.23989.6.camel@Abyss>
	<1322040258.1005.1.camel@zakaz.uk.xensource.com>
	<1322043870.24897.25.camel@Abyss> <1322045702.24897.32.camel@Abyss>
	<1322048295.1005.82.camel@zakaz.uk.xensource.com>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 5] xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3204066372254937752=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3204066372254937752==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-rVch5BMpfVtSkj7mzhji"


--=-rVch5BMpfVtSkj7mzhji
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-11-23 at 11:38 +0000, Ian Campbell wrote:
> /usr/lib64 used to be a symlink to /usr/lib on Debian but that has gone
> away due to the beginnings of multiarch support.
>=20
Yep. I was thinking I've messed up something, but then I saw no symlink
on my workstation (still Sid) at all. :-)

> It's not clear to me if this is a bug of sorts in multiarch (or at least
> in the transition) or if we ought to be doing something to work with
> such systems. My build/test machines are all Debian Stable so I haven't
> had to think about it too hard yet since multiarch-ification is only
> going on in unstable (perhaps testing too, I don't know).
>=20
Ok, that's exactly why I fired the question.

> Short term you can edit config/StdGNU.mk to change LIBLEAFDIR_x86_64.
>=20
Nice. I've already put something in my scripts to cope with that, I'll
see which solution better fits my needs.

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-rVch5BMpfVtSkj7mzhji
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7M4f4ACgkQk4XaBE3IOsQk+gCgkn7W9TecNYR0rrWA52FEhqMs
xasAnjdXeU/CXutN+ONDpfZvwk3wo+8f
=bzmZ
-----END PGP SIGNATURE-----

--=-rVch5BMpfVtSkj7mzhji--



--===============3204066372254937752==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3204066372254937752==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:14:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:14:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBiY-0001ao-9N; Wed, 23 Nov 2011 12:14:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RTBiX-0001ah-NP
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:14:21 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322050431!4296758!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1556 invoked from network); 23 Nov 2011 12:13:51 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 12:13:51 -0000
Received: from [192.168.100.16] (unknown [109.231.64.198])
	by mail.avalus.com (Postfix) with ESMTPSA id 40C21C56116;
	Wed, 23 Nov 2011 12:13:50 +0000 (GMT)
Date: Wed, 23 Nov 2011 12:13:49 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <4920A24BA9A56EE621ABF2DF@nimrod.local>
In-Reply-To: <1322047105.1005.69.camel@zakaz.uk.xensource.com>
References: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
	<1322047105.1005.69.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Minimum python version for xen-4.1.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

--On 23 November 2011 11:18:25 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

> On Wed, 2011-11-23 at 11:11 +0000, Alex Bligh wrote:
>> Does xen-4.1.1 really require python 2.7 (as per Ubuntu packaging) or
>> will it actually work on python 2.6? I am trying to backport it to
>> an Ubuntu LTS version and would rather not have to bring in Python 2.7
>> if possible.
>
> The README says 2.3 or later. I don't think we rely on 2.7 specifically
> and we would take patches to fix it for earlier versions as necessary
> (although perhaps we would bump the 2.3 to e.g. 2.4 or 2.5 if that
> turned out to be easier, depends on the prevalence of 2.4+ in distro
> stable releases).

Thanks.

Having worked out how to do this, I found someone else has already
done it. Reference for the mailing list:
 http://crypt47.blogspot.com/2011/08/xen-411-on-ubuntu-lucid-1004-lts-easy.ht
ml

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:14:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:14:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTBiY-0001ao-9N; Wed, 23 Nov 2011 12:14:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <alex@alex.org.uk>) id 1RTBiX-0001ah-NP
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:14:21 +0000
X-Env-Sender: alex@alex.org.uk
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322050431!4296758!1
X-Originating-IP: [89.16.176.221]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1556 invoked from network); 23 Nov 2011 12:13:51 -0000
Received: from mail.avalus.com (HELO mail.avalus.com) (89.16.176.221)
	by server-2.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 12:13:51 -0000
Received: from [192.168.100.16] (unknown [109.231.64.198])
	by mail.avalus.com (Postfix) with ESMTPSA id 40C21C56116;
	Wed, 23 Nov 2011 12:13:50 +0000 (GMT)
Date: Wed, 23 Nov 2011 12:13:49 +0000
From: Alex Bligh <alex@alex.org.uk>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <4920A24BA9A56EE621ABF2DF@nimrod.local>
In-Reply-To: <1322047105.1005.69.camel@zakaz.uk.xensource.com>
References: <21EFAFAEFF8A3AE4BE1AE24D@nimrod.local>
	<1322047105.1005.69.camel@zakaz.uk.xensource.com>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Alex Bligh <alex@alex.org.uk>
Subject: Re: [Xen-devel] Minimum python version for xen-4.1.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

--On 23 November 2011 11:18:25 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
wrote:

> On Wed, 2011-11-23 at 11:11 +0000, Alex Bligh wrote:
>> Does xen-4.1.1 really require python 2.7 (as per Ubuntu packaging) or
>> will it actually work on python 2.6? I am trying to backport it to
>> an Ubuntu LTS version and would rather not have to bring in Python 2.7
>> if possible.
>
> The README says 2.3 or later. I don't think we rely on 2.7 specifically
> and we would take patches to fix it for earlier versions as necessary
> (although perhaps we would bump the 2.3 to e.g. 2.4 or 2.5 if that
> turned out to be easier, depends on the prevalence of 2.4+ in distro
> stable releases).

Thanks.

Having worked out how to do this, I found someone else has already
done it. Reference for the mailing list:
 http://crypt47.blogspot.com/2011/08/xen-411-on-ubuntu-lucid-1004-lts-easy.ht
ml

-- 
Alex Bligh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:54:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCL9-0002KA-B7; Wed, 23 Nov 2011 12:54:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTCL8-0002K5-Ag
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:54:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322052824!4275846!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17472 invoked from network); 23 Nov 2011 12:53:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 12:53:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9090249"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:53:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 12:53:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Wed, 23 Nov 2011 12:53:43 +0000
In-Reply-To: <CAEwRVpOVmfKGzL7jFd8k9mH06Ct0tXhb6rZeYnrVpgR3x+mC1Q@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
	<1322048085.1005.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
	<1322049282.1005.90.camel@zakaz.uk.xensource.com>
	<CAEwRVpOVmfKGzL7jFd8k9mH06Ct0tXhb6rZeYnrVpgR3x+mC1Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322052824.1005.100.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 11:59 +0000, Teck Choon Giam wrote:
> I will repost later.  Just one question... ... do you guys prefer such
> reports to be posted in xen-users or xen-devel mailing list?
> Sometimes I wonder which one is more suitable... ...

Generally most issues are best taken to xen-users in the first instance
(since the most common cause is misconfiguration or user error).
xen-devel is appropriate when there has been shown to be a bug in the
code or xen-users has proved unsuccessful etc.

Looking at your original mail I think you might want to include some
more details and logs etc when you repost.
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen has a list of
various useful logs to include.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:54:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:54:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCL9-0002KA-B7; Wed, 23 Nov 2011 12:54:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTCL8-0002K5-Ag
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:54:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322052824!4275846!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17472 invoked from network); 23 Nov 2011 12:53:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 12:53:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9090249"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:53:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 12:53:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Teck Choon Giam <giamteckchoon@gmail.com>
Date: Wed, 23 Nov 2011 12:53:43 +0000
In-Reply-To: <CAEwRVpOVmfKGzL7jFd8k9mH06Ct0tXhb6rZeYnrVpgR3x+mC1Q@mail.gmail.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
	<1322048085.1005.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
	<1322049282.1005.90.camel@zakaz.uk.xensource.com>
	<CAEwRVpOVmfKGzL7jFd8k9mH06Ct0tXhb6rZeYnrVpgR3x+mC1Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322052824.1005.100.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 11:59 +0000, Teck Choon Giam wrote:
> I will repost later.  Just one question... ... do you guys prefer such
> reports to be posted in xen-users or xen-devel mailing list?
> Sometimes I wonder which one is more suitable... ...

Generally most issues are best taken to xen-users in the first instance
(since the most common cause is misconfiguration or user error).
xen-devel is appropriate when there has been shown to be a bug in the
code or xen-users has proved unsuccessful etc.

Looking at your original mail I think you might want to include some
more details and logs etc when you repost.
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen has a list of
various useful logs to include.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:56:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCMn-0002O1-Rc; Wed, 23 Nov 2011 12:55:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1RTCMm-0002Nk-Iq
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:55:57 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322052926!2722088!1
X-Originating-IP: [209.85.220.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10632 invoked from network); 23 Nov 2011 12:55:26 -0000
Received: from mail-dy0-f43.google.com (HELO mail-dy0-f43.google.com)
	(209.85.220.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 12:55:26 -0000
Received: by dyf28 with SMTP id 28so232834dyf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 04:55:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=5ikyueYR67fUEy0N1qiiA/ZUwx5OCQ1AD/rqD+vdCKo=;
	b=vEs+pMXwuPd21iUKWaWj/gMqmId9IWV2NogiLao/nI3oRpwreUI555Fp0mp4yd4ma2
	UgKllf35gtRx1w99PSNhTsUwSkn89e5lmbP9oQy8WShblqbn2Oh8nG8JRNDW4aehJq+s
	1Yot+xGMHvwdSthAX/O743I2z6rL0L4iP617A=
MIME-Version: 1.0
Received: by 10.204.154.7 with SMTP id m7mr24128776bkw.71.1322052925978; Wed,
	23 Nov 2011 04:55:25 -0800 (PST)
Received: by 10.223.78.130 with HTTP; Wed, 23 Nov 2011 04:55:25 -0800 (PST)
Date: Wed, 23 Nov 2011 07:55:25 -0500
X-Google-Sender-Auth: LvEwwQ-xS0CARMTVF1AcI8JUtaw
Message-ID: <CAOvdn6VeSzv63PYYWy1TEgYVSdT5Pz5wMzK2TJwZTg3PL2A-oA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, 
	Anton Blanchard <anton@samba.org>
Subject: [Xen-devel] kdb on a pvops xen kernel, with hvc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've been attempting to get kdb working with a pvops kernel, and the
hvc driver - without much success.

Chageset  762e77ae7dd055d0b77e0ad34d87db7416df109e by Anton Blanchard
seemed to indicate
that support for this was added back in July, but I'm having some
issues that I'm hoping someone here
could point me in the right direction.

Below is my work in progress patch (with apologies about the excessive
trace debugging included)

However, I am having the following problem (that I'm clearly lacking
some understanding about tty
infrastructure) -

When the hvc_poll_get_char() function is called from kdb, there seems
to be no tty mapped to the
driver... I see in the dmesg log that my debug printk indicated that
it was removed from the driver.

Any pointers on why this might be would be, so I can go debug it,
would be greatly appreciated



/btg



This is against a 2.6.38 based kernel...but nothing here should be
specific to that kernel.



diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index a413000..de7236b 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -515,8 +515,11 @@ static int __kgdb_notify(struct die_args *args,
unsigned long cmd)
 {
 	struct pt_regs *regs = args->regs;

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+
 	switch (cmd) {
 	case DIE_NMI:
+		printk(KERN_CRIT "kgdb: DIE_NMI %s:%d\n", __func__, __LINE__);
 		if (atomic_read(&kgdb_active) != -1) {
 			/* KGDB CPU roundup */
 			kgdb_nmicallback(raw_smp_processor_id(), regs);
@@ -527,6 +530,7 @@ static int __kgdb_notify(struct die_args *args,
unsigned long cmd)
 		return NOTIFY_DONE;

 	case DIE_NMIUNKNOWN:
+		printk(KERN_CRIT "kgdb: DIE_NMIUNKNOWN %s:%d\n", __func__, __LINE__);
 		if (was_in_debug_nmi[raw_smp_processor_id()]) {
 			was_in_debug_nmi[raw_smp_processor_id()] = 0;
 			return NOTIFY_STOP;
@@ -534,6 +538,7 @@ static int __kgdb_notify(struct die_args *args,
unsigned long cmd)
 		return NOTIFY_DONE;

 	case DIE_NMIWATCHDOG:
+		printk(KERN_CRIT "kgdb: DIE_NMIWATCHDOG %s:%d\n", __func__, __LINE__);
 		if (atomic_read(&kgdb_active) != -1) {
 			/* KGDB CPU roundup: */
 			kgdb_nmicallback(raw_smp_processor_id(), regs);
@@ -543,6 +548,7 @@ static int __kgdb_notify(struct die_args *args,
unsigned long cmd)
 		break;

 	case DIE_DEBUG:
+		printk(KERN_CRIT "kgdb: DIE_DEBUG %s:%d\n", __func__, __LINE__);
 		if (atomic_read(&kgdb_cpu_doing_single_step) != -1) {
 			if (user_mode(regs))
 				return single_step_cont(regs, args);
@@ -554,6 +560,7 @@ static int __kgdb_notify(struct die_args *args,
unsigned long cmd)
 			return NOTIFY_DONE;
 		/* fall through */
 	default:
+		printk(KERN_CRIT "kgdb: default %s:%d\n", __func__, __LINE__);
 		if (user_mode(regs))
 			return NOTIFY_DONE;
 	}
@@ -578,6 +585,8 @@ int kgdb_ll_trap(int cmd, const char *str,

 	};

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+
 	if (!kgdb_io_module_registered)
 		return NOTIFY_DONE;

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d5e0e0a..b0763eb 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -40,6 +40,7 @@
 #include <xen/interface/memory.h>
 #include <xen/features.h>
 #include <xen/page.h>
+#include <xen/events.h>
 #include <xen/hvm.h>
 #include <xen/hvc-console.h>

@@ -760,6 +761,15 @@ static u32 xen_safe_apic_wait_icr_idle(void)
         return 0;
 }

+extern void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector);
+extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector);
+extern void xen_send_IPI_allbutself(int vector);
+extern void physflat_send_IPI_allbutself(int vector);
+extern void xen_send_IPI_all(int vector);
+extern void xen_send_IPI_self(int vector);
+
 static void set_xen_basic_apic_ops(void)
 {
 	apic->read = xen_apic_read;
@@ -768,6 +778,12 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
+
+	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
+	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
+	apic->send_IPI_mask = xen_send_IPI_mask;
+	apic->send_IPI_all = xen_send_IPI_all;
+	apic->send_IPI_self = xen_send_IPI_self;
 }

 #endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3061244..77863bb 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -436,8 +436,8 @@ static void xen_smp_send_reschedule(int cpu)
 	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }

-static void xen_send_IPI_mask(const struct cpumask *mask,
-			      enum ipi_vector vector)
+void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector)
 {
 	unsigned cpu;

@@ -466,6 +466,46 @@ static void xen_smp_send_call_function_single_ipi(int cpu)
 			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
 }

+void xen_send_IPI_all(int vector)
+{
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+	xen_send_IPI_mask(cpu_online_mask, vector);
+}
+
+void xen_send_IPI_self(int vector)
+{
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+	xen_send_IPI_one(smp_processor_id(), vector);
+}
+
+void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector)
+{
+	unsigned cpu;
+	unsigned int this_cpu = smp_processor_id();
+
+	if (!(num_online_cpus() > 1))
+		return;
+
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+	for_each_cpu_and(cpu, mask, cpu_online_mask) {
+		if (this_cpu == cpu)
+			continue;
+		
+		printk(KERN_CRIT "kgdb: %s:%d Sending IPI for CPU %d\n",
+			__func__, __LINE__, cpu);
+		/* xen_send_IPI_one(cpu, vector); */
+		xen_smp_send_call_function_single_ipi(cpu);
+	}
+}
+
+void xen_send_IPI_allbutself(int vector)
+{
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+	xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
+}
+
+
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
 {
 	irq_enter();
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 58ca7ce..f93fdad 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -40,6 +40,7 @@
 #include <linux/freezer.h>
 #include <linux/slab.h>
 #include <linux/serial_core.h>
+#include <linux/ratelimit.h>

 #include <asm/uaccess.h>

@@ -755,10 +756,25 @@ int hvc_poll_init(struct tty_driver *driver, int
line, char *options)
 static int hvc_poll_get_char(struct tty_driver *driver, int line)
 {
 	struct tty_struct *tty = driver->ttys[0];
-	struct hvc_struct *hp = tty->driver_data;
+	struct hvc_struct *hp;
 	int n;
 	char ch;

+	if (!tty) {
+		printk_ratelimited(KERN_CRIT "kgdb: %s:%d invalid driver data %s\n",
+				__func__, __LINE__, driver->name);
+		return -1;
+	}
+
+
+	hp = tty->driver_data;
+	if (!hp || !hp->ops) {
+		printk_ratelimited(KERN_CRIT "kgdb: %s:%d invalid hp, or hp->ops\n",
+				__func__, __LINE__);
+		return -1;
+	}
+	
+
 	n = hp->ops->get_chars(hp->vtermno, &ch, 1);

 	if (n == 0)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 0065da4..8caa6fa 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -365,6 +365,8 @@ struct tty_driver *tty_find_polling_driver(char
*name, int *line)
 		    p->ops->poll_init && !p->ops->poll_init(p, tty_line, stp)) {
 			res = tty_driver_kref_get(p);
 			*line = tty_line;
+			printk(KERN_CRIT "kgdb: %s:%d Found tty %s line %d\n",
+				__func__, __LINE__, res->name, tty_line);
 			break;
 		}
 	}
@@ -1279,9 +1281,12 @@ static int tty_driver_install_tty(struct
tty_driver *driver,
 	if (tty_init_termios(tty) == 0) {
 		tty_driver_kref_get(driver);
 		tty->count++;
+		printk(KERN_CRIT "kgdb: Installing tty %s %d\n", driver->name, idx);
 		driver->ttys[idx] = tty;
 		return 0;
 	}
+
+	printk(KERN_CRIT "kgdb: Failed to init %s\n", driver->name);
 	return -ENOMEM;
 }

@@ -1298,6 +1303,7 @@ static int tty_driver_install_tty(struct
tty_driver *driver,
 static void tty_driver_remove_tty(struct tty_driver *driver,
 						struct tty_struct *tty)
 {
+	printk(KERN_CRIT "kgdb: Removing tty %s %d\n", driver->name, tty->count);
 	if (driver->ops->remove)
 		driver->ops->remove(driver, tty);
 	else
@@ -3064,6 +3070,7 @@ int tty_register_driver(struct tty_driver *driver)
 	}

 	if (p) {
+		printk(KERN_ERR "kgdb: setting up ttys for %s\n", driver->name);
 		driver->ttys = (struct tty_struct **)p;
 		driver->termios = (struct ktermios **)(p + driver->num);
 	} else {
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index cefd4a1..a773f91 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -54,6 +54,10 @@
 #include <asm/atomic.h>
 #include <asm/system.h>

+#ifdef CONFIG_XEN
+#include <asm/xen/hypercall.h>
+#endif
+
 #include "debug_core.h"

 static int kgdb_break_asap;
@@ -405,8 +409,10 @@ static int kgdb_reenter_check(struct kgdb_state *ks)
 {
 	unsigned long addr;

-	if (atomic_read(&kgdb_active) != raw_smp_processor_id())
+	if (atomic_read(&kgdb_active) != raw_smp_processor_id()) {
+		printk(KERN_CRIT "KGDB: bailing %d != %d\n", kgdb_active,
raw_smp_processor_id());
 		return 0;
+	}

 	/* Panic on recursive debugger calls: */
 	exception_level++;
@@ -468,6 +474,7 @@ static int kgdb_cpu_enter(struct kgdb_state *ks,
struct pt_regs *regs,
 	kgdb_info[ks->cpu].enter_kgdb++;
 	kgdb_info[ks->cpu].exception_state |= exception_state;

+	printk(KERN_CRIT "kgdb: %s:%d cpuid: %d\n", __func__, __LINE__,
raw_smp_processor_id());
 	if (exception_state == DCPU_WANT_MASTER)
 		atomic_inc(&masters_in_kgdb);
 	else
@@ -477,6 +484,7 @@ static int kgdb_cpu_enter(struct kgdb_state *ks,
struct pt_regs *regs,
 		arch_kgdb_ops.disable_hw_break(regs);

 acquirelock:
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	/*
 	 * Interrupts will be restored by the 'trap return' code, except when
 	 * single stepping.
@@ -502,8 +510,10 @@ acquirelock:
 	 * CPU will loop if it is a slave or request to become a kgdb
 	 * master cpu and acquire the kgdb_active lock:
 	 */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	while (1) {
 cpu_loop:
+		printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 		if (kgdb_info[cpu].exception_state & DCPU_NEXT_MASTER) {
 			kgdb_info[cpu].exception_state &= ~DCPU_NEXT_MASTER;
 			goto cpu_master_loop;
@@ -517,6 +527,7 @@ cpu_loop:
 				goto return_normal;
 		} else {
 return_normal:
+			printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 			/* Return to normal operation by executing any
 			 * hw breakpoint fixup.
 			 */
@@ -536,6 +547,7 @@ return_normal:
 		cpu_relax();
 	}

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	/*
 	 * For single stepping, try to only enter on the processor
 	 * that was single stepping.  To gaurd against a deadlock, the
@@ -553,6 +565,7 @@ return_normal:
 		goto acquirelock;
 	}

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	if (!kgdb_io_ready(1)) {
 		kgdb_info[cpu].ret_state = 1;
 		goto kgdb_restore; /* No I/O connection, resume the system */
@@ -561,10 +574,12 @@ return_normal:
 	/*
 	 * Don't enter if we have hit a removed breakpoint.
 	 */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	if (kgdb_skipexception(ks->ex_vector, ks->linux_regs))
 		goto kgdb_restore;

 	/* Call the I/O driver's pre_exception routine */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	if (dbg_io_ops->pre_exception)
 		dbg_io_ops->pre_exception();

@@ -572,21 +587,30 @@ return_normal:
 	 * Get the passive CPU lock which will hold all the non-primary
 	 * CPU in a spin state while the debugger is active
 	 */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	if (!kgdb_single_step)
 		raw_spin_lock(&dbg_slave_lock);

 #ifdef CONFIG_SMP
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	/* Signal the other CPUs to enter kgdb_wait() */
 	if ((!kgdb_single_step) && kgdb_do_roundup)
 		kgdb_roundup_cpus(flags);
 #endif

+#if 0
 	/*
 	 * Wait for the other CPUs to be notified and be waiting for us:
 	 */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
-				atomic_read(&slaves_in_kgdb)) != online_cpus)
+				atomic_read(&slaves_in_kgdb)) != online_cpus) {
+#ifdef CONFIG_XEN
+		HYPERVISOR_sched_op(SCHEDOP_yield, NULL);
+#endif
 		cpu_relax();
+	}
+#endif

 	/*
 	 * At this point the primary processor is completely
@@ -602,6 +626,7 @@ return_normal:

 	while (1) {
 cpu_master_loop:
+		printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 		if (dbg_kdb_mode) {
 			kgdb_connected = 1;
 			error = kdb_stub(ks);
@@ -624,6 +649,7 @@ cpu_master_loop:
 		}
 	}

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	/* Call the I/O driver's post_exception routine */
 	if (dbg_io_ops->post_exception)
 		dbg_io_ops->post_exception();
@@ -636,6 +662,7 @@ cpu_master_loop:
 	}

 kgdb_restore:
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	if (atomic_read(&kgdb_cpu_doing_single_step) != -1) {
 		int sstep_cpu = atomic_read(&kgdb_cpu_doing_single_step);
 		if (kgdb_info[sstep_cpu].task)
@@ -659,6 +686,7 @@ kgdb_restore:
 	dbg_touch_watchdogs();
 	local_irq_restore(flags);

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	return kgdb_info[cpu].ret_state;
 }

@@ -675,6 +703,8 @@ kgdb_handle_exception(int evector, int signo, int
ecode, struct pt_regs *regs)
 	struct kgdb_state kgdb_var;
 	struct kgdb_state *ks = &kgdb_var;

+	printk(KERN_CRIT "kgdb: %s:%d cpu:%d\n", __func__, __LINE__,
raw_smp_processor_id());
+
 	ks->cpu			= raw_smp_processor_id();
 	ks->ex_vector		= evector;
 	ks->signo		= signo;
@@ -696,6 +726,7 @@ int kgdb_nmicallback(int cpu, void *regs)
 	struct kgdb_state kgdb_var;
 	struct kgdb_state *ks = &kgdb_var;

+	printk(KERN_CRIT "kgdb: %s:%d cpu:%d\n", __func__, __LINE__,
raw_smp_processor_id());
 	memset(ks, 0, sizeof(struct kgdb_state));
 	ks->cpu			= cpu;
 	ks->linux_regs		= regs;
@@ -954,11 +985,17 @@ int dbg_io_get_char(void)
  */
 void kgdb_breakpoint(void)
 {
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	atomic_inc(&kgdb_setting_breakpoint);
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	wmb(); /* Sync point before breakpoint */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	arch_kgdb_breakpoint();
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	wmb(); /* Sync point after breakpoint */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	atomic_dec(&kgdb_setting_breakpoint);
+	printk(KERN_CRIT "kgdb: %s exiting\n", __func__);
 }
 EXPORT_SYMBOL_GPL(kgdb_breakpoint);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:56:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCMn-0002O1-Rc; Wed, 23 Nov 2011 12:55:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1RTCMm-0002Nk-Iq
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:55:57 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322052926!2722088!1
X-Originating-IP: [209.85.220.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10632 invoked from network); 23 Nov 2011 12:55:26 -0000
Received: from mail-dy0-f43.google.com (HELO mail-dy0-f43.google.com)
	(209.85.220.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 12:55:26 -0000
Received: by dyf28 with SMTP id 28so232834dyf.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 04:55:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=5ikyueYR67fUEy0N1qiiA/ZUwx5OCQ1AD/rqD+vdCKo=;
	b=vEs+pMXwuPd21iUKWaWj/gMqmId9IWV2NogiLao/nI3oRpwreUI555Fp0mp4yd4ma2
	UgKllf35gtRx1w99PSNhTsUwSkn89e5lmbP9oQy8WShblqbn2Oh8nG8JRNDW4aehJq+s
	1Yot+xGMHvwdSthAX/O743I2z6rL0L4iP617A=
MIME-Version: 1.0
Received: by 10.204.154.7 with SMTP id m7mr24128776bkw.71.1322052925978; Wed,
	23 Nov 2011 04:55:25 -0800 (PST)
Received: by 10.223.78.130 with HTTP; Wed, 23 Nov 2011 04:55:25 -0800 (PST)
Date: Wed, 23 Nov 2011 07:55:25 -0500
X-Google-Sender-Auth: LvEwwQ-xS0CARMTVF1AcI8JUtaw
Message-ID: <CAOvdn6VeSzv63PYYWy1TEgYVSdT5Pz5wMzK2TJwZTg3PL2A-oA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org, 
	Anton Blanchard <anton@samba.org>
Subject: [Xen-devel] kdb on a pvops xen kernel, with hvc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've been attempting to get kdb working with a pvops kernel, and the
hvc driver - without much success.

Chageset  762e77ae7dd055d0b77e0ad34d87db7416df109e by Anton Blanchard
seemed to indicate
that support for this was added back in July, but I'm having some
issues that I'm hoping someone here
could point me in the right direction.

Below is my work in progress patch (with apologies about the excessive
trace debugging included)

However, I am having the following problem (that I'm clearly lacking
some understanding about tty
infrastructure) -

When the hvc_poll_get_char() function is called from kdb, there seems
to be no tty mapped to the
driver... I see in the dmesg log that my debug printk indicated that
it was removed from the driver.

Any pointers on why this might be would be, so I can go debug it,
would be greatly appreciated



/btg



This is against a 2.6.38 based kernel...but nothing here should be
specific to that kernel.



diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index a413000..de7236b 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -515,8 +515,11 @@ static int __kgdb_notify(struct die_args *args,
unsigned long cmd)
 {
 	struct pt_regs *regs = args->regs;

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+
 	switch (cmd) {
 	case DIE_NMI:
+		printk(KERN_CRIT "kgdb: DIE_NMI %s:%d\n", __func__, __LINE__);
 		if (atomic_read(&kgdb_active) != -1) {
 			/* KGDB CPU roundup */
 			kgdb_nmicallback(raw_smp_processor_id(), regs);
@@ -527,6 +530,7 @@ static int __kgdb_notify(struct die_args *args,
unsigned long cmd)
 		return NOTIFY_DONE;

 	case DIE_NMIUNKNOWN:
+		printk(KERN_CRIT "kgdb: DIE_NMIUNKNOWN %s:%d\n", __func__, __LINE__);
 		if (was_in_debug_nmi[raw_smp_processor_id()]) {
 			was_in_debug_nmi[raw_smp_processor_id()] = 0;
 			return NOTIFY_STOP;
@@ -534,6 +538,7 @@ static int __kgdb_notify(struct die_args *args,
unsigned long cmd)
 		return NOTIFY_DONE;

 	case DIE_NMIWATCHDOG:
+		printk(KERN_CRIT "kgdb: DIE_NMIWATCHDOG %s:%d\n", __func__, __LINE__);
 		if (atomic_read(&kgdb_active) != -1) {
 			/* KGDB CPU roundup: */
 			kgdb_nmicallback(raw_smp_processor_id(), regs);
@@ -543,6 +548,7 @@ static int __kgdb_notify(struct die_args *args,
unsigned long cmd)
 		break;

 	case DIE_DEBUG:
+		printk(KERN_CRIT "kgdb: DIE_DEBUG %s:%d\n", __func__, __LINE__);
 		if (atomic_read(&kgdb_cpu_doing_single_step) != -1) {
 			if (user_mode(regs))
 				return single_step_cont(regs, args);
@@ -554,6 +560,7 @@ static int __kgdb_notify(struct die_args *args,
unsigned long cmd)
 			return NOTIFY_DONE;
 		/* fall through */
 	default:
+		printk(KERN_CRIT "kgdb: default %s:%d\n", __func__, __LINE__);
 		if (user_mode(regs))
 			return NOTIFY_DONE;
 	}
@@ -578,6 +585,8 @@ int kgdb_ll_trap(int cmd, const char *str,

 	};

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+
 	if (!kgdb_io_module_registered)
 		return NOTIFY_DONE;

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d5e0e0a..b0763eb 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -40,6 +40,7 @@
 #include <xen/interface/memory.h>
 #include <xen/features.h>
 #include <xen/page.h>
+#include <xen/events.h>
 #include <xen/hvm.h>
 #include <xen/hvc-console.h>

@@ -760,6 +761,15 @@ static u32 xen_safe_apic_wait_icr_idle(void)
         return 0;
 }

+extern void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector);
+extern void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector);
+extern void xen_send_IPI_allbutself(int vector);
+extern void physflat_send_IPI_allbutself(int vector);
+extern void xen_send_IPI_all(int vector);
+extern void xen_send_IPI_self(int vector);
+
 static void set_xen_basic_apic_ops(void)
 {
 	apic->read = xen_apic_read;
@@ -768,6 +778,12 @@ static void set_xen_basic_apic_ops(void)
 	apic->icr_write = xen_apic_icr_write;
 	apic->wait_icr_idle = xen_apic_wait_icr_idle;
 	apic->safe_wait_icr_idle = xen_safe_apic_wait_icr_idle;
+
+	apic->send_IPI_allbutself = xen_send_IPI_allbutself;
+	apic->send_IPI_mask_allbutself = xen_send_IPI_mask_allbutself;
+	apic->send_IPI_mask = xen_send_IPI_mask;
+	apic->send_IPI_all = xen_send_IPI_all;
+	apic->send_IPI_self = xen_send_IPI_self;
 }

 #endif
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3061244..77863bb 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -436,8 +436,8 @@ static void xen_smp_send_reschedule(int cpu)
 	xen_send_IPI_one(cpu, XEN_RESCHEDULE_VECTOR);
 }

-static void xen_send_IPI_mask(const struct cpumask *mask,
-			      enum ipi_vector vector)
+void xen_send_IPI_mask(const struct cpumask *mask,
+			      int vector)
 {
 	unsigned cpu;

@@ -466,6 +466,46 @@ static void xen_smp_send_call_function_single_ipi(int cpu)
 			  XEN_CALL_FUNCTION_SINGLE_VECTOR);
 }

+void xen_send_IPI_all(int vector)
+{
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+	xen_send_IPI_mask(cpu_online_mask, vector);
+}
+
+void xen_send_IPI_self(int vector)
+{
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+	xen_send_IPI_one(smp_processor_id(), vector);
+}
+
+void xen_send_IPI_mask_allbutself(const struct cpumask *mask,
+				int vector)
+{
+	unsigned cpu;
+	unsigned int this_cpu = smp_processor_id();
+
+	if (!(num_online_cpus() > 1))
+		return;
+
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+	for_each_cpu_and(cpu, mask, cpu_online_mask) {
+		if (this_cpu == cpu)
+			continue;
+		
+		printk(KERN_CRIT "kgdb: %s:%d Sending IPI for CPU %d\n",
+			__func__, __LINE__, cpu);
+		/* xen_send_IPI_one(cpu, vector); */
+		xen_smp_send_call_function_single_ipi(cpu);
+	}
+}
+
+void xen_send_IPI_allbutself(int vector)
+{
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
+	xen_send_IPI_mask_allbutself(cpu_online_mask, vector);
+}
+
+
 static irqreturn_t xen_call_function_interrupt(int irq, void *dev_id)
 {
 	irq_enter();
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 58ca7ce..f93fdad 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -40,6 +40,7 @@
 #include <linux/freezer.h>
 #include <linux/slab.h>
 #include <linux/serial_core.h>
+#include <linux/ratelimit.h>

 #include <asm/uaccess.h>

@@ -755,10 +756,25 @@ int hvc_poll_init(struct tty_driver *driver, int
line, char *options)
 static int hvc_poll_get_char(struct tty_driver *driver, int line)
 {
 	struct tty_struct *tty = driver->ttys[0];
-	struct hvc_struct *hp = tty->driver_data;
+	struct hvc_struct *hp;
 	int n;
 	char ch;

+	if (!tty) {
+		printk_ratelimited(KERN_CRIT "kgdb: %s:%d invalid driver data %s\n",
+				__func__, __LINE__, driver->name);
+		return -1;
+	}
+
+
+	hp = tty->driver_data;
+	if (!hp || !hp->ops) {
+		printk_ratelimited(KERN_CRIT "kgdb: %s:%d invalid hp, or hp->ops\n",
+				__func__, __LINE__);
+		return -1;
+	}
+	
+
 	n = hp->ops->get_chars(hp->vtermno, &ch, 1);

 	if (n == 0)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 0065da4..8caa6fa 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -365,6 +365,8 @@ struct tty_driver *tty_find_polling_driver(char
*name, int *line)
 		    p->ops->poll_init && !p->ops->poll_init(p, tty_line, stp)) {
 			res = tty_driver_kref_get(p);
 			*line = tty_line;
+			printk(KERN_CRIT "kgdb: %s:%d Found tty %s line %d\n",
+				__func__, __LINE__, res->name, tty_line);
 			break;
 		}
 	}
@@ -1279,9 +1281,12 @@ static int tty_driver_install_tty(struct
tty_driver *driver,
 	if (tty_init_termios(tty) == 0) {
 		tty_driver_kref_get(driver);
 		tty->count++;
+		printk(KERN_CRIT "kgdb: Installing tty %s %d\n", driver->name, idx);
 		driver->ttys[idx] = tty;
 		return 0;
 	}
+
+	printk(KERN_CRIT "kgdb: Failed to init %s\n", driver->name);
 	return -ENOMEM;
 }

@@ -1298,6 +1303,7 @@ static int tty_driver_install_tty(struct
tty_driver *driver,
 static void tty_driver_remove_tty(struct tty_driver *driver,
 						struct tty_struct *tty)
 {
+	printk(KERN_CRIT "kgdb: Removing tty %s %d\n", driver->name, tty->count);
 	if (driver->ops->remove)
 		driver->ops->remove(driver, tty);
 	else
@@ -3064,6 +3070,7 @@ int tty_register_driver(struct tty_driver *driver)
 	}

 	if (p) {
+		printk(KERN_ERR "kgdb: setting up ttys for %s\n", driver->name);
 		driver->ttys = (struct tty_struct **)p;
 		driver->termios = (struct ktermios **)(p + driver->num);
 	} else {
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index cefd4a1..a773f91 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -54,6 +54,10 @@
 #include <asm/atomic.h>
 #include <asm/system.h>

+#ifdef CONFIG_XEN
+#include <asm/xen/hypercall.h>
+#endif
+
 #include "debug_core.h"

 static int kgdb_break_asap;
@@ -405,8 +409,10 @@ static int kgdb_reenter_check(struct kgdb_state *ks)
 {
 	unsigned long addr;

-	if (atomic_read(&kgdb_active) != raw_smp_processor_id())
+	if (atomic_read(&kgdb_active) != raw_smp_processor_id()) {
+		printk(KERN_CRIT "KGDB: bailing %d != %d\n", kgdb_active,
raw_smp_processor_id());
 		return 0;
+	}

 	/* Panic on recursive debugger calls: */
 	exception_level++;
@@ -468,6 +474,7 @@ static int kgdb_cpu_enter(struct kgdb_state *ks,
struct pt_regs *regs,
 	kgdb_info[ks->cpu].enter_kgdb++;
 	kgdb_info[ks->cpu].exception_state |= exception_state;

+	printk(KERN_CRIT "kgdb: %s:%d cpuid: %d\n", __func__, __LINE__,
raw_smp_processor_id());
 	if (exception_state == DCPU_WANT_MASTER)
 		atomic_inc(&masters_in_kgdb);
 	else
@@ -477,6 +484,7 @@ static int kgdb_cpu_enter(struct kgdb_state *ks,
struct pt_regs *regs,
 		arch_kgdb_ops.disable_hw_break(regs);

 acquirelock:
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	/*
 	 * Interrupts will be restored by the 'trap return' code, except when
 	 * single stepping.
@@ -502,8 +510,10 @@ acquirelock:
 	 * CPU will loop if it is a slave or request to become a kgdb
 	 * master cpu and acquire the kgdb_active lock:
 	 */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	while (1) {
 cpu_loop:
+		printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 		if (kgdb_info[cpu].exception_state & DCPU_NEXT_MASTER) {
 			kgdb_info[cpu].exception_state &= ~DCPU_NEXT_MASTER;
 			goto cpu_master_loop;
@@ -517,6 +527,7 @@ cpu_loop:
 				goto return_normal;
 		} else {
 return_normal:
+			printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 			/* Return to normal operation by executing any
 			 * hw breakpoint fixup.
 			 */
@@ -536,6 +547,7 @@ return_normal:
 		cpu_relax();
 	}

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	/*
 	 * For single stepping, try to only enter on the processor
 	 * that was single stepping.  To gaurd against a deadlock, the
@@ -553,6 +565,7 @@ return_normal:
 		goto acquirelock;
 	}

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	if (!kgdb_io_ready(1)) {
 		kgdb_info[cpu].ret_state = 1;
 		goto kgdb_restore; /* No I/O connection, resume the system */
@@ -561,10 +574,12 @@ return_normal:
 	/*
 	 * Don't enter if we have hit a removed breakpoint.
 	 */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	if (kgdb_skipexception(ks->ex_vector, ks->linux_regs))
 		goto kgdb_restore;

 	/* Call the I/O driver's pre_exception routine */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	if (dbg_io_ops->pre_exception)
 		dbg_io_ops->pre_exception();

@@ -572,21 +587,30 @@ return_normal:
 	 * Get the passive CPU lock which will hold all the non-primary
 	 * CPU in a spin state while the debugger is active
 	 */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	if (!kgdb_single_step)
 		raw_spin_lock(&dbg_slave_lock);

 #ifdef CONFIG_SMP
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	/* Signal the other CPUs to enter kgdb_wait() */
 	if ((!kgdb_single_step) && kgdb_do_roundup)
 		kgdb_roundup_cpus(flags);
 #endif

+#if 0
 	/*
 	 * Wait for the other CPUs to be notified and be waiting for us:
 	 */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	while (kgdb_do_roundup && (atomic_read(&masters_in_kgdb) +
-				atomic_read(&slaves_in_kgdb)) != online_cpus)
+				atomic_read(&slaves_in_kgdb)) != online_cpus) {
+#ifdef CONFIG_XEN
+		HYPERVISOR_sched_op(SCHEDOP_yield, NULL);
+#endif
 		cpu_relax();
+	}
+#endif

 	/*
 	 * At this point the primary processor is completely
@@ -602,6 +626,7 @@ return_normal:

 	while (1) {
 cpu_master_loop:
+		printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 		if (dbg_kdb_mode) {
 			kgdb_connected = 1;
 			error = kdb_stub(ks);
@@ -624,6 +649,7 @@ cpu_master_loop:
 		}
 	}

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	/* Call the I/O driver's post_exception routine */
 	if (dbg_io_ops->post_exception)
 		dbg_io_ops->post_exception();
@@ -636,6 +662,7 @@ cpu_master_loop:
 	}

 kgdb_restore:
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	if (atomic_read(&kgdb_cpu_doing_single_step) != -1) {
 		int sstep_cpu = atomic_read(&kgdb_cpu_doing_single_step);
 		if (kgdb_info[sstep_cpu].task)
@@ -659,6 +686,7 @@ kgdb_restore:
 	dbg_touch_watchdogs();
 	local_irq_restore(flags);

+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	return kgdb_info[cpu].ret_state;
 }

@@ -675,6 +703,8 @@ kgdb_handle_exception(int evector, int signo, int
ecode, struct pt_regs *regs)
 	struct kgdb_state kgdb_var;
 	struct kgdb_state *ks = &kgdb_var;

+	printk(KERN_CRIT "kgdb: %s:%d cpu:%d\n", __func__, __LINE__,
raw_smp_processor_id());
+
 	ks->cpu			= raw_smp_processor_id();
 	ks->ex_vector		= evector;
 	ks->signo		= signo;
@@ -696,6 +726,7 @@ int kgdb_nmicallback(int cpu, void *regs)
 	struct kgdb_state kgdb_var;
 	struct kgdb_state *ks = &kgdb_var;

+	printk(KERN_CRIT "kgdb: %s:%d cpu:%d\n", __func__, __LINE__,
raw_smp_processor_id());
 	memset(ks, 0, sizeof(struct kgdb_state));
 	ks->cpu			= cpu;
 	ks->linux_regs		= regs;
@@ -954,11 +985,17 @@ int dbg_io_get_char(void)
  */
 void kgdb_breakpoint(void)
 {
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	atomic_inc(&kgdb_setting_breakpoint);
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	wmb(); /* Sync point before breakpoint */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	arch_kgdb_breakpoint();
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	wmb(); /* Sync point after breakpoint */
+	printk(KERN_CRIT "kgdb: %s:%d\n", __func__, __LINE__);
 	atomic_dec(&kgdb_setting_breakpoint);
+	printk(KERN_CRIT "kgdb: %s exiting\n", __func__);
 }
 EXPORT_SYMBOL_GPL(kgdb_breakpoint);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:58:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:58:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCOZ-0002Wh-IN; Wed, 23 Nov 2011 12:57:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RTCOY-0002W4-2P
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:57:46 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322053035!4660786!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24244 invoked from network); 23 Nov 2011 12:57:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 12:57:15 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pANCv1EK028024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 07:57:01 -0500
Received: from localhost ([10.3.113.10])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pANCuwbD019810; Wed, 23 Nov 2011 07:57:00 -0500
Date: Wed, 23 Nov 2011 18:26:57 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111123125657.GH16665@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111123103852.GG16665@amit-x200.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Wed) 23 Nov 2011 [16:08:52], Amit Shah wrote:
> With this setup, with and without patches, I can spawn two consoles
> via:
> 
> /sbin/agetty /dev/hvc0 9600 vt100
> /sbin/agetty /dev/hvc1 9600 vt100
> 
> (Strange thing is, the second one gives a 'password incorrect' error
> on login attempts, while the first one logs in fine.  I do remember
> testing multiple consoles just fine a year and a half back, so no idea
> why this isn't behaving as expected -- but it mostly looks like a
> userspace issue rather than kernel one.)

Right -- when I test this on the Fedora 11 VM I used back then, the
two consoles work just fine without these patches.  When I use
something newer (F14), I get the weird password rejection, with and
without your patches.

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:58:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:58:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCOZ-0002Wh-IN; Wed, 23 Nov 2011 12:57:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RTCOY-0002W4-2P
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:57:46 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322053035!4660786!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24244 invoked from network); 23 Nov 2011 12:57:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 12:57:15 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pANCv1EK028024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 07:57:01 -0500
Received: from localhost ([10.3.113.10])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pANCuwbD019810; Wed, 23 Nov 2011 07:57:00 -0500
Date: Wed, 23 Nov 2011 18:26:57 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111123125657.GH16665@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111123103852.GG16665@amit-x200.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Wed) 23 Nov 2011 [16:08:52], Amit Shah wrote:
> With this setup, with and without patches, I can spawn two consoles
> via:
> 
> /sbin/agetty /dev/hvc0 9600 vt100
> /sbin/agetty /dev/hvc1 9600 vt100
> 
> (Strange thing is, the second one gives a 'password incorrect' error
> on login attempts, while the first one logs in fine.  I do remember
> testing multiple consoles just fine a year and a half back, so no idea
> why this isn't behaving as expected -- but it mostly looks like a
> userspace issue rather than kernel one.)

Right -- when I test this on the Fedora 11 VM I used back then, the
two consoles work just fine without these patches.  When I use
something newer (F14), I get the weird password rejection, with and
without your patches.

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:59:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCQN-0002gO-3j; Wed, 23 Nov 2011 12:59:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTCQM-0002fm-ES
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:59:38 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322053148!5397087!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29261 invoked from network); 23 Nov 2011 12:59:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 12:59:08 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9090789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:59:08 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 23 Nov 2011
	12:59:08 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 12:59:14 +0000
Thread-Topic: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
	control/shutdown key is removed
Thread-Index: Acyp0lm6FhznbhVmTV2qDuGkX3HUbgADSjyw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4AE8@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
	<1322047419.1005.72.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322047419.1005.72.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 23 November 2011 11:24
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] Prevent xl save from segfaulting
> when control/shutdown key is removed
> 
> On Wed, 2011-11-23 at 11:19 +0000, Paul Durrant wrote:
> > what is the reason for creating control ro to the guest?
> 
> In general libxl prefers to whitelist paths which the guest can
> write too, just to prevent a complete free for all, keep things
> somewhat under control and to help avoid situations where tools
> might inadvertently rely on a guest-writeable key in an unsafe way..
> 
> >  In XenServer we allow the guest to write the control key to
> advertise
> > feature-shutdown, feature-suspend etc. so that the tools know what
> > values of control/shutdown the guest will respond to.
> 
> The libxl way would be to create these at build time (perhaps empty)
> with the appropriate permissions.
> 
> It's not clear how that functionality can be added in a way which is
> compatible with existing guests though, e.g. no Linux guest writes
> those but many can be suspended etc.
> 

So the simple solution, for compatibility's sake, is to make control rw isn't it?

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 12:59:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 12:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCQN-0002gO-3j; Wed, 23 Nov 2011 12:59:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTCQM-0002fm-ES
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 12:59:38 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322053148!5397087!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29261 invoked from network); 23 Nov 2011 12:59:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 12:59:08 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9090789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:59:08 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 23 Nov 2011
	12:59:08 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 12:59:14 +0000
Thread-Topic: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
	control/shutdown key is removed
Thread-Index: Acyp0lm6FhznbhVmTV2qDuGkX3HUbgADSjyw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4AE8@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
	<1322047419.1005.72.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322047419.1005.72.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 23 November 2011 11:24
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] Prevent xl save from segfaulting
> when control/shutdown key is removed
> 
> On Wed, 2011-11-23 at 11:19 +0000, Paul Durrant wrote:
> > what is the reason for creating control ro to the guest?
> 
> In general libxl prefers to whitelist paths which the guest can
> write too, just to prevent a complete free for all, keep things
> somewhat under control and to help avoid situations where tools
> might inadvertently rely on a guest-writeable key in an unsafe way..
> 
> >  In XenServer we allow the guest to write the control key to
> advertise
> > feature-shutdown, feature-suspend etc. so that the tools know what
> > values of control/shutdown the guest will respond to.
> 
> The libxl way would be to create these at build time (perhaps empty)
> with the appropriate permissions.
> 
> It's not clear how that functionality can be added in a way which is
> compatible with existing guests though, e.g. no Linux guest writes
> those but many can be suspended etc.
> 

So the simple solution, for compatibility's sake, is to make control rw isn't it?

  Paul
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:05:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:05:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCVu-00031r-3f; Wed, 23 Nov 2011 13:05:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTCVt-00031g-3i
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:05:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322053490!2723902!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13040 invoked from network); 23 Nov 2011 13:04:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:04:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9091051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:04:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 13:04:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 23 Nov 2011 13:04:48 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4AE8@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
	<1322047419.1005.72.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AE8@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322053488.1005.107.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 12:59 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 23 November 2011 11:24
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: RE: [Xen-devel] [PATCH] Prevent xl save from segfaulting
> > when control/shutdown key is removed
> > 
> > On Wed, 2011-11-23 at 11:19 +0000, Paul Durrant wrote:
> > > what is the reason for creating control ro to the guest?
> > 
> > In general libxl prefers to whitelist paths which the guest can
> > write too, just to prevent a complete free for all, keep things
> > somewhat under control and to help avoid situations where tools
> > might inadvertently rely on a guest-writeable key in an unsafe way..
> > 
> > >  In XenServer we allow the guest to write the control key to
> > advertise
> > > feature-shutdown, feature-suspend etc. so that the tools know what
> > > values of control/shutdown the guest will respond to.
> > 
> > The libxl way would be to create these at build time (perhaps empty)
> > with the appropriate permissions.
> > 
> > It's not clear how that functionality can be added in a way which is
> > compatible with existing guests though, e.g. no Linux guest writes
> > those but many can be suspended etc.
> > 
> 
> So the simple solution, for compatibility's sake, is to make control rw isn't it?

The problem I'm thinking of exists even if control is rw.

Given an empty control directory how do you know if a guest supports
suspend or not, given that most existing guests which do support suspend
do not write any key there?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:05:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:05:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCVu-00031r-3f; Wed, 23 Nov 2011 13:05:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTCVt-00031g-3i
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:05:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322053490!2723902!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13040 invoked from network); 23 Nov 2011 13:04:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:04:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9091051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:04:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 13:04:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 23 Nov 2011 13:04:48 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4AE8@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
	<1322047419.1005.72.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AE8@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322053488.1005.107.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 12:59 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 23 November 2011 11:24
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: RE: [Xen-devel] [PATCH] Prevent xl save from segfaulting
> > when control/shutdown key is removed
> > 
> > On Wed, 2011-11-23 at 11:19 +0000, Paul Durrant wrote:
> > > what is the reason for creating control ro to the guest?
> > 
> > In general libxl prefers to whitelist paths which the guest can
> > write too, just to prevent a complete free for all, keep things
> > somewhat under control and to help avoid situations where tools
> > might inadvertently rely on a guest-writeable key in an unsafe way..
> > 
> > >  In XenServer we allow the guest to write the control key to
> > advertise
> > > feature-shutdown, feature-suspend etc. so that the tools know what
> > > values of control/shutdown the guest will respond to.
> > 
> > The libxl way would be to create these at build time (perhaps empty)
> > with the appropriate permissions.
> > 
> > It's not clear how that functionality can be added in a way which is
> > compatible with existing guests though, e.g. no Linux guest writes
> > those but many can be suspended etc.
> > 
> 
> So the simple solution, for compatibility's sake, is to make control rw isn't it?

The problem I'm thinking of exists even if control is rw.

Given an empty control directory how do you know if a guest supports
suspend or not, given that most existing guests which do support suspend
do not write any key there?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:12:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCcr-0003FT-6n; Wed, 23 Nov 2011 13:12:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTCcp-0003FO-Ex
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:12:31 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322053883!57955914!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19416 invoked from network); 23 Nov 2011 13:11:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9091236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:12:06 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 23 Nov 2011
	13:12:06 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 13:12:13 +0000
Thread-Topic: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
	control/shutdown key is removed
Thread-Index: Acyp4Hs15MItXuhlTU6sRGVifNYk0AAAJVBQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4AED@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
	<1322047419.1005.72.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AE8@LONPMAILBOX01.citrite.net>
	<1322053488.1005.107.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322053488.1005.107.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

True. I was conflating the key rm issue with the fact that the XenServer Windows PV guest agent gets unhappy because it can't advertise its features (which I hadn't mentioned before).

I suppose that libxl will just have to continue to speculatively write control/shutdown and timeout if it's not NUL-ed or rm-ed as it does now.

  Paul

> -----Original Message-----
> From: Ian Campbell
> Sent: 23 November 2011 13:05
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] Prevent xl save from segfaulting
> when control/shutdown key is removed
> 
> On Wed, 2011-11-23 at 12:59 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 23 November 2011 11:24
> > > To: Paul Durrant
> > > Cc: xen-devel@lists.xensource.com
> > > Subject: RE: [Xen-devel] [PATCH] Prevent xl save from
> segfaulting
> > > when control/shutdown key is removed
> > >
> > > On Wed, 2011-11-23 at 11:19 +0000, Paul Durrant wrote:
> > > > what is the reason for creating control ro to the guest?
> > >
> > > In general libxl prefers to whitelist paths which the guest can
> > > write too, just to prevent a complete free for all, keep things
> > > somewhat under control and to help avoid situations where tools
> > > might inadvertently rely on a guest-writeable key in an unsafe
> way..
> > >
> > > >  In XenServer we allow the guest to write the control key to
> > > advertise
> > > > feature-shutdown, feature-suspend etc. so that the tools know
> what
> > > > values of control/shutdown the guest will respond to.
> > >
> > > The libxl way would be to create these at build time (perhaps
> empty)
> > > with the appropriate permissions.
> > >
> > > It's not clear how that functionality can be added in a way
> which is
> > > compatible with existing guests though, e.g. no Linux guest
> writes
> > > those but many can be suspended etc.
> > >
> >
> > So the simple solution, for compatibility's sake, is to make
> control rw isn't it?
> 
> The problem I'm thinking of exists even if control is rw.
> 
> Given an empty control directory how do you know if a guest supports
> suspend or not, given that most existing guests which do support
> suspend do not write any key there?
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:12:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:12:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCcr-0003FT-6n; Wed, 23 Nov 2011 13:12:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTCcp-0003FO-Ex
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:12:31 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322053883!57955914!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19416 invoked from network); 23 Nov 2011 13:11:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9091236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:12:06 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 23 Nov 2011
	13:12:06 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 13:12:13 +0000
Thread-Topic: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
	control/shutdown key is removed
Thread-Index: Acyp4Hs15MItXuhlTU6sRGVifNYk0AAAJVBQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4AED@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
	<1322047419.1005.72.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AE8@LONPMAILBOX01.citrite.net>
	<1322053488.1005.107.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322053488.1005.107.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

True. I was conflating the key rm issue with the fact that the XenServer Windows PV guest agent gets unhappy because it can't advertise its features (which I hadn't mentioned before).

I suppose that libxl will just have to continue to speculatively write control/shutdown and timeout if it's not NUL-ed or rm-ed as it does now.

  Paul

> -----Original Message-----
> From: Ian Campbell
> Sent: 23 November 2011 13:05
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH] Prevent xl save from segfaulting
> when control/shutdown key is removed
> 
> On Wed, 2011-11-23 at 12:59 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 23 November 2011 11:24
> > > To: Paul Durrant
> > > Cc: xen-devel@lists.xensource.com
> > > Subject: RE: [Xen-devel] [PATCH] Prevent xl save from
> segfaulting
> > > when control/shutdown key is removed
> > >
> > > On Wed, 2011-11-23 at 11:19 +0000, Paul Durrant wrote:
> > > > what is the reason for creating control ro to the guest?
> > >
> > > In general libxl prefers to whitelist paths which the guest can
> > > write too, just to prevent a complete free for all, keep things
> > > somewhat under control and to help avoid situations where tools
> > > might inadvertently rely on a guest-writeable key in an unsafe
> way..
> > >
> > > >  In XenServer we allow the guest to write the control key to
> > > advertise
> > > > feature-shutdown, feature-suspend etc. so that the tools know
> what
> > > > values of control/shutdown the guest will respond to.
> > >
> > > The libxl way would be to create these at build time (perhaps
> empty)
> > > with the appropriate permissions.
> > >
> > > It's not clear how that functionality can be added in a way
> which is
> > > compatible with existing guests though, e.g. no Linux guest
> writes
> > > those but many can be suspended etc.
> > >
> >
> > So the simple solution, for compatibility's sake, is to make
> control rw isn't it?
> 
> The problem I'm thinking of exists even if control is rw.
> 
> Given an empty control directory how do you know if a guest supports
> suspend or not, given that most existing guests which do support
> suspend do not write any key there?
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:16:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCfz-0003Pi-RB; Wed, 23 Nov 2011 13:15:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RTCfy-0003PH-FK
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:15:46 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322054115!2715400!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10821 invoked from network); 23 Nov 2011 13:15:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 13:15:16 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pANDF55M001620
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 08:15:05 -0500
Received: from localhost ([10.3.113.10])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pANDF2N1026600; Wed, 23 Nov 2011 08:15:04 -0500
Date: Wed, 23 Nov 2011 18:45:01 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Sasha Levin <levinsasha928@gmail.com>
Message-ID: <20111123131501.GK16665@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<20111123125657.GH16665@amit-x200.redhat.com>
	<1322053564.3581.19.camel@lappy>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322053564.3581.19.camel@lappy>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Miche Baker-Harvey <miche@google.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Wed) 23 Nov 2011 [15:06:04], Sasha Levin wrote:
> On Wed, 2011-11-23 at 18:26 +0530, Amit Shah wrote:
> > On (Wed) 23 Nov 2011 [16:08:52], Amit Shah wrote:
> > > With this setup, with and without patches, I can spawn two consoles
> > > via:
> > > 
> > > /sbin/agetty /dev/hvc0 9600 vt100
> > > /sbin/agetty /dev/hvc1 9600 vt100
> > > 
> > > (Strange thing is, the second one gives a 'password incorrect' error
> > > on login attempts, while the first one logs in fine.  I do remember
> > > testing multiple consoles just fine a year and a half back, so no idea
> > > why this isn't behaving as expected -- but it mostly looks like a
> > > userspace issue rather than kernel one.)
> > 
> > Right -- when I test this on the Fedora 11 VM I used back then, the
> > two consoles work just fine without these patches.  When I use
> > something newer (F14), I get the weird password rejection, with and
> > without your patches.
> 
> It's not a weird password rejection, it's probably not set as a secure
> terminal :)
> 
> Try adding hvc1 to /etc/securetty on the guest.

Ah, of course :-)

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:16:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:16:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCfz-0003Pi-RB; Wed, 23 Nov 2011 13:15:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RTCfy-0003PH-FK
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:15:46 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322054115!2715400!1
X-Originating-IP: [209.132.183.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10821 invoked from network); 23 Nov 2011 13:15:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 13:15:16 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pANDF55M001620
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 23 Nov 2011 08:15:05 -0500
Received: from localhost ([10.3.113.10])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pANDF2N1026600; Wed, 23 Nov 2011 08:15:04 -0500
Date: Wed, 23 Nov 2011 18:45:01 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Sasha Levin <levinsasha928@gmail.com>
Message-ID: <20111123131501.GK16665@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<20111123125657.GH16665@amit-x200.redhat.com>
	<1322053564.3581.19.camel@lappy>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322053564.3581.19.camel@lappy>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Miche Baker-Harvey <miche@google.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On (Wed) 23 Nov 2011 [15:06:04], Sasha Levin wrote:
> On Wed, 2011-11-23 at 18:26 +0530, Amit Shah wrote:
> > On (Wed) 23 Nov 2011 [16:08:52], Amit Shah wrote:
> > > With this setup, with and without patches, I can spawn two consoles
> > > via:
> > > 
> > > /sbin/agetty /dev/hvc0 9600 vt100
> > > /sbin/agetty /dev/hvc1 9600 vt100
> > > 
> > > (Strange thing is, the second one gives a 'password incorrect' error
> > > on login attempts, while the first one logs in fine.  I do remember
> > > testing multiple consoles just fine a year and a half back, so no idea
> > > why this isn't behaving as expected -- but it mostly looks like a
> > > userspace issue rather than kernel one.)
> > 
> > Right -- when I test this on the Fedora 11 VM I used back then, the
> > two consoles work just fine without these patches.  When I use
> > something newer (F14), I get the weird password rejection, with and
> > without your patches.
> 
> It's not a weird password rejection, it's probably not set as a secure
> terminal :)
> 
> Try adding hvc1 to /etc/securetty on the guest.

Ah, of course :-)

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:25:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:25:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCoy-0003eo-2c; Wed, 23 Nov 2011 13:25:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTCow-0003ej-46
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:25:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322054672!3756111!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28992 invoked from network); 23 Nov 2011 13:24:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:24:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9091539"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:24:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:24:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTCoR-000519-BB;
	Wed, 23 Nov 2011 13:24:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTCoR-0000rV-2t;
	Wed, 23 Nov 2011 13:24:31 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10008-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 13:24:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10008: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10008 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10008/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  7aa5838499d1
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24186:7aa5838499d1
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 23 11:15:31 2011 +0000
    
    tools: use system libaio for blktap1 as well.
    
    24184:4ecd3615e726 missed this because I was accidentally testing with a
    .config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
    without this. There were no other issues.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24185:f88c745575bb
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 18:51:13 2011 +0000
    
    docs: remove some fatally out of date documentation
    
    I think these are better off deleted than remaining to confuse people.
    
    docs/misc/blkif-drivers-explained.txt:
    
     - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.
    
    docs/misc/cpuid-config-for-guest.txt:
    
     - Doesn't really say anything, in particular doesn't actually describe how to
       configure CPUID.
    
    docs/misc/hg-cheatsheet.txt:
    
     - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
       under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
       hardly unusual anymore I think there must be better guides out there so this
       one is not worth resurecting.
    
    docs/misc/network_setup.txt:
    
     - This is more comprehensively documented on the wiki these days.
    
    docs/misc/VMX_changes.txt:
    
     - Is basically a changelog from the initial implementation of VMX in 2004.
    
    I'm not sure about some of the other docs, but these ones seemed fairly
    obvious.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24184:4ecd3615e726
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:25:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:25:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTCoy-0003eo-2c; Wed, 23 Nov 2011 13:25:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTCow-0003ej-46
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:25:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322054672!3756111!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28992 invoked from network); 23 Nov 2011 13:24:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:24:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9091539"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:24:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:24:31 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTCoR-000519-BB;
	Wed, 23 Nov 2011 13:24:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTCoR-0000rV-2t;
	Wed, 23 Nov 2011 13:24:31 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10008-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 13:24:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10008: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10008 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10008/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  7aa5838499d1
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24186:7aa5838499d1
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 23 11:15:31 2011 +0000
    
    tools: use system libaio for blktap1 as well.
    
    24184:4ecd3615e726 missed this because I was accidentally testing with a
    .config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
    without this. There were no other issues.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24185:f88c745575bb
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 18:51:13 2011 +0000
    
    docs: remove some fatally out of date documentation
    
    I think these are better off deleted than remaining to confuse people.
    
    docs/misc/blkif-drivers-explained.txt:
    
     - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.
    
    docs/misc/cpuid-config-for-guest.txt:
    
     - Doesn't really say anything, in particular doesn't actually describe how to
       configure CPUID.
    
    docs/misc/hg-cheatsheet.txt:
    
     - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
       under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
       hardly unusual anymore I think there must be better guides out there so this
       one is not worth resurecting.
    
    docs/misc/network_setup.txt:
    
     - This is more comprehensively documented on the wiki these days.
    
    docs/misc/VMX_changes.txt:
    
     - Is basically a changelog from the initial implementation of VMX in 2004.
    
    I'm not sure about some of the other docs, but these ones seemed fairly
    obvious.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24184:4ecd3615e726
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:46:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:46:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTD9n-0004G4-4O; Wed, 23 Nov 2011 13:46:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTD9l-0004Fs-78
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:46:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322055963!5418981!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29494 invoked from network); 23 Nov 2011 13:46:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:46:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:46:02 +0000
Date: Wed, 23 Nov 2011 13:46:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20125.47084.805207.230744@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111221430380.31179@kaball-desktop>
References: <alpine.DEB.2.00.1110131909250.3519@kaball-desktop>
	<20125.47084.805207.230744@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v8 0/6] build upstream qemu and seabios by
 default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 18 Oct 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v8 0/6] build upstream qemu and seabios by default"):
> > Hi all,
> > this is the eighth version of the patch series to introduce upstream qemu
> > and seabios in the xen-unstable build system.
> 
> I tried this series.  I built my tree with this in .config
>   CONFIG_QEMU=/u/iwj/work/1/qemu-iwj.git
>   QEMU_UPSTREAM_URL=/u/iwj/work/1/qemu-upstream-unstable.git
> 
> I then found that the directory qemu-upstream-unstable.git contained a
> symlink qemu-upstream-unstable.git linking to the directory (by full
> pathname).

Yes, it has been the case since the early versions of this patch series.
Now I have fixed the out of tree build in upstream qemu so we can do the
same thing we are already doing with qemu-xen-traditional.


> It also had "linux-headers/asm" which wasn't covered by
> .gitignore.

It's a bug in qemu's "make clean". I'll work on it in the qemu tree. FYI
git clean works very well :)


> The xen-unstable-tools.hg tree I built it in also ended up with an
> awful lot of
>  ? tools/firmware/seabios-dir-remote/*

That is due to a typo in patch #5, it is fixed now.


> Can you please test:
> 
>  * That setting CONFIG_QEMU and QEMU_UPSTREAM_URL and
>    SEABIOS_UPSTREAM_URL (work whether they are set to URLs or
>    directories)

I have already tested this before sending v8 to the list


>  * That after building the dists/ tree looks as you would expect
>    (compare it with a dists/ tree from before your series)

done

>  * That setting {QEMU_UPSTREAM,SEABIOS_UPSTREAM,QEMU}_TAG still works
>    afterwards.

The behaviour is unchanged since before the patch series.

>  * That "make clean" cleans up everything that "make" creates except
>    for things which you deliberately decide it shouldn't

done (apart from the aforementioned bug in qemu's "make clean")


>  * That everything that "make" creates is mentioned in the
>    appropriate ignore files

done

>  * That a 2nd "make" doesn't do a lot of needless work

done

>  * That machinery is provided for pulling included trees eg
>    analagous to
>      make tools/ioemu-dir-force-update

Added to patch #4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:46:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:46:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTD9n-0004G4-4O; Wed, 23 Nov 2011 13:46:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTD9l-0004Fs-78
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:46:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322055963!5418981!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29494 invoked from network); 23 Nov 2011 13:46:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:46:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:46:02 +0000
Date: Wed, 23 Nov 2011 13:46:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20125.47084.805207.230744@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111221430380.31179@kaball-desktop>
References: <alpine.DEB.2.00.1110131909250.3519@kaball-desktop>
	<20125.47084.805207.230744@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v8 0/6] build upstream qemu and seabios by
 default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 18 Oct 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH v8 0/6] build upstream qemu and seabios by default"):
> > Hi all,
> > this is the eighth version of the patch series to introduce upstream qemu
> > and seabios in the xen-unstable build system.
> 
> I tried this series.  I built my tree with this in .config
>   CONFIG_QEMU=/u/iwj/work/1/qemu-iwj.git
>   QEMU_UPSTREAM_URL=/u/iwj/work/1/qemu-upstream-unstable.git
> 
> I then found that the directory qemu-upstream-unstable.git contained a
> symlink qemu-upstream-unstable.git linking to the directory (by full
> pathname).

Yes, it has been the case since the early versions of this patch series.
Now I have fixed the out of tree build in upstream qemu so we can do the
same thing we are already doing with qemu-xen-traditional.


> It also had "linux-headers/asm" which wasn't covered by
> .gitignore.

It's a bug in qemu's "make clean". I'll work on it in the qemu tree. FYI
git clean works very well :)


> The xen-unstable-tools.hg tree I built it in also ended up with an
> awful lot of
>  ? tools/firmware/seabios-dir-remote/*

That is due to a typo in patch #5, it is fixed now.


> Can you please test:
> 
>  * That setting CONFIG_QEMU and QEMU_UPSTREAM_URL and
>    SEABIOS_UPSTREAM_URL (work whether they are set to URLs or
>    directories)

I have already tested this before sending v8 to the list


>  * That after building the dists/ tree looks as you would expect
>    (compare it with a dists/ tree from before your series)

done

>  * That setting {QEMU_UPSTREAM,SEABIOS_UPSTREAM,QEMU}_TAG still works
>    afterwards.

The behaviour is unchanged since before the patch series.

>  * That "make clean" cleans up everything that "make" creates except
>    for things which you deliberately decide it shouldn't

done (apart from the aforementioned bug in qemu's "make clean")


>  * That everything that "make" creates is mentioned in the
>    appropriate ignore files

done

>  * That a 2nd "make" doesn't do a lot of needless work

done

>  * That machinery is provided for pulling included trees eg
>    analagous to
>      make tools/ioemu-dir-force-update

Added to patch #4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:50:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:50:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDCv-0004PJ-Pd; Wed, 23 Nov 2011 13:49:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDCu-0004P5-Dy
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:49:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322056041!45496342!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18113 invoked from network); 23 Nov 2011 13:47:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:47:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:49:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:49:20 +0000
Date: Wed, 23 Nov 2011 13:50:08 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 0/6] build upstream qemu and seabios by
	default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this is the nineth version of the patch series to introduce upstream qemu
and seabios in the xen-unstable build system.


Changes to v8:

- build upstream qemu out of tree;

- add a tools/qemu-xen-dir-force-update target;

- add a tools/firmware/seabios-dir-force-update target;

- call make install from subdir-all and subdir-install
qemu-xen-traditional and qemu-xen targets; 

- fix a typo in patch #5;


Changes to v7:

- call upstream qemu's configure script right before building qemu and
after building libxc and xenstore because it needs them;

- introduce a new patch to move the call to xen-setup after building
libxc and xenstore for consistency with upstream qemu;

- fix a typo in tools/Makefile (patch #4);


Changes to v6:

- add "set -e" to git-checkout.sh;

- add argument count check to git-checkout.sh;

- remove spurious semicolons in git-checkout.sh.


Changes to v5:

- use $GIT in git-checkout.sh;

- add an http mirror for seabios;

- use $(LIBEXEC) to configure upstream qemu;

- append a patch for libxenlight to find the upstream qemu binary under
$(LIBEXEC).


Changes to v4:

- remove an obsolete comment;

- use /bin/sh to execute git-checkout.sh rathen than /bin/bash.


Changes to v3:

- reduce the scope of git-checkout.sh, now it only does what the name
says; calling "configure" is responsibility of the caller. As a result
of this change, the build still works when the user specifies a local
directory in the CONFIG_QEMU environmental variable;

- use a more official qemu repository hosted on xenbits;

- use a changeset as QEMU_UPSTREAM_TAG rather than a branch name.



Changes to v2:

- move tools/git-checkout.sh to scripts/git-checkout.sh;

- use git-checkout.sh for seabios;

- improve seabios integration with tools/firmware make system;

- add qemu-xen-traditional, qemu-xen and seabios dir entries to
.hgignore.



Changes to v1:

- always build upstream qemu and seabios, rather than introducing them
as an option.


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:50:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:50:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDCv-0004PJ-Pd; Wed, 23 Nov 2011 13:49:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDCu-0004P5-Dy
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:49:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322056041!45496342!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18113 invoked from network); 23 Nov 2011 13:47:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:47:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:49:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:49:20 +0000
Date: Wed, 23 Nov 2011 13:50:08 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 0/6] build upstream qemu and seabios by
	default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this is the nineth version of the patch series to introduce upstream qemu
and seabios in the xen-unstable build system.


Changes to v8:

- build upstream qemu out of tree;

- add a tools/qemu-xen-dir-force-update target;

- add a tools/firmware/seabios-dir-force-update target;

- call make install from subdir-all and subdir-install
qemu-xen-traditional and qemu-xen targets; 

- fix a typo in patch #5;


Changes to v7:

- call upstream qemu's configure script right before building qemu and
after building libxc and xenstore because it needs them;

- introduce a new patch to move the call to xen-setup after building
libxc and xenstore for consistency with upstream qemu;

- fix a typo in tools/Makefile (patch #4);


Changes to v6:

- add "set -e" to git-checkout.sh;

- add argument count check to git-checkout.sh;

- remove spurious semicolons in git-checkout.sh.


Changes to v5:

- use $GIT in git-checkout.sh;

- add an http mirror for seabios;

- use $(LIBEXEC) to configure upstream qemu;

- append a patch for libxenlight to find the upstream qemu binary under
$(LIBEXEC).


Changes to v4:

- remove an obsolete comment;

- use /bin/sh to execute git-checkout.sh rathen than /bin/bash.


Changes to v3:

- reduce the scope of git-checkout.sh, now it only does what the name
says; calling "configure" is responsibility of the caller. As a result
of this change, the build still works when the user specifies a local
directory in the CONFIG_QEMU environmental variable;

- use a more official qemu repository hosted on xenbits;

- use a changeset as QEMU_UPSTREAM_TAG rather than a branch name.



Changes to v2:

- move tools/git-checkout.sh to scripts/git-checkout.sh;

- use git-checkout.sh for seabios;

- improve seabios integration with tools/firmware make system;

- add qemu-xen-traditional, qemu-xen and seabios dir entries to
.hgignore.



Changes to v1:

- always build upstream qemu and seabios, rather than introducing them
as an option.


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEf-0004WZ-6S; Wed, 23 Nov 2011 13:51:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEd-0004VP-Kr
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322056264!4297346!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1284 invoked from network); 23 Nov 2011 13:51:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="171669548"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:03 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAU023713;
	Wed, 23 Nov 2011 05:51:01 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:56 +0000
Message-ID: <1322056320-5826-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 2/6] Rename ioemu-dir as
	qemu-xen-traditional-dir
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore        |    4 ++--
 Makefile         |   14 +++++++-------
 stubdom/Makefile |    8 ++++----
 tools/Makefile   |   26 +++++++++++++-------------
 4 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/.hgignore b/.hgignore
index 067d83d..c1486a6 100644
--- a/.hgignore
+++ b/.hgignore
@@ -295,8 +295,8 @@
 ^tools/xm-test/lib/XmTestLib/config.py$
 ^tools/xm-test/lib/XmTestReport/xmtest.py$
 ^tools/xm-test/tests/.*\.test$
-^tools/ioemu-dir-remote
-^tools/ioemu-dir$
+^tools/qemu-xen-traditional-dir-remote
+^tools/qemu-xen-traditional-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Makefile b/Makefile
index 31e8795..c0197a5 100644
--- a/Makefile
+++ b/Makefile
@@ -70,7 +70,7 @@ install-tools:
 	$(MAKE) -C tools install
 
 ifeq ($(CONFIG_IOEMU),y)
-install-tools: tools/ioemu-dir
+install-tools: tools/qemu-xen-traditional-dir
 endif
 
 .PHONY: install-kernels
@@ -78,18 +78,18 @@ install-kernels:
 	for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done
 
 .PHONY: install-stubdom
-install-stubdom: tools/ioemu-dir install-tools
+install-stubdom: tools/qemu-xen-traditional-dir install-tools
 	$(MAKE) -C stubdom install
 ifeq (x86_64,$(XEN_TARGET_ARCH))
 	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub
 endif
 
-tools/ioemu-dir:
-	$(MAKE) -C tools ioemu-dir-find
+tools/qemu-xen-traditional-dir:
+	$(MAKE) -C tools qemu-xen-traditional-dir-find
 
-.PHONY: tools/ioemu-dir-force-update
-tools/ioemu-dir-force-update:
-	$(MAKE) -C tools ioemu-dir-force-update
+.PHONY: tools/qemu-xen-traditional-dir-force-update
+tools/qemu-xen-traditional-dir-force-update:
+	$(MAKE) -C tools qemu-xen-traditional-dir-force-update
 
 .PHONY: install-docs
 install-docs:
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 938fc0a..d03ccba 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -218,15 +218,15 @@ $(CROSS_ROOT): cross-newlib cross-zlib cross-libpci
 QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi)
 
 ifeq ($(QEMU_ROOT),.)
-$(XEN_ROOT)/tools/ioemu-dir:
-	$(CROSS_MAKE) -C $(XEN_ROOT)/tools ioemu-dir-find
+$(XEN_ROOT)/tools/qemu-xen-traditional-dir:
+	$(CROSS_MAKE) -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find
 
-ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/ioemu-dir
+ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir
 	mkdir -p ioemu
 	set -e;									\
 	$(buildmakevars2shellvars);						\
 	cd ioemu;								\
-	src="$$XEN_ROOT/tools/ioemu-dir"; export src;				\
+	src="$$XEN_ROOT/tools/qemu-xen-traditional-dir"; export src;		\
 	(cd $$src && find * -type d -print) | xargs mkdir -p;			\
 	(cd $$src && find *	! -type l  -type f  $(addprefix ! -name ,	\
 			'*.[oda1]' 'config-*' config.mak qemu-dm qemu-img-xen	\
diff --git a/tools/Makefile b/tools/Makefile
index beccad2..c19d3c9 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -31,7 +31,7 @@ SUBDIRS-y += libvchan
 
 # do not recurse in to a dir we are about to delete
 ifneq "$(MAKECMDGOALS)" "distclean"
-SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir
+SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir
 endif
 
 SUBDIRS-y += xenpmd
@@ -71,7 +71,7 @@ clean: subdirs-clean
 
 .PHONY: distclean
 distclean: subdirs-distclean
-	rm -rf ioemu-dir ioemu-dir-remote
+	rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -84,34 +84,34 @@ ifneq ($(QEMU_ROOT),.)
 export QEMU_ROOT
 endif
 
-ioemu-dir-find:
+qemu-xen-traditional-dir-find:
 	set -ex; \
 	if test -d $(CONFIG_QEMU); then \
-		mkdir -p ioemu-dir; \
+		mkdir -p qemu-xen-traditional-dir; \
 	else \
 		export GIT=$(GIT); \
-		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
 	set -e; \
 		$(buildmakevars2shellvars); \
-		cd ioemu-dir; \
+		cd qemu-xen-traditional-dir; \
 		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS)
 
-.PHONY: ioemu-dir-force-update
-ioemu-dir-force-update:
+.PHONY: qemu-xen-traditional-dir-force-update
+qemu-xen-traditional-dir-force-update:
 	set -ex; \
 	if [ "$(QEMU_TAG)" ]; then \
-		cd ioemu-dir-remote; \
+		cd qemu-xen-traditional-dir-remote; \
 		$(GIT) fetch origin; \
 		$(GIT) reset --hard $(QEMU_TAG); \
 	fi
 
-subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find
+subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
 
-subdir-clean-ioemu-dir:
-	set -e; if test -d ioemu-dir/.; then \
+subdir-clean-qemu-xen-traditional-dir:
+	set -e; if test -d qemu-xen-traditional-dir/.; then \
 		$(buildmakevars2shellvars); \
-		$(MAKE) -C ioemu-dir clean; \
+		$(MAKE) -C qemu-xen-traditional-dir clean; \
 	fi
 
 subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEf-0004WZ-6S; Wed, 23 Nov 2011 13:51:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEd-0004VP-Kr
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322056264!4297346!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1284 invoked from network); 23 Nov 2011 13:51:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="171669548"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:03 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAU023713;
	Wed, 23 Nov 2011 05:51:01 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:56 +0000
Message-ID: <1322056320-5826-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 2/6] Rename ioemu-dir as
	qemu-xen-traditional-dir
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore        |    4 ++--
 Makefile         |   14 +++++++-------
 stubdom/Makefile |    8 ++++----
 tools/Makefile   |   26 +++++++++++++-------------
 4 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/.hgignore b/.hgignore
index 067d83d..c1486a6 100644
--- a/.hgignore
+++ b/.hgignore
@@ -295,8 +295,8 @@
 ^tools/xm-test/lib/XmTestLib/config.py$
 ^tools/xm-test/lib/XmTestReport/xmtest.py$
 ^tools/xm-test/tests/.*\.test$
-^tools/ioemu-dir-remote
-^tools/ioemu-dir$
+^tools/qemu-xen-traditional-dir-remote
+^tools/qemu-xen-traditional-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Makefile b/Makefile
index 31e8795..c0197a5 100644
--- a/Makefile
+++ b/Makefile
@@ -70,7 +70,7 @@ install-tools:
 	$(MAKE) -C tools install
 
 ifeq ($(CONFIG_IOEMU),y)
-install-tools: tools/ioemu-dir
+install-tools: tools/qemu-xen-traditional-dir
 endif
 
 .PHONY: install-kernels
@@ -78,18 +78,18 @@ install-kernels:
 	for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done
 
 .PHONY: install-stubdom
-install-stubdom: tools/ioemu-dir install-tools
+install-stubdom: tools/qemu-xen-traditional-dir install-tools
 	$(MAKE) -C stubdom install
 ifeq (x86_64,$(XEN_TARGET_ARCH))
 	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub
 endif
 
-tools/ioemu-dir:
-	$(MAKE) -C tools ioemu-dir-find
+tools/qemu-xen-traditional-dir:
+	$(MAKE) -C tools qemu-xen-traditional-dir-find
 
-.PHONY: tools/ioemu-dir-force-update
-tools/ioemu-dir-force-update:
-	$(MAKE) -C tools ioemu-dir-force-update
+.PHONY: tools/qemu-xen-traditional-dir-force-update
+tools/qemu-xen-traditional-dir-force-update:
+	$(MAKE) -C tools qemu-xen-traditional-dir-force-update
 
 .PHONY: install-docs
 install-docs:
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 938fc0a..d03ccba 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -218,15 +218,15 @@ $(CROSS_ROOT): cross-newlib cross-zlib cross-libpci
 QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi)
 
 ifeq ($(QEMU_ROOT),.)
-$(XEN_ROOT)/tools/ioemu-dir:
-	$(CROSS_MAKE) -C $(XEN_ROOT)/tools ioemu-dir-find
+$(XEN_ROOT)/tools/qemu-xen-traditional-dir:
+	$(CROSS_MAKE) -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find
 
-ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/ioemu-dir
+ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir
 	mkdir -p ioemu
 	set -e;									\
 	$(buildmakevars2shellvars);						\
 	cd ioemu;								\
-	src="$$XEN_ROOT/tools/ioemu-dir"; export src;				\
+	src="$$XEN_ROOT/tools/qemu-xen-traditional-dir"; export src;		\
 	(cd $$src && find * -type d -print) | xargs mkdir -p;			\
 	(cd $$src && find *	! -type l  -type f  $(addprefix ! -name ,	\
 			'*.[oda1]' 'config-*' config.mak qemu-dm qemu-img-xen	\
diff --git a/tools/Makefile b/tools/Makefile
index beccad2..c19d3c9 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -31,7 +31,7 @@ SUBDIRS-y += libvchan
 
 # do not recurse in to a dir we are about to delete
 ifneq "$(MAKECMDGOALS)" "distclean"
-SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir
+SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir
 endif
 
 SUBDIRS-y += xenpmd
@@ -71,7 +71,7 @@ clean: subdirs-clean
 
 .PHONY: distclean
 distclean: subdirs-distclean
-	rm -rf ioemu-dir ioemu-dir-remote
+	rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -84,34 +84,34 @@ ifneq ($(QEMU_ROOT),.)
 export QEMU_ROOT
 endif
 
-ioemu-dir-find:
+qemu-xen-traditional-dir-find:
 	set -ex; \
 	if test -d $(CONFIG_QEMU); then \
-		mkdir -p ioemu-dir; \
+		mkdir -p qemu-xen-traditional-dir; \
 	else \
 		export GIT=$(GIT); \
-		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
 	set -e; \
 		$(buildmakevars2shellvars); \
-		cd ioemu-dir; \
+		cd qemu-xen-traditional-dir; \
 		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS)
 
-.PHONY: ioemu-dir-force-update
-ioemu-dir-force-update:
+.PHONY: qemu-xen-traditional-dir-force-update
+qemu-xen-traditional-dir-force-update:
 	set -ex; \
 	if [ "$(QEMU_TAG)" ]; then \
-		cd ioemu-dir-remote; \
+		cd qemu-xen-traditional-dir-remote; \
 		$(GIT) fetch origin; \
 		$(GIT) reset --hard $(QEMU_TAG); \
 	fi
 
-subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find
+subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
 
-subdir-clean-ioemu-dir:
-	set -e; if test -d ioemu-dir/.; then \
+subdir-clean-qemu-xen-traditional-dir:
+	set -e; if test -d qemu-xen-traditional-dir/.; then \
 		$(buildmakevars2shellvars); \
-		$(MAKE) -C ioemu-dir clean; \
+		$(MAKE) -C qemu-xen-traditional-dir clean; \
 	fi
 
 subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEf-0004Wj-KG; Wed, 23 Nov 2011 13:51:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEe-0004VS-HH
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322056264!4297346!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1361 invoked from network); 23 Nov 2011 13:51:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="171669552"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:05 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAW023713;
	Wed, 23 Nov 2011 05:51:04 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:58 +0000
Message-ID: <1322056320-5826-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 4/6] Clone and build upstream Qemu by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore      |    2 ++
 Config.mk      |    7 +++++++
 Makefile       |    9 ++++++++-
 tools/Makefile |   44 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 61 insertions(+), 1 deletions(-)

diff --git a/.hgignore b/.hgignore
index c1486a6..efbb5ed 100644
--- a/.hgignore
+++ b/.hgignore
@@ -297,6 +297,8 @@
 ^tools/xm-test/tests/.*\.test$
 ^tools/qemu-xen-traditional-dir-remote
 ^tools/qemu-xen-traditional-dir$
+^tools/qemu-xen-dir-remote
+^tools/qemu-xen-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Config.mk b/Config.mk
index b2c6ba2..e72324f 100644
--- a/Config.mk
+++ b/Config.mk
@@ -203,6 +203,13 @@ else
 QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git
 endif
 
+ifeq ($(GIT_HTTP),y)
+QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
+else
+QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git
+endif
+QEMU_UPSTREAM_TAG ?= 30f93db54875e1f2836e1f3d21672c33191f883f
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/Makefile b/Makefile
index c0197a5..edc5e3d 100644
--- a/Makefile
+++ b/Makefile
@@ -70,7 +70,7 @@ install-tools:
 	$(MAKE) -C tools install
 
 ifeq ($(CONFIG_IOEMU),y)
-install-tools: tools/qemu-xen-traditional-dir
+install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir
 endif
 
 .PHONY: install-kernels
@@ -91,6 +91,13 @@ tools/qemu-xen-traditional-dir:
 tools/qemu-xen-traditional-dir-force-update:
 	$(MAKE) -C tools qemu-xen-traditional-dir-force-update
 
+tools/qemu-xen-dir:
+	$(MAKE) -C tools qemu-xen-dir-find
+
+.PHONY: tools/qemu-xen-dir-force-update
+tools/qemu-xen-dir-force-update:
+	$(MAKE) -C tools qemu-xen-dir-force-update
+
 .PHONY: install-docs
 install-docs:
 	sh ./docs/check_pkgs && $(MAKE) -C docs install || true
diff --git a/tools/Makefile b/tools/Makefile
index 20bee85..f9a07d2 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -32,6 +32,7 @@ SUBDIRS-y += libvchan
 # do not recurse in to a dir we are about to delete
 ifneq "$(MAKECMDGOALS)" "distclean"
 SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir
+SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir
 endif
 
 SUBDIRS-y += xenpmd
@@ -72,6 +73,7 @@ clean: subdirs-clean
 .PHONY: distclean
 distclean: subdirs-distclean
 	rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote
+	rm -rf qemu-xen-dir qemu-xen-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -93,6 +95,14 @@ qemu-xen-traditional-dir-find:
 		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
 
+qemu-xen-dir-find:
+	if test -d $(QEMU_UPSTREAM_URL) ; then \
+		mkdir -p qemu-xen-dir; \
+	else \
+		export GIT=$(GIT); \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir ; \
+	fi
+
 .PHONY: qemu-xen-traditional-dir-force-update
 qemu-xen-traditional-dir-force-update:
 	set -ex; \
@@ -115,6 +125,40 @@ subdir-clean-qemu-xen-traditional-dir:
 		$(MAKE) -C qemu-xen-traditional-dir clean; \
 	fi
 
+.PHONY: qemu-xen-dir-force-update
+qemu-xen-dir-force-update:
+	set -ex; \
+	if [ "$(QEMU_UPSTREAM_TAG)" ]; then \
+		cd qemu-xen-dir-remote; \
+		$(GIT) fetch origin; \
+		$(GIT) reset --hard $(QEMU_UPSTREAM_TAG); \
+	fi
+
+subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find
+	if test -d $(QEMU_UPSTREAM_URL) ; then \
+		source=$(QEMU_UPSTREAM_URL); \
+	else \
+		source=.; \
+	fi; \
+	cd qemu-xen-dir; \
+	$$source/configure --enable-xen --target-list=i386-softmmu \
+		--source-path=$$source \
+		--extra-cflags="-I$(XEN_ROOT)/tools/include \
+		-I$(XEN_ROOT)/tools/libxc \
+		-I$(XEN_ROOT)/tools/xenstore" \
+		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
+		-L$(XEN_ROOT)/tools/xenstore" \
+		--bindir=$(LIBEXEC) \
+		--disable-kvm \
+		$(IOEMU_CONFIGURE_CROSS); \
+	$(MAKE) install
+
+subdir-clean-qemu-xen-dir:
+	set -e; if test -d qemu-xen-dir/.; then \
+		$(buildmakevars2shellvars); \
+		$(MAKE) -C qemu-xen-dir clean; \
+	fi
+
 subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
 	$(MAKE) -C debugger/gdbsx clean
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEf-0004Wj-KG; Wed, 23 Nov 2011 13:51:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEe-0004VS-HH
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322056264!4297346!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1361 invoked from network); 23 Nov 2011 13:51:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="171669552"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:05 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAW023713;
	Wed, 23 Nov 2011 05:51:04 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:58 +0000
Message-ID: <1322056320-5826-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 4/6] Clone and build upstream Qemu by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore      |    2 ++
 Config.mk      |    7 +++++++
 Makefile       |    9 ++++++++-
 tools/Makefile |   44 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 61 insertions(+), 1 deletions(-)

diff --git a/.hgignore b/.hgignore
index c1486a6..efbb5ed 100644
--- a/.hgignore
+++ b/.hgignore
@@ -297,6 +297,8 @@
 ^tools/xm-test/tests/.*\.test$
 ^tools/qemu-xen-traditional-dir-remote
 ^tools/qemu-xen-traditional-dir$
+^tools/qemu-xen-dir-remote
+^tools/qemu-xen-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Config.mk b/Config.mk
index b2c6ba2..e72324f 100644
--- a/Config.mk
+++ b/Config.mk
@@ -203,6 +203,13 @@ else
 QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git
 endif
 
+ifeq ($(GIT_HTTP),y)
+QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
+else
+QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git
+endif
+QEMU_UPSTREAM_TAG ?= 30f93db54875e1f2836e1f3d21672c33191f883f
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/Makefile b/Makefile
index c0197a5..edc5e3d 100644
--- a/Makefile
+++ b/Makefile
@@ -70,7 +70,7 @@ install-tools:
 	$(MAKE) -C tools install
 
 ifeq ($(CONFIG_IOEMU),y)
-install-tools: tools/qemu-xen-traditional-dir
+install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir
 endif
 
 .PHONY: install-kernels
@@ -91,6 +91,13 @@ tools/qemu-xen-traditional-dir:
 tools/qemu-xen-traditional-dir-force-update:
 	$(MAKE) -C tools qemu-xen-traditional-dir-force-update
 
+tools/qemu-xen-dir:
+	$(MAKE) -C tools qemu-xen-dir-find
+
+.PHONY: tools/qemu-xen-dir-force-update
+tools/qemu-xen-dir-force-update:
+	$(MAKE) -C tools qemu-xen-dir-force-update
+
 .PHONY: install-docs
 install-docs:
 	sh ./docs/check_pkgs && $(MAKE) -C docs install || true
diff --git a/tools/Makefile b/tools/Makefile
index 20bee85..f9a07d2 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -32,6 +32,7 @@ SUBDIRS-y += libvchan
 # do not recurse in to a dir we are about to delete
 ifneq "$(MAKECMDGOALS)" "distclean"
 SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir
+SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir
 endif
 
 SUBDIRS-y += xenpmd
@@ -72,6 +73,7 @@ clean: subdirs-clean
 .PHONY: distclean
 distclean: subdirs-distclean
 	rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote
+	rm -rf qemu-xen-dir qemu-xen-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -93,6 +95,14 @@ qemu-xen-traditional-dir-find:
 		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
 
+qemu-xen-dir-find:
+	if test -d $(QEMU_UPSTREAM_URL) ; then \
+		mkdir -p qemu-xen-dir; \
+	else \
+		export GIT=$(GIT); \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_TAG) qemu-xen-dir ; \
+	fi
+
 .PHONY: qemu-xen-traditional-dir-force-update
 qemu-xen-traditional-dir-force-update:
 	set -ex; \
@@ -115,6 +125,40 @@ subdir-clean-qemu-xen-traditional-dir:
 		$(MAKE) -C qemu-xen-traditional-dir clean; \
 	fi
 
+.PHONY: qemu-xen-dir-force-update
+qemu-xen-dir-force-update:
+	set -ex; \
+	if [ "$(QEMU_UPSTREAM_TAG)" ]; then \
+		cd qemu-xen-dir-remote; \
+		$(GIT) fetch origin; \
+		$(GIT) reset --hard $(QEMU_UPSTREAM_TAG); \
+	fi
+
+subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find
+	if test -d $(QEMU_UPSTREAM_URL) ; then \
+		source=$(QEMU_UPSTREAM_URL); \
+	else \
+		source=.; \
+	fi; \
+	cd qemu-xen-dir; \
+	$$source/configure --enable-xen --target-list=i386-softmmu \
+		--source-path=$$source \
+		--extra-cflags="-I$(XEN_ROOT)/tools/include \
+		-I$(XEN_ROOT)/tools/libxc \
+		-I$(XEN_ROOT)/tools/xenstore" \
+		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
+		-L$(XEN_ROOT)/tools/xenstore" \
+		--bindir=$(LIBEXEC) \
+		--disable-kvm \
+		$(IOEMU_CONFIGURE_CROSS); \
+	$(MAKE) install
+
+subdir-clean-qemu-xen-dir:
+	set -e; if test -d qemu-xen-dir/.; then \
+		$(buildmakevars2shellvars); \
+		$(MAKE) -C qemu-xen-dir clean; \
+	fi
+
 subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
 	$(MAKE) -C debugger/gdbsx clean
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEh-0004XK-9w; Wed, 23 Nov 2011 13:51:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEf-0004VX-OX
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322056262!4295953!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12288 invoked from network); 23 Nov 2011 13:51:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="19355117"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:07 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAX023713;
	Wed, 23 Nov 2011 05:51:05 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:59 +0000
Message-ID: <1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore                         |    2 +
 Config.mk                         |   12 ++-----
 Makefile                          |    4 ++
 tools/firmware/Makefile           |   21 ++++++++++-
 tools/firmware/hvmloader/Makefile |    1 +
 tools/firmware/seabios-config     |   73 +++++++++++++++++++++++++++++++++++++
 6 files changed, 102 insertions(+), 11 deletions(-)
 create mode 100644 tools/firmware/seabios-config

diff --git a/.hgignore b/.hgignore
index efbb5ed..c2023ec 100644
--- a/.hgignore
+++ b/.hgignore
@@ -299,6 +299,8 @@
 ^tools/qemu-xen-traditional-dir$
 ^tools/qemu-xen-dir-remote
 ^tools/qemu-xen-dir$
+^tools/firmware/seabios-dir-remote
+^tools/firmware/seabios-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Config.mk b/Config.mk
index e72324f..30e0ab5 100644
--- a/Config.mk
+++ b/Config.mk
@@ -205,10 +205,13 @@ endif
 
 ifeq ($(GIT_HTTP),y)
 QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
+SEABIOS_UPSTREAM_URL ?= http://git.qemu.org/git/seabios.git
 else
 QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git
+SEABIOS_UPSTREAM_URL ?= git://git.qemu.org/seabios.git
 endif
 QEMU_UPSTREAM_TAG ?= 30f93db54875e1f2836e1f3d21672c33191f883f
+SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560
 
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
@@ -222,15 +225,6 @@ QEMU_TAG ?= 52834188eedfbbca5636fd869d4c86b3b3044439
 # Short answer -- do not enable this unless you know what you are
 # doing and are prepared for some pain.
 
-# SeaBIOS integration is a work in progress. Before enabling this
-# option you must clone git://git.qemu.org/seabios.git/, possibly add
-# some development patches and then build it yourself before pointing
-# this variable to it (using an absolute path).
-#
-# Note that using SeaBIOS requires the use the upstream qemu as the
-# device model.
-SEABIOS_DIR ?= 
-
 # Optional components
 XENSTAT_XENTOP     ?= y
 VTPM_TOOLS         ?= n
diff --git a/Makefile b/Makefile
index edc5e3d..8edea0d 100644
--- a/Makefile
+++ b/Makefile
@@ -98,6 +98,10 @@ tools/qemu-xen-dir:
 tools/qemu-xen-dir-force-update:
 	$(MAKE) -C tools qemu-xen-dir-force-update
 
+.PHONY: tools/firmware/seabios-dir-force-update
+tools/firmware/seabios-dir-force-update:
+	$(MAKE) -C tools/firmware seabios-dir-force-update
+
 .PHONY: install-docs
 install-docs:
 	sh ./docs/check_pkgs && $(MAKE) -C docs install || true
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 4b6d144..c3ec9a0 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -6,13 +6,18 @@ TARGET      := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
 SUBDIRS :=
+SUBDIRS += seabios-dir
 SUBDIRS += rombios
 SUBDIRS += vgabios
 SUBDIRS += etherboot
 SUBDIRS += hvmloader
 
+seabios-dir:
+	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
+	cp seabios-config seabios-dir/.config;
+
 .PHONY: all
-all:
+all: seabios-dir
 	@set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \
 	echo "==========================================================================="; \
 	echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \
@@ -35,4 +40,16 @@ clean: subdirs-clean
 distclean: subdirs-distclean
 
 subdir-distclean-etherboot: .phony
-	$(MAKE) -C etherboot distclean
\ No newline at end of file
+	$(MAKE) -C etherboot distclean
+
+subdir-distclean-seabios-dir: .phony
+	rm -rf seabios-dir seabios-dir-remote
+
+.PHONY: seabios-dir-force-update
+seabios-dir-force-update:
+	set -ex; \
+	if [ "$(SEABIOS_UPSTREAM_TAG)" ]; then \
+		cd seabios-dir-remote; \
+		$(GIT) fetch origin; \
+		$(GIT) reset --hard $(SEABIOS_UPSTREAM_TAG); \
+	fi
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 11e8f1c..ae8a1e2 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
 
+SEABIOS_DIR := ../seabios-dir
 ifneq ($(SEABIOS_DIR),)
 OBJS += seabios.o
 CFLAGS += -DENABLE_SEABIOS
diff --git a/tools/firmware/seabios-config b/tools/firmware/seabios-config
new file mode 100644
index 0000000..202d15f
--- /dev/null
+++ b/tools/firmware/seabios-config
@@ -0,0 +1,73 @@
+#
+# Automatically generated make config: don't edit
+# SeaBIOS Configuration
+# Wed Sep  7 13:03:21 2011
+#
+
+#
+# General Features
+#
+# CONFIG_COREBOOT is not set
+CONFIG_XEN=y
+CONFIG_THREADS=y
+# CONFIG_THREAD_OPTIONROMS is not set
+CONFIG_RELOCATE_INIT=y
+CONFIG_BOOTMENU=y
+# CONFIG_BOOTSPLASH is not set
+CONFIG_BOOTORDER=y
+
+#
+# Hardware support
+#
+CONFIG_ATA=y
+CONFIG_ATA_DMA=y
+CONFIG_ATA_PIO32=y
+CONFIG_AHCI=y
+CONFIG_VIRTIO_BLK=y
+CONFIG_FLOPPY=y
+CONFIG_PS2PORT=y
+CONFIG_USB=y
+CONFIG_USB_UHCI=y
+CONFIG_USB_OHCI=y
+CONFIG_USB_EHCI=y
+CONFIG_USB_MSC=y
+CONFIG_USB_HUB=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_USB_MOUSE=y
+CONFIG_SERIAL=y
+CONFIG_LPT=y
+# CONFIG_USE_SMM is not set
+CONFIG_MTRR_INIT=y
+
+#
+# BIOS interfaces
+#
+CONFIG_DRIVES=y
+CONFIG_CDROM_BOOT=y
+CONFIG_CDROM_EMU=y
+CONFIG_PCIBIOS=y
+CONFIG_APMBIOS=y
+CONFIG_PNPBIOS=y
+CONFIG_OPTIONROMS=y
+# CONFIG_OPTIONROMS_DEPLOYED is not set
+CONFIG_PMM=y
+CONFIG_BOOT=y
+CONFIG_KEYBOARD=y
+CONFIG_KBD_CALL_INT15_4F=y
+CONFIG_MOUSE=y
+CONFIG_S3_RESUME=y
+# CONFIG_DISABLE_A20 is not set
+
+#
+# BIOS Tables
+#
+CONFIG_PIRTABLE=y
+CONFIG_MPTABLE=y
+CONFIG_SMBIOS=y
+CONFIG_ACPI=y
+
+#
+# Debugging
+#
+CONFIG_DEBUG_LEVEL=1
+# CONFIG_DEBUG_SERIAL is not set
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEh-0004XK-9w; Wed, 23 Nov 2011 13:51:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEf-0004VX-OX
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322056262!4295953!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12288 invoked from network); 23 Nov 2011 13:51:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="19355117"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:07 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAX023713;
	Wed, 23 Nov 2011 05:51:05 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:59 +0000
Message-ID: <1322056320-5826-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore                         |    2 +
 Config.mk                         |   12 ++-----
 Makefile                          |    4 ++
 tools/firmware/Makefile           |   21 ++++++++++-
 tools/firmware/hvmloader/Makefile |    1 +
 tools/firmware/seabios-config     |   73 +++++++++++++++++++++++++++++++++++++
 6 files changed, 102 insertions(+), 11 deletions(-)
 create mode 100644 tools/firmware/seabios-config

diff --git a/.hgignore b/.hgignore
index efbb5ed..c2023ec 100644
--- a/.hgignore
+++ b/.hgignore
@@ -299,6 +299,8 @@
 ^tools/qemu-xen-traditional-dir$
 ^tools/qemu-xen-dir-remote
 ^tools/qemu-xen-dir$
+^tools/firmware/seabios-dir-remote
+^tools/firmware/seabios-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Config.mk b/Config.mk
index e72324f..30e0ab5 100644
--- a/Config.mk
+++ b/Config.mk
@@ -205,10 +205,13 @@ endif
 
 ifeq ($(GIT_HTTP),y)
 QEMU_UPSTREAM_URL ?= http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
+SEABIOS_UPSTREAM_URL ?= http://git.qemu.org/git/seabios.git
 else
 QEMU_UPSTREAM_URL ?= git://xenbits.xensource.com/qemu-upstream-unstable.git
+SEABIOS_UPSTREAM_URL ?= git://git.qemu.org/seabios.git
 endif
 QEMU_UPSTREAM_TAG ?= 30f93db54875e1f2836e1f3d21672c33191f883f
+SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560
 
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
@@ -222,15 +225,6 @@ QEMU_TAG ?= 52834188eedfbbca5636fd869d4c86b3b3044439
 # Short answer -- do not enable this unless you know what you are
 # doing and are prepared for some pain.
 
-# SeaBIOS integration is a work in progress. Before enabling this
-# option you must clone git://git.qemu.org/seabios.git/, possibly add
-# some development patches and then build it yourself before pointing
-# this variable to it (using an absolute path).
-#
-# Note that using SeaBIOS requires the use the upstream qemu as the
-# device model.
-SEABIOS_DIR ?= 
-
 # Optional components
 XENSTAT_XENTOP     ?= y
 VTPM_TOOLS         ?= n
diff --git a/Makefile b/Makefile
index edc5e3d..8edea0d 100644
--- a/Makefile
+++ b/Makefile
@@ -98,6 +98,10 @@ tools/qemu-xen-dir:
 tools/qemu-xen-dir-force-update:
 	$(MAKE) -C tools qemu-xen-dir-force-update
 
+.PHONY: tools/firmware/seabios-dir-force-update
+tools/firmware/seabios-dir-force-update:
+	$(MAKE) -C tools/firmware seabios-dir-force-update
+
 .PHONY: install-docs
 install-docs:
 	sh ./docs/check_pkgs && $(MAKE) -C docs install || true
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 4b6d144..c3ec9a0 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -6,13 +6,18 @@ TARGET      := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
 SUBDIRS :=
+SUBDIRS += seabios-dir
 SUBDIRS += rombios
 SUBDIRS += vgabios
 SUBDIRS += etherboot
 SUBDIRS += hvmloader
 
+seabios-dir:
+	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
+	cp seabios-config seabios-dir/.config;
+
 .PHONY: all
-all:
+all: seabios-dir
 	@set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \
 	echo "==========================================================================="; \
 	echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \
@@ -35,4 +40,16 @@ clean: subdirs-clean
 distclean: subdirs-distclean
 
 subdir-distclean-etherboot: .phony
-	$(MAKE) -C etherboot distclean
\ No newline at end of file
+	$(MAKE) -C etherboot distclean
+
+subdir-distclean-seabios-dir: .phony
+	rm -rf seabios-dir seabios-dir-remote
+
+.PHONY: seabios-dir-force-update
+seabios-dir-force-update:
+	set -ex; \
+	if [ "$(SEABIOS_UPSTREAM_TAG)" ]; then \
+		cd seabios-dir-remote; \
+		$(GIT) fetch origin; \
+		$(GIT) reset --hard $(SEABIOS_UPSTREAM_TAG); \
+	fi
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index 11e8f1c..ae8a1e2 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
 
+SEABIOS_DIR := ../seabios-dir
 ifneq ($(SEABIOS_DIR),)
 OBJS += seabios.o
 CFLAGS += -DENABLE_SEABIOS
diff --git a/tools/firmware/seabios-config b/tools/firmware/seabios-config
new file mode 100644
index 0000000..202d15f
--- /dev/null
+++ b/tools/firmware/seabios-config
@@ -0,0 +1,73 @@
+#
+# Automatically generated make config: don't edit
+# SeaBIOS Configuration
+# Wed Sep  7 13:03:21 2011
+#
+
+#
+# General Features
+#
+# CONFIG_COREBOOT is not set
+CONFIG_XEN=y
+CONFIG_THREADS=y
+# CONFIG_THREAD_OPTIONROMS is not set
+CONFIG_RELOCATE_INIT=y
+CONFIG_BOOTMENU=y
+# CONFIG_BOOTSPLASH is not set
+CONFIG_BOOTORDER=y
+
+#
+# Hardware support
+#
+CONFIG_ATA=y
+CONFIG_ATA_DMA=y
+CONFIG_ATA_PIO32=y
+CONFIG_AHCI=y
+CONFIG_VIRTIO_BLK=y
+CONFIG_FLOPPY=y
+CONFIG_PS2PORT=y
+CONFIG_USB=y
+CONFIG_USB_UHCI=y
+CONFIG_USB_OHCI=y
+CONFIG_USB_EHCI=y
+CONFIG_USB_MSC=y
+CONFIG_USB_HUB=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_USB_MOUSE=y
+CONFIG_SERIAL=y
+CONFIG_LPT=y
+# CONFIG_USE_SMM is not set
+CONFIG_MTRR_INIT=y
+
+#
+# BIOS interfaces
+#
+CONFIG_DRIVES=y
+CONFIG_CDROM_BOOT=y
+CONFIG_CDROM_EMU=y
+CONFIG_PCIBIOS=y
+CONFIG_APMBIOS=y
+CONFIG_PNPBIOS=y
+CONFIG_OPTIONROMS=y
+# CONFIG_OPTIONROMS_DEPLOYED is not set
+CONFIG_PMM=y
+CONFIG_BOOT=y
+CONFIG_KEYBOARD=y
+CONFIG_KBD_CALL_INT15_4F=y
+CONFIG_MOUSE=y
+CONFIG_S3_RESUME=y
+# CONFIG_DISABLE_A20 is not set
+
+#
+# BIOS Tables
+#
+CONFIG_PIRTABLE=y
+CONFIG_MPTABLE=y
+CONFIG_SMBIOS=y
+CONFIG_ACPI=y
+
+#
+# Debugging
+#
+CONFIG_DEBUG_LEVEL=1
+# CONFIG_DEBUG_SERIAL is not set
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEe-0004WL-Nt; Wed, 23 Nov 2011 13:51:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEd-0004VO-08
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322056262!4295953!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12114 invoked from network); 23 Nov 2011 13:51:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="19355116"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:04 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAV023713;
	Wed, 23 Nov 2011 05:51:03 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:57 +0000
Message-ID: <1322056320-5826-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 3/6] move the call to xen-setup after libxc
	and xenstore are built
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Move the call to xen-setup, the wrapper script to configure
qemu-xen-traditional, right before building qemu-xen-traditional and
after libxc and xenstore are already built.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/Makefile |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index c19d3c9..20bee85 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -92,10 +92,6 @@ qemu-xen-traditional-dir-find:
 		export GIT=$(GIT); \
 		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
-	set -e; \
-		$(buildmakevars2shellvars); \
-		cd qemu-xen-traditional-dir; \
-		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS)
 
 .PHONY: qemu-xen-traditional-dir-force-update
 qemu-xen-traditional-dir-force-update:
@@ -107,6 +103,11 @@ qemu-xen-traditional-dir-force-update:
 	fi
 
 subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
+	set -e; \
+		$(buildmakevars2shellvars); \
+		cd qemu-xen-traditional-dir; \
+		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
+		$(MAKE) install
 
 subdir-clean-qemu-xen-traditional-dir:
 	set -e; if test -d qemu-xen-traditional-dir/.; then \
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEe-0004WL-Nt; Wed, 23 Nov 2011 13:51:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEd-0004VO-08
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322056262!4295953!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12114 invoked from network); 23 Nov 2011 13:51:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="19355116"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:04 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAV023713;
	Wed, 23 Nov 2011 05:51:03 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:57 +0000
Message-ID: <1322056320-5826-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 3/6] move the call to xen-setup after libxc
	and xenstore are built
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Move the call to xen-setup, the wrapper script to configure
qemu-xen-traditional, right before building qemu-xen-traditional and
after libxc and xenstore are already built.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/Makefile |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index c19d3c9..20bee85 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -92,10 +92,6 @@ qemu-xen-traditional-dir-find:
 		export GIT=$(GIT); \
 		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
-	set -e; \
-		$(buildmakevars2shellvars); \
-		cd qemu-xen-traditional-dir; \
-		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS)
 
 .PHONY: qemu-xen-traditional-dir-force-update
 qemu-xen-traditional-dir-force-update:
@@ -107,6 +103,11 @@ qemu-xen-traditional-dir-force-update:
 	fi
 
 subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
+	set -e; \
+		$(buildmakevars2shellvars); \
+		cd qemu-xen-traditional-dir; \
+		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
+		$(MAKE) install
 
 subdir-clean-qemu-xen-traditional-dir:
 	set -e; if test -d qemu-xen-traditional-dir/.; then \
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEd-0004W1-Am; Wed, 23 Nov 2011 13:51:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEb-0004VJ-FH
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322056262!4295953!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12048 invoked from network); 23 Nov 2011 13:51:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="19355113"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:01 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAT023713;
	Wed, 23 Nov 2011 05:51:00 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:55 +0000
Message-ID: <1322056320-5826-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 1/6] Introduce git-checkout.sh
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Introduce a script to perform git checkout on an external git tree; use
git-checkout.sh in ioemu-dir-find.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore               |    2 +-
 scripts/git-checkout.sh |   27 +++++++++++++++++++++++++++
 tools/Makefile          |   20 ++++----------------
 3 files changed, 32 insertions(+), 17 deletions(-)
 create mode 100755 scripts/git-checkout.sh

diff --git a/.hgignore b/.hgignore
index e62fb2d..067d83d 100644
--- a/.hgignore
+++ b/.hgignore
@@ -295,7 +295,7 @@
 ^tools/xm-test/lib/XmTestLib/config.py$
 ^tools/xm-test/lib/XmTestReport/xmtest.py$
 ^tools/xm-test/tests/.*\.test$
-^tools/ioemu-remote
+^tools/ioemu-dir-remote
 ^tools/ioemu-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh
new file mode 100755
index 0000000..15b3ce9
--- /dev/null
+++ b/scripts/git-checkout.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+if test $# -lt 3; then
+	echo "Usage: $0 <tree> <tag> <dir>"
+	exit 1
+fi
+
+TREE=$1
+TAG=$2
+DIR=$3
+
+set -e
+
+if test \! -d $DIR-remote; then
+	rm -rf $DIR-remote $DIR-remote.tmp
+	mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp
+	$GIT clone $TREE $DIR-remote.tmp
+	if test "$TAG" ; then
+		cd $DIR-remote.tmp
+		$GIT branch -D dummy >/dev/null 2>&1 ||:
+		$GIT checkout -b dummy $TAG
+		cd ..
+	fi
+	mv $DIR-remote.tmp $DIR-remote
+fi
+rm -f $DIR
+ln -sf $DIR-remote $DIR
diff --git a/tools/Makefile b/tools/Makefile
index 9389e1f..beccad2 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -71,7 +71,7 @@ clean: subdirs-clean
 
 .PHONY: distclean
 distclean: subdirs-distclean
-	rm -rf ioemu-dir ioemu-remote
+	rm -rf ioemu-dir ioemu-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -89,20 +89,8 @@ ioemu-dir-find:
 	if test -d $(CONFIG_QEMU); then \
 		mkdir -p ioemu-dir; \
 	else \
-		if [ ! -d ioemu-remote ]; then \
-			rm -rf ioemu-remote ioemu-remote.tmp; \
-			mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \
-			$(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \
-			if [ "$(QEMU_TAG)" ]; then			\
-				cd ioemu-remote.tmp;			\
-				$(GIT) branch -D dummy >/dev/null 2>&1 ||:; \
-				$(GIT) checkout -b dummy $(QEMU_TAG);	\
-				cd ..;					\
-			fi;						\
-			mv ioemu-remote.tmp ioemu-remote; \
-		fi; \
-		rm -f ioemu-dir; \
-		ln -sf ioemu-remote ioemu-dir; \
+		export GIT=$(GIT); \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \
 	fi
 	set -e; \
 		$(buildmakevars2shellvars); \
@@ -113,7 +101,7 @@ ioemu-dir-find:
 ioemu-dir-force-update:
 	set -ex; \
 	if [ "$(QEMU_TAG)" ]; then \
-		cd ioemu-remote; \
+		cd ioemu-dir-remote; \
 		$(GIT) fetch origin; \
 		$(GIT) reset --hard $(QEMU_TAG); \
 	fi
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEd-0004W1-Am; Wed, 23 Nov 2011 13:51:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEb-0004VJ-FH
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322056262!4295953!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12048 invoked from network); 23 Nov 2011 13:51:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="19355113"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:01 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAT023713;
	Wed, 23 Nov 2011 05:51:00 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:55 +0000
Message-ID: <1322056320-5826-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v9 1/6] Introduce git-checkout.sh
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Introduce a script to perform git checkout on an external git tree; use
git-checkout.sh in ioemu-dir-find.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore               |    2 +-
 scripts/git-checkout.sh |   27 +++++++++++++++++++++++++++
 tools/Makefile          |   20 ++++----------------
 3 files changed, 32 insertions(+), 17 deletions(-)
 create mode 100755 scripts/git-checkout.sh

diff --git a/.hgignore b/.hgignore
index e62fb2d..067d83d 100644
--- a/.hgignore
+++ b/.hgignore
@@ -295,7 +295,7 @@
 ^tools/xm-test/lib/XmTestLib/config.py$
 ^tools/xm-test/lib/XmTestReport/xmtest.py$
 ^tools/xm-test/tests/.*\.test$
-^tools/ioemu-remote
+^tools/ioemu-dir-remote
 ^tools/ioemu-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh
new file mode 100755
index 0000000..15b3ce9
--- /dev/null
+++ b/scripts/git-checkout.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+if test $# -lt 3; then
+	echo "Usage: $0 <tree> <tag> <dir>"
+	exit 1
+fi
+
+TREE=$1
+TAG=$2
+DIR=$3
+
+set -e
+
+if test \! -d $DIR-remote; then
+	rm -rf $DIR-remote $DIR-remote.tmp
+	mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp
+	$GIT clone $TREE $DIR-remote.tmp
+	if test "$TAG" ; then
+		cd $DIR-remote.tmp
+		$GIT branch -D dummy >/dev/null 2>&1 ||:
+		$GIT checkout -b dummy $TAG
+		cd ..
+	fi
+	mv $DIR-remote.tmp $DIR-remote
+fi
+rm -f $DIR
+ln -sf $DIR-remote $DIR
diff --git a/tools/Makefile b/tools/Makefile
index 9389e1f..beccad2 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -71,7 +71,7 @@ clean: subdirs-clean
 
 .PHONY: distclean
 distclean: subdirs-distclean
-	rm -rf ioemu-dir ioemu-remote
+	rm -rf ioemu-dir ioemu-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -89,20 +89,8 @@ ioemu-dir-find:
 	if test -d $(CONFIG_QEMU); then \
 		mkdir -p ioemu-dir; \
 	else \
-		if [ ! -d ioemu-remote ]; then \
-			rm -rf ioemu-remote ioemu-remote.tmp; \
-			mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \
-			$(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \
-			if [ "$(QEMU_TAG)" ]; then			\
-				cd ioemu-remote.tmp;			\
-				$(GIT) branch -D dummy >/dev/null 2>&1 ||:; \
-				$(GIT) checkout -b dummy $(QEMU_TAG);	\
-				cd ..;					\
-			fi;						\
-			mv ioemu-remote.tmp ioemu-remote; \
-		fi; \
-		rm -f ioemu-dir; \
-		ln -sf ioemu-remote ioemu-dir; \
+		export GIT=$(GIT); \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \
 	fi
 	set -e; \
 		$(buildmakevars2shellvars); \
@@ -113,7 +101,7 @@ ioemu-dir-find:
 ioemu-dir-force-update:
 	set -ex; \
 	if [ "$(QEMU_TAG)" ]; then \
-		cd ioemu-remote; \
+		cd ioemu-dir-remote; \
 		$(GIT) fetch origin; \
 		$(GIT) reset --hard $(QEMU_TAG); \
 	fi
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEo-0004Zo-QW; Wed, 23 Nov 2011 13:51:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEn-0004Xe-Gs
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322056273!2729928!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30068 invoked from network); 23 Nov 2011 13:51:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="171669570"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:13 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAY023713;
	Wed, 23 Nov 2011 05:51:07 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:52:00 +0000
Message-ID: <1322056320-5826-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v9 6/6] libxl: use new qemu at the location
	where xen-unstable installs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bf38877..633123f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -55,7 +55,7 @@ const char *libxl__domain_device_model(libxl__gc *gc,
             dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
             break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            dm = libxl__strdup(gc, "/usr/bin/qemu");
+            dm = libxl__abs_path(gc, "qemu", libxl_libexec_path());
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:51:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDEo-0004Zo-QW; Wed, 23 Nov 2011 13:51:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDEn-0004Xe-Gs
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:51:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322056273!2729928!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30068 invoked from network); 23 Nov 2011 13:51:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:51:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315195200"; d="scan'208";a="171669570"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 08:51:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 08:51:13 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pANDoxAY023713;
	Wed, 23 Nov 2011 05:51:07 -0800
From: <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:52:00 +0000
Message-ID: <1322056320-5826-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
MIME-Version: 1.0
Cc: keir@xen.org, Ian.Jackson@eu.citrix.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v9 6/6] libxl: use new qemu at the location
	where xen-unstable installs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bf38877..633123f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -55,7 +55,7 @@ const char *libxl__domain_device_model(libxl__gc *gc,
             dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
             break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            dm = libxl__strdup(gc, "/usr/bin/qemu");
+            dm = libxl__abs_path(gc, "qemu", libxl_libexec_path());
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:52:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDFs-0004uq-6p; Wed, 23 Nov 2011 13:52:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTDFq-0004sk-1Z
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:52:50 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322056339!4683660!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23893 invoked from network); 23 Nov 2011 13:52:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:52:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:52:14 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTDFF-0005C0-Pk;
	Wed, 23 Nov 2011 13:52:13 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTDF2-00058n-Bn;
	Wed, 23 Nov 2011 13:52:00 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 13:51:59 +0000
Message-ID: <1322056319-19725-3-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
In-Reply-To: <1322056319-19725-2-git-send-email-jean.guyader@eu.citrix.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
	<1322056319-19725-2-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: allen.m.kay@intel.com, Ian.Jackson@eu.citrix.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] qemu-xen: passthrough, add PT_LOG_DEV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |   97 +++++++++++++++++++----------------------------------
 hw/pass-through.h |    5 +++
 hw/pt-graphics.c  |   14 ++++---
 3 files changed, 48 insertions(+), 68 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0003-qemu-xen-passthrough-add-PT_LOG_DEV.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0003-qemu-xen-passthrough-add-PT_LOG_DEV.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index bd46b2d..919937f 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -1475,37 +1475,30 @@ static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
     int ret = 0;
 
 #ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-    PT_LOG("[%02x:%02x.%x]: address=%04x val=0x%08x len=%d\n",
-       pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-       address, val, len);
+    PT_LOG_DEV(d, "address=%04x val=0x%08x len=%d\n", address, val, len);
 #endif
 
     /* check offset range */
     if (address >= 0xFF)
     {
-        PT_LOG("Error: Failed to write register with offset exceeding FFh. "
-            "[%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Error: Failed to write register with offset exceeding FFh. "
+            "[Offset:%02xh][Length:%d]\n", address, len);
         goto exit;
     }
 
     /* check write size */
     if ((len != 1) && (len != 2) && (len != 4))
     {
-        PT_LOG("Error: Failed to write register with invalid access length. "
-            "[%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Error: Failed to write register with invalid access length. "
+            "[Offset:%02xh][Length:%d]\n", address, len);
         goto exit;
     }
 
     /* check offset alignment */
     if (address & (len-1))
     {
-        PT_LOG("Error: Failed to write register with invalid access size "
-            "alignment. [%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+        PT_LOG_DEV(d, "Error: Failed to write register with invalid access size "
+            "alignment. [Offset:%02xh][Length:%d]\n",
             address, len);
         goto exit;
     }
@@ -1515,10 +1508,8 @@ static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
     if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
         (assigned_device->bases[index].bar_flag == PT_BAR_FLAG_UNUSED))
     {
-        PT_LOG("Warning: Guest attempt to set address to unused Base Address "
-            "Register. [%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Warning: Guest attempt to set address to unused Base Address "
+            "Register. [Offset:%02xh][Length:%d]\n", address, len);
     }
 
     /* check power state transition flags */
@@ -1537,10 +1528,8 @@ static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
         if (reg_grp->grp_type == GRP_TYPE_HARDWIRED)
         {
             /* ignore silently */
-            PT_LOG("Warning: Access to 0 Hardwired register. "
-                "[%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-                pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-                address, len);
+            PT_LOG_DEV(d, "Warning: Access to 0 Hardwired register. "
+                "[Offset:%02xh][Length:%d]\n", address, len);
             goto exit;
         }
     }
@@ -1668,30 +1657,24 @@ static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
     /* check offset range */
     if (address >= 0xFF)
     {
-        PT_LOG("Error: Failed to read register with offset exceeding FFh. "
-            "[%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Error: Failed to read register with offset exceeding FFh. "
+            "[Offset:%02xh][Length:%d]\n", address, len);
         goto exit;
     }
 
     /* check read size */
     if ((len != 1) && (len != 2) && (len != 4))
     {
-        PT_LOG("Error: Failed to read register with invalid access length. "
-            "[%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Error: Failed to read register with invalid access length. "
+            "[Offset:%02xh][Length:%d]\n", address, len);
         goto exit;
     }
 
     /* check offset alignment */
     if (address & (len-1))
     {
-        PT_LOG("Error: Failed to read register with invalid access size "
-            "alignment. [%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Error: Failed to read register with invalid access size "
+            "alignment. [Offset:%02xh][Length:%d]\n", address, len);
         goto exit;
     }
 
@@ -1803,9 +1786,7 @@ static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
 exit:
 
 #ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-    PT_LOG("[%02x:%02x.%x]: address=%04x val=0x%08x len=%d\n",
-       pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-       address, val, len);
+    PT_LOG_DEV(d, "address=%04x val=0x%08x len=%d\n", address, val, len);
 #endif
 
     return val;
@@ -2181,9 +2162,8 @@ static void pt_bar_mapping_one(struct pt_dev *ptdev, int bar, int io_enable,
     ret = pt_chk_bar_overlap(dev->bus, dev->devfn,
                     r_addr, r_size, r->type);
     if (ret > 0)
-        PT_LOG("Warning: ptdev[%02x:%02x.%x][Region:%d][Address:%08xh]"
-            "[Size:%08xh] is overlapped.\n", pci_bus_num(dev->bus),
-            PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn), bar, r_addr, r_size);
+        PT_LOG_DEV(dev, "Warning: [Region:%d][Address:%08xh]"
+            "[Size:%08xh] is overlapped.\n", bar, r_addr, r_size);
 
     /* check whether we need to update the mapping or not */
     if (r_addr != ptdev->bases[bar].e_physbase)
@@ -2217,9 +2197,8 @@ static int check_power_state(struct pt_dev *ptdev)
 
     if (pm_state->req_state != cur_state)
     {
-        PT_LOG("Error: Failed to change power state. "
-            "[%02x:%02x.%x][requested state:%d][current state:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+        PT_LOG_DEV(d, "Error: Failed to change power state. "
+            "[requested state:%d][current state:%d]\n",
             pm_state->req_state, cur_state);
         return -1;
     }
@@ -2379,9 +2358,8 @@ static void pt_config_restore(struct pt_dev *ptdev)
             }
 
 #ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG("[%02x:%02x.%x]: address=%04x val=0x%08x len=%d\n",
-                pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-                real_offset, val, reg->size);
+            PT_LOG_DEV(d, "address=%04x val=0x%08x len=%d\n",
+                    real_offset, val, reg->size);
 #endif
 
             ret = pci_write_block(ptdev->pci_dev, real_offset,
@@ -2426,9 +2404,8 @@ static int pt_init_pci_config(struct pt_dev *ptdev)
     PCIDevice *d = &ptdev->dev;
     int ret = 0;
 
-    PT_LOG("Reinitialize PCI configuration registers "
-        "due to power state transition with internal reset. [%02x:%02x.%x]\n",
-        pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    PT_LOG_DEV(d, "Reinitialize PCI configuration registers "
+        "due to power state transition with internal reset.\n");
 
     /* restore a part of I/O device register */
     pt_config_restore(ptdev);
@@ -3493,10 +3470,9 @@ static int pt_bar_reg_write(struct pt_dev *ptdev,
             if ((last_addr >= 0x10000) &&
                 (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)))
             {
-                PT_LOG("Warning: Guest attempt to set Base Address "
+                PT_LOG_DEV(d, "Warning: Guest attempt to set Base Address "
                     "over the 64KB. "
-                    "[%02x:%02x.%x][Offset:%02xh][Address:%08xh][Size:%08xh]\n",
-                    pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+                    "[Offset:%02xh][Address:%08xh][Size:%08xh]\n",
                     reg->offset, new_addr, r_size);
             }
             /* just remove mapping */
@@ -3509,11 +3485,10 @@ static int pt_bar_reg_write(struct pt_dev *ptdev,
         {
             if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask))
             {
-                PT_LOG("Warning: Guest attempt to set high MMIO Base Address. "
+                PT_LOG_DEV(d, "Warning: Guest attempt to set high MMIO Base Address. "
                     "Ignore mapping. "
-                    "[%02x:%02x.%x][Offset:%02xh][High Address:%08xh]\n",
-                    pci_bus_num(d->bus), PCI_SLOT(d->devfn),
-                    PCI_FUNC(d->devfn), reg->offset, cfg_entry->data);
+                    "[Offset:%02xh][High Address:%08xh]\n",
+                    reg->offset, cfg_entry->data);
             }
             /* clear lower address */
             d->io_regions[index-1].addr = -1;
@@ -3678,9 +3653,8 @@ static int pt_pmcsr_reg_write(struct pt_dev *ptdev,
     if ((pm_state->req_state != 0) &&
         (pm_state->cur_state > pm_state->req_state))
     {
-        PT_LOG("Error: Invalid power transition. "
-            "[%02x:%02x.%x][requested state:%d][current state:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+        PT_LOG_DEV(d, "Error: Invalid power transition. "
+            "[requested state:%d][current state:%d]\n",
             pm_state->req_state, pm_state->cur_state);
 
         return 0;
@@ -3691,9 +3665,8 @@ static int pt_pmcsr_reg_write(struct pt_dev *ptdev,
         || ((pm_state->req_state == 2) &&
         !(pm_state->pmc_field & PCI_PM_CAP_D2)))
     {
-        PT_LOG("Error: Invalid power transition. "
-            "[%02x:%02x.%x][requested state:%d][current state:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+        PT_LOG_DEV(d, "Error: Invalid power transition. "
+            "[requested state:%d][current state:%d]\n",
             pm_state->req_state, pm_state->cur_state);
 
         return 0;
diff --git a/hw/pass-through.h b/hw/pass-through.h
index bb31acd..884139c 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -31,8 +31,13 @@
 
 #ifdef PT_LOGGING_ENABLED
 #define PT_LOG(_f, _a...)   fprintf(logfile, "%s: " _f, __func__, ##_a)
+#define PT_LOG_DEV(_dev, _f, _a...)   fprintf(logfile, "%s: [%02x:%02x:%01x] " _f, __func__,    \
+                                              pci_bus_num((_dev)->bus),                         \
+                                              PCI_SLOT((_dev)->devfn),                          \
+                                              PCI_FUNC((_dev)->devfn), ##_a)
 #else
 #define PT_LOG(_f, _a...)
+#define PT_LOG_DEV(_dev, _f, _a...)
 #endif
 
 /* Some compilation flags */
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index 6a485ce..fec7390 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -50,9 +50,10 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
     {
         case 0x58:        // PAVPC Offset
             pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
-            PT_LOG("pci_config_write: %x:%x.%x: addr=%x len=%x val=%x\n",
-                   pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
-                   PCI_FUNC(pci_dev->devfn), config_addr, len, val);
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+                    config_addr, len, val);
+#endif
             break;
         default:
             pci_default_write_config(pci_dev, config_addr, val, len);
@@ -81,9 +82,10 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
             val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
-            PT_LOG("pci_config_read: %x:%x.%x: addr=%x len=%x val=%x\n",
-                   pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
-                   PCI_FUNC(pci_dev->devfn), config_addr, len, val);
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+                    config_addr, len, val);
+#endif
             break;
         default:
             val = pci_default_read_config(pci_dev, config_addr, len);

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:52:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDFs-0004uq-6p; Wed, 23 Nov 2011 13:52:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTDFq-0004sk-1Z
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:52:50 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322056339!4683660!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23893 invoked from network); 23 Nov 2011 13:52:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092356"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:52:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:52:14 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTDFF-0005C0-Pk;
	Wed, 23 Nov 2011 13:52:13 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTDF2-00058n-Bn;
	Wed, 23 Nov 2011 13:52:00 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 13:51:59 +0000
Message-ID: <1322056319-19725-3-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
In-Reply-To: <1322056319-19725-2-git-send-email-jean.guyader@eu.citrix.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
	<1322056319-19725-2-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: allen.m.kay@intel.com, Ian.Jackson@eu.citrix.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] qemu-xen: passthrough, add PT_LOG_DEV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |   97 +++++++++++++++++++----------------------------------
 hw/pass-through.h |    5 +++
 hw/pt-graphics.c  |   14 ++++---
 3 files changed, 48 insertions(+), 68 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0003-qemu-xen-passthrough-add-PT_LOG_DEV.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0003-qemu-xen-passthrough-add-PT_LOG_DEV.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index bd46b2d..919937f 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -1475,37 +1475,30 @@ static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
     int ret = 0;
 
 #ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-    PT_LOG("[%02x:%02x.%x]: address=%04x val=0x%08x len=%d\n",
-       pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-       address, val, len);
+    PT_LOG_DEV(d, "address=%04x val=0x%08x len=%d\n", address, val, len);
 #endif
 
     /* check offset range */
     if (address >= 0xFF)
     {
-        PT_LOG("Error: Failed to write register with offset exceeding FFh. "
-            "[%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Error: Failed to write register with offset exceeding FFh. "
+            "[Offset:%02xh][Length:%d]\n", address, len);
         goto exit;
     }
 
     /* check write size */
     if ((len != 1) && (len != 2) && (len != 4))
     {
-        PT_LOG("Error: Failed to write register with invalid access length. "
-            "[%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Error: Failed to write register with invalid access length. "
+            "[Offset:%02xh][Length:%d]\n", address, len);
         goto exit;
     }
 
     /* check offset alignment */
     if (address & (len-1))
     {
-        PT_LOG("Error: Failed to write register with invalid access size "
-            "alignment. [%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+        PT_LOG_DEV(d, "Error: Failed to write register with invalid access size "
+            "alignment. [Offset:%02xh][Length:%d]\n",
             address, len);
         goto exit;
     }
@@ -1515,10 +1508,8 @@ static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
     if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
         (assigned_device->bases[index].bar_flag == PT_BAR_FLAG_UNUSED))
     {
-        PT_LOG("Warning: Guest attempt to set address to unused Base Address "
-            "Register. [%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Warning: Guest attempt to set address to unused Base Address "
+            "Register. [Offset:%02xh][Length:%d]\n", address, len);
     }
 
     /* check power state transition flags */
@@ -1537,10 +1528,8 @@ static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
         if (reg_grp->grp_type == GRP_TYPE_HARDWIRED)
         {
             /* ignore silently */
-            PT_LOG("Warning: Access to 0 Hardwired register. "
-                "[%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-                pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-                address, len);
+            PT_LOG_DEV(d, "Warning: Access to 0 Hardwired register. "
+                "[Offset:%02xh][Length:%d]\n", address, len);
             goto exit;
         }
     }
@@ -1668,30 +1657,24 @@ static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
     /* check offset range */
     if (address >= 0xFF)
     {
-        PT_LOG("Error: Failed to read register with offset exceeding FFh. "
-            "[%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Error: Failed to read register with offset exceeding FFh. "
+            "[Offset:%02xh][Length:%d]\n", address, len);
         goto exit;
     }
 
     /* check read size */
     if ((len != 1) && (len != 2) && (len != 4))
     {
-        PT_LOG("Error: Failed to read register with invalid access length. "
-            "[%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Error: Failed to read register with invalid access length. "
+            "[Offset:%02xh][Length:%d]\n", address, len);
         goto exit;
     }
 
     /* check offset alignment */
     if (address & (len-1))
     {
-        PT_LOG("Error: Failed to read register with invalid access size "
-            "alignment. [%02x:%02x.%x][Offset:%02xh][Length:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-            address, len);
+        PT_LOG_DEV(d, "Error: Failed to read register with invalid access size "
+            "alignment. [Offset:%02xh][Length:%d]\n", address, len);
         goto exit;
     }
 
@@ -1803,9 +1786,7 @@ static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
 exit:
 
 #ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-    PT_LOG("[%02x:%02x.%x]: address=%04x val=0x%08x len=%d\n",
-       pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-       address, val, len);
+    PT_LOG_DEV(d, "address=%04x val=0x%08x len=%d\n", address, val, len);
 #endif
 
     return val;
@@ -2181,9 +2162,8 @@ static void pt_bar_mapping_one(struct pt_dev *ptdev, int bar, int io_enable,
     ret = pt_chk_bar_overlap(dev->bus, dev->devfn,
                     r_addr, r_size, r->type);
     if (ret > 0)
-        PT_LOG("Warning: ptdev[%02x:%02x.%x][Region:%d][Address:%08xh]"
-            "[Size:%08xh] is overlapped.\n", pci_bus_num(dev->bus),
-            PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn), bar, r_addr, r_size);
+        PT_LOG_DEV(dev, "Warning: [Region:%d][Address:%08xh]"
+            "[Size:%08xh] is overlapped.\n", bar, r_addr, r_size);
 
     /* check whether we need to update the mapping or not */
     if (r_addr != ptdev->bases[bar].e_physbase)
@@ -2217,9 +2197,8 @@ static int check_power_state(struct pt_dev *ptdev)
 
     if (pm_state->req_state != cur_state)
     {
-        PT_LOG("Error: Failed to change power state. "
-            "[%02x:%02x.%x][requested state:%d][current state:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+        PT_LOG_DEV(d, "Error: Failed to change power state. "
+            "[requested state:%d][current state:%d]\n",
             pm_state->req_state, cur_state);
         return -1;
     }
@@ -2379,9 +2358,8 @@ static void pt_config_restore(struct pt_dev *ptdev)
             }
 
 #ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG("[%02x:%02x.%x]: address=%04x val=0x%08x len=%d\n",
-                pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
-                real_offset, val, reg->size);
+            PT_LOG_DEV(d, "address=%04x val=0x%08x len=%d\n",
+                    real_offset, val, reg->size);
 #endif
 
             ret = pci_write_block(ptdev->pci_dev, real_offset,
@@ -2426,9 +2404,8 @@ static int pt_init_pci_config(struct pt_dev *ptdev)
     PCIDevice *d = &ptdev->dev;
     int ret = 0;
 
-    PT_LOG("Reinitialize PCI configuration registers "
-        "due to power state transition with internal reset. [%02x:%02x.%x]\n",
-        pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    PT_LOG_DEV(d, "Reinitialize PCI configuration registers "
+        "due to power state transition with internal reset.\n");
 
     /* restore a part of I/O device register */
     pt_config_restore(ptdev);
@@ -3493,10 +3470,9 @@ static int pt_bar_reg_write(struct pt_dev *ptdev,
             if ((last_addr >= 0x10000) &&
                 (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)))
             {
-                PT_LOG("Warning: Guest attempt to set Base Address "
+                PT_LOG_DEV(d, "Warning: Guest attempt to set Base Address "
                     "over the 64KB. "
-                    "[%02x:%02x.%x][Offset:%02xh][Address:%08xh][Size:%08xh]\n",
-                    pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+                    "[Offset:%02xh][Address:%08xh][Size:%08xh]\n",
                     reg->offset, new_addr, r_size);
             }
             /* just remove mapping */
@@ -3509,11 +3485,10 @@ static int pt_bar_reg_write(struct pt_dev *ptdev,
         {
             if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask))
             {
-                PT_LOG("Warning: Guest attempt to set high MMIO Base Address. "
+                PT_LOG_DEV(d, "Warning: Guest attempt to set high MMIO Base Address. "
                     "Ignore mapping. "
-                    "[%02x:%02x.%x][Offset:%02xh][High Address:%08xh]\n",
-                    pci_bus_num(d->bus), PCI_SLOT(d->devfn),
-                    PCI_FUNC(d->devfn), reg->offset, cfg_entry->data);
+                    "[Offset:%02xh][High Address:%08xh]\n",
+                    reg->offset, cfg_entry->data);
             }
             /* clear lower address */
             d->io_regions[index-1].addr = -1;
@@ -3678,9 +3653,8 @@ static int pt_pmcsr_reg_write(struct pt_dev *ptdev,
     if ((pm_state->req_state != 0) &&
         (pm_state->cur_state > pm_state->req_state))
     {
-        PT_LOG("Error: Invalid power transition. "
-            "[%02x:%02x.%x][requested state:%d][current state:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+        PT_LOG_DEV(d, "Error: Invalid power transition. "
+            "[requested state:%d][current state:%d]\n",
             pm_state->req_state, pm_state->cur_state);
 
         return 0;
@@ -3691,9 +3665,8 @@ static int pt_pmcsr_reg_write(struct pt_dev *ptdev,
         || ((pm_state->req_state == 2) &&
         !(pm_state->pmc_field & PCI_PM_CAP_D2)))
     {
-        PT_LOG("Error: Invalid power transition. "
-            "[%02x:%02x.%x][requested state:%d][current state:%d]\n",
-            pci_bus_num(d->bus), PCI_SLOT(d->devfn), PCI_FUNC(d->devfn),
+        PT_LOG_DEV(d, "Error: Invalid power transition. "
+            "[requested state:%d][current state:%d]\n",
             pm_state->req_state, pm_state->cur_state);
 
         return 0;
diff --git a/hw/pass-through.h b/hw/pass-through.h
index bb31acd..884139c 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -31,8 +31,13 @@
 
 #ifdef PT_LOGGING_ENABLED
 #define PT_LOG(_f, _a...)   fprintf(logfile, "%s: " _f, __func__, ##_a)
+#define PT_LOG_DEV(_dev, _f, _a...)   fprintf(logfile, "%s: [%02x:%02x:%01x] " _f, __func__,    \
+                                              pci_bus_num((_dev)->bus),                         \
+                                              PCI_SLOT((_dev)->devfn),                          \
+                                              PCI_FUNC((_dev)->devfn), ##_a)
 #else
 #define PT_LOG(_f, _a...)
+#define PT_LOG_DEV(_dev, _f, _a...)
 #endif
 
 /* Some compilation flags */
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index 6a485ce..fec7390 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -50,9 +50,10 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
     {
         case 0x58:        // PAVPC Offset
             pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
-            PT_LOG("pci_config_write: %x:%x.%x: addr=%x len=%x val=%x\n",
-                   pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
-                   PCI_FUNC(pci_dev->devfn), config_addr, len, val);
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+                    config_addr, len, val);
+#endif
             break;
         default:
             pci_default_write_config(pci_dev, config_addr, val, len);
@@ -81,9 +82,10 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
             val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
-            PT_LOG("pci_config_read: %x:%x.%x: addr=%x len=%x val=%x\n",
-                   pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
-                   PCI_FUNC(pci_dev->devfn), config_addr, len, val);
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+                    config_addr, len, val);
+#endif
             break;
         default:
             val = pci_default_read_config(pci_dev, config_addr, len);

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:52:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDFr-0004uK-Bz; Wed, 23 Nov 2011 13:52:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTDFq-0004sl-0Q
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:52:50 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322056339!4683660!2
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23904 invoked from network); 23 Nov 2011 13:52:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:52:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:52:13 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTDFF-0005Bx-KJ;
	Wed, 23 Nov 2011 13:52:13 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTDF2-00058k-5k;
	Wed, 23 Nov 2011 13:52:00 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 13:51:58 +0000
Message-ID: <1322056319-19725-2-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
In-Reply-To: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: allen.m.kay@intel.com, Ian.Jackson@eu.citrix.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] qemu-xen: Clean pt-graphic,
	use defined value.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Used defined value for 0x8086 (PCI_VENDOR_ID_INTEL) and some PCI config
space offsets.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pci.h         |    1 +
 hw/pt-graphics.c |   12 ++++++------
 2 files changed, 7 insertions(+), 6 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0002-qemu-xen-Clean-pt-graphic-use-defined-value.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0002-qemu-xen-Clean-pt-graphic-use-defined-value.patch"

diff --git a/hw/pci.h b/hw/pci.h
index e2c1fd8..edc58b6 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -169,6 +169,7 @@ typedef struct PCIIORegion {
 #define PCI_INTERRUPT_PIN	0x3d	/* 8 bits */
 #define PCI_MIN_GNT		0x3e	/* 8 bits */
 #define PCI_MAX_LAT		0x3f	/* 8 bits */
+#define PCI_INTEL_OPREGION	0xfc    /* 32 bits */
 
 /* Header type 1 (PCI-to-PCI bridges) */
 #define PCI_SEC_STATUS		0x1e	/* Secondary status register */
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index 73c5a43..6a485ce 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -32,7 +32,7 @@ void intel_pch_init(PCIBus *bus)
     did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
     rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
 
-    if ( vid == 0x8086 ) 
+    if ( vid == PCI_VENDOR_ID_INTEL )
         pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
                         pch_map_irq, "intel_bridge_1f");
 }
@@ -117,8 +117,8 @@ int register_vga_regions(struct pt_dev *real_device)
 
     /* 1:1 map ASL Storage register value */
     vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, 0xfc, 4);
-    if ( (vendor_id == 0x8086) && igd_opregion )
+    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
+    if ( (vendor_id == PCI_VENDOR_ID_INTEL ) && igd_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,
                 igd_opregion >> XC_PAGE_SHIFT,
@@ -157,9 +157,9 @@ int unregister_vga_regions(struct pt_dev *real_device)
             20,
             DPCI_REMOVE_MAPPING);
 
-    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, 0xfc, 4);
-    if ( (vendor_id == 0x8086) && igd_opregion )
+    vendor_id = pt_pci_host_read(real_device->pci_dev, PCI_VENDOR_ID, 2);
+    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
+    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,
                 igd_opregion >> XC_PAGE_SHIFT,

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:52:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:52:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDFr-0004uK-Bz; Wed, 23 Nov 2011 13:52:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTDFq-0004sl-0Q
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:52:50 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322056339!4683660!2
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23904 invoked from network); 23 Nov 2011 13:52:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:52:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:52:13 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTDFF-0005Bx-KJ;
	Wed, 23 Nov 2011 13:52:13 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTDF2-00058k-5k;
	Wed, 23 Nov 2011 13:52:00 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 13:51:58 +0000
Message-ID: <1322056319-19725-2-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
In-Reply-To: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: allen.m.kay@intel.com, Ian.Jackson@eu.citrix.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] qemu-xen: Clean pt-graphic,
	use defined value.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Used defined value for 0x8086 (PCI_VENDOR_ID_INTEL) and some PCI config
space offsets.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pci.h         |    1 +
 hw/pt-graphics.c |   12 ++++++------
 2 files changed, 7 insertions(+), 6 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0002-qemu-xen-Clean-pt-graphic-use-defined-value.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0002-qemu-xen-Clean-pt-graphic-use-defined-value.patch"

diff --git a/hw/pci.h b/hw/pci.h
index e2c1fd8..edc58b6 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -169,6 +169,7 @@ typedef struct PCIIORegion {
 #define PCI_INTERRUPT_PIN	0x3d	/* 8 bits */
 #define PCI_MIN_GNT		0x3e	/* 8 bits */
 #define PCI_MAX_LAT		0x3f	/* 8 bits */
+#define PCI_INTEL_OPREGION	0xfc    /* 32 bits */
 
 /* Header type 1 (PCI-to-PCI bridges) */
 #define PCI_SEC_STATUS		0x1e	/* Secondary status register */
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index 73c5a43..6a485ce 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -32,7 +32,7 @@ void intel_pch_init(PCIBus *bus)
     did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
     rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
 
-    if ( vid == 0x8086 ) 
+    if ( vid == PCI_VENDOR_ID_INTEL )
         pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
                         pch_map_irq, "intel_bridge_1f");
 }
@@ -117,8 +117,8 @@ int register_vga_regions(struct pt_dev *real_device)
 
     /* 1:1 map ASL Storage register value */
     vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, 0xfc, 4);
-    if ( (vendor_id == 0x8086) && igd_opregion )
+    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
+    if ( (vendor_id == PCI_VENDOR_ID_INTEL ) && igd_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,
                 igd_opregion >> XC_PAGE_SHIFT,
@@ -157,9 +157,9 @@ int unregister_vga_regions(struct pt_dev *real_device)
             20,
             DPCI_REMOVE_MAPPING);
 
-    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, 0xfc, 4);
-    if ( (vendor_id == 0x8086) && igd_opregion )
+    vendor_id = pt_pci_host_read(real_device->pci_dev, PCI_VENDOR_ID, 2);
+    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
+    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,
                 igd_opregion >> XC_PAGE_SHIFT,

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:53:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDFr-0004uX-PE; Wed, 23 Nov 2011 13:52:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTDFp-0004sm-Vv
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:52:50 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322056339!4683660!3
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23913 invoked from network); 23 Nov 2011 13:52:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:52:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:52:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:52:13 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTDFF-0005Bu-EF;
	Wed, 23 Nov 2011 13:52:13 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTDF2-00058i-1X;
	Wed, 23 Nov 2011 13:52:00 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:57 +0000
Message-ID: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: allen.m.kay@intel.com, Ian.Jackson@eu.citrix.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for
	pt_pci_host_read/write
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


pt_pci_host_read/write now takes a struct pci_dev*.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |   19 +++++++------------
 hw/pass-through.h |    5 +++--
 hw/pt-graphics.c  |   24 +++++++++++++-----------
 3 files changed, 23 insertions(+), 25 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-qemu-xen-Change-prototype-for-pt_pci_host_read-write.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-qemu-xen-Change-prototype-for-pt_pci_host_read-write.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 9c5620d..bd46b2d 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -2055,31 +2055,26 @@ static void pci_access_init(void)
     dpci_infos.pci_access = pci_access;
 }
 
-u32 pt_pci_host_read(int bus, int dev, int fn, u32 addr, int len)
+struct pci_dev *pt_pci_get_dev(int bus, int dev, int fn)
 {
+    pci_access_init();
+    return pci_get_dev(dpci_infos.pci_access, 0, bus, dev, fn);
+}
 
-    struct pci_dev *pci_dev;
+u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len)
+{
     u32 val = -1;
 
     pci_access_init();
-    pci_dev = pci_get_dev(dpci_infos.pci_access, 0, bus, dev, fn);
-    if ( !pci_dev )
-        return 0;
-
     pci_read_block(pci_dev, addr, (u8 *) &val, len);
     return val;
 }
 
-int pt_pci_host_write(int bus, int dev, int fn, u32 addr, u32 val, int len)
+int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len)
 {
-    struct pci_dev *pci_dev;
     int ret = 0;
 
     pci_access_init();
-    pci_dev = pci_get_dev(dpci_infos.pci_access, 0, bus, dev, fn);
-    if ( !pci_dev )
-        return 0;
-
     ret = pci_write_block(pci_dev, addr, (u8 *) &val, len);
     return ret;
 }
diff --git a/hw/pass-through.h b/hw/pass-through.h
index dd218f7..bb31acd 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -406,8 +406,9 @@ static inline pciaddr_t pt_pci_base_addr(pciaddr_t base)
 }
 
 uint8_t pci_intx(struct pt_dev *ptdev);
-u32 pt_pci_host_read(int bus, int dev, int fn, u32 addr, int len);
-int pt_pci_host_write(int bus, int dev, int fn, u32 addr, u32 val, int len);
+struct pci_dev *pt_pci_get_dev(int bus, int dev, int func);
+u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len);
+int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len);
 void intel_pch_init(PCIBus *bus);
 int register_vga_regions(struct pt_dev *real_device);
 int unregister_vga_regions(struct pt_dev *real_device);
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index 889772d..73c5a43 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -23,13 +23,14 @@ void intel_pch_init(PCIBus *bus)
 {
     uint16_t vid, did;
     uint8_t  rid;
+    struct pci_dev *pci_dev_1f = pt_pci_get_dev(0, 0x1f, 0);
 
-    if ( !gfx_passthru )
+    if ( !gfx_passthru || !pci_dev_1f )
         return;
 
-    vid = pt_pci_host_read(0, 0x1f, 0, 0, 2);
-    did = pt_pci_host_read(0, 0x1f, 0, 2, 2);
-    rid = pt_pci_host_read(0, 0x1f, 0, 8, 1);
+    vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
+    did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
+    rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
 
     if ( vid == 0x8086 ) 
         pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
@@ -38,6 +39,7 @@ void intel_pch_init(PCIBus *bus)
 
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
 {
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
     assert(pci_dev->devfn == 0x00);
     if ( !igd_passthru ) {
         pci_default_write_config(pci_dev, config_addr, val, len);
@@ -47,7 +49,7 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
     switch (config_addr)
     {
         case 0x58:        // PAVPC Offset
-            pt_pci_host_write(0, 0, 0, config_addr, val, len);
+            pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
             PT_LOG("pci_config_write: %x:%x.%x: addr=%x len=%x val=%x\n",
                    pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
                    PCI_FUNC(pci_dev->devfn), config_addr, len, val);
@@ -59,6 +61,7 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
 
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
     uint32_t val;
 
     assert(pci_dev->devfn == 0x00);
@@ -77,8 +80,7 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0x58:        /* SNB: PAVPC Offset */
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
-            val = pt_pci_host_read(0, PCI_SLOT(pci_dev->devfn),
-                                   0, config_addr, len);
+            val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
             PT_LOG("pci_config_read: %x:%x.%x: addr=%x len=%x val=%x\n",
                    pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
                    PCI_FUNC(pci_dev->devfn), config_addr, len, val);
@@ -114,8 +116,8 @@ int register_vga_regions(struct pt_dev *real_device)
             DPCI_ADD_MAPPING);
 
     /* 1:1 map ASL Storage register value */
-    vendor_id = pt_pci_host_read(0, 2, 0, 0, 2);
-    igd_opregion = pt_pci_host_read(0, 2, 0, 0xfc, 4);
+    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
+    igd_opregion = pt_pci_host_read(real_device->pci_dev, 0xfc, 4);
     if ( (vendor_id == 0x8086) && igd_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,
@@ -155,8 +157,8 @@ int unregister_vga_regions(struct pt_dev *real_device)
             20,
             DPCI_REMOVE_MAPPING);
 
-    vendor_id = pt_pci_host_read(0, 2, 0, 0, 2);
-    igd_opregion = pt_pci_host_read(0, 2, 0, 0xfc, 4);
+    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
+    igd_opregion = pt_pci_host_read(real_device->pci_dev, 0xfc, 4);
     if ( (vendor_id == 0x8086) && igd_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:53:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDFr-0004uX-PE; Wed, 23 Nov 2011 13:52:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTDFp-0004sm-Vv
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:52:50 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322056339!4683660!3
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23913 invoked from network); 23 Nov 2011 13:52:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:52:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:52:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:52:13 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTDFF-0005Bu-EF;
	Wed, 23 Nov 2011 13:52:13 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTDF2-00058i-1X;
	Wed, 23 Nov 2011 13:52:00 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 13:51:57 +0000
Message-ID: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: allen.m.kay@intel.com, Ian.Jackson@eu.citrix.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for
	pt_pci_host_read/write
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


pt_pci_host_read/write now takes a struct pci_dev*.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |   19 +++++++------------
 hw/pass-through.h |    5 +++--
 hw/pt-graphics.c  |   24 +++++++++++++-----------
 3 files changed, 23 insertions(+), 25 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-qemu-xen-Change-prototype-for-pt_pci_host_read-write.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-qemu-xen-Change-prototype-for-pt_pci_host_read-write.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 9c5620d..bd46b2d 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -2055,31 +2055,26 @@ static void pci_access_init(void)
     dpci_infos.pci_access = pci_access;
 }
 
-u32 pt_pci_host_read(int bus, int dev, int fn, u32 addr, int len)
+struct pci_dev *pt_pci_get_dev(int bus, int dev, int fn)
 {
+    pci_access_init();
+    return pci_get_dev(dpci_infos.pci_access, 0, bus, dev, fn);
+}
 
-    struct pci_dev *pci_dev;
+u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len)
+{
     u32 val = -1;
 
     pci_access_init();
-    pci_dev = pci_get_dev(dpci_infos.pci_access, 0, bus, dev, fn);
-    if ( !pci_dev )
-        return 0;
-
     pci_read_block(pci_dev, addr, (u8 *) &val, len);
     return val;
 }
 
-int pt_pci_host_write(int bus, int dev, int fn, u32 addr, u32 val, int len)
+int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len)
 {
-    struct pci_dev *pci_dev;
     int ret = 0;
 
     pci_access_init();
-    pci_dev = pci_get_dev(dpci_infos.pci_access, 0, bus, dev, fn);
-    if ( !pci_dev )
-        return 0;
-
     ret = pci_write_block(pci_dev, addr, (u8 *) &val, len);
     return ret;
 }
diff --git a/hw/pass-through.h b/hw/pass-through.h
index dd218f7..bb31acd 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -406,8 +406,9 @@ static inline pciaddr_t pt_pci_base_addr(pciaddr_t base)
 }
 
 uint8_t pci_intx(struct pt_dev *ptdev);
-u32 pt_pci_host_read(int bus, int dev, int fn, u32 addr, int len);
-int pt_pci_host_write(int bus, int dev, int fn, u32 addr, u32 val, int len);
+struct pci_dev *pt_pci_get_dev(int bus, int dev, int func);
+u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len);
+int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len);
 void intel_pch_init(PCIBus *bus);
 int register_vga_regions(struct pt_dev *real_device);
 int unregister_vga_regions(struct pt_dev *real_device);
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index 889772d..73c5a43 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -23,13 +23,14 @@ void intel_pch_init(PCIBus *bus)
 {
     uint16_t vid, did;
     uint8_t  rid;
+    struct pci_dev *pci_dev_1f = pt_pci_get_dev(0, 0x1f, 0);
 
-    if ( !gfx_passthru )
+    if ( !gfx_passthru || !pci_dev_1f )
         return;
 
-    vid = pt_pci_host_read(0, 0x1f, 0, 0, 2);
-    did = pt_pci_host_read(0, 0x1f, 0, 2, 2);
-    rid = pt_pci_host_read(0, 0x1f, 0, 8, 1);
+    vid = pt_pci_host_read(pci_dev_1f, PCI_VENDOR_ID, 2);
+    did = pt_pci_host_read(pci_dev_1f, PCI_DEVICE_ID, 2);
+    rid = pt_pci_host_read(pci_dev_1f, PCI_REVISION, 1);
 
     if ( vid == 0x8086 ) 
         pci_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid,
@@ -38,6 +39,7 @@ void intel_pch_init(PCIBus *bus)
 
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
 {
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
     assert(pci_dev->devfn == 0x00);
     if ( !igd_passthru ) {
         pci_default_write_config(pci_dev, config_addr, val, len);
@@ -47,7 +49,7 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
     switch (config_addr)
     {
         case 0x58:        // PAVPC Offset
-            pt_pci_host_write(0, 0, 0, config_addr, val, len);
+            pt_pci_host_write(pci_dev_host_bridge, config_addr, val, len);
             PT_LOG("pci_config_write: %x:%x.%x: addr=%x len=%x val=%x\n",
                    pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
                    PCI_FUNC(pci_dev->devfn), config_addr, len, val);
@@ -59,6 +61,7 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
 
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
     uint32_t val;
 
     assert(pci_dev->devfn == 0x00);
@@ -77,8 +80,7 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0x58:        /* SNB: PAVPC Offset */
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
-            val = pt_pci_host_read(0, PCI_SLOT(pci_dev->devfn),
-                                   0, config_addr, len);
+            val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
             PT_LOG("pci_config_read: %x:%x.%x: addr=%x len=%x val=%x\n",
                    pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
                    PCI_FUNC(pci_dev->devfn), config_addr, len, val);
@@ -114,8 +116,8 @@ int register_vga_regions(struct pt_dev *real_device)
             DPCI_ADD_MAPPING);
 
     /* 1:1 map ASL Storage register value */
-    vendor_id = pt_pci_host_read(0, 2, 0, 0, 2);
-    igd_opregion = pt_pci_host_read(0, 2, 0, 0xfc, 4);
+    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
+    igd_opregion = pt_pci_host_read(real_device->pci_dev, 0xfc, 4);
     if ( (vendor_id == 0x8086) && igd_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,
@@ -155,8 +157,8 @@ int unregister_vga_regions(struct pt_dev *real_device)
             20,
             DPCI_REMOVE_MAPPING);
 
-    vendor_id = pt_pci_host_read(0, 2, 0, 0, 2);
-    igd_opregion = pt_pci_host_read(0, 2, 0, 0xfc, 4);
+    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
+    igd_opregion = pt_pci_host_read(real_device->pci_dev, 0xfc, 4);
     if ( (vendor_id == 0x8086) && igd_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:57:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDK6-000611-B3; Wed, 23 Nov 2011 13:57:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDK5-00060H-0j
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:57:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322056603!5408657!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8113 invoked from network); 23 Nov 2011 13:56:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:56:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092497"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:56:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:56:20 +0000
Date: Wed, 23 Nov 2011 13:57:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322047821.1005.77.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111231353370.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk> 
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com> 
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop> 
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
	<1322047821.1005.77.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 23 Nov 2011, Ian Campbell wrote:
> > > On the other hand I'm not sure why autoballoon and dom0_mem play so
> > > badly together. Surely if dom0_mem is used autoballon should just see
> > > that there is plenty of free RAM in the system and not do anything?
> >  
> > Because one of the "memory slack" paramters needed by autoballoon is
> > 
> > totalmemory - dom0_memory_at_boot
> 
> libxl gets dom0_memory_at_boot via the dominfo (in
> libxl__fill_dom0_memory_info which I assume happens before any
> potentially autoballooning) which should take dom0_mem into account,
> doesn't it?

It does, in the sense that the memory slack is trimmered to max 15% of
total memory.
Basically there is no way to calculate this parameter if dom0_mem is
set, so we conservatively set it to 15%.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:57:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDK6-000611-B3; Wed, 23 Nov 2011 13:57:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTDK5-00060H-0j
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:57:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322056603!5408657!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8113 invoked from network); 23 Nov 2011 13:56:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:56:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9092497"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 13:56:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 13:56:20 +0000
Date: Wed, 23 Nov 2011 13:57:08 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322047821.1005.77.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111231353370.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk> 
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com> 
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop> 
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
	<1322047821.1005.77.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 23 Nov 2011, Ian Campbell wrote:
> > > On the other hand I'm not sure why autoballoon and dom0_mem play so
> > > badly together. Surely if dom0_mem is used autoballon should just see
> > > that there is plenty of free RAM in the system and not do anything?
> >  
> > Because one of the "memory slack" paramters needed by autoballoon is
> > 
> > totalmemory - dom0_memory_at_boot
> 
> libxl gets dom0_memory_at_boot via the dominfo (in
> libxl__fill_dom0_memory_info which I assume happens before any
> potentially autoballooning) which should take dom0_mem into account,
> doesn't it?

It does, in the sense that the memory slack is trimmered to max 15% of
total memory.
Basically there is no way to calculate this parameter if dom0_mem is
set, so we conservatively set it to 15%.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:59:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:59:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDLr-00069u-S7; Wed, 23 Nov 2011 13:59:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RTDLq-00069S-Dd
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:59:02 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322056712!4287916!1
X-Originating-IP: [213.199.154.205]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21004 invoked from network); 23 Nov 2011 13:58:32 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	AM1EHSOBE002.bigfish.com) (213.199.154.205)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Nov 2011 13:58:32 -0000
Received: from mail18-am1-R.bigfish.com (10.3.201.243) by
	AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id
	14.1.225.22; Wed, 23 Nov 2011 13:57:51 +0000
Received: from mail18-am1 (localhost [127.0.0.1])	by mail18-am1-R.bigfish.com
	(Postfix) with ESMTP id BAD945803BF;
	Wed, 23 Nov 2011 13:56:35 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dK1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,13,
Received: from mail18-am1 (localhost.localdomain [127.0.0.1]) by mail18-am1
	(MessageSwitch) id 1322056595515389_1566;
	Wed, 23 Nov 2011 13:56:35 +0000 (UTC)
Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.251])	by
	mail18-am1.bigfish.com (Postfix) with ESMTP id 6E4F4640047;
	Wed, 23 Nov 2011 13:56:35 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server id
	14.1.225.22; Wed, 23 Nov 2011 13:57:50 +0000
X-WSS-ID: 0LV49HF-02-2KS-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25CF8C8119;	Wed, 23 Nov 2011 07:58:27 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 23 Nov 2011 07:58:39 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 23 Nov 2011 07:58:28 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 23 Nov 2011
	08:58:27 -0500
Message-ID: <4ECCFC01.9000700@amd.com>
Date: Wed, 23 Nov 2011 14:58:25 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1322056320-5826-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-OriginatorOrg: amd.com
Cc: Ian.Jackson@eu.citrix.com, xen-devel@lists.xensource.com, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v9 1/6] Introduce git-checkout.sh
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/23/11 14:51, stefano.stabellini@eu.citrix.com wrote:
> From: stefano.stabellini@eu.citrix.com<stefano.stabellini@eu.citrix.com>
>
> Introduce a script to perform git checkout on an external git tree; use
> git-checkout.sh in ioemu-dir-find.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>

[...]

> diff --git a/tools/Makefile b/tools/Makefile
> index 9389e1f..beccad2 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -71,7 +71,7 @@ clean: subdirs-clean
>
>   .PHONY: distclean
>   distclean: subdirs-distclean
> -	rm -rf ioemu-dir ioemu-remote
> +	rm -rf ioemu-dir ioemu-dir-remote
>
>   ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
>   IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
> @@ -89,20 +89,8 @@ ioemu-dir-find:
>   	if test -d $(CONFIG_QEMU); then \
>   		mkdir -p ioemu-dir; \
>   	else \
> -		if [ ! -d ioemu-remote ]; then \
> -			rm -rf ioemu-remote ioemu-remote.tmp; \
> -			mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \
> -			$(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \
> -			if [ "$(QEMU_TAG)" ]; then			\
> -				cd ioemu-remote.tmp;			\
> -				$(GIT) branch -D dummy>/dev/null 2>&1 ||:; \
> -				$(GIT) checkout -b dummy $(QEMU_TAG);	\
> -				cd ..;					\
> -			fi;						\
> -			mv ioemu-remote.tmp ioemu-remote; \
> -		fi; \
> -		rm -f ioemu-dir; \
> -		ln -sf ioemu-remote ioemu-dir; \
> +		export GIT=$(GIT); \
> +		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \

When you use $(SHELL) then we do not need to care about the execute bit:

+		$(SHELL) $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) 
$(QEMU_TAG) ioemu-dir; \


Christoph


>   	fi
>   	set -e; \
>   		$(buildmakevars2shellvars); \
> @@ -113,7 +101,7 @@ ioemu-dir-find:
>   ioemu-dir-force-update:
>   	set -ex; \
>   	if [ "$(QEMU_TAG)" ]; then \
> -		cd ioemu-remote; \
> +		cd ioemu-dir-remote; \
>   		$(GIT) fetch origin; \
>   		$(GIT) reset --hard $(QEMU_TAG); \
>   	fi


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 13:59:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 13:59:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTDLr-00069u-S7; Wed, 23 Nov 2011 13:59:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RTDLq-00069S-Dd
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:59:02 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322056712!4287916!1
X-Originating-IP: [213.199.154.205]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21004 invoked from network); 23 Nov 2011 13:58:32 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	AM1EHSOBE002.bigfish.com) (213.199.154.205)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Nov 2011 13:58:32 -0000
Received: from mail18-am1-R.bigfish.com (10.3.201.243) by
	AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id
	14.1.225.22; Wed, 23 Nov 2011 13:57:51 +0000
Received: from mail18-am1 (localhost [127.0.0.1])	by mail18-am1-R.bigfish.com
	(Postfix) with ESMTP id BAD945803BF;
	Wed, 23 Nov 2011 13:56:35 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dK1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,13,
Received: from mail18-am1 (localhost.localdomain [127.0.0.1]) by mail18-am1
	(MessageSwitch) id 1322056595515389_1566;
	Wed, 23 Nov 2011 13:56:35 +0000 (UTC)
Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.251])	by
	mail18-am1.bigfish.com (Postfix) with ESMTP id 6E4F4640047;
	Wed, 23 Nov 2011 13:56:35 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server id
	14.1.225.22; Wed, 23 Nov 2011 13:57:50 +0000
X-WSS-ID: 0LV49HF-02-2KS-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25CF8C8119;	Wed, 23 Nov 2011 07:58:27 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 23 Nov 2011 07:58:39 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 23 Nov 2011 07:58:28 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Wed, 23 Nov 2011
	08:58:27 -0500
Message-ID: <4ECCFC01.9000700@amd.com>
Date: Wed, 23 Nov 2011 14:58:25 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1322056320-5826-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-OriginatorOrg: amd.com
Cc: Ian.Jackson@eu.citrix.com, xen-devel@lists.xensource.com, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v9 1/6] Introduce git-checkout.sh
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/23/11 14:51, stefano.stabellini@eu.citrix.com wrote:
> From: stefano.stabellini@eu.citrix.com<stefano.stabellini@eu.citrix.com>
>
> Introduce a script to perform git checkout on an external git tree; use
> git-checkout.sh in ioemu-dir-find.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>

[...]

> diff --git a/tools/Makefile b/tools/Makefile
> index 9389e1f..beccad2 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -71,7 +71,7 @@ clean: subdirs-clean
>
>   .PHONY: distclean
>   distclean: subdirs-distclean
> -	rm -rf ioemu-dir ioemu-remote
> +	rm -rf ioemu-dir ioemu-dir-remote
>
>   ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
>   IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
> @@ -89,20 +89,8 @@ ioemu-dir-find:
>   	if test -d $(CONFIG_QEMU); then \
>   		mkdir -p ioemu-dir; \
>   	else \
> -		if [ ! -d ioemu-remote ]; then \
> -			rm -rf ioemu-remote ioemu-remote.tmp; \
> -			mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \
> -			$(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \
> -			if [ "$(QEMU_TAG)" ]; then			\
> -				cd ioemu-remote.tmp;			\
> -				$(GIT) branch -D dummy>/dev/null 2>&1 ||:; \
> -				$(GIT) checkout -b dummy $(QEMU_TAG);	\
> -				cd ..;					\
> -			fi;						\
> -			mv ioemu-remote.tmp ioemu-remote; \
> -		fi; \
> -		rm -f ioemu-dir; \
> -		ln -sf ioemu-remote ioemu-dir; \
> +		export GIT=$(GIT); \
> +		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \

When you use $(SHELL) then we do not need to care about the execute bit:

+		$(SHELL) $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) 
$(QEMU_TAG) ioemu-dir; \


Christoph


>   	fi
>   	set -e; \
>   		$(buildmakevars2shellvars); \
> @@ -113,7 +101,7 @@ ioemu-dir-find:
>   ioemu-dir-force-update:
>   	set -ex; \
>   	if [ "$(QEMU_TAG)" ]; then \
> -		cd ioemu-remote; \
> +		cd ioemu-dir-remote; \
>   		$(GIT) fetch origin; \
>   		$(GIT) reset --hard $(QEMU_TAG); \
>   	fi


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 14:41:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 14:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTE0h-0006mC-38; Wed, 23 Nov 2011 14:41:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTE0g-0006m4-5R
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 14:41:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322059243!2721183!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28842 invoked from network); 23 Nov 2011 14:40:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 14:40:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9093707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 14:40:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 14:40:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 23 Nov 2011 14:40:43 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4AED@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
	<1322047419.1005.72.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AE8@LONPMAILBOX01.citrite.net>
	<1322053488.1005.107.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AED@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322059243.1005.140.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 13:12 +0000, Paul Durrant wrote:
> True. I was conflating the key rm issue with the fact that the
> XenServer Windows PV guest agent gets unhappy because it can't
> advertise its features (which I hadn't mentioned before).
> 
> I suppose that libxl will just have to continue to speculatively write
> control/shutdown and timeout if it's not NUL-ed or rm-ed as it does
> now.

I suppose one option might be a "feature-will-write-features" flag. If
it is not written to true then assume everything is supported, if it
does get set to true then look for the flags and follow them. However if
a protocol is going to be invented then it should be discussed here and
documented etc.

Ian.

> 
>   Paul
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 23 November 2011 13:05
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: RE: [Xen-devel] [PATCH] Prevent xl save from segfaulting
> > when control/shutdown key is removed
> > 
> > On Wed, 2011-11-23 at 12:59 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 23 November 2011 11:24
> > > > To: Paul Durrant
> > > > Cc: xen-devel@lists.xensource.com
> > > > Subject: RE: [Xen-devel] [PATCH] Prevent xl save from
> > segfaulting
> > > > when control/shutdown key is removed
> > > >
> > > > On Wed, 2011-11-23 at 11:19 +0000, Paul Durrant wrote:
> > > > > what is the reason for creating control ro to the guest?
> > > >
> > > > In general libxl prefers to whitelist paths which the guest can
> > > > write too, just to prevent a complete free for all, keep things
> > > > somewhat under control and to help avoid situations where tools
> > > > might inadvertently rely on a guest-writeable key in an unsafe
> > way..
> > > >
> > > > >  In XenServer we allow the guest to write the control key to
> > > > advertise
> > > > > feature-shutdown, feature-suspend etc. so that the tools know
> > what
> > > > > values of control/shutdown the guest will respond to.
> > > >
> > > > The libxl way would be to create these at build time (perhaps
> > empty)
> > > > with the appropriate permissions.
> > > >
> > > > It's not clear how that functionality can be added in a way
> > which is
> > > > compatible with existing guests though, e.g. no Linux guest
> > writes
> > > > those but many can be suspended etc.
> > > >
> > >
> > > So the simple solution, for compatibility's sake, is to make
> > control rw isn't it?
> > 
> > The problem I'm thinking of exists even if control is rw.
> > 
> > Given an empty control directory how do you know if a guest supports
> > suspend or not, given that most existing guests which do support
> > suspend do not write any key there?
> > 
> > Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 14:41:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 14:41:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTE0h-0006mC-38; Wed, 23 Nov 2011 14:41:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTE0g-0006m4-5R
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 14:41:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322059243!2721183!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28842 invoked from network); 23 Nov 2011 14:40:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 14:40:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9093707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 14:40:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 14:40:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 23 Nov 2011 14:40:43 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4AED@LONPMAILBOX01.citrite.net>
References: <3341e3e990568f459ae9.1322041536@cosworth.uk.xensource.com>
	<1322043166.1005.27.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AD4@LONPMAILBOX01.citrite.net>
	<1322047419.1005.72.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AE8@LONPMAILBOX01.citrite.net>
	<1322053488.1005.107.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4AED@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322059243.1005.140.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Prevent xl save from segfaulting when
 control/shutdown key is removed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 13:12 +0000, Paul Durrant wrote:
> True. I was conflating the key rm issue with the fact that the
> XenServer Windows PV guest agent gets unhappy because it can't
> advertise its features (which I hadn't mentioned before).
> 
> I suppose that libxl will just have to continue to speculatively write
> control/shutdown and timeout if it's not NUL-ed or rm-ed as it does
> now.

I suppose one option might be a "feature-will-write-features" flag. If
it is not written to true then assume everything is supported, if it
does get set to true then look for the flags and follow them. However if
a protocol is going to be invented then it should be discussed here and
documented etc.

Ian.

> 
>   Paul
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 23 November 2011 13:05
> > To: Paul Durrant
> > Cc: xen-devel@lists.xensource.com
> > Subject: RE: [Xen-devel] [PATCH] Prevent xl save from segfaulting
> > when control/shutdown key is removed
> > 
> > On Wed, 2011-11-23 at 12:59 +0000, Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > Sent: 23 November 2011 11:24
> > > > To: Paul Durrant
> > > > Cc: xen-devel@lists.xensource.com
> > > > Subject: RE: [Xen-devel] [PATCH] Prevent xl save from
> > segfaulting
> > > > when control/shutdown key is removed
> > > >
> > > > On Wed, 2011-11-23 at 11:19 +0000, Paul Durrant wrote:
> > > > > what is the reason for creating control ro to the guest?
> > > >
> > > > In general libxl prefers to whitelist paths which the guest can
> > > > write too, just to prevent a complete free for all, keep things
> > > > somewhat under control and to help avoid situations where tools
> > > > might inadvertently rely on a guest-writeable key in an unsafe
> > way..
> > > >
> > > > >  In XenServer we allow the guest to write the control key to
> > > > advertise
> > > > > feature-shutdown, feature-suspend etc. so that the tools know
> > what
> > > > > values of control/shutdown the guest will respond to.
> > > >
> > > > The libxl way would be to create these at build time (perhaps
> > empty)
> > > > with the appropriate permissions.
> > > >
> > > > It's not clear how that functionality can be added in a way
> > which is
> > > > compatible with existing guests though, e.g. no Linux guest
> > writes
> > > > those but many can be suspended etc.
> > > >
> > >
> > > So the simple solution, for compatibility's sake, is to make
> > control rw isn't it?
> > 
> > The problem I'm thinking of exists even if control is rw.
> > 
> > Given an empty control directory how do you know if a guest supports
> > suspend or not, given that most existing guests which do support
> > suspend do not write any key there?
> > 
> > Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 14:46:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 14:46:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTE51-0006wY-SZ; Wed, 23 Nov 2011 14:45:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTE4z-0006vq-TP
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 14:45:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322059511!2732994!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 382 invoked from network); 23 Nov 2011 14:45:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 14:45:11 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9093884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 14:45:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 14:45:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTE4U-0005Wh-Ld;
	Wed, 23 Nov 2011 14:45:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTE4U-0005P4-Kz;
	Wed, 23 Nov 2011 14:45:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10007-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 14:45:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10007: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10007 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10007/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win          14 guest-start.2                fail pass in 9980
 test-amd64-amd64-xl-sedf     10 guest-saverestore   fail in 9980 pass in 10007

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check       fail in 9980 never pass

version targeted for testing:
 xen                  c613d436ca09
baseline version:
 xen                  4f4763690d74

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=c613d436ca09
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing c613d436ca09
+ branch=xen-4.1-testing
+ revision=c613d436ca09
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r c613d436ca09 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 14:46:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 14:46:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTE51-0006wY-SZ; Wed, 23 Nov 2011 14:45:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTE4z-0006vq-TP
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 14:45:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322059511!2732994!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 382 invoked from network); 23 Nov 2011 14:45:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 14:45:11 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9093884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 14:45:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 14:45:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTE4U-0005Wh-Ld;
	Wed, 23 Nov 2011 14:45:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTE4U-0005P4-Kz;
	Wed, 23 Nov 2011 14:45:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10007-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 14:45:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10007: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10007 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10007/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win          14 guest-start.2                fail pass in 9980
 test-amd64-amd64-xl-sedf     10 guest-saverestore   fail in 9980 pass in 10007

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check       fail in 9980 never pass

version targeted for testing:
 xen                  c613d436ca09
baseline version:
 xen                  4f4763690d74

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=c613d436ca09
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.1-testing c613d436ca09
+ branch=xen-4.1-testing
+ revision=c613d436ca09
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r c613d436ca09 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 14:46:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 14:46:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTE52-0006wk-9f; Wed, 23 Nov 2011 14:45:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTE50-0006vu-Oh
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 14:45:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322059511!2732994!2
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 443 invoked from network); 23 Nov 2011 14:45:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 14:45:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9093885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 14:45:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 14:45:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 23 Nov 2011 14:45:12 +0000
In-Reply-To: <alpine.DEB.2.00.1111231353370.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
	<1322047821.1005.77.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231353370.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322059512.1005.144.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 13:57 +0000, Stefano Stabellini wrote:
> On Wed, 23 Nov 2011, Ian Campbell wrote:
> > > > On the other hand I'm not sure why autoballoon and dom0_mem play so
> > > > badly together. Surely if dom0_mem is used autoballon should just see
> > > > that there is plenty of free RAM in the system and not do anything?
> > >  
> > > Because one of the "memory slack" paramters needed by autoballoon is
> > > 
> > > totalmemory - dom0_memory_at_boot
> > 
> > libxl gets dom0_memory_at_boot via the dominfo (in
> > libxl__fill_dom0_memory_info which I assume happens before any
> > potentially autoballooning) which should take dom0_mem into account,
> > doesn't it?
> 
> It does, in the sense that the memory slack is trimmered to max 15% of
> total memory.
> Basically there is no way to calculate this parameter if dom0_mem is
> set, so we conservatively set it to 15%.

What I meant was that dom0_memory_at_boot comes from
XEN_SYSCTL_getdomaininfolist and is therefore the value of the dom0_mem
parameter (give or take a wiggle, I suppose), when called from
libxl__fill_dom0_memory_info (i.e. before any auto ballooning has taken
place). In other words there is a way to calculate this parameter...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 14:46:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 14:46:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTE52-0006wk-9f; Wed, 23 Nov 2011 14:45:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTE50-0006vu-Oh
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 14:45:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322059511!2732994!2
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 443 invoked from network); 23 Nov 2011 14:45:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 14:45:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9093885"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 14:45:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 14:45:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 23 Nov 2011 14:45:12 +0000
In-Reply-To: <alpine.DEB.2.00.1111231353370.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
	<1322047821.1005.77.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231353370.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322059512.1005.144.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 13:57 +0000, Stefano Stabellini wrote:
> On Wed, 23 Nov 2011, Ian Campbell wrote:
> > > > On the other hand I'm not sure why autoballoon and dom0_mem play so
> > > > badly together. Surely if dom0_mem is used autoballon should just see
> > > > that there is plenty of free RAM in the system and not do anything?
> > >  
> > > Because one of the "memory slack" paramters needed by autoballoon is
> > > 
> > > totalmemory - dom0_memory_at_boot
> > 
> > libxl gets dom0_memory_at_boot via the dominfo (in
> > libxl__fill_dom0_memory_info which I assume happens before any
> > potentially autoballooning) which should take dom0_mem into account,
> > doesn't it?
> 
> It does, in the sense that the memory slack is trimmered to max 15% of
> total memory.
> Basically there is no way to calculate this parameter if dom0_mem is
> set, so we conservatively set it to 15%.

What I meant was that dom0_memory_at_boot comes from
XEN_SYSCTL_getdomaininfolist and is therefore the value of the dom0_mem
parameter (give or take a wiggle, I suppose), when called from
libxl__fill_dom0_memory_info (i.e. before any auto ballooning has taken
place). In other words there is a way to calculate this parameter...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 14:53:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 14:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTECV-0007KV-AA; Wed, 23 Nov 2011 14:53:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTECT-0007KJ-Ai
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 14:53:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322059975!5434265!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22042 invoked from network); 23 Nov 2011 14:52:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 14:52:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9094131"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 14:52:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 14:52:55 +0000
Date: Wed, 23 Nov 2011 14:53:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322059512.1005.144.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111231452270.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk> 
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com> 
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop> 
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
	<1322047821.1005.77.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231353370.31179@kaball-desktop>
	<1322059512.1005.144.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 23 Nov 2011, Ian Campbell wrote:
> On Wed, 2011-11-23 at 13:57 +0000, Stefano Stabellini wrote:
> > On Wed, 23 Nov 2011, Ian Campbell wrote:
> > > > > On the other hand I'm not sure why autoballoon and dom0_mem play so
> > > > > badly together. Surely if dom0_mem is used autoballon should just see
> > > > > that there is plenty of free RAM in the system and not do anything?
> > > >  
> > > > Because one of the "memory slack" paramters needed by autoballoon is
> > > > 
> > > > totalmemory - dom0_memory_at_boot
> > > 
> > > libxl gets dom0_memory_at_boot via the dominfo (in
> > > libxl__fill_dom0_memory_info which I assume happens before any
> > > potentially autoballooning) which should take dom0_mem into account,
> > > doesn't it?
> > 
> > It does, in the sense that the memory slack is trimmered to max 15% of
> > total memory.
> > Basically there is no way to calculate this parameter if dom0_mem is
> > set, so we conservatively set it to 15%.
> 
> What I meant was that dom0_memory_at_boot comes from
> XEN_SYSCTL_getdomaininfolist and is therefore the value of the dom0_mem
> parameter (give or take a wiggle, I suppose), when called from
> libxl__fill_dom0_memory_info (i.e. before any auto ballooning has taken
> place). In other words there is a way to calculate this parameter...

we don't want to know the value of the dom0_mem parameter, we need the
amount of memory dom0 would have if dom0_mem was NOT passed to Xen.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 14:53:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 14:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTECV-0007KV-AA; Wed, 23 Nov 2011 14:53:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTECT-0007KJ-Ai
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 14:53:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322059975!5434265!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22042 invoked from network); 23 Nov 2011 14:52:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 14:52:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9094131"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 14:52:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 14:52:55 +0000
Date: Wed, 23 Nov 2011 14:53:43 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322059512.1005.144.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111231452270.31179@kaball-desktop>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk> 
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com> 
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop> 
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231118120.31179@kaball-desktop>
	<1322047821.1005.77.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1111231353370.31179@kaball-desktop>
	<1322059512.1005.144.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Teck Choon Giam <giamteckchoon@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 23 Nov 2011, Ian Campbell wrote:
> On Wed, 2011-11-23 at 13:57 +0000, Stefano Stabellini wrote:
> > On Wed, 23 Nov 2011, Ian Campbell wrote:
> > > > > On the other hand I'm not sure why autoballoon and dom0_mem play so
> > > > > badly together. Surely if dom0_mem is used autoballon should just see
> > > > > that there is plenty of free RAM in the system and not do anything?
> > > >  
> > > > Because one of the "memory slack" paramters needed by autoballoon is
> > > > 
> > > > totalmemory - dom0_memory_at_boot
> > > 
> > > libxl gets dom0_memory_at_boot via the dominfo (in
> > > libxl__fill_dom0_memory_info which I assume happens before any
> > > potentially autoballooning) which should take dom0_mem into account,
> > > doesn't it?
> > 
> > It does, in the sense that the memory slack is trimmered to max 15% of
> > total memory.
> > Basically there is no way to calculate this parameter if dom0_mem is
> > set, so we conservatively set it to 15%.
> 
> What I meant was that dom0_memory_at_boot comes from
> XEN_SYSCTL_getdomaininfolist and is therefore the value of the dom0_mem
> parameter (give or take a wiggle, I suppose), when called from
> libxl__fill_dom0_memory_info (i.e. before any auto ballooning has taken
> place). In other words there is a way to calculate this parameter...

we don't want to know the value of the dom0_mem parameter, we need the
amount of memory dom0 would have if dom0_mem was NOT passed to Xen.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 14:56:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 14:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTEFA-0007St-4D; Wed, 23 Nov 2011 14:56:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTEF9-0007Sn-1L
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 14:56:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322060026!45508403!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3994 invoked from network); 23 Nov 2011 14:53:46 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 14:53:46 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73385261; Wed, 23 Nov 2011 15:55:39 +0100
Message-ID: <1322060131.30168.15.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 15:55:31 +0100
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3623433031883149479=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3623433031883149479==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-isU7WgRQ2IUCWmmUijnl"


--=-isU7WgRQ2IUCWmmUijnl
Content-Type: multipart/mixed; boundary="=-X2L9tkRP5oeRl7Vc+sn5"


--=-X2L9tkRP5oeRl7Vc+sn5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

This series changes how locks are dealt with while adjusting domains'
scheduling parameters.

I've done and am still doing tests for credit and credit2, and it's
surviving to all I threw at it up to now. Unfortunately, I can't test
the sedf part yet, since it is not working on my test boxes due to other
issues (which I'm also trying to track down). I'm sending the series out
anyway, so that at least you can have a look at it, and maybe give a
spin on the sedf part, if you don't have anything more interesting to
do. ;-P

Juergen series on xl scheduling support attached to this mail, in the
form of a single patch, for testing convenience.

--

xen/common/sched_credit.c  |   10 +++++++---
xen/common/sched_credit2.c |   21 +++++++++++----------
xen/common/sched_sedf.c    |  131 +++++++++++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------=
---------------
xen/common/schedule.c      |   34 ++--------------------------------
4 files changed, 130 insertions(+), 66 deletions(-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-X2L9tkRP5oeRl7Vc+sn5
Content-Disposition: attachment; filename="update-xl-sched-interface-from-Juergen.patch"
Content-Type: text/x-patch; name="update-xl-sched-interface-from-Juergen.patch";
	charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGE4MGE1NzdjMzRjYTQyMWZlOTcxNDFlZWUz
MjlmYjE0YjEwMGZhYTINCkltcHJvdmVkIHhsIHNjaGVkdWxpbmcgc3VwcG9ydCBmcm9tIEp1ZXJn
ZW4uDQoNClRoaXMgaXMgaGVyZSBhcyBhIHNpbmdsZSBwYXRjaCwganVzdCBmb3IgY29udmVuaWVu
Y2UsIGluIGNhc2UNCm9uZSB3YW50cyB0byB0ZXN0IHRoZSBzZXJpZXMuIEZvciBkZXRhaWxzIHNl
ZQ0KaHR0cDovL29zZGlyLmNvbS9tbC94ZW4tZGV2ZWxvcG1lbnQvMjAxMS0xMS9tc2cwMTA5Ny5o
dG1sIC4NCg0KZGlmZiAtciBhODBhNTc3YzM0Y2EgZG9jcy9tYW4veGwucG9kLjENCi0tLSBhL2Rv
Y3MvbWFuL3hsLnBvZC4xCVdlZCBOb3YgMjMgMTU6MzY6MjIgMjAxMSArMDEwMA0KKysrIGIvZG9j
cy9tYW4veGwucG9kLjEJV2VkIE5vdiAyMyAxNTo0MTozMiAyMDExICswMTAwDQpAQCAtNTc5LDI1
ICs1NzksMzAgQEAgZGVmYXVsdCBCPGNyZWRpdD4gaXMgdXNlZCBmb3Igc2NoZWR1bGluZw0KIA0K
ID1vdmVyIDQNCiANCi09aXRlbSBCPHNjaGVkLWNyZWRpdD4gWyBCPC1kPiBJPGRvbWFpbi1pZD4g
WyBCPC13PltCPD0+STxXRUlHSFQ+XSB8IEI8LWM+W0I8PT5JPENBUD5dIF0gXQ0KKz1pdGVtIEI8
c2NoZWQtY3JlZGl0PiBbSTxPUFRJT05TPl0NCiANCi1TZXQgY3JlZGl0IHNjaGVkdWxlciBwYXJh
bWV0ZXJzLiAgVGhlIGNyZWRpdCBzY2hlZHVsZXIgaXMgYQ0KK1NldCBvciBnZXQgY3JlZGl0IHNj
aGVkdWxlciBwYXJhbWV0ZXJzLiAgVGhlIGNyZWRpdCBzY2hlZHVsZXIgaXMgYQ0KIHByb3BvcnRp
b25hbCBmYWlyIHNoYXJlIENQVSBzY2hlZHVsZXIgYnVpbHQgZnJvbSB0aGUgZ3JvdW5kIHVwIHRv
IGJlDQogd29yayBjb25zZXJ2aW5nIG9uIFNNUCBob3N0cy4NCiANCiBFYWNoIGRvbWFpbiAoaW5j
bHVkaW5nIERvbWFpbjApIGlzIGFzc2lnbmVkIGEgd2VpZ2h0IGFuZCBhIGNhcC4NCiANCi1CPFBB
UkFNRVRFUlM+DQorQjxPUFRJT05TPg0KIA0KID1vdmVyIDQNCiANCi09aXRlbSBJPFdFSUdIVD4N
Cis9aXRlbSBCPC1kIERPTUFJTj4sIEI8LS1kb21haW49RE9NQUlOPg0KKw0KK1NwZWNpZnkgZG9t
YWluIGZvciB3aGljaCBzY2hlZHVsZXIgcGFyYW1ldGVycyBhcmUgdG8gYmUgbW9kaWZpZWQgb3Ig
cmV0cmlldmVkLg0KK01hbmRhdG9yeSBmb3IgbW9kaWZ5aW5nIHNjaGVkdWxlciBwYXJhbWV0ZXJz
Lg0KKw0KKz1pdGVtIEI8LXcgV0VJR0hUPiwgQjwtLXdlaWdodD1XRUlHSFQ+DQogDQogQSBkb21h
aW4gd2l0aCBhIHdlaWdodCBvZiA1MTIgd2lsbCBnZXQgdHdpY2UgYXMgbXVjaCBDUFUgYXMgYSBk
b21haW4NCiB3aXRoIGEgd2VpZ2h0IG9mIDI1NiBvbiBhIGNvbnRlbmRlZCBob3N0LiBMZWdhbCB3
ZWlnaHRzIHJhbmdlIGZyb20gMQ0KIHRvIDY1NTM1IGFuZCB0aGUgZGVmYXVsdCBpcyAyNTYuDQog
DQotPWl0ZW0gSTxDQVA+DQorPWl0ZW0gQjwtYyBDQVA+LCBCPC0tY2FwPUNBUD4NCiANCiBUaGUg
Y2FwIG9wdGlvbmFsbHkgZml4ZXMgdGhlIG1heGltdW0gYW1vdW50IG9mIENQVSBhIGRvbWFpbiB3
aWxsIGJlDQogYWJsZSB0byBjb25zdW1lLCBldmVuIGlmIHRoZSBob3N0IHN5c3RlbSBoYXMgaWRs
ZSBDUFUgY3ljbGVzLiBUaGUgY2FwDQpAQCAtNjA1LDYgKzYxMCw4MSBAQCBpcyBleHByZXNzZWQg
aW4gcGVyY2VudGFnZSBvZiBvbmUgcGh5c2ljDQogNTAgaXMgaGFsZiBhIENQVSwgNDAwIGlzIDQg
Q1BVcywgZXRjLiBUaGUgZGVmYXVsdCwgMCwgbWVhbnMgdGhlcmUgaXMNCiBubyB1cHBlciBjYXAu
DQogDQorPWl0ZW0gQjwtcCBDUFVQT09MPiwgQjwtLWNwdXBvb2w9Q1BVUE9PTD4NCisNCitSZXN0
cmljdCBvdXRwdXQgdG8gZG9tYWlucyBpbiB0aGUgc3BlY2lmaWVkIGNwdXBvb2wuDQorDQorPWJh
Y2sNCisNCis9aXRlbSBCPHNjaGVkLWNyZWRpdDI+IFtJPE9QVElPTlM+XQ0KKw0KK1NldCBvciBn
ZXQgY3JlZGl0MiBzY2hlZHVsZXIgcGFyYW1ldGVycy4gIFRoZSBjcmVkaXQyIHNjaGVkdWxlciBp
cyBhDQorcHJvcG9ydGlvbmFsIGZhaXIgc2hhcmUgQ1BVIHNjaGVkdWxlciBidWlsdCBmcm9tIHRo
ZSBncm91bmQgdXAgdG8gYmUNCit3b3JrIGNvbnNlcnZpbmcgb24gU01QIGhvc3RzLg0KKw0KK0Vh
Y2ggZG9tYWluIChpbmNsdWRpbmcgRG9tYWluMCkgaXMgYXNzaWduZWQgYSB3ZWlnaHQuDQorDQor
QjxPUFRJT05TPg0KKw0KKz1vdmVyIDQNCisNCis9aXRlbSBCPC1kIERPTUFJTj4sIEI8LS1kb21h
aW49RE9NQUlOPg0KKw0KK1NwZWNpZnkgZG9tYWluIGZvciB3aGljaCBzY2hlZHVsZXIgcGFyYW1l
dGVycyBhcmUgdG8gYmUgbW9kaWZpZWQgb3IgcmV0cmlldmVkLg0KK01hbmRhdG9yeSBmb3IgbW9k
aWZ5aW5nIHNjaGVkdWxlciBwYXJhbWV0ZXJzLg0KKw0KKz1pdGVtIEI8LXcgV0VJR0hUPiwgQjwt
LXdlaWdodD1XRUlHSFQ+DQorDQorQSBkb21haW4gd2l0aCBhIHdlaWdodCBvZiA1MTIgd2lsbCBn
ZXQgdHdpY2UgYXMgbXVjaCBDUFUgYXMgYSBkb21haW4NCit3aXRoIGEgd2VpZ2h0IG9mIDI1NiBv
biBhIGNvbnRlbmRlZCBob3N0LiBMZWdhbCB3ZWlnaHRzIHJhbmdlIGZyb20gMQ0KK3RvIDY1NTM1
IGFuZCB0aGUgZGVmYXVsdCBpcyAyNTYuDQorDQorPWl0ZW0gQjwtcCBDUFVQT09MPiwgQjwtLWNw
dXBvb2w9Q1BVUE9PTD4NCisNCitSZXN0cmljdCBvdXRwdXQgdG8gZG9tYWlucyBpbiB0aGUgc3Bl
Y2lmaWVkIGNwdXBvb2wuDQorDQorPWJhY2sNCisNCis9aXRlbSBCPHNjaGVkLXNlZGY+IFtJPE9Q
VElPTlM+XQ0KKw0KK1NldCBvciBnZXQgU2ltcGxlIEVERiAoRWFybGllc3QgRGVhZGxpbmUgRmly
c3QpIHNjaGVkdWxlciBwYXJhbWV0ZXJzLiBUaGlzDQorc2NoZWR1bGVyIHByb3ZpZGVzIHdlaWdo
dGVkIENQVSBzaGFyaW5nIGluIGFuIGludHVpdGl2ZSB3YXkgYW5kIHVzZXMNCityZWFsdGltZS1h
bGdvcml0aG1zIHRvIGVuc3VyZSB0aW1lIGd1YXJhbnRlZXMuICBGb3IgbW9yZSBpbmZvcm1hdGlv
biBzZWUNCitkb2NzL21pc2Mvc2VkZl9zY2hlZHVsZXJfbWluaS1IT1dUTy50eHQgaW4gdGhlIFhl
biBkaXN0cmlidXRpb24uDQorDQorQjxPUFRJT05TPg0KKw0KKz1vdmVyIDQNCisNCis9aXRlbSBC
PC1kIERPTUFJTj4sIEI8LS1kb21haW49RE9NQUlOPg0KKw0KK1NwZWNpZnkgZG9tYWluIGZvciB3
aGljaCBzY2hlZHVsZXIgcGFyYW1ldGVycyBhcmUgdG8gYmUgbW9kaWZpZWQgb3IgcmV0cmlldmVk
Lg0KK01hbmRhdG9yeSBmb3IgbW9kaWZ5aW5nIHNjaGVkdWxlciBwYXJhbWV0ZXJzLg0KKw0KKz1p
dGVtIEI8LXAgUEVSSU9EPiwgQjwtLXBlcmlvZD1QRVJJT0Q+DQorDQorVGhlIG5vcm1hbCBFREYg
c2NoZWR1bGluZyB1c2FnZSBpbiBtaWxsaXNlY29uZHMuDQorDQorPWl0ZW0gQjwtcyBTTElDRT4s
IEI8LS1zbGljZT1TTElDRT4NCisNCitUaGUgbm9ybWFsIEVERiBzY2hlZHVsaW5nIHVzYWdlIGlu
IG1pbGxpc2Vjb25kcy4NCisNCis9aXRlbSBCPC1sIExBVEVOQ1k+LCBCPC0tbGF0ZW5jeT1MQVRF
TkNZPg0KKw0KK1NjYWxlZCBwZXJpb2QgaWYgZG9tYWluIGlzIGRvaW5nIGhlYXZ5IEkvTy4NCisN
Cis9aXRlbSBCPC1lIEVYVFJBPiwgQjwtLWV4dHJhPUVYVFJBPg0KKw0KK0ZsYWcgZm9yIGFsbG93
aW5nIGRvbWFpbiB0byBydW4gaW4gZXh0cmEgdGltZSAoMCBvciAxKS4NCisNCis9aXRlbSBCPC13
IFdFSUdIVD4sIEI8LS13ZWlnaHQ9V0VJR0hUPg0KKw0KK0Fub3RoZXIgd2F5IG9mIHNldHRpbmcg
Q1BVIHNsaWNlLg0KKw0KKz1pdGVtIEI8LWMgQ1BVUE9PTD4sIEI8LS1jcHVwb29sPUNQVVBPT0w+
DQorDQorUmVzdHJpY3Qgb3V0cHV0IHRvIGRvbWFpbnMgaW4gdGhlIHNwZWNpZmllZCBjcHVwb29s
Lg0KKw0KID1iYWNrDQogDQogPWJhY2sNCmRpZmYgLXIgYTgwYTU3N2MzNGNhIHRvb2xzL2xpYnhs
L2xpYnhsLmMNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsLmMJV2VkIE5vdiAyMyAxNTozNjoyMiAy
MDExICswMTAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bC5jCVdlZCBOb3YgMjMgMTU6NDE6MzIg
MjAxMSArMDEwMA0KQEAgLTM2MSw2ICszNjEsNyBAQCBzdGF0aWMgdm9pZCB4Y2luZm8yeGxpbmZv
KGNvbnN0IHhjX2RvbWFpDQogICAgIHhsaW5mby0+Y3B1X3RpbWUgPSB4Y2luZm8tPmNwdV90aW1l
Ow0KICAgICB4bGluZm8tPnZjcHVfbWF4X2lkID0geGNpbmZvLT5tYXhfdmNwdV9pZDsNCiAgICAg
eGxpbmZvLT52Y3B1X29ubGluZSA9IHhjaW5mby0+bnJfb25saW5lX3ZjcHVzOw0KKyAgICB4bGlu
Zm8tPmNwdXBvb2wgPSB4Y2luZm8tPmNwdXBvb2w7DQogfQ0KIA0KIGxpYnhsX2RvbWluZm8gKiBs
aWJ4bF9saXN0X2RvbWFpbihsaWJ4bF9jdHggKmN0eCwgaW50ICpuYl9kb21haW4pDQpAQCAtMjY3
OCw3ICsyNjc5LDcgQEAgaW50IGxpYnhsX3NjaGVkX2NyZWRpdF9kb21haW5fZ2V0KGxpYnhsXw0K
IA0KICAgICByYyA9IHhjX3NjaGVkX2NyZWRpdF9kb21haW5fZ2V0KGN0eC0+eGNoLCBkb21pZCwg
JnNkb20pOw0KICAgICBpZiAocmMgIT0gMCkgew0KLSAgICAgICAgTElCWExfX0xPR19FUlJOTyhj
dHgsIExJQlhMX19MT0dfRVJST1IsICJzZXR0aW5nIGRvbWFpbiBzY2hlZCBjcmVkaXQiKTsNCisg
ICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAiZ2V0dGluZyBk
b21haW4gc2NoZWQgY3JlZGl0Iik7DQogICAgICAgICByZXR1cm4gRVJST1JfRkFJTDsNCiAgICAg
fQ0KIA0KQEAgLTI3MjgsNiArMjcyOSwxMDMgQEAgaW50IGxpYnhsX3NjaGVkX2NyZWRpdF9kb21h
aW5fc2V0KGxpYnhsXw0KICAgICByZXR1cm4gMDsNCiB9DQogDQoraW50IGxpYnhsX3NjaGVkX2Ny
ZWRpdDJfZG9tYWluX2dldChsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQsIGxpYnhsX3Nj
aGVkX2NyZWRpdDIgKnNjaW5mbykNCit7DQorICAgIHN0cnVjdCB4ZW5fZG9tY3RsX3NjaGVkX2Ny
ZWRpdDIgc2RvbTsNCisgICAgaW50IHJjOw0KKw0KKyAgICByYyA9IHhjX3NjaGVkX2NyZWRpdDJf
ZG9tYWluX2dldChjdHgtPnhjaCwgZG9taWQsICZzZG9tKTsNCisgICAgaWYgKHJjICE9IDApIHsN
CisgICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAiZ2V0dGlu
ZyBkb21haW4gc2NoZWQgY3JlZGl0MiIpOw0KKyAgICAgICAgcmV0dXJuIEVSUk9SX0ZBSUw7DQor
ICAgIH0NCisNCisgICAgc2NpbmZvLT53ZWlnaHQgPSBzZG9tLndlaWdodDsNCisNCisgICAgcmV0
dXJuIDA7DQorfQ0KKw0KK2ludCBsaWJ4bF9zY2hlZF9jcmVkaXQyX2RvbWFpbl9zZXQobGlieGxf
Y3R4ICpjdHgsIHVpbnQzMl90IGRvbWlkLCBsaWJ4bF9zY2hlZF9jcmVkaXQyICpzY2luZm8pDQor
ew0KKyAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zY2hlZF9jcmVkaXQyIHNkb207DQorICAgIHhjX2Rv
bWFpbmluZm9fdCBkb21haW5pbmZvOw0KKyAgICBpbnQgcmM7DQorDQorICAgIHJjID0geGNfZG9t
YWluX2dldGluZm9saXN0KGN0eC0+eGNoLCBkb21pZCwgMSwgJmRvbWFpbmluZm8pOw0KKyAgICBp
ZiAocmMgPCAwKSB7DQorICAgICAgICBMSUJYTF9fTE9HX0VSUk5PKGN0eCwgTElCWExfX0xPR19F
UlJPUiwgImdldHRpbmcgZG9tYWluIGluZm8gbGlzdCIpOw0KKyAgICAgICAgcmV0dXJuIEVSUk9S
X0ZBSUw7DQorICAgIH0NCisgICAgaWYgKHJjICE9IDEgfHwgZG9tYWluaW5mby5kb21haW4gIT0g
ZG9taWQpDQorICAgICAgICByZXR1cm4gRVJST1JfSU5WQUw7DQorDQorDQorICAgIGlmIChzY2lu
Zm8tPndlaWdodCA8IDEgfHwgc2NpbmZvLT53ZWlnaHQgPiA2NTUzNSkgew0KKyAgICAgICAgTElC
WExfX0xPR19FUlJOT1ZBTChjdHgsIExJQlhMX19MT0dfRVJST1IsIHJjLA0KKyAgICAgICAgICAg
ICJDcHUgd2VpZ2h0IG91dCBvZiByYW5nZSwgdmFsaWQgdmFsdWVzIGFyZSB3aXRoaW4gcmFuZ2Ug
ZnJvbSAxIHRvIDY1NTM1Iik7DQorICAgICAgICByZXR1cm4gRVJST1JfSU5WQUw7DQorICAgIH0N
CisNCisgICAgc2RvbS53ZWlnaHQgPSBzY2luZm8tPndlaWdodDsNCisNCisgICAgcmMgPSB4Y19z
Y2hlZF9jcmVkaXQyX2RvbWFpbl9zZXQoY3R4LT54Y2gsIGRvbWlkLCAmc2RvbSk7DQorICAgIGlm
ICggcmMgPCAwICkgew0KKyAgICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0df
RVJST1IsICJzZXR0aW5nIGRvbWFpbiBzY2hlZCBjcmVkaXQyIik7DQorICAgICAgICByZXR1cm4g
RVJST1JfRkFJTDsNCisgICAgfQ0KKw0KKyAgICByZXR1cm4gMDsNCit9DQorDQoraW50IGxpYnhs
X3NjaGVkX3NlZGZfZG9tYWluX2dldChsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQsIGxp
YnhsX3NjaGVkX3NlZGYgKnNjaW5mbykNCit7DQorICAgIHVpbnQ2NF90IHBlcmlvZDsNCisgICAg
dWludDY0X3Qgc2xpY2U7DQorICAgIHVpbnQ2NF90IGxhdGVuY3k7DQorICAgIHVpbnQxNl90IGV4
dHJhdGltZTsNCisgICAgdWludDE2X3Qgd2VpZ2h0Ow0KKyAgICBpbnQgcmM7DQorDQorICAgIHJj
ID0geGNfc2VkZl9kb21haW5fZ2V0KGN0eC0+eGNoLCBkb21pZCwgJnBlcmlvZCwgJnNsaWNlLCAm
bGF0ZW5jeSwgJmV4dHJhdGltZSwgJndlaWdodCk7DQorICAgIGlmIChyYyAhPSAwKSB7DQorICAg
ICAgICBMSUJYTF9fTE9HX0VSUk5PKGN0eCwgTElCWExfX0xPR19FUlJPUiwgImdldHRpbmcgZG9t
YWluIHNjaGVkIHNlZGYiKTsNCisgICAgICAgIHJldHVybiBFUlJPUl9GQUlMOw0KKyAgICB9DQor
DQorICAgIHNjaW5mby0+cGVyaW9kID0gcGVyaW9kIC8gMTAwMDAwMDsNCisgICAgc2NpbmZvLT5z
bGljZSA9IHNsaWNlIC8gMTAwMDAwMDsNCisgICAgc2NpbmZvLT5sYXRlbmN5ID0gbGF0ZW5jeSAv
IDEwMDAwMDA7DQorICAgIHNjaW5mby0+ZXh0cmF0aW1lID0gZXh0cmF0aW1lOw0KKyAgICBzY2lu
Zm8tPndlaWdodCA9IHdlaWdodDsNCisNCisgICAgcmV0dXJuIDA7DQorfQ0KKw0KK2ludCBsaWJ4
bF9zY2hlZF9zZWRmX2RvbWFpbl9zZXQobGlieGxfY3R4ICpjdHgsIHVpbnQzMl90IGRvbWlkLCBs
aWJ4bF9zY2hlZF9zZWRmICpzY2luZm8pDQorew0KKyAgICB4Y19kb21haW5pbmZvX3QgZG9tYWlu
aW5mbzsNCisgICAgaW50IHJjOw0KKw0KKyAgICByYyA9IHhjX2RvbWFpbl9nZXRpbmZvbGlzdChj
dHgtPnhjaCwgZG9taWQsIDEsICZkb21haW5pbmZvKTsNCisgICAgaWYgKHJjIDwgMCkgew0KKyAg
ICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJnZXR0aW5nIGRv
bWFpbiBpbmZvIGxpc3QiKTsNCisgICAgICAgIHJldHVybiBFUlJPUl9GQUlMOw0KKyAgICB9DQor
ICAgIGlmIChyYyAhPSAxIHx8IGRvbWFpbmluZm8uZG9tYWluICE9IGRvbWlkKQ0KKyAgICAgICAg
cmV0dXJuIEVSUk9SX0lOVkFMOw0KKw0KKw0KKyAgICByYyA9IHhjX3NlZGZfZG9tYWluX3NldChj
dHgtPnhjaCwgZG9taWQsIHNjaW5mby0+cGVyaW9kICogMTAwMDAwMCwNCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2NpbmZvLT5zbGljZSAqIDEwMDAwMDAsIHNjaW5mby0+bGF0ZW5jeSAq
IDEwMDAwMDAsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNjaW5mby0+ZXh0cmF0aW1l
LCBzY2luZm8tPndlaWdodCk7DQorICAgIGlmICggcmMgPCAwICkgew0KKyAgICAgICAgTElCWExf
X0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJzZXR0aW5nIGRvbWFpbiBzY2hlZCBz
ZWRmIik7DQorICAgICAgICByZXR1cm4gRVJST1JfRkFJTDsNCisgICAgfQ0KKw0KKyAgICByZXR1
cm4gMDsNCit9DQorDQogc3RhdGljIGludCB0cmlnZ2VyX3R5cGVfZnJvbV9zdHJpbmcoY2hhciAq
dHJpZ2dlcl9uYW1lKQ0KIHsNCiAgICAgaWYgKCFzdHJjbXAodHJpZ2dlcl9uYW1lLCAibm1pIikp
DQpkaWZmIC1yIGE4MGE1NzdjMzRjYSB0b29scy9saWJ4bC9saWJ4bC5oDQotLS0gYS90b29scy9s
aWJ4bC9saWJ4bC5oCVdlZCBOb3YgMjMgMTU6MzY6MjIgMjAxMSArMDEwMA0KKysrIGIvdG9vbHMv
bGlieGwvbGlieGwuaAlXZWQgTm92IDIzIDE1OjQxOjMyIDIwMTEgKzAxMDANCkBAIC01NjcsNiAr
NTY3LDE0IEBAIGludCBsaWJ4bF9zY2hlZF9jcmVkaXRfZG9tYWluX2dldChsaWJ4bF8NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfc2NoZWRfY3JlZGl0ICpzY2luZm8p
Ow0KIGludCBsaWJ4bF9zY2hlZF9jcmVkaXRfZG9tYWluX3NldChsaWJ4bF9jdHggKmN0eCwgdWlu
dDMyX3QgZG9taWQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX3Nj
aGVkX2NyZWRpdCAqc2NpbmZvKTsNCitpbnQgbGlieGxfc2NoZWRfY3JlZGl0Ml9kb21haW5fZ2V0
KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwNCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGxpYnhsX3NjaGVkX2NyZWRpdDIgKnNjaW5mbyk7DQoraW50IGxpYnhsX3Nj
aGVkX2NyZWRpdDJfZG9tYWluX3NldChsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQsDQor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9zY2hlZF9jcmVkaXQyICpz
Y2luZm8pOw0KK2ludCBsaWJ4bF9zY2hlZF9zZWRmX2RvbWFpbl9nZXQobGlieGxfY3R4ICpjdHgs
IHVpbnQzMl90IGRvbWlkLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlieGxf
c2NoZWRfc2VkZiAqc2NpbmZvKTsNCitpbnQgbGlieGxfc2NoZWRfc2VkZl9kb21haW5fc2V0KGxp
YnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwNCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGxpYnhsX3NjaGVkX3NlZGYgKnNjaW5mbyk7DQogaW50IGxpYnhsX3NlbmRfdHJpZ2dl
cihsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQsDQogICAgICAgICAgICAgICAgICAgICAg
ICBjaGFyICp0cmlnZ2VyX25hbWUsIHVpbnQzMl90IHZjcHVpZCk7DQogaW50IGxpYnhsX3NlbmRf
c3lzcnEobGlieGxfY3R4ICpjdHgsIHVpbnQzMl90IGRvbWlkLCBjaGFyIHN5c3JxKTsNCmRpZmYg
LXIgYTgwYTU3N2MzNGNhIHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbA0KLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfdHlwZXMuaWRsCVdlZCBOb3YgMjMgMTU6MzY6MjIgMjAxMSArMDEwMA0KKysr
IGIvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVdlZCBOb3YgMjMgMTU6NDE6MzIgMjAxMSAr
MDEwMA0KQEAgLTEwOSw2ICsxMDksNyBAQCBTSFVURE9XTl8qIGNvbnN0YW50LiIiIiksDQogICAg
ICgiY3B1X3RpbWUiLCAgICB1aW50NjQpLA0KICAgICAoInZjcHVfbWF4X2lkIiwgdWludDMyKSwN
CiAgICAgKCJ2Y3B1X29ubGluZSIsIHVpbnQzMiksDQorICAgICgiY3B1cG9vbCIsICAgICB1aW50
MzIpLA0KICAgICBdLCBkaXNwb3NlX2ZuPU5vbmUpDQogDQogbGlieGxfY3B1cG9vbGluZm8gPSBT
dHJ1Y3QoImNwdXBvb2xpbmZvIiwgWw0KQEAgLTM3NCwzICszNzUsMTUgQEAgbGlieGxfc2NoZWRf
Y3JlZGl0ID0gU3RydWN0KCJzY2hlZF9jcmVkaQ0KICAgICAoIndlaWdodCIsIGludGVnZXIpLA0K
ICAgICAoImNhcCIsIGludGVnZXIpLA0KICAgICBdLCBkaXNwb3NlX2ZuPU5vbmUpDQorDQorbGli
eGxfc2NoZWRfY3JlZGl0MiA9IFN0cnVjdCgic2NoZWRfY3JlZGl0MiIsIFsNCisgICAgKCJ3ZWln
aHQiLCBpbnRlZ2VyKSwNCisgICAgXSwgZGlzcG9zZV9mbj1Ob25lKQ0KKw0KK2xpYnhsX3NjaGVk
X3NlZGYgPSBTdHJ1Y3QoInNjaGVkX3NlZGYiLCBbDQorICAgICgicGVyaW9kIiwgaW50ZWdlciks
DQorICAgICgic2xpY2UiLCBpbnRlZ2VyKSwNCisgICAgKCJsYXRlbmN5IiwgaW50ZWdlciksDQor
ICAgICgiZXh0cmF0aW1lIiwgaW50ZWdlciksDQorICAgICgid2VpZ2h0IiwgaW50ZWdlciksDQor
ICAgIF0sIGRpc3Bvc2VfZm49Tm9uZSkNCmRpZmYgLXIgYTgwYTU3N2MzNGNhIHRvb2xzL2xpYnhs
L3hsLmgNCi0tLSBhL3Rvb2xzL2xpYnhsL3hsLmgJV2VkIE5vdiAyMyAxNTozNjoyMiAyMDExICsw
MTAwDQorKysgYi90b29scy9saWJ4bC94bC5oCVdlZCBOb3YgMjMgMTU6NDE6MzIgMjAxMSArMDEw
MA0KQEAgLTU1LDYgKzU1LDggQEAgaW50IG1haW5fdmNwdXNldChpbnQgYXJnYywgY2hhciAqKmFy
Z3YpOw0KIGludCBtYWluX21lbW1heChpbnQgYXJnYywgY2hhciAqKmFyZ3YpOw0KIGludCBtYWlu
X21lbXNldChpbnQgYXJnYywgY2hhciAqKmFyZ3YpOw0KIGludCBtYWluX3NjaGVkX2NyZWRpdChp
bnQgYXJnYywgY2hhciAqKmFyZ3YpOw0KK2ludCBtYWluX3NjaGVkX2NyZWRpdDIoaW50IGFyZ2Ms
IGNoYXIgKiphcmd2KTsNCitpbnQgbWFpbl9zY2hlZF9zZWRmKGludCBhcmdjLCBjaGFyICoqYXJn
dik7DQogaW50IG1haW5fZG9taWQoaW50IGFyZ2MsIGNoYXIgKiphcmd2KTsNCiBpbnQgbWFpbl9k
b21uYW1lKGludCBhcmdjLCBjaGFyICoqYXJndik7DQogaW50IG1haW5fcmVuYW1lKGludCBhcmdj
LCBjaGFyICoqYXJndik7DQpkaWZmIC1yIGE4MGE1NzdjMzRjYSB0b29scy9saWJ4bC94bF9jbWRp
bXBsLmMNCi0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgTm92IDIzIDE1OjM2OjIy
IDIwMTEgKzAxMDANCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgTm92IDIzIDE1
OjQxOjMyIDIwMTEgKzAxMDANCkBAIC0zNjk5LDI5ICszNjk5LDIwNCBAQCBzdGF0aWMgaW50IHNj
aGVkX2NyZWRpdF9kb21haW5fc2V0KA0KICAgICByZXR1cm4gcmM7DQogfQ0KIA0KLXN0YXRpYyB2
b2lkIHNjaGVkX2NyZWRpdF9kb21haW5fb3V0cHV0KA0KLSAgICBpbnQgZG9taWQsIGxpYnhsX3Nj
aGVkX2NyZWRpdCAqc2NpbmZvKQ0KK3N0YXRpYyBpbnQgc2NoZWRfY3JlZGl0X2RvbWFpbl9vdXRw
dXQoDQorICAgIGludCBkb21pZCkNCiB7DQogICAgIGNoYXIgKmRvbW5hbWU7DQorICAgIGxpYnhs
X3NjaGVkX2NyZWRpdCBzY2luZm87DQorICAgIGludCByYzsNCisNCisgICAgaWYgKGRvbWlkIDwg
MCkgew0KKyAgICAgICAgcHJpbnRmKCIlLTMzcyAlNHMgJTZzICU0c1xuIiwgIk5hbWUiLCAiSUQi
LCAiV2VpZ2h0IiwgIkNhcCIpOw0KKyAgICAgICAgcmV0dXJuIDA7DQorICAgIH0NCisgICAgcmMg
PSBzY2hlZF9jcmVkaXRfZG9tYWluX2dldChkb21pZCwgJnNjaW5mbyk7DQorICAgIGlmIChyYykN
CisgICAgICAgIHJldHVybiByYzsNCiAgICAgZG9tbmFtZSA9IGxpYnhsX2RvbWlkX3RvX25hbWUo
Y3R4LCBkb21pZCk7DQogICAgIHByaW50ZigiJS0zM3MgJTRkICU2ZCAlNGRcbiIsDQogICAgICAg
ICBkb21uYW1lLA0KICAgICAgICAgZG9taWQsDQotICAgICAgICBzY2luZm8tPndlaWdodCwNCi0g
ICAgICAgIHNjaW5mby0+Y2FwKTsNCisgICAgICAgIHNjaW5mby53ZWlnaHQsDQorICAgICAgICBz
Y2luZm8uY2FwKTsNCiAgICAgZnJlZShkb21uYW1lKTsNCisgICAgcmV0dXJuIDA7DQorfQ0KKw0K
K3N0YXRpYyBpbnQgc2NoZWRfY3JlZGl0Ml9kb21haW5fZ2V0KA0KKyAgICBpbnQgZG9taWQsIGxp
YnhsX3NjaGVkX2NyZWRpdDIgKnNjaW5mbykNCit7DQorICAgIGludCByYzsNCisNCisgICAgcmMg
PSBsaWJ4bF9zY2hlZF9jcmVkaXQyX2RvbWFpbl9nZXQoY3R4LCBkb21pZCwgc2NpbmZvKTsNCisg
ICAgaWYgKHJjKQ0KKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJsaWJ4bF9zY2hlZF9jcmVkaXQy
X2RvbWFpbl9nZXQgZmFpbGVkLlxuIik7DQorDQorICAgIHJldHVybiByYzsNCit9DQorDQorc3Rh
dGljIGludCBzY2hlZF9jcmVkaXQyX2RvbWFpbl9zZXQoDQorICAgIGludCBkb21pZCwgbGlieGxf
c2NoZWRfY3JlZGl0MiAqc2NpbmZvKQ0KK3sNCisgICAgaW50IHJjOw0KKw0KKyAgICByYyA9IGxp
YnhsX3NjaGVkX2NyZWRpdDJfZG9tYWluX3NldChjdHgsIGRvbWlkLCBzY2luZm8pOw0KKyAgICBp
ZiAocmMpDQorICAgICAgICBmcHJpbnRmKHN0ZGVyciwgImxpYnhsX3NjaGVkX2NyZWRpdDJfZG9t
YWluX3NldCBmYWlsZWQuXG4iKTsNCisNCisgICAgcmV0dXJuIHJjOw0KK30NCisNCitzdGF0aWMg
aW50IHNjaGVkX2NyZWRpdDJfZG9tYWluX291dHB1dCgNCisgICAgaW50IGRvbWlkKQ0KK3sNCisg
ICAgY2hhciAqZG9tbmFtZTsNCisgICAgbGlieGxfc2NoZWRfY3JlZGl0MiBzY2luZm87DQorICAg
IGludCByYzsNCisNCisgICAgaWYgKGRvbWlkIDwgMCkgew0KKyAgICAgICAgcHJpbnRmKCIlLTMz
cyAlNHMgJTZzXG4iLCAiTmFtZSIsICJJRCIsICJXZWlnaHQiKTsNCisgICAgICAgIHJldHVybiAw
Ow0KKyAgICB9DQorICAgIHJjID0gc2NoZWRfY3JlZGl0Ml9kb21haW5fZ2V0KGRvbWlkLCAmc2Np
bmZvKTsNCisgICAgaWYgKHJjKQ0KKyAgICAgICAgcmV0dXJuIHJjOw0KKyAgICBkb21uYW1lID0g
bGlieGxfZG9taWRfdG9fbmFtZShjdHgsIGRvbWlkKTsNCisgICAgcHJpbnRmKCIlLTMzcyAlNGQg
JTZkXG4iLA0KKyAgICAgICAgZG9tbmFtZSwNCisgICAgICAgIGRvbWlkLA0KKyAgICAgICAgc2Np
bmZvLndlaWdodCk7DQorICAgIGZyZWUoZG9tbmFtZSk7DQorICAgIHJldHVybiAwOw0KK30NCisN
CitzdGF0aWMgaW50IHNjaGVkX3NlZGZfZG9tYWluX2dldCgNCisgICAgaW50IGRvbWlkLCBsaWJ4
bF9zY2hlZF9zZWRmICpzY2luZm8pDQorew0KKyAgICBpbnQgcmM7DQorDQorICAgIHJjID0gbGli
eGxfc2NoZWRfc2VkZl9kb21haW5fZ2V0KGN0eCwgZG9taWQsIHNjaW5mbyk7DQorICAgIGlmIChy
YykNCisgICAgICAgIGZwcmludGYoc3RkZXJyLCAibGlieGxfc2NoZWRfc2VkZl9kb21haW5fZ2V0
IGZhaWxlZC5cbiIpOw0KKw0KKyAgICByZXR1cm4gcmM7DQorfQ0KKw0KK3N0YXRpYyBpbnQgc2No
ZWRfc2VkZl9kb21haW5fc2V0KA0KKyAgICBpbnQgZG9taWQsIGxpYnhsX3NjaGVkX3NlZGYgKnNj
aW5mbykNCit7DQorICAgIGludCByYzsNCisNCisgICAgcmMgPSBsaWJ4bF9zY2hlZF9zZWRmX2Rv
bWFpbl9zZXQoY3R4LCBkb21pZCwgc2NpbmZvKTsNCisgICAgaWYgKHJjKQ0KKyAgICAgICAgZnBy
aW50ZihzdGRlcnIsICJsaWJ4bF9zY2hlZF9zZWRmX2RvbWFpbl9zZXQgZmFpbGVkLlxuIik7DQor
DQorICAgIHJldHVybiByYzsNCit9DQorDQorc3RhdGljIGludCBzY2hlZF9zZWRmX2RvbWFpbl9v
dXRwdXQoDQorICAgIGludCBkb21pZCkNCit7DQorICAgIGNoYXIgKmRvbW5hbWU7DQorICAgIGxp
YnhsX3NjaGVkX3NlZGYgc2NpbmZvOw0KKyAgICBpbnQgcmM7DQorDQorICAgIGlmIChkb21pZCA8
IDApIHsNCisgICAgICAgIHByaW50ZigiJS0zM3MgJTRzICU2cyAlLTZzICU3cyAlNXMgJTZzXG4i
LCAiTmFtZSIsICJJRCIsICJQZXJpb2QiLCAiU2xpY2UiLCAiTGF0ZW5jeSIsICJFeHRyYSIsICJX
ZWlnaHQiKTsNCisgICAgICAgIHJldHVybiAwOw0KKyAgICB9DQorICAgIHJjID0gc2NoZWRfc2Vk
Zl9kb21haW5fZ2V0KGRvbWlkLCAmc2NpbmZvKTsNCisgICAgaWYgKHJjKQ0KKyAgICAgICAgcmV0
dXJuIHJjOw0KKyAgICBkb21uYW1lID0gbGlieGxfZG9taWRfdG9fbmFtZShjdHgsIGRvbWlkKTsN
CisgICAgcHJpbnRmKCIlLTMzcyAlNGQgJTZkICU2ZCAlN2QgJTVkICU2ZFxuIiwNCisgICAgICAg
IGRvbW5hbWUsDQorICAgICAgICBkb21pZCwNCisgICAgICAgIHNjaW5mby5wZXJpb2QsDQorICAg
ICAgICBzY2luZm8uc2xpY2UsDQorICAgICAgICBzY2luZm8ubGF0ZW5jeSwNCisgICAgICAgIHNj
aW5mby5leHRyYXRpbWUsDQorICAgICAgICBzY2luZm8ud2VpZ2h0KTsNCisgICAgZnJlZShkb21u
YW1lKTsNCisgICAgcmV0dXJuIDA7DQorfQ0KKw0KK3N0YXRpYyBpbnQgc2NoZWRfZG9tYWluX291
dHB1dCgNCisgICAgdWludDMyX3Qgc2NoZWQsIGludCAoKm91dHB1dCkoaW50KSwgY29uc3QgY2hh
ciAqY3B1cG9vbCkNCit7DQorICAgIGxpYnhsX2RvbWluZm8gKmluZm87DQorICAgIGxpYnhsX2Nw
dXBvb2xpbmZvICpwb29saW5mbyA9IE5VTEw7DQorICAgIHVpbnQzMl90IHBvb2xpZDsNCisgICAg
Y2hhciAqcG9vbG5hbWU7DQorICAgIGludCBuYl9kb21haW4sIG5fcG9vbHMgPSAwLCBpLCBwOw0K
KyAgICBpbnQgcmMgPSAwOw0KKw0KKyAgICBpZiAoY3B1cG9vbCkgew0KKyAgICAgICAgaWYgKGNw
dXBvb2xfcXVhbGlmaWVyX3RvX2NwdXBvb2xpZChjcHVwb29sLCAmcG9vbGlkLCBOVUxMKSB8fA0K
KyAgICAgICAgICAgICFsaWJ4bF9jcHVwb29saWRfdG9fbmFtZShjdHgsIHBvb2xpZCkpIHsNCisg
ICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgInVua25vd24gY3B1cG9vbCBcJyVzXCdcbiIsIGNw
dXBvb2wpOw0KKyAgICAgICAgICAgIHJldHVybiAtRVJST1JfRkFJTDsNCisgICAgICAgIH0NCisg
ICAgfQ0KKw0KKyAgICBpbmZvID0gbGlieGxfbGlzdF9kb21haW4oY3R4LCAmbmJfZG9tYWluKTsN
CisgICAgaWYgKCFpbmZvKSB7DQorICAgICAgICBmcHJpbnRmKHN0ZGVyciwgImxpYnhsX2RvbWFp
bl9pbmZvbGlzdCBmYWlsZWQuXG4iKTsNCisgICAgICAgIHJldHVybiAxOw0KKyAgICB9DQorICAg
IHBvb2xpbmZvID0gbGlieGxfbGlzdF9jcHVwb29sKGN0eCwgJm5fcG9vbHMpOw0KKyAgICBpZiAo
IXBvb2xpbmZvKSB7DQorICAgICAgICBmcHJpbnRmKHN0ZGVyciwgImVycm9yIGdldHRpbmcgY3B1
cG9vbCBpbmZvXG4iKTsNCisgICAgICAgIHJldHVybiAtRVJST1JfTk9NRU07DQorICAgIH0NCisN
CisgICAgZm9yIChwID0gMDsgIXJjICYmIChwIDwgbl9wb29scyk7IHArKykgew0KKyAgICAgICAg
aWYgKChwb29saW5mb1twXS5zY2hlZF9pZCAhPSBzY2hlZCkgfHwNCisgICAgICAgICAgICAoY3B1
cG9vbCAmJiAocG9vbGlkICE9IHBvb2xpbmZvW3BdLnBvb2xpZCkpKQ0KKyAgICAgICAgICAgIGNv
bnRpbnVlOw0KKw0KKyAgICAgICAgcG9vbG5hbWUgPSBsaWJ4bF9jcHVwb29saWRfdG9fbmFtZShj
dHgsIHBvb2xpbmZvW3BdLnBvb2xpZCk7DQorICAgICAgICBwcmludGYoIkNwdXBvb2wgJXM6XG4i
LCBwb29sbmFtZSk7DQorICAgICAgICBmcmVlKHBvb2xuYW1lKTsNCisNCisgICAgICAgIG91dHB1
dCgtMSk7DQorICAgICAgICBmb3IgKGkgPSAwOyBpIDwgbmJfZG9tYWluOyBpKyspIHsNCisgICAg
ICAgICAgICBpZiAoaW5mb1tpXS5jcHVwb29sICE9IHBvb2xpbmZvW3BdLnBvb2xpZCkNCisgICAg
ICAgICAgICAgICAgY29udGludWU7DQorICAgICAgICAgICAgcmMgPSBvdXRwdXQoaW5mb1tpXS5k
b21pZCk7DQorICAgICAgICAgICAgaWYgKHJjKQ0KKyAgICAgICAgICAgICAgICBicmVhazsNCisg
ICAgICAgIH0NCisgICAgfQ0KKyAgICBpZiAocG9vbGluZm8pIHsNCisgICAgICAgIGZvciAocCA9
IDA7IHAgPCBuX3Bvb2xzOyBwKyspIHsNCisgICAgICAgICAgICBsaWJ4bF9jcHVwb29saW5mb19k
aXNwb3NlKHBvb2xpbmZvICsgcCk7DQorICAgICAgICB9DQorICAgIH0NCisgICAgcmV0dXJuIDA7
DQogfQ0KIA0KIGludCBtYWluX3NjaGVkX2NyZWRpdChpbnQgYXJnYywgY2hhciAqKmFyZ3YpDQog
ew0KLSAgICBsaWJ4bF9kb21pbmZvICppbmZvOw0KICAgICBsaWJ4bF9zY2hlZF9jcmVkaXQgc2Np
bmZvOw0KLSAgICBpbnQgbmJfZG9tYWluLCBpOw0KICAgICBjb25zdCBjaGFyICpkb20gPSBOVUxM
Ow0KKyAgICBjb25zdCBjaGFyICpjcHVwb29sID0gTlVMTDsNCiAgICAgaW50IHdlaWdodCA9IDI1
NiwgY2FwID0gMCwgb3B0X3cgPSAwLCBvcHRfYyA9IDA7DQogICAgIGludCBvcHQsIHJjOw0KLQ0K
LSAgICB3aGlsZSAoKG9wdCA9IGRlZl9nZXRvcHQoYXJnYywgYXJndiwgImQ6dzpjOiIsICJzY2hl
ZC1jcmVkaXQiLCAwKSkgIT0gLTEpIHsNCisgICAgaW50IG9wdGlvbl9pbmRleCA9IDA7DQorICAg
IHN0YXRpYyBzdHJ1Y3Qgb3B0aW9uIGxvbmdfb3B0aW9uc1tdID0gew0KKyAgICAgICAgeyJkb21h
aW4iLCAxLCAwLCAnZCd9LA0KKyAgICAgICAgeyJ3ZWlnaHQiLCAxLCAwLCAndyd9LA0KKyAgICAg
ICAgeyJjYXAiLCAxLCAwLCAnYyd9LA0KKyAgICAgICAgeyJjcHVwb29sIiwgMSwgMCwgJ3AnfSwN
CisgICAgICAgIHsiaGVscCIsIDAsIDAsICdoJ30sDQorICAgICAgICB7MCwgMCwgMCwgMH0NCisg
ICAgfTsNCisNCisgICAgd2hpbGUgKDEpIHsNCisgICAgICAgIG9wdCA9IGdldG9wdF9sb25nKGFy
Z2MsIGFyZ3YsICJkOnc6YzpwOmgiLCBsb25nX29wdGlvbnMsICZvcHRpb25faW5kZXgpOw0KKyAg
ICAgICAgaWYgKG9wdCA9PSAtMSkNCisgICAgICAgICAgICBicmVhazsNCiAgICAgICAgIHN3aXRj
aCAob3B0KSB7DQogICAgICAgICBjYXNlIDA6IGNhc2UgMjoNCiAgICAgICAgICAgICByZXR1cm4g
b3B0Ow0KQEAgLTM3MzYsMjggKzM5MTEsMjYgQEAgaW50IG1haW5fc2NoZWRfY3JlZGl0KGludCBh
cmdjLCBjaGFyICoqYQ0KICAgICAgICAgICAgIGNhcCA9IHN0cnRvbChvcHRhcmcsIE5VTEwsIDEw
KTsNCiAgICAgICAgICAgICBvcHRfYyA9IDE7DQogICAgICAgICAgICAgYnJlYWs7DQorICAgICAg
ICBjYXNlICdwJzoNCisgICAgICAgICAgICBjcHVwb29sID0gb3B0YXJnOw0KKyAgICAgICAgICAg
IGJyZWFrOw0KKyAgICAgICAgY2FzZSAnaCc6DQorICAgICAgICAgICAgaGVscCgic2NoZWQtY3Jl
ZGl0Iik7DQorICAgICAgICAgICAgcmV0dXJuIDA7DQogICAgICAgICB9DQogICAgIH0NCiANCisg
ICAgaWYgKGNwdXBvb2wgJiYgKGRvbSB8fCBvcHRfdyB8fCBvcHRfYykpIHsNCisgICAgICAgIGZw
cmludGYoc3RkZXJyLCAiU3BlY2lmeWluZyBhIGNwdXBvb2wgaXMgbm90IGFsbG93ZWQgd2l0aCBv
dGhlciBvcHRpb25zLlxuIik7DQorICAgICAgICByZXR1cm4gMTsNCisgICAgfQ0KICAgICBpZiAo
IWRvbSAmJiAob3B0X3cgfHwgb3B0X2MpKSB7DQogICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIk11
c3Qgc3BlY2lmeSBhIGRvbWFpbi5cbiIpOw0KICAgICAgICAgcmV0dXJuIDE7DQogICAgIH0NCiAN
CiAgICAgaWYgKCFkb20pIHsgLyogbGlzdCBhbGwgZG9tYWluJ3MgY3JlZGl0IHNjaGVkdWxlciBp
bmZvICovDQotICAgICAgICBpbmZvID0gbGlieGxfbGlzdF9kb21haW4oY3R4LCAmbmJfZG9tYWlu
KTsNCi0gICAgICAgIGlmICghaW5mbykgew0KLSAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAi
bGlieGxfZG9tYWluX2luZm9saXN0IGZhaWxlZC5cbiIpOw0KLSAgICAgICAgICAgIHJldHVybiAx
Ow0KLSAgICAgICAgfQ0KLQ0KLSAgICAgICAgcHJpbnRmKCIlLTMzcyAlNHMgJTZzICU0c1xuIiwg
Ik5hbWUiLCAiSUQiLCAiV2VpZ2h0IiwgIkNhcCIpOw0KLSAgICAgICAgZm9yIChpID0gMDsgaSA8
IG5iX2RvbWFpbjsgaSsrKSB7DQotICAgICAgICAgICAgcmMgPSBzY2hlZF9jcmVkaXRfZG9tYWlu
X2dldChpbmZvW2ldLmRvbWlkLCAmc2NpbmZvKTsNCi0gICAgICAgICAgICBpZiAocmMpDQotICAg
ICAgICAgICAgICAgIHJldHVybiAtcmM7DQotICAgICAgICAgICAgc2NoZWRfY3JlZGl0X2RvbWFp
bl9vdXRwdXQoaW5mb1tpXS5kb21pZCwgJnNjaW5mbyk7DQotICAgICAgICB9DQorICAgICAgICBy
ZXR1cm4gLXNjaGVkX2RvbWFpbl9vdXRwdXQoWEVOX1NDSEVEVUxFUl9DUkVESVQsIHNjaGVkX2Ny
ZWRpdF9kb21haW5fb3V0cHV0LCBjcHVwb29sKTsNCiAgICAgfSBlbHNlIHsNCiAgICAgICAgIGZp
bmRfZG9tYWluKGRvbSk7DQogDQpAQCAtMzc2Niw4ICszOTM5LDggQEAgaW50IG1haW5fc2NoZWRf
Y3JlZGl0KGludCBhcmdjLCBjaGFyICoqYQ0KICAgICAgICAgICAgIHJldHVybiAtcmM7DQogDQog
ICAgICAgICBpZiAoIW9wdF93ICYmICFvcHRfYykgeyAvKiBvdXRwdXQgY3JlZGl0IHNjaGVkdWxl
ciBpbmZvICovDQotICAgICAgICAgICAgcHJpbnRmKCIlLTMzcyAlNHMgJTZzICU0c1xuIiwgIk5h
bWUiLCAiSUQiLCAiV2VpZ2h0IiwgIkNhcCIpOw0KLSAgICAgICAgICAgIHNjaGVkX2NyZWRpdF9k
b21haW5fb3V0cHV0KGRvbWlkLCAmc2NpbmZvKTsNCisgICAgICAgICAgICBzY2hlZF9jcmVkaXRf
ZG9tYWluX291dHB1dCgtMSk7DQorICAgICAgICAgICAgcmV0dXJuIC1zY2hlZF9jcmVkaXRfZG9t
YWluX291dHB1dChkb21pZCk7DQogICAgICAgICB9IGVsc2UgeyAvKiBzZXQgY3JlZGl0IHNjaGVk
dWxlciBwYXJhbWF0ZXJzICovDQogICAgICAgICAgICAgaWYgKG9wdF93KQ0KICAgICAgICAgICAg
ICAgICBzY2luZm8ud2VpZ2h0ID0gd2VpZ2h0Ow0KQEAgLTM3ODIsNiArMzk1NSwxOTEgQEAgaW50
IG1haW5fc2NoZWRfY3JlZGl0KGludCBhcmdjLCBjaGFyICoqYQ0KICAgICByZXR1cm4gMDsNCiB9
DQogDQoraW50IG1haW5fc2NoZWRfY3JlZGl0MihpbnQgYXJnYywgY2hhciAqKmFyZ3YpDQorew0K
KyAgICBsaWJ4bF9zY2hlZF9jcmVkaXQyIHNjaW5mbzsNCisgICAgY29uc3QgY2hhciAqZG9tID0g
TlVMTDsNCisgICAgY29uc3QgY2hhciAqY3B1cG9vbCA9IE5VTEw7DQorICAgIGludCB3ZWlnaHQg
PSAyNTYsIG9wdF93ID0gMDsNCisgICAgaW50IG9wdCwgcmM7DQorICAgIGludCBvcHRpb25faW5k
ZXggPSAwOw0KKyAgICBzdGF0aWMgc3RydWN0IG9wdGlvbiBsb25nX29wdGlvbnNbXSA9IHsNCisg
ICAgICAgIHsiZG9tYWluIiwgMSwgMCwgJ2QnfSwNCisgICAgICAgIHsid2VpZ2h0IiwgMSwgMCwg
J3cnfSwNCisgICAgICAgIHsiY3B1cG9vbCIsIDEsIDAsICdwJ30sDQorICAgICAgICB7ImhlbHAi
LCAwLCAwLCAnaCd9LA0KKyAgICAgICAgezAsIDAsIDAsIDB9DQorICAgIH07DQorDQorICAgIHdo
aWxlICgxKSB7DQorICAgICAgICBvcHQgPSBnZXRvcHRfbG9uZyhhcmdjLCBhcmd2LCAiZDp3OnA6
aCIsIGxvbmdfb3B0aW9ucywgJm9wdGlvbl9pbmRleCk7DQorICAgICAgICBpZiAob3B0ID09IC0x
KQ0KKyAgICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgc3dpdGNoIChvcHQpIHsNCisgICAgICAg
IGNhc2UgMDogY2FzZSAyOg0KKyAgICAgICAgICAgIHJldHVybiBvcHQ7DQorICAgICAgICBjYXNl
ICdkJzoNCisgICAgICAgICAgICBkb20gPSBvcHRhcmc7DQorICAgICAgICAgICAgYnJlYWs7DQor
ICAgICAgICBjYXNlICd3JzoNCisgICAgICAgICAgICB3ZWlnaHQgPSBzdHJ0b2wob3B0YXJnLCBO
VUxMLCAxMCk7DQorICAgICAgICAgICAgb3B0X3cgPSAxOw0KKyAgICAgICAgICAgIGJyZWFrOw0K
KyAgICAgICAgY2FzZSAncCc6DQorICAgICAgICAgICAgY3B1cG9vbCA9IG9wdGFyZzsNCisgICAg
ICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgJ2gnOg0KKyAgICAgICAgICAgIGhlbHAoInNj
aGVkLWNyZWRpdCIpOw0KKyAgICAgICAgICAgIHJldHVybiAwOw0KKyAgICAgICAgfQ0KKyAgICB9
DQorDQorICAgIGlmIChjcHVwb29sICYmIChkb20gfHwgb3B0X3cpKSB7DQorICAgICAgICBmcHJp
bnRmKHN0ZGVyciwgIlNwZWNpZnlpbmcgYSBjcHVwb29sIGlzIG5vdCBhbGxvd2VkIHdpdGggb3Ro
ZXIgb3B0aW9ucy5cbiIpOw0KKyAgICAgICAgcmV0dXJuIDE7DQorICAgIH0NCisgICAgaWYgKCFk
b20gJiYgb3B0X3cpIHsNCisgICAgICAgIGZwcmludGYoc3RkZXJyLCAiTXVzdCBzcGVjaWZ5IGEg
ZG9tYWluLlxuIik7DQorICAgICAgICByZXR1cm4gMTsNCisgICAgfQ0KKw0KKyAgICBpZiAoIWRv
bSkgeyAvKiBsaXN0IGFsbCBkb21haW4ncyBjcmVkaXQgc2NoZWR1bGVyIGluZm8gKi8NCisgICAg
ICAgIHJldHVybiAtc2NoZWRfZG9tYWluX291dHB1dChYRU5fU0NIRURVTEVSX0NSRURJVDIsIHNj
aGVkX2NyZWRpdDJfZG9tYWluX291dHB1dCwgY3B1cG9vbCk7DQorICAgIH0gZWxzZSB7DQorICAg
ICAgICBmaW5kX2RvbWFpbihkb20pOw0KKw0KKyAgICAgICAgcmMgPSBzY2hlZF9jcmVkaXQyX2Rv
bWFpbl9nZXQoZG9taWQsICZzY2luZm8pOw0KKyAgICAgICAgaWYgKHJjKQ0KKyAgICAgICAgICAg
IHJldHVybiAtcmM7DQorDQorICAgICAgICBpZiAoIW9wdF93KSB7IC8qIG91dHB1dCBjcmVkaXQy
IHNjaGVkdWxlciBpbmZvICovDQorICAgICAgICAgICAgc2NoZWRfY3JlZGl0Ml9kb21haW5fb3V0
cHV0KC0xKTsNCisgICAgICAgICAgICByZXR1cm4gLXNjaGVkX2NyZWRpdDJfZG9tYWluX291dHB1
dChkb21pZCk7DQorICAgICAgICB9IGVsc2UgeyAvKiBzZXQgY3JlZGl0MiBzY2hlZHVsZXIgcGFy
YW1hdGVycyAqLw0KKyAgICAgICAgICAgIGlmIChvcHRfdykNCisgICAgICAgICAgICAgICAgc2Np
bmZvLndlaWdodCA9IHdlaWdodDsNCisgICAgICAgICAgICByYyA9IHNjaGVkX2NyZWRpdDJfZG9t
YWluX3NldChkb21pZCwgJnNjaW5mbyk7DQorICAgICAgICAgICAgaWYgKHJjKQ0KKyAgICAgICAg
ICAgICAgICByZXR1cm4gLXJjOw0KKyAgICAgICAgfQ0KKyAgICB9DQorDQorICAgIHJldHVybiAw
Ow0KK30NCisNCitpbnQgbWFpbl9zY2hlZF9zZWRmKGludCBhcmdjLCBjaGFyICoqYXJndikNCit7
DQorICAgIGxpYnhsX3NjaGVkX3NlZGYgc2NpbmZvOw0KKyAgICBjb25zdCBjaGFyICpkb20gPSBO
VUxMOw0KKyAgICBjb25zdCBjaGFyICpjcHVwb29sID0gTlVMTDsNCisgICAgaW50IHBlcmlvZCA9
IDAsIG9wdF9wID0gMDsNCisgICAgaW50IHNsaWNlID0gMCwgb3B0X3MgPSAwOw0KKyAgICBpbnQg
bGF0ZW5jeSA9IDAsIG9wdF9sID0gMDsNCisgICAgaW50IGV4dHJhID0gMCwgb3B0X2UgPSAwOw0K
KyAgICBpbnQgd2VpZ2h0ID0gMCwgb3B0X3cgPSAwOw0KKyAgICBpbnQgb3B0LCByYzsNCisgICAg
aW50IG9wdGlvbl9pbmRleCA9IDA7DQorICAgIHN0YXRpYyBzdHJ1Y3Qgb3B0aW9uIGxvbmdfb3B0
aW9uc1tdID0gew0KKyAgICAgICAgeyJwZXJpb2QiLCAxLCAwLCAncCd9LA0KKyAgICAgICAgeyJz
bGljZSIsIDEsIDAsICdzJ30sDQorICAgICAgICB7ImxhdGVuY3kiLCAxLCAwLCAnbCd9LA0KKyAg
ICAgICAgeyJleHRyYSIsIDEsIDAsICdlJ30sDQorICAgICAgICB7IndlaWdodCIsIDEsIDAsICd3
J30sDQorICAgICAgICB7ImNwdXBvb2wiLCAxLCAwLCAnYyd9LA0KKyAgICAgICAgeyJoZWxwIiwg
MCwgMCwgJ2gnfSwNCisgICAgICAgIHswLCAwLCAwLCAwfQ0KKyAgICB9Ow0KKw0KKyAgICB3aGls
ZSAoMSkgew0KKyAgICAgICAgb3B0ID0gZ2V0b3B0X2xvbmcoYXJnYywgYXJndiwgImQ6cDpzOmw6
ZTp3OmM6aCIsIGxvbmdfb3B0aW9ucywgJm9wdGlvbl9pbmRleCk7DQorICAgICAgICBpZiAob3B0
ID09IC0xKQ0KKyAgICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgc3dpdGNoIChvcHQpIHsNCisg
ICAgICAgIGNhc2UgMDogY2FzZSAyOg0KKyAgICAgICAgICAgIHJldHVybiBvcHQ7DQorICAgICAg
ICBjYXNlICdkJzoNCisgICAgICAgICAgICBkb20gPSBvcHRhcmc7DQorICAgICAgICAgICAgYnJl
YWs7DQorICAgICAgICBjYXNlICdwJzoNCisgICAgICAgICAgICBwZXJpb2QgPSBzdHJ0b2wob3B0
YXJnLCBOVUxMLCAxMCk7DQorICAgICAgICAgICAgb3B0X3AgPSAxOw0KKyAgICAgICAgICAgIGJy
ZWFrOw0KKyAgICAgICAgY2FzZSAncyc6DQorICAgICAgICAgICAgc2xpY2UgPSBzdHJ0b2wob3B0
YXJnLCBOVUxMLCAxMCk7DQorICAgICAgICAgICAgb3B0X3MgPSAxOw0KKyAgICAgICAgICAgIGJy
ZWFrOw0KKyAgICAgICAgY2FzZSAnbCc6DQorICAgICAgICAgICAgbGF0ZW5jeSA9IHN0cnRvbChv
cHRhcmcsIE5VTEwsIDEwKTsNCisgICAgICAgICAgICBvcHRfbCA9IDE7DQorICAgICAgICAgICAg
YnJlYWs7DQorICAgICAgICBjYXNlICdlJzoNCisgICAgICAgICAgICBleHRyYSA9IHN0cnRvbChv
cHRhcmcsIE5VTEwsIDEwKTsNCisgICAgICAgICAgICBvcHRfZSA9IDE7DQorICAgICAgICAgICAg
YnJlYWs7DQorICAgICAgICBjYXNlICd3JzoNCisgICAgICAgICAgICB3ZWlnaHQgPSBzdHJ0b2wo
b3B0YXJnLCBOVUxMLCAxMCk7DQorICAgICAgICAgICAgb3B0X3cgPSAxOw0KKyAgICAgICAgICAg
IGJyZWFrOw0KKyAgICAgICAgY2FzZSAnYyc6DQorICAgICAgICAgICAgY3B1cG9vbCA9IG9wdGFy
ZzsNCisgICAgICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgJ2gnOg0KKyAgICAgICAgICAg
IGhlbHAoInNjaGVkLXNlZGYiKTsNCisgICAgICAgICAgICByZXR1cm4gMDsNCisgICAgICAgIH0N
CisgICAgfQ0KKw0KKyAgICBpZiAoY3B1cG9vbCAmJiAoZG9tIHx8IG9wdF9wIHx8IG9wdF9zIHx8
IG9wdF9sIHx8IG9wdF9lIHx8IG9wdF93KSkgew0KKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJT
cGVjaWZ5aW5nIGEgY3B1cG9vbCBpcyBub3QgYWxsb3dlZCB3aXRoIG90aGVyIG9wdGlvbnMuXG4i
KTsNCisgICAgICAgIHJldHVybiAxOw0KKyAgICB9DQorICAgIGlmICghZG9tICYmIChvcHRfcCB8
fCBvcHRfcyB8fCBvcHRfbCB8fCBvcHRfZSB8fCBvcHRfdykpIHsNCisgICAgICAgIGZwcmludGYo
c3RkZXJyLCAiTXVzdCBzcGVjaWZ5IGEgZG9tYWluLlxuIik7DQorICAgICAgICByZXR1cm4gMTsN
CisgICAgfQ0KKyAgICBpZiAob3B0X3cgJiYgKG9wdF9wIHx8IG9wdF9zKSkgew0KKyAgICAgICAg
ZnByaW50ZihzdGRlcnIsICJTcGVjaWZ5aW5nIGEgd2VpZ2h0IEFORCBwZXJpb2Qgb3Igc2xpY2Ug
aXMgbm90IGFsbG93ZWQuXG4iKTsNCisgICAgfQ0KKw0KKyAgICBpZiAoIWRvbSkgeyAvKiBsaXN0
IGFsbCBkb21haW4ncyBjcmVkaXQgc2NoZWR1bGVyIGluZm8gKi8NCisgICAgICAgIHJldHVybiAt
c2NoZWRfZG9tYWluX291dHB1dChYRU5fU0NIRURVTEVSX1NFREYsIHNjaGVkX3NlZGZfZG9tYWlu
X291dHB1dCwgY3B1cG9vbCk7DQorICAgIH0gZWxzZSB7DQorICAgICAgICBmaW5kX2RvbWFpbihk
b20pOw0KKw0KKyAgICAgICAgcmMgPSBzY2hlZF9zZWRmX2RvbWFpbl9nZXQoZG9taWQsICZzY2lu
Zm8pOw0KKyAgICAgICAgaWYgKHJjKQ0KKyAgICAgICAgICAgIHJldHVybiAtcmM7DQorDQorICAg
ICAgICBpZiAoIW9wdF9wICYmICFvcHRfcyAmJiAhb3B0X2wgJiYgIW9wdF9lICYmICFvcHRfdykg
eyAvKiBvdXRwdXQgc2VkZiBzY2hlZHVsZXIgaW5mbyAqLw0KKyAgICAgICAgICAgIHNjaGVkX3Nl
ZGZfZG9tYWluX291dHB1dCgtMSk7DQorICAgICAgICAgICAgcmV0dXJuIC1zY2hlZF9zZWRmX2Rv
bWFpbl9vdXRwdXQoZG9taWQpOw0KKyAgICAgICAgfSBlbHNlIHsgLyogc2V0IHNlZGYgc2NoZWR1
bGVyIHBhcmFtYXRlcnMgKi8NCisgICAgICAgICAgICBpZiAob3B0X3ApIHsNCisgICAgICAgICAg
ICAgICAgc2NpbmZvLnBlcmlvZCA9IHBlcmlvZDsNCisgICAgICAgICAgICAgICAgc2NpbmZvLndl
aWdodCA9IDA7DQorICAgICAgICAgICAgfQ0KKyAgICAgICAgICAgIGlmIChvcHRfcykgew0KKyAg
ICAgICAgICAgICAgICBzY2luZm8uc2xpY2UgPSBzbGljZTsNCisgICAgICAgICAgICAgICAgc2Np
bmZvLndlaWdodCA9IDA7DQorICAgICAgICAgICAgfQ0KKyAgICAgICAgICAgIGlmIChvcHRfbCkN
CisgICAgICAgICAgICAgICAgc2NpbmZvLmxhdGVuY3kgPSBsYXRlbmN5Ow0KKyAgICAgICAgICAg
IGlmIChvcHRfZSkNCisgICAgICAgICAgICAgICAgc2NpbmZvLmV4dHJhdGltZSA9IGV4dHJhOw0K
KyAgICAgICAgICAgIGlmIChvcHRfdykgew0KKyAgICAgICAgICAgICAgICBzY2luZm8ud2VpZ2h0
ID0gd2VpZ2h0Ow0KKyAgICAgICAgICAgICAgICBzY2luZm8ucGVyaW9kID0gMDsNCisgICAgICAg
ICAgICAgICAgc2NpbmZvLnNsaWNlID0gMDsNCisgICAgICAgICAgICB9DQorICAgICAgICAgICAg
cmMgPSBzY2hlZF9zZWRmX2RvbWFpbl9zZXQoZG9taWQsICZzY2luZm8pOw0KKyAgICAgICAgICAg
IGlmIChyYykNCisgICAgICAgICAgICAgICAgcmV0dXJuIC1yYzsNCisgICAgICAgIH0NCisgICAg
fQ0KKw0KKyAgICByZXR1cm4gMDsNCit9DQorDQogaW50IG1haW5fZG9taWQoaW50IGFyZ2MsIGNo
YXIgKiphcmd2KQ0KIHsNCiAgICAgaW50IG9wdDsNCmRpZmYgLXIgYTgwYTU3N2MzNGNhIHRvb2xz
L2xpYnhsL3hsX2NtZHRhYmxlLmMNCi0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZHRhYmxlLmMJV2Vk
IE5vdiAyMyAxNTozNjoyMiAyMDExICswMTAwDQorKysgYi90b29scy9saWJ4bC94bF9jbWR0YWJs
ZS5jCVdlZCBOb3YgMjMgMTU6NDE6MzIgMjAxMSArMDEwMA0KQEAgLTE5MiwxMCArMTkyLDM1IEBA
IHN0cnVjdCBjbWRfc3BlYyBjbWRfdGFibGVbXSA9IHsNCiAgICAgeyAic2NoZWQtY3JlZGl0IiwN
CiAgICAgICAmbWFpbl9zY2hlZF9jcmVkaXQsIDAsDQogICAgICAgIkdldC9zZXQgY3JlZGl0IHNj
aGVkdWxlciBwYXJhbWV0ZXJzIiwNCi0gICAgICAiWy1kIDxEb21haW4+IFstd1s9V0VJR0hUXXwt
Y1s9Q0FQXV1dIiwNCisgICAgICAiWy1kIDxEb21haW4+IFstd1s9V0VJR0hUXXwtY1s9Q0FQXV1d
IFstcCBDUFVQT09MXSIsDQogICAgICAgIi1kIERPTUFJTiwgLS1kb21haW49RE9NQUlOICAgICBE
b21haW4gdG8gbW9kaWZ5XG4iDQogICAgICAgIi13IFdFSUdIVCwgLS13ZWlnaHQ9V0VJR0hUICAg
ICBXZWlnaHQgKGludClcbiINCi0gICAgICAiLWMgQ0FQLCAtLWNhcD1DQVAgICAgICAgICAgICAg
IENhcCAoaW50KSINCisgICAgICAiLWMgQ0FQLCAtLWNhcD1DQVAgICAgICAgICAgICAgIENhcCAo
aW50KVxuIg0KKyAgICAgICItcCBDUFVQT09MLCAtLWNwdXBvb2w9Q1BVUE9PTCAgUmVzdHJpY3Qg
b3V0cHV0IHRvIENQVVBPT0wiDQorICAgIH0sDQorICAgIHsgInNjaGVkLWNyZWRpdDIiLA0KKyAg
ICAgICZtYWluX3NjaGVkX2NyZWRpdDIsIDAsDQorICAgICAgIkdldC9zZXQgY3JlZGl0MiBzY2hl
ZHVsZXIgcGFyYW1ldGVycyIsDQorICAgICAgIlstZCA8RG9tYWluPiBbLXdbPVdFSUdIVF1dXSBb
LXAgQ1BVUE9PTF0iLA0KKyAgICAgICItZCBET01BSU4sIC0tZG9tYWluPURPTUFJTiAgICAgRG9t
YWluIHRvIG1vZGlmeVxuIg0KKyAgICAgICItdyBXRUlHSFQsIC0td2VpZ2h0PVdFSUdIVCAgICAg
V2VpZ2h0IChpbnQpXG4iDQorICAgICAgIi1wIENQVVBPT0wsIC0tY3B1cG9vbD1DUFVQT09MICBS
ZXN0cmljdCBvdXRwdXQgdG8gQ1BVUE9PTCINCisgICAgfSwNCisgICAgeyAic2NoZWQtc2VkZiIs
DQorICAgICAgJm1haW5fc2NoZWRfc2VkZiwgMCwNCisgICAgICAiR2V0L3NldCBzZWRmIHNjaGVk
dWxlciBwYXJhbWV0ZXJzIiwNCisgICAgICAiW29wdGlvbnNdIiwNCisgICAgICAiLWQgRE9NQUlO
LCAtLWRvbWFpbj1ET01BSU4gICAgIERvbWFpbiB0byBtb2RpZnlcbiINCisgICAgICAiLXAgTVMs
IC0tcGVyaW9kPU1TICAgICAgICAgICAgIFJlbGF0aXZlIGRlYWRsaW5lKG1zKVxuIg0KKyAgICAg
ICItcyBNUywgLS1zbGljZT1NUyAgICAgICAgICAgICAgV29yc3QtY2FzZSBleGVjdXRpb24gdGlt
ZShtcykuIChzbGljZSA8XG4iDQorICAgICAgIiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBwZXJpb2QpXG4iDQorICAgICAgIi1sIE1TLCAtLWxhdGVuY3k9TVMgICAgICAgICAgICBTY2Fs
ZWQgcGVyaW9kIChtcykgd2hlbiBkb21haW4gcGVyZm9ybXNcbiINCisgICAgICAiICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGhlYXZ5IEkvT1xuIg0KKyAgICAgICItZSBGTEFHLCAtLWV4
dHJhPUZMQUcgICAgICAgICAgRmxhZyAoMCBvciAxKSBjb250cm9scyBpZiBkb21haW4gY2FuIHJ1
blxuIg0KKyAgICAgICIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW4gZXh0cmEgdGlt
ZVxuIg0KKyAgICAgICItdyBGTE9BVCwgLS13ZWlnaHQ9RkxPQVQgICAgICAgQ1BVIFBlcmlvZC9z
bGljZSAoZG8gbm90IHNldCB3aXRoXG4iDQorICAgICAgIiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAtLXBlcmlvZC8tLXNsaWNlKVxuIg0KKyAgICAgICItYyBDUFVQT09MLCAtLWNwdXBv
b2w9Q1BVUE9PTCAgUmVzdHJpY3Qgb3V0cHV0IHRvIENQVVBPT0wiDQogICAgIH0sDQogICAgIHsg
ImRvbWlkIiwNCiAgICAgICAmbWFpbl9kb21pZCwgMCwNCi==


--=-X2L9tkRP5oeRl7Vc+sn5--

--=-isU7WgRQ2IUCWmmUijnl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7NCWMACgkQk4XaBE3IOsQbhgCfU96ZxGpCgkuDjKnBpb+ah8o9
DBkAoKgN0r90vCq9UGjh9OaZAwZ/RGZ0
=NgwM
-----END PGP SIGNATURE-----

--=-isU7WgRQ2IUCWmmUijnl--



--===============3623433031883149479==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3623433031883149479==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 14:56:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 14:56:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTEFA-0007St-4D; Wed, 23 Nov 2011 14:56:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTEF9-0007Sn-1L
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 14:56:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322060026!45508403!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3994 invoked from network); 23 Nov 2011 14:53:46 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 14:53:46 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73385261; Wed, 23 Nov 2011 15:55:39 +0100
Message-ID: <1322060131.30168.15.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 15:55:31 +0100
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [RFC/RFT][PATCH 0 of 3] rework locking in sched_adjust
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3623433031883149479=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3623433031883149479==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-isU7WgRQ2IUCWmmUijnl"


--=-isU7WgRQ2IUCWmmUijnl
Content-Type: multipart/mixed; boundary="=-X2L9tkRP5oeRl7Vc+sn5"


--=-X2L9tkRP5oeRl7Vc+sn5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

This series changes how locks are dealt with while adjusting domains'
scheduling parameters.

I've done and am still doing tests for credit and credit2, and it's
surviving to all I threw at it up to now. Unfortunately, I can't test
the sedf part yet, since it is not working on my test boxes due to other
issues (which I'm also trying to track down). I'm sending the series out
anyway, so that at least you can have a look at it, and maybe give a
spin on the sedf part, if you don't have anything more interesting to
do. ;-P

Juergen series on xl scheduling support attached to this mail, in the
form of a single patch, for testing convenience.

--

xen/common/sched_credit.c  |   10 +++++++---
xen/common/sched_credit2.c |   21 +++++++++++----------
xen/common/sched_sedf.c    |  131 +++++++++++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------=
---------------
xen/common/schedule.c      |   34 ++--------------------------------
4 files changed, 130 insertions(+), 66 deletions(-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-X2L9tkRP5oeRl7Vc+sn5
Content-Disposition: attachment; filename="update-xl-sched-interface-from-Juergen.patch"
Content-Type: text/x-patch; name="update-xl-sched-interface-from-Juergen.patch";
	charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGE4MGE1NzdjMzRjYTQyMWZlOTcxNDFlZWUz
MjlmYjE0YjEwMGZhYTINCkltcHJvdmVkIHhsIHNjaGVkdWxpbmcgc3VwcG9ydCBmcm9tIEp1ZXJn
ZW4uDQoNClRoaXMgaXMgaGVyZSBhcyBhIHNpbmdsZSBwYXRjaCwganVzdCBmb3IgY29udmVuaWVu
Y2UsIGluIGNhc2UNCm9uZSB3YW50cyB0byB0ZXN0IHRoZSBzZXJpZXMuIEZvciBkZXRhaWxzIHNl
ZQ0KaHR0cDovL29zZGlyLmNvbS9tbC94ZW4tZGV2ZWxvcG1lbnQvMjAxMS0xMS9tc2cwMTA5Ny5o
dG1sIC4NCg0KZGlmZiAtciBhODBhNTc3YzM0Y2EgZG9jcy9tYW4veGwucG9kLjENCi0tLSBhL2Rv
Y3MvbWFuL3hsLnBvZC4xCVdlZCBOb3YgMjMgMTU6MzY6MjIgMjAxMSArMDEwMA0KKysrIGIvZG9j
cy9tYW4veGwucG9kLjEJV2VkIE5vdiAyMyAxNTo0MTozMiAyMDExICswMTAwDQpAQCAtNTc5LDI1
ICs1NzksMzAgQEAgZGVmYXVsdCBCPGNyZWRpdD4gaXMgdXNlZCBmb3Igc2NoZWR1bGluZw0KIA0K
ID1vdmVyIDQNCiANCi09aXRlbSBCPHNjaGVkLWNyZWRpdD4gWyBCPC1kPiBJPGRvbWFpbi1pZD4g
WyBCPC13PltCPD0+STxXRUlHSFQ+XSB8IEI8LWM+W0I8PT5JPENBUD5dIF0gXQ0KKz1pdGVtIEI8
c2NoZWQtY3JlZGl0PiBbSTxPUFRJT05TPl0NCiANCi1TZXQgY3JlZGl0IHNjaGVkdWxlciBwYXJh
bWV0ZXJzLiAgVGhlIGNyZWRpdCBzY2hlZHVsZXIgaXMgYQ0KK1NldCBvciBnZXQgY3JlZGl0IHNj
aGVkdWxlciBwYXJhbWV0ZXJzLiAgVGhlIGNyZWRpdCBzY2hlZHVsZXIgaXMgYQ0KIHByb3BvcnRp
b25hbCBmYWlyIHNoYXJlIENQVSBzY2hlZHVsZXIgYnVpbHQgZnJvbSB0aGUgZ3JvdW5kIHVwIHRv
IGJlDQogd29yayBjb25zZXJ2aW5nIG9uIFNNUCBob3N0cy4NCiANCiBFYWNoIGRvbWFpbiAoaW5j
bHVkaW5nIERvbWFpbjApIGlzIGFzc2lnbmVkIGEgd2VpZ2h0IGFuZCBhIGNhcC4NCiANCi1CPFBB
UkFNRVRFUlM+DQorQjxPUFRJT05TPg0KIA0KID1vdmVyIDQNCiANCi09aXRlbSBJPFdFSUdIVD4N
Cis9aXRlbSBCPC1kIERPTUFJTj4sIEI8LS1kb21haW49RE9NQUlOPg0KKw0KK1NwZWNpZnkgZG9t
YWluIGZvciB3aGljaCBzY2hlZHVsZXIgcGFyYW1ldGVycyBhcmUgdG8gYmUgbW9kaWZpZWQgb3Ig
cmV0cmlldmVkLg0KK01hbmRhdG9yeSBmb3IgbW9kaWZ5aW5nIHNjaGVkdWxlciBwYXJhbWV0ZXJz
Lg0KKw0KKz1pdGVtIEI8LXcgV0VJR0hUPiwgQjwtLXdlaWdodD1XRUlHSFQ+DQogDQogQSBkb21h
aW4gd2l0aCBhIHdlaWdodCBvZiA1MTIgd2lsbCBnZXQgdHdpY2UgYXMgbXVjaCBDUFUgYXMgYSBk
b21haW4NCiB3aXRoIGEgd2VpZ2h0IG9mIDI1NiBvbiBhIGNvbnRlbmRlZCBob3N0LiBMZWdhbCB3
ZWlnaHRzIHJhbmdlIGZyb20gMQ0KIHRvIDY1NTM1IGFuZCB0aGUgZGVmYXVsdCBpcyAyNTYuDQog
DQotPWl0ZW0gSTxDQVA+DQorPWl0ZW0gQjwtYyBDQVA+LCBCPC0tY2FwPUNBUD4NCiANCiBUaGUg
Y2FwIG9wdGlvbmFsbHkgZml4ZXMgdGhlIG1heGltdW0gYW1vdW50IG9mIENQVSBhIGRvbWFpbiB3
aWxsIGJlDQogYWJsZSB0byBjb25zdW1lLCBldmVuIGlmIHRoZSBob3N0IHN5c3RlbSBoYXMgaWRs
ZSBDUFUgY3ljbGVzLiBUaGUgY2FwDQpAQCAtNjA1LDYgKzYxMCw4MSBAQCBpcyBleHByZXNzZWQg
aW4gcGVyY2VudGFnZSBvZiBvbmUgcGh5c2ljDQogNTAgaXMgaGFsZiBhIENQVSwgNDAwIGlzIDQg
Q1BVcywgZXRjLiBUaGUgZGVmYXVsdCwgMCwgbWVhbnMgdGhlcmUgaXMNCiBubyB1cHBlciBjYXAu
DQogDQorPWl0ZW0gQjwtcCBDUFVQT09MPiwgQjwtLWNwdXBvb2w9Q1BVUE9PTD4NCisNCitSZXN0
cmljdCBvdXRwdXQgdG8gZG9tYWlucyBpbiB0aGUgc3BlY2lmaWVkIGNwdXBvb2wuDQorDQorPWJh
Y2sNCisNCis9aXRlbSBCPHNjaGVkLWNyZWRpdDI+IFtJPE9QVElPTlM+XQ0KKw0KK1NldCBvciBn
ZXQgY3JlZGl0MiBzY2hlZHVsZXIgcGFyYW1ldGVycy4gIFRoZSBjcmVkaXQyIHNjaGVkdWxlciBp
cyBhDQorcHJvcG9ydGlvbmFsIGZhaXIgc2hhcmUgQ1BVIHNjaGVkdWxlciBidWlsdCBmcm9tIHRo
ZSBncm91bmQgdXAgdG8gYmUNCit3b3JrIGNvbnNlcnZpbmcgb24gU01QIGhvc3RzLg0KKw0KK0Vh
Y2ggZG9tYWluIChpbmNsdWRpbmcgRG9tYWluMCkgaXMgYXNzaWduZWQgYSB3ZWlnaHQuDQorDQor
QjxPUFRJT05TPg0KKw0KKz1vdmVyIDQNCisNCis9aXRlbSBCPC1kIERPTUFJTj4sIEI8LS1kb21h
aW49RE9NQUlOPg0KKw0KK1NwZWNpZnkgZG9tYWluIGZvciB3aGljaCBzY2hlZHVsZXIgcGFyYW1l
dGVycyBhcmUgdG8gYmUgbW9kaWZpZWQgb3IgcmV0cmlldmVkLg0KK01hbmRhdG9yeSBmb3IgbW9k
aWZ5aW5nIHNjaGVkdWxlciBwYXJhbWV0ZXJzLg0KKw0KKz1pdGVtIEI8LXcgV0VJR0hUPiwgQjwt
LXdlaWdodD1XRUlHSFQ+DQorDQorQSBkb21haW4gd2l0aCBhIHdlaWdodCBvZiA1MTIgd2lsbCBn
ZXQgdHdpY2UgYXMgbXVjaCBDUFUgYXMgYSBkb21haW4NCit3aXRoIGEgd2VpZ2h0IG9mIDI1NiBv
biBhIGNvbnRlbmRlZCBob3N0LiBMZWdhbCB3ZWlnaHRzIHJhbmdlIGZyb20gMQ0KK3RvIDY1NTM1
IGFuZCB0aGUgZGVmYXVsdCBpcyAyNTYuDQorDQorPWl0ZW0gQjwtcCBDUFVQT09MPiwgQjwtLWNw
dXBvb2w9Q1BVUE9PTD4NCisNCitSZXN0cmljdCBvdXRwdXQgdG8gZG9tYWlucyBpbiB0aGUgc3Bl
Y2lmaWVkIGNwdXBvb2wuDQorDQorPWJhY2sNCisNCis9aXRlbSBCPHNjaGVkLXNlZGY+IFtJPE9Q
VElPTlM+XQ0KKw0KK1NldCBvciBnZXQgU2ltcGxlIEVERiAoRWFybGllc3QgRGVhZGxpbmUgRmly
c3QpIHNjaGVkdWxlciBwYXJhbWV0ZXJzLiBUaGlzDQorc2NoZWR1bGVyIHByb3ZpZGVzIHdlaWdo
dGVkIENQVSBzaGFyaW5nIGluIGFuIGludHVpdGl2ZSB3YXkgYW5kIHVzZXMNCityZWFsdGltZS1h
bGdvcml0aG1zIHRvIGVuc3VyZSB0aW1lIGd1YXJhbnRlZXMuICBGb3IgbW9yZSBpbmZvcm1hdGlv
biBzZWUNCitkb2NzL21pc2Mvc2VkZl9zY2hlZHVsZXJfbWluaS1IT1dUTy50eHQgaW4gdGhlIFhl
biBkaXN0cmlidXRpb24uDQorDQorQjxPUFRJT05TPg0KKw0KKz1vdmVyIDQNCisNCis9aXRlbSBC
PC1kIERPTUFJTj4sIEI8LS1kb21haW49RE9NQUlOPg0KKw0KK1NwZWNpZnkgZG9tYWluIGZvciB3
aGljaCBzY2hlZHVsZXIgcGFyYW1ldGVycyBhcmUgdG8gYmUgbW9kaWZpZWQgb3IgcmV0cmlldmVk
Lg0KK01hbmRhdG9yeSBmb3IgbW9kaWZ5aW5nIHNjaGVkdWxlciBwYXJhbWV0ZXJzLg0KKw0KKz1p
dGVtIEI8LXAgUEVSSU9EPiwgQjwtLXBlcmlvZD1QRVJJT0Q+DQorDQorVGhlIG5vcm1hbCBFREYg
c2NoZWR1bGluZyB1c2FnZSBpbiBtaWxsaXNlY29uZHMuDQorDQorPWl0ZW0gQjwtcyBTTElDRT4s
IEI8LS1zbGljZT1TTElDRT4NCisNCitUaGUgbm9ybWFsIEVERiBzY2hlZHVsaW5nIHVzYWdlIGlu
IG1pbGxpc2Vjb25kcy4NCisNCis9aXRlbSBCPC1sIExBVEVOQ1k+LCBCPC0tbGF0ZW5jeT1MQVRF
TkNZPg0KKw0KK1NjYWxlZCBwZXJpb2QgaWYgZG9tYWluIGlzIGRvaW5nIGhlYXZ5IEkvTy4NCisN
Cis9aXRlbSBCPC1lIEVYVFJBPiwgQjwtLWV4dHJhPUVYVFJBPg0KKw0KK0ZsYWcgZm9yIGFsbG93
aW5nIGRvbWFpbiB0byBydW4gaW4gZXh0cmEgdGltZSAoMCBvciAxKS4NCisNCis9aXRlbSBCPC13
IFdFSUdIVD4sIEI8LS13ZWlnaHQ9V0VJR0hUPg0KKw0KK0Fub3RoZXIgd2F5IG9mIHNldHRpbmcg
Q1BVIHNsaWNlLg0KKw0KKz1pdGVtIEI8LWMgQ1BVUE9PTD4sIEI8LS1jcHVwb29sPUNQVVBPT0w+
DQorDQorUmVzdHJpY3Qgb3V0cHV0IHRvIGRvbWFpbnMgaW4gdGhlIHNwZWNpZmllZCBjcHVwb29s
Lg0KKw0KID1iYWNrDQogDQogPWJhY2sNCmRpZmYgLXIgYTgwYTU3N2MzNGNhIHRvb2xzL2xpYnhs
L2xpYnhsLmMNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsLmMJV2VkIE5vdiAyMyAxNTozNjoyMiAy
MDExICswMTAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bC5jCVdlZCBOb3YgMjMgMTU6NDE6MzIg
MjAxMSArMDEwMA0KQEAgLTM2MSw2ICszNjEsNyBAQCBzdGF0aWMgdm9pZCB4Y2luZm8yeGxpbmZv
KGNvbnN0IHhjX2RvbWFpDQogICAgIHhsaW5mby0+Y3B1X3RpbWUgPSB4Y2luZm8tPmNwdV90aW1l
Ow0KICAgICB4bGluZm8tPnZjcHVfbWF4X2lkID0geGNpbmZvLT5tYXhfdmNwdV9pZDsNCiAgICAg
eGxpbmZvLT52Y3B1X29ubGluZSA9IHhjaW5mby0+bnJfb25saW5lX3ZjcHVzOw0KKyAgICB4bGlu
Zm8tPmNwdXBvb2wgPSB4Y2luZm8tPmNwdXBvb2w7DQogfQ0KIA0KIGxpYnhsX2RvbWluZm8gKiBs
aWJ4bF9saXN0X2RvbWFpbihsaWJ4bF9jdHggKmN0eCwgaW50ICpuYl9kb21haW4pDQpAQCAtMjY3
OCw3ICsyNjc5LDcgQEAgaW50IGxpYnhsX3NjaGVkX2NyZWRpdF9kb21haW5fZ2V0KGxpYnhsXw0K
IA0KICAgICByYyA9IHhjX3NjaGVkX2NyZWRpdF9kb21haW5fZ2V0KGN0eC0+eGNoLCBkb21pZCwg
JnNkb20pOw0KICAgICBpZiAocmMgIT0gMCkgew0KLSAgICAgICAgTElCWExfX0xPR19FUlJOTyhj
dHgsIExJQlhMX19MT0dfRVJST1IsICJzZXR0aW5nIGRvbWFpbiBzY2hlZCBjcmVkaXQiKTsNCisg
ICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAiZ2V0dGluZyBk
b21haW4gc2NoZWQgY3JlZGl0Iik7DQogICAgICAgICByZXR1cm4gRVJST1JfRkFJTDsNCiAgICAg
fQ0KIA0KQEAgLTI3MjgsNiArMjcyOSwxMDMgQEAgaW50IGxpYnhsX3NjaGVkX2NyZWRpdF9kb21h
aW5fc2V0KGxpYnhsXw0KICAgICByZXR1cm4gMDsNCiB9DQogDQoraW50IGxpYnhsX3NjaGVkX2Ny
ZWRpdDJfZG9tYWluX2dldChsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQsIGxpYnhsX3Nj
aGVkX2NyZWRpdDIgKnNjaW5mbykNCit7DQorICAgIHN0cnVjdCB4ZW5fZG9tY3RsX3NjaGVkX2Ny
ZWRpdDIgc2RvbTsNCisgICAgaW50IHJjOw0KKw0KKyAgICByYyA9IHhjX3NjaGVkX2NyZWRpdDJf
ZG9tYWluX2dldChjdHgtPnhjaCwgZG9taWQsICZzZG9tKTsNCisgICAgaWYgKHJjICE9IDApIHsN
CisgICAgICAgIExJQlhMX19MT0dfRVJSTk8oY3R4LCBMSUJYTF9fTE9HX0VSUk9SLCAiZ2V0dGlu
ZyBkb21haW4gc2NoZWQgY3JlZGl0MiIpOw0KKyAgICAgICAgcmV0dXJuIEVSUk9SX0ZBSUw7DQor
ICAgIH0NCisNCisgICAgc2NpbmZvLT53ZWlnaHQgPSBzZG9tLndlaWdodDsNCisNCisgICAgcmV0
dXJuIDA7DQorfQ0KKw0KK2ludCBsaWJ4bF9zY2hlZF9jcmVkaXQyX2RvbWFpbl9zZXQobGlieGxf
Y3R4ICpjdHgsIHVpbnQzMl90IGRvbWlkLCBsaWJ4bF9zY2hlZF9jcmVkaXQyICpzY2luZm8pDQor
ew0KKyAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zY2hlZF9jcmVkaXQyIHNkb207DQorICAgIHhjX2Rv
bWFpbmluZm9fdCBkb21haW5pbmZvOw0KKyAgICBpbnQgcmM7DQorDQorICAgIHJjID0geGNfZG9t
YWluX2dldGluZm9saXN0KGN0eC0+eGNoLCBkb21pZCwgMSwgJmRvbWFpbmluZm8pOw0KKyAgICBp
ZiAocmMgPCAwKSB7DQorICAgICAgICBMSUJYTF9fTE9HX0VSUk5PKGN0eCwgTElCWExfX0xPR19F
UlJPUiwgImdldHRpbmcgZG9tYWluIGluZm8gbGlzdCIpOw0KKyAgICAgICAgcmV0dXJuIEVSUk9S
X0ZBSUw7DQorICAgIH0NCisgICAgaWYgKHJjICE9IDEgfHwgZG9tYWluaW5mby5kb21haW4gIT0g
ZG9taWQpDQorICAgICAgICByZXR1cm4gRVJST1JfSU5WQUw7DQorDQorDQorICAgIGlmIChzY2lu
Zm8tPndlaWdodCA8IDEgfHwgc2NpbmZvLT53ZWlnaHQgPiA2NTUzNSkgew0KKyAgICAgICAgTElC
WExfX0xPR19FUlJOT1ZBTChjdHgsIExJQlhMX19MT0dfRVJST1IsIHJjLA0KKyAgICAgICAgICAg
ICJDcHUgd2VpZ2h0IG91dCBvZiByYW5nZSwgdmFsaWQgdmFsdWVzIGFyZSB3aXRoaW4gcmFuZ2Ug
ZnJvbSAxIHRvIDY1NTM1Iik7DQorICAgICAgICByZXR1cm4gRVJST1JfSU5WQUw7DQorICAgIH0N
CisNCisgICAgc2RvbS53ZWlnaHQgPSBzY2luZm8tPndlaWdodDsNCisNCisgICAgcmMgPSB4Y19z
Y2hlZF9jcmVkaXQyX2RvbWFpbl9zZXQoY3R4LT54Y2gsIGRvbWlkLCAmc2RvbSk7DQorICAgIGlm
ICggcmMgPCAwICkgew0KKyAgICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0df
RVJST1IsICJzZXR0aW5nIGRvbWFpbiBzY2hlZCBjcmVkaXQyIik7DQorICAgICAgICByZXR1cm4g
RVJST1JfRkFJTDsNCisgICAgfQ0KKw0KKyAgICByZXR1cm4gMDsNCit9DQorDQoraW50IGxpYnhs
X3NjaGVkX3NlZGZfZG9tYWluX2dldChsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQsIGxp
YnhsX3NjaGVkX3NlZGYgKnNjaW5mbykNCit7DQorICAgIHVpbnQ2NF90IHBlcmlvZDsNCisgICAg
dWludDY0X3Qgc2xpY2U7DQorICAgIHVpbnQ2NF90IGxhdGVuY3k7DQorICAgIHVpbnQxNl90IGV4
dHJhdGltZTsNCisgICAgdWludDE2X3Qgd2VpZ2h0Ow0KKyAgICBpbnQgcmM7DQorDQorICAgIHJj
ID0geGNfc2VkZl9kb21haW5fZ2V0KGN0eC0+eGNoLCBkb21pZCwgJnBlcmlvZCwgJnNsaWNlLCAm
bGF0ZW5jeSwgJmV4dHJhdGltZSwgJndlaWdodCk7DQorICAgIGlmIChyYyAhPSAwKSB7DQorICAg
ICAgICBMSUJYTF9fTE9HX0VSUk5PKGN0eCwgTElCWExfX0xPR19FUlJPUiwgImdldHRpbmcgZG9t
YWluIHNjaGVkIHNlZGYiKTsNCisgICAgICAgIHJldHVybiBFUlJPUl9GQUlMOw0KKyAgICB9DQor
DQorICAgIHNjaW5mby0+cGVyaW9kID0gcGVyaW9kIC8gMTAwMDAwMDsNCisgICAgc2NpbmZvLT5z
bGljZSA9IHNsaWNlIC8gMTAwMDAwMDsNCisgICAgc2NpbmZvLT5sYXRlbmN5ID0gbGF0ZW5jeSAv
IDEwMDAwMDA7DQorICAgIHNjaW5mby0+ZXh0cmF0aW1lID0gZXh0cmF0aW1lOw0KKyAgICBzY2lu
Zm8tPndlaWdodCA9IHdlaWdodDsNCisNCisgICAgcmV0dXJuIDA7DQorfQ0KKw0KK2ludCBsaWJ4
bF9zY2hlZF9zZWRmX2RvbWFpbl9zZXQobGlieGxfY3R4ICpjdHgsIHVpbnQzMl90IGRvbWlkLCBs
aWJ4bF9zY2hlZF9zZWRmICpzY2luZm8pDQorew0KKyAgICB4Y19kb21haW5pbmZvX3QgZG9tYWlu
aW5mbzsNCisgICAgaW50IHJjOw0KKw0KKyAgICByYyA9IHhjX2RvbWFpbl9nZXRpbmZvbGlzdChj
dHgtPnhjaCwgZG9taWQsIDEsICZkb21haW5pbmZvKTsNCisgICAgaWYgKHJjIDwgMCkgew0KKyAg
ICAgICAgTElCWExfX0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJnZXR0aW5nIGRv
bWFpbiBpbmZvIGxpc3QiKTsNCisgICAgICAgIHJldHVybiBFUlJPUl9GQUlMOw0KKyAgICB9DQor
ICAgIGlmIChyYyAhPSAxIHx8IGRvbWFpbmluZm8uZG9tYWluICE9IGRvbWlkKQ0KKyAgICAgICAg
cmV0dXJuIEVSUk9SX0lOVkFMOw0KKw0KKw0KKyAgICByYyA9IHhjX3NlZGZfZG9tYWluX3NldChj
dHgtPnhjaCwgZG9taWQsIHNjaW5mby0+cGVyaW9kICogMTAwMDAwMCwNCisgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2NpbmZvLT5zbGljZSAqIDEwMDAwMDAsIHNjaW5mby0+bGF0ZW5jeSAq
IDEwMDAwMDAsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNjaW5mby0+ZXh0cmF0aW1l
LCBzY2luZm8tPndlaWdodCk7DQorICAgIGlmICggcmMgPCAwICkgew0KKyAgICAgICAgTElCWExf
X0xPR19FUlJOTyhjdHgsIExJQlhMX19MT0dfRVJST1IsICJzZXR0aW5nIGRvbWFpbiBzY2hlZCBz
ZWRmIik7DQorICAgICAgICByZXR1cm4gRVJST1JfRkFJTDsNCisgICAgfQ0KKw0KKyAgICByZXR1
cm4gMDsNCit9DQorDQogc3RhdGljIGludCB0cmlnZ2VyX3R5cGVfZnJvbV9zdHJpbmcoY2hhciAq
dHJpZ2dlcl9uYW1lKQ0KIHsNCiAgICAgaWYgKCFzdHJjbXAodHJpZ2dlcl9uYW1lLCAibm1pIikp
DQpkaWZmIC1yIGE4MGE1NzdjMzRjYSB0b29scy9saWJ4bC9saWJ4bC5oDQotLS0gYS90b29scy9s
aWJ4bC9saWJ4bC5oCVdlZCBOb3YgMjMgMTU6MzY6MjIgMjAxMSArMDEwMA0KKysrIGIvdG9vbHMv
bGlieGwvbGlieGwuaAlXZWQgTm92IDIzIDE1OjQxOjMyIDIwMTEgKzAxMDANCkBAIC01NjcsNiAr
NTY3LDE0IEBAIGludCBsaWJ4bF9zY2hlZF9jcmVkaXRfZG9tYWluX2dldChsaWJ4bF8NCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfc2NoZWRfY3JlZGl0ICpzY2luZm8p
Ow0KIGludCBsaWJ4bF9zY2hlZF9jcmVkaXRfZG9tYWluX3NldChsaWJ4bF9jdHggKmN0eCwgdWlu
dDMyX3QgZG9taWQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX3Nj
aGVkX2NyZWRpdCAqc2NpbmZvKTsNCitpbnQgbGlieGxfc2NoZWRfY3JlZGl0Ml9kb21haW5fZ2V0
KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwNCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGxpYnhsX3NjaGVkX2NyZWRpdDIgKnNjaW5mbyk7DQoraW50IGxpYnhsX3Nj
aGVkX2NyZWRpdDJfZG9tYWluX3NldChsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQsDQor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9zY2hlZF9jcmVkaXQyICpz
Y2luZm8pOw0KK2ludCBsaWJ4bF9zY2hlZF9zZWRmX2RvbWFpbl9nZXQobGlieGxfY3R4ICpjdHgs
IHVpbnQzMl90IGRvbWlkLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlieGxf
c2NoZWRfc2VkZiAqc2NpbmZvKTsNCitpbnQgbGlieGxfc2NoZWRfc2VkZl9kb21haW5fc2V0KGxp
YnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwNCisgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGxpYnhsX3NjaGVkX3NlZGYgKnNjaW5mbyk7DQogaW50IGxpYnhsX3NlbmRfdHJpZ2dl
cihsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQsDQogICAgICAgICAgICAgICAgICAgICAg
ICBjaGFyICp0cmlnZ2VyX25hbWUsIHVpbnQzMl90IHZjcHVpZCk7DQogaW50IGxpYnhsX3NlbmRf
c3lzcnEobGlieGxfY3R4ICpjdHgsIHVpbnQzMl90IGRvbWlkLCBjaGFyIHN5c3JxKTsNCmRpZmYg
LXIgYTgwYTU3N2MzNGNhIHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbA0KLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfdHlwZXMuaWRsCVdlZCBOb3YgMjMgMTU6MzY6MjIgMjAxMSArMDEwMA0KKysr
IGIvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVdlZCBOb3YgMjMgMTU6NDE6MzIgMjAxMSAr
MDEwMA0KQEAgLTEwOSw2ICsxMDksNyBAQCBTSFVURE9XTl8qIGNvbnN0YW50LiIiIiksDQogICAg
ICgiY3B1X3RpbWUiLCAgICB1aW50NjQpLA0KICAgICAoInZjcHVfbWF4X2lkIiwgdWludDMyKSwN
CiAgICAgKCJ2Y3B1X29ubGluZSIsIHVpbnQzMiksDQorICAgICgiY3B1cG9vbCIsICAgICB1aW50
MzIpLA0KICAgICBdLCBkaXNwb3NlX2ZuPU5vbmUpDQogDQogbGlieGxfY3B1cG9vbGluZm8gPSBT
dHJ1Y3QoImNwdXBvb2xpbmZvIiwgWw0KQEAgLTM3NCwzICszNzUsMTUgQEAgbGlieGxfc2NoZWRf
Y3JlZGl0ID0gU3RydWN0KCJzY2hlZF9jcmVkaQ0KICAgICAoIndlaWdodCIsIGludGVnZXIpLA0K
ICAgICAoImNhcCIsIGludGVnZXIpLA0KICAgICBdLCBkaXNwb3NlX2ZuPU5vbmUpDQorDQorbGli
eGxfc2NoZWRfY3JlZGl0MiA9IFN0cnVjdCgic2NoZWRfY3JlZGl0MiIsIFsNCisgICAgKCJ3ZWln
aHQiLCBpbnRlZ2VyKSwNCisgICAgXSwgZGlzcG9zZV9mbj1Ob25lKQ0KKw0KK2xpYnhsX3NjaGVk
X3NlZGYgPSBTdHJ1Y3QoInNjaGVkX3NlZGYiLCBbDQorICAgICgicGVyaW9kIiwgaW50ZWdlciks
DQorICAgICgic2xpY2UiLCBpbnRlZ2VyKSwNCisgICAgKCJsYXRlbmN5IiwgaW50ZWdlciksDQor
ICAgICgiZXh0cmF0aW1lIiwgaW50ZWdlciksDQorICAgICgid2VpZ2h0IiwgaW50ZWdlciksDQor
ICAgIF0sIGRpc3Bvc2VfZm49Tm9uZSkNCmRpZmYgLXIgYTgwYTU3N2MzNGNhIHRvb2xzL2xpYnhs
L3hsLmgNCi0tLSBhL3Rvb2xzL2xpYnhsL3hsLmgJV2VkIE5vdiAyMyAxNTozNjoyMiAyMDExICsw
MTAwDQorKysgYi90b29scy9saWJ4bC94bC5oCVdlZCBOb3YgMjMgMTU6NDE6MzIgMjAxMSArMDEw
MA0KQEAgLTU1LDYgKzU1LDggQEAgaW50IG1haW5fdmNwdXNldChpbnQgYXJnYywgY2hhciAqKmFy
Z3YpOw0KIGludCBtYWluX21lbW1heChpbnQgYXJnYywgY2hhciAqKmFyZ3YpOw0KIGludCBtYWlu
X21lbXNldChpbnQgYXJnYywgY2hhciAqKmFyZ3YpOw0KIGludCBtYWluX3NjaGVkX2NyZWRpdChp
bnQgYXJnYywgY2hhciAqKmFyZ3YpOw0KK2ludCBtYWluX3NjaGVkX2NyZWRpdDIoaW50IGFyZ2Ms
IGNoYXIgKiphcmd2KTsNCitpbnQgbWFpbl9zY2hlZF9zZWRmKGludCBhcmdjLCBjaGFyICoqYXJn
dik7DQogaW50IG1haW5fZG9taWQoaW50IGFyZ2MsIGNoYXIgKiphcmd2KTsNCiBpbnQgbWFpbl9k
b21uYW1lKGludCBhcmdjLCBjaGFyICoqYXJndik7DQogaW50IG1haW5fcmVuYW1lKGludCBhcmdj
LCBjaGFyICoqYXJndik7DQpkaWZmIC1yIGE4MGE1NzdjMzRjYSB0b29scy9saWJ4bC94bF9jbWRp
bXBsLmMNCi0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgTm92IDIzIDE1OjM2OjIy
IDIwMTEgKzAxMDANCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgTm92IDIzIDE1
OjQxOjMyIDIwMTEgKzAxMDANCkBAIC0zNjk5LDI5ICszNjk5LDIwNCBAQCBzdGF0aWMgaW50IHNj
aGVkX2NyZWRpdF9kb21haW5fc2V0KA0KICAgICByZXR1cm4gcmM7DQogfQ0KIA0KLXN0YXRpYyB2
b2lkIHNjaGVkX2NyZWRpdF9kb21haW5fb3V0cHV0KA0KLSAgICBpbnQgZG9taWQsIGxpYnhsX3Nj
aGVkX2NyZWRpdCAqc2NpbmZvKQ0KK3N0YXRpYyBpbnQgc2NoZWRfY3JlZGl0X2RvbWFpbl9vdXRw
dXQoDQorICAgIGludCBkb21pZCkNCiB7DQogICAgIGNoYXIgKmRvbW5hbWU7DQorICAgIGxpYnhs
X3NjaGVkX2NyZWRpdCBzY2luZm87DQorICAgIGludCByYzsNCisNCisgICAgaWYgKGRvbWlkIDwg
MCkgew0KKyAgICAgICAgcHJpbnRmKCIlLTMzcyAlNHMgJTZzICU0c1xuIiwgIk5hbWUiLCAiSUQi
LCAiV2VpZ2h0IiwgIkNhcCIpOw0KKyAgICAgICAgcmV0dXJuIDA7DQorICAgIH0NCisgICAgcmMg
PSBzY2hlZF9jcmVkaXRfZG9tYWluX2dldChkb21pZCwgJnNjaW5mbyk7DQorICAgIGlmIChyYykN
CisgICAgICAgIHJldHVybiByYzsNCiAgICAgZG9tbmFtZSA9IGxpYnhsX2RvbWlkX3RvX25hbWUo
Y3R4LCBkb21pZCk7DQogICAgIHByaW50ZigiJS0zM3MgJTRkICU2ZCAlNGRcbiIsDQogICAgICAg
ICBkb21uYW1lLA0KICAgICAgICAgZG9taWQsDQotICAgICAgICBzY2luZm8tPndlaWdodCwNCi0g
ICAgICAgIHNjaW5mby0+Y2FwKTsNCisgICAgICAgIHNjaW5mby53ZWlnaHQsDQorICAgICAgICBz
Y2luZm8uY2FwKTsNCiAgICAgZnJlZShkb21uYW1lKTsNCisgICAgcmV0dXJuIDA7DQorfQ0KKw0K
K3N0YXRpYyBpbnQgc2NoZWRfY3JlZGl0Ml9kb21haW5fZ2V0KA0KKyAgICBpbnQgZG9taWQsIGxp
YnhsX3NjaGVkX2NyZWRpdDIgKnNjaW5mbykNCit7DQorICAgIGludCByYzsNCisNCisgICAgcmMg
PSBsaWJ4bF9zY2hlZF9jcmVkaXQyX2RvbWFpbl9nZXQoY3R4LCBkb21pZCwgc2NpbmZvKTsNCisg
ICAgaWYgKHJjKQ0KKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJsaWJ4bF9zY2hlZF9jcmVkaXQy
X2RvbWFpbl9nZXQgZmFpbGVkLlxuIik7DQorDQorICAgIHJldHVybiByYzsNCit9DQorDQorc3Rh
dGljIGludCBzY2hlZF9jcmVkaXQyX2RvbWFpbl9zZXQoDQorICAgIGludCBkb21pZCwgbGlieGxf
c2NoZWRfY3JlZGl0MiAqc2NpbmZvKQ0KK3sNCisgICAgaW50IHJjOw0KKw0KKyAgICByYyA9IGxp
YnhsX3NjaGVkX2NyZWRpdDJfZG9tYWluX3NldChjdHgsIGRvbWlkLCBzY2luZm8pOw0KKyAgICBp
ZiAocmMpDQorICAgICAgICBmcHJpbnRmKHN0ZGVyciwgImxpYnhsX3NjaGVkX2NyZWRpdDJfZG9t
YWluX3NldCBmYWlsZWQuXG4iKTsNCisNCisgICAgcmV0dXJuIHJjOw0KK30NCisNCitzdGF0aWMg
aW50IHNjaGVkX2NyZWRpdDJfZG9tYWluX291dHB1dCgNCisgICAgaW50IGRvbWlkKQ0KK3sNCisg
ICAgY2hhciAqZG9tbmFtZTsNCisgICAgbGlieGxfc2NoZWRfY3JlZGl0MiBzY2luZm87DQorICAg
IGludCByYzsNCisNCisgICAgaWYgKGRvbWlkIDwgMCkgew0KKyAgICAgICAgcHJpbnRmKCIlLTMz
cyAlNHMgJTZzXG4iLCAiTmFtZSIsICJJRCIsICJXZWlnaHQiKTsNCisgICAgICAgIHJldHVybiAw
Ow0KKyAgICB9DQorICAgIHJjID0gc2NoZWRfY3JlZGl0Ml9kb21haW5fZ2V0KGRvbWlkLCAmc2Np
bmZvKTsNCisgICAgaWYgKHJjKQ0KKyAgICAgICAgcmV0dXJuIHJjOw0KKyAgICBkb21uYW1lID0g
bGlieGxfZG9taWRfdG9fbmFtZShjdHgsIGRvbWlkKTsNCisgICAgcHJpbnRmKCIlLTMzcyAlNGQg
JTZkXG4iLA0KKyAgICAgICAgZG9tbmFtZSwNCisgICAgICAgIGRvbWlkLA0KKyAgICAgICAgc2Np
bmZvLndlaWdodCk7DQorICAgIGZyZWUoZG9tbmFtZSk7DQorICAgIHJldHVybiAwOw0KK30NCisN
CitzdGF0aWMgaW50IHNjaGVkX3NlZGZfZG9tYWluX2dldCgNCisgICAgaW50IGRvbWlkLCBsaWJ4
bF9zY2hlZF9zZWRmICpzY2luZm8pDQorew0KKyAgICBpbnQgcmM7DQorDQorICAgIHJjID0gbGli
eGxfc2NoZWRfc2VkZl9kb21haW5fZ2V0KGN0eCwgZG9taWQsIHNjaW5mbyk7DQorICAgIGlmIChy
YykNCisgICAgICAgIGZwcmludGYoc3RkZXJyLCAibGlieGxfc2NoZWRfc2VkZl9kb21haW5fZ2V0
IGZhaWxlZC5cbiIpOw0KKw0KKyAgICByZXR1cm4gcmM7DQorfQ0KKw0KK3N0YXRpYyBpbnQgc2No
ZWRfc2VkZl9kb21haW5fc2V0KA0KKyAgICBpbnQgZG9taWQsIGxpYnhsX3NjaGVkX3NlZGYgKnNj
aW5mbykNCit7DQorICAgIGludCByYzsNCisNCisgICAgcmMgPSBsaWJ4bF9zY2hlZF9zZWRmX2Rv
bWFpbl9zZXQoY3R4LCBkb21pZCwgc2NpbmZvKTsNCisgICAgaWYgKHJjKQ0KKyAgICAgICAgZnBy
aW50ZihzdGRlcnIsICJsaWJ4bF9zY2hlZF9zZWRmX2RvbWFpbl9zZXQgZmFpbGVkLlxuIik7DQor
DQorICAgIHJldHVybiByYzsNCit9DQorDQorc3RhdGljIGludCBzY2hlZF9zZWRmX2RvbWFpbl9v
dXRwdXQoDQorICAgIGludCBkb21pZCkNCit7DQorICAgIGNoYXIgKmRvbW5hbWU7DQorICAgIGxp
YnhsX3NjaGVkX3NlZGYgc2NpbmZvOw0KKyAgICBpbnQgcmM7DQorDQorICAgIGlmIChkb21pZCA8
IDApIHsNCisgICAgICAgIHByaW50ZigiJS0zM3MgJTRzICU2cyAlLTZzICU3cyAlNXMgJTZzXG4i
LCAiTmFtZSIsICJJRCIsICJQZXJpb2QiLCAiU2xpY2UiLCAiTGF0ZW5jeSIsICJFeHRyYSIsICJX
ZWlnaHQiKTsNCisgICAgICAgIHJldHVybiAwOw0KKyAgICB9DQorICAgIHJjID0gc2NoZWRfc2Vk
Zl9kb21haW5fZ2V0KGRvbWlkLCAmc2NpbmZvKTsNCisgICAgaWYgKHJjKQ0KKyAgICAgICAgcmV0
dXJuIHJjOw0KKyAgICBkb21uYW1lID0gbGlieGxfZG9taWRfdG9fbmFtZShjdHgsIGRvbWlkKTsN
CisgICAgcHJpbnRmKCIlLTMzcyAlNGQgJTZkICU2ZCAlN2QgJTVkICU2ZFxuIiwNCisgICAgICAg
IGRvbW5hbWUsDQorICAgICAgICBkb21pZCwNCisgICAgICAgIHNjaW5mby5wZXJpb2QsDQorICAg
ICAgICBzY2luZm8uc2xpY2UsDQorICAgICAgICBzY2luZm8ubGF0ZW5jeSwNCisgICAgICAgIHNj
aW5mby5leHRyYXRpbWUsDQorICAgICAgICBzY2luZm8ud2VpZ2h0KTsNCisgICAgZnJlZShkb21u
YW1lKTsNCisgICAgcmV0dXJuIDA7DQorfQ0KKw0KK3N0YXRpYyBpbnQgc2NoZWRfZG9tYWluX291
dHB1dCgNCisgICAgdWludDMyX3Qgc2NoZWQsIGludCAoKm91dHB1dCkoaW50KSwgY29uc3QgY2hh
ciAqY3B1cG9vbCkNCit7DQorICAgIGxpYnhsX2RvbWluZm8gKmluZm87DQorICAgIGxpYnhsX2Nw
dXBvb2xpbmZvICpwb29saW5mbyA9IE5VTEw7DQorICAgIHVpbnQzMl90IHBvb2xpZDsNCisgICAg
Y2hhciAqcG9vbG5hbWU7DQorICAgIGludCBuYl9kb21haW4sIG5fcG9vbHMgPSAwLCBpLCBwOw0K
KyAgICBpbnQgcmMgPSAwOw0KKw0KKyAgICBpZiAoY3B1cG9vbCkgew0KKyAgICAgICAgaWYgKGNw
dXBvb2xfcXVhbGlmaWVyX3RvX2NwdXBvb2xpZChjcHVwb29sLCAmcG9vbGlkLCBOVUxMKSB8fA0K
KyAgICAgICAgICAgICFsaWJ4bF9jcHVwb29saWRfdG9fbmFtZShjdHgsIHBvb2xpZCkpIHsNCisg
ICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgInVua25vd24gY3B1cG9vbCBcJyVzXCdcbiIsIGNw
dXBvb2wpOw0KKyAgICAgICAgICAgIHJldHVybiAtRVJST1JfRkFJTDsNCisgICAgICAgIH0NCisg
ICAgfQ0KKw0KKyAgICBpbmZvID0gbGlieGxfbGlzdF9kb21haW4oY3R4LCAmbmJfZG9tYWluKTsN
CisgICAgaWYgKCFpbmZvKSB7DQorICAgICAgICBmcHJpbnRmKHN0ZGVyciwgImxpYnhsX2RvbWFp
bl9pbmZvbGlzdCBmYWlsZWQuXG4iKTsNCisgICAgICAgIHJldHVybiAxOw0KKyAgICB9DQorICAg
IHBvb2xpbmZvID0gbGlieGxfbGlzdF9jcHVwb29sKGN0eCwgJm5fcG9vbHMpOw0KKyAgICBpZiAo
IXBvb2xpbmZvKSB7DQorICAgICAgICBmcHJpbnRmKHN0ZGVyciwgImVycm9yIGdldHRpbmcgY3B1
cG9vbCBpbmZvXG4iKTsNCisgICAgICAgIHJldHVybiAtRVJST1JfTk9NRU07DQorICAgIH0NCisN
CisgICAgZm9yIChwID0gMDsgIXJjICYmIChwIDwgbl9wb29scyk7IHArKykgew0KKyAgICAgICAg
aWYgKChwb29saW5mb1twXS5zY2hlZF9pZCAhPSBzY2hlZCkgfHwNCisgICAgICAgICAgICAoY3B1
cG9vbCAmJiAocG9vbGlkICE9IHBvb2xpbmZvW3BdLnBvb2xpZCkpKQ0KKyAgICAgICAgICAgIGNv
bnRpbnVlOw0KKw0KKyAgICAgICAgcG9vbG5hbWUgPSBsaWJ4bF9jcHVwb29saWRfdG9fbmFtZShj
dHgsIHBvb2xpbmZvW3BdLnBvb2xpZCk7DQorICAgICAgICBwcmludGYoIkNwdXBvb2wgJXM6XG4i
LCBwb29sbmFtZSk7DQorICAgICAgICBmcmVlKHBvb2xuYW1lKTsNCisNCisgICAgICAgIG91dHB1
dCgtMSk7DQorICAgICAgICBmb3IgKGkgPSAwOyBpIDwgbmJfZG9tYWluOyBpKyspIHsNCisgICAg
ICAgICAgICBpZiAoaW5mb1tpXS5jcHVwb29sICE9IHBvb2xpbmZvW3BdLnBvb2xpZCkNCisgICAg
ICAgICAgICAgICAgY29udGludWU7DQorICAgICAgICAgICAgcmMgPSBvdXRwdXQoaW5mb1tpXS5k
b21pZCk7DQorICAgICAgICAgICAgaWYgKHJjKQ0KKyAgICAgICAgICAgICAgICBicmVhazsNCisg
ICAgICAgIH0NCisgICAgfQ0KKyAgICBpZiAocG9vbGluZm8pIHsNCisgICAgICAgIGZvciAocCA9
IDA7IHAgPCBuX3Bvb2xzOyBwKyspIHsNCisgICAgICAgICAgICBsaWJ4bF9jcHVwb29saW5mb19k
aXNwb3NlKHBvb2xpbmZvICsgcCk7DQorICAgICAgICB9DQorICAgIH0NCisgICAgcmV0dXJuIDA7
DQogfQ0KIA0KIGludCBtYWluX3NjaGVkX2NyZWRpdChpbnQgYXJnYywgY2hhciAqKmFyZ3YpDQog
ew0KLSAgICBsaWJ4bF9kb21pbmZvICppbmZvOw0KICAgICBsaWJ4bF9zY2hlZF9jcmVkaXQgc2Np
bmZvOw0KLSAgICBpbnQgbmJfZG9tYWluLCBpOw0KICAgICBjb25zdCBjaGFyICpkb20gPSBOVUxM
Ow0KKyAgICBjb25zdCBjaGFyICpjcHVwb29sID0gTlVMTDsNCiAgICAgaW50IHdlaWdodCA9IDI1
NiwgY2FwID0gMCwgb3B0X3cgPSAwLCBvcHRfYyA9IDA7DQogICAgIGludCBvcHQsIHJjOw0KLQ0K
LSAgICB3aGlsZSAoKG9wdCA9IGRlZl9nZXRvcHQoYXJnYywgYXJndiwgImQ6dzpjOiIsICJzY2hl
ZC1jcmVkaXQiLCAwKSkgIT0gLTEpIHsNCisgICAgaW50IG9wdGlvbl9pbmRleCA9IDA7DQorICAg
IHN0YXRpYyBzdHJ1Y3Qgb3B0aW9uIGxvbmdfb3B0aW9uc1tdID0gew0KKyAgICAgICAgeyJkb21h
aW4iLCAxLCAwLCAnZCd9LA0KKyAgICAgICAgeyJ3ZWlnaHQiLCAxLCAwLCAndyd9LA0KKyAgICAg
ICAgeyJjYXAiLCAxLCAwLCAnYyd9LA0KKyAgICAgICAgeyJjcHVwb29sIiwgMSwgMCwgJ3AnfSwN
CisgICAgICAgIHsiaGVscCIsIDAsIDAsICdoJ30sDQorICAgICAgICB7MCwgMCwgMCwgMH0NCisg
ICAgfTsNCisNCisgICAgd2hpbGUgKDEpIHsNCisgICAgICAgIG9wdCA9IGdldG9wdF9sb25nKGFy
Z2MsIGFyZ3YsICJkOnc6YzpwOmgiLCBsb25nX29wdGlvbnMsICZvcHRpb25faW5kZXgpOw0KKyAg
ICAgICAgaWYgKG9wdCA9PSAtMSkNCisgICAgICAgICAgICBicmVhazsNCiAgICAgICAgIHN3aXRj
aCAob3B0KSB7DQogICAgICAgICBjYXNlIDA6IGNhc2UgMjoNCiAgICAgICAgICAgICByZXR1cm4g
b3B0Ow0KQEAgLTM3MzYsMjggKzM5MTEsMjYgQEAgaW50IG1haW5fc2NoZWRfY3JlZGl0KGludCBh
cmdjLCBjaGFyICoqYQ0KICAgICAgICAgICAgIGNhcCA9IHN0cnRvbChvcHRhcmcsIE5VTEwsIDEw
KTsNCiAgICAgICAgICAgICBvcHRfYyA9IDE7DQogICAgICAgICAgICAgYnJlYWs7DQorICAgICAg
ICBjYXNlICdwJzoNCisgICAgICAgICAgICBjcHVwb29sID0gb3B0YXJnOw0KKyAgICAgICAgICAg
IGJyZWFrOw0KKyAgICAgICAgY2FzZSAnaCc6DQorICAgICAgICAgICAgaGVscCgic2NoZWQtY3Jl
ZGl0Iik7DQorICAgICAgICAgICAgcmV0dXJuIDA7DQogICAgICAgICB9DQogICAgIH0NCiANCisg
ICAgaWYgKGNwdXBvb2wgJiYgKGRvbSB8fCBvcHRfdyB8fCBvcHRfYykpIHsNCisgICAgICAgIGZw
cmludGYoc3RkZXJyLCAiU3BlY2lmeWluZyBhIGNwdXBvb2wgaXMgbm90IGFsbG93ZWQgd2l0aCBv
dGhlciBvcHRpb25zLlxuIik7DQorICAgICAgICByZXR1cm4gMTsNCisgICAgfQ0KICAgICBpZiAo
IWRvbSAmJiAob3B0X3cgfHwgb3B0X2MpKSB7DQogICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIk11
c3Qgc3BlY2lmeSBhIGRvbWFpbi5cbiIpOw0KICAgICAgICAgcmV0dXJuIDE7DQogICAgIH0NCiAN
CiAgICAgaWYgKCFkb20pIHsgLyogbGlzdCBhbGwgZG9tYWluJ3MgY3JlZGl0IHNjaGVkdWxlciBp
bmZvICovDQotICAgICAgICBpbmZvID0gbGlieGxfbGlzdF9kb21haW4oY3R4LCAmbmJfZG9tYWlu
KTsNCi0gICAgICAgIGlmICghaW5mbykgew0KLSAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAi
bGlieGxfZG9tYWluX2luZm9saXN0IGZhaWxlZC5cbiIpOw0KLSAgICAgICAgICAgIHJldHVybiAx
Ow0KLSAgICAgICAgfQ0KLQ0KLSAgICAgICAgcHJpbnRmKCIlLTMzcyAlNHMgJTZzICU0c1xuIiwg
Ik5hbWUiLCAiSUQiLCAiV2VpZ2h0IiwgIkNhcCIpOw0KLSAgICAgICAgZm9yIChpID0gMDsgaSA8
IG5iX2RvbWFpbjsgaSsrKSB7DQotICAgICAgICAgICAgcmMgPSBzY2hlZF9jcmVkaXRfZG9tYWlu
X2dldChpbmZvW2ldLmRvbWlkLCAmc2NpbmZvKTsNCi0gICAgICAgICAgICBpZiAocmMpDQotICAg
ICAgICAgICAgICAgIHJldHVybiAtcmM7DQotICAgICAgICAgICAgc2NoZWRfY3JlZGl0X2RvbWFp
bl9vdXRwdXQoaW5mb1tpXS5kb21pZCwgJnNjaW5mbyk7DQotICAgICAgICB9DQorICAgICAgICBy
ZXR1cm4gLXNjaGVkX2RvbWFpbl9vdXRwdXQoWEVOX1NDSEVEVUxFUl9DUkVESVQsIHNjaGVkX2Ny
ZWRpdF9kb21haW5fb3V0cHV0LCBjcHVwb29sKTsNCiAgICAgfSBlbHNlIHsNCiAgICAgICAgIGZp
bmRfZG9tYWluKGRvbSk7DQogDQpAQCAtMzc2Niw4ICszOTM5LDggQEAgaW50IG1haW5fc2NoZWRf
Y3JlZGl0KGludCBhcmdjLCBjaGFyICoqYQ0KICAgICAgICAgICAgIHJldHVybiAtcmM7DQogDQog
ICAgICAgICBpZiAoIW9wdF93ICYmICFvcHRfYykgeyAvKiBvdXRwdXQgY3JlZGl0IHNjaGVkdWxl
ciBpbmZvICovDQotICAgICAgICAgICAgcHJpbnRmKCIlLTMzcyAlNHMgJTZzICU0c1xuIiwgIk5h
bWUiLCAiSUQiLCAiV2VpZ2h0IiwgIkNhcCIpOw0KLSAgICAgICAgICAgIHNjaGVkX2NyZWRpdF9k
b21haW5fb3V0cHV0KGRvbWlkLCAmc2NpbmZvKTsNCisgICAgICAgICAgICBzY2hlZF9jcmVkaXRf
ZG9tYWluX291dHB1dCgtMSk7DQorICAgICAgICAgICAgcmV0dXJuIC1zY2hlZF9jcmVkaXRfZG9t
YWluX291dHB1dChkb21pZCk7DQogICAgICAgICB9IGVsc2UgeyAvKiBzZXQgY3JlZGl0IHNjaGVk
dWxlciBwYXJhbWF0ZXJzICovDQogICAgICAgICAgICAgaWYgKG9wdF93KQ0KICAgICAgICAgICAg
ICAgICBzY2luZm8ud2VpZ2h0ID0gd2VpZ2h0Ow0KQEAgLTM3ODIsNiArMzk1NSwxOTEgQEAgaW50
IG1haW5fc2NoZWRfY3JlZGl0KGludCBhcmdjLCBjaGFyICoqYQ0KICAgICByZXR1cm4gMDsNCiB9
DQogDQoraW50IG1haW5fc2NoZWRfY3JlZGl0MihpbnQgYXJnYywgY2hhciAqKmFyZ3YpDQorew0K
KyAgICBsaWJ4bF9zY2hlZF9jcmVkaXQyIHNjaW5mbzsNCisgICAgY29uc3QgY2hhciAqZG9tID0g
TlVMTDsNCisgICAgY29uc3QgY2hhciAqY3B1cG9vbCA9IE5VTEw7DQorICAgIGludCB3ZWlnaHQg
PSAyNTYsIG9wdF93ID0gMDsNCisgICAgaW50IG9wdCwgcmM7DQorICAgIGludCBvcHRpb25faW5k
ZXggPSAwOw0KKyAgICBzdGF0aWMgc3RydWN0IG9wdGlvbiBsb25nX29wdGlvbnNbXSA9IHsNCisg
ICAgICAgIHsiZG9tYWluIiwgMSwgMCwgJ2QnfSwNCisgICAgICAgIHsid2VpZ2h0IiwgMSwgMCwg
J3cnfSwNCisgICAgICAgIHsiY3B1cG9vbCIsIDEsIDAsICdwJ30sDQorICAgICAgICB7ImhlbHAi
LCAwLCAwLCAnaCd9LA0KKyAgICAgICAgezAsIDAsIDAsIDB9DQorICAgIH07DQorDQorICAgIHdo
aWxlICgxKSB7DQorICAgICAgICBvcHQgPSBnZXRvcHRfbG9uZyhhcmdjLCBhcmd2LCAiZDp3OnA6
aCIsIGxvbmdfb3B0aW9ucywgJm9wdGlvbl9pbmRleCk7DQorICAgICAgICBpZiAob3B0ID09IC0x
KQ0KKyAgICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgc3dpdGNoIChvcHQpIHsNCisgICAgICAg
IGNhc2UgMDogY2FzZSAyOg0KKyAgICAgICAgICAgIHJldHVybiBvcHQ7DQorICAgICAgICBjYXNl
ICdkJzoNCisgICAgICAgICAgICBkb20gPSBvcHRhcmc7DQorICAgICAgICAgICAgYnJlYWs7DQor
ICAgICAgICBjYXNlICd3JzoNCisgICAgICAgICAgICB3ZWlnaHQgPSBzdHJ0b2wob3B0YXJnLCBO
VUxMLCAxMCk7DQorICAgICAgICAgICAgb3B0X3cgPSAxOw0KKyAgICAgICAgICAgIGJyZWFrOw0K
KyAgICAgICAgY2FzZSAncCc6DQorICAgICAgICAgICAgY3B1cG9vbCA9IG9wdGFyZzsNCisgICAg
ICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgJ2gnOg0KKyAgICAgICAgICAgIGhlbHAoInNj
aGVkLWNyZWRpdCIpOw0KKyAgICAgICAgICAgIHJldHVybiAwOw0KKyAgICAgICAgfQ0KKyAgICB9
DQorDQorICAgIGlmIChjcHVwb29sICYmIChkb20gfHwgb3B0X3cpKSB7DQorICAgICAgICBmcHJp
bnRmKHN0ZGVyciwgIlNwZWNpZnlpbmcgYSBjcHVwb29sIGlzIG5vdCBhbGxvd2VkIHdpdGggb3Ro
ZXIgb3B0aW9ucy5cbiIpOw0KKyAgICAgICAgcmV0dXJuIDE7DQorICAgIH0NCisgICAgaWYgKCFk
b20gJiYgb3B0X3cpIHsNCisgICAgICAgIGZwcmludGYoc3RkZXJyLCAiTXVzdCBzcGVjaWZ5IGEg
ZG9tYWluLlxuIik7DQorICAgICAgICByZXR1cm4gMTsNCisgICAgfQ0KKw0KKyAgICBpZiAoIWRv
bSkgeyAvKiBsaXN0IGFsbCBkb21haW4ncyBjcmVkaXQgc2NoZWR1bGVyIGluZm8gKi8NCisgICAg
ICAgIHJldHVybiAtc2NoZWRfZG9tYWluX291dHB1dChYRU5fU0NIRURVTEVSX0NSRURJVDIsIHNj
aGVkX2NyZWRpdDJfZG9tYWluX291dHB1dCwgY3B1cG9vbCk7DQorICAgIH0gZWxzZSB7DQorICAg
ICAgICBmaW5kX2RvbWFpbihkb20pOw0KKw0KKyAgICAgICAgcmMgPSBzY2hlZF9jcmVkaXQyX2Rv
bWFpbl9nZXQoZG9taWQsICZzY2luZm8pOw0KKyAgICAgICAgaWYgKHJjKQ0KKyAgICAgICAgICAg
IHJldHVybiAtcmM7DQorDQorICAgICAgICBpZiAoIW9wdF93KSB7IC8qIG91dHB1dCBjcmVkaXQy
IHNjaGVkdWxlciBpbmZvICovDQorICAgICAgICAgICAgc2NoZWRfY3JlZGl0Ml9kb21haW5fb3V0
cHV0KC0xKTsNCisgICAgICAgICAgICByZXR1cm4gLXNjaGVkX2NyZWRpdDJfZG9tYWluX291dHB1
dChkb21pZCk7DQorICAgICAgICB9IGVsc2UgeyAvKiBzZXQgY3JlZGl0MiBzY2hlZHVsZXIgcGFy
YW1hdGVycyAqLw0KKyAgICAgICAgICAgIGlmIChvcHRfdykNCisgICAgICAgICAgICAgICAgc2Np
bmZvLndlaWdodCA9IHdlaWdodDsNCisgICAgICAgICAgICByYyA9IHNjaGVkX2NyZWRpdDJfZG9t
YWluX3NldChkb21pZCwgJnNjaW5mbyk7DQorICAgICAgICAgICAgaWYgKHJjKQ0KKyAgICAgICAg
ICAgICAgICByZXR1cm4gLXJjOw0KKyAgICAgICAgfQ0KKyAgICB9DQorDQorICAgIHJldHVybiAw
Ow0KK30NCisNCitpbnQgbWFpbl9zY2hlZF9zZWRmKGludCBhcmdjLCBjaGFyICoqYXJndikNCit7
DQorICAgIGxpYnhsX3NjaGVkX3NlZGYgc2NpbmZvOw0KKyAgICBjb25zdCBjaGFyICpkb20gPSBO
VUxMOw0KKyAgICBjb25zdCBjaGFyICpjcHVwb29sID0gTlVMTDsNCisgICAgaW50IHBlcmlvZCA9
IDAsIG9wdF9wID0gMDsNCisgICAgaW50IHNsaWNlID0gMCwgb3B0X3MgPSAwOw0KKyAgICBpbnQg
bGF0ZW5jeSA9IDAsIG9wdF9sID0gMDsNCisgICAgaW50IGV4dHJhID0gMCwgb3B0X2UgPSAwOw0K
KyAgICBpbnQgd2VpZ2h0ID0gMCwgb3B0X3cgPSAwOw0KKyAgICBpbnQgb3B0LCByYzsNCisgICAg
aW50IG9wdGlvbl9pbmRleCA9IDA7DQorICAgIHN0YXRpYyBzdHJ1Y3Qgb3B0aW9uIGxvbmdfb3B0
aW9uc1tdID0gew0KKyAgICAgICAgeyJwZXJpb2QiLCAxLCAwLCAncCd9LA0KKyAgICAgICAgeyJz
bGljZSIsIDEsIDAsICdzJ30sDQorICAgICAgICB7ImxhdGVuY3kiLCAxLCAwLCAnbCd9LA0KKyAg
ICAgICAgeyJleHRyYSIsIDEsIDAsICdlJ30sDQorICAgICAgICB7IndlaWdodCIsIDEsIDAsICd3
J30sDQorICAgICAgICB7ImNwdXBvb2wiLCAxLCAwLCAnYyd9LA0KKyAgICAgICAgeyJoZWxwIiwg
MCwgMCwgJ2gnfSwNCisgICAgICAgIHswLCAwLCAwLCAwfQ0KKyAgICB9Ow0KKw0KKyAgICB3aGls
ZSAoMSkgew0KKyAgICAgICAgb3B0ID0gZ2V0b3B0X2xvbmcoYXJnYywgYXJndiwgImQ6cDpzOmw6
ZTp3OmM6aCIsIGxvbmdfb3B0aW9ucywgJm9wdGlvbl9pbmRleCk7DQorICAgICAgICBpZiAob3B0
ID09IC0xKQ0KKyAgICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgc3dpdGNoIChvcHQpIHsNCisg
ICAgICAgIGNhc2UgMDogY2FzZSAyOg0KKyAgICAgICAgICAgIHJldHVybiBvcHQ7DQorICAgICAg
ICBjYXNlICdkJzoNCisgICAgICAgICAgICBkb20gPSBvcHRhcmc7DQorICAgICAgICAgICAgYnJl
YWs7DQorICAgICAgICBjYXNlICdwJzoNCisgICAgICAgICAgICBwZXJpb2QgPSBzdHJ0b2wob3B0
YXJnLCBOVUxMLCAxMCk7DQorICAgICAgICAgICAgb3B0X3AgPSAxOw0KKyAgICAgICAgICAgIGJy
ZWFrOw0KKyAgICAgICAgY2FzZSAncyc6DQorICAgICAgICAgICAgc2xpY2UgPSBzdHJ0b2wob3B0
YXJnLCBOVUxMLCAxMCk7DQorICAgICAgICAgICAgb3B0X3MgPSAxOw0KKyAgICAgICAgICAgIGJy
ZWFrOw0KKyAgICAgICAgY2FzZSAnbCc6DQorICAgICAgICAgICAgbGF0ZW5jeSA9IHN0cnRvbChv
cHRhcmcsIE5VTEwsIDEwKTsNCisgICAgICAgICAgICBvcHRfbCA9IDE7DQorICAgICAgICAgICAg
YnJlYWs7DQorICAgICAgICBjYXNlICdlJzoNCisgICAgICAgICAgICBleHRyYSA9IHN0cnRvbChv
cHRhcmcsIE5VTEwsIDEwKTsNCisgICAgICAgICAgICBvcHRfZSA9IDE7DQorICAgICAgICAgICAg
YnJlYWs7DQorICAgICAgICBjYXNlICd3JzoNCisgICAgICAgICAgICB3ZWlnaHQgPSBzdHJ0b2wo
b3B0YXJnLCBOVUxMLCAxMCk7DQorICAgICAgICAgICAgb3B0X3cgPSAxOw0KKyAgICAgICAgICAg
IGJyZWFrOw0KKyAgICAgICAgY2FzZSAnYyc6DQorICAgICAgICAgICAgY3B1cG9vbCA9IG9wdGFy
ZzsNCisgICAgICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgJ2gnOg0KKyAgICAgICAgICAg
IGhlbHAoInNjaGVkLXNlZGYiKTsNCisgICAgICAgICAgICByZXR1cm4gMDsNCisgICAgICAgIH0N
CisgICAgfQ0KKw0KKyAgICBpZiAoY3B1cG9vbCAmJiAoZG9tIHx8IG9wdF9wIHx8IG9wdF9zIHx8
IG9wdF9sIHx8IG9wdF9lIHx8IG9wdF93KSkgew0KKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJT
cGVjaWZ5aW5nIGEgY3B1cG9vbCBpcyBub3QgYWxsb3dlZCB3aXRoIG90aGVyIG9wdGlvbnMuXG4i
KTsNCisgICAgICAgIHJldHVybiAxOw0KKyAgICB9DQorICAgIGlmICghZG9tICYmIChvcHRfcCB8
fCBvcHRfcyB8fCBvcHRfbCB8fCBvcHRfZSB8fCBvcHRfdykpIHsNCisgICAgICAgIGZwcmludGYo
c3RkZXJyLCAiTXVzdCBzcGVjaWZ5IGEgZG9tYWluLlxuIik7DQorICAgICAgICByZXR1cm4gMTsN
CisgICAgfQ0KKyAgICBpZiAob3B0X3cgJiYgKG9wdF9wIHx8IG9wdF9zKSkgew0KKyAgICAgICAg
ZnByaW50ZihzdGRlcnIsICJTcGVjaWZ5aW5nIGEgd2VpZ2h0IEFORCBwZXJpb2Qgb3Igc2xpY2Ug
aXMgbm90IGFsbG93ZWQuXG4iKTsNCisgICAgfQ0KKw0KKyAgICBpZiAoIWRvbSkgeyAvKiBsaXN0
IGFsbCBkb21haW4ncyBjcmVkaXQgc2NoZWR1bGVyIGluZm8gKi8NCisgICAgICAgIHJldHVybiAt
c2NoZWRfZG9tYWluX291dHB1dChYRU5fU0NIRURVTEVSX1NFREYsIHNjaGVkX3NlZGZfZG9tYWlu
X291dHB1dCwgY3B1cG9vbCk7DQorICAgIH0gZWxzZSB7DQorICAgICAgICBmaW5kX2RvbWFpbihk
b20pOw0KKw0KKyAgICAgICAgcmMgPSBzY2hlZF9zZWRmX2RvbWFpbl9nZXQoZG9taWQsICZzY2lu
Zm8pOw0KKyAgICAgICAgaWYgKHJjKQ0KKyAgICAgICAgICAgIHJldHVybiAtcmM7DQorDQorICAg
ICAgICBpZiAoIW9wdF9wICYmICFvcHRfcyAmJiAhb3B0X2wgJiYgIW9wdF9lICYmICFvcHRfdykg
eyAvKiBvdXRwdXQgc2VkZiBzY2hlZHVsZXIgaW5mbyAqLw0KKyAgICAgICAgICAgIHNjaGVkX3Nl
ZGZfZG9tYWluX291dHB1dCgtMSk7DQorICAgICAgICAgICAgcmV0dXJuIC1zY2hlZF9zZWRmX2Rv
bWFpbl9vdXRwdXQoZG9taWQpOw0KKyAgICAgICAgfSBlbHNlIHsgLyogc2V0IHNlZGYgc2NoZWR1
bGVyIHBhcmFtYXRlcnMgKi8NCisgICAgICAgICAgICBpZiAob3B0X3ApIHsNCisgICAgICAgICAg
ICAgICAgc2NpbmZvLnBlcmlvZCA9IHBlcmlvZDsNCisgICAgICAgICAgICAgICAgc2NpbmZvLndl
aWdodCA9IDA7DQorICAgICAgICAgICAgfQ0KKyAgICAgICAgICAgIGlmIChvcHRfcykgew0KKyAg
ICAgICAgICAgICAgICBzY2luZm8uc2xpY2UgPSBzbGljZTsNCisgICAgICAgICAgICAgICAgc2Np
bmZvLndlaWdodCA9IDA7DQorICAgICAgICAgICAgfQ0KKyAgICAgICAgICAgIGlmIChvcHRfbCkN
CisgICAgICAgICAgICAgICAgc2NpbmZvLmxhdGVuY3kgPSBsYXRlbmN5Ow0KKyAgICAgICAgICAg
IGlmIChvcHRfZSkNCisgICAgICAgICAgICAgICAgc2NpbmZvLmV4dHJhdGltZSA9IGV4dHJhOw0K
KyAgICAgICAgICAgIGlmIChvcHRfdykgew0KKyAgICAgICAgICAgICAgICBzY2luZm8ud2VpZ2h0
ID0gd2VpZ2h0Ow0KKyAgICAgICAgICAgICAgICBzY2luZm8ucGVyaW9kID0gMDsNCisgICAgICAg
ICAgICAgICAgc2NpbmZvLnNsaWNlID0gMDsNCisgICAgICAgICAgICB9DQorICAgICAgICAgICAg
cmMgPSBzY2hlZF9zZWRmX2RvbWFpbl9zZXQoZG9taWQsICZzY2luZm8pOw0KKyAgICAgICAgICAg
IGlmIChyYykNCisgICAgICAgICAgICAgICAgcmV0dXJuIC1yYzsNCisgICAgICAgIH0NCisgICAg
fQ0KKw0KKyAgICByZXR1cm4gMDsNCit9DQorDQogaW50IG1haW5fZG9taWQoaW50IGFyZ2MsIGNo
YXIgKiphcmd2KQ0KIHsNCiAgICAgaW50IG9wdDsNCmRpZmYgLXIgYTgwYTU3N2MzNGNhIHRvb2xz
L2xpYnhsL3hsX2NtZHRhYmxlLmMNCi0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZHRhYmxlLmMJV2Vk
IE5vdiAyMyAxNTozNjoyMiAyMDExICswMTAwDQorKysgYi90b29scy9saWJ4bC94bF9jbWR0YWJs
ZS5jCVdlZCBOb3YgMjMgMTU6NDE6MzIgMjAxMSArMDEwMA0KQEAgLTE5MiwxMCArMTkyLDM1IEBA
IHN0cnVjdCBjbWRfc3BlYyBjbWRfdGFibGVbXSA9IHsNCiAgICAgeyAic2NoZWQtY3JlZGl0IiwN
CiAgICAgICAmbWFpbl9zY2hlZF9jcmVkaXQsIDAsDQogICAgICAgIkdldC9zZXQgY3JlZGl0IHNj
aGVkdWxlciBwYXJhbWV0ZXJzIiwNCi0gICAgICAiWy1kIDxEb21haW4+IFstd1s9V0VJR0hUXXwt
Y1s9Q0FQXV1dIiwNCisgICAgICAiWy1kIDxEb21haW4+IFstd1s9V0VJR0hUXXwtY1s9Q0FQXV1d
IFstcCBDUFVQT09MXSIsDQogICAgICAgIi1kIERPTUFJTiwgLS1kb21haW49RE9NQUlOICAgICBE
b21haW4gdG8gbW9kaWZ5XG4iDQogICAgICAgIi13IFdFSUdIVCwgLS13ZWlnaHQ9V0VJR0hUICAg
ICBXZWlnaHQgKGludClcbiINCi0gICAgICAiLWMgQ0FQLCAtLWNhcD1DQVAgICAgICAgICAgICAg
IENhcCAoaW50KSINCisgICAgICAiLWMgQ0FQLCAtLWNhcD1DQVAgICAgICAgICAgICAgIENhcCAo
aW50KVxuIg0KKyAgICAgICItcCBDUFVQT09MLCAtLWNwdXBvb2w9Q1BVUE9PTCAgUmVzdHJpY3Qg
b3V0cHV0IHRvIENQVVBPT0wiDQorICAgIH0sDQorICAgIHsgInNjaGVkLWNyZWRpdDIiLA0KKyAg
ICAgICZtYWluX3NjaGVkX2NyZWRpdDIsIDAsDQorICAgICAgIkdldC9zZXQgY3JlZGl0MiBzY2hl
ZHVsZXIgcGFyYW1ldGVycyIsDQorICAgICAgIlstZCA8RG9tYWluPiBbLXdbPVdFSUdIVF1dXSBb
LXAgQ1BVUE9PTF0iLA0KKyAgICAgICItZCBET01BSU4sIC0tZG9tYWluPURPTUFJTiAgICAgRG9t
YWluIHRvIG1vZGlmeVxuIg0KKyAgICAgICItdyBXRUlHSFQsIC0td2VpZ2h0PVdFSUdIVCAgICAg
V2VpZ2h0IChpbnQpXG4iDQorICAgICAgIi1wIENQVVBPT0wsIC0tY3B1cG9vbD1DUFVQT09MICBS
ZXN0cmljdCBvdXRwdXQgdG8gQ1BVUE9PTCINCisgICAgfSwNCisgICAgeyAic2NoZWQtc2VkZiIs
DQorICAgICAgJm1haW5fc2NoZWRfc2VkZiwgMCwNCisgICAgICAiR2V0L3NldCBzZWRmIHNjaGVk
dWxlciBwYXJhbWV0ZXJzIiwNCisgICAgICAiW29wdGlvbnNdIiwNCisgICAgICAiLWQgRE9NQUlO
LCAtLWRvbWFpbj1ET01BSU4gICAgIERvbWFpbiB0byBtb2RpZnlcbiINCisgICAgICAiLXAgTVMs
IC0tcGVyaW9kPU1TICAgICAgICAgICAgIFJlbGF0aXZlIGRlYWRsaW5lKG1zKVxuIg0KKyAgICAg
ICItcyBNUywgLS1zbGljZT1NUyAgICAgICAgICAgICAgV29yc3QtY2FzZSBleGVjdXRpb24gdGlt
ZShtcykuIChzbGljZSA8XG4iDQorICAgICAgIiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBwZXJpb2QpXG4iDQorICAgICAgIi1sIE1TLCAtLWxhdGVuY3k9TVMgICAgICAgICAgICBTY2Fs
ZWQgcGVyaW9kIChtcykgd2hlbiBkb21haW4gcGVyZm9ybXNcbiINCisgICAgICAiICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGhlYXZ5IEkvT1xuIg0KKyAgICAgICItZSBGTEFHLCAtLWV4
dHJhPUZMQUcgICAgICAgICAgRmxhZyAoMCBvciAxKSBjb250cm9scyBpZiBkb21haW4gY2FuIHJ1
blxuIg0KKyAgICAgICIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW4gZXh0cmEgdGlt
ZVxuIg0KKyAgICAgICItdyBGTE9BVCwgLS13ZWlnaHQ9RkxPQVQgICAgICAgQ1BVIFBlcmlvZC9z
bGljZSAoZG8gbm90IHNldCB3aXRoXG4iDQorICAgICAgIiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAtLXBlcmlvZC8tLXNsaWNlKVxuIg0KKyAgICAgICItYyBDUFVQT09MLCAtLWNwdXBv
b2w9Q1BVUE9PTCAgUmVzdHJpY3Qgb3V0cHV0IHRvIENQVVBPT0wiDQogICAgIH0sDQogICAgIHsg
ImRvbWlkIiwNCiAgICAgICAmbWFpbl9kb21pZCwgMCwNCi==


--=-X2L9tkRP5oeRl7Vc+sn5--

--=-isU7WgRQ2IUCWmmUijnl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7NCWMACgkQk4XaBE3IOsQbhgCfU96ZxGpCgkuDjKnBpb+ah8o9
DBkAoKgN0r90vCq9UGjh9OaZAwZ/RGZ0
=NgwM
-----END PGP SIGNATURE-----

--=-isU7WgRQ2IUCWmmUijnl--



--===============3623433031883149479==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3623433031883149479==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:09:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTER9-0007yP-W4; Wed, 23 Nov 2011 15:08:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTER8-0007xz-19
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:08:34 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322060883!5350613!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19329 invoked from network); 23 Nov 2011 15:08:03 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	23 Nov 2011 15:08:03 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73385674; Wed, 23 Nov 2011 16:08:02 +0100
Message-ID: <1322060876.30168.18.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 16:07:56 +0100
In-Reply-To: <1322060131.30168.15.camel@Abyss>
References: <1322060131.30168.15.camel@Abyss>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
	schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4988314752036575231=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4988314752036575231==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-YFk3Qd7bSF4SLMiJwwzE"


--=-YFk3Qd7bSF4SLMiJwwzE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Pluggable schedulers' code knows what (and when) to lock better than
generic code, let's delegate to them all the concurrency related issues.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 84b3e46aa7d2 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Wed Nov 23 12:03:37 2011 +0000
+++ b/xen/common/sched_credit.c	Wed Nov 23 15:09:14 2011 +0100
@@ -161,6 +161,7 @@ struct csched_dom {
  * System-wide private data
  */
 struct csched_private {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
     spinlock_t lock;
     struct list_head active_sdom;
     uint32_t ncpus;
@@ -800,6 +801,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Protect both get and put branches with the pluggable scheduler
+     * lock. Runq lock not needed anywhere in here. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit.weight =3D sdom->weight;
@@ -809,8 +814,6 @@ csched_dom_cntl(
     {
         ASSERT(op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo);
=20
-        spin_lock_irqsave(&prv->lock, flags);
-
         if ( op->u.credit.weight !=3D 0 )
         {
             if ( !list_empty(&sdom->active_sdom_elem) )
@@ -824,9 +827,10 @@ csched_dom_cntl(
         if ( op->u.credit.cap !=3D (uint16_t)~0U )
             sdom->cap =3D op->u.credit.cap;
=20
-        spin_unlock_irqrestore(&prv->lock, flags);
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 84b3e46aa7d2 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Wed Nov 23 12:03:37 2011 +0000
+++ b/xen/common/sched_credit2.c	Wed Nov 23 15:09:14 2011 +0100
@@ -1384,6 +1384,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Must hold csched_priv lock to read and update sdom,
+     * runq lock to update csvcs. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit2.weight =3D sdom->weight;
@@ -1397,10 +1401,6 @@ csched_dom_cntl(
             struct list_head *iter;
             int old_weight;
=20
-            /* Must hold csched_priv lock to update sdom, runq lock to
-             * update csvcs. */
-            spin_lock_irqsave(&prv->lock, flags);
-
             old_weight =3D sdom->weight;
=20
             sdom->weight =3D op->u.credit2.weight;
@@ -1411,22 +1411,23 @@ csched_dom_cntl(
                 struct csched_vcpu *svc =3D list_entry(iter, struct csched=
_vcpu, sdom_elem);
=20
                 /* NB: Locking order is important here.  Because we grab t=
his lock here, we
-                 * must never lock csched_priv.lock if we're holding a run=
queue
-                 * lock. */
-                vcpu_schedule_lock_irq(svc->vcpu);
+                 * must never lock csched_priv.lock if we're holding a run=
queue lock.
+                 * Also, calling vcpu_schedule_lock() is enough, since IRQ=
s have already
+                 * been disabled. */
+                vcpu_schedule_lock(svc->vcpu);
=20
                 BUG_ON(svc->rqd !=3D RQD(ops, svc->vcpu->processor));
=20
                 svc->weight =3D sdom->weight;
                 update_max_weight(svc->rqd, svc->weight, old_weight);
=20
-                vcpu_schedule_unlock_irq(svc->vcpu);
+                vcpu_schedule_unlock(svc->vcpu);
             }
-
-            spin_unlock_irqrestore(&prv->lock, flags);
         }
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 84b3e46aa7d2 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Nov 23 12:03:37 2011 +0000
+++ b/xen/common/sched_sedf.c	Wed Nov 23 15:09:14 2011 +0100
@@ -1397,18 +1397,28 @@ static int sedf_adjust_weights(struct cp
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
     struct vcpu *v;
-    int rc;
+    int rc =3D 0;
=20
     PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
           "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
           p->domain_id, op->u.sedf.period, op->u.sedf.slice,
           op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
=20
+    /* Serialize everything against runq lock to prevent concurrent update
+     * (notice all non-current VCPUs of the domain have been paused in the
+     * caller). */
+    if ( p =3D=3D current->domain )
+        vcpu_schedule_lock_irq(current);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
         /* Check for sane parameters. */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         if ( op->u.sedf.weight )
         {
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
@@ -1443,7 +1453,11 @@ static int sedf_adjust(const struct sche
                      (op->u.sedf.period < PERIOD_MIN) ||
                      (op->u.sedf.slice  > op->u.sedf.period) ||
                      (op->u.sedf.slice  < SLICE_MIN) )
-                    return -EINVAL;
+                {
+                    rc =3D -EINVAL;
+                    goto out;
+                }
+
                 EDOM_INFO(v)->weight =3D 0;
                 EDOM_INFO(v)->extraweight =3D 0;
                 EDOM_INFO(v)->period_orig =3D=20
@@ -1455,7 +1469,7 @@ static int sedf_adjust(const struct sche
=20
         rc =3D sedf_adjust_weights(p->cpupool, op);
         if ( rc )
-            return rc;
+            goto out;
=20
         for_each_vcpu ( p, v )
         {
@@ -1469,7 +1483,11 @@ static int sedf_adjust(const struct sche
     else if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         if ( p->vcpu[0] =3D=3D NULL )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         op->u.sedf.period    =3D EDOM_INFO(p->vcpu[0])->period;
         op->u.sedf.slice     =3D EDOM_INFO(p->vcpu[0])->slice;
         op->u.sedf.extratime =3D EDOM_INFO(p->vcpu[0])->status & EXTRA_AWA=
RE;
@@ -1477,8 +1495,12 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
-    return 0;
+out:
+    if ( p =3D=3D current->domain )
+        vcpu_schedule_unlock_irq(current);
+
+    PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
+    return rc;
 }
=20
 const struct scheduler sched_sedf_def =3D {
diff -r 84b3e46aa7d2 xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Nov 23 12:03:37 2011 +0000
+++ b/xen/common/schedule.c	Wed Nov 23 15:09:14 2011 +0100
@@ -1015,15 +1015,8 @@ long sched_adjust(struct domain *d, stru
=20
     /*
      * Most VCPUs we can simply pause. If we are adjusting this VCPU then
-     * we acquire the local schedule_lock to guard against concurrent upda=
tes.
-     *
-     * We only acquire the local schedule lock after we have paused all ot=
her
-     * VCPUs in this domain. There are two reasons for this:
-     * 1- We don't want to hold up interrupts as pausing a VCPU can
-     *    trigger a tlb shootdown.
-     * 2- Pausing other VCPUs involves briefly locking the schedule
-     *    lock of the CPU they are running on. This CPU could be the
-     *    same as ours.
+     * concurrent updates shall be prevented within the actual pluggable
+     * scheduler.
      */
=20
     for_each_vcpu ( d, v )
@@ -1032,15 +1025,9 @@ long sched_adjust(struct domain *d, stru
             vcpu_pause(v);
     }
=20
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_lock_irq(current);
-
     if ( (ret =3D SCHED_OP(DOM2OP(d), adjust, d, op)) =3D=3D 0 )
         TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
=20
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_unlock_irq(current);
-
     for_each_vcpu ( d, v )
     {
         if ( v !=3D current )

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-YFk3Qd7bSF4SLMiJwwzE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7NDEwACgkQk4XaBE3IOsSeCQCgoJCJsYia/X/oVQMLDtYBGLCi
sckAnR9wYQJXIJ1KE9lISJkdrg5g3oOl
=vyX5
-----END PGP SIGNATURE-----

--=-YFk3Qd7bSF4SLMiJwwzE--



--===============4988314752036575231==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4988314752036575231==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:09:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTER9-0007yP-W4; Wed, 23 Nov 2011 15:08:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTER8-0007xz-19
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:08:34 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322060883!5350613!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19329 invoked from network); 23 Nov 2011 15:08:03 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	23 Nov 2011 15:08:03 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73385674; Wed, 23 Nov 2011 16:08:02 +0100
Message-ID: <1322060876.30168.18.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 16:07:56 +0100
In-Reply-To: <1322060131.30168.15.camel@Abyss>
References: <1322060131.30168.15.camel@Abyss>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
	schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4988314752036575231=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4988314752036575231==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-YFk3Qd7bSF4SLMiJwwzE"


--=-YFk3Qd7bSF4SLMiJwwzE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Pluggable schedulers' code knows what (and when) to lock better than
generic code, let's delegate to them all the concurrency related issues.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 84b3e46aa7d2 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Wed Nov 23 12:03:37 2011 +0000
+++ b/xen/common/sched_credit.c	Wed Nov 23 15:09:14 2011 +0100
@@ -161,6 +161,7 @@ struct csched_dom {
  * System-wide private data
  */
 struct csched_private {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
     spinlock_t lock;
     struct list_head active_sdom;
     uint32_t ncpus;
@@ -800,6 +801,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Protect both get and put branches with the pluggable scheduler
+     * lock. Runq lock not needed anywhere in here. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit.weight =3D sdom->weight;
@@ -809,8 +814,6 @@ csched_dom_cntl(
     {
         ASSERT(op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo);
=20
-        spin_lock_irqsave(&prv->lock, flags);
-
         if ( op->u.credit.weight !=3D 0 )
         {
             if ( !list_empty(&sdom->active_sdom_elem) )
@@ -824,9 +827,10 @@ csched_dom_cntl(
         if ( op->u.credit.cap !=3D (uint16_t)~0U )
             sdom->cap =3D op->u.credit.cap;
=20
-        spin_unlock_irqrestore(&prv->lock, flags);
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 84b3e46aa7d2 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Wed Nov 23 12:03:37 2011 +0000
+++ b/xen/common/sched_credit2.c	Wed Nov 23 15:09:14 2011 +0100
@@ -1384,6 +1384,10 @@ csched_dom_cntl(
     struct csched_private *prv =3D CSCHED_PRIV(ops);
     unsigned long flags;
=20
+    /* Must hold csched_priv lock to read and update sdom,
+     * runq lock to update csvcs. */
+    spin_lock_irqsave(&prv->lock, flags);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         op->u.credit2.weight =3D sdom->weight;
@@ -1397,10 +1401,6 @@ csched_dom_cntl(
             struct list_head *iter;
             int old_weight;
=20
-            /* Must hold csched_priv lock to update sdom, runq lock to
-             * update csvcs. */
-            spin_lock_irqsave(&prv->lock, flags);
-
             old_weight =3D sdom->weight;
=20
             sdom->weight =3D op->u.credit2.weight;
@@ -1411,22 +1411,23 @@ csched_dom_cntl(
                 struct csched_vcpu *svc =3D list_entry(iter, struct csched=
_vcpu, sdom_elem);
=20
                 /* NB: Locking order is important here.  Because we grab t=
his lock here, we
-                 * must never lock csched_priv.lock if we're holding a run=
queue
-                 * lock. */
-                vcpu_schedule_lock_irq(svc->vcpu);
+                 * must never lock csched_priv.lock if we're holding a run=
queue lock.
+                 * Also, calling vcpu_schedule_lock() is enough, since IRQ=
s have already
+                 * been disabled. */
+                vcpu_schedule_lock(svc->vcpu);
=20
                 BUG_ON(svc->rqd !=3D RQD(ops, svc->vcpu->processor));
=20
                 svc->weight =3D sdom->weight;
                 update_max_weight(svc->rqd, svc->weight, old_weight);
=20
-                vcpu_schedule_unlock_irq(svc->vcpu);
+                vcpu_schedule_unlock(svc->vcpu);
             }
-
-            spin_unlock_irqrestore(&prv->lock, flags);
         }
     }
=20
+    spin_unlock_irqrestore(&prv->lock, flags);
+
     return 0;
 }
=20
diff -r 84b3e46aa7d2 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Nov 23 12:03:37 2011 +0000
+++ b/xen/common/sched_sedf.c	Wed Nov 23 15:09:14 2011 +0100
@@ -1397,18 +1397,28 @@ static int sedf_adjust_weights(struct cp
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
     struct vcpu *v;
-    int rc;
+    int rc =3D 0;
=20
     PRINT(2,"sedf_adjust was called, domain-id %i new period %"PRIu64" "
           "new slice %"PRIu64"\nlatency %"PRIu64" extra:%s\n",
           p->domain_id, op->u.sedf.period, op->u.sedf.slice,
           op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
=20
+    /* Serialize everything against runq lock to prevent concurrent update
+     * (notice all non-current VCPUs of the domain have been paused in the
+     * caller). */
+    if ( p =3D=3D current->domain )
+        vcpu_schedule_lock_irq(current);
+
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
         /* Check for sane parameters. */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         if ( op->u.sedf.weight )
         {
             if ( (op->u.sedf.extratime & EXTRA_AWARE) &&
@@ -1443,7 +1453,11 @@ static int sedf_adjust(const struct sche
                      (op->u.sedf.period < PERIOD_MIN) ||
                      (op->u.sedf.slice  > op->u.sedf.period) ||
                      (op->u.sedf.slice  < SLICE_MIN) )
-                    return -EINVAL;
+                {
+                    rc =3D -EINVAL;
+                    goto out;
+                }
+
                 EDOM_INFO(v)->weight =3D 0;
                 EDOM_INFO(v)->extraweight =3D 0;
                 EDOM_INFO(v)->period_orig =3D=20
@@ -1455,7 +1469,7 @@ static int sedf_adjust(const struct sche
=20
         rc =3D sedf_adjust_weights(p->cpupool, op);
         if ( rc )
-            return rc;
+            goto out;
=20
         for_each_vcpu ( p, v )
         {
@@ -1469,7 +1483,11 @@ static int sedf_adjust(const struct sche
     else if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
     {
         if ( p->vcpu[0] =3D=3D NULL )
-            return -EINVAL;
+        {
+            rc =3D -EINVAL;
+            goto out;
+        }
+
         op->u.sedf.period    =3D EDOM_INFO(p->vcpu[0])->period;
         op->u.sedf.slice     =3D EDOM_INFO(p->vcpu[0])->slice;
         op->u.sedf.extratime =3D EDOM_INFO(p->vcpu[0])->status & EXTRA_AWA=
RE;
@@ -1477,8 +1495,12 @@ static int sedf_adjust(const struct sche
         op->u.sedf.weight    =3D EDOM_INFO(p->vcpu[0])->weight;
     }
=20
-    PRINT(2,"sedf_adjust_finished\n");
-    return 0;
+out:
+    if ( p =3D=3D current->domain )
+        vcpu_schedule_unlock_irq(current);
+
+    PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
+    return rc;
 }
=20
 const struct scheduler sched_sedf_def =3D {
diff -r 84b3e46aa7d2 xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Nov 23 12:03:37 2011 +0000
+++ b/xen/common/schedule.c	Wed Nov 23 15:09:14 2011 +0100
@@ -1015,15 +1015,8 @@ long sched_adjust(struct domain *d, stru
=20
     /*
      * Most VCPUs we can simply pause. If we are adjusting this VCPU then
-     * we acquire the local schedule_lock to guard against concurrent upda=
tes.
-     *
-     * We only acquire the local schedule lock after we have paused all ot=
her
-     * VCPUs in this domain. There are two reasons for this:
-     * 1- We don't want to hold up interrupts as pausing a VCPU can
-     *    trigger a tlb shootdown.
-     * 2- Pausing other VCPUs involves briefly locking the schedule
-     *    lock of the CPU they are running on. This CPU could be the
-     *    same as ours.
+     * concurrent updates shall be prevented within the actual pluggable
+     * scheduler.
      */
=20
     for_each_vcpu ( d, v )
@@ -1032,15 +1025,9 @@ long sched_adjust(struct domain *d, stru
             vcpu_pause(v);
     }
=20
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_lock_irq(current);
-
     if ( (ret =3D SCHED_OP(DOM2OP(d), adjust, d, op)) =3D=3D 0 )
         TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
=20
-    if ( d =3D=3D current->domain )
-        vcpu_schedule_unlock_irq(current);
-
     for_each_vcpu ( d, v )
     {
         if ( v !=3D current )

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-YFk3Qd7bSF4SLMiJwwzE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7NDEwACgkQk4XaBE3IOsSeCQCgoJCJsYia/X/oVQMLDtYBGLCi
sckAnR9wYQJXIJ1KE9lISJkdrg5g3oOl
=vyX5
-----END PGP SIGNATURE-----

--=-YFk3Qd7bSF4SLMiJwwzE--



--===============4988314752036575231==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4988314752036575231==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:10:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:10:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTESW-00085k-Kx; Wed, 23 Nov 2011 15:10:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTESV-00085A-4e
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:09:59 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322060968!2736282!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31620 invoked from network); 23 Nov 2011 15:09:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 15:09:29 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73385737; Wed, 23 Nov 2011 16:09:28 +0100
Message-ID: <1322060962.30168.20.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 16:09:22 +0100
In-Reply-To: <1322060131.30168.15.camel@Abyss>
References: <1322060131.30168.15.camel@Abyss>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [RFC/RFT][PATCH 2 of 3] Remove VCPU pausing while
 adjusting domain scheduling parameters.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1264720008416452509=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1264720008416452509==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-iUixRJLLusaLlDYRB4m1"


--=-iUixRJLLusaLlDYRB4m1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Pausing all the non-current VCPUs of a domain while changing its
scheduling parameters is dangerous (what if two VCPUs try to pause
all the other VCPUs but themselves at the same time?). Moreover, it
does not appear to be needed, since:
 - races are (or should be) avoided within each pluggable scheduler
   by means of proper locking;
 - changes in values using during actual scheduling are (or should be)
   prevented by runq locking.

Just remove it.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 6b5e2eb81706 xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Nov 23 15:09:14 2011 +0100
+++ b/xen/common/schedule.c	Wed Nov 23 15:20:28 2011 +0100
@@ -1005,7 +1005,6 @@ int sched_id(void)
 /* Adjust scheduling parameter for a given domain. */
 long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
 {
-    struct vcpu *v;
     long ret;
    =20
     if ( (op->sched_id !=3D DOM2OP(d)->sched_id) ||
@@ -1013,27 +1012,11 @@ long sched_adjust(struct domain *d, stru
           (op->cmd !=3D XEN_DOMCTL_SCHEDOP_getinfo)) )
         return -EINVAL;
=20
-    /*
-     * Most VCPUs we can simply pause. If we are adjusting this VCPU then
-     * concurrent updates shall be prevented within the actual pluggable
-     * scheduler.
-     */
-
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_pause(v);
-    }
-
+    /* NB: the pluggable scheduler code needs to take care
+     * of locking by itself. */
     if ( (ret =3D SCHED_OP(DOM2OP(d), adjust, d, op)) =3D=3D 0 )
         TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
=20
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_unpause(v);
-    }
-
     return ret;
 }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-iUixRJLLusaLlDYRB4m1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7NDKIACgkQk4XaBE3IOsSxLwCgh2gB8Ci33mMrIK8rSZ47h7s7
SfsAnRbJDt855eGyTrffJzKMwUdFvyxB
=16Lq
-----END PGP SIGNATURE-----

--=-iUixRJLLusaLlDYRB4m1--



--===============1264720008416452509==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1264720008416452509==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:10:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:10:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTESW-00085k-Kx; Wed, 23 Nov 2011 15:10:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTESV-00085A-4e
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:09:59 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322060968!2736282!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31620 invoked from network); 23 Nov 2011 15:09:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 15:09:29 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73385737; Wed, 23 Nov 2011 16:09:28 +0100
Message-ID: <1322060962.30168.20.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 16:09:22 +0100
In-Reply-To: <1322060131.30168.15.camel@Abyss>
References: <1322060131.30168.15.camel@Abyss>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [RFC/RFT][PATCH 2 of 3] Remove VCPU pausing while
 adjusting domain scheduling parameters.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1264720008416452509=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1264720008416452509==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-iUixRJLLusaLlDYRB4m1"


--=-iUixRJLLusaLlDYRB4m1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Pausing all the non-current VCPUs of a domain while changing its
scheduling parameters is dangerous (what if two VCPUs try to pause
all the other VCPUs but themselves at the same time?). Moreover, it
does not appear to be needed, since:
 - races are (or should be) avoided within each pluggable scheduler
   by means of proper locking;
 - changes in values using during actual scheduling are (or should be)
   prevented by runq locking.

Just remove it.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 6b5e2eb81706 xen/common/schedule.c
--- a/xen/common/schedule.c	Wed Nov 23 15:09:14 2011 +0100
+++ b/xen/common/schedule.c	Wed Nov 23 15:20:28 2011 +0100
@@ -1005,7 +1005,6 @@ int sched_id(void)
 /* Adjust scheduling parameter for a given domain. */
 long sched_adjust(struct domain *d, struct xen_domctl_scheduler_op *op)
 {
-    struct vcpu *v;
     long ret;
    =20
     if ( (op->sched_id !=3D DOM2OP(d)->sched_id) ||
@@ -1013,27 +1012,11 @@ long sched_adjust(struct domain *d, stru
           (op->cmd !=3D XEN_DOMCTL_SCHEDOP_getinfo)) )
         return -EINVAL;
=20
-    /*
-     * Most VCPUs we can simply pause. If we are adjusting this VCPU then
-     * concurrent updates shall be prevented within the actual pluggable
-     * scheduler.
-     */
-
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_pause(v);
-    }
-
+    /* NB: the pluggable scheduler code needs to take care
+     * of locking by itself. */
     if ( (ret =3D SCHED_OP(DOM2OP(d), adjust, d, op)) =3D=3D 0 )
         TRACE_1D(TRC_SCHED_ADJDOM, d->domain_id);
=20
-    for_each_vcpu ( d, v )
-    {
-        if ( v !=3D current )
-            vcpu_unpause(v);
-    }
-
     return ret;
 }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-iUixRJLLusaLlDYRB4m1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7NDKIACgkQk4XaBE3IOsSxLwCgh2gB8Ci33mMrIK8rSZ47h7s7
SfsAnRbJDt855eGyTrffJzKMwUdFvyxB
=16Lq
-----END PGP SIGNATURE-----

--=-iUixRJLLusaLlDYRB4m1--



--===============1264720008416452509==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1264720008416452509==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:11:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTEU8-0008Ho-TB; Wed, 23 Nov 2011 15:11:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTEU7-0008GZ-9B
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:11:39 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322061068!4669015!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8047 invoked from network); 23 Nov 2011 15:11:09 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 15:11:09 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73385791; Wed, 23 Nov 2011 16:11:08 +0100
Message-ID: <1322061062.30168.22.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 16:11:02 +0100
In-Reply-To: <1322060131.30168.15.camel@Abyss>
References: <1322060131.30168.15.camel@Abyss>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [RFC/RFT][PATCH 3 of 3] Introduce proper locking in
	sedf.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0241393363426667974=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0241393363426667974==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-IjfV40v9ap5/aVZ3f22v"


--=-IjfV40v9ap5/aVZ3f22v
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Add a global scheduler lock in sedf, as we have in credit and credit2,
mostly for preventing races while adjusting scheduling parameters. Also,
add runq locking within sedf_adjust_weights since we are touching
scheduling sensitive values in there.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 17653f5c2995 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Nov 23 15:20:28 2011 +0100
+++ b/xen/common/sched_sedf.c	Wed Nov 23 15:36:22 2011 +0100
@@ -61,6 +61,11 @@ struct sedf_dom_info {
     struct domain  *domain;
 };
=20
+struct sedf_priv_info {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
+    spinlock_t lock;
+};
+
 struct sedf_vcpu_info {
     struct vcpu *vcpu;
     struct list_head list;
@@ -115,6 +120,8 @@ struct sedf_cpu_info {
     s_time_t         current_slice_expires;
 };
=20
+#define SEDF_PRIV(_ops) \
+    ((struct sedf_priv_info *)((_ops)->sched_data))
 #define EDOM_INFO(d)   ((struct sedf_vcpu_info *)((d)->sched_priv))
 #define CPU_INFO(cpu)  \
     ((struct sedf_cpu_info *)per_cpu(schedule_data, cpu).sched_priv)
@@ -772,6 +779,31 @@ static struct task_slice sedf_do_extra_s
 }
=20

+static int sedf_init(struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D xzalloc(struct sedf_priv_info);
+    if ( prv =3D=3D NULL )
+        return -ENOMEM;
+
+    ops->sched_data =3D prv;
+    spin_lock_init(&prv->lock);
+
+    return 0;
+}
+
+
+static void sedf_deinit(const struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D SEDF_PRIV(ops);
+    if ( prv !=3D NULL )
+        xfree(prv);
+}
+
+
 /* Main scheduling function
    Reasons for calling this function are:
    -timeslice for the current period used up
@@ -1247,11 +1279,18 @@ static void sedf_dump_domain(struct vcpu
 /* dumps all domains on the specified cpu */
 static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
 {
+    struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
     struct list_head      *list, *queue, *tmp;
     struct sedf_vcpu_info *d_inf;
     struct domain         *d;
     struct vcpu    *ed;
     int loop =3D 0;
+    unsigned long flags;
+
+    /* Lock the scheduler, we want to be sure we dump a
+     * consistent set of parameters.
+     */
+    spin_lock_irqsave(&prv->lock, flags);
 =20
     printk("now=3D%"PRIu64"\n",NOW());
     queue =3D RUNQ(i);
@@ -1316,6 +1355,8 @@ static void sedf_dump_cpu_state(const st
         }
     }
     rcu_read_unlock(&domlist_read_lock);
+
+    spin_unlock_irqrestore(&prv->lock, flags);
 }
=20

@@ -1335,7 +1376,9 @@ static int sedf_adjust_weights(struct cp
         return -ENOMEM;
     }
=20
-    /* Sum across all weights. */
+    /* Sum across all weights. Notice that no runq locking is needed
+     * here: the caller holds sedf_priv_info->lock and we're not changing
+     * anything that is accessed during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1365,7 +1408,9 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight. Unlike above, we
+     * need to take thr runq lock for the various VCPUs: we're modyfing
+     * slice and period which are referenced during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1375,12 +1420,15 @@ static int sedf_adjust_weights(struct cp
                 continue;
             if ( EDOM_INFO(p)->weight )
             {
+                /* Interrupts already off */
+                vcpu_schedule_lock(p);
                 EDOM_INFO(p)->period_orig =3D=20
                     EDOM_INFO(p)->period  =3D WEIGHT_PERIOD;
                 EDOM_INFO(p)->slice_orig  =3D
                     EDOM_INFO(p)->slice   =3D=20
                     (EDOM_INFO(p)->weight *
                      (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu])) / sumw[c=
pu];
+                vcpu_schedule_unlock(p);
             }
         }
     }
@@ -1396,6 +1444,8 @@ static int sedf_adjust_weights(struct cp
 /* set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
+    struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
+    unsigned long flags;
     struct vcpu *v;
     int rc =3D 0;
=20
@@ -1404,11 +1454,12 @@ static int sedf_adjust(const struct sche
           p->domain_id, op->u.sedf.period, op->u.sedf.slice,
           op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
=20
-    /* Serialize everything against runq lock to prevent concurrent update
-     * (notice all non-current VCPUs of the domain have been paused in the
-     * caller). */
-    if ( p =3D=3D current->domain )
-        vcpu_schedule_lock_irq(current);
+    /* Serialize against the pluggable scheduler lock to protect from
+     * concurrent updates. We need to take the runq lock for the VCPUs
+     * as well, since we are touching extraweight, weight, slice and
+     * period. As in sched_credit2.c, runq locks nest inside the
+     * pluggable scheduler lock. */
+    spin_lock_irqsave(&prv->lock, flags);
=20
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
@@ -1427,43 +1478,52 @@ static int sedf_adjust(const struct sche
                 /* Weight-driven domains with extratime only. */
                 for_each_vcpu ( p, v )
                 {
+                    /* (Here and everywhere in the following) IRQs are alr=
eady off,
+                     * hence vcpu_spin_lock() is the one. */
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
                     EDOM_INFO(v)->weight =3D 0;
                     EDOM_INFO(v)->slice =3D 0;
                     EDOM_INFO(v)->period =3D WEIGHT_PERIOD;
+                    vcpu_schedule_unlock(v);
                 }
             }
             else
             {
                 /* Weight-driven domains with real-time execution. */
-                for_each_vcpu ( p, v )
+                for_each_vcpu ( p, v ) {
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
+                    vcpu_schedule_lock(v);
+                }
             }
         }
         else
         {
+            /*
+             * Sanity checking: note that disabling extra weight requires
+             * that we set a non-zero slice.
+             */
+            if ( (op->u.sedf.period > PERIOD_MAX) ||
+                 (op->u.sedf.period < PERIOD_MIN) ||
+                 (op->u.sedf.slice  > op->u.sedf.period) ||
+                 (op->u.sedf.slice  < SLICE_MIN) )
+            {
+                rc =3D -EINVAL;
+                goto out;
+            }
+
             /* Time-driven domains. */
             for_each_vcpu ( p, v )
             {
-                /*
-                 * Sanity checking: note that disabling extra weight requi=
res
-                 * that we set a non-zero slice.
-                 */
-                if ( (op->u.sedf.period > PERIOD_MAX) ||
-                     (op->u.sedf.period < PERIOD_MIN) ||
-                     (op->u.sedf.slice  > op->u.sedf.period) ||
-                     (op->u.sedf.slice  < SLICE_MIN) )
-                {
-                    rc =3D -EINVAL;
-                    goto out;
-                }
-
+                vcpu_schedule_lock(v);
                 EDOM_INFO(v)->weight =3D 0;
                 EDOM_INFO(v)->extraweight =3D 0;
                 EDOM_INFO(v)->period_orig =3D=20
                     EDOM_INFO(v)->period  =3D op->u.sedf.period;
                 EDOM_INFO(v)->slice_orig  =3D=20
                     EDOM_INFO(v)->slice   =3D op->u.sedf.slice;
+                vcpu_schedule_unlock(v);
             }
         }
=20
@@ -1473,11 +1533,13 @@ static int sedf_adjust(const struct sche
=20
         for_each_vcpu ( p, v )
         {
+            vcpu_schedule_lock(v);
             EDOM_INFO(v)->status  =3D=20
                 (EDOM_INFO(v)->status &
                  ~EXTRA_AWARE) | (op->u.sedf.extratime & EXTRA_AWARE);
             EDOM_INFO(v)->latency =3D op->u.sedf.latency;
             extraq_check(v);
+            vcpu_schedule_lock(v);
         }
     }
     else if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
@@ -1496,17 +1558,19 @@ static int sedf_adjust(const struct sche
     }
=20
 out:
-    if ( p =3D=3D current->domain )
-        vcpu_schedule_unlock_irq(current);
+    spin_unlock_irqrestore(&prv->lock, flags);
=20
     PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
     return rc;
 }
=20
+static struct sedf_priv_info _sedf_priv;
+
 const struct scheduler sched_sedf_def =3D {
-    .name     =3D "Simple EDF Scheduler",
-    .opt_name =3D "sedf",
-    .sched_id =3D XEN_SCHEDULER_SEDF,
+    .name           =3D "Simple EDF Scheduler",
+    .opt_name       =3D "sedf",
+    .sched_id       =3D XEN_SCHEDULER_SEDF,
+    .sched_data     =3D &_sedf_priv,
    =20
     .init_domain    =3D sedf_init_domain,
     .destroy_domain =3D sedf_destroy_domain,
@@ -1520,6 +1584,9 @@ const struct scheduler sched_sedf_def =3D=20
     .alloc_domdata  =3D sedf_alloc_domdata,
     .free_domdata   =3D sedf_free_domdata,
=20
+    .init           =3D sedf_init,
+    .deinit         =3D sedf_deinit,
+
     .do_schedule    =3D sedf_do_schedule,
     .pick_cpu       =3D sedf_pick_cpu,
     .dump_cpu_state =3D sedf_dump_cpu_state,

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-IjfV40v9ap5/aVZ3f22v
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7NDQYACgkQk4XaBE3IOsTwSACfZG19agcDoI2QpTUucS6PzrFv
HI8An0lOVe9XzYwMQbzTGduA0j0SE2XF
=Egjy
-----END PGP SIGNATURE-----

--=-IjfV40v9ap5/aVZ3f22v--



--===============0241393363426667974==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0241393363426667974==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:11:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTEU8-0008Ho-TB; Wed, 23 Nov 2011 15:11:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTEU7-0008GZ-9B
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:11:39 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322061068!4669015!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8047 invoked from network); 23 Nov 2011 15:11:09 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 15:11:09 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.21]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73385791; Wed, 23 Nov 2011 16:11:08 +0100
Message-ID: <1322061062.30168.22.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 16:11:02 +0100
In-Reply-To: <1322060131.30168.15.camel@Abyss>
References: <1322060131.30168.15.camel@Abyss>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [RFC/RFT][PATCH 3 of 3] Introduce proper locking in
	sedf.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0241393363426667974=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0241393363426667974==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-IjfV40v9ap5/aVZ3f22v"


--=-IjfV40v9ap5/aVZ3f22v
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Add a global scheduler lock in sedf, as we have in credit and credit2,
mostly for preventing races while adjusting scheduling parameters. Also,
add runq locking within sedf_adjust_weights since we are touching
scheduling sensitive values in there.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 17653f5c2995 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Nov 23 15:20:28 2011 +0100
+++ b/xen/common/sched_sedf.c	Wed Nov 23 15:36:22 2011 +0100
@@ -61,6 +61,11 @@ struct sedf_dom_info {
     struct domain  *domain;
 };
=20
+struct sedf_priv_info {
+    /* lock for the whole pluggable scheduler, nests inside cpupool_lock *=
/
+    spinlock_t lock;
+};
+
 struct sedf_vcpu_info {
     struct vcpu *vcpu;
     struct list_head list;
@@ -115,6 +120,8 @@ struct sedf_cpu_info {
     s_time_t         current_slice_expires;
 };
=20
+#define SEDF_PRIV(_ops) \
+    ((struct sedf_priv_info *)((_ops)->sched_data))
 #define EDOM_INFO(d)   ((struct sedf_vcpu_info *)((d)->sched_priv))
 #define CPU_INFO(cpu)  \
     ((struct sedf_cpu_info *)per_cpu(schedule_data, cpu).sched_priv)
@@ -772,6 +779,31 @@ static struct task_slice sedf_do_extra_s
 }
=20

+static int sedf_init(struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D xzalloc(struct sedf_priv_info);
+    if ( prv =3D=3D NULL )
+        return -ENOMEM;
+
+    ops->sched_data =3D prv;
+    spin_lock_init(&prv->lock);
+
+    return 0;
+}
+
+
+static void sedf_deinit(const struct scheduler *ops)
+{
+    struct sedf_priv_info *prv;
+
+    prv =3D SEDF_PRIV(ops);
+    if ( prv !=3D NULL )
+        xfree(prv);
+}
+
+
 /* Main scheduling function
    Reasons for calling this function are:
    -timeslice for the current period used up
@@ -1247,11 +1279,18 @@ static void sedf_dump_domain(struct vcpu
 /* dumps all domains on the specified cpu */
 static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
 {
+    struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
     struct list_head      *list, *queue, *tmp;
     struct sedf_vcpu_info *d_inf;
     struct domain         *d;
     struct vcpu    *ed;
     int loop =3D 0;
+    unsigned long flags;
+
+    /* Lock the scheduler, we want to be sure we dump a
+     * consistent set of parameters.
+     */
+    spin_lock_irqsave(&prv->lock, flags);
 =20
     printk("now=3D%"PRIu64"\n",NOW());
     queue =3D RUNQ(i);
@@ -1316,6 +1355,8 @@ static void sedf_dump_cpu_state(const st
         }
     }
     rcu_read_unlock(&domlist_read_lock);
+
+    spin_unlock_irqrestore(&prv->lock, flags);
 }
=20

@@ -1335,7 +1376,9 @@ static int sedf_adjust_weights(struct cp
         return -ENOMEM;
     }
=20
-    /* Sum across all weights. */
+    /* Sum across all weights. Notice that no runq locking is needed
+     * here: the caller holds sedf_priv_info->lock and we're not changing
+     * anything that is accessed during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1365,7 +1408,9 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. */
+    /* Adjust all slices (and periods) to the new weight. Unlike above, we
+     * need to take thr runq lock for the various VCPUs: we're modyfing
+     * slice and period which are referenced during scheduling. */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1375,12 +1420,15 @@ static int sedf_adjust_weights(struct cp
                 continue;
             if ( EDOM_INFO(p)->weight )
             {
+                /* Interrupts already off */
+                vcpu_schedule_lock(p);
                 EDOM_INFO(p)->period_orig =3D=20
                     EDOM_INFO(p)->period  =3D WEIGHT_PERIOD;
                 EDOM_INFO(p)->slice_orig  =3D
                     EDOM_INFO(p)->slice   =3D=20
                     (EDOM_INFO(p)->weight *
                      (WEIGHT_PERIOD - WEIGHT_SAFETY - sumt[cpu])) / sumw[c=
pu];
+                vcpu_schedule_unlock(p);
             }
         }
     }
@@ -1396,6 +1444,8 @@ static int sedf_adjust_weights(struct cp
 /* set or fetch domain scheduling parameters */
 static int sedf_adjust(const struct scheduler *ops, struct domain *p, stru=
ct xen_domctl_scheduler_op *op)
 {
+    struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
+    unsigned long flags;
     struct vcpu *v;
     int rc =3D 0;
=20
@@ -1404,11 +1454,12 @@ static int sedf_adjust(const struct sche
           p->domain_id, op->u.sedf.period, op->u.sedf.slice,
           op->u.sedf.latency, (op->u.sedf.extratime)?"yes":"no");
=20
-    /* Serialize everything against runq lock to prevent concurrent update
-     * (notice all non-current VCPUs of the domain have been paused in the
-     * caller). */
-    if ( p =3D=3D current->domain )
-        vcpu_schedule_lock_irq(current);
+    /* Serialize against the pluggable scheduler lock to protect from
+     * concurrent updates. We need to take the runq lock for the VCPUs
+     * as well, since we are touching extraweight, weight, slice and
+     * period. As in sched_credit2.c, runq locks nest inside the
+     * pluggable scheduler lock. */
+    spin_lock_irqsave(&prv->lock, flags);
=20
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
@@ -1427,43 +1478,52 @@ static int sedf_adjust(const struct sche
                 /* Weight-driven domains with extratime only. */
                 for_each_vcpu ( p, v )
                 {
+                    /* (Here and everywhere in the following) IRQs are alr=
eady off,
+                     * hence vcpu_spin_lock() is the one. */
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->extraweight =3D op->u.sedf.weight;
                     EDOM_INFO(v)->weight =3D 0;
                     EDOM_INFO(v)->slice =3D 0;
                     EDOM_INFO(v)->period =3D WEIGHT_PERIOD;
+                    vcpu_schedule_unlock(v);
                 }
             }
             else
             {
                 /* Weight-driven domains with real-time execution. */
-                for_each_vcpu ( p, v )
+                for_each_vcpu ( p, v ) {
+                    vcpu_schedule_lock(v);
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
+                    vcpu_schedule_lock(v);
+                }
             }
         }
         else
         {
+            /*
+             * Sanity checking: note that disabling extra weight requires
+             * that we set a non-zero slice.
+             */
+            if ( (op->u.sedf.period > PERIOD_MAX) ||
+                 (op->u.sedf.period < PERIOD_MIN) ||
+                 (op->u.sedf.slice  > op->u.sedf.period) ||
+                 (op->u.sedf.slice  < SLICE_MIN) )
+            {
+                rc =3D -EINVAL;
+                goto out;
+            }
+
             /* Time-driven domains. */
             for_each_vcpu ( p, v )
             {
-                /*
-                 * Sanity checking: note that disabling extra weight requi=
res
-                 * that we set a non-zero slice.
-                 */
-                if ( (op->u.sedf.period > PERIOD_MAX) ||
-                     (op->u.sedf.period < PERIOD_MIN) ||
-                     (op->u.sedf.slice  > op->u.sedf.period) ||
-                     (op->u.sedf.slice  < SLICE_MIN) )
-                {
-                    rc =3D -EINVAL;
-                    goto out;
-                }
-
+                vcpu_schedule_lock(v);
                 EDOM_INFO(v)->weight =3D 0;
                 EDOM_INFO(v)->extraweight =3D 0;
                 EDOM_INFO(v)->period_orig =3D=20
                     EDOM_INFO(v)->period  =3D op->u.sedf.period;
                 EDOM_INFO(v)->slice_orig  =3D=20
                     EDOM_INFO(v)->slice   =3D op->u.sedf.slice;
+                vcpu_schedule_unlock(v);
             }
         }
=20
@@ -1473,11 +1533,13 @@ static int sedf_adjust(const struct sche
=20
         for_each_vcpu ( p, v )
         {
+            vcpu_schedule_lock(v);
             EDOM_INFO(v)->status  =3D=20
                 (EDOM_INFO(v)->status &
                  ~EXTRA_AWARE) | (op->u.sedf.extratime & EXTRA_AWARE);
             EDOM_INFO(v)->latency =3D op->u.sedf.latency;
             extraq_check(v);
+            vcpu_schedule_lock(v);
         }
     }
     else if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_getinfo )
@@ -1496,17 +1558,19 @@ static int sedf_adjust(const struct sche
     }
=20
 out:
-    if ( p =3D=3D current->domain )
-        vcpu_schedule_unlock_irq(current);
+    spin_unlock_irqrestore(&prv->lock, flags);
=20
     PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
     return rc;
 }
=20
+static struct sedf_priv_info _sedf_priv;
+
 const struct scheduler sched_sedf_def =3D {
-    .name     =3D "Simple EDF Scheduler",
-    .opt_name =3D "sedf",
-    .sched_id =3D XEN_SCHEDULER_SEDF,
+    .name           =3D "Simple EDF Scheduler",
+    .opt_name       =3D "sedf",
+    .sched_id       =3D XEN_SCHEDULER_SEDF,
+    .sched_data     =3D &_sedf_priv,
    =20
     .init_domain    =3D sedf_init_domain,
     .destroy_domain =3D sedf_destroy_domain,
@@ -1520,6 +1584,9 @@ const struct scheduler sched_sedf_def =3D=20
     .alloc_domdata  =3D sedf_alloc_domdata,
     .free_domdata   =3D sedf_free_domdata,
=20
+    .init           =3D sedf_init,
+    .deinit         =3D sedf_deinit,
+
     .do_schedule    =3D sedf_do_schedule,
     .pick_cpu       =3D sedf_pick_cpu,
     .dump_cpu_state =3D sedf_dump_cpu_state,

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)



--=-IjfV40v9ap5/aVZ3f22v
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7NDQYACgkQk4XaBE3IOsTwSACfZG19agcDoI2QpTUucS6PzrFv
HI8An0lOVe9XzYwMQbzTGduA0j0SE2XF
=Egjy
-----END PGP SIGNATURE-----

--=-IjfV40v9ap5/aVZ3f22v--



--===============0241393363426667974==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0241393363426667974==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:45:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:45:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF0Q-0001cW-6z; Wed, 23 Nov 2011 15:45:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <levinsasha928@gmail.com>) id 1RTCZF-0003B8-E8
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:08:49 +0000
X-Env-Sender: levinsasha928@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322053698!5451691!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22803 invoked from network); 23 Nov 2011 13:08:19 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:08:19 -0000
Received: by ywn1 with SMTP id 1so2078955ywn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 05:08:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=Qx0HCvnuuL1imrgvLxBo98hS54bBQ1gukaQZvC8Rv0g=;
	b=E+xzFpdMUVGsasbX/CIXMJuUSKJtFBYHAzr70aK3+ABvCSifLNJMrD8yqfejU7TSlW
	bT2pHoX7BpZkvsKTM55Air6bFOT9OkEyXevkWB4ck2Pmi3eeir059B4tsB7za5G5iHHp
	if1iluQfgaHkU+QkpXqjnCXtgUK2nx3FOQzRA=
Received: by 10.204.12.68 with SMTP id w4mr23710195bkw.31.1322053696955;
	Wed, 23 Nov 2011 05:08:16 -0800 (PST)
Received: from [172.16.1.240] (safend2.bb.netvision.net.il. [212.143.23.59])
	by mx.google.com with ESMTPS id e18sm12790099bkr.15.2011.11.23.05.08.13
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 05:08:16 -0800 (PST)
From: Sasha Levin <levinsasha928@gmail.com>
To: Amit Shah <amit.shah@redhat.com>
In-Reply-To: <20111123125657.GH16665@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<20111123125657.GH16665@amit-x200.redhat.com>
Date: Wed, 23 Nov 2011 15:06:04 +0200
Message-ID: <1322053564.3581.19.camel@lappy>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 
X-Mailman-Approved-At: Wed, 23 Nov 2011 15:45:00 +0000
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Miche Baker-Harvey <miche@google.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 18:26 +0530, Amit Shah wrote:
> On (Wed) 23 Nov 2011 [16:08:52], Amit Shah wrote:
> > With this setup, with and without patches, I can spawn two consoles
> > via:
> > 
> > /sbin/agetty /dev/hvc0 9600 vt100
> > /sbin/agetty /dev/hvc1 9600 vt100
> > 
> > (Strange thing is, the second one gives a 'password incorrect' error
> > on login attempts, while the first one logs in fine.  I do remember
> > testing multiple consoles just fine a year and a half back, so no idea
> > why this isn't behaving as expected -- but it mostly looks like a
> > userspace issue rather than kernel one.)
> 
> Right -- when I test this on the Fedora 11 VM I used back then, the
> two consoles work just fine without these patches.  When I use
> something newer (F14), I get the weird password rejection, with and
> without your patches.

It's not a weird password rejection, it's probably not set as a secure
terminal :)

Try adding hvc1 to /etc/securetty on the guest.

-- 

Sasha.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:45:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:45:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF0Q-0001cW-6z; Wed, 23 Nov 2011 15:45:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <levinsasha928@gmail.com>) id 1RTCZF-0003B8-E8
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:08:49 +0000
X-Env-Sender: levinsasha928@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322053698!5451691!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22803 invoked from network); 23 Nov 2011 13:08:19 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:08:19 -0000
Received: by ywn1 with SMTP id 1so2078955ywn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 05:08:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=subject:from:to:cc:in-reply-to:references:content-type:date
	:message-id:mime-version:x-mailer:content-transfer-encoding;
	bh=Qx0HCvnuuL1imrgvLxBo98hS54bBQ1gukaQZvC8Rv0g=;
	b=E+xzFpdMUVGsasbX/CIXMJuUSKJtFBYHAzr70aK3+ABvCSifLNJMrD8yqfejU7TSlW
	bT2pHoX7BpZkvsKTM55Air6bFOT9OkEyXevkWB4ck2Pmi3eeir059B4tsB7za5G5iHHp
	if1iluQfgaHkU+QkpXqjnCXtgUK2nx3FOQzRA=
Received: by 10.204.12.68 with SMTP id w4mr23710195bkw.31.1322053696955;
	Wed, 23 Nov 2011 05:08:16 -0800 (PST)
Received: from [172.16.1.240] (safend2.bb.netvision.net.il. [212.143.23.59])
	by mx.google.com with ESMTPS id e18sm12790099bkr.15.2011.11.23.05.08.13
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 05:08:16 -0800 (PST)
From: Sasha Levin <levinsasha928@gmail.com>
To: Amit Shah <amit.shah@redhat.com>
In-Reply-To: <20111123125657.GH16665@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<20111123125657.GH16665@amit-x200.redhat.com>
Date: Wed, 23 Nov 2011 15:06:04 +0200
Message-ID: <1322053564.3581.19.camel@lappy>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 
X-Mailman-Approved-At: Wed, 23 Nov 2011 15:45:00 +0000
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Miche Baker-Harvey <miche@google.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 18:26 +0530, Amit Shah wrote:
> On (Wed) 23 Nov 2011 [16:08:52], Amit Shah wrote:
> > With this setup, with and without patches, I can spawn two consoles
> > via:
> > 
> > /sbin/agetty /dev/hvc0 9600 vt100
> > /sbin/agetty /dev/hvc1 9600 vt100
> > 
> > (Strange thing is, the second one gives a 'password incorrect' error
> > on login attempts, while the first one logs in fine.  I do remember
> > testing multiple consoles just fine a year and a half back, so no idea
> > why this isn't behaving as expected -- but it mostly looks like a
> > userspace issue rather than kernel one.)
> 
> Right -- when I test this on the Fedora 11 VM I used back then, the
> two consoles work just fine without these patches.  When I use
> something newer (F14), I get the weird password rejection, with and
> without your patches.

It's not a weird password rejection, it's probably not set as a secure
terminal :)

Try adding hvc1 to /etc/securetty on the guest.

-- 

Sasha.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:45:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:45:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF0P-0001cP-Qs; Wed, 23 Nov 2011 15:45:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sploving1@gmail.com>) id 1RTCTw-0002yt-UG
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:03:21 +0000
X-Env-Sender: sploving1@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322053370!3752054!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21160 invoked from network); 23 Nov 2011 13:02:50 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:02:50 -0000
Received: by bkbzt12 with SMTP id zt12so2098195bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 05:02:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=jhmBs9mpoxWLkMERL9ErfzuJfiacYoKmnc6tx/rCIbU=;
	b=E+vlKDwvwebNaXGvJaDS5jDNUtoPw53oU5MoExMMdpH3sGZOUXhjoW3pRa1bYnDGxe
	jXSTXU04U4BTawzL5lw543tGT9rhsw6QEnz9xEkMDSZieNJWfBNK8ymta+T5hFxwVFX3
	JrBaO29NPl2rrikVZX9J/gHAXr8re1Kp8Oppc=
MIME-Version: 1.0
Received: by 10.205.126.13 with SMTP id gu13mr24056443bkc.114.1322053370120;
	Wed, 23 Nov 2011 05:02:50 -0800 (PST)
Received: by 10.205.125.139 with HTTP; Wed, 23 Nov 2011 05:02:50 -0800 (PST)
Date: Wed, 23 Nov 2011 21:02:50 +0800
Message-ID: <CAP=GMUHJQzK=q2hBxkmu9trPxDbecKNb2j+Rp-=z-YeEmc=sXw@mail.gmail.com>
From: Baozeng <sploving1@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 23 Nov 2011 15:45:00 +0000
Subject: [Xen-devel] how to objdump xen to print its function?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello all,
I want to see the assemble code of Xen. So I use make world and make
install to generate xen-4.1.2.gz. and unzip it to be the ELF file
xen-4.1.2. Then I use objdump tool to see the assemble code.
I found xen has only one section .text. Then I wonder where is the
section .data?
# objdump -h /boot/xen-4.1.2

/boot/xen-4.1.2:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0013d41c  00100000  00100000  00000080  2**6
                  CONTENTS, ALLOC, LOAD, CODE

Another question: how do I know which assemble code in the ELF file
corresponds to the source code line "dom0->is_privileged=1" in
xen\arch\x86\setup.c file? In other words, how could I show the
function name in the assemble code file? by adding -g option when
making xen?
-- 
     Best Regards,
                                                                 Baozeng Ding
                                                                 OSTG,NFS,ISCAS

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:45:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:45:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF0P-0001cP-Qs; Wed, 23 Nov 2011 15:45:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sploving1@gmail.com>) id 1RTCTw-0002yt-UG
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 13:03:21 +0000
X-Env-Sender: sploving1@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322053370!3752054!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21160 invoked from network); 23 Nov 2011 13:02:50 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 13:02:50 -0000
Received: by bkbzt12 with SMTP id zt12so2098195bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 05:02:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=jhmBs9mpoxWLkMERL9ErfzuJfiacYoKmnc6tx/rCIbU=;
	b=E+vlKDwvwebNaXGvJaDS5jDNUtoPw53oU5MoExMMdpH3sGZOUXhjoW3pRa1bYnDGxe
	jXSTXU04U4BTawzL5lw543tGT9rhsw6QEnz9xEkMDSZieNJWfBNK8ymta+T5hFxwVFX3
	JrBaO29NPl2rrikVZX9J/gHAXr8re1Kp8Oppc=
MIME-Version: 1.0
Received: by 10.205.126.13 with SMTP id gu13mr24056443bkc.114.1322053370120;
	Wed, 23 Nov 2011 05:02:50 -0800 (PST)
Received: by 10.205.125.139 with HTTP; Wed, 23 Nov 2011 05:02:50 -0800 (PST)
Date: Wed, 23 Nov 2011 21:02:50 +0800
Message-ID: <CAP=GMUHJQzK=q2hBxkmu9trPxDbecKNb2j+Rp-=z-YeEmc=sXw@mail.gmail.com>
From: Baozeng <sploving1@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Wed, 23 Nov 2011 15:45:00 +0000
Subject: [Xen-devel] how to objdump xen to print its function?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello all,
I want to see the assemble code of Xen. So I use make world and make
install to generate xen-4.1.2.gz. and unzip it to be the ELF file
xen-4.1.2. Then I use objdump tool to see the assemble code.
I found xen has only one section .text. Then I wonder where is the
section .data?
# objdump -h /boot/xen-4.1.2

/boot/xen-4.1.2:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0013d41c  00100000  00100000  00000080  2**6
                  CONTENTS, ALLOC, LOAD, CODE

Another question: how do I know which assemble code in the ELF file
corresponds to the source code line "dom0->is_privileged=1" in
xen\arch\x86\setup.c file? In other words, how could I show the
function name in the assemble code file? by adding -g option when
making xen?
-- 
     Best Regards,
                                                                 Baozeng Ding
                                                                 OSTG,NFS,ISCAS

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:45:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:45:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF0P-0001cG-EK; Wed, 23 Nov 2011 15:45:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jonathan.Davies@eu.citrix.com>) id 1RT9RE-0003MJ-Of
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:48:21 +0000
X-Env-Sender: Jonathan.Davies@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322041670!4650843!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6621 invoked from network); 23 Nov 2011 09:47:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:47:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9081753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 09:47:49 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 23 Nov 2011
	09:47:49 +0000
From: Jonathan Davies <Jonathan.Davies@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 09:47:49 +0000
Thread-Topic: [Xen-devel] [PATCH] [OCaml] Release the global lock during
	some	hypercalls
Thread-Index: AcypR0ZQecrqrqeUSKalN+AnPADRcgAfO71Q
Message-ID: <CCE8682617CC8E4693CEF507039F8E86B59B2F52F4@LONPMAILBOX01.citrite.net>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
In-Reply-To: <20171.61030.71499.197458@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 23 Nov 2011 15:45:00 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during
	some	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Ian Jackson wrote:
> Jonathan Davies writes ("[Xen-devel] [PATCH] [OCaml] Release the global
> lock during some hypercalls"):
> > Since libxc is re-entrant, there is no need for the OCaml bindings to
> prevent more than one thread from entering libxc concurrently.
> 
> Well, libxc is supposed to be re-entrant apart from certain calls,
> yes.
> 
> As the main user of the ocaml bindings is xapi, can you confirm that
> you've run this change through a good test of xapi (eg, the Citrix
> XenRT suite) ?

It hasn't yet gone through XenRT, although I've done some manual xapi stress testing in addition to some basic functional verification tests.

It sounds like you'd prefer it to go through XenRT before accepting it here. I'll do so, and then confirm if all is well.

Thanks,
Jonathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:45:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:45:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF0P-0001cG-EK; Wed, 23 Nov 2011 15:45:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jonathan.Davies@eu.citrix.com>) id 1RT9RE-0003MJ-Of
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 09:48:21 +0000
X-Env-Sender: Jonathan.Davies@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322041670!4650843!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6621 invoked from network); 23 Nov 2011 09:47:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 09:47:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; 
   d="scan'208";a="9081753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 09:47:49 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 23 Nov 2011
	09:47:49 +0000
From: Jonathan Davies <Jonathan.Davies@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 09:47:49 +0000
Thread-Topic: [Xen-devel] [PATCH] [OCaml] Release the global lock during
	some	hypercalls
Thread-Index: AcypR0ZQecrqrqeUSKalN+AnPADRcgAfO71Q
Message-ID: <CCE8682617CC8E4693CEF507039F8E86B59B2F52F4@LONPMAILBOX01.citrite.net>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
In-Reply-To: <20171.61030.71499.197458@mariner.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 23 Nov 2011 15:45:00 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during
	some	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Ian Jackson wrote:
> Jonathan Davies writes ("[Xen-devel] [PATCH] [OCaml] Release the global
> lock during some hypercalls"):
> > Since libxc is re-entrant, there is no need for the OCaml bindings to
> prevent more than one thread from entering libxc concurrently.
> 
> Well, libxc is supposed to be re-entrant apart from certain calls,
> yes.
> 
> As the main user of the ocaml bindings is xapi, can you confirm that
> you've run this change through a good test of xapi (eg, the Citrix
> XenRT suite) ?

It hasn't yet gone through XenRT, although I've done some manual xapi stress testing in addition to some basic functional verification tests.

It sounds like you'd prefer it to go through XenRT before accepting it here. I'll do so, and then confirm if all is well.

Thanks,
Jonathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:47:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:47:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF2v-00028Q-Ng; Wed, 23 Nov 2011 15:47:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTF2t-000279-Dc
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:47:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322063225!5345591!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23883 invoked from network); 23 Nov 2011 15:47:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 15:47:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9095851"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 15:47:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 15:47:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTF2O-0005up-UR;
	Wed, 23 Nov 2011 15:47:04 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTF2O-000214-Tq;
	Wed, 23 Nov 2011 15:47:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RTF2O-000214-Tq@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 15:47:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-amd64-oldkern
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job build-amd64-oldkern
test xen-build

Tree: linux http://hg.uk.xensource.com/linux-2.6.18-xen.hg
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://hg.uk.xensource.com/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://hg.uk.xensource.com/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08


  changeset:   24184:4ecd3615e726
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10008 fail [host=woodlouse] / 9958 [host=moss-bug] 9956 [host=moss-bug] 9955 [host=moss-bug] 9951 [host=moss-bug] 9946 [host=potato-beetle] 9941 [host=moss-bug] 9936 [host=moss-bug] 9931 [host=leaf-beetle] 9924 [host=moss-bug] 9915 [host=moss-bug] 9906 [host=moss-bug] 9901 [host=field-cricket] 9893 [host=leaf-beetle] 9884 [host=leaf-beetle] 9878 [host=moss-bug] 9872 [host=moss-bug] 9868 [host=leaf-beetle] 9860 [host=itch-mite] 9857 [host=moss-bug] 9855 [host=itch-mite] 9832 [host=moss-bug] 9817 [host=potato-beetle] 9806 [host=moss-bug] 9803 [host=moss-bug] 9802 [host=moss-bug] 9800 [host=leaf-beetle] 9799 [host=moss-bug] 9789 [host=moss-bug] 9767 [host=moss-bug] 9766 [host=moss-bug] 9765 [host=moss-bug] 9753 [host=moss-bug] 9752 [host=moss-bug] 9749 [host=moss-bug] 9748 [host=moss-bug] 9747 [host=moss-bug] 9746 [host=moss-bug] 9745 [host=potato-beetle] 9743 [host=moss-bug] 9742 [host=moss-bug] 9741 [host=moss-bug] 9663 [host=moss-bug] 9662 [host=potato-beetle] 9661 [host=leaf-beetle] 9659 [host=moss-bug] 9656 [host=moss-bug] 9655 [host=moss-bug] 9652 [host=moss-bug] 9651 [host=moss-bug] 9650 [host=moss-bug] 9649 [host=moss-bug] 9648 [host=moss-bug] 9647 [host=moss-bug] 9646 [host=moss-bug] 9645 [host=moss-bug] 9644 [host=moss-bug] 9642 [host=potato-beetle] 9640 [host=leaf-beetle] 9639 [host=moss-bug] 9638 [host=earwig] 9637 [host=leaf-beetle] 9625 [host=leaf-beetle] 9615 [host=potato-beetle] 9611 [host=leaf-beetle] 9608 [host=leaf-beetle] 9601 [host=earwig] 9593 [host=moss-bug] 9471 [host=potato-beetle] 9363 [host=potato-beetle] 9355 [host=potato-beetle] 9351 [host=moss-bug] 9350 [host=moss-bug] 9349 [host=moss-bug] 9348 [host=moss-bug] 9347 [host=moss-bug] 9346 [host=moss-bug] 9345 [host=moss-bug] 9344 [host=moss-bug] 9343 [host=moss-bug] 9342 [host=moss-bug] 9341 [host=moss-bug] 9339 [host=moss-bug] 9292 [host=moss-bug] 9275 [host=moss-bug] 9253 [host=moss-bug] 9252 [host=moss-bug] 9251 [host=moss-bug] 9247 [host=moss-bug] 9246 [host=moss-bug] 9245 [host=moss-bug] 9244 [host=moss-bug] 9239 [host=moss-bug] 9238 [host=moss-bug] 9237 [host=moss-bug] 9236 [host=moss-bug] 9235 [host=moss-bug] 9234 [host=potato-beetle] 9224 [host=moss-bug] 9207 [host=potato-beetle] 9204 [host=potato-beetle] 9203 [host=moss-bug] 9201 [host=moss-bug] 9198 [host=moss-bug] 9195 [host=moss-bug] 9193 [host=moss-bug] 9192 [host=moss-bug] 9191 [host=moss-bug] 9188 [host=moss-bug] 9187 [host=moss-bug] 9186 [host=moss-bug] 9183 [host=moss-bug] 9182 [host=potato-beetle] 9181 [host=moss-bug] 9176 [host=moss-bug] 9169 [host=moss-bug] 9163 [host=moss-bug] 9160 [host=potato-beetle] 9138 [host=lace-bug] 9121 [host=lace-bug] 9119 [host=lace-bug] 9118 [host=lace-bug] 9115 [host=lace-bug] 9113 [host=potato-beetle] 9110 [host=lace-bug] 9109 [host=moss-bug] 9105 [host=lace-bug] 9085 [host=itch-mite] 9083 [host=lace-bug] 9081 [host=moss-bug] 9079 [host=itch-mite] 9077 [host=lace-bug] 9075 [host=itch-mite] 9073 [host=itch-mite] 9071 [host=itch-mite] 9069 [host=potato-beetle] 9067 [host=lace-bug] 9065 [host=itch-mite] 9063 [host=potato-beetle] 9061 [host=leaf-beetle] 9059 [host=itch-mite] 9054 [host=moss-bug] 9043 [host=moss-bug] 9005 [host=leaf-beetle] 9000 [host=itch-mite] 8995 [host=lace-bug] 8991 [host=lace-bug] 8990 [host=potato-beetle] 8986 [host=moss-bug] 8975 [host=moss-bug] 8960 [host=moss-bug] 8955 [host=moss-bug] 8951 ok.
Failure / basis pass flights: 10008 / 8951
Tree: linux http://hg.uk.xensource.com/linux-2.6.18-xen.hg
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://hg.uk.xensource.com/xen-unstable.hg
Latest da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 7aa5838499d1
Basis pass 700f70b60d4b cd776ee9408ff127f934a707c1a339ee600bc127 483c5f8319ad
Generating revisions with ./adhoc-revtuple-generator  http://hg.uk.xensource.com/linux-2.6.18-xen.hg#700f70b60d4b-da0850ab55d6 git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#cd776ee9408ff127f934a707c1a339ee600bc127-9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 http://hg.uk.xensource.com/xen-unstable.hg#483c5f8319ad-7aa5838499d1
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 2009 nodes in revision graph
Searching for test results:
 8951 pass 700f70b60d4b cd776ee9408ff127f934a707c1a339ee600bc127 483c5f8319ad
 8960 [host=moss-bug]
 8955 [host=moss-bug]
 8975 [host=moss-bug]
 8986 [host=moss-bug]
 8990 [host=potato-beetle]
 8991 [host=lace-bug]
 9075 [host=itch-mite]
 8995 [host=lace-bug]
 9065 [host=itch-mite]
 9000 [host=itch-mite]
 9043 [host=moss-bug]
 9083 [host=lace-bug]
 9005 [host=leaf-beetle]
 9067 [host=lace-bug]
 9054 [host=moss-bug]
 9077 [host=lace-bug]
 9059 [host=itch-mite]
 9069 [host=potato-beetle]
 9061 [host=leaf-beetle]
 9063 [host=potato-beetle]
 9071 [host=itch-mite]
 9079 [host=itch-mite]
 9085 [host=itch-mite]
 9073 [host=itch-mite]
 9098 [host=itch-mite]
 9081 [host=moss-bug]
 9097 [host=itch-mite]
 9105 [host=lace-bug]
 9109 [host=moss-bug]
 9110 [host=lace-bug]
 9113 [host=potato-beetle]
 9115 [host=lace-bug]
 9118 [host=lace-bug]
 9176 [host=moss-bug]
 9119 [host=lace-bug]
 9204 [host=potato-beetle]
 9191 [host=moss-bug]
 9121 [host=lace-bug]
 9138 [host=lace-bug]
 9181 [host=moss-bug]
 9163 [host=moss-bug]
 9198 [host=moss-bug]
 9182 [host=potato-beetle]
 9192 [host=moss-bug]
 9183 [host=moss-bug]
 9160 [host=potato-beetle]
 9193 [host=moss-bug]
 9169 [host=moss-bug]
 9186 [host=moss-bug]
 9187 [host=moss-bug]
 9201 [host=moss-bug]
 9195 [host=moss-bug]
 9188 [host=moss-bug]
 9203 [host=moss-bug]
 9224 [host=moss-bug]
 9207 [host=potato-beetle]
 9234 [host=potato-beetle]
 9235 [host=moss-bug]
 9236 [host=moss-bug]
 9237 [host=moss-bug]
 9238 [host=moss-bug]
 9239 [host=moss-bug]
 9244 [host=moss-bug]
 9245 [host=moss-bug]
 9246 [host=moss-bug]
 9247 [host=moss-bug]
 9251 [host=moss-bug]
 9252 [host=moss-bug]
 9253 [host=moss-bug]
 9275 [host=moss-bug]
 9292 [host=moss-bug]
 9339 [host=moss-bug]
 9341 [host=moss-bug]
 9342 [host=moss-bug]
 9343 [host=moss-bug]
 9344 [host=moss-bug]
 9345 [host=moss-bug]
 9346 [host=moss-bug]
 9347 [host=moss-bug]
 9348 [host=moss-bug]
 9349 [host=moss-bug]
 9350 [host=moss-bug]
 9351 [host=moss-bug]
 9355 [host=potato-beetle]
 9363 [host=potato-beetle]
 9471 [host=potato-beetle]
 9615 [host=potato-beetle]
 9649 [host=moss-bug]
 9625 [host=leaf-beetle]
 9661 [host=leaf-beetle]
 9650 [host=moss-bug]
 9593 [host=moss-bug]
 9637 [host=leaf-beetle]
 9651 [host=moss-bug]
 9638 [host=earwig]
 9662 [host=potato-beetle]
 9639 [host=moss-bug]
 9601 [host=earwig]
 9640 [host=leaf-beetle]
 9608 [host=leaf-beetle]
 9611 [host=leaf-beetle]
 9652 [host=moss-bug]
 9642 [host=potato-beetle]
 9644 [host=moss-bug]
 9655 [host=moss-bug]
 9645 [host=moss-bug]
 9646 [host=moss-bug]
 9656 [host=moss-bug]
 9647 [host=moss-bug]
 9648 [host=moss-bug]
 9663 [host=moss-bug]
 9659 [host=moss-bug]
 9741 [host=moss-bug]
 9742 [host=moss-bug]
 9743 [host=moss-bug]
 9745 [host=potato-beetle]
 9746 [host=moss-bug]
 9747 [host=moss-bug]
 9748 [host=moss-bug]
 9749 [host=moss-bug]
 9764 [host=leaf-beetle]
 9752 [host=moss-bug]
 9753 [host=moss-bug]
 9765 [host=moss-bug]
 9766 [host=moss-bug]
 9789 [host=moss-bug]
 9767 [host=moss-bug]
 9802 [host=moss-bug]
 9799 [host=moss-bug]
 9803 [host=moss-bug]
 9800 [host=leaf-beetle]
 9817 [host=potato-beetle]
 9806 [host=moss-bug]
 9878 [host=moss-bug]
 9864 [host=itch-mite]
 9832 [host=moss-bug]
 9868 [host=leaf-beetle]
 9855 [host=itch-mite]
 9857 [host=moss-bug]
 9860 [host=itch-mite]
 9901 [host=field-cricket]
 9872 [host=moss-bug]
 9884 [host=leaf-beetle]
 9893 [host=leaf-beetle]
 9906 [host=moss-bug]
 9915 [host=moss-bug]
 9924 [host=moss-bug]
 9931 [host=leaf-beetle]
 9936 [host=moss-bug]
 9941 [host=moss-bug]
 10003 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 b21b6c91c1f4
 9946 [host=potato-beetle]
 10014 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 9951 [host=moss-bug]
 10004 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 2b5c6fff0e5b
 9955 [host=moss-bug]
 9956 [host=moss-bug]
 9958 [host=moss-bug]
 9959 [host=moss-bug]
 10005 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 9978 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9962 [host=moss-bug]
 9994 pass 700f70b60d4b cd776ee9408ff127f934a707c1a339ee600bc127 483c5f8319ad
 10015 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9995 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9996 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 8edcd2e3f3f1
 9997 pass 2d7a321286c9 25378e0a76b282127e9ab8933a4defbc91db3862 083797fda372
 10006 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9998 pass 2d7a321286c9 52834188eedfbbca5636fd869d4c86b3b3044439 4de6a56b7b5d
 9999 pass 985b8f62df25 52834188eedfbbca5636fd869d4c86b3b3044439 a3a2e300951a
 10009 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 10000 pass 985b8f62df25 52834188eedfbbca5636fd869d4c86b3b3044439 7a9a1261a6b0
 10001 pass da0850ab55d6 52834188eedfbbca5636fd869d4c86b3b3044439 883f1c35810e
 10008 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 7aa5838499d1
 10002 pass da0850ab55d6 52834188eedfbbca5636fd869d4c86b3b3044439 1f2a06dbbb69
 10010 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 10011 pass 700f70b60d4b cd776ee9408ff127f934a707c1a339ee600bc127 483c5f8319ad
 10012 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 7aa5838499d1
Searching for interesting versions
 Result found: flight 8951 (pass), for basis pass
 Result found: flight 10008 (fail), for basis failure
 Repro found: flight 10011 (pass), for basis pass
 Repro found: flight 10012 (fail), for basis failure
 0 revisions at da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
No revisions left to test, checking graph state.
 Result found: flight 10005 (pass), for last pass
 Result found: flight 10006 (fail), for first failure
 Repro found: flight 10009 (pass), for last pass
 Repro found: flight 10010 (fail), for first failure
 Repro found: flight 10014 (pass), for last pass
 Repro found: flight 10015 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://hg.uk.xensource.com/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24184:4ecd3615e726
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.{dot,ps,png,html}.
----------------------------------------
10015: ALL FAIL

flight 10015 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10015/


jobs:
 build-amd64-oldkern                                          fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:47:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:47:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF2v-00028Q-Ng; Wed, 23 Nov 2011 15:47:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTF2t-000279-Dc
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:47:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322063225!5345591!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23883 invoked from network); 23 Nov 2011 15:47:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 15:47:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9095851"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 15:47:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 15:47:05 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTF2O-0005up-UR;
	Wed, 23 Nov 2011 15:47:04 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTF2O-000214-Tq;
	Wed, 23 Nov 2011 15:47:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RTF2O-000214-Tq@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 15:47:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete build-amd64-oldkern
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

branch xen-unstable
xen branch xen-unstable
job build-amd64-oldkern
test xen-build

Tree: linux http://hg.uk.xensource.com/linux-2.6.18-xen.hg
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://hg.uk.xensource.com/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://hg.uk.xensource.com/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08


  changeset:   24184:4ecd3615e726
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10008 fail [host=woodlouse] / 9958 [host=moss-bug] 9956 [host=moss-bug] 9955 [host=moss-bug] 9951 [host=moss-bug] 9946 [host=potato-beetle] 9941 [host=moss-bug] 9936 [host=moss-bug] 9931 [host=leaf-beetle] 9924 [host=moss-bug] 9915 [host=moss-bug] 9906 [host=moss-bug] 9901 [host=field-cricket] 9893 [host=leaf-beetle] 9884 [host=leaf-beetle] 9878 [host=moss-bug] 9872 [host=moss-bug] 9868 [host=leaf-beetle] 9860 [host=itch-mite] 9857 [host=moss-bug] 9855 [host=itch-mite] 9832 [host=moss-bug] 9817 [host=potato-beetle] 9806 [host=moss-bug] 9803 [host=moss-bug] 9802 [host=moss-bug] 9800 [host=leaf-beetle] 9799 [host=moss-bug] 9789 [host=moss-bug] 9767 [host=moss-bug] 9766 [host=moss-bug] 9765 [host=moss-bug] 9753 [host=moss-bug] 9752 [host=moss-bug] 9749 [host=moss-bug] 9748 [host=moss-bug] 9747 [host=moss-bug] 9746 [host=moss-bug] 9745 [host=potato-beetle] 9743 [host=moss-bug] 9742 [host=moss-bug] 9741 [host=moss-bug] 9663 [host=moss-bug] 9662 [host=potato-beetle] 9661 [host=leaf-beetle] 9659 [host=moss-bug] 9656 [host=moss-bug] 9655 [host=moss-bug] 9652 [host=moss-bug] 9651 [host=moss-bug] 9650 [host=moss-bug] 9649 [host=moss-bug] 9648 [host=moss-bug] 9647 [host=moss-bug] 9646 [host=moss-bug] 9645 [host=moss-bug] 9644 [host=moss-bug] 9642 [host=potato-beetle] 9640 [host=leaf-beetle] 9639 [host=moss-bug] 9638 [host=earwig] 9637 [host=leaf-beetle] 9625 [host=leaf-beetle] 9615 [host=potato-beetle] 9611 [host=leaf-beetle] 9608 [host=leaf-beetle] 9601 [host=earwig] 9593 [host=moss-bug] 9471 [host=potato-beetle] 9363 [host=potato-beetle] 9355 [host=potato-beetle] 9351 [host=moss-bug] 9350 [host=moss-bug] 9349 [host=moss-bug] 9348 [host=moss-bug] 9347 [host=moss-bug] 9346 [host=moss-bug] 9345 [host=moss-bug] 9344 [host=moss-bug] 9343 [host=moss-bug] 9342 [host=moss-bug] 9341 [host=moss-bug] 9339 [host=moss-bug] 9292 [host=moss-bug] 9275 [host=moss-bug] 9253 [host=moss-bug] 9252 [host=moss-bug] 9251 [host=moss-bug] 9247 [host=moss-bug] 9246 [host=moss-bug] 9245 [host=moss-bug] 9244 [host=moss-bug] 9239 [host=moss-bug] 9238 [host=moss-bug] 9237 [host=moss-bug] 9236 [host=moss-bug] 9235 [host=moss-bug] 9234 [host=potato-beetle] 9224 [host=moss-bug] 9207 [host=potato-beetle] 9204 [host=potato-beetle] 9203 [host=moss-bug] 9201 [host=moss-bug] 9198 [host=moss-bug] 9195 [host=moss-bug] 9193 [host=moss-bug] 9192 [host=moss-bug] 9191 [host=moss-bug] 9188 [host=moss-bug] 9187 [host=moss-bug] 9186 [host=moss-bug] 9183 [host=moss-bug] 9182 [host=potato-beetle] 9181 [host=moss-bug] 9176 [host=moss-bug] 9169 [host=moss-bug] 9163 [host=moss-bug] 9160 [host=potato-beetle] 9138 [host=lace-bug] 9121 [host=lace-bug] 9119 [host=lace-bug] 9118 [host=lace-bug] 9115 [host=lace-bug] 9113 [host=potato-beetle] 9110 [host=lace-bug] 9109 [host=moss-bug] 9105 [host=lace-bug] 9085 [host=itch-mite] 9083 [host=lace-bug] 9081 [host=moss-bug] 9079 [host=itch-mite] 9077 [host=lace-bug] 9075 [host=itch-mite] 9073 [host=itch-mite] 9071 [host=itch-mite] 9069 [host=potato-beetle] 9067 [host=lace-bug] 9065 [host=itch-mite] 9063 [host=potato-beetle] 9061 [host=leaf-beetle] 9059 [host=itch-mite] 9054 [host=moss-bug] 9043 [host=moss-bug] 9005 [host=leaf-beetle] 9000 [host=itch-mite] 8995 [host=lace-bug] 8991 [host=lace-bug] 8990 [host=potato-beetle] 8986 [host=moss-bug] 8975 [host=moss-bug] 8960 [host=moss-bug] 8955 [host=moss-bug] 8951 ok.
Failure / basis pass flights: 10008 / 8951
Tree: linux http://hg.uk.xensource.com/linux-2.6.18-xen.hg
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://hg.uk.xensource.com/xen-unstable.hg
Latest da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 7aa5838499d1
Basis pass 700f70b60d4b cd776ee9408ff127f934a707c1a339ee600bc127 483c5f8319ad
Generating revisions with ./adhoc-revtuple-generator  http://hg.uk.xensource.com/linux-2.6.18-xen.hg#700f70b60d4b-da0850ab55d6 git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#cd776ee9408ff127f934a707c1a339ee600bc127-9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 http://hg.uk.xensource.com/xen-unstable.hg#483c5f8319ad-7aa5838499d1
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://hg.uk.xensource.com/HG/qemu-xen-unstable.git /export/home/osstest/repos/qemu-xen-unstable...
Initialized empty Git repository in /export/home/osstest/repos/qemu-xen-unstable/
updating cache /export/home/osstest/repos/git-cache qemu-xen-unstable...
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 2009 nodes in revision graph
Searching for test results:
 8951 pass 700f70b60d4b cd776ee9408ff127f934a707c1a339ee600bc127 483c5f8319ad
 8960 [host=moss-bug]
 8955 [host=moss-bug]
 8975 [host=moss-bug]
 8986 [host=moss-bug]
 8990 [host=potato-beetle]
 8991 [host=lace-bug]
 9075 [host=itch-mite]
 8995 [host=lace-bug]
 9065 [host=itch-mite]
 9000 [host=itch-mite]
 9043 [host=moss-bug]
 9083 [host=lace-bug]
 9005 [host=leaf-beetle]
 9067 [host=lace-bug]
 9054 [host=moss-bug]
 9077 [host=lace-bug]
 9059 [host=itch-mite]
 9069 [host=potato-beetle]
 9061 [host=leaf-beetle]
 9063 [host=potato-beetle]
 9071 [host=itch-mite]
 9079 [host=itch-mite]
 9085 [host=itch-mite]
 9073 [host=itch-mite]
 9098 [host=itch-mite]
 9081 [host=moss-bug]
 9097 [host=itch-mite]
 9105 [host=lace-bug]
 9109 [host=moss-bug]
 9110 [host=lace-bug]
 9113 [host=potato-beetle]
 9115 [host=lace-bug]
 9118 [host=lace-bug]
 9176 [host=moss-bug]
 9119 [host=lace-bug]
 9204 [host=potato-beetle]
 9191 [host=moss-bug]
 9121 [host=lace-bug]
 9138 [host=lace-bug]
 9181 [host=moss-bug]
 9163 [host=moss-bug]
 9198 [host=moss-bug]
 9182 [host=potato-beetle]
 9192 [host=moss-bug]
 9183 [host=moss-bug]
 9160 [host=potato-beetle]
 9193 [host=moss-bug]
 9169 [host=moss-bug]
 9186 [host=moss-bug]
 9187 [host=moss-bug]
 9201 [host=moss-bug]
 9195 [host=moss-bug]
 9188 [host=moss-bug]
 9203 [host=moss-bug]
 9224 [host=moss-bug]
 9207 [host=potato-beetle]
 9234 [host=potato-beetle]
 9235 [host=moss-bug]
 9236 [host=moss-bug]
 9237 [host=moss-bug]
 9238 [host=moss-bug]
 9239 [host=moss-bug]
 9244 [host=moss-bug]
 9245 [host=moss-bug]
 9246 [host=moss-bug]
 9247 [host=moss-bug]
 9251 [host=moss-bug]
 9252 [host=moss-bug]
 9253 [host=moss-bug]
 9275 [host=moss-bug]
 9292 [host=moss-bug]
 9339 [host=moss-bug]
 9341 [host=moss-bug]
 9342 [host=moss-bug]
 9343 [host=moss-bug]
 9344 [host=moss-bug]
 9345 [host=moss-bug]
 9346 [host=moss-bug]
 9347 [host=moss-bug]
 9348 [host=moss-bug]
 9349 [host=moss-bug]
 9350 [host=moss-bug]
 9351 [host=moss-bug]
 9355 [host=potato-beetle]
 9363 [host=potato-beetle]
 9471 [host=potato-beetle]
 9615 [host=potato-beetle]
 9649 [host=moss-bug]
 9625 [host=leaf-beetle]
 9661 [host=leaf-beetle]
 9650 [host=moss-bug]
 9593 [host=moss-bug]
 9637 [host=leaf-beetle]
 9651 [host=moss-bug]
 9638 [host=earwig]
 9662 [host=potato-beetle]
 9639 [host=moss-bug]
 9601 [host=earwig]
 9640 [host=leaf-beetle]
 9608 [host=leaf-beetle]
 9611 [host=leaf-beetle]
 9652 [host=moss-bug]
 9642 [host=potato-beetle]
 9644 [host=moss-bug]
 9655 [host=moss-bug]
 9645 [host=moss-bug]
 9646 [host=moss-bug]
 9656 [host=moss-bug]
 9647 [host=moss-bug]
 9648 [host=moss-bug]
 9663 [host=moss-bug]
 9659 [host=moss-bug]
 9741 [host=moss-bug]
 9742 [host=moss-bug]
 9743 [host=moss-bug]
 9745 [host=potato-beetle]
 9746 [host=moss-bug]
 9747 [host=moss-bug]
 9748 [host=moss-bug]
 9749 [host=moss-bug]
 9764 [host=leaf-beetle]
 9752 [host=moss-bug]
 9753 [host=moss-bug]
 9765 [host=moss-bug]
 9766 [host=moss-bug]
 9789 [host=moss-bug]
 9767 [host=moss-bug]
 9802 [host=moss-bug]
 9799 [host=moss-bug]
 9803 [host=moss-bug]
 9800 [host=leaf-beetle]
 9817 [host=potato-beetle]
 9806 [host=moss-bug]
 9878 [host=moss-bug]
 9864 [host=itch-mite]
 9832 [host=moss-bug]
 9868 [host=leaf-beetle]
 9855 [host=itch-mite]
 9857 [host=moss-bug]
 9860 [host=itch-mite]
 9901 [host=field-cricket]
 9872 [host=moss-bug]
 9884 [host=leaf-beetle]
 9893 [host=leaf-beetle]
 9906 [host=moss-bug]
 9915 [host=moss-bug]
 9924 [host=moss-bug]
 9931 [host=leaf-beetle]
 9936 [host=moss-bug]
 9941 [host=moss-bug]
 10003 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 b21b6c91c1f4
 9946 [host=potato-beetle]
 10014 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 9951 [host=moss-bug]
 10004 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 2b5c6fff0e5b
 9955 [host=moss-bug]
 9956 [host=moss-bug]
 9958 [host=moss-bug]
 9959 [host=moss-bug]
 10005 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 9978 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9962 [host=moss-bug]
 9994 pass 700f70b60d4b cd776ee9408ff127f934a707c1a339ee600bc127 483c5f8319ad
 10015 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9995 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9996 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 8edcd2e3f3f1
 9997 pass 2d7a321286c9 25378e0a76b282127e9ab8933a4defbc91db3862 083797fda372
 10006 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 9998 pass 2d7a321286c9 52834188eedfbbca5636fd869d4c86b3b3044439 4de6a56b7b5d
 9999 pass 985b8f62df25 52834188eedfbbca5636fd869d4c86b3b3044439 a3a2e300951a
 10009 pass da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
 10000 pass 985b8f62df25 52834188eedfbbca5636fd869d4c86b3b3044439 7a9a1261a6b0
 10001 pass da0850ab55d6 52834188eedfbbca5636fd869d4c86b3b3044439 883f1c35810e
 10008 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 7aa5838499d1
 10002 pass da0850ab55d6 52834188eedfbbca5636fd869d4c86b3b3044439 1f2a06dbbb69
 10010 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 4ecd3615e726
 10011 pass 700f70b60d4b cd776ee9408ff127f934a707c1a339ee600bc127 483c5f8319ad
 10012 fail da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 7aa5838499d1
Searching for interesting versions
 Result found: flight 8951 (pass), for basis pass
 Result found: flight 10008 (fail), for basis failure
 Repro found: flight 10011 (pass), for basis pass
 Repro found: flight 10012 (fail), for basis failure
 0 revisions at da0850ab55d6 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2 53bec838bb08
No revisions left to test, checking graph state.
 Result found: flight 10005 (pass), for last pass
 Result found: flight 10006 (fail), for first failure
 Repro found: flight 10009 (pass), for last pass
 Repro found: flight 10010 (fail), for first failure
 Repro found: flight 10014 (pass), for last pass
 Repro found: flight 10015 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://hg.uk.xensource.com/xen-unstable.hg
  Bug introduced:  4ecd3615e726
  Bug not present: 53bec838bb08

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24184:4ecd3615e726
  user:        Ian Campbell <ian.campbell@citrix.com>
  date:        Tue Nov 22 17:24:51 2011 +0000
      
      tools: use system installed libaio by default.
      
      I could have sworn I did this years ago.
      
      IIRC the need for our own copy was due to the use of io_set_eventfd which is
      not present in version 0.3.106. However it is in 0.3.107 the first version of
      which was uploaded to Debian in June 2008 (I can't find a better reference for
      the release date).
      
      The necessary version is available in Debian Lenny onwards and is in at least
      RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
      available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
      version.
      
      This is based on tools-system-libaio.diff from the Debian packaging although I
      have made it optional (but default on).
      
      Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
      Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.{dot,ps,png,html}.
----------------------------------------
10015: ALL FAIL

flight 10015 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10015/


jobs:
 build-amd64-oldkern                                          fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:50:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF5i-0002a2-Pm; Wed, 23 Nov 2011 15:50:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RTF5g-0002Yt-V8; Wed, 23 Nov 2011 15:50:29 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322063382!46827990!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29096 invoked from network); 23 Nov 2011 15:49:43 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 15:49:43 -0000
Received: by yenm6 with SMTP id m6so2301320yen.30
	for <multiple recipients>; Wed, 23 Nov 2011 07:49:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:references:in-reply-to:x-forwarded-message-id:content-type;
	bh=JdXsmRTd708rNRY3nG2qzMkSp1MY0ZdL3KZ+hTrp/uk=;
	b=OgXPSbt4LX8M0P5bYKedKtzo2HKLeaIa5tv/s/HgHltyFRTDbft3NhKJV4usJI+kI9
	EO7+lz/ZXt4kkvkQICdJ5YWzPUXCokPWTbtWRACqgdaFgE7KEJddnthmMTUPtMbYBq5M
	MrVNwPYh8WotChsJEFWAX8LPIwxFdN/245T9M=
Received: by 10.204.131.88 with SMTP id w24mr24729119bks.113.1322063396518;
	Wed, 23 Nov 2011 07:49:56 -0800 (PST)
Received: from [172.16.26.10] (5e0575b0.bb.sky.com. [94.5.117.176])
	by mx.google.com with ESMTPS id h7sm13177907bkw.12.2011.11.23.07.49.53
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 07:49:54 -0800 (PST)
Message-ID: <4ECD160B.9060104@xen.org>
Date: Wed, 23 Nov 2011 15:49:31 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
References: <4ECCF9B9.9050102@openstack.org>
In-Reply-To: <4ECCF9B9.9050102@openstack.org>
X-Forwarded-Message-Id: <4ECCF9B9.9050102@openstack.org>
Subject: [Xen-devel] FOSDEM 2012: Open source Virtualization and Cloud
 devroom: Call for speakers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1787925656479448093=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============1787925656479448093==
Content-Type: multipart/alternative;
 boundary="------------090100020209090705040302"

This is a multi-part message in MIME format.
--------------090100020209090705040302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,
due to the space that FOSDEM gave us, which is a large auditorium where 
it is not possible to change the layout and work in small groups, we had 
to go for a slightly more formal set-up for the devroom. See the 
attached CFP for more info.
Regards
Lars

-------- Original Message --------
Subject: 	FOSDEM 2012: Open source Virtualization and Cloud devroom: 
Call for speakers
Date: 	Wed, 23 Nov 2011 14:48:41 +0100
From: 	Thierry Carrez <thierry@openstack.org>
Organisation: 	OpenStack
To: 	fosdem@lists.fosdem.org
CC: 	Renzo Davoli <renzo@cs.unibo.it>, Lars Kurth <lars.kurth@xen.org>, 
"openstack@lists.launchpad.net" <openstack@lists.launchpad.net>, 
devrooms@fosdem.org



Hello everyone,

The devroom named "Open Source Virtualization and Cloud" (OSVC2012)
scheduled at FOSDEM on both days, February 4-5 2012, is a meeting
opportunity for the developers of all the innovative open source
projects around virtualization and cloud computing.

OSVC2012 will include:

* state-of-the-art presentations of virtualization/cloud projects
* workshops to brainstorm and discuss new user requests, new developer
ideas, and the possible synergies between projects

All information about the devroom will be posted on the wiki at:
http://osvc.v2.cs.unibo.it


Relevant topics
===============

All developers who want to present their ideas and software at OSVC2012
are welcome, provided that:

* Their project is related to virtualization or cloud computing

* They join the devroom as developers. Developers working for companies,
public/private agencies or universities speak for themselves and not for
their employer. OSVC2012 is about how to develop more effective
virtualizing/cloud solutions (ideas and code, not marketing)

* The code for their project must have been released under a free
software or open source license (its license must meet the FSF
definition of Free Software or the OSI definition of Open Source)


Call for Presentations and Workshops
====================================

All submissions must be sent to osvc@cs.unibo.it and include the
following information:

* Type of submission: Presentation or Workshop
* Desired length: "20min presentation + 5min Q&A", "45min presentation +
10min Q&A", or "no preference"
* Title
* Abstract / Description
* Speaker / Moderator bio
* Comments: scheduling constraints, remarks...
* Links to the project (including its source code)
* Related projects

Dates:
* Deadline for submission: December 18, 2011
* Notification of accepted submissions: January 5, 2012

-- 
Thierry Carrez
Renzo Davoli
Lars Kurth


--------------090100020209090705040302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    due to the space that FOSDEM gave us, which is a large auditorium
    where it is not possible to change the layout and work in small
    groups, we had to go for a slightly more formal set-up for the
    devroom. See the attached CFP for more info.<br>
    Regards<br>
    Lars<br>
    <br>
    -------- Original Message --------
    <table class="moz-email-headers-table" border="0" cellpadding="0"
      cellspacing="0">
      <tbody>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject: </th>
          <td>FOSDEM 2012: Open source Virtualization and Cloud devroom:
            Call for speakers</td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
          <td>Wed, 23 Nov 2011 14:48:41 +0100</td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
          <td>Thierry Carrez <a class="moz-txt-link-rfc2396E" href="mailto:thierry@openstack.org">&lt;thierry@openstack.org&gt;</a></td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Organisation:
          </th>
          <td>OpenStack</td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
          <td><a class="moz-txt-link-abbreviated" href="mailto:fosdem@lists.fosdem.org">fosdem@lists.fosdem.org</a></td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC: </th>
          <td>Renzo Davoli <a class="moz-txt-link-rfc2396E" href="mailto:renzo@cs.unibo.it">&lt;renzo@cs.unibo.it&gt;</a>, Lars Kurth
            <a class="moz-txt-link-rfc2396E" href="mailto:lars.kurth@xen.org">&lt;lars.kurth@xen.org&gt;</a>, <a class="moz-txt-link-rfc2396E" href="mailto:openstack@lists.launchpad.net">"openstack@lists.launchpad.net"</a>
            <a class="moz-txt-link-rfc2396E" href="mailto:openstack@lists.launchpad.net">&lt;openstack@lists.launchpad.net&gt;</a>, <a class="moz-txt-link-abbreviated" href="mailto:devrooms@fosdem.org">devrooms@fosdem.org</a></td>
        </tr>
      </tbody>
    </table>
    <br>
    <br>
    <pre>Hello everyone,

The devroom named "Open Source Virtualization and Cloud" (OSVC2012)
scheduled at FOSDEM on both days, February 4-5 2012, is a meeting
opportunity for the developers of all the innovative open source
projects around virtualization and cloud computing.

OSVC2012 will include:

* state-of-the-art presentations of virtualization/cloud projects
* workshops to brainstorm and discuss new user requests, new developer
ideas, and the possible synergies between projects

All information about the devroom will be posted on the wiki at:
<a class="moz-txt-link-freetext" href="http://osvc.v2.cs.unibo.it">http://osvc.v2.cs.unibo.it</a>


Relevant topics
===============

All developers who want to present their ideas and software at OSVC2012
are welcome, provided that:

* Their project is related to virtualization or cloud computing

* They join the devroom as developers. Developers working for companies,
public/private agencies or universities speak for themselves and not for
their employer. OSVC2012 is about how to develop more effective
virtualizing/cloud solutions (ideas and code, not marketing)

* The code for their project must have been released under a free
software or open source license (its license must meet the FSF
definition of Free Software or the OSI definition of Open Source)


Call for Presentations and Workshops
====================================

All submissions must be sent to <a class="moz-txt-link-abbreviated" href="mailto:osvc@cs.unibo.it">osvc@cs.unibo.it</a> and include the
following information:

* Type of submission: Presentation or Workshop
* Desired length: "20min presentation + 5min Q&amp;A", "45min presentation +
10min Q&amp;A", or "no preference"
* Title
* Abstract / Description
* Speaker / Moderator bio
* Comments: scheduling constraints, remarks...
* Links to the project (including its source code)
* Related projects

Dates:
* Deadline for submission: December 18, 2011
* Notification of accepted submissions: January 5, 2012

-- 
Thierry Carrez
Renzo Davoli
Lars Kurth
</pre>
  </body>
</html>

--------------090100020209090705040302--


--===============1787925656479448093==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1787925656479448093==--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:50:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF5i-0002a2-Pm; Wed, 23 Nov 2011 15:50:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RTF5g-0002Yt-V8; Wed, 23 Nov 2011 15:50:29 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322063382!46827990!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29096 invoked from network); 23 Nov 2011 15:49:43 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 15:49:43 -0000
Received: by yenm6 with SMTP id m6so2301320yen.30
	for <multiple recipients>; Wed, 23 Nov 2011 07:49:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:references:in-reply-to:x-forwarded-message-id:content-type;
	bh=JdXsmRTd708rNRY3nG2qzMkSp1MY0ZdL3KZ+hTrp/uk=;
	b=OgXPSbt4LX8M0P5bYKedKtzo2HKLeaIa5tv/s/HgHltyFRTDbft3NhKJV4usJI+kI9
	EO7+lz/ZXt4kkvkQICdJ5YWzPUXCokPWTbtWRACqgdaFgE7KEJddnthmMTUPtMbYBq5M
	MrVNwPYh8WotChsJEFWAX8LPIwxFdN/245T9M=
Received: by 10.204.131.88 with SMTP id w24mr24729119bks.113.1322063396518;
	Wed, 23 Nov 2011 07:49:56 -0800 (PST)
Received: from [172.16.26.10] (5e0575b0.bb.sky.com. [94.5.117.176])
	by mx.google.com with ESMTPS id h7sm13177907bkw.12.2011.11.23.07.49.53
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 07:49:54 -0800 (PST)
Message-ID: <4ECD160B.9060104@xen.org>
Date: Wed, 23 Nov 2011 15:49:31 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
References: <4ECCF9B9.9050102@openstack.org>
In-Reply-To: <4ECCF9B9.9050102@openstack.org>
X-Forwarded-Message-Id: <4ECCF9B9.9050102@openstack.org>
Subject: [Xen-devel] FOSDEM 2012: Open source Virtualization and Cloud
 devroom: Call for speakers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1787925656479448093=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============1787925656479448093==
Content-Type: multipart/alternative;
 boundary="------------090100020209090705040302"

This is a multi-part message in MIME format.
--------------090100020209090705040302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,
due to the space that FOSDEM gave us, which is a large auditorium where 
it is not possible to change the layout and work in small groups, we had 
to go for a slightly more formal set-up for the devroom. See the 
attached CFP for more info.
Regards
Lars

-------- Original Message --------
Subject: 	FOSDEM 2012: Open source Virtualization and Cloud devroom: 
Call for speakers
Date: 	Wed, 23 Nov 2011 14:48:41 +0100
From: 	Thierry Carrez <thierry@openstack.org>
Organisation: 	OpenStack
To: 	fosdem@lists.fosdem.org
CC: 	Renzo Davoli <renzo@cs.unibo.it>, Lars Kurth <lars.kurth@xen.org>, 
"openstack@lists.launchpad.net" <openstack@lists.launchpad.net>, 
devrooms@fosdem.org



Hello everyone,

The devroom named "Open Source Virtualization and Cloud" (OSVC2012)
scheduled at FOSDEM on both days, February 4-5 2012, is a meeting
opportunity for the developers of all the innovative open source
projects around virtualization and cloud computing.

OSVC2012 will include:

* state-of-the-art presentations of virtualization/cloud projects
* workshops to brainstorm and discuss new user requests, new developer
ideas, and the possible synergies between projects

All information about the devroom will be posted on the wiki at:
http://osvc.v2.cs.unibo.it


Relevant topics
===============

All developers who want to present their ideas and software at OSVC2012
are welcome, provided that:

* Their project is related to virtualization or cloud computing

* They join the devroom as developers. Developers working for companies,
public/private agencies or universities speak for themselves and not for
their employer. OSVC2012 is about how to develop more effective
virtualizing/cloud solutions (ideas and code, not marketing)

* The code for their project must have been released under a free
software or open source license (its license must meet the FSF
definition of Free Software or the OSI definition of Open Source)


Call for Presentations and Workshops
====================================

All submissions must be sent to osvc@cs.unibo.it and include the
following information:

* Type of submission: Presentation or Workshop
* Desired length: "20min presentation + 5min Q&A", "45min presentation +
10min Q&A", or "no preference"
* Title
* Abstract / Description
* Speaker / Moderator bio
* Comments: scheduling constraints, remarks...
* Links to the project (including its source code)
* Related projects

Dates:
* Deadline for submission: December 18, 2011
* Notification of accepted submissions: January 5, 2012

-- 
Thierry Carrez
Renzo Davoli
Lars Kurth


--------------090100020209090705040302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    due to the space that FOSDEM gave us, which is a large auditorium
    where it is not possible to change the layout and work in small
    groups, we had to go for a slightly more formal set-up for the
    devroom. See the attached CFP for more info.<br>
    Regards<br>
    Lars<br>
    <br>
    -------- Original Message --------
    <table class="moz-email-headers-table" border="0" cellpadding="0"
      cellspacing="0">
      <tbody>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject: </th>
          <td>FOSDEM 2012: Open source Virtualization and Cloud devroom:
            Call for speakers</td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
          <td>Wed, 23 Nov 2011 14:48:41 +0100</td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
          <td>Thierry Carrez <a class="moz-txt-link-rfc2396E" href="mailto:thierry@openstack.org">&lt;thierry@openstack.org&gt;</a></td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Organisation:
          </th>
          <td>OpenStack</td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
          <td><a class="moz-txt-link-abbreviated" href="mailto:fosdem@lists.fosdem.org">fosdem@lists.fosdem.org</a></td>
        </tr>
        <tr>
          <th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC: </th>
          <td>Renzo Davoli <a class="moz-txt-link-rfc2396E" href="mailto:renzo@cs.unibo.it">&lt;renzo@cs.unibo.it&gt;</a>, Lars Kurth
            <a class="moz-txt-link-rfc2396E" href="mailto:lars.kurth@xen.org">&lt;lars.kurth@xen.org&gt;</a>, <a class="moz-txt-link-rfc2396E" href="mailto:openstack@lists.launchpad.net">"openstack@lists.launchpad.net"</a>
            <a class="moz-txt-link-rfc2396E" href="mailto:openstack@lists.launchpad.net">&lt;openstack@lists.launchpad.net&gt;</a>, <a class="moz-txt-link-abbreviated" href="mailto:devrooms@fosdem.org">devrooms@fosdem.org</a></td>
        </tr>
      </tbody>
    </table>
    <br>
    <br>
    <pre>Hello everyone,

The devroom named "Open Source Virtualization and Cloud" (OSVC2012)
scheduled at FOSDEM on both days, February 4-5 2012, is a meeting
opportunity for the developers of all the innovative open source
projects around virtualization and cloud computing.

OSVC2012 will include:

* state-of-the-art presentations of virtualization/cloud projects
* workshops to brainstorm and discuss new user requests, new developer
ideas, and the possible synergies between projects

All information about the devroom will be posted on the wiki at:
<a class="moz-txt-link-freetext" href="http://osvc.v2.cs.unibo.it">http://osvc.v2.cs.unibo.it</a>


Relevant topics
===============

All developers who want to present their ideas and software at OSVC2012
are welcome, provided that:

* Their project is related to virtualization or cloud computing

* They join the devroom as developers. Developers working for companies,
public/private agencies or universities speak for themselves and not for
their employer. OSVC2012 is about how to develop more effective
virtualizing/cloud solutions (ideas and code, not marketing)

* The code for their project must have been released under a free
software or open source license (its license must meet the FSF
definition of Free Software or the OSI definition of Open Source)


Call for Presentations and Workshops
====================================

All submissions must be sent to <a class="moz-txt-link-abbreviated" href="mailto:osvc@cs.unibo.it">osvc@cs.unibo.it</a> and include the
following information:

* Type of submission: Presentation or Workshop
* Desired length: "20min presentation + 5min Q&amp;A", "45min presentation +
10min Q&amp;A", or "no preference"
* Title
* Abstract / Description
* Speaker / Moderator bio
* Comments: scheduling constraints, remarks...
* Links to the project (including its source code)
* Related projects

Dates:
* Deadline for submission: December 18, 2011
* Notification of accepted submissions: January 5, 2012

-- 
Thierry Carrez
Renzo Davoli
Lars Kurth
</pre>
  </body>
</html>

--------------090100020209090705040302--


--===============1787925656479448093==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1787925656479448093==--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:52:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:52:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF7M-0002xE-B3; Wed, 23 Nov 2011 15:52:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTF7L-0002wC-D0
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:52:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322063501!5467111!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5279 invoked from network); 23 Nov 2011 15:51:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 15:51:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9095946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 15:51:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 15:51:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTF6V-0005wR-So;
	Wed, 23 Nov 2011 15:51:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTF6V-00027K-RW;
	Wed, 23 Nov 2011 15:51:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10013-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 15:51:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10013: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10013 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10013/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  84b3e46aa7d2
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24187:84b3e46aa7d2
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 23 12:03:37 2011 +0000
    
    libxl: Prevent xl save from segfaulting when control/shutdown key is removed
    
    To acknowledge the tools' setting of control/shutdown it is normal for
    PV drivers to rm the key. This leads to libxl__xs_read() returning
    NULL and thus a subsequent strcmp on the return value will cause a
    segfault.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24186:7aa5838499d1
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 23 11:15:31 2011 +0000
    
    tools: use system libaio for blktap1 as well.
    
    24184:4ecd3615e726 missed this because I was accidentally testing with a
    .config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
    without this. There were no other issues.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24185:f88c745575bb
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 18:51:13 2011 +0000
    
    docs: remove some fatally out of date documentation
    
    I think these are better off deleted than remaining to confuse people.
    
    docs/misc/blkif-drivers-explained.txt:
    
     - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.
    
    docs/misc/cpuid-config-for-guest.txt:
    
     - Doesn't really say anything, in particular doesn't actually describe how to
       configure CPUID.
    
    docs/misc/hg-cheatsheet.txt:
    
     - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
       under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
       hardly unusual anymore I think there must be better guides out there so this
       one is not worth resurecting.
    
    docs/misc/network_setup.txt:
    
     - This is more comprehensively documented on the wiki these days.
    
    docs/misc/VMX_changes.txt:
    
     - Is basically a changelog from the initial implementation of VMX in 2004.
    
    I'm not sure about some of the other docs, but these ones seemed fairly
    obvious.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24184:4ecd3615e726
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:52:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:52:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTF7M-0002xE-B3; Wed, 23 Nov 2011 15:52:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTF7L-0002wC-D0
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:52:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322063501!5467111!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5279 invoked from network); 23 Nov 2011 15:51:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 15:51:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9095946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 15:51:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 15:51:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTF6V-0005wR-So;
	Wed, 23 Nov 2011 15:51:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTF6V-00027K-RW;
	Wed, 23 Nov 2011 15:51:19 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10013-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 15:51:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10013: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10013 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10013/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  84b3e46aa7d2
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24187:84b3e46aa7d2
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 23 12:03:37 2011 +0000
    
    libxl: Prevent xl save from segfaulting when control/shutdown key is removed
    
    To acknowledge the tools' setting of control/shutdown it is normal for
    PV drivers to rm the key. This leads to libxl__xs_read() returning
    NULL and thus a subsequent strcmp on the return value will cause a
    segfault.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24186:7aa5838499d1
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 23 11:15:31 2011 +0000
    
    tools: use system libaio for blktap1 as well.
    
    24184:4ecd3615e726 missed this because I was accidentally testing with a
    .config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
    without this. There were no other issues.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24185:f88c745575bb
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 18:51:13 2011 +0000
    
    docs: remove some fatally out of date documentation
    
    I think these are better off deleted than remaining to confuse people.
    
    docs/misc/blkif-drivers-explained.txt:
    
     - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.
    
    docs/misc/cpuid-config-for-guest.txt:
    
     - Doesn't really say anything, in particular doesn't actually describe how to
       configure CPUID.
    
    docs/misc/hg-cheatsheet.txt:
    
     - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
       under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
       hardly unusual anymore I think there must be better guides out there so this
       one is not worth resurecting.
    
    docs/misc/network_setup.txt:
    
     - This is more comprehensively documented on the wiki these days.
    
    docs/misc/VMX_changes.txt:
    
     - Is basically a changelog from the initial implementation of VMX in 2004.
    
    I'm not sure about some of the other docs, but these ones seemed fairly
    obvious.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24184:4ecd3615e726
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:55:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:55:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFAB-0003PB-2k; Wed, 23 Nov 2011 15:55:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTFA9-0003OP-Vp
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:55:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322063675!5461319!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15262 invoked from network); 23 Nov 2011 15:54:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 15:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9096045"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 15:54:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 15:54:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Baozeng <sploving1@gmail.com>
Date: Wed, 23 Nov 2011 15:54:34 +0000
In-Reply-To: <CAP=GMUHJQzK=q2hBxkmu9trPxDbecKNb2j+Rp-=z-YeEmc=sXw@mail.gmail.com>
References: <CAP=GMUHJQzK=q2hBxkmu9trPxDbecKNb2j+Rp-=z-YeEmc=sXw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322063675.1005.147.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] how to objdump xen to print its function?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 13:02 +0000, Baozeng wrote:
> Hello all,
> I want to see the assemble code of Xen. So I use make world and make
> install to generate xen-4.1.2.gz. and unzip it to be the ELF file
> xen-4.1.2. Then I use objdump tool to see the assemble code.
> I found xen has only one section .text. Then I wonder where is the
> section .data?

This file is actually a specially constructed thing to satisfy
multiboots requirements and not the "real" ELF file. You should use the
xen...-syms file instead. Either from the build tree or possibly
from /boot if it is installed.

> # objdump -h /boot/xen-4.1.2
> 
> /boot/xen-4.1.2:     file format elf32-i386
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         0013d41c  00100000  00100000  00000080  2**6
>                   CONTENTS, ALLOC, LOAD, CODE
> 
> Another question: how do I know which assemble code in the ELF file
> corresponds to the source code line "dom0->is_privileged=1" in
> xen\arch\x86\setup.c file? In other words, how could I show the
> function name in the assemble code file? by adding -g option when
> making xen?

Add "debug=y" to your build line.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:55:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:55:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFAB-0003PB-2k; Wed, 23 Nov 2011 15:55:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTFA9-0003OP-Vp
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:55:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322063675!5461319!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15262 invoked from network); 23 Nov 2011 15:54:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 15:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9096045"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 15:54:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 15:54:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Baozeng <sploving1@gmail.com>
Date: Wed, 23 Nov 2011 15:54:34 +0000
In-Reply-To: <CAP=GMUHJQzK=q2hBxkmu9trPxDbecKNb2j+Rp-=z-YeEmc=sXw@mail.gmail.com>
References: <CAP=GMUHJQzK=q2hBxkmu9trPxDbecKNb2j+Rp-=z-YeEmc=sXw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322063675.1005.147.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] how to objdump xen to print its function?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 13:02 +0000, Baozeng wrote:
> Hello all,
> I want to see the assemble code of Xen. So I use make world and make
> install to generate xen-4.1.2.gz. and unzip it to be the ELF file
> xen-4.1.2. Then I use objdump tool to see the assemble code.
> I found xen has only one section .text. Then I wonder where is the
> section .data?

This file is actually a specially constructed thing to satisfy
multiboots requirements and not the "real" ELF file. You should use the
xen...-syms file instead. Either from the build tree or possibly
from /boot if it is installed.

> # objdump -h /boot/xen-4.1.2
> 
> /boot/xen-4.1.2:     file format elf32-i386
> 
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         0013d41c  00100000  00100000  00000080  2**6
>                   CONTENTS, ALLOC, LOAD, CODE
> 
> Another question: how do I know which assemble code in the ELF file
> corresponds to the source code line "dom0->is_privileged=1" in
> xen\arch\x86\setup.c file? In other words, how could I show the
> function name in the assemble code file? by adding -g option when
> making xen?

Add "debug=y" to your build line.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:56:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFBG-0003XE-Jf; Wed, 23 Nov 2011 15:56:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTFBF-0003WW-6m
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:56:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322063742!4328728!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8589 invoked from network); 23 Nov 2011 15:55:43 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-3.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 15:55:43 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 2720C30008F
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 07:55:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=JySmA+yd
	0zfLZss4r15ligsnLonr4xotKpOMstaPEyImlMPRR4pJPpkv0kp7yzZVitMxWqfr
	JARfiAt1ZmAY+CXd8MzW6XRLdJZ2KCbPosrTdfHg1NUX6IXAci5sYCi3ox6Z8HJP
	c4R7SxPAdzZnQXUgclfzFDKzPEq1A7/PWI8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	uboMKY3BcC0JN2xEsI4Zok9/+/E=; b=HOh3TvpsVkTdZzgmL7paGHeML9dt7c49
	KN9ls5IlfdaUmRgN12XyIEygrPEY+nWoPngm92NO3n2oxcEBh7Yx0z5+dUFLYrDI
	MTxQvHFpG4n/RRAeyAhmkzc9KeoforKxVcQbhU0qWdCC8kyEM7CJC6w0aqTVZiKg
	cR/71+Q4PT8=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 0A8C8300079
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 07:55:42 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 23 Nov 2011 07:55:42 -0800
Message-ID: <0653c27a1ace1d8b05f703421658f355.squirrel@webmail.lagarcavilla.org>
Date: Wed, 23 Nov 2011 07:55:42 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: [Xen-devel] PCI-E serial board not working under Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I've been banging my head against this serial board and I'd like to know
if anyone has tips.

It's an Oxford 0x1415:0xc138. It's located at 03:00.0, I've identified a
few problems with Xen's initialization.

First off, ns16550_parse_port_config string compares "pci" with
strncmp(conf, "pci", 5) which obviously fails. It should be 3. I can send
trivial patch.

Once that is left behind, reading the bar with pci_conf_read32(0,b,d,f,
PCI_BASE_ADDRESS_0) yields the mmio address of the first accessible
region, instead of the bar.

Linux inits this card fine, and reports three mmio regions at 0xfb600000
(size 16k), 0xfb400000 (size 2M) and 0xfb200000 (size 2M), BAR 1 with the
actual IO port at 0xfb601000 (one page inside the first mmio region). It
gets irq 19.

Going back to Xen, instead of reading bar=1, it reads the mmio offset of
the first region and then it naturally bails out. Even if it were to get
the right bar, the io_base value it would compute (bar & 0xfffe) would be
useless.

I've tried passing the explicit parameters
(com1=115200,8n1,0xfb601000,19,03:00.0), and the mere mention of an mmio
io port for the serial card hard freezes the hypervisor immediately.

Help, pointers, etc, are appreciated. I know next to nothing about PCI
config, so pardon my inaccurate ramblings.

Thanks,
Andres


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 15:56:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 15:56:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFBG-0003XE-Jf; Wed, 23 Nov 2011 15:56:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTFBF-0003WW-6m
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 15:56:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322063742!4328728!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8589 invoked from network); 23 Nov 2011 15:55:43 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-3.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 15:55:43 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 2720C30008F
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 07:55:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=JySmA+yd
	0zfLZss4r15ligsnLonr4xotKpOMstaPEyImlMPRR4pJPpkv0kp7yzZVitMxWqfr
	JARfiAt1ZmAY+CXd8MzW6XRLdJZ2KCbPosrTdfHg1NUX6IXAci5sYCi3ox6Z8HJP
	c4R7SxPAdzZnQXUgclfzFDKzPEq1A7/PWI8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	uboMKY3BcC0JN2xEsI4Zok9/+/E=; b=HOh3TvpsVkTdZzgmL7paGHeML9dt7c49
	KN9ls5IlfdaUmRgN12XyIEygrPEY+nWoPngm92NO3n2oxcEBh7Yx0z5+dUFLYrDI
	MTxQvHFpG4n/RRAeyAhmkzc9KeoforKxVcQbhU0qWdCC8kyEM7CJC6w0aqTVZiKg
	cR/71+Q4PT8=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 0A8C8300079
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 07:55:42 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 23 Nov 2011 07:55:42 -0800
Message-ID: <0653c27a1ace1d8b05f703421658f355.squirrel@webmail.lagarcavilla.org>
Date: Wed, 23 Nov 2011 07:55:42 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: [Xen-devel] PCI-E serial board not working under Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I've been banging my head against this serial board and I'd like to know
if anyone has tips.

It's an Oxford 0x1415:0xc138. It's located at 03:00.0, I've identified a
few problems with Xen's initialization.

First off, ns16550_parse_port_config string compares "pci" with
strncmp(conf, "pci", 5) which obviously fails. It should be 3. I can send
trivial patch.

Once that is left behind, reading the bar with pci_conf_read32(0,b,d,f,
PCI_BASE_ADDRESS_0) yields the mmio address of the first accessible
region, instead of the bar.

Linux inits this card fine, and reports three mmio regions at 0xfb600000
(size 16k), 0xfb400000 (size 2M) and 0xfb200000 (size 2M), BAR 1 with the
actual IO port at 0xfb601000 (one page inside the first mmio region). It
gets irq 19.

Going back to Xen, instead of reading bar=1, it reads the mmio offset of
the first region and then it naturally bails out. Even if it were to get
the right bar, the io_base value it would compute (bar & 0xfffe) would be
useless.

I've tried passing the explicit parameters
(com1=115200,8n1,0xfb601000,19,03:00.0), and the mere mention of an mmio
io port for the serial card hard freezes the hypervisor immediately.

Help, pointers, etc, are appreciated. I know next to nothing about PCI
config, so pardon my inaccurate ramblings.

Thanks,
Andres


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:08:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFN5-0004e6-TB; Wed, 23 Nov 2011 16:08:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTFN4-0004e1-RA
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:08:27 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322064476!4677451!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3981 invoked from network); 23 Nov 2011 16:07:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 16:07:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9096355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 16:07:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 16:07:56 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTFMZ-000634-SK;
	Wed, 23 Nov 2011 16:07:55 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTFMM-0005nS-EB;
	Wed, 23 Nov 2011 16:07:42 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 16:07:40 +0000
Message-ID: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: allen.m.kay@intel.com, Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
	reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


The Intel GPU uses a two pages NVS region called OpRegion.
In order to get full support for the driver in the guest
we need to map this region.

This patch reserves 2 pages on the top of the RAM and
mark this region as NVS in the e820. Then we write the
address to the config space (offset 0xfc) so the device
model can map the OpRegion at this address in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 tools/firmware/hvmloader/config.h   |    1 +
 tools/firmware/hvmloader/e820.c     |    8 ++++++++
 tools/firmware/hvmloader/pci.c      |   28 ++++++++++++++++++++++++++++
 tools/firmware/hvmloader/pci_regs.h |    2 ++
 4 files changed, 39 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch"

diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index d911352..9cac9c1 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -5,6 +5,7 @@
 
 enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
 extern enum virtual_vga virtual_vga;
+extern unsigned long igd_opregion_pgbase;
 
 struct bios_config {
     const char *name;
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 3b50dd0..fd993fe 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -124,6 +124,14 @@ int build_e820_table(struct e820entry *e820,
     e820[nr].type = E820_RAM;
     nr++;
 
+    if ( igd_opregion_pgbase )
+    {
+        e820[nr].addr = igd_opregion_pgbase << PAGE_SHIFT;
+        e820[nr].size = 2 * PAGE_SIZE;
+        e820[nr].type = E820_NVS;
+        nr++;
+    }
+
     /*
      * Explicitly reserve space for special pages.
      * This space starts at RESERVED_MEMBASE an extends to cover various
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 00490f1..13d3822 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -32,6 +32,7 @@ unsigned long pci_mem_start = PCI_MEM_START;
 unsigned long pci_mem_end = PCI_MEM_END;
 
 enum virtual_vga virtual_vga = VGA_none;
+unsigned long igd_opregion_pgbase = 0;
 
 void pci_setup(void)
 {
@@ -271,6 +272,33 @@ void pci_setup(void)
         cmd |= PCI_COMMAND_IO;
         pci_writew(vga_devfn, PCI_COMMAND, cmd);
     }
+
+    if ( virtual_vga == VGA_pt )
+    {
+        class     = pci_readw(vga_devfn, PCI_CLASS_DEVICE);
+        vendor_id = pci_readw(vga_devfn, PCI_VENDOR_ID);
+        device_id = pci_readw(vga_devfn, PCI_DEVICE_ID);
+
+        switch ( vendor_id )
+        {
+            case 0x8086: /* PCI_VENDOR_INTEL */
+                for ( i = 0; i < 2; i++ )
+                {
+                    struct xen_add_to_physmap xatp;
+                    xatp.domid = DOMID_SELF;
+                    xatp.space = XENMAPSPACE_gmfn;
+                    xatp.idx   = --hvm_info->low_mem_pgend;
+                    xatp.gpfn  = hvm_info->high_mem_pgend++;
+                    if ( hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0 )
+                        BUG();
+                }
+                igd_opregion_pgbase = hvm_info->low_mem_pgend;
+                pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+                        igd_opregion_pgbase << PAGE_SHIFT);
+                break;
+        }
+    }
+
 }
 
 /*
diff --git a/tools/firmware/hvmloader/pci_regs.h b/tools/firmware/hvmloader/pci_regs.h
index f37affe..873255c 100644
--- a/tools/firmware/hvmloader/pci_regs.h
+++ b/tools/firmware/hvmloader/pci_regs.h
@@ -105,6 +105,8 @@
 #define PCI_MIN_GNT  0x3e /* 8 bits */
 #define PCI_MAX_LAT  0x3f /* 8 bits */
 
+#define PCI_INTEL_OPREGION 0xfc /* 32 bits */
+
 #endif /* __HVMLOADER_PCI_REGS_H__ */
 
 /*

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:08:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFN5-0004e6-TB; Wed, 23 Nov 2011 16:08:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTFN4-0004e1-RA
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:08:27 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322064476!4677451!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3981 invoked from network); 23 Nov 2011 16:07:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 16:07:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9096355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 16:07:56 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 16:07:56 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTFMZ-000634-SK;
	Wed, 23 Nov 2011 16:07:55 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTFMM-0005nS-EB;
	Wed, 23 Nov 2011 16:07:42 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 23 Nov 2011 16:07:40 +0000
Message-ID: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: allen.m.kay@intel.com, Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
	reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


The Intel GPU uses a two pages NVS region called OpRegion.
In order to get full support for the driver in the guest
we need to map this region.

This patch reserves 2 pages on the top of the RAM and
mark this region as NVS in the e820. Then we write the
address to the config space (offset 0xfc) so the device
model can map the OpRegion at this address in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 tools/firmware/hvmloader/config.h   |    1 +
 tools/firmware/hvmloader/e820.c     |    8 ++++++++
 tools/firmware/hvmloader/pci.c      |   28 ++++++++++++++++++++++++++++
 tools/firmware/hvmloader/pci_regs.h |    2 ++
 4 files changed, 39 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch"

diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index d911352..9cac9c1 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -5,6 +5,7 @@
 
 enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
 extern enum virtual_vga virtual_vga;
+extern unsigned long igd_opregion_pgbase;
 
 struct bios_config {
     const char *name;
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 3b50dd0..fd993fe 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -124,6 +124,14 @@ int build_e820_table(struct e820entry *e820,
     e820[nr].type = E820_RAM;
     nr++;
 
+    if ( igd_opregion_pgbase )
+    {
+        e820[nr].addr = igd_opregion_pgbase << PAGE_SHIFT;
+        e820[nr].size = 2 * PAGE_SIZE;
+        e820[nr].type = E820_NVS;
+        nr++;
+    }
+
     /*
      * Explicitly reserve space for special pages.
      * This space starts at RESERVED_MEMBASE an extends to cover various
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 00490f1..13d3822 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -32,6 +32,7 @@ unsigned long pci_mem_start = PCI_MEM_START;
 unsigned long pci_mem_end = PCI_MEM_END;
 
 enum virtual_vga virtual_vga = VGA_none;
+unsigned long igd_opregion_pgbase = 0;
 
 void pci_setup(void)
 {
@@ -271,6 +272,33 @@ void pci_setup(void)
         cmd |= PCI_COMMAND_IO;
         pci_writew(vga_devfn, PCI_COMMAND, cmd);
     }
+
+    if ( virtual_vga == VGA_pt )
+    {
+        class     = pci_readw(vga_devfn, PCI_CLASS_DEVICE);
+        vendor_id = pci_readw(vga_devfn, PCI_VENDOR_ID);
+        device_id = pci_readw(vga_devfn, PCI_DEVICE_ID);
+
+        switch ( vendor_id )
+        {
+            case 0x8086: /* PCI_VENDOR_INTEL */
+                for ( i = 0; i < 2; i++ )
+                {
+                    struct xen_add_to_physmap xatp;
+                    xatp.domid = DOMID_SELF;
+                    xatp.space = XENMAPSPACE_gmfn;
+                    xatp.idx   = --hvm_info->low_mem_pgend;
+                    xatp.gpfn  = hvm_info->high_mem_pgend++;
+                    if ( hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0 )
+                        BUG();
+                }
+                igd_opregion_pgbase = hvm_info->low_mem_pgend;
+                pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+                        igd_opregion_pgbase << PAGE_SHIFT);
+                break;
+        }
+    }
+
 }
 
 /*
diff --git a/tools/firmware/hvmloader/pci_regs.h b/tools/firmware/hvmloader/pci_regs.h
index f37affe..873255c 100644
--- a/tools/firmware/hvmloader/pci_regs.h
+++ b/tools/firmware/hvmloader/pci_regs.h
@@ -105,6 +105,8 @@
 #define PCI_MIN_GNT  0x3e /* 8 bits */
 #define PCI_MAX_LAT  0x3f /* 8 bits */
 
+#define PCI_INTEL_OPREGION 0xfc /* 32 bits */
+
 #endif /* __HVMLOADER_PCI_REGS_H__ */
 
 /*

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:14:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFTA-0004qs-Uk; Wed, 23 Nov 2011 16:14:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avsm@dark.recoil.org>) id 1RTFT9-0004qj-5I
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:14:43 +0000
X-Env-Sender: avsm@dark.recoil.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322064853!4341111!1
X-Originating-IP: [89.16.177.154]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14522 invoked from network); 23 Nov 2011 16:14:13 -0000
Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154)
	by server-5.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 16:14:13 -0000
Received: (qmail 2428 invoked by uid 10000); 23 Nov 2011 16:14:13 -0000
Date: Wed, 23 Nov 2011 16:14:13 +0000
From: Anil Madhavapeddy <anil@recoil.org>
To: xen-devel@lists.xensource.com
Message-ID: <20111123161412.GA26454@dark.recoil.org>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] [PATCH] fix segfault in libvchan client error path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Anil Madhavapeddy <anil@recoil.org>
# Date 1322064942 0
# Node ID 2934afb3348776eaad57d0d91893f00c862ac507
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
In libvchan_client_init, go to the error path if the gntdev device is not
available.  Otherwise, a segfault happens later as the vchan context is
invalid.

Signed-off-by: Anil Madhavapeddy <anil@recoil.org>

diff -r 0a0c02a61676 -r 2934afb33487 tools/libvchan/init.c
--- a/tools/libvchan/init.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libvchan/init.c	Wed Nov 23 16:15:42 2011 +0000
@@ -385,7 +385,7 @@
 
 	ctrl->gnttab = xc_gnttab_open(logger, 0);
 	if (!ctrl->gnttab)
-		goto out;
+		goto fail;
 
 // set up event channel
 	if (init_evt_cli(ctrl, domain, logger))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:14:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFTA-0004qs-Uk; Wed, 23 Nov 2011 16:14:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avsm@dark.recoil.org>) id 1RTFT9-0004qj-5I
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:14:43 +0000
X-Env-Sender: avsm@dark.recoil.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322064853!4341111!1
X-Originating-IP: [89.16.177.154]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14522 invoked from network); 23 Nov 2011 16:14:13 -0000
Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154)
	by server-5.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 16:14:13 -0000
Received: (qmail 2428 invoked by uid 10000); 23 Nov 2011 16:14:13 -0000
Date: Wed, 23 Nov 2011 16:14:13 +0000
From: Anil Madhavapeddy <anil@recoil.org>
To: xen-devel@lists.xensource.com
Message-ID: <20111123161412.GA26454@dark.recoil.org>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] [PATCH] fix segfault in libvchan client error path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Anil Madhavapeddy <anil@recoil.org>
# Date 1322064942 0
# Node ID 2934afb3348776eaad57d0d91893f00c862ac507
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
In libvchan_client_init, go to the error path if the gntdev device is not
available.  Otherwise, a segfault happens later as the vchan context is
invalid.

Signed-off-by: Anil Madhavapeddy <anil@recoil.org>

diff -r 0a0c02a61676 -r 2934afb33487 tools/libvchan/init.c
--- a/tools/libvchan/init.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libvchan/init.c	Wed Nov 23 16:15:42 2011 +0000
@@ -385,7 +385,7 @@
 
 	ctrl->gnttab = xc_gnttab_open(logger, 0);
 	if (!ctrl->gnttab)
-		goto out;
+		goto fail;
 
 // set up event channel
 	if (init_evt_cli(ctrl, domain, logger))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:25:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:25:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFd9-00052w-7p; Wed, 23 Nov 2011 16:25:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTFd8-00052r-4A
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:25:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322065440!45106530!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12938 invoked from network); 23 Nov 2011 16:24:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 16:24:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9096683"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 16:24:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 16:24:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 23 Nov 2011 16:24:33 +0000
In-Reply-To: <1322060876.30168.18.camel@Abyss>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322065473.1005.151.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
 schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 15:07 +0000, Dario Faggioli wrote:
> Pluggable schedulers' code knows what (and when) to lock better than
> generic code, let's delegate to them all the concurrency related issues.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r 84b3e46aa7d2 xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c	Wed Nov 23 12:03:37 2011 +0000
> +++ b/xen/common/sched_credit.c	Wed Nov 23 15:09:14 2011 +0100
> @@ -161,6 +161,7 @@ struct csched_dom {
>   * System-wide private data
>   */
>  struct csched_private {
> +    /* lock for the whole pluggable scheduler, nests inside cpupool_lock */
>      spinlock_t lock;
>      struct list_head active_sdom;
>      uint32_t ncpus;

Given that every scheduler plugin is going to need this lock perhaps it
could be provided globally (but still have the responsibility for using
it fall on the plugin)?

I was mainly thinking of the sedf case where you add and maintain the
whole structure for just that lock. Perhaps you have future plans which
involve having to do that anyway in which case maybe my suggestion
doesn't make sense.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:25:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:25:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFd9-00052w-7p; Wed, 23 Nov 2011 16:25:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTFd8-00052r-4A
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:25:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322065440!45106530!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12938 invoked from network); 23 Nov 2011 16:24:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 16:24:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; 
   d="scan'208";a="9096683"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 16:24:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 16:24:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 23 Nov 2011 16:24:33 +0000
In-Reply-To: <1322060876.30168.18.camel@Abyss>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322065473.1005.151.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
 schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 15:07 +0000, Dario Faggioli wrote:
> Pluggable schedulers' code knows what (and when) to lock better than
> generic code, let's delegate to them all the concurrency related issues.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r 84b3e46aa7d2 xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c	Wed Nov 23 12:03:37 2011 +0000
> +++ b/xen/common/sched_credit.c	Wed Nov 23 15:09:14 2011 +0100
> @@ -161,6 +161,7 @@ struct csched_dom {
>   * System-wide private data
>   */
>  struct csched_private {
> +    /* lock for the whole pluggable scheduler, nests inside cpupool_lock */
>      spinlock_t lock;
>      struct list_head active_sdom;
>      uint32_t ncpus;

Given that every scheduler plugin is going to need this lock perhaps it
could be provided globally (but still have the responsibility for using
it fall on the plugin)?

I was mainly thinking of the sedf case where you add and maintain the
whole structure for just that lock. Perhaps you have future plans which
involve having to do that anyway in which case maybe my suggestion
doesn't make sense.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:25:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFdL-00053Q-M2; Wed, 23 Nov 2011 16:25:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTFdJ-000539-9s
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:25:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322065483!5448580!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28912 invoked from network); 23 Nov 2011 16:24:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 16:24:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 16:24:42 +0000
Message-Id: <4ECD2C570200007800062BF8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 16:24:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <0653c27a1ace1d8b05f703421658f355.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <0653c27a1ace1d8b05f703421658f355.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] PCI-E serial board not working under Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.11.11 at 16:55, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
> First off, ns16550_parse_port_config string compares "pci" with
> strncmp(conf, "pci", 5) which obviously fails. It should be 3. I can send
> trivial patch.

Yes, please. (It must be an oversight in an earlier change.)

> Once that is left behind, reading the bar with pci_conf_read32(0,b,d,f,
> PCI_BASE_ADDRESS_0) yields the mmio address of the first accessible
> region, instead of the bar.

This is an assumption, not a bug (not sure what, if any, conventions
exist here). If your card doesn't meet it, then you'll have to either
provide a patch (without breaking anyone else) or deal with this for
yourself. But read on.

Also, what is being read is the BAR, just that in your case it doesn't point
into IO port space.

> Linux inits this card fine, and reports three mmio regions at 0xfb600000
> (size 16k), 0xfb400000 (size 2M) and 0xfb200000 (size 2M), BAR 1 with the
> actual IO port at 0xfb601000 (one page inside the first mmio region). It
> gets irq 19.
> 
> Going back to Xen, instead of reading bar=1, it reads the mmio offset of
> the first region and then it naturally bails out. Even if it were to get
> the right bar, the io_base value it would compute (bar & 0xfffe) would be
> useless.

On x86, the code assumes that the interface is through an IO port; the
MMIO variant, iirc, so far is there only for ia64. The primary issue being
that the (stub) ioremap() x86 has isn't suitable for this purpose.

> I've tried passing the explicit parameters
> (com1=115200,8n1,0xfb601000,19,03:00.0), and the mere mention of an mmio
> io port for the serial card hard freezes the hypervisor immediately.

That's, as mentioned above, a result of the stubbed out ioremap().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:25:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFdL-00053Q-M2; Wed, 23 Nov 2011 16:25:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTFdJ-000539-9s
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:25:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322065483!5448580!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28912 invoked from network); 23 Nov 2011 16:24:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 16:24:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 16:24:42 +0000
Message-Id: <4ECD2C570200007800062BF8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 16:24:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <andres@lagarcavilla.org>
References: <0653c27a1ace1d8b05f703421658f355.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <0653c27a1ace1d8b05f703421658f355.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] PCI-E serial board not working under Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.11.11 at 16:55, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
> First off, ns16550_parse_port_config string compares "pci" with
> strncmp(conf, "pci", 5) which obviously fails. It should be 3. I can send
> trivial patch.

Yes, please. (It must be an oversight in an earlier change.)

> Once that is left behind, reading the bar with pci_conf_read32(0,b,d,f,
> PCI_BASE_ADDRESS_0) yields the mmio address of the first accessible
> region, instead of the bar.

This is an assumption, not a bug (not sure what, if any, conventions
exist here). If your card doesn't meet it, then you'll have to either
provide a patch (without breaking anyone else) or deal with this for
yourself. But read on.

Also, what is being read is the BAR, just that in your case it doesn't point
into IO port space.

> Linux inits this card fine, and reports three mmio regions at 0xfb600000
> (size 16k), 0xfb400000 (size 2M) and 0xfb200000 (size 2M), BAR 1 with the
> actual IO port at 0xfb601000 (one page inside the first mmio region). It
> gets irq 19.
> 
> Going back to Xen, instead of reading bar=1, it reads the mmio offset of
> the first region and then it naturally bails out. Even if it were to get
> the right bar, the io_base value it would compute (bar & 0xfffe) would be
> useless.

On x86, the code assumes that the interface is through an IO port; the
MMIO variant, iirc, so far is there only for ia64. The primary issue being
that the (stub) ioremap() x86 has isn't suitable for this purpose.

> I've tried passing the explicit parameters
> (com1=115200,8n1,0xfb601000,19,03:00.0), and the mere mention of an mmio
> io port for the serial card hard freezes the hypervisor immediately.

That's, as mentioned above, a result of the stubbed out ioremap().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:32:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFkM-0005Vi-Cf; Wed, 23 Nov 2011 16:32:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RTFkK-0005VA-VL
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:32:29 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322065917!4698067!1
X-Originating-IP: [209.85.212.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21753 invoked from network); 23 Nov 2011 16:31:58 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 16:31:58 -0000
Received: by vbbfq11 with SMTP id fq11so1691849vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 08:31:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=TuB5JbT2noAGC3g4ghYkk978tbHbdvDDW7uuAAh4eww=;
	b=uGqPiebVCwBGtrofCS1xWxB77JsJ9g5rXNcFJqLLYlqlTIjGZ+HEjSZP8aTXCJMftN
	ZdEz5IAUSZdgFDS0vk3XDX5K9V7J9RcWzDQcGDfSZSuub9qdle6MyXjLZGLXADA2x5nw
	QLMNfSc0J9VwKfVUC5/IjxkfEQAByFOEOTof0=
Received: by 10.52.23.134 with SMTP id m6mr5788548vdf.123.1322065917119; Wed,
	23 Nov 2011 08:31:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Wed, 23 Nov 2011 08:31:36 -0800 (PST)
In-Reply-To: <CACC6B9F.23926%keir.xen@gmail.com>
References: <4EA698C8.8030603@amd.com> <CACC6B9F.23926%keir.xen@gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Wed, 23 Nov 2011 16:31:36 +0000
Message-ID: <CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25 October 2011 13:35, Keir Fraser <keir.xen@gmail.com> wrote:
> On 25/10/2011 12:08, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
>
>>
>> Hi,
>>
>> Compiling the xen kernel fails with:
>>
>> xen/arch/x86/domain.c: In function 'alloc_domain_struct'
>> xen/arch/x86/domain.c:191: error: negative width in bit-field '<anonymou=
s>'
>
> Problem is that struct domain has grown bigger than a page for some reaso=
n,
> in your build environment.
>
> I can't reproduce this.
>
>> Removing the line
>>
>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>>
>> makes xen kernel compile again.
>
> But not actually work properly. We only allocate a single page for the
> domain struct. If the struct is bigger than a page, you'll get memory
> corruption at run time.
>

Is there a reason for that? What would be the recommended to add something
into the struct domain now if we can't make it bigger than a page.

Jean

> =A0-- Keir
>
>>
>> Christoph
>>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:32:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFkM-0005Vi-Cf; Wed, 23 Nov 2011 16:32:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RTFkK-0005VA-VL
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:32:29 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322065917!4698067!1
X-Originating-IP: [209.85.212.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21753 invoked from network); 23 Nov 2011 16:31:58 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 16:31:58 -0000
Received: by vbbfq11 with SMTP id fq11so1691849vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 08:31:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=TuB5JbT2noAGC3g4ghYkk978tbHbdvDDW7uuAAh4eww=;
	b=uGqPiebVCwBGtrofCS1xWxB77JsJ9g5rXNcFJqLLYlqlTIjGZ+HEjSZP8aTXCJMftN
	ZdEz5IAUSZdgFDS0vk3XDX5K9V7J9RcWzDQcGDfSZSuub9qdle6MyXjLZGLXADA2x5nw
	QLMNfSc0J9VwKfVUC5/IjxkfEQAByFOEOTof0=
Received: by 10.52.23.134 with SMTP id m6mr5788548vdf.123.1322065917119; Wed,
	23 Nov 2011 08:31:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Wed, 23 Nov 2011 08:31:36 -0800 (PST)
In-Reply-To: <CACC6B9F.23926%keir.xen@gmail.com>
References: <4EA698C8.8030603@amd.com> <CACC6B9F.23926%keir.xen@gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Wed, 23 Nov 2011 16:31:36 +0000
Message-ID: <CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25 October 2011 13:35, Keir Fraser <keir.xen@gmail.com> wrote:
> On 25/10/2011 12:08, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
>
>>
>> Hi,
>>
>> Compiling the xen kernel fails with:
>>
>> xen/arch/x86/domain.c: In function 'alloc_domain_struct'
>> xen/arch/x86/domain.c:191: error: negative width in bit-field '<anonymou=
s>'
>
> Problem is that struct domain has grown bigger than a page for some reaso=
n,
> in your build environment.
>
> I can't reproduce this.
>
>> Removing the line
>>
>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>>
>> makes xen kernel compile again.
>
> But not actually work properly. We only allocate a single page for the
> domain struct. If the struct is bigger than a page, you'll get memory
> corruption at run time.
>

Is there a reason for that? What would be the recommended to add something
into the struct domain now if we can't make it bigger than a page.

Jean

> =A0-- Keir
>
>>
>> Christoph
>>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:38:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFq8-0005of-Ts; Wed, 23 Nov 2011 16:38:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTFq6-0005oA-TM
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:38:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322066276!5459658!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3552 invoked from network); 23 Nov 2011 16:37:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-4.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Nov 2011 16:37:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322066276; l=2803;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=zwT9aCrvgcWu2AkjzyAj4B9f7Hg=;
	b=kRojnbPywgfWmwJ4hMpAVF8yyXSvXOnKQICSzfGLLYXjJHmrfOlc7y6CU0X9inExZPx
	cIpWqemRqSvf1E9x6BlkMhCXR09aGzA1e1TRADjfxnFk74OPkST59wZLuDZtpjCsgVbCw
	fNOYYO3JN3J0UX2j1RAdZgLFMUWpCGeoYEA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (fruni mo35) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a0653fnANGRU2Y ;
	Wed, 23 Nov 2011 17:37:42 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C1DA318637; Wed, 23 Nov 2011 17:37:28 +0100 (CET)
Date: Wed, 23 Nov 2011 17:37:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111123163728.GA6000@aepfle.de>
References: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
	<b9f83375b8bf452e866311e3ec3fbbc0.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b9f83375b8bf452e866311e3ec3fbbc0.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in
	ept_get
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Andres Lagar-Cavilla wrote:

> Hi Olaf,
> 
> thanks for posting these RFC patches, great work!
> 
> I have several comments. Most importantly, I want to hash out the
> interactions between these wait queues and the work I've been doing on p2m
> synchronization. I've been runnning Xen with synchronized (i.e. locking)
> p2m lookups for a few weeks now with little/no trouble. You can refer to a
> patch I posted to the list previously, which I can resend. (I'm waiting on
> feedback on some previous patches I sent to keep pushing on this work)
> 
> - I think the waitqueue should be part of struct arch_domain. It is an x86
> construct that applies only to the base level p2m of the domain, not every
> possible p2m in a nested setting.

Good point, I will move it. On the other hand, its current location cant
be the final solution. A wake_up would start all waiting vcpus, not just
the ones waiting for a certain gfn (in case of paging). There needs to
be a better way for selective wake_up.

> - The right place to wait is not ept->get_entry, imho, but rather the
> implementation-independent caller (get_gfn_type_access). More p2m
> implementations could be added in the future (however unlikely that may
> be) that can also perform paging.

The wait could probably be moved one level up, yes.

> - With locking p2m lookups, one needs to be careful about in_atomic. I
> haven't performed a full audit of all callers, but this is what I can say:
> 1. there are no code paths that perform recursive p2m lookups, *on
> different gfns*, with p2m_query_t != p2m_query
> 2. there are recursive lookups of different gfns, with p2m_query_t ==
> p2m_query, most notably pod sweeps. These do not represent a problem here,
> since those paths will skip over gfns that are paged.
> 
> Why is this important? Because we need to be in a position where a code
> snippet such as
> 
> get_gfn_type_access(gfn) {
> retry:
>    p2m_lock()
>    mfn = p2m->get_entry(gfn, &p2mt)
>    if (p2mt == paging) {
>        p2m_unlock()
>        sleep_on_waitqueue()
>        goto retry;
>    }
> 
> works. This will get us a non-racy p2m that sends vcpu's to sleep without
> holding locks. Makes sense?

Something like that can be done if needed, yes.

> - What is the plan for grant operations for pv-on-hvm drivers? Those will
> enter get_gfn* holding the domain lock, and thus in an atomic context.

Is that a new thing? So far my PVonHVM guests did not encounter that
issue. I see do_grant_table_op() taking the domain_lock, but is this
code path really entered from the guest or rather from dom0?
__get_paged_frame() returns GNTST_eagain, and that needs to be handled
by callers of do_grant_table_op. linux-2.6.18-xen.hg has code to retry
the grant operation in that case.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:38:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:38:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFq8-0005of-Ts; Wed, 23 Nov 2011 16:38:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTFq6-0005oA-TM
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:38:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322066276!5459658!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3552 invoked from network); 23 Nov 2011 16:37:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-4.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Nov 2011 16:37:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322066276; l=2803;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=zwT9aCrvgcWu2AkjzyAj4B9f7Hg=;
	b=kRojnbPywgfWmwJ4hMpAVF8yyXSvXOnKQICSzfGLLYXjJHmrfOlc7y6CU0X9inExZPx
	cIpWqemRqSvf1E9x6BlkMhCXR09aGzA1e1TRADjfxnFk74OPkST59wZLuDZtpjCsgVbCw
	fNOYYO3JN3J0UX2j1RAdZgLFMUWpCGeoYEA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (fruni mo35) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a0653fnANGRU2Y ;
	Wed, 23 Nov 2011 17:37:42 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C1DA318637; Wed, 23 Nov 2011 17:37:28 +0100 (CET)
Date: Wed, 23 Nov 2011 17:37:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111123163728.GA6000@aepfle.de>
References: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
	<b9f83375b8bf452e866311e3ec3fbbc0.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b9f83375b8bf452e866311e3ec3fbbc0.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in
	ept_get
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Andres Lagar-Cavilla wrote:

> Hi Olaf,
> 
> thanks for posting these RFC patches, great work!
> 
> I have several comments. Most importantly, I want to hash out the
> interactions between these wait queues and the work I've been doing on p2m
> synchronization. I've been runnning Xen with synchronized (i.e. locking)
> p2m lookups for a few weeks now with little/no trouble. You can refer to a
> patch I posted to the list previously, which I can resend. (I'm waiting on
> feedback on some previous patches I sent to keep pushing on this work)
> 
> - I think the waitqueue should be part of struct arch_domain. It is an x86
> construct that applies only to the base level p2m of the domain, not every
> possible p2m in a nested setting.

Good point, I will move it. On the other hand, its current location cant
be the final solution. A wake_up would start all waiting vcpus, not just
the ones waiting for a certain gfn (in case of paging). There needs to
be a better way for selective wake_up.

> - The right place to wait is not ept->get_entry, imho, but rather the
> implementation-independent caller (get_gfn_type_access). More p2m
> implementations could be added in the future (however unlikely that may
> be) that can also perform paging.

The wait could probably be moved one level up, yes.

> - With locking p2m lookups, one needs to be careful about in_atomic. I
> haven't performed a full audit of all callers, but this is what I can say:
> 1. there are no code paths that perform recursive p2m lookups, *on
> different gfns*, with p2m_query_t != p2m_query
> 2. there are recursive lookups of different gfns, with p2m_query_t ==
> p2m_query, most notably pod sweeps. These do not represent a problem here,
> since those paths will skip over gfns that are paged.
> 
> Why is this important? Because we need to be in a position where a code
> snippet such as
> 
> get_gfn_type_access(gfn) {
> retry:
>    p2m_lock()
>    mfn = p2m->get_entry(gfn, &p2mt)
>    if (p2mt == paging) {
>        p2m_unlock()
>        sleep_on_waitqueue()
>        goto retry;
>    }
> 
> works. This will get us a non-racy p2m that sends vcpu's to sleep without
> holding locks. Makes sense?

Something like that can be done if needed, yes.

> - What is the plan for grant operations for pv-on-hvm drivers? Those will
> enter get_gfn* holding the domain lock, and thus in an atomic context.

Is that a new thing? So far my PVonHVM guests did not encounter that
issue. I see do_grant_table_op() taking the domain_lock, but is this
code path really entered from the guest or rather from dom0?
__get_paged_frame() returns GNTST_eagain, and that needs to be handled
by callers of do_grant_table_op. linux-2.6.18-xen.hg has code to retry
the grant operation in that case.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:41:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:41:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFtH-0006BH-L1; Wed, 23 Nov 2011 16:41:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTFtF-0006Ar-FL
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:41:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322066471!4725031!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13443 invoked from network); 23 Nov 2011 16:41:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 16:41:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 16:41:10 +0000
Message-Id: <4ECD30330200007800062C2E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 16:41:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@gmail.com>
References: <4EA698C8.8030603@amd.com> <CACC6B9F.23926%keir.xen@gmail.com>
	<CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
In-Reply-To: <CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger <Christoph.Egger@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.11.11 at 17:31, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 25 October 2011 13:35, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 25/10/2011 12:08, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
>>
>>>
>>> Hi,
>>>
>>> Compiling the xen kernel fails with:
>>>
>>> xen/arch/x86/domain.c: In function 'alloc_domain_struct'
>>> xen/arch/x86/domain.c:191: error: negative width in bit-field '<anonymous>'
>>
>> Problem is that struct domain has grown bigger than a page for some reason,
>> in your build environment.
>>
>> I can't reproduce this.
>>
>>> Removing the line
>>>
>>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>>>
>>> makes xen kernel compile again.
>>
>> But not actually work properly. We only allocate a single page for the
>> domain struct. If the struct is bigger than a page, you'll get memory
>> corruption at run time.
>>
> 
> Is there a reason for that?

Of course there is: Post-boot there shouldn't be any allocations of
order greater than zero. This is a generally advisable thing, given that
Xen can't reclaim memory arbitrarily from domains, and in particular
also necessary for tmem.

> What would be the recommended to add something
> into the struct domain now if we can't make it bigger than a page.

Put a pointer to your data (or larger parts that are already there)
instead of the data itself into struct domain, and allocate it
separately. (You may have seen a patch from Olaf Hering late
yesterday or earlier today that moved the mem_event pieces out
of there for this very reason.)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:41:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:41:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTFtH-0006BH-L1; Wed, 23 Nov 2011 16:41:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTFtF-0006Ar-FL
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:41:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322066471!4725031!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13443 invoked from network); 23 Nov 2011 16:41:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 16:41:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 23 Nov 2011 16:41:10 +0000
Message-Id: <4ECD30330200007800062C2E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 23 Nov 2011 16:41:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@gmail.com>
References: <4EA698C8.8030603@amd.com> <CACC6B9F.23926%keir.xen@gmail.com>
	<CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
In-Reply-To: <CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger <Christoph.Egger@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.11.11 at 17:31, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 25 October 2011 13:35, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 25/10/2011 12:08, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
>>
>>>
>>> Hi,
>>>
>>> Compiling the xen kernel fails with:
>>>
>>> xen/arch/x86/domain.c: In function 'alloc_domain_struct'
>>> xen/arch/x86/domain.c:191: error: negative width in bit-field '<anonymous>'
>>
>> Problem is that struct domain has grown bigger than a page for some reason,
>> in your build environment.
>>
>> I can't reproduce this.
>>
>>> Removing the line
>>>
>>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>>>
>>> makes xen kernel compile again.
>>
>> But not actually work properly. We only allocate a single page for the
>> domain struct. If the struct is bigger than a page, you'll get memory
>> corruption at run time.
>>
> 
> Is there a reason for that?

Of course there is: Post-boot there shouldn't be any allocations of
order greater than zero. This is a generally advisable thing, given that
Xen can't reclaim memory arbitrarily from domains, and in particular
also necessary for tmem.

> What would be the recommended to add something
> into the struct domain now if we can't make it bigger than a page.

Put a pointer to your data (or larger parts that are already there)
instead of the data itself into struct domain, and allocate it
separately. (You may have seen a patch from Olaf Hering late
yesterday or earlier today that moved the mem_event pieces out
of there for this very reason.)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:50:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTG1I-0006eN-KQ; Wed, 23 Nov 2011 16:50:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTG1H-0006eG-6o
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:49:59 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322066968!4336841!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30934 invoked from network); 23 Nov 2011 16:49:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 16:49:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322066968; l=949;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=2W4NA7vrPzIITmhHJThckgaweao=;
	b=S67xdFiNKEw0VxRf6x85tbBuYF8wpJ55xL28z5VYRE2S3ry310lUJGGNXR3FF3SGK/r
	ot2Tns8xUQDxfjiM31T9z0nTTufaCz11uzJVolddV6+hM7+lchG87iIA8inihGtiBuL9n
	u//DNkl2oZKxrEbFbN/Prad5WqR2qodd7qg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (cohen mo62) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v0634bnANGd6Td ;
	Wed, 23 Nov 2011 17:49:23 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 91DF118637; Wed, 23 Nov 2011 17:49:18 +0100 (CET)
Date: Wed, 23 Nov 2011 17:49:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111123164918.GB6000@aepfle.de>
References: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
	<6c2682114a95a003123344f552a2c64c.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6c2682114a95a003123344f552a2c64c.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, adin@gridncetric.ca
Subject: Re: [Xen-devel] RFC: mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Andres Lagar-Cavilla wrote:

> Olaf, two questions here
> 
> - do you have any insight for events caused by foreign mappings? Those
> will be lost with a full ring, with or without wait queues

The callers of mem_event_check_ring() have to retry if the ring is full.
Thats what happens with p2m_mem_paging_populate(), the callers return
-ENOENT and expect a retry at some later point.

> - we have posted a patch (twice) previously, with changes to ring
> management, most importantly sending guest vcpus to sleep when space in
> the ring is < d->max_vcpus. I see these two patches as complementary. What
> is your take?

I'm not proposing to include my patch as is, because it has one issue:
wake_up will start all waiting vcpus even if there is just a single slot
free in the ringbuffer. You patch is better in this respect because only
a few will be started again.

I will send comments for it later.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 16:50:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 16:50:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTG1I-0006eN-KQ; Wed, 23 Nov 2011 16:50:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTG1H-0006eG-6o
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 16:49:59 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322066968!4336841!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30934 invoked from network); 23 Nov 2011 16:49:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 16:49:29 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322066968; l=949;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=2W4NA7vrPzIITmhHJThckgaweao=;
	b=S67xdFiNKEw0VxRf6x85tbBuYF8wpJ55xL28z5VYRE2S3ry310lUJGGNXR3FF3SGK/r
	ot2Tns8xUQDxfjiM31T9z0nTTufaCz11uzJVolddV6+hM7+lchG87iIA8inihGtiBuL9n
	u//DNkl2oZKxrEbFbN/Prad5WqR2qodd7qg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (cohen mo62) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v0634bnANGd6Td ;
	Wed, 23 Nov 2011 17:49:23 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 91DF118637; Wed, 23 Nov 2011 17:49:18 +0100 (CET)
Date: Wed, 23 Nov 2011 17:49:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111123164918.GB6000@aepfle.de>
References: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
	<6c2682114a95a003123344f552a2c64c.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6c2682114a95a003123344f552a2c64c.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, adin@gridncetric.ca
Subject: Re: [Xen-devel] RFC: mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Andres Lagar-Cavilla wrote:

> Olaf, two questions here
> 
> - do you have any insight for events caused by foreign mappings? Those
> will be lost with a full ring, with or without wait queues

The callers of mem_event_check_ring() have to retry if the ring is full.
Thats what happens with p2m_mem_paging_populate(), the callers return
-ENOENT and expect a retry at some later point.

> - we have posted a patch (twice) previously, with changes to ring
> management, most importantly sending guest vcpus to sleep when space in
> the ring is < d->max_vcpus. I see these two patches as complementary. What
> is your take?

I'm not proposing to include my patch as is, because it has one issue:
wake_up will start all waiting vcpus even if there is just a single slot
free in the ringbuffer. You patch is better in this respect because only
a few will be started again.

I will send comments for it later.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:01:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGC6-0007Ho-GI; Wed, 23 Nov 2011 17:01:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTGC5-0007Hh-LX
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:01:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322067639!4333999!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20198 invoked from network); 23 Nov 2011 17:00:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 17:00:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322067639; l=600;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=a0tF+5VNCdR+zS0zBI8T6edZV1U=;
	b=uzY6MZnAXYxumqMTFmBZRT/R18KG0EO3ycyE38Q1UwfHEc4mMssLARnjlqh+miw05t+
	h9IJHPnGNVmwUkF+w06xl0DYIj+NAqW6E3hx2duNo2s/Jk03IXxhWsjs3+GQpaGi8XTll
	KoEaevwgQ/Gf2vUfSgbBjf+oy8colVnUp74=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (jimi mo33) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c045b6nANFf7Dn ;
	Wed, 23 Nov 2011 18:00:26 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 53F4B18637; Wed, 23 Nov 2011 18:00:17 +0100 (CET)
Date: Wed, 23 Nov 2011 18:00:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111123170017.GC6000@aepfle.de>
References: <20111122211519.GA1039@aepfle.de>
	<CAF1CA5F.2560C%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1CA5F.2560C%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Keir Fraser wrote:

> We obviously can't have dom0 going to sleep on paging work. This, at least,
> isn't a wait-queue bug.

I had to rearrange some code in p2m_mem_paging_populate for my debug
stuff. This led to an uninitialized req, and as a result req.flags
sometimes had MEM_EVENT_FLAG_VCPU_PAUSED set. For some reason gcc did
not catch that..
Now waitqueues appear to work ok for me. Thanks!


What do you think about C99 initializers in p2m_mem_paging_populate,
just to avoid such mistakes?

   mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING };

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:01:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGC6-0007Ho-GI; Wed, 23 Nov 2011 17:01:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTGC5-0007Hh-LX
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:01:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322067639!4333999!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20198 invoked from network); 23 Nov 2011 17:00:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Nov 2011 17:00:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322067639; l=600;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=a0tF+5VNCdR+zS0zBI8T6edZV1U=;
	b=uzY6MZnAXYxumqMTFmBZRT/R18KG0EO3ycyE38Q1UwfHEc4mMssLARnjlqh+miw05t+
	h9IJHPnGNVmwUkF+w06xl0DYIj+NAqW6E3hx2duNo2s/Jk03IXxhWsjs3+GQpaGi8XTll
	KoEaevwgQ/Gf2vUfSgbBjf+oy8colVnUp74=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (jimi mo33) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c045b6nANFf7Dn ;
	Wed, 23 Nov 2011 18:00:26 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 53F4B18637; Wed, 23 Nov 2011 18:00:17 +0100 (CET)
Date: Wed, 23 Nov 2011 18:00:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111123170017.GC6000@aepfle.de>
References: <20111122211519.GA1039@aepfle.de>
	<CAF1CA5F.2560C%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF1CA5F.2560C%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, Keir Fraser wrote:

> We obviously can't have dom0 going to sleep on paging work. This, at least,
> isn't a wait-queue bug.

I had to rearrange some code in p2m_mem_paging_populate for my debug
stuff. This led to an uninitialized req, and as a result req.flags
sometimes had MEM_EVENT_FLAG_VCPU_PAUSED set. For some reason gcc did
not catch that..
Now waitqueues appear to work ok for me. Thanks!


What do you think about C99 initializers in p2m_mem_paging_populate,
just to avoid such mistakes?

   mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING };

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:11:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:11:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGLR-0007Yk-JA; Wed, 23 Nov 2011 17:10:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTGLQ-0007Yd-7C
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:10:48 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322068217!6048329!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2414 invoked from network); 23 Nov 2011 17:10:17 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 17:10:17 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73389613; Wed, 23 Nov 2011 18:10:16 +0100
Message-ID: <1322068169.26883.35.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 18:09:29 +0100
In-Reply-To: <1322065473.1005.151.camel@zakaz.uk.xensource.com>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
 schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8061296350353117102=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============8061296350353117102==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-b2p6OwMVVfDgkYxiBe9M"


--=-b2p6OwMVVfDgkYxiBe9M
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-11-23 at 16:24 +0000, Ian Campbell wrote:
> >  struct csched_private {
> > +    /* lock for the whole pluggable scheduler, nests inside cpupool_lo=
ck */
> >      spinlock_t lock;
> >      struct list_head active_sdom;
> >      uint32_t ncpus;
>=20
> Given that every scheduler plugin is going to need this lock perhaps it
> could be provided globally (but still have the responsibility for using
> it fall on the plugin)?
>=20
Makes sense to me, and it should be something pretty easy to do, if you
were thinking of just moving the lock to general code.
I'm saying this because both credit and credit2 has much more payload in
their `struct csched_private', and if we also want to get rid of the
struct for them as well, that would be a different story! :-)

> I was mainly thinking of the sedf case where you add and maintain the
> whole structure for just that lock. Perhaps you have future plans which
> involve having to do that anyway in which case maybe my suggestion
> doesn't make sense.
>
I know and I agree, that 1-field-struct is just as ugly as hell! Reason
why I went for it are homogeneity with the current code of all the
schedulers, and yes, also, what you're saying above, i.e., it might turn
useful in future to have some scheduler-wide repository in sedf as it is
now for credit*. But no, I don't have _specific_ plans yet, so your
comment do make sense.

Anyway, even if we'd stay with what's in this patch, I think this at
least need some commenting...

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-b2p6OwMVVfDgkYxiBe9M
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7NKMkACgkQk4XaBE3IOsR4kQCggdxArIZwLSu69FHgSkj+GaS5
lJIAoKPhb3fXn/v026WNpn34tgWPFMWU
=MH6R
-----END PGP SIGNATURE-----

--=-b2p6OwMVVfDgkYxiBe9M--



--===============8061296350353117102==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8061296350353117102==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:11:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:11:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGLR-0007Yk-JA; Wed, 23 Nov 2011 17:10:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RTGLQ-0007Yd-7C
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:10:48 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322068217!6048329!1
X-Originating-IP: [193.205.80.99]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2414 invoked from network); 23 Nov 2011 17:10:17 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 17:10:17 -0000
Received: from [62.94.142.149] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 73389613; Wed, 23 Nov 2011 18:10:16 +0100
Message-ID: <1322068169.26883.35.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 23 Nov 2011 18:09:29 +0100
In-Reply-To: <1322065473.1005.151.camel@zakaz.uk.xensource.com>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.0.3-2 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
 schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8061296350353117102=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============8061296350353117102==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-b2p6OwMVVfDgkYxiBe9M"


--=-b2p6OwMVVfDgkYxiBe9M
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-11-23 at 16:24 +0000, Ian Campbell wrote:
> >  struct csched_private {
> > +    /* lock for the whole pluggable scheduler, nests inside cpupool_lo=
ck */
> >      spinlock_t lock;
> >      struct list_head active_sdom;
> >      uint32_t ncpus;
>=20
> Given that every scheduler plugin is going to need this lock perhaps it
> could be provided globally (but still have the responsibility for using
> it fall on the plugin)?
>=20
Makes sense to me, and it should be something pretty easy to do, if you
were thinking of just moving the lock to general code.
I'm saying this because both credit and credit2 has much more payload in
their `struct csched_private', and if we also want to get rid of the
struct for them as well, that would be a different story! :-)

> I was mainly thinking of the sedf case where you add and maintain the
> whole structure for just that lock. Perhaps you have future plans which
> involve having to do that anyway in which case maybe my suggestion
> doesn't make sense.
>
I know and I agree, that 1-field-struct is just as ugly as hell! Reason
why I went for it are homogeneity with the current code of all the
schedulers, and yes, also, what you're saying above, i.e., it might turn
useful in future to have some scheduler-wide repository in sedf as it is
now for credit*. But no, I don't have _specific_ plans yet, so your
comment do make sense.

Anyway, even if we'd stay with what's in this patch, I think this at
least need some commenting...

Thanks and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy)


--=-b2p6OwMVVfDgkYxiBe9M
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7NKMkACgkQk4XaBE3IOsR4kQCggdxArIZwLSu69FHgSkj+GaS5
lJIAoKPhb3fXn/v026WNpn34tgWPFMWU
=MH6R
-----END PGP SIGNATURE-----

--=-b2p6OwMVVfDgkYxiBe9M--



--===============8061296350353117102==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8061296350353117102==--



From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:14:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:14:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGOP-0007ho-Fq; Wed, 23 Nov 2011 17:13:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTGON-0007hX-N1
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:13:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322068401!2752313!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31904 invoked from network); 23 Nov 2011 17:13:21 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:13:21 -0000
Received: by bkbzt12 with SMTP id zt12so2464330bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:13:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=6Hk4DjyTsEvkWbTDLh4do4i/A6nNaMces+p9O8KB/1U=;
	b=eXoxCzyABnwTHIRlc2nEkjGaf/FQ4b2PkMrT/aSyQwknOmS0ZwN+TTquzrhMUzTxfB
	IV7pWT7O+n5ThHey7b+0m3WxsOmk2yatPBu6H5ig39oc/c7WRIanl8FBKoreo1BXNewK
	aVYHt4QUObUzQcpkcVxSInjJiNTE/ueJ7mux8=
Received: by 10.205.135.129 with SMTP id ig1mr25344157bkc.106.1322068400315;
	Wed, 23 Nov 2011 09:13:20 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id f14sm13413191bkv.3.2011.11.23.09.13.18
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 09:13:19 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 17:13:17 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jean Guyader <jean.guyader@gmail.com>
Message-ID: <CAF2DA2D.256ED%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] xen kernel: build failure
Thread-Index: AcyqAzD24xzqf5IifkOoTvfnir4sug==
In-Reply-To: <CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 16:31, "Jean Guyader" <jean.guyader@gmail.com> wrote:

>>> Removing the line
>>> 
>>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>>> 
>>> makes xen kernel compile again.
>> 
>> But not actually work properly. We only allocate a single page for the
>> domain struct. If the struct is bigger than a page, you'll get memory
>> corruption at run time.
>> 
> 
> Is there a reason for that? What would be the recommended to add something
> into the struct domain now if we can't make it bigger than a page.

If the thing being added is sufficiently large and self-contained, it could
be allocated separately and a pointer added to the domain struct. Else a
large logical piece of the domain struct needs to be split off. Would have
to check what would be a nice large piece -- arch.{hvm,pv} for example. Jan
might also have an opinion, as he already did some work on shrinking the
domain struct.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:14:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:14:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGOP-0007ho-Fq; Wed, 23 Nov 2011 17:13:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTGON-0007hX-N1
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:13:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322068401!2752313!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31904 invoked from network); 23 Nov 2011 17:13:21 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:13:21 -0000
Received: by bkbzt12 with SMTP id zt12so2464330bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:13:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=6Hk4DjyTsEvkWbTDLh4do4i/A6nNaMces+p9O8KB/1U=;
	b=eXoxCzyABnwTHIRlc2nEkjGaf/FQ4b2PkMrT/aSyQwknOmS0ZwN+TTquzrhMUzTxfB
	IV7pWT7O+n5ThHey7b+0m3WxsOmk2yatPBu6H5ig39oc/c7WRIanl8FBKoreo1BXNewK
	aVYHt4QUObUzQcpkcVxSInjJiNTE/ueJ7mux8=
Received: by 10.205.135.129 with SMTP id ig1mr25344157bkc.106.1322068400315;
	Wed, 23 Nov 2011 09:13:20 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id f14sm13413191bkv.3.2011.11.23.09.13.18
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 09:13:19 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 17:13:17 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jean Guyader <jean.guyader@gmail.com>
Message-ID: <CAF2DA2D.256ED%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] xen kernel: build failure
Thread-Index: AcyqAzD24xzqf5IifkOoTvfnir4sug==
In-Reply-To: <CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 16:31, "Jean Guyader" <jean.guyader@gmail.com> wrote:

>>> Removing the line
>>> 
>>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>>> 
>>> makes xen kernel compile again.
>> 
>> But not actually work properly. We only allocate a single page for the
>> domain struct. If the struct is bigger than a page, you'll get memory
>> corruption at run time.
>> 
> 
> Is there a reason for that? What would be the recommended to add something
> into the struct domain now if we can't make it bigger than a page.

If the thing being added is sufficiently large and self-contained, it could
be allocated separately and a pointer added to the domain struct. Else a
large logical piece of the domain struct needs to be split off. Would have
to check what would be a nice large piece -- arch.{hvm,pv} for example. Jan
might also have an opinion, as he already did some work on shrinking the
domain struct.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:17:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:17:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGRk-0007tF-6V; Wed, 23 Nov 2011 17:17:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTGRi-0007sl-Ev
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:17:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322068608!2752758!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9242 invoked from network); 23 Nov 2011 17:16:48 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:16:48 -0000
Received: by bkbzt12 with SMTP id zt12so2468875bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:16:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0U/8ML6eyO/6GjnVhzlMwMZDPE/bYUCOzg0AbXjxVZ8=;
	b=PFaR7rj12mbySpAttSoXUwwT+OIT9Vaw0DTwiRPPKbh0SMdrV6jrqIGiC/tlhxBhOK
	Cn836Zg/ZsAFMPAFbHNo/tVfxiuYfsymlv5L5YtIvwVBGPk4ZcniHl6/PuODY9fwqzji
	h+Ims+HzOkYcVowYRgzqJdnb8Mg8bqPAmECI8=
Received: by 10.204.41.66 with SMTP id n2mr25319297bke.77.1322068607673;
	Wed, 23 Nov 2011 09:16:47 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id z7sm13428254bka.1.2011.11.23.09.16.45
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 09:16:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 17:16:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF2DAFB.256EF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqA6u/YPIz4SJrjUuVJSulwM3zTg==
In-Reply-To: <20111123170017.GC6000@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 17:00, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Keir Fraser wrote:
> 
>> We obviously can't have dom0 going to sleep on paging work. This, at least,
>> isn't a wait-queue bug.
> 
> I had to rearrange some code in p2m_mem_paging_populate for my debug
> stuff. This led to an uninitialized req, and as a result req.flags
> sometimes had MEM_EVENT_FLAG_VCPU_PAUSED set. For some reason gcc did
> not catch that..
> Now waitqueues appear to work ok for me. Thanks!

Great. However, while eyeballing wait.c I spotted at least two bugs. I'm
pretty sure that the hypervisor will blow up pretty quickly when you resume
testing with multiple physical CPUs, for example. I need to create a couple
of fixup patches which I will then send to you for test.

By the way, did you test my patch to domain_crash when the stack-save area
isn't large enough?

> What do you think about C99 initializers in p2m_mem_paging_populate,
> just to avoid such mistakes?
> 
>    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING };

We like them.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:17:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:17:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGRk-0007tF-6V; Wed, 23 Nov 2011 17:17:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTGRi-0007sl-Ev
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:17:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322068608!2752758!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9242 invoked from network); 23 Nov 2011 17:16:48 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:16:48 -0000
Received: by bkbzt12 with SMTP id zt12so2468875bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:16:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0U/8ML6eyO/6GjnVhzlMwMZDPE/bYUCOzg0AbXjxVZ8=;
	b=PFaR7rj12mbySpAttSoXUwwT+OIT9Vaw0DTwiRPPKbh0SMdrV6jrqIGiC/tlhxBhOK
	Cn836Zg/ZsAFMPAFbHNo/tVfxiuYfsymlv5L5YtIvwVBGPk4ZcniHl6/PuODY9fwqzji
	h+Ims+HzOkYcVowYRgzqJdnb8Mg8bqPAmECI8=
Received: by 10.204.41.66 with SMTP id n2mr25319297bke.77.1322068607673;
	Wed, 23 Nov 2011 09:16:47 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id z7sm13428254bka.1.2011.11.23.09.16.45
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 09:16:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 17:16:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF2DAFB.256EF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqA6u/YPIz4SJrjUuVJSulwM3zTg==
In-Reply-To: <20111123170017.GC6000@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 17:00, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Keir Fraser wrote:
> 
>> We obviously can't have dom0 going to sleep on paging work. This, at least,
>> isn't a wait-queue bug.
> 
> I had to rearrange some code in p2m_mem_paging_populate for my debug
> stuff. This led to an uninitialized req, and as a result req.flags
> sometimes had MEM_EVENT_FLAG_VCPU_PAUSED set. For some reason gcc did
> not catch that..
> Now waitqueues appear to work ok for me. Thanks!

Great. However, while eyeballing wait.c I spotted at least two bugs. I'm
pretty sure that the hypervisor will blow up pretty quickly when you resume
testing with multiple physical CPUs, for example. I need to create a couple
of fixup patches which I will then send to you for test.

By the way, did you test my patch to domain_crash when the stack-save area
isn't large enough?

> What do you think about C99 initializers in p2m_mem_paging_populate,
> just to avoid such mistakes?
> 
>    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING };

We like them.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:18:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGST-0007wc-LU; Wed, 23 Nov 2011 17:18:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTGSS-0007wL-MU
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:18:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322068653!4726437!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22444 invoked from network); 23 Nov 2011 17:17:34 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:17:34 -0000
Received: by yenm6 with SMTP id m6so2436417yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:17:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=9Bbnwmss+ByDqmlSFYz1NscKuwYwXOjU0cWNqa1zuGw=;
	b=O8mDIln1fqigf6AzZACMg1Q2K4RNW38EiDtQ/rCfXBrJAD7ztg1tOPqmnT6h1hghqP
	pVTNIJ0ZvyEtS2yf0GAP9R1DnUWNQkiryoZ3/IhtAXLyzn5frkwio98HAsCby7t58/2A
	vavRig2ba+rLexUVXd+Ex0O1+Nu4EP3TqAUok=
Received: by 10.205.139.65 with SMTP id iv1mr12652651bkc.34.1322068652904;
	Wed, 23 Nov 2011 09:17:32 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id z15sm13418207bkv.4.2011.11.23.09.17.29
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 09:17:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 17:17:24 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CAF2DB24.256F1%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] RFC: mem_event: use wait queue when ring is full
Thread-Index: AcyqA8QvGpkFKSsn+EKKbEIVaf25xg==
In-Reply-To: <20111123164918.GB6000@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, adin@gridncetric.ca
Subject: Re: [Xen-devel] RFC: mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 16:49, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Andres Lagar-Cavilla wrote:
> 
>> Olaf, two questions here
>> 
>> - do you have any insight for events caused by foreign mappings? Those
>> will be lost with a full ring, with or without wait queues
> 
> The callers of mem_event_check_ring() have to retry if the ring is full.
> Thats what happens with p2m_mem_paging_populate(), the callers return
> -ENOENT and expect a retry at some later point.
> 
>> - we have posted a patch (twice) previously, with changes to ring
>> management, most importantly sending guest vcpus to sleep when space in
>> the ring is < d->max_vcpus. I see these two patches as complementary. What
>> is your take?
> 
> I'm not proposing to include my patch as is, because it has one issue:
> wake_up will start all waiting vcpus even if there is just a single slot
> free in the ringbuffer. You patch is better in this respect because only
> a few will be started again.

Do you need a wake_up_one() function?

 -- Keir

> I will send comments for it later.
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:18:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGST-0007wc-LU; Wed, 23 Nov 2011 17:18:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTGSS-0007wL-MU
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:18:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322068653!4726437!1
X-Originating-IP: [209.85.213.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22444 invoked from network); 23 Nov 2011 17:17:34 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:17:34 -0000
Received: by yenm6 with SMTP id m6so2436417yen.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:17:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=9Bbnwmss+ByDqmlSFYz1NscKuwYwXOjU0cWNqa1zuGw=;
	b=O8mDIln1fqigf6AzZACMg1Q2K4RNW38EiDtQ/rCfXBrJAD7ztg1tOPqmnT6h1hghqP
	pVTNIJ0ZvyEtS2yf0GAP9R1DnUWNQkiryoZ3/IhtAXLyzn5frkwio98HAsCby7t58/2A
	vavRig2ba+rLexUVXd+Ex0O1+Nu4EP3TqAUok=
Received: by 10.205.139.65 with SMTP id iv1mr12652651bkc.34.1322068652904;
	Wed, 23 Nov 2011 09:17:32 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id z15sm13418207bkv.4.2011.11.23.09.17.29
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 09:17:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 17:17:24 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CAF2DB24.256F1%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] RFC: mem_event: use wait queue when ring is full
Thread-Index: AcyqA8QvGpkFKSsn+EKKbEIVaf25xg==
In-Reply-To: <20111123164918.GB6000@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, adin@gridncetric.ca
Subject: Re: [Xen-devel] RFC: mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 16:49, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, Nov 22, Andres Lagar-Cavilla wrote:
> 
>> Olaf, two questions here
>> 
>> - do you have any insight for events caused by foreign mappings? Those
>> will be lost with a full ring, with or without wait queues
> 
> The callers of mem_event_check_ring() have to retry if the ring is full.
> Thats what happens with p2m_mem_paging_populate(), the callers return
> -ENOENT and expect a retry at some later point.
> 
>> - we have posted a patch (twice) previously, with changes to ring
>> management, most importantly sending guest vcpus to sleep when space in
>> the ring is < d->max_vcpus. I see these two patches as complementary. What
>> is your take?
> 
> I'm not proposing to include my patch as is, because it has one issue:
> wake_up will start all waiting vcpus even if there is just a single slot
> free in the ringbuffer. You patch is better in this respect because only
> a few will be started again.

Do you need a wake_up_one() function?

 -- Keir

> I will send comments for it later.
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:21:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGVD-0008BB-FH; Wed, 23 Nov 2011 17:20:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTGVB-0008Af-Qr
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:20:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322068823!4339753!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22442 invoked from network); 23 Nov 2011 17:20:23 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:20:23 -0000
Received: by bkbzt12 with SMTP id zt12so2474226bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:20:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tssC6nZKZ09CdCVPLqUzevoj/vZBDJoIftk+RqdF53c=;
	b=m1hg2vx/RmbMt8UwzZgbRtrrmXX7Tt8lF0qtFlt0mZWXk3n+N+JfrkAA5TsNTK2bgC
	UnDyvdvHzjVYsPZRqciJNB8dbskpzveOt0EuOpVyoOaAqWkYuhIvv1XkgCj09n41JSzn
	yYOBwGgxqC3/oJsya1k+mlJNC0amOlSdRH4os=
Received: by 10.204.152.83 with SMTP id f19mr25241074bkw.90.1322068823169;
	Wed, 23 Nov 2011 09:20:23 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id f14sm13430812bkv.3.2011.11.23.09.20.19
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 09:20:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 17:20:18 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jean Guyader <jean.guyader@eu.citrix.com>, <xen-devel@lists.xensource.com>
Message-ID: <CAF2DBD2.256F3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough, reverse
	OpRegion
Thread-Index: AcyqBCvmSWnsnz904kCn1ioctm0yNw==
In-Reply-To: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
Mime-version: 1.0
Cc: allen.m.kay@intel.com
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:

> 
> The Intel GPU uses a two pages NVS region called OpRegion.
> In order to get full support for the driver in the guest
> we need to map this region.
> 
> This patch reserves 2 pages on the top of the RAM and
> mark this region as NVS in the e820. Then we write the
> address to the config space (offset 0xfc) so the device
> model can map the OpRegion at this address in the guest.

Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.

Is it correct to do this for *all* gfx devices with Intel vendor id?

 -- Keir

> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  tools/firmware/hvmloader/config.h   |    1 +
>  tools/firmware/hvmloader/e820.c     |    8 ++++++++
>  tools/firmware/hvmloader/pci.c      |   28 ++++++++++++++++++++++++++++
>  tools/firmware/hvmloader/pci_regs.h |    2 ++
>  4 files changed, 39 insertions(+), 0 deletions(-)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:21:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGVD-0008BB-FH; Wed, 23 Nov 2011 17:20:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTGVB-0008Af-Qr
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:20:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322068823!4339753!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22442 invoked from network); 23 Nov 2011 17:20:23 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:20:23 -0000
Received: by bkbzt12 with SMTP id zt12so2474226bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:20:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tssC6nZKZ09CdCVPLqUzevoj/vZBDJoIftk+RqdF53c=;
	b=m1hg2vx/RmbMt8UwzZgbRtrrmXX7Tt8lF0qtFlt0mZWXk3n+N+JfrkAA5TsNTK2bgC
	UnDyvdvHzjVYsPZRqciJNB8dbskpzveOt0EuOpVyoOaAqWkYuhIvv1XkgCj09n41JSzn
	yYOBwGgxqC3/oJsya1k+mlJNC0amOlSdRH4os=
Received: by 10.204.152.83 with SMTP id f19mr25241074bkw.90.1322068823169;
	Wed, 23 Nov 2011 09:20:23 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id f14sm13430812bkv.3.2011.11.23.09.20.19
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 09:20:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 17:20:18 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jean Guyader <jean.guyader@eu.citrix.com>, <xen-devel@lists.xensource.com>
Message-ID: <CAF2DBD2.256F3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough, reverse
	OpRegion
Thread-Index: AcyqBCvmSWnsnz904kCn1ioctm0yNw==
In-Reply-To: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
Mime-version: 1.0
Cc: allen.m.kay@intel.com
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:

> 
> The Intel GPU uses a two pages NVS region called OpRegion.
> In order to get full support for the driver in the guest
> we need to map this region.
> 
> This patch reserves 2 pages on the top of the RAM and
> mark this region as NVS in the e820. Then we write the
> address to the config space (offset 0xfc) so the device
> model can map the OpRegion at this address in the guest.

Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.

Is it correct to do this for *all* gfx devices with Intel vendor id?

 -- Keir

> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  tools/firmware/hvmloader/config.h   |    1 +
>  tools/firmware/hvmloader/e820.c     |    8 ++++++++
>  tools/firmware/hvmloader/pci.c      |   28 ++++++++++++++++++++++++++++
>  tools/firmware/hvmloader/pci_regs.h |    2 ++
>  4 files changed, 39 insertions(+), 0 deletions(-)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:23:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:23:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGX6-0008KB-1B; Wed, 23 Nov 2011 17:22:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTGX4-0008Js-2K
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:22:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322068939!2765906!1
X-Originating-IP: [208.97.132.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21078 invoked from network); 23 Nov 2011 17:22:19 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.81) by server-16.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 17:22:19 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id C836476C06F;
	Wed, 23 Nov 2011 09:22:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=P+GSe8pYJwj6S9OAY6fQRV2WXYBRXOIcu31uxMqx12vS
	neO7CcE3e0LGG69M3yjACjEE8wiPq/33CC2JHNo83VbeFABKP5vrUCMOFIS12Ilb
	KUk+w3+eyg2QuIWWGIGkB7DpQt300KIclMpRo1YZoaJenKY6KmEa6Ur+yJ14zMw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=WuaTQdBYa5PFETcfny43MRlN4m4=; b=W42v2sLW
	d7ZsODaou6MAwpYx9PkJV7ETxPf1U3eHX8dQNPhjC0CIUW3R706r1AZ28tPfD0tL
	pw1+6tYNXOklUlpJuPIZpHWvCcc4hv7JDoiQz6iMv+D+gijMMcnFpFT2yb+DkS8E
	FfQ36g4m1DkWyh28YPiu3r48Hkj/74HCvbE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 6CE2576C072; 
	Wed, 23 Nov 2011 09:22:18 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 23 Nov 2011 09:22:18 -0800
Message-ID: <64bcb346ef05628bec4e65c3e9d18d5f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4ECD2C570200007800062BF8@nat28.tlf.novell.com>
References: <0653c27a1ace1d8b05f703421658f355.squirrel@webmail.lagarcavilla.org>
	<4ECD2C570200007800062BF8@nat28.tlf.novell.com>
Date: Wed, 23 Nov 2011 09:22:18 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] PCI-E serial board not working under Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks, I will try a few things to get my card working. The main obstacle
seems to get an x86 ioremap for this card. As I've mentioned, I'm
basically poking in the dark here wrt configuring a pci dev.

Andres

>>>> On 23.11.11 at 16:55, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>> wrote:
>> First off, ns16550_parse_port_config string compares "pci" with
>> strncmp(conf, "pci", 5) which obviously fails. It should be 3. I can
>> send
>> trivial patch.
>
> Yes, please. (It must be an oversight in an earlier change.)
>
>> Once that is left behind, reading the bar with pci_conf_read32(0,b,d,f,
>> PCI_BASE_ADDRESS_0) yields the mmio address of the first accessible
>> region, instead of the bar.
>
> This is an assumption, not a bug (not sure what, if any, conventions
> exist here). If your card doesn't meet it, then you'll have to either
> provide a patch (without breaking anyone else) or deal with this for
> yourself. But read on.
>
> Also, what is being read is the BAR, just that in your case it doesn't
> point
> into IO port space.
>
>> Linux inits this card fine, and reports three mmio regions at 0xfb600000
>> (size 16k), 0xfb400000 (size 2M) and 0xfb200000 (size 2M), BAR 1 with
>> the
>> actual IO port at 0xfb601000 (one page inside the first mmio region). It
>> gets irq 19.
>>
>> Going back to Xen, instead of reading bar=1, it reads the mmio offset of
>> the first region and then it naturally bails out. Even if it were to get
>> the right bar, the io_base value it would compute (bar & 0xfffe) would
>> be
>> useless.
>
> On x86, the code assumes that the interface is through an IO port; the
> MMIO variant, iirc, so far is there only for ia64. The primary issue being
> that the (stub) ioremap() x86 has isn't suitable for this purpose.
>
>> I've tried passing the explicit parameters
>> (com1=115200,8n1,0xfb601000,19,03:00.0), and the mere mention of an mmio
>> io port for the serial card hard freezes the hypervisor immediately.
>
> That's, as mentioned above, a result of the stubbed out ioremap().
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:23:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:23:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGX6-0008KB-1B; Wed, 23 Nov 2011 17:22:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTGX4-0008Js-2K
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:22:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322068939!2765906!1
X-Originating-IP: [208.97.132.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21078 invoked from network); 23 Nov 2011 17:22:19 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.81) by server-16.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 17:22:19 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id C836476C06F;
	Wed, 23 Nov 2011 09:22:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=P+GSe8pYJwj6S9OAY6fQRV2WXYBRXOIcu31uxMqx12vS
	neO7CcE3e0LGG69M3yjACjEE8wiPq/33CC2JHNo83VbeFABKP5vrUCMOFIS12Ilb
	KUk+w3+eyg2QuIWWGIGkB7DpQt300KIclMpRo1YZoaJenKY6KmEa6Ur+yJ14zMw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=WuaTQdBYa5PFETcfny43MRlN4m4=; b=W42v2sLW
	d7ZsODaou6MAwpYx9PkJV7ETxPf1U3eHX8dQNPhjC0CIUW3R706r1AZ28tPfD0tL
	pw1+6tYNXOklUlpJuPIZpHWvCcc4hv7JDoiQz6iMv+D+gijMMcnFpFT2yb+DkS8E
	FfQ36g4m1DkWyh28YPiu3r48Hkj/74HCvbE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 6CE2576C072; 
	Wed, 23 Nov 2011 09:22:18 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 23 Nov 2011 09:22:18 -0800
Message-ID: <64bcb346ef05628bec4e65c3e9d18d5f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4ECD2C570200007800062BF8@nat28.tlf.novell.com>
References: <0653c27a1ace1d8b05f703421658f355.squirrel@webmail.lagarcavilla.org>
	<4ECD2C570200007800062BF8@nat28.tlf.novell.com>
Date: Wed, 23 Nov 2011 09:22:18 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] PCI-E serial board not working under Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks, I will try a few things to get my card working. The main obstacle
seems to get an x86 ioremap for this card. As I've mentioned, I'm
basically poking in the dark here wrt configuring a pci dev.

Andres

>>>> On 23.11.11 at 16:55, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>>>> wrote:
>> First off, ns16550_parse_port_config string compares "pci" with
>> strncmp(conf, "pci", 5) which obviously fails. It should be 3. I can
>> send
>> trivial patch.
>
> Yes, please. (It must be an oversight in an earlier change.)
>
>> Once that is left behind, reading the bar with pci_conf_read32(0,b,d,f,
>> PCI_BASE_ADDRESS_0) yields the mmio address of the first accessible
>> region, instead of the bar.
>
> This is an assumption, not a bug (not sure what, if any, conventions
> exist here). If your card doesn't meet it, then you'll have to either
> provide a patch (without breaking anyone else) or deal with this for
> yourself. But read on.
>
> Also, what is being read is the BAR, just that in your case it doesn't
> point
> into IO port space.
>
>> Linux inits this card fine, and reports three mmio regions at 0xfb600000
>> (size 16k), 0xfb400000 (size 2M) and 0xfb200000 (size 2M), BAR 1 with
>> the
>> actual IO port at 0xfb601000 (one page inside the first mmio region). It
>> gets irq 19.
>>
>> Going back to Xen, instead of reading bar=1, it reads the mmio offset of
>> the first region and then it naturally bails out. Even if it were to get
>> the right bar, the io_base value it would compute (bar & 0xfffe) would
>> be
>> useless.
>
> On x86, the code assumes that the interface is through an IO port; the
> MMIO variant, iirc, so far is there only for ia64. The primary issue being
> that the (stub) ioremap() x86 has isn't suitable for this purpose.
>
>> I've tried passing the explicit parameters
>> (com1=115200,8n1,0xfb601000,19,03:00.0), and the mere mention of an mmio
>> io port for the serial card hard freezes the hypervisor immediately.
>
> That's, as mentioned above, a result of the stubbed out ioremap().
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:29:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:29:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGdT-0000G6-09; Wed, 23 Nov 2011 17:29:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RTGdR-0000Fu-J4
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:29:25 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322069334!5435208!1
X-Originating-IP: [209.85.212.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9434 invoked from network); 23 Nov 2011 17:28:55 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:28:55 -0000
Received: by vbbfq11 with SMTP id fq11so1776756vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:28:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=+M+EF70mg7wZLL0K8bjAAoQHZeejLF7MRmlAfFu8mHs=;
	b=wcauTr8jldnFDAlbiT3RD4GI0moJ20t5TVyIpk0z0yfFDLAck+N8FkH7ls9JagPkmq
	dx/Rfq0sX3XDRnzPoyOJ+rwY2dJlGlxsIkBiFuyYjEBvShq6rty1W5OZ7t8aBTXE94tD
	rg/NzBzT1D4zbR4iNDP69feyPz/iKEcvncgHM=
Received: by 10.52.21.148 with SMTP id v20mr24265058vde.89.1322069334107; Wed,
	23 Nov 2011 09:28:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Wed, 23 Nov 2011 09:28:33 -0800 (PST)
In-Reply-To: <CAF2DBD2.256F3%keir.xen@gmail.com>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Wed, 23 Nov 2011 17:28:33 +0000
Message-ID: <CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
	reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
>
>>
>> The Intel GPU uses a two pages NVS region called OpRegion.
>> In order to get full support for the driver in the guest
>> we need to map this region.
>>
>> This patch reserves 2 pages on the top of the RAM and
>> mark this region as NVS in the e820. Then we write the
>> address to the config space (offset 0xfc) so the device
>> model can map the OpRegion at this address in the guest.
>
> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
>

Ok, that is handy.

> Is it correct to do this for *all* gfx devices with Intel vendor id?
>

The OpRegion is a Intel GPU specific thing.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:29:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:29:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGdT-0000G6-09; Wed, 23 Nov 2011 17:29:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RTGdR-0000Fu-J4
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:29:25 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322069334!5435208!1
X-Originating-IP: [209.85.212.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9434 invoked from network); 23 Nov 2011 17:28:55 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:28:55 -0000
Received: by vbbfq11 with SMTP id fq11so1776756vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:28:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=+M+EF70mg7wZLL0K8bjAAoQHZeejLF7MRmlAfFu8mHs=;
	b=wcauTr8jldnFDAlbiT3RD4GI0moJ20t5TVyIpk0z0yfFDLAck+N8FkH7ls9JagPkmq
	dx/Rfq0sX3XDRnzPoyOJ+rwY2dJlGlxsIkBiFuyYjEBvShq6rty1W5OZ7t8aBTXE94tD
	rg/NzBzT1D4zbR4iNDP69feyPz/iKEcvncgHM=
Received: by 10.52.21.148 with SMTP id v20mr24265058vde.89.1322069334107; Wed,
	23 Nov 2011 09:28:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Wed, 23 Nov 2011 09:28:33 -0800 (PST)
In-Reply-To: <CAF2DBD2.256F3%keir.xen@gmail.com>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Wed, 23 Nov 2011 17:28:33 +0000
Message-ID: <CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
	reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
>
>>
>> The Intel GPU uses a two pages NVS region called OpRegion.
>> In order to get full support for the driver in the guest
>> we need to map this region.
>>
>> This patch reserves 2 pages on the top of the RAM and
>> mark this region as NVS in the e820. Then we write the
>> address to the config space (offset 0xfc) so the device
>> model can map the OpRegion at this address in the guest.
>
> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
>

Ok, that is handy.

> Is it correct to do this for *all* gfx devices with Intel vendor id?
>

The OpRegion is a Intel GPU specific thing.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:30:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGeZ-0000RL-GG; Wed, 23 Nov 2011 17:30:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTGeY-0000Qy-6R
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:30:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322069385!49462902!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24963 invoked from network); 23 Nov 2011 17:29:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:29:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315180800"; 
   d="scan'208";a="9098228"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 17:30:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 17:30:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1322068169.26883.35.camel@Solace>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
	<1322068169.26883.35.camel@Solace>
Organization: Citrix Systems, Inc.
Date: Wed, 23 Nov 2011 17:30:03 +0000
Message-ID: <1322069403.9567.0.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
 schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 17:09 +0000, Dario Faggioli wrote:
> On Wed, 2011-11-23 at 16:24 +0000, Ian Campbell wrote:
> > >  struct csched_private {
> > > +    /* lock for the whole pluggable scheduler, nests inside cpupool_lock */
> > >      spinlock_t lock;
> > >      struct list_head active_sdom;
> > >      uint32_t ncpus;
> > 
> > Given that every scheduler plugin is going to need this lock perhaps it
> > could be provided globally (but still have the responsibility for using
> > it fall on the plugin)?
> > 
> Makes sense to me, and it should be something pretty easy to do, if you
> were thinking of just moving the lock to general code.
> I'm saying this because both credit and credit2 has much more payload in
> their `struct csched_private', and if we also want to get rid of the
> struct for them as well, that would be a different story! :-)

No, I just meant the lock.

> 
> > I was mainly thinking of the sedf case where you add and maintain the
> > whole structure for just that lock. Perhaps you have future plans which
> > involve having to do that anyway in which case maybe my suggestion
> > doesn't make sense.
> >
> I know and I agree, that 1-field-struct is just as ugly as hell! Reason
> why I went for it are homogeneity with the current code of all the
> schedulers, and yes, also, what you're saying above, i.e., it might turn
> useful in future to have some scheduler-wide repository in sedf as it is
> now for credit*. But no, I don't have _specific_ plans yet, so your
> comment do make sense.
> 
> Anyway, even if we'd stay with what's in this patch, I think this at
> least need some commenting...
> 
> Thanks and Regards,
> Dario
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:30:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGeZ-0000RL-GG; Wed, 23 Nov 2011 17:30:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTGeY-0000Qy-6R
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:30:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322069385!49462902!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24963 invoked from network); 23 Nov 2011 17:29:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:29:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315180800"; 
   d="scan'208";a="9098228"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 17:30:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 17:30:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1322068169.26883.35.camel@Solace>
References: <1322060131.30168.15.camel@Abyss> <1322060876.30168.18.camel@Abyss>
	<1322065473.1005.151.camel@zakaz.uk.xensource.com>
	<1322068169.26883.35.camel@Solace>
Organization: Citrix Systems, Inc.
Date: Wed, 23 Nov 2011 17:30:03 +0000
Message-ID: <1322069403.9567.0.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC/RFT][PATCH 1 of 3] Move locking into pluggable
 schedulers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 17:09 +0000, Dario Faggioli wrote:
> On Wed, 2011-11-23 at 16:24 +0000, Ian Campbell wrote:
> > >  struct csched_private {
> > > +    /* lock for the whole pluggable scheduler, nests inside cpupool_lock */
> > >      spinlock_t lock;
> > >      struct list_head active_sdom;
> > >      uint32_t ncpus;
> > 
> > Given that every scheduler plugin is going to need this lock perhaps it
> > could be provided globally (but still have the responsibility for using
> > it fall on the plugin)?
> > 
> Makes sense to me, and it should be something pretty easy to do, if you
> were thinking of just moving the lock to general code.
> I'm saying this because both credit and credit2 has much more payload in
> their `struct csched_private', and if we also want to get rid of the
> struct for them as well, that would be a different story! :-)

No, I just meant the lock.

> 
> > I was mainly thinking of the sedf case where you add and maintain the
> > whole structure for just that lock. Perhaps you have future plans which
> > involve having to do that anyway in which case maybe my suggestion
> > doesn't make sense.
> >
> I know and I agree, that 1-field-struct is just as ugly as hell! Reason
> why I went for it are homogeneity with the current code of all the
> schedulers, and yes, also, what you're saying above, i.e., it might turn
> useful in future to have some scheduler-wide repository in sedf as it is
> now for credit*. But no, I don't have _specific_ plans yet, so your
> comment do make sense.
> 
> Anyway, even if we'd stay with what's in this patch, I think this at
> least need some commenting...
> 
> Thanks and Regards,
> Dario
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:36:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:36:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGkQ-0000k2-Ct; Wed, 23 Nov 2011 17:36:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTGkO-0000jp-T9
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:36:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322069765!2767492!1
X-Originating-IP: [208.97.132.119]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25391 invoked from network); 23 Nov 2011 17:36:06 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 17:36:06 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 994A276C06E;
	Wed, 23 Nov 2011 09:36:04 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LjWWR4pZmrV3l7hW5baO/gEZ8fBF0ceE/bwBwZQEJIgU
	rDtToHk+N2MIcWQLt6Lkp72sRjkB0PxQsBA3iuxWtJoONBiYSJpMF+XG6io4a7Oh
	mCn0DSUuS2PiM/cge/GdhSh1V9RA+p6N23pq3Kw1fUeaUqkHZdE0mMfo0lTsR1E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=AN83LbNpOdE2MAf7vBLWFk35C6I=; b=GZZqaXxE
	pUPR3LqFrONo8G1YqNN6KR49f2apypBEwtIiIB6fzlU5KNpBv52MV+W4QHCGu1iI
	AnrmzYVulbqQrwN8p2cN6wyq2xYeeJZQqAm9+PbNODlYmBPVW6+nNPhoKW8TVrSC
	diaa5KY2YKqXuznfKr21IJ8I0TLXSSf8Wgo=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 4347F76C065; 
	Wed, 23 Nov 2011 09:36:04 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 23 Nov 2011 09:36:04 -0800
Message-ID: <3032fb41a74f3f77dca8b1e1ce1f1077.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111123163728.GA6000@aepfle.de>
References: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
	<b9f83375b8bf452e866311e3ec3fbbc0.squirrel@webmail.lagarcavilla.org>
	<20111123163728.GA6000@aepfle.de>
Date: Wed, 23 Nov 2011 09:36:04 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in
	ept_get
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Below:
> On Tue, Nov 22, Andres Lagar-Cavilla wrote:
>
>> Hi Olaf,
>>
>> thanks for posting these RFC patches, great work!
>>
>> I have several comments. Most importantly, I want to hash out the
>> interactions between these wait queues and the work I've been doing on
>> p2m
>> synchronization. I've been runnning Xen with synchronized (i.e. locking)
>> p2m lookups for a few weeks now with little/no trouble. You can refer to
>> a
>> patch I posted to the list previously, which I can resend. (I'm waiting
>> on
>> feedback on some previous patches I sent to keep pushing on this work)
>>
>> - I think the waitqueue should be part of struct arch_domain. It is an
>> x86
>> construct that applies only to the base level p2m of the domain, not
>> every
>> possible p2m in a nested setting.
>
> Good point, I will move it. On the other hand, its current location cant
> be the final solution. A wake_up would start all waiting vcpus, not just
> the ones waiting for a certain gfn (in case of paging). There needs to
> be a better way for selective wake_up.

As long as you wrap the wait queue go-to-sleep action in a while loop that
rechecks the sleep condition before exiting the loop, this should be fine.
It's a standard idiom. There is an argument against spurious wake-ups, but
imhois no biggie.

>
>> - The right place to wait is not ept->get_entry, imho, but rather the
>> implementation-independent caller (get_gfn_type_access). More p2m
>> implementations could be added in the future (however unlikely that may
>> be) that can also perform paging.
>
> The wait could probably be moved one level up, yes.
>
>> - With locking p2m lookups, one needs to be careful about in_atomic. I
>> haven't performed a full audit of all callers, but this is what I can
>> say:
>> 1. there are no code paths that perform recursive p2m lookups, *on
>> different gfns*, with p2m_query_t != p2m_query
>> 2. there are recursive lookups of different gfns, with p2m_query_t ==
>> p2m_query, most notably pod sweeps. These do not represent a problem
>> here,
>> since those paths will skip over gfns that are paged.
>>
>> Why is this important? Because we need to be in a position where a code
>> snippet such as
>>
>> get_gfn_type_access(gfn) {
>> retry:
>>    p2m_lock()
>>    mfn = p2m->get_entry(gfn, &p2mt)
>>    if (p2mt == paging) {
>>        p2m_unlock()
>>        sleep_on_waitqueue()
>>        goto retry;
>>    }
>>
>> works. This will get us a non-racy p2m that sends vcpu's to sleep
>> without
>> holding locks. Makes sense?
>
> Something like that can be done if needed, yes.
>
>> - What is the plan for grant operations for pv-on-hvm drivers? Those
>> will
>> enter get_gfn* holding the domain lock, and thus in an atomic context.
>
> Is that a new thing? So far my PVonHVM guests did not encounter that
> issue. I see do_grant_table_op() taking the domain_lock, but is this
> code path really entered from the guest or rather from dom0?
> __get_paged_frame() returns GNTST_eagain, and that needs to be handled
> by callers of do_grant_table_op. linux-2.6.18-xen.hg has code to retry
> the grant operation in that case.

I'm on your side here. I've seen posts in the list about putting dom0 into
an hvm container using ept, though.

Andres
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:36:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:36:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGkQ-0000k2-Ct; Wed, 23 Nov 2011 17:36:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTGkO-0000jp-T9
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:36:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322069765!2767492!1
X-Originating-IP: [208.97.132.119]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25391 invoked from network); 23 Nov 2011 17:36:06 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 17:36:06 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 994A276C06E;
	Wed, 23 Nov 2011 09:36:04 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LjWWR4pZmrV3l7hW5baO/gEZ8fBF0ceE/bwBwZQEJIgU
	rDtToHk+N2MIcWQLt6Lkp72sRjkB0PxQsBA3iuxWtJoONBiYSJpMF+XG6io4a7Oh
	mCn0DSUuS2PiM/cge/GdhSh1V9RA+p6N23pq3Kw1fUeaUqkHZdE0mMfo0lTsR1E=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=AN83LbNpOdE2MAf7vBLWFk35C6I=; b=GZZqaXxE
	pUPR3LqFrONo8G1YqNN6KR49f2apypBEwtIiIB6fzlU5KNpBv52MV+W4QHCGu1iI
	AnrmzYVulbqQrwN8p2cN6wyq2xYeeJZQqAm9+PbNODlYmBPVW6+nNPhoKW8TVrSC
	diaa5KY2YKqXuznfKr21IJ8I0TLXSSf8Wgo=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 4347F76C065; 
	Wed, 23 Nov 2011 09:36:04 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 23 Nov 2011 09:36:04 -0800
Message-ID: <3032fb41a74f3f77dca8b1e1ce1f1077.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111123163728.GA6000@aepfle.de>
References: <mailman.1126.1321998852.12970.xen-devel@lists.xensource.com>
	<b9f83375b8bf452e866311e3ec3fbbc0.squirrel@webmail.lagarcavilla.org>
	<20111123163728.GA6000@aepfle.de>
Date: Wed, 23 Nov 2011 09:36:04 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] RFC: xenpaging: use waitqueue in
	ept_get
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Below:
> On Tue, Nov 22, Andres Lagar-Cavilla wrote:
>
>> Hi Olaf,
>>
>> thanks for posting these RFC patches, great work!
>>
>> I have several comments. Most importantly, I want to hash out the
>> interactions between these wait queues and the work I've been doing on
>> p2m
>> synchronization. I've been runnning Xen with synchronized (i.e. locking)
>> p2m lookups for a few weeks now with little/no trouble. You can refer to
>> a
>> patch I posted to the list previously, which I can resend. (I'm waiting
>> on
>> feedback on some previous patches I sent to keep pushing on this work)
>>
>> - I think the waitqueue should be part of struct arch_domain. It is an
>> x86
>> construct that applies only to the base level p2m of the domain, not
>> every
>> possible p2m in a nested setting.
>
> Good point, I will move it. On the other hand, its current location cant
> be the final solution. A wake_up would start all waiting vcpus, not just
> the ones waiting for a certain gfn (in case of paging). There needs to
> be a better way for selective wake_up.

As long as you wrap the wait queue go-to-sleep action in a while loop that
rechecks the sleep condition before exiting the loop, this should be fine.
It's a standard idiom. There is an argument against spurious wake-ups, but
imhois no biggie.

>
>> - The right place to wait is not ept->get_entry, imho, but rather the
>> implementation-independent caller (get_gfn_type_access). More p2m
>> implementations could be added in the future (however unlikely that may
>> be) that can also perform paging.
>
> The wait could probably be moved one level up, yes.
>
>> - With locking p2m lookups, one needs to be careful about in_atomic. I
>> haven't performed a full audit of all callers, but this is what I can
>> say:
>> 1. there are no code paths that perform recursive p2m lookups, *on
>> different gfns*, with p2m_query_t != p2m_query
>> 2. there are recursive lookups of different gfns, with p2m_query_t ==
>> p2m_query, most notably pod sweeps. These do not represent a problem
>> here,
>> since those paths will skip over gfns that are paged.
>>
>> Why is this important? Because we need to be in a position where a code
>> snippet such as
>>
>> get_gfn_type_access(gfn) {
>> retry:
>>    p2m_lock()
>>    mfn = p2m->get_entry(gfn, &p2mt)
>>    if (p2mt == paging) {
>>        p2m_unlock()
>>        sleep_on_waitqueue()
>>        goto retry;
>>    }
>>
>> works. This will get us a non-racy p2m that sends vcpu's to sleep
>> without
>> holding locks. Makes sense?
>
> Something like that can be done if needed, yes.
>
>> - What is the plan for grant operations for pv-on-hvm drivers? Those
>> will
>> enter get_gfn* holding the domain lock, and thus in an atomic context.
>
> Is that a new thing? So far my PVonHVM guests did not encounter that
> issue. I see do_grant_table_op() taking the domain_lock, but is this
> code path really entered from the guest or rather from dom0?
> __get_paged_frame() returns GNTST_eagain, and that needs to be handled
> by callers of do_grant_table_op. linux-2.6.18-xen.hg has code to retry
> the grant operation in that case.

I'm on your side here. I've seen posts in the list about putting dom0 into
an hvm container using ept, though.

Andres
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:38:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:38:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGlu-0000qr-5R; Wed, 23 Nov 2011 17:38:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RTGls-0000qS-DY
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:38:08 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322069857!5483767!1
X-Originating-IP: [209.85.220.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22062 invoked from network); 23 Nov 2011 17:37:38 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:37:38 -0000
Received: by vcbfo1 with SMTP id fo1so2128932vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:37:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=/KPPy8lpN+ooWcsX/buy8F1ALgnrRFv1GdGwqX305nA=;
	b=uSZJaIPpHh6jUOaYvzoY0S/95id5HTcX0jnsMc0y3pr9sePPYXiEyhxdyw/WTC78Us
	BiCl3qIqkjfQMbyJYZ7YR84J/iq2dpDF+wzx1yo3nnQrpfZWY2h4PZNe4yHesVSrKZfJ
	940cA3rB8nri/E/mzAIiaxRawCLvwS54hNaew=
Received: by 10.52.95.164 with SMTP id dl4mr26659550vdb.72.1322069857066; Wed,
	23 Nov 2011 09:37:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Wed, 23 Nov 2011 09:37:16 -0800 (PST)
In-Reply-To: <CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
	<CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Wed, 23 Nov 2011 17:37:16 +0000
Message-ID: <CAEBdQ91x9Afq5kSAZD=vttx+5yrfJbCcVpJNcWzBSYNmx_AMBw@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
	reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
>>
>>>
>>> The Intel GPU uses a two pages NVS region called OpRegion.
>>> In order to get full support for the driver in the guest
>>> we need to map this region.
>>>
>>> This patch reserves 2 pages on the top of the RAM and
>>> mark this region as NVS in the e820. Then we write the
>>> address to the config space (offset 0xfc) so the device
>>> model can map the OpRegion at this address in the guest.
>>
>> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
>>
>
> Ok, that is handy.
>
>> Is it correct to do this for *all* gfx devices with Intel vendor id?
>>
>
> The OpRegion is a Intel GPU specific thing.
>

Sorry didn't read carefully the first time, yes I think it's correct
to do that for
all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
a NVS region on the host, but that won't work for stub domain.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:38:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:38:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGlu-0000qr-5R; Wed, 23 Nov 2011 17:38:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RTGls-0000qS-DY
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:38:08 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322069857!5483767!1
X-Originating-IP: [209.85.220.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22062 invoked from network); 23 Nov 2011 17:37:38 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:37:38 -0000
Received: by vcbfo1 with SMTP id fo1so2128932vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 09:37:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=/KPPy8lpN+ooWcsX/buy8F1ALgnrRFv1GdGwqX305nA=;
	b=uSZJaIPpHh6jUOaYvzoY0S/95id5HTcX0jnsMc0y3pr9sePPYXiEyhxdyw/WTC78Us
	BiCl3qIqkjfQMbyJYZ7YR84J/iq2dpDF+wzx1yo3nnQrpfZWY2h4PZNe4yHesVSrKZfJ
	940cA3rB8nri/E/mzAIiaxRawCLvwS54hNaew=
Received: by 10.52.95.164 with SMTP id dl4mr26659550vdb.72.1322069857066; Wed,
	23 Nov 2011 09:37:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Wed, 23 Nov 2011 09:37:16 -0800 (PST)
In-Reply-To: <CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
	<CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Wed, 23 Nov 2011 17:37:16 +0000
Message-ID: <CAEBdQ91x9Afq5kSAZD=vttx+5yrfJbCcVpJNcWzBSYNmx_AMBw@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
	reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
>>
>>>
>>> The Intel GPU uses a two pages NVS region called OpRegion.
>>> In order to get full support for the driver in the guest
>>> we need to map this region.
>>>
>>> This patch reserves 2 pages on the top of the RAM and
>>> mark this region as NVS in the e820. Then we write the
>>> address to the config space (offset 0xfc) so the device
>>> model can map the OpRegion at this address in the guest.
>>
>> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
>>
>
> Ok, that is handy.
>
>> Is it correct to do this for *all* gfx devices with Intel vendor id?
>>
>
> The OpRegion is a Intel GPU specific thing.
>

Sorry didn't read carefully the first time, yes I think it's correct
to do that for
all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
a NVS region on the host, but that won't work for stub domain.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:41:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:41:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGp1-00012t-6x; Wed, 23 Nov 2011 17:41:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTGoz-00012A-Fs
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:41:21 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322070050!4322799!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29254 invoked from network); 23 Nov 2011 17:40:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:40:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315195200"; d="scan'208";a="19364616"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:40:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 12:40:49 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pANHekdX024196;	Wed, 23 Nov 2011 09:40:48 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 17:40:37 +0000
Message-ID: <1322070039-439-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] libxl_qmp: Cut qmp_send function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch prepare for the next patch, that will introduce an alternative send
function.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_qmp.c |   56 +++++++++++++++++++++++++++++++---------------
 1 files changed, 38 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..99ab4fa 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -446,13 +446,14 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
     return rc;
 }
 
-static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
-                    qmp_callback_t callback, void *opaque,
-                    qmp_request_context *context)
+static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
+                              const char *cmd, libxl_key_value_list *args,
+                              qmp_callback_t callback, void *opaque,
+                              qmp_request_context *context)
 {
     yajl_gen_config conf = { 0, NULL };
-    const unsigned char *buf;
+    const unsigned char *buf = NULL;
+    char *ret = NULL;
     unsigned int len = 0;
     yajl_gen_status s;
     yajl_gen hand;
@@ -460,7 +461,7 @@ static int qmp_send(libxl__qmp_handler *qmp,
 
     hand = yajl_gen_alloc(&conf, NULL);
     if (!hand) {
-        return -1;
+        return NULL;
     }
 
     yajl_gen_map_open(hand);
@@ -479,14 +480,14 @@ static int qmp_send(libxl__qmp_handler *qmp,
     if (s) {
         LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
                    "Failed to generate a qmp command");
-        return -1;
+        goto out;
     }
 
     elm = malloc(sizeof (callback_id_pair));
     if (elm == NULL) {
         LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
                          "Failed to allocate a QMP callback");
-        goto error;
+        goto out;
     }
     elm->id = qmp->last_id_used;
     elm->callback = callback;
@@ -494,22 +495,41 @@ static int qmp_send(libxl__qmp_handler *qmp,
     elm->context = context;
     SIMPLEQ_INSERT_TAIL(&qmp->callback_list, elm, next);
 
+    ret = libxl__strndup(gc, (const char*)buf, len);
+
     LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, "next qmp command: '%s'", buf);
 
-    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, len,
+out:
+    yajl_gen_free(hand);
+    return ret;
+}
+
+static int qmp_send(libxl__qmp_handler *qmp,
+                    const char *cmd, libxl_key_value_list *args,
+                    qmp_callback_t callback, void *opaque,
+                    qmp_request_context *context)
+{
+    char *buf = NULL;
+    int rc = -1;
+    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+
+    buf = qmp_send_prepare(&gc, qmp, cmd, args, callback, opaque, context);
+
+    if (buf == NULL) {
+        goto out;
+    }
+
+    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, strlen(buf),
                             "QMP command", "QMP socket"))
-        goto error;
+        goto out;
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket"))
-        goto error;
+        goto out;
 
-    yajl_gen_free(hand);
-
-    return qmp->last_id_used;
-
-error:
-    yajl_gen_free(hand);
-    return -1;
+    rc = qmp->last_id_used;
+out:
+    libxl__free_all(&gc);
+    return rc;
 }
 
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:41:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:41:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGp1-00012t-6x; Wed, 23 Nov 2011 17:41:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTGoz-00012A-Fs
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:41:21 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322070050!4322799!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29254 invoked from network); 23 Nov 2011 17:40:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:40:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315195200"; d="scan'208";a="19364616"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:40:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 12:40:49 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pANHekdX024196;	Wed, 23 Nov 2011 09:40:48 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 17:40:37 +0000
Message-ID: <1322070039-439-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] libxl_qmp: Cut qmp_send function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch prepare for the next patch, that will introduce an alternative send
function.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_qmp.c |   56 +++++++++++++++++++++++++++++++---------------
 1 files changed, 38 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..99ab4fa 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -446,13 +446,14 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
     return rc;
 }
 
-static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
-                    qmp_callback_t callback, void *opaque,
-                    qmp_request_context *context)
+static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
+                              const char *cmd, libxl_key_value_list *args,
+                              qmp_callback_t callback, void *opaque,
+                              qmp_request_context *context)
 {
     yajl_gen_config conf = { 0, NULL };
-    const unsigned char *buf;
+    const unsigned char *buf = NULL;
+    char *ret = NULL;
     unsigned int len = 0;
     yajl_gen_status s;
     yajl_gen hand;
@@ -460,7 +461,7 @@ static int qmp_send(libxl__qmp_handler *qmp,
 
     hand = yajl_gen_alloc(&conf, NULL);
     if (!hand) {
-        return -1;
+        return NULL;
     }
 
     yajl_gen_map_open(hand);
@@ -479,14 +480,14 @@ static int qmp_send(libxl__qmp_handler *qmp,
     if (s) {
         LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
                    "Failed to generate a qmp command");
-        return -1;
+        goto out;
     }
 
     elm = malloc(sizeof (callback_id_pair));
     if (elm == NULL) {
         LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
                          "Failed to allocate a QMP callback");
-        goto error;
+        goto out;
     }
     elm->id = qmp->last_id_used;
     elm->callback = callback;
@@ -494,22 +495,41 @@ static int qmp_send(libxl__qmp_handler *qmp,
     elm->context = context;
     SIMPLEQ_INSERT_TAIL(&qmp->callback_list, elm, next);
 
+    ret = libxl__strndup(gc, (const char*)buf, len);
+
     LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG, "next qmp command: '%s'", buf);
 
-    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, len,
+out:
+    yajl_gen_free(hand);
+    return ret;
+}
+
+static int qmp_send(libxl__qmp_handler *qmp,
+                    const char *cmd, libxl_key_value_list *args,
+                    qmp_callback_t callback, void *opaque,
+                    qmp_request_context *context)
+{
+    char *buf = NULL;
+    int rc = -1;
+    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+
+    buf = qmp_send_prepare(&gc, qmp, cmd, args, callback, opaque, context);
+
+    if (buf == NULL) {
+        goto out;
+    }
+
+    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, strlen(buf),
                             "QMP command", "QMP socket"))
-        goto error;
+        goto out;
     if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
                             "CRLF", "QMP socket"))
-        goto error;
+        goto out;
 
-    yajl_gen_free(hand);
-
-    return qmp->last_id_used;
-
-error:
-    yajl_gen_free(hand);
-    return -1;
+    rc = qmp->last_id_used;
+out:
+    libxl__free_all(&gc);
+    return rc;
 }
 
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:41:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:41:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGp1-000133-Jd; Wed, 23 Nov 2011 17:41:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTGp0-000129-8p
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:41:22 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322070048!5444161!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8203 invoked from network); 23 Nov 2011 17:40:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:40:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315195200"; d="scan'208";a="171708107"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:40:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 12:40:50 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pANHekdY024196;	Wed, 23 Nov 2011 09:40:49 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 17:40:38 +0000
Message-ID: <1322070039-439-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] libxl_qmp: Command migrate.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This command works in two steps. First, a fd is sent to QEMU through the QMP
socket. And then, the second command "migrate" use the fd previously sent to
ask QEMU to save its states.

This come with an alternative qmp_send function that can send a fd.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |    2 +
 tools/libxl/libxl_qmp.c      |  109 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 111 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..e4afd2b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -528,6 +528,8 @@ _hidden int libxl__qmp_query_serial(libxl__qmp_handler *qmp);
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Save current QEMU state into fd. */
+_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 99ab4fa..891ca9e 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -532,6 +532,52 @@ out:
     return rc;
 }
 
+static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
+                       libxl_key_value_list *args,
+                       qmp_callback_t callback, void *opaque,
+                       qmp_request_context *context,
+                       int fd)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    char control[CMSG_SPACE(sizeof (fd))];
+    struct iovec iov;
+    char *buf = NULL;
+
+    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
+
+    /* Response data */
+    iov.iov_base = buf;
+    iov.iov_len  = strlen(buf);
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof (control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
+    *(int *)CMSG_DATA(cmsg) = fd;
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
+        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
+                         "Failed to send a QMP message to QEMU.");
+        return ERROR_FAIL;
+    }
+    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
+                            "CRLF", "QMP socket")) {
+        return ERROR_FAIL;
+    }
+
+    return qmp->last_id_used;
+}
+
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
                                 libxl_key_value_list *args,
                                 qmp_callback_t callback, void *opaque,
@@ -768,6 +814,69 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     return qmp_device_del(gc, domid, id);
 }
 
+static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
+                     int fd, const char *name)
+{
+    flexarray_t *parameters = NULL;
+    libxl_key_value_list args = NULL;
+    int rc = 0;
+
+    parameters = flexarray_make(2, 1);
+    if (!parameters)
+        return ERROR_NOMEM;
+    flexarray_append_pair(parameters, "fdname", (char*)name);
+    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    if (!args) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
+        rc = ERROR_FAIL;
+    }
+out:
+    flexarray_free(parameters);
+    return rc;
+}
+
+int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
+{
+#define MIGRATE_FD_NAME "dm-migrate"
+    libxl__qmp_handler *qmp = NULL;
+    flexarray_t *parameters = NULL;
+    libxl_key_value_list args = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
+    if (rc)
+        goto out;
+
+    parameters = flexarray_make(2, 1);
+    if (!parameters) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
+    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    if (!args) {
+        rc = ERROR_NOMEM;
+        goto out2;
+    }
+
+    rc = qmp_synchronous_send(qmp, "migrate", &args,
+                              NULL, NULL, qmp->timeout);
+
+out2:
+    flexarray_free(parameters);
+out:
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:41:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:41:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGp1-000133-Jd; Wed, 23 Nov 2011 17:41:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTGp0-000129-8p
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:41:22 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322070048!5444161!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8203 invoked from network); 23 Nov 2011 17:40:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:40:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315195200"; d="scan'208";a="171708107"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:40:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 12:40:50 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pANHekdY024196;	Wed, 23 Nov 2011 09:40:49 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 17:40:38 +0000
Message-ID: <1322070039-439-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] libxl_qmp: Command migrate.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This command works in two steps. First, a fd is sent to QEMU through the QMP
socket. And then, the second command "migrate" use the fd previously sent to
ask QEMU to save its states.

This come with an alternative qmp_send function that can send a fd.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |    2 +
 tools/libxl/libxl_qmp.c      |  109 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 111 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..e4afd2b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -528,6 +528,8 @@ _hidden int libxl__qmp_query_serial(libxl__qmp_handler *qmp);
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Save current QEMU state into fd. */
+_hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 99ab4fa..891ca9e 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -532,6 +532,52 @@ out:
     return rc;
 }
 
+static int qmp_send_fd(libxl__gc *gc, libxl__qmp_handler *qmp,
+                       libxl_key_value_list *args,
+                       qmp_callback_t callback, void *opaque,
+                       qmp_request_context *context,
+                       int fd)
+{
+    struct msghdr msg = { 0 };
+    struct cmsghdr *cmsg;
+    char control[CMSG_SPACE(sizeof (fd))];
+    struct iovec iov;
+    char *buf = NULL;
+
+    buf = qmp_send_prepare(gc, qmp, "getfd", args, callback, opaque, context);
+
+    /* Response data */
+    iov.iov_base = buf;
+    iov.iov_len  = strlen(buf);
+
+    /* compose the message */
+    msg.msg_iov = &iov;
+    msg.msg_iovlen = 1;
+    msg.msg_control = control;
+    msg.msg_controllen = sizeof (control);
+
+    /* attach open fd */
+    cmsg = CMSG_FIRSTHDR(&msg);
+    cmsg->cmsg_level = SOL_SOCKET;
+    cmsg->cmsg_type = SCM_RIGHTS;
+    cmsg->cmsg_len = CMSG_LEN(sizeof (fd));
+    *(int *)CMSG_DATA(cmsg) = fd;
+
+    msg.msg_controllen = cmsg->cmsg_len;
+
+    if (sendmsg(qmp->qmp_fd, &msg, 0) < 0) {
+        LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR,
+                         "Failed to send a QMP message to QEMU.");
+        return ERROR_FAIL;
+    }
+    if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
+                            "CRLF", "QMP socket")) {
+        return ERROR_FAIL;
+    }
+
+    return qmp->last_id_used;
+}
+
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
                                 libxl_key_value_list *args,
                                 qmp_callback_t callback, void *opaque,
@@ -768,6 +814,69 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     return qmp_device_del(gc, domid, id);
 }
 
+static int qmp_getfd(libxl__gc *gc, libxl__qmp_handler *qmp,
+                     int fd, const char *name)
+{
+    flexarray_t *parameters = NULL;
+    libxl_key_value_list args = NULL;
+    int rc = 0;
+
+    parameters = flexarray_make(2, 1);
+    if (!parameters)
+        return ERROR_NOMEM;
+    flexarray_append_pair(parameters, "fdname", (char*)name);
+    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    if (!args) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    if (qmp_send_fd(gc, qmp, &args, NULL, NULL, NULL, fd) < 0) {
+        rc = ERROR_FAIL;
+    }
+out:
+    flexarray_free(parameters);
+    return rc;
+}
+
+int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd)
+{
+#define MIGRATE_FD_NAME "dm-migrate"
+    libxl__qmp_handler *qmp = NULL;
+    flexarray_t *parameters = NULL;
+    libxl_key_value_list args = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_getfd(gc, qmp, fd, MIGRATE_FD_NAME);
+    if (rc)
+        goto out;
+
+    parameters = flexarray_make(2, 1);
+    if (!parameters) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    flexarray_append_pair(parameters, "uri", "fd:" MIGRATE_FD_NAME);
+    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    if (!args) {
+        rc = ERROR_NOMEM;
+        goto out2;
+    }
+
+    rc = qmp_synchronous_send(qmp, "migrate", &args,
+                              NULL, NULL, qmp->timeout);
+
+out2:
+    flexarray_free(parameters);
+out:
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:41:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:41:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGp2-00013B-2v; Wed, 23 Nov 2011 17:41:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTGp0-00012F-A6
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:41:22 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322070050!4322799!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29289 invoked from network); 23 Nov 2011 17:40:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:40:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315195200"; d="scan'208";a="19364617"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:40:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 12:40:51 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pANHekdZ024196;	Wed, 23 Nov 2011 09:40:50 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 17:40:39 +0000
Message-ID: <1322070039-439-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] libxl: Introduce migrate with the new QEMU.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_dm.c  |    6 ++++--
 tools/libxl/libxl_dom.c |   28 +++++++++++++++++++++++++---
 2 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bf38877..d1e023b 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -408,8 +408,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
         }
     }
     if (info->saved_state) {
-        flexarray_append(dm_args, "-loadvm");
-        flexarray_append(dm_args, info->saved_state);
+        /* This file descriptor is meant to be used by QEMU */
+        int migration_fd = open(info->saved_state, O_RDONLY);
+        flexarray_append(dm_args, "-incoming");
+        flexarray_append(dm_args, libxl__sprintf(gc, "fd:%d", migration_fd));
     }
     for (i = 0; info->extra && info->extra[i] != NULL; i++)
         flexarray_append(dm_args, info->extra[i]);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 718281a..3cef616 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -595,9 +595,31 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
     struct stat st;
     uint32_t qemu_state_len;
 
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Saving device model state to %s", filename);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "save");
-    libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        char *path = NULL;
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Saving device model state to %s", filename);
+        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                              domid);
+        libxl__xs_write(gc, XBT_NULL, path, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC);
+        if (fd2 < 0) {
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "Unable to create a QEMU save file\n");
+            return ERROR_FAIL;
+        }
+        /* Save DM state into fd2 */
+        if (libxl__qmp_migrate(gc, domid, fd2))
+            return ERROR_FAIL;
+        break;
+    default:
+        return ERROR_INVAL;
+    }
 
     if (stat(filename, &st) < 0)
     {
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:41:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:41:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGp2-00013B-2v; Wed, 23 Nov 2011 17:41:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTGp0-00012F-A6
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:41:22 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322070050!4322799!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29289 invoked from network); 23 Nov 2011 17:40:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:40:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315195200"; d="scan'208";a="19364617"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:40:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 12:40:51 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pANHekdZ024196;	Wed, 23 Nov 2011 09:40:50 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 17:40:39 +0000
Message-ID: <1322070039-439-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] libxl: Introduce migrate with the new QEMU.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_dm.c  |    6 ++++--
 tools/libxl/libxl_dom.c |   28 +++++++++++++++++++++++++---
 2 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bf38877..d1e023b 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -408,8 +408,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
         }
     }
     if (info->saved_state) {
-        flexarray_append(dm_args, "-loadvm");
-        flexarray_append(dm_args, info->saved_state);
+        /* This file descriptor is meant to be used by QEMU */
+        int migration_fd = open(info->saved_state, O_RDONLY);
+        flexarray_append(dm_args, "-incoming");
+        flexarray_append(dm_args, libxl__sprintf(gc, "fd:%d", migration_fd));
     }
     for (i = 0; info->extra && info->extra[i] != NULL; i++)
         flexarray_append(dm_args, info->extra[i]);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 718281a..3cef616 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -595,9 +595,31 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
     struct stat st;
     uint32_t qemu_state_len;
 
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Saving device model state to %s", filename);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "save");
-    libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        char *path = NULL;
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Saving device model state to %s", filename);
+        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                              domid);
+        libxl__xs_write(gc, XBT_NULL, path, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC);
+        if (fd2 < 0) {
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "Unable to create a QEMU save file\n");
+            return ERROR_FAIL;
+        }
+        /* Save DM state into fd2 */
+        if (libxl__qmp_migrate(gc, domid, fd2))
+            return ERROR_FAIL;
+        break;
+    default:
+        return ERROR_INVAL;
+    }
 
     if (stat(filename, &st) < 0)
     {
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:41:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:41:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGoz-00012W-Pu; Wed, 23 Nov 2011 17:41:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTGoy-000127-9N
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:41:20 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322070048!5444161!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8140 invoked from network); 23 Nov 2011 17:40:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:40:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315195200"; d="scan'208";a="171708104"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:40:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 12:40:48 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pANHekdW024196;	Wed, 23 Nov 2011 09:40:47 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 17:40:36 +0000
Message-ID: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/3] Migration on QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series introduce migration with QEMU upstream.

A patch series for QEMU will be sent later meant to "fix" the default behavior
of QEMU during save/restore.

There is two new QMP commands implemented:
  - getfd: This give a file descriptor to QEMU through the unix socket.
  - migration: This ask QEMU to save its states in a fd previously sent.

In order to call "getfd", an alternative qmp_send have been implemented in
libxl.

Regards,


Anthony PERARD (3):
  libxl_qmp: Cut qmp_send function.
  libxl_qmp: Command migrate.
  libxl: Introduce migrate with the new QEMU.

 tools/libxl/libxl_dm.c       |    6 +-
 tools/libxl/libxl_dom.c      |   28 +++++++-
 tools/libxl/libxl_internal.h |    2 +
 tools/libxl/libxl_qmp.c      |  161 +++++++++++++++++++++++++++++++++++++----
 4 files changed, 176 insertions(+), 21 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:41:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:41:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGoz-00012W-Pu; Wed, 23 Nov 2011 17:41:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTGoy-000127-9N
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:41:20 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322070048!5444161!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8140 invoked from network); 23 Nov 2011 17:40:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:40:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315195200"; d="scan'208";a="171708104"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 12:40:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 12:40:48 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pANHekdW024196;	Wed, 23 Nov 2011 09:40:47 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 23 Nov 2011 17:40:36 +0000
Message-ID: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/3] Migration on QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series introduce migration with QEMU upstream.

A patch series for QEMU will be sent later meant to "fix" the default behavior
of QEMU during save/restore.

There is two new QMP commands implemented:
  - getfd: This give a file descriptor to QEMU through the unix socket.
  - migration: This ask QEMU to save its states in a fd previously sent.

In order to call "getfd", an alternative qmp_send have been implemented in
libxl.

Regards,


Anthony PERARD (3):
  libxl_qmp: Cut qmp_send function.
  libxl_qmp: Command migrate.
  libxl: Introduce migrate with the new QEMU.

 tools/libxl/libxl_dm.c       |    6 +-
 tools/libxl/libxl_dom.c      |   28 +++++++-
 tools/libxl/libxl_internal.h |    2 +
 tools/libxl/libxl_qmp.c      |  161 +++++++++++++++++++++++++++++++++++++----
 4 files changed, 176 insertions(+), 21 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:50:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGxE-0001lb-DH; Wed, 23 Nov 2011 17:49:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTGxC-0001lH-IS
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:49:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322070560!2760462!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7322 invoked from network); 23 Nov 2011 17:49:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:49:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315180800"; 
   d="scan'208";a="9098544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 17:49:20 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 17:49:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "ehiwere.matthew@ieee.org" <ehiwere.matthew@ieee.org>
In-Reply-To: <CAK8ZZBm5UWxk6wvQgQn5tEC7_uTaY671QWNJQjcssDG32+47hw@mail.gmail.com>
References: <CAK8ZZBm5UWxk6wvQgQn5tEC7_uTaY671QWNJQjcssDG32+47hw@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Wed, 23 Nov 2011 17:49:19 +0000
Message-ID: <1322070559.9567.8.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] netconsole failed in getting target on a guest node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 10:54 +0000, ehiwere.matthew@ieee.org wrote:
> When i configure netconsole on my domU,it failed in getting the
> target.

I'm afraid you have not provided enough information for anyone to be
able to help you. e.g. kernel version, settings, command line etc.

http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen may help you in
formulating a bug report.

Ian.

> 
> 
> The following lines show up in /var/log/messages: 
> kernel: [ 1428.983221] netconsole: local port 6665 
> kernel: [ 1428.983227] netconsole: local IP 0.0.0.0 
>  kernel: [ 1428.983230] netconsole: interface eth2 
>  kernel: [ 1428.983234] netconsole: remote port 8008 
>  kernel: [ 1428.983237] netconsole: remote IP XXX.XXX.XX.XX 
>  kernel: [ 1428.983240] netconsole: remote ethernet address
> 00:15:72:3f:0e:5e
>  kernel: [ 1428.983246] netconsole: eth2 doesn't support polling,
> aborting. 
> 
> 
> -- 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 17:50:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 17:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTGxE-0001lb-DH; Wed, 23 Nov 2011 17:49:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTGxC-0001lH-IS
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 17:49:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322070560!2760462!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7322 invoked from network); 23 Nov 2011 17:49:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 17:49:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315180800"; 
   d="scan'208";a="9098544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 17:49:20 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 23 Nov 2011 17:49:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "ehiwere.matthew@ieee.org" <ehiwere.matthew@ieee.org>
In-Reply-To: <CAK8ZZBm5UWxk6wvQgQn5tEC7_uTaY671QWNJQjcssDG32+47hw@mail.gmail.com>
References: <CAK8ZZBm5UWxk6wvQgQn5tEC7_uTaY671QWNJQjcssDG32+47hw@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Wed, 23 Nov 2011 17:49:19 +0000
Message-ID: <1322070559.9567.8.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] netconsole failed in getting target on a guest node
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 10:54 +0000, ehiwere.matthew@ieee.org wrote:
> When i configure netconsole on my domU,it failed in getting the
> target.

I'm afraid you have not provided enough information for anyone to be
able to help you. e.g. kernel version, settings, command line etc.

http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen may help you in
formulating a bug report.

Ian.

> 
> 
> The following lines show up in /var/log/messages: 
> kernel: [ 1428.983221] netconsole: local port 6665 
> kernel: [ 1428.983227] netconsole: local IP 0.0.0.0 
>  kernel: [ 1428.983230] netconsole: interface eth2 
>  kernel: [ 1428.983234] netconsole: remote port 8008 
>  kernel: [ 1428.983237] netconsole: remote IP XXX.XXX.XX.XX 
>  kernel: [ 1428.983240] netconsole: remote ethernet address
> 00:15:72:3f:0e:5e
>  kernel: [ 1428.983246] netconsole: eth2 doesn't support polling,
> aborting. 
> 
> 
> -- 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:07:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHE2-00022r-BV; Wed, 23 Nov 2011 18:07:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTHE0-00022m-9m
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:07:12 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322071601!2770017!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30354 invoked from network); 23 Nov 2011 18:06:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Nov 2011 18:06:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322071601; l=1103;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=+f05p7txDBI+0fk66rytXr8ROK4=;
	b=ZoVN0wK6ahoFlKp4mJuOW2KUTIAJiBDqMraArwm1irLST/Vbq5ybS2C3UW2a1yvuNuX
	n7L6QlSVibf5TuS9VJWevS2b/T4l7oAitMmAWnwoVrBqS0KkjpcgBjRHXktkqnyEpC+VY
	E+NNzqGb+M2Q+Pn1a0qSUljtJr4OTs76ZJI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by post.strato.de (mrclete mo26) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t01f97nANG0agu ;
	Wed, 23 Nov 2011 19:06:32 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E438618637; Wed, 23 Nov 2011 19:06:20 +0100 (CET)
Date: Wed, 23 Nov 2011 19:06:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111123180620.GA26648@aepfle.de>
References: <20111123170017.GC6000@aepfle.de>
	<CAF2DAFB.256EF%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF2DAFB.256EF%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Keir Fraser wrote:

> On 23/11/2011 17:00, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> > On Tue, Nov 22, Keir Fraser wrote:
> > 
> >> We obviously can't have dom0 going to sleep on paging work. This, at least,
> >> isn't a wait-queue bug.
> > 
> > I had to rearrange some code in p2m_mem_paging_populate for my debug
> > stuff. This led to an uninitialized req, and as a result req.flags
> > sometimes had MEM_EVENT_FLAG_VCPU_PAUSED set. For some reason gcc did
> > not catch that..
> > Now waitqueues appear to work ok for me. Thanks!
> 
> Great. However, while eyeballing wait.c I spotted at least two bugs. I'm
> pretty sure that the hypervisor will blow up pretty quickly when you resume
> testing with multiple physical CPUs, for example. I need to create a couple
> of fixup patches which I will then send to you for test.

Good, I will look forward for these fixes.

> By the way, did you test my patch to domain_crash when the stack-save area
> isn't large enough?

I ran into the ->esp == 0 case right away, but I need to retest with a
clean tree.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:07:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHE2-00022r-BV; Wed, 23 Nov 2011 18:07:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTHE0-00022m-9m
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:07:12 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322071601!2770017!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30354 invoked from network); 23 Nov 2011 18:06:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Nov 2011 18:06:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322071601; l=1103;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=+f05p7txDBI+0fk66rytXr8ROK4=;
	b=ZoVN0wK6ahoFlKp4mJuOW2KUTIAJiBDqMraArwm1irLST/Vbq5ybS2C3UW2a1yvuNuX
	n7L6QlSVibf5TuS9VJWevS2b/T4l7oAitMmAWnwoVrBqS0KkjpcgBjRHXktkqnyEpC+VY
	E+NNzqGb+M2Q+Pn1a0qSUljtJr4OTs76ZJI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by post.strato.de (mrclete mo26) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t01f97nANG0agu ;
	Wed, 23 Nov 2011 19:06:32 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E438618637; Wed, 23 Nov 2011 19:06:20 +0100 (CET)
Date: Wed, 23 Nov 2011 19:06:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111123180620.GA26648@aepfle.de>
References: <20111123170017.GC6000@aepfle.de>
	<CAF2DAFB.256EF%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF2DAFB.256EF%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Keir Fraser wrote:

> On 23/11/2011 17:00, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> > On Tue, Nov 22, Keir Fraser wrote:
> > 
> >> We obviously can't have dom0 going to sleep on paging work. This, at least,
> >> isn't a wait-queue bug.
> > 
> > I had to rearrange some code in p2m_mem_paging_populate for my debug
> > stuff. This led to an uninitialized req, and as a result req.flags
> > sometimes had MEM_EVENT_FLAG_VCPU_PAUSED set. For some reason gcc did
> > not catch that..
> > Now waitqueues appear to work ok for me. Thanks!
> 
> Great. However, while eyeballing wait.c I spotted at least two bugs. I'm
> pretty sure that the hypervisor will blow up pretty quickly when you resume
> testing with multiple physical CPUs, for example. I need to create a couple
> of fixup patches which I will then send to you for test.

Good, I will look forward for these fixes.

> By the way, did you test my patch to domain_crash when the stack-save area
> isn't large enough?

I ran into the ->esp == 0 case right away, but I need to retest with a
clean tree.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:19:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHPi-0002OK-12; Wed, 23 Nov 2011 18:19:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTHPg-0002O2-IJ
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:19:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322072326!4347326!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3122 invoked from network); 23 Nov 2011 18:18:46 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 18:18:46 -0000
Received: by bkbzt12 with SMTP id zt12so2561816bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 10:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=loOUpWiI6/ABjYjNSbzFUWFhVdS3eErtTNrUmTyl2Xo=;
	b=qhb/KD4NuEIR/hv5ruHWEXgqTM6hyiznUvH/JfUyzHEagyFnD5IV4OKmdPxmeScQGY
	HTWZP61vgpWY6jrOu6cGk1HD4F/zxg3OtCaTXnuYi5a60+V4XWD8SiImlLf+SbPbe6xD
	vMPGMRRotwM1SdU+xjiNMiSYSbJqBsPI3EfLw=
Received: by 10.205.142.4 with SMTP id jg4mr18908881bkc.119.1322072326007;
	Wed, 23 Nov 2011 10:18:46 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id l5sm10077713bkv.9.2011.11.23.10.18.44
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 10:18:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 18:18:42 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF2E982.34B3A%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqA6u/YPIz4SJrjUuVJSulwM3zTgACKiyE
In-Reply-To: <CAF2DAFB.256EF%keir.xen@gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 17:16, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 23/11/2011 17:00, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
>> On Tue, Nov 22, Keir Fraser wrote:
>> 
>>> We obviously can't have dom0 going to sleep on paging work. This, at least,
>>> isn't a wait-queue bug.
>> 
>> I had to rearrange some code in p2m_mem_paging_populate for my debug
>> stuff. This led to an uninitialized req, and as a result req.flags
>> sometimes had MEM_EVENT_FLAG_VCPU_PAUSED set. For some reason gcc did
>> not catch that..
>> Now waitqueues appear to work ok for me. Thanks!
> 
> Great. However, while eyeballing wait.c I spotted at least two bugs. I'm
> pretty sure that the hypervisor will blow up pretty quickly when you resume
> testing with multiple physical CPUs, for example. I need to create a couple
> of fixup patches which I will then send to you for test.

We have quite a big waitqueue problem actually. The current scheme of
per-cpu stacks doesn't work nicely, as the stack pointer will change if a
vcpu goes to sleep and then wakes up on a different cpu. This really doesn't
work nicely with preempted C code, which may implement frame pointers and/or
arbitrarily take the address of on-stack variables. The result will be
hideous cross-stack corruptions, as these frame pointers and cached
addresses of automatic variables will reference the wrong cpu's stack!
Fixing or detecting this in general is not possible afaics.

So, we'll have to switch to per-vcpu stacks, probably with separate per-cpu
irq stacks (as a later followup). That's quite a nuisance!

 -- Keir

> By the way, did you test my patch to domain_crash when the stack-save area
> isn't large enough?
> 
>> What do you think about C99 initializers in p2m_mem_paging_populate,
>> just to avoid such mistakes?
>> 
>>    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING };
> 
> We like them.
> 
>  -- Keir
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:19:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHPi-0002OK-12; Wed, 23 Nov 2011 18:19:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTHPg-0002O2-IJ
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:19:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322072326!4347326!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3122 invoked from network); 23 Nov 2011 18:18:46 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 18:18:46 -0000
Received: by bkbzt12 with SMTP id zt12so2561816bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 10:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=loOUpWiI6/ABjYjNSbzFUWFhVdS3eErtTNrUmTyl2Xo=;
	b=qhb/KD4NuEIR/hv5ruHWEXgqTM6hyiznUvH/JfUyzHEagyFnD5IV4OKmdPxmeScQGY
	HTWZP61vgpWY6jrOu6cGk1HD4F/zxg3OtCaTXnuYi5a60+V4XWD8SiImlLf+SbPbe6xD
	vMPGMRRotwM1SdU+xjiNMiSYSbJqBsPI3EfLw=
Received: by 10.205.142.4 with SMTP id jg4mr18908881bkc.119.1322072326007;
	Wed, 23 Nov 2011 10:18:46 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id l5sm10077713bkv.9.2011.11.23.10.18.44
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 10:18:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 18:18:42 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF2E982.34B3A%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqA6u/YPIz4SJrjUuVJSulwM3zTgACKiyE
In-Reply-To: <CAF2DAFB.256EF%keir.xen@gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 17:16, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 23/11/2011 17:00, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
>> On Tue, Nov 22, Keir Fraser wrote:
>> 
>>> We obviously can't have dom0 going to sleep on paging work. This, at least,
>>> isn't a wait-queue bug.
>> 
>> I had to rearrange some code in p2m_mem_paging_populate for my debug
>> stuff. This led to an uninitialized req, and as a result req.flags
>> sometimes had MEM_EVENT_FLAG_VCPU_PAUSED set. For some reason gcc did
>> not catch that..
>> Now waitqueues appear to work ok for me. Thanks!
> 
> Great. However, while eyeballing wait.c I spotted at least two bugs. I'm
> pretty sure that the hypervisor will blow up pretty quickly when you resume
> testing with multiple physical CPUs, for example. I need to create a couple
> of fixup patches which I will then send to you for test.

We have quite a big waitqueue problem actually. The current scheme of
per-cpu stacks doesn't work nicely, as the stack pointer will change if a
vcpu goes to sleep and then wakes up on a different cpu. This really doesn't
work nicely with preempted C code, which may implement frame pointers and/or
arbitrarily take the address of on-stack variables. The result will be
hideous cross-stack corruptions, as these frame pointers and cached
addresses of automatic variables will reference the wrong cpu's stack!
Fixing or detecting this in general is not possible afaics.

So, we'll have to switch to per-vcpu stacks, probably with separate per-cpu
irq stacks (as a later followup). That's quite a nuisance!

 -- Keir

> By the way, did you test my patch to domain_crash when the stack-save area
> isn't large enough?
> 
>> What do you think about C99 initializers in p2m_mem_paging_populate,
>> just to avoid such mistakes?
>> 
>>    mem_event_request_t req = { .type = MEM_EVENT_TYPE_PAGING };
> 
> We like them.
> 
>  -- Keir
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:24:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHUs-0002Y5-V9; Wed, 23 Nov 2011 18:24:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTHUr-0002Xu-E4
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:24:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322072647!5464001!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20929 invoked from network); 23 Nov 2011 18:24:07 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 18:24:07 -0000
Received: by fanq24 with SMTP id q24so1741986fan.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 10:24:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=j3jz4gwkjEG2LqlLqspMZn99saymt4YN/k5s6SaZEpI=;
	b=H8yQY833HnG/mWCb8UGOZAnfbeFqk2su0uA6z4VEXlT8hh9aDlCZEsFFMRHxUxcb6h
	ktTeAWP7+H0PWDjXjloWxeqpAHRyyCgIvopYfa9QtzxrHQDMLEGrsfj+MufVFi7HTrbP
	MtR4crhRqjrJrNQwrWfwPs4++CH6F5MZX1BBA=
Received: by 10.204.136.200 with SMTP id s8mr24985178bkt.49.1322072646362;
	Wed, 23 Nov 2011 10:24:06 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id c4sm13562064bkk.13.2011.11.23.10.24.04
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 10:24:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 18:23:56 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF2EABC.34B3B%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqDQ+aUPhC5IAn10agUiQsADt+og==
In-Reply-To: <20111123180620.GA26648@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 18:06, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Wed, Nov 23, Keir Fraser wrote:
> 
>> On 23/11/2011 17:00, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>>> On Tue, Nov 22, Keir Fraser wrote:
>>> 
>>>> We obviously can't have dom0 going to sleep on paging work. This, at least,
>>>> isn't a wait-queue bug.
>>> 
>>> I had to rearrange some code in p2m_mem_paging_populate for my debug
>>> stuff. This led to an uninitialized req, and as a result req.flags
>>> sometimes had MEM_EVENT_FLAG_VCPU_PAUSED set. For some reason gcc did
>>> not catch that..
>>> Now waitqueues appear to work ok for me. Thanks!
>> 
>> Great. However, while eyeballing wait.c I spotted at least two bugs. I'm
>> pretty sure that the hypervisor will blow up pretty quickly when you resume
>> testing with multiple physical CPUs, for example. I need to create a couple
>> of fixup patches which I will then send to you for test.
> 
> Good, I will look forward for these fixes.
> 
>> By the way, did you test my patch to domain_crash when the stack-save area
>> isn't large enough?
> 
> I ran into the ->esp == 0 case right away, but I need to retest with a
> clean tree.

I think I have a test the wrong way round. This doesn't really matter now
anyway. As I say in my previous email, stack management will have to be
redone for waitqueues.

 -- Keir

> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:24:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:24:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHUs-0002Y5-V9; Wed, 23 Nov 2011 18:24:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTHUr-0002Xu-E4
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:24:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322072647!5464001!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20929 invoked from network); 23 Nov 2011 18:24:07 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 18:24:07 -0000
Received: by fanq24 with SMTP id q24so1741986fan.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 10:24:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=j3jz4gwkjEG2LqlLqspMZn99saymt4YN/k5s6SaZEpI=;
	b=H8yQY833HnG/mWCb8UGOZAnfbeFqk2su0uA6z4VEXlT8hh9aDlCZEsFFMRHxUxcb6h
	ktTeAWP7+H0PWDjXjloWxeqpAHRyyCgIvopYfa9QtzxrHQDMLEGrsfj+MufVFi7HTrbP
	MtR4crhRqjrJrNQwrWfwPs4++CH6F5MZX1BBA=
Received: by 10.204.136.200 with SMTP id s8mr24985178bkt.49.1322072646362;
	Wed, 23 Nov 2011 10:24:06 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id c4sm13562064bkk.13.2011.11.23.10.24.04
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 10:24:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 18:23:56 +0000
From: Keir Fraser <keir@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF2EABC.34B3B%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqDQ+aUPhC5IAn10agUiQsADt+og==
In-Reply-To: <20111123180620.GA26648@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 18:06, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Wed, Nov 23, Keir Fraser wrote:
> 
>> On 23/11/2011 17:00, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>>> On Tue, Nov 22, Keir Fraser wrote:
>>> 
>>>> We obviously can't have dom0 going to sleep on paging work. This, at least,
>>>> isn't a wait-queue bug.
>>> 
>>> I had to rearrange some code in p2m_mem_paging_populate for my debug
>>> stuff. This led to an uninitialized req, and as a result req.flags
>>> sometimes had MEM_EVENT_FLAG_VCPU_PAUSED set. For some reason gcc did
>>> not catch that..
>>> Now waitqueues appear to work ok for me. Thanks!
>> 
>> Great. However, while eyeballing wait.c I spotted at least two bugs. I'm
>> pretty sure that the hypervisor will blow up pretty quickly when you resume
>> testing with multiple physical CPUs, for example. I need to create a couple
>> of fixup patches which I will then send to you for test.
> 
> Good, I will look forward for these fixes.
> 
>> By the way, did you test my patch to domain_crash when the stack-save area
>> isn't large enough?
> 
> I ran into the ->esp == 0 case right away, but I need to retest with a
> clean tree.

I think I have a test the wrong way round. This doesn't really matter now
anyway. As I say in my previous email, stack management will have to be
redone for waitqueues.

 -- Keir

> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:25:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:25:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHUy-0002YT-C0; Wed, 23 Nov 2011 18:24:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTHUw-0002Xy-G3
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:24:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322072651!2760095!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8251 invoked from network); 23 Nov 2011 18:24:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Nov 2011 18:24:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322072651; l=960;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=SpTzgd9MW2qKaqnHO4v/pnULlis=;
	b=LEtpglNpYehWt4qHGKVGoQaXsD/DYBMPOaXWNYQSUiq2jele6bQod+Vnz7xZXiHFaYt
	Wt5QvdNR8bwo80P+XZebiQW5MdZlkdsz+ha9xcmxcUdmaq8so90n0Zz6ngDPeByV5FD8d
	Hg054yCdfD1aiiUJtxIFRtY7Yw7XkAkLhzQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by post.strato.de (mrclete mo28) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 302080nANIHPJi ;
	Wed, 23 Nov 2011 19:23:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 68F8E18637; Wed, 23 Nov 2011 19:23:57 +0100 (CET)
Date: Wed, 23 Nov 2011 19:23:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111123182357.GB26648@aepfle.de>
References: <20111123164918.GB6000@aepfle.de>
	<CAF2DB24.256F1%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF2DB24.256F1%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridncetric.ca
Subject: Re: [Xen-devel] RFC: mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Keir Fraser wrote:

> On 23/11/2011 16:49, "Olaf Hering" <olaf@aepfle.de> wrote:
> > I'm not proposing to include my patch as is, because it has one issue:
> > wake_up will start all waiting vcpus even if there is just a single slot
> > free in the ringbuffer. You patch is better in this respect because only
> > a few will be started again.
> 
> Do you need a wake_up_one() function?

I'm not sure.

In case of paging, if gfn 1234 is missing, several vcpus may wait for it
to come back. Other vcpus may wait for other gfns. So if we had a struct
waitqueue_head for gfn 1234, and other individual gfns, that would help
for this case.
Since there cant be more gfns to wait for than the available guest
vcpus, a list of waitqueue_head's with a gfn attached to it would work.

If that sounds to crazy, or if I'm on the wrong track, how would you do that?
(Perhaps I should prepare a patch to demonstrate what I mean.)

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:25:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:25:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHUy-0002YT-C0; Wed, 23 Nov 2011 18:24:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTHUw-0002Xy-G3
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:24:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322072651!2760095!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8251 invoked from network); 23 Nov 2011 18:24:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Nov 2011 18:24:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322072651; l=960;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=SpTzgd9MW2qKaqnHO4v/pnULlis=;
	b=LEtpglNpYehWt4qHGKVGoQaXsD/DYBMPOaXWNYQSUiq2jele6bQod+Vnz7xZXiHFaYt
	Wt5QvdNR8bwo80P+XZebiQW5MdZlkdsz+ha9xcmxcUdmaq8so90n0Zz6ngDPeByV5FD8d
	Hg054yCdfD1aiiUJtxIFRtY7Yw7XkAkLhzQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by post.strato.de (mrclete mo28) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 302080nANIHPJi ;
	Wed, 23 Nov 2011 19:23:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 68F8E18637; Wed, 23 Nov 2011 19:23:57 +0100 (CET)
Date: Wed, 23 Nov 2011 19:23:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111123182357.GB26648@aepfle.de>
References: <20111123164918.GB6000@aepfle.de>
	<CAF2DB24.256F1%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF2DB24.256F1%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridncetric.ca
Subject: Re: [Xen-devel] RFC: mem_event: use wait queue when ring is full
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Keir Fraser wrote:

> On 23/11/2011 16:49, "Olaf Hering" <olaf@aepfle.de> wrote:
> > I'm not proposing to include my patch as is, because it has one issue:
> > wake_up will start all waiting vcpus even if there is just a single slot
> > free in the ringbuffer. You patch is better in this respect because only
> > a few will be started again.
> 
> Do you need a wake_up_one() function?

I'm not sure.

In case of paging, if gfn 1234 is missing, several vcpus may wait for it
to come back. Other vcpus may wait for other gfns. So if we had a struct
waitqueue_head for gfn 1234, and other individual gfns, that would help
for this case.
Since there cant be more gfns to wait for than the available guest
vcpus, a list of waitqueue_head's with a gfn attached to it would work.

If that sounds to crazy, or if I'm on the wrong track, how would you do that?
(Perhaps I should prepare a patch to demonstrate what I mean.)

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:26:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHW8-0002fT-SW; Wed, 23 Nov 2011 18:25:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTHW7-0002fF-VC
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:25:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322072702!49670691!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20434 invoked from network); 23 Nov 2011 18:25:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 18:25:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315180800"; 
   d="scan'208";a="9099018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 18:25:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 18:25:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTHVi-0006uK-7h;
	Wed, 23 Nov 2011 18:25:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTHVi-0008RF-78;
	Wed, 23 Nov 2011 18:25:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10016-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 18:25:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10016: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10016 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10016/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  84b3e46aa7d2
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24187:84b3e46aa7d2
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 23 12:03:37 2011 +0000
    
    libxl: Prevent xl save from segfaulting when control/shutdown key is removed
    
    To acknowledge the tools' setting of control/shutdown it is normal for
    PV drivers to rm the key. This leads to libxl__xs_read() returning
    NULL and thus a subsequent strcmp on the return value will cause a
    segfault.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24186:7aa5838499d1
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 23 11:15:31 2011 +0000
    
    tools: use system libaio for blktap1 as well.
    
    24184:4ecd3615e726 missed this because I was accidentally testing with a
    .config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
    without this. There were no other issues.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24185:f88c745575bb
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 18:51:13 2011 +0000
    
    docs: remove some fatally out of date documentation
    
    I think these are better off deleted than remaining to confuse people.
    
    docs/misc/blkif-drivers-explained.txt:
    
     - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.
    
    docs/misc/cpuid-config-for-guest.txt:
    
     - Doesn't really say anything, in particular doesn't actually describe how to
       configure CPUID.
    
    docs/misc/hg-cheatsheet.txt:
    
     - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
       under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
       hardly unusual anymore I think there must be better guides out there so this
       one is not worth resurecting.
    
    docs/misc/network_setup.txt:
    
     - This is more comprehensively documented on the wiki these days.
    
    docs/misc/VMX_changes.txt:
    
     - Is basically a changelog from the initial implementation of VMX in 2004.
    
    I'm not sure about some of the other docs, but these ones seemed fairly
    obvious.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24184:4ecd3615e726
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:26:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHW8-0002fT-SW; Wed, 23 Nov 2011 18:25:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTHW7-0002fF-VC
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:25:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322072702!49670691!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20434 invoked from network); 23 Nov 2011 18:25:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 18:25:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,560,1315180800"; 
   d="scan'208";a="9099018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 18:25:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 18:25:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTHVi-0006uK-7h;
	Wed, 23 Nov 2011 18:25:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTHVi-0008RF-78;
	Wed, 23 Nov 2011 18:25:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10016-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 18:25:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10016: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10016 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10016/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  84b3e46aa7d2
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24187:84b3e46aa7d2
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 23 12:03:37 2011 +0000
    
    libxl: Prevent xl save from segfaulting when control/shutdown key is removed
    
    To acknowledge the tools' setting of control/shutdown it is normal for
    PV drivers to rm the key. This leads to libxl__xs_read() returning
    NULL and thus a subsequent strcmp on the return value will cause a
    segfault.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24186:7aa5838499d1
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 23 11:15:31 2011 +0000
    
    tools: use system libaio for blktap1 as well.
    
    24184:4ecd3615e726 missed this because I was accidentally testing with a
    .config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
    without this. There were no other issues.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24185:f88c745575bb
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 18:51:13 2011 +0000
    
    docs: remove some fatally out of date documentation
    
    I think these are better off deleted than remaining to confuse people.
    
    docs/misc/blkif-drivers-explained.txt:
    
     - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.
    
    docs/misc/cpuid-config-for-guest.txt:
    
     - Doesn't really say anything, in particular doesn't actually describe how to
       configure CPUID.
    
    docs/misc/hg-cheatsheet.txt:
    
     - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
       under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
       hardly unusual anymore I think there must be better guides out there so this
       one is not worth resurecting.
    
    docs/misc/network_setup.txt:
    
     - This is more comprehensively documented on the wiki these days.
    
    docs/misc/VMX_changes.txt:
    
     - Is basically a changelog from the initial implementation of VMX in 2004.
    
    I'm not sure about some of the other docs, but these ones seemed fairly
    obvious.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24184:4ecd3615e726
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:26:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHWN-0002h8-BV; Wed, 23 Nov 2011 18:26:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RTHWM-0002gK-B2
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:26:10 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322072738!4667263!1
X-Originating-IP: [209.85.212.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6508 invoked from network); 23 Nov 2011 18:25:39 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 18:25:39 -0000
Received: by vbbfq11 with SMTP id fq11so1850312vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 10:25:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=Nme0tg9iYaGzObgonQLVPGwmHbWo4c1QxQAqxdB3IBs=;
	b=jwYY/R3EJLxsYHpLi7kksqSPFc1iXPysMVyiGyW/94PDgzhfQ6I3iEIZADRVV0hxlx
	s5ZwWPg5KxueLwrpXra1SgxCyf69i2TtDi1XKkLCTLudctGVz3hoOZeqvxH+GNpyeyn0
	l6PSO+Ah3IRQzLxSFExGigLzdGeMwPH89XClw=
Received: by 10.182.7.66 with SMTP id h2mr8662146oba.14.1322072738190; Wed, 23
	Nov 2011 10:25:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.37.225 with HTTP; Wed, 23 Nov 2011 10:25:07 -0800 (PST)
In-Reply-To: <20111118150622.GB17708@phenom.dumpdata.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
	<1321543033-22090-6-git-send-email-anthony.perard@citrix.com>
	<20111118150622.GB17708@phenom.dumpdata.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Wed, 23 Nov 2011 18:25:07 +0000
X-Google-Sender-Auth: VtKJ_5NyvGSBkYFN9i6emvjqVwc
Message-ID: <CAJJyHjKLCet1-5bnSKxXUL7Ypq9TzBffL_5qa7dD0yStNPNp5w@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V4 05/10] Introduce
 HostPCIDevice to access a pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBOb3YgMTgsIDIwMTEgYXQgMTU6MDYsIEtvbnJhZCBSemVzenV0ZWsgV2lsawo8a29u
cmFkLndpbGtAb3JhY2xlLmNvbT4gd3JvdGU6Cj4+ICtzdGF0aWMgaW50IGhvc3RfcGNpX2NvbmZp
Z19yZWFkKEhvc3RQQ0lEZXZpY2UgKmQsIGludCBwb3MsIHZvaWQgKmJ1ZiwgaW50IGxlbikKPj4g
K3sKPj4gKyDCoCDCoGludCBmZCA9IGhvc3RfcGNpX2NvbmZpZ19mZChkKTsKPj4gKyDCoCDCoGlu
dCByZXMgPSAwOwo+PiArCj4+ICthZ2FpbjoKPj4gKyDCoCDCoHJlcyA9IHByZWFkKGZkLCBidWYs
IGxlbiwgcG9zKTsKPj4gKyDCoCDCoGlmIChyZXMgIT0gbGVuKSB7Cj4+ICsgwqAgwqAgwqAgwqBp
ZiAocmVzIDwgMCAmJiAoZXJybm8gPT0gRUlOVFIgfHwgZXJybm8gPT0gRUFHQUlOKSkgewo+PiAr
IMKgIMKgIMKgIMKgIMKgIMKgZ290byBhZ2FpbjsKPj4gKyDCoCDCoCDCoCDCoH0KPj4gKyDCoCDC
oCDCoCDCoGZwcmludGYoc3RkZXJyLCAiaG9zdF9wY2lfY29uZmlnOiByZWFkIGZhaWxlZDogJXMg
KGZkOiAlaSlcbiIsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzdHJlcnJvcihlcnJubyks
IGZkKTsKPj4gKyDCoCDCoCDCoCDCoHJldHVybiAtZXJybm87Cj4+ICsgwqAgwqB9Cj4+ICsgwqAg
wqByZXR1cm4gMDsKPj4gK30KPj4gK3N0YXRpYyBpbnQgaG9zdF9wY2lfY29uZmlnX3dyaXRlKEhv
c3RQQ0lEZXZpY2UgKmQsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgaW50IHBvcywgY29uc3Qgdm9pZCAqYnVmLCBpbnQgbGVuKQo+PiArewo+PiAr
IMKgIMKgaW50IGZkID0gaG9zdF9wY2lfY29uZmlnX2ZkKGQpOwo+PiArIMKgIMKgaW50IHJlcyA9
IDA7Cj4+ICsKPj4gK2FnYWluOgo+PiArIMKgIMKgcmVzID0gcHdyaXRlKGZkLCBidWYsIGxlbiwg
cG9zKTsKPj4gKyDCoCDCoGlmIChyZXMgIT0gbGVuKSB7Cj4+ICsgwqAgwqAgwqAgwqBpZiAocmVz
IDwgMCAmJiAoZXJybm8gPT0gRUlOVFIgfHwgZXJybm8gPT0gRUFHQUlOKSkgewo+PiArIMKgIMKg
IMKgIMKgIMKgIMKgZ290byBhZ2FpbjsKPj4gKyDCoCDCoCDCoCDCoH0KPj4gKyDCoCDCoCDCoCDC
oGZwcmludGYoc3RkZXJyLCAiaG9zdF9wY2lfY29uZmlnOiB3cml0ZSBmYWlsZWQ6ICVzXG4iLAo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc3RyZXJyb3IoZXJybm8pKTsKPj4gKyDCoCDCoCDC
oCDCoHJldHVybiAtZXJybm87Cj4+ICsgwqAgwqB9Cj4+ICsgwqAgwqByZXR1cm4gMDsKPj4gK30K
Pj4gKwo+PiAraW50IGhvc3RfcGNpX2dldF9ieXRlKEhvc3RQQ0lEZXZpY2UgKmQsIGludCBwb3Ms
IHVpbnQ4X3QgKnApCj4+ICt7Cj4+ICsgwqB1aW50OF90IGJ1ZjsKPj4gKyDCoGlmIChob3N0X3Bj
aV9jb25maWdfcmVhZChkLCBwb3MsICZidWYsIDEpKSB7Cj4+ICsgwqAgwqAgwqByZXR1cm4gLTE7
Cj4KPiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIHVzZSB0aGUgbmljZSBlbnVtIHlvdSBkZWNsZXJh
ZWQgYXQgdGhlCj4gdG9wIG9mIHRoZSBmaWxlPyDCoE9yIG5vdD8KCkkgc2hvdWxkIHByb2JhYmx5
IHJldHVybiAtZXJybm8gaW5zdGVhZCwgSSBtZWFuIHRoZSByZXR1cm4gdmFsdWUgb2YKaG9zdF9w
Y2lfY29uZmlnX3JlYWQvd3JpdGUuCgpJIGp1c3QgaW50cm9kdWNlIHRoZSBlbnVtIHRvIGhhdmUg
YSBkaWZmZXJlbnRlIHZhbHVlIHRoYW4gLWVycm5vIGZvcgpzb21lIGludGVybmFsIGZ1bmN0aW9u
IChnZXRfcmVzc291cmNlL2dldF9oZXhfdmFsdWUpLCBzbyBJIGRvbid0IHRoaW5rCnRoYXQgdGhl
IGVudW0gY2FuIHJlYWxseSBieSB1c2VkIG91dHNpZGUgb2YgdGhpcyBmaWxlLCB5ZXQuCgooSSB3
aWxsIGNoYW5nZSB0aGUgcmVzdCBvZiB0aGUgcGF0Y2ggYXMgeW91IHN1Z2VzdCBpbiB5b3VyIGNv
bW1lbnQpCgpUaGFua3MsCgotLSAKQW50aG9ueSBQRVJBUkQKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:26:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHWN-0002h8-BV; Wed, 23 Nov 2011 18:26:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RTHWM-0002gK-B2
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:26:10 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322072738!4667263!1
X-Originating-IP: [209.85.212.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6508 invoked from network); 23 Nov 2011 18:25:39 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 18:25:39 -0000
Received: by vbbfq11 with SMTP id fq11so1850312vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 10:25:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=Nme0tg9iYaGzObgonQLVPGwmHbWo4c1QxQAqxdB3IBs=;
	b=jwYY/R3EJLxsYHpLi7kksqSPFc1iXPysMVyiGyW/94PDgzhfQ6I3iEIZADRVV0hxlx
	s5ZwWPg5KxueLwrpXra1SgxCyf69i2TtDi1XKkLCTLudctGVz3hoOZeqvxH+GNpyeyn0
	l6PSO+Ah3IRQzLxSFExGigLzdGeMwPH89XClw=
Received: by 10.182.7.66 with SMTP id h2mr8662146oba.14.1322072738190; Wed, 23
	Nov 2011 10:25:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.37.225 with HTTP; Wed, 23 Nov 2011 10:25:07 -0800 (PST)
In-Reply-To: <20111118150622.GB17708@phenom.dumpdata.com>
References: <1321543033-22090-1-git-send-email-anthony.perard@citrix.com>
	<1321543033-22090-6-git-send-email-anthony.perard@citrix.com>
	<20111118150622.GB17708@phenom.dumpdata.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Wed, 23 Nov 2011 18:25:07 +0000
X-Google-Sender-Auth: VtKJ_5NyvGSBkYFN9i6emvjqVwc
Message-ID: <CAJJyHjKLCet1-5bnSKxXUL7Ypq9TzBffL_5qa7dD0yStNPNp5w@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V4 05/10] Introduce
 HostPCIDevice to access a pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBOb3YgMTgsIDIwMTEgYXQgMTU6MDYsIEtvbnJhZCBSemVzenV0ZWsgV2lsawo8a29u
cmFkLndpbGtAb3JhY2xlLmNvbT4gd3JvdGU6Cj4+ICtzdGF0aWMgaW50IGhvc3RfcGNpX2NvbmZp
Z19yZWFkKEhvc3RQQ0lEZXZpY2UgKmQsIGludCBwb3MsIHZvaWQgKmJ1ZiwgaW50IGxlbikKPj4g
K3sKPj4gKyDCoCDCoGludCBmZCA9IGhvc3RfcGNpX2NvbmZpZ19mZChkKTsKPj4gKyDCoCDCoGlu
dCByZXMgPSAwOwo+PiArCj4+ICthZ2FpbjoKPj4gKyDCoCDCoHJlcyA9IHByZWFkKGZkLCBidWYs
IGxlbiwgcG9zKTsKPj4gKyDCoCDCoGlmIChyZXMgIT0gbGVuKSB7Cj4+ICsgwqAgwqAgwqAgwqBp
ZiAocmVzIDwgMCAmJiAoZXJybm8gPT0gRUlOVFIgfHwgZXJybm8gPT0gRUFHQUlOKSkgewo+PiAr
IMKgIMKgIMKgIMKgIMKgIMKgZ290byBhZ2FpbjsKPj4gKyDCoCDCoCDCoCDCoH0KPj4gKyDCoCDC
oCDCoCDCoGZwcmludGYoc3RkZXJyLCAiaG9zdF9wY2lfY29uZmlnOiByZWFkIGZhaWxlZDogJXMg
KGZkOiAlaSlcbiIsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzdHJlcnJvcihlcnJubyks
IGZkKTsKPj4gKyDCoCDCoCDCoCDCoHJldHVybiAtZXJybm87Cj4+ICsgwqAgwqB9Cj4+ICsgwqAg
wqByZXR1cm4gMDsKPj4gK30KPj4gK3N0YXRpYyBpbnQgaG9zdF9wY2lfY29uZmlnX3dyaXRlKEhv
c3RQQ0lEZXZpY2UgKmQsCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgaW50IHBvcywgY29uc3Qgdm9pZCAqYnVmLCBpbnQgbGVuKQo+PiArewo+PiAr
IMKgIMKgaW50IGZkID0gaG9zdF9wY2lfY29uZmlnX2ZkKGQpOwo+PiArIMKgIMKgaW50IHJlcyA9
IDA7Cj4+ICsKPj4gK2FnYWluOgo+PiArIMKgIMKgcmVzID0gcHdyaXRlKGZkLCBidWYsIGxlbiwg
cG9zKTsKPj4gKyDCoCDCoGlmIChyZXMgIT0gbGVuKSB7Cj4+ICsgwqAgwqAgwqAgwqBpZiAocmVz
IDwgMCAmJiAoZXJybm8gPT0gRUlOVFIgfHwgZXJybm8gPT0gRUFHQUlOKSkgewo+PiArIMKgIMKg
IMKgIMKgIMKgIMKgZ290byBhZ2FpbjsKPj4gKyDCoCDCoCDCoCDCoH0KPj4gKyDCoCDCoCDCoCDC
oGZwcmludGYoc3RkZXJyLCAiaG9zdF9wY2lfY29uZmlnOiB3cml0ZSBmYWlsZWQ6ICVzXG4iLAo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgc3RyZXJyb3IoZXJybm8pKTsKPj4gKyDCoCDCoCDC
oCDCoHJldHVybiAtZXJybm87Cj4+ICsgwqAgwqB9Cj4+ICsgwqAgwqByZXR1cm4gMDsKPj4gK30K
Pj4gKwo+PiAraW50IGhvc3RfcGNpX2dldF9ieXRlKEhvc3RQQ0lEZXZpY2UgKmQsIGludCBwb3Ms
IHVpbnQ4X3QgKnApCj4+ICt7Cj4+ICsgwqB1aW50OF90IGJ1ZjsKPj4gKyDCoGlmIChob3N0X3Bj
aV9jb25maWdfcmVhZChkLCBwb3MsICZidWYsIDEpKSB7Cj4+ICsgwqAgwqAgwqByZXR1cm4gLTE7
Cj4KPiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIHVzZSB0aGUgbmljZSBlbnVtIHlvdSBkZWNsZXJh
ZWQgYXQgdGhlCj4gdG9wIG9mIHRoZSBmaWxlPyDCoE9yIG5vdD8KCkkgc2hvdWxkIHByb2JhYmx5
IHJldHVybiAtZXJybm8gaW5zdGVhZCwgSSBtZWFuIHRoZSByZXR1cm4gdmFsdWUgb2YKaG9zdF9w
Y2lfY29uZmlnX3JlYWQvd3JpdGUuCgpJIGp1c3QgaW50cm9kdWNlIHRoZSBlbnVtIHRvIGhhdmUg
YSBkaWZmZXJlbnRlIHZhbHVlIHRoYW4gLWVycm5vIGZvcgpzb21lIGludGVybmFsIGZ1bmN0aW9u
IChnZXRfcmVzc291cmNlL2dldF9oZXhfdmFsdWUpLCBzbyBJIGRvbid0IHRoaW5rCnRoYXQgdGhl
IGVudW0gY2FuIHJlYWxseSBieSB1c2VkIG91dHNpZGUgb2YgdGhpcyBmaWxlLCB5ZXQuCgooSSB3
aWxsIGNoYW5nZSB0aGUgcmVzdCBvZiB0aGUgcGF0Y2ggYXMgeW91IHN1Z2VzdCBpbiB5b3VyIGNv
bW1lbnQpCgpUaGFua3MsCgotLSAKQW50aG9ueSBQRVJBUkQKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:33:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:33:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHcn-0003H9-EM; Wed, 23 Nov 2011 18:32:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTHcm-0003Gk-4U
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:32:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322073137!4337227!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 637 invoked from network); 23 Nov 2011 18:32:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Nov 2011 18:32:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322073137; l=801;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=qA1bVNhvSdrwJJTo3GpBb5xlozk=;
	b=cNX7ZTjvXn/OOoQPsNt4tEjq2cthuKRmg871QocD3bcsYiogA1k1yJ8T304C9KSjtM/
	0zX5DbzekNAqXytsZtEf7sAwsyACrqgvAuEQzyDwb+TS/qzllQ0d4x8MXKy+l78u3H4VM
	fNadnymoyVizIbMhSY8pleI2rLreGB+3/iI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (klopstock mo24) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id v04383nANIGOir ;
	Wed, 23 Nov 2011 19:31:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 0F8AA18637; Wed, 23 Nov 2011 19:31:48 +0100 (CET)
Date: Wed, 23 Nov 2011 19:31:48 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir@xen.org>
Message-ID: <20111123183148.GA26869@aepfle.de>
References: <CAF2DAFB.256EF%keir.xen@gmail.com> <CAF2E982.34B3A%keir@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF2E982.34B3A%keir@xen.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Keir Fraser wrote:

> We have quite a big waitqueue problem actually. The current scheme of
> per-cpu stacks doesn't work nicely, as the stack pointer will change if a
> vcpu goes to sleep and then wakes up on a different cpu. This really doesn't
> work nicely with preempted C code, which may implement frame pointers and/or
> arbitrarily take the address of on-stack variables. The result will be
> hideous cross-stack corruptions, as these frame pointers and cached
> addresses of automatic variables will reference the wrong cpu's stack!
> Fixing or detecting this in general is not possible afaics.

Yes, I was thinking about that wakeup on different cpu as well.
As a quick fix/hack, perhaps the scheduler could make sure the vcpu
wakes up on the same cpu?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:33:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:33:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHcn-0003H9-EM; Wed, 23 Nov 2011 18:32:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTHcm-0003Gk-4U
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:32:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322073137!4337227!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 637 invoked from network); 23 Nov 2011 18:32:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Nov 2011 18:32:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322073137; l=801;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=qA1bVNhvSdrwJJTo3GpBb5xlozk=;
	b=cNX7ZTjvXn/OOoQPsNt4tEjq2cthuKRmg871QocD3bcsYiogA1k1yJ8T304C9KSjtM/
	0zX5DbzekNAqXytsZtEf7sAwsyACrqgvAuEQzyDwb+TS/qzllQ0d4x8MXKy+l78u3H4VM
	fNadnymoyVizIbMhSY8pleI2rLreGB+3/iI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (klopstock mo24) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id v04383nANIGOir ;
	Wed, 23 Nov 2011 19:31:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 0F8AA18637; Wed, 23 Nov 2011 19:31:48 +0100 (CET)
Date: Wed, 23 Nov 2011 19:31:48 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir@xen.org>
Message-ID: <20111123183148.GA26869@aepfle.de>
References: <CAF2DAFB.256EF%keir.xen@gmail.com> <CAF2E982.34B3A%keir@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF2E982.34B3A%keir@xen.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Keir Fraser wrote:

> We have quite a big waitqueue problem actually. The current scheme of
> per-cpu stacks doesn't work nicely, as the stack pointer will change if a
> vcpu goes to sleep and then wakes up on a different cpu. This really doesn't
> work nicely with preempted C code, which may implement frame pointers and/or
> arbitrarily take the address of on-stack variables. The result will be
> hideous cross-stack corruptions, as these frame pointers and cached
> addresses of automatic variables will reference the wrong cpu's stack!
> Fixing or detecting this in general is not possible afaics.

Yes, I was thinking about that wakeup on different cpu as well.
As a quick fix/hack, perhaps the scheduler could make sure the vcpu
wakes up on the same cpu?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:36:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:36:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHfr-0003aH-2i; Wed, 23 Nov 2011 18:35:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTHfp-0003a6-T2
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:35:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322073289!58007163!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2956 invoked from network); 23 Nov 2011 18:34:49 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 18:34:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322073332; l=796;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=GMZsx3MxrQTiz2I5cgON/v2pLcU=;
	b=A4jZGXoGZTvzzX7p9uEJSywyuRFQxQA85AoWo83QNo9CkGButXLeK2ypEljpD+XCLPB
	yOG0NdT+pUTHeP3IaHGOFG1mwiHqKpETz7l7Tb1+hZk66R54RJAO0rIX9qbroDpFuZLJZ
	uVe5B5cW4Ht/6N5SnG5gg8VGc/PgjQqB27s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (jimi mo13) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y03710nANFqCk4 ;
	Wed, 23 Nov 2011 19:35:16 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C44C218637; Wed, 23 Nov 2011 19:35:11 +0100 (CET)
Date: Wed, 23 Nov 2011 19:35:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111123183511.GA26144@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 14, Andres Lagar-Cavilla wrote:

I will do a more complete review later, a few comments below.


> +    free_requests = RING_FREE_REQUESTS(&med->front_ring);
> +    if ( unlikely(free_requests < d->max_vcpus) )
> +    {
> +        /* This may happen during normal operation (hopefully not often). */
> +        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d: %d\n",
> +                               d->domain_id, free_requests);

What is the purpose of this printk? The ring can and does fillup quickly
with paging.


> +    if ( mem_event_ring_free(d, med) == 0 )
> +    {
> +        /* This *may* happen, but only when foreign mappings generate events. */
> +        gdprintk(XENLOG_WARNING, "possible lost mem_event for domain %d\n",
> +                                 d->domain_id);

This printk is not needed, callers have to try again.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:36:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:36:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHfr-0003aH-2i; Wed, 23 Nov 2011 18:35:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTHfp-0003a6-T2
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:35:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322073289!58007163!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2956 invoked from network); 23 Nov 2011 18:34:49 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 18:34:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322073332; l=796;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=GMZsx3MxrQTiz2I5cgON/v2pLcU=;
	b=A4jZGXoGZTvzzX7p9uEJSywyuRFQxQA85AoWo83QNo9CkGButXLeK2ypEljpD+XCLPB
	yOG0NdT+pUTHeP3IaHGOFG1mwiHqKpETz7l7Tb1+hZk66R54RJAO0rIX9qbroDpFuZLJZ
	uVe5B5cW4Ht/6N5SnG5gg8VGc/PgjQqB27s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (jimi mo13) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id y03710nANFqCk4 ;
	Wed, 23 Nov 2011 19:35:16 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C44C218637; Wed, 23 Nov 2011 19:35:11 +0100 (CET)
Date: Wed, 23 Nov 2011 19:35:11 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111123183511.GA26144@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 14, Andres Lagar-Cavilla wrote:

I will do a more complete review later, a few comments below.


> +    free_requests = RING_FREE_REQUESTS(&med->front_ring);
> +    if ( unlikely(free_requests < d->max_vcpus) )
> +    {
> +        /* This may happen during normal operation (hopefully not often). */
> +        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d: %d\n",
> +                               d->domain_id, free_requests);

What is the purpose of this printk? The ring can and does fillup quickly
with paging.


> +    if ( mem_event_ring_free(d, med) == 0 )
> +    {
> +        /* This *may* happen, but only when foreign mappings generate events. */
> +        gdprintk(XENLOG_WARNING, "possible lost mem_event for domain %d\n",
> +                                 d->domain_id);

This printk is not needed, callers have to try again.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:53:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:53:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHwf-0004ez-M2; Wed, 23 Nov 2011 18:53:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTHwd-0004eT-U5
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:53:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322074368!4689750!1
X-Originating-IP: [208.97.132.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 779 invoked from network); 23 Nov 2011 18:52:49 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.81) by server-16.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 18:52:49 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 8F2E71A8069;
	Wed, 23 Nov 2011 10:52:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LmZzxgkmEqCE/0tj9Xr0vyvPS/Minx++9TK9woKsWT9c
	YpAoZCbJE4ftKkJStqI3e8OblhT2gRrx6XPl/boiuHwy5oBQvlNE7fcgdFMZbr/A
	ECNpebl37OAdXnR2qGze9RUAj+R1P+0xDE7rh18EdbKYCfxsIL2tKQPhc3O71DA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=0d850PJHmA0e4G1qMoDPQktMr5s=; b=tiPIeEi7
	G3Z/d02GTPgeesnME1zAZkL+9t6lX2rjYA3UnnjDfUUBbhub2n73rU11Ilbfbv2D
	qssygL3WZcai5yZ9LpCtkehAKACciv91vBNeu0+u6TTLuPUUpjFQB51USznfo3ny
	oCG++0847z7HBRO3sLHWm87Q/n8o9lXdI+Q=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id EF34C1A8061; 
	Wed, 23 Nov 2011 10:52:47 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 23 Nov 2011 10:52:48 -0800
Message-ID: <d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111123183511.GA26144@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
	<20111123183511.GA26144@aepfle.de>
Date: Wed, 23 Nov 2011 10:52:48 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf,
> On Mon, Nov 14, Andres Lagar-Cavilla wrote:
>
> I will do a more complete review later, a few comments below.
>
>
>> +    free_requests = RING_FREE_REQUESTS(&med->front_ring);
>> +    if ( unlikely(free_requests < d->max_vcpus) )
>> +    {
>> +        /* This may happen during normal operation (hopefully not
>> often). */
>> +        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d:
>> %d\n",
>> +                               d->domain_id, free_requests);
>
> What is the purpose of this printk? The ring can and does fillup quickly
> with paging.

Well, we can tone down printk's to be debug level. I don't think they're
unnecessary if they're made an optional debug tool.

Question: I have one vcpu, how do I fill up the ring quickly? (outside of
foreign mappings)

Andres
>
>
>> +    if ( mem_event_ring_free(d, med) == 0 )
>> +    {
>> +        /* This *may* happen, but only when foreign mappings generate
>> events. */
>> +        gdprintk(XENLOG_WARNING, "possible lost mem_event for domain
>> %d\n",
>> +                                 d->domain_id);
>
> This printk is not needed, callers have to try again.
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:53:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:53:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTHwf-0004ez-M2; Wed, 23 Nov 2011 18:53:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTHwd-0004eT-U5
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:53:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322074368!4689750!1
X-Originating-IP: [208.97.132.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 779 invoked from network); 23 Nov 2011 18:52:49 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.81) by server-16.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 18:52:49 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 8F2E71A8069;
	Wed, 23 Nov 2011 10:52:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LmZzxgkmEqCE/0tj9Xr0vyvPS/Minx++9TK9woKsWT9c
	YpAoZCbJE4ftKkJStqI3e8OblhT2gRrx6XPl/boiuHwy5oBQvlNE7fcgdFMZbr/A
	ECNpebl37OAdXnR2qGze9RUAj+R1P+0xDE7rh18EdbKYCfxsIL2tKQPhc3O71DA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=0d850PJHmA0e4G1qMoDPQktMr5s=; b=tiPIeEi7
	G3Z/d02GTPgeesnME1zAZkL+9t6lX2rjYA3UnnjDfUUBbhub2n73rU11Ilbfbv2D
	qssygL3WZcai5yZ9LpCtkehAKACciv91vBNeu0+u6TTLuPUUpjFQB51USznfo3ny
	oCG++0847z7HBRO3sLHWm87Q/n8o9lXdI+Q=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id EF34C1A8061; 
	Wed, 23 Nov 2011 10:52:47 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 23 Nov 2011 10:52:48 -0800
Message-ID: <d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111123183511.GA26144@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
	<20111123183511.GA26144@aepfle.de>
Date: Wed, 23 Nov 2011 10:52:48 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf,
> On Mon, Nov 14, Andres Lagar-Cavilla wrote:
>
> I will do a more complete review later, a few comments below.
>
>
>> +    free_requests = RING_FREE_REQUESTS(&med->front_ring);
>> +    if ( unlikely(free_requests < d->max_vcpus) )
>> +    {
>> +        /* This may happen during normal operation (hopefully not
>> often). */
>> +        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d:
>> %d\n",
>> +                               d->domain_id, free_requests);
>
> What is the purpose of this printk? The ring can and does fillup quickly
> with paging.

Well, we can tone down printk's to be debug level. I don't think they're
unnecessary if they're made an optional debug tool.

Question: I have one vcpu, how do I fill up the ring quickly? (outside of
foreign mappings)

Andres
>
>
>> +    if ( mem_event_ring_free(d, med) == 0 )
>> +    {
>> +        /* This *may* happen, but only when foreign mappings generate
>> events. */
>> +        gdprintk(XENLOG_WARNING, "possible lost mem_event for domain
>> %d\n",
>> +                                 d->domain_id);
>
> This printk is not needed, callers have to try again.
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:57:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTI04-0004xt-PN; Wed, 23 Nov 2011 18:56:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthoine.bourgeois@gmail.com>) id 1RTI03-0004xY-FR
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:56:51 +0000
X-Env-Sender: anthoine.bourgeois@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322074580!4637681!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15986 invoked from network); 23 Nov 2011 18:56:21 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 18:56:21 -0000
Received: by qyk7 with SMTP id 7so503859qyk.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 10:56:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=KIMffZuP/eX/4Yaos82kuRlfL4HSxY85WFHwZKgniXo=;
	b=FrZHOThIduM8VXOOEqhIFj2U0gDgU9tp+UpID9X826hKbmICIOMoeMHAuE57+7vrIX
	mhPtZwmQYaIucdDxxYQp4GDTf7g6NXmfhmVyDO0+7wPRsASYGshTdd9w2iNjPb21lRKm
	WaLHj+6R9VZIHBt1wYT2mVOt30f5xUbIYqVik=
MIME-Version: 1.0
Received: by 10.68.22.167 with SMTP id e7mr10223870pbf.43.1322074579256; Wed,
	23 Nov 2011 10:56:19 -0800 (PST)
Received: by 10.142.233.7 with HTTP; Wed, 23 Nov 2011 10:56:19 -0800 (PST)
Date: Wed, 23 Nov 2011 19:56:19 +0100
Message-ID: <CAHHxriBEsA-23K5QMe3eE-=8Ca6mbsQ4x7C0TG+ap_TRv2vXbg@mail.gmail.com>
From: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=bcaec5215dfba9c67804b26b793e
Subject: [Xen-devel] [patch] Initialize xen_vcpu0 before initialize irq_ops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--bcaec5215dfba9c67804b26b793e
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I find a strange behavior. When a machine is slow (or with many debug
traces or a qemu vm),
a interrupt can occur between the pv_irq_ops initialization and the xen_vcpu[0]
initialization. This lead to a problem because some operations in
xen_irq_ops use
xen_vcpu.
I send you a patch to fix that but I'm not quite sure that is the
right solution.

Regards,
Anthoine

>From ac683ad8264f83fa0a5d743e18c0422e43e871d2 Mon Sep 17 00:00:00 2001
From: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Date: Wed, 23 Nov 2011 19:23:42 +0100
Subject: [PATCH] Initialize xen_vcpu0 before initialize irq_ops.

xen_vcpu is used by
xen_irq_ops.xen_{save_fl,restore_fl,irq_disable,irq_enable} and should
be initialized before xen_init_irq_ops that initialize the pv_irq_ops
with it. If not, a call to those functions could lead to a deference of
NULL pointer.  This behaviour was find with a slow machine or qemu.
---
 arch/x86/xen/enlighten.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 2d69617..a8111a0 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1166,6 +1166,10 @@ asmlinkage void __init xen_start_kernel(void)
         */
        xen_setup_stackprotector();

+       /* Don't do the full vcpu_info placement stuff until we have a
+          possible map and a non-dummy shared_info. */
+       per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+
        xen_init_irq_ops();
        xen_init_cpuid_mask();

@@ -1207,9 +1211,6 @@ asmlinkage void __init xen_start_kernel(void)
                __supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);

        __supported_pte_mask |= _PAGE_IOMAP;
-       /* Don't do the full vcpu_info placement stuff until we have a
-          possible map and a non-dummy shared_info. */
-       per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];

        local_irq_disable();
        early_boot_irqs_disabled = true;
-- 
1.7.3.4

--bcaec5215dfba9c67804b26b793e
Content-Type: text/x-patch; charset=US-ASCII; 
	name="0001-Initialize-xen_vcpu0-before-initialize-irq_ops.patch"
Content-Disposition: attachment; 
	filename="0001-Initialize-xen_vcpu0-before-initialize-irq_ops.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gvcp2t9a1

RnJvbSBhYzY4M2FkODI2NGY4M2ZhMGE1ZDc0M2UxOGMwNDIyZTQzZTg3MWQyIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBBbnRob2luZSBCb3VyZ2VvaXMgPGFudGhvaW5lLmJvdXJnZW9p
c0BnbWFpbC5jb20+CkRhdGU6IFdlZCwgMjMgTm92IDIwMTEgMTk6MjM6NDIgKzAxMDAKU3ViamVj
dDogW1BBVENIXSBJbml0aWFsaXplIHhlbl92Y3B1MCBiZWZvcmUgaW5pdGlhbGl6ZSBpcnFfb3Bz
LgoKeGVuX3ZjcHUgaXMgdXNlZCBieQp4ZW5faXJxX29wcy54ZW5fe3NhdmVfZmwscmVzdG9yZV9m
bCxpcnFfZGlzYWJsZSxpcnFfZW5hYmxlfSBhbmQgc2hvdWxkCmJlIGluaXRpYWxpemVkIGJlZm9y
ZSB4ZW5faW5pdF9pcnFfb3BzIHRoYXQgaW5pdGlhbGl6ZSB0aGUgcHZfaXJxX29wcwp3aXRoIGl0
LiBJZiBub3QsIGEgY2FsbCB0byB0aG9zZSBmdW5jdGlvbnMgY291bGQgbGVhZCB0byBhIGRlZmVy
ZW5jZSBvZgpOVUxMIHBvaW50ZXIuICBUaGlzIGJlaGF2aW91ciB3YXMgZmluZCB3aXRoIGEgc2xv
dyBtYWNoaW5lIG9yIHFlbXUuCi0tLQogYXJjaC94ODYveGVuL2VubGlnaHRlbi5jIHwgICAgNyAr
KysrLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkK
CmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5s
aWdodGVuLmMKaW5kZXggMmQ2OTYxNy4uYTgxMTFhMCAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVu
L2VubGlnaHRlbi5jCisrKyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMTE2Niw2ICsx
MTY2LDEwIEBAIGFzbWxpbmthZ2Ugdm9pZCBfX2luaXQgeGVuX3N0YXJ0X2tlcm5lbCh2b2lkKQog
CSAqLwogCXhlbl9zZXR1cF9zdGFja3Byb3RlY3RvcigpOwogCisJLyogRG9uJ3QgZG8gdGhlIGZ1
bGwgdmNwdV9pbmZvIHBsYWNlbWVudCBzdHVmZiB1bnRpbCB3ZSBoYXZlIGEKKwkgICBwb3NzaWJs
ZSBtYXAgYW5kIGEgbm9uLWR1bW15IHNoYXJlZF9pbmZvLiAqLworCXBlcl9jcHUoeGVuX3ZjcHUs
IDApID0gJkhZUEVSVklTT1Jfc2hhcmVkX2luZm8tPnZjcHVfaW5mb1swXTsKKwogCXhlbl9pbml0
X2lycV9vcHMoKTsKIAl4ZW5faW5pdF9jcHVpZF9tYXNrKCk7CiAKQEAgLTEyMDcsOSArMTIxMSw2
IEBAIGFzbWxpbmthZ2Ugdm9pZCBfX2luaXQgeGVuX3N0YXJ0X2tlcm5lbCh2b2lkKQogCQlfX3N1
cHBvcnRlZF9wdGVfbWFzayAmPSB+KF9QQUdFX1BXVCB8IF9QQUdFX1BDRCk7CiAKIAlfX3N1cHBv
cnRlZF9wdGVfbWFzayB8PSBfUEFHRV9JT01BUDsKLQkvKiBEb24ndCBkbyB0aGUgZnVsbCB2Y3B1
X2luZm8gcGxhY2VtZW50IHN0dWZmIHVudGlsIHdlIGhhdmUgYQotCSAgIHBvc3NpYmxlIG1hcCBh
bmQgYSBub24tZHVtbXkgc2hhcmVkX2luZm8uICovCi0JcGVyX2NwdSh4ZW5fdmNwdSwgMCkgPSAm
SFlQRVJWSVNPUl9zaGFyZWRfaW5mby0+dmNwdV9pbmZvWzBdOwogCiAJbG9jYWxfaXJxX2Rpc2Fi
bGUoKTsKIAllYXJseV9ib290X2lycXNfZGlzYWJsZWQgPSB0cnVlOwotLSAKMS43LjMuNAoK
--bcaec5215dfba9c67804b26b793e
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--bcaec5215dfba9c67804b26b793e--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:57:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTI04-0004xt-PN; Wed, 23 Nov 2011 18:56:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthoine.bourgeois@gmail.com>) id 1RTI03-0004xY-FR
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:56:51 +0000
X-Env-Sender: anthoine.bourgeois@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322074580!4637681!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15986 invoked from network); 23 Nov 2011 18:56:21 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 18:56:21 -0000
Received: by qyk7 with SMTP id 7so503859qyk.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 10:56:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=KIMffZuP/eX/4Yaos82kuRlfL4HSxY85WFHwZKgniXo=;
	b=FrZHOThIduM8VXOOEqhIFj2U0gDgU9tp+UpID9X826hKbmICIOMoeMHAuE57+7vrIX
	mhPtZwmQYaIucdDxxYQp4GDTf7g6NXmfhmVyDO0+7wPRsASYGshTdd9w2iNjPb21lRKm
	WaLHj+6R9VZIHBt1wYT2mVOt30f5xUbIYqVik=
MIME-Version: 1.0
Received: by 10.68.22.167 with SMTP id e7mr10223870pbf.43.1322074579256; Wed,
	23 Nov 2011 10:56:19 -0800 (PST)
Received: by 10.142.233.7 with HTTP; Wed, 23 Nov 2011 10:56:19 -0800 (PST)
Date: Wed, 23 Nov 2011 19:56:19 +0100
Message-ID: <CAHHxriBEsA-23K5QMe3eE-=8Ca6mbsQ4x7C0TG+ap_TRv2vXbg@mail.gmail.com>
From: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=bcaec5215dfba9c67804b26b793e
Subject: [Xen-devel] [patch] Initialize xen_vcpu0 before initialize irq_ops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--bcaec5215dfba9c67804b26b793e
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I find a strange behavior. When a machine is slow (or with many debug
traces or a qemu vm),
a interrupt can occur between the pv_irq_ops initialization and the xen_vcpu[0]
initialization. This lead to a problem because some operations in
xen_irq_ops use
xen_vcpu.
I send you a patch to fix that but I'm not quite sure that is the
right solution.

Regards,
Anthoine

>From ac683ad8264f83fa0a5d743e18c0422e43e871d2 Mon Sep 17 00:00:00 2001
From: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
Date: Wed, 23 Nov 2011 19:23:42 +0100
Subject: [PATCH] Initialize xen_vcpu0 before initialize irq_ops.

xen_vcpu is used by
xen_irq_ops.xen_{save_fl,restore_fl,irq_disable,irq_enable} and should
be initialized before xen_init_irq_ops that initialize the pv_irq_ops
with it. If not, a call to those functions could lead to a deference of
NULL pointer.  This behaviour was find with a slow machine or qemu.
---
 arch/x86/xen/enlighten.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 2d69617..a8111a0 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1166,6 +1166,10 @@ asmlinkage void __init xen_start_kernel(void)
         */
        xen_setup_stackprotector();

+       /* Don't do the full vcpu_info placement stuff until we have a
+          possible map and a non-dummy shared_info. */
+       per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+
        xen_init_irq_ops();
        xen_init_cpuid_mask();

@@ -1207,9 +1211,6 @@ asmlinkage void __init xen_start_kernel(void)
                __supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);

        __supported_pte_mask |= _PAGE_IOMAP;
-       /* Don't do the full vcpu_info placement stuff until we have a
-          possible map and a non-dummy shared_info. */
-       per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];

        local_irq_disable();
        early_boot_irqs_disabled = true;
-- 
1.7.3.4

--bcaec5215dfba9c67804b26b793e
Content-Type: text/x-patch; charset=US-ASCII; 
	name="0001-Initialize-xen_vcpu0-before-initialize-irq_ops.patch"
Content-Disposition: attachment; 
	filename="0001-Initialize-xen_vcpu0-before-initialize-irq_ops.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gvcp2t9a1

RnJvbSBhYzY4M2FkODI2NGY4M2ZhMGE1ZDc0M2UxOGMwNDIyZTQzZTg3MWQyIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBBbnRob2luZSBCb3VyZ2VvaXMgPGFudGhvaW5lLmJvdXJnZW9p
c0BnbWFpbC5jb20+CkRhdGU6IFdlZCwgMjMgTm92IDIwMTEgMTk6MjM6NDIgKzAxMDAKU3ViamVj
dDogW1BBVENIXSBJbml0aWFsaXplIHhlbl92Y3B1MCBiZWZvcmUgaW5pdGlhbGl6ZSBpcnFfb3Bz
LgoKeGVuX3ZjcHUgaXMgdXNlZCBieQp4ZW5faXJxX29wcy54ZW5fe3NhdmVfZmwscmVzdG9yZV9m
bCxpcnFfZGlzYWJsZSxpcnFfZW5hYmxlfSBhbmQgc2hvdWxkCmJlIGluaXRpYWxpemVkIGJlZm9y
ZSB4ZW5faW5pdF9pcnFfb3BzIHRoYXQgaW5pdGlhbGl6ZSB0aGUgcHZfaXJxX29wcwp3aXRoIGl0
LiBJZiBub3QsIGEgY2FsbCB0byB0aG9zZSBmdW5jdGlvbnMgY291bGQgbGVhZCB0byBhIGRlZmVy
ZW5jZSBvZgpOVUxMIHBvaW50ZXIuICBUaGlzIGJlaGF2aW91ciB3YXMgZmluZCB3aXRoIGEgc2xv
dyBtYWNoaW5lIG9yIHFlbXUuCi0tLQogYXJjaC94ODYveGVuL2VubGlnaHRlbi5jIHwgICAgNyAr
KysrLS0tCiAxIGZpbGVzIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkK
CmRpZmYgLS1naXQgYS9hcmNoL3g4Ni94ZW4vZW5saWdodGVuLmMgYi9hcmNoL3g4Ni94ZW4vZW5s
aWdodGVuLmMKaW5kZXggMmQ2OTYxNy4uYTgxMTFhMCAxMDA2NDQKLS0tIGEvYXJjaC94ODYveGVu
L2VubGlnaHRlbi5jCisrKyBiL2FyY2gveDg2L3hlbi9lbmxpZ2h0ZW4uYwpAQCAtMTE2Niw2ICsx
MTY2LDEwIEBAIGFzbWxpbmthZ2Ugdm9pZCBfX2luaXQgeGVuX3N0YXJ0X2tlcm5lbCh2b2lkKQog
CSAqLwogCXhlbl9zZXR1cF9zdGFja3Byb3RlY3RvcigpOwogCisJLyogRG9uJ3QgZG8gdGhlIGZ1
bGwgdmNwdV9pbmZvIHBsYWNlbWVudCBzdHVmZiB1bnRpbCB3ZSBoYXZlIGEKKwkgICBwb3NzaWJs
ZSBtYXAgYW5kIGEgbm9uLWR1bW15IHNoYXJlZF9pbmZvLiAqLworCXBlcl9jcHUoeGVuX3ZjcHUs
IDApID0gJkhZUEVSVklTT1Jfc2hhcmVkX2luZm8tPnZjcHVfaW5mb1swXTsKKwogCXhlbl9pbml0
X2lycV9vcHMoKTsKIAl4ZW5faW5pdF9jcHVpZF9tYXNrKCk7CiAKQEAgLTEyMDcsOSArMTIxMSw2
IEBAIGFzbWxpbmthZ2Ugdm9pZCBfX2luaXQgeGVuX3N0YXJ0X2tlcm5lbCh2b2lkKQogCQlfX3N1
cHBvcnRlZF9wdGVfbWFzayAmPSB+KF9QQUdFX1BXVCB8IF9QQUdFX1BDRCk7CiAKIAlfX3N1cHBv
cnRlZF9wdGVfbWFzayB8PSBfUEFHRV9JT01BUDsKLQkvKiBEb24ndCBkbyB0aGUgZnVsbCB2Y3B1
X2luZm8gcGxhY2VtZW50IHN0dWZmIHVudGlsIHdlIGhhdmUgYQotCSAgIHBvc3NpYmxlIG1hcCBh
bmQgYSBub24tZHVtbXkgc2hhcmVkX2luZm8uICovCi0JcGVyX2NwdSh4ZW5fdmNwdSwgMCkgPSAm
SFlQRVJWSVNPUl9zaGFyZWRfaW5mby0+dmNwdV9pbmZvWzBdOwogCiAJbG9jYWxfaXJxX2Rpc2Fi
bGUoKTsKIAllYXJseV9ib290X2lycXNfZGlzYWJsZWQgPSB0cnVlOwotLSAKMS43LjMuNAoK
--bcaec5215dfba9c67804b26b793e
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--bcaec5215dfba9c67804b26b793e--


From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:58:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:58:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTI1Q-00054T-9D; Wed, 23 Nov 2011 18:58:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTI1O-00053w-Ev
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:58:14 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322074625!64397791!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18658 invoked from network); 23 Nov 2011 18:57:06 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 18:57:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322074665; l=594;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=MmlTl27W/MPyju6BVCwORQwbbrY=;
	b=M6M97X09lw3Jfd8DnGIC6kRFA5GMxiLKJv53c+SyGrmzAMyw/xm5D36jCSull7uogtA
	zWQTnYXPSWumsXIiGgN2iiO9R4TuIleUt7y0YqcbHEmTYZ92EgnxCd+iQ9hu6xf4tNyIG
	9JW4lchou+PgsbBtMoIFQ3ctdUnMytWZt08=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (jimi mo49) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y050f7nANHC2tN ;
	Wed, 23 Nov 2011 19:57:31 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7C59A18637; Wed, 23 Nov 2011 19:57:28 +0100 (CET)
Date: Wed, 23 Nov 2011 19:57:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111123185728.GA27583@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
	<20111123183511.GA26144@aepfle.de>
	<d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Andres Lagar-Cavilla wrote:

> Well, we can tone down printk's to be debug level. I don't think they're
> unnecessary if they're made an optional debug tool.

There is nothing to debug here, since the callers have to retry anyway.

> Question: I have one vcpu, how do I fill up the ring quickly? (outside of
> foreign mappings)

Have a balloon driver in the guest and balloon down more than
64*PAGE_SIZE. This is the default at least in my setup where the kernel
driver releases some memory right away (I havent checked where this is
actually configured).

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 18:58:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 18:58:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTI1Q-00054T-9D; Wed, 23 Nov 2011 18:58:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTI1O-00053w-Ev
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 18:58:14 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322074625!64397791!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18658 invoked from network); 23 Nov 2011 18:57:06 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 18:57:06 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322074665; l=594;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=MmlTl27W/MPyju6BVCwORQwbbrY=;
	b=M6M97X09lw3Jfd8DnGIC6kRFA5GMxiLKJv53c+SyGrmzAMyw/xm5D36jCSull7uogtA
	zWQTnYXPSWumsXIiGgN2iiO9R4TuIleUt7y0YqcbHEmTYZ92EgnxCd+iQ9hu6xf4tNyIG
	9JW4lchou+PgsbBtMoIFQ3ctdUnMytWZt08=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (jimi mo49) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y050f7nANHC2tN ;
	Wed, 23 Nov 2011 19:57:31 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7C59A18637; Wed, 23 Nov 2011 19:57:28 +0100 (CET)
Date: Wed, 23 Nov 2011 19:57:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111123185728.GA27583@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
	<20111123183511.GA26144@aepfle.de>
	<d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Andres Lagar-Cavilla wrote:

> Well, we can tone down printk's to be debug level. I don't think they're
> unnecessary if they're made an optional debug tool.

There is nothing to debug here, since the callers have to retry anyway.

> Question: I have one vcpu, how do I fill up the ring quickly? (outside of
> foreign mappings)

Have a balloon driver in the guest and balloon down more than
64*PAGE_SIZE. This is the default at least in my setup where the kernel
driver releases some memory right away (I havent checked where this is
actually configured).

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 19:22:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 19:22:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTIOo-0005kv-JL; Wed, 23 Nov 2011 19:22:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTIOn-0005kp-10
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 19:22:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322076114!4725474!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20123 invoked from network); 23 Nov 2011 19:21:54 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 19:21:54 -0000
Received: by bkbzt12 with SMTP id zt12so2649268bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 11:21:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=M5c+wURR0XXk1C3IipS5g7gofY3BJdXIqRa6i66pcf4=;
	b=ZIW32mRwtwjfjpH9JxPI/0Xt180fTFVTjGjOK08I/NUaToMqIumFrl97UMlFMsD5iZ
	gi+wvOt0zuWwYueKcL8JHS5D04gTprDCjStgK1j5ovc9GYpPzjYMK/BmHPE8H0dohkHP
	gI/WPGhB0YS02B3tx7A5bIStbDasy+SF9q3BI=
Received: by 10.205.128.15 with SMTP id hc15mr24882031bkc.110.1322076113783;
	Wed, 23 Nov 2011 11:21:53 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id e8sm13733168bkd.7.2011.11.23.11.21.49
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 11:21:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 19:21:46 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF2F84A.2571A%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqFSPigRbmOh5ymkyxVkLvJHSMcg==
In-Reply-To: <20111123183148.GA26869@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 18:31, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Wed, Nov 23, Keir Fraser wrote:
> 
>> We have quite a big waitqueue problem actually. The current scheme of
>> per-cpu stacks doesn't work nicely, as the stack pointer will change if a
>> vcpu goes to sleep and then wakes up on a different cpu. This really doesn't
>> work nicely with preempted C code, which may implement frame pointers and/or
>> arbitrarily take the address of on-stack variables. The result will be
>> hideous cross-stack corruptions, as these frame pointers and cached
>> addresses of automatic variables will reference the wrong cpu's stack!
>> Fixing or detecting this in general is not possible afaics.
> 
> Yes, I was thinking about that wakeup on different cpu as well.
> As a quick fix/hack, perhaps the scheduler could make sure the vcpu
> wakes up on the same cpu?

Could save old affinity and then vcpu_set_affinity. That will have to do for
now. Actually it should work okay as long as toolstack doesn't mess with
affinity meanwhile. I'll sort out a patch for this.

 -- Keir

> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 19:22:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 19:22:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTIOo-0005kv-JL; Wed, 23 Nov 2011 19:22:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTIOn-0005kp-10
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 19:22:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322076114!4725474!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20123 invoked from network); 23 Nov 2011 19:21:54 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 19:21:54 -0000
Received: by bkbzt12 with SMTP id zt12so2649268bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 11:21:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=M5c+wURR0XXk1C3IipS5g7gofY3BJdXIqRa6i66pcf4=;
	b=ZIW32mRwtwjfjpH9JxPI/0Xt180fTFVTjGjOK08I/NUaToMqIumFrl97UMlFMsD5iZ
	gi+wvOt0zuWwYueKcL8JHS5D04gTprDCjStgK1j5ovc9GYpPzjYMK/BmHPE8H0dohkHP
	gI/WPGhB0YS02B3tx7A5bIStbDasy+SF9q3BI=
Received: by 10.205.128.15 with SMTP id hc15mr24882031bkc.110.1322076113783;
	Wed, 23 Nov 2011 11:21:53 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id e8sm13733168bkd.7.2011.11.23.11.21.49
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 11:21:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 19:21:46 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF2F84A.2571A%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqFSPigRbmOh5ymkyxVkLvJHSMcg==
In-Reply-To: <20111123183148.GA26869@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 18:31, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Wed, Nov 23, Keir Fraser wrote:
> 
>> We have quite a big waitqueue problem actually. The current scheme of
>> per-cpu stacks doesn't work nicely, as the stack pointer will change if a
>> vcpu goes to sleep and then wakes up on a different cpu. This really doesn't
>> work nicely with preempted C code, which may implement frame pointers and/or
>> arbitrarily take the address of on-stack variables. The result will be
>> hideous cross-stack corruptions, as these frame pointers and cached
>> addresses of automatic variables will reference the wrong cpu's stack!
>> Fixing or detecting this in general is not possible afaics.
> 
> Yes, I was thinking about that wakeup on different cpu as well.
> As a quick fix/hack, perhaps the scheduler could make sure the vcpu
> wakes up on the same cpu?

Could save old affinity and then vcpu_set_affinity. That will have to do for
now. Actually it should work okay as long as toolstack doesn't mess with
affinity meanwhile. I'll sort out a patch for this.

 -- Keir

> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 20:12:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 20:12:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTJBA-00075H-RG; Wed, 23 Nov 2011 20:12:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>) id 1RTJB8-00075A-JF
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 20:12:22 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322079111!4351383!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6449 invoked from network); 23 Nov 2011 20:11:52 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 20:11:52 -0000
Received: by iaby12 with SMTP id y12so2507983iab.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 12:11:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=gS2OLPqX3KhPTrC46gycDVH7/rpCrV1jkQQt0zlm3LA=;
	b=BNmNjtuDXBDsiE40vnv96Cx7VFjhCqyM1dGzcDrY75kk/ncZ5YBmMBVyPX3ZQzPDYd
	TS4txsM9Od70R9/jgqYwZQQnxcMskpST+HSIcUuyNcI7IJrTfrcP+kfvwiWpfFEGVzYA
	yV2sk3mEZ9MU98GU/GpneXRhjfC3+GTGrEKfg=
MIME-Version: 1.0
Received: by 10.42.244.133 with SMTP id lq5mr4319572icb.29.1322079110600; Wed,
	23 Nov 2011 12:11:50 -0800 (PST)
Received: by 10.231.62.1 with HTTP; Wed, 23 Nov 2011 12:11:50 -0800 (PST)
Date: Wed, 23 Nov 2011 21:11:50 +0100
Message-ID: <CAFivhPnQVSAPq7cUv4H-aZn_P79f0_CyrJGaRnP4BFAeGBKQJg@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Can domU config add userdefined keys to Xenstore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I wonder if there is some (crazy, useful, your choice) way to do the
equivalent of the following commands while a new VM is built.
(much like adding usb or pci devices works)

xenstore-write /local/domain/<id>/new_node "Null"
xenstore-chmod /local/domain/<id>/new_node w

I would like to create the entry right at domU launch, and I'd like to
make use of
Xens knowledge of the domU ID it'll use, because the changing domU ID
is a grief.

Also, it would of course be much saner to do it in the VM config
instead via some watch-daemon or even udev rules.

Greetings,
Florian


-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 20:12:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 20:12:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTJBA-00075H-RG; Wed, 23 Nov 2011 20:12:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>) id 1RTJB8-00075A-JF
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 20:12:22 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322079111!4351383!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6449 invoked from network); 23 Nov 2011 20:11:52 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 20:11:52 -0000
Received: by iaby12 with SMTP id y12so2507983iab.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 12:11:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=gS2OLPqX3KhPTrC46gycDVH7/rpCrV1jkQQt0zlm3LA=;
	b=BNmNjtuDXBDsiE40vnv96Cx7VFjhCqyM1dGzcDrY75kk/ncZ5YBmMBVyPX3ZQzPDYd
	TS4txsM9Od70R9/jgqYwZQQnxcMskpST+HSIcUuyNcI7IJrTfrcP+kfvwiWpfFEGVzYA
	yV2sk3mEZ9MU98GU/GpneXRhjfC3+GTGrEKfg=
MIME-Version: 1.0
Received: by 10.42.244.133 with SMTP id lq5mr4319572icb.29.1322079110600; Wed,
	23 Nov 2011 12:11:50 -0800 (PST)
Received: by 10.231.62.1 with HTTP; Wed, 23 Nov 2011 12:11:50 -0800 (PST)
Date: Wed, 23 Nov 2011 21:11:50 +0100
Message-ID: <CAFivhPnQVSAPq7cUv4H-aZn_P79f0_CyrJGaRnP4BFAeGBKQJg@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Can domU config add userdefined keys to Xenstore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I wonder if there is some (crazy, useful, your choice) way to do the
equivalent of the following commands while a new VM is built.
(much like adding usb or pci devices works)

xenstore-write /local/domain/<id>/new_node "Null"
xenstore-chmod /local/domain/<id>/new_node w

I would like to create the entry right at domU launch, and I'd like to
make use of
Xens knowledge of the domU ID it'll use, because the changing domU ID
is a grief.

Also, it would of course be much saner to do it in the VM config
instead via some watch-daemon or even udev rules.

Greetings,
Florian


-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 20:42:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 20:42:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTJdc-0007Ww-M6; Wed, 23 Nov 2011 20:41:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTJda-0007Vt-FV
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 20:41:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322080876!5511522!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 803 invoked from network); 23 Nov 2011 20:41:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 20:41:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,561,1315180800"; 
   d="scan'208";a="9100412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 20:41:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 20:41:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTJd5-0007kQ-7W;
	Wed, 23 Nov 2011 20:41:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTJd5-000794-6C;
	Wed, 23 Nov 2011 20:41:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10017-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 20:41:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10017: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10017 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10017/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  84b3e46aa7d2
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24187:84b3e46aa7d2
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 23 12:03:37 2011 +0000
    
    libxl: Prevent xl save from segfaulting when control/shutdown key is removed
    
    To acknowledge the tools' setting of control/shutdown it is normal for
    PV drivers to rm the key. This leads to libxl__xs_read() returning
    NULL and thus a subsequent strcmp on the return value will cause a
    segfault.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24186:7aa5838499d1
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 23 11:15:31 2011 +0000
    
    tools: use system libaio for blktap1 as well.
    
    24184:4ecd3615e726 missed this because I was accidentally testing with a
    .config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
    without this. There were no other issues.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24185:f88c745575bb
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 18:51:13 2011 +0000
    
    docs: remove some fatally out of date documentation
    
    I think these are better off deleted than remaining to confuse people.
    
    docs/misc/blkif-drivers-explained.txt:
    
     - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.
    
    docs/misc/cpuid-config-for-guest.txt:
    
     - Doesn't really say anything, in particular doesn't actually describe how to
       configure CPUID.
    
    docs/misc/hg-cheatsheet.txt:
    
     - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
       under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
       hardly unusual anymore I think there must be better guides out there so this
       one is not worth resurecting.
    
    docs/misc/network_setup.txt:
    
     - This is more comprehensively documented on the wiki these days.
    
    docs/misc/VMX_changes.txt:
    
     - Is basically a changelog from the initial implementation of VMX in 2004.
    
    I'm not sure about some of the other docs, but these ones seemed fairly
    obvious.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24184:4ecd3615e726
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 20:42:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 20:42:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTJdc-0007Ww-M6; Wed, 23 Nov 2011 20:41:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTJda-0007Vt-FV
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 20:41:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322080876!5511522!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 803 invoked from network); 23 Nov 2011 20:41:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 20:41:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,561,1315180800"; 
   d="scan'208";a="9100412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Nov 2011 20:41:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 23 Nov 2011 20:41:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTJd5-0007kQ-7W;
	Wed, 23 Nov 2011 20:41:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTJd5-000794-6C;
	Wed, 23 Nov 2011 20:41:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10017-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 23 Nov 2011 20:41:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10017: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10017 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10017/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  84b3e46aa7d2
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24187:84b3e46aa7d2
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 23 12:03:37 2011 +0000
    
    libxl: Prevent xl save from segfaulting when control/shutdown key is removed
    
    To acknowledge the tools' setting of control/shutdown it is normal for
    PV drivers to rm the key. This leads to libxl__xs_read() returning
    NULL and thus a subsequent strcmp on the return value will cause a
    segfault.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24186:7aa5838499d1
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 23 11:15:31 2011 +0000
    
    tools: use system libaio for blktap1 as well.
    
    24184:4ecd3615e726 missed this because I was accidentally testing with a
    .config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
    without this. There were no other issues.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24185:f88c745575bb
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 18:51:13 2011 +0000
    
    docs: remove some fatally out of date documentation
    
    I think these are better off deleted than remaining to confuse people.
    
    docs/misc/blkif-drivers-explained.txt:
    
     - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.
    
    docs/misc/cpuid-config-for-guest.txt:
    
     - Doesn't really say anything, in particular doesn't actually describe how to
       configure CPUID.
    
    docs/misc/hg-cheatsheet.txt:
    
     - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
       under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
       hardly unusual anymore I think there must be better guides out there so this
       one is not worth resurecting.
    
    docs/misc/network_setup.txt:
    
     - This is more comprehensively documented on the wiki these days.
    
    docs/misc/VMX_changes.txt:
    
     - Is basically a changelog from the initial implementation of VMX in 2004.
    
    I'm not sure about some of the other docs, but these ones seemed fairly
    obvious.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24184:4ecd3615e726
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:04:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:04:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTJzP-00080j-1y; Wed, 23 Nov 2011 21:04:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTJzN-00080c-Vb
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:04:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322082227!4749120!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15517 invoked from network); 23 Nov 2011 21:03:47 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 21:03:47 -0000
Received: by bkbzt12 with SMTP id zt12so2768865bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 13:03:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=HeDAeB7+R1Dtl7sQpC2W4I7iHy461eJM/TscB/OPRqg=;
	b=a74S584awyk18fVYk9uf/7hJRp7edsqIu1oUOlQwpw6SfpfsHInH2gmHbw6JwxmL2n
	Vy9iC2zZbjBqBNkwi4bboHDHrucJ1ZPriae6OE/lp6H+tOdQU3FCNjjo/nrvaC/mcg1l
	4O6BomuoIKriNmXkiKGB8N2nETunezVAHLuyU=
Received: by 10.204.148.4 with SMTP id n4mr26088057bkv.42.1322082226933;
	Wed, 23 Nov 2011 13:03:46 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id hw14sm1045667bkc.16.2011.11.23.13.03.45
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 13:03:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 21:03:39 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF3102F.25730%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqFSPigRbmOh5ymkyxVkLvJHSMcgADjugi
In-Reply-To: <CAF2F84A.2571A%keir.xen@gmail.com>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3404927025_64467266"
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3404927025_64467266
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 23/11/2011 19:21, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 23/11/2011 18:31, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
>> On Wed, Nov 23, Keir Fraser wrote:
>> 
>>> We have quite a big waitqueue problem actually. The current scheme of
>>> per-cpu stacks doesn't work nicely, as the stack pointer will change if a
>>> vcpu goes to sleep and then wakes up on a different cpu. This really doesn't
>>> work nicely with preempted C code, which may implement frame pointers and/or
>>> arbitrarily take the address of on-stack variables. The result will be
>>> hideous cross-stack corruptions, as these frame pointers and cached
>>> addresses of automatic variables will reference the wrong cpu's stack!
>>> Fixing or detecting this in general is not possible afaics.
>> 
>> Yes, I was thinking about that wakeup on different cpu as well.
>> As a quick fix/hack, perhaps the scheduler could make sure the vcpu
>> wakes up on the same cpu?
> 
> Could save old affinity and then vcpu_set_affinity. That will have to do for
> now. Actually it should work okay as long as toolstack doesn't mess with
> affinity meanwhile. I'll sort out a patch for this.

Attached three patches for you to try. They apply in sequence.
00: A fixed version of "domain_crash on stack overflow"
01: Reorders prepare_to_wait so that the vcpu will always be on the
waitqueue on exit (even if it has just been woken).
02: Ensures the vcpu wakes up on the same cpu that it slept on.

We need all of these. Just need testing to make sure they aren't horribly
broken. You should be able to test multi-processor host again with these.

 -- Keir

>  -- Keir
> 
>> Olaf
> 
> 


--B_3404927025_64467266
Content-type: application/octet-stream; name="00-prep-to-wait-dom-crash"
Content-disposition: attachment;
	filename="00-prep-to-wait-dom-crash"
Content-transfer-encoding: base64


IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgODRiM2U0NmFhN2QyNGE0NjA1YzM2OTQw
NjA2ZTdkYTk2NzliMGU3ZgoKZGlmZiAtciA4NGIzZTQ2YWE3ZDIgeGVuL2NvbW1vbi93YWl0
LmMKLS0tIGEveGVuL2NvbW1vbi93YWl0LmMJV2VkIE5vdiAyMyAxMjowMzozNyAyMDExICsw
MDAwCisrKyBiL3hlbi9jb21tb24vd2FpdC5jCVdlZCBOb3YgMjMgMTk6NDM6MzUgMjAxMSAr
MDAwMApAQCAtMTA2LDEzICsxMDYsMTYgQEAgdm9pZCB3YWtlX3VwKHN0cnVjdCB3YWl0cXVl
dWVfaGVhZCAqd3EpCiBzdGF0aWMgdm9pZCBfX3ByZXBhcmVfdG9fd2FpdChzdHJ1Y3Qgd2Fp
dHF1ZXVlX3ZjcHUgKndxdikKIHsKICAgICBjaGFyICpjcHVfaW5mbyA9IChjaGFyICopZ2V0
X2NwdV9pbmZvKCk7CisKICAgICBhc20gdm9sYXRpbGUgKAogI2lmZGVmIENPTkZJR19YODZf
NjQKICAgICAgICAgInB1c2ggJSVyYXg7IHB1c2ggJSVyYng7IHB1c2ggJSVyY3g7IHB1c2gg
JSVyZHg7IHB1c2ggJSVyZGk7ICIKICAgICAgICAgInB1c2ggJSVyYnA7IHB1c2ggJSVyODsg
cHVzaCAlJXI5OyBwdXNoICUlcjEwOyBwdXNoICUlcjExOyAiCiAgICAgICAgICJwdXNoICUl
cjEyOyBwdXNoICUlcjEzOyBwdXNoICUlcjE0OyBwdXNoICUlcjE1OyBjYWxsIDFmOyAiCiAg
ICAgICAgICIxOiBtb3YgODAoJSVyc3ApLCUlcmRpOyBtb3YgOTYoJSVyc3ApLCUlcmN4OyBt
b3YgJSVyc3AsJSVyc2k7ICIKLSAgICAgICAgInN1YiAlJXJzaSwlJXJjeDsgcmVwIG1vdnNi
OyBtb3YgJSVyc3AsJSVyc2k7IHBvcCAlJXJheDsgIgorICAgICAgICAic3ViICUlcnNpLCUl
cmN4OyBjbXAgJTMsJSVyY3g7IGpiZSAyZjsgIgorICAgICAgICAieG9yICUlZXNpLCUlZXNp
OyBqbXAgM2Y7ICIKKyAgICAgICAgIjI6IHJlcCBtb3ZzYjsgbW92ICUlcnNwLCUlcnNpOyAz
OiBwb3AgJSVyYXg7ICIKICAgICAgICAgInBvcCAlJXIxNTsgcG9wICUlcjE0OyBwb3AgJSVy
MTM7IHBvcCAlJXIxMjsgIgogICAgICAgICAicG9wICUlcjExOyBwb3AgJSVyMTA7IHBvcCAl
JXI5OyBwb3AgJSVyODsgIgogICAgICAgICAicG9wICUlcmJwOyBwb3AgJSVyZGk7IHBvcCAl
JXJkeDsgcG9wICUlcmN4OyBwb3AgJSVyYng7IHBvcCAlJXJheCIKQEAgLTEyMCwxMyArMTIz
LDIwIEBAIHN0YXRpYyB2b2lkIF9fcHJlcGFyZV90b193YWl0KHN0cnVjdCB3YWkKICAgICAg
ICAgInB1c2ggJSVlYXg7IHB1c2ggJSVlYng7IHB1c2ggJSVlY3g7IHB1c2ggJSVlZHg7IHB1
c2ggJSVlZGk7ICIKICAgICAgICAgInB1c2ggJSVlYnA7IGNhbGwgMWY7ICIKICAgICAgICAg
IjE6IG1vdiA4KCUlZXNwKSwlJWVkaTsgbW92IDE2KCUlZXNwKSwlJWVjeDsgbW92ICUlZXNw
LCUlZXNpOyAiCi0gICAgICAgICJzdWIgJSVlc2ksJSVlY3g7IHJlcCBtb3ZzYjsgbW92ICUl
ZXNwLCUlZXNpOyBwb3AgJSVlYXg7ICIKKyAgICAgICAgInN1YiAlJWVzaSwlJWVjeDsgY21w
ICUzLCUlZWN4OyBqYmUgMmY7ICIKKyAgICAgICAgInhvciAlJWVzaSwlJWVzaTsgam1wIDNm
OyAiCisgICAgICAgICIyOiByZXAgbW92c2I7IG1vdiAlJWVzcCwlJWVzaTsgMzogcG9wICUl
ZWF4OyAiCiAgICAgICAgICJwb3AgJSVlYnA7IHBvcCAlJWVkaTsgcG9wICUlZWR4OyBwb3Ag
JSVlY3g7IHBvcCAlJWVieDsgcG9wICUlZWF4IgogI2VuZGlmCiAgICAgICAgIDogIj1TIiAo
d3F2LT5lc3ApCi0gICAgICAgIDogImMiIChjcHVfaW5mbyksICJEIiAod3F2LT5zdGFjaykK
KyAgICAgICAgOiAiYyIgKGNwdV9pbmZvKSwgIkQiICh3cXYtPnN0YWNrKSwgImkiIChQQUdF
X1NJWkUpCiAgICAgICAgIDogIm1lbW9yeSIgKTsKLSAgICBCVUdfT04oKGNwdV9pbmZvIC0g
KGNoYXIgKil3cXYtPmVzcCkgPiBQQUdFX1NJWkUpOworCisgICAgaWYgKCB1bmxpa2VseSh3
cXYtPmVzcCA9PSAwKSApCisgICAgeworICAgICAgICBnZHByaW50ayhYRU5MT0dfRVJSLCAi
U3RhY2sgdG9vIGxhcmdlIGluICVzXG4iLCBfX0ZVTkNUSU9OX18pOworICAgICAgICBkb21h
aW5fY3Jhc2hfc3luY2hyb25vdXMoKTsKKyAgICB9CiB9CiAKIHN0YXRpYyB2b2lkIF9fZmlu
aXNoX3dhaXQoc3RydWN0IHdhaXRxdWV1ZV92Y3B1ICp3cXYpCkBAIC0xNjIsNiArMTcyLDcg
QEAgdm9pZCBwcmVwYXJlX3RvX3dhaXQoc3RydWN0IHdhaXRxdWV1ZV9oZQogICAgIHN0cnVj
dCB2Y3B1ICpjdXJyID0gY3VycmVudDsKICAgICBzdHJ1Y3Qgd2FpdHF1ZXVlX3ZjcHUgKndx
diA9IGN1cnItPndhaXRxdWV1ZV92Y3B1OwogCisgICAgQVNTRVJUKCFpbl9hdG9taWMoKSk7
CiAgICAgQVNTRVJUKGxpc3RfZW1wdHkoJndxdi0+bGlzdCkpOwogCiAgICAgc3Bpbl9sb2Nr
KCZ3cS0+bG9jayk7Cg==
--B_3404927025_64467266
Content-type: application/octet-stream; name="01-prep-to-wait-reorder"
Content-disposition: attachment;
	filename="01-prep-to-wait-reorder"
Content-transfer-encoding: base64


IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgY2MwNTVkYWIzNjA2NTI5ZmNhYmMyODY4
NWM1YmYwZGViZGZjMjEzYwpkaWZmIC1yIGNjMDU1ZGFiMzYwNiAtciA4NDYyODI5MWU1ODUg
eGVuL2NvbW1vbi93YWl0LmMKLS0tIGEveGVuL2NvbW1vbi93YWl0LmMJV2VkIE5vdiAyMyAx
ODowMTo0NCAyMDExICswMDAwCisrKyBiL3hlbi9jb21tb24vd2FpdC5jCVdlZCBOb3YgMjMg
MTg6MDM6NTUgMjAxMSArMDAwMApAQCAtMTA3LDYgKzEwNyw4IEBAIHN0YXRpYyB2b2lkIF9f
cHJlcGFyZV90b193YWl0KHN0cnVjdCB3YWkKIHsKICAgICBjaGFyICpjcHVfaW5mbyA9IChj
aGFyICopZ2V0X2NwdV9pbmZvKCk7CiAKKyAgICBBU1NFUlQod3F2LT5lc3AgPT0gMCk7CisK
ICAgICBhc20gdm9sYXRpbGUgKAogI2lmZGVmIENPTkZJR19YODZfNjQKICAgICAgICAgInB1
c2ggJSVyYXg7IHB1c2ggJSVyYng7IHB1c2ggJSVyY3g7IHB1c2ggJSVyZHg7IHB1c2ggJSVy
ZGk7ICIKQEAgLTE3MywxNCArMTc1LDEzIEBAIHZvaWQgcHJlcGFyZV90b193YWl0KHN0cnVj
dCB3YWl0cXVldWVfaGUKICAgICBzdHJ1Y3Qgd2FpdHF1ZXVlX3ZjcHUgKndxdiA9IGN1cnIt
PndhaXRxdWV1ZV92Y3B1OwogCiAgICAgQVNTRVJUKCFpbl9hdG9taWMoKSk7CisgICAgX19w
cmVwYXJlX3RvX3dhaXQod3F2KTsKKwogICAgIEFTU0VSVChsaXN0X2VtcHR5KCZ3cXYtPmxp
c3QpKTsKLQogICAgIHNwaW5fbG9jaygmd3EtPmxvY2spOwogICAgIGxpc3RfYWRkX3RhaWwo
Jndxdi0+bGlzdCwgJndxLT5saXN0KTsKICAgICB2Y3B1X3BhdXNlX25vc3luYyhjdXJyKTsK
ICAgICBzcGluX3VubG9jaygmd3EtPmxvY2spOwotCi0gICAgX19wcmVwYXJlX3RvX3dhaXQo
d3F2KTsKIH0KIAogdm9pZCBmaW5pc2hfd2FpdChzdHJ1Y3Qgd2FpdHF1ZXVlX2hlYWQgKndx
KQo=
--B_3404927025_64467266
Content-type: application/octet-stream; name="02-waitq-set-vcpu-affinity"
Content-disposition: attachment;
	filename="02-waitq-set-vcpu-affinity"
Content-transfer-encoding: base64


IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgMThhMWYzNWFmMWM1NWRkYmQ4N2JkMzlh
OTMxN2MzOGZmYTJhMWY3YQpkaWZmIC1yIDE4YTFmMzVhZjFjNSAtciAwZjIyMDY0ZDk4YWUg
eGVuL2NvbW1vbi93YWl0LmMKLS0tIGEveGVuL2NvbW1vbi93YWl0LmMJV2VkIE5vdiAyMyAx
OTo0Mzo0NiAyMDExICswMDAwCisrKyBiL3hlbi9jb21tb24vd2FpdC5jCVdlZCBOb3YgMjMg
MjA6MDI6MDUgMjAxMSArMDAwMApAQCAtMzQsNiArMzQsOCBAQCBzdHJ1Y3Qgd2FpdHF1ZXVl
X3ZjcHUgewogICAgICAqLwogICAgIHZvaWQgKmVzcDsKICAgICBjaGFyICpzdGFjazsKKyAg
ICBjcHVtYXNrX3Qgc2F2ZWRfYWZmaW5pdHk7CisgICAgdW5zaWduZWQgaW50IHdha2V1cF9j
cHU7CiAjZW5kaWYKIH07CiAKQEAgLTEwNiw5ICsxMDgsMTkgQEAgdm9pZCB3YWtlX3VwKHN0
cnVjdCB3YWl0cXVldWVfaGVhZCAqd3EpCiBzdGF0aWMgdm9pZCBfX3ByZXBhcmVfdG9fd2Fp
dChzdHJ1Y3Qgd2FpdHF1ZXVlX3ZjcHUgKndxdikKIHsKICAgICBjaGFyICpjcHVfaW5mbyA9
IChjaGFyICopZ2V0X2NwdV9pbmZvKCk7CisgICAgc3RydWN0IHZjcHUgKmN1cnIgPSBjdXJy
ZW50OwogCiAgICAgQVNTRVJUKHdxdi0+ZXNwID09IDApOwogCisgICAgLyogU2F2ZSBjdXJy
ZW50IFZDUFUgYWZmaW5pdHk7IGZvcmNlIHdha2V1cCBvbiAqdGhpcyogQ1BVIG9ubHkuICov
CisgICAgd3F2LT53YWtldXBfY3B1ID0gc21wX3Byb2Nlc3Nvcl9pZCgpOworICAgIGNwdW1h
c2tfY29weSgmd3F2LT5zYXZlZF9hZmZpbml0eSwgY3Vyci0+Y3B1X2FmZmluaXR5KTsKKyAg
ICBpZiAoIHZjcHVfc2V0X2FmZmluaXR5KGN1cnIsIGNwdW1hc2tfb2Yod3F2LT53YWtldXBf
Y3B1KSkgKQorICAgIHsKKyAgICAgICAgZ2RwcmludGsoWEVOTE9HX0VSUiwgIlVuYWJsZSB0
byBzZXQgdmNwdSBhZmZpbml0eVxuIik7CisgICAgICAgIGRvbWFpbl9jcmFzaF9zeW5jaHJv
bm91cygpOworICAgIH0KKwogICAgIGFzbSB2b2xhdGlsZSAoCiAjaWZkZWYgQ09ORklHX1g4
Nl82NAogICAgICAgICAicHVzaCAlJXJheDsgcHVzaCAlJXJieDsgcHVzaCAlJXJjeDsgcHVz
aCAlJXJkeDsgcHVzaCAlJXJkaTsgIgpAQCAtMTQ0LDYgKzE1Niw3IEBAIHN0YXRpYyB2b2lk
IF9fcHJlcGFyZV90b193YWl0KHN0cnVjdCB3YWkKIHN0YXRpYyB2b2lkIF9fZmluaXNoX3dh
aXQoc3RydWN0IHdhaXRxdWV1ZV92Y3B1ICp3cXYpCiB7CiAgICAgd3F2LT5lc3AgPSBOVUxM
OworICAgICh2b2lkKXZjcHVfc2V0X2FmZmluaXR5KGN1cnJlbnQsICZ3cXYtPnNhdmVkX2Fm
ZmluaXR5KTsKIH0KIAogdm9pZCBjaGVja193YWtldXBfZnJvbV93YWl0KHZvaWQpCkBAIC0x
NTUsNiArMTY4LDIwIEBAIHZvaWQgY2hlY2tfd2FrZXVwX2Zyb21fd2FpdCh2b2lkKQogICAg
IGlmICggbGlrZWx5KHdxdi0+ZXNwID09IE5VTEwpICkKICAgICAgICAgcmV0dXJuOwogCisg
ICAgLyogQ2hlY2sgaWYgd2Ugd29rZSB1cCBvbiB0aGUgd3JvbmcgQ1BVLiAqLworICAgIGlm
ICggdW5saWtlbHkoc21wX3Byb2Nlc3Nvcl9pZCgpICE9IHdxdi0+d2FrZXVwX2NwdSkgKQor
ICAgIHsKKyAgICAgICAgLyogUmUtc2V0IFZDUFUgYWZmaW5pdHkgYW5kIHJlLWVudGVyIHRo
ZSBzY2hlZHVsZXIuICovCisgICAgICAgIHN0cnVjdCB2Y3B1ICpjdXJyID0gY3VycmVudDsK
KyAgICAgICAgY3B1bWFza19jb3B5KCZ3cXYtPnNhdmVkX2FmZmluaXR5LCBjdXJyLT5jcHVf
YWZmaW5pdHkpOworICAgICAgICBpZiAoIHZjcHVfc2V0X2FmZmluaXR5KGN1cnIsIGNwdW1h
c2tfb2Yod3F2LT53YWtldXBfY3B1KSkgKQorICAgICAgICB7CisgICAgICAgICAgICBnZHBy
aW50ayhYRU5MT0dfRVJSLCAiVW5hYmxlIHRvIHNldCB2Y3B1IGFmZmluaXR5XG4iKTsKKyAg
ICAgICAgICAgIGRvbWFpbl9jcmFzaF9zeW5jaHJvbm91cygpOworICAgICAgICB9CisgICAg
ICAgIHdhaXQoKTsgLyogdGFrZXMgdXMgYmFjayBpbnRvIHRoZSBzY2hlZHVsZXIgKi8KKyAg
ICB9CisKICAgICBhc20gdm9sYXRpbGUgKAogICAgICAgICAibW92ICUxLCUlIl9fT1Aic3A7
IHJlcCBtb3ZzYjsgam1wICooJSUiX19PUCJzcCkiCiAgICAgICAgIDogOiAiUyIgKHdxdi0+
c3RhY2spLCAiRCIgKHdxdi0+ZXNwKSwK
--B_3404927025_64467266
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--B_3404927025_64467266--




From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:04:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:04:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTJzP-00080j-1y; Wed, 23 Nov 2011 21:04:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTJzN-00080c-Vb
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:04:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322082227!4749120!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15517 invoked from network); 23 Nov 2011 21:03:47 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 21:03:47 -0000
Received: by bkbzt12 with SMTP id zt12so2768865bkb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 13:03:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=HeDAeB7+R1Dtl7sQpC2W4I7iHy461eJM/TscB/OPRqg=;
	b=a74S584awyk18fVYk9uf/7hJRp7edsqIu1oUOlQwpw6SfpfsHInH2gmHbw6JwxmL2n
	Vy9iC2zZbjBqBNkwi4bboHDHrucJ1ZPriae6OE/lp6H+tOdQU3FCNjjo/nrvaC/mcg1l
	4O6BomuoIKriNmXkiKGB8N2nETunezVAHLuyU=
Received: by 10.204.148.4 with SMTP id n4mr26088057bkv.42.1322082226933;
	Wed, 23 Nov 2011 13:03:46 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id hw14sm1045667bkc.16.2011.11.23.13.03.45
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 13:03:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 21:03:39 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF3102F.25730%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqFSPigRbmOh5ymkyxVkLvJHSMcgADjugi
In-Reply-To: <CAF2F84A.2571A%keir.xen@gmail.com>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3404927025_64467266"
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3404927025_64467266
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 23/11/2011 19:21, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 23/11/2011 18:31, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
>> On Wed, Nov 23, Keir Fraser wrote:
>> 
>>> We have quite a big waitqueue problem actually. The current scheme of
>>> per-cpu stacks doesn't work nicely, as the stack pointer will change if a
>>> vcpu goes to sleep and then wakes up on a different cpu. This really doesn't
>>> work nicely with preempted C code, which may implement frame pointers and/or
>>> arbitrarily take the address of on-stack variables. The result will be
>>> hideous cross-stack corruptions, as these frame pointers and cached
>>> addresses of automatic variables will reference the wrong cpu's stack!
>>> Fixing or detecting this in general is not possible afaics.
>> 
>> Yes, I was thinking about that wakeup on different cpu as well.
>> As a quick fix/hack, perhaps the scheduler could make sure the vcpu
>> wakes up on the same cpu?
> 
> Could save old affinity and then vcpu_set_affinity. That will have to do for
> now. Actually it should work okay as long as toolstack doesn't mess with
> affinity meanwhile. I'll sort out a patch for this.

Attached three patches for you to try. They apply in sequence.
00: A fixed version of "domain_crash on stack overflow"
01: Reorders prepare_to_wait so that the vcpu will always be on the
waitqueue on exit (even if it has just been woken).
02: Ensures the vcpu wakes up on the same cpu that it slept on.

We need all of these. Just need testing to make sure they aren't horribly
broken. You should be able to test multi-processor host again with these.

 -- Keir

>  -- Keir
> 
>> Olaf
> 
> 


--B_3404927025_64467266
Content-type: application/octet-stream; name="00-prep-to-wait-dom-crash"
Content-disposition: attachment;
	filename="00-prep-to-wait-dom-crash"
Content-transfer-encoding: base64


IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgODRiM2U0NmFhN2QyNGE0NjA1YzM2OTQw
NjA2ZTdkYTk2NzliMGU3ZgoKZGlmZiAtciA4NGIzZTQ2YWE3ZDIgeGVuL2NvbW1vbi93YWl0
LmMKLS0tIGEveGVuL2NvbW1vbi93YWl0LmMJV2VkIE5vdiAyMyAxMjowMzozNyAyMDExICsw
MDAwCisrKyBiL3hlbi9jb21tb24vd2FpdC5jCVdlZCBOb3YgMjMgMTk6NDM6MzUgMjAxMSAr
MDAwMApAQCAtMTA2LDEzICsxMDYsMTYgQEAgdm9pZCB3YWtlX3VwKHN0cnVjdCB3YWl0cXVl
dWVfaGVhZCAqd3EpCiBzdGF0aWMgdm9pZCBfX3ByZXBhcmVfdG9fd2FpdChzdHJ1Y3Qgd2Fp
dHF1ZXVlX3ZjcHUgKndxdikKIHsKICAgICBjaGFyICpjcHVfaW5mbyA9IChjaGFyICopZ2V0
X2NwdV9pbmZvKCk7CisKICAgICBhc20gdm9sYXRpbGUgKAogI2lmZGVmIENPTkZJR19YODZf
NjQKICAgICAgICAgInB1c2ggJSVyYXg7IHB1c2ggJSVyYng7IHB1c2ggJSVyY3g7IHB1c2gg
JSVyZHg7IHB1c2ggJSVyZGk7ICIKICAgICAgICAgInB1c2ggJSVyYnA7IHB1c2ggJSVyODsg
cHVzaCAlJXI5OyBwdXNoICUlcjEwOyBwdXNoICUlcjExOyAiCiAgICAgICAgICJwdXNoICUl
cjEyOyBwdXNoICUlcjEzOyBwdXNoICUlcjE0OyBwdXNoICUlcjE1OyBjYWxsIDFmOyAiCiAg
ICAgICAgICIxOiBtb3YgODAoJSVyc3ApLCUlcmRpOyBtb3YgOTYoJSVyc3ApLCUlcmN4OyBt
b3YgJSVyc3AsJSVyc2k7ICIKLSAgICAgICAgInN1YiAlJXJzaSwlJXJjeDsgcmVwIG1vdnNi
OyBtb3YgJSVyc3AsJSVyc2k7IHBvcCAlJXJheDsgIgorICAgICAgICAic3ViICUlcnNpLCUl
cmN4OyBjbXAgJTMsJSVyY3g7IGpiZSAyZjsgIgorICAgICAgICAieG9yICUlZXNpLCUlZXNp
OyBqbXAgM2Y7ICIKKyAgICAgICAgIjI6IHJlcCBtb3ZzYjsgbW92ICUlcnNwLCUlcnNpOyAz
OiBwb3AgJSVyYXg7ICIKICAgICAgICAgInBvcCAlJXIxNTsgcG9wICUlcjE0OyBwb3AgJSVy
MTM7IHBvcCAlJXIxMjsgIgogICAgICAgICAicG9wICUlcjExOyBwb3AgJSVyMTA7IHBvcCAl
JXI5OyBwb3AgJSVyODsgIgogICAgICAgICAicG9wICUlcmJwOyBwb3AgJSVyZGk7IHBvcCAl
JXJkeDsgcG9wICUlcmN4OyBwb3AgJSVyYng7IHBvcCAlJXJheCIKQEAgLTEyMCwxMyArMTIz
LDIwIEBAIHN0YXRpYyB2b2lkIF9fcHJlcGFyZV90b193YWl0KHN0cnVjdCB3YWkKICAgICAg
ICAgInB1c2ggJSVlYXg7IHB1c2ggJSVlYng7IHB1c2ggJSVlY3g7IHB1c2ggJSVlZHg7IHB1
c2ggJSVlZGk7ICIKICAgICAgICAgInB1c2ggJSVlYnA7IGNhbGwgMWY7ICIKICAgICAgICAg
IjE6IG1vdiA4KCUlZXNwKSwlJWVkaTsgbW92IDE2KCUlZXNwKSwlJWVjeDsgbW92ICUlZXNw
LCUlZXNpOyAiCi0gICAgICAgICJzdWIgJSVlc2ksJSVlY3g7IHJlcCBtb3ZzYjsgbW92ICUl
ZXNwLCUlZXNpOyBwb3AgJSVlYXg7ICIKKyAgICAgICAgInN1YiAlJWVzaSwlJWVjeDsgY21w
ICUzLCUlZWN4OyBqYmUgMmY7ICIKKyAgICAgICAgInhvciAlJWVzaSwlJWVzaTsgam1wIDNm
OyAiCisgICAgICAgICIyOiByZXAgbW92c2I7IG1vdiAlJWVzcCwlJWVzaTsgMzogcG9wICUl
ZWF4OyAiCiAgICAgICAgICJwb3AgJSVlYnA7IHBvcCAlJWVkaTsgcG9wICUlZWR4OyBwb3Ag
JSVlY3g7IHBvcCAlJWVieDsgcG9wICUlZWF4IgogI2VuZGlmCiAgICAgICAgIDogIj1TIiAo
d3F2LT5lc3ApCi0gICAgICAgIDogImMiIChjcHVfaW5mbyksICJEIiAod3F2LT5zdGFjaykK
KyAgICAgICAgOiAiYyIgKGNwdV9pbmZvKSwgIkQiICh3cXYtPnN0YWNrKSwgImkiIChQQUdF
X1NJWkUpCiAgICAgICAgIDogIm1lbW9yeSIgKTsKLSAgICBCVUdfT04oKGNwdV9pbmZvIC0g
KGNoYXIgKil3cXYtPmVzcCkgPiBQQUdFX1NJWkUpOworCisgICAgaWYgKCB1bmxpa2VseSh3
cXYtPmVzcCA9PSAwKSApCisgICAgeworICAgICAgICBnZHByaW50ayhYRU5MT0dfRVJSLCAi
U3RhY2sgdG9vIGxhcmdlIGluICVzXG4iLCBfX0ZVTkNUSU9OX18pOworICAgICAgICBkb21h
aW5fY3Jhc2hfc3luY2hyb25vdXMoKTsKKyAgICB9CiB9CiAKIHN0YXRpYyB2b2lkIF9fZmlu
aXNoX3dhaXQoc3RydWN0IHdhaXRxdWV1ZV92Y3B1ICp3cXYpCkBAIC0xNjIsNiArMTcyLDcg
QEAgdm9pZCBwcmVwYXJlX3RvX3dhaXQoc3RydWN0IHdhaXRxdWV1ZV9oZQogICAgIHN0cnVj
dCB2Y3B1ICpjdXJyID0gY3VycmVudDsKICAgICBzdHJ1Y3Qgd2FpdHF1ZXVlX3ZjcHUgKndx
diA9IGN1cnItPndhaXRxdWV1ZV92Y3B1OwogCisgICAgQVNTRVJUKCFpbl9hdG9taWMoKSk7
CiAgICAgQVNTRVJUKGxpc3RfZW1wdHkoJndxdi0+bGlzdCkpOwogCiAgICAgc3Bpbl9sb2Nr
KCZ3cS0+bG9jayk7Cg==
--B_3404927025_64467266
Content-type: application/octet-stream; name="01-prep-to-wait-reorder"
Content-disposition: attachment;
	filename="01-prep-to-wait-reorder"
Content-transfer-encoding: base64


IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgY2MwNTVkYWIzNjA2NTI5ZmNhYmMyODY4
NWM1YmYwZGViZGZjMjEzYwpkaWZmIC1yIGNjMDU1ZGFiMzYwNiAtciA4NDYyODI5MWU1ODUg
eGVuL2NvbW1vbi93YWl0LmMKLS0tIGEveGVuL2NvbW1vbi93YWl0LmMJV2VkIE5vdiAyMyAx
ODowMTo0NCAyMDExICswMDAwCisrKyBiL3hlbi9jb21tb24vd2FpdC5jCVdlZCBOb3YgMjMg
MTg6MDM6NTUgMjAxMSArMDAwMApAQCAtMTA3LDYgKzEwNyw4IEBAIHN0YXRpYyB2b2lkIF9f
cHJlcGFyZV90b193YWl0KHN0cnVjdCB3YWkKIHsKICAgICBjaGFyICpjcHVfaW5mbyA9IChj
aGFyICopZ2V0X2NwdV9pbmZvKCk7CiAKKyAgICBBU1NFUlQod3F2LT5lc3AgPT0gMCk7CisK
ICAgICBhc20gdm9sYXRpbGUgKAogI2lmZGVmIENPTkZJR19YODZfNjQKICAgICAgICAgInB1
c2ggJSVyYXg7IHB1c2ggJSVyYng7IHB1c2ggJSVyY3g7IHB1c2ggJSVyZHg7IHB1c2ggJSVy
ZGk7ICIKQEAgLTE3MywxNCArMTc1LDEzIEBAIHZvaWQgcHJlcGFyZV90b193YWl0KHN0cnVj
dCB3YWl0cXVldWVfaGUKICAgICBzdHJ1Y3Qgd2FpdHF1ZXVlX3ZjcHUgKndxdiA9IGN1cnIt
PndhaXRxdWV1ZV92Y3B1OwogCiAgICAgQVNTRVJUKCFpbl9hdG9taWMoKSk7CisgICAgX19w
cmVwYXJlX3RvX3dhaXQod3F2KTsKKwogICAgIEFTU0VSVChsaXN0X2VtcHR5KCZ3cXYtPmxp
c3QpKTsKLQogICAgIHNwaW5fbG9jaygmd3EtPmxvY2spOwogICAgIGxpc3RfYWRkX3RhaWwo
Jndxdi0+bGlzdCwgJndxLT5saXN0KTsKICAgICB2Y3B1X3BhdXNlX25vc3luYyhjdXJyKTsK
ICAgICBzcGluX3VubG9jaygmd3EtPmxvY2spOwotCi0gICAgX19wcmVwYXJlX3RvX3dhaXQo
d3F2KTsKIH0KIAogdm9pZCBmaW5pc2hfd2FpdChzdHJ1Y3Qgd2FpdHF1ZXVlX2hlYWQgKndx
KQo=
--B_3404927025_64467266
Content-type: application/octet-stream; name="02-waitq-set-vcpu-affinity"
Content-disposition: attachment;
	filename="02-waitq-set-vcpu-affinity"
Content-transfer-encoding: base64


IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBQYXJlbnQgMThhMWYzNWFmMWM1NWRkYmQ4N2JkMzlh
OTMxN2MzOGZmYTJhMWY3YQpkaWZmIC1yIDE4YTFmMzVhZjFjNSAtciAwZjIyMDY0ZDk4YWUg
eGVuL2NvbW1vbi93YWl0LmMKLS0tIGEveGVuL2NvbW1vbi93YWl0LmMJV2VkIE5vdiAyMyAx
OTo0Mzo0NiAyMDExICswMDAwCisrKyBiL3hlbi9jb21tb24vd2FpdC5jCVdlZCBOb3YgMjMg
MjA6MDI6MDUgMjAxMSArMDAwMApAQCAtMzQsNiArMzQsOCBAQCBzdHJ1Y3Qgd2FpdHF1ZXVl
X3ZjcHUgewogICAgICAqLwogICAgIHZvaWQgKmVzcDsKICAgICBjaGFyICpzdGFjazsKKyAg
ICBjcHVtYXNrX3Qgc2F2ZWRfYWZmaW5pdHk7CisgICAgdW5zaWduZWQgaW50IHdha2V1cF9j
cHU7CiAjZW5kaWYKIH07CiAKQEAgLTEwNiw5ICsxMDgsMTkgQEAgdm9pZCB3YWtlX3VwKHN0
cnVjdCB3YWl0cXVldWVfaGVhZCAqd3EpCiBzdGF0aWMgdm9pZCBfX3ByZXBhcmVfdG9fd2Fp
dChzdHJ1Y3Qgd2FpdHF1ZXVlX3ZjcHUgKndxdikKIHsKICAgICBjaGFyICpjcHVfaW5mbyA9
IChjaGFyICopZ2V0X2NwdV9pbmZvKCk7CisgICAgc3RydWN0IHZjcHUgKmN1cnIgPSBjdXJy
ZW50OwogCiAgICAgQVNTRVJUKHdxdi0+ZXNwID09IDApOwogCisgICAgLyogU2F2ZSBjdXJy
ZW50IFZDUFUgYWZmaW5pdHk7IGZvcmNlIHdha2V1cCBvbiAqdGhpcyogQ1BVIG9ubHkuICov
CisgICAgd3F2LT53YWtldXBfY3B1ID0gc21wX3Byb2Nlc3Nvcl9pZCgpOworICAgIGNwdW1h
c2tfY29weSgmd3F2LT5zYXZlZF9hZmZpbml0eSwgY3Vyci0+Y3B1X2FmZmluaXR5KTsKKyAg
ICBpZiAoIHZjcHVfc2V0X2FmZmluaXR5KGN1cnIsIGNwdW1hc2tfb2Yod3F2LT53YWtldXBf
Y3B1KSkgKQorICAgIHsKKyAgICAgICAgZ2RwcmludGsoWEVOTE9HX0VSUiwgIlVuYWJsZSB0
byBzZXQgdmNwdSBhZmZpbml0eVxuIik7CisgICAgICAgIGRvbWFpbl9jcmFzaF9zeW5jaHJv
bm91cygpOworICAgIH0KKwogICAgIGFzbSB2b2xhdGlsZSAoCiAjaWZkZWYgQ09ORklHX1g4
Nl82NAogICAgICAgICAicHVzaCAlJXJheDsgcHVzaCAlJXJieDsgcHVzaCAlJXJjeDsgcHVz
aCAlJXJkeDsgcHVzaCAlJXJkaTsgIgpAQCAtMTQ0LDYgKzE1Niw3IEBAIHN0YXRpYyB2b2lk
IF9fcHJlcGFyZV90b193YWl0KHN0cnVjdCB3YWkKIHN0YXRpYyB2b2lkIF9fZmluaXNoX3dh
aXQoc3RydWN0IHdhaXRxdWV1ZV92Y3B1ICp3cXYpCiB7CiAgICAgd3F2LT5lc3AgPSBOVUxM
OworICAgICh2b2lkKXZjcHVfc2V0X2FmZmluaXR5KGN1cnJlbnQsICZ3cXYtPnNhdmVkX2Fm
ZmluaXR5KTsKIH0KIAogdm9pZCBjaGVja193YWtldXBfZnJvbV93YWl0KHZvaWQpCkBAIC0x
NTUsNiArMTY4LDIwIEBAIHZvaWQgY2hlY2tfd2FrZXVwX2Zyb21fd2FpdCh2b2lkKQogICAg
IGlmICggbGlrZWx5KHdxdi0+ZXNwID09IE5VTEwpICkKICAgICAgICAgcmV0dXJuOwogCisg
ICAgLyogQ2hlY2sgaWYgd2Ugd29rZSB1cCBvbiB0aGUgd3JvbmcgQ1BVLiAqLworICAgIGlm
ICggdW5saWtlbHkoc21wX3Byb2Nlc3Nvcl9pZCgpICE9IHdxdi0+d2FrZXVwX2NwdSkgKQor
ICAgIHsKKyAgICAgICAgLyogUmUtc2V0IFZDUFUgYWZmaW5pdHkgYW5kIHJlLWVudGVyIHRo
ZSBzY2hlZHVsZXIuICovCisgICAgICAgIHN0cnVjdCB2Y3B1ICpjdXJyID0gY3VycmVudDsK
KyAgICAgICAgY3B1bWFza19jb3B5KCZ3cXYtPnNhdmVkX2FmZmluaXR5LCBjdXJyLT5jcHVf
YWZmaW5pdHkpOworICAgICAgICBpZiAoIHZjcHVfc2V0X2FmZmluaXR5KGN1cnIsIGNwdW1h
c2tfb2Yod3F2LT53YWtldXBfY3B1KSkgKQorICAgICAgICB7CisgICAgICAgICAgICBnZHBy
aW50ayhYRU5MT0dfRVJSLCAiVW5hYmxlIHRvIHNldCB2Y3B1IGFmZmluaXR5XG4iKTsKKyAg
ICAgICAgICAgIGRvbWFpbl9jcmFzaF9zeW5jaHJvbm91cygpOworICAgICAgICB9CisgICAg
ICAgIHdhaXQoKTsgLyogdGFrZXMgdXMgYmFjayBpbnRvIHRoZSBzY2hlZHVsZXIgKi8KKyAg
ICB9CisKICAgICBhc20gdm9sYXRpbGUgKAogICAgICAgICAibW92ICUxLCUlIl9fT1Aic3A7
IHJlcCBtb3ZzYjsgam1wICooJSUiX19PUCJzcCkiCiAgICAgICAgIDogOiAiUyIgKHdxdi0+
c3RhY2spLCAiRCIgKHdxdi0+ZXNwKSwK
--B_3404927025_64467266
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--B_3404927025_64467266--




From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK6z-0008Gv-Cm; Wed, 23 Nov 2011 21:12:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK6x-0008G7-Jw
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322082696!4346991!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4138 invoked from network); 23 Nov 2011 21:11:36 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-15.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 21:11:36 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 3F46B30007B;
	Wed, 23 Nov 2011 13:11:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=sEeKh47BmcvJWwtNOf4262ROLX7uB0g/zBA1ylYpFLdH
	BQi1hg/DBqZtVyR6xJn6TupZnmvdAVWwhVgviZuPmmpf2TN45W3BvCGJTDClYVHx
	skAlXzpHEwP8nRPaY8Q2lEpOak3DjtHjnxaUdE7Q/XQXwCb3mkdueJslhZkWBeU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=ZEO0rAFVcWB2/qyKBBOQS5n6So8=; b=e39Bu/KrxTN
	MGzFmPLYC/LxXj3VZyRRLzbLOOz3yxSjILLKrBGv34N5sHK3sYA8AmqkzugeYfgL
	KknHw/NX/DiPebhmYI1fHD+kG4rJLBLhY5mZB+MIGF0OS5YGdmLiOogb+mEZKPT6
	1/2jqIIw8me6d0aBWQtVBNOgidaSjh0c=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 83B7030006C; 
	Wed, 23 Nov 2011 13:11:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 00c1834b28829f26671b1045f3767a9654de57f5
Message-Id: <00c1834b28829f26671b.1322082668@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:08 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 01 of 14] The PoD code may split a 1GB superpage
 in a potentially unlocked way
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m-pod.c |  1 -
 xen/arch/x86/mm/p2m-pt.c  |  9 ++++++---
 2 files changed, 6 insertions(+), 4 deletions(-)


The path p2m-lookup -> p2m-pt->get_entry -> 1GB PoD superpage ->
pod_demand_populate ends in the pod code performing a p2m_set_entry with
no locks held (in order to split the 1GB superpage into 512 2MB ones)

Further, it calls p2m_unlock after that, which will break the spinlock.

This patch attempts to fix that.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 909f13636400 -r 00c1834b2882 xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -987,7 +987,6 @@ p2m_pod_demand_populate(struct p2m_domai
         set_p2m_entry(p2m, gfn_aligned, _mfn(0), PAGE_ORDER_2M,
                       p2m_populate_on_demand, p2m->default_access);
         audit_p2m(p2m, 1);
-        p2m_unlock(p2m);
         return 0;
     }
 
diff -r 909f13636400 -r 00c1834b2882 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -542,10 +542,11 @@ pod_retry_l3:
             /* The read has succeeded, so we know that mapping exists */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
+                if ( !p2m_pod_check_and_populate(p2m, gfn,
+                                      (l1_pgentry_t *) &l3e, PAGE_ORDER_1G, q) )
                     goto pod_retry_l3;
                 p2mt = p2m_invalid;
-                printk("%s: Allocate 1GB failed!\n", __func__);
+                gdprintk(XENLOG_ERR, "%s: Allocate 1GB failed!\n", __func__);
                 goto out;
             }
             else
@@ -743,8 +744,10 @@ pod_retry_l3:
             {
                 if ( q != p2m_query )
                 {
-                    if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
+                    if ( !p2m_pod_check_and_populate(p2m, gfn,
+                                      (l1_pgentry_t *) l3e, PAGE_ORDER_1G, q) )
                         goto pod_retry_l3;
+                    gdprintk(XENLOG_ERR, "%s: Allocate 1GB failed!\n", __func__);
                 }
                 else
                     *t = p2m_populate_on_demand;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK74-0008Iv-CD; Wed, 23 Nov 2011 21:12:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK72-0008GT-Sp
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322082701!4346995!2
X-Originating-IP: [208.97.132.74]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4205 invoked from network); 23 Nov 2011 21:11:42 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.74) by server-15.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 21:11:42 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 35128300072;
	Wed, 23 Nov 2011 13:11:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=oni0LEC8FnDqpvmwBCER3BkvrkZYF+43CyvmoG6nBc/n
	u9SbGuWoM9r5y3WMDX7sWBKw+QNWhSoUcgH6QFGKw+8kMRmF0AxyQD5C2Nl/msC4
	YlsYAg4/XibDuOPpU4rz4cBdxrNjsOtYvxJE/CrnzKJbg1WFl6G1J6SoEgDcTXQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=8JxnAhTpqkR+zZRr0MK/xq6/KSc=; b=Rs76qppsDNG
	ZYdtPKyR038DDTLW0jG439qkAqr+bJt6NcBoblByetEaTJgKFPM6zM0kfuLUSkMK
	u6DmnXpfWuA3jaimy3L2xzJUgrzpzT4tPsQ56no/q7licDu16eVv1Ddj3vn95uVT
	BXJBUjeCyl7R7YRBLgJgia31NBOZCU9o=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 669E930006C; 
	Wed, 23 Nov 2011 13:11:41 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 25d27decfdccbb221b2f4dd236bacf390c72df81
Message-Id: <25d27decfdccbb221b2f.1322082674@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:14 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 07 of 14] Trivial fix for rc val in hap track
	dirty vram
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/hap/hap.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r e22610ef339a -r 25d27decfdcc xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -141,7 +141,7 @@ int hap_track_dirty_vram(struct domain *
         }
         else if ( !paging_mode_log_dirty(d) && !dirty_vram )
         {
-            rc -ENOMEM;
+            rc = -ENOMEM;
             if ( (dirty_vram = xmalloc(struct sh_dirty_vram)) == NULL )
                 goto param_fail;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK74-0008Iv-CD; Wed, 23 Nov 2011 21:12:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK72-0008GT-Sp
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322082701!4346995!2
X-Originating-IP: [208.97.132.74]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4205 invoked from network); 23 Nov 2011 21:11:42 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.74) by server-15.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 21:11:42 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 35128300072;
	Wed, 23 Nov 2011 13:11:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=oni0LEC8FnDqpvmwBCER3BkvrkZYF+43CyvmoG6nBc/n
	u9SbGuWoM9r5y3WMDX7sWBKw+QNWhSoUcgH6QFGKw+8kMRmF0AxyQD5C2Nl/msC4
	YlsYAg4/XibDuOPpU4rz4cBdxrNjsOtYvxJE/CrnzKJbg1WFl6G1J6SoEgDcTXQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=8JxnAhTpqkR+zZRr0MK/xq6/KSc=; b=Rs76qppsDNG
	ZYdtPKyR038DDTLW0jG439qkAqr+bJt6NcBoblByetEaTJgKFPM6zM0kfuLUSkMK
	u6DmnXpfWuA3jaimy3L2xzJUgrzpzT4tPsQ56no/q7licDu16eVv1Ddj3vn95uVT
	BXJBUjeCyl7R7YRBLgJgia31NBOZCU9o=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 669E930006C; 
	Wed, 23 Nov 2011 13:11:41 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 25d27decfdccbb221b2f4dd236bacf390c72df81
Message-Id: <25d27decfdccbb221b2f.1322082674@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:14 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 07 of 14] Trivial fix for rc val in hap track
	dirty vram
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/hap/hap.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r e22610ef339a -r 25d27decfdcc xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -141,7 +141,7 @@ int hap_track_dirty_vram(struct domain *
         }
         else if ( !paging_mode_log_dirty(d) && !dirty_vram )
         {
-            rc -ENOMEM;
+            rc = -ENOMEM;
             if ( (dirty_vram = xmalloc(struct sh_dirty_vram)) == NULL )
                 goto param_fail;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK6z-0008HI-V1; Wed, 23 Nov 2011 21:12:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK6z-0008GD-A2
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322082698!4744639!1
X-Originating-IP: [208.97.132.207]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29114 invoked from network); 23 Nov 2011 21:11:38 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.207) by server-7.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 21:11:38 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 4CC4530008D;
	Wed, 23 Nov 2011 13:11:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=hXA3L7uQFZYo2vLUKUlH9rl3u6y1EQ7+7EnkT/dqkbV5
	ecCOMmvOtpcL+5TDyCg6FbOKSCV+PFgymOQJwBSUEb25c6VNRbjVjkyO6AN2GTZE
	JSrHeezxJmQz9iD9I2DdPF6JI+x7RzqszRIGqUfL4qmfeOvFC6SkiC9adtIXnbQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=ZC9UgSGMvqFduNxIXizD02hMlNE=; b=Z67aZRJ62BV
	MUQ4X+DDiX38owY4dI+S24htl8N8Q6S50N0dNt1KyZMv4mqo7DkTBdw4mVVMyknH
	JljDsTvHWfQ63IAdLkQ9gnyo5idD2ysTm8krxxgd9LiBAex8LJJncouq/uhWx5kk
	TxG9efdZGXR1Z2JmXcyct4Fs5IZkvJQM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 74B6930006C; 
	Wed, 23 Nov 2011 13:11:37 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 58eae300fa634451839f22c74db9d196805bd8d6
Message-Id: <58eae300fa634451839f.1322082670@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:10 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 03 of 14] Make HAP log dirty disable return the
	correct rc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/hap/hap.c |  2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)


Disabling log dirty mode in HAP always returns -EINVAL. Make it
return the correct rc on success.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b85ecdc5aa83 -r 58eae300fa63 xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -709,6 +709,8 @@ int hap_domctl(struct domain *d, xen_dom
         return rc;
     case XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION:
         sc->mb = hap_get_allocation(d);
+        /* Fall through */
+    case XEN_DOMCTL_SHADOW_OP_OFF:
         return 0;
     default:
         HAP_ERROR("Bad hap domctl op %u\n", sc->op);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK6z-0008Gv-Cm; Wed, 23 Nov 2011 21:12:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK6x-0008G7-Jw
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322082696!4346991!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4138 invoked from network); 23 Nov 2011 21:11:36 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-15.tower-182.messagelabs.com with SMTP;
	23 Nov 2011 21:11:36 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 3F46B30007B;
	Wed, 23 Nov 2011 13:11:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=sEeKh47BmcvJWwtNOf4262ROLX7uB0g/zBA1ylYpFLdH
	BQi1hg/DBqZtVyR6xJn6TupZnmvdAVWwhVgviZuPmmpf2TN45W3BvCGJTDClYVHx
	skAlXzpHEwP8nRPaY8Q2lEpOak3DjtHjnxaUdE7Q/XQXwCb3mkdueJslhZkWBeU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=ZEO0rAFVcWB2/qyKBBOQS5n6So8=; b=e39Bu/KrxTN
	MGzFmPLYC/LxXj3VZyRRLzbLOOz3yxSjILLKrBGv34N5sHK3sYA8AmqkzugeYfgL
	KknHw/NX/DiPebhmYI1fHD+kG4rJLBLhY5mZB+MIGF0OS5YGdmLiOogb+mEZKPT6
	1/2jqIIw8me6d0aBWQtVBNOgidaSjh0c=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 83B7030006C; 
	Wed, 23 Nov 2011 13:11:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 00c1834b28829f26671b1045f3767a9654de57f5
Message-Id: <00c1834b28829f26671b.1322082668@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:08 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 01 of 14] The PoD code may split a 1GB superpage
 in a potentially unlocked way
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m-pod.c |  1 -
 xen/arch/x86/mm/p2m-pt.c  |  9 ++++++---
 2 files changed, 6 insertions(+), 4 deletions(-)


The path p2m-lookup -> p2m-pt->get_entry -> 1GB PoD superpage ->
pod_demand_populate ends in the pod code performing a p2m_set_entry with
no locks held (in order to split the 1GB superpage into 512 2MB ones)

Further, it calls p2m_unlock after that, which will break the spinlock.

This patch attempts to fix that.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 909f13636400 -r 00c1834b2882 xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -987,7 +987,6 @@ p2m_pod_demand_populate(struct p2m_domai
         set_p2m_entry(p2m, gfn_aligned, _mfn(0), PAGE_ORDER_2M,
                       p2m_populate_on_demand, p2m->default_access);
         audit_p2m(p2m, 1);
-        p2m_unlock(p2m);
         return 0;
     }
 
diff -r 909f13636400 -r 00c1834b2882 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -542,10 +542,11 @@ pod_retry_l3:
             /* The read has succeeded, so we know that mapping exists */
             if ( q != p2m_query )
             {
-                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
+                if ( !p2m_pod_check_and_populate(p2m, gfn,
+                                      (l1_pgentry_t *) &l3e, PAGE_ORDER_1G, q) )
                     goto pod_retry_l3;
                 p2mt = p2m_invalid;
-                printk("%s: Allocate 1GB failed!\n", __func__);
+                gdprintk(XENLOG_ERR, "%s: Allocate 1GB failed!\n", __func__);
                 goto out;
             }
             else
@@ -743,8 +744,10 @@ pod_retry_l3:
             {
                 if ( q != p2m_query )
                 {
-                    if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
+                    if ( !p2m_pod_check_and_populate(p2m, gfn,
+                                      (l1_pgentry_t *) l3e, PAGE_ORDER_1G, q) )
                         goto pod_retry_l3;
+                    gdprintk(XENLOG_ERR, "%s: Allocate 1GB failed!\n", __func__);
                 }
                 else
                     *t = p2m_populate_on_demand;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK6z-0008HI-V1; Wed, 23 Nov 2011 21:12:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK6z-0008GD-A2
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322082698!4744639!1
X-Originating-IP: [208.97.132.207]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29114 invoked from network); 23 Nov 2011 21:11:38 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.207) by server-7.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 21:11:38 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 4CC4530008D;
	Wed, 23 Nov 2011 13:11:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=hXA3L7uQFZYo2vLUKUlH9rl3u6y1EQ7+7EnkT/dqkbV5
	ecCOMmvOtpcL+5TDyCg6FbOKSCV+PFgymOQJwBSUEb25c6VNRbjVjkyO6AN2GTZE
	JSrHeezxJmQz9iD9I2DdPF6JI+x7RzqszRIGqUfL4qmfeOvFC6SkiC9adtIXnbQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=ZC9UgSGMvqFduNxIXizD02hMlNE=; b=Z67aZRJ62BV
	MUQ4X+DDiX38owY4dI+S24htl8N8Q6S50N0dNt1KyZMv4mqo7DkTBdw4mVVMyknH
	JljDsTvHWfQ63IAdLkQ9gnyo5idD2ysTm8krxxgd9LiBAex8LJJncouq/uhWx5kk
	TxG9efdZGXR1Z2JmXcyct4Fs5IZkvJQM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 74B6930006C; 
	Wed, 23 Nov 2011 13:11:37 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 58eae300fa634451839f22c74db9d196805bd8d6
Message-Id: <58eae300fa634451839f.1322082670@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:10 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 03 of 14] Make HAP log dirty disable return the
	correct rc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/hap/hap.c |  2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)


Disabling log dirty mode in HAP always returns -EINVAL. Make it
return the correct rc on success.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b85ecdc5aa83 -r 58eae300fa63 xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -709,6 +709,8 @@ int hap_domctl(struct domain *d, xen_dom
         return rc;
     case XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION:
         sc->mb = hap_get_allocation(d);
+        /* Fall through */
+    case XEN_DOMCTL_SHADOW_OP_OFF:
         return 0;
     default:
         HAP_ERROR("Bad hap domctl op %u\n", sc->op);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK6y-0008Gm-VU; Wed, 23 Nov 2011 21:12:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK6x-0008GR-Ds
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322082672!49682455!1
X-Originating-IP: [208.97.132.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25479 invoked from network); 23 Nov 2011 21:11:13 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.81) by server-4.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 21:11:13 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 2C736300080;
	Wed, 23 Nov 2011 13:11:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=gyxsP2nLYSOb4BAiuz3tlO1IRGaylTHY2OWxFnQjqpp+
	RKKraJUEigLCahGaDlbJvfAW6/whemRqqXT5AuTnUwn3f9ayFE0QPUVW+RxpWruu
	iV+yyXE0dxh7b12ls4y+XJc9Ef0at/pluM1jM6QwJlggOfWyLYf1bdTXcF/aprY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=4FCXQP8v4EVfyn4DmeU5ZzjHULc=; b=qIKHNu8GM5/
	kAAQVEO1xyaGnt5JRAqXea4NYt/xaQGAdp4mhwZqp4IbIF25o8aMSLkv83Lllasi
	Ziw1aag68m2D9vLgRUmKvLu1ThvMlQCxQhFeHCC1wIHMWN3yiOfqElkq4qqfNkU+
	iFBxFGFhtusiw2SmZne8CvxMTr/qK24M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 6468730007B; 
	Wed, 23 Nov 2011 13:11:40 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e22610ef339ab7ddd2f663c40fb3c6cdcfdf6c46
Message-Id: <e22610ef339ab7ddd2f6.1322082673@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:13 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 06 of 14] Don't lose track of the log dirty
	bitmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/hap/hap.c |  15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)


hap_log_dirty_init unconditionally sets the top of the log dirty
bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
then leaked, and the host crashes on an ASSERT when the domain is
cleaned up. Fixing it here.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r e8f0709af2b7 -r e22610ef339a xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -224,11 +224,18 @@ static void hap_clean_dirty_bitmap(struc
 void hap_logdirty_init(struct domain *d)
 {
     struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-    if ( paging_mode_log_dirty(d) && dirty_vram )
+    if ( paging_mode_log_dirty(d) )
     {
-        paging_log_dirty_disable(d);
-        xfree(dirty_vram);
-        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
+        if ( dirty_vram )
+        {
+            paging_log_dirty_disable(d);
+            xfree(dirty_vram);
+            dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
+        } else {
+            /* We still need to clean up the bitmap, because
+             * init below will overwrite it */
+            paging_free_log_dirty_bitmap(d);
+        }
     }
 
     /* Reinitialize logdirty mechanism */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK6y-0008Ge-ID; Wed, 23 Nov 2011 21:12:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK6w-0008G6-BI
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322082695!4744634!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29083 invoked from network); 23 Nov 2011 21:11:36 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-7.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 21:11:36 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 535C7300072;
	Wed, 23 Nov 2011 13:11:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=NM4enZs6OSK7fsBQ7uyOiU
	iO4J7aN0W31MRVCHdi/gUDH9WtPAQ+MJZFd0nOxePgRRKAqbQyOrLurCiKzsLVOY
	HqNbLSXhuLQ/u3I3HrNEMvszXK65+M8Y8qh5iEi8cTADnf/cmAMhcbx0COF1SNBG
	dwxBLqQapAyherC499kKw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=uNRRsd/ZWpwl
	it6h0UfAeQWiA5Q=; b=G6u55/gRUvAWf177f3kPBqjEn4cxecOYPEjmiI0rmQYq
	80t+mqSKkSruz8mfZ+yz9hNHOijmF+B/GEyNUgge+nZX2fCrx311MduEoeCXkXl/
	IiWKcm7k/EuJS/cWLYTsbYO4Wte0u/foinTAbkrQJd2dk/44sqt9Ybw/1g5bVXs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 71D3F30006C; 
	Wed, 23 Nov 2011 13:11:34 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 00 of 14] MM Fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series includes a number of bug fixes, targetting 
primarily the mm layer. Many of these fixes also lay groundwork
for future patches.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/p2m-pod.c          |   1 -
 xen/arch/x86/mm/p2m-pt.c           |   9 +++-
 xen/arch/x86/mm/p2m.c              |   5 +-
 xen/arch/x86/mm/hap/hap.c          |   2 +
 tools/libxc/xc_domain.c            |   2 +
 xen/arch/x86/mm/shadow/common.c    |   4 +-
 xen/arch/x86/mm/hap/hap.c          |  15 ++++++--
 xen/arch/x86/mm/hap/hap.c          |   2 +-
 xen/drivers/char/ns16550.c         |   2 +-
 xen/arch/x86/mm/p2m.c              |   4 +-
 xen/include/asm-x86/p2m.h          |   3 +-
 xen/arch/x86/hvm/hvm.c             |  10 ++++-
 xen/arch/x86/mm.c                  |   5 ++-
 xen/arch/x86/hvm/hvm.c             |  69 ++++++++++++++++++++++++-------------
 xen/arch/x86/hvm/nestedhvm.c       |   4 +-
 xen/arch/x86/hvm/svm/nestedsvm.c   |  23 ++++++------
 xen/arch/x86/hvm/vmx/vvmx.c        |  36 +++++++++++--------
 xen/include/asm-x86/hvm/hvm.h      |   9 +++-
 xen/include/asm-x86/hvm/vcpu.h     |   1 +
 xen/include/asm-x86/hvm/vmx/vvmx.h |   1 +
 xen/arch/x86/mm/guest_walk.c       |  16 ++++++--
 xen/common/grant_table.c           |  69 ++++++++++++++++++++-----------------
 22 files changed, 182 insertions(+), 110 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK76-0008Ke-Om; Wed, 23 Nov 2011 21:12:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK75-0008HC-8y
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322082704!2719914!1
X-Originating-IP: [208.97.132.145]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17636 invoked from network); 23 Nov 2011 21:11:44 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-3.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 21:11:44 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id EE69230008F;
	Wed, 23 Nov 2011 13:11:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=eNuCHmuPmdSgeA+ZLvAzYIg76hFm2Ui6M/eEbvSpZkNh
	W0n5frtPT6PJdW+aC2A1vifND6dx3S65E5/UjR/k6jfhi+ABSkqDXKa3wCLdko1B
	MTnmKzjMBHdfUo3/y1Yw/bgBQecYq3XRL0wCyPuDaLmacCr7jWWHXVI5wml6nK4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=OTXRTHzGNzhBhqAhplrQ6KTuOQo=; b=BatrAGS2tj3
	v6Zt+5F2PnEMqyF14TwPEwcMuRnRc3p2+AA4NTq9+XvdTSOmzHoKmkcc0xXxiOij
	DfnLcY8nioEharYJyLkXkO7EIDJoa2E42AP93lMMYraN/D0TAwXmQ7SfZi88HnaD
	dY8rm+qNHWXEBTqAeQBUL+VIZP7QyQPk=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 3EA2130007B; 
	Wed, 23 Nov 2011 13:11:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 76802e649c2cb95c564cc19119d934a6e6b4b6e6
Message-Id: <76802e649c2cb95c564c.1322082676@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:16 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 09 of 14] Allow log dirty mode to be used in
 conjunction with paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c     |  4 +++-
 xen/include/asm-x86/p2m.h |  3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)


Allow pages typed log dirty to be paged out, and the proper type to
restored when paging pages back in.

Signed-off-by: Andres lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 7e8211d0f41d -r 76802e649c2c xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1061,7 +1061,9 @@ void p2m_mem_paging_resume(struct domain
         if ( mfn_valid(mfn) && 
              (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
         {
-            set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, p2m_ram_rw, a);
+            set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
+                            paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, 
+                            a);
             set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
             audit_p2m(p2m, 1);
         }
diff -r 7e8211d0f41d -r 76802e649c2c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -150,7 +150,8 @@ typedef enum {
 #define P2M_MAGIC_TYPES (p2m_to_mask(p2m_populate_on_demand))
 
 /* Pageable types */
-#define P2M_PAGEABLE_TYPES (p2m_to_mask(p2m_ram_rw))
+#define P2M_PAGEABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
+                            | p2m_to_mask(p2m_ram_logdirty) )
 
 #define P2M_PAGING_TYPES (p2m_to_mask(p2m_ram_paging_out)        \
                           | p2m_to_mask(p2m_ram_paged)           \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK6y-0008Gm-VU; Wed, 23 Nov 2011 21:12:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK6x-0008GR-Ds
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322082672!49682455!1
X-Originating-IP: [208.97.132.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25479 invoked from network); 23 Nov 2011 21:11:13 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.81) by server-4.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 21:11:13 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 2C736300080;
	Wed, 23 Nov 2011 13:11:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=gyxsP2nLYSOb4BAiuz3tlO1IRGaylTHY2OWxFnQjqpp+
	RKKraJUEigLCahGaDlbJvfAW6/whemRqqXT5AuTnUwn3f9ayFE0QPUVW+RxpWruu
	iV+yyXE0dxh7b12ls4y+XJc9Ef0at/pluM1jM6QwJlggOfWyLYf1bdTXcF/aprY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=4FCXQP8v4EVfyn4DmeU5ZzjHULc=; b=qIKHNu8GM5/
	kAAQVEO1xyaGnt5JRAqXea4NYt/xaQGAdp4mhwZqp4IbIF25o8aMSLkv83Lllasi
	Ziw1aag68m2D9vLgRUmKvLu1ThvMlQCxQhFeHCC1wIHMWN3yiOfqElkq4qqfNkU+
	iFBxFGFhtusiw2SmZne8CvxMTr/qK24M=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 6468730007B; 
	Wed, 23 Nov 2011 13:11:40 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e22610ef339ab7ddd2f663c40fb3c6cdcfdf6c46
Message-Id: <e22610ef339ab7ddd2f6.1322082673@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:13 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 06 of 14] Don't lose track of the log dirty
	bitmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/hap/hap.c |  15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)


hap_log_dirty_init unconditionally sets the top of the log dirty
bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
then leaked, and the host crashes on an ASSERT when the domain is
cleaned up. Fixing it here.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r e8f0709af2b7 -r e22610ef339a xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -224,11 +224,18 @@ static void hap_clean_dirty_bitmap(struc
 void hap_logdirty_init(struct domain *d)
 {
     struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
-    if ( paging_mode_log_dirty(d) && dirty_vram )
+    if ( paging_mode_log_dirty(d) )
     {
-        paging_log_dirty_disable(d);
-        xfree(dirty_vram);
-        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
+        if ( dirty_vram )
+        {
+            paging_log_dirty_disable(d);
+            xfree(dirty_vram);
+            dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
+        } else {
+            /* We still need to clean up the bitmap, because
+             * init below will overwrite it */
+            paging_free_log_dirty_bitmap(d);
+        }
     }
 
     /* Reinitialize logdirty mechanism */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK78-0008Li-74; Wed, 23 Nov 2011 21:12:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK76-0008HY-AX
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322082704!4744876!2
X-Originating-IP: [208.97.132.83]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24910 invoked from network); 23 Nov 2011 21:11:46 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-13.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 21:11:46 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id C502C30007B;
	Wed, 23 Nov 2011 13:11:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vO57jr3VaoMjN4TasOorutA5gYqfpxvtEQHzhBCOqJgd
	4oIseDJVztqceBU8/fdZo1IvnPWmUGlE81Cr+uXUmVrqP8iQMyygSjlJnzelK1YJ
	kJPWQg+C9u/uEFVEdqtapOW9VGmw8klPA4MCTLttcjtkDqPgHaEYGHDljBQ+YwA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=D/VenX4Rkx3h8Ex84OVEajtSKk4=; b=O34W8wYerw8
	dlYpHfd9y9eLTcJ8b2Mv/r2/sxgtHraX2NDK0UkyVW18VKsdJWSXWNalySmT/X1F
	+Wo6p6pZ59ZzvCwle96q3NSEmADsANej4WlQDAYGMqR4WhahrbNzZwRHbfSunch7
	oBsfUKcCus3Cm4/NpIap/ERJnND0YdF0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 180FD300080; 
	Wed, 23 Nov 2011 13:11:45 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a64f63ecfc57ed8d5200b9983d00a9f42357e3b0
Message-Id: <a64f63ecfc57ed8d5200.1322082678@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:18 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 11 of 14] ASSERT we are putting the right gfn in
 the XNEMAPSPACE_gmfn* cases
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c |  5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 667e53a7ad34 -r a64f63ecfc57 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4773,13 +4773,16 @@ static int xenmem_add_to_physmap_once(
     /* Unmap from old location, if any. */
     gpfn = get_gpfn_from_mfn(mfn);
     ASSERT( gpfn != SHARED_M2P_ENTRY );
+    if ( xatp->space == XENMAPSPACE_gmfn ||
+         xatp->space == XENMAPSPACE_gmfn_range )
+        ASSERT( gpfn == gfn );
     if ( gpfn != INVALID_M2P_ENTRY )
         guest_physmap_remove_page(d, gpfn, mfn, PAGE_ORDER_4K);
 
     /* Map at new location. */
     rc = guest_physmap_add_page(d, xatp->gpfn, mfn, PAGE_ORDER_4K);
 
-    /* In the XENMAPSPACE_gmfn, we took a ref and locked the p2m at the top */
+    /* In the XENMAPSPACE_gmfn, we took a ref of the gfn at the top */
     if ( xatp->space == XENMAPSPACE_gmfn ||
          xatp->space == XENMAPSPACE_gmfn_range )
         put_gfn(d, gfn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK76-0008Ke-Om; Wed, 23 Nov 2011 21:12:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK75-0008HC-8y
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322082704!2719914!1
X-Originating-IP: [208.97.132.145]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17636 invoked from network); 23 Nov 2011 21:11:44 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-3.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 21:11:44 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id EE69230008F;
	Wed, 23 Nov 2011 13:11:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=eNuCHmuPmdSgeA+ZLvAzYIg76hFm2Ui6M/eEbvSpZkNh
	W0n5frtPT6PJdW+aC2A1vifND6dx3S65E5/UjR/k6jfhi+ABSkqDXKa3wCLdko1B
	MTnmKzjMBHdfUo3/y1Yw/bgBQecYq3XRL0wCyPuDaLmacCr7jWWHXVI5wml6nK4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=OTXRTHzGNzhBhqAhplrQ6KTuOQo=; b=BatrAGS2tj3
	v6Zt+5F2PnEMqyF14TwPEwcMuRnRc3p2+AA4NTq9+XvdTSOmzHoKmkcc0xXxiOij
	DfnLcY8nioEharYJyLkXkO7EIDJoa2E42AP93lMMYraN/D0TAwXmQ7SfZi88HnaD
	dY8rm+qNHWXEBTqAeQBUL+VIZP7QyQPk=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 3EA2130007B; 
	Wed, 23 Nov 2011 13:11:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 76802e649c2cb95c564cc19119d934a6e6b4b6e6
Message-Id: <76802e649c2cb95c564c.1322082676@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:16 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 09 of 14] Allow log dirty mode to be used in
 conjunction with paging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c     |  4 +++-
 xen/include/asm-x86/p2m.h |  3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)


Allow pages typed log dirty to be paged out, and the proper type to
restored when paging pages back in.

Signed-off-by: Andres lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 7e8211d0f41d -r 76802e649c2c xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1061,7 +1061,9 @@ void p2m_mem_paging_resume(struct domain
         if ( mfn_valid(mfn) && 
              (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
         {
-            set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, p2m_ram_rw, a);
+            set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
+                            paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, 
+                            a);
             set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
             audit_p2m(p2m, 1);
         }
diff -r 7e8211d0f41d -r 76802e649c2c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -150,7 +150,8 @@ typedef enum {
 #define P2M_MAGIC_TYPES (p2m_to_mask(p2m_populate_on_demand))
 
 /* Pageable types */
-#define P2M_PAGEABLE_TYPES (p2m_to_mask(p2m_ram_rw))
+#define P2M_PAGEABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
+                            | p2m_to_mask(p2m_ram_logdirty) )
 
 #define P2M_PAGING_TYPES (p2m_to_mask(p2m_ram_paging_out)        \
                           | p2m_to_mask(p2m_ram_paged)           \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK6y-0008Ge-ID; Wed, 23 Nov 2011 21:12:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK6w-0008G6-BI
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322082695!4744634!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29083 invoked from network); 23 Nov 2011 21:11:36 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-7.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 21:11:36 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 535C7300072;
	Wed, 23 Nov 2011 13:11:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=NM4enZs6OSK7fsBQ7uyOiU
	iO4J7aN0W31MRVCHdi/gUDH9WtPAQ+MJZFd0nOxePgRRKAqbQyOrLurCiKzsLVOY
	HqNbLSXhuLQ/u3I3HrNEMvszXK65+M8Y8qh5iEi8cTADnf/cmAMhcbx0COF1SNBG
	dwxBLqQapAyherC499kKw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=uNRRsd/ZWpwl
	it6h0UfAeQWiA5Q=; b=G6u55/gRUvAWf177f3kPBqjEn4cxecOYPEjmiI0rmQYq
	80t+mqSKkSruz8mfZ+yz9hNHOijmF+B/GEyNUgge+nZX2fCrx311MduEoeCXkXl/
	IiWKcm7k/EuJS/cWLYTsbYO4Wte0u/foinTAbkrQJd2dk/44sqt9Ybw/1g5bVXs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 71D3F30006C; 
	Wed, 23 Nov 2011 13:11:34 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 00 of 14] MM Fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series includes a number of bug fixes, targetting 
primarily the mm layer. Many of these fixes also lay groundwork
for future patches.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/p2m-pod.c          |   1 -
 xen/arch/x86/mm/p2m-pt.c           |   9 +++-
 xen/arch/x86/mm/p2m.c              |   5 +-
 xen/arch/x86/mm/hap/hap.c          |   2 +
 tools/libxc/xc_domain.c            |   2 +
 xen/arch/x86/mm/shadow/common.c    |   4 +-
 xen/arch/x86/mm/hap/hap.c          |  15 ++++++--
 xen/arch/x86/mm/hap/hap.c          |   2 +-
 xen/drivers/char/ns16550.c         |   2 +-
 xen/arch/x86/mm/p2m.c              |   4 +-
 xen/include/asm-x86/p2m.h          |   3 +-
 xen/arch/x86/hvm/hvm.c             |  10 ++++-
 xen/arch/x86/mm.c                  |   5 ++-
 xen/arch/x86/hvm/hvm.c             |  69 ++++++++++++++++++++++++-------------
 xen/arch/x86/hvm/nestedhvm.c       |   4 +-
 xen/arch/x86/hvm/svm/nestedsvm.c   |  23 ++++++------
 xen/arch/x86/hvm/vmx/vvmx.c        |  36 +++++++++++--------
 xen/include/asm-x86/hvm/hvm.h      |   9 +++-
 xen/include/asm-x86/hvm/vcpu.h     |   1 +
 xen/include/asm-x86/hvm/vmx/vvmx.h |   1 +
 xen/arch/x86/mm/guest_walk.c       |  16 ++++++--
 xen/common/grant_table.c           |  69 ++++++++++++++++++++-----------------
 22 files changed, 182 insertions(+), 110 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK78-0008Li-74; Wed, 23 Nov 2011 21:12:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK76-0008HY-AX
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322082704!4744876!2
X-Originating-IP: [208.97.132.83]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24910 invoked from network); 23 Nov 2011 21:11:46 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-13.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 21:11:46 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id C502C30007B;
	Wed, 23 Nov 2011 13:11:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=vO57jr3VaoMjN4TasOorutA5gYqfpxvtEQHzhBCOqJgd
	4oIseDJVztqceBU8/fdZo1IvnPWmUGlE81Cr+uXUmVrqP8iQMyygSjlJnzelK1YJ
	kJPWQg+C9u/uEFVEdqtapOW9VGmw8klPA4MCTLttcjtkDqPgHaEYGHDljBQ+YwA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=D/VenX4Rkx3h8Ex84OVEajtSKk4=; b=O34W8wYerw8
	dlYpHfd9y9eLTcJ8b2Mv/r2/sxgtHraX2NDK0UkyVW18VKsdJWSXWNalySmT/X1F
	+Wo6p6pZ59ZzvCwle96q3NSEmADsANej4WlQDAYGMqR4WhahrbNzZwRHbfSunch7
	oBsfUKcCus3Cm4/NpIap/ERJnND0YdF0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 180FD300080; 
	Wed, 23 Nov 2011 13:11:45 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a64f63ecfc57ed8d5200b9983d00a9f42357e3b0
Message-Id: <a64f63ecfc57ed8d5200.1322082678@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:18 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 11 of 14] ASSERT we are putting the right gfn in
 the XNEMAPSPACE_gmfn* cases
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c |  5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 667e53a7ad34 -r a64f63ecfc57 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4773,13 +4773,16 @@ static int xenmem_add_to_physmap_once(
     /* Unmap from old location, if any. */
     gpfn = get_gpfn_from_mfn(mfn);
     ASSERT( gpfn != SHARED_M2P_ENTRY );
+    if ( xatp->space == XENMAPSPACE_gmfn ||
+         xatp->space == XENMAPSPACE_gmfn_range )
+        ASSERT( gpfn == gfn );
     if ( gpfn != INVALID_M2P_ENTRY )
         guest_physmap_remove_page(d, gpfn, mfn, PAGE_ORDER_4K);
 
     /* Map at new location. */
     rc = guest_physmap_add_page(d, xatp->gpfn, mfn, PAGE_ORDER_4K);
 
-    /* In the XENMAPSPACE_gmfn, we took a ref and locked the p2m at the top */
+    /* In the XENMAPSPACE_gmfn, we took a ref of the gfn at the top */
     if ( xatp->space == XENMAPSPACE_gmfn ||
          xatp->space == XENMAPSPACE_gmfn_range )
         put_gfn(d, gfn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK75-0008Jq-TX; Wed, 23 Nov 2011 21:12:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK74-0008Gh-13
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322082703!2784146!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27045 invoked from network); 23 Nov 2011 21:11:43 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-4.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 21:11:43 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 1076D30006C;
	Wed, 23 Nov 2011 13:11:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=NjxyvOBaOZTisTYk7ujEXoDYi+691GMEMO15gKVGhiof
	kqM9cP5QnjpTtuPuxzT7ySR53WX31NpkPFfYIzaAb6xj2i50weIUko2/D32JWPmN
	Iz6thhxjqPD+jCsZuwMv6nJnr5oOqI0yxEYofU/Lvn0Bi7DWpR0qj1Mpi2PNiKk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=lu9MxZB7g3lfHNIEF3xF0AQUfpg=; b=fC0giv0d01a
	DpluhmcQk1TtWsga/LflAsySqFNh8Y284v02M1MNM3J87x99Fp6C2mejKLow0qYG
	io0Op7sWKZbs1SeI4VwSGc+h9cgez8TxW6BdPBE5TfEfGCOh7TGyqn0qFZDO8YGT
	YG2IyLysfVmNm+CZQ/s3e9495I5xoSVs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 61FAF30007B; 
	Wed, 23 Nov 2011 13:11:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7e8211d0f41d42257d278e454ff87b15a664aac9
Message-Id: <7e8211d0f41d42257d27.1322082675@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:15 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 08 of 14] Properly compare "pci" token when
 groking serial port config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/drivers/char/ns16550.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 25d27decfdcc -r 7e8211d0f41d xen/drivers/char/ns16550.c
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -554,7 +554,7 @@ static void __init ns16550_parse_port_co
     if ( *conf == ',' )
     {
         conf++;
-        if ( strncmp(conf, "pci", 5) == 0 )
+        if ( strncmp(conf, "pci", 3) == 0 )
         {
             if ( pci_uart_config(uart, 1/* skip AMT */, uart - ns16550_com) )
                 return;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK6v-0008GF-4w; Wed, 23 Nov 2011 21:12:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK6t-0008G8-Dj
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322082593!53421512!1
X-Originating-IP: [208.97.132.119]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32221 invoked from network); 23 Nov 2011 21:09:53 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.119) by server-8.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 21:09:53 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 48876300080;
	Wed, 23 Nov 2011 13:11:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=V1Ue+vZjD0FXGj+Hoxzin7sr5YlQRCITF4UEpYmU+S0x
	TnBBfMguEBR3e5jmro1bhcKa4+ltVgTfMqXGxp5JGELgHOP56Y11YPnYzYuyF7U0
	bjl8tLoQoEuEzvaY8Ko8z4Qgs7UF+uO5LfInNn7SPr6TrPTYWpzrSkuJK0xPmWg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=gqMEmfW9vJJ6tJKn/PmY5CTx5ck=; b=Xmaiq0gY7nW
	g61KA086Cz70trW1to4OWZQB0NUQHTQ9SakAMeV2vkAj0PzdnjA2HoCj/Ms+vOIz
	od6gT+AP++SAaK4hvOWpN/nwoL7QvZuCGrV7DHnIESuV/fm1knas+AE6BpiR95QU
	VO0fGwi80/XNnUxFDs7JbNCdsBdZ07uY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 7000430006C; 
	Wed, 23 Nov 2011 13:11:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b85ecdc5aa831af1000937676225e8cfa18da0fb
Message-Id: <b85ecdc5aa831af10009.1322082669@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:09 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 02 of 14] Fix handling of m2p map in
	set_shared_p2m_entry
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)


When updating a p2m mapping to shared, previous code
unconditionally set the m2p entry for the old mfn to invalid.
We now check that the old mfn does not remain shared.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 00c1834b2882 -r b85ecdc5aa83 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -714,8 +714,9 @@ set_shared_p2m_entry(struct domain *d, u
      * sharable first */
     ASSERT(p2m_is_shared(ot));
     ASSERT(mfn_valid(omfn));
-    /* XXX: M2P translations have to be handled properly for shared pages */
-    set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
+    if ( ((mfn_to_page(omfn)->u.inuse.type_info & PGT_type_mask) 
+                    != PGT_shared_page) )
+        set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
 
     P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_shared, p2m->default_access);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK75-0008Jq-TX; Wed, 23 Nov 2011 21:12:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK74-0008Gh-13
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322082703!2784146!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27045 invoked from network); 23 Nov 2011 21:11:43 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-4.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 21:11:43 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 1076D30006C;
	Wed, 23 Nov 2011 13:11:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=NjxyvOBaOZTisTYk7ujEXoDYi+691GMEMO15gKVGhiof
	kqM9cP5QnjpTtuPuxzT7ySR53WX31NpkPFfYIzaAb6xj2i50weIUko2/D32JWPmN
	Iz6thhxjqPD+jCsZuwMv6nJnr5oOqI0yxEYofU/Lvn0Bi7DWpR0qj1Mpi2PNiKk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=lu9MxZB7g3lfHNIEF3xF0AQUfpg=; b=fC0giv0d01a
	DpluhmcQk1TtWsga/LflAsySqFNh8Y284v02M1MNM3J87x99Fp6C2mejKLow0qYG
	io0Op7sWKZbs1SeI4VwSGc+h9cgez8TxW6BdPBE5TfEfGCOh7TGyqn0qFZDO8YGT
	YG2IyLysfVmNm+CZQ/s3e9495I5xoSVs=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 61FAF30007B; 
	Wed, 23 Nov 2011 13:11:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7e8211d0f41d42257d278e454ff87b15a664aac9
Message-Id: <7e8211d0f41d42257d27.1322082675@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:15 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 08 of 14] Properly compare "pci" token when
 groking serial port config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/drivers/char/ns16550.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 25d27decfdcc -r 7e8211d0f41d xen/drivers/char/ns16550.c
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -554,7 +554,7 @@ static void __init ns16550_parse_port_co
     if ( *conf == ',' )
     {
         conf++;
-        if ( strncmp(conf, "pci", 5) == 0 )
+        if ( strncmp(conf, "pci", 3) == 0 )
         {
             if ( pci_uart_config(uart, 1/* skip AMT */, uart - ns16550_com) )
                 return;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK6v-0008GF-4w; Wed, 23 Nov 2011 21:12:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK6t-0008G8-Dj
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322082593!53421512!1
X-Originating-IP: [208.97.132.119]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32221 invoked from network); 23 Nov 2011 21:09:53 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.119) by server-8.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 21:09:53 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 48876300080;
	Wed, 23 Nov 2011 13:11:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=V1Ue+vZjD0FXGj+Hoxzin7sr5YlQRCITF4UEpYmU+S0x
	TnBBfMguEBR3e5jmro1bhcKa4+ltVgTfMqXGxp5JGELgHOP56Y11YPnYzYuyF7U0
	bjl8tLoQoEuEzvaY8Ko8z4Qgs7UF+uO5LfInNn7SPr6TrPTYWpzrSkuJK0xPmWg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=gqMEmfW9vJJ6tJKn/PmY5CTx5ck=; b=Xmaiq0gY7nW
	g61KA086Cz70trW1to4OWZQB0NUQHTQ9SakAMeV2vkAj0PzdnjA2HoCj/Ms+vOIz
	od6gT+AP++SAaK4hvOWpN/nwoL7QvZuCGrV7DHnIESuV/fm1knas+AE6BpiR95QU
	VO0fGwi80/XNnUxFDs7JbNCdsBdZ07uY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 7000430006C; 
	Wed, 23 Nov 2011 13:11:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b85ecdc5aa831af1000937676225e8cfa18da0fb
Message-Id: <b85ecdc5aa831af10009.1322082669@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:09 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 02 of 14] Fix handling of m2p map in
	set_shared_p2m_entry
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)


When updating a p2m mapping to shared, previous code
unconditionally set the m2p entry for the old mfn to invalid.
We now check that the old mfn does not remain shared.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 00c1834b2882 -r b85ecdc5aa83 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -714,8 +714,9 @@ set_shared_p2m_entry(struct domain *d, u
      * sharable first */
     ASSERT(p2m_is_shared(ot));
     ASSERT(mfn_valid(omfn));
-    /* XXX: M2P translations have to be handled properly for shared pages */
-    set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
+    if ( ((mfn_to_page(omfn)->u.inuse.type_info & PGT_type_mask) 
+                    != PGT_shared_page) )
+        set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
 
     P2M_DEBUG("set shared %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_shared, p2m->default_access);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK72-0008IM-Tl; Wed, 23 Nov 2011 21:12:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK71-0008GM-9p
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322082700!2774335!1
X-Originating-IP: [208.97.132.145]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21995 invoked from network); 23 Nov 2011 21:11:40 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-10.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 21:11:40 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 36B4430006C;
	Wed, 23 Nov 2011 13:11:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mv8gw8t8IMeYkdXDuhvcnHUHLHWu5grmIKL0TmgbHG5p
	KeF+QYu3bh9zlxecGLQdsWi8jxYjHWoFgwoaqVvkb+95C/VxgGn9w/zo8DFFcgT8
	2XjxR8I1KPYm0G+agtGsPO305eB9bJHq8msLtI6q5x/r7ScSWBZoODu+An62xow=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=fOpj2bn9Mco3XCHrkv3Ryxd2qBQ=; b=vbLz9XSVbDT
	HT0bNkPZL8jlIjS6qapXtSn78PBaY8XNsqXta60cAoFl6FKJeYfhJCvgM7DlHNgS
	YYzafXqQtchf0DpbZOLLvtwy6LS4lBwMdosU4ETmMIFZjgAYLX2yXdSSTZLe1Yo+
	Jj+xdTa/CC/CS5iaiMlo4pr+oGdF/6AA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 6F43130007B; 
	Wed, 23 Nov 2011 13:11:39 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e8f0709af2b783a9e4300ba1ce7c9b718be71a05
Message-Id: <e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:12 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 05 of 14] Don't trigger unnecessary shadow scans
 on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/shadow/common.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


When updating a p2m entry, the hypervisor scans all shadow pte's to find
mappings of that gfn and tear them down. This is avoided if the page count
reveals that there are no additional mappings. The current test ignores the
PGC_allocated flag and its effect on the page count.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 93066bdc1e1c -r e8f0709af2b7 xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2501,7 +2501,8 @@ int sh_remove_all_mappings(struct vcpu *
         ;
 
     perfc_incr(shadow_mappings);
-    if ( (page->count_info & PGC_count_mask) == 0 )
+    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
+    if ( (page->count_info & PGC_count_mask) == expected_count )
         return 0;
 
     /* Although this is an externally visible function, we do not know
@@ -2517,7 +2518,6 @@ int sh_remove_all_mappings(struct vcpu *
     hash_foreach(v, callback_mask, callbacks, gmfn);
 
     /* If that didn't catch the mapping, something is very wrong */
-    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
     if ( (page->count_info & PGC_count_mask) != expected_count )
     {
         /* Don't complain if we're in HVM and there are some extra mappings: 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK72-0008IM-Tl; Wed, 23 Nov 2011 21:12:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK71-0008GM-9p
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322082700!2774335!1
X-Originating-IP: [208.97.132.145]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21995 invoked from network); 23 Nov 2011 21:11:40 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-10.tower-174.messagelabs.com with SMTP;
	23 Nov 2011 21:11:40 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 36B4430006C;
	Wed, 23 Nov 2011 13:11:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=mv8gw8t8IMeYkdXDuhvcnHUHLHWu5grmIKL0TmgbHG5p
	KeF+QYu3bh9zlxecGLQdsWi8jxYjHWoFgwoaqVvkb+95C/VxgGn9w/zo8DFFcgT8
	2XjxR8I1KPYm0G+agtGsPO305eB9bJHq8msLtI6q5x/r7ScSWBZoODu+An62xow=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=fOpj2bn9Mco3XCHrkv3Ryxd2qBQ=; b=vbLz9XSVbDT
	HT0bNkPZL8jlIjS6qapXtSn78PBaY8XNsqXta60cAoFl6FKJeYfhJCvgM7DlHNgS
	YYzafXqQtchf0DpbZOLLvtwy6LS4lBwMdosU4ETmMIFZjgAYLX2yXdSSTZLe1Yo+
	Jj+xdTa/CC/CS5iaiMlo4pr+oGdF/6AA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 6F43130007B; 
	Wed, 23 Nov 2011 13:11:39 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e8f0709af2b783a9e4300ba1ce7c9b718be71a05
Message-Id: <e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:12 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 05 of 14] Don't trigger unnecessary shadow scans
 on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/shadow/common.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


When updating a p2m entry, the hypervisor scans all shadow pte's to find
mappings of that gfn and tear them down. This is avoided if the page count
reveals that there are no additional mappings. The current test ignores the
PGC_allocated flag and its effect on the page count.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 93066bdc1e1c -r e8f0709af2b7 xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2501,7 +2501,8 @@ int sh_remove_all_mappings(struct vcpu *
         ;
 
     perfc_incr(shadow_mappings);
-    if ( (page->count_info & PGC_count_mask) == 0 )
+    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
+    if ( (page->count_info & PGC_count_mask) == expected_count )
         return 0;
 
     /* Although this is an externally visible function, we do not know
@@ -2517,7 +2518,6 @@ int sh_remove_all_mappings(struct vcpu *
     hash_foreach(v, callback_mask, callbacks, gmfn);
 
     /* If that didn't catch the mapping, something is very wrong */
-    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
     if ( (page->count_info & PGC_count_mask) != expected_count )
     {
         /* Don't complain if we're in HVM and there are some extra mappings: 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK71-0008Hj-D0; Wed, 23 Nov 2011 21:12:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK70-0008GE-7Q
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322082699!4647182!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19677 invoked from network); 23 Nov 2011 21:11:40 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 21:11:40 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 3D723300072;
	Wed, 23 Nov 2011 13:11:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=HNtIxpwzv2d0Rq0XAA8AqkTz51GB4204PwChnTU1HSE+
	tYcU4ZuDDmbpaqXaLd+uAjueNPi+5sNVkhnq1k/oQ3XYlJwCsepo5fbTTk7hBWHQ
	i9fMBQaki7vwJQglwj8cu8i9jgPCTv00/eeCW3Wu6wKUfWvAA9cFXxjq3NjwMQc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=08Pr3/xce2HJDypkwrMdfhWehCU=; b=jE3iDK/jGQ0
	/zFAh1zO13unQNlvAYYg+VWzpIzqTUfsAjVgmR+cqzqP9Ddmtleresfz/3tS7bek
	UtaFrvhD3IIc+ukZUhh5J1mmHdySVu4//F4YStTsq2lka0OmoqxeYOWv68mHCSuC
	IDjasH2p1Ourkb+ZIYwCycGBoConORys=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 7B8AD30006C; 
	Wed, 23 Nov 2011 13:11:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 93066bdc1e1cb04f4524570c0c1c4843fec7f45a
Message-Id: <93066bdc1e1cb04f4524.1322082671@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:11 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 04 of 14] When passing no bitmap for the shadow
 log dirty bitmap clean up, we should not get EFAULT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_domain.c |  2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)


This is due to a stale check for guest_handle_null in the hypervisor, which doesn't
necessarily work with the hypercall buffers.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 58eae300fa63 -r 93066bdc1e1c tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -430,6 +430,8 @@ int xc_shadow_control(xc_interface *xch,
     DECLARE_DOMCTL;
     DECLARE_HYPERCALL_BUFFER_ARGUMENT(dirty_bitmap);
 
+    memset(&domctl, 0, sizeof(domctl));
+
     domctl.cmd = XEN_DOMCTL_shadow_op;
     domctl.domain = (domid_t)domid;
     domctl.u.shadow_op.op     = sop;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK71-0008Hj-D0; Wed, 23 Nov 2011 21:12:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK70-0008GE-7Q
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322082699!4647182!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19677 invoked from network); 23 Nov 2011 21:11:40 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-216.messagelabs.com with SMTP;
	23 Nov 2011 21:11:40 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 3D723300072;
	Wed, 23 Nov 2011 13:11:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=HNtIxpwzv2d0Rq0XAA8AqkTz51GB4204PwChnTU1HSE+
	tYcU4ZuDDmbpaqXaLd+uAjueNPi+5sNVkhnq1k/oQ3XYlJwCsepo5fbTTk7hBWHQ
	i9fMBQaki7vwJQglwj8cu8i9jgPCTv00/eeCW3Wu6wKUfWvAA9cFXxjq3NjwMQc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=08Pr3/xce2HJDypkwrMdfhWehCU=; b=jE3iDK/jGQ0
	/zFAh1zO13unQNlvAYYg+VWzpIzqTUfsAjVgmR+cqzqP9Ddmtleresfz/3tS7bek
	UtaFrvhD3IIc+ukZUhh5J1mmHdySVu4//F4YStTsq2lka0OmoqxeYOWv68mHCSuC
	IDjasH2p1Ourkb+ZIYwCycGBoConORys=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 7B8AD30006C; 
	Wed, 23 Nov 2011 13:11:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 93066bdc1e1cb04f4524570c0c1c4843fec7f45a
Message-Id: <93066bdc1e1cb04f4524.1322082671@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:11 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 04 of 14] When passing no bitmap for the shadow
 log dirty bitmap clean up, we should not get EFAULT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_domain.c |  2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)


This is due to a stale check for guest_handle_null in the hypervisor, which doesn't
necessarily work with the hypercall buffers.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 58eae300fa63 -r 93066bdc1e1c tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -430,6 +430,8 @@ int xc_shadow_control(xc_interface *xch,
     DECLARE_DOMCTL;
     DECLARE_HYPERCALL_BUFFER_ARGUMENT(dirty_bitmap);
 
+    memset(&domctl, 0, sizeof(domctl));
+
     domctl.cmd = XEN_DOMCTL_shadow_op;
     domctl.domain = (domid_t)domid;
     domctl.u.shadow_op.op     = sop;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK76-0008KB-AH; Wed, 23 Nov 2011 21:12:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK74-0008HX-Cx
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322082672!45134055!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4892 invoked from network); 23 Nov 2011 21:11:12 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 21:11:12 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id E58F630008D;
	Wed, 23 Nov 2011 13:11:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=eL5gmSDD0T+rfBRHnCwnMptgA4oFm8Mq5UsufuWZL2gu
	u/rcpxuh1PIHJxKnsjsNJq7p7Ckyl264dl02iO5zFVMENEl2WNyjvVGeO8ion4y+
	TDciahmbr1zF73Y8Li2j29JtRpFCa6ys27aK67GMPSLz/OK5cidhofHNnUaWVQU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=aLMyHizUoIX7k5OqNX2X4BtWNII=; b=oqeVE3KMiPA
	nn4njRneDHedQ4741INrUBDBmF4IyqjdJkZXl9EHcgD5DMZp17lggao0qjGKqi9E
	zNbRV/KZDJnnDPp7FbWFIdQ8tZ6ph+rtaqa65uZHvQZDkYb+BvSWCeEqJ+eXh9gG
	FZXKOc09YYW2fTa46q86YgaUl/a00n3E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 27C6530007B; 
	Wed, 23 Nov 2011 13:11:44 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 667e53a7ad34cd286c767ec3c8b529900217e076
Message-Id: <667e53a7ad34cd286c76.1322082677@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:17 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 10 of 14] Prevent the hypervisor from BUGging if
 xc_hvm_modified_memory is called on a shared page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c |  10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 76802e649c2c -r 667e53a7ad34 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3755,7 +3755,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
         for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ )
         {
             p2m_type_t t;
-            mfn_t mfn = get_gfn(d, pfn, &t);
+            mfn_t mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
                 p2m_mem_paging_populate(d, pfn);
@@ -3764,8 +3764,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 goto param_fail3;
             }
             if( p2m_is_shared(t) )
+            {
+                /* If it insists on not unsharing itself, crash the domain 
+                 * rather than crashing the host down in mark dirty */
                 gdprintk(XENLOG_WARNING,
                          "shared pfn 0x%lx modified?\n", pfn);
+                domain_crash(d);
+                put_gfn(d, pfn);
+                rc = -EINVAL;
+                goto param_fail3;
+            }
             
             if ( mfn_x(mfn) != INVALID_MFN )
             {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 21:12:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 21:12:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTK76-0008KB-AH; Wed, 23 Nov 2011 21:12:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTK74-0008HX-Cx
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 21:12:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322082672!45134055!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4892 invoked from network); 23 Nov 2011 21:11:12 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-27.messagelabs.com with SMTP;
	23 Nov 2011 21:11:12 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id E58F630008D;
	Wed, 23 Nov 2011 13:11:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=eL5gmSDD0T+rfBRHnCwnMptgA4oFm8Mq5UsufuWZL2gu
	u/rcpxuh1PIHJxKnsjsNJq7p7Ckyl264dl02iO5zFVMENEl2WNyjvVGeO8ion4y+
	TDciahmbr1zF73Y8Li2j29JtRpFCa6ys27aK67GMPSLz/OK5cidhofHNnUaWVQU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=aLMyHizUoIX7k5OqNX2X4BtWNII=; b=oqeVE3KMiPA
	nn4njRneDHedQ4741INrUBDBmF4IyqjdJkZXl9EHcgD5DMZp17lggao0qjGKqi9E
	zNbRV/KZDJnnDPp7FbWFIdQ8tZ6ph+rtaqa65uZHvQZDkYb+BvSWCeEqJ+eXh9gG
	FZXKOc09YYW2fTa46q86YgaUl/a00n3E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 27C6530007B; 
	Wed, 23 Nov 2011 13:11:44 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 667e53a7ad34cd286c767ec3c8b529900217e076
Message-Id: <667e53a7ad34cd286c76.1322082677@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 23 Nov 2011 16:11:17 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 10 of 14] Prevent the hypervisor from BUGging if
 xc_hvm_modified_memory is called on a shared page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c |  10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 76802e649c2c -r 667e53a7ad34 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3755,7 +3755,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
         for ( pfn = a.first_pfn; pfn < a.first_pfn + a.nr; pfn++ )
         {
             p2m_type_t t;
-            mfn_t mfn = get_gfn(d, pfn, &t);
+            mfn_t mfn = get_gfn_unshare(d, pfn, &t);
             if ( p2m_is_paging(t) )
             {
                 p2m_mem_paging_populate(d, pfn);
@@ -3764,8 +3764,16 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 goto param_fail3;
             }
             if( p2m_is_shared(t) )
+            {
+                /* If it insists on not unsharing itself, crash the domain 
+                 * rather than crashing the host down in mark dirty */
                 gdprintk(XENLOG_WARNING,
                          "shared pfn 0x%lx modified?\n", pfn);
+                domain_crash(d);
+                put_gfn(d, pfn);
+                rc = -EINVAL;
+                goto param_fail3;
+            }
             
             if ( mfn_x(mfn) != INVALID_MFN )
             {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 22:32:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 22:32:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTLLx-0002nX-UQ; Wed, 23 Nov 2011 22:31:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTLLv-0002nS-VX
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 22:31:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322087469!4728000!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3359 invoked from network); 23 Nov 2011 22:31:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 22:31:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322087469; l=1686;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=9e08dbteI9RSo822o8ESVQqcBtM=;
	b=BpU5Yt7Qa+maMtWlkYJuc+B+C2sVQfJSDwgy+Tga9YAD1f/bqlLf47q6jrnZdphFeEo
	4bX/obS8d6PSkui5/+K4Jj7sbNoSFXs1ZmhmD848wqtmLo8BVdzqPjxBBSrv2E6l8iuzf
	xkjQZ/1Pp8otbzZyfe6fY21ORHz2kqTSOkI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (jimi mo40) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L04ae0nANMLfMf ;
	Wed, 23 Nov 2011 23:30:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E43DC18637; Wed, 23 Nov 2011 23:30:49 +0100 (CET)
Date: Wed, 23 Nov 2011 23:30:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111123223049.GA14423@aepfle.de>
References: <CAF2F84A.2571A%keir.xen@gmail.com>
	<CAF3102F.25730%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF3102F.25730%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Keir Fraser wrote:

> Attached three patches for you to try. They apply in sequence.
> 00: A fixed version of "domain_crash on stack overflow"
> 01: Reorders prepare_to_wait so that the vcpu will always be on the
> waitqueue on exit (even if it has just been woken).
> 02: Ensures the vcpu wakes up on the same cpu that it slept on.
> 
> We need all of these. Just need testing to make sure they aren't horribly
> broken. You should be able to test multi-processor host again with these.

Thanks Keir.

In a first test they work ok with multi-processor.
I get vcpu hangs when I balloon up and down with mem-set. Thats most
likely caused by uneven vcpu_pause/unpause calls in my changes which use
wait queue in mem_event handling and ept_get_entry. I will debug that
further.

After the vcpu hung I killed the guest and tried to start a new one.
Oddly enough I wasnt able to fully kill the guest, it remained in --p--d
state. Most vcpus were in paused state before that.

In another attempt I was able to run firefox in a guest. But after
trying to open all "latest headlines" in tabs the guest crashed. qemu-dm
log had alot of this (but nothing in xen dmesg):
track_dirty_vram(f0000000, 12c) failed (-1, 3)

xl vcpu-list shows
(null)                               1     0    -   --p      47.3  any cpu
(null)                               1     1   12   ---      13.4  any cpu
(null)                               1     2    -   --p       4.3  any cpu
(null)                               1     3    -   --p       7.8  any cpu
(null)                               1     4    -   --p       3.5  any cpu
(null)                               1     5    -   --p       1.9  any cpu
(null)                               1     6    -   --p       1.6  any cpu
(null)                               1     7    -   --p       1.4  any cpu

Hmm, qemu-dm doesnt get killed in all cases, killing it destroys the guest..
I have seen that before already.


I will provide more test results tomorrow.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 22:32:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 22:32:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTLLx-0002nX-UQ; Wed, 23 Nov 2011 22:31:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTLLv-0002nS-VX
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 22:31:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322087469!4728000!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3359 invoked from network); 23 Nov 2011 22:31:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Nov 2011 22:31:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322087469; l=1686;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=9e08dbteI9RSo822o8ESVQqcBtM=;
	b=BpU5Yt7Qa+maMtWlkYJuc+B+C2sVQfJSDwgy+Tga9YAD1f/bqlLf47q6jrnZdphFeEo
	4bX/obS8d6PSkui5/+K4Jj7sbNoSFXs1ZmhmD848wqtmLo8BVdzqPjxBBSrv2E6l8iuzf
	xkjQZ/1Pp8otbzZyfe6fY21ORHz2kqTSOkI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr387oEdY=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-066-033.pools.arcor-ip.net [84.57.66.33])
	by smtp.strato.de (jimi mo40) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L04ae0nANMLfMf ;
	Wed, 23 Nov 2011 23:30:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id E43DC18637; Wed, 23 Nov 2011 23:30:49 +0100 (CET)
Date: Wed, 23 Nov 2011 23:30:49 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111123223049.GA14423@aepfle.de>
References: <CAF2F84A.2571A%keir.xen@gmail.com>
	<CAF3102F.25730%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF3102F.25730%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Keir Fraser wrote:

> Attached three patches for you to try. They apply in sequence.
> 00: A fixed version of "domain_crash on stack overflow"
> 01: Reorders prepare_to_wait so that the vcpu will always be on the
> waitqueue on exit (even if it has just been woken).
> 02: Ensures the vcpu wakes up on the same cpu that it slept on.
> 
> We need all of these. Just need testing to make sure they aren't horribly
> broken. You should be able to test multi-processor host again with these.

Thanks Keir.

In a first test they work ok with multi-processor.
I get vcpu hangs when I balloon up and down with mem-set. Thats most
likely caused by uneven vcpu_pause/unpause calls in my changes which use
wait queue in mem_event handling and ept_get_entry. I will debug that
further.

After the vcpu hung I killed the guest and tried to start a new one.
Oddly enough I wasnt able to fully kill the guest, it remained in --p--d
state. Most vcpus were in paused state before that.

In another attempt I was able to run firefox in a guest. But after
trying to open all "latest headlines" in tabs the guest crashed. qemu-dm
log had alot of this (but nothing in xen dmesg):
track_dirty_vram(f0000000, 12c) failed (-1, 3)

xl vcpu-list shows
(null)                               1     0    -   --p      47.3  any cpu
(null)                               1     1   12   ---      13.4  any cpu
(null)                               1     2    -   --p       4.3  any cpu
(null)                               1     3    -   --p       7.8  any cpu
(null)                               1     4    -   --p       3.5  any cpu
(null)                               1     5    -   --p       1.9  any cpu
(null)                               1     6    -   --p       1.6  any cpu
(null)                               1     7    -   --p       1.4  any cpu

Hmm, qemu-dm doesnt get killed in all cases, killing it destroys the guest..
I have seen that before already.


I will provide more test results tomorrow.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 23:13:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 23:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTM0C-0003JU-O8; Wed, 23 Nov 2011 23:13:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTM0B-0003JP-O8
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 23:13:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322089965!4346595!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7200 invoked from network); 23 Nov 2011 23:12:45 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 23:12:45 -0000
Received: by wwo1 with SMTP id 1so2286126wwo.24
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 15:12:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cikSW0nXhtrzyLTmvHYEZCoOF7R97i6bcRlpKDguCeg=;
	b=hkDOdU41os47vIDy32MmR6yNyOhPNq0nSx8LCdc2Ssj5ReZYbmopLPHb3NQZHdvVVi
	rR8GF7dp65N+rLoYFCalHhptbL2/PmPjba4+zYcsYVpmkhxhkXyfY9KRq++TQIdLIPDg
	3Y+x87heQ+S1a9fRY0YgBXHLfbwlKxm5WCIHA=
Received: by 10.227.198.76 with SMTP id en12mr10760339wbb.14.1322089965116;
	Wed, 23 Nov 2011 15:12:45 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id z10sm3681326wbn.10.2011.11.23.15.12.43
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 15:12:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 23:12:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF32E64.25744%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqNWMhF/QUSgn9l0KTvVUSHUvNOA==
In-Reply-To: <20111123223049.GA14423@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 22:30, "Olaf Hering" <olaf@aepfle.de> wrote:

> After the vcpu hung I killed the guest and tried to start a new one.
> Oddly enough I wasnt able to fully kill the guest, it remained in --p--d
> state. Most vcpus were in paused state before that.

Dying but kept as a zombie by memory references...

> In another attempt I was able to run firefox in a guest. But after
> trying to open all "latest headlines" in tabs the guest crashed. qemu-dm
> log had alot of this (but nothing in xen dmesg):
> track_dirty_vram(f0000000, 12c) failed (-1, 3)
> 
> xl vcpu-list shows
> (null)                               1     0    -   --p      47.3  any cpu
> (null)                               1     1   12   ---      13.4  any cpu
> (null)                               1     2    -   --p       4.3  any cpu
> (null)                               1     3    -   --p       7.8  any cpu
> (null)                               1     4    -   --p       3.5  any cpu
> (null)                               1     5    -   --p       1.9  any cpu
> (null)                               1     6    -   --p       1.6  any cpu
> (null)                               1     7    -   --p       1.4  any cpu
> 
> Hmm, qemu-dm doesnt get killed in all cases, killing it destroys the guest..
> I have seen that before already.

...from qemu-dm. Problem is that toolstack is not killing qemu-dm, or
qemu-dm is not responding to some shutdown signal.

> I will provide more test results tomorrow.

Thanks.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 23 23:13:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 23 Nov 2011 23:13:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTM0C-0003JU-O8; Wed, 23 Nov 2011 23:13:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTM0B-0003JP-O8
	for xen-devel@lists.xensource.com; Wed, 23 Nov 2011 23:13:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322089965!4346595!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7200 invoked from network); 23 Nov 2011 23:12:45 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Nov 2011 23:12:45 -0000
Received: by wwo1 with SMTP id 1so2286126wwo.24
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 15:12:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cikSW0nXhtrzyLTmvHYEZCoOF7R97i6bcRlpKDguCeg=;
	b=hkDOdU41os47vIDy32MmR6yNyOhPNq0nSx8LCdc2Ssj5ReZYbmopLPHb3NQZHdvVVi
	rR8GF7dp65N+rLoYFCalHhptbL2/PmPjba4+zYcsYVpmkhxhkXyfY9KRq++TQIdLIPDg
	3Y+x87heQ+S1a9fRY0YgBXHLfbwlKxm5WCIHA=
Received: by 10.227.198.76 with SMTP id en12mr10760339wbb.14.1322089965116;
	Wed, 23 Nov 2011 15:12:45 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id z10sm3681326wbn.10.2011.11.23.15.12.43
	(version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 15:12:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 23:12:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF32E64.25744%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqNWMhF/QUSgn9l0KTvVUSHUvNOA==
In-Reply-To: <20111123223049.GA14423@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11/2011 22:30, "Olaf Hering" <olaf@aepfle.de> wrote:

> After the vcpu hung I killed the guest and tried to start a new one.
> Oddly enough I wasnt able to fully kill the guest, it remained in --p--d
> state. Most vcpus were in paused state before that.

Dying but kept as a zombie by memory references...

> In another attempt I was able to run firefox in a guest. But after
> trying to open all "latest headlines" in tabs the guest crashed. qemu-dm
> log had alot of this (but nothing in xen dmesg):
> track_dirty_vram(f0000000, 12c) failed (-1, 3)
> 
> xl vcpu-list shows
> (null)                               1     0    -   --p      47.3  any cpu
> (null)                               1     1   12   ---      13.4  any cpu
> (null)                               1     2    -   --p       4.3  any cpu
> (null)                               1     3    -   --p       7.8  any cpu
> (null)                               1     4    -   --p       3.5  any cpu
> (null)                               1     5    -   --p       1.9  any cpu
> (null)                               1     6    -   --p       1.6  any cpu
> (null)                               1     7    -   --p       1.4  any cpu
> 
> Hmm, qemu-dm doesnt get killed in all cases, killing it destroys the guest..
> I have seen that before already.

...from qemu-dm. Problem is that toolstack is not killing qemu-dm, or
qemu-dm is not responding to some shutdown signal.

> I will provide more test results tomorrow.

Thanks.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 02:43:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 02:43:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTPHD-00012B-0U; Thu, 24 Nov 2011 02:43:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTPHB-000126-5V
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 02:43:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322102527!45825611!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12861 invoked from network); 24 Nov 2011 02:42:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 02:42:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,562,1315180800"; 
   d="scan'208";a="9102357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 02:42:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 02:42:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTPGi-0001YJ-1c;
	Thu, 24 Nov 2011 02:42:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTPGi-0004gs-12;
	Thu, 24 Nov 2011 02:42:32 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10018-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 24 Nov 2011 02:42:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10018: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10018 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10018/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  84b3e46aa7d2
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24187:84b3e46aa7d2
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 23 12:03:37 2011 +0000
    
    libxl: Prevent xl save from segfaulting when control/shutdown key is removed
    
    To acknowledge the tools' setting of control/shutdown it is normal for
    PV drivers to rm the key. This leads to libxl__xs_read() returning
    NULL and thus a subsequent strcmp on the return value will cause a
    segfault.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24186:7aa5838499d1
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 23 11:15:31 2011 +0000
    
    tools: use system libaio for blktap1 as well.
    
    24184:4ecd3615e726 missed this because I was accidentally testing with a
    .config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
    without this. There were no other issues.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24185:f88c745575bb
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 18:51:13 2011 +0000
    
    docs: remove some fatally out of date documentation
    
    I think these are better off deleted than remaining to confuse people.
    
    docs/misc/blkif-drivers-explained.txt:
    
     - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.
    
    docs/misc/cpuid-config-for-guest.txt:
    
     - Doesn't really say anything, in particular doesn't actually describe how to
       configure CPUID.
    
    docs/misc/hg-cheatsheet.txt:
    
     - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
       under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
       hardly unusual anymore I think there must be better guides out there so this
       one is not worth resurecting.
    
    docs/misc/network_setup.txt:
    
     - This is more comprehensively documented on the wiki these days.
    
    docs/misc/VMX_changes.txt:
    
     - Is basically a changelog from the initial implementation of VMX in 2004.
    
    I'm not sure about some of the other docs, but these ones seemed fairly
    obvious.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24184:4ecd3615e726
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 02:43:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 02:43:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTPHD-00012B-0U; Thu, 24 Nov 2011 02:43:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTPHB-000126-5V
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 02:43:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322102527!45825611!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12861 invoked from network); 24 Nov 2011 02:42:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 02:42:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,562,1315180800"; 
   d="scan'208";a="9102357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 02:42:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 02:42:32 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTPGi-0001YJ-1c;
	Thu, 24 Nov 2011 02:42:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTPGi-0004gs-12;
	Thu, 24 Nov 2011 02:42:32 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10018-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 24 Nov 2011 02:42:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10018: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10018 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10018/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  84b3e46aa7d2
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24187:84b3e46aa7d2
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 23 12:03:37 2011 +0000
    
    libxl: Prevent xl save from segfaulting when control/shutdown key is removed
    
    To acknowledge the tools' setting of control/shutdown it is normal for
    PV drivers to rm the key. This leads to libxl__xs_read() returning
    NULL and thus a subsequent strcmp on the return value will cause a
    segfault.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24186:7aa5838499d1
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Wed Nov 23 11:15:31 2011 +0000
    
    tools: use system libaio for blktap1 as well.
    
    24184:4ecd3615e726 missed this because I was accidentally testing with a
    .config containing CONFIG_SYSTEM_LIBAIO=n. Tools tree now fully rebuilt
    without this. There were no other issues.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24185:f88c745575bb
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 18:51:13 2011 +0000
    
    docs: remove some fatally out of date documentation
    
    I think these are better off deleted than remaining to confuse people.
    
    docs/misc/blkif-drivers-explained.txt:
    
     - Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.
    
    docs/misc/cpuid-config-for-guest.txt:
    
     - Doesn't really say anything, in particular doesn't actually describe how to
       configure CPUID.
    
    docs/misc/hg-cheatsheet.txt:
    
     - Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
       under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
       hardly unusual anymore I think there must be better guides out there so this
       one is not worth resurecting.
    
    docs/misc/network_setup.txt:
    
     - This is more comprehensively documented on the wiki these days.
    
    docs/misc/VMX_changes.txt:
    
     - Is basically a changelog from the initial implementation of VMX in 2004.
    
    I'm not sure about some of the other docs, but these ones seemed fairly
    obvious.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24184:4ecd3615e726
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Nov 22 17:24:51 2011 +0000
    
    tools: use system installed libaio by default.
    
    I could have sworn I did this years ago.
    
    IIRC the need for our own copy was due to the use of io_set_eventfd which is
    not present in version 0.3.106. However it is in 0.3.107 the first version of
    which was uploaded to Debian in June 2008 (I can't find a better reference for
    the release date).
    
    The necessary version is available in Debian Lenny onwards and is in at least
    RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
    available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
    version.
    
    This is based on tools-system-libaio.diff from the Debian packaging although I
    have made it optional (but default on).
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24183:53bec838bb08
parent:      24182:8edcd2e3f3f1
parent:      24181:2b5c6fff0e5b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 17:09:12 2011 +0000
    
    Merge
    
    
changeset:   24182:8edcd2e3f3f1
parent:      24180:b21b6c91c1f4
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 17:07:32 2011 +0000
    
    xenstore: xenbus cannot be opened read-only
    
    In order to read keys from xenstore, the xenstore libraries need to
    write the request to the xenbus socket. This means that the socket
    cannot be opened read-only.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24181:2b5c6fff0e5b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Nov 22 17:22:31 2011 +0100
    
    move pci_find_ext_capability() into common PCI code
    
    There's nothing architecture specific about it. It requires, however,
    that x86-32's pci_conf_read32() tolerates register accesses above 255
    (for consistency the adjustment is done to all pci_conf_readNN()
    functions).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24180:b21b6c91c1f4
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Tue Nov 22 16:19:48 2011 +0000
    
    libxl: Add a vkbd frontend/backend pair for HVM guests
    
    Linux PV on HVM guests can use vkbd, so add a vkbd frontend/backend
    pair for HVM guests by default.  It is useful because it doesn't
    require frequent qemu wakeups as the usb keyboard/mouse does.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24179:99a567be1978
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Nov 22 16:19:11 2011 +0000
    
    Update QEMU_TAG
    
    
changeset:   24178:1f2a06dbbb69
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 15:35:26 2011 +0000
    
    debug: Add domain/vcpu pause_count info to 'd' key.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24177:d3859e348951
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:48 2011 +0000
    
    xsm/flask: fix resource list range checks
    
    The FLASK security checks for resource ranges were not implemented
    correctly - only the permissions on the endpoints of a range were
    checked, instead of all items contained in the range. This would allow
    certain resources (I/O ports, I/O memory) to be used by domains in
    contravention to security policy.
    
    This also corrects a bug where adding overlapping resource ranges did
    not trigger an error.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24176:0db9c1fc8213
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Tue Nov 22 13:29:01 2011 +0000
    
    xsm/flask: Use correct flag to detect writable grant mappings
    
    The flags passed to xsm_grant_mapref are the flags from the map
    operation (GNTMAP_*), not status flags (GTF_*).
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24175:2bc6c29b14a7
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:27:19 2011 +0000
    
    amd iommu: Support INVALIDATE_IOMMU_ALL command.
    
    It is one of the new architectural commands supported by iommu v2.
    It instructs iommu to clear all address translation and interrupt
    remapping caches for all devices and all domains.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24174:9a5e973305a8
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:46 2011 +0000
    
    amd iommu: Factor out iommu command handling functions,
    and move them into a new file.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24173:28c295c82ff6
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:26:11 2011 +0000
    
    amd iommu: Fix incorrect definitions.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24172:883f1c35810e
user:        Wei Wang <wei.wang2@amd.com>
date:        Tue Nov 22 13:25:42 2011 +0000
    
    amd iommu: Advertise iommu extended feature bits to xen.
    
    Signed-off-by: Wei Wang <wei.wang2@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24171:fe80909663c1
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 13:00:21 2011 +0000
    
    x86,waitqueue: Allocate whole page for shadow stack.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24170:334d3ec1130c
user:        Keir Fraser <keir@xen.org>
date:        Tue Nov 22 12:53:48 2011 +0000
    
    x86,vmx: Remove broken and unused __vmptrst().
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24169:0a0c02a61676
user:        Keir Fraser <keir@xen.org>
date:        Mon Nov 21 21:28:34 2011 +0000
    
    hvmloader: Fix memory relocation loop.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit 9b33a3e5603ecd3ceca482a72c6ff8e951afb6d2
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Nov 22 16:12:40 2011 +0000

    qemu-xen: add vkbd support for PV on HVM guests
    
    Register the vkbd backend even when running as device emulator for HVM
    guests: it is useful because it doesn't need a frequent timer like usb.
    
    Check whether the XenInput DisplayState has been set in the initialise
    state, rather than the input state.
    In case the DisplayState hasn't been set and there is no vfb for this
    domain, then set the XenInput DisplayState to the default one.
    
    An equivalent patch has already been committed in upstream qemu.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 06:27:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 06:27:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTSlm-0003d3-UM; Thu, 24 Nov 2011 06:26:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RTSll-0003cy-Gf
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 06:26:49 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322115949!58468647!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22503 invoked from network); 24 Nov 2011 06:25:50 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 06:25:50 -0000
Received: by ghbz2 with SMTP id z2so3189702ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 22:26:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=+Vw1GiBG5qFyWNoQHfIHS3C3c867oYYrYNOL8CmhKLs=;
	b=M71K3i5Hv+heTTE5lfdE/DfQwIsWu4gptBX3GtiThWPjl+ZgGiuDAVVmVq4kaOTBRu
	H0FvHUkJl68SKoLSR4UkJNfsOC/tSUSzU3d3fN/DW6w4pbuwRdHUgH0W6w89mLVmj8Yx
	Dfkd3y/vQXNolHkOLYr6cJ6N2PhrL07bxePwE=
MIME-Version: 1.0
Received: by 10.68.20.234 with SMTP id q10mr14893309pbe.27.1322115980654; Wed,
	23 Nov 2011 22:26:20 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Wed, 23 Nov 2011 22:26:20 -0800 (PST)
In-Reply-To: <1322052824.1005.100.camel@zakaz.uk.xensource.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
	<1322048085.1005.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
	<1322049282.1005.90.camel@zakaz.uk.xensource.com>
	<CAEwRVpOVmfKGzL7jFd8k9mH06Ct0tXhb6rZeYnrVpgR3x+mC1Q@mail.gmail.com>
	<1322052824.1005.100.camel@zakaz.uk.xensource.com>
Date: Thu, 24 Nov 2011 14:26:20 +0800
Message-ID: <CAEwRVpOg148+JJhgX0jvMDwzGZHQ+oCZ=4V4-aY=H5_w==0Hog@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, 2011 at 8:53 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Wed, 2011-11-23 at 11:59 +0000, Teck Choon Giam wrote:
>> I will repost later. =A0Just one question... ... do you guys prefer such
>> reports to be posted in xen-users or xen-devel mailing list?
>> Sometimes I wonder which one is more suitable... ...
>
> Generally most issues are best taken to xen-users in the first instance
> (since the most common cause is misconfiguration or user error).
> xen-devel is appropriate when there has been shown to be a bug in the
> code or xen-users has proved unsuccessful etc.
>
> Looking at your original mail I think you might want to include some
> more details and logs etc when you repost.
> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen has a list of
> various useful logs to include.

Noted and thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 06:27:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 06:27:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTSlm-0003d3-UM; Thu, 24 Nov 2011 06:26:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1RTSll-0003cy-Gf
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 06:26:49 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322115949!58468647!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22503 invoked from network); 24 Nov 2011 06:25:50 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 06:25:50 -0000
Received: by ghbz2 with SMTP id z2so3189702ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 23 Nov 2011 22:26:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=+Vw1GiBG5qFyWNoQHfIHS3C3c867oYYrYNOL8CmhKLs=;
	b=M71K3i5Hv+heTTE5lfdE/DfQwIsWu4gptBX3GtiThWPjl+ZgGiuDAVVmVq4kaOTBRu
	H0FvHUkJl68SKoLSR4UkJNfsOC/tSUSzU3d3fN/DW6w4pbuwRdHUgH0W6w89mLVmj8Yx
	Dfkd3y/vQXNolHkOLYr6cJ6N2PhrL07bxePwE=
MIME-Version: 1.0
Received: by 10.68.20.234 with SMTP id q10mr14893309pbe.27.1322115980654; Wed,
	23 Nov 2011 22:26:20 -0800 (PST)
Received: by 10.68.58.233 with HTTP; Wed, 23 Nov 2011 22:26:20 -0800 (PST)
In-Reply-To: <1322052824.1005.100.camel@zakaz.uk.xensource.com>
References: <CAEwRVpObp89PW5LdrxdaBmyU+UzffXYM0bJApHJqAGU8f+RiHA@mail.gmail.com>
	<1321946469.20464.12.camel@dagon.hellion.org.uk>
	<CAEwRVpMWnL9wnvrqEJUx9R14wX6PRqjmxEPQq7dcKGd9sCvHFA@mail.gmail.com>
	<1321949903.20464.19.camel@dagon.hellion.org.uk>
	<CAEwRVpM+jBXs78XeTdJ2Hez+Y94tLVGQ3Sjbttfuu2vouqHnSA@mail.gmail.com>
	<1321950680.20464.20.camel@dagon.hellion.org.uk>
	<CAEwRVpMmFqtCRQUzUrww3yAzJYfva8fRFXfxQGXQVRBxFxn5PQ@mail.gmail.com>
	<1321952996.3664.401.camel@zakaz.uk.xensource.com>
	<CAEwRVpN_HtrAAr+mDkD4imf51bft3UMvjcH=YNydYsB6jch7Fg@mail.gmail.com>
	<alpine.DEB.2.00.1111221114160.31179@kaball-desktop>
	<CAEwRVpNOw3ONYMsWpnMuY6+TCpHFwx6biA3obO+kKQEH6EXWRA@mail.gmail.com>
	<alpine.DEB.2.00.1111231055330.31179@kaball-desktop>
	<1322046437.1005.62.camel@zakaz.uk.xensource.com>
	<CAEwRVpPdFDqhLDy0qrehkOSgKnuLSsQLcDwKyWok_p5Pk2giYA@mail.gmail.com>
	<1322048085.1005.81.camel@zakaz.uk.xensource.com>
	<CAEwRVpPLcBNLz45iavVWMDd=o59U9kgDkA67cMz75fA+kE0yaQ@mail.gmail.com>
	<1322049282.1005.90.camel@zakaz.uk.xensource.com>
	<CAEwRVpOVmfKGzL7jFd8k9mH06Ct0tXhb6rZeYnrVpgR3x+mC1Q@mail.gmail.com>
	<1322052824.1005.100.camel@zakaz.uk.xensource.com>
Date: Thu, 24 Nov 2011 14:26:20 +0800
Message-ID: <CAEwRVpOg148+JJhgX0jvMDwzGZHQ+oCZ=4V4-aY=H5_w==0Hog@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] libxl: error: libxl.c:2150:libxl_set_memory_target
 new target 0 for dom0 is below the minimum threshold
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, 2011 at 8:53 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Wed, 2011-11-23 at 11:59 +0000, Teck Choon Giam wrote:
>> I will repost later. =A0Just one question... ... do you guys prefer such
>> reports to be posted in xen-users or xen-devel mailing list?
>> Sometimes I wonder which one is more suitable... ...
>
> Generally most issues are best taken to xen-users in the first instance
> (since the most common cause is misconfiguration or user error).
> xen-devel is appropriate when there has been shown to be a bug in the
> code or xen-users has proved unsuccessful etc.
>
> Looking at your original mail I think you might want to include some
> more details and logs etc when you repost.
> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen has a list of
> various useful logs to include.

Noted and thanks.

Kindest regards,
Giam Teck Choon

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 08:39:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 08:39:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTUpZ-0005bb-J8; Thu, 24 Nov 2011 08:38:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTUpX-0005bW-Dk
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 08:38:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322123872!54347831!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11415 invoked from network); 24 Nov 2011 08:37:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 08:37:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9104919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 08:38:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 08:38:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Florian Heigl <florian.heigl@gmail.com>
In-Reply-To: <CAFivhPnQVSAPq7cUv4H-aZn_P79f0_CyrJGaRnP4BFAeGBKQJg@mail.gmail.com>
References: <CAFivhPnQVSAPq7cUv4H-aZn_P79f0_CyrJGaRnP4BFAeGBKQJg@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 08:38:24 +0000
Message-ID: <1322123905.9567.32.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Can domU config add userdefined keys to Xenstore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 20:11 +0000, Florian Heigl wrote:
> Hi,
> 
> I wonder if there is some (crazy, useful, your choice) way to do the
> equivalent of the following commands while a new VM is built.
> (much like adding usb or pci devices works)
> 
> xenstore-write /local/domain/<id>/new_node "Null"
> xenstore-chmod /local/domain/<id>/new_node w
> 
> I would like to create the entry right at domU launch, and I'd like to
> make use of Xens knowledge of the domU ID it'll use, because the changing
> domU ID is a grief.

FWIW you can use "xl domid <name>" in your scripts.

> Also, it would of course be much saner to do it in the VM config
> instead via some watch-daemon or even udev rules.

You could just start the VM paused, use "xl domid" to setup your keys
and then unpause?

If you are using xapi then VM.xenstore_data is a list of key-value pairs
which is written xenstore. AFAICT The key is relative to
to /local/domain/<id> and must start "vm-data/..." (i.e. you can only
write to keys under /local/domain/<id>/vm-data/ using this mechanism).

I suspect you aren't using xapi but the reason I mention it is that
someone added libxl_domain_create_info.xsdata in the early days of
libxl, presumably with this purpose in mind, but it appears not to be
hooked up into the xl configuration parser. I expect doing so would be a
reasonably simply job.

Another, possibly more flexible but more complex option, would be to
allow for a series of hook scripts (both global and domain specific?) to
be called at various points in a VM lifecylce, including after building
but before starting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 08:39:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 08:39:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTUpZ-0005bb-J8; Thu, 24 Nov 2011 08:38:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTUpX-0005bW-Dk
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 08:38:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322123872!54347831!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11415 invoked from network); 24 Nov 2011 08:37:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 08:37:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9104919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 08:38:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 08:38:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Florian Heigl <florian.heigl@gmail.com>
In-Reply-To: <CAFivhPnQVSAPq7cUv4H-aZn_P79f0_CyrJGaRnP4BFAeGBKQJg@mail.gmail.com>
References: <CAFivhPnQVSAPq7cUv4H-aZn_P79f0_CyrJGaRnP4BFAeGBKQJg@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 08:38:24 +0000
Message-ID: <1322123905.9567.32.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Can domU config add userdefined keys to Xenstore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 20:11 +0000, Florian Heigl wrote:
> Hi,
> 
> I wonder if there is some (crazy, useful, your choice) way to do the
> equivalent of the following commands while a new VM is built.
> (much like adding usb or pci devices works)
> 
> xenstore-write /local/domain/<id>/new_node "Null"
> xenstore-chmod /local/domain/<id>/new_node w
> 
> I would like to create the entry right at domU launch, and I'd like to
> make use of Xens knowledge of the domU ID it'll use, because the changing
> domU ID is a grief.

FWIW you can use "xl domid <name>" in your scripts.

> Also, it would of course be much saner to do it in the VM config
> instead via some watch-daemon or even udev rules.

You could just start the VM paused, use "xl domid" to setup your keys
and then unpause?

If you are using xapi then VM.xenstore_data is a list of key-value pairs
which is written xenstore. AFAICT The key is relative to
to /local/domain/<id> and must start "vm-data/..." (i.e. you can only
write to keys under /local/domain/<id>/vm-data/ using this mechanism).

I suspect you aren't using xapi but the reason I mention it is that
someone added libxl_domain_create_info.xsdata in the early days of
libxl, presumably with this purpose in mind, but it appears not to be
hooked up into the xl configuration parser. I expect doing so would be a
reasonably simply job.

Another, possibly more flexible but more complex option, would be to
allow for a series of hook scripts (both global and domain specific?) to
be called at various points in a VM lifecylce, including after building
but before starting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 08:42:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 08:42:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTUsn-0005jv-6m; Thu, 24 Nov 2011 08:42:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTUsm-0005jq-BT
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 08:42:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322124091!56273029!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1975 invoked from network); 24 Nov 2011 08:41:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 08:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9105098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 08:41:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 08:41:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>, Konrad Rzeszutek
	Wilk <konrad.wilk@oracle.com>, Jeremy Fitzhardinge <jeremy@goop.org>
In-Reply-To: <CAHHxriBEsA-23K5QMe3eE-=8Ca6mbsQ4x7C0TG+ap_TRv2vXbg@mail.gmail.com>
References: <CAHHxriBEsA-23K5QMe3eE-=8Ca6mbsQ4x7C0TG+ap_TRv2vXbg@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 08:41:18 +0000
Message-ID: <1322124079.9567.36.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [patch] Initialize xen_vcpu0 before initialize
 irq_ops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CC'ing Xen Liunx maintainers, please consult MAINTAINERS or
use ./scripts/get_maintainer.pl.

On Wed, 2011-11-23 at 18:56 +0000, Anthoine Bourgeois wrote:
> Hello,
> 
> I find a strange behavior. When a machine is slow (or with many debug
> traces or a qemu vm),
> a interrupt can occur between the pv_irq_ops initialization and the xen_vcpu[0]
> initialization. This lead to a problem because some operations in
> xen_irq_ops use
> xen_vcpu.
> I send you a patch to fix that but I'm not quite sure that is the
> right solution.
> 
> Regards,
> Anthoine
> 
> From ac683ad8264f83fa0a5d743e18c0422e43e871d2 Mon Sep 17 00:00:00 2001
> From: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
> Date: Wed, 23 Nov 2011 19:23:42 +0100
> Subject: [PATCH] Initialize xen_vcpu0 before initialize irq_ops.
> 
> xen_vcpu is used by
> xen_irq_ops.xen_{save_fl,restore_fl,irq_disable,irq_enable} and should
> be initialized before xen_init_irq_ops that initialize the pv_irq_ops
> with it. If not, a call to those functions could lead to a deference of
> NULL pointer.  This behaviour was find with a slow machine or qemu.

Can you provide an example of the stack trace which leads to this
please.

> ---
>  arch/x86/xen/enlighten.c |    7 ++++---
>  1 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 2d69617..a8111a0 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1166,6 +1166,10 @@ asmlinkage void __init xen_start_kernel(void)
>          */
>         xen_setup_stackprotector();
> 
> +       /* Don't do the full vcpu_info placement stuff until we have a
> +          possible map and a non-dummy shared_info. */
> +       per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> +
>         xen_init_irq_ops();
>         xen_init_cpuid_mask();
> 
> @@ -1207,9 +1211,6 @@ asmlinkage void __init xen_start_kernel(void)
>                 __supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
> 
>         __supported_pte_mask |= _PAGE_IOMAP;
> -       /* Don't do the full vcpu_info placement stuff until we have a
> -          possible map and a non-dummy shared_info. */
> -       per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> 
>         local_irq_disable();
>         early_boot_irqs_disabled = true;

This local_irq_disable is interesting. Aren't IRQs supposed to already
be disabled from entry to xen_start_kernel (really, since start of time)
until at least this point?

Enabling (or disabling) interrupts would require both xen_init_irq_ops()
and xen_vcpu[0] to be setup, so it seems that either interrupts are not
disabled at start of day (I'm fairly sure they are) or there is some
magic code somewhere which does it directly without using the generic
infrastructure (I can't find anything like that).

So where do interrupts get enabled? Is before xen_init_irq_ops really
early enough? I can't find anything between the old and new locations of
this setup code which looks like it would enable them. It is possible
that you just win the race on your slow systems now but that the window
is still there.

Wherever this init goes I expect we would want to pull the
local_irq_disable and early_boot_irqs_disabled stuff along with it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 08:42:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 08:42:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTUsn-0005jv-6m; Thu, 24 Nov 2011 08:42:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTUsm-0005jq-BT
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 08:42:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322124091!56273029!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1975 invoked from network); 24 Nov 2011 08:41:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 08:41:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9105098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 08:41:19 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 08:41:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>, Konrad Rzeszutek
	Wilk <konrad.wilk@oracle.com>, Jeremy Fitzhardinge <jeremy@goop.org>
In-Reply-To: <CAHHxriBEsA-23K5QMe3eE-=8Ca6mbsQ4x7C0TG+ap_TRv2vXbg@mail.gmail.com>
References: <CAHHxriBEsA-23K5QMe3eE-=8Ca6mbsQ4x7C0TG+ap_TRv2vXbg@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 08:41:18 +0000
Message-ID: <1322124079.9567.36.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [patch] Initialize xen_vcpu0 before initialize
 irq_ops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CC'ing Xen Liunx maintainers, please consult MAINTAINERS or
use ./scripts/get_maintainer.pl.

On Wed, 2011-11-23 at 18:56 +0000, Anthoine Bourgeois wrote:
> Hello,
> 
> I find a strange behavior. When a machine is slow (or with many debug
> traces or a qemu vm),
> a interrupt can occur between the pv_irq_ops initialization and the xen_vcpu[0]
> initialization. This lead to a problem because some operations in
> xen_irq_ops use
> xen_vcpu.
> I send you a patch to fix that but I'm not quite sure that is the
> right solution.
> 
> Regards,
> Anthoine
> 
> From ac683ad8264f83fa0a5d743e18c0422e43e871d2 Mon Sep 17 00:00:00 2001
> From: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
> Date: Wed, 23 Nov 2011 19:23:42 +0100
> Subject: [PATCH] Initialize xen_vcpu0 before initialize irq_ops.
> 
> xen_vcpu is used by
> xen_irq_ops.xen_{save_fl,restore_fl,irq_disable,irq_enable} and should
> be initialized before xen_init_irq_ops that initialize the pv_irq_ops
> with it. If not, a call to those functions could lead to a deference of
> NULL pointer.  This behaviour was find with a slow machine or qemu.

Can you provide an example of the stack trace which leads to this
please.

> ---
>  arch/x86/xen/enlighten.c |    7 ++++---
>  1 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 2d69617..a8111a0 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1166,6 +1166,10 @@ asmlinkage void __init xen_start_kernel(void)
>          */
>         xen_setup_stackprotector();
> 
> +       /* Don't do the full vcpu_info placement stuff until we have a
> +          possible map and a non-dummy shared_info. */
> +       per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> +
>         xen_init_irq_ops();
>         xen_init_cpuid_mask();
> 
> @@ -1207,9 +1211,6 @@ asmlinkage void __init xen_start_kernel(void)
>                 __supported_pte_mask &= ~(_PAGE_PWT | _PAGE_PCD);
> 
>         __supported_pte_mask |= _PAGE_IOMAP;
> -       /* Don't do the full vcpu_info placement stuff until we have a
> -          possible map and a non-dummy shared_info. */
> -       per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> 
>         local_irq_disable();
>         early_boot_irqs_disabled = true;

This local_irq_disable is interesting. Aren't IRQs supposed to already
be disabled from entry to xen_start_kernel (really, since start of time)
until at least this point?

Enabling (or disabling) interrupts would require both xen_init_irq_ops()
and xen_vcpu[0] to be setup, so it seems that either interrupts are not
disabled at start of day (I'm fairly sure they are) or there is some
magic code somewhere which does it directly without using the generic
infrastructure (I can't find anything like that).

So where do interrupts get enabled? Is before xen_init_irq_ops really
early enough? I can't find anything between the old and new locations of
this setup code which looks like it would enable them. It is possible
that you just win the race on your slow systems now but that the window
is still there.

Wherever this init goes I expect we would want to pull the
local_irq_disable and early_boot_irqs_disabled stuff along with it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVPW-0006Do-Ak; Thu, 24 Nov 2011 09:16:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTVPU-0006Dj-PP
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:16:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322126129!6121964!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24119 invoked from network); 24 Nov 2011 09:15:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 09:15:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 09:15:29 +0000
Message-Id: <4ECE19400200007800062E4A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 09:15:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <CAF2F84A.2571A%keir.xen@gmail.com>
	<CAF3102F.25730%keir.xen@gmail.com>
In-Reply-To: <CAF3102F.25730%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.11.11 at 22:03, Keir Fraser <keir.xen@gmail.com> wrote:
> On 23/11/2011 19:21, "Keir Fraser" <keir.xen@gmail.com> wrote:
> 
>> On 23/11/2011 18:31, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>>> On Wed, Nov 23, Keir Fraser wrote:
>>> 
>>>> We have quite a big waitqueue problem actually. The current scheme of
>>>> per-cpu stacks doesn't work nicely, as the stack pointer will change if a
>>>> vcpu goes to sleep and then wakes up on a different cpu. This really doesn't
>>>> work nicely with preempted C code, which may implement frame pointers and/or
>>>> arbitrarily take the address of on-stack variables. The result will be
>>>> hideous cross-stack corruptions, as these frame pointers and cached
>>>> addresses of automatic variables will reference the wrong cpu's stack!
>>>> Fixing or detecting this in general is not possible afaics.
>>> 
>>> Yes, I was thinking about that wakeup on different cpu as well.
>>> As a quick fix/hack, perhaps the scheduler could make sure the vcpu
>>> wakes up on the same cpu?
>> 
>> Could save old affinity and then vcpu_set_affinity. That will have to do for
>> now. Actually it should work okay as long as toolstack doesn't mess with
>> affinity meanwhile. I'll sort out a patch for this.
> 
> Attached three patches for you to try. They apply in sequence.
> 00: A fixed version of "domain_crash on stack overflow"
> 01: Reorders prepare_to_wait so that the vcpu will always be on the
> waitqueue on exit (even if it has just been woken).
> 02: Ensures the vcpu wakes up on the same cpu that it slept on.

Didn't we (long ago) settle on not permitting new calls to
domain_crash_synchronous()? Is it really impossible to just
domain_crash() in any of the instances these add?

Jan

> We need all of these. Just need testing to make sure they aren't horribly
> broken. You should be able to test multi-processor host again with these.
> 
>  -- Keir
> 
>>  -- Keir
>> 
>>> Olaf
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVPW-0006Do-Ak; Thu, 24 Nov 2011 09:16:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTVPU-0006Dj-PP
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:16:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322126129!6121964!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24119 invoked from network); 24 Nov 2011 09:15:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 09:15:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 09:15:29 +0000
Message-Id: <4ECE19400200007800062E4A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 09:15:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <CAF2F84A.2571A%keir.xen@gmail.com>
	<CAF3102F.25730%keir.xen@gmail.com>
In-Reply-To: <CAF3102F.25730%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.11.11 at 22:03, Keir Fraser <keir.xen@gmail.com> wrote:
> On 23/11/2011 19:21, "Keir Fraser" <keir.xen@gmail.com> wrote:
> 
>> On 23/11/2011 18:31, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>>> On Wed, Nov 23, Keir Fraser wrote:
>>> 
>>>> We have quite a big waitqueue problem actually. The current scheme of
>>>> per-cpu stacks doesn't work nicely, as the stack pointer will change if a
>>>> vcpu goes to sleep and then wakes up on a different cpu. This really doesn't
>>>> work nicely with preempted C code, which may implement frame pointers and/or
>>>> arbitrarily take the address of on-stack variables. The result will be
>>>> hideous cross-stack corruptions, as these frame pointers and cached
>>>> addresses of automatic variables will reference the wrong cpu's stack!
>>>> Fixing or detecting this in general is not possible afaics.
>>> 
>>> Yes, I was thinking about that wakeup on different cpu as well.
>>> As a quick fix/hack, perhaps the scheduler could make sure the vcpu
>>> wakes up on the same cpu?
>> 
>> Could save old affinity and then vcpu_set_affinity. That will have to do for
>> now. Actually it should work okay as long as toolstack doesn't mess with
>> affinity meanwhile. I'll sort out a patch for this.
> 
> Attached three patches for you to try. They apply in sequence.
> 00: A fixed version of "domain_crash on stack overflow"
> 01: Reorders prepare_to_wait so that the vcpu will always be on the
> waitqueue on exit (even if it has just been woken).
> 02: Ensures the vcpu wakes up on the same cpu that it slept on.

Didn't we (long ago) settle on not permitting new calls to
domain_crash_synchronous()? Is it really impossible to just
domain_crash() in any of the instances these add?

Jan

> We need all of these. Just need testing to make sure they aren't horribly
> broken. You should be able to test multi-processor host again with these.
> 
>  -- Keir
> 
>>  -- Keir
>> 
>>> Olaf
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:23:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVWP-0006Nk-Bc; Thu, 24 Nov 2011 09:23:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTVWN-0006NX-Vx
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:23:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322126556!5536572!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14203 invoked from network); 24 Nov 2011 09:22:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 09:22:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9106222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 09:22:36 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 09:22:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 09:22:35 +0000
Message-ID: <1322126555.9567.39.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] Migration on QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 17:40 +0000, Anthony PERARD wrote:
> Hi all,
> 
> This patch series introduce migration with QEMU upstream.
> 
> A patch series for QEMU will be sent later meant to "fix" the default behavior
> of QEMU during save/restore.
> 
> There is two new QMP commands implemented:
>   - getfd: This give a file descriptor to QEMU through the unix socket.

This sounds more like a setfd command.

>   - migration: This ask QEMU to save its states in a fd previously sent.

Why can the fd not be included in this message directly? How is a given
{s,g}etfd call associated with the migration command? What happens if
some other command also wants to receive an fd in the future?

I presume that a bunch of this will become  more obvious when the qemu
side is posted, there's a qemu protocol spec in that right?

> In order to call "getfd", an alternative qmp_send have been implemented in
> libxl.

You could also have added optional msg_control{len} parameters to the
existing command. I don't know if that is better though.

Ian.

> 
> Regards,
> 
> 
> Anthony PERARD (3):
>   libxl_qmp: Cut qmp_send function.
>   libxl_qmp: Command migrate.
>   libxl: Introduce migrate with the new QEMU.
> 
>  tools/libxl/libxl_dm.c       |    6 +-
>  tools/libxl/libxl_dom.c      |   28 +++++++-
>  tools/libxl/libxl_internal.h |    2 +
>  tools/libxl/libxl_qmp.c      |  161 +++++++++++++++++++++++++++++++++++++----
>  4 files changed, 176 insertions(+), 21 deletions(-)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:23:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVWP-0006Nk-Bc; Thu, 24 Nov 2011 09:23:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTVWN-0006NX-Vx
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:23:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322126556!5536572!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14203 invoked from network); 24 Nov 2011 09:22:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 09:22:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9106222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 09:22:36 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 09:22:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 09:22:35 +0000
Message-ID: <1322126555.9567.39.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] Migration on QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-23 at 17:40 +0000, Anthony PERARD wrote:
> Hi all,
> 
> This patch series introduce migration with QEMU upstream.
> 
> A patch series for QEMU will be sent later meant to "fix" the default behavior
> of QEMU during save/restore.
> 
> There is two new QMP commands implemented:
>   - getfd: This give a file descriptor to QEMU through the unix socket.

This sounds more like a setfd command.

>   - migration: This ask QEMU to save its states in a fd previously sent.

Why can the fd not be included in this message directly? How is a given
{s,g}etfd call associated with the migration command? What happens if
some other command also wants to receive an fd in the future?

I presume that a bunch of this will become  more obvious when the qemu
side is posted, there's a qemu protocol spec in that right?

> In order to call "getfd", an alternative qmp_send have been implemented in
> libxl.

You could also have added optional msg_control{len} parameters to the
existing command. I don't know if that is better though.

Ian.

> 
> Regards,
> 
> 
> Anthony PERARD (3):
>   libxl_qmp: Cut qmp_send function.
>   libxl_qmp: Command migrate.
>   libxl: Introduce migrate with the new QEMU.
> 
>  tools/libxl/libxl_dm.c       |    6 +-
>  tools/libxl/libxl_dom.c      |   28 +++++++-
>  tools/libxl/libxl_internal.h |    2 +
>  tools/libxl/libxl_qmp.c      |  161 +++++++++++++++++++++++++++++++++++++----
>  4 files changed, 176 insertions(+), 21 deletions(-)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:24:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:24:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVWs-0006PD-Pk; Thu, 24 Nov 2011 09:23:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTVWq-0006Ox-T4
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:23:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322126585!2839592!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32018 invoked from network); 24 Nov 2011 09:23:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 09:23:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 09:23:04 +0000
Message-Id: <4ECE1B070200007800062E5D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 09:23:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 00 of 14] MM Fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> This patch series includes a number of bug fixes, targetting 
> primarily the mm layer. Many of these fixes also lay groundwork
> for future patches.

Only 10 (or 11) of the advertised 14 patches actually arrived - in the
mailing list archive patches 4 and 12-14 are missing, and in my mailbox
I got directly addressed (due to being on Cc) 1-10 and through
xen-devel 1-11.

What's going on here?

Jan

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
>  xen/arch/x86/mm/p2m-pod.c          |   1 -
>  xen/arch/x86/mm/p2m-pt.c           |   9 +++-
>  xen/arch/x86/mm/p2m.c              |   5 +-
>  xen/arch/x86/mm/hap/hap.c          |   2 +
>  tools/libxc/xc_domain.c            |   2 +
>  xen/arch/x86/mm/shadow/common.c    |   4 +-
>  xen/arch/x86/mm/hap/hap.c          |  15 ++++++--
>  xen/arch/x86/mm/hap/hap.c          |   2 +-
>  xen/drivers/char/ns16550.c         |   2 +-
>  xen/arch/x86/mm/p2m.c              |   4 +-
>  xen/include/asm-x86/p2m.h          |   3 +-
>  xen/arch/x86/hvm/hvm.c             |  10 ++++-
>  xen/arch/x86/mm.c                  |   5 ++-
>  xen/arch/x86/hvm/hvm.c             |  69 ++++++++++++++++++++++++-------------
>  xen/arch/x86/hvm/nestedhvm.c       |   4 +-
>  xen/arch/x86/hvm/svm/nestedsvm.c   |  23 ++++++------
>  xen/arch/x86/hvm/vmx/vvmx.c        |  36 +++++++++++--------
>  xen/include/asm-x86/hvm/hvm.h      |   9 +++-
>  xen/include/asm-x86/hvm/vcpu.h     |   1 +
>  xen/include/asm-x86/hvm/vmx/vvmx.h |   1 +
>  xen/arch/x86/mm/guest_walk.c       |  16 ++++++--
>  xen/common/grant_table.c           |  69 ++++++++++++++++++++-----------------
>  22 files changed, 182 insertions(+), 110 deletions(-)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:24:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:24:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVWs-0006PD-Pk; Thu, 24 Nov 2011 09:23:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTVWq-0006Ox-T4
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:23:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322126585!2839592!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32018 invoked from network); 24 Nov 2011 09:23:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 09:23:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 09:23:04 +0000
Message-Id: <4ECE1B070200007800062E5D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 09:23:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 00 of 14] MM Fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> This patch series includes a number of bug fixes, targetting 
> primarily the mm layer. Many of these fixes also lay groundwork
> for future patches.

Only 10 (or 11) of the advertised 14 patches actually arrived - in the
mailing list archive patches 4 and 12-14 are missing, and in my mailbox
I got directly addressed (due to being on Cc) 1-10 and through
xen-devel 1-11.

What's going on here?

Jan

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
>  xen/arch/x86/mm/p2m-pod.c          |   1 -
>  xen/arch/x86/mm/p2m-pt.c           |   9 +++-
>  xen/arch/x86/mm/p2m.c              |   5 +-
>  xen/arch/x86/mm/hap/hap.c          |   2 +
>  tools/libxc/xc_domain.c            |   2 +
>  xen/arch/x86/mm/shadow/common.c    |   4 +-
>  xen/arch/x86/mm/hap/hap.c          |  15 ++++++--
>  xen/arch/x86/mm/hap/hap.c          |   2 +-
>  xen/drivers/char/ns16550.c         |   2 +-
>  xen/arch/x86/mm/p2m.c              |   4 +-
>  xen/include/asm-x86/p2m.h          |   3 +-
>  xen/arch/x86/hvm/hvm.c             |  10 ++++-
>  xen/arch/x86/mm.c                  |   5 ++-
>  xen/arch/x86/hvm/hvm.c             |  69 ++++++++++++++++++++++++-------------
>  xen/arch/x86/hvm/nestedhvm.c       |   4 +-
>  xen/arch/x86/hvm/svm/nestedsvm.c   |  23 ++++++------
>  xen/arch/x86/hvm/vmx/vvmx.c        |  36 +++++++++++--------
>  xen/include/asm-x86/hvm/hvm.h      |   9 +++-
>  xen/include/asm-x86/hvm/vcpu.h     |   1 +
>  xen/include/asm-x86/hvm/vmx/vvmx.h |   1 +
>  xen/arch/x86/mm/guest_walk.c       |  16 ++++++--
>  xen/common/grant_table.c           |  69 ++++++++++++++++++++-----------------
>  22 files changed, 182 insertions(+), 110 deletions(-)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:37:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:37:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVjS-00070L-PG; Thu, 24 Nov 2011 09:36:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTVjR-00070E-Ew
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:36:37 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322127366!4777356!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23619 invoked from network); 24 Nov 2011 09:36:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 09:36:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9106627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 09:36:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 09:36:05 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTViv-0004GL-KN;
	Thu, 24 Nov 2011 09:36:05 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTVih-0007jt-WE;
	Thu, 24 Nov 2011 09:35:52 +0000
Date: Thu, 24 Nov 2011 09:35:51 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111124093551.GC22563@spongy.cam.xci-test.com>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF2DBD2.256F3%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11 05:20, Keir Fraser wrote:
> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> 
> > 
> > The Intel GPU uses a two pages NVS region called OpRegion.
> > In order to get full support for the driver in the guest
> > we need to map this region.
> > 
> > This patch reserves 2 pages on the top of the RAM and
> > mark this region as NVS in the e820. Then we write the
> > address to the config space (offset 0xfc) so the device
> > model can map the OpRegion at this address in the guest.
> 
> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> 

I'm calling mem_hole_alloc() in pci_setup (see patch attached),
but that causes an overlap in e820, is that expected?

(XEN) HVM5: E820 table:
(XEN) HVM5:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM5:  [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
(XEN) HVM5:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM5:  [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM5:  [03]: 00000000:00100000 - 00000000:3f800000: RAM
(XEN) HVM5:  HOLE: 00000000:3f800000 - 00000000:feff8000
(XEN) HVM5:  [04]: 00000000:feff8000 - 00000000:feffa000: NVS
(XEN) HVM5:  OVERLAP!!
(XEN) HVM5:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:37:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:37:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVjS-00070L-PG; Thu, 24 Nov 2011 09:36:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTVjR-00070E-Ew
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:36:37 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322127366!4777356!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23619 invoked from network); 24 Nov 2011 09:36:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 09:36:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9106627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 09:36:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 09:36:05 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTViv-0004GL-KN;
	Thu, 24 Nov 2011 09:36:05 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTVih-0007jt-WE;
	Thu, 24 Nov 2011 09:35:52 +0000
Date: Thu, 24 Nov 2011 09:35:51 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111124093551.GC22563@spongy.cam.xci-test.com>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF2DBD2.256F3%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11 05:20, Keir Fraser wrote:
> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> 
> > 
> > The Intel GPU uses a two pages NVS region called OpRegion.
> > In order to get full support for the driver in the guest
> > we need to map this region.
> > 
> > This patch reserves 2 pages on the top of the RAM and
> > mark this region as NVS in the e820. Then we write the
> > address to the config space (offset 0xfc) so the device
> > model can map the OpRegion at this address in the guest.
> 
> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> 

I'm calling mem_hole_alloc() in pci_setup (see patch attached),
but that causes an overlap in e820, is that expected?

(XEN) HVM5: E820 table:
(XEN) HVM5:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM5:  [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
(XEN) HVM5:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM5:  [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM5:  [03]: 00000000:00100000 - 00000000:3f800000: RAM
(XEN) HVM5:  HOLE: 00000000:3f800000 - 00000000:feff8000
(XEN) HVM5:  [04]: 00000000:feff8000 - 00000000:feffa000: NVS
(XEN) HVM5:  OVERLAP!!
(XEN) HVM5:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:49:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVvR-0007H1-5J; Thu, 24 Nov 2011 09:49:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTVvP-0007Gv-Ko
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:48:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322128072!64463667!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15609 invoked from network); 24 Nov 2011 09:47:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 09:47:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 09:48:33 +0000
Message-Id: <4ECE20FF0200007800062E93@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 09:48:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
In-Reply-To: <e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 05 of 14] Don't trigger unnecessary shadow
 scans on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> xen/arch/x86/mm/shadow/common.c |  4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> 
> When updating a p2m entry, the hypervisor scans all shadow pte's to find
> mappings of that gfn and tear them down. This is avoided if the page count
> reveals that there are no additional mappings. The current test ignores the
> PGC_allocated flag and its effect on the page count.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r 93066bdc1e1c -r e8f0709af2b7 xen/arch/x86/mm/shadow/common.c
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -2501,7 +2501,8 @@ int sh_remove_all_mappings(struct vcpu *
>          ;
>  
>      perfc_incr(shadow_mappings);
> -    if ( (page->count_info & PGC_count_mask) == 0 )
> +    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
> +    if ( (page->count_info & PGC_count_mask) == expected_count )

Is that really valid outside the locked region?

>          return 0;
>  
>      /* Although this is an externally visible function, we do not know
> @@ -2517,7 +2518,6 @@ int sh_remove_all_mappings(struct vcpu *
>      hash_foreach(v, callback_mask, callbacks, gmfn);
>  
>      /* If that didn't catch the mapping, something is very wrong */
> -    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;

This certainly isn't right - iiuc the count would normally have changed
during the hash_foreach() above this.

Jan

>      if ( (page->count_info & PGC_count_mask) != expected_count )
>      {
>          /* Don't complain if we're in HVM and there are some extra 
> mappings: 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:49:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:49:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVvR-0007H1-5J; Thu, 24 Nov 2011 09:49:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTVvP-0007Gv-Ko
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:48:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322128072!64463667!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15609 invoked from network); 24 Nov 2011 09:47:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 09:47:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 09:48:33 +0000
Message-Id: <4ECE20FF0200007800062E93@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 09:48:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
In-Reply-To: <e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 05 of 14] Don't trigger unnecessary shadow
 scans on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> xen/arch/x86/mm/shadow/common.c |  4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> 
> When updating a p2m entry, the hypervisor scans all shadow pte's to find
> mappings of that gfn and tear them down. This is avoided if the page count
> reveals that there are no additional mappings. The current test ignores the
> PGC_allocated flag and its effect on the page count.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r 93066bdc1e1c -r e8f0709af2b7 xen/arch/x86/mm/shadow/common.c
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -2501,7 +2501,8 @@ int sh_remove_all_mappings(struct vcpu *
>          ;
>  
>      perfc_incr(shadow_mappings);
> -    if ( (page->count_info & PGC_count_mask) == 0 )
> +    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
> +    if ( (page->count_info & PGC_count_mask) == expected_count )

Is that really valid outside the locked region?

>          return 0;
>  
>      /* Although this is an externally visible function, we do not know
> @@ -2517,7 +2518,6 @@ int sh_remove_all_mappings(struct vcpu *
>      hash_foreach(v, callback_mask, callbacks, gmfn);
>  
>      /* If that didn't catch the mapping, something is very wrong */
> -    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;

This certainly isn't right - iiuc the count would normally have changed
during the hash_foreach() above this.

Jan

>      if ( (page->count_info & PGC_count_mask) != expected_count )
>      {
>          /* Don't complain if we're in HVM and there are some extra 
> mappings: 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:52:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVyR-0007Mi-Pf; Thu, 24 Nov 2011 09:52:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTVyR-0007MQ-0W
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:52:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322128294!5519132!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24094 invoked from network); 24 Nov 2011 09:51:36 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 09:51:36 -0000
Received: by ghbz2 with SMTP id z2so3389932ghb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 01:51:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VNHm9VXHiciaAbqCPmqbLGdhIzTCslLXvGjZCxlEUdI=;
	b=B8ODNAVTVLkpn4WJrkATnG6m79NZbYGb+sBC5p+driRjv48sNUirN5cRcMC5iJBB4q
	K/FMZuHsbmXNLWbJoMiykK10sEwPPDEgsugVCccH5y8GxMcM4J18ZaqT1JnSSBiXwkR5
	J+051nc1rjSvHU3WENOITrPWOYiuNqdBIvd4E=
Received: by 10.152.136.2 with SMTP id pw2mr17063382lab.22.1322128294105;
	Thu, 24 Nov 2011 01:51:34 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id pi7sm18769406lab.5.2011.11.24.01.51.30
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 01:51:33 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 09:51:27 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CAF3C41F.34BDA%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqjqIvGnKiwPFDFUeERlqmWp9uSA==
In-Reply-To: <4ECE19400200007800062E4A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 09:15, "Jan Beulich" <JBeulich@suse.com> wrote:

>> 
>> Attached three patches for you to try. They apply in sequence.
>> 00: A fixed version of "domain_crash on stack overflow"
>> 01: Reorders prepare_to_wait so that the vcpu will always be on the
>> waitqueue on exit (even if it has just been woken).
>> 02: Ensures the vcpu wakes up on the same cpu that it slept on.
> 
> Didn't we (long ago) settle on not permitting new calls to
> domain_crash_synchronous()? Is it really impossible to just
> domain_crash() in any of the instances these add?

It's safe because you must be in a context that is safe to preempt. That's a
pre-condition for using a waitqueue. It's not safe to use domain_crash()
because the caller of wait_event() may not handle the exceptional return.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:52:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVyR-0007Mi-Pf; Thu, 24 Nov 2011 09:52:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTVyR-0007MQ-0W
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:52:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322128294!5519132!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24094 invoked from network); 24 Nov 2011 09:51:36 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 09:51:36 -0000
Received: by ghbz2 with SMTP id z2so3389932ghb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 01:51:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VNHm9VXHiciaAbqCPmqbLGdhIzTCslLXvGjZCxlEUdI=;
	b=B8ODNAVTVLkpn4WJrkATnG6m79NZbYGb+sBC5p+driRjv48sNUirN5cRcMC5iJBB4q
	K/FMZuHsbmXNLWbJoMiykK10sEwPPDEgsugVCccH5y8GxMcM4J18ZaqT1JnSSBiXwkR5
	J+051nc1rjSvHU3WENOITrPWOYiuNqdBIvd4E=
Received: by 10.152.136.2 with SMTP id pw2mr17063382lab.22.1322128294105;
	Thu, 24 Nov 2011 01:51:34 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id pi7sm18769406lab.5.2011.11.24.01.51.30
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 01:51:33 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 09:51:27 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CAF3C41F.34BDA%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyqjqIvGnKiwPFDFUeERlqmWp9uSA==
In-Reply-To: <4ECE19400200007800062E4A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 09:15, "Jan Beulich" <JBeulich@suse.com> wrote:

>> 
>> Attached three patches for you to try. They apply in sequence.
>> 00: A fixed version of "domain_crash on stack overflow"
>> 01: Reorders prepare_to_wait so that the vcpu will always be on the
>> waitqueue on exit (even if it has just been woken).
>> 02: Ensures the vcpu wakes up on the same cpu that it slept on.
> 
> Didn't we (long ago) settle on not permitting new calls to
> domain_crash_synchronous()? Is it really impossible to just
> domain_crash() in any of the instances these add?

It's safe because you must be in a context that is safe to preempt. That's a
pre-condition for using a waitqueue. It's not safe to use domain_crash()
because the caller of wait_event() may not handle the exceptional return.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:52:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVyi-0007OO-Fn; Thu, 24 Nov 2011 09:52:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTVyg-0007OA-Sw
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:52:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322128212!53480247!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12717 invoked from network); 24 Nov 2011 09:50:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 09:50:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 09:51:56 +0000
Message-Id: <4ECE21CB0200007800062EA0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 09:51:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
	<4ECE20FF0200007800062E93@nat28.tlf.novell.com>
In-Reply-To: <4ECE20FF0200007800062E93@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 05 of 14] Don't trigger unnecessary shadow
 scans on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 24.11.11 at 10:48, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
>> xen/arch/x86/mm/shadow/common.c |  4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> 
>> When updating a p2m entry, the hypervisor scans all shadow pte's to find
>> mappings of that gfn and tear them down. This is avoided if the page count
>> reveals that there are no additional mappings. The current test ignores the
>> PGC_allocated flag and its effect on the page count.
>> 
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>> 
>> diff -r 93066bdc1e1c -r e8f0709af2b7 xen/arch/x86/mm/shadow/common.c
>> --- a/xen/arch/x86/mm/shadow/common.c
>> +++ b/xen/arch/x86/mm/shadow/common.c
>> @@ -2501,7 +2501,8 @@ int sh_remove_all_mappings(struct vcpu *
>>          ;
>>  
>>      perfc_incr(shadow_mappings);
>> -    if ( (page->count_info & PGC_count_mask) == 0 )
>> +    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
>> +    if ( (page->count_info & PGC_count_mask) == expected_count )
> 
> Is that really valid outside the locked region?
> 
>>          return 0;
>>  
>>      /* Although this is an externally visible function, we do not know
>> @@ -2517,7 +2518,6 @@ int sh_remove_all_mappings(struct vcpu *
>>      hash_foreach(v, callback_mask, callbacks, gmfn);
>>  
>>      /* If that didn't catch the mapping, something is very wrong */
>> -    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
> 
> This certainly isn't right - iiuc the count would normally have changed
> during the hash_foreach() above this.

Hmm, I was wrong here, you aren't caching the page count. Still, is it
certain that the state of PGC_allocated doesn't change from where
you set expected_count now to where it was set before?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:52:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTVyi-0007OO-Fn; Thu, 24 Nov 2011 09:52:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTVyg-0007OA-Sw
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:52:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322128212!53480247!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12717 invoked from network); 24 Nov 2011 09:50:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 09:50:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 09:51:56 +0000
Message-Id: <4ECE21CB0200007800062EA0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 09:51:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
	<4ECE20FF0200007800062E93@nat28.tlf.novell.com>
In-Reply-To: <4ECE20FF0200007800062E93@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 05 of 14] Don't trigger unnecessary shadow
 scans on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 24.11.11 at 10:48, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
>> xen/arch/x86/mm/shadow/common.c |  4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> 
>> When updating a p2m entry, the hypervisor scans all shadow pte's to find
>> mappings of that gfn and tear them down. This is avoided if the page count
>> reveals that there are no additional mappings. The current test ignores the
>> PGC_allocated flag and its effect on the page count.
>> 
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>> 
>> diff -r 93066bdc1e1c -r e8f0709af2b7 xen/arch/x86/mm/shadow/common.c
>> --- a/xen/arch/x86/mm/shadow/common.c
>> +++ b/xen/arch/x86/mm/shadow/common.c
>> @@ -2501,7 +2501,8 @@ int sh_remove_all_mappings(struct vcpu *
>>          ;
>>  
>>      perfc_incr(shadow_mappings);
>> -    if ( (page->count_info & PGC_count_mask) == 0 )
>> +    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
>> +    if ( (page->count_info & PGC_count_mask) == expected_count )
> 
> Is that really valid outside the locked region?
> 
>>          return 0;
>>  
>>      /* Although this is an externally visible function, we do not know
>> @@ -2517,7 +2518,6 @@ int sh_remove_all_mappings(struct vcpu *
>>      hash_foreach(v, callback_mask, callbacks, gmfn);
>>  
>>      /* If that didn't catch the mapping, something is very wrong */
>> -    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
> 
> This certainly isn't right - iiuc the count would normally have changed
> during the hash_foreach() above this.

Hmm, I was wrong here, you aren't caching the page count. Still, is it
certain that the state of PGC_allocated doesn't change from where
you set expected_count now to where it was set before?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:57:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:57:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTW3b-0007kf-CO; Thu, 24 Nov 2011 09:57:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTW3Z-0007kN-QZ
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:57:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322128613!4791621!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15035 invoked from network); 24 Nov 2011 09:56:54 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 09:56:54 -0000
Received: by ggnr4 with SMTP id r4so3516334ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 01:56:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=I6YXs4HHk6KrMzeiYok9G977akcauXE3bbIQ8WniKN0=;
	b=rkpkSJWn53LO7SqhmlDevOiz2ehaD1IoP4HFUSwLQYDE1OdZ+4WegGVNMlXC/nn+a7
	FHSrP2MayjG6Ho2tv+h3d2qGYNDFYqvbooJUnPPgtM4ZORdMrxA/Qv/Q+Jgcr+AJijwv
	6DkFggF/BX6vAMmtsnN5EdjR92fFeeFMCUCB8=
Received: by 10.152.135.166 with SMTP id pt6mr17144382lab.26.1322128612989;
	Thu, 24 Nov 2011 01:56:52 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id hh9sm18795590lab.1.2011.11.24.01.56.49
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 01:56:52 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 09:56:47 +0000
From: Keir Fraser <keir@xen.org>
To: Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <CAF3C55F.34BE1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough, reverse
	OpRegion
Thread-Index: Acyqj2DrxBJSigcrNkCUFBGgrCEU0A==
In-Reply-To: <20111124093551.GC22563@spongy.cam.xci-test.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 09:35, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:

> On 23/11 05:20, Keir Fraser wrote:
>> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
>> 
>>> 
>>> The Intel GPU uses a two pages NVS region called OpRegion.
>>> In order to get full support for the driver in the guest
>>> we need to map this region.
>>> 
>>> This patch reserves 2 pages on the top of the RAM and
>>> mark this region as NVS in the e820. Then we write the
>>> address to the config space (offset 0xfc) so the device
>>> model can map the OpRegion at this address in the guest.
>> 
>> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
>> 
> 
> I'm calling mem_hole_alloc() in pci_setup (see patch attached),
> but that causes an overlap in e820, is that expected?

You'll have to adjust your changes to build_e820_table() to split the range
RESERVED_MEMBASE-0x10000000 into two pieces partitioned by your NVS region.

The region starting at RESERVED_MEMBASE comes *before* your NVS region. Then
you add an another reserved region up to 0x1000000 if your NVS region
exists.

 -- Keir

> (XEN) HVM5: E820 table:
> (XEN) HVM5:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
> (XEN) HVM5:  [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
> (XEN) HVM5:  HOLE: 00000000:000a0000 - 00000000:000e0000
> (XEN) HVM5:  [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
> (XEN) HVM5:  [03]: 00000000:00100000 - 00000000:3f800000: RAM
> (XEN) HVM5:  HOLE: 00000000:3f800000 - 00000000:feff8000
> (XEN) HVM5:  [04]: 00000000:feff8000 - 00000000:feffa000: NVS
> (XEN) HVM5:  OVERLAP!!
> (XEN) HVM5:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
> 
> Jean



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:57:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:57:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTW3b-0007kf-CO; Thu, 24 Nov 2011 09:57:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTW3Z-0007kN-QZ
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:57:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322128613!4791621!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15035 invoked from network); 24 Nov 2011 09:56:54 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 09:56:54 -0000
Received: by ggnr4 with SMTP id r4so3516334ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 01:56:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=I6YXs4HHk6KrMzeiYok9G977akcauXE3bbIQ8WniKN0=;
	b=rkpkSJWn53LO7SqhmlDevOiz2ehaD1IoP4HFUSwLQYDE1OdZ+4WegGVNMlXC/nn+a7
	FHSrP2MayjG6Ho2tv+h3d2qGYNDFYqvbooJUnPPgtM4ZORdMrxA/Qv/Q+Jgcr+AJijwv
	6DkFggF/BX6vAMmtsnN5EdjR92fFeeFMCUCB8=
Received: by 10.152.135.166 with SMTP id pt6mr17144382lab.26.1322128612989;
	Thu, 24 Nov 2011 01:56:52 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id hh9sm18795590lab.1.2011.11.24.01.56.49
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 01:56:52 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 09:56:47 +0000
From: Keir Fraser <keir@xen.org>
To: Jean Guyader <jean.guyader@eu.citrix.com>
Message-ID: <CAF3C55F.34BE1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough, reverse
	OpRegion
Thread-Index: Acyqj2DrxBJSigcrNkCUFBGgrCEU0A==
In-Reply-To: <20111124093551.GC22563@spongy.cam.xci-test.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 09:35, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:

> On 23/11 05:20, Keir Fraser wrote:
>> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
>> 
>>> 
>>> The Intel GPU uses a two pages NVS region called OpRegion.
>>> In order to get full support for the driver in the guest
>>> we need to map this region.
>>> 
>>> This patch reserves 2 pages on the top of the RAM and
>>> mark this region as NVS in the e820. Then we write the
>>> address to the config space (offset 0xfc) so the device
>>> model can map the OpRegion at this address in the guest.
>> 
>> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
>> 
> 
> I'm calling mem_hole_alloc() in pci_setup (see patch attached),
> but that causes an overlap in e820, is that expected?

You'll have to adjust your changes to build_e820_table() to split the range
RESERVED_MEMBASE-0x10000000 into two pieces partitioned by your NVS region.

The region starting at RESERVED_MEMBASE comes *before* your NVS region. Then
you add an another reserved region up to 0x1000000 if your NVS region
exists.

 -- Keir

> (XEN) HVM5: E820 table:
> (XEN) HVM5:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
> (XEN) HVM5:  [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
> (XEN) HVM5:  HOLE: 00000000:000a0000 - 00000000:000e0000
> (XEN) HVM5:  [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
> (XEN) HVM5:  [03]: 00000000:00100000 - 00000000:3f800000: RAM
> (XEN) HVM5:  HOLE: 00000000:3f800000 - 00000000:feff8000
> (XEN) HVM5:  [04]: 00000000:feff8000 - 00000000:feffa000: NVS
> (XEN) HVM5:  OVERLAP!!
> (XEN) HVM5:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
> 
> Jean



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:59:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTW5M-0007rD-VP; Thu, 24 Nov 2011 09:59:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTW5L-0007qv-3n
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:59:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322128710!56287373!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27617 invoked from network); 24 Nov 2011 09:58:31 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 09:58:31 -0000
Received: by ywn1 with SMTP id 1so3490700ywn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 01:58:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=eZklurG9c+BdaimsI6OgGfsAmyRB+sAQmVacRo2tMaE=;
	b=QcUELd/oE2zm2zmouDwO3TC4XWTXS1aQdwkgHJai2ZGIlvBtYTubdd0MWRPpvqtGAF
	HPJnMVyuktIBvqQM85eIsZ9a21euty532gxzCr9Qk4DzBfP0En20t42yvcmStEwfKpjX
	5oiZ0cddvDzw7M5sV9+QXJLGVJMdxRUCg9RW4=
Received: by 10.152.110.99 with SMTP id hz3mr17065344lab.29.1322128724483;
	Thu, 24 Nov 2011 01:58:44 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id ne3sm18781319lab.7.2011.11.24.01.58.42
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 01:58:43 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 09:58:35 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CAF3C5CB.34BE2%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: Acyqj6FL7prPnlwo5kSBkAXLhCAerg==
In-Reply-To: <4ECE19400200007800062E4A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 09:15, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Attached three patches for you to try. They apply in sequence.
>> 00: A fixed version of "domain_crash on stack overflow"
>> 01: Reorders prepare_to_wait so that the vcpu will always be on the
>> waitqueue on exit (even if it has just been woken).
>> 02: Ensures the vcpu wakes up on the same cpu that it slept on.
> 
> Didn't we (long ago) settle on not permitting new calls to
> domain_crash_synchronous()?

This was a reaction to lazy patches which sprinkled d_c_s calls around
liberally, and in unsafe locations, as a dodge around proper error handling.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:59:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:59:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTW5M-0007rD-VP; Thu, 24 Nov 2011 09:59:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTW5L-0007qv-3n
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:59:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322128710!56287373!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27617 invoked from network); 24 Nov 2011 09:58:31 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 09:58:31 -0000
Received: by ywn1 with SMTP id 1so3490700ywn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 01:58:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=eZklurG9c+BdaimsI6OgGfsAmyRB+sAQmVacRo2tMaE=;
	b=QcUELd/oE2zm2zmouDwO3TC4XWTXS1aQdwkgHJai2ZGIlvBtYTubdd0MWRPpvqtGAF
	HPJnMVyuktIBvqQM85eIsZ9a21euty532gxzCr9Qk4DzBfP0En20t42yvcmStEwfKpjX
	5oiZ0cddvDzw7M5sV9+QXJLGVJMdxRUCg9RW4=
Received: by 10.152.110.99 with SMTP id hz3mr17065344lab.29.1322128724483;
	Thu, 24 Nov 2011 01:58:44 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id ne3sm18781319lab.7.2011.11.24.01.58.42
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 01:58:43 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 09:58:35 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CAF3C5CB.34BE2%keir@xen.org>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: Acyqj6FL7prPnlwo5kSBkAXLhCAerg==
In-Reply-To: <4ECE19400200007800062E4A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 09:15, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Attached three patches for you to try. They apply in sequence.
>> 00: A fixed version of "domain_crash on stack overflow"
>> 01: Reorders prepare_to_wait so that the vcpu will always be on the
>> waitqueue on exit (even if it has just been woken).
>> 02: Ensures the vcpu wakes up on the same cpu that it slept on.
> 
> Didn't we (long ago) settle on not permitting new calls to
> domain_crash_synchronous()?

This was a reaction to lazy patches which sprinkled d_c_s calls around
liberally, and in unsafe locations, as a dodge around proper error handling.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:59:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTW5l-0007tH-Db; Thu, 24 Nov 2011 09:59:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTW5k-0007sb-No
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:59:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322128749!4798756!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6372 invoked from network); 24 Nov 2011 09:59:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 09:59:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 09:59:09 +0000
Message-Id: <4ECE237B0200007800062EB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 09:59:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	"Keir Fraser" <keir@xen.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<25d27decfdccbb221b2f.1322082674@xdev.gridcentric.ca>
In-Reply-To: <25d27decfdccbb221b2f.1322082674@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 07 of 14] Trivial fix for rc val in hap
 track dirty vram
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> xen/arch/x86/mm/hap/hap.c |  2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r e22610ef339a -r 25d27decfdcc xen/arch/x86/mm/hap/hap.c
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -141,7 +141,7 @@ int hap_track_dirty_vram(struct domain *
>          }
>          else if ( !paging_mode_log_dirty(d) && !dirty_vram )
>          {
> -            rc -ENOMEM;
> +            rc = -ENOMEM;
>              if ( (dirty_vram = xmalloc(struct sh_dirty_vram)) == NULL )
>                  goto param_fail;
>  

This would have been caught by the compiler if we weren't forcing
-Wno-unused-value. Keir, shouldn't we revisit this 5 year old decision
(c/s 11762:db3d58d30e9d)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 09:59:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 09:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTW5l-0007tH-Db; Thu, 24 Nov 2011 09:59:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTW5k-0007sb-No
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 09:59:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322128749!4798756!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6372 invoked from network); 24 Nov 2011 09:59:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 09:59:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 09:59:09 +0000
Message-Id: <4ECE237B0200007800062EB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 09:59:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	"Keir Fraser" <keir@xen.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<25d27decfdccbb221b2f.1322082674@xdev.gridcentric.ca>
In-Reply-To: <25d27decfdccbb221b2f.1322082674@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 07 of 14] Trivial fix for rc val in hap
 track dirty vram
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> xen/arch/x86/mm/hap/hap.c |  2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r e22610ef339a -r 25d27decfdcc xen/arch/x86/mm/hap/hap.c
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -141,7 +141,7 @@ int hap_track_dirty_vram(struct domain *
>          }
>          else if ( !paging_mode_log_dirty(d) && !dirty_vram )
>          {
> -            rc -ENOMEM;
> +            rc = -ENOMEM;
>              if ( (dirty_vram = xmalloc(struct sh_dirty_vram)) == NULL )
>                  goto param_fail;
>  

This would have been caught by the compiler if we weren't forcing
-Wno-unused-value. Keir, shouldn't we revisit this 5 year old decision
(c/s 11762:db3d58d30e9d)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 10:01:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 10:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTW79-00086c-UU; Thu, 24 Nov 2011 10:01:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTW78-000861-4e
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 10:01:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322128834!4435595!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13260 invoked from network); 24 Nov 2011 10:00:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2011 10:00:35 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322128834; l=284;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ye6M5O+h+zCb4bd9ymggIr/5ZWE=;
	b=mRTDJmpkzzBfr4ajiKITTVOAMlVW/dQ0z5/7DpCrD7hS7vmgplmP0j/lmqdb182JhdC
	oBGmZS5qZQX1hGGMH4DRCNixqlAkD2AjNwehSjSmq93ZDRQuQw2ae0rzld/cMPReDITl6
	7v3KlC6wATxgqs9dfdREgFExgZ8FQQQdy6g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (jimi mo59) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g05844nAO8P3LX ;
	Thu, 24 Nov 2011 11:00:21 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 539F118637; Thu, 24 Nov 2011 11:00:21 +0100 (CET)
Date: Thu, 24 Nov 2011 11:00:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111124100021.GA17462@aepfle.de>
References: <20111123223049.GA14423@aepfle.de>
	<CAF32E64.25744%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF32E64.25744%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Keir Fraser wrote:

> ...from qemu-dm. Problem is that toolstack is not killing qemu-dm, or
> qemu-dm is not responding to some shutdown signal.

In the first crash there was no qemu-dm process left from what I
remember. I will see if it happens again.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 10:01:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 10:01:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTW79-00086c-UU; Thu, 24 Nov 2011 10:01:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTW78-000861-4e
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 10:01:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322128834!4435595!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13260 invoked from network); 24 Nov 2011 10:00:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2011 10:00:35 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322128834; l=284;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ye6M5O+h+zCb4bd9ymggIr/5ZWE=;
	b=mRTDJmpkzzBfr4ajiKITTVOAMlVW/dQ0z5/7DpCrD7hS7vmgplmP0j/lmqdb182JhdC
	oBGmZS5qZQX1hGGMH4DRCNixqlAkD2AjNwehSjSmq93ZDRQuQw2ae0rzld/cMPReDITl6
	7v3KlC6wATxgqs9dfdREgFExgZ8FQQQdy6g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (jimi mo59) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g05844nAO8P3LX ;
	Thu, 24 Nov 2011 11:00:21 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 539F118637; Thu, 24 Nov 2011 11:00:21 +0100 (CET)
Date: Thu, 24 Nov 2011 11:00:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111124100021.GA17462@aepfle.de>
References: <20111123223049.GA14423@aepfle.de>
	<CAF32E64.25744%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF32E64.25744%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 23, Keir Fraser wrote:

> ...from qemu-dm. Problem is that toolstack is not killing qemu-dm, or
> qemu-dm is not responding to some shutdown signal.

In the first crash there was no qemu-dm process left from what I
remember. I will see if it happens again.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 10:04:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 10:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTWA2-0008Nw-IS; Thu, 24 Nov 2011 10:04:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTWA0-0008NZ-Qz
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 10:04:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322129013!4425401!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28986 invoked from network); 24 Nov 2011 10:03:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 10:03:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 10:03:33 +0000
Message-Id: <4ECE24840200007800062EC8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 10:03:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	"Keir Fraser" <keir@xen.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<7e8211d0f41d42257d27.1322082675@xdev.gridcentric.ca>
In-Reply-To: <7e8211d0f41d42257d27.1322082675@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 08 of 14] Properly compare "pci" token when
 groking serial port config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> xen/drivers/char/ns16550.c |  2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

This regression fix (from c/s 23679:cf7e1746bdb7) should probably
go in right away.

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r 25d27decfdcc -r 7e8211d0f41d xen/drivers/char/ns16550.c
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -554,7 +554,7 @@ static void __init ns16550_parse_port_co
>      if ( *conf == ',' )
>      {
>          conf++;
> -        if ( strncmp(conf, "pci", 5) == 0 )
> +        if ( strncmp(conf, "pci", 3) == 0 )
>          {
>              if ( pci_uart_config(uart, 1/* skip AMT */, uart - ns16550_com) 
> )
>                  return;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 10:04:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 10:04:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTWA2-0008Nw-IS; Thu, 24 Nov 2011 10:04:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTWA0-0008NZ-Qz
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 10:04:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322129013!4425401!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28986 invoked from network); 24 Nov 2011 10:03:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 10:03:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 10:03:33 +0000
Message-Id: <4ECE24840200007800062EC8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 10:03:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	"Keir Fraser" <keir@xen.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<7e8211d0f41d42257d27.1322082675@xdev.gridcentric.ca>
In-Reply-To: <7e8211d0f41d42257d27.1322082675@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 08 of 14] Properly compare "pci" token when
 groking serial port config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> xen/drivers/char/ns16550.c |  2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

This regression fix (from c/s 23679:cf7e1746bdb7) should probably
go in right away.

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r 25d27decfdcc -r 7e8211d0f41d xen/drivers/char/ns16550.c
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -554,7 +554,7 @@ static void __init ns16550_parse_port_co
>      if ( *conf == ',' )
>      {
>          conf++;
> -        if ( strncmp(conf, "pci", 5) == 0 )
> +        if ( strncmp(conf, "pci", 3) == 0 )
>          {
>              if ( pci_uart_config(uart, 1/* skip AMT */, uart - ns16550_com) 
> )
>                  return;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 10:29:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 10:29:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTWYW-0000NV-Sc; Thu, 24 Nov 2011 10:29:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ciccinocj@gmail.com>) id 1RTWYV-0000NO-VF
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 10:29:24 +0000
X-Env-Sender: ciccinocj@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322130531!2850964!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10592 invoked from network); 24 Nov 2011 10:28:52 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 10:28:52 -0000
Received: by ywn1 with SMTP id 1so3528000ywn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 02:28:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=1bK3qCrHvA0Pbb9XRvfNlunKwHE3bIVjBso79njEBUQ=;
	b=fNM/tDYw9YglCsYK3VUG7EsO1QZJDM4IhcGZuJIoRUWZqFUkbIdBUEx+gF4zXjQ1I7
	nsZjU5djutTSe/jr1d5jzHI5WrI7fkO7FGbM3qaaq3M+oBfiCkuNUR1YSRldfzeXIDrO
	ISkUe/ZLnBavY21kXKOeBSRXgYYX6BQzvtKZM=
MIME-Version: 1.0
Received: by 10.146.92.19 with SMTP id p19mr5581409yab.7.1322130531006; Thu,
	24 Nov 2011 02:28:51 -0800 (PST)
Received: by 10.236.116.166 with HTTP; Thu, 24 Nov 2011 02:28:50 -0800 (PST)
In-Reply-To: <CAK+nMnn_g57Oh1L8sFtAwt7a42YfuqxeuVBdvfpqfJ-AdyPORw@mail.gmail.com>
References: <CAK+nMnn_g57Oh1L8sFtAwt7a42YfuqxeuVBdvfpqfJ-AdyPORw@mail.gmail.com>
Date: Thu, 24 Nov 2011 18:28:50 +0800
Message-ID: <CAK+nMnmBPCiR9HJj_+K+=XSnehibqeJZH3UVJ=j5NLMaUHmsnw@mail.gmail.com>
From: =?GB2312?B?s8K9+A==?= <ciccinocj@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Question about hvm disk io behavior
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1094512596400364180=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1094512596400364180==
Content-Type: multipart/alternative; boundary=000e0cd30338a5b83504b27880d2

--000e0cd30338a5b83504b27880d2
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi, I am currently doing some study about hvm IO behavior.
I encounter a strange thing that hvm tries to access a page owned to dom0
when it executes disk io instructions like "rep ins/outs".

Here is my console output message:
         (XEN) [M]emulate.c:384 =3D=3D=3DWarning!! dst_ma=3D0x1ed0fa400,
domain_id=3D0 rip=3D0xffffffff812a38fb size=3D0x200.
         (XEN) insns: f3 66 6d 5b. pite=3D0x80000000

domain id =3D 0 means it's a page of dom0 but rip is in the address space o=
f
domU, its instructions are f3 66 6d 5b.

I am confusing why hvm need to put its disk data into dom0 memory space, is
it a shared page? what do they share with this page?
Thanks for any reply.

--=20
=B3=C2=BD=F8
=B5=E7=BB=B0=A3=BA+86-21-51355360
=B8=B4=B5=A9=B4=F3=D1=A7=B2=A2=D0=D0=B4=A6=C0=ED=D1=D0=BE=BF=CB=F9
=C9=CF=BA=A3=C6=D6=B6=AB=D0=C2=C7=F8=D5=C5=BA=E2=C2=B7825=BA=C5=A3=AC=C8=ED=
=BC=FE=C2=A5320

Jin Chen
Phone: +86-21-51355360
Room 320, Software Building
No. 825, Zhangheng Road
Pudong District, Shanghai




--=20
=B3=C2=BD=F8
=B5=E7=BB=B0=A3=BA+86-21-51355360
=B8=B4=B5=A9=B4=F3=D1=A7=B2=A2=D0=D0=B4=A6=C0=ED=D1=D0=BE=BF=CB=F9
=C9=CF=BA=A3=C6=D6=B6=AB=D0=C2=C7=F8=D5=C5=BA=E2=C2=B7825=BA=C5=A3=AC=C8=ED=
=BC=FE=C2=A5320

Jin Chen
Phone: +86-21-51355360
Room 320, Software Building
No. 825, Zhangheng Road
Pudong District, Shanghai

--000e0cd30338a5b83504b27880d2
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi, I am currently doing some study about hvm IO behavior.<br><div class=3D=
"gmail_quote"><div>I encounter a strange thing that hvm tries to access a p=
age owned to dom0 when it executes disk io instructions like &quot;rep ins/=
outs&quot;.</div>
<div><br></div>
<div>Here is my console output message:</div><div><div>&nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp;(XEN) [M]emulate.c:384 =3D=3D=3DWarning!! dst_ma=3D0x1ed0fa40=
0, domain_id=3D0 rip=3D0xffffffff812a38fb size=3D0x200.</div><div>&nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp;(XEN) <span style=3D"white-space:pre-wrap">		</spa=
n>insns: f3 66 6d 5b. pite=3D0x80000000</div>

<div><br></div><div>domain id =3D 0 means it&#39;s a page of dom0 but rip i=
s in the address space of domU, its instructions are f3 66 6d 5b.</div><div=
><br></div><div>I am confusing why hvm need to put its disk data into dom0 =
memory space, is it a shared page? what do they share with this page?</div>

<div>Thanks for any&nbsp;reply.&nbsp;</div><span class=3D"HOEnZb"><font col=
or=3D"#888888"><div><br></div>-- <br>=B3=C2=BD=F8<div>=B5=E7=BB=B0=A3=BA<sp=
an style=3D"font-family:sans-serif;font-size:13px;line-height:19px;backgrou=
nd-color:rgb(255,255,255)"><a href=3D"tel:%2B86-21-51355360" value=3D"+8621=
51355360" target=3D"_blank">+86-21-51355360</a></span></div>
<div>=B8=B4=B5=A9=B4=F3=D1=A7=B2=A2=D0=D0=B4=A6=C0=ED=D1=D0=BE=BF=CB=F9</di=
v><div>
=C9=CF=BA=A3=C6=D6=B6=AB=D0=C2=C7=F8=D5=C5=BA=E2=C2=B7825=BA=C5=A3=AC=C8=ED=
=BC=FE=C2=A5320</div><div><br></div><div>Jin Chen</div><div>Phone:&nbsp;<sp=
an style=3D"font-family:sans-serif;font-size:13px;line-height:19px;backgrou=
nd-color:rgb(255,255,255)"><a href=3D"tel:%2B86-21-51355360" value=3D"+8621=
51355360" target=3D"_blank">+86-21-51355360</a></span></div>
<div><div>Room 320, Software Building</div>
<div>No. 825, Zhangheng Road</div><div>Pudong District, Shanghai</div></div=
><br>
</font></span></div>
</div><br><br clear=3D"all"><div><br></div>-- <br>=B3=C2=BD=F8<div>=B5=E7=
=BB=B0=A3=BA<span style=3D"font-family:sans-serif;font-size:13px;line-heigh=
t:19px;background-color:rgb(255, 255, 255)">+86-21-51355360</span></div><di=
v>=B8=B4=B5=A9=B4=F3=D1=A7=B2=A2=D0=D0=B4=A6=C0=ED=D1=D0=BE=BF=CB=F9</div><=
div>=C9=CF=BA=A3=C6=D6=B6=AB=D0=C2=C7=F8=D5=C5=BA=E2=C2=B7825=BA=C5=A3=AC=
=C8=ED=BC=FE=C2=A5320</div>
<div><br></div><div>Jin Chen</div><div>Phone:&nbsp;<span style=3D"font-fami=
ly:sans-serif;font-size:13px;line-height:19px;background-color:rgb(255, 255=
, 255)">+86-21-51355360</span></div><div><div>Room 320, Software Building</=
div>
<div>No. 825, Zhangheng Road</div><div>Pudong District, Shanghai</div></div=
><br>

--000e0cd30338a5b83504b27880d2--


--===============1094512596400364180==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1094512596400364180==--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 10:29:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 10:29:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTWYW-0000NV-Sc; Thu, 24 Nov 2011 10:29:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ciccinocj@gmail.com>) id 1RTWYV-0000NO-VF
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 10:29:24 +0000
X-Env-Sender: ciccinocj@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322130531!2850964!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10592 invoked from network); 24 Nov 2011 10:28:52 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 10:28:52 -0000
Received: by ywn1 with SMTP id 1so3528000ywn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 02:28:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=1bK3qCrHvA0Pbb9XRvfNlunKwHE3bIVjBso79njEBUQ=;
	b=fNM/tDYw9YglCsYK3VUG7EsO1QZJDM4IhcGZuJIoRUWZqFUkbIdBUEx+gF4zXjQ1I7
	nsZjU5djutTSe/jr1d5jzHI5WrI7fkO7FGbM3qaaq3M+oBfiCkuNUR1YSRldfzeXIDrO
	ISkUe/ZLnBavY21kXKOeBSRXgYYX6BQzvtKZM=
MIME-Version: 1.0
Received: by 10.146.92.19 with SMTP id p19mr5581409yab.7.1322130531006; Thu,
	24 Nov 2011 02:28:51 -0800 (PST)
Received: by 10.236.116.166 with HTTP; Thu, 24 Nov 2011 02:28:50 -0800 (PST)
In-Reply-To: <CAK+nMnn_g57Oh1L8sFtAwt7a42YfuqxeuVBdvfpqfJ-AdyPORw@mail.gmail.com>
References: <CAK+nMnn_g57Oh1L8sFtAwt7a42YfuqxeuVBdvfpqfJ-AdyPORw@mail.gmail.com>
Date: Thu, 24 Nov 2011 18:28:50 +0800
Message-ID: <CAK+nMnmBPCiR9HJj_+K+=XSnehibqeJZH3UVJ=j5NLMaUHmsnw@mail.gmail.com>
From: =?GB2312?B?s8K9+A==?= <ciccinocj@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Question about hvm disk io behavior
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1094512596400364180=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1094512596400364180==
Content-Type: multipart/alternative; boundary=000e0cd30338a5b83504b27880d2

--000e0cd30338a5b83504b27880d2
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi, I am currently doing some study about hvm IO behavior.
I encounter a strange thing that hvm tries to access a page owned to dom0
when it executes disk io instructions like "rep ins/outs".

Here is my console output message:
         (XEN) [M]emulate.c:384 =3D=3D=3DWarning!! dst_ma=3D0x1ed0fa400,
domain_id=3D0 rip=3D0xffffffff812a38fb size=3D0x200.
         (XEN) insns: f3 66 6d 5b. pite=3D0x80000000

domain id =3D 0 means it's a page of dom0 but rip is in the address space o=
f
domU, its instructions are f3 66 6d 5b.

I am confusing why hvm need to put its disk data into dom0 memory space, is
it a shared page? what do they share with this page?
Thanks for any reply.

--=20
=B3=C2=BD=F8
=B5=E7=BB=B0=A3=BA+86-21-51355360
=B8=B4=B5=A9=B4=F3=D1=A7=B2=A2=D0=D0=B4=A6=C0=ED=D1=D0=BE=BF=CB=F9
=C9=CF=BA=A3=C6=D6=B6=AB=D0=C2=C7=F8=D5=C5=BA=E2=C2=B7825=BA=C5=A3=AC=C8=ED=
=BC=FE=C2=A5320

Jin Chen
Phone: +86-21-51355360
Room 320, Software Building
No. 825, Zhangheng Road
Pudong District, Shanghai




--=20
=B3=C2=BD=F8
=B5=E7=BB=B0=A3=BA+86-21-51355360
=B8=B4=B5=A9=B4=F3=D1=A7=B2=A2=D0=D0=B4=A6=C0=ED=D1=D0=BE=BF=CB=F9
=C9=CF=BA=A3=C6=D6=B6=AB=D0=C2=C7=F8=D5=C5=BA=E2=C2=B7825=BA=C5=A3=AC=C8=ED=
=BC=FE=C2=A5320

Jin Chen
Phone: +86-21-51355360
Room 320, Software Building
No. 825, Zhangheng Road
Pudong District, Shanghai

--000e0cd30338a5b83504b27880d2
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi, I am currently doing some study about hvm IO behavior.<br><div class=3D=
"gmail_quote"><div>I encounter a strange thing that hvm tries to access a p=
age owned to dom0 when it executes disk io instructions like &quot;rep ins/=
outs&quot;.</div>
<div><br></div>
<div>Here is my console output message:</div><div><div>&nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp;(XEN) [M]emulate.c:384 =3D=3D=3DWarning!! dst_ma=3D0x1ed0fa40=
0, domain_id=3D0 rip=3D0xffffffff812a38fb size=3D0x200.</div><div>&nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp;(XEN) <span style=3D"white-space:pre-wrap">		</spa=
n>insns: f3 66 6d 5b. pite=3D0x80000000</div>

<div><br></div><div>domain id =3D 0 means it&#39;s a page of dom0 but rip i=
s in the address space of domU, its instructions are f3 66 6d 5b.</div><div=
><br></div><div>I am confusing why hvm need to put its disk data into dom0 =
memory space, is it a shared page? what do they share with this page?</div>

<div>Thanks for any&nbsp;reply.&nbsp;</div><span class=3D"HOEnZb"><font col=
or=3D"#888888"><div><br></div>-- <br>=B3=C2=BD=F8<div>=B5=E7=BB=B0=A3=BA<sp=
an style=3D"font-family:sans-serif;font-size:13px;line-height:19px;backgrou=
nd-color:rgb(255,255,255)"><a href=3D"tel:%2B86-21-51355360" value=3D"+8621=
51355360" target=3D"_blank">+86-21-51355360</a></span></div>
<div>=B8=B4=B5=A9=B4=F3=D1=A7=B2=A2=D0=D0=B4=A6=C0=ED=D1=D0=BE=BF=CB=F9</di=
v><div>
=C9=CF=BA=A3=C6=D6=B6=AB=D0=C2=C7=F8=D5=C5=BA=E2=C2=B7825=BA=C5=A3=AC=C8=ED=
=BC=FE=C2=A5320</div><div><br></div><div>Jin Chen</div><div>Phone:&nbsp;<sp=
an style=3D"font-family:sans-serif;font-size:13px;line-height:19px;backgrou=
nd-color:rgb(255,255,255)"><a href=3D"tel:%2B86-21-51355360" value=3D"+8621=
51355360" target=3D"_blank">+86-21-51355360</a></span></div>
<div><div>Room 320, Software Building</div>
<div>No. 825, Zhangheng Road</div><div>Pudong District, Shanghai</div></div=
><br>
</font></span></div>
</div><br><br clear=3D"all"><div><br></div>-- <br>=B3=C2=BD=F8<div>=B5=E7=
=BB=B0=A3=BA<span style=3D"font-family:sans-serif;font-size:13px;line-heigh=
t:19px;background-color:rgb(255, 255, 255)">+86-21-51355360</span></div><di=
v>=B8=B4=B5=A9=B4=F3=D1=A7=B2=A2=D0=D0=B4=A6=C0=ED=D1=D0=BE=BF=CB=F9</div><=
div>=C9=CF=BA=A3=C6=D6=B6=AB=D0=C2=C7=F8=D5=C5=BA=E2=C2=B7825=BA=C5=A3=AC=
=C8=ED=BC=FE=C2=A5320</div>
<div><br></div><div>Jin Chen</div><div>Phone:&nbsp;<span style=3D"font-fami=
ly:sans-serif;font-size:13px;line-height:19px;background-color:rgb(255, 255=
, 255)">+86-21-51355360</span></div><div><div>Room 320, Software Building</=
div>
<div>No. 825, Zhangheng Road</div><div>Pudong District, Shanghai</div></div=
><br>

--000e0cd30338a5b83504b27880d2--


--===============1094512596400364180==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1094512596400364180==--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 10:32:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 10:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTWak-0000Uz-Ef; Thu, 24 Nov 2011 10:31:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>) id 1RTWaj-0000Un-10
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 10:31:41 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322130648!45872854!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26018 invoked from network); 24 Nov 2011 10:30:49 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 10:30:49 -0000
Received: by iaby12 with SMTP id y12so3406195iab.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 02:31:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=NIT8TN73NaUoqEAHaE4BHSQ8jZ1CCUY605+Koi1WBA0=;
	b=vy7cXDQBSPdIHCsAhfJfP+Vab1cY9OgO0oDh/h/jj2wKBnkODTn2/MPVv3GBbNDnbQ
	FxsWyVlg5iTELIrfV9yxWiOK1ConUxLbUz3OclUoYCavEVUu226b194PNUITAnXhC3d7
	jGO7GglKQcXTNqgLoPj8ywSDj/0MKjz70LlLo=
MIME-Version: 1.0
Received: by 10.42.156.130 with SMTP id z2mr7116821icw.13.1322130673663; Thu,
	24 Nov 2011 02:31:13 -0800 (PST)
Received: by 10.231.62.1 with HTTP; Thu, 24 Nov 2011 02:31:13 -0800 (PST)
In-Reply-To: <1322123905.9567.32.camel@dagon.hellion.org.uk>
References: <CAFivhPnQVSAPq7cUv4H-aZn_P79f0_CyrJGaRnP4BFAeGBKQJg@mail.gmail.com>
	<1322123905.9567.32.camel@dagon.hellion.org.uk>
Date: Thu, 24 Nov 2011 11:31:13 +0100
Message-ID: <CAFivhPnQmRe94ZLsy5NG9X1hzU_L4y-3-PbSJJzOnuZ6XsTGUw@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Can domU config add userdefined keys to Xenstore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/24 Ian Campbell <Ian.Campbell@citrix.com>:
> On Wed, 2011-11-23 at 20:11 +0000, Florian Heigl wrote:
>> I would like to create the entry right at domU launch, and I'd like to
>> make use of Xens knowledge of the domU ID it'll use, because the changing
>> domU ID is a grief.
>
> FWIW you can use "xl domid <name>" in your scripts.

Ok, nice to know, cleaner than xl list | awk ...

> You could just start the VM paused, use "xl domid" to setup your keys
> and then unpause?

This will all need wrapping around domU creation, so it would mean
that it's not
possible to use the normal /etc/init.d/xendomains
For me, no problem I had to replace that anyway, but in general maybe not so
"transparent".

> If you are using xapi then VM.xenstore_data is a list of key-value pairs
> which is written xenstore. AFAICT The key is relative to
> to /local/domain/<id> and must start "vm-data/..." (i.e. you can only
> write to keys under /local/domain/<id>/vm-data/ using this mechanism).
>
> I suspect you aren't using xapi but the reason I mention it is that
> someone added libxl_domain_create_info.xsdata in the early days of
> libxl, presumably with this purpose in mind, but it appears not to be
> hooked up into the xl configuration parser. I expect doing so would be a
> reasonably simply job.

I'm not using Xapi, yup. But that seems a nice feature.

> Another, possibly more flexible but more complex option, would be to
> allow for a series of hook scripts (both global and domain specific?) to
> be called at various points in a VM lifecylce, including after building
> but before starting.

There are already kind of hooks in the "on_reboot" "on_destroy" things.
but thats quite in hazy future I guess. And it might be overkill.

It would be enough if the things you can add into a VM are configured in
the same way, in the same place and run at start / stop!
Ok. Technically the xenstore /vm/domain/XX is not IN the VM. :)

I'll poke around some more, either something using the udev xen backend
or the easy and safe route with a small shellscripty-daemon.

Many people have looked for some way to find out the xen host's name
from within a domU, it's pity this stuff isn't more obvious since it's quite
nice to use (just consider stateless linux boxes)

Oh and THANKS to whomever wrote the Xenstore articles during last doc day.
I was amazed when I found them.

Greetings,
Florian

-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 10:32:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 10:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTWak-0000Uz-Ef; Thu, 24 Nov 2011 10:31:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>) id 1RTWaj-0000Un-10
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 10:31:41 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322130648!45872854!1
X-Originating-IP: [209.85.210.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26018 invoked from network); 24 Nov 2011 10:30:49 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 10:30:49 -0000
Received: by iaby12 with SMTP id y12so3406195iab.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 02:31:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=NIT8TN73NaUoqEAHaE4BHSQ8jZ1CCUY605+Koi1WBA0=;
	b=vy7cXDQBSPdIHCsAhfJfP+Vab1cY9OgO0oDh/h/jj2wKBnkODTn2/MPVv3GBbNDnbQ
	FxsWyVlg5iTELIrfV9yxWiOK1ConUxLbUz3OclUoYCavEVUu226b194PNUITAnXhC3d7
	jGO7GglKQcXTNqgLoPj8ywSDj/0MKjz70LlLo=
MIME-Version: 1.0
Received: by 10.42.156.130 with SMTP id z2mr7116821icw.13.1322130673663; Thu,
	24 Nov 2011 02:31:13 -0800 (PST)
Received: by 10.231.62.1 with HTTP; Thu, 24 Nov 2011 02:31:13 -0800 (PST)
In-Reply-To: <1322123905.9567.32.camel@dagon.hellion.org.uk>
References: <CAFivhPnQVSAPq7cUv4H-aZn_P79f0_CyrJGaRnP4BFAeGBKQJg@mail.gmail.com>
	<1322123905.9567.32.camel@dagon.hellion.org.uk>
Date: Thu, 24 Nov 2011 11:31:13 +0100
Message-ID: <CAFivhPnQmRe94ZLsy5NG9X1hzU_L4y-3-PbSJJzOnuZ6XsTGUw@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Can domU config add userdefined keys to Xenstore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/24 Ian Campbell <Ian.Campbell@citrix.com>:
> On Wed, 2011-11-23 at 20:11 +0000, Florian Heigl wrote:
>> I would like to create the entry right at domU launch, and I'd like to
>> make use of Xens knowledge of the domU ID it'll use, because the changing
>> domU ID is a grief.
>
> FWIW you can use "xl domid <name>" in your scripts.

Ok, nice to know, cleaner than xl list | awk ...

> You could just start the VM paused, use "xl domid" to setup your keys
> and then unpause?

This will all need wrapping around domU creation, so it would mean
that it's not
possible to use the normal /etc/init.d/xendomains
For me, no problem I had to replace that anyway, but in general maybe not so
"transparent".

> If you are using xapi then VM.xenstore_data is a list of key-value pairs
> which is written xenstore. AFAICT The key is relative to
> to /local/domain/<id> and must start "vm-data/..." (i.e. you can only
> write to keys under /local/domain/<id>/vm-data/ using this mechanism).
>
> I suspect you aren't using xapi but the reason I mention it is that
> someone added libxl_domain_create_info.xsdata in the early days of
> libxl, presumably with this purpose in mind, but it appears not to be
> hooked up into the xl configuration parser. I expect doing so would be a
> reasonably simply job.

I'm not using Xapi, yup. But that seems a nice feature.

> Another, possibly more flexible but more complex option, would be to
> allow for a series of hook scripts (both global and domain specific?) to
> be called at various points in a VM lifecylce, including after building
> but before starting.

There are already kind of hooks in the "on_reboot" "on_destroy" things.
but thats quite in hazy future I guess. And it might be overkill.

It would be enough if the things you can add into a VM are configured in
the same way, in the same place and run at start / stop!
Ok. Technically the xenstore /vm/domain/XX is not IN the VM. :)

I'll poke around some more, either something using the udev xen backend
or the easy and safe route with a small shellscripty-daemon.

Many people have looked for some way to find out the xen host's name
from within a domU, it's pity this stuff isn't more obvious since it's quite
nice to use (just consider stateless linux boxes)

Oh and THANKS to whomever wrote the Xenstore articles during last doc day.
I was amazed when I found them.

Greetings,
Florian

-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 10:38:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 10:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTWge-0000lO-HA; Thu, 24 Nov 2011 10:37:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTWgd-0000lB-Iu
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 10:37:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322131036!3884513!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13525 invoked from network); 24 Nov 2011 10:37:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 10:37:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9108440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 10:37:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 10:37:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Florian Heigl <florian.heigl@gmail.com>
Date: Thu, 24 Nov 2011 10:37:16 +0000
In-Reply-To: <CAFivhPnQmRe94ZLsy5NG9X1hzU_L4y-3-PbSJJzOnuZ6XsTGUw@mail.gmail.com>
References: <CAFivhPnQVSAPq7cUv4H-aZn_P79f0_CyrJGaRnP4BFAeGBKQJg@mail.gmail.com>
	<1322123905.9567.32.camel@dagon.hellion.org.uk>
	<CAFivhPnQmRe94ZLsy5NG9X1hzU_L4y-3-PbSJJzOnuZ6XsTGUw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322131036.1005.157.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Can domU config add userdefined keys to Xenstore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 10:31 +0000, Florian Heigl wrote:
> 2011/11/24 Ian Campbell <Ian.Campbell@citrix.com>:
> > You could just start the VM paused, use "xl domid" to setup your keys
> > and then unpause?
> 
> This will all need wrapping around domU creation, so it would mean
> that it's not
> possible to use the normal /etc/init.d/xendomains
> For me, no problem I had to replace that anyway, but in general maybe not so
> "transparent".

Right.
> 
> > If you are using xapi then VM.xenstore_data is a list of key-value pairs
> > which is written xenstore. AFAICT The key is relative to
> > to /local/domain/<id> and must start "vm-data/..." (i.e. you can only
> > write to keys under /local/domain/<id>/vm-data/ using this mechanism).
> >
> > I suspect you aren't using xapi but the reason I mention it is that
> > someone added libxl_domain_create_info.xsdata in the early days of
> > libxl, presumably with this purpose in mind, but it appears not to be
> > hooked up into the xl configuration parser. I expect doing so would be a
> > reasonably simply job.
> 
> I'm not using Xapi, yup. But that seems a nice feature.
> 
> > Another, possibly more flexible but more complex option, would be to
> > allow for a series of hook scripts (both global and domain specific?) to
> > be called at various points in a VM lifecylce, including after building
> > but before starting.
> 
> There are already kind of hooks in the "on_reboot" "on_destroy" things.
> but thats quite in hazy future I guess. And it might be overkill.

Those options configure the behaviour of xl itself rather than calling
out to some hook script.

> It would be enough if the things you can add into a VM are configured in
> the same way, in the same place and run at start / stop!

That's what I was suggesting by exposing libxl_domain_create_info.xsdata
through xl.

> Ok. Technically the xenstore /vm/domain/XX is not IN the VM. :)
> 
> I'll poke around some more, either something using the udev xen backend
> or the easy and safe route with a small shellscripty-daemon.
> 
> Many people have looked for some way to find out the xen host's name
> from within a domU, it's pity this stuff isn't more obvious since it's quite
> nice to use (just consider stateless linux boxes)
> 
> Oh and THANKS to whomever wrote the Xenstore articles during last doc day.
> I was amazed when I found them.
> 
> Greetings,
> Florian
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 10:38:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 10:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTWge-0000lO-HA; Thu, 24 Nov 2011 10:37:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTWgd-0000lB-Iu
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 10:37:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322131036!3884513!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13525 invoked from network); 24 Nov 2011 10:37:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 10:37:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9108440"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 10:37:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 10:37:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Florian Heigl <florian.heigl@gmail.com>
Date: Thu, 24 Nov 2011 10:37:16 +0000
In-Reply-To: <CAFivhPnQmRe94ZLsy5NG9X1hzU_L4y-3-PbSJJzOnuZ6XsTGUw@mail.gmail.com>
References: <CAFivhPnQVSAPq7cUv4H-aZn_P79f0_CyrJGaRnP4BFAeGBKQJg@mail.gmail.com>
	<1322123905.9567.32.camel@dagon.hellion.org.uk>
	<CAFivhPnQmRe94ZLsy5NG9X1hzU_L4y-3-PbSJJzOnuZ6XsTGUw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322131036.1005.157.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Can domU config add userdefined keys to Xenstore?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 10:31 +0000, Florian Heigl wrote:
> 2011/11/24 Ian Campbell <Ian.Campbell@citrix.com>:
> > You could just start the VM paused, use "xl domid" to setup your keys
> > and then unpause?
> 
> This will all need wrapping around domU creation, so it would mean
> that it's not
> possible to use the normal /etc/init.d/xendomains
> For me, no problem I had to replace that anyway, but in general maybe not so
> "transparent".

Right.
> 
> > If you are using xapi then VM.xenstore_data is a list of key-value pairs
> > which is written xenstore. AFAICT The key is relative to
> > to /local/domain/<id> and must start "vm-data/..." (i.e. you can only
> > write to keys under /local/domain/<id>/vm-data/ using this mechanism).
> >
> > I suspect you aren't using xapi but the reason I mention it is that
> > someone added libxl_domain_create_info.xsdata in the early days of
> > libxl, presumably with this purpose in mind, but it appears not to be
> > hooked up into the xl configuration parser. I expect doing so would be a
> > reasonably simply job.
> 
> I'm not using Xapi, yup. But that seems a nice feature.
> 
> > Another, possibly more flexible but more complex option, would be to
> > allow for a series of hook scripts (both global and domain specific?) to
> > be called at various points in a VM lifecylce, including after building
> > but before starting.
> 
> There are already kind of hooks in the "on_reboot" "on_destroy" things.
> but thats quite in hazy future I guess. And it might be overkill.

Those options configure the behaviour of xl itself rather than calling
out to some hook script.

> It would be enough if the things you can add into a VM are configured in
> the same way, in the same place and run at start / stop!

That's what I was suggesting by exposing libxl_domain_create_info.xsdata
through xl.

> Ok. Technically the xenstore /vm/domain/XX is not IN the VM. :)
> 
> I'll poke around some more, either something using the udev xen backend
> or the easy and safe route with a small shellscripty-daemon.
> 
> Many people have looked for some way to find out the xen host's name
> from within a domU, it's pity this stuff isn't more obvious since it's quite
> nice to use (just consider stateless linux boxes)
> 
> Oh and THANKS to whomever wrote the Xenstore articles during last doc day.
> I was amazed when I found them.
> 
> Greetings,
> Florian
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:18:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:18:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXJS-0001cE-Q7; Thu, 24 Nov 2011 11:17:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTXJQ-0001c4-S5
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:17:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322133441!2848806!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7834 invoked from network); 24 Nov 2011 11:17:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 11:17:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9109350"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:17:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:17:21 +0000
Date: Thu, 24 Nov 2011 11:18:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@gmail.com>
In-Reply-To: <CAEBdQ91x9Afq5kSAZD=vttx+5yrfJbCcVpJNcWzBSYNmx_AMBw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111241117470.31179@kaball-desktop>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
	<CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
	<CAEBdQ91x9Afq5kSAZD=vttx+5yrfJbCcVpJNcWzBSYNmx_AMBw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 23 Nov 2011, Jean Guyader wrote:
> On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> > On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> >> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> >>
> >>>
> >>> The Intel GPU uses a two pages NVS region called OpRegion.
> >>> In order to get full support for the driver in the guest
> >>> we need to map this region.
> >>>
> >>> This patch reserves 2 pages on the top of the RAM and
> >>> mark this region as NVS in the e820. Then we write the
> >>> address to the config space (offset 0xfc) so the device
> >>> model can map the OpRegion at this address in the guest.
> >>
> >> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> >>
> >
> > Ok, that is handy.
> >
> >> Is it correct to do this for *all* gfx devices with Intel vendor id?
> >>
> >
> > The OpRegion is a Intel GPU specific thing.
> >
> 
> Sorry didn't read carefully the first time, yes I think it's correct
> to do that for
> all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
> something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
> a NVS region on the host, but that won't work for stub domain.

access to physical memory through /dev/mem should work from the stubdom

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:18:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:18:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXJS-0001cE-Q7; Thu, 24 Nov 2011 11:17:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTXJQ-0001c4-S5
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:17:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322133441!2848806!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7834 invoked from network); 24 Nov 2011 11:17:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 11:17:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9109350"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:17:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:17:21 +0000
Date: Thu, 24 Nov 2011 11:18:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@gmail.com>
In-Reply-To: <CAEBdQ91x9Afq5kSAZD=vttx+5yrfJbCcVpJNcWzBSYNmx_AMBw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111241117470.31179@kaball-desktop>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
	<CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
	<CAEBdQ91x9Afq5kSAZD=vttx+5yrfJbCcVpJNcWzBSYNmx_AMBw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 23 Nov 2011, Jean Guyader wrote:
> On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> > On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> >> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> >>
> >>>
> >>> The Intel GPU uses a two pages NVS region called OpRegion.
> >>> In order to get full support for the driver in the guest
> >>> we need to map this region.
> >>>
> >>> This patch reserves 2 pages on the top of the RAM and
> >>> mark this region as NVS in the e820. Then we write the
> >>> address to the config space (offset 0xfc) so the device
> >>> model can map the OpRegion at this address in the guest.
> >>
> >> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> >>
> >
> > Ok, that is handy.
> >
> >> Is it correct to do this for *all* gfx devices with Intel vendor id?
> >>
> >
> > The OpRegion is a Intel GPU specific thing.
> >
> 
> Sorry didn't read carefully the first time, yes I think it's correct
> to do that for
> all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
> something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
> a NVS region on the host, but that won't work for stub domain.

access to physical memory through /dev/mem should work from the stubdom

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:21:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXM7-0001iH-DT; Thu, 24 Nov 2011 11:20:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTXM5-0001hw-VY
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:20:38 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322133606!4779869!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30689 invoked from network); 24 Nov 2011 11:20:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 11:20:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9109410"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:20:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:20:03 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTXLW-0004ov-PS;
	Thu, 24 Nov 2011 11:20:02 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTXLJ-0006Iz-3w;
	Thu, 24 Nov 2011 11:19:49 +0000
Date: Thu, 24 Nov 2011 11:19:49 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20111124111948.GE22563@spongy.cam.xci-test.com>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
	<CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
	<CAEBdQ91x9Afq5kSAZD=vttx+5yrfJbCcVpJNcWzBSYNmx_AMBw@mail.gmail.com>
	<alpine.DEB.2.00.1111241117470.31179@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111241117470.31179@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jean Guyader <Jean.Guyader@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11 11:18, Stefano Stabellini wrote:
> On Wed, 23 Nov 2011, Jean Guyader wrote:
> > On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> > > On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> > >> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> > >>
> > >>>
> > >>> The Intel GPU uses a two pages NVS region called OpRegion.
> > >>> In order to get full support for the driver in the guest
> > >>> we need to map this region.
> > >>>
> > >>> This patch reserves 2 pages on the top of the RAM and
> > >>> mark this region as NVS in the e820. Then we write the
> > >>> address to the config space (offset 0xfc) so the device
> > >>> model can map the OpRegion at this address in the guest.
> > >>
> > >> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> > >>
> > >
> > > Ok, that is handy.
> > >
> > >> Is it correct to do this for *all* gfx devices with Intel vendor id?
> > >>
> > >
> > > The OpRegion is a Intel GPU specific thing.
> > >
> > 
> > Sorry didn't read carefully the first time, yes I think it's correct
> > to do that for
> > all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
> > something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
> > a NVS region on the host, but that won't work for stub domain.
> 
> access to physical memory through /dev/mem should work from the stubdom

I would think that /dev/mem in a stubdom will expose the memory of the guest but
maybe I'm wrong.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:21:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXM7-0001iH-DT; Thu, 24 Nov 2011 11:20:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTXM5-0001hw-VY
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:20:38 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322133606!4779869!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30689 invoked from network); 24 Nov 2011 11:20:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 11:20:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9109410"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:20:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:20:03 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTXLW-0004ov-PS;
	Thu, 24 Nov 2011 11:20:02 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTXLJ-0006Iz-3w;
	Thu, 24 Nov 2011 11:19:49 +0000
Date: Thu, 24 Nov 2011 11:19:49 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20111124111948.GE22563@spongy.cam.xci-test.com>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
	<CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
	<CAEBdQ91x9Afq5kSAZD=vttx+5yrfJbCcVpJNcWzBSYNmx_AMBw@mail.gmail.com>
	<alpine.DEB.2.00.1111241117470.31179@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111241117470.31179@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jean Guyader <Jean.Guyader@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11 11:18, Stefano Stabellini wrote:
> On Wed, 23 Nov 2011, Jean Guyader wrote:
> > On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> > > On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> > >> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> > >>
> > >>>
> > >>> The Intel GPU uses a two pages NVS region called OpRegion.
> > >>> In order to get full support for the driver in the guest
> > >>> we need to map this region.
> > >>>
> > >>> This patch reserves 2 pages on the top of the RAM and
> > >>> mark this region as NVS in the e820. Then we write the
> > >>> address to the config space (offset 0xfc) so the device
> > >>> model can map the OpRegion at this address in the guest.
> > >>
> > >> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> > >>
> > >
> > > Ok, that is handy.
> > >
> > >> Is it correct to do this for *all* gfx devices with Intel vendor id?
> > >>
> > >
> > > The OpRegion is a Intel GPU specific thing.
> > >
> > 
> > Sorry didn't read carefully the first time, yes I think it's correct
> > to do that for
> > all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
> > something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
> > a NVS region on the host, but that won't work for stub domain.
> 
> access to physical memory through /dev/mem should work from the stubdom

I would think that /dev/mem in a stubdom will expose the memory of the guest but
maybe I'm wrong.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:25:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:25:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXQN-0001uI-8R; Thu, 24 Nov 2011 11:25:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTXQL-0001u5-2W
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:25:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322133869!2842104!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4166 invoked from network); 24 Nov 2011 11:24:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 11:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9109527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:24:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:24:29 +0000
Date: Thu, 24 Nov 2011 11:25:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <20111124111948.GE22563@spongy.cam.xci-test.com>
Message-ID: <alpine.DEB.2.00.1111241123300.31179@kaball-desktop>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
	<CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
	<CAEBdQ91x9Afq5kSAZD=vttx+5yrfJbCcVpJNcWzBSYNmx_AMBw@mail.gmail.com>
	<alpine.DEB.2.00.1111241117470.31179@kaball-desktop>
	<20111124111948.GE22563@spongy.cam.xci-test.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 24 Nov 2011, Jean Guyader wrote:
> On 24/11 11:18, Stefano Stabellini wrote:
> > On Wed, 23 Nov 2011, Jean Guyader wrote:
> > > On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> > > > On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> > > >> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> > > >>
> > > >>>
> > > >>> The Intel GPU uses a two pages NVS region called OpRegion.
> > > >>> In order to get full support for the driver in the guest
> > > >>> we need to map this region.
> > > >>>
> > > >>> This patch reserves 2 pages on the top of the RAM and
> > > >>> mark this region as NVS in the e820. Then we write the
> > > >>> address to the config space (offset 0xfc) so the device
> > > >>> model can map the OpRegion at this address in the guest.
> > > >>
> > > >> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> > > >>
> > > >
> > > > Ok, that is handy.
> > > >
> > > >> Is it correct to do this for *all* gfx devices with Intel vendor id?
> > > >>
> > > >
> > > > The OpRegion is a Intel GPU specific thing.
> > > >
> > > 
> > > Sorry didn't read carefully the first time, yes I think it's correct
> > > to do that for
> > > all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
> > > something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
> > > a NVS region on the host, but that won't work for stub domain.
> > 
> > access to physical memory through /dev/mem should work from the stubdom
> 
> I would think that /dev/mem in a stubdom will expose the memory of the guest but
> maybe I'm wrong.
> 
 
Nope, it maps host memory. Of course you need to make sure you have
given enough privileges to the stubdom so that it can actually map the
memory area.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:25:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:25:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXQN-0001uI-8R; Thu, 24 Nov 2011 11:25:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTXQL-0001u5-2W
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:25:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322133869!2842104!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4166 invoked from network); 24 Nov 2011 11:24:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 11:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9109527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:24:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:24:29 +0000
Date: Thu, 24 Nov 2011 11:25:18 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <20111124111948.GE22563@spongy.cam.xci-test.com>
Message-ID: <alpine.DEB.2.00.1111241123300.31179@kaball-desktop>
References: <1322064460-22248-1-git-send-email-jean.guyader@eu.citrix.com>
	<CAF2DBD2.256F3%keir.xen@gmail.com>
	<CAEBdQ93KdD30Q6Uzf+_p3tgNF4qhVb5YPewZz5Bt7=ObyF+z7A@mail.gmail.com>
	<CAEBdQ91x9Afq5kSAZD=vttx+5yrfJbCcVpJNcWzBSYNmx_AMBw@mail.gmail.com>
	<alpine.DEB.2.00.1111241117470.31179@kaball-desktop>
	<20111124111948.GE22563@spongy.cam.xci-test.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>, Keir Fraser <keir.xen@gmail.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
 reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 24 Nov 2011, Jean Guyader wrote:
> On 24/11 11:18, Stefano Stabellini wrote:
> > On Wed, 23 Nov 2011, Jean Guyader wrote:
> > > On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> > > > On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> > > >> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> > > >>
> > > >>>
> > > >>> The Intel GPU uses a two pages NVS region called OpRegion.
> > > >>> In order to get full support for the driver in the guest
> > > >>> we need to map this region.
> > > >>>
> > > >>> This patch reserves 2 pages on the top of the RAM and
> > > >>> mark this region as NVS in the e820. Then we write the
> > > >>> address to the config space (offset 0xfc) so the device
> > > >>> model can map the OpRegion at this address in the guest.
> > > >>
> > > >> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> > > >>
> > > >
> > > > Ok, that is handy.
> > > >
> > > >> Is it correct to do this for *all* gfx devices with Intel vendor id?
> > > >>
> > > >
> > > > The OpRegion is a Intel GPU specific thing.
> > > >
> > > 
> > > Sorry didn't read carefully the first time, yes I think it's correct
> > > to do that for
> > > all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
> > > something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
> > > a NVS region on the host, but that won't work for stub domain.
> > 
> > access to physical memory through /dev/mem should work from the stubdom
> 
> I would think that /dev/mem in a stubdom will expose the memory of the guest but
> maybe I'm wrong.
> 
 
Nope, it maps host memory. Of course you need to make sure you have
given enough privileges to the stubdom so that it can actually map the
memory area.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:36:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXah-00027l-Jb; Thu, 24 Nov 2011 11:35:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTXag-00027g-Hx
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:35:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322134511!2845704!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18629 invoked from network); 24 Nov 2011 11:35:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 11:35:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTXa7-000Ke7-Qn; Thu, 24 Nov 2011 11:35:07 +0000
Date: Thu, 24 Nov 2011 11:35:07 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124113507.GA77868@ocelot.phlegethon.org>
References: <patchbomb.1320788543@xdev.gridcentric.ca>
	<6203a0549d8a1a21753b.1320788545@xdev.gridcentric.ca>
	<20111110125342.GG62117@ocelot.phlegethon.org>
	<4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Make p2m lookups fully synchronized
	wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:03 -0800 on 14 Nov (1321264988), Andres Lagar-Cavilla wrote:
> Hi there,
> > At 16:42 -0500 on 08 Nov (1320770545), Andres Lagar-Cavilla wrote:
> >>  xen/arch/x86/mm/mm-locks.h |  13 +++++++------
> >>  xen/arch/x86/mm/p2m.c      |  18 +++++++++++++++++-
> >>  xen/include/asm-x86/p2m.h  |  39
> >> ++++++++++++++++++++++++---------------
> >>  3 files changed, 48 insertions(+), 22 deletions(-)
> >>
> >>
> >> We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.
> >> This brings about a few consequences for the p2m_lock:
> >>
> >>  - not ordered anymore in mm-locks.h: unshare does get_gfn -> shr_lock,
> >>    there are code paths that do paging_lock -> get_gfn. All of these
> >>    would cause mm-locks.h to panic.
> >
> > In that case there's a potential deadlock in the sharing code, and
> > turning off the safety catches is not an acceptable response to that. :)
> >
> > ISTR you had a plan to get rid of the shr_lock entirely, or am
> > I misremembering?
> Sharing is actually fine, I can reorder those safely until I get rid of
> the shr_lock. Except for sharing audits, which basically lock the whole
> hypervisor, and _no one is using at all_.
> 
> I have a more fundamental problem with the paging lock. sh_update_cr3 can
> be called from a variety of situations. It will walk the four top level
> PAE mappings, acquiring the p2m entry for each, with the paging lock held.
> This is an inversion & deadlock, if I try to synchronize p2m lookups with
> the p2m lock.

Is sh_update_cr3() really called with p2m locks/refs held?  Since it
doesn't take a frame number as an argument it might be possible to
shuffle things around at the callers.

> Any suggestions here? Other than disabling ordering of the p2m lock?

Disabling the ordering won't do, so we need to find something else.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:36:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXah-00027l-Jb; Thu, 24 Nov 2011 11:35:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTXag-00027g-Hx
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:35:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322134511!2845704!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18629 invoked from network); 24 Nov 2011 11:35:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 11:35:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTXa7-000Ke7-Qn; Thu, 24 Nov 2011 11:35:07 +0000
Date: Thu, 24 Nov 2011 11:35:07 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124113507.GA77868@ocelot.phlegethon.org>
References: <patchbomb.1320788543@xdev.gridcentric.ca>
	<6203a0549d8a1a21753b.1320788545@xdev.gridcentric.ca>
	<20111110125342.GG62117@ocelot.phlegethon.org>
	<4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Make p2m lookups fully synchronized
	wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 10:03 -0800 on 14 Nov (1321264988), Andres Lagar-Cavilla wrote:
> Hi there,
> > At 16:42 -0500 on 08 Nov (1320770545), Andres Lagar-Cavilla wrote:
> >>  xen/arch/x86/mm/mm-locks.h |  13 +++++++------
> >>  xen/arch/x86/mm/p2m.c      |  18 +++++++++++++++++-
> >>  xen/include/asm-x86/p2m.h  |  39
> >> ++++++++++++++++++++++++---------------
> >>  3 files changed, 48 insertions(+), 22 deletions(-)
> >>
> >>
> >> We achieve this by locking/unlocking the global p2m_lock in get/put_gfn.
> >> This brings about a few consequences for the p2m_lock:
> >>
> >>  - not ordered anymore in mm-locks.h: unshare does get_gfn -> shr_lock,
> >>    there are code paths that do paging_lock -> get_gfn. All of these
> >>    would cause mm-locks.h to panic.
> >
> > In that case there's a potential deadlock in the sharing code, and
> > turning off the safety catches is not an acceptable response to that. :)
> >
> > ISTR you had a plan to get rid of the shr_lock entirely, or am
> > I misremembering?
> Sharing is actually fine, I can reorder those safely until I get rid of
> the shr_lock. Except for sharing audits, which basically lock the whole
> hypervisor, and _no one is using at all_.
> 
> I have a more fundamental problem with the paging lock. sh_update_cr3 can
> be called from a variety of situations. It will walk the four top level
> PAE mappings, acquiring the p2m entry for each, with the paging lock held.
> This is an inversion & deadlock, if I try to synchronize p2m lookups with
> the p2m lock.

Is sh_update_cr3() really called with p2m locks/refs held?  Since it
doesn't take a frame number as an argument it might be possible to
shuffle things around at the callers.

> Any suggestions here? Other than disabling ordering of the p2m lock?

Disabling the ordering won't do, so we need to find something else.

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:38:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:38:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXdT-0002Ds-9m; Thu, 24 Nov 2011 11:38:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTXdR-0002De-Q7
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:38:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322134682!2844486!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27966 invoked from network); 24 Nov 2011 11:38:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 11:38:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTXcw-000KfE-3d; Thu, 24 Nov 2011 11:38:02 +0000
Date: Thu, 24 Nov 2011 11:38:02 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111124113802.GB77868@ocelot.phlegethon.org>
References: <20111114165302.GA6688@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111114165302.GA6688@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 17:53 +0100 on 14 Nov (1321293182), Olaf Hering wrote:
> 
> I was wondering why ept_p2m_type_to_flags() removes all permissions from
> a gfn in state p2m_ram_paging_out. If the guest happens to read or
> execute from that page while the pager writes that gfn to disk, wouldnt
> it be enough to remove the write bit to prevent writes from the guest?
> If the page is read-only the guest could continue to make progress until
> the gfn is really evicted and the p2mt changes to p2m_ram_paged.
> 
> I havent actually tried the patch below, but is there any reason it
> would break the guest?

As long as we change the p2m type before scrubbing or freeing the page,
that seems like it shuold be fine. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:38:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:38:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXdT-0002Ds-9m; Thu, 24 Nov 2011 11:38:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTXdR-0002De-Q7
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:38:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322134682!2844486!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27966 invoked from network); 24 Nov 2011 11:38:02 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 11:38:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTXcw-000KfE-3d; Thu, 24 Nov 2011 11:38:02 +0000
Date: Thu, 24 Nov 2011 11:38:02 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20111124113802.GB77868@ocelot.phlegethon.org>
References: <20111114165302.GA6688@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111114165302.GA6688@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 17:53 +0100 on 14 Nov (1321293182), Olaf Hering wrote:
> 
> I was wondering why ept_p2m_type_to_flags() removes all permissions from
> a gfn in state p2m_ram_paging_out. If the guest happens to read or
> execute from that page while the pager writes that gfn to disk, wouldnt
> it be enough to remove the write bit to prevent writes from the guest?
> If the page is read-only the guest could continue to make progress until
> the gfn is really evicted and the p2mt changes to p2m_ram_paged.
> 
> I havent actually tried the patch below, but is there any reason it
> would break the guest?

As long as we change the p2m type before scrubbing or freeing the page,
that seems like it shuold be fine. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:39:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXdf-0002Er-Mm; Thu, 24 Nov 2011 11:38:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTXdd-0002Ed-TU
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:38:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322134580!45627654!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23593 invoked from network); 24 Nov 2011 11:36:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 11:36:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9109842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:38:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:38:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTXdD-0004vy-B4; Thu, 24 Nov 2011 11:38:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTXdD-0003zO-AG;
	Thu, 24 Nov 2011 11:38:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.11435.306730.583922@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 11:38:19 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00 of 14] MM Fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 00 of 14] MM Fixes"):
> This patch series includes a number of bug fixes, targetting 
> primarily the mm layer. Many of these fixes also lay groundwork
> for future patches.

Thanks.  Something seems to have eaten patches 12,13,14.

Can you please confirm that you sent them, and tell me their
messageids, and any information you can tell me about their
transmission ?

Ideally I would like log entries from the final hop mail server on
your side showing the messages being handed over to the MX's for
lists.xensource.com, but looking at the headers of your other messages
they came through "homiemail-***.***.dreamhost.com" so that may
involve talking to whoever they are.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:39:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXdf-0002Er-Mm; Thu, 24 Nov 2011 11:38:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTXdd-0002Ed-TU
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:38:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322134580!45627654!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23593 invoked from network); 24 Nov 2011 11:36:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 11:36:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,564,1315180800"; 
   d="scan'208";a="9109842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:38:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:38:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTXdD-0004vy-B4; Thu, 24 Nov 2011 11:38:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTXdD-0003zO-AG;
	Thu, 24 Nov 2011 11:38:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.11435.306730.583922@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 11:38:19 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00 of 14] MM Fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 00 of 14] MM Fixes"):
> This patch series includes a number of bug fixes, targetting 
> primarily the mm layer. Many of these fixes also lay groundwork
> for future patches.

Thanks.  Something seems to have eaten patches 12,13,14.

Can you please confirm that you sent them, and tell me their
messageids, and any information you can tell me about their
transmission ?

Ideally I would like log entries from the final hop mail server on
your side showing the messages being handed over to the MX's for
lists.xensource.com, but looking at the headers of your other messages
they came through "homiemail-***.***.dreamhost.com" so that may
involve talking to whoever they are.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:59:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:59:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXx8-0002kz-UM; Thu, 24 Nov 2011 11:58:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTXx7-0002kP-7f
	for Xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:58:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322135901!3994101!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6978 invoked from network); 24 Nov 2011 11:58:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 11:58:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTXwW-000Kjf-Pd; Thu, 24 Nov 2011 11:58:16 +0000
Date: Thu, 24 Nov 2011 11:58:16 +0000
From: Tim Deegan <tim@xen.org>
To: ???? <327801865@qq.com>
Message-ID: <20111124115816.GD77868@ocelot.phlegethon.org>
References: <tencent_1975194D595A261C1C28650E@qq.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tencent_1975194D595A261C1C28650E@qq.com>
User-Agent: Mutt/1.4.2.1i
Cc: Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] HVM (hypercall_grant_table_op) Problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 00:52 +0800 on 18 Nov (1321577533), ???? wrote:
> Hi:
>      I modified the netfont.c of Linux HVM domU installed PVonHVM.In it, I call hypercall_grant_table_op
>  (GNTTABOP_map_grant_ref...), then dom0 shutdown and restart at once.

Do you have a serial line attached to the machine to capture the console
output when this happens?  Without that it's hard to knwo what the bug is.

>      From above, I conclude that I can map a HVM's page to another HVM, just like two PVs. 
>  Am I wrong? Who can give me some suggestion?

Yes, HVM guests can now map granted frames, but not quite 'just like pv'.
The grant hypercall maps the granted frame into the HVM guest's p2m map,
instead of into the pagetables.  That is, you pass in a PFN, and when
the grant succeeds, you still need to map that PFN in your pagetables to
access the page. 

The checkin that added the feature came with this comment:

  After some discussion, here's a second version of the patch I posted a
  couple of weeks back to map grant references into HVM guests.  As
  before, this is done by modifying the P2M map, but this time there's
  no new hypercall to do it.  Instead, the existing GNTTABOP_map is
  overloaded to perform a P2M mapping if called from a shadow mode
  translate guest.  This matches the IA64 API.

http://xenbits.xen.org/hg/xen-unstable.hg/rev/c0cb307d927f

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 11:59:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 11:59:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXx8-0002kz-UM; Thu, 24 Nov 2011 11:58:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTXx7-0002kP-7f
	for Xen-devel@lists.xensource.com; Thu, 24 Nov 2011 11:58:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322135901!3994101!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6978 invoked from network); 24 Nov 2011 11:58:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 11:58:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTXwW-000Kjf-Pd; Thu, 24 Nov 2011 11:58:16 +0000
Date: Thu, 24 Nov 2011 11:58:16 +0000
From: Tim Deegan <tim@xen.org>
To: ???? <327801865@qq.com>
Message-ID: <20111124115816.GD77868@ocelot.phlegethon.org>
References: <tencent_1975194D595A261C1C28650E@qq.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tencent_1975194D595A261C1C28650E@qq.com>
User-Agent: Mutt/1.4.2.1i
Cc: Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] HVM (hypercall_grant_table_op) Problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 00:52 +0800 on 18 Nov (1321577533), ???? wrote:
> Hi:
>      I modified the netfont.c of Linux HVM domU installed PVonHVM.In it, I call hypercall_grant_table_op
>  (GNTTABOP_map_grant_ref...), then dom0 shutdown and restart at once.

Do you have a serial line attached to the machine to capture the console
output when this happens?  Without that it's hard to knwo what the bug is.

>      From above, I conclude that I can map a HVM's page to another HVM, just like two PVs. 
>  Am I wrong? Who can give me some suggestion?

Yes, HVM guests can now map granted frames, but not quite 'just like pv'.
The grant hypercall maps the granted frame into the HVM guest's p2m map,
instead of into the pagetables.  That is, you pass in a PFN, and when
the grant succeeds, you still need to map that PFN in your pagetables to
access the page. 

The checkin that added the feature came with this comment:

  After some discussion, here's a second version of the patch I posted a
  couple of weeks back to map grant references into HVM guests.  As
  before, this is done by modifying the P2M map, but this time there's
  no new hypercall to do it.  Instead, the existing GNTTABOP_map is
  overloaded to perform a P2M mapping if called from a shadow mode
  translate guest.  This matches the IA64 API.

http://xenbits.xen.org/hg/xen-unstable.hg/rev/c0cb307d927f

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:01:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXze-00033w-5g; Thu, 24 Nov 2011 12:01:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTXzc-00033U-Uw
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:01:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322136057!4446189!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29975 invoked from network); 24 Nov 2011 12:00:58 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 12:00:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTXz6-000Kkm-Kr; Thu, 24 Nov 2011 12:00:56 +0000
Date: Thu, 24 Nov 2011 12:00:56 +0000
From: Tim Deegan <tim@xen.org>
To: Xin Jin <jxinpku@gmail.com>
Message-ID: <20111124120056.GE77868@ocelot.phlegethon.org>
References: <CAKpDea=ZVyz2Oza8p0UHijuspfkMCpQjSD_Kc_yDz8ftrrrucw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKpDea=ZVyz2Oza8p0UHijuspfkMCpQjSD_Kc_yDz8ftrrrucw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Create shared memory between HVM domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:30 -0500 on 20 Nov (1321828217), Xin Jin wrote:
> Hi,
> 
> I just want to know if it is possible to use grant table to create shared
> memory between HVM domU.

AFAIK, it ought to work (see my last mail to the list), but I haven't
tried it recently.  I believe that there are some other users of it.

> I tried in Xen 4.1.1 with Linux kernel 3.1.1.
> It seems that I cannot create it.

You'll need to post a lot more detail if you want anyone to help you
with this.  See http://wiki.xen.org/xenwiki/AskingXenDevelQuestions

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:01:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTXze-00033w-5g; Thu, 24 Nov 2011 12:01:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTXzc-00033U-Uw
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:01:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322136057!4446189!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29975 invoked from network); 24 Nov 2011 12:00:58 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 12:00:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTXz6-000Kkm-Kr; Thu, 24 Nov 2011 12:00:56 +0000
Date: Thu, 24 Nov 2011 12:00:56 +0000
From: Tim Deegan <tim@xen.org>
To: Xin Jin <jxinpku@gmail.com>
Message-ID: <20111124120056.GE77868@ocelot.phlegethon.org>
References: <CAKpDea=ZVyz2Oza8p0UHijuspfkMCpQjSD_Kc_yDz8ftrrrucw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKpDea=ZVyz2Oza8p0UHijuspfkMCpQjSD_Kc_yDz8ftrrrucw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Create shared memory between HVM domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:30 -0500 on 20 Nov (1321828217), Xin Jin wrote:
> Hi,
> 
> I just want to know if it is possible to use grant table to create shared
> memory between HVM domU.

AFAIK, it ought to work (see my last mail to the list), but I haven't
tried it recently.  I believe that there are some other users of it.

> I tried in Xen 4.1.1 with Linux kernel 3.1.1.
> It seems that I cannot create it.

You'll need to post a lot more detail if you want anyone to help you
with this.  See http://wiki.xen.org/xenwiki/AskingXenDevelQuestions

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:10:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:10:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTY83-0003Mw-DO; Thu, 24 Nov 2011 12:10:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RTY82-0003Mr-LT
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:10:10 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322136578!5528229!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16687 invoked from network); 24 Nov 2011 12:09:39 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 12:09:39 -0000
Received: by qyk7 with SMTP id 7so1270788qyk.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 04:09:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=1jE5K5ziXucvYrJD9MajV0jJQUqbSMXfGNrB/WKHmYU=;
	b=vvZHriB1I5TMQXgznFsPeS7ZKgdKHH+420lrL9YoDRVw3cSgYjYlLsweUdr3D1P+wv
	Y5kGopOIEPqX4coch4xIOpIM6Iu6yscMsJ4kDWmzKEniFoOkvOM0llIZesbUULfLy70i
	axpAGRR5Dxzso/J2ncliy3mHWJy2LdbP+ec/Y=
Received: by 10.182.77.231 with SMTP id v7mr9442945obw.4.1322136578110; Thu,
	24 Nov 2011 04:09:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.37.225 with HTTP; Thu, 24 Nov 2011 04:09:07 -0800 (PST)
In-Reply-To: <1322126555.9567.39.camel@dagon.hellion.org.uk>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
	<1322126555.9567.39.camel@dagon.hellion.org.uk>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 24 Nov 2011 12:09:07 +0000
X-Google-Sender-Auth: bmJmEJPcdWbEhh95QIAC9b9scMk
Message-ID: <CAJJyHjK2FQ-wbutCjOWZ5uJOyGJN=qvFp7C5f+ofDMZntjx69Q@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] Migration on QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBOb3YgMjQsIDIwMTEgYXQgMDk6MjIsIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxs
QGNpdHJpeC5jb20+IHdyb3RlOgo+IE9uIFdlZCwgMjAxMS0xMS0yMyBhdCAxNzo0MCArMDAwMCwg
QW50aG9ueSBQRVJBUkQgd3JvdGU6Cj4+IEhpIGFsbCwKPj4KPj4gVGhpcyBwYXRjaCBzZXJpZXMg
aW50cm9kdWNlIG1pZ3JhdGlvbiB3aXRoIFFFTVUgdXBzdHJlYW0uCj4+Cj4+IEEgcGF0Y2ggc2Vy
aWVzIGZvciBRRU1VIHdpbGwgYmUgc2VudCBsYXRlciBtZWFudCB0byAiZml4IiB0aGUgZGVmYXVs
dCBiZWhhdmlvcgo+PiBvZiBRRU1VIGR1cmluZyBzYXZlL3Jlc3RvcmUuCj4+Cj4+IFRoZXJlIGlz
IHR3byBuZXcgUU1QIGNvbW1hbmRzIGltcGxlbWVudGVkOgo+PiDCoCAtIGdldGZkOiBUaGlzIGdp
dmUgYSBmaWxlIGRlc2NyaXB0b3IgdG8gUUVNVSB0aHJvdWdoIHRoZSB1bml4IHNvY2tldC4KPgo+
IFRoaXMgc291bmRzIG1vcmUgbGlrZSBhIHNldGZkIGNvbW1hbmQuCgpXZWxsLCBpdCdzIHRoZSBu
YW1lIG9mIHRoZSBRTVAgY29tbWFuZC4gSSBqdXN0IHJlc3BlY3QgdGhlCiJjb252ZW50aW9uIiBJ
IGhhdmUgaW4gdGhlIHJlc3Qgb2YgdGhlIGZpbGUgdGhhdCBpcwovKGxpYnhsX18pP3FtcF8oPzxj
b21tYW5kX25hbWU+LispLwoKCj4+IMKgIC0gbWlncmF0aW9uOiBUaGlzIGFzayBRRU1VIHRvIHNh
dmUgaXRzIHN0YXRlcyBpbiBhIGZkIHByZXZpb3VzbHkgc2VudC4KPgo+IFdoeSBjYW4gdGhlIGZk
IG5vdCBiZSBpbmNsdWRlZCBpbiB0aGlzIG1lc3NhZ2UgZGlyZWN0bHk/CgpUaGUgbWlncmF0ZSBj
b21tYW5kIG9ubHkgYWNjZXB0ICJmZDpuYW1lZGZkIiBhcyBvdXRwdXQgKGFtb25nIG90aGVyCndh
eSkuIEFuZCB0byBoYXZlIGEgbmFtZWQgZmQsIHdlIGhhdmUgdG8gY2FsbCAiZ2V0ZmQiIGZpc3Qu
IEJ1dCBoZXJlLApJIGRvIGJvdGggd2l0aCBvbmUgY2FsbCBmcm9tIHRoZSB3aWxkLgoKPiBIb3cg
aXMgYSBnaXZlbiB7cyxnfWV0ZmQgY2FsbCBhc3NvY2lhdGVkIHdpdGggdGhlIG1pZ3JhdGlvbiBj
b21tYW5kPwoKbGlieGxfX3FtcF9taWdyYXRlIHdpbGwgY2FsbCBhIHN0YXRpYyBmdW5jdGlvbiBx
bXBfZ2V0ZmQoZmQsICJtaWdyYXRpb24tZmQiKQoKPiBXaGF0IGhhcHBlbnMgaWYgc29tZSBvdGhl
ciBjb21tYW5kIGFsc28gd2FudHMgdG8gcmVjZWl2ZSBhbiBmZCBpbiB0aGUgZnV0dXJlPwoKVGhl
IGZ1dHVyIGNvbW1hbmQgY2FuIGp1c3QgY2FsbCB0aGUgcW1wX2dldGZkIGZ1bmN0aW9uLCBvciB3
ZSBjYW4KZXhwb3J0IHFtcF9nZXRmZC4KCj4gSSBwcmVzdW1lIHRoYXQgYSBidW5jaCBvZiB0aGlz
IHdpbGwgYmVjb21lIMKgbW9yZSBvYnZpb3VzIHdoZW4gdGhlIHFlbXUKPiBzaWRlIGlzIHBvc3Rl
ZCwgdGhlcmUncyBhIHFlbXUgcHJvdG9jb2wgc3BlYyBpbiB0aGF0IHJpZ2h0PwoKTW1oLCBub3Qg
cmVhbGx5LCB0aGVyZSBpcyBub3RoaW5nIHRvIGhhZCBpbiBRRU1VIHNpZGUuIGdldGZkIGFuZApt
aWdyYXRlIGFyZSBib3RoIFFNUCBjb21tYW5kLiBZb3UgY2FuIGxvb2sgaW4gdGhlIGZpbGUgcW1w
LWNvbW1hbmRzLmh4CmluIFFFTVUgZm9yIHRoZSBjb21tYW5kIG1pZ3JhdGUgYW5kIGdldGZkOyBh
bmQgbG9vayBpbiB0aGUgZmlsZQpkb2NzL21pZ3JhdGlvbi50eHQgdG8ga25vdyB3aWNoICJUeXBl
cyBvZiBtaWdyYXRpb24iIFFFTVUgdXNlLgoKVGhlIFFFTVUgcGF0Y2ggc2VyaWVzIEknbSBhYm91
dCB0byBzZW5kIGlzIGp1c3QgYSAiZml4IiBmb3IgdGhlIFhlbiBjYXNlOgogLSBkbyBub3Qgc2F2
ZSB0aGUgUkFNLgogLSBhdCByZXN0b3JlIHRpbWUsIGRvIG5vdCB0cnkgdG8gImFsbG9jYXRlIiAo
cG9wdWxhdGVfcGh5c21hcCkgbWVtb3J5CnRoYXQgc2hvdWxkIGFscmVhZHkgYmUgYWxsb2NhdGVk
LCBhbmQgYWNjZXNzIHRvIHRoZSByaWdodCBndWVzdAphZGRyZXNzIGluIGNhc2UgdGhpcyBvbmUg
aGF2ZSBiZWVuICJtb3ZlZCIgKHRydWUgZm9yIHRoZSBWaWRlb1JBTSkKKCJtb3ZlZCIgdXNpbmcg
YWRkX3RvX3BoeXNtYXApLgoKPj4gSW4gb3JkZXIgdG8gY2FsbCAiZ2V0ZmQiLCBhbiBhbHRlcm5h
dGl2ZSBxbXBfc2VuZCBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgaW4KPj4gbGlieGwuCj4KPiBZb3Ug
Y291bGQgYWxzbyBoYXZlIGFkZGVkIG9wdGlvbmFsIG1zZ19jb250cm9se2xlbn0gcGFyYW1ldGVy
cyB0byB0aGUKPiBleGlzdGluZyBjb21tYW5kLiBJIGRvbid0IGtub3cgaWYgdGhhdCBpcyBiZXR0
ZXIgdGhvdWdoLgoKV2VsbCwgdGhpcyB3aWxsIGJlIGFuIGV4dHJhIHBhcmFtZXRlciB0aGF0IHdp
bGwgYmUgdXNlZCBpbiBvbmx5IG9uZQpjYXNlIChJIHRoaW5rKS4gQW5kIHRoaXMgcGFyYW1ldGVy
IHdpbGwgYmUgYSBiaXQgb2JzY3VyZS4gU28sIHByb2JhYmx5CmJvdGggYXJlIGdvb2QuIEFsc28s
IHRoZSBjb2RlIHRoYXQgcHJlcGFyZSB0aGUgbWVzc2FnZSAoc3RyaW5nKSB0byBiZQpzZW50IGlz
IGluIGEgc2VwYXJhdGUgZnVuY3Rpb24gbm93LCBzbyBib3RoIHFtcF9zZW5kIGFuZCBxbXBfc2Vu
ZF9mZApkbyBub3QgaGF2ZSBhbnl0aGluZyBpbiBjb21tb24gKGFsbW9zdCkuCgpUaGFua3MsCgot
LSAKQW50aG9ueSBQRVJBUkQKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:10:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:10:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTY83-0003Mw-DO; Thu, 24 Nov 2011 12:10:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RTY82-0003Mr-LT
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:10:10 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322136578!5528229!1
X-Originating-IP: [209.85.216.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16687 invoked from network); 24 Nov 2011 12:09:39 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 12:09:39 -0000
Received: by qyk7 with SMTP id 7so1270788qyk.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 04:09:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=1jE5K5ziXucvYrJD9MajV0jJQUqbSMXfGNrB/WKHmYU=;
	b=vvZHriB1I5TMQXgznFsPeS7ZKgdKHH+420lrL9YoDRVw3cSgYjYlLsweUdr3D1P+wv
	Y5kGopOIEPqX4coch4xIOpIM6Iu6yscMsJ4kDWmzKEniFoOkvOM0llIZesbUULfLy70i
	axpAGRR5Dxzso/J2ncliy3mHWJy2LdbP+ec/Y=
Received: by 10.182.77.231 with SMTP id v7mr9442945obw.4.1322136578110; Thu,
	24 Nov 2011 04:09:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.37.225 with HTTP; Thu, 24 Nov 2011 04:09:07 -0800 (PST)
In-Reply-To: <1322126555.9567.39.camel@dagon.hellion.org.uk>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
	<1322126555.9567.39.camel@dagon.hellion.org.uk>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 24 Nov 2011 12:09:07 +0000
X-Google-Sender-Auth: bmJmEJPcdWbEhh95QIAC9b9scMk
Message-ID: <CAJJyHjK2FQ-wbutCjOWZ5uJOyGJN=qvFp7C5f+ofDMZntjx69Q@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] Migration on QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBOb3YgMjQsIDIwMTEgYXQgMDk6MjIsIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxs
QGNpdHJpeC5jb20+IHdyb3RlOgo+IE9uIFdlZCwgMjAxMS0xMS0yMyBhdCAxNzo0MCArMDAwMCwg
QW50aG9ueSBQRVJBUkQgd3JvdGU6Cj4+IEhpIGFsbCwKPj4KPj4gVGhpcyBwYXRjaCBzZXJpZXMg
aW50cm9kdWNlIG1pZ3JhdGlvbiB3aXRoIFFFTVUgdXBzdHJlYW0uCj4+Cj4+IEEgcGF0Y2ggc2Vy
aWVzIGZvciBRRU1VIHdpbGwgYmUgc2VudCBsYXRlciBtZWFudCB0byAiZml4IiB0aGUgZGVmYXVs
dCBiZWhhdmlvcgo+PiBvZiBRRU1VIGR1cmluZyBzYXZlL3Jlc3RvcmUuCj4+Cj4+IFRoZXJlIGlz
IHR3byBuZXcgUU1QIGNvbW1hbmRzIGltcGxlbWVudGVkOgo+PiDCoCAtIGdldGZkOiBUaGlzIGdp
dmUgYSBmaWxlIGRlc2NyaXB0b3IgdG8gUUVNVSB0aHJvdWdoIHRoZSB1bml4IHNvY2tldC4KPgo+
IFRoaXMgc291bmRzIG1vcmUgbGlrZSBhIHNldGZkIGNvbW1hbmQuCgpXZWxsLCBpdCdzIHRoZSBu
YW1lIG9mIHRoZSBRTVAgY29tbWFuZC4gSSBqdXN0IHJlc3BlY3QgdGhlCiJjb252ZW50aW9uIiBJ
IGhhdmUgaW4gdGhlIHJlc3Qgb2YgdGhlIGZpbGUgdGhhdCBpcwovKGxpYnhsX18pP3FtcF8oPzxj
b21tYW5kX25hbWU+LispLwoKCj4+IMKgIC0gbWlncmF0aW9uOiBUaGlzIGFzayBRRU1VIHRvIHNh
dmUgaXRzIHN0YXRlcyBpbiBhIGZkIHByZXZpb3VzbHkgc2VudC4KPgo+IFdoeSBjYW4gdGhlIGZk
IG5vdCBiZSBpbmNsdWRlZCBpbiB0aGlzIG1lc3NhZ2UgZGlyZWN0bHk/CgpUaGUgbWlncmF0ZSBj
b21tYW5kIG9ubHkgYWNjZXB0ICJmZDpuYW1lZGZkIiBhcyBvdXRwdXQgKGFtb25nIG90aGVyCndh
eSkuIEFuZCB0byBoYXZlIGEgbmFtZWQgZmQsIHdlIGhhdmUgdG8gY2FsbCAiZ2V0ZmQiIGZpc3Qu
IEJ1dCBoZXJlLApJIGRvIGJvdGggd2l0aCBvbmUgY2FsbCBmcm9tIHRoZSB3aWxkLgoKPiBIb3cg
aXMgYSBnaXZlbiB7cyxnfWV0ZmQgY2FsbCBhc3NvY2lhdGVkIHdpdGggdGhlIG1pZ3JhdGlvbiBj
b21tYW5kPwoKbGlieGxfX3FtcF9taWdyYXRlIHdpbGwgY2FsbCBhIHN0YXRpYyBmdW5jdGlvbiBx
bXBfZ2V0ZmQoZmQsICJtaWdyYXRpb24tZmQiKQoKPiBXaGF0IGhhcHBlbnMgaWYgc29tZSBvdGhl
ciBjb21tYW5kIGFsc28gd2FudHMgdG8gcmVjZWl2ZSBhbiBmZCBpbiB0aGUgZnV0dXJlPwoKVGhl
IGZ1dHVyIGNvbW1hbmQgY2FuIGp1c3QgY2FsbCB0aGUgcW1wX2dldGZkIGZ1bmN0aW9uLCBvciB3
ZSBjYW4KZXhwb3J0IHFtcF9nZXRmZC4KCj4gSSBwcmVzdW1lIHRoYXQgYSBidW5jaCBvZiB0aGlz
IHdpbGwgYmVjb21lIMKgbW9yZSBvYnZpb3VzIHdoZW4gdGhlIHFlbXUKPiBzaWRlIGlzIHBvc3Rl
ZCwgdGhlcmUncyBhIHFlbXUgcHJvdG9jb2wgc3BlYyBpbiB0aGF0IHJpZ2h0PwoKTW1oLCBub3Qg
cmVhbGx5LCB0aGVyZSBpcyBub3RoaW5nIHRvIGhhZCBpbiBRRU1VIHNpZGUuIGdldGZkIGFuZApt
aWdyYXRlIGFyZSBib3RoIFFNUCBjb21tYW5kLiBZb3UgY2FuIGxvb2sgaW4gdGhlIGZpbGUgcW1w
LWNvbW1hbmRzLmh4CmluIFFFTVUgZm9yIHRoZSBjb21tYW5kIG1pZ3JhdGUgYW5kIGdldGZkOyBh
bmQgbG9vayBpbiB0aGUgZmlsZQpkb2NzL21pZ3JhdGlvbi50eHQgdG8ga25vdyB3aWNoICJUeXBl
cyBvZiBtaWdyYXRpb24iIFFFTVUgdXNlLgoKVGhlIFFFTVUgcGF0Y2ggc2VyaWVzIEknbSBhYm91
dCB0byBzZW5kIGlzIGp1c3QgYSAiZml4IiBmb3IgdGhlIFhlbiBjYXNlOgogLSBkbyBub3Qgc2F2
ZSB0aGUgUkFNLgogLSBhdCByZXN0b3JlIHRpbWUsIGRvIG5vdCB0cnkgdG8gImFsbG9jYXRlIiAo
cG9wdWxhdGVfcGh5c21hcCkgbWVtb3J5CnRoYXQgc2hvdWxkIGFscmVhZHkgYmUgYWxsb2NhdGVk
LCBhbmQgYWNjZXNzIHRvIHRoZSByaWdodCBndWVzdAphZGRyZXNzIGluIGNhc2UgdGhpcyBvbmUg
aGF2ZSBiZWVuICJtb3ZlZCIgKHRydWUgZm9yIHRoZSBWaWRlb1JBTSkKKCJtb3ZlZCIgdXNpbmcg
YWRkX3RvX3BoeXNtYXApLgoKPj4gSW4gb3JkZXIgdG8gY2FsbCAiZ2V0ZmQiLCBhbiBhbHRlcm5h
dGl2ZSBxbXBfc2VuZCBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgaW4KPj4gbGlieGwuCj4KPiBZb3Ug
Y291bGQgYWxzbyBoYXZlIGFkZGVkIG9wdGlvbmFsIG1zZ19jb250cm9se2xlbn0gcGFyYW1ldGVy
cyB0byB0aGUKPiBleGlzdGluZyBjb21tYW5kLiBJIGRvbid0IGtub3cgaWYgdGhhdCBpcyBiZXR0
ZXIgdGhvdWdoLgoKV2VsbCwgdGhpcyB3aWxsIGJlIGFuIGV4dHJhIHBhcmFtZXRlciB0aGF0IHdp
bGwgYmUgdXNlZCBpbiBvbmx5IG9uZQpjYXNlIChJIHRoaW5rKS4gQW5kIHRoaXMgcGFyYW1ldGVy
IHdpbGwgYmUgYSBiaXQgb2JzY3VyZS4gU28sIHByb2JhYmx5CmJvdGggYXJlIGdvb2QuIEFsc28s
IHRoZSBjb2RlIHRoYXQgcHJlcGFyZSB0aGUgbWVzc2FnZSAoc3RyaW5nKSB0byBiZQpzZW50IGlz
IGluIGEgc2VwYXJhdGUgZnVuY3Rpb24gbm93LCBzbyBib3RoIHFtcF9zZW5kIGFuZCBxbXBfc2Vu
ZF9mZApkbyBub3QgaGF2ZSBhbnl0aGluZyBpbiBjb21tb24gKGFsbW9zdCkuCgpUaGFua3MsCgot
LSAKQW50aG9ueSBQRVJBUkQKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:12:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:12:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTYAT-0003Si-1S; Thu, 24 Nov 2011 12:12:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTYAR-0003SS-Jn
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:12:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322136728!3996905!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32027 invoked from network); 24 Nov 2011 12:12:08 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 12:12:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTY9v-000Kn8-Mo; Thu, 24 Nov 2011 12:12:07 +0000
Date: Thu, 24 Nov 2011 12:12:07 +0000
From: Tim Deegan <tim@xen.org>
To: Steven <wangwangkang@gmail.com>
Message-ID: <20111124121207.GF77868@ocelot.phlegethon.org>
References: <CAMTrTqVYqJLmU-vhN=28Sv16_sdXO5V5SRQtbQCvnvb9QNNUWg@mail.gmail.com>
	<CAMTrTqVg9iAcfv+bL5=n0W+GDDbxH5ZPupa=_23FN6UnML7-zQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMTrTqVg9iAcfv+bL5=n0W+GDDbxH5ZPupa=_23FN6UnML7-zQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] what is the max number of page can be granted and
	mapped between two domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 12:40 PM, Steven <wangwangkang@gmail.com> wrote:
> Hi,
> I am trying to share some memory pages between a domU and dom0.
> The domU calls gnttab_grant_foreign_access(domid, mfn, 0); to grant the its
> pages for accessing by dom0, and then dom0 calls
>
> gnttab_set_map_op(... remoteDomain) and HYPERVISOR_grant_table_op(...)
> to map the pages from domU.
> Everying works fine when the number of granted page is < 533
> However, when the number of granted page is >= 533, dom0 can not map
> the granted pages.
> The function HYPERVISOR_grant_table_op returns error.
>
> My question is whether the max number of mapped page is 533. If it is
> how can I changed this limit. Or if there is any bettter way to
> sharing a large chunk of memory (about 20MB) page between two domains.

No, 533 is not the limit.  It's a rather odd point for things to stop
working, though. 

512 is the number of grant entries that fit into a single page; is your
domU setting up its grant tables properly to be the right size?

At 14:52 -0500 on 22 Nov (1321973551), Steven wrote:
> By the way, the error message from Xen by xm dmesg is
> 
> (XEN) grant_table.c:266:d0 Bad flags (0) or dom (0). (expected dom 0)

That probably means the grant-table entry wasn't set up in the right
place (if at all).  You'll need to add some tracing to your domU kernel
and to Xen to find out why Xen doesn't see the grant entry.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:12:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:12:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTYAT-0003Si-1S; Thu, 24 Nov 2011 12:12:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTYAR-0003SS-Jn
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:12:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322136728!3996905!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32027 invoked from network); 24 Nov 2011 12:12:08 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 12:12:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTY9v-000Kn8-Mo; Thu, 24 Nov 2011 12:12:07 +0000
Date: Thu, 24 Nov 2011 12:12:07 +0000
From: Tim Deegan <tim@xen.org>
To: Steven <wangwangkang@gmail.com>
Message-ID: <20111124121207.GF77868@ocelot.phlegethon.org>
References: <CAMTrTqVYqJLmU-vhN=28Sv16_sdXO5V5SRQtbQCvnvb9QNNUWg@mail.gmail.com>
	<CAMTrTqVg9iAcfv+bL5=n0W+GDDbxH5ZPupa=_23FN6UnML7-zQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMTrTqVg9iAcfv+bL5=n0W+GDDbxH5ZPupa=_23FN6UnML7-zQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] what is the max number of page can be granted and
	mapped between two domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 22, 2011 at 12:40 PM, Steven <wangwangkang@gmail.com> wrote:
> Hi,
> I am trying to share some memory pages between a domU and dom0.
> The domU calls gnttab_grant_foreign_access(domid, mfn, 0); to grant the its
> pages for accessing by dom0, and then dom0 calls
>
> gnttab_set_map_op(... remoteDomain) and HYPERVISOR_grant_table_op(...)
> to map the pages from domU.
> Everying works fine when the number of granted page is < 533
> However, when the number of granted page is >= 533, dom0 can not map
> the granted pages.
> The function HYPERVISOR_grant_table_op returns error.
>
> My question is whether the max number of mapped page is 533. If it is
> how can I changed this limit. Or if there is any bettter way to
> sharing a large chunk of memory (about 20MB) page between two domains.

No, 533 is not the limit.  It's a rather odd point for things to stop
working, though. 

512 is the number of grant entries that fit into a single page; is your
domU setting up its grant tables properly to be the right size?

At 14:52 -0500 on 22 Nov (1321973551), Steven wrote:
> By the way, the error message from Xen by xm dmesg is
> 
> (XEN) grant_table.c:266:d0 Bad flags (0) or dom (0). (expected dom 0)

That probably means the grant-table entry wasn't set up in the right
place (if at all).  You'll need to add some tracing to your domU kernel
and to Xen to find out why Xen doesn't see the grant entry.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:19:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTYGy-0003hw-9h; Thu, 24 Nov 2011 12:19:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTYGw-0003hn-S5
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:19:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322137131!5570041!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21183 invoked from network); 24 Nov 2011 12:18:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 12:18:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9110850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:18:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 12:18:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 24 Nov 2011 12:18:41 +0000
In-Reply-To: <CAJJyHjK2FQ-wbutCjOWZ5uJOyGJN=qvFp7C5f+ofDMZntjx69Q@mail.gmail.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
	<1322126555.9567.39.camel@dagon.hellion.org.uk>
	<CAJJyHjK2FQ-wbutCjOWZ5uJOyGJN=qvFp7C5f+ofDMZntjx69Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322137122.1005.183.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] Migration on QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 12:09 +0000, Anthony PERARD wrote:
[...]
> Mmh, not really, there is nothing to had in QEMU side. getfd and
> migrate are both QMP command. You can look in the file qmp-commands.hx
> in QEMU for the command migrate and getfd; and look in the file
> docs/migration.txt to know wich "Types of migration" QEMU use.

Oh, I didn't realise these were all existing qmp commands, I assumed a
patch adding them was forthcoming. You can ignore most of what I said
then...

> 
> The QEMU patch series I'm about to send is just a "fix" for the Xen case:
>  - do not save the RAM.
>  - at restore time, do not try to "allocate" (populate_physmap) memory
> that should already be allocated, and access to the right guest
> address in case this one have been "moved" (true for the VideoRAM)
> ("moved" using add_to_physmap).
> 
> >> In order to call "getfd", an alternative qmp_send have been implemented in
> >> libxl.
> >
> > You could also have added optional msg_control{len} parameters to the
> > existing command. I don't know if that is better though.
> 
> Well, this will be an extra parameter that will be used in only one
> case (I think). And this parameter will be a bit obscure. So, probably
> both are good. Also, the code that prepare the message (string) to be
> sent is in a separate function now, so both qmp_send and qmp_send_fd
> do not have anything in common (almost).
> 
> Thanks,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:19:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTYGy-0003hw-9h; Thu, 24 Nov 2011 12:19:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTYGw-0003hn-S5
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:19:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322137131!5570041!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21183 invoked from network); 24 Nov 2011 12:18:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 12:18:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9110850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:18:42 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 12:18:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 24 Nov 2011 12:18:41 +0000
In-Reply-To: <CAJJyHjK2FQ-wbutCjOWZ5uJOyGJN=qvFp7C5f+ofDMZntjx69Q@mail.gmail.com>
References: <1322070039-439-1-git-send-email-anthony.perard@citrix.com>
	<1322126555.9567.39.camel@dagon.hellion.org.uk>
	<CAJJyHjK2FQ-wbutCjOWZ5uJOyGJN=qvFp7C5f+ofDMZntjx69Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322137122.1005.183.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] Migration on QEMU upstream
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 12:09 +0000, Anthony PERARD wrote:
[...]
> Mmh, not really, there is nothing to had in QEMU side. getfd and
> migrate are both QMP command. You can look in the file qmp-commands.hx
> in QEMU for the command migrate and getfd; and look in the file
> docs/migration.txt to know wich "Types of migration" QEMU use.

Oh, I didn't realise these were all existing qmp commands, I assumed a
patch adding them was forthcoming. You can ignore most of what I said
then...

> 
> The QEMU patch series I'm about to send is just a "fix" for the Xen case:
>  - do not save the RAM.
>  - at restore time, do not try to "allocate" (populate_physmap) memory
> that should already be allocated, and access to the right guest
> address in case this one have been "moved" (true for the VideoRAM)
> ("moved" using add_to_physmap).
> 
> >> In order to call "getfd", an alternative qmp_send have been implemented in
> >> libxl.
> >
> > You could also have added optional msg_control{len} parameters to the
> > existing command. I don't know if that is better though.
> 
> Well, this will be an extra parameter that will be used in only one
> case (I think). And this parameter will be a bit obscure. So, probably
> both are good. Also, the code that prepare the message (string) to be
> sent is in a separate function now, so both qmp_send and qmp_send_fd
> do not have anything in common (almost).
> 
> Thanks,
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:20:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTYHZ-0003jr-NB; Thu, 24 Nov 2011 12:20:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTYHZ-0003jW-6I
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:20:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322137170!4730869!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32473 invoked from network); 24 Nov 2011 12:19:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 12:19:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9110870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:19:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 12:19:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Thu, 24 Nov 2011 12:19:29 +0000
In-Reply-To: <1d81d1c4c851c0b07696.1321617582@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<1d81d1c4c851c0b07696.1321617582@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322137170.1005.184.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I was just looking at this again because someone was talking about
hotplug issues on Linux and something new occurred to me.

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> [...]
> +++ b/tools/libxl/hotplug_linux.c       Fri Sep 30 14:38:55 2011 +0200
> [...]
> +int libxl_disk_hotplug(libxl__gc *gc, libxl__device *dev)
> [...]
> +int libxl_nic_hotplug_connect(libxl__gc *gc, libxl__device *dev)
> [...]
> +++ b/tools/libxl/hotplug_netbsd.c      Fri Sep 30 14:38:55 2011 +0200
> [...]
> +int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev)
> [...]
> +int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev)

Although Linux doesn't do hotplug this way now I think it will/should in
the future and the code will look very much like the netbsd one. So I
think that the code which actually handles calling the script should
probably be a generic function, only the selector on whether to do so
needs to be platform specific.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:20:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTYHZ-0003jr-NB; Thu, 24 Nov 2011 12:20:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTYHZ-0003jW-6I
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:20:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322137170!4730869!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32473 invoked from network); 24 Nov 2011 12:19:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 12:19:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9110870"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:19:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 12:19:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Thu, 24 Nov 2011 12:19:29 +0000
In-Reply-To: <1d81d1c4c851c0b07696.1321617582@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<1d81d1c4c851c0b07696.1321617582@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322137170.1005.184.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 6 of 9 v2] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I was just looking at this again because someone was talking about
hotplug issues on Linux and something new occurred to me.

On Fri, 2011-11-18 at 11:59 +0000, Roger Pau Monne wrote:
> [...]
> +++ b/tools/libxl/hotplug_linux.c       Fri Sep 30 14:38:55 2011 +0200
> [...]
> +int libxl_disk_hotplug(libxl__gc *gc, libxl__device *dev)
> [...]
> +int libxl_nic_hotplug_connect(libxl__gc *gc, libxl__device *dev)
> [...]
> +++ b/tools/libxl/hotplug_netbsd.c      Fri Sep 30 14:38:55 2011 +0200
> [...]
> +int libxl__disk_hotplug(libxl__gc *gc, libxl__device *dev)
> [...]
> +int libxl__nic_hotplug(libxl__gc *gc, libxl__device *dev)

Although Linux doesn't do hotplug this way now I think it will/should in
the future and the code will look very much like the netbsd one. So I
think that the code which actually handles calling the script should
probably be a generic function, only the selector on whether to do so
needs to be platform specific.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:29:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:29:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTYQa-000421-Q6; Thu, 24 Nov 2011 12:29:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RTYQZ-00041t-5U
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:29:19 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322137727!5548994!1
X-Originating-IP: [194.117.254.36]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15073 invoked from network); 24 Nov 2011 12:28:48 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2011 12:28:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:message-id; s=beta;
	bh=aio1XMluyWaGldqh/8b2TxBAQkaCpsknv4AgoZPgWWE=; b=Xt7syE6c4iLU
	mWe42bZ01q+Fi1BkXRHfJlrVoflPZbK+gAtHSKAH+Ni62UNzp4rIxwKejcd6MuRT
	baK9oSBogR7kn1zzNknajBqEhFLN0t6kVgtvWi7JDi8kXVDt9rx5hc/NVrp+L586
	7IYMVbu/cDo78DDbbvbtX8eXKRT6AOI=
Received: (qmail 10255 invoked from network); 24 Nov 2011 13:28:47 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.181.123)
	by mail.zeus06.de with ESMTPA; 24 Nov 2011 13:28:47 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 474932C515;
	Thu, 24 Nov 2011 13:28:47 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id cBD7dP+X-NBO; Thu, 24 Nov 2011 13:28:44 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id AF61A2C514;
	Thu, 24 Nov 2011 13:28:44 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Date: Thu, 24 Nov 2011 13:28:44 +0100
Mime-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
Cc: =?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5279143288043207915=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============5279143288043207915==
Content-Type: multipart/alternative; 
 boundary="=_YxzPBjBTzpUBlSYZQ4vSJPEqrKxiuQBmiORB-kDfPBPw5Qac"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_YxzPBjBTzpUBlSYZQ4vSJPEqrKxiuQBmiORB-kDfPBPw5Qac
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello again, I would like to come back to that thing...sorry that I did n=
ot have the time up to now.=0D=0A=0D=0A=C2=A0=0D=0AWe (now) speak about=0D=
=0A=0D=0A=C2=A0=0D=0A*=09Xen 4.1.2=0D=0A*=09Dom0 is Jeremy's 2.6.32.46 64=
 bit=0D=0A*=09DomU in question is now 3.1.2 64 bit=0D=0A*=09Same thing if=
 DomU is also 2.6.32.46=0D=0A*=09DomU owns two PCI cards (DVB-C) that o D=
MA=0D=0A*=09Machine has 8GB, Dom0 pinned at 512MB=0D=0A=0D=0A=C2=A0=0D=0A=
As compared to 2.6.34 Kernel with backported patches, the load on the Dom=
U is at least twice as high. It=0D=0A=0D=0Awill be "close to normal" if I=
 reduce the memory used to 4GB.=0D=0A=0D=0A=C2=A0=0D=0AAs you can see fro=
m the attachment, you once had an idea. So should we try to find somethin=
g...=3F=0D=0A=0D=0A=C2=A0=0D=0ACarsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=BC=
ngliche Nachricht-----=0D=0AAn:konrad.wilk <konrad.wilk@oracle.com>;=20=0D=
=0ACC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.=
com>;=20=0D=0AVon:Carsten Schiers <carsten@schiers.de>=0D=0AGesendet:Mi 2=
9.06.2011 23:17=0D=0ABetreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load=
 increase after memory upgrade=3F=0D=0A> Lets first do the c) experiment =
as that will likely explain your load average increase.=0D=0A...=0D=0A> >=
c). If you want to see if the fault here lies in the bounce buffer=20=0D=0A=
> being used more=0D=0A> >often in the DomU b/c you have 8GB of memory no=
w and you end up using=20=0D=0A> more pages=0D=0A> >past 4GB (in DomU), I=
 can cook up a patch to figure this out. But an=20=0D=0A> easier way is=0D=
=0A> >to just do (on the Xen hypervisor line): mem=3D4G and that will mak=
e=20=0D=0A> think you only have=0D=0A> >4GB of physical RAM. =C2=A0If the=
 load comes back to the normal "amount"=20=0D=0A> then the likely=0D=0A> =
>culprit is that and we can think on how to fix this.=0D=0A=0D=0AYou are =
on the right track. Load was going down to "normal" 10% when reducing=0D=0A=
Xen to 4GB by the parameter. Load seems to be still a little, little bit =
lower=0D=0Awith Xenified Kernel (8-9%), but this is drastically lower tha=
n the 20% we had=0D=0Abefore.=0D=0A
--=_YxzPBjBTzpUBlSYZQ4vSJPEqrKxiuQBmiORB-kDfPBPw5Qac
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>Load increase=
 after memory upgrade (part2)</title>=0A  <style type=3D"text/css">=0A   =
   body=0D=0A      {=0D=0A        font-family: Arial, Verdana, Sans-Serif=
 ! important;=0D=0A        font-size: 12px;=0D=0A        padding: 5px 5px=
 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-style: none;=0D=0A=
        background-color: #ffffff;=0D=0A      }=0D=0A=0D=0A      p, ul, l=
i=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A        margin-bottom: =
0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<p>Hello again, I =
would like to come back to that thing...sorry that I did not have the tim=
e up to now.</p><p>&nbsp;</p><p>We (now) speak about</p><p>&nbsp;</p><ul>=
<li>Xen 4.1.2</li><li>Dom0 is Jeremy&#39;s 2.6.32.46 64 bit</li><li>DomU =
in question is now 3.1.2 64 bit</li><li>Same thing if DomU is also 2.6.32=
=2E46</li><li>DomU owns two PCI cards (DVB-C) that o DMA</li><li>Machine =
has 8GB, Dom0 pinned at 512MB</li></ul><p>&nbsp;</p><p>As compared to 2.6=
=2E34 Kernel with backported patches, the load on the DomU is at least tw=
ice as high. It</p><p>will be &quot;close to normal&quot; if I reduce the=
 memory used to 4GB.</p><p>&nbsp;</p><p>As you can see from the attachmen=
t, you once had an idea. So should we try to find something...=3F</p><p>&=
nbsp;</p><p>Carsten.<br />&nbsp;</p><blockquote style=3D"border-left: 2px=
 solid #325FBA; padding-left: 5px;margin-left:5px;">-----Urspr&uuml;nglic=
he Nachricht-----<br /><strong>An:</strong>=09konrad.wilk &lt;konrad.wilk=
@oracle.com&gt;; <br /><strong>CC:</strong>=09linux &lt;linux@eikelenboom=
=2Eit&gt;; xen-devel &lt;xen-devel@lists.xensource.com&gt;; <br /><strong=
>Von:</strong>=09Carsten Schiers &lt;carsten@schiers.de&gt;<br /><strong>=
Gesendet:</strong>=09Mi 29.06.2011 23:17<br /><strong>Betreff:</strong>=09=
AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memory upgrad=
e=3F<br />&gt; Lets first do the c) experiment as that will likely explai=
n your load average increase.<br />...<br />&gt; &gt;c). If you want to s=
ee if the fault here lies in the bounce buffer <br />&gt; being used more=
<br />&gt; &gt;often in the DomU b/c you have 8GB of memory now and you e=
nd up using <br />&gt; more pages<br />&gt; &gt;past 4GB (in DomU), I can=
 cook up a patch to figure this out. But an <br />&gt; easier way is<br /=
>&gt; &gt;to just do (on the Xen hypervisor line): mem=3D4G and that will=
 make <br />&gt; think you only have<br />&gt; &gt;4GB of physical RAM. &=
nbsp;If the load comes back to the normal &quot;amount&quot; <br />&gt; t=
hen the likely<br />&gt; &gt;culprit is that and we can think on how to f=
ix this.<br /><br />You are on the right track. Load was going down to &q=
uot;normal&quot; 10% when reducing<br />Xen to 4GB by the parameter. Load=
 seems to be still a little, little bit lower<br />with Xenified Kernel (=
8-9%), but this is drastically lower than the 20% we had<br />before.<br =
/></blockquote>=0A</body>=0A</html>
--=_YxzPBjBTzpUBlSYZQ4vSJPEqrKxiuQBmiORB-kDfPBPw5Qac--



--===============5279143288043207915==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5279143288043207915==--



From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:29:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:29:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTYQa-000421-Q6; Thu, 24 Nov 2011 12:29:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RTYQZ-00041t-5U
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:29:19 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322137727!5548994!1
X-Originating-IP: [194.117.254.36]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15073 invoked from network); 24 Nov 2011 12:28:48 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2011 12:28:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:message-id; s=beta;
	bh=aio1XMluyWaGldqh/8b2TxBAQkaCpsknv4AgoZPgWWE=; b=Xt7syE6c4iLU
	mWe42bZ01q+Fi1BkXRHfJlrVoflPZbK+gAtHSKAH+Ni62UNzp4rIxwKejcd6MuRT
	baK9oSBogR7kn1zzNknajBqEhFLN0t6kVgtvWi7JDi8kXVDt9rx5hc/NVrp+L586
	7IYMVbu/cDo78DDbbvbtX8eXKRT6AOI=
Received: (qmail 10255 invoked from network); 24 Nov 2011 13:28:47 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.181.123)
	by mail.zeus06.de with ESMTPA; 24 Nov 2011 13:28:47 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 474932C515;
	Thu, 24 Nov 2011 13:28:47 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id cBD7dP+X-NBO; Thu, 24 Nov 2011 13:28:44 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id AF61A2C514;
	Thu, 24 Nov 2011 13:28:44 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Date: Thu, 24 Nov 2011 13:28:44 +0100
Mime-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
Cc: =?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5279143288043207915=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============5279143288043207915==
Content-Type: multipart/alternative; 
 boundary="=_YxzPBjBTzpUBlSYZQ4vSJPEqrKxiuQBmiORB-kDfPBPw5Qac"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_YxzPBjBTzpUBlSYZQ4vSJPEqrKxiuQBmiORB-kDfPBPw5Qac
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello again, I would like to come back to that thing...sorry that I did n=
ot have the time up to now.=0D=0A=0D=0A=C2=A0=0D=0AWe (now) speak about=0D=
=0A=0D=0A=C2=A0=0D=0A*=09Xen 4.1.2=0D=0A*=09Dom0 is Jeremy's 2.6.32.46 64=
 bit=0D=0A*=09DomU in question is now 3.1.2 64 bit=0D=0A*=09Same thing if=
 DomU is also 2.6.32.46=0D=0A*=09DomU owns two PCI cards (DVB-C) that o D=
MA=0D=0A*=09Machine has 8GB, Dom0 pinned at 512MB=0D=0A=0D=0A=C2=A0=0D=0A=
As compared to 2.6.34 Kernel with backported patches, the load on the Dom=
U is at least twice as high. It=0D=0A=0D=0Awill be "close to normal" if I=
 reduce the memory used to 4GB.=0D=0A=0D=0A=C2=A0=0D=0AAs you can see fro=
m the attachment, you once had an idea. So should we try to find somethin=
g...=3F=0D=0A=0D=0A=C2=A0=0D=0ACarsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=BC=
ngliche Nachricht-----=0D=0AAn:konrad.wilk <konrad.wilk@oracle.com>;=20=0D=
=0ACC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.=
com>;=20=0D=0AVon:Carsten Schiers <carsten@schiers.de>=0D=0AGesendet:Mi 2=
9.06.2011 23:17=0D=0ABetreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load=
 increase after memory upgrade=3F=0D=0A> Lets first do the c) experiment =
as that will likely explain your load average increase.=0D=0A...=0D=0A> >=
c). If you want to see if the fault here lies in the bounce buffer=20=0D=0A=
> being used more=0D=0A> >often in the DomU b/c you have 8GB of memory no=
w and you end up using=20=0D=0A> more pages=0D=0A> >past 4GB (in DomU), I=
 can cook up a patch to figure this out. But an=20=0D=0A> easier way is=0D=
=0A> >to just do (on the Xen hypervisor line): mem=3D4G and that will mak=
e=20=0D=0A> think you only have=0D=0A> >4GB of physical RAM. =C2=A0If the=
 load comes back to the normal "amount"=20=0D=0A> then the likely=0D=0A> =
>culprit is that and we can think on how to fix this.=0D=0A=0D=0AYou are =
on the right track. Load was going down to "normal" 10% when reducing=0D=0A=
Xen to 4GB by the parameter. Load seems to be still a little, little bit =
lower=0D=0Awith Xenified Kernel (8-9%), but this is drastically lower tha=
n the 20% we had=0D=0Abefore.=0D=0A
--=_YxzPBjBTzpUBlSYZQ4vSJPEqrKxiuQBmiORB-kDfPBPw5Qac
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>Load increase=
 after memory upgrade (part2)</title>=0A  <style type=3D"text/css">=0A   =
   body=0D=0A      {=0D=0A        font-family: Arial, Verdana, Sans-Serif=
 ! important;=0D=0A        font-size: 12px;=0D=0A        padding: 5px 5px=
 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-style: none;=0D=0A=
        background-color: #ffffff;=0D=0A      }=0D=0A=0D=0A      p, ul, l=
i=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A        margin-bottom: =
0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<p>Hello again, I =
would like to come back to that thing...sorry that I did not have the tim=
e up to now.</p><p>&nbsp;</p><p>We (now) speak about</p><p>&nbsp;</p><ul>=
<li>Xen 4.1.2</li><li>Dom0 is Jeremy&#39;s 2.6.32.46 64 bit</li><li>DomU =
in question is now 3.1.2 64 bit</li><li>Same thing if DomU is also 2.6.32=
=2E46</li><li>DomU owns two PCI cards (DVB-C) that o DMA</li><li>Machine =
has 8GB, Dom0 pinned at 512MB</li></ul><p>&nbsp;</p><p>As compared to 2.6=
=2E34 Kernel with backported patches, the load on the DomU is at least tw=
ice as high. It</p><p>will be &quot;close to normal&quot; if I reduce the=
 memory used to 4GB.</p><p>&nbsp;</p><p>As you can see from the attachmen=
t, you once had an idea. So should we try to find something...=3F</p><p>&=
nbsp;</p><p>Carsten.<br />&nbsp;</p><blockquote style=3D"border-left: 2px=
 solid #325FBA; padding-left: 5px;margin-left:5px;">-----Urspr&uuml;nglic=
he Nachricht-----<br /><strong>An:</strong>=09konrad.wilk &lt;konrad.wilk=
@oracle.com&gt;; <br /><strong>CC:</strong>=09linux &lt;linux@eikelenboom=
=2Eit&gt;; xen-devel &lt;xen-devel@lists.xensource.com&gt;; <br /><strong=
>Von:</strong>=09Carsten Schiers &lt;carsten@schiers.de&gt;<br /><strong>=
Gesendet:</strong>=09Mi 29.06.2011 23:17<br /><strong>Betreff:</strong>=09=
AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memory upgrad=
e=3F<br />&gt; Lets first do the c) experiment as that will likely explai=
n your load average increase.<br />...<br />&gt; &gt;c). If you want to s=
ee if the fault here lies in the bounce buffer <br />&gt; being used more=
<br />&gt; &gt;often in the DomU b/c you have 8GB of memory now and you e=
nd up using <br />&gt; more pages<br />&gt; &gt;past 4GB (in DomU), I can=
 cook up a patch to figure this out. But an <br />&gt; easier way is<br /=
>&gt; &gt;to just do (on the Xen hypervisor line): mem=3D4G and that will=
 make <br />&gt; think you only have<br />&gt; &gt;4GB of physical RAM. &=
nbsp;If the load comes back to the normal &quot;amount&quot; <br />&gt; t=
hen the likely<br />&gt; &gt;culprit is that and we can think on how to f=
ix this.<br /><br />You are on the right track. Load was going down to &q=
uot;normal&quot; 10% when reducing<br />Xen to 4GB by the parameter. Load=
 seems to be still a little, little bit lower<br />with Xenified Kernel (=
8-9%), but this is drastically lower than the 20% we had<br />before.<br =
/></blockquote>=0A</body>=0A</html>
--=_YxzPBjBTzpUBlSYZQ4vSJPEqrKxiuQBmiORB-kDfPBPw5Qac--



--===============5279143288043207915==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5279143288043207915==--



From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:54:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTYox-0004O3-2O; Thu, 24 Nov 2011 12:54:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTYov-0004Ny-IL
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:54:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322139237!5585177!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5549 invoked from network); 24 Nov 2011 12:53:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 12:53:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9111856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:53:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:53:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTYoO-0005Qr-Rf;
	Thu, 24 Nov 2011 12:53:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTYoO-0003Ik-OC;
	Thu, 24 Nov 2011 12:53:56 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10019-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 24 Nov 2011 12:53:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10019: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10019 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10019/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  b082fdc52ad7
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 301 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 12:54:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 12:54:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTYox-0004O3-2O; Thu, 24 Nov 2011 12:54:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTYov-0004Ny-IL
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 12:54:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322139237!5585177!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5549 invoked from network); 24 Nov 2011 12:53:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 12:53:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9111856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:53:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:53:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTYoO-0005Qr-Rf;
	Thu, 24 Nov 2011 12:53:56 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTYoO-0003Ik-OC;
	Thu, 24 Nov 2011 12:53:56 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10019-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 24 Nov 2011 12:53:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10019: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10019 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10019/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  b082fdc52ad7
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 301 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 13:41:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 13:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTZYH-00058x-BP; Thu, 24 Nov 2011 13:41:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTZYF-00058n-Ru
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 13:41:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322142048!2873844!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26677 invoked from network); 24 Nov 2011 13:40:48 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 13:40:48 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 9B84076C072;
	Thu, 24 Nov 2011 05:40:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=aUmGx1zf1Zxgm/zf3zE4PqP6qjQ/mn/YoBCStvi6Ofic
	eC5CFgOL5KBgAOco0Q6KgUffNi8MwswR5qsYmGNUOUXjBSD4IGRKW47aE22SsR5O
	RAEuGeyx7Qmp5bFKJK0kZN4RK7KB8wGvLKQMLNlj42fQL+lFgy/Ikwbdgh317Ng=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=mqZ5Mp9H5/bPbdar8VYpojHHP/A=; b=mC78rWKi
	SFPo6/hcvkFHagpY0wy5emFCW6diMsqfQ2oO23ZXuSOd+e/oF6G5SwDGdK0Yp2ZY
	PSlgngpDwG4caMlZrEAJpw/PrIVp4QErwfrMkqh3j43mCxKc2YmG92aqbVb3vgxq
	4gFZgqyB4vULjCLLfgJOtrNCJRnNiD52Isg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 4575476C06E; 
	Thu, 24 Nov 2011 05:40:47 -0800 (PST)
Received: from 69.196.190.226 (proxying for 69.196.190.226)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 05:40:47 -0800
Message-ID: <d3eaa517c6668255c04d1e8dd07385f2.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20174.11435.306730.583922@mariner.uk.xensource.com>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<20174.11435.306730.583922@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 05:40:47 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 00 of 14] MM Fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Not a problem on your side. smtp quota on my side. Resending the final
three separately.
Thanks
Andres
> Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 00 of 14] MM Fixes"):
>> This patch series includes a number of bug fixes, targetting
>> primarily the mm layer. Many of these fixes also lay groundwork
>> for future patches.
>
> Thanks.  Something seems to have eaten patches 12,13,14.
>
> Can you please confirm that you sent them, and tell me their
> messageids, and any information you can tell me about their
> transmission ?
>
> Ideally I would like log entries from the final hop mail server on
> your side showing the messages being handed over to the MX's for
> lists.xensource.com, but looking at the headers of your other messages
> they came through "homiemail-***.***.dreamhost.com" so that may
> involve talking to whoever they are.
>
> Thanks,
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 13:41:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 13:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTZYH-00058x-BP; Thu, 24 Nov 2011 13:41:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTZYF-00058n-Ru
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 13:41:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322142048!2873844!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26677 invoked from network); 24 Nov 2011 13:40:48 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.177) by server-10.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 13:40:48 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 9B84076C072;
	Thu, 24 Nov 2011 05:40:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=aUmGx1zf1Zxgm/zf3zE4PqP6qjQ/mn/YoBCStvi6Ofic
	eC5CFgOL5KBgAOco0Q6KgUffNi8MwswR5qsYmGNUOUXjBSD4IGRKW47aE22SsR5O
	RAEuGeyx7Qmp5bFKJK0kZN4RK7KB8wGvLKQMLNlj42fQL+lFgy/Ikwbdgh317Ng=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=mqZ5Mp9H5/bPbdar8VYpojHHP/A=; b=mC78rWKi
	SFPo6/hcvkFHagpY0wy5emFCW6diMsqfQ2oO23ZXuSOd+e/oF6G5SwDGdK0Yp2ZY
	PSlgngpDwG4caMlZrEAJpw/PrIVp4QErwfrMkqh3j43mCxKc2YmG92aqbVb3vgxq
	4gFZgqyB4vULjCLLfgJOtrNCJRnNiD52Isg=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 4575476C06E; 
	Thu, 24 Nov 2011 05:40:47 -0800 (PST)
Received: from 69.196.190.226 (proxying for 69.196.190.226)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 05:40:47 -0800
Message-ID: <d3eaa517c6668255c04d1e8dd07385f2.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20174.11435.306730.583922@mariner.uk.xensource.com>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<20174.11435.306730.583922@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 05:40:47 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 00 of 14] MM Fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Not a problem on your side. smtp quota on my side. Resending the final
three separately.
Thanks
Andres
> Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 00 of 14] MM Fixes"):
>> This patch series includes a number of bug fixes, targetting
>> primarily the mm layer. Many of these fixes also lay groundwork
>> for future patches.
>
> Thanks.  Something seems to have eaten patches 12,13,14.
>
> Can you please confirm that you sent them, and tell me their
> messageids, and any information you can tell me about their
> transmission ?
>
> Ideally I would like log entries from the final hop mail server on
> your side showing the messages being handed over to the MX's for
> lists.xensource.com, but looking at the headers of your other messages
> they came through "homiemail-***.***.dreamhost.com" so that may
> involve talking to whoever they are.
>
> Thanks,
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 13:48:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 13:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTZf4-0005TF-9u; Thu, 24 Nov 2011 13:48:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTZf2-0005Sa-9D
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 13:48:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322142468!4831257!1
X-Originating-IP: [208.97.132.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21442 invoked from network); 24 Nov 2011 13:47:48 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.81) by server-15.tower-216.messagelabs.com with SMTP;
	24 Nov 2011 13:47:48 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 1061B76C06E;
	Thu, 24 Nov 2011 05:47:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=L2ZURt4iV2Sv2Wj5EENAkV
	Xsy63wu8Hx5ijZVDIcFk5e4Z3bHkL/xShTk2jZUtD0wijzTFpddZrxc0p/aBBXKY
	chYIgC6+ZZE4Uf88EU92GS8upq+ZLit3O/7xpWpQeU2bymRcpSkNldfftOsI6vp+
	T3PRcLoKTvgWBfmHr0Ikw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=VlZ37+SnO8iE
	JK8Tg6cczLq6WuE=; b=aW8MqXGam3A2gwdl1zmV2bfmyupXBfcu8GNN4W5DVmUX
	1x4JW0snhJZfNsFoZOCCbyK1XM947vG8hYOXcWlmBQYbzDn0K6zzYhdlYLPB+CbU
	n7C6AAUqGQZeqedX9W+3N0htUNh5G5GqeqtrTMmSUyzEEUMteq6jqV+FSrDHv6k=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 47BAB76C065; 
	Thu, 24 Nov 2011 05:47:46 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322142090@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 08:41:30 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] MM fixes, part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Second haf of patch series submitted yesterday. These three patches contain
improvements to users of the get_gfn* interface. We ensure liveness of 
hypervisors mappings of guest pages in the face of paging, and remove a
few cases of recursive locking.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/hvm/hvm.c             |  69 ++++++++++++++++++++++++-------------
 xen/arch/x86/hvm/nestedhvm.c       |   4 +-
 xen/arch/x86/hvm/svm/nestedsvm.c   |  23 ++++++------
 xen/arch/x86/hvm/vmx/vvmx.c        |  36 +++++++++++--------
 xen/include/asm-x86/hvm/hvm.h      |   9 +++-
 xen/include/asm-x86/hvm/vcpu.h     |   1 +
 xen/include/asm-x86/hvm/vmx/vvmx.h |   1 +
 xen/arch/x86/mm/guest_walk.c       |  16 ++++++--
 xen/common/grant_table.c           |  69 ++++++++++++++++++++-----------------
 9 files changed, 136 insertions(+), 92 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 13:48:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 13:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTZf4-0005TF-9u; Thu, 24 Nov 2011 13:48:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTZf2-0005Sa-9D
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 13:48:20 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322142468!4831257!1
X-Originating-IP: [208.97.132.81]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21442 invoked from network); 24 Nov 2011 13:47:48 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.81) by server-15.tower-216.messagelabs.com with SMTP;
	24 Nov 2011 13:47:48 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 1061B76C06E;
	Thu, 24 Nov 2011 05:47:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=L2ZURt4iV2Sv2Wj5EENAkV
	Xsy63wu8Hx5ijZVDIcFk5e4Z3bHkL/xShTk2jZUtD0wijzTFpddZrxc0p/aBBXKY
	chYIgC6+ZZE4Uf88EU92GS8upq+ZLit3O/7xpWpQeU2bymRcpSkNldfftOsI6vp+
	T3PRcLoKTvgWBfmHr0Ikw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=VlZ37+SnO8iE
	JK8Tg6cczLq6WuE=; b=aW8MqXGam3A2gwdl1zmV2bfmyupXBfcu8GNN4W5DVmUX
	1x4JW0snhJZfNsFoZOCCbyK1XM947vG8hYOXcWlmBQYbzDn0K6zzYhdlYLPB+CbU
	n7C6AAUqGQZeqedX9W+3N0htUNh5G5GqeqtrTMmSUyzEEUMteq6jqV+FSrDHv6k=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 47BAB76C065; 
	Thu, 24 Nov 2011 05:47:46 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322142090@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 08:41:30 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 3] MM fixes, part 2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Second haf of patch series submitted yesterday. These three patches contain
improvements to users of the get_gfn* interface. We ensure liveness of 
hypervisors mappings of guest pages in the face of paging, and remove a
few cases of recursive locking.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/hvm/hvm.c             |  69 ++++++++++++++++++++++++-------------
 xen/arch/x86/hvm/nestedhvm.c       |   4 +-
 xen/arch/x86/hvm/svm/nestedsvm.c   |  23 ++++++------
 xen/arch/x86/hvm/vmx/vvmx.c        |  36 +++++++++++--------
 xen/include/asm-x86/hvm/hvm.h      |   9 +++-
 xen/include/asm-x86/hvm/vcpu.h     |   1 +
 xen/include/asm-x86/hvm/vmx/vvmx.h |   1 +
 xen/arch/x86/mm/guest_walk.c       |  16 ++++++--
 xen/common/grant_table.c           |  69 ++++++++++++++++++++-----------------
 9 files changed, 136 insertions(+), 92 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 13:48:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 13:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTZf2-0005T6-MD; Thu, 24 Nov 2011 13:48:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTZf1-0005Se-JU
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 13:48:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322142426!58121624!1
X-Originating-IP: [208.97.132.74]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16143 invoked from network); 24 Nov 2011 13:47:06 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-27.messagelabs.com with SMTP;
	24 Nov 2011 13:47:06 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 6399176C06E;
	Thu, 24 Nov 2011 05:47:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=WsopyjACrdeoOCkgQ9XGu3WF3TtKqBYGiCU9JE9GFMz6
	G9QquZIBDmqX+o8ha6pYyaK+D59pVz58Idbes9Hsjt1zHj/IBxpukZJK36wqLEcy
	HRFH6ncV2ZvtrCpuGrZtb2C2KxcEscXHq1x33uKBCspN5cAJ+Mrl237YtDvV1LE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=X/nYXL7iutJYGI40S8LMQXIeDMw=; b=cM5az1Zwl/H
	XBONoPPZuD6FojLD6gID1EwpNa3UpQB7ccuZDw37vFO7E0X513Bs0HBxFLO/rB1s
	uiuMmm5k7PJujBF0b7AvOz/1sfqbAHcn8LMjUzUc7vdTGAnLDisBXpCJayDmkK08
	TPyTGiZOVpKMYNlZkBkXybYuF8iG09ec=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id BFA1476C065; 
	Thu, 24 Nov 2011 05:47:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b0410cb27d17a470005e7aafc35e86028f4f817b
Message-Id: <b0410cb27d17a470005e.1322142092@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322142090@xdev.gridcentric.ca>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 08:41:32 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] Ensure liveness of pages involved in a
 guest page table walk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/guest_walk.c |  16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)


Instead of risking deadlock by holding onto the gfn's acquired during
a guest page table walk, acquire an extra reference within the get_gfn/
put_gfn critical section, and drop the extra reference when done with
the map. This ensures liveness of the map, i.e. the underlying page
won't be paged out.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f079cbeae77e -r b0410cb27d17 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -87,7 +87,7 @@ static uint32_t set_ad_bits(void *guest_
 }
 
 /* If the map is non-NULL, we leave this function having 
- * called get_gfn, you need to call put_gfn. */
+ * acquired an extra ref on mfn_to_page(*mfn) */
 static inline void *map_domain_gfn(struct p2m_domain *p2m,
                                    gfn_t gfn, 
                                    mfn_t *mfn,
@@ -95,6 +95,7 @@ static inline void *map_domain_gfn(struc
                                    uint32_t *rc) 
 {
     p2m_access_t p2ma;
+    void *map;
 
     /* Translate the gfn, unsharing if shared */
     *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, p2m_unshare, NULL);
@@ -120,7 +121,12 @@ static inline void *map_domain_gfn(struc
     }
     ASSERT(mfn_valid(mfn_x(*mfn)));
     
-    return map_domain_page(mfn_x(*mfn));
+    /* Get an extra ref to the page to ensure liveness of the map.
+     * Then we can safely put gfn */
+    page_get_owner_and_reference(mfn_to_page(mfn_x(*mfn)));
+    map = map_domain_page(mfn_x(*mfn));
+    __put_gfn(p2m, gfn_x(gfn));
+    return map;
 }
 
 
@@ -357,20 +363,20 @@ set_ad:
     if ( l3p ) 
     {
         unmap_domain_page(l3p);
-        __put_gfn(p2m, gfn_x(guest_l4e_get_gfn(gw->l4e)));
+        put_page(mfn_to_page(mfn_x(gw->l3mfn)));
     }
 #endif
 #if GUEST_PAGING_LEVELS >= 3
     if ( l2p ) 
     {
         unmap_domain_page(l2p);
-        __put_gfn(p2m, gfn_x(guest_l3e_get_gfn(gw->l3e))); 
+        put_page(mfn_to_page(mfn_x(gw->l2mfn)));
     }
 #endif
     if ( l1p ) 
     {
         unmap_domain_page(l1p);
-        __put_gfn(p2m, gfn_x(guest_l2e_get_gfn(gw->l2e)));
+        put_page(mfn_to_page(mfn_x(gw->l1mfn)));
     }
 
     return rc;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 13:48:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 13:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTZf2-0005T6-MD; Thu, 24 Nov 2011 13:48:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTZf1-0005Se-JU
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 13:48:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322142426!58121624!1
X-Originating-IP: [208.97.132.74]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16143 invoked from network); 24 Nov 2011 13:47:06 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-27.messagelabs.com with SMTP;
	24 Nov 2011 13:47:06 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 6399176C06E;
	Thu, 24 Nov 2011 05:47:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=WsopyjACrdeoOCkgQ9XGu3WF3TtKqBYGiCU9JE9GFMz6
	G9QquZIBDmqX+o8ha6pYyaK+D59pVz58Idbes9Hsjt1zHj/IBxpukZJK36wqLEcy
	HRFH6ncV2ZvtrCpuGrZtb2C2KxcEscXHq1x33uKBCspN5cAJ+Mrl237YtDvV1LE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=X/nYXL7iutJYGI40S8LMQXIeDMw=; b=cM5az1Zwl/H
	XBONoPPZuD6FojLD6gID1EwpNa3UpQB7ccuZDw37vFO7E0X513Bs0HBxFLO/rB1s
	uiuMmm5k7PJujBF0b7AvOz/1sfqbAHcn8LMjUzUc7vdTGAnLDisBXpCJayDmkK08
	TPyTGiZOVpKMYNlZkBkXybYuF8iG09ec=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id BFA1476C065; 
	Thu, 24 Nov 2011 05:47:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b0410cb27d17a470005e7aafc35e86028f4f817b
Message-Id: <b0410cb27d17a470005e.1322142092@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322142090@xdev.gridcentric.ca>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 08:41:32 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 3] Ensure liveness of pages involved in a
 guest page table walk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/guest_walk.c |  16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)


Instead of risking deadlock by holding onto the gfn's acquired during
a guest page table walk, acquire an extra reference within the get_gfn/
put_gfn critical section, and drop the extra reference when done with
the map. This ensures liveness of the map, i.e. the underlying page
won't be paged out.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f079cbeae77e -r b0410cb27d17 xen/arch/x86/mm/guest_walk.c
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -87,7 +87,7 @@ static uint32_t set_ad_bits(void *guest_
 }
 
 /* If the map is non-NULL, we leave this function having 
- * called get_gfn, you need to call put_gfn. */
+ * acquired an extra ref on mfn_to_page(*mfn) */
 static inline void *map_domain_gfn(struct p2m_domain *p2m,
                                    gfn_t gfn, 
                                    mfn_t *mfn,
@@ -95,6 +95,7 @@ static inline void *map_domain_gfn(struc
                                    uint32_t *rc) 
 {
     p2m_access_t p2ma;
+    void *map;
 
     /* Translate the gfn, unsharing if shared */
     *mfn = get_gfn_type_access(p2m, gfn_x(gfn), p2mt, &p2ma, p2m_unshare, NULL);
@@ -120,7 +121,12 @@ static inline void *map_domain_gfn(struc
     }
     ASSERT(mfn_valid(mfn_x(*mfn)));
     
-    return map_domain_page(mfn_x(*mfn));
+    /* Get an extra ref to the page to ensure liveness of the map.
+     * Then we can safely put gfn */
+    page_get_owner_and_reference(mfn_to_page(mfn_x(*mfn)));
+    map = map_domain_page(mfn_x(*mfn));
+    __put_gfn(p2m, gfn_x(gfn));
+    return map;
 }
 
 
@@ -357,20 +363,20 @@ set_ad:
     if ( l3p ) 
     {
         unmap_domain_page(l3p);
-        __put_gfn(p2m, gfn_x(guest_l4e_get_gfn(gw->l4e)));
+        put_page(mfn_to_page(mfn_x(gw->l3mfn)));
     }
 #endif
 #if GUEST_PAGING_LEVELS >= 3
     if ( l2p ) 
     {
         unmap_domain_page(l2p);
-        __put_gfn(p2m, gfn_x(guest_l3e_get_gfn(gw->l3e))); 
+        put_page(mfn_to_page(mfn_x(gw->l2mfn)));
     }
 #endif
     if ( l1p ) 
     {
         unmap_domain_page(l1p);
-        __put_gfn(p2m, gfn_x(guest_l2e_get_gfn(gw->l2e)));
+        put_page(mfn_to_page(mfn_x(gw->l1mfn)));
     }
 
     return rc;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 13:48:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 13:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTZf6-0005Tt-TY; Thu, 24 Nov 2011 13:48:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTZf5-0005Sj-Ue
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 13:48:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322142471!2877691!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15667 invoked from network); 24 Nov 2011 13:47:52 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 13:47:52 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 50D9C76C073;
	Thu, 24 Nov 2011 05:47:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=WhnXxOXH/4DAT3jY9rnsAAwxldV7xAK/EjG8XkU9DwQd
	yNHsFthpyqcJGHmne2z3j6mODmlU/Xtl7DZsVTZASEWLE5Ln8BGjqfm1SYd+uhmy
	PWwSPpSwen5aaLIvWiZgStxlkUSWJbcj1kA6w8m3Srk7eojTy5q/9R1qUbmFOiM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=LRIwRPvd98UBSSC3eWU0hee2pj8=; b=oWOcZP3LgW3
	1SUUUbscXfY8UCLLGqfW941u2P8dQEybcPGQwsUQX6LOQskdkQ20KUjQDl6ZkuQT
	hbVWmQNcPb5ZDzCHQ3MxJGkNn59leWSXnEfde9yoFmGmacAtPpAjczsTD3MHQVPQ
	xRMp0I06WJfUvvyCPCbsBISRiyEahn3g=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 94C6D76C065; 
	Thu, 24 Nov 2011 05:47:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9e44fd6e495518af3ac230bb4573783c6feea8b6
Message-Id: <9e44fd6e495518af3ac2.1322142093@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322142090@xdev.gridcentric.ca>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 08:41:33 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] Fix liveness of pages in grant copy
	operations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/grant_table.c |  69 +++++++++++++++++++++++++----------------------
 1 files changed, 37 insertions(+), 32 deletions(-)


We were immediately putting the p2m entry translation for grant
copy operations. This allowed for an unnecessary race by which the
page could have been swapped out between the p2m lookup and the actual
use. Hold on to the p2m entries until the grant operation finishes.

Also fixes a small bug: for the source page of the copy, get_page
was assuming the page was owned by the source domain. It may be a
shared page, since we don't perform an unsharing p2m lookup.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b0410cb27d17 -r 9e44fd6e4955 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1723,11 +1723,12 @@ static void __fixup_status_for_pin(struc
 /* Grab a frame number from a grant entry and update the flags and pin
    count as appropriate.  Note that this does *not* update the page
    type or reference counts, and does not check that the mfn is
-   actually valid. */
+   actually valid. If *gfn != INVALID_GFN, and rc == GNTST_okay, then
+   we leave this function holding the p2m entry for *gfn in *owning_domain */
 static int
 __acquire_grant_for_copy(
     struct domain *rd, unsigned long gref, struct domain *ld, int readonly,
-    unsigned long *frame, unsigned *page_off, unsigned *length,
+    unsigned long *frame, unsigned long *gfn, unsigned *page_off, unsigned *length,
     unsigned allow_transitive, struct domain **owning_domain)
 {
     grant_entry_v1_t *sha1;
@@ -1739,7 +1740,6 @@ __acquire_grant_for_copy(
     domid_t trans_domid;
     grant_ref_t trans_gref;
     struct domain *td;
-    unsigned long gfn;
     unsigned long grant_frame;
     unsigned trans_page_off;
     unsigned trans_length;
@@ -1748,6 +1748,7 @@ __acquire_grant_for_copy(
     s16 rc = GNTST_okay;
 
     *owning_domain = NULL;
+    *gfn = INVALID_GFN;
 
     spin_lock(&rd->grant_table->lock);
 
@@ -1824,7 +1825,7 @@ __acquire_grant_for_copy(
             spin_unlock(&rd->grant_table->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd,
-                                          readonly, &grant_frame,
+                                          readonly, &grant_frame, gfn,
                                           &trans_page_off, &trans_length,
                                           0, &ignore);
 
@@ -1846,7 +1847,7 @@ __acquire_grant_for_copy(
 	        rcu_unlock_domain(td);
                 spin_unlock(&rd->grant_table->lock);
                 return __acquire_grant_for_copy(rd, gref, ld, readonly,
-                                                frame, page_off, length,
+                                                frame, gfn, page_off, length,
                                                 allow_transitive,
                                                 owning_domain);
             }
@@ -1860,13 +1861,11 @@ __acquire_grant_for_copy(
         }
         else if ( sha1 )
         {
-            gfn = sha1->frame;
-            rc = __get_paged_frame(gfn, &grant_frame, readonly, rd);
-            /* We drop this immediately per the comments at the top */
-            put_gfn(rd, gfn);
+            *gfn = sha1->frame;
+            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = gfn;
+            act->gfn = *gfn;
             is_sub_page = 0;
             trans_page_off = 0;
             trans_length = PAGE_SIZE;
@@ -1874,12 +1873,11 @@ __acquire_grant_for_copy(
         }
         else if ( !(sha2->hdr.flags & GTF_sub_page) )
         {
-            gfn = sha2->full_page.frame;
-            rc = __get_paged_frame(gfn, &grant_frame, readonly, rd);
-            put_gfn(rd, gfn);
+            *gfn = sha2->full_page.frame;
+            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = gfn;
+            act->gfn = *gfn;
             is_sub_page = 0;
             trans_page_off = 0;
             trans_length = PAGE_SIZE;
@@ -1887,12 +1885,11 @@ __acquire_grant_for_copy(
         }
         else
         {
-            gfn = sha2->sub_page.frame;
-            rc = __get_paged_frame(gfn, &grant_frame, readonly, rd);
-            put_gfn(rd, gfn);
+            *gfn = sha2->sub_page.frame;
+            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = gfn;
+            act->gfn = *gfn;
             is_sub_page = 1;
             trans_page_off = sha2->sub_page.page_off;
             trans_length = sha2->sub_page.length;
@@ -1932,7 +1929,7 @@ __gnttab_copy(
 {
     struct domain *sd = NULL, *dd = NULL;
     struct domain *source_domain = NULL, *dest_domain = NULL;
-    unsigned long s_frame, d_frame;
+    unsigned long s_frame, d_frame, s_gfn = INVALID_GFN, d_gfn = INVALID_GFN;
     char *sp, *dp;
     s16 rc = GNTST_okay;
     int have_d_grant = 0, have_s_grant = 0, have_s_ref = 0;
@@ -1973,14 +1970,14 @@ __gnttab_copy(
     {
         unsigned source_off, source_len;
         rc = __acquire_grant_for_copy(sd, op->source.u.ref, current->domain, 1,
-                                      &s_frame, &source_off, &source_len, 1,
+                                      &s_frame, &s_gfn, &source_off, &source_len, 1,
                                       &source_domain);
         if ( rc != GNTST_okay )
             goto error_out;
         have_s_grant = 1;
         if ( op->source.offset < source_off ||
              op->len > source_len )
-            PIN_FAIL(error_out, GNTST_general_error,
+            PIN_FAIL(error_put_s_gfn, GNTST_general_error,
                      "copy source out of bounds: %d < %d || %d > %d\n",
                      op->source.offset, source_off,
                      op->len, source_len);
@@ -1988,8 +1985,8 @@ __gnttab_copy(
     else
     {
 #ifdef CONFIG_X86
+        s_gfn = op->source.u.gmfn;
         rc = __get_paged_frame(op->source.u.gmfn, &s_frame, 1, sd);
-        put_gfn(sd, op->source.u.gmfn);
         if ( rc != GNTST_okay )
             goto error_out;
 #else
@@ -1998,14 +1995,16 @@ __gnttab_copy(
         source_domain = sd;
     }
     if ( unlikely(!mfn_valid(s_frame)) )
-        PIN_FAIL(error_out, GNTST_general_error,
+        PIN_FAIL(error_put_s_gfn, GNTST_general_error,
                  "source frame %lx invalid.\n", s_frame);
-    if ( !get_page(mfn_to_page(s_frame), source_domain) )
+    /* For the source frame, the page could still be shared, so
+     * don't assume ownership by source_domain */
+    if ( !page_get_owner_and_reference(mfn_to_page(s_frame)) )
     {
         if ( !sd->is_dying )
             gdprintk(XENLOG_WARNING, "Could not get src frame %lx\n", s_frame);
         rc = GNTST_general_error;
-        goto error_out;
+        goto error_put_s_gfn;
     }
     have_s_ref = 1;
 
@@ -2013,14 +2012,14 @@ __gnttab_copy(
     {
         unsigned dest_off, dest_len;
         rc = __acquire_grant_for_copy(dd, op->dest.u.ref, current->domain, 0,
-                                      &d_frame, &dest_off, &dest_len, 1,
+                                      &d_frame, &d_gfn, &dest_off, &dest_len, 1,
                                       &dest_domain);
         if ( rc != GNTST_okay )
-            goto error_out;
+            goto error_put_s_gfn;
         have_d_grant = 1;
         if ( op->dest.offset < dest_off ||
              op->len > dest_len )
-            PIN_FAIL(error_out, GNTST_general_error,
+            PIN_FAIL(error_put_d_gfn, GNTST_general_error,
                      "copy dest out of bounds: %d < %d || %d > %d\n",
                      op->dest.offset, dest_off,
                      op->len, dest_len);
@@ -2028,17 +2027,17 @@ __gnttab_copy(
     else
     {
 #ifdef CONFIG_X86
+        d_gfn = op->dest.u.gmfn;
         rc = __get_paged_frame(op->dest.u.gmfn, &d_frame, 0, dd);
-        put_gfn(dd, op->dest.u.gmfn);
         if ( rc != GNTST_okay )
-            goto error_out;
+            goto error_put_s_gfn;
 #else
         d_frame = gmfn_to_mfn(dd, op->dest.u.gmfn);
 #endif
         dest_domain = dd;
     }
     if ( unlikely(!mfn_valid(d_frame)) )
-        PIN_FAIL(error_out, GNTST_general_error,
+        PIN_FAIL(error_put_d_gfn, GNTST_general_error,
                  "destination frame %lx invalid.\n", d_frame);
     if ( !get_page_and_type(mfn_to_page(d_frame), dest_domain,
                             PGT_writable_page) )
@@ -2046,7 +2045,7 @@ __gnttab_copy(
         if ( !dd->is_dying )
             gdprintk(XENLOG_WARNING, "Could not get dst frame %lx\n", d_frame);
         rc = GNTST_general_error;
-        goto error_out;
+        goto error_put_d_gfn;
     }
 
     sp = map_domain_page(s_frame);
@@ -2060,6 +2059,12 @@ __gnttab_copy(
     gnttab_mark_dirty(dd, d_frame);
 
     put_page_and_type(mfn_to_page(d_frame));
+ error_put_d_gfn:
+    if ( (d_gfn != INVALID_GFN) && (dest_domain) )
+        put_gfn(dest_domain, d_gfn);
+ error_put_s_gfn:
+    if ( (s_gfn != INVALID_GFN) && (source_domain) )
+        put_gfn(source_domain, s_gfn);
  error_out:
     if ( have_s_ref )
         put_page(mfn_to_page(s_frame));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 13:48:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 13:48:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTZf6-0005Tt-TY; Thu, 24 Nov 2011 13:48:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTZf5-0005Sj-Ue
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 13:48:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322142471!2877691!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15667 invoked from network); 24 Nov 2011 13:47:52 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 13:47:52 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 50D9C76C073;
	Thu, 24 Nov 2011 05:47:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=WhnXxOXH/4DAT3jY9rnsAAwxldV7xAK/EjG8XkU9DwQd
	yNHsFthpyqcJGHmne2z3j6mODmlU/Xtl7DZsVTZASEWLE5Ln8BGjqfm1SYd+uhmy
	PWwSPpSwen5aaLIvWiZgStxlkUSWJbcj1kA6w8m3Srk7eojTy5q/9R1qUbmFOiM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=LRIwRPvd98UBSSC3eWU0hee2pj8=; b=oWOcZP3LgW3
	1SUUUbscXfY8UCLLGqfW941u2P8dQEybcPGQwsUQX6LOQskdkQ20KUjQDl6ZkuQT
	hbVWmQNcPb5ZDzCHQ3MxJGkNn59leWSXnEfde9yoFmGmacAtPpAjczsTD3MHQVPQ
	xRMp0I06WJfUvvyCPCbsBISRiyEahn3g=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 94C6D76C065; 
	Thu, 24 Nov 2011 05:47:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9e44fd6e495518af3ac230bb4573783c6feea8b6
Message-Id: <9e44fd6e495518af3ac2.1322142093@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322142090@xdev.gridcentric.ca>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 08:41:33 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 3] Fix liveness of pages in grant copy
	operations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/grant_table.c |  69 +++++++++++++++++++++++++----------------------
 1 files changed, 37 insertions(+), 32 deletions(-)


We were immediately putting the p2m entry translation for grant
copy operations. This allowed for an unnecessary race by which the
page could have been swapped out between the p2m lookup and the actual
use. Hold on to the p2m entries until the grant operation finishes.

Also fixes a small bug: for the source page of the copy, get_page
was assuming the page was owned by the source domain. It may be a
shared page, since we don't perform an unsharing p2m lookup.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b0410cb27d17 -r 9e44fd6e4955 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1723,11 +1723,12 @@ static void __fixup_status_for_pin(struc
 /* Grab a frame number from a grant entry and update the flags and pin
    count as appropriate.  Note that this does *not* update the page
    type or reference counts, and does not check that the mfn is
-   actually valid. */
+   actually valid. If *gfn != INVALID_GFN, and rc == GNTST_okay, then
+   we leave this function holding the p2m entry for *gfn in *owning_domain */
 static int
 __acquire_grant_for_copy(
     struct domain *rd, unsigned long gref, struct domain *ld, int readonly,
-    unsigned long *frame, unsigned *page_off, unsigned *length,
+    unsigned long *frame, unsigned long *gfn, unsigned *page_off, unsigned *length,
     unsigned allow_transitive, struct domain **owning_domain)
 {
     grant_entry_v1_t *sha1;
@@ -1739,7 +1740,6 @@ __acquire_grant_for_copy(
     domid_t trans_domid;
     grant_ref_t trans_gref;
     struct domain *td;
-    unsigned long gfn;
     unsigned long grant_frame;
     unsigned trans_page_off;
     unsigned trans_length;
@@ -1748,6 +1748,7 @@ __acquire_grant_for_copy(
     s16 rc = GNTST_okay;
 
     *owning_domain = NULL;
+    *gfn = INVALID_GFN;
 
     spin_lock(&rd->grant_table->lock);
 
@@ -1824,7 +1825,7 @@ __acquire_grant_for_copy(
             spin_unlock(&rd->grant_table->lock);
 
             rc = __acquire_grant_for_copy(td, trans_gref, rd,
-                                          readonly, &grant_frame,
+                                          readonly, &grant_frame, gfn,
                                           &trans_page_off, &trans_length,
                                           0, &ignore);
 
@@ -1846,7 +1847,7 @@ __acquire_grant_for_copy(
 	        rcu_unlock_domain(td);
                 spin_unlock(&rd->grant_table->lock);
                 return __acquire_grant_for_copy(rd, gref, ld, readonly,
-                                                frame, page_off, length,
+                                                frame, gfn, page_off, length,
                                                 allow_transitive,
                                                 owning_domain);
             }
@@ -1860,13 +1861,11 @@ __acquire_grant_for_copy(
         }
         else if ( sha1 )
         {
-            gfn = sha1->frame;
-            rc = __get_paged_frame(gfn, &grant_frame, readonly, rd);
-            /* We drop this immediately per the comments at the top */
-            put_gfn(rd, gfn);
+            *gfn = sha1->frame;
+            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = gfn;
+            act->gfn = *gfn;
             is_sub_page = 0;
             trans_page_off = 0;
             trans_length = PAGE_SIZE;
@@ -1874,12 +1873,11 @@ __acquire_grant_for_copy(
         }
         else if ( !(sha2->hdr.flags & GTF_sub_page) )
         {
-            gfn = sha2->full_page.frame;
-            rc = __get_paged_frame(gfn, &grant_frame, readonly, rd);
-            put_gfn(rd, gfn);
+            *gfn = sha2->full_page.frame;
+            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = gfn;
+            act->gfn = *gfn;
             is_sub_page = 0;
             trans_page_off = 0;
             trans_length = PAGE_SIZE;
@@ -1887,12 +1885,11 @@ __acquire_grant_for_copy(
         }
         else
         {
-            gfn = sha2->sub_page.frame;
-            rc = __get_paged_frame(gfn, &grant_frame, readonly, rd);
-            put_gfn(rd, gfn);
+            *gfn = sha2->sub_page.frame;
+            rc = __get_paged_frame(*gfn, &grant_frame, readonly, rd);
             if ( rc != GNTST_okay )
                 goto unlock_out;
-            act->gfn = gfn;
+            act->gfn = *gfn;
             is_sub_page = 1;
             trans_page_off = sha2->sub_page.page_off;
             trans_length = sha2->sub_page.length;
@@ -1932,7 +1929,7 @@ __gnttab_copy(
 {
     struct domain *sd = NULL, *dd = NULL;
     struct domain *source_domain = NULL, *dest_domain = NULL;
-    unsigned long s_frame, d_frame;
+    unsigned long s_frame, d_frame, s_gfn = INVALID_GFN, d_gfn = INVALID_GFN;
     char *sp, *dp;
     s16 rc = GNTST_okay;
     int have_d_grant = 0, have_s_grant = 0, have_s_ref = 0;
@@ -1973,14 +1970,14 @@ __gnttab_copy(
     {
         unsigned source_off, source_len;
         rc = __acquire_grant_for_copy(sd, op->source.u.ref, current->domain, 1,
-                                      &s_frame, &source_off, &source_len, 1,
+                                      &s_frame, &s_gfn, &source_off, &source_len, 1,
                                       &source_domain);
         if ( rc != GNTST_okay )
             goto error_out;
         have_s_grant = 1;
         if ( op->source.offset < source_off ||
              op->len > source_len )
-            PIN_FAIL(error_out, GNTST_general_error,
+            PIN_FAIL(error_put_s_gfn, GNTST_general_error,
                      "copy source out of bounds: %d < %d || %d > %d\n",
                      op->source.offset, source_off,
                      op->len, source_len);
@@ -1988,8 +1985,8 @@ __gnttab_copy(
     else
     {
 #ifdef CONFIG_X86
+        s_gfn = op->source.u.gmfn;
         rc = __get_paged_frame(op->source.u.gmfn, &s_frame, 1, sd);
-        put_gfn(sd, op->source.u.gmfn);
         if ( rc != GNTST_okay )
             goto error_out;
 #else
@@ -1998,14 +1995,16 @@ __gnttab_copy(
         source_domain = sd;
     }
     if ( unlikely(!mfn_valid(s_frame)) )
-        PIN_FAIL(error_out, GNTST_general_error,
+        PIN_FAIL(error_put_s_gfn, GNTST_general_error,
                  "source frame %lx invalid.\n", s_frame);
-    if ( !get_page(mfn_to_page(s_frame), source_domain) )
+    /* For the source frame, the page could still be shared, so
+     * don't assume ownership by source_domain */
+    if ( !page_get_owner_and_reference(mfn_to_page(s_frame)) )
     {
         if ( !sd->is_dying )
             gdprintk(XENLOG_WARNING, "Could not get src frame %lx\n", s_frame);
         rc = GNTST_general_error;
-        goto error_out;
+        goto error_put_s_gfn;
     }
     have_s_ref = 1;
 
@@ -2013,14 +2012,14 @@ __gnttab_copy(
     {
         unsigned dest_off, dest_len;
         rc = __acquire_grant_for_copy(dd, op->dest.u.ref, current->domain, 0,
-                                      &d_frame, &dest_off, &dest_len, 1,
+                                      &d_frame, &d_gfn, &dest_off, &dest_len, 1,
                                       &dest_domain);
         if ( rc != GNTST_okay )
-            goto error_out;
+            goto error_put_s_gfn;
         have_d_grant = 1;
         if ( op->dest.offset < dest_off ||
              op->len > dest_len )
-            PIN_FAIL(error_out, GNTST_general_error,
+            PIN_FAIL(error_put_d_gfn, GNTST_general_error,
                      "copy dest out of bounds: %d < %d || %d > %d\n",
                      op->dest.offset, dest_off,
                      op->len, dest_len);
@@ -2028,17 +2027,17 @@ __gnttab_copy(
     else
     {
 #ifdef CONFIG_X86
+        d_gfn = op->dest.u.gmfn;
         rc = __get_paged_frame(op->dest.u.gmfn, &d_frame, 0, dd);
-        put_gfn(dd, op->dest.u.gmfn);
         if ( rc != GNTST_okay )
-            goto error_out;
+            goto error_put_s_gfn;
 #else
         d_frame = gmfn_to_mfn(dd, op->dest.u.gmfn);
 #endif
         dest_domain = dd;
     }
     if ( unlikely(!mfn_valid(d_frame)) )
-        PIN_FAIL(error_out, GNTST_general_error,
+        PIN_FAIL(error_put_d_gfn, GNTST_general_error,
                  "destination frame %lx invalid.\n", d_frame);
     if ( !get_page_and_type(mfn_to_page(d_frame), dest_domain,
                             PGT_writable_page) )
@@ -2046,7 +2045,7 @@ __gnttab_copy(
         if ( !dd->is_dying )
             gdprintk(XENLOG_WARNING, "Could not get dst frame %lx\n", d_frame);
         rc = GNTST_general_error;
-        goto error_out;
+        goto error_put_d_gfn;
     }
 
     sp = map_domain_page(s_frame);
@@ -2060,6 +2059,12 @@ __gnttab_copy(
     gnttab_mark_dirty(dd, d_frame);
 
     put_page_and_type(mfn_to_page(d_frame));
+ error_put_d_gfn:
+    if ( (d_gfn != INVALID_GFN) && (dest_domain) )
+        put_gfn(dest_domain, d_gfn);
+ error_put_s_gfn:
+    if ( (s_gfn != INVALID_GFN) && (source_domain) )
+        put_gfn(source_domain, s_gfn);
  error_out:
     if ( have_s_ref )
         put_page(mfn_to_page(s_frame));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 13:48:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 13:48:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTZf2-0005Sv-7q; Thu, 24 Nov 2011 13:48:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTZf0-0005Sb-N9
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 13:48:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322142364!53526911!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26697 invoked from network); 24 Nov 2011 13:46:04 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.177) by server-8.tower-27.messagelabs.com with SMTP;
	24 Nov 2011 13:46:04 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 8192176C06F;
	Thu, 24 Nov 2011 05:47:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=LO9h2gikVeX7YTBnkt2sXgZA8njFgvshenXo23ZmcrUJ
	VpL7rFIJ2ZGBw1z8P4XuOk2uOZRZrLgiT+87+ZkMZnL3hOuwWxFR2hWlivGIs1tO
	qYJNyuNSspeZYTQVln9vnRCEu/vtoFzQ8sLREFPmi5R3UwnSUC4c4Um5gYzTJpM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7hkCatFz4Ytix9SyREvqBIB85uQ=; b=lgz0pmeApVK
	R1BfmM4s+Mjw2Q/B31nnSezApr7e90Y2u58j7oTgpxAFBD6ontt0+4xrLBTASZaE
	YgMl7iUJBEvTVVoZJ03dtFt3efhzBD9A0CKgxQbdxrZTbnkFXc6tnfAkb98sLRAK
	E5LB5zdlUDQNJn2bKKA1IRkrbB64oTHA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 3FEF476C065; 
	Thu, 24 Nov 2011 05:47:47 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f079cbeae77e5570c1935c9b6983820d7698dbf6
Message-Id: <f079cbeae77e5570c193.1322142091@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322142090@xdev.gridcentric.ca>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 08:41:31 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] Ensure maps used by nested hvm code
	cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c             |  69 ++++++++++++++++++++++++-------------
 xen/arch/x86/hvm/nestedhvm.c       |   4 +-
 xen/arch/x86/hvm/svm/nestedsvm.c   |  23 ++++++------
 xen/arch/x86/hvm/vmx/vvmx.c        |  36 +++++++++++--------
 xen/include/asm-x86/hvm/hvm.h      |   9 +++-
 xen/include/asm-x86/hvm/vcpu.h     |   1 +
 xen/include/asm-x86/hvm/vmx/vvmx.h |   1 +
 7 files changed, 88 insertions(+), 55 deletions(-)


The nested hvm code maps pages of the guest hvm. These maps live beyond
a hypervisor entry/exit pair, and thus their liveness cannot be ensured
with get_gfn/put_gfn critical sections. Ensure their liveness by
increasing the page ref count, instead.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1801,11 +1801,15 @@ int hvm_virtual_to_linear_addr(
     return 0;
 }
 
-/* We leave this function holding a lock on the p2m entry */
-static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
+/* On non-NULL return, we leave this function holding an additional 
+ * ref on the underlying mfn, if any */
+static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable,
+                                    struct page_info **page)
 {
+    void *map;
     unsigned long mfn;
     p2m_type_t p2mt;
+    struct page_info *pg;
     struct domain *d = current->domain;
 
     mfn = mfn_x(writable
@@ -1828,27 +1832,43 @@ static void *__hvm_map_guest_frame(unsig
     if ( writable )
         paging_mark_dirty(d, mfn);
 
-    return map_domain_page(mfn);
+    pg = mfn_to_page(mfn);
+    if (page)
+    {
+        page_get_owner_and_reference(pg);
+        *page = pg;
+    }
+
+    map = map_domain_page(mfn);
+    put_gfn(d, gfn);
+    return map;
 }
 
-void *hvm_map_guest_frame_rw(unsigned long gfn)
+void *hvm_map_guest_frame_rw(unsigned long gfn,
+                             struct page_info **page)
 {
-    return __hvm_map_guest_frame(gfn, 1);
+    return __hvm_map_guest_frame(gfn, 1, page);
 }
 
-void *hvm_map_guest_frame_ro(unsigned long gfn)
+void *hvm_map_guest_frame_ro(unsigned long gfn,
+                             struct page_info **page)
 {
-    return __hvm_map_guest_frame(gfn, 0);
+    return __hvm_map_guest_frame(gfn, 0, page);
 }
 
-void hvm_unmap_guest_frame(void *p)
+void hvm_unmap_guest_frame(void *p, struct page_info *page)
 {
     if ( p )
+    {
         unmap_domain_page(p);
+        if ( page )
+            put_page(page);
+    }
 }
 
-static void *hvm_map_entry(unsigned long va, unsigned long *gfn)
+static void *hvm_map_entry(unsigned long va, struct page_info **page)
 {
+    unsigned long gfn;
     uint32_t pfec;
     char *v;
 
@@ -1865,11 +1885,11 @@ static void *hvm_map_entry(unsigned long
      * treat it as a kernel-mode read (i.e. no access checks).
      */
     pfec = PFEC_page_present;
-    *gfn = paging_gva_to_gfn(current, va, &pfec);
+    gfn = paging_gva_to_gfn(current, va, &pfec);
     if ( (pfec == PFEC_page_paged) || (pfec == PFEC_page_shared) )
         goto fail;
 
-    v = hvm_map_guest_frame_rw(*gfn);
+    v = hvm_map_guest_frame_rw(gfn, page);
     if ( v == NULL )
         goto fail;
 
@@ -1880,11 +1900,9 @@ static void *hvm_map_entry(unsigned long
     return NULL;
 }
 
-static void hvm_unmap_entry(void *p, unsigned long gfn)
+static void hvm_unmap_entry(void *p, struct page_info *page)
 {
-    hvm_unmap_guest_frame(p);
-    if ( p && (gfn != INVALID_GFN) )
-        put_gfn(current->domain, gfn);
+    hvm_unmap_guest_frame(p, page);
 }
 
 static int hvm_load_segment_selector(
@@ -1896,7 +1914,7 @@ static int hvm_load_segment_selector(
     int fault_type = TRAP_invalid_tss;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct vcpu *v = current;
-    unsigned long pdesc_gfn = INVALID_GFN;
+    struct page_info *pdesc_pg = NULL;
 
     if ( regs->eflags & X86_EFLAGS_VM )
     {
@@ -1930,7 +1948,7 @@ static int hvm_load_segment_selector(
     if ( ((sel & 0xfff8) + 7) > desctab.limit )
         goto fail;
 
-    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_gfn);
+    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_pg);
     if ( pdesc == NULL )
         goto hvm_map_fail;
 
@@ -1990,7 +2008,7 @@ static int hvm_load_segment_selector(
     desc.b |= 0x100;
 
  skip_accessed_flag:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc, pdesc_pg);
 
     segr.base = (((desc.b <<  0) & 0xff000000u) |
                  ((desc.b << 16) & 0x00ff0000u) |
@@ -2006,7 +2024,7 @@ static int hvm_load_segment_selector(
     return 0;
 
  unmap_and_fail:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc, pdesc_pg);
  fail:
     hvm_inject_exception(fault_type, sel & 0xfffc, 0);
  hvm_map_fail:
@@ -2021,7 +2039,8 @@ void hvm_task_switch(
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct segment_register gdt, tr, prev_tr, segr;
     struct desc_struct *optss_desc = NULL, *nptss_desc = NULL, tss_desc;
-    unsigned long eflags, optss_gfn = INVALID_GFN, nptss_gfn = INVALID_GFN;
+    unsigned long eflags;
+    struct page_info *optss_pg = NULL, *nptss_pg = NULL;
     int exn_raised, rc;
     struct {
         u16 back_link,__blh;
@@ -2047,11 +2066,13 @@ void hvm_task_switch(
         goto out;
     }
 
-    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), &optss_gfn);
+    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), 
+                                &optss_pg);
     if ( optss_desc == NULL )
         goto out;
 
-    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), &nptss_gfn);
+    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), 
+                                &nptss_pg);
     if ( nptss_desc == NULL )
         goto out;
 
@@ -2216,8 +2237,8 @@ void hvm_task_switch(
     }
 
  out:
-    hvm_unmap_entry(optss_desc, optss_gfn);
-    hvm_unmap_entry(nptss_desc, nptss_gfn);
+    hvm_unmap_entry(optss_desc, optss_pg);
+    hvm_unmap_entry(nptss_desc, nptss_pg);
 }
 
 #define HVMCOPY_from_guest (0u<<0)
diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/nestedhvm.c
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -56,9 +56,11 @@ nestedhvm_vcpu_reset(struct vcpu *v)
     nv->nv_ioportED = 0;
 
     if (nv->nv_vvmcx)
-        hvm_unmap_guest_frame(nv->nv_vvmcx);
+        hvm_unmap_guest_frame(nv->nv_vvmcx, 
+                              nv->nv_vvmcx_pg);
     nv->nv_vvmcx = NULL;
     nv->nv_vvmcxaddr = VMCX_EADDR;
+    nv->nv_vvmcx_pg  = NULL;
     nv->nv_flushp2m = 0;
     nv->nv_p2m = NULL;
 
diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -71,20 +71,18 @@ int nestedsvm_vmcb_map(struct vcpu *v, u
     if (nv->nv_vvmcx != NULL && nv->nv_vvmcxaddr != vmcbaddr) {
         ASSERT(nv->nv_vvmcx != NULL);
         ASSERT(nv->nv_vvmcxaddr != VMCX_EADDR);
-        hvm_unmap_guest_frame(nv->nv_vvmcx);
+        hvm_unmap_guest_frame(nv->nv_vvmcx, nv->nv_vvmcx_pg);
         nv->nv_vvmcx = NULL;
         nv->nv_vvmcxaddr = VMCX_EADDR;
+        nv->nv_vvmcx_pg = NULL;
     }
 
     if (nv->nv_vvmcx == NULL) {
-        nv->nv_vvmcx = hvm_map_guest_frame_rw(vmcbaddr >> PAGE_SHIFT);
+        nv->nv_vvmcx = hvm_map_guest_frame_rw(vmcbaddr >> PAGE_SHIFT,
+                                                &nv->nv_vvmcx_pg);
         if (nv->nv_vvmcx == NULL)
             return 0;
         nv->nv_vvmcxaddr = vmcbaddr;
-        /* put_gfn here even though the map survives beyond this caller.
-         * The map can likely survive beyond a hypervisor exit, thus we
-         * need to put the gfn */
-        put_gfn(current->domain, vmcbaddr >> PAGE_SHIFT);
     }
 
     return 1;
@@ -336,6 +334,7 @@ static int nsvm_vmrun_permissionmap(stru
     unsigned int i;
     enum hvm_copy_result ret;
     unsigned long *ns_viomap;
+    struct page_info *ns_viomap_pg = NULL;
     bool_t ioport_80, ioport_ed;
 
     ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm;
@@ -353,12 +352,12 @@ static int nsvm_vmrun_permissionmap(stru
     svm->ns_oiomap_pa = svm->ns_iomap_pa;
     svm->ns_iomap_pa = ns_vmcb->_iopm_base_pa;
 
-    ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT);
+    ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT,
+                                        &ns_viomap_pg);
     ASSERT(ns_viomap != NULL);
     ioport_80 = test_bit(0x80, ns_viomap);
     ioport_ed = test_bit(0xed, ns_viomap);
-    hvm_unmap_guest_frame(ns_viomap);
-    put_gfn(current->domain, svm->ns_iomap_pa >> PAGE_SHIFT);
+    hvm_unmap_guest_frame(ns_viomap, ns_viomap_pg);
 
     svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
 
@@ -863,6 +862,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
     uint16_t port;
     bool_t enabled;
     unsigned long gfn = 0; /* gcc ... */
+    struct page_info *io_bitmap_pg = NULL;
 
     ioinfo.bytes = exitinfo1;
     port = ioinfo.fields.port;
@@ -880,7 +880,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
         break;
     }
 
-    io_bitmap = hvm_map_guest_frame_ro(gfn);
+    io_bitmap = hvm_map_guest_frame_ro(gfn, &io_bitmap_pg);
     if (io_bitmap == NULL) {
         gdprintk(XENLOG_ERR,
             "IOIO intercept: mapping of permission map failed\n");
@@ -888,8 +888,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
     }
 
     enabled = test_bit(port, io_bitmap);
-    hvm_unmap_guest_frame(io_bitmap);
-    put_gfn(current->domain, gfn);
+    hvm_unmap_guest_frame(io_bitmap, io_bitmap_pg);
 
     if (!enabled)
         return NESTEDHVM_VMEXIT_HOST;
diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -44,10 +44,13 @@ int nvmx_vcpu_initialise(struct vcpu *v)
     nvmx->vmxon_region_pa = 0;
     nvcpu->nv_vvmcx = NULL;
     nvcpu->nv_vvmcxaddr = VMCX_EADDR;
+    nvcpu->nv_vvmcx_pg = NULL;
     nvmx->intr.intr_info = 0;
     nvmx->intr.error_code = 0;
     nvmx->iobitmap[0] = NULL;
     nvmx->iobitmap[1] = NULL;
+    nvmx->iobitmap_pg[0] = NULL;
+    nvmx->iobitmap_pg[1] = NULL;
     return 0;
 out:
     return -ENOMEM;
@@ -558,12 +561,14 @@ static void __map_io_bitmap(struct vcpu 
 
     index = vmcs_reg == IO_BITMAP_A ? 0 : 1;
     if (nvmx->iobitmap[index])
-        hvm_unmap_guest_frame (nvmx->iobitmap[index]); 
+    {
+        hvm_unmap_guest_frame (nvmx->iobitmap[index],
+                               nvmx->iobitmap_pg[index]); 
+        nvmx->iobitmap_pg[index] = NULL;
+    }
     gpa = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, vmcs_reg);
-    nvmx->iobitmap[index] = hvm_map_guest_frame_ro (gpa >> PAGE_SHIFT);
-    /* See comment in nestedsvm_vmcb_map re putting this gfn and 
-     * liveness of the map it backs */
-    put_gfn(current->domain, gpa >> PAGE_SHIFT);
+    nvmx->iobitmap[index] = hvm_map_guest_frame_ro(gpa >> PAGE_SHIFT,
+                                             &nvmx->iobitmap_pg[index]);
 }
 
 static inline void map_io_bitmap_all(struct vcpu *v)
@@ -580,13 +585,16 @@ static void nvmx_purge_vvmcs(struct vcpu
 
     __clear_current_vvmcs(v);
     if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
-        hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
-    nvcpu->nv_vvmcx == NULL;
+        hvm_unmap_guest_frame(nvcpu->nv_vvmcx, nvcpu->nv_vvmcx_pg);
+    nvcpu->nv_vvmcx = NULL;
     nvcpu->nv_vvmcxaddr = VMCX_EADDR;
+    nvcpu->nv_vvmcx_pg = NULL;
     for (i=0; i<2; i++) {
         if ( nvmx->iobitmap[i] ) {
-            hvm_unmap_guest_frame(nvmx->iobitmap[i]); 
+            hvm_unmap_guest_frame(nvmx->iobitmap[i], 
+                                  nvmx->iobitmap_pg[i]); 
             nvmx->iobitmap[i] = NULL;
+            nvmx->iobitmap_pg[i] = NULL;
         }
     }
 }
@@ -1138,12 +1146,10 @@ int nvmx_handle_vmptrld(struct cpu_user_
 
     if ( nvcpu->nv_vvmcxaddr == VMCX_EADDR )
     {
-        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw (gpa >> PAGE_SHIFT);
+        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT,
+                                                 &nvcpu->nv_vvmcx_pg);
         nvcpu->nv_vvmcxaddr = gpa;
         map_io_bitmap_all (v);
-        /* See comment in nestedsvm_vmcb_map regarding putting this 
-         * gfn and liveness of the map that uses it */
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
     }
 
     vmreturn(regs, VMSUCCEED);
@@ -1201,11 +1207,11 @@ int nvmx_handle_vmclear(struct cpu_user_
     else 
     {
         /* Even if this VMCS isn't the current one, we must clear it. */
-        vvmcs = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT);
+        struct page_info *vvmcs_pg = NULL;
+        vvmcs = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT, &vvmcs_pg);
         if ( vvmcs ) 
             __set_vvmcs(vvmcs, NVMX_LAUNCH_STATE, 0);
-        hvm_unmap_guest_frame(vvmcs);
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
+        hvm_unmap_guest_frame(vvmcs, vvmcs_pg);
     }
 
     vmreturn(regs, VMSUCCEED);
diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -26,6 +26,7 @@
 #include <asm/hvm/asid.h>
 #include <public/domctl.h>
 #include <public/hvm/save.h>
+#include <asm/mm.h>
 
 /* Interrupt acknowledgement sources. */
 enum hvm_intsrc {
@@ -392,9 +393,11 @@ int hvm_virtual_to_linear_addr(
     unsigned int addr_size,
     unsigned long *linear_addr);
 
-void *hvm_map_guest_frame_rw(unsigned long gfn);
-void *hvm_map_guest_frame_ro(unsigned long gfn);
-void hvm_unmap_guest_frame(void *p);
+void *hvm_map_guest_frame_rw(unsigned long gfn,
+                             struct page_info **page);
+void *hvm_map_guest_frame_ro(unsigned long gfn,
+                             struct page_info **page);
+void hvm_unmap_guest_frame(void *p, struct page_info *page);
 
 static inline void hvm_set_info_guest(struct vcpu *v)
 {
diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/vcpu.h
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -77,6 +77,7 @@ struct nestedvcpu {
     void *nv_n2vmcx; /* shadow VMCB/VMCS used to run l2 guest */
 
     uint64_t nv_vvmcxaddr; /* l1 guest physical address of nv_vvmcx */
+    struct page_info *nv_vvmcx_pg; /* page where nv_vvmcx resides */
     uint64_t nv_n1vmcx_pa; /* host physical address of nv_n1vmcx */
     uint64_t nv_n2vmcx_pa; /* host physical address of nv_n2vmcx */
 
diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h
@@ -26,6 +26,7 @@
 struct nestedvmx {
     paddr_t    vmxon_region_pa;
     void       *iobitmap[2];		/* map (va) of L1 guest I/O bitmap */
+    struct page_info *iobitmap_pg[2]; /* pages backing L1 guest I/O bitmap */
     /* deferred nested interrupt */
     struct {
         unsigned long intr_info;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 13:48:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 13:48:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTZf2-0005Sv-7q; Thu, 24 Nov 2011 13:48:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTZf0-0005Sb-N9
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 13:48:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322142364!53526911!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26697 invoked from network); 24 Nov 2011 13:46:04 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.177) by server-8.tower-27.messagelabs.com with SMTP;
	24 Nov 2011 13:46:04 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 8192176C06F;
	Thu, 24 Nov 2011 05:47:48 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=LO9h2gikVeX7YTBnkt2sXgZA8njFgvshenXo23ZmcrUJ
	VpL7rFIJ2ZGBw1z8P4XuOk2uOZRZrLgiT+87+ZkMZnL3hOuwWxFR2hWlivGIs1tO
	qYJNyuNSspeZYTQVln9vnRCEu/vtoFzQ8sLREFPmi5R3UwnSUC4c4Um5gYzTJpM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7hkCatFz4Ytix9SyREvqBIB85uQ=; b=lgz0pmeApVK
	R1BfmM4s+Mjw2Q/B31nnSezApr7e90Y2u58j7oTgpxAFBD6ontt0+4xrLBTASZaE
	YgMl7iUJBEvTVVoZJ03dtFt3efhzBD9A0CKgxQbdxrZTbnkFXc6tnfAkb98sLRAK
	E5LB5zdlUDQNJn2bKKA1IRkrbB64oTHA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPSA id 3FEF476C065; 
	Thu, 24 Nov 2011 05:47:47 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f079cbeae77e5570c1935c9b6983820d7698dbf6
Message-Id: <f079cbeae77e5570c193.1322142091@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322142090@xdev.gridcentric.ca>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 08:41:31 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 3] Ensure maps used by nested hvm code
	cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c             |  69 ++++++++++++++++++++++++-------------
 xen/arch/x86/hvm/nestedhvm.c       |   4 +-
 xen/arch/x86/hvm/svm/nestedsvm.c   |  23 ++++++------
 xen/arch/x86/hvm/vmx/vvmx.c        |  36 +++++++++++--------
 xen/include/asm-x86/hvm/hvm.h      |   9 +++-
 xen/include/asm-x86/hvm/vcpu.h     |   1 +
 xen/include/asm-x86/hvm/vmx/vvmx.h |   1 +
 7 files changed, 88 insertions(+), 55 deletions(-)


The nested hvm code maps pages of the guest hvm. These maps live beyond
a hypervisor entry/exit pair, and thus their liveness cannot be ensured
with get_gfn/put_gfn critical sections. Ensure their liveness by
increasing the page ref count, instead.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1801,11 +1801,15 @@ int hvm_virtual_to_linear_addr(
     return 0;
 }
 
-/* We leave this function holding a lock on the p2m entry */
-static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
+/* On non-NULL return, we leave this function holding an additional 
+ * ref on the underlying mfn, if any */
+static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable,
+                                    struct page_info **page)
 {
+    void *map;
     unsigned long mfn;
     p2m_type_t p2mt;
+    struct page_info *pg;
     struct domain *d = current->domain;
 
     mfn = mfn_x(writable
@@ -1828,27 +1832,43 @@ static void *__hvm_map_guest_frame(unsig
     if ( writable )
         paging_mark_dirty(d, mfn);
 
-    return map_domain_page(mfn);
+    pg = mfn_to_page(mfn);
+    if (page)
+    {
+        page_get_owner_and_reference(pg);
+        *page = pg;
+    }
+
+    map = map_domain_page(mfn);
+    put_gfn(d, gfn);
+    return map;
 }
 
-void *hvm_map_guest_frame_rw(unsigned long gfn)
+void *hvm_map_guest_frame_rw(unsigned long gfn,
+                             struct page_info **page)
 {
-    return __hvm_map_guest_frame(gfn, 1);
+    return __hvm_map_guest_frame(gfn, 1, page);
 }
 
-void *hvm_map_guest_frame_ro(unsigned long gfn)
+void *hvm_map_guest_frame_ro(unsigned long gfn,
+                             struct page_info **page)
 {
-    return __hvm_map_guest_frame(gfn, 0);
+    return __hvm_map_guest_frame(gfn, 0, page);
 }
 
-void hvm_unmap_guest_frame(void *p)
+void hvm_unmap_guest_frame(void *p, struct page_info *page)
 {
     if ( p )
+    {
         unmap_domain_page(p);
+        if ( page )
+            put_page(page);
+    }
 }
 
-static void *hvm_map_entry(unsigned long va, unsigned long *gfn)
+static void *hvm_map_entry(unsigned long va, struct page_info **page)
 {
+    unsigned long gfn;
     uint32_t pfec;
     char *v;
 
@@ -1865,11 +1885,11 @@ static void *hvm_map_entry(unsigned long
      * treat it as a kernel-mode read (i.e. no access checks).
      */
     pfec = PFEC_page_present;
-    *gfn = paging_gva_to_gfn(current, va, &pfec);
+    gfn = paging_gva_to_gfn(current, va, &pfec);
     if ( (pfec == PFEC_page_paged) || (pfec == PFEC_page_shared) )
         goto fail;
 
-    v = hvm_map_guest_frame_rw(*gfn);
+    v = hvm_map_guest_frame_rw(gfn, page);
     if ( v == NULL )
         goto fail;
 
@@ -1880,11 +1900,9 @@ static void *hvm_map_entry(unsigned long
     return NULL;
 }
 
-static void hvm_unmap_entry(void *p, unsigned long gfn)
+static void hvm_unmap_entry(void *p, struct page_info *page)
 {
-    hvm_unmap_guest_frame(p);
-    if ( p && (gfn != INVALID_GFN) )
-        put_gfn(current->domain, gfn);
+    hvm_unmap_guest_frame(p, page);
 }
 
 static int hvm_load_segment_selector(
@@ -1896,7 +1914,7 @@ static int hvm_load_segment_selector(
     int fault_type = TRAP_invalid_tss;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct vcpu *v = current;
-    unsigned long pdesc_gfn = INVALID_GFN;
+    struct page_info *pdesc_pg = NULL;
 
     if ( regs->eflags & X86_EFLAGS_VM )
     {
@@ -1930,7 +1948,7 @@ static int hvm_load_segment_selector(
     if ( ((sel & 0xfff8) + 7) > desctab.limit )
         goto fail;
 
-    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_gfn);
+    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_pg);
     if ( pdesc == NULL )
         goto hvm_map_fail;
 
@@ -1990,7 +2008,7 @@ static int hvm_load_segment_selector(
     desc.b |= 0x100;
 
  skip_accessed_flag:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc, pdesc_pg);
 
     segr.base = (((desc.b <<  0) & 0xff000000u) |
                  ((desc.b << 16) & 0x00ff0000u) |
@@ -2006,7 +2024,7 @@ static int hvm_load_segment_selector(
     return 0;
 
  unmap_and_fail:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc, pdesc_pg);
  fail:
     hvm_inject_exception(fault_type, sel & 0xfffc, 0);
  hvm_map_fail:
@@ -2021,7 +2039,8 @@ void hvm_task_switch(
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct segment_register gdt, tr, prev_tr, segr;
     struct desc_struct *optss_desc = NULL, *nptss_desc = NULL, tss_desc;
-    unsigned long eflags, optss_gfn = INVALID_GFN, nptss_gfn = INVALID_GFN;
+    unsigned long eflags;
+    struct page_info *optss_pg = NULL, *nptss_pg = NULL;
     int exn_raised, rc;
     struct {
         u16 back_link,__blh;
@@ -2047,11 +2066,13 @@ void hvm_task_switch(
         goto out;
     }
 
-    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), &optss_gfn);
+    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), 
+                                &optss_pg);
     if ( optss_desc == NULL )
         goto out;
 
-    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), &nptss_gfn);
+    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), 
+                                &nptss_pg);
     if ( nptss_desc == NULL )
         goto out;
 
@@ -2216,8 +2237,8 @@ void hvm_task_switch(
     }
 
  out:
-    hvm_unmap_entry(optss_desc, optss_gfn);
-    hvm_unmap_entry(nptss_desc, nptss_gfn);
+    hvm_unmap_entry(optss_desc, optss_pg);
+    hvm_unmap_entry(nptss_desc, nptss_pg);
 }
 
 #define HVMCOPY_from_guest (0u<<0)
diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/nestedhvm.c
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -56,9 +56,11 @@ nestedhvm_vcpu_reset(struct vcpu *v)
     nv->nv_ioportED = 0;
 
     if (nv->nv_vvmcx)
-        hvm_unmap_guest_frame(nv->nv_vvmcx);
+        hvm_unmap_guest_frame(nv->nv_vvmcx, 
+                              nv->nv_vvmcx_pg);
     nv->nv_vvmcx = NULL;
     nv->nv_vvmcxaddr = VMCX_EADDR;
+    nv->nv_vvmcx_pg  = NULL;
     nv->nv_flushp2m = 0;
     nv->nv_p2m = NULL;
 
diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -71,20 +71,18 @@ int nestedsvm_vmcb_map(struct vcpu *v, u
     if (nv->nv_vvmcx != NULL && nv->nv_vvmcxaddr != vmcbaddr) {
         ASSERT(nv->nv_vvmcx != NULL);
         ASSERT(nv->nv_vvmcxaddr != VMCX_EADDR);
-        hvm_unmap_guest_frame(nv->nv_vvmcx);
+        hvm_unmap_guest_frame(nv->nv_vvmcx, nv->nv_vvmcx_pg);
         nv->nv_vvmcx = NULL;
         nv->nv_vvmcxaddr = VMCX_EADDR;
+        nv->nv_vvmcx_pg = NULL;
     }
 
     if (nv->nv_vvmcx == NULL) {
-        nv->nv_vvmcx = hvm_map_guest_frame_rw(vmcbaddr >> PAGE_SHIFT);
+        nv->nv_vvmcx = hvm_map_guest_frame_rw(vmcbaddr >> PAGE_SHIFT,
+                                                &nv->nv_vvmcx_pg);
         if (nv->nv_vvmcx == NULL)
             return 0;
         nv->nv_vvmcxaddr = vmcbaddr;
-        /* put_gfn here even though the map survives beyond this caller.
-         * The map can likely survive beyond a hypervisor exit, thus we
-         * need to put the gfn */
-        put_gfn(current->domain, vmcbaddr >> PAGE_SHIFT);
     }
 
     return 1;
@@ -336,6 +334,7 @@ static int nsvm_vmrun_permissionmap(stru
     unsigned int i;
     enum hvm_copy_result ret;
     unsigned long *ns_viomap;
+    struct page_info *ns_viomap_pg = NULL;
     bool_t ioport_80, ioport_ed;
 
     ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm;
@@ -353,12 +352,12 @@ static int nsvm_vmrun_permissionmap(stru
     svm->ns_oiomap_pa = svm->ns_iomap_pa;
     svm->ns_iomap_pa = ns_vmcb->_iopm_base_pa;
 
-    ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT);
+    ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT,
+                                        &ns_viomap_pg);
     ASSERT(ns_viomap != NULL);
     ioport_80 = test_bit(0x80, ns_viomap);
     ioport_ed = test_bit(0xed, ns_viomap);
-    hvm_unmap_guest_frame(ns_viomap);
-    put_gfn(current->domain, svm->ns_iomap_pa >> PAGE_SHIFT);
+    hvm_unmap_guest_frame(ns_viomap, ns_viomap_pg);
 
     svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
 
@@ -863,6 +862,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
     uint16_t port;
     bool_t enabled;
     unsigned long gfn = 0; /* gcc ... */
+    struct page_info *io_bitmap_pg = NULL;
 
     ioinfo.bytes = exitinfo1;
     port = ioinfo.fields.port;
@@ -880,7 +880,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
         break;
     }
 
-    io_bitmap = hvm_map_guest_frame_ro(gfn);
+    io_bitmap = hvm_map_guest_frame_ro(gfn, &io_bitmap_pg);
     if (io_bitmap == NULL) {
         gdprintk(XENLOG_ERR,
             "IOIO intercept: mapping of permission map failed\n");
@@ -888,8 +888,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
     }
 
     enabled = test_bit(port, io_bitmap);
-    hvm_unmap_guest_frame(io_bitmap);
-    put_gfn(current->domain, gfn);
+    hvm_unmap_guest_frame(io_bitmap, io_bitmap_pg);
 
     if (!enabled)
         return NESTEDHVM_VMEXIT_HOST;
diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -44,10 +44,13 @@ int nvmx_vcpu_initialise(struct vcpu *v)
     nvmx->vmxon_region_pa = 0;
     nvcpu->nv_vvmcx = NULL;
     nvcpu->nv_vvmcxaddr = VMCX_EADDR;
+    nvcpu->nv_vvmcx_pg = NULL;
     nvmx->intr.intr_info = 0;
     nvmx->intr.error_code = 0;
     nvmx->iobitmap[0] = NULL;
     nvmx->iobitmap[1] = NULL;
+    nvmx->iobitmap_pg[0] = NULL;
+    nvmx->iobitmap_pg[1] = NULL;
     return 0;
 out:
     return -ENOMEM;
@@ -558,12 +561,14 @@ static void __map_io_bitmap(struct vcpu 
 
     index = vmcs_reg == IO_BITMAP_A ? 0 : 1;
     if (nvmx->iobitmap[index])
-        hvm_unmap_guest_frame (nvmx->iobitmap[index]); 
+    {
+        hvm_unmap_guest_frame (nvmx->iobitmap[index],
+                               nvmx->iobitmap_pg[index]); 
+        nvmx->iobitmap_pg[index] = NULL;
+    }
     gpa = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, vmcs_reg);
-    nvmx->iobitmap[index] = hvm_map_guest_frame_ro (gpa >> PAGE_SHIFT);
-    /* See comment in nestedsvm_vmcb_map re putting this gfn and 
-     * liveness of the map it backs */
-    put_gfn(current->domain, gpa >> PAGE_SHIFT);
+    nvmx->iobitmap[index] = hvm_map_guest_frame_ro(gpa >> PAGE_SHIFT,
+                                             &nvmx->iobitmap_pg[index]);
 }
 
 static inline void map_io_bitmap_all(struct vcpu *v)
@@ -580,13 +585,16 @@ static void nvmx_purge_vvmcs(struct vcpu
 
     __clear_current_vvmcs(v);
     if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
-        hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
-    nvcpu->nv_vvmcx == NULL;
+        hvm_unmap_guest_frame(nvcpu->nv_vvmcx, nvcpu->nv_vvmcx_pg);
+    nvcpu->nv_vvmcx = NULL;
     nvcpu->nv_vvmcxaddr = VMCX_EADDR;
+    nvcpu->nv_vvmcx_pg = NULL;
     for (i=0; i<2; i++) {
         if ( nvmx->iobitmap[i] ) {
-            hvm_unmap_guest_frame(nvmx->iobitmap[i]); 
+            hvm_unmap_guest_frame(nvmx->iobitmap[i], 
+                                  nvmx->iobitmap_pg[i]); 
             nvmx->iobitmap[i] = NULL;
+            nvmx->iobitmap_pg[i] = NULL;
         }
     }
 }
@@ -1138,12 +1146,10 @@ int nvmx_handle_vmptrld(struct cpu_user_
 
     if ( nvcpu->nv_vvmcxaddr == VMCX_EADDR )
     {
-        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw (gpa >> PAGE_SHIFT);
+        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT,
+                                                 &nvcpu->nv_vvmcx_pg);
         nvcpu->nv_vvmcxaddr = gpa;
         map_io_bitmap_all (v);
-        /* See comment in nestedsvm_vmcb_map regarding putting this 
-         * gfn and liveness of the map that uses it */
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
     }
 
     vmreturn(regs, VMSUCCEED);
@@ -1201,11 +1207,11 @@ int nvmx_handle_vmclear(struct cpu_user_
     else 
     {
         /* Even if this VMCS isn't the current one, we must clear it. */
-        vvmcs = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT);
+        struct page_info *vvmcs_pg = NULL;
+        vvmcs = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT, &vvmcs_pg);
         if ( vvmcs ) 
             __set_vvmcs(vvmcs, NVMX_LAUNCH_STATE, 0);
-        hvm_unmap_guest_frame(vvmcs);
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
+        hvm_unmap_guest_frame(vvmcs, vvmcs_pg);
     }
 
     vmreturn(regs, VMSUCCEED);
diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -26,6 +26,7 @@
 #include <asm/hvm/asid.h>
 #include <public/domctl.h>
 #include <public/hvm/save.h>
+#include <asm/mm.h>
 
 /* Interrupt acknowledgement sources. */
 enum hvm_intsrc {
@@ -392,9 +393,11 @@ int hvm_virtual_to_linear_addr(
     unsigned int addr_size,
     unsigned long *linear_addr);
 
-void *hvm_map_guest_frame_rw(unsigned long gfn);
-void *hvm_map_guest_frame_ro(unsigned long gfn);
-void hvm_unmap_guest_frame(void *p);
+void *hvm_map_guest_frame_rw(unsigned long gfn,
+                             struct page_info **page);
+void *hvm_map_guest_frame_ro(unsigned long gfn,
+                             struct page_info **page);
+void hvm_unmap_guest_frame(void *p, struct page_info *page);
 
 static inline void hvm_set_info_guest(struct vcpu *v)
 {
diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/vcpu.h
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -77,6 +77,7 @@ struct nestedvcpu {
     void *nv_n2vmcx; /* shadow VMCB/VMCS used to run l2 guest */
 
     uint64_t nv_vvmcxaddr; /* l1 guest physical address of nv_vvmcx */
+    struct page_info *nv_vvmcx_pg; /* page where nv_vvmcx resides */
     uint64_t nv_n1vmcx_pa; /* host physical address of nv_n1vmcx */
     uint64_t nv_n2vmcx_pa; /* host physical address of nv_n2vmcx */
 
diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/vmx/vvmx.h
--- a/xen/include/asm-x86/hvm/vmx/vvmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vvmx.h
@@ -26,6 +26,7 @@
 struct nestedvmx {
     paddr_t    vmxon_region_pa;
     void       *iobitmap[2];		/* map (va) of L1 guest I/O bitmap */
+    struct page_info *iobitmap_pg[2]; /* pages backing L1 guest I/O bitmap */
     /* deferred nested interrupt */
     struct {
         unsigned long intr_info;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 14:55:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 14:55:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTah7-00070t-13; Thu, 24 Nov 2011 14:54:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTah5-00070n-2G
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 14:54:31 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322146399!64521815!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25165 invoked from network); 24 Nov 2011 14:53:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 14:53:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9114808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 14:53:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 14:53:59 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTagZ-0006B9-8x;
	Thu, 24 Nov 2011 14:53:59 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTagL-0004sn-IL;
	Thu, 24 Nov 2011 14:53:45 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 14:53:44 +0000
Message-ID: <1322146424-18738-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: keir@xen.org, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
	reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


The Intel GPU uses a two pages NVS region called OpRegion.
In order to get full support for the driver in the guest
we need to map this region.

This patch reserves 2 pages on the top of the RAM and
mark this region as NVS in the e820. Then we write the
address to the config space (offset 0xfc) so the device
model can map the OpRegion at this address in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 tools/firmware/hvmloader/config.h   |    1 +
 tools/firmware/hvmloader/e820.c     |   34 ++++++++++++++++++++++++++++++----
 tools/firmware/hvmloader/pci.c      |   14 ++++++++++++++
 tools/firmware/hvmloader/pci_regs.h |    2 ++
 4 files changed, 47 insertions(+), 4 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch"

diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index d911352..9cac9c1 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -5,6 +5,7 @@
 
 enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
 extern enum virtual_vga virtual_vga;
+extern unsigned long igd_opregion_pgbase;
 
 struct bios_config {
     const char *name;
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 3b50dd0..0fc0b1c 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -128,11 +128,37 @@ int build_e820_table(struct e820entry *e820,
      * Explicitly reserve space for special pages.
      * This space starts at RESERVED_MEMBASE an extends to cover various
      * fixed hardware mappings (e.g., LAPIC, IOAPIC, default SVGA framebuffer).
+     *
+     * If igd_opregion_pgbase we need to split the RESERVED region in two.
      */
-    e820[nr].addr = RESERVED_MEMBASE;
-    e820[nr].size = (uint32_t)-e820[nr].addr;
-    e820[nr].type = E820_RESERVED;
-    nr++;
+
+    if ( igd_opregion_pgbase )
+    {
+        uint32_t igd_opregion_base = igd_opregion_pgbase << PAGE_SHIFT;
+
+        e820[nr].addr = RESERVED_MEMBASE;
+        e820[nr].size = (uint32_t) igd_opregion_base - RESERVED_MEMBASE;
+        e820[nr].type = E820_RESERVED;
+        nr++;
+
+        e820[nr].addr = igd_opregion_base;
+        e820[nr].size = 2 * PAGE_SIZE;
+        e820[nr].type = E820_NVS;
+        nr++;
+
+        e820[nr].addr = igd_opregion_base + 2 * PAGE_SIZE;
+        e820[nr].size = (uint32_t)-e820[nr].addr;
+        e820[nr].type = E820_RESERVED;
+        nr++;
+    }
+    else
+    {
+        e820[nr].addr = RESERVED_MEMBASE;
+        e820[nr].size = (uint32_t)-e820[nr].addr;
+        e820[nr].type = E820_RESERVED;
+        nr++;
+    }
+
 
     if ( hvm_info->high_mem_pgend )
     {
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 00490f1..2534530 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -32,6 +32,7 @@ unsigned long pci_mem_start = PCI_MEM_START;
 unsigned long pci_mem_end = PCI_MEM_END;
 
 enum virtual_vga virtual_vga = VGA_none;
+unsigned long igd_opregion_pgbase = 0;
 
 void pci_setup(void)
 {
@@ -95,6 +96,19 @@ void pci_setup(void)
             {
                 vga_devfn = devfn;
                 virtual_vga = VGA_pt;
+                if ( vendor_id == 0x8086 )
+                {
+                    igd_opregion_pgbase = mem_hole_alloc(2);
+
+                    /*
+                    ** Write the the OpRegion offset to give the opregion
+                    ** address to the device model.
+                    ** The device model will trap and map the OpRegion at
+                    ** the give address.
+                    */
+                    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+                            igd_opregion_pgbase << PAGE_SHIFT);
+                }
             }
             break;
         case 0x0680:
diff --git a/tools/firmware/hvmloader/pci_regs.h b/tools/firmware/hvmloader/pci_regs.h
index f37affe..0803f77 100644
--- a/tools/firmware/hvmloader/pci_regs.h
+++ b/tools/firmware/hvmloader/pci_regs.h
@@ -105,6 +105,8 @@
 #define PCI_MIN_GNT  0x3e /* 8 bits */
 #define PCI_MAX_LAT  0x3f /* 8 bits */
 
+#define PCI_INTEL_OPREGION 0xfc /* 4 bits */
+
 #endif /* __HVMLOADER_PCI_REGS_H__ */
 
 /*

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 14:55:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 14:55:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTah7-00070t-13; Thu, 24 Nov 2011 14:54:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTah5-00070n-2G
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 14:54:31 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322146399!64521815!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25165 invoked from network); 24 Nov 2011 14:53:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 14:53:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9114808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 14:53:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 14:53:59 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTagZ-0006B9-8x;
	Thu, 24 Nov 2011 14:53:59 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTagL-0004sn-IL;
	Thu, 24 Nov 2011 14:53:45 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 14:53:44 +0000
Message-ID: <1322146424-18738-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: keir@xen.org, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
	reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


The Intel GPU uses a two pages NVS region called OpRegion.
In order to get full support for the driver in the guest
we need to map this region.

This patch reserves 2 pages on the top of the RAM and
mark this region as NVS in the e820. Then we write the
address to the config space (offset 0xfc) so the device
model can map the OpRegion at this address in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 tools/firmware/hvmloader/config.h   |    1 +
 tools/firmware/hvmloader/e820.c     |   34 ++++++++++++++++++++++++++++++----
 tools/firmware/hvmloader/pci.c      |   14 ++++++++++++++
 tools/firmware/hvmloader/pci_regs.h |    2 ++
 4 files changed, 47 insertions(+), 4 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch"

diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index d911352..9cac9c1 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -5,6 +5,7 @@
 
 enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
 extern enum virtual_vga virtual_vga;
+extern unsigned long igd_opregion_pgbase;
 
 struct bios_config {
     const char *name;
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 3b50dd0..0fc0b1c 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -128,11 +128,37 @@ int build_e820_table(struct e820entry *e820,
      * Explicitly reserve space for special pages.
      * This space starts at RESERVED_MEMBASE an extends to cover various
      * fixed hardware mappings (e.g., LAPIC, IOAPIC, default SVGA framebuffer).
+     *
+     * If igd_opregion_pgbase we need to split the RESERVED region in two.
      */
-    e820[nr].addr = RESERVED_MEMBASE;
-    e820[nr].size = (uint32_t)-e820[nr].addr;
-    e820[nr].type = E820_RESERVED;
-    nr++;
+
+    if ( igd_opregion_pgbase )
+    {
+        uint32_t igd_opregion_base = igd_opregion_pgbase << PAGE_SHIFT;
+
+        e820[nr].addr = RESERVED_MEMBASE;
+        e820[nr].size = (uint32_t) igd_opregion_base - RESERVED_MEMBASE;
+        e820[nr].type = E820_RESERVED;
+        nr++;
+
+        e820[nr].addr = igd_opregion_base;
+        e820[nr].size = 2 * PAGE_SIZE;
+        e820[nr].type = E820_NVS;
+        nr++;
+
+        e820[nr].addr = igd_opregion_base + 2 * PAGE_SIZE;
+        e820[nr].size = (uint32_t)-e820[nr].addr;
+        e820[nr].type = E820_RESERVED;
+        nr++;
+    }
+    else
+    {
+        e820[nr].addr = RESERVED_MEMBASE;
+        e820[nr].size = (uint32_t)-e820[nr].addr;
+        e820[nr].type = E820_RESERVED;
+        nr++;
+    }
+
 
     if ( hvm_info->high_mem_pgend )
     {
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 00490f1..2534530 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -32,6 +32,7 @@ unsigned long pci_mem_start = PCI_MEM_START;
 unsigned long pci_mem_end = PCI_MEM_END;
 
 enum virtual_vga virtual_vga = VGA_none;
+unsigned long igd_opregion_pgbase = 0;
 
 void pci_setup(void)
 {
@@ -95,6 +96,19 @@ void pci_setup(void)
             {
                 vga_devfn = devfn;
                 virtual_vga = VGA_pt;
+                if ( vendor_id == 0x8086 )
+                {
+                    igd_opregion_pgbase = mem_hole_alloc(2);
+
+                    /*
+                    ** Write the the OpRegion offset to give the opregion
+                    ** address to the device model.
+                    ** The device model will trap and map the OpRegion at
+                    ** the give address.
+                    */
+                    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+                            igd_opregion_pgbase << PAGE_SHIFT);
+                }
             }
             break;
         case 0x0680:
diff --git a/tools/firmware/hvmloader/pci_regs.h b/tools/firmware/hvmloader/pci_regs.h
index f37affe..0803f77 100644
--- a/tools/firmware/hvmloader/pci_regs.h
+++ b/tools/firmware/hvmloader/pci_regs.h
@@ -105,6 +105,8 @@
 #define PCI_MIN_GNT  0x3e /* 8 bits */
 #define PCI_MAX_LAT  0x3f /* 8 bits */
 
+#define PCI_INTEL_OPREGION 0xfc /* 4 bits */
+
 #endif /* __HVMLOADER_PCI_REGS_H__ */
 
 /*

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:01:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTanO-0007Cl-V2; Thu, 24 Nov 2011 15:01:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RTanN-0007Ce-Tw
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:01:02 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322146786!58135776!1
X-Originating-IP: [209.85.220.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27198 invoked from network); 24 Nov 2011 14:59:47 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 14:59:47 -0000
Received: by vcbfo1 with SMTP id fo1so3156492vcb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 07:00:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=oWLm1tlufG0BWPBsnBq4bnCntrw2+VJQ5MnXpAxWvOw=;
	b=vO79NLqUNGuTeMB65yLZY/RGCeBNcgE56dgjbUNn6HEBn8pmCPBi+WIZm5PgH6UICy
	4hvVgYc83ifMJ7PyzBTHNxPMUz5RN+SmcdTxaphJHs6IJ+MnF+BdxITM3nYqBK4hpeHN
	+2pvU8vY/ZRBZxrh24QSfpal6Y6guDDvJT/XM=
Received: by 10.52.69.13 with SMTP id a13mr605949vdu.89.1322146829158; Thu, 24
	Nov 2011 07:00:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Thu, 24 Nov 2011 07:00:08 -0800 (PST)
In-Reply-To: <1322146424-18738-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1322146424-18738-1-git-send-email-jean.guyader@eu.citrix.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 24 Nov 2011 15:00:08 +0000
Message-ID: <CAEBdQ93csrR9vhskdSonUsBRW+BM0imWnfmrDcH4UawVZJz0=w@mail.gmail.com>
To: Jean Guyader <jean.guyader@eu.citrix.com>
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
	reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The description was slightly wrong, here is a new one:

The Intel GPU uses a two pages NVS region called OpRegion.
In order to get full support for the driver in the guest
we need to map this region.

This patch reserves 2 pages on the top of the memory in the
reserved area and mark this region as NVS in the e820. Then
we write the address to the config space (offset 0xfc) so the
device model can map the OpRegion at this address in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

On 24 November 2011 14:53, Jean Guyader <jean.guyader@eu.citrix.com> wrote:
>
> The Intel GPU uses a two pages NVS region called OpRegion.
> In order to get full support for the driver in the guest
> we need to map this region.
>
> This patch reserves 2 pages on the top of the RAM and
> mark this region as NVS in the e820. Then we write the
> address to the config space (offset 0xfc) so the device
> model can map the OpRegion at this address in the guest.
>
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
> =A0tools/firmware/hvmloader/config.h =A0 | =A0 =A01 +
> =A0tools/firmware/hvmloader/e820.c =A0 =A0 | =A0 34 +++++++++++++++++++++=
+++++++++----
> =A0tools/firmware/hvmloader/pci.c =A0 =A0 =A0| =A0 14 ++++++++++++++
> =A0tools/firmware/hvmloader/pci_regs.h | =A0 =A02 ++
> =A04 files changed, 47 insertions(+), 4 deletions(-)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:01:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTanO-0007Cl-V2; Thu, 24 Nov 2011 15:01:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1RTanN-0007Ce-Tw
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:01:02 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322146786!58135776!1
X-Originating-IP: [209.85.220.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27198 invoked from network); 24 Nov 2011 14:59:47 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 14:59:47 -0000
Received: by vcbfo1 with SMTP id fo1so3156492vcb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 07:00:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=oWLm1tlufG0BWPBsnBq4bnCntrw2+VJQ5MnXpAxWvOw=;
	b=vO79NLqUNGuTeMB65yLZY/RGCeBNcgE56dgjbUNn6HEBn8pmCPBi+WIZm5PgH6UICy
	4hvVgYc83ifMJ7PyzBTHNxPMUz5RN+SmcdTxaphJHs6IJ+MnF+BdxITM3nYqBK4hpeHN
	+2pvU8vY/ZRBZxrh24QSfpal6Y6guDDvJT/XM=
Received: by 10.52.69.13 with SMTP id a13mr605949vdu.89.1322146829158; Thu, 24
	Nov 2011 07:00:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.180.75 with HTTP; Thu, 24 Nov 2011 07:00:08 -0800 (PST)
In-Reply-To: <1322146424-18738-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1322146424-18738-1-git-send-email-jean.guyader@eu.citrix.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 24 Nov 2011 15:00:08 +0000
Message-ID: <CAEBdQ93csrR9vhskdSonUsBRW+BM0imWnfmrDcH4UawVZJz0=w@mail.gmail.com>
To: Jean Guyader <jean.guyader@eu.citrix.com>
Cc: allen.m.kay@intel.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH] hvmloader: Intel GPU passthrough,
	reverse OpRegion
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The description was slightly wrong, here is a new one:

The Intel GPU uses a two pages NVS region called OpRegion.
In order to get full support for the driver in the guest
we need to map this region.

This patch reserves 2 pages on the top of the memory in the
reserved area and mark this region as NVS in the e820. Then
we write the address to the config space (offset 0xfc) so the
device model can map the OpRegion at this address in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

On 24 November 2011 14:53, Jean Guyader <jean.guyader@eu.citrix.com> wrote:
>
> The Intel GPU uses a two pages NVS region called OpRegion.
> In order to get full support for the driver in the guest
> we need to map this region.
>
> This patch reserves 2 pages on the top of the RAM and
> mark this region as NVS in the e820. Then we write the
> address to the config space (offset 0xfc) so the device
> model can map the OpRegion at this address in the guest.
>
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
> =A0tools/firmware/hvmloader/config.h =A0 | =A0 =A01 +
> =A0tools/firmware/hvmloader/e820.c =A0 =A0 | =A0 34 +++++++++++++++++++++=
+++++++++----
> =A0tools/firmware/hvmloader/pci.c =A0 =A0 =A0| =A0 14 ++++++++++++++
> =A0tools/firmware/hvmloader/pci_regs.h | =A0 =A02 ++
> =A04 files changed, 47 insertions(+), 4 deletions(-)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:25:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:25:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbAa-0007RY-AT; Thu, 24 Nov 2011 15:25:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTbAZ-0007RT-0m
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:24:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322148267!4036888!1
X-Originating-IP: [208.97.132.145]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11163 invoked from network); 24 Nov 2011 15:24:27 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-5.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 15:24:27 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 37BAA45807B;
	Thu, 24 Nov 2011 07:24:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=qvXTiu1KkXfbdGxZ1+ZULLE6t4V98+szBUxDHLC+9h+0
	0DVHMxPFSnlMqemwlT3iC4DnhWwV68f02du360qiWn1f6RMRyZJDrg+5zYTEJzW3
	uF4Y6EFMZOLU1ak/TRrcqlEM5R/LCNCcCrB3bvB6MBUHsvTZk/2jKvvUb9Rt2yA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=n2RaG36BHbUhJV0OF/ZbN6HXBm8=; b=jWlJK4cx
	WOMfhbUyAzhy8ad++KImXmkfE3XkPFsedlBDfynGRzGjuRy6WlML8tGZIrAnpLnu
	xpBiap6R2tzJTldF5I8Z+mq/OYGOpQj/2EnKHz7z4uvklE1VbLxEMZ+FgcKuQZ1E
	xwq615G1r9WPIGRPR++UAxAGh3eIh77VFWA=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 76834458079; 
	Thu, 24 Nov 2011 07:24:25 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 07:24:26 -0800
Message-ID: <93094315832b40f3892a71fa0797016c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4ECE21CB0200007800062EA0@nat28.tlf.novell.com>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
	<4ECE20FF0200007800062E93@nat28.tlf.novell.com>
	<4ECE21CB0200007800062EA0@nat28.tlf.novell.com>
Date: Thu, 24 Nov 2011 07:24:26 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 05 of 14] Don't trigger unnecessary shadow
 scans on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan,
>  >>> On 24.11.11 at 10:48, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>> wrote:
>>> xen/arch/x86/mm/shadow/common.c |  4 ++--
>>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>>
>>> When updating a p2m entry, the hypervisor scans all shadow pte's to
>>> find
>>> mappings of that gfn and tear them down. This is avoided if the page
>>> count
>>> reveals that there are no additional mappings. The current test ignores
>>> the
>>> PGC_allocated flag and its effect on the page count.
>>>
>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>>>
>>> diff -r 93066bdc1e1c -r e8f0709af2b7 xen/arch/x86/mm/shadow/common.c
>>> --- a/xen/arch/x86/mm/shadow/common.c
>>> +++ b/xen/arch/x86/mm/shadow/common.c
>>> @@ -2501,7 +2501,8 @@ int sh_remove_all_mappings(struct vcpu *
>>>          ;
>>>
>>>      perfc_incr(shadow_mappings);
>>> -    if ( (page->count_info & PGC_count_mask) == 0 )
>>> +    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
>>> +    if ( (page->count_info & PGC_count_mask) == expected_count )
>>
>> Is that really valid outside the locked region?
We can move it below to be protected by the lock.

>>
>>>          return 0;
>>>
>>>      /* Although this is an externally visible function, we do not know
>>> @@ -2517,7 +2518,6 @@ int sh_remove_all_mappings(struct vcpu *
>>>      hash_foreach(v, callback_mask, callbacks, gmfn);
>>>
>>>      /* If that didn't catch the mapping, something is very wrong */
>>> -    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
>>
>> This certainly isn't right - iiuc the count would normally have changed
>> during the hash_foreach() above this.

I don't think that's a problem. The expected count is still the same. The
shadow scan callback will not change the PGC_allocated flag in the target
page. Further, the sh_rm_mappings_from_l1 should also be updated. It
breaks out of the loop on a count of zero, but it should also break out on
1 | PGC_allocated.

I'll resend this one.
Andres
>
> Hmm, I was wrong here, you aren't caching the page count. Still, is it
> certain that the state of PGC_allocated doesn't change from where
> you set expected_count now to where it was set before?
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:25:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:25:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbAa-0007RY-AT; Thu, 24 Nov 2011 15:25:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTbAZ-0007RT-0m
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:24:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322148267!4036888!1
X-Originating-IP: [208.97.132.145]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11163 invoked from network); 24 Nov 2011 15:24:27 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-5.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 15:24:27 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 37BAA45807B;
	Thu, 24 Nov 2011 07:24:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=qvXTiu1KkXfbdGxZ1+ZULLE6t4V98+szBUxDHLC+9h+0
	0DVHMxPFSnlMqemwlT3iC4DnhWwV68f02du360qiWn1f6RMRyZJDrg+5zYTEJzW3
	uF4Y6EFMZOLU1ak/TRrcqlEM5R/LCNCcCrB3bvB6MBUHsvTZk/2jKvvUb9Rt2yA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=n2RaG36BHbUhJV0OF/ZbN6HXBm8=; b=jWlJK4cx
	WOMfhbUyAzhy8ad++KImXmkfE3XkPFsedlBDfynGRzGjuRy6WlML8tGZIrAnpLnu
	xpBiap6R2tzJTldF5I8Z+mq/OYGOpQj/2EnKHz7z4uvklE1VbLxEMZ+FgcKuQZ1E
	xwq615G1r9WPIGRPR++UAxAGh3eIh77VFWA=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 76834458079; 
	Thu, 24 Nov 2011 07:24:25 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 07:24:26 -0800
Message-ID: <93094315832b40f3892a71fa0797016c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <4ECE21CB0200007800062EA0@nat28.tlf.novell.com>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
	<4ECE20FF0200007800062E93@nat28.tlf.novell.com>
	<4ECE21CB0200007800062EA0@nat28.tlf.novell.com>
Date: Thu, 24 Nov 2011 07:24:26 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Jan Beulich" <JBeulich@suse.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org,
	xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 05 of 14] Don't trigger unnecessary shadow
 scans on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan,
>  >>> On 24.11.11 at 10:48, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>>> wrote:
>>> xen/arch/x86/mm/shadow/common.c |  4 ++--
>>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>>
>>> When updating a p2m entry, the hypervisor scans all shadow pte's to
>>> find
>>> mappings of that gfn and tear them down. This is avoided if the page
>>> count
>>> reveals that there are no additional mappings. The current test ignores
>>> the
>>> PGC_allocated flag and its effect on the page count.
>>>
>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>>>
>>> diff -r 93066bdc1e1c -r e8f0709af2b7 xen/arch/x86/mm/shadow/common.c
>>> --- a/xen/arch/x86/mm/shadow/common.c
>>> +++ b/xen/arch/x86/mm/shadow/common.c
>>> @@ -2501,7 +2501,8 @@ int sh_remove_all_mappings(struct vcpu *
>>>          ;
>>>
>>>      perfc_incr(shadow_mappings);
>>> -    if ( (page->count_info & PGC_count_mask) == 0 )
>>> +    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
>>> +    if ( (page->count_info & PGC_count_mask) == expected_count )
>>
>> Is that really valid outside the locked region?
We can move it below to be protected by the lock.

>>
>>>          return 0;
>>>
>>>      /* Although this is an externally visible function, we do not know
>>> @@ -2517,7 +2518,6 @@ int sh_remove_all_mappings(struct vcpu *
>>>      hash_foreach(v, callback_mask, callbacks, gmfn);
>>>
>>>      /* If that didn't catch the mapping, something is very wrong */
>>> -    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
>>
>> This certainly isn't right - iiuc the count would normally have changed
>> during the hash_foreach() above this.

I don't think that's a problem. The expected count is still the same. The
shadow scan callback will not change the PGC_allocated flag in the target
page. Further, the sh_rm_mappings_from_l1 should also be updated. It
breaks out of the loop on a count of zero, but it should also break out on
1 | PGC_allocated.

I'll resend this one.
Andres
>
> Hmm, I was wrong here, you aren't caching the page count. Still, is it
> certain that the state of PGC_allocated doesn't change from where
> you set expected_count now to where it was set before?
>
> Jan
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:32:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbGV-0007b0-5B; Thu, 24 Nov 2011 15:31:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTbGS-0007an-QU
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:31:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322148633!4488102!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17222 invoked from network); 24 Nov 2011 15:30:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 15:30:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTbFr-000LHE-Dc; Thu, 24 Nov 2011 15:30:27 +0000
Date: Thu, 24 Nov 2011 15:30:27 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124153027.GH77868@ocelot.phlegethon.org>
References: <patchbomb.1321307321@xdev.gridcentric.ca>
	<764e0872dd4f50c70fbc.1321307326@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <764e0872dd4f50c70fbc.1321307326@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, George.Dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:48 -0500 on 14 Nov (1321289326), Andres Lagar-Cavilla wrote:
> The p2m audit code doesn't even compile, let alone work. It also
> partially supports ept. Make it:
> 
> - compile
> - lay groundwork for eventual ept support
> - move out of the way of all calls and turn it into a domctl. It's
>   obviously not being used by anybody presently.
> - enable it via said domctl

Thanks for looking at this code (which, as you say, had considerably
rotted).  

I'm not sure I'm a big fan of provoking audits from user-space rather
than having them run on every operation; in previous incarnations there
have been serial debug-keys that triggered auditing code (which would
then be run before and after every operation) - I found that much more
helpful in the case of failure, as it pointed to which operation had
caused the problem rather than saying 'something bad happened at somne
point'.

If you really want to keep the hypercall, I think it could probably be
part of the existing paging/shadow control domctl rather than having
its own.  That would have the advantage of preventing an untrusted
domain from calling it on itself (which has in the past turned slightly
bitrotted audit code into a denial-of-service vector!).

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:32:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbGV-0007b0-5B; Thu, 24 Nov 2011 15:31:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTbGS-0007an-QU
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:31:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322148633!4488102!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17222 invoked from network); 24 Nov 2011 15:30:33 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 15:30:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTbFr-000LHE-Dc; Thu, 24 Nov 2011 15:30:27 +0000
Date: Thu, 24 Nov 2011 15:30:27 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124153027.GH77868@ocelot.phlegethon.org>
References: <patchbomb.1321307321@xdev.gridcentric.ca>
	<764e0872dd4f50c70fbc.1321307326@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <764e0872dd4f50c70fbc.1321307326@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, George.Dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:48 -0500 on 14 Nov (1321289326), Andres Lagar-Cavilla wrote:
> The p2m audit code doesn't even compile, let alone work. It also
> partially supports ept. Make it:
> 
> - compile
> - lay groundwork for eventual ept support
> - move out of the way of all calls and turn it into a domctl. It's
>   obviously not being used by anybody presently.
> - enable it via said domctl

Thanks for looking at this code (which, as you say, had considerably
rotted).  

I'm not sure I'm a big fan of provoking audits from user-space rather
than having them run on every operation; in previous incarnations there
have been serial debug-keys that triggered auditing code (which would
then be run before and after every operation) - I found that much more
helpful in the case of failure, as it pointed to which operation had
caused the problem rather than saying 'something bad happened at somne
point'.

If you really want to keep the hypercall, I think it could probably be
part of the existing paging/shadow control domctl rather than having
its own.  That would have the advantage of preventing an untrusted
domain from calling it on itself (which has in the past turned slightly
bitrotted audit code into a denial-of-service vector!).

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:33:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbIF-0007kD-Tj; Thu, 24 Nov 2011 15:32:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTbIE-0007je-Qg
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:32:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322148743!3940402!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26599 invoked from network); 24 Nov 2011 15:32:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 15:32:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTbHi-000LHZ-S6; Thu, 24 Nov 2011 15:32:22 +0000
Date: Thu, 24 Nov 2011 15:32:22 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124153222.GI77868@ocelot.phlegethon.org>
References: <patchbomb.1321307321@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1321307321@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, George.Dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] P2M various fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

At 16:48 -0500 on 14 Nov (1321289321), Andres Lagar-Cavilla wrote:
> This patch series brings about a number of fixes to the p2m code
> in anticipation of synchonizing lookups. Specifically:
> - Four bug fixes on shadow domctls, setting shared p2m entries,
>   and splitting 1GB PoD superpages
> - Rework the p2m audit code. Today it does neither compile nor
>   apply to ept, so make it compile and move it out of the way
>   for most callers, which obviously don't care.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks.  
 - I've applied 1-3; 
 - 4 is a tools patch and needs a tools maintainer's ack; 
 - 5 I commented on separately;
 - 6 depends on 5 and is a tools patch.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:33:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:33:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbIF-0007kD-Tj; Thu, 24 Nov 2011 15:32:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTbIE-0007je-Qg
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:32:55 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322148743!3940402!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26599 invoked from network); 24 Nov 2011 15:32:23 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 15:32:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTbHi-000LHZ-S6; Thu, 24 Nov 2011 15:32:22 +0000
Date: Thu, 24 Nov 2011 15:32:22 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124153222.GI77868@ocelot.phlegethon.org>
References: <patchbomb.1321307321@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1321307321@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, George.Dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] P2M various fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

At 16:48 -0500 on 14 Nov (1321289321), Andres Lagar-Cavilla wrote:
> This patch series brings about a number of fixes to the p2m code
> in anticipation of synchonizing lookups. Specifically:
> - Four bug fixes on shadow domctls, setting shared p2m entries,
>   and splitting 1GB PoD superpages
> - Rework the p2m audit code. Today it does neither compile nor
>   apply to ept, so make it compile and move it out of the way
>   for most callers, which obviously don't care.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks.  
 - I've applied 1-3; 
 - 4 is a tools patch and needs a tools maintainer's ack; 
 - 5 I commented on separately;
 - 6 depends on 5 and is a tools patch.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:39:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbOb-0008G2-0N; Thu, 24 Nov 2011 15:39:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTbOY-0008Fj-R1
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:39:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322149135!5648866!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17216 invoked from network); 24 Nov 2011 15:38:55 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 15:38:55 -0000
Received: by bkbzt12 with SMTP id zt12so4048938bkb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 07:38:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=X4XdZ+GkX8Jo33v0AL+61PAecQ3kelHwcFKihkjRboM=;
	b=fxc30Se6PaX8sWxIihYdZORutdYPXSCZhVNqvZOS2QC3aB1bsysOshjiGgBrE3KhtK
	8n2dpmSozdxCgdHlvyq4mOHxuEjwmkK4/Oar4DvtdEgHAY2OcoL8O8pWsgpZ59/w2I7Q
	YXz16PDLVBRe211LaZ7f7abWoFT8FYFyXtBws=
Received: by 10.204.9.211 with SMTP id m19mr29061782bkm.92.1322149135269;
	Thu, 24 Nov 2011 07:38:55 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id h7sm16116016bkw.12.2011.11.24.07.38.53
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 07:38:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 15:38:50 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CAF4158A.34C1C%keir@xen.org>
Thread-Topic: [PATCH 07 of 14] Trivial fix for rc val in hap track dirty vram
Thread-Index: AcyqvymU2nNPll9r/Ueet790q3q83w==
In-Reply-To: <4ECE237B0200007800062EB5@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 07 of 14] Trivial fix for rc val in hap
	track dirty vram
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 09:59, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
>> xen/arch/x86/mm/hap/hap.c |  2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> 
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> 
>> diff -r e22610ef339a -r 25d27decfdcc xen/arch/x86/mm/hap/hap.c
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -141,7 +141,7 @@ int hap_track_dirty_vram(struct domain *
>>          }
>>          else if ( !paging_mode_log_dirty(d) && !dirty_vram )
>>          {
>> -            rc -ENOMEM;
>> +            rc = -ENOMEM;
>>              if ( (dirty_vram = xmalloc(struct sh_dirty_vram)) == NULL )
>>                  goto param_fail;
>>  
> 
> This would have been caught by the compiler if we weren't forcing
> -Wno-unused-value. Keir, shouldn't we revisit this 5 year old decision
> (c/s 11762:db3d58d30e9d)?

Fine with me to allow the warnings now.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:39:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbOb-0008G2-0N; Thu, 24 Nov 2011 15:39:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTbOY-0008Fj-R1
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:39:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322149135!5648866!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17216 invoked from network); 24 Nov 2011 15:38:55 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 15:38:55 -0000
Received: by bkbzt12 with SMTP id zt12so4048938bkb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 07:38:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=X4XdZ+GkX8Jo33v0AL+61PAecQ3kelHwcFKihkjRboM=;
	b=fxc30Se6PaX8sWxIihYdZORutdYPXSCZhVNqvZOS2QC3aB1bsysOshjiGgBrE3KhtK
	8n2dpmSozdxCgdHlvyq4mOHxuEjwmkK4/Oar4DvtdEgHAY2OcoL8O8pWsgpZ59/w2I7Q
	YXz16PDLVBRe211LaZ7f7abWoFT8FYFyXtBws=
Received: by 10.204.9.211 with SMTP id m19mr29061782bkm.92.1322149135269;
	Thu, 24 Nov 2011 07:38:55 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id h7sm16116016bkw.12.2011.11.24.07.38.53
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 07:38:53 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 15:38:50 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CAF4158A.34C1C%keir@xen.org>
Thread-Topic: [PATCH 07 of 14] Trivial fix for rc val in hap track dirty vram
Thread-Index: AcyqvymU2nNPll9r/Ueet790q3q83w==
In-Reply-To: <4ECE237B0200007800062EB5@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 07 of 14] Trivial fix for rc val in hap
	track dirty vram
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 09:59, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 23.11.11 at 22:11, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
>> xen/arch/x86/mm/hap/hap.c |  2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> 
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> 
>> diff -r e22610ef339a -r 25d27decfdcc xen/arch/x86/mm/hap/hap.c
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -141,7 +141,7 @@ int hap_track_dirty_vram(struct domain *
>>          }
>>          else if ( !paging_mode_log_dirty(d) && !dirty_vram )
>>          {
>> -            rc -ENOMEM;
>> +            rc = -ENOMEM;
>>              if ( (dirty_vram = xmalloc(struct sh_dirty_vram)) == NULL )
>>                  goto param_fail;
>>  
> 
> This would have been caught by the compiler if we weren't forcing
> -Wno-unused-value. Keir, shouldn't we revisit this 5 year old decision
> (c/s 11762:db3d58d30e9d)?

Fine with me to allow the warnings now.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:47:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:47:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbVv-0008QZ-2g; Thu, 24 Nov 2011 15:47:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbVt-0008QU-Vx
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:47:02 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322149589!4862358!1
X-Originating-IP: [134.134.136.24]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22482 invoked from network); 24 Nov 2011 15:46:30 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-216.messagelabs.com with SMTP;
	24 Nov 2011 15:46:30 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 24 Nov 2011 07:46:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="79661159"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 24 Nov 2011 07:46:28 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:46:09 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 24 Nov 2011 23:46:08 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Thu, 24 Nov 2011 23:46:07 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:46:06 +0800
Thread-Topic: [PATCH 0/6] X86 new features expose and PCID/INVPCID
Thread-Index: AcyqwC3b45qLy8wGRMmKCNIXVisVgw==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7A@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/6] X86 new features expose and PCID/INVPCID
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These patches expose 6 X86 new features to dom0/pv/hvm guest, and implement PCID/INVPCID for hap hvm.

Intel recently add 6 X86 new features, refer to http://software.intel.com/file/36945
Patch 1/2 are to expose these new features to dom0, pv, and hvm.

Intel also add a new instruction INVPCID to invalidate TLB. Refer latest Intel SDM http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
Patch 3/4 are to disable PCID/INVPCID for dom0 and pv. Exposing them into dom0 and pv may result in performance regression, and it would trigger GP or UD depending on whether platform suppport INVPCID or not.
Patch 5/6 are to handle PCID/INVPCID for hvm: For hap hvm, we enable PCID/INVPCID, since no need to intercept INVPCID, and we just set INVPCID non-root behavior as running natively; For shadow hvm, we disable PCID/INVPCID, otherwise we need to emulate INVPCID at vmm by setting INVPCID non-root behavior as vmexit.

Thanks,
Jinsong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:47:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:47:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbVv-0008QZ-2g; Thu, 24 Nov 2011 15:47:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbVt-0008QU-Vx
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:47:02 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322149589!4862358!1
X-Originating-IP: [134.134.136.24]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22482 invoked from network); 24 Nov 2011 15:46:30 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-13.tower-216.messagelabs.com with SMTP;
	24 Nov 2011 15:46:30 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 24 Nov 2011 07:46:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="79661159"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 24 Nov 2011 07:46:28 -0800
Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:46:09 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 24 Nov 2011 23:46:08 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Thu, 24 Nov 2011 23:46:07 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:46:06 +0800
Thread-Topic: [PATCH 0/6] X86 new features expose and PCID/INVPCID
Thread-Index: AcyqwC3b45qLy8wGRMmKCNIXVisVgw==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7A@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/6] X86 new features expose and PCID/INVPCID
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These patches expose 6 X86 new features to dom0/pv/hvm guest, and implement PCID/INVPCID for hap hvm.

Intel recently add 6 X86 new features, refer to http://software.intel.com/file/36945
Patch 1/2 are to expose these new features to dom0, pv, and hvm.

Intel also add a new instruction INVPCID to invalidate TLB. Refer latest Intel SDM http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
Patch 3/4 are to disable PCID/INVPCID for dom0 and pv. Exposing them into dom0 and pv may result in performance regression, and it would trigger GP or UD depending on whether platform suppport INVPCID or not.
Patch 5/6 are to handle PCID/INVPCID for hvm: For hap hvm, we enable PCID/INVPCID, since no need to intercept INVPCID, and we just set INVPCID non-root behavior as running natively; For shadow hvm, we disable PCID/INVPCID, otherwise we need to emulate INVPCID at vmm by setting INVPCID non-root behavior as vmexit.

Thanks,
Jinsong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:51:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:51:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbZp-000077-Qo; Thu, 24 Nov 2011 15:51:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbZn-00006s-Po
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:51:04 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322149827!4489474!1
X-Originating-IP: [143.182.124.37]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28998 invoked from network); 24 Nov 2011 15:50:31 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-3.tower-182.messagelabs.com with SMTP;
	24 Nov 2011 15:50:31 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 24 Nov 2011 07:50:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.69,565,1315206000"; d="scan'208";a="40891119"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Nov 2011 07:50:25 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:50:08 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:50:08 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Thu, 24 Nov 2011 23:50:06 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:50:05 +0800
Thread-Topic: [PATCH 1/6] X86: expose Intel new features to pv/hvm
Thread-Index: AcyqwLw8fwXuntSETACxT0XIwpd5pA==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7B@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Bshsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/6] X86: expose Intel new features to pv/hvm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Bshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: expose Intel new features to pv/hvm

Intel recently release some new features, including FMA/AVX2/BMI1/BMI2/LZCN=
T/MOVBE.
Refer to http://software.intel.com/file/36945
This patch expose these new features to pv and hvm.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

# HG changeset patch
# Parent 4815be3af73cd22d8225754ef5fff0ca03759ad7

diff -r 4815be3af73c tools/libxc/xc_cpufeature.h
--- a/tools/libxc/xc_cpufeature.h	Thu Sep 15 15:26:07 2011 +0100
+++ b/tools/libxc/xc_cpufeature.h	Thu Nov 17 17:54:17 2011 +0800
@@ -74,6 +74,7 @@
 #define X86_FEATURE_TM2          8 /* Thermal Monitor 2 */
 #define X86_FEATURE_SSSE3        9 /* Supplemental Streaming SIMD Exts-3 *=
/
 #define X86_FEATURE_CID         10 /* Context ID */
+#define X86_FEATURE_FMA         12 /* Fused Multiply Add */
 #define X86_FEATURE_CX16        13 /* CMPXCHG16B */
 #define X86_FEATURE_XTPR        14 /* Send Task Priority Messages */
 #define X86_FEATURE_PDCM        15 /* Perf/Debug Capability MSR */
@@ -81,6 +82,7 @@
 #define X86_FEATURE_SSE4_1      19 /* Streaming SIMD Extensions 4.1 */
 #define X86_FEATURE_SSE4_2      20 /* Streaming SIMD Extensions 4.2 */
 #define X86_FEATURE_X2APIC      21 /* x2APIC */
+#define X86_FEATURE_MOVBE       22 /* movbe instruction */
 #define X86_FEATURE_POPCNT      23 /* POPCNT instruction */
 #define X86_FEATURE_TSC_DEADLINE 24 /* "tdt" TSC Deadline Timer */
 #define X86_FEATURE_AES         25 /* AES acceleration instructions */
@@ -125,7 +127,10 @@
=20
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx) */
 #define X86_FEATURE_FSGSBASE     0 /* {RD,WR}{FS,GS}BASE instructions */
+#define X86_FEATURE_BMI1         3 /* 1st group bit manipulation extension=
s */
+#define X86_FEATURE_AVX2         5 /* AVX2 instructions */
 #define X86_FEATURE_SMEP         7 /* Supervisor Mode Execution Protection=
 */
+#define X86_FEATURE_BMI2         8 /* 2nd group bit manipulation extension=
s */
 #define X86_FEATURE_ERMS         9 /* Enhanced REP MOVSB/STOSB */
=20
 #endif /* __LIBXC_CPUFEATURE_H */
diff -r 4815be3af73c tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Sep 15 15:26:07 2011 +0100
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Nov 17 17:54:17 2011 +0800
@@ -196,7 +196,8 @@ static void intel_xc_cpuid_policy(
         int is_64bit =3D hypervisor_is_64bit(xch) && is_pae;
=20
         /* Only a few features are advertised in Intel's 0x80000001. */
-        regs[2] &=3D (is_64bit ? bitmaskof(X86_FEATURE_LAHF_LM) : 0);
+        regs[2] &=3D (is_64bit ? bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
+                               bitmaskof(X86_FEATURE_ABM);
         regs[3] &=3D ((is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
                     (is_64bit ? bitmaskof(X86_FEATURE_SYSCALL) : 0) |
@@ -308,9 +309,11 @@ static void xc_cpuid_hvm_policy(
         regs[2] &=3D (bitmaskof(X86_FEATURE_XMM3) |
                     bitmaskof(X86_FEATURE_PCLMULQDQ) |
                     bitmaskof(X86_FEATURE_SSSE3) |
+                    bitmaskof(X86_FEATURE_FMA) |
                     bitmaskof(X86_FEATURE_CX16) |
                     bitmaskof(X86_FEATURE_SSE4_1) |
                     bitmaskof(X86_FEATURE_SSE4_2) |
+                    bitmaskof(X86_FEATURE_MOVBE)  |
                     bitmaskof(X86_FEATURE_POPCNT) |
                     bitmaskof(X86_FEATURE_AES) |
                     bitmaskof(X86_FEATURE_F16C) |
@@ -355,7 +358,10 @@ static void xc_cpuid_hvm_policy(
=20
     case 0x00000007: /* Intel-defined CPU features */
         if ( input[1] =3D=3D 0 ) {
-            regs[1] &=3D (bitmaskof(X86_FEATURE_SMEP) |
+            regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+                        bitmaskof(X86_FEATURE_AVX2) |
+                        bitmaskof(X86_FEATURE_SMEP) |
+                        bitmaskof(X86_FEATURE_BMI2) |
                         bitmaskof(X86_FEATURE_ERMS) |
                         bitmaskof(X86_FEATURE_FSGSBASE));
         } else
@@ -481,8 +487,11 @@ static void xc_cpuid_pv_policy(
=20
     case 0x00000007:
         if ( input[1] =3D=3D 0 )
-            regs[1] &=3D (bitmaskof(X86_FEATURE_FSGSBASE) |
-                        bitmaskof(X86_FEATURE_ERMS));
+            regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+                        bitmaskof(X86_FEATURE_AVX2) |
+                        bitmaskof(X86_FEATURE_BMI2) |
+                        bitmaskof(X86_FEATURE_ERMS) |
+                        bitmaskof(X86_FEATURE_FSGSBASE));
         else
             regs[1] =3D 0;
         regs[0] =3D regs[2] =3D regs[3] =3D 0;=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Bshsmsx502ccrc_
Content-Type: application/octet-stream;
	name="1_new_cpuid_expose_pv_hvm.patch"
Content-Description: 1_new_cpuid_expose_pv_hvm.patch
Content-Disposition: attachment; filename="1_new_cpuid_expose_pv_hvm.patch";
	size=4550; creation-date="Thu, 24 Nov 2011 23:28:02 GMT";
	modification-date="Thu, 24 Nov 2011 22:10:24 GMT"
Content-Transfer-Encoding: base64

WDg2OiBleHBvc2UgSW50ZWwgbmV3IGZlYXR1cmVzIHRvIHB2L2h2bQoKSW50ZWwgcmVjZW50bHkg
cmVsZWFzZSBzb21lIG5ldyBmZWF0dXJlcywgaW5jbHVkaW5nIEZNQS9BVlgyL0JNSTEvQk1JMi9M
WkNOVC9NT1ZCRS4KUmVmZXIgdG8gaHR0cDovL3NvZnR3YXJlLmludGVsLmNvbS9maWxlLzM2OTQ1
ClRoaXMgcGF0Y2ggZXhwb3NlIHRoZXNlIG5ldyBmZWF0dXJlcyB0byBwdiBhbmQgaHZtLgoKU2ln
bmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgojIEhHIGNo
YW5nZXNldCBwYXRjaAojIFBhcmVudCA0ODE1YmUzYWY3M2NkMjJkODIyNTc1NGVmNWZmZjBjYTAz
NzU5YWQ3CgpkaWZmIC1yIDQ4MTViZTNhZjczYyB0b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgK
LS0tIGEvdG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCVRodSBTZXAgMTUgMTU6MjY6MDcgMjAx
MSArMDEwMAorKysgYi90b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgJVGh1IE5vdiAxNyAxNzo1
NDoxNyAyMDExICswODAwCkBAIC03NCw2ICs3NCw3IEBACiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1RN
MiAgICAgICAgICA4IC8qIFRoZXJtYWwgTW9uaXRvciAyICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJF
X1NTU0UzICAgICAgICA5IC8qIFN1cHBsZW1lbnRhbCBTdHJlYW1pbmcgU0lNRCBFeHRzLTMgKi8K
ICNkZWZpbmUgWDg2X0ZFQVRVUkVfQ0lEICAgICAgICAgMTAgLyogQ29udGV4dCBJRCAqLworI2Rl
ZmluZSBYODZfRkVBVFVSRV9GTUEgICAgICAgICAxMiAvKiBGdXNlZCBNdWx0aXBseSBBZGQgKi8K
ICNkZWZpbmUgWDg2X0ZFQVRVUkVfQ1gxNiAgICAgICAgMTMgLyogQ01QWENIRzE2QiAqLwogI2Rl
ZmluZSBYODZfRkVBVFVSRV9YVFBSICAgICAgICAxNCAvKiBTZW5kIFRhc2sgUHJpb3JpdHkgTWVz
c2FnZXMgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfUERDTSAgICAgICAgMTUgLyogUGVyZi9EZWJ1
ZyBDYXBhYmlsaXR5IE1TUiAqLwpAQCAtODEsNiArODIsNyBAQAogI2RlZmluZSBYODZfRkVBVFVS
RV9TU0U0XzEgICAgICAxOSAvKiBTdHJlYW1pbmcgU0lNRCBFeHRlbnNpb25zIDQuMSAqLwogI2Rl
ZmluZSBYODZfRkVBVFVSRV9TU0U0XzIgICAgICAyMCAvKiBTdHJlYW1pbmcgU0lNRCBFeHRlbnNp
b25zIDQuMiAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9YMkFQSUMgICAgICAyMSAvKiB4MkFQSUMg
Ki8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfTU9WQkUgICAgICAgMjIgLyogbW92YmUgaW5zdHJ1Y3Rp
b24gKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfUE9QQ05UICAgICAgMjMgLyogUE9QQ05UIGluc3Ry
dWN0aW9uICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1RTQ19ERUFETElORSAyNCAvKiAidGR0IiBU
U0MgRGVhZGxpbmUgVGltZXIgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfQUVTICAgICAgICAgMjUg
LyogQUVTIGFjY2VsZXJhdGlvbiBpbnN0cnVjdGlvbnMgKi8KQEAgLTEyNSw3ICsxMjcsMTAgQEAK
IAogLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMsIENQVUlEIGxldmVsIDB4MDAwMDAwMDc6
MCAoZWJ4KSAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9GU0dTQkFTRSAgICAgMCAvKiB7UkQsV1J9
e0ZTLEdTfUJBU0UgaW5zdHJ1Y3Rpb25zICovCisjZGVmaW5lIFg4Nl9GRUFUVVJFX0JNSTEgICAg
ICAgICAzIC8qIDFzdCBncm91cCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KKyNkZWZp
bmUgWDg2X0ZFQVRVUkVfQVZYMiAgICAgICAgIDUgLyogQVZYMiBpbnN0cnVjdGlvbnMgKi8KICNk
ZWZpbmUgWDg2X0ZFQVRVUkVfU01FUCAgICAgICAgIDcgLyogU3VwZXJ2aXNvciBNb2RlIEV4ZWN1
dGlvbiBQcm90ZWN0aW9uICovCisjZGVmaW5lIFg4Nl9GRUFUVVJFX0JNSTIgICAgICAgICA4IC8q
IDJuZCBncm91cCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KICNkZWZpbmUgWDg2X0ZF
QVRVUkVfRVJNUyAgICAgICAgIDkgLyogRW5oYW5jZWQgUkVQIE1PVlNCL1NUT1NCICovCiAKICNl
bmRpZiAvKiBfX0xJQlhDX0NQVUZFQVRVUkVfSCAqLwpkaWZmIC1yIDQ4MTViZTNhZjczYyB0b29s
cy9saWJ4Yy94Y19jcHVpZF94ODYuYwotLS0gYS90b29scy9saWJ4Yy94Y19jcHVpZF94ODYuYwlU
aHUgU2VwIDE1IDE1OjI2OjA3IDIwMTEgKzAxMDAKKysrIGIvdG9vbHMvbGlieGMveGNfY3B1aWRf
eDg2LmMJVGh1IE5vdiAxNyAxNzo1NDoxNyAyMDExICswODAwCkBAIC0xOTYsNyArMTk2LDggQEAg
c3RhdGljIHZvaWQgaW50ZWxfeGNfY3B1aWRfcG9saWN5KAogICAgICAgICBpbnQgaXNfNjRiaXQg
PSBoeXBlcnZpc29yX2lzXzY0Yml0KHhjaCkgJiYgaXNfcGFlOwogCiAgICAgICAgIC8qIE9ubHkg
YSBmZXcgZmVhdHVyZXMgYXJlIGFkdmVydGlzZWQgaW4gSW50ZWwncyAweDgwMDAwMDAxLiAqLwot
ICAgICAgICByZWdzWzJdICY9IChpc182NGJpdCA/IGJpdG1hc2tvZihYODZfRkVBVFVSRV9MQUhG
X0xNKSA6IDApOworICAgICAgICByZWdzWzJdICY9IChpc182NGJpdCA/IGJpdG1hc2tvZihYODZf
RkVBVFVSRV9MQUhGX0xNKSA6IDApIHwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBi
aXRtYXNrb2YoWDg2X0ZFQVRVUkVfQUJNKTsKICAgICAgICAgcmVnc1szXSAmPSAoKGlzX3BhZSA/
IGJpdG1hc2tvZihYODZfRkVBVFVSRV9OWCkgOiAwKSB8CiAgICAgICAgICAgICAgICAgICAgIChp
c182NGJpdCA/IGJpdG1hc2tvZihYODZfRkVBVFVSRV9MTSkgOiAwKSB8CiAgICAgICAgICAgICAg
ICAgICAgIChpc182NGJpdCA/IGJpdG1hc2tvZihYODZfRkVBVFVSRV9TWVNDQUxMKSA6IDApIHwK
QEAgLTMwOCw5ICszMDksMTEgQEAgc3RhdGljIHZvaWQgeGNfY3B1aWRfaHZtX3BvbGljeSgKICAg
ICAgICAgcmVnc1syXSAmPSAoYml0bWFza29mKFg4Nl9GRUFUVVJFX1hNTTMpIHwKICAgICAgICAg
ICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX1BDTE1VTFFEUSkgfAogICAgICAgICAg
ICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfU1NTRTMpIHwKKyAgICAgICAgICAgICAg
ICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0ZNQSkgfAogICAgICAgICAgICAgICAgICAgICBi
aXRtYXNrb2YoWDg2X0ZFQVRVUkVfQ1gxNikgfAogICAgICAgICAgICAgICAgICAgICBiaXRtYXNr
b2YoWDg2X0ZFQVRVUkVfU1NFNF8xKSB8CiAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihY
ODZfRkVBVFVSRV9TU0U0XzIpIHwKKyAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9G
RUFUVVJFX01PVkJFKSAgfAogICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRV
UkVfUE9QQ05UKSB8CiAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9B
RVMpIHwKICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0YxNkMpIHwK
QEAgLTM1NSw3ICszNTgsMTAgQEAgc3RhdGljIHZvaWQgeGNfY3B1aWRfaHZtX3BvbGljeSgKIAog
ICAgIGNhc2UgMHgwMDAwMDAwNzogLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMgKi8KICAg
ICAgICAgaWYgKCBpbnB1dFsxXSA9PSAwICkgewotICAgICAgICAgICAgcmVnc1sxXSAmPSAoYml0
bWFza29mKFg4Nl9GRUFUVVJFX1NNRVApIHwKKyAgICAgICAgICAgIHJlZ3NbMV0gJj0gKGJpdG1h
c2tvZihYODZfRkVBVFVSRV9CTUkxKSB8CisgICAgICAgICAgICAgICAgICAgICAgICBiaXRtYXNr
b2YoWDg2X0ZFQVRVUkVfQVZYMikgfAorICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFza29m
KFg4Nl9GRUFUVVJFX1NNRVApIHwKKyAgICAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihY
ODZfRkVBVFVSRV9CTUkyKSB8CiAgICAgICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2
X0ZFQVRVUkVfRVJNUykgfAogICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9G
RUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIH0gZWxzZQpAQCAtNDgxLDggKzQ4NywxMSBAQCBz
dGF0aWMgdm9pZCB4Y19jcHVpZF9wdl9wb2xpY3koCiAKICAgICBjYXNlIDB4MDAwMDAwMDc6CiAg
ICAgICAgIGlmICggaW5wdXRbMV0gPT0gMCApCi0gICAgICAgICAgICByZWdzWzFdICY9IChiaXRt
YXNrb2YoWDg2X0ZFQVRVUkVfRlNHU0JBU0UpIHwKLSAgICAgICAgICAgICAgICAgICAgICAgIGJp
dG1hc2tvZihYODZfRkVBVFVSRV9FUk1TKSk7CisgICAgICAgICAgICByZWdzWzFdICY9IChiaXRt
YXNrb2YoWDg2X0ZFQVRVUkVfQk1JMSkgfAorICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFz
a29mKFg4Nl9GRUFUVVJFX0FWWDIpIHwKKyAgICAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tv
ZihYODZfRkVBVFVSRV9CTUkyKSB8CisgICAgICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2Yo
WDg2X0ZFQVRVUkVfRVJNUykgfAorICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4
Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIHJlZ3NbMV0g
PSAwOwogICAgICAgICByZWdzWzBdID0gcmVnc1syXSA9IHJlZ3NbM10gPSAwOwo=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Bshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Bshsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:51:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:51:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbZp-000077-Qo; Thu, 24 Nov 2011 15:51:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbZn-00006s-Po
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:51:04 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322149827!4489474!1
X-Originating-IP: [143.182.124.37]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28998 invoked from network); 24 Nov 2011 15:50:31 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-3.tower-182.messagelabs.com with SMTP;
	24 Nov 2011 15:50:31 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 24 Nov 2011 07:50:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.69,565,1315206000"; d="scan'208";a="40891119"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Nov 2011 07:50:25 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:50:08 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:50:08 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Thu, 24 Nov 2011 23:50:06 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:50:05 +0800
Thread-Topic: [PATCH 1/6] X86: expose Intel new features to pv/hvm
Thread-Index: AcyqwLw8fwXuntSETACxT0XIwpd5pA==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7B@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Bshsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/6] X86: expose Intel new features to pv/hvm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Bshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: expose Intel new features to pv/hvm

Intel recently release some new features, including FMA/AVX2/BMI1/BMI2/LZCN=
T/MOVBE.
Refer to http://software.intel.com/file/36945
This patch expose these new features to pv and hvm.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

# HG changeset patch
# Parent 4815be3af73cd22d8225754ef5fff0ca03759ad7

diff -r 4815be3af73c tools/libxc/xc_cpufeature.h
--- a/tools/libxc/xc_cpufeature.h	Thu Sep 15 15:26:07 2011 +0100
+++ b/tools/libxc/xc_cpufeature.h	Thu Nov 17 17:54:17 2011 +0800
@@ -74,6 +74,7 @@
 #define X86_FEATURE_TM2          8 /* Thermal Monitor 2 */
 #define X86_FEATURE_SSSE3        9 /* Supplemental Streaming SIMD Exts-3 *=
/
 #define X86_FEATURE_CID         10 /* Context ID */
+#define X86_FEATURE_FMA         12 /* Fused Multiply Add */
 #define X86_FEATURE_CX16        13 /* CMPXCHG16B */
 #define X86_FEATURE_XTPR        14 /* Send Task Priority Messages */
 #define X86_FEATURE_PDCM        15 /* Perf/Debug Capability MSR */
@@ -81,6 +82,7 @@
 #define X86_FEATURE_SSE4_1      19 /* Streaming SIMD Extensions 4.1 */
 #define X86_FEATURE_SSE4_2      20 /* Streaming SIMD Extensions 4.2 */
 #define X86_FEATURE_X2APIC      21 /* x2APIC */
+#define X86_FEATURE_MOVBE       22 /* movbe instruction */
 #define X86_FEATURE_POPCNT      23 /* POPCNT instruction */
 #define X86_FEATURE_TSC_DEADLINE 24 /* "tdt" TSC Deadline Timer */
 #define X86_FEATURE_AES         25 /* AES acceleration instructions */
@@ -125,7 +127,10 @@
=20
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx) */
 #define X86_FEATURE_FSGSBASE     0 /* {RD,WR}{FS,GS}BASE instructions */
+#define X86_FEATURE_BMI1         3 /* 1st group bit manipulation extension=
s */
+#define X86_FEATURE_AVX2         5 /* AVX2 instructions */
 #define X86_FEATURE_SMEP         7 /* Supervisor Mode Execution Protection=
 */
+#define X86_FEATURE_BMI2         8 /* 2nd group bit manipulation extension=
s */
 #define X86_FEATURE_ERMS         9 /* Enhanced REP MOVSB/STOSB */
=20
 #endif /* __LIBXC_CPUFEATURE_H */
diff -r 4815be3af73c tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Sep 15 15:26:07 2011 +0100
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Nov 17 17:54:17 2011 +0800
@@ -196,7 +196,8 @@ static void intel_xc_cpuid_policy(
         int is_64bit =3D hypervisor_is_64bit(xch) && is_pae;
=20
         /* Only a few features are advertised in Intel's 0x80000001. */
-        regs[2] &=3D (is_64bit ? bitmaskof(X86_FEATURE_LAHF_LM) : 0);
+        regs[2] &=3D (is_64bit ? bitmaskof(X86_FEATURE_LAHF_LM) : 0) |
+                               bitmaskof(X86_FEATURE_ABM);
         regs[3] &=3D ((is_pae ? bitmaskof(X86_FEATURE_NX) : 0) |
                     (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) |
                     (is_64bit ? bitmaskof(X86_FEATURE_SYSCALL) : 0) |
@@ -308,9 +309,11 @@ static void xc_cpuid_hvm_policy(
         regs[2] &=3D (bitmaskof(X86_FEATURE_XMM3) |
                     bitmaskof(X86_FEATURE_PCLMULQDQ) |
                     bitmaskof(X86_FEATURE_SSSE3) |
+                    bitmaskof(X86_FEATURE_FMA) |
                     bitmaskof(X86_FEATURE_CX16) |
                     bitmaskof(X86_FEATURE_SSE4_1) |
                     bitmaskof(X86_FEATURE_SSE4_2) |
+                    bitmaskof(X86_FEATURE_MOVBE)  |
                     bitmaskof(X86_FEATURE_POPCNT) |
                     bitmaskof(X86_FEATURE_AES) |
                     bitmaskof(X86_FEATURE_F16C) |
@@ -355,7 +358,10 @@ static void xc_cpuid_hvm_policy(
=20
     case 0x00000007: /* Intel-defined CPU features */
         if ( input[1] =3D=3D 0 ) {
-            regs[1] &=3D (bitmaskof(X86_FEATURE_SMEP) |
+            regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+                        bitmaskof(X86_FEATURE_AVX2) |
+                        bitmaskof(X86_FEATURE_SMEP) |
+                        bitmaskof(X86_FEATURE_BMI2) |
                         bitmaskof(X86_FEATURE_ERMS) |
                         bitmaskof(X86_FEATURE_FSGSBASE));
         } else
@@ -481,8 +487,11 @@ static void xc_cpuid_pv_policy(
=20
     case 0x00000007:
         if ( input[1] =3D=3D 0 )
-            regs[1] &=3D (bitmaskof(X86_FEATURE_FSGSBASE) |
-                        bitmaskof(X86_FEATURE_ERMS));
+            regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+                        bitmaskof(X86_FEATURE_AVX2) |
+                        bitmaskof(X86_FEATURE_BMI2) |
+                        bitmaskof(X86_FEATURE_ERMS) |
+                        bitmaskof(X86_FEATURE_FSGSBASE));
         else
             regs[1] =3D 0;
         regs[0] =3D regs[2] =3D regs[3] =3D 0;=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Bshsmsx502ccrc_
Content-Type: application/octet-stream;
	name="1_new_cpuid_expose_pv_hvm.patch"
Content-Description: 1_new_cpuid_expose_pv_hvm.patch
Content-Disposition: attachment; filename="1_new_cpuid_expose_pv_hvm.patch";
	size=4550; creation-date="Thu, 24 Nov 2011 23:28:02 GMT";
	modification-date="Thu, 24 Nov 2011 22:10:24 GMT"
Content-Transfer-Encoding: base64

WDg2OiBleHBvc2UgSW50ZWwgbmV3IGZlYXR1cmVzIHRvIHB2L2h2bQoKSW50ZWwgcmVjZW50bHkg
cmVsZWFzZSBzb21lIG5ldyBmZWF0dXJlcywgaW5jbHVkaW5nIEZNQS9BVlgyL0JNSTEvQk1JMi9M
WkNOVC9NT1ZCRS4KUmVmZXIgdG8gaHR0cDovL3NvZnR3YXJlLmludGVsLmNvbS9maWxlLzM2OTQ1
ClRoaXMgcGF0Y2ggZXhwb3NlIHRoZXNlIG5ldyBmZWF0dXJlcyB0byBwdiBhbmQgaHZtLgoKU2ln
bmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgojIEhHIGNo
YW5nZXNldCBwYXRjaAojIFBhcmVudCA0ODE1YmUzYWY3M2NkMjJkODIyNTc1NGVmNWZmZjBjYTAz
NzU5YWQ3CgpkaWZmIC1yIDQ4MTViZTNhZjczYyB0b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgK
LS0tIGEvdG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCVRodSBTZXAgMTUgMTU6MjY6MDcgMjAx
MSArMDEwMAorKysgYi90b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgJVGh1IE5vdiAxNyAxNzo1
NDoxNyAyMDExICswODAwCkBAIC03NCw2ICs3NCw3IEBACiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1RN
MiAgICAgICAgICA4IC8qIFRoZXJtYWwgTW9uaXRvciAyICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJF
X1NTU0UzICAgICAgICA5IC8qIFN1cHBsZW1lbnRhbCBTdHJlYW1pbmcgU0lNRCBFeHRzLTMgKi8K
ICNkZWZpbmUgWDg2X0ZFQVRVUkVfQ0lEICAgICAgICAgMTAgLyogQ29udGV4dCBJRCAqLworI2Rl
ZmluZSBYODZfRkVBVFVSRV9GTUEgICAgICAgICAxMiAvKiBGdXNlZCBNdWx0aXBseSBBZGQgKi8K
ICNkZWZpbmUgWDg2X0ZFQVRVUkVfQ1gxNiAgICAgICAgMTMgLyogQ01QWENIRzE2QiAqLwogI2Rl
ZmluZSBYODZfRkVBVFVSRV9YVFBSICAgICAgICAxNCAvKiBTZW5kIFRhc2sgUHJpb3JpdHkgTWVz
c2FnZXMgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfUERDTSAgICAgICAgMTUgLyogUGVyZi9EZWJ1
ZyBDYXBhYmlsaXR5IE1TUiAqLwpAQCAtODEsNiArODIsNyBAQAogI2RlZmluZSBYODZfRkVBVFVS
RV9TU0U0XzEgICAgICAxOSAvKiBTdHJlYW1pbmcgU0lNRCBFeHRlbnNpb25zIDQuMSAqLwogI2Rl
ZmluZSBYODZfRkVBVFVSRV9TU0U0XzIgICAgICAyMCAvKiBTdHJlYW1pbmcgU0lNRCBFeHRlbnNp
b25zIDQuMiAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9YMkFQSUMgICAgICAyMSAvKiB4MkFQSUMg
Ki8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfTU9WQkUgICAgICAgMjIgLyogbW92YmUgaW5zdHJ1Y3Rp
b24gKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfUE9QQ05UICAgICAgMjMgLyogUE9QQ05UIGluc3Ry
dWN0aW9uICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1RTQ19ERUFETElORSAyNCAvKiAidGR0IiBU
U0MgRGVhZGxpbmUgVGltZXIgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfQUVTICAgICAgICAgMjUg
LyogQUVTIGFjY2VsZXJhdGlvbiBpbnN0cnVjdGlvbnMgKi8KQEAgLTEyNSw3ICsxMjcsMTAgQEAK
IAogLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMsIENQVUlEIGxldmVsIDB4MDAwMDAwMDc6
MCAoZWJ4KSAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9GU0dTQkFTRSAgICAgMCAvKiB7UkQsV1J9
e0ZTLEdTfUJBU0UgaW5zdHJ1Y3Rpb25zICovCisjZGVmaW5lIFg4Nl9GRUFUVVJFX0JNSTEgICAg
ICAgICAzIC8qIDFzdCBncm91cCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KKyNkZWZp
bmUgWDg2X0ZFQVRVUkVfQVZYMiAgICAgICAgIDUgLyogQVZYMiBpbnN0cnVjdGlvbnMgKi8KICNk
ZWZpbmUgWDg2X0ZFQVRVUkVfU01FUCAgICAgICAgIDcgLyogU3VwZXJ2aXNvciBNb2RlIEV4ZWN1
dGlvbiBQcm90ZWN0aW9uICovCisjZGVmaW5lIFg4Nl9GRUFUVVJFX0JNSTIgICAgICAgICA4IC8q
IDJuZCBncm91cCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KICNkZWZpbmUgWDg2X0ZF
QVRVUkVfRVJNUyAgICAgICAgIDkgLyogRW5oYW5jZWQgUkVQIE1PVlNCL1NUT1NCICovCiAKICNl
bmRpZiAvKiBfX0xJQlhDX0NQVUZFQVRVUkVfSCAqLwpkaWZmIC1yIDQ4MTViZTNhZjczYyB0b29s
cy9saWJ4Yy94Y19jcHVpZF94ODYuYwotLS0gYS90b29scy9saWJ4Yy94Y19jcHVpZF94ODYuYwlU
aHUgU2VwIDE1IDE1OjI2OjA3IDIwMTEgKzAxMDAKKysrIGIvdG9vbHMvbGlieGMveGNfY3B1aWRf
eDg2LmMJVGh1IE5vdiAxNyAxNzo1NDoxNyAyMDExICswODAwCkBAIC0xOTYsNyArMTk2LDggQEAg
c3RhdGljIHZvaWQgaW50ZWxfeGNfY3B1aWRfcG9saWN5KAogICAgICAgICBpbnQgaXNfNjRiaXQg
PSBoeXBlcnZpc29yX2lzXzY0Yml0KHhjaCkgJiYgaXNfcGFlOwogCiAgICAgICAgIC8qIE9ubHkg
YSBmZXcgZmVhdHVyZXMgYXJlIGFkdmVydGlzZWQgaW4gSW50ZWwncyAweDgwMDAwMDAxLiAqLwot
ICAgICAgICByZWdzWzJdICY9IChpc182NGJpdCA/IGJpdG1hc2tvZihYODZfRkVBVFVSRV9MQUhG
X0xNKSA6IDApOworICAgICAgICByZWdzWzJdICY9IChpc182NGJpdCA/IGJpdG1hc2tvZihYODZf
RkVBVFVSRV9MQUhGX0xNKSA6IDApIHwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBi
aXRtYXNrb2YoWDg2X0ZFQVRVUkVfQUJNKTsKICAgICAgICAgcmVnc1szXSAmPSAoKGlzX3BhZSA/
IGJpdG1hc2tvZihYODZfRkVBVFVSRV9OWCkgOiAwKSB8CiAgICAgICAgICAgICAgICAgICAgIChp
c182NGJpdCA/IGJpdG1hc2tvZihYODZfRkVBVFVSRV9MTSkgOiAwKSB8CiAgICAgICAgICAgICAg
ICAgICAgIChpc182NGJpdCA/IGJpdG1hc2tvZihYODZfRkVBVFVSRV9TWVNDQUxMKSA6IDApIHwK
QEAgLTMwOCw5ICszMDksMTEgQEAgc3RhdGljIHZvaWQgeGNfY3B1aWRfaHZtX3BvbGljeSgKICAg
ICAgICAgcmVnc1syXSAmPSAoYml0bWFza29mKFg4Nl9GRUFUVVJFX1hNTTMpIHwKICAgICAgICAg
ICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX1BDTE1VTFFEUSkgfAogICAgICAgICAg
ICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfU1NTRTMpIHwKKyAgICAgICAgICAgICAg
ICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0ZNQSkgfAogICAgICAgICAgICAgICAgICAgICBi
aXRtYXNrb2YoWDg2X0ZFQVRVUkVfQ1gxNikgfAogICAgICAgICAgICAgICAgICAgICBiaXRtYXNr
b2YoWDg2X0ZFQVRVUkVfU1NFNF8xKSB8CiAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihY
ODZfRkVBVFVSRV9TU0U0XzIpIHwKKyAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9G
RUFUVVJFX01PVkJFKSAgfAogICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRV
UkVfUE9QQ05UKSB8CiAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9B
RVMpIHwKICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0YxNkMpIHwK
QEAgLTM1NSw3ICszNTgsMTAgQEAgc3RhdGljIHZvaWQgeGNfY3B1aWRfaHZtX3BvbGljeSgKIAog
ICAgIGNhc2UgMHgwMDAwMDAwNzogLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMgKi8KICAg
ICAgICAgaWYgKCBpbnB1dFsxXSA9PSAwICkgewotICAgICAgICAgICAgcmVnc1sxXSAmPSAoYml0
bWFza29mKFg4Nl9GRUFUVVJFX1NNRVApIHwKKyAgICAgICAgICAgIHJlZ3NbMV0gJj0gKGJpdG1h
c2tvZihYODZfRkVBVFVSRV9CTUkxKSB8CisgICAgICAgICAgICAgICAgICAgICAgICBiaXRtYXNr
b2YoWDg2X0ZFQVRVUkVfQVZYMikgfAorICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFza29m
KFg4Nl9GRUFUVVJFX1NNRVApIHwKKyAgICAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihY
ODZfRkVBVFVSRV9CTUkyKSB8CiAgICAgICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2
X0ZFQVRVUkVfRVJNUykgfAogICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9G
RUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIH0gZWxzZQpAQCAtNDgxLDggKzQ4NywxMSBAQCBz
dGF0aWMgdm9pZCB4Y19jcHVpZF9wdl9wb2xpY3koCiAKICAgICBjYXNlIDB4MDAwMDAwMDc6CiAg
ICAgICAgIGlmICggaW5wdXRbMV0gPT0gMCApCi0gICAgICAgICAgICByZWdzWzFdICY9IChiaXRt
YXNrb2YoWDg2X0ZFQVRVUkVfRlNHU0JBU0UpIHwKLSAgICAgICAgICAgICAgICAgICAgICAgIGJp
dG1hc2tvZihYODZfRkVBVFVSRV9FUk1TKSk7CisgICAgICAgICAgICByZWdzWzFdICY9IChiaXRt
YXNrb2YoWDg2X0ZFQVRVUkVfQk1JMSkgfAorICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFz
a29mKFg4Nl9GRUFUVVJFX0FWWDIpIHwKKyAgICAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tv
ZihYODZfRkVBVFVSRV9CTUkyKSB8CisgICAgICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2Yo
WDg2X0ZFQVRVUkVfRVJNUykgfAorICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4
Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIHJlZ3NbMV0g
PSAwOwogICAgICAgICByZWdzWzBdID0gcmVnc1syXSA9IHJlZ3NbM10gPSAwOwo=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Bshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Bshsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:52:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:52:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbb3-0000Bg-B5; Thu, 24 Nov 2011 15:52:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbb0-0000BE-UN
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:52:19 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322149906!4469032!1
X-Originating-IP: [143.182.124.21]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10743 invoked from network); 24 Nov 2011 15:51:47 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-182.messagelabs.com with SMTP;
	24 Nov 2011 15:51:47 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 24 Nov 2011 07:51:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.69,565,1315206000"; d="scan'208";a="40891357"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Nov 2011 07:51:44 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:51:39 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Thu, 24 Nov 2011 23:51:38 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:51:37 +0800
Thread-Topic: [PATCH 2/6] X86: expose Intel new features to dom0
Thread-Index: AcyqwPLgT5ZetwLzQrS3XN6RbGfSEg==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7C@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Cshsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/6] X86: expose Intel new features to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Cshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: expose Intel new features to dom0

This patch expose Intel new features to dom0, including FMA/AVX2/BMI1/BMI2/=
LZCNT/MOVBE.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 38b25f3b2bca xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Nov 17 17:54:17 2011 +0800
+++ b/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
@@ -826,8 +826,11 @@ static void pv_cpuid(struct cpu_user_reg
=20
     case 0x00000007:
         if ( regs->ecx =3D=3D 0 )
-            b &=3D (cpufeat_mask(X86_FEATURE_FSGSBASE) |
-                  cpufeat_mask(X86_FEATURE_ERMS));
+            b &=3D (cpufeat_mask(X86_FEATURE_BMI1) |
+                  cpufeat_mask(X86_FEATURE_AVX2) |
+                  cpufeat_mask(X86_FEATURE_BMI2) |
+                  cpufeat_mask(X86_FEATURE_ERMS) |
+                  cpufeat_mask(X86_FEATURE_FSGSBASE));
         else
             b =3D 0;
         a =3D c =3D d =3D 0;
diff -r 38b25f3b2bca xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 17:54:17 2011 +0800
+++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
@@ -93,6 +93,7 @@
 #define X86_FEATURE_TM2		(4*32+ 8) /* Thermal Monitor 2 */
 #define X86_FEATURE_SSSE3	(4*32+ 9) /* Supplemental Streaming SIMD Extensi=
ons-3 */
 #define X86_FEATURE_CID		(4*32+10) /* Context ID */
+#define X86_FEATURE_FMA		(4*32+12) /* Fused Multiply Add */
 #define X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */
 #define X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
 #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
@@ -100,6 +101,7 @@
 #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming SIMD Extensions 4.1 */
 #define X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
 #define X86_FEATURE_X2APIC	(4*32+21) /* Extended xAPIC */
+#define X86_FEATURE_MOVBE	(4*32+22) /* movbe instruction */
 #define X86_FEATURE_POPCNT	(4*32+23) /* POPCNT instruction */
 #define X86_FEATURE_TSC_DEADLINE (4*32+24) /* "tdt" TSC Deadline Timer */
 #define X86_FEATURE_AES		(4*32+25) /* AES instructions */
@@ -145,7 +147,10 @@
=20
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx), word 7 */
 #define X86_FEATURE_FSGSBASE	(7*32+ 0) /* {RD,WR}{FS,GS}BASE instructions =
*/
+#define X86_FEATURE_BMI1	(7*32+ 3) /* 1st bit manipulation extensions */
+#define X86_FEATURE_AVX2	(7*32+ 5) /* AVX2 instructions */
 #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection=
 */
+#define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
 #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
=20
 #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Cshsmsx502ccrc_
Content-Type: application/octet-stream; name="2_new_cpuid_expose_dom0.patch"
Content-Description: 2_new_cpuid_expose_dom0.patch
Content-Disposition: attachment; filename="2_new_cpuid_expose_dom0.patch";
	size=2632; creation-date="Thu, 24 Nov 2011 23:28:03 GMT";
	modification-date="Tue, 22 Nov 2011 15:26:54 GMT"
Content-Transfer-Encoding: base64

WDg2OiBleHBvc2UgSW50ZWwgbmV3IGZlYXR1cmVzIHRvIGRvbTAKClRoaXMgcGF0Y2ggZXhwb3Nl
IEludGVsIG5ldyBmZWF0dXJlcyB0byBkb20wLCBpbmNsdWRpbmcgRk1BL0FWWDIvQk1JMS9CTUky
L0xaQ05UL01PVkJFLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBp
bnRlbC5jb20+CgpkaWZmIC1yIDM4YjI1ZjNiMmJjYSB4ZW4vYXJjaC94ODYvdHJhcHMuYwotLS0g
YS94ZW4vYXJjaC94ODYvdHJhcHMuYwlUaHUgTm92IDE3IDE3OjU0OjE3IDIwMTEgKzA4MDAKKysr
IGIveGVuL2FyY2gveDg2L3RyYXBzLmMJVGh1IE5vdiAxNyAxODowNjowMSAyMDExICswODAwCkBA
IC04MjYsOCArODI2LDExIEBAIHN0YXRpYyB2b2lkIHB2X2NwdWlkKHN0cnVjdCBjcHVfdXNlcl9y
ZWcKIAogICAgIGNhc2UgMHgwMDAwMDAwNzoKICAgICAgICAgaWYgKCByZWdzLT5lY3ggPT0gMCAp
Ci0gICAgICAgICAgICBiICY9IChjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfRlNHU0JBU0UpIHwK
LSAgICAgICAgICAgICAgICAgIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9FUk1TKSk7CisgICAg
ICAgICAgICBiICY9IChjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfQk1JMSkgfAorICAgICAgICAg
ICAgICAgICAgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0FWWDIpIHwKKyAgICAgICAgICAgICAg
ICAgIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9CTUkyKSB8CisgICAgICAgICAgICAgICAgICBj
cHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfRVJNUykgfAorICAgICAgICAgICAgICAgICAgY3B1ZmVh
dF9tYXNrKFg4Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAg
IGIgPSAwOwogICAgICAgICBhID0gYyA9IGQgPSAwOwpkaWZmIC1yIDM4YjI1ZjNiMmJjYSB4ZW4v
aW5jbHVkZS9hc20teDg2L2NwdWZlYXR1cmUuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2Nw
dWZlYXR1cmUuaAlUaHUgTm92IDE3IDE3OjU0OjE3IDIwMTEgKzA4MDAKKysrIGIveGVuL2luY2x1
ZGUvYXNtLXg4Ni9jcHVmZWF0dXJlLmgJVGh1IE5vdiAxNyAxODowNjowMSAyMDExICswODAwCkBA
IC05Myw2ICs5Myw3IEBACiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1RNMgkJKDQqMzIrIDgpIC8qIFRo
ZXJtYWwgTW9uaXRvciAyICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1NTU0UzCSg0KjMyKyA5KSAv
KiBTdXBwbGVtZW50YWwgU3RyZWFtaW5nIFNJTUQgRXh0ZW5zaW9ucy0zICovCiAjZGVmaW5lIFg4
Nl9GRUFUVVJFX0NJRAkJKDQqMzIrMTApIC8qIENvbnRleHQgSUQgKi8KKyNkZWZpbmUgWDg2X0ZF
QVRVUkVfRk1BCQkoNCozMisxMikgLyogRnVzZWQgTXVsdGlwbHkgQWRkICovCiAjZGVmaW5lIFg4
Nl9GRUFUVVJFX0NYMTYgICAgICAgICg0KjMyKzEzKSAvKiBDTVBYQ0hHMTZCICovCiAjZGVmaW5l
IFg4Nl9GRUFUVVJFX1hUUFIJKDQqMzIrMTQpIC8qIFNlbmQgVGFzayBQcmlvcml0eSBNZXNzYWdl
cyAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9QRENNCSg0KjMyKzE1KSAvKiBQZXJmL0RlYnVnIENh
cGFiaWxpdHkgTVNSICovCkBAIC0xMDAsNiArMTAxLDcgQEAKICNkZWZpbmUgWDg2X0ZFQVRVUkVf
U1NFNF8xCSg0KjMyKzE5KSAvKiBTdHJlYW1pbmcgU0lNRCBFeHRlbnNpb25zIDQuMSAqLwogI2Rl
ZmluZSBYODZfRkVBVFVSRV9TU0U0XzIJKDQqMzIrMjApIC8qIFN0cmVhbWluZyBTSU1EIEV4dGVu
c2lvbnMgNC4yICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1gyQVBJQwkoNCozMisyMSkgLyogRXh0
ZW5kZWQgeEFQSUMgKi8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfTU9WQkUJKDQqMzIrMjIpIC8qIG1v
dmJlIGluc3RydWN0aW9uICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1BPUENOVAkoNCozMisyMykg
LyogUE9QQ05UIGluc3RydWN0aW9uICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1RTQ19ERUFETElO
RSAoNCozMisyNCkgLyogInRkdCIgVFNDIERlYWRsaW5lIFRpbWVyICovCiAjZGVmaW5lIFg4Nl9G
RUFUVVJFX0FFUwkJKDQqMzIrMjUpIC8qIEFFUyBpbnN0cnVjdGlvbnMgKi8KQEAgLTE0NSw3ICsx
NDcsMTAgQEAKIAogLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMsIENQVUlEIGxldmVsIDB4
MDAwMDAwMDc6MCAoZWJ4KSwgd29yZCA3ICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0ZTR1NCQVNF
CSg3KjMyKyAwKSAvKiB7UkQsV1J9e0ZTLEdTfUJBU0UgaW5zdHJ1Y3Rpb25zICovCisjZGVmaW5l
IFg4Nl9GRUFUVVJFX0JNSTEJKDcqMzIrIDMpIC8qIDFzdCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVu
c2lvbnMgKi8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfQVZYMgkoNyozMisgNSkgLyogQVZYMiBpbnN0
cnVjdGlvbnMgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfU01FUAkoNyozMisgNykgLyogU3VwZXJ2
aXNvciBNb2RlIEV4ZWN1dGlvbiBQcm90ZWN0aW9uICovCisjZGVmaW5lIFg4Nl9GRUFUVVJFX0JN
STIJKDcqMzIrIDgpIC8qIDJuZCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KICNkZWZp
bmUgWDg2X0ZFQVRVUkVfRVJNUwkoNyozMisgOSkgLyogRW5oYW5jZWQgUkVQIE1PVlNCL1NUT1NC
ICovCiAKICNkZWZpbmUgY3B1X2hhcyhjLCBiaXQpCQl0ZXN0X2JpdChiaXQsIChjKS0+eDg2X2Nh
cGFiaWxpdHkpCg==

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Cshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Cshsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:52:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:52:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbb3-0000Bg-B5; Thu, 24 Nov 2011 15:52:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbb0-0000BE-UN
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:52:19 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322149906!4469032!1
X-Originating-IP: [143.182.124.21]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10743 invoked from network); 24 Nov 2011 15:51:47 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-182.messagelabs.com with SMTP;
	24 Nov 2011 15:51:47 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 24 Nov 2011 07:51:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.69,565,1315206000"; d="scan'208";a="40891357"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Nov 2011 07:51:44 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:51:39 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Thu, 24 Nov 2011 23:51:38 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:51:37 +0800
Thread-Topic: [PATCH 2/6] X86: expose Intel new features to dom0
Thread-Index: AcyqwPLgT5ZetwLzQrS3XN6RbGfSEg==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7C@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Cshsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/6] X86: expose Intel new features to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Cshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: expose Intel new features to dom0

This patch expose Intel new features to dom0, including FMA/AVX2/BMI1/BMI2/=
LZCNT/MOVBE.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 38b25f3b2bca xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Nov 17 17:54:17 2011 +0800
+++ b/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
@@ -826,8 +826,11 @@ static void pv_cpuid(struct cpu_user_reg
=20
     case 0x00000007:
         if ( regs->ecx =3D=3D 0 )
-            b &=3D (cpufeat_mask(X86_FEATURE_FSGSBASE) |
-                  cpufeat_mask(X86_FEATURE_ERMS));
+            b &=3D (cpufeat_mask(X86_FEATURE_BMI1) |
+                  cpufeat_mask(X86_FEATURE_AVX2) |
+                  cpufeat_mask(X86_FEATURE_BMI2) |
+                  cpufeat_mask(X86_FEATURE_ERMS) |
+                  cpufeat_mask(X86_FEATURE_FSGSBASE));
         else
             b =3D 0;
         a =3D c =3D d =3D 0;
diff -r 38b25f3b2bca xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 17:54:17 2011 +0800
+++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
@@ -93,6 +93,7 @@
 #define X86_FEATURE_TM2		(4*32+ 8) /* Thermal Monitor 2 */
 #define X86_FEATURE_SSSE3	(4*32+ 9) /* Supplemental Streaming SIMD Extensi=
ons-3 */
 #define X86_FEATURE_CID		(4*32+10) /* Context ID */
+#define X86_FEATURE_FMA		(4*32+12) /* Fused Multiply Add */
 #define X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */
 #define X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
 #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
@@ -100,6 +101,7 @@
 #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming SIMD Extensions 4.1 */
 #define X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
 #define X86_FEATURE_X2APIC	(4*32+21) /* Extended xAPIC */
+#define X86_FEATURE_MOVBE	(4*32+22) /* movbe instruction */
 #define X86_FEATURE_POPCNT	(4*32+23) /* POPCNT instruction */
 #define X86_FEATURE_TSC_DEADLINE (4*32+24) /* "tdt" TSC Deadline Timer */
 #define X86_FEATURE_AES		(4*32+25) /* AES instructions */
@@ -145,7 +147,10 @@
=20
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx), word 7 */
 #define X86_FEATURE_FSGSBASE	(7*32+ 0) /* {RD,WR}{FS,GS}BASE instructions =
*/
+#define X86_FEATURE_BMI1	(7*32+ 3) /* 1st bit manipulation extensions */
+#define X86_FEATURE_AVX2	(7*32+ 5) /* AVX2 instructions */
 #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection=
 */
+#define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
 #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
=20
 #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Cshsmsx502ccrc_
Content-Type: application/octet-stream; name="2_new_cpuid_expose_dom0.patch"
Content-Description: 2_new_cpuid_expose_dom0.patch
Content-Disposition: attachment; filename="2_new_cpuid_expose_dom0.patch";
	size=2632; creation-date="Thu, 24 Nov 2011 23:28:03 GMT";
	modification-date="Tue, 22 Nov 2011 15:26:54 GMT"
Content-Transfer-Encoding: base64

WDg2OiBleHBvc2UgSW50ZWwgbmV3IGZlYXR1cmVzIHRvIGRvbTAKClRoaXMgcGF0Y2ggZXhwb3Nl
IEludGVsIG5ldyBmZWF0dXJlcyB0byBkb20wLCBpbmNsdWRpbmcgRk1BL0FWWDIvQk1JMS9CTUky
L0xaQ05UL01PVkJFLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBp
bnRlbC5jb20+CgpkaWZmIC1yIDM4YjI1ZjNiMmJjYSB4ZW4vYXJjaC94ODYvdHJhcHMuYwotLS0g
YS94ZW4vYXJjaC94ODYvdHJhcHMuYwlUaHUgTm92IDE3IDE3OjU0OjE3IDIwMTEgKzA4MDAKKysr
IGIveGVuL2FyY2gveDg2L3RyYXBzLmMJVGh1IE5vdiAxNyAxODowNjowMSAyMDExICswODAwCkBA
IC04MjYsOCArODI2LDExIEBAIHN0YXRpYyB2b2lkIHB2X2NwdWlkKHN0cnVjdCBjcHVfdXNlcl9y
ZWcKIAogICAgIGNhc2UgMHgwMDAwMDAwNzoKICAgICAgICAgaWYgKCByZWdzLT5lY3ggPT0gMCAp
Ci0gICAgICAgICAgICBiICY9IChjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfRlNHU0JBU0UpIHwK
LSAgICAgICAgICAgICAgICAgIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9FUk1TKSk7CisgICAg
ICAgICAgICBiICY9IChjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfQk1JMSkgfAorICAgICAgICAg
ICAgICAgICAgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0FWWDIpIHwKKyAgICAgICAgICAgICAg
ICAgIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9CTUkyKSB8CisgICAgICAgICAgICAgICAgICBj
cHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfRVJNUykgfAorICAgICAgICAgICAgICAgICAgY3B1ZmVh
dF9tYXNrKFg4Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAg
IGIgPSAwOwogICAgICAgICBhID0gYyA9IGQgPSAwOwpkaWZmIC1yIDM4YjI1ZjNiMmJjYSB4ZW4v
aW5jbHVkZS9hc20teDg2L2NwdWZlYXR1cmUuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2Nw
dWZlYXR1cmUuaAlUaHUgTm92IDE3IDE3OjU0OjE3IDIwMTEgKzA4MDAKKysrIGIveGVuL2luY2x1
ZGUvYXNtLXg4Ni9jcHVmZWF0dXJlLmgJVGh1IE5vdiAxNyAxODowNjowMSAyMDExICswODAwCkBA
IC05Myw2ICs5Myw3IEBACiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1RNMgkJKDQqMzIrIDgpIC8qIFRo
ZXJtYWwgTW9uaXRvciAyICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1NTU0UzCSg0KjMyKyA5KSAv
KiBTdXBwbGVtZW50YWwgU3RyZWFtaW5nIFNJTUQgRXh0ZW5zaW9ucy0zICovCiAjZGVmaW5lIFg4
Nl9GRUFUVVJFX0NJRAkJKDQqMzIrMTApIC8qIENvbnRleHQgSUQgKi8KKyNkZWZpbmUgWDg2X0ZF
QVRVUkVfRk1BCQkoNCozMisxMikgLyogRnVzZWQgTXVsdGlwbHkgQWRkICovCiAjZGVmaW5lIFg4
Nl9GRUFUVVJFX0NYMTYgICAgICAgICg0KjMyKzEzKSAvKiBDTVBYQ0hHMTZCICovCiAjZGVmaW5l
IFg4Nl9GRUFUVVJFX1hUUFIJKDQqMzIrMTQpIC8qIFNlbmQgVGFzayBQcmlvcml0eSBNZXNzYWdl
cyAqLwogI2RlZmluZSBYODZfRkVBVFVSRV9QRENNCSg0KjMyKzE1KSAvKiBQZXJmL0RlYnVnIENh
cGFiaWxpdHkgTVNSICovCkBAIC0xMDAsNiArMTAxLDcgQEAKICNkZWZpbmUgWDg2X0ZFQVRVUkVf
U1NFNF8xCSg0KjMyKzE5KSAvKiBTdHJlYW1pbmcgU0lNRCBFeHRlbnNpb25zIDQuMSAqLwogI2Rl
ZmluZSBYODZfRkVBVFVSRV9TU0U0XzIJKDQqMzIrMjApIC8qIFN0cmVhbWluZyBTSU1EIEV4dGVu
c2lvbnMgNC4yICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1gyQVBJQwkoNCozMisyMSkgLyogRXh0
ZW5kZWQgeEFQSUMgKi8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfTU9WQkUJKDQqMzIrMjIpIC8qIG1v
dmJlIGluc3RydWN0aW9uICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1BPUENOVAkoNCozMisyMykg
LyogUE9QQ05UIGluc3RydWN0aW9uICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1RTQ19ERUFETElO
RSAoNCozMisyNCkgLyogInRkdCIgVFNDIERlYWRsaW5lIFRpbWVyICovCiAjZGVmaW5lIFg4Nl9G
RUFUVVJFX0FFUwkJKDQqMzIrMjUpIC8qIEFFUyBpbnN0cnVjdGlvbnMgKi8KQEAgLTE0NSw3ICsx
NDcsMTAgQEAKIAogLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVhdHVyZXMsIENQVUlEIGxldmVsIDB4
MDAwMDAwMDc6MCAoZWJ4KSwgd29yZCA3ICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0ZTR1NCQVNF
CSg3KjMyKyAwKSAvKiB7UkQsV1J9e0ZTLEdTfUJBU0UgaW5zdHJ1Y3Rpb25zICovCisjZGVmaW5l
IFg4Nl9GRUFUVVJFX0JNSTEJKDcqMzIrIDMpIC8qIDFzdCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVu
c2lvbnMgKi8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfQVZYMgkoNyozMisgNSkgLyogQVZYMiBpbnN0
cnVjdGlvbnMgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfU01FUAkoNyozMisgNykgLyogU3VwZXJ2
aXNvciBNb2RlIEV4ZWN1dGlvbiBQcm90ZWN0aW9uICovCisjZGVmaW5lIFg4Nl9GRUFUVVJFX0JN
STIJKDcqMzIrIDgpIC8qIDJuZCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KICNkZWZp
bmUgWDg2X0ZFQVRVUkVfRVJNUwkoNyozMisgOSkgLyogRW5oYW5jZWQgUkVQIE1PVlNCL1NUT1NC
ICovCiAKICNkZWZpbmUgY3B1X2hhcyhjLCBiaXQpCQl0ZXN0X2JpdChiaXQsIChjKS0+eDg2X2Nh
cGFiaWxpdHkpCg==

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Cshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Cshsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:54:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:54:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbca-0000Lh-5g; Thu, 24 Nov 2011 15:53:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbcY-0000LB-Pa
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:53:55 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322150002!4488837!1
X-Originating-IP: [134.134.136.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8705 invoked from network); 24 Nov 2011 15:53:23 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-182.messagelabs.com with SMTP;
	24 Nov 2011 15:53:23 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2011 07:53:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="79662326"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 24 Nov 2011 07:53:21 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:53:20 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:53:20 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Thu, 24 Nov 2011 23:53:18 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:53:17 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcyqwS6o3Ylo9hBPR2yjjv4EPXZvXA==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Eshsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Eshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: Disable PCID/INVPCID for dom0

PCID (Process-context identifier) is a facility by which a logical processo=
r may cache information for multiple linear-address spaces. INVPCID is an n=
ew instruction to invalidate TLB. Refer latest Intel SDM http://www.intel.c=
om/content/www/us/en/processors/architectures-software-developer-manuals.ht=
ml

We disable PCID/INVPCID for dom0 and pv. Exposing them into dom0 and pv may=
 result in performance regression, and it would trigger GP or UD depending =
on whether platform suppport INVPCID or not.

This patch disable PCID/INVPCID for dom0.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 519a0e3c982d xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
+++ b/xen/arch/x86/traps.c	Thu Nov 17 18:41:59 2011 +0800
@@ -813,6 +813,7 @@ static void pv_cpuid(struct cpu_user_reg
             __clear_bit(X86_FEATURE_CX16 % 32, &c);
         __clear_bit(X86_FEATURE_XTPR % 32, &c);
         __clear_bit(X86_FEATURE_PDCM % 32, &c);
+        __clear_bit(X86_FEATURE_PCID % 32, &c);
         __clear_bit(X86_FEATURE_DCA % 32, &c);
         if ( !xsave_enabled(current) )
         {
diff -r 519a0e3c982d xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
+++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:41:59 2011 +0800
@@ -97,6 +97,7 @@
 #define X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */
 #define X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
 #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
+#define X86_FEATURE_PCID	(4*32+17) /* Process Context ID */
 #define X86_FEATURE_DCA		(4*32+18) /* Direct Cache Access */
 #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming SIMD Extensions 4.1 */
 #define X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
@@ -152,6 +153,7 @@
 #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection=
 */
 #define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
 #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
+#define X86_FEATURE_INVPCID	(7*32+10) /* Invalidate Process Context ID */
=20
 #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
 #define boot_cpu_has(bit)	test_bit(bit, boot_cpu_data.x86_capability)=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Eshsmsx502ccrc_
Content-Type: application/octet-stream;
	name="3_disable_pcid_invpcid_for_dom0.patch"
Content-Description: 3_disable_pcid_invpcid_for_dom0.patch
Content-Disposition: attachment;
	filename="3_disable_pcid_invpcid_for_dom0.patch"; size=2280;
	creation-date="Thu, 24 Nov 2011 23:28:03 GMT";
	modification-date="Thu, 24 Nov 2011 22:54:54 GMT"
Content-Transfer-Encoding: base64

WDg2OiBEaXNhYmxlIFBDSUQvSU5WUENJRCBmb3IgZG9tMAoKUENJRCAoUHJvY2Vzcy1jb250ZXh0
IGlkZW50aWZpZXIpIGlzIGEgZmFjaWxpdHkgYnkgd2hpY2ggYSBsb2dpY2FsIHByb2Nlc3NvciBt
YXkgY2FjaGUgaW5mb3JtYXRpb24gZm9yIG11bHRpcGxlIGxpbmVhci1hZGRyZXNzIHNwYWNlcy4g
SU5WUENJRCBpcyBhbiBuZXcgaW5zdHJ1Y3Rpb24gdG8gaW52YWxpZGF0ZSBUTEIuIFJlZmVyIGxh
dGVzdCBJbnRlbCBTRE0gaHR0cDovL3d3dy5pbnRlbC5jb20vY29udGVudC93d3cvdXMvZW4vcHJv
Y2Vzc29ycy9hcmNoaXRlY3R1cmVzLXNvZnR3YXJlLWRldmVsb3Blci1tYW51YWxzLmh0bWwKCldl
IGRpc2FibGUgUENJRC9JTlZQQ0lEIGZvciBkb20wIGFuZCBwdi4gRXhwb3NpbmcgdGhlbSBpbnRv
IGRvbTAgYW5kIHB2IG1heSByZXN1bHQgaW4gcGVyZm9ybWFuY2UgcmVncmVzc2lvbiwgYW5kIGl0
IHdvdWxkIHRyaWdnZXIgR1Agb3IgVUQgZGVwZW5kaW5nIG9uIHdoZXRoZXIgcGxhdGZvcm0gc3Vw
cHBvcnQgSU5WUENJRCBvciBub3QuCgpUaGlzIHBhdGNoIGRpc2FibGUgUENJRC9JTlZQQ0lEIGZv
ciBkb20wLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5j
b20+CgpkaWZmIC1yIDUxOWEwZTNjOTgyZCB4ZW4vYXJjaC94ODYvdHJhcHMuYwotLS0gYS94ZW4v
YXJjaC94ODYvdHJhcHMuYwlUaHUgTm92IDE3IDE4OjA2OjAxIDIwMTEgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L3RyYXBzLmMJVGh1IE5vdiAxNyAxODo0MTo1OSAyMDExICswODAwCkBAIC04MTMs
NiArODEzLDcgQEAgc3RhdGljIHZvaWQgcHZfY3B1aWQoc3RydWN0IGNwdV91c2VyX3JlZwogICAg
ICAgICAgICAgX19jbGVhcl9iaXQoWDg2X0ZFQVRVUkVfQ1gxNiAlIDMyLCAmYyk7CiAgICAgICAg
IF9fY2xlYXJfYml0KFg4Nl9GRUFUVVJFX1hUUFIgJSAzMiwgJmMpOwogICAgICAgICBfX2NsZWFy
X2JpdChYODZfRkVBVFVSRV9QRENNICUgMzIsICZjKTsKKyAgICAgICAgX19jbGVhcl9iaXQoWDg2
X0ZFQVRVUkVfUENJRCAlIDMyLCAmYyk7CiAgICAgICAgIF9fY2xlYXJfYml0KFg4Nl9GRUFUVVJF
X0RDQSAlIDMyLCAmYyk7CiAgICAgICAgIGlmICggIXhzYXZlX2VuYWJsZWQoY3VycmVudCkgKQog
ICAgICAgICB7CmRpZmYgLXIgNTE5YTBlM2M5ODJkIHhlbi9pbmNsdWRlL2FzbS14ODYvY3B1ZmVh
dHVyZS5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvY3B1ZmVhdHVyZS5oCVRodSBOb3YgMTcg
MTg6MDY6MDEgMjAxMSArMDgwMAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZlYXR1cmUu
aAlUaHUgTm92IDE3IDE4OjQxOjU5IDIwMTEgKzA4MDAKQEAgLTk3LDYgKzk3LDcgQEAKICNkZWZp
bmUgWDg2X0ZFQVRVUkVfQ1gxNiAgICAgICAgKDQqMzIrMTMpIC8qIENNUFhDSEcxNkIgKi8KICNk
ZWZpbmUgWDg2X0ZFQVRVUkVfWFRQUgkoNCozMisxNCkgLyogU2VuZCBUYXNrIFByaW9yaXR5IE1l
c3NhZ2VzICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1BEQ00JKDQqMzIrMTUpIC8qIFBlcmYvRGVi
dWcgQ2FwYWJpbGl0eSBNU1IgKi8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfUENJRAkoNCozMisxNykg
LyogUHJvY2VzcyBDb250ZXh0IElEICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0RDQQkJKDQqMzIr
MTgpIC8qIERpcmVjdCBDYWNoZSBBY2Nlc3MgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfU1NFNF8x
CSg0KjMyKzE5KSAvKiBTdHJlYW1pbmcgU0lNRCBFeHRlbnNpb25zIDQuMSAqLwogI2RlZmluZSBY
ODZfRkVBVFVSRV9TU0U0XzIJKDQqMzIrMjApIC8qIFN0cmVhbWluZyBTSU1EIEV4dGVuc2lvbnMg
NC4yICovCkBAIC0xNTIsNiArMTUzLDcgQEAKICNkZWZpbmUgWDg2X0ZFQVRVUkVfU01FUAkoNyoz
MisgNykgLyogU3VwZXJ2aXNvciBNb2RlIEV4ZWN1dGlvbiBQcm90ZWN0aW9uICovCiAjZGVmaW5l
IFg4Nl9GRUFUVVJFX0JNSTIJKDcqMzIrIDgpIC8qIDJuZCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVu
c2lvbnMgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfRVJNUwkoNyozMisgOSkgLyogRW5oYW5jZWQg
UkVQIE1PVlNCL1NUT1NCICovCisjZGVmaW5lIFg4Nl9GRUFUVVJFX0lOVlBDSUQJKDcqMzIrMTAp
IC8qIEludmFsaWRhdGUgUHJvY2VzcyBDb250ZXh0IElEICovCiAKICNkZWZpbmUgY3B1X2hhcyhj
LCBiaXQpCQl0ZXN0X2JpdChiaXQsIChjKS0+eDg2X2NhcGFiaWxpdHkpCiAjZGVmaW5lIGJvb3Rf
Y3B1X2hhcyhiaXQpCXRlc3RfYml0KGJpdCwgYm9vdF9jcHVfZGF0YS54ODZfY2FwYWJpbGl0eSkK

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Eshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Eshsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:54:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:54:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbca-0000Lh-5g; Thu, 24 Nov 2011 15:53:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbcY-0000LB-Pa
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:53:55 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322150002!4488837!1
X-Originating-IP: [134.134.136.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8705 invoked from network); 24 Nov 2011 15:53:23 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-182.messagelabs.com with SMTP;
	24 Nov 2011 15:53:23 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2011 07:53:22 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="79662326"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 24 Nov 2011 07:53:21 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:53:20 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:53:20 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Thu, 24 Nov 2011 23:53:18 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:53:17 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcyqwS6o3Ylo9hBPR2yjjv4EPXZvXA==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Eshsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Eshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: Disable PCID/INVPCID for dom0

PCID (Process-context identifier) is a facility by which a logical processo=
r may cache information for multiple linear-address spaces. INVPCID is an n=
ew instruction to invalidate TLB. Refer latest Intel SDM http://www.intel.c=
om/content/www/us/en/processors/architectures-software-developer-manuals.ht=
ml

We disable PCID/INVPCID for dom0 and pv. Exposing them into dom0 and pv may=
 result in performance regression, and it would trigger GP or UD depending =
on whether platform suppport INVPCID or not.

This patch disable PCID/INVPCID for dom0.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 519a0e3c982d xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
+++ b/xen/arch/x86/traps.c	Thu Nov 17 18:41:59 2011 +0800
@@ -813,6 +813,7 @@ static void pv_cpuid(struct cpu_user_reg
             __clear_bit(X86_FEATURE_CX16 % 32, &c);
         __clear_bit(X86_FEATURE_XTPR % 32, &c);
         __clear_bit(X86_FEATURE_PDCM % 32, &c);
+        __clear_bit(X86_FEATURE_PCID % 32, &c);
         __clear_bit(X86_FEATURE_DCA % 32, &c);
         if ( !xsave_enabled(current) )
         {
diff -r 519a0e3c982d xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
+++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:41:59 2011 +0800
@@ -97,6 +97,7 @@
 #define X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */
 #define X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
 #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
+#define X86_FEATURE_PCID	(4*32+17) /* Process Context ID */
 #define X86_FEATURE_DCA		(4*32+18) /* Direct Cache Access */
 #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming SIMD Extensions 4.1 */
 #define X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
@@ -152,6 +153,7 @@
 #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection=
 */
 #define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
 #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
+#define X86_FEATURE_INVPCID	(7*32+10) /* Invalidate Process Context ID */
=20
 #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
 #define boot_cpu_has(bit)	test_bit(bit, boot_cpu_data.x86_capability)=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Eshsmsx502ccrc_
Content-Type: application/octet-stream;
	name="3_disable_pcid_invpcid_for_dom0.patch"
Content-Description: 3_disable_pcid_invpcid_for_dom0.patch
Content-Disposition: attachment;
	filename="3_disable_pcid_invpcid_for_dom0.patch"; size=2280;
	creation-date="Thu, 24 Nov 2011 23:28:03 GMT";
	modification-date="Thu, 24 Nov 2011 22:54:54 GMT"
Content-Transfer-Encoding: base64

WDg2OiBEaXNhYmxlIFBDSUQvSU5WUENJRCBmb3IgZG9tMAoKUENJRCAoUHJvY2Vzcy1jb250ZXh0
IGlkZW50aWZpZXIpIGlzIGEgZmFjaWxpdHkgYnkgd2hpY2ggYSBsb2dpY2FsIHByb2Nlc3NvciBt
YXkgY2FjaGUgaW5mb3JtYXRpb24gZm9yIG11bHRpcGxlIGxpbmVhci1hZGRyZXNzIHNwYWNlcy4g
SU5WUENJRCBpcyBhbiBuZXcgaW5zdHJ1Y3Rpb24gdG8gaW52YWxpZGF0ZSBUTEIuIFJlZmVyIGxh
dGVzdCBJbnRlbCBTRE0gaHR0cDovL3d3dy5pbnRlbC5jb20vY29udGVudC93d3cvdXMvZW4vcHJv
Y2Vzc29ycy9hcmNoaXRlY3R1cmVzLXNvZnR3YXJlLWRldmVsb3Blci1tYW51YWxzLmh0bWwKCldl
IGRpc2FibGUgUENJRC9JTlZQQ0lEIGZvciBkb20wIGFuZCBwdi4gRXhwb3NpbmcgdGhlbSBpbnRv
IGRvbTAgYW5kIHB2IG1heSByZXN1bHQgaW4gcGVyZm9ybWFuY2UgcmVncmVzc2lvbiwgYW5kIGl0
IHdvdWxkIHRyaWdnZXIgR1Agb3IgVUQgZGVwZW5kaW5nIG9uIHdoZXRoZXIgcGxhdGZvcm0gc3Vw
cHBvcnQgSU5WUENJRCBvciBub3QuCgpUaGlzIHBhdGNoIGRpc2FibGUgUENJRC9JTlZQQ0lEIGZv
ciBkb20wLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5j
b20+CgpkaWZmIC1yIDUxOWEwZTNjOTgyZCB4ZW4vYXJjaC94ODYvdHJhcHMuYwotLS0gYS94ZW4v
YXJjaC94ODYvdHJhcHMuYwlUaHUgTm92IDE3IDE4OjA2OjAxIDIwMTEgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L3RyYXBzLmMJVGh1IE5vdiAxNyAxODo0MTo1OSAyMDExICswODAwCkBAIC04MTMs
NiArODEzLDcgQEAgc3RhdGljIHZvaWQgcHZfY3B1aWQoc3RydWN0IGNwdV91c2VyX3JlZwogICAg
ICAgICAgICAgX19jbGVhcl9iaXQoWDg2X0ZFQVRVUkVfQ1gxNiAlIDMyLCAmYyk7CiAgICAgICAg
IF9fY2xlYXJfYml0KFg4Nl9GRUFUVVJFX1hUUFIgJSAzMiwgJmMpOwogICAgICAgICBfX2NsZWFy
X2JpdChYODZfRkVBVFVSRV9QRENNICUgMzIsICZjKTsKKyAgICAgICAgX19jbGVhcl9iaXQoWDg2
X0ZFQVRVUkVfUENJRCAlIDMyLCAmYyk7CiAgICAgICAgIF9fY2xlYXJfYml0KFg4Nl9GRUFUVVJF
X0RDQSAlIDMyLCAmYyk7CiAgICAgICAgIGlmICggIXhzYXZlX2VuYWJsZWQoY3VycmVudCkgKQog
ICAgICAgICB7CmRpZmYgLXIgNTE5YTBlM2M5ODJkIHhlbi9pbmNsdWRlL2FzbS14ODYvY3B1ZmVh
dHVyZS5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvY3B1ZmVhdHVyZS5oCVRodSBOb3YgMTcg
MTg6MDY6MDEgMjAxMSArMDgwMAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZlYXR1cmUu
aAlUaHUgTm92IDE3IDE4OjQxOjU5IDIwMTEgKzA4MDAKQEAgLTk3LDYgKzk3LDcgQEAKICNkZWZp
bmUgWDg2X0ZFQVRVUkVfQ1gxNiAgICAgICAgKDQqMzIrMTMpIC8qIENNUFhDSEcxNkIgKi8KICNk
ZWZpbmUgWDg2X0ZFQVRVUkVfWFRQUgkoNCozMisxNCkgLyogU2VuZCBUYXNrIFByaW9yaXR5IE1l
c3NhZ2VzICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX1BEQ00JKDQqMzIrMTUpIC8qIFBlcmYvRGVi
dWcgQ2FwYWJpbGl0eSBNU1IgKi8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfUENJRAkoNCozMisxNykg
LyogUHJvY2VzcyBDb250ZXh0IElEICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0RDQQkJKDQqMzIr
MTgpIC8qIERpcmVjdCBDYWNoZSBBY2Nlc3MgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfU1NFNF8x
CSg0KjMyKzE5KSAvKiBTdHJlYW1pbmcgU0lNRCBFeHRlbnNpb25zIDQuMSAqLwogI2RlZmluZSBY
ODZfRkVBVFVSRV9TU0U0XzIJKDQqMzIrMjApIC8qIFN0cmVhbWluZyBTSU1EIEV4dGVuc2lvbnMg
NC4yICovCkBAIC0xNTIsNiArMTUzLDcgQEAKICNkZWZpbmUgWDg2X0ZFQVRVUkVfU01FUAkoNyoz
MisgNykgLyogU3VwZXJ2aXNvciBNb2RlIEV4ZWN1dGlvbiBQcm90ZWN0aW9uICovCiAjZGVmaW5l
IFg4Nl9GRUFUVVJFX0JNSTIJKDcqMzIrIDgpIC8qIDJuZCBiaXQgbWFuaXB1bGF0aW9uIGV4dGVu
c2lvbnMgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfRVJNUwkoNyozMisgOSkgLyogRW5oYW5jZWQg
UkVQIE1PVlNCL1NUT1NCICovCisjZGVmaW5lIFg4Nl9GRUFUVVJFX0lOVlBDSUQJKDcqMzIrMTAp
IC8qIEludmFsaWRhdGUgUHJvY2VzcyBDb250ZXh0IElEICovCiAKICNkZWZpbmUgY3B1X2hhcyhj
LCBiaXQpCQl0ZXN0X2JpdChiaXQsIChjKS0+eDg2X2NhcGFiaWxpdHkpCiAjZGVmaW5lIGJvb3Rf
Y3B1X2hhcyhiaXQpCXRlc3RfYml0KGJpdCwgYm9vdF9jcHVfZGF0YS54ODZfY2FwYWJpbGl0eSkK

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Eshsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7Eshsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:54:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbcn-0000N7-LQ; Thu, 24 Nov 2011 15:54:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTbcl-0000MN-Th
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:54:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322150016!4498374!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26137 invoked from network); 24 Nov 2011 15:53:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 15:53:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTbc9-000LLw-O0; Thu, 24 Nov 2011 15:53:29 +0000
Date: Thu, 24 Nov 2011 15:53:29 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124155329.GJ77868@ocelot.phlegethon.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
	<4ECE20FF0200007800062E93@nat28.tlf.novell.com>
	<4ECE21CB0200007800062EA0@nat28.tlf.novell.com>
	<93094315832b40f3892a71fa0797016c.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <93094315832b40f3892a71fa0797016c.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, keir.xen@gmail.com, xen-devel@lists.xensource.com,
	Jan Beulich <JBeulich@suse.com>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 05 of 14] Don't trigger unnecessary shadow
	scans on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 07:24 -0800 on 24 Nov (1322119466), Andres Lagar-Cavilla wrote:
> >>> @@ -2501,7 +2501,8 @@ int sh_remove_all_mappings(struct vcpu *
> >>>          ;
> >>>
> >>>      perfc_incr(shadow_mappings);
> >>> -    if ( (page->count_info & PGC_count_mask) == 0 )
> >>> +    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
> >>> +    if ( (page->count_info & PGC_count_mask) == expected_count )
> >>
> >> Is that really valid outside the locked region?
> We can move it below to be protected by the lock.

It doesn't need to be protected by the lock.  All we care about is that
at some point after the p2m update, the count has fallen to the correct
value.

It would probably be better to explicitly snapshot 
(page->count_info & (PGC_count_mask | PGC_allocated) and make sure that
that is either 0 or (1 | PGC_allocated).  (Yes, the code you're copying
from does it the other way, and it probably shouldn't either).

> >>
> >>>          return 0;
> >>>
> >>>      /* Although this is an externally visible function, we do not know
> >>> @@ -2517,7 +2518,6 @@ int sh_remove_all_mappings(struct vcpu *
> >>>      hash_foreach(v, callback_mask, callbacks, gmfn);
> >>>
> >>>      /* If that didn't catch the mapping, something is very wrong */
> >>> -    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
> >>
> >> This certainly isn't right - iiuc the count would normally have changed
> >> during the hash_foreach() above this.
> 
> I don't think that's a problem. The expected count is still the same. The
> shadow scan callback will not change the PGC_allocated flag in the target
> page.

I don't think there's any interlock stopping another CPU from changing
PGC_allocated, though.  

> Further, the sh_rm_mappings_from_l1 should also be updated. It
> breaks out of the loop on a count of zero, but it should also break out on
> 1 | PGC_allocated.

True.  A helper function that does the snapshot-and-test and is called
from all three places would be an improvement. 

> I'll resend this one.

Thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:54:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:54:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbcn-0000N7-LQ; Thu, 24 Nov 2011 15:54:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTbcl-0000MN-Th
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:54:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322150016!4498374!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26137 invoked from network); 24 Nov 2011 15:53:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 15:53:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTbc9-000LLw-O0; Thu, 24 Nov 2011 15:53:29 +0000
Date: Thu, 24 Nov 2011 15:53:29 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124155329.GJ77868@ocelot.phlegethon.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e8f0709af2b783a9e430.1322082672@xdev.gridcentric.ca>
	<4ECE20FF0200007800062E93@nat28.tlf.novell.com>
	<4ECE21CB0200007800062EA0@nat28.tlf.novell.com>
	<93094315832b40f3892a71fa0797016c.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <93094315832b40f3892a71fa0797016c.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, keir.xen@gmail.com, xen-devel@lists.xensource.com,
	Jan Beulich <JBeulich@suse.com>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 05 of 14] Don't trigger unnecessary shadow
	scans on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 07:24 -0800 on 24 Nov (1322119466), Andres Lagar-Cavilla wrote:
> >>> @@ -2501,7 +2501,8 @@ int sh_remove_all_mappings(struct vcpu *
> >>>          ;
> >>>
> >>>      perfc_incr(shadow_mappings);
> >>> -    if ( (page->count_info & PGC_count_mask) == 0 )
> >>> +    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
> >>> +    if ( (page->count_info & PGC_count_mask) == expected_count )
> >>
> >> Is that really valid outside the locked region?
> We can move it below to be protected by the lock.

It doesn't need to be protected by the lock.  All we care about is that
at some point after the p2m update, the count has fallen to the correct
value.

It would probably be better to explicitly snapshot 
(page->count_info & (PGC_count_mask | PGC_allocated) and make sure that
that is either 0 or (1 | PGC_allocated).  (Yes, the code you're copying
from does it the other way, and it probably shouldn't either).

> >>
> >>>          return 0;
> >>>
> >>>      /* Although this is an externally visible function, we do not know
> >>> @@ -2517,7 +2518,6 @@ int sh_remove_all_mappings(struct vcpu *
> >>>      hash_foreach(v, callback_mask, callbacks, gmfn);
> >>>
> >>>      /* If that didn't catch the mapping, something is very wrong */
> >>> -    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
> >>
> >> This certainly isn't right - iiuc the count would normally have changed
> >> during the hash_foreach() above this.
> 
> I don't think that's a problem. The expected count is still the same. The
> shadow scan callback will not change the PGC_allocated flag in the target
> page.

I don't think there's any interlock stopping another CPU from changing
PGC_allocated, though.  

> Further, the sh_rm_mappings_from_l1 should also be updated. It
> breaks out of the loop on a count of zero, but it should also break out on
> 1 | PGC_allocated.

True.  A helper function that does the snapshot-and-test and is called
from all three places would be an improvement. 

> I'll resend this one.

Thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:55:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbdm-0000W8-5Y; Thu, 24 Nov 2011 15:55:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbdl-0000VP-AK
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:55:09 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322150077!4043541!1
X-Originating-IP: [134.134.136.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27868 invoked from network); 24 Nov 2011 15:54:37 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 15:54:37 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2011 07:54:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="79662569"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 24 Nov 2011 07:54:35 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:54:34 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 24 Nov 2011 23:54:33 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Thu, 24 Nov 2011 23:54:32 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:54:31 +0800
Thread-Topic: [PATCH 4/6] X86: Disable PCID/INVPCID for pv
Thread-Index: AcyqwVr1UdLdhqsGTB+CT0KDr2/4og==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80shsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 4/6] X86: Disable PCID/INVPCID for pv
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: Disable PCID/INVPCID for pv

This patch disable PCID/INVPCID for pv.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 0b15aa9541dc tools/libxc/xc_cpufeature.h
--- a/tools/libxc/xc_cpufeature.h	Thu Nov 17 18:41:59 2011 +0800
+++ b/tools/libxc/xc_cpufeature.h	Thu Nov 17 23:09:45 2011 +0800
@@ -78,6 +78,7 @@
 #define X86_FEATURE_CX16        13 /* CMPXCHG16B */
 #define X86_FEATURE_XTPR        14 /* Send Task Priority Messages */
 #define X86_FEATURE_PDCM        15 /* Perf/Debug Capability MSR */
+#define X86_FEATURE_PCID        17 /* Process Context ID */
 #define X86_FEATURE_DCA         18 /* Direct Cache Access */
 #define X86_FEATURE_SSE4_1      19 /* Streaming SIMD Extensions 4.1 */
 #define X86_FEATURE_SSE4_2      20 /* Streaming SIMD Extensions 4.2 */
@@ -132,5 +133,6 @@
 #define X86_FEATURE_SMEP         7 /* Supervisor Mode Execution Protection=
 */
 #define X86_FEATURE_BMI2         8 /* 2nd group bit manipulation extension=
s */
 #define X86_FEATURE_ERMS         9 /* Enhanced REP MOVSB/STOSB */
+#define X86_FEATURE_INVPCID     10 /* Invalidate Process Context ID */
=20
 #endif /* __LIBXC_CPUFEATURE_H */
diff -r 0b15aa9541dc tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Nov 17 18:41:59 2011 +0800
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Nov 17 23:09:45 2011 +0800
@@ -481,6 +481,7 @@ static void xc_cpuid_pv_policy(
         }
         clear_bit(X86_FEATURE_XTPR, regs[2]);
         clear_bit(X86_FEATURE_PDCM, regs[2]);
+        clear_bit(X86_FEATURE_PCID, regs[2]);
         clear_bit(X86_FEATURE_DCA, regs[2]);
         set_bit(X86_FEATURE_HYPERVISOR, regs[2]);
         break;=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80shsmsx502ccrc_
Content-Type: application/octet-stream;
	name="4_disable_pcid_invpcid_for_pv.patch"
Content-Description: 4_disable_pcid_invpcid_for_pv.patch
Content-Disposition: attachment;
	filename="4_disable_pcid_invpcid_for_pv.patch"; size=1631;
	creation-date="Thu, 24 Nov 2011 23:28:03 GMT";
	modification-date="Thu, 24 Nov 2011 22:55:48 GMT"
Content-Transfer-Encoding: base64

WDg2OiBEaXNhYmxlIFBDSUQvSU5WUENJRCBmb3IgcHYKClRoaXMgcGF0Y2ggZGlzYWJsZSBQQ0lE
L0lOVlBDSUQgZm9yIHB2LgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxp
dUBpbnRlbC5jb20+CgpkaWZmIC1yIDBiMTVhYTk1NDFkYyB0b29scy9saWJ4Yy94Y19jcHVmZWF0
dXJlLmgKLS0tIGEvdG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCVRodSBOb3YgMTcgMTg6NDE6
NTkgMjAxMSArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgJVGh1IE5vdiAx
NyAyMzowOTo0NSAyMDExICswODAwCkBAIC03OCw2ICs3OCw3IEBACiAjZGVmaW5lIFg4Nl9GRUFU
VVJFX0NYMTYgICAgICAgIDEzIC8qIENNUFhDSEcxNkIgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVf
WFRQUiAgICAgICAgMTQgLyogU2VuZCBUYXNrIFByaW9yaXR5IE1lc3NhZ2VzICovCiAjZGVmaW5l
IFg4Nl9GRUFUVVJFX1BEQ00gICAgICAgIDE1IC8qIFBlcmYvRGVidWcgQ2FwYWJpbGl0eSBNU1Ig
Ki8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfUENJRCAgICAgICAgMTcgLyogUHJvY2VzcyBDb250ZXh0
IElEICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0RDQSAgICAgICAgIDE4IC8qIERpcmVjdCBDYWNo
ZSBBY2Nlc3MgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfU1NFNF8xICAgICAgMTkgLyogU3RyZWFt
aW5nIFNJTUQgRXh0ZW5zaW9ucyA0LjEgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfU1NFNF8yICAg
ICAgMjAgLyogU3RyZWFtaW5nIFNJTUQgRXh0ZW5zaW9ucyA0LjIgKi8KQEAgLTEzMiw1ICsxMzMs
NiBAQAogI2RlZmluZSBYODZfRkVBVFVSRV9TTUVQICAgICAgICAgNyAvKiBTdXBlcnZpc29yIE1v
ZGUgRXhlY3V0aW9uIFByb3RlY3Rpb24gKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfQk1JMiAgICAg
ICAgIDggLyogMm5kIGdyb3VwIGJpdCBtYW5pcHVsYXRpb24gZXh0ZW5zaW9ucyAqLwogI2RlZmlu
ZSBYODZfRkVBVFVSRV9FUk1TICAgICAgICAgOSAvKiBFbmhhbmNlZCBSRVAgTU9WU0IvU1RPU0Ig
Ki8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfSU5WUENJRCAgICAgMTAgLyogSW52YWxpZGF0ZSBQcm9j
ZXNzIENvbnRleHQgSUQgKi8KIAogI2VuZGlmIC8qIF9fTElCWENfQ1BVRkVBVFVSRV9IICovCmRp
ZmYgLXIgMGIxNWFhOTU0MWRjIHRvb2xzL2xpYnhjL3hjX2NwdWlkX3g4Ni5jCi0tLSBhL3Rvb2xz
L2xpYnhjL3hjX2NwdWlkX3g4Ni5jCVRodSBOb3YgMTcgMTg6NDE6NTkgMjAxMSArMDgwMAorKysg
Yi90b29scy9saWJ4Yy94Y19jcHVpZF94ODYuYwlUaHUgTm92IDE3IDIzOjA5OjQ1IDIwMTEgKzA4
MDAKQEAgLTQ4MSw2ICs0ODEsNyBAQCBzdGF0aWMgdm9pZCB4Y19jcHVpZF9wdl9wb2xpY3koCiAg
ICAgICAgIH0KICAgICAgICAgY2xlYXJfYml0KFg4Nl9GRUFUVVJFX1hUUFIsIHJlZ3NbMl0pOwog
ICAgICAgICBjbGVhcl9iaXQoWDg2X0ZFQVRVUkVfUERDTSwgcmVnc1syXSk7CisgICAgICAgIGNs
ZWFyX2JpdChYODZfRkVBVFVSRV9QQ0lELCByZWdzWzJdKTsKICAgICAgICAgY2xlYXJfYml0KFg4
Nl9GRUFUVVJFX0RDQSwgcmVnc1syXSk7CiAgICAgICAgIHNldF9iaXQoWDg2X0ZFQVRVUkVfSFlQ
RVJWSVNPUiwgcmVnc1syXSk7CiAgICAgICAgIGJyZWFrOwo=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:55:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:55:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbdm-0000W8-5Y; Thu, 24 Nov 2011 15:55:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbdl-0000VP-AK
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:55:09 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322150077!4043541!1
X-Originating-IP: [134.134.136.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27868 invoked from network); 24 Nov 2011 15:54:37 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 15:54:37 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2011 07:54:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="79662569"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 24 Nov 2011 07:54:35 -0800
Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:54:34 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 24 Nov 2011 23:54:33 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Thu, 24 Nov 2011 23:54:32 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:54:31 +0800
Thread-Topic: [PATCH 4/6] X86: Disable PCID/INVPCID for pv
Thread-Index: AcyqwVr1UdLdhqsGTB+CT0KDr2/4og==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80shsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 4/6] X86: Disable PCID/INVPCID for pv
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: Disable PCID/INVPCID for pv

This patch disable PCID/INVPCID for pv.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 0b15aa9541dc tools/libxc/xc_cpufeature.h
--- a/tools/libxc/xc_cpufeature.h	Thu Nov 17 18:41:59 2011 +0800
+++ b/tools/libxc/xc_cpufeature.h	Thu Nov 17 23:09:45 2011 +0800
@@ -78,6 +78,7 @@
 #define X86_FEATURE_CX16        13 /* CMPXCHG16B */
 #define X86_FEATURE_XTPR        14 /* Send Task Priority Messages */
 #define X86_FEATURE_PDCM        15 /* Perf/Debug Capability MSR */
+#define X86_FEATURE_PCID        17 /* Process Context ID */
 #define X86_FEATURE_DCA         18 /* Direct Cache Access */
 #define X86_FEATURE_SSE4_1      19 /* Streaming SIMD Extensions 4.1 */
 #define X86_FEATURE_SSE4_2      20 /* Streaming SIMD Extensions 4.2 */
@@ -132,5 +133,6 @@
 #define X86_FEATURE_SMEP         7 /* Supervisor Mode Execution Protection=
 */
 #define X86_FEATURE_BMI2         8 /* 2nd group bit manipulation extension=
s */
 #define X86_FEATURE_ERMS         9 /* Enhanced REP MOVSB/STOSB */
+#define X86_FEATURE_INVPCID     10 /* Invalidate Process Context ID */
=20
 #endif /* __LIBXC_CPUFEATURE_H */
diff -r 0b15aa9541dc tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Nov 17 18:41:59 2011 +0800
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Nov 17 23:09:45 2011 +0800
@@ -481,6 +481,7 @@ static void xc_cpuid_pv_policy(
         }
         clear_bit(X86_FEATURE_XTPR, regs[2]);
         clear_bit(X86_FEATURE_PDCM, regs[2]);
+        clear_bit(X86_FEATURE_PCID, regs[2]);
         clear_bit(X86_FEATURE_DCA, regs[2]);
         set_bit(X86_FEATURE_HYPERVISOR, regs[2]);
         break;=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80shsmsx502ccrc_
Content-Type: application/octet-stream;
	name="4_disable_pcid_invpcid_for_pv.patch"
Content-Description: 4_disable_pcid_invpcid_for_pv.patch
Content-Disposition: attachment;
	filename="4_disable_pcid_invpcid_for_pv.patch"; size=1631;
	creation-date="Thu, 24 Nov 2011 23:28:03 GMT";
	modification-date="Thu, 24 Nov 2011 22:55:48 GMT"
Content-Transfer-Encoding: base64

WDg2OiBEaXNhYmxlIFBDSUQvSU5WUENJRCBmb3IgcHYKClRoaXMgcGF0Y2ggZGlzYWJsZSBQQ0lE
L0lOVlBDSUQgZm9yIHB2LgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxp
dUBpbnRlbC5jb20+CgpkaWZmIC1yIDBiMTVhYTk1NDFkYyB0b29scy9saWJ4Yy94Y19jcHVmZWF0
dXJlLmgKLS0tIGEvdG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCVRodSBOb3YgMTcgMTg6NDE6
NTkgMjAxMSArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgJVGh1IE5vdiAx
NyAyMzowOTo0NSAyMDExICswODAwCkBAIC03OCw2ICs3OCw3IEBACiAjZGVmaW5lIFg4Nl9GRUFU
VVJFX0NYMTYgICAgICAgIDEzIC8qIENNUFhDSEcxNkIgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVf
WFRQUiAgICAgICAgMTQgLyogU2VuZCBUYXNrIFByaW9yaXR5IE1lc3NhZ2VzICovCiAjZGVmaW5l
IFg4Nl9GRUFUVVJFX1BEQ00gICAgICAgIDE1IC8qIFBlcmYvRGVidWcgQ2FwYWJpbGl0eSBNU1Ig
Ki8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfUENJRCAgICAgICAgMTcgLyogUHJvY2VzcyBDb250ZXh0
IElEICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0RDQSAgICAgICAgIDE4IC8qIERpcmVjdCBDYWNo
ZSBBY2Nlc3MgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfU1NFNF8xICAgICAgMTkgLyogU3RyZWFt
aW5nIFNJTUQgRXh0ZW5zaW9ucyA0LjEgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfU1NFNF8yICAg
ICAgMjAgLyogU3RyZWFtaW5nIFNJTUQgRXh0ZW5zaW9ucyA0LjIgKi8KQEAgLTEzMiw1ICsxMzMs
NiBAQAogI2RlZmluZSBYODZfRkVBVFVSRV9TTUVQICAgICAgICAgNyAvKiBTdXBlcnZpc29yIE1v
ZGUgRXhlY3V0aW9uIFByb3RlY3Rpb24gKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfQk1JMiAgICAg
ICAgIDggLyogMm5kIGdyb3VwIGJpdCBtYW5pcHVsYXRpb24gZXh0ZW5zaW9ucyAqLwogI2RlZmlu
ZSBYODZfRkVBVFVSRV9FUk1TICAgICAgICAgOSAvKiBFbmhhbmNlZCBSRVAgTU9WU0IvU1RPU0Ig
Ki8KKyNkZWZpbmUgWDg2X0ZFQVRVUkVfSU5WUENJRCAgICAgMTAgLyogSW52YWxpZGF0ZSBQcm9j
ZXNzIENvbnRleHQgSUQgKi8KIAogI2VuZGlmIC8qIF9fTElCWENfQ1BVRkVBVFVSRV9IICovCmRp
ZmYgLXIgMGIxNWFhOTU0MWRjIHRvb2xzL2xpYnhjL3hjX2NwdWlkX3g4Ni5jCi0tLSBhL3Rvb2xz
L2xpYnhjL3hjX2NwdWlkX3g4Ni5jCVRodSBOb3YgMTcgMTg6NDE6NTkgMjAxMSArMDgwMAorKysg
Yi90b29scy9saWJ4Yy94Y19jcHVpZF94ODYuYwlUaHUgTm92IDE3IDIzOjA5OjQ1IDIwMTEgKzA4
MDAKQEAgLTQ4MSw2ICs0ODEsNyBAQCBzdGF0aWMgdm9pZCB4Y19jcHVpZF9wdl9wb2xpY3koCiAg
ICAgICAgIH0KICAgICAgICAgY2xlYXJfYml0KFg4Nl9GRUFUVVJFX1hUUFIsIHJlZ3NbMl0pOwog
ICAgICAgICBjbGVhcl9iaXQoWDg2X0ZFQVRVUkVfUERDTSwgcmVnc1syXSk7CisgICAgICAgIGNs
ZWFyX2JpdChYODZfRkVBVFVSRV9QQ0lELCByZWdzWzJdKTsKICAgICAgICAgY2xlYXJfYml0KFg4
Nl9GRUFUVVJFX0RDQSwgcmVnc1syXSk7CiAgICAgICAgIHNldF9iaXQoWDg2X0ZFQVRVUkVfSFlQ
RVJWSVNPUiwgcmVnc1syXSk7CiAgICAgICAgIGJyZWFrOwo=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A80shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:55:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:55:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbeB-0000bO-0f; Thu, 24 Nov 2011 15:55:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTbe9-0000a4-O6
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:55:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322150102!3617322!1
X-Originating-IP: [208.97.132.119]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13128 invoked from network); 24 Nov 2011 15:55:02 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-13.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 15:55:02 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id D5F0D458081;
	Thu, 24 Nov 2011 07:55:01 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=tU6ROtqkzre/gwyjmYsB5i0fHUlFXqNtgxwuS3S34I38
	ru0x3hpRENvWtprnvW+FemDFyeoHZfMQgmoY8gQq0mVeGv8DEhE4n64UFI26RF9b
	jGlPvUxzGrk35zalCHyFQI61PgyfQUpnH6pp3E5qMSodaRwt/D90rG/iqHw9W3M=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=6P2hzGPl5T1C1+CzebPVa7szEA0=; b=WLYqD3y0
	dfjWrOVB70gYy/VNP5X32epLeyUJq8uF21JPEwTiX6nb88NcbLsXTjVYHkw9WAL0
	N1o8hQpN6XGgElQkfl64ol+kCVlHCxPNYcWGR4kh4+nyKXVHwwaB5iF61sSiAg4d
	YUtyEM3V4Wvp5D9dplnMKkeTTCYM4YjWY9k=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 5E0EA45807C; 
	Thu, 24 Nov 2011 07:55:01 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 07:55:01 -0800
Message-ID: <30c6e35791fba36a017fca0bc59e0f54.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124153222.GI77868@ocelot.phlegethon.org>
References: <patchbomb.1321307321@xdev.gridcentric.ca>
	<20111124153222.GI77868@ocelot.phlegethon.org>
Date: Thu, 24 Nov 2011 07:55:01 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] P2M various fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Note that patches 1-3 you just applied were resent yesterday (in identical
form). So please ignore patches 1-3 from yesterday's 'MM fixes' series.

Thanks a bunch.
Andres
> Hi,
>
> At 16:48 -0500 on 14 Nov (1321289321), Andres Lagar-Cavilla wrote:
>> This patch series brings about a number of fixes to the p2m code
>> in anticipation of synchonizing lookups. Specifically:
>> - Four bug fixes on shadow domctls, setting shared p2m entries,
>>   and splitting 1GB PoD superpages
>> - Rework the p2m audit code. Today it does neither compile nor
>>   apply to ept, so make it compile and move it out of the way
>>   for most callers, which obviously don't care.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Thanks.
>  - I've applied 1-3;
>  - 4 is a tools patch and needs a tools maintainer's ack;
>  - 5 I commented on separately;
>  - 6 depends on 5 and is a tools patch.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:55:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:55:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbeB-0000bO-0f; Thu, 24 Nov 2011 15:55:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTbe9-0000a4-O6
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:55:33 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322150102!3617322!1
X-Originating-IP: [208.97.132.119]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13128 invoked from network); 24 Nov 2011 15:55:02 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-13.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 15:55:02 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id D5F0D458081;
	Thu, 24 Nov 2011 07:55:01 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=tU6ROtqkzre/gwyjmYsB5i0fHUlFXqNtgxwuS3S34I38
	ru0x3hpRENvWtprnvW+FemDFyeoHZfMQgmoY8gQq0mVeGv8DEhE4n64UFI26RF9b
	jGlPvUxzGrk35zalCHyFQI61PgyfQUpnH6pp3E5qMSodaRwt/D90rG/iqHw9W3M=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=6P2hzGPl5T1C1+CzebPVa7szEA0=; b=WLYqD3y0
	dfjWrOVB70gYy/VNP5X32epLeyUJq8uF21JPEwTiX6nb88NcbLsXTjVYHkw9WAL0
	N1o8hQpN6XGgElQkfl64ol+kCVlHCxPNYcWGR4kh4+nyKXVHwwaB5iF61sSiAg4d
	YUtyEM3V4Wvp5D9dplnMKkeTTCYM4YjWY9k=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 5E0EA45807C; 
	Thu, 24 Nov 2011 07:55:01 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 07:55:01 -0800
Message-ID: <30c6e35791fba36a017fca0bc59e0f54.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124153222.GI77868@ocelot.phlegethon.org>
References: <patchbomb.1321307321@xdev.gridcentric.ca>
	<20111124153222.GI77868@ocelot.phlegethon.org>
Date: Thu, 24 Nov 2011 07:55:01 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 6] P2M various fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Note that patches 1-3 you just applied were resent yesterday (in identical
form). So please ignore patches 1-3 from yesterday's 'MM fixes' series.

Thanks a bunch.
Andres
> Hi,
>
> At 16:48 -0500 on 14 Nov (1321289321), Andres Lagar-Cavilla wrote:
>> This patch series brings about a number of fixes to the p2m code
>> in anticipation of synchonizing lookups. Specifically:
>> - Four bug fixes on shadow domctls, setting shared p2m entries,
>>   and splitting 1GB PoD superpages
>> - Rework the p2m audit code. Today it does neither compile nor
>>   apply to ept, so make it compile and move it out of the way
>>   for most callers, which obviously don't care.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Thanks.
>  - I've applied 1-3;
>  - 4 is a tools patch and needs a tools maintainer's ack;
>  - 5 I commented on separately;
>  - 6 depends on 5 and is a tools patch.
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:56:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:56:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbfM-0000pH-Hu; Thu, 24 Nov 2011 15:56:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbfL-0000om-Oh
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:56:47 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322150175!5518931!1
X-Originating-IP: [134.134.136.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15532 invoked from network); 24 Nov 2011 15:56:15 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 15:56:15 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2011 07:56:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="79662820"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 24 Nov 2011 07:56:13 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:56:12 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Thu, 24 Nov 2011 23:56:11 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:56:10 +0800
Thread-Topic: [PATCH 5/6] X86: Prepare PCID/INVPCID for hvm
Thread-Index: AcyqwZWUwFGkeFYFQ/WluzIVxrqX7A==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81shsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 5/6] X86: Prepare PCID/INVPCID for hvm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: Prepare PCID/INVPCID for hvm

This patch is used to prepare exposing PCID/INVPCID features to hvm guest.
The specific exposure result depend on hvm paging mode (hap/shadow), which =
would be handled at next patch.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 1b62d4e08880 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Nov 17 23:09:45 2011 +0800
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Nov 17 23:16:30 2011 +0800
@@ -311,6 +311,7 @@ static void xc_cpuid_hvm_policy(
                     bitmaskof(X86_FEATURE_SSSE3) |
                     bitmaskof(X86_FEATURE_FMA) |
                     bitmaskof(X86_FEATURE_CX16) |
+                    bitmaskof(X86_FEATURE_PCID) |
                     bitmaskof(X86_FEATURE_SSE4_1) |
                     bitmaskof(X86_FEATURE_SSE4_2) |
                     bitmaskof(X86_FEATURE_MOVBE)  |
@@ -363,6 +364,7 @@ static void xc_cpuid_hvm_policy(
                         bitmaskof(X86_FEATURE_SMEP) |
                         bitmaskof(X86_FEATURE_BMI2) |
                         bitmaskof(X86_FEATURE_ERMS) |
+                        bitmaskof(X86_FEATURE_INVPCID) |
                         bitmaskof(X86_FEATURE_FSGSBASE));
         } else
             regs[1] =3D 0;=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81shsmsx502ccrc_
Content-Type: application/octet-stream;
	name="5_prepare_pcid_invpcid_for_hvm.patch"
Content-Description: 5_prepare_pcid_invpcid_for_hvm.patch
Content-Disposition: attachment;
	filename="5_prepare_pcid_invpcid_for_hvm.patch"; size=1240;
	creation-date="Thu, 24 Nov 2011 23:28:03 GMT";
	modification-date="Tue, 22 Nov 2011 15:34:24 GMT"
Content-Transfer-Encoding: base64

WDg2OiBQcmVwYXJlIFBDSUQvSU5WUENJRCBmb3IgaHZtCgpUaGlzIHBhdGNoIGlzIHVzZWQgdG8g
cHJlcGFyZSBleHBvc2luZyBQQ0lEL0lOVlBDSUQgZmVhdHVyZXMgdG8gaHZtIGd1ZXN0LgpUaGUg
c3BlY2lmaWMgZXhwb3N1cmUgcmVzdWx0IGRlcGVuZCBvbiBodm0gcGFnaW5nIG1vZGUgKGhhcC9z
aGFkb3cpLCB3aGljaCB3b3VsZCBiZSBoYW5kbGVkIGF0IG5leHQgcGF0Y2guCgpTaWduZWQtb2Zm
LWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgMWI2MmQ0
ZTA4ODgwIHRvb2xzL2xpYnhjL3hjX2NwdWlkX3g4Ni5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Nw
dWlkX3g4Ni5jCVRodSBOb3YgMTcgMjM6MDk6NDUgMjAxMSArMDgwMAorKysgYi90b29scy9saWJ4
Yy94Y19jcHVpZF94ODYuYwlUaHUgTm92IDE3IDIzOjE2OjMwIDIwMTEgKzA4MDAKQEAgLTMxMSw2
ICszMTEsNyBAQCBzdGF0aWMgdm9pZCB4Y19jcHVpZF9odm1fcG9saWN5KAogICAgICAgICAgICAg
ICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfU1NTRTMpIHwKICAgICAgICAgICAgICAgICAg
ICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0ZNQSkgfAogICAgICAgICAgICAgICAgICAgICBiaXRt
YXNrb2YoWDg2X0ZFQVRVUkVfQ1gxNikgfAorICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2Yo
WDg2X0ZFQVRVUkVfUENJRCkgfAogICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZF
QVRVUkVfU1NFNF8xKSB8CiAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVS
RV9TU0U0XzIpIHwKICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX01P
VkJFKSAgfApAQCAtMzYzLDYgKzM2NCw3IEBAIHN0YXRpYyB2b2lkIHhjX2NwdWlkX2h2bV9wb2xp
Y3koCiAgICAgICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfU01FUCkg
fAogICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0JNSTIpIHwK
ICAgICAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9FUk1TKSB8Cisg
ICAgICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfSU5WUENJRCkgfAog
ICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7
CiAgICAgICAgIH0gZWxzZQogICAgICAgICAgICAgcmVnc1sxXSA9IDA7Cg==

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:56:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:56:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbfM-0000pH-Hu; Thu, 24 Nov 2011 15:56:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbfL-0000om-Oh
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:56:47 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322150175!5518931!1
X-Originating-IP: [134.134.136.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15532 invoked from network); 24 Nov 2011 15:56:15 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-9.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 15:56:15 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2011 07:56:14 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="79662820"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 24 Nov 2011 07:56:13 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:56:12 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Thu, 24 Nov 2011 23:56:11 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:56:10 +0800
Thread-Topic: [PATCH 5/6] X86: Prepare PCID/INVPCID for hvm
Thread-Index: AcyqwZWUwFGkeFYFQ/WluzIVxrqX7A==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81shsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 5/6] X86: Prepare PCID/INVPCID for hvm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: Prepare PCID/INVPCID for hvm

This patch is used to prepare exposing PCID/INVPCID features to hvm guest.
The specific exposure result depend on hvm paging mode (hap/shadow), which =
would be handled at next patch.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 1b62d4e08880 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Nov 17 23:09:45 2011 +0800
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Nov 17 23:16:30 2011 +0800
@@ -311,6 +311,7 @@ static void xc_cpuid_hvm_policy(
                     bitmaskof(X86_FEATURE_SSSE3) |
                     bitmaskof(X86_FEATURE_FMA) |
                     bitmaskof(X86_FEATURE_CX16) |
+                    bitmaskof(X86_FEATURE_PCID) |
                     bitmaskof(X86_FEATURE_SSE4_1) |
                     bitmaskof(X86_FEATURE_SSE4_2) |
                     bitmaskof(X86_FEATURE_MOVBE)  |
@@ -363,6 +364,7 @@ static void xc_cpuid_hvm_policy(
                         bitmaskof(X86_FEATURE_SMEP) |
                         bitmaskof(X86_FEATURE_BMI2) |
                         bitmaskof(X86_FEATURE_ERMS) |
+                        bitmaskof(X86_FEATURE_INVPCID) |
                         bitmaskof(X86_FEATURE_FSGSBASE));
         } else
             regs[1] =3D 0;=

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81shsmsx502ccrc_
Content-Type: application/octet-stream;
	name="5_prepare_pcid_invpcid_for_hvm.patch"
Content-Description: 5_prepare_pcid_invpcid_for_hvm.patch
Content-Disposition: attachment;
	filename="5_prepare_pcid_invpcid_for_hvm.patch"; size=1240;
	creation-date="Thu, 24 Nov 2011 23:28:03 GMT";
	modification-date="Tue, 22 Nov 2011 15:34:24 GMT"
Content-Transfer-Encoding: base64

WDg2OiBQcmVwYXJlIFBDSUQvSU5WUENJRCBmb3IgaHZtCgpUaGlzIHBhdGNoIGlzIHVzZWQgdG8g
cHJlcGFyZSBleHBvc2luZyBQQ0lEL0lOVlBDSUQgZmVhdHVyZXMgdG8gaHZtIGd1ZXN0LgpUaGUg
c3BlY2lmaWMgZXhwb3N1cmUgcmVzdWx0IGRlcGVuZCBvbiBodm0gcGFnaW5nIG1vZGUgKGhhcC9z
aGFkb3cpLCB3aGljaCB3b3VsZCBiZSBoYW5kbGVkIGF0IG5leHQgcGF0Y2guCgpTaWduZWQtb2Zm
LWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgMWI2MmQ0
ZTA4ODgwIHRvb2xzL2xpYnhjL3hjX2NwdWlkX3g4Ni5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Nw
dWlkX3g4Ni5jCVRodSBOb3YgMTcgMjM6MDk6NDUgMjAxMSArMDgwMAorKysgYi90b29scy9saWJ4
Yy94Y19jcHVpZF94ODYuYwlUaHUgTm92IDE3IDIzOjE2OjMwIDIwMTEgKzA4MDAKQEAgLTMxMSw2
ICszMTEsNyBAQCBzdGF0aWMgdm9pZCB4Y19jcHVpZF9odm1fcG9saWN5KAogICAgICAgICAgICAg
ICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfU1NTRTMpIHwKICAgICAgICAgICAgICAgICAg
ICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0ZNQSkgfAogICAgICAgICAgICAgICAgICAgICBiaXRt
YXNrb2YoWDg2X0ZFQVRVUkVfQ1gxNikgfAorICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2Yo
WDg2X0ZFQVRVUkVfUENJRCkgfAogICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZF
QVRVUkVfU1NFNF8xKSB8CiAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVS
RV9TU0U0XzIpIHwKICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX01P
VkJFKSAgfApAQCAtMzYzLDYgKzM2NCw3IEBAIHN0YXRpYyB2b2lkIHhjX2NwdWlkX2h2bV9wb2xp
Y3koCiAgICAgICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfU01FUCkg
fAogICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0JNSTIpIHwK
ICAgICAgICAgICAgICAgICAgICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9FUk1TKSB8Cisg
ICAgICAgICAgICAgICAgICAgICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfSU5WUENJRCkgfAog
ICAgICAgICAgICAgICAgICAgICAgICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0ZTR1NCQVNFKSk7
CiAgICAgICAgIH0gZWxzZQogICAgICAgICAgICAgcmVnc1sxXSA9IDA7Cg==

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A81shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:58:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbh7-0001AD-Bi; Thu, 24 Nov 2011 15:58:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbh5-00019W-TC
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:58:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322150282!2898509!1
X-Originating-IP: [134.134.136.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28914 invoked from network); 24 Nov 2011 15:58:03 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 15:58:03 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2011 07:58:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="79663152"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 24 Nov 2011 07:58:00 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:57:59 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:57:59 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Thu, 24 Nov 2011 23:57:57 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:57:54 +0800
Thread-Topic: [PATCH 6/6] X86: implement PCID/INVPCID for hvm
Thread-Index: AcyqwdOaqDg2NcrBTauPGnqGECe41w==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82shsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 6/6] X86: implement PCID/INVPCID for hvm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: implement PCID/INVPCID for hvm

This patch handle PCID/INVPCID for hvm:
For hap hvm, we enable PCID/INVPCID, since no need to intercept INVPCID, an=
d we just set INVPCID non-root behavior as running natively;
For shadow hvm, we disable PCID/INVPCID, otherwise we need to emulate INVPC=
ID at vmm by setting INVPCID non-root behavior as vmexit.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r c61a5ba8c972 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/arch/x86/hvm/hvm.c	Tue Nov 22 16:15:19 2011 +0800
@@ -1549,6 +1549,13 @@ int hvm_set_cr0(unsigned long value)
     }
     else if ( !(value & X86_CR0_PG) && (old_value & X86_CR0_PG) )
     {
+        if ( hvm_pcid_enabled(v) )
+        {
+            HVM_DBG_LOG(DBG_LEVEL_1, "Guest attempts to clear CR0.PG "
+                        "while CR4.PCIDE=3D1");
+            goto gpf;
+        }
+
         /* When CR0.PG is cleared, LMA is cleared immediately. */
         if ( hvm_long_mode_enabled(v) )
         {
@@ -1663,12 +1670,26 @@ int hvm_set_cr4(unsigned long value)
     }
=20
     old_cr =3D v->arch.hvm_vcpu.guest_cr[4];
+
+    if ( (value & X86_CR4_PCIDE) && !(old_cr & X86_CR4_PCIDE) &&
+        (!hvm_long_mode_enabled(v) || (v->arch.hvm_vcpu.guest_cr[3] & 0xff=
f)) )
+    {
+        HVM_DBG_LOG(DBG_LEVEL_1, "Guest attempts to change CR4.PCIDE from =
"
+                    "0 to 1 while either EFER.LMA=3D0 or CR3[11:0]!=3D000H=
");
+        goto gpf;
+    }
+
     v->arch.hvm_vcpu.guest_cr[4] =3D value;
     hvm_update_guest_cr(v, 4);
=20
-    /* Modifying CR4.{PSE,PAE,PGE,SMEP} invalidates all TLB entries. */
-    if ( (old_cr ^ value) & (X86_CR4_PSE | X86_CR4_PGE |
-                             X86_CR4_PAE | X86_CR4_SMEP) ) {
+    /*=20
+     * Modifying CR4.{PSE,PAE,PGE,SMEP}, or clearing CR4.PCIDE
+     * invalidate all TLB entries.
+     */
+    if ( ((old_cr ^ value) &=20
+          (X86_CR4_PSE | X86_CR4_PGE | X86_CR4_PAE | X86_CR4_SMEP)) ||
+            (!(value & X86_CR4_PCIDE) && (old_cr & X86_CR4_PCIDE)) )
+    {
         if ( !nestedhvm_vmswitch_in_progress(v) && nestedhvm_vcpu_in_guest=
mode(v) )
             paging_update_nestedmode(v);
         else
@@ -2409,10 +2430,18 @@ void hvm_cpuid(unsigned int input, unsig
         if ( xsave_enabled(v) )
             *ecx |=3D (v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_OSXSAVE) ?
                      cpufeat_mask(X86_FEATURE_OSXSAVE) : 0;
+
+        /* Not expose PCID to non-hap hvm */
+        if ( !hap_enabled(d) )
+            *ecx &=3D ~cpufeat_mask(X86_FEATURE_PCID);
         break;
     case 0x7:
         if ( (count =3D=3D 0) && !cpu_has_smep )
             *ebx &=3D ~cpufeat_mask(X86_FEATURE_SMEP);
+
+        /* Not expose INVPCID to non-hap hvm */
+        if ( (count =3D=3D 0) && !hap_enabled(d) )
+            *ebx &=3D ~cpufeat_mask(X86_FEATURE_INVPCID);
         break;
     case 0xb:
         /* Fix the x2APIC identifier. */
diff -r c61a5ba8c972 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Tue Nov 22 16:15:19 2011 +0800
@@ -183,7 +183,8 @@ static int vmx_init_vmcs_config(void)
                SECONDARY_EXEC_WBINVD_EXITING |
                SECONDARY_EXEC_ENABLE_EPT |
                SECONDARY_EXEC_ENABLE_RDTSCP |
-               SECONDARY_EXEC_PAUSE_LOOP_EXITING);
+               SECONDARY_EXEC_PAUSE_LOOP_EXITING |
+               SECONDARY_EXEC_ENABLE_INVPCID);
         if ( opt_vpid_enabled )
             opt |=3D SECONDARY_EXEC_ENABLE_VPID;
         if ( opt_unrestricted_guest_enabled )
@@ -726,7 +727,8 @@ static int construct_vmcs(struct vcpu *v
     {
         v->arch.hvm_vmx.secondary_exec_control &=3D=20
             ~(SECONDARY_EXEC_ENABLE_EPT |=20
-              SECONDARY_EXEC_UNRESTRICTED_GUEST);
+              SECONDARY_EXEC_UNRESTRICTED_GUEST |
+              SECONDARY_EXEC_ENABLE_INVPCID);
         vmexit_ctl &=3D ~(VM_EXIT_SAVE_GUEST_PAT |
                         VM_EXIT_LOAD_HOST_PAT);
         vmentry_ctl &=3D ~VM_ENTRY_LOAD_GUEST_PAT;
diff -r c61a5ba8c972 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Tue Nov 22 16:15:19 2011 +0800
@@ -1004,7 +1004,7 @@ static void vmx_load_pdptrs(struct vcpu=20
     if ( !hvm_pae_enabled(v) || (v->arch.hvm_vcpu.guest_efer & EFER_LMA) )
         return;
=20
-    if ( cr3 & 0x1fUL )
+    if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) )
         goto crash;
=20
     mfn =3D mfn_x(gfn_to_mfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
@@ -2661,6 +2661,7 @@ asmlinkage void vmx_vmexit_handler(struc
     case EXIT_REASON_ACCESS_GDTR_OR_IDTR:
     case EXIT_REASON_ACCESS_LDTR_OR_TR:
     case EXIT_REASON_VMX_PREEMPTION_TIMER_EXPIRED:
+    case EXIT_REASON_INVPCID:
     /* fall through */
     default:
     exit_and_crash:
diff -r c61a5ba8c972 xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/include/asm-x86/cpufeature.h	Tue Nov 22 16:15:19 2011 +0800
@@ -224,6 +224,8 @@
=20
 #define cpu_has_x2apic          boot_cpu_has(X86_FEATURE_X2APIC)
=20
+#define cpu_has_pcid            boot_cpu_has(X86_FEATURE_PCID)
+
 #define cpu_has_xsave           boot_cpu_has(X86_FEATURE_XSAVE)
=20
 #define cpu_has_lwp             boot_cpu_has(X86_FEATURE_LWP)
diff -r c61a5ba8c972 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/include/asm-x86/hvm/hvm.h	Tue Nov 22 16:15:19 2011 +0800
@@ -212,6 +212,8 @@ int hvm_girq_dest_2_vcpu_id(struct domai
     (!!((v)->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PG))
 #define hvm_wp_enabled(v) \
     (!!((v)->arch.hvm_vcpu.guest_cr[0] & X86_CR0_WP))
+#define hvm_pcid_enabled(v) \
+    (!!((v)->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PCIDE))
 #define hvm_pae_enabled(v) \
     (hvm_paging_enabled(v) && ((v)->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PA=
E))
 #define hvm_smep_enabled(v) \
@@ -334,6 +336,7 @@ static inline int hvm_do_pmu_interrupt(s
         (cpu_has_fsgsbase ? X86_CR4_FSGSBASE : 0) |     \
         ((nestedhvm_enabled((_v)->domain) && cpu_has_vmx)\
                       ? X86_CR4_VMXE : 0)  |             \
+        (cpu_has_pcid ? X86_CR4_PCIDE : 0) |             \
         (xsave_enabled(_v) ? X86_CR4_OSXSAVE : 0))))
=20
 /* These exceptions must always be intercepted. */
diff -r c61a5ba8c972 xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h	Tue Nov 22 16:15:19 2011 +0800
@@ -184,6 +184,7 @@ extern u32 vmx_vmentry_control;
 #define SECONDARY_EXEC_WBINVD_EXITING           0x00000040
 #define SECONDARY_EXEC_UNRESTRICTED_GUEST       0x00000080
 #define SECONDARY_EXEC_PAUSE_LOOP_EXITING       0x00000400
+#define SECONDARY_EXEC_ENABLE_INVPCID           0x00001000
 extern u32 vmx_secondary_exec_control;
=20
 extern bool_t cpu_has_vmx_ins_outs_instr_info;
diff -r c61a5ba8c972 xen/include/asm-x86/hvm/vmx/vmx.h
--- a/xen/include/asm-x86/hvm/vmx/vmx.h	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h	Tue Nov 22 16:15:19 2011 +0800
@@ -129,6 +129,7 @@ void vmx_update_cpu_exec_control(struct=20
 #define EXIT_REASON_INVVPID             53
 #define EXIT_REASON_WBINVD              54
 #define EXIT_REASON_XSETBV              55
+#define EXIT_REASON_INVPCID             58
=20
 /*
  * Interruption-information format
diff -r c61a5ba8c972 xen/include/asm-x86/processor.h
--- a/xen/include/asm-x86/processor.h	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/include/asm-x86/processor.h	Tue Nov 22 16:15:19 2011 +0800
@@ -84,6 +84,7 @@
 #define X86_CR4_VMXE		0x2000  /* enable VMX */
 #define X86_CR4_SMXE		0x4000  /* enable SMX */
 #define X86_CR4_FSGSBASE	0x10000 /* enable {rd,wr}{fs,gs}base */
+#define X86_CR4_PCIDE		0x20000 /* enable PCID */
 #define X86_CR4_OSXSAVE	0x40000 /* enable XSAVE/XRSTOR */
 #define X86_CR4_SMEP		0x100000/* enable SMEP */
 =

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82shsmsx502ccrc_
Content-Type: application/octet-stream;
	name="6_implement_pcid_invpcid_for_hvm.patch"
Content-Description: 6_implement_pcid_invpcid_for_hvm.patch
Content-Disposition: attachment;
	filename="6_implement_pcid_invpcid_for_hvm.patch"; size=7908;
	creation-date="Thu, 24 Nov 2011 23:28:03 GMT";
	modification-date="Thu, 24 Nov 2011 23:14:16 GMT"
Content-Transfer-Encoding: base64

WDg2OiBpbXBsZW1lbnQgUENJRC9JTlZQQ0lEIGZvciBodm0KClRoaXMgcGF0Y2ggaGFuZGxlIFBD
SUQvSU5WUENJRCBmb3IgaHZtOgpGb3IgaGFwIGh2bSwgd2UgZW5hYmxlIFBDSUQvSU5WUENJRCwg
c2luY2Ugbm8gbmVlZCB0byBpbnRlcmNlcHQgSU5WUENJRCwgYW5kIHdlIGp1c3Qgc2V0IElOVlBD
SUQgbm9uLXJvb3QgYmVoYXZpb3IgYXMgcnVubmluZyBuYXRpdmVseTsKRm9yIHNoYWRvdyBodm0s
IHdlIGRpc2FibGUgUENJRC9JTlZQQ0lELCBvdGhlcndpc2Ugd2UgbmVlZCB0byBlbXVsYXRlIElO
VlBDSUQgYXQgdm1tIGJ5IHNldHRpbmcgSU5WUENJRCBub24tcm9vdCBiZWhhdmlvciBhcyB2bWV4
aXQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
CmRpZmYgLXIgYzYxYTViYThjOTcyIHhlbi9hcmNoL3g4Ni9odm0vaHZtLmMKLS0tIGEveGVuL2Fy
Y2gveDg2L2h2bS9odm0uYwlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2h2bS9odm0uYwlUdWUgTm92IDIyIDE2OjE1OjE5IDIwMTEgKzA4MDAKQEAgLTE1
NDksNiArMTU0OSwxMyBAQCBpbnQgaHZtX3NldF9jcjAodW5zaWduZWQgbG9uZyB2YWx1ZSkKICAg
ICB9CiAgICAgZWxzZSBpZiAoICEodmFsdWUgJiBYODZfQ1IwX1BHKSAmJiAob2xkX3ZhbHVlICYg
WDg2X0NSMF9QRykgKQogICAgIHsKKyAgICAgICAgaWYgKCBodm1fcGNpZF9lbmFibGVkKHYpICkK
KyAgICAgICAgeworICAgICAgICAgICAgSFZNX0RCR19MT0coREJHX0xFVkVMXzEsICJHdWVzdCBh
dHRlbXB0cyB0byBjbGVhciBDUjAuUEcgIgorICAgICAgICAgICAgICAgICAgICAgICAgIndoaWxl
IENSNC5QQ0lERT0xIik7CisgICAgICAgICAgICBnb3RvIGdwZjsKKyAgICAgICAgfQorCiAgICAg
ICAgIC8qIFdoZW4gQ1IwLlBHIGlzIGNsZWFyZWQsIExNQSBpcyBjbGVhcmVkIGltbWVkaWF0ZWx5
LiAqLwogICAgICAgICBpZiAoIGh2bV9sb25nX21vZGVfZW5hYmxlZCh2KSApCiAgICAgICAgIHsK
QEAgLTE2NjMsMTIgKzE2NzAsMjYgQEAgaW50IGh2bV9zZXRfY3I0KHVuc2lnbmVkIGxvbmcgdmFs
dWUpCiAgICAgfQogCiAgICAgb2xkX2NyID0gdi0+YXJjaC5odm1fdmNwdS5ndWVzdF9jcls0XTsK
KworICAgIGlmICggKHZhbHVlICYgWDg2X0NSNF9QQ0lERSkgJiYgIShvbGRfY3IgJiBYODZfQ1I0
X1BDSURFKSAmJgorICAgICAgICAoIWh2bV9sb25nX21vZGVfZW5hYmxlZCh2KSB8fCAodi0+YXJj
aC5odm1fdmNwdS5ndWVzdF9jclszXSAmIDB4ZmZmKSkgKQorICAgIHsKKyAgICAgICAgSFZNX0RC
R19MT0coREJHX0xFVkVMXzEsICJHdWVzdCBhdHRlbXB0cyB0byBjaGFuZ2UgQ1I0LlBDSURFIGZy
b20gIgorICAgICAgICAgICAgICAgICAgICAiMCB0byAxIHdoaWxlIGVpdGhlciBFRkVSLkxNQT0w
IG9yIENSM1sxMTowXSE9MDAwSCIpOworICAgICAgICBnb3RvIGdwZjsKKyAgICB9CisKICAgICB2
LT5hcmNoLmh2bV92Y3B1Lmd1ZXN0X2NyWzRdID0gdmFsdWU7CiAgICAgaHZtX3VwZGF0ZV9ndWVz
dF9jcih2LCA0KTsKIAotICAgIC8qIE1vZGlmeWluZyBDUjQue1BTRSxQQUUsUEdFLFNNRVB9IGlu
dmFsaWRhdGVzIGFsbCBUTEIgZW50cmllcy4gKi8KLSAgICBpZiAoIChvbGRfY3IgXiB2YWx1ZSkg
JiAoWDg2X0NSNF9QU0UgfCBYODZfQ1I0X1BHRSB8Ci0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFg4Nl9DUjRfUEFFIHwgWDg2X0NSNF9TTUVQKSApIHsKKyAgICAvKiAKKyAgICAgKiBNb2Rp
ZnlpbmcgQ1I0LntQU0UsUEFFLFBHRSxTTUVQfSwgb3IgY2xlYXJpbmcgQ1I0LlBDSURFCisgICAg
ICogaW52YWxpZGF0ZSBhbGwgVExCIGVudHJpZXMuCisgICAgICovCisgICAgaWYgKCAoKG9sZF9j
ciBeIHZhbHVlKSAmIAorICAgICAgICAgIChYODZfQ1I0X1BTRSB8IFg4Nl9DUjRfUEdFIHwgWDg2
X0NSNF9QQUUgfCBYODZfQ1I0X1NNRVApKSB8fAorICAgICAgICAgICAgKCEodmFsdWUgJiBYODZf
Q1I0X1BDSURFKSAmJiAob2xkX2NyICYgWDg2X0NSNF9QQ0lERSkpICkKKyAgICB7CiAgICAgICAg
IGlmICggIW5lc3RlZGh2bV92bXN3aXRjaF9pbl9wcm9ncmVzcyh2KSAmJiBuZXN0ZWRodm1fdmNw
dV9pbl9ndWVzdG1vZGUodikgKQogICAgICAgICAgICAgcGFnaW5nX3VwZGF0ZV9uZXN0ZWRtb2Rl
KHYpOwogICAgICAgICBlbHNlCkBAIC0yNDA5LDEwICsyNDMwLDE4IEBAIHZvaWQgaHZtX2NwdWlk
KHVuc2lnbmVkIGludCBpbnB1dCwgdW5zaWcKICAgICAgICAgaWYgKCB4c2F2ZV9lbmFibGVkKHYp
ICkKICAgICAgICAgICAgICplY3ggfD0gKHYtPmFyY2guaHZtX3ZjcHUuZ3Vlc3RfY3JbNF0gJiBY
ODZfQ1I0X09TWFNBVkUpID8KICAgICAgICAgICAgICAgICAgICAgIGNwdWZlYXRfbWFzayhYODZf
RkVBVFVSRV9PU1hTQVZFKSA6IDA7CisKKyAgICAgICAgLyogTm90IGV4cG9zZSBQQ0lEIHRvIG5v
bi1oYXAgaHZtICovCisgICAgICAgIGlmICggIWhhcF9lbmFibGVkKGQpICkKKyAgICAgICAgICAg
ICplY3ggJj0gfmNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9QQ0lEKTsKICAgICAgICAgYnJlYWs7
CiAgICAgY2FzZSAweDc6CiAgICAgICAgIGlmICggKGNvdW50ID09IDApICYmICFjcHVfaGFzX3Nt
ZXAgKQogICAgICAgICAgICAgKmVieCAmPSB+Y3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX1NNRVAp
OworCisgICAgICAgIC8qIE5vdCBleHBvc2UgSU5WUENJRCB0byBub24taGFwIGh2bSAqLworICAg
ICAgICBpZiAoIChjb3VudCA9PSAwKSAmJiAhaGFwX2VuYWJsZWQoZCkgKQorICAgICAgICAgICAg
KmVieCAmPSB+Y3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lOVlBDSUQpOwogICAgICAgICBicmVh
azsKICAgICBjYXNlIDB4YjoKICAgICAgICAgLyogRml4IHRoZSB4MkFQSUMgaWRlbnRpZmllci4g
Ki8KZGlmZiAtciBjNjFhNWJhOGM5NzIgeGVuL2FyY2gveDg2L2h2bS92bXgvdm1jcy5jCi0tLSBh
L3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZtY3MuYwlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEgKzA4
MDAKKysrIGIveGVuL2FyY2gveDg2L2h2bS92bXgvdm1jcy5jCVR1ZSBOb3YgMjIgMTY6MTU6MTkg
MjAxMSArMDgwMApAQCAtMTgzLDcgKzE4Myw4IEBAIHN0YXRpYyBpbnQgdm14X2luaXRfdm1jc19j
b25maWcodm9pZCkKICAgICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVDX1dCSU5WRF9FWElUSU5H
IHwKICAgICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVDX0VOQUJMRV9FUFQgfAogICAgICAgICAg
ICAgICAgU0VDT05EQVJZX0VYRUNfRU5BQkxFX1JEVFNDUCB8Ci0gICAgICAgICAgICAgICBTRUNP
TkRBUllfRVhFQ19QQVVTRV9MT09QX0VYSVRJTkcpOworICAgICAgICAgICAgICAgU0VDT05EQVJZ
X0VYRUNfUEFVU0VfTE9PUF9FWElUSU5HIHwKKyAgICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVD
X0VOQUJMRV9JTlZQQ0lEKTsKICAgICAgICAgaWYgKCBvcHRfdnBpZF9lbmFibGVkICkKICAgICAg
ICAgICAgIG9wdCB8PSBTRUNPTkRBUllfRVhFQ19FTkFCTEVfVlBJRDsKICAgICAgICAgaWYgKCBv
cHRfdW5yZXN0cmljdGVkX2d1ZXN0X2VuYWJsZWQgKQpAQCAtNzI2LDcgKzcyNyw4IEBAIHN0YXRp
YyBpbnQgY29uc3RydWN0X3ZtY3Moc3RydWN0IHZjcHUgKnYKICAgICB7CiAgICAgICAgIHYtPmFy
Y2guaHZtX3ZteC5zZWNvbmRhcnlfZXhlY19jb250cm9sICY9IAogICAgICAgICAgICAgfihTRUNP
TkRBUllfRVhFQ19FTkFCTEVfRVBUIHwgCi0gICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVDX1VO
UkVTVFJJQ1RFRF9HVUVTVCk7CisgICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVDX1VOUkVTVFJJ
Q1RFRF9HVUVTVCB8CisgICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVDX0VOQUJMRV9JTlZQQ0lE
KTsKICAgICAgICAgdm1leGl0X2N0bCAmPSB+KFZNX0VYSVRfU0FWRV9HVUVTVF9QQVQgfAogICAg
ICAgICAgICAgICAgICAgICAgICAgVk1fRVhJVF9MT0FEX0hPU1RfUEFUKTsKICAgICAgICAgdm1l
bnRyeV9jdGwgJj0gflZNX0VOVFJZX0xPQURfR1VFU1RfUEFUOwpkaWZmIC1yIGM2MWE1YmE4Yzk3
MiB4ZW4vYXJjaC94ODYvaHZtL3ZteC92bXguYwotLS0gYS94ZW4vYXJjaC94ODYvaHZtL3ZteC92
bXguYwlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2h2
bS92bXgvdm14LmMJVHVlIE5vdiAyMiAxNjoxNToxOSAyMDExICswODAwCkBAIC0xMDA0LDcgKzEw
MDQsNyBAQCBzdGF0aWMgdm9pZCB2bXhfbG9hZF9wZHB0cnMoc3RydWN0IHZjcHUgCiAgICAgaWYg
KCAhaHZtX3BhZV9lbmFibGVkKHYpIHx8ICh2LT5hcmNoLmh2bV92Y3B1Lmd1ZXN0X2VmZXIgJiBF
RkVSX0xNQSkgKQogICAgICAgICByZXR1cm47CiAKLSAgICBpZiAoIGNyMyAmIDB4MWZVTCApCisg
ICAgaWYgKCAoY3IzICYgMHgxZlVMKSAmJiAhaHZtX3BjaWRfZW5hYmxlZCh2KSApCiAgICAgICAg
IGdvdG8gY3Jhc2g7CiAKICAgICBtZm4gPSBtZm5feChnZm5fdG9fbWZuKHYtPmRvbWFpbiwgY3Iz
ID4+IFBBR0VfU0hJRlQsICZwMm10KSk7CkBAIC0yNjYxLDYgKzI2NjEsNyBAQCBhc21saW5rYWdl
IHZvaWQgdm14X3ZtZXhpdF9oYW5kbGVyKHN0cnVjCiAgICAgY2FzZSBFWElUX1JFQVNPTl9BQ0NF
U1NfR0RUUl9PUl9JRFRSOgogICAgIGNhc2UgRVhJVF9SRUFTT05fQUNDRVNTX0xEVFJfT1JfVFI6
CiAgICAgY2FzZSBFWElUX1JFQVNPTl9WTVhfUFJFRU1QVElPTl9USU1FUl9FWFBJUkVEOgorICAg
IGNhc2UgRVhJVF9SRUFTT05fSU5WUENJRDoKICAgICAvKiBmYWxsIHRocm91Z2ggKi8KICAgICBk
ZWZhdWx0OgogICAgIGV4aXRfYW5kX2NyYXNoOgpkaWZmIC1yIGM2MWE1YmE4Yzk3MiB4ZW4vaW5j
bHVkZS9hc20teDg2L2NwdWZlYXR1cmUuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZl
YXR1cmUuaAlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUv
YXNtLXg4Ni9jcHVmZWF0dXJlLmgJVHVlIE5vdiAyMiAxNjoxNToxOSAyMDExICswODAwCkBAIC0y
MjQsNiArMjI0LDggQEAKIAogI2RlZmluZSBjcHVfaGFzX3gyYXBpYyAgICAgICAgICBib290X2Nw
dV9oYXMoWDg2X0ZFQVRVUkVfWDJBUElDKQogCisjZGVmaW5lIGNwdV9oYXNfcGNpZCAgICAgICAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9QQ0lEKQorCiAjZGVmaW5lIGNwdV9oYXNfeHNh
dmUgICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9YU0FWRSkKIAogI2RlZmluZSBj
cHVfaGFzX2x3cCAgICAgICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfTFdQKQpkaWZm
IC1yIGM2MWE1YmE4Yzk3MiB4ZW4vaW5jbHVkZS9hc20teDg2L2h2bS9odm0uaAotLS0gYS94ZW4v
aW5jbHVkZS9hc20teDg2L2h2bS9odm0uaAlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEgKzA4MDAK
KysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vaHZtLmgJVHVlIE5vdiAyMiAxNjoxNToxOSAy
MDExICswODAwCkBAIC0yMTIsNiArMjEyLDggQEAgaW50IGh2bV9naXJxX2Rlc3RfMl92Y3B1X2lk
KHN0cnVjdCBkb21haQogICAgICghISgodiktPmFyY2guaHZtX3ZjcHUuZ3Vlc3RfY3JbMF0gJiBY
ODZfQ1IwX1BHKSkKICNkZWZpbmUgaHZtX3dwX2VuYWJsZWQodikgXAogICAgICghISgodiktPmFy
Y2guaHZtX3ZjcHUuZ3Vlc3RfY3JbMF0gJiBYODZfQ1IwX1dQKSkKKyNkZWZpbmUgaHZtX3BjaWRf
ZW5hYmxlZCh2KSBcCisgICAgKCEhKCh2KS0+YXJjaC5odm1fdmNwdS5ndWVzdF9jcls0XSAmIFg4
Nl9DUjRfUENJREUpKQogI2RlZmluZSBodm1fcGFlX2VuYWJsZWQodikgXAogICAgIChodm1fcGFn
aW5nX2VuYWJsZWQodikgJiYgKCh2KS0+YXJjaC5odm1fdmNwdS5ndWVzdF9jcls0XSAmIFg4Nl9D
UjRfUEFFKSkKICNkZWZpbmUgaHZtX3NtZXBfZW5hYmxlZCh2KSBcCkBAIC0zMzQsNiArMzM2LDcg
QEAgc3RhdGljIGlubGluZSBpbnQgaHZtX2RvX3BtdV9pbnRlcnJ1cHQocwogICAgICAgICAoY3B1
X2hhc19mc2dzYmFzZSA/IFg4Nl9DUjRfRlNHU0JBU0UgOiAwKSB8ICAgICBcCiAgICAgICAgICgo
bmVzdGVkaHZtX2VuYWJsZWQoKF92KS0+ZG9tYWluKSAmJiBjcHVfaGFzX3ZteClcCiAgICAgICAg
ICAgICAgICAgICAgICAgPyBYODZfQ1I0X1ZNWEUgOiAwKSAgfCAgICAgICAgICAgICBcCisgICAg
ICAgIChjcHVfaGFzX3BjaWQgPyBYODZfQ1I0X1BDSURFIDogMCkgfCAgICAgICAgICAgICBcCiAg
ICAgICAgICh4c2F2ZV9lbmFibGVkKF92KSA/IFg4Nl9DUjRfT1NYU0FWRSA6IDApKSkpCiAKIC8q
IFRoZXNlIGV4Y2VwdGlvbnMgbXVzdCBhbHdheXMgYmUgaW50ZXJjZXB0ZWQuICovCmRpZmYgLXIg
YzYxYTViYThjOTcyIHhlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZteC92bWNzLmgKLS0tIGEveGVu
L2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZtY3MuaAlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEg
KzA4MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZtY3MuaAlUdWUgTm92IDIy
IDE2OjE1OjE5IDIwMTEgKzA4MDAKQEAgLTE4NCw2ICsxODQsNyBAQCBleHRlcm4gdTMyIHZteF92
bWVudHJ5X2NvbnRyb2w7CiAjZGVmaW5lIFNFQ09OREFSWV9FWEVDX1dCSU5WRF9FWElUSU5HICAg
ICAgICAgICAweDAwMDAwMDQwCiAjZGVmaW5lIFNFQ09OREFSWV9FWEVDX1VOUkVTVFJJQ1RFRF9H
VUVTVCAgICAgICAweDAwMDAwMDgwCiAjZGVmaW5lIFNFQ09OREFSWV9FWEVDX1BBVVNFX0xPT1Bf
RVhJVElORyAgICAgICAweDAwMDAwNDAwCisjZGVmaW5lIFNFQ09OREFSWV9FWEVDX0VOQUJMRV9J
TlZQQ0lEICAgICAgICAgICAweDAwMDAxMDAwCiBleHRlcm4gdTMyIHZteF9zZWNvbmRhcnlfZXhl
Y19jb250cm9sOwogCiBleHRlcm4gYm9vbF90IGNwdV9oYXNfdm14X2luc19vdXRzX2luc3RyX2lu
Zm87CmRpZmYgLXIgYzYxYTViYThjOTcyIHhlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZteC92bXgu
aAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS92bXgvdm14LmgJVHVlIE5vdiAyMiAwMjo0
Nzo1MSAyMDExICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZteC92bXguaAlU
dWUgTm92IDIyIDE2OjE1OjE5IDIwMTEgKzA4MDAKQEAgLTEyOSw2ICsxMjksNyBAQCB2b2lkIHZt
eF91cGRhdGVfY3B1X2V4ZWNfY29udHJvbChzdHJ1Y3QgCiAjZGVmaW5lIEVYSVRfUkVBU09OX0lO
VlZQSUQgICAgICAgICAgICAgNTMKICNkZWZpbmUgRVhJVF9SRUFTT05fV0JJTlZEICAgICAgICAg
ICAgICA1NAogI2RlZmluZSBFWElUX1JFQVNPTl9YU0VUQlYgICAgICAgICAgICAgIDU1CisjZGVm
aW5lIEVYSVRfUkVBU09OX0lOVlBDSUQgICAgICAgICAgICAgNTgKIAogLyoKICAqIEludGVycnVw
dGlvbi1pbmZvcm1hdGlvbiBmb3JtYXQKZGlmZiAtciBjNjFhNWJhOGM5NzIgeGVuL2luY2x1ZGUv
YXNtLXg4Ni9wcm9jZXNzb3IuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L3Byb2Nlc3Nvci5o
CVR1ZSBOb3YgMjIgMDI6NDc6NTEgMjAxMSArMDgwMAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2
L3Byb2Nlc3Nvci5oCVR1ZSBOb3YgMjIgMTY6MTU6MTkgMjAxMSArMDgwMApAQCAtODQsNiArODQs
NyBAQAogI2RlZmluZSBYODZfQ1I0X1ZNWEUJCTB4MjAwMCAgLyogZW5hYmxlIFZNWCAqLwogI2Rl
ZmluZSBYODZfQ1I0X1NNWEUJCTB4NDAwMCAgLyogZW5hYmxlIFNNWCAqLwogI2RlZmluZSBYODZf
Q1I0X0ZTR1NCQVNFCTB4MTAwMDAgLyogZW5hYmxlIHtyZCx3cn17ZnMsZ3N9YmFzZSAqLworI2Rl
ZmluZSBYODZfQ1I0X1BDSURFCQkweDIwMDAwIC8qIGVuYWJsZSBQQ0lEICovCiAjZGVmaW5lIFg4
Nl9DUjRfT1NYU0FWRQkweDQwMDAwIC8qIGVuYWJsZSBYU0FWRS9YUlNUT1IgKi8KICNkZWZpbmUg
WDg2X0NSNF9TTUVQCQkweDEwMDAwMC8qIGVuYWJsZSBTTUVQICovCiAK

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:58:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:58:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbh7-0001AD-Bi; Thu, 24 Nov 2011 15:58:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RTbh5-00019W-TC
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:58:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322150282!2898509!1
X-Originating-IP: [134.134.136.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28914 invoked from network); 24 Nov 2011 15:58:03 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-11.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 15:58:03 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Nov 2011 07:58:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="79663152"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga002.jf.intel.com with ESMTP; 24 Nov 2011 07:58:00 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:57:59 +0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Thu, 24 Nov 2011 23:57:59 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Thu, 24 Nov 2011 23:57:57 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 23:57:54 +0800
Thread-Topic: [PATCH 6/6] X86: implement PCID/INVPCID for hvm
Thread-Index: AcyqwdOaqDg2NcrBTauPGnqGECe41w==
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82@shsmsx502.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82shsmsx502ccrc_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 6/6] X86: implement PCID/INVPCID for hvm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86: implement PCID/INVPCID for hvm

This patch handle PCID/INVPCID for hvm:
For hap hvm, we enable PCID/INVPCID, since no need to intercept INVPCID, an=
d we just set INVPCID non-root behavior as running natively;
For shadow hvm, we disable PCID/INVPCID, otherwise we need to emulate INVPC=
ID at vmm by setting INVPCID non-root behavior as vmexit.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r c61a5ba8c972 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/arch/x86/hvm/hvm.c	Tue Nov 22 16:15:19 2011 +0800
@@ -1549,6 +1549,13 @@ int hvm_set_cr0(unsigned long value)
     }
     else if ( !(value & X86_CR0_PG) && (old_value & X86_CR0_PG) )
     {
+        if ( hvm_pcid_enabled(v) )
+        {
+            HVM_DBG_LOG(DBG_LEVEL_1, "Guest attempts to clear CR0.PG "
+                        "while CR4.PCIDE=3D1");
+            goto gpf;
+        }
+
         /* When CR0.PG is cleared, LMA is cleared immediately. */
         if ( hvm_long_mode_enabled(v) )
         {
@@ -1663,12 +1670,26 @@ int hvm_set_cr4(unsigned long value)
     }
=20
     old_cr =3D v->arch.hvm_vcpu.guest_cr[4];
+
+    if ( (value & X86_CR4_PCIDE) && !(old_cr & X86_CR4_PCIDE) &&
+        (!hvm_long_mode_enabled(v) || (v->arch.hvm_vcpu.guest_cr[3] & 0xff=
f)) )
+    {
+        HVM_DBG_LOG(DBG_LEVEL_1, "Guest attempts to change CR4.PCIDE from =
"
+                    "0 to 1 while either EFER.LMA=3D0 or CR3[11:0]!=3D000H=
");
+        goto gpf;
+    }
+
     v->arch.hvm_vcpu.guest_cr[4] =3D value;
     hvm_update_guest_cr(v, 4);
=20
-    /* Modifying CR4.{PSE,PAE,PGE,SMEP} invalidates all TLB entries. */
-    if ( (old_cr ^ value) & (X86_CR4_PSE | X86_CR4_PGE |
-                             X86_CR4_PAE | X86_CR4_SMEP) ) {
+    /*=20
+     * Modifying CR4.{PSE,PAE,PGE,SMEP}, or clearing CR4.PCIDE
+     * invalidate all TLB entries.
+     */
+    if ( ((old_cr ^ value) &=20
+          (X86_CR4_PSE | X86_CR4_PGE | X86_CR4_PAE | X86_CR4_SMEP)) ||
+            (!(value & X86_CR4_PCIDE) && (old_cr & X86_CR4_PCIDE)) )
+    {
         if ( !nestedhvm_vmswitch_in_progress(v) && nestedhvm_vcpu_in_guest=
mode(v) )
             paging_update_nestedmode(v);
         else
@@ -2409,10 +2430,18 @@ void hvm_cpuid(unsigned int input, unsig
         if ( xsave_enabled(v) )
             *ecx |=3D (v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_OSXSAVE) ?
                      cpufeat_mask(X86_FEATURE_OSXSAVE) : 0;
+
+        /* Not expose PCID to non-hap hvm */
+        if ( !hap_enabled(d) )
+            *ecx &=3D ~cpufeat_mask(X86_FEATURE_PCID);
         break;
     case 0x7:
         if ( (count =3D=3D 0) && !cpu_has_smep )
             *ebx &=3D ~cpufeat_mask(X86_FEATURE_SMEP);
+
+        /* Not expose INVPCID to non-hap hvm */
+        if ( (count =3D=3D 0) && !hap_enabled(d) )
+            *ebx &=3D ~cpufeat_mask(X86_FEATURE_INVPCID);
         break;
     case 0xb:
         /* Fix the x2APIC identifier. */
diff -r c61a5ba8c972 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Tue Nov 22 16:15:19 2011 +0800
@@ -183,7 +183,8 @@ static int vmx_init_vmcs_config(void)
                SECONDARY_EXEC_WBINVD_EXITING |
                SECONDARY_EXEC_ENABLE_EPT |
                SECONDARY_EXEC_ENABLE_RDTSCP |
-               SECONDARY_EXEC_PAUSE_LOOP_EXITING);
+               SECONDARY_EXEC_PAUSE_LOOP_EXITING |
+               SECONDARY_EXEC_ENABLE_INVPCID);
         if ( opt_vpid_enabled )
             opt |=3D SECONDARY_EXEC_ENABLE_VPID;
         if ( opt_unrestricted_guest_enabled )
@@ -726,7 +727,8 @@ static int construct_vmcs(struct vcpu *v
     {
         v->arch.hvm_vmx.secondary_exec_control &=3D=20
             ~(SECONDARY_EXEC_ENABLE_EPT |=20
-              SECONDARY_EXEC_UNRESTRICTED_GUEST);
+              SECONDARY_EXEC_UNRESTRICTED_GUEST |
+              SECONDARY_EXEC_ENABLE_INVPCID);
         vmexit_ctl &=3D ~(VM_EXIT_SAVE_GUEST_PAT |
                         VM_EXIT_LOAD_HOST_PAT);
         vmentry_ctl &=3D ~VM_ENTRY_LOAD_GUEST_PAT;
diff -r c61a5ba8c972 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Tue Nov 22 16:15:19 2011 +0800
@@ -1004,7 +1004,7 @@ static void vmx_load_pdptrs(struct vcpu=20
     if ( !hvm_pae_enabled(v) || (v->arch.hvm_vcpu.guest_efer & EFER_LMA) )
         return;
=20
-    if ( cr3 & 0x1fUL )
+    if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) )
         goto crash;
=20
     mfn =3D mfn_x(gfn_to_mfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt));
@@ -2661,6 +2661,7 @@ asmlinkage void vmx_vmexit_handler(struc
     case EXIT_REASON_ACCESS_GDTR_OR_IDTR:
     case EXIT_REASON_ACCESS_LDTR_OR_TR:
     case EXIT_REASON_VMX_PREEMPTION_TIMER_EXPIRED:
+    case EXIT_REASON_INVPCID:
     /* fall through */
     default:
     exit_and_crash:
diff -r c61a5ba8c972 xen/include/asm-x86/cpufeature.h
--- a/xen/include/asm-x86/cpufeature.h	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/include/asm-x86/cpufeature.h	Tue Nov 22 16:15:19 2011 +0800
@@ -224,6 +224,8 @@
=20
 #define cpu_has_x2apic          boot_cpu_has(X86_FEATURE_X2APIC)
=20
+#define cpu_has_pcid            boot_cpu_has(X86_FEATURE_PCID)
+
 #define cpu_has_xsave           boot_cpu_has(X86_FEATURE_XSAVE)
=20
 #define cpu_has_lwp             boot_cpu_has(X86_FEATURE_LWP)
diff -r c61a5ba8c972 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/include/asm-x86/hvm/hvm.h	Tue Nov 22 16:15:19 2011 +0800
@@ -212,6 +212,8 @@ int hvm_girq_dest_2_vcpu_id(struct domai
     (!!((v)->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PG))
 #define hvm_wp_enabled(v) \
     (!!((v)->arch.hvm_vcpu.guest_cr[0] & X86_CR0_WP))
+#define hvm_pcid_enabled(v) \
+    (!!((v)->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PCIDE))
 #define hvm_pae_enabled(v) \
     (hvm_paging_enabled(v) && ((v)->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PA=
E))
 #define hvm_smep_enabled(v) \
@@ -334,6 +336,7 @@ static inline int hvm_do_pmu_interrupt(s
         (cpu_has_fsgsbase ? X86_CR4_FSGSBASE : 0) |     \
         ((nestedhvm_enabled((_v)->domain) && cpu_has_vmx)\
                       ? X86_CR4_VMXE : 0)  |             \
+        (cpu_has_pcid ? X86_CR4_PCIDE : 0) |             \
         (xsave_enabled(_v) ? X86_CR4_OSXSAVE : 0))))
=20
 /* These exceptions must always be intercepted. */
diff -r c61a5ba8c972 xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h	Tue Nov 22 16:15:19 2011 +0800
@@ -184,6 +184,7 @@ extern u32 vmx_vmentry_control;
 #define SECONDARY_EXEC_WBINVD_EXITING           0x00000040
 #define SECONDARY_EXEC_UNRESTRICTED_GUEST       0x00000080
 #define SECONDARY_EXEC_PAUSE_LOOP_EXITING       0x00000400
+#define SECONDARY_EXEC_ENABLE_INVPCID           0x00001000
 extern u32 vmx_secondary_exec_control;
=20
 extern bool_t cpu_has_vmx_ins_outs_instr_info;
diff -r c61a5ba8c972 xen/include/asm-x86/hvm/vmx/vmx.h
--- a/xen/include/asm-x86/hvm/vmx/vmx.h	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h	Tue Nov 22 16:15:19 2011 +0800
@@ -129,6 +129,7 @@ void vmx_update_cpu_exec_control(struct=20
 #define EXIT_REASON_INVVPID             53
 #define EXIT_REASON_WBINVD              54
 #define EXIT_REASON_XSETBV              55
+#define EXIT_REASON_INVPCID             58
=20
 /*
  * Interruption-information format
diff -r c61a5ba8c972 xen/include/asm-x86/processor.h
--- a/xen/include/asm-x86/processor.h	Tue Nov 22 02:47:51 2011 +0800
+++ b/xen/include/asm-x86/processor.h	Tue Nov 22 16:15:19 2011 +0800
@@ -84,6 +84,7 @@
 #define X86_CR4_VMXE		0x2000  /* enable VMX */
 #define X86_CR4_SMXE		0x4000  /* enable SMX */
 #define X86_CR4_FSGSBASE	0x10000 /* enable {rd,wr}{fs,gs}base */
+#define X86_CR4_PCIDE		0x20000 /* enable PCID */
 #define X86_CR4_OSXSAVE	0x40000 /* enable XSAVE/XRSTOR */
 #define X86_CR4_SMEP		0x100000/* enable SMEP */
 =

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82shsmsx502ccrc_
Content-Type: application/octet-stream;
	name="6_implement_pcid_invpcid_for_hvm.patch"
Content-Description: 6_implement_pcid_invpcid_for_hvm.patch
Content-Disposition: attachment;
	filename="6_implement_pcid_invpcid_for_hvm.patch"; size=7908;
	creation-date="Thu, 24 Nov 2011 23:28:03 GMT";
	modification-date="Thu, 24 Nov 2011 23:14:16 GMT"
Content-Transfer-Encoding: base64

WDg2OiBpbXBsZW1lbnQgUENJRC9JTlZQQ0lEIGZvciBodm0KClRoaXMgcGF0Y2ggaGFuZGxlIFBD
SUQvSU5WUENJRCBmb3IgaHZtOgpGb3IgaGFwIGh2bSwgd2UgZW5hYmxlIFBDSUQvSU5WUENJRCwg
c2luY2Ugbm8gbmVlZCB0byBpbnRlcmNlcHQgSU5WUENJRCwgYW5kIHdlIGp1c3Qgc2V0IElOVlBD
SUQgbm9uLXJvb3QgYmVoYXZpb3IgYXMgcnVubmluZyBuYXRpdmVseTsKRm9yIHNoYWRvdyBodm0s
IHdlIGRpc2FibGUgUENJRC9JTlZQQ0lELCBvdGhlcndpc2Ugd2UgbmVlZCB0byBlbXVsYXRlIElO
VlBDSUQgYXQgdm1tIGJ5IHNldHRpbmcgSU5WUENJRCBub24tcm9vdCBiZWhhdmlvciBhcyB2bWV4
aXQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4K
CmRpZmYgLXIgYzYxYTViYThjOTcyIHhlbi9hcmNoL3g4Ni9odm0vaHZtLmMKLS0tIGEveGVuL2Fy
Y2gveDg2L2h2bS9odm0uYwlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2h2bS9odm0uYwlUdWUgTm92IDIyIDE2OjE1OjE5IDIwMTEgKzA4MDAKQEAgLTE1
NDksNiArMTU0OSwxMyBAQCBpbnQgaHZtX3NldF9jcjAodW5zaWduZWQgbG9uZyB2YWx1ZSkKICAg
ICB9CiAgICAgZWxzZSBpZiAoICEodmFsdWUgJiBYODZfQ1IwX1BHKSAmJiAob2xkX3ZhbHVlICYg
WDg2X0NSMF9QRykgKQogICAgIHsKKyAgICAgICAgaWYgKCBodm1fcGNpZF9lbmFibGVkKHYpICkK
KyAgICAgICAgeworICAgICAgICAgICAgSFZNX0RCR19MT0coREJHX0xFVkVMXzEsICJHdWVzdCBh
dHRlbXB0cyB0byBjbGVhciBDUjAuUEcgIgorICAgICAgICAgICAgICAgICAgICAgICAgIndoaWxl
IENSNC5QQ0lERT0xIik7CisgICAgICAgICAgICBnb3RvIGdwZjsKKyAgICAgICAgfQorCiAgICAg
ICAgIC8qIFdoZW4gQ1IwLlBHIGlzIGNsZWFyZWQsIExNQSBpcyBjbGVhcmVkIGltbWVkaWF0ZWx5
LiAqLwogICAgICAgICBpZiAoIGh2bV9sb25nX21vZGVfZW5hYmxlZCh2KSApCiAgICAgICAgIHsK
QEAgLTE2NjMsMTIgKzE2NzAsMjYgQEAgaW50IGh2bV9zZXRfY3I0KHVuc2lnbmVkIGxvbmcgdmFs
dWUpCiAgICAgfQogCiAgICAgb2xkX2NyID0gdi0+YXJjaC5odm1fdmNwdS5ndWVzdF9jcls0XTsK
KworICAgIGlmICggKHZhbHVlICYgWDg2X0NSNF9QQ0lERSkgJiYgIShvbGRfY3IgJiBYODZfQ1I0
X1BDSURFKSAmJgorICAgICAgICAoIWh2bV9sb25nX21vZGVfZW5hYmxlZCh2KSB8fCAodi0+YXJj
aC5odm1fdmNwdS5ndWVzdF9jclszXSAmIDB4ZmZmKSkgKQorICAgIHsKKyAgICAgICAgSFZNX0RC
R19MT0coREJHX0xFVkVMXzEsICJHdWVzdCBhdHRlbXB0cyB0byBjaGFuZ2UgQ1I0LlBDSURFIGZy
b20gIgorICAgICAgICAgICAgICAgICAgICAiMCB0byAxIHdoaWxlIGVpdGhlciBFRkVSLkxNQT0w
IG9yIENSM1sxMTowXSE9MDAwSCIpOworICAgICAgICBnb3RvIGdwZjsKKyAgICB9CisKICAgICB2
LT5hcmNoLmh2bV92Y3B1Lmd1ZXN0X2NyWzRdID0gdmFsdWU7CiAgICAgaHZtX3VwZGF0ZV9ndWVz
dF9jcih2LCA0KTsKIAotICAgIC8qIE1vZGlmeWluZyBDUjQue1BTRSxQQUUsUEdFLFNNRVB9IGlu
dmFsaWRhdGVzIGFsbCBUTEIgZW50cmllcy4gKi8KLSAgICBpZiAoIChvbGRfY3IgXiB2YWx1ZSkg
JiAoWDg2X0NSNF9QU0UgfCBYODZfQ1I0X1BHRSB8Ci0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFg4Nl9DUjRfUEFFIHwgWDg2X0NSNF9TTUVQKSApIHsKKyAgICAvKiAKKyAgICAgKiBNb2Rp
ZnlpbmcgQ1I0LntQU0UsUEFFLFBHRSxTTUVQfSwgb3IgY2xlYXJpbmcgQ1I0LlBDSURFCisgICAg
ICogaW52YWxpZGF0ZSBhbGwgVExCIGVudHJpZXMuCisgICAgICovCisgICAgaWYgKCAoKG9sZF9j
ciBeIHZhbHVlKSAmIAorICAgICAgICAgIChYODZfQ1I0X1BTRSB8IFg4Nl9DUjRfUEdFIHwgWDg2
X0NSNF9QQUUgfCBYODZfQ1I0X1NNRVApKSB8fAorICAgICAgICAgICAgKCEodmFsdWUgJiBYODZf
Q1I0X1BDSURFKSAmJiAob2xkX2NyICYgWDg2X0NSNF9QQ0lERSkpICkKKyAgICB7CiAgICAgICAg
IGlmICggIW5lc3RlZGh2bV92bXN3aXRjaF9pbl9wcm9ncmVzcyh2KSAmJiBuZXN0ZWRodm1fdmNw
dV9pbl9ndWVzdG1vZGUodikgKQogICAgICAgICAgICAgcGFnaW5nX3VwZGF0ZV9uZXN0ZWRtb2Rl
KHYpOwogICAgICAgICBlbHNlCkBAIC0yNDA5LDEwICsyNDMwLDE4IEBAIHZvaWQgaHZtX2NwdWlk
KHVuc2lnbmVkIGludCBpbnB1dCwgdW5zaWcKICAgICAgICAgaWYgKCB4c2F2ZV9lbmFibGVkKHYp
ICkKICAgICAgICAgICAgICplY3ggfD0gKHYtPmFyY2guaHZtX3ZjcHUuZ3Vlc3RfY3JbNF0gJiBY
ODZfQ1I0X09TWFNBVkUpID8KICAgICAgICAgICAgICAgICAgICAgIGNwdWZlYXRfbWFzayhYODZf
RkVBVFVSRV9PU1hTQVZFKSA6IDA7CisKKyAgICAgICAgLyogTm90IGV4cG9zZSBQQ0lEIHRvIG5v
bi1oYXAgaHZtICovCisgICAgICAgIGlmICggIWhhcF9lbmFibGVkKGQpICkKKyAgICAgICAgICAg
ICplY3ggJj0gfmNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9QQ0lEKTsKICAgICAgICAgYnJlYWs7
CiAgICAgY2FzZSAweDc6CiAgICAgICAgIGlmICggKGNvdW50ID09IDApICYmICFjcHVfaGFzX3Nt
ZXAgKQogICAgICAgICAgICAgKmVieCAmPSB+Y3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX1NNRVAp
OworCisgICAgICAgIC8qIE5vdCBleHBvc2UgSU5WUENJRCB0byBub24taGFwIGh2bSAqLworICAg
ICAgICBpZiAoIChjb3VudCA9PSAwKSAmJiAhaGFwX2VuYWJsZWQoZCkgKQorICAgICAgICAgICAg
KmVieCAmPSB+Y3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lOVlBDSUQpOwogICAgICAgICBicmVh
azsKICAgICBjYXNlIDB4YjoKICAgICAgICAgLyogRml4IHRoZSB4MkFQSUMgaWRlbnRpZmllci4g
Ki8KZGlmZiAtciBjNjFhNWJhOGM5NzIgeGVuL2FyY2gveDg2L2h2bS92bXgvdm1jcy5jCi0tLSBh
L3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZtY3MuYwlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEgKzA4
MDAKKysrIGIveGVuL2FyY2gveDg2L2h2bS92bXgvdm1jcy5jCVR1ZSBOb3YgMjIgMTY6MTU6MTkg
MjAxMSArMDgwMApAQCAtMTgzLDcgKzE4Myw4IEBAIHN0YXRpYyBpbnQgdm14X2luaXRfdm1jc19j
b25maWcodm9pZCkKICAgICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVDX1dCSU5WRF9FWElUSU5H
IHwKICAgICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVDX0VOQUJMRV9FUFQgfAogICAgICAgICAg
ICAgICAgU0VDT05EQVJZX0VYRUNfRU5BQkxFX1JEVFNDUCB8Ci0gICAgICAgICAgICAgICBTRUNP
TkRBUllfRVhFQ19QQVVTRV9MT09QX0VYSVRJTkcpOworICAgICAgICAgICAgICAgU0VDT05EQVJZ
X0VYRUNfUEFVU0VfTE9PUF9FWElUSU5HIHwKKyAgICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVD
X0VOQUJMRV9JTlZQQ0lEKTsKICAgICAgICAgaWYgKCBvcHRfdnBpZF9lbmFibGVkICkKICAgICAg
ICAgICAgIG9wdCB8PSBTRUNPTkRBUllfRVhFQ19FTkFCTEVfVlBJRDsKICAgICAgICAgaWYgKCBv
cHRfdW5yZXN0cmljdGVkX2d1ZXN0X2VuYWJsZWQgKQpAQCAtNzI2LDcgKzcyNyw4IEBAIHN0YXRp
YyBpbnQgY29uc3RydWN0X3ZtY3Moc3RydWN0IHZjcHUgKnYKICAgICB7CiAgICAgICAgIHYtPmFy
Y2guaHZtX3ZteC5zZWNvbmRhcnlfZXhlY19jb250cm9sICY9IAogICAgICAgICAgICAgfihTRUNP
TkRBUllfRVhFQ19FTkFCTEVfRVBUIHwgCi0gICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVDX1VO
UkVTVFJJQ1RFRF9HVUVTVCk7CisgICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVDX1VOUkVTVFJJ
Q1RFRF9HVUVTVCB8CisgICAgICAgICAgICAgIFNFQ09OREFSWV9FWEVDX0VOQUJMRV9JTlZQQ0lE
KTsKICAgICAgICAgdm1leGl0X2N0bCAmPSB+KFZNX0VYSVRfU0FWRV9HVUVTVF9QQVQgfAogICAg
ICAgICAgICAgICAgICAgICAgICAgVk1fRVhJVF9MT0FEX0hPU1RfUEFUKTsKICAgICAgICAgdm1l
bnRyeV9jdGwgJj0gflZNX0VOVFJZX0xPQURfR1VFU1RfUEFUOwpkaWZmIC1yIGM2MWE1YmE4Yzk3
MiB4ZW4vYXJjaC94ODYvaHZtL3ZteC92bXguYwotLS0gYS94ZW4vYXJjaC94ODYvaHZtL3ZteC92
bXguYwlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2h2
bS92bXgvdm14LmMJVHVlIE5vdiAyMiAxNjoxNToxOSAyMDExICswODAwCkBAIC0xMDA0LDcgKzEw
MDQsNyBAQCBzdGF0aWMgdm9pZCB2bXhfbG9hZF9wZHB0cnMoc3RydWN0IHZjcHUgCiAgICAgaWYg
KCAhaHZtX3BhZV9lbmFibGVkKHYpIHx8ICh2LT5hcmNoLmh2bV92Y3B1Lmd1ZXN0X2VmZXIgJiBF
RkVSX0xNQSkgKQogICAgICAgICByZXR1cm47CiAKLSAgICBpZiAoIGNyMyAmIDB4MWZVTCApCisg
ICAgaWYgKCAoY3IzICYgMHgxZlVMKSAmJiAhaHZtX3BjaWRfZW5hYmxlZCh2KSApCiAgICAgICAg
IGdvdG8gY3Jhc2g7CiAKICAgICBtZm4gPSBtZm5feChnZm5fdG9fbWZuKHYtPmRvbWFpbiwgY3Iz
ID4+IFBBR0VfU0hJRlQsICZwMm10KSk7CkBAIC0yNjYxLDYgKzI2NjEsNyBAQCBhc21saW5rYWdl
IHZvaWQgdm14X3ZtZXhpdF9oYW5kbGVyKHN0cnVjCiAgICAgY2FzZSBFWElUX1JFQVNPTl9BQ0NF
U1NfR0RUUl9PUl9JRFRSOgogICAgIGNhc2UgRVhJVF9SRUFTT05fQUNDRVNTX0xEVFJfT1JfVFI6
CiAgICAgY2FzZSBFWElUX1JFQVNPTl9WTVhfUFJFRU1QVElPTl9USU1FUl9FWFBJUkVEOgorICAg
IGNhc2UgRVhJVF9SRUFTT05fSU5WUENJRDoKICAgICAvKiBmYWxsIHRocm91Z2ggKi8KICAgICBk
ZWZhdWx0OgogICAgIGV4aXRfYW5kX2NyYXNoOgpkaWZmIC1yIGM2MWE1YmE4Yzk3MiB4ZW4vaW5j
bHVkZS9hc20teDg2L2NwdWZlYXR1cmUuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2NwdWZl
YXR1cmUuaAlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUv
YXNtLXg4Ni9jcHVmZWF0dXJlLmgJVHVlIE5vdiAyMiAxNjoxNToxOSAyMDExICswODAwCkBAIC0y
MjQsNiArMjI0LDggQEAKIAogI2RlZmluZSBjcHVfaGFzX3gyYXBpYyAgICAgICAgICBib290X2Nw
dV9oYXMoWDg2X0ZFQVRVUkVfWDJBUElDKQogCisjZGVmaW5lIGNwdV9oYXNfcGNpZCAgICAgICAg
ICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9QQ0lEKQorCiAjZGVmaW5lIGNwdV9oYXNfeHNh
dmUgICAgICAgICAgIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9YU0FWRSkKIAogI2RlZmluZSBj
cHVfaGFzX2x3cCAgICAgICAgICAgICBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfTFdQKQpkaWZm
IC1yIGM2MWE1YmE4Yzk3MiB4ZW4vaW5jbHVkZS9hc20teDg2L2h2bS9odm0uaAotLS0gYS94ZW4v
aW5jbHVkZS9hc20teDg2L2h2bS9odm0uaAlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEgKzA4MDAK
KysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vaHZtLmgJVHVlIE5vdiAyMiAxNjoxNToxOSAy
MDExICswODAwCkBAIC0yMTIsNiArMjEyLDggQEAgaW50IGh2bV9naXJxX2Rlc3RfMl92Y3B1X2lk
KHN0cnVjdCBkb21haQogICAgICghISgodiktPmFyY2guaHZtX3ZjcHUuZ3Vlc3RfY3JbMF0gJiBY
ODZfQ1IwX1BHKSkKICNkZWZpbmUgaHZtX3dwX2VuYWJsZWQodikgXAogICAgICghISgodiktPmFy
Y2guaHZtX3ZjcHUuZ3Vlc3RfY3JbMF0gJiBYODZfQ1IwX1dQKSkKKyNkZWZpbmUgaHZtX3BjaWRf
ZW5hYmxlZCh2KSBcCisgICAgKCEhKCh2KS0+YXJjaC5odm1fdmNwdS5ndWVzdF9jcls0XSAmIFg4
Nl9DUjRfUENJREUpKQogI2RlZmluZSBodm1fcGFlX2VuYWJsZWQodikgXAogICAgIChodm1fcGFn
aW5nX2VuYWJsZWQodikgJiYgKCh2KS0+YXJjaC5odm1fdmNwdS5ndWVzdF9jcls0XSAmIFg4Nl9D
UjRfUEFFKSkKICNkZWZpbmUgaHZtX3NtZXBfZW5hYmxlZCh2KSBcCkBAIC0zMzQsNiArMzM2LDcg
QEAgc3RhdGljIGlubGluZSBpbnQgaHZtX2RvX3BtdV9pbnRlcnJ1cHQocwogICAgICAgICAoY3B1
X2hhc19mc2dzYmFzZSA/IFg4Nl9DUjRfRlNHU0JBU0UgOiAwKSB8ICAgICBcCiAgICAgICAgICgo
bmVzdGVkaHZtX2VuYWJsZWQoKF92KS0+ZG9tYWluKSAmJiBjcHVfaGFzX3ZteClcCiAgICAgICAg
ICAgICAgICAgICAgICAgPyBYODZfQ1I0X1ZNWEUgOiAwKSAgfCAgICAgICAgICAgICBcCisgICAg
ICAgIChjcHVfaGFzX3BjaWQgPyBYODZfQ1I0X1BDSURFIDogMCkgfCAgICAgICAgICAgICBcCiAg
ICAgICAgICh4c2F2ZV9lbmFibGVkKF92KSA/IFg4Nl9DUjRfT1NYU0FWRSA6IDApKSkpCiAKIC8q
IFRoZXNlIGV4Y2VwdGlvbnMgbXVzdCBhbHdheXMgYmUgaW50ZXJjZXB0ZWQuICovCmRpZmYgLXIg
YzYxYTViYThjOTcyIHhlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZteC92bWNzLmgKLS0tIGEveGVu
L2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZtY3MuaAlUdWUgTm92IDIyIDAyOjQ3OjUxIDIwMTEg
KzA4MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZtY3MuaAlUdWUgTm92IDIy
IDE2OjE1OjE5IDIwMTEgKzA4MDAKQEAgLTE4NCw2ICsxODQsNyBAQCBleHRlcm4gdTMyIHZteF92
bWVudHJ5X2NvbnRyb2w7CiAjZGVmaW5lIFNFQ09OREFSWV9FWEVDX1dCSU5WRF9FWElUSU5HICAg
ICAgICAgICAweDAwMDAwMDQwCiAjZGVmaW5lIFNFQ09OREFSWV9FWEVDX1VOUkVTVFJJQ1RFRF9H
VUVTVCAgICAgICAweDAwMDAwMDgwCiAjZGVmaW5lIFNFQ09OREFSWV9FWEVDX1BBVVNFX0xPT1Bf
RVhJVElORyAgICAgICAweDAwMDAwNDAwCisjZGVmaW5lIFNFQ09OREFSWV9FWEVDX0VOQUJMRV9J
TlZQQ0lEICAgICAgICAgICAweDAwMDAxMDAwCiBleHRlcm4gdTMyIHZteF9zZWNvbmRhcnlfZXhl
Y19jb250cm9sOwogCiBleHRlcm4gYm9vbF90IGNwdV9oYXNfdm14X2luc19vdXRzX2luc3RyX2lu
Zm87CmRpZmYgLXIgYzYxYTViYThjOTcyIHhlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZteC92bXgu
aAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS92bXgvdm14LmgJVHVlIE5vdiAyMiAwMjo0
Nzo1MSAyMDExICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZteC92bXguaAlU
dWUgTm92IDIyIDE2OjE1OjE5IDIwMTEgKzA4MDAKQEAgLTEyOSw2ICsxMjksNyBAQCB2b2lkIHZt
eF91cGRhdGVfY3B1X2V4ZWNfY29udHJvbChzdHJ1Y3QgCiAjZGVmaW5lIEVYSVRfUkVBU09OX0lO
VlZQSUQgICAgICAgICAgICAgNTMKICNkZWZpbmUgRVhJVF9SRUFTT05fV0JJTlZEICAgICAgICAg
ICAgICA1NAogI2RlZmluZSBFWElUX1JFQVNPTl9YU0VUQlYgICAgICAgICAgICAgIDU1CisjZGVm
aW5lIEVYSVRfUkVBU09OX0lOVlBDSUQgICAgICAgICAgICAgNTgKIAogLyoKICAqIEludGVycnVw
dGlvbi1pbmZvcm1hdGlvbiBmb3JtYXQKZGlmZiAtciBjNjFhNWJhOGM5NzIgeGVuL2luY2x1ZGUv
YXNtLXg4Ni9wcm9jZXNzb3IuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L3Byb2Nlc3Nvci5o
CVR1ZSBOb3YgMjIgMDI6NDc6NTEgMjAxMSArMDgwMAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2
L3Byb2Nlc3Nvci5oCVR1ZSBOb3YgMjIgMTY6MTU6MTkgMjAxMSArMDgwMApAQCAtODQsNiArODQs
NyBAQAogI2RlZmluZSBYODZfQ1I0X1ZNWEUJCTB4MjAwMCAgLyogZW5hYmxlIFZNWCAqLwogI2Rl
ZmluZSBYODZfQ1I0X1NNWEUJCTB4NDAwMCAgLyogZW5hYmxlIFNNWCAqLwogI2RlZmluZSBYODZf
Q1I0X0ZTR1NCQVNFCTB4MTAwMDAgLyogZW5hYmxlIHtyZCx3cn17ZnMsZ3N9YmFzZSAqLworI2Rl
ZmluZSBYODZfQ1I0X1BDSURFCQkweDIwMDAwIC8qIGVuYWJsZSBQQ0lEICovCiAjZGVmaW5lIFg4
Nl9DUjRfT1NYU0FWRQkweDQwMDAwIC8qIGVuYWJsZSBYU0FWRS9YUlNUT1IgKi8KICNkZWZpbmUg
WDg2X0NSNF9TTUVQCQkweDEwMDAwMC8qIGVuYWJsZSBTTUVQICovCiAK

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_002_BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A82shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:59:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbi3-0001Hz-TQ; Thu, 24 Nov 2011 15:59:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTbi2-0001H4-DP
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:59:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322150342!4474379!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12267 invoked from network); 24 Nov 2011 15:59:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 15:59:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9116585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 15:59:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 15:59:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTbhW-0006Zr-Dw;
	Thu, 24 Nov 2011 15:59:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTbhW-0004p5-DN;
	Thu, 24 Nov 2011 15:59:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10020-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 24 Nov 2011 15:59:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10020 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10020/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  b082fdc52ad7
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 301 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 15:59:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 15:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbi3-0001Hz-TQ; Thu, 24 Nov 2011 15:59:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTbi2-0001H4-DP
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 15:59:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322150342!4474379!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12267 invoked from network); 24 Nov 2011 15:59:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 15:59:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9116585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 15:59:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 15:59:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTbhW-0006Zr-Dw;
	Thu, 24 Nov 2011 15:59:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTbhW-0004p5-DN;
	Thu, 24 Nov 2011 15:59:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10020-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 24 Nov 2011 15:59:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10020 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10020/

Regressions :-(

Tests which did not succeed and are blocking:
 build-amd64                   4 xen-build                  fail REGR. vs. 9956
 build-i386-oldkern            4 xen-build                  fail REGR. vs. 9956
 build-i386                    4 xen-build                  fail REGR. vs. 9956
 build-amd64-oldkern           4 xen-build                  fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  b082fdc52ad7
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 301 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:07:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbpv-00029W-1c; Thu, 24 Nov 2011 16:07:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTbps-00029M-VL
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:07:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322150829!4870155!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21537 invoked from network); 24 Nov 2011 16:07:09 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:07:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTbpL-000LP3-Bg; Thu, 24 Nov 2011 16:07:07 +0000
Date: Thu, 24 Nov 2011 16:07:07 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124160707.GK77868@ocelot.phlegethon.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e22610ef339ab7ddd2f6.1322082673@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e22610ef339ab7ddd2f6.1322082673@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 06 of 14] Don't lose track of the log dirty
	bitmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:11 -0500 on 23 Nov (1322064673), Andres Lagar-Cavilla wrote:
> hap_log_dirty_init unconditionally sets the top of the log dirty
> bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
> then leaked, and the host crashes on an ASSERT when the domain is
> cleaned up. Fixing it here.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r e8f0709af2b7 -r e22610ef339a xen/arch/x86/mm/hap/hap.c
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -224,11 +224,18 @@ static void hap_clean_dirty_bitmap(struc
>  void hap_logdirty_init(struct domain *d)
>  {
>      struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
> -    if ( paging_mode_log_dirty(d) && dirty_vram )
> +    if ( paging_mode_log_dirty(d) )
>      {
> -        paging_log_dirty_disable(d);
> -        xfree(dirty_vram);
> -        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
> +        if ( dirty_vram )
> +        {
> +            paging_log_dirty_disable(d);
> +            xfree(dirty_vram);
> +            dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
> +        } else {
> +            /* We still need to clean up the bitmap, because
> +             * init below will overwrite it */
> +            paging_free_log_dirty_bitmap(d);

That's not safe - in the particular case you're worried about there are
concurrent users of this bitmap.  I think the only sane way to deal with
this is to make sure the initialization of log_dirty.top to INVALID_MFN
happens once at start of day, and remove it from the functions that get
called mulitple times. 

Something like this:

diff -r f71ff2f7b604 xen/arch/x86/mm/paging.c
--- a/xen/arch/x86/mm/paging.c	Thu Nov 24 15:20:57 2011 +0000
+++ b/xen/arch/x86/mm/paging.c	Thu Nov 24 16:05:46 2011 +0000
@@ -595,7 +595,6 @@ void paging_log_dirty_init(struct domain
     d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
     d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
     d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
-    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
 }
 
 /* This function fress log dirty bitmap resources. */
@@ -617,6 +616,11 @@ int paging_domain_init(struct domain *d,
 
     mm_lock_init(&d->arch.paging.lock);
 
+    /* This must be initialized separately from the rest of the
+     * log-dirty init code as that can be called more than once and we
+     * don't want to leak any active log-dirty bitmaps */
+    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
+
     /* The order of the *_init calls below is important, as the later
      * ones may rewrite some common fields.  Shadow pagetables are the
      * default... */

Does that make sense to you?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:07:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbpv-00029W-1c; Thu, 24 Nov 2011 16:07:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTbps-00029M-VL
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:07:41 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322150829!4870155!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21537 invoked from network); 24 Nov 2011 16:07:09 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:07:09 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTbpL-000LP3-Bg; Thu, 24 Nov 2011 16:07:07 +0000
Date: Thu, 24 Nov 2011 16:07:07 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124160707.GK77868@ocelot.phlegethon.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e22610ef339ab7ddd2f6.1322082673@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e22610ef339ab7ddd2f6.1322082673@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 06 of 14] Don't lose track of the log dirty
	bitmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:11 -0500 on 23 Nov (1322064673), Andres Lagar-Cavilla wrote:
> hap_log_dirty_init unconditionally sets the top of the log dirty
> bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
> then leaked, and the host crashes on an ASSERT when the domain is
> cleaned up. Fixing it here.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r e8f0709af2b7 -r e22610ef339a xen/arch/x86/mm/hap/hap.c
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -224,11 +224,18 @@ static void hap_clean_dirty_bitmap(struc
>  void hap_logdirty_init(struct domain *d)
>  {
>      struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
> -    if ( paging_mode_log_dirty(d) && dirty_vram )
> +    if ( paging_mode_log_dirty(d) )
>      {
> -        paging_log_dirty_disable(d);
> -        xfree(dirty_vram);
> -        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
> +        if ( dirty_vram )
> +        {
> +            paging_log_dirty_disable(d);
> +            xfree(dirty_vram);
> +            dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
> +        } else {
> +            /* We still need to clean up the bitmap, because
> +             * init below will overwrite it */
> +            paging_free_log_dirty_bitmap(d);

That's not safe - in the particular case you're worried about there are
concurrent users of this bitmap.  I think the only sane way to deal with
this is to make sure the initialization of log_dirty.top to INVALID_MFN
happens once at start of day, and remove it from the functions that get
called mulitple times. 

Something like this:

diff -r f71ff2f7b604 xen/arch/x86/mm/paging.c
--- a/xen/arch/x86/mm/paging.c	Thu Nov 24 15:20:57 2011 +0000
+++ b/xen/arch/x86/mm/paging.c	Thu Nov 24 16:05:46 2011 +0000
@@ -595,7 +595,6 @@ void paging_log_dirty_init(struct domain
     d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
     d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
     d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
-    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
 }
 
 /* This function fress log dirty bitmap resources. */
@@ -617,6 +616,11 @@ int paging_domain_init(struct domain *d,
 
     mm_lock_init(&d->arch.paging.lock);
 
+    /* This must be initialized separately from the rest of the
+     * log-dirty init code as that can be called more than once and we
+     * don't want to leak any active log-dirty bitmaps */
+    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
+
     /* The order of the *_init calls below is important, as the later
      * ones may rewrite some common fields.  Shadow pagetables are the
      * default... */

Does that make sense to you?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrP-0002Ft-PF; Thu, 24 Nov 2011 16:09:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrO-0002Fh-Hq
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:14 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322150882!58147602!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30949 invoked from network); 24 Nov 2011 16:08:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="171802731"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:47 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9d027232;	Thu, 24 Nov 2011 08:08:46 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:11 +0000
Message-ID: <1322150893-887-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/5] Introduce premigrate RunState.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This new state will be used by Xen functions to know QEMU will wait for a
migration. This is important to know for memory related function because the
memory is already allocated and reallocated them will not works.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 qapi-schema.json |    2 +-
 vl.c             |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index cb1ba77..bd77444 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -121,7 +121,7 @@
 { 'enum': 'RunState',
   'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
             'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-            'running', 'save-vm', 'shutdown', 'watchdog' ] }
+            'running', 'save-vm', 'shutdown', 'watchdog', 'premigrate' ] }
 
 ##
 # @StatusInfo:
diff --git a/vl.c b/vl.c
index e7dced2..a291416 100644
--- a/vl.c
+++ b/vl.c
@@ -351,8 +351,11 @@ static const RunStateTransition runstate_transitions_def[] = {
 
     { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
     { RUN_STATE_PRELAUNCH, RUN_STATE_FINISH_MIGRATE },
+    { RUN_STATE_PRELAUNCH, RUN_STATE_PREMIGRATE },
     { RUN_STATE_PRELAUNCH, RUN_STATE_INMIGRATE },
 
+    { RUN_STATE_PREMIGRATE, RUN_STATE_INMIGRATE },
+
     { RUN_STATE_FINISH_MIGRATE, RUN_STATE_RUNNING },
     { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
 
@@ -2975,6 +2978,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_PREMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrP-0002Ft-PF; Thu, 24 Nov 2011 16:09:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrO-0002Fh-Hq
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:14 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322150882!58147602!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30949 invoked from network); 24 Nov 2011 16:08:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="171802731"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:47 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9d027232;	Thu, 24 Nov 2011 08:08:46 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:11 +0000
Message-ID: <1322150893-887-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/5] Introduce premigrate RunState.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This new state will be used by Xen functions to know QEMU will wait for a
migration. This is important to know for memory related function because the
memory is already allocated and reallocated them will not works.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 qapi-schema.json |    2 +-
 vl.c             |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index cb1ba77..bd77444 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -121,7 +121,7 @@
 { 'enum': 'RunState',
   'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
             'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-            'running', 'save-vm', 'shutdown', 'watchdog' ] }
+            'running', 'save-vm', 'shutdown', 'watchdog', 'premigrate' ] }
 
 ##
 # @StatusInfo:
diff --git a/vl.c b/vl.c
index e7dced2..a291416 100644
--- a/vl.c
+++ b/vl.c
@@ -351,8 +351,11 @@ static const RunStateTransition runstate_transitions_def[] = {
 
     { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
     { RUN_STATE_PRELAUNCH, RUN_STATE_FINISH_MIGRATE },
+    { RUN_STATE_PRELAUNCH, RUN_STATE_PREMIGRATE },
     { RUN_STATE_PRELAUNCH, RUN_STATE_INMIGRATE },
 
+    { RUN_STATE_PREMIGRATE, RUN_STATE_INMIGRATE },
+
     { RUN_STATE_FINISH_MIGRATE, RUN_STATE_RUNNING },
     { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
 
@@ -2975,6 +2978,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_PREMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrU-0002Gs-2m; Thu, 24 Nov 2011 16:09:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrS-0002Fe-6f
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:18 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322150882!58147602!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30904 invoked from network); 24 Nov 2011 16:08:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="171802725"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:45 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9b027232;	Thu, 24 Nov 2011 08:08:43 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:09 +0000
Message-ID: <1322150893-887-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/5] vl.c: Do not save RAM state when Xen is
	used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In Xen case, the guest RAM is not handle by QEMU, and it is saved by Xen tools.
So, we just avoid to register the RAM save state handler.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 vl.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index f5afed4..e7dced2 100644
--- a/vl.c
+++ b/vl.c
@@ -3273,8 +3273,10 @@ int main(int argc, char **argv, char **envp)
     default_drive(default_sdcard, snapshot, machine->use_scsi,
                   IF_SD, 0, SD_OPTS);
 
-    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
-                         ram_load, NULL);
+    if (!xen_enabled()) {
+        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
+                             ram_load, NULL);
+    }
 
     if (nb_numa_nodes > 0) {
         int i;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrU-0002Gs-2m; Thu, 24 Nov 2011 16:09:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrS-0002Fe-6f
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:18 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322150882!58147602!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30904 invoked from network); 24 Nov 2011 16:08:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="171802725"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:45 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9b027232;	Thu, 24 Nov 2011 08:08:43 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:09 +0000
Message-ID: <1322150893-887-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/5] vl.c: Do not save RAM state when Xen is
	used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In Xen case, the guest RAM is not handle by QEMU, and it is saved by Xen tools.
So, we just avoid to register the RAM save state handler.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 vl.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index f5afed4..e7dced2 100644
--- a/vl.c
+++ b/vl.c
@@ -3273,8 +3273,10 @@ int main(int argc, char **argv, char **envp)
     default_drive(default_sdcard, snapshot, machine->use_scsi,
                   IF_SD, 0, SD_OPTS);
 
-    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
-                         ram_load, NULL);
+    if (!xen_enabled()) {
+        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
+                             ram_load, NULL);
+    }
 
     if (nb_numa_nodes > 0) {
         int i;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrT-0002Ge-LP; Thu, 24 Nov 2011 16:09:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrS-0002Fd-3l
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:18 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322150924!2899354!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22036 invoked from network); 24 Nov 2011 16:08:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="19389703"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:46 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9c027232;	Thu, 24 Nov 2011 08:08:45 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:10 +0000
Message-ID: <1322150893-887-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/5] xen mapcache: Check if a memory space has
	moved.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch change the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c      |   19 +++++++++++++++++++
 xen-mapcache.c |    8 ++++++--
 xen-mapcache.h |    1 +
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index b5e28ab..40e8869 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -83,6 +83,8 @@ typedef struct XenIOState {
     Notifier exit;
 } XenIOState;
 
+XenIOState *xen_io_state = NULL;
+
 /* Xen specific function for piix pci */
 
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
@@ -218,6 +220,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+target_phys_addr_t xen_addr_actually_is(target_phys_addr_t start_addr, ram_addr_t size)
+{
+    if (xen_io_state) {
+        target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+        XenPhysmap *physmap = NULL;
+
+        QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+            if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+                return physmap->start_addr;
+            }
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -891,6 +909,7 @@ int xen_hvm_init(void)
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
+    xen_io_state = state;
 
     state->xce_handle = xen_xc_evtchn_open(NULL, 0);
     if (state->xce_handle == XC_HANDLER_INITIAL_VALUE) {
diff --git a/xen-mapcache.c b/xen-mapcache.c
index 7bcb86e..73927ab 100644
--- a/xen-mapcache.c
+++ b/xen-mapcache.c
@@ -191,10 +191,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
                        uint8_t lock)
 {
     MapCacheEntry *entry, *pentry = NULL;
-    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
-    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
+    target_phys_addr_t address_index;
+    target_phys_addr_t address_offset;
     target_phys_addr_t __size = size;
 
+    phys_addr = xen_addr_actually_is(phys_addr, size);
+    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
+    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
+
     trace_xen_map_cache(phys_addr);
 
     if (address_index == mapcache->last_address_index && !lock && !__size) {
diff --git a/xen-mapcache.h b/xen-mapcache.h
index da874ca..5e561c5 100644
--- a/xen-mapcache.h
+++ b/xen-mapcache.h
@@ -19,6 +19,7 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
 ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
 void xen_invalidate_map_cache_entry(uint8_t *buffer);
 void xen_invalidate_map_cache(void);
+target_phys_addr_t xen_addr_actually_is(target_phys_addr_t start_addr, ram_addr_t size);
 
 #else
 
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrT-0002Ge-LP; Thu, 24 Nov 2011 16:09:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrS-0002Fd-3l
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:18 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322150924!2899354!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22036 invoked from network); 24 Nov 2011 16:08:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="19389703"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:46 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9c027232;	Thu, 24 Nov 2011 08:08:45 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:10 +0000
Message-ID: <1322150893-887-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/5] xen mapcache: Check if a memory space has
	moved.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch change the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c      |   19 +++++++++++++++++++
 xen-mapcache.c |    8 ++++++--
 xen-mapcache.h |    1 +
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index b5e28ab..40e8869 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -83,6 +83,8 @@ typedef struct XenIOState {
     Notifier exit;
 } XenIOState;
 
+XenIOState *xen_io_state = NULL;
+
 /* Xen specific function for piix pci */
 
 int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
@@ -218,6 +220,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+target_phys_addr_t xen_addr_actually_is(target_phys_addr_t start_addr, ram_addr_t size)
+{
+    if (xen_io_state) {
+        target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+        XenPhysmap *physmap = NULL;
+
+        QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+            if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+                return physmap->start_addr;
+            }
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -891,6 +909,7 @@ int xen_hvm_init(void)
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
+    xen_io_state = state;
 
     state->xce_handle = xen_xc_evtchn_open(NULL, 0);
     if (state->xce_handle == XC_HANDLER_INITIAL_VALUE) {
diff --git a/xen-mapcache.c b/xen-mapcache.c
index 7bcb86e..73927ab 100644
--- a/xen-mapcache.c
+++ b/xen-mapcache.c
@@ -191,10 +191,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
                        uint8_t lock)
 {
     MapCacheEntry *entry, *pentry = NULL;
-    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
-    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
+    target_phys_addr_t address_index;
+    target_phys_addr_t address_offset;
     target_phys_addr_t __size = size;
 
+    phys_addr = xen_addr_actually_is(phys_addr, size);
+    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
+    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
+
     trace_xen_map_cache(phys_addr);
 
     if (address_index == mapcache->last_address_index && !lock && !__size) {
diff --git a/xen-mapcache.h b/xen-mapcache.h
index da874ca..5e561c5 100644
--- a/xen-mapcache.h
+++ b/xen-mapcache.h
@@ -19,6 +19,7 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
 ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
 void xen_invalidate_map_cache_entry(uint8_t *buffer);
 void xen_invalidate_map_cache(void);
+target_phys_addr_t xen_addr_actually_is(target_phys_addr_t start_addr, ram_addr_t size);
 
 #else
 
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrT-0002GV-8R; Thu, 24 Nov 2011 16:09:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrR-0002FX-7L
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:17 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322150924!2899354!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21947 invoked from network); 24 Nov 2011 16:08:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="19389702"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:44 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9a027232;	Thu, 24 Nov 2011 08:08:42 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:08 +0000
Message-ID: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/5] Have a working migration with Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series provide some fix to have migration working with Xen. The main
issue with Xen is that the guest RAM is not handle by QEMU.

So, first of all, the RAM will not be saved in the QEMU state file.

Then, during the initialisation that append before the migration, QEMU should
not try to allocate again the VRAM of the vga emulation, because it's already
there. (The guest RAM is restored before calling QEMU)

And last but not least, in QEMU with Xen, a call to set_memory (with different
address for start_addr and phys_offset) actually move the the memory, and the
only way to have a pointer to this memory is to ask a ptr with the new addr.
So, there is a patch that check for the right guest address to map.

There is probably a better way to do some of this.

Regards,


Anthony PERARD (5):
  vl.c: Do not save RAM state when Xen is used.
  xen mapcache: Check if a memory space has moved.
  Introduce premigrate RunState.
  xen: Change memory access behavior during migration.
  vga-cirrus: Workaround during restore when using Xen.

 hw/cirrus_vga.c  |   20 +++++++++++++++++---
 qapi-schema.json |    2 +-
 vl.c             |   10 ++++++++--
 xen-all.c        |   32 ++++++++++++++++++++++++++++++++
 xen-mapcache.c   |    8 ++++++--
 xen-mapcache.h   |    1 +
 6 files changed, 65 insertions(+), 8 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrT-0002GV-8R; Thu, 24 Nov 2011 16:09:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrR-0002FX-7L
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:17 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322150924!2899354!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21947 invoked from network); 24 Nov 2011 16:08:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="19389702"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:44 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9a027232;	Thu, 24 Nov 2011 08:08:42 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:08 +0000
Message-ID: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/5] Have a working migration with Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series provide some fix to have migration working with Xen. The main
issue with Xen is that the guest RAM is not handle by QEMU.

So, first of all, the RAM will not be saved in the QEMU state file.

Then, during the initialisation that append before the migration, QEMU should
not try to allocate again the VRAM of the vga emulation, because it's already
there. (The guest RAM is restored before calling QEMU)

And last but not least, in QEMU with Xen, a call to set_memory (with different
address for start_addr and phys_offset) actually move the the memory, and the
only way to have a pointer to this memory is to ask a ptr with the new addr.
So, there is a patch that check for the right guest address to map.

There is probably a better way to do some of this.

Regards,


Anthony PERARD (5):
  vl.c: Do not save RAM state when Xen is used.
  xen mapcache: Check if a memory space has moved.
  Introduce premigrate RunState.
  xen: Change memory access behavior during migration.
  vga-cirrus: Workaround during restore when using Xen.

 hw/cirrus_vga.c  |   20 +++++++++++++++++---
 qapi-schema.json |    2 +-
 vl.c             |   10 ++++++++--
 xen-all.c        |   32 ++++++++++++++++++++++++++++++++
 xen-mapcache.c   |    8 ++++++--
 xen-mapcache.h   |    1 +
 6 files changed, 65 insertions(+), 8 deletions(-)

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrV-0002HO-U3; Thu, 24 Nov 2011 16:09:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrU-0002Fp-Bg
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:20 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322150924!2899354!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22172 invoked from network); 24 Nov 2011 16:08:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="19389704"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:48 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9e027232;	Thu, 24 Nov 2011 08:08:47 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:12 +0000
Message-ID: <1322150893-887-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/5] xen: Change memory access behavior during
	migration.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Do not allocate RAM during pre-migration runstate.
Do not actually "do" set_memory during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 40e8869..279651a 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -191,6 +191,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
 
     trace_xen_ram_alloc(ram_addr, size);
 
+    if (runstate_check(RUN_STATE_PREMIGRATE)) {
+        /* RAM already populated in Xen */
+        return;
+    }
+
     nr_pfn = size >> TARGET_PAGE_BITS;
     pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
 
@@ -271,6 +276,13 @@ go_physmap:
     DPRINTF("mapping vram to %llx - %llx, from %llx\n",
             start_addr, start_addr + size, phys_offset);
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* The mapping should already be done and can not be done a second
+         * time. So we just add to the physmap list instead.
+         */
+        goto done;
+    }
+
     pfn = phys_offset >> TARGET_PAGE_BITS;
     start_gpfn = start_addr >> TARGET_PAGE_BITS;
     for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
@@ -285,6 +297,7 @@ go_physmap:
         }
     }
 
+done:
     physmap = g_malloc(sizeof (XenPhysmap));
 
     physmap->start_addr = start_addr;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrV-0002HO-U3; Thu, 24 Nov 2011 16:09:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrU-0002Fp-Bg
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:20 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322150924!2899354!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22172 invoked from network); 24 Nov 2011 16:08:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="19389704"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:48 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9e027232;	Thu, 24 Nov 2011 08:08:47 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:12 +0000
Message-ID: <1322150893-887-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/5] xen: Change memory access behavior during
	migration.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Do not allocate RAM during pre-migration runstate.
Do not actually "do" set_memory during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 40e8869..279651a 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -191,6 +191,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size)
 
     trace_xen_ram_alloc(ram_addr, size);
 
+    if (runstate_check(RUN_STATE_PREMIGRATE)) {
+        /* RAM already populated in Xen */
+        return;
+    }
+
     nr_pfn = size >> TARGET_PAGE_BITS;
     pfn_list = g_malloc(sizeof (*pfn_list) * nr_pfn);
 
@@ -271,6 +276,13 @@ go_physmap:
     DPRINTF("mapping vram to %llx - %llx, from %llx\n",
             start_addr, start_addr + size, phys_offset);
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* The mapping should already be done and can not be done a second
+         * time. So we just add to the physmap list instead.
+         */
+        goto done;
+    }
+
     pfn = phys_offset >> TARGET_PAGE_BITS;
     start_gpfn = start_addr >> TARGET_PAGE_BITS;
     for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
@@ -285,6 +297,7 @@ go_physmap:
         }
     }
 
+done:
     physmap = g_malloc(sizeof (XenPhysmap));
 
     physmap->start_addr = start_addr;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrV-0002HG-HJ; Thu, 24 Nov 2011 16:09:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrT-0002G0-M5
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:19 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322150882!58147602!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31091 invoked from network); 24 Nov 2011 16:08:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="171802732"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:49 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9f027232;	Thu, 24 Nov 2011 08:08:48 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:13 +0000
Message-ID: <1322150893-887-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 5/5] vga-cirrus: Workaround during restore when
	using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

During the initialisation of the machine at restore time, the access to the
VRAM will fail because QEMU does not know yet the right guest address to map,
so the vram_ptr is NULL.

So this patch avoid using a NULL pointer during initialisation, and try to get
another vram_ptr if the call failed the first time.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/cirrus_vga.c |   20 +++++++++++++++++---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index c7e365b..d092c74 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -32,6 +32,7 @@
 #include "console.h"
 #include "vga_int.h"
 #include "loader.h"
+#include "sysemu.h"
 
 /*
  * TODO:
@@ -2696,6 +2697,17 @@ static int cirrus_post_load(void *opaque, int version_id)
     s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
 
     cirrus_update_memory_access(s);
+    if (!s->vga.vram_ptr) {
+        /* Try again
+         * The initial call to get_ram_ptr can fail with Xen during a migration
+         * because the VRAM has been moved arround.
+         * (Moved with a set_memory and a xen_add_to_physmap)
+         * After cirrus_update_memory_access, the Xen function will know were
+         * the memory actually is, and fix the address before give back a
+         * ram_ptr.
+         */
+        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
+    }
     /* force refresh */
     s->vga.graphic_mode = -1;
     cirrus_update_bank_ptr(s, 0);
@@ -2784,9 +2796,11 @@ static void cirrus_reset(void *opaque)
     }
     s->vga.cr[0x27] = s->device_id;
 
-    /* Win2K seems to assume that the pattern buffer is at 0xff
-       initially ! */
-    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
+        /* Win2K seems to assume that the pattern buffer is at 0xff
+           initially ! */
+        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    }
 
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:09:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbrV-0002HG-HJ; Thu, 24 Nov 2011 16:09:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTbrT-0002G0-M5
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:09:19 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322150882!58147602!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31091 invoked from network); 24 Nov 2011 16:08:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:08:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315195200"; d="scan'208";a="171802732"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 11:08:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 11:08:49 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOG8f9f027232;	Thu, 24 Nov 2011 08:08:48 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 16:08:13 +0000
Message-ID: <1322150893-887-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 5/5] vga-cirrus: Workaround during restore when
	using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

During the initialisation of the machine at restore time, the access to the
VRAM will fail because QEMU does not know yet the right guest address to map,
so the vram_ptr is NULL.

So this patch avoid using a NULL pointer during initialisation, and try to get
another vram_ptr if the call failed the first time.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/cirrus_vga.c |   20 +++++++++++++++++---
 1 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index c7e365b..d092c74 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -32,6 +32,7 @@
 #include "console.h"
 #include "vga_int.h"
 #include "loader.h"
+#include "sysemu.h"
 
 /*
  * TODO:
@@ -2696,6 +2697,17 @@ static int cirrus_post_load(void *opaque, int version_id)
     s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
 
     cirrus_update_memory_access(s);
+    if (!s->vga.vram_ptr) {
+        /* Try again
+         * The initial call to get_ram_ptr can fail with Xen during a migration
+         * because the VRAM has been moved arround.
+         * (Moved with a set_memory and a xen_add_to_physmap)
+         * After cirrus_update_memory_access, the Xen function will know were
+         * the memory actually is, and fix the address before give back a
+         * ram_ptr.
+         */
+        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
+    }
     /* force refresh */
     s->vga.graphic_mode = -1;
     cirrus_update_bank_ptr(s, 0);
@@ -2784,9 +2796,11 @@ static void cirrus_reset(void *opaque)
     }
     s->vga.cr[0x27] = s->device_id;
 
-    /* Win2K seems to assume that the pattern buffer is at 0xff
-       initially ! */
-    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
+        /* Win2K seems to assume that the pattern buffer is at 0xff
+           initially ! */
+        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    }
 
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:12:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:12:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbuJ-00032b-4r; Thu, 24 Nov 2011 16:12:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTbuH-00031M-VF
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:12:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322151102!5604984!1
X-Originating-IP: [208.97.132.202]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15069 invoked from network); 24 Nov 2011 16:11:42 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 16:11:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 902467EC069;
	Thu, 24 Nov 2011 08:11:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=oUyhkUQpvLAtDP1J6ys2LU/eYeQQ6YpOOHbQlRCqmVkp
	5BQUS0BpNrtbbuDPz79Zvg8bk7Y15aj2Be7pYTqDJxMCebGlTcOOscxRahYdTG+m
	V9yh+c36GIW813KOEHLYlKlQt0YJk/lmQlXQtFYkWH+lVuS2//yyt1yl5q4+tI0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Nw7qdqdBBpNBg9p0jZUimusdMlQ=; b=n6XyIAjN
	6395iWslXtirFn49D3MmdrGfwxaKH4TkNeiXc69ADKcHO/M8pYDF1ETS9b44GmqI
	3XEcecxSmUOqQjRauhuYbZT4ULZqZ4LinVx5eGtbh5Mx7fGfaHv2lYhf8Fclw3Q7
	RJzmzRE84u6Lz4JvIc0++KDz8qrj3IboEg4=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 1541E7EC065; 
	Thu, 24 Nov 2011 08:11:41 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 08:11:41 -0800
Message-ID: <30e8db57e5d9290d90dcff09cca05daa.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124160707.GK77868@ocelot.phlegethon.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e22610ef339ab7ddd2f6.1322082673@xdev.gridcentric.ca>
	<20111124160707.GK77868@ocelot.phlegethon.org>
Date: Thu, 24 Nov 2011 08:11:41 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 06 of 14] Don't lose track of the log dirty
 bitmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Certainly, looks good. Let me give it a quick test. I was
enabling-dsabling-enablig log dirty, and that was crashing my box on the
ASSERT that was checking no dirty bitmap pages were left when tearing
down.

Andres
> At 16:11 -0500 on 23 Nov (1322064673), Andres Lagar-Cavilla wrote:
>> hap_log_dirty_init unconditionally sets the top of the log dirty
>> bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
>> then leaked, and the host crashes on an ASSERT when the domain is
>> cleaned up. Fixing it here.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r e8f0709af2b7 -r e22610ef339a xen/arch/x86/mm/hap/hap.c
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -224,11 +224,18 @@ static void hap_clean_dirty_bitmap(struc
>>  void hap_logdirty_init(struct domain *d)
>>  {
>>      struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
>> -    if ( paging_mode_log_dirty(d) && dirty_vram )
>> +    if ( paging_mode_log_dirty(d) )
>>      {
>> -        paging_log_dirty_disable(d);
>> -        xfree(dirty_vram);
>> -        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
>> +        if ( dirty_vram )
>> +        {
>> +            paging_log_dirty_disable(d);
>> +            xfree(dirty_vram);
>> +            dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
>> +        } else {
>> +            /* We still need to clean up the bitmap, because
>> +             * init below will overwrite it */
>> +            paging_free_log_dirty_bitmap(d);
>
> That's not safe - in the particular case you're worried about there are
> concurrent users of this bitmap.  I think the only sane way to deal with
> this is to make sure the initialization of log_dirty.top to INVALID_MFN
> happens once at start of day, and remove it from the functions that get
> called mulitple times.
>
> Something like this:
>
> diff -r f71ff2f7b604 xen/arch/x86/mm/paging.c
> --- a/xen/arch/x86/mm/paging.c	Thu Nov 24 15:20:57 2011 +0000
> +++ b/xen/arch/x86/mm/paging.c	Thu Nov 24 16:05:46 2011 +0000
> @@ -595,7 +595,6 @@ void paging_log_dirty_init(struct domain
>      d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
>      d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
>      d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
> -    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
>  }
>
>  /* This function fress log dirty bitmap resources. */
> @@ -617,6 +616,11 @@ int paging_domain_init(struct domain *d,
>
>      mm_lock_init(&d->arch.paging.lock);
>
> +    /* This must be initialized separately from the rest of the
> +     * log-dirty init code as that can be called more than once and we
> +     * don't want to leak any active log-dirty bitmaps */
> +    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
> +
>      /* The order of the *_init calls below is important, as the later
>       * ones may rewrite some common fields.  Shadow pagetables are the
>       * default... */
>
> Does that make sense to you?
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:12:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:12:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbuJ-00032b-4r; Thu, 24 Nov 2011 16:12:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTbuH-00031M-VF
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:12:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322151102!5604984!1
X-Originating-IP: [208.97.132.202]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15069 invoked from network); 24 Nov 2011 16:11:42 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 16:11:42 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 902467EC069;
	Thu, 24 Nov 2011 08:11:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=oUyhkUQpvLAtDP1J6ys2LU/eYeQQ6YpOOHbQlRCqmVkp
	5BQUS0BpNrtbbuDPz79Zvg8bk7Y15aj2Be7pYTqDJxMCebGlTcOOscxRahYdTG+m
	V9yh+c36GIW813KOEHLYlKlQt0YJk/lmQlXQtFYkWH+lVuS2//yyt1yl5q4+tI0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=Nw7qdqdBBpNBg9p0jZUimusdMlQ=; b=n6XyIAjN
	6395iWslXtirFn49D3MmdrGfwxaKH4TkNeiXc69ADKcHO/M8pYDF1ETS9b44GmqI
	3XEcecxSmUOqQjRauhuYbZT4ULZqZ4LinVx5eGtbh5Mx7fGfaHv2lYhf8Fclw3Q7
	RJzmzRE84u6Lz4JvIc0++KDz8qrj3IboEg4=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 1541E7EC065; 
	Thu, 24 Nov 2011 08:11:41 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 08:11:41 -0800
Message-ID: <30e8db57e5d9290d90dcff09cca05daa.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124160707.GK77868@ocelot.phlegethon.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e22610ef339ab7ddd2f6.1322082673@xdev.gridcentric.ca>
	<20111124160707.GK77868@ocelot.phlegethon.org>
Date: Thu, 24 Nov 2011 08:11:41 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 06 of 14] Don't lose track of the log dirty
 bitmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Certainly, looks good. Let me give it a quick test. I was
enabling-dsabling-enablig log dirty, and that was crashing my box on the
ASSERT that was checking no dirty bitmap pages were left when tearing
down.

Andres
> At 16:11 -0500 on 23 Nov (1322064673), Andres Lagar-Cavilla wrote:
>> hap_log_dirty_init unconditionally sets the top of the log dirty
>> bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
>> then leaked, and the host crashes on an ASSERT when the domain is
>> cleaned up. Fixing it here.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r e8f0709af2b7 -r e22610ef339a xen/arch/x86/mm/hap/hap.c
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -224,11 +224,18 @@ static void hap_clean_dirty_bitmap(struc
>>  void hap_logdirty_init(struct domain *d)
>>  {
>>      struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
>> -    if ( paging_mode_log_dirty(d) && dirty_vram )
>> +    if ( paging_mode_log_dirty(d) )
>>      {
>> -        paging_log_dirty_disable(d);
>> -        xfree(dirty_vram);
>> -        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
>> +        if ( dirty_vram )
>> +        {
>> +            paging_log_dirty_disable(d);
>> +            xfree(dirty_vram);
>> +            dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
>> +        } else {
>> +            /* We still need to clean up the bitmap, because
>> +             * init below will overwrite it */
>> +            paging_free_log_dirty_bitmap(d);
>
> That's not safe - in the particular case you're worried about there are
> concurrent users of this bitmap.  I think the only sane way to deal with
> this is to make sure the initialization of log_dirty.top to INVALID_MFN
> happens once at start of day, and remove it from the functions that get
> called mulitple times.
>
> Something like this:
>
> diff -r f71ff2f7b604 xen/arch/x86/mm/paging.c
> --- a/xen/arch/x86/mm/paging.c	Thu Nov 24 15:20:57 2011 +0000
> +++ b/xen/arch/x86/mm/paging.c	Thu Nov 24 16:05:46 2011 +0000
> @@ -595,7 +595,6 @@ void paging_log_dirty_init(struct domain
>      d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
>      d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
>      d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
> -    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
>  }
>
>  /* This function fress log dirty bitmap resources. */
> @@ -617,6 +616,11 @@ int paging_domain_init(struct domain *d,
>
>      mm_lock_init(&d->arch.paging.lock);
>
> +    /* This must be initialized separately from the rest of the
> +     * log-dirty init code as that can be called more than once and we
> +     * don't want to leak any active log-dirty bitmaps */
> +    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
> +
>      /* The order of the *_init calls below is important, as the later
>       * ones may rewrite some common fields.  Shadow pagetables are the
>       * default... */
>
> Does that make sense to you?
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:14:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:14:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbwY-0003Tr-8Q; Thu, 24 Nov 2011 16:14:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RTbwW-0003SG-5d; Thu, 24 Nov 2011 16:14:32 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322151240!4855615!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5707 invoked from network); 24 Nov 2011 16:14:00 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:14:00 -0000
Received: by bkbzt12 with SMTP id zt12so4100091bkb.30
	for <multiple recipients>; Thu, 24 Nov 2011 08:14:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=oUU1jjFizyWmLazXxMuh01ermZnp8fzg75s6Xhltz8Q=;
	b=P2h9JN06Lu9LsoK+/DsttiMq6JEeAekAS8Eko6pZ0Jt2erO96tioP8vd1Em3vNLSwc
	nttHVxHoLMq6JrZ7K6YhoJ1dWbQ+vMUcsaUhfSsAFj6UmfM1YeaBq74MOyD0ckDreciK
	YwDqHMMo7yIWQ5tMNgMdxOQ6/fT+dMcBBww04=
Received: by 10.204.154.7 with SMTP id m7mr29973723bkw.71.1322151240161;
	Thu, 24 Nov 2011 08:14:00 -0800 (PST)
Received: from [172.16.25.10] (5e0575b0.bb.sky.com. [94.5.117.176])
	by mx.google.com with ESMTPS id q6sm16220938bka.6.2011.11.24.08.13.58
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 08:13:59 -0800 (PST)
Message-ID: <4ECE6D45.8060408@xen.org>
Date: Thu, 24 Nov 2011 16:13:57 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-arm@lists.xensource.com, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>, 
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
References: <4EBD03EA.9070907@xen.org>
	<20111111150013.GA4712@phenom.dumpdata.com>
	<CAL_tfFeUsDO1oAoKeWHLBJG0CHDf8A19mvjNX+zJCXfVdmfd3w@mail.gmail.com>
	<4EC3DDCE.9020506@xen.org>
In-Reply-To: <4EC3DDCE.9020506@xen.org>
Subject: Re: [Xen-devel] [Xen-users] Re: [Xen-API] Another Xen Doc Day,
 Nov 29 or Dec 12
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/11/2011 15:59, Lars Kurth wrote:
> So far we had two votes for Nov 29th
> Any others?
> Lars

OK: 29th it is then
Lars


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:14:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:14:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTbwY-0003Tr-8Q; Thu, 24 Nov 2011 16:14:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RTbwW-0003SG-5d; Thu, 24 Nov 2011 16:14:32 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322151240!4855615!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5707 invoked from network); 24 Nov 2011 16:14:00 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:14:00 -0000
Received: by bkbzt12 with SMTP id zt12so4100091bkb.30
	for <multiple recipients>; Thu, 24 Nov 2011 08:14:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=oUU1jjFizyWmLazXxMuh01ermZnp8fzg75s6Xhltz8Q=;
	b=P2h9JN06Lu9LsoK+/DsttiMq6JEeAekAS8Eko6pZ0Jt2erO96tioP8vd1Em3vNLSwc
	nttHVxHoLMq6JrZ7K6YhoJ1dWbQ+vMUcsaUhfSsAFj6UmfM1YeaBq74MOyD0ckDreciK
	YwDqHMMo7yIWQ5tMNgMdxOQ6/fT+dMcBBww04=
Received: by 10.204.154.7 with SMTP id m7mr29973723bkw.71.1322151240161;
	Thu, 24 Nov 2011 08:14:00 -0800 (PST)
Received: from [172.16.25.10] (5e0575b0.bb.sky.com. [94.5.117.176])
	by mx.google.com with ESMTPS id q6sm16220938bka.6.2011.11.24.08.13.58
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 08:13:59 -0800 (PST)
Message-ID: <4ECE6D45.8060408@xen.org>
Date: Thu, 24 Nov 2011 16:13:57 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-arm@lists.xensource.com, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>, 
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
References: <4EBD03EA.9070907@xen.org>
	<20111111150013.GA4712@phenom.dumpdata.com>
	<CAL_tfFeUsDO1oAoKeWHLBJG0CHDf8A19mvjNX+zJCXfVdmfd3w@mail.gmail.com>
	<4EC3DDCE.9020506@xen.org>
In-Reply-To: <4EC3DDCE.9020506@xen.org>
Subject: Re: [Xen-devel] [Xen-users] Re: [Xen-API] Another Xen Doc Day,
 Nov 29 or Dec 12
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/11/2011 15:59, Lars Kurth wrote:
> So far we had two votes for Nov 29th
> Any others?
> Lars

OK: 29th it is then
Lars


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:21:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTc3S-00044s-3P; Thu, 24 Nov 2011 16:21:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTc3Q-00044n-IO
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:21:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322151668!2881279!1
X-Originating-IP: [208.97.132.66]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21778 invoked from network); 24 Nov 2011 16:21:09 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-8.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 16:21:09 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 8B2E4300064;
	Thu, 24 Nov 2011 08:21:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=dtZJTsUQfyXv35kAb9y+FjXYEI1bzlZgASexDfRM9uLa
	4CKuQB5F/gWoQJX3fPdm5rN1onDGyfi67txfpmBWmNzWxEHs/+GbhVUMayh1Eqwa
	sy4J7mNd9zZGLtioK/dvJfEPIuw0M/j2muxz/JipFnFR+XMXAdw5KoCd+dSur28=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=2o9iXpb80Xcl8i/Ph7FUdE7hKeE=; b=cY5N7Et/
	HsdsxhHNZrO8XULXxhFNpR0Z9qV4XugdfuTW4RjbK71YRav8iPR2V4TcrjZow07U
	osHAuzhQ9MTAxEKdcp/vUin2mxNoJwqXVd19Wc8GnrH0eTuEfgzrWOkKg9BgDlJ/
	gChoIEuJNeTaKsms5SG299PqoqioCIKvtPw=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 776D0300061; 
	Thu, 24 Nov 2011 08:21:06 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 08:21:08 -0800
Message-ID: <3ef317bfa15a9cb853f589ad771a4dbb.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124153027.GH77868@ocelot.phlegethon.org>
References: <patchbomb.1321307321@xdev.gridcentric.ca>
	<764e0872dd4f50c70fbc.1321307326@xdev.gridcentric.ca>
	<20111124153027.GH77868@ocelot.phlegethon.org>
Date: Thu, 24 Nov 2011 08:21:08 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim,

I don't think we'll ever be able to move out of global p2m locks if we
allow these inline audits. In a fine-grained p2m lock case, the code will
acquire exclusive rights on a range of the p2m. But then, in order to
audit the whole p2m, it will need to promote its exclusive access to the
whole p2m, and that's a deadlock trap.

Ultimately, I can submit a patch that fixes the bit rotting and leaves the
inlines in place. And if and when the p2m locking becomes fine-grained, we
can ifdef into global locking if P2M_AUDIT is nonzero.

It's kinda yucky. And somewhat crippling of the intended debugging
purposes of an audit (with fine-grained locks). But it will work and will
not put the fine-grained cart before the locking horse.

Thanks
Andres

> At 16:48 -0500 on 14 Nov (1321289326), Andres Lagar-Cavilla wrote:
>> The p2m audit code doesn't even compile, let alone work. It also
>> partially supports ept. Make it:
>>
>> - compile
>> - lay groundwork for eventual ept support
>> - move out of the way of all calls and turn it into a domctl. It's
>>   obviously not being used by anybody presently.
>> - enable it via said domctl
>
> Thanks for looking at this code (which, as you say, had considerably
> rotted).
>
> I'm not sure I'm a big fan of provoking audits from user-space rather
> than having them run on every operation; in previous incarnations there
> have been serial debug-keys that triggered auditing code (which would
> then be run before and after every operation) - I found that much more
> helpful in the case of failure, as it pointed to which operation had
> caused the problem rather than saying 'something bad happened at somne
> point'.
>
> If you really want to keep the hypercall, I think it could probably be
> part of the existing paging/shadow control domctl rather than having
> its own.  That would have the advantage of preventing an untrusted
> domain from calling it on itself (which has in the past turned slightly
> bitrotted audit code into a denial-of-service vector!).
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:21:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTc3S-00044s-3P; Thu, 24 Nov 2011 16:21:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTc3Q-00044n-IO
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:21:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322151668!2881279!1
X-Originating-IP: [208.97.132.66]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21778 invoked from network); 24 Nov 2011 16:21:09 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-8.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 16:21:09 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 8B2E4300064;
	Thu, 24 Nov 2011 08:21:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=dtZJTsUQfyXv35kAb9y+FjXYEI1bzlZgASexDfRM9uLa
	4CKuQB5F/gWoQJX3fPdm5rN1onDGyfi67txfpmBWmNzWxEHs/+GbhVUMayh1Eqwa
	sy4J7mNd9zZGLtioK/dvJfEPIuw0M/j2muxz/JipFnFR+XMXAdw5KoCd+dSur28=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=2o9iXpb80Xcl8i/Ph7FUdE7hKeE=; b=cY5N7Et/
	HsdsxhHNZrO8XULXxhFNpR0Z9qV4XugdfuTW4RjbK71YRav8iPR2V4TcrjZow07U
	osHAuzhQ9MTAxEKdcp/vUin2mxNoJwqXVd19Wc8GnrH0eTuEfgzrWOkKg9BgDlJ/
	gChoIEuJNeTaKsms5SG299PqoqioCIKvtPw=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 776D0300061; 
	Thu, 24 Nov 2011 08:21:06 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 08:21:08 -0800
Message-ID: <3ef317bfa15a9cb853f589ad771a4dbb.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124153027.GH77868@ocelot.phlegethon.org>
References: <patchbomb.1321307321@xdev.gridcentric.ca>
	<764e0872dd4f50c70fbc.1321307326@xdev.gridcentric.ca>
	<20111124153027.GH77868@ocelot.phlegethon.org>
Date: Thu, 24 Nov 2011 08:21:08 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim,

I don't think we'll ever be able to move out of global p2m locks if we
allow these inline audits. In a fine-grained p2m lock case, the code will
acquire exclusive rights on a range of the p2m. But then, in order to
audit the whole p2m, it will need to promote its exclusive access to the
whole p2m, and that's a deadlock trap.

Ultimately, I can submit a patch that fixes the bit rotting and leaves the
inlines in place. And if and when the p2m locking becomes fine-grained, we
can ifdef into global locking if P2M_AUDIT is nonzero.

It's kinda yucky. And somewhat crippling of the intended debugging
purposes of an audit (with fine-grained locks). But it will work and will
not put the fine-grained cart before the locking horse.

Thanks
Andres

> At 16:48 -0500 on 14 Nov (1321289326), Andres Lagar-Cavilla wrote:
>> The p2m audit code doesn't even compile, let alone work. It also
>> partially supports ept. Make it:
>>
>> - compile
>> - lay groundwork for eventual ept support
>> - move out of the way of all calls and turn it into a domctl. It's
>>   obviously not being used by anybody presently.
>> - enable it via said domctl
>
> Thanks for looking at this code (which, as you say, had considerably
> rotted).
>
> I'm not sure I'm a big fan of provoking audits from user-space rather
> than having them run on every operation; in previous incarnations there
> have been serial debug-keys that triggered auditing code (which would
> then be run before and after every operation) - I found that much more
> helpful in the case of failure, as it pointed to which operation had
> caused the problem rather than saying 'something bad happened at somne
> point'.
>
> If you really want to keep the hypercall, I think it could probably be
> part of the existing paging/shadow control domctl rather than having
> its own.  That would have the advantage of preventing an untrusted
> domain from calling it on itself (which has in the past turned slightly
> bitrotted audit code into a denial-of-service vector!).
>
> Cheers,
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:24:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTc6A-0004Da-Na; Thu, 24 Nov 2011 16:24:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTc69-0004DC-Pn
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:24:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322151838!5582802!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20256 invoked from network); 24 Nov 2011 16:23:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:23:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:23:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 16:23:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTc5d-0006kT-RW; Thu, 24 Nov 2011 16:23:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTc5d-0004Gw-Qm;
	Thu, 24 Nov 2011 16:23:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.28573.818575.318659@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 16:23:57 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <osstest-10020-mainreport@xen.org>
References: <osstest-10020-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 10020: regressions - FAIL"):
> flight 10020 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10020/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  build-i386                    4 xen-build                  fail REGR. vs. 995

gcc  -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-aft
er-statement   -D__XEN_TOOLS__ -MMD -MF .block-sync.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-
optimize-sibling-calls -mno-tls-direct-seg-refs -Werror -Wno-unused -I../lib -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/driv
ers/../../../tools/libxc -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/drivers/../../../tools/include -I/home/osstest/build.100
20.build-i386/xen-unstable/tools/blktap/drivers/../../../tools/xenstore -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/drivers/.
./../../tools/include -I ../../memshr -D_GNU_SOURCE -DMEMSHR  -c -o block-sync.o block-sync.c 
In file included from block-aio.c:45:
tapaio.h:42: error: expected specifier-qualifier-list before 'io_context_t'
block-aio.c: In function 'init_fds':
block-aio.c:117: error: 'tap_aio_internal_context_t' has no member named 'pollfd'
cc1: warnings being treated as errors
block-aio.c: In function 'tdaio_close':
block-aio.c:201: error: implicit declaration of function 'io_destroy'
block-aio.c:201: error: 'tap_aio_internal_context_t' has no member named 'aio_ctx'
block-aio.c: In function 'tdaio_do_callbacks':
block-aio.c:215: error: increment of pointer to unknown structure
block-aio.c:215: error: arithmetic on pointer to an incomplete type
block-aio.c:216: error: dereferencing pointer to incomplete type
block-aio.c:219: error: dereferencing pointer to incomplete type
block-aio.c:220: error: dereferencing pointer to incomplete type
block-aio.c:220: error: dereferencing pointer to incomplete type
block-aio.c:221: error: dereferencing pointer to incomplete type
make[5]: *** [block-aio.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: *** wait: No child processes.  Stop.
make[4]: *** [subdir-install-drivers] Error 2
make[4]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap'
make[3]: *** [subdirs-install] Error 2
make[3]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap'
make[2]: *** [subdir-install-blktap] Error 2
make[2]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools'
make: *** [install-tools] Error 2
+ test -f ../build-ok-stamp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:24:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:24:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTc6A-0004Da-Na; Thu, 24 Nov 2011 16:24:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTc69-0004DC-Pn
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:24:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322151838!5582802!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20256 invoked from network); 24 Nov 2011 16:23:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:23:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:23:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 16:23:58 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTc5d-0006kT-RW; Thu, 24 Nov 2011 16:23:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTc5d-0004Gw-Qm;
	Thu, 24 Nov 2011 16:23:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.28573.818575.318659@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 16:23:57 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <osstest-10020-mainreport@xen.org>
References: <osstest-10020-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 10020: regressions - FAIL"):
> flight 10020 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10020/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  build-i386                    4 xen-build                  fail REGR. vs. 995

gcc  -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-aft
er-statement   -D__XEN_TOOLS__ -MMD -MF .block-sync.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-
optimize-sibling-calls -mno-tls-direct-seg-refs -Werror -Wno-unused -I../lib -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/driv
ers/../../../tools/libxc -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/drivers/../../../tools/include -I/home/osstest/build.100
20.build-i386/xen-unstable/tools/blktap/drivers/../../../tools/xenstore -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/drivers/.
./../../tools/include -I ../../memshr -D_GNU_SOURCE -DMEMSHR  -c -o block-sync.o block-sync.c 
In file included from block-aio.c:45:
tapaio.h:42: error: expected specifier-qualifier-list before 'io_context_t'
block-aio.c: In function 'init_fds':
block-aio.c:117: error: 'tap_aio_internal_context_t' has no member named 'pollfd'
cc1: warnings being treated as errors
block-aio.c: In function 'tdaio_close':
block-aio.c:201: error: implicit declaration of function 'io_destroy'
block-aio.c:201: error: 'tap_aio_internal_context_t' has no member named 'aio_ctx'
block-aio.c: In function 'tdaio_do_callbacks':
block-aio.c:215: error: increment of pointer to unknown structure
block-aio.c:215: error: arithmetic on pointer to an incomplete type
block-aio.c:216: error: dereferencing pointer to incomplete type
block-aio.c:219: error: dereferencing pointer to incomplete type
block-aio.c:220: error: dereferencing pointer to incomplete type
block-aio.c:220: error: dereferencing pointer to incomplete type
block-aio.c:221: error: dereferencing pointer to incomplete type
make[5]: *** [block-aio.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: *** wait: No child processes.  Stop.
make[4]: *** [subdir-install-drivers] Error 2
make[4]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap'
make[3]: *** [subdirs-install] Error 2
make[3]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap'
make[2]: *** [subdir-install-blktap] Error 2
make[2]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools'
make: *** [install-tools] Error 2
+ test -f ../build-ok-stamp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:27:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:27:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTc8j-0004Oe-Ah; Thu, 24 Nov 2011 16:27:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTc8h-0004OQ-TN
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:27:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322151996!4872832!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18847 invoked from network); 24 Nov 2011 16:26:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:26:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTc89-000LTF-RB; Thu, 24 Nov 2011 16:26:33 +0000
Date: Thu, 24 Nov 2011 16:26:33 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124162633.GL77868@ocelot.phlegethon.org>
References: <patchbomb.1321307321@xdev.gridcentric.ca>
	<764e0872dd4f50c70fbc.1321307326@xdev.gridcentric.ca>
	<20111124153027.GH77868@ocelot.phlegethon.org>
	<3ef317bfa15a9cb853f589ad771a4dbb.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3ef317bfa15a9cb853f589ad771a4dbb.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:21 -0800 on 24 Nov (1322122868), Andres Lagar-Cavilla wrote:
> I don't think we'll ever be able to move out of global p2m locks if we
> allow these inline audits. In a fine-grained p2m lock case, the code will
> acquire exclusive rights on a range of the p2m. But then, in order to
> audit the whole p2m, it will need to promote its exclusive access to the
> whole p2m, and that's a deadlock trap.

Hmmm.  Fair enough, I guess.  As you said, this audit code wan't being
any use so your patch is an improvement. :)

I'd still like to see the interface changed, in particular so a domain
can't audit itself.

Tim.

> Ultimately, I can submit a patch that fixes the bit rotting and leaves the
> inlines in place. And if and when the p2m locking becomes fine-grained, we
> can ifdef into global locking if P2M_AUDIT is nonzero.
> 
> It's kinda yucky. And somewhat crippling of the intended debugging
> purposes of an audit (with fine-grained locks). But it will work and will
> not put the fine-grained cart before the locking horse.
> 
> Thanks
> Andres
> 
> > At 16:48 -0500 on 14 Nov (1321289326), Andres Lagar-Cavilla wrote:
> >> The p2m audit code doesn't even compile, let alone work. It also
> >> partially supports ept. Make it:
> >>
> >> - compile
> >> - lay groundwork for eventual ept support
> >> - move out of the way of all calls and turn it into a domctl. It's
> >>   obviously not being used by anybody presently.
> >> - enable it via said domctl
> >
> > Thanks for looking at this code (which, as you say, had considerably
> > rotted).
> >
> > I'm not sure I'm a big fan of provoking audits from user-space rather
> > than having them run on every operation; in previous incarnations there
> > have been serial debug-keys that triggered auditing code (which would
> > then be run before and after every operation) - I found that much more
> > helpful in the case of failure, as it pointed to which operation had
> > caused the problem rather than saying 'something bad happened at somne
> > point'.
> >
> > If you really want to keep the hypercall, I think it could probably be
> > part of the existing paging/shadow control domctl rather than having
> > its own.  That would have the advantage of preventing an untrusted
> > domain from calling it on itself (which has in the past turned slightly
> > bitrotted audit code into a denial-of-service vector!).
> >
> > Cheers,
> >
> > Tim.
> >
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:27:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:27:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTc8j-0004Oe-Ah; Thu, 24 Nov 2011 16:27:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTc8h-0004OQ-TN
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:27:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322151996!4872832!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18847 invoked from network); 24 Nov 2011 16:26:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:26:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTc89-000LTF-RB; Thu, 24 Nov 2011 16:26:33 +0000
Date: Thu, 24 Nov 2011 16:26:33 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124162633.GL77868@ocelot.phlegethon.org>
References: <patchbomb.1321307321@xdev.gridcentric.ca>
	<764e0872dd4f50c70fbc.1321307326@xdev.gridcentric.ca>
	<20111124153027.GH77868@ocelot.phlegethon.org>
	<3ef317bfa15a9cb853f589ad771a4dbb.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3ef317bfa15a9cb853f589ad771a4dbb.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 6] Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:21 -0800 on 24 Nov (1322122868), Andres Lagar-Cavilla wrote:
> I don't think we'll ever be able to move out of global p2m locks if we
> allow these inline audits. In a fine-grained p2m lock case, the code will
> acquire exclusive rights on a range of the p2m. But then, in order to
> audit the whole p2m, it will need to promote its exclusive access to the
> whole p2m, and that's a deadlock trap.

Hmmm.  Fair enough, I guess.  As you said, this audit code wan't being
any use so your patch is an improvement. :)

I'd still like to see the interface changed, in particular so a domain
can't audit itself.

Tim.

> Ultimately, I can submit a patch that fixes the bit rotting and leaves the
> inlines in place. And if and when the p2m locking becomes fine-grained, we
> can ifdef into global locking if P2M_AUDIT is nonzero.
> 
> It's kinda yucky. And somewhat crippling of the intended debugging
> purposes of an audit (with fine-grained locks). But it will work and will
> not put the fine-grained cart before the locking horse.
> 
> Thanks
> Andres
> 
> > At 16:48 -0500 on 14 Nov (1321289326), Andres Lagar-Cavilla wrote:
> >> The p2m audit code doesn't even compile, let alone work. It also
> >> partially supports ept. Make it:
> >>
> >> - compile
> >> - lay groundwork for eventual ept support
> >> - move out of the way of all calls and turn it into a domctl. It's
> >>   obviously not being used by anybody presently.
> >> - enable it via said domctl
> >
> > Thanks for looking at this code (which, as you say, had considerably
> > rotted).
> >
> > I'm not sure I'm a big fan of provoking audits from user-space rather
> > than having them run on every operation; in previous incarnations there
> > have been serial debug-keys that triggered auditing code (which would
> > then be run before and after every operation) - I found that much more
> > helpful in the case of failure, as it pointed to which operation had
> > caused the problem rather than saying 'something bad happened at somne
> > point'.
> >
> > If you really want to keep the hypercall, I think it could probably be
> > part of the existing paging/shadow control domctl rather than having
> > its own.  That would have the advantage of preventing an untrusted
> > domain from calling it on itself (which has in the past turned slightly
> > bitrotted audit code into a denial-of-service vector!).
> >
> > Cheers,
> >
> > Tim.
> >
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:28:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTc9Q-0004Su-PR; Thu, 24 Nov 2011 16:27:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTc9P-0004SH-A0
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:27:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322152039!4493555!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19515 invoked from network); 24 Nov 2011 16:27:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:27:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 16:27:18 +0000
Message-Id: <4ECE7E7602000078000630E6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 16:27:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEEC16376.0__="
Subject: [Xen-devel] [PATCH] x86: small fixes to pcpu platform op handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartEEC16376.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

XENPF_get_cpuinfo should init the flags output field rather than only
modify it.

XENPF_cpu_online must check for the input CPU number to be in range.

XENPF_cpu_offline must also do that, and should also reject attempts to
offline CPU 0 (this fails in cpu_down() too, but preventing this here
appears more correct given that the code here calls
continue_hypercall_on_cpu(0, ...), which would be flawed if cpu_down()
would ever allow bringing down CPU 0 (and a distinct error code is
easier to deal with when debugging issues).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -449,13 +449,14 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
         if ( (g_info->xen_cpuid >=3D nr_cpu_ids) ||
              !cpu_present(g_info->xen_cpuid) )
         {
-            g_info->flags |=3D XEN_PCPU_FLAGS_INVALID;
+            g_info->flags =3D XEN_PCPU_FLAGS_INVALID;
         }
         else
         {
             g_info->apic_id =3D x86_cpu_to_apicid[g_info->xen_cpuid];
             g_info->acpi_id =3D acpi_get_processor_id(g_info->xen_cpuid);
             ASSERT(g_info->apic_id !=3D BAD_APICID);
+            g_info->flags =3D 0;
             if (cpu_online(g_info->xen_cpuid))
                 g_info->flags |=3D XEN_PCPU_FLAGS_ONLINE;
         }
@@ -472,7 +473,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
     {
         int cpu =3D op->u.cpu_ol.cpuid;
=20
-        if ( !cpu_present(cpu) )
+        if ( cpu >=3D nr_cpu_ids || !cpu_present(cpu) )
         {
             ret =3D -EINVAL;
             break;
@@ -493,7 +494,13 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
     {
         int cpu =3D op->u.cpu_ol.cpuid;
=20
-        if ( !cpu_present(cpu) )
+        if ( cpu =3D=3D 0 )
+        {
+            ret =3D -EOPNOTSUPP;
+            break;
+        }
+
+        if ( cpu >=3D nr_cpu_ids || !cpu_present(cpu) )
         {
             ret =3D -EINVAL;
             break;




--=__PartEEC16376.0__=
Content-Type: text/plain; name="x86-pcpu-op.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-pcpu-op.patch"

x86: small fixes to pcpu platform op handling=0A=0AXENPF_get_cpuinfo =
should init the flags output field rather than only=0Amodify it.=0A=0AXENPF=
_cpu_online must check for the input CPU number to be in range.=0A=0AXENPF_=
cpu_offline must also do that, and should also reject attempts to=0Aoffline=
 CPU 0 (this fails in cpu_down() too, but preventing this here=0Aappears =
more correct given that the code here calls=0Acontinue_hypercall_on_cpu(0, =
...), which would be flawed if cpu_down()=0Awould ever allow bringing down =
CPU 0 (and a distinct error code is=0Aeasier to deal with when debugging =
issues).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/platform_hypercall.c=0A+++ b/xen/arch/x86/platform_hypercall=
.c=0A@@ -449,13 +449,14 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe=0A     =
    if ( (g_info->xen_cpuid >=3D nr_cpu_ids) ||=0A              !cpu_presen=
t(g_info->xen_cpuid) )=0A         {=0A-            g_info->flags |=3D =
XEN_PCPU_FLAGS_INVALID;=0A+            g_info->flags =3D XEN_PCPU_FLAGS_INV=
ALID;=0A         }=0A         else=0A         {=0A             g_info->apic=
_id =3D x86_cpu_to_apicid[g_info->xen_cpuid];=0A             g_info->acpi_i=
d =3D acpi_get_processor_id(g_info->xen_cpuid);=0A             ASSERT(g_inf=
o->apic_id !=3D BAD_APICID);=0A+            g_info->flags =3D 0;=0A        =
     if (cpu_online(g_info->xen_cpuid))=0A                 g_info->flags =
|=3D XEN_PCPU_FLAGS_ONLINE;=0A         }=0A@@ -472,7 +473,7 @@ ret_t =
do_platform_op(XEN_GUEST_HANDLE(xe=0A     {=0A         int cpu =3D =
op->u.cpu_ol.cpuid;=0A =0A-        if ( !cpu_present(cpu) )=0A+        if =
( cpu >=3D nr_cpu_ids || !cpu_present(cpu) )=0A         {=0A             =
ret =3D -EINVAL;=0A             break;=0A@@ -493,7 +494,13 @@ ret_t =
do_platform_op(XEN_GUEST_HANDLE(xe=0A     {=0A         int cpu =3D =
op->u.cpu_ol.cpuid;=0A =0A-        if ( !cpu_present(cpu) )=0A+        if =
( cpu =3D=3D 0 )=0A+        {=0A+            ret =3D -EOPNOTSUPP;=0A+      =
      break;=0A+        }=0A+=0A+        if ( cpu >=3D nr_cpu_ids || =
!cpu_present(cpu) )=0A         {=0A             ret =3D -EINVAL;=0A        =
     break;=0A
--=__PartEEC16376.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartEEC16376.0__=--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:28:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:28:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTc9Q-0004Su-PR; Thu, 24 Nov 2011 16:27:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTc9P-0004SH-A0
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:27:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322152039!4493555!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19515 invoked from network); 24 Nov 2011 16:27:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:27:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 16:27:18 +0000
Message-Id: <4ECE7E7602000078000630E6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 16:27:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEEC16376.0__="
Subject: [Xen-devel] [PATCH] x86: small fixes to pcpu platform op handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartEEC16376.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

XENPF_get_cpuinfo should init the flags output field rather than only
modify it.

XENPF_cpu_online must check for the input CPU number to be in range.

XENPF_cpu_offline must also do that, and should also reject attempts to
offline CPU 0 (this fails in cpu_down() too, but preventing this here
appears more correct given that the code here calls
continue_hypercall_on_cpu(0, ...), which would be flawed if cpu_down()
would ever allow bringing down CPU 0 (and a distinct error code is
easier to deal with when debugging issues).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -449,13 +449,14 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
         if ( (g_info->xen_cpuid >=3D nr_cpu_ids) ||
              !cpu_present(g_info->xen_cpuid) )
         {
-            g_info->flags |=3D XEN_PCPU_FLAGS_INVALID;
+            g_info->flags =3D XEN_PCPU_FLAGS_INVALID;
         }
         else
         {
             g_info->apic_id =3D x86_cpu_to_apicid[g_info->xen_cpuid];
             g_info->acpi_id =3D acpi_get_processor_id(g_info->xen_cpuid);
             ASSERT(g_info->apic_id !=3D BAD_APICID);
+            g_info->flags =3D 0;
             if (cpu_online(g_info->xen_cpuid))
                 g_info->flags |=3D XEN_PCPU_FLAGS_ONLINE;
         }
@@ -472,7 +473,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
     {
         int cpu =3D op->u.cpu_ol.cpuid;
=20
-        if ( !cpu_present(cpu) )
+        if ( cpu >=3D nr_cpu_ids || !cpu_present(cpu) )
         {
             ret =3D -EINVAL;
             break;
@@ -493,7 +494,13 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
     {
         int cpu =3D op->u.cpu_ol.cpuid;
=20
-        if ( !cpu_present(cpu) )
+        if ( cpu =3D=3D 0 )
+        {
+            ret =3D -EOPNOTSUPP;
+            break;
+        }
+
+        if ( cpu >=3D nr_cpu_ids || !cpu_present(cpu) )
         {
             ret =3D -EINVAL;
             break;




--=__PartEEC16376.0__=
Content-Type: text/plain; name="x86-pcpu-op.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-pcpu-op.patch"

x86: small fixes to pcpu platform op handling=0A=0AXENPF_get_cpuinfo =
should init the flags output field rather than only=0Amodify it.=0A=0AXENPF=
_cpu_online must check for the input CPU number to be in range.=0A=0AXENPF_=
cpu_offline must also do that, and should also reject attempts to=0Aoffline=
 CPU 0 (this fails in cpu_down() too, but preventing this here=0Aappears =
more correct given that the code here calls=0Acontinue_hypercall_on_cpu(0, =
...), which would be flawed if cpu_down()=0Awould ever allow bringing down =
CPU 0 (and a distinct error code is=0Aeasier to deal with when debugging =
issues).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/platform_hypercall.c=0A+++ b/xen/arch/x86/platform_hypercall=
.c=0A@@ -449,13 +449,14 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe=0A     =
    if ( (g_info->xen_cpuid >=3D nr_cpu_ids) ||=0A              !cpu_presen=
t(g_info->xen_cpuid) )=0A         {=0A-            g_info->flags |=3D =
XEN_PCPU_FLAGS_INVALID;=0A+            g_info->flags =3D XEN_PCPU_FLAGS_INV=
ALID;=0A         }=0A         else=0A         {=0A             g_info->apic=
_id =3D x86_cpu_to_apicid[g_info->xen_cpuid];=0A             g_info->acpi_i=
d =3D acpi_get_processor_id(g_info->xen_cpuid);=0A             ASSERT(g_inf=
o->apic_id !=3D BAD_APICID);=0A+            g_info->flags =3D 0;=0A        =
     if (cpu_online(g_info->xen_cpuid))=0A                 g_info->flags =
|=3D XEN_PCPU_FLAGS_ONLINE;=0A         }=0A@@ -472,7 +473,7 @@ ret_t =
do_platform_op(XEN_GUEST_HANDLE(xe=0A     {=0A         int cpu =3D =
op->u.cpu_ol.cpuid;=0A =0A-        if ( !cpu_present(cpu) )=0A+        if =
( cpu >=3D nr_cpu_ids || !cpu_present(cpu) )=0A         {=0A             =
ret =3D -EINVAL;=0A             break;=0A@@ -493,7 +494,13 @@ ret_t =
do_platform_op(XEN_GUEST_HANDLE(xe=0A     {=0A         int cpu =3D =
op->u.cpu_ol.cpuid;=0A =0A-        if ( !cpu_present(cpu) )=0A+        if =
( cpu =3D=3D 0 )=0A+        {=0A+            ret =3D -EOPNOTSUPP;=0A+      =
      break;=0A+        }=0A+=0A+        if ( cpu >=3D nr_cpu_ids || =
!cpu_present(cpu) )=0A         {=0A             ret =3D -EINVAL;=0A        =
     break;=0A
--=__PartEEC16376.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartEEC16376.0__=--


From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:29:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcAf-0004c3-9Z; Thu, 24 Nov 2011 16:29:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RTcAe-0004ba-3s
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:29:08 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322152098!49611578!1
X-Originating-IP: [206.212.254.10]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30077 invoked from network); 24 Nov 2011 16:28:19 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:28:19 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAOGSZid021664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 24 Nov 2011 11:28:35 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAOGSY94021662;
	Thu, 24 Nov 2011 11:28:34 -0500
Date: Thu, 24 Nov 2011 12:28:34 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111124162834.GA20715@andromeda.dapyr.net>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7C@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7C@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/6] X86: expose Intel new features to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 11:51:37PM +0800, Liu, Jinsong wrote:
> X86: expose Intel new features to dom0
> 
> This patch expose Intel new features to dom0, including FMA/AVX2/BMI1/BMI2/LZCNT/MOVBE.

And has it been tested with 3.1 pvops kernel?
Does it need a patch in the pvops kernel as well?
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r 38b25f3b2bca xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c	Thu Nov 17 17:54:17 2011 +0800
> +++ b/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
> @@ -826,8 +826,11 @@ static void pv_cpuid(struct cpu_user_reg
>  
>      case 0x00000007:
>          if ( regs->ecx == 0 )
> -            b &= (cpufeat_mask(X86_FEATURE_FSGSBASE) |
> -                  cpufeat_mask(X86_FEATURE_ERMS));
> +            b &= (cpufeat_mask(X86_FEATURE_BMI1) |
> +                  cpufeat_mask(X86_FEATURE_AVX2) |
> +                  cpufeat_mask(X86_FEATURE_BMI2) |
> +                  cpufeat_mask(X86_FEATURE_ERMS) |
> +                  cpufeat_mask(X86_FEATURE_FSGSBASE));
>          else
>              b = 0;
>          a = c = d = 0;
> diff -r 38b25f3b2bca xen/include/asm-x86/cpufeature.h
> --- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 17:54:17 2011 +0800
> +++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
> @@ -93,6 +93,7 @@
>  #define X86_FEATURE_TM2		(4*32+ 8) /* Thermal Monitor 2 */
>  #define X86_FEATURE_SSSE3	(4*32+ 9) /* Supplemental Streaming SIMD Extensions-3 */
>  #define X86_FEATURE_CID		(4*32+10) /* Context ID */
> +#define X86_FEATURE_FMA		(4*32+12) /* Fused Multiply Add */
>  #define X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */
>  #define X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
>  #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
> @@ -100,6 +101,7 @@
>  #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming SIMD Extensions 4.1 */
>  #define X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
>  #define X86_FEATURE_X2APIC	(4*32+21) /* Extended xAPIC */
> +#define X86_FEATURE_MOVBE	(4*32+22) /* movbe instruction */
>  #define X86_FEATURE_POPCNT	(4*32+23) /* POPCNT instruction */
>  #define X86_FEATURE_TSC_DEADLINE (4*32+24) /* "tdt" TSC Deadline Timer */
>  #define X86_FEATURE_AES		(4*32+25) /* AES instructions */
> @@ -145,7 +147,10 @@
>  
>  /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx), word 7 */
>  #define X86_FEATURE_FSGSBASE	(7*32+ 0) /* {RD,WR}{FS,GS}BASE instructions */
> +#define X86_FEATURE_BMI1	(7*32+ 3) /* 1st bit manipulation extensions */
> +#define X86_FEATURE_AVX2	(7*32+ 5) /* AVX2 instructions */
>  #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection */
> +#define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
>  #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
>  
>  #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:29:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:29:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcAf-0004c3-9Z; Thu, 24 Nov 2011 16:29:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RTcAe-0004ba-3s
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:29:08 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322152098!49611578!1
X-Originating-IP: [206.212.254.10]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30077 invoked from network); 24 Nov 2011 16:28:19 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:28:19 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAOGSZid021664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 24 Nov 2011 11:28:35 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAOGSY94021662;
	Thu, 24 Nov 2011 11:28:34 -0500
Date: Thu, 24 Nov 2011 12:28:34 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>
Message-ID: <20111124162834.GA20715@andromeda.dapyr.net>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7C@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7C@shsmsx502.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>, "JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/6] X86: expose Intel new features to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 11:51:37PM +0800, Liu, Jinsong wrote:
> X86: expose Intel new features to dom0
> 
> This patch expose Intel new features to dom0, including FMA/AVX2/BMI1/BMI2/LZCNT/MOVBE.

And has it been tested with 3.1 pvops kernel?
Does it need a patch in the pvops kernel as well?
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r 38b25f3b2bca xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c	Thu Nov 17 17:54:17 2011 +0800
> +++ b/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
> @@ -826,8 +826,11 @@ static void pv_cpuid(struct cpu_user_reg
>  
>      case 0x00000007:
>          if ( regs->ecx == 0 )
> -            b &= (cpufeat_mask(X86_FEATURE_FSGSBASE) |
> -                  cpufeat_mask(X86_FEATURE_ERMS));
> +            b &= (cpufeat_mask(X86_FEATURE_BMI1) |
> +                  cpufeat_mask(X86_FEATURE_AVX2) |
> +                  cpufeat_mask(X86_FEATURE_BMI2) |
> +                  cpufeat_mask(X86_FEATURE_ERMS) |
> +                  cpufeat_mask(X86_FEATURE_FSGSBASE));
>          else
>              b = 0;
>          a = c = d = 0;
> diff -r 38b25f3b2bca xen/include/asm-x86/cpufeature.h
> --- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 17:54:17 2011 +0800
> +++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
> @@ -93,6 +93,7 @@
>  #define X86_FEATURE_TM2		(4*32+ 8) /* Thermal Monitor 2 */
>  #define X86_FEATURE_SSSE3	(4*32+ 9) /* Supplemental Streaming SIMD Extensions-3 */
>  #define X86_FEATURE_CID		(4*32+10) /* Context ID */
> +#define X86_FEATURE_FMA		(4*32+12) /* Fused Multiply Add */
>  #define X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */
>  #define X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
>  #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
> @@ -100,6 +101,7 @@
>  #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming SIMD Extensions 4.1 */
>  #define X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
>  #define X86_FEATURE_X2APIC	(4*32+21) /* Extended xAPIC */
> +#define X86_FEATURE_MOVBE	(4*32+22) /* movbe instruction */
>  #define X86_FEATURE_POPCNT	(4*32+23) /* POPCNT instruction */
>  #define X86_FEATURE_TSC_DEADLINE (4*32+24) /* "tdt" TSC Deadline Timer */
>  #define X86_FEATURE_AES		(4*32+25) /* AES instructions */
> @@ -145,7 +147,10 @@
>  
>  /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx), word 7 */
>  #define X86_FEATURE_FSGSBASE	(7*32+ 0) /* {RD,WR}{FS,GS}BASE instructions */
> +#define X86_FEATURE_BMI1	(7*32+ 3) /* 1st bit manipulation extensions */
> +#define X86_FEATURE_AVX2	(7*32+ 5) /* AVX2 instructions */
>  #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection */
> +#define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
>  #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
>  
>  #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:31:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:31:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcCN-0004tK-28; Thu, 24 Nov 2011 16:30:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcCL-0004sJ-DV
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:30:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322152185!47249078!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7023 invoked from network); 24 Nov 2011 16:29:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:29:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:30:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 16:30:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcBp-0006mp-Qe; Thu, 24 Nov 2011 16:30:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcBp-0004IN-Pq;
	Thu, 24 Nov 2011 16:30:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.28957.787602.771046@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 16:30:21 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4EBA7C3A.6010801@amd.com>
References: <4EBA7C3A.6010801@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Refactor x86 specific code into
	x86	specific files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("[Xen-devel] [PATCH] libxc: Refactor x86 specific code into x86 specific files"):
> Move x86 specific code into x86 specific files.
> Eliminate arch specific PAGE constants by using common
> XC_PAGE_* contants.

I'm not sure I understand the motivation for this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:31:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:31:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcCN-0004tK-28; Thu, 24 Nov 2011 16:30:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcCL-0004sJ-DV
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:30:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322152185!47249078!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7023 invoked from network); 24 Nov 2011 16:29:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:29:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:30:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 16:30:22 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcBp-0006mp-Qe; Thu, 24 Nov 2011 16:30:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcBp-0004IN-Pq;
	Thu, 24 Nov 2011 16:30:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.28957.787602.771046@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 16:30:21 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4EBA7C3A.6010801@amd.com>
References: <4EBA7C3A.6010801@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Refactor x86 specific code into
	x86	specific files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("[Xen-devel] [PATCH] libxc: Refactor x86 specific code into x86 specific files"):
> Move x86 specific code into x86 specific files.
> Eliminate arch specific PAGE constants by using common
> XC_PAGE_* contants.

I'm not sure I understand the motivation for this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:36:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:36:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcH9-0005Lc-Tn; Thu, 24 Nov 2011 16:35:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTcH8-0005LM-Jn
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:35:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322152519!4479761!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8853 invoked from network); 24 Nov 2011 16:35:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:35:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:35:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 16:35:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 24 Nov 2011 16:35:18 +0000
In-Reply-To: <20174.28573.818575.318659@mariner.uk.xensource.com>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322152518.1005.189.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 16:23 +0000, Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 10020: regressions - FAIL"):
> > flight 10020 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/10020/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking:
> >  build-i386                    4 xen-build                  fail REGR. vs. 995
> 
> gcc  -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-aft
> er-statement   -D__XEN_TOOLS__ -MMD -MF .block-sync.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-
> optimize-sibling-calls -mno-tls-direct-seg-refs -Werror -Wno-unused -I../lib -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/driv
> ers/../../../tools/libxc -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/drivers/../../../tools/include -I/home/osstest/build.100
> 20.build-i386/xen-unstable/tools/blktap/drivers/../../../tools/xenstore -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/drivers/.
> ./../../tools/include -I ../../memshr -D_GNU_SOURCE -DMEMSHR  -c -o block-sync.o block-sync.c 
> In file included from block-aio.c:45:
> tapaio.h:42: error: expected specifier-qualifier-list before 'io_context_t'

Further up there is a 
block-aio.c:36:20: error: libaio.h: No such file or directory

I think you need to install libaio-dev.

Ian.

> block-aio.c: In function 'init_fds':
> block-aio.c:117: error: 'tap_aio_internal_context_t' has no member named 'pollfd'
> cc1: warnings being treated as errors
> block-aio.c: In function 'tdaio_close':
> block-aio.c:201: error: implicit declaration of function 'io_destroy'
> block-aio.c:201: error: 'tap_aio_internal_context_t' has no member named 'aio_ctx'
> block-aio.c: In function 'tdaio_do_callbacks':
> block-aio.c:215: error: increment of pointer to unknown structure
> block-aio.c:215: error: arithmetic on pointer to an incomplete type
> block-aio.c:216: error: dereferencing pointer to incomplete type
> block-aio.c:219: error: dereferencing pointer to incomplete type
> block-aio.c:220: error: dereferencing pointer to incomplete type
> block-aio.c:220: error: dereferencing pointer to incomplete type
> block-aio.c:221: error: dereferencing pointer to incomplete type
> make[5]: *** [block-aio.o] Error 1
> make[5]: *** Waiting for unfinished jobs....
> make[5]: *** wait: No child processes.  Stop.
> make[4]: *** [subdir-install-drivers] Error 2
> make[4]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap'
> make[3]: *** [subdirs-install] Error 2
> make[3]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap'
> make[2]: *** [subdir-install-blktap] Error 2
> make[2]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools'
> make: *** [install-tools] Error 2
> + test -f ../build-ok-stamp



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:36:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:36:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcH9-0005Lc-Tn; Thu, 24 Nov 2011 16:35:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTcH8-0005LM-Jn
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:35:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322152519!4479761!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8853 invoked from network); 24 Nov 2011 16:35:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:35:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:35:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 16:35:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 24 Nov 2011 16:35:18 +0000
In-Reply-To: <20174.28573.818575.318659@mariner.uk.xensource.com>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322152518.1005.189.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 16:23 +0000, Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 10020: regressions - FAIL"):
> > flight 10020 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/10020/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking:
> >  build-i386                    4 xen-build                  fail REGR. vs. 995
> 
> gcc  -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-aft
> er-statement   -D__XEN_TOOLS__ -MMD -MF .block-sync.o.d -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-
> optimize-sibling-calls -mno-tls-direct-seg-refs -Werror -Wno-unused -I../lib -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/driv
> ers/../../../tools/libxc -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/drivers/../../../tools/include -I/home/osstest/build.100
> 20.build-i386/xen-unstable/tools/blktap/drivers/../../../tools/xenstore -I/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap/drivers/.
> ./../../tools/include -I ../../memshr -D_GNU_SOURCE -DMEMSHR  -c -o block-sync.o block-sync.c 
> In file included from block-aio.c:45:
> tapaio.h:42: error: expected specifier-qualifier-list before 'io_context_t'

Further up there is a 
block-aio.c:36:20: error: libaio.h: No such file or directory

I think you need to install libaio-dev.

Ian.

> block-aio.c: In function 'init_fds':
> block-aio.c:117: error: 'tap_aio_internal_context_t' has no member named 'pollfd'
> cc1: warnings being treated as errors
> block-aio.c: In function 'tdaio_close':
> block-aio.c:201: error: implicit declaration of function 'io_destroy'
> block-aio.c:201: error: 'tap_aio_internal_context_t' has no member named 'aio_ctx'
> block-aio.c: In function 'tdaio_do_callbacks':
> block-aio.c:215: error: increment of pointer to unknown structure
> block-aio.c:215: error: arithmetic on pointer to an incomplete type
> block-aio.c:216: error: dereferencing pointer to incomplete type
> block-aio.c:219: error: dereferencing pointer to incomplete type
> block-aio.c:220: error: dereferencing pointer to incomplete type
> block-aio.c:220: error: dereferencing pointer to incomplete type
> block-aio.c:221: error: dereferencing pointer to incomplete type
> make[5]: *** [block-aio.o] Error 1
> make[5]: *** Waiting for unfinished jobs....
> make[5]: *** wait: No child processes.  Stop.
> make[4]: *** [subdir-install-drivers] Error 2
> make[4]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap'
> make[3]: *** [subdirs-install] Error 2
> make[3]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools/blktap'
> make[2]: *** [subdir-install-blktap] Error 2
> make[2]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools'
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/home/osstest/build.10020.build-i386/xen-unstable/tools'
> make: *** [install-tools] Error 2
> + test -f ../build-ok-stamp



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:36:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:36:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcHb-0005Nq-Bg; Thu, 24 Nov 2011 16:36:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTcHY-0005NK-Vh
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:36:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322152545!4498226!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23401 invoked from network); 24 Nov 2011 16:35:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:35:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 16:35:45 +0000
Message-Id: <4ECE80700200007800063105@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 16:35:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7C@shsmsx502.ccr.corp.intel.com>
	<20111124162834.GA20715@andromeda.dapyr.net>
In-Reply-To: <20111124162834.GA20715@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/6] X86: expose Intel new features to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.11.11 at 17:28, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> On Thu, Nov 24, 2011 at 11:51:37PM +0800, Liu, Jinsong wrote:
>> X86: expose Intel new features to dom0
>> 
>> This patch expose Intel new features to dom0, including 
> FMA/AVX2/BMI1/BMI2/LZCNT/MOVBE.
> 
> And has it been tested with 3.1 pvops kernel?
> Does it need a patch in the pvops kernel as well?

No - these are all unprivileged instructions not requiring any OS support.

Jan

>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r 38b25f3b2bca xen/arch/x86/traps.c
>> --- a/xen/arch/x86/traps.c	Thu Nov 17 17:54:17 2011 +0800
>> +++ b/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
>> @@ -826,8 +826,11 @@ static void pv_cpuid(struct cpu_user_reg
>>  
>>      case 0x00000007:
>>          if ( regs->ecx == 0 )
>> -            b &= (cpufeat_mask(X86_FEATURE_FSGSBASE) |
>> -                  cpufeat_mask(X86_FEATURE_ERMS));
>> +            b &= (cpufeat_mask(X86_FEATURE_BMI1) |
>> +                  cpufeat_mask(X86_FEATURE_AVX2) |
>> +                  cpufeat_mask(X86_FEATURE_BMI2) |
>> +                  cpufeat_mask(X86_FEATURE_ERMS) |
>> +                  cpufeat_mask(X86_FEATURE_FSGSBASE));
>>          else
>>              b = 0;
>>          a = c = d = 0;
>> diff -r 38b25f3b2bca xen/include/asm-x86/cpufeature.h
>> --- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 17:54:17 2011 +0800
>> +++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
>> @@ -93,6 +93,7 @@
>>  #define X86_FEATURE_TM2		(4*32+ 8) /* Thermal Monitor 2 */
>>  #define X86_FEATURE_SSSE3	(4*32+ 9) /* Supplemental Streaming SIMD 
> Extensions-3 */
>>  #define X86_FEATURE_CID		(4*32+10) /* Context ID */
>> +#define X86_FEATURE_FMA		(4*32+12) /* Fused Multiply Add */
>>  #define X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */
>>  #define X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
>>  #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
>> @@ -100,6 +101,7 @@
>>  #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming SIMD Extensions 4.1 */
>>  #define X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
>>  #define X86_FEATURE_X2APIC	(4*32+21) /* Extended xAPIC */
>> +#define X86_FEATURE_MOVBE	(4*32+22) /* movbe instruction */
>>  #define X86_FEATURE_POPCNT	(4*32+23) /* POPCNT instruction */
>>  #define X86_FEATURE_TSC_DEADLINE (4*32+24) /* "tdt" TSC Deadline Timer */
>>  #define X86_FEATURE_AES		(4*32+25) /* AES instructions */
>> @@ -145,7 +147,10 @@
>>  
>>  /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx), word 7 */
>>  #define X86_FEATURE_FSGSBASE	(7*32+ 0) /* {RD,WR}{FS,GS}BASE instructions */
>> +#define X86_FEATURE_BMI1	(7*32+ 3) /* 1st bit manipulation extensions */
>> +#define X86_FEATURE_AVX2	(7*32+ 5) /* AVX2 instructions */
>>  #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection 
> */
>> +#define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
>>  #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
>>  
>>  #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:36:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:36:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcHb-0005Nq-Bg; Thu, 24 Nov 2011 16:36:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTcHY-0005NK-Vh
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:36:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322152545!4498226!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23401 invoked from network); 24 Nov 2011 16:35:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:35:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 16:35:45 +0000
Message-Id: <4ECE80700200007800063105@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 16:35:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7C@shsmsx502.ccr.corp.intel.com>
	<20111124162834.GA20715@andromeda.dapyr.net>
In-Reply-To: <20111124162834.GA20715@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/6] X86: expose Intel new features to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.11.11 at 17:28, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> On Thu, Nov 24, 2011 at 11:51:37PM +0800, Liu, Jinsong wrote:
>> X86: expose Intel new features to dom0
>> 
>> This patch expose Intel new features to dom0, including 
> FMA/AVX2/BMI1/BMI2/LZCNT/MOVBE.
> 
> And has it been tested with 3.1 pvops kernel?
> Does it need a patch in the pvops kernel as well?

No - these are all unprivileged instructions not requiring any OS support.

Jan

>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r 38b25f3b2bca xen/arch/x86/traps.c
>> --- a/xen/arch/x86/traps.c	Thu Nov 17 17:54:17 2011 +0800
>> +++ b/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
>> @@ -826,8 +826,11 @@ static void pv_cpuid(struct cpu_user_reg
>>  
>>      case 0x00000007:
>>          if ( regs->ecx == 0 )
>> -            b &= (cpufeat_mask(X86_FEATURE_FSGSBASE) |
>> -                  cpufeat_mask(X86_FEATURE_ERMS));
>> +            b &= (cpufeat_mask(X86_FEATURE_BMI1) |
>> +                  cpufeat_mask(X86_FEATURE_AVX2) |
>> +                  cpufeat_mask(X86_FEATURE_BMI2) |
>> +                  cpufeat_mask(X86_FEATURE_ERMS) |
>> +                  cpufeat_mask(X86_FEATURE_FSGSBASE));
>>          else
>>              b = 0;
>>          a = c = d = 0;
>> diff -r 38b25f3b2bca xen/include/asm-x86/cpufeature.h
>> --- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 17:54:17 2011 +0800
>> +++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
>> @@ -93,6 +93,7 @@
>>  #define X86_FEATURE_TM2		(4*32+ 8) /* Thermal Monitor 2 */
>>  #define X86_FEATURE_SSSE3	(4*32+ 9) /* Supplemental Streaming SIMD 
> Extensions-3 */
>>  #define X86_FEATURE_CID		(4*32+10) /* Context ID */
>> +#define X86_FEATURE_FMA		(4*32+12) /* Fused Multiply Add */
>>  #define X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */
>>  #define X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
>>  #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
>> @@ -100,6 +101,7 @@
>>  #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming SIMD Extensions 4.1 */
>>  #define X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
>>  #define X86_FEATURE_X2APIC	(4*32+21) /* Extended xAPIC */
>> +#define X86_FEATURE_MOVBE	(4*32+22) /* movbe instruction */
>>  #define X86_FEATURE_POPCNT	(4*32+23) /* POPCNT instruction */
>>  #define X86_FEATURE_TSC_DEADLINE (4*32+24) /* "tdt" TSC Deadline Timer */
>>  #define X86_FEATURE_AES		(4*32+25) /* AES instructions */
>> @@ -145,7 +147,10 @@
>>  
>>  /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx), word 7 */
>>  #define X86_FEATURE_FSGSBASE	(7*32+ 0) /* {RD,WR}{FS,GS}BASE instructions */
>> +#define X86_FEATURE_BMI1	(7*32+ 3) /* 1st bit manipulation extensions */
>> +#define X86_FEATURE_AVX2	(7*32+ 5) /* AVX2 instructions */
>>  #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection 
> */
>> +#define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
>>  #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
>>  
>>  #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:38:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcJg-0005bU-Tz; Thu, 24 Nov 2011 16:38:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTcJf-0005b3-3L
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:38:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322152557!45683377!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9618 invoked from network); 24 Nov 2011 16:35:58 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:35:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTcJ9-000LVY-MF; Thu, 24 Nov 2011 16:37:55 +0000
Date: Thu, 24 Nov 2011 16:37:55 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124163755.GM77868@ocelot.phlegethon.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 00 of 14] MM Fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:11 -0500 on 23 Nov (1322064667), Andres Lagar-Cavilla wrote:
> This patch series includes a number of bug fixes, targetting 
> primarily the mm layer. Many of these fixes also lay groundwork
> for future patches.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Thanks for these
 - 1-4 I addressed in the last round without noticing they'd been reposted
 - 5 and 6 I've commented on separately
 - 7-11 are applied.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:38:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcJg-0005bU-Tz; Thu, 24 Nov 2011 16:38:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTcJf-0005b3-3L
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:38:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322152557!45683377!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9618 invoked from network); 24 Nov 2011 16:35:58 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:35:58 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTcJ9-000LVY-MF; Thu, 24 Nov 2011 16:37:55 +0000
Date: Thu, 24 Nov 2011 16:37:55 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124163755.GM77868@ocelot.phlegethon.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322082667@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 00 of 14] MM Fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 16:11 -0500 on 23 Nov (1322064667), Andres Lagar-Cavilla wrote:
> This patch series includes a number of bug fixes, targetting 
> primarily the mm layer. Many of these fixes also lay groundwork
> for future patches.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Thanks for these
 - 1-4 I addressed in the last round without noticing they'd been reposted
 - 5 and 6 I've commented on separately
 - 7-11 are applied.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:39:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:39:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcKa-0005hg-Cq; Thu, 24 Nov 2011 16:39:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcKY-0005gy-Rm
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:39:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322152731!2909177!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18909 invoked from network); 24 Nov 2011 16:38:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:38:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117662"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:38:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 16:38:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcK2-0006q2-Mw; Thu, 24 Nov 2011 16:38:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcK2-0004Lg-M4;
	Thu, 24 Nov 2011 16:38:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.29466.673218.433257@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 16:38:50 +0000
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <123596ca8b29d3fd9922.1321279510@nehalem1>
References: <123596ca8b29d3fd9922.1321279510@nehalem1>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] add xl sched-credit2 sub command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Juergen Gross writes ("[Xen-devel] [PATCH] add xl sched-credit2 sub command"):
> Adds the sched-credit2 sub command to xl.

Thanks, this looks like good stuff.

I have just one comment though.  Can you try to limit the length of
the lines ?  When I see them in my 80-column windows they wrap.  Try
to keep it to 70-75 columns to allow for quoting, +/- prefixes, etc.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:39:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:39:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcKa-0005hg-Cq; Thu, 24 Nov 2011 16:39:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcKY-0005gy-Rm
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:39:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322152731!2909177!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18909 invoked from network); 24 Nov 2011 16:38:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:38:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117662"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:38:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 16:38:50 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcK2-0006q2-Mw; Thu, 24 Nov 2011 16:38:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcK2-0004Lg-M4;
	Thu, 24 Nov 2011 16:38:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.29466.673218.433257@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 16:38:50 +0000
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <123596ca8b29d3fd9922.1321279510@nehalem1>
References: <123596ca8b29d3fd9922.1321279510@nehalem1>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] add xl sched-credit2 sub command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Juergen Gross writes ("[Xen-devel] [PATCH] add xl sched-credit2 sub command"):
> Adds the sched-credit2 sub command to xl.

Thanks, this looks like good stuff.

I have just one comment though.  Can you try to limit the length of
the lines ?  When I see them in my 80-column windows they wrap.  Try
to keep it to 70-75 columns to allow for quoting, +/- prefixes, etc.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:42:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:42:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcNG-00060j-1p; Thu, 24 Nov 2011 16:42:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTcNE-00060T-Hy
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:42:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322152782!45683880!1
X-Originating-IP: [208.97.132.202]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20818 invoked from network); 24 Nov 2011 16:39:42 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.202) by server-14.tower-27.messagelabs.com with SMTP;
	24 Nov 2011 16:39:42 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 58A90250071;
	Thu, 24 Nov 2011 08:41:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=aPmPS+CQ8sAebee0KlRJzFawziWEsIgErkauCaj5cNlc
	H0rngD3YLuW55DdXhMjgKbIoG7T++KMlMMUFN1ZCQZBwXJlDCXMgs+DyHTJvlvem
	A/X1d/ciJmTdEN+HGvbfawZuxcaZnrh5mWge1KgF8/dNHOzmTKlB2MdssgcPudU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=6vt86pob0pDCHgk57UNsly5zUWY=; b=t7eMCpTe
	NFUAyeXOfkAXj51VwVmVuSYGUqo4pKekvwh3oOUW/6Y+IhrtWoXSQkzbDdPKPzda
	NotWVY/DhDkjAHYnavNY/92rgzXtUkz2vcY3+3yGalQhcNXBz6iRxejmjgAVKHuf
	7dpOx2j7EavhSVHfRbRz8ISV0cIosBi4vm0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id A993625006C; 
	Thu, 24 Nov 2011 08:41:40 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 08:41:41 -0800
Message-ID: <180057def2be9bc8eb519865f17aca96.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124113507.GA77868@ocelot.phlegethon.org>
References: <patchbomb.1320788543@xdev.gridcentric.ca>
	<6203a0549d8a1a21753b.1320788545@xdev.gridcentric.ca>
	<20111110125342.GG62117@ocelot.phlegethon.org>
	<4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
	<20111124113507.GA77868@ocelot.phlegethon.org>
Date: Thu, 24 Nov 2011 08:41:41 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Make p2m lookups fully synchronized
 wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 10:03 -0800 on 14 Nov (1321264988), Andres Lagar-Cavilla wrote:
>> Hi there,
>> > At 16:42 -0500 on 08 Nov (1320770545), Andres Lagar-Cavilla wrote:
>> >>  xen/arch/x86/mm/mm-locks.h |  13 +++++++------
>> >>  xen/arch/x86/mm/p2m.c      |  18 +++++++++++++++++-
>> >>  xen/include/asm-x86/p2m.h  |  39
>> >> ++++++++++++++++++++++++---------------
>> >>  3 files changed, 48 insertions(+), 22 deletions(-)
>> >>
>> >>
>> >> We achieve this by locking/unlocking the global p2m_lock in
>> get/put_gfn.
>> >> This brings about a few consequences for the p2m_lock:
>> >>
>> >>  - not ordered anymore in mm-locks.h: unshare does get_gfn ->
>> shr_lock,
>> >>    there are code paths that do paging_lock -> get_gfn. All of these
>> >>    would cause mm-locks.h to panic.
>> >
>> > In that case there's a potential deadlock in the sharing code, and
>> > turning off the safety catches is not an acceptable response to that.
>> :)
>> >
>> > ISTR you had a plan to get rid of the shr_lock entirely, or am
>> > I misremembering?
>> Sharing is actually fine, I can reorder those safely until I get rid of
>> the shr_lock. Except for sharing audits, which basically lock the whole
>> hypervisor, and _no one is using at all_.
>>
>> I have a more fundamental problem with the paging lock. sh_update_cr3
>> can
>> be called from a variety of situations. It will walk the four top level
>> PAE mappings, acquiring the p2m entry for each, with the paging lock
>> held.
>> This is an inversion & deadlock, if I try to synchronize p2m lookups
>> with
>> the p2m lock.
>
> Is sh_update_cr3() really called with p2m locks/refs held?  Since it
> doesn't take a frame number as an argument it might be possible to
> shuffle things around at the callers.

Ok, I've refined this a bit. There are several instances of code that
takes the paging_lock and later needs to perform a p2m lookup. Apart from
the previously mentioned example here are two others:

hap_update_paging_modes -> ... -> vmx_load_pdptrs -> get_gfn(guest_cr3)

sh_x86_emulate_* -> ... -> validate_gl?e -> get_gfn_query()

None of these functions are called with p2m locks/refs held, and likely
they shouldn't. However, they will result in a deadlock panic situation,
if get_gfn takes a lock.

Here is one solution to consider: do not lock the p2m on lookups in shadow
mode. Shadow mode does not support paging out and sharing of pages, which
are primary reasons why we want synchronized p2m lookups. The hap cases
where there is an inversion of the p2m_lock -> paging_lock order are
reasonably simple to handle.

The other option is to invert the order and place paging_lock -> p2m_lock,
but that will raise another set of potential inversions. I think this is a
no go.

Finally, one could audit all these calls and have them perform futurology,
get_gfn the gfn they will end up perhaps looking up, before taking the
paging_lock. I also think this is a no go.

All very unsavory.
Andres

>
>> Any suggestions here? Other than disabling ordering of the p2m lock?
>
> Disabling the ordering won't do, so we need to find something else.
>
> Tim.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:42:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:42:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcNG-00060j-1p; Thu, 24 Nov 2011 16:42:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTcNE-00060T-Hy
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:42:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322152782!45683880!1
X-Originating-IP: [208.97.132.202]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20818 invoked from network); 24 Nov 2011 16:39:42 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.202) by server-14.tower-27.messagelabs.com with SMTP;
	24 Nov 2011 16:39:42 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 58A90250071;
	Thu, 24 Nov 2011 08:41:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=aPmPS+CQ8sAebee0KlRJzFawziWEsIgErkauCaj5cNlc
	H0rngD3YLuW55DdXhMjgKbIoG7T++KMlMMUFN1ZCQZBwXJlDCXMgs+DyHTJvlvem
	A/X1d/ciJmTdEN+HGvbfawZuxcaZnrh5mWge1KgF8/dNHOzmTKlB2MdssgcPudU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=6vt86pob0pDCHgk57UNsly5zUWY=; b=t7eMCpTe
	NFUAyeXOfkAXj51VwVmVuSYGUqo4pKekvwh3oOUW/6Y+IhrtWoXSQkzbDdPKPzda
	NotWVY/DhDkjAHYnavNY/92rgzXtUkz2vcY3+3yGalQhcNXBz6iRxejmjgAVKHuf
	7dpOx2j7EavhSVHfRbRz8ISV0cIosBi4vm0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id A993625006C; 
	Thu, 24 Nov 2011 08:41:40 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 08:41:41 -0800
Message-ID: <180057def2be9bc8eb519865f17aca96.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124113507.GA77868@ocelot.phlegethon.org>
References: <patchbomb.1320788543@xdev.gridcentric.ca>
	<6203a0549d8a1a21753b.1320788545@xdev.gridcentric.ca>
	<20111110125342.GG62117@ocelot.phlegethon.org>
	<4cb5acd8fa013dc40d5063d61296a319.squirrel@webmail.lagarcavilla.org>
	<20111124113507.GA77868@ocelot.phlegethon.org>
Date: Thu, 24 Nov 2011 08:41:41 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, george.dunlap@eu.citrix.com,
	andres@gridcentric.ca, keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Make p2m lookups fully synchronized
 wrt modifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 10:03 -0800 on 14 Nov (1321264988), Andres Lagar-Cavilla wrote:
>> Hi there,
>> > At 16:42 -0500 on 08 Nov (1320770545), Andres Lagar-Cavilla wrote:
>> >>  xen/arch/x86/mm/mm-locks.h |  13 +++++++------
>> >>  xen/arch/x86/mm/p2m.c      |  18 +++++++++++++++++-
>> >>  xen/include/asm-x86/p2m.h  |  39
>> >> ++++++++++++++++++++++++---------------
>> >>  3 files changed, 48 insertions(+), 22 deletions(-)
>> >>
>> >>
>> >> We achieve this by locking/unlocking the global p2m_lock in
>> get/put_gfn.
>> >> This brings about a few consequences for the p2m_lock:
>> >>
>> >>  - not ordered anymore in mm-locks.h: unshare does get_gfn ->
>> shr_lock,
>> >>    there are code paths that do paging_lock -> get_gfn. All of these
>> >>    would cause mm-locks.h to panic.
>> >
>> > In that case there's a potential deadlock in the sharing code, and
>> > turning off the safety catches is not an acceptable response to that.
>> :)
>> >
>> > ISTR you had a plan to get rid of the shr_lock entirely, or am
>> > I misremembering?
>> Sharing is actually fine, I can reorder those safely until I get rid of
>> the shr_lock. Except for sharing audits, which basically lock the whole
>> hypervisor, and _no one is using at all_.
>>
>> I have a more fundamental problem with the paging lock. sh_update_cr3
>> can
>> be called from a variety of situations. It will walk the four top level
>> PAE mappings, acquiring the p2m entry for each, with the paging lock
>> held.
>> This is an inversion & deadlock, if I try to synchronize p2m lookups
>> with
>> the p2m lock.
>
> Is sh_update_cr3() really called with p2m locks/refs held?  Since it
> doesn't take a frame number as an argument it might be possible to
> shuffle things around at the callers.

Ok, I've refined this a bit. There are several instances of code that
takes the paging_lock and later needs to perform a p2m lookup. Apart from
the previously mentioned example here are two others:

hap_update_paging_modes -> ... -> vmx_load_pdptrs -> get_gfn(guest_cr3)

sh_x86_emulate_* -> ... -> validate_gl?e -> get_gfn_query()

None of these functions are called with p2m locks/refs held, and likely
they shouldn't. However, they will result in a deadlock panic situation,
if get_gfn takes a lock.

Here is one solution to consider: do not lock the p2m on lookups in shadow
mode. Shadow mode does not support paging out and sharing of pages, which
are primary reasons why we want synchronized p2m lookups. The hap cases
where there is an inversion of the p2m_lock -> paging_lock order are
reasonably simple to handle.

The other option is to invert the order and place paging_lock -> p2m_lock,
but that will raise another set of potential inversions. I think this is a
no go.

Finally, one could audit all these calls and have them perform futurology,
get_gfn the gfn they will end up perhaps looking up, before taking the
paging_lock. I also think this is a no go.

All very unsavory.
Andres

>
>> Any suggestions here? Other than disabling ordering of the p2m lock?
>
> Disabling the ordering won't do, so we need to find something else.
>
> Tim.
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:48:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:48:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcTW-0006IM-2f; Thu, 24 Nov 2011 16:48:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTcTV-0006IG-7Y
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:48:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322153258!49817622!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16272 invoked from network); 24 Nov 2011 16:47:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:47:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTcSz-000LXp-EP; Thu, 24 Nov 2011 16:48:05 +0000
Date: Thu, 24 Nov 2011 16:48:05 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124164805.GN77868@ocelot.phlegethon.org>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
	<f079cbeae77e5570c193.1322142091@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f079cbeae77e5570c193.1322142091@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] Ensure maps used by nested hvm code
	cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


This is a bit messy still.  On 64-bit Xen we could just use
virt_to_page() on the map pointers rather than storing their 
page_info pointers separately. 

On 32-bit, maybe we could use the existing linear mappings to look up
the MFN instead.  Or would it be easier to add a function to eth
map_domain_page() family that does va->mfn for mapped frames?
Keir, any opinion?

Tim.

At 08:41 -0500 on 24 Nov (1322124091), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/hvm.c             |  69 ++++++++++++++++++++++++-------------
>  xen/arch/x86/hvm/nestedhvm.c       |   4 +-
>  xen/arch/x86/hvm/svm/nestedsvm.c   |  23 ++++++------
>  xen/arch/x86/hvm/vmx/vvmx.c        |  36 +++++++++++--------
>  xen/include/asm-x86/hvm/hvm.h      |   9 +++-
>  xen/include/asm-x86/hvm/vcpu.h     |   1 +
>  xen/include/asm-x86/hvm/vmx/vvmx.h |   1 +
>  7 files changed, 88 insertions(+), 55 deletions(-)
> 
> 
> The nested hvm code maps pages of the guest hvm. These maps live beyond
> a hypervisor entry/exit pair, and thus their liveness cannot be ensured
> with get_gfn/put_gfn critical sections. Ensure their liveness by
> increasing the page ref count, instead.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1801,11 +1801,15 @@ int hvm_virtual_to_linear_addr(
>      return 0;
>  }
>  
> -/* We leave this function holding a lock on the p2m entry */
> -static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
> +/* On non-NULL return, we leave this function holding an additional 
> + * ref on the underlying mfn, if any */
> +static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable,
> +                                    struct page_info **page)
>  {
> +    void *map;
>      unsigned long mfn;
>      p2m_type_t p2mt;
> +    struct page_info *pg;
>      struct domain *d = current->domain;
>  
>      mfn = mfn_x(writable
> @@ -1828,27 +1832,43 @@ static void *__hvm_map_guest_frame(unsig
>      if ( writable )
>          paging_mark_dirty(d, mfn);
>  
> -    return map_domain_page(mfn);
> +    pg = mfn_to_page(mfn);
> +    if (page)
> +    {
> +        page_get_owner_and_reference(pg);
> +        *page = pg;
> +    }
> +
> +    map = map_domain_page(mfn);
> +    put_gfn(d, gfn);
> +    return map;
>  }
>  
> -void *hvm_map_guest_frame_rw(unsigned long gfn)
> +void *hvm_map_guest_frame_rw(unsigned long gfn,
> +                             struct page_info **page)
>  {
> -    return __hvm_map_guest_frame(gfn, 1);
> +    return __hvm_map_guest_frame(gfn, 1, page);
>  }
>  
> -void *hvm_map_guest_frame_ro(unsigned long gfn)
> +void *hvm_map_guest_frame_ro(unsigned long gfn,
> +                             struct page_info **page)
>  {
> -    return __hvm_map_guest_frame(gfn, 0);
> +    return __hvm_map_guest_frame(gfn, 0, page);
>  }
>  
> -void hvm_unmap_guest_frame(void *p)
> +void hvm_unmap_guest_frame(void *p, struct page_info *page)
>  {
>      if ( p )
> +    {
>          unmap_domain_page(p);
> +        if ( page )
> +            put_page(page);
> +    }
>  }
>  
> -static void *hvm_map_entry(unsigned long va, unsigned long *gfn)
> +static void *hvm_map_entry(unsigned long va, struct page_info **page)
>  {
> +    unsigned long gfn;
>      uint32_t pfec;
>      char *v;
>  
> @@ -1865,11 +1885,11 @@ static void *hvm_map_entry(unsigned long
>       * treat it as a kernel-mode read (i.e. no access checks).
>       */
>      pfec = PFEC_page_present;
> -    *gfn = paging_gva_to_gfn(current, va, &pfec);
> +    gfn = paging_gva_to_gfn(current, va, &pfec);
>      if ( (pfec == PFEC_page_paged) || (pfec == PFEC_page_shared) )
>          goto fail;
>  
> -    v = hvm_map_guest_frame_rw(*gfn);
> +    v = hvm_map_guest_frame_rw(gfn, page);
>      if ( v == NULL )
>          goto fail;
>  
> @@ -1880,11 +1900,9 @@ static void *hvm_map_entry(unsigned long
>      return NULL;
>  }
>  
> -static void hvm_unmap_entry(void *p, unsigned long gfn)
> +static void hvm_unmap_entry(void *p, struct page_info *page)
>  {
> -    hvm_unmap_guest_frame(p);
> -    if ( p && (gfn != INVALID_GFN) )
> -        put_gfn(current->domain, gfn);
> +    hvm_unmap_guest_frame(p, page);
>  }
>  
>  static int hvm_load_segment_selector(
> @@ -1896,7 +1914,7 @@ static int hvm_load_segment_selector(
>      int fault_type = TRAP_invalid_tss;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
>      struct vcpu *v = current;
> -    unsigned long pdesc_gfn = INVALID_GFN;
> +    struct page_info *pdesc_pg = NULL;
>  
>      if ( regs->eflags & X86_EFLAGS_VM )
>      {
> @@ -1930,7 +1948,7 @@ static int hvm_load_segment_selector(
>      if ( ((sel & 0xfff8) + 7) > desctab.limit )
>          goto fail;
>  
> -    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_gfn);
> +    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_pg);
>      if ( pdesc == NULL )
>          goto hvm_map_fail;
>  
> @@ -1990,7 +2008,7 @@ static int hvm_load_segment_selector(
>      desc.b |= 0x100;
>  
>   skip_accessed_flag:
> -    hvm_unmap_entry(pdesc, pdesc_gfn);
> +    hvm_unmap_entry(pdesc, pdesc_pg);
>  
>      segr.base = (((desc.b <<  0) & 0xff000000u) |
>                   ((desc.b << 16) & 0x00ff0000u) |
> @@ -2006,7 +2024,7 @@ static int hvm_load_segment_selector(
>      return 0;
>  
>   unmap_and_fail:
> -    hvm_unmap_entry(pdesc, pdesc_gfn);
> +    hvm_unmap_entry(pdesc, pdesc_pg);
>   fail:
>      hvm_inject_exception(fault_type, sel & 0xfffc, 0);
>   hvm_map_fail:
> @@ -2021,7 +2039,8 @@ void hvm_task_switch(
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
>      struct segment_register gdt, tr, prev_tr, segr;
>      struct desc_struct *optss_desc = NULL, *nptss_desc = NULL, tss_desc;
> -    unsigned long eflags, optss_gfn = INVALID_GFN, nptss_gfn = INVALID_GFN;
> +    unsigned long eflags;
> +    struct page_info *optss_pg = NULL, *nptss_pg = NULL;
>      int exn_raised, rc;
>      struct {
>          u16 back_link,__blh;
> @@ -2047,11 +2066,13 @@ void hvm_task_switch(
>          goto out;
>      }
>  
> -    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), &optss_gfn);
> +    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), 
> +                                &optss_pg);
>      if ( optss_desc == NULL )
>          goto out;
>  
> -    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), &nptss_gfn);
> +    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), 
> +                                &nptss_pg);
>      if ( nptss_desc == NULL )
>          goto out;
>  
> @@ -2216,8 +2237,8 @@ void hvm_task_switch(
>      }
>  
>   out:
> -    hvm_unmap_entry(optss_desc, optss_gfn);
> -    hvm_unmap_entry(nptss_desc, nptss_gfn);
> +    hvm_unmap_entry(optss_desc, optss_pg);
> +    hvm_unmap_entry(nptss_desc, nptss_pg);
>  }
>  
>  #define HVMCOPY_from_guest (0u<<0)
> diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/nestedhvm.c
> --- a/xen/arch/x86/hvm/nestedhvm.c
> +++ b/xen/arch/x86/hvm/nestedhvm.c
> @@ -56,9 +56,11 @@ nestedhvm_vcpu_reset(struct vcpu *v)
>      nv->nv_ioportED = 0;
>  
>      if (nv->nv_vvmcx)
> -        hvm_unmap_guest_frame(nv->nv_vvmcx);
> +        hvm_unmap_guest_frame(nv->nv_vvmcx, 
> +                              nv->nv_vvmcx_pg);
>      nv->nv_vvmcx = NULL;
>      nv->nv_vvmcxaddr = VMCX_EADDR;
> +    nv->nv_vvmcx_pg  = NULL;
>      nv->nv_flushp2m = 0;
>      nv->nv_p2m = NULL;
>  
> diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/svm/nestedsvm.c
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -71,20 +71,18 @@ int nestedsvm_vmcb_map(struct vcpu *v, u
>      if (nv->nv_vvmcx != NULL && nv->nv_vvmcxaddr != vmcbaddr) {
>          ASSERT(nv->nv_vvmcx != NULL);
>          ASSERT(nv->nv_vvmcxaddr != VMCX_EADDR);
> -        hvm_unmap_guest_frame(nv->nv_vvmcx);
> +        hvm_unmap_guest_frame(nv->nv_vvmcx, nv->nv_vvmcx_pg);
>          nv->nv_vvmcx = NULL;
>          nv->nv_vvmcxaddr = VMCX_EADDR;
> +        nv->nv_vvmcx_pg = NULL;
>      }
>  
>      if (nv->nv_vvmcx == NULL) {
> -        nv->nv_vvmcx = hvm_map_guest_frame_rw(vmcbaddr >> PAGE_SHIFT);
> +        nv->nv_vvmcx = hvm_map_guest_frame_rw(vmcbaddr >> PAGE_SHIFT,
> +                                                &nv->nv_vvmcx_pg);
>          if (nv->nv_vvmcx == NULL)
>              return 0;
>          nv->nv_vvmcxaddr = vmcbaddr;
> -        /* put_gfn here even though the map survives beyond this caller.
> -         * The map can likely survive beyond a hypervisor exit, thus we
> -         * need to put the gfn */
> -        put_gfn(current->domain, vmcbaddr >> PAGE_SHIFT);
>      }
>  
>      return 1;
> @@ -336,6 +334,7 @@ static int nsvm_vmrun_permissionmap(stru
>      unsigned int i;
>      enum hvm_copy_result ret;
>      unsigned long *ns_viomap;
> +    struct page_info *ns_viomap_pg = NULL;
>      bool_t ioport_80, ioport_ed;
>  
>      ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm;
> @@ -353,12 +352,12 @@ static int nsvm_vmrun_permissionmap(stru
>      svm->ns_oiomap_pa = svm->ns_iomap_pa;
>      svm->ns_iomap_pa = ns_vmcb->_iopm_base_pa;
>  
> -    ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT);
> +    ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT,
> +                                        &ns_viomap_pg);
>      ASSERT(ns_viomap != NULL);
>      ioport_80 = test_bit(0x80, ns_viomap);
>      ioport_ed = test_bit(0xed, ns_viomap);
> -    hvm_unmap_guest_frame(ns_viomap);
> -    put_gfn(current->domain, svm->ns_iomap_pa >> PAGE_SHIFT);
> +    hvm_unmap_guest_frame(ns_viomap, ns_viomap_pg);
>  
>      svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
>  
> @@ -863,6 +862,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
>      uint16_t port;
>      bool_t enabled;
>      unsigned long gfn = 0; /* gcc ... */
> +    struct page_info *io_bitmap_pg = NULL;
>  
>      ioinfo.bytes = exitinfo1;
>      port = ioinfo.fields.port;
> @@ -880,7 +880,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
>          break;
>      }
>  
> -    io_bitmap = hvm_map_guest_frame_ro(gfn);
> +    io_bitmap = hvm_map_guest_frame_ro(gfn, &io_bitmap_pg);
>      if (io_bitmap == NULL) {
>          gdprintk(XENLOG_ERR,
>              "IOIO intercept: mapping of permission map failed\n");
> @@ -888,8 +888,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
>      }
>  
>      enabled = test_bit(port, io_bitmap);
> -    hvm_unmap_guest_frame(io_bitmap);
> -    put_gfn(current->domain, gfn);
> +    hvm_unmap_guest_frame(io_bitmap, io_bitmap_pg);
>  
>      if (!enabled)
>          return NESTEDHVM_VMEXIT_HOST;
> diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/vmx/vvmx.c
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -44,10 +44,13 @@ int nvmx_vcpu_initialise(struct vcpu *v)
>      nvmx->vmxon_region_pa = 0;
>      nvcpu->nv_vvmcx = NULL;
>      nvcpu->nv_vvmcxaddr = VMCX_EADDR;
> +    nvcpu->nv_vvmcx_pg = NULL;
>      nvmx->intr.intr_info = 0;
>      nvmx->intr.error_code = 0;
>      nvmx->iobitmap[0] = NULL;
>      nvmx->iobitmap[1] = NULL;
> +    nvmx->iobitmap_pg[0] = NULL;
> +    nvmx->iobitmap_pg[1] = NULL;
>      return 0;
>  out:
>      return -ENOMEM;
> @@ -558,12 +561,14 @@ static void __map_io_bitmap(struct vcpu 
>  
>      index = vmcs_reg == IO_BITMAP_A ? 0 : 1;
>      if (nvmx->iobitmap[index])
> -        hvm_unmap_guest_frame (nvmx->iobitmap[index]); 
> +    {
> +        hvm_unmap_guest_frame (nvmx->iobitmap[index],
> +                               nvmx->iobitmap_pg[index]); 
> +        nvmx->iobitmap_pg[index] = NULL;
> +    }
>      gpa = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, vmcs_reg);
> -    nvmx->iobitmap[index] = hvm_map_guest_frame_ro (gpa >> PAGE_SHIFT);
> -    /* See comment in nestedsvm_vmcb_map re putting this gfn and 
> -     * liveness of the map it backs */
> -    put_gfn(current->domain, gpa >> PAGE_SHIFT);
> +    nvmx->iobitmap[index] = hvm_map_guest_frame_ro(gpa >> PAGE_SHIFT,
> +                                             &nvmx->iobitmap_pg[index]);
>  }
>  
>  static inline void map_io_bitmap_all(struct vcpu *v)
> @@ -580,13 +585,16 @@ static void nvmx_purge_vvmcs(struct vcpu
>  
>      __clear_current_vvmcs(v);
>      if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
> -        hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
> -    nvcpu->nv_vvmcx == NULL;
> +        hvm_unmap_guest_frame(nvcpu->nv_vvmcx, nvcpu->nv_vvmcx_pg);
> +    nvcpu->nv_vvmcx = NULL;
>      nvcpu->nv_vvmcxaddr = VMCX_EADDR;
> +    nvcpu->nv_vvmcx_pg = NULL;
>      for (i=0; i<2; i++) {
>          if ( nvmx->iobitmap[i] ) {
> -            hvm_unmap_guest_frame(nvmx->iobitmap[i]); 
> +            hvm_unmap_guest_frame(nvmx->iobitmap[i], 
> +                                  nvmx->iobitmap_pg[i]); 
>              nvmx->iobitmap[i] = NULL;
> +            nvmx->iobitmap_pg[i] = NULL;
>          }
>      }
>  }
> @@ -1138,12 +1146,10 @@ int nvmx_handle_vmptrld(struct cpu_user_
>  
>      if ( nvcpu->nv_vvmcxaddr == VMCX_EADDR )
>      {
> -        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw (gpa >> PAGE_SHIFT);
> +        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT,
> +                                                 &nvcpu->nv_vvmcx_pg);
>          nvcpu->nv_vvmcxaddr = gpa;
>          map_io_bitmap_all (v);
> -        /* See comment in nestedsvm_vmcb_map regarding putting this 
> -         * gfn and liveness of the map that uses it */
> -        put_gfn(current->domain, gpa >> PAGE_SHIFT);
>      }
>  
>      vmreturn(regs, VMSUCCEED);
> @@ -1201,11 +1207,11 @@ int nvmx_handle_vmclear(struct cpu_user_
>      else 
>      {
>          /* Even if this VMCS isn't the current one, we must clear it. */
> -        vvmcs = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT);
> +        struct page_info *vvmcs_pg = NULL;
> +        vvmcs = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT, &vvmcs_pg);
>          if ( vvmcs ) 
>              __set_vvmcs(vvmcs, NVMX_LAUNCH_STATE, 0);
> -        hvm_unmap_guest_frame(vvmcs);
> -        put_gfn(current->domain, gpa >> PAGE_SHIFT);
> +        hvm_unmap_guest_frame(vvmcs, vvmcs_pg);
>      }
>  
>      vmreturn(regs, VMSUCCEED);
> diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/hvm.h
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -26,6 +26,7 @@
>  #include <asm/hvm/asid.h>
>  #include <public/domctl.h>
>  #include <public/hvm/save.h>
> +#include <asm/mm.h>
>  
>  /* Interrupt acknowledgement sources. */
>  enum hvm_intsrc {
> @@ -392,9 +393,11 @@ int hvm_virtual_to_linear_addr(
>      unsigned int addr_size,
>      unsigned long *linear_addr);
>  
> -void *hvm_map_guest_frame_rw(unsigned long gfn);
> -void *hvm_map_guest_frame_ro(unsigned long gfn);
> -void hvm_unmap_guest_frame(void *p);
> +void *hvm_map_guest_frame_rw(unsigned long gfn,
> +                             struct page_info **page);
> +void *hvm_map_guest_frame_ro(unsigned long gfn,
> +                             struct page_info **page);
> +void hvm_unmap_guest_frame(void *p, struct page_info *page);
>  
>  static inline void hvm_set_info_guest(struct vcpu *v)
>  {
> diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/vcpu.h
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -77,6 +77,7 @@ struct nestedvcpu {
>      void *nv_n2vmcx; /* shadow VMCB/VMCS used to run l2 guest */
>  
>      uint64_t nv_vvmcxaddr; /* l1 guest physical address of nv_vvmcx */
> +    struct page_info *nv_vvmcx_pg; /* page where nv_vvmcx resides */
>      uint64_t nv_n1vmcx_pa; /* host physical address of nv_n1vmcx */
>      uint64_t nv_n2vmcx_pa; /* host physical address of nv_n2vmcx */
>  
> diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/vmx/vvmx.h
> --- a/xen/include/asm-x86/hvm/vmx/vvmx.h
> +++ b/xen/include/asm-x86/hvm/vmx/vvmx.h
> @@ -26,6 +26,7 @@
>  struct nestedvmx {
>      paddr_t    vmxon_region_pa;
>      void       *iobitmap[2];		/* map (va) of L1 guest I/O bitmap */
> +    struct page_info *iobitmap_pg[2]; /* pages backing L1 guest I/O bitmap */
>      /* deferred nested interrupt */
>      struct {
>          unsigned long intr_info;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:48:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:48:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcTW-0006IM-2f; Thu, 24 Nov 2011 16:48:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTcTV-0006IG-7Y
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:48:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322153258!49817622!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16272 invoked from network); 24 Nov 2011 16:47:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 16:47:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTcSz-000LXp-EP; Thu, 24 Nov 2011 16:48:05 +0000
Date: Thu, 24 Nov 2011 16:48:05 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124164805.GN77868@ocelot.phlegethon.org>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
	<f079cbeae77e5570c193.1322142091@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f079cbeae77e5570c193.1322142091@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] Ensure maps used by nested hvm code
	cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


This is a bit messy still.  On 64-bit Xen we could just use
virt_to_page() on the map pointers rather than storing their 
page_info pointers separately. 

On 32-bit, maybe we could use the existing linear mappings to look up
the MFN instead.  Or would it be easier to add a function to eth
map_domain_page() family that does va->mfn for mapped frames?
Keir, any opinion?

Tim.

At 08:41 -0500 on 24 Nov (1322124091), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/hvm.c             |  69 ++++++++++++++++++++++++-------------
>  xen/arch/x86/hvm/nestedhvm.c       |   4 +-
>  xen/arch/x86/hvm/svm/nestedsvm.c   |  23 ++++++------
>  xen/arch/x86/hvm/vmx/vvmx.c        |  36 +++++++++++--------
>  xen/include/asm-x86/hvm/hvm.h      |   9 +++-
>  xen/include/asm-x86/hvm/vcpu.h     |   1 +
>  xen/include/asm-x86/hvm/vmx/vvmx.h |   1 +
>  7 files changed, 88 insertions(+), 55 deletions(-)
> 
> 
> The nested hvm code maps pages of the guest hvm. These maps live beyond
> a hypervisor entry/exit pair, and thus their liveness cannot be ensured
> with get_gfn/put_gfn critical sections. Ensure their liveness by
> increasing the page ref count, instead.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1801,11 +1801,15 @@ int hvm_virtual_to_linear_addr(
>      return 0;
>  }
>  
> -/* We leave this function holding a lock on the p2m entry */
> -static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
> +/* On non-NULL return, we leave this function holding an additional 
> + * ref on the underlying mfn, if any */
> +static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable,
> +                                    struct page_info **page)
>  {
> +    void *map;
>      unsigned long mfn;
>      p2m_type_t p2mt;
> +    struct page_info *pg;
>      struct domain *d = current->domain;
>  
>      mfn = mfn_x(writable
> @@ -1828,27 +1832,43 @@ static void *__hvm_map_guest_frame(unsig
>      if ( writable )
>          paging_mark_dirty(d, mfn);
>  
> -    return map_domain_page(mfn);
> +    pg = mfn_to_page(mfn);
> +    if (page)
> +    {
> +        page_get_owner_and_reference(pg);
> +        *page = pg;
> +    }
> +
> +    map = map_domain_page(mfn);
> +    put_gfn(d, gfn);
> +    return map;
>  }
>  
> -void *hvm_map_guest_frame_rw(unsigned long gfn)
> +void *hvm_map_guest_frame_rw(unsigned long gfn,
> +                             struct page_info **page)
>  {
> -    return __hvm_map_guest_frame(gfn, 1);
> +    return __hvm_map_guest_frame(gfn, 1, page);
>  }
>  
> -void *hvm_map_guest_frame_ro(unsigned long gfn)
> +void *hvm_map_guest_frame_ro(unsigned long gfn,
> +                             struct page_info **page)
>  {
> -    return __hvm_map_guest_frame(gfn, 0);
> +    return __hvm_map_guest_frame(gfn, 0, page);
>  }
>  
> -void hvm_unmap_guest_frame(void *p)
> +void hvm_unmap_guest_frame(void *p, struct page_info *page)
>  {
>      if ( p )
> +    {
>          unmap_domain_page(p);
> +        if ( page )
> +            put_page(page);
> +    }
>  }
>  
> -static void *hvm_map_entry(unsigned long va, unsigned long *gfn)
> +static void *hvm_map_entry(unsigned long va, struct page_info **page)
>  {
> +    unsigned long gfn;
>      uint32_t pfec;
>      char *v;
>  
> @@ -1865,11 +1885,11 @@ static void *hvm_map_entry(unsigned long
>       * treat it as a kernel-mode read (i.e. no access checks).
>       */
>      pfec = PFEC_page_present;
> -    *gfn = paging_gva_to_gfn(current, va, &pfec);
> +    gfn = paging_gva_to_gfn(current, va, &pfec);
>      if ( (pfec == PFEC_page_paged) || (pfec == PFEC_page_shared) )
>          goto fail;
>  
> -    v = hvm_map_guest_frame_rw(*gfn);
> +    v = hvm_map_guest_frame_rw(gfn, page);
>      if ( v == NULL )
>          goto fail;
>  
> @@ -1880,11 +1900,9 @@ static void *hvm_map_entry(unsigned long
>      return NULL;
>  }
>  
> -static void hvm_unmap_entry(void *p, unsigned long gfn)
> +static void hvm_unmap_entry(void *p, struct page_info *page)
>  {
> -    hvm_unmap_guest_frame(p);
> -    if ( p && (gfn != INVALID_GFN) )
> -        put_gfn(current->domain, gfn);
> +    hvm_unmap_guest_frame(p, page);
>  }
>  
>  static int hvm_load_segment_selector(
> @@ -1896,7 +1914,7 @@ static int hvm_load_segment_selector(
>      int fault_type = TRAP_invalid_tss;
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
>      struct vcpu *v = current;
> -    unsigned long pdesc_gfn = INVALID_GFN;
> +    struct page_info *pdesc_pg = NULL;
>  
>      if ( regs->eflags & X86_EFLAGS_VM )
>      {
> @@ -1930,7 +1948,7 @@ static int hvm_load_segment_selector(
>      if ( ((sel & 0xfff8) + 7) > desctab.limit )
>          goto fail;
>  
> -    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_gfn);
> +    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_pg);
>      if ( pdesc == NULL )
>          goto hvm_map_fail;
>  
> @@ -1990,7 +2008,7 @@ static int hvm_load_segment_selector(
>      desc.b |= 0x100;
>  
>   skip_accessed_flag:
> -    hvm_unmap_entry(pdesc, pdesc_gfn);
> +    hvm_unmap_entry(pdesc, pdesc_pg);
>  
>      segr.base = (((desc.b <<  0) & 0xff000000u) |
>                   ((desc.b << 16) & 0x00ff0000u) |
> @@ -2006,7 +2024,7 @@ static int hvm_load_segment_selector(
>      return 0;
>  
>   unmap_and_fail:
> -    hvm_unmap_entry(pdesc, pdesc_gfn);
> +    hvm_unmap_entry(pdesc, pdesc_pg);
>   fail:
>      hvm_inject_exception(fault_type, sel & 0xfffc, 0);
>   hvm_map_fail:
> @@ -2021,7 +2039,8 @@ void hvm_task_switch(
>      struct cpu_user_regs *regs = guest_cpu_user_regs();
>      struct segment_register gdt, tr, prev_tr, segr;
>      struct desc_struct *optss_desc = NULL, *nptss_desc = NULL, tss_desc;
> -    unsigned long eflags, optss_gfn = INVALID_GFN, nptss_gfn = INVALID_GFN;
> +    unsigned long eflags;
> +    struct page_info *optss_pg = NULL, *nptss_pg = NULL;
>      int exn_raised, rc;
>      struct {
>          u16 back_link,__blh;
> @@ -2047,11 +2066,13 @@ void hvm_task_switch(
>          goto out;
>      }
>  
> -    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), &optss_gfn);
> +    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), 
> +                                &optss_pg);
>      if ( optss_desc == NULL )
>          goto out;
>  
> -    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), &nptss_gfn);
> +    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), 
> +                                &nptss_pg);
>      if ( nptss_desc == NULL )
>          goto out;
>  
> @@ -2216,8 +2237,8 @@ void hvm_task_switch(
>      }
>  
>   out:
> -    hvm_unmap_entry(optss_desc, optss_gfn);
> -    hvm_unmap_entry(nptss_desc, nptss_gfn);
> +    hvm_unmap_entry(optss_desc, optss_pg);
> +    hvm_unmap_entry(nptss_desc, nptss_pg);
>  }
>  
>  #define HVMCOPY_from_guest (0u<<0)
> diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/nestedhvm.c
> --- a/xen/arch/x86/hvm/nestedhvm.c
> +++ b/xen/arch/x86/hvm/nestedhvm.c
> @@ -56,9 +56,11 @@ nestedhvm_vcpu_reset(struct vcpu *v)
>      nv->nv_ioportED = 0;
>  
>      if (nv->nv_vvmcx)
> -        hvm_unmap_guest_frame(nv->nv_vvmcx);
> +        hvm_unmap_guest_frame(nv->nv_vvmcx, 
> +                              nv->nv_vvmcx_pg);
>      nv->nv_vvmcx = NULL;
>      nv->nv_vvmcxaddr = VMCX_EADDR;
> +    nv->nv_vvmcx_pg  = NULL;
>      nv->nv_flushp2m = 0;
>      nv->nv_p2m = NULL;
>  
> diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/svm/nestedsvm.c
> --- a/xen/arch/x86/hvm/svm/nestedsvm.c
> +++ b/xen/arch/x86/hvm/svm/nestedsvm.c
> @@ -71,20 +71,18 @@ int nestedsvm_vmcb_map(struct vcpu *v, u
>      if (nv->nv_vvmcx != NULL && nv->nv_vvmcxaddr != vmcbaddr) {
>          ASSERT(nv->nv_vvmcx != NULL);
>          ASSERT(nv->nv_vvmcxaddr != VMCX_EADDR);
> -        hvm_unmap_guest_frame(nv->nv_vvmcx);
> +        hvm_unmap_guest_frame(nv->nv_vvmcx, nv->nv_vvmcx_pg);
>          nv->nv_vvmcx = NULL;
>          nv->nv_vvmcxaddr = VMCX_EADDR;
> +        nv->nv_vvmcx_pg = NULL;
>      }
>  
>      if (nv->nv_vvmcx == NULL) {
> -        nv->nv_vvmcx = hvm_map_guest_frame_rw(vmcbaddr >> PAGE_SHIFT);
> +        nv->nv_vvmcx = hvm_map_guest_frame_rw(vmcbaddr >> PAGE_SHIFT,
> +                                                &nv->nv_vvmcx_pg);
>          if (nv->nv_vvmcx == NULL)
>              return 0;
>          nv->nv_vvmcxaddr = vmcbaddr;
> -        /* put_gfn here even though the map survives beyond this caller.
> -         * The map can likely survive beyond a hypervisor exit, thus we
> -         * need to put the gfn */
> -        put_gfn(current->domain, vmcbaddr >> PAGE_SHIFT);
>      }
>  
>      return 1;
> @@ -336,6 +334,7 @@ static int nsvm_vmrun_permissionmap(stru
>      unsigned int i;
>      enum hvm_copy_result ret;
>      unsigned long *ns_viomap;
> +    struct page_info *ns_viomap_pg = NULL;
>      bool_t ioport_80, ioport_ed;
>  
>      ns_msrpm_ptr = (unsigned long *)svm->ns_cached_msrpm;
> @@ -353,12 +352,12 @@ static int nsvm_vmrun_permissionmap(stru
>      svm->ns_oiomap_pa = svm->ns_iomap_pa;
>      svm->ns_iomap_pa = ns_vmcb->_iopm_base_pa;
>  
> -    ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT);
> +    ns_viomap = hvm_map_guest_frame_ro(svm->ns_iomap_pa >> PAGE_SHIFT,
> +                                        &ns_viomap_pg);
>      ASSERT(ns_viomap != NULL);
>      ioport_80 = test_bit(0x80, ns_viomap);
>      ioport_ed = test_bit(0xed, ns_viomap);
> -    hvm_unmap_guest_frame(ns_viomap);
> -    put_gfn(current->domain, svm->ns_iomap_pa >> PAGE_SHIFT);
> +    hvm_unmap_guest_frame(ns_viomap, ns_viomap_pg);
>  
>      svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
>  
> @@ -863,6 +862,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
>      uint16_t port;
>      bool_t enabled;
>      unsigned long gfn = 0; /* gcc ... */
> +    struct page_info *io_bitmap_pg = NULL;
>  
>      ioinfo.bytes = exitinfo1;
>      port = ioinfo.fields.port;
> @@ -880,7 +880,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
>          break;
>      }
>  
> -    io_bitmap = hvm_map_guest_frame_ro(gfn);
> +    io_bitmap = hvm_map_guest_frame_ro(gfn, &io_bitmap_pg);
>      if (io_bitmap == NULL) {
>          gdprintk(XENLOG_ERR,
>              "IOIO intercept: mapping of permission map failed\n");
> @@ -888,8 +888,7 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
>      }
>  
>      enabled = test_bit(port, io_bitmap);
> -    hvm_unmap_guest_frame(io_bitmap);
> -    put_gfn(current->domain, gfn);
> +    hvm_unmap_guest_frame(io_bitmap, io_bitmap_pg);
>  
>      if (!enabled)
>          return NESTEDHVM_VMEXIT_HOST;
> diff -r a64f63ecfc57 -r f079cbeae77e xen/arch/x86/hvm/vmx/vvmx.c
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -44,10 +44,13 @@ int nvmx_vcpu_initialise(struct vcpu *v)
>      nvmx->vmxon_region_pa = 0;
>      nvcpu->nv_vvmcx = NULL;
>      nvcpu->nv_vvmcxaddr = VMCX_EADDR;
> +    nvcpu->nv_vvmcx_pg = NULL;
>      nvmx->intr.intr_info = 0;
>      nvmx->intr.error_code = 0;
>      nvmx->iobitmap[0] = NULL;
>      nvmx->iobitmap[1] = NULL;
> +    nvmx->iobitmap_pg[0] = NULL;
> +    nvmx->iobitmap_pg[1] = NULL;
>      return 0;
>  out:
>      return -ENOMEM;
> @@ -558,12 +561,14 @@ static void __map_io_bitmap(struct vcpu 
>  
>      index = vmcs_reg == IO_BITMAP_A ? 0 : 1;
>      if (nvmx->iobitmap[index])
> -        hvm_unmap_guest_frame (nvmx->iobitmap[index]); 
> +    {
> +        hvm_unmap_guest_frame (nvmx->iobitmap[index],
> +                               nvmx->iobitmap_pg[index]); 
> +        nvmx->iobitmap_pg[index] = NULL;
> +    }
>      gpa = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, vmcs_reg);
> -    nvmx->iobitmap[index] = hvm_map_guest_frame_ro (gpa >> PAGE_SHIFT);
> -    /* See comment in nestedsvm_vmcb_map re putting this gfn and 
> -     * liveness of the map it backs */
> -    put_gfn(current->domain, gpa >> PAGE_SHIFT);
> +    nvmx->iobitmap[index] = hvm_map_guest_frame_ro(gpa >> PAGE_SHIFT,
> +                                             &nvmx->iobitmap_pg[index]);
>  }
>  
>  static inline void map_io_bitmap_all(struct vcpu *v)
> @@ -580,13 +585,16 @@ static void nvmx_purge_vvmcs(struct vcpu
>  
>      __clear_current_vvmcs(v);
>      if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
> -        hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
> -    nvcpu->nv_vvmcx == NULL;
> +        hvm_unmap_guest_frame(nvcpu->nv_vvmcx, nvcpu->nv_vvmcx_pg);
> +    nvcpu->nv_vvmcx = NULL;
>      nvcpu->nv_vvmcxaddr = VMCX_EADDR;
> +    nvcpu->nv_vvmcx_pg = NULL;
>      for (i=0; i<2; i++) {
>          if ( nvmx->iobitmap[i] ) {
> -            hvm_unmap_guest_frame(nvmx->iobitmap[i]); 
> +            hvm_unmap_guest_frame(nvmx->iobitmap[i], 
> +                                  nvmx->iobitmap_pg[i]); 
>              nvmx->iobitmap[i] = NULL;
> +            nvmx->iobitmap_pg[i] = NULL;
>          }
>      }
>  }
> @@ -1138,12 +1146,10 @@ int nvmx_handle_vmptrld(struct cpu_user_
>  
>      if ( nvcpu->nv_vvmcxaddr == VMCX_EADDR )
>      {
> -        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw (gpa >> PAGE_SHIFT);
> +        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT,
> +                                                 &nvcpu->nv_vvmcx_pg);
>          nvcpu->nv_vvmcxaddr = gpa;
>          map_io_bitmap_all (v);
> -        /* See comment in nestedsvm_vmcb_map regarding putting this 
> -         * gfn and liveness of the map that uses it */
> -        put_gfn(current->domain, gpa >> PAGE_SHIFT);
>      }
>  
>      vmreturn(regs, VMSUCCEED);
> @@ -1201,11 +1207,11 @@ int nvmx_handle_vmclear(struct cpu_user_
>      else 
>      {
>          /* Even if this VMCS isn't the current one, we must clear it. */
> -        vvmcs = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT);
> +        struct page_info *vvmcs_pg = NULL;
> +        vvmcs = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT, &vvmcs_pg);
>          if ( vvmcs ) 
>              __set_vvmcs(vvmcs, NVMX_LAUNCH_STATE, 0);
> -        hvm_unmap_guest_frame(vvmcs);
> -        put_gfn(current->domain, gpa >> PAGE_SHIFT);
> +        hvm_unmap_guest_frame(vvmcs, vvmcs_pg);
>      }
>  
>      vmreturn(regs, VMSUCCEED);
> diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/hvm.h
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -26,6 +26,7 @@
>  #include <asm/hvm/asid.h>
>  #include <public/domctl.h>
>  #include <public/hvm/save.h>
> +#include <asm/mm.h>
>  
>  /* Interrupt acknowledgement sources. */
>  enum hvm_intsrc {
> @@ -392,9 +393,11 @@ int hvm_virtual_to_linear_addr(
>      unsigned int addr_size,
>      unsigned long *linear_addr);
>  
> -void *hvm_map_guest_frame_rw(unsigned long gfn);
> -void *hvm_map_guest_frame_ro(unsigned long gfn);
> -void hvm_unmap_guest_frame(void *p);
> +void *hvm_map_guest_frame_rw(unsigned long gfn,
> +                             struct page_info **page);
> +void *hvm_map_guest_frame_ro(unsigned long gfn,
> +                             struct page_info **page);
> +void hvm_unmap_guest_frame(void *p, struct page_info *page);
>  
>  static inline void hvm_set_info_guest(struct vcpu *v)
>  {
> diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/vcpu.h
> --- a/xen/include/asm-x86/hvm/vcpu.h
> +++ b/xen/include/asm-x86/hvm/vcpu.h
> @@ -77,6 +77,7 @@ struct nestedvcpu {
>      void *nv_n2vmcx; /* shadow VMCB/VMCS used to run l2 guest */
>  
>      uint64_t nv_vvmcxaddr; /* l1 guest physical address of nv_vvmcx */
> +    struct page_info *nv_vvmcx_pg; /* page where nv_vvmcx resides */
>      uint64_t nv_n1vmcx_pa; /* host physical address of nv_n1vmcx */
>      uint64_t nv_n2vmcx_pa; /* host physical address of nv_n2vmcx */
>  
> diff -r a64f63ecfc57 -r f079cbeae77e xen/include/asm-x86/hvm/vmx/vvmx.h
> --- a/xen/include/asm-x86/hvm/vmx/vvmx.h
> +++ b/xen/include/asm-x86/hvm/vmx/vvmx.h
> @@ -26,6 +26,7 @@
>  struct nestedvmx {
>      paddr_t    vmxon_region_pa;
>      void       *iobitmap[2];		/* map (va) of L1 guest I/O bitmap */
> +    struct page_info *iobitmap_pg[2]; /* pages backing L1 guest I/O bitmap */
>      /* deferred nested interrupt */
>      struct {
>          unsigned long intr_info;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:49:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:49:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcUY-0006MW-OA; Thu, 24 Nov 2011 16:49:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTcUX-0006M9-Cg
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:49:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322153350!2902520!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9275 invoked from network); 24 Nov 2011 16:49:10 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:49:10 -0000
Received: by fagn18 with SMTP id n18so7574fag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 08:49:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=OyIM5LxEzmPhU+xnKIdsH/4zUhNm1CNluBkDLntTZY0=;
	b=lvfjyjO22Mkkhf1eGcX3tRGtyipHm05ABp+4O/OAA7StHuHEiw2Edd4D9UKZaPYZp5
	+VbVqdvxRu+0+oJXwgJ2rGBhWSaDL8uxRna58bRTzQalKyxyTHbdI5vCFAyCWHo6tVHu
	YEV4QVDyeqs0exutr1oB5AZ6gQitH524LofYI=
Received: by 10.204.7.133 with SMTP id d5mr30537838bkd.64.1322153349492;
	Thu, 24 Nov 2011 08:49:09 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id f14sm16318861bkv.3.2011.11.24.08.49.08
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 08:49:08 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 16:49:06 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAF42602.34C81%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: small fixes to pcpu platform op handling
Thread-Index: AcyqyPqDhA9LybrKLk+GG1BB4mlYow==
In-Reply-To: <4ECE7E7602000078000630E6@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: small fixes to pcpu platform op
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 16:27, "Jan Beulich" <JBeulich@suse.com> wrote:

> XENPF_get_cpuinfo should init the flags output field rather than only
> modify it.
> 
> XENPF_cpu_online must check for the input CPU number to be in range.
> 
> XENPF_cpu_offline must also do that, and should also reject attempts to
> offline CPU 0 (this fails in cpu_down() too, but preventing this here
> appears more correct given that the code here calls
> continue_hypercall_on_cpu(0, ...), which would be flawed if cpu_down()
> would ever allow bringing down CPU 0 (and a distinct error code is
> easier to deal with when debugging issues).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -449,13 +449,14 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>          if ( (g_info->xen_cpuid >= nr_cpu_ids) ||
>               !cpu_present(g_info->xen_cpuid) )
>          {
> -            g_info->flags |= XEN_PCPU_FLAGS_INVALID;
> +            g_info->flags = XEN_PCPU_FLAGS_INVALID;
>          }
>          else
>          {
>              g_info->apic_id = x86_cpu_to_apicid[g_info->xen_cpuid];
>              g_info->acpi_id = acpi_get_processor_id(g_info->xen_cpuid);
>              ASSERT(g_info->apic_id != BAD_APICID);
> +            g_info->flags = 0;
>              if (cpu_online(g_info->xen_cpuid))
>                  g_info->flags |= XEN_PCPU_FLAGS_ONLINE;
>          }
> @@ -472,7 +473,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>      {
>          int cpu = op->u.cpu_ol.cpuid;
>  
> -        if ( !cpu_present(cpu) )
> +        if ( cpu >= nr_cpu_ids || !cpu_present(cpu) )
>          {
>              ret = -EINVAL;
>              break;
> @@ -493,7 +494,13 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>      {
>          int cpu = op->u.cpu_ol.cpuid;
>  
> -        if ( !cpu_present(cpu) )
> +        if ( cpu == 0 )
> +        {
> +            ret = -EOPNOTSUPP;
> +            break;
> +        }
> +
> +        if ( cpu >= nr_cpu_ids || !cpu_present(cpu) )
>          {
>              ret = -EINVAL;
>              break;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:49:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:49:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcUY-0006MW-OA; Thu, 24 Nov 2011 16:49:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTcUX-0006M9-Cg
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:49:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322153350!2902520!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9275 invoked from network); 24 Nov 2011 16:49:10 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:49:10 -0000
Received: by fagn18 with SMTP id n18so7574fag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 08:49:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=OyIM5LxEzmPhU+xnKIdsH/4zUhNm1CNluBkDLntTZY0=;
	b=lvfjyjO22Mkkhf1eGcX3tRGtyipHm05ABp+4O/OAA7StHuHEiw2Edd4D9UKZaPYZp5
	+VbVqdvxRu+0+oJXwgJ2rGBhWSaDL8uxRna58bRTzQalKyxyTHbdI5vCFAyCWHo6tVHu
	YEV4QVDyeqs0exutr1oB5AZ6gQitH524LofYI=
Received: by 10.204.7.133 with SMTP id d5mr30537838bkd.64.1322153349492;
	Thu, 24 Nov 2011 08:49:09 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id f14sm16318861bkv.3.2011.11.24.08.49.08
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 08:49:08 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 16:49:06 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAF42602.34C81%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: small fixes to pcpu platform op handling
Thread-Index: AcyqyPqDhA9LybrKLk+GG1BB4mlYow==
In-Reply-To: <4ECE7E7602000078000630E6@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: small fixes to pcpu platform op
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 16:27, "Jan Beulich" <JBeulich@suse.com> wrote:

> XENPF_get_cpuinfo should init the flags output field rather than only
> modify it.
> 
> XENPF_cpu_online must check for the input CPU number to be in range.
> 
> XENPF_cpu_offline must also do that, and should also reject attempts to
> offline CPU 0 (this fails in cpu_down() too, but preventing this here
> appears more correct given that the code here calls
> continue_hypercall_on_cpu(0, ...), which would be flawed if cpu_down()
> would ever allow bringing down CPU 0 (and a distinct error code is
> easier to deal with when debugging issues).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -449,13 +449,14 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>          if ( (g_info->xen_cpuid >= nr_cpu_ids) ||
>               !cpu_present(g_info->xen_cpuid) )
>          {
> -            g_info->flags |= XEN_PCPU_FLAGS_INVALID;
> +            g_info->flags = XEN_PCPU_FLAGS_INVALID;
>          }
>          else
>          {
>              g_info->apic_id = x86_cpu_to_apicid[g_info->xen_cpuid];
>              g_info->acpi_id = acpi_get_processor_id(g_info->xen_cpuid);
>              ASSERT(g_info->apic_id != BAD_APICID);
> +            g_info->flags = 0;
>              if (cpu_online(g_info->xen_cpuid))
>                  g_info->flags |= XEN_PCPU_FLAGS_ONLINE;
>          }
> @@ -472,7 +473,7 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>      {
>          int cpu = op->u.cpu_ol.cpuid;
>  
> -        if ( !cpu_present(cpu) )
> +        if ( cpu >= nr_cpu_ids || !cpu_present(cpu) )
>          {
>              ret = -EINVAL;
>              break;
> @@ -493,7 +494,13 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>      {
>          int cpu = op->u.cpu_ol.cpuid;
>  
> -        if ( !cpu_present(cpu) )
> +        if ( cpu == 0 )
> +        {
> +            ret = -EOPNOTSUPP;
> +            break;
> +        }
> +
> +        if ( cpu >= nr_cpu_ids || !cpu_present(cpu) )
>          {
>              ret = -EINVAL;
>              break;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:52:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcXC-0006YW-C2; Thu, 24 Nov 2011 16:52:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcXA-0006Y6-Mp
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:52:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322153513!5627823!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30545 invoked from network); 24 Nov 2011 16:51:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:51:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:51:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 16:51:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcWH-0006ut-Im; Thu, 24 Nov 2011 16:51:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcWH-0004TD-I1;
	Thu, 24 Nov 2011 16:51:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.30225.546593.786234@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 16:51:29 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322152518.1005.189.camel@zakaz.uk.xensource.com>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [xen-unstable test] 10020: regressions - FAIL"):
> I think you need to install libaio-dev.

Yes, thanks.  I have submitted that to the auto-tester which (when it
passes the meta-auto-test) ought to fix it.

IWBNI we had a sort-of-machine-readable list of Debian packages to
install in some README; then I could use that.  It wouldn't break
every time we add a dependency and also would make sure the build docs
remain up to date.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:52:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcXC-0006YW-C2; Thu, 24 Nov 2011 16:52:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcXA-0006Y6-Mp
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:52:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322153513!5627823!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30545 invoked from network); 24 Nov 2011 16:51:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:51:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:51:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 16:51:29 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcWH-0006ut-Im; Thu, 24 Nov 2011 16:51:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcWH-0004TD-I1;
	Thu, 24 Nov 2011 16:51:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.30225.546593.786234@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 16:51:29 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322152518.1005.189.camel@zakaz.uk.xensource.com>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [xen-unstable test] 10020: regressions - FAIL"):
> I think you need to install libaio-dev.

Yes, thanks.  I have submitted that to the auto-tester which (when it
passes the meta-auto-test) ought to fix it.

IWBNI we had a sort-of-machine-readable list of Debian packages to
install in some README; then I could use that.  It wouldn't break
every time we add a dependency and also would make sure the build docs
remain up to date.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:56:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcab-0006oH-0Q; Thu, 24 Nov 2011 16:55:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcaZ-0006oC-Sq
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:55:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322153724!4485154!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20743 invoked from network); 24 Nov 2011 16:55:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:55:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117980"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:55:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 16:55:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTca3-0006wa-PF; Thu, 24 Nov 2011 16:55:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTca3-0004Tn-Oc;
	Thu, 24 Nov 2011 16:55:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.30459.750301.824392@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 16:55:23 +0000
To: Vladimir =?utf-8?Q?'=CF=86-coder/phcoder'?= Serbinenko <phcoder@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <m2n.s.1RR00M-272707@chiark.greenend.org.uk>
References: <4EC45B57.80602@gmail.com>
	<20111117005949.GR4275@type.famille.thibault.fr>
	<m2n.s.1RR00M-272707@chiark.greenend.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xensource.com,
	The development of GRUB 2 <grub-devel@gnu.org>
Subject: [Xen-devel]  Re: [Grub2] Xen branches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28gd3JpdGVzICgiW1hlbi1kZXZl
bF0gUmU6IFtHcnViMl0gWGVuIGJyYW5jaGVzIik6Cj4gT24gMTcuMTEuMjAxMSAwMTo1OSwgU2Ft
dWVsIFRoaWJhdWx0IHdyb3RlOgo+ID4gSXQgY2FuIGJlIHVzZWZ1bCB0byBqdXN0IHJlLXVzZSB0
aGUgZHJpdmVycyBmcm9tIE1pbmktT1MsIGJ1dCB5b3UgbWF5Cj4gPiB3YW50IHRvIHJlaW1wbGVt
ZW50IHRoZW0uCj4gCj4gVGhleSBkb24ndCBzZWVtIHRvIGJlIGRpZmZpY3VsdCB0byBpbXBsZW1l
bnQganVkZ2luZyBmcm9tIHRoZSBzcGVjLiBPbgo+IHRoZSBvdGhlciBoYW5kIG1ha2luZyBNaW5p
T1MgYnVpbGRpbmcgc3lzdGVtIHdvcmsgbmljZWx5IHdpdGggb3Vycwo+IHNvdW5kcyBsaWtlIGhl
bGwuCgpZZXMuICBJIHdvdWxkIGF2b2lkIHRoZSBtaW5pb3MgYnVpbGQgc3lzdGVtOyBpdCdzIGF3
ZnVsLiAgRmVlbCBmcmVlIHRvCmxpZnQgYW55IGNvZGUgdGhhdCBsb29rcyB1c2VmdWwgdGhvdWdo
LgoKSWFuLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:56:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:56:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcab-0006oH-0Q; Thu, 24 Nov 2011 16:55:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcaZ-0006oC-Sq
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:55:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322153724!4485154!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20743 invoked from network); 24 Nov 2011 16:55:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 16:55:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9117980"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 16:55:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 16:55:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTca3-0006wa-PF; Thu, 24 Nov 2011 16:55:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTca3-0004Tn-Oc;
	Thu, 24 Nov 2011 16:55:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.30459.750301.824392@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 16:55:23 +0000
To: Vladimir =?utf-8?Q?'=CF=86-coder/phcoder'?= Serbinenko <phcoder@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <m2n.s.1RR00M-272707@chiark.greenend.org.uk>
References: <4EC45B57.80602@gmail.com>
	<20111117005949.GR4275@type.famille.thibault.fr>
	<m2n.s.1RR00M-272707@chiark.greenend.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	xen-devel@lists.xensource.com,
	The development of GRUB 2 <grub-devel@gnu.org>
Subject: [Xen-devel]  Re: [Grub2] Xen branches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28gd3JpdGVzICgiW1hlbi1kZXZl
bF0gUmU6IFtHcnViMl0gWGVuIGJyYW5jaGVzIik6Cj4gT24gMTcuMTEuMjAxMSAwMTo1OSwgU2Ft
dWVsIFRoaWJhdWx0IHdyb3RlOgo+ID4gSXQgY2FuIGJlIHVzZWZ1bCB0byBqdXN0IHJlLXVzZSB0
aGUgZHJpdmVycyBmcm9tIE1pbmktT1MsIGJ1dCB5b3UgbWF5Cj4gPiB3YW50IHRvIHJlaW1wbGVt
ZW50IHRoZW0uCj4gCj4gVGhleSBkb24ndCBzZWVtIHRvIGJlIGRpZmZpY3VsdCB0byBpbXBsZW1l
bnQganVkZ2luZyBmcm9tIHRoZSBzcGVjLiBPbgo+IHRoZSBvdGhlciBoYW5kIG1ha2luZyBNaW5p
T1MgYnVpbGRpbmcgc3lzdGVtIHdvcmsgbmljZWx5IHdpdGggb3Vycwo+IHNvdW5kcyBsaWtlIGhl
bGwuCgpZZXMuICBJIHdvdWxkIGF2b2lkIHRoZSBtaW5pb3MgYnVpbGQgc3lzdGVtOyBpdCdzIGF3
ZnVsLiAgRmVlbCBmcmVlIHRvCmxpZnQgYW55IGNvZGUgdGhhdCBsb29rcyB1c2VmdWwgdGhvdWdo
LgoKSWFuLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:56:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:56:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcbJ-0006qw-FC; Thu, 24 Nov 2011 16:56:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RTcbH-0006qU-R2
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:56:40 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322153767!4507415!1
X-Originating-IP: [65.55.88.13]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23095 invoked from network); 24 Nov 2011 16:56:08 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.13)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Nov 2011 16:56:08 -0000
Received: from mail105-tx2-R.bigfish.com (10.9.14.247) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.22; Thu, 24 Nov 2011 16:55:25 +0000
Received: from mail105-tx2 (localhost [127.0.0.1])	by
	mail105-tx2-R.bigfish.com (Postfix) with ESMTP id 940D93E01A3;
	Thu, 24 Nov 2011 16:55:37 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dK1432N98dKzz1202hzzz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail105-tx2 (localhost.localdomain [127.0.0.1]) by mail105-tx2
	(MessageSwitch) id 1322153736226342_10724;
	Thu, 24 Nov 2011 16:55:36 +0000 (UTC)
Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.238])	by
	mail105-tx2.bigfish.com (Postfix) with ESMTP id 30D4A1C0042;
	Thu, 24 Nov 2011 16:55:36 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server id
	14.1.225.22; Thu, 24 Nov 2011 16:55:23 +0000
X-WSS-ID: 0LV6CDE-02-9HC-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2C672C8110;	Thu, 24 Nov 2011 10:56:02 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 24 Nov 2011 10:56:20 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 24 Nov 2011 10:56:04 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 24 Nov 2011
	11:56:04 -0500
Message-ID: <4ECE7721.8010007@amd.com>
Date: Thu, 24 Nov 2011 17:56:01 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4EBA7C3A.6010801@amd.com>
	<20174.28957.787602.771046@mariner.uk.xensource.com>
In-Reply-To: <20174.28957.787602.771046@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Refactor x86 specific code into x86
 specific files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/24/11 17:30, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] libxc: Refactor x86 specific code into x86 specific files"):
>> Move x86 specific code into x86 specific files.
>> Eliminate arch specific PAGE constants by using common
>> XC_PAGE_* contants.
>
> I'm not sure I understand the motivation for this.

Code cleanup, better readability, better code organization.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 16:56:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 16:56:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcbJ-0006qw-FC; Thu, 24 Nov 2011 16:56:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RTcbH-0006qU-R2
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 16:56:40 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322153767!4507415!1
X-Originating-IP: [65.55.88.13]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23095 invoked from network); 24 Nov 2011 16:56:08 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.13)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Nov 2011 16:56:08 -0000
Received: from mail105-tx2-R.bigfish.com (10.9.14.247) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.22; Thu, 24 Nov 2011 16:55:25 +0000
Received: from mail105-tx2 (localhost [127.0.0.1])	by
	mail105-tx2-R.bigfish.com (Postfix) with ESMTP id 940D93E01A3;
	Thu, 24 Nov 2011 16:55:37 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dK1432N98dKzz1202hzzz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail105-tx2 (localhost.localdomain [127.0.0.1]) by mail105-tx2
	(MessageSwitch) id 1322153736226342_10724;
	Thu, 24 Nov 2011 16:55:36 +0000 (UTC)
Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.238])	by
	mail105-tx2.bigfish.com (Postfix) with ESMTP id 30D4A1C0042;
	Thu, 24 Nov 2011 16:55:36 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server id
	14.1.225.22; Thu, 24 Nov 2011 16:55:23 +0000
X-WSS-ID: 0LV6CDE-02-9HC-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2C672C8110;	Thu, 24 Nov 2011 10:56:02 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 24 Nov 2011 10:56:20 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 24 Nov 2011 10:56:04 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 24 Nov 2011
	11:56:04 -0500
Message-ID: <4ECE7721.8010007@amd.com>
Date: Thu, 24 Nov 2011 17:56:01 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <4EBA7C3A.6010801@amd.com>
	<20174.28957.787602.771046@mariner.uk.xensource.com>
In-Reply-To: <20174.28957.787602.771046@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxc: Refactor x86 specific code into x86
 specific files
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/24/11 17:30, Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH] libxc: Refactor x86 specific code into x86 specific files"):
>> Move x86 specific code into x86 specific files.
>> Eliminate arch specific PAGE constants by using common
>> XC_PAGE_* contants.
>
> I'm not sure I understand the motivation for this.

Code cleanup, better readability, better code organization.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:01:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcfn-0007GL-8C; Thu, 24 Nov 2011 17:01:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcfl-0007Fv-7x
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:01:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322154045!5614928!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5685 invoked from network); 24 Nov 2011 17:00:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:00:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:00:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcfE-0006yd-IX; Thu, 24 Nov 2011 17:00:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcfE-0004Uj-Hp;
	Thu, 24 Nov 2011 17:00:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.30780.537728.282540@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:00:44 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9aa0fdb44068548abc75.1321540776@cosworth.uk.xensource.com>
References: <9aa0fdb44068548abc75.1321540776@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: dgdegra@tycho.nsa.gov, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] libvchan: clean *.opic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] libvchan: clean *.opic"):
> libvchan: clean *.opic

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:01:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcfn-0007GL-8C; Thu, 24 Nov 2011 17:01:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcfl-0007Fv-7x
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:01:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322154045!5614928!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5685 invoked from network); 24 Nov 2011 17:00:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:00:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:00:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:00:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcfE-0006yd-IX; Thu, 24 Nov 2011 17:00:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcfE-0004Uj-Hp;
	Thu, 24 Nov 2011 17:00:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.30780.537728.282540@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:00:44 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9aa0fdb44068548abc75.1321540776@cosworth.uk.xensource.com>
References: <9aa0fdb44068548abc75.1321540776@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: dgdegra@tycho.nsa.gov, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] libvchan: clean *.opic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH] libvchan: clean *.opic"):
> libvchan: clean *.opic

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:01:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcfs-0007Gi-Kw; Thu, 24 Nov 2011 17:01:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTcfr-0007Ga-A1
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:01:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322154023!45270379!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25043 invoked from network); 24 Nov 2011 17:00:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 17:00:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 17:00:56 +0000
Message-Id: <4ECE8656020000780006314D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 17:00:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322152518.1005.189.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.11.11 at 17:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2011-11-24 at 16:23 +0000, Ian Jackson wrote:
>> In file included from block-aio.c:45:
>> tapaio.h:42: error: expected specifier-qualifier-list before 'io_context_t'
> 
> Further up there is a 
> block-aio.c:36:20: error: libaio.h: No such file or directory
> 
> I think you need to install libaio-dev.

But if there's a new dependency, should that be verified in tools/check/,
so that things fail early?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:01:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:01:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcfs-0007Gi-Kw; Thu, 24 Nov 2011 17:01:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTcfr-0007Ga-A1
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:01:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322154023!45270379!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25043 invoked from network); 24 Nov 2011 17:00:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 17:00:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 24 Nov 2011 17:00:56 +0000
Message-Id: <4ECE8656020000780006314D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 24 Nov 2011 17:00:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322152518.1005.189.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.11.11 at 17:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2011-11-24 at 16:23 +0000, Ian Jackson wrote:
>> In file included from block-aio.c:45:
>> tapaio.h:42: error: expected specifier-qualifier-list before 'io_context_t'
> 
> Further up there is a 
> block-aio.c:36:20: error: libaio.h: No such file or directory
> 
> I think you need to install libaio-dev.

But if there's a new dependency, should that be verified in tools/check/,
so that things fail early?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:05:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:05:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcjN-0007Z6-C3; Thu, 24 Nov 2011 17:05:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTcjM-0007Yw-9a
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:05:00 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322154169!53559323!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18863 invoked from network); 24 Nov 2011 17:02:49 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:02:49 -0000
Received: by fagn18 with SMTP id n18so19327fag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 09:04:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=kQ2Q+ine8u89HkSHgwcHWvR2Jy/MmCMQ+T40XlTzIHc=;
	b=ZyhFvAzKzTM0+neI/Zwsq3+WWnll0qWEmSx1FZY/zjLcz7kyjH4PD8XXm3i+q0COMV
	bEN2OkdXz51pdYwZxvCqVUWHOVfLUHWdwPA8rbrYwsvtFQnOag0A8ssCOFB4oKIGzoUe
	WUKffZ0BkFn8RFYgL/yqn0WGwY8Moa2XcaxjI=
Received: by 10.205.112.6 with SMTP id eq6mr30322924bkc.16.1322154273487;
	Thu, 24 Nov 2011 09:04:33 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id x14sm16337387bkf.10.2011.11.24.09.04.31
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 09:04:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 17:04:29 +0000
From: Keir Fraser <keir@xen.org>
To: Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CAF4299D.34C87%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 1 of 3] Ensure maps used by nested hvm code
	cannot be paged out
Thread-Index: AcyqyyCqjS9+/NxZ/0mfDToIJZ1vhA==
In-Reply-To: <20111124164805.GN77868@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] Ensure maps used by nested hvm code
 cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 16:48, "Tim Deegan" <tim@xen.org> wrote:

> This is a bit messy still.  On 64-bit Xen we could just use
> virt_to_page() on the map pointers rather than storing their
> page_info pointers separately.
> 
> On 32-bit, maybe we could use the existing linear mappings to look up
> the MFN instead.  Or would it be easier to add a function to eth
> map_domain_page() family that does va->mfn for mapped frames?
> Keir, any opinion?

Whatever's easiest. 32-bit isn't a priority.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:05:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:05:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcjN-0007Z6-C3; Thu, 24 Nov 2011 17:05:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTcjM-0007Yw-9a
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:05:00 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322154169!53559323!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18863 invoked from network); 24 Nov 2011 17:02:49 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:02:49 -0000
Received: by fagn18 with SMTP id n18so19327fag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 09:04:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=kQ2Q+ine8u89HkSHgwcHWvR2Jy/MmCMQ+T40XlTzIHc=;
	b=ZyhFvAzKzTM0+neI/Zwsq3+WWnll0qWEmSx1FZY/zjLcz7kyjH4PD8XXm3i+q0COMV
	bEN2OkdXz51pdYwZxvCqVUWHOVfLUHWdwPA8rbrYwsvtFQnOag0A8ssCOFB4oKIGzoUe
	WUKffZ0BkFn8RFYgL/yqn0WGwY8Moa2XcaxjI=
Received: by 10.205.112.6 with SMTP id eq6mr30322924bkc.16.1322154273487;
	Thu, 24 Nov 2011 09:04:33 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id x14sm16337387bkf.10.2011.11.24.09.04.31
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 09:04:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 17:04:29 +0000
From: Keir Fraser <keir@xen.org>
To: Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CAF4299D.34C87%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 1 of 3] Ensure maps used by nested hvm code
	cannot be paged out
Thread-Index: AcyqyyCqjS9+/NxZ/0mfDToIJZ1vhA==
In-Reply-To: <20111124164805.GN77868@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 3] Ensure maps used by nested hvm code
 cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 16:48, "Tim Deegan" <tim@xen.org> wrote:

> This is a bit messy still.  On 64-bit Xen we could just use
> virt_to_page() on the map pointers rather than storing their
> page_info pointers separately.
> 
> On 32-bit, maybe we could use the existing linear mappings to look up
> the MFN instead.  Or would it be easier to add a function to eth
> map_domain_page() family that does va->mfn for mapped frames?
> Keir, any opinion?

Whatever's easiest. 32-bit isn't a priority.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:07:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTclr-0007sn-Lq; Thu, 24 Nov 2011 17:07:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTclq-0007sE-G5
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:07:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322154423!4874735!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2112 invoked from network); 24 Nov 2011 17:07:03 -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;
	24 Nov 2011 17:07:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118202"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:06:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:06:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcks-00070v-Rp; Thu, 24 Nov 2011 17:06:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcks-0004WB-R3;
	Thu, 24 Nov 2011 17:06:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.31130.609126.117709@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:06:34 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into
	final	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final filename"):
> docs: generate docs direct into final filename
> 
> Nothing depends on the final document

... except the user.

> so there is not much point in generating
> to a tempfile and move-if-changed.

We don't want to leave half-generated documents lying around which
aren't fixed by "make", regardless of further dependencies, surely ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:07:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTclr-0007sn-Lq; Thu, 24 Nov 2011 17:07:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTclq-0007sE-G5
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:07:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322154423!4874735!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2112 invoked from network); 24 Nov 2011 17:07:03 -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;
	24 Nov 2011 17:07:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118202"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:06:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:06:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcks-00070v-Rp; Thu, 24 Nov 2011 17:06:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcks-0004WB-R3;
	Thu, 24 Nov 2011 17:06:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.31130.609126.117709@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:06:34 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into
	final	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final filename"):
> docs: generate docs direct into final filename
> 
> Nothing depends on the final document

... except the user.

> so there is not much point in generating
> to a tempfile and move-if-changed.

We don't want to leave half-generated documents lying around which
aren't fixed by "make", regardless of further dependencies, surely ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:07:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTclt-0007t9-40; Thu, 24 Nov 2011 17:07:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTclr-0007sk-FI
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:07:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322154396!58574901!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13921 invoked from network); 24 Nov 2011 17:06:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 17:06:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTclP-000Lbh-MT; Thu, 24 Nov 2011 17:07:07 +0000
Date: Thu, 24 Nov 2011 17:07:07 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124170707.GO77868@ocelot.phlegethon.org>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
	<b0410cb27d17a470005e.1322142092@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b0410cb27d17a470005e.1322142092@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Ensure liveness of pages involved in
	a guest page table walk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:41 -0500 on 24 Nov (1322124092), Andres Lagar-Cavilla wrote:
> Instead of risking deadlock by holding onto the gfn's acquired during
> a guest page table walk, acquire an extra reference within the get_gfn/
> put_gfn critical section, and drop the extra reference when done with
> the map. This ensures liveness of the map, i.e. the underlying page
> won't be paged out.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:07:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTclt-0007t9-40; Thu, 24 Nov 2011 17:07:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTclr-0007sk-FI
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:07:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322154396!58574901!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13921 invoked from network); 24 Nov 2011 17:06:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 17:06:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTclP-000Lbh-MT; Thu, 24 Nov 2011 17:07:07 +0000
Date: Thu, 24 Nov 2011 17:07:07 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124170707.GO77868@ocelot.phlegethon.org>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
	<b0410cb27d17a470005e.1322142092@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b0410cb27d17a470005e.1322142092@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 3] Ensure liveness of pages involved in
	a guest page table walk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:41 -0500 on 24 Nov (1322124092), Andres Lagar-Cavilla wrote:
> Instead of risking deadlock by holding onto the gfn's acquired during
> a guest page table walk, acquire an extra reference within the get_gfn/
> put_gfn critical section, and drop the extra reference when done with
> the map. This ensures liveness of the map, i.e. the underlying page
> won't be paged out.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:08:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcmQ-00080v-Or; Thu, 24 Nov 2011 17:08:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTcmP-0007z2-82
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:08:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322154457!2898436!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30375 invoked from network); 24 Nov 2011 17:07:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 17:07:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTclt-000Lc3-GZ; Thu, 24 Nov 2011 17:07:37 +0000
Date: Thu, 24 Nov 2011 17:07:37 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124170737.GP77868@ocelot.phlegethon.org>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
	<9e44fd6e495518af3ac2.1322142093@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9e44fd6e495518af3ac2.1322142093@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 3] Fix liveness of pages in grant copy
	operations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:41 -0500 on 24 Nov (1322124093), Andres Lagar-Cavilla wrote:
> We were immediately putting the p2m entry translation for grant
> copy operations. This allowed for an unnecessary race by which the
> page could have been swapped out between the p2m lookup and the actual
> use. Hold on to the p2m entries until the grant operation finishes.
> 
> Also fixes a small bug: for the source page of the copy, get_page
> was assuming the page was owned by the source domain. It may be a
> shared page, since we don't perform an unsharing p2m lookup.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:08:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:08:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcmQ-00080v-Or; Thu, 24 Nov 2011 17:08:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTcmP-0007z2-82
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:08:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322154457!2898436!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30375 invoked from network); 24 Nov 2011 17:07:38 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 17:07:38 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTclt-000Lc3-GZ; Thu, 24 Nov 2011 17:07:37 +0000
Date: Thu, 24 Nov 2011 17:07:37 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124170737.GP77868@ocelot.phlegethon.org>
References: <patchbomb.1322142090@xdev.gridcentric.ca>
	<9e44fd6e495518af3ac2.1322142093@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9e44fd6e495518af3ac2.1322142093@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 3 of 3] Fix liveness of pages in grant copy
	operations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:41 -0500 on 24 Nov (1322124093), Andres Lagar-Cavilla wrote:
> We were immediately putting the p2m entry translation for grant
> copy operations. This allowed for an unnecessary race by which the
> page could have been swapped out between the p2m lookup and the actual
> use. Hold on to the p2m entries until the grant operation finishes.
> 
> Also fixes a small bug: for the source page of the copy, get_page
> was assuming the page was owned by the source domain. It may be a
> shared page, since we don't perform an unsharing p2m lookup.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:08:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcmh-000864-8h; Thu, 24 Nov 2011 17:08:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcmg-00083w-1a
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:08:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322154474!5655504!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18341 invoked from network); 24 Nov 2011 17:07:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118229"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:07:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:07:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcmA-00071X-Az; Thu, 24 Nov 2011 17:07:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcmA-0004We-AM;
	Thu, 24 Nov 2011 17:07:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.31210.305203.236947@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:07:54 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <83fc69637135353021aa.1321542123@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<83fc69637135353021aa.1321542123@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 17 of 17] docs: install txt files as html
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 17 of 17] docs: install txt files as html"):
> docs: install txt files as html
...
> NB: I'm not totally sure about this since many of the *.txt docs are out of
> date or deeply technical etc. It might be preferable to simply add the minimal
> necessary markdown to the ones we actually want to publish.

I think putting them all there is a reasonable first step.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:08:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:08:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcmh-000864-8h; Thu, 24 Nov 2011 17:08:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTcmg-00083w-1a
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:08:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322154474!5655504!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18341 invoked from network); 24 Nov 2011 17:07:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118229"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:07:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:07:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTcmA-00071X-Az; Thu, 24 Nov 2011 17:07:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTcmA-0004We-AM;
	Thu, 24 Nov 2011 17:07:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.31210.305203.236947@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:07:54 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <83fc69637135353021aa.1321542123@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<83fc69637135353021aa.1321542123@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 17 of 17] docs: install txt files as html
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 17 of 17] docs: install txt files as html"):
> docs: install txt files as html
...
> NB: I'm not totally sure about this since many of the *.txt docs are out of
> date or deeply technical etc. It might be preferable to simply add the minimal
> necessary markdown to the ones we actually want to publish.

I think putting them all there is a reasonable first step.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:10:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcoW-0008Uj-T4; Thu, 24 Nov 2011 17:10:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTcoU-0008TA-Ny
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:10:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322154586!5544708!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4254 invoked from network); 24 Nov 2011 17:09:47 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 17:09:47 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 52118714075;
	Thu, 24 Nov 2011 09:09:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=UXceofaSUeCQDCzpcItmLxKc2P7PUQm8VtDWrrJ1Jzz8
	96IRVQzfIt14P6zswH5LuO+LJxUtl1ITq6GwLPptP6Xmn9sNx5Yj1AZHL6Yr45i8
	Zw6ih5HOf6H2RP4HLdeE8HRc1tDD7mehWoZVGskSMG1sBJyHR4HIy4bnIe7EVfI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; s=
	lagarcavilla.org; bh=od3uEK6xod62YORXnhqoC9DvclU=; b=rFKS4XkrRuK
	DW9NoG0h8PSISNbfODD6qRt2lBBM7COuexuJ6uIsaQlmk2736zeSUdDiX4gipP8Q
	Z8xqc+R60YitpyDwF4SdSH3ljVqXlGLQJRrKSfqXQnNPSvlEZ+wg+64Izhd+1/Q8
	Mdlkao7MBb/eet5/n1sYeq5h0PMlX73o=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 1681B714070; 
	Thu, 24 Nov 2011 09:09:46 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 09:09:46 -0800
Message-ID: <8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
References: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 09:09:46 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com,
 tim@xen.org,
 olaf@aepfle.de
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Thu, 24 Nov 2011 11:38:02 +0000
> From: Tim Deegan <tim@xen.org>
> To: Olaf Hering <olaf@aepfle.de>
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state
> 	read-only
> Message-ID: <20111124113802.GB77868@ocelot.phlegethon.org>
> Content-Type: text/plain; charset=iso-8859-1
>
> At 17:53 +0100 on 14 Nov (1321293182), Olaf Hering wrote:
>>
>> I was wondering why ept_p2m_type_to_flags() removes all permissions from
>> a gfn in state p2m_ram_paging_out. If the guest happens to read or
>> execute from that page while the pager writes that gfn to disk, wouldnt
>> it be enough to remove the write bit to prevent writes from the guest?
>> If the page is read-only the guest could continue to make progress until
>> the gfn is really evicted and the p2mt changes to p2m_ram_paged.
>>
>> I havent actually tried the patch below, but is there any reason it
>> would break the guest?
>
> As long as we change the p2m type before scrubbing or freeing the page,
> that seems like it shuold be fine.

Is this a good idea? If the guest is accessing the page, then paging out
should stop immediately. We're risking complex races for a tiny tiny gain.

Andres
>
> Tim.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 24 Nov 2011 11:38:19 +0000
> From: Ian Jackson <Ian.Jackson@eu.citrix.com>
> To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 00 of 14] MM Fixes
> Message-ID: <20174.11435.306730.583922@mariner.uk.xensource.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 00 of 14] MM Fixes"):
>> This patch series includes a number of bug fixes, targetting
>> primarily the mm layer. Many of these fixes also lay groundwork
>> for future patches.
>
> Thanks.  Something seems to have eaten patches 12,13,14.
>
> Can you please confirm that you sent them, and tell me their
> messageids, and any information you can tell me about their
> transmission ?
>
> Ideally I would like log entries from the final hop mail server on
> your side showing the messages being handed over to the MX's for
> lists.xensource.com, but looking at the headers of your other messages
> they came through "homiemail-***.***.dreamhost.com" so that may
> involve talking to whoever they are.
>
> Thanks,
> Ian.
>
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 24 Nov 2011 11:58:16 +0000
> From: Tim Deegan <tim@xen.org>
> To: ???? <327801865@qq.com>
> Cc: Xen-devel <Xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] HVM (hypercall_grant_table_op) Problem
> Message-ID: <20111124115816.GD77868@ocelot.phlegethon.org>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hi,
>
> At 00:52 +0800 on 18 Nov (1321577533), ???? wrote:
>> Hi:
>>      I modified the netfont.c of Linux HVM domU installed PVonHVM.In it,
>> I call hypercall_grant_table_op
>>  (GNTTABOP_map_grant_ref...), then dom0 shutdown and restart at once.
>
> Do you have a serial line attached to the machine to capture the console
> output when this happens?  Without that it's hard to knwo what the bug is.
>
>>      From above, I conclude that I can map a HVM's page to another HVM,
>> just like two PVs.
>>  Am I wrong? Who can give me some suggestion?
>
> Yes, HVM guests can now map granted frames, but not quite 'just like pv'.
> The grant hypercall maps the granted frame into the HVM guest's p2m map,
> instead of into the pagetables.  That is, you pass in a PFN, and when
> the grant succeeds, you still need to map that PFN in your pagetables to
> access the page.
>
> The checkin that added the feature came with this comment:
>
>   After some discussion, here's a second version of the patch I posted a
>   couple of weeks back to map grant references into HVM guests.  As
>   before, this is done by modifying the P2M map, but this time there's
>   no new hypercall to do it.  Instead, the existing GNTTABOP_map is
>   overloaded to perform a P2M mapping if called from a shadow mode
>   translate guest.  This matches the IA64 API.
>
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/c0cb307d927f
>
> Tim.
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 81, Issue 328
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:10:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:10:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcoW-0008Uj-T4; Thu, 24 Nov 2011 17:10:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTcoU-0008TA-Ny
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:10:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322154586!5544708!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4254 invoked from network); 24 Nov 2011 17:09:47 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 17:09:47 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 52118714075;
	Thu, 24 Nov 2011 09:09:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=UXceofaSUeCQDCzpcItmLxKc2P7PUQm8VtDWrrJ1Jzz8
	96IRVQzfIt14P6zswH5LuO+LJxUtl1ITq6GwLPptP6Xmn9sNx5Yj1AZHL6Yr45i8
	Zw6ih5HOf6H2RP4HLdeE8HRc1tDD7mehWoZVGskSMG1sBJyHR4HIy4bnIe7EVfI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:reply-to
	:mime-version:content-type:content-transfer-encoding; s=
	lagarcavilla.org; bh=od3uEK6xod62YORXnhqoC9DvclU=; b=rFKS4XkrRuK
	DW9NoG0h8PSISNbfODD6qRt2lBBM7COuexuJ6uIsaQlmk2736zeSUdDiX4gipP8Q
	Z8xqc+R60YitpyDwF4SdSH3ljVqXlGLQJRrKSfqXQnNPSvlEZ+wg+64Izhd+1/Q8
	Mdlkao7MBb/eet5/n1sYeq5h0PMlX73o=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 1681B714070; 
	Thu, 24 Nov 2011 09:09:46 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 09:09:46 -0800
Message-ID: <8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
References: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
Date: Thu, 24 Nov 2011 09:09:46 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com,
 tim@xen.org,
 olaf@aepfle.de
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Thu, 24 Nov 2011 11:38:02 +0000
> From: Tim Deegan <tim@xen.org>
> To: Olaf Hering <olaf@aepfle.de>
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state
> 	read-only
> Message-ID: <20111124113802.GB77868@ocelot.phlegethon.org>
> Content-Type: text/plain; charset=iso-8859-1
>
> At 17:53 +0100 on 14 Nov (1321293182), Olaf Hering wrote:
>>
>> I was wondering why ept_p2m_type_to_flags() removes all permissions from
>> a gfn in state p2m_ram_paging_out. If the guest happens to read or
>> execute from that page while the pager writes that gfn to disk, wouldnt
>> it be enough to remove the write bit to prevent writes from the guest?
>> If the page is read-only the guest could continue to make progress until
>> the gfn is really evicted and the p2mt changes to p2m_ram_paged.
>>
>> I havent actually tried the patch below, but is there any reason it
>> would break the guest?
>
> As long as we change the p2m type before scrubbing or freeing the page,
> that seems like it shuold be fine.

Is this a good idea? If the guest is accessing the page, then paging out
should stop immediately. We're risking complex races for a tiny tiny gain.

Andres
>
> Tim.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 24 Nov 2011 11:38:19 +0000
> From: Ian Jackson <Ian.Jackson@eu.citrix.com>
> To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 00 of 14] MM Fixes
> Message-ID: <20174.11435.306730.583922@mariner.uk.xensource.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 00 of 14] MM Fixes"):
>> This patch series includes a number of bug fixes, targetting
>> primarily the mm layer. Many of these fixes also lay groundwork
>> for future patches.
>
> Thanks.  Something seems to have eaten patches 12,13,14.
>
> Can you please confirm that you sent them, and tell me their
> messageids, and any information you can tell me about their
> transmission ?
>
> Ideally I would like log entries from the final hop mail server on
> your side showing the messages being handed over to the MX's for
> lists.xensource.com, but looking at the headers of your other messages
> they came through "homiemail-***.***.dreamhost.com" so that may
> involve talking to whoever they are.
>
> Thanks,
> Ian.
>
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 24 Nov 2011 11:58:16 +0000
> From: Tim Deegan <tim@xen.org>
> To: ???? <327801865@qq.com>
> Cc: Xen-devel <Xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] HVM (hypercall_grant_table_op) Problem
> Message-ID: <20111124115816.GD77868@ocelot.phlegethon.org>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hi,
>
> At 00:52 +0800 on 18 Nov (1321577533), ???? wrote:
>> Hi:
>>      I modified the netfont.c of Linux HVM domU installed PVonHVM.In it,
>> I call hypercall_grant_table_op
>>  (GNTTABOP_map_grant_ref...), then dom0 shutdown and restart at once.
>
> Do you have a serial line attached to the machine to capture the console
> output when this happens?  Without that it's hard to knwo what the bug is.
>
>>      From above, I conclude that I can map a HVM's page to another HVM,
>> just like two PVs.
>>  Am I wrong? Who can give me some suggestion?
>
> Yes, HVM guests can now map granted frames, but not quite 'just like pv'.
> The grant hypercall maps the granted frame into the HVM guest's p2m map,
> instead of into the pagetables.  That is, you pass in a PFN, and when
> the grant succeeds, you still need to map that PFN in your pagetables to
> access the page.
>
> The checkin that added the feature came with this comment:
>
>   After some discussion, here's a second version of the patch I posted a
>   couple of weeks back to map grant references into HVM guests.  As
>   before, this is done by modifying the P2M map, but this time there's
>   no new hypercall to do it.  Instead, the existing GNTTABOP_map is
>   overloaded to perform a P2M mapping if called from a shadow mode
>   translate guest.  This matches the IA64 API.
>
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/c0cb307d927f
>
> Tim.
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 81, Issue 328
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:13:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:13:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcrB-0000Q8-KN; Thu, 24 Nov 2011 17:13:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTcrA-0000PP-9j
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:13:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322154752!2908364!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6024 invoked from network); 24 Nov 2011 17:12:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:12:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:12:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 17:12:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20174.31130.609126.117709@mariner.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
	<20174.31130.609126.117709@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 17:12:31 +0000
Message-ID: <1322154751.9567.56.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into
 final	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final filename"):
> > docs: generate docs direct into final filename
> > 
> > Nothing depends on the final document
> 
> ... except the user.

OK, nothing about the build depends...

> > so there is not much point in generating
> > to a tempfile and move-if-changed.
> 
> We don't want to leave half-generated documents lying around which
> aren't fixed by "make", regardless of further dependencies, surely ?

Doesn't make automatically delete the targets if the command fails?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:13:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:13:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcrB-0000Q8-KN; Thu, 24 Nov 2011 17:13:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTcrA-0000PP-9j
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:13:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322154752!2908364!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6024 invoked from network); 24 Nov 2011 17:12:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:12:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118333"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:12:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 17:12:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20174.31130.609126.117709@mariner.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
	<20174.31130.609126.117709@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 17:12:31 +0000
Message-ID: <1322154751.9567.56.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into
 final	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final filename"):
> > docs: generate docs direct into final filename
> > 
> > Nothing depends on the final document
> 
> ... except the user.

OK, nothing about the build depends...

> > so there is not much point in generating
> > to a tempfile and move-if-changed.
> 
> We don't want to leave half-generated documents lying around which
> aren't fixed by "make", regardless of further dependencies, surely ?

Doesn't make automatically delete the targets if the command fails?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:14:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcsG-0000WS-Ty; Thu, 24 Nov 2011 17:14:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTcsE-0000VR-Ng
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:14:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322154818!4494755!1
X-Originating-IP: [208.97.132.66]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1657 invoked from network); 24 Nov 2011 17:13:39 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-10.tower-182.messagelabs.com with SMTP;
	24 Nov 2011 17:13:39 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id E6CF3300079;
	Thu, 24 Nov 2011 09:13:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Px7sMkzxUptUmXf7QGdcWG9qmfHm//mjqNTDus73gx7p
	g1FbvwQfGfHIGIFuOu/QabvHHCyEQiOzwnFL3jHD4hLGbO3gnq2wHyLJXLsqvGa+
	p1V8DC+QbhHy2HCPYCDVuX/a1K4+bTzGKpOgwGdHnAd9TKmEnRidqcQLDtmzVF4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=YRySwfZYDuUhDXmpVczmTgACL2o=; b=DxR5bi5Dn6I
	/tguyt6OBwy9EbSMEFg6ZUugSPHX2On/xN0WZIIABTM51L7sA9r9qanfvkS+EEXW
	Li9ScfiMjukVqjOHwr5Exu1774K5l7sP8e80dcQa476QHR/0s5VTjFc8P1DuxrQu
	0AgITgla8kkZZsllhpcB8V8ueQC5wilc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 209BF300072; 
	Thu, 24 Nov 2011 09:13:37 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1994287f9fc142d974901e1d9a6af62b9fef383e
Message-Id: <1994287f9fc142d97490.1322154760@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322154758@xdev.gridcentric.ca>
References: <patchbomb.1322154758@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 12:12:40 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Add libxc wrapper for p2m audit domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_domain.c |  22 ++++++++++++++++++++++
 tools/libxc/xenctrl.h   |  27 +++++++++++++++++++++++++++
 2 files changed, 49 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f964ff59ca6c -r 1994287f9fc1 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1472,6 +1472,28 @@ int xc_domain_debug_control(xc_interface
     return do_domctl(xc, &domctl);
 }
 
+int xc_domain_p2m_audit(xc_interface *xch, 
+                        uint32_t domid,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,   
+                        uint64_t *p2m_bad)
+{
+    DECLARE_DOMCTL;
+    int rc;
+
+    domctl.cmd = XEN_DOMCTL_audit_p2m;
+    domctl.domain = domid;
+    rc = do_domctl(xch, &domctl);
+
+    *orphans_debug      = domctl.u.audit_p2m.orphans_debug;
+    *orphans_invalid    = domctl.u.audit_p2m.orphans_invalid;
+    *m2p_bad            = domctl.u.audit_p2m.m2p_bad;
+    *p2m_bad            = domctl.u.audit_p2m.p2m_bad;
+
+    return rc;
+}
+
 int xc_domain_set_access_required(xc_interface *xch,
                                   uint32_t domid,
                                   unsigned int required)
diff -r f964ff59ca6c -r 1994287f9fc1 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -712,6 +712,33 @@ int xc_domain_setdebugging(xc_interface 
                            unsigned int enable);
 
 /**
+ * This function audits the (top level) p2m of a domain 
+ * and returns the different error counts, if any.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id whose top level p2m we 
+ *       want to audit
+ * @parm orphans_debug count of m2p entries for valid
+ *       domain pages containing a debug value
+ * @parm orphans_invalid count of m2p entries for valid
+ *       domain pages containing an invalid value
+ * @parm m2p_bad count of m2p entries mismatching the
+ *       associated p2m entry for this domain
+ * @parm p2m_bad count of p2m entries for this domain
+ *       mismatching the associated m2p entry
+ * return 0 on success, -1 on failure
+ * errno values on failure include: 
+ *          -ENOSYS: not implemented
+ *          -EFAULT: could not copy results back to guest
+ */
+int xc_domain_p2m_audit(xc_interface *xch,
+				        uint32_t domid,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,   
+                        uint64_t *p2m_bad);
+
+/**
  * This function sets or clears the requirement that an access memory
  * event listener is required on the domain.
  *

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:14:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcsG-0000WS-Ty; Thu, 24 Nov 2011 17:14:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTcsE-0000VR-Ng
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:14:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322154818!4494755!1
X-Originating-IP: [208.97.132.66]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1657 invoked from network); 24 Nov 2011 17:13:39 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-10.tower-182.messagelabs.com with SMTP;
	24 Nov 2011 17:13:39 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id E6CF3300079;
	Thu, 24 Nov 2011 09:13:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Px7sMkzxUptUmXf7QGdcWG9qmfHm//mjqNTDus73gx7p
	g1FbvwQfGfHIGIFuOu/QabvHHCyEQiOzwnFL3jHD4hLGbO3gnq2wHyLJXLsqvGa+
	p1V8DC+QbhHy2HCPYCDVuX/a1K4+bTzGKpOgwGdHnAd9TKmEnRidqcQLDtmzVF4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=YRySwfZYDuUhDXmpVczmTgACL2o=; b=DxR5bi5Dn6I
	/tguyt6OBwy9EbSMEFg6ZUugSPHX2On/xN0WZIIABTM51L7sA9r9qanfvkS+EEXW
	Li9ScfiMjukVqjOHwr5Exu1774K5l7sP8e80dcQa476QHR/0s5VTjFc8P1DuxrQu
	0AgITgla8kkZZsllhpcB8V8ueQC5wilc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 209BF300072; 
	Thu, 24 Nov 2011 09:13:37 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1994287f9fc142d974901e1d9a6af62b9fef383e
Message-Id: <1994287f9fc142d97490.1322154760@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322154758@xdev.gridcentric.ca>
References: <patchbomb.1322154758@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 12:12:40 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Add libxc wrapper for p2m audit domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_domain.c |  22 ++++++++++++++++++++++
 tools/libxc/xenctrl.h   |  27 +++++++++++++++++++++++++++
 2 files changed, 49 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f964ff59ca6c -r 1994287f9fc1 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1472,6 +1472,28 @@ int xc_domain_debug_control(xc_interface
     return do_domctl(xc, &domctl);
 }
 
+int xc_domain_p2m_audit(xc_interface *xch, 
+                        uint32_t domid,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,   
+                        uint64_t *p2m_bad)
+{
+    DECLARE_DOMCTL;
+    int rc;
+
+    domctl.cmd = XEN_DOMCTL_audit_p2m;
+    domctl.domain = domid;
+    rc = do_domctl(xch, &domctl);
+
+    *orphans_debug      = domctl.u.audit_p2m.orphans_debug;
+    *orphans_invalid    = domctl.u.audit_p2m.orphans_invalid;
+    *m2p_bad            = domctl.u.audit_p2m.m2p_bad;
+    *p2m_bad            = domctl.u.audit_p2m.p2m_bad;
+
+    return rc;
+}
+
 int xc_domain_set_access_required(xc_interface *xch,
                                   uint32_t domid,
                                   unsigned int required)
diff -r f964ff59ca6c -r 1994287f9fc1 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -712,6 +712,33 @@ int xc_domain_setdebugging(xc_interface 
                            unsigned int enable);
 
 /**
+ * This function audits the (top level) p2m of a domain 
+ * and returns the different error counts, if any.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id whose top level p2m we 
+ *       want to audit
+ * @parm orphans_debug count of m2p entries for valid
+ *       domain pages containing a debug value
+ * @parm orphans_invalid count of m2p entries for valid
+ *       domain pages containing an invalid value
+ * @parm m2p_bad count of m2p entries mismatching the
+ *       associated p2m entry for this domain
+ * @parm p2m_bad count of p2m entries for this domain
+ *       mismatching the associated m2p entry
+ * return 0 on success, -1 on failure
+ * errno values on failure include: 
+ *          -ENOSYS: not implemented
+ *          -EFAULT: could not copy results back to guest
+ */
+int xc_domain_p2m_audit(xc_interface *xch,
+				        uint32_t domid,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,   
+                        uint64_t *p2m_bad);
+
+/**
  * This function sets or clears the requirement that an access memory
  * event listener is required on the domain.
  *

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:14:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcsE-0000Vq-3m; Thu, 24 Nov 2011 17:14:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTcsC-0000VC-Ee
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:14:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322154816!4875460!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18894 invoked from network); 24 Nov 2011 17:13:36 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-7.tower-216.messagelabs.com with SMTP;
	24 Nov 2011 17:13:36 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id DAE12300074;
	Thu, 24 Nov 2011 09:13:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=WCrBSYoazB1VRs9kAbD+Ri
	6qJcNWQe+huhaaFBL23G/DU4PNwMfUWMS6sofPB1hm0bxwkzBYktx58vk66D2rm0
	5Qq/PIzJ9L/TDDtTe3DYQ8JOANmSEeexMjbtBipzl7UEiDbTLE3mNP+OLTLhDpAk
	AkX8f6q3JSWqcT0YUBnAg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=zLm19evnPeIS
	9DlrgRHO7WHzvGg=; b=f5WANBRbHbO74wPEBxkwwynskjbQfqdD6GCQxv8654oe
	lXtm8nx8xdZntGl3dwoHydtbLwYpECzWu8doPtcmcAl1w7EkxCg23cyHfB1dM8kK
	7Ah6ZK0bUyl+ay9q3ncxBQ4C6JrJ2PCyCdxshhwpL5p3KY/N88hTWjj8RPkoyxA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 0D49F300072; 
	Thu, 24 Nov 2011 09:13:34 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322154758@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 12:12:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] P2M audit rework
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Bring the p2m audit back from the dead. Tease out -ept and -pt
specific code. TUrn it into a domctl.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/domctl.c       |   30 +++++++++
 xen/arch/x86/mm/p2m-ept.c   |    1 +
 xen/arch/x86/mm/p2m-pod.c   |    5 -
 xen/arch/x86/mm/p2m-pt.c    |  137 +++++++------------------------------------
 xen/arch/x86/mm/p2m.c       |  124 ++++++++++++++++++++++++++++++++++++---
 xen/include/asm-x86/p2m.h   |   11 ++-
 xen/include/public/domctl.h |   12 +++
 tools/libxc/xc_domain.c     |   22 +++++++
 tools/libxc/xenctrl.h       |   27 ++++++++
 9 files changed, 235 insertions(+), 134 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:14:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcsE-0000Vq-3m; Thu, 24 Nov 2011 17:14:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTcsC-0000VC-Ee
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:14:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322154816!4875460!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18894 invoked from network); 24 Nov 2011 17:13:36 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-7.tower-216.messagelabs.com with SMTP;
	24 Nov 2011 17:13:36 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id DAE12300074;
	Thu, 24 Nov 2011 09:13:35 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=WCrBSYoazB1VRs9kAbD+Ri
	6qJcNWQe+huhaaFBL23G/DU4PNwMfUWMS6sofPB1hm0bxwkzBYktx58vk66D2rm0
	5Qq/PIzJ9L/TDDtTe3DYQ8JOANmSEeexMjbtBipzl7UEiDbTLE3mNP+OLTLhDpAk
	AkX8f6q3JSWqcT0YUBnAg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=zLm19evnPeIS
	9DlrgRHO7WHzvGg=; b=f5WANBRbHbO74wPEBxkwwynskjbQfqdD6GCQxv8654oe
	lXtm8nx8xdZntGl3dwoHydtbLwYpECzWu8doPtcmcAl1w7EkxCg23cyHfB1dM8kK
	7Ah6ZK0bUyl+ay9q3ncxBQ4C6JrJ2PCyCdxshhwpL5p3KY/N88hTWjj8RPkoyxA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 0D49F300072; 
	Thu, 24 Nov 2011 09:13:34 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322154758@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 12:12:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] P2M audit rework
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Bring the p2m audit back from the dead. Tease out -ept and -pt
specific code. TUrn it into a domctl.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/domctl.c       |   30 +++++++++
 xen/arch/x86/mm/p2m-ept.c   |    1 +
 xen/arch/x86/mm/p2m-pod.c   |    5 -
 xen/arch/x86/mm/p2m-pt.c    |  137 +++++++------------------------------------
 xen/arch/x86/mm/p2m.c       |  124 ++++++++++++++++++++++++++++++++++++---
 xen/include/asm-x86/p2m.h   |   11 ++-
 xen/include/public/domctl.h |   12 +++
 tools/libxc/xc_domain.c     |   22 +++++++
 tools/libxc/xenctrl.h       |   27 ++++++++
 9 files changed, 235 insertions(+), 134 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:14:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcsG-0000WJ-H3; Thu, 24 Nov 2011 17:14:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTcsD-0000VN-TW
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:14:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322154817!5591640!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11322 invoked from network); 24 Nov 2011 17:13:37 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-2.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 17:13:37 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id E831B300061;
	Thu, 24 Nov 2011 09:13:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Js82p9sHFfPGCxtRTKdaeMMHklSuEP+crb3o10GzoEtW
	FWVjfmAbErZNTGzDFIAcD4N3trOhqtX3E5gClLbKEFadoGvoSWRczBlyQJRzdN3w
	SQmNAWb+exwbn1b76EjQCt0/12p7+ixuLveRqLxKdodGTiJYYsjQy044p9pEnSI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=PI8HIz8w5tyBubTefw0a+SIOF7U=; b=dGLHErte3e2
	ddtyxfi4HVX2ltdD0FwJy3hhVGl9dNTUYgx/XEgW13CpLoQojc+dZz+oT0VvrOT3
	+xnTB0KWRLuzB96a1B31O4zkjxMvcrOxVbG7t6qDVYa33tg2olUNSrhVi8h5vkbm
	dC7ZzbfqB+Xaj1qbzyPG7TQtHH9Y7vZw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id E8EA930007B; 
	Thu, 24 Nov 2011 09:13:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f964ff59ca6cfc7902037ccca6d9e93569276600
Message-Id: <f964ff59ca6cfc790203.1322154759@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322154758@xdev.gridcentric.ca>
References: <patchbomb.1322154758@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 12:12:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/domctl.c       |   30 +++++++++
 xen/arch/x86/mm/p2m-ept.c   |    1 +
 xen/arch/x86/mm/p2m-pod.c   |    5 -
 xen/arch/x86/mm/p2m-pt.c    |  137 +++++++------------------------------------
 xen/arch/x86/mm/p2m.c       |  124 ++++++++++++++++++++++++++++++++++++---
 xen/include/asm-x86/p2m.h   |   11 ++-
 xen/include/public/domctl.h |   12 +++
 7 files changed, 186 insertions(+), 134 deletions(-)


The p2m audit code doesn't even compile, let alone work. It also
partially supports ept. Make it:

- compile
- lay groundwork for eventual ept support
- move out of the way of all calls and turn it into a domctl. It's
  obviously not being used by anybody presently.
- enable it via said domctl

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9e44fd6e4955 -r f964ff59ca6c xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1449,6 +1449,36 @@ long arch_do_domctl(
     break;
 #endif /* __x86_64__ */
 
+    case XEN_DOMCTL_audit_p2m:
+    {
+        struct domain *d;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(domctl->domain);
+        if ( d != NULL )
+        {
+            ret = -EPERM;
+            if ( (domctl->domain != DOMID_SELF) &&
+                 (d != current->domain) &&
+                 (IS_PRIV_FOR(current->domain, d)) )
+            {
+#if P2M_AUDIT
+                audit_p2m(d,
+                          &domctl->u.audit_p2m.orphans_debug,
+                          &domctl->u.audit_p2m.orphans_invalid,
+                          &domctl->u.audit_p2m.m2p_bad,
+                          &domctl->u.audit_p2m.p2m_bad);
+                ret = (copy_to_guest(u_domctl, domctl, 1)) ?
+                        -EFAULT : 0;
+#else
+                ret = -ENOSYS;
+#endif /* P2M_AUDIT */
+            }
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     case XEN_DOMCTL_set_access_required:
     {
         struct domain *d;
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -817,6 +817,7 @@ void ept_p2m_init(struct p2m_domain *p2m
     p2m->set_entry = ept_set_entry;
     p2m->get_entry = ept_get_entry;
     p2m->change_entry_type_global = ept_change_entry_type_global;
+    p2m->audit_p2m = NULL;
 }
 
 static void ept_dump_p2m_table(unsigned char key)
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -522,7 +522,6 @@ p2m_pod_decrease_reservation(struct doma
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
 
     if ( unlikely(d->is_dying) )
         goto out_unlock;
@@ -616,7 +615,6 @@ out_entry_check:
     }
 
 out_unlock:
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
 out:
@@ -986,7 +984,6 @@ p2m_pod_demand_populate(struct p2m_domai
          */
         set_p2m_entry(p2m, gfn_aligned, _mfn(0), PAGE_ORDER_2M,
                       p2m_populate_on_demand, p2m->default_access);
-        audit_p2m(p2m, 1);
         return 0;
     }
 
@@ -1108,7 +1105,6 @@ guest_physmap_mark_populate_on_demand(st
         return rc;
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
 
     P2M_DEBUG("mark pod gfn=%#lx\n", gfn);
 
@@ -1142,7 +1138,6 @@ guest_physmap_mark_populate_on_demand(st
         BUG_ON(p2m->pod.entry_count < 0);
     }
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
 out:
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -483,7 +483,6 @@ static int p2m_pod_check_and_populate(st
     /* This is called from the p2m lookups, which can happen with or 
      * without the lock hed. */
     p2m_lock_recursive(p2m);
-    audit_p2m(p2m, 1);
 
     /* Check to make sure this is still PoD */
     if ( p2m_flags_to_type(l1e_get_flags(*p2m_entry)) != p2m_populate_on_demand )
@@ -494,7 +493,6 @@ static int p2m_pod_check_and_populate(st
 
     r = p2m_pod_demand_populate(p2m, gfn, order, q);
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
     return r;
@@ -975,118 +973,23 @@ static void p2m_change_type_global(struc
 
 }
 
-/* Set up the p2m function pointers for pagetable format */
-void p2m_pt_init(struct p2m_domain *p2m)
+#if P2M_AUDIT
+long p2m_pt_audit_p2m(struct p2m_domain *p2m)
 {
-    p2m->set_entry = p2m_set_entry;
-    p2m->get_entry = p2m_gfn_to_mfn;
-    p2m->change_entry_type_global = p2m_change_type_global;
-    p2m->write_p2m_entry = paging_write_p2m_entry;
-}
-
-
-#if P2M_AUDIT
-/* strict_m2p == 0 allows m2p mappings that don'#t match the p2m. 
- * It's intended for add_to_physmap, when the domain has just been allocated 
- * new mfns that might have stale m2p entries from previous owners */
-void audit_p2m(struct p2m_domain *p2m, int strict_m2p)
-{
-    struct page_info *page;
-    struct domain *od;
-    unsigned long mfn, gfn, m2pfn, lp2mfn = 0;
     int entry_count = 0;
-    mfn_t p2mfn;
-    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    unsigned long pmbad = 0;
+    unsigned long mfn, gfn, m2pfn;
     int test_linear;
-    p2m_type_t type;
     struct domain *d = p2m->domain;
 
-    if ( !paging_mode_translate(d) )
-        return;
-
-    //P2M_PRINTK("p2m audit starts\n");
+    ASSERT(p2m_locked_by_me(p2m));
 
     test_linear = ( (d == current->domain)
                     && !pagetable_is_null(current->arch.monitor_table) );
     if ( test_linear )
         flush_tlb_local();
 
-    spin_lock(&d->page_alloc_lock);
-
-    /* Audit part one: walk the domain's page allocation list, checking
-     * the m2p entries. */
-    page_list_for_each ( page, &d->page_list )
-    {
-        mfn = mfn_x(page_to_mfn(page));
-
-        // P2M_PRINTK("auditing guest page, mfn=%#lx\n", mfn);
-
-        od = page_get_owner(page);
-
-        if ( od != d )
-        {
-            P2M_PRINTK("wrong owner %#lx -> %p(%u) != %p(%u)\n",
-                       mfn, od, (od?od->domain_id:-1), d, d->domain_id);
-            continue;
-        }
-
-        gfn = get_gpfn_from_mfn(mfn);
-        if ( gfn == INVALID_M2P_ENTRY )
-        {
-            orphans_i++;
-            //P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
-            //               mfn);
-            continue;
-        }
-
-        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
-        {
-            orphans_d++;
-            //P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
-            //               mfn);
-            continue;
-        }
-
-        if ( gfn == SHARED_M2P_ENTRY )
-        {
-            P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
-                    mfn);
-            continue;
-        }
-
-        p2mfn = gfn_to_mfn_type_p2m(p2m, gfn, &type, p2m_query);
-        if ( strict_m2p && mfn_x(p2mfn) != mfn )
-        {
-            mpbad++;
-            P2M_PRINTK("map mismatch mfn %#lx -> gfn %#lx -> mfn %#lx"
-                       " (-> gfn %#lx)\n",
-                       mfn, gfn, mfn_x(p2mfn),
-                       (mfn_valid(p2mfn)
-                        ? get_gpfn_from_mfn(mfn_x(p2mfn))
-                        : -1u));
-            /* This m2p entry is stale: the domain has another frame in
-             * this physical slot.  No great disaster, but for neatness,
-             * blow away the m2p entry. */
-            set_gpfn_from_mfn(mfn, INVALID_M2P_ENTRY);
-        }
-
-        if ( test_linear && (gfn <= p2m->max_mapped_pfn) )
-        {
-            lp2mfn = mfn_x(gfn_to_mfn_type_p2m(p2m, gfn, &type, p2m_query));
-            if ( lp2mfn != mfn_x(p2mfn) )
-            {
-                P2M_PRINTK("linear mismatch gfn %#lx -> mfn %#lx "
-                           "(!= mfn %#lx)\n", gfn, lp2mfn, mfn_x(p2mfn));
-            }
-        }
-
-        // P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx, lp2mfn=%#lx\n",
-        //                mfn, gfn, mfn_x(p2mfn), lp2mfn);
-    }
-
-    spin_unlock(&d->page_alloc_lock);
-
-    /* Audit part two: walk the domain's p2m table, checking the entries. */
+    /* Audit part one: walk the domain's p2m table, checking the entries. */
     if ( pagetable_get_pfn(p2m_get_pagetable(p2m)) != 0 )
     {
         l2_pgentry_t *l2e;
@@ -1239,17 +1142,23 @@ void audit_p2m(struct p2m_domain *p2m, i
                entry_count);
         BUG();
     }
-        
-    //P2M_PRINTK("p2m audit complete\n");
-    //if ( orphans_i | orphans_d | mpbad | pmbad )
-    //    P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
-    //                   orphans_i + orphans_d, orphans_i, orphans_d);
-    if ( mpbad | pmbad )
-    {
-        P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
-                   pmbad, mpbad);
-        WARN();
-    }
+
+    return pmbad;
 }
 #endif /* P2M_AUDIT */
 
+/* Set up the p2m function pointers for pagetable format */
+void p2m_pt_init(struct p2m_domain *p2m)
+{
+    p2m->set_entry = p2m_set_entry;
+    p2m->get_entry = p2m_gfn_to_mfn;
+    p2m->change_entry_type_global = p2m_change_type_global;
+    p2m->write_p2m_entry = paging_write_p2m_entry;
+#if P2M_AUDIT
+    p2m->audit_p2m = p2m_pt_audit_p2m;
+#else
+    p2m->audit_p2m = NULL;
+#endif
+}
+
+
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -439,9 +439,7 @@ guest_physmap_remove_page(struct domain 
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
     p2m_remove_page(p2m, gfn, mfn, page_order);
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 }
 
@@ -482,7 +480,6 @@ guest_physmap_add_entry(struct domain *d
         return rc;
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 0);
 
     P2M_DEBUG("adding gfn=%#lx mfn=%#lx\n", gfn, mfn);
 
@@ -566,7 +563,6 @@ guest_physmap_add_entry(struct domain *d
         }
     }
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
     return rc;
@@ -656,7 +652,6 @@ set_mmio_p2m_entry(struct domain *d, uns
 
     P2M_DEBUG("set mmio %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_mmio_direct, p2m->default_access);
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
@@ -688,7 +683,6 @@ clear_mmio_p2m_entry(struct domain *d, u
         goto out;
     }
     rc = set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_invalid, p2m->default_access);
-    audit_p2m(p2m, 1);
 
 out:
     p2m_unlock(p2m);
@@ -785,7 +779,6 @@ int p2m_mem_paging_nominate(struct domai
 
     /* Fix p2m entry */
     set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_out, a);
-    audit_p2m(p2m, 1);
     ret = 0;
 
  out:
@@ -852,7 +845,6 @@ int p2m_mem_paging_evict(struct domain *
 
     /* Remove mapping from p2m table */
     set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_ram_paged, a);
-    audit_p2m(p2m, 1);
 
     /* Clear content before returning the page to Xen */
     scrub_one_page(page);
@@ -946,7 +938,6 @@ void p2m_mem_paging_populate(struct doma
             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
 
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
-        audit_p2m(p2m, 1);
     }
     p2m_unlock(p2m);
 
@@ -1014,7 +1005,6 @@ int p2m_mem_paging_prep(struct domain *d
 
     /* Fix p2m mapping */
     set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
-    audit_p2m(p2m, 1);
 
     atomic_dec(&d->paged_pages);
 
@@ -1065,7 +1055,6 @@ void p2m_mem_paging_resume(struct domain
                             paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, 
                             a);
             set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
-            audit_p2m(p2m, 1);
         }
         p2m_unlock(p2m);
     }
@@ -1427,6 +1416,119 @@ unsigned long paging_gva_to_gfn(struct v
     return hostmode->gva_to_gfn(v, hostp2m, va, pfec);
 }
 
+/*** Audit ***/
+
+#if P2M_AUDIT
+void audit_p2m(struct domain *d,
+                uint64_t *orphans_debug,
+                uint64_t *orphans_invalid,
+                uint64_t *m2p_bad,
+                uint64_t *p2m_bad)
+{
+    struct page_info *page;
+    struct domain *od;
+    unsigned long mfn, gfn;
+    mfn_t p2mfn;
+    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    p2m_access_t p2ma;
+    p2m_type_t type;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    if ( !paging_mode_translate(d) )
+        goto out_p2m_audit;
+
+    P2M_PRINTK("p2m audit starts\n");
+
+    p2m_lock(p2m);
+
+    if (p2m->audit_p2m)
+        pmbad = p2m->audit_p2m(p2m);
+
+    /* Audit part two: walk the domain's page allocation list, checking
+     * the m2p entries. */
+    spin_lock(&d->page_alloc_lock);
+    page_list_for_each ( page, &d->page_list )
+    {
+        mfn = mfn_x(page_to_mfn(page));
+
+        P2M_PRINTK("auditing guest page, mfn=%#lx\n", mfn);
+
+        od = page_get_owner(page);
+
+        if ( od != d )
+        {
+            P2M_PRINTK("wrong owner %#lx -> %p(%u) != %p(%u)\n",
+                       mfn, od, (od?od->domain_id:-1), d, d->domain_id);
+            continue;
+        }
+
+        gfn = get_gpfn_from_mfn(mfn);
+        if ( gfn == INVALID_M2P_ENTRY )
+        {
+            orphans_i++;
+            P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
+                           mfn);
+            continue;
+        }
+
+        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
+        {
+            orphans_d++;
+            P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
+                           mfn);
+            continue;
+        }
+
+        if ( gfn == SHARED_M2P_ENTRY )
+        {
+            P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
+                    mfn);
+            continue;
+        }
+
+        p2mfn = get_gfn_type_access(p2m, gfn, &type, &p2ma, p2m_query, NULL);
+        if ( mfn_x(p2mfn) != mfn )
+        {
+            mpbad++;
+            P2M_PRINTK("map mismatch mfn %#lx -> gfn %#lx -> mfn %#lx"
+                       " (-> gfn %#lx)\n",
+                       mfn, gfn, mfn_x(p2mfn),
+                       (mfn_valid(p2mfn)
+                        ? get_gpfn_from_mfn(mfn_x(p2mfn))
+                        : -1u));
+            /* This m2p entry is stale: the domain has another frame in
+             * this physical slot.  No great disaster, but for neatness,
+             * blow away the m2p entry. */
+            set_gpfn_from_mfn(mfn, INVALID_M2P_ENTRY);
+        }
+        __put_gfn(p2m, gfn);
+
+        P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx, lp2mfn=%#lx\n",
+                       mfn, gfn, mfn_x(p2mfn), lp2mfn);
+    }
+    spin_unlock(&d->page_alloc_lock);
+
+    p2m_unlock(p2m);
+ 
+    P2M_PRINTK("p2m audit complete\n");
+    if ( orphans_i | orphans_d | mpbad | pmbad )
+        P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
+                       orphans_i + orphans_d, orphans_i, orphans_d);
+    if ( mpbad | pmbad )
+    {
+        P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
+                   pmbad, mpbad);
+        WARN();
+    }
+
+out_p2m_audit:
+    *orphans_debug      = (uint64_t) orphans_d;
+    *orphans_invalid    = (uint64_t) orphans_i;
+    *m2p_bad            = (uint64_t) mpbad;
+    *p2m_bad            = (uint64_t) pmbad;
+}
+#endif /* P2M_AUDIT */
+
 /*
  * Local variables:
  * mode: C
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -245,6 +245,7 @@ struct p2m_domain {
                                           unsigned long gfn, l1_pgentry_t *p,
                                           mfn_t table_mfn, l1_pgentry_t new,
                                           unsigned int level);
+    long               (*audit_p2m)(struct p2m_domain *p2m);
 
     /* Default P2M access type for each page in the the domain: new pages,
      * swapped in pages, cleared pages, and pages that are ambiquously
@@ -559,13 +560,15 @@ int set_p2m_entry(struct p2m_domain *p2m
 extern void p2m_pt_init(struct p2m_domain *p2m);
 
 /* Debugging and auditing of the P2M code? */
-#define P2M_AUDIT     0
+#define P2M_AUDIT     1
 #define P2M_DEBUGGING 0
 
 #if P2M_AUDIT
-extern void audit_p2m(struct p2m_domain *p2m, int strict_m2p);
-#else
-# define audit_p2m(_p2m, _m2p) do { (void)(_p2m),(_m2p); } while (0)
+extern void audit_p2m(struct domain *d,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,
+                        uint64_t *p2m_bad);
 #endif /* P2M_AUDIT */
 
 /* Printouts */
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -800,6 +800,16 @@ struct xen_domctl_mem_sharing_op {
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_sharing_op_t);
 
+struct xen_domctl_audit_p2m {
+    /* OUT error counts */
+    uint64_t orphans_debug;
+    uint64_t orphans_invalid;
+    uint64_t m2p_bad;
+    uint64_t p2m_bad;
+};
+typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -898,6 +908,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_setvcpuextstate               62
 #define XEN_DOMCTL_getvcpuextstate               63
 #define XEN_DOMCTL_set_access_required           64
+#define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -951,6 +962,7 @@ struct xen_domctl {
         struct xen_domctl_vcpuextstate      vcpuextstate;
 #endif
         struct xen_domctl_set_access_required access_required;
+        struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:14:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcsG-0000WJ-H3; Thu, 24 Nov 2011 17:14:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTcsD-0000VN-TW
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:14:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322154817!5591640!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11322 invoked from network); 24 Nov 2011 17:13:37 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-2.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 17:13:37 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id E831B300061;
	Thu, 24 Nov 2011 09:13:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=Js82p9sHFfPGCxtRTKdaeMMHklSuEP+crb3o10GzoEtW
	FWVjfmAbErZNTGzDFIAcD4N3trOhqtX3E5gClLbKEFadoGvoSWRczBlyQJRzdN3w
	SQmNAWb+exwbn1b76EjQCt0/12p7+ixuLveRqLxKdodGTiJYYsjQy044p9pEnSI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=PI8HIz8w5tyBubTefw0a+SIOF7U=; b=dGLHErte3e2
	ddtyxfi4HVX2ltdD0FwJy3hhVGl9dNTUYgx/XEgW13CpLoQojc+dZz+oT0VvrOT3
	+xnTB0KWRLuzB96a1B31O4zkjxMvcrOxVbG7t6qDVYa33tg2olUNSrhVi8h5vkbm
	dC7ZzbfqB+Xaj1qbzyPG7TQtHH9Y7vZw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id E8EA930007B; 
	Thu, 24 Nov 2011 09:13:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f964ff59ca6cfc7902037ccca6d9e93569276600
Message-Id: <f964ff59ca6cfc790203.1322154759@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322154758@xdev.gridcentric.ca>
References: <patchbomb.1322154758@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 12:12:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/domctl.c       |   30 +++++++++
 xen/arch/x86/mm/p2m-ept.c   |    1 +
 xen/arch/x86/mm/p2m-pod.c   |    5 -
 xen/arch/x86/mm/p2m-pt.c    |  137 +++++++------------------------------------
 xen/arch/x86/mm/p2m.c       |  124 ++++++++++++++++++++++++++++++++++++---
 xen/include/asm-x86/p2m.h   |   11 ++-
 xen/include/public/domctl.h |   12 +++
 7 files changed, 186 insertions(+), 134 deletions(-)


The p2m audit code doesn't even compile, let alone work. It also
partially supports ept. Make it:

- compile
- lay groundwork for eventual ept support
- move out of the way of all calls and turn it into a domctl. It's
  obviously not being used by anybody presently.
- enable it via said domctl

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 9e44fd6e4955 -r f964ff59ca6c xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1449,6 +1449,36 @@ long arch_do_domctl(
     break;
 #endif /* __x86_64__ */
 
+    case XEN_DOMCTL_audit_p2m:
+    {
+        struct domain *d;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(domctl->domain);
+        if ( d != NULL )
+        {
+            ret = -EPERM;
+            if ( (domctl->domain != DOMID_SELF) &&
+                 (d != current->domain) &&
+                 (IS_PRIV_FOR(current->domain, d)) )
+            {
+#if P2M_AUDIT
+                audit_p2m(d,
+                          &domctl->u.audit_p2m.orphans_debug,
+                          &domctl->u.audit_p2m.orphans_invalid,
+                          &domctl->u.audit_p2m.m2p_bad,
+                          &domctl->u.audit_p2m.p2m_bad);
+                ret = (copy_to_guest(u_domctl, domctl, 1)) ?
+                        -EFAULT : 0;
+#else
+                ret = -ENOSYS;
+#endif /* P2M_AUDIT */
+            }
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     case XEN_DOMCTL_set_access_required:
     {
         struct domain *d;
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -817,6 +817,7 @@ void ept_p2m_init(struct p2m_domain *p2m
     p2m->set_entry = ept_set_entry;
     p2m->get_entry = ept_get_entry;
     p2m->change_entry_type_global = ept_change_entry_type_global;
+    p2m->audit_p2m = NULL;
 }
 
 static void ept_dump_p2m_table(unsigned char key)
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -522,7 +522,6 @@ p2m_pod_decrease_reservation(struct doma
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
 
     if ( unlikely(d->is_dying) )
         goto out_unlock;
@@ -616,7 +615,6 @@ out_entry_check:
     }
 
 out_unlock:
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
 out:
@@ -986,7 +984,6 @@ p2m_pod_demand_populate(struct p2m_domai
          */
         set_p2m_entry(p2m, gfn_aligned, _mfn(0), PAGE_ORDER_2M,
                       p2m_populate_on_demand, p2m->default_access);
-        audit_p2m(p2m, 1);
         return 0;
     }
 
@@ -1108,7 +1105,6 @@ guest_physmap_mark_populate_on_demand(st
         return rc;
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
 
     P2M_DEBUG("mark pod gfn=%#lx\n", gfn);
 
@@ -1142,7 +1138,6 @@ guest_physmap_mark_populate_on_demand(st
         BUG_ON(p2m->pod.entry_count < 0);
     }
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
 out:
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -483,7 +483,6 @@ static int p2m_pod_check_and_populate(st
     /* This is called from the p2m lookups, which can happen with or 
      * without the lock hed. */
     p2m_lock_recursive(p2m);
-    audit_p2m(p2m, 1);
 
     /* Check to make sure this is still PoD */
     if ( p2m_flags_to_type(l1e_get_flags(*p2m_entry)) != p2m_populate_on_demand )
@@ -494,7 +493,6 @@ static int p2m_pod_check_and_populate(st
 
     r = p2m_pod_demand_populate(p2m, gfn, order, q);
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
     return r;
@@ -975,118 +973,23 @@ static void p2m_change_type_global(struc
 
 }
 
-/* Set up the p2m function pointers for pagetable format */
-void p2m_pt_init(struct p2m_domain *p2m)
+#if P2M_AUDIT
+long p2m_pt_audit_p2m(struct p2m_domain *p2m)
 {
-    p2m->set_entry = p2m_set_entry;
-    p2m->get_entry = p2m_gfn_to_mfn;
-    p2m->change_entry_type_global = p2m_change_type_global;
-    p2m->write_p2m_entry = paging_write_p2m_entry;
-}
-
-
-#if P2M_AUDIT
-/* strict_m2p == 0 allows m2p mappings that don'#t match the p2m. 
- * It's intended for add_to_physmap, when the domain has just been allocated 
- * new mfns that might have stale m2p entries from previous owners */
-void audit_p2m(struct p2m_domain *p2m, int strict_m2p)
-{
-    struct page_info *page;
-    struct domain *od;
-    unsigned long mfn, gfn, m2pfn, lp2mfn = 0;
     int entry_count = 0;
-    mfn_t p2mfn;
-    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    unsigned long pmbad = 0;
+    unsigned long mfn, gfn, m2pfn;
     int test_linear;
-    p2m_type_t type;
     struct domain *d = p2m->domain;
 
-    if ( !paging_mode_translate(d) )
-        return;
-
-    //P2M_PRINTK("p2m audit starts\n");
+    ASSERT(p2m_locked_by_me(p2m));
 
     test_linear = ( (d == current->domain)
                     && !pagetable_is_null(current->arch.monitor_table) );
     if ( test_linear )
         flush_tlb_local();
 
-    spin_lock(&d->page_alloc_lock);
-
-    /* Audit part one: walk the domain's page allocation list, checking
-     * the m2p entries. */
-    page_list_for_each ( page, &d->page_list )
-    {
-        mfn = mfn_x(page_to_mfn(page));
-
-        // P2M_PRINTK("auditing guest page, mfn=%#lx\n", mfn);
-
-        od = page_get_owner(page);
-
-        if ( od != d )
-        {
-            P2M_PRINTK("wrong owner %#lx -> %p(%u) != %p(%u)\n",
-                       mfn, od, (od?od->domain_id:-1), d, d->domain_id);
-            continue;
-        }
-
-        gfn = get_gpfn_from_mfn(mfn);
-        if ( gfn == INVALID_M2P_ENTRY )
-        {
-            orphans_i++;
-            //P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
-            //               mfn);
-            continue;
-        }
-
-        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
-        {
-            orphans_d++;
-            //P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
-            //               mfn);
-            continue;
-        }
-
-        if ( gfn == SHARED_M2P_ENTRY )
-        {
-            P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
-                    mfn);
-            continue;
-        }
-
-        p2mfn = gfn_to_mfn_type_p2m(p2m, gfn, &type, p2m_query);
-        if ( strict_m2p && mfn_x(p2mfn) != mfn )
-        {
-            mpbad++;
-            P2M_PRINTK("map mismatch mfn %#lx -> gfn %#lx -> mfn %#lx"
-                       " (-> gfn %#lx)\n",
-                       mfn, gfn, mfn_x(p2mfn),
-                       (mfn_valid(p2mfn)
-                        ? get_gpfn_from_mfn(mfn_x(p2mfn))
-                        : -1u));
-            /* This m2p entry is stale: the domain has another frame in
-             * this physical slot.  No great disaster, but for neatness,
-             * blow away the m2p entry. */
-            set_gpfn_from_mfn(mfn, INVALID_M2P_ENTRY);
-        }
-
-        if ( test_linear && (gfn <= p2m->max_mapped_pfn) )
-        {
-            lp2mfn = mfn_x(gfn_to_mfn_type_p2m(p2m, gfn, &type, p2m_query));
-            if ( lp2mfn != mfn_x(p2mfn) )
-            {
-                P2M_PRINTK("linear mismatch gfn %#lx -> mfn %#lx "
-                           "(!= mfn %#lx)\n", gfn, lp2mfn, mfn_x(p2mfn));
-            }
-        }
-
-        // P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx, lp2mfn=%#lx\n",
-        //                mfn, gfn, mfn_x(p2mfn), lp2mfn);
-    }
-
-    spin_unlock(&d->page_alloc_lock);
-
-    /* Audit part two: walk the domain's p2m table, checking the entries. */
+    /* Audit part one: walk the domain's p2m table, checking the entries. */
     if ( pagetable_get_pfn(p2m_get_pagetable(p2m)) != 0 )
     {
         l2_pgentry_t *l2e;
@@ -1239,17 +1142,23 @@ void audit_p2m(struct p2m_domain *p2m, i
                entry_count);
         BUG();
     }
-        
-    //P2M_PRINTK("p2m audit complete\n");
-    //if ( orphans_i | orphans_d | mpbad | pmbad )
-    //    P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
-    //                   orphans_i + orphans_d, orphans_i, orphans_d);
-    if ( mpbad | pmbad )
-    {
-        P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
-                   pmbad, mpbad);
-        WARN();
-    }
+
+    return pmbad;
 }
 #endif /* P2M_AUDIT */
 
+/* Set up the p2m function pointers for pagetable format */
+void p2m_pt_init(struct p2m_domain *p2m)
+{
+    p2m->set_entry = p2m_set_entry;
+    p2m->get_entry = p2m_gfn_to_mfn;
+    p2m->change_entry_type_global = p2m_change_type_global;
+    p2m->write_p2m_entry = paging_write_p2m_entry;
+#if P2M_AUDIT
+    p2m->audit_p2m = p2m_pt_audit_p2m;
+#else
+    p2m->audit_p2m = NULL;
+#endif
+}
+
+
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -439,9 +439,7 @@ guest_physmap_remove_page(struct domain 
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
     p2m_remove_page(p2m, gfn, mfn, page_order);
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 }
 
@@ -482,7 +480,6 @@ guest_physmap_add_entry(struct domain *d
         return rc;
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 0);
 
     P2M_DEBUG("adding gfn=%#lx mfn=%#lx\n", gfn, mfn);
 
@@ -566,7 +563,6 @@ guest_physmap_add_entry(struct domain *d
         }
     }
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
     return rc;
@@ -656,7 +652,6 @@ set_mmio_p2m_entry(struct domain *d, uns
 
     P2M_DEBUG("set mmio %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_mmio_direct, p2m->default_access);
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
@@ -688,7 +683,6 @@ clear_mmio_p2m_entry(struct domain *d, u
         goto out;
     }
     rc = set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_invalid, p2m->default_access);
-    audit_p2m(p2m, 1);
 
 out:
     p2m_unlock(p2m);
@@ -785,7 +779,6 @@ int p2m_mem_paging_nominate(struct domai
 
     /* Fix p2m entry */
     set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_out, a);
-    audit_p2m(p2m, 1);
     ret = 0;
 
  out:
@@ -852,7 +845,6 @@ int p2m_mem_paging_evict(struct domain *
 
     /* Remove mapping from p2m table */
     set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_ram_paged, a);
-    audit_p2m(p2m, 1);
 
     /* Clear content before returning the page to Xen */
     scrub_one_page(page);
@@ -946,7 +938,6 @@ void p2m_mem_paging_populate(struct doma
             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
 
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
-        audit_p2m(p2m, 1);
     }
     p2m_unlock(p2m);
 
@@ -1014,7 +1005,6 @@ int p2m_mem_paging_prep(struct domain *d
 
     /* Fix p2m mapping */
     set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
-    audit_p2m(p2m, 1);
 
     atomic_dec(&d->paged_pages);
 
@@ -1065,7 +1055,6 @@ void p2m_mem_paging_resume(struct domain
                             paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, 
                             a);
             set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
-            audit_p2m(p2m, 1);
         }
         p2m_unlock(p2m);
     }
@@ -1427,6 +1416,119 @@ unsigned long paging_gva_to_gfn(struct v
     return hostmode->gva_to_gfn(v, hostp2m, va, pfec);
 }
 
+/*** Audit ***/
+
+#if P2M_AUDIT
+void audit_p2m(struct domain *d,
+                uint64_t *orphans_debug,
+                uint64_t *orphans_invalid,
+                uint64_t *m2p_bad,
+                uint64_t *p2m_bad)
+{
+    struct page_info *page;
+    struct domain *od;
+    unsigned long mfn, gfn;
+    mfn_t p2mfn;
+    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    p2m_access_t p2ma;
+    p2m_type_t type;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    if ( !paging_mode_translate(d) )
+        goto out_p2m_audit;
+
+    P2M_PRINTK("p2m audit starts\n");
+
+    p2m_lock(p2m);
+
+    if (p2m->audit_p2m)
+        pmbad = p2m->audit_p2m(p2m);
+
+    /* Audit part two: walk the domain's page allocation list, checking
+     * the m2p entries. */
+    spin_lock(&d->page_alloc_lock);
+    page_list_for_each ( page, &d->page_list )
+    {
+        mfn = mfn_x(page_to_mfn(page));
+
+        P2M_PRINTK("auditing guest page, mfn=%#lx\n", mfn);
+
+        od = page_get_owner(page);
+
+        if ( od != d )
+        {
+            P2M_PRINTK("wrong owner %#lx -> %p(%u) != %p(%u)\n",
+                       mfn, od, (od?od->domain_id:-1), d, d->domain_id);
+            continue;
+        }
+
+        gfn = get_gpfn_from_mfn(mfn);
+        if ( gfn == INVALID_M2P_ENTRY )
+        {
+            orphans_i++;
+            P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
+                           mfn);
+            continue;
+        }
+
+        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
+        {
+            orphans_d++;
+            P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
+                           mfn);
+            continue;
+        }
+
+        if ( gfn == SHARED_M2P_ENTRY )
+        {
+            P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
+                    mfn);
+            continue;
+        }
+
+        p2mfn = get_gfn_type_access(p2m, gfn, &type, &p2ma, p2m_query, NULL);
+        if ( mfn_x(p2mfn) != mfn )
+        {
+            mpbad++;
+            P2M_PRINTK("map mismatch mfn %#lx -> gfn %#lx -> mfn %#lx"
+                       " (-> gfn %#lx)\n",
+                       mfn, gfn, mfn_x(p2mfn),
+                       (mfn_valid(p2mfn)
+                        ? get_gpfn_from_mfn(mfn_x(p2mfn))
+                        : -1u));
+            /* This m2p entry is stale: the domain has another frame in
+             * this physical slot.  No great disaster, but for neatness,
+             * blow away the m2p entry. */
+            set_gpfn_from_mfn(mfn, INVALID_M2P_ENTRY);
+        }
+        __put_gfn(p2m, gfn);
+
+        P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx, lp2mfn=%#lx\n",
+                       mfn, gfn, mfn_x(p2mfn), lp2mfn);
+    }
+    spin_unlock(&d->page_alloc_lock);
+
+    p2m_unlock(p2m);
+ 
+    P2M_PRINTK("p2m audit complete\n");
+    if ( orphans_i | orphans_d | mpbad | pmbad )
+        P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
+                       orphans_i + orphans_d, orphans_i, orphans_d);
+    if ( mpbad | pmbad )
+    {
+        P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
+                   pmbad, mpbad);
+        WARN();
+    }
+
+out_p2m_audit:
+    *orphans_debug      = (uint64_t) orphans_d;
+    *orphans_invalid    = (uint64_t) orphans_i;
+    *m2p_bad            = (uint64_t) mpbad;
+    *p2m_bad            = (uint64_t) pmbad;
+}
+#endif /* P2M_AUDIT */
+
 /*
  * Local variables:
  * mode: C
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -245,6 +245,7 @@ struct p2m_domain {
                                           unsigned long gfn, l1_pgentry_t *p,
                                           mfn_t table_mfn, l1_pgentry_t new,
                                           unsigned int level);
+    long               (*audit_p2m)(struct p2m_domain *p2m);
 
     /* Default P2M access type for each page in the the domain: new pages,
      * swapped in pages, cleared pages, and pages that are ambiquously
@@ -559,13 +560,15 @@ int set_p2m_entry(struct p2m_domain *p2m
 extern void p2m_pt_init(struct p2m_domain *p2m);
 
 /* Debugging and auditing of the P2M code? */
-#define P2M_AUDIT     0
+#define P2M_AUDIT     1
 #define P2M_DEBUGGING 0
 
 #if P2M_AUDIT
-extern void audit_p2m(struct p2m_domain *p2m, int strict_m2p);
-#else
-# define audit_p2m(_p2m, _m2p) do { (void)(_p2m),(_m2p); } while (0)
+extern void audit_p2m(struct domain *d,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,
+                        uint64_t *p2m_bad);
 #endif /* P2M_AUDIT */
 
 /* Printouts */
diff -r 9e44fd6e4955 -r f964ff59ca6c xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -800,6 +800,16 @@ struct xen_domctl_mem_sharing_op {
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_sharing_op_t);
 
+struct xen_domctl_audit_p2m {
+    /* OUT error counts */
+    uint64_t orphans_debug;
+    uint64_t orphans_invalid;
+    uint64_t m2p_bad;
+    uint64_t p2m_bad;
+};
+typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -898,6 +908,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_setvcpuextstate               62
 #define XEN_DOMCTL_getvcpuextstate               63
 #define XEN_DOMCTL_set_access_required           64
+#define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -951,6 +962,7 @@ struct xen_domctl {
         struct xen_domctl_vcpuextstate      vcpuextstate;
 #endif
         struct xen_domctl_set_access_required access_required;
+        struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:15:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:15:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcst-0000iN-Jz; Thu, 24 Nov 2011 17:14:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTcsr-0000gE-Nb
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:14:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322154858!2918622!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17961 invoked from network); 24 Nov 2011 17:14:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:14:18 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:14:18 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 17:14:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20174.30225.546593.786234@mariner.uk.xensource.com>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
	<20174.30225.546593.786234@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 17:14:17 +0000
Message-ID: <1322154857.9567.57.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 16:51 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [xen-unstable test] 10020: regressions - FAIL"):
> > I think you need to install libaio-dev.
> 
> Yes, thanks.  I have submitted that to the auto-tester which (when it
> passes the meta-auto-test) ought to fix it.
> 
> IWBNI we had a sort-of-machine-readable list of Debian packages to
> install in some README; then I could use that.  It wouldn't break
> every time we add a dependency and also would make sure the build docs
> remain up to date.

There's a list of dependencies in the toplevel README, including Debian
package names in many cases, would adding some sort of markup to that be
sufficient?

> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:15:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:15:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTcst-0000iN-Jz; Thu, 24 Nov 2011 17:14:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTcsr-0000gE-Nb
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:14:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322154858!2918622!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17961 invoked from network); 24 Nov 2011 17:14:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:14:18 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:14:18 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 17:14:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20174.30225.546593.786234@mariner.uk.xensource.com>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
	<20174.30225.546593.786234@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 17:14:17 +0000
Message-ID: <1322154857.9567.57.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 16:51 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [xen-unstable test] 10020: regressions - FAIL"):
> > I think you need to install libaio-dev.
> 
> Yes, thanks.  I have submitted that to the auto-tester which (when it
> passes the meta-auto-test) ought to fix it.
> 
> IWBNI we had a sort-of-machine-readable list of Debian packages to
> install in some README; then I could use that.  It wouldn't break
> every time we add a dependency and also would make sure the build docs
> remain up to date.

There's a list of dependencies in the toplevel README, including Debian
package names in many cases, would adding some sort of markup to that be
sufficient?

> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:15:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:15:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTct9-0000mc-21; Thu, 24 Nov 2011 17:15:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTct8-0000l8-9D
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:15:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322154874!2907818!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3050 invoked from network); 24 Nov 2011 17:14:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:14:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118374"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:14:34 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 17:14:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4ECE8656020000780006314D@nat28.tlf.novell.com>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
	<4ECE8656020000780006314D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 17:14:33 +0000
Message-ID: <1322154873.9567.58.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:00 +0000, Jan Beulich wrote:
> >>> On 24.11.11 at 17:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2011-11-24 at 16:23 +0000, Ian Jackson wrote:
> >> In file included from block-aio.c:45:
> >> tapaio.h:42: error: expected specifier-qualifier-list before 'io_context_t'
> > 
> > Further up there is a 
> > block-aio.c:36:20: error: libaio.h: No such file or directory
> > 
> > I think you need to install libaio-dev.
> 
> But if there's a new dependency, should that be verified in tools/check/,
> so that things fail early?

Yes, I also forgot to patch README. I'll look into it tomorrow.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:15:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:15:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTct9-0000mc-21; Thu, 24 Nov 2011 17:15:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTct8-0000l8-9D
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:15:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322154874!2907818!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3050 invoked from network); 24 Nov 2011 17:14:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:14:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118374"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:14:34 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 17:14:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4ECE8656020000780006314D@nat28.tlf.novell.com>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
	<4ECE8656020000780006314D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 17:14:33 +0000
Message-ID: <1322154873.9567.58.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:00 +0000, Jan Beulich wrote:
> >>> On 24.11.11 at 17:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2011-11-24 at 16:23 +0000, Ian Jackson wrote:
> >> In file included from block-aio.c:45:
> >> tapaio.h:42: error: expected specifier-qualifier-list before 'io_context_t'
> > 
> > Further up there is a 
> > block-aio.c:36:20: error: libaio.h: No such file or directory
> > 
> > I think you need to install libaio-dev.
> 
> But if there's a new dependency, should that be verified in tools/check/,
> so that things fail early?

Yes, I also forgot to patch README. I'll look into it tomorrow.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:22:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTd0V-0001b5-5E; Thu, 24 Nov 2011 17:22:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTd0T-0001b0-S6
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:22:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322155302!58576715!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15646 invoked from network); 24 Nov 2011 17:21:42 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 17:21:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTd03-000LfR-4w; Thu, 24 Nov 2011 17:22:15 +0000
Date: Thu, 24 Nov 2011 17:22:15 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124172215.GQ77868@ocelot.phlegethon.org>
References: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
	<8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 09:09 -0800 on 24 Nov (1322125786), Andres Lagar-Cavilla wrote:
> > Date: Thu, 24 Nov 2011 11:38:02 +0000
> > From: Tim Deegan <tim@xen.org>
> > To: Olaf Hering <olaf@aepfle.de>
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state
> > 	read-only
> > Message-ID: <20111124113802.GB77868@ocelot.phlegethon.org>
> > Content-Type: text/plain; charset=iso-8859-1
> >
> > At 17:53 +0100 on 14 Nov (1321293182), Olaf Hering wrote:
> >>
> >> I was wondering why ept_p2m_type_to_flags() removes all permissions from
> >> a gfn in state p2m_ram_paging_out. If the guest happens to read or
> >> execute from that page while the pager writes that gfn to disk, wouldnt
> >> it be enough to remove the write bit to prevent writes from the guest?
> >> If the page is read-only the guest could continue to make progress until
> >> the gfn is really evicted and the p2mt changes to p2m_ram_paged.
> >>
> >> I havent actually tried the patch below, but is there any reason it
> >> would break the guest?
> >
> > As long as we change the p2m type before scrubbing or freeing the page,
> > that seems like it shuold be fine.
> 
> Is this a good idea? If the guest is accessing the page, then paging out
> should stop immediately. We're risking complex races for a tiny tiny gain.

I don't think that this would introduce any new races, but yes - this is
probably a hint that this page is a poor candidate to be paged out.
We might as well abandon the page-out rather than probably having to
page it back in immediately.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:22:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTd0V-0001b5-5E; Thu, 24 Nov 2011 17:22:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTd0T-0001b0-S6
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:22:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322155302!58576715!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15646 invoked from network); 24 Nov 2011 17:21:42 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 17:21:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTd03-000LfR-4w; Thu, 24 Nov 2011 17:22:15 +0000
Date: Thu, 24 Nov 2011 17:22:15 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124172215.GQ77868@ocelot.phlegethon.org>
References: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
	<8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 09:09 -0800 on 24 Nov (1322125786), Andres Lagar-Cavilla wrote:
> > Date: Thu, 24 Nov 2011 11:38:02 +0000
> > From: Tim Deegan <tim@xen.org>
> > To: Olaf Hering <olaf@aepfle.de>
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state
> > 	read-only
> > Message-ID: <20111124113802.GB77868@ocelot.phlegethon.org>
> > Content-Type: text/plain; charset=iso-8859-1
> >
> > At 17:53 +0100 on 14 Nov (1321293182), Olaf Hering wrote:
> >>
> >> I was wondering why ept_p2m_type_to_flags() removes all permissions from
> >> a gfn in state p2m_ram_paging_out. If the guest happens to read or
> >> execute from that page while the pager writes that gfn to disk, wouldnt
> >> it be enough to remove the write bit to prevent writes from the guest?
> >> If the page is read-only the guest could continue to make progress until
> >> the gfn is really evicted and the p2mt changes to p2m_ram_paged.
> >>
> >> I havent actually tried the patch below, but is there any reason it
> >> would break the guest?
> >
> > As long as we change the p2m type before scrubbing or freeing the page,
> > that seems like it shuold be fine.
> 
> Is this a good idea? If the guest is accessing the page, then paging out
> should stop immediately. We're risking complex races for a tiny tiny gain.

I don't think that this would introduce any new races, but yes - this is
probably a hint that this page is a poor candidate to be paged out.
We might as well abandon the page-out rather than probably having to
page it back in immediately.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:23:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:23:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTd11-0001cq-JB; Thu, 24 Nov 2011 17:23:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTd0z-0001cP-WC
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:23:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322155362!4492823!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22835 invoked from network); 24 Nov 2011 17:22:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:22:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:22:41 +0000
Date: Thu, 24 Nov 2011 17:23:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1322150893-887-2-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1111241720410.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-2-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/5] vl.c: Do not save RAM state when Xen is
	used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 24 Nov 2011, Anthony PERARD wrote:
> In Xen case, the guest RAM is not handle by QEMU, and it is saved by Xen tools.
> So, we just avoid to register the RAM save state handler.

Maybe we can unregister these handlers in the Xen specific
initialization code, before we start receiving save/restore requests,
otherwise we could have a nasty race condition.


> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  vl.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/vl.c b/vl.c
> index f5afed4..e7dced2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3273,8 +3273,10 @@ int main(int argc, char **argv, char **envp)
>      default_drive(default_sdcard, snapshot, machine->use_scsi,
>                    IF_SD, 0, SD_OPTS);
>  
> -    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> -                         ram_load, NULL);
> +    if (!xen_enabled()) {
> +        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> +                             ram_load, NULL);
> +    }
>  
>      if (nb_numa_nodes > 0) {
>          int i;
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:23:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:23:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTd11-0001cq-JB; Thu, 24 Nov 2011 17:23:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTd0z-0001cP-WC
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:23:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322155362!4492823!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22835 invoked from network); 24 Nov 2011 17:22:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:22:42 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:22:41 +0000
Date: Thu, 24 Nov 2011 17:23:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1322150893-887-2-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1111241720410.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-2-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/5] vl.c: Do not save RAM state when Xen is
	used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 24 Nov 2011, Anthony PERARD wrote:
> In Xen case, the guest RAM is not handle by QEMU, and it is saved by Xen tools.
> So, we just avoid to register the RAM save state handler.

Maybe we can unregister these handlers in the Xen specific
initialization code, before we start receiving save/restore requests,
otherwise we could have a nasty race condition.


> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  vl.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/vl.c b/vl.c
> index f5afed4..e7dced2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3273,8 +3273,10 @@ int main(int argc, char **argv, char **envp)
>      default_drive(default_sdcard, snapshot, machine->use_scsi,
>                    IF_SD, 0, SD_OPTS);
>  
> -    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> -                         ram_load, NULL);
> +    if (!xen_enabled()) {
> +        register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
> +                             ram_load, NULL);
> +    }
>  
>      if (nb_numa_nodes > 0) {
>          int i;
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:26:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:26:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTd3v-0001tD-6u; Thu, 24 Nov 2011 17:26:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTd3u-0001sR-4r
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:26:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322155542!4850019!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6667 invoked from network); 24 Nov 2011 17:25:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:25:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:25:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:25:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTd3O-00078a-GF; Thu, 24 Nov 2011 17:25:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTd3O-0004Yj-FW;
	Thu, 24 Nov 2011 17:25:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.32278.467007.484327@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:25:42 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322154751.9567.56.camel@dagon.hellion.org.uk>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
	<20174.31130.609126.117709@mariner.uk.xensource.com>
	<1322154751.9567.56.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into
 final	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final	filename"):
> On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote:
> > We don't want to leave half-generated documents lying around which
> > aren't fixed by "make", regardless of further dependencies, surely ?
> 
> Doesn't make automatically delete the targets if the command fails?

Crash-only software.  Or in other words, to write reliable software,
do not rely on actions which are supposed to happen on error cleanup
or exit.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:26:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:26:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTd3v-0001tD-6u; Thu, 24 Nov 2011 17:26:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTd3u-0001sR-4r
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:26:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322155542!4850019!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6667 invoked from network); 24 Nov 2011 17:25:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:25:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:25:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:25:42 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTd3O-00078a-GF; Thu, 24 Nov 2011 17:25:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTd3O-0004Yj-FW;
	Thu, 24 Nov 2011 17:25:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.32278.467007.484327@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:25:42 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322154751.9567.56.camel@dagon.hellion.org.uk>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
	<20174.31130.609126.117709@mariner.uk.xensource.com>
	<1322154751.9567.56.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into
 final	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final	filename"):
> On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote:
> > We don't want to leave half-generated documents lying around which
> > aren't fixed by "make", regardless of further dependencies, surely ?
> 
> Doesn't make automatically delete the targets if the command fails?

Crash-only software.  Or in other words, to write reliable software,
do not rely on actions which are supposed to happen on error cleanup
or exit.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:31:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTd8d-0002Gt-1V; Thu, 24 Nov 2011 17:31:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTd8b-0002Gf-5e
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:31:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322155833!2918916!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4293 invoked from network); 24 Nov 2011 17:30:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:30:34 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:30:33 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 17:30:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <1322154873.9567.58.camel@dagon.hellion.org.uk>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
	<4ECE8656020000780006314D@nat28.tlf.novell.com>
	<1322154873.9567.58.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 17:30:32 +0000
Message-ID: <1322155832.9567.61.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:14 +0000, Ian Campbell wrote:
> On Thu, 2011-11-24 at 17:00 +0000, Jan Beulich wrote:
> > >>> On 24.11.11 at 17:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Thu, 2011-11-24 at 16:23 +0000, Ian Jackson wrote:
> > >> In file included from block-aio.c:45:
> > >> tapaio.h:42: error: expected specifier-qualifier-list before 'io_context_t'
> > > 
> > > Further up there is a 
> > > block-aio.c:36:20: error: libaio.h: No such file or directory
> > > 
> > > I think you need to install libaio-dev.
> > 
> > But if there's a new dependency, should that be verified in tools/check/,
> > so that things fail early?
> 
> Yes, I also forgot to patch README.

Actually I did remember the README (*pats self on back*)

>  I'll look into it tomorrow.

Or now even:

8<-----------------------------------------------------------------

tools: check for libaio unless user has configured CONFIG_SYSTEM_LIBAIO=n

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8fb3fa6218c6 tools/check/Makefile
--- a/tools/check/Makefile	Thu Nov 24 17:05:25 2011 +0000
+++ b/tools/check/Makefile	Thu Nov 24 17:30:17 2011 +0000
@@ -6,6 +6,7 @@
 export LIBXENAPI_BINDINGS
 export CHECK_INCLUDES
 export CHECK_LIB
+export CONFIG_SYSTEM_LIBAIO
 
 .PHONY: all install
 all install: check-build
diff -r 8fb3fa6218c6 tools/check/check_libaio_devel
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/check/check_libaio_devel	Thu Nov 24 17:30:17 2011 +0000
@@ -0,0 +1,11 @@
+#!/bin/sh
+# CHECK-BUILD
+
+. ./funcs.sh
+
+if [ X${CONFIG_SYSTEM_LIBAIO} != X"y" ] ; then
+    exit 0
+fi
+if ! has_header libaio.h ; then
+    fail "can't find libaio headers, install libaio devel package or set CONFIG_SYSTEM_LIBAIO=n"
+fi
diff -r 8fb3fa6218c6 tools/check/check_libaio_lib
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/check/check_libaio_lib	Thu Nov 24 17:30:17 2011 +0000
@@ -0,0 +1,9 @@
+#!/bin/sh
+# CHECK-BUILD CHECK-INSTALL
+
+. ./funcs.sh
+
+if [ X${CONFIG_SYSTEM_LIBAIO} != X"y" ] ; then
+    exit 0
+fi
+has_lib libaio.so || fail "can't find libaio"



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:31:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTd8d-0002Gt-1V; Thu, 24 Nov 2011 17:31:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTd8b-0002Gf-5e
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:31:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322155833!2918916!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4293 invoked from network); 24 Nov 2011 17:30:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:30:34 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:30:33 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 17:30:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <1322154873.9567.58.camel@dagon.hellion.org.uk>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
	<4ECE8656020000780006314D@nat28.tlf.novell.com>
	<1322154873.9567.58.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 17:30:32 +0000
Message-ID: <1322155832.9567.61.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:14 +0000, Ian Campbell wrote:
> On Thu, 2011-11-24 at 17:00 +0000, Jan Beulich wrote:
> > >>> On 24.11.11 at 17:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Thu, 2011-11-24 at 16:23 +0000, Ian Jackson wrote:
> > >> In file included from block-aio.c:45:
> > >> tapaio.h:42: error: expected specifier-qualifier-list before 'io_context_t'
> > > 
> > > Further up there is a 
> > > block-aio.c:36:20: error: libaio.h: No such file or directory
> > > 
> > > I think you need to install libaio-dev.
> > 
> > But if there's a new dependency, should that be verified in tools/check/,
> > so that things fail early?
> 
> Yes, I also forgot to patch README.

Actually I did remember the README (*pats self on back*)

>  I'll look into it tomorrow.

Or now even:

8<-----------------------------------------------------------------

tools: check for libaio unless user has configured CONFIG_SYSTEM_LIBAIO=n

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8fb3fa6218c6 tools/check/Makefile
--- a/tools/check/Makefile	Thu Nov 24 17:05:25 2011 +0000
+++ b/tools/check/Makefile	Thu Nov 24 17:30:17 2011 +0000
@@ -6,6 +6,7 @@
 export LIBXENAPI_BINDINGS
 export CHECK_INCLUDES
 export CHECK_LIB
+export CONFIG_SYSTEM_LIBAIO
 
 .PHONY: all install
 all install: check-build
diff -r 8fb3fa6218c6 tools/check/check_libaio_devel
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/check/check_libaio_devel	Thu Nov 24 17:30:17 2011 +0000
@@ -0,0 +1,11 @@
+#!/bin/sh
+# CHECK-BUILD
+
+. ./funcs.sh
+
+if [ X${CONFIG_SYSTEM_LIBAIO} != X"y" ] ; then
+    exit 0
+fi
+if ! has_header libaio.h ; then
+    fail "can't find libaio headers, install libaio devel package or set CONFIG_SYSTEM_LIBAIO=n"
+fi
diff -r 8fb3fa6218c6 tools/check/check_libaio_lib
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/check/check_libaio_lib	Thu Nov 24 17:30:17 2011 +0000
@@ -0,0 +1,9 @@
+#!/bin/sh
+# CHECK-BUILD CHECK-INSTALL
+
+. ./funcs.sh
+
+if [ X${CONFIG_SYSTEM_LIBAIO} != X"y" ] ; then
+    exit 0
+fi
+has_lib libaio.so || fail "can't find libaio"



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:36:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:36:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdDN-0002Zi-QI; Thu, 24 Nov 2011 17:36:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTdDL-0002ZC-Rx
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:36:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322156128!4503537!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12706 invoked from network); 24 Nov 2011 17:35:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:35:28 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:35:28 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 17:35:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20174.32278.467007.484327@mariner.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
	<20174.31130.609126.117709@mariner.uk.xensource.com>
	<1322154751.9567.56.camel@dagon.hellion.org.uk>
	<20174.32278.467007.484327@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 17:35:27 +0000
Message-ID: <1322156127.9567.63.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into
 final	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:25 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final	filename"):
> > On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote:
> > > We don't want to leave half-generated documents lying around which
> > > aren't fixed by "make", regardless of further dependencies, surely ?
> > 
> > Doesn't make automatically delete the targets if the command fails?
> 
> Crash-only software.  Or in other words, to write reliable software,
> do not rely on actions which are supposed to happen on error cleanup
> or exit.

Also, my experiments suggest that make doesn't do this anyway (perhaps
it's only for implicit intermediaries or something).

Do you want to pickup what you can from this series having dropped this
patch and I'll repost the rest or shall I just repost the whole lot?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:36:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:36:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdDN-0002Zi-QI; Thu, 24 Nov 2011 17:36:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTdDL-0002ZC-Rx
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:36:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322156128!4503537!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12706 invoked from network); 24 Nov 2011 17:35:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:35:28 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:35:28 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 24 Nov 2011 17:35:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20174.32278.467007.484327@mariner.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
	<20174.31130.609126.117709@mariner.uk.xensource.com>
	<1322154751.9567.56.camel@dagon.hellion.org.uk>
	<20174.32278.467007.484327@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Thu, 24 Nov 2011 17:35:27 +0000
Message-ID: <1322156127.9567.63.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into
 final	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:25 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final	filename"):
> > On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote:
> > > We don't want to leave half-generated documents lying around which
> > > aren't fixed by "make", regardless of further dependencies, surely ?
> > 
> > Doesn't make automatically delete the targets if the command fails?
> 
> Crash-only software.  Or in other words, to write reliable software,
> do not rely on actions which are supposed to happen on error cleanup
> or exit.

Also, my experiments suggest that make doesn't do this anyway (perhaps
it's only for implicit intermediaries or something).

Do you want to pickup what you can from this series having dropped this
patch and I'll repost the rest or shall I just repost the whole lot?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:40:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdHq-0002v0-Sp; Thu, 24 Nov 2011 17:40:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTdHp-0002ut-HR
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:40:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322156405!2901789!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26412 invoked from network); 24 Nov 2011 17:40:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:40:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:40:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:40:04 +0000
Date: Thu, 24 Nov 2011 17:40:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1322150893-887-3-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1111241735110.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-3-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen mapcache: Check if a memory space
	has moved.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 24 Nov 2011, Anthony PERARD wrote:
> This patch change the xen_map_cache behavior. Before trying to map a guest
> addr, mapcache will look into the list of range of address that have been moved
> (physmap/set_memory). There is currently one memory space like this, the vram,
> "moved" from were it's allocated to were the guest will look into.
> 
> This help to have a succefull migration.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  xen-all.c      |   19 +++++++++++++++++++
>  xen-mapcache.c |    8 ++++++--
>  xen-mapcache.h |    1 +
>  3 files changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index b5e28ab..40e8869 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -83,6 +83,8 @@ typedef struct XenIOState {
>      Notifier exit;
>  } XenIOState;
>  
> +XenIOState *xen_io_state = NULL;
> +
>  /* Xen specific function for piix pci */
>  
>  int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
> @@ -218,6 +220,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
>      return NULL;
>  }
>  
> +target_phys_addr_t xen_addr_actually_is(target_phys_addr_t start_addr, ram_addr_t size)

I really don't like the name of this function. What about xen_phys_offset_to_gaddr?


> +{
> +    if (xen_io_state) {
> +        target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
> +        XenPhysmap *physmap = NULL;
> +
> +        QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
> +            if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
> +                return physmap->start_addr;
> +            }
> +        }
> +    }
> +
> +    return start_addr;
> +}
> +
>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
>  static int xen_add_to_physmap(XenIOState *state,
>                                target_phys_addr_t start_addr,
> @@ -891,6 +909,7 @@ int xen_hvm_init(void)
>      XenIOState *state;
>  
>      state = g_malloc0(sizeof (XenIOState));
> +    xen_io_state = state;

We should pass a XenIOState pointer as an opaque pointer and
xen_phys_offset_to_gaddr as a function pointer to xen_map_cache_init,
rather than setting this global variable.


>      state->xce_handle = xen_xc_evtchn_open(NULL, 0);
>      if (state->xce_handle == XC_HANDLER_INITIAL_VALUE) {
> diff --git a/xen-mapcache.c b/xen-mapcache.c
> index 7bcb86e..73927ab 100644
> --- a/xen-mapcache.c
> +++ b/xen-mapcache.c
> @@ -191,10 +191,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
>                         uint8_t lock)
>  {
>      MapCacheEntry *entry, *pentry = NULL;
> -    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> -    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
> +    target_phys_addr_t address_index;
> +    target_phys_addr_t address_offset;
>      target_phys_addr_t __size = size;
>  
> +    phys_addr = xen_addr_actually_is(phys_addr, size);
> +    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> +    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
> +
>      trace_xen_map_cache(phys_addr);
>  
>      if (address_index == mapcache->last_address_index && !lock && !__size) {
> diff --git a/xen-mapcache.h b/xen-mapcache.h
> index da874ca..5e561c5 100644
> --- a/xen-mapcache.h
> +++ b/xen-mapcache.h
> @@ -19,6 +19,7 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
>  ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
>  void xen_invalidate_map_cache_entry(uint8_t *buffer);
>  void xen_invalidate_map_cache(void);
> +target_phys_addr_t xen_addr_actually_is(target_phys_addr_t start_addr, ram_addr_t size);
>  
>  #else
>  
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:40:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdHq-0002v0-Sp; Thu, 24 Nov 2011 17:40:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTdHp-0002ut-HR
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:40:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322156405!2901789!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26412 invoked from network); 24 Nov 2011 17:40:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:40:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:40:04 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:40:04 +0000
Date: Thu, 24 Nov 2011 17:40:54 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1322150893-887-3-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1111241735110.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-3-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen mapcache: Check if a memory space
	has moved.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 24 Nov 2011, Anthony PERARD wrote:
> This patch change the xen_map_cache behavior. Before trying to map a guest
> addr, mapcache will look into the list of range of address that have been moved
> (physmap/set_memory). There is currently one memory space like this, the vram,
> "moved" from were it's allocated to were the guest will look into.
> 
> This help to have a succefull migration.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  xen-all.c      |   19 +++++++++++++++++++
>  xen-mapcache.c |    8 ++++++--
>  xen-mapcache.h |    1 +
>  3 files changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index b5e28ab..40e8869 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -83,6 +83,8 @@ typedef struct XenIOState {
>      Notifier exit;
>  } XenIOState;
>  
> +XenIOState *xen_io_state = NULL;
> +
>  /* Xen specific function for piix pci */
>  
>  int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
> @@ -218,6 +220,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
>      return NULL;
>  }
>  
> +target_phys_addr_t xen_addr_actually_is(target_phys_addr_t start_addr, ram_addr_t size)

I really don't like the name of this function. What about xen_phys_offset_to_gaddr?


> +{
> +    if (xen_io_state) {
> +        target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
> +        XenPhysmap *physmap = NULL;
> +
> +        QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
> +            if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
> +                return physmap->start_addr;
> +            }
> +        }
> +    }
> +
> +    return start_addr;
> +}
> +
>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
>  static int xen_add_to_physmap(XenIOState *state,
>                                target_phys_addr_t start_addr,
> @@ -891,6 +909,7 @@ int xen_hvm_init(void)
>      XenIOState *state;
>  
>      state = g_malloc0(sizeof (XenIOState));
> +    xen_io_state = state;

We should pass a XenIOState pointer as an opaque pointer and
xen_phys_offset_to_gaddr as a function pointer to xen_map_cache_init,
rather than setting this global variable.


>      state->xce_handle = xen_xc_evtchn_open(NULL, 0);
>      if (state->xce_handle == XC_HANDLER_INITIAL_VALUE) {
> diff --git a/xen-mapcache.c b/xen-mapcache.c
> index 7bcb86e..73927ab 100644
> --- a/xen-mapcache.c
> +++ b/xen-mapcache.c
> @@ -191,10 +191,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
>                         uint8_t lock)
>  {
>      MapCacheEntry *entry, *pentry = NULL;
> -    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> -    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
> +    target_phys_addr_t address_index;
> +    target_phys_addr_t address_offset;
>      target_phys_addr_t __size = size;
>  
> +    phys_addr = xen_addr_actually_is(phys_addr, size);
> +    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> +    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
> +
>      trace_xen_map_cache(phys_addr);
>  
>      if (address_index == mapcache->last_address_index && !lock && !__size) {
> diff --git a/xen-mapcache.h b/xen-mapcache.h
> index da874ca..5e561c5 100644
> --- a/xen-mapcache.h
> +++ b/xen-mapcache.h
> @@ -19,6 +19,7 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
>  ram_addr_t xen_ram_addr_from_mapcache(void *ptr);
>  void xen_invalidate_map_cache_entry(uint8_t *buffer);
>  void xen_invalidate_map_cache(void);
> +target_phys_addr_t xen_addr_actually_is(target_phys_addr_t start_addr, ram_addr_t size);
>  
>  #else
>  
> -- 
> Anthony PERARD
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:42:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdJk-00031C-DR; Thu, 24 Nov 2011 17:42:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTdJj-00030u-92
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:42:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322156523!4504103!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21713 invoked from network); 24 Nov 2011 17:42:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:42:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:42:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:42:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTdJB-0007Ec-RI; Thu, 24 Nov 2011 17:42:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTdJB-0004aP-QX;
	Thu, 24 Nov 2011 17:42:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.33257.808458.54256@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:42:01 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
	html	output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 13 of 17] docs: generate an index for the html output"):
> docs: generate an index for the html output
> 
> nb: I'm not a Perl wizard...

The Perl looks reasonable in general, except that some of the style is
a bit odd.  perlstyle(1) is mostly a good guide.

In particular

> +sub write_file ($$) {
                 ^
vs.

> +sub make_page($$$) {
                ^
perlsub(1) suggests inculding the space in Perl sub prototypes.
(Multiple occurrences.)

> +    $l =~ s/.(html)$//g;

Why the capturing parens ?

> +    if ( $title eq "" )
> +    {

Brace should be on the same line.

> +	$title = $h1 = "Xen Documentation";

And indent should be 4, not 1.  (Multiple occurrences.)

> +    print STDERR "Writing: $file\n";
> +    write_file($file, $o);

Perhaps (i) the print should be to STDOUT (ii) it should be in
write_file ?

> +sub read_index
> +{

Missing prototype and bracket should be on same line.  To make the
prototype work you'll probably have to move the definition to before
the option parser call (or have a declaration).  Perhaps the main
program should be at the bottom.

> +	s/#.*$//;

This of course prevents link anchor texts in the inde including #,
which is probably an error which it would be nice to sort out now
rather than in the future when we'll have to read this script to make
it cope.

> +	m/([^\t]+)\t+(.*)/ or die;

This reliance on hard tabs will irritate many people.  You should use
\S and \s.  The filenames (the LHS) won't contain whitespace of
course.

Also you probably meant to anchor the pattern.  I would do something
like:

    s/^\s+//;
    s/\s+$//;
    next if m/^\#/;
    next unless m/\S/;
    m/^(\S+)\s+(\S.*)$/ or die;

> +for (@docs) { s,^${outdir}/,, }

This is not correct because $outdir is not a regular expression.  The
shortest way of doing this is indeed substr.

> +my $top = '';
> +
> +foreach my $od (sort { $a cmp $b } uniq map { dirname($_) } @docs) {
> +    my @d = (grep /^$od/, @docs);

Again, directory names are not regexps.

Do we really want an index per subdirectory ?

> +    if ( $#d == 0 and $d[0] eq "$od/index.html" )

$#d==0 is a rather odd way of putting it.  I would write @d==1.

> +	$top .= "<li><a href=\"${od}/index.html\">$od</a></li>\n";
> +	$top .= "<ul>\n";
> +	$top .= make_links($od,0,@d);
> +	$top .= "</ul>\n";

Maybe this wants a here document ?
        my $links = make_links blah blah;
        $top .= <<END;

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:42:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdJk-00031C-DR; Thu, 24 Nov 2011 17:42:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTdJj-00030u-92
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:42:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322156523!4504103!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21713 invoked from network); 24 Nov 2011 17:42:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:42:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; 
   d="scan'208";a="9118832"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:42:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:42:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTdJB-0007Ec-RI; Thu, 24 Nov 2011 17:42:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTdJB-0004aP-QX;
	Thu, 24 Nov 2011 17:42:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.33257.808458.54256@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:42:01 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
	html	output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 13 of 17] docs: generate an index for the html output"):
> docs: generate an index for the html output
> 
> nb: I'm not a Perl wizard...

The Perl looks reasonable in general, except that some of the style is
a bit odd.  perlstyle(1) is mostly a good guide.

In particular

> +sub write_file ($$) {
                 ^
vs.

> +sub make_page($$$) {
                ^
perlsub(1) suggests inculding the space in Perl sub prototypes.
(Multiple occurrences.)

> +    $l =~ s/.(html)$//g;

Why the capturing parens ?

> +    if ( $title eq "" )
> +    {

Brace should be on the same line.

> +	$title = $h1 = "Xen Documentation";

And indent should be 4, not 1.  (Multiple occurrences.)

> +    print STDERR "Writing: $file\n";
> +    write_file($file, $o);

Perhaps (i) the print should be to STDOUT (ii) it should be in
write_file ?

> +sub read_index
> +{

Missing prototype and bracket should be on same line.  To make the
prototype work you'll probably have to move the definition to before
the option parser call (or have a declaration).  Perhaps the main
program should be at the bottom.

> +	s/#.*$//;

This of course prevents link anchor texts in the inde including #,
which is probably an error which it would be nice to sort out now
rather than in the future when we'll have to read this script to make
it cope.

> +	m/([^\t]+)\t+(.*)/ or die;

This reliance on hard tabs will irritate many people.  You should use
\S and \s.  The filenames (the LHS) won't contain whitespace of
course.

Also you probably meant to anchor the pattern.  I would do something
like:

    s/^\s+//;
    s/\s+$//;
    next if m/^\#/;
    next unless m/\S/;
    m/^(\S+)\s+(\S.*)$/ or die;

> +for (@docs) { s,^${outdir}/,, }

This is not correct because $outdir is not a regular expression.  The
shortest way of doing this is indeed substr.

> +my $top = '';
> +
> +foreach my $od (sort { $a cmp $b } uniq map { dirname($_) } @docs) {
> +    my @d = (grep /^$od/, @docs);

Again, directory names are not regexps.

Do we really want an index per subdirectory ?

> +    if ( $#d == 0 and $d[0] eq "$od/index.html" )

$#d==0 is a rather odd way of putting it.  I would write @d==1.

> +	$top .= "<li><a href=\"${od}/index.html\">$od</a></li>\n";
> +	$top .= "<ul>\n";
> +	$top .= make_links($od,0,@d);
> +	$top .= "</ul>\n";

Maybe this wants a here document ?
        my $links = make_links blah blah;
        $top .= <<END;

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:44:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdLb-0003ES-W9; Thu, 24 Nov 2011 17:44:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTdLa-0003Dm-CA
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:44:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322156639!4876959!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17124 invoked from network); 24 Nov 2011 17:43:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:43:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9118854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:43:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:43:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTdL4-0007FM-QV; Thu, 24 Nov 2011 17:43:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTdL4-0004b3-PB;
	Thu, 24 Nov 2011 17:43:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.33374.767183.926805@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:43:58 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322155832.9567.61.camel@dagon.hellion.org.uk>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
	<4ECE8656020000780006314D@nat28.tlf.novell.com>
	<1322154873.9567.58.camel@dagon.hellion.org.uk>
	<1322155832.9567.61.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL"):
> tools: check for libaio unless user has configured CONFIG_SYSTEM_LIBAIO=n
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:44:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:44:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdLb-0003ES-W9; Thu, 24 Nov 2011 17:44:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTdLa-0003Dm-CA
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:44:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322156639!4876959!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17124 invoked from network); 24 Nov 2011 17:43:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:43:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9118854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:43:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:43:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTdL4-0007FM-QV; Thu, 24 Nov 2011 17:43:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTdL4-0004b3-PB;
	Thu, 24 Nov 2011 17:43:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.33374.767183.926805@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 17:43:58 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322155832.9567.61.camel@dagon.hellion.org.uk>
References: <osstest-10020-mainreport@xen.org>
	<20174.28573.818575.318659@mariner.uk.xensource.com>
	<1322152518.1005.189.camel@zakaz.uk.xensource.com>
	<4ECE8656020000780006314D@nat28.tlf.novell.com>
	<1322154873.9567.58.camel@dagon.hellion.org.uk>
	<1322155832.9567.61.camel@dagon.hellion.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10020: regressions - FAIL"):
> tools: check for libaio unless user has configured CONFIG_SYSTEM_LIBAIO=n
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:45:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdMS-0003K3-FL; Thu, 24 Nov 2011 17:45:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdMR-0003Jt-D6
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:45:23 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156652!58158209!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26008 invoked from network); 24 Nov 2011 17:44:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="19391869"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:44:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:44:55 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ1027444;	Thu, 24 Nov 2011 09:44:53 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:29 +0000
Message-ID: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 00/10] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series introduces the PCI passthrough for Xen.

First, we have HostPCIDevice that help to access one PCI device of the host.

Then, there is an additions in the QEMU code, pci_check_bar_overlap.

There are also several change in pci_ids and pci_regs.

Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
(or file), there is one to take care of the initialisation of a passthrough
device. The second one handle everything about the config address space, there
are specifics functions for every config register. The third one is to handle
MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:00:1b.0".

Change since v4:
  - return -errno if there is an error in host_pci_get_*
  - rename internal function get_value to get_hex_value (and return the same
    error value has get_resource)


Change since v3-v4:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.


Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.


Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property



Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (6):
  pci_ids: Add INTEL_82599_VF id.
  pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
  pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce HostPCIDevice to access a pci device on the host.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

Yuji Shimada (1):
  pci.c: Add pci_check_bar_overlap

 Makefile.target                      |    6 +
 configure                            |   25 +
 hw/apic-msidef.h                     |   30 +
 hw/apic.c                            |   11 +-
 hw/host-pci-device.c                 |  278 ++++
 hw/host-pci-device.h                 |   75 +
 hw/pci.c                             |   47 +
 hw/pci.h                             |    3 +
 hw/pci_ids.h                         |    1 +
 hw/pci_regs.h                        |    3 +-
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  902 ++++++++++++
 hw/xen_pci_passthrough.h             |  337 +++++
 hw/xen_pci_passthrough_config_init.c | 2637 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  678 +++++++++
 xen-all.c                            |   12 +
 16 files changed, 5037 insertions(+), 11 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c
 create mode 100644 hw/xen_pci_passthrough_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:45:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdMS-0003K3-FL; Thu, 24 Nov 2011 17:45:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdMR-0003Jt-D6
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:45:23 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156652!58158209!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26008 invoked from network); 24 Nov 2011 17:44:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="19391869"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:44:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:44:55 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ1027444;	Thu, 24 Nov 2011 09:44:53 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:29 +0000
Message-ID: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 00/10] Xen PCI Passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,

This patch series introduces the PCI passthrough for Xen.

First, we have HostPCIDevice that help to access one PCI device of the host.

Then, there is an additions in the QEMU code, pci_check_bar_overlap.

There are also several change in pci_ids and pci_regs.

Last part, but not least, the PCI passthrough device himself. Cut in 3 parts
(or file), there is one to take care of the initialisation of a passthrough
device. The second one handle everything about the config address space, there
are specifics functions for every config register. The third one is to handle
MSI.

There is a patch series on xen-devel (applied to xen-unstable) that add the
support of setting a PCI passthrough device through QMP from libxl (xen tool
stack). It is just a call to device_add, with the driver parametter
hostaddr="0000:00:1b.0".

Change since v4:
  - return -errno if there is an error in host_pci_get_*
  - rename internal function get_value to get_hex_value (and return the same
    error value has get_resource)


Change since v3-v4:
  - host_pci_get_* can now return an error, and take an extra parameter, a
    pointer to store the wanted value.
  - The memory_region for the PCI BAR are handled "manualy" because calling
    pci_default_write_config was not possible, because the XenPT handle the
    PCIIORegion it self. This make possible to do a device_remove.
  - Introduction of PT_ERR and PT_WARN macro to print debug and error messages.
    Also, these macro as well as PT_LOG will always print the short BDF of the
    device in the guest point of view.
  - PT_ERR is print by default (for all error messages).
  - Some debug/error message have been improve and should be a bit more useful.
  - hw_error have been removed from the code, and have been replaced by either
    a call to qemu_system_shudown_request() (that lead to a domain destroy) or
    a failed in the initialisation of the device.
  - Now, every patchs should compile with no error.


Change v2-v3;
  - in host-pci-device.c:
    - Return more usefull error code in get_ressource().
    - Use macro in host_pci_find_ext_cap_offset instead of raw number. But I
      still not sure if PCI_MAX_EXT_CAP is right, it's result is 480 like it
      was before, so it's maybe ok.
  - All use of MSI stuff in two first pci passthrough patch have been removed
    and move to the last patch.


Change v1-v2:
  - fix style issue (checkpatch.pl)
  - set the original authors, add some missing copyright headers
  - HostPCIDevice:
    - introduce HostPCIIORegions (with base_addr, size, flags)
    - save all flags from ./resource and store it in a separate field.
    - fix endianess on write
    - new host_pci_dev_put function
    - use pci.c like interface host_pci_get/set_byte/word/long (instead of
      host_pci_read/write_)
  - compile HostPCIDevice only on linux (as well as xen_pci_passthrough)
  - introduce apic-msidef.h file.
  - no more run_one_timer, if a pci device is in the middle of a power
    transition, just "return an error" in config read/write
  - use a global var mapped_machine_irq (local to xen_pci_passthrough.c)
  - add msitranslate and power-mgmt ad qdev property



Allen Kay (2):
  Introduce Xen PCI Passthrough, qdevice (1/3)
  Introduce Xen PCI Passthrough, PCI config space helpers (2/3)

Anthony PERARD (6):
  pci_ids: Add INTEL_82599_VF id.
  pci_regs: Fix value of PCI_EXP_TYPE_RC_EC.
  pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
  configure: Introduce --enable-xen-pci-passthrough.
  Introduce HostPCIDevice to access a pci device on the host.
  Introduce apic-msidef.h

Jiang Yunhong (1):
  Introduce Xen PCI Passthrough, MSI (3/3)

Yuji Shimada (1):
  pci.c: Add pci_check_bar_overlap

 Makefile.target                      |    6 +
 configure                            |   25 +
 hw/apic-msidef.h                     |   30 +
 hw/apic.c                            |   11 +-
 hw/host-pci-device.c                 |  278 ++++
 hw/host-pci-device.h                 |   75 +
 hw/pci.c                             |   47 +
 hw/pci.h                             |    3 +
 hw/pci_ids.h                         |    1 +
 hw/pci_regs.h                        |    3 +-
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  902 ++++++++++++
 hw/xen_pci_passthrough.h             |  337 +++++
 hw/xen_pci_passthrough_config_init.c | 2637 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough_msi.c         |  678 +++++++++
 xen-all.c                            |   12 +
 16 files changed, 5037 insertions(+), 11 deletions(-)
 create mode 100644 hw/apic-msidef.h
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c
 create mode 100644 hw/xen_pci_passthrough_msi.c

-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:45:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdMU-0003KS-TT; Thu, 24 Nov 2011 17:45:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdMS-0003K0-Kz
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:45:24 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156652!58158209!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26061 invoked from network); 24 Nov 2011 17:44:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="19391870"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:44:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:44:57 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ3027444;	Thu, 24 Nov 2011 09:44:56 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:31 +0000
Message-ID: <1322156679-9441-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 02/10] pci_regs: Fix value of
	PCI_EXP_TYPE_RC_EC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Value check in PCI Express Base Specification rev 1.1

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index e8357c3..6b42515 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -393,7 +393,7 @@
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
-#define  PCI_EXP_TYPE_RC_EC	0x10	/* Root Complex Event Collector */
+#define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
 #define PCI_EXP_FLAGS_IRQ	0x3e00	/* Interrupt message number */
 #define PCI_EXP_DEVCAP		4	/* Device capabilities */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:45:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:45:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdMU-0003KS-TT; Thu, 24 Nov 2011 17:45:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdMS-0003K0-Kz
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:45:24 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156652!58158209!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26061 invoked from network); 24 Nov 2011 17:44:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="19391870"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:44:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:44:57 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ3027444;	Thu, 24 Nov 2011 09:44:56 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:31 +0000
Message-ID: <1322156679-9441-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 02/10] pci_regs: Fix value of
	PCI_EXP_TYPE_RC_EC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Value check in PCI Express Base Specification rev 1.1

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index e8357c3..6b42515 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -393,7 +393,7 @@
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
-#define  PCI_EXP_TYPE_RC_EC	0x10	/* Root Complex Event Collector */
+#define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
 #define PCI_EXP_FLAGS_IRQ	0x3e00	/* Interrupt message number */
 #define PCI_EXP_DEVCAP		4	/* Device capabilities */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:45:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdMa-0003LX-Bz; Thu, 24 Nov 2011 17:45:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdMZ-0003L9-4K
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:45:31 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156652!58158209!4
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26267 invoked from network); 24 Nov 2011 17:44:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="19391877"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:04 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ7027444;	Thu, 24 Nov 2011 09:45:01 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:35 +0000
Message-ID: <1322156679-9441-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 06/10] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>

This function help Xen PCI Passthrough device to check for overlap.

Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/pci.h |    3 +++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 399227f..563bb37 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -2038,3 +2038,50 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
 {
     return dev->bus->address_space_io;
 }
+
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type)
+{
+    PCIBus *bus = dev->bus;
+    PCIDevice *devices = NULL;
+    PCIIORegion *r;
+    int i, j;
+    int rc = 0;
+
+    /* check Overlapped to Base Address */
+    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
+        devices = bus->devices[i];
+        if (!devices) {
+            continue;
+        }
+
+        /* skip itself */
+        if (devices->devfn == dev->devfn) {
+            continue;
+        }
+
+        for (j = 0; j < PCI_NUM_REGIONS; j++) {
+            r = &devices->io_regions[j];
+
+            /* skip different resource type, but don't skip when
+             * prefetch and non-prefetch memory are compared.
+             */
+            if (type != r->type) {
+                if (type == PCI_BASE_ADDRESS_SPACE_IO ||
+                    r->type == PCI_BASE_ADDRESS_SPACE_IO) {
+                    continue;
+                }
+            }
+
+            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {
+                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
+                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
+                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
+                       PCI_FUNC(devices->devfn), j, r->addr, r->size);
+                rc = 1;
+            }
+        }
+    }
+
+    return rc;
+}
diff --git a/hw/pci.h b/hw/pci.h
index 625e717..9a723d2 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -552,4 +552,7 @@ static inline void pci_dma_sglist_init(QEMUSGList *qsg, PCIDevice *dev,
     qemu_sglist_init(qsg, alloc_hint);
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type);
+
 #endif
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:45:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdMa-0003LX-Bz; Thu, 24 Nov 2011 17:45:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdMZ-0003L9-4K
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:45:31 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156652!58158209!4
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26267 invoked from network); 24 Nov 2011 17:44:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="19391877"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:04 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ7027444;	Thu, 24 Nov 2011 09:45:01 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:35 +0000
Message-ID: <1322156679-9441-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 06/10] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>

This function help Xen PCI Passthrough device to check for overlap.

Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 hw/pci.h |    3 +++
 2 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 399227f..563bb37 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -2038,3 +2038,50 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
 {
     return dev->bus->address_space_io;
 }
+
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type)
+{
+    PCIBus *bus = dev->bus;
+    PCIDevice *devices = NULL;
+    PCIIORegion *r;
+    int i, j;
+    int rc = 0;
+
+    /* check Overlapped to Base Address */
+    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
+        devices = bus->devices[i];
+        if (!devices) {
+            continue;
+        }
+
+        /* skip itself */
+        if (devices->devfn == dev->devfn) {
+            continue;
+        }
+
+        for (j = 0; j < PCI_NUM_REGIONS; j++) {
+            r = &devices->io_regions[j];
+
+            /* skip different resource type, but don't skip when
+             * prefetch and non-prefetch memory are compared.
+             */
+            if (type != r->type) {
+                if (type == PCI_BASE_ADDRESS_SPACE_IO ||
+                    r->type == PCI_BASE_ADDRESS_SPACE_IO) {
+                    continue;
+                }
+            }
+
+            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {
+                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
+                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
+                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
+                       PCI_FUNC(devices->devfn), j, r->addr, r->size);
+                rc = 1;
+            }
+        }
+    }
+
+    return rc;
+}
diff --git a/hw/pci.h b/hw/pci.h
index 625e717..9a723d2 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -552,4 +552,7 @@ static inline void pci_dma_sglist_init(QEMUSGList *qsg, PCIDevice *dev,
     qemu_sglist_init(qsg, alloc_hint);
 }
 
+int pci_check_bar_overlap(PCIDevice *dev,
+                          pcibus_t addr, pcibus_t size, uint8_t type);
+
 #endif
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:45:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdMb-0003MB-R3; Thu, 24 Nov 2011 17:45:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdMa-0003KW-Bv
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:45:32 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156652!58158209!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26139 invoked from network); 24 Nov 2011 17:44:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="19391872"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:00 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ5027444;	Thu, 24 Nov 2011 09:44:59 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:33 +0000
Message-ID: <1322156679-9441-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 04/10] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index f033438..8ad6698 100755
--- a/configure
+++ b/configure
@@ -127,6 +127,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 attr=""
 libattr=""
@@ -644,6 +645,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -990,6 +995,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1398,6 +1405,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3500,6 +3522,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:45:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:45:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdMb-0003MB-R3; Thu, 24 Nov 2011 17:45:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdMa-0003KW-Bv
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:45:32 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156652!58158209!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26139 invoked from network); 24 Nov 2011 17:44:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="19391872"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:00 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ5027444;	Thu, 24 Nov 2011 09:44:59 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:33 +0000
Message-ID: <1322156679-9441-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 04/10] configure: Introduce
	--enable-xen-pci-passthrough.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 configure |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index f033438..8ad6698 100755
--- a/configure
+++ b/configure
@@ -127,6 +127,7 @@ vnc_png=""
 vnc_thread="no"
 xen=""
 xen_ctrl_version=""
+xen_pci_passthrough=""
 linux_aio=""
 attr=""
 libattr=""
@@ -644,6 +645,10 @@ for opt do
   ;;
   --enable-xen) xen="yes"
   ;;
+  --disable-xen-pci-passthrough) xen_pci_passthrough="no"
+  ;;
+  --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -990,6 +995,8 @@ echo "                           (affects only QEMU, not qemu-img)"
 echo "  --enable-mixemu          enable mixer emulation"
 echo "  --disable-xen            disable xen backend driver support"
 echo "  --enable-xen             enable xen backend driver support"
+echo "  --disable-xen-pci-passthrough"
+echo "  --enable-xen-pci-passthrough"
 echo "  --disable-brlapi         disable BrlAPI"
 echo "  --enable-brlapi          enable BrlAPI"
 echo "  --disable-vnc-tls        disable TLS encryption for VNC server"
@@ -1398,6 +1405,21 @@ EOF
   fi
 fi
 
+if test "$xen_pci_passthrough" != "no"; then
+  if test "$xen" = "yes" && test "$linux" = "yes"; then
+    xen_pci_passthrough=yes
+  else
+    if test "$xen_pci_passthrough" = "yes"; then
+      echo "ERROR"
+      echo "ERROR: User requested feature Xen PCI Passthrough"
+      echo "ERROR: but this feature require /sys from Linux"
+      echo "ERROR"
+      exit 1;
+    fi
+    xen_pci_passthrough=no
+  fi
+fi
+
 ##########################################
 # pkg-config probe
 
@@ -3500,6 +3522,9 @@ case "$target_arch2" in
     if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
       target_phys_bits=64
       echo "CONFIG_XEN=y" >> $config_target_mak
+      if test "$xen_pci_passthrough" = yes; then
+        echo "CONFIG_XEN_PCI_PASSTHROUGH=y" >> "$config_target_mak"
+      fi
     else
       echo "CONFIG_NO_XEN=y" >> $config_target_mak
     fi
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:45:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdMj-0003R0-ET; Thu, 24 Nov 2011 17:45:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdMh-0003NT-Fv
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:45:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156652!58158209!5
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26361 invoked from network); 24 Nov 2011 17:44:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="19391878"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:07 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ9027444;	Thu, 24 Nov 2011 09:45:06 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:37 +0000
Message-ID: <1322156679-9441-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 08/10] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c             |   15 +
 hw/xen_pci_passthrough_config_init.c | 2131 ++++++++++++++++++++++++++++++++++
 2 files changed, 2146 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 998470b..c816ed5 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -360,6 +360,11 @@ out:
             PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
         }
     }
+
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        qemu_mod_timer(s->pm_state->pm_timer,
+                       qemu_get_clock_ms(rt_clock) + s->pm_state->pm_delay);
+    }
 }
 
 /* ioport/iomem space*/
@@ -706,6 +711,13 @@ static int pt_initfn(PCIDevice *pcidev)
     /* Handle real device's MMIO/PIO BARs */
     pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (pt_config_init(s)) {
+        PT_ERR(pcidev, "PCI Config space initialisation failed.\n");
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         PT_LOG(pcidev, "no pin interrupt\n");
@@ -798,6 +810,9 @@ static int pt_unregister_device(PCIDevice *pcidev)
         }
     }
 
+    /* delete all emulated config registers */
+    pt_config_delete(s);
+
     /* unregister real device's MMIO/PIO BARs */
     pt_unregister_regions(s);
 
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 1e9de64..ae64544 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1,11 +1,2142 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pci_passthrough.h"
 
+#define PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data);
+static int pt_init_pci_config(XenPCIPassthroughState *s);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+/* parse BAR */
+static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int flags = s->real_device->io_regions[index - 1].flags;
+
+        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
+                return PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
+        return PT_BAR_FLAG_IO;
+    } else {
+        return PT_BAR_FLAG_MEM;
+    }
+}
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int pt_common_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+
+/* Write register functions */
+
+static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint8_t *value, uint8_t dev_value,
+                             uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t dev_value,
+                             uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint32_t *value, uint32_t dev_value,
+                             uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* common restore register fonctions */
+static int pt_byte_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint8_t dev_value,
+                               uint8_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_byte(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint16_t dev_value,
+                               uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int pt_vendor_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->vendor_id;
+    return 0;
+}
+static int pt_device_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->device_id;
+    return 0;
+}
+static int pt_status_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t dev_value,
+                            uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t wr_value = *value;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*value & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* mapping BAR */
+    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
+                   wr_value & PCI_COMMAND_MEMORY);
+
+    return 0;
+}
+static int pt_cmd_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint16_t dev_value,
+                              uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+    uint16_t restorable_mask = 0;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring to I/O device register
+     * but do not include Fast Back-to-Back Enable bit.
+     */
+    restorable_mask = reg->emu_mask & ~PCI_COMMAND_FAST_BACK;
+    *value = PT_MERGE_VALUE(*value, dev_value, restorable_mask);
+
+    if (!s->machine_irq) {
+        *value |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        *value &= ~PCI_COMMAND_INTX_DISABLE;
+    }
+
+    return 0;
+}
+
+/* BAR */
+#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
+#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
+#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
+#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
+
+static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
+{
+    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set initial guest physical base address to -1 */
+    s->bases[index].e_physbase = -1;
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
+        reg_field = PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device->io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t dev_value,
+                            uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t new_addr, last_addr;
+    uint32_t prev_offset;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_IO:
+        new_addr = cfg_entry->data;
+        last_addr = new_addr + r_size - 1;
+        /* check invalid address */
+        if (last_addr <= new_addr || !new_addr || last_addr >= UINT16_MAX) {
+            /* check 64K range */
+            if ((last_addr >= UINT16_MAX) &&
+                (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask))) {
+                PT_WARN(d, "Guest attempt to set Base Address "
+                       "over the 64KB. (offset: 0x%02x,"
+                       " addr: 0x%08x, size: 0x%08x)\n",
+                       reg->offset, new_addr, r_size);
+            }
+            /* just remove mapping */
+            r->addr = PCI_BAR_UNMAPPED;
+            goto exit;
+        }
+        break;
+    case PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
+                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                        "Ignore mapping. "
+                        "(offset: 0x%02x, high address: 0x%08x)\n",
+                        reg->offset, cfg_entry->data);
+            }
+            /* clear lower address */
+            d->io_regions[index-1].addr = -1;
+        } else {
+            /* find lower 32bit BAR */
+            prev_offset = (reg->offset - 4);
+            reg_grp_entry = pt_find_reg_grp(s, prev_offset);
+            if (reg_grp_entry) {
+                reg_entry = pt_find_reg(reg_grp_entry, prev_offset);
+                if (reg_entry) {
+                    /* restore lower address */
+                    d->io_regions[index-1].addr = reg_entry->data;
+                } else {
+                    return -1;
+                }
+            } else {
+                return -1;
+            }
+        }
+
+        /* never mapping the 'empty' upper region,
+         * because we'll do it enough for the lower region.
+         */
+        r->addr = -1;
+        goto exit;
+    default:
+        break;
+    }
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+exit:
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+static int pt_bar_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint32_t dev_value,
+                              uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t bar_emu_mask = 0;
+    int index = 0;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use value from kernel sysfs */
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UPPER) {
+        *value = s->real_device->io_regions[index - 1].base_addr >> 32;
+    } else {
+        *value = base_address_with_flags(&s->real_device->io_regions[index]);
+    }
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, bar_emu_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint32_t *value,
+                                    uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r = &d->io_regions[PCI_ROM_SLOT];
+    r_size = r->size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR*/
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, PCI_ROM_SLOT,
+                               reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+/* restore ROM BAR */
+static int pt_exp_rom_bar_reg_restore(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry,
+                                      uint32_t real_offset,
+                                      uint32_t dev_value, uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t v;
+
+    if (host_pci_get_long(s->real_device, PCI_ROM_ADDRESS, &v)) {
+        return -1;
+    }
+    /* use value from kernel sysfs */
+    *value = PT_MERGE_VALUE(v, dev_value, reg->emu_mask);
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_vendor_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_device_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_cmd_reg_read,
+        .u.w.write  = pt_cmd_reg_write,
+        .u.w.restore  = pt_cmd_reg_restore,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = pt_status_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = pt_header_type_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_irqpin_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_exp_rom_bar_reg_write,
+        .u.dw.restore = pt_exp_rom_bar_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+/* initialize Link Control register */
+static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = 0;
+    uint8_t dev_type = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+    dev_type = (pci_get_byte(s->dev.config + real_offset - reg->offset
+                             + PCI_EXP_FLAGS)
+                & PCI_EXP_FLAGS_TYPE) >> 4;
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    uint8_t cap_ver = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_long_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_devctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* initialize Power Management Capabilities register */
+static int pt_pmc_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+
+    if (s->power_mgmt) {
+        /* set Power Management Capabilities register */
+        s->pm_state->pmc_field = pci_get_word(d->config + real_offset);
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize PCI Power Management Control/Status register */
+static int pt_pmcsr_reg_init(XenPCIPassthroughState *s,
+                             XenPTRegInfo *reg, uint32_t real_offset,
+                             uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t cap_ver  = 0;
+    uint16_t v = 0;
+
+    if (!s->power_mgmt) {
+        *data = reg->init_val;
+        return 0;
+    }
+
+    /* check PCI Power Management support version */
+    cap_ver = s->pm_state->pmc_field & PCI_PM_CAP_VER_MASK;
+
+    if (cap_ver > 2) {
+        /* set No Soft Reset */
+        s->pm_state->no_soft_reset =
+            pci_get_byte(d->config + real_offset) & PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    host_pci_get_word(s->real_device, real_offset, &v);
+    /* wake up real physical device */
+    switch (v & PCI_PM_CTRL_STATE_MASK) {
+    case 0:
+        break;
+    case 1:
+        PT_LOG(d, "Power state transition D1 -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        break;
+    case 2:
+        PT_LOG(d, "Power state transition D2 -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        usleep(200);
+        break;
+    case 3:
+        PT_LOG(d, "Power state transition D3hot -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        usleep(10 * 1000);
+        if (pt_init_pci_config(s)) {
+            return -1;
+        }
+        break;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* read Power Management Control/Status register */
+static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    if (!s->power_mgmt) {
+        valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* reset Interrupt and I/O resource  */
+static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    PCIIORegion *r;
+    int i = 0;
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    /* unbind INTx */
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+
+    if (s->machine_irq) {
+        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
+                                    PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
+            PT_ERR(d, "Unbinding of interrupt failed!\n");
+        }
+    }
+
+    /* clear all virtual region address */
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        r = &d->io_regions[i];
+        r->addr = -1;
+    }
+
+    /* unmapping BAR */
+    pt_bar_mapping(s, 0, 0);
+}
+/* check power state transition */
+static int check_power_state(XenPCIPassthroughState *s)
+{
+    XenPTPM *pm_state = s->pm_state;
+    PCIDevice *d = &s->dev;
+    uint16_t read_val = 0;
+    uint16_t cur_state = 0;
+
+    /* get current power state */
+    if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                          &read_val)) {
+        return -1;
+    }
+    cur_state = read_val & PCI_PM_CTRL_STATE_MASK;
+
+    if (pm_state->req_state != cur_state) {
+        PT_ERR(d, "Failed to change power state. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, cur_state);
+        return -1;
+    }
+    return 0;
+}
+/* write Power Management Control/Status register */
+static void pt_from_d3hot_to_d0_with_reset(void *opaque)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTPM *pm_state = s->pm_state;
+    int ret = 0;
+
+    /* check power state */
+    ret = check_power_state(s);
+
+    if (ret < 0) {
+        goto out;
+    }
+
+    pt_init_pci_config(s);
+
+out:
+    /* power state transition flags off */
+    pm_state->flags &= ~PT_FLAG_TRANSITING;
+
+    qemu_free_timer(pm_state->pm_timer);
+    pm_state->pm_timer = NULL;
+}
+static void pt_default_power_transition(void *opaque)
+{
+    XenPCIPassthroughState *ptdev = opaque;
+    XenPTPM *pm_state = ptdev->pm_state;
+
+    /* check power state */
+    check_power_state(ptdev);
+
+    /* power state transition flags off */
+    pm_state->flags &= ~PT_FLAG_TRANSITING;
+
+    qemu_free_timer(pm_state->pm_timer);
+    pm_state->pm_timer = NULL;
+}
+static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint16_t *value, uint16_t dev_value,
+                              uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    XenPTPM *pm_state = s->pm_state;
+
+    if (!s->power_mgmt) {
+        emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    if (!s->power_mgmt) {
+        return 0;
+    }
+
+    /* set I/O device power state */
+    pm_state->cur_state = dev_value & PCI_PM_CTRL_STATE_MASK;
+
+    /* set Guest requested PowerState */
+    pm_state->req_state = *value & PCI_PM_CTRL_STATE_MASK;
+
+    /* check power state transition or not */
+    if (pm_state->cur_state == pm_state->req_state) {
+        /* not power state transition */
+        return 0;
+    }
+
+    /* check enable power state transition */
+    if ((pm_state->req_state != 0) &&
+        (pm_state->cur_state > pm_state->req_state)) {
+        PT_ERR(d, "Invalid power transition. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, pm_state->cur_state);
+
+        return 0;
+    }
+
+    /* check if this device supports the requested power state */
+    if (((pm_state->req_state == 1) && !(pm_state->pmc_field & PCI_PM_CAP_D1))
+        || ((pm_state->req_state == 2) &&
+            !(pm_state->pmc_field & PCI_PM_CAP_D2))) {
+        PT_ERR(d, "Invalid power transition. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, pm_state->cur_state);
+
+        return 0;
+    }
+
+    /* in case of transition related to D3hot, it's necessary to wait 10 ms.
+     * But because writing to register will be performed later on actually,
+     * don't start QEMUTimer right now, just alloc and init QEMUTimer here.
+     */
+    if ((pm_state->cur_state == 3) || (pm_state->req_state == 3)) {
+        if (pm_state->req_state == 0) {
+            /* alloc and init QEMUTimer */
+            if (!pm_state->no_soft_reset) {
+                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                    pt_from_d3hot_to_d0_with_reset, s);
+
+                /* reset Interrupt and I/O resource mapping */
+                pt_reset_interrupt_and_io_mapping(s);
+            } else {
+                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                                        pt_default_power_transition, s);
+            }
+        } else {
+            /* alloc and init QEMUTimer */
+            pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                pt_default_power_transition, s);
+        }
+
+        /* set power state transition delay */
+        pm_state->pm_delay = 10;
+
+        /* power state transition flags on */
+        pm_state->flags |= PT_FLAG_TRANSITING;
+    }
+    /* in case of transition related to D0, D1 and D2,
+     * no need to use QEMUTimer.
+     * So, we perfom writing to register here and then read it back.
+     */
+    else {
+        /* write power state to I/O device register */
+        host_pci_set_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                          *value);
+
+        /* in case of transition related to D2,
+         * it's necessary to wait 200 usec.
+         * But because QEMUTimer do not support microsec unit right now,
+         * so we do wait ourself here.
+         */
+        if ((pm_state->cur_state == 2) || (pm_state->req_state == 2)) {
+            usleep(200);
+        }
+
+        /* check power state */
+        check_power_state(s);
+
+        /* recreate value for writing to I/O device register */
+        if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                              value)) {
+            return -1;
+        }
+    }
+
+    return 0;
+}
+
+/* restore Power Management Control/Status register */
+static int pt_pmcsr_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t real_offset, uint16_t dev_value,
+                                uint16_t *value)
+{
+    /* create value for restoring to I/O device register
+     * No need to restore, just clear PME Enable and PME Status bit
+     * Note: register type of PME Status bit is RW1C, so clear by writing 1b
+     */
+    *value = (dev_value & ~PCI_PM_CTRL_PME_ENABLE) | PCI_PM_CTRL_PME_STATUS;
+
+    return 0;
+}
+
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = pt_pmc_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = pt_pmcsr_reg_init,
+        .u.w.read   = pt_pmcsr_reg_read,
+        .u.w.write  = pt_pmcsr_reg_write,
+        .u.w.restore  = pt_pmcsr_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* AER register operations */
+
+static void aer_save_one_register(XenPCIPassthroughState *s, int offset)
+{
+    PCIDevice *d = &s->dev;
+    uint32_t aer_base = s->pm_state->aer_base;
+    uint32_t val = 0;
+
+    if (host_pci_get_long(s->real_device, aer_base + offset, &val)) {
+        return;
+    }
+    pci_set_long(d->config + aer_base + offset, val);
+}
+static void pt_aer_reg_save(XenPCIPassthroughState *s)
+{
+    /* after reset, following register values should be restored.
+     * So, save them.
+     */
+    aer_save_one_register(s, PCI_ERR_UNCOR_MASK);
+    aer_save_one_register(s, PCI_ERR_UNCOR_SEVER);
+    aer_save_one_register(s, PCI_ERR_COR_MASK);
+    aer_save_one_register(s, PCI_ERR_CAP);
+}
+static void aer_restore_one_register(XenPCIPassthroughState *s, int offset)
+{
+    PCIDevice *d = &s->dev;
+    uint32_t aer_base = s->pm_state->aer_base;
+    uint32_t config = 0;
+
+    config = pci_get_long(d->config + aer_base + offset);
+    host_pci_set_long(s->real_device, aer_base + offset, config);
+}
+static void pt_aer_reg_restore(XenPCIPassthroughState *s)
+{
+    /* the following registers should be reconfigured to correct values
+     * after reset. restore them.
+     * other registers should not be reconfigured after reset
+     * if there is no reason
+     */
+    aer_restore_one_register(s, PCI_ERR_UNCOR_MASK);
+    aer_restore_one_register(s, PCI_ERR_UNCOR_SEVER);
+    aer_restore_one_register(s, PCI_ERR_COR_MASK);
+    aer_restore_one_register(s, PCI_ERR_CAP);
+}
+
+/* capability structure register group size functions */
+
+static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Power Management Capability Structure register group size */
+static int pt_pm_size_init(XenPCIPassthroughState *s,
+                           const XenPTRegGroupInfo *grp_reg,
+                           uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+
+    if (!s->power_mgmt) {
+        return 0;
+    }
+
+    s->pm_state = g_new0(XenPTPM, 1);
+
+    /* set Power Management Capability base offset */
+    s->pm_state->pm_base = base_offset;
+
+    /* find AER register and set AER Capability base offset */
+    s->pm_state->aer_base = host_pci_find_ext_cap_offset(s->real_device,
+                                                         PCI_EXT_CAP_ID_ERR);
+
+    /* save AER register */
+    if (s->pm_state->aer_base) {
+        pt_aer_reg_save(s);
+    }
+
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int pt_vendor_size_init(XenPCIPassthroughState *s,
+                               const XenPTRegGroupInfo *grp_reg,
+                               uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int pt_pcie_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t exp_flag = 0;
+    uint16_t type = 0;
+    uint16_t version = 0;
+    uint8_t pcie_size = 0;
+
+    exp_flag = pci_get_word(d->config + base_offset + PCI_EXP_FLAGS);
+    type = (exp_flag & PCI_EXP_FLAGS_TYPE) >> 4;
+    version = exp_flag & PCI_EXP_FLAGS_VERS;
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
+                   type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
+                   type);
+            return -1;
+        }
+    } else {
+        PT_ERR(d, "Internal error: Unsupported capability version (%d).\n",
+               version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_header0_tbl,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = pt_pm_size_init,
+        .emu_reg_tbl = pt_emu_reg_pm_tbl,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_vendor_size_init,
+        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_pcie_size_init,
+        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int pt_ptr_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    /* uint32_t reg_field = (uint32_t)s->dev.config[real_offset]; */
+    uint32_t reg_field = pci_get_byte(s->dev.config + real_offset);
+    int i;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+            if (pt_emu_reg_grp_tbl[i].grp_id == s->dev.config[reg_field]) {
+                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+        /* next capability */
+        /* reg_field = (uint32_t)s->dev.config[reg_field + 1]; */
+        reg_field = pci_get_byte(s->dev.config + reg_field + 1);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+/* restore a part of I/O device register */
+static int pt_config_restore(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+    uint32_t read_val = 0;
+    uint32_t val = 0;
+    int rc = 0;
+
+    /* find emulate register group entry */
+    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
+        /* find emulate register entry */
+        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
+            reg = reg_entry->reg;
+
+            /* check whether restoring is needed */
+            if (!reg->u.b.restore) {
+                continue;
+            }
+
+            real_offset = reg_grp_entry->base_offset + reg->offset;
+
+            /* read I/O device register value */
+            rc = host_pci_get_block(s->real_device, real_offset,
+                                    (uint8_t *)&read_val, reg->size);
+
+            if (rc < 0) {
+                PT_ERR(&s->dev, "pci_read_block failed. "
+                       "return value: %d.\n", rc);
+                memset(&read_val, 0xff, reg->size);
+            }
+
+            val = 0;
+
+            /* restore based on register size */
+            switch (reg->size) {
+            case 1:
+                /* byte register */
+                rc = reg->u.b.restore(s, reg_entry, real_offset,
+                                      (uint8_t)read_val, (uint8_t *)&val);
+                break;
+            case 2:
+                /* word register */
+                rc = reg->u.w.restore(s, reg_entry, real_offset,
+                                      (uint16_t)read_val, (uint16_t *)&val);
+                break;
+            case 4:
+                /* double word register */
+                rc = reg->u.dw.restore(s, reg_entry, real_offset,
+                                       (uint32_t)read_val, (uint32_t *)&val);
+                break;
+            }
+
+            /* restoring error */
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid restoring."
+                                         " (%s, rc: %d)\n", __func__, rc);
+                return -1;
+            }
+
+            PT_LOG_CONFIG(&s->dev, real_offset, val, reg->size);
+
+            rc = host_pci_set_block(s->real_device, real_offset,
+                                    (uint8_t *)&val, reg->size);
+
+            if (rc < 0) {
+                PT_ERR(&s->dev, "pci_write_block failed. "
+                       "return value: %d.\n", rc);
+                return -1;
+            }
+        }
+    }
+
+    /* if AER supported, restore it */
+    if (s->pm_state->aer_base) {
+        pt_aer_reg_restore(s);
+    }
+    return 0;
+}
+/* reinitialize all emulate registers */
+static int pt_config_reinit(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    int rc = 0;
+
+    /* find emulate register group entry */
+    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
+        /* find emulate register entry */
+        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
+            reg = reg_entry->reg;
+            if (reg->init) {
+                /* initialize emulate register */
+                rc = reg->init(s, reg_entry->reg,
+                               reg_grp_entry->base_offset + reg->offset,
+                               &reg_entry->data);
+                if (rc < 0) {
+                    return rc;
+                }
+            }
+        }
+    }
+    return 0;
+}
+
+static int pt_init_pci_config(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    int rc = 0;
+
+    PT_LOG(d, "Reinitialize PCI configuration registers due to power state"
+           " transition with internal reset.\n");
+
+    /* restore a part of I/O device register */
+    rc = pt_config_restore(s);
+    if (rc < 0) {
+        return rc;
+    }
+
+    /* reinitialize all emulate register */
+    rc = pt_config_reinit(s);
+    if (rc < 0) {
+        return rc;
+    }
+
+    /* rebind machine_irq to device */
+    if (s->machine_irq != 0) {
+        uint8_t e_device = PCI_SLOT(s->dev.devfn);
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq, 0,
+                                       e_device, e_intx);
+        if (rc < 0) {
+            PT_ERR(d, "Rebinding of interrupt failed! rc=%d\n", rc);
+        }
+    }
+
+    return rc;
+}
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    int max_cap = 48;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (host_pci_get_byte(s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < 0x40) {
+            break;
+        }
+
+        pos &= ~3;
+        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int pt_config_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int pt_config_init(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    uint32_t reg_grp_offset = 0;
+    XenPTRegInfo *reg_tbl = NULL;
+    int i, j, rc;
+
+    QLIST_INIT(&s->reg_grp_tbl);
+
+    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
+        if (pt_emu_reg_grp_tbl[i].size_init) {
+            /* get register group size */
+            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
+                                                 reg_grp_offset,
+                                                 &reg_grp_entry->size);
+            if (rc < 0) {
+                pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
+                reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
+                /* initialize capability register */
+                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
+                    /* initialize capability register */
+                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
+                    if (rc < 0) {
+                        pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+        reg_grp_offset = 0;
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free Power Management info table */
+    if (s->pm_state) {
+        if (s->pm_state->pm_timer) {
+            qemu_del_timer(s->pm_state->pm_timer);
+            qemu_free_timer(s->pm_state->pm_timer);
+            s->pm_state->pm_timer = NULL;
+        }
+
+        g_free(s->pm_state);
+    }
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:45:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:45:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdMj-0003R0-ET; Thu, 24 Nov 2011 17:45:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdMh-0003NT-Fv
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:45:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156652!58158209!5
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26361 invoked from network); 24 Nov 2011 17:44:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="19391878"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:07 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ9027444;	Thu, 24 Nov 2011 09:45:06 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:37 +0000
Message-ID: <1322156679-9441-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 08/10] Introduce Xen PCI Passthrough,
	PCI config space helpers (2/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen_pci_passthrough.c             |   15 +
 hw/xen_pci_passthrough_config_init.c | 2131 ++++++++++++++++++++++++++++++++++
 2 files changed, 2146 insertions(+), 0 deletions(-)

diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index 998470b..c816ed5 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -360,6 +360,11 @@ out:
             PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
         }
     }
+
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        qemu_mod_timer(s->pm_state->pm_timer,
+                       qemu_get_clock_ms(rt_clock) + s->pm_state->pm_delay);
+    }
 }
 
 /* ioport/iomem space*/
@@ -706,6 +711,13 @@ static int pt_initfn(PCIDevice *pcidev)
     /* Handle real device's MMIO/PIO BARs */
     pt_register_regions(s);
 
+    /* reinitialize each config register to be emulated */
+    if (pt_config_init(s)) {
+        PT_ERR(pcidev, "PCI Config space initialisation failed.\n");
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
     /* Bind interrupt */
     if (!s->dev.config[PCI_INTERRUPT_PIN]) {
         PT_LOG(pcidev, "no pin interrupt\n");
@@ -798,6 +810,9 @@ static int pt_unregister_device(PCIDevice *pcidev)
         }
     }
 
+    /* delete all emulated config registers */
+    pt_config_delete(s);
+
     /* unregister real device's MMIO/PIO BARs */
     pt_unregister_regions(s);
 
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index 1e9de64..ae64544 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -1,11 +1,2142 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include "qemu-timer.h"
+#include "xen_backend.h"
 #include "xen_pci_passthrough.h"
 
+#define PT_MERGE_VALUE(value, data, val_mask) \
+    (((value) & (val_mask)) | ((data) & ~(val_mask)))
+
+#define PT_INVALID_REG          0xFFFFFFFF      /* invalid register value */
+
+/* prototype */
+
+static int pt_ptr_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data);
+static int pt_init_pci_config(XenPCIPassthroughState *s);
+
+
+/* helper */
+
+/* A return value of 1 means the capability should NOT be exposed to guest. */
+static int pt_hide_dev_cap(const HostPCIDevice *d, uint8_t grp_id)
+{
+    switch (grp_id) {
+    case PCI_CAP_ID_EXP:
+        /* The PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0. We should not try to expose it to guest.
+         *
+         * The datasheet is available at
+         * http://download.intel.com/design/network/datashts/82599_datasheet.pdf
+         *
+         * See 'Table 9.7. VF PCIe Configuration Space' of the datasheet, the
+         * PCI Express Capability Structure of the VF of Intel 82599 10GbE
+         * Controller looks trivial, e.g., the PCI Express Capabilities
+         * Register is 0, so the Capability Version is 0 and
+         * pt_pcie_size_init() would fail.
+         */
+        if (d->vendor_id == PCI_VENDOR_ID_INTEL &&
+            d->device_id == PCI_DEVICE_ID_INTEL_82599_VF) {
+            return 1;
+        }
+        break;
+    }
+    return 0;
+}
+
+/*   find emulate register group entry */
 XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
 {
+    XenPTRegGroup *entry = NULL;
+
+    /* find register group entry */
+    QLIST_FOREACH(entry, &s->reg_grp_tbl, entries) {
+        /* check address */
+        if ((entry->base_offset <= address)
+            && ((entry->base_offset + entry->size) > address)) {
+            return entry;
+        }
+    }
+
+    /* group entry not found */
     return NULL;
 }
 
+/* find emulate register entry */
 XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
 {
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+
+    /* find register entry */
+    QLIST_FOREACH(reg_entry, &reg_grp->reg_tbl_list, entries) {
+        reg = reg_entry->reg;
+        real_offset = reg_grp->base_offset + reg->offset;
+        /* check address */
+        if ((real_offset <= address)
+            && ((real_offset + reg->size) > address)) {
+            return reg_entry;
+        }
+    }
+
     return NULL;
 }
+
+/* parse BAR */
+static PTBarFlag pt_bar_reg_parse(XenPCIPassthroughState *s, XenPTRegInfo *reg)
+{
+    PCIDevice *d = &s->dev;
+    XenPTRegion *region = NULL;
+    PCIIORegion *r;
+    int index = 0;
+
+    /* check 64bit BAR */
+    index = pt_bar_offset_to_index(reg->offset);
+    if ((0 < index) && (index < PCI_ROM_SLOT)) {
+        int flags = s->real_device->io_regions[index - 1].flags;
+
+        if ((flags & IORESOURCE_MEM) && (flags & IORESOURCE_MEM_64)) {
+            region = &s->bases[index - 1];
+            if (region->bar_flag != PT_BAR_FLAG_UPPER) {
+                return PT_BAR_FLAG_UPPER;
+            }
+        }
+    }
+
+    /* check unused BAR */
+    r = &d->io_regions[index];
+    if (r->size == 0) {
+        return PT_BAR_FLAG_UNUSED;
+    }
+
+    /* for ExpROM BAR */
+    if (index == PCI_ROM_SLOT) {
+        return PT_BAR_FLAG_MEM;
+    }
+
+    /* check BAR I/O indicator */
+    if (s->real_device->io_regions[index].flags & IORESOURCE_IO) {
+        return PT_BAR_FLAG_IO;
+    } else {
+        return PT_BAR_FLAG_MEM;
+    }
+}
+
+
+/****************
+ * general register functions
+ */
+
+/* register initialization function */
+
+static int pt_common_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = reg->init_val;
+    return 0;
+}
+
+/* Read register functions */
+
+static int pt_byte_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint8_t *value, uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t valid_emu_mask = 0;
+
+    /* emulate byte register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+
+    /* emulate word register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_long_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+
+    /* emulate long register */
+    valid_emu_mask = reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+
+/* Write register functions */
+
+static int pt_byte_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint8_t *value, uint8_t dev_value,
+                             uint8_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint8_t writable_mask = 0;
+    uint8_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_word_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t dev_value,
+                             uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+static int pt_long_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint32_t *value, uint32_t dev_value,
+                             uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    return 0;
+}
+
+/* common restore register fonctions */
+static int pt_byte_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint8_t dev_value,
+                               uint8_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_byte(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+static int pt_word_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                               uint32_t real_offset, uint16_t dev_value,
+                               uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, reg->emu_mask);
+
+    return 0;
+}
+
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/********************
+ * Header Type0
+ */
+
+static int pt_vendor_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->vendor_id;
+    return 0;
+}
+static int pt_device_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = s->real_device->device_id;
+    return 0;
+}
+static int pt_status_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    uint32_t reg_field = 0;
+
+    /* find Header register group */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_CAPABILITY_LIST);
+    if (reg_grp_entry) {
+        /* find Capabilities Pointer register */
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_CAPABILITY_LIST);
+        if (reg_entry) {
+            /* check Capabilities Pointer register */
+            if (reg_entry->data) {
+                reg_field |= PCI_STATUS_CAP_LIST;
+            } else {
+                reg_field &= ~PCI_STATUS_CAP_LIST;
+            }
+        } else {
+            xen_shutdown_fatal_error("Internal error: Couldn't find XenPTReg*"
+                                     " for Capabilities Pointer register."
+                                     " (%s)\n", __func__);
+            return -1;
+        }
+    } else {
+        xen_shutdown_fatal_error("Internal error: Couldn't find XenPTRegGroup"
+                                 " for Header. (%s)\n", __func__);
+        return -1;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_header_type_reg_init(XenPCIPassthroughState *s,
+                                   XenPTRegInfo *reg, uint32_t real_offset,
+                                   uint32_t *data)
+{
+    /* read PCI_HEADER_TYPE */
+    *data = reg->init_val | 0x80;
+    return 0;
+}
+
+/* initialize Interrupt Pin register */
+static int pt_irqpin_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegInfo *reg, uint32_t real_offset,
+                              uint32_t *data)
+{
+    *data = pci_read_intx(s);
+    return 0;
+}
+
+/* Command register */
+static int pt_cmd_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = 0;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* emulate word register */
+    valid_emu_mask = emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint16_t *value, uint16_t dev_value,
+                            uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t wr_value = *value;
+    uint16_t emu_mask = reg->emu_mask;
+
+    if (s->is_virtfn) {
+        emu_mask |= PCI_COMMAND_MEMORY;
+    }
+
+    /* modify emulate register */
+    writable_mask = ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+
+    if (*value & PCI_COMMAND_INTX_DISABLE) {
+        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        if (s->machine_irq) {
+            throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+        }
+    }
+
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* mapping BAR */
+    pt_bar_mapping(s, wr_value & PCI_COMMAND_IO,
+                   wr_value & PCI_COMMAND_MEMORY);
+
+    return 0;
+}
+static int pt_cmd_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint16_t dev_value,
+                              uint16_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+    uint16_t restorable_mask = 0;
+
+    /* use I/O device register's value as restore value */
+    *value = pci_get_word(d->config + real_offset);
+
+    /* create value for restoring to I/O device register
+     * but do not include Fast Back-to-Back Enable bit.
+     */
+    restorable_mask = reg->emu_mask & ~PCI_COMMAND_FAST_BACK;
+    *value = PT_MERGE_VALUE(*value, dev_value, restorable_mask);
+
+    if (!s->machine_irq) {
+        *value |= PCI_COMMAND_INTX_DISABLE;
+    } else {
+        *value &= ~PCI_COMMAND_INTX_DISABLE;
+    }
+
+    return 0;
+}
+
+/* BAR */
+#define PT_BAR_MEM_RO_MASK      0x0000000F      /* BAR ReadOnly mask(Memory) */
+#define PT_BAR_MEM_EMU_MASK     0xFFFFFFF0      /* BAR emul mask(Memory) */
+#define PT_BAR_IO_RO_MASK       0x00000003      /* BAR ReadOnly mask(I/O) */
+#define PT_BAR_IO_EMU_MASK      0xFFFFFFFC      /* BAR emul mask(I/O) */
+
+static inline uint32_t base_address_with_flags(HostPCIIORegion *hr)
+{
+    if ((hr->flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_IO_MASK);
+    } else {
+        return hr->base_addr | (hr->flags & ~PCI_BASE_ADDRESS_MEM_MASK);
+    }
+}
+
+static int pt_bar_reg_init(XenPCIPassthroughState *s, XenPTRegInfo *reg,
+                           uint32_t real_offset, uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* set initial guest physical base address to -1 */
+    s->bases[index].e_physbase = -1;
+
+    /* set BAR flag */
+    s->bases[index].bar_flag = pt_bar_reg_parse(s, reg);
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED) {
+        reg_field = PT_INVALID_REG;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+static int pt_bar_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                           uint32_t *value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t valid_emu_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    int index;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use fixed-up value from kernel sysfs */
+    *value = base_address_with_flags(&s->real_device->io_regions[index]);
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* emulate BAR */
+    valid_emu_mask = bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+   return 0;
+}
+static int pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                            uint32_t *value, uint32_t dev_value,
+                            uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = &s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+    uint32_t new_addr, last_addr;
+    uint32_t prev_offset;
+    uint32_t r_size = 0;
+    int index = 0;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(d, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    r = &d->io_regions[index];
+    base = &s->bases[index];
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    /* set emulate mask and read-only mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        bar_ro_mask = PT_BAR_MEM_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        bar_ro_mask = PT_BAR_IO_RO_MASK | (r_size - 1);
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        break;
+    default:
+        break;
+    }
+
+    /* modify emulate register */
+    writable_mask = bar_emu_mask & ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* check whether we need to update the virtual region address or not */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        /* nothing to do */
+        break;
+    case PT_BAR_FLAG_IO:
+        new_addr = cfg_entry->data;
+        last_addr = new_addr + r_size - 1;
+        /* check invalid address */
+        if (last_addr <= new_addr || !new_addr || last_addr >= UINT16_MAX) {
+            /* check 64K range */
+            if ((last_addr >= UINT16_MAX) &&
+                (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask))) {
+                PT_WARN(d, "Guest attempt to set Base Address "
+                       "over the 64KB. (offset: 0x%02x,"
+                       " addr: 0x%08x, size: 0x%08x)\n",
+                       reg->offset, new_addr, r_size);
+            }
+            /* just remove mapping */
+            r->addr = PCI_BAR_UNMAPPED;
+            goto exit;
+        }
+        break;
+    case PT_BAR_FLAG_UPPER:
+        if (cfg_entry->data) {
+            if (cfg_entry->data != (PT_BAR_ALLF & ~bar_ro_mask)) {
+                PT_WARN(d, "Guest attempt to set high MMIO Base Address. "
+                        "Ignore mapping. "
+                        "(offset: 0x%02x, high address: 0x%08x)\n",
+                        reg->offset, cfg_entry->data);
+            }
+            /* clear lower address */
+            d->io_regions[index-1].addr = -1;
+        } else {
+            /* find lower 32bit BAR */
+            prev_offset = (reg->offset - 4);
+            reg_grp_entry = pt_find_reg_grp(s, prev_offset);
+            if (reg_grp_entry) {
+                reg_entry = pt_find_reg(reg_grp_entry, prev_offset);
+                if (reg_entry) {
+                    /* restore lower address */
+                    d->io_regions[index-1].addr = reg_entry->data;
+                } else {
+                    return -1;
+                }
+            } else {
+                return -1;
+            }
+        }
+
+        /* never mapping the 'empty' upper region,
+         * because we'll do it enough for the lower region.
+         */
+        r->addr = -1;
+        goto exit;
+    default:
+        break;
+    }
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+exit:
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR */
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, index, reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+static int pt_bar_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint32_t real_offset, uint32_t dev_value,
+                              uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t bar_emu_mask = 0;
+    int index = 0;
+
+    /* get BAR index */
+    index = pt_bar_offset_to_index(reg->offset);
+    if (index < 0) {
+        PT_ERR(&s->dev, "Internal error: Invalid BAR index [%d].\n", index);
+        return -1;
+    }
+
+    /* use value from kernel sysfs */
+    if (s->bases[index].bar_flag == PT_BAR_FLAG_UPPER) {
+        *value = s->real_device->io_regions[index - 1].base_addr >> 32;
+    } else {
+        *value = base_address_with_flags(&s->real_device->io_regions[index]);
+    }
+
+    /* set emulate mask depend on BAR flag */
+    switch (s->bases[index].bar_flag) {
+    case PT_BAR_FLAG_MEM:
+        bar_emu_mask = PT_BAR_MEM_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_IO:
+        bar_emu_mask = PT_BAR_IO_EMU_MASK;
+        break;
+    case PT_BAR_FLAG_UPPER:
+        bar_emu_mask = PT_BAR_ALLF;
+        break;
+    default:
+        break;
+    }
+
+    /* create value for restoring to I/O device register */
+    *value = PT_MERGE_VALUE(*value, dev_value, bar_emu_mask);
+
+    return 0;
+}
+
+/* write Exp ROM BAR */
+static int pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
+                                    XenPTReg *cfg_entry, uint32_t *value,
+                                    uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    PCIDevice *d = (PCIDevice *)&s->dev;
+    PCIIORegion *r;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    pcibus_t r_size = 0;
+    uint32_t bar_emu_mask = 0;
+    uint32_t bar_ro_mask = 0;
+
+    r = &d->io_regions[PCI_ROM_SLOT];
+    r_size = r->size;
+    base = &s->bases[PCI_ROM_SLOT];
+    /* align memory type resource size */
+    pt_get_emul_size(base->bar_flag, r_size);
+
+    /* set emulate mask and read-only mask */
+    bar_emu_mask = reg->emu_mask;
+    bar_ro_mask = (reg->ro_mask | (r_size - 1)) & ~PCI_ROM_ADDRESS_ENABLE;
+
+    /* modify emulate register */
+    writable_mask = ~bar_ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* update the corresponding virtual region address */
+    /*
+     * When guest code tries to get block size of mmio, it will write all "1"s
+     * into pci bar register. In this case, cfg_entry->data == writable_mask.
+     * Especially for devices with large mmio, the value of writable_mask
+     * is likely to be a guest physical address that has been mapped to ram
+     * rather than mmio. Remapping this value to mmio should be prevented.
+     */
+
+    if (cfg_entry->data != writable_mask) {
+        r->addr = cfg_entry->data;
+    }
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~bar_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* After BAR reg update, we need to remap BAR*/
+    reg_grp_entry = pt_find_reg_grp(s, PCI_COMMAND);
+    if (reg_grp_entry) {
+        reg_entry = pt_find_reg(reg_grp_entry, PCI_COMMAND);
+        if (reg_entry) {
+            pt_bar_mapping_one(s, PCI_ROM_SLOT,
+                               reg_entry->data & PCI_COMMAND_IO,
+                               reg_entry->data & PCI_COMMAND_MEMORY);
+        }
+    }
+
+    return 0;
+}
+/* restore ROM BAR */
+static int pt_exp_rom_bar_reg_restore(XenPCIPassthroughState *s,
+                                      XenPTReg *cfg_entry,
+                                      uint32_t real_offset,
+                                      uint32_t dev_value, uint32_t *value)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t v;
+
+    if (host_pci_get_long(s->real_device, PCI_ROM_ADDRESS, &v)) {
+        return -1;
+    }
+    /* use value from kernel sysfs */
+    *value = PT_MERGE_VALUE(v, dev_value, reg->emu_mask);
+    return 0;
+}
+
+/* Header Type0 reg static infomation table */
+static XenPTRegInfo pt_emu_reg_header0_tbl[] = {
+    /* Vendor ID reg */
+    {
+        .offset     = PCI_VENDOR_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_vendor_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Device ID reg */
+    {
+        .offset     = PCI_DEVICE_ID,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_device_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Command reg */
+    {
+        .offset     = PCI_COMMAND,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xF880,
+        .emu_mask   = 0x0740,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_cmd_reg_read,
+        .u.w.write  = pt_cmd_reg_write,
+        .u.w.restore  = pt_cmd_reg_restore,
+    },
+    /* Capabilities Pointer reg */
+    {
+        .offset     = PCI_CAPABILITY_LIST,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Status reg */
+    /* use emulated Cap Ptr value to initialize,
+     * so need to be declared after Cap Ptr reg
+     */
+    {
+        .offset     = PCI_STATUS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x06FF,
+        .emu_mask   = 0x0010,
+        .init       = pt_status_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Cache Line Size reg */
+    {
+        .offset     = PCI_CACHE_LINE_SIZE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Latency Timer reg */
+    {
+        .offset     = PCI_LATENCY_TIMER,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = pt_byte_reg_restore,
+    },
+    /* Header Type reg */
+    {
+        .offset     = PCI_HEADER_TYPE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0x00,
+        .init       = pt_header_type_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Line reg */
+    {
+        .offset     = PCI_INTERRUPT_LINE,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0x00,
+        .emu_mask   = 0xFF,
+        .init       = pt_common_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Interrupt Pin reg */
+    {
+        .offset     = PCI_INTERRUPT_PIN,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_irqpin_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* BAR 0 reg */
+    /* mask of BAR need to be decided later, depends on IO/MEM type */
+    {
+        .offset     = PCI_BASE_ADDRESS_0,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 1 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_1,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 2 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_2,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 3 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_3,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 4 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_4,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* BAR 5 reg */
+    {
+        .offset     = PCI_BASE_ADDRESS_5,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_bar_reg_read,
+        .u.dw.write = pt_bar_reg_write,
+        .u.dw.restore = pt_bar_reg_restore,
+    },
+    /* Expansion ROM BAR reg */
+    {
+        .offset     = PCI_ROM_ADDRESS,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x000007FE,
+        .emu_mask   = 0xFFFFF800,
+        .init       = pt_bar_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_exp_rom_bar_reg_write,
+        .u.dw.restore = pt_exp_rom_bar_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Vital Product Data Capability
+ */
+
+/* Vital Product Data Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vpd_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * Vendor Specific Capability
+ */
+
+/* Vendor Specific Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_vendor_tbl[] = {
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*****************************
+ * PCI Express Capability
+ */
+
+/* initialize Link Control register */
+static int pt_linkctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = 0;
+    uint8_t dev_type = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+    dev_type = (pci_get_byte(s->dev.config + real_offset - reg->offset
+                             + PCI_EXP_FLAGS)
+                & PCI_EXP_FLAGS_TYPE) >> 4;
+
+    /* no need to initialize in case of Root Complex Integrated Endpoint
+     * with cap_ver 1.x
+     */
+    if ((dev_type == PCI_EXP_TYPE_RC_END) && (cap_ver == 1)) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Device Control 2 register */
+static int pt_devctrl2_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    uint8_t cap_ver = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        *data = PT_INVALID_REG;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize Link Control 2 register */
+static int pt_linkctrl2_reg_init(XenPCIPassthroughState *s,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    uint32_t reg_field = 0;
+    uint8_t cap_ver = 0;
+
+    cap_ver = pci_get_byte(s->dev.config + real_offset - reg->offset
+                           + PCI_EXP_FLAGS)
+        & PCI_EXP_FLAGS_VERS;
+
+    /* no need to initialize in case of cap_ver 1.x */
+    if (cap_ver == 1) {
+        reg_field = PT_INVALID_REG;
+    } else {
+        /* set Supported Link Speed */
+        uint8_t lnkcap = pci_get_byte(s->dev.config + real_offset - reg->offset
+                                      + PCI_EXP_LNKCAP);
+        reg_field |= PCI_EXP_LNKCAP_SLS & lnkcap;
+    }
+
+    *data = reg_field;
+    return 0;
+}
+
+/* PCI Express Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pcie_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Device Capabilities reg */
+    {
+        .offset     = PCI_EXP_DEVCAP,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x1FFCFFFF,
+        .emu_mask   = 0x10000000,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_long_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Device Control reg */
+    {
+        .offset     = PCI_EXP_DEVCTL,
+        .size       = 2,
+        .init_val   = 0x2810,
+        .ro_mask    = 0x8400,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_common_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control reg */
+    {
+        .offset     = PCI_EXP_LNKCTL,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFC34,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Device Control 2 reg */
+    {
+        .offset     = 0x28,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFE0,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_devctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    /* Link Control 2 reg */
+    {
+        .offset     = 0x30,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xE040,
+        .emu_mask   = 0xFFFF,
+        .init       = pt_linkctrl2_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = pt_word_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/*********************************
+ * Power Management Capability
+ */
+
+/* initialize Power Management Capabilities register */
+static int pt_pmc_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+
+    if (s->power_mgmt) {
+        /* set Power Management Capabilities register */
+        s->pm_state->pmc_field = pci_get_word(d->config + real_offset);
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* initialize PCI Power Management Control/Status register */
+static int pt_pmcsr_reg_init(XenPCIPassthroughState *s,
+                             XenPTRegInfo *reg, uint32_t real_offset,
+                             uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t cap_ver  = 0;
+    uint16_t v = 0;
+
+    if (!s->power_mgmt) {
+        *data = reg->init_val;
+        return 0;
+    }
+
+    /* check PCI Power Management support version */
+    cap_ver = s->pm_state->pmc_field & PCI_PM_CAP_VER_MASK;
+
+    if (cap_ver > 2) {
+        /* set No Soft Reset */
+        s->pm_state->no_soft_reset =
+            pci_get_byte(d->config + real_offset) & PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    host_pci_get_word(s->real_device, real_offset, &v);
+    /* wake up real physical device */
+    switch (v & PCI_PM_CTRL_STATE_MASK) {
+    case 0:
+        break;
+    case 1:
+        PT_LOG(d, "Power state transition D1 -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        break;
+    case 2:
+        PT_LOG(d, "Power state transition D2 -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        usleep(200);
+        break;
+    case 3:
+        PT_LOG(d, "Power state transition D3hot -> D0active\n");
+        host_pci_set_word(s->real_device, real_offset, 0);
+        usleep(10 * 1000);
+        if (pt_init_pci_config(s)) {
+            return -1;
+        }
+        break;
+    }
+
+    *data = reg->init_val;
+    return 0;
+}
+/* read Power Management Control/Status register */
+static int pt_pmcsr_reg_read(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                             uint16_t *value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t valid_emu_mask = reg->emu_mask;
+
+    if (!s->power_mgmt) {
+        valid_emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    valid_emu_mask = valid_emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, cfg_entry->data, ~valid_emu_mask);
+
+    return 0;
+}
+/* reset Interrupt and I/O resource  */
+static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    PCIIORegion *r;
+    int i = 0;
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    /* unbind INTx */
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+
+    if (s->machine_irq) {
+        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
+                                    PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
+            PT_ERR(d, "Unbinding of interrupt failed!\n");
+        }
+    }
+
+    /* clear all virtual region address */
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        r = &d->io_regions[i];
+        r->addr = -1;
+    }
+
+    /* unmapping BAR */
+    pt_bar_mapping(s, 0, 0);
+}
+/* check power state transition */
+static int check_power_state(XenPCIPassthroughState *s)
+{
+    XenPTPM *pm_state = s->pm_state;
+    PCIDevice *d = &s->dev;
+    uint16_t read_val = 0;
+    uint16_t cur_state = 0;
+
+    /* get current power state */
+    if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                          &read_val)) {
+        return -1;
+    }
+    cur_state = read_val & PCI_PM_CTRL_STATE_MASK;
+
+    if (pm_state->req_state != cur_state) {
+        PT_ERR(d, "Failed to change power state. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, cur_state);
+        return -1;
+    }
+    return 0;
+}
+/* write Power Management Control/Status register */
+static void pt_from_d3hot_to_d0_with_reset(void *opaque)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTPM *pm_state = s->pm_state;
+    int ret = 0;
+
+    /* check power state */
+    ret = check_power_state(s);
+
+    if (ret < 0) {
+        goto out;
+    }
+
+    pt_init_pci_config(s);
+
+out:
+    /* power state transition flags off */
+    pm_state->flags &= ~PT_FLAG_TRANSITING;
+
+    qemu_free_timer(pm_state->pm_timer);
+    pm_state->pm_timer = NULL;
+}
+static void pt_default_power_transition(void *opaque)
+{
+    XenPCIPassthroughState *ptdev = opaque;
+    XenPTPM *pm_state = ptdev->pm_state;
+
+    /* check power state */
+    check_power_state(ptdev);
+
+    /* power state transition flags off */
+    pm_state->flags &= ~PT_FLAG_TRANSITING;
+
+    qemu_free_timer(pm_state->pm_timer);
+    pm_state->pm_timer = NULL;
+}
+static int pt_pmcsr_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                              uint16_t *value, uint16_t dev_value,
+                              uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    PCIDevice *d = &s->dev;
+    uint16_t emu_mask = reg->emu_mask;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    XenPTPM *pm_state = s->pm_state;
+
+    if (!s->power_mgmt) {
+        emu_mask |= PCI_PM_CTRL_STATE_MASK | PCI_PM_CTRL_NO_SOFT_RESET;
+    }
+
+    /* modify emulate register */
+    writable_mask = emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    if (!s->power_mgmt) {
+        return 0;
+    }
+
+    /* set I/O device power state */
+    pm_state->cur_state = dev_value & PCI_PM_CTRL_STATE_MASK;
+
+    /* set Guest requested PowerState */
+    pm_state->req_state = *value & PCI_PM_CTRL_STATE_MASK;
+
+    /* check power state transition or not */
+    if (pm_state->cur_state == pm_state->req_state) {
+        /* not power state transition */
+        return 0;
+    }
+
+    /* check enable power state transition */
+    if ((pm_state->req_state != 0) &&
+        (pm_state->cur_state > pm_state->req_state)) {
+        PT_ERR(d, "Invalid power transition. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, pm_state->cur_state);
+
+        return 0;
+    }
+
+    /* check if this device supports the requested power state */
+    if (((pm_state->req_state == 1) && !(pm_state->pmc_field & PCI_PM_CAP_D1))
+        || ((pm_state->req_state == 2) &&
+            !(pm_state->pmc_field & PCI_PM_CAP_D2))) {
+        PT_ERR(d, "Invalid power transition. "
+               "(requested state: %d, current state: %d)\n",
+               pm_state->req_state, pm_state->cur_state);
+
+        return 0;
+    }
+
+    /* in case of transition related to D3hot, it's necessary to wait 10 ms.
+     * But because writing to register will be performed later on actually,
+     * don't start QEMUTimer right now, just alloc and init QEMUTimer here.
+     */
+    if ((pm_state->cur_state == 3) || (pm_state->req_state == 3)) {
+        if (pm_state->req_state == 0) {
+            /* alloc and init QEMUTimer */
+            if (!pm_state->no_soft_reset) {
+                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                    pt_from_d3hot_to_d0_with_reset, s);
+
+                /* reset Interrupt and I/O resource mapping */
+                pt_reset_interrupt_and_io_mapping(s);
+            } else {
+                pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                                        pt_default_power_transition, s);
+            }
+        } else {
+            /* alloc and init QEMUTimer */
+            pm_state->pm_timer = qemu_new_timer_ms(rt_clock,
+                pt_default_power_transition, s);
+        }
+
+        /* set power state transition delay */
+        pm_state->pm_delay = 10;
+
+        /* power state transition flags on */
+        pm_state->flags |= PT_FLAG_TRANSITING;
+    }
+    /* in case of transition related to D0, D1 and D2,
+     * no need to use QEMUTimer.
+     * So, we perfom writing to register here and then read it back.
+     */
+    else {
+        /* write power state to I/O device register */
+        host_pci_set_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                          *value);
+
+        /* in case of transition related to D2,
+         * it's necessary to wait 200 usec.
+         * But because QEMUTimer do not support microsec unit right now,
+         * so we do wait ourself here.
+         */
+        if ((pm_state->cur_state == 2) || (pm_state->req_state == 2)) {
+            usleep(200);
+        }
+
+        /* check power state */
+        check_power_state(s);
+
+        /* recreate value for writing to I/O device register */
+        if (host_pci_get_word(s->real_device, pm_state->pm_base + PCI_PM_CTRL,
+                              value)) {
+            return -1;
+        }
+    }
+
+    return 0;
+}
+
+/* restore Power Management Control/Status register */
+static int pt_pmcsr_reg_restore(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint32_t real_offset, uint16_t dev_value,
+                                uint16_t *value)
+{
+    /* create value for restoring to I/O device register
+     * No need to restore, just clear PME Enable and PME Status bit
+     * Note: register type of PME Status bit is RW1C, so clear by writing 1b
+     */
+    *value = (dev_value & ~PCI_PM_CTRL_PME_ENABLE) | PCI_PM_CTRL_PME_STATUS;
+
+    return 0;
+}
+
+
+/* Power Management Capability reg static infomation table */
+static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Power Management Capabilities reg */
+    {
+        .offset     = PCI_CAP_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFFFF,
+        .emu_mask   = 0xF9C8,
+        .init       = pt_pmc_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_word_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* PCI Power Management Control/Status reg */
+    {
+        .offset     = PCI_PM_CTRL,
+        .size       = 2,
+        .init_val   = 0x0008,
+        .ro_mask    = 0xE1FC,
+        .emu_mask   = 0x8100,
+        .init       = pt_pmcsr_reg_init,
+        .u.w.read   = pt_pmcsr_reg_read,
+        .u.w.write  = pt_pmcsr_reg_write,
+        .u.w.restore  = pt_pmcsr_reg_restore,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/****************************
+ * Capabilities
+ */
+
+/* AER register operations */
+
+static void aer_save_one_register(XenPCIPassthroughState *s, int offset)
+{
+    PCIDevice *d = &s->dev;
+    uint32_t aer_base = s->pm_state->aer_base;
+    uint32_t val = 0;
+
+    if (host_pci_get_long(s->real_device, aer_base + offset, &val)) {
+        return;
+    }
+    pci_set_long(d->config + aer_base + offset, val);
+}
+static void pt_aer_reg_save(XenPCIPassthroughState *s)
+{
+    /* after reset, following register values should be restored.
+     * So, save them.
+     */
+    aer_save_one_register(s, PCI_ERR_UNCOR_MASK);
+    aer_save_one_register(s, PCI_ERR_UNCOR_SEVER);
+    aer_save_one_register(s, PCI_ERR_COR_MASK);
+    aer_save_one_register(s, PCI_ERR_CAP);
+}
+static void aer_restore_one_register(XenPCIPassthroughState *s, int offset)
+{
+    PCIDevice *d = &s->dev;
+    uint32_t aer_base = s->pm_state->aer_base;
+    uint32_t config = 0;
+
+    config = pci_get_long(d->config + aer_base + offset);
+    host_pci_set_long(s->real_device, aer_base + offset, config);
+}
+static void pt_aer_reg_restore(XenPCIPassthroughState *s)
+{
+    /* the following registers should be reconfigured to correct values
+     * after reset. restore them.
+     * other registers should not be reconfigured after reset
+     * if there is no reason
+     */
+    aer_restore_one_register(s, PCI_ERR_UNCOR_MASK);
+    aer_restore_one_register(s, PCI_ERR_UNCOR_SEVER);
+    aer_restore_one_register(s, PCI_ERR_COR_MASK);
+    aer_restore_one_register(s, PCI_ERR_CAP);
+}
+
+/* capability structure register group size functions */
+
+static int pt_reg_grp_size_init(XenPCIPassthroughState *s,
+                                const XenPTRegGroupInfo *grp_reg,
+                                uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+    return 0;
+}
+/* get Power Management Capability Structure register group size */
+static int pt_pm_size_init(XenPCIPassthroughState *s,
+                           const XenPTRegGroupInfo *grp_reg,
+                           uint32_t base_offset, uint8_t *size)
+{
+    *size = grp_reg->grp_size;
+
+    if (!s->power_mgmt) {
+        return 0;
+    }
+
+    s->pm_state = g_new0(XenPTPM, 1);
+
+    /* set Power Management Capability base offset */
+    s->pm_state->pm_base = base_offset;
+
+    /* find AER register and set AER Capability base offset */
+    s->pm_state->aer_base = host_pci_find_ext_cap_offset(s->real_device,
+                                                         PCI_EXT_CAP_ID_ERR);
+
+    /* save AER register */
+    if (s->pm_state->aer_base) {
+        pt_aer_reg_save(s);
+    }
+
+    return 0;
+}
+/* get Vendor Specific Capability Structure register group size */
+static int pt_vendor_size_init(XenPCIPassthroughState *s,
+                               const XenPTRegGroupInfo *grp_reg,
+                               uint32_t base_offset, uint8_t *size)
+{
+    *size = pci_get_byte(s->dev.config + base_offset + 0x02);
+    return 0;
+}
+/* get PCI Express Capability Structure register group size */
+static int pt_pcie_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t exp_flag = 0;
+    uint16_t type = 0;
+    uint16_t version = 0;
+    uint8_t pcie_size = 0;
+
+    exp_flag = pci_get_word(d->config + base_offset + PCI_EXP_FLAGS);
+    type = (exp_flag & PCI_EXP_FLAGS_TYPE) >> 4;
+    version = exp_flag & PCI_EXP_FLAGS_VERS;
+
+    /* calculate size depend on capability version and device/port type */
+    /* in case of PCI Express Base Specification Rev 1.x */
+    if (version == 1) {
+        /* The PCI Express Capabilities, Device Capabilities, and Device
+         * Status/Control registers are required for all PCI Express devices.
+         * The Link Capabilities and Link Status/Control are required for all
+         * Endpoints that are not Root Complex Integrated Endpoints. Endpoints
+         * are not required to implement registers other than those listed
+         * above and terminate the capability structure.
+         */
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+            pcie_size = 0x14;
+            break;
+        case PCI_EXP_TYPE_RC_END:
+            /* has no link */
+            pcie_size = 0x0C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
+                   type);
+            return -1;
+        }
+    }
+    /* in case of PCI Express Base Specification Rev 2.0 */
+    else if (version == 2) {
+        switch (type) {
+        case PCI_EXP_TYPE_ENDPOINT:
+        case PCI_EXP_TYPE_LEG_END:
+        case PCI_EXP_TYPE_RC_END:
+            /* For Functions that do not implement the registers,
+             * these spaces must be hardwired to 0b.
+             */
+            pcie_size = 0x3C;
+            break;
+        /* only EndPoint passthrough is supported */
+        case PCI_EXP_TYPE_ROOT_PORT:
+        case PCI_EXP_TYPE_UPSTREAM:
+        case PCI_EXP_TYPE_DOWNSTREAM:
+        case PCI_EXP_TYPE_PCI_BRIDGE:
+        case PCI_EXP_TYPE_PCIE_BRIDGE:
+        case PCI_EXP_TYPE_RC_EC:
+        default:
+            PT_ERR(d, "Internal error: Unsupported device/port type (%d).\n",
+                   type);
+            return -1;
+        }
+    } else {
+        PT_ERR(d, "Internal error: Unsupported capability version (%d).\n",
+               version);
+        return -1;
+    }
+
+    *size = pcie_size;
+    return 0;
+}
+
+static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
+    /* Header Type0 reg group */
+    {
+        .grp_id      = 0xFF,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x40,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_header0_tbl,
+    },
+    /* PCI PowerManagement Capability reg group */
+    {
+        .grp_id      = PCI_CAP_ID_PM,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = PCI_PM_SIZEOF,
+        .size_init   = pt_pm_size_init,
+        .emu_reg_tbl = pt_emu_reg_pm_tbl,
+    },
+    /* AGP Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vital Product Data Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VPD,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x08,
+        .size_init   = pt_reg_grp_size_init,
+        .emu_reg_tbl = pt_emu_reg_vpd_tbl,
+    },
+    /* Slot Identification reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SLOTID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x04,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI-X Capabilities List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_PCIX,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x18,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Vendor Specific Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_VNDR,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_vendor_size_init,
+        .emu_reg_tbl = pt_emu_reg_vendor_tbl,
+    },
+    /* SHPC Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SHPC,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* Subsystem ID and Subsystem Vendor ID Capability List Item reg group */
+    {
+        .grp_id     = PCI_CAP_ID_SSVID,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x08,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* AGP 8x Capability Structure reg group */
+    {
+        .grp_id     = PCI_CAP_ID_AGP3,
+        .grp_type   = GRP_TYPE_HARDWIRED,
+        .grp_size   = 0x30,
+        .size_init  = pt_reg_grp_size_init,
+    },
+    /* PCI Express Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_EXP,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_pcie_size_init,
+        .emu_reg_tbl = pt_emu_reg_pcie_tbl,
+    },
+    {
+        .grp_size = 0,
+    },
+};
+
+/* initialize Capabilities Pointer or Next Pointer register */
+static int pt_ptr_reg_init(XenPCIPassthroughState *s,
+                           XenPTRegInfo *reg, uint32_t real_offset,
+                           uint32_t *data)
+{
+    /* uint32_t reg_field = (uint32_t)s->dev.config[real_offset]; */
+    uint32_t reg_field = pci_get_byte(s->dev.config + real_offset);
+    int i;
+
+    /* find capability offset */
+    while (reg_field) {
+        for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+            if (pt_emu_reg_grp_tbl[i].grp_id == s->dev.config[reg_field]) {
+                if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+                    goto out;
+                }
+                /* ignore the 0 hardwired capability, find next one */
+                break;
+            }
+        }
+        /* next capability */
+        /* reg_field = (uint32_t)s->dev.config[reg_field + 1]; */
+        reg_field = pci_get_byte(s->dev.config + reg_field + 1);
+    }
+
+out:
+    *data = reg_field;
+    return 0;
+}
+
+
+/*************
+ * Main
+ */
+
+/* restore a part of I/O device register */
+static int pt_config_restore(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    uint32_t real_offset = 0;
+    uint32_t read_val = 0;
+    uint32_t val = 0;
+    int rc = 0;
+
+    /* find emulate register group entry */
+    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
+        /* find emulate register entry */
+        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
+            reg = reg_entry->reg;
+
+            /* check whether restoring is needed */
+            if (!reg->u.b.restore) {
+                continue;
+            }
+
+            real_offset = reg_grp_entry->base_offset + reg->offset;
+
+            /* read I/O device register value */
+            rc = host_pci_get_block(s->real_device, real_offset,
+                                    (uint8_t *)&read_val, reg->size);
+
+            if (rc < 0) {
+                PT_ERR(&s->dev, "pci_read_block failed. "
+                       "return value: %d.\n", rc);
+                memset(&read_val, 0xff, reg->size);
+            }
+
+            val = 0;
+
+            /* restore based on register size */
+            switch (reg->size) {
+            case 1:
+                /* byte register */
+                rc = reg->u.b.restore(s, reg_entry, real_offset,
+                                      (uint8_t)read_val, (uint8_t *)&val);
+                break;
+            case 2:
+                /* word register */
+                rc = reg->u.w.restore(s, reg_entry, real_offset,
+                                      (uint16_t)read_val, (uint16_t *)&val);
+                break;
+            case 4:
+                /* double word register */
+                rc = reg->u.dw.restore(s, reg_entry, real_offset,
+                                       (uint32_t)read_val, (uint32_t *)&val);
+                break;
+            }
+
+            /* restoring error */
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid restoring."
+                                         " (%s, rc: %d)\n", __func__, rc);
+                return -1;
+            }
+
+            PT_LOG_CONFIG(&s->dev, real_offset, val, reg->size);
+
+            rc = host_pci_set_block(s->real_device, real_offset,
+                                    (uint8_t *)&val, reg->size);
+
+            if (rc < 0) {
+                PT_ERR(&s->dev, "pci_write_block failed. "
+                       "return value: %d.\n", rc);
+                return -1;
+            }
+        }
+    }
+
+    /* if AER supported, restore it */
+    if (s->pm_state->aer_base) {
+        pt_aer_reg_restore(s);
+    }
+    return 0;
+}
+/* reinitialize all emulate registers */
+static int pt_config_reinit(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegInfo *reg = NULL;
+    int rc = 0;
+
+    /* find emulate register group entry */
+    QLIST_FOREACH(reg_grp_entry, &s->reg_grp_tbl, entries) {
+        /* find emulate register entry */
+        QLIST_FOREACH(reg_entry, &reg_grp_entry->reg_tbl_list, entries) {
+            reg = reg_entry->reg;
+            if (reg->init) {
+                /* initialize emulate register */
+                rc = reg->init(s, reg_entry->reg,
+                               reg_grp_entry->base_offset + reg->offset,
+                               &reg_entry->data);
+                if (rc < 0) {
+                    return rc;
+                }
+            }
+        }
+    }
+    return 0;
+}
+
+static int pt_init_pci_config(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    int rc = 0;
+
+    PT_LOG(d, "Reinitialize PCI configuration registers due to power state"
+           " transition with internal reset.\n");
+
+    /* restore a part of I/O device register */
+    rc = pt_config_restore(s);
+    if (rc < 0) {
+        return rc;
+    }
+
+    /* reinitialize all emulate register */
+    rc = pt_config_reinit(s);
+    if (rc < 0) {
+        return rc;
+    }
+
+    /* rebind machine_irq to device */
+    if (s->machine_irq != 0) {
+        uint8_t e_device = PCI_SLOT(s->dev.devfn);
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq, 0,
+                                       e_device, e_intx);
+        if (rc < 0) {
+            PT_ERR(d, "Rebinding of interrupt failed! rc=%d\n", rc);
+        }
+    }
+
+    return rc;
+}
+
+static uint8_t find_cap_offset(XenPCIPassthroughState *s, uint8_t cap)
+{
+    uint8_t id;
+    int max_cap = 48;
+    uint8_t pos = PCI_CAPABILITY_LIST;
+    uint8_t status = 0;
+
+    if (host_pci_get_byte(s->real_device, PCI_STATUS, &status)) {
+        return 0;
+    }
+    if ((status & PCI_STATUS_CAP_LIST) == 0) {
+        return 0;
+    }
+
+    while (max_cap--) {
+        if (host_pci_get_byte(s->real_device, pos, &pos)) {
+            break;
+        }
+        if (pos < 0x40) {
+            break;
+        }
+
+        pos &= ~3;
+        if (host_pci_get_byte(s->real_device, pos + PCI_CAP_LIST_ID, &id)) {
+            break;
+        }
+
+        if (id == 0xff) {
+            break;
+        }
+        if (id == cap) {
+            return pos;
+        }
+
+        pos += PCI_CAP_LIST_NEXT;
+    }
+    return 0;
+}
+
+static int pt_config_reg_init(XenPCIPassthroughState *s,
+                              XenPTRegGroup *reg_grp, XenPTRegInfo *reg)
+{
+    XenPTReg *reg_entry;
+    uint32_t data = 0;
+    int rc = 0;
+
+    reg_entry = g_new0(XenPTReg, 1);
+    reg_entry->reg = reg;
+
+    if (reg->init) {
+        /* initialize emulate register */
+        rc = reg->init(s, reg_entry->reg,
+                       reg_grp->base_offset + reg->offset, &data);
+        if (rc < 0) {
+            free(reg_entry);
+            return rc;
+        }
+        if (data == PT_INVALID_REG) {
+            /* free unused BAR register entry */
+            free(reg_entry);
+            return 0;
+        }
+        /* set register value */
+        reg_entry->data = data;
+    }
+    /* list add register entry */
+    QLIST_INSERT_HEAD(&reg_grp->reg_tbl_list, reg_entry, entries);
+
+    return 0;
+}
+
+int pt_config_init(XenPCIPassthroughState *s)
+{
+    XenPTRegGroup *reg_grp_entry = NULL;
+    uint32_t reg_grp_offset = 0;
+    XenPTRegInfo *reg_tbl = NULL;
+    int i, j, rc;
+
+    QLIST_INIT(&s->reg_grp_tbl);
+
+    for (i = 0; pt_emu_reg_grp_tbl[i].grp_size != 0; i++) {
+        if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) {
+            if (pt_hide_dev_cap(s->real_device,
+                                pt_emu_reg_grp_tbl[i].grp_id)) {
+                continue;
+            }
+
+            reg_grp_offset = find_cap_offset(s, pt_emu_reg_grp_tbl[i].grp_id);
+
+            if (!reg_grp_offset) {
+                continue;
+            }
+        }
+
+        reg_grp_entry = g_new0(XenPTRegGroup, 1);
+        QLIST_INIT(&reg_grp_entry->reg_tbl_list);
+        QLIST_INSERT_HEAD(&s->reg_grp_tbl, reg_grp_entry, entries);
+
+        reg_grp_entry->base_offset = reg_grp_offset;
+        reg_grp_entry->reg_grp = pt_emu_reg_grp_tbl + i;
+        if (pt_emu_reg_grp_tbl[i].size_init) {
+            /* get register group size */
+            rc = pt_emu_reg_grp_tbl[i].size_init(s, reg_grp_entry->reg_grp,
+                                                 reg_grp_offset,
+                                                 &reg_grp_entry->size);
+            if (rc < 0) {
+                pt_config_delete(s);
+                return rc;
+            }
+        }
+
+        if (pt_emu_reg_grp_tbl[i].grp_type == GRP_TYPE_EMU) {
+            if (pt_emu_reg_grp_tbl[i].emu_reg_tbl) {
+                reg_tbl = pt_emu_reg_grp_tbl[i].emu_reg_tbl;
+                /* initialize capability register */
+                for (j = 0; reg_tbl->size != 0; j++, reg_tbl++) {
+                    /* initialize capability register */
+                    rc = pt_config_reg_init(s, reg_grp_entry, reg_tbl);
+                    if (rc < 0) {
+                        pt_config_delete(s);
+                        return rc;
+                    }
+                }
+            }
+        }
+        reg_grp_offset = 0;
+    }
+
+    return 0;
+}
+
+/* delete all emulate register */
+void pt_config_delete(XenPCIPassthroughState *s)
+{
+    struct XenPTRegGroup *reg_group, *next_grp;
+    struct XenPTReg *reg, *next_reg;
+
+    /* free Power Management info table */
+    if (s->pm_state) {
+        if (s->pm_state->pm_timer) {
+            qemu_del_timer(s->pm_state->pm_timer);
+            qemu_free_timer(s->pm_state->pm_timer);
+            s->pm_state->pm_timer = NULL;
+        }
+
+        g_free(s->pm_state);
+    }
+
+    /* free all register group entry */
+    QLIST_FOREACH_SAFE(reg_group, &s->reg_grp_tbl, entries, next_grp) {
+        /* free all register entry */
+        QLIST_FOREACH_SAFE(reg, &reg_group->reg_tbl_list, entries, next_reg) {
+            QLIST_REMOVE(reg, entries);
+            g_free(reg);
+        }
+
+        QLIST_REMOVE(reg_group, entries);
+        g_free(reg_group);
+    }
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:47:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdO7-0003uQ-7u; Thu, 24 Nov 2011 17:47:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTdO5-0003tj-4J
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:47:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156754!58158398!1
X-Originating-IP: [208.97.132.74]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29261 invoked from network); 24 Nov 2011 17:45:55 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-27.messagelabs.com with SMTP;
	24 Nov 2011 17:45:55 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id B50737EC063;
	Thu, 24 Nov 2011 09:46:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=sZ/eDPlxwMKHr5T8dHVS5eeLQx3I9Axuz78Z0dtjdpXC
	/+ysW9dU2JCABdhBWRGbn5WwBcERa7gqD7RjVLkIsTbqzFBv/wMKDiTnwQRzuqyF
	GDXRoLB7W2m9uH6PyDhLALi2Y0+UJoDnmJc7pU69/e4hd65K8PwTpvqBNFxO+zw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=xLg4SC8uIByfWGDHfr0pXiitgYA=; b=jaZ/cv31
	DnleIpCLUfWeIkeJRKxNceAzKm+UETPA4ioEUsFZDjoyIR0mIjHuiQkEN8WYNN5j
	OA7JTbSe8UU8w6UAfjaEd0ojSZwXVIL57WISpHl9HBUgvSbZr+APWVBtPrrMYxrb
	13nDWLZFQEAQqhK32Xbs/VujSYa9021twXU=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 3AA967EC060; 
	Thu, 24 Nov 2011 09:46:37 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 09:46:37 -0800
Message-ID: <c06f47a05c874c3c08eb516cf7c3ac2c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124160707.GK77868@ocelot.phlegethon.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e22610ef339ab7ddd2f6.1322082673@xdev.gridcentric.ca>
	<20111124160707.GK77868@ocelot.phlegethon.org>
Date: Thu, 24 Nov 2011 09:46:37 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 06 of 14] Don't lose track of the log dirty
 bitmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Confirmed that your (simpler) patch solves the issue
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks
Andres
> At 16:11 -0500 on 23 Nov (1322064673), Andres Lagar-Cavilla wrote:
>> hap_log_dirty_init unconditionally sets the top of the log dirty
>> bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
>> then leaked, and the host crashes on an ASSERT when the domain is
>> cleaned up. Fixing it here.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r e8f0709af2b7 -r e22610ef339a xen/arch/x86/mm/hap/hap.c
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -224,11 +224,18 @@ static void hap_clean_dirty_bitmap(struc
>>  void hap_logdirty_init(struct domain *d)
>>  {
>>      struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
>> -    if ( paging_mode_log_dirty(d) && dirty_vram )
>> +    if ( paging_mode_log_dirty(d) )
>>      {
>> -        paging_log_dirty_disable(d);
>> -        xfree(dirty_vram);
>> -        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
>> +        if ( dirty_vram )
>> +        {
>> +            paging_log_dirty_disable(d);
>> +            xfree(dirty_vram);
>> +            dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
>> +        } else {
>> +            /* We still need to clean up the bitmap, because
>> +             * init below will overwrite it */
>> +            paging_free_log_dirty_bitmap(d);
>
> That's not safe - in the particular case you're worried about there are
> concurrent users of this bitmap.  I think the only sane way to deal with
> this is to make sure the initialization of log_dirty.top to INVALID_MFN
> happens once at start of day, and remove it from the functions that get
> called mulitple times.
>
> Something like this:
>
> diff -r f71ff2f7b604 xen/arch/x86/mm/paging.c
> --- a/xen/arch/x86/mm/paging.c	Thu Nov 24 15:20:57 2011 +0000
> +++ b/xen/arch/x86/mm/paging.c	Thu Nov 24 16:05:46 2011 +0000
> @@ -595,7 +595,6 @@ void paging_log_dirty_init(struct domain
>      d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
>      d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
>      d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
> -    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
>  }
>
>  /* This function fress log dirty bitmap resources. */
> @@ -617,6 +616,11 @@ int paging_domain_init(struct domain *d,
>
>      mm_lock_init(&d->arch.paging.lock);
>
> +    /* This must be initialized separately from the rest of the
> +     * log-dirty init code as that can be called more than once and we
> +     * don't want to leak any active log-dirty bitmaps */
> +    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
> +
>      /* The order of the *_init calls below is important, as the later
>       * ones may rewrite some common fields.  Shadow pagetables are the
>       * default... */
>
> Does that make sense to you?
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:47:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdO7-0003uQ-7u; Thu, 24 Nov 2011 17:47:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTdO5-0003tj-4J
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:47:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322156754!58158398!1
X-Originating-IP: [208.97.132.74]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29261 invoked from network); 24 Nov 2011 17:45:55 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-27.messagelabs.com with SMTP;
	24 Nov 2011 17:45:55 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id B50737EC063;
	Thu, 24 Nov 2011 09:46:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=sZ/eDPlxwMKHr5T8dHVS5eeLQx3I9Axuz78Z0dtjdpXC
	/+ysW9dU2JCABdhBWRGbn5WwBcERa7gqD7RjVLkIsTbqzFBv/wMKDiTnwQRzuqyF
	GDXRoLB7W2m9uH6PyDhLALi2Y0+UJoDnmJc7pU69/e4hd65K8PwTpvqBNFxO+zw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=xLg4SC8uIByfWGDHfr0pXiitgYA=; b=jaZ/cv31
	DnleIpCLUfWeIkeJRKxNceAzKm+UETPA4ioEUsFZDjoyIR0mIjHuiQkEN8WYNN5j
	OA7JTbSe8UU8w6UAfjaEd0ojSZwXVIL57WISpHl9HBUgvSbZr+APWVBtPrrMYxrb
	13nDWLZFQEAQqhK32Xbs/VujSYa9021twXU=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 3AA967EC060; 
	Thu, 24 Nov 2011 09:46:37 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 09:46:37 -0800
Message-ID: <c06f47a05c874c3c08eb516cf7c3ac2c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124160707.GK77868@ocelot.phlegethon.org>
References: <patchbomb.1322082667@xdev.gridcentric.ca>
	<e22610ef339ab7ddd2f6.1322082673@xdev.gridcentric.ca>
	<20111124160707.GK77868@ocelot.phlegethon.org>
Date: Thu, 24 Nov 2011 09:46:37 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 06 of 14] Don't lose track of the log dirty
 bitmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Confirmed that your (simpler) patch solves the issue
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks
Andres
> At 16:11 -0500 on 23 Nov (1322064673), Andres Lagar-Cavilla wrote:
>> hap_log_dirty_init unconditionally sets the top of the log dirty
>> bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
>> then leaked, and the host crashes on an ASSERT when the domain is
>> cleaned up. Fixing it here.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> diff -r e8f0709af2b7 -r e22610ef339a xen/arch/x86/mm/hap/hap.c
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -224,11 +224,18 @@ static void hap_clean_dirty_bitmap(struc
>>  void hap_logdirty_init(struct domain *d)
>>  {
>>      struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
>> -    if ( paging_mode_log_dirty(d) && dirty_vram )
>> +    if ( paging_mode_log_dirty(d) )
>>      {
>> -        paging_log_dirty_disable(d);
>> -        xfree(dirty_vram);
>> -        dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
>> +        if ( dirty_vram )
>> +        {
>> +            paging_log_dirty_disable(d);
>> +            xfree(dirty_vram);
>> +            dirty_vram = d->arch.hvm_domain.dirty_vram = NULL;
>> +        } else {
>> +            /* We still need to clean up the bitmap, because
>> +             * init below will overwrite it */
>> +            paging_free_log_dirty_bitmap(d);
>
> That's not safe - in the particular case you're worried about there are
> concurrent users of this bitmap.  I think the only sane way to deal with
> this is to make sure the initialization of log_dirty.top to INVALID_MFN
> happens once at start of day, and remove it from the functions that get
> called mulitple times.
>
> Something like this:
>
> diff -r f71ff2f7b604 xen/arch/x86/mm/paging.c
> --- a/xen/arch/x86/mm/paging.c	Thu Nov 24 15:20:57 2011 +0000
> +++ b/xen/arch/x86/mm/paging.c	Thu Nov 24 16:05:46 2011 +0000
> @@ -595,7 +595,6 @@ void paging_log_dirty_init(struct domain
>      d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
>      d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
>      d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
> -    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
>  }
>
>  /* This function fress log dirty bitmap resources. */
> @@ -617,6 +616,11 @@ int paging_domain_init(struct domain *d,
>
>      mm_lock_init(&d->arch.paging.lock);
>
> +    /* This must be initialized separately from the rest of the
> +     * log-dirty init code as that can be called more than once and we
> +     * don't want to leak any active log-dirty bitmaps */
> +    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
> +
>      /* The order of the *_init calls below is important, as the later
>       * ones may rewrite some common fields.  Shadow pagetables are the
>       * default... */
>
> Does that make sense to you?
>
> Tim.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:48:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdPQ-0004Fx-02; Thu, 24 Nov 2011 17:48:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdPP-0004EI-04
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:48:27 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18224 invoked from network); 24 Nov 2011 17:44:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809598"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:44:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:44:59 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ4027444;	Thu, 24 Nov 2011 09:44:57 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:32 +0000
Message-ID: <1322156679-9441-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 03/10] pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index 6b42515..56a404b 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -392,6 +392,7 @@
 #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
+#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
 #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:48:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdPQ-0004Fx-02; Thu, 24 Nov 2011 17:48:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdPP-0004EI-04
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:48:27 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18224 invoked from network); 24 Nov 2011 17:44:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809598"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:44:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:44:59 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ4027444;	Thu, 24 Nov 2011 09:44:57 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:32 +0000
Message-ID: <1322156679-9441-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 03/10] pci_regs: Add PCI_EXP_TYPE_PCIE_BRIDGE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_regs.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_regs.h b/hw/pci_regs.h
index 6b42515..56a404b 100644
--- a/hw/pci_regs.h
+++ b/hw/pci_regs.h
@@ -392,6 +392,7 @@
 #define  PCI_EXP_TYPE_UPSTREAM	0x5	/* Upstream Port */
 #define  PCI_EXP_TYPE_DOWNSTREAM 0x6	/* Downstream Port */
 #define  PCI_EXP_TYPE_PCI_BRIDGE 0x7	/* PCI/PCI-X Bridge */
+#define  PCI_EXP_TYPE_PCIE_BRIDGE 0x8   /* PCI/PCI-X to PCIE Bridge */
 #define  PCI_EXP_TYPE_RC_END	0x9	/* Root Complex Integrated Endpoint */
 #define  PCI_EXP_TYPE_RC_EC     0xa     /* Root Complex Event Collector */
 #define PCI_EXP_FLAGS_SLOT	0x0100	/* Slot implemented */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:48:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:48:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdPW-0004I7-EO; Thu, 24 Nov 2011 17:48:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdPU-0004Fn-Ml
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:48:33 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!4
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18401 invoked from network); 24 Nov 2011 17:45:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:45:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809604"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:06 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ8027444;	Thu, 24 Nov 2011 09:45:04 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:36 +0000
Message-ID: <1322156679-9441-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 07/10] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    2 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  831 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough.h             |  282 ++++++++++++
 hw/xen_pci_passthrough_config_init.c |   11 +
 xen-all.c                            |   12 +
 6 files changed, 1141 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c

diff --git a/Makefile.target b/Makefile.target
index e527c1b..33435a3 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -221,6 +221,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
new file mode 100644
index 0000000..998470b
--- /dev/null
+++ b/hw/xen_pci_passthrough.c
@@ -0,0 +1,831 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       <ptdev->msi_trans_en is false>
+ *         - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       <ptdev->msi_trans_en is false>
+ *         - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+
+#define PCI_BAR_ENTRIES (6)
+
+#define PT_NR_IRQS          (256)
+char mapped_machine_irq[PT_NR_IRQS] = {0};
+
+void pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+
+/* Config Space */
+static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
+{
+    /* check offset range */
+    if (address >= 0xFF) {
+        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        PT_ERR(d, "Failed to access register with invalid access length. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (address & (len - 1)) {
+        PT_ERR(d, "Failed to access register with invalid access size "
+               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = address;
+
+    if (pt_pci_config_access_check(d, address, len)) {
+        goto exit;
+    }
+
+    /* check power state transition flags */
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        /* can't accept until previous power state transition is completed.
+         * so finish previous request here.
+         */
+        PT_WARN(d, "Guest want to write during power state transition\n");
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, address);
+    if (reg_grp_entry) {
+        /* check 0 Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, address, (uint8_t *)&val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (address & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((address & 3) << 3);
+
+exit:
+    PT_LOG_CONFIG(d, address, val, len);
+    return val;
+}
+
+static void pt_pci_write_config(PCIDevice *d, uint32_t address,
+                                uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = address;
+    XenPTRegInfo *reg = NULL;
+
+    if (pt_pci_config_access_check(d, address, len)) {
+        return;
+    }
+
+    PT_LOG_CONFIG(d, address, val, len);
+
+    /* check unused BAR register */
+    index = pt_bar_offset_to_index(address);
+    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
+        PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                "Register. (addr: 0x%02x, len: %d)\n", address, len);
+    }
+
+    /* check power state transition flags */
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        /* can't accept until previous power state transition is completed.
+         * so finish previous request here.
+         */
+        PT_WARN(d, "Guest want to write during power state transition\n");
+        return;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, address);
+    if (reg_grp_entry) {
+        /* check 0 Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            PT_WARN(d, "Access to 0 Hardwired register. "
+                    "(addr: 0x%02x, len: %d)\n", address, len);
+            return;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, address,
+                             (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (address & 3) << 3;
+    val <<= (address & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to host_pci_device */
+    val >>= (address & 3) << 3;
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = host_pci_set_block(s->real_device, address, (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* ioport/iomem space*/
+static void pt_iomem_map(XenPCIPassthroughState *s, int i,
+                         pcibus_t e_phys, pcibus_t e_size, int type)
+{
+    PCIIORegion *r = &s->dev.io_regions[i];
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int ret = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "e_phys=%#"PRIx64" maddr=%#"PRIx64" type=%d"
+           " len=%#"PRIx64" index=%d first_map=%d\n",
+           e_phys, s->bases[i].access.maddr, type,
+           e_size, i, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        memory_region_del_subregion(r->address_space,
+                                    r->memory);
+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                               old_ebase >> XC_PAGE_SHIFT,
+                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                               DPCI_REMOVE_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "remove old mapping failed!\n");
+            return;
+        }
+    }
+
+    /* map only valid guest address */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        memory_region_add_subregion_overlap(r->address_space,
+                                            e_phys, r->memory, 1);
+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                                   DPCI_ADD_MAPPING);
+
+        if (ret != 0) {
+            PT_ERR(&s->dev, "create new mapping failed!\n");
+        }
+    }
+}
+
+static void pt_ioport_map(XenPCIPassthroughState *s, int i,
+                          pcibus_t e_phys, pcibus_t e_size, int type)
+{
+    PCIIORegion *r = &s->dev.io_regions[i];
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int ret = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "e_phys=%#04"PRIx64" pio_base=%#04"PRIx64" len=%"PRId64
+           " index=%d first_map=%d\n",
+           e_phys, s->bases[i].access.pio_base, e_size, i, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        memory_region_del_subregion(r->address_space,
+                                    r->memory);
+        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, old_ebase,
+                                       s->bases[i].access.pio_base, e_size,
+                                       DPCI_REMOVE_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "remove old mapping failed!\n");
+            return;
+        }
+    }
+
+    /* map only valid guest address (include 0) */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        memory_region_add_subregion_overlap(r->address_space,
+                                            e_phys, r->memory, 1);
+        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, e_phys,
+                                       s->bases[i].access.pio_base, e_size,
+                                       DPCI_ADD_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "create new mapping failed!\n");
+        }
+    }
+
+}
+
+
+/* mapping BAR */
+
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable)
+{
+    PCIDevice *dev = &s->dev;
+    PCIIORegion *r;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    pcibus_t r_size = 0, r_addr = PCI_BAR_UNMAPPED;
+    int rc = 0;
+
+    r = &dev->io_regions[bar];
+
+    /* check valid region */
+    if (!r->size) {
+        return;
+    }
+
+    base = &s->bases[bar];
+    /* skip unused BAR or upper 64bit BAR */
+    if ((base->bar_flag == PT_BAR_FLAG_UNUSED)
+        || (base->bar_flag == PT_BAR_FLAG_UPPER)) {
+           return;
+    }
+
+    /* copy region address to temporary */
+    r_addr = r->addr;
+
+    /* need unmapping in case I/O Space or Memory Space disable */
+    if (((base->bar_flag == PT_BAR_FLAG_IO) && !io_enable) ||
+        ((base->bar_flag == PT_BAR_FLAG_MEM) && !mem_enable)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+    if ((bar == PCI_ROM_SLOT) && (r_addr != PCI_BAR_UNMAPPED)) {
+        reg_grp_entry = pt_find_reg_grp(s, PCI_ROM_ADDRESS);
+        if (reg_grp_entry) {
+            reg_entry = pt_find_reg(reg_grp_entry, PCI_ROM_ADDRESS);
+            if (reg_entry && !(reg_entry->data & PCI_ROM_ADDRESS_ENABLE)) {
+                r_addr = PCI_BAR_UNMAPPED;
+            }
+        }
+    }
+
+    /* prevent guest software mapping memory resource to 00000000h */
+    if ((base->bar_flag == PT_BAR_FLAG_MEM) && (r_addr == 0)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    rc = pci_check_bar_overlap(dev, r_addr, r_size, r->type);
+    if (rc) {
+        PT_WARN(dev, "Region: %d (addr: %#"FMT_PCIBUS
+                ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                bar, r_addr, r_size);
+    }
+
+    /* check whether we need to update the mapping or not */
+    if (r_addr != s->bases[bar].e_physbase) {
+        /* mapping BAR */
+        if (base->bar_flag == PT_BAR_FLAG_IO) {
+            pt_ioport_map(s, bar, r_addr, r_size, r->type);
+        } else {
+            pt_iomem_map(s, bar, r_addr, r_size, r->type);
+        }
+    }
+}
+
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable)
+{
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        pt_bar_mapping_one(s, i, io_enable, mem_enable);
+    }
+}
+
+static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
+{
+    PCIDevice *d = o;
+    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+    return 0;
+}
+static void bar_write(void *o, target_phys_addr_t addr,
+                      uint64_t data, unsigned size)
+{
+    PCIDevice* d = o;
+    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = bar_read,
+    .write = bar_write,
+};
+
+/* register regions */
+static int pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    uint32_t bar_data = 0;
+    HostPCIDevice *d = s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr && r->size) {
+            s->bases[i].e_physbase = r->base_addr;
+            s->bases[i].access.u = r->base_addr;
+
+            /* Register current region */
+            if (r->flags & IORESOURCE_IO) {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-io", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_IO,
+                                 &s->bar[i]);
+            } else if (r->flags & IORESOURCE_PREFETCH) {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-mem", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                                 &s->bar[i]);
+            } else {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-mem", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_MEMORY,
+                                 &s->bar[i]);
+            }
+
+            PT_LOG(&s->dev, "IO region registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64")\n",
+                   r->size, r->base_addr);
+        }
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].e_physbase = d->rom.base_addr;
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL, &s->dev.qdev,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64")\n",
+               d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    int i, type, rc;
+    uint32_t e_size;
+    PCIDevice *d = &s->dev;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        e_size = s->bases[i].e_size;
+        if ((e_size == 0) || (s->bases[i].e_physbase == PT_PCI_BAR_UNMAPPED)) {
+            continue;
+        }
+
+        type = d->io_regions[i].type;
+
+        if (type == PCI_BASE_ADDRESS_SPACE_MEMORY
+            || type == PCI_BASE_ADDRESS_MEM_PREFETCH) {
+            rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                    s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                    s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                    (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                    DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old mem mapping failed!\n");
+                continue;
+            }
+
+        } else if (type == PCI_BASE_ADDRESS_SPACE_IO) {
+            rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                        s->bases[i].e_physbase,
+                        s->bases[i].access.pio_base,
+                        e_size,
+                        DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old io mapping failed!\n");
+                continue;
+            }
+        }
+    }
+}
+
+static int pt_initfn(PCIDevice *pcidev)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        PT_ERR(pcidev, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    PT_LOG(pcidev, "Assigning real physical device %02x:%02x.%x"
+           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    s->real_device = host_pci_device_get(bus, slot, func);
+    if (!s->real_device) {
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device->is_virtfn;
+    if (s->is_virtfn) {
+        PT_LOG(pcidev, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+               s->real_device->domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (host_pci_get_block(s->real_device, 0, pcidev->config,
+                           PCI_CONFIG_SPACE_SIZE) == -1) {
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
+    /* Handle real device's MMIO/PIO BARs */
+    pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        PT_LOG(pcidev, "no pin interrupt\n");
+        goto out;
+    }
+
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        PT_ERR(pcidev, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+               machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        host_pci_set_word(s->real_device,
+                          PCI_COMMAND,
+                          pci_get_word(s->dev.config + PCI_COMMAND)
+                          | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (rc < 0 && machine_irq != 0) {
+        uint8_t e_device = PCI_SLOT(s->dev.devfn);
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq, 0,
+                                       e_device, e_intx);
+        if (rc < 0) {
+            PT_ERR(pcidev, "Binding of interrupt %i failed! (rc: %d)\n",
+                   e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            host_pci_set_word(s->real_device, PCI_COMMAND,
+                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                              | PCI_COMMAND_INTX_DISABLE);
+            mapped_machine_irq[machine_irq]--;
+
+            if (mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    PT_ERR(pcidev, "Unmapping of machine interrupt %i failed!"
+                           " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
+           "\nIRQ type = %s\n", bus, slot, func, "INTx");
+
+    return 0;
+}
+
+static int pt_unregister_device(PCIDevice *pcidev)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
+    uint8_t e_device, e_intx;
+    uint8_t machine_irq;
+    int rc;
+
+    /* Unbind interrupt */
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+    machine_irq = s->machine_irq;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);
+        if (rc < 0) {
+            PT_ERR(pcidev, "Unbinding of interrupt failed! rc=%d\n", rc);
+        }
+    }
+
+    if (machine_irq) {
+        mapped_machine_irq[machine_irq]--;
+
+        if (mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                PT_ERR(pcidev, "Unmaping of interrupt failed! rc=%d\n", rc);
+            }
+        }
+    }
+
+    /* unregister real device's MMIO/PIO BARs */
+    pt_unregister_regions(s);
+
+    host_pci_device_put(s->real_device);
+
+    return 0;
+}
+
+static PCIDeviceInfo xen_pci_passthrough = {
+    .init = pt_initfn,
+    .exit = pt_unregister_device,
+    .qdev.name = "xen-pci-passthrough",
+    .qdev.desc = "Assign an host pci device with Xen",
+    .qdev.size = sizeof(XenPCIPassthroughState),
+    .config_read = pt_pci_read_config,
+    .config_write = pt_pci_write_config,
+    .is_express = 0,
+    .qdev.props = (Property[]) {
+        DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+        DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
+                        0, false),
+        DEFINE_PROP_END_OF_LIST(),
+    }
+};
+
+static void xen_passthrough_register(void)
+{
+    pci_qdev_register(&xen_pci_passthrough);
+}
+
+device_init(xen_passthrough_register);
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
new file mode 100644
index 0000000..110325c
--- /dev/null
+++ b/hw/xen_pci_passthrough.h
@@ -0,0 +1,282 @@
+#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
+#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "host-pci-device.h"
+
+/* #define PT_LOGGING_ENABLED */
+/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
+
+void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
+
+#ifdef PT_LOGGING_ENABLED
+#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
+#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
+#else
+#  define PT_LOG(d, _f, _a...)
+#  define PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+#  define PT_LOG_CONFIG(d, addr, val, len) \
+    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+           __func__, addr, val, len)
+#else
+#  define PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+typedef int (*conf_dword_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint32_t dev_value, uint32_t *val);
+typedef int (*conf_word_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint16_t dev_value, uint16_t *val);
+typedef int (*conf_byte_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint8_t dev_value, uint8_t *val);
+
+/* power state transition */
+#define PT_FLAG_TRANSITING  0x0001
+
+#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
+#define PT_PCI_BAR_UNMAPPED (-1)
+#define PT_UNASSIGNED_PIRQ (-1)
+
+
+typedef enum {
+    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
+    GRP_TYPE_EMU,                               /* emul reg group */
+} RegisterGroupType;
+
+typedef enum {
+    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
+    PT_BAR_FLAG_IO,                             /* I/O type BAR */
+    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
+    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
+} PTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* Virtual phys base & size */
+    uint32_t e_physbase;
+    uint32_t e_size;
+    /* Index of region in qemu */
+    uint32_t memory_index;
+    /* BAR flag */
+    PTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    conf_reg_init init;
+    /* read/write/restore function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            conf_dword_write write;
+            conf_dword_read read;
+            conf_dword_restore restore;
+        } dw;
+        struct {
+            conf_word_write write;
+            conf_word_read read;
+            conf_word_restore restore;
+        } w;
+        struct {
+            conf_byte_write write;
+            conf_byte_read read;
+            conf_byte_restore restore;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data;
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    RegisterGroupType grp_type;
+    uint8_t grp_size;
+    pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_reg_tbl;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+typedef struct XenPTPM {
+    QEMUTimer *pm_timer;  /* QEMUTimer struct */
+    int no_soft_reset;    /* No Soft Reset flags */
+    uint16_t flags;       /* power state transition flags */
+    uint16_t pmc_field;   /* Power Management Capabilities field */
+    int pm_delay;         /* power state transition delay */
+    uint16_t cur_state;   /* current power state */
+    uint16_t req_state;   /* requested power state */
+    uint32_t pm_base;     /* Power Management Capability reg base offset */
+    uint32_t aer_base;    /* AER Capability reg base offset */
+} XenPTPM;
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    HostPCIDevice *real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
+
+    uint32_t machine_irq;
+
+    uint32_t power_mgmt;
+    XenPTPM *pm_state;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+};
+
+int pt_config_init(XenPCIPassthroughState *s);
+void pt_config_delete(XenPCIPassthroughState *s);
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable);
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable);
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the intertupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = pci_read_intx(s);
+
+    PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+               " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
new file mode 100644
index 0000000..1e9de64
--- /dev/null
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pci_passthrough.h"
+
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index b5e28ab..0e3bbcf 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -979,3 +979,15 @@ void destroy_hvm_domain(void)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:48:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:48:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdPW-0004I7-EO; Thu, 24 Nov 2011 17:48:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdPU-0004Fn-Ml
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:48:33 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!4
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18401 invoked from network); 24 Nov 2011 17:45:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:45:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809604"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:06 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ8027444;	Thu, 24 Nov 2011 09:45:04 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:36 +0000
Message-ID: <1322156679-9441-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, Guy Zana <guy@neocleus.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Allen Kay <allen.m.kay@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 07/10] Introduce Xen PCI Passthrough,
	qdevice (1/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Allen Kay <allen.m.kay@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    2 +
 hw/xen_common.h                      |    3 +
 hw/xen_pci_passthrough.c             |  831 ++++++++++++++++++++++++++++++++++
 hw/xen_pci_passthrough.h             |  282 ++++++++++++
 hw/xen_pci_passthrough_config_init.c |   11 +
 xen-all.c                            |   12 +
 6 files changed, 1141 insertions(+), 0 deletions(-)
 create mode 100644 hw/xen_pci_passthrough.c
 create mode 100644 hw/xen_pci_passthrough.h
 create mode 100644 hw/xen_pci_passthrough_config_init.c

diff --git a/Makefile.target b/Makefile.target
index e527c1b..33435a3 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -221,6 +221,8 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 
 # Xen PCI Passthrough
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/xen_common.h b/hw/xen_common.h
index 0409ac7..48916fd 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -135,4 +135,7 @@ static inline int xc_fd(xc_interface *xen_xc)
 
 void destroy_hvm_domain(void);
 
+/* shutdown/destroy current domain because of an error */
+void xen_shutdown_fatal_error(const char *fmt, ...) GCC_FMT_ATTR(1, 2);
+
 #endif /* QEMU_HW_XEN_COMMON_H */
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
new file mode 100644
index 0000000..998470b
--- /dev/null
+++ b/hw/xen_pci_passthrough.c
@@ -0,0 +1,831 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Alex Novik <alex@neocleus.com>
+ * Allen Kay <allen.m.kay@intel.com>
+ * Guy Zana <guy@neocleus.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+/*
+ * Interrupt Disable policy:
+ *
+ * INTx interrupt:
+ *   Initialize(register_real_device)
+ *     Map INTx(xc_physdev_map_pirq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Set machine_irq and assigned_device->machine_irq to '0'.
+ *         * Don't bind INTx.
+ *
+ *     Bind INTx(xc_domain_bind_pt_pci_irq):
+ *       <fail>
+ *         - Set real Interrupt Disable bit to '1'.
+ *         - Unmap INTx.
+ *         - Decrement mapped_machine_irq[machine_irq]
+ *         - Set assigned_device->machine_irq to '0'.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       <ptdev->msi_trans_en is false>
+ *         - Set real bit to '0' if assigned_device->machine_irq isn't '0'.
+ *
+ *     Write '1'
+ *       <ptdev->msi_trans_en is false>
+ *         - Set real bit to '1'.
+ */
+
+#include <sys/ioctl.h>
+
+#include "pci.h"
+#include "xen.h"
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+
+#define PCI_BAR_ENTRIES (6)
+
+#define PT_NR_IRQS          (256)
+char mapped_machine_irq[PT_NR_IRQS] = {0};
+
+void pt_log(const PCIDevice *d, const char *f, ...)
+{
+    va_list ap;
+
+    va_start(ap, f);
+    if (d) {
+        fprintf(stderr, "[%02x:%02x.%x] ", pci_bus_num(d->bus),
+                PCI_SLOT(d->devfn), PCI_FUNC(d->devfn));
+    }
+    vfprintf(stderr, f, ap);
+    va_end(ap);
+}
+
+
+/* Config Space */
+static int pt_pci_config_access_check(PCIDevice *d, uint32_t address, int len)
+{
+    /* check offset range */
+    if (address >= 0xFF) {
+        PT_ERR(d, "Failed to access register with offset exceeding 0xFF. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check read size */
+    if ((len != 1) && (len != 2) && (len != 4)) {
+        PT_ERR(d, "Failed to access register with invalid access length. "
+               "(addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    /* check offset alignment */
+    if (address & (len - 1)) {
+        PT_ERR(d, "Failed to access register with invalid access size "
+               "alignment. (addr: 0x%02x, len: %d)\n", address, len);
+        return -1;
+    }
+
+    return 0;
+}
+
+int pt_bar_offset_to_index(uint32_t offset)
+{
+    int index = 0;
+
+    /* check Exp ROM BAR */
+    if (offset == PCI_ROM_ADDRESS) {
+        return PCI_ROM_SLOT;
+    }
+
+    /* calculate BAR index */
+    index = (offset - PCI_BASE_ADDRESS_0) >> 2;
+    if (index >= PCI_NUM_REGIONS) {
+        return -1;
+    }
+
+    return index;
+}
+
+static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    uint32_t val = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    int rc = 0;
+    int emul_len = 0;
+    uint32_t find_addr = address;
+
+    if (pt_pci_config_access_check(d, address, len)) {
+        goto exit;
+    }
+
+    /* check power state transition flags */
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        /* can't accept until previous power state transition is completed.
+         * so finish previous request here.
+         */
+        PT_WARN(d, "Guest want to write during power state transition\n");
+        goto exit;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, address);
+    if (reg_grp_entry) {
+        /* check 0 Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* no need to emulate, just return 0 */
+            val = 0;
+            goto exit;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, address, (uint8_t *)&val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&val, 0xff, len);
+    }
+
+    /* just return the I/O device register value for
+     * passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto exit;
+    }
+
+    /* adjust the read value to appropriate CFC-CFF window */
+    val <<= (address & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            XenPTRegInfo *reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.read) {
+                    rc = reg->u.b.read(s, reg_entry, ptr_val, valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.read) {
+                    rc = reg->u.w.read(s, reg_entry,
+                                       (uint16_t *)ptr_val, valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.read) {
+                    rc = reg->u.dw.read(s, reg_entry,
+                                        (uint32_t *)ptr_val, valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid read "
+                                         "emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return 0;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before returning them to pci bus emulator */
+    val >>= ((address & 3) << 3);
+
+exit:
+    PT_LOG_CONFIG(d, address, val, len);
+    return val;
+}
+
+static void pt_pci_write_config(PCIDevice *d, uint32_t address,
+                                uint32_t val, int len)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, d);
+    int index = 0;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    int rc = 0;
+    uint32_t read_val = 0;
+    int emul_len = 0;
+    XenPTReg *reg_entry = NULL;
+    uint32_t find_addr = address;
+    XenPTRegInfo *reg = NULL;
+
+    if (pt_pci_config_access_check(d, address, len)) {
+        return;
+    }
+
+    PT_LOG_CONFIG(d, address, val, len);
+
+    /* check unused BAR register */
+    index = pt_bar_offset_to_index(address);
+    if ((index >= 0) && (val > 0 && val < PT_BAR_ALLF) &&
+        (s->bases[index].bar_flag == PT_BAR_FLAG_UNUSED)) {
+        PT_WARN(d, "Guest attempt to set address to unused Base Address "
+                "Register. (addr: 0x%02x, len: %d)\n", address, len);
+    }
+
+    /* check power state transition flags */
+    if (s->pm_state != NULL && s->pm_state->flags & PT_FLAG_TRANSITING) {
+        /* can't accept until previous power state transition is completed.
+         * so finish previous request here.
+         */
+        PT_WARN(d, "Guest want to write during power state transition\n");
+        return;
+    }
+
+    /* find register group entry */
+    reg_grp_entry = pt_find_reg_grp(s, address);
+    if (reg_grp_entry) {
+        /* check 0 Hardwired register group */
+        if (reg_grp_entry->reg_grp->grp_type == GRP_TYPE_HARDWIRED) {
+            /* ignore silently */
+            PT_WARN(d, "Access to 0 Hardwired register. "
+                    "(addr: 0x%02x, len: %d)\n", address, len);
+            return;
+        }
+    }
+
+    /* read I/O device register value */
+    rc = host_pci_get_block(s->real_device, address,
+                             (uint8_t *)&read_val, len);
+    if (rc < 0) {
+        PT_ERR(d, "pci_read_block failed. return value: %d.\n", rc);
+        memset(&read_val, 0xff, len);
+    }
+
+    /* pass directly to the real device for passthrough type register group */
+    if (reg_grp_entry == NULL) {
+        goto out;
+    }
+
+    /* adjust the read and write value to appropriate CFC-CFF window */
+    read_val <<= (address & 3) << 3;
+    val <<= (address & 3) << 3;
+    emul_len = len;
+
+    /* loop around the guest requested size */
+    while (emul_len > 0) {
+        /* find register entry to be emulated */
+        reg_entry = pt_find_reg(reg_grp_entry, find_addr);
+        if (reg_entry) {
+            reg = reg_entry->reg;
+            uint32_t real_offset = reg_grp_entry->base_offset + reg->offset;
+            uint32_t valid_mask = 0xFFFFFFFF >> ((4 - emul_len) << 3);
+            uint8_t *ptr_val = NULL;
+
+            valid_mask <<= (find_addr - real_offset) << 3;
+            ptr_val = (uint8_t *)&val + (real_offset & 3);
+
+            /* do emulation based on register size */
+            switch (reg->size) {
+            case 1:
+                if (reg->u.b.write) {
+                    rc = reg->u.b.write(s, reg_entry, ptr_val,
+                                        read_val >> ((real_offset & 3) << 3),
+                                        valid_mask);
+                }
+                break;
+            case 2:
+                if (reg->u.w.write) {
+                    rc = reg->u.w.write(s, reg_entry, (uint16_t *)ptr_val,
+                                        (read_val >> ((real_offset & 3) << 3)),
+                                        valid_mask);
+                }
+                break;
+            case 4:
+                if (reg->u.dw.write) {
+                    rc = reg->u.dw.write(s, reg_entry, (uint32_t *)ptr_val,
+                                         (read_val >> ((real_offset & 3) << 3)),
+                                         valid_mask);
+                }
+                break;
+            }
+
+            if (rc < 0) {
+                xen_shutdown_fatal_error("Internal error: Invalid write"
+                                         " emulation. (%s, rc: %d)\n",
+                                         __func__, rc);
+                return;
+            }
+
+            /* calculate next address to find */
+            emul_len -= reg->size;
+            if (emul_len > 0) {
+                find_addr = real_offset + reg->size;
+            }
+        } else {
+            /* nothing to do with passthrough type register,
+             * continue to find next byte */
+            emul_len--;
+            find_addr++;
+        }
+    }
+
+    /* need to shift back before passing them to host_pci_device */
+    val >>= (address & 3) << 3;
+
+out:
+    if (!(reg && reg->no_wb)) {
+        /* unknown regs are passed through */
+        rc = host_pci_set_block(s->real_device, address, (uint8_t *)&val, len);
+
+        if (rc < 0) {
+            PT_ERR(d, "pci_write_block failed. return value: %d.\n", rc);
+        }
+    }
+}
+
+/* ioport/iomem space*/
+static void pt_iomem_map(XenPCIPassthroughState *s, int i,
+                         pcibus_t e_phys, pcibus_t e_size, int type)
+{
+    PCIIORegion *r = &s->dev.io_regions[i];
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int ret = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "e_phys=%#"PRIx64" maddr=%#"PRIx64" type=%d"
+           " len=%#"PRIx64" index=%d first_map=%d\n",
+           e_phys, s->bases[i].access.maddr, type,
+           e_size, i, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        memory_region_del_subregion(r->address_space,
+                                    r->memory);
+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                               old_ebase >> XC_PAGE_SHIFT,
+                               s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                               (e_size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+                               DPCI_REMOVE_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "remove old mapping failed!\n");
+            return;
+        }
+    }
+
+    /* map only valid guest address */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        memory_region_add_subregion_overlap(r->address_space,
+                                            e_phys, r->memory, 1);
+        ret = xc_domain_memory_mapping(xen_xc, xen_domid,
+                                   s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                                   s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                                   (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                                   DPCI_ADD_MAPPING);
+
+        if (ret != 0) {
+            PT_ERR(&s->dev, "create new mapping failed!\n");
+        }
+    }
+}
+
+static void pt_ioport_map(XenPCIPassthroughState *s, int i,
+                          pcibus_t e_phys, pcibus_t e_size, int type)
+{
+    PCIIORegion *r = &s->dev.io_regions[i];
+    uint32_t old_ebase = s->bases[i].e_physbase;
+    bool first_map = s->bases[i].e_size == 0;
+    int ret = 0;
+
+    s->bases[i].e_physbase = e_phys;
+    s->bases[i].e_size = e_size;
+
+    PT_LOG(&s->dev, "e_phys=%#04"PRIx64" pio_base=%#04"PRIx64" len=%"PRId64
+           " index=%d first_map=%d\n",
+           e_phys, s->bases[i].access.pio_base, e_size, i, first_map);
+
+    if (e_size == 0) {
+        return;
+    }
+
+    if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        /* Remove old mapping */
+        memory_region_del_subregion(r->address_space,
+                                    r->memory);
+        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, old_ebase,
+                                       s->bases[i].access.pio_base, e_size,
+                                       DPCI_REMOVE_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "remove old mapping failed!\n");
+            return;
+        }
+    }
+
+    /* map only valid guest address (include 0) */
+    if (e_phys != PCI_BAR_UNMAPPED) {
+        /* Create new mapping */
+        memory_region_add_subregion_overlap(r->address_space,
+                                            e_phys, r->memory, 1);
+        ret = xc_domain_ioport_mapping(xen_xc, xen_domid, e_phys,
+                                       s->bases[i].access.pio_base, e_size,
+                                       DPCI_ADD_MAPPING);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "create new mapping failed!\n");
+        }
+    }
+
+}
+
+
+/* mapping BAR */
+
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable)
+{
+    PCIDevice *dev = &s->dev;
+    PCIIORegion *r;
+    XenPTRegGroup *reg_grp_entry = NULL;
+    XenPTReg *reg_entry = NULL;
+    XenPTRegion *base = NULL;
+    pcibus_t r_size = 0, r_addr = PCI_BAR_UNMAPPED;
+    int rc = 0;
+
+    r = &dev->io_regions[bar];
+
+    /* check valid region */
+    if (!r->size) {
+        return;
+    }
+
+    base = &s->bases[bar];
+    /* skip unused BAR or upper 64bit BAR */
+    if ((base->bar_flag == PT_BAR_FLAG_UNUSED)
+        || (base->bar_flag == PT_BAR_FLAG_UPPER)) {
+           return;
+    }
+
+    /* copy region address to temporary */
+    r_addr = r->addr;
+
+    /* need unmapping in case I/O Space or Memory Space disable */
+    if (((base->bar_flag == PT_BAR_FLAG_IO) && !io_enable) ||
+        ((base->bar_flag == PT_BAR_FLAG_MEM) && !mem_enable)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+    if ((bar == PCI_ROM_SLOT) && (r_addr != PCI_BAR_UNMAPPED)) {
+        reg_grp_entry = pt_find_reg_grp(s, PCI_ROM_ADDRESS);
+        if (reg_grp_entry) {
+            reg_entry = pt_find_reg(reg_grp_entry, PCI_ROM_ADDRESS);
+            if (reg_entry && !(reg_entry->data & PCI_ROM_ADDRESS_ENABLE)) {
+                r_addr = PCI_BAR_UNMAPPED;
+            }
+        }
+    }
+
+    /* prevent guest software mapping memory resource to 00000000h */
+    if ((base->bar_flag == PT_BAR_FLAG_MEM) && (r_addr == 0)) {
+        r_addr = PCI_BAR_UNMAPPED;
+    }
+
+    r_size = pt_get_emul_size(base->bar_flag, r->size);
+
+    rc = pci_check_bar_overlap(dev, r_addr, r_size, r->type);
+    if (rc) {
+        PT_WARN(dev, "Region: %d (addr: %#"FMT_PCIBUS
+                ", len: %#"FMT_PCIBUS") is overlapped.\n",
+                bar, r_addr, r_size);
+    }
+
+    /* check whether we need to update the mapping or not */
+    if (r_addr != s->bases[bar].e_physbase) {
+        /* mapping BAR */
+        if (base->bar_flag == PT_BAR_FLAG_IO) {
+            pt_ioport_map(s, bar, r_addr, r_size, r->type);
+        } else {
+            pt_iomem_map(s, bar, r_addr, r_size, r->type);
+        }
+    }
+}
+
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable)
+{
+    int i;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        pt_bar_mapping_one(s, i, io_enable, mem_enable);
+    }
+}
+
+static uint64_t bar_read(void *o, target_phys_addr_t addr, unsigned size)
+{
+    PCIDevice *d = o;
+    PT_ERR(d, "Should not read BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+    return 0;
+}
+static void bar_write(void *o, target_phys_addr_t addr,
+                      uint64_t data, unsigned size)
+{
+    PCIDevice* d = o;
+    PT_ERR(d, "Should not write BAR through QEMU. @0x"TARGET_FMT_plx"\n", addr);
+}
+
+static const MemoryRegionOps ops = {
+    .endianness = DEVICE_NATIVE_ENDIAN,
+    .read = bar_read,
+    .write = bar_write,
+};
+
+/* register regions */
+static int pt_register_regions(XenPCIPassthroughState *s)
+{
+    int i = 0;
+    uint32_t bar_data = 0;
+    HostPCIDevice *d = s->real_device;
+
+    /* Register PIO/MMIO BARs */
+    for (i = 0; i < PCI_BAR_ENTRIES; i++) {
+        HostPCIIORegion *r = &d->io_regions[i];
+
+        if (r->base_addr && r->size) {
+            s->bases[i].e_physbase = r->base_addr;
+            s->bases[i].access.u = r->base_addr;
+
+            /* Register current region */
+            if (r->flags & IORESOURCE_IO) {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-io", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_IO,
+                                 &s->bar[i]);
+            } else if (r->flags & IORESOURCE_PREFETCH) {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-mem", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                                 &s->bar[i]);
+            } else {
+                memory_region_init_io(&s->bar[i], &ops, &s->dev,
+                                      "xen-pci-pt-bar-mem", r->size);
+                pci_register_bar(&s->dev, i, PCI_BASE_ADDRESS_SPACE_MEMORY,
+                                 &s->bar[i]);
+            }
+
+            PT_LOG(&s->dev, "IO region registered (size=0x%08"PRIx64
+                   " base_addr=0x%08"PRIx64")\n",
+                   r->size, r->base_addr);
+        }
+    }
+
+    /* Register expansion ROM address */
+    if (d->rom.base_addr && d->rom.size) {
+        /* Re-set BAR reported by OS, otherwise ROM can't be read. */
+        if (host_pci_get_long(d, PCI_ROM_ADDRESS, &bar_data)) {
+            return 0;
+        }
+        if ((bar_data & PCI_ROM_ADDRESS_MASK) == 0) {
+            bar_data |= d->rom.base_addr & PCI_ROM_ADDRESS_MASK;
+            host_pci_set_long(d, PCI_ROM_ADDRESS, bar_data);
+        }
+
+        s->bases[PCI_ROM_SLOT].e_physbase = d->rom.base_addr;
+        s->bases[PCI_ROM_SLOT].access.maddr = d->rom.base_addr;
+
+        memory_region_init_rom_device(&s->rom, NULL, NULL, &s->dev.qdev,
+                                      "xen-pci-pt-rom", d->rom.size);
+        pci_register_bar(&s->dev, PCI_ROM_SLOT, PCI_BASE_ADDRESS_MEM_PREFETCH,
+                         &s->rom);
+
+        PT_LOG(&s->dev, "Expansion ROM registered (size=0x%08"PRIx64
+               " base_addr=0x%08"PRIx64")\n",
+               d->rom.size, d->rom.base_addr);
+    }
+
+    return 0;
+}
+
+static void pt_unregister_regions(XenPCIPassthroughState *s)
+{
+    int i, type, rc;
+    uint32_t e_size;
+    PCIDevice *d = &s->dev;
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        e_size = s->bases[i].e_size;
+        if ((e_size == 0) || (s->bases[i].e_physbase == PT_PCI_BAR_UNMAPPED)) {
+            continue;
+        }
+
+        type = d->io_regions[i].type;
+
+        if (type == PCI_BASE_ADDRESS_SPACE_MEMORY
+            || type == PCI_BASE_ADDRESS_MEM_PREFETCH) {
+            rc = xc_domain_memory_mapping(xen_xc, xen_domid,
+                    s->bases[i].e_physbase >> XC_PAGE_SHIFT,
+                    s->bases[i].access.maddr >> XC_PAGE_SHIFT,
+                    (e_size+XC_PAGE_SIZE-1) >> XC_PAGE_SHIFT,
+                    DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old mem mapping failed!\n");
+                continue;
+            }
+
+        } else if (type == PCI_BASE_ADDRESS_SPACE_IO) {
+            rc = xc_domain_ioport_mapping(xen_xc, xen_domid,
+                        s->bases[i].e_physbase,
+                        s->bases[i].access.pio_base,
+                        e_size,
+                        DPCI_REMOVE_MAPPING);
+            if (rc != 0) {
+                PT_ERR(d, "remove old io mapping failed!\n");
+                continue;
+            }
+        }
+    }
+}
+
+static int pt_initfn(PCIDevice *pcidev)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
+    int dom, bus;
+    unsigned slot, func;
+    int rc = 0;
+    uint8_t machine_irq = 0;
+    int pirq = PT_UNASSIGNED_PIRQ;
+
+    if (pci_parse_devaddr(s->hostaddr, &dom, &bus, &slot, &func) < 0) {
+        PT_ERR(pcidev, "Failed to parse BDF: %s\n", s->hostaddr);
+        return -1;
+    }
+
+    /* register real device */
+    PT_LOG(pcidev, "Assigning real physical device %02x:%02x.%x"
+           " to devfn %#x\n", bus, slot, func, s->dev.devfn);
+
+    s->real_device = host_pci_device_get(bus, slot, func);
+    if (!s->real_device) {
+        return -1;
+    }
+
+    s->is_virtfn = s->real_device->is_virtfn;
+    if (s->is_virtfn) {
+        PT_LOG(pcidev, "%04x:%02x:%02x.%x is a SR-IOV Virtual Function\n",
+               s->real_device->domain, bus, slot, func);
+    }
+
+    /* Initialize virtualized PCI configuration (Extended 256 Bytes) */
+    if (host_pci_get_block(s->real_device, 0, pcidev->config,
+                           PCI_CONFIG_SPACE_SIZE) == -1) {
+        host_pci_device_put(s->real_device);
+        return -1;
+    }
+
+    /* Handle real device's MMIO/PIO BARs */
+    pt_register_regions(s);
+
+    /* Bind interrupt */
+    if (!s->dev.config[PCI_INTERRUPT_PIN]) {
+        PT_LOG(pcidev, "no pin interrupt\n");
+        goto out;
+    }
+
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_LINE, &machine_irq);
+    rc = xc_physdev_map_pirq(xen_xc, xen_domid, machine_irq, &pirq);
+
+    if (rc < 0) {
+        PT_ERR(pcidev, "Mapping machine irq %u to pirq %i failed, (rc: %d)\n",
+               machine_irq, pirq, rc);
+
+        /* Disable PCI intx assertion (turn on bit10 of devctl) */
+        host_pci_set_word(s->real_device,
+                          PCI_COMMAND,
+                          pci_get_word(s->dev.config + PCI_COMMAND)
+                          | PCI_COMMAND_INTX_DISABLE);
+        machine_irq = 0;
+        s->machine_irq = 0;
+    } else {
+        machine_irq = pirq;
+        s->machine_irq = pirq;
+        mapped_machine_irq[machine_irq]++;
+    }
+
+    /* bind machine_irq to device */
+    if (rc < 0 && machine_irq != 0) {
+        uint8_t e_device = PCI_SLOT(s->dev.devfn);
+        uint8_t e_intx = pci_intx(s);
+
+        rc = xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, machine_irq, 0,
+                                       e_device, e_intx);
+        if (rc < 0) {
+            PT_ERR(pcidev, "Binding of interrupt %i failed! (rc: %d)\n",
+                   e_intx, rc);
+
+            /* Disable PCI intx assertion (turn on bit10 of devctl) */
+            host_pci_set_word(s->real_device, PCI_COMMAND,
+                              *(uint16_t *)(&s->dev.config[PCI_COMMAND])
+                              | PCI_COMMAND_INTX_DISABLE);
+            mapped_machine_irq[machine_irq]--;
+
+            if (mapped_machine_irq[machine_irq] == 0) {
+                if (xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq)) {
+                    PT_ERR(pcidev, "Unmapping of machine interrupt %i failed!"
+                           " (rc: %d)\n", machine_irq, rc);
+                }
+            }
+            s->machine_irq = 0;
+        }
+    }
+
+out:
+    PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
+           "\nIRQ type = %s\n", bus, slot, func, "INTx");
+
+    return 0;
+}
+
+static int pt_unregister_device(PCIDevice *pcidev)
+{
+    XenPCIPassthroughState *s = DO_UPCAST(XenPCIPassthroughState, dev, pcidev);
+    uint8_t e_device, e_intx;
+    uint8_t machine_irq;
+    int rc;
+
+    /* Unbind interrupt */
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+    machine_irq = s->machine_irq;
+
+    if (machine_irq) {
+        rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
+                                     PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);
+        if (rc < 0) {
+            PT_ERR(pcidev, "Unbinding of interrupt failed! rc=%d\n", rc);
+        }
+    }
+
+    if (machine_irq) {
+        mapped_machine_irq[machine_irq]--;
+
+        if (mapped_machine_irq[machine_irq] == 0) {
+            rc = xc_physdev_unmap_pirq(xen_xc, xen_domid, machine_irq);
+
+            if (rc < 0) {
+                PT_ERR(pcidev, "Unmaping of interrupt failed! rc=%d\n", rc);
+            }
+        }
+    }
+
+    /* unregister real device's MMIO/PIO BARs */
+    pt_unregister_regions(s);
+
+    host_pci_device_put(s->real_device);
+
+    return 0;
+}
+
+static PCIDeviceInfo xen_pci_passthrough = {
+    .init = pt_initfn,
+    .exit = pt_unregister_device,
+    .qdev.name = "xen-pci-passthrough",
+    .qdev.desc = "Assign an host pci device with Xen",
+    .qdev.size = sizeof(XenPCIPassthroughState),
+    .config_read = pt_pci_read_config,
+    .config_write = pt_pci_write_config,
+    .is_express = 0,
+    .qdev.props = (Property[]) {
+        DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+        DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
+                        0, false),
+        DEFINE_PROP_END_OF_LIST(),
+    }
+};
+
+static void xen_passthrough_register(void)
+{
+    pci_qdev_register(&xen_pci_passthrough);
+}
+
+device_init(xen_passthrough_register);
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
new file mode 100644
index 0000000..110325c
--- /dev/null
+++ b/hw/xen_pci_passthrough.h
@@ -0,0 +1,282 @@
+#ifndef QEMU_HW_XEN_PCI_PASSTHROUGH_H
+#  define QEMU_HW_XEN_PCI_PASSTHROUGH_H
+
+#include "qemu-common.h"
+#include "xen_common.h"
+#include "pci.h"
+#include "host-pci-device.h"
+
+/* #define PT_LOGGING_ENABLED */
+/* #define PT_DEBUG_PCI_CONFIG_ACCESS */
+
+void pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
+
+#define PT_ERR(d, _f, _a...)  pt_log(d, "%s: Error: " _f, __func__, ##_a)
+
+#ifdef PT_LOGGING_ENABLED
+#  define PT_LOG(d, _f, _a...)  pt_log(d, "%s: " _f, __func__, ##_a)
+#  define PT_WARN(d, _f, _a...) pt_log(d, "%s: Warning: " _f, __func__, ##_a)
+#else
+#  define PT_LOG(d, _f, _a...)
+#  define PT_WARN(d, _f, _a...)
+#endif
+
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+#  define PT_LOG_CONFIG(d, addr, val, len) \
+    pt_log(d, "%s: address=0x%04x val=0x%08x len=%d\n", \
+           __func__, addr, val, len)
+#else
+#  define PT_LOG_CONFIG(d, addr, val, len)
+#endif
+
+
+typedef struct XenPTRegInfo XenPTRegInfo;
+typedef struct XenPTReg XenPTReg;
+
+typedef struct XenPCIPassthroughState XenPCIPassthroughState;
+
+/* function type for config reg */
+typedef int (*conf_reg_init)
+    (XenPCIPassthroughState *, XenPTRegInfo *, uint32_t real_offset,
+     uint32_t *data);
+typedef int (*conf_dword_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t dev_value, uint32_t valid_mask);
+typedef int (*conf_word_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t dev_value, uint16_t valid_mask);
+typedef int (*conf_byte_write)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t dev_value, uint8_t valid_mask);
+typedef int (*conf_dword_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint32_t *val, uint32_t valid_mask);
+typedef int (*conf_word_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint16_t *val, uint16_t valid_mask);
+typedef int (*conf_byte_read)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry,
+     uint8_t *val, uint8_t valid_mask);
+typedef int (*conf_dword_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint32_t dev_value, uint32_t *val);
+typedef int (*conf_word_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint16_t dev_value, uint16_t *val);
+typedef int (*conf_byte_restore)
+    (XenPCIPassthroughState *, XenPTReg *cfg_entry, uint32_t real_offset,
+     uint8_t dev_value, uint8_t *val);
+
+/* power state transition */
+#define PT_FLAG_TRANSITING  0x0001
+
+#define PT_BAR_ALLF         0xFFFFFFFF  /* BAR ALLF value */
+#define PT_PCI_BAR_UNMAPPED (-1)
+#define PT_UNASSIGNED_PIRQ (-1)
+
+
+typedef enum {
+    GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
+    GRP_TYPE_EMU,                               /* emul reg group */
+} RegisterGroupType;
+
+typedef enum {
+    PT_BAR_FLAG_MEM = 0,                        /* Memory type BAR */
+    PT_BAR_FLAG_IO,                             /* I/O type BAR */
+    PT_BAR_FLAG_UPPER,                          /* upper 64bit BAR */
+    PT_BAR_FLAG_UNUSED,                         /* unused BAR */
+} PTBarFlag;
+
+
+typedef struct XenPTRegion {
+    /* Virtual phys base & size */
+    uint32_t e_physbase;
+    uint32_t e_size;
+    /* Index of region in qemu */
+    uint32_t memory_index;
+    /* BAR flag */
+    PTBarFlag bar_flag;
+    /* Translation of the emulated address */
+    union {
+        uint64_t maddr;
+        uint64_t pio_base;
+        uint64_t u;
+    } access;
+} XenPTRegion;
+
+/* XenPTRegInfo declaration
+ * - only for emulated register (either a part or whole bit).
+ * - for passthrough register that need special behavior (like interacting with
+ *   other component), set emu_mask to all 0 and specify r/w func properly.
+ * - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
+ */
+
+/* emulated register infomation */
+struct XenPTRegInfo {
+    uint32_t offset;
+    uint32_t size;
+    uint32_t init_val;
+    /* reg read only field mask (ON:RO/ROS, OFF:other) */
+    uint32_t ro_mask;
+    /* reg emulate field mask (ON:emu, OFF:passthrough) */
+    uint32_t emu_mask;
+    /* no write back allowed */
+    uint32_t no_wb;
+    conf_reg_init init;
+    /* read/write/restore function pointer
+     * for double_word/word/byte size */
+    union {
+        struct {
+            conf_dword_write write;
+            conf_dword_read read;
+            conf_dword_restore restore;
+        } dw;
+        struct {
+            conf_word_write write;
+            conf_word_read read;
+            conf_word_restore restore;
+        } w;
+        struct {
+            conf_byte_write write;
+            conf_byte_read read;
+            conf_byte_restore restore;
+        } b;
+    } u;
+};
+
+/* emulated register management */
+struct XenPTReg {
+    QLIST_ENTRY(XenPTReg) entries;
+    XenPTRegInfo *reg;
+    uint32_t data;
+};
+
+typedef struct XenPTRegGroupInfo XenPTRegGroupInfo;
+
+/* emul reg group size initialize method */
+typedef int (*pt_reg_size_init_fn)
+    (XenPCIPassthroughState *, const XenPTRegGroupInfo *,
+     uint32_t base_offset, uint8_t *size);
+
+/* emulated register group infomation */
+struct XenPTRegGroupInfo {
+    uint8_t grp_id;
+    RegisterGroupType grp_type;
+    uint8_t grp_size;
+    pt_reg_size_init_fn size_init;
+    XenPTRegInfo *emu_reg_tbl;
+};
+
+/* emul register group management table */
+typedef struct XenPTRegGroup {
+    QLIST_ENTRY(XenPTRegGroup) entries;
+    const XenPTRegGroupInfo *reg_grp;
+    uint32_t base_offset;
+    uint8_t size;
+    QLIST_HEAD(, XenPTReg) reg_tbl_list;
+} XenPTRegGroup;
+
+
+typedef struct XenPTPM {
+    QEMUTimer *pm_timer;  /* QEMUTimer struct */
+    int no_soft_reset;    /* No Soft Reset flags */
+    uint16_t flags;       /* power state transition flags */
+    uint16_t pmc_field;   /* Power Management Capabilities field */
+    int pm_delay;         /* power state transition delay */
+    uint16_t cur_state;   /* current power state */
+    uint16_t req_state;   /* requested power state */
+    uint32_t pm_base;     /* Power Management Capability reg base offset */
+    uint32_t aer_base;    /* AER Capability reg base offset */
+} XenPTPM;
+
+struct XenPCIPassthroughState {
+    PCIDevice dev;
+
+    char *hostaddr;
+    bool is_virtfn;
+    HostPCIDevice *real_device;
+    XenPTRegion bases[PCI_NUM_REGIONS]; /* Access regions */
+    QLIST_HEAD(, XenPTRegGroup) reg_grp_tbl;
+
+    uint32_t machine_irq;
+
+    uint32_t power_mgmt;
+    XenPTPM *pm_state;
+
+    MemoryRegion bar[PCI_NUM_REGIONS - 1];
+    MemoryRegion rom;
+};
+
+int pt_config_init(XenPCIPassthroughState *s);
+void pt_config_delete(XenPCIPassthroughState *s);
+void pt_bar_mapping(XenPCIPassthroughState *s, int io_enable, int mem_enable);
+void pt_bar_mapping_one(XenPCIPassthroughState *s, int bar,
+                        int io_enable, int mem_enable);
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address);
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address);
+int pt_bar_offset_to_index(uint32_t offset);
+
+static inline pcibus_t pt_get_emul_size(PTBarFlag flag, pcibus_t r_size)
+{
+    /* align resource size (memory type only) */
+    if (flag == PT_BAR_FLAG_MEM) {
+        return (r_size + XC_PAGE_SIZE - 1) & XC_PAGE_MASK;
+    } else {
+        return r_size;
+    }
+}
+
+/* INTx */
+/* The PCI Local Bus Specification, Rev. 3.0,
+ * Section 6.2.4 Miscellaneous Registers, pp 223
+ * outlines 5 valid values for the intertupt pin (intx).
+ *  0: For devices (or device functions) that don't use an interrupt in
+ *  1: INTA#
+ *  2: INTB#
+ *  3: INTC#
+ *  4: INTD#
+ *
+ * Xen uses the following 4 values for intx
+ *  0: INTA#
+ *  1: INTB#
+ *  2: INTC#
+ *  3: INTD#
+ *
+ * Observing that these list of values are not the same, pci_read_intx()
+ * uses the following mapping from hw to xen values.
+ * This seems to reflect the current usage within Xen.
+ *
+ * PCI hardware    | Xen | Notes
+ * ----------------+-----+----------------------------------------------------
+ * 0               | 0   | No interrupt
+ * 1               | 0   | INTA#
+ * 2               | 1   | INTB#
+ * 3               | 2   | INTC#
+ * 4               | 3   | INTD#
+ * any other value | 0   | This should never happen, log error message
+ */
+
+static inline uint8_t pci_read_intx(XenPCIPassthroughState *s)
+{
+    uint8_t v = 0;
+    host_pci_get_byte(s->real_device, PCI_INTERRUPT_PIN, &v);
+    return v;
+}
+
+static inline uint8_t pci_intx(XenPCIPassthroughState *s)
+{
+    uint8_t r_val = pci_read_intx(s);
+
+    PT_LOG(&s->dev, "intx=%i\n", r_val);
+    if (r_val < 1 || r_val > 4) {
+        PT_LOG(&s->dev, "Interrupt pin read from hardware is out of range:"
+               " value=%i, acceptable range is 1 - 4\n", r_val);
+        r_val = 0;
+    } else {
+        r_val -= 1;
+    }
+
+    return r_val;
+}
+
+#endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
new file mode 100644
index 0000000..1e9de64
--- /dev/null
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -0,0 +1,11 @@
+#include "xen_pci_passthrough.h"
+
+XenPTRegGroup *pt_find_reg_grp(XenPCIPassthroughState *s, uint32_t address)
+{
+    return NULL;
+}
+
+XenPTReg *pt_find_reg(XenPTRegGroup *reg_grp, uint32_t address)
+{
+    return NULL;
+}
diff --git a/xen-all.c b/xen-all.c
index b5e28ab..0e3bbcf 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -979,3 +979,15 @@ void destroy_hvm_domain(void)
         xc_interface_close(xc_handle);
     }
 }
+
+void xen_shutdown_fatal_error(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+    fprintf(stderr, "Will destroy the domain.\n");
+    /* destroy the domain */
+    qemu_system_shutdown_request();
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:48:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdPa-0004K8-4R; Thu, 24 Nov 2011 17:48:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdPY-0004Gv-Au
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:48:36 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!5
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18409 invoked from network); 24 Nov 2011 17:45:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:45:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809608"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:09 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJA027444;	Thu, 24 Nov 2011 09:45:07 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:38 +0000
Message-ID: <1322156679-9441-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 09/10] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
---
 hw/apic-msidef.h |   28 ++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 29 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..3182f0b
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,28 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 8289eef..18c4a87 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -24,6 +24,7 @@
 #include "sysbus.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 /* APIC Local Vector Table */
 #define APIC_LVT_TIMER   0
@@ -65,16 +66,6 @@
 #define MAX_APICS 255
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 #define MSI_ADDR_SIZE                   0x100000
 
 typedef struct APICState APICState;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:48:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdPa-0004K8-4R; Thu, 24 Nov 2011 17:48:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdPY-0004Gv-Au
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:48:36 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!5
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18409 invoked from network); 24 Nov 2011 17:45:10 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:45:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809608"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:09 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJA027444;	Thu, 24 Nov 2011 09:45:07 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:38 +0000
Message-ID: <1322156679-9441-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 09/10] Introduce apic-msidef.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch move the msi definition from apic.c to apic-msidef.h. So it can be
used also by other .c files.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
---
 hw/apic-msidef.h |   28 ++++++++++++++++++++++++++++
 hw/apic.c        |   11 +----------
 2 files changed, 29 insertions(+), 10 deletions(-)
 create mode 100644 hw/apic-msidef.h

diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
new file mode 100644
index 0000000..3182f0b
--- /dev/null
+++ b/hw/apic-msidef.h
@@ -0,0 +1,28 @@
+#ifndef HW_APIC_MSIDEF_H
+#define HW_APIC_MSIDEF_H
+
+/*
+ * Intel APIC constants: from include/asm/msidef.h
+ */
+
+/*
+ * Shifts for MSI data
+ */
+
+#define MSI_DATA_VECTOR_SHIFT           0
+#define  MSI_DATA_VECTOR_MASK           0x000000ff
+
+#define MSI_DATA_DELIVERY_MODE_SHIFT    8
+#define MSI_DATA_LEVEL_SHIFT            14
+#define MSI_DATA_TRIGGER_SHIFT          15
+
+/*
+ * Shift/mask fields for msi address
+ */
+
+#define MSI_ADDR_DEST_MODE_SHIFT        2
+
+#define MSI_ADDR_DEST_ID_SHIFT          12
+#define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
+
+#endif /* HW_APIC_MSIDEF_H */
diff --git a/hw/apic.c b/hw/apic.c
index 8289eef..18c4a87 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -24,6 +24,7 @@
 #include "sysbus.h"
 #include "trace.h"
 #include "pc.h"
+#include "apic-msidef.h"
 
 /* APIC Local Vector Table */
 #define APIC_LVT_TIMER   0
@@ -65,16 +66,6 @@
 #define MAX_APICS 255
 #define MAX_APIC_WORDS 8
 
-/* Intel APIC constants: from include/asm/msidef.h */
-#define MSI_DATA_VECTOR_SHIFT		0
-#define MSI_DATA_VECTOR_MASK		0x000000ff
-#define MSI_DATA_DELIVERY_MODE_SHIFT	8
-#define MSI_DATA_TRIGGER_SHIFT		15
-#define MSI_DATA_LEVEL_SHIFT		14
-#define MSI_ADDR_DEST_MODE_SHIFT	2
-#define MSI_ADDR_DEST_ID_SHIFT		12
-#define	MSI_ADDR_DEST_ID_MASK		0x00ffff0
-
 #define MSI_ADDR_SIZE                   0x100000
 
 typedef struct APICState APICState;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:49:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdQ7-0004X9-N1; Thu, 24 Nov 2011 17:49:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdQ6-0004Ur-Qi
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:49:11 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18181 invoked from network); 24 Nov 2011 17:44:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809595"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:44:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:44:56 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ2027444;	Thu, 24 Nov 2011 09:44:55 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:30 +0000
Message-ID: <1322156679-9441-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 01/10] pci_ids: Add INTEL_82599_VF id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index 83f3893..2ea5ec2 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -117,6 +117,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_VF     0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:49:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:49:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdQ7-0004X9-N1; Thu, 24 Nov 2011 17:49:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdQ6-0004Ur-Qi
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:49:11 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18181 invoked from network); 24 Nov 2011 17:44:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:44:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809595"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:44:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:44:56 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ2027444;	Thu, 24 Nov 2011 09:44:55 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:30 +0000
Message-ID: <1322156679-9441-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 01/10] pci_ids: Add INTEL_82599_VF id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/pci_ids.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index 83f3893..2ea5ec2 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -117,6 +117,7 @@
 #define PCI_DEVICE_ID_INTEL_82801I_UHCI6 0x2939
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI1 0x293a
 #define PCI_DEVICE_ID_INTEL_82801I_EHCI2 0x293c
+#define PCI_DEVICE_ID_INTEL_82599_VF     0x10ed
 
 #define PCI_VENDOR_ID_XEN               0x5853
 #define PCI_DEVICE_ID_XEN_PLATFORM      0x0001
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:49:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:49:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdQA-0004YA-4m; Thu, 24 Nov 2011 17:49:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdQ8-0004VN-7M
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:49:12 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!6
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18419 invoked from network); 24 Nov 2011 17:45:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:45:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809611"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:11 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJB027444;	Thu, 24 Nov 2011 09:45:09 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:39 +0000
Message-ID: <1322156679-9441-11-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 10/10] Introduce Xen PCI Passthrough,
	MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    1 +
 hw/apic-msidef.h                     |    2 +
 hw/xen_pci_passthrough.c             |   60 +++-
 hw/xen_pci_passthrough.h             |   55 +++
 hw/xen_pci_passthrough_config_init.c |  505 +++++++++++++++++++++++++-
 hw/xen_pci_passthrough_msi.c         |  678 ++++++++++++++++++++++++++++++++++
 6 files changed, 1294 insertions(+), 7 deletions(-)
 create mode 100644 hw/xen_pci_passthrough_msi.c

diff --git a/Makefile.target b/Makefile.target
index 33435a3..81cff70 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -223,6 +223,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
index 3182f0b..6e2eb71 100644
--- a/hw/apic-msidef.h
+++ b/hw/apic-msidef.h
@@ -22,6 +22,8 @@
 
 #define MSI_ADDR_DEST_MODE_SHIFT        2
 
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
 #define MSI_ADDR_DEST_ID_SHIFT          12
 #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
 
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index c816ed5..cd7e3c7 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -38,6 +38,39 @@
  *     Write '1'
  *       <ptdev->msi_trans_en is false>
  *         - Set real bit to '1'.
+ *
+ * MSI-INTx translation.
+ *   Initialize(xc_physdev_map_pirq_msi/pt_msi_setup)
+ *     Bind MSI-INTx(xc_domain_bind_pt_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *           <success>
+ *             - Set dev->msi->pirq to '-1'.
+ *           <fail>
+ *             - Do nothing.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       <ptdev->msi_trans_en is true>
+ *         - Set MSI Enable bit to '1'.
+ *
+ *     Write '1'
+ *       <ptdev->msi_trans_en is true>
+ *         - Set MSI Enable bit to '0'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(pt_msi_setup, pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -389,6 +422,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
     }
 
     if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        pt_add_msix_mapping(s, i);
         /* Remove old mapping */
         memory_region_del_subregion(r->address_space,
                                     r->memory);
@@ -417,6 +451,15 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
         if (ret != 0) {
             PT_ERR(&s->dev, "create new mapping failed!\n");
         }
+
+        ret = pt_remove_msix_mapping(s, i);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed!\n");
+        }
+
+        if (old_ebase != e_phys && old_ebase != -1) {
+            pt_msix_update_remap(s, i);
+        }
     }
 }
 
@@ -744,6 +787,9 @@ static int pt_initfn(PCIDevice *pcidev)
         mapped_machine_irq[machine_irq]++;
     }
 
+    /* setup MSI-INTx translation if support */
+    rc = pt_enable_msi_translate(s);
+
     /* bind machine_irq to device */
     if (rc < 0 && machine_irq != 0) {
         uint8_t e_device = PCI_SLOT(s->dev.devfn);
@@ -773,7 +819,8 @@ static int pt_initfn(PCIDevice *pcidev)
 
 out:
     PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
-           "\nIRQ type = %s\n", bus, slot, func, "INTx");
+           "\nIRQ type = %s\n", bus, slot, func,
+           s->msi_trans_en ? "MSI-INTx" : "INTx");
 
     return 0;
 }
@@ -790,7 +837,7 @@ static int pt_unregister_device(PCIDevice *pcidev)
     e_intx = pci_intx(s);
     machine_irq = s->machine_irq;
 
-    if (machine_irq) {
+    if (s->msi_trans_en == 0 && machine_irq) {
         rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
                                      PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);
         if (rc < 0) {
@@ -798,6 +845,13 @@ static int pt_unregister_device(PCIDevice *pcidev)
         }
     }
 
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         mapped_machine_irq[machine_irq]--;
 
@@ -832,6 +886,8 @@ static PCIDeviceInfo xen_pci_passthrough = {
     .is_express = 0,
     .qdev.props = (Property[]) {
         DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+        DEFINE_PROP_BIT("msitranslate", XenPCIPassthroughState, msi_trans_cap,
+                        0, true),
         DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
                         0, false),
         DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 110325c..acbbab5 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -74,6 +74,10 @@ typedef int (*conf_byte_restore)
 #define PT_PCI_BAR_UNMAPPED (-1)
 #define PT_UNASSIGNED_PIRQ (-1)
 
+/* MSI-X */
+#define PT_MSI_FLAG_UNINIT 0x1000
+#define PT_MSI_FLAG_MAPPED 0x2000
+
 
 typedef enum {
     GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
@@ -177,6 +181,34 @@ typedef struct XenPTRegGroup {
 } XenPTRegGroup;
 
 
+typedef struct XenPTMSI {
+    uint32_t flags;
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+} XenPTMSI;
+
+typedef struct XenMSIXEntry {
+    int pirq;        /* -1 means unmapped */
+    int flags;       /* flags indicting whether MSI ADDR or DATA is updated */
+    uint32_t io_mem[4];
+} XenMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    int enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_off;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    int mmio_index;
+    void *phys_iomem_base;
+    XenMSIXEntry msix_entry[0];
+} XenPTMSIX;
+
 typedef struct XenPTPM {
     QEMUTimer *pm_timer;  /* QEMUTimer struct */
     int no_soft_reset;    /* No Soft Reset flags */
@@ -200,6 +232,13 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
+    /* Physical MSI to guest INTx translation when possible */
+    uint32_t msi_trans_cap;
+    bool msi_trans_en;
+
     uint32_t power_mgmt;
     XenPTPM *pm_state;
 
@@ -279,4 +318,20 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+void pt_msi_set_enable(XenPCIPassthroughState *s, int en);
+int pt_msi_setup(XenPCIPassthroughState *s);
+int pt_msi_update(XenPCIPassthroughState *d);
+void pt_msi_disable(XenPCIPassthroughState *s);
+int pt_enable_msi_translate(XenPCIPassthroughState *s);
+void pt_disable_msi_translate(XenPCIPassthroughState *s);
+
+int pt_msix_init(XenPCIPassthroughState *s, int pos);
+void pt_msix_delete(XenPCIPassthroughState *s);
+int pt_msix_update(XenPCIPassthroughState *s);
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void pt_msix_disable(XenPCIPassthroughState *s);
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index ae64544..28523f1 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -398,11 +398,19 @@ static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
     throughable_mask = ~emu_mask & valid_mask;
 
     if (*value & PCI_COMMAND_INTX_DISABLE) {
-        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
-    } else {
-        if (s->machine_irq) {
+        if (s->msi_trans_en) {
+            pt_msi_set_enable(s, 0);
+        } else {
             throughable_mask |= PCI_COMMAND_INTX_DISABLE;
         }
+    } else {
+        if (s->msi_trans_en) {
+            pt_msi_set_enable(s, 1);
+        } else {
+            if (s->machine_irq) {
+                throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+            }
+        }
     }
 
     *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
@@ -1282,13 +1290,21 @@ static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
     e_device = PCI_SLOT(s->dev.devfn);
     e_intx = pci_intx(s);
 
-    if (s->machine_irq) {
+    if (s->msi_trans_en == 0 && s->machine_irq) {
         if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
                                     PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
             PT_ERR(d, "Unbinding of interrupt failed!\n");
         }
     }
 
+    /* disable MSI/MSI-X and MSI-INTx translation */
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     /* clear all virtual region address */
     for (i = 0; i < PCI_NUM_REGIONS; i++) {
         r = &d->io_regions[i];
@@ -1536,6 +1552,415 @@ static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
     },
 };
 
+/********************************
+ * MSI Capability
+ */
+
+/* Message Control register */
+static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        PT_LOG(&s->dev, "MSI already enabled, disable it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    s->msi->flags |= reg_field | PT_MSI_FLAG_UNINIT;
+    s->msi->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t val;
+
+    /* Currently no support for multi-vector */
+    if (*value & PCI_MSI_FLAGS_QSIZE) {
+        PT_WARN(&s->dev, "try to set more than 1 vector ctrl %x\n", *value);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->flags |= cfg_entry->data &
+        ~(PT_MSI_FLAG_UNINIT | PT_MSI_FLAG_MAPPED | PCI_MSI_FLAGS_ENABLE);
+
+    /* create value for writing to I/O device register */
+    val = *value;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (s->msi->flags & PT_MSI_FLAG_UNINIT) {
+            if (s->msi_trans_en) {
+                PT_LOG(&s->dev,
+                       "guest enabling MSI, disable MSI-INTx translation\n");
+                pt_disable_msi_translate(s);
+            } else {
+                /* Init physical one */
+                PT_LOG(&s->dev, "setup MSI\n");
+                if (pt_msi_setup(s)) {
+                    /* We do not broadcast the error to the framework code, so
+                     * that MSI errors are contained in MSI emulation code and
+                     * QEMU can go on running.
+                     * Guest MSI would be actually not working.
+                     */
+                    *value &= ~PCI_MSI_FLAGS_ENABLE;
+                    PT_WARN(&s->dev, "Can not map MSI.\n");
+                    return 0;
+                }
+            }
+            if (pt_msi_update(s)) {
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            s->msi->flags &= ~PT_MSI_FLAG_UNINIT;
+            s->msi->flags |= PT_MSI_FLAG_MAPPED;
+        }
+        s->msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        s->msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit when no MSI-INTx translation */
+    if (!s->msi_trans_en) {
+        *value &= ~PCI_MSI_FLAGS_ENABLE;
+        *value |= val & PCI_MSI_FLAGS_ENABLE;
+    }
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int pt_msgaddr64_reg_init(XenPCIPassthroughState *ptdev,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(ptdev->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int pt_msgdata_reg_init(XenPCIPassthroughState *ptdev,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    uint32_t flags = ptdev->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) ||
+        ((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {
+        *data = reg->init_val;
+    } else {
+        *data = PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        PT_ERR(&s->dev, "Write to the Upper Address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) &&
+        !((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {
+        /* exit I/O emulator */
+        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = pt_msgctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr32_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgaddr64_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr64_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        PT_LOG(d, "MSIX already enabled, disable it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                 XenPTReg *cfg_entry, uint16_t *value,
+                                 uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*value & PCI_MSIX_FLAGS_ENABLE)
+        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
+        if (s->msi_trans_en) {
+            PT_LOG(&s->dev,
+                   "guest enabling MSI-X, disable MSI-INTx translation\n");
+            pt_disable_msi_translate(s);
+        }
+        pt_msix_update(s);
+    }
+
+    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = pt_msixctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msixctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
 
 /****************************
  * Capabilities
@@ -1709,6 +2134,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int pt_msi_size_init(XenPCIPassthroughState *s,
+                            const XenPTRegGroupInfo *grp_reg,
+                            uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check 64 bit address capable & Per-vector masking capable */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int pt_msix_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = pt_msix_init(s, base_offset);
+
+    if (rc == -1) {
+        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
     /* Header Type0 reg group */
@@ -1749,6 +2217,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .grp_size   = 0x04,
         .size_init  = pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_msi_size_init,
+        .emu_reg_tbl = pt_emu_reg_msi_tbl,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1793,6 +2269,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .size_init   = pt_pcie_size_init,
         .emu_reg_tbl = pt_emu_reg_pcie_tbl,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = pt_msix_size_init,
+        .emu_reg_tbl = pt_emu_reg_msix_tbl,
+    },
     {
         .grp_size = 0,
     },
@@ -1965,8 +2449,11 @@ static int pt_init_pci_config(XenPCIPassthroughState *s)
         return rc;
     }
 
+    /* setup MSI-INTx translation if support */
+    rc = pt_enable_msi_translate(s);
+
     /* rebind machine_irq to device */
-    if (s->machine_irq != 0) {
+    if (rc < 0 && s->machine_irq != 0) {
         uint8_t e_device = PCI_SLOT(s->dev.devfn);
         uint8_t e_intx = pci_intx(s);
 
@@ -2117,6 +2604,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free Power Management info table */
     if (s->pm_state) {
         if (s->pm_state->pm_timer) {
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
new file mode 100644
index 0000000..73d3d9b
--- /dev/null
+++ b/hw/xen_pci_passthrough_msi.c
@@ -0,0 +1,678 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+#include "apic-msidef.h"
+
+
+#define AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define GFLAGS_SHIFT_DEST_ID        0
+#define GFLAGS_SHIFT_RH             8
+#define GFLAGS_SHIFT_DM             9
+#define GLFAGS_SHIFT_DELIV_MODE     12
+#define GLFAGS_SHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static uint32_t get_msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = (addr >> MSI_ADDR_DEST_ID_SHIFT) & 0xff;
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
+             (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
+             (trig_mode << GLFAGS_SHIFT_TRG_MODE);
+
+    return result;
+}
+
+
+/*
+ * MSI virtualization functions
+ */
+
+void pt_msi_set_enable(XenPCIPassthroughState *s, int en)
+{
+    uint16_t val = 0;
+    uint32_t address = 0;
+
+    PT_LOG(&s->dev, "enable: %i\n", en);
+
+    if (!s->msi) {
+        return;
+    }
+
+    address = s->msi->ctrl_offset;
+    if (!address) {
+        return;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    val &= ~PCI_MSI_FLAGS_ENABLE;
+    val |= en & PCI_MSI_FLAGS_ENABLE;
+    host_pci_set_word(s->real_device, address, val);
+}
+
+/* setup physical msi, but don't enable it */
+int pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = PT_UNASSIGNED_PIRQ;
+    uint8_t gvec = 0;
+    int rc = 0;
+
+    if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
+        PT_ERR(&s->dev, "Setup physical MSI when it's already initialized.\n");
+        return -1;
+    }
+
+    gvec = s->msi->data & 0xFF;
+    if (!gvec) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        pirq = (s->msi->addr_hi & 0xffffff00) |
+               ((s->msi->addr_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
+        if (!pirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            pirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
+        }
+    }
+
+    rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
+                                 PCI_DEVFN(s->real_device->dev,
+                                           s->real_device->func),
+                                 s->real_device->bus, 0, 0);
+    if (rc) {
+        PT_ERR(&s->dev, "Mapping of MSI failed. (rc: %d,"
+               " assigned device: %02x:%02x.%x)\n", rc,
+               s->real_device->dev, s->real_device->func, s->real_device->bus);
+        return -1;
+    }
+
+    if (pirq < 0) {
+        PT_ERR(&s->dev, "Invalid pirq number.\n");
+        return -1;
+    }
+
+    s->msi->pirq = pirq;
+    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int pt_msi_update(XenPCIPassthroughState *s)
+{
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    int rc = 0;
+
+    /* get vector, address, flags info, etc. */
+    gvec = s->msi->data & 0xFF;
+    addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
+    gflags = get_msi_gflags(s->msi->data, addr);
+
+    PT_LOG(&s->dev, "Update MSI with pirq %d gvec 0x%x gflags 0x%x\n",
+           s->msi->pirq, gvec, gflags);
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  s->msi->pirq, gflags, 0);
+    if (rc) {
+        PT_ERR(&s->dev, "Binding of MSI failed. (rc: %d)\n", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI pirq %d failed.\n",
+                   s->msi->pirq);
+        }
+        s->msi->pirq = PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+void pt_msi_disable(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    pt_msi_set_enable(s, 0);
+
+    e_device = PCI_SLOT(d->devfn);
+    e_intx = pci_intx(s);
+
+    if (s->msi_trans_en) {
+        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                                    PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                                    e_device, e_intx, 0)) {
+            PT_ERR(d, "Unbinding pt irq for MSI-INTx failed!\n");
+            goto out;
+        }
+    } else if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
+        /* get vector, address, flags info, etc. */
+        gvec = s->msi->data & 0xFF;
+        addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
+        gflags = get_msi_gflags(s->msi->data, addr);
+
+        PT_ERR(&s->dev, "Unbind MSI with pirq %x, gvec %x\n",
+               s->msi->pirq, gvec);
+
+        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
+                                     s->msi->pirq, gflags)) {
+            PT_ERR(&s->dev, "Unbinding of MSI failed. (pirq: %d)\n",
+                   s->msi->pirq);
+            goto out;
+        }
+    }
+
+    if (s->msi->pirq != PT_UNASSIGNED_PIRQ) {
+        PT_LOG(&s->dev, "Unmap msi with pirq %d\n", s->msi->pirq);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI failed. (pirq: %d)\n",
+                   s->msi->pirq);
+            goto out;
+        }
+    }
+
+out:
+    /* clear msi info */
+    s->msi->flags = 0;
+    s->msi->pirq = -1;
+    s->msi_trans_en = 0;
+}
+
+/*
+ * MSI-INTx translation virtualization functions
+ */
+
+int pt_enable_msi_translate(XenPCIPassthroughState *s)
+{
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    if (!(s->msi && s->msi_trans_cap)) {
+        return -1;
+    }
+
+    pt_msi_set_enable(s, 0);
+    s->msi_trans_en = 0;
+
+    if (pt_msi_setup(s)) {
+        PT_ERR(&s->dev, "MSI-INTx translation MSI setup failed, fallback\n");
+        return -1;
+    }
+
+    e_device = PCI_SLOT(s->dev.devfn);
+    /* fix virtual interrupt pin to INTA# */
+    e_intx = pci_intx(s);
+
+    if (xc_domain_bind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                              PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                              e_device, e_intx, 0)) {
+        PT_ERR(&s->dev, "MSI-INTx translation bind failed, fallback\n");
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI failed.\n");
+        }
+        s->msi->pirq = PT_UNASSIGNED_PIRQ;
+        return -1;
+    }
+
+    pt_msi_set_enable(s, 1);
+    s->msi_trans_en = 1;
+
+    return 0;
+}
+
+void pt_disable_msi_translate(XenPCIPassthroughState *s)
+{
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    /* MSI_ENABLE bit should be disabed until the new handler is set */
+    pt_msi_set_enable(s, 0);
+
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+
+    if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                                PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                                e_device, e_intx, 0)) {
+        PT_ERR(&s->dev, "Unbinding pt irq for MSI-INTx failed!\n");
+    }
+
+    if (s->machine_irq) {
+        if (xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq,
+                                      0, e_device, e_intx)) {
+            PT_ERR(&s->dev, "Rebinding of interrupt failed!\n");
+        }
+    }
+
+    s->msi_trans_en = 0;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static void msix_set_enable(XenPCIPassthroughState *s, int en)
+{
+    uint16_t val = 0;
+    uint32_t address = 0;
+
+    if (!s->msix) {
+        return;
+    }
+
+    address = s->msix->ctrl_offset;
+    if (!address) {
+        return;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    val &= ~PCI_MSIX_FLAGS_ENABLE;
+    if (en) {
+        val |= PCI_MSIX_FLAGS_ENABLE;
+    }
+    host_pci_set_word(s->real_device, address, val);
+}
+
+static void mask_physical_msix_entry(XenPCIPassthroughState *s,
+                                     int entry_nr, int mask)
+{
+    void *phys_off;
+
+    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;
+    *(uint32_t *)phys_off = mask;
+}
+
+static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenMSIXEntry *entry = &s->msix->msix_entry[entry_nr];
+    int pirq = entry->pirq;
+    int gvec = entry->io_mem[2] & 0xff;
+    uint64_t gaddr = *(uint64_t *)&entry->io_mem[0];
+    uint32_t gflags = get_msi_gflags(entry->io_mem[2], gaddr);
+    int rc;
+
+    if (!entry->flags) {
+        return 0;
+    }
+
+    if (!gvec) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        pirq = ((gaddr >> 32) & 0xffffff00) |
+               (((gaddr & 0xffffffff) >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
+        if (!pirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            pirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
+        }
+    }
+
+    /* Check if this entry is already mapped */
+    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
+                                     PCI_DEVFN(s->real_device->dev,
+                                               s->real_device->func),
+                                     s->real_device->bus, entry_nr,
+                                     s->msix->table_base);
+        if (rc) {
+            PT_ERR(&s->dev, "Mapping msix entry %x\n", entry_nr);
+            return rc;
+        }
+        entry->pirq = pirq;
+    }
+
+    PT_LOG(&s->dev, "Update msix entry 0x%x with pirq %d gvec 0x%x\n",
+            entry_nr, pirq, gvec);
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags,
+                                  s->msix->mmio_base_addr);
+    if (rc) {
+        PT_ERR(&s->dev, "Updating msix irq %d info for entry %d\n",
+               pirq, entry_nr);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI-X failed. (pirq: %d)\n",
+                   entry->pirq);
+        }
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        return rc;
+    }
+
+    entry->flags = 0;
+
+    return 0;
+}
+
+int pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void pt_msix_disable(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    int i = 0;
+    XenMSIXEntry *entry = NULL;
+
+    msix_set_enable(s, 0);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+
+        if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+            continue;
+        }
+
+        gvec = entry->io_mem[2] & 0xff;
+        addr = *(uint64_t *)&entry->io_mem[0];
+        gflags = get_msi_gflags(entry->io_mem[2], addr);
+
+        PT_LOG(d, "Unbind msix with pirq %d, gvec 0x%x\n",
+                entry->pirq, gvec);
+
+        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
+                                        entry->pirq, gflags)) {
+            PT_ERR(d, "Unbinding of MSI-X failed.\n");
+        } else {
+            PT_LOG(d, "Unmap msix with pirq %d\n", entry->pirq);
+
+            if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
+                PT_ERR(d, "Unmapping of MSI-X failed.\n");
+            }
+        }
+        /* clear msi-x info */
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        entry->flags = 0;
+    }
+}
+
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
+            }
+            entry->flags = 1;
+        }
+    }
+    pt_msix_update(s);
+
+    return 0;
+}
+
+static void pci_msix_invalid_write(void *opaque, target_phys_addr_t addr,
+                                   uint32_t val)
+{
+    XenPCIPassthroughState *s = opaque;
+    PT_ERR(&s->dev, "Invalid write to MSI-X table,"
+           " only dword access is allowed.\n");
+}
+
+static void pci_msix_writel(void *opaque, target_phys_addr_t addr,
+                            uint32_t val)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenMSIXEntry *entry;
+    int entry_nr, offset;
+    void *phys_off;
+    uint32_t vec_ctrl;
+
+    if (addr % 4) {
+        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
+                "addr 0x"TARGET_FMT_plx"\n", addr);
+        return;
+    }
+
+    entry_nr = addr / 16;
+    entry = &msix->msix_entry[entry_nr];
+    offset = (addr % 16) / 4;
+
+    /*
+     * If Xen intercepts the mask bit access, io_mem[3] may not be
+     * up-to-date. Read from hardware directly.
+     */
+    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;
+    vec_ctrl = *(uint32_t *)phys_off;
+
+    if (offset != 3 && msix->enabled && !(vec_ctrl & 0x1)) {
+        PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
+                "enabled.\n", entry_nr);
+        return;
+    }
+
+    if (offset != 3 && entry->io_mem[offset] != val) {
+        entry->flags = 1;
+    }
+    entry->io_mem[offset] = val;
+
+    if (offset == 3) {
+        if (msix->enabled && !(val & 0x1)) {
+            pt_msix_update_one(s, entry_nr);
+        }
+        mask_physical_msix_entry(s, entry_nr, entry->io_mem[3] & 0x1);
+    }
+}
+
+static CPUWriteMemoryFunc *pci_msix_write[] = {
+    pci_msix_invalid_write,
+    pci_msix_invalid_write,
+    pci_msix_writel
+};
+
+static uint32_t pci_msix_invalid_read(void *opaque, target_phys_addr_t addr)
+{
+    XenPCIPassthroughState *s = opaque;
+    PT_ERR(&s->dev, "Invalid read to MSI-X table,"
+           " only dword access is allowed.\n");
+    return 0;
+}
+
+static uint32_t pci_msix_readl(void *opaque, target_phys_addr_t addr)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    if (addr % 4) {
+        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
+                "addr 0x"TARGET_FMT_plx"\n", addr);
+        return 0;
+    }
+
+    entry_nr = addr / 16;
+    offset = (addr % 16) / 4;
+
+    return msix->msix_entry[entry_nr].io_mem[offset];
+}
+
+static CPUReadMemoryFunc *pci_msix_read[] = {
+    pci_msix_invalid_read,
+    pci_msix_invalid_read,
+    pci_msix_readl
+};
+
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+         DPCI_ADD_MAPPING);
+}
+
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    s->msix->mmio_base_addr = s->bases[bar_index].e_physbase
+        + s->msix->table_off;
+
+    cpu_register_physical_memory(s->msix->mmio_base_addr,
+                                 s->msix->total_entries * 16,
+                                 s->msix->mmio_index);
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+         DPCI_REMOVE_MAPPING);
+}
+
+int pt_msix_init(XenPCIPassthroughState *s, int base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    HostPCIDevice *d = s->real_device;
+    int fd;
+
+    if (host_pci_get_byte(d, base + PCI_CAP_LIST_ID, &id)) {
+        return -1;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        PT_ERR(&s->dev, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    host_pci_get_word(d, base + 2, &control);
+    total_entries = control & 0x7ff;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenMSIXEntry));
+
+    s->msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        s->msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
+    }
+
+    s->msix->mmio_index =
+        cpu_register_io_memory(pci_msix_read, pci_msix_write,
+                               s, DEVICE_NATIVE_ENDIAN);
+
+    host_pci_get_long(d, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = s->msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = s->msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    s->msix->table_base = s->real_device->io_regions[bar_index].base_addr;
+    PT_LOG(&s->dev, "get MSI-X table BAR base 0x%"PRIx64"\n",
+           s->msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        PT_ERR(&s->dev, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    PT_LOG(&s->dev, "table_off = %#x, total_entries = %d\n",
+           table_off, total_entries);
+    s->msix->table_offset_adjust = table_off & 0x0fff;
+    s->msix->phys_iomem_base =
+        mmap(0,
+             total_entries * 16 + s->msix->table_offset_adjust,
+             PROT_WRITE | PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             s->msix->table_base + table_off - s->msix->table_offset_adjust);
+
+    if (s->msix->phys_iomem_base == MAP_FAILED) {
+        PT_ERR(&s->dev, "Can't map physical MSI-X table: %s\n",
+               strerror(errno));
+        close(fd);
+        goto error_out;
+    }
+    s->msix->phys_iomem_base = (char *)s->msix->phys_iomem_base
+        + s->msix->table_offset_adjust;
+
+    close(fd);
+
+    PT_LOG(&s->dev, "mapping physical MSI-X table to %p\n",
+           s->msix->phys_iomem_base);
+    return 0;
+
+error_out:
+    g_free(s->msix);
+    s->msix = NULL;
+    return -1;
+}
+
+void pt_msix_delete(XenPCIPassthroughState *s)
+{
+    /* unmap the MSI-X memory mapped register area */
+    if (s->msix->phys_iomem_base) {
+        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+           s->msix->phys_iomem_base);
+        munmap(s->msix->phys_iomem_base, s->msix->total_entries * 16 +
+           s->msix->table_offset_adjust);
+    }
+
+    if (s->msix->mmio_index > 0) {
+        cpu_unregister_io_memory(s->msix->mmio_index);
+    }
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:49:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:49:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdQA-0004YA-4m; Thu, 24 Nov 2011 17:49:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdQ8-0004VN-7M
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:49:12 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!6
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18419 invoked from network); 24 Nov 2011 17:45:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:45:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809611"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:11 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJB027444;	Thu, 24 Nov 2011 09:45:09 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:39 +0000
Message-ID: <1322156679-9441-11-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Shan Haitao <haitao.shan@intel.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 10/10] Introduce Xen PCI Passthrough,
	MSI (3/3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Jiang Yunhong <yunhong.jiang@intel.com>

A more complete history can be found here:
git://xenbits.xensource.com/qemu-xen-unstable.git

Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Shan Haitao <haitao.shan@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target                      |    1 +
 hw/apic-msidef.h                     |    2 +
 hw/xen_pci_passthrough.c             |   60 +++-
 hw/xen_pci_passthrough.h             |   55 +++
 hw/xen_pci_passthrough_config_init.c |  505 +++++++++++++++++++++++++-
 hw/xen_pci_passthrough_msi.c         |  678 ++++++++++++++++++++++++++++++++++
 6 files changed, 1294 insertions(+), 7 deletions(-)
 create mode 100644 hw/xen_pci_passthrough_msi.c

diff --git a/Makefile.target b/Makefile.target
index 33435a3..81cff70 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -223,6 +223,7 @@ obj-i386-$(CONFIG_XEN) += xen_platform.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough.o
 obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_config_init.o
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pci_passthrough_msi.o
 
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
diff --git a/hw/apic-msidef.h b/hw/apic-msidef.h
index 3182f0b..6e2eb71 100644
--- a/hw/apic-msidef.h
+++ b/hw/apic-msidef.h
@@ -22,6 +22,8 @@
 
 #define MSI_ADDR_DEST_MODE_SHIFT        2
 
+#define MSI_ADDR_REDIRECTION_SHIFT      3
+
 #define MSI_ADDR_DEST_ID_SHIFT          12
 #define  MSI_ADDR_DEST_ID_MASK          0x00ffff0
 
diff --git a/hw/xen_pci_passthrough.c b/hw/xen_pci_passthrough.c
index c816ed5..cd7e3c7 100644
--- a/hw/xen_pci_passthrough.c
+++ b/hw/xen_pci_passthrough.c
@@ -38,6 +38,39 @@
  *     Write '1'
  *       <ptdev->msi_trans_en is false>
  *         - Set real bit to '1'.
+ *
+ * MSI-INTx translation.
+ *   Initialize(xc_physdev_map_pirq_msi/pt_msi_setup)
+ *     Bind MSI-INTx(xc_domain_bind_pt_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *           <success>
+ *             - Set dev->msi->pirq to '-1'.
+ *           <fail>
+ *             - Do nothing.
+ *
+ *   Write to Interrupt Disable bit by guest software(pt_cmd_reg_write)
+ *     Write '0'
+ *       <ptdev->msi_trans_en is true>
+ *         - Set MSI Enable bit to '1'.
+ *
+ *     Write '1'
+ *       <ptdev->msi_trans_en is true>
+ *         - Set MSI Enable bit to '0'.
+ *
+ * MSI interrupt:
+ *   Initialize MSI register(pt_msi_setup, pt_msi_update)
+ *     Bind MSI(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI.
+ *         - Set dev->msi->pirq to '-1'.
+ *
+ * MSI-X interrupt:
+ *   Initialize MSI-X register(pt_msix_update_one)
+ *     Bind MSI-X(xc_domain_update_msi_irq)
+ *       <fail>
+ *         - Unmap MSI-X.
+ *         - Set entry->pirq to '-1'.
  */
 
 #include <sys/ioctl.h>
@@ -389,6 +422,7 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
     }
 
     if (!first_map && old_ebase != PT_PCI_BAR_UNMAPPED) {
+        pt_add_msix_mapping(s, i);
         /* Remove old mapping */
         memory_region_del_subregion(r->address_space,
                                     r->memory);
@@ -417,6 +451,15 @@ static void pt_iomem_map(XenPCIPassthroughState *s, int i,
         if (ret != 0) {
             PT_ERR(&s->dev, "create new mapping failed!\n");
         }
+
+        ret = pt_remove_msix_mapping(s, i);
+        if (ret != 0) {
+            PT_ERR(&s->dev, "Remove MSI-X MMIO mapping failed!\n");
+        }
+
+        if (old_ebase != e_phys && old_ebase != -1) {
+            pt_msix_update_remap(s, i);
+        }
     }
 }
 
@@ -744,6 +787,9 @@ static int pt_initfn(PCIDevice *pcidev)
         mapped_machine_irq[machine_irq]++;
     }
 
+    /* setup MSI-INTx translation if support */
+    rc = pt_enable_msi_translate(s);
+
     /* bind machine_irq to device */
     if (rc < 0 && machine_irq != 0) {
         uint8_t e_device = PCI_SLOT(s->dev.devfn);
@@ -773,7 +819,8 @@ static int pt_initfn(PCIDevice *pcidev)
 
 out:
     PT_LOG(pcidev, "Real physical device %02x:%02x.%x registered successfuly!"
-           "\nIRQ type = %s\n", bus, slot, func, "INTx");
+           "\nIRQ type = %s\n", bus, slot, func,
+           s->msi_trans_en ? "MSI-INTx" : "INTx");
 
     return 0;
 }
@@ -790,7 +837,7 @@ static int pt_unregister_device(PCIDevice *pcidev)
     e_intx = pci_intx(s);
     machine_irq = s->machine_irq;
 
-    if (machine_irq) {
+    if (s->msi_trans_en == 0 && machine_irq) {
         rc = xc_domain_unbind_pt_irq(xen_xc, xen_domid, machine_irq,
                                      PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0);
         if (rc < 0) {
@@ -798,6 +845,13 @@ static int pt_unregister_device(PCIDevice *pcidev)
         }
     }
 
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     if (machine_irq) {
         mapped_machine_irq[machine_irq]--;
 
@@ -832,6 +886,8 @@ static PCIDeviceInfo xen_pci_passthrough = {
     .is_express = 0,
     .qdev.props = (Property[]) {
         DEFINE_PROP_STRING("hostaddr", XenPCIPassthroughState, hostaddr),
+        DEFINE_PROP_BIT("msitranslate", XenPCIPassthroughState, msi_trans_cap,
+                        0, true),
         DEFINE_PROP_BIT("power-mgmt", XenPCIPassthroughState, power_mgmt,
                         0, false),
         DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/xen_pci_passthrough.h b/hw/xen_pci_passthrough.h
index 110325c..acbbab5 100644
--- a/hw/xen_pci_passthrough.h
+++ b/hw/xen_pci_passthrough.h
@@ -74,6 +74,10 @@ typedef int (*conf_byte_restore)
 #define PT_PCI_BAR_UNMAPPED (-1)
 #define PT_UNASSIGNED_PIRQ (-1)
 
+/* MSI-X */
+#define PT_MSI_FLAG_UNINIT 0x1000
+#define PT_MSI_FLAG_MAPPED 0x2000
+
 
 typedef enum {
     GRP_TYPE_HARDWIRED = 0,                     /* 0 Hardwired reg group */
@@ -177,6 +181,34 @@ typedef struct XenPTRegGroup {
 } XenPTRegGroup;
 
 
+typedef struct XenPTMSI {
+    uint32_t flags;
+    uint32_t ctrl_offset; /* saved control offset */
+    int pirq;          /* guest pirq corresponding */
+    uint32_t addr_lo;  /* guest message address */
+    uint32_t addr_hi;  /* guest message upper address */
+    uint16_t data;     /* guest message data */
+} XenPTMSI;
+
+typedef struct XenMSIXEntry {
+    int pirq;        /* -1 means unmapped */
+    int flags;       /* flags indicting whether MSI ADDR or DATA is updated */
+    uint32_t io_mem[4];
+} XenMSIXEntry;
+typedef struct XenPTMSIX {
+    uint32_t ctrl_offset;
+    int enabled;
+    int total_entries;
+    int bar_index;
+    uint64_t table_base;
+    uint32_t table_off;
+    uint32_t table_offset_adjust; /* page align mmap */
+    uint64_t mmio_base_addr;
+    int mmio_index;
+    void *phys_iomem_base;
+    XenMSIXEntry msix_entry[0];
+} XenPTMSIX;
+
 typedef struct XenPTPM {
     QEMUTimer *pm_timer;  /* QEMUTimer struct */
     int no_soft_reset;    /* No Soft Reset flags */
@@ -200,6 +232,13 @@ struct XenPCIPassthroughState {
 
     uint32_t machine_irq;
 
+    XenPTMSI *msi;
+    XenPTMSIX *msix;
+
+    /* Physical MSI to guest INTx translation when possible */
+    uint32_t msi_trans_cap;
+    bool msi_trans_en;
+
     uint32_t power_mgmt;
     XenPTPM *pm_state;
 
@@ -279,4 +318,20 @@ static inline uint8_t pci_intx(XenPCIPassthroughState *s)
     return r_val;
 }
 
+/* MSI/MSI-X */
+void pt_msi_set_enable(XenPCIPassthroughState *s, int en);
+int pt_msi_setup(XenPCIPassthroughState *s);
+int pt_msi_update(XenPCIPassthroughState *d);
+void pt_msi_disable(XenPCIPassthroughState *s);
+int pt_enable_msi_translate(XenPCIPassthroughState *s);
+void pt_disable_msi_translate(XenPCIPassthroughState *s);
+
+int pt_msix_init(XenPCIPassthroughState *s, int pos);
+void pt_msix_delete(XenPCIPassthroughState *s);
+int pt_msix_update(XenPCIPassthroughState *s);
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index);
+void pt_msix_disable(XenPCIPassthroughState *s);
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index);
+
 #endif /* !QEMU_HW_XEN_PCI_PASSTHROUGH_H */
diff --git a/hw/xen_pci_passthrough_config_init.c b/hw/xen_pci_passthrough_config_init.c
index ae64544..28523f1 100644
--- a/hw/xen_pci_passthrough_config_init.c
+++ b/hw/xen_pci_passthrough_config_init.c
@@ -398,11 +398,19 @@ static int pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
     throughable_mask = ~emu_mask & valid_mask;
 
     if (*value & PCI_COMMAND_INTX_DISABLE) {
-        throughable_mask |= PCI_COMMAND_INTX_DISABLE;
-    } else {
-        if (s->machine_irq) {
+        if (s->msi_trans_en) {
+            pt_msi_set_enable(s, 0);
+        } else {
             throughable_mask |= PCI_COMMAND_INTX_DISABLE;
         }
+    } else {
+        if (s->msi_trans_en) {
+            pt_msi_set_enable(s, 1);
+        } else {
+            if (s->machine_irq) {
+                throughable_mask |= PCI_COMMAND_INTX_DISABLE;
+            }
+        }
     }
 
     *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
@@ -1282,13 +1290,21 @@ static void pt_reset_interrupt_and_io_mapping(XenPCIPassthroughState *s)
     e_device = PCI_SLOT(s->dev.devfn);
     e_intx = pci_intx(s);
 
-    if (s->machine_irq) {
+    if (s->msi_trans_en == 0 && s->machine_irq) {
         if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->machine_irq,
                                     PT_IRQ_TYPE_PCI, 0, e_device, e_intx, 0)) {
             PT_ERR(d, "Unbinding of interrupt failed!\n");
         }
     }
 
+    /* disable MSI/MSI-X and MSI-INTx translation */
+    if (s->msi) {
+        pt_msi_disable(s);
+    }
+    if (s->msix) {
+        pt_msix_disable(s);
+    }
+
     /* clear all virtual region address */
     for (i = 0; i < PCI_NUM_REGIONS; i++) {
         r = &d->io_regions[i];
@@ -1536,6 +1552,415 @@ static XenPTRegInfo pt_emu_reg_pm_tbl[] = {
     },
 };
 
+/********************************
+ * MSI Capability
+ */
+
+/* Message Control register */
+static int pt_msgctrl_reg_init(XenPCIPassthroughState *s,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSI_FLAGS_ENABLE) {
+        PT_LOG(&s->dev, "MSI already enabled, disable it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSI_FLAGS_ENABLE);
+    }
+    s->msi->flags |= reg_field | PT_MSI_FLAG_UNINIT;
+    s->msi->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msgctrl_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t val;
+
+    /* Currently no support for multi-vector */
+    if (*value & PCI_MSI_FLAGS_QSIZE) {
+        PT_WARN(&s->dev, "try to set more than 1 vector ctrl %x\n", *value);
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->flags |= cfg_entry->data &
+        ~(PT_MSI_FLAG_UNINIT | PT_MSI_FLAG_MAPPED | PCI_MSI_FLAGS_ENABLE);
+
+    /* create value for writing to I/O device register */
+    val = *value;
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (val & PCI_MSI_FLAGS_ENABLE) {
+        /* setup MSI pirq for the first time */
+        if (s->msi->flags & PT_MSI_FLAG_UNINIT) {
+            if (s->msi_trans_en) {
+                PT_LOG(&s->dev,
+                       "guest enabling MSI, disable MSI-INTx translation\n");
+                pt_disable_msi_translate(s);
+            } else {
+                /* Init physical one */
+                PT_LOG(&s->dev, "setup MSI\n");
+                if (pt_msi_setup(s)) {
+                    /* We do not broadcast the error to the framework code, so
+                     * that MSI errors are contained in MSI emulation code and
+                     * QEMU can go on running.
+                     * Guest MSI would be actually not working.
+                     */
+                    *value &= ~PCI_MSI_FLAGS_ENABLE;
+                    PT_WARN(&s->dev, "Can not map MSI.\n");
+                    return 0;
+                }
+            }
+            if (pt_msi_update(s)) {
+                *value &= ~PCI_MSI_FLAGS_ENABLE;
+                PT_WARN(&s->dev, "Can not bind MSI\n");
+                return 0;
+            }
+            s->msi->flags &= ~PT_MSI_FLAG_UNINIT;
+            s->msi->flags |= PT_MSI_FLAG_MAPPED;
+        }
+        s->msi->flags |= PCI_MSI_FLAGS_ENABLE;
+    } else {
+        s->msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+    }
+
+    /* pass through MSI_ENABLE bit when no MSI-INTx translation */
+    if (!s->msi_trans_en) {
+        *value &= ~PCI_MSI_FLAGS_ENABLE;
+        *value |= val & PCI_MSI_FLAGS_ENABLE;
+    }
+
+    return 0;
+}
+
+/* initialize Message Upper Address register */
+static int pt_msgaddr64_reg_init(XenPCIPassthroughState *ptdev,
+                                 XenPTRegInfo *reg, uint32_t real_offset,
+                                 uint32_t *data)
+{
+    /* no need to initialize in case of 32 bit type */
+    if (!(ptdev->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        *data = PT_INVALID_REG;
+    } else {
+        *data = reg->init_val;
+    }
+
+    return 0;
+}
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* initialize Message Data register */
+static int pt_msgdata_reg_init(XenPCIPassthroughState *ptdev,
+                               XenPTRegInfo *reg, uint32_t real_offset,
+                               uint32_t *data)
+{
+    uint32_t flags = ptdev->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) ||
+        ((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {
+        *data = reg->init_val;
+    } else {
+        *data = PT_INVALID_REG;
+    }
+    return 0;
+}
+
+/* write Message Address register */
+static int pt_msgaddr32_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_lo = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+/* write Message Upper Address register */
+static int pt_msgaddr64_reg_write(XenPCIPassthroughState *s,
+                                  XenPTReg *cfg_entry, uint32_t *value,
+                                  uint32_t dev_value, uint32_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint32_t writable_mask = 0;
+    uint32_t throughable_mask = 0;
+    uint32_t old_addr = cfg_entry->data;
+
+    /* check whether the type is 64 bit or not */
+    if (!(s->msi->flags & PCI_MSI_FLAGS_64BIT)) {
+        PT_ERR(&s->dev, "Write to the Upper Address without 64 bit support\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->addr_hi = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_addr) {
+        if (s->msi->flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+
+/* this function will be called twice (for 32 bit and 64 bit type) */
+/* write Message Data register */
+static int pt_msgdata_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
+                                uint16_t *value, uint16_t dev_value,
+                                uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+    uint16_t old_data = cfg_entry->data;
+    uint32_t flags = s->msi->flags;
+    uint32_t offset = reg->offset;
+
+    /* check the offset whether matches the type or not */
+    if (!((offset == PCI_MSI_DATA_64) &&  (flags & PCI_MSI_FLAGS_64BIT)) &&
+        !((offset == PCI_MSI_DATA_32) && !(flags & PCI_MSI_FLAGS_64BIT))) {
+        /* exit I/O emulator */
+        PT_ERR(&s->dev, "the offset does not match the 32/64 bit type!\n");
+        return -1;
+    }
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+    /* update the msi_info too */
+    s->msi->data = cfg_entry->data;
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI */
+    if (cfg_entry->data != old_data) {
+        if (flags & PT_MSI_FLAG_MAPPED) {
+            pt_msi_update(s);
+        }
+    }
+
+    return 0;
+}
+
+/* MSI Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msi_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0xFF8E,
+        .emu_mask   = 0x007F,
+        .init       = pt_msgctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Address reg */
+    {
+        .offset     = PCI_MSI_ADDRESS_LO,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000003,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_common_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr32_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Upper Address reg (if PCI_MSI_FLAGS_64BIT set) */
+    {
+        .offset     = PCI_MSI_ADDRESS_HI,
+        .size       = 4,
+        .init_val   = 0x00000000,
+        .ro_mask    = 0x00000000,
+        .emu_mask   = 0xFFFFFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgaddr64_reg_init,
+        .u.dw.read  = pt_long_reg_read,
+        .u.dw.write = pt_msgaddr64_reg_write,
+        .u.dw.restore = NULL,
+    },
+    /* Message Data reg (16 bits of data for 32-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_32,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    /* Message Data reg (16 bits of data for 64-bit devices) */
+    {
+        .offset     = PCI_MSI_DATA_64,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x0000,
+        .emu_mask   = 0xFFFF,
+        .no_wb      = 1,
+        .init       = pt_msgdata_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msgdata_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
+
+/**************************************
+ * MSI-X Capability
+ */
+
+/* Message Control register for MSI-X */
+static int pt_msixctrl_reg_init(XenPCIPassthroughState *s,
+                                XenPTRegInfo *reg, uint32_t real_offset,
+                                uint32_t *data)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t reg_field = 0;
+
+    /* use I/O device register's value as initial value */
+    reg_field = pci_get_word(d->config + real_offset);
+
+    if (reg_field & PCI_MSIX_FLAGS_ENABLE) {
+        PT_LOG(d, "MSIX already enabled, disable it first\n");
+        host_pci_set_word(s->real_device, real_offset,
+                          reg_field & ~PCI_MSIX_FLAGS_ENABLE);
+    }
+
+    s->msix->ctrl_offset = real_offset;
+
+    *data = reg->init_val;
+    return 0;
+}
+static int pt_msixctrl_reg_write(XenPCIPassthroughState *s,
+                                 XenPTReg *cfg_entry, uint16_t *value,
+                                 uint16_t dev_value, uint16_t valid_mask)
+{
+    XenPTRegInfo *reg = cfg_entry->reg;
+    uint16_t writable_mask = 0;
+    uint16_t throughable_mask = 0;
+
+    /* modify emulate register */
+    writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
+    cfg_entry->data = PT_MERGE_VALUE(*value, cfg_entry->data, writable_mask);
+
+    /* create value for writing to I/O device register */
+    throughable_mask = ~reg->emu_mask & valid_mask;
+    *value = PT_MERGE_VALUE(*value, dev_value, throughable_mask);
+
+    /* update MSI-X */
+    if ((*value & PCI_MSIX_FLAGS_ENABLE)
+        && !(*value & PCI_MSIX_FLAGS_MASKALL)) {
+        if (s->msi_trans_en) {
+            PT_LOG(&s->dev,
+                   "guest enabling MSI-X, disable MSI-INTx translation\n");
+            pt_disable_msi_translate(s);
+        }
+        pt_msix_update(s);
+    }
+
+    s->msix->enabled = !!(*value & PCI_MSIX_FLAGS_ENABLE);
+
+    return 0;
+}
+
+/* MSI-X Capability Structure reg static infomation table */
+static XenPTRegInfo pt_emu_reg_msix_tbl[] = {
+    /* Next Pointer reg */
+    {
+        .offset     = PCI_CAP_LIST_NEXT,
+        .size       = 1,
+        .init_val   = 0x00,
+        .ro_mask    = 0xFF,
+        .emu_mask   = 0xFF,
+        .init       = pt_ptr_reg_init,
+        .u.b.read   = pt_byte_reg_read,
+        .u.b.write  = pt_byte_reg_write,
+        .u.b.restore  = NULL,
+    },
+    /* Message Control reg */
+    {
+        .offset     = PCI_MSI_FLAGS,
+        .size       = 2,
+        .init_val   = 0x0000,
+        .ro_mask    = 0x3FFF,
+        .emu_mask   = 0x0000,
+        .init       = pt_msixctrl_reg_init,
+        .u.w.read   = pt_word_reg_read,
+        .u.w.write  = pt_msixctrl_reg_write,
+        .u.w.restore  = NULL,
+    },
+    {
+        .size = 0,
+    },
+};
+
 
 /****************************
  * Capabilities
@@ -1709,6 +2134,49 @@ static int pt_pcie_size_init(XenPCIPassthroughState *s,
     *size = pcie_size;
     return 0;
 }
+/* get MSI Capability Structure register group size */
+static int pt_msi_size_init(XenPCIPassthroughState *s,
+                            const XenPTRegGroupInfo *grp_reg,
+                            uint32_t base_offset, uint8_t *size)
+{
+    PCIDevice *d = &s->dev;
+    uint16_t msg_ctrl = 0;
+    uint8_t msi_size = 0xa;
+
+    msg_ctrl = pci_get_word(d->config + (base_offset + PCI_MSI_FLAGS));
+
+    /* check 64 bit address capable & Per-vector masking capable */
+    if (msg_ctrl & PCI_MSI_FLAGS_64BIT) {
+        msi_size += 4;
+    }
+    if (msg_ctrl & PCI_MSI_FLAGS_MASKBIT) {
+        msi_size += 10;
+    }
+
+    s->msi = g_new0(XenPTMSI, 1);
+    s->msi->pirq = PT_UNASSIGNED_PIRQ;
+
+    *size = msi_size;
+    return 0;
+}
+/* get MSI-X Capability Structure register group size */
+static int pt_msix_size_init(XenPCIPassthroughState *s,
+                             const XenPTRegGroupInfo *grp_reg,
+                             uint32_t base_offset, uint8_t *size)
+{
+    int rc = 0;
+
+    rc = pt_msix_init(s, base_offset);
+
+    if (rc == -1) {
+        PT_ERR(&s->dev, "Internal error: Invalid pt_msix_init.\n");
+        return rc;
+    }
+
+    *size = grp_reg->grp_size;
+    return 0;
+}
+
 
 static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
     /* Header Type0 reg group */
@@ -1749,6 +2217,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .grp_size   = 0x04,
         .size_init  = pt_reg_grp_size_init,
     },
+    /* MSI Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSI,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0xFF,
+        .size_init   = pt_msi_size_init,
+        .emu_reg_tbl = pt_emu_reg_msi_tbl,
+    },
     /* PCI-X Capabilities List Item reg group */
     {
         .grp_id     = PCI_CAP_ID_PCIX,
@@ -1793,6 +2269,14 @@ static const XenPTRegGroupInfo pt_emu_reg_grp_tbl[] = {
         .size_init   = pt_pcie_size_init,
         .emu_reg_tbl = pt_emu_reg_pcie_tbl,
     },
+    /* MSI-X Capability Structure reg group */
+    {
+        .grp_id      = PCI_CAP_ID_MSIX,
+        .grp_type    = GRP_TYPE_EMU,
+        .grp_size    = 0x0C,
+        .size_init   = pt_msix_size_init,
+        .emu_reg_tbl = pt_emu_reg_msix_tbl,
+    },
     {
         .grp_size = 0,
     },
@@ -1965,8 +2449,11 @@ static int pt_init_pci_config(XenPCIPassthroughState *s)
         return rc;
     }
 
+    /* setup MSI-INTx translation if support */
+    rc = pt_enable_msi_translate(s);
+
     /* rebind machine_irq to device */
-    if (s->machine_irq != 0) {
+    if (rc < 0 && s->machine_irq != 0) {
         uint8_t e_device = PCI_SLOT(s->dev.devfn);
         uint8_t e_intx = pci_intx(s);
 
@@ -2117,6 +2604,14 @@ void pt_config_delete(XenPCIPassthroughState *s)
     struct XenPTRegGroup *reg_group, *next_grp;
     struct XenPTReg *reg, *next_reg;
 
+    /* free MSI/MSI-X info table */
+    if (s->msix) {
+        pt_msix_delete(s);
+    }
+    if (s->msi) {
+        g_free(s->msi);
+    }
+
     /* free Power Management info table */
     if (s->pm_state) {
         if (s->pm_state->pm_timer) {
diff --git a/hw/xen_pci_passthrough_msi.c b/hw/xen_pci_passthrough_msi.c
new file mode 100644
index 0000000..73d3d9b
--- /dev/null
+++ b/hw/xen_pci_passthrough_msi.c
@@ -0,0 +1,678 @@
+/*
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Jiang Yunhong <yunhong.jiang@intel.com>
+ *
+ * This file implements direct PCI assignment to a HVM guest
+ */
+
+#include <sys/mman.h>
+
+#include "xen_backend.h"
+#include "xen_pci_passthrough.h"
+#include "apic-msidef.h"
+
+
+#define AUTO_ASSIGN -1
+
+/* shift count for gflags */
+#define GFLAGS_SHIFT_DEST_ID        0
+#define GFLAGS_SHIFT_RH             8
+#define GFLAGS_SHIFT_DM             9
+#define GLFAGS_SHIFT_DELIV_MODE     12
+#define GLFAGS_SHIFT_TRG_MODE       15
+
+
+/*
+ * Helpers
+ */
+
+static uint32_t get_msi_gflags(uint32_t data, uint64_t addr)
+{
+    uint32_t result = 0;
+    int rh, dm, dest_id, deliv_mode, trig_mode;
+
+    rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+    dm = (addr >> MSI_ADDR_DEST_MODE_SHIFT) & 0x1;
+    dest_id = (addr >> MSI_ADDR_DEST_ID_SHIFT) & 0xff;
+    deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+    trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+    result = dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
+             (deliv_mode << GLFAGS_SHIFT_DELIV_MODE) |
+             (trig_mode << GLFAGS_SHIFT_TRG_MODE);
+
+    return result;
+}
+
+
+/*
+ * MSI virtualization functions
+ */
+
+void pt_msi_set_enable(XenPCIPassthroughState *s, int en)
+{
+    uint16_t val = 0;
+    uint32_t address = 0;
+
+    PT_LOG(&s->dev, "enable: %i\n", en);
+
+    if (!s->msi) {
+        return;
+    }
+
+    address = s->msi->ctrl_offset;
+    if (!address) {
+        return;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    val &= ~PCI_MSI_FLAGS_ENABLE;
+    val |= en & PCI_MSI_FLAGS_ENABLE;
+    host_pci_set_word(s->real_device, address, val);
+}
+
+/* setup physical msi, but don't enable it */
+int pt_msi_setup(XenPCIPassthroughState *s)
+{
+    int pirq = PT_UNASSIGNED_PIRQ;
+    uint8_t gvec = 0;
+    int rc = 0;
+
+    if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
+        PT_ERR(&s->dev, "Setup physical MSI when it's already initialized.\n");
+        return -1;
+    }
+
+    gvec = s->msi->data & 0xFF;
+    if (!gvec) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        pirq = (s->msi->addr_hi & 0xffffff00) |
+               ((s->msi->addr_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
+        if (!pirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            pirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
+        }
+    }
+
+    rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
+                                 PCI_DEVFN(s->real_device->dev,
+                                           s->real_device->func),
+                                 s->real_device->bus, 0, 0);
+    if (rc) {
+        PT_ERR(&s->dev, "Mapping of MSI failed. (rc: %d,"
+               " assigned device: %02x:%02x.%x)\n", rc,
+               s->real_device->dev, s->real_device->func, s->real_device->bus);
+        return -1;
+    }
+
+    if (pirq < 0) {
+        PT_ERR(&s->dev, "Invalid pirq number.\n");
+        return -1;
+    }
+
+    s->msi->pirq = pirq;
+    PT_LOG(&s->dev, "MSI mapped with pirq %d.\n", pirq);
+
+    return 0;
+}
+
+int pt_msi_update(XenPCIPassthroughState *s)
+{
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    int rc = 0;
+
+    /* get vector, address, flags info, etc. */
+    gvec = s->msi->data & 0xFF;
+    addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
+    gflags = get_msi_gflags(s->msi->data, addr);
+
+    PT_LOG(&s->dev, "Update MSI with pirq %d gvec 0x%x gflags 0x%x\n",
+           s->msi->pirq, gvec, gflags);
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec,
+                                  s->msi->pirq, gflags, 0);
+    if (rc) {
+        PT_ERR(&s->dev, "Binding of MSI failed. (rc: %d)\n", rc);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI pirq %d failed.\n",
+                   s->msi->pirq);
+        }
+        s->msi->pirq = PT_UNASSIGNED_PIRQ;
+    }
+    return rc;
+}
+
+void pt_msi_disable(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    pt_msi_set_enable(s, 0);
+
+    e_device = PCI_SLOT(d->devfn);
+    e_intx = pci_intx(s);
+
+    if (s->msi_trans_en) {
+        if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                                    PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                                    e_device, e_intx, 0)) {
+            PT_ERR(d, "Unbinding pt irq for MSI-INTx failed!\n");
+            goto out;
+        }
+    } else if (!(s->msi->flags & PT_MSI_FLAG_UNINIT)) {
+        /* get vector, address, flags info, etc. */
+        gvec = s->msi->data & 0xFF;
+        addr = (uint64_t)s->msi->addr_hi << 32 | s->msi->addr_lo;
+        gflags = get_msi_gflags(s->msi->data, addr);
+
+        PT_ERR(&s->dev, "Unbind MSI with pirq %x, gvec %x\n",
+               s->msi->pirq, gvec);
+
+        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
+                                     s->msi->pirq, gflags)) {
+            PT_ERR(&s->dev, "Unbinding of MSI failed. (pirq: %d)\n",
+                   s->msi->pirq);
+            goto out;
+        }
+    }
+
+    if (s->msi->pirq != PT_UNASSIGNED_PIRQ) {
+        PT_LOG(&s->dev, "Unmap msi with pirq %d\n", s->msi->pirq);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI failed. (pirq: %d)\n",
+                   s->msi->pirq);
+            goto out;
+        }
+    }
+
+out:
+    /* clear msi info */
+    s->msi->flags = 0;
+    s->msi->pirq = -1;
+    s->msi_trans_en = 0;
+}
+
+/*
+ * MSI-INTx translation virtualization functions
+ */
+
+int pt_enable_msi_translate(XenPCIPassthroughState *s)
+{
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    if (!(s->msi && s->msi_trans_cap)) {
+        return -1;
+    }
+
+    pt_msi_set_enable(s, 0);
+    s->msi_trans_en = 0;
+
+    if (pt_msi_setup(s)) {
+        PT_ERR(&s->dev, "MSI-INTx translation MSI setup failed, fallback\n");
+        return -1;
+    }
+
+    e_device = PCI_SLOT(s->dev.devfn);
+    /* fix virtual interrupt pin to INTA# */
+    e_intx = pci_intx(s);
+
+    if (xc_domain_bind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                              PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                              e_device, e_intx, 0)) {
+        PT_ERR(&s->dev, "MSI-INTx translation bind failed, fallback\n");
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, s->msi->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI failed.\n");
+        }
+        s->msi->pirq = PT_UNASSIGNED_PIRQ;
+        return -1;
+    }
+
+    pt_msi_set_enable(s, 1);
+    s->msi_trans_en = 1;
+
+    return 0;
+}
+
+void pt_disable_msi_translate(XenPCIPassthroughState *s)
+{
+    uint8_t e_device = 0;
+    uint8_t e_intx = 0;
+
+    /* MSI_ENABLE bit should be disabed until the new handler is set */
+    pt_msi_set_enable(s, 0);
+
+    e_device = PCI_SLOT(s->dev.devfn);
+    e_intx = pci_intx(s);
+
+    if (xc_domain_unbind_pt_irq(xen_xc, xen_domid, s->msi->pirq,
+                                PT_IRQ_TYPE_MSI_TRANSLATE, 0,
+                                e_device, e_intx, 0)) {
+        PT_ERR(&s->dev, "Unbinding pt irq for MSI-INTx failed!\n");
+    }
+
+    if (s->machine_irq) {
+        if (xc_domain_bind_pt_pci_irq(xen_xc, xen_domid, s->machine_irq,
+                                      0, e_device, e_intx)) {
+            PT_ERR(&s->dev, "Rebinding of interrupt failed!\n");
+        }
+    }
+
+    s->msi_trans_en = 0;
+}
+
+/*
+ * MSI-X virtualization functions
+ */
+
+static void msix_set_enable(XenPCIPassthroughState *s, int en)
+{
+    uint16_t val = 0;
+    uint32_t address = 0;
+
+    if (!s->msix) {
+        return;
+    }
+
+    address = s->msix->ctrl_offset;
+    if (!address) {
+        return;
+    }
+
+    host_pci_get_word(s->real_device, address, &val);
+    val &= ~PCI_MSIX_FLAGS_ENABLE;
+    if (en) {
+        val |= PCI_MSIX_FLAGS_ENABLE;
+    }
+    host_pci_set_word(s->real_device, address, val);
+}
+
+static void mask_physical_msix_entry(XenPCIPassthroughState *s,
+                                     int entry_nr, int mask)
+{
+    void *phys_off;
+
+    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;
+    *(uint32_t *)phys_off = mask;
+}
+
+static int pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+{
+    XenMSIXEntry *entry = &s->msix->msix_entry[entry_nr];
+    int pirq = entry->pirq;
+    int gvec = entry->io_mem[2] & 0xff;
+    uint64_t gaddr = *(uint64_t *)&entry->io_mem[0];
+    uint32_t gflags = get_msi_gflags(entry->io_mem[2], gaddr);
+    int rc;
+
+    if (!entry->flags) {
+        return 0;
+    }
+
+    if (!gvec) {
+        /* if gvec is 0, the guest is asking for a particular pirq that
+         * is passed as dest_id */
+        pirq = ((gaddr >> 32) & 0xffffff00) |
+               (((gaddr & 0xffffffff) >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
+        if (!pirq) {
+            /* this probably identifies an misconfiguration of the guest,
+             * try the emulated path */
+            pirq = PT_UNASSIGNED_PIRQ;
+        } else {
+            PT_LOG(&s->dev, "requested pirq: %d\n", pirq);
+        }
+    }
+
+    /* Check if this entry is already mapped */
+    if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+        rc = xc_physdev_map_pirq_msi(xen_xc, xen_domid, AUTO_ASSIGN, &pirq,
+                                     PCI_DEVFN(s->real_device->dev,
+                                               s->real_device->func),
+                                     s->real_device->bus, entry_nr,
+                                     s->msix->table_base);
+        if (rc) {
+            PT_ERR(&s->dev, "Mapping msix entry %x\n", entry_nr);
+            return rc;
+        }
+        entry->pirq = pirq;
+    }
+
+    PT_LOG(&s->dev, "Update msix entry 0x%x with pirq %d gvec 0x%x\n",
+            entry_nr, pirq, gvec);
+
+    rc = xc_domain_update_msi_irq(xen_xc, xen_domid, gvec, pirq, gflags,
+                                  s->msix->mmio_base_addr);
+    if (rc) {
+        PT_ERR(&s->dev, "Updating msix irq %d info for entry %d\n",
+               pirq, entry_nr);
+
+        if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
+            PT_ERR(&s->dev, "Unmapping of MSI-X failed. (pirq: %d)\n",
+                   entry->pirq);
+        }
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        return rc;
+    }
+
+    entry->flags = 0;
+
+    return 0;
+}
+
+int pt_msix_update(XenPCIPassthroughState *s)
+{
+    XenPTMSIX *msix = s->msix;
+    int i;
+
+    for (i = 0; i < msix->total_entries; i++) {
+        pt_msix_update_one(s, i);
+    }
+
+    return 0;
+}
+
+void pt_msix_disable(XenPCIPassthroughState *s)
+{
+    PCIDevice *d = &s->dev;
+    uint8_t gvec = 0;
+    uint32_t gflags = 0;
+    uint64_t addr = 0;
+    int i = 0;
+    XenMSIXEntry *entry = NULL;
+
+    msix_set_enable(s, 0);
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+
+        if (entry->pirq == PT_UNASSIGNED_PIRQ) {
+            continue;
+        }
+
+        gvec = entry->io_mem[2] & 0xff;
+        addr = *(uint64_t *)&entry->io_mem[0];
+        gflags = get_msi_gflags(entry->io_mem[2], addr);
+
+        PT_LOG(d, "Unbind msix with pirq %d, gvec 0x%x\n",
+                entry->pirq, gvec);
+
+        if (xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec,
+                                        entry->pirq, gflags)) {
+            PT_ERR(d, "Unbinding of MSI-X failed.\n");
+        } else {
+            PT_LOG(d, "Unmap msix with pirq %d\n", entry->pirq);
+
+            if (xc_physdev_unmap_pirq(xen_xc, xen_domid, entry->pirq)) {
+                PT_ERR(d, "Unmapping of MSI-X failed.\n");
+            }
+        }
+        /* clear msi-x info */
+        entry->pirq = PT_UNASSIGNED_PIRQ;
+        entry->flags = 0;
+    }
+}
+
+int pt_msix_update_remap(XenPCIPassthroughState *s, int bar_index)
+{
+    XenMSIXEntry *entry;
+    int i, ret;
+
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    for (i = 0; i < s->msix->total_entries; i++) {
+        entry = &s->msix->msix_entry[i];
+        if (entry->pirq != PT_UNASSIGNED_PIRQ) {
+            ret = xc_domain_unbind_pt_irq(xen_xc, xen_domid, entry->pirq,
+                                          PT_IRQ_TYPE_MSI, 0, 0, 0, 0);
+            if (ret) {
+                PT_ERR(&s->dev, "unbind MSI-X entry %d failed\n", entry->pirq);
+            }
+            entry->flags = 1;
+        }
+    }
+    pt_msix_update(s);
+
+    return 0;
+}
+
+static void pci_msix_invalid_write(void *opaque, target_phys_addr_t addr,
+                                   uint32_t val)
+{
+    XenPCIPassthroughState *s = opaque;
+    PT_ERR(&s->dev, "Invalid write to MSI-X table,"
+           " only dword access is allowed.\n");
+}
+
+static void pci_msix_writel(void *opaque, target_phys_addr_t addr,
+                            uint32_t val)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    XenMSIXEntry *entry;
+    int entry_nr, offset;
+    void *phys_off;
+    uint32_t vec_ctrl;
+
+    if (addr % 4) {
+        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
+                "addr 0x"TARGET_FMT_plx"\n", addr);
+        return;
+    }
+
+    entry_nr = addr / 16;
+    entry = &msix->msix_entry[entry_nr];
+    offset = (addr % 16) / 4;
+
+    /*
+     * If Xen intercepts the mask bit access, io_mem[3] may not be
+     * up-to-date. Read from hardware directly.
+     */
+    phys_off = s->msix->phys_iomem_base + 16 * entry_nr + 12;
+    vec_ctrl = *(uint32_t *)phys_off;
+
+    if (offset != 3 && msix->enabled && !(vec_ctrl & 0x1)) {
+        PT_ERR(&s->dev, "Can't update msix entry %d since MSI-X is already "
+                "enabled.\n", entry_nr);
+        return;
+    }
+
+    if (offset != 3 && entry->io_mem[offset] != val) {
+        entry->flags = 1;
+    }
+    entry->io_mem[offset] = val;
+
+    if (offset == 3) {
+        if (msix->enabled && !(val & 0x1)) {
+            pt_msix_update_one(s, entry_nr);
+        }
+        mask_physical_msix_entry(s, entry_nr, entry->io_mem[3] & 0x1);
+    }
+}
+
+static CPUWriteMemoryFunc *pci_msix_write[] = {
+    pci_msix_invalid_write,
+    pci_msix_invalid_write,
+    pci_msix_writel
+};
+
+static uint32_t pci_msix_invalid_read(void *opaque, target_phys_addr_t addr)
+{
+    XenPCIPassthroughState *s = opaque;
+    PT_ERR(&s->dev, "Invalid read to MSI-X table,"
+           " only dword access is allowed.\n");
+    return 0;
+}
+
+static uint32_t pci_msix_readl(void *opaque, target_phys_addr_t addr)
+{
+    XenPCIPassthroughState *s = opaque;
+    XenPTMSIX *msix = s->msix;
+    int entry_nr, offset;
+
+    if (addr % 4) {
+        PT_ERR(&s->dev, "Unaligned dword access to MSI-X table, "
+                "addr 0x"TARGET_FMT_plx"\n", addr);
+        return 0;
+    }
+
+    entry_nr = addr / 16;
+    offset = (addr % 16) / 4;
+
+    return msix->msix_entry[entry_nr].io_mem[offset];
+}
+
+static CPUReadMemoryFunc *pci_msix_read[] = {
+    pci_msix_invalid_read,
+    pci_msix_invalid_read,
+    pci_msix_readl
+};
+
+int pt_add_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+         DPCI_ADD_MAPPING);
+}
+
+int pt_remove_msix_mapping(XenPCIPassthroughState *s, int bar_index)
+{
+    if (!(s->msix && s->msix->bar_index == bar_index)) {
+        return 0;
+    }
+
+    s->msix->mmio_base_addr = s->bases[bar_index].e_physbase
+        + s->msix->table_off;
+
+    cpu_register_physical_memory(s->msix->mmio_base_addr,
+                                 s->msix->total_entries * 16,
+                                 s->msix->mmio_index);
+
+    return xc_domain_memory_mapping(xen_xc, xen_domid,
+         s->msix->mmio_base_addr >> XC_PAGE_SHIFT,
+         (s->bases[bar_index].access.maddr + s->msix->table_off)
+             >> XC_PAGE_SHIFT,
+         (s->msix->total_entries * 16 + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT,
+         DPCI_REMOVE_MAPPING);
+}
+
+int pt_msix_init(XenPCIPassthroughState *s, int base)
+{
+    uint8_t id = 0;
+    uint16_t control = 0;
+    uint32_t table_off = 0;
+    int i, total_entries, bar_index;
+    HostPCIDevice *d = s->real_device;
+    int fd;
+
+    if (host_pci_get_byte(d, base + PCI_CAP_LIST_ID, &id)) {
+        return -1;
+    }
+
+    if (id != PCI_CAP_ID_MSIX) {
+        PT_ERR(&s->dev, "Invalid id %#x base %#x\n", id, base);
+        return -1;
+    }
+
+    host_pci_get_word(d, base + 2, &control);
+    total_entries = control & 0x7ff;
+    total_entries += 1;
+
+    s->msix = g_malloc0(sizeof (XenPTMSIX)
+                        + total_entries * sizeof (XenMSIXEntry));
+
+    s->msix->total_entries = total_entries;
+    for (i = 0; i < total_entries; i++) {
+        s->msix->msix_entry[i].pirq = PT_UNASSIGNED_PIRQ;
+    }
+
+    s->msix->mmio_index =
+        cpu_register_io_memory(pci_msix_read, pci_msix_write,
+                               s, DEVICE_NATIVE_ENDIAN);
+
+    host_pci_get_long(d, base + PCI_MSIX_TABLE, &table_off);
+    bar_index = s->msix->bar_index = table_off & PCI_MSIX_FLAGS_BIRMASK;
+    table_off = s->msix->table_off = table_off & ~PCI_MSIX_FLAGS_BIRMASK;
+    s->msix->table_base = s->real_device->io_regions[bar_index].base_addr;
+    PT_LOG(&s->dev, "get MSI-X table BAR base 0x%"PRIx64"\n",
+           s->msix->table_base);
+
+    fd = open("/dev/mem", O_RDWR);
+    if (fd == -1) {
+        PT_ERR(&s->dev, "Can't open /dev/mem: %s\n", strerror(errno));
+        goto error_out;
+    }
+    PT_LOG(&s->dev, "table_off = %#x, total_entries = %d\n",
+           table_off, total_entries);
+    s->msix->table_offset_adjust = table_off & 0x0fff;
+    s->msix->phys_iomem_base =
+        mmap(0,
+             total_entries * 16 + s->msix->table_offset_adjust,
+             PROT_WRITE | PROT_READ,
+             MAP_SHARED | MAP_LOCKED,
+             fd,
+             s->msix->table_base + table_off - s->msix->table_offset_adjust);
+
+    if (s->msix->phys_iomem_base == MAP_FAILED) {
+        PT_ERR(&s->dev, "Can't map physical MSI-X table: %s\n",
+               strerror(errno));
+        close(fd);
+        goto error_out;
+    }
+    s->msix->phys_iomem_base = (char *)s->msix->phys_iomem_base
+        + s->msix->table_offset_adjust;
+
+    close(fd);
+
+    PT_LOG(&s->dev, "mapping physical MSI-X table to %p\n",
+           s->msix->phys_iomem_base);
+    return 0;
+
+error_out:
+    g_free(s->msix);
+    s->msix = NULL;
+    return -1;
+}
+
+void pt_msix_delete(XenPCIPassthroughState *s)
+{
+    /* unmap the MSI-X memory mapped register area */
+    if (s->msix->phys_iomem_base) {
+        PT_LOG(&s->dev, "unmapping physical MSI-X table from %p\n",
+           s->msix->phys_iomem_base);
+        munmap(s->msix->phys_iomem_base, s->msix->total_entries * 16 +
+           s->msix->table_offset_adjust);
+    }
+
+    if (s->msix->mmio_index > 0) {
+        cpu_unregister_io_memory(s->msix->mmio_index);
+    }
+
+    g_free(s->msix);
+    s->msix = NULL;
+}
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:49:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:49:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdQD-0004aV-PF; Thu, 24 Nov 2011 17:49:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdQB-0004Wl-Px
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:49:16 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18328 invoked from network); 24 Nov 2011 17:45:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:45:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809601"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:01 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ6027444;	Thu, 24 Nov 2011 09:45:00 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:34 +0000
Message-ID: <1322156679-9441-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 05/10] Introduce HostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target      |    3 +
 hw/host-pci-device.c |  278 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/host-pci-device.h |   75 ++++++++++++++
 3 files changed, 356 insertions(+), 0 deletions(-)
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index a111521..e527c1b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -219,6 +219,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 0000000..b1e2db3
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "host-pci-device.h"
+
+#define PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+enum error_code {
+    ERROR_SYNTAX = 1,
+};
+
+static int path_to(const HostPCIDevice *d,
+                   const char *name, char *buf, ssize_t size)
+{
+    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
+                    d->domain, d->bus, d->dev, d->func, name);
+}
+
+static int get_resource(HostPCIDevice *d)
+{
+    int i, rc = 0;
+    FILE *f;
+    char path[PATH_MAX];
+    unsigned long long start, end, flags, size;
+
+    path_to(d, "resource", path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
+            fprintf(stderr, "Error: Syntax error in %s\n", path);
+            rc = ERROR_SYNTAX;
+            break;
+        }
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].flags = flags;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.flags = flags;
+        }
+    }
+
+    fclose(f);
+    return rc;
+}
+
+static int get_hex_value(HostPCIDevice *d, const char *name,
+                         unsigned long *pvalue)
+{
+    char path[PATH_MAX];
+    FILE *f;
+    unsigned long value;
+
+    path_to(d, name, path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    if (fscanf(f, "%lx\n", &value) != 1) {
+        fprintf(stderr, "Error: Syntax error in %s\n", path);
+        fclose(f);
+        return ERROR_SYNTAX;
+    }
+    fclose(f);
+    *pvalue = value;
+    return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    path_to(d, "physfn", path, sizeof (path));
+    return !stat(path, &buf);
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+
+    if (d->config_fd < 0) {
+        path_to(d, "config", path, sizeof (path));
+        d->config_fd = open(path, O_RDWR);
+        if (d->config_fd < 0) {
+            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
+                    path, strerror(errno));
+        }
+    }
+    return d->config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pread(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: read failed: %s (fd: %i)\n",
+                __func__, strerror(errno), fd);
+        return -errno;
+    }
+    return 0;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+                                 int pos, const void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pwrite(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: write failed: %s\n",
+                __func__, strerror(errno));
+        return -errno;
+    }
+    return 0;
+}
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
+{
+  uint8_t buf;
+  int rc = host_pci_config_read(d, pos, &buf, 1);
+  if (rc == 0) {
+      *p = buf;
+  }
+  return rc;
+}
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p)
+{
+  uint16_t buf;
+  int rc = host_pci_config_read(d, pos, &buf, 2);
+  if (rc == 0) {
+      *p = le16_to_cpu(buf);
+  }
+  return rc;
+}
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p)
+{
+  uint32_t buf;
+  int rc = host_pci_config_read(d, pos, &buf, 4);
+  if (rc == 0) {
+      *p = le32_to_cpu(buf);
+  }
+  return rc;
+}
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+  return host_pci_config_read(d, pos, buf, len);
+}
+
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
+{
+  return host_pci_config_write(d, pos, &data, 1);
+}
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
+{
+  data = cpu_to_le16(data);
+  return host_pci_config_write(d, pos, &data, 2);
+}
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
+{
+  data = cpu_to_le32(data);
+  return host_pci_config_write(d, pos, &data, 4);
+}
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+  return host_pci_config_write(d, pos, buf, len);
+}
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return 0;
+}
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
+{
+    HostPCIDevice *d = NULL;
+    unsigned long v = 0;
+
+    d = g_new0(HostPCIDevice, 1);
+
+    d->config_fd = -1;
+    d->domain = 0;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    if (host_pci_config_fd(d) == -1) {
+        goto error;
+    }
+    if (get_resource(d) != 0) {
+        goto error;
+    }
+
+    if (get_hex_value(d, "vendor", &v)) {
+        goto error;
+    }
+    d->vendor_id = v;
+    if (get_hex_value(d, "device", &v)) {
+        goto error;
+    }
+    d->device_id = v;
+    d->is_virtfn = pci_dev_is_virtfn(d);
+
+    return d;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+    return NULL;
+}
+
+void host_pci_device_put(HostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+}
diff --git a/hw/host-pci-device.h b/hw/host-pci-device.h
new file mode 100644
index 0000000..c8880eb
--- /dev/null
+++ b/hw/host-pci-device.h
@@ -0,0 +1,75 @@
+#ifndef HW_HOST_PCI_DEVICE
+#  define HW_HOST_PCI_DEVICE
+
+#include "pci.h"
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+#define IORESOURCE_IRQ          0x00000400
+#define IORESOURCE_DMA          0x00000800
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_READONLY     0x00002000
+#define IORESOURCE_CACHEABLE    0x00004000
+#define IORESOURCE_RANGELENGTH  0x00008000
+#define IORESOURCE_SHADOWABLE   0x00010000
+
+#define IORESOURCE_SIZEALIGN    0x00020000      /* size indicates alignment */
+#define IORESOURCE_STARTALIGN   0x00040000      /* start field is alignment */
+
+#define IORESOURCE_MEM_64       0x00100000
+
+    /* Userland may not map this resource */
+#define IORESOURCE_EXCLUSIVE    0x08000000
+#define IORESOURCE_DISABLED     0x10000000
+#define IORESOURCE_UNSET        0x20000000
+#define IORESOURCE_AUTO         0x40000000
+    /* Driver has marked this resource busy */
+#define IORESOURCE_BUSY         0x80000000
+
+
+typedef struct HostPCIIORegion {
+    unsigned long flags;
+    pcibus_t base_addr;
+    pcibus_t size;
+} HostPCIIORegion;
+
+typedef struct HostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+
+    HostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    HostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} HostPCIDevice;
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func);
+void host_pci_device_put(HostPCIDevice *pci_dev);
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p);
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p);
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p);
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data);
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data);
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data);
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *s, uint32_t cap);
+
+#endif /* !HW_HOST_PCI_DEVICE */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:49:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:49:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdQD-0004aV-PF; Thu, 24 Nov 2011 17:49:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTdQB-0004Wl-Px
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:49:16 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322156697!5537019!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18328 invoked from network); 24 Nov 2011 17:45:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:45:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315195200"; d="scan'208";a="171809601"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 12:45:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 12:45:01 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAOHiqJ6027444;	Thu, 24 Nov 2011 09:45:00 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 24 Nov 2011 17:44:34 +0000
Message-ID: <1322156679-9441-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH V5 05/10] Introduce HostPCIDevice to access a
	pci device on the host.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 Makefile.target      |    3 +
 hw/host-pci-device.c |  278 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/host-pci-device.h |   75 ++++++++++++++
 3 files changed, 356 insertions(+), 0 deletions(-)
 create mode 100644 hw/host-pci-device.c
 create mode 100644 hw/host-pci-device.h

diff --git a/Makefile.target b/Makefile.target
index a111521..e527c1b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -219,6 +219,9 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
 
 obj-i386-$(CONFIG_XEN) += xen_platform.o
 
+# Xen PCI Passthrough
+obj-i386-$(CONFIG_XEN_PCI_PASSTHROUGH) += host-pci-device.o
+
 # Inter-VM PCI shared memory
 CONFIG_IVSHMEM =
 ifeq ($(CONFIG_KVM), y)
diff --git a/hw/host-pci-device.c b/hw/host-pci-device.c
new file mode 100644
index 0000000..b1e2db3
--- /dev/null
+++ b/hw/host-pci-device.c
@@ -0,0 +1,278 @@
+/*
+ * Copyright (C) 2011       Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "qemu-common.h"
+#include "host-pci-device.h"
+
+#define PCI_MAX_EXT_CAP \
+    ((PCIE_CONFIG_SPACE_SIZE - PCI_CONFIG_SPACE_SIZE) / (PCI_CAP_SIZEOF + 4))
+
+enum error_code {
+    ERROR_SYNTAX = 1,
+};
+
+static int path_to(const HostPCIDevice *d,
+                   const char *name, char *buf, ssize_t size)
+{
+    return snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%x/%s",
+                    d->domain, d->bus, d->dev, d->func, name);
+}
+
+static int get_resource(HostPCIDevice *d)
+{
+    int i, rc = 0;
+    FILE *f;
+    char path[PATH_MAX];
+    unsigned long long start, end, flags, size;
+
+    path_to(d, "resource", path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+
+    for (i = 0; i < PCI_NUM_REGIONS; i++) {
+        if (fscanf(f, "%llx %llx %llx", &start, &end, &flags) != 3) {
+            fprintf(stderr, "Error: Syntax error in %s\n", path);
+            rc = ERROR_SYNTAX;
+            break;
+        }
+        if (start) {
+            size = end - start + 1;
+        } else {
+            size = 0;
+        }
+
+        if (i < PCI_ROM_SLOT) {
+            d->io_regions[i].base_addr = start;
+            d->io_regions[i].size = size;
+            d->io_regions[i].flags = flags;
+        } else {
+            d->rom.base_addr = start;
+            d->rom.size = size;
+            d->rom.flags = flags;
+        }
+    }
+
+    fclose(f);
+    return rc;
+}
+
+static int get_hex_value(HostPCIDevice *d, const char *name,
+                         unsigned long *pvalue)
+{
+    char path[PATH_MAX];
+    FILE *f;
+    unsigned long value;
+
+    path_to(d, name, path, sizeof (path));
+    f = fopen(path, "r");
+    if (!f) {
+        fprintf(stderr, "Error: Can't open %s: %s\n", path, strerror(errno));
+        return -errno;
+    }
+    if (fscanf(f, "%lx\n", &value) != 1) {
+        fprintf(stderr, "Error: Syntax error in %s\n", path);
+        fclose(f);
+        return ERROR_SYNTAX;
+    }
+    fclose(f);
+    *pvalue = value;
+    return 0;
+}
+
+static bool pci_dev_is_virtfn(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+    struct stat buf;
+
+    path_to(d, "physfn", path, sizeof (path));
+    return !stat(path, &buf);
+}
+
+static int host_pci_config_fd(HostPCIDevice *d)
+{
+    char path[PATH_MAX];
+
+    if (d->config_fd < 0) {
+        path_to(d, "config", path, sizeof (path));
+        d->config_fd = open(path, O_RDWR);
+        if (d->config_fd < 0) {
+            fprintf(stderr, "HostPCIDevice: Can not open '%s': %s\n",
+                    path, strerror(errno));
+        }
+    }
+    return d->config_fd;
+}
+static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pread(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: read failed: %s (fd: %i)\n",
+                __func__, strerror(errno), fd);
+        return -errno;
+    }
+    return 0;
+}
+static int host_pci_config_write(HostPCIDevice *d,
+                                 int pos, const void *buf, int len)
+{
+    int fd = host_pci_config_fd(d);
+    int res = 0;
+
+again:
+    res = pwrite(fd, buf, len, pos);
+    if (res != len) {
+        if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
+            goto again;
+        }
+        fprintf(stderr, "%s: write failed: %s\n",
+                __func__, strerror(errno));
+        return -errno;
+    }
+    return 0;
+}
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
+{
+  uint8_t buf;
+  int rc = host_pci_config_read(d, pos, &buf, 1);
+  if (rc == 0) {
+      *p = buf;
+  }
+  return rc;
+}
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p)
+{
+  uint16_t buf;
+  int rc = host_pci_config_read(d, pos, &buf, 2);
+  if (rc == 0) {
+      *p = le16_to_cpu(buf);
+  }
+  return rc;
+}
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p)
+{
+  uint32_t buf;
+  int rc = host_pci_config_read(d, pos, &buf, 4);
+  if (rc == 0) {
+      *p = le32_to_cpu(buf);
+  }
+  return rc;
+}
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+  return host_pci_config_read(d, pos, buf, len);
+}
+
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data)
+{
+  return host_pci_config_write(d, pos, &data, 1);
+}
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data)
+{
+  data = cpu_to_le16(data);
+  return host_pci_config_write(d, pos, &data, 2);
+}
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data)
+{
+  data = cpu_to_le32(data);
+  return host_pci_config_write(d, pos, &data, 4);
+}
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len)
+{
+  return host_pci_config_write(d, pos, buf, len);
+}
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *d, uint32_t cap)
+{
+    uint32_t header = 0;
+    int max_cap = PCI_MAX_EXT_CAP;
+    int pos = PCI_CONFIG_SPACE_SIZE;
+
+    do {
+        if (host_pci_get_long(d, pos, &header)) {
+            break;
+        }
+        /*
+         * If we have no capabilities, this is indicated by cap ID,
+         * cap version and next pointer all being 0.
+         */
+        if (header == 0) {
+            break;
+        }
+
+        if (PCI_EXT_CAP_ID(header) == cap) {
+            return pos;
+        }
+
+        pos = PCI_EXT_CAP_NEXT(header);
+        if (pos < PCI_CONFIG_SPACE_SIZE) {
+            break;
+        }
+
+        max_cap--;
+    } while (max_cap > 0);
+
+    return 0;
+}
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func)
+{
+    HostPCIDevice *d = NULL;
+    unsigned long v = 0;
+
+    d = g_new0(HostPCIDevice, 1);
+
+    d->config_fd = -1;
+    d->domain = 0;
+    d->bus = bus;
+    d->dev = dev;
+    d->func = func;
+
+    if (host_pci_config_fd(d) == -1) {
+        goto error;
+    }
+    if (get_resource(d) != 0) {
+        goto error;
+    }
+
+    if (get_hex_value(d, "vendor", &v)) {
+        goto error;
+    }
+    d->vendor_id = v;
+    if (get_hex_value(d, "device", &v)) {
+        goto error;
+    }
+    d->device_id = v;
+    d->is_virtfn = pci_dev_is_virtfn(d);
+
+    return d;
+error:
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+    return NULL;
+}
+
+void host_pci_device_put(HostPCIDevice *d)
+{
+    if (d->config_fd >= 0) {
+        close(d->config_fd);
+    }
+    g_free(d);
+}
diff --git a/hw/host-pci-device.h b/hw/host-pci-device.h
new file mode 100644
index 0000000..c8880eb
--- /dev/null
+++ b/hw/host-pci-device.h
@@ -0,0 +1,75 @@
+#ifndef HW_HOST_PCI_DEVICE
+#  define HW_HOST_PCI_DEVICE
+
+#include "pci.h"
+
+/*
+ * from linux/ioport.h
+ * IO resources have these defined flags.
+ */
+#define IORESOURCE_BITS         0x000000ff      /* Bus-specific bits */
+
+#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
+#define IORESOURCE_IO           0x00000100
+#define IORESOURCE_MEM          0x00000200
+#define IORESOURCE_IRQ          0x00000400
+#define IORESOURCE_DMA          0x00000800
+
+#define IORESOURCE_PREFETCH     0x00001000      /* No side effects */
+#define IORESOURCE_READONLY     0x00002000
+#define IORESOURCE_CACHEABLE    0x00004000
+#define IORESOURCE_RANGELENGTH  0x00008000
+#define IORESOURCE_SHADOWABLE   0x00010000
+
+#define IORESOURCE_SIZEALIGN    0x00020000      /* size indicates alignment */
+#define IORESOURCE_STARTALIGN   0x00040000      /* start field is alignment */
+
+#define IORESOURCE_MEM_64       0x00100000
+
+    /* Userland may not map this resource */
+#define IORESOURCE_EXCLUSIVE    0x08000000
+#define IORESOURCE_DISABLED     0x10000000
+#define IORESOURCE_UNSET        0x20000000
+#define IORESOURCE_AUTO         0x40000000
+    /* Driver has marked this resource busy */
+#define IORESOURCE_BUSY         0x80000000
+
+
+typedef struct HostPCIIORegion {
+    unsigned long flags;
+    pcibus_t base_addr;
+    pcibus_t size;
+} HostPCIIORegion;
+
+typedef struct HostPCIDevice {
+    uint16_t domain;
+    uint8_t bus;
+    uint8_t dev;
+    uint8_t func;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+
+    HostPCIIORegion io_regions[PCI_NUM_REGIONS - 1];
+    HostPCIIORegion rom;
+
+    bool is_virtfn;
+
+    int config_fd;
+} HostPCIDevice;
+
+HostPCIDevice *host_pci_device_get(uint8_t bus, uint8_t dev, uint8_t func);
+void host_pci_device_put(HostPCIDevice *pci_dev);
+
+int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p);
+int host_pci_get_word(HostPCIDevice *d, int pos, uint16_t *p);
+int host_pci_get_long(HostPCIDevice *d, int pos, uint32_t *p);
+int host_pci_get_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+int host_pci_set_byte(HostPCIDevice *d, int pos, uint8_t data);
+int host_pci_set_word(HostPCIDevice *d, int pos, uint16_t data);
+int host_pci_set_long(HostPCIDevice *d, int pos, uint32_t data);
+int host_pci_set_block(HostPCIDevice *d, int pos, uint8_t *buf, int len);
+
+uint32_t host_pci_find_ext_cap_offset(HostPCIDevice *s, uint32_t cap);
+
+#endif /* !HW_HOST_PCI_DEVICE */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:57:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:57:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdYM-0005bU-VC; Thu, 24 Nov 2011 17:57:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTdYL-0005bM-9I
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:57:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322157429!2892174!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8296 invoked from network); 24 Nov 2011 17:57:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:57:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:57:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:57:09 +0000
Date: Thu, 24 Nov 2011 17:57:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1322150893-887-3-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1111241757060.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-3-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen mapcache: Check if a memory space
	has moved.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 24 Nov 2011, Anthony PERARD wrote:
> diff --git a/xen-mapcache.c b/xen-mapcache.c
> index 7bcb86e..73927ab 100644
> --- a/xen-mapcache.c
> +++ b/xen-mapcache.c
> @@ -191,10 +191,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
>                         uint8_t lock)
>  {
>      MapCacheEntry *entry, *pentry = NULL;
> -    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> -    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
> +    target_phys_addr_t address_index;
> +    target_phys_addr_t address_offset;
>      target_phys_addr_t __size = size;
>  
> +    phys_addr = xen_addr_actually_is(phys_addr, size);
> +    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> +    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
> +
>      trace_xen_map_cache(phys_addr);
>  
>      if (address_index == mapcache->last_address_index && !lock && !__size) {

it is probably a good idea to call xen_addr_actually_is only in case
the normal mapping failed, for performance reasons

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:57:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:57:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdYM-0005bU-VC; Thu, 24 Nov 2011 17:57:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTdYL-0005bM-9I
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:57:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322157429!2892174!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8296 invoked from network); 24 Nov 2011 17:57:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 17:57:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 17:57:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 17:57:09 +0000
Date: Thu, 24 Nov 2011 17:57:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1322150893-887-3-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1111241757060.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-3-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen mapcache: Check if a memory space
	has moved.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 24 Nov 2011, Anthony PERARD wrote:
> diff --git a/xen-mapcache.c b/xen-mapcache.c
> index 7bcb86e..73927ab 100644
> --- a/xen-mapcache.c
> +++ b/xen-mapcache.c
> @@ -191,10 +191,14 @@ uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
>                         uint8_t lock)
>  {
>      MapCacheEntry *entry, *pentry = NULL;
> -    target_phys_addr_t address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> -    target_phys_addr_t address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
> +    target_phys_addr_t address_index;
> +    target_phys_addr_t address_offset;
>      target_phys_addr_t __size = size;
>  
> +    phys_addr = xen_addr_actually_is(phys_addr, size);
> +    address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> +    address_offset = phys_addr & (MCACHE_BUCKET_SIZE - 1);
> +
>      trace_xen_map_cache(phys_addr);
>  
>      if (address_index == mapcache->last_address_index && !lock && !__size) {

it is probably a good idea to call xen_addr_actually_is only in case
the normal mapping failed, for performance reasons

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:59:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:59:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdZT-0005f2-I5; Thu, 24 Nov 2011 17:58:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTdZS-0005ei-Ge
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:58:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322157498!5647579!1
X-Originating-IP: [208.97.132.66]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22564 invoked from network); 24 Nov 2011 17:58:18 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-4.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 17:58:18 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 3B0914B0086;
	Thu, 24 Nov 2011 09:58:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=MDPoThxTsLRKsSN4b81865
	tcrgZlg5zHMUkp5+9zbjZ094lle3gGXfxuurWsVR+9yeFIMkszs4xbltgkMYDq6d
	OGSUBEHgryY/fJ9EICc2AeHN5OaqpbPqVsuf8mhGTzvXqalNAykD/oKlotIajGyZ
	R8y6BhAi338QCw6K7CJ18=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=ZaByyZahYbXX
	KLZZIUweUpwiS3k=; b=OMCVhbJlLj8Je7oQMp5ok5WbVHUcvZDs2b1wVGfJCvyB
	udNSRVTBG3X7XwJLS9bCi9qhdDyhQhV5YmK32TWE4KWDq3NFOryx5nUtCum/3ccm
	fwTIdvyobfRF/qVWBK1nrnOZTxGaRjMSMPAxAYVCckjS+zcfE6wzArvmCWib7is=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id 8A0FB4B0084; 
	Thu, 24 Nov 2011 09:58:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a264fb979b0c5391ce91c4adae27979af4aaea4e
Message-Id: <a264fb979b0c5391ce91.1322157496@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 12:58:16 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Don't trigger unnecessary shadow scans on p2m
	entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/shadow/common.c  |  6 ++----
 xen/arch/x86/mm/shadow/multi.c   |  2 +-
 xen/arch/x86/mm/shadow/private.h |  6 ++++++
 3 files changed, 9 insertions(+), 5 deletions(-)


When updating a p2m entry, the hypervisor scans all shadow pte's to find
mappings of that gfn and tear them down. This is avoided if the page count
reveals that there are no additional mappings. The current test ignores the
PGC_allocated flag and its effect on the page count.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2464,7 +2464,6 @@ int sh_remove_write_access_from_sl1p(str
 int sh_remove_all_mappings(struct vcpu *v, mfn_t gmfn)
 {
     struct page_info *page = mfn_to_page(gmfn);
-    int expected_count;
 
     /* Dispatch table for getting per-type functions */
     static const hash_callback_t callbacks[SH_type_unused] = {
@@ -2501,7 +2500,7 @@ int sh_remove_all_mappings(struct vcpu *
         ;
 
     perfc_incr(shadow_mappings);
-    if ( (page->count_info & PGC_count_mask) == 0 )
+    if ( __check_page_no_refs(page) )
         return 0;
 
     /* Although this is an externally visible function, we do not know
@@ -2517,8 +2516,7 @@ int sh_remove_all_mappings(struct vcpu *
     hash_foreach(v, callback_mask, callbacks, gmfn);
 
     /* If that didn't catch the mapping, something is very wrong */
-    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
-    if ( (page->count_info & PGC_count_mask) != expected_count )
+    if ( !__check_page_no_refs(page) )
     {
         /* Don't complain if we're in HVM and there are some extra mappings: 
          * The qemu helper process has an untyped mapping of this dom's RAM 
diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4591,7 +4591,7 @@ int sh_rm_mappings_from_l1(struct vcpu *
         {
             (void) shadow_set_l1e(v, sl1e, shadow_l1e_empty(),
                                   p2m_invalid, sl1mfn);
-            if ( (mfn_to_page(target_mfn)->count_info & PGC_count_mask) == 0 )
+            if ( __check_page_no_refs(mfn_to_page(target_mfn)) )
                 /* This breaks us cleanly out of the FOREACH macro */
                 done = 1;
         }
diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/private.h
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -815,6 +815,12 @@ static inline unsigned long vtlb_lookup(
 }
 #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
 
+static inline int __check_page_no_refs(struct page_info *page)
+{
+    unsigned long __count = page->count_info;
+    return ( (__count & PGC_count_mask) ==
+             ((__count & PGC_allocated) ? 1 : 0) ); 
+}
 
 #endif /* _XEN_SHADOW_PRIVATE_H */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 17:59:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 17:59:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdZT-0005f2-I5; Thu, 24 Nov 2011 17:58:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTdZS-0005ei-Ge
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 17:58:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322157498!5647579!1
X-Originating-IP: [208.97.132.66]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22564 invoked from network); 24 Nov 2011 17:58:18 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-4.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 17:58:18 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 3B0914B0086;
	Thu, 24 Nov 2011 09:58:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=MDPoThxTsLRKsSN4b81865
	tcrgZlg5zHMUkp5+9zbjZ094lle3gGXfxuurWsVR+9yeFIMkszs4xbltgkMYDq6d
	OGSUBEHgryY/fJ9EICc2AeHN5OaqpbPqVsuf8mhGTzvXqalNAykD/oKlotIajGyZ
	R8y6BhAi338QCw6K7CJ18=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=ZaByyZahYbXX
	KLZZIUweUpwiS3k=; b=OMCVhbJlLj8Je7oQMp5ok5WbVHUcvZDs2b1wVGfJCvyB
	udNSRVTBG3X7XwJLS9bCi9qhdDyhQhV5YmK32TWE4KWDq3NFOryx5nUtCum/3ccm
	fwTIdvyobfRF/qVWBK1nrnOZTxGaRjMSMPAxAYVCckjS+zcfE6wzArvmCWib7is=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPSA id 8A0FB4B0084; 
	Thu, 24 Nov 2011 09:58:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a264fb979b0c5391ce91c4adae27979af4aaea4e
Message-Id: <a264fb979b0c5391ce91.1322157496@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 24 Nov 2011 12:58:16 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Don't trigger unnecessary shadow scans on p2m
	entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/shadow/common.c  |  6 ++----
 xen/arch/x86/mm/shadow/multi.c   |  2 +-
 xen/arch/x86/mm/shadow/private.h |  6 ++++++
 3 files changed, 9 insertions(+), 5 deletions(-)


When updating a p2m entry, the hypervisor scans all shadow pte's to find
mappings of that gfn and tear them down. This is avoided if the page count
reveals that there are no additional mappings. The current test ignores the
PGC_allocated flag and its effect on the page count.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2464,7 +2464,6 @@ int sh_remove_write_access_from_sl1p(str
 int sh_remove_all_mappings(struct vcpu *v, mfn_t gmfn)
 {
     struct page_info *page = mfn_to_page(gmfn);
-    int expected_count;
 
     /* Dispatch table for getting per-type functions */
     static const hash_callback_t callbacks[SH_type_unused] = {
@@ -2501,7 +2500,7 @@ int sh_remove_all_mappings(struct vcpu *
         ;
 
     perfc_incr(shadow_mappings);
-    if ( (page->count_info & PGC_count_mask) == 0 )
+    if ( __check_page_no_refs(page) )
         return 0;
 
     /* Although this is an externally visible function, we do not know
@@ -2517,8 +2516,7 @@ int sh_remove_all_mappings(struct vcpu *
     hash_foreach(v, callback_mask, callbacks, gmfn);
 
     /* If that didn't catch the mapping, something is very wrong */
-    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
-    if ( (page->count_info & PGC_count_mask) != expected_count )
+    if ( !__check_page_no_refs(page) )
     {
         /* Don't complain if we're in HVM and there are some extra mappings: 
          * The qemu helper process has an untyped mapping of this dom's RAM 
diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4591,7 +4591,7 @@ int sh_rm_mappings_from_l1(struct vcpu *
         {
             (void) shadow_set_l1e(v, sl1e, shadow_l1e_empty(),
                                   p2m_invalid, sl1mfn);
-            if ( (mfn_to_page(target_mfn)->count_info & PGC_count_mask) == 0 )
+            if ( __check_page_no_refs(mfn_to_page(target_mfn)) )
                 /* This breaks us cleanly out of the FOREACH macro */
                 done = 1;
         }
diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/private.h
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -815,6 +815,12 @@ static inline unsigned long vtlb_lookup(
 }
 #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
 
+static inline int __check_page_no_refs(struct page_info *page)
+{
+    unsigned long __count = page->count_info;
+    return ( (__count & PGC_count_mask) ==
+             ((__count & PGC_allocated) ? 1 : 0) ); 
+}
 
 #endif /* _XEN_SHADOW_PRIVATE_H */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:07:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:07:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdhi-00064k-8k; Thu, 24 Nov 2011 18:07:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RTdhh-00064c-DW
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:07:21 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322158008!2923738!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14642 invoked from network); 24 Nov 2011 18:06:49 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:06:49 -0000
Received: by ggnr4 with SMTP id r4so4180987ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 10:06:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=nFw9GtKR9G0YqxU+V9tsbO+PIHoApakIS0KbLEZ7MlY=;
	b=jXlEU10V/pXLGWjsW8bbB1wVcRTnAnUZnWvlU7XTVWP9NPn3/ErzVUfPttkoMBwPCY
	95Um7TApIBjbhgVUHcuYx3tc3BIrR601K+/TnskH0cJgJZUEJr/Wh20A13srMjncgTu0
	v1ImyOx6Cld/2FbQaJfGng5C+ZcyimlL6Qq5I=
Received: by 10.182.115.106 with SMTP id jn10mr9533428obb.54.1322158008249;
	Thu, 24 Nov 2011 10:06:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.37.225 with HTTP; Thu, 24 Nov 2011 10:06:17 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111241720410.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-2-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.00.1111241720410.31179@kaball-desktop>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 24 Nov 2011 18:06:17 +0000
X-Google-Sender-Auth: vtZBOy9ygjTEpZFvkpReO4bPGec
Message-ID: <CAJJyHjJiR=s-uBwpOWe6JdSqnoWvgjkOLGBviLeTdG-DTY1r+Q@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/5] vl.c: Do not save RAM
	state when Xen is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 17:23, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 24 Nov 2011, Anthony PERARD wrote:
>> In Xen case, the guest RAM is not handle by QEMU, and it is saved by Xen tools.
>> So, we just avoid to register the RAM save state handler.
>
> Maybe we can unregister these handlers in the Xen specific
> initialization code, before we start receiving save/restore requests,
> otherwise we could have a nasty race condition.

One argument for my patch was: Not register at all the "ram"
save/restore function when Xen is enable make the code more clear: no
ram saved with Xen.

On the other hand, unregister the "ram" save/restore function in the
Xen code, will remove this if(xen) from the generic code.

I'm fine with both.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:07:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:07:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdhi-00064k-8k; Thu, 24 Nov 2011 18:07:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RTdhh-00064c-DW
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:07:21 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322158008!2923738!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14642 invoked from network); 24 Nov 2011 18:06:49 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:06:49 -0000
Received: by ggnr4 with SMTP id r4so4180987ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 10:06:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=nFw9GtKR9G0YqxU+V9tsbO+PIHoApakIS0KbLEZ7MlY=;
	b=jXlEU10V/pXLGWjsW8bbB1wVcRTnAnUZnWvlU7XTVWP9NPn3/ErzVUfPttkoMBwPCY
	95Um7TApIBjbhgVUHcuYx3tc3BIrR601K+/TnskH0cJgJZUEJr/Wh20A13srMjncgTu0
	v1ImyOx6Cld/2FbQaJfGng5C+ZcyimlL6Qq5I=
Received: by 10.182.115.106 with SMTP id jn10mr9533428obb.54.1322158008249;
	Thu, 24 Nov 2011 10:06:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.37.225 with HTTP; Thu, 24 Nov 2011 10:06:17 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111241720410.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-2-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.00.1111241720410.31179@kaball-desktop>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 24 Nov 2011 18:06:17 +0000
X-Google-Sender-Auth: vtZBOy9ygjTEpZFvkpReO4bPGec
Message-ID: <CAJJyHjJiR=s-uBwpOWe6JdSqnoWvgjkOLGBviLeTdG-DTY1r+Q@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 1/5] vl.c: Do not save RAM
	state when Xen is used.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 17:23, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 24 Nov 2011, Anthony PERARD wrote:
>> In Xen case, the guest RAM is not handle by QEMU, and it is saved by Xen tools.
>> So, we just avoid to register the RAM save state handler.
>
> Maybe we can unregister these handlers in the Xen specific
> initialization code, before we start receiving save/restore requests,
> otherwise we could have a nasty race condition.

One argument for my patch was: Not register at all the "ram"
save/restore function when Xen is enable make the code more clear: no
ram saved with Xen.

On the other hand, unregister the "ram" save/restore function in the
Xen code, will remove this if(xen) from the generic code.

I'm fine with both.

Regards,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:11:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:11:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdlq-0006Ig-Vg; Thu, 24 Nov 2011 18:11:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTdlp-0006IS-S3
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:11:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322158266!3640609!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10071 invoked from network); 24 Nov 2011 18:11:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:11:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119268"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:11:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:11:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTdlJ-0007Px-Js; Thu, 24 Nov 2011 18:11:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTdlJ-0004dY-J8;
	Thu, 24 Nov 2011 18:11:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.35001.566794.745844@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:11:05 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ec94a7e4983ad6338db2.1321617579@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<ec94a7e4983ad6338db2.1321617579@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec
	function	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexe> +        while (waitpid(pid, &status, 0) < 0) {
> +            if (errno != EINTR) {
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "waitpid failed\n");
> +                rc = -1;
> +                break;
> +            }
> +        }

It is good to see the exit status actually being retrieved and
checked.  But:

> +        if (WIFEXITED(status)) {
> +            rc = WEXITSTATUS(status);
> +        } else {
> +            rc = -1;
> +        }

I don't think this is the right thing to do with it.

Full and proper checking of a subprocess exit status involves:
  * checking for WIFSIGNALED too and perhaps calling strsignal
  * printing a message somewhere

I have found that the best way to deal with this is to split this up
into two parts:
   - Functions which pass back the wait status without interpreting it,
     and leaves checking it up to the caller
   - A generic function for reporting the meaning of an exit status
     to the log

It's also OK to have convenience functions which bundle these two
together, but the actual checking of an exit status involves logging.

Conveniently, I have already written the second function for you:
libxl_report_child_exitstatus :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:11:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:11:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdlq-0006Ig-Vg; Thu, 24 Nov 2011 18:11:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTdlp-0006IS-S3
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:11:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322158266!3640609!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10071 invoked from network); 24 Nov 2011 18:11:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:11:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119268"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:11:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:11:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTdlJ-0007Px-Js; Thu, 24 Nov 2011 18:11:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTdlJ-0004dY-J8;
	Thu, 24 Nov 2011 18:11:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.35001.566794.745844@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:11:05 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ec94a7e4983ad6338db2.1321617579@loki.upc.es>
References: <patchbomb.1321617576@loki.upc.es>
	<ec94a7e4983ad6338db2.1321617579@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexec
	function	to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monne writes ("[Xen-devel] [PATCH 3 of 9 v2] libxl: add libxl__forkexe> +        while (waitpid(pid, &status, 0) < 0) {
> +            if (errno != EINTR) {
> +                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "waitpid failed\n");
> +                rc = -1;
> +                break;
> +            }
> +        }

It is good to see the exit status actually being retrieved and
checked.  But:

> +        if (WIFEXITED(status)) {
> +            rc = WEXITSTATUS(status);
> +        } else {
> +            rc = -1;
> +        }

I don't think this is the right thing to do with it.

Full and proper checking of a subprocess exit status involves:
  * checking for WIFSIGNALED too and perhaps calling strsignal
  * printing a message somewhere

I have found that the best way to deal with this is to split this up
into two parts:
   - Functions which pass back the wait status without interpreting it,
     and leaves checking it up to the caller
   - A generic function for reporting the meaning of an exit status
     to the log

It's also OK to have convenience functions which bundle these two
together, but the actual checking of an exit status involves logging.

Conveniently, I have already written the second function for you:
libxl_report_child_exitstatus :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:25:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:25:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdyZ-0006sq-B8; Thu, 24 Nov 2011 18:24:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTdyX-0006si-U2
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:24:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322159054!2916601!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24886 invoked from network); 24 Nov 2011 18:24:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:24:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119386"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:24:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:24:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTdy1-0007VG-EH; Thu, 24 Nov 2011 18:24:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTdy1-0004fZ-Dn;
	Thu, 24 Nov 2011 18:24:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.35789.415583.75576@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:24:13 +0000
To: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CACm5R6QtG3LYGkUw-Js6w3G5Gj61Cox0LrN0Cay=q_Z0k5fL4Q@mail.gmail.com>
References: <CACm5R6QtG3LYGkUw-Js6w3G5Gj61Cox0LrN0Cay=q_Z0k5fL4Q@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] HTML in wikitext
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen-devel.GarveyPatrickD@OrdinaryAmerican.net writes ("[Xen-devel] HTML in wikitext"):
> According to https://secure.wikimedia.org/wikipedia/en/wiki/Help:HTML_in_wikitext#Permitted_HTML
> <abbr title="abbreviation">abbr.</abbr> should be parsed as HTML by
> the wiki server.

That text refers to Wikipedia, not to the Xen Wiki.

> According to my experiment,
> http://wiki.xen.org/wiki/User:GarveyPatrickD/Abbreviations
> the Xen wiki doesn't seem to have this feature enabled.

That is correct.  We don't plan to enable it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:25:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:25:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdyZ-0006sq-B8; Thu, 24 Nov 2011 18:24:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTdyX-0006si-U2
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:24:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322159054!2916601!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24886 invoked from network); 24 Nov 2011 18:24:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:24:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119386"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:24:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:24:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTdy1-0007VG-EH; Thu, 24 Nov 2011 18:24:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTdy1-0004fZ-Dn;
	Thu, 24 Nov 2011 18:24:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.35789.415583.75576@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:24:13 +0000
To: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CACm5R6QtG3LYGkUw-Js6w3G5Gj61Cox0LrN0Cay=q_Z0k5fL4Q@mail.gmail.com>
References: <CACm5R6QtG3LYGkUw-Js6w3G5Gj61Cox0LrN0Cay=q_Z0k5fL4Q@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] HTML in wikitext
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen-devel.GarveyPatrickD@OrdinaryAmerican.net writes ("[Xen-devel] HTML in wikitext"):
> According to https://secure.wikimedia.org/wikipedia/en/wiki/Help:HTML_in_wikitext#Permitted_HTML
> <abbr title="abbreviation">abbr.</abbr> should be parsed as HTML by
> the wiki server.

That text refers to Wikipedia, not to the Xen Wiki.

> According to my experiment,
> http://wiki.xen.org/wiki/User:GarveyPatrickD/Abbreviations
> the Xen wiki doesn't seem to have this feature enabled.

That is correct.  We don't plan to enable it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:25:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdyl-0006tv-UN; Thu, 24 Nov 2011 18:24:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTdyk-0006tl-KB
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:24:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322159034!47261080!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26930 invoked from network); 24 Nov 2011 18:23:55 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Nov 2011 18:23:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322159071; l=671;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ANl2wbgpSLDgDlteIBu4BrI2LX0=;
	b=oKKnepxZ7Y1lwFcv3J86ctu/0TC7PZJhhHZbJPS0M4VzQetJweP8LJcJQs0kkLOcNZH
	3uiWNcmE+zgJDaCz8aQTJm3OHGdhDgg70ipE0jXGpJedHGx8CgQset9/KXTOQvGZ99OsY
	Bh75KRYMEHB/fuPz2QtDAU2ubsB1Ql06vbM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (klopstock mo48) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R05163nAOGH1Tk ;
	Thu, 24 Nov 2011 19:24:15 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2F78F18637; Thu, 24 Nov 2011 19:24:15 +0100 (CET)
Date: Thu, 24 Nov 2011 19:24:15 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111124182415.GA24717@aepfle.de>
References: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
	<8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
	<20111124172215.GQ77868@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111124172215.GQ77868@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Tim Deegan wrote:

> > Is this a good idea? If the guest is accessing the page, then paging out
> > should stop immediately. We're risking complex races for a tiny tiny gain.
> 
> I don't think that this would introduce any new races, but yes - this is
> probably a hint that this page is a poor candidate to be paged out.
> We might as well abandon the page-out rather than probably having to
> page it back in immediately.

In the current state there will be a stall in the guest due to the
fault, until the page comes back. 
With this change the guest can still make progress. 
Can the read-execute access be detected anyway to stop paging?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:25:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTdyl-0006tv-UN; Thu, 24 Nov 2011 18:24:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTdyk-0006tl-KB
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:24:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322159034!47261080!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26930 invoked from network); 24 Nov 2011 18:23:55 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Nov 2011 18:23:55 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322159071; l=671;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=ANl2wbgpSLDgDlteIBu4BrI2LX0=;
	b=oKKnepxZ7Y1lwFcv3J86ctu/0TC7PZJhhHZbJPS0M4VzQetJweP8LJcJQs0kkLOcNZH
	3uiWNcmE+zgJDaCz8aQTJm3OHGdhDgg70ipE0jXGpJedHGx8CgQset9/KXTOQvGZ99OsY
	Bh75KRYMEHB/fuPz2QtDAU2ubsB1Ql06vbM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (klopstock mo48) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R05163nAOGH1Tk ;
	Thu, 24 Nov 2011 19:24:15 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2F78F18637; Thu, 24 Nov 2011 19:24:15 +0100 (CET)
Date: Thu, 24 Nov 2011 19:24:15 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111124182415.GA24717@aepfle.de>
References: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
	<8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
	<20111124172215.GQ77868@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111124172215.GQ77868@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Tim Deegan wrote:

> > Is this a good idea? If the guest is accessing the page, then paging out
> > should stop immediately. We're risking complex races for a tiny tiny gain.
> 
> I don't think that this would introduce any new races, but yes - this is
> probably a hint that this page is a poor candidate to be paged out.
> We might as well abandon the page-out rather than probably having to
> page it back in immediately.

In the current state there will be a stall in the guest due to the
fault, until the page comes back. 
With this change the guest can still make progress. 
Can the read-execute access be detected anyway to stop paging?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:30:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:30:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTe3Z-0007DB-Mx; Thu, 24 Nov 2011 18:29:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTe3Y-0007Co-2B
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:29:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322159364!4817027!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32500 invoked from network); 24 Nov 2011 18:29:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:29:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:29:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:29:24 +0000
Date: Thu, 24 Nov 2011 18:30:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1322150893-887-6-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1111241816250.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-6-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/5] vga-cirrus: Workaround during restore
 when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 24 Nov 2011, Anthony PERARD wrote:
> During the initialisation of the machine at restore time, the access to the
> VRAM will fail because QEMU does not know yet the right guest address to map,
> so the vram_ptr is NULL.
> 
> So this patch avoid using a NULL pointer during initialisation, and try to get
> another vram_ptr if the call failed the first time.

This patch looks really bad, however I am not sure how to improve it.

Let's see if I get this straight: on Xen the videoram is saved and
restored by Xen like normal guest's ram.
Therefore we skip a second videoram allocation in vga_common_init,
returning NULL.
As a consequence vga.vram_ptr is going to be invalid until
cirrus_update_memory_access is called, when the cirrus state is restored
and we finally know the position of the videoram in the guest address
space, so we can map it again.



> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/cirrus_vga.c |   20 +++++++++++++++++---
>  1 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
> index c7e365b..d092c74 100644
> --- a/hw/cirrus_vga.c
> +++ b/hw/cirrus_vga.c
> @@ -32,6 +32,7 @@
>  #include "console.h"
>  #include "vga_int.h"
>  #include "loader.h"
> +#include "sysemu.h"
>  
>  /*
>   * TODO:
> @@ -2696,6 +2697,17 @@ static int cirrus_post_load(void *opaque, int version_id)
>      s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
>  
>      cirrus_update_memory_access(s);
> +    if (!s->vga.vram_ptr) {
> +        /* Try again
> +         * The initial call to get_ram_ptr can fail with Xen during a migration
> +         * because the VRAM has been moved arround.
> +         * (Moved with a set_memory and a xen_add_to_physmap)
> +         * After cirrus_update_memory_access, the Xen function will know were
> +         * the memory actually is, and fix the address before give back a
> +         * ram_ptr.
> +         */
> +        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
> +    }
>      /* force refresh */
>      s->vga.graphic_mode = -1;
>      cirrus_update_bank_ptr(s, 0);

I would change the comment to:

"At this point vga.vram_ptr can be invalid on Xen because we need to
know the position of the videoram in the guest physical address space in
order to be able to map it. After cirrus_update_memory_access we do know
where the videoram is, so let's map it now."


> @@ -2784,9 +2796,11 @@ static void cirrus_reset(void *opaque)
>      }
>      s->vga.cr[0x27] = s->device_id;
>  
> -    /* Win2K seems to assume that the pattern buffer is at 0xff
> -       initially ! */
> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
> +        /* Win2K seems to assume that the pattern buffer is at 0xff
> +           initially ! */
> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> +    }
>  

this is not too bad, I suppose that the videoram is going to be written
again at restore time anyway so at least it saves some cycles

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:30:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:30:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTe3Z-0007DB-Mx; Thu, 24 Nov 2011 18:29:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTe3Y-0007Co-2B
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:29:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322159364!4817027!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32500 invoked from network); 24 Nov 2011 18:29:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:29:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:29:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:29:24 +0000
Date: Thu, 24 Nov 2011 18:30:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <1322150893-887-6-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.00.1111241816250.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-6-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/5] vga-cirrus: Workaround during restore
 when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 24 Nov 2011, Anthony PERARD wrote:
> During the initialisation of the machine at restore time, the access to the
> VRAM will fail because QEMU does not know yet the right guest address to map,
> so the vram_ptr is NULL.
> 
> So this patch avoid using a NULL pointer during initialisation, and try to get
> another vram_ptr if the call failed the first time.

This patch looks really bad, however I am not sure how to improve it.

Let's see if I get this straight: on Xen the videoram is saved and
restored by Xen like normal guest's ram.
Therefore we skip a second videoram allocation in vga_common_init,
returning NULL.
As a consequence vga.vram_ptr is going to be invalid until
cirrus_update_memory_access is called, when the cirrus state is restored
and we finally know the position of the videoram in the guest address
space, so we can map it again.



> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/cirrus_vga.c |   20 +++++++++++++++++---
>  1 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
> index c7e365b..d092c74 100644
> --- a/hw/cirrus_vga.c
> +++ b/hw/cirrus_vga.c
> @@ -32,6 +32,7 @@
>  #include "console.h"
>  #include "vga_int.h"
>  #include "loader.h"
> +#include "sysemu.h"
>  
>  /*
>   * TODO:
> @@ -2696,6 +2697,17 @@ static int cirrus_post_load(void *opaque, int version_id)
>      s->vga.gr[0x01] = s->cirrus_shadow_gr1 & 0x0f;
>  
>      cirrus_update_memory_access(s);
> +    if (!s->vga.vram_ptr) {
> +        /* Try again
> +         * The initial call to get_ram_ptr can fail with Xen during a migration
> +         * because the VRAM has been moved arround.
> +         * (Moved with a set_memory and a xen_add_to_physmap)
> +         * After cirrus_update_memory_access, the Xen function will know were
> +         * the memory actually is, and fix the address before give back a
> +         * ram_ptr.
> +         */
> +        s->vga.vram_ptr = memory_region_get_ram_ptr(&s->vga.vram);
> +    }
>      /* force refresh */
>      s->vga.graphic_mode = -1;
>      cirrus_update_bank_ptr(s, 0);

I would change the comment to:

"At this point vga.vram_ptr can be invalid on Xen because we need to
know the position of the videoram in the guest physical address space in
order to be able to map it. After cirrus_update_memory_access we do know
where the videoram is, so let's map it now."


> @@ -2784,9 +2796,11 @@ static void cirrus_reset(void *opaque)
>      }
>      s->vga.cr[0x27] = s->device_id;
>  
> -    /* Win2K seems to assume that the pattern buffer is at 0xff
> -       initially ! */
> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
> +        /* Win2K seems to assume that the pattern buffer is at 0xff
> +           initially ! */
> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> +    }
>  

this is not too bad, I suppose that the videoram is going to be written
again at restore time anyway so at least it saves some cycles

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:32:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:32:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTe65-0007PU-8P; Thu, 24 Nov 2011 18:32:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTe64-0007PC-1J
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:32:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322159520!4885023!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14562 invoked from network); 24 Nov 2011 18:32:00 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:32:00 -0000
Received: by bkbzt12 with SMTP id zt12so4293734bkb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 10:32:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=XlLuvmWQ4qeHgvQsAx65dH+sXN3LaLiTN0iNqe6TUrE=;
	b=PSs+exHYqGYy0769yPGYrT6n6BLx0JqYTiu8bg5gB9z6FTAFxFcVMmUETpwpthpw7P
	wRH2qdPrMqC5LpkdapFRXWaPb2QB+oYy+ndAw4MGzvqWLZ5b0Na9Qn5ih6r8pS09r0/6
	G4mAo1iernARWudd7zt6UCt/iJRqTkeiFg2Wk=
Received: by 10.204.141.2 with SMTP id k2mr27448482bku.81.1322159519971;
	Thu, 24 Nov 2011 10:31:59 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id c4sm16550869bkk.13.2011.11.24.10.31.57
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 10:31:59 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 18:31:55 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAF43E1B.25838%keir.xen@gmail.com>
Thread-Topic: [PATCH] Don't trigger unnecessary shadow scans on p2m entry
	update
Thread-Index: Acyq11eGzlptdw5qgk2jIsI/IS1PTg==
In-Reply-To: <a264fb979b0c5391ce91.1322157496@xdev.gridcentric.ca>
Mime-version: 1.0
Cc: andres@gridcentric.ca, tim@xen.org, JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Don't trigger unnecessary shadow scans on
 p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 17:58, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

>  xen/arch/x86/mm/shadow/common.c  |  6 ++----
>  xen/arch/x86/mm/shadow/multi.c   |  2 +-
>  xen/arch/x86/mm/shadow/private.h |  6 ++++++
>  3 files changed, 9 insertions(+), 5 deletions(-)
> 
> 
> When updating a p2m entry, the hypervisor scans all shadow pte's to find
> mappings of that gfn and tear them down. This is avoided if the page count
> reveals that there are no additional mappings. The current test ignores the
> PGC_allocated flag and its effect on the page count.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/common.c
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -2464,7 +2464,6 @@ int sh_remove_write_access_from_sl1p(str
>  int sh_remove_all_mappings(struct vcpu *v, mfn_t gmfn)
>  {
>      struct page_info *page = mfn_to_page(gmfn);
> -    int expected_count;
>  
>      /* Dispatch table for getting per-type functions */
>      static const hash_callback_t callbacks[SH_type_unused] = {
> @@ -2501,7 +2500,7 @@ int sh_remove_all_mappings(struct vcpu *
>          ;
>  
>      perfc_incr(shadow_mappings);
> -    if ( (page->count_info & PGC_count_mask) == 0 )
> +    if ( __check_page_no_refs(page) )
>          return 0;
>  
>      /* Although this is an externally visible function, we do not know
> @@ -2517,8 +2516,7 @@ int sh_remove_all_mappings(struct vcpu *
>      hash_foreach(v, callback_mask, callbacks, gmfn);
>  
>      /* If that didn't catch the mapping, something is very wrong */
> -    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
> -    if ( (page->count_info & PGC_count_mask) != expected_count )
> +    if ( !__check_page_no_refs(page) )
>      {
>          /* Don't complain if we're in HVM and there are some extra mappings:
>           * The qemu helper process has an untyped mapping of this dom's RAM
> diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/multi.c
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -4591,7 +4591,7 @@ int sh_rm_mappings_from_l1(struct vcpu *
>          {
>              (void) shadow_set_l1e(v, sl1e, shadow_l1e_empty(),
>                                    p2m_invalid, sl1mfn);
> -            if ( (mfn_to_page(target_mfn)->count_info & PGC_count_mask) == 0
> )
> +            if ( __check_page_no_refs(mfn_to_page(target_mfn)) )
>                  /* This breaks us cleanly out of the FOREACH macro */
>                  done = 1;
>          }
> diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/private.h
> --- a/xen/arch/x86/mm/shadow/private.h
> +++ b/xen/arch/x86/mm/shadow/private.h
> @@ -815,6 +815,12 @@ static inline unsigned long vtlb_lookup(
>  }
>  #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
>  
> +static inline int __check_page_no_refs(struct page_info *page)
> +{
> +    unsigned long __count = page->count_info;
> +    return ( (__count & PGC_count_mask) ==
> +             ((__count & PGC_allocated) ? 1 : 0) );

It's a fussy point, but it might be better to use
atomic_read_ulong(&page->count_info) here, to ensure that the compiler reads
the field once only. It's cheap (compiles to a single mov instruction), but
atomic_read_ulong doesn't exist so you'd have to add its (obvious)
definition to asm-x86/atomic.h

 -- Keir

> +}
>  
>  #endif /* _XEN_SHADOW_PRIVATE_H */
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:32:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:32:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTe65-0007PU-8P; Thu, 24 Nov 2011 18:32:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTe64-0007PC-1J
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:32:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322159520!4885023!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14562 invoked from network); 24 Nov 2011 18:32:00 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:32:00 -0000
Received: by bkbzt12 with SMTP id zt12so4293734bkb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 10:32:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=XlLuvmWQ4qeHgvQsAx65dH+sXN3LaLiTN0iNqe6TUrE=;
	b=PSs+exHYqGYy0769yPGYrT6n6BLx0JqYTiu8bg5gB9z6FTAFxFcVMmUETpwpthpw7P
	wRH2qdPrMqC5LpkdapFRXWaPb2QB+oYy+ndAw4MGzvqWLZ5b0Na9Qn5ih6r8pS09r0/6
	G4mAo1iernARWudd7zt6UCt/iJRqTkeiFg2Wk=
Received: by 10.204.141.2 with SMTP id k2mr27448482bku.81.1322159519971;
	Thu, 24 Nov 2011 10:31:59 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id c4sm16550869bkk.13.2011.11.24.10.31.57
	(version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 10:31:59 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Thu, 24 Nov 2011 18:31:55 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAF43E1B.25838%keir.xen@gmail.com>
Thread-Topic: [PATCH] Don't trigger unnecessary shadow scans on p2m entry
	update
Thread-Index: Acyq11eGzlptdw5qgk2jIsI/IS1PTg==
In-Reply-To: <a264fb979b0c5391ce91.1322157496@xdev.gridcentric.ca>
Mime-version: 1.0
Cc: andres@gridcentric.ca, tim@xen.org, JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Don't trigger unnecessary shadow scans on
 p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11/2011 17:58, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

>  xen/arch/x86/mm/shadow/common.c  |  6 ++----
>  xen/arch/x86/mm/shadow/multi.c   |  2 +-
>  xen/arch/x86/mm/shadow/private.h |  6 ++++++
>  3 files changed, 9 insertions(+), 5 deletions(-)
> 
> 
> When updating a p2m entry, the hypervisor scans all shadow pte's to find
> mappings of that gfn and tear them down. This is avoided if the page count
> reveals that there are no additional mappings. The current test ignores the
> PGC_allocated flag and its effect on the page count.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/common.c
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -2464,7 +2464,6 @@ int sh_remove_write_access_from_sl1p(str
>  int sh_remove_all_mappings(struct vcpu *v, mfn_t gmfn)
>  {
>      struct page_info *page = mfn_to_page(gmfn);
> -    int expected_count;
>  
>      /* Dispatch table for getting per-type functions */
>      static const hash_callback_t callbacks[SH_type_unused] = {
> @@ -2501,7 +2500,7 @@ int sh_remove_all_mappings(struct vcpu *
>          ;
>  
>      perfc_incr(shadow_mappings);
> -    if ( (page->count_info & PGC_count_mask) == 0 )
> +    if ( __check_page_no_refs(page) )
>          return 0;
>  
>      /* Although this is an externally visible function, we do not know
> @@ -2517,8 +2516,7 @@ int sh_remove_all_mappings(struct vcpu *
>      hash_foreach(v, callback_mask, callbacks, gmfn);
>  
>      /* If that didn't catch the mapping, something is very wrong */
> -    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
> -    if ( (page->count_info & PGC_count_mask) != expected_count )
> +    if ( !__check_page_no_refs(page) )
>      {
>          /* Don't complain if we're in HVM and there are some extra mappings:
>           * The qemu helper process has an untyped mapping of this dom's RAM
> diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/multi.c
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -4591,7 +4591,7 @@ int sh_rm_mappings_from_l1(struct vcpu *
>          {
>              (void) shadow_set_l1e(v, sl1e, shadow_l1e_empty(),
>                                    p2m_invalid, sl1mfn);
> -            if ( (mfn_to_page(target_mfn)->count_info & PGC_count_mask) == 0
> )
> +            if ( __check_page_no_refs(mfn_to_page(target_mfn)) )
>                  /* This breaks us cleanly out of the FOREACH macro */
>                  done = 1;
>          }
> diff -r 5c339eb31d34 -r a264fb979b0c xen/arch/x86/mm/shadow/private.h
> --- a/xen/arch/x86/mm/shadow/private.h
> +++ b/xen/arch/x86/mm/shadow/private.h
> @@ -815,6 +815,12 @@ static inline unsigned long vtlb_lookup(
>  }
>  #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
>  
> +static inline int __check_page_no_refs(struct page_info *page)
> +{
> +    unsigned long __count = page->count_info;
> +    return ( (__count & PGC_count_mask) ==
> +             ((__count & PGC_allocated) ? 1 : 0) );

It's a fussy point, but it might be better to use
atomic_read_ulong(&page->count_info) here, to ensure that the compiler reads
the field once only. It's cheap (compiles to a single mov instruction), but
atomic_read_ulong doesn't exist so you'd have to add its (obvious)
definition to asm-x86/atomic.h

 -- Keir

> +}
>  
>  #endif /* _XEN_SHADOW_PRIVATE_H */
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:33:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTe6Y-0007Ri-MW; Thu, 24 Nov 2011 18:33:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTe6X-0007R4-2Q
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:33:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322159549!5628290!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22262 invoked from network); 24 Nov 2011 18:32:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:32:29 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119451"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:31:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:31:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTe5X-0007YC-D0; Thu, 24 Nov 2011 18:31:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTe5X-0004gC-CD;
	Thu, 24 Nov 2011 18:31:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.36255.134440.874181@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:31:59 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("[Xen-devel] [PATCH] Add missing modprobe to xencommons"):
> Add missing modprobe to xencommons
...
> +		modprobe xen-evtchn

Is this really the way we want to do things ?  I guess it's a
plausible thing to do which is harmless if the module name doesn't
change.

But perhaps something else in the system should be organising that
evtchn gets loaded ?  Also, this isn't the only module we need.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:33:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:33:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTe6Y-0007Ri-MW; Thu, 24 Nov 2011 18:33:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTe6X-0007R4-2Q
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:33:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322159549!5628290!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22262 invoked from network); 24 Nov 2011 18:32:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:32:29 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119451"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:31:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:31:59 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTe5X-0007YC-D0; Thu, 24 Nov 2011 18:31:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTe5X-0004gC-CD;
	Thu, 24 Nov 2011 18:31:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.36255.134440.874181@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:31:59 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("[Xen-devel] [PATCH] Add missing modprobe to xencommons"):
> Add missing modprobe to xencommons
...
> +		modprobe xen-evtchn

Is this really the way we want to do things ?  I guess it's a
plausible thing to do which is harmless if the module name doesn't
change.

But perhaps something else in the system should be organising that
evtchn gets loaded ?  Also, this isn't the only module we need.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:39:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeCX-0007nF-NG; Thu, 24 Nov 2011 18:39:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeCW-0007nA-Ju
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:39:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322159911!56374494!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3583 invoked from network); 24 Nov 2011 18:38:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:38:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:38:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeC5-0007aF-RL; Thu, 24 Nov 2011 18:38:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeC5-0004gp-Qf;
	Thu, 24 Nov 2011 18:38:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.36661.814563.526570@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:38:45 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111122113507.GA28412@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
	related	libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> After a split of libtinfo from libncurses in openSuSE Factory the tools
> will not link anymore. In the URL below it was suggested to use
> 'ncurses-config --libs' to find the correct linker options. But
> ncurses-config does not exist neither in SLES11 nor in openSuSE. So
> check for both ncurses5-config and ncurses-config, if the latter happens
> to exist in other environments.
> 
> With this change xen-unstable tools build succeeds again in SLES11 and
> the latest openSuSE development branch.

Thanks.  However:

> -CURSES_LIBS = -lncurses
> +CURSES_LIBS = $(shell if ! ncurses5-config --libs 2>/dev/null ; then ncurses-config --libs ; fi)

In the case where ncurses5-config is not provided, this will fail.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:39:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeCX-0007nF-NG; Thu, 24 Nov 2011 18:39:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeCW-0007nA-Ju
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:39:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322159911!56374494!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3583 invoked from network); 24 Nov 2011 18:38:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:38:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:38:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeC5-0007aF-RL; Thu, 24 Nov 2011 18:38:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeC5-0004gp-Qf;
	Thu, 24 Nov 2011 18:38:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.36661.814563.526570@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:38:45 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111122113507.GA28412@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
	related	libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> After a split of libtinfo from libncurses in openSuSE Factory the tools
> will not link anymore. In the URL below it was suggested to use
> 'ncurses-config --libs' to find the correct linker options. But
> ncurses-config does not exist neither in SLES11 nor in openSuSE. So
> check for both ncurses5-config and ncurses-config, if the latter happens
> to exist in other environments.
> 
> With this change xen-unstable tools build succeeds again in SLES11 and
> the latest openSuSE development branch.

Thanks.  However:

> -CURSES_LIBS = -lncurses
> +CURSES_LIBS = $(shell if ! ncurses5-config --libs 2>/dev/null ; then ncurses-config --libs ; fi)

In the case where ncurses5-config is not provided, this will fail.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:41:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeEs-0007t4-9B; Thu, 24 Nov 2011 18:41:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTeEq-0007st-9e
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:41:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322160064!2917753!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24304 invoked from network); 24 Nov 2011 18:41:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Nov 2011 18:41:04 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322160064; l=1296;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TxQINFuQAbeeyMlwD243+4J9c2E=;
	b=qrafBaC9Y8/9DhtW9i7wNCEXOX7BOB/JA3IPJ83rEf0mfefkzYEt17MRj8CDSDwPzzT
	ffX/obAvEIhSSBUZKl1Zc0kqBvkHVKpQT+2Ox6zsXrWSixU4qKfcQ8DjCKf/36zP+Dq3V
	CrIhEPCus1jzEPGd691Yfb0rj+Es2TdKbaU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (klopstock mo48) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R05163nAOGH1f1 ;
	Thu, 24 Nov 2011 19:40:45 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4046418637; Thu, 24 Nov 2011 19:40:45 +0100 (CET)
Date: Thu, 24 Nov 2011 19:40:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111124184045.GB24717@aepfle.de>
References: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
	<8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
	<20111124172215.GQ77868@ocelot.phlegethon.org>
	<20111124182415.GA24717@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111124182415.GA24717@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Olaf Hering wrote:

> On Thu, Nov 24, Tim Deegan wrote:
> 
> > > Is this a good idea? If the guest is accessing the page, then paging out
> > > should stop immediately. We're risking complex races for a tiny tiny gain.
> > 
> > I don't think that this would introduce any new races, but yes - this is
> > probably a hint that this page is a poor candidate to be paged out.
> > We might as well abandon the page-out rather than probably having to
> > page it back in immediately.
> 
> In the current state there will be a stall in the guest due to the
> fault, until the page comes back. 
> With this change the guest can still make progress. 
> Can the read-execute access be detected anyway to stop paging?

(I hit send too soon..)

Right now nominate would cause an immediate fault. populate would be
called at some point, hopefully before evict. If populate were smart
enough to bring the page back from p2m_ram_paging_out to p2m_ram_rw and
let the callers know about that, the guest could proceed right away. I
have already added some code to populate to detect p2m_ram_paging_out.
Perhaps p2m_mem_paging_populate shouldnt be void. It could return -EBUSY
to its callers, they should get a valid mfn for their gfn and handle the
gfn as valid ram.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:41:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:41:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeEs-0007t4-9B; Thu, 24 Nov 2011 18:41:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTeEq-0007st-9e
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:41:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322160064!2917753!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24304 invoked from network); 24 Nov 2011 18:41:04 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Nov 2011 18:41:04 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322160064; l=1296;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TxQINFuQAbeeyMlwD243+4J9c2E=;
	b=qrafBaC9Y8/9DhtW9i7wNCEXOX7BOB/JA3IPJ83rEf0mfefkzYEt17MRj8CDSDwPzzT
	ffX/obAvEIhSSBUZKl1Zc0kqBvkHVKpQT+2Ox6zsXrWSixU4qKfcQ8DjCKf/36zP+Dq3V
	CrIhEPCus1jzEPGd691Yfb0rj+Es2TdKbaU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (klopstock mo48) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R05163nAOGH1f1 ;
	Thu, 24 Nov 2011 19:40:45 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4046418637; Thu, 24 Nov 2011 19:40:45 +0100 (CET)
Date: Thu, 24 Nov 2011 19:40:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20111124184045.GB24717@aepfle.de>
References: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
	<8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
	<20111124172215.GQ77868@ocelot.phlegethon.org>
	<20111124182415.GA24717@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111124182415.GA24717@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Olaf Hering wrote:

> On Thu, Nov 24, Tim Deegan wrote:
> 
> > > Is this a good idea? If the guest is accessing the page, then paging out
> > > should stop immediately. We're risking complex races for a tiny tiny gain.
> > 
> > I don't think that this would introduce any new races, but yes - this is
> > probably a hint that this page is a poor candidate to be paged out.
> > We might as well abandon the page-out rather than probably having to
> > page it back in immediately.
> 
> In the current state there will be a stall in the guest due to the
> fault, until the page comes back. 
> With this change the guest can still make progress. 
> Can the read-execute access be detected anyway to stop paging?

(I hit send too soon..)

Right now nominate would cause an immediate fault. populate would be
called at some point, hopefully before evict. If populate were smart
enough to bring the page back from p2m_ram_paging_out to p2m_ram_rw and
let the callers know about that, the guest could proceed right away. I
have already added some code to populate to detect p2m_ram_paging_out.
Perhaps p2m_mem_paging_populate shouldnt be void. It could return -EBUSY
to its callers, they should get a valid mfn for their gfn and handle the
gfn as valid ram.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:42:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeF3-0007u6-M4; Thu, 24 Nov 2011 18:41:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTeF2-0007ta-SQ
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:41:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322160077!2924785!1
X-Originating-IP: [208.97.132.83]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23500 invoked from network); 24 Nov 2011 18:41:17 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 18:41:17 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 249DD33406B;
	Thu, 24 Nov 2011 10:41:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=mx4/zmlWmak+41fgsowE+ZeOUTlg9nL9tnbSw0YVnIqI
	XL3OS85FkzddbmxShTnAFCSlG8eHfjFsnDt5jpIZriQlApLlmhcJSP0svp0KCcg3
	hdM15l8xMT5VwBfoSZwtVW1hsGGBohCip4YHU2pg+mR5xFbtup+zgqFY6EguPME=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=DOSx3UfqNbTFo4JIlZ/g2rNZYZY=; b=ZV7t8byU
	9Cc4MPynJ6JkFFLK5BIHwjQgjkXEE8vIpPJvZzWDTt0NnIqq9wGzW9buNiE7q3YO
	FQYIlBPNvt+/vVhbx7QrDj7aB4NccB+LdlwjskFkLE+gH/kjFbAP1Vv+I7KrOnPw
	6ByTZbR2KfDcWcnX/k6dR+RltnypxXB3FBE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id BC81F33406A; 
	Thu, 24 Nov 2011 10:41:15 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 10:41:16 -0800
Message-ID: <faf6ec7d1e124a4cd9e4ac9146808dbb.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124182415.GA24717@aepfle.de>
References: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
	<8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
	<20111124172215.GQ77868@ocelot.phlegethon.org>
	<20111124182415.GA24717@aepfle.de>
Date: Thu, 24 Nov 2011 10:41:16 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Nov 24, Tim Deegan wrote:
>
>> > Is this a good idea? If the guest is accessing the page, then paging
>> out
>> > should stop immediately. We're risking complex races for a tiny tiny
>> gain.
>>
>> I don't think that this would introduce any new races, but yes - this is
>> probably a hint that this page is a poor candidate to be paged out.
>> We might as well abandon the page-out rather than probably having to
>> page it back in immediately.
>
> In the current state there will be a stall in the guest due to the
> fault, until the page comes back.
> With this change the guest can still make progress.
> Can the read-execute access be detected anyway to stop paging?
>
The stall is minuscule. A "minor fault" since the page hasn't been paged
out yet (in the condition this patch is concerned with) and thus there is
no IO readback.

The current code handles this nicely with its state machine. Further, it
lets the pager know with an additional event in the ring, which is
something I'd like to keep in place.

There are extra round-trip(s) to the pager, as is. Imho, it's not an
unreasonable price for a fringe condition.

Andres


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:42:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeF3-0007u6-M4; Thu, 24 Nov 2011 18:41:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTeF2-0007ta-SQ
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:41:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322160077!2924785!1
X-Originating-IP: [208.97.132.83]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23500 invoked from network); 24 Nov 2011 18:41:17 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 18:41:17 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 249DD33406B;
	Thu, 24 Nov 2011 10:41:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=mx4/zmlWmak+41fgsowE+ZeOUTlg9nL9tnbSw0YVnIqI
	XL3OS85FkzddbmxShTnAFCSlG8eHfjFsnDt5jpIZriQlApLlmhcJSP0svp0KCcg3
	hdM15l8xMT5VwBfoSZwtVW1hsGGBohCip4YHU2pg+mR5xFbtup+zgqFY6EguPME=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=DOSx3UfqNbTFo4JIlZ/g2rNZYZY=; b=ZV7t8byU
	9Cc4MPynJ6JkFFLK5BIHwjQgjkXEE8vIpPJvZzWDTt0NnIqq9wGzW9buNiE7q3YO
	FQYIlBPNvt+/vVhbx7QrDj7aB4NccB+LdlwjskFkLE+gH/kjFbAP1Vv+I7KrOnPw
	6ByTZbR2KfDcWcnX/k6dR+RltnypxXB3FBE=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id BC81F33406A; 
	Thu, 24 Nov 2011 10:41:15 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 10:41:16 -0800
Message-ID: <faf6ec7d1e124a4cd9e4ac9146808dbb.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124182415.GA24717@aepfle.de>
References: <mailman.1616.1322135934.12970.xen-devel@lists.xensource.com>
	<8473f13969bb87a8e297b87c88f7a257.squirrel@webmail.lagarcavilla.org>
	<20111124172215.GQ77868@ocelot.phlegethon.org>
	<20111124182415.GA24717@aepfle.de>
Date: Thu, 24 Nov 2011 10:41:16 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] mark pages in p2m_ram_paging_out state read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Nov 24, Tim Deegan wrote:
>
>> > Is this a good idea? If the guest is accessing the page, then paging
>> out
>> > should stop immediately. We're risking complex races for a tiny tiny
>> gain.
>>
>> I don't think that this would introduce any new races, but yes - this is
>> probably a hint that this page is a poor candidate to be paged out.
>> We might as well abandon the page-out rather than probably having to
>> page it back in immediately.
>
> In the current state there will be a stall in the guest due to the
> fault, until the page comes back.
> With this change the guest can still make progress.
> Can the read-execute access be detected anyway to stop paging?
>
The stall is minuscule. A "minor fault" since the page hasn't been paged
out yet (in the condition this patch is concerned with) and thus there is
no IO readback.

The current code handles this nicely with its state machine. Further, it
lets the pager know with an additional event in the ring, which is
something I'd like to keep in place.

There are extra round-trip(s) to the pager, as is. Imho, it's not an
unreasonable price for a fringe condition.

Andres


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:42:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:42:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeFe-00082T-AW; Thu, 24 Nov 2011 18:42:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeFc-00081a-PP
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:42:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322160113!4871124!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16791 invoked from network); 24 Nov 2011 18:41:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:41:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:41:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:41:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeEz-0007bJ-P2; Thu, 24 Nov 2011 18:41:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeEz-0004hD-OG;
	Thu, 24 Nov 2011 18:41:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.36841.738985.984736@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:41:45 +0000
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2b60cfe7-2c97-45ef-bf89-88cd01cff1d3@default>
References: <20171.55835.240381.351382@mariner.uk.xensource.com>
	<2b60cfe7-2c97-45ef-bf89-88cd01cff1d3@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dan Magenheimer writes ("Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-pars> No, it doesn't.  I agree it *could* if parse_string is
> used/called differently.  The caller simply needs to
> ensure that the declared buffer is at least one larger
> than the data to be matched which is true for both
> callers.

Urgh.  So in the previous code the buffer was a byte too big ?

I think functions with prototypes like
     f(int len, char *buf)
should take buf[len], not buf[len+1].

> P.S. Please note that I am still not receiving email
> >from the xen-devel reflector (and am on vacation this
> week so probably won't be looking into it... my best
> guess is that the Oracle spam filter isn't happy with
> the new source of the xen-devel messages, as some
> other Oracle folk are having problems too).

Hrmm.  If this is still a problem when you get back please let me know.

ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:42:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:42:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeFe-00082T-AW; Thu, 24 Nov 2011 18:42:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeFc-00081a-PP
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:42:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322160113!4871124!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16791 invoked from network); 24 Nov 2011 18:41:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:41:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:41:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:41:46 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeEz-0007bJ-P2; Thu, 24 Nov 2011 18:41:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeEz-0004hD-OG;
	Thu, 24 Nov 2011 18:41:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.36841.738985.984736@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:41:45 +0000
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2b60cfe7-2c97-45ef-bf89-88cd01cff1d3@default>
References: <20171.55835.240381.351382@mariner.uk.xensource.com>
	<2b60cfe7-2c97-45ef-bf89-88cd01cff1d3@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dan Magenheimer writes ("Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-pars> No, it doesn't.  I agree it *could* if parse_string is
> used/called differently.  The caller simply needs to
> ensure that the declared buffer is at least one larger
> than the data to be matched which is true for both
> callers.

Urgh.  So in the previous code the buffer was a byte too big ?

I think functions with prototypes like
     f(int len, char *buf)
should take buf[len], not buf[len+1].

> P.S. Please note that I am still not receiving email
> >from the xen-devel reflector (and am on vacation this
> week so probably won't be looking into it... my best
> guess is that the Oracle spam filter isn't happy with
> the new source of the xen-devel messages, as some
> other Oracle folk are having problems too).

Hrmm.  If this is still a problem when you get back please let me know.

ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:44:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeHR-0008IX-TD; Thu, 24 Nov 2011 18:44:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeHP-0008Hq-Sa
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:44:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322160224!2924977!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5917 invoked from network); 24 Nov 2011 18:43:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:43:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119528"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:43:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:43:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeGs-0007by-TO; Thu, 24 Nov 2011 18:43:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeGs-0004hU-Sm;
	Thu, 24 Nov 2011 18:43:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.36958.880749.316596@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:43:42 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322041611.1005.14.camel@zakaz.uk.xensource.com>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
	<1322041611.1005.14.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jonathan Davies <Jonathan.Davies@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during	some
 hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] [OCaml] Release the global lock du> Which ones aren't? Either I'm grepping the wrong thing in xenctrl.h or
> it is documented somewhere else (OK, I admit it, there's a third, more
> likely, option...)

As an example, the migration calls aren't reentrant.  Not because of
clashes in the libxc data structures but because they do things to the
domain.  There are probably a few others but they're probably not
worth worrying about ...

> > As the main user of the ocaml bindings is xapi, can you confirm that
> > you've run this change through a good test of xapi (eg, the Citrix
> > XenRT suite) ?

... if the result passes a reasonable test suite.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:44:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeHR-0008IX-TD; Thu, 24 Nov 2011 18:44:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeHP-0008Hq-Sa
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:44:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322160224!2924977!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5917 invoked from network); 24 Nov 2011 18:43:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:43:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119528"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:43:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:43:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeGs-0007by-TO; Thu, 24 Nov 2011 18:43:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeGs-0004hU-Sm;
	Thu, 24 Nov 2011 18:43:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.36958.880749.316596@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:43:42 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322041611.1005.14.camel@zakaz.uk.xensource.com>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
	<1322041611.1005.14.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jonathan Davies <Jonathan.Davies@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during	some
 hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] [OCaml] Release the global lock du> Which ones aren't? Either I'm grepping the wrong thing in xenctrl.h or
> it is documented somewhere else (OK, I admit it, there's a third, more
> likely, option...)

As an example, the migration calls aren't reentrant.  Not because of
clashes in the libxc data structures but because they do things to the
domain.  There are probably a few others but they're probably not
worth worrying about ...

> > As the main user of the ocaml bindings is xapi, can you confirm that
> > you've run this change through a good test of xapi (eg, the Citrix
> > XenRT suite) ?

... if the result passes a reasonable test suite.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:47:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:47:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeKR-0000GF-Is; Thu, 24 Nov 2011 18:47:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeKQ-0000Fy-3x
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:47:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322160410!2907519!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11519 invoked from network); 24 Nov 2011 18:46:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:46:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119551"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:46:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:46:34 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeJe-0007ct-Fj; Thu, 24 Nov 2011 18:46:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeJe-0004he-F2;
	Thu, 24 Nov 2011 18:46:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.37130.453340.517982@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:46:34 +0000
To: Jonathan Davies <Jonathan.Davies@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CCE8682617CC8E4693CEF507039F8E86B59B2F52F4@LONPMAILBOX01.citrite.net>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
	<CCE8682617CC8E4693CEF507039F8E86B59B2F52F4@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock
	during	some	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jonathan Davies writes ("Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during some	hypercalls"):
> It hasn't yet gone through XenRT, although I've done some manual xapi stress testing in addition to some basic functional verification tests.
> 
> It sounds like you'd prefer it to go through XenRT before accepting it here. I'll do so, and then confirm if all is well.

I think that would be useful, if that's OK with you.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:47:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:47:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeKR-0000GF-Is; Thu, 24 Nov 2011 18:47:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeKQ-0000Fy-3x
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:47:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322160410!2907519!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11519 invoked from network); 24 Nov 2011 18:46:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:46:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119551"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:46:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:46:34 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeJe-0007ct-Fj; Thu, 24 Nov 2011 18:46:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeJe-0004he-F2;
	Thu, 24 Nov 2011 18:46:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.37130.453340.517982@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:46:34 +0000
To: Jonathan Davies <Jonathan.Davies@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CCE8682617CC8E4693CEF507039F8E86B59B2F52F4@LONPMAILBOX01.citrite.net>
References: <10758a9aa01ce39c4075.1321268775@localhost6.localdomain6>
	<20171.61030.71499.197458@mariner.uk.xensource.com>
	<CCE8682617CC8E4693CEF507039F8E86B59B2F52F4@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] [OCaml] Release the global lock
	during	some	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jonathan Davies writes ("Re: [Xen-devel] [PATCH] [OCaml] Release the global lock during some	hypercalls"):
> It hasn't yet gone through XenRT, although I've done some manual xapi stress testing in addition to some basic functional verification tests.
> 
> It sounds like you'd prefer it to go through XenRT before accepting it here. I'll do so, and then confirm if all is well.

I think that would be useful, if that's OK with you.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:50:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:50:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeN6-0000TB-71; Thu, 24 Nov 2011 18:50:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTeN4-0000Sy-GC
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:50:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322160537!47263044!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31614 invoked from network); 24 Nov 2011 18:48:58 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2011 18:48:58 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322160574; l=457;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=atVyjF+44qomUWQJavkDczcAhic=;
	b=kwrvIwQmkx7a0C27o0Ol0aw1hrJ8GiXEcFndTF9qdWjco4F/V3zGhhtwv7VrF8Okmd4
	b7JM05rQIVzo1TaPM0TrVN6UmvbglAvUJVJcmzWPbA3GDilD/KK7k17X+3iZTdObvyVqD
	GKr1TXd5XSBabf0xgHR73yW/Of93g9Lv3kA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (jimi mo23) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I03e57nAOI7iav ;
	Thu, 24 Nov 2011 19:49:18 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 9A89918637; Thu, 24 Nov 2011 19:49:17 +0100 (CET)
Date: Thu, 24 Nov 2011 19:49:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111124184917.GA25646@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
	<20174.36661.814563.526570@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20174.36661.814563.526570@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
 related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> > -CURSES_LIBS = -lncurses
> > +CURSES_LIBS = $(shell if ! ncurses5-config --libs 2>/dev/null ; then ncurses-config --libs ; fi)
> 
> In the case where ncurses5-config is not provided, this will fail.

It seems to work for me, with this example foo is printed:

if ! ABC 2>/dev/null ; then echo foo ; fi

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:50:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:50:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeN6-0000TB-71; Thu, 24 Nov 2011 18:50:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTeN4-0000Sy-GC
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:50:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322160537!47263044!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31614 invoked from network); 24 Nov 2011 18:48:58 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2011 18:48:58 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322160574; l=457;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=atVyjF+44qomUWQJavkDczcAhic=;
	b=kwrvIwQmkx7a0C27o0Ol0aw1hrJ8GiXEcFndTF9qdWjco4F/V3zGhhtwv7VrF8Okmd4
	b7JM05rQIVzo1TaPM0TrVN6UmvbglAvUJVJcmzWPbA3GDilD/KK7k17X+3iZTdObvyVqD
	GKr1TXd5XSBabf0xgHR73yW/Of93g9Lv3kA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (jimi mo23) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I03e57nAOI7iav ;
	Thu, 24 Nov 2011 19:49:18 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 9A89918637; Thu, 24 Nov 2011 19:49:17 +0100 (CET)
Date: Thu, 24 Nov 2011 19:49:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111124184917.GA25646@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
	<20174.36661.814563.526570@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20174.36661.814563.526570@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
 related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> > -CURSES_LIBS = -lncurses
> > +CURSES_LIBS = $(shell if ! ncurses5-config --libs 2>/dev/null ; then ncurses-config --libs ; fi)
> 
> In the case where ncurses5-config is not provided, this will fail.

It seems to work for me, with this example foo is printed:

if ! ABC 2>/dev/null ; then echo foo ; fi

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:51:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeNp-0000Wn-Lo; Thu, 24 Nov 2011 18:50:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RTeNn-0000W4-MA
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:50:51 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322160616!4506216!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2368 invoked from network); 24 Nov 2011 18:50:20 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:50:20 -0000
Received: by ggnr4 with SMTP id r4so4229456ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 10:50:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=DQitkA7FXKlrD2T75GoQzxW6Uq9VMiy07tUeAOEXrxg=;
	b=AqJuqyGWLhzFU+FvE6aK9ekjbedmYWttAXzd8DfIkaAK4DBdaqsL/htfGucrYUAx4Q
	x/D5ESMSO3CeKp/EIgqIJV4VyqtKo++vjmGoOxGmG9W4lmLviZTvsiGofbmbqPRK15L/
	ZFEMO9hwyZeDViitnse6/B24/3AjHeaIukYao=
Received: by 10.182.150.4 with SMTP id ue4mr9640333obb.74.1322160606136; Thu,
	24 Nov 2011 10:50:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.37.225 with HTTP; Thu, 24 Nov 2011 10:49:35 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111241816250.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-6-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.00.1111241816250.31179@kaball-desktop>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 24 Nov 2011 18:49:35 +0000
X-Google-Sender-Auth: 03z92CNGU9SCQc539pJelINZqic
Message-ID: <CAJJyHjL6pmt53GARCaV1QRC4Zam7uX6Huf_AON8ZZswmxt4YaQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 5/5] vga-cirrus: Workaround
 during restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBOb3YgMjQsIDIwMTEgYXQgMTg6MzAsIFN0ZWZhbm8gU3RhYmVsbGluaQo8c3RlZmFu
by5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+IHdyb3RlOgo+Cj4+IEBAIC0yNzg0LDkgKzI3OTYs
MTEgQEAgc3RhdGljIHZvaWQgY2lycnVzX3Jlc2V0KHZvaWQgKm9wYXF1ZSkKPj4gwqAgwqAgwqB9
Cj4+IMKgIMKgIMKgcy0+dmdhLmNyWzB4MjddID0gcy0+ZGV2aWNlX2lkOwo+Pgo+PiAtIMKgIMKg
LyogV2luMksgc2VlbXMgdG8gYXNzdW1lIHRoYXQgdGhlIHBhdHRlcm4gYnVmZmVyIGlzIGF0IDB4
ZmYKPj4gLSDCoCDCoCDCoCBpbml0aWFsbHkgISAqLwo+PiAtIMKgIMKgbWVtc2V0KHMtPnZnYS52
cmFtX3B0ciwgMHhmZiwgcy0+cmVhbF92cmFtX3NpemUpOwo+PiArIMKgIMKgaWYgKCFydW5zdGF0
ZV9jaGVjayhSVU5fU1RBVEVfUFJFTUlHUkFURSkpIHsKPj4gKyDCoCDCoCDCoCDCoC8qIFdpbjJL
IHNlZW1zIHRvIGFzc3VtZSB0aGF0IHRoZSBwYXR0ZXJuIGJ1ZmZlciBpcyBhdCAweGZmCj4+ICsg
wqAgwqAgwqAgwqAgwqAgaW5pdGlhbGx5ICEgKi8KPj4gKyDCoCDCoCDCoCDCoG1lbXNldChzLT52
Z2EudnJhbV9wdHIsIDB4ZmYsIHMtPnJlYWxfdnJhbV9zaXplKTsKPj4gKyDCoCDCoH0KPj4KPgo+
IHRoaXMgaXMgbm90IHRvbyBiYWQsIEkgc3VwcG9zZSB0aGF0IHRoZSB2aWRlb3JhbSBpcyBnb2lu
ZyB0byBiZSB3cml0dGVuCj4gYWdhaW4gYXQgcmVzdG9yZSB0aW1lIGFueXdheSBzbyBhdCBsZWFz
dCBpdCBzYXZlcyBzb21lIGN5Y2xlcwoKQWN0dWFsbHksIEkgdGhpbmsgdGhlIG5leHQgdGltZSB0
aGF0IHRoaXMgdnJhbSB3aWxsIGJlIHdyaXR0ZW4gYWdhaW4KaXMsIHdoZW4gdGhlIGd1ZXN0IGlz
IGFjdHVhbGx5ICJ3YWtlZC11cCIgYW5kIHdyb3RlIHNvbWV0aGluZyB0aGVyZS4KT3RoZXJ3aXNl
LCB0aGUgInJlc3RvcmUiIG9mIHRoZSB2cmFtIGlzIGRvbmUgYmVmb3JlIFFFTVUgc3RhcnQuIFNv
LAp0aGUgbWVtc2V0IGNvdWxkIGxlYXZlIHNvbWUgd2VhcmQgc3R1ZmYgdGhlIHNjcmVlbiAoYSB3
aGl0ZSBzY3JlZW4/KS4KCi0tIApBbnRob255IFBFUkFSRAoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:51:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeNp-0000Wn-Lo; Thu, 24 Nov 2011 18:50:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RTeNn-0000W4-MA
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:50:51 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322160616!4506216!1
X-Originating-IP: [209.85.161.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2368 invoked from network); 24 Nov 2011 18:50:20 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:50:20 -0000
Received: by ggnr4 with SMTP id r4so4229456ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 10:50:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=DQitkA7FXKlrD2T75GoQzxW6Uq9VMiy07tUeAOEXrxg=;
	b=AqJuqyGWLhzFU+FvE6aK9ekjbedmYWttAXzd8DfIkaAK4DBdaqsL/htfGucrYUAx4Q
	x/D5ESMSO3CeKp/EIgqIJV4VyqtKo++vjmGoOxGmG9W4lmLviZTvsiGofbmbqPRK15L/
	ZFEMO9hwyZeDViitnse6/B24/3AjHeaIukYao=
Received: by 10.182.150.4 with SMTP id ue4mr9640333obb.74.1322160606136; Thu,
	24 Nov 2011 10:50:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.37.225 with HTTP; Thu, 24 Nov 2011 10:49:35 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111241816250.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-6-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.00.1111241816250.31179@kaball-desktop>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 24 Nov 2011 18:49:35 +0000
X-Google-Sender-Auth: 03z92CNGU9SCQc539pJelINZqic
Message-ID: <CAJJyHjL6pmt53GARCaV1QRC4Zam7uX6Huf_AON8ZZswmxt4YaQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 5/5] vga-cirrus: Workaround
 during restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBOb3YgMjQsIDIwMTEgYXQgMTg6MzAsIFN0ZWZhbm8gU3RhYmVsbGluaQo8c3RlZmFu
by5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+IHdyb3RlOgo+Cj4+IEBAIC0yNzg0LDkgKzI3OTYs
MTEgQEAgc3RhdGljIHZvaWQgY2lycnVzX3Jlc2V0KHZvaWQgKm9wYXF1ZSkKPj4gwqAgwqAgwqB9
Cj4+IMKgIMKgIMKgcy0+dmdhLmNyWzB4MjddID0gcy0+ZGV2aWNlX2lkOwo+Pgo+PiAtIMKgIMKg
LyogV2luMksgc2VlbXMgdG8gYXNzdW1lIHRoYXQgdGhlIHBhdHRlcm4gYnVmZmVyIGlzIGF0IDB4
ZmYKPj4gLSDCoCDCoCDCoCBpbml0aWFsbHkgISAqLwo+PiAtIMKgIMKgbWVtc2V0KHMtPnZnYS52
cmFtX3B0ciwgMHhmZiwgcy0+cmVhbF92cmFtX3NpemUpOwo+PiArIMKgIMKgaWYgKCFydW5zdGF0
ZV9jaGVjayhSVU5fU1RBVEVfUFJFTUlHUkFURSkpIHsKPj4gKyDCoCDCoCDCoCDCoC8qIFdpbjJL
IHNlZW1zIHRvIGFzc3VtZSB0aGF0IHRoZSBwYXR0ZXJuIGJ1ZmZlciBpcyBhdCAweGZmCj4+ICsg
wqAgwqAgwqAgwqAgwqAgaW5pdGlhbGx5ICEgKi8KPj4gKyDCoCDCoCDCoCDCoG1lbXNldChzLT52
Z2EudnJhbV9wdHIsIDB4ZmYsIHMtPnJlYWxfdnJhbV9zaXplKTsKPj4gKyDCoCDCoH0KPj4KPgo+
IHRoaXMgaXMgbm90IHRvbyBiYWQsIEkgc3VwcG9zZSB0aGF0IHRoZSB2aWRlb3JhbSBpcyBnb2lu
ZyB0byBiZSB3cml0dGVuCj4gYWdhaW4gYXQgcmVzdG9yZSB0aW1lIGFueXdheSBzbyBhdCBsZWFz
dCBpdCBzYXZlcyBzb21lIGN5Y2xlcwoKQWN0dWFsbHksIEkgdGhpbmsgdGhlIG5leHQgdGltZSB0
aGF0IHRoaXMgdnJhbSB3aWxsIGJlIHdyaXR0ZW4gYWdhaW4KaXMsIHdoZW4gdGhlIGd1ZXN0IGlz
IGFjdHVhbGx5ICJ3YWtlZC11cCIgYW5kIHdyb3RlIHNvbWV0aGluZyB0aGVyZS4KT3RoZXJ3aXNl
LCB0aGUgInJlc3RvcmUiIG9mIHRoZSB2cmFtIGlzIGRvbmUgYmVmb3JlIFFFTVUgc3RhcnQuIFNv
LAp0aGUgbWVtc2V0IGNvdWxkIGxlYXZlIHNvbWUgd2VhcmQgc3R1ZmYgdGhlIHNjcmVlbiAoYSB3
aGl0ZSBzY3JlZW4/KS4KCi0tIApBbnRob255IFBFUkFSRAoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:53:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeQW-0000kX-9r; Thu, 24 Nov 2011 18:53:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeQU-0000k2-OC
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:53:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322160786!4832943!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23308 invoked from network); 24 Nov 2011 18:53:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:53:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:53:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:53:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTePy-0007fH-D4; Thu, 24 Nov 2011 18:53:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTePy-0004in-Bf;
	Thu, 24 Nov 2011 18:53:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.37522.349763.828592@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:53:06 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111124184917.GA25646@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
	<20174.36661.814563.526570@mariner.uk.xensource.com>
	<20111124184917.GA25646@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
 related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("Re: [Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> On Thu, Nov 24, Ian Jackson wrote:
> > Olaf Hering writes ("[Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> > > -CURSES_LIBS = -lncurses
> > > +CURSES_LIBS = $(shell if ! ncurses5-config --libs 2>/dev/null ; then ncurses-config --libs ; fi)
> > 
> > In the case where ncurses5-config is not provided, this will fail.

Sorry, I wasn't sufficiently clear.  The case that fails is if neither
ncurses5-config nor ncurses-config is provided.  The default should be
to use -lncurses as before.

> It seems to work for me, with this example foo is printed:
> 
> if ! ABC 2>/dev/null ; then echo foo ; fi

Yes, but it won't include -lncurses in CURSES_LIBS.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:53:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeQW-0000kX-9r; Thu, 24 Nov 2011 18:53:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeQU-0000k2-OC
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:53:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322160786!4832943!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23308 invoked from network); 24 Nov 2011 18:53:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:53:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:53:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:53:06 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTePy-0007fH-D4; Thu, 24 Nov 2011 18:53:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTePy-0004in-Bf;
	Thu, 24 Nov 2011 18:53:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.37522.349763.828592@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:53:06 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111124184917.GA25646@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
	<20174.36661.814563.526570@mariner.uk.xensource.com>
	<20111124184917.GA25646@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
 related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("Re: [Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> On Thu, Nov 24, Ian Jackson wrote:
> > Olaf Hering writes ("[Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> > > -CURSES_LIBS = -lncurses
> > > +CURSES_LIBS = $(shell if ! ncurses5-config --libs 2>/dev/null ; then ncurses-config --libs ; fi)
> > 
> > In the case where ncurses5-config is not provided, this will fail.

Sorry, I wasn't sufficiently clear.  The case that fails is if neither
ncurses5-config nor ncurses-config is provided.  The default should be
to use -lncurses as before.

> It seems to work for me, with this example foo is printed:
> 
> if ! ABC 2>/dev/null ; then echo foo ; fi

Yes, but it won't include -lncurses in CURSES_LIBS.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:54:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeQj-0000mS-Ne; Thu, 24 Nov 2011 18:53:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeQi-0000mB-II
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:53:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322160777!49829568!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31471 invoked from network); 24 Nov 2011 18:52:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:52:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:53:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:53:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeQH-0007fS-Rj; Thu, 24 Nov 2011 18:53:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeQH-0004ix-R7;
	Thu, 24 Nov 2011 18:53:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.37541.829455.368699@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:53:25 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4ECCFC01.9000700@amd.com>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4ECCFC01.9000700@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, keir@xen.org, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v9 1/6] Introduce git-checkout.sh
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("Re: [Xen-devel] [PATCH v9 1/6] Introduce git-checkout.sh"):
> On 11/23/11 14:51, stefano.stabellini@eu.citrix.com wrote:
> > +		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \
> 
> When you use $(SHELL) then we do not need to care about the execute bit:
> 
> +		$(SHELL) $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) 
> $(QEMU_TAG) ioemu-dir; \

I'm afraid I don't agree with this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:54:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:54:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeQj-0000mS-Ne; Thu, 24 Nov 2011 18:53:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeQi-0000mB-II
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:53:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322160777!49829568!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31471 invoked from network); 24 Nov 2011 18:52:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:52:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:53:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:53:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeQH-0007fS-Rj; Thu, 24 Nov 2011 18:53:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeQH-0004ix-R7;
	Thu, 24 Nov 2011 18:53:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.37541.829455.368699@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:53:25 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4ECCFC01.9000700@amd.com>
References: <alpine.DEB.2.00.1111221551510.31179@kaball-desktop>
	<1322056320-5826-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4ECCFC01.9000700@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, keir@xen.org, Ian.Campbell@citrix.com,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH v9 1/6] Introduce git-checkout.sh
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("Re: [Xen-devel] [PATCH v9 1/6] Introduce git-checkout.sh"):
> On 11/23/11 14:51, stefano.stabellini@eu.citrix.com wrote:
> > +		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \
> 
> When you use $(SHELL) then we do not need to care about the execute bit:
> 
> +		$(SHELL) $(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) 
> $(QEMU_TAG) ioemu-dir; \

I'm afraid I don't agree with this.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:55:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:55:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeS2-0000xj-9c; Thu, 24 Nov 2011 18:55:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTeS0-0000xS-Fi
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:55:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322160848!47263487!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7156 invoked from network); 24 Nov 2011 18:54:08 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-3.tower-27.messagelabs.com with SMTP;
	24 Nov 2011 18:54:08 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id DC6AC300064;
	Thu, 24 Nov 2011 10:54:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=hX66BZWAAXxK1KjS9oRTBMcMCmwqH679EoGU6grvcP7A
	L4iArgJmQODhTZfbeUd+qwvw5KmI7PZ5ZA9a/Aje9qVrtu+RCtO9z81LrHmQdLgx
	eW1pOAoSfSEzBccumyRiILHkyx6OaHib69KXjoXrEwab/D6XEIMYqr9HRTtkD5A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=HYXOWViZt8NMlaOK+uhnvl+hTKU=; b=intX6YPP
	iQHStPNXerRQ3K2jXUimN6jLwz8eKu/iXgAGzq8ZksH3NAPdd27WlE4PQgtqDXPw
	4z1J2Q/IiNOhrdM1wojldxoZtgY24XrWitLduNaWYOH9xWkpq4aci7i9iL7xbiXU
	nr6XM9dbnX4gSVcktZA5v+RS3AermUNYK4c=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 827ED300061; 
	Thu, 24 Nov 2011 10:54:44 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 10:54:44 -0800
Message-ID: <ec591bf57167a6212502a1eca68d2334.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111123185728.GA27583@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
	<20111123183511.GA26144@aepfle.de>
	<d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
	<20111123185728.GA27583@aepfle.de>
Date: Thu, 24 Nov 2011 10:54:44 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, Nov 23, Andres Lagar-Cavilla wrote:
>
>> Well, we can tone down printk's to be debug level. I don't think they're
>> unnecessary if they're made an optional debug tool.
>
> There is nothing to debug here, since the callers have to retry anyway.
>
>> Question: I have one vcpu, how do I fill up the ring quickly? (outside
>> of
>> foreign mappings)
>
> Have a balloon driver in the guest and balloon down more than
> 64*PAGE_SIZE. This is the default at least in my setup where the kernel
> driver releases some memory right away (I havent checked where this is
> actually configured).

I see, a guest can call decrease_reservation with an extent_order large
enough that it will overflow the ring. No matter the size of the ring.
Isn't preemption of this hypercall a better tactic than putting the vcpu
on a wait-queue? This won't preclude the need for wait queues, but it
feels like a much cleaner solution.

With retrying of foreign mappings in xc_map_foreign_bulk (and grants), I
wonder if we should put events in the ring due to foreign mappings *at
all*, in the case of congestion. Eventually a retry will get to kick the
pager.

Andres

>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:55:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:55:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeS2-0000xj-9c; Thu, 24 Nov 2011 18:55:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTeS0-0000xS-Fi
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:55:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322160848!47263487!1
X-Originating-IP: [208.97.132.5]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7156 invoked from network); 24 Nov 2011 18:54:08 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-3.tower-27.messagelabs.com with SMTP;
	24 Nov 2011 18:54:08 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id DC6AC300064;
	Thu, 24 Nov 2011 10:54:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=hX66BZWAAXxK1KjS9oRTBMcMCmwqH679EoGU6grvcP7A
	L4iArgJmQODhTZfbeUd+qwvw5KmI7PZ5ZA9a/Aje9qVrtu+RCtO9z81LrHmQdLgx
	eW1pOAoSfSEzBccumyRiILHkyx6OaHib69KXjoXrEwab/D6XEIMYqr9HRTtkD5A=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=HYXOWViZt8NMlaOK+uhnvl+hTKU=; b=intX6YPP
	iQHStPNXerRQ3K2jXUimN6jLwz8eKu/iXgAGzq8ZksH3NAPdd27WlE4PQgtqDXPw
	4z1J2Q/IiNOhrdM1wojldxoZtgY24XrWitLduNaWYOH9xWkpq4aci7i9iL7xbiXU
	nr6XM9dbnX4gSVcktZA5v+RS3AermUNYK4c=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 827ED300061; 
	Thu, 24 Nov 2011 10:54:44 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 10:54:44 -0800
Message-ID: <ec591bf57167a6212502a1eca68d2334.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111123185728.GA27583@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
	<20111123183511.GA26144@aepfle.de>
	<d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
	<20111123185728.GA27583@aepfle.de>
Date: Thu, 24 Nov 2011 10:54:44 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, Nov 23, Andres Lagar-Cavilla wrote:
>
>> Well, we can tone down printk's to be debug level. I don't think they're
>> unnecessary if they're made an optional debug tool.
>
> There is nothing to debug here, since the callers have to retry anyway.
>
>> Question: I have one vcpu, how do I fill up the ring quickly? (outside
>> of
>> foreign mappings)
>
> Have a balloon driver in the guest and balloon down more than
> 64*PAGE_SIZE. This is the default at least in my setup where the kernel
> driver releases some memory right away (I havent checked where this is
> actually configured).

I see, a guest can call decrease_reservation with an extent_order large
enough that it will overflow the ring. No matter the size of the ring.
Isn't preemption of this hypercall a better tactic than putting the vcpu
on a wait-queue? This won't preclude the need for wait queues, but it
feels like a much cleaner solution.

With retrying of foreign mappings in xc_map_foreign_bulk (and grants), I
wonder if we should put events in the ring due to foreign mappings *at
all*, in the case of congestion. Eventually a retry will get to kick the
pager.

Andres

>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:57:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:57:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeU7-0001Em-T4; Thu, 24 Nov 2011 18:57:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeU6-0001Dz-Sg
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:57:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322161011!4882671!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15712 invoked from network); 24 Nov 2011 18:56:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:56:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119622"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:56:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:56:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeTa-0007gW-TF; Thu, 24 Nov 2011 18:56:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeTa-0004jD-SZ;
	Thu, 24 Nov 2011 18:56:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.37746.873433.6131@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:56:50 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com
Subject: Re: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype
	for	pt_pci_host_read/write
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jean Guyader writes ("[Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for pt_pci_host_read/write"):
> pt_pci_host_read/write now takes a struct pci_dev*.

Why ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 18:57:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 18:57:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeU7-0001Em-T4; Thu, 24 Nov 2011 18:57:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeU6-0001Dz-Sg
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 18:57:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322161011!4882671!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15712 invoked from network); 24 Nov 2011 18:56:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 18:56:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119622"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 18:56:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 18:56:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeTa-0007gW-TF; Thu, 24 Nov 2011 18:56:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeTa-0004jD-SZ;
	Thu, 24 Nov 2011 18:56:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.37746.873433.6131@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 18:56:50 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com
Subject: Re: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype
	for	pt_pci_host_read/write
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jean Guyader writes ("[Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for pt_pci_host_read/write"):
> pt_pci_host_read/write now takes a struct pci_dev*.

Why ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:10:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTegy-0001f4-Hw; Thu, 24 Nov 2011 19:10:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTegw-0001ez-I8
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:10:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322161807!6208321!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2517 invoked from network); 24 Nov 2011 19:10:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 19:10:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 19:10:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 19:10:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTegQ-0007lT-Ok; Thu, 24 Nov 2011 19:10:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTegQ-0003zR-IS;
	Thu, 24 Nov 2011 19:10:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.38542.532288.785789@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 19:10:06 +0000
To: Anil Madhavapeddy <anil@recoil.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111123161412.GA26454@dark.recoil.org>
References: <20111123161412.GA26454@dark.recoil.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] fix segfault in libvchan client error path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anil Madhavapeddy writes ("[Xen-devel] [PATCH] fix segfault in libvchan client error path"):
> In libvchan_client_init, go to the error path if the gntdev device is not
> available.  Otherwise, a segfault happens later as the vchan context is
> invalid.
> 
> Signed-off-by: Anil Madhavapeddy <anil@recoil.org>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:10:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:10:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTegy-0001f4-Hw; Thu, 24 Nov 2011 19:10:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTegw-0001ez-I8
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:10:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322161807!6208321!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2517 invoked from network); 24 Nov 2011 19:10:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 19:10:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 19:10:07 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 19:10:07 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTegQ-0007lT-Ok; Thu, 24 Nov 2011 19:10:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTegQ-0003zR-IS;
	Thu, 24 Nov 2011 19:10:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.38542.532288.785789@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 19:10:06 +0000
To: Anil Madhavapeddy <anil@recoil.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111123161412.GA26454@dark.recoil.org>
References: <20111123161412.GA26454@dark.recoil.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] fix segfault in libvchan client error path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anil Madhavapeddy writes ("[Xen-devel] [PATCH] fix segfault in libvchan client error path"):
> In libvchan_client_init, go to the error path if the gntdev device is not
> available.  Otherwise, a segfault happens later as the vchan context is
> invalid.
> 
> Signed-off-by: Anil Madhavapeddy <anil@recoil.org>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:15:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:15:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeli-00024F-RX; Thu, 24 Nov 2011 19:15:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTelh-000249-2k
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:15:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322162063!58165504!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10064 invoked from network); 24 Nov 2011 19:14:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Nov 2011 19:14:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322162106; l=1134;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=6/CBcNC3tShEuX+xmSSHzeFQXjA=;
	b=k9JMHcCq99pOwyzAf5RwJ01htFOP6FNSjwcq6Yz/R3w/tn90uJYtAty4qLCR21T6KS9
	35Z9ixBJQ96fDCDS/PXdgrpwJK6l0SpPnhjkHPliirL6oklJLFMZlZ9lR2iolubRbSmIv
	D8UhK1DnSPC7Lqt2tjy6MlK62U9Axm+Sbl0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (fruni mo11) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 005356nAOICopW ;
	Thu, 24 Nov 2011 20:15:03 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A28AA18637; Thu, 24 Nov 2011 20:15:02 +0100 (CET)
Date: Thu, 24 Nov 2011 20:15:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111124191502.GA25881@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
	<20174.36661.814563.526570@mariner.uk.xensource.com>
	<20111124184917.GA25646@aepfle.de>
	<20174.37522.349763.828592@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20174.37522.349763.828592@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
 related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Ian Jackson wrote:

> Olaf Hering writes ("Re: [Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> > On Thu, Nov 24, Ian Jackson wrote:
> > > Olaf Hering writes ("[Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> > > > -CURSES_LIBS = -lncurses
> > > > +CURSES_LIBS = $(shell if ! ncurses5-config --libs 2>/dev/null ; then ncurses-config --libs ; fi)
> > > 
> > > In the case where ncurses5-config is not provided, this will fail.
> 
> Sorry, I wasn't sufficiently clear.  The case that fails is if neither
> ncurses5-config nor ncurses-config is provided.  The default should be
> to use -lncurses as before.

I see. Another if construct, or a check_ncurses script which looks for
ncurses5-config or ncurses-config. After some digging in old SuSE
releases, ncurses5-config appeared in 11.0 (2008), SLES10 does not have
it yes . So blindly relying on -config scripts will likely break
building on old distributions.

This should work:

if ! ncurses5-config --libs 2>/dev/null;then if ! ncurses-config --libs ; then echo '-lncurses' ; fi ; fi

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:15:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:15:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeli-00024F-RX; Thu, 24 Nov 2011 19:15:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTelh-000249-2k
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:15:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322162063!58165504!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10064 invoked from network); 24 Nov 2011 19:14:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Nov 2011 19:14:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322162106; l=1134;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=6/CBcNC3tShEuX+xmSSHzeFQXjA=;
	b=k9JMHcCq99pOwyzAf5RwJ01htFOP6FNSjwcq6Yz/R3w/tn90uJYtAty4qLCR21T6KS9
	35Z9ixBJQ96fDCDS/PXdgrpwJK6l0SpPnhjkHPliirL6oklJLFMZlZ9lR2iolubRbSmIv
	D8UhK1DnSPC7Lqt2tjy6MlK62U9Axm+Sbl0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (fruni mo11) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 005356nAOICopW ;
	Thu, 24 Nov 2011 20:15:03 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A28AA18637; Thu, 24 Nov 2011 20:15:02 +0100 (CET)
Date: Thu, 24 Nov 2011 20:15:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111124191502.GA25881@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
	<20174.36661.814563.526570@mariner.uk.xensource.com>
	<20111124184917.GA25646@aepfle.de>
	<20174.37522.349763.828592@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20174.37522.349763.828592@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
 related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Ian Jackson wrote:

> Olaf Hering writes ("Re: [Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> > On Thu, Nov 24, Ian Jackson wrote:
> > > Olaf Hering writes ("[Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> > > > -CURSES_LIBS = -lncurses
> > > > +CURSES_LIBS = $(shell if ! ncurses5-config --libs 2>/dev/null ; then ncurses-config --libs ; fi)
> > > 
> > > In the case where ncurses5-config is not provided, this will fail.
> 
> Sorry, I wasn't sufficiently clear.  The case that fails is if neither
> ncurses5-config nor ncurses-config is provided.  The default should be
> to use -lncurses as before.

I see. Another if construct, or a check_ncurses script which looks for
ncurses5-config or ncurses-config. After some digging in old SuSE
releases, ncurses5-config appeared in 11.0 (2008), SLES10 does not have
it yes . So blindly relying on -config scripts will likely break
building on old distributions.

This should work:

if ! ncurses5-config --libs 2>/dev/null;then if ! ncurses-config --libs ; then echo '-lncurses' ; fi ; fi

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:21:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:21:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeql-0002EV-JP; Thu, 24 Nov 2011 19:20:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeqk-0002EM-Lb
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:20:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322162414!5633221!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2346 invoked from network); 24 Nov 2011 19:20:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 19:20:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 19:20:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 19:20:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeqD-0007pJ-7q; Thu, 24 Nov 2011 19:20:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeqD-0001G9-6y;
	Thu, 24 Nov 2011 19:20:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.39148.582161.596738@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 19:20:12 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111124191502.GA25881@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
	<20174.36661.814563.526570@mariner.uk.xensource.com>
	<20111124184917.GA25646@aepfle.de>
	<20174.37522.349763.828592@mariner.uk.xensource.com>
	<20111124191502.GA25881@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
 related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("Re: [Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> This should work:
> 
> if ! ncurses5-config --libs 2>/dev/null;then if ! ncurses-config --libs ; then echo '-lncurses' ; fi ; fi

That's an improvement, but it reruns the shell rune for every time
CURSES_LIBS is expanded.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:21:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:21:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeql-0002EV-JP; Thu, 24 Nov 2011 19:20:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTeqk-0002EM-Lb
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:20:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322162414!5633221!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2346 invoked from network); 24 Nov 2011 19:20:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 19:20:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 19:20:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 19:20:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTeqD-0007pJ-7q; Thu, 24 Nov 2011 19:20:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTeqD-0001G9-6y;
	Thu, 24 Nov 2011 19:20:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.39148.582161.596738@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 19:20:12 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111124191502.GA25881@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
	<20174.36661.814563.526570@mariner.uk.xensource.com>
	<20111124184917.GA25646@aepfle.de>
	<20174.37522.349763.828592@mariner.uk.xensource.com>
	<20111124191502.GA25881@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
 related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("Re: [Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> This should work:
> 
> if ! ncurses5-config --libs 2>/dev/null;then if ! ncurses-config --libs ; then echo '-lncurses' ; fi ; fi

That's an improvement, but it reruns the shell rune for every time
CURSES_LIBS is expanded.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:23:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:23:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTesw-0002Kl-5g; Thu, 24 Nov 2011 19:23:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTesu-0002KJ-K2
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:23:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322162548!5672977!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25710 invoked from network); 24 Nov 2011 19:22:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 19:22:29 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 19:22:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 19:22:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTesO-0007q6-Cl; Thu, 24 Nov 2011 19:22:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTesO-0006aS-B9;
	Thu, 24 Nov 2011 19:22:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.39284.171056.419712@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 19:22:28 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 20] tools/xenpaging changes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH 00 of 20] tools/xenpaging changes"):
> The following changes contains non-controversial changes for xenpaging.
> They were sent out twice earlier already.

Thanks.  Sorry for the delay.  I have been very busy moving all the
Xen.org services out of our old colo; that task suddenly became
critical and unfortunately members of the Xen.org team including
myself had to pick it up.  So sorry to you and to everyone else who
has been waiting for patches to go in.

I have been catching up on the list in the past few days and applying
small and obvious patches.  With the larger series I have been waiting
until I was fully caught up, to avoid applying superseded versions,
etc.

Anyway, I have now applied all 20 of your patches.

To others who are waiting: I hope to start clearing the larger queues
from the backlog over the next few days.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:23:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:23:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTesw-0002Kl-5g; Thu, 24 Nov 2011 19:23:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTesu-0002KJ-K2
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:23:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322162548!5672977!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25710 invoked from network); 24 Nov 2011 19:22:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 19:22:29 -0000
X-IronPort-AV: E=Sophos;i="4.69,566,1315180800"; 
   d="scan'208";a="9119914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 19:22:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 19:22:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTesO-0007q6-Cl; Thu, 24 Nov 2011 19:22:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTesO-0006aS-B9;
	Thu, 24 Nov 2011 19:22:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20174.39284.171056.419712@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 19:22:28 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1321814045@probook.site>
References: <patchbomb.1321814045@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 00 of 20] tools/xenpaging changes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH 00 of 20] tools/xenpaging changes"):
> The following changes contains non-controversial changes for xenpaging.
> They were sent out twice earlier already.

Thanks.  Sorry for the delay.  I have been very busy moving all the
Xen.org services out of our old colo; that task suddenly became
critical and unfortunately members of the Xen.org team including
myself had to pick it up.  So sorry to you and to everyone else who
has been waiting for patches to go in.

I have been catching up on the list in the past few days and applying
small and obvious patches.  With the larger series I have been waiting
until I was fully caught up, to avoid applying superseded versions,
etc.

Anyway, I have now applied all 20 of your patches.

To others who are waiting: I hope to start clearing the larger queues
from the backlog over the next few days.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:24:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:24:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeuB-0002Qv-Lr; Thu, 24 Nov 2011 19:24:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTeu9-0002QF-Md
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:24:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322162626!4864919!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24948 invoked from network); 24 Nov 2011 19:23:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Nov 2011 19:23:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322162626; l=1512;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=7XjRpigKFZO1I00n/bekAwxA4sI=;
	b=ygDVTa0Ou/0eOwreMNbSGazkow3Ma5pRQB44l4AB+Zev4WpAet0c8yQqIz+Lje72D8F
	wC7iqKkGWVPOS4203Ng17zR9XwkQU8NBDgCf883gWCqqy/Sjml9cWhpN2fVjXN+ghuaub
	8dSIc5/PDVeDHajS2GWkf7TepWuVbeVnkDo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by post.strato.de (mrclete mo46) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id D02b92nAOHL1FA ;
	Thu, 24 Nov 2011 20:23:35 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D580018637; Thu, 24 Nov 2011 20:23:34 +0100 (CET)
Date: Thu, 24 Nov 2011 20:23:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124192334.GA26208@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
	<20111123183511.GA26144@aepfle.de>
	<d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
	<20111123185728.GA27583@aepfle.de>
	<ec591bf57167a6212502a1eca68d2334.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ec591bf57167a6212502a1eca68d2334.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Andres Lagar-Cavilla wrote:

> > On Wed, Nov 23, Andres Lagar-Cavilla wrote:
> >
> >> Well, we can tone down printk's to be debug level. I don't think they're
> >> unnecessary if they're made an optional debug tool.
> >
> > There is nothing to debug here, since the callers have to retry anyway.
> >
> >> Question: I have one vcpu, how do I fill up the ring quickly? (outside
> >> of
> >> foreign mappings)
> >
> > Have a balloon driver in the guest and balloon down more than
> > 64*PAGE_SIZE. This is the default at least in my setup where the kernel
> > driver releases some memory right away (I havent checked where this is
> > actually configured).
> 
> I see, a guest can call decrease_reservation with an extent_order large
> enough that it will overflow the ring. No matter the size of the ring.
> Isn't preemption of this hypercall a better tactic than putting the vcpu
> on a wait-queue? This won't preclude the need for wait queues, but it
> feels like a much cleaner solution.

Yes, yesterday I was thinking about this as well.
p2m_mem_paging_drop_page() should return -EBUSY. But currently not all
callers of guest_remove_page() look at the exit code. Perhaps that can
be fixed.

> With retrying of foreign mappings in xc_map_foreign_bulk (and grants), I
> wonder if we should put events in the ring due to foreign mappings *at
> all*, in the case of congestion. Eventually a retry will get to kick the
> pager.

What do you mean with that?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:24:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:24:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTeuB-0002Qv-Lr; Thu, 24 Nov 2011 19:24:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTeu9-0002QF-Md
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:24:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322162626!4864919!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24948 invoked from network); 24 Nov 2011 19:23:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 24 Nov 2011 19:23:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322162626; l=1512;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=7XjRpigKFZO1I00n/bekAwxA4sI=;
	b=ygDVTa0Ou/0eOwreMNbSGazkow3Ma5pRQB44l4AB+Zev4WpAet0c8yQqIz+Lje72D8F
	wC7iqKkGWVPOS4203Ng17zR9XwkQU8NBDgCf883gWCqqy/Sjml9cWhpN2fVjXN+ghuaub
	8dSIc5/PDVeDHajS2GWkf7TepWuVbeVnkDo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by post.strato.de (mrclete mo46) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id D02b92nAOHL1FA ;
	Thu, 24 Nov 2011 20:23:35 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D580018637; Thu, 24 Nov 2011 20:23:34 +0100 (CET)
Date: Thu, 24 Nov 2011 20:23:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111124192334.GA26208@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
	<20111123183511.GA26144@aepfle.de>
	<d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
	<20111123185728.GA27583@aepfle.de>
	<ec591bf57167a6212502a1eca68d2334.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ec591bf57167a6212502a1eca68d2334.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Andres Lagar-Cavilla wrote:

> > On Wed, Nov 23, Andres Lagar-Cavilla wrote:
> >
> >> Well, we can tone down printk's to be debug level. I don't think they're
> >> unnecessary if they're made an optional debug tool.
> >
> > There is nothing to debug here, since the callers have to retry anyway.
> >
> >> Question: I have one vcpu, how do I fill up the ring quickly? (outside
> >> of
> >> foreign mappings)
> >
> > Have a balloon driver in the guest and balloon down more than
> > 64*PAGE_SIZE. This is the default at least in my setup where the kernel
> > driver releases some memory right away (I havent checked where this is
> > actually configured).
> 
> I see, a guest can call decrease_reservation with an extent_order large
> enough that it will overflow the ring. No matter the size of the ring.
> Isn't preemption of this hypercall a better tactic than putting the vcpu
> on a wait-queue? This won't preclude the need for wait queues, but it
> feels like a much cleaner solution.

Yes, yesterday I was thinking about this as well.
p2m_mem_paging_drop_page() should return -EBUSY. But currently not all
callers of guest_remove_page() look at the exit code. Perhaps that can
be fixed.

> With retrying of foreign mappings in xc_map_foreign_bulk (and grants), I
> wonder if we should put events in the ring due to foreign mappings *at
> all*, in the case of congestion. Eventually a retry will get to kick the
> pager.

What do you mean with that?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:36:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTf5o-0002sq-TF; Thu, 24 Nov 2011 19:36:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTf5n-0002si-DW
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:36:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322163347!4874991!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21898 invoked from network); 24 Nov 2011 19:35:47 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-15.tower-216.messagelabs.com with SMTP;
	24 Nov 2011 19:35:47 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 074DF60407C;
	Thu, 24 Nov 2011 11:35:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=XyVfbsfz7bh6Y5ue2O0co8TU7eLdQtgO/SrwFvuCNske
	1iHDf4btma5oOuCcUG7NDyeh1Qq5Lr/upoWgfScMPWp0dvJ8oKnzo9kILEx/fPEG
	7hQPJBm1+SMQirNOZOGnmhxGgr4K5xINbEiodNFpS53nLfhGBZJwFXVTxAbPGQ0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=y8nKENX9WYwiSzKn5QLdoipVbaA=; b=WOcypLT2
	6Vtn9AKHE6mTsIoA60g22b+Kewjw1bzEINmcYq31omtBfjwVm09Db2S28XZvC2rC
	iOPUFkwu8sZxtIncWGNNn7ZJU2Gjrrtj38fFQ2CLBURNS+CD6s0Ydn4euoSJSG6Q
	vewOyfUrvdrylw0cOK4GaNmg2WLX01ZzUX4=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 91BE6604079; 
	Thu, 24 Nov 2011 11:35:46 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 11:35:47 -0800
Message-ID: <593e94781b4c0b04c2c97e105caa3a50.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124192334.GA26208@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
	<20111123183511.GA26144@aepfle.de>
	<d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
	<20111123185728.GA27583@aepfle.de>
	<ec591bf57167a6212502a1eca68d2334.squirrel@webmail.lagarcavilla.org>
	<20111124192334.GA26208@aepfle.de>
Date: Thu, 24 Nov 2011 11:35:47 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Nov 24, Andres Lagar-Cavilla wrote:
>
>> > On Wed, Nov 23, Andres Lagar-Cavilla wrote:
>> >
>> >> Well, we can tone down printk's to be debug level. I don't think
>> they're
>> >> unnecessary if they're made an optional debug tool.
>> >
>> > There is nothing to debug here, since the callers have to retry
>> anyway.
>> >
>> >> Question: I have one vcpu, how do I fill up the ring quickly?
>> (outside
>> >> of
>> >> foreign mappings)
>> >
>> > Have a balloon driver in the guest and balloon down more than
>> > 64*PAGE_SIZE. This is the default at least in my setup where the
>> kernel
>> > driver releases some memory right away (I havent checked where this is
>> > actually configured).
>>
>> I see, a guest can call decrease_reservation with an extent_order large
>> enough that it will overflow the ring. No matter the size of the ring.
>> Isn't preemption of this hypercall a better tactic than putting the vcpu
>> on a wait-queue? This won't preclude the need for wait queues, but it
>> feels like a much cleaner solution.
>
> Yes, yesterday I was thinking about this as well.
> p2m_mem_paging_drop_page() should return -EBUSY. But currently not all
> callers of guest_remove_page() look at the exit code. Perhaps that can
> be fixed.
>
>> With retrying of foreign mappings in xc_map_foreign_bulk (and grants), I
>> wonder if we should put events in the ring due to foreign mappings *at
>> all*, in the case of congestion. Eventually a retry will get to kick the
>> pager.
>
> What do you mean with that?

Thinking out loud here. In our ring management patch, we put a guest vcpu
to sleep if space in the ring < d->max_vcpus.

In the case of a foreign mapping vcpu, we still allow the vcpu to put an
event in the ring, as long as there is any space. This can eventually fill
up the ring and prevent guest vcpus from placing events.

However, we could prevent this latter behaviour if it will result in a
condition in which
space_in_the_ring < (d->max_vcpus - ring->blocked)

This will ensure no event caused by a guest vcpu will ever be lost (we
still need the preemption of decrease_reservation, though).

Correctness is preserved for the foreign mapping vcpu. It will retry its
mapping and eventually there will be space in the ring.

With this, we won't need wait-queues for ring management.

Makes sense?
Andres

>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:36:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTf5o-0002sq-TF; Thu, 24 Nov 2011 19:36:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RTf5n-0002si-DW
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:36:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322163347!4874991!1
X-Originating-IP: [208.97.132.177]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21898 invoked from network); 24 Nov 2011 19:35:47 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-15.tower-216.messagelabs.com with SMTP;
	24 Nov 2011 19:35:47 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 074DF60407C;
	Thu, 24 Nov 2011 11:35:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=XyVfbsfz7bh6Y5ue2O0co8TU7eLdQtgO/SrwFvuCNske
	1iHDf4btma5oOuCcUG7NDyeh1Qq5Lr/upoWgfScMPWp0dvJ8oKnzo9kILEx/fPEG
	7hQPJBm1+SMQirNOZOGnmhxGgr4K5xINbEiodNFpS53nLfhGBZJwFXVTxAbPGQ0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=y8nKENX9WYwiSzKn5QLdoipVbaA=; b=WOcypLT2
	6Vtn9AKHE6mTsIoA60g22b+Kewjw1bzEINmcYq31omtBfjwVm09Db2S28XZvC2rC
	iOPUFkwu8sZxtIncWGNNn7ZJU2Gjrrtj38fFQ2CLBURNS+CD6s0Ydn4euoSJSG6Q
	vewOyfUrvdrylw0cOK4GaNmg2WLX01ZzUX4=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 91BE6604079; 
	Thu, 24 Nov 2011 11:35:46 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 24 Nov 2011 11:35:47 -0800
Message-ID: <593e94781b4c0b04c2c97e105caa3a50.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111124192334.GA26208@aepfle.de>
References: <patchbomb.1321307910@xdev.gridcentric.ca>
	<ee909e5a9d8555d7dd4d.1321307911@xdev.gridcentric.ca>
	<20111123183511.GA26144@aepfle.de>
	<d78fe2c45f3dec05bb9d525ea3f06d6d.squirrel@webmail.lagarcavilla.org>
	<20111123185728.GA27583@aepfle.de>
	<ec591bf57167a6212502a1eca68d2334.squirrel@webmail.lagarcavilla.org>
	<20111124192334.GA26208@aepfle.de>
Date: Thu, 24 Nov 2011 11:35:47 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	keir.xen@gmail.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 4] Improve ring management for memory
	events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, Nov 24, Andres Lagar-Cavilla wrote:
>
>> > On Wed, Nov 23, Andres Lagar-Cavilla wrote:
>> >
>> >> Well, we can tone down printk's to be debug level. I don't think
>> they're
>> >> unnecessary if they're made an optional debug tool.
>> >
>> > There is nothing to debug here, since the callers have to retry
>> anyway.
>> >
>> >> Question: I have one vcpu, how do I fill up the ring quickly?
>> (outside
>> >> of
>> >> foreign mappings)
>> >
>> > Have a balloon driver in the guest and balloon down more than
>> > 64*PAGE_SIZE. This is the default at least in my setup where the
>> kernel
>> > driver releases some memory right away (I havent checked where this is
>> > actually configured).
>>
>> I see, a guest can call decrease_reservation with an extent_order large
>> enough that it will overflow the ring. No matter the size of the ring.
>> Isn't preemption of this hypercall a better tactic than putting the vcpu
>> on a wait-queue? This won't preclude the need for wait queues, but it
>> feels like a much cleaner solution.
>
> Yes, yesterday I was thinking about this as well.
> p2m_mem_paging_drop_page() should return -EBUSY. But currently not all
> callers of guest_remove_page() look at the exit code. Perhaps that can
> be fixed.
>
>> With retrying of foreign mappings in xc_map_foreign_bulk (and grants), I
>> wonder if we should put events in the ring due to foreign mappings *at
>> all*, in the case of congestion. Eventually a retry will get to kick the
>> pager.
>
> What do you mean with that?

Thinking out loud here. In our ring management patch, we put a guest vcpu
to sleep if space in the ring < d->max_vcpus.

In the case of a foreign mapping vcpu, we still allow the vcpu to put an
event in the ring, as long as there is any space. This can eventually fill
up the ring and prevent guest vcpus from placing events.

However, we could prevent this latter behaviour if it will result in a
condition in which
space_in_the_ring < (d->max_vcpus - ring->blocked)

This will ensure no event caused by a guest vcpu will ever be lost (we
still need the preemption of decrease_reservation, though).

Correctness is preserved for the foreign mapping vcpu. It will retry its
mapping and eventually there will be space in the ring.

With this, we won't need wait-queues for ring management.

Makes sense?
Andres

>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:38:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTf7C-0002wc-DO; Thu, 24 Nov 2011 19:37:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTf7A-0002w6-Kq
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:37:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322163433!5684438!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11477 invoked from network); 24 Nov 2011 19:37:13 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2011 19:37:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322163432; l=494;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=UXa3NsHRQGXnqvvTXXVA/UufSTo=;
	b=LmK4BKbJ9FEQNmxPyva7xH8GSh/OKjx5n1l16nIBv86v8O+jSNmJdr+uXKXNbgP8cdM
	afu/abnrotYe4yz4SNrYbupaAI/P5um1iGjg4kjlo0u1QFR4Wd05+CuOzJOAx83CBIP5Q
	uQ+EJ+7eKj7543F5pbooU42zwDEvNh415wE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (jimi mo58) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id p057banAOH77gf ;
	Thu, 24 Nov 2011 20:37:06 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2EDA918637; Thu, 24 Nov 2011 20:37:06 +0100 (CET)
Date: Thu, 24 Nov 2011 20:37:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111124193706.GA26604@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
	<20174.36661.814563.526570@mariner.uk.xensource.com>
	<20111124184917.GA25646@aepfle.de>
	<20174.37522.349763.828592@mariner.uk.xensource.com>
	<20111124191502.GA25881@aepfle.de>
	<20174.39148.582161.596738@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20174.39148.582161.596738@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
 related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Ian Jackson wrote:

> Olaf Hering writes ("Re: [Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> > This should work:
> > 
> > if ! ncurses5-config --libs 2>/dev/null;then if ! ncurses-config --libs ; then echo '-lncurses' ; fi ; fi
> 
> That's an improvement, but it reruns the shell rune for every time
> CURSES_LIBS is expanded.

Right. I remember there are ways to assign a variable only once, I will
check the make documentation.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:38:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTf7C-0002wc-DO; Thu, 24 Nov 2011 19:37:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTf7A-0002w6-Kq
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:37:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322163433!5684438!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11477 invoked from network); 24 Nov 2011 19:37:13 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Nov 2011 19:37:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322163432; l=494;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=UXa3NsHRQGXnqvvTXXVA/UufSTo=;
	b=LmK4BKbJ9FEQNmxPyva7xH8GSh/OKjx5n1l16nIBv86v8O+jSNmJdr+uXKXNbgP8cdM
	afu/abnrotYe4yz4SNrYbupaAI/P5um1iGjg4kjlo0u1QFR4Wd05+CuOzJOAx83CBIP5Q
	uQ+EJ+7eKj7543F5pbooU42zwDEvNh415wE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (jimi mo58) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id p057banAOH77gf ;
	Thu, 24 Nov 2011 20:37:06 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2EDA918637; Thu, 24 Nov 2011 20:37:06 +0100 (CET)
Date: Thu, 24 Nov 2011 20:37:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111124193706.GA26604@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
	<20174.36661.814563.526570@mariner.uk.xensource.com>
	<20111124184917.GA25646@aepfle.de>
	<20174.37522.349763.828592@mariner.uk.xensource.com>
	<20111124191502.GA25881@aepfle.de>
	<20174.39148.582161.596738@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20174.39148.582161.596738@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] use ncurses-config to find all curses
 related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Ian Jackson wrote:

> Olaf Hering writes ("Re: [Xen-devel] [PATCH] use ncurses-config to find all curses related libs"):
> > This should work:
> > 
> > if ! ncurses5-config --libs 2>/dev/null;then if ! ncurses-config --libs ; then echo '-lncurses' ; fi ; fi
> 
> That's an improvement, but it reruns the shell rune for every time
> CURSES_LIBS is expanded.

Right. I remember there are ways to assign a variable only once, I will
check the make documentation.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:45:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTfDt-0003SK-AR; Thu, 24 Nov 2011 19:44:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RTfDr-0003SF-QE
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:44:40 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322163847!5650535!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14993 invoked from network); 24 Nov 2011 19:44:08 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-14.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 19:44:08 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RTfDL-0000Yu-3u
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:44:07 +0000
Received: from mail-yw0-f48.google.com ([209.85.213.48])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RTfDK-0000Ym-Tj for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Thu, 24 Nov 2011 19:44:06 +0000
Received: by ywp31 with SMTP id 31so2691016ywp.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Thu, 24 Nov 2011 11:44:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=3fwQSXL5HCfqGuuABpc5kLmo0gwcMVmHsA8Ixjrr764=;
	b=p9aDZl5NkyjPU48faF+RLnLsyZH6DUYd1xMUQtlhIOk6zfEKR6X5B6d1B2EV5LcMyW
	n65YVR02ytAIbgU9HoPCzQBSeKTLtXeH0pFyxm27901yv7GEYto1eoL/xR8/3lKooue6
	N++B8QzzKNlY+chH2bT64/gNTqP/1GbJnAvec=
MIME-Version: 1.0
Received: by 10.182.41.100 with SMTP id e4mr9703971obl.63.1322163846424; Thu,
	24 Nov 2011 11:44:06 -0800 (PST)
Received: by 10.182.35.167 with HTTP; Thu, 24 Nov 2011 11:44:06 -0800 (PST)
In-Reply-To: <20174.35789.415583.75576@mariner.uk.xensource.com>
References: <CACm5R6QtG3LYGkUw-Js6w3G5Gj61Cox0LrN0Cay=q_Z0k5fL4Q@mail.gmail.com>
	<20174.35789.415583.75576@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 11:44:06 -0800
Message-ID: <CACm5R6QrjEs8p9xa8fpUWW2+Ng8byt7eTV6KdHS-BF0e5=Ug2g@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: Re: [Xen-devel] HTML in wikitext
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 10:24 AM, Ian Jackson - Ian.Jackson@eu.citrix.com w=
rote:
> xen-devel.GarveyPatrickD@OrdinaryAmerican.net writes ("[Xen-devel] HTML i=
n wikitext"):
>> According to https://secure.wikimedia.org/wikipedia/en/wiki/Help:HTML_in=
_wikitext#Permitted_HTML
>> <abbr title=3D"abbreviation">abbr.</abbr> should be parsed as HTML by
>> the wiki server.
>
> That text refers to Wikipedia, not to the Xen Wiki.
>

I understood that the wikimedia.org page was documentation of their
implementation of MediaWiki server software.  I guess I should have
said, "... can be parsed ...", as a request to whomever implemented
the MediaWiki server to look into turning on that feature.  I've found
it useful to the understanding by first time readers of the local
TLA's (Three Letter Acronyms).

>> According to my experiment,
>> http://wiki.xen.org/wiki/User:GarveyPatrickD/Abbreviations
>> the Xen wiki doesn't seem to have this feature enabled.
>
> That is correct. =A0We don't plan to enable it.
>

As part of my newness here, I'm trying to understand the tools and
their implementations chosen by the project leaders.  Was there a
discussion of the choice not to implement this extension to MediaWiki
that I can study?  I've tried to use http://xen.markmail.org to find
such a discussion, but there seems to only be an announcement that
MoinMoin is being migrated to MediaWiki.

I can imagine the focus of the migration was getting the MediaWiki
server functioning without a lot of extensions or special options
enabled.

As I noted above, I've found it easier to read wiki pages that allow
me to hover over the TLA's for their expansion when I'm reading for my
initial entrance to the project.

> Ian.
>
>

Thank you for taking the time to answer my posting,
Patrick.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 19:45:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 19:45:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTfDt-0003SK-AR; Thu, 24 Nov 2011 19:44:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RTfDr-0003SF-QE
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:44:40 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322163847!5650535!1
X-Originating-IP: [216.75.62.102]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14993 invoked from network); 24 Nov 2011 19:44:08 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-14.tower-21.messagelabs.com with SMTP;
	24 Nov 2011 19:44:08 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RTfDL-0000Yu-3u
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 19:44:07 +0000
Received: from mail-yw0-f48.google.com ([209.85.213.48])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RTfDK-0000Ym-Tj for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Thu, 24 Nov 2011 19:44:06 +0000
Received: by ywp31 with SMTP id 31so2691016ywp.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Thu, 24 Nov 2011 11:44:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=3fwQSXL5HCfqGuuABpc5kLmo0gwcMVmHsA8Ixjrr764=;
	b=p9aDZl5NkyjPU48faF+RLnLsyZH6DUYd1xMUQtlhIOk6zfEKR6X5B6d1B2EV5LcMyW
	n65YVR02ytAIbgU9HoPCzQBSeKTLtXeH0pFyxm27901yv7GEYto1eoL/xR8/3lKooue6
	N++B8QzzKNlY+chH2bT64/gNTqP/1GbJnAvec=
MIME-Version: 1.0
Received: by 10.182.41.100 with SMTP id e4mr9703971obl.63.1322163846424; Thu,
	24 Nov 2011 11:44:06 -0800 (PST)
Received: by 10.182.35.167 with HTTP; Thu, 24 Nov 2011 11:44:06 -0800 (PST)
In-Reply-To: <20174.35789.415583.75576@mariner.uk.xensource.com>
References: <CACm5R6QtG3LYGkUw-Js6w3G5Gj61Cox0LrN0Cay=q_Z0k5fL4Q@mail.gmail.com>
	<20174.35789.415583.75576@mariner.uk.xensource.com>
Date: Thu, 24 Nov 2011 11:44:06 -0800
Message-ID: <CACm5R6QrjEs8p9xa8fpUWW2+Ng8byt7eTV6KdHS-BF0e5=Ug2g@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: Re: [Xen-devel] HTML in wikitext
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 10:24 AM, Ian Jackson - Ian.Jackson@eu.citrix.com w=
rote:
> xen-devel.GarveyPatrickD@OrdinaryAmerican.net writes ("[Xen-devel] HTML i=
n wikitext"):
>> According to https://secure.wikimedia.org/wikipedia/en/wiki/Help:HTML_in=
_wikitext#Permitted_HTML
>> <abbr title=3D"abbreviation">abbr.</abbr> should be parsed as HTML by
>> the wiki server.
>
> That text refers to Wikipedia, not to the Xen Wiki.
>

I understood that the wikimedia.org page was documentation of their
implementation of MediaWiki server software.  I guess I should have
said, "... can be parsed ...", as a request to whomever implemented
the MediaWiki server to look into turning on that feature.  I've found
it useful to the understanding by first time readers of the local
TLA's (Three Letter Acronyms).

>> According to my experiment,
>> http://wiki.xen.org/wiki/User:GarveyPatrickD/Abbreviations
>> the Xen wiki doesn't seem to have this feature enabled.
>
> That is correct. =A0We don't plan to enable it.
>

As part of my newness here, I'm trying to understand the tools and
their implementations chosen by the project leaders.  Was there a
discussion of the choice not to implement this extension to MediaWiki
that I can study?  I've tried to use http://xen.markmail.org to find
such a discussion, but there seems to only be an announcement that
MoinMoin is being migrated to MediaWiki.

I can imagine the focus of the migration was getting the MediaWiki
server functioning without a lot of extensions or special options
enabled.

As I noted above, I've found it easier to read wiki pages that allow
me to hover over the TLA's for their expansion when I'm reading for my
initial entrance to the project.

> Ian.
>
>

Thank you for taking the time to answer my posting,
Patrick.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 20:03:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 20:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTfVl-0003pP-BR; Thu, 24 Nov 2011 20:03:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avsm@dark.recoil.org>) id 1RTfVk-0003p4-03
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 20:03:08 +0000
X-Env-Sender: avsm@dark.recoil.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322164956!2912659!1
X-Originating-IP: [89.16.177.154]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24000 invoked from network); 24 Nov 2011 20:02:36 -0000
Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154)
	by server-13.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 20:02:36 -0000
Received: (qmail 17843 invoked by uid 10000); 24 Nov 2011 20:02:35 -0000
Date: Thu, 24 Nov 2011 20:02:35 +0000
From: Anil Madhavapeddy <anil@recoil.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111124200235.GA21510@dark.recoil.org>
References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov>
	<CACaajQsMnXb9u1pTtB9jT5b6n2p6gFq_A8aQajAO4kmcpSwKdw@mail.gmail.com>
	<CACaajQtCMpWuqH8PGhwK-WGC=bXRiE1an+2sWcm2JaozK7BK=w@mail.gmail.com>
	<4E85D4CB.80009@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4E85D4CB.80009@tycho.nsa.gov>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	konrad.wilk@oracle.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@eu.citrix.com, Vasiliy Tolstov <v.tolstov@ghs.l.google.com>
Subject: Re: [Xen-devel] [PATCH v6 0/3] libxenvchan: interdomain
 communications library
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Sep 30, 2011 at 10:40:11AM -0400, Daniel De Graaf wrote:
> >>
> >> 2011/9/23 Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >>
> >>> Changes since v5:
> >>>  - Unify gntdev osdep interface
> >>>  - Eliminate notify_result and revert mapping if notify ioctl fails
> >>>  - Rename functions and structures to libxenvchan
> >>>  - Use application-specified xenstore path for ring/event data
> >>>  - Enforce maximum ring size of 2^20 bytes on client
> >>>  - Change to LGPL 2.1
> >>>
> >>> [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify
> >>> [PATCH 2/3] libxc: add xc_gntshr_* functions
> >>> [PATCH 3/3] libvchan: interdomain communications library
> >>>
<snip>
> This library depends on gntdev for the client and gntalloc for the server;
> these were merged in 2.6.39. The client can be used with 2.6.32.x kernels
> however it is not possible to detect when a peer crashes or exits without
> calling libxenvchan_close() on that kernel.

I'm trying this with your most recent dom0 patches all included, and
xen-unstable. In order to get decent performance, I tried the vchan-node
examples with a cranked up buffer size, which fails immediately on 64-bit
VMs.  This below patch fixes the xc_gntshr_share_pages call (which sets
notify_offset to -1 and without this bounds check will send a big offset
to the unmap notify ioctl).

With this, communication does work with the big buffers, but it never
frees them, and so I can get an ENOSPACE error by calling vchan-node a few
times. What's the intended cleanup path for the grants in normal use of
the vchan library? Something's holding onto them, but I don't have a
serial console on my current laptop in order to drop into Xen's serial and
find out more.

diff -r 614e9f371209 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c      Thu Nov 24 18:53:09 2011 +0000
+++ b/tools/libxc/xc_linux_osdep.c      Thu Nov 24 20:00:21 2011 +0000
@@ -709,7 +709,7 @@
 
     notify.index = gref_info->index;
     notify.action = 0;
-    if (notify_offset >= 0) {
+    if (notify_offset >= 0 && notify_offset < XC_PAGE_SIZE * count) {
         notify.index += notify_offset;
         notify.action |= UNMAP_NOTIFY_CLEAR_BYTE;
     }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 20:03:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 20:03:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTfVl-0003pP-BR; Thu, 24 Nov 2011 20:03:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <avsm@dark.recoil.org>) id 1RTfVk-0003p4-03
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 20:03:08 +0000
X-Env-Sender: avsm@dark.recoil.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322164956!2912659!1
X-Originating-IP: [89.16.177.154]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24000 invoked from network); 24 Nov 2011 20:02:36 -0000
Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154)
	by server-13.tower-174.messagelabs.com with SMTP;
	24 Nov 2011 20:02:36 -0000
Received: (qmail 17843 invoked by uid 10000); 24 Nov 2011 20:02:35 -0000
Date: Thu, 24 Nov 2011 20:02:35 +0000
From: Anil Madhavapeddy <anil@recoil.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111124200235.GA21510@dark.recoil.org>
References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov>
	<CACaajQsMnXb9u1pTtB9jT5b6n2p6gFq_A8aQajAO4kmcpSwKdw@mail.gmail.com>
	<CACaajQtCMpWuqH8PGhwK-WGC=bXRiE1an+2sWcm2JaozK7BK=w@mail.gmail.com>
	<4E85D4CB.80009@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4E85D4CB.80009@tycho.nsa.gov>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	konrad.wilk@oracle.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@eu.citrix.com, Vasiliy Tolstov <v.tolstov@ghs.l.google.com>
Subject: Re: [Xen-devel] [PATCH v6 0/3] libxenvchan: interdomain
 communications library
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Sep 30, 2011 at 10:40:11AM -0400, Daniel De Graaf wrote:
> >>
> >> 2011/9/23 Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >>
> >>> Changes since v5:
> >>>  - Unify gntdev osdep interface
> >>>  - Eliminate notify_result and revert mapping if notify ioctl fails
> >>>  - Rename functions and structures to libxenvchan
> >>>  - Use application-specified xenstore path for ring/event data
> >>>  - Enforce maximum ring size of 2^20 bytes on client
> >>>  - Change to LGPL 2.1
> >>>
> >>> [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify
> >>> [PATCH 2/3] libxc: add xc_gntshr_* functions
> >>> [PATCH 3/3] libvchan: interdomain communications library
> >>>
<snip>
> This library depends on gntdev for the client and gntalloc for the server;
> these were merged in 2.6.39. The client can be used with 2.6.32.x kernels
> however it is not possible to detect when a peer crashes or exits without
> calling libxenvchan_close() on that kernel.

I'm trying this with your most recent dom0 patches all included, and
xen-unstable. In order to get decent performance, I tried the vchan-node
examples with a cranked up buffer size, which fails immediately on 64-bit
VMs.  This below patch fixes the xc_gntshr_share_pages call (which sets
notify_offset to -1 and without this bounds check will send a big offset
to the unmap notify ioctl).

With this, communication does work with the big buffers, but it never
frees them, and so I can get an ENOSPACE error by calling vchan-node a few
times. What's the intended cleanup path for the grants in normal use of
the vchan library? Something's holding onto them, but I don't have a
serial console on my current laptop in order to drop into Xen's serial and
find out more.

diff -r 614e9f371209 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c      Thu Nov 24 18:53:09 2011 +0000
+++ b/tools/libxc/xc_linux_osdep.c      Thu Nov 24 20:00:21 2011 +0000
@@ -709,7 +709,7 @@
 
     notify.index = gref_info->index;
     notify.action = 0;
-    if (notify_offset >= 0) {
+    if (notify_offset >= 0 && notify_offset < XC_PAGE_SIZE * count) {
         notify.index += notify_offset;
         notify.action |= UNMAP_NOTIFY_CLEAR_BYTE;
     }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 20:18:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 20:18:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTfk7-0004GX-Pc; Thu, 24 Nov 2011 20:17:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTfk6-0004GS-Fe
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 20:17:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322165846!4824661!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4152 invoked from network); 24 Nov 2011 20:17:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 20:17:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322165846; l=7285;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=+6hC2unsnDYveVU4V1uAV9hK8jQ=;
	b=x61FHDiS/70h2soXyzyO+3s3gzZQrFDGpOJVeqrFjhyDLDBnYD6EH444x/yB1SY/OFD
	J88O+pi50NI3RM3K9uOC5AStgxnAoZVLgI54CULvVop+bW3nxQJvhscWvRsgTz+NS+jDy
	/AnUXwiy3uZZekcgvAcVHc/1Q1aEVVF/T0k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (jimi mo2) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Z03b67nAOJfF7Q
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 21:17:23 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D7D2C18636
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 21:17:22 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: dfa1e22034ca627961c311b1b6bb231276b7e6e6
Message-Id: <dfa1e22034ca627961c3.1322165841@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 24 Nov 2011 21:17:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mem_event: move mem_event_domain out of struct
	domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322165728 -3600
# Node ID dfa1e22034ca627961c311b1b6bb231276b7e6e6
# Parent  1027e7d13d02143048c7d48d7960967c5b1657a8
mem_event: move mem_event_domain out of struct domain

An upcoming change may increase the size of mem_event_domain. The result
is a build failure because struct domain gets larger than a page.
Allocate the room for the three mem_event_domain members at runtime.

v2:
 - remove mem_ prefix from members of new struct

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1027e7d13d02 -r dfa1e22034ca xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4106,7 +4106,7 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_access);
+    rc = mem_event_check_ring(d, &d->mem_event->access);
     if ( rc )
         return rc;
     
@@ -4129,7 +4129,7 @@ static int hvm_memory_event_traps(long p
         req.gla_valid = 1;
     }
     
-    mem_event_put_request(d, &d->mem_access, &req);
+    mem_event_put_request(d, &d->mem_event->access, &req);
     
     return 1;
 }
diff -r 1027e7d13d02 -r dfa1e22034ca xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -265,7 +265,7 @@ int mem_event_domctl(struct domain *d, x
     {
     case XEN_DOMCTL_MEM_EVENT_OP_PAGING:
     {
-        struct mem_event_domain *med = &d->mem_paging;
+        struct mem_event_domain *med = &d->mem_event->paging;
         rc = -EINVAL;
 
         switch( mec->op )
@@ -310,7 +310,7 @@ int mem_event_domctl(struct domain *d, x
 
     case XEN_DOMCTL_MEM_EVENT_OP_ACCESS: 
     {
-        struct mem_event_domain *med = &d->mem_access;
+        struct mem_event_domain *med = &d->mem_event->access;
         rc = -EINVAL;
 
         switch( mec->op )
@@ -333,7 +333,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(&d->mem_access);
+                rc = mem_event_disable(med);
         }
         break;
 
diff -r 1027e7d13d02 -r dfa1e22034ca xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -281,12 +281,12 @@ static struct page_info* mem_sharing_all
     vcpu_pause_nosync(v);
     req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
 
-    if(mem_event_check_ring(d, &d->mem_share)) return page;
+    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
 
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
-    mem_event_put_request(d, &d->mem_share, &req);
+    mem_event_put_request(d, &d->mem_event->share, &req);
 
     return page;
 }
@@ -301,7 +301,7 @@ int mem_sharing_sharing_resume(struct do
     mem_event_response_t rsp;
 
     /* Get request off the ring */
-    mem_event_get_response(&d->mem_share, &rsp);
+    mem_event_get_response(&d->mem_event->share, &rsp);
 
     /* Unpause domain/vcpu */
     if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
diff -r 1027e7d13d02 -r dfa1e22034ca xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -886,7 +886,7 @@ void p2m_mem_paging_drop_page(struct dom
     mem_event_request_t req;
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_paging) == 0)
+    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
     {
         /* Send release notification to pager */
         memset(&req, 0, sizeof(req));
@@ -894,7 +894,7 @@ void p2m_mem_paging_drop_page(struct dom
         req.gfn = gfn;
         req.vcpu_id = v->vcpu_id;
 
-        mem_event_put_request(d, &d->mem_paging, &req);
+        mem_event_put_request(d, &d->mem_event->paging, &req);
     }
 }
 
@@ -929,7 +929,7 @@ void p2m_mem_paging_populate(struct doma
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_paging) )
+    if ( mem_event_check_ring(d, &d->mem_event->paging) )
         return;
 
     memset(&req, 0, sizeof(req));
@@ -960,7 +960,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_paging);
+        mem_event_put_req_producers(&d->mem_event->paging);
         return;
     }
 
@@ -969,7 +969,7 @@ void p2m_mem_paging_populate(struct doma
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_paging, &req);
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -1049,7 +1049,7 @@ void p2m_mem_paging_resume(struct domain
     mfn_t mfn;
 
     /* Pull the response off the ring */
-    mem_event_get_response(&d->mem_paging, &rsp);
+    mem_event_get_response(&d->mem_event->paging, &rsp);
 
     /* Fix p2m entry if the page was not dropped */
     if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
@@ -1104,7 +1104,7 @@ void p2m_mem_access_check(unsigned long 
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_access);
+    res = mem_event_check_ring(d, &d->mem_event->access);
     if ( res < 0 ) 
     {
         /* No listener */
@@ -1148,7 +1148,7 @@ void p2m_mem_access_check(unsigned long 
     
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_access, &req);
+    mem_event_put_request(d, &d->mem_event->access, &req);
 
     /* VCPU paused, mem event request sent */
 }
@@ -1158,7 +1158,7 @@ void p2m_mem_access_resume(struct p2m_do
     struct domain *d = p2m->domain;
     mem_event_response_t rsp;
 
-    mem_event_get_response(&d->mem_access, &rsp);
+    mem_event_get_response(&d->mem_event->access, &rsp);
 
     /* Unpause domain */
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
diff -r 1027e7d13d02 -r dfa1e22034ca xen/common/domain.c
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -304,6 +304,10 @@ struct domain *domain_create(
         init_status |= INIT_gnttab;
 
         poolid = 0;
+
+        d->mem_event = xzalloc(struct mem_event_per_domain);
+        if ( !d->mem_event )
+            goto fail;
     }
 
     if ( arch_domain_create(d, domcr_flags) != 0 )
@@ -335,6 +339,7 @@ struct domain *domain_create(
  fail:
     d->is_dying = DOMDYING_dead;
     atomic_set(&d->refcnt, DOMAIN_DESTROYED);
+    xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
     if ( init_status & INIT_gnttab )
diff -r 1027e7d13d02 -r dfa1e22034ca xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -194,6 +194,16 @@ struct mem_event_domain
     int xen_port;
 };
 
+struct mem_event_per_domain
+{
+    /* Memory sharing support */
+    struct mem_event_domain share;
+    /* Memory paging support */
+    struct mem_event_domain paging;
+    /* Memory access support */
+    struct mem_event_domain access;
+};
+
 struct domain
 {
     domid_t          domain_id;
@@ -318,12 +328,8 @@ struct domain
     /* Non-migratable and non-restoreable? */
     bool_t disable_migrate;
 
-    /* Memory sharing support */
-    struct mem_event_domain mem_share;
-    /* Memory paging support */
-    struct mem_event_domain mem_paging;
-    /* Memory access support */
-    struct mem_event_domain mem_access;
+    /* Various mem_events */
+    struct mem_event_per_domain *mem_event;
 
     /* Currently computed from union of all vcpu cpu-affinity masks. */
     nodemask_t node_affinity;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 20:18:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 20:18:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTfk7-0004GX-Pc; Thu, 24 Nov 2011 20:17:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTfk6-0004GS-Fe
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 20:17:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322165846!4824661!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4152 invoked from network); 24 Nov 2011 20:17:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Nov 2011 20:17:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322165846; l=7285;
	s=domk; d=aepfle.de;
	h=To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=+6hC2unsnDYveVU4V1uAV9hK8jQ=;
	b=x61FHDiS/70h2soXyzyO+3s3gzZQrFDGpOJVeqrFjhyDLDBnYD6EH444x/yB1SY/OFD
	J88O+pi50NI3RM3K9uOC5AStgxnAoZVLgI54CULvVop+bW3nxQJvhscWvRsgTz+NS+jDy
	/AnUXwiy3uZZekcgvAcVHc/1Q1aEVVF/T0k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr3c7pESom
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-064-237.pools.arcor-ip.net [84.57.64.237])
	by smtp.strato.de (jimi mo2) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Z03b67nAOJfF7Q
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 21:17:23 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D7D2C18636
	for <xen-devel@lists.xensource.com>;
	Thu, 24 Nov 2011 21:17:22 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: dfa1e22034ca627961c311b1b6bb231276b7e6e6
Message-Id: <dfa1e22034ca627961c3.1322165841@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 24 Nov 2011 21:17:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mem_event: move mem_event_domain out of struct
	domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322165728 -3600
# Node ID dfa1e22034ca627961c311b1b6bb231276b7e6e6
# Parent  1027e7d13d02143048c7d48d7960967c5b1657a8
mem_event: move mem_event_domain out of struct domain

An upcoming change may increase the size of mem_event_domain. The result
is a build failure because struct domain gets larger than a page.
Allocate the room for the three mem_event_domain members at runtime.

v2:
 - remove mem_ prefix from members of new struct

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1027e7d13d02 -r dfa1e22034ca xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4106,7 +4106,7 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_access);
+    rc = mem_event_check_ring(d, &d->mem_event->access);
     if ( rc )
         return rc;
     
@@ -4129,7 +4129,7 @@ static int hvm_memory_event_traps(long p
         req.gla_valid = 1;
     }
     
-    mem_event_put_request(d, &d->mem_access, &req);
+    mem_event_put_request(d, &d->mem_event->access, &req);
     
     return 1;
 }
diff -r 1027e7d13d02 -r dfa1e22034ca xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -265,7 +265,7 @@ int mem_event_domctl(struct domain *d, x
     {
     case XEN_DOMCTL_MEM_EVENT_OP_PAGING:
     {
-        struct mem_event_domain *med = &d->mem_paging;
+        struct mem_event_domain *med = &d->mem_event->paging;
         rc = -EINVAL;
 
         switch( mec->op )
@@ -310,7 +310,7 @@ int mem_event_domctl(struct domain *d, x
 
     case XEN_DOMCTL_MEM_EVENT_OP_ACCESS: 
     {
-        struct mem_event_domain *med = &d->mem_access;
+        struct mem_event_domain *med = &d->mem_event->access;
         rc = -EINVAL;
 
         switch( mec->op )
@@ -333,7 +333,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(&d->mem_access);
+                rc = mem_event_disable(med);
         }
         break;
 
diff -r 1027e7d13d02 -r dfa1e22034ca xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -281,12 +281,12 @@ static struct page_info* mem_sharing_all
     vcpu_pause_nosync(v);
     req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
 
-    if(mem_event_check_ring(d, &d->mem_share)) return page;
+    if(mem_event_check_ring(d, &d->mem_event->share)) return page;
 
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
-    mem_event_put_request(d, &d->mem_share, &req);
+    mem_event_put_request(d, &d->mem_event->share, &req);
 
     return page;
 }
@@ -301,7 +301,7 @@ int mem_sharing_sharing_resume(struct do
     mem_event_response_t rsp;
 
     /* Get request off the ring */
-    mem_event_get_response(&d->mem_share, &rsp);
+    mem_event_get_response(&d->mem_event->share, &rsp);
 
     /* Unpause domain/vcpu */
     if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
diff -r 1027e7d13d02 -r dfa1e22034ca xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -886,7 +886,7 @@ void p2m_mem_paging_drop_page(struct dom
     mem_event_request_t req;
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_paging) == 0)
+    if ( mem_event_check_ring(d, &d->mem_event->paging) == 0)
     {
         /* Send release notification to pager */
         memset(&req, 0, sizeof(req));
@@ -894,7 +894,7 @@ void p2m_mem_paging_drop_page(struct dom
         req.gfn = gfn;
         req.vcpu_id = v->vcpu_id;
 
-        mem_event_put_request(d, &d->mem_paging, &req);
+        mem_event_put_request(d, &d->mem_event->paging, &req);
     }
 }
 
@@ -929,7 +929,7 @@ void p2m_mem_paging_populate(struct doma
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     /* Check that there's space on the ring for this request */
-    if ( mem_event_check_ring(d, &d->mem_paging) )
+    if ( mem_event_check_ring(d, &d->mem_event->paging) )
         return;
 
     memset(&req, 0, sizeof(req));
@@ -960,7 +960,7 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_paging);
+        mem_event_put_req_producers(&d->mem_event->paging);
         return;
     }
 
@@ -969,7 +969,7 @@ void p2m_mem_paging_populate(struct doma
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_paging, &req);
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -1049,7 +1049,7 @@ void p2m_mem_paging_resume(struct domain
     mfn_t mfn;
 
     /* Pull the response off the ring */
-    mem_event_get_response(&d->mem_paging, &rsp);
+    mem_event_get_response(&d->mem_event->paging, &rsp);
 
     /* Fix p2m entry if the page was not dropped */
     if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
@@ -1104,7 +1104,7 @@ void p2m_mem_access_check(unsigned long 
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_access);
+    res = mem_event_check_ring(d, &d->mem_event->access);
     if ( res < 0 ) 
     {
         /* No listener */
@@ -1148,7 +1148,7 @@ void p2m_mem_access_check(unsigned long 
     
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_access, &req);
+    mem_event_put_request(d, &d->mem_event->access, &req);
 
     /* VCPU paused, mem event request sent */
 }
@@ -1158,7 +1158,7 @@ void p2m_mem_access_resume(struct p2m_do
     struct domain *d = p2m->domain;
     mem_event_response_t rsp;
 
-    mem_event_get_response(&d->mem_access, &rsp);
+    mem_event_get_response(&d->mem_event->access, &rsp);
 
     /* Unpause domain */
     if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
diff -r 1027e7d13d02 -r dfa1e22034ca xen/common/domain.c
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -304,6 +304,10 @@ struct domain *domain_create(
         init_status |= INIT_gnttab;
 
         poolid = 0;
+
+        d->mem_event = xzalloc(struct mem_event_per_domain);
+        if ( !d->mem_event )
+            goto fail;
     }
 
     if ( arch_domain_create(d, domcr_flags) != 0 )
@@ -335,6 +339,7 @@ struct domain *domain_create(
  fail:
     d->is_dying = DOMDYING_dead;
     atomic_set(&d->refcnt, DOMAIN_DESTROYED);
+    xfree(d->mem_event);
     if ( init_status & INIT_arch )
         arch_domain_destroy(d);
     if ( init_status & INIT_gnttab )
diff -r 1027e7d13d02 -r dfa1e22034ca xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -194,6 +194,16 @@ struct mem_event_domain
     int xen_port;
 };
 
+struct mem_event_per_domain
+{
+    /* Memory sharing support */
+    struct mem_event_domain share;
+    /* Memory paging support */
+    struct mem_event_domain paging;
+    /* Memory access support */
+    struct mem_event_domain access;
+};
+
 struct domain
 {
     domid_t          domain_id;
@@ -318,12 +328,8 @@ struct domain
     /* Non-migratable and non-restoreable? */
     bool_t disable_migrate;
 
-    /* Memory sharing support */
-    struct mem_event_domain mem_share;
-    /* Memory paging support */
-    struct mem_event_domain mem_paging;
-    /* Memory access support */
-    struct mem_event_domain mem_access;
+    /* Various mem_events */
+    struct mem_event_per_domain *mem_event;
 
     /* Currently computed from union of all vcpu cpu-affinity masks. */
     nodemask_t node_affinity;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 23:09:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 23:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTiPU-0007VN-Ak; Thu, 24 Nov 2011 23:08:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTiPS-0007VI-Es
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 23:08:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322176098!2877736!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6833 invoked from network); 24 Nov 2011 23:08:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 23:08:18 -0000
X-IronPort-AV: E=Sophos;i="4.69,567,1315180800"; 
   d="scan'208";a="9120941"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 23:08:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 23:08:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTiOv-0000cA-Dg;
	Thu, 24 Nov 2011 23:08:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTiOv-0003Qz-Cb;
	Thu, 24 Nov 2011 23:08:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10022-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 24 Nov 2011 23:08:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10022: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10022 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10022/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     12 guest-saverestore.2        fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5c88358164cc
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 541 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Nov 24 23:09:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 24 Nov 2011 23:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTiPU-0007VN-Ak; Thu, 24 Nov 2011 23:08:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTiPS-0007VI-Es
	for xen-devel@lists.xensource.com; Thu, 24 Nov 2011 23:08:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322176098!2877736!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6833 invoked from network); 24 Nov 2011 23:08:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Nov 2011 23:08:18 -0000
X-IronPort-AV: E=Sophos;i="4.69,567,1315180800"; 
   d="scan'208";a="9120941"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Nov 2011 23:08:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 24 Nov 2011 23:08:17 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTiOv-0000cA-Dg;
	Thu, 24 Nov 2011 23:08:17 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTiOv-0003Qz-Cb;
	Thu, 24 Nov 2011 23:08:17 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10022-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 24 Nov 2011 23:08:17 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10022: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10022 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10022/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     12 guest-saverestore.2        fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5c88358164cc
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 541 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 01:53:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 01:53:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTkyW-0005p4-Sv; Fri, 25 Nov 2011 01:53:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kuwa@jp.fujitsu.com>)
	id 1RTkyV-0005ow-6D; Fri, 25 Nov 2011 01:53:11 +0000
X-Env-Sender: kuwa@jp.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322185956!2941608!1
X-Originating-IP: [192.51.44.36]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29250 invoked from network); 25 Nov 2011 01:52:38 -0000
Received: from fgwmail6.fujitsu.co.jp (HELO fgwmail6.fujitsu.co.jp)
	(192.51.44.36)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 01:52:38 -0000
Received: from m3.gw.fujitsu.co.jp (unknown [10.0.50.73])
	by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id CCD8F3EE0AE;
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from smail (m3 [127.0.0.1])
	by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id B5A2D45DEEB;
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93])
	by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id A06F545DED9;
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 93ED41DB8038;
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp
	[10.25.192.37])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 62B4C1DB803C;
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp
	[10.25.192.39])
	by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs.
	Domain Mail Master) with ESMTP id pAP1pkAR023210; 
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
X-AuditID: 0a19c027-b7ca5ae000001565-39-4ecef4e20854
Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp
	[10.25.192.105])
	by vskawa.flab.fujitsu.co.jp (Symantec Brightmail Gateway) with SMTP id
	F9.39.05477.2E4FECE4; Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from eve.cad.flab.fujitsu.co.jp (eve.cad.flab.fujitsu.co.jp
	[10.25.228.68])
	by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs.
	Kawasaki Domain Mail Master) with ESMTP id pAP1qYQQ024714; 
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by eve.cad.flab.fujitsu.co.jp (8.14.4/8.14.4) with ESMTP id
	pAP1qX6F013664; Fri, 25 Nov 2011 10:52:33 +0900 (JST)
	(envelope-from kuwa@jp.fujitsu.com)
Date: Fri, 25 Nov 2011 10:52:13 +0900 (JST)
Message-Id: <20111125.105213.310075014.kuwa@jp.fujitsu.com>
To: JBeulich@suse.com
From: "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com>
In-Reply-To: <4EBD56C50200007800060781@nat28.tlf.novell.com>
References: <4EBD56C50200007800060781@nat28.tlf.novell.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: xen-devel@lists.xensource.com, xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ia64: introduce atomic_{read,write}NN()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Jan,

Excuse me for too late response. Thank you for your work.
But I have a question.

>>>>> On Fri, 11 Nov 2011 16:09:25 +0000
>>>>> JBeulich@suse.com("Jan Beulich")  said:
> 
> +#define build_atomic_read(tag, type) \
> +static inline type atomic_read##tag(const volatile type *addr) \
> +{ \
> +	type ret; \
> +	asm volatile("ld%2.acq %0 = %1" \
> +		     : "=r" (ret) \
> +		     : "m" (*addr), "i" (sizeof(type))); \
> +	return ret; \
> +}
> +
> +#define build_atomic_write(tag, type) \
> +static inline void atomic_write##tag(volatile type *addr, type val) \
> +{ \
> +	asm volatile("st%2.rel %0 = %1" \
> +		     : "=m" (*addr) \
> +		     : "r" (val), "i" (sizeof(type))); \
> +}

Why do you use explicitly ld.acq and st.rel?
I think that volatile variables are always accessed using ld.acq and
st.rel and they are not required.
For example, The implementation of Linux is as follows:

#define atomic_read(v)		(*(volatile int *)&(v)->counter)
#define atomic64_read(v)	(*(volatile long *)&(v)->counter)

Best regards,
-- 
  KUWAMURA Shin'ya

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 01:53:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 01:53:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTkyW-0005p4-Sv; Fri, 25 Nov 2011 01:53:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kuwa@jp.fujitsu.com>)
	id 1RTkyV-0005ow-6D; Fri, 25 Nov 2011 01:53:11 +0000
X-Env-Sender: kuwa@jp.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322185956!2941608!1
X-Originating-IP: [192.51.44.36]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29250 invoked from network); 25 Nov 2011 01:52:38 -0000
Received: from fgwmail6.fujitsu.co.jp (HELO fgwmail6.fujitsu.co.jp)
	(192.51.44.36)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 01:52:38 -0000
Received: from m3.gw.fujitsu.co.jp (unknown [10.0.50.73])
	by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id CCD8F3EE0AE;
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from smail (m3 [127.0.0.1])
	by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id B5A2D45DEEB;
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93])
	by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id A06F545DED9;
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 93ED41DB8038;
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp
	[10.25.192.37])
	by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 62B4C1DB803C;
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp
	[10.25.192.39])
	by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs.
	Domain Mail Master) with ESMTP id pAP1pkAR023210; 
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
X-AuditID: 0a19c027-b7ca5ae000001565-39-4ecef4e20854
Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp
	[10.25.192.105])
	by vskawa.flab.fujitsu.co.jp (Symantec Brightmail Gateway) with SMTP id
	F9.39.05477.2E4FECE4; Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from eve.cad.flab.fujitsu.co.jp (eve.cad.flab.fujitsu.co.jp
	[10.25.228.68])
	by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs.
	Kawasaki Domain Mail Master) with ESMTP id pAP1qYQQ024714; 
	Fri, 25 Nov 2011 10:52:34 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by eve.cad.flab.fujitsu.co.jp (8.14.4/8.14.4) with ESMTP id
	pAP1qX6F013664; Fri, 25 Nov 2011 10:52:33 +0900 (JST)
	(envelope-from kuwa@jp.fujitsu.com)
Date: Fri, 25 Nov 2011 10:52:13 +0900 (JST)
Message-Id: <20111125.105213.310075014.kuwa@jp.fujitsu.com>
To: JBeulich@suse.com
From: "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com>
In-Reply-To: <4EBD56C50200007800060781@nat28.tlf.novell.com>
References: <4EBD56C50200007800060781@nat28.tlf.novell.com>
X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: xen-devel@lists.xensource.com, xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ia64: introduce atomic_{read,write}NN()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Jan,

Excuse me for too late response. Thank you for your work.
But I have a question.

>>>>> On Fri, 11 Nov 2011 16:09:25 +0000
>>>>> JBeulich@suse.com("Jan Beulich")  said:
> 
> +#define build_atomic_read(tag, type) \
> +static inline type atomic_read##tag(const volatile type *addr) \
> +{ \
> +	type ret; \
> +	asm volatile("ld%2.acq %0 = %1" \
> +		     : "=r" (ret) \
> +		     : "m" (*addr), "i" (sizeof(type))); \
> +	return ret; \
> +}
> +
> +#define build_atomic_write(tag, type) \
> +static inline void atomic_write##tag(volatile type *addr, type val) \
> +{ \
> +	asm volatile("st%2.rel %0 = %1" \
> +		     : "=m" (*addr) \
> +		     : "r" (val), "i" (sizeof(type))); \
> +}

Why do you use explicitly ld.acq and st.rel?
I think that volatile variables are always accessed using ld.acq and
st.rel and they are not required.
For example, The implementation of Linux is as follows:

#define atomic_read(v)		(*(volatile int *)&(v)->counter)
#define atomic64_read(v)	(*(volatile long *)&(v)->counter)

Best regards,
-- 
  KUWAMURA Shin'ya

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 03:06:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 03:06:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTm6Z-0007E9-1F; Fri, 25 Nov 2011 03:05:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTm6X-0007E4-IX
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 03:05:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322190301!2942735!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32584 invoked from network); 25 Nov 2011 03:05:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 03:05:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,568,1315180800"; 
   d="scan'208";a="9121583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 03:05:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 03:05:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTm61-0001w0-5P;
	Fri, 25 Nov 2011 03:05:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTm61-0004RJ-3I;
	Fri, 25 Nov 2011 03:05:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10023-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 03:05:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10023: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10023 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10023/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1027e7d13d02
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 847 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 03:06:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 03:06:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTm6Z-0007E9-1F; Fri, 25 Nov 2011 03:05:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTm6X-0007E4-IX
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 03:05:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322190301!2942735!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32584 invoked from network); 25 Nov 2011 03:05:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 03:05:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,568,1315180800"; 
   d="scan'208";a="9121583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 03:05:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 03:05:01 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTm61-0001w0-5P;
	Fri, 25 Nov 2011 03:05:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTm61-0004RJ-3I;
	Fri, 25 Nov 2011 03:05:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10023-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 03:05:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10023: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10023 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10023/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1027e7d13d02
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 847 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 07:08:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 07:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTpsc-0004Pm-Nh; Fri, 25 Nov 2011 07:07:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTpsb-0004Pf-CL
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 07:07:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322204813!5712813!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13827 invoked from network); 25 Nov 2011 07:06:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 07:06:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,569,1315180800"; 
   d="scan'208";a="9122751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 07:06:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 07:06:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTprh-0003No-Pw;
	Fri, 25 Nov 2011 07:06:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTprh-0004k1-P5;
	Fri, 25 Nov 2011 07:06:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10032-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 07:06:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10032: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10032 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10032/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9955
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1027e7d13d02
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 847 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 07:08:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 07:08:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTpsc-0004Pm-Nh; Fri, 25 Nov 2011 07:07:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTpsb-0004Pf-CL
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 07:07:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322204813!5712813!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13827 invoked from network); 25 Nov 2011 07:06:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 07:06:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,569,1315180800"; 
   d="scan'208";a="9122751"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 07:06:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 07:06:29 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTprh-0003No-Pw;
	Fri, 25 Nov 2011 07:06:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTprh-0004k1-P5;
	Fri, 25 Nov 2011 07:06:29 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10032-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 07:06:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10032: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10032 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10032/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9955
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  1027e7d13d02
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 847 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 08:37:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 08:37:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTrHV-0005yx-Aa; Fri, 25 Nov 2011 08:37:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>)
	id 1RTrHT-0005yp-Gz; Fri, 25 Nov 2011 08:37:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322210170!45322460!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4022 invoked from network); 25 Nov 2011 08:36:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 08:36:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 08:36:43 +0000
Message-Id: <4ECF61A902000078000633A0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 08:36:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com>
References: <4EBD56C50200007800060781@nat28.tlf.novell.com>
	<20111125.105213.310075014.kuwa@jp.fujitsu.com>
In-Reply-To: <20111125.105213.310075014.kuwa@jp.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ia64: introduce atomic_{read,write}NN()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.11.11 at 02:52, "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com> wrote:
> Hi Jan,
> 
> Excuse me for too late response. Thank you for your work.
> But I have a question.
> 
>>>>>> On Fri, 11 Nov 2011 16:09:25 +0000
>>>>>> JBeulich@suse.com("Jan Beulich")  said:
>> 
>> +#define build_atomic_read(tag, type) \
>> +static inline type atomic_read##tag(const volatile type *addr) \
>> +{ \
>> +	type ret; \
>> +	asm volatile("ld%2.acq %0 = %1" \
>> +		     : "=r" (ret) \
>> +		     : "m" (*addr), "i" (sizeof(type))); \
>> +	return ret; \
>> +}
>> +
>> +#define build_atomic_write(tag, type) \
>> +static inline void atomic_write##tag(volatile type *addr, type val) \
>> +{ \
>> +	asm volatile("st%2.rel %0 = %1" \
>> +		     : "=m" (*addr) \
>> +		     : "r" (val), "i" (sizeof(type))); \
>> +}
> 
> Why do you use explicitly ld.acq and st.rel?
> I think that volatile variables are always accessed using ld.acq and
> st.rel and they are not required.

That would imply the compiler would attach these completers, but in
inline assembly it obviously can't.

> For example, The implementation of Linux is as follows:
> 
> #define atomic_read(v)		(*(volatile int *)&(v)->counter)
> #define atomic64_read(v)	(*(volatile long *)&(v)->counter)

Indeed - here the compiler is required to use acquire loads and
release stores. The inline assembly has to mimic this behavior.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 08:37:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 08:37:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTrHV-0005yx-Aa; Fri, 25 Nov 2011 08:37:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>)
	id 1RTrHT-0005yp-Gz; Fri, 25 Nov 2011 08:37:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322210170!45322460!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4022 invoked from network); 25 Nov 2011 08:36:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 08:36:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 08:36:43 +0000
Message-Id: <4ECF61A902000078000633A0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 08:36:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com>
References: <4EBD56C50200007800060781@nat28.tlf.novell.com>
	<20111125.105213.310075014.kuwa@jp.fujitsu.com>
In-Reply-To: <20111125.105213.310075014.kuwa@jp.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ia64: introduce atomic_{read,write}NN()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.11.11 at 02:52, "KUWAMURA Shin'ya" <kuwa@jp.fujitsu.com> wrote:
> Hi Jan,
> 
> Excuse me for too late response. Thank you for your work.
> But I have a question.
> 
>>>>>> On Fri, 11 Nov 2011 16:09:25 +0000
>>>>>> JBeulich@suse.com("Jan Beulich")  said:
>> 
>> +#define build_atomic_read(tag, type) \
>> +static inline type atomic_read##tag(const volatile type *addr) \
>> +{ \
>> +	type ret; \
>> +	asm volatile("ld%2.acq %0 = %1" \
>> +		     : "=r" (ret) \
>> +		     : "m" (*addr), "i" (sizeof(type))); \
>> +	return ret; \
>> +}
>> +
>> +#define build_atomic_write(tag, type) \
>> +static inline void atomic_write##tag(volatile type *addr, type val) \
>> +{ \
>> +	asm volatile("st%2.rel %0 = %1" \
>> +		     : "=m" (*addr) \
>> +		     : "r" (val), "i" (sizeof(type))); \
>> +}
> 
> Why do you use explicitly ld.acq and st.rel?
> I think that volatile variables are always accessed using ld.acq and
> st.rel and they are not required.

That would imply the compiler would attach these completers, but in
inline assembly it obviously can't.

> For example, The implementation of Linux is as follows:
> 
> #define atomic_read(v)		(*(volatile int *)&(v)->counter)
> #define atomic64_read(v)	(*(volatile long *)&(v)->counter)

Indeed - here the compiler is required to use acquire loads and
release stores. The inline assembly has to mimic this behavior.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 08:46:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 08:46:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTrQ3-0006S5-GS; Fri, 25 Nov 2011 08:46:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTrQ2-0006S0-7B
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 08:46:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322210716!47016747!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31121 invoked from network); 25 Nov 2011 08:45:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 08:45:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 08:45:31 +0000
Message-Id: <4ECF63BA02000078000633AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 08:45:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	<xen-devel@lists.xensource.com>
References: <a264fb979b0c5391ce91.1322157496@xdev.gridcentric.ca>
	<CAF43E1B.25838%keir.xen@gmail.com>
In-Reply-To: <CAF43E1B.25838%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Don't trigger unnecessary shadow scans on
 p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.11.11 at 19:31, Keir Fraser <keir.xen@gmail.com> wrote:
> On 24/11/2011 17:58, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>> @@ -815,6 +815,12 @@ static inline unsigned long vtlb_lookup(
>>  }
>>  #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
>>  
>> +static inline int __check_page_no_refs(struct page_info *page)
>> +{
>> +    unsigned long __count = page->count_info;
>> +    return ( (__count & PGC_count_mask) ==
>> +             ((__count & PGC_allocated) ? 1 : 0) );
> 
> It's a fussy point, but it might be better to use
> atomic_read_ulong(&page->count_info) here, to ensure that the compiler reads
> the field once only. It's cheap (compiles to a single mov instruction), but
> atomic_read_ulong doesn't exist so you'd have to add its (obvious)
> definition to asm-x86/atomic.h

I think Tim suggested anyway to use

(__count & (PGC_count_mask|PGC_allocated)) matched against
(1|PGC_allocated) here, which would eliminate the multiple read
potential if used in a switch statement.

Also, for clarity the function should probably return bool_t.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 08:46:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 08:46:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTrQ3-0006S5-GS; Fri, 25 Nov 2011 08:46:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTrQ2-0006S0-7B
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 08:46:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322210716!47016747!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31121 invoked from network); 25 Nov 2011 08:45:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 08:45:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 08:45:31 +0000
Message-Id: <4ECF63BA02000078000633AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 08:45:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"Andres Lagar-Cavilla" <andres@lagarcavilla.org>,
	<xen-devel@lists.xensource.com>
References: <a264fb979b0c5391ce91.1322157496@xdev.gridcentric.ca>
	<CAF43E1B.25838%keir.xen@gmail.com>
In-Reply-To: <CAF43E1B.25838%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Don't trigger unnecessary shadow scans on
 p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.11.11 at 19:31, Keir Fraser <keir.xen@gmail.com> wrote:
> On 24/11/2011 17:58, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>> @@ -815,6 +815,12 @@ static inline unsigned long vtlb_lookup(
>>  }
>>  #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
>>  
>> +static inline int __check_page_no_refs(struct page_info *page)
>> +{
>> +    unsigned long __count = page->count_info;
>> +    return ( (__count & PGC_count_mask) ==
>> +             ((__count & PGC_allocated) ? 1 : 0) );
> 
> It's a fussy point, but it might be better to use
> atomic_read_ulong(&page->count_info) here, to ensure that the compiler reads
> the field once only. It's cheap (compiles to a single mov instruction), but
> atomic_read_ulong doesn't exist so you'd have to add its (obvious)
> definition to asm-x86/atomic.h

I think Tim suggested anyway to use

(__count & (PGC_count_mask|PGC_allocated)) matched against
(1|PGC_allocated) here, which would eliminate the multiple read
potential if used in a switch statement.

Also, for clarity the function should probably return bool_t.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 09:18:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 09:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTruo-0006y1-31; Fri, 25 Nov 2011 09:17:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>)
	id 1RTrul-0006xq-Re; Fri, 25 Nov 2011 09:17:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322212630!2986697!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21097 invoked from network); 25 Nov 2011 09:17:10 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 09:17:10 -0000
Received: by bkbzt12 with SMTP id zt12so5384100bkb.30
	for <multiple recipients>; Fri, 25 Nov 2011 01:17:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=aI5RT5iaZtQrtG6z8vie1/RyV5U/0Eq2pprnbooXU7k=;
	b=Hjx34PshDr9eEIVj2NxMd/uKIYX2/KsOJ9XKQhX0BG+PGBzQO7XeOB/a+M2z175HJ2
	+98JBQ0rtB7yppe2j8Z/0TTGVrpsMvMJqfAE9JfXkDXngqepFqr3GIhbme2/EfzgZniW
	XHFQbNDqJJRzOtBLOPgAXwaDXnrmaXGpa2YBo=
Received: by 10.204.156.208 with SMTP id y16mr33031628bkw.72.1322212626182;
	Fri, 25 Nov 2011 01:17:06 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id j9sm18244612bkd.2.2011.11.25.01.17.03
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 01:17:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 09:16:59 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
Message-ID: <CAF50D8B.34CC9%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ia64: introduce atomic_{read,write}NN()
Thread-Index: AcyrUvv59pQsPeUDGUaXczERpZCu5g==
In-Reply-To: <4ECF61A902000078000633A0@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ia64: introduce atomic_{read,write}NN()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 08:36, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Why do you use explicitly ld.acq and st.rel?
>> I think that volatile variables are always accessed using ld.acq and
>> st.rel and they are not required.
> 
> That would imply the compiler would attach these completers, but in
> inline assembly it obviously can't.
> 
>> For example, The implementation of Linux is as follows:
>> 
>> #define atomic_read(v)  (*(volatile int *)&(v)->counter)
>> #define atomic64_read(v) (*(volatile long *)&(v)->counter)
> 
> Indeed - here the compiler is required to use acquire loads and
> release stores. The inline assembly has to mimic this behavior.

I assume Jan was mimic'ing the use of inline asm in the x86 equivalents. I
used asm for those, rather than straightforward volatile casting like in
Linux's ACCESS_ONCE() macro, just to be 100% sure about what is being
emitted by the compiler. It's not an especially compelling argument;
arch/ia64 can implement them whichever way you see fit as far as I'm
concerned.

By the by, I'm also thing about switching the naming round to
{read,write}N_atomic(), to avoid conflict with atomic_*() naming for
manipulations of atomic_t. Then I can implement {read,write}_atomic()
without the caller needing to hardcode the operation size.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 09:18:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 09:18:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTruo-0006y1-31; Fri, 25 Nov 2011 09:17:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>)
	id 1RTrul-0006xq-Re; Fri, 25 Nov 2011 09:17:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322212630!2986697!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21097 invoked from network); 25 Nov 2011 09:17:10 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 09:17:10 -0000
Received: by bkbzt12 with SMTP id zt12so5384100bkb.30
	for <multiple recipients>; Fri, 25 Nov 2011 01:17:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=aI5RT5iaZtQrtG6z8vie1/RyV5U/0Eq2pprnbooXU7k=;
	b=Hjx34PshDr9eEIVj2NxMd/uKIYX2/KsOJ9XKQhX0BG+PGBzQO7XeOB/a+M2z175HJ2
	+98JBQ0rtB7yppe2j8Z/0TTGVrpsMvMJqfAE9JfXkDXngqepFqr3GIhbme2/EfzgZniW
	XHFQbNDqJJRzOtBLOPgAXwaDXnrmaXGpa2YBo=
Received: by 10.204.156.208 with SMTP id y16mr33031628bkw.72.1322212626182;
	Fri, 25 Nov 2011 01:17:06 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id j9sm18244612bkd.2.2011.11.25.01.17.03
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 01:17:03 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 09:16:59 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
Message-ID: <CAF50D8B.34CC9%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ia64: introduce atomic_{read,write}NN()
Thread-Index: AcyrUvv59pQsPeUDGUaXczERpZCu5g==
In-Reply-To: <4ECF61A902000078000633A0@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] ia64: introduce atomic_{read,write}NN()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 08:36, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Why do you use explicitly ld.acq and st.rel?
>> I think that volatile variables are always accessed using ld.acq and
>> st.rel and they are not required.
> 
> That would imply the compiler would attach these completers, but in
> inline assembly it obviously can't.
> 
>> For example, The implementation of Linux is as follows:
>> 
>> #define atomic_read(v)  (*(volatile int *)&(v)->counter)
>> #define atomic64_read(v) (*(volatile long *)&(v)->counter)
> 
> Indeed - here the compiler is required to use acquire loads and
> release stores. The inline assembly has to mimic this behavior.

I assume Jan was mimic'ing the use of inline asm in the x86 equivalents. I
used asm for those, rather than straightforward volatile casting like in
Linux's ACCESS_ONCE() macro, just to be 100% sure about what is being
emitted by the compiler. It's not an especially compelling argument;
arch/ia64 can implement them whichever way you see fit as far as I'm
concerned.

By the by, I'm also thing about switching the naming round to
{read,write}N_atomic(), to avoid conflict with atomic_*() naming for
manipulations of atomic_t. Then I can implement {read,write}_atomic()
without the caller needing to hardcode the operation size.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 09:19:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 09:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTrwC-00071A-PH; Fri, 25 Nov 2011 09:19:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTrwA-00070v-En
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 09:19:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322212722!2987726!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7919 invoked from network); 25 Nov 2011 09:18:42 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 09:18:42 -0000
Received: by bkbzt12 with SMTP id zt12so5386389bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 01:18:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=EKJj3Xfi4yngoydxXqPgrBuZ+fR/vkoeuKK4shvZWiM=;
	b=KBmFF3bNohxOLw7pR8/KbNoTH1poO5kqYZiC+WQPkVBLf5ZlLVZZ9WUi8SQnlPvnYC
	Yt7kcSi50ydU2pvbIZwn9YU0lggNXs+GfuncOCy7kmOrkZ6XCSdrjCOdFYDNAtr8ZySI
	MGcO5rWcN1kFKqVGkDim7VZuygM4wR7WL4MXE=
Received: by 10.204.9.204 with SMTP id m12mr32973687bkm.131.1322212721995;
	Fri, 25 Nov 2011 01:18:41 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id x14sm18224794bkf.10.2011.11.25.01.18.39
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 01:18:40 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 09:18:26 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAF50DE2.34CCA%keir@xen.org>
Thread-Topic: [PATCH] Don't trigger unnecessary shadow scans on p2m entry
	update
Thread-Index: AcyrUy/U+bXI3RZt7Uqgbe9mhLCdIQ==
In-Reply-To: <4ECF63BA02000078000633AA@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Don't trigger unnecessary shadow scans on
 p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 08:45, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 24.11.11 at 19:31, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 24/11/2011 17:58, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>> @@ -815,6 +815,12 @@ static inline unsigned long vtlb_lookup(
>>>  }
>>>  #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
>>>  
>>> +static inline int __check_page_no_refs(struct page_info *page)
>>> +{
>>> +    unsigned long __count = page->count_info;
>>> +    return ( (__count & PGC_count_mask) ==
>>> +             ((__count & PGC_allocated) ? 1 : 0) );
>> 
>> It's a fussy point, but it might be better to use
>> atomic_read_ulong(&page->count_info) here, to ensure that the compiler reads
>> the field once only. It's cheap (compiles to a single mov instruction), but
>> atomic_read_ulong doesn't exist so you'd have to add its (obvious)
>> definition to asm-x86/atomic.h
> 
> I think Tim suggested anyway to use
> 
> (__count & (PGC_count_mask|PGC_allocated)) matched against
> (1|PGC_allocated) here, which would eliminate the multiple read
> potential if used in a switch statement.

Yes, that would be better.

 -- Keir

> Also, for clarity the function should probably return bool_t.
> 
> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 09:19:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 09:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTrwC-00071A-PH; Fri, 25 Nov 2011 09:19:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTrwA-00070v-En
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 09:19:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322212722!2987726!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7919 invoked from network); 25 Nov 2011 09:18:42 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 09:18:42 -0000
Received: by bkbzt12 with SMTP id zt12so5386389bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 01:18:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=EKJj3Xfi4yngoydxXqPgrBuZ+fR/vkoeuKK4shvZWiM=;
	b=KBmFF3bNohxOLw7pR8/KbNoTH1poO5kqYZiC+WQPkVBLf5ZlLVZZ9WUi8SQnlPvnYC
	Yt7kcSi50ydU2pvbIZwn9YU0lggNXs+GfuncOCy7kmOrkZ6XCSdrjCOdFYDNAtr8ZySI
	MGcO5rWcN1kFKqVGkDim7VZuygM4wR7WL4MXE=
Received: by 10.204.9.204 with SMTP id m12mr32973687bkm.131.1322212721995;
	Fri, 25 Nov 2011 01:18:41 -0800 (PST)
Received: from [192.168.1.3] (host86-129-244-131.range86-129.btcentralplus.com.
	[86.129.244.131])
	by mx.google.com with ESMTPS id x14sm18224794bkf.10.2011.11.25.01.18.39
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 01:18:40 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 09:18:26 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAF50DE2.34CCA%keir@xen.org>
Thread-Topic: [PATCH] Don't trigger unnecessary shadow scans on p2m entry
	update
Thread-Index: AcyrUy/U+bXI3RZt7Uqgbe9mhLCdIQ==
In-Reply-To: <4ECF63BA02000078000633AA@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] Don't trigger unnecessary shadow scans on
 p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 08:45, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 24.11.11 at 19:31, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 24/11/2011 17:58, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
>>> @@ -815,6 +815,12 @@ static inline unsigned long vtlb_lookup(
>>>  }
>>>  #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
>>>  
>>> +static inline int __check_page_no_refs(struct page_info *page)
>>> +{
>>> +    unsigned long __count = page->count_info;
>>> +    return ( (__count & PGC_count_mask) ==
>>> +             ((__count & PGC_allocated) ? 1 : 0) );
>> 
>> It's a fussy point, but it might be better to use
>> atomic_read_ulong(&page->count_info) here, to ensure that the compiler reads
>> the field once only. It's cheap (compiles to a single mov instruction), but
>> atomic_read_ulong doesn't exist so you'd have to add its (obvious)
>> definition to asm-x86/atomic.h
> 
> I think Tim suggested anyway to use
> 
> (__count & (PGC_count_mask|PGC_allocated)) matched against
> (1|PGC_allocated) here, which would eliminate the multiple read
> potential if used in a switch statement.

Yes, that would be better.

 -- Keir

> Also, for clarity the function should probably return bool_t.
> 
> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 09:30:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 09:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTs6X-0007J8-Ck; Fri, 25 Nov 2011 09:29:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTs6W-0007J3-01
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 09:29:56 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322213363!4943324!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 304 invoked from network); 25 Nov 2011 09:29:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 09:29:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9125231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:29:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:29:23 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTs5z-0004AM-2M;
	Fri, 25 Nov 2011 09:29:23 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTs5l-00035D-2n;
	Fri, 25 Nov 2011 09:29:09 +0000
Date: Fri, 25 Nov 2011 09:29:08 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111125092908.GA11790@spongy.cam.xci-test.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
	<20174.37746.873433.6131@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20174.37746.873433.6131@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for
 pt_pci_host_read/write
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11 06:56, Ian Jackson wrote:
> Jean Guyader writes ("[Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for pt_pci_host_read/write"):
> > pt_pci_host_read/write now takes a struct pci_dev*.
> 
> Why ?
> 
> Ian.

I found it more elegant that having to do thing like that:
        val = pt_pci_host_read(0, PCI_SLOT(pci_dev->devfn),
                0, config_addr, len);
pci_dev is already of the right type.

With the old approach you would give a B:D:F to pt_pci_host_read
then the function will call to libpci to get a pci_dev from that
to do the config space access. In pretty much all the cases we
already have a pci_dev, so I figured that we should be using it
directly.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 09:30:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 09:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTs6X-0007J8-Ck; Fri, 25 Nov 2011 09:29:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RTs6W-0007J3-01
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 09:29:56 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322213363!4943324!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 304 invoked from network); 25 Nov 2011 09:29:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 09:29:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9125231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:29:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:29:23 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RTs5z-0004AM-2M;
	Fri, 25 Nov 2011 09:29:23 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RTs5l-00035D-2n;
	Fri, 25 Nov 2011 09:29:09 +0000
Date: Fri, 25 Nov 2011 09:29:08 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111125092908.GA11790@spongy.cam.xci-test.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
	<20174.37746.873433.6131@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20174.37746.873433.6131@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for
 pt_pci_host_read/write
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/11 06:56, Ian Jackson wrote:
> Jean Guyader writes ("[Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for pt_pci_host_read/write"):
> > pt_pci_host_read/write now takes a struct pci_dev*.
> 
> Why ?
> 
> Ian.

I found it more elegant that having to do thing like that:
        val = pt_pci_host_read(0, PCI_SLOT(pci_dev->devfn),
                0, config_addr, len);
pci_dev is already of the right type.

With the old approach you would give a B:D:F to pt_pci_host_read
then the function will call to libpci to get a pci_dev from that
to do the config space access. In pretty much all the cases we
already have a pci_dev, so I figured that we should be using it
directly.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 09:34:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 09:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTsAc-0007TN-2e; Fri, 25 Nov 2011 09:34:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTsAa-0007TH-GI
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 09:34:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322213603!56434125!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28747 invoked from network); 25 Nov 2011 09:33:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 09:33:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9125331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:33:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 09:33:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 09:33:37 +0000
In-Reply-To: <20174.36255.134440.874181@mariner.uk.xensource.com>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
	<20174.36255.134440.874181@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322213618.1005.222.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 18:31 +0000, Ian Jackson wrote:
> Paul Durrant writes ("[Xen-devel] [PATCH] Add missing modprobe to xencommons"):
> > Add missing modprobe to xencommons
> ...
> > +		modprobe xen-evtchn
> 
> Is this really the way we want to do things ?  I guess it's a
> plausible thing to do which is harmless if the module name doesn't
> change.

I thought we already did this sort of thing somewhere (I thought it was
xencommons) but I guess not.

> But perhaps something else in the system should be organising that
> evtchn gets loaded ?

The problem is, I think, that there is no actual device which would
trigger the Linux hotplug subsystem to try and load this module. There
is a similar problem with things like /dev/loop. This has been a problem
since udev removed (or at least obfuscated) the old behaviour of having
a /dev node with no backing driver and modprobing on open.

Debian has /etc/udev/links.conf which says:
# This file does not exist. Please do not ask the Debian maintainer about it.
# If you need manually created devices, create them in /lib/udev/devices/ .

/lib/udev/devices is empty on my system and I can't see any
documentation about what one should create there (actual dev nodes?) In
any case it appears to be Debian specific.

We could perhaps cause the xenbus code or some other suitably core thing
to generate a hotplug event to cause these things to be autoloaded?

Also this is the sort of thing which (lib)xl could and should trivially
sanity check for at start of day.

>   Also, this isn't the only module we need.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 09:34:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 09:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTsAc-0007TN-2e; Fri, 25 Nov 2011 09:34:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTsAa-0007TH-GI
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 09:34:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322213603!56434125!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28747 invoked from network); 25 Nov 2011 09:33:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 09:33:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9125331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:33:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 09:33:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 09:33:37 +0000
In-Reply-To: <20174.36255.134440.874181@mariner.uk.xensource.com>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
	<20174.36255.134440.874181@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322213618.1005.222.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 18:31 +0000, Ian Jackson wrote:
> Paul Durrant writes ("[Xen-devel] [PATCH] Add missing modprobe to xencommons"):
> > Add missing modprobe to xencommons
> ...
> > +		modprobe xen-evtchn
> 
> Is this really the way we want to do things ?  I guess it's a
> plausible thing to do which is harmless if the module name doesn't
> change.

I thought we already did this sort of thing somewhere (I thought it was
xencommons) but I guess not.

> But perhaps something else in the system should be organising that
> evtchn gets loaded ?

The problem is, I think, that there is no actual device which would
trigger the Linux hotplug subsystem to try and load this module. There
is a similar problem with things like /dev/loop. This has been a problem
since udev removed (or at least obfuscated) the old behaviour of having
a /dev node with no backing driver and modprobing on open.

Debian has /etc/udev/links.conf which says:
# This file does not exist. Please do not ask the Debian maintainer about it.
# If you need manually created devices, create them in /lib/udev/devices/ .

/lib/udev/devices is empty on my system and I can't see any
documentation about what one should create there (actual dev nodes?) In
any case it appears to be Debian specific.

We could perhaps cause the xenbus code or some other suitably core thing
to generate a hotplug event to cause these things to be autoloaded?

Also this is the sort of thing which (lib)xl could and should trivially
sanity check for at start of day.

>   Also, this isn't the only module we need.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 09:40:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 09:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTsG6-0007fI-0X; Fri, 25 Nov 2011 09:39:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTsG4-0007fD-84
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 09:39:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322213955!2985949!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9173 invoked from network); 25 Nov 2011 09:39:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 09:39:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9125565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:39:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 09:39:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 09:39:15 +0000
In-Reply-To: <1322213618.1005.222.camel@zakaz.uk.xensource.com>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
	<20174.36255.134440.874181@mariner.uk.xensource.com>
	<1322213618.1005.222.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322213955.1005.226.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 09:33 +0000, Ian Campbell wrote:
> /lib/udev/devices is empty on my system and I can't see any
> documentation about what one should create there (actual dev nodes?) In
> any case it appears to be Debian specific.

Actually it turns out it is a core udevd feature and is documented in
udevd(8). So we could usefully create things here in our install target,
if we wanted.

That's assuming that opening /dev/xen/evtchn turns into a suitable
modprobe it should do, I think.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 09:40:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 09:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTsG6-0007fI-0X; Fri, 25 Nov 2011 09:39:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTsG4-0007fD-84
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 09:39:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322213955!2985949!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9173 invoked from network); 25 Nov 2011 09:39:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 09:39:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9125565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:39:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 09:39:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 09:39:15 +0000
In-Reply-To: <1322213618.1005.222.camel@zakaz.uk.xensource.com>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
	<20174.36255.134440.874181@mariner.uk.xensource.com>
	<1322213618.1005.222.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322213955.1005.226.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 09:33 +0000, Ian Campbell wrote:
> /lib/udev/devices is empty on my system and I can't see any
> documentation about what one should create there (actual dev nodes?) In
> any case it appears to be Debian specific.

Actually it turns out it is a core udevd feature and is documented in
udevd(8). So we could usefully create things here in our install target,
if we wanted.

That's assuming that opening /dev/xen/evtchn turns into a suitable
modprobe it should do, I think.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 10:14:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 10:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTsmz-0000BT-A7; Fri, 25 Nov 2011 10:13:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTsmx-0000BO-Pg
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 10:13:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322215960!47332497!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18869 invoked from network); 25 Nov 2011 10:12:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 10:12:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9126385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:13:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 10:13:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 10:13:17 +0000
In-Reply-To: <20174.33257.808458.54256@mariner.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
	<20174.33257.808458.54256@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322215997.1005.234.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
 html	output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 13 of 17] docs: generate an index for the html output"):
> > docs: generate an index for the html output
> > 
> > nb: I'm not a Perl wizard...
> 
> The Perl looks reasonable in general, except that some of the style is
> a bit odd.  perlstyle(1) is mostly a good guide.

Thanks for the thorough review. I've trimmed everything I agree with and
don't have a comment on.

> > +    $l =~ s/.(html)$//g;
> 
> Why the capturing parens ?

I had intended to add "|txt" etc at some point. I suppose this ought to
be (?:...) instead though.

> 
> > +    if ( $title eq "" )
> > +    {
> 
> Brace should be on the same line.
> 
> > +	$title = $h1 = "Xen Documentation";
> 
> And indent should be 4, not 1.  (Multiple occurrences.)

emacs seems to default to indentations of 4 spaces but unhelpfully turns
two lots of that into a hard tab. I'll figure out how to nix that
behaviour.

> > +	s/#.*$//;
> 
> This of course prevents link anchor texts in the inde including #,
> which is probably an error which it would be nice to sort out now
> rather than in the future when we'll have to read this script to make
> it cope.

Looks like (in the suggested code below) requiring the # to be in the
first column instead is your preferred solution here? Works for me.

> Also you probably meant to anchor the pattern.  I would do something
> like:
> 
>     s/^\s+//;
>     s/\s+$//;
>     next if m/^\#/;
>     next unless m/\S/;

I think that would be a syntax error so die unless m/\S/ ?

>     m/^(\S+)\s+(\S.*)$/ or die;
> 
> > +for (@docs) { s,^${outdir}/,, }
> 
> This is not correct because $outdir is not a regular expression.  The
> shortest way of doing this is indeed substr.

OK.

Aside: how does one dynamically construct a regex then?

> Do we really want an index per subdirectory ?

I was thinking of folks how manually type urls or who string the last
element off. Having an index in each dir ensures they get something
structured and not the apache generated thing.

It does complicate the code though so I could be convinced to drop it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 10:14:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 10:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTsmz-0000BT-A7; Fri, 25 Nov 2011 10:13:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTsmx-0000BO-Pg
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 10:13:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322215960!47332497!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18869 invoked from network); 25 Nov 2011 10:12:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 10:12:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9126385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:13:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 10:13:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 10:13:17 +0000
In-Reply-To: <20174.33257.808458.54256@mariner.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
	<20174.33257.808458.54256@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322215997.1005.234.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
 html	output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 13 of 17] docs: generate an index for the html output"):
> > docs: generate an index for the html output
> > 
> > nb: I'm not a Perl wizard...
> 
> The Perl looks reasonable in general, except that some of the style is
> a bit odd.  perlstyle(1) is mostly a good guide.

Thanks for the thorough review. I've trimmed everything I agree with and
don't have a comment on.

> > +    $l =~ s/.(html)$//g;
> 
> Why the capturing parens ?

I had intended to add "|txt" etc at some point. I suppose this ought to
be (?:...) instead though.

> 
> > +    if ( $title eq "" )
> > +    {
> 
> Brace should be on the same line.
> 
> > +	$title = $h1 = "Xen Documentation";
> 
> And indent should be 4, not 1.  (Multiple occurrences.)

emacs seems to default to indentations of 4 spaces but unhelpfully turns
two lots of that into a hard tab. I'll figure out how to nix that
behaviour.

> > +	s/#.*$//;
> 
> This of course prevents link anchor texts in the inde including #,
> which is probably an error which it would be nice to sort out now
> rather than in the future when we'll have to read this script to make
> it cope.

Looks like (in the suggested code below) requiring the # to be in the
first column instead is your preferred solution here? Works for me.

> Also you probably meant to anchor the pattern.  I would do something
> like:
> 
>     s/^\s+//;
>     s/\s+$//;
>     next if m/^\#/;
>     next unless m/\S/;

I think that would be a syntax error so die unless m/\S/ ?

>     m/^(\S+)\s+(\S.*)$/ or die;
> 
> > +for (@docs) { s,^${outdir}/,, }
> 
> This is not correct because $outdir is not a regular expression.  The
> shortest way of doing this is indeed substr.

OK.

Aside: how does one dynamically construct a regex then?

> Do we really want an index per subdirectory ?

I was thinking of folks how manually type urls or who string the last
element off. Having an index in each dir ensures they get something
structured and not the apache generated thing.

It does complicate the code though so I could be convinced to drop it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 10:47:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 10:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTtJ0-0000Qc-8R; Fri, 25 Nov 2011 10:46:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTtIy-0000QX-FM
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 10:46:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322216634!4905846!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31061 invoked from network); 25 Nov 2011 10:23:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 10:23:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9126619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:22:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 10:22:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 10:22:53 +0000
In-Reply-To: <1322156127.9567.63.camel@dagon.hellion.org.uk>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
	<20174.31130.609126.117709@mariner.uk.xensource.com>
	<1322154751.9567.56.camel@dagon.hellion.org.uk>
	<20174.32278.467007.484327@mariner.uk.xensource.com>
	<1322156127.9567.63.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322216573.1005.235.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into
 final	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:35 +0000, Ian Campbell wrote:
> On Thu, 2011-11-24 at 17:25 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final	filename"):
> > > On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote:
> > > > We don't want to leave half-generated documents lying around which
> > > > aren't fixed by "make", regardless of further dependencies, surely ?
> > > 
> > > Doesn't make automatically delete the targets if the command fails?
> > 
> > Crash-only software.  Or in other words, to write reliable software,
> > do not rely on actions which are supposed to happen on error cleanup
> > or exit.
> 
> Also, my experiments suggest that make doesn't do this anyway (perhaps
> it's only for implicit intermediaries or something).
> 
> Do you want to pickup what you can from this series having dropped this
> patch and I'll repost the rest or shall I just repost the whole lot?

I needed to rebase so I could get to work on your comments to patch 13
so I may as well repost.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 10:47:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 10:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTtJ0-0000Qc-8R; Fri, 25 Nov 2011 10:46:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTtIy-0000QX-FM
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 10:46:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322216634!4905846!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31061 invoked from network); 25 Nov 2011 10:23:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 10:23:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9126619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:22:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 10:22:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 10:22:53 +0000
In-Reply-To: <1322156127.9567.63.camel@dagon.hellion.org.uk>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<f1464f6fba419acc019c.1321542113@cosworth.uk.xensource.com>
	<20174.31130.609126.117709@mariner.uk.xensource.com>
	<1322154751.9567.56.camel@dagon.hellion.org.uk>
	<20174.32278.467007.484327@mariner.uk.xensource.com>
	<1322156127.9567.63.camel@dagon.hellion.org.uk>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322216573.1005.235.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into
 final	filename
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2011-11-24 at 17:35 +0000, Ian Campbell wrote:
> On Thu, 2011-11-24 at 17:25 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final	filename"):
> > > On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote:
> > > > We don't want to leave half-generated documents lying around which
> > > > aren't fixed by "make", regardless of further dependencies, surely ?
> > > 
> > > Doesn't make automatically delete the targets if the command fails?
> > 
> > Crash-only software.  Or in other words, to write reliable software,
> > do not rely on actions which are supposed to happen on error cleanup
> > or exit.
> 
> Also, my experiments suggest that make doesn't do this anyway (perhaps
> it's only for implicit intermediaries or something).
> 
> Do you want to pickup what you can from this series having dropped this
> patch and I'll repost the rest or shall I just repost the whole lot?

I needed to rebase so I could get to work on your comments to patch 13
so I may as well repost.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 11:13:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 11:13:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTti0-0000hk-Oz; Fri, 25 Nov 2011 11:12:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RTthz-0000hc-Hi
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 11:12:43 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322219410!45776641!1
X-Originating-IP: [216.139.236.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22922 invoked from network); 25 Nov 2011 11:10:11 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Nov 2011 11:10:11 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RTthR-0004Hn-GC
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 03:12:09 -0800
Date: Fri, 25 Nov 2011 03:12:09 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1322219529495-5022556.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I try to use cdrom in domU linux pv, on Lucid and Natty with
'phy:/dev/scd0,xvdc,r' see it as internal disk (not cdrom) and only
administrators can mount it, i try also 'phy:/dev/scd0,xvdc1,r' but not
work.
On Oneiric and Precise (daily build) with 'phy:/dev/scd0,xvdc,r' see it as
cdrom but not automount it, work only manual mount of xvdc; i try also
'phy:/dev/scd0,xvdc1,r' but not work.
Is possible use cdrom on linux domU pv full working where also normal user
can mount it without terminal?
I do something wrong, or there are still bugs in this regard?
Thanks for any reply.

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5022556p5022556.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 11:13:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 11:13:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTti0-0000hk-Oz; Fri, 25 Nov 2011 11:12:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RTthz-0000hc-Hi
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 11:12:43 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322219410!45776641!1
X-Originating-IP: [216.139.236.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22922 invoked from network); 25 Nov 2011 11:10:11 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Nov 2011 11:10:11 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RTthR-0004Hn-GC
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 03:12:09 -0800
Date: Fri, 25 Nov 2011 03:12:09 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1322219529495-5022556.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I try to use cdrom in domU linux pv, on Lucid and Natty with
'phy:/dev/scd0,xvdc,r' see it as internal disk (not cdrom) and only
administrators can mount it, i try also 'phy:/dev/scd0,xvdc1,r' but not
work.
On Oneiric and Precise (daily build) with 'phy:/dev/scd0,xvdc,r' see it as
cdrom but not automount it, work only manual mount of xvdc; i try also
'phy:/dev/scd0,xvdc1,r' but not work.
Is possible use cdrom on linux domU pv full working where also normal user
can mount it without terminal?
I do something wrong, or there are still bugs in this regard?
Thanks for any reply.

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5022556p5022556.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 11:24:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 11:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTtsT-0000tU-Uw; Fri, 25 Nov 2011 11:23:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RTtsS-0000tP-5g
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 11:23:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322220178!4601438!1
X-Originating-IP: [209.85.210.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29619 invoked from network); 25 Nov 2011 11:22:59 -0000
Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com)
	(209.85.210.49)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 11:22:59 -0000
Received: by pzk6 with SMTP id 6so239624pzk.8
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 03:22:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=tN2RIuXra80/9r8rbvo0X8N6oROmYRezGnHGiJfTOyY=;
	b=URqNyB8nAzNPc7XGMZ8Bx66Nsx1LACrH2nLL2BY9oR4XnZikTHvH4+4SLHUXm6ocHC
	nUluSN7xT2gc0NAcIlnlOABw7QuSha42y+k5kBEKmJ65KO/duZg1H8FW2hqH6Vd4nkSf
	4mEcHKGVZWEKDTKkcm8sWc/kAD50PMlw14Rwg=
MIME-Version: 1.0
Received: by 10.68.58.7 with SMTP id m7mr26154629pbq.106.1322220177829; Fri,
	25 Nov 2011 03:22:57 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 25 Nov 2011 03:22:57 -0800 (PST)
In-Reply-To: <8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
Date: Fri, 25 Nov 2011 12:22:57 +0100
X-Google-Sender-Auth: Ml8rq588RKqaYEwqyamT1Aa5apc
Message-ID: <CAPLaKK7weZ-25xFnRrmcAMr=BQwPZmHoLxKJXKbsDp78EXd9Vg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
	html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8xNyBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPjoKPiAjIEhH
IGNoYW5nZXNldCBwYXRjaAo+ICMgVXNlciBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRy
aXguY29tPgo+ICMgRGF0ZSAxMzIxNTQyMDc1IDAKPiAjIE5vZGUgSUQgOGYyNDA0ZWVmOGZhYzgw
MjA1MjhiNDA4YjNhOTU4ZDgxY2JiNzNjMAo+ICMgUGFyZW50IMKgYzFmODQwNmRhNTA3NDNjZDA1
OTdiOTNjNGI1YjhiNmZmMDNlZGU0Mgo+IGRvY3M6IGdlbmVyYXRlIGFuIGluZGV4IGZvciB0aGUg
aHRtbCBvdXRwdXQKPgo+IG5iOiBJJ20gbm90IGEgUGVybCB3aXphcmQuLi4KPgo+IFNpZ25lZC1v
ZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4KPiBkaWZmIC1y
IGMxZjg0MDZkYTUwNyAtciA4ZjI0MDRlZWY4ZmEgZG9jcy9JTkRFWAo+IC0tLSAvZGV2L251bGwg
wqAgVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCj4gKysrIGIvZG9jcy9JTkRFWCDCoCDC
oCDCoCDCoFRodSBOb3YgMTcgMTU6MDE6MTUgMjAxMSArMDAwMAo+IEBAIC0wLDAgKzEsNSBAQAo+
ICttaXNjL2h2bS1lbXVsYXRlZC11bnBsdWcgwqAgwqAgwqAgWGVuIEhWTSBlbXVsYXRlZCBkZXZp
Y2UgdW5wbHVnIHByb3RvY29sCj4gKwo+ICsjIFRoZXNlIGFyZSBub3QgYWxsIHRoYXQgdXNlZnVs
IGFueW1vcmUsIGhpZGUgdGhlbSBmcm9tIHRoZSBpbmRleAo+ICtpbnRlcmZhY2UvaW5kZXggwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBOTy1JTkRFWAo+ICt1c2VyL2luZGV4IMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE5PLUlOREVYCj4gZGlmZiAtciBjMWY4NDA2ZGE1
MDcgLXIgOGYyNDA0ZWVmOGZhIGRvY3MvTWFrZWZpbGUKPiAtLS0gYS9kb2NzL01ha2VmaWxlIMKg
IMKgIFRodSBOb3YgMTcgMTQ6NTQ6MzggMjAxMSArMDAwMAo+ICsrKyBiL2RvY3MvTWFrZWZpbGUg
wqAgwqAgVGh1IE5vdiAxNyAxNTowMToxNSAyMDExICswMDAwCj4gQEAgLTQ1LDcgKzQ1LDcgQEAg
cHM6ICQoRE9DX1BTKQo+IMKgcGRmOiAkKERPQ19QREYpCj4KPiDCoC5QSE9OWTogaHRtbAo+IC1o
dG1sOiAkKERPQ19IVE1MKQo+ICtodG1sOiAkKERPQ19IVE1MKSBodG1sL2luZGV4Lmh0bWwKPgo+
IMKgLlBIT05ZOiB0eHQKPiDCoHR4dDogJChET0NfVFhUKQo+IEBAIC0xMjgsNiArMTI4LDkgQEAg
aHRtbC8lL2luZGV4Lmh0bWw6IHNyYy8lLnRleAo+IMKgIMKgIMKgIMKgJDwgMT4vZGV2L251bGwg
Mj4vZGV2L251bGwgOyBlbHNlIFwKPiDCoCDCoCDCoCDCoGVjaG8gImxhdGV4Mmh0bWwgbm90IGlu
c3RhbGxlZDsgc2tpcHBpbmcgJCouIjsgZmkKPgo+ICtodG1sL2luZGV4Lmh0bWw6ICQoRE9DX0hU
TUwpIC4vZ2VuLWh0bWwtaW5kZXggSU5ERVgKPiArIMKgIMKgIMKgIC4vZ2VuLWh0bWwtaW5kZXgg
LWkgSU5ERVggaHRtbCAkKERPQ19IVE1MKQo+ICsKPiDCoGh0bWwvJS5odG1sOiAlLm1hcmtkb3du
Cj4gwqAgwqAgwqAgwqBAJChJTlNUQUxMX0RJUikgJChARCkKPiDCoCDCoCDCoCDCoEBzZXQgLWUg
OyBpZiB3aGljaCAkKE1BUktET1dOKSAxPi9kZXYvbnVsbCAyPi9kZXYvbnVsbDsgdGhlbiBcCj4g
ZGlmZiAtciBjMWY4NDA2ZGE1MDcgLXIgOGYyNDA0ZWVmOGZhIGRvY3MvZ2VuLWh0bWwtaW5kZXgK
PiAtLS0gL2Rldi9udWxsIMKgIFRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAo+ICsrKyBi
L2RvY3MvZ2VuLWh0bWwtaW5kZXggwqAgwqAgwqAgVGh1IE5vdiAxNyAxNTowMToxNSAyMDExICsw
MDAwCj4gQEAgLTAsMCArMSwxMjkgQEAKPiArIyEvdXNyL2Jpbi9wZXJsIC13CgpQbGVhc2UgdXNl
ICIvdXNyL2Jpbi9lbnYgcGVybCIgb3IgY2FsbCB0aGUgc2NyaXB0IGZyb20gdGhlIE1ha2VmaWxl
CndpdGggInBlcmwgLi8uLi4iIChhcyBJYW4gSmFja3NvbiBoYXMgZG9uZSBpbiBoaXMgcGF0Y2gg
dG8gaW1wb3J0CnF1ZXVlLmgpCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Nov 25 11:24:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 11:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTtsT-0000tU-Uw; Fri, 25 Nov 2011 11:23:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RTtsS-0000tP-5g
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 11:23:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322220178!4601438!1
X-Originating-IP: [209.85.210.49]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29619 invoked from network); 25 Nov 2011 11:22:59 -0000
Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com)
	(209.85.210.49)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 11:22:59 -0000
Received: by pzk6 with SMTP id 6so239624pzk.8
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 03:22:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=tN2RIuXra80/9r8rbvo0X8N6oROmYRezGnHGiJfTOyY=;
	b=URqNyB8nAzNPc7XGMZ8Bx66Nsx1LACrH2nLL2BY9oR4XnZikTHvH4+4SLHUXm6ocHC
	nUluSN7xT2gc0NAcIlnlOABw7QuSha42y+k5kBEKmJ65KO/duZg1H8FW2hqH6Vd4nkSf
	4mEcHKGVZWEKDTKkcm8sWc/kAD50PMlw14Rwg=
MIME-Version: 1.0
Received: by 10.68.58.7 with SMTP id m7mr26154629pbq.106.1322220177829; Fri,
	25 Nov 2011 03:22:57 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 25 Nov 2011 03:22:57 -0800 (PST)
In-Reply-To: <8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
Date: Fri, 25 Nov 2011 12:22:57 +0100
X-Google-Sender-Auth: Ml8rq588RKqaYEwqyamT1Aa5apc
Message-ID: <CAPLaKK7weZ-25xFnRrmcAMr=BQwPZmHoLxKJXKbsDp78EXd9Vg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
	html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8xNyBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPjoKPiAjIEhH
IGNoYW5nZXNldCBwYXRjaAo+ICMgVXNlciBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRy
aXguY29tPgo+ICMgRGF0ZSAxMzIxNTQyMDc1IDAKPiAjIE5vZGUgSUQgOGYyNDA0ZWVmOGZhYzgw
MjA1MjhiNDA4YjNhOTU4ZDgxY2JiNzNjMAo+ICMgUGFyZW50IMKgYzFmODQwNmRhNTA3NDNjZDA1
OTdiOTNjNGI1YjhiNmZmMDNlZGU0Mgo+IGRvY3M6IGdlbmVyYXRlIGFuIGluZGV4IGZvciB0aGUg
aHRtbCBvdXRwdXQKPgo+IG5iOiBJJ20gbm90IGEgUGVybCB3aXphcmQuLi4KPgo+IFNpZ25lZC1v
ZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4KPiBkaWZmIC1y
IGMxZjg0MDZkYTUwNyAtciA4ZjI0MDRlZWY4ZmEgZG9jcy9JTkRFWAo+IC0tLSAvZGV2L251bGwg
wqAgVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCj4gKysrIGIvZG9jcy9JTkRFWCDCoCDC
oCDCoCDCoFRodSBOb3YgMTcgMTU6MDE6MTUgMjAxMSArMDAwMAo+IEBAIC0wLDAgKzEsNSBAQAo+
ICttaXNjL2h2bS1lbXVsYXRlZC11bnBsdWcgwqAgwqAgwqAgWGVuIEhWTSBlbXVsYXRlZCBkZXZp
Y2UgdW5wbHVnIHByb3RvY29sCj4gKwo+ICsjIFRoZXNlIGFyZSBub3QgYWxsIHRoYXQgdXNlZnVs
IGFueW1vcmUsIGhpZGUgdGhlbSBmcm9tIHRoZSBpbmRleAo+ICtpbnRlcmZhY2UvaW5kZXggwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBOTy1JTkRFWAo+ICt1c2VyL2luZGV4IMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE5PLUlOREVYCj4gZGlmZiAtciBjMWY4NDA2ZGE1
MDcgLXIgOGYyNDA0ZWVmOGZhIGRvY3MvTWFrZWZpbGUKPiAtLS0gYS9kb2NzL01ha2VmaWxlIMKg
IMKgIFRodSBOb3YgMTcgMTQ6NTQ6MzggMjAxMSArMDAwMAo+ICsrKyBiL2RvY3MvTWFrZWZpbGUg
wqAgwqAgVGh1IE5vdiAxNyAxNTowMToxNSAyMDExICswMDAwCj4gQEAgLTQ1LDcgKzQ1LDcgQEAg
cHM6ICQoRE9DX1BTKQo+IMKgcGRmOiAkKERPQ19QREYpCj4KPiDCoC5QSE9OWTogaHRtbAo+IC1o
dG1sOiAkKERPQ19IVE1MKQo+ICtodG1sOiAkKERPQ19IVE1MKSBodG1sL2luZGV4Lmh0bWwKPgo+
IMKgLlBIT05ZOiB0eHQKPiDCoHR4dDogJChET0NfVFhUKQo+IEBAIC0xMjgsNiArMTI4LDkgQEAg
aHRtbC8lL2luZGV4Lmh0bWw6IHNyYy8lLnRleAo+IMKgIMKgIMKgIMKgJDwgMT4vZGV2L251bGwg
Mj4vZGV2L251bGwgOyBlbHNlIFwKPiDCoCDCoCDCoCDCoGVjaG8gImxhdGV4Mmh0bWwgbm90IGlu
c3RhbGxlZDsgc2tpcHBpbmcgJCouIjsgZmkKPgo+ICtodG1sL2luZGV4Lmh0bWw6ICQoRE9DX0hU
TUwpIC4vZ2VuLWh0bWwtaW5kZXggSU5ERVgKPiArIMKgIMKgIMKgIC4vZ2VuLWh0bWwtaW5kZXgg
LWkgSU5ERVggaHRtbCAkKERPQ19IVE1MKQo+ICsKPiDCoGh0bWwvJS5odG1sOiAlLm1hcmtkb3du
Cj4gwqAgwqAgwqAgwqBAJChJTlNUQUxMX0RJUikgJChARCkKPiDCoCDCoCDCoCDCoEBzZXQgLWUg
OyBpZiB3aGljaCAkKE1BUktET1dOKSAxPi9kZXYvbnVsbCAyPi9kZXYvbnVsbDsgdGhlbiBcCj4g
ZGlmZiAtciBjMWY4NDA2ZGE1MDcgLXIgOGYyNDA0ZWVmOGZhIGRvY3MvZ2VuLWh0bWwtaW5kZXgK
PiAtLS0gL2Rldi9udWxsIMKgIFRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAo+ICsrKyBi
L2RvY3MvZ2VuLWh0bWwtaW5kZXggwqAgwqAgwqAgVGh1IE5vdiAxNyAxNTowMToxNSAyMDExICsw
MDAwCj4gQEAgLTAsMCArMSwxMjkgQEAKPiArIyEvdXNyL2Jpbi9wZXJsIC13CgpQbGVhc2UgdXNl
ICIvdXNyL2Jpbi9lbnYgcGVybCIgb3IgY2FsbCB0aGUgc2NyaXB0IGZyb20gdGhlIE1ha2VmaWxl
CndpdGggInBlcmwgLi8uLi4iIChhcyBJYW4gSmFja3NvbiBoYXMgZG9uZSBpbiBoaXMgcGF0Y2gg
dG8gaW1wb3J0CnF1ZXVlLmgpCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Nov 25 11:51:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 11:51:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuIu-0001jG-LM; Fri, 25 Nov 2011 11:50:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTuIt-0001iw-2U
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 11:50:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322221790!45360824!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5623 invoked from network); 25 Nov 2011 11:49:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 11:49:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9128623"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 11:50:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 11:50:23 +0000
Date: Fri, 25 Nov 2011 11:51:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <CAJJyHjL6pmt53GARCaV1QRC4Zam7uX6Huf_AON8ZZswmxt4YaQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111251146100.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-6-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.00.1111241816250.31179@kaball-desktop>
	<CAJJyHjL6pmt53GARCaV1QRC4Zam7uX6Huf_AON8ZZswmxt4YaQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1530592377-1322221888=:31179"
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 5/5] vga-cirrus: Workaround
 during restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1530592377-1322221888=:31179
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

> On Thu, Nov 24, 2011 at 18:30, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> >
> >> @@ -2784,9 +2796,11 @@ static void cirrus_reset(void *opaque)
> >>      }
> >>      s->vga.cr[0x27] = s->device_id;
> >>
> >> -    /* Win2K seems to assume that the pattern buffer is at 0xff
> >> -       initially ! */
> >> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> >> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
> >> +        /* Win2K seems to assume that the pattern buffer is at 0xff
> >> +           initially ! */
> >> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> >> +    }
> >>
> >
> > this is not too bad, I suppose that the videoram is going to be written
> > again at restore time anyway so at least it saves some cycles
> 
> Actually, I think the next time that this vram will be written again
> is, when the guest is actually "waked-up" and wrote something there.
> Otherwise, the "restore" of the vram is done before QEMU start. So,
> the memset could leave some weard stuff the screen (a white screen?).
 
So this is the succession of events:

- vga_common_init
allocates the videoram

- cirrus_reset
sets set videoram to 0xff

- load_vmstate
the old videoram is copied over, overwriting what cirrus_reset has done

therefore setting the videoram to 0xff when resuming is a waste of
efforts
--8323329-1530592377-1322221888=:31179
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1530592377-1322221888=:31179--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 11:51:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 11:51:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuIu-0001jG-LM; Fri, 25 Nov 2011 11:50:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTuIt-0001iw-2U
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 11:50:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322221790!45360824!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5623 invoked from network); 25 Nov 2011 11:49:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 11:49:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; 
   d="scan'208";a="9128623"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 11:50:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 11:50:23 +0000
Date: Fri, 25 Nov 2011 11:51:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony PERARD <anthony.perard@citrix.com>
In-Reply-To: <CAJJyHjL6pmt53GARCaV1QRC4Zam7uX6Huf_AON8ZZswmxt4YaQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111251146100.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-6-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.00.1111241816250.31179@kaball-desktop>
	<CAJJyHjL6pmt53GARCaV1QRC4Zam7uX6Huf_AON8ZZswmxt4YaQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1530592377-1322221888=:31179"
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 5/5] vga-cirrus: Workaround
 during restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1530592377-1322221888=:31179
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

> On Thu, Nov 24, 2011 at 18:30, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> >
> >> @@ -2784,9 +2796,11 @@ static void cirrus_reset(void *opaque)
> >>      }
> >>      s->vga.cr[0x27] = s->device_id;
> >>
> >> -    /* Win2K seems to assume that the pattern buffer is at 0xff
> >> -       initially ! */
> >> -    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> >> +    if (!runstate_check(RUN_STATE_PREMIGRATE)) {
> >> +        /* Win2K seems to assume that the pattern buffer is at 0xff
> >> +           initially ! */
> >> +        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
> >> +    }
> >>
> >
> > this is not too bad, I suppose that the videoram is going to be written
> > again at restore time anyway so at least it saves some cycles
> 
> Actually, I think the next time that this vram will be written again
> is, when the guest is actually "waked-up" and wrote something there.
> Otherwise, the "restore" of the vram is done before QEMU start. So,
> the memset could leave some weard stuff the screen (a white screen?).
 
So this is the succession of events:

- vga_common_init
allocates the videoram

- cirrus_reset
sets set videoram to 0xff

- load_vmstate
the old videoram is copied over, overwriting what cirrus_reset has done

therefore setting the videoram to 0xff when resuming is a waste of
efforts
--8323329-1530592377-1322221888=:31179
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1530592377-1322221888=:31179--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:14:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTueq-0002SI-39; Fri, 25 Nov 2011 12:13:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RTuen-0002Rt-WC; Fri, 25 Nov 2011 12:13:30 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322223141!64645928!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20560 invoked from network); 25 Nov 2011 12:12:21 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:12:21 -0000
Received: by fagn18 with SMTP id n18so590974fag.30
	for <multiple recipients>; Fri, 25 Nov 2011 04:13:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=5wkYTP6UiDZK8P/x/w8Gj1wmKlorMrJEfSB6ZhSE/O8=;
	b=Fv5Fa0KG5Lmm1R7DxgAsARbVX4Uw2uv5w3W//s8RHT0/7h5eKsAwlMqlZdTjGfTzDt
	bbnWRXLQIGNvVdfXw4nPE2/Ml3rCgQLsjrMUqOMO7zYLtZwAMGrquqcvAloVo/NQT5mE
	ai/0WzHfu2ORCO27uankimv1WlrLBrJ+BbK34=
Received: by 10.204.152.25 with SMTP id e25mr34275983bkw.51.1322223180680;
	Fri, 25 Nov 2011 04:13:00 -0800 (PST)
Received: from [172.16.25.10] (5e0575b0.bb.sky.com. [94.5.117.176])
	by mx.google.com with ESMTPS id e8sm18624772bkd.7.2011.11.25.04.12.58
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 04:12:59 -0800 (PST)
Message-ID: <4ECF8648.9020108@xen.org>
Date: Fri, 25 Nov 2011 12:12:56 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, 
	xen-arm@lists.xensource.com
Subject: [Xen-devel] Xen Document Day: November 29th
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8076194431292431066=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============8076194431292431066==
Content-Type: multipart/alternative;
 boundary="------------030900070306080905070905"

This is a multi-part message in MIME format.
--------------030900070306080905070905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,

after the last Xen Document Day, many people asked me when we would do 
another document day. After a discussion on the mailing list, we settled 
on next Tuesday (November 29). This will be an all-day on-line IRC event 
with the aim to

  * Improve user documentation
  * Improve developer documentation, including the creation of man
    pages, etc.

There is no hard start and end to the event, but volunteers in the UK 
will be on-line on *Nov 29th* from around 9:00 UTC+1 until around 18:00 
UTC+1, and then volunteers from the US will take over. The event will be 
take place on freenode channel *#xendocday*

An intial work item lists and what we agreed on can be found on the 
Documentation Day Etherpad <http://openetherpad.org/TSPGIEOBiS>. Other 
work that needs doing is:

  * Improve user and wiki documentation
      o Migrate remaining wiki pages
        <http://wiki.xen.org/wiki/Wiki_Community/Migration_Instructions_from_Old_to_New_Xen_Wiki>
      o Pages that need reviewing/fixing
        <http://wiki.xen.org/wiki/Category:Contains_Needs_Action>
      o Pages that need formatting
        <http://wiki.xen.org/wiki/Category:Contains_Needs_Formatting>
      o Missing pages (many may just need to be migrated), some may be
        obsolete <http://wiki.xen.org/wiki/Special:WantedPages>
  * Improve developer documentation, including the creation of man
    pages, etc.

But anyway, a long list of stuff that is needed can be found on the 
Documentation Day Etherpad <http://openetherpad.org/TSPGIEOBiS>. I am 
sure, you will find something that suits you. Instructions on how to use 
the new wiki, can be found here 
<http://wiki.xen.org/wiki/Wiki_Community> and on the front-page.

*The Protocol*

  * Join us on IRC: freenode channel *#xendocday*
  * Tell people what you intend to work on (to avoid doing something
    somebody else is already working on)
  * Fix some documentation
  * Help others
  * And above all: have fun!

I am looking forward to the day and hopefully documentation days will 
become a regular Xen event. See you on IRC!

Regards
Lars


--------------030900070306080905070905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    <br>
    after the last Xen Document Day, many people asked me when we would
    do another document day. After a discussion on the mailing list, we
    settled on next Tuesday (November 29). This will be an all-day
    on-line IRC event with the aim to
    <ul>
      <li>Improve user documentation</li>
      <li>Improve developer documentation, including the creation of man
        pages, etc.</li>
    </ul>
    <p>There is no hard start and end to the event, but volunteers in
      the UK will be on-line on <strong>Nov 29th</strong> from around
      9:00 UTC+1 until around 18:00 UTC+1, and then volunteers from the
      US will take over. The event will be take place on freenode
      channel <strong>#xendocday</strong></p>
    <p>An intial work item lists and what we agreed on can be found on
      the <a href="http://openetherpad.org/TSPGIEOBiS">Documentation
        Day Etherpad</a>. Other work that needs doing is:</p>
    <ul>
      <li>Improve user and wiki documentation
        <ul>
          <li><a
href="http://wiki.xen.org/wiki/Wiki_Community/Migration_Instructions_from_Old_to_New_Xen_Wiki">Migrate
              remaining wiki pages</a></li>
          <li><a
              href="http://wiki.xen.org/wiki/Category:Contains_Needs_Action">Pages
              that need reviewing/fixing</a></li>
          <li><a
              href="http://wiki.xen.org/wiki/Category:Contains_Needs_Formatting">Pages
              that need formatting</a></li>
          <li><a href="http://wiki.xen.org/wiki/Special:WantedPages">Missing
              pages (many may just need to be migrated), some may be
              obsolete</a></li>
        </ul>
      </li>
      <li>Improve developer documentation, including the creation of man
        pages, etc.</li>
    </ul>
    <p>But anyway, a long list of stuff that is needed can be found on
      the <a href="http://openetherpad.org/TSPGIEOBiS">Documentation
        Day Etherpad</a>. I am sure, you will find something that suits
      you. Instructions on how to use the new wiki, can be found <a
        href="http://wiki.xen.org/wiki/Wiki_Community">here</a> and on
      the front-page.</p>
    <p><strong>The Protocol</strong></p>
    <ul>
      <li>Join us on IRC: freenode channel <strong>#xendocday</strong></li>
      <li>Tell people what you intend to work on (to avoid doing
        something somebody else is already working on)</li>
      <li>Fix some documentation</li>
      <li>Help others</li>
      <li>And above all: have fun!</li>
    </ul>
    <p>I am looking forward to the day and hopefully documentation days
      will become a regular Xen event. See you on IRC!<br>
    </p>
    <p>Regards<br>
      Lars<br>
    </p>
  </body>
</html>

--------------030900070306080905070905--


--===============8076194431292431066==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8076194431292431066==--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:14:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTueq-0002SI-39; Fri, 25 Nov 2011 12:13:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RTuen-0002Rt-WC; Fri, 25 Nov 2011 12:13:30 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322223141!64645928!1
X-Originating-IP: [209.85.161.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20560 invoked from network); 25 Nov 2011 12:12:21 -0000
Received: from mail-fx0-f43.google.com (HELO mail-fx0-f43.google.com)
	(209.85.161.43)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:12:21 -0000
Received: by fagn18 with SMTP id n18so590974fag.30
	for <multiple recipients>; Fri, 25 Nov 2011 04:13:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=5wkYTP6UiDZK8P/x/w8Gj1wmKlorMrJEfSB6ZhSE/O8=;
	b=Fv5Fa0KG5Lmm1R7DxgAsARbVX4Uw2uv5w3W//s8RHT0/7h5eKsAwlMqlZdTjGfTzDt
	bbnWRXLQIGNvVdfXw4nPE2/Ml3rCgQLsjrMUqOMO7zYLtZwAMGrquqcvAloVo/NQT5mE
	ai/0WzHfu2ORCO27uankimv1WlrLBrJ+BbK34=
Received: by 10.204.152.25 with SMTP id e25mr34275983bkw.51.1322223180680;
	Fri, 25 Nov 2011 04:13:00 -0800 (PST)
Received: from [172.16.25.10] (5e0575b0.bb.sky.com. [94.5.117.176])
	by mx.google.com with ESMTPS id e8sm18624772bkd.7.2011.11.25.04.12.58
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 04:12:59 -0800 (PST)
Message-ID: <4ECF8648.9020108@xen.org>
Date: Fri, 25 Nov 2011 12:12:56 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, 
	xen-arm@lists.xensource.com
Subject: [Xen-devel] Xen Document Day: November 29th
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8076194431292431066=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============8076194431292431066==
Content-Type: multipart/alternative;
 boundary="------------030900070306080905070905"

This is a multi-part message in MIME format.
--------------030900070306080905070905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi everybody,

after the last Xen Document Day, many people asked me when we would do 
another document day. After a discussion on the mailing list, we settled 
on next Tuesday (November 29). This will be an all-day on-line IRC event 
with the aim to

  * Improve user documentation
  * Improve developer documentation, including the creation of man
    pages, etc.

There is no hard start and end to the event, but volunteers in the UK 
will be on-line on *Nov 29th* from around 9:00 UTC+1 until around 18:00 
UTC+1, and then volunteers from the US will take over. The event will be 
take place on freenode channel *#xendocday*

An intial work item lists and what we agreed on can be found on the 
Documentation Day Etherpad <http://openetherpad.org/TSPGIEOBiS>. Other 
work that needs doing is:

  * Improve user and wiki documentation
      o Migrate remaining wiki pages
        <http://wiki.xen.org/wiki/Wiki_Community/Migration_Instructions_from_Old_to_New_Xen_Wiki>
      o Pages that need reviewing/fixing
        <http://wiki.xen.org/wiki/Category:Contains_Needs_Action>
      o Pages that need formatting
        <http://wiki.xen.org/wiki/Category:Contains_Needs_Formatting>
      o Missing pages (many may just need to be migrated), some may be
        obsolete <http://wiki.xen.org/wiki/Special:WantedPages>
  * Improve developer documentation, including the creation of man
    pages, etc.

But anyway, a long list of stuff that is needed can be found on the 
Documentation Day Etherpad <http://openetherpad.org/TSPGIEOBiS>. I am 
sure, you will find something that suits you. Instructions on how to use 
the new wiki, can be found here 
<http://wiki.xen.org/wiki/Wiki_Community> and on the front-page.

*The Protocol*

  * Join us on IRC: freenode channel *#xendocday*
  * Tell people what you intend to work on (to avoid doing something
    somebody else is already working on)
  * Fix some documentation
  * Help others
  * And above all: have fun!

I am looking forward to the day and hopefully documentation days will 
become a regular Xen event. See you on IRC!

Regards
Lars


--------------030900070306080905070905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi everybody,<br>
    <br>
    after the last Xen Document Day, many people asked me when we would
    do another document day. After a discussion on the mailing list, we
    settled on next Tuesday (November 29). This will be an all-day
    on-line IRC event with the aim to
    <ul>
      <li>Improve user documentation</li>
      <li>Improve developer documentation, including the creation of man
        pages, etc.</li>
    </ul>
    <p>There is no hard start and end to the event, but volunteers in
      the UK will be on-line on <strong>Nov 29th</strong> from around
      9:00 UTC+1 until around 18:00 UTC+1, and then volunteers from the
      US will take over. The event will be take place on freenode
      channel <strong>#xendocday</strong></p>
    <p>An intial work item lists and what we agreed on can be found on
      the <a href="http://openetherpad.org/TSPGIEOBiS">Documentation
        Day Etherpad</a>. Other work that needs doing is:</p>
    <ul>
      <li>Improve user and wiki documentation
        <ul>
          <li><a
href="http://wiki.xen.org/wiki/Wiki_Community/Migration_Instructions_from_Old_to_New_Xen_Wiki">Migrate
              remaining wiki pages</a></li>
          <li><a
              href="http://wiki.xen.org/wiki/Category:Contains_Needs_Action">Pages
              that need reviewing/fixing</a></li>
          <li><a
              href="http://wiki.xen.org/wiki/Category:Contains_Needs_Formatting">Pages
              that need formatting</a></li>
          <li><a href="http://wiki.xen.org/wiki/Special:WantedPages">Missing
              pages (many may just need to be migrated), some may be
              obsolete</a></li>
        </ul>
      </li>
      <li>Improve developer documentation, including the creation of man
        pages, etc.</li>
    </ul>
    <p>But anyway, a long list of stuff that is needed can be found on
      the <a href="http://openetherpad.org/TSPGIEOBiS">Documentation
        Day Etherpad</a>. I am sure, you will find something that suits
      you. Instructions on how to use the new wiki, can be found <a
        href="http://wiki.xen.org/wiki/Wiki_Community">here</a> and on
      the front-page.</p>
    <p><strong>The Protocol</strong></p>
    <ul>
      <li>Join us on IRC: freenode channel <strong>#xendocday</strong></li>
      <li>Tell people what you intend to work on (to avoid doing
        something somebody else is already working on)</li>
      <li>Fix some documentation</li>
      <li>Help others</li>
      <li>And above all: have fun!</li>
    </ul>
    <p>I am looking forward to the day and hopefully documentation days
      will become a regular Xen event. See you on IRC!<br>
    </p>
    <p>Regards<br>
      Lars<br>
    </p>
  </body>
</html>

--------------030900070306080905070905--


--===============8076194431292431066==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8076194431292431066==--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:17:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuij-0002ql-Hj; Fri, 25 Nov 2011 12:17:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTuii-0002qW-Bz
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:17:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322223409!47059500!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30402 invoked from network); 25 Nov 2011 12:16:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:16:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9129225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:16:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 12:16:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTui2-00050t-U1; Fri, 25 Nov 2011 12:16:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTui2-0007Jh-SJ;
	Fri, 25 Nov 2011 12:16:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20175.34610.865081.821439@mariner.uk.xensource.com>
Date: Fri, 25 Nov 2011 12:16:50 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-10032-mainreport@xen.org>
References: <osstest-10032-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: keir@xen.org
Subject: Re: [Xen-devel] [xen-unstable test] 10032: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 10032: regressions - FAIL"):
> flight 10032 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10032/
...
> Tests which did not succeed and are blocking:
>  test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
>  test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
>  test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
>  test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
>  test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

It looks like something has completely broken HVM.  My bisector is
working on it and should report later today.

Maybe we should stop throwing things into the tree until we get a
pass and push.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:17:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:17:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuij-0002ql-Hj; Fri, 25 Nov 2011 12:17:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTuii-0002qW-Bz
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:17:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322223409!47059500!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30402 invoked from network); 25 Nov 2011 12:16:50 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:16:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9129225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:16:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 12:16:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTui2-00050t-U1; Fri, 25 Nov 2011 12:16:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTui2-0007Jh-SJ;
	Fri, 25 Nov 2011 12:16:50 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20175.34610.865081.821439@mariner.uk.xensource.com>
Date: Fri, 25 Nov 2011 12:16:50 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-10032-mainreport@xen.org>
References: <osstest-10032-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: keir@xen.org
Subject: Re: [Xen-devel] [xen-unstable test] 10032: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 10032: regressions - FAIL"):
> flight 10032 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10032/
...
> Tests which did not succeed and are blocking:
>  test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
>  test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
>  test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
>  test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
>  test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

It looks like something has completely broken HVM.  My bisector is
working on it and should report later today.

Maybe we should stop throwing things into the tree until we get a
pass and push.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:19:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:19:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTukF-0002yV-27; Fri, 25 Nov 2011 12:19:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTukD-0002yB-Oi
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:19:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322223482!58678351!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6425 invoked from network); 25 Nov 2011 12:18:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9129268"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:18:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 12:18:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTujj-00051g-3Z; Fri, 25 Nov 2011 12:18:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTujj-0007K3-18;
	Fri, 25 Nov 2011 12:18:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20175.34715.23093.32794@mariner.uk.xensource.com>
Date: Fri, 25 Nov 2011 12:18:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322213955.1005.226.camel@zakaz.uk.xensource.com>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
	<20174.36255.134440.874181@mariner.uk.xensource.com>
	<1322213618.1005.222.camel@zakaz.uk.xensource.com>
	<1322213955.1005.226.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons"):
> On Fri, 2011-11-25 at 09:33 +0000, Ian Campbell wrote:
> > /lib/udev/devices is empty on my system and I can't see any
> > documentation about what one should create there (actual dev nodes?) In
> > any case it appears to be Debian specific.
> 
> Actually it turns out it is a core udevd feature and is documented in
> udevd(8). So we could usefully create things here in our install target,
> if we wanted.
> 
> That's assuming that opening /dev/xen/evtchn turns into a suitable
> modprobe it should do, I think.

I think I will take the patch to modprobe in the init script.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:19:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:19:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTukF-0002yV-27; Fri, 25 Nov 2011 12:19:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTukD-0002yB-Oi
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:19:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322223482!58678351!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6425 invoked from network); 25 Nov 2011 12:18:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:18:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9129268"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:18:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 12:18:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTujj-00051g-3Z; Fri, 25 Nov 2011 12:18:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTujj-0007K3-18;
	Fri, 25 Nov 2011 12:18:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20175.34715.23093.32794@mariner.uk.xensource.com>
Date: Fri, 25 Nov 2011 12:18:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322213955.1005.226.camel@zakaz.uk.xensource.com>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
	<20174.36255.134440.874181@mariner.uk.xensource.com>
	<1322213618.1005.222.camel@zakaz.uk.xensource.com>
	<1322213955.1005.226.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons"):
> On Fri, 2011-11-25 at 09:33 +0000, Ian Campbell wrote:
> > /lib/udev/devices is empty on my system and I can't see any
> > documentation about what one should create there (actual dev nodes?) In
> > any case it appears to be Debian specific.
> 
> Actually it turns out it is a core udevd feature and is documented in
> udevd(8). So we could usefully create things here in our install target,
> if we wanted.
> 
> That's assuming that opening /dev/xen/evtchn turns into a suitable
> modprobe it should do, I think.

I think I will take the patch to modprobe in the init script.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:23:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:23:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuo8-0003G2-PP; Fri, 25 Nov 2011 12:23:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTuo7-0003Fr-3E
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:23:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322223726!54545547!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9405 invoked from network); 25 Nov 2011 12:22:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:22:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9129353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:22:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 12:22:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTunf-000534-By; Fri, 25 Nov 2011 12:22:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTunf-0007KL-B5;
	Fri, 25 Nov 2011 12:22:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20175.34959.330377.576086@mariner.uk.xensource.com>
Date: Fri, 25 Nov 2011 12:22:39 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322215997.1005.234.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
	<20174.33257.808458.54256@mariner.uk.xensource.com>
	<1322215997.1005.234.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
 html	output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the html	output"):
> On Thu, 2011-11-24 at 17:42 +0000, Ian Jackson wrote:
> >     next unless m/\S/;
> 
> I think that would be a syntax error so die unless m/\S/ ?

Surely ignoring blank lines is going to be less irritating.

> > This is not correct because $outdir is not a regular expression.  The
> > shortest way of doing this is indeed substr.
> 
> OK.
> 
> Aside: how does one dynamically construct a regex then?

However you like.  Make a variable which contains your regexp.  If you
have a string in a scalar and want a regexp which matches that string
you can do this:
   my $regexp = $string;
   $regexp =~ s/\W/\\$&/g;
   ... m/^$regexp/ ...

> > Do we really want an index per subdirectory ?
> 
> I was thinking of folks how manually type urls or who string the last
> element off. Having an index in each dir ensures they get something
> structured and not the apache generated thing.

True.

> It does complicate the code though so I could be convinced to drop it.

No, that's OK.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:23:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:23:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuo8-0003G2-PP; Fri, 25 Nov 2011 12:23:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTuo7-0003Fr-3E
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:23:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322223726!54545547!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9405 invoked from network); 25 Nov 2011 12:22:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:22:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9129353"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:22:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 12:22:39 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTunf-000534-By; Fri, 25 Nov 2011 12:22:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTunf-0007KL-B5;
	Fri, 25 Nov 2011 12:22:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20175.34959.330377.576086@mariner.uk.xensource.com>
Date: Fri, 25 Nov 2011 12:22:39 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322215997.1005.234.camel@zakaz.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
	<20174.33257.808458.54256@mariner.uk.xensource.com>
	<1322215997.1005.234.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
 html	output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the html	output"):
> On Thu, 2011-11-24 at 17:42 +0000, Ian Jackson wrote:
> >     next unless m/\S/;
> 
> I think that would be a syntax error so die unless m/\S/ ?

Surely ignoring blank lines is going to be less irritating.

> > This is not correct because $outdir is not a regular expression.  The
> > shortest way of doing this is indeed substr.
> 
> OK.
> 
> Aside: how does one dynamically construct a regex then?

However you like.  Make a variable which contains your regexp.  If you
have a string in a scalar and want a regexp which matches that string
you can do this:
   my $regexp = $string;
   $regexp =~ s/\W/\\$&/g;
   ... m/^$regexp/ ...

> > Do we really want an index per subdirectory ?
> 
> I was thinking of folks how manually type urls or who string the last
> element off. Having an index in each dir ensures they get something
> structured and not the apache generated thing.

True.

> It does complicate the code though so I could be convinced to drop it.

No, that's OK.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:29:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuuA-0003Wj-S7; Fri, 25 Nov 2011 12:29:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTuu8-0003WP-Ir
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:29:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322224099!54206881!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14291 invoked from network); 25 Nov 2011 12:28:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 25 Nov 2011 12:28:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322224128; l=1005;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=1eYzimJZnk+UwRo9tYARMODWuyY=;
	b=i+g0+s0TnXpGvOdpQRhqoH74eww9gL6oU5ePRNOlHq3PzlKQ/kKuf7jdAcs4VnOR+HG
	XiBJPyRslqOFurw2PQR0uUJ18qmp3J1xijzKY3BBsPL2QKXP71+g9Mh1HRuaqmHypHZlY
	ZkPlWo+Az7X8xP8LT+oXXren5VmhTE06VwQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by post.strato.de (mrclete mo34) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j0247fnAPBqNvA ;
	Fri, 25 Nov 2011 13:28:38 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A592518637; Fri, 25 Nov 2011 13:28:32 +0100 (CET)
Date: Fri, 25 Nov 2011 13:28:32 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111125122832.GA14183@aepfle.de>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
	<20174.36255.134440.874181@mariner.uk.xensource.com>
	<1322213618.1005.222.camel@zakaz.uk.xensource.com>
	<1322213955.1005.226.camel@zakaz.uk.xensource.com>
	<20175.34715.23093.32794@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20175.34715.23093.32794@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 25, Ian Jackson wrote:

> Ian Campbell writes ("Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons"):
> > On Fri, 2011-11-25 at 09:33 +0000, Ian Campbell wrote:
> > > /lib/udev/devices is empty on my system and I can't see any
> > > documentation about what one should create there (actual dev nodes?) In
> > > any case it appears to be Debian specific.
> > 
> > Actually it turns out it is a core udevd feature and is documented in
> > udevd(8). So we could usefully create things here in our install target,
> > if we wanted.
> > 
> > That's assuming that opening /dev/xen/evtchn turns into a suitable
> > modprobe it should do, I think.
> 
> I think I will take the patch to modprobe in the init script.

This is what I have in a similar patch, it loads the relevant modules
for pvops and xenlinux kernel:

+modprobe xen-evtchn 2>/dev/null || :
+modprobe xen-gntdev 2>/dev/null || :
+modprobe evtchn 2>/dev/null || :
+modprobe gntdev 2>/dev/null || :


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:29:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:29:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuuA-0003Wj-S7; Fri, 25 Nov 2011 12:29:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTuu8-0003WP-Ir
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:29:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322224099!54206881!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14291 invoked from network); 25 Nov 2011 12:28:19 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 25 Nov 2011 12:28:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322224128; l=1005;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=1eYzimJZnk+UwRo9tYARMODWuyY=;
	b=i+g0+s0TnXpGvOdpQRhqoH74eww9gL6oU5ePRNOlHq3PzlKQ/kKuf7jdAcs4VnOR+HG
	XiBJPyRslqOFurw2PQR0uUJ18qmp3J1xijzKY3BBsPL2QKXP71+g9Mh1HRuaqmHypHZlY
	ZkPlWo+Az7X8xP8LT+oXXren5VmhTE06VwQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by post.strato.de (mrclete mo34) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j0247fnAPBqNvA ;
	Fri, 25 Nov 2011 13:28:38 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A592518637; Fri, 25 Nov 2011 13:28:32 +0100 (CET)
Date: Fri, 25 Nov 2011 13:28:32 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111125122832.GA14183@aepfle.de>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
	<20174.36255.134440.874181@mariner.uk.xensource.com>
	<1322213618.1005.222.camel@zakaz.uk.xensource.com>
	<1322213955.1005.226.camel@zakaz.uk.xensource.com>
	<20175.34715.23093.32794@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20175.34715.23093.32794@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 25, Ian Jackson wrote:

> Ian Campbell writes ("Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons"):
> > On Fri, 2011-11-25 at 09:33 +0000, Ian Campbell wrote:
> > > /lib/udev/devices is empty on my system and I can't see any
> > > documentation about what one should create there (actual dev nodes?) In
> > > any case it appears to be Debian specific.
> > 
> > Actually it turns out it is a core udevd feature and is documented in
> > udevd(8). So we could usefully create things here in our install target,
> > if we wanted.
> > 
> > That's assuming that opening /dev/xen/evtchn turns into a suitable
> > modprobe it should do, I think.
> 
> I think I will take the patch to modprobe in the init script.

This is what I have in a similar patch, it loads the relevant modules
for pvops and xenlinux kernel:

+modprobe xen-evtchn 2>/dev/null || :
+modprobe xen-gntdev 2>/dev/null || :
+modprobe evtchn 2>/dev/null || :
+modprobe gntdev 2>/dev/null || :


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:32:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:32:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuwd-0003eA-Ec; Fri, 25 Nov 2011 12:31:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTuwc-0003dt-1J
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:31:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322224176!53666853!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23307 invoked from network); 25 Nov 2011 12:29:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9129511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:31:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 12:31:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTuw4-00055q-T2; Fri, 25 Nov 2011 12:31:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTuw4-0007L1-S5;
	Fri, 25 Nov 2011 12:31:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20175.35480.856086.248400@mariner.uk.xensource.com>
Date: Fri, 25 Nov 2011 12:31:20 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111125122832.GA14183@aepfle.de>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
	<20174.36255.134440.874181@mariner.uk.xensource.com>
	<1322213618.1005.222.camel@zakaz.uk.xensource.com>
	<1322213955.1005.226.camel@zakaz.uk.xensource.com>
	<20175.34715.23093.32794@mariner.uk.xensource.com>
	<20111125122832.GA14183@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons"):
> On Fri, Nov 25, Ian Jackson wrote:
> > I think I will take the patch to modprobe in the init script.
> 
> This is what I have in a similar patch, it loads the relevant modules
> for pvops and xenlinux kernel:
> 
> +modprobe xen-evtchn 2>/dev/null || :
> +modprobe xen-gntdev 2>/dev/null || :
> +modprobe evtchn 2>/dev/null || :
> +modprobe gntdev 2>/dev/null || :

Would you care to post that patch with a proper signed-off-by and a
commit comment ?  That seems more comprehensive than Paul's.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:32:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:32:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuwd-0003eA-Ec; Fri, 25 Nov 2011 12:31:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTuwc-0003dt-1J
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:31:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322224176!53666853!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23307 invoked from network); 25 Nov 2011 12:29:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:29:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9129511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:31:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 12:31:21 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RTuw4-00055q-T2; Fri, 25 Nov 2011 12:31:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RTuw4-0007L1-S5;
	Fri, 25 Nov 2011 12:31:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20175.35480.856086.248400@mariner.uk.xensource.com>
Date: Fri, 25 Nov 2011 12:31:20 +0000
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20111125122832.GA14183@aepfle.de>
References: <ff6518e294a7daa552e3.1321880839@cosworth.uk.xensource.com>
	<20174.36255.134440.874181@mariner.uk.xensource.com>
	<1322213618.1005.222.camel@zakaz.uk.xensource.com>
	<1322213955.1005.226.camel@zakaz.uk.xensource.com>
	<20175.34715.23093.32794@mariner.uk.xensource.com>
	<20111125122832.GA14183@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("Re: [Xen-devel] [PATCH] Add missing modprobe to xencommons"):
> On Fri, Nov 25, Ian Jackson wrote:
> > I think I will take the patch to modprobe in the init script.
> 
> This is what I have in a similar patch, it loads the relevant modules
> for pvops and xenlinux kernel:
> 
> +modprobe xen-evtchn 2>/dev/null || :
> +modprobe xen-gntdev 2>/dev/null || :
> +modprobe evtchn 2>/dev/null || :
> +modprobe gntdev 2>/dev/null || :

Would you care to post that patch with a proper signed-off-by and a
commit comment ?  That seems more comprehensive than Paul's.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:35:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:35:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuzI-0003mQ-2E; Fri, 25 Nov 2011 12:34:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RTuzG-0003m2-FX
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:34:38 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322224412!54548188!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2773 invoked from network); 25 Nov 2011 12:33:33 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:33:33 -0000
Received: by ywt34 with SMTP id 34so1521920ywt.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 04:34:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=+LvmRKB0fXnY5I6MgWhzk+rEyiO0YXkSegCH3GC81GE=;
	b=Cq2egilNhihaLSQt4NpzPLlM7Ojr9m5GUbUKSouQYhaNolRGEGyWYU2aDGVV+71C8/
	YDw2++HgHvtQFl0JuJqg5Veif8nvk+mX3zQb6R43gbh51FTYzdWnfjA+udbK/C8D2nxt
	STBaFtZXm+nsSWoPUQH7JrRKXQ2UDIb+Y0tv8=
Received: by 10.182.77.231 with SMTP id v7mr10306245obw.4.1322224445115; Fri,
	25 Nov 2011 04:34:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.37.225 with HTTP; Fri, 25 Nov 2011 04:33:34 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111251146100.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-6-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.00.1111241816250.31179@kaball-desktop>
	<CAJJyHjL6pmt53GARCaV1QRC4Zam7uX6Huf_AON8ZZswmxt4YaQ@mail.gmail.com>
	<alpine.DEB.2.00.1111251146100.31179@kaball-desktop>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 25 Nov 2011 12:33:34 +0000
X-Google-Sender-Auth: t5MFvhmuRW13dQITe047yES_FF8
Message-ID: <CAJJyHjJjUdO+keSDsgUPtTHbeWF63QvAXzTS1sCfnGyzzxqpeQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 5/5] vga-cirrus: Workaround
 during restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBOb3YgMjUsIDIwMTEgYXQgMTE6NTEsIFN0ZWZhbm8gU3RhYmVsbGluaQo8c3RlZmFu
by5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+IHdyb3RlOgo+PiBPbiBUaHUsIE5vdiAyNCwgMjAx
MSBhdCAxODozMCwgU3RlZmFubyBTdGFiZWxsaW5pCj4+IDxzdGVmYW5vLnN0YWJlbGxpbmlAZXUu
Y2l0cml4LmNvbT4gd3JvdGU6Cj4+ID4KPj4gPj4gQEAgLTI3ODQsOSArMjc5NiwxMSBAQCBzdGF0
aWMgdm9pZCBjaXJydXNfcmVzZXQodm9pZCAqb3BhcXVlKQo+PiA+PiDCoCDCoCDCoH0KPj4gPj4g
wqAgwqAgwqBzLT52Z2EuY3JbMHgyN10gPSBzLT5kZXZpY2VfaWQ7Cj4+ID4+Cj4+ID4+IC0gwqAg
wqAvKiBXaW4ySyBzZWVtcyB0byBhc3N1bWUgdGhhdCB0aGUgcGF0dGVybiBidWZmZXIgaXMgYXQg
MHhmZgo+PiA+PiAtIMKgIMKgIMKgIGluaXRpYWxseSAhICovCj4+ID4+IC0gwqAgwqBtZW1zZXQo
cy0+dmdhLnZyYW1fcHRyLCAweGZmLCBzLT5yZWFsX3ZyYW1fc2l6ZSk7Cj4+ID4+ICsgwqAgwqBp
ZiAoIXJ1bnN0YXRlX2NoZWNrKFJVTl9TVEFURV9QUkVNSUdSQVRFKSkgewo+PiA+PiArIMKgIMKg
IMKgIMKgLyogV2luMksgc2VlbXMgdG8gYXNzdW1lIHRoYXQgdGhlIHBhdHRlcm4gYnVmZmVyIGlz
IGF0IDB4ZmYKPj4gPj4gKyDCoCDCoCDCoCDCoCDCoCBpbml0aWFsbHkgISAqLwo+PiA+PiArIMKg
IMKgIMKgIMKgbWVtc2V0KHMtPnZnYS52cmFtX3B0ciwgMHhmZiwgcy0+cmVhbF92cmFtX3NpemUp
Owo+PiA+PiArIMKgIMKgfQo+PiA+Pgo+PiA+Cj4+ID4gdGhpcyBpcyBub3QgdG9vIGJhZCwgSSBz
dXBwb3NlIHRoYXQgdGhlIHZpZGVvcmFtIGlzIGdvaW5nIHRvIGJlIHdyaXR0ZW4KPj4gPiBhZ2Fp
biBhdCByZXN0b3JlIHRpbWUgYW55d2F5IHNvIGF0IGxlYXN0IGl0IHNhdmVzIHNvbWUgY3ljbGVz
Cj4+Cj4+IEFjdHVhbGx5LCBJIHRoaW5rIHRoZSBuZXh0IHRpbWUgdGhhdCB0aGlzIHZyYW0gd2ls
bCBiZSB3cml0dGVuIGFnYWluCj4+IGlzLCB3aGVuIHRoZSBndWVzdCBpcyBhY3R1YWxseSAid2Fr
ZWQtdXAiIGFuZCB3cm90ZSBzb21ldGhpbmcgdGhlcmUuCj4+IE90aGVyd2lzZSwgdGhlICJyZXN0
b3JlIiBvZiB0aGUgdnJhbSBpcyBkb25lIGJlZm9yZSBRRU1VIHN0YXJ0LiBTbywKPj4gdGhlIG1l
bXNldCBjb3VsZCBsZWF2ZSBzb21lIHdlYXJkIHN0dWZmIHRoZSBzY3JlZW4gKGEgd2hpdGUgc2Ny
ZWVuPykuCj4KPiBTbyB0aGlzIGlzIHRoZSBzdWNjZXNzaW9uIG9mIGV2ZW50czoKPgo+IC0gdmdh
X2NvbW1vbl9pbml0Cj4gYWxsb2NhdGVzIHRoZSB2aWRlb3JhbQo+Cj4gLSBjaXJydXNfcmVzZXQK
PiBzZXRzIHNldCB2aWRlb3JhbSB0byAweGZmCj4KPiAtIGxvYWRfdm1zdGF0ZQo+IHRoZSBvbGQg
dmlkZW9yYW0gaXMgY29waWVkIG92ZXIsIG92ZXJ3cml0aW5nIHdoYXQgY2lycnVzX3Jlc2V0IGhh
cyBkb25lCj4KPiB0aGVyZWZvcmUgc2V0dGluZyB0aGUgdmlkZW9yYW0gdG8gMHhmZiB3aGVuIHJl
c3VtaW5nIGlzIGEgd2FzdGUgb2YKPiBlZmZvcnRzCgpPb29wcywgSSByZWR1Y2UgbXkgYW5zd2Vy
IHRvIHRoZSBvbmx5IFhlbiBjYXNlLiBTbyBJIGFncmVlIHdpdGggeW91LgoKLS0gCkFudGhvbnkg
UEVSQVJECgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:35:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:35:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTuzI-0003mQ-2E; Fri, 25 Nov 2011 12:34:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RTuzG-0003m2-FX
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:34:38 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322224412!54548188!1
X-Originating-IP: [209.85.213.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2773 invoked from network); 25 Nov 2011 12:33:33 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:33:33 -0000
Received: by ywt34 with SMTP id 34so1521920ywt.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 04:34:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=+LvmRKB0fXnY5I6MgWhzk+rEyiO0YXkSegCH3GC81GE=;
	b=Cq2egilNhihaLSQt4NpzPLlM7Ojr9m5GUbUKSouQYhaNolRGEGyWYU2aDGVV+71C8/
	YDw2++HgHvtQFl0JuJqg5Veif8nvk+mX3zQb6R43gbh51FTYzdWnfjA+udbK/C8D2nxt
	STBaFtZXm+nsSWoPUQH7JrRKXQ2UDIb+Y0tv8=
Received: by 10.182.77.231 with SMTP id v7mr10306245obw.4.1322224445115; Fri,
	25 Nov 2011 04:34:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.37.225 with HTTP; Fri, 25 Nov 2011 04:33:34 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1111251146100.31179@kaball-desktop>
References: <1322150893-887-1-git-send-email-anthony.perard@citrix.com>
	<1322150893-887-6-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.00.1111241816250.31179@kaball-desktop>
	<CAJJyHjL6pmt53GARCaV1QRC4Zam7uX6Huf_AON8ZZswmxt4YaQ@mail.gmail.com>
	<alpine.DEB.2.00.1111251146100.31179@kaball-desktop>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 25 Nov 2011 12:33:34 +0000
X-Google-Sender-Auth: t5MFvhmuRW13dQITe047yES_FF8
Message-ID: <CAJJyHjJjUdO+keSDsgUPtTHbeWF63QvAXzTS1sCfnGyzzxqpeQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 5/5] vga-cirrus: Workaround
 during restore when using Xen.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBOb3YgMjUsIDIwMTEgYXQgMTE6NTEsIFN0ZWZhbm8gU3RhYmVsbGluaQo8c3RlZmFu
by5zdGFiZWxsaW5pQGV1LmNpdHJpeC5jb20+IHdyb3RlOgo+PiBPbiBUaHUsIE5vdiAyNCwgMjAx
MSBhdCAxODozMCwgU3RlZmFubyBTdGFiZWxsaW5pCj4+IDxzdGVmYW5vLnN0YWJlbGxpbmlAZXUu
Y2l0cml4LmNvbT4gd3JvdGU6Cj4+ID4KPj4gPj4gQEAgLTI3ODQsOSArMjc5NiwxMSBAQCBzdGF0
aWMgdm9pZCBjaXJydXNfcmVzZXQodm9pZCAqb3BhcXVlKQo+PiA+PiDCoCDCoCDCoH0KPj4gPj4g
wqAgwqAgwqBzLT52Z2EuY3JbMHgyN10gPSBzLT5kZXZpY2VfaWQ7Cj4+ID4+Cj4+ID4+IC0gwqAg
wqAvKiBXaW4ySyBzZWVtcyB0byBhc3N1bWUgdGhhdCB0aGUgcGF0dGVybiBidWZmZXIgaXMgYXQg
MHhmZgo+PiA+PiAtIMKgIMKgIMKgIGluaXRpYWxseSAhICovCj4+ID4+IC0gwqAgwqBtZW1zZXQo
cy0+dmdhLnZyYW1fcHRyLCAweGZmLCBzLT5yZWFsX3ZyYW1fc2l6ZSk7Cj4+ID4+ICsgwqAgwqBp
ZiAoIXJ1bnN0YXRlX2NoZWNrKFJVTl9TVEFURV9QUkVNSUdSQVRFKSkgewo+PiA+PiArIMKgIMKg
IMKgIMKgLyogV2luMksgc2VlbXMgdG8gYXNzdW1lIHRoYXQgdGhlIHBhdHRlcm4gYnVmZmVyIGlz
IGF0IDB4ZmYKPj4gPj4gKyDCoCDCoCDCoCDCoCDCoCBpbml0aWFsbHkgISAqLwo+PiA+PiArIMKg
IMKgIMKgIMKgbWVtc2V0KHMtPnZnYS52cmFtX3B0ciwgMHhmZiwgcy0+cmVhbF92cmFtX3NpemUp
Owo+PiA+PiArIMKgIMKgfQo+PiA+Pgo+PiA+Cj4+ID4gdGhpcyBpcyBub3QgdG9vIGJhZCwgSSBz
dXBwb3NlIHRoYXQgdGhlIHZpZGVvcmFtIGlzIGdvaW5nIHRvIGJlIHdyaXR0ZW4KPj4gPiBhZ2Fp
biBhdCByZXN0b3JlIHRpbWUgYW55d2F5IHNvIGF0IGxlYXN0IGl0IHNhdmVzIHNvbWUgY3ljbGVz
Cj4+Cj4+IEFjdHVhbGx5LCBJIHRoaW5rIHRoZSBuZXh0IHRpbWUgdGhhdCB0aGlzIHZyYW0gd2ls
bCBiZSB3cml0dGVuIGFnYWluCj4+IGlzLCB3aGVuIHRoZSBndWVzdCBpcyBhY3R1YWxseSAid2Fr
ZWQtdXAiIGFuZCB3cm90ZSBzb21ldGhpbmcgdGhlcmUuCj4+IE90aGVyd2lzZSwgdGhlICJyZXN0
b3JlIiBvZiB0aGUgdnJhbSBpcyBkb25lIGJlZm9yZSBRRU1VIHN0YXJ0LiBTbywKPj4gdGhlIG1l
bXNldCBjb3VsZCBsZWF2ZSBzb21lIHdlYXJkIHN0dWZmIHRoZSBzY3JlZW4gKGEgd2hpdGUgc2Ny
ZWVuPykuCj4KPiBTbyB0aGlzIGlzIHRoZSBzdWNjZXNzaW9uIG9mIGV2ZW50czoKPgo+IC0gdmdh
X2NvbW1vbl9pbml0Cj4gYWxsb2NhdGVzIHRoZSB2aWRlb3JhbQo+Cj4gLSBjaXJydXNfcmVzZXQK
PiBzZXRzIHNldCB2aWRlb3JhbSB0byAweGZmCj4KPiAtIGxvYWRfdm1zdGF0ZQo+IHRoZSBvbGQg
dmlkZW9yYW0gaXMgY29waWVkIG92ZXIsIG92ZXJ3cml0aW5nIHdoYXQgY2lycnVzX3Jlc2V0IGhh
cyBkb25lCj4KPiB0aGVyZWZvcmUgc2V0dGluZyB0aGUgdmlkZW9yYW0gdG8gMHhmZiB3aGVuIHJl
c3VtaW5nIGlzIGEgd2FzdGUgb2YKPiBlZmZvcnRzCgpPb29wcywgSSByZWR1Y2UgbXkgYW5zd2Vy
IHRvIHRoZSBvbmx5IFhlbiBjYXNlLiBTbyBJIGFncmVlIHdpdGggeW91LgoKLS0gCkFudGhvbnkg
UEVSQVJECgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:57:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvKh-00047j-CM; Fri, 25 Nov 2011 12:56:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTvKf-00047b-Lh
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:56:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322225773!3010966!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20809 invoked from network); 25 Nov 2011 12:56:13 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 12:56:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322225773; l=612;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=xlfehILjlCiPIVrvHLS3N08ZWAo=;
	b=mshYkoRVKmUjYCvkseGFauSFNjFSMmLazCfTTDMwQvBlyimUQ/8FRpaeceBuih8Livt
	sbSkk2eta3FSsO4wrZ++L7XnQoMC5d5OmuNnKcwPb6yFhGnLxGT++bwUsCPct6c5caANJ
	SJ9DTAiLP+ik0YhF0skkaytGwLPuN71fzY8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by smtp.strato.de (cohen mo51) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a05b10nAPBrf9s ;
	Fri, 25 Nov 2011 13:56:05 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 94EA718637; Fri, 25 Nov 2011 13:56:04 +0100 (CET)
Date: Fri, 25 Nov 2011 13:56:04 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111125125604.GA14585@aepfle.de>
References: <20111123223049.GA14423@aepfle.de>
	<CAF32E64.25744%keir.xen@gmail.com>
	<20111124100021.GA17462@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111124100021.GA17462@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Olaf Hering wrote:

> On Wed, Nov 23, Keir Fraser wrote:
> 
> > ...from qemu-dm. Problem is that toolstack is not killing qemu-dm, or
> > qemu-dm is not responding to some shutdown signal.
> 
> In the first crash there was no qemu-dm process left from what I
> remember. I will see if it happens again.

I see the patches were already commited. Thanks.

After more investigation my config file has on_crash="preserve".
To me it looks like the guest kills itself, since nothing is in the
logs. So after all thats not a waitqueue issue, and most likely also not
a paging bug.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:57:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvKh-00047j-CM; Fri, 25 Nov 2011 12:56:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTvKf-00047b-Lh
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:56:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322225773!3010966!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20809 invoked from network); 25 Nov 2011 12:56:13 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 12:56:13 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322225773; l=612;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=xlfehILjlCiPIVrvHLS3N08ZWAo=;
	b=mshYkoRVKmUjYCvkseGFauSFNjFSMmLazCfTTDMwQvBlyimUQ/8FRpaeceBuih8Livt
	sbSkk2eta3FSsO4wrZ++L7XnQoMC5d5OmuNnKcwPb6yFhGnLxGT++bwUsCPct6c5caANJ
	SJ9DTAiLP+ik0YhF0skkaytGwLPuN71fzY8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by smtp.strato.de (cohen mo51) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a05b10nAPBrf9s ;
	Fri, 25 Nov 2011 13:56:05 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 94EA718637; Fri, 25 Nov 2011 13:56:04 +0100 (CET)
Date: Fri, 25 Nov 2011 13:56:04 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111125125604.GA14585@aepfle.de>
References: <20111123223049.GA14423@aepfle.de>
	<CAF32E64.25744%keir.xen@gmail.com>
	<20111124100021.GA17462@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111124100021.GA17462@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, Olaf Hering wrote:

> On Wed, Nov 23, Keir Fraser wrote:
> 
> > ...from qemu-dm. Problem is that toolstack is not killing qemu-dm, or
> > qemu-dm is not responding to some shutdown signal.
> 
> In the first crash there was no qemu-dm process left from what I
> remember. I will see if it happens again.

I see the patches were already commited. Thanks.

After more investigation my config file has on_crash="preserve".
To me it looks like the guest kills itself, since nothing is in the
logs. So after all thats not a waitqueue issue, and most likely also not
a paging bug.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:59:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:59:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvMu-0004DX-U5; Fri, 25 Nov 2011 12:59:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pankaj.kumarbiswas@citrix.com>) id 1RTvMt-0004DE-UA
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:59:04 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322225907!4977486!1
X-Originating-IP: [203.166.19.134]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10893 invoked from network); 25 Nov 2011 12:58:30 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:58:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; d="scan'208,217";a="9415098"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:58:08 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.72]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Fri, 25 Nov 2011
	18:28:07 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 18:28:06 +0530
Thread-Topic: Re: Make failure for xen-4.1-testing branch
Thread-Index: AcyrcZ2LM14gfBVYQeS6TVSsWLf6wA==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F442904829@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4298714491566037496=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4298714491566037496==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904829BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904829BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Team,
The Make is getting failed with the following error for xen-4.1-testing bra=
nch. The OS is open SUSE 11(free).
Any suggestion ??

+ git clone git://xenbits.xensource.com/qemu-xen-4.1-testing.git ioemu-remo=
te.tmp
Cloning into ioemu-remote.tmp...
xenbits.xensource.com[0: 50.57.170.242]: errno=3DConnection refused
fatal: unable to connect a socket (Connection refused)
make[1]: *** [ioemu-dir-find] Error 128
make[1]: Leaving directory `/root/Desktop/xen-4.1-testing.hg/tools'
make: *** [tools/ioemu-dir] Error 2


thanks,
PANKAJ KUMAR BISWAS


--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904829BANPMAILBOX01_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Cambria;
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Hi Team,<o:p></o=
:p></p><p class=3DMsoNormal>The Make is getting failed with the following e=
rror for xen-4.1-testing branch. The OS is open SUSE 11(free).<o:p></o:p></=
p><p class=3DMsoNormal>Any suggestion ??<o:p></o:p></p><p class=3DMsoNormal=
><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>+ git clone git://xenbits.xensou=
rce.com/qemu-xen-4.1-testing.git ioemu-remote.tmp<o:p></o:p></p><p class=3D=
MsoNormal>Cloning into ioemu-remote.tmp...<o:p></o:p></p><p class=3DMsoNorm=
al>xenbits.xensource.com[0: 50.57.170.242]: errno=3DConnection refused<o:p>=
</o:p></p><p class=3DMsoNormal>fatal: unable to connect a socket (Connectio=
n refused)<o:p></o:p></p><p class=3DMsoNormal>make[1]: *** [ioemu-dir-find]=
 Error 128<o:p></o:p></p><p class=3DMsoNormal>make[1]: Leaving directory `/=
root/Desktop/xen-4.1-testing.hg/tools'<o:p></o:p></p><p class=3DMsoNormal>m=
ake: *** [tools/ioemu-dir] Error 2<o:p></o:p></p><p class=3DMsoNormal><o:p>=
&nbsp;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNor=
mal><b><span style=3D'font-family:"Cambria","serif"'>thanks,<o:p></o:p></sp=
an></b></p><p class=3DMsoNormal><b><span style=3D'font-family:"Cambria","se=
rif"'>PANKAJ KUMAR BISWAS<o:p></o:p></span></b></p><p class=3DMsoNormal><o:=
p>&nbsp;</o:p></p></div></body></html>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904829BANPMAILBOX01_--


--===============4298714491566037496==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4298714491566037496==--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 12:59:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 12:59:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvMu-0004DX-U5; Fri, 25 Nov 2011 12:59:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pankaj.kumarbiswas@citrix.com>) id 1RTvMt-0004DE-UA
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 12:59:04 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322225907!4977486!1
X-Originating-IP: [203.166.19.134]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10893 invoked from network); 25 Nov 2011 12:58:30 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 12:58:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; d="scan'208,217";a="9415098"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:58:08 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.72]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Fri, 25 Nov 2011
	18:28:07 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 18:28:06 +0530
Thread-Topic: Re: Make failure for xen-4.1-testing branch
Thread-Index: AcyrcZ2LM14gfBVYQeS6TVSsWLf6wA==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F442904829@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4298714491566037496=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4298714491566037496==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904829BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904829BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Team,
The Make is getting failed with the following error for xen-4.1-testing bra=
nch. The OS is open SUSE 11(free).
Any suggestion ??

+ git clone git://xenbits.xensource.com/qemu-xen-4.1-testing.git ioemu-remo=
te.tmp
Cloning into ioemu-remote.tmp...
xenbits.xensource.com[0: 50.57.170.242]: errno=3DConnection refused
fatal: unable to connect a socket (Connection refused)
make[1]: *** [ioemu-dir-find] Error 128
make[1]: Leaving directory `/root/Desktop/xen-4.1-testing.hg/tools'
make: *** [tools/ioemu-dir] Error 2


thanks,
PANKAJ KUMAR BISWAS


--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904829BANPMAILBOX01_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Cambria;
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Hi Team,<o:p></o=
:p></p><p class=3DMsoNormal>The Make is getting failed with the following e=
rror for xen-4.1-testing branch. The OS is open SUSE 11(free).<o:p></o:p></=
p><p class=3DMsoNormal>Any suggestion ??<o:p></o:p></p><p class=3DMsoNormal=
><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>+ git clone git://xenbits.xensou=
rce.com/qemu-xen-4.1-testing.git ioemu-remote.tmp<o:p></o:p></p><p class=3D=
MsoNormal>Cloning into ioemu-remote.tmp...<o:p></o:p></p><p class=3DMsoNorm=
al>xenbits.xensource.com[0: 50.57.170.242]: errno=3DConnection refused<o:p>=
</o:p></p><p class=3DMsoNormal>fatal: unable to connect a socket (Connectio=
n refused)<o:p></o:p></p><p class=3DMsoNormal>make[1]: *** [ioemu-dir-find]=
 Error 128<o:p></o:p></p><p class=3DMsoNormal>make[1]: Leaving directory `/=
root/Desktop/xen-4.1-testing.hg/tools'<o:p></o:p></p><p class=3DMsoNormal>m=
ake: *** [tools/ioemu-dir] Error 2<o:p></o:p></p><p class=3DMsoNormal><o:p>=
&nbsp;</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNor=
mal><b><span style=3D'font-family:"Cambria","serif"'>thanks,<o:p></o:p></sp=
an></b></p><p class=3DMsoNormal><b><span style=3D'font-family:"Cambria","se=
rif"'>PANKAJ KUMAR BISWAS<o:p></o:p></span></b></p><p class=3DMsoNormal><o:=
p>&nbsp;</o:p></p></div></body></html>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F442904829BANPMAILBOX01_--


--===============4298714491566037496==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4298714491566037496==--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:12:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:12:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvZO-0004gt-0l; Fri, 25 Nov 2011 13:11:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTvZM-0004gZ-9Q
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:11:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322226683!4995098!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2539 invoked from network); 25 Nov 2011 13:11:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 13:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9130293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 13:11:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 13:11:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
Date: Fri, 25 Nov 2011 13:11:22 +0000
In-Reply-To: <64FB1554ABC9B44FAA773FBD6CB889C2F442904829@BANPMAILBOX01.citrite.net>
References: <64FB1554ABC9B44FAA773FBD6CB889C2F442904829@BANPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322226683.1005.247.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 12:58 +0000, Pankaj Kumar Biswas wrote:
> Hi Team,
> 
> The Make is getting failed with the following error for
> xen-4.1-testing branch. The OS is open SUSE 11(free).
> 
> Any suggestion ??
> 
>  
> 
> + git clone git://xenbits.xensource.com/qemu-xen-4.1-testing.git
> ioemu-remote.tmp
> 
> Cloning into ioemu-remote.tmp...
> 
> xenbits.xensource.com[0: 50.57.170.242]: errno=Connection refused
> 
> fatal: unable to connect a socket (Connection refused)

It's working for me right now. The git daemon was down for a little
while earler in the week -- when did you see this failure?

It is possible that your site firewalls the git port. While you work to
get it opened up you can set GIT_HTTP=y in .config at the top of the Xen
source tree.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:12:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:12:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvZO-0004gt-0l; Fri, 25 Nov 2011 13:11:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTvZM-0004gZ-9Q
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:11:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322226683!4995098!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2539 invoked from network); 25 Nov 2011 13:11:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 13:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9130293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 13:11:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 13:11:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
Date: Fri, 25 Nov 2011 13:11:22 +0000
In-Reply-To: <64FB1554ABC9B44FAA773FBD6CB889C2F442904829@BANPMAILBOX01.citrite.net>
References: <64FB1554ABC9B44FAA773FBD6CB889C2F442904829@BANPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322226683.1005.247.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 12:58 +0000, Pankaj Kumar Biswas wrote:
> Hi Team,
> 
> The Make is getting failed with the following error for
> xen-4.1-testing branch. The OS is open SUSE 11(free).
> 
> Any suggestion ??
> 
>  
> 
> + git clone git://xenbits.xensource.com/qemu-xen-4.1-testing.git
> ioemu-remote.tmp
> 
> Cloning into ioemu-remote.tmp...
> 
> xenbits.xensource.com[0: 50.57.170.242]: errno=Connection refused
> 
> fatal: unable to connect a socket (Connection refused)

It's working for me right now. The git daemon was down for a little
while earler in the week -- when did you see this failure?

It is possible that your site firewalls the git port. While you work to
get it opened up you can set GIT_HTTP=y in .config at the top of the Xen
source tree.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:23:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvjy-0005M8-Ts; Fri, 25 Nov 2011 13:22:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pankaj.kumarbiswas@citrix.com>) id 1RTvjx-0005Lw-6U
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:22:53 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322227222!45804766!1
X-Originating-IP: [203.166.19.134]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32677 invoked from network); 25 Nov 2011 13:20:25 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 13:20:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9415228"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 13:22:21 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.72]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Fri, 25 Nov 2011
	18:52:20 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 25 Nov 2011 18:52:19 +0530
Thread-Topic: [Xen-devel] Make failure for xen-4.1-testing branch
Thread-Index: Acyrc7x4wl0rNlySRheU80Qt/yLsiQAAGiuA
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F442904830@BANPMAILBOX01.citrite.net>
References: <64FB1554ABC9B44FAA773FBD6CB889C2F442904829@BANPMAILBOX01.citrite.net>
	<1322226683.1005.247.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322226683.1005.247.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian,
Thanks a lot for the quick reply. I will do as you have mentioned. The failure happened today evening around 4:30 PM (IST).
Is there anything  to do with building as a  root/normal user??

Regards,
PANKAJ KUMAR BISWAS


-----Original Message-----
From: Ian Campbell 
Sent: Friday, November 25, 2011 6:41 PM
To: Pankaj Kumar Biswas
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch

On Fri, 2011-11-25 at 12:58 +0000, Pankaj Kumar Biswas wrote:
> Hi Team,
> 
> The Make is getting failed with the following error for 
> xen-4.1-testing branch. The OS is open SUSE 11(free).
> 
> Any suggestion ??
> 
>  
> 
> + git clone git://xenbits.xensource.com/qemu-xen-4.1-testing.git
> ioemu-remote.tmp
> 
> Cloning into ioemu-remote.tmp...
> 
> xenbits.xensource.com[0: 50.57.170.242]: errno=Connection refused
> 
> fatal: unable to connect a socket (Connection refused)

It's working for me right now. The git daemon was down for a little while earler in the week -- when did you see this failure?

It is possible that your site firewalls the git port. While you work to get it opened up you can set GIT_HTTP=y in .config at the top of the Xen source tree.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:23:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvjy-0005M8-Ts; Fri, 25 Nov 2011 13:22:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pankaj.kumarbiswas@citrix.com>) id 1RTvjx-0005Lw-6U
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:22:53 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322227222!45804766!1
X-Originating-IP: [203.166.19.134]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32677 invoked from network); 25 Nov 2011 13:20:25 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 13:20:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9415228"
Received: from banpmailmx02.citrite.net ([10.103.128.74])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 13:22:21 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.72]) by
	BANPMAILMX02.citrite.net ([10.103.128.74]) with mapi; Fri, 25 Nov 2011
	18:52:20 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 25 Nov 2011 18:52:19 +0530
Thread-Topic: [Xen-devel] Make failure for xen-4.1-testing branch
Thread-Index: Acyrc7x4wl0rNlySRheU80Qt/yLsiQAAGiuA
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F442904830@BANPMAILBOX01.citrite.net>
References: <64FB1554ABC9B44FAA773FBD6CB889C2F442904829@BANPMAILBOX01.citrite.net>
	<1322226683.1005.247.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322226683.1005.247.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian,
Thanks a lot for the quick reply. I will do as you have mentioned. The failure happened today evening around 4:30 PM (IST).
Is there anything  to do with building as a  root/normal user??

Regards,
PANKAJ KUMAR BISWAS


-----Original Message-----
From: Ian Campbell 
Sent: Friday, November 25, 2011 6:41 PM
To: Pankaj Kumar Biswas
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch

On Fri, 2011-11-25 at 12:58 +0000, Pankaj Kumar Biswas wrote:
> Hi Team,
> 
> The Make is getting failed with the following error for 
> xen-4.1-testing branch. The OS is open SUSE 11(free).
> 
> Any suggestion ??
> 
>  
> 
> + git clone git://xenbits.xensource.com/qemu-xen-4.1-testing.git
> ioemu-remote.tmp
> 
> Cloning into ioemu-remote.tmp...
> 
> xenbits.xensource.com[0: 50.57.170.242]: errno=Connection refused
> 
> fatal: unable to connect a socket (Connection refused)

It's working for me right now. The git daemon was down for a little while earler in the week -- when did you see this failure?

It is possible that your site firewalls the git port. While you work to get it opened up you can set GIT_HTTP=y in .config at the top of the Xen source tree.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:27:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:27:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvo8-0005bM-KN; Fri, 25 Nov 2011 13:27:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RTvo7-0005b8-1e
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:27:11 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322227597!3006525!1
X-Originating-IP: [216.139.236.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23765 invoked from network); 25 Nov 2011 13:26:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Nov 2011 13:26:38 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RTvnX-0001vG-J2
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 05:26:35 -0800
Date: Fri, 25 Nov 2011 05:26:35 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1322227595583-5022781.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Blktap 2 driver on upstream kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I currently use kernel based on 2.6.32 pv_ops from jeremy git for dom0, I
would like to start trying the upstream, the 3.2 seems to be perhaps
sufficiently good beginning but have a problem, there isn't blktap 2 module
and i not found it on manteiners git or todo in project page
(http://wiki.xen.org/wiki/XenDevelopmentProjects).
Nothing new about that?

--
View this message in context: http://xen.1045712.n5.nabble.com/Blktap-2-driver-on-upstream-kernel-tp5022781p5022781.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:27:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:27:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvo8-0005bM-KN; Fri, 25 Nov 2011 13:27:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RTvo7-0005b8-1e
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:27:11 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322227597!3006525!1
X-Originating-IP: [216.139.236.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23765 invoked from network); 25 Nov 2011 13:26:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Nov 2011 13:26:38 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RTvnX-0001vG-J2
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 05:26:35 -0800
Date: Fri, 25 Nov 2011 05:26:35 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1322227595583-5022781.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Blktap 2 driver on upstream kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I currently use kernel based on 2.6.32 pv_ops from jeremy git for dom0, I
would like to start trying the upstream, the 3.2 seems to be perhaps
sufficiently good beginning but have a problem, there isn't blktap 2 module
and i not found it on manteiners git or todo in project page
(http://wiki.xen.org/wiki/XenDevelopmentProjects).
Nothing new about that?

--
View this message in context: http://xen.1045712.n5.nabble.com/Blktap-2-driver-on-upstream-kernel-tp5022781p5022781.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:32:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvst-0005sA-K7; Fri, 25 Nov 2011 13:32:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTvss-0005r7-D6
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:32:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322227893!4984666!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 903 invoked from network); 25 Nov 2011 13:31:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 13:31:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 13:31:33 +0000
Message-Id: <4ECFA6C302000078000634A1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 13:31:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> X86: Disable PCID/INVPCID for dom0
> 
> PCID (Process-context identifier) is a facility by which a logical processor 
> may cache information for multiple linear-address spaces. INVPCID is an new 
> instruction to invalidate TLB. Refer latest Intel SDM 
> http://www.intel.com/content/www/us/en/processors/architectures-software-develo 
> per-manuals.html
> 
> We disable PCID/INVPCID for dom0 and pv. Exposing them into dom0 and pv may 
> result in performance regression, and it would trigger GP or UD depending on 
> whether platform suppport INVPCID or not.
> 
> This patch disable PCID/INVPCID for dom0.

Do we really need to disable it, rather than making it work?
Conceptually the feature seems usable, and the instruction would
need replacement by a hypercall anyway (just like invlpg).

Jan

> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r 519a0e3c982d xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
> +++ b/xen/arch/x86/traps.c	Thu Nov 17 18:41:59 2011 +0800
> @@ -813,6 +813,7 @@ static void pv_cpuid(struct cpu_user_reg
>              __clear_bit(X86_FEATURE_CX16 % 32, &c);
>          __clear_bit(X86_FEATURE_XTPR % 32, &c);
>          __clear_bit(X86_FEATURE_PDCM % 32, &c);
> +        __clear_bit(X86_FEATURE_PCID % 32, &c);
>          __clear_bit(X86_FEATURE_DCA % 32, &c);
>          if ( !xsave_enabled(current) )
>          {
> diff -r 519a0e3c982d xen/include/asm-x86/cpufeature.h
> --- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
> +++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:41:59 2011 +0800
> @@ -97,6 +97,7 @@
>  #define X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */
>  #define X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
>  #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
> +#define X86_FEATURE_PCID	(4*32+17) /* Process Context ID */
>  #define X86_FEATURE_DCA		(4*32+18) /* Direct Cache Access */
>  #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming SIMD Extensions 4.1 */
>  #define X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
> @@ -152,6 +153,7 @@
>  #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection 
> */
>  #define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
>  #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
> +#define X86_FEATURE_INVPCID	(7*32+10) /* Invalidate Process Context ID */
>  
>  #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
>  #define boot_cpu_has(bit)	test_bit(bit, boot_cpu_data.x86_capability)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:32:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:32:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvst-0005sA-K7; Fri, 25 Nov 2011 13:32:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTvss-0005r7-D6
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:32:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322227893!4984666!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 903 invoked from network); 25 Nov 2011 13:31:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 13:31:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 13:31:33 +0000
Message-Id: <4ECFA6C302000078000634A1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 13:31:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> X86: Disable PCID/INVPCID for dom0
> 
> PCID (Process-context identifier) is a facility by which a logical processor 
> may cache information for multiple linear-address spaces. INVPCID is an new 
> instruction to invalidate TLB. Refer latest Intel SDM 
> http://www.intel.com/content/www/us/en/processors/architectures-software-develo 
> per-manuals.html
> 
> We disable PCID/INVPCID for dom0 and pv. Exposing them into dom0 and pv may 
> result in performance regression, and it would trigger GP or UD depending on 
> whether platform suppport INVPCID or not.
> 
> This patch disable PCID/INVPCID for dom0.

Do we really need to disable it, rather than making it work?
Conceptually the feature seems usable, and the instruction would
need replacement by a hypercall anyway (just like invlpg).

Jan

> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r 519a0e3c982d xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
> +++ b/xen/arch/x86/traps.c	Thu Nov 17 18:41:59 2011 +0800
> @@ -813,6 +813,7 @@ static void pv_cpuid(struct cpu_user_reg
>              __clear_bit(X86_FEATURE_CX16 % 32, &c);
>          __clear_bit(X86_FEATURE_XTPR % 32, &c);
>          __clear_bit(X86_FEATURE_PDCM % 32, &c);
> +        __clear_bit(X86_FEATURE_PCID % 32, &c);
>          __clear_bit(X86_FEATURE_DCA % 32, &c);
>          if ( !xsave_enabled(current) )
>          {
> diff -r 519a0e3c982d xen/include/asm-x86/cpufeature.h
> --- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
> +++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:41:59 2011 +0800
> @@ -97,6 +97,7 @@
>  #define X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */
>  #define X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
>  #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
> +#define X86_FEATURE_PCID	(4*32+17) /* Process Context ID */
>  #define X86_FEATURE_DCA		(4*32+18) /* Direct Cache Access */
>  #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming SIMD Extensions 4.1 */
>  #define X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
> @@ -152,6 +153,7 @@
>  #define X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection 
> */
>  #define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation extensions */
>  #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP MOVSB/STOSB */
> +#define X86_FEATURE_INVPCID	(7*32+10) /* Invalidate Process Context ID */
>  
>  #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
>  #define boot_cpu_has(bit)	test_bit(bit, boot_cpu_data.x86_capability)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:35:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:35:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvvc-00064Z-9m; Fri, 25 Nov 2011 13:34:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTvva-00064S-6k
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:34:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322228061!3028136!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6605 invoked from network); 25 Nov 2011 13:34:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 13:34:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9130730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 13:34:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 13:34:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
Date: Fri, 25 Nov 2011 13:34:20 +0000
In-Reply-To: <64FB1554ABC9B44FAA773FBD6CB889C2F442904830@BANPMAILBOX01.citrite.net>
References: <64FB1554ABC9B44FAA773FBD6CB889C2F442904829@BANPMAILBOX01.citrite.net>
	<1322226683.1005.247.camel@zakaz.uk.xensource.com>
	<64FB1554ABC9B44FAA773FBD6CB889C2F442904830@BANPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322228060.1005.250.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 13:22 +0000, Pankaj Kumar Biswas wrote:
> Hi Ian,
> Thanks a lot for the quick reply. I will do as you have mentioned. The failure happened today evening around 4:30 PM (IST).

So is it working for you now?

> Is there anything  to do with building as a  root/normal user??

There are no issues which I know of relating to the user you build as.
It certainly wouldn't affect your network connectivity.

Ian.

> 
> Regards,
> PANKAJ KUMAR BISWAS
> 
> 
> -----Original Message-----
> From: Ian Campbell 
> Sent: Friday, November 25, 2011 6:41 PM
> To: Pankaj Kumar Biswas
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch
> 
> On Fri, 2011-11-25 at 12:58 +0000, Pankaj Kumar Biswas wrote:
> > Hi Team,
> > 
> > The Make is getting failed with the following error for 
> > xen-4.1-testing branch. The OS is open SUSE 11(free).
> > 
> > Any suggestion ??
> > 
> >  
> > 
> > + git clone git://xenbits.xensource.com/qemu-xen-4.1-testing.git
> > ioemu-remote.tmp
> > 
> > Cloning into ioemu-remote.tmp...
> > 
> > xenbits.xensource.com[0: 50.57.170.242]: errno=Connection refused
> > 
> > fatal: unable to connect a socket (Connection refused)
> 
> It's working for me right now. The git daemon was down for a little while earler in the week -- when did you see this failure?
> 
> It is possible that your site firewalls the git port. While you work to get it opened up you can set GIT_HTTP=y in .config at the top of the Xen source tree.
> 
> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:35:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:35:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvvc-00064Z-9m; Fri, 25 Nov 2011 13:34:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTvva-00064S-6k
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:34:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322228061!3028136!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6605 invoked from network); 25 Nov 2011 13:34:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 13:34:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9130730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 13:34:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 13:34:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
Date: Fri, 25 Nov 2011 13:34:20 +0000
In-Reply-To: <64FB1554ABC9B44FAA773FBD6CB889C2F442904830@BANPMAILBOX01.citrite.net>
References: <64FB1554ABC9B44FAA773FBD6CB889C2F442904829@BANPMAILBOX01.citrite.net>
	<1322226683.1005.247.camel@zakaz.uk.xensource.com>
	<64FB1554ABC9B44FAA773FBD6CB889C2F442904830@BANPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322228060.1005.250.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 13:22 +0000, Pankaj Kumar Biswas wrote:
> Hi Ian,
> Thanks a lot for the quick reply. I will do as you have mentioned. The failure happened today evening around 4:30 PM (IST).

So is it working for you now?

> Is there anything  to do with building as a  root/normal user??

There are no issues which I know of relating to the user you build as.
It certainly wouldn't affect your network connectivity.

Ian.

> 
> Regards,
> PANKAJ KUMAR BISWAS
> 
> 
> -----Original Message-----
> From: Ian Campbell 
> Sent: Friday, November 25, 2011 6:41 PM
> To: Pankaj Kumar Biswas
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Make failure for xen-4.1-testing branch
> 
> On Fri, 2011-11-25 at 12:58 +0000, Pankaj Kumar Biswas wrote:
> > Hi Team,
> > 
> > The Make is getting failed with the following error for 
> > xen-4.1-testing branch. The OS is open SUSE 11(free).
> > 
> > Any suggestion ??
> > 
> >  
> > 
> > + git clone git://xenbits.xensource.com/qemu-xen-4.1-testing.git
> > ioemu-remote.tmp
> > 
> > Cloning into ioemu-remote.tmp...
> > 
> > xenbits.xensource.com[0: 50.57.170.242]: errno=Connection refused
> > 
> > fatal: unable to connect a socket (Connection refused)
> 
> It's working for me right now. The git daemon was down for a little while earler in the week -- when did you see this failure?
> 
> It is possible that your site firewalls the git port. While you work to get it opened up you can set GIT_HTTP=y in .config at the top of the Xen source tree.
> 
> Ian.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:35:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvw7-00066Q-Ny; Fri, 25 Nov 2011 13:35:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTvw6-00065z-CM
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:35:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322228094!4998108!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1687 invoked from network); 25 Nov 2011 13:34:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 13:34:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9130739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 13:34:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 13:34:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 25 Nov 2011 13:34:53 +0000
In-Reply-To: <1322227595583-5022781.post@n5.nabble.com>
References: <1322227595583-5022781.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322228093.1005.251.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Blktap 2 driver on upstream kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 13:26 +0000, Fantu wrote:
> I currently use kernel based on 2.6.32 pv_ops from jeremy git for dom0, I
> would like to start trying the upstream, the 3.2 seems to be perhaps
> sufficiently good beginning but have a problem, there isn't blktap 2 module
> and i not found it on manteiners git or todo in project page
> (http://wiki.xen.org/wiki/XenDevelopmentProjects).
> Nothing new about that?

Please check the mailing list archives, this has been discussed several
times.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:35:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:35:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvw7-00066Q-Ny; Fri, 25 Nov 2011 13:35:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTvw6-00065z-CM
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:35:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322228094!4998108!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1687 invoked from network); 25 Nov 2011 13:34:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 13:34:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9130739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 13:34:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 13:34:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Fri, 25 Nov 2011 13:34:53 +0000
In-Reply-To: <1322227595583-5022781.post@n5.nabble.com>
References: <1322227595583-5022781.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322228093.1005.251.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Blktap 2 driver on upstream kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 13:26 +0000, Fantu wrote:
> I currently use kernel based on 2.6.32 pv_ops from jeremy git for dom0, I
> would like to start trying the upstream, the 3.2 seems to be perhaps
> sufficiently good beginning but have a problem, there isn't blktap 2 module
> and i not found it on manteiners git or todo in project page
> (http://wiki.xen.org/wiki/XenDevelopmentProjects).
> Nothing new about that?

Please check the mailing list archives, this has been discussed several
times.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:37:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvy8-0006JN-AT; Fri, 25 Nov 2011 13:37:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTvy7-0006II-54
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:37:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322228194!49939753!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18834 invoked from network); 25 Nov 2011 13:36:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 13:36:34 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9130785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 13:36:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 13:36:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 13:36:51 +0000
In-Reply-To: <20175.34959.330377.576086@mariner.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
	<20174.33257.808458.54256@mariner.uk.xensource.com>
	<1322215997.1005.234.camel@zakaz.uk.xensource.com>
	<20175.34959.330377.576086@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322228211.1005.252.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
 html	output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 12:22 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the html	output"):
> > On Thu, 2011-11-24 at 17:42 +0000, Ian Jackson wrote:
> > >     next unless m/\S/;
> > 
> > I think that would be a syntax error so die unless m/\S/ ?
> 
> Surely ignoring blank lines is going to be less irritating.

I missed that this was \S not \s. Your way does indeed make sense.

> > > This is not correct because $outdir is not a regular expression.  The
> > > shortest way of doing this is indeed substr.
> > 
> > OK.
> > 
> > Aside: how does one dynamically construct a regex then?
> 
> However you like.  Make a variable which contains your regexp.  If you
> have a string in a scalar and want a regexp which matches that string
> you can do this:
>    my $regexp = $string;
>    $regexp =~ s/\W/\\$&/g;
>    ... m/^$regexp/ ...

Ah, I thought you were suggesting that /$something/ was not valid at
all, but you meant only if you don't correctly quote it etc.

Thanks,
Ian.

> 
> > > Do we really want an index per subdirectory ?
> > 
> > I was thinking of folks how manually type urls or who string the last
> > element off. Having an index in each dir ensures they get something
> > structured and not the apache generated thing.
> 
> True.
> 
> > It does complicate the code though so I could be convinced to drop it.
> 
> No, that's OK.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:37:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:37:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTvy8-0006JN-AT; Fri, 25 Nov 2011 13:37:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTvy7-0006II-54
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:37:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322228194!49939753!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18834 invoked from network); 25 Nov 2011 13:36:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 13:36:34 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9130785"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 13:36:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 13:36:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 13:36:51 +0000
In-Reply-To: <20175.34959.330377.576086@mariner.uk.xensource.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
	<20174.33257.808458.54256@mariner.uk.xensource.com>
	<1322215997.1005.234.camel@zakaz.uk.xensource.com>
	<20175.34959.330377.576086@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322228211.1005.252.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
 html	output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 12:22 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the html	output"):
> > On Thu, 2011-11-24 at 17:42 +0000, Ian Jackson wrote:
> > >     next unless m/\S/;
> > 
> > I think that would be a syntax error so die unless m/\S/ ?
> 
> Surely ignoring blank lines is going to be less irritating.

I missed that this was \S not \s. Your way does indeed make sense.

> > > This is not correct because $outdir is not a regular expression.  The
> > > shortest way of doing this is indeed substr.
> > 
> > OK.
> > 
> > Aside: how does one dynamically construct a regex then?
> 
> However you like.  Make a variable which contains your regexp.  If you
> have a string in a scalar and want a regexp which matches that string
> you can do this:
>    my $regexp = $string;
>    $regexp =~ s/\W/\\$&/g;
>    ... m/^$regexp/ ...

Ah, I thought you were suggesting that /$something/ was not valid at
all, but you meant only if you don't correctly quote it etc.

Thanks,
Ian.

> 
> > > Do we really want an index per subdirectory ?
> > 
> > I was thinking of folks how manually type urls or who string the last
> > element off. Having an index in each dir ensures they get something
> > structured and not the apache generated thing.
> 
> True.
> 
> > It does complicate the code though so I could be convinced to drop it.
> 
> No, that's OK.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:40:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTw0S-0006eL-Sa; Fri, 25 Nov 2011 13:39:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTw0R-0006dV-Nh
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:39:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322228363!4634967!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27614 invoked from network); 25 Nov 2011 13:39:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 25 Nov 2011 13:39:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322228363; l=229;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=dUl4Lr6//iO6HC64OSXWryKad3o=;
	b=YbHmzU2dXej1dcEkG32zAnHX/7LQdMfo32WpLlzr4ltWVjkzcMfCh5IJRr9YuT64yAU
	r0AM2aPjb1n6K3niWbewQyin+jhO5J5MejSmDFvswvKYJtloYFRucGd8K+dj3DEQbeH+o
	9IqajWhcjFNq1/Tp7qpGpBho1UR4YpJIlRk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by smtp.strato.de (klopstock mo6) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z05899nAPCVDQe ;
	Fri, 25 Nov 2011 14:39:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 65BBE18636;
	Fri, 25 Nov 2011 14:39:07 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1322228345@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 25 Nov 2011 14:39:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Update xencommons to avoid error messages in non-Xen environment, and
load required kernel drivers.

Olaf

 tools/hotplug/Linux/init.d/xencommons |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:40:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTw0S-0006eL-Sa; Fri, 25 Nov 2011 13:39:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTw0R-0006dV-Nh
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:39:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322228363!4634967!1
X-Originating-IP: [81.169.146.162]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27614 invoked from network); 25 Nov 2011 13:39:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 25 Nov 2011 13:39:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322228363; l=229;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=dUl4Lr6//iO6HC64OSXWryKad3o=;
	b=YbHmzU2dXej1dcEkG32zAnHX/7LQdMfo32WpLlzr4ltWVjkzcMfCh5IJRr9YuT64yAU
	r0AM2aPjb1n6K3niWbewQyin+jhO5J5MejSmDFvswvKYJtloYFRucGd8K+dj3DEQbeH+o
	9IqajWhcjFNq1/Tp7qpGpBho1UR4YpJIlRk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by smtp.strato.de (klopstock mo6) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z05899nAPCVDQe ;
	Fri, 25 Nov 2011 14:39:07 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 65BBE18636;
	Fri, 25 Nov 2011 14:39:07 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1322228345@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 25 Nov 2011 14:39:05 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0 of 2] tools/hotplug fixes for xen-unstable
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Update xencommons to avoid error messages in non-Xen environment, and
load required kernel drivers.

Olaf

 tools/hotplug/Linux/init.d/xencommons |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:40:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:40:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTw0P-0006dk-2T; Fri, 25 Nov 2011 13:39:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTw0M-0006d7-T0
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:39:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322228358!4627662!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20109 invoked from network); 25 Nov 2011 13:39:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 25 Nov 2011 13:39:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322228358; l=963;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=Pd2Ec/4cZcYxKFu3iLKNaIyfLXk=;
	b=Gy2yX0Zoyq6sqG0hwOwXpGGhZvgR9Uhs/zBOtMMDuyXibQjvuOgDCKzTO5mAgpXjaPN
	kN021eaXYTXPuy973sYnisIMj7bbBsvLSCFU8+L4VC2GwiBlLcsAzR4brfvKMyQb+9zHe
	cMY4d/Syd4pNjvShqSgcQi2GHcuzD6aw3G8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by smtp.strato.de (klopstock mo49) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y05232nAPCptOQ ;
	Fri, 25 Nov 2011 14:39:08 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CEED918638;
	Fri, 25 Nov 2011 14:39:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 666c76daa1e74cb7f6d237fe34434d262fc91f6a
Message-Id: <666c76daa1e74cb7f6d2.1322228347@probook.site>
In-Reply-To: <patchbomb.1322228345@probook.site>
References: <patchbomb.1322228345@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 25 Nov 2011 14:39:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2 of 2] xencommons: load evtchn and gntdev
	modules
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322228288 -3600
# Node ID 666c76daa1e74cb7f6d237fe34434d262fc91f6a
# Parent  bed3a6489d9a2ee2fdfc12a35f8544c7148dfe1a
xencommons: load evtchn and gntdev modules

There is currently no code in the kernel to trigger autoload of the
evtchn or gntdev drivers. Load them manually during xencommons start.
Handle both pvops and xenlinux module names.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r bed3a6489d9a -r 666c76daa1e7 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -54,6 +54,11 @@ do_start () {
         local time=0
 	local timeout=30
 
+	modprobe xen-evtchn 2>/dev/null
+	modprobe xen-gntdev 2>/dev/null
+	modprobe evtchn 2>/dev/null
+	modprobe gntdev 2>/dev/null
+
 	if ! `xenstore-read -s / >/dev/null 2>&1`
 	then
 		test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:40:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:40:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTw0P-0006dk-2T; Fri, 25 Nov 2011 13:39:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTw0M-0006d7-T0
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:39:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322228358!4627662!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20109 invoked from network); 25 Nov 2011 13:39:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 25 Nov 2011 13:39:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322228358; l=963;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=Pd2Ec/4cZcYxKFu3iLKNaIyfLXk=;
	b=Gy2yX0Zoyq6sqG0hwOwXpGGhZvgR9Uhs/zBOtMMDuyXibQjvuOgDCKzTO5mAgpXjaPN
	kN021eaXYTXPuy973sYnisIMj7bbBsvLSCFU8+L4VC2GwiBlLcsAzR4brfvKMyQb+9zHe
	cMY4d/Syd4pNjvShqSgcQi2GHcuzD6aw3G8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by smtp.strato.de (klopstock mo49) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y05232nAPCptOQ ;
	Fri, 25 Nov 2011 14:39:08 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CEED918638;
	Fri, 25 Nov 2011 14:39:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 666c76daa1e74cb7f6d237fe34434d262fc91f6a
Message-Id: <666c76daa1e74cb7f6d2.1322228347@probook.site>
In-Reply-To: <patchbomb.1322228345@probook.site>
References: <patchbomb.1322228345@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 25 Nov 2011 14:39:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2 of 2] xencommons: load evtchn and gntdev
	modules
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322228288 -3600
# Node ID 666c76daa1e74cb7f6d237fe34434d262fc91f6a
# Parent  bed3a6489d9a2ee2fdfc12a35f8544c7148dfe1a
xencommons: load evtchn and gntdev modules

There is currently no code in the kernel to trigger autoload of the
evtchn or gntdev drivers. Load them manually during xencommons start.
Handle both pvops and xenlinux module names.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r bed3a6489d9a -r 666c76daa1e7 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -54,6 +54,11 @@ do_start () {
         local time=0
 	local timeout=30
 
+	modprobe xen-evtchn 2>/dev/null
+	modprobe xen-gntdev 2>/dev/null
+	modprobe evtchn 2>/dev/null
+	modprobe gntdev 2>/dev/null
+
 	if ! `xenstore-read -s / >/dev/null 2>&1`
 	then
 		test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:40:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:40:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTw0P-0006ds-F6; Fri, 25 Nov 2011 13:39:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTw0M-0006d6-Ue
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:39:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322228358!4634947!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27054 invoked from network); 25 Nov 2011 13:39:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 25 Nov 2011 13:39:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322228358; l=1489;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=/q3gd4SFxfoNUMNT6eE+vrL/GWk=;
	b=SB5cOQqkXXX5/drXdjrU+2jIrdXWW5lkvyweNtba597FXFyxfoW0EKYJhUu1RFPIiOG
	qNNyuqav0ewzO0K2s+gRrcB1GDRrPtTB4jgko+vKO7SSiEP4tlmV3iVRhioSR5u4UVEAS
	IxONf/9PKuy1HZk31SYKaD2LD09RoEp7FrQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by smtp.strato.de (klopstock mo49) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y05232nAPCptOO ;
	Fri, 25 Nov 2011 14:39:08 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9CC3418637;
	Fri, 25 Nov 2011 14:39:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bed3a6489d9a2ee2fdfc12a35f8544c7148dfe1a
Message-Id: <bed3a6489d9a2ee2fdfc.1322228346@probook.site>
In-Reply-To: <patchbomb.1322228345@probook.site>
References: <patchbomb.1322228345@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 25 Nov 2011 14:39:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1 of 2] xencommons: run script only when needed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322228282 -3600
# Node ID bed3a6489d9a2ee2fdfc12a35f8544c7148dfe1a
# Parent  1027e7d13d02143048c7d48d7960967c5b1657a8
xencommons: run script only when needed

Currently xencommons prints an error that /proc/xen/capabilities does
not exist when started on a non-xen kernel.

Update the xencommons script to run only when needed:
- do not run if /proc/xen does not exist
- check if /proc/xen/capabilities exists before doing the grep for dom0

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1027e7d13d02 -r bed3a6489d9a tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -29,15 +29,24 @@ test -f $xencommons_config/xencommons &&
 XENCONSOLED_PIDFILE=/var/run/xenconsoled.pid
 shopt -s extglob
 
+# not running in Xen dom0 or domU
+if ! test -d /proc/xen ; then
+	exit 0
+fi
+
+# mount xenfs in dom0 or domU with a pv_ops kernel
 if test "x$1" = xstart && \
-     test -d /proc/xen && \
    ! test -f /proc/xen/capabilities && \
    ! grep '^xenfs ' /proc/mounts >/dev/null;
 then
 	mount -t xenfs xenfs /proc/xen
 fi
 
-if ! grep -q "control_d" /proc/xen/capabilities ; then
+# run this script only in dom0:
+# no capabilities file in xenlinux domU kernel
+# empty capabilities file in pv_ops domU kernel
+if test -f /proc/xen/capabilities && \
+   ! grep -q "control_d" /proc/xen/capabilities ; then
 	exit 0
 fi
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 13:40:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 13:40:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTw0P-0006ds-F6; Fri, 25 Nov 2011 13:39:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RTw0M-0006d6-Ue
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 13:39:51 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322228358!4634947!1
X-Originating-IP: [81.169.146.160]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27054 invoked from network); 25 Nov 2011 13:39:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 25 Nov 2011 13:39:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322228358; l=1489;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=/q3gd4SFxfoNUMNT6eE+vrL/GWk=;
	b=SB5cOQqkXXX5/drXdjrU+2jIrdXWW5lkvyweNtba597FXFyxfoW0EKYJhUu1RFPIiOG
	qNNyuqav0ewzO0K2s+gRrcB1GDRrPtTB4jgko+vKO7SSiEP4tlmV3iVRhioSR5u4UVEAS
	IxONf/9PKuy1HZk31SYKaD2LD09RoEp7FrQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by smtp.strato.de (klopstock mo49) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y05232nAPCptOO ;
	Fri, 25 Nov 2011 14:39:08 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 9CC3418637;
	Fri, 25 Nov 2011 14:39:07 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bed3a6489d9a2ee2fdfc12a35f8544c7148dfe1a
Message-Id: <bed3a6489d9a2ee2fdfc.1322228346@probook.site>
In-Reply-To: <patchbomb.1322228345@probook.site>
References: <patchbomb.1322228345@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 25 Nov 2011 14:39:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1 of 2] xencommons: run script only when needed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1322228282 -3600
# Node ID bed3a6489d9a2ee2fdfc12a35f8544c7148dfe1a
# Parent  1027e7d13d02143048c7d48d7960967c5b1657a8
xencommons: run script only when needed

Currently xencommons prints an error that /proc/xen/capabilities does
not exist when started on a non-xen kernel.

Update the xencommons script to run only when needed:
- do not run if /proc/xen does not exist
- check if /proc/xen/capabilities exists before doing the grep for dom0

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 1027e7d13d02 -r bed3a6489d9a tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -29,15 +29,24 @@ test -f $xencommons_config/xencommons &&
 XENCONSOLED_PIDFILE=/var/run/xenconsoled.pid
 shopt -s extglob
 
+# not running in Xen dom0 or domU
+if ! test -d /proc/xen ; then
+	exit 0
+fi
+
+# mount xenfs in dom0 or domU with a pv_ops kernel
 if test "x$1" = xstart && \
-     test -d /proc/xen && \
    ! test -f /proc/xen/capabilities && \
    ! grep '^xenfs ' /proc/mounts >/dev/null;
 then
 	mount -t xenfs xenfs /proc/xen
 fi
 
-if ! grep -q "control_d" /proc/xen/capabilities ; then
+# run this script only in dom0:
+# no capabilities file in xenlinux domU kernel
+# empty capabilities file in pv_ops domU kernel
+if test -f /proc/xen/capabilities && \
+   ! grep -q "control_d" /proc/xen/capabilities ; then
 	exit 0
 fi
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:02:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:02:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTwMT-0007RI-4F; Fri, 25 Nov 2011 14:02:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTwMS-0007RD-84
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:02:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322229727!4631623!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17356 invoked from network); 25 Nov 2011 14:02:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:02:08 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9131346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 14:02:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 14:02:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 25 Nov 2011 14:02:07 +0000
In-Reply-To: <CAPLaKK7weZ-25xFnRrmcAMr=BQwPZmHoLxKJXKbsDp78EXd9Vg@mail.gmail.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
	<CAPLaKK7weZ-25xFnRrmcAMr=BQwPZmHoLxKJXKbsDp78EXd9Vg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322229727.1005.254.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTExLTI1IGF0IDExOjIyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTEvMTcgSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiArIyEvdXNyL2Jpbi9wZXJsIC13Cj4gCj4gUGxlYXNlIHVzZSAiL3Vzci9iaW4vZW52IHBlcmwi
IG9yIGNhbGwgdGhlIHNjcmlwdCBmcm9tIHRoZSBNYWtlZmlsZQo+IHdpdGggInBlcmwgLi8uLi4i
IChhcyBJYW4gSmFja3NvbiBoYXMgZG9uZSBpbiBoaXMgcGF0Y2ggdG8gaW1wb3J0Cj4gcXVldWUu
aCkKClRoaXMgZG9lc24ndCBhbGxvdyB0aGUgdXNlIG9mIC13OgovdXNyL2Jpbi9lbnY6IHBlcmwg
LXc6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKCkl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIGFj
aGlldmUgdGhlIHNhbWUgd2l0aCAkXlcgPSAxPwoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:02:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:02:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTwMT-0007RI-4F; Fri, 25 Nov 2011 14:02:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTwMS-0007RD-84
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:02:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322229727!4631623!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17356 invoked from network); 25 Nov 2011 14:02:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:02:08 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9131346"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 14:02:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 14:02:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Fri, 25 Nov 2011 14:02:07 +0000
In-Reply-To: <CAPLaKK7weZ-25xFnRrmcAMr=BQwPZmHoLxKJXKbsDp78EXd9Vg@mail.gmail.com>
References: <patchbomb.1321542106@cosworth.uk.xensource.com>
	<8f2404eef8fac8020528.1321542119@cosworth.uk.xensource.com>
	<CAPLaKK7weZ-25xFnRrmcAMr=BQwPZmHoLxKJXKbsDp78EXd9Vg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322229727.1005.254.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTExLTI1IGF0IDExOjIyICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTEvMTEvMTcgSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT46Cj4g
PiArIyEvdXNyL2Jpbi9wZXJsIC13Cj4gCj4gUGxlYXNlIHVzZSAiL3Vzci9iaW4vZW52IHBlcmwi
IG9yIGNhbGwgdGhlIHNjcmlwdCBmcm9tIHRoZSBNYWtlZmlsZQo+IHdpdGggInBlcmwgLi8uLi4i
IChhcyBJYW4gSmFja3NvbiBoYXMgZG9uZSBpbiBoaXMgcGF0Y2ggdG8gaW1wb3J0Cj4gcXVldWUu
aCkKClRoaXMgZG9lc24ndCBhbGxvdyB0aGUgdXNlIG9mIC13OgovdXNyL2Jpbi9lbnY6IHBlcmwg
LXc6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKCkl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIGFj
aGlldmUgdGhlIHNhbWUgd2l0aCAkXlcgPSAxPwoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:06:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:06:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTwPQ-0007Z2-RR; Fri, 25 Nov 2011 14:05:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTwPP-0007YX-FN; Fri, 25 Nov 2011 14:05:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322229877!58701745!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19863 invoked from network); 25 Nov 2011 14:04:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:04:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9131423"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 14:05:10 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 14:05:10 +0000
Date: Fri, 25 Nov 2011 14:06:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: xen-devel@lists.xensource.com
Message-ID: <alpine.DEB.2.00.1111251201421.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-arm@lists.xensource.com
Subject: [Xen-devel] [RFC] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with
 virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everybody,
a few weeks ago a small group of hackers started working from scratch on
a Cortex-A15 Xen port, exploiting all the latest hardware virtualization
extensions.

The port can now boot dom0 all the way to a shell prompt, so we are
planning to make an announcement to various Open Source communities
regarding ARMv7 with virt extensions support in Xen. The intention is to
get more parties interested and engaged in Xen on ARM in general, and
also to get feedback.  We propose to send the email below, to the
following mailings lists:

virtualization@lists.linux-foundation.org
linux-kernel@vger.kernel.org
linux-arm-kernel@lists.infradead.org
android-virt@lists.cs.columbia.edu
linaro-dev@lists.linaro.org

We would appreciate it if you could let us know of any additional lists
which we should send this to. We would also welcome if you checked out
the code.
 
The plan is to send out the email next week, after the Thanksgiving 
holiday.

I did want to say that this work is in no way competing with Samsung's
efforts to upstream XenARM to xen-unstable. From what we can see,
there is very little duplication between the XenARM port and what we
did, considering that we target different architectures.

Cheers,

Stefano 

---

Hi all,
a few weeks ago I (and a few others) started hacking on a
proof-of-concept hypervisor port to Cortex-A15 which uses and requires
ARMv7 virtualization extensions. The intention of this work was to find
out how to best support ARM v7+ on Xen. See
http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
for more details. 

I am pleased to announce that significant progress has been made, and
that we now have a nascent Xen port for Cortex-A15. The port is based on
xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
the latest virtualization, LPAE, GIC and generic timer support in
hardware.

We started the work less than three months ago, but the port is already
capable of booting a Linux 3.0 based virtual machine (dom0) up to a
shell prompt on an ARM Architecture Envelope Model, configured to emulate
an A15-based Versatile Express. In this context, we wanted to thank ARM
for making the model available to us.
Now we are looking forward to porting the tools and running multiple
guests.

The code requires virtualization, LPAE and GIC support and therefore it
won't be able to run on anything older than a Cortex-A15.
On the other hand, thanks to this, it is very small and easy to read,
write and understand.
The implementation does not distinguish between PV and HVM guests: there
is just one type of guests that would be comparable to Linux PV on HVM
in the Xen X86 world, but with no need for Qemu emulation.
The code only requires minimal changes to the Linux kernel: just enough
to support PV drivers.

Even though we are currently targeting Versatile Express and Cortex-A15
we do intend to support other machines and other ARMv7 with
virtualization extensions CPUs.
We are also looking forward to ARMv8 and 64 bits support.

Given that porting Xen to Cortex-A15 could be done with so little code,
we believe that the best course of action is to merge it into
xen-unstable as quickly as possible. There are still few rough edges to
sort out but we should be able to produce a clean and digestible patch
series for submission to xen-devel within the next couple of months. I
hope to see the first patches going to the list as soon as possible.
We would very welcome any contributions, in the form of testing, code
reviews and, of course, patches! 


A git tree is available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm

the gitweb url is the following:

http://xenbits.xen.org/gitweb/?p=people/sstabellini/xen-unstable.git/.git;a=shortlog;h=refs/heads/arm

And here is the full diff:

http://xenbits.xen.org/people/sstabellini/diff


We want to point out that this effort is in addition to Samsung's
ongoing efforts to upstream Xen ARM to xen-unstable. Samsung's XenARM
port allows virtualization of Xen on ARM CPUs prior to virtualization
extensions and supports traditional PV guests.

I would like to thank Tim Deegan and Ian Campbell: if you spend some
time reading the history, you'll see that this project wouldn't have
been possible in such a short time without great contributions from
them.

Cheers,
Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:06:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:06:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTwPQ-0007Z2-RR; Fri, 25 Nov 2011 14:05:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RTwPP-0007YX-FN; Fri, 25 Nov 2011 14:05:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322229877!58701745!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19863 invoked from network); 25 Nov 2011 14:04:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:04:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,571,1315180800"; 
   d="scan'208";a="9131423"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 14:05:10 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 14:05:10 +0000
Date: Fri, 25 Nov 2011 14:06:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: xen-devel@lists.xensource.com
Message-ID: <alpine.DEB.2.00.1111251201421.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-arm@lists.xensource.com
Subject: [Xen-devel] [RFC] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with
 virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everybody,
a few weeks ago a small group of hackers started working from scratch on
a Cortex-A15 Xen port, exploiting all the latest hardware virtualization
extensions.

The port can now boot dom0 all the way to a shell prompt, so we are
planning to make an announcement to various Open Source communities
regarding ARMv7 with virt extensions support in Xen. The intention is to
get more parties interested and engaged in Xen on ARM in general, and
also to get feedback.  We propose to send the email below, to the
following mailings lists:

virtualization@lists.linux-foundation.org
linux-kernel@vger.kernel.org
linux-arm-kernel@lists.infradead.org
android-virt@lists.cs.columbia.edu
linaro-dev@lists.linaro.org

We would appreciate it if you could let us know of any additional lists
which we should send this to. We would also welcome if you checked out
the code.
 
The plan is to send out the email next week, after the Thanksgiving 
holiday.

I did want to say that this work is in no way competing with Samsung's
efforts to upstream XenARM to xen-unstable. From what we can see,
there is very little duplication between the XenARM port and what we
did, considering that we target different architectures.

Cheers,

Stefano 

---

Hi all,
a few weeks ago I (and a few others) started hacking on a
proof-of-concept hypervisor port to Cortex-A15 which uses and requires
ARMv7 virtualization extensions. The intention of this work was to find
out how to best support ARM v7+ on Xen. See
http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
for more details. 

I am pleased to announce that significant progress has been made, and
that we now have a nascent Xen port for Cortex-A15. The port is based on
xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
the latest virtualization, LPAE, GIC and generic timer support in
hardware.

We started the work less than three months ago, but the port is already
capable of booting a Linux 3.0 based virtual machine (dom0) up to a
shell prompt on an ARM Architecture Envelope Model, configured to emulate
an A15-based Versatile Express. In this context, we wanted to thank ARM
for making the model available to us.
Now we are looking forward to porting the tools and running multiple
guests.

The code requires virtualization, LPAE and GIC support and therefore it
won't be able to run on anything older than a Cortex-A15.
On the other hand, thanks to this, it is very small and easy to read,
write and understand.
The implementation does not distinguish between PV and HVM guests: there
is just one type of guests that would be comparable to Linux PV on HVM
in the Xen X86 world, but with no need for Qemu emulation.
The code only requires minimal changes to the Linux kernel: just enough
to support PV drivers.

Even though we are currently targeting Versatile Express and Cortex-A15
we do intend to support other machines and other ARMv7 with
virtualization extensions CPUs.
We are also looking forward to ARMv8 and 64 bits support.

Given that porting Xen to Cortex-A15 could be done with so little code,
we believe that the best course of action is to merge it into
xen-unstable as quickly as possible. There are still few rough edges to
sort out but we should be able to produce a clean and digestible patch
series for submission to xen-devel within the next couple of months. I
hope to see the first patches going to the list as soon as possible.
We would very welcome any contributions, in the form of testing, code
reviews and, of course, patches! 


A git tree is available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm

the gitweb url is the following:

http://xenbits.xen.org/gitweb/?p=people/sstabellini/xen-unstable.git/.git;a=shortlog;h=refs/heads/arm

And here is the full diff:

http://xenbits.xen.org/people/sstabellini/diff


We want to point out that this effort is in addition to Samsung's
ongoing efforts to upstream Xen ARM to xen-unstable. Samsung's XenARM
port allows virtualization of Xen on ARM CPUs prior to virtualization
extensions and supports traditional PV guests.

I would like to thank Tim Deegan and Ian Campbell: if you spend some
time reading the history, you'll see that this project wouldn't have
been possible in such a short time without great contributions from
them.

Cheers,
Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6U-0008DU-G9; Fri, 25 Nov 2011 14:50:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6S-0008Ck-VI
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13770 invoked from network); 25 Nov 2011 14:49:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874324"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:39 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq6030497;	Fri, 25 Nov 2011 06:49:38 -0800
MIME-Version: 1.0
X-Mercurial-Node: 08a74d202a0a5b19b1229da893526856d832807b
Message-ID: <08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:37 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document describing the
 xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221975 0
# Node ID 08a74d202a0a5b19b1229da893526856d832807b
# Parent  96479242221d8b58dde242442c47da2ab4c71a8f
docs: add a document describing the xl cfg file syntax

Based on an initial version by Ian Jackson.

I believe that all keys are now present in the document although there are are
various omissions in the actual documentation of them. Hopefully however this
covers the majority of the most interesting keys.

Spice section:
Signed-off-by: Zhou Peng <zhoupeng@nfs.iscas.ac.cn>

The rest:
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 96479242221d -r 08a74d202a0a docs/man/xl.cfg.pod.5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/man/xl.cfg.pod.5	Fri Nov 25 11:52:55 2011 +0000
@@ -0,0 +1,844 @@
+=head1 NAME
+
+xl.cfg - XL Domain Configuration File Syntax
+
+=head1 SYNOPSIS
+
+ /etc/xen/xldomain
+
+=head1 DESCRIPTION
+
+To create a VM (a domain in Xen terminology, sometimes called a guest)
+with xl requires the provision of a domain config file.  Typically
+these live in `/etc/xen/DOMAIN.cfg` where DOMAIN is the name of the
+domain.
+
+=head1 SYNTAX
+
+A domain config file consists of a series of C<KEY=VALUE> pairs.
+
+Some C<KEY>s are mandatory, others are global options which apply to
+any guest type while others relate only to specific guest types
+(e.g. PV or HVM guests).
+
+A value C<VALUE> is one of:
+
+=over 4
+
+=item B<"STRING">
+
+A string, surrounded by either single or double quotes.
+
+=item B<NUMBER>
+
+A number, in either decimal, octal (using a C<0> prefix) or
+hexadecimal (using an C<0x> prefix).
+
+=item B<BOOLEAN>
+
+A C<NUMBER> interpreted as C<False> (C<0>) or C<True> (any other
+value).
+
+=item B<[ VALUE, VALUE, ... ]>
+
+A list of C<VALUES> of the above types. Lists are homogeneous and are
+not nested.
+
+=back
+
+The semantics of each C<KEY> defines which form of C<VALUE> is required.
+
+=head1 OPTIONS
+
+=head2 Mandatory Configuration Items
+
+The following key is mandatory for any guest type:
+
+=over 4
+
+=item B<name="NAME">
+
+Specifies the name of the domain.  Names of domains existing on a
+single host must be unique.
+
+=back
+
+=head2 Selecting Guest Type
+
+=over 4
+
+=item B<builder="generic">
+
+Specifies that this is to be a PV domain. This is the default.
+
+=item B<builder="hvm">
+
+Specifies that this is to be an HVM domain.  That is, a fully
+virtualised computer with emulated BIOS, disk and network peripherals,
+etc.  The default is a PV domain, suitable for hosting Xen-aware guest
+operating systems.
+
+=back
+
+=head2 Global Options
+
+The following options apply to guests of any type.
+
+=over 4
+
+=item B<uuid="UUID">
+
+Specifies the UUID of the domain.  If not specified, a fresh unique
+UUID will be generated.
+
+=item B<pool="CPUPOOLNAME">
+
+Put the guest's vcpus into the named cpu pool.
+
+=item B<vcpus=N>
+
+Start the guest with N vcpus initially online.
+
+=item B<maxvcpus=M>
+
+Allow the guest to bring up a maximum of M vcpus. At start of day if
+`vcpus=N` is less than `maxvcpus=M` then the first `N` vcpus will be
+created online and the remainder will be offline.
+
+=item B<memory=MBYTES>
+
+Start the guest with MBYTES megabytes of RAM.
+
+=item B<on_poweroff="ACTION">
+
+Specifies what should be done with the domain if it shuts itself down.
+The C<ACTION>s are:
+
+=over 4
+
+=item B<destroy>
+
+destroy the domain
+     
+=item B<restart>
+
+destroy the domain and immediately create a new domain with the same
+configuration
+        
+=item B<rename-restart>
+
+rename the domain which terminated, and thenimmediately create a new
+domain with the same configuration as the original
+
+=item B<preserve>
+
+keep the domain.  It can be examined, and later destroyed with `xl
+destroy`.
+
+=item B<coredump-destroy>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+destroy the domain.
+
+=item B<coredump-restart>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+restart the domain.
+
+=back
+
+The default for C<on_poweroff> is C<destroy>.
+
+=item B<on_reboot="ACTION">
+
+Action to take if the domain shuts down with a reason code requesting
+a reboot.  Default is C<restart>.
+
+=item B<on_watchdog="ACTION">
+
+Action to take if the domain shuts down due to a Xen watchdog timeout.
+Default is C<destroy>.
+
+=item B<on_crash="ACTION">
+
+Action to take if the domain crashes.  Default is C<destroy>.
+
+=item B<seclabel="LABEL">
+
+Assign an XSM security label to this domain.
+
+=back
+
+=head2 Devices
+
+The following options define the paravirtual, emulated and physical
+devices which the guest will contain.
+
+=over 4
+
+=item B<disk=[ "DISK_SPEC_STRING", "DISK_SPEC_STRING", ...]>
+
+Specifies the disks (both emulated disks and Xen virtual block
+devices) which are to be provided to the guest, and what objects on
+the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
+
+=item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
+
+Specifies the networking provision (both emulated network adapters,
+and Xen virtual interfaces) to provided to the guest.  See
+F<docs/misc/xl-network-configuration.markdown>.
+
+=item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
+
+Specifies the paravirtual framebuffer devices which should be supplied
+to the domain.
+
+This options does not control the emulated graphics card presented to
+an HVM guest. See L<Emulated VGA Graphics Device> below for how to
+configure the emulated device.
+
+Each B<VFB_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
+settings, from the following list:
+
+=over 4
+
+=item C<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item C<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item C<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use.  The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item C<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item C<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item C<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is to not enable this mode
+
+=item C<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using C<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item C<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below or consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item C<display=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=item C<authority=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=back
+
+=item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ... ]>
+
+Specifies the host PCI devices to passthrough to this guest. Each B<PCI_SPEC_STRING>
+has the form C<[DDDD:]BB:DD.F[@VSLOT],KEY=VALUE,KEY=VALUE,...> where:
+
+=over 4
+
+=item B<DDDD:BB:DD.F>
+
+identifies the PCI device from the host perspective in domain
+(B<DDDD>), Bus (B<BB>), Device (B<DD>) and Function (B<F>) syntax. This is
+the same scheme as used in the output of C<lspci> for the device in
+question. Note: By default C<lspci> will omit the domain (B<DDDD>) if it
+is zero and it is optional here also. You may specify the function
+(B<F>) as B<*> to indicate all functions.
+
+=item B<@VSLOT>
+
+specifies the virtual device where the guest will see this
+device. This is equivalent to the B<DD> which the guest sees. In a
+guest B<DDDD> and B<BB> are C<0000:00>. XXX how does this really work?
+
+=item B<KEY=VALUE>
+
+Posible B<KEY>s are:
+
+=over 4
+
+=item B<msitranslate=BOOLEAN>
+
+XXX
+
+=item B<power_mgmt=BOOLEAN>
+
+XXX
+
+=back
+
+=back
+
+=back
+
+=head2 Paravirtualised (PV) Guest Specific Options
+
+The following options apply only to Paravirtual guests.
+
+=over 4
+
+=item B<kernel="PATHNAME">
+
+Load the specified file as the kernel image.  Either B<kernel> or
+B<bootloader> must be specified for PV guests.
+
+=item B<ramdisk="PATHNAME">
+
+Load the specified file as the ramdisk.
+
+=item B<bootloader="PROGRAM">
+
+Run C<PROGRAM> to find the kernel image and ramdisk to use.  Normally
+C<PROGRAM> would be C<pygrub>, which is an emulation of
+grub/grub2/syslinux.
+
+=item B<bootloader_args=STRING>
+
+Append B<STRING> (split into words at whitespace) to the arguments to
+the B<bootloader> program.  XXX this should be a list of strings.
+
+=item B<root="STRING">
+
+Append B<root="STRING"> to the kernel command line (Note: it is guest
+specific what meaning this has).
+
+=item B<extra="STRING">
+
+Append B<STRING> to the kernel command line. Note: it is guest
+specific what meaning this has).
+
+=item B<e820_host=BOOLEAN>
+
+Selects whether to expose the host e820 (memory map) to the guest via
+the virtual e820. When this option is false the guest psuedo-physical
+address space consists of a single contiguous RAM region. When this
+option is specified the virtual e820 instead reflects the host e820
+and contains the same PCI holes. The total amount of RAM represented
+by the memory map is always the same, this option configures only how
+it is layed out.
+
+Exposing the host e820 to the guest gives the guest kernel the
+opportunity to set aside the required part of its pseudo-physical
+address space in order to provide address space to map passedthrough
+PCI devices. It is guest Operaring System dependant whether this
+option is required, specifically it is required when using a mainline
+Linux ("pvops") kernel. This option defaults to true if any PCI
+passthrough devices are configued and false otherwise. If you do not
+configure any passthrough devices at domain creation time but expect
+to hotplug devices later then you should set this option. Conversely
+if your particular guest kernel does not require this behaviour then
+it is safe to allow this to be enabled but you may wish to disable it
+anyway.
+
+=back
+
+=head2 Fully-virtualised (HVM) Guest Specific Options
+
+The following options apply only to HVM guests.
+
+=head3 Boot Device
+
+=over 4
+
+=item B<boot=[c|d|n]>
+
+Selects the emulated virtual device to boot from. Options are hard
+disk (B<c>), cd-rom (B<d>) or network/PXE (B<n>). Multiple options can be
+given and will be attempted in the order they are given. e.g. to boot
+from cd-rom but fallback to the hard disk you can give B<dc>. The
+default is B<cd>.
+
+=back
+
+=head3 Paging
+
+The following options control the mechanisms used to virtualise guest
+memory.  The defaults are selected to give the best results for the
+common case and so you should normally leave these options
+unspecified.
+
+=over 4
+
+=item B<hap=BOOLEAN>
+
+Turns "hardware assisted paging" (the use of the hardware nested page
+table feature) on or off.  This feature is called EPT (Extended Page
+Tables) by Intel and NPT (Nested Page Tables) or RVI (Rapid
+Virtualisation Indexing) by AMD.  Affects HVM guests only.  If turned
+off, Xen will run the guest in "shadow page table" mode where the
+guest's page table updates and/or TLB flushes etc. will be emulated.
+Use of HAP is the default when available.
+
+=item B<oos=BOOLEAN>
+
+Turns "out of sync pagetables" on or off.  When running in shadow page
+table mode, the guest's page table updates may be deferred as
+specified in the Intel/AMD architecture manuals.  However this may
+expose unexpected bugs in the guest, or find bugs in Xen, so it is
+possible to disable this feature.  Use of out of sync page tables,
+when Xen thinks it appropriate, is the default.
+
+=item B<shadow_memory=MBYTES>
+
+Number of megabytes to set aside for shadowing guest pagetable pages
+(effectively acting as a cache of translated pages) or to use for HAP
+state. By default this is 1MB per guest vcpu plus 8KB per MB of guest
+RAM. You should not normally need to adjust this value. However if you
+are not using hardware assisted paging (i.e. you are using shadow
+mode) and your guest workload consists of a a very large number of
+similar processes then increasing this value may improve performance.
+
+=back
+
+=head3 Processor and Platform Features
+
+The following options allow various processor and platform level
+features to be hidden or exposed from the guest's point of view. This
+can be useful when running older guest Operating Systems which may
+misbehave when faced with more modern features. In general you should
+accept the defaults for these options wherever possible.
+
+=over 4
+
+=item B<pae=BOOLEAN>
+
+Hide or expose the IA32 Physical Address Extensions. These extensions
+make it possible for a 32 bit guest Operating System to access more
+than 4GB of RAM. Enabling PAE also enabled other features such as
+NX. PAE is required if you wish to run a 64-bit guest Operating
+System. In general you should leave this enabled and allow the guest
+Operating System to choose whether or not to use PAE. (X86 only)
+
+=item B<acpi=BOOLEAN>
+
+Expose ACPI (Advanced Configuration and Power Interface) tables from
+the virtual firmware to the guest Operating System. ACPI is required
+by most modern guest Operating Systems. This option is enabled by
+default and usually you should omit it. However it may be necessary to
+disable ACPI for compatibility with some guest Operating Systems.
+
+=item B<apic=BOOLEAN>
+
+Include information regarding APIC (Advanced Programmable Interrupt
+Controller) in the firmware/BIOS tables on a single processor
+guest. This causes the MP (multiprocessor) and PIR (PCI Interrupt
+Routing) tables to be exported by the virtual firmware. This option
+has no effect on a guest with multiple virtual CPUS as they must
+always include these tables. This option is enabled by default and you
+should usually omit it but it may be necessary to disable these
+firmware tables when using certain older guest Operating
+Systems. These tables have been superceded by newer constructs within
+the ACPI tables. (X86 only)
+
+=item B<nx=BOOLEAN>
+
+Hides or exposes the No-eXecute capability. This allows a guest
+Operating system to map pages such that they cannot be executed which
+can enhance security. This options requires that PAE also be
+enabled. (X86 only)
+
+=item B<hpet=BOOLEAN>
+
+Enables or disables HPET (High Precision Event Timer). This option is
+enabled by default and you should usually omit it. It may be necessary
+to disable the HPET in order to improve compatibility with guest
+Operating Systems (X86 only)
+
+=item B<nestedhvm=BOOLEAN>
+
+Enable or disables guest access to hardware virtualisation features,
+e.g. it allows a guest Operating System to also function as a
+hypervisor. This option is disabled by default. You may want this
+option if you want to run another hypervisor (including another copy
+of Xen) within a Xen guest or to support a guest Operating System
+which uses hardware virtualisation extensions (e.g. Windows XP
+compatibility mode on more modern Windows OS).
+
+=back 
+
+=head3 Guest Virtual Time Controls
+
+=over 4
+
+=item B<tsc_mode="MODE">
+
+Specifies how the TSC (Time Stamp Counter) should be provided to the
+guest.  XXX ???
+
+=back
+
+=head3 Support for Paravirtualisation of HVM Guests
+
+The following options allow Paravirtualised features (such as devices)
+to be exposed to the guest Operating System in an HVM guest.
+Utilising these features requires specific guest support but when
+available they will result in improved performance.
+
+=over 4
+
+=item B<xen_platform_pci=BOOLEAN>
+
+Enable or disable the Xen platform PCI device.  The presence of this
+virtual device enables a guest Operating System (subject to the
+availability of suitable drivers) to make use of paravirtualisation
+features such as disk and network devices etc. Enabling these drivers
+improves performance and is strongly recommended when available. PV
+drivers are available for various Operating Systems including HVM
+Linux L<http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers> and Microsoft
+Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
+
+=item B<viridian=BOOLEAN>
+
+Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
+compatible enlightenments to the guest.  These can improve performance
+of Microsoft Windows guests (XXX which versions of Windows benefit?)
+
+=back
+
+=head3 Emulated VGA Graphics Device
+
+The following options control the features of the emulated graphics
+device.  Many of these options behave similarly to the equivalent key
+in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
+(see above).
+
+=over 4
+
+=item B<videoram=MBYTES>
+
+Sets the amount of RAM which the emulated video card will contain,
+which in turn limits the resolutions and bit depths which will be
+available. This option is only available when using the B<stdvga>
+option (see below). The default is 8MB which is sufficient for
+e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
+amount of video ram is fixed at 4MB which is sufficient for 1024x768
+at 32 bpp.
+
+=item B<stdvga=BOOLEAN>
+
+Select a standard VGA card with VBE (VESA BIOS Extensions) as the
+emulated graphics device. The default is false which means to emulate
+a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
+later (e.g. Windows XP onwards) then you should enable this.
+
+=item B<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item B<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item B<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use. The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item B<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item B<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item B<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below of consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item B<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is not to enable this mode.
+
+=item B<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using B<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item B<nographic=BOOLEAN>
+
+Enable or disable the virtual graphics device.  The default is to
+provide a VGA graphics device but this option can be used to disable
+it.
+
+=back
+
+=head3 Spice Graphics Support
+
+The following options control the features of SPICE.
+
+=over 4
+
+=item B<spice=BOOLEAN>
+
+Allow access to the display via the SPICE protocol.  This enables the
+other SPICE-related settings.
+
+=item B<spicehost="ADDRESS">
+
+Specify the interface address to listen on if given, otherwise any
+interface.
+
+=item B<spiceport=NUMBER>
+
+Specify the port to listen on by the SPICE server if the SPICE is
+enabled.
+
+=item B<spicetls_port=NUMBER>
+
+Specify the secure port to listen on by the SPICE server if the SPICE
+is enabled. At least one of the spiceport or spicetls_port must be
+given if SPICE is enabled.  NB. the options depending on spicetls_port
+have not been supported.
+
+=item B<spicedisable_ticketing=BOOLEAN>
+
+Enable client connection without password. The default is false. If
+it's false (set to 0), spicepasswd must be set.
+
+=item B<spicepasswd="PASSWORD">
+
+Specify the ticket password which is used by a client for connection.
+
+=item B<spiceagent_mouse=BOOLEAN>
+
+Whether SPICE agent is used for client mouse mode. The default is true
+(turn on)
+
+=back
+
+=head3 Miscellaneous Emulated Hardware
+
+=over 4
+
+=item B<serial=DEVICE>
+
+Redirect the virtual serial port to B<DEVICE>. Please see the
+B<-serial> option in the L<qemu(1)> manpage for details of the valid
+B<DEVICE> options. Default is B<vc> when in graphical mode and
+B<stdio> if B<nographics=1> is used.
+
+=item B<soundhw=DEVICE>
+
+Select the virtual sound card to expose to the guest. The valid
+devices are defined by the device model configuration, please see the
+L<qemu(1)> manpage for details. The default is not to export any sound
+device.
+
+=item B<usb=BOOLEAN>
+
+Enables or disables a USB bus in the guest.
+
+=item B<usbdevice=DEVICE>
+
+Adds B<DEVICE> to the USB bus. The USB bus must also be enabled using
+B<usb=1>. The most common use for this option is B<usbdevice=tablet>
+which adds pointer device using absolute coordinates. Such devices
+function better than relative coordinate devices (such as a standard
+mouse) since many methods of exporting guest graphics (such as VNC)
+work better in this mode. Note that this is independent of the actual
+pointer device you are using on the host/client side. XXX should/could
+be a list of devices.
+
+=back
+
+=head3 Unclassified HVM Specific Options
+
+These HVM specific options have not yet been documented or
+classified. They almost certainly belong in a more appropriate
+section.
+
+=over 4
+
+=item B<vpt_align=BOOLEAN>
+
+Align the Virtual Platform Timer ??? XXX Reduces interrupts?
+
+=item B<timer_mode=NUMBER>
+
+Set mode for Virtual Timers XXX ??? should be an enum of particular
+values. See C<HVM_PARAM_TIMER_MODE> in
+F<xen/include/public/hvm/params.h>.
+
+=back
+
+=head2 Device-Model Options
+
+The following options control the selection of the device-model.  This
+is the component which provides emulation of the virtual devices to an
+HVM guest.  For a PV guest a device-model is sometimes used to provide
+backends for certain PV devices (most usually a virtual framebuffer
+device).
+
+=over 4
+
+=item B<device_model_version="DEVICE-MODEL">
+
+Selects which variant of the device-model should be used for this
+guest. Valid values are:
+
+=over 4
+
+=item B<qemu-xen-traditional>
+
+Use the device-model based upon the historical Xen fork of Qemu.  This
+device-model is currently the default.
+
+=item B<qemu-xen>
+
+use the device-model merged into the upstream Qemu project.  This
+device-model will become the default in a future version of Xen.
+
+=back
+
+It is recommended to accept the default value for new guests.  If
+you have existing guests then, depeending on the nature of the guest
+Operating System, you may wish to force them to use the device
+model which they were installed with.
+
+=item B<device_model_override="PATH">
+
+Override the path to the binary to be used as the device-model. The
+binary provided here MUST be consistent with the
+`device_model_version` which you have specified. You should not
+normally need to specify this option.
+
+=item B<device_model_stubdomain_override=BOOLEAN>
+
+Override the use of stubdomain based device-model.  Normally this will
+be automatically selected based upon the other features and options
+you have selected.
+
+=item B<device_model_args=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command
+line. Each element in the list is passed as an option to the
+device-model.
+
+=item B<device_model_args_pv=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+a PV device model only. Each element in the list is passed as an
+option to the device-model.
+
+=item B<device_model_args_hvm=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+an HVM device model only. Each element in the list is passed as an
+option to the device-model.
+
+=back
+
+=head2 Unclassified General Options
+
+These have not yet been fully documented or classified. They almost
+certainly belong in a more appropriate section.
+
+=over 4
+
+=item B<gfx_passthrough=BOOLEAN>
+
+Enable graphics device PCI passthrough. XXX which device is passed through ?
+
+=item B<nomigrate=BOOLEAN>
+
+Disable migration of this domain.  This enables certain other features
+which are incompatible with migration (currently certain TSC modes XXX
+?).
+
+=item B<pci_msitranslate=BOOLEAN>
+
+XXX
+
+=item B<pci_power_mgmt=BOOLEAN>
+
+XXX
+
+=item B<cpuid=XXX>
+
+XXX
+
+=back
+
+=head2 Keymaps
+
+The keymaps available are defined by the device-model which you are
+using. Commonly this includes:
+
+        ar  de-ch  es  fo     fr-ca  hu  ja  mk     no  pt-br  sv
+        da  en-gb  et  fr     fr-ch  is  lt  nl     pl  ru     th
+        de  en-us  fi  fr-be  hr     it  lv  nl-be  pt  sl     tr
+
+The default is B<en-us>.
+
+See L<qemu(1)> for more information.
+
+=head1 SEE ALSO
+
+=over 4
+
+=item L<xl(1)>
+
+=item F<xl-disk-configuration>
+
+=item F<xl-network-configuration>
+
+=back
+
+=head1 FILES
+
+F</etc/xen/NAME.cfg>
+F</var/xen/dump/NAME>
+F<docs/misc/tscmode.txt>
+
+=head1 BUGS
+
+This document is a work in progress and contains items which require
+further documentation and which are generally incomplete (marked with
+XXX).  However all options are included here whether or not they are
+fully documented.
+
+Patches to improve incomplete items (or any other item) would be
+greatfully received on the xen-devel@lists.xensource.com mailing
+list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
+information on how to submit a patch to Xen.
+
diff -r 96479242221d -r 08a74d202a0a docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Fri Nov 25 11:52:48 2011 +0000
+++ b/docs/man/xl.pod.1	Fri Nov 25 11:52:55 2011 +0000
@@ -54,7 +54,7 @@ previously, most commands take I<domain-
 
 =item B<create> [I<OPTIONS>] I<configfile>
 
-The create subcommand requires a config file: see L<xldomain.cfg> for
+The create subcommand requires a config file: see L<xl.cfg(5)> for
 full details of that file format and possible options.
 
 I<configfile> can either be an absolute path to a file, or a relative
@@ -232,7 +232,7 @@ FIXME: Why would you ever see this state
 
 The domain has crashed, which is always a violent ending.  Usually
 this state can only occur if the domain has been configured not to
-restart on crash.  See L<xldomain.cfg> for more info.
+restart on crash.  See L<xl.cfg(5)> for more info.
 
 =item B<d - dying>
 
@@ -319,8 +319,8 @@ executed the reboot action, which may be
 domain actually reboots.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_reboot> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_reboot> parameter of the domain configuration file when the
+domain was created.
 
 =item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile>
 
@@ -372,8 +372,8 @@ services must be shutdown in the domain.
 immediately after signally the domain unless that B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_shutdown> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_shutdown> parameter of the domain configuration file when the
+domain was created.
 
 B<OPTIONS>
 
@@ -699,7 +699,7 @@ The domain id of the guest domain that t
 =item I<disc-spec-component>
 
 A disc specification in the same format used for the B<disk> variable in
-the domain config file. See L<xldomain.cfg>.
+the domain config file. See F<xl-disk-configuration>.
 
 =back
 
@@ -733,9 +733,9 @@ How the device should be presented to th
 
 =item I<be-dev>
 
-the device in the backend domain (usually domain 0) to be exported; it can be a
-path to a file (file://path/to/file.iso). See B<disk> in L<xldomain.cfg> for the
-details.
+the device in the backend domain (usually domain 0) to be exported; it
+can be a path to a file (file://path/to/file.iso). See B<disk> in
+L<xl.cfg(5)> for the details.
 
 =back
 
@@ -754,7 +754,7 @@ I<VirtualDevice> is the cdrom device in 
 
 Creates a new network device in the domain specified by I<domain-id>.
 I<network-device> describes the device to attach, using the same format as the
-B<vif> string in the domain config file. See L<xldomain.cfg> for the
+B<vif> string in the domain config file. See L<xl.cfg(5)> for the
 description.
 
 =item B<network-detach> I<domain-id> I<devid|mac>
@@ -795,7 +795,7 @@ List pass-through pci devices for a doma
 
 =head1 SEE ALSO
 
-B<xldomain.cfg>(5), B<xlcpupool.cfg>(5), B<xentop>(1)
+L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
 
 =head1 AUTHOR
 
diff -r 96479242221d -r 08a74d202a0a tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Fri Nov 25 11:52:48 2011 +0000
+++ b/tools/examples/xlexample.hvm	Fri Nov 25 11:52:55 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for an
-# HVM guest. For a more complete guide see <XXX Document TBD>
+# HVM guest. For a more complete guide see xl.cfg(5)
 
 # This configures an HVM rather than PV guest
 builder = "hvm"
diff -r 96479242221d -r 08a74d202a0a tools/examples/xlexample.pvlinux
--- a/tools/examples/xlexample.pvlinux	Fri Nov 25 11:52:48 2011 +0000
+++ b/tools/examples/xlexample.pvlinux	Fri Nov 25 11:52:55 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for a
-# Paravirtualised Linux guest. For a more complete guide see <XXX Document TBD>
+# Paravirtualised Linux guest. For a more complete guide see xl.cfg(5)
 
 # Guest name
 name = "example.pvlinux"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6U-0008DU-G9; Fri, 25 Nov 2011 14:50:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6S-0008Ck-VI
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!3
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13770 invoked from network); 25 Nov 2011 14:49:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874324"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:39 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq6030497;	Fri, 25 Nov 2011 06:49:38 -0800
MIME-Version: 1.0
X-Mercurial-Node: 08a74d202a0a5b19b1229da893526856d832807b
Message-ID: <08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:37 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document describing the
 xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221975 0
# Node ID 08a74d202a0a5b19b1229da893526856d832807b
# Parent  96479242221d8b58dde242442c47da2ab4c71a8f
docs: add a document describing the xl cfg file syntax

Based on an initial version by Ian Jackson.

I believe that all keys are now present in the document although there are are
various omissions in the actual documentation of them. Hopefully however this
covers the majority of the most interesting keys.

Spice section:
Signed-off-by: Zhou Peng <zhoupeng@nfs.iscas.ac.cn>

The rest:
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 96479242221d -r 08a74d202a0a docs/man/xl.cfg.pod.5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/man/xl.cfg.pod.5	Fri Nov 25 11:52:55 2011 +0000
@@ -0,0 +1,844 @@
+=head1 NAME
+
+xl.cfg - XL Domain Configuration File Syntax
+
+=head1 SYNOPSIS
+
+ /etc/xen/xldomain
+
+=head1 DESCRIPTION
+
+To create a VM (a domain in Xen terminology, sometimes called a guest)
+with xl requires the provision of a domain config file.  Typically
+these live in `/etc/xen/DOMAIN.cfg` where DOMAIN is the name of the
+domain.
+
+=head1 SYNTAX
+
+A domain config file consists of a series of C<KEY=VALUE> pairs.
+
+Some C<KEY>s are mandatory, others are global options which apply to
+any guest type while others relate only to specific guest types
+(e.g. PV or HVM guests).
+
+A value C<VALUE> is one of:
+
+=over 4
+
+=item B<"STRING">
+
+A string, surrounded by either single or double quotes.
+
+=item B<NUMBER>
+
+A number, in either decimal, octal (using a C<0> prefix) or
+hexadecimal (using an C<0x> prefix).
+
+=item B<BOOLEAN>
+
+A C<NUMBER> interpreted as C<False> (C<0>) or C<True> (any other
+value).
+
+=item B<[ VALUE, VALUE, ... ]>
+
+A list of C<VALUES> of the above types. Lists are homogeneous and are
+not nested.
+
+=back
+
+The semantics of each C<KEY> defines which form of C<VALUE> is required.
+
+=head1 OPTIONS
+
+=head2 Mandatory Configuration Items
+
+The following key is mandatory for any guest type:
+
+=over 4
+
+=item B<name="NAME">
+
+Specifies the name of the domain.  Names of domains existing on a
+single host must be unique.
+
+=back
+
+=head2 Selecting Guest Type
+
+=over 4
+
+=item B<builder="generic">
+
+Specifies that this is to be a PV domain. This is the default.
+
+=item B<builder="hvm">
+
+Specifies that this is to be an HVM domain.  That is, a fully
+virtualised computer with emulated BIOS, disk and network peripherals,
+etc.  The default is a PV domain, suitable for hosting Xen-aware guest
+operating systems.
+
+=back
+
+=head2 Global Options
+
+The following options apply to guests of any type.
+
+=over 4
+
+=item B<uuid="UUID">
+
+Specifies the UUID of the domain.  If not specified, a fresh unique
+UUID will be generated.
+
+=item B<pool="CPUPOOLNAME">
+
+Put the guest's vcpus into the named cpu pool.
+
+=item B<vcpus=N>
+
+Start the guest with N vcpus initially online.
+
+=item B<maxvcpus=M>
+
+Allow the guest to bring up a maximum of M vcpus. At start of day if
+`vcpus=N` is less than `maxvcpus=M` then the first `N` vcpus will be
+created online and the remainder will be offline.
+
+=item B<memory=MBYTES>
+
+Start the guest with MBYTES megabytes of RAM.
+
+=item B<on_poweroff="ACTION">
+
+Specifies what should be done with the domain if it shuts itself down.
+The C<ACTION>s are:
+
+=over 4
+
+=item B<destroy>
+
+destroy the domain
+     
+=item B<restart>
+
+destroy the domain and immediately create a new domain with the same
+configuration
+        
+=item B<rename-restart>
+
+rename the domain which terminated, and thenimmediately create a new
+domain with the same configuration as the original
+
+=item B<preserve>
+
+keep the domain.  It can be examined, and later destroyed with `xl
+destroy`.
+
+=item B<coredump-destroy>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+destroy the domain.
+
+=item B<coredump-restart>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+restart the domain.
+
+=back
+
+The default for C<on_poweroff> is C<destroy>.
+
+=item B<on_reboot="ACTION">
+
+Action to take if the domain shuts down with a reason code requesting
+a reboot.  Default is C<restart>.
+
+=item B<on_watchdog="ACTION">
+
+Action to take if the domain shuts down due to a Xen watchdog timeout.
+Default is C<destroy>.
+
+=item B<on_crash="ACTION">
+
+Action to take if the domain crashes.  Default is C<destroy>.
+
+=item B<seclabel="LABEL">
+
+Assign an XSM security label to this domain.
+
+=back
+
+=head2 Devices
+
+The following options define the paravirtual, emulated and physical
+devices which the guest will contain.
+
+=over 4
+
+=item B<disk=[ "DISK_SPEC_STRING", "DISK_SPEC_STRING", ...]>
+
+Specifies the disks (both emulated disks and Xen virtual block
+devices) which are to be provided to the guest, and what objects on
+the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
+
+=item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
+
+Specifies the networking provision (both emulated network adapters,
+and Xen virtual interfaces) to provided to the guest.  See
+F<docs/misc/xl-network-configuration.markdown>.
+
+=item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
+
+Specifies the paravirtual framebuffer devices which should be supplied
+to the domain.
+
+This options does not control the emulated graphics card presented to
+an HVM guest. See L<Emulated VGA Graphics Device> below for how to
+configure the emulated device.
+
+Each B<VFB_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
+settings, from the following list:
+
+=over 4
+
+=item C<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item C<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item C<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use.  The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item C<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item C<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item C<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is to not enable this mode
+
+=item C<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using C<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item C<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below or consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item C<display=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=item C<authority=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=back
+
+=item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ... ]>
+
+Specifies the host PCI devices to passthrough to this guest. Each B<PCI_SPEC_STRING>
+has the form C<[DDDD:]BB:DD.F[@VSLOT],KEY=VALUE,KEY=VALUE,...> where:
+
+=over 4
+
+=item B<DDDD:BB:DD.F>
+
+identifies the PCI device from the host perspective in domain
+(B<DDDD>), Bus (B<BB>), Device (B<DD>) and Function (B<F>) syntax. This is
+the same scheme as used in the output of C<lspci> for the device in
+question. Note: By default C<lspci> will omit the domain (B<DDDD>) if it
+is zero and it is optional here also. You may specify the function
+(B<F>) as B<*> to indicate all functions.
+
+=item B<@VSLOT>
+
+specifies the virtual device where the guest will see this
+device. This is equivalent to the B<DD> which the guest sees. In a
+guest B<DDDD> and B<BB> are C<0000:00>. XXX how does this really work?
+
+=item B<KEY=VALUE>
+
+Posible B<KEY>s are:
+
+=over 4
+
+=item B<msitranslate=BOOLEAN>
+
+XXX
+
+=item B<power_mgmt=BOOLEAN>
+
+XXX
+
+=back
+
+=back
+
+=back
+
+=head2 Paravirtualised (PV) Guest Specific Options
+
+The following options apply only to Paravirtual guests.
+
+=over 4
+
+=item B<kernel="PATHNAME">
+
+Load the specified file as the kernel image.  Either B<kernel> or
+B<bootloader> must be specified for PV guests.
+
+=item B<ramdisk="PATHNAME">
+
+Load the specified file as the ramdisk.
+
+=item B<bootloader="PROGRAM">
+
+Run C<PROGRAM> to find the kernel image and ramdisk to use.  Normally
+C<PROGRAM> would be C<pygrub>, which is an emulation of
+grub/grub2/syslinux.
+
+=item B<bootloader_args=STRING>
+
+Append B<STRING> (split into words at whitespace) to the arguments to
+the B<bootloader> program.  XXX this should be a list of strings.
+
+=item B<root="STRING">
+
+Append B<root="STRING"> to the kernel command line (Note: it is guest
+specific what meaning this has).
+
+=item B<extra="STRING">
+
+Append B<STRING> to the kernel command line. Note: it is guest
+specific what meaning this has).
+
+=item B<e820_host=BOOLEAN>
+
+Selects whether to expose the host e820 (memory map) to the guest via
+the virtual e820. When this option is false the guest psuedo-physical
+address space consists of a single contiguous RAM region. When this
+option is specified the virtual e820 instead reflects the host e820
+and contains the same PCI holes. The total amount of RAM represented
+by the memory map is always the same, this option configures only how
+it is layed out.
+
+Exposing the host e820 to the guest gives the guest kernel the
+opportunity to set aside the required part of its pseudo-physical
+address space in order to provide address space to map passedthrough
+PCI devices. It is guest Operaring System dependant whether this
+option is required, specifically it is required when using a mainline
+Linux ("pvops") kernel. This option defaults to true if any PCI
+passthrough devices are configued and false otherwise. If you do not
+configure any passthrough devices at domain creation time but expect
+to hotplug devices later then you should set this option. Conversely
+if your particular guest kernel does not require this behaviour then
+it is safe to allow this to be enabled but you may wish to disable it
+anyway.
+
+=back
+
+=head2 Fully-virtualised (HVM) Guest Specific Options
+
+The following options apply only to HVM guests.
+
+=head3 Boot Device
+
+=over 4
+
+=item B<boot=[c|d|n]>
+
+Selects the emulated virtual device to boot from. Options are hard
+disk (B<c>), cd-rom (B<d>) or network/PXE (B<n>). Multiple options can be
+given and will be attempted in the order they are given. e.g. to boot
+from cd-rom but fallback to the hard disk you can give B<dc>. The
+default is B<cd>.
+
+=back
+
+=head3 Paging
+
+The following options control the mechanisms used to virtualise guest
+memory.  The defaults are selected to give the best results for the
+common case and so you should normally leave these options
+unspecified.
+
+=over 4
+
+=item B<hap=BOOLEAN>
+
+Turns "hardware assisted paging" (the use of the hardware nested page
+table feature) on or off.  This feature is called EPT (Extended Page
+Tables) by Intel and NPT (Nested Page Tables) or RVI (Rapid
+Virtualisation Indexing) by AMD.  Affects HVM guests only.  If turned
+off, Xen will run the guest in "shadow page table" mode where the
+guest's page table updates and/or TLB flushes etc. will be emulated.
+Use of HAP is the default when available.
+
+=item B<oos=BOOLEAN>
+
+Turns "out of sync pagetables" on or off.  When running in shadow page
+table mode, the guest's page table updates may be deferred as
+specified in the Intel/AMD architecture manuals.  However this may
+expose unexpected bugs in the guest, or find bugs in Xen, so it is
+possible to disable this feature.  Use of out of sync page tables,
+when Xen thinks it appropriate, is the default.
+
+=item B<shadow_memory=MBYTES>
+
+Number of megabytes to set aside for shadowing guest pagetable pages
+(effectively acting as a cache of translated pages) or to use for HAP
+state. By default this is 1MB per guest vcpu plus 8KB per MB of guest
+RAM. You should not normally need to adjust this value. However if you
+are not using hardware assisted paging (i.e. you are using shadow
+mode) and your guest workload consists of a a very large number of
+similar processes then increasing this value may improve performance.
+
+=back
+
+=head3 Processor and Platform Features
+
+The following options allow various processor and platform level
+features to be hidden or exposed from the guest's point of view. This
+can be useful when running older guest Operating Systems which may
+misbehave when faced with more modern features. In general you should
+accept the defaults for these options wherever possible.
+
+=over 4
+
+=item B<pae=BOOLEAN>
+
+Hide or expose the IA32 Physical Address Extensions. These extensions
+make it possible for a 32 bit guest Operating System to access more
+than 4GB of RAM. Enabling PAE also enabled other features such as
+NX. PAE is required if you wish to run a 64-bit guest Operating
+System. In general you should leave this enabled and allow the guest
+Operating System to choose whether or not to use PAE. (X86 only)
+
+=item B<acpi=BOOLEAN>
+
+Expose ACPI (Advanced Configuration and Power Interface) tables from
+the virtual firmware to the guest Operating System. ACPI is required
+by most modern guest Operating Systems. This option is enabled by
+default and usually you should omit it. However it may be necessary to
+disable ACPI for compatibility with some guest Operating Systems.
+
+=item B<apic=BOOLEAN>
+
+Include information regarding APIC (Advanced Programmable Interrupt
+Controller) in the firmware/BIOS tables on a single processor
+guest. This causes the MP (multiprocessor) and PIR (PCI Interrupt
+Routing) tables to be exported by the virtual firmware. This option
+has no effect on a guest with multiple virtual CPUS as they must
+always include these tables. This option is enabled by default and you
+should usually omit it but it may be necessary to disable these
+firmware tables when using certain older guest Operating
+Systems. These tables have been superceded by newer constructs within
+the ACPI tables. (X86 only)
+
+=item B<nx=BOOLEAN>
+
+Hides or exposes the No-eXecute capability. This allows a guest
+Operating system to map pages such that they cannot be executed which
+can enhance security. This options requires that PAE also be
+enabled. (X86 only)
+
+=item B<hpet=BOOLEAN>
+
+Enables or disables HPET (High Precision Event Timer). This option is
+enabled by default and you should usually omit it. It may be necessary
+to disable the HPET in order to improve compatibility with guest
+Operating Systems (X86 only)
+
+=item B<nestedhvm=BOOLEAN>
+
+Enable or disables guest access to hardware virtualisation features,
+e.g. it allows a guest Operating System to also function as a
+hypervisor. This option is disabled by default. You may want this
+option if you want to run another hypervisor (including another copy
+of Xen) within a Xen guest or to support a guest Operating System
+which uses hardware virtualisation extensions (e.g. Windows XP
+compatibility mode on more modern Windows OS).
+
+=back 
+
+=head3 Guest Virtual Time Controls
+
+=over 4
+
+=item B<tsc_mode="MODE">
+
+Specifies how the TSC (Time Stamp Counter) should be provided to the
+guest.  XXX ???
+
+=back
+
+=head3 Support for Paravirtualisation of HVM Guests
+
+The following options allow Paravirtualised features (such as devices)
+to be exposed to the guest Operating System in an HVM guest.
+Utilising these features requires specific guest support but when
+available they will result in improved performance.
+
+=over 4
+
+=item B<xen_platform_pci=BOOLEAN>
+
+Enable or disable the Xen platform PCI device.  The presence of this
+virtual device enables a guest Operating System (subject to the
+availability of suitable drivers) to make use of paravirtualisation
+features such as disk and network devices etc. Enabling these drivers
+improves performance and is strongly recommended when available. PV
+drivers are available for various Operating Systems including HVM
+Linux L<http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers> and Microsoft
+Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
+
+=item B<viridian=BOOLEAN>
+
+Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
+compatible enlightenments to the guest.  These can improve performance
+of Microsoft Windows guests (XXX which versions of Windows benefit?)
+
+=back
+
+=head3 Emulated VGA Graphics Device
+
+The following options control the features of the emulated graphics
+device.  Many of these options behave similarly to the equivalent key
+in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
+(see above).
+
+=over 4
+
+=item B<videoram=MBYTES>
+
+Sets the amount of RAM which the emulated video card will contain,
+which in turn limits the resolutions and bit depths which will be
+available. This option is only available when using the B<stdvga>
+option (see below). The default is 8MB which is sufficient for
+e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
+amount of video ram is fixed at 4MB which is sufficient for 1024x768
+at 32 bpp.
+
+=item B<stdvga=BOOLEAN>
+
+Select a standard VGA card with VBE (VESA BIOS Extensions) as the
+emulated graphics device. The default is false which means to emulate
+a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
+later (e.g. Windows XP onwards) then you should enable this.
+
+=item B<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item B<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item B<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use. The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item B<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item B<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item B<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below of consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item B<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is not to enable this mode.
+
+=item B<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using B<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item B<nographic=BOOLEAN>
+
+Enable or disable the virtual graphics device.  The default is to
+provide a VGA graphics device but this option can be used to disable
+it.
+
+=back
+
+=head3 Spice Graphics Support
+
+The following options control the features of SPICE.
+
+=over 4
+
+=item B<spice=BOOLEAN>
+
+Allow access to the display via the SPICE protocol.  This enables the
+other SPICE-related settings.
+
+=item B<spicehost="ADDRESS">
+
+Specify the interface address to listen on if given, otherwise any
+interface.
+
+=item B<spiceport=NUMBER>
+
+Specify the port to listen on by the SPICE server if the SPICE is
+enabled.
+
+=item B<spicetls_port=NUMBER>
+
+Specify the secure port to listen on by the SPICE server if the SPICE
+is enabled. At least one of the spiceport or spicetls_port must be
+given if SPICE is enabled.  NB. the options depending on spicetls_port
+have not been supported.
+
+=item B<spicedisable_ticketing=BOOLEAN>
+
+Enable client connection without password. The default is false. If
+it's false (set to 0), spicepasswd must be set.
+
+=item B<spicepasswd="PASSWORD">
+
+Specify the ticket password which is used by a client for connection.
+
+=item B<spiceagent_mouse=BOOLEAN>
+
+Whether SPICE agent is used for client mouse mode. The default is true
+(turn on)
+
+=back
+
+=head3 Miscellaneous Emulated Hardware
+
+=over 4
+
+=item B<serial=DEVICE>
+
+Redirect the virtual serial port to B<DEVICE>. Please see the
+B<-serial> option in the L<qemu(1)> manpage for details of the valid
+B<DEVICE> options. Default is B<vc> when in graphical mode and
+B<stdio> if B<nographics=1> is used.
+
+=item B<soundhw=DEVICE>
+
+Select the virtual sound card to expose to the guest. The valid
+devices are defined by the device model configuration, please see the
+L<qemu(1)> manpage for details. The default is not to export any sound
+device.
+
+=item B<usb=BOOLEAN>
+
+Enables or disables a USB bus in the guest.
+
+=item B<usbdevice=DEVICE>
+
+Adds B<DEVICE> to the USB bus. The USB bus must also be enabled using
+B<usb=1>. The most common use for this option is B<usbdevice=tablet>
+which adds pointer device using absolute coordinates. Such devices
+function better than relative coordinate devices (such as a standard
+mouse) since many methods of exporting guest graphics (such as VNC)
+work better in this mode. Note that this is independent of the actual
+pointer device you are using on the host/client side. XXX should/could
+be a list of devices.
+
+=back
+
+=head3 Unclassified HVM Specific Options
+
+These HVM specific options have not yet been documented or
+classified. They almost certainly belong in a more appropriate
+section.
+
+=over 4
+
+=item B<vpt_align=BOOLEAN>
+
+Align the Virtual Platform Timer ??? XXX Reduces interrupts?
+
+=item B<timer_mode=NUMBER>
+
+Set mode for Virtual Timers XXX ??? should be an enum of particular
+values. See C<HVM_PARAM_TIMER_MODE> in
+F<xen/include/public/hvm/params.h>.
+
+=back
+
+=head2 Device-Model Options
+
+The following options control the selection of the device-model.  This
+is the component which provides emulation of the virtual devices to an
+HVM guest.  For a PV guest a device-model is sometimes used to provide
+backends for certain PV devices (most usually a virtual framebuffer
+device).
+
+=over 4
+
+=item B<device_model_version="DEVICE-MODEL">
+
+Selects which variant of the device-model should be used for this
+guest. Valid values are:
+
+=over 4
+
+=item B<qemu-xen-traditional>
+
+Use the device-model based upon the historical Xen fork of Qemu.  This
+device-model is currently the default.
+
+=item B<qemu-xen>
+
+use the device-model merged into the upstream Qemu project.  This
+device-model will become the default in a future version of Xen.
+
+=back
+
+It is recommended to accept the default value for new guests.  If
+you have existing guests then, depeending on the nature of the guest
+Operating System, you may wish to force them to use the device
+model which they were installed with.
+
+=item B<device_model_override="PATH">
+
+Override the path to the binary to be used as the device-model. The
+binary provided here MUST be consistent with the
+`device_model_version` which you have specified. You should not
+normally need to specify this option.
+
+=item B<device_model_stubdomain_override=BOOLEAN>
+
+Override the use of stubdomain based device-model.  Normally this will
+be automatically selected based upon the other features and options
+you have selected.
+
+=item B<device_model_args=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command
+line. Each element in the list is passed as an option to the
+device-model.
+
+=item B<device_model_args_pv=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+a PV device model only. Each element in the list is passed as an
+option to the device-model.
+
+=item B<device_model_args_hvm=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+an HVM device model only. Each element in the list is passed as an
+option to the device-model.
+
+=back
+
+=head2 Unclassified General Options
+
+These have not yet been fully documented or classified. They almost
+certainly belong in a more appropriate section.
+
+=over 4
+
+=item B<gfx_passthrough=BOOLEAN>
+
+Enable graphics device PCI passthrough. XXX which device is passed through ?
+
+=item B<nomigrate=BOOLEAN>
+
+Disable migration of this domain.  This enables certain other features
+which are incompatible with migration (currently certain TSC modes XXX
+?).
+
+=item B<pci_msitranslate=BOOLEAN>
+
+XXX
+
+=item B<pci_power_mgmt=BOOLEAN>
+
+XXX
+
+=item B<cpuid=XXX>
+
+XXX
+
+=back
+
+=head2 Keymaps
+
+The keymaps available are defined by the device-model which you are
+using. Commonly this includes:
+
+        ar  de-ch  es  fo     fr-ca  hu  ja  mk     no  pt-br  sv
+        da  en-gb  et  fr     fr-ch  is  lt  nl     pl  ru     th
+        de  en-us  fi  fr-be  hr     it  lv  nl-be  pt  sl     tr
+
+The default is B<en-us>.
+
+See L<qemu(1)> for more information.
+
+=head1 SEE ALSO
+
+=over 4
+
+=item L<xl(1)>
+
+=item F<xl-disk-configuration>
+
+=item F<xl-network-configuration>
+
+=back
+
+=head1 FILES
+
+F</etc/xen/NAME.cfg>
+F</var/xen/dump/NAME>
+F<docs/misc/tscmode.txt>
+
+=head1 BUGS
+
+This document is a work in progress and contains items which require
+further documentation and which are generally incomplete (marked with
+XXX).  However all options are included here whether or not they are
+fully documented.
+
+Patches to improve incomplete items (or any other item) would be
+greatfully received on the xen-devel@lists.xensource.com mailing
+list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
+information on how to submit a patch to Xen.
+
diff -r 96479242221d -r 08a74d202a0a docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Fri Nov 25 11:52:48 2011 +0000
+++ b/docs/man/xl.pod.1	Fri Nov 25 11:52:55 2011 +0000
@@ -54,7 +54,7 @@ previously, most commands take I<domain-
 
 =item B<create> [I<OPTIONS>] I<configfile>
 
-The create subcommand requires a config file: see L<xldomain.cfg> for
+The create subcommand requires a config file: see L<xl.cfg(5)> for
 full details of that file format and possible options.
 
 I<configfile> can either be an absolute path to a file, or a relative
@@ -232,7 +232,7 @@ FIXME: Why would you ever see this state
 
 The domain has crashed, which is always a violent ending.  Usually
 this state can only occur if the domain has been configured not to
-restart on crash.  See L<xldomain.cfg> for more info.
+restart on crash.  See L<xl.cfg(5)> for more info.
 
 =item B<d - dying>
 
@@ -319,8 +319,8 @@ executed the reboot action, which may be
 domain actually reboots.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_reboot> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_reboot> parameter of the domain configuration file when the
+domain was created.
 
 =item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile>
 
@@ -372,8 +372,8 @@ services must be shutdown in the domain.
 immediately after signally the domain unless that B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_shutdown> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_shutdown> parameter of the domain configuration file when the
+domain was created.
 
 B<OPTIONS>
 
@@ -699,7 +699,7 @@ The domain id of the guest domain that t
 =item I<disc-spec-component>
 
 A disc specification in the same format used for the B<disk> variable in
-the domain config file. See L<xldomain.cfg>.
+the domain config file. See F<xl-disk-configuration>.
 
 =back
 
@@ -733,9 +733,9 @@ How the device should be presented to th
 
 =item I<be-dev>
 
-the device in the backend domain (usually domain 0) to be exported; it can be a
-path to a file (file://path/to/file.iso). See B<disk> in L<xldomain.cfg> for the
-details.
+the device in the backend domain (usually domain 0) to be exported; it
+can be a path to a file (file://path/to/file.iso). See B<disk> in
+L<xl.cfg(5)> for the details.
 
 =back
 
@@ -754,7 +754,7 @@ I<VirtualDevice> is the cdrom device in 
 
 Creates a new network device in the domain specified by I<domain-id>.
 I<network-device> describes the device to attach, using the same format as the
-B<vif> string in the domain config file. See L<xldomain.cfg> for the
+B<vif> string in the domain config file. See L<xl.cfg(5)> for the
 description.
 
 =item B<network-detach> I<domain-id> I<devid|mac>
@@ -795,7 +795,7 @@ List pass-through pci devices for a doma
 
 =head1 SEE ALSO
 
-B<xldomain.cfg>(5), B<xlcpupool.cfg>(5), B<xentop>(1)
+L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
 
 =head1 AUTHOR
 
diff -r 96479242221d -r 08a74d202a0a tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Fri Nov 25 11:52:48 2011 +0000
+++ b/tools/examples/xlexample.hvm	Fri Nov 25 11:52:55 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for an
-# HVM guest. For a more complete guide see <XXX Document TBD>
+# HVM guest. For a more complete guide see xl.cfg(5)
 
 # This configures an HVM rather than PV guest
 builder = "hvm"
diff -r 96479242221d -r 08a74d202a0a tools/examples/xlexample.pvlinux
--- a/tools/examples/xlexample.pvlinux	Fri Nov 25 11:52:48 2011 +0000
+++ b/tools/examples/xlexample.pvlinux	Fri Nov 25 11:52:55 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for a
-# Paravirtualised Linux guest. For a more complete guide see <XXX Document TBD>
+# Paravirtualised Linux guest. For a more complete guide see xl.cfg(5)
 
 # Guest name
 name = "example.pvlinux"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6a-0008FE-05; Fri, 25 Nov 2011 14:50:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6X-0008DG-UN
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!6
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14021 invoked from network); 25 Nov 2011 14:49:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874330"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:44 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqC030497;	Fri, 25 Nov 2011 06:49:43 -0800
MIME-Version: 1.0
X-Mercurial-Node: 00ea49f77bdcef16251e3773c99fc02394524b83
Message-ID: <00ea49f77bdcef16251e.1322232583@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:43 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 11 of 15 v2] docs: generate an index for the
	html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322231661 0
# Node ID 00ea49f77bdcef16251e3773c99fc02394524b83
# Parent  ddeac8b237e4f71d05c817fa8432417886e7e202
docs: generate an index for the html output

nb: I'm not a Perl wizard...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ddeac8b237e4 -r 00ea49f77bdc docs/INDEX
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/INDEX	Fri Nov 25 14:34:21 2011 +0000
@@ -0,0 +1,5 @@
+misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
+
+# These are not all that useful anymore, hide them from the index
+interface/index			NO-INDEX
+user/index			NO-INDEX
diff -r ddeac8b237e4 -r 00ea49f77bdc docs/Makefile
--- a/docs/Makefile	Fri Nov 25 11:53:06 2011 +0000
+++ b/docs/Makefile	Fri Nov 25 14:34:21 2011 +0000
@@ -45,7 +45,7 @@ ps: $(DOC_PS)
 pdf: $(DOC_PDF)
 
 .PHONY: html
-html: $(DOC_HTML)
+html: $(DOC_HTML) html/index.html
 
 .PHONY: txt
 txt: $(DOC_TXT)
@@ -128,6 +128,9 @@ html/%/index.html: src/%.tex
 	$< 1>/dev/null 2>/dev/null ; else \
 	echo "latex2html not installed; skipping $*."; fi
 
+html/index.html: $(DOC_HTML) ./gen-html-index INDEX
+	./gen-html-index -i INDEX html $(DOC_HTML)
+
 html/%.html: %.markdown
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \
diff -r ddeac8b237e4 -r 00ea49f77bdc docs/gen-html-index
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/gen-html-index	Fri Nov 25 14:34:21 2011 +0000
@@ -0,0 +1,136 @@
+#!/usr/bin/perl -w
+
+#
+# Generate indexes for html documentation
+#
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+use IO::File;
+use File::Basename;
+use List::MoreUtils qw/ uniq /;
+
+Getopt::Long::Configure('bundling');
+
+@ARGV >= 2 or die;
+
+our @docs;
+our @dirs;
+our %index;
+
+our $outdir;
+
+GetOptions("i=s" => sub { read_index(@_);} )
+    or die;
+
+($outdir,@docs) = @ARGV;
+
+sub write_file ($$) {
+    my ($opath, $odata) = @_;
+    print STDOUT "Writing: $opath\n";
+    my $out = new IO::File "$opath.new", '>' or die "$opath $!";
+    print $out $odata or die $!;
+    rename "$opath.new", "$opath" or die "$opath $!";
+}
+
+sub make_page ($$$) {
+    my ($file,$title,$content) = @_;
+    my $o = '';
+    my $h1;
+    if ( $title eq "" )
+    {
+        $title = $h1 = "Xen Documentation";
+    }
+    else
+    {
+        $h1 = "<a href=\"../index.(?:html|txt)\">Xen Documentation</a> - $title";
+        $title = "Xen Documentation - $title";
+    }
+    $o .= <<END;
+<html><head><title>$title</title></head>
+<body>
+<h1>$h1</h1>
+<ul>
+$content
+</ul>
+</body></html>
+END
+    write_file($file, $o);
+}
+
+sub make_linktext ($) {
+    my ($l) = @_;
+    return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
+    $l =~ s/.(html)$//g;
+    return $index{$l} if exists $index{$l};
+    return basename($l);
+}
+
+sub make_link ($$) {
+    my ($ref,$base) = @_;
+
+    my $txt = make_linktext($ref);
+    $ref = basename($ref) if $base;
+
+    return "<li><a href=\"$ref\">$txt</a></li>\n";
+}
+
+sub make_links ($$@) {
+    my ($dir,$base,@docs) = @_;
+    my $idx = '';
+    foreach my $of (sort { $a cmp $b } @docs) {
+        $idx .= make_link($of,$base);
+    }
+    return $idx;
+}
+
+sub read_index ($$) {
+    my ($opt, $val) = @_;
+    my $idx = new IO::File "$val", '<' or die "$val $!";
+    while ($_ = $idx->getline()) {
+	s/^\s+//;
+	s/\s+$//;
+	next if m/^\#/;
+	next unless m/\S/;
+	m/^(\S+)\s+(\S.*)$/ or die;
+        $index{$1} = $2;
+    }
+}
+
+for (@docs) { s,^\Q$outdir\E/,, }
+
+@docs = grep { -e "$outdir/$_" && (make_linktext($_) ne "NO-INDEX") } @docs;
+
+my $top = '';
+
+foreach my $od (sort { $a cmp $b } uniq map { dirname($_) } @docs) {
+    my @d = (grep /^\Q$od\E/, @docs);
+    if ( @d == 1 and $d[0] eq "$od/index.html" )
+    {
+        $top .= "<li><a href=\"${od}/index.html\">${od}/index.html</a></li>\n";
+    }
+    else
+    {
+	my $links = make_links($od,0,@d);
+	$top .= <<END;
+<li><a href=\"${od}/index.html\">$od</a></li>
+<ul>
+$links
+</ul>
+END
+
+	$links = make_links($od,1,@d);
+        my $idx = '';
+	$idx .= <<END;
+<li>$od</li>
+<ul>
+$links
+</ul>
+END
+        make_page("$outdir/$od/index.html", $od, $idx);
+    }
+}
+
+make_page("$outdir/index.html", "", $top);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6a-0008FE-05; Fri, 25 Nov 2011 14:50:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6X-0008DG-UN
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!6
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14021 invoked from network); 25 Nov 2011 14:49:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874330"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:44 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqC030497;	Fri, 25 Nov 2011 06:49:43 -0800
MIME-Version: 1.0
X-Mercurial-Node: 00ea49f77bdcef16251e3773c99fc02394524b83
Message-ID: <00ea49f77bdcef16251e.1322232583@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:43 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 11 of 15 v2] docs: generate an index for the
	html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322231661 0
# Node ID 00ea49f77bdcef16251e3773c99fc02394524b83
# Parent  ddeac8b237e4f71d05c817fa8432417886e7e202
docs: generate an index for the html output

nb: I'm not a Perl wizard...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ddeac8b237e4 -r 00ea49f77bdc docs/INDEX
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/INDEX	Fri Nov 25 14:34:21 2011 +0000
@@ -0,0 +1,5 @@
+misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
+
+# These are not all that useful anymore, hide them from the index
+interface/index			NO-INDEX
+user/index			NO-INDEX
diff -r ddeac8b237e4 -r 00ea49f77bdc docs/Makefile
--- a/docs/Makefile	Fri Nov 25 11:53:06 2011 +0000
+++ b/docs/Makefile	Fri Nov 25 14:34:21 2011 +0000
@@ -45,7 +45,7 @@ ps: $(DOC_PS)
 pdf: $(DOC_PDF)
 
 .PHONY: html
-html: $(DOC_HTML)
+html: $(DOC_HTML) html/index.html
 
 .PHONY: txt
 txt: $(DOC_TXT)
@@ -128,6 +128,9 @@ html/%/index.html: src/%.tex
 	$< 1>/dev/null 2>/dev/null ; else \
 	echo "latex2html not installed; skipping $*."; fi
 
+html/index.html: $(DOC_HTML) ./gen-html-index INDEX
+	./gen-html-index -i INDEX html $(DOC_HTML)
+
 html/%.html: %.markdown
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \
diff -r ddeac8b237e4 -r 00ea49f77bdc docs/gen-html-index
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/gen-html-index	Fri Nov 25 14:34:21 2011 +0000
@@ -0,0 +1,136 @@
+#!/usr/bin/perl -w
+
+#
+# Generate indexes for html documentation
+#
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+use IO::File;
+use File::Basename;
+use List::MoreUtils qw/ uniq /;
+
+Getopt::Long::Configure('bundling');
+
+@ARGV >= 2 or die;
+
+our @docs;
+our @dirs;
+our %index;
+
+our $outdir;
+
+GetOptions("i=s" => sub { read_index(@_);} )
+    or die;
+
+($outdir,@docs) = @ARGV;
+
+sub write_file ($$) {
+    my ($opath, $odata) = @_;
+    print STDOUT "Writing: $opath\n";
+    my $out = new IO::File "$opath.new", '>' or die "$opath $!";
+    print $out $odata or die $!;
+    rename "$opath.new", "$opath" or die "$opath $!";
+}
+
+sub make_page ($$$) {
+    my ($file,$title,$content) = @_;
+    my $o = '';
+    my $h1;
+    if ( $title eq "" )
+    {
+        $title = $h1 = "Xen Documentation";
+    }
+    else
+    {
+        $h1 = "<a href=\"../index.(?:html|txt)\">Xen Documentation</a> - $title";
+        $title = "Xen Documentation - $title";
+    }
+    $o .= <<END;
+<html><head><title>$title</title></head>
+<body>
+<h1>$h1</h1>
+<ul>
+$content
+</ul>
+</body></html>
+END
+    write_file($file, $o);
+}
+
+sub make_linktext ($) {
+    my ($l) = @_;
+    return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
+    $l =~ s/.(html)$//g;
+    return $index{$l} if exists $index{$l};
+    return basename($l);
+}
+
+sub make_link ($$) {
+    my ($ref,$base) = @_;
+
+    my $txt = make_linktext($ref);
+    $ref = basename($ref) if $base;
+
+    return "<li><a href=\"$ref\">$txt</a></li>\n";
+}
+
+sub make_links ($$@) {
+    my ($dir,$base,@docs) = @_;
+    my $idx = '';
+    foreach my $of (sort { $a cmp $b } @docs) {
+        $idx .= make_link($of,$base);
+    }
+    return $idx;
+}
+
+sub read_index ($$) {
+    my ($opt, $val) = @_;
+    my $idx = new IO::File "$val", '<' or die "$val $!";
+    while ($_ = $idx->getline()) {
+	s/^\s+//;
+	s/\s+$//;
+	next if m/^\#/;
+	next unless m/\S/;
+	m/^(\S+)\s+(\S.*)$/ or die;
+        $index{$1} = $2;
+    }
+}
+
+for (@docs) { s,^\Q$outdir\E/,, }
+
+@docs = grep { -e "$outdir/$_" && (make_linktext($_) ne "NO-INDEX") } @docs;
+
+my $top = '';
+
+foreach my $od (sort { $a cmp $b } uniq map { dirname($_) } @docs) {
+    my @d = (grep /^\Q$od\E/, @docs);
+    if ( @d == 1 and $d[0] eq "$od/index.html" )
+    {
+        $top .= "<li><a href=\"${od}/index.html\">${od}/index.html</a></li>\n";
+    }
+    else
+    {
+	my $links = make_links($od,0,@d);
+	$top .= <<END;
+<li><a href=\"${od}/index.html\">$od</a></li>
+<ul>
+$links
+</ul>
+END
+
+	$links = make_links($od,1,@d);
+        my $idx = '';
+	$idx .= <<END;
+<li>$od</li>
+<ul>
+$links
+</ul>
+END
+        make_page("$outdir/$od/index.html", $od, $idx);
+    }
+}
+
+make_page("$outdir/index.html", "", $top);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6R-0008Cv-FM; Fri, 25 Nov 2011 14:50:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6Q-0008Ci-3l
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13363 invoked from network); 25 Nov 2011 14:49:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874319"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:35 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq2030497;	Fri, 25 Nov 2011 06:49:34 -0800
MIME-Version: 1.0
X-Mercurial-Node: 732154549538fe983a8cc6ea74605e04e8ea0a64
Message-ID: <732154549538fe983a8c.1322232573@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:33 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 01 of 15 v2] Replace references to old wiki with
	ones to new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221956 0
# Node ID 732154549538fe983a8cc6ea74605e04e8ea0a64
# Parent  1027e7d13d02143048c7d48d7960967c5b1657a8
Replace references to old wiki with ones to new.

I have confirmed that the relevant pages have been transitioned.

What remains is pages which have not yet been moved over:

$ rgrep xenwiki *
docs/misc/xenstore.txt:	See http://wiki.xensource.com/xenwiki/XenBus section
tools/libxen/README:http://wiki.xensource.com/xenwiki/XenApi
tools/xenballoon/xenballoond.README:http://wiki.xensource.com/xenwiki/Open_Topics_For_Discussion?action=AttachFile&do=get&target=Memory+Overcommit.pdf

Note that "PythonInXlConfig" never existed in the old wiki and does not exist
in the new. This reference was introduced by 22735:cb94dbe20f97 and was
supposed to have been written prior to the 4.1 release. I have transitioned it
anyway but it's not clear how valuable the message actually is. Perhaps we
should just remove that aspect of it?

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1027e7d13d02 -r 732154549538 README
--- a/README	Sun Nov 20 18:26:16 2011 +0100
+++ b/README	Fri Nov 25 11:52:36 2011 +0000
@@ -61,10 +61,10 @@ provided by your OS distributor:
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
 no suitable kernel is available from your OS distributor then refer to
-http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
+http://wiki.xen.org/wiki/XenDom0Kernels for suggestions for
 suitable kernels to use.
 If you are looking to compile a Dom0 kernel from source, please refer to
-http://wiki.xensource.com/xenwiki/XenParavirtOps.
+http://wiki.xensource.com/wiki/XenParavirtOps.
 
 [NB. Unless noted otherwise, all the following steps should be
 performed with root privileges.]
diff -r 1027e7d13d02 -r 732154549538 docs/misc/vtd.txt
--- a/docs/misc/vtd.txt	Sun Nov 20 18:26:16 2011 +0100
+++ b/docs/misc/vtd.txt	Fri Nov 25 11:52:36 2011 +0000
@@ -184,7 +184,7 @@ http://www.dell.com/content/products/cat
 - HP Compaq:  DC7800
 http://h10010.www1.hp.com/wwpc/us/en/en/WF04a/12454-12454-64287-321860-3328898.html
 
-For more information, pls refer to http://wiki.xensource.com/xenwiki/VTdHowTo.
+For more information, pls refer to http://wiki.xensource.com/wiki/VTdHowTo.
 
 
 Assigning devices to HVM domains
diff -r 1027e7d13d02 -r 732154549538 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Sun Nov 20 18:26:16 2011 +0100
+++ b/docs/misc/xl-network-configuration.markdown	Fri Nov 25 11:52:36 2011 +0000
@@ -123,4 +123,4 @@ defaults to domain 0. Specifying another
 driver domain which is outside the scope of this document.
 
 [oui]: http://en.wikipedia.org/wiki/Organizationally_Unique_Identifier
-[net]: http://wiki.xen.org/xenwiki/HostConfiguration/Networking
+[net]: http://wiki.xen.org/wiki/HostConfiguration/Networking
diff -r 1027e7d13d02 -r 732154549538 docs/src/interface.tex
--- a/docs/src/interface.tex	Sun Nov 20 18:26:16 2011 +0100
+++ b/docs/src/interface.tex	Fri Nov 25 11:52:36 2011 +0000
@@ -1579,7 +1579,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xensource.com/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r 1027e7d13d02 -r 732154549538 docs/src/user.tex
--- a/docs/src/user.tex	Sun Nov 20 18:26:16 2011 +0100
+++ b/docs/src/user.tex	Fri Nov 25 11:52:36 2011 +0000
@@ -2349,7 +2349,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xensource.com/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r 1027e7d13d02 -r 732154549538 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Sun Nov 20 18:26:16 2011 +0100
+++ b/tools/libxl/libxlu_cfg.c	Fri Nov 25 11:52:36 2011 +0000
@@ -72,7 +72,7 @@ static void parse(CfgParseContext *ctx) 
         fputs(
  "warning: Config file looks like it contains Python code.\n"
  "warning:  Arbitrary Python is no longer supported.\n"
- "warning:  See http://wiki.xen.org/xenwiki/PythonInXlConfig\n",
+ "warning:  See http://wiki.xen.org/wiki/PythonInXlConfig\n",
               ctx->cfg->report);
     }
 }
diff -r 1027e7d13d02 -r 732154549538 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Sun Nov 20 18:26:16 2011 +0100
+++ b/xen/common/sched_credit2.c	Fri Nov 25 11:52:36 2011 +0000
@@ -51,7 +51,7 @@
 /*
  * WARNING: This is still in an experimental phase.  Status and work can be found at the
  * credit2 wiki page:
- *  http://wiki.xensource.com/xenwiki/Credit2_Scheduler_Development
+ *  http://wiki.xensource.com/wiki/Credit2_Scheduler_Development
  * TODO:
  * + Immediate bug-fixes
  *  - Do per-runqueue, grab proper lock for dump debugkey

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6R-0008Cv-FM; Fri, 25 Nov 2011 14:50:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6Q-0008Ci-3l
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13363 invoked from network); 25 Nov 2011 14:49:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874319"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:35 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq2030497;	Fri, 25 Nov 2011 06:49:34 -0800
MIME-Version: 1.0
X-Mercurial-Node: 732154549538fe983a8cc6ea74605e04e8ea0a64
Message-ID: <732154549538fe983a8c.1322232573@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:33 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 01 of 15 v2] Replace references to old wiki with
	ones to new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221956 0
# Node ID 732154549538fe983a8cc6ea74605e04e8ea0a64
# Parent  1027e7d13d02143048c7d48d7960967c5b1657a8
Replace references to old wiki with ones to new.

I have confirmed that the relevant pages have been transitioned.

What remains is pages which have not yet been moved over:

$ rgrep xenwiki *
docs/misc/xenstore.txt:	See http://wiki.xensource.com/xenwiki/XenBus section
tools/libxen/README:http://wiki.xensource.com/xenwiki/XenApi
tools/xenballoon/xenballoond.README:http://wiki.xensource.com/xenwiki/Open_Topics_For_Discussion?action=AttachFile&do=get&target=Memory+Overcommit.pdf

Note that "PythonInXlConfig" never existed in the old wiki and does not exist
in the new. This reference was introduced by 22735:cb94dbe20f97 and was
supposed to have been written prior to the 4.1 release. I have transitioned it
anyway but it's not clear how valuable the message actually is. Perhaps we
should just remove that aspect of it?

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1027e7d13d02 -r 732154549538 README
--- a/README	Sun Nov 20 18:26:16 2011 +0100
+++ b/README	Fri Nov 25 11:52:36 2011 +0000
@@ -61,10 +61,10 @@ provided by your OS distributor:
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
 no suitable kernel is available from your OS distributor then refer to
-http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
+http://wiki.xen.org/wiki/XenDom0Kernels for suggestions for
 suitable kernels to use.
 If you are looking to compile a Dom0 kernel from source, please refer to
-http://wiki.xensource.com/xenwiki/XenParavirtOps.
+http://wiki.xensource.com/wiki/XenParavirtOps.
 
 [NB. Unless noted otherwise, all the following steps should be
 performed with root privileges.]
diff -r 1027e7d13d02 -r 732154549538 docs/misc/vtd.txt
--- a/docs/misc/vtd.txt	Sun Nov 20 18:26:16 2011 +0100
+++ b/docs/misc/vtd.txt	Fri Nov 25 11:52:36 2011 +0000
@@ -184,7 +184,7 @@ http://www.dell.com/content/products/cat
 - HP Compaq:  DC7800
 http://h10010.www1.hp.com/wwpc/us/en/en/WF04a/12454-12454-64287-321860-3328898.html
 
-For more information, pls refer to http://wiki.xensource.com/xenwiki/VTdHowTo.
+For more information, pls refer to http://wiki.xensource.com/wiki/VTdHowTo.
 
 
 Assigning devices to HVM domains
diff -r 1027e7d13d02 -r 732154549538 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Sun Nov 20 18:26:16 2011 +0100
+++ b/docs/misc/xl-network-configuration.markdown	Fri Nov 25 11:52:36 2011 +0000
@@ -123,4 +123,4 @@ defaults to domain 0. Specifying another
 driver domain which is outside the scope of this document.
 
 [oui]: http://en.wikipedia.org/wiki/Organizationally_Unique_Identifier
-[net]: http://wiki.xen.org/xenwiki/HostConfiguration/Networking
+[net]: http://wiki.xen.org/wiki/HostConfiguration/Networking
diff -r 1027e7d13d02 -r 732154549538 docs/src/interface.tex
--- a/docs/src/interface.tex	Sun Nov 20 18:26:16 2011 +0100
+++ b/docs/src/interface.tex	Fri Nov 25 11:52:36 2011 +0000
@@ -1579,7 +1579,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xensource.com/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r 1027e7d13d02 -r 732154549538 docs/src/user.tex
--- a/docs/src/user.tex	Sun Nov 20 18:26:16 2011 +0100
+++ b/docs/src/user.tex	Fri Nov 25 11:52:36 2011 +0000
@@ -2349,7 +2349,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xensource.com/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r 1027e7d13d02 -r 732154549538 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Sun Nov 20 18:26:16 2011 +0100
+++ b/tools/libxl/libxlu_cfg.c	Fri Nov 25 11:52:36 2011 +0000
@@ -72,7 +72,7 @@ static void parse(CfgParseContext *ctx) 
         fputs(
  "warning: Config file looks like it contains Python code.\n"
  "warning:  Arbitrary Python is no longer supported.\n"
- "warning:  See http://wiki.xen.org/xenwiki/PythonInXlConfig\n",
+ "warning:  See http://wiki.xen.org/wiki/PythonInXlConfig\n",
               ctx->cfg->report);
     }
 }
diff -r 1027e7d13d02 -r 732154549538 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Sun Nov 20 18:26:16 2011 +0100
+++ b/xen/common/sched_credit2.c	Fri Nov 25 11:52:36 2011 +0000
@@ -51,7 +51,7 @@
 /*
  * WARNING: This is still in an experimental phase.  Status and work can be found at the
  * credit2 wiki page:
- *  http://wiki.xensource.com/xenwiki/Credit2_Scheduler_Development
+ *  http://wiki.xensource.com/wiki/Credit2_Scheduler_Development
  * TODO:
  * + Immediate bug-fixes
  *  - Do per-runqueue, grab proper lock for dump debugkey

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6X-0008EJ-3J; Fri, 25 Nov 2011 14:50:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6U-0008Cl-JV
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!4
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13859 invoked from network); 25 Nov 2011 14:49:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874325"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:41 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq8030497;	Fri, 25 Nov 2011 06:49:40 -0800
MIME-Version: 1.0
X-Mercurial-Node: 88eee947a2bd15d4811c664ba6ed345a066708eb
Message-ID: <88eee947a2bd15d4811c.1322232579@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:39 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 07 of 15 v2] xlu: add "dont_warn" to xlu_cfg_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221980 0
# Node ID 88eee947a2bd15d4811c664ba6ed345a066708eb
# Parent  5a4e9f351a8ea57568a4a2dd8a5c4684628c56c9
xlu: add "dont_warn" to xlu_cfg_*

I want it for get_long but we might as well have it everywhere.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 5a4e9f351a8e -r 88eee947a2bd tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Fri Nov 25 11:52:58 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Fri Nov 25 11:53:00 2011 +0000
@@ -165,17 +165,18 @@ static XLU_ConfigSetting *find(const XLU
 }
 
 static int find_atom(const XLU_Config *cfg, const char *n,
-                     XLU_ConfigSetting **set_r) {
+                     XLU_ConfigSetting **set_r, int dont_warn) {
     XLU_ConfigSetting *set;
 
     set= find(cfg,n);
     if (!set) return ESRCH;
 
     if (set->avalues!=1) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is"
-                " a list but should be a single value\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is"
+                    " a list but should be a single value\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *set_r= set;
@@ -183,49 +184,51 @@ static int find_atom(const XLU_Config *c
 }
 
 int xlu_cfg_get_string(const XLU_Config *cfg, const char *n,
-                       const char **value_r) {
+                       const char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     *value_r= set->values[0];
     return 0;
 }
 
 int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
-                           char **value_r) {
+                           char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     free(*value_r);
     *value_r= strdup(set->values[0]);
     return 0;
 }
 
 int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
-                     long *value_r) {
+                     long *value_r, int dont_warn) {
     long l;
     XLU_ConfigSetting *set;
     int e;
     char *ep;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     errno= 0; l= strtol(set->values[0], &ep, 0);
     e= errno;
     if (errno) {
         e= errno;
         assert(e==EINVAL || e==ERANGE);
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' could not be parsed"
-                " as a number: %s\n",
-                cfg->filename, set->lineno, n, strerror(e));
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' could not be parsed"
+                    " as a number: %s\n",
+                    cfg->filename, set->lineno, n, strerror(e));
         return e;
     }
     if (*ep || ep==set->values[0]) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is not a valid number\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is not a valid number\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *value_r= l;
diff -r 5a4e9f351a8e -r 88eee947a2bd tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Fri Nov 25 11:52:58 2011 +0000
+++ b/tools/libxl/libxlutil.h	Fri Nov 25 11:53:00 2011 +0000
@@ -41,13 +41,17 @@ void xlu_cfg_destroy(XLU_Config*);
  * Return values are:
  *   0        OK
  *   ESRCH    not defined
- *   EINVAL   value found but wrong format for request (prints warning)
+ *   EINVAL   value found but wrong format for request (prints warning unless dont_warn=true)
  *   ERANGE   value out of range (from strtol)
  */
 
-int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r);
-int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char **value_r); /* free/strdup version */
-int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r);
+int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r,
+                       int dont_warn);
+/* free/strdup version */
+int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
+                           char **value_r, int dont_warn);
+int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r 5a4e9f351a8e -r 88eee947a2bd tools/libxl/xl.c
--- a/tools/libxl/xl.c	Fri Nov 25 11:52:58 2011 +0000
+++ b/tools/libxl/xl.c	Fri Nov 25 11:53:00 2011 +0000
@@ -62,10 +62,10 @@ static void parse_global_config(const ch
         exit(1);
     }
 
-    if (!xlu_cfg_get_long (config, "autoballoon", &l))
+    if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
-    if (!xlu_cfg_get_string (config, "lockfile", &buf))
+    if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
         e = asprintf(&lockfile, "%s/xl", (char *)libxl_lock_dir_path());
@@ -75,7 +75,7 @@ static void parse_global_config(const ch
         }
     }
 
-    if (!xlu_cfg_get_string (config, "vifscript", &buf))
+    if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
     xlu_cfg_destroy(config);
diff -r 5a4e9f351a8e -r 88eee947a2bd tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:52:58 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:53:00 2011 +0000
@@ -554,7 +554,7 @@ static void parse_config_data(const char
     if (libxl_init_create_info(ctx, c_info))
         exit(1);
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf)) {
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
@@ -568,19 +568,19 @@ static void parse_config_data(const char
     }
 
     c_info->type = LIBXL_DOMAIN_TYPE_PV;
-    if (!xlu_cfg_get_string (config, "builder", &buf) &&
+    if (!xlu_cfg_get_string (config, "builder", &buf, 0) &&
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l))
+    if (!xlu_cfg_get_long (config, "hap", &l, 0))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+    if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.");
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
+    if (!xlu_cfg_get_string (config, "uuid", &buf, 0) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {
             fprintf(stderr, "Failed to parse UUID: %s\n", buf);
             exit(1);
@@ -589,10 +589,10 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l))
+    if (!xlu_cfg_get_long(config, "oos", &l, 0))
         c_info->oos = l;
 
-    if (!xlu_cfg_get_string (config, "pool", &buf)) {
+    if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
@@ -606,37 +606,37 @@ static void parse_config_data(const char
         exit(1);
 
     /* the following is the actual config parsing with overriding values in the structures */
-    if (!xlu_cfg_get_long (config, "vcpus", &l)) {
+    if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;
     }
 
-    if (!xlu_cfg_get_long (config, "maxvcpus", &l))
+    if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus = l;
 
-    if (!xlu_cfg_get_long (config, "memory", &l)) {
+    if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
     }
 
-    if (!xlu_cfg_get_long (config, "maxmem", &l))
+    if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
         b_info->max_memkb = l * 1024;
 
-    if (xlu_cfg_get_string (config, "on_poweroff", &buf))
+    if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_poweroff)) {
         fprintf(stderr, "Unknown on_poweroff action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_reboot", &buf))
+    if (xlu_cfg_get_string (config, "on_reboot", &buf, 0))
         buf = "restart";
     if (!parse_action_on_shutdown(buf, &d_config->on_reboot)) {
         fprintf(stderr, "Unknown on_reboot action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_watchdog", &buf))
+    if (xlu_cfg_get_string (config, "on_watchdog", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_watchdog)) {
         fprintf(stderr, "Unknown on_watchdog action \"%s\" specified\n", buf);
@@ -644,7 +644,7 @@ static void parse_config_data(const char
     }
 
 
-    if (xlu_cfg_get_string (config, "on_crash", &buf))
+    if (xlu_cfg_get_string (config, "on_crash", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_crash)) {
         fprintf(stderr, "Unknown on_crash action \"%s\" specified\n", buf);
@@ -654,52 +654,52 @@ static void parse_config_data(const char
     /* libxl_get_required_shadow_memory() must be called after final values
      * (default or specified) for vcpus and memory are set, because the
      * calculation depends on those values. */
-    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l)
+    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l, 0)
         ? l * 1024
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l))
+    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
         b_info->tsc_mode = l;
 
-    if (!xlu_cfg_get_long (config, "videoram", &l))
+    if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+    if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
         dm_info->gfx_passthru = l;
 
     switch(c_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        if (!xlu_cfg_get_string (config, "kernel", &buf))
+        if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
             fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "
                     "Use \"firmware_override\" instead if you really want a non-default firmware\n");
 
         xlu_cfg_replace_string (config, "firmware_override",
-                                &b_info->u.hvm.firmware);
-        if (!xlu_cfg_get_long (config, "pae", &l))
+                                &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l))
+        if (!xlu_cfg_get_long (config, "apic", &l, 0))
             b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l))
+        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
             b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l, 0))
             b_info->u.hvm.acpi_s3 = l;
-        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l, 0))
             b_info->u.hvm.acpi_s4 = l;
-        if (!xlu_cfg_get_long (config, "nx", &l))
+        if (!xlu_cfg_get_long (config, "nx", &l, 0))
             b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l))
+        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
             b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l))
+        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
             b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l))
+        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
             b_info->u.hvm.vpt_align = l;
-        if (!xlu_cfg_get_long (config, "timer_mode", &l))
+        if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
             b_info->u.hvm.timer_mode = l;
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l))
+        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -707,12 +707,12 @@ static void parse_config_data(const char
         char *cmdline = NULL;
         const char *root = NULL, *extra = "";
 
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_get_string (config, "root", &root);
-        xlu_cfg_get_string (config, "extra", &extra);
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_get_string (config, "root", &root, 0);
+        xlu_cfg_get_string (config, "extra", &extra, 0);
 
         if (root) {
             if (asprintf(&cmdline, "root=%s %s", root, extra) == -1)
@@ -726,8 +726,10 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader);
-        xlu_cfg_replace_string (config, "bootloader_args", &b_info->u.pv.bootloader_args);
+        xlu_cfg_replace_string (config, "bootloader",
+                                &b_info->u.pv.bootloader, 0);
+        xlu_cfg_replace_string (config, "bootloader_args",
+                                &b_info->u.pv.bootloader_args, 0);
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");
@@ -735,7 +737,7 @@ static void parse_config_data(const char
         }
 
         b_info->u.pv.cmdline = cmdline;
-        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path);
+        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path, 0);
         break;
     }
     default:
@@ -910,15 +912,15 @@ skip_vfb:
         }
     }
 
-    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l))
+    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l, 0))
         pci_msitranslate = l;
 
-    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l))
+    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l, 0))
         pci_power_mgmt = l;
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l)) {
+    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
         switch (c_info->type) {
         case LIBXL_DOMAIN_TYPE_HVM:
             fprintf(stderr, "Can't do e820_host in HVM mode!");
@@ -986,7 +988,7 @@ skip_vfb:
         }
         break;
     case EINVAL:    /* config option is not a list, parse as a string */
-        if (!xlu_cfg_get_string(config, "cpuid", &buf)) {
+        if (!xlu_cfg_get_string(config, "cpuid", &buf, 0)) {
             char *buf2, *p, *strtok_ptr = NULL;
             const char *errstr;
 
@@ -1034,7 +1036,7 @@ skip_vfb:
     if (libxl_init_dm_info(ctx, dm_info, c_info, b_info))
         exit(1);
     /* parse device model arguments, this works for pv, hvm and stubdom */
-    if (!xlu_cfg_get_string (config, "device_model", &buf)) {
+    if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) {
         fprintf(stderr,
                 "WARNING: ignoring device_model directive.\n"
                 "WARNING: Use \"device_model_override\" instead if you"
@@ -1053,8 +1055,8 @@ skip_vfb:
 
 
     xlu_cfg_replace_string (config, "device_model_override",
-                            &dm_info->device_model);
-    if (!xlu_cfg_get_string (config, "device_model_version", &buf)) {
+                            &dm_info->device_model, 0);
+    if (!xlu_cfg_get_string (config, "device_model_version", &buf, 0)) {
         if (!strcmp(buf, "qemu-xen-traditional")) {
             dm_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
@@ -1068,7 +1070,7 @@ skip_vfb:
         }
     } else if (dm_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l))
+    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
 #define parse_extra_args(type)                                          \
@@ -1096,46 +1098,46 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l))
+        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
             dm_info->stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l))
+        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
             dm_info->vnc = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd);
-        if (!xlu_cfg_get_long (config, "vncdisplay", &l))
+        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd, 0);
+        if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             dm_info->vncdisplay = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l))
+        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
             dm_info->vncunused = l;
-        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap);
-        if (!xlu_cfg_get_long (config, "sdl", &l))
+        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
+        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l))
+        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
             dm_info->opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l))
+        if (!xlu_cfg_get_long (config, "spice", &l, 0))
             dm_info->spice = l;
-        if (!xlu_cfg_get_long (config, "spiceport", &l))
+        if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             dm_info->spiceport = l;
-        if (!xlu_cfg_get_long (config, "spicetls_port", &l))
+        if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             dm_info->spicetls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l))
+        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost, 0);
+        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
             dm_info->spicedisable_ticketing = l;
-        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l))
+        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd, 0);
+        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
             dm_info->spiceagent_mouse = l;
         else
             dm_info->spiceagent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l))
+        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             dm_info->nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
-        xlu_cfg_replace_string (config, "serial", &dm_info->serial);
-        xlu_cfg_replace_string (config, "boot", &dm_info->boot);
-        if (!xlu_cfg_get_long (config, "usb", &l))
+        xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);
+        xlu_cfg_replace_string (config, "boot", &dm_info->boot, 0);
+        if (!xlu_cfg_get_long (config, "usb", &l, 0))
             dm_info->usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice);
-        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l))
+        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice, 0);
+        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
+        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
             dm_info->xen_platform_pci = l;
     }
 
@@ -4765,7 +4767,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "name", &buf))
+    if (!xlu_cfg_get_string (config, "name", &buf, 0))
         name = strdup(buf);
     else
         name = libxl_basename(filename);
@@ -4774,7 +4776,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "sched", &buf)) {
+    if (!xlu_cfg_get_string (config, "sched", &buf, 0)) {
         if ((schedid = libxl_name_to_schedid(ctx, buf)) < 0) {
             fprintf(stderr, "Unknown scheduler\n");
             return -ERROR_FAIL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6X-0008EJ-3J; Fri, 25 Nov 2011 14:50:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6U-0008Cl-JV
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!4
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13859 invoked from network); 25 Nov 2011 14:49:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874325"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:41 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq8030497;	Fri, 25 Nov 2011 06:49:40 -0800
MIME-Version: 1.0
X-Mercurial-Node: 88eee947a2bd15d4811c664ba6ed345a066708eb
Message-ID: <88eee947a2bd15d4811c.1322232579@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:39 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 07 of 15 v2] xlu: add "dont_warn" to xlu_cfg_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221980 0
# Node ID 88eee947a2bd15d4811c664ba6ed345a066708eb
# Parent  5a4e9f351a8ea57568a4a2dd8a5c4684628c56c9
xlu: add "dont_warn" to xlu_cfg_*

I want it for get_long but we might as well have it everywhere.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 5a4e9f351a8e -r 88eee947a2bd tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Fri Nov 25 11:52:58 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Fri Nov 25 11:53:00 2011 +0000
@@ -165,17 +165,18 @@ static XLU_ConfigSetting *find(const XLU
 }
 
 static int find_atom(const XLU_Config *cfg, const char *n,
-                     XLU_ConfigSetting **set_r) {
+                     XLU_ConfigSetting **set_r, int dont_warn) {
     XLU_ConfigSetting *set;
 
     set= find(cfg,n);
     if (!set) return ESRCH;
 
     if (set->avalues!=1) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is"
-                " a list but should be a single value\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is"
+                    " a list but should be a single value\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *set_r= set;
@@ -183,49 +184,51 @@ static int find_atom(const XLU_Config *c
 }
 
 int xlu_cfg_get_string(const XLU_Config *cfg, const char *n,
-                       const char **value_r) {
+                       const char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     *value_r= set->values[0];
     return 0;
 }
 
 int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
-                           char **value_r) {
+                           char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     free(*value_r);
     *value_r= strdup(set->values[0]);
     return 0;
 }
 
 int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
-                     long *value_r) {
+                     long *value_r, int dont_warn) {
     long l;
     XLU_ConfigSetting *set;
     int e;
     char *ep;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     errno= 0; l= strtol(set->values[0], &ep, 0);
     e= errno;
     if (errno) {
         e= errno;
         assert(e==EINVAL || e==ERANGE);
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' could not be parsed"
-                " as a number: %s\n",
-                cfg->filename, set->lineno, n, strerror(e));
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' could not be parsed"
+                    " as a number: %s\n",
+                    cfg->filename, set->lineno, n, strerror(e));
         return e;
     }
     if (*ep || ep==set->values[0]) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is not a valid number\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is not a valid number\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *value_r= l;
diff -r 5a4e9f351a8e -r 88eee947a2bd tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Fri Nov 25 11:52:58 2011 +0000
+++ b/tools/libxl/libxlutil.h	Fri Nov 25 11:53:00 2011 +0000
@@ -41,13 +41,17 @@ void xlu_cfg_destroy(XLU_Config*);
  * Return values are:
  *   0        OK
  *   ESRCH    not defined
- *   EINVAL   value found but wrong format for request (prints warning)
+ *   EINVAL   value found but wrong format for request (prints warning unless dont_warn=true)
  *   ERANGE   value out of range (from strtol)
  */
 
-int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r);
-int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char **value_r); /* free/strdup version */
-int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r);
+int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r,
+                       int dont_warn);
+/* free/strdup version */
+int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
+                           char **value_r, int dont_warn);
+int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r 5a4e9f351a8e -r 88eee947a2bd tools/libxl/xl.c
--- a/tools/libxl/xl.c	Fri Nov 25 11:52:58 2011 +0000
+++ b/tools/libxl/xl.c	Fri Nov 25 11:53:00 2011 +0000
@@ -62,10 +62,10 @@ static void parse_global_config(const ch
         exit(1);
     }
 
-    if (!xlu_cfg_get_long (config, "autoballoon", &l))
+    if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
-    if (!xlu_cfg_get_string (config, "lockfile", &buf))
+    if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
         e = asprintf(&lockfile, "%s/xl", (char *)libxl_lock_dir_path());
@@ -75,7 +75,7 @@ static void parse_global_config(const ch
         }
     }
 
-    if (!xlu_cfg_get_string (config, "vifscript", &buf))
+    if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
     xlu_cfg_destroy(config);
diff -r 5a4e9f351a8e -r 88eee947a2bd tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:52:58 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:53:00 2011 +0000
@@ -554,7 +554,7 @@ static void parse_config_data(const char
     if (libxl_init_create_info(ctx, c_info))
         exit(1);
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf)) {
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
@@ -568,19 +568,19 @@ static void parse_config_data(const char
     }
 
     c_info->type = LIBXL_DOMAIN_TYPE_PV;
-    if (!xlu_cfg_get_string (config, "builder", &buf) &&
+    if (!xlu_cfg_get_string (config, "builder", &buf, 0) &&
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l))
+    if (!xlu_cfg_get_long (config, "hap", &l, 0))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+    if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.");
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
+    if (!xlu_cfg_get_string (config, "uuid", &buf, 0) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {
             fprintf(stderr, "Failed to parse UUID: %s\n", buf);
             exit(1);
@@ -589,10 +589,10 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l))
+    if (!xlu_cfg_get_long(config, "oos", &l, 0))
         c_info->oos = l;
 
-    if (!xlu_cfg_get_string (config, "pool", &buf)) {
+    if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
@@ -606,37 +606,37 @@ static void parse_config_data(const char
         exit(1);
 
     /* the following is the actual config parsing with overriding values in the structures */
-    if (!xlu_cfg_get_long (config, "vcpus", &l)) {
+    if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;
     }
 
-    if (!xlu_cfg_get_long (config, "maxvcpus", &l))
+    if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus = l;
 
-    if (!xlu_cfg_get_long (config, "memory", &l)) {
+    if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
     }
 
-    if (!xlu_cfg_get_long (config, "maxmem", &l))
+    if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
         b_info->max_memkb = l * 1024;
 
-    if (xlu_cfg_get_string (config, "on_poweroff", &buf))
+    if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_poweroff)) {
         fprintf(stderr, "Unknown on_poweroff action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_reboot", &buf))
+    if (xlu_cfg_get_string (config, "on_reboot", &buf, 0))
         buf = "restart";
     if (!parse_action_on_shutdown(buf, &d_config->on_reboot)) {
         fprintf(stderr, "Unknown on_reboot action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_watchdog", &buf))
+    if (xlu_cfg_get_string (config, "on_watchdog", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_watchdog)) {
         fprintf(stderr, "Unknown on_watchdog action \"%s\" specified\n", buf);
@@ -644,7 +644,7 @@ static void parse_config_data(const char
     }
 
 
-    if (xlu_cfg_get_string (config, "on_crash", &buf))
+    if (xlu_cfg_get_string (config, "on_crash", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_crash)) {
         fprintf(stderr, "Unknown on_crash action \"%s\" specified\n", buf);
@@ -654,52 +654,52 @@ static void parse_config_data(const char
     /* libxl_get_required_shadow_memory() must be called after final values
      * (default or specified) for vcpus and memory are set, because the
      * calculation depends on those values. */
-    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l)
+    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l, 0)
         ? l * 1024
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l))
+    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
         b_info->tsc_mode = l;
 
-    if (!xlu_cfg_get_long (config, "videoram", &l))
+    if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+    if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
         dm_info->gfx_passthru = l;
 
     switch(c_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        if (!xlu_cfg_get_string (config, "kernel", &buf))
+        if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
             fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "
                     "Use \"firmware_override\" instead if you really want a non-default firmware\n");
 
         xlu_cfg_replace_string (config, "firmware_override",
-                                &b_info->u.hvm.firmware);
-        if (!xlu_cfg_get_long (config, "pae", &l))
+                                &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l))
+        if (!xlu_cfg_get_long (config, "apic", &l, 0))
             b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l))
+        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
             b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l, 0))
             b_info->u.hvm.acpi_s3 = l;
-        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l, 0))
             b_info->u.hvm.acpi_s4 = l;
-        if (!xlu_cfg_get_long (config, "nx", &l))
+        if (!xlu_cfg_get_long (config, "nx", &l, 0))
             b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l))
+        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
             b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l))
+        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
             b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l))
+        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
             b_info->u.hvm.vpt_align = l;
-        if (!xlu_cfg_get_long (config, "timer_mode", &l))
+        if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
             b_info->u.hvm.timer_mode = l;
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l))
+        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -707,12 +707,12 @@ static void parse_config_data(const char
         char *cmdline = NULL;
         const char *root = NULL, *extra = "";
 
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_get_string (config, "root", &root);
-        xlu_cfg_get_string (config, "extra", &extra);
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_get_string (config, "root", &root, 0);
+        xlu_cfg_get_string (config, "extra", &extra, 0);
 
         if (root) {
             if (asprintf(&cmdline, "root=%s %s", root, extra) == -1)
@@ -726,8 +726,10 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader);
-        xlu_cfg_replace_string (config, "bootloader_args", &b_info->u.pv.bootloader_args);
+        xlu_cfg_replace_string (config, "bootloader",
+                                &b_info->u.pv.bootloader, 0);
+        xlu_cfg_replace_string (config, "bootloader_args",
+                                &b_info->u.pv.bootloader_args, 0);
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");
@@ -735,7 +737,7 @@ static void parse_config_data(const char
         }
 
         b_info->u.pv.cmdline = cmdline;
-        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path);
+        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path, 0);
         break;
     }
     default:
@@ -910,15 +912,15 @@ skip_vfb:
         }
     }
 
-    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l))
+    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l, 0))
         pci_msitranslate = l;
 
-    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l))
+    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l, 0))
         pci_power_mgmt = l;
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l)) {
+    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
         switch (c_info->type) {
         case LIBXL_DOMAIN_TYPE_HVM:
             fprintf(stderr, "Can't do e820_host in HVM mode!");
@@ -986,7 +988,7 @@ skip_vfb:
         }
         break;
     case EINVAL:    /* config option is not a list, parse as a string */
-        if (!xlu_cfg_get_string(config, "cpuid", &buf)) {
+        if (!xlu_cfg_get_string(config, "cpuid", &buf, 0)) {
             char *buf2, *p, *strtok_ptr = NULL;
             const char *errstr;
 
@@ -1034,7 +1036,7 @@ skip_vfb:
     if (libxl_init_dm_info(ctx, dm_info, c_info, b_info))
         exit(1);
     /* parse device model arguments, this works for pv, hvm and stubdom */
-    if (!xlu_cfg_get_string (config, "device_model", &buf)) {
+    if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) {
         fprintf(stderr,
                 "WARNING: ignoring device_model directive.\n"
                 "WARNING: Use \"device_model_override\" instead if you"
@@ -1053,8 +1055,8 @@ skip_vfb:
 
 
     xlu_cfg_replace_string (config, "device_model_override",
-                            &dm_info->device_model);
-    if (!xlu_cfg_get_string (config, "device_model_version", &buf)) {
+                            &dm_info->device_model, 0);
+    if (!xlu_cfg_get_string (config, "device_model_version", &buf, 0)) {
         if (!strcmp(buf, "qemu-xen-traditional")) {
             dm_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
@@ -1068,7 +1070,7 @@ skip_vfb:
         }
     } else if (dm_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l))
+    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
 #define parse_extra_args(type)                                          \
@@ -1096,46 +1098,46 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l))
+        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
             dm_info->stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l))
+        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
             dm_info->vnc = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd);
-        if (!xlu_cfg_get_long (config, "vncdisplay", &l))
+        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd, 0);
+        if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             dm_info->vncdisplay = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l))
+        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
             dm_info->vncunused = l;
-        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap);
-        if (!xlu_cfg_get_long (config, "sdl", &l))
+        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
+        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l))
+        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
             dm_info->opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l))
+        if (!xlu_cfg_get_long (config, "spice", &l, 0))
             dm_info->spice = l;
-        if (!xlu_cfg_get_long (config, "spiceport", &l))
+        if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             dm_info->spiceport = l;
-        if (!xlu_cfg_get_long (config, "spicetls_port", &l))
+        if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             dm_info->spicetls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l))
+        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost, 0);
+        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
             dm_info->spicedisable_ticketing = l;
-        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l))
+        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd, 0);
+        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
             dm_info->spiceagent_mouse = l;
         else
             dm_info->spiceagent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l))
+        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             dm_info->nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
-        xlu_cfg_replace_string (config, "serial", &dm_info->serial);
-        xlu_cfg_replace_string (config, "boot", &dm_info->boot);
-        if (!xlu_cfg_get_long (config, "usb", &l))
+        xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);
+        xlu_cfg_replace_string (config, "boot", &dm_info->boot, 0);
+        if (!xlu_cfg_get_long (config, "usb", &l, 0))
             dm_info->usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice);
-        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l))
+        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice, 0);
+        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
+        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
             dm_info->xen_platform_pci = l;
     }
 
@@ -4765,7 +4767,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "name", &buf))
+    if (!xlu_cfg_get_string (config, "name", &buf, 0))
         name = strdup(buf);
     else
         name = libxl_basename(filename);
@@ -4774,7 +4776,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "sched", &buf)) {
+    if (!xlu_cfg_get_string (config, "sched", &buf, 0)) {
         if ((schedid = libxl_name_to_schedid(ctx, buf)) < 0) {
             fprintf(stderr, "Unknown scheduler\n");
             return -ERROR_FAIL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6X-0008EV-He; Fri, 25 Nov 2011 14:50:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6V-0008Cq-Ud
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!5
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13942 invoked from network); 25 Nov 2011 14:49:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874329"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:42 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqA030497;	Fri, 25 Nov 2011 06:49:41 -0800
MIME-Version: 1.0
X-Mercurial-Node: bf4b5ef1f1d16189cb1a628ec8445a8018c96be5
Message-ID: <bf4b5ef1f1d16189cb1a.1322232581@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:41 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 09 of 15 v2] docs: remove non-breaking spaces
 from sedf_scheduler_mini-HOWTO.txt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0925039666670693276=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0925039666670693276==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221984 0
# Node ID bf4b5ef1f1d16189cb1a628ec8445a8018c96be5
# Parent  b0009f28bbf2ec313eead3ed36a2b139fa5f3512
docs: remove non-breaking spaces from sedf_scheduler_mini-HOWTO.txt

This document contains several 0xa0 characters (non-breaking spaces). These do
not display correctly in (some) terminals or when the document is rendered by (some)
browsers. Re-encode them as spaces.

I'm not confident that this change will make it through being encoded as a patch
and sent through email. Its effect can be replicated with:

	perl -i -p -e 's/\xa0/ /g' docs/misc/sedf_scheduler_mini-HOWTO.txt

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b0009f28bbf2 -r bf4b5ef1f1d1 docs/misc/sedf_scheduler_mini-HOWTO.txt
--- a/docs/misc/sedf_scheduler_mini-HOWTO.txt	Fri Nov 25 11:53:02 2011 +0000
+++ b/docs/misc/sedf_scheduler_mini-HOWTO.txt	Fri Nov 25 11:53:04 2011 +0000
@@ -8,37 +8,37 @@ Overview:
   uses realtime-algorithms to ensure time guarantees.
 
 Usage:
-   -add "sched=sedf" on Xen's boot command-line
-   -create domains as usual
-   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
-    Where:
-      -period/slice are the normal EDF scheduling parameters in nanosecs
-      -latency-hint is the scaled period in case the domain is doing heavy I/O
+   -add "sched=sedf" on Xen's boot command-line
+   -create domains as usual
+   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
+    Where:
+      -period/slice are the normal EDF scheduling parameters in nanosecs
+      -latency-hint is the scaled period in case the domain is doing heavy I/O
          (unused by the currently compiled version)
-      -extra is a flag (0/1), which controls whether the domain can run in
+      -extra is a flag (0/1), which controls whether the domain can run in
        extra-time
-      -weight is mutually exclusive with period/slice and specifies another
+      -weight is mutually exclusive with period/slice and specifies another
        way of setting a domains cpu slice
 
 Examples:
- normal EDF (20ms/5ms):
-  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
+ normal EDF (20ms/5ms):
+  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
   
- best-effort domains (i.e. non-realtime):
-  xm sched-sedf <dom-id> 20000000 0 0 1 0
- 
+ best-effort domains (i.e. non-realtime):
+  xm sched-sedf <dom-id> 20000000 0 0 1 0
+ 
  normal EDF (20ms/5ms) + share of extra-time:
-  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
+  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
   
- 4 domains with weights 2:3:4:2
-  xm sched-sedf <d1> 0 0 0 0 2
-  xm sched-sedf <d2> 0 0 0 0 3
-  xm sched-sedf <d3> 0 0 0 0 4
-  xm sched-sedf <d4> 0 0 0 0 2
+ 4 domains with weights 2:3:4:2
+  xm sched-sedf <d1> 0 0 0 0 2
+  xm sched-sedf <d2> 0 0 0 0 3
+  xm sched-sedf <d3> 0 0 0 0 4
+  xm sched-sedf <d4> 0 0 0 0 2
   
- 1 fully-specified (10ms/3ms) domain, 3 other domains share
- available rest in 2:7:3 ratio:
-  xm sched-sedf <d1> 10000000 3000000 0 0 0
-  xm sched-sedf <d2> 0 0 0 0 2
-  xm sched-sedf <d3> 0 0 0 0 7
-  xm sched-sedf <d4> 0 0 0 0 3
+ 1 fully-specified (10ms/3ms) domain, 3 other domains share
+ available rest in 2:7:3 ratio:
+  xm sched-sedf <d1> 10000000 3000000 0 0 0
+  xm sched-sedf <d2> 0 0 0 0 2
+  xm sched-sedf <d3> 0 0 0 0 7
+  xm sched-sedf <d4> 0 0 0 0 3


--===============0925039666670693276==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0925039666670693276==--

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6R-0008D2-TB; Fri, 25 Nov 2011 14:50:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6R-0008Cj-3T
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13435 invoked from network); 25 Nov 2011 14:49:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874321"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:37 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq4030497;	Fri, 25 Nov 2011 06:49:36 -0800
MIME-Version: 1.0
X-Mercurial-Node: 224340062d194a2ef551402cdf79ecd92c34d8f3
Message-ID: <224340062d194a2ef551.1322232575@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:35 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 03 of 15 v2] README: add markdown to dependency
	list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221966 0
# Node ID 224340062d194a2ef551402cdf79ecd92c34d8f3
# Parent  6d7ef8b8a5631f6324b14468ea0f458918f4ad77
README: add markdown to dependency list

although this tool is strictly speaking optional we are providing various user
docs in this format so increase the changes that they will install it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 6d7ef8b8a563 -r 224340062d19 README
--- a/README	Fri Nov 25 11:52:43 2011 +0000
+++ b/README	Fri Nov 25 11:52:46 2011 +0000
@@ -57,6 +57,7 @@ provided by your OS distributor:
     * GNU gettext
     * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
     * ACPI ASL compiler (iasl)
+    * markdown
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6b-0008G0-KG; Fri, 25 Nov 2011 14:50:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6Z-0008DR-IS
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!7
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14123 invoked from network); 25 Nov 2011 14:49:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:47 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874336"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:46 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqE030497;	Fri, 25 Nov 2011 06:49:45 -0800
MIME-Version: 1.0
X-Mercurial-Node: 5ce5f2cdb7be8faed396b62ce26b4ad8669db0bf
Message-ID: <5ce5f2cdb7be8faed396.1322232585@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:45 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 13 of 15 v2] libxlu: add
	xlu_cfg_get_list_as_string_list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322231691 0
# Node ID 5ce5f2cdb7be8faed396b62ce26b4ad8669db0bf
# Parent  9e98f587da45fced29dc9c317f403f53e3fec904
libxlu: add xlu_cfg_get_list_as_string_list

Returns a cfg list as a libxl_string_list.

Use this to simplify the parsing of device model extra args.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9e98f587da45 -r 5ce5f2cdb7be tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Fri Nov 25 14:34:22 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Fri Nov 25 14:34:51 2011 +0000
@@ -254,6 +254,29 @@ int xlu_cfg_get_list(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                     libxl_string_list *psl, int dont_warn) {
+    int i, rc, nr;
+    XLU_ConfigList *list;
+    libxl_string_list sl;
+
+    rc = xlu_cfg_get_list(cfg, n, &list, &nr, dont_warn);
+    if (rc)  return rc;
+
+    sl = malloc(sizeof(char*)*(nr + 1));
+    if (sl == NULL) return ENOMEM;
+
+    for (i=0; i<nr; i++) {
+        const char *a = xlu_cfg_get_listitem(list, i);
+        sl[i] = a ? strdup(a) : NULL;
+    }
+
+    sl[nr] = NULL;
+
+    *psl = sl;
+    return 0;
+}
+
 const char *xlu_cfg_get_listitem(const XLU_ConfigList *set, int entry) {
     if (entry < 0 || entry >= set->nvalues) return 0;
     return set->values[entry];
diff -r 9e98f587da45 -r 5ce5f2cdb7be tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Fri Nov 25 14:34:22 2011 +0000
+++ b/tools/libxl/libxlutil.h	Fri Nov 25 14:34:51 2011 +0000
@@ -58,6 +58,8 @@ int xlu_cfg_get_list(const XLU_Config*, 
                      int *entries_r /* may be 0 */,
                      int dont_warn);
   /* there is no need to free *list_r; lifetime is that of the XLU_Config */
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                                    libxl_string_list *sl, int dont_warn);
 const char *xlu_cfg_get_listitem(const XLU_ConfigList*, int entry);
   /* xlu_cfg_get_listitem cannot fail, except that if entry is
    * out of range it returns 0 (not setting errno) */
diff -r 9e98f587da45 -r 5ce5f2cdb7be tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 14:34:22 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 25 14:34:51 2011 +0000
@@ -529,13 +529,6 @@ static void parse_config_data(const char
     int pci_msitranslate = 1;
     int e;
 
-    XLU_ConfigList *dmargs;
-    int nr_dmargs = 0;
-    XLU_ConfigList *dmargs_hvm;
-    int nr_dmargs_hvm = 0;
-    XLU_ConfigList *dmargs_pv;
-    int nr_dmargs_pv = 0;
-
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
 
@@ -1093,19 +1086,14 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
-#define parse_extra_args(type)                                          \
-    if (!xlu_cfg_get_list(config, "device_model_args"#type,             \
-                          &dmargs##type, &nr_dmargs##type, 0))          \
-    {                                                                   \
-        int i;                                                          \
-        dm_info->extra##type =                                          \
-            xmalloc(sizeof(char*)*(nr_dmargs##type + 1));               \
-        dm_info->extra##type[nr_dmargs##type] = NULL;                   \
-        for (i=0; i<nr_dmargs##type; i++) {                             \
-            const char *a = xlu_cfg_get_listitem(dmargs##type, i);      \
-            dm_info->extra##type[i] = a ? strdup(a) : NULL;             \
-        }                                                               \
-    }                                                                   \
+#define parse_extra_args(type)                                            \
+    e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
+                                    &dm_info->extra##type, 0);            \
+    if (e && e != ESRCH) {                                                \
+        fprintf(stderr,"xl: Unable to parse device_model_args"#type".\n");\
+        exit(-ERROR_FAIL);                                                \
+    }
+
     /* parse extra args for qemu, common to both pv, hvm */
     parse_extra_args();
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6d-0008Gg-3i; Fri, 25 Nov 2011 14:50:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6b-0008Dy-5x
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!8
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14190 invoked from network); 25 Nov 2011 14:49:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874340"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:48 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqG030497;	Fri, 25 Nov 2011 06:49:47 -0800
MIME-Version: 1.0
X-Mercurial-Node: 31e71820ce93b72b0223882f6c2e1f461920bda9
Message-ID: <31e71820ce93b72b0223.1322232587@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 15 of 15 v2] docs: install txt files as html
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322232250 0
# Node ID 31e71820ce93b72b0223882f6c2e1f461920bda9
# Parent  484b880d2ddf1137bcbfec50c89627626a1cf8a6
docs: install txt files as html

A browser will display them just fine.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 484b880d2ddf -r 31e71820ce93 docs/INDEX
--- a/docs/INDEX	Fri Nov 25 14:34:57 2011 +0000
+++ b/docs/INDEX	Fri Nov 25 14:44:10 2011 +0000
@@ -1,5 +1,7 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
+misc/console.txt		Xen PV Console notes
+
 # These are not all that useful anymore, hide them from the index
 reference/interface/index	NO-INDEX
 reference/user/index		NO-INDEX
diff -r 484b880d2ddf -r 31e71820ce93 docs/Makefile
--- a/docs/Makefile	Fri Nov 25 14:34:57 2011 +0000
+++ b/docs/Makefile	Fri Nov 25 14:44:10 2011 +0000
@@ -17,7 +17,8 @@ DOC_PDF		:= $(patsubst src/%.tex,pdf/%.p
 DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
-		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC)) \
+		   $(patsubst %.txt,html/%.txt,$(wildcard misc/*.txt))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
@@ -139,6 +140,10 @@ html/%.html: %.markdown
 	$(call move-if-changed,$@.tmp,$@) ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/%.txt: %.txt
+	@$(INSTALL_DIR) $(@D)
+	cp $< $@
+
 html/man/%.1.html: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
 	$(POD2HTML) --infile=$< --outfile=$@.tmp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6X-0008EV-He; Fri, 25 Nov 2011 14:50:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6V-0008Cq-Ud
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!5
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13942 invoked from network); 25 Nov 2011 14:49:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874329"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:42 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqA030497;	Fri, 25 Nov 2011 06:49:41 -0800
MIME-Version: 1.0
X-Mercurial-Node: bf4b5ef1f1d16189cb1a628ec8445a8018c96be5
Message-ID: <bf4b5ef1f1d16189cb1a.1322232581@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:41 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 09 of 15 v2] docs: remove non-breaking spaces
 from sedf_scheduler_mini-HOWTO.txt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0925039666670693276=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0925039666670693276==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221984 0
# Node ID bf4b5ef1f1d16189cb1a628ec8445a8018c96be5
# Parent  b0009f28bbf2ec313eead3ed36a2b139fa5f3512
docs: remove non-breaking spaces from sedf_scheduler_mini-HOWTO.txt

This document contains several 0xa0 characters (non-breaking spaces). These do
not display correctly in (some) terminals or when the document is rendered by (some)
browsers. Re-encode them as spaces.

I'm not confident that this change will make it through being encoded as a patch
and sent through email. Its effect can be replicated with:

	perl -i -p -e 's/\xa0/ /g' docs/misc/sedf_scheduler_mini-HOWTO.txt

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b0009f28bbf2 -r bf4b5ef1f1d1 docs/misc/sedf_scheduler_mini-HOWTO.txt
--- a/docs/misc/sedf_scheduler_mini-HOWTO.txt	Fri Nov 25 11:53:02 2011 +0000
+++ b/docs/misc/sedf_scheduler_mini-HOWTO.txt	Fri Nov 25 11:53:04 2011 +0000
@@ -8,37 +8,37 @@ Overview:
   uses realtime-algorithms to ensure time guarantees.
 
 Usage:
-   -add "sched=sedf" on Xen's boot command-line
-   -create domains as usual
-   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
-    Where:
-      -period/slice are the normal EDF scheduling parameters in nanosecs
-      -latency-hint is the scaled period in case the domain is doing heavy I/O
+   -add "sched=sedf" on Xen's boot command-line
+   -create domains as usual
+   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
+    Where:
+      -period/slice are the normal EDF scheduling parameters in nanosecs
+      -latency-hint is the scaled period in case the domain is doing heavy I/O
          (unused by the currently compiled version)
-      -extra is a flag (0/1), which controls whether the domain can run in
+      -extra is a flag (0/1), which controls whether the domain can run in
        extra-time
-      -weight is mutually exclusive with period/slice and specifies another
+      -weight is mutually exclusive with period/slice and specifies another
        way of setting a domains cpu slice
 
 Examples:
- normal EDF (20ms/5ms):
-  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
+ normal EDF (20ms/5ms):
+  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
   
- best-effort domains (i.e. non-realtime):
-  xm sched-sedf <dom-id> 20000000 0 0 1 0
- 
+ best-effort domains (i.e. non-realtime):
+  xm sched-sedf <dom-id> 20000000 0 0 1 0
+ 
  normal EDF (20ms/5ms) + share of extra-time:
-  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
+  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
   
- 4 domains with weights 2:3:4:2
-  xm sched-sedf <d1> 0 0 0 0 2
-  xm sched-sedf <d2> 0 0 0 0 3
-  xm sched-sedf <d3> 0 0 0 0 4
-  xm sched-sedf <d4> 0 0 0 0 2
+ 4 domains with weights 2:3:4:2
+  xm sched-sedf <d1> 0 0 0 0 2
+  xm sched-sedf <d2> 0 0 0 0 3
+  xm sched-sedf <d3> 0 0 0 0 4
+  xm sched-sedf <d4> 0 0 0 0 2
   
- 1 fully-specified (10ms/3ms) domain, 3 other domains share
- available rest in 2:7:3 ratio:
-  xm sched-sedf <d1> 10000000 3000000 0 0 0
-  xm sched-sedf <d2> 0 0 0 0 2
-  xm sched-sedf <d3> 0 0 0 0 7
-  xm sched-sedf <d4> 0 0 0 0 3
+ 1 fully-specified (10ms/3ms) domain, 3 other domains share
+ available rest in 2:7:3 ratio:
+  xm sched-sedf <d1> 10000000 3000000 0 0 0
+  xm sched-sedf <d2> 0 0 0 0 2
+  xm sched-sedf <d3> 0 0 0 0 7
+  xm sched-sedf <d4> 0 0 0 0 3


--===============0925039666670693276==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0925039666670693276==--

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6R-0008D2-TB; Fri, 25 Nov 2011 14:50:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6R-0008Cj-3T
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!2
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13435 invoked from network); 25 Nov 2011 14:49:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874321"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:37 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq4030497;	Fri, 25 Nov 2011 06:49:36 -0800
MIME-Version: 1.0
X-Mercurial-Node: 224340062d194a2ef551402cdf79ecd92c34d8f3
Message-ID: <224340062d194a2ef551.1322232575@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:35 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 03 of 15 v2] README: add markdown to dependency
	list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221966 0
# Node ID 224340062d194a2ef551402cdf79ecd92c34d8f3
# Parent  6d7ef8b8a5631f6324b14468ea0f458918f4ad77
README: add markdown to dependency list

although this tool is strictly speaking optional we are providing various user
docs in this format so increase the changes that they will install it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 6d7ef8b8a563 -r 224340062d19 README
--- a/README	Fri Nov 25 11:52:43 2011 +0000
+++ b/README	Fri Nov 25 11:52:46 2011 +0000
@@ -57,6 +57,7 @@ provided by your OS distributor:
     * GNU gettext
     * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
     * ACPI ASL compiler (iasl)
+    * markdown
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6b-0008G0-KG; Fri, 25 Nov 2011 14:50:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6Z-0008DR-IS
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!7
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14123 invoked from network); 25 Nov 2011 14:49:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:47 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874336"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:46 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqE030497;	Fri, 25 Nov 2011 06:49:45 -0800
MIME-Version: 1.0
X-Mercurial-Node: 5ce5f2cdb7be8faed396b62ce26b4ad8669db0bf
Message-ID: <5ce5f2cdb7be8faed396.1322232585@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:45 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 13 of 15 v2] libxlu: add
	xlu_cfg_get_list_as_string_list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322231691 0
# Node ID 5ce5f2cdb7be8faed396b62ce26b4ad8669db0bf
# Parent  9e98f587da45fced29dc9c317f403f53e3fec904
libxlu: add xlu_cfg_get_list_as_string_list

Returns a cfg list as a libxl_string_list.

Use this to simplify the parsing of device model extra args.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9e98f587da45 -r 5ce5f2cdb7be tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Fri Nov 25 14:34:22 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Fri Nov 25 14:34:51 2011 +0000
@@ -254,6 +254,29 @@ int xlu_cfg_get_list(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                     libxl_string_list *psl, int dont_warn) {
+    int i, rc, nr;
+    XLU_ConfigList *list;
+    libxl_string_list sl;
+
+    rc = xlu_cfg_get_list(cfg, n, &list, &nr, dont_warn);
+    if (rc)  return rc;
+
+    sl = malloc(sizeof(char*)*(nr + 1));
+    if (sl == NULL) return ENOMEM;
+
+    for (i=0; i<nr; i++) {
+        const char *a = xlu_cfg_get_listitem(list, i);
+        sl[i] = a ? strdup(a) : NULL;
+    }
+
+    sl[nr] = NULL;
+
+    *psl = sl;
+    return 0;
+}
+
 const char *xlu_cfg_get_listitem(const XLU_ConfigList *set, int entry) {
     if (entry < 0 || entry >= set->nvalues) return 0;
     return set->values[entry];
diff -r 9e98f587da45 -r 5ce5f2cdb7be tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Fri Nov 25 14:34:22 2011 +0000
+++ b/tools/libxl/libxlutil.h	Fri Nov 25 14:34:51 2011 +0000
@@ -58,6 +58,8 @@ int xlu_cfg_get_list(const XLU_Config*, 
                      int *entries_r /* may be 0 */,
                      int dont_warn);
   /* there is no need to free *list_r; lifetime is that of the XLU_Config */
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                                    libxl_string_list *sl, int dont_warn);
 const char *xlu_cfg_get_listitem(const XLU_ConfigList*, int entry);
   /* xlu_cfg_get_listitem cannot fail, except that if entry is
    * out of range it returns 0 (not setting errno) */
diff -r 9e98f587da45 -r 5ce5f2cdb7be tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 14:34:22 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 25 14:34:51 2011 +0000
@@ -529,13 +529,6 @@ static void parse_config_data(const char
     int pci_msitranslate = 1;
     int e;
 
-    XLU_ConfigList *dmargs;
-    int nr_dmargs = 0;
-    XLU_ConfigList *dmargs_hvm;
-    int nr_dmargs_hvm = 0;
-    XLU_ConfigList *dmargs_pv;
-    int nr_dmargs_pv = 0;
-
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
 
@@ -1093,19 +1086,14 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
-#define parse_extra_args(type)                                          \
-    if (!xlu_cfg_get_list(config, "device_model_args"#type,             \
-                          &dmargs##type, &nr_dmargs##type, 0))          \
-    {                                                                   \
-        int i;                                                          \
-        dm_info->extra##type =                                          \
-            xmalloc(sizeof(char*)*(nr_dmargs##type + 1));               \
-        dm_info->extra##type[nr_dmargs##type] = NULL;                   \
-        for (i=0; i<nr_dmargs##type; i++) {                             \
-            const char *a = xlu_cfg_get_listitem(dmargs##type, i);      \
-            dm_info->extra##type[i] = a ? strdup(a) : NULL;             \
-        }                                                               \
-    }                                                                   \
+#define parse_extra_args(type)                                            \
+    e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
+                                    &dm_info->extra##type, 0);            \
+    if (e && e != ESRCH) {                                                \
+        fprintf(stderr,"xl: Unable to parse device_model_args"#type".\n");\
+        exit(-ERROR_FAIL);                                                \
+    }
+
     /* parse extra args for qemu, common to both pv, hvm */
     parse_extra_args();
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6d-0008Gg-3i; Fri, 25 Nov 2011 14:50:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6b-0008Dy-5x
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322232576!4620535!8
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14190 invoked from network); 25 Nov 2011 14:49:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171874340"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:48 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqG030497;	Fri, 25 Nov 2011 06:49:47 -0800
MIME-Version: 1.0
X-Mercurial-Node: 31e71820ce93b72b0223882f6c2e1f461920bda9
Message-ID: <31e71820ce93b72b0223.1322232587@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 15 of 15 v2] docs: install txt files as html
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322232250 0
# Node ID 31e71820ce93b72b0223882f6c2e1f461920bda9
# Parent  484b880d2ddf1137bcbfec50c89627626a1cf8a6
docs: install txt files as html

A browser will display them just fine.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 484b880d2ddf -r 31e71820ce93 docs/INDEX
--- a/docs/INDEX	Fri Nov 25 14:34:57 2011 +0000
+++ b/docs/INDEX	Fri Nov 25 14:44:10 2011 +0000
@@ -1,5 +1,7 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
+misc/console.txt		Xen PV Console notes
+
 # These are not all that useful anymore, hide them from the index
 reference/interface/index	NO-INDEX
 reference/user/index		NO-INDEX
diff -r 484b880d2ddf -r 31e71820ce93 docs/Makefile
--- a/docs/Makefile	Fri Nov 25 14:34:57 2011 +0000
+++ b/docs/Makefile	Fri Nov 25 14:44:10 2011 +0000
@@ -17,7 +17,8 @@ DOC_PDF		:= $(patsubst src/%.tex,pdf/%.p
 DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
-		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC)) \
+		   $(patsubst %.txt,html/%.txt,$(wildcard misc/*.txt))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
@@ -139,6 +140,10 @@ html/%.html: %.markdown
 	$(call move-if-changed,$@.tmp,$@) ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/%.txt: %.txt
+	@$(INSTALL_DIR) $(@D)
+	cp $< $@
+
 html/man/%.1.html: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
 	$(POD2HTML) --infile=$< --outfile=$@.tmp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6o-0008L9-UC; Fri, 25 Nov 2011 14:50:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6m-0008IE-T1
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322232599!3042642!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22985 invoked from network); 25 Nov 2011 14:50:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:50:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407291"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:42 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq9030497;	Fri, 25 Nov 2011 06:49:41 -0800
MIME-Version: 1.0
X-Mercurial-Node: b0009f28bbf2ec313eead3ed36a2b139fa5f3512
Message-ID: <b0009f28bbf2ec313eea.1322232580@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:40 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 08 of 15 v2] libxl: use named options for
	tsc_mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221982 0
# Node ID b0009f28bbf2ec313eead3ed36a2b139fa5f3512
# Parent  88eee947a2bd15d4811c664ba6ed345a066708eb
libxl: use named options for tsc_mode.

Add an enum at the libxl level with a hopefully descriptive set of names.
Deprecate the use of an integer in xl cfg files.

Signed-off-by: Ian Campbell

diff -r 88eee947a2bd -r b0009f28bbf2 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Fri Nov 25 11:53:00 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Fri Nov 25 11:53:02 2011 +0000
@@ -491,11 +491,45 @@ compatibility mode on more modern Window
 
 =item B<tsc_mode="MODE">
 
+
 Specifies how the TSC (Time Stamp Counter) should be provided to the
-guest.  XXX ???
+guest (X86 only). Specifying this option as a number is
+deprecated. Options are:
+
+=over 4
+
+=item B<"default">
+
+Guest rdtsc/p executed natively when monotonicity can be guaranteed
+and emulated otherwise (with frequency scaled if necessary).
+
+=item B<"always_emulate">
+
+Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
+always emulated and the virtual TSC will appear to increment (kernel
+and user) at a fixed 1GHz rate, regardless of the PCPU HZ rate or
+power state; Although there is an overhead associated with emulation
+this will NOT affect underlying CPU performance.
+
+=item B<"native">
+
+Guest rdtsc always executed natively (no monotonicity/frequency
+guarantees); guest rdtscp emulated at native frequency if unsupported
+by h/w, else executed natively.
+
+=item B<"native_paravirt">
+
+Same as B<native>, except xen manages TSC_AUX register so guest can
+determine when a restore/migration has occurred and assumes guest
+obtains/uses pvclock-like mechanism to adjust for monotonicity and
+frequency changes.
 
 =back
 
+=back
+
+Please see F<docs/misc/tscmode.txt> for more information on this option.
+
 =head3 Support for Paravirtualisation of HVM Guests
 
 The following options allow Paravirtualised features (such as devices)
diff -r 88eee947a2bd -r b0009f28bbf2 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Nov 25 11:53:00 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Nov 25 11:53:02 2011 +0000
@@ -73,12 +73,29 @@ int libxl__build_pre(libxl__gc *gc, uint
               libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    int tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
                 (info->max_memkb + info->u.pv.slack_memkb));
-    xc_domain_set_tsc_info(ctx->xch, domid, info->tsc_mode, 0, 0, 0);
+    switch (info->tsc_mode) {
+    case LIBXL_TSC_MODE_DEFAULT:
+        tsc_mode = 0;
+        break;
+    case LIBXL_TSC_MODE_ALWAYS_EMULATE:
+        tsc_mode = 1;
+        break;
+    case LIBXL_TSC_MODE_NATIVE:
+        tsc_mode = 2;
+        break;
+    case LIBXL_TSC_MODE_NATIVE_PARAVIRT:
+        tsc_mode = 3;
+        break;
+    default:
+        abort();
+    }
+    xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
     if ( info->disable_migrate )
         xc_domain_disable_migrate(ctx->xch, domid);
 
diff -r 88eee947a2bd -r b0009f28bbf2 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Nov 25 11:53:00 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Nov 25 11:53:02 2011 +0000
@@ -85,6 +85,13 @@ libxl_button = Enumeration("button", [
     (2, "SLEEP"),
     ])
 
+libxl_tsc_mode = Enumeration("tsc_mode", [
+    (0, "default"),
+    (1, "always_emulate"),
+    (2, "native"),
+    (3, "native_paravirt"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -154,7 +161,7 @@ libxl_domain_create_info = Struct("domai
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
-    ("tsc_mode",        integer),
+    ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
     ("video_memkb",     uint32),
diff -r 88eee947a2bd -r b0009f28bbf2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:53:00 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:53:02 2011 +0000
@@ -328,7 +328,7 @@ static void printf_info(int domid,
 
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
-    printf("\t(tsc_mode %d)\n", b_info->tsc_mode);
+    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
@@ -662,8 +662,28 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
+        const char *s = libxl_tsc_mode_to_string(l);
+        fprintf(stderr, "WARNING: specifying \"tsc_mode\" as an integer is deprecated. "
+                "Please use the named parameter variant. %s%s%s\n",
+                s ? "e.g. tsc_mode=\"" : "",
+                s ? s : "",
+                s ? "\"" : "");
+
+        if (l < LIBXL_TSC_MODE_DEFAULT ||
+            l > LIBXL_TSC_MODE_NATIVE_PARAVIRT) {
+            fprintf(stderr, "ERROR: invalid value %ld for \"tsc_mode\"\n", l);
+            exit (1);
+        }
         b_info->tsc_mode = l;
+    } else if (!xlu_cfg_get_string(config, "tsc_mode", &buf, 0)) {
+        fprintf(stderr, "got a tsc mode string: \"%s\"\n", buf);
+        if (libxl_tsc_mode_from_string(buf, &b_info->tsc_mode)) {
+            fprintf(stderr, "ERROR: invalid value \"%s\" for \"tsc_mode\"\n",
+                    buf);
+            exit (1);
+        }
+    }
 
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6o-0008L9-UC; Fri, 25 Nov 2011 14:50:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6m-0008IE-T1
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322232599!3042642!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22985 invoked from network); 25 Nov 2011 14:50:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:50:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407291"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:42 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq9030497;	Fri, 25 Nov 2011 06:49:41 -0800
MIME-Version: 1.0
X-Mercurial-Node: b0009f28bbf2ec313eead3ed36a2b139fa5f3512
Message-ID: <b0009f28bbf2ec313eea.1322232580@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:40 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 08 of 15 v2] libxl: use named options for
	tsc_mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221982 0
# Node ID b0009f28bbf2ec313eead3ed36a2b139fa5f3512
# Parent  88eee947a2bd15d4811c664ba6ed345a066708eb
libxl: use named options for tsc_mode.

Add an enum at the libxl level with a hopefully descriptive set of names.
Deprecate the use of an integer in xl cfg files.

Signed-off-by: Ian Campbell

diff -r 88eee947a2bd -r b0009f28bbf2 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Fri Nov 25 11:53:00 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Fri Nov 25 11:53:02 2011 +0000
@@ -491,11 +491,45 @@ compatibility mode on more modern Window
 
 =item B<tsc_mode="MODE">
 
+
 Specifies how the TSC (Time Stamp Counter) should be provided to the
-guest.  XXX ???
+guest (X86 only). Specifying this option as a number is
+deprecated. Options are:
+
+=over 4
+
+=item B<"default">
+
+Guest rdtsc/p executed natively when monotonicity can be guaranteed
+and emulated otherwise (with frequency scaled if necessary).
+
+=item B<"always_emulate">
+
+Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
+always emulated and the virtual TSC will appear to increment (kernel
+and user) at a fixed 1GHz rate, regardless of the PCPU HZ rate or
+power state; Although there is an overhead associated with emulation
+this will NOT affect underlying CPU performance.
+
+=item B<"native">
+
+Guest rdtsc always executed natively (no monotonicity/frequency
+guarantees); guest rdtscp emulated at native frequency if unsupported
+by h/w, else executed natively.
+
+=item B<"native_paravirt">
+
+Same as B<native>, except xen manages TSC_AUX register so guest can
+determine when a restore/migration has occurred and assumes guest
+obtains/uses pvclock-like mechanism to adjust for monotonicity and
+frequency changes.
 
 =back
 
+=back
+
+Please see F<docs/misc/tscmode.txt> for more information on this option.
+
 =head3 Support for Paravirtualisation of HVM Guests
 
 The following options allow Paravirtualised features (such as devices)
diff -r 88eee947a2bd -r b0009f28bbf2 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Nov 25 11:53:00 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Nov 25 11:53:02 2011 +0000
@@ -73,12 +73,29 @@ int libxl__build_pre(libxl__gc *gc, uint
               libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    int tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
                 (info->max_memkb + info->u.pv.slack_memkb));
-    xc_domain_set_tsc_info(ctx->xch, domid, info->tsc_mode, 0, 0, 0);
+    switch (info->tsc_mode) {
+    case LIBXL_TSC_MODE_DEFAULT:
+        tsc_mode = 0;
+        break;
+    case LIBXL_TSC_MODE_ALWAYS_EMULATE:
+        tsc_mode = 1;
+        break;
+    case LIBXL_TSC_MODE_NATIVE:
+        tsc_mode = 2;
+        break;
+    case LIBXL_TSC_MODE_NATIVE_PARAVIRT:
+        tsc_mode = 3;
+        break;
+    default:
+        abort();
+    }
+    xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
     if ( info->disable_migrate )
         xc_domain_disable_migrate(ctx->xch, domid);
 
diff -r 88eee947a2bd -r b0009f28bbf2 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Nov 25 11:53:00 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Nov 25 11:53:02 2011 +0000
@@ -85,6 +85,13 @@ libxl_button = Enumeration("button", [
     (2, "SLEEP"),
     ])
 
+libxl_tsc_mode = Enumeration("tsc_mode", [
+    (0, "default"),
+    (1, "always_emulate"),
+    (2, "native"),
+    (3, "native_paravirt"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -154,7 +161,7 @@ libxl_domain_create_info = Struct("domai
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
-    ("tsc_mode",        integer),
+    ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
     ("video_memkb",     uint32),
diff -r 88eee947a2bd -r b0009f28bbf2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:53:00 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:53:02 2011 +0000
@@ -328,7 +328,7 @@ static void printf_info(int domid,
 
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
-    printf("\t(tsc_mode %d)\n", b_info->tsc_mode);
+    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
@@ -662,8 +662,28 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
+        const char *s = libxl_tsc_mode_to_string(l);
+        fprintf(stderr, "WARNING: specifying \"tsc_mode\" as an integer is deprecated. "
+                "Please use the named parameter variant. %s%s%s\n",
+                s ? "e.g. tsc_mode=\"" : "",
+                s ? s : "",
+                s ? "\"" : "");
+
+        if (l < LIBXL_TSC_MODE_DEFAULT ||
+            l > LIBXL_TSC_MODE_NATIVE_PARAVIRT) {
+            fprintf(stderr, "ERROR: invalid value %ld for \"tsc_mode\"\n", l);
+            exit (1);
+        }
         b_info->tsc_mode = l;
+    } else if (!xlu_cfg_get_string(config, "tsc_mode", &buf, 0)) {
+        fprintf(stderr, "got a tsc mode string: \"%s\"\n", buf);
+        if (libxl_tsc_mode_from_string(buf, &b_info->tsc_mode)) {
+            fprintf(stderr, "ERROR: invalid value \"%s\" for \"tsc_mode\"\n",
+                    buf);
+            exit (1);
+        }
+    }
 
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6o-0008Kl-ER; Fri, 25 Nov 2011 14:50:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6m-0008I4-9E
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322232597!3042528!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25604 invoked from network); 25 Nov 2011 14:49:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407286"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:35 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq1030497;	Fri, 25 Nov 2011 06:49:34 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:32 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 00 of 15 v2] Documentation updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Repost of my documentation series.

Changes since last time:

Dropped "docs: generate docs direct into final filename", using a
temp file prevents half completed docsshowing up after an error

Applied IanJ's review of my perl code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6o-0008Kl-ER; Fri, 25 Nov 2011 14:50:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6m-0008I4-9E
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322232597!3042528!3
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25604 invoked from network); 25 Nov 2011 14:49:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407286"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:35 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq1030497;	Fri, 25 Nov 2011 06:49:34 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:32 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 00 of 15 v2] Documentation updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Repost of my documentation series.

Changes since last time:

Dropped "docs: generate docs direct into final filename", using a
temp file prevents half completed docsshowing up after an error

Applied IanJ's review of my perl code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6m-0008Jm-HU; Fri, 25 Nov 2011 14:50:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6l-0008HZ-2q
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322232597!3042528!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25540 invoked from network); 25 Nov 2011 14:49:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407290"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:40 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq7030497;	Fri, 25 Nov 2011 06:49:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: 5a4e9f351a8ea57568a4a2dd8a5c4684628c56c9
Message-ID: <5a4e9f351a8ea57568a4.1322232578@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 06 of 15 v2] xl: the name field in a guest
 config file is mandatory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221978 0
# Node ID 5a4e9f351a8ea57568a4a2dd8a5c4684628c56c9
# Parent  08a74d202a0a5b19b1229da893526856d832807b
xl: the name field in a guest config file is mandatory

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 08a74d202a0a -r 5a4e9f351a8e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:52:55 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:52:58 2011 +0000
@@ -575,8 +575,10 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "hap", &l))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name))
-        c_info->name = strdup("test");
+    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+        fprintf(stderr, "Domain name must be specified.");
+        exit(1);
+    }
 
     if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6m-0008Jm-HU; Fri, 25 Nov 2011 14:50:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6l-0008HZ-2q
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322232597!3042528!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25540 invoked from network); 25 Nov 2011 14:49:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407290"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:40 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq7030497;	Fri, 25 Nov 2011 06:49:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: 5a4e9f351a8ea57568a4a2dd8a5c4684628c56c9
Message-ID: <5a4e9f351a8ea57568a4.1322232578@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 06 of 15 v2] xl: the name field in a guest
 config file is mandatory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221978 0
# Node ID 5a4e9f351a8ea57568a4a2dd8a5c4684628c56c9
# Parent  08a74d202a0a5b19b1229da893526856d832807b
xl: the name field in a guest config file is mandatory

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 08a74d202a0a -r 5a4e9f351a8e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:52:55 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 25 11:52:58 2011 +0000
@@ -575,8 +575,10 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "hap", &l))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name))
-        c_info->name = strdup("test");
+    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+        fprintf(stderr, "Domain name must be specified.");
+        exit(1);
+    }
 
     if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6m-0008K4-Ux; Fri, 25 Nov 2011 14:50:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6l-0008Ho-Ke
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322232597!3042528!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25568 invoked from network); 25 Nov 2011 14:49:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407292"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:43 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqB030497;	Fri, 25 Nov 2011 06:49:42 -0800
MIME-Version: 1.0
X-Mercurial-Node: ddeac8b237e4f71d05c817fa8432417886e7e202
Message-ID: <ddeac8b237e4f71d05c8.1322232582@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:42 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 10 of 15 v2] docs: tweak markup and wording of
 qemu upstream doc slightly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221986 0
# Node ID ddeac8b237e4f71d05c817fa8432417886e7e202
# Parent  bf4b5ef1f1d16189cb1a628ec8445a8018c96be5
docs: tweak markup and wording of qemu upstream doc slightly

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r bf4b5ef1f1d1 -r ddeac8b237e4 docs/misc/qemu-upstream_howto_use_it.markdown
--- a/docs/misc/qemu-upstream_howto_use_it.markdown	Fri Nov 25 11:53:04 2011 +0000
+++ b/docs/misc/qemu-upstream_howto_use_it.markdown	Fri Nov 25 11:53:06 2011 +0000
@@ -1,11 +1,11 @@
-Help to use QEMU (upstream version) with Xen
-============================================
+Using Upstream QEMU with Xen
+============================
 
 Note
 ----
 
 All these steps will become unnecessary after the patches to integrate
-SeaBIOS/QEMU build will be applied.
+SeaBIOS/QEMU into the Xen build system have been applied.
 
 
 How to build it
@@ -15,14 +15,15 @@ How to build it
 
 The new device-model needs a different BIOS, SeaBIOS. Clone the repository from:
 
-  - git://git.qemu.org/seabios.git
-  - http://git.qemu.org/git/seabios.git
+  - [git://git.qemu.org/seabios.git]()
+  - [http://git.qemu.org/git/seabios.git]()
 
-Put the `.config` file in the appendix at the root of seabios.git and build SeaBIOS.
+Put the `.config` file in the appendix at the root of `seabios.git`
+and build SeaBIOS by typing `make`.
 
-In xen-unstable source tree, add the file `.config` with
+In the xen-unstable source tree, add the file `.config` with
 `SEABIOS_DIR = /path/to/seabios.git`.
-To build hvmloader with SeaBIOS, you propably need to `make -C tools/firmware
+To build hvmloader with SeaBIOS, you probably need to `make -C tools/firmware
 clean` first and then `make tools`, to use the new SEABIOS_DIR parameter.
 
 
@@ -30,10 +31,10 @@ clean` first and then `make tools`, to u
 
 Get QEMU upstream source from:
 
-  - git://xenbits.xensource.com/qemu-upstream-unstable.git
-  - http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
+  - [git://xenbits.xensource.com/qemu-upstream-unstable.git]()
+  - [http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git]()
 
-To configure build QEMU upstream with Xen
+To configure QEMU upstream with support for Xen:
 
     ./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I$path_to_xen_source/tools/include -I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore" --extra-ldflags="-L$path_to_xen_source/tools/libxc -L$path_to_xen_source/tools/xenstore"
 
@@ -43,15 +44,15 @@ You can also use other several options s
 How to use QEMU upstream
 ------------------------
 
-Only xl support QEMU upstream.
+Only `xl` supports QEMU upstream.
 
 To actually use it, add or change this in your VM configuration file:
 
     device_model_version = 'qemu-xen'
     device_model_override = '/path/to/qemu/i386-softmmu/qemu'
 
-NB: On qemu-upstream repository, the default binary name has been renamed to
-`qemu-system-i386`.
+NB: In the `qemu-upstream` repository, the default binary name has been
+renamed to `qemu-system-i386`.
 
 
 Appendix

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6m-0008K4-Ux; Fri, 25 Nov 2011 14:50:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6l-0008Ho-Ke
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322232597!3042528!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25568 invoked from network); 25 Nov 2011 14:49:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:49:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407292"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:43 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqB030497;	Fri, 25 Nov 2011 06:49:42 -0800
MIME-Version: 1.0
X-Mercurial-Node: ddeac8b237e4f71d05c817fa8432417886e7e202
Message-ID: <ddeac8b237e4f71d05c8.1322232582@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:42 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 10 of 15 v2] docs: tweak markup and wording of
 qemu upstream doc slightly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221986 0
# Node ID ddeac8b237e4f71d05c817fa8432417886e7e202
# Parent  bf4b5ef1f1d16189cb1a628ec8445a8018c96be5
docs: tweak markup and wording of qemu upstream doc slightly

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r bf4b5ef1f1d1 -r ddeac8b237e4 docs/misc/qemu-upstream_howto_use_it.markdown
--- a/docs/misc/qemu-upstream_howto_use_it.markdown	Fri Nov 25 11:53:04 2011 +0000
+++ b/docs/misc/qemu-upstream_howto_use_it.markdown	Fri Nov 25 11:53:06 2011 +0000
@@ -1,11 +1,11 @@
-Help to use QEMU (upstream version) with Xen
-============================================
+Using Upstream QEMU with Xen
+============================
 
 Note
 ----
 
 All these steps will become unnecessary after the patches to integrate
-SeaBIOS/QEMU build will be applied.
+SeaBIOS/QEMU into the Xen build system have been applied.
 
 
 How to build it
@@ -15,14 +15,15 @@ How to build it
 
 The new device-model needs a different BIOS, SeaBIOS. Clone the repository from:
 
-  - git://git.qemu.org/seabios.git
-  - http://git.qemu.org/git/seabios.git
+  - [git://git.qemu.org/seabios.git]()
+  - [http://git.qemu.org/git/seabios.git]()
 
-Put the `.config` file in the appendix at the root of seabios.git and build SeaBIOS.
+Put the `.config` file in the appendix at the root of `seabios.git`
+and build SeaBIOS by typing `make`.
 
-In xen-unstable source tree, add the file `.config` with
+In the xen-unstable source tree, add the file `.config` with
 `SEABIOS_DIR = /path/to/seabios.git`.
-To build hvmloader with SeaBIOS, you propably need to `make -C tools/firmware
+To build hvmloader with SeaBIOS, you probably need to `make -C tools/firmware
 clean` first and then `make tools`, to use the new SEABIOS_DIR parameter.
 
 
@@ -30,10 +31,10 @@ clean` first and then `make tools`, to u
 
 Get QEMU upstream source from:
 
-  - git://xenbits.xensource.com/qemu-upstream-unstable.git
-  - http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
+  - [git://xenbits.xensource.com/qemu-upstream-unstable.git]()
+  - [http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git]()
 
-To configure build QEMU upstream with Xen
+To configure QEMU upstream with support for Xen:
 
     ./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I$path_to_xen_source/tools/include -I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore" --extra-ldflags="-L$path_to_xen_source/tools/libxc -L$path_to_xen_source/tools/xenstore"
 
@@ -43,15 +44,15 @@ You can also use other several options s
 How to use QEMU upstream
 ------------------------
 
-Only xl support QEMU upstream.
+Only `xl` supports QEMU upstream.
 
 To actually use it, add or change this in your VM configuration file:
 
     device_model_version = 'qemu-xen'
     device_model_override = '/path/to/qemu/i386-softmmu/qemu'
 
-NB: On qemu-upstream repository, the default binary name has been renamed to
-`qemu-system-i386`.
+NB: In the `qemu-upstream` repository, the default binary name has been
+renamed to `qemu-system-i386`.
 
 
 Appendix

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6q-0008MI-Dg; Fri, 25 Nov 2011 14:50:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6o-0008It-IT
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322232600!4999750!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4138 invoked from network); 25 Nov 2011 14:50:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:50:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407294"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:47 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqF030497;	Fri, 25 Nov 2011 06:49:46 -0800
MIME-Version: 1.0
X-Mercurial-Node: 484b880d2ddf1137bcbfec50c89627626a1cf8a6
Message-ID: <484b880d2ddf1137bcbf.1322232586@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 14 of 15 v2] xl: make bootloader_args a list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322231697 0
# Node ID 484b880d2ddf1137bcbfec50c89627626a1cf8a6
# Parent  5ce5f2cdb7be8faed396b62ce26b4ad8669db0bf
xl: make bootloader_args a list

This is much more natural. Continue to support the old syntax in xl but deprecate it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 5ce5f2cdb7be -r 484b880d2ddf docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Fri Nov 25 14:34:51 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Fri Nov 25 14:34:57 2011 +0000
@@ -321,10 +321,11 @@ Run C<PROGRAM> to find the kernel image 
 C<PROGRAM> would be C<pygrub>, which is an emulation of
 grub/grub2/syslinux.
 
-=item B<bootloader_args=STRING>
+=item B<bootloader_args=[ "ARG", "ARG", ...]>
 
-Append B<STRING> (split into words at whitespace) to the arguments to
-the B<bootloader> program.  XXX this should be a list of strings.
+Append B<ARG>s to the arguments to the B<bootloader>
+program. Alternatively if the argument is a simple string then it will
+be split into words at whitespace (this second option is deprecated).
 
 =item B<root="STRING">
 
diff -r 5ce5f2cdb7be -r 484b880d2ddf tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Fri Nov 25 14:34:51 2011 +0000
+++ b/tools/libxl/libxl_bootloader.c	Fri Nov 25 14:34:57 2011 +0000
@@ -58,13 +58,9 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *saveptr;
-        /* Operate on a duplicate since strtok modifes the argument */
-        char *dup = libxl__strdup(gc, info->u.pv.bootloader_args);
-        char *t = strtok_r(dup, " \t\n", &saveptr);
-        do {
-            flexarray_set(args, nr++, t);
-        } while ((t = strtok_r(NULL, " \t\n", &saveptr)));
+        char *p = info->u.pv.bootloader_args[0];
+        while (*(p++))
+            flexarray_set(args, nr++, p);
     }
 
     flexarray_set(args, nr++, disk);
diff -r 5ce5f2cdb7be -r 484b880d2ddf tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Nov 25 14:34:51 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Nov 25 14:34:57 2011 +0000
@@ -187,7 +187,7 @@ libxl_domain_build_info = Struct("domain
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
                                       ("bootloader", string),
-                                      ("bootloader_args", string),
+                                      ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, True),
diff -r 5ce5f2cdb7be -r 484b880d2ddf tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 14:34:51 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 25 14:34:57 2011 +0000
@@ -334,9 +334,14 @@ static void printf_info(int domid,
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
+        int i;
         printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
-        if (b_info->u.pv.bootloader_args)
-            printf("\t(bootloader_args %s)\n", b_info->u.pv.bootloader_args);
+        if (b_info->u.pv.bootloader_args) {
+            printf("\t(bootloader_args");
+            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
+                printf(" %s", b_info->u.pv.bootloader_args[i]);
+            printf(")\n");
+        }
     }
 
     printf("\t(image\n");
@@ -515,6 +520,51 @@ static void parse_disk_config(XLU_Config
     parse_disk_config_multistring(config, 1, &spec, disk);
 }
 
+static void split_string_into_string_list(const char *str,
+                                          const char *delim,
+                                          libxl_string_list *psl)
+{
+    char *s, *saveptr;
+    const char *p;
+    libxl_string_list sl;
+
+    int i = 0, nr = 0;
+
+    s = strdup(str);
+    if (s == NULL) {
+        fprintf(stderr, "unable to allocate memory to parse bootloader args\n");
+        exit(-1);
+    }
+
+    /* Count number of entries */
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        nr++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+
+    free(s);
+
+    s = strdup(str);
+
+    sl = malloc((nr+1) * sizeof (char *));
+    if (sl == NULL) {
+        fprintf(stderr, "unable to allocate memory for bootloader args\n");
+        exit(-1);
+    }
+
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        assert(i < nr);
+        sl[i] = strdup(p);
+        i++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+    sl[i] = NULL;
+
+    *psl = sl;
+
+    free(s);
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -739,10 +789,26 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader",
-                                &b_info->u.pv.bootloader, 0);
-        xlu_cfg_replace_string (config, "bootloader_args",
-                                &b_info->u.pv.bootloader_args, 0);
+        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader, 0);
+        switch (xlu_cfg_get_list_as_string_list(config, "bootloader_args",
+                                                &b_info->u.pv.bootloader_args, 1))
+        {
+
+        case 0: break; /* Success */
+        case ESRCH: break; /* Option not present */
+        case EINVAL:
+            if (!xlu_cfg_get_string(config, "bootloader_args", &buf, 0)) {
+
+                fprintf(stderr, "WARNING: Specifying \"bootloader_args\" as a string is deprecated. "
+                        "Please use a list of arguments.\n");
+                split_string_into_string_list(buf, " \t\n",
+                                              &b_info->u.pv.bootloader_args);
+            }
+            break;
+        default:
+            fprintf(stderr,"xl: Unable to parse bootloader_args.\n");
+            exit(-ERROR_FAIL);
+        }
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6q-0008MI-Dg; Fri, 25 Nov 2011 14:50:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6o-0008It-IT
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322232600!4999750!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4138 invoked from network); 25 Nov 2011 14:50:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:50:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407294"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:47 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqF030497;	Fri, 25 Nov 2011 06:49:46 -0800
MIME-Version: 1.0
X-Mercurial-Node: 484b880d2ddf1137bcbfec50c89627626a1cf8a6
Message-ID: <484b880d2ddf1137bcbf.1322232586@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 14 of 15 v2] xl: make bootloader_args a list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322231697 0
# Node ID 484b880d2ddf1137bcbfec50c89627626a1cf8a6
# Parent  5ce5f2cdb7be8faed396b62ce26b4ad8669db0bf
xl: make bootloader_args a list

This is much more natural. Continue to support the old syntax in xl but deprecate it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 5ce5f2cdb7be -r 484b880d2ddf docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Fri Nov 25 14:34:51 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Fri Nov 25 14:34:57 2011 +0000
@@ -321,10 +321,11 @@ Run C<PROGRAM> to find the kernel image 
 C<PROGRAM> would be C<pygrub>, which is an emulation of
 grub/grub2/syslinux.
 
-=item B<bootloader_args=STRING>
+=item B<bootloader_args=[ "ARG", "ARG", ...]>
 
-Append B<STRING> (split into words at whitespace) to the arguments to
-the B<bootloader> program.  XXX this should be a list of strings.
+Append B<ARG>s to the arguments to the B<bootloader>
+program. Alternatively if the argument is a simple string then it will
+be split into words at whitespace (this second option is deprecated).
 
 =item B<root="STRING">
 
diff -r 5ce5f2cdb7be -r 484b880d2ddf tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Fri Nov 25 14:34:51 2011 +0000
+++ b/tools/libxl/libxl_bootloader.c	Fri Nov 25 14:34:57 2011 +0000
@@ -58,13 +58,9 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *saveptr;
-        /* Operate on a duplicate since strtok modifes the argument */
-        char *dup = libxl__strdup(gc, info->u.pv.bootloader_args);
-        char *t = strtok_r(dup, " \t\n", &saveptr);
-        do {
-            flexarray_set(args, nr++, t);
-        } while ((t = strtok_r(NULL, " \t\n", &saveptr)));
+        char *p = info->u.pv.bootloader_args[0];
+        while (*(p++))
+            flexarray_set(args, nr++, p);
     }
 
     flexarray_set(args, nr++, disk);
diff -r 5ce5f2cdb7be -r 484b880d2ddf tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Nov 25 14:34:51 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Nov 25 14:34:57 2011 +0000
@@ -187,7 +187,7 @@ libxl_domain_build_info = Struct("domain
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
                                       ("bootloader", string),
-                                      ("bootloader_args", string),
+                                      ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, True),
diff -r 5ce5f2cdb7be -r 484b880d2ddf tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 14:34:51 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Nov 25 14:34:57 2011 +0000
@@ -334,9 +334,14 @@ static void printf_info(int domid,
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
+        int i;
         printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
-        if (b_info->u.pv.bootloader_args)
-            printf("\t(bootloader_args %s)\n", b_info->u.pv.bootloader_args);
+        if (b_info->u.pv.bootloader_args) {
+            printf("\t(bootloader_args");
+            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
+                printf(" %s", b_info->u.pv.bootloader_args[i]);
+            printf(")\n");
+        }
     }
 
     printf("\t(image\n");
@@ -515,6 +520,51 @@ static void parse_disk_config(XLU_Config
     parse_disk_config_multistring(config, 1, &spec, disk);
 }
 
+static void split_string_into_string_list(const char *str,
+                                          const char *delim,
+                                          libxl_string_list *psl)
+{
+    char *s, *saveptr;
+    const char *p;
+    libxl_string_list sl;
+
+    int i = 0, nr = 0;
+
+    s = strdup(str);
+    if (s == NULL) {
+        fprintf(stderr, "unable to allocate memory to parse bootloader args\n");
+        exit(-1);
+    }
+
+    /* Count number of entries */
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        nr++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+
+    free(s);
+
+    s = strdup(str);
+
+    sl = malloc((nr+1) * sizeof (char *));
+    if (sl == NULL) {
+        fprintf(stderr, "unable to allocate memory for bootloader args\n");
+        exit(-1);
+    }
+
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        assert(i < nr);
+        sl[i] = strdup(p);
+        i++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+    sl[i] = NULL;
+
+    *psl = sl;
+
+    free(s);
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -739,10 +789,26 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader",
-                                &b_info->u.pv.bootloader, 0);
-        xlu_cfg_replace_string (config, "bootloader_args",
-                                &b_info->u.pv.bootloader_args, 0);
+        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader, 0);
+        switch (xlu_cfg_get_list_as_string_list(config, "bootloader_args",
+                                                &b_info->u.pv.bootloader_args, 1))
+        {
+
+        case 0: break; /* Success */
+        case ESRCH: break; /* Option not present */
+        case EINVAL:
+            if (!xlu_cfg_get_string(config, "bootloader_args", &buf, 0)) {
+
+                fprintf(stderr, "WARNING: Specifying \"bootloader_args\" as a string is deprecated. "
+                        "Please use a list of arguments.\n");
+                split_string_into_string_list(buf, " \t\n",
+                                              &b_info->u.pv.bootloader_args);
+            }
+            break;
+        default:
+            fprintf(stderr,"xl: Unable to parse bootloader_args.\n");
+            exit(-ERROR_FAIL);
+        }
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6q-0008Lt-0f; Fri, 25 Nov 2011 14:50:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6o-0008Ik-43
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322232599!3042642!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23028 invoked from network); 25 Nov 2011 14:50:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:50:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407287"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:36 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq3030497;	Fri, 25 Nov 2011 06:49:35 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6d7ef8b8a5631f6324b14468ea0f458918f4ad77
Message-ID: <6d7ef8b8a5631f6324b1.1322232574@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:34 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 02 of 15 v2] docs: xlexample.hvm is missing
	"builder = 'hvm'"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221963 0
# Node ID 6d7ef8b8a5631f6324b14468ea0f458918f4ad77
# Parent  732154549538fe983a8cc6ea74605e04e8ea0a64
docs: xlexample.hvm is missing "builder = 'hvm'"

This is rather critical...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 732154549538 -r 6d7ef8b8a563 tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Fri Nov 25 11:52:36 2011 +0000
+++ b/tools/examples/xlexample.hvm	Fri Nov 25 11:52:43 2011 +0000
@@ -5,6 +5,9 @@
 # This is a fairly minimal example of what is required for an
 # HVM guest. For a more complete guide see <XXX Document TBD>
 
+# This configures an HVM rather than PV guest
+builder = "hvm"
+
 # Guest name
 name = "example.hvm"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6q-0008Lt-0f; Fri, 25 Nov 2011 14:50:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6o-0008Ik-43
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322232599!3042642!2
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23028 invoked from network); 25 Nov 2011 14:50:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:50:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407287"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:36 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq3030497;	Fri, 25 Nov 2011 06:49:35 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6d7ef8b8a5631f6324b14468ea0f458918f4ad77
Message-ID: <6d7ef8b8a5631f6324b1.1322232574@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:34 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 02 of 15 v2] docs: xlexample.hvm is missing
	"builder = 'hvm'"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221963 0
# Node ID 6d7ef8b8a5631f6324b14468ea0f458918f4ad77
# Parent  732154549538fe983a8cc6ea74605e04e8ea0a64
docs: xlexample.hvm is missing "builder = 'hvm'"

This is rather critical...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 732154549538 -r 6d7ef8b8a563 tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Fri Nov 25 11:52:36 2011 +0000
+++ b/tools/examples/xlexample.hvm	Fri Nov 25 11:52:43 2011 +0000
@@ -5,6 +5,9 @@
 # This is a fairly minimal example of what is required for an
 # HVM guest. For a more complete guide see <XXX Document TBD>
 
+# This configures an HVM rather than PV guest
+builder = "hvm"
+
 # Guest name
 name = "example.hvm"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6r-0008N1-Rq; Fri, 25 Nov 2011 14:50:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6q-0008J9-22
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322232597!3042528!5
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25942 invoked from network); 25 Nov 2011 14:50:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:50:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407288"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:38 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq5030497;	Fri, 25 Nov 2011 06:49:37 -0800
MIME-Version: 1.0
X-Mercurial-Node: 96479242221d8b58dde242442c47da2ab4c71a8f
Message-ID: <96479242221d8b58dde2.1322232576@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 04 of 15 v2] docs: install html and txt versions
	of manpages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221968 0
# Node ID 96479242221d8b58dde242442c47da2ab4c71a8f
# Parent  224340062d194a2ef551402cdf79ecd92c34d8f3
docs: install html and txt versions of manpages

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 224340062d19 -r 96479242221d docs/Docs.mk
--- a/docs/Docs.mk	Fri Nov 25 11:52:46 2011 +0000
+++ b/docs/Docs.mk	Fri Nov 25 11:52:48 2011 +0000
@@ -5,6 +5,8 @@ FIG2DEV		:= fig2dev
 LATEX2HTML	:= latex2html
 DOXYGEN		:= doxygen
 POD2MAN		:= pod2man
+POD2HTML	:= pod2html
+POD2TEXT	:= pod2text
 DOT		:= dot
 NEATO		:= neato
 MARKDOWN	:= markdown
diff -r 224340062d19 -r 96479242221d docs/Makefile
--- a/docs/Makefile	Fri Nov 25 11:52:46 2011 +0000
+++ b/docs/Makefile	Fri Nov 25 11:52:48 2011 +0000
@@ -15,9 +15,13 @@ DOC_MARKDOWN	:= $(wildcard misc/*.markdo
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
 DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
-		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
-		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,txt/man/%.5.txt,$(DOC_MAN5SRC))
 
 GFX = $(patsubst %.fig, %.eps, $(wildcard figs/*.fig))
 
@@ -76,7 +80,7 @@ clean:
 	$(MAKE) -C xen-api clean
 	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
 	rm -rf *.ilg *.log *.ind *.toc *.bak core
-	rm -rf $(GFX) ps pdf html
+	rm -rf $(GFX) ps pdf html txt
 	rm -rf api
 	rm -rf man5
 	rm -rf man1
@@ -132,6 +136,16 @@ html/%.html: %.markdown
 	$(call move-if-changed,$@.tmp,$@) ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/man/%.1.html: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+html/man/%.5.html: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
@@ -141,3 +155,14 @@ txt/%.txt: %.markdown
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.1.txt: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.5.txt: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6r-0008N1-Rq; Fri, 25 Nov 2011 14:50:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6q-0008J9-22
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322232597!3042528!5
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25942 invoked from network); 25 Nov 2011 14:50:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:50:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407288"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:38 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXq5030497;	Fri, 25 Nov 2011 06:49:37 -0800
MIME-Version: 1.0
X-Mercurial-Node: 96479242221d8b58dde242442c47da2ab4c71a8f
Message-ID: <96479242221d8b58dde2.1322232576@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 04 of 15 v2] docs: install html and txt versions
	of manpages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322221968 0
# Node ID 96479242221d8b58dde242442c47da2ab4c71a8f
# Parent  224340062d194a2ef551402cdf79ecd92c34d8f3
docs: install html and txt versions of manpages

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 224340062d19 -r 96479242221d docs/Docs.mk
--- a/docs/Docs.mk	Fri Nov 25 11:52:46 2011 +0000
+++ b/docs/Docs.mk	Fri Nov 25 11:52:48 2011 +0000
@@ -5,6 +5,8 @@ FIG2DEV		:= fig2dev
 LATEX2HTML	:= latex2html
 DOXYGEN		:= doxygen
 POD2MAN		:= pod2man
+POD2HTML	:= pod2html
+POD2TEXT	:= pod2text
 DOT		:= dot
 NEATO		:= neato
 MARKDOWN	:= markdown
diff -r 224340062d19 -r 96479242221d docs/Makefile
--- a/docs/Makefile	Fri Nov 25 11:52:46 2011 +0000
+++ b/docs/Makefile	Fri Nov 25 11:52:48 2011 +0000
@@ -15,9 +15,13 @@ DOC_MARKDOWN	:= $(wildcard misc/*.markdo
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
 DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
-		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
-		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,txt/man/%.5.txt,$(DOC_MAN5SRC))
 
 GFX = $(patsubst %.fig, %.eps, $(wildcard figs/*.fig))
 
@@ -76,7 +80,7 @@ clean:
 	$(MAKE) -C xen-api clean
 	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
 	rm -rf *.ilg *.log *.ind *.toc *.bak core
-	rm -rf $(GFX) ps pdf html
+	rm -rf $(GFX) ps pdf html txt
 	rm -rf api
 	rm -rf man5
 	rm -rf man1
@@ -132,6 +136,16 @@ html/%.html: %.markdown
 	$(call move-if-changed,$@.tmp,$@) ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/man/%.1.html: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+html/man/%.5.html: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
@@ -141,3 +155,14 @@ txt/%.txt: %.markdown
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.1.txt: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.5.txt: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6p-0008LR-BD; Fri, 25 Nov 2011 14:50:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6n-0008II-33
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322232597!3042528!4
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25629 invoked from network); 25 Nov 2011 14:50:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:50:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407293"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:45 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqD030497;	Fri, 25 Nov 2011 06:49:44 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9e98f587da45fced29dc9c317f403f53e3fec904
Message-ID: <9e98f587da45fced29dc.1322232584@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 12 of 15 v2] docs: move user and interface .tex
 documents under reference
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322231662 0
# Node ID 9e98f587da45fced29dc9c317f403f53e3fec904
# Parent  00ea49f77bdcef16251e3773c99fc02394524b83
docs: move user and interface .tex documents under reference.

Taking over the top level "user" entry with a relatively obsolete document is a
bit of an annoyance but these docs are not so out of date that they should be
deleted. Move them out of the top-level instead.

(the original motivation here was to allow for user/xl-domain-cfg.markdown but
we have since decided to go with man/xl.cfg.pod.5 instead so perhaps this is a
waste of time)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 00ea49f77bdc -r 9e98f587da45 docs/INDEX
--- a/docs/INDEX	Fri Nov 25 14:34:21 2011 +0000
+++ b/docs/INDEX	Fri Nov 25 14:34:22 2011 +0000
@@ -1,5 +1,5 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
 # These are not all that useful anymore, hide them from the index
-interface/index			NO-INDEX
-user/index			NO-INDEX
+reference/interface/index	NO-INDEX
+reference/user/index		NO-INDEX
diff -r 00ea49f77bdc -r 9e98f587da45 docs/Makefile
--- a/docs/Makefile	Fri Nov 25 14:34:21 2011 +0000
+++ b/docs/Makefile	Fri Nov 25 14:34:22 2011 +0000
@@ -14,7 +14,7 @@ DOC_TEX		:= src/user.tex src/interface.t
 DOC_MARKDOWN	:= $(wildcard misc/*.markdown)
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
-DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
+DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
 		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
@@ -119,14 +119,14 @@ ps/%.ps: %.dvi
 %.eps: %.fig
 	$(FIG2DEV) -L eps $< $@
 
-html/%/index.html: src/%.tex
+html/reference/%/index.html: src/%.tex
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(LATEX2HTML) 1>/dev/null 2>/dev/null; then \
-        echo "Running latex2html to generate $*/index.html ... "; \
+        echo "Running latex2html to generate reference/$*/index.html ... "; \
 	$(LATEX2HTML) -split 0 -show_section_numbers -toc_depth 3 -nonavigation \
 	-numbered_footnotes -local_icons -noinfo -math -dir $(@D) \
 	$< 1>/dev/null 2>/dev/null ; else \
-	echo "latex2html not installed; skipping $*."; fi
+	echo "latex2html not installed; skipping reference/$*."; fi
 
 html/index.html: $(DOC_HTML) ./gen-html-index INDEX
 	./gen-html-index -i INDEX html $(DOC_HTML)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:50:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx6p-0008LR-BD; Fri, 25 Nov 2011 14:50:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTx6n-0008II-33
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:50:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322232597!3042528!4
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25629 invoked from network); 25 Nov 2011 14:50:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:50:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407293"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:49:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 09:49:45 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPEnXqD030497;	Fri, 25 Nov 2011 06:49:44 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9e98f587da45fced29dc9c317f403f53e3fec904
Message-ID: <9e98f587da45fced29dc.1322232584@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322232572@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:49:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 12 of 15 v2] docs: move user and interface .tex
 documents under reference
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322231662 0
# Node ID 9e98f587da45fced29dc9c317f403f53e3fec904
# Parent  00ea49f77bdcef16251e3773c99fc02394524b83
docs: move user and interface .tex documents under reference.

Taking over the top level "user" entry with a relatively obsolete document is a
bit of an annoyance but these docs are not so out of date that they should be
deleted. Move them out of the top-level instead.

(the original motivation here was to allow for user/xl-domain-cfg.markdown but
we have since decided to go with man/xl.cfg.pod.5 instead so perhaps this is a
waste of time)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 00ea49f77bdc -r 9e98f587da45 docs/INDEX
--- a/docs/INDEX	Fri Nov 25 14:34:21 2011 +0000
+++ b/docs/INDEX	Fri Nov 25 14:34:22 2011 +0000
@@ -1,5 +1,5 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
 # These are not all that useful anymore, hide them from the index
-interface/index			NO-INDEX
-user/index			NO-INDEX
+reference/interface/index	NO-INDEX
+reference/user/index		NO-INDEX
diff -r 00ea49f77bdc -r 9e98f587da45 docs/Makefile
--- a/docs/Makefile	Fri Nov 25 14:34:21 2011 +0000
+++ b/docs/Makefile	Fri Nov 25 14:34:22 2011 +0000
@@ -14,7 +14,7 @@ DOC_TEX		:= src/user.tex src/interface.t
 DOC_MARKDOWN	:= $(wildcard misc/*.markdown)
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
-DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
+DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
 		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
@@ -119,14 +119,14 @@ ps/%.ps: %.dvi
 %.eps: %.fig
 	$(FIG2DEV) -L eps $< $@
 
-html/%/index.html: src/%.tex
+html/reference/%/index.html: src/%.tex
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(LATEX2HTML) 1>/dev/null 2>/dev/null; then \
-        echo "Running latex2html to generate $*/index.html ... "; \
+        echo "Running latex2html to generate reference/$*/index.html ... "; \
 	$(LATEX2HTML) -split 0 -show_section_numbers -toc_depth 3 -nonavigation \
 	-numbered_footnotes -local_icons -noinfo -math -dir $(@D) \
 	$< 1>/dev/null 2>/dev/null ; else \
-	echo "latex2html not installed; skipping $*."; fi
+	echo "latex2html not installed; skipping reference/$*."; fi
 
 html/index.html: $(DOC_HTML) ./gen-html-index INDEX
 	./gen-html-index -i INDEX html $(DOC_HTML)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:51:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:51:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx80-0000it-CW; Fri, 25 Nov 2011 14:51:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTx7z-0000g1-80
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:51:47 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322232673!4641463!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24105 invoked from network); 25 Nov 2011 14:51:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:51:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407340"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:51:13 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 09:51:13 -0500
MIME-Version: 1.0
X-Mercurial-Node: a3c5e87c73a991861fcdd9a5a1eb8ebc635a2d09
Message-ID: <a3c5e87c73a991861fcd.1322232658@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:50:58 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix save/restore for HVM domains with viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322232651 0
# Node ID a3c5e87c73a991861fcdd9a5a1eb8ebc635a2d09
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Fix save/restore for HVM domains with viridian=1

xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
results in an HVM domain running a recent version on Windows (post-Vista)
locking up on a domain restore due to EOIs (done via a viridian MSR write)
being silently dropped.
This patch adds an extra save entry for the viridian parameter and also
adds code in the viridian kernel module to catch attempted use of viridian
functionality when the HVM parameter has not been set.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 14:50:51 2011 +0000
@@ -675,6 +675,7 @@ typedef struct {
     uint64_t vm86_tss;
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
+    uint64_t viridian;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_VIRIDIAN:
+        /* Skip padding 4 bytes then read the acpi ioport location. */
+        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
+        {
+            PERROR("error read the viridian flag");
+            return -1;
+        }
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
             fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
     }
 
+    if (pagebuf.viridian != 0)
+        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
+
     if (pagebuf.acpi_ioport_location == 1) {
         DBGPRINTF("Use new firmware ioport from the checkpoint\n");
         xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 14:50:51 2011 +0000
@@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
             PERROR("Error when writing the firmware ioport version");
             goto out;
         }
+
+        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the viridian flag");
+            goto out;
+        }
     }
 
     if ( !callbacks->checkpoint )
diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 14:50:51 2011 +0000
@@ -134,6 +134,7 @@
 #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
+#define XC_SAVE_ID_HVM_VIRIDIAN       -11
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 0a0c02a61676 -r a3c5e87c73a9 xen/arch/x86/hvm/viridian.c
--- a/xen/arch/x86/hvm/viridian.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/xen/arch/x86/hvm/viridian.c	Fri Nov 25 14:50:51 2011 +0000
@@ -206,8 +206,11 @@ int wrmsr_viridian_regs(uint32_t idx, ui
     struct vcpu *v = current;
     struct domain *d = v->domain;
 
-    if ( !is_viridian_domain(d) )
+    if ( !is_viridian_domain(d) ) {
+        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", __func__,
+                 d->domain_id);
         return 0;
+    }
 
     switch ( idx )
     {
@@ -271,8 +274,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui
     struct vcpu *v = current;
     struct domain *d = v->domain;
     
-    if ( !is_viridian_domain(d) )
+    if ( !is_viridian_domain(d) ) {
+        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", __func__,
+                 d->domain_id);
         return 0;
+    }
 
     switch ( idx )
     {
@@ -411,6 +417,8 @@ static int viridian_load_domain_ctxt(str
     if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
         return -EINVAL;
 
+    ASSERT(is_viridian_domain(d));
+
     d->arch.hvm_domain.viridian.hypercall_gpa.raw = ctxt.hypercall_gpa;
     d->arch.hvm_domain.viridian.guest_os_id.raw   = ctxt.guest_os_id;
 
@@ -455,6 +463,8 @@ static int viridian_load_vcpu_ctxt(struc
     if ( hvm_load_entry(VIRIDIAN_VCPU, h, &ctxt) != 0 )
         return -EINVAL;
 
+    ASSERT(is_viridian_domain(d));
+
     v->arch.hvm_vcpu.viridian.apic_assist.raw = ctxt.apic_assist;
 
     return 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:51:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:51:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx80-0000it-CW; Fri, 25 Nov 2011 14:51:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTx7z-0000g1-80
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:51:47 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322232673!4641463!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24105 invoked from network); 25 Nov 2011 14:51:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 14:51:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407340"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 09:51:13 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 09:51:13 -0500
MIME-Version: 1.0
X-Mercurial-Node: a3c5e87c73a991861fcdd9a5a1eb8ebc635a2d09
Message-ID: <a3c5e87c73a991861fcd.1322232658@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 14:50:58 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix save/restore for HVM domains with viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322232651 0
# Node ID a3c5e87c73a991861fcdd9a5a1eb8ebc635a2d09
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Fix save/restore for HVM domains with viridian=1

xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
results in an HVM domain running a recent version on Windows (post-Vista)
locking up on a domain restore due to EOIs (done via a viridian MSR write)
being silently dropped.
This patch adds an extra save entry for the viridian parameter and also
adds code in the viridian kernel module to catch attempted use of viridian
functionality when the HVM parameter has not been set.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 14:50:51 2011 +0000
@@ -675,6 +675,7 @@ typedef struct {
     uint64_t vm86_tss;
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
+    uint64_t viridian;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_VIRIDIAN:
+        /* Skip padding 4 bytes then read the acpi ioport location. */
+        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
+        {
+            PERROR("error read the viridian flag");
+            return -1;
+        }
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
             fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
     }
 
+    if (pagebuf.viridian != 0)
+        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
+
     if (pagebuf.acpi_ioport_location == 1) {
         DBGPRINTF("Use new firmware ioport from the checkpoint\n");
         xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 14:50:51 2011 +0000
@@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
             PERROR("Error when writing the firmware ioport version");
             goto out;
         }
+
+        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the viridian flag");
+            goto out;
+        }
     }
 
     if ( !callbacks->checkpoint )
diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 14:50:51 2011 +0000
@@ -134,6 +134,7 @@
 #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
+#define XC_SAVE_ID_HVM_VIRIDIAN       -11
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 0a0c02a61676 -r a3c5e87c73a9 xen/arch/x86/hvm/viridian.c
--- a/xen/arch/x86/hvm/viridian.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/xen/arch/x86/hvm/viridian.c	Fri Nov 25 14:50:51 2011 +0000
@@ -206,8 +206,11 @@ int wrmsr_viridian_regs(uint32_t idx, ui
     struct vcpu *v = current;
     struct domain *d = v->domain;
 
-    if ( !is_viridian_domain(d) )
+    if ( !is_viridian_domain(d) ) {
+        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", __func__,
+                 d->domain_id);
         return 0;
+    }
 
     switch ( idx )
     {
@@ -271,8 +274,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui
     struct vcpu *v = current;
     struct domain *d = v->domain;
     
-    if ( !is_viridian_domain(d) )
+    if ( !is_viridian_domain(d) ) {
+        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", __func__,
+                 d->domain_id);
         return 0;
+    }
 
     switch ( idx )
     {
@@ -411,6 +417,8 @@ static int viridian_load_domain_ctxt(str
     if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
         return -EINVAL;
 
+    ASSERT(is_viridian_domain(d));
+
     d->arch.hvm_domain.viridian.hypercall_gpa.raw = ctxt.hypercall_gpa;
     d->arch.hvm_domain.viridian.guest_os_id.raw   = ctxt.guest_os_id;
 
@@ -455,6 +463,8 @@ static int viridian_load_vcpu_ctxt(struc
     if ( hvm_load_entry(VIRIDIAN_VCPU, h, &ctxt) != 0 )
         return -EINVAL;
 
+    ASSERT(is_viridian_domain(d));
+
     v->arch.hvm_vcpu.viridian.apic_assist.raw = ctxt.apic_assist;
 
     return 0;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:53:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx9T-0001Te-Vz; Fri, 25 Nov 2011 14:53:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTx9S-0001RR-UR
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:53:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322232766!3051905!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14033 invoked from network); 25 Nov 2011 14:52:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 14:52:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 14:52:44 +0000
Message-Id: <4ECFB9CA020000780006354E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 14:52:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] booting HVM guest via passed through NIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

All,

is this supposed to work? If so, is it also known to work (in general or for
specific NICs)?

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:53:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTx9T-0001Te-Vz; Fri, 25 Nov 2011 14:53:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTx9S-0001RR-UR
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:53:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322232766!3051905!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14033 invoked from network); 25 Nov 2011 14:52:46 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 14:52:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 14:52:44 +0000
Message-Id: <4ECFB9CA020000780006354E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 14:52:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] booting HVM guest via passed through NIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

All,

is this supposed to work? If so, is it also known to work (in general or for
specific NICs)?

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:59:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxF3-0002hL-4E; Fri, 25 Nov 2011 14:59:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTxF2-0002hB-5C
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:59:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322233111!4948676!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23417 invoked from network); 25 Nov 2011 14:58:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 14:58:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 14:58:31 +0000
Message-Id: <4ECFBB26020000780006356F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 14:58:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <paul.durrant@citrix.com>
References: <a3c5e87c73a991861fcd.1322232658@cosworth.uk.xensource.com>
In-Reply-To: <a3c5e87c73a991861fcd.1322232658@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.11.11 at 15:50, Paul Durrant <paul.durrant@citrix.com> wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322232651 0
> # Node ID a3c5e87c73a991861fcdd9a5a1eb8ebc635a2d09
> # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> Fix save/restore for HVM domains with viridian=1
> 
> xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN 
> which
> results in an HVM domain running a recent version on Windows (post-Vista)
> locking up on a domain restore due to EOIs (done via a viridian MSR write)
> being silently dropped.
> This patch adds an extra save entry for the viridian parameter and also
> adds code in the viridian kernel module to catch attempted use of viridian
> functionality when the HVM parameter has not been set.

Assuming this means the changes to {rd,wr}msr_viridian_regs(), isn't
this going to needlessly spam the log? I.e. printing this just once (per
VM) would seem to suffice. Or alternatively I would think that
HVM_DBG_LOG() would be a better choice here.

Jan

> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -675,6 +675,7 @@ typedef struct {
>      uint64_t vm86_tss;
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
> +    uint64_t viridian;
>  } pagebuf_t;
>  
>  static int pagebuf_init(pagebuf_t* buf)
> @@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
>          }
>          return pagebuf_get_one(xch, ctx, buf, fd, dom);
>  
> +    case XC_SAVE_ID_HVM_VIRIDIAN:
> +        /* Skip padding 4 bytes then read the acpi ioport location. */
> +        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the viridian flag");
> +            return -1;
> +        }
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.", count);
> @@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
>              fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
>      }
>  
> +    if (pagebuf.viridian != 0)
> +        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
> +
>      if (pagebuf.acpi_ioport_location == 1) {
>          DBGPRINTF("Use new firmware ioport from the checkpoint\n");
>          xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
>              PERROR("Error when writing the firmware ioport version");
>              goto out;
>          }
> +
> +        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
> +        chunk.data = 0;
> +        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
> +                         (unsigned long *)&chunk.data);
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the viridian flag");
> +            goto out;
> +        }
>      }
>  
>      if ( !callbacks->checkpoint )
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 14:50:51 2011 +0000
> @@ -134,6 +134,7 @@
>  #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after 
> completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> +#define XC_SAVE_ID_HVM_VIRIDIAN       -11
>  
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff -r 0a0c02a61676 -r a3c5e87c73a9 xen/arch/x86/hvm/viridian.c
> --- a/xen/arch/x86/hvm/viridian.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/xen/arch/x86/hvm/viridian.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -206,8 +206,11 @@ int wrmsr_viridian_regs(uint32_t idx, ui
>      struct vcpu *v = current;
>      struct domain *d = v->domain;
>  
> -    if ( !is_viridian_domain(d) )
> +    if ( !is_viridian_domain(d) ) {
> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", 
> __func__,
> +                 d->domain_id);
>          return 0;
> +    }
>  
>      switch ( idx )
>      {
> @@ -271,8 +274,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui
>      struct vcpu *v = current;
>      struct domain *d = v->domain;
>      
> -    if ( !is_viridian_domain(d) )
> +    if ( !is_viridian_domain(d) ) {
> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", 
> __func__,
> +                 d->domain_id);
>          return 0;
> +    }
>  
>      switch ( idx )
>      {
> @@ -411,6 +417,8 @@ static int viridian_load_domain_ctxt(str
>      if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
>          return -EINVAL;
>  
> +    ASSERT(is_viridian_domain(d));
> +
>      d->arch.hvm_domain.viridian.hypercall_gpa.raw = ctxt.hypercall_gpa;
>      d->arch.hvm_domain.viridian.guest_os_id.raw   = ctxt.guest_os_id;
>  
> @@ -455,6 +463,8 @@ static int viridian_load_vcpu_ctxt(struc
>      if ( hvm_load_entry(VIRIDIAN_VCPU, h, &ctxt) != 0 )
>          return -EINVAL;
>  
> +    ASSERT(is_viridian_domain(d));
> +
>      v->arch.hvm_vcpu.viridian.apic_assist.raw = ctxt.apic_assist;
>  
>      return 0;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 14:59:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 14:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxF3-0002hL-4E; Fri, 25 Nov 2011 14:59:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTxF2-0002hB-5C
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 14:59:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322233111!4948676!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23417 invoked from network); 25 Nov 2011 14:58:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 14:58:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 14:58:31 +0000
Message-Id: <4ECFBB26020000780006356F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 14:58:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <paul.durrant@citrix.com>
References: <a3c5e87c73a991861fcd.1322232658@cosworth.uk.xensource.com>
In-Reply-To: <a3c5e87c73a991861fcd.1322232658@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.11.11 at 15:50, Paul Durrant <paul.durrant@citrix.com> wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322232651 0
> # Node ID a3c5e87c73a991861fcdd9a5a1eb8ebc635a2d09
> # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> Fix save/restore for HVM domains with viridian=1
> 
> xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN 
> which
> results in an HVM domain running a recent version on Windows (post-Vista)
> locking up on a domain restore due to EOIs (done via a viridian MSR write)
> being silently dropped.
> This patch adds an extra save entry for the viridian parameter and also
> adds code in the viridian kernel module to catch attempted use of viridian
> functionality when the HVM parameter has not been set.

Assuming this means the changes to {rd,wr}msr_viridian_regs(), isn't
this going to needlessly spam the log? I.e. printing this just once (per
VM) would seem to suffice. Or alternatively I would think that
HVM_DBG_LOG() would be a better choice here.

Jan

> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -675,6 +675,7 @@ typedef struct {
>      uint64_t vm86_tss;
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
> +    uint64_t viridian;
>  } pagebuf_t;
>  
>  static int pagebuf_init(pagebuf_t* buf)
> @@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
>          }
>          return pagebuf_get_one(xch, ctx, buf, fd, dom);
>  
> +    case XC_SAVE_ID_HVM_VIRIDIAN:
> +        /* Skip padding 4 bytes then read the acpi ioport location. */
> +        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the viridian flag");
> +            return -1;
> +        }
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.", count);
> @@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
>              fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
>      }
>  
> +    if (pagebuf.viridian != 0)
> +        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
> +
>      if (pagebuf.acpi_ioport_location == 1) {
>          DBGPRINTF("Use new firmware ioport from the checkpoint\n");
>          xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
>              PERROR("Error when writing the firmware ioport version");
>              goto out;
>          }
> +
> +        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
> +        chunk.data = 0;
> +        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
> +                         (unsigned long *)&chunk.data);
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the viridian flag");
> +            goto out;
> +        }
>      }
>  
>      if ( !callbacks->checkpoint )
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 14:50:51 2011 +0000
> @@ -134,6 +134,7 @@
>  #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after 
> completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> +#define XC_SAVE_ID_HVM_VIRIDIAN       -11
>  
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff -r 0a0c02a61676 -r a3c5e87c73a9 xen/arch/x86/hvm/viridian.c
> --- a/xen/arch/x86/hvm/viridian.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/xen/arch/x86/hvm/viridian.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -206,8 +206,11 @@ int wrmsr_viridian_regs(uint32_t idx, ui
>      struct vcpu *v = current;
>      struct domain *d = v->domain;
>  
> -    if ( !is_viridian_domain(d) )
> +    if ( !is_viridian_domain(d) ) {
> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", 
> __func__,
> +                 d->domain_id);
>          return 0;
> +    }
>  
>      switch ( idx )
>      {
> @@ -271,8 +274,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui
>      struct vcpu *v = current;
>      struct domain *d = v->domain;
>      
> -    if ( !is_viridian_domain(d) )
> +    if ( !is_viridian_domain(d) ) {
> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", 
> __func__,
> +                 d->domain_id);
>          return 0;
> +    }
>  
>      switch ( idx )
>      {
> @@ -411,6 +417,8 @@ static int viridian_load_domain_ctxt(str
>      if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
>          return -EINVAL;
>  
> +    ASSERT(is_viridian_domain(d));
> +
>      d->arch.hvm_domain.viridian.hypercall_gpa.raw = ctxt.hypercall_gpa;
>      d->arch.hvm_domain.viridian.guest_os_id.raw   = ctxt.guest_os_id;
>  
> @@ -455,6 +463,8 @@ static int viridian_load_vcpu_ctxt(struc
>      if ( hvm_load_entry(VIRIDIAN_VCPU, h, &ctxt) != 0 )
>          return -EINVAL;
>  
> +    ASSERT(is_viridian_domain(d));
> +
>      v->arch.hvm_vcpu.viridian.apic_assist.raw = ctxt.apic_assist;
>  
>      return 0;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:01:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxH4-0002rz-MI; Fri, 25 Nov 2011 15:01:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTxH3-0002rc-F5
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:01:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322233237!4646379!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22818 invoked from network); 25 Nov 2011 15:00:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 15:00:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTxGV-0001iU-M3; Fri, 25 Nov 2011 15:00:35 +0000
Date: Fri, 25 Nov 2011 15:00:35 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20111125150035.GA6475@ocelot.phlegethon.org>
References: <a3c5e87c73a991861fcd.1322232658@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a3c5e87c73a991861fcd.1322232658@cosworth.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:50 +0000 on 25 Nov (1322232658), Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322232651 0
> # Node ID a3c5e87c73a991861fcdd9a5a1eb8ebc635a2d09
> # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> Fix save/restore for HVM domains with viridian=1
> 
> xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
> results in an HVM domain running a recent version on Windows (post-Vista)
> locking up on a domain restore due to EOIs (done via a viridian MSR write)
> being silently dropped.
> This patch adds an extra save entry for the viridian parameter and also
> adds code in the viridian kernel module to catch attempted use of viridian
> functionality when the HVM parameter has not been set.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -675,6 +675,7 @@ typedef struct {
>      uint64_t vm86_tss;
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
> +    uint64_t viridian;
>  } pagebuf_t;
>  
>  static int pagebuf_init(pagebuf_t* buf)
> @@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
>          }
>          return pagebuf_get_one(xch, ctx, buf, fd, dom);
>  
> +    case XC_SAVE_ID_HVM_VIRIDIAN:
> +        /* Skip padding 4 bytes then read the acpi ioport location. */

Ahem.                                            ^^^^^^^^^^^^^^^^^^^^

> +        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the viridian flag");
> +            return -1;
> +        }
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.", count);
> @@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
>              fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
>      }
>  
> +    if (pagebuf.viridian != 0)
> +        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
> +
>      if (pagebuf.acpi_ioport_location == 1) {
>          DBGPRINTF("Use new firmware ioport from the checkpoint\n");
>          xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
>              PERROR("Error when writing the firmware ioport version");
>              goto out;
>          }
> +
> +        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
> +        chunk.data = 0;
> +        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
> +                         (unsigned long *)&chunk.data);
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the viridian flag");
> +            goto out;
> +        }
>      }
>  
>      if ( !callbacks->checkpoint )
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 14:50:51 2011 +0000
> @@ -134,6 +134,7 @@
>  #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> +#define XC_SAVE_ID_HVM_VIRIDIAN       -11
>  
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff -r 0a0c02a61676 -r a3c5e87c73a9 xen/arch/x86/hvm/viridian.c
> --- a/xen/arch/x86/hvm/viridian.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/xen/arch/x86/hvm/viridian.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -206,8 +206,11 @@ int wrmsr_viridian_regs(uint32_t idx, ui
>      struct vcpu *v = current;
>      struct domain *d = v->domain;
>  
> -    if ( !is_viridian_domain(d) )
> +    if ( !is_viridian_domain(d) ) {
> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", __func__,
> +                 d->domain_id);

This should probably be rate-limited; a confused domain could cause a
_lot_ of these.  Might we want to pause/kill the domain as well, or
inject a fault?

>          return 0;
> +    }
>  
>      switch ( idx )
>      {
> @@ -271,8 +274,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui
>      struct vcpu *v = current;
>      struct domain *d = v->domain;
>      
> -    if ( !is_viridian_domain(d) )
> +    if ( !is_viridian_domain(d) ) {
> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", __func__,
> +                 d->domain_id);

Likewise.

>          return 0;
> +    }
>  
>      switch ( idx )
>      {
> @@ -411,6 +417,8 @@ static int viridian_load_domain_ctxt(str
>      if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
>          return -EINVAL;
>  
> +    ASSERT(is_viridian_domain(d));
> +

I don't think it's appropriate to crash Xen if the save file is bogus. 

>      d->arch.hvm_domain.viridian.hypercall_gpa.raw = ctxt.hypercall_gpa;
>      d->arch.hvm_domain.viridian.guest_os_id.raw   = ctxt.guest_os_id;
>  
> @@ -455,6 +463,8 @@ static int viridian_load_vcpu_ctxt(struc
>      if ( hvm_load_entry(VIRIDIAN_VCPU, h, &ctxt) != 0 )
>          return -EINVAL;
>  
> +    ASSERT(is_viridian_domain(d));
> +

Likewise.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:01:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:01:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxH4-0002rz-MI; Fri, 25 Nov 2011 15:01:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTxH3-0002rc-F5
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:01:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322233237!4646379!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22818 invoked from network); 25 Nov 2011 15:00:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 15:00:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTxGV-0001iU-M3; Fri, 25 Nov 2011 15:00:35 +0000
Date: Fri, 25 Nov 2011 15:00:35 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20111125150035.GA6475@ocelot.phlegethon.org>
References: <a3c5e87c73a991861fcd.1322232658@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a3c5e87c73a991861fcd.1322232658@cosworth.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:50 +0000 on 25 Nov (1322232658), Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322232651 0
> # Node ID a3c5e87c73a991861fcdd9a5a1eb8ebc635a2d09
> # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> Fix save/restore for HVM domains with viridian=1
> 
> xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
> results in an HVM domain running a recent version on Windows (post-Vista)
> locking up on a domain restore due to EOIs (done via a viridian MSR write)
> being silently dropped.
> This patch adds an extra save entry for the viridian parameter and also
> adds code in the viridian kernel module to catch attempted use of viridian
> functionality when the HVM parameter has not been set.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -675,6 +675,7 @@ typedef struct {
>      uint64_t vm86_tss;
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
> +    uint64_t viridian;
>  } pagebuf_t;
>  
>  static int pagebuf_init(pagebuf_t* buf)
> @@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
>          }
>          return pagebuf_get_one(xch, ctx, buf, fd, dom);
>  
> +    case XC_SAVE_ID_HVM_VIRIDIAN:
> +        /* Skip padding 4 bytes then read the acpi ioport location. */

Ahem.                                            ^^^^^^^^^^^^^^^^^^^^

> +        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the viridian flag");
> +            return -1;
> +        }
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.", count);
> @@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
>              fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
>      }
>  
> +    if (pagebuf.viridian != 0)
> +        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
> +
>      if (pagebuf.acpi_ioport_location == 1) {
>          DBGPRINTF("Use new firmware ioport from the checkpoint\n");
>          xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
>              PERROR("Error when writing the firmware ioport version");
>              goto out;
>          }
> +
> +        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
> +        chunk.data = 0;
> +        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
> +                         (unsigned long *)&chunk.data);
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the viridian flag");
> +            goto out;
> +        }
>      }
>  
>      if ( !callbacks->checkpoint )
> diff -r 0a0c02a61676 -r a3c5e87c73a9 tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 14:50:51 2011 +0000
> @@ -134,6 +134,7 @@
>  #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> +#define XC_SAVE_ID_HVM_VIRIDIAN       -11
>  
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff -r 0a0c02a61676 -r a3c5e87c73a9 xen/arch/x86/hvm/viridian.c
> --- a/xen/arch/x86/hvm/viridian.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/xen/arch/x86/hvm/viridian.c	Fri Nov 25 14:50:51 2011 +0000
> @@ -206,8 +206,11 @@ int wrmsr_viridian_regs(uint32_t idx, ui
>      struct vcpu *v = current;
>      struct domain *d = v->domain;
>  
> -    if ( !is_viridian_domain(d) )
> +    if ( !is_viridian_domain(d) ) {
> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", __func__,
> +                 d->domain_id);

This should probably be rate-limited; a confused domain could cause a
_lot_ of these.  Might we want to pause/kill the domain as well, or
inject a fault?

>          return 0;
> +    }
>  
>      switch ( idx )
>      {
> @@ -271,8 +274,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui
>      struct vcpu *v = current;
>      struct domain *d = v->domain;
>      
> -    if ( !is_viridian_domain(d) )
> +    if ( !is_viridian_domain(d) ) {
> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", __func__,
> +                 d->domain_id);

Likewise.

>          return 0;
> +    }
>  
>      switch ( idx )
>      {
> @@ -411,6 +417,8 @@ static int viridian_load_domain_ctxt(str
>      if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
>          return -EINVAL;
>  
> +    ASSERT(is_viridian_domain(d));
> +

I don't think it's appropriate to crash Xen if the save file is bogus. 

>      d->arch.hvm_domain.viridian.hypercall_gpa.raw = ctxt.hypercall_gpa;
>      d->arch.hvm_domain.viridian.guest_os_id.raw   = ctxt.guest_os_id;
>  
> @@ -455,6 +463,8 @@ static int viridian_load_vcpu_ctxt(struc
>      if ( hvm_load_entry(VIRIDIAN_VCPU, h, &ctxt) != 0 )
>          return -EINVAL;
>  
> +    ASSERT(is_viridian_domain(d));
> +

Likewise.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:04:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxJl-000333-IV; Fri, 25 Nov 2011 15:03:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTxJk-00032k-2L
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:03:56 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322233402!4914711!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18745 invoked from network); 25 Nov 2011 15:03:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:03:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407527"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:03:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 10:03:21 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAPF3KEN030575;	Fri, 25 Nov 2011 07:03:20 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>, Xen Devel
	<xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 15:03:15 +0000
Message-ID: <1322233395-29575-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH] xl: Apply CLOEXEC to the restore_fd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At restore time, the file descriptor open on the migration state file is still
open in the device model. Let apply FD_CLOEXEC to it.

This patch provide libxl_fd_set_cloexec to users of libxl, instead of keeping
this function internal.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 tools/libxl/libxl.c          |   13 +++++++++++++
 tools/libxl/libxl.h          |    3 +++
 tools/libxl/libxl_internal.c |   13 -------------
 tools/libxl/libxl_internal.h |    1 -
 tools/libxl/libxl_qmp.c      |    2 +-
 tools/libxl/xl_cmdimpl.c     |    1 +
 6 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a171142..de35adf 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3330,6 +3330,19 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     return 0;
 }
 
+int libxl_fd_set_cloexec(int fd)
+{
+    int flags = 0;
+
+    if ((flags = fcntl(fd, F_GETFD)) == -1) {
+        flags = 0;
+    }
+    if ((flags & FD_CLOEXEC)) {
+        return 0;
+    }
+    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6ce3d83..2015051 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -634,6 +634,9 @@ const char *libxl_xen_script_dir_path(void);
 const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 
+/* misc */
+int libxl_fd_set_cloexec(int fd);
+
 #endif /* LIBXL_H */
 
 /*
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..028f90f 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -306,19 +306,6 @@ _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b)
     return 0;
 }
 
-int libxl__fd_set_cloexec(int fd)
-{
-    int flags = 0;
-
-    if ((flags = fcntl(fd, F_GETFD)) == -1) {
-        flags = 0;
-    }
-    if ((flags & FD_CLOEXEC)) {
-        return 0;
-    }
-    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
-}
-
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..6ce34fd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -503,7 +503,6 @@ _hidden int libxl__error_set(libxl__gc *gc, int code);
 
 _hidden int libxl__file_reference_map(libxl_file_reference *f);
 _hidden int libxl__file_reference_unmap(libxl_file_reference *f);
-_hidden int libxl__fd_set_cloexec(int fd);
 
 _hidden int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..66a0134 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -324,7 +324,7 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
     if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
         return -1;
     }
-    libxl__fd_set_cloexec(qmp->qmp_fd);
+    libxl_fd_set_cloexec(qmp->qmp_fd);
 
     memset(&qmp->addr, 0, sizeof (&qmp->addr));
     qmp->addr.sun_family = AF_UNIX;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 080aa2b..8bdfc32 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1382,6 +1382,7 @@ static int create_domain(struct domain_create *dom_info)
 
         restore_fd = migrate_fd >= 0 ? migrate_fd :
             open(restore_file, O_RDONLY);
+        libxl_fd_set_cloexec(restore_fd);
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
                    sizeof(hdr), restore_file, "header") );
-- 
tg: (fa8754d..) fix/close-migration-state (depends on: master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:04:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:04:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxJl-000333-IV; Fri, 25 Nov 2011 15:03:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RTxJk-00032k-2L
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:03:56 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322233402!4914711!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18745 invoked from network); 25 Nov 2011 15:03:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:03:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19407527"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:03:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 10:03:21 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAPF3KEN030575;	Fri, 25 Nov 2011 07:03:20 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>, Xen Devel
	<xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 15:03:15 +0000
Message-ID: <1322233395-29575-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH] xl: Apply CLOEXEC to the restore_fd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At restore time, the file descriptor open on the migration state file is still
open in the device model. Let apply FD_CLOEXEC to it.

This patch provide libxl_fd_set_cloexec to users of libxl, instead of keeping
this function internal.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 tools/libxl/libxl.c          |   13 +++++++++++++
 tools/libxl/libxl.h          |    3 +++
 tools/libxl/libxl_internal.c |   13 -------------
 tools/libxl/libxl_internal.h |    1 -
 tools/libxl/libxl_qmp.c      |    2 +-
 tools/libxl/xl_cmdimpl.c     |    1 +
 6 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a171142..de35adf 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3330,6 +3330,19 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     return 0;
 }
 
+int libxl_fd_set_cloexec(int fd)
+{
+    int flags = 0;
+
+    if ((flags = fcntl(fd, F_GETFD)) == -1) {
+        flags = 0;
+    }
+    if ((flags & FD_CLOEXEC)) {
+        return 0;
+    }
+    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6ce3d83..2015051 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -634,6 +634,9 @@ const char *libxl_xen_script_dir_path(void);
 const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 
+/* misc */
+int libxl_fd_set_cloexec(int fd);
+
 #endif /* LIBXL_H */
 
 /*
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..028f90f 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -306,19 +306,6 @@ _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b)
     return 0;
 }
 
-int libxl__fd_set_cloexec(int fd)
-{
-    int flags = 0;
-
-    if ((flags = fcntl(fd, F_GETFD)) == -1) {
-        flags = 0;
-    }
-    if ((flags & FD_CLOEXEC)) {
-        return 0;
-    }
-    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
-}
-
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..6ce34fd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -503,7 +503,6 @@ _hidden int libxl__error_set(libxl__gc *gc, int code);
 
 _hidden int libxl__file_reference_map(libxl_file_reference *f);
 _hidden int libxl__file_reference_unmap(libxl_file_reference *f);
-_hidden int libxl__fd_set_cloexec(int fd);
 
 _hidden int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..66a0134 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -324,7 +324,7 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
     if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
         return -1;
     }
-    libxl__fd_set_cloexec(qmp->qmp_fd);
+    libxl_fd_set_cloexec(qmp->qmp_fd);
 
     memset(&qmp->addr, 0, sizeof (&qmp->addr));
     qmp->addr.sun_family = AF_UNIX;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 080aa2b..8bdfc32 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1382,6 +1382,7 @@ static int create_domain(struct domain_create *dom_info)
 
         restore_fd = migrate_fd >= 0 ? migrate_fd :
             open(restore_file, O_RDONLY);
+        libxl_fd_set_cloexec(restore_fd);
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
                    sizeof(hdr), restore_file, "header") );
-- 
tg: (fa8754d..) fix/close-migration-state (depends on: master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:06:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:06:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxM2-0003DU-5L; Fri, 25 Nov 2011 15:06:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTxM0-0003DC-Jw
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:06:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322233544!4640670!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32613 invoked from network); 25 Nov 2011 15:05:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9132956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:05:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 15:05:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 15:05:43 +0000
In-Reply-To: <08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322233543.1005.261.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document describing
 the xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul,

On Fri, 2011-11-25 at 14:49 +0000, Ian Campbell wrote:
> 
> +=item B<viridian=BOOLEAN>
> +
> +Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
> +compatible enlightenments to the guest.  These can improve
> performance
> +of Microsoft Windows guests (XXX which versions of Windows benefit?) 

Is there anything else we can say here? What are the first versions of
Windows which benefit from this?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:06:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:06:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxM2-0003DU-5L; Fri, 25 Nov 2011 15:06:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTxM0-0003DC-Jw
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:06:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322233544!4640670!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32613 invoked from network); 25 Nov 2011 15:05:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:05:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9132956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:05:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 15:05:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 15:05:43 +0000
In-Reply-To: <08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322233543.1005.261.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document describing
 the xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul,

On Fri, 2011-11-25 at 14:49 +0000, Ian Campbell wrote:
> 
> +=item B<viridian=BOOLEAN>
> +
> +Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
> +compatible enlightenments to the guest.  These can improve
> performance
> +of Microsoft Windows guests (XXX which versions of Windows benefit?) 

Is there anything else we can say here? What are the first versions of
Windows which benefit from this?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:12:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:12:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxRp-0003QU-1k; Fri, 25 Nov 2011 15:12:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTxRm-0003QP-V6
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:12:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322233901!5020513!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17095 invoked from network); 25 Nov 2011 15:11:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:11:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171876101"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:11:41 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 10:11:40 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPFBc9w030578;	Fri, 25 Nov 2011 07:11:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: b4c07fbe3557ae501fc2d8a21b41f1b1cd5198cb
Message-ID: <b4c07fbe3557ae501fc2.1322233898@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 15:11:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] docs: xlexample.hvm: mention the viridian
	setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322233890 0
# Node ID b4c07fbe3557ae501fc2d8a21b41f1b1cd5198cb
# Parent  31e71820ce93b72b0223882f6c2e1f461920bda9
docs: xlexample.hvm: mention the viridian setting.

Turning this on for Windows guests is recommended.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 31e71820ce93 -r b4c07fbe3557 tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Fri Nov 25 14:44:10 2011 +0000
+++ b/tools/examples/xlexample.hvm	Fri Nov 25 15:11:30 2011 +0000
@@ -16,6 +16,11 @@ name = "example.hvm"
 # The default behavior is to generate a new UUID each time the guest is started.
 #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
 
+# Enable Microsoft Hyper-V compatibile paravirtualisation /
+# enlightenment interfaces. Turning this on can improve Windows guest
+# performance and is therefore recommended
+#viridian = 1
+
 # Initial memory allocation (MB)
 memory = 128
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:12:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:12:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxRp-0003QU-1k; Fri, 25 Nov 2011 15:12:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTxRm-0003QP-V6
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:12:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322233901!5020513!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17095 invoked from network); 25 Nov 2011 15:11:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:11:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171876101"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:11:41 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 10:11:40 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pAPFBc9w030578;	Fri, 25 Nov 2011 07:11:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: b4c07fbe3557ae501fc2d8a21b41f1b1cd5198cb
Message-ID: <b4c07fbe3557ae501fc2.1322233898@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 15:11:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] docs: xlexample.hvm: mention the viridian
	setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322233890 0
# Node ID b4c07fbe3557ae501fc2d8a21b41f1b1cd5198cb
# Parent  31e71820ce93b72b0223882f6c2e1f461920bda9
docs: xlexample.hvm: mention the viridian setting.

Turning this on for Windows guests is recommended.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 31e71820ce93 -r b4c07fbe3557 tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Fri Nov 25 14:44:10 2011 +0000
+++ b/tools/examples/xlexample.hvm	Fri Nov 25 15:11:30 2011 +0000
@@ -16,6 +16,11 @@ name = "example.hvm"
 # The default behavior is to generate a new UUID each time the guest is started.
 #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
 
+# Enable Microsoft Hyper-V compatibile paravirtualisation /
+# enlightenment interfaces. Turning this on can improve Windows guest
+# performance and is therefore recommended
+#viridian = 1
+
 # Initial memory allocation (MB)
 memory = 128
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:13:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxSb-0003TI-Fk; Fri, 25 Nov 2011 15:13:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RTxSa-0003T1-45
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:13:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322233950!5017416!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19386 invoked from network); 25 Nov 2011 15:12:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:12:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171876147"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:12:30 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	10:12:29 -0500
Message-ID: <4ECFB05B.2060501@citrix.com>
Date: Fri, 25 Nov 2011 15:12:27 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan
	Beulich <JBeulich@novell.com>, Keir Fraser <keir.xen@gmail.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------080404090301050001090008"
Subject: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for the
	crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------080404090301050001090008
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------080404090301050001090008
Content-Type: text/x-patch; name="fix-range-choice-logic.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="fix-range-choice-logic.patch"

# HG changeset patch
# Parent 031be098e227bc0dcceef880a1a4c8f9c81647df
KEXEC: Clean up logic to choose a range for the crash kernel.

This is a fairly large change but I can't see an easy way to split it
up without things breaking.

Before this patch, using "classic" crashdump= syntax (<size>@<start>)
causes an exact size and location to be reserved in the e820 map
before Xen and modules are relocated.  However, using "new" syntax
(<start>-[<end>]:<size>) encounteres a myriad of problems, most
notibly not considering the range when allocating its region.

This patch tries to unify both codepaths, and fix the broken logic
when using "newer" syntax.

Changes addressed:

1) Remove use of kexec_crash_area from parse_crashkernel().
     Use ranges[0] in preference, as there is no support for multiple
     ranges using classic syntax.  This prevents some wierd logic in
     __setup_xen() depending on whether kexec_crash_area.size is set
     or not.

2) Change set_kexec_crash_area_size() to choose_kexec_range()
     The new method of choosing a range provides an entire rather than
     just setting kexec_crash_area.size.  Also, fix the very broken
     logic which will only consider a range if its .end is greater
     than system_ram.  Additionally, prefer range with the largest
     size if we have a choice of valid ones, and prefer ranges with
     more flexibility in their limits.

3) Move kexec_reserve_area() from setup.c to kexec.c
     It makes more sense here, Also, change its functionality a little
     to always work from the kexec range provided by choose_kexec_range()

4) Remove the kexec reservation code when considering modules
     This code only had any effect for people using the "newer" syntax
     on the command line, as people using the "classic" syntax would
     reserve a memory region before considering modules.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 0a0c02a61676 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -482,32 +482,6 @@ static void __init parse_video_info(void
     }
 }
 
-static void __init kexec_reserve_area(struct e820map *e820)
-{
-    unsigned long kdump_start = kexec_crash_area.start;
-    unsigned long kdump_size  = kexec_crash_area.size;
-    static int is_reserved = 0;
-
-    kdump_size = (kdump_size + PAGE_SIZE - 1) & PAGE_MASK;
-
-    if ( (kdump_start == 0) || (kdump_size == 0) || is_reserved )
-        return;
-
-    is_reserved = 1;
-
-    if ( !reserve_e820_ram(e820, kdump_start, kdump_start + kdump_size) )
-    {
-        printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) at 0x%lx)"
-               "\n", kdump_size >> 20, kdump_size >> 10, kdump_start);
-        kexec_crash_area.start = kexec_crash_area.size = 0;
-    }
-    else
-    {
-        printk("Kdump: %luMB (%lukB) at 0x%lx\n",
-               kdump_size >> 20, kdump_size >> 10, kdump_start);
-    }
-}
-
 void init_done(void)
 {
     /* Free (or page-protect) the init areas. */
@@ -759,13 +733,15 @@ void __init __start_xen(unsigned long mb
     /* Create a temporary copy of the E820 map. */
     memcpy(&boot_e820, &e820, sizeof(e820));
 
-    /* Early kexec reservation (explicit static start address). */
+    /* Calculate nr_pages from the e820 map. */
     nr_pages = 0;
     for ( i = 0; i < e820.nr_map; i++ )
         if ( e820.map[i].type == E820_RAM )
             nr_pages += e820.map[i].size >> PAGE_SHIFT;
-    set_kexec_crash_area_size((u64)nr_pages << PAGE_SHIFT);
-    kexec_reserve_area(&boot_e820);
+
+    /* Early kexec reservation. */
+    if( choose_kexec_range((u64)nr_pages << PAGE_SHIFT) )
+        kexec_reserve_area(&boot_e820);
 
     initial_images = mod;
     nr_initial_images = mbi->mods_count;
@@ -939,19 +915,6 @@ void __init __start_xen(unsigned long mb
                 mod[j].reserved = 1;
             }
         }
-
-#ifdef CONFIG_X86_32
-        /* Confine the kexec area to below 4Gb. */
-        e = min_t(uint64_t, e, 1ULL << 32);
-#endif
-        /* Don't overlap with modules. */
-        e = consider_modules(s, e, PAGE_ALIGN(kexec_crash_area.size),
-                             mod, mbi->mods_count, -1);
-        if ( !kexec_crash_area.start && (s < e) )
-        {
-            e = (e - kexec_crash_area.size) & PAGE_MASK;
-            kexec_crash_area.start = e;
-        }
     }
 
     if ( modules_headroom && !mod->reserved )
diff -r 0a0c02a61676 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -51,10 +51,22 @@ static unsigned char vmcoreinfo_data[VMC
 static size_t vmcoreinfo_size = 0;
 
 xen_kexec_reserve_t kexec_crash_area;
-static struct {
-    u64 start, end;
-    unsigned long size;
-} ranges[16] __initdata;
+
+/* Structure to contain kexec memory regions, as provided by the
+   crashkernel= command line parameter.  The meaining is a region of
+   size byte anywhere in the range start to end.  Therefore,
+   size <= (end - start) */
+struct kexec_boot_range {
+    u64 start, end, size;
+};
+
+/* Possible regions for the crashdump kernel region, parsed from the
+ * "crashkernel=foo" command line option. */
+static struct kexec_boot_range ranges[16] __initdata;
+
+/* Our chosen range to place the crashdump kernel, taking into account
+ * system memory. */
+static struct kexec_boot_range * kexec_range __initdata = NULL;
 
 /*
  * Parse command lines in the format
@@ -126,32 +138,126 @@ static void __init parse_crashkernel(con
             ranges[idx].size = 0;
     }
     else
-        kexec_crash_area.size = parse_size_and_unit(cur = str, &str);
+        ranges[0].size = parse_size_and_unit(cur = str, &str);
     if ( cur != str && *str == '@' )
-        kexec_crash_area.start = parse_size_and_unit(cur = str + 1, &str);
+    {
+        ranges[0].start = parse_size_and_unit(cur = str + 1, &str);
+        ranges[0].end = ranges[0].start + ranges[0].size;
+    }
     if ( cur == str )
+    {
         printk(XENLOG_WARNING "crashkernel: memory value expected\n");
+        ranges[0].size = 0;
+    }
 }
 custom_param("crashkernel", parse_crashkernel);
 
-void __init set_kexec_crash_area_size(u64 system_ram)
+/* Using system ram as a guide, choice one of the possible ranges to
+   use.  Return boolean indicating whether a range has been chosen or
+   not. */
+bool_t __init choose_kexec_range(u64 system_ram)
 {
     unsigned int idx;
+    struct kexec_boot_range * best_choice = NULL;
 
-    for ( idx = 0; idx < ARRAY_SIZE(ranges) && !kexec_crash_area.size; ++idx )
+    for ( idx = 0; idx < ARRAY_SIZE(ranges); ++idx )
     {
+        /* size == 0 indicates invalid range. */
         if ( !ranges[idx].size )
             break;
 
-        if ( ranges[idx].size >= system_ram )
+        /* PAGE_ALIGN each of the values. */
+        ranges[idx].start = PAGE_ALIGN(ranges[idx].start);
+        ranges[idx].size = PAGE_ALIGN(ranges[idx].size);
+        if ( ranges[idx].end != -1 )
+            ranges[idx].end = PAGE_ALIGN(ranges[idx].end);
+
+        /* Check that the size can actually fit in the region provided. */
+        if ( (ranges[idx].end - ranges[idx].start) < ranges[idx].size )
+            continue;
+
+        /* Check that the ranges size will fit inside its ends. */
+        if ( (ranges[idx].end - ranges[idx].start) < ranges[idx].size )
         {
-            printk(XENLOG_WARNING "crashkernel: invalid size\n");
+            printk(XENLOG_WARNING "crashkernel: range %d size bigger than "
+                   "defined range\n", idx);
             continue;
         }
 
-        if ( ranges[idx].start <= system_ram && ranges[idx].end > system_ram )
-            kexec_crash_area.size = ranges[idx].size;
+        /* Check that the range will fit in memory. */
+        if ( ranges[idx].start + ranges[idx].size <= system_ram )
+        {
+            /* Prefer regions with a larger size if we have a choice, and
+               prefer regions with more flexibility in its range. */
+            if ( !best_choice || (ranges[idx].size > best_choice->size) ||
+                 ((ranges[idx].end - ranges[idx].start) > 
+                  (best_choice->end - best_choice->start)) )
+                best_choice = &ranges[idx];
+        }
+        /* else complain. */
+        else
+            printk(XENLOG_WARNING "crashkernel: range %d size bigger than "
+                   "available ram\n", idx);
     }
+
+    kexec_range = best_choice;
+    return best_choice != NULL;
+}
+
+/* Reserve an area in the e820 map for the kexec region. */
+void __init kexec_reserve_area(struct e820map *e820)
+{
+    static bool_t is_reserved = FALSE;
+    unsigned long kexec_start, kexec_size;
+    int i;
+
+    /* Do we have a chosen range, or have we already reserved an
+       area? */
+    if ( ! kexec_range || is_reserved )
+        return;
+
+    for ( i = 0; i < e820->nr_map; ++i )
+    {
+        /* We dont want to allocate in any non RAM regions. */
+        if ( e820->map[i].type != E820_RAM )
+            continue;
+
+        /* Check that the e820 region is big enough to fit the kexec
+           region. */
+        if ( (kexec_range->size >= e820->map[i].size) ||
+             (kexec_range->start + kexec_range->size) >
+             (e820->map[i].addr + e820->map[i].size) )
+            continue;
+
+        kexec_start = max_t(u64, kexec_range->start, e820->map[i].addr);
+
+        /* If we have to start the kexec region higher in memory because
+           of the start of the e820 region, check that we still respect
+           the specified end of kexec region. */
+        if ( kexec_range->size > (kexec_range->end - kexec_start) )
+            continue;
+
+        is_reserved = TRUE;
+        kexec_size = kexec_range->size;
+
+        /* Try to reserve this region in the e820. On failure, we just might
+           be able to successfully reserve a region in a later RAM block. */
+        if ( reserve_e820_ram(e820, kexec_start, kexec_start + kexec_size) )
+        {
+            printk("Kdump: %luMB (%lukB) at 0x%lx\n",
+                   kexec_size >> 20, kexec_size >> 10, kexec_start);
+            kexec_crash_area.start = kexec_start;
+            kexec_crash_area.size = kexec_size;
+            return;
+        }
+    }
+    
+    /* If we fail to find a valid region, or fail ro reserve one, complain
+       to the console. */
+    printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) in range 0x%lx "
+           "-> 0x%lx\n", kexec_range->size >> 20, kexec_range->size >> 10,
+           kexec_range->start, kexec_range->end );
+    kexec_crash_area.start = kexec_crash_area.size = 0;
 }
 
 static void one_cpu_only(void)
diff -r 0a0c02a61676 xen/include/xen/kexec.h
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -4,6 +4,7 @@
 #include <public/kexec.h>
 #include <asm/percpu.h>
 #include <xen/elfcore.h>
+#include <asm/e820.h>
 
 typedef struct xen_kexec_reserve {
     unsigned long size;
@@ -14,7 +15,8 @@ extern xen_kexec_reserve_t kexec_crash_a
 
 extern bool_t kexecing;
 
-void set_kexec_crash_area_size(u64 system_ram);
+bool_t choose_kexec_range(u64 system_ram);
+void kexec_reserve_area(struct e820map *e820);
 
 /* We have space for 4 images to support atomic update
  * of images. This is important for CRASH images since

--------------080404090301050001090008
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------080404090301050001090008--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:13:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxSb-0003TI-Fk; Fri, 25 Nov 2011 15:13:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RTxSa-0003T1-45
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:13:04 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322233950!5017416!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19386 invoked from network); 25 Nov 2011 15:12:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:12:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171876147"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:12:30 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	10:12:29 -0500
Message-ID: <4ECFB05B.2060501@citrix.com>
Date: Fri, 25 Nov 2011 15:12:27 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan
	Beulich <JBeulich@novell.com>, Keir Fraser <keir.xen@gmail.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------080404090301050001090008"
Subject: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for the
	crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------080404090301050001090008
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------080404090301050001090008
Content-Type: text/x-patch; name="fix-range-choice-logic.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="fix-range-choice-logic.patch"

# HG changeset patch
# Parent 031be098e227bc0dcceef880a1a4c8f9c81647df
KEXEC: Clean up logic to choose a range for the crash kernel.

This is a fairly large change but I can't see an easy way to split it
up without things breaking.

Before this patch, using "classic" crashdump= syntax (<size>@<start>)
causes an exact size and location to be reserved in the e820 map
before Xen and modules are relocated.  However, using "new" syntax
(<start>-[<end>]:<size>) encounteres a myriad of problems, most
notibly not considering the range when allocating its region.

This patch tries to unify both codepaths, and fix the broken logic
when using "newer" syntax.

Changes addressed:

1) Remove use of kexec_crash_area from parse_crashkernel().
     Use ranges[0] in preference, as there is no support for multiple
     ranges using classic syntax.  This prevents some wierd logic in
     __setup_xen() depending on whether kexec_crash_area.size is set
     or not.

2) Change set_kexec_crash_area_size() to choose_kexec_range()
     The new method of choosing a range provides an entire rather than
     just setting kexec_crash_area.size.  Also, fix the very broken
     logic which will only consider a range if its .end is greater
     than system_ram.  Additionally, prefer range with the largest
     size if we have a choice of valid ones, and prefer ranges with
     more flexibility in their limits.

3) Move kexec_reserve_area() from setup.c to kexec.c
     It makes more sense here, Also, change its functionality a little
     to always work from the kexec range provided by choose_kexec_range()

4) Remove the kexec reservation code when considering modules
     This code only had any effect for people using the "newer" syntax
     on the command line, as people using the "classic" syntax would
     reserve a memory region before considering modules.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 0a0c02a61676 xen/arch/x86/setup.c
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -482,32 +482,6 @@ static void __init parse_video_info(void
     }
 }
 
-static void __init kexec_reserve_area(struct e820map *e820)
-{
-    unsigned long kdump_start = kexec_crash_area.start;
-    unsigned long kdump_size  = kexec_crash_area.size;
-    static int is_reserved = 0;
-
-    kdump_size = (kdump_size + PAGE_SIZE - 1) & PAGE_MASK;
-
-    if ( (kdump_start == 0) || (kdump_size == 0) || is_reserved )
-        return;
-
-    is_reserved = 1;
-
-    if ( !reserve_e820_ram(e820, kdump_start, kdump_start + kdump_size) )
-    {
-        printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) at 0x%lx)"
-               "\n", kdump_size >> 20, kdump_size >> 10, kdump_start);
-        kexec_crash_area.start = kexec_crash_area.size = 0;
-    }
-    else
-    {
-        printk("Kdump: %luMB (%lukB) at 0x%lx\n",
-               kdump_size >> 20, kdump_size >> 10, kdump_start);
-    }
-}
-
 void init_done(void)
 {
     /* Free (or page-protect) the init areas. */
@@ -759,13 +733,15 @@ void __init __start_xen(unsigned long mb
     /* Create a temporary copy of the E820 map. */
     memcpy(&boot_e820, &e820, sizeof(e820));
 
-    /* Early kexec reservation (explicit static start address). */
+    /* Calculate nr_pages from the e820 map. */
     nr_pages = 0;
     for ( i = 0; i < e820.nr_map; i++ )
         if ( e820.map[i].type == E820_RAM )
             nr_pages += e820.map[i].size >> PAGE_SHIFT;
-    set_kexec_crash_area_size((u64)nr_pages << PAGE_SHIFT);
-    kexec_reserve_area(&boot_e820);
+
+    /* Early kexec reservation. */
+    if( choose_kexec_range((u64)nr_pages << PAGE_SHIFT) )
+        kexec_reserve_area(&boot_e820);
 
     initial_images = mod;
     nr_initial_images = mbi->mods_count;
@@ -939,19 +915,6 @@ void __init __start_xen(unsigned long mb
                 mod[j].reserved = 1;
             }
         }
-
-#ifdef CONFIG_X86_32
-        /* Confine the kexec area to below 4Gb. */
-        e = min_t(uint64_t, e, 1ULL << 32);
-#endif
-        /* Don't overlap with modules. */
-        e = consider_modules(s, e, PAGE_ALIGN(kexec_crash_area.size),
-                             mod, mbi->mods_count, -1);
-        if ( !kexec_crash_area.start && (s < e) )
-        {
-            e = (e - kexec_crash_area.size) & PAGE_MASK;
-            kexec_crash_area.start = e;
-        }
     }
 
     if ( modules_headroom && !mod->reserved )
diff -r 0a0c02a61676 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -51,10 +51,22 @@ static unsigned char vmcoreinfo_data[VMC
 static size_t vmcoreinfo_size = 0;
 
 xen_kexec_reserve_t kexec_crash_area;
-static struct {
-    u64 start, end;
-    unsigned long size;
-} ranges[16] __initdata;
+
+/* Structure to contain kexec memory regions, as provided by the
+   crashkernel= command line parameter.  The meaining is a region of
+   size byte anywhere in the range start to end.  Therefore,
+   size <= (end - start) */
+struct kexec_boot_range {
+    u64 start, end, size;
+};
+
+/* Possible regions for the crashdump kernel region, parsed from the
+ * "crashkernel=foo" command line option. */
+static struct kexec_boot_range ranges[16] __initdata;
+
+/* Our chosen range to place the crashdump kernel, taking into account
+ * system memory. */
+static struct kexec_boot_range * kexec_range __initdata = NULL;
 
 /*
  * Parse command lines in the format
@@ -126,32 +138,126 @@ static void __init parse_crashkernel(con
             ranges[idx].size = 0;
     }
     else
-        kexec_crash_area.size = parse_size_and_unit(cur = str, &str);
+        ranges[0].size = parse_size_and_unit(cur = str, &str);
     if ( cur != str && *str == '@' )
-        kexec_crash_area.start = parse_size_and_unit(cur = str + 1, &str);
+    {
+        ranges[0].start = parse_size_and_unit(cur = str + 1, &str);
+        ranges[0].end = ranges[0].start + ranges[0].size;
+    }
     if ( cur == str )
+    {
         printk(XENLOG_WARNING "crashkernel: memory value expected\n");
+        ranges[0].size = 0;
+    }
 }
 custom_param("crashkernel", parse_crashkernel);
 
-void __init set_kexec_crash_area_size(u64 system_ram)
+/* Using system ram as a guide, choice one of the possible ranges to
+   use.  Return boolean indicating whether a range has been chosen or
+   not. */
+bool_t __init choose_kexec_range(u64 system_ram)
 {
     unsigned int idx;
+    struct kexec_boot_range * best_choice = NULL;
 
-    for ( idx = 0; idx < ARRAY_SIZE(ranges) && !kexec_crash_area.size; ++idx )
+    for ( idx = 0; idx < ARRAY_SIZE(ranges); ++idx )
     {
+        /* size == 0 indicates invalid range. */
         if ( !ranges[idx].size )
             break;
 
-        if ( ranges[idx].size >= system_ram )
+        /* PAGE_ALIGN each of the values. */
+        ranges[idx].start = PAGE_ALIGN(ranges[idx].start);
+        ranges[idx].size = PAGE_ALIGN(ranges[idx].size);
+        if ( ranges[idx].end != -1 )
+            ranges[idx].end = PAGE_ALIGN(ranges[idx].end);
+
+        /* Check that the size can actually fit in the region provided. */
+        if ( (ranges[idx].end - ranges[idx].start) < ranges[idx].size )
+            continue;
+
+        /* Check that the ranges size will fit inside its ends. */
+        if ( (ranges[idx].end - ranges[idx].start) < ranges[idx].size )
         {
-            printk(XENLOG_WARNING "crashkernel: invalid size\n");
+            printk(XENLOG_WARNING "crashkernel: range %d size bigger than "
+                   "defined range\n", idx);
             continue;
         }
 
-        if ( ranges[idx].start <= system_ram && ranges[idx].end > system_ram )
-            kexec_crash_area.size = ranges[idx].size;
+        /* Check that the range will fit in memory. */
+        if ( ranges[idx].start + ranges[idx].size <= system_ram )
+        {
+            /* Prefer regions with a larger size if we have a choice, and
+               prefer regions with more flexibility in its range. */
+            if ( !best_choice || (ranges[idx].size > best_choice->size) ||
+                 ((ranges[idx].end - ranges[idx].start) > 
+                  (best_choice->end - best_choice->start)) )
+                best_choice = &ranges[idx];
+        }
+        /* else complain. */
+        else
+            printk(XENLOG_WARNING "crashkernel: range %d size bigger than "
+                   "available ram\n", idx);
     }
+
+    kexec_range = best_choice;
+    return best_choice != NULL;
+}
+
+/* Reserve an area in the e820 map for the kexec region. */
+void __init kexec_reserve_area(struct e820map *e820)
+{
+    static bool_t is_reserved = FALSE;
+    unsigned long kexec_start, kexec_size;
+    int i;
+
+    /* Do we have a chosen range, or have we already reserved an
+       area? */
+    if ( ! kexec_range || is_reserved )
+        return;
+
+    for ( i = 0; i < e820->nr_map; ++i )
+    {
+        /* We dont want to allocate in any non RAM regions. */
+        if ( e820->map[i].type != E820_RAM )
+            continue;
+
+        /* Check that the e820 region is big enough to fit the kexec
+           region. */
+        if ( (kexec_range->size >= e820->map[i].size) ||
+             (kexec_range->start + kexec_range->size) >
+             (e820->map[i].addr + e820->map[i].size) )
+            continue;
+
+        kexec_start = max_t(u64, kexec_range->start, e820->map[i].addr);
+
+        /* If we have to start the kexec region higher in memory because
+           of the start of the e820 region, check that we still respect
+           the specified end of kexec region. */
+        if ( kexec_range->size > (kexec_range->end - kexec_start) )
+            continue;
+
+        is_reserved = TRUE;
+        kexec_size = kexec_range->size;
+
+        /* Try to reserve this region in the e820. On failure, we just might
+           be able to successfully reserve a region in a later RAM block. */
+        if ( reserve_e820_ram(e820, kexec_start, kexec_start + kexec_size) )
+        {
+            printk("Kdump: %luMB (%lukB) at 0x%lx\n",
+                   kexec_size >> 20, kexec_size >> 10, kexec_start);
+            kexec_crash_area.start = kexec_start;
+            kexec_crash_area.size = kexec_size;
+            return;
+        }
+    }
+    
+    /* If we fail to find a valid region, or fail ro reserve one, complain
+       to the console. */
+    printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) in range 0x%lx "
+           "-> 0x%lx\n", kexec_range->size >> 20, kexec_range->size >> 10,
+           kexec_range->start, kexec_range->end );
+    kexec_crash_area.start = kexec_crash_area.size = 0;
 }
 
 static void one_cpu_only(void)
diff -r 0a0c02a61676 xen/include/xen/kexec.h
--- a/xen/include/xen/kexec.h
+++ b/xen/include/xen/kexec.h
@@ -4,6 +4,7 @@
 #include <public/kexec.h>
 #include <asm/percpu.h>
 #include <xen/elfcore.h>
+#include <asm/e820.h>
 
 typedef struct xen_kexec_reserve {
     unsigned long size;
@@ -14,7 +15,8 @@ extern xen_kexec_reserve_t kexec_crash_a
 
 extern bool_t kexecing;
 
-void set_kexec_crash_area_size(u64 system_ram);
+bool_t choose_kexec_range(u64 system_ram);
+void kexec_reserve_area(struct e820map *e820);
 
 /* We have space for 4 images to support atomic update
  * of images. This is important for CRASH images since

--------------080404090301050001090008
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------080404090301050001090008--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:15:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxUL-0003m1-AP; Fri, 25 Nov 2011 15:14:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxUK-0003lP-02
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:14:52 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322234025!45403966!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3417 invoked from network); 25 Nov 2011 15:13:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:13:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133154"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:14:19 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 25 Nov 2011
	15:14:19 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Fri, 25 Nov 2011 15:14:18 +0000
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyrhOJsnABcN6OrSS2PejfwK/uSKg==
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4CE3@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: 25 November 2011 15:01
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains
> with viridian=1
> 
> At 14:50 +0000 on 25 Nov (1322232658), Paul Durrant wrote:
[snip]
> >
> > +    case XC_SAVE_ID_HVM_VIRIDIAN:
> > +        /* Skip padding 4 bytes then read the acpi ioport
> location.
> > + */
> 
> Ahem.
> ^^^^^^^^^^^^^^^^^^^^
> 

Yes, whoops.

[snip]
> > @@ -206,8 +206,11 @@ int wrmsr_viridian_regs(uint32_t idx, ui
> >      struct vcpu *v = current;
> >      struct domain *d = v->domain;
> >
> > -    if ( !is_viridian_domain(d) )
> > +    if ( !is_viridian_domain(d) ) {
> > +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian
> domain\n", __func__,
> > +                 d->domain_id);
> 
> This should probably be rate-limited; a confused domain could cause
> a _lot_ of these.  Might we want to pause/kill the domain as well,
> or inject a fault?
> 

Yes, true.

> >          return 0;
> > +    }
> >
> >      switch ( idx )
> >      {
> > @@ -271,8 +274,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui
> >      struct vcpu *v = current;
> >      struct domain *d = v->domain;
> >
> > -    if ( !is_viridian_domain(d) )
> > +    if ( !is_viridian_domain(d) ) {
> > +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian
> domain\n", __func__,
> > +                 d->domain_id);
> 
> Likewise.
> 
> >          return 0;
> > +    }
> >
> >      switch ( idx )
> >      {
> > @@ -411,6 +417,8 @@ static int viridian_load_domain_ctxt(str
> >      if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
> >          return -EINVAL;
> >
> > +    ASSERT(is_viridian_domain(d));
> > +
> 
> I don't think it's appropriate to crash Xen if the save file is
> bogus.
> 

There's a similar ASSERT in the hypercall function anyway; would you rather I turned that into a rate limited warning too?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:15:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:15:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxUL-0003m1-AP; Fri, 25 Nov 2011 15:14:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxUK-0003lP-02
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:14:52 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322234025!45403966!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3417 invoked from network); 25 Nov 2011 15:13:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:13:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133154"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:14:19 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 25 Nov 2011
	15:14:19 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Fri, 25 Nov 2011 15:14:18 +0000
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyrhOJsnABcN6OrSS2PejfwK/uSKg==
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4CE3@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: 25 November 2011 15:01
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains
> with viridian=1
> 
> At 14:50 +0000 on 25 Nov (1322232658), Paul Durrant wrote:
[snip]
> >
> > +    case XC_SAVE_ID_HVM_VIRIDIAN:
> > +        /* Skip padding 4 bytes then read the acpi ioport
> location.
> > + */
> 
> Ahem.
> ^^^^^^^^^^^^^^^^^^^^
> 

Yes, whoops.

[snip]
> > @@ -206,8 +206,11 @@ int wrmsr_viridian_regs(uint32_t idx, ui
> >      struct vcpu *v = current;
> >      struct domain *d = v->domain;
> >
> > -    if ( !is_viridian_domain(d) )
> > +    if ( !is_viridian_domain(d) ) {
> > +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian
> domain\n", __func__,
> > +                 d->domain_id);
> 
> This should probably be rate-limited; a confused domain could cause
> a _lot_ of these.  Might we want to pause/kill the domain as well,
> or inject a fault?
> 

Yes, true.

> >          return 0;
> > +    }
> >
> >      switch ( idx )
> >      {
> > @@ -271,8 +274,11 @@ int rdmsr_viridian_regs(uint32_t idx, ui
> >      struct vcpu *v = current;
> >      struct domain *d = v->domain;
> >
> > -    if ( !is_viridian_domain(d) )
> > +    if ( !is_viridian_domain(d) ) {
> > +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian
> domain\n", __func__,
> > +                 d->domain_id);
> 
> Likewise.
> 
> >          return 0;
> > +    }
> >
> >      switch ( idx )
> >      {
> > @@ -411,6 +417,8 @@ static int viridian_load_domain_ctxt(str
> >      if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
> >          return -EINVAL;
> >
> > +    ASSERT(is_viridian_domain(d));
> > +
> 
> I don't think it's appropriate to crash Xen if the save file is
> bogus.
> 

There's a similar ASSERT in the hypercall function anyway; would you rather I turned that into a rate limited warning too?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:17:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:17:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxWb-00041O-SX; Fri, 25 Nov 2011 15:17:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTxWa-00040z-3H
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:17:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322234155!58299237!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11264 invoked from network); 25 Nov 2011 15:15:56 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:15:56 -0000
Received: by bkbzt12 with SMTP id zt12so5914234bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 07:16:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=lnX4ndPQI9AzpqlBoyS9tbopL2ovT5nuaSbCJaQ7c1U=;
	b=FmSC00qwREAeuk3hBzPSRwohZdFloP+R2G5nKG3EkO3mSRnaoIObfQme+gubVNsDuO
	khXKzsOs0X2QBxV4bNwIPq7eLE7YdE5wea/7UQ6J6JKO37F0jPWDzV/n7i1sRtCvnyj0
	xftZg/urxuJpzCC6LqPQmt1MygOiLEeicQqyE=
Received: by 10.204.41.66 with SMTP id n2mr34639694bke.77.1322234199120;
	Fri, 25 Nov 2011 07:16:39 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id c4sm19045590bkk.13.2011.11.25.07.16.37
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 07:16:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 15:16:30 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	<paul.durrant@citrix.com>
Message-ID: <CAF561CE.25A6B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyrhTVK6qWnaducJUe+zb5KzJSZiA==
In-Reply-To: <4ECFBB26020000780006356F@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 14:58, "Jan Beulich" <JBeulich@suse.com> wrote:

>> xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN
>> which
>> results in an HVM domain running a recent version on Windows (post-Vista)
>> locking up on a domain restore due to EOIs (done via a viridian MSR write)
>> being silently dropped.
>> This patch adds an extra save entry for the viridian parameter and also
>> adds code in the viridian kernel module to catch attempted use of viridian
>> functionality when the HVM parameter has not been set.
> 
> Assuming this means the changes to {rd,wr}msr_viridian_regs(), isn't
> this going to needlessly spam the log? I.e. printing this just once (per
> VM) would seem to suffice. Or alternatively I would think that
> HVM_DBG_LOG() would be a better choice here.

It's unlikely to print more than once before the VM wedges. We could go
further and inject #GP, which we ought to be doing anyway.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:17:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:17:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxWb-00041O-SX; Fri, 25 Nov 2011 15:17:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTxWa-00040z-3H
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:17:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322234155!58299237!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11264 invoked from network); 25 Nov 2011 15:15:56 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:15:56 -0000
Received: by bkbzt12 with SMTP id zt12so5914234bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 07:16:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=lnX4ndPQI9AzpqlBoyS9tbopL2ovT5nuaSbCJaQ7c1U=;
	b=FmSC00qwREAeuk3hBzPSRwohZdFloP+R2G5nKG3EkO3mSRnaoIObfQme+gubVNsDuO
	khXKzsOs0X2QBxV4bNwIPq7eLE7YdE5wea/7UQ6J6JKO37F0jPWDzV/n7i1sRtCvnyj0
	xftZg/urxuJpzCC6LqPQmt1MygOiLEeicQqyE=
Received: by 10.204.41.66 with SMTP id n2mr34639694bke.77.1322234199120;
	Fri, 25 Nov 2011 07:16:39 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id c4sm19045590bkk.13.2011.11.25.07.16.37
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 07:16:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 15:16:30 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	<paul.durrant@citrix.com>
Message-ID: <CAF561CE.25A6B%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyrhTVK6qWnaducJUe+zb5KzJSZiA==
In-Reply-To: <4ECFBB26020000780006356F@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 14:58, "Jan Beulich" <JBeulich@suse.com> wrote:

>> xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN
>> which
>> results in an HVM domain running a recent version on Windows (post-Vista)
>> locking up on a domain restore due to EOIs (done via a viridian MSR write)
>> being silently dropped.
>> This patch adds an extra save entry for the viridian parameter and also
>> adds code in the viridian kernel module to catch attempted use of viridian
>> functionality when the HVM parameter has not been set.
> 
> Assuming this means the changes to {rd,wr}msr_viridian_regs(), isn't
> this going to needlessly spam the log? I.e. printing this just once (per
> VM) would seem to suffice. Or alternatively I would think that
> HVM_DBG_LOG() would be a better choice here.

It's unlikely to print more than once before the VM wedges. We could go
further and inject #GP, which we ought to be doing anyway.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:17:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:17:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxWs-00043G-AA; Fri, 25 Nov 2011 15:17:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxWr-00042R-MW
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:17:29 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322234217!6342230!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22229 invoked from network); 25 Nov 2011 15:16:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133203"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:16:31 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 25 Nov 2011
	15:16:31 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 15:16:31 +0000
Thread-Topic: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document
	describing the xl cfg file syntax
Thread-Index: Acyrg7RwakuVuZdbT3W4vTTy+9o3cwAAUkFg
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4CE6@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
	<1322233543.1005.261.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322233543.1005.261.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document describing
 the xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 25 November 2011 15:06
> To: xen-devel@lists.xensource.com
> Cc: Ian Jackson; Paul Durrant
> Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document
> describing the xl cfg file syntax
> 
> Paul,
> 
> On Fri, 2011-11-25 at 14:49 +0000, Ian Campbell wrote:
> >
> > +=item B<viridian=BOOLEAN>
> > +
> > +Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
> > +compatible enlightenments to the guest.  These can improve
> > performance
> > +of Microsoft Windows guests (XXX which versions of Windows
> benefit?)
> 
> Is there anything else we can say here? What are the first versions
> of Windows which benefit from this?
> 

Ian,

  I think that's probably good enough. AFAIK viridian enlightenments came in with the 6.0 kernel in Vista/2K8 but having the flag on should do no harm for older kernels.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:17:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:17:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxWs-00043G-AA; Fri, 25 Nov 2011 15:17:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxWr-00042R-MW
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:17:29 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322234217!6342230!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22229 invoked from network); 25 Nov 2011 15:16:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133203"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:16:31 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 25 Nov 2011
	15:16:31 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 15:16:31 +0000
Thread-Topic: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document
	describing the xl cfg file syntax
Thread-Index: Acyrg7RwakuVuZdbT3W4vTTy+9o3cwAAUkFg
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4CE6@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
	<1322233543.1005.261.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322233543.1005.261.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document describing
 the xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 25 November 2011 15:06
> To: xen-devel@lists.xensource.com
> Cc: Ian Jackson; Paul Durrant
> Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document
> describing the xl cfg file syntax
> 
> Paul,
> 
> On Fri, 2011-11-25 at 14:49 +0000, Ian Campbell wrote:
> >
> > +=item B<viridian=BOOLEAN>
> > +
> > +Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
> > +compatible enlightenments to the guest.  These can improve
> > performance
> > +of Microsoft Windows guests (XXX which versions of Windows
> benefit?)
> 
> Is there anything else we can say here? What are the first versions
> of Windows which benefit from this?
> 

Ian,

  I think that's probably good enough. AFAIK viridian enlightenments came in with the 6.0 kernel in Vista/2K8 but having the flag on should do no harm for older kernels.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:19:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:19:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxYI-0004Ec-VK; Fri, 25 Nov 2011 15:18:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTxYH-0004Dm-SQ
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:18:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322234305!4995720!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5796 invoked from network); 25 Nov 2011 15:18:25 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:18:25 -0000
Received: by bkbzt12 with SMTP id zt12so5916492bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 07:18:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=drQI+f52pAzbpEZq9tAoVYjPXBQxN73tEMY4hlykxlM=;
	b=b2UH/SZv+QW6ITjPZHW7UzjgXreW2+cdH+6ofVUhyCj1z3RzYKpGmD3IBJcpuBSNk4
	LDxIyk40TYfByxAHIPUZC1itjCH9aOki4EpWi12zWysvQvA+bGT7gbnHuiZSmCVi2NKh
	27MwqQ0ZTWk0/qZyQUAhAd8KIvLR8fCrTCFNI=
Received: by 10.204.13.78 with SMTP id b14mr20324480bka.23.1322234304608;
	Fri, 25 Nov 2011 07:18:24 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id j9sm19083038bkd.2.2011.11.25.07.18.22
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 07:18:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 15:18:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Paul Durrant <paul.durrant@citrix.com>
Message-ID: <CAF5623C.25A6C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyrhXbblPk+A1lA5kaRksSktIcJ8g==
In-Reply-To: <20111125150035.GA6475@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 15:00, "Tim Deegan" <tim@xen.org> wrote:

>> -    if ( !is_viridian_domain(d) )
>> +    if ( !is_viridian_domain(d) ) {
>> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", __func__,
>> +                 d->domain_id);
> 
> This should probably be rate-limited; a confused domain could cause a
> _lot_ of these.  Might we want to pause/kill the domain as well, or
> inject a fault?

We do XENLOG_WARNING logging on various paths that silently fail (e.g.,
weird writes to the VIOAPIC). We should probably just #GP, that will silence
the guest pretty quickly. I can make that change.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:19:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:19:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxYI-0004Ec-VK; Fri, 25 Nov 2011 15:18:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTxYH-0004Dm-SQ
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:18:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322234305!4995720!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5796 invoked from network); 25 Nov 2011 15:18:25 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:18:25 -0000
Received: by bkbzt12 with SMTP id zt12so5916492bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 07:18:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=drQI+f52pAzbpEZq9tAoVYjPXBQxN73tEMY4hlykxlM=;
	b=b2UH/SZv+QW6ITjPZHW7UzjgXreW2+cdH+6ofVUhyCj1z3RzYKpGmD3IBJcpuBSNk4
	LDxIyk40TYfByxAHIPUZC1itjCH9aOki4EpWi12zWysvQvA+bGT7gbnHuiZSmCVi2NKh
	27MwqQ0ZTWk0/qZyQUAhAd8KIvLR8fCrTCFNI=
Received: by 10.204.13.78 with SMTP id b14mr20324480bka.23.1322234304608;
	Fri, 25 Nov 2011 07:18:24 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id j9sm19083038bkd.2.2011.11.25.07.18.22
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 07:18:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 15:18:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Paul Durrant <paul.durrant@citrix.com>
Message-ID: <CAF5623C.25A6C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyrhXbblPk+A1lA5kaRksSktIcJ8g==
In-Reply-To: <20111125150035.GA6475@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 15:00, "Tim Deegan" <tim@xen.org> wrote:

>> -    if ( !is_viridian_domain(d) )
>> +    if ( !is_viridian_domain(d) ) {
>> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian domain\n", __func__,
>> +                 d->domain_id);
> 
> This should probably be rate-limited; a confused domain could cause a
> _lot_ of these.  Might we want to pause/kill the domain as well, or
> inject a fault?

We do XENLOG_WARNING logging on various paths that silently fail (e.g.,
weird writes to the VIOAPIC). We should probably just #GP, that will silence
the guest pretty quickly. I can make that change.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:23:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxcC-0004e2-PA; Fri, 25 Nov 2011 15:23:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RTxcA-0004dA-RM
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:22:59 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322234546!4655724!1
X-Originating-IP: [213.199.154.139]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19259 invoked from network); 25 Nov 2011 15:22:26 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Nov 2011 15:22:26 -0000
Received: from mail69-db3-R.bigfish.com (10.3.81.252) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.22; Fri, 25 Nov 2011 15:21:43 +0000
Received: from mail69-db3 (localhost [127.0.0.1])	by mail69-db3-R.bigfish.com
	(Postfix) with ESMTP id 2A4A422047D;
	Fri, 25 Nov 2011 15:21:20 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dK1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail69-db3 (localhost.localdomain [127.0.0.1]) by mail69-db3
	(MessageSwitch) id 1322234479293249_16333;
	Fri, 25 Nov 2011 15:21:19 +0000 (UTC)
Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.245])	by
	mail69-db3.bigfish.com (Postfix) with ESMTP id 3A2A7100043;
	Fri, 25 Nov 2011 15:21:19 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server id
	14.1.225.22; Fri, 25 Nov 2011 15:21:41 +0000
X-WSS-ID: 0LV82P8-02-84Z-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25F67C812B;	Fri, 25 Nov 2011 09:22:19 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 25 Nov 2011 09:22:40 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 25 Nov 2011 09:22:21 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	10:22:20 -0500
Message-ID: <4ECFB2AB.8070005@amd.com>
Date: Fri, 25 Nov 2011 16:22:19 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <b4c07fbe3557ae501fc2.1322233898@cosworth.uk.xensource.com>
In-Reply-To: <b4c07fbe3557ae501fc2.1322233898@cosworth.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	paul.durrant@citrix.com
Subject: Re: [Xen-devel] [PATCH] docs: xlexample.hvm: mention the viridian
 setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/25/11 16:11, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1322233890 0
> # Node ID b4c07fbe3557ae501fc2d8a21b41f1b1cd5198cb
> # Parent  31e71820ce93b72b0223882f6c2e1f461920bda9
> docs: xlexample.hvm: mention the viridian setting.
>
> Turning this on for Windows guests is recommended.

Actually, Hyper-V fails to boot with viridian=1 because our
viridian implementation misses features such as the virtualized
LAPIC interface.

Christoph


>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
>
> diff -r 31e71820ce93 -r b4c07fbe3557 tools/examples/xlexample.hvm
> --- a/tools/examples/xlexample.hvm	Fri Nov 25 14:44:10 2011 +0000
> +++ b/tools/examples/xlexample.hvm	Fri Nov 25 15:11:30 2011 +0000
> @@ -16,6 +16,11 @@ name = "example.hvm"
>   # The default behavior is to generate a new UUID each time the guest is started.
>   #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>
> +# Enable Microsoft Hyper-V compatibile paravirtualisation /
> +# enlightenment interfaces. Turning this on can improve Windows guest
> +# performance and is therefore recommended
> +#viridian = 1
> +
>   # Initial memory allocation (MB)
>   memory = 128
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:23:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:23:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxcC-0004e2-PA; Fri, 25 Nov 2011 15:23:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RTxcA-0004dA-RM
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:22:59 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322234546!4655724!1
X-Originating-IP: [213.199.154.139]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19259 invoked from network); 25 Nov 2011 15:22:26 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Nov 2011 15:22:26 -0000
Received: from mail69-db3-R.bigfish.com (10.3.81.252) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.22; Fri, 25 Nov 2011 15:21:43 +0000
Received: from mail69-db3 (localhost [127.0.0.1])	by mail69-db3-R.bigfish.com
	(Postfix) with ESMTP id 2A4A422047D;
	Fri, 25 Nov 2011 15:21:20 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dK1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail69-db3 (localhost.localdomain [127.0.0.1]) by mail69-db3
	(MessageSwitch) id 1322234479293249_16333;
	Fri, 25 Nov 2011 15:21:19 +0000 (UTC)
Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.245])	by
	mail69-db3.bigfish.com (Postfix) with ESMTP id 3A2A7100043;
	Fri, 25 Nov 2011 15:21:19 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server id
	14.1.225.22; Fri, 25 Nov 2011 15:21:41 +0000
X-WSS-ID: 0LV82P8-02-84Z-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 25F67C812B;	Fri, 25 Nov 2011 09:22:19 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 25 Nov 2011 09:22:40 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 25 Nov 2011 09:22:21 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	10:22:20 -0500
Message-ID: <4ECFB2AB.8070005@amd.com>
Date: Fri, 25 Nov 2011 16:22:19 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <b4c07fbe3557ae501fc2.1322233898@cosworth.uk.xensource.com>
In-Reply-To: <b4c07fbe3557ae501fc2.1322233898@cosworth.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	paul.durrant@citrix.com
Subject: Re: [Xen-devel] [PATCH] docs: xlexample.hvm: mention the viridian
 setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/25/11 16:11, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1322233890 0
> # Node ID b4c07fbe3557ae501fc2d8a21b41f1b1cd5198cb
> # Parent  31e71820ce93b72b0223882f6c2e1f461920bda9
> docs: xlexample.hvm: mention the viridian setting.
>
> Turning this on for Windows guests is recommended.

Actually, Hyper-V fails to boot with viridian=1 because our
viridian implementation misses features such as the virtualized
LAPIC interface.

Christoph


>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
>
> diff -r 31e71820ce93 -r b4c07fbe3557 tools/examples/xlexample.hvm
> --- a/tools/examples/xlexample.hvm	Fri Nov 25 14:44:10 2011 +0000
> +++ b/tools/examples/xlexample.hvm	Fri Nov 25 15:11:30 2011 +0000
> @@ -16,6 +16,11 @@ name = "example.hvm"
>   # The default behavior is to generate a new UUID each time the guest is started.
>   #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
>
> +# Enable Microsoft Hyper-V compatibile paravirtualisation /
> +# enlightenment interfaces. Turning this on can improve Windows guest
> +# performance and is therefore recommended
> +#viridian = 1
> +
>   # Initial memory allocation (MB)
>   memory = 128
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:25:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:25:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxen-0004oy-Ce; Fri, 25 Nov 2011 15:25:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTxel-0004oc-8b
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:25:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322234706!5019550!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21937 invoked from network); 25 Nov 2011 15:25:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 15:25:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTxeE-0001nP-6U; Fri, 25 Nov 2011 15:25:06 +0000
Date: Fri, 25 Nov 2011 15:25:06 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20111125152506.GC6475@ocelot.phlegethon.org>
References: <291EDFCB1E9E224A99088639C4762022B5988E4CE3@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4CE3@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:14 +0000 on 25 Nov (1322234058), Paul Durrant wrote:
> > > @@ -411,6 +417,8 @@ static int viridian_load_domain_ctxt(str
> > >      if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
> > >          return -EINVAL;
> > >
> > > +    ASSERT(is_viridian_domain(d));
> > > +
> > 
> > I don't think it's appropriate to crash Xen if the save file is
> > bogus.
> > 
> 
> There's a similar ASSERT in the hypercall function anyway; would you rather I turned that into a rate limited warning too?
> 

If you mean the one in viridian_hypercall(), no - if that function is
called for a non-viridian VM that's a bug in Xen so the ASSERT() is
correct.   

The viridian_load_*_ctxt() functions are called based on the HVM save
record the tools gave us, so we should at most return an error if they
lead us astray.  And I think it should be OK to load the HVM state and then
set the HVM params, so the current (lack of) response is correct. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:25:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:25:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxen-0004oy-Ce; Fri, 25 Nov 2011 15:25:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RTxel-0004oc-8b
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:25:39 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322234706!5019550!1
X-Originating-IP: [81.29.64.94]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21937 invoked from network); 25 Nov 2011 15:25:06 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 15:25:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RTxeE-0001nP-6U; Fri, 25 Nov 2011 15:25:06 +0000
Date: Fri, 25 Nov 2011 15:25:06 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20111125152506.GC6475@ocelot.phlegethon.org>
References: <291EDFCB1E9E224A99088639C4762022B5988E4CE3@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4CE3@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:14 +0000 on 25 Nov (1322234058), Paul Durrant wrote:
> > > @@ -411,6 +417,8 @@ static int viridian_load_domain_ctxt(str
> > >      if ( hvm_load_entry(VIRIDIAN_DOMAIN, h, &ctxt) != 0 )
> > >          return -EINVAL;
> > >
> > > +    ASSERT(is_viridian_domain(d));
> > > +
> > 
> > I don't think it's appropriate to crash Xen if the save file is
> > bogus.
> > 
> 
> There's a similar ASSERT in the hypercall function anyway; would you rather I turned that into a rate limited warning too?
> 

If you mean the one in viridian_hypercall(), no - if that function is
called for a non-viridian VM that's a bug in Xen so the ASSERT() is
correct.   

The viridian_load_*_ctxt() functions are called based on the HVM save
record the tools gave us, so we should at most return an error if they
lead us astray.  And I think it should be OK to load the HVM state and then
set the HVM params, so the current (lack of) response is correct. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:27:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:27:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxgf-0004xI-Vn; Fri, 25 Nov 2011 15:27:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxge-0004ww-Kc
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:27:36 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322234823!3049979!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27236 invoked from network); 25 Nov 2011 15:27:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:27:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133557"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:26:46 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 25 Nov 2011
	15:26:46 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, "Tim (Xen.org)" <tim@xen.org>
Date: Fri, 25 Nov 2011 15:26:46 +0000
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyrhXbblPk+A1lA5kaRksSktIcJ8gAAMmMg
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4CEE@LONPMAILBOX01.citrite.net>
References: <20111125150035.GA6475@ocelot.phlegethon.org>
	<CAF5623C.25A6C%keir.xen@gmail.com>
In-Reply-To: <CAF5623C.25A6C%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yes, I forgot about #GP. Windows 7 unfortunately handles and but doesn't complain. I'll ditch the logging.

  Paul

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: 25 November 2011 15:18
> To: Tim (Xen.org); Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains
> with viridian=1
> 
> On 25/11/2011 15:00, "Tim Deegan" <tim@xen.org> wrote:
> 
> >> -    if ( !is_viridian_domain(d) )
> >> +    if ( !is_viridian_domain(d) ) {
> >> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian
> domain\n", __func__,
> >> +                 d->domain_id);
> >
> > This should probably be rate-limited; a confused domain could
> cause a
> > _lot_ of these.  Might we want to pause/kill the domain as well,
> or
> > inject a fault?
> 
> We do XENLOG_WARNING logging on various paths that silently fail
> (e.g., weird writes to the VIOAPIC). We should probably just #GP,
> that will silence the guest pretty quickly. I can make that change.
> 
>  -- Keir
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:27:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:27:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxgf-0004xI-Vn; Fri, 25 Nov 2011 15:27:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxge-0004ww-Kc
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:27:36 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322234823!3049979!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27236 invoked from network); 25 Nov 2011 15:27:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:27:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133557"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:26:46 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 25 Nov 2011
	15:26:46 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, "Tim (Xen.org)" <tim@xen.org>
Date: Fri, 25 Nov 2011 15:26:46 +0000
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyrhXbblPk+A1lA5kaRksSktIcJ8gAAMmMg
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4CEE@LONPMAILBOX01.citrite.net>
References: <20111125150035.GA6475@ocelot.phlegethon.org>
	<CAF5623C.25A6C%keir.xen@gmail.com>
In-Reply-To: <CAF5623C.25A6C%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yes, I forgot about #GP. Windows 7 unfortunately handles and but doesn't complain. I'll ditch the logging.

  Paul

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: 25 November 2011 15:18
> To: Tim (Xen.org); Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains
> with viridian=1
> 
> On 25/11/2011 15:00, "Tim Deegan" <tim@xen.org> wrote:
> 
> >> -    if ( !is_viridian_domain(d) )
> >> +    if ( !is_viridian_domain(d) ) {
> >> +        gdprintk(XENLOG_WARNING, "%s: %d not a viridian
> domain\n", __func__,
> >> +                 d->domain_id);
> >
> > This should probably be rate-limited; a confused domain could
> cause a
> > _lot_ of these.  Might we want to pause/kill the domain as well,
> or
> > inject a fault?
> 
> We do XENLOG_WARNING logging on various paths that silently fail
> (e.g., weird writes to the VIOAPIC). We should probably just #GP,
> that will silence the guest pretty quickly. I can make that change.
> 
>  -- Keir
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:29:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxiK-00056R-HY; Fri, 25 Nov 2011 15:29:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxiJ-00055o-Az
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:29:19 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322234925!6344017!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31492 invoked from network); 25 Nov 2011 15:28:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:28:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171877514"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:28:45 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 10:28:45 -0500
MIME-Version: 1.0
X-Mercurial-Node: b50479d64deea72b11008fd444aa951737b2573d
Message-ID: <b50479d64deea72b1100.1322234906@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 15:28:26 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix save/restore for HVM domains with viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322234894 0
# Node ID b50479d64deea72b11008fd444aa951737b2573d
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Fix save/restore for HVM domains with viridian=1

xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
results in an HVM domain running a recent version on Windows (post-Vista)
locking up on a domain restore due to EOIs (done via a viridian MSR write)
being silently dropped.
This patch adds an extra save entry for the viridian parameter and also
adds code in the viridian kernel module to catch attempted use of viridian
functionality when the HVM parameter has not been set.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 15:28:14 2011 +0000
@@ -675,6 +675,7 @@ typedef struct {
     uint64_t vm86_tss;
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
+    uint64_t viridian;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_VIRIDIAN:
+        /* Skip padding 4 bytes then read the viridian flag. */
+        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
+        {
+            PERROR("error read the viridian flag");
+            return -1;
+        }
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
             fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
     }
 
+    if (pagebuf.viridian != 0)
+        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
+
     if (pagebuf.acpi_ioport_location == 1) {
         DBGPRINTF("Use new firmware ioport from the checkpoint\n");
         xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 15:28:14 2011 +0000
@@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
             PERROR("Error when writing the firmware ioport version");
             goto out;
         }
+
+        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the viridian flag");
+            goto out;
+        }
     }
 
     if ( !callbacks->checkpoint )
diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 15:28:14 2011 +0000
@@ -134,6 +134,7 @@
 #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
+#define XC_SAVE_ID_HVM_VIRIDIAN       -11
 
 /*
 ** We process save/restore/migrate in batches of pages; the below

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:29:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:29:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxiK-00056R-HY; Fri, 25 Nov 2011 15:29:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxiJ-00055o-Az
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:29:19 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322234925!6344017!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31492 invoked from network); 25 Nov 2011 15:28:46 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:28:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171877514"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:28:45 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 10:28:45 -0500
MIME-Version: 1.0
X-Mercurial-Node: b50479d64deea72b11008fd444aa951737b2573d
Message-ID: <b50479d64deea72b1100.1322234906@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 15:28:26 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix save/restore for HVM domains with viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322234894 0
# Node ID b50479d64deea72b11008fd444aa951737b2573d
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Fix save/restore for HVM domains with viridian=1

xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
results in an HVM domain running a recent version on Windows (post-Vista)
locking up on a domain restore due to EOIs (done via a viridian MSR write)
being silently dropped.
This patch adds an extra save entry for the viridian parameter and also
adds code in the viridian kernel module to catch attempted use of viridian
functionality when the HVM parameter has not been set.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 15:28:14 2011 +0000
@@ -675,6 +675,7 @@ typedef struct {
     uint64_t vm86_tss;
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
+    uint64_t viridian;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_VIRIDIAN:
+        /* Skip padding 4 bytes then read the viridian flag. */
+        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
+        {
+            PERROR("error read the viridian flag");
+            return -1;
+        }
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
             fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
     }
 
+    if (pagebuf.viridian != 0)
+        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
+
     if (pagebuf.acpi_ioport_location == 1) {
         DBGPRINTF("Use new firmware ioport from the checkpoint\n");
         xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 15:28:14 2011 +0000
@@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
             PERROR("Error when writing the firmware ioport version");
             goto out;
         }
+
+        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the viridian flag");
+            goto out;
+        }
     }
 
     if ( !callbacks->checkpoint )
diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 15:28:14 2011 +0000
@@ -134,6 +134,7 @@
 #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
+#define XC_SAVE_ID_HVM_VIRIDIAN       -11
 
 /*
 ** We process save/restore/migrate in batches of pages; the below

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxj4-0005BT-58; Fri, 25 Nov 2011 15:30:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxj3-0005Az-7F
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:30:05 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322234971!3052951!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16062 invoked from network); 25 Nov 2011 15:29:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:29:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171877556"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:29:30 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 10:29:30 -0500
MIME-Version: 1.0
X-Mercurial-Node: b50479d64deea72b11008fd444aa951737b2573d
Message-ID: <b50479d64deea72b1100.1322234965@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 15:29:25 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix save/restore for HVM domains with viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322234894 0
# Node ID b50479d64deea72b11008fd444aa951737b2573d
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Fix save/restore for HVM domains with viridian=1

xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
results in an HVM domain running a recent version on Windows (post-Vista)
locking up on a domain restore due to EOIs (done via a viridian MSR write)
being silently dropped.
This patch adds an extra save entry for the viridian parameter and also
adds code in the viridian kernel module to catch attempted use of viridian
functionality when the HVM parameter has not been set.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 15:28:14 2011 +0000
@@ -675,6 +675,7 @@ typedef struct {
     uint64_t vm86_tss;
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
+    uint64_t viridian;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_VIRIDIAN:
+        /* Skip padding 4 bytes then read the viridian flag. */
+        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
+        {
+            PERROR("error read the viridian flag");
+            return -1;
+        }
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
             fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
     }
 
+    if (pagebuf.viridian != 0)
+        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
+
     if (pagebuf.acpi_ioport_location == 1) {
         DBGPRINTF("Use new firmware ioport from the checkpoint\n");
         xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 15:28:14 2011 +0000
@@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
             PERROR("Error when writing the firmware ioport version");
             goto out;
         }
+
+        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the viridian flag");
+            goto out;
+        }
     }
 
     if ( !callbacks->checkpoint )
diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 15:28:14 2011 +0000
@@ -134,6 +134,7 @@
 #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
+#define XC_SAVE_ID_HVM_VIRIDIAN       -11
 
 /*
 ** We process save/restore/migrate in batches of pages; the below

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:30:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:30:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxj4-0005BT-58; Fri, 25 Nov 2011 15:30:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxj3-0005Az-7F
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:30:05 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322234971!3052951!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16062 invoked from network); 25 Nov 2011 15:29:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:29:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171877556"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:29:30 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 10:29:30 -0500
MIME-Version: 1.0
X-Mercurial-Node: b50479d64deea72b11008fd444aa951737b2573d
Message-ID: <b50479d64deea72b1100.1322234965@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 15:29:25 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix save/restore for HVM domains with viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322234894 0
# Node ID b50479d64deea72b11008fd444aa951737b2573d
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Fix save/restore for HVM domains with viridian=1

xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
results in an HVM domain running a recent version on Windows (post-Vista)
locking up on a domain restore due to EOIs (done via a viridian MSR write)
being silently dropped.
This patch adds an extra save entry for the viridian parameter and also
adds code in the viridian kernel module to catch attempted use of viridian
functionality when the HVM parameter has not been set.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 15:28:14 2011 +0000
@@ -675,6 +675,7 @@ typedef struct {
     uint64_t vm86_tss;
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
+    uint64_t viridian;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_VIRIDIAN:
+        /* Skip padding 4 bytes then read the viridian flag. */
+        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
+        {
+            PERROR("error read the viridian flag");
+            return -1;
+        }
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
             fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
     }
 
+    if (pagebuf.viridian != 0)
+        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
+
     if (pagebuf.acpi_ioport_location == 1) {
         DBGPRINTF("Use new firmware ioport from the checkpoint\n");
         xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 15:28:14 2011 +0000
@@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
             PERROR("Error when writing the firmware ioport version");
             goto out;
         }
+
+        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the viridian flag");
+            goto out;
+        }
     }
 
     if ( !callbacks->checkpoint )
diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 15:28:14 2011 +0000
@@ -134,6 +134,7 @@
 #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
+#define XC_SAVE_ID_HVM_VIRIDIAN       -11
 
 /*
 ** We process save/restore/migrate in batches of pages; the below

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:31:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxjr-0005Ju-Ky; Fri, 25 Nov 2011 15:30:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxjq-0005Im-86
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:30:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322235020!4629748!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14263 invoked from network); 25 Nov 2011 15:30:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:30:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:30:19 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 25 Nov 2011
	15:30:20 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 15:30:19 +0000
Thread-Topic: [PATCH] Fix save/restore for HVM domains with viridian=1
Thread-Index: Acyrhwfe2MB10kysR+SQTKzPCytbHQAABNCQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4CEF@LONPMAILBOX01.citrite.net>
References: <b50479d64deea72b1100.1322234965@cosworth.uk.xensource.com>
In-Reply-To: <b50479d64deea72b1100.1322234965@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry, ignore this one. I need to fix the comment.

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 25 November 2011 15:29
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH] Fix save/restore for HVM domains with viridian=1
> 
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1322234894 0 #
> Node ID b50479d64deea72b11008fd444aa951737b2573d
> # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> Fix save/restore for HVM domains with viridian=1
> 
> xc_domain_save/restore currently pay no attention to
> HVM_PARAM_VIRIDIAN which results in an HVM domain running a recent
> version on Windows (post-Vista) locking up on a domain restore due
> to EOIs (done via a viridian MSR write) being silently dropped.
> This patch adds an extra save entry for the viridian parameter and
> also adds code in the viridian kernel module to catch attempted use
> of viridian functionality when the HVM parameter has not been set.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011
> +0000
> +++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 15:28:14 2011
> +0000
> @@ -675,6 +675,7 @@ typedef struct {
>      uint64_t vm86_tss;
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
> +    uint64_t viridian;
>  } pagebuf_t;
> 
>  static int pagebuf_init(pagebuf_t* buf) @@ -809,6 +810,16 @@ static
> int pagebuf_get_one(xc_interface
>          }
>          return pagebuf_get_one(xch, ctx, buf, fd, dom);
> 
> +    case XC_SAVE_ID_HVM_VIRIDIAN:
> +        /* Skip padding 4 bytes then read the viridian flag. */
> +        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the viridian flag");
> +            return -1;
> +        }
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.",
> count); @@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface
> *xch,
>              fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
>      }
> 
> +    if (pagebuf.viridian != 0)
> +        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
> +
>      if (pagebuf.acpi_ioport_location == 1) {
>          DBGPRINTF("Use new firmware ioport from the checkpoint\n");
>          xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION,
> 1); diff -r 0a0c02a61676 -r b50479d64dee
> tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 15:28:14 2011 +0000
> @@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
>              PERROR("Error when writing the firmware ioport
> version");
>              goto out;
>          }
> +
> +        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
> +        chunk.data = 0;
> +        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
> +                         (unsigned long *)&chunk.data);
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the viridian flag");
> +            goto out;
> +        }
>      }
> 
>      if ( !callbacks->checkpoint )
> diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011
> +0000
> +++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 15:28:14 2011
> +0000
> @@ -134,6 +134,7 @@
>  #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring
> after completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> +#define XC_SAVE_ID_HVM_VIRIDIAN       -11
> 
>  /*
>  ** We process save/restore/migrate in batches of pages; the below

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:31:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxjr-0005Ju-Ky; Fri, 25 Nov 2011 15:30:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxjq-0005Im-86
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:30:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322235020!4629748!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14263 invoked from network); 25 Nov 2011 15:30:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:30:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:30:19 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 25 Nov 2011
	15:30:20 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 15:30:19 +0000
Thread-Topic: [PATCH] Fix save/restore for HVM domains with viridian=1
Thread-Index: Acyrhwfe2MB10kysR+SQTKzPCytbHQAABNCQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4CEF@LONPMAILBOX01.citrite.net>
References: <b50479d64deea72b1100.1322234965@cosworth.uk.xensource.com>
In-Reply-To: <b50479d64deea72b1100.1322234965@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry, ignore this one. I need to fix the comment.

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 25 November 2011 15:29
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH] Fix save/restore for HVM domains with viridian=1
> 
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1322234894 0 #
> Node ID b50479d64deea72b11008fd444aa951737b2573d
> # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> Fix save/restore for HVM domains with viridian=1
> 
> xc_domain_save/restore currently pay no attention to
> HVM_PARAM_VIRIDIAN which results in an HVM domain running a recent
> version on Windows (post-Vista) locking up on a domain restore due
> to EOIs (done via a viridian MSR write) being silently dropped.
> This patch adds an extra save entry for the viridian parameter and
> also adds code in the viridian kernel module to catch attempted use
> of viridian functionality when the HVM parameter has not been set.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011
> +0000
> +++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 15:28:14 2011
> +0000
> @@ -675,6 +675,7 @@ typedef struct {
>      uint64_t vm86_tss;
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
> +    uint64_t viridian;
>  } pagebuf_t;
> 
>  static int pagebuf_init(pagebuf_t* buf) @@ -809,6 +810,16 @@ static
> int pagebuf_get_one(xc_interface
>          }
>          return pagebuf_get_one(xch, ctx, buf, fd, dom);
> 
> +    case XC_SAVE_ID_HVM_VIRIDIAN:
> +        /* Skip padding 4 bytes then read the viridian flag. */
> +        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the viridian flag");
> +            return -1;
> +        }
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.",
> count); @@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface
> *xch,
>              fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
>      }
> 
> +    if (pagebuf.viridian != 0)
> +        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
> +
>      if (pagebuf.acpi_ioport_location == 1) {
>          DBGPRINTF("Use new firmware ioport from the checkpoint\n");
>          xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION,
> 1); diff -r 0a0c02a61676 -r b50479d64dee
> tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 15:28:14 2011 +0000
> @@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
>              PERROR("Error when writing the firmware ioport
> version");
>              goto out;
>          }
> +
> +        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
> +        chunk.data = 0;
> +        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
> +                         (unsigned long *)&chunk.data);
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the viridian flag");
> +            goto out;
> +        }
>      }
> 
>      if ( !callbacks->checkpoint )
> diff -r 0a0c02a61676 -r b50479d64dee tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011
> +0000
> +++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 15:28:14 2011
> +0000
> @@ -134,6 +134,7 @@
>  #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring
> after completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> +#define XC_SAVE_ID_HVM_VIRIDIAN       -11
> 
>  /*
>  ** We process save/restore/migrate in batches of pages; the below

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:31:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxkO-0005PW-Ef; Fri, 25 Nov 2011 15:31:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxkM-0005OL-0z
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:31:26 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322235052!4632414!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16784 invoked from network); 25 Nov 2011 15:30:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:30:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171877658"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:30:52 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 10:30:51 -0500
MIME-Version: 1.0
X-Mercurial-Node: 2a8ef49f60cfe5a6c4c9f434af472ab58a125a7a
Message-ID: <2a8ef49f60cfe5a6c4c9.1322235046@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 15:30:46 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix save/restore for HVM domains with viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322235040 0
# Node ID 2a8ef49f60cfe5a6c4c9f434af472ab58a125a7a
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Fix save/restore for HVM domains with viridian=1

xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
results in an HVM domain running a recent version on Windows (post-Vista)
locking up on a domain restore due to EOIs (done via a viridian MSR write)
being silently dropped.
This patch adds an extra save entry for the viridian parameter.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 15:30:40 2011 +0000
@@ -675,6 +675,7 @@ typedef struct {
     uint64_t vm86_tss;
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
+    uint64_t viridian;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_VIRIDIAN:
+        /* Skip padding 4 bytes then read the viridian flag. */
+        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
+        {
+            PERROR("error read the viridian flag");
+            return -1;
+        }
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
             fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
     }
 
+    if (pagebuf.viridian != 0)
+        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
+
     if (pagebuf.acpi_ioport_location == 1) {
         DBGPRINTF("Use new firmware ioport from the checkpoint\n");
         xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 15:30:40 2011 +0000
@@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
             PERROR("Error when writing the firmware ioport version");
             goto out;
         }
+
+        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the viridian flag");
+            goto out;
+        }
     }
 
     if ( !callbacks->checkpoint )
diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 15:30:40 2011 +0000
@@ -134,6 +134,7 @@
 #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
+#define XC_SAVE_ID_HVM_VIRIDIAN       -11
 
 /*
 ** We process save/restore/migrate in batches of pages; the below

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:31:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxkO-0005PW-Ef; Fri, 25 Nov 2011 15:31:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxkM-0005OL-0z
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:31:26 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322235052!4632414!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16784 invoked from network); 25 Nov 2011 15:30:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:30:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171877658"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 10:30:52 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 10:30:51 -0500
MIME-Version: 1.0
X-Mercurial-Node: 2a8ef49f60cfe5a6c4c9f434af472ab58a125a7a
Message-ID: <2a8ef49f60cfe5a6c4c9.1322235046@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 15:30:46 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix save/restore for HVM domains with viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322235040 0
# Node ID 2a8ef49f60cfe5a6c4c9f434af472ab58a125a7a
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Fix save/restore for HVM domains with viridian=1

xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
results in an HVM domain running a recent version on Windows (post-Vista)
locking up on a domain restore due to EOIs (done via a viridian MSR write)
being silently dropped.
This patch adds an extra save entry for the viridian parameter.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Fri Nov 25 15:30:40 2011 +0000
@@ -675,6 +675,7 @@ typedef struct {
     uint64_t vm86_tss;
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
+    uint64_t viridian;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_VIRIDIAN:
+        /* Skip padding 4 bytes then read the viridian flag. */
+        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
+        {
+            PERROR("error read the viridian flag");
+            return -1;
+        }
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
             fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
     }
 
+    if (pagebuf.viridian != 0)
+        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
+
     if (pagebuf.acpi_ioport_location == 1) {
         DBGPRINTF("Use new firmware ioport from the checkpoint\n");
         xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Fri Nov 25 15:30:40 2011 +0000
@@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
             PERROR("Error when writing the firmware ioport version");
             goto out;
         }
+
+        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
+                         (unsigned long *)&chunk.data);
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the viridian flag");
+            goto out;
+        }
     }
 
     if ( !callbacks->checkpoint )
diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Mon Nov 21 21:28:34 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Fri Nov 25 15:30:40 2011 +0000
@@ -134,6 +134,7 @@
 #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
+#define XC_SAVE_ID_HVM_VIRIDIAN       -11
 
 /*
 ** We process save/restore/migrate in batches of pages; the below

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:36:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:36:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxpW-0005sU-Gr; Fri, 25 Nov 2011 15:36:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTxpV-0005sP-3d
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:36:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322235372!5596578!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10308 invoked from network); 25 Nov 2011 15:36:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 15:36:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 15:36:11 +0000
Message-Id: <4ECFC3F902000078000635FF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 15:36:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4ECFB05B.2060501@citrix.com>
In-Reply-To: <4ECFB05B.2060501@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
 the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>Before this patch, using "classic" crashdump= syntax (<size>@<start>)
>causes an exact size and location to be reserved in the e820 map
>before Xen and modules are relocated.  However, using "new" syntax
>(<start>-[<end>]:<size>) encounteres a myriad of problems, most
>notibly not considering the range when allocating its region.

I'm sure I tested this (with some basic values), so the "myriad of
problems" make me curious as to what they are.

What does "range" refer to here, and what is "its region"?

You also seem to overlook that even the old syntax allowed for only
specifying a size.

>This patch tries to unify both codepaths, and fix the broken logic
>when using "newer" syntax.
>
>Changes addressed:
>
>1) Remove use of kexec_crash_area from parse_crashkernel().
>     Use ranges[0] in preference, as there is no support for multiple
>     ranges using classic syntax.  This prevents some wierd logic in
>     __setup_xen() depending on whether kexec_crash_area.size is set
>     or not.

What weird about that?

>2) Change set_kexec_crash_area_size() to choose_kexec_range()
>     The new method of choosing a range provides an entire rather than

And entire what?

>     just setting kexec_crash_area.size.  Also, fix the very broken
>     logic which will only consider a range if its .end is greater
>     than system_ram.

Where's that happening? Are you perhaps mis-interpreting the
purpose of these ranges?

>  Additionally, prefer range with the largest
>     size if we have a choice of valid ones, and prefer ranges with
>     more flexibility in their limits.
>
>3) Move kexec_reserve_area() from setup.c to kexec.c
>     It makes more sense here, Also, change its functionality a little
>     to always work from the kexec range provided by choose_kexec_range()
>
>4) Remove the kexec reservation code when considering modules
>     This code only had any effect for people using the "newer" syntax
>     on the command line, as people using the "classic" syntax would
>     reserve a memory region before considering modules.

Are you sure? How do you prevent the kexec area from overlapping
any of the modules (in particular the initrd, which can get passed in
place to Dom0)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:36:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:36:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxpW-0005sU-Gr; Fri, 25 Nov 2011 15:36:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTxpV-0005sP-3d
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:36:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322235372!5596578!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10308 invoked from network); 25 Nov 2011 15:36:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 15:36:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 15:36:11 +0000
Message-Id: <4ECFC3F902000078000635FF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 15:36:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4ECFB05B.2060501@citrix.com>
In-Reply-To: <4ECFB05B.2060501@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
 the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>Before this patch, using "classic" crashdump= syntax (<size>@<start>)
>causes an exact size and location to be reserved in the e820 map
>before Xen and modules are relocated.  However, using "new" syntax
>(<start>-[<end>]:<size>) encounteres a myriad of problems, most
>notibly not considering the range when allocating its region.

I'm sure I tested this (with some basic values), so the "myriad of
problems" make me curious as to what they are.

What does "range" refer to here, and what is "its region"?

You also seem to overlook that even the old syntax allowed for only
specifying a size.

>This patch tries to unify both codepaths, and fix the broken logic
>when using "newer" syntax.
>
>Changes addressed:
>
>1) Remove use of kexec_crash_area from parse_crashkernel().
>     Use ranges[0] in preference, as there is no support for multiple
>     ranges using classic syntax.  This prevents some wierd logic in
>     __setup_xen() depending on whether kexec_crash_area.size is set
>     or not.

What weird about that?

>2) Change set_kexec_crash_area_size() to choose_kexec_range()
>     The new method of choosing a range provides an entire rather than

And entire what?

>     just setting kexec_crash_area.size.  Also, fix the very broken
>     logic which will only consider a range if its .end is greater
>     than system_ram.

Where's that happening? Are you perhaps mis-interpreting the
purpose of these ranges?

>  Additionally, prefer range with the largest
>     size if we have a choice of valid ones, and prefer ranges with
>     more flexibility in their limits.
>
>3) Move kexec_reserve_area() from setup.c to kexec.c
>     It makes more sense here, Also, change its functionality a little
>     to always work from the kexec range provided by choose_kexec_range()
>
>4) Remove the kexec reservation code when considering modules
>     This code only had any effect for people using the "newer" syntax
>     on the command line, as people using the "classic" syntax would
>     reserve a memory region before considering modules.

Are you sure? How do you prevent the kexec area from overlapping
any of the modules (in particular the initrd, which can get passed in
place to Dom0)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:40:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxst-00064t-6H; Fri, 25 Nov 2011 15:40:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTxsr-00064T-JB
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:40:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322235580!3044022!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29135 invoked from network); 25 Nov 2011 15:39:41 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:39:41 -0000
Received: by bkbzt12 with SMTP id zt12so5945071bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 07:39:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=c1baQ6NbLDXrso8XPl7u+fY9+79Q07hpDV5LlGTZ6Qc=;
	b=AV8bbFiziXBhhUMjZXkR7nPWmbQrBImDZPFGmSrzPyalLDwqRTRmOXX8BZgXXP+JXE
	MkIre/YcOfIgcF5UIMS+Kz0WmwzByIUdrUjdVQ4ldDBb5OHcQHiCBV52ZSfKAPrI73zi
	gWlIndMltALPclHl+NirHrdbuXXxOECPSh72U=
Received: by 10.204.15.208 with SMTP id l16mr29043802bka.100.1322235580728;
	Fri, 25 Nov 2011 07:39:40 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id x14sm19112256bkf.10.2011.11.25.07.39.39
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 07:39:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 15:39:38 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAF5673A.25AAA%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyriHCaq0HLgXnVVUyUli2J/8YsqA==
In-Reply-To: <2a8ef49f60cfe5a6c4c9.1322235046@cosworth.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 15:30, "Paul Durrant" <paul.durrant@citrix.com> wrote:

> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322235040 0
> # Node ID 2a8ef49f60cfe5a6c4c9f434af472ab58a125a7a
> # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> Fix save/restore for HVM domains with viridian=1
> 
> xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
> results in an HVM domain running a recent version on Windows (post-Vista)
> locking up on a domain restore due to EOIs (done via a viridian MSR write)
> being silently dropped.
> This patch adds an extra save entry for the viridian parameter.

Ok, I did check in the previous with the intention of fixing up the Xen
bits. Is the best fix now agreed to just remove the Xen bits? :-) I can
check in a patch to do that if so.

 -- Keir

> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_restore.c Fri Nov 25 15:30:40 2011 +0000
> @@ -675,6 +675,7 @@ typedef struct {
>      uint64_t vm86_tss;
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
> +    uint64_t viridian;
>  } pagebuf_t;
>  
>  static int pagebuf_init(pagebuf_t* buf)
> @@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface
>          }
>          return pagebuf_get_one(xch, ctx, buf, fd, dom);
>  
> +    case XC_SAVE_ID_HVM_VIRIDIAN:
> +        /* Skip padding 4 bytes then read the viridian flag. */
> +        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the viridian flag");
> +            return -1;
> +        }
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.", count);
> @@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
>              fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
>      }
>  
> +    if (pagebuf.viridian != 0)
> +        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
> +
>      if (pagebuf.acpi_ioport_location == 1) {
>          DBGPRINTF("Use new firmware ioport from the checkpoint\n");
>          xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
> diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_save.c Fri Nov 25 15:30:40 2011 +0000
> @@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
>              PERROR("Error when writing the firmware ioport version");
>              goto out;
>          }
> +
> +        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
> +        chunk.data = 0;
> +        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
> +                         (unsigned long *)&chunk.data);
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the viridian flag");
> +            goto out;
> +        }
>      }
>  
>      if ( !callbacks->checkpoint )
> diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xg_save_restore.h Fri Nov 25 15:30:40 2011 +0000
> @@ -134,6 +134,7 @@
>  #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after
> completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> +#define XC_SAVE_ID_HVM_VIRIDIAN       -11
>  
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:40:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxst-00064t-6H; Fri, 25 Nov 2011 15:40:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RTxsr-00064T-JB
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:40:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322235580!3044022!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29135 invoked from network); 25 Nov 2011 15:39:41 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:39:41 -0000
Received: by bkbzt12 with SMTP id zt12so5945071bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 07:39:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=c1baQ6NbLDXrso8XPl7u+fY9+79Q07hpDV5LlGTZ6Qc=;
	b=AV8bbFiziXBhhUMjZXkR7nPWmbQrBImDZPFGmSrzPyalLDwqRTRmOXX8BZgXXP+JXE
	MkIre/YcOfIgcF5UIMS+Kz0WmwzByIUdrUjdVQ4ldDBb5OHcQHiCBV52ZSfKAPrI73zi
	gWlIndMltALPclHl+NirHrdbuXXxOECPSh72U=
Received: by 10.204.15.208 with SMTP id l16mr29043802bka.100.1322235580728;
	Fri, 25 Nov 2011 07:39:40 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id x14sm19112256bkf.10.2011.11.25.07.39.39
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 07:39:39 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 15:39:38 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAF5673A.25AAA%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyriHCaq0HLgXnVVUyUli2J/8YsqA==
In-Reply-To: <2a8ef49f60cfe5a6c4c9.1322235046@cosworth.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 15:30, "Paul Durrant" <paul.durrant@citrix.com> wrote:

> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322235040 0
> # Node ID 2a8ef49f60cfe5a6c4c9f434af472ab58a125a7a
> # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> Fix save/restore for HVM domains with viridian=1
> 
> xc_domain_save/restore currently pay no attention to HVM_PARAM_VIRIDIAN which
> results in an HVM domain running a recent version on Windows (post-Vista)
> locking up on a domain restore due to EOIs (done via a viridian MSR write)
> being silently dropped.
> This patch adds an extra save entry for the viridian parameter.

Ok, I did check in the previous with the intention of fixing up the Xen
bits. Is the best fix now agreed to just remove the Xen bits? :-) I can
check in a patch to do that if so.

 -- Keir

> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_restore.c Fri Nov 25 15:30:40 2011 +0000
> @@ -675,6 +675,7 @@ typedef struct {
>      uint64_t vm86_tss;
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
> +    uint64_t viridian;
>  } pagebuf_t;
>  
>  static int pagebuf_init(pagebuf_t* buf)
> @@ -809,6 +810,16 @@ static int pagebuf_get_one(xc_interface
>          }
>          return pagebuf_get_one(xch, ctx, buf, fd, dom);
>  
> +    case XC_SAVE_ID_HVM_VIRIDIAN:
> +        /* Skip padding 4 bytes then read the viridian flag. */
> +        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the viridian flag");
> +            return -1;
> +        }
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.", count);
> @@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
>              fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
>      }
>  
> +    if (pagebuf.viridian != 0)
> +        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
> +
>      if (pagebuf.acpi_ioport_location == 1) {
>          DBGPRINTF("Use new firmware ioport from the checkpoint\n");
>          xc_set_hvm_param(xch, dom, HVM_PARAM_ACPI_IOPORTS_LOCATION, 1);
> diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xc_domain_save.c Fri Nov 25 15:30:40 2011 +0000
> @@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
>              PERROR("Error when writing the firmware ioport version");
>              goto out;
>          }
> +
> +        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
> +        chunk.data = 0;
> +        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
> +                         (unsigned long *)&chunk.data);
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the viridian flag");
> +            goto out;
> +        }
>      }
>  
>      if ( !callbacks->checkpoint )
> diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h Mon Nov 21 21:28:34 2011 +0000
> +++ b/tools/libxc/xg_save_restore.h Fri Nov 25 15:30:40 2011 +0000
> @@ -134,6 +134,7 @@
>  #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after
> completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> +#define XC_SAVE_ID_HVM_VIRIDIAN       -11
>  
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:41:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:41:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxtc-00068L-LX; Fri, 25 Nov 2011 15:41:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTxta-00067g-Qt
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:40:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322235625!4640805!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 473 invoked from network); 25 Nov 2011 15:40:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:40:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 15:40:22 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTxt0-00068W-42;
	Fri, 25 Nov 2011 15:40:22 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTxt0-0001xP-0g;
	Fri, 25 Nov 2011 15:40:22 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10045-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 15:40:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10045: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10045 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10045/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-win         14 guest-start.2               fail pass in 10032

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate           fail    like 9951
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-sedf      5 xen-boot               fail in 10032 like 9955
 test-i386-i386-win           14 guest-start.2          fail in 10032 like 9955
 test-amd64-amd64-win         16 leak-check/check      fail in 10032 never pass

version targeted for testing:
 xen                  1027e7d13d02
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 847 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:41:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:41:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxtc-00068L-LX; Fri, 25 Nov 2011 15:41:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RTxta-00067g-Qt
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:40:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322235625!4640805!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 473 invoked from network); 25 Nov 2011 15:40:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:40:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:40:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 15:40:22 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RTxt0-00068W-42;
	Fri, 25 Nov 2011 15:40:22 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RTxt0-0001xP-0g;
	Fri, 25 Nov 2011 15:40:22 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10045-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 15:40:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10045: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10045 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10045/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-win         14 guest-start.2               fail pass in 10032

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate           fail    like 9951
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-sedf      5 xen-boot               fail in 10032 like 9955
 test-i386-i386-win           14 guest-start.2          fail in 10032 like 9955
 test-amd64-amd64-win         16 leak-check/check      fail in 10032 never pass

version targeted for testing:
 xen                  1027e7d13d02
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 847 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:43:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxvr-0006Wv-Ht; Fri, 25 Nov 2011 15:43:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxvq-0006Vj-Kt
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:43:18 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322235646!45832687!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13561 invoked from network); 25 Nov 2011 15:40:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:40:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133925"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:42:45 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 25 Nov 2011
	15:42:45 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 15:42:45 +0000
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyriHCaq0HLgXnVVUyUli2J/8YsqAAAGFYw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4CF1@LONPMAILBOX01.citrite.net>
References: <2a8ef49f60cfe5a6c4c9.1322235046@cosworth.uk.xensource.com>
	<CAF5673A.25AAA%keir.xen@gmail.com>
In-Reply-To: <CAF5673A.25AAA%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir,

  Yes, just ditch the kernel change.

  Paul

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: 25 November 2011 15:40
> To: Paul Durrant; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains
> with viridian=1
> 
> On 25/11/2011 15:30, "Paul Durrant" <paul.durrant@citrix.com> wrote:
> 
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1322235040 0
> #
> > Node ID 2a8ef49f60cfe5a6c4c9f434af472ab58a125a7a
> > # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> > Fix save/restore for HVM domains with viridian=1
> >
> > xc_domain_save/restore currently pay no attention to
> > HVM_PARAM_VIRIDIAN which results in an HVM domain running a recent
> > version on Windows (post-Vista) locking up on a domain restore due
> to
> > EOIs (done via a viridian MSR write) being silently dropped.
> > This patch adds an extra save entry for the viridian parameter.
> 
> Ok, I did check in the previous with the intention of fixing up the
> Xen bits. Is the best fix now agreed to just remove the Xen bits? :-
> ) I can check in a patch to do that if so.
> 
>  -- Keir
> 
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >
> > diff -r 0a0c02a61676 -r 2a8ef49f60cf
> tools/libxc/xc_domain_restore.c
> > --- a/tools/libxc/xc_domain_restore.c Mon Nov 21 21:28:34 2011
> +0000
> > +++ b/tools/libxc/xc_domain_restore.c Fri Nov 25 15:30:40 2011
> +0000
> > @@ -675,6 +675,7 @@ typedef struct {
> >      uint64_t vm86_tss;
> >      uint64_t console_pfn;
> >      uint64_t acpi_ioport_location;
> > +    uint64_t viridian;
> >  } pagebuf_t;
> >
> >  static int pagebuf_init(pagebuf_t* buf) @@ -809,6 +810,16 @@
> static
> > int pagebuf_get_one(xc_interface
> >          }
> >          return pagebuf_get_one(xch, ctx, buf, fd, dom);
> >
> > +    case XC_SAVE_ID_HVM_VIRIDIAN:
> > +        /* Skip padding 4 bytes then read the viridian flag. */
> > +        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
> > +             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
> > +        {
> > +            PERROR("error read the viridian flag");
> > +            return -1;
> > +        }
> > +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > +
> >      default:
> >          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
> >              ERROR("Max batch size exceeded (%d). Giving up.",
> count);
> > @@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
> >              fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
> >      }
> >
> > +    if (pagebuf.viridian != 0)
> > +        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
> > +
> >      if (pagebuf.acpi_ioport_location == 1) {
> >          DBGPRINTF("Use new firmware ioport from the
> checkpoint\n");
> >          xc_set_hvm_param(xch, dom,
> HVM_PARAM_ACPI_IOPORTS_LOCATION,
> > 1); diff -r 0a0c02a61676 -r 2a8ef49f60cf
> tools/libxc/xc_domain_save.c
> > --- a/tools/libxc/xc_domain_save.c Mon Nov 21 21:28:34 2011 +0000
> > +++ b/tools/libxc/xc_domain_save.c Fri Nov 25 15:30:40 2011 +0000
> > @@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
> >              PERROR("Error when writing the firmware ioport
> version");
> >              goto out;
> >          }
> > +
> > +        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
> > +        chunk.data = 0;
> > +        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
> > +                         (unsigned long *)&chunk.data);
> > +
> > +        if ( (chunk.data != 0) &&
> > +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> > +        {
> > +            PERROR("Error when writing the viridian flag");
> > +            goto out;
> > +        }
> >      }
> >
> >      if ( !callbacks->checkpoint )
> > diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xg_save_restore.h
> > --- a/tools/libxc/xg_save_restore.h Mon Nov 21 21:28:34 2011 +0000
> > +++ b/tools/libxc/xg_save_restore.h Fri Nov 25 15:30:40 2011 +0000
> > @@ -134,6 +134,7 @@
> >  #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
> >  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring
> after
> > completion of current iteration. */
> >  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> > +#define XC_SAVE_ID_HVM_VIRIDIAN       -11
> >
> >  /*
> >  ** We process save/restore/migrate in batches of pages; the below
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:43:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:43:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxvr-0006Wv-Ht; Fri, 25 Nov 2011 15:43:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTxvq-0006Vj-Kt
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:43:18 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322235646!45832687!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13561 invoked from network); 25 Nov 2011 15:40:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:40:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133925"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:42:45 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 25 Nov 2011
	15:42:45 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 15:42:45 +0000
Thread-Topic: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
	viridian=1
Thread-Index: AcyriHCaq0HLgXnVVUyUli2J/8YsqAAAGFYw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4CF1@LONPMAILBOX01.citrite.net>
References: <2a8ef49f60cfe5a6c4c9.1322235046@cosworth.uk.xensource.com>
	<CAF5673A.25AAA%keir.xen@gmail.com>
In-Reply-To: <CAF5673A.25AAA%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains with
 viridian=1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir,

  Yes, just ditch the kernel change.

  Paul

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: 25 November 2011 15:40
> To: Paul Durrant; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Fix save/restore for HVM domains
> with viridian=1
> 
> On 25/11/2011 15:30, "Paul Durrant" <paul.durrant@citrix.com> wrote:
> 
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1322235040 0
> #
> > Node ID 2a8ef49f60cfe5a6c4c9f434af472ab58a125a7a
> > # Parent  0a0c02a616768bfab16c072788cb76be1893c37f
> > Fix save/restore for HVM domains with viridian=1
> >
> > xc_domain_save/restore currently pay no attention to
> > HVM_PARAM_VIRIDIAN which results in an HVM domain running a recent
> > version on Windows (post-Vista) locking up on a domain restore due
> to
> > EOIs (done via a viridian MSR write) being silently dropped.
> > This patch adds an extra save entry for the viridian parameter.
> 
> Ok, I did check in the previous with the intention of fixing up the
> Xen bits. Is the best fix now agreed to just remove the Xen bits? :-
> ) I can check in a patch to do that if so.
> 
>  -- Keir
> 
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> >
> > diff -r 0a0c02a61676 -r 2a8ef49f60cf
> tools/libxc/xc_domain_restore.c
> > --- a/tools/libxc/xc_domain_restore.c Mon Nov 21 21:28:34 2011
> +0000
> > +++ b/tools/libxc/xc_domain_restore.c Fri Nov 25 15:30:40 2011
> +0000
> > @@ -675,6 +675,7 @@ typedef struct {
> >      uint64_t vm86_tss;
> >      uint64_t console_pfn;
> >      uint64_t acpi_ioport_location;
> > +    uint64_t viridian;
> >  } pagebuf_t;
> >
> >  static int pagebuf_init(pagebuf_t* buf) @@ -809,6 +810,16 @@
> static
> > int pagebuf_get_one(xc_interface
> >          }
> >          return pagebuf_get_one(xch, ctx, buf, fd, dom);
> >
> > +    case XC_SAVE_ID_HVM_VIRIDIAN:
> > +        /* Skip padding 4 bytes then read the viridian flag. */
> > +        if ( RDEXACT(fd, &buf->viridian, sizeof(uint32_t)) ||
> > +             RDEXACT(fd, &buf->viridian, sizeof(uint64_t)) )
> > +        {
> > +            PERROR("error read the viridian flag");
> > +            return -1;
> > +        }
> > +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > +
> >      default:
> >          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
> >              ERROR("Max batch size exceeded (%d). Giving up.",
> count);
> > @@ -1440,6 +1451,9 @@ int xc_domain_restore(xc_interface *xch,
> >              fcntl(io_fd, F_SETFL, orig_io_fd_flags | O_NONBLOCK);
> >      }
> >
> > +    if (pagebuf.viridian != 0)
> > +        xc_set_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN, 1);
> > +
> >      if (pagebuf.acpi_ioport_location == 1) {
> >          DBGPRINTF("Use new firmware ioport from the
> checkpoint\n");
> >          xc_set_hvm_param(xch, dom,
> HVM_PARAM_ACPI_IOPORTS_LOCATION,
> > 1); diff -r 0a0c02a61676 -r 2a8ef49f60cf
> tools/libxc/xc_domain_save.c
> > --- a/tools/libxc/xc_domain_save.c Mon Nov 21 21:28:34 2011 +0000
> > +++ b/tools/libxc/xc_domain_save.c Fri Nov 25 15:30:40 2011 +0000
> > @@ -1506,6 +1506,18 @@ int xc_domain_save(xc_interface *xch, in
> >              PERROR("Error when writing the firmware ioport
> version");
> >              goto out;
> >          }
> > +
> > +        chunk.id = XC_SAVE_ID_HVM_VIRIDIAN;
> > +        chunk.data = 0;
> > +        xc_get_hvm_param(xch, dom, HVM_PARAM_VIRIDIAN,
> > +                         (unsigned long *)&chunk.data);
> > +
> > +        if ( (chunk.data != 0) &&
> > +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> > +        {
> > +            PERROR("Error when writing the viridian flag");
> > +            goto out;
> > +        }
> >      }
> >
> >      if ( !callbacks->checkpoint )
> > diff -r 0a0c02a61676 -r 2a8ef49f60cf tools/libxc/xg_save_restore.h
> > --- a/tools/libxc/xg_save_restore.h Mon Nov 21 21:28:34 2011 +0000
> > +++ b/tools/libxc/xg_save_restore.h Fri Nov 25 15:30:40 2011 +0000
> > @@ -134,6 +134,7 @@
> >  #define XC_SAVE_ID_HVM_CONSOLE_PFN    -8 /* (HVM-only) */
> >  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring
> after
> > completion of current iteration. */
> >  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
> > +#define XC_SAVE_ID_HVM_VIRIDIAN       -11
> >
> >  /*
> >  ** We process save/restore/migrate in batches of pages; the below
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:44:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxww-0006eq-25; Fri, 25 Nov 2011 15:44:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTxwu-0006e3-C0
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:44:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322235831!3031759!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30238 invoked from network); 25 Nov 2011 15:43:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:43:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133952"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:43:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 15:43:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Fri, 25 Nov 2011 15:43:51 +0000
In-Reply-To: <4ECFB2AB.8070005@amd.com>
References: <b4c07fbe3557ae501fc2.1322233898@cosworth.uk.xensource.com>
	<4ECFB2AB.8070005@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322235831.1005.269.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH] docs: xlexample.hvm: mention the viridian
 setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 15:22 +0000, Christoph Egger wrote:
> On 11/25/11 16:11, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell<ian.campbell@citrix.com>
> > # Date 1322233890 0
> > # Node ID b4c07fbe3557ae501fc2d8a21b41f1b1cd5198cb
> > # Parent  31e71820ce93b72b0223882f6c2e1f461920bda9
> > docs: xlexample.hvm: mention the viridian setting.
> >
> > Turning this on for Windows guests is recommended.
> 
> Actually, Hyper-V fails to boot with viridian=1 because our
> viridian implementation misses features such as the virtualized
> LAPIC interface.

You mean booting a Viridian _Host_ as a Nested HVM guest?

I'm not sure I can make that distinction clearly and concisely enough to
be useful in this context nor that this is something for a regular user
to worry about.

If you want to propose an update to the xl.cfg(5) man page I posted we
could see how that looks.

Ian.

> 
> Christoph
> 
> 
> >
> > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> >
> > diff -r 31e71820ce93 -r b4c07fbe3557 tools/examples/xlexample.hvm
> > --- a/tools/examples/xlexample.hvm	Fri Nov 25 14:44:10 2011 +0000
> > +++ b/tools/examples/xlexample.hvm	Fri Nov 25 15:11:30 2011 +0000
> > @@ -16,6 +16,11 @@ name = "example.hvm"
> >   # The default behavior is to generate a new UUID each time the guest is started.
> >   #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
> >
> > +# Enable Microsoft Hyper-V compatibile paravirtualisation /
> > +# enlightenment interfaces. Turning this on can improve Windows guest
> > +# performance and is therefore recommended
> > +#viridian = 1
> > +
> >   # Initial memory allocation (MB)
> >   memory = 128
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 15:44:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 15:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTxww-0006eq-25; Fri, 25 Nov 2011 15:44:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTxwu-0006e3-C0
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 15:44:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322235831!3031759!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30238 invoked from network); 25 Nov 2011 15:43:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 15:43:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9133952"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 15:43:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 15:43:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Fri, 25 Nov 2011 15:43:51 +0000
In-Reply-To: <4ECFB2AB.8070005@amd.com>
References: <b4c07fbe3557ae501fc2.1322233898@cosworth.uk.xensource.com>
	<4ECFB2AB.8070005@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322235831.1005.269.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH] docs: xlexample.hvm: mention the viridian
 setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 15:22 +0000, Christoph Egger wrote:
> On 11/25/11 16:11, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell<ian.campbell@citrix.com>
> > # Date 1322233890 0
> > # Node ID b4c07fbe3557ae501fc2d8a21b41f1b1cd5198cb
> > # Parent  31e71820ce93b72b0223882f6c2e1f461920bda9
> > docs: xlexample.hvm: mention the viridian setting.
> >
> > Turning this on for Windows guests is recommended.
> 
> Actually, Hyper-V fails to boot with viridian=1 because our
> viridian implementation misses features such as the virtualized
> LAPIC interface.

You mean booting a Viridian _Host_ as a Nested HVM guest?

I'm not sure I can make that distinction clearly and concisely enough to
be useful in this context nor that this is something for a regular user
to worry about.

If you want to propose an update to the xl.cfg(5) man page I posted we
could see how that looks.

Ian.

> 
> Christoph
> 
> 
> >
> > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> >
> > diff -r 31e71820ce93 -r b4c07fbe3557 tools/examples/xlexample.hvm
> > --- a/tools/examples/xlexample.hvm	Fri Nov 25 14:44:10 2011 +0000
> > +++ b/tools/examples/xlexample.hvm	Fri Nov 25 15:11:30 2011 +0000
> > @@ -16,6 +16,11 @@ name = "example.hvm"
> >   # The default behavior is to generate a new UUID each time the guest is started.
> >   #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
> >
> > +# Enable Microsoft Hyper-V compatibile paravirtualisation /
> > +# enlightenment interfaces. Turning this on can improve Windows guest
> > +# performance and is therefore recommended
> > +#viridian = 1
> > +
> >   # Initial memory allocation (MB)
> >   memory = 128
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:02:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyEB-0007d9-E0; Fri, 25 Nov 2011 16:02:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTyE9-0007cx-Vu
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:02:14 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322236900!4106425!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10909 invoked from network); 25 Nov 2011 16:01:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 16:01:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171880263"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 11:01:40 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 11:01:39 -0500
MIME-Version: 1.0
X-Mercurial-Node: 328f967f13cb22b979842ffd6ca3f075ca6ffe28
Message-ID: <328f967f13cb22b97984.1322236884@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 16:01:24 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Re-instate HVM IRQ debug code and add keyhandler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322236878 0
# Node ID 328f967f13cb22b979842ffd6ca3f075ca6ffe28
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Re-instate HVM IRQ debug code and add keyhandler.

I found this patch useful a couple of times while trying to debug the
viridian problem.
irq_dump() was #ifdef-ed out so this patch puts it back abd registers
a handler on the 'I' key to iterate over all HVM domains and call it.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r 328f967f13cb xen/arch/x86/hvm/irq.c
--- a/xen/arch/x86/hvm/irq.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/xen/arch/x86/hvm/irq.c	Fri Nov 25 16:01:18 2011 +0000
@@ -1,4 +1,4 @@
-/******************************************************************************
+    /******************************************************************************
  * irq.c
  * 
  * Interrupt distribution and delivery logic.
@@ -24,6 +24,7 @@
 #include <xen/event.h>
 #include <xen/sched.h>
 #include <xen/irq.h>
+#include <xen/keyhandler.h>
 #include <asm/hvm/domain.h>
 #include <asm/hvm/support.h>
 #include <asm/msi.h>
@@ -434,11 +435,11 @@ int hvm_local_events_need_delivery(struc
     return !hvm_interrupt_blocked(v, intack);
 }
 
-#if 0 /* Keep for debugging */
 static void irq_dump(struct domain *d)
 {
     struct hvm_irq *hvm_irq = &d->arch.hvm_domain.irq;
     int i; 
+    printk("Domain %d:\n", d->domain_id);
     printk("PCI 0x%16.16"PRIx64"%16.16"PRIx64
            " ISA 0x%8.8"PRIx32" ROUTE %u %u %u %u\n",
            hvm_irq->pci_intx.pad[0],  hvm_irq->pci_intx.pad[1],
@@ -446,8 +447,9 @@ static void irq_dump(struct domain *d)
            hvm_irq->pci_link.route[0], hvm_irq->pci_link.route[1],
            hvm_irq->pci_link.route[2], hvm_irq->pci_link.route[3]);
     for ( i = 0 ; i < VIOAPIC_NUM_PINS; i += 8 )
-        printk("GSI  %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8
+        printk("GSI [%x - %x] %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8
                " %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8"\n",
+               i, i+7,
                hvm_irq->gsi_assert_count[i+0],
                hvm_irq->gsi_assert_count[i+1],
                hvm_irq->gsi_assert_count[i+2],
@@ -465,7 +467,34 @@ static void irq_dump(struct domain *d)
            hvm_irq->callback_via_type, hvm_irq->callback_via.gsi, 
            hvm_irq->callback_via_asserted ? "" : " not");
 }
-#endif
+
+static void dump_irq_info(unsigned char key)
+{
+    struct domain *d;
+
+    printk("'%c' pressed -> dumping HVM irq info\n", key);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain ( d )
+        if ( is_hvm_domain(d) )
+            irq_dump(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+}
+
+static struct keyhandler dump_irq_info_keyhandler = {
+    .diagnostic = 1,
+    .u.fn = dump_irq_info,
+    .desc = "dump HVM irq info"
+};
+
+static int __init dump_irq_info_key_init(void)
+{
+    register_keyhandler('I', &dump_irq_info_keyhandler);
+    return 0;
+}
+__initcall(dump_irq_info_key_init);
 
 static int irq_save_pci(struct domain *d, hvm_domain_context_t *h)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:02:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyEB-0007d9-E0; Fri, 25 Nov 2011 16:02:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTyE9-0007cx-Vu
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:02:14 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322236900!4106425!1
X-Originating-IP: [66.165.176.63]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10909 invoked from network); 25 Nov 2011 16:01:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 16:01:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="171880263"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 11:01:40 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 11:01:39 -0500
MIME-Version: 1.0
X-Mercurial-Node: 328f967f13cb22b979842ffd6ca3f075ca6ffe28
Message-ID: <328f967f13cb22b97984.1322236884@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 25 Nov 2011 16:01:24 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Re-instate HVM IRQ debug code and add keyhandler
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322236878 0
# Node ID 328f967f13cb22b979842ffd6ca3f075ca6ffe28
# Parent  0a0c02a616768bfab16c072788cb76be1893c37f
Re-instate HVM IRQ debug code and add keyhandler.

I found this patch useful a couple of times while trying to debug the
viridian problem.
irq_dump() was #ifdef-ed out so this patch puts it back abd registers
a handler on the 'I' key to iterate over all HVM domains and call it.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 0a0c02a61676 -r 328f967f13cb xen/arch/x86/hvm/irq.c
--- a/xen/arch/x86/hvm/irq.c	Mon Nov 21 21:28:34 2011 +0000
+++ b/xen/arch/x86/hvm/irq.c	Fri Nov 25 16:01:18 2011 +0000
@@ -1,4 +1,4 @@
-/******************************************************************************
+    /******************************************************************************
  * irq.c
  * 
  * Interrupt distribution and delivery logic.
@@ -24,6 +24,7 @@
 #include <xen/event.h>
 #include <xen/sched.h>
 #include <xen/irq.h>
+#include <xen/keyhandler.h>
 #include <asm/hvm/domain.h>
 #include <asm/hvm/support.h>
 #include <asm/msi.h>
@@ -434,11 +435,11 @@ int hvm_local_events_need_delivery(struc
     return !hvm_interrupt_blocked(v, intack);
 }
 
-#if 0 /* Keep for debugging */
 static void irq_dump(struct domain *d)
 {
     struct hvm_irq *hvm_irq = &d->arch.hvm_domain.irq;
     int i; 
+    printk("Domain %d:\n", d->domain_id);
     printk("PCI 0x%16.16"PRIx64"%16.16"PRIx64
            " ISA 0x%8.8"PRIx32" ROUTE %u %u %u %u\n",
            hvm_irq->pci_intx.pad[0],  hvm_irq->pci_intx.pad[1],
@@ -446,8 +447,9 @@ static void irq_dump(struct domain *d)
            hvm_irq->pci_link.route[0], hvm_irq->pci_link.route[1],
            hvm_irq->pci_link.route[2], hvm_irq->pci_link.route[3]);
     for ( i = 0 ; i < VIOAPIC_NUM_PINS; i += 8 )
-        printk("GSI  %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8
+        printk("GSI [%x - %x] %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8
                " %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8" %2.2"PRIu8"\n",
+               i, i+7,
                hvm_irq->gsi_assert_count[i+0],
                hvm_irq->gsi_assert_count[i+1],
                hvm_irq->gsi_assert_count[i+2],
@@ -465,7 +467,34 @@ static void irq_dump(struct domain *d)
            hvm_irq->callback_via_type, hvm_irq->callback_via.gsi, 
            hvm_irq->callback_via_asserted ? "" : " not");
 }
-#endif
+
+static void dump_irq_info(unsigned char key)
+{
+    struct domain *d;
+
+    printk("'%c' pressed -> dumping HVM irq info\n", key);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain ( d )
+        if ( is_hvm_domain(d) )
+            irq_dump(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+}
+
+static struct keyhandler dump_irq_info_keyhandler = {
+    .diagnostic = 1,
+    .u.fn = dump_irq_info,
+    .desc = "dump HVM irq info"
+};
+
+static int __init dump_irq_info_key_init(void)
+{
+    register_keyhandler('I', &dump_irq_info_keyhandler);
+    return 0;
+}
+__initcall(dump_irq_info_key_init);
 
 static int irq_save_pci(struct domain *d, hvm_domain_context_t *h)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:03:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:03:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyFV-0007hz-Tn; Fri, 25 Nov 2011 16:03:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RTyFU-0007ha-IF
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:03:36 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322236982!5024415!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3905 invoked from network); 25 Nov 2011 16:03:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 16:03:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19409239"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 11:03:02 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	11:03:02 -0500
Message-ID: <4ECFBC35.7080202@citrix.com>
Date: Fri, 25 Nov 2011 16:03:01 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ECFB05B.2060501@citrix.com>
	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>
In-Reply-To: <4ECFC3F902000078000635FF@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
	the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/11 15:36, Jan Beulich wrote:
>>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Before this patch, using "classic" crashdump= syntax (<size>@<start>)
>> causes an exact size and location to be reserved in the e820 map
>> before Xen and modules are relocated.  However, using "new" syntax
>> (<start>-[<end>]:<size>) encounteres a myriad of problems, most
>> notibly not considering the range when allocating its region.
> I'm sure I tested this (with some basic values), so the "myriad of
> problems" make me curious as to what they are.

The comment was a bit old from before I twigged what some of the code
was doing.  The two key problems were only considering the size, and a
bug in set_kexec_crash_area_size() which will only consider a range as
being valid if its end is greater than system_ram.  This bug prevents
specifying a range as "128M anywhere in 1G-2G" actually working on a box
with more than 2G of ram.

> What does "range" refer to here, and what is "its region"?

I will need to clean up my use of the term range and region, although it
doesn't help that there is ambiguity in the source code as well. 
Loosely, I have been using "range" to mean a possible range as given on
the command line, and "region" to be the actual area in memory where the
kdump kernel is going to be put.

> You also seem to overlook that even the old syntax allowed for only
> specifying a size.

No.  In the case of using the old syntax, both
kexec_crash_area.{start,size} are set, which caused the earlier call to
kexec_reserve_region() in __setup_xen() to attempt to reserve an exact
region at an exact address.  Using the newer syntax,
kexec_crash_area.size did not get set in the parsing function, and got
considered in set_kexec_crash_area_size(), which only sets the size. 
The subsiquent call to kexec_reverse_area() on the next line fails
silently because kexec_crash_area.start is 0.  Later, when considering
the modules, kexec_crash_area.start gets set to e-size, at which point
the call to kexec_reserve_area() actually does attempt to reserve a
region, based on the limits of an arbitrary e820 entry, not on the
limits provided on the command line.

>> This patch tries to unify both codepaths, and fix the broken logic
>> when using "newer" syntax.
>>
>> Changes addressed:
>>
>> 1) Remove use of kexec_crash_area from parse_crashkernel().
>>     Use ranges[0] in preference, as there is no support for multiple
>>     ranges using classic syntax.  This prevents some wierd logic in
>>     __setup_xen() depending on whether kexec_crash_area.size is set
>>     or not.
> What weird about that?

As described above.

>> 2) Change set_kexec_crash_area_size() to choose_kexec_range()
>>     The new method of choosing a range provides an entire rather than
> And entire what?

Oops.  An entire "kexec_range" entry giving a start, end and size value,
rather than the current case which takes either an exact size/start pair
from the 'classic' case, or a size anywhere in memory for the 'newer' case.

>>     just setting kexec_crash_area.size.  Also, fix the very broken
>>     logic which will only consider a range if its .end is greater
>>     than system_ram.
> Where's that happening? Are you perhaps mis-interpreting the
> purpose of these ranges?

I might possibly be misinterpreting these ranges as the only
documentation is the code, but I believe I have got it correct based on
the upstream Linux code.  What are your interpretations of the ranges?

>>  Additionally, prefer range with the largest
>>     size if we have a choice of valid ones, and prefer ranges with
>>     more flexibility in their limits.
>>
>> 3) Move kexec_reserve_area() from setup.c to kexec.c
>>     It makes more sense here, Also, change its functionality a little
>>     to always work from the kexec range provided by choose_kexec_range()
>>
>> 4) Remove the kexec reservation code when considering modules
>>     This code only had any effect for people using the "newer" syntax
>>     on the command line, as people using the "classic" syntax would
>>     reserve a memory region before considering modules.
> Are you sure? How do you prevent the kexec area from overlapping
> any of the modules (in particular the initrd, which can get passed in
> place to Dom0)?

Good point, which is why this is an RFC.  Note that the "classic"
syntax, which everyone refers to in documents on the subject, will never
consider any of the modules.  I am not really sure which is best, but I
would consider positioning the kdump kernel more important than the
location of initrd.  The user is likely to know more about why their
kdump kernel needs to be located where specified than Xen does.  Perhaps
after deciding where the kdump kernel should go, we should move any
overlapping modules?

> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:03:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:03:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyFV-0007hz-Tn; Fri, 25 Nov 2011 16:03:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RTyFU-0007ha-IF
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:03:36 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322236982!5024415!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3905 invoked from network); 25 Nov 2011 16:03:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 16:03:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19409239"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 11:03:02 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	11:03:02 -0500
Message-ID: <4ECFBC35.7080202@citrix.com>
Date: Fri, 25 Nov 2011 16:03:01 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ECFB05B.2060501@citrix.com>
	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>
In-Reply-To: <4ECFC3F902000078000635FF@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
	the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/11 15:36, Jan Beulich wrote:
>>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Before this patch, using "classic" crashdump= syntax (<size>@<start>)
>> causes an exact size and location to be reserved in the e820 map
>> before Xen and modules are relocated.  However, using "new" syntax
>> (<start>-[<end>]:<size>) encounteres a myriad of problems, most
>> notibly not considering the range when allocating its region.
> I'm sure I tested this (with some basic values), so the "myriad of
> problems" make me curious as to what they are.

The comment was a bit old from before I twigged what some of the code
was doing.  The two key problems were only considering the size, and a
bug in set_kexec_crash_area_size() which will only consider a range as
being valid if its end is greater than system_ram.  This bug prevents
specifying a range as "128M anywhere in 1G-2G" actually working on a box
with more than 2G of ram.

> What does "range" refer to here, and what is "its region"?

I will need to clean up my use of the term range and region, although it
doesn't help that there is ambiguity in the source code as well. 
Loosely, I have been using "range" to mean a possible range as given on
the command line, and "region" to be the actual area in memory where the
kdump kernel is going to be put.

> You also seem to overlook that even the old syntax allowed for only
> specifying a size.

No.  In the case of using the old syntax, both
kexec_crash_area.{start,size} are set, which caused the earlier call to
kexec_reserve_region() in __setup_xen() to attempt to reserve an exact
region at an exact address.  Using the newer syntax,
kexec_crash_area.size did not get set in the parsing function, and got
considered in set_kexec_crash_area_size(), which only sets the size. 
The subsiquent call to kexec_reverse_area() on the next line fails
silently because kexec_crash_area.start is 0.  Later, when considering
the modules, kexec_crash_area.start gets set to e-size, at which point
the call to kexec_reserve_area() actually does attempt to reserve a
region, based on the limits of an arbitrary e820 entry, not on the
limits provided on the command line.

>> This patch tries to unify both codepaths, and fix the broken logic
>> when using "newer" syntax.
>>
>> Changes addressed:
>>
>> 1) Remove use of kexec_crash_area from parse_crashkernel().
>>     Use ranges[0] in preference, as there is no support for multiple
>>     ranges using classic syntax.  This prevents some wierd logic in
>>     __setup_xen() depending on whether kexec_crash_area.size is set
>>     or not.
> What weird about that?

As described above.

>> 2) Change set_kexec_crash_area_size() to choose_kexec_range()
>>     The new method of choosing a range provides an entire rather than
> And entire what?

Oops.  An entire "kexec_range" entry giving a start, end and size value,
rather than the current case which takes either an exact size/start pair
from the 'classic' case, or a size anywhere in memory for the 'newer' case.

>>     just setting kexec_crash_area.size.  Also, fix the very broken
>>     logic which will only consider a range if its .end is greater
>>     than system_ram.
> Where's that happening? Are you perhaps mis-interpreting the
> purpose of these ranges?

I might possibly be misinterpreting these ranges as the only
documentation is the code, but I believe I have got it correct based on
the upstream Linux code.  What are your interpretations of the ranges?

>>  Additionally, prefer range with the largest
>>     size if we have a choice of valid ones, and prefer ranges with
>>     more flexibility in their limits.
>>
>> 3) Move kexec_reserve_area() from setup.c to kexec.c
>>     It makes more sense here, Also, change its functionality a little
>>     to always work from the kexec range provided by choose_kexec_range()
>>
>> 4) Remove the kexec reservation code when considering modules
>>     This code only had any effect for people using the "newer" syntax
>>     on the command line, as people using the "classic" syntax would
>>     reserve a memory region before considering modules.
> Are you sure? How do you prevent the kexec area from overlapping
> any of the modules (in particular the initrd, which can get passed in
> place to Dom0)?

Good point, which is why this is an RFC.  Note that the "classic"
syntax, which everyone refers to in documents on the subject, will never
consider any of the modules.  I am not really sure which is best, but I
would consider positioning the kdump kernel more important than the
location of initrd.  The user is likely to know more about why their
kdump kernel needs to be located where specified than Xen does.  Perhaps
after deciding where the kdump kernel should go, we should move any
overlapping modules?

> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:10:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:10:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyLT-0007zO-Oh; Fri, 25 Nov 2011 16:09:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RTyLR-0007zG-HC
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:09:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322237351!3045290!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6875 invoked from network); 25 Nov 2011 16:09:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 16:09:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19409329"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 11:09:10 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	11:09:10 -0500
Message-ID: <4ECFBDA5.9050700@citrix.com>
Date: Fri, 25 Nov 2011 16:09:09 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ECFB05B.2060501@citrix.com>	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>
	<4ECFBC35.7080202@citrix.com>
In-Reply-To: <4ECFBC35.7080202@citrix.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
 the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 25/11/11 16:03, Andrew Cooper wrote:
> On 25/11/11 15:36, Jan Beulich wrote:
>>>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> Before this patch, using "classic" crashdump= syntax (<size>@<start>)
>>> causes an exact size and location to be reserved in the e820 map
>>> before Xen and modules are relocated.  However, using "new" syntax
>>> (<start>-[<end>]:<size>) encounteres a myriad of problems, most
>>> notibly not considering the range when allocating its region.
>> I'm sure I tested this (with some basic values), so the "myriad of
>> problems" make me curious as to what they are.
> The comment was a bit old from before I twigged what some of the code
> was doing.  The two key problems were only considering the size, and a
> bug in set_kexec_crash_area_size() which will only consider a range as
> being valid if its end is greater than system_ram.  This bug prevents
> specifying a range as "128M anywhere in 1G-2G" actually working on a box
> with more than 2G of ram.
>
>> What does "range" refer to here, and what is "its region"?
> I will need to clean up my use of the term range and region, although it
> doesn't help that there is ambiguity in the source code as well. 
> Loosely, I have been using "range" to mean a possible range as given on
> the command line, and "region" to be the actual area in memory where the
> kdump kernel is going to be put.
>
>> You also seem to overlook that even the old syntax allowed for only
>> specifying a size.
> No.  In the case of using the old syntax, both
> kexec_crash_area.{start,size} are set, which caused the earlier call to
> kexec_reserve_region() in __setup_xen() to attempt to reserve an exact
> region at an exact address.  Using the newer syntax,
> kexec_crash_area.size did not get set in the parsing function, and got
> considered in set_kexec_crash_area_size(), which only sets the size. 
> The subsiquent call to kexec_reverse_area() on the next line fails
> silently because kexec_crash_area.start is 0.  Later, when considering
> the modules, kexec_crash_area.start gets set to e-size, at which point
> the call to kexec_reserve_area() actually does attempt to reserve a
> region, based on the limits of an arbitrary e820 entry, not on the
> limits provided on the command line.
>
>>> This patch tries to unify both codepaths, and fix the broken logic
>>> when using "newer" syntax.
>>>
>>> Changes addressed:
>>>
>>> 1) Remove use of kexec_crash_area from parse_crashkernel().
>>>     Use ranges[0] in preference, as there is no support for multiple
>>>     ranges using classic syntax.  This prevents some wierd logic in
>>>     __setup_xen() depending on whether kexec_crash_area.size is set
>>>     or not.
>> What weird about that?
> As described above.
>
>>> 2) Change set_kexec_crash_area_size() to choose_kexec_range()
>>>     The new method of choosing a range provides an entire rather than
>> And entire what?
> Oops.  An entire "kexec_range" entry giving a start, end and size value,
> rather than the current case which takes either an exact size/start pair
> from the 'classic' case, or a size anywhere in memory for the 'newer' case.
>
>>>     just setting kexec_crash_area.size.  Also, fix the very broken
>>>     logic which will only consider a range if its .end is greater
>>>     than system_ram.
>> Where's that happening? Are you perhaps mis-interpreting the
>> purpose of these ranges?
> I might possibly be misinterpreting these ranges as the only
> documentation is the code, but I believe I have got it correct based on
> the upstream Linux code.  What are your interpretations of the ranges?
>
>>>  Additionally, prefer range with the largest
>>>     size if we have a choice of valid ones, and prefer ranges with
>>>     more flexibility in their limits.
>>>
>>> 3) Move kexec_reserve_area() from setup.c to kexec.c
>>>     It makes more sense here, Also, change its functionality a little
>>>     to always work from the kexec range provided by choose_kexec_range()
>>>
>>> 4) Remove the kexec reservation code when considering modules
>>>     This code only had any effect for people using the "newer" syntax
>>>     on the command line, as people using the "classic" syntax would
>>>     reserve a memory region before considering modules.
>> Are you sure? How do you prevent the kexec area from overlapping
>> any of the modules (in particular the initrd, which can get passed in
>> place to Dom0)?
> Good point, which is why this is an RFC.  Note that the "classic"
> syntax, which everyone refers to in documents on the subject, will never
> consider any of the modules.  I am not really sure which is best, but I
> would consider positioning the kdump kernel more important than the
> location of initrd.  The user is likely to know more about why their
> kdump kernel needs to be located where specified than Xen does.  Perhaps
> after deciding where the kdump kernel should go, we should move any
> overlapping modules?

On second thoughts, how about this?

If a user provides an exact position and size for the kdump kernel,
place the kdump kernel there and move any overlapping modules.

If the user provides a range, attempt to fit the kdump kernel around
other modules, and in the case where we cant, move the offending
module(s) elsewhere.

>> Jan
>>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:10:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:10:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyLT-0007zO-Oh; Fri, 25 Nov 2011 16:09:47 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RTyLR-0007zG-HC
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:09:45 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322237351!3045290!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6875 invoked from network); 25 Nov 2011 16:09:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 16:09:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19409329"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 11:09:10 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	11:09:10 -0500
Message-ID: <4ECFBDA5.9050700@citrix.com>
Date: Fri, 25 Nov 2011 16:09:09 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ECFB05B.2060501@citrix.com>	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>
	<4ECFBC35.7080202@citrix.com>
In-Reply-To: <4ECFBC35.7080202@citrix.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
 the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 25/11/11 16:03, Andrew Cooper wrote:
> On 25/11/11 15:36, Jan Beulich wrote:
>>>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> Before this patch, using "classic" crashdump= syntax (<size>@<start>)
>>> causes an exact size and location to be reserved in the e820 map
>>> before Xen and modules are relocated.  However, using "new" syntax
>>> (<start>-[<end>]:<size>) encounteres a myriad of problems, most
>>> notibly not considering the range when allocating its region.
>> I'm sure I tested this (with some basic values), so the "myriad of
>> problems" make me curious as to what they are.
> The comment was a bit old from before I twigged what some of the code
> was doing.  The two key problems were only considering the size, and a
> bug in set_kexec_crash_area_size() which will only consider a range as
> being valid if its end is greater than system_ram.  This bug prevents
> specifying a range as "128M anywhere in 1G-2G" actually working on a box
> with more than 2G of ram.
>
>> What does "range" refer to here, and what is "its region"?
> I will need to clean up my use of the term range and region, although it
> doesn't help that there is ambiguity in the source code as well. 
> Loosely, I have been using "range" to mean a possible range as given on
> the command line, and "region" to be the actual area in memory where the
> kdump kernel is going to be put.
>
>> You also seem to overlook that even the old syntax allowed for only
>> specifying a size.
> No.  In the case of using the old syntax, both
> kexec_crash_area.{start,size} are set, which caused the earlier call to
> kexec_reserve_region() in __setup_xen() to attempt to reserve an exact
> region at an exact address.  Using the newer syntax,
> kexec_crash_area.size did not get set in the parsing function, and got
> considered in set_kexec_crash_area_size(), which only sets the size. 
> The subsiquent call to kexec_reverse_area() on the next line fails
> silently because kexec_crash_area.start is 0.  Later, when considering
> the modules, kexec_crash_area.start gets set to e-size, at which point
> the call to kexec_reserve_area() actually does attempt to reserve a
> region, based on the limits of an arbitrary e820 entry, not on the
> limits provided on the command line.
>
>>> This patch tries to unify both codepaths, and fix the broken logic
>>> when using "newer" syntax.
>>>
>>> Changes addressed:
>>>
>>> 1) Remove use of kexec_crash_area from parse_crashkernel().
>>>     Use ranges[0] in preference, as there is no support for multiple
>>>     ranges using classic syntax.  This prevents some wierd logic in
>>>     __setup_xen() depending on whether kexec_crash_area.size is set
>>>     or not.
>> What weird about that?
> As described above.
>
>>> 2) Change set_kexec_crash_area_size() to choose_kexec_range()
>>>     The new method of choosing a range provides an entire rather than
>> And entire what?
> Oops.  An entire "kexec_range" entry giving a start, end and size value,
> rather than the current case which takes either an exact size/start pair
> from the 'classic' case, or a size anywhere in memory for the 'newer' case.
>
>>>     just setting kexec_crash_area.size.  Also, fix the very broken
>>>     logic which will only consider a range if its .end is greater
>>>     than system_ram.
>> Where's that happening? Are you perhaps mis-interpreting the
>> purpose of these ranges?
> I might possibly be misinterpreting these ranges as the only
> documentation is the code, but I believe I have got it correct based on
> the upstream Linux code.  What are your interpretations of the ranges?
>
>>>  Additionally, prefer range with the largest
>>>     size if we have a choice of valid ones, and prefer ranges with
>>>     more flexibility in their limits.
>>>
>>> 3) Move kexec_reserve_area() from setup.c to kexec.c
>>>     It makes more sense here, Also, change its functionality a little
>>>     to always work from the kexec range provided by choose_kexec_range()
>>>
>>> 4) Remove the kexec reservation code when considering modules
>>>     This code only had any effect for people using the "newer" syntax
>>>     on the command line, as people using the "classic" syntax would
>>>     reserve a memory region before considering modules.
>> Are you sure? How do you prevent the kexec area from overlapping
>> any of the modules (in particular the initrd, which can get passed in
>> place to Dom0)?
> Good point, which is why this is an RFC.  Note that the "classic"
> syntax, which everyone refers to in documents on the subject, will never
> consider any of the modules.  I am not really sure which is best, but I
> would consider positioning the kdump kernel more important than the
> location of initrd.  The user is likely to know more about why their
> kdump kernel needs to be located where specified than Xen does.  Perhaps
> after deciding where the kdump kernel should go, we should move any
> overlapping modules?

On second thoughts, how about this?

If a user provides an exact position and size for the kdump kernel,
place the kdump kernel there and move any overlapping modules.

If the user provides a range, attempt to fit the kdump kernel around
other modules, and in the case where we cant, move the offending
module(s) elsewhere.

>> Jan
>>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:22:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyXF-0008Ct-AH; Fri, 25 Nov 2011 16:21:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1RTyXD-0008Co-PS
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:21:56 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322238082!3068705!1
X-Originating-IP: [82.198.197.8]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12349 invoked from network); 25 Nov 2011 16:21:22 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-16.tower-174.messagelabs.com with SMTP;
	25 Nov 2011 16:21:22 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id BEA6EE5B101
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 17:21:18 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id AE4FBE5B103
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 17:21:18 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 43QCX7rJfW9B for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 17:21:18 +0100 (CET)
Received: from stave.knut.univention.de (stave.knut.univention.de
	[192.168.0.191])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 29446E5B101
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 17:21:18 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 17:21:08 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
MIME-Version: 1.0
Message-Id: <201111251721.12753.hahn@univention.de>
Subject: [Xen-devel] [BUG] insufficient quoting between "tap-ctl list" and
	xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6074550851469247843=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6074550851469247843==
Content-Type: multipart/signed;
  boundary="nextPart3624085.j0xhk99oQK";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart3624085.j0xhk99oQK
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

I have a problem shutting down a domU with xen-4.1.2, which doesn't termina=
te=20
the corresponding blktap2 process, since one (other) VM uses a image file,=
=20
which contains spaces in its file name.
/var/log/xen/xend-debug.log has the following information:

Unhandled exception in thread started by
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.p=
y",=20
line 199, in finishDeviceCleanup
    TapdiskController.destroy(path)
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.p=
y",=20
line 289, in destroy
    tapdisk =3D TapdiskController.fromDevice(device)
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.p=
y",=20
line 278, in fromDevice
    TapdiskController.list())
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.p=
y",=20
line 256, in list
    key, value =3D pair.split('=3D')
ValueError: need more than 1 value to unpack

BlktapController calls "tap-ctl list", which outputs one line for each=20
process. Each line contains key=3Dvalue pairs without any quoting.

# tap-ctl list | grep 'args=3D.*:.* '
pid=3D10145 minor=3D18 state=3D0 args=3Daio:/var/lib/libvirt/images/Xen Win=
dows=20
drivers (gplpv 308).iso

(passing the output of tap-ctl through a pipe is important, since it switch=
es=20
to a different list-format when STDOUT is a tty.)

BlktapController splits the output into lines using \n, then each line at e=
ach=20
space, and finally each of these 'words' at the '=3D', which fails for the=
=20
filename.


tap-ctl should probably be changed to use some quoting when printing the=20
filename.

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart3624085.j0xhk99oQK
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAk7PwHQACgkQYPlgoZpUDjn7LACeORTtRf7B3BO/sEh9rgXnVdXi
+cEAoKuJnvT9Kl7/wFT0uSCbqfJ+eWWC
=us3f
-----END PGP SIGNATURE-----

--nextPart3624085.j0xhk99oQK--


--===============6074550851469247843==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6074550851469247843==--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:22:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyXF-0008Ct-AH; Fri, 25 Nov 2011 16:21:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1RTyXD-0008Co-PS
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:21:56 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322238082!3068705!1
X-Originating-IP: [82.198.197.8]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12349 invoked from network); 25 Nov 2011 16:21:22 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-16.tower-174.messagelabs.com with SMTP;
	25 Nov 2011 16:21:22 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id BEA6EE5B101
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 17:21:18 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id AE4FBE5B103
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 17:21:18 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 43QCX7rJfW9B for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 17:21:18 +0100 (CET)
Received: from stave.knut.univention.de (stave.knut.univention.de
	[192.168.0.191])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 29446E5B101
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 17:21:18 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 25 Nov 2011 17:21:08 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
MIME-Version: 1.0
Message-Id: <201111251721.12753.hahn@univention.de>
Subject: [Xen-devel] [BUG] insufficient quoting between "tap-ctl list" and
	xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6074550851469247843=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6074550851469247843==
Content-Type: multipart/signed;
  boundary="nextPart3624085.j0xhk99oQK";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart3624085.j0xhk99oQK
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

I have a problem shutting down a domU with xen-4.1.2, which doesn't termina=
te=20
the corresponding blktap2 process, since one (other) VM uses a image file,=
=20
which contains spaces in its file name.
/var/log/xen/xend-debug.log has the following information:

Unhandled exception in thread started by
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.p=
y",=20
line 199, in finishDeviceCleanup
    TapdiskController.destroy(path)
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.p=
y",=20
line 289, in destroy
    tapdisk =3D TapdiskController.fromDevice(device)
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.p=
y",=20
line 278, in fromDevice
    TapdiskController.list())
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.p=
y",=20
line 256, in list
    key, value =3D pair.split('=3D')
ValueError: need more than 1 value to unpack

BlktapController calls "tap-ctl list", which outputs one line for each=20
process. Each line contains key=3Dvalue pairs without any quoting.

# tap-ctl list | grep 'args=3D.*:.* '
pid=3D10145 minor=3D18 state=3D0 args=3Daio:/var/lib/libvirt/images/Xen Win=
dows=20
drivers (gplpv 308).iso

(passing the output of tap-ctl through a pipe is important, since it switch=
es=20
to a different list-format when STDOUT is a tty.)

BlktapController splits the output into lines using \n, then each line at e=
ach=20
space, and finally each of these 'words' at the '=3D', which fails for the=
=20
filename.


tap-ctl should probably be changed to use some quoting when printing the=20
filename.

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart3624085.j0xhk99oQK
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAk7PwHQACgkQYPlgoZpUDjn7LACeORTtRf7B3BO/sEh9rgXnVdXi
+cEAoKuJnvT9Kl7/wFT0uSCbqfJ+eWWC
=us3f
-----END PGP SIGNATURE-----

--nextPart3624085.j0xhk99oQK--


--===============6074550851469247843==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6074550851469247843==--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:40:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyoV-00005f-9b; Fri, 25 Nov 2011 16:39:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTyoS-00005X-Rf
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:39:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322239152!5772187!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23625 invoked from network); 25 Nov 2011 16:39:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 16:39:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9135164"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 16:39:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 16:39:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 25 Nov 2011 16:39:11 +0000
In-Reply-To: <4ECFB9CA020000780006354E@nat28.tlf.novell.com>
References: <4ECFB9CA020000780006354E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322239151.1005.279.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] booting HVM guest via passed through NIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 14:52 +0000, Jan Beulich wrote:
> is this supposed to work? If so, is it also known to work (in general or for
> specific NICs)?

Does qemu-xen/ROMBIOS collude to run any option roms for the device? I
suspect not in which case you might have to supply a suitable Etherboot
(or whatever it's called this week) for the NIC in question to be built
into hvmloader?

FWIW upstream qemu+SeaBIOS do allow for option ROMS, although I've only
tested that with the emulated NICs.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:40:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyoV-00005f-9b; Fri, 25 Nov 2011 16:39:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTyoS-00005X-Rf
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:39:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322239152!5772187!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23625 invoked from network); 25 Nov 2011 16:39:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 16:39:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9135164"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 16:39:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 16:39:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 25 Nov 2011 16:39:11 +0000
In-Reply-To: <4ECFB9CA020000780006354E@nat28.tlf.novell.com>
References: <4ECFB9CA020000780006354E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322239151.1005.279.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] booting HVM guest via passed through NIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 14:52 +0000, Jan Beulich wrote:
> is this supposed to work? If so, is it also known to work (in general or for
> specific NICs)?

Does qemu-xen/ROMBIOS collude to run any option roms for the device? I
suspect not in which case you might have to supply a suitable Etherboot
(or whatever it's called this week) for the NIC in question to be built
into hvmloader?

FWIW upstream qemu+SeaBIOS do allow for option ROMS, although I've only
tested that with the emulated NICs.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:40:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyoh-00006G-NP; Fri, 25 Nov 2011 16:39:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTyog-00005t-5P
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:39:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322239165!5547871!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18114 invoked from network); 25 Nov 2011 16:39:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 16:39:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9135168"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 16:39:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 16:39:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Fri, 25 Nov 2011 16:39:25 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4CE6@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
	<1322233543.1005.261.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4CE6@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322239165.1005.280.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document describing
 the xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 15:16 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 25 November 2011 15:06
> > To: xen-devel@lists.xensource.com
> > Cc: Ian Jackson; Paul Durrant
> > Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document
> > describing the xl cfg file syntax
> > 
> > Paul,
> > 
> > On Fri, 2011-11-25 at 14:49 +0000, Ian Campbell wrote:
> > >
> > > +=item B<viridian=BOOLEAN>
> > > +
> > > +Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
> > > +compatible enlightenments to the guest.  These can improve
> > > performance
> > > +of Microsoft Windows guests (XXX which versions of Windows
> > benefit?)
> > 
> > Is there anything else we can say here? What are the first versions
> > of Windows which benefit from this?
> > 
> 
> Ian,
> 
>   I think that's probably good enough. AFAIK viridian enlightenments
> came in with the 6.0 kernel in Vista/2K8 but having the flag on should
> do no harm for older kernels.

How about this incremental patch?

diff -r b4c07fbe3557 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Fri Nov 25 15:11:30 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Fri Nov 25 15:23:14 2011 +0000
@@ -555,7 +555,13 @@ Windows L<http://wiki.xen.org/wiki/XenWi
 
 Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
 compatible enlightenments to the guest.  These can improve performance
-of Microsoft Windows guests (XXX which versions of Windows benefit?)
+of Microsoft Windows guests from Windows Vista and Windows 2008
+onwards and setting this option for such guests is strongly
+recommended. This option should be harmless for other versions of
+Windows (although it won't give any benefit) and the majority of other
+non-Windows OSes. However it is known to be incompatible with some
+other Operating Systems and in some circumstance can prevent Xen's own
+paravirtualisation interfaces for HVM guests from being used.
 
 =back
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:40:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:40:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyoh-00006G-NP; Fri, 25 Nov 2011 16:39:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RTyog-00005t-5P
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:39:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322239165!5547871!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18114 invoked from network); 25 Nov 2011 16:39:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 16:39:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9135168"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 16:39:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 25 Nov 2011 16:39:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Fri, 25 Nov 2011 16:39:25 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4CE6@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
	<1322233543.1005.261.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4CE6@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322239165.1005.280.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document describing
 the xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 15:16 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 25 November 2011 15:06
> > To: xen-devel@lists.xensource.com
> > Cc: Ian Jackson; Paul Durrant
> > Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document
> > describing the xl cfg file syntax
> > 
> > Paul,
> > 
> > On Fri, 2011-11-25 at 14:49 +0000, Ian Campbell wrote:
> > >
> > > +=item B<viridian=BOOLEAN>
> > > +
> > > +Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
> > > +compatible enlightenments to the guest.  These can improve
> > > performance
> > > +of Microsoft Windows guests (XXX which versions of Windows
> > benefit?)
> > 
> > Is there anything else we can say here? What are the first versions
> > of Windows which benefit from this?
> > 
> 
> Ian,
> 
>   I think that's probably good enough. AFAIK viridian enlightenments
> came in with the 6.0 kernel in Vista/2K8 but having the flag on should
> do no harm for older kernels.

How about this incremental patch?

diff -r b4c07fbe3557 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Fri Nov 25 15:11:30 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Fri Nov 25 15:23:14 2011 +0000
@@ -555,7 +555,13 @@ Windows L<http://wiki.xen.org/wiki/XenWi
 
 Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
 compatible enlightenments to the guest.  These can improve performance
-of Microsoft Windows guests (XXX which versions of Windows benefit?)
+of Microsoft Windows guests from Windows Vista and Windows 2008
+onwards and setting this option for such guests is strongly
+recommended. This option should be harmless for other versions of
+Windows (although it won't give any benefit) and the majority of other
+non-Windows OSes. However it is known to be incompatible with some
+other Operating Systems and in some circumstance can prevent Xen's own
+paravirtualisation interfaces for HVM guests from being used.
 
 =back
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:50:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:50:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyya-0000mY-Ue; Fri, 25 Nov 2011 16:50:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTyyZ-0000mT-Nx
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:50:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322239778!5549261!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12027 invoked from network); 25 Nov 2011 16:49:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 16:49:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 16:49:38 +0000
Message-Id: <4ECFD531020000780006366D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 16:49:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4ECFB05B.2060501@citrix.com>
	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>
	<4ECFBC35.7080202@citrix.com>
In-Reply-To: <4ECFBC35.7080202@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
 the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.11.11 at 17:03, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 25/11/11 15:36, Jan Beulich wrote:
>>>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Where's that happening? Are you perhaps mis-interpreting the
>> purpose of these ranges?
> 
> I might possibly be misinterpreting these ranges as the only
> documentation is the code, but I believe I have got it correct based on
> the upstream Linux code.  What are your interpretations of the ranges?

The ranges are to say "if the system has between <start> and <end>
amount of memory, then allocate a <size> block (possibly located at
<offset>).

>>> 4) Remove the kexec reservation code when considering modules
>>>     This code only had any effect for people using the "newer" syntax
>>>     on the command line, as people using the "classic" syntax would
>>>     reserve a memory region before considering modules.
>> Are you sure? How do you prevent the kexec area from overlapping
>> any of the modules (in particular the initrd, which can get passed in
>> place to Dom0)?
> 
> Good point, which is why this is an RFC.  Note that the "classic"
> syntax, which everyone refers to in documents on the subject, will never
> consider any of the modules.

It won't in either case when addresses are specified. It will in
both cases when only sizes are provided.

> I am not really sure which is best, but I
> would consider positioning the kdump kernel more important than the
> location of initrd.  The user is likely to know more about why their
> kdump kernel needs to be located where specified than Xen does.  Perhaps
> after deciding where the kdump kernel should go, we should move any
> overlapping modules?

And that's already happening (or is at least supposed to be).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:50:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:50:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTyya-0000mY-Ue; Fri, 25 Nov 2011 16:50:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RTyyZ-0000mT-Nx
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:50:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322239778!5549261!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12027 invoked from network); 25 Nov 2011 16:49:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 16:49:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 25 Nov 2011 16:49:38 +0000
Message-Id: <4ECFD531020000780006366D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 25 Nov 2011 16:49:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4ECFB05B.2060501@citrix.com>
	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>
	<4ECFBC35.7080202@citrix.com>
In-Reply-To: <4ECFBC35.7080202@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
 the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.11.11 at 17:03, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 25/11/11 15:36, Jan Beulich wrote:
>>>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> Where's that happening? Are you perhaps mis-interpreting the
>> purpose of these ranges?
> 
> I might possibly be misinterpreting these ranges as the only
> documentation is the code, but I believe I have got it correct based on
> the upstream Linux code.  What are your interpretations of the ranges?

The ranges are to say "if the system has between <start> and <end>
amount of memory, then allocate a <size> block (possibly located at
<offset>).

>>> 4) Remove the kexec reservation code when considering modules
>>>     This code only had any effect for people using the "newer" syntax
>>>     on the command line, as people using the "classic" syntax would
>>>     reserve a memory region before considering modules.
>> Are you sure? How do you prevent the kexec area from overlapping
>> any of the modules (in particular the initrd, which can get passed in
>> place to Dom0)?
> 
> Good point, which is why this is an RFC.  Note that the "classic"
> syntax, which everyone refers to in documents on the subject, will never
> consider any of the modules.

It won't in either case when addresses are specified. It will in
both cases when only sizes are provided.

> I am not really sure which is best, but I
> would consider positioning the kdump kernel more important than the
> location of initrd.  The user is likely to know more about why their
> kdump kernel needs to be located where specified than Xen does.  Perhaps
> after deciding where the kdump kernel should go, we should move any
> overlapping modules?

And that's already happening (or is at least supposed to be).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:53:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTz1r-0000tL-JC; Fri, 25 Nov 2011 16:53:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RTz1p-0000t6-UL
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:53:34 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322239981!3058510!1
X-Originating-IP: [63.239.65.40]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28510 invoked from network); 25 Nov 2011 16:53:01 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-174.messagelabs.com with SMTP;
	25 Nov 2011 16:53:01 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAPGqlvF025467; Fri, 25 Nov 2011 16:52:47 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAPGqlx4027433; 
	Fri, 25 Nov 2011 11:52:47 -0500
Message-ID: <4ECFC7F3.3080201@tycho.nsa.gov>
Date: Fri, 25 Nov 2011 11:53:07 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Anil Madhavapeddy <anil@recoil.org>
References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov>
	<CACaajQsMnXb9u1pTtB9jT5b6n2p6gFq_A8aQajAO4kmcpSwKdw@mail.gmail.com>
	<CACaajQtCMpWuqH8PGhwK-WGC=bXRiE1an+2sWcm2JaozK7BK=w@mail.gmail.com>
	<4E85D4CB.80009@tycho.nsa.gov>
	<20111124200235.GA21510@dark.recoil.org>
In-Reply-To: <20111124200235.GA21510@dark.recoil.org>
X-Enigmail-Version: 1.3.2
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	konrad.wilk@oracle.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@eu.citrix.com, Vasiliy Tolstov <v.tolstov@ghs.l.google.com>
Subject: Re: [Xen-devel] [PATCH v6 0/3] libxenvchan: interdomain
 communications library
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/24/2011 03:02 PM, Anil Madhavapeddy wrote:
> On Fri, Sep 30, 2011 at 10:40:11AM -0400, Daniel De Graaf wrote:
>>>>
>>>> 2011/9/23 Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>>
>>>>> Changes since v5:
>>>>>  - Unify gntdev osdep interface
>>>>>  - Eliminate notify_result and revert mapping if notify ioctl fails
>>>>>  - Rename functions and structures to libxenvchan
>>>>>  - Use application-specified xenstore path for ring/event data
>>>>>  - Enforce maximum ring size of 2^20 bytes on client
>>>>>  - Change to LGPL 2.1
>>>>>
>>>>> [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify
>>>>> [PATCH 2/3] libxc: add xc_gntshr_* functions
>>>>> [PATCH 3/3] libvchan: interdomain communications library
>>>>>
> <snip>
>> This library depends on gntdev for the client and gntalloc for the server;
>> these were merged in 2.6.39. The client can be used with 2.6.32.x kernels
>> however it is not possible to detect when a peer crashes or exits without
>> calling libxenvchan_close() on that kernel.
> 
> I'm trying this with your most recent dom0 patches all included, and
> xen-unstable. In order to get decent performance, I tried the vchan-node
> examples with a cranked up buffer size, which fails immediately on 64-bit
> VMs.  This below patch fixes the xc_gntshr_share_pages call (which sets
> notify_offset to -1 and without this bounds check will send a big offset
> to the unmap notify ioctl).
> 
> With this, communication does work with the big buffers, but it never
> frees them, and so I can get an ENOSPACE error by calling vchan-node a few
> times. What's the intended cleanup path for the grants in normal use of
> the vchan library? Something's holding onto them, but I don't have a
> serial console on my current laptop in order to drop into Xen's serial and
> find out more.
> 

As long as things aren't crashing, you should be able to use "xl debug-key g"
and "xl dmesg" together to view the grant table debug output.

The ENOSPC bug is due to a missing gnttab_free_grant_reference call, the patch
to fix should be sent as a reply. The libxc patch fixing notify_offset is
incomplete; a more complete version will also be sent as a reply.

It is possible to observe this ENOSPC error even with proper cleanup if the
client refuses to release the grants it has mapped. Xen does not allow domains
to force unmapping of pages they have granted, so the best we can do is try to
remove any hanging grants on later gntalloc calls.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:53:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTz1r-0000tL-JC; Fri, 25 Nov 2011 16:53:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RTz1p-0000t6-UL
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:53:34 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322239981!3058510!1
X-Originating-IP: [63.239.65.40]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28510 invoked from network); 25 Nov 2011 16:53:01 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-174.messagelabs.com with SMTP;
	25 Nov 2011 16:53:01 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAPGqlvF025467; Fri, 25 Nov 2011 16:52:47 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAPGqlx4027433; 
	Fri, 25 Nov 2011 11:52:47 -0500
Message-ID: <4ECFC7F3.3080201@tycho.nsa.gov>
Date: Fri, 25 Nov 2011 11:53:07 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Anil Madhavapeddy <anil@recoil.org>
References: <1313764724-12683-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1316729665-15004-1-git-send-email-dgdegra@tycho.nsa.gov>
	<CACaajQsMnXb9u1pTtB9jT5b6n2p6gFq_A8aQajAO4kmcpSwKdw@mail.gmail.com>
	<CACaajQtCMpWuqH8PGhwK-WGC=bXRiE1an+2sWcm2JaozK7BK=w@mail.gmail.com>
	<4E85D4CB.80009@tycho.nsa.gov>
	<20111124200235.GA21510@dark.recoil.org>
In-Reply-To: <20111124200235.GA21510@dark.recoil.org>
X-Enigmail-Version: 1.3.2
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	konrad.wilk@oracle.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@eu.citrix.com, Vasiliy Tolstov <v.tolstov@ghs.l.google.com>
Subject: Re: [Xen-devel] [PATCH v6 0/3] libxenvchan: interdomain
 communications library
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/24/2011 03:02 PM, Anil Madhavapeddy wrote:
> On Fri, Sep 30, 2011 at 10:40:11AM -0400, Daniel De Graaf wrote:
>>>>
>>>> 2011/9/23 Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>>
>>>>> Changes since v5:
>>>>>  - Unify gntdev osdep interface
>>>>>  - Eliminate notify_result and revert mapping if notify ioctl fails
>>>>>  - Rename functions and structures to libxenvchan
>>>>>  - Use application-specified xenstore path for ring/event data
>>>>>  - Enforce maximum ring size of 2^20 bytes on client
>>>>>  - Change to LGPL 2.1
>>>>>
>>>>> [PATCH 1/3] libxc: add xc_gnttab_map_grant_ref_notify
>>>>> [PATCH 2/3] libxc: add xc_gntshr_* functions
>>>>> [PATCH 3/3] libvchan: interdomain communications library
>>>>>
> <snip>
>> This library depends on gntdev for the client and gntalloc for the server;
>> these were merged in 2.6.39. The client can be used with 2.6.32.x kernels
>> however it is not possible to detect when a peer crashes or exits without
>> calling libxenvchan_close() on that kernel.
> 
> I'm trying this with your most recent dom0 patches all included, and
> xen-unstable. In order to get decent performance, I tried the vchan-node
> examples with a cranked up buffer size, which fails immediately on 64-bit
> VMs.  This below patch fixes the xc_gntshr_share_pages call (which sets
> notify_offset to -1 and without this bounds check will send a big offset
> to the unmap notify ioctl).
> 
> With this, communication does work with the big buffers, but it never
> frees them, and so I can get an ENOSPACE error by calling vchan-node a few
> times. What's the intended cleanup path for the grants in normal use of
> the vchan library? Something's holding onto them, but I don't have a
> serial console on my current laptop in order to drop into Xen's serial and
> find out more.
> 

As long as things aren't crashing, you should be able to use "xl debug-key g"
and "xl dmesg" together to view the grant table debug output.

The ENOSPC bug is due to a missing gnttab_free_grant_reference call, the patch
to fix should be sent as a reply. The libxc patch fixing notify_offset is
incomplete; a more complete version will also be sent as a reply.

It is possible to observe this ENOSPC error even with proper cleanup if the
client refuses to release the grants it has mapped. Xen does not allow domains
to force unmapping of pages they have granted, so the best we can do is try to
remove any hanging grants on later gntalloc calls.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:55:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:55:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTz30-0000y8-2w; Fri, 25 Nov 2011 16:54:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RTz2z-0000xj-0o
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:54:45 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322240052!5030299!1
X-Originating-IP: [63.239.65.39]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 733 invoked from network); 25 Nov 2011 16:54:12 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-216.messagelabs.com with SMTP;
	25 Nov 2011 16:54:12 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAPGrxMK001419; Fri, 25 Nov 2011 16:53:59 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAPGrxMH027467; 
	Fri, 25 Nov 2011 11:53:59 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Ian Jackson <ian.jackson@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>
Date: Fri, 25 Nov 2011 11:54:18 -0500
Message-Id: <1322240058-29038-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <4ECFC7F3.3080201@tycho.nsa.gov>
References: <4ECFC7F3.3080201@tycho.nsa.gov>
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	konrad.wilk@oracle.com, Ian.Campbell@eu.citrix.com,
	Vasiliy Tolstov <v.tolstov@ghs.l.google.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] libxc: Fix checks on grant notify arguments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The notify offset and event channels are both unsigned variables, so
testing for >= 0 will not correctly detect the use of -1 to indicate
the field is unused. Remove the useless comparison and replace with
correct range checks or comparisons to -1.

Reported-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_linux_osdep.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 04059b8..2a4dd94 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -567,7 +567,7 @@ static void *linux_gnttab_grant_map(xc_gnttab *xch, xc_osdep_handle h,
         struct ioctl_gntdev_unmap_notify notify;
         notify.index = map->index;
         notify.action = 0;
-        if (notify_offset >= 0 && notify_offset < XC_PAGE_SIZE * count) {
+        if (notify_offset < XC_PAGE_SIZE * count) {
             notify.index += notify_offset;
             notify.action |= UNMAP_NOTIFY_CLEAR_BYTE;
         }
@@ -709,11 +709,11 @@ static void *linux_gntshr_share_pages(xc_gntshr *xch, xc_osdep_handle h,
 
     notify.index = gref_info->index;
     notify.action = 0;
-    if (notify_offset >= 0) {
+    if (notify_offset < XC_PAGE_SIZE * count) {
         notify.index += notify_offset;
         notify.action |= UNMAP_NOTIFY_CLEAR_BYTE;
     }
-    if (notify_port >= 0) {
+    if (notify_port != -1) {
         notify.event_channel_port = notify_port;
         notify.action |= UNMAP_NOTIFY_SEND_EVENT;
     }
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:55:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:55:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTz30-0000y8-2w; Fri, 25 Nov 2011 16:54:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RTz2z-0000xj-0o
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:54:45 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322240052!5030299!1
X-Originating-IP: [63.239.65.39]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 733 invoked from network); 25 Nov 2011 16:54:12 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-216.messagelabs.com with SMTP;
	25 Nov 2011 16:54:12 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAPGrxMK001419; Fri, 25 Nov 2011 16:53:59 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAPGrxMH027467; 
	Fri, 25 Nov 2011 11:53:59 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Ian Jackson <ian.jackson@eu.citrix.com>,
	Anil Madhavapeddy <anil@recoil.org>
Date: Fri, 25 Nov 2011 11:54:18 -0500
Message-Id: <1322240058-29038-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <4ECFC7F3.3080201@tycho.nsa.gov>
References: <4ECFC7F3.3080201@tycho.nsa.gov>
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	konrad.wilk@oracle.com, Ian.Campbell@eu.citrix.com,
	Vasiliy Tolstov <v.tolstov@ghs.l.google.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] libxc: Fix checks on grant notify arguments
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The notify offset and event channels are both unsigned variables, so
testing for >= 0 will not correctly detect the use of -1 to indicate
the field is unused. Remove the useless comparison and replace with
correct range checks or comparisons to -1.

Reported-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_linux_osdep.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 04059b8..2a4dd94 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -567,7 +567,7 @@ static void *linux_gnttab_grant_map(xc_gnttab *xch, xc_osdep_handle h,
         struct ioctl_gntdev_unmap_notify notify;
         notify.index = map->index;
         notify.action = 0;
-        if (notify_offset >= 0 && notify_offset < XC_PAGE_SIZE * count) {
+        if (notify_offset < XC_PAGE_SIZE * count) {
             notify.index += notify_offset;
             notify.action |= UNMAP_NOTIFY_CLEAR_BYTE;
         }
@@ -709,11 +709,11 @@ static void *linux_gntshr_share_pages(xc_gntshr *xch, xc_osdep_handle h,
 
     notify.index = gref_info->index;
     notify.action = 0;
-    if (notify_offset >= 0) {
+    if (notify_offset < XC_PAGE_SIZE * count) {
         notify.index += notify_offset;
         notify.action |= UNMAP_NOTIFY_CLEAR_BYTE;
     }
-    if (notify_port >= 0) {
+    if (notify_port != -1) {
         notify.event_channel_port = notify_port;
         notify.action |= UNMAP_NOTIFY_SEND_EVENT;
     }
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:57:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTz5O-00019t-M7; Fri, 25 Nov 2011 16:57:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RTz5M-00019i-OO
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:57:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322240179!42435199!1
X-Originating-IP: [63.239.65.40]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21396 invoked from network); 25 Nov 2011 16:56:20 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-27.messagelabs.com with SMTP;
	25 Nov 2011 16:56:20 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAPGuWvF026344; Fri, 25 Nov 2011 16:56:33 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAPGuWaM027603; 
	Fri, 25 Nov 2011 11:56:32 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Anil Madhavapeddy <anil@recoil.org>, konrad.wilk@oracle.com
Date: Fri, 25 Nov 2011 11:56:49 -0500
Message-Id: <1322240210-8503-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <4ECFC7F3.3080201@tycho.nsa.gov>
References: <4ECFC7F3.3080201@tycho.nsa.gov>
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>, Ian.Campbell@eu.citrix.com,
	Vasiliy Tolstov <v.tolstov@ghs.l.google.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 1/2] xen/events: prevent calling evtchn_get on
	invlaid channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The event channel number provided to evtchn_get can be provided by
userspace, so needs to be checked against the maximum number of event
channels prior to using it to index into evtchn_to_irq.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/events.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index a3bcd61..e5e5812 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1104,6 +1104,9 @@ int evtchn_get(unsigned int evtchn)
 	struct irq_info *info;
 	int err = -ENOENT;
 
+	if (evtchn >= NR_EVENT_CHANNELS)
+		return -EINVAL;
+
 	mutex_lock(&irq_mapping_update_lock);
 
 	irq = evtchn_to_irq[evtchn];
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:57:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:57:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTz5O-00019t-M7; Fri, 25 Nov 2011 16:57:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RTz5M-00019i-OO
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:57:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322240179!42435199!1
X-Originating-IP: [63.239.65.40]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21396 invoked from network); 25 Nov 2011 16:56:20 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-27.messagelabs.com with SMTP;
	25 Nov 2011 16:56:20 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAPGuWvF026344; Fri, 25 Nov 2011 16:56:33 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAPGuWaM027603; 
	Fri, 25 Nov 2011 11:56:32 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Anil Madhavapeddy <anil@recoil.org>, konrad.wilk@oracle.com
Date: Fri, 25 Nov 2011 11:56:49 -0500
Message-Id: <1322240210-8503-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <4ECFC7F3.3080201@tycho.nsa.gov>
References: <4ECFC7F3.3080201@tycho.nsa.gov>
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>, Ian.Campbell@eu.citrix.com,
	Vasiliy Tolstov <v.tolstov@ghs.l.google.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 1/2] xen/events: prevent calling evtchn_get on
	invlaid channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The event channel number provided to evtchn_get can be provided by
userspace, so needs to be checked against the maximum number of event
channels prior to using it to index into evtchn_to_irq.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/events.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index a3bcd61..e5e5812 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1104,6 +1104,9 @@ int evtchn_get(unsigned int evtchn)
 	struct irq_info *info;
 	int err = -ENOENT;
 
+	if (evtchn >= NR_EVENT_CHANNELS)
+		return -EINVAL;
+
 	mutex_lock(&irq_mapping_update_lock);
 
 	irq = evtchn_to_irq[evtchn];
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:57:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTz5T-0001AM-3N; Fri, 25 Nov 2011 16:57:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RTz5R-00019h-7s
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:57:17 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322240204!82993!1
X-Originating-IP: [63.239.65.39]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32202 invoked from network); 25 Nov 2011 16:56:44 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-182.messagelabs.com with SMTP;
	25 Nov 2011 16:56:44 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAPGuWMK002040; Fri, 25 Nov 2011 16:56:33 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAPGuWaN027603; 
	Fri, 25 Nov 2011 11:56:32 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Anil Madhavapeddy <anil@recoil.org>, konrad.wilk@oracle.com
Date: Fri, 25 Nov 2011 11:56:50 -0500
Message-Id: <1322240210-8503-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322240210-8503-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <4ECFC7F3.3080201@tycho.nsa.gov>
	<1322240210-8503-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>, Ian.Campbell@eu.citrix.com,
	Vasiliy Tolstov <v.tolstov@ghs.l.google.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 2/2] xen/gntalloc: release grant references on
	page free
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

gnttab_end_foreign_access_ref does not return the grant reference it is
passed to the free list; gnttab_free_grant_reference needs to be
explicitly called. While gnttab_end_foreign_access provides a wrapper
for this, it is unsuitable because it does not return errors.

Reported-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntalloc.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 60eee4e..7b936cc 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -191,6 +191,8 @@ static void __del_gref(struct gntalloc_gref *gref)
 
 		if (!gnttab_end_foreign_access_ref(gref->gref_id, 0))
 			return;
+
+		gnttab_free_grant_reference(gref->gref_id);
 	}
 
 	gref_size--;
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 16:57:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 16:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTz5T-0001AM-3N; Fri, 25 Nov 2011 16:57:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RTz5R-00019h-7s
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 16:57:17 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322240204!82993!1
X-Originating-IP: [63.239.65.39]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32202 invoked from network); 25 Nov 2011 16:56:44 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-182.messagelabs.com with SMTP;
	25 Nov 2011 16:56:44 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAPGuWMK002040; Fri, 25 Nov 2011 16:56:33 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAPGuWaN027603; 
	Fri, 25 Nov 2011 11:56:32 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Anil Madhavapeddy <anil@recoil.org>, konrad.wilk@oracle.com
Date: Fri, 25 Nov 2011 11:56:50 -0500
Message-Id: <1322240210-8503-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322240210-8503-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <4ECFC7F3.3080201@tycho.nsa.gov>
	<1322240210-8503-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>, Ian.Campbell@eu.citrix.com,
	Vasiliy Tolstov <v.tolstov@ghs.l.google.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 2/2] xen/gntalloc: release grant references on
	page free
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

gnttab_end_foreign_access_ref does not return the grant reference it is
passed to the free list; gnttab_free_grant_reference needs to be
explicitly called. While gnttab_end_foreign_access provides a wrapper
for this, it is unsuitable because it does not return errors.

Reported-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntalloc.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 60eee4e..7b936cc 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -191,6 +191,8 @@ static void __del_gref(struct gntalloc_gref *gref)
 
 		if (!gnttab_end_foreign_access_ref(gref->gref_id, 0))
 			return;
+
+		gnttab_free_grant_reference(gref->gref_id);
 	}
 
 	gref_size--;
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 17:04:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 17:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTzC2-0001dC-7B; Fri, 25 Nov 2011 17:04:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RTzC1-0001d6-8c
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 17:04:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322240611!3059752!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27793 invoked from network); 25 Nov 2011 17:03:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 17:03:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19410522"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:03:30 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	12:03:30 -0500
Message-ID: <4ECFCA61.1090401@citrix.com>
Date: Fri, 25 Nov 2011 17:03:29 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ECFB05B.2060501@citrix.com>
	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>
	<4ECFBC35.7080202@citrix.com>
	<4ECFD531020000780006366D@nat28.tlf.novell.com>
In-Reply-To: <4ECFD531020000780006366D@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
	the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 25/11/11 16:49, Jan Beulich wrote:
>>>> On 25.11.11 at 17:03, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 25/11/11 15:36, Jan Beulich wrote:
>>>>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> Where's that happening? Are you perhaps mis-interpreting the
>>> purpose of these ranges?
>> I might possibly be misinterpreting these ranges as the only
>> documentation is the code, but I believe I have got it correct based on
>> the upstream Linux code.  What are your interpretations of the ranges?
> The ranges are to say "if the system has between <start> and <end>
> amount of memory, then allocate a <size> block (possibly located at
> <offset>).

Ah ok.  That actually makes more logical sense.  Is there some
documentation as to exactly what is permitted to specify? I have not
been able to find any.

>>>> 4) Remove the kexec reservation code when considering modules
>>>>     This code only had any effect for people using the "newer" syntax
>>>>     on the command line, as people using the "classic" syntax would
>>>>     reserve a memory region before considering modules.
>>> Are you sure? How do you prevent the kexec area from overlapping
>>> any of the modules (in particular the initrd, which can get passed in
>>> place to Dom0)?
>> Good point, which is why this is an RFC.  Note that the "classic"
>> syntax, which everyone refers to in documents on the subject, will never
>> consider any of the modules.
> It won't in either case when addresses are specified. It will in
> both cases when only sizes are provided.

How can you specify an offset while using the range syntax?  This leaves
the classic syntax as the only way to specific an exact location in memory.

>> I am not really sure which is best, but I
>> would consider positioning the kdump kernel more important than the
>> location of initrd.  The user is likely to know more about why their
>> kdump kernel needs to be located where specified than Xen does.  Perhaps
>> after deciding where the kdump kernel should go, we should move any
>> overlapping modules?
> And that's already happening (or is at least supposed to be).
>
> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 17:04:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 17:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTzC2-0001dC-7B; Fri, 25 Nov 2011 17:04:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RTzC1-0001d6-8c
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 17:04:05 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322240611!3059752!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27793 invoked from network); 25 Nov 2011 17:03:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 17:03:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19410522"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:03:30 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	12:03:30 -0500
Message-ID: <4ECFCA61.1090401@citrix.com>
Date: Fri, 25 Nov 2011 17:03:29 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ECFB05B.2060501@citrix.com>
	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>
	<4ECFBC35.7080202@citrix.com>
	<4ECFD531020000780006366D@nat28.tlf.novell.com>
In-Reply-To: <4ECFD531020000780006366D@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
	the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 25/11/11 16:49, Jan Beulich wrote:
>>>> On 25.11.11 at 17:03, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 25/11/11 15:36, Jan Beulich wrote:
>>>>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> Where's that happening? Are you perhaps mis-interpreting the
>>> purpose of these ranges?
>> I might possibly be misinterpreting these ranges as the only
>> documentation is the code, but I believe I have got it correct based on
>> the upstream Linux code.  What are your interpretations of the ranges?
> The ranges are to say "if the system has between <start> and <end>
> amount of memory, then allocate a <size> block (possibly located at
> <offset>).

Ah ok.  That actually makes more logical sense.  Is there some
documentation as to exactly what is permitted to specify? I have not
been able to find any.

>>>> 4) Remove the kexec reservation code when considering modules
>>>>     This code only had any effect for people using the "newer" syntax
>>>>     on the command line, as people using the "classic" syntax would
>>>>     reserve a memory region before considering modules.
>>> Are you sure? How do you prevent the kexec area from overlapping
>>> any of the modules (in particular the initrd, which can get passed in
>>> place to Dom0)?
>> Good point, which is why this is an RFC.  Note that the "classic"
>> syntax, which everyone refers to in documents on the subject, will never
>> consider any of the modules.
> It won't in either case when addresses are specified. It will in
> both cases when only sizes are provided.

How can you specify an offset while using the range syntax?  This leaves
the classic syntax as the only way to specific an exact location in memory.

>> I am not really sure which is best, but I
>> would consider positioning the kdump kernel more important than the
>> location of initrd.  The user is likely to know more about why their
>> kdump kernel needs to be located where specified than Xen does.  Perhaps
>> after deciding where the kdump kernel should go, we should move any
>> overlapping modules?
> And that's already happening (or is at least supposed to be).
>
> Jan
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 17:07:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 17:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTzFL-0001n6-TE; Fri, 25 Nov 2011 17:07:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTzFK-0001mr-H8
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 17:07:30 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322240817!3062925!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12640 invoked from network); 25 Nov 2011 17:06:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 17:06:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9135576"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 17:06:50 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 25 Nov 2011
	17:06:50 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 25 Nov 2011 17:06:49 +0000
Thread-Topic: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document
	describing the xl cfg file syntax
Thread-Index: AcyrkMs90eUNvw/0TbedQYJ4tMT/YAAA8zHw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4D05@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
	<1322233543.1005.261.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4CE6@LONPMAILBOX01.citrite.net>
	<1322239165.1005.280.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322239165.1005.280.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document describing
 the xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Looks ok to me.

  Paul

> -----Original Message-----
> From: Ian Campbell
> Sent: 25 November 2011 16:39
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com; Ian Jackson
> Subject: RE: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document
> describing the xl cfg file syntax
> 
> On Fri, 2011-11-25 at 15:16 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 25 November 2011 15:06
> > > To: xen-devel@lists.xensource.com
> > > Cc: Ian Jackson; Paul Durrant
> > > Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a
> document
> > > describing the xl cfg file syntax
> > >
> > > Paul,
> > >
> > > On Fri, 2011-11-25 at 14:49 +0000, Ian Campbell wrote:
> > > >
> > > > +=item B<viridian=BOOLEAN>
> > > > +
> > > > +Turns on or off the exposure of MicroSoft Hyper-V (AKA
> viridian)
> > > > +compatible enlightenments to the guest.  These can improve
> > > > performance
> > > > +of Microsoft Windows guests (XXX which versions of Windows
> > > benefit?)
> > >
> > > Is there anything else we can say here? What are the first
> versions
> > > of Windows which benefit from this?
> > >
> >
> > Ian,
> >
> >   I think that's probably good enough. AFAIK viridian
> enlightenments
> > came in with the 6.0 kernel in Vista/2K8 but having the flag on
> should
> > do no harm for older kernels.
> 
> How about this incremental patch?
> 
> diff -r b4c07fbe3557 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Fri Nov 25 15:11:30 2011 +0000
> +++ b/docs/man/xl.cfg.pod.5	Fri Nov 25 15:23:14 2011 +0000
> @@ -555,7 +555,13 @@ Windows L<http://wiki.xen.org/wiki/XenWi
> 
>  Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
> compatible enlightenments to the guest.  These can improve
> performance -of Microsoft Windows guests (XXX which versions of
> Windows benefit?)
> +of Microsoft Windows guests from Windows Vista and Windows 2008
> onwards
> +and setting this option for such guests is strongly recommended.
> This
> +option should be harmless for other versions of Windows (although
> it
> +won't give any benefit) and the majority of other non-Windows OSes.
> +However it is known to be incompatible with some other Operating
> +Systems and in some circumstance can prevent Xen's own
> +paravirtualisation interfaces for HVM guests from being used.
> 
>  =back
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 17:07:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 17:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTzFL-0001n6-TE; Fri, 25 Nov 2011 17:07:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RTzFK-0001mr-H8
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 17:07:30 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322240817!3062925!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12640 invoked from network); 25 Nov 2011 17:06:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 17:06:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; 
   d="scan'208";a="9135576"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 17:06:50 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Fri, 25 Nov 2011
	17:06:50 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 25 Nov 2011 17:06:49 +0000
Thread-Topic: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document
	describing the xl cfg file syntax
Thread-Index: AcyrkMs90eUNvw/0TbedQYJ4tMT/YAAA8zHw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4D05@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<08a74d202a0a5b19b122.1322232577@cosworth.uk.xensource.com>
	<1322233543.1005.261.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4CE6@LONPMAILBOX01.citrite.net>
	<1322239165.1005.280.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322239165.1005.280.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document describing
 the xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Looks ok to me.

  Paul

> -----Original Message-----
> From: Ian Campbell
> Sent: 25 November 2011 16:39
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com; Ian Jackson
> Subject: RE: [Xen-devel] [PATCH 05 of 15 v2] docs: add a document
> describing the xl cfg file syntax
> 
> On Fri, 2011-11-25 at 15:16 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 25 November 2011 15:06
> > > To: xen-devel@lists.xensource.com
> > > Cc: Ian Jackson; Paul Durrant
> > > Subject: Re: [Xen-devel] [PATCH 05 of 15 v2] docs: add a
> document
> > > describing the xl cfg file syntax
> > >
> > > Paul,
> > >
> > > On Fri, 2011-11-25 at 14:49 +0000, Ian Campbell wrote:
> > > >
> > > > +=item B<viridian=BOOLEAN>
> > > > +
> > > > +Turns on or off the exposure of MicroSoft Hyper-V (AKA
> viridian)
> > > > +compatible enlightenments to the guest.  These can improve
> > > > performance
> > > > +of Microsoft Windows guests (XXX which versions of Windows
> > > benefit?)
> > >
> > > Is there anything else we can say here? What are the first
> versions
> > > of Windows which benefit from this?
> > >
> >
> > Ian,
> >
> >   I think that's probably good enough. AFAIK viridian
> enlightenments
> > came in with the 6.0 kernel in Vista/2K8 but having the flag on
> should
> > do no harm for older kernels.
> 
> How about this incremental patch?
> 
> diff -r b4c07fbe3557 docs/man/xl.cfg.pod.5
> --- a/docs/man/xl.cfg.pod.5	Fri Nov 25 15:11:30 2011 +0000
> +++ b/docs/man/xl.cfg.pod.5	Fri Nov 25 15:23:14 2011 +0000
> @@ -555,7 +555,13 @@ Windows L<http://wiki.xen.org/wiki/XenWi
> 
>  Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
> compatible enlightenments to the guest.  These can improve
> performance -of Microsoft Windows guests (XXX which versions of
> Windows benefit?)
> +of Microsoft Windows guests from Windows Vista and Windows 2008
> onwards
> +and setting this option for such guests is strongly recommended.
> This
> +option should be harmless for other versions of Windows (although
> it
> +won't give any benefit) and the majority of other non-Windows OSes.
> +However it is known to be incompatible with some other Operating
> +Systems and in some circumstance can prevent Xen's own
> +paravirtualisation interfaces for HVM guests from being used.
> 
>  =back
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 17:09:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 17:09:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTzHE-0001uk-Dy; Fri, 25 Nov 2011 17:09:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RTzHD-0001uT-Jq
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 17:09:27 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322240933!5036782!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24227 invoked from network); 25 Nov 2011 17:08:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 17:08:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19410589"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:08:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 12:08:53 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAPH8pBL030822;
	Fri, 25 Nov 2011 09:08:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: 68ac72db10a3d9772a2570ff1c32bd1487a67030
Message-ID: <68ac72db10a3d9772a25.1322241169@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Fri, 25 Nov 2011 17:12:49 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] Trace traps and realmode exits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add some more tracing to vmexits that don't currently have
trace information:
 * VMX realmode emulation
 * Various VMX traps
 * Fast-pathed APIC accesses

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 96bbdc894224 -r 68ac72db10a3 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Fri Nov 25 15:48:03 2011 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Fri Nov 25 17:12:41 2011 +0000
@@ -2217,6 +2217,7 @@ static int vmx_handle_eoi_write(void)
     {
         update_guest_eip(); /* Safe: APIC data write */
         vlapic_EOI_set(vcpu_vlapic(current));
+        HVMTRACE_0D(VLAPIC);
         return 1;
     }
 
@@ -2324,6 +2325,7 @@ asmlinkage void vmx_vmexit_handler(struc
             {
                 perfc_incr(realmode_exits);
                 v->arch.hvm_vmx.vmx_emulate = 1;
+                HVMTRACE_0D(REALMODE_EMULATE);
                 return;
             }
         case EXIT_REASON_EXTERNAL_INTERRUPT:
@@ -2343,6 +2345,7 @@ asmlinkage void vmx_vmexit_handler(struc
         default:
             v->arch.hvm_vmx.vmx_emulate = 1;
             perfc_incr(realmode_exits);
+            HVMTRACE_0D(REALMODE_EMULATE);
             return;
         }
     }
@@ -2386,6 +2389,7 @@ asmlinkage void vmx_vmexit_handler(struc
              * Table 23-1, "Exit Qualification for Debug Exceptions").
              */
             exit_qualification = __vmread(EXIT_QUALIFICATION);
+            HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
             write_debugreg(6, exit_qualification | 0xffff0ff0);
             if ( !v->domain->debugger_attached || cpu_has_monitor_trap_flag )
                 goto exit_and_crash;
@@ -2393,6 +2397,7 @@ asmlinkage void vmx_vmexit_handler(struc
             break;
         case TRAP_int3: 
         {
+            HVMTRACE_1D(TRAP, vector);
             if ( v->domain->debugger_attached )
             {
                 update_guest_eip(); /* Safe: INT3 */            
@@ -2415,6 +2420,7 @@ asmlinkage void vmx_vmexit_handler(struc
             goto exit_and_crash;
         }
         case TRAP_no_device:
+            HVMTRACE_1D(TRAP, vector);
             vmx_fpu_dirty_intercept();
             break;
         case TRAP_page_fault:
@@ -2455,9 +2461,11 @@ asmlinkage void vmx_vmexit_handler(struc
             /* Already handled above. */
             break;
         case TRAP_invalid_op:
+            HVMTRACE_1D(TRAP, vector);
             vmx_vmexit_ud_intercept(regs);
             break;
         default:
+            HVMTRACE_1D(TRAP, vector);
             goto exit_and_crash;
         }
         break;
diff -r 96bbdc894224 -r 68ac72db10a3 xen/include/asm-x86/hvm/trace.h
--- a/xen/include/asm-x86/hvm/trace.h	Fri Nov 25 15:48:03 2011 +0000
+++ b/xen/include/asm-x86/hvm/trace.h	Fri Nov 25 17:12:41 2011 +0000
@@ -50,6 +50,10 @@
 #define DO_TRC_HVM_CLTS        DEFAULT_HVM_MISC
 #define DO_TRC_HVM_LMSW        DEFAULT_HVM_MISC
 #define DO_TRC_HVM_LMSW64      DEFAULT_HVM_MISC
+#define DO_TRC_HVM_REALMODE_EMULATE DEFAULT_HVM_MISC 
+#define DO_TRC_HVM_TRAP             DEFAULT_HVM_MISC
+#define DO_TRC_HVM_TRAP_DEBUG       DEFAULT_HVM_MISC
+#define DO_TRC_HVM_VLAPIC           DEFAULT_HVM_MISC
 
 
 #ifdef __x86_64__
diff -r 96bbdc894224 -r 68ac72db10a3 xen/include/public/trace.h
--- a/xen/include/public/trace.h	Fri Nov 25 15:48:03 2011 +0000
+++ b/xen/include/public/trace.h	Fri Nov 25 17:12:41 2011 +0000
@@ -164,6 +164,10 @@
 #define TRC_HVM_RDTSC           (TRC_HVM_HANDLER + 0x1a)
 #define TRC_HVM_INTR_WINDOW     (TRC_HVM_HANDLER + 0x20)
 #define TRC_HVM_NPF             (TRC_HVM_HANDLER + 0x21)
+#define TRC_HVM_REALMODE_EMULATE (TRC_HVM_HANDLER + 0x22)
+#define TRC_HVM_TRAP             (TRC_HVM_HANDLER + 0x23)
+#define TRC_HVM_TRAP_DEBUG       (TRC_HVM_HANDLER + 0x24)
+#define TRC_HVM_VLAPIC           (TRC_HVM_HANDLER + 0x25)
 
 #define TRC_HVM_IOPORT_WRITE    (TRC_HVM_HANDLER + 0x216)
 #define TRC_HVM_IOMEM_WRITE     (TRC_HVM_HANDLER + 0x217)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 17:09:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 17:09:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTzHE-0001uk-Dy; Fri, 25 Nov 2011 17:09:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RTzHD-0001uT-Jq
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 17:09:27 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322240933!5036782!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24227 invoked from network); 25 Nov 2011 17:08:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 17:08:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19410589"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:08:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 12:08:53 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAPH8pBL030822;
	Fri, 25 Nov 2011 09:08:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: 68ac72db10a3d9772a2570ff1c32bd1487a67030
Message-ID: <68ac72db10a3d9772a25.1322241169@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Fri, 25 Nov 2011 17:12:49 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] Trace traps and realmode exits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add some more tracing to vmexits that don't currently have
trace information:
 * VMX realmode emulation
 * Various VMX traps
 * Fast-pathed APIC accesses

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 96bbdc894224 -r 68ac72db10a3 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Fri Nov 25 15:48:03 2011 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Fri Nov 25 17:12:41 2011 +0000
@@ -2217,6 +2217,7 @@ static int vmx_handle_eoi_write(void)
     {
         update_guest_eip(); /* Safe: APIC data write */
         vlapic_EOI_set(vcpu_vlapic(current));
+        HVMTRACE_0D(VLAPIC);
         return 1;
     }
 
@@ -2324,6 +2325,7 @@ asmlinkage void vmx_vmexit_handler(struc
             {
                 perfc_incr(realmode_exits);
                 v->arch.hvm_vmx.vmx_emulate = 1;
+                HVMTRACE_0D(REALMODE_EMULATE);
                 return;
             }
         case EXIT_REASON_EXTERNAL_INTERRUPT:
@@ -2343,6 +2345,7 @@ asmlinkage void vmx_vmexit_handler(struc
         default:
             v->arch.hvm_vmx.vmx_emulate = 1;
             perfc_incr(realmode_exits);
+            HVMTRACE_0D(REALMODE_EMULATE);
             return;
         }
     }
@@ -2386,6 +2389,7 @@ asmlinkage void vmx_vmexit_handler(struc
              * Table 23-1, "Exit Qualification for Debug Exceptions").
              */
             exit_qualification = __vmread(EXIT_QUALIFICATION);
+            HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
             write_debugreg(6, exit_qualification | 0xffff0ff0);
             if ( !v->domain->debugger_attached || cpu_has_monitor_trap_flag )
                 goto exit_and_crash;
@@ -2393,6 +2397,7 @@ asmlinkage void vmx_vmexit_handler(struc
             break;
         case TRAP_int3: 
         {
+            HVMTRACE_1D(TRAP, vector);
             if ( v->domain->debugger_attached )
             {
                 update_guest_eip(); /* Safe: INT3 */            
@@ -2415,6 +2420,7 @@ asmlinkage void vmx_vmexit_handler(struc
             goto exit_and_crash;
         }
         case TRAP_no_device:
+            HVMTRACE_1D(TRAP, vector);
             vmx_fpu_dirty_intercept();
             break;
         case TRAP_page_fault:
@@ -2455,9 +2461,11 @@ asmlinkage void vmx_vmexit_handler(struc
             /* Already handled above. */
             break;
         case TRAP_invalid_op:
+            HVMTRACE_1D(TRAP, vector);
             vmx_vmexit_ud_intercept(regs);
             break;
         default:
+            HVMTRACE_1D(TRAP, vector);
             goto exit_and_crash;
         }
         break;
diff -r 96bbdc894224 -r 68ac72db10a3 xen/include/asm-x86/hvm/trace.h
--- a/xen/include/asm-x86/hvm/trace.h	Fri Nov 25 15:48:03 2011 +0000
+++ b/xen/include/asm-x86/hvm/trace.h	Fri Nov 25 17:12:41 2011 +0000
@@ -50,6 +50,10 @@
 #define DO_TRC_HVM_CLTS        DEFAULT_HVM_MISC
 #define DO_TRC_HVM_LMSW        DEFAULT_HVM_MISC
 #define DO_TRC_HVM_LMSW64      DEFAULT_HVM_MISC
+#define DO_TRC_HVM_REALMODE_EMULATE DEFAULT_HVM_MISC 
+#define DO_TRC_HVM_TRAP             DEFAULT_HVM_MISC
+#define DO_TRC_HVM_TRAP_DEBUG       DEFAULT_HVM_MISC
+#define DO_TRC_HVM_VLAPIC           DEFAULT_HVM_MISC
 
 
 #ifdef __x86_64__
diff -r 96bbdc894224 -r 68ac72db10a3 xen/include/public/trace.h
--- a/xen/include/public/trace.h	Fri Nov 25 15:48:03 2011 +0000
+++ b/xen/include/public/trace.h	Fri Nov 25 17:12:41 2011 +0000
@@ -164,6 +164,10 @@
 #define TRC_HVM_RDTSC           (TRC_HVM_HANDLER + 0x1a)
 #define TRC_HVM_INTR_WINDOW     (TRC_HVM_HANDLER + 0x20)
 #define TRC_HVM_NPF             (TRC_HVM_HANDLER + 0x21)
+#define TRC_HVM_REALMODE_EMULATE (TRC_HVM_HANDLER + 0x22)
+#define TRC_HVM_TRAP             (TRC_HVM_HANDLER + 0x23)
+#define TRC_HVM_TRAP_DEBUG       (TRC_HVM_HANDLER + 0x24)
+#define TRC_HVM_VLAPIC           (TRC_HVM_HANDLER + 0x25)
 
 #define TRC_HVM_IOPORT_WRITE    (TRC_HVM_HANDLER + 0x216)
 #define TRC_HVM_IOMEM_WRITE     (TRC_HVM_HANDLER + 0x217)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 17:50:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 17:50:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTzuZ-0002j8-G5; Fri, 25 Nov 2011 17:50:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RTzuX-0002j3-Qp
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 17:50:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322243371!3066745!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19670 invoked from network); 25 Nov 2011 17:49:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 17:49:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19411311"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:49:31 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	12:49:31 -0500
Message-ID: <4ECFD528.2090102@citrix.com>
Date: Fri, 25 Nov 2011 17:49:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ECFB05B.2060501@citrix.com>	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>	<4ECFBC35.7080202@citrix.com>	<4ECFD531020000780006366D@nat28.tlf.novell.com>
	<4ECFCA61.1090401@citrix.com>
In-Reply-To: <4ECFCA61.1090401@citrix.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
 the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/11 17:03, Andrew Cooper wrote:
>
> On 25/11/11 16:49, Jan Beulich wrote:
>>>>> On 25.11.11 at 17:03, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 25/11/11 15:36, Jan Beulich wrote:
>>>>>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> Where's that happening? Are you perhaps mis-interpreting the
>>>> purpose of these ranges?
>>> I might possibly be misinterpreting these ranges as the only
>>> documentation is the code, but I believe I have got it correct based on
>>> the upstream Linux code.  What are your interpretations of the ranges?
>> The ranges are to say "if the system has between <start> and <end>
>> amount of memory, then allocate a <size> block (possibly located at
>> <offset>).
> Ah ok.  That actually makes more logical sense.  Is there some
> documentation as to exactly what is permitted to specify? I have not
> been able to find any.
>
>>>>> 4) Remove the kexec reservation code when considering modules
>>>>>     This code only had any effect for people using the "newer" syntax
>>>>>     on the command line, as people using the "classic" syntax would
>>>>>     reserve a memory region before considering modules.
>>>> Are you sure? How do you prevent the kexec area from overlapping
>>>> any of the modules (in particular the initrd, which can get passed in
>>>> place to Dom0)?
>>> Good point, which is why this is an RFC.  Note that the "classic"
>>> syntax, which everyone refers to in documents on the subject, will never
>>> consider any of the modules.
>> It won't in either case when addresses are specified. It will in
>> both cases when only sizes are provided.
> How can you specify an offset while using the range syntax?  This leaves
> the classic syntax as the only way to specific an exact location in memory.
>
>>> I am not really sure which is best, but I
>>> would consider positioning the kdump kernel more important than the
>>> location of initrd.  The user is likely to know more about why their
>>> kdump kernel needs to be located where specified than Xen does.  Perhaps
>>> after deciding where the kdump kernel should go, we should move any
>>> overlapping modules?
>> And that's already happening (or is at least supposed to be).
>>
>> Jan

After comparing the Xen parsing code with the Linux parsing code, with
the correct idea of what we are trying to do, Xen still lacks the
ability to specify an exact offset using the newer style.  I will
implement this.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 17:50:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 17:50:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RTzuZ-0002j8-G5; Fri, 25 Nov 2011 17:50:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RTzuX-0002j3-Qp
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 17:50:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322243371!3066745!1
X-Originating-IP: [66.165.176.89]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19670 invoked from network); 25 Nov 2011 17:49:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 17:49:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,572,1315195200"; d="scan'208";a="19411311"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 12:49:31 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Fri, 25 Nov 2011
	12:49:31 -0500
Message-ID: <4ECFD528.2090102@citrix.com>
Date: Fri, 25 Nov 2011 17:49:28 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ECFB05B.2060501@citrix.com>	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>	<4ECFBC35.7080202@citrix.com>	<4ECFD531020000780006366D@nat28.tlf.novell.com>
	<4ECFCA61.1090401@citrix.com>
In-Reply-To: <4ECFCA61.1090401@citrix.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
 the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/11 17:03, Andrew Cooper wrote:
>
> On 25/11/11 16:49, Jan Beulich wrote:
>>>>> On 25.11.11 at 17:03, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 25/11/11 15:36, Jan Beulich wrote:
>>>>>>> On 25.11.11 at 16:12, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> Where's that happening? Are you perhaps mis-interpreting the
>>>> purpose of these ranges?
>>> I might possibly be misinterpreting these ranges as the only
>>> documentation is the code, but I believe I have got it correct based on
>>> the upstream Linux code.  What are your interpretations of the ranges?
>> The ranges are to say "if the system has between <start> and <end>
>> amount of memory, then allocate a <size> block (possibly located at
>> <offset>).
> Ah ok.  That actually makes more logical sense.  Is there some
> documentation as to exactly what is permitted to specify? I have not
> been able to find any.
>
>>>>> 4) Remove the kexec reservation code when considering modules
>>>>>     This code only had any effect for people using the "newer" syntax
>>>>>     on the command line, as people using the "classic" syntax would
>>>>>     reserve a memory region before considering modules.
>>>> Are you sure? How do you prevent the kexec area from overlapping
>>>> any of the modules (in particular the initrd, which can get passed in
>>>> place to Dom0)?
>>> Good point, which is why this is an RFC.  Note that the "classic"
>>> syntax, which everyone refers to in documents on the subject, will never
>>> consider any of the modules.
>> It won't in either case when addresses are specified. It will in
>> both cases when only sizes are provided.
> How can you specify an offset while using the range syntax?  This leaves
> the classic syntax as the only way to specific an exact location in memory.
>
>>> I am not really sure which is best, but I
>>> would consider positioning the kdump kernel more important than the
>>> location of initrd.  The user is likely to know more about why their
>>> kdump kernel needs to be located where specified than Xen does.  Perhaps
>>> after deciding where the kdump kernel should go, we should move any
>>> overlapping modules?
>> And that's already happening (or is at least supposed to be).
>>
>> Jan

After comparing the Xen parsing code with the Linux parsing code, with
the correct idea of what we are trying to do, Xen still lacks the
ability to specify an exact offset using the newer style.  I will
implement this.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 18:07:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 18:07:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU0B5-00030E-5S; Fri, 25 Nov 2011 18:07:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthoine.bourgeois@gmail.com>) id 1RU0B3-000309-MQ
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 18:07:09 +0000
X-Env-Sender: anthoine.bourgeois@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322244368!49984020!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28094 invoked from network); 25 Nov 2011 18:06:10 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 18:06:10 -0000
Received: by ghbz2 with SMTP id z2so5592140ghb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 10:06:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=rYZXMyAqJECZ7zRkgvA08s/skKCtlPwH3d8hl/gyofs=;
	b=SevNL7i9Y4rAaUDob1R59zC0hp6UFUhk5HzzUxMfHZ4EpisiG5NXQ1N+X7bNonFCz4
	L7KSDd73sFp0zVPaWBstwV4FEkLgVFmK4+Bco41baCiF/gc4quG1yO3q8VEvEkBhgd3B
	eBTJg0dMHXQfTyAa+MdMR0+GOp6sNMtapMXWY=
MIME-Version: 1.0
Received: by 10.68.0.129 with SMTP id 1mr29149027pbe.94.1322244396976; Fri, 25
	Nov 2011 10:06:36 -0800 (PST)
Received: by 10.142.233.7 with HTTP; Fri, 25 Nov 2011 10:06:36 -0800 (PST)
In-Reply-To: <1322124079.9567.36.camel@dagon.hellion.org.uk>
References: <CAHHxriBEsA-23K5QMe3eE-=8Ca6mbsQ4x7C0TG+ap_TRv2vXbg@mail.gmail.com>
	<1322124079.9567.36.camel@dagon.hellion.org.uk>
Date: Fri, 25 Nov 2011 19:06:36 +0100
Message-ID: <CAHHxriC5jk-3-Mbpqp1BDWkTzY7c3nOL__-Q0xM-_GHaOeC6UA@mail.gmail.com>
From: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [patch] Initialize xen_vcpu0 before initialize
	irq_ops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/24 Ian Campbell <Ian.Campbell@citrix.com>:
> CC'ing Xen Liunx maintainers, please consult MAINTAINERS or
> use ./scripts/get_maintainer.pl.
>
> This local_irq_disable is interesting. Aren't IRQs supposed to already
> be disabled from entry to xen_start_kernel (really, since start of time)
> until at least this point?
>
> Enabling (or disabling) interrupts would require both xen_init_irq_ops()
> and xen_vcpu[0] to be setup, so it seems that either interrupts are not
> disabled at start of day (I'm fairly sure they are) or there is some
> magic code somewhere which does it directly without using the generic
> infrastructure (I can't find anything like that).
>
> So where do interrupts get enabled? Is before xen_init_irq_ops really
> early enough? I can't find anything between the old and new locations of
> this setup code which looks like it would enable them. It is possible
> that you just win the race on your slow systems now but that the window
> is still there.

Hum, you're right, there is something strange here.
I don't know why interrupts are enabled. I investigate and come back to
you later. Looks like my bug is elsewhere.
I'll CC Xen Liunx maintainers as you have advised me next time.
Thanks.

--
Anthoine

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 18:07:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 18:07:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU0B5-00030E-5S; Fri, 25 Nov 2011 18:07:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthoine.bourgeois@gmail.com>) id 1RU0B3-000309-MQ
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 18:07:09 +0000
X-Env-Sender: anthoine.bourgeois@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322244368!49984020!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28094 invoked from network); 25 Nov 2011 18:06:10 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 18:06:10 -0000
Received: by ghbz2 with SMTP id z2so5592140ghb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 10:06:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=rYZXMyAqJECZ7zRkgvA08s/skKCtlPwH3d8hl/gyofs=;
	b=SevNL7i9Y4rAaUDob1R59zC0hp6UFUhk5HzzUxMfHZ4EpisiG5NXQ1N+X7bNonFCz4
	L7KSDd73sFp0zVPaWBstwV4FEkLgVFmK4+Bco41baCiF/gc4quG1yO3q8VEvEkBhgd3B
	eBTJg0dMHXQfTyAa+MdMR0+GOp6sNMtapMXWY=
MIME-Version: 1.0
Received: by 10.68.0.129 with SMTP id 1mr29149027pbe.94.1322244396976; Fri, 25
	Nov 2011 10:06:36 -0800 (PST)
Received: by 10.142.233.7 with HTTP; Fri, 25 Nov 2011 10:06:36 -0800 (PST)
In-Reply-To: <1322124079.9567.36.camel@dagon.hellion.org.uk>
References: <CAHHxriBEsA-23K5QMe3eE-=8Ca6mbsQ4x7C0TG+ap_TRv2vXbg@mail.gmail.com>
	<1322124079.9567.36.camel@dagon.hellion.org.uk>
Date: Fri, 25 Nov 2011 19:06:36 +0100
Message-ID: <CAHHxriC5jk-3-Mbpqp1BDWkTzY7c3nOL__-Q0xM-_GHaOeC6UA@mail.gmail.com>
From: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [patch] Initialize xen_vcpu0 before initialize
	irq_ops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2011/11/24 Ian Campbell <Ian.Campbell@citrix.com>:
> CC'ing Xen Liunx maintainers, please consult MAINTAINERS or
> use ./scripts/get_maintainer.pl.
>
> This local_irq_disable is interesting. Aren't IRQs supposed to already
> be disabled from entry to xen_start_kernel (really, since start of time)
> until at least this point?
>
> Enabling (or disabling) interrupts would require both xen_init_irq_ops()
> and xen_vcpu[0] to be setup, so it seems that either interrupts are not
> disabled at start of day (I'm fairly sure they are) or there is some
> magic code somewhere which does it directly without using the generic
> infrastructure (I can't find anything like that).
>
> So where do interrupts get enabled? Is before xen_init_irq_ops really
> early enough? I can't find anything between the old and new locations of
> this setup code which looks like it would enable them. It is possible
> that you just win the race on your slow systems now but that the window
> is still there.

Hum, you're right, there is something strange here.
I don't know why interrupts are enabled. I investigate and come back to
you later. Looks like my bug is elsewhere.
I'll CC Xen Liunx maintainers as you have advised me next time.
Thanks.

--
Anthoine

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 18:28:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 18:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU0Um-0003Fl-1A; Fri, 25 Nov 2011 18:27:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RU0Uk-0003Fg-IQ
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 18:27:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322245617!5698727!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31449 invoked from network); 25 Nov 2011 18:26:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2011 18:26:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322245617; l=265;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=6DJdst4kdF4WmbftSXm7xDt9pUY=;
	b=T4K9TsAwZHv5rzWEhAVHF4f1HMoJ/ytl2Hig01SeP7qXLbONl3W0eCBE2JTgSRSGc7i
	qZiGkl+EP86evNNja24Ml0YavUoB+qSsAw+H2WlgURFFuVHJWW5VsZq32g5IPstXgfBEm
	vdFjg5j25ulQltI5zKaoIPUqXd8iCpCBz2g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by smtp.strato.de (jimi mo8) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f05e10nAPHgdWN ;
	Fri, 25 Nov 2011 19:26:46 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 123EE18637; Fri, 25 Nov 2011 19:26:45 +0100 (CET)
Date: Fri, 25 Nov 2011 19:26:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111125182645.GA27992@aepfle.de>
References: <20111123223049.GA14423@aepfle.de>
	<CAF32E64.25744%keir.xen@gmail.com>
	<20111124100021.GA17462@aepfle.de>
	<20111125125604.GA14585@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111125125604.GA14585@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


One more thing:

Is the BUG_ON in destroy_waitqueue_vcpu really required? If the vcpu
happens to be in a queue by the time xl destroy is called the hypervisor
will crash.

Perhaps there should be some sort of domain destructor for each
waitqueue?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 18:28:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 18:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU0Um-0003Fl-1A; Fri, 25 Nov 2011 18:27:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RU0Uk-0003Fg-IQ
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 18:27:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322245617!5698727!1
X-Originating-IP: [81.169.146.161]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31449 invoked from network); 25 Nov 2011 18:26:57 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2011 18:26:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322245617; l=265;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=6DJdst4kdF4WmbftSXm7xDt9pUY=;
	b=T4K9TsAwZHv5rzWEhAVHF4f1HMoJ/ytl2Hig01SeP7qXLbONl3W0eCBE2JTgSRSGc7i
	qZiGkl+EP86evNNja24Ml0YavUoB+qSsAw+H2WlgURFFuVHJWW5VsZq32g5IPstXgfBEm
	vdFjg5j25ulQltI5zKaoIPUqXd8iCpCBz2g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjDEQEiPRxA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-122-157.pools.arcor-ip.net [88.65.122.157])
	by smtp.strato.de (jimi mo8) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f05e10nAPHgdWN ;
	Fri, 25 Nov 2011 19:26:46 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 123EE18637; Fri, 25 Nov 2011 19:26:45 +0100 (CET)
Date: Fri, 25 Nov 2011 19:26:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111125182645.GA27992@aepfle.de>
References: <20111123223049.GA14423@aepfle.de>
	<CAF32E64.25744%keir.xen@gmail.com>
	<20111124100021.GA17462@aepfle.de>
	<20111125125604.GA14585@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111125125604.GA14585@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


One more thing:

Is the BUG_ON in destroy_waitqueue_vcpu really required? If the vcpu
happens to be in a queue by the time xl destroy is called the hypervisor
will crash.

Perhaps there should be some sort of domain destructor for each
waitqueue?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 18:38:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 18:38:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU0eb-0003aT-50; Fri, 25 Nov 2011 18:37:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RU0eZ-0003aO-7u
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 18:37:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322246226!6366507!1
X-Originating-IP: [63.239.65.40]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19534 invoked from network); 25 Nov 2011 18:37:06 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-2.tower-216.messagelabs.com with SMTP;
	25 Nov 2011 18:37:06 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAPIarvF011470; Fri, 25 Nov 2011 18:36:53 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAPIarKU031696; 
	Fri, 25 Nov 2011 13:36:53 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Anil Madhavapeddy <anil@recoil.org>, konrad.wilk@oracle.com
Date: Fri, 25 Nov 2011 13:37:11 -0500
Message-Id: <1322246231-1617-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322240210-8503-2-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322240210-8503-2-git-send-email-dgdegra@tycho.nsa.gov>
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>, Ian.Campbell@eu.citrix.com,
	Vasiliy Tolstov <v.tolstov@ghs.l.google.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xen/gntalloc: fix reference counts on
	multi-page mappings
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When a multi-page mapping of gntalloc is created, the reference counts
of all pages in the vma are incremented. However, the vma open/close
operations only adjusted the reference count of the first page in the
mapping, leaking the other pages. Store a struct in the vm_private_data
to track the original page count to properly free the pages when the
last reference to the vma is closed.

Reported-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntalloc.c |   56 ++++++++++++++++++++++++++++++++++++-----------
 1 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 7b936cc..e2400c8 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -99,6 +99,12 @@ struct gntalloc_file_private_data {
 	uint64_t index;
 };
 
+struct gntalloc_vma_private_data {
+	struct gntalloc_gref *gref;
+	int users;
+	int count;
+};
+
 static void __del_gref(struct gntalloc_gref *gref);
 
 static void do_cleanup(void)
@@ -451,25 +457,39 @@ static long gntalloc_ioctl(struct file *filp, unsigned int cmd,
 
 static void gntalloc_vma_open(struct vm_area_struct *vma)
 {
-	struct gntalloc_gref *gref = vma->vm_private_data;
-	if (!gref)
+	struct gntalloc_vma_private_data *priv = vma->vm_private_data;
+
+	if (!priv)
 		return;
 
 	mutex_lock(&gref_mutex);
-	gref->users++;
+	priv->users++;
 	mutex_unlock(&gref_mutex);
 }
 
 static void gntalloc_vma_close(struct vm_area_struct *vma)
 {
-	struct gntalloc_gref *gref = vma->vm_private_data;
-	if (!gref)
+	struct gntalloc_vma_private_data *priv = vma->vm_private_data;
+	struct gntalloc_gref *gref, *next;
+	int i;
+
+	if (!priv)
 		return;
 
 	mutex_lock(&gref_mutex);
-	gref->users--;
-	if (gref->users == 0)
-		__del_gref(gref);
+	priv->users--;
+	if (priv->users == 0) {
+		gref = priv->gref;
+		for (i = 0; i < priv->count; i++) {
+			gref->users--;
+			next = list_entry(gref->next_gref.next,
+					  struct gntalloc_gref, next_gref);
+			if (gref->users == 0)
+				__del_gref(gref);
+			gref = next;
+		}
+		kfree(priv);
+	}
 	mutex_unlock(&gref_mutex);
 }
 
@@ -481,19 +501,25 @@ static struct vm_operations_struct gntalloc_vmops = {
 static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 {
 	struct gntalloc_file_private_data *priv = filp->private_data;
+	struct gntalloc_vma_private_data *vm_priv;
 	struct gntalloc_gref *gref;
 	int count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
 	int rv, i;
 
-	pr_debug("%s: priv %p, page %lu+%d\n", __func__,
-		       priv, vma->vm_pgoff, count);
-
 	if (!(vma->vm_flags & VM_SHARED)) {
 		printk(KERN_ERR "%s: Mapping must be shared.\n", __func__);
 		return -EINVAL;
 	}
 
+	vm_priv = kmalloc(sizeof(*vm_priv), GFP_KERNEL);
+	if (!vm_priv)
+		return -ENOMEM;
+
 	mutex_lock(&gref_mutex);
+
+	pr_debug("%s: priv %p,%p, page %lu+%d\n", __func__,
+		       priv, vm_priv, vma->vm_pgoff, count);
+
 	gref = find_grefs(priv, vma->vm_pgoff << PAGE_SHIFT, count);
 	if (gref == NULL) {
 		rv = -ENOENT;
@@ -502,9 +528,13 @@ static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 		goto out_unlock;
 	}
 
-	vma->vm_private_data = gref;
+	vm_priv->gref = gref;
+	vm_priv->users = 1;
+	vm_priv->count = count;
+
+	vma->vm_private_data = vm_priv;
 
-	vma->vm_flags |= VM_RESERVED;
+	vma->vm_flags |= VM_RESERVED | VM_DONTEXPAND;
 
 	vma->vm_ops = &gntalloc_vmops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 18:38:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 18:38:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU0eb-0003aT-50; Fri, 25 Nov 2011 18:37:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RU0eZ-0003aO-7u
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 18:37:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322246226!6366507!1
X-Originating-IP: [63.239.65.40]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19534 invoked from network); 25 Nov 2011 18:37:06 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-2.tower-216.messagelabs.com with SMTP;
	25 Nov 2011 18:37:06 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAPIarvF011470; Fri, 25 Nov 2011 18:36:53 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAPIarKU031696; 
	Fri, 25 Nov 2011 13:36:53 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Anil Madhavapeddy <anil@recoil.org>, konrad.wilk@oracle.com
Date: Fri, 25 Nov 2011 13:37:11 -0500
Message-Id: <1322246231-1617-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322240210-8503-2-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322240210-8503-2-git-send-email-dgdegra@tycho.nsa.gov>
Cc: xen-devel@lists.xensource.com, Stefano.Stabellini@eu.citrix.com,
	Ian Jackson <ian.jackson@eu.citrix.com>, Ian.Campbell@eu.citrix.com,
	Vasiliy Tolstov <v.tolstov@ghs.l.google.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xen/gntalloc: fix reference counts on
	multi-page mappings
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When a multi-page mapping of gntalloc is created, the reference counts
of all pages in the vma are incremented. However, the vma open/close
operations only adjusted the reference count of the first page in the
mapping, leaking the other pages. Store a struct in the vm_private_data
to track the original page count to properly free the pages when the
last reference to the vma is closed.

Reported-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntalloc.c |   56 ++++++++++++++++++++++++++++++++++++-----------
 1 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 7b936cc..e2400c8 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -99,6 +99,12 @@ struct gntalloc_file_private_data {
 	uint64_t index;
 };
 
+struct gntalloc_vma_private_data {
+	struct gntalloc_gref *gref;
+	int users;
+	int count;
+};
+
 static void __del_gref(struct gntalloc_gref *gref);
 
 static void do_cleanup(void)
@@ -451,25 +457,39 @@ static long gntalloc_ioctl(struct file *filp, unsigned int cmd,
 
 static void gntalloc_vma_open(struct vm_area_struct *vma)
 {
-	struct gntalloc_gref *gref = vma->vm_private_data;
-	if (!gref)
+	struct gntalloc_vma_private_data *priv = vma->vm_private_data;
+
+	if (!priv)
 		return;
 
 	mutex_lock(&gref_mutex);
-	gref->users++;
+	priv->users++;
 	mutex_unlock(&gref_mutex);
 }
 
 static void gntalloc_vma_close(struct vm_area_struct *vma)
 {
-	struct gntalloc_gref *gref = vma->vm_private_data;
-	if (!gref)
+	struct gntalloc_vma_private_data *priv = vma->vm_private_data;
+	struct gntalloc_gref *gref, *next;
+	int i;
+
+	if (!priv)
 		return;
 
 	mutex_lock(&gref_mutex);
-	gref->users--;
-	if (gref->users == 0)
-		__del_gref(gref);
+	priv->users--;
+	if (priv->users == 0) {
+		gref = priv->gref;
+		for (i = 0; i < priv->count; i++) {
+			gref->users--;
+			next = list_entry(gref->next_gref.next,
+					  struct gntalloc_gref, next_gref);
+			if (gref->users == 0)
+				__del_gref(gref);
+			gref = next;
+		}
+		kfree(priv);
+	}
 	mutex_unlock(&gref_mutex);
 }
 
@@ -481,19 +501,25 @@ static struct vm_operations_struct gntalloc_vmops = {
 static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 {
 	struct gntalloc_file_private_data *priv = filp->private_data;
+	struct gntalloc_vma_private_data *vm_priv;
 	struct gntalloc_gref *gref;
 	int count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
 	int rv, i;
 
-	pr_debug("%s: priv %p, page %lu+%d\n", __func__,
-		       priv, vma->vm_pgoff, count);
-
 	if (!(vma->vm_flags & VM_SHARED)) {
 		printk(KERN_ERR "%s: Mapping must be shared.\n", __func__);
 		return -EINVAL;
 	}
 
+	vm_priv = kmalloc(sizeof(*vm_priv), GFP_KERNEL);
+	if (!vm_priv)
+		return -ENOMEM;
+
 	mutex_lock(&gref_mutex);
+
+	pr_debug("%s: priv %p,%p, page %lu+%d\n", __func__,
+		       priv, vm_priv, vma->vm_pgoff, count);
+
 	gref = find_grefs(priv, vma->vm_pgoff << PAGE_SHIFT, count);
 	if (gref == NULL) {
 		rv = -ENOENT;
@@ -502,9 +528,13 @@ static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 		goto out_unlock;
 	}
 
-	vma->vm_private_data = gref;
+	vm_priv->gref = gref;
+	vm_priv->users = 1;
+	vm_priv->count = count;
+
+	vma->vm_private_data = vm_priv;
 
-	vma->vm_flags |= VM_RESERVED;
+	vma->vm_flags |= VM_RESERVED | VM_DONTEXPAND;
 
 	vma->vm_ops = &gntalloc_vmops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 18:43:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 18:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU0ju-0003vh-4r; Fri, 25 Nov 2011 18:43:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RU0jt-0003va-8z
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 18:43:09 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322246555!5614740!1
X-Originating-IP: [206.212.254.10]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3302 invoked from network); 25 Nov 2011 18:42:36 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 18:42:36 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAPIgYkj027229
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 25 Nov 2011 13:42:34 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAPIgXYY027227;
	Fri, 25 Nov 2011 13:42:33 -0500
Date: Fri, 25 Nov 2011 14:42:33 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111125184233.GB26841@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"konrad.wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:
> Hello again, I would like to come back to that thing...sorry that I did not have the time up to now.
> 
> ??
> We (now) speak about
> 
> ??
> *	Xen 4.1.2
> *	Dom0 is Jeremy's 2.6.32.46 64 bit
> *	DomU in question is now 3.1.2 64 bit
> *	Same thing if DomU is also 2.6.32.46
> *	DomU owns two PCI cards (DVB-C) that o DMA
> *	Machine has 8GB, Dom0 pinned at 512MB
> 
> ??
> As compared to 2.6.34 Kernel with backported patches, the load on the DomU is at least twice as high. It
> 
> will be "close to normal" if I reduce the memory used to 4GB.

That is in the dom0 or just in general on the machine?
> 
> ??
> As you can see from the attachment, you once had an idea. So should we try to find something...?

I think that was to instrument swiotlb to give an idea of how
often it is called and basically have a matrix of its load. And
from there figure out if the issue is that:

 1). The drivers allocoate/bounce/deallocate buffers on every interrupt
    (bad, driver should be using some form of dma pool and most of the
    ivtv do that)

 2). The buffers allocated to the drivers are above the 4GB and we end
    up bouncing it needlessly. That can happen if the dom0 has most of
    the precious memory under 4GB. However, that is usually not the case
    as the domain isusually allocated from the top of the memory. The
    fix for that was to set dom0_mem=max:XX. .. but with Dom0 kernels
    before 3.1, the parameter would be ignored, so you had to use
    'mem=XX' on the Linux command line as well.

 3). Where did you get the load values? Was it dom0? or domU?



> 
> ??
> Carsten.
> ??
> -----Urspr??ngliche Nachricht-----
> An:konrad.wilk <konrad.wilk@oracle.com>; 
> CC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com>; 
> Von:Carsten Schiers <carsten@schiers.de>
> Gesendet:Mi 29.06.2011 23:17
> Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memory upgrade?
> > Lets first do the c) experiment as that will likely explain your load average increase.
> ...
> > >c). If you want to see if the fault here lies in the bounce buffer 
> > being used more
> > >often in the DomU b/c you have 8GB of memory now and you end up using 
> > more pages
> > >past 4GB (in DomU), I can cook up a patch to figure this out. But an 
> > easier way is
> > >to just do (on the Xen hypervisor line): mem=4G and that will make 
> > think you only have
> > >4GB of physical RAM. ??If the load comes back to the normal "amount" 
> > then the likely
> > >culprit is that and we can think on how to fix this.
> 
> You are on the right track. Load was going down to "normal" 10% when reducing
> Xen to 4GB by the parameter. Load seems to be still a little, little bit lower
> with Xenified Kernel (8-9%), but this is drastically lower than the 20% we had
> before.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 18:43:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 18:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU0ju-0003vh-4r; Fri, 25 Nov 2011 18:43:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RU0jt-0003va-8z
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 18:43:09 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322246555!5614740!1
X-Originating-IP: [206.212.254.10]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3302 invoked from network); 25 Nov 2011 18:42:36 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Nov 2011 18:42:36 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAPIgYkj027229
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 25 Nov 2011 13:42:34 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAPIgXYY027227;
	Fri, 25 Nov 2011 13:42:33 -0500
Date: Fri, 25 Nov 2011 14:42:33 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111125184233.GB26841@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"konrad.wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:
> Hello again, I would like to come back to that thing...sorry that I did not have the time up to now.
> 
> ??
> We (now) speak about
> 
> ??
> *	Xen 4.1.2
> *	Dom0 is Jeremy's 2.6.32.46 64 bit
> *	DomU in question is now 3.1.2 64 bit
> *	Same thing if DomU is also 2.6.32.46
> *	DomU owns two PCI cards (DVB-C) that o DMA
> *	Machine has 8GB, Dom0 pinned at 512MB
> 
> ??
> As compared to 2.6.34 Kernel with backported patches, the load on the DomU is at least twice as high. It
> 
> will be "close to normal" if I reduce the memory used to 4GB.

That is in the dom0 or just in general on the machine?
> 
> ??
> As you can see from the attachment, you once had an idea. So should we try to find something...?

I think that was to instrument swiotlb to give an idea of how
often it is called and basically have a matrix of its load. And
from there figure out if the issue is that:

 1). The drivers allocoate/bounce/deallocate buffers on every interrupt
    (bad, driver should be using some form of dma pool and most of the
    ivtv do that)

 2). The buffers allocated to the drivers are above the 4GB and we end
    up bouncing it needlessly. That can happen if the dom0 has most of
    the precious memory under 4GB. However, that is usually not the case
    as the domain isusually allocated from the top of the memory. The
    fix for that was to set dom0_mem=max:XX. .. but with Dom0 kernels
    before 3.1, the parameter would be ignored, so you had to use
    'mem=XX' on the Linux command line as well.

 3). Where did you get the load values? Was it dom0? or domU?



> 
> ??
> Carsten.
> ??
> -----Urspr??ngliche Nachricht-----
> An:konrad.wilk <konrad.wilk@oracle.com>; 
> CC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com>; 
> Von:Carsten Schiers <carsten@schiers.de>
> Gesendet:Mi 29.06.2011 23:17
> Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memory upgrade?
> > Lets first do the c) experiment as that will likely explain your load average increase.
> ...
> > >c). If you want to see if the fault here lies in the bounce buffer 
> > being used more
> > >often in the DomU b/c you have 8GB of memory now and you end up using 
> > more pages
> > >past 4GB (in DomU), I can cook up a patch to figure this out. But an 
> > easier way is
> > >to just do (on the Xen hypervisor line): mem=4G and that will make 
> > think you only have
> > >4GB of physical RAM. ??If the load comes back to the normal "amount" 
> > then the likely
> > >culprit is that and we can think on how to fix this.
> 
> You are on the right track. Load was going down to "normal" 10% when reducing
> Xen to 4GB by the parameter. Load seems to be still a little, little bit lower
> with Xenified Kernel (8-9%), but this is drastically lower than the 20% we had
> before.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 18:44:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 18:44:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU0kk-0003yV-Js; Fri, 25 Nov 2011 18:44:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RU0kj-0003y3-7n
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 18:44:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322246607!5771109!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19795 invoked from network); 25 Nov 2011 18:43:28 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 18:43:28 -0000
Received: by ghbz2 with SMTP id z2so5633379ghb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 10:43:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=TUlxbcxTYD7MaPBXxH//mPodqQxYBlxUa4WGxWtdNhA=;
	b=KEY9wrNTOaZQI6mzLSDot3sqPFlfsX/obIF7tdXw5NCbzIYm07IPubjRMaP8qE8TfP
	+h178tIDSYWGXhpiUmRthbakh9dAeGOfEIN9AyG5tIhJOSZAyQ2q2NwU1fHphpauMbpj
	XIlThYxmXQJBdiSOECAofSp1DZ1UZ7RDbiYJc=
MIME-Version: 1.0
Received: by 10.68.51.135 with SMTP id k7mr29871305pbo.72.1322246606464; Fri,
	25 Nov 2011 10:43:26 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 25 Nov 2011 10:43:26 -0800 (PST)
In-Reply-To: <00ea49f77bdcef16251e.1322232583@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<00ea49f77bdcef16251e.1322232583@cosworth.uk.xensource.com>
Date: Fri, 25 Nov 2011 19:43:26 +0100
X-Google-Sender-Auth: 24iUtj2wrT83JjlOgBi7ejc7ffI
Message-ID: <CAPLaKK6usX0BPg-fm7yLVZVH4_roF320TJ0yQNGMb=EUKmSgVg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 15 v2] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8yNSBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPjoKPiAjIEhH
IGNoYW5nZXNldCBwYXRjaAo+ICMgVXNlciBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRy
aXguY29tPgo+ICMgRGF0ZSAxMzIyMjMxNjYxIDAKPiAjIE5vZGUgSUQgMDBlYTQ5Zjc3YmRjZWYx
NjI1MWUzNzczYzk5ZmMwMjM5NDUyNGI4Mwo+ICMgUGFyZW50IMKgZGRlYWM4YjIzN2U0ZjcxZDA1
YzgxN2ZhODQzMjQxNzg4NmU3ZTIwMgo+IGRvY3M6IGdlbmVyYXRlIGFuIGluZGV4IGZvciB0aGUg
aHRtbCBvdXRwdXQKPgo+IG5iOiBJJ20gbm90IGEgUGVybCB3aXphcmQuLi4KPgo+IFNpZ25lZC1v
ZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4KPiBkaWZmIC1y
IGRkZWFjOGIyMzdlNCAtciAwMGVhNDlmNzdiZGMgZG9jcy9JTkRFWAo+IC0tLSAvZGV2L251bGwg
wqAgVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCj4gKysrIGIvZG9jcy9JTkRFWCDCoCDC
oCDCoCDCoEZyaSBOb3YgMjUgMTQ6MzQ6MjEgMjAxMSArMDAwMAo+IEBAIC0wLDAgKzEsNSBAQAo+
ICttaXNjL2h2bS1lbXVsYXRlZC11bnBsdWcgwqAgwqAgwqAgWGVuIEhWTSBlbXVsYXRlZCBkZXZp
Y2UgdW5wbHVnIHByb3RvY29sCj4gKwo+ICsjIFRoZXNlIGFyZSBub3QgYWxsIHRoYXQgdXNlZnVs
IGFueW1vcmUsIGhpZGUgdGhlbSBmcm9tIHRoZSBpbmRleAo+ICtpbnRlcmZhY2UvaW5kZXggwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBOTy1JTkRFWAo+ICt1c2VyL2luZGV4IMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE5PLUlOREVYCj4gZGlmZiAtciBkZGVhYzhiMjM3
ZTQgLXIgMDBlYTQ5Zjc3YmRjIGRvY3MvTWFrZWZpbGUKPiAtLS0gYS9kb2NzL01ha2VmaWxlIMKg
IMKgIEZyaSBOb3YgMjUgMTE6NTM6MDYgMjAxMSArMDAwMAo+ICsrKyBiL2RvY3MvTWFrZWZpbGUg
wqAgwqAgRnJpIE5vdiAyNSAxNDozNDoyMSAyMDExICswMDAwCj4gQEAgLTQ1LDcgKzQ1LDcgQEAg
cHM6ICQoRE9DX1BTKQo+IMKgcGRmOiAkKERPQ19QREYpCj4KPiDCoC5QSE9OWTogaHRtbAo+IC1o
dG1sOiAkKERPQ19IVE1MKQo+ICtodG1sOiAkKERPQ19IVE1MKSBodG1sL2luZGV4Lmh0bWwKPgo+
IMKgLlBIT05ZOiB0eHQKPiDCoHR4dDogJChET0NfVFhUKQo+IEBAIC0xMjgsNiArMTI4LDkgQEAg
aHRtbC8lL2luZGV4Lmh0bWw6IHNyYy8lLnRleAo+IMKgIMKgIMKgIMKgJDwgMT4vZGV2L251bGwg
Mj4vZGV2L251bGwgOyBlbHNlIFwKPiDCoCDCoCDCoCDCoGVjaG8gImxhdGV4Mmh0bWwgbm90IGlu
c3RhbGxlZDsgc2tpcHBpbmcgJCouIjsgZmkKPgo+ICtodG1sL2luZGV4Lmh0bWw6ICQoRE9DX0hU
TUwpIC4vZ2VuLWh0bWwtaW5kZXggSU5ERVgKPiArIMKgIMKgIMKgIC4vZ2VuLWh0bWwtaW5kZXgg
LWkgSU5ERVggaHRtbCAkKERPQ19IVE1MKQo+ICsKPiDCoGh0bWwvJS5odG1sOiAlLm1hcmtkb3du
Cj4gwqAgwqAgwqAgwqBAJChJTlNUQUxMX0RJUikgJChARCkKPiDCoCDCoCDCoCDCoEBzZXQgLWUg
OyBpZiB3aGljaCAkKE1BUktET1dOKSAxPi9kZXYvbnVsbCAyPi9kZXYvbnVsbDsgdGhlbiBcCj4g
ZGlmZiAtciBkZGVhYzhiMjM3ZTQgLXIgMDBlYTQ5Zjc3YmRjIGRvY3MvZ2VuLWh0bWwtaW5kZXgK
PiAtLS0gL2Rldi9udWxsIMKgIFRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAo+ICsrKyBi
L2RvY3MvZ2VuLWh0bWwtaW5kZXggwqAgwqAgwqAgRnJpIE5vdiAyNSAxNDozNDoyMSAyMDExICsw
MDAwCj4gQEAgLTAsMCArMSwxMzYgQEAKPiArIyEvdXNyL2Jpbi9wZXJsIC13CgpXaGF0IGFib3V0
IHVzaW5nIHRoZSBmb2xsb3dpbmc6CgojIS91c3IvYmluL2VudiBwZXJsCnVzZSB3YXJuaW5nczsK
CkZyb20gd2hhdCBJJ3ZlIHJlYWQgKGFuZCB0cmllZCksICItdyIgaXMgZXF1aXZhbGVudCB0byAi
JF5XID0gMSIgYW5kCiJ1c2Ugd2FybmluZ3MiLCBJIHRoaW5rICJ1c2Ugd2FybmluZ3MiIGlzIHRo
ZSBjbGVhcmVyIHdheSB0byBkbyB0aGlzLgpUaGUgb25seSBwcm9ibGVtIGlzIHRoYXQgInVzZSB3
YXJuaW5ncyIgcmVxdWlyZXMgcGVybCA1LjYsIGJ1dCBmcm9tCndoYXQgSSBzZWUgdGhpcyBpcyBx
dWl0ZSBhbiBvbGQgdmVyc2lvbiBvZiBwZXJsIChmcm9tIDIwMDIgbW9yZSBvcgpsZXNzKSBzbyBl
dmVyeSBtb2Rlcm4gTGludXggZGlzdHJvIGNvbWVzIHdpdGggNS4xMCBhdCBsZWFzdC4KCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNv
dXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Nov 25 18:44:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 18:44:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU0kk-0003yV-Js; Fri, 25 Nov 2011 18:44:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RU0kj-0003y3-7n
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 18:44:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322246607!5771109!1
X-Originating-IP: [209.85.160.171]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19795 invoked from network); 25 Nov 2011 18:43:28 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 18:43:28 -0000
Received: by ghbz2 with SMTP id z2so5633379ghb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 10:43:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=TUlxbcxTYD7MaPBXxH//mPodqQxYBlxUa4WGxWtdNhA=;
	b=KEY9wrNTOaZQI6mzLSDot3sqPFlfsX/obIF7tdXw5NCbzIYm07IPubjRMaP8qE8TfP
	+h178tIDSYWGXhpiUmRthbakh9dAeGOfEIN9AyG5tIhJOSZAyQ2q2NwU1fHphpauMbpj
	XIlThYxmXQJBdiSOECAofSp1DZ1UZ7RDbiYJc=
MIME-Version: 1.0
Received: by 10.68.51.135 with SMTP id k7mr29871305pbo.72.1322246606464; Fri,
	25 Nov 2011 10:43:26 -0800 (PST)
Received: by 10.142.212.12 with HTTP; Fri, 25 Nov 2011 10:43:26 -0800 (PST)
In-Reply-To: <00ea49f77bdcef16251e.1322232583@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<00ea49f77bdcef16251e.1322232583@cosworth.uk.xensource.com>
Date: Fri, 25 Nov 2011 19:43:26 +0100
X-Google-Sender-Auth: 24iUtj2wrT83JjlOgBi7ejc7ffI
Message-ID: <CAPLaKK6usX0BPg-fm7yLVZVH4_roF320TJ0yQNGMb=EUKmSgVg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 15 v2] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMS8xMS8yNSBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPjoKPiAjIEhH
IGNoYW5nZXNldCBwYXRjaAo+ICMgVXNlciBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRy
aXguY29tPgo+ICMgRGF0ZSAxMzIyMjMxNjYxIDAKPiAjIE5vZGUgSUQgMDBlYTQ5Zjc3YmRjZWYx
NjI1MWUzNzczYzk5ZmMwMjM5NDUyNGI4Mwo+ICMgUGFyZW50IMKgZGRlYWM4YjIzN2U0ZjcxZDA1
YzgxN2ZhODQzMjQxNzg4NmU3ZTIwMgo+IGRvY3M6IGdlbmVyYXRlIGFuIGluZGV4IGZvciB0aGUg
aHRtbCBvdXRwdXQKPgo+IG5iOiBJJ20gbm90IGEgUGVybCB3aXphcmQuLi4KPgo+IFNpZ25lZC1v
ZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+Cj4KPiBkaWZmIC1y
IGRkZWFjOGIyMzdlNCAtciAwMGVhNDlmNzdiZGMgZG9jcy9JTkRFWAo+IC0tLSAvZGV2L251bGwg
wqAgVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCj4gKysrIGIvZG9jcy9JTkRFWCDCoCDC
oCDCoCDCoEZyaSBOb3YgMjUgMTQ6MzQ6MjEgMjAxMSArMDAwMAo+IEBAIC0wLDAgKzEsNSBAQAo+
ICttaXNjL2h2bS1lbXVsYXRlZC11bnBsdWcgwqAgwqAgwqAgWGVuIEhWTSBlbXVsYXRlZCBkZXZp
Y2UgdW5wbHVnIHByb3RvY29sCj4gKwo+ICsjIFRoZXNlIGFyZSBub3QgYWxsIHRoYXQgdXNlZnVs
IGFueW1vcmUsIGhpZGUgdGhlbSBmcm9tIHRoZSBpbmRleAo+ICtpbnRlcmZhY2UvaW5kZXggwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBOTy1JTkRFWAo+ICt1c2VyL2luZGV4IMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE5PLUlOREVYCj4gZGlmZiAtciBkZGVhYzhiMjM3
ZTQgLXIgMDBlYTQ5Zjc3YmRjIGRvY3MvTWFrZWZpbGUKPiAtLS0gYS9kb2NzL01ha2VmaWxlIMKg
IMKgIEZyaSBOb3YgMjUgMTE6NTM6MDYgMjAxMSArMDAwMAo+ICsrKyBiL2RvY3MvTWFrZWZpbGUg
wqAgwqAgRnJpIE5vdiAyNSAxNDozNDoyMSAyMDExICswMDAwCj4gQEAgLTQ1LDcgKzQ1LDcgQEAg
cHM6ICQoRE9DX1BTKQo+IMKgcGRmOiAkKERPQ19QREYpCj4KPiDCoC5QSE9OWTogaHRtbAo+IC1o
dG1sOiAkKERPQ19IVE1MKQo+ICtodG1sOiAkKERPQ19IVE1MKSBodG1sL2luZGV4Lmh0bWwKPgo+
IMKgLlBIT05ZOiB0eHQKPiDCoHR4dDogJChET0NfVFhUKQo+IEBAIC0xMjgsNiArMTI4LDkgQEAg
aHRtbC8lL2luZGV4Lmh0bWw6IHNyYy8lLnRleAo+IMKgIMKgIMKgIMKgJDwgMT4vZGV2L251bGwg
Mj4vZGV2L251bGwgOyBlbHNlIFwKPiDCoCDCoCDCoCDCoGVjaG8gImxhdGV4Mmh0bWwgbm90IGlu
c3RhbGxlZDsgc2tpcHBpbmcgJCouIjsgZmkKPgo+ICtodG1sL2luZGV4Lmh0bWw6ICQoRE9DX0hU
TUwpIC4vZ2VuLWh0bWwtaW5kZXggSU5ERVgKPiArIMKgIMKgIMKgIC4vZ2VuLWh0bWwtaW5kZXgg
LWkgSU5ERVggaHRtbCAkKERPQ19IVE1MKQo+ICsKPiDCoGh0bWwvJS5odG1sOiAlLm1hcmtkb3du
Cj4gwqAgwqAgwqAgwqBAJChJTlNUQUxMX0RJUikgJChARCkKPiDCoCDCoCDCoCDCoEBzZXQgLWUg
OyBpZiB3aGljaCAkKE1BUktET1dOKSAxPi9kZXYvbnVsbCAyPi9kZXYvbnVsbDsgdGhlbiBcCj4g
ZGlmZiAtciBkZGVhYzhiMjM3ZTQgLXIgMDBlYTQ5Zjc3YmRjIGRvY3MvZ2VuLWh0bWwtaW5kZXgK
PiAtLS0gL2Rldi9udWxsIMKgIFRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAo+ICsrKyBi
L2RvY3MvZ2VuLWh0bWwtaW5kZXggwqAgwqAgwqAgRnJpIE5vdiAyNSAxNDozNDoyMSAyMDExICsw
MDAwCj4gQEAgLTAsMCArMSwxMzYgQEAKPiArIyEvdXNyL2Jpbi9wZXJsIC13CgpXaGF0IGFib3V0
IHVzaW5nIHRoZSBmb2xsb3dpbmc6CgojIS91c3IvYmluL2VudiBwZXJsCnVzZSB3YXJuaW5nczsK
CkZyb20gd2hhdCBJJ3ZlIHJlYWQgKGFuZCB0cmllZCksICItdyIgaXMgZXF1aXZhbGVudCB0byAi
JF5XID0gMSIgYW5kCiJ1c2Ugd2FybmluZ3MiLCBJIHRoaW5rICJ1c2Ugd2FybmluZ3MiIGlzIHRo
ZSBjbGVhcmVyIHdheSB0byBkbyB0aGlzLgpUaGUgb25seSBwcm9ibGVtIGlzIHRoYXQgInVzZSB3
YXJuaW5ncyIgcmVxdWlyZXMgcGVybCA1LjYsIGJ1dCBmcm9tCndoYXQgSSBzZWUgdGhpcyBpcyBx
dWl0ZSBhbiBvbGQgdmVyc2lvbiBvZiBwZXJsIChmcm9tIDIwMDIgbW9yZSBvcgpsZXNzKSBzbyBl
dmVyeSBtb2Rlcm4gTGludXggZGlzdHJvIGNvbWVzIHdpdGggNS4xMCBhdCBsZWFzdC4KCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNv
dXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Nov 25 19:36:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 19:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU1Yh-0004zr-Qb; Fri, 25 Nov 2011 19:35:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RU1Yg-0004zm-Fq
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 19:35:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322249705!3087956!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17952 invoked from network); 25 Nov 2011 19:35:05 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 19:35:05 -0000
Received: by bkbzt12 with SMTP id zt12so6274567bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 11:35:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Evs05Q081g1IqJ14xXYVnip3yGELyAjHWosfqkkeFAo=;
	b=BVo5wJ8s6mpOrVqW/3YpICdZZj1inmLTQxAT2u4Au4yeHJFogGvizkfMiw0GLZkLff
	4G6aHkwuGmYlQDNKIvDtL5/TMyxB/iKGx/RVfzEmcnY76kFMPiBJMUQlvQ/9neaOYgAl
	qHN/Wju6PWwkjxk+DM+tS/3MI+eRcvha0dKkM=
Received: by 10.204.152.83 with SMTP id f19mr35383412bkw.90.1322249705172;
	Fri, 25 Nov 2011 11:35:05 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id hw14sm6780841bkc.16.2011.11.25.11.35.03
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 11:35:04 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 19:35:01 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF59E65.25AF5%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyrqVKRtjJmg2n7k0+EwQNmxnkanQ==
In-Reply-To: <20111125182645.GA27992@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 18:26, "Olaf Hering" <olaf@aepfle.de> wrote:

> 
> One more thing:
> 
> Is the BUG_ON in destroy_waitqueue_vcpu really required? If the vcpu
> happens to be in a queue by the time xl destroy is called the hypervisor
> will crash.

We could fix this by having waitqueues that contain a vcpu hold a reference
to that vcpu's domain.

> Perhaps there should be some sort of domain destructor for each
> waitqueue?

Not sure what you mean.

 -- Keir

> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 19:36:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 19:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU1Yh-0004zr-Qb; Fri, 25 Nov 2011 19:35:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RU1Yg-0004zm-Fq
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 19:35:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322249705!3087956!1
X-Originating-IP: [209.85.214.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17952 invoked from network); 25 Nov 2011 19:35:05 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 19:35:05 -0000
Received: by bkbzt12 with SMTP id zt12so6274567bkb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 11:35:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Evs05Q081g1IqJ14xXYVnip3yGELyAjHWosfqkkeFAo=;
	b=BVo5wJ8s6mpOrVqW/3YpICdZZj1inmLTQxAT2u4Au4yeHJFogGvizkfMiw0GLZkLff
	4G6aHkwuGmYlQDNKIvDtL5/TMyxB/iKGx/RVfzEmcnY76kFMPiBJMUQlvQ/9neaOYgAl
	qHN/Wju6PWwkjxk+DM+tS/3MI+eRcvha0dKkM=
Received: by 10.204.152.83 with SMTP id f19mr35383412bkw.90.1322249705172;
	Fri, 25 Nov 2011 11:35:05 -0800 (PST)
Received: from [192.168.1.71]
	(host86-129-244-131.range86-129.btcentralplus.com. [86.129.244.131])
	by mx.google.com with ESMTPS id hw14sm6780841bkc.16.2011.11.25.11.35.03
	(version=SSLv3 cipher=OTHER); Fri, 25 Nov 2011 11:35:04 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 25 Nov 2011 19:35:01 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CAF59E65.25AF5%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Need help with fixing the Xen waitqueue feature
Thread-Index: AcyrqVKRtjJmg2n7k0+EwQNmxnkanQ==
In-Reply-To: <20111125182645.GA27992@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Need help with fixing the Xen waitqueue feature
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11/2011 18:26, "Olaf Hering" <olaf@aepfle.de> wrote:

> 
> One more thing:
> 
> Is the BUG_ON in destroy_waitqueue_vcpu really required? If the vcpu
> happens to be in a queue by the time xl destroy is called the hypervisor
> will crash.

We could fix this by having waitqueues that contain a vcpu hold a reference
to that vcpu's domain.

> Perhaps there should be some sort of domain destructor for each
> waitqueue?

Not sure what you mean.

 -- Keir

> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 19:58:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 19:58:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU1uS-0005EI-Ra; Fri, 25 Nov 2011 19:58:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1RU1uR-0005ED-4f
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 19:58:07 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322251054!5041119!1
X-Originating-IP: [82.198.197.8]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13918 invoked from network); 25 Nov 2011 19:57:34 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-5.tower-216.messagelabs.com with SMTP;
	25 Nov 2011 19:57:34 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 1DD456EA18C
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 20:57:31 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 10509164B103
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 20:57:31 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 1tdOENSfL59r for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 20:57:30 +0100 (CET)
Received: from stave.knut.univention.de (stave.knut.univention.de
	[192.168.0.191])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 862396EA18C
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 20:57:30 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: xen-devel@lists.xensource.com
Date: Fri, 25 Nov 2011 20:57:26 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <201111251721.12753.hahn@univention.de>
In-Reply-To: <201111251721.12753.hahn@univention.de>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201111252057.31649.hahn@univention.de>
Subject: Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl list"
	and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6505664973786568702=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6505664973786568702==
Content-Type: multipart/signed;
  boundary="nextPart2568946.41NRMazOLD";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2568946.41NRMazOLD
Content-Type: multipart/mixed;
  boundary="Boundary-01=_nM/zOt+gNGR34E7"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--Boundary-01=_nM/zOt+gNGR34E7
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

On Friday 25 November 2011 17:21:08 Philipp Hahn wrote:
> BlktapController splits the output into lines using \n, then each line at
> each space, and finally each of these 'words' at the '=3D', which fails f=
or
> the filename.

As a quick work-around, the attached patch fixes the problem for me. That i=
s,=20
until tap-ctl changes it's output format.
A more permanent solution would be to add proper quoting / escaping to tap-=
ctl=20
and un-quoting / de-escaping  to BlktapController.py

Signed-off-by: Philipp Hahn <hahn@univention.de>

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--Boundary-01=_nM/zOt+gNGR34E7
Content-Type: text/x-diff;
  charset="utf-8";
  name="0004-tap-ctl.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="0004-tap-ctl.patch"

Bug #18357: Fix tap-ctl parsing.

Shutting down a domU with xen-4.1.2 doesn't terminate the corresponding blk=
tap2
process, since one (other) VM uses a image file, which contains spaces in i=
ts
file name.  /var/log/xen/xend-debug.log has the following information:

Unhandled exception in thread started by
Traceback (most recent call last):
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 199, in finishDeviceCleanup
=C2=A0 =C2=A0 TapdiskController.destroy(path)
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 289, in destroy
=C2=A0 =C2=A0 tapdisk =3D TapdiskController.fromDevice(device)
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 278, in fromDevice
=C2=A0 =C2=A0 TapdiskController.list())
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 256, in list
=C2=A0 =C2=A0 key, value =3D pair.split('=3D')
ValueError: need more than 1 value to unpack

BlktapController calls "tap-ctl list", which outputs one line for each proc=
ess.
Each line contains key=3Dvalue pairs without any quoting.

# tap-ctl list | grep 'args=3D.*:.* '
pid=3D10145 minor=3D18 state=3D0 args=3Daio:/var/lib/libvirt/images/Xen Win=
dows drivers (gplpv 308).iso

(passing the output of tap-ctl through a pipe is important, since it switch=
es
to a different list-format when STDOUT is a tty.)

BlktapController splits the output into lines using \n, then each line at e=
ach
space, and finally each of these 'words' at the '=3D', which fails for the
filename.


Limit the number of splits as a fast work-around.
=2D-- a/tools/python/xen/xend/server/BlktapController.py
+++ b/tools/python/xen/xend/server/BlktapController.py
@@ -249,11 +249,12 @@ class TapdiskController(object):
         _list =3D TapdiskController.exc('list')
         if not _list: return []
=20
=2D        for line in _list.split('\n'):
+        for line in _list.splitlines():
             tapdisk =3D TapdiskController.Tapdisk()
=20
=2D            for pair in line.split():
=2D                key, value =3D pair.split('=3D')
+            # Since 'tap-ctl list' does not escape blanks in the path, har=
d-code the current format using 4 pairs to prevent splitting the path
+            for pair in line.split(None, 4):
+                key, value =3D pair.split('=3D', 1)
                 if key =3D=3D 'pid':
                     tapdisk.pid =3D value
                 elif key =3D=3D 'minor':
@@ -264,7 +265,7 @@ class TapdiskController(object):
                 elif key =3D=3D 'state':
                     tapdisk.state =3D value
                 elif key =3D=3D 'args' and value.find(':') !=3D -1:
=2D                    tapdisk.dtype, tapdisk.image =3D value.split(':')
+                    tapdisk.dtype, tapdisk.image =3D value.split(':', 1)
=20
             tapdisks.append(tapdisk)
=20

--Boundary-01=_nM/zOt+gNGR34E7--

--nextPart2568946.41NRMazOLD
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAk7P8ycACgkQYPlgoZpUDjmErgCdGA+spWED5y5PBJtWpLG6+k4T
KwEAoI+WnUZwKIhFEN8fc4mra5QG8VRC
=A+74
-----END PGP SIGNATURE-----

--nextPart2568946.41NRMazOLD--


--===============6505664973786568702==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6505664973786568702==--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 19:58:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 19:58:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU1uS-0005EI-Ra; Fri, 25 Nov 2011 19:58:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1RU1uR-0005ED-4f
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 19:58:07 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322251054!5041119!1
X-Originating-IP: [82.198.197.8]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13918 invoked from network); 25 Nov 2011 19:57:34 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-5.tower-216.messagelabs.com with SMTP;
	25 Nov 2011 19:57:34 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 1DD456EA18C
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 20:57:31 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 10509164B103
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 20:57:31 +0100 (CET)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 1tdOENSfL59r for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 20:57:30 +0100 (CET)
Received: from stave.knut.univention.de (stave.knut.univention.de
	[192.168.0.191])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 862396EA18C
	for <xen-devel@lists.xensource.com>;
	Fri, 25 Nov 2011 20:57:30 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: xen-devel@lists.xensource.com
Date: Fri, 25 Nov 2011 20:57:26 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <201111251721.12753.hahn@univention.de>
In-Reply-To: <201111251721.12753.hahn@univention.de>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201111252057.31649.hahn@univention.de>
Subject: Re: [Xen-devel] [BUG] insufficient quoting between "tap-ctl list"
	and xend/server/BlktapController.py
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6505664973786568702=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6505664973786568702==
Content-Type: multipart/signed;
  boundary="nextPart2568946.41NRMazOLD";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2568946.41NRMazOLD
Content-Type: multipart/mixed;
  boundary="Boundary-01=_nM/zOt+gNGR34E7"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--Boundary-01=_nM/zOt+gNGR34E7
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

On Friday 25 November 2011 17:21:08 Philipp Hahn wrote:
> BlktapController splits the output into lines using \n, then each line at
> each space, and finally each of these 'words' at the '=3D', which fails f=
or
> the filename.

As a quick work-around, the attached patch fixes the problem for me. That i=
s,=20
until tap-ctl changes it's output format.
A more permanent solution would be to add proper quoting / escaping to tap-=
ctl=20
and un-quoting / de-escaping  to BlktapController.py

Signed-off-by: Philipp Hahn <hahn@univention.de>

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--Boundary-01=_nM/zOt+gNGR34E7
Content-Type: text/x-diff;
  charset="utf-8";
  name="0004-tap-ctl.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="0004-tap-ctl.patch"

Bug #18357: Fix tap-ctl parsing.

Shutting down a domU with xen-4.1.2 doesn't terminate the corresponding blk=
tap2
process, since one (other) VM uses a image file, which contains spaces in i=
ts
file name.  /var/log/xen/xend-debug.log has the following information:

Unhandled exception in thread started by
Traceback (most recent call last):
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 199, in finishDeviceCleanup
=C2=A0 =C2=A0 TapdiskController.destroy(path)
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 289, in destroy
=C2=A0 =C2=A0 tapdisk =3D TapdiskController.fromDevice(device)
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 278, in fromDevice
=C2=A0 =C2=A0 TapdiskController.list())
=C2=A0 File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapControl=
ler.py", line 256, in list
=C2=A0 =C2=A0 key, value =3D pair.split('=3D')
ValueError: need more than 1 value to unpack

BlktapController calls "tap-ctl list", which outputs one line for each proc=
ess.
Each line contains key=3Dvalue pairs without any quoting.

# tap-ctl list | grep 'args=3D.*:.* '
pid=3D10145 minor=3D18 state=3D0 args=3Daio:/var/lib/libvirt/images/Xen Win=
dows drivers (gplpv 308).iso

(passing the output of tap-ctl through a pipe is important, since it switch=
es
to a different list-format when STDOUT is a tty.)

BlktapController splits the output into lines using \n, then each line at e=
ach
space, and finally each of these 'words' at the '=3D', which fails for the
filename.


Limit the number of splits as a fast work-around.
=2D-- a/tools/python/xen/xend/server/BlktapController.py
+++ b/tools/python/xen/xend/server/BlktapController.py
@@ -249,11 +249,12 @@ class TapdiskController(object):
         _list =3D TapdiskController.exc('list')
         if not _list: return []
=20
=2D        for line in _list.split('\n'):
+        for line in _list.splitlines():
             tapdisk =3D TapdiskController.Tapdisk()
=20
=2D            for pair in line.split():
=2D                key, value =3D pair.split('=3D')
+            # Since 'tap-ctl list' does not escape blanks in the path, har=
d-code the current format using 4 pairs to prevent splitting the path
+            for pair in line.split(None, 4):
+                key, value =3D pair.split('=3D', 1)
                 if key =3D=3D 'pid':
                     tapdisk.pid =3D value
                 elif key =3D=3D 'minor':
@@ -264,7 +265,7 @@ class TapdiskController(object):
                 elif key =3D=3D 'state':
                     tapdisk.state =3D value
                 elif key =3D=3D 'args' and value.find(':') !=3D -1:
=2D                    tapdisk.dtype, tapdisk.image =3D value.split(':')
+                    tapdisk.dtype, tapdisk.image =3D value.split(':', 1)
=20
             tapdisks.append(tapdisk)
=20

--Boundary-01=_nM/zOt+gNGR34E7--

--nextPart2568946.41NRMazOLD
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAk7P8ycACgkQYPlgoZpUDjmErgCdGA+spWED5y5PBJtWpLG6+k4T
KwEAoI+WnUZwKIhFEN8fc4mra5QG8VRC
=A+74
-----END PGP SIGNATURE-----

--nextPart2568946.41NRMazOLD--


--===============6505664973786568702==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6505664973786568702==--


From xen-devel-bounces@lists.xensource.com Fri Nov 25 20:01:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 20:01:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU1wq-0005Nb-EF; Fri, 25 Nov 2011 20:00:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RU1wp-0005Md-8C
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 20:00:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322251174!54615423!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10402 invoked from network); 25 Nov 2011 19:59:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 19:59:34 -0000
X-IronPort-AV: E=Sophos;i="4.69,573,1315180800"; 
   d="scan'208";a="9137144"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 20:00:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 20:00:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RU1wM-0007aK-FR;
	Fri, 25 Nov 2011 20:00:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RU1wM-0007PV-Ad;
	Fri, 25 Nov 2011 20:00:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10051-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 20:00:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10051: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10051 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10051/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956
 test-amd64-amd64-win         14 guest-start.2              fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9955
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  373bd877cac3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 874 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 20:01:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 20:01:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU1wq-0005Nb-EF; Fri, 25 Nov 2011 20:00:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RU1wp-0005Md-8C
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 20:00:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322251174!54615423!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10402 invoked from network); 25 Nov 2011 19:59:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Nov 2011 19:59:34 -0000
X-IronPort-AV: E=Sophos;i="4.69,573,1315180800"; 
   d="scan'208";a="9137144"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Nov 2011 20:00:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 25 Nov 2011 20:00:06 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RU1wM-0007aK-FR;
	Fri, 25 Nov 2011 20:00:06 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RU1wM-0007PV-Ad;
	Fri, 25 Nov 2011 20:00:06 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10051-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 25 Nov 2011 20:00:06 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10051: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10051 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10051/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956
 test-amd64-amd64-win         14 guest-start.2              fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail    like 9955
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  373bd877cac3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 874 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 22:13:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 22:13:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU40Y-000798-AT; Fri, 25 Nov 2011 22:12:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RU40X-000793-Bf
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 22:12:33 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322259120!5820835!1
X-Originating-IP: [194.117.254.36]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14617 invoked from network); 25 Nov 2011 22:12:00 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2011 22:12:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=iOYgFmMFF9yMUABjZ96mZvLE9g3Whq5enqsY6rQwBJo=; b=bM7HWJY
	Tn0WffWDlG/eSggYyjz3AAIcziENpjm2Wq0B8AxOkU6OQt58GRVPoNJFbeeLchwD
	VxcHsqzTwVM9OE/4FzpY4jDzNeGlW8aeEvlKI5StgHbgR+nusJ2FRCIdfjLqtg2O
	JN/il9hX0Ibsjuk+3zTCYpj+AYrrR8D82wiY=
Received: (qmail 27046 invoked from network); 25 Nov 2011 23:11:58 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.129.249)
	by mail.zeus06.de with ESMTPA; 25 Nov 2011 23:11:58 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 7463F2C514;
	Fri, 25 Nov 2011 23:11:58 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id U1w4mfAncEXe; Fri, 25 Nov 2011 23:11:55 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id A8BAF2C513;
	Fri, 25 Nov 2011 23:11:55 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Fri, 25 Nov 2011 23:11:55 +0100
Mime-Version: 1.0
In-Reply-To: <20111125184233.GB26841@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: AcyrvzGm8oAK58w3Q0Cg1D+L8HnkTA==
Message-Id: <zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
Cc: =?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I got the values in DomU. I will have

  - aprox. 5% load in DomU with 2.6.34 Xenified Kernel
  - aprox. 15% load in DomU with 2.6.32.46 Jeremy or 3.1.2 Kernel with one =
card attached
  - aprox. 30% load in DomU with 2.6.32.46 Jeremy or 3.1.2 Kernel with two =
cards attached

I looked through my old mails from you and you explained already the necess=
ity of double
bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: w=
hy does the
Xenified kernel not have this kind of issue?

The driver in question is nearly identical between the two kernel versions.=
 It is in
Drivers/media/dvb/ttpci by the way and when I understood the code right, th=
e allo in =

question is:

        /* allocate and init buffers */
        av7110->debi_virt =3D pci_alloc_consistent(pdev, 8192, &av7110->deb=
i_bus);
        if (!av7110->debi_virt)
                goto err_saa71466_vfree_4;

isn't it? I think the cards are constantly transferring the stream received=
 through DMA. =


I have set dom0_mem=3D512M by the way, shall I change that in some way?

I can try out some things, if you want me to. But I have no idea what to do=
 and where to
start, so I rely on your help...

Carsten.

-----Urspr=FCngliche Nachricht-----
Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.=
xensource.com] Im Auftrag von Konrad Rzeszutek Wilk
Gesendet: Freitag, 25. November 2011 19:43
An: Carsten Schiers
Cc: xen-devel; konrad.wilk
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:
> Hello again, I would like to come back to that thing...sorry that I did n=
ot have the time up to now.
> =

> ??
> We (now) speak about
> =

> ??
> *	Xen 4.1.2
> *	Dom0 is Jeremy's 2.6.32.46 64 bit
> *	DomU in question is now 3.1.2 64 bit
> *	Same thing if DomU is also 2.6.32.46
> *	DomU owns two PCI cards (DVB-C) that o DMA
> *	Machine has 8GB, Dom0 pinned at 512MB
> =

> ??
> As compared to 2.6.34 Kernel with backported patches, the load on the Dom=
U is at least twice as high. It
> =

> will be "close to normal" if I reduce the memory used to 4GB.

That is in the dom0 or just in general on the machine?
> =

> ??
> As you can see from the attachment, you once had an idea. So should we tr=
y to find something...?

I think that was to instrument swiotlb to give an idea of how
often it is called and basically have a matrix of its load. And
from there figure out if the issue is that:

 1). The drivers allocoate/bounce/deallocate buffers on every interrupt
    (bad, driver should be using some form of dma pool and most of the
    ivtv do that)

 2). The buffers allocated to the drivers are above the 4GB and we end
    up bouncing it needlessly. That can happen if the dom0 has most of
    the precious memory under 4GB. However, that is usually not the case
    as the domain isusually allocated from the top of the memory. The
    fix for that was to set dom0_mem=3Dmax:XX. .. but with Dom0 kernels
    before 3.1, the parameter would be ignored, so you had to use
    'mem=3DXX' on the Linux command line as well.

 3). Where did you get the load values? Was it dom0? or domU?



> =

> ??
> Carsten.
> ??
> -----Urspr??ngliche Nachricht-----
> An:konrad.wilk <konrad.wilk@oracle.com>; =

> CC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com=
>; =

> Von:Carsten Schiers <carsten@schiers.de>
> Gesendet:Mi 29.06.2011 23:17
> Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memor=
y upgrade?
> > Lets first do the c) experiment as that will likely explain your load a=
verage increase.
> ...
> > >c). If you want to see if the fault here lies in the bounce buffer =

> > being used more
> > >often in the DomU b/c you have 8GB of memory now and you end up using =

> > more pages
> > >past 4GB (in DomU), I can cook up a patch to figure this out. But an =

> > easier way is
> > >to just do (on the Xen hypervisor line): mem=3D4G and that will make =

> > think you only have
> > >4GB of physical RAM. ??If the load comes back to the normal "amount" =

> > then the likely
> > >culprit is that and we can think on how to fix this.
> =

> You are on the right track. Load was going down to "normal" 10% when redu=
cing
> Xen to 4GB by the parameter. Load seems to be still a little, little bit =
lower
> with Xenified Kernel (8-9%), but this is drastically lower than the 20% w=
e had
> before.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Nov 25 22:13:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 25 Nov 2011 22:13:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU40Y-000798-AT; Fri, 25 Nov 2011 22:12:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RU40X-000793-Bf
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 22:12:33 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322259120!5820835!1
X-Originating-IP: [194.117.254.36]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14617 invoked from network); 25 Nov 2011 22:12:00 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Nov 2011 22:12:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=iOYgFmMFF9yMUABjZ96mZvLE9g3Whq5enqsY6rQwBJo=; b=bM7HWJY
	Tn0WffWDlG/eSggYyjz3AAIcziENpjm2Wq0B8AxOkU6OQt58GRVPoNJFbeeLchwD
	VxcHsqzTwVM9OE/4FzpY4jDzNeGlW8aeEvlKI5StgHbgR+nusJ2FRCIdfjLqtg2O
	JN/il9hX0Ibsjuk+3zTCYpj+AYrrR8D82wiY=
Received: (qmail 27046 invoked from network); 25 Nov 2011 23:11:58 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.129.249)
	by mail.zeus06.de with ESMTPA; 25 Nov 2011 23:11:58 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 7463F2C514;
	Fri, 25 Nov 2011 23:11:58 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id U1w4mfAncEXe; Fri, 25 Nov 2011 23:11:55 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id A8BAF2C513;
	Fri, 25 Nov 2011 23:11:55 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Fri, 25 Nov 2011 23:11:55 +0100
Mime-Version: 1.0
In-Reply-To: <20111125184233.GB26841@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: AcyrvzGm8oAK58w3Q0Cg1D+L8HnkTA==
Message-Id: <zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
Cc: =?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I got the values in DomU. I will have

  - aprox. 5% load in DomU with 2.6.34 Xenified Kernel
  - aprox. 15% load in DomU with 2.6.32.46 Jeremy or 3.1.2 Kernel with one =
card attached
  - aprox. 30% load in DomU with 2.6.32.46 Jeremy or 3.1.2 Kernel with two =
cards attached

I looked through my old mails from you and you explained already the necess=
ity of double
bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: w=
hy does the
Xenified kernel not have this kind of issue?

The driver in question is nearly identical between the two kernel versions.=
 It is in
Drivers/media/dvb/ttpci by the way and when I understood the code right, th=
e allo in =

question is:

        /* allocate and init buffers */
        av7110->debi_virt =3D pci_alloc_consistent(pdev, 8192, &av7110->deb=
i_bus);
        if (!av7110->debi_virt)
                goto err_saa71466_vfree_4;

isn't it? I think the cards are constantly transferring the stream received=
 through DMA. =


I have set dom0_mem=3D512M by the way, shall I change that in some way?

I can try out some things, if you want me to. But I have no idea what to do=
 and where to
start, so I rely on your help...

Carsten.

-----Urspr=FCngliche Nachricht-----
Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.=
xensource.com] Im Auftrag von Konrad Rzeszutek Wilk
Gesendet: Freitag, 25. November 2011 19:43
An: Carsten Schiers
Cc: xen-devel; konrad.wilk
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:
> Hello again, I would like to come back to that thing...sorry that I did n=
ot have the time up to now.
> =

> ??
> We (now) speak about
> =

> ??
> *	Xen 4.1.2
> *	Dom0 is Jeremy's 2.6.32.46 64 bit
> *	DomU in question is now 3.1.2 64 bit
> *	Same thing if DomU is also 2.6.32.46
> *	DomU owns two PCI cards (DVB-C) that o DMA
> *	Machine has 8GB, Dom0 pinned at 512MB
> =

> ??
> As compared to 2.6.34 Kernel with backported patches, the load on the Dom=
U is at least twice as high. It
> =

> will be "close to normal" if I reduce the memory used to 4GB.

That is in the dom0 or just in general on the machine?
> =

> ??
> As you can see from the attachment, you once had an idea. So should we tr=
y to find something...?

I think that was to instrument swiotlb to give an idea of how
often it is called and basically have a matrix of its load. And
from there figure out if the issue is that:

 1). The drivers allocoate/bounce/deallocate buffers on every interrupt
    (bad, driver should be using some form of dma pool and most of the
    ivtv do that)

 2). The buffers allocated to the drivers are above the 4GB and we end
    up bouncing it needlessly. That can happen if the dom0 has most of
    the precious memory under 4GB. However, that is usually not the case
    as the domain isusually allocated from the top of the memory. The
    fix for that was to set dom0_mem=3Dmax:XX. .. but with Dom0 kernels
    before 3.1, the parameter would be ignored, so you had to use
    'mem=3DXX' on the Linux command line as well.

 3). Where did you get the load values? Was it dom0? or domU?



> =

> ??
> Carsten.
> ??
> -----Urspr??ngliche Nachricht-----
> An:konrad.wilk <konrad.wilk@oracle.com>; =

> CC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com=
>; =

> Von:Carsten Schiers <carsten@schiers.de>
> Gesendet:Mi 29.06.2011 23:17
> Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memor=
y upgrade?
> > Lets first do the c) experiment as that will likely explain your load a=
verage increase.
> ...
> > >c). If you want to see if the fault here lies in the bounce buffer =

> > being used more
> > >often in the DomU b/c you have 8GB of memory now and you end up using =

> > more pages
> > >past 4GB (in DomU), I can cook up a patch to figure this out. But an =

> > easier way is
> > >to just do (on the Xen hypervisor line): mem=3D4G and that will make =

> > think you only have
> > >4GB of physical RAM. ??If the load comes back to the normal "amount" =

> > then the likely
> > >culprit is that and we can think on how to fix this.
> =

> You are on the right track. Load was going down to "normal" 10% when redu=
cing
> Xen to 4GB by the parameter. Load seems to be still a little, little bit =
lower
> with Xenified Kernel (8-9%), but this is drastically lower than the 20% w=
e had
> before.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 00:27:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 00:27:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU66B-0000lB-Qv; Sat, 26 Nov 2011 00:26:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RU66A-0000l6-Ng
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 00:26:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322267144!47146672!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23298 invoked from network); 26 Nov 2011 00:25:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 00:25:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,574,1315180800"; 
   d="scan'208";a="9138186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 00:25:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 00:25:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RU65e-0000ae-NZ;
	Sat, 26 Nov 2011 00:25:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RU65e-0006Ds-N6;
	Sat, 26 Nov 2011 00:25:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10056-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 00:25:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10056: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10056 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10056/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  96bbdc894224
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 886 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 00:27:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 00:27:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU66B-0000lB-Qv; Sat, 26 Nov 2011 00:26:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RU66A-0000l6-Ng
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 00:26:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322267144!47146672!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23298 invoked from network); 26 Nov 2011 00:25:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 00:25:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,574,1315180800"; 
   d="scan'208";a="9138186"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 00:25:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 00:25:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RU65e-0000ae-NZ;
	Sat, 26 Nov 2011 00:25:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RU65e-0006Ds-N6;
	Sat, 26 Nov 2011 00:25:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10056-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 00:25:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10056: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10056 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10056/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  96bbdc894224
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 886 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 04:19:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 04:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU9jF-0008DJ-GH; Sat, 26 Nov 2011 04:19:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RU9jE-0008DE-5F
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 04:19:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322281110!4986118!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9167 invoked from network); 26 Nov 2011 04:18:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 04:18:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,575,1315180800"; 
   d="scan'208";a="9138537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 04:18:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 04:18:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RU9ig-0001rt-0R;
	Sat, 26 Nov 2011 04:18:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RU9if-0003wq-UE;
	Sat, 26 Nov 2011 04:18:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10062-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 04:18:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10062: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10062 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10062/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 04:19:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 04:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RU9jF-0008DJ-GH; Sat, 26 Nov 2011 04:19:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RU9jE-0008DE-5F
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 04:19:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322281110!4986118!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9167 invoked from network); 26 Nov 2011 04:18:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 04:18:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,575,1315180800"; 
   d="scan'208";a="9138537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 04:18:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 04:18:30 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RU9ig-0001rt-0R;
	Sat, 26 Nov 2011 04:18:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RU9if-0003wq-UE;
	Sat, 26 Nov 2011 04:18:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10062-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 04:18:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10062: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10062 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10062/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 06:59:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 06:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUCDx-0001Xg-Ke; Sat, 26 Nov 2011 06:58:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUCDw-0001Xb-Ip
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 06:58:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322290703!3127356!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31683 invoked from network); 26 Nov 2011 06:58:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 06:58:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,575,1315180800"; 
   d="scan'208";a="9139148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 06:58:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 06:58:22 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUCDO-0002kl-4C;
	Sat, 26 Nov 2011 06:58:22 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUCDO-0004Da-3b;
	Sat, 26 Nov 2011 06:58:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10069-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 06:58:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10069: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10069 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10069/

Regressions :-(

Tests which did not succeed and are blocking:
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-intel  7 redhat-install  fail in 10062 REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install    fail in 10062 REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install   fail in 10062 REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install  fail in 10062 REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 build-amd64                   4 xen-build                   fail pass in 10062
 build-amd64-pvops             4 kernel-build                fail pass in 10062
 build-amd64-oldkern           4 xen-build                   fail pass in 10062

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 10062 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10062 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10062 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 10062 never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 06:59:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 06:59:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUCDx-0001Xg-Ke; Sat, 26 Nov 2011 06:58:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUCDw-0001Xb-Ip
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 06:58:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322290703!3127356!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31683 invoked from network); 26 Nov 2011 06:58:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 06:58:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,575,1315180800"; 
   d="scan'208";a="9139148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 06:58:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 06:58:22 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUCDO-0002kl-4C;
	Sat, 26 Nov 2011 06:58:22 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUCDO-0004Da-3b;
	Sat, 26 Nov 2011 06:58:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10069-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 06:58:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10069: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10069 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10069/

Regressions :-(

Tests which did not succeed and are blocking:
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-intel  7 redhat-install  fail in 10062 REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install    fail in 10062 REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install   fail in 10062 REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install  fail in 10062 REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 build-amd64                   4 xen-build                   fail pass in 10062
 build-amd64-pvops             4 kernel-build                fail pass in 10062
 build-amd64-oldkern           4 xen-build                   fail pass in 10062

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 10062 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10062 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10062 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 10062 never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 09:15:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 09:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUELQ-0004Di-BR; Sat, 26 Nov 2011 09:14:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RUELO-0004Da-SZ
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 09:14:47 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322298853!5112714!1
X-Originating-IP: [194.117.254.36]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24109 invoked from network); 26 Nov 2011 09:14:13 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2011 09:14:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=fuKzBVBIkQef9Dho7h39NxWqm4ozUj9j06kZ5E92Gts=; b=nB8rLyK
	tv3jeXvZNWSzE//FA1X4zdrkVFqVsWZo9eavEX3VdxqKShKyNvUhqtu6j23MwMVr
	gIznt+krXseHYO5vAtgYm0oOofR7d+XwfY22DQUvx21d5trdPwZYtRd6WQ06SgVn
	ZelvsWTKBjer8xB3/NgqU3oOb/tmu5i3ZmJY=
Received: (qmail 4271 invoked from network); 26 Nov 2011 10:14:12 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.138.119)
	by mail.zeus06.de with ESMTPA; 26 Nov 2011 10:14:12 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 5E80F2C514;
	Sat, 26 Nov 2011 10:14:12 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id IM3oiGpi-m4c; Sat, 26 Nov 2011 10:14:09 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id EEF022C513;
	Sat, 26 Nov 2011 10:14:08 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Sat, 26 Nov 2011 10:14:08 +0100
Mime-Version: 1.0
In-Reply-To: <20111125184233.GB26841@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: AcysG7Qw+7VA+AppTSanuxlIe8GLhg==
Message-Id: <zarafa.4ed0ade0.2336.3bb50750629d7fd5@uhura.space.zz>
Cc: =?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

To add (read from some munin statistics I made over the time):

  - with load I mean the %CPU of xentop
  - there is no change in CPU usage of the DomU or Dom0
  - xenpm shows the core dedicated to that DomU is doing more work

Also I need to say that reduction to 4GB was performed by Xen parameter.

Carsten.


-----Urspr=FCngliche Nachricht-----
Von: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] =

Gesendet: Freitag, 25. November 2011 19:43
An: Carsten Schiers
Cc: konrad.wilk; xen-devel
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:
> Hello again, I would like to come back to that thing...sorry that I did n=
ot have the time up to now.
> =

> ??
> We (now) speak about
> =

> ??
> *	Xen 4.1.2
> *	Dom0 is Jeremy's 2.6.32.46 64 bit
> *	DomU in question is now 3.1.2 64 bit
> *	Same thing if DomU is also 2.6.32.46
> *	DomU owns two PCI cards (DVB-C) that o DMA
> *	Machine has 8GB, Dom0 pinned at 512MB
> =

> ??
> As compared to 2.6.34 Kernel with backported patches, the load on the Dom=
U is at least twice as high. It
> =

> will be "close to normal" if I reduce the memory used to 4GB.

That is in the dom0 or just in general on the machine?
> =

> ??
> As you can see from the attachment, you once had an idea. So should we tr=
y to find something...?

I think that was to instrument swiotlb to give an idea of how
often it is called and basically have a matrix of its load. And
from there figure out if the issue is that:

 1). The drivers allocoate/bounce/deallocate buffers on every interrupt
    (bad, driver should be using some form of dma pool and most of the
    ivtv do that)

 2). The buffers allocated to the drivers are above the 4GB and we end
    up bouncing it needlessly. That can happen if the dom0 has most of
    the precious memory under 4GB. However, that is usually not the case
    as the domain isusually allocated from the top of the memory. The
    fix for that was to set dom0_mem=3Dmax:XX. .. but with Dom0 kernels
    before 3.1, the parameter would be ignored, so you had to use
    'mem=3DXX' on the Linux command line as well.

 3). Where did you get the load values? Was it dom0? or domU?



> =

> ??
> Carsten.
> ??
> -----Urspr??ngliche Nachricht-----
> An:konrad.wilk <konrad.wilk@oracle.com>; =

> CC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com=
>; =

> Von:Carsten Schiers <carsten@schiers.de>
> Gesendet:Mi 29.06.2011 23:17
> Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memor=
y upgrade?
> > Lets first do the c) experiment as that will likely explain your load a=
verage increase.
> ...
> > >c). If you want to see if the fault here lies in the bounce buffer =

> > being used more
> > >often in the DomU b/c you have 8GB of memory now and you end up using =

> > more pages
> > >past 4GB (in DomU), I can cook up a patch to figure this out. But an =

> > easier way is
> > >to just do (on the Xen hypervisor line): mem=3D4G and that will make =

> > think you only have
> > >4GB of physical RAM. ??If the load comes back to the normal "amount" =

> > then the likely
> > >culprit is that and we can think on how to fix this.
> =

> You are on the right track. Load was going down to "normal" 10% when redu=
cing
> Xen to 4GB by the parameter. Load seems to be still a little, little bit =
lower
> with Xenified Kernel (8-9%), but this is drastically lower than the 20% w=
e had
> before.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 09:15:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 09:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUELQ-0004Di-BR; Sat, 26 Nov 2011 09:14:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RUELO-0004Da-SZ
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 09:14:47 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322298853!5112714!1
X-Originating-IP: [194.117.254.36]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24109 invoked from network); 26 Nov 2011 09:14:13 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2011 09:14:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type
	:content-transfer-encoding:in-reply-to:references:message-id; s=
	beta; bh=fuKzBVBIkQef9Dho7h39NxWqm4ozUj9j06kZ5E92Gts=; b=nB8rLyK
	tv3jeXvZNWSzE//FA1X4zdrkVFqVsWZo9eavEX3VdxqKShKyNvUhqtu6j23MwMVr
	gIznt+krXseHYO5vAtgYm0oOofR7d+XwfY22DQUvx21d5trdPwZYtRd6WQ06SgVn
	ZelvsWTKBjer8xB3/NgqU3oOb/tmu5i3ZmJY=
Received: (qmail 4271 invoked from network); 26 Nov 2011 10:14:12 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.138.119)
	by mail.zeus06.de with ESMTPA; 26 Nov 2011 10:14:12 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 5E80F2C514;
	Sat, 26 Nov 2011 10:14:12 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id IM3oiGpi-m4c; Sat, 26 Nov 2011 10:14:09 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id EEF022C513;
	Sat, 26 Nov 2011 10:14:08 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Sat, 26 Nov 2011 10:14:08 +0100
Mime-Version: 1.0
In-Reply-To: <20111125184233.GB26841@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: AcysG7Qw+7VA+AppTSanuxlIe8GLhg==
Message-Id: <zarafa.4ed0ade0.2336.3bb50750629d7fd5@uhura.space.zz>
Cc: =?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel]
 =?iso-8859-1?q?Load_increase_after_memory_upgrade_=28?=
 =?iso-8859-1?q?part2=29?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

To add (read from some munin statistics I made over the time):

  - with load I mean the %CPU of xentop
  - there is no change in CPU usage of the DomU or Dom0
  - xenpm shows the core dedicated to that DomU is doing more work

Also I need to say that reduction to 4GB was performed by Xen parameter.

Carsten.


-----Urspr=FCngliche Nachricht-----
Von: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] =

Gesendet: Freitag, 25. November 2011 19:43
An: Carsten Schiers
Cc: konrad.wilk; xen-devel
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:
> Hello again, I would like to come back to that thing...sorry that I did n=
ot have the time up to now.
> =

> ??
> We (now) speak about
> =

> ??
> *	Xen 4.1.2
> *	Dom0 is Jeremy's 2.6.32.46 64 bit
> *	DomU in question is now 3.1.2 64 bit
> *	Same thing if DomU is also 2.6.32.46
> *	DomU owns two PCI cards (DVB-C) that o DMA
> *	Machine has 8GB, Dom0 pinned at 512MB
> =

> ??
> As compared to 2.6.34 Kernel with backported patches, the load on the Dom=
U is at least twice as high. It
> =

> will be "close to normal" if I reduce the memory used to 4GB.

That is in the dom0 or just in general on the machine?
> =

> ??
> As you can see from the attachment, you once had an idea. So should we tr=
y to find something...?

I think that was to instrument swiotlb to give an idea of how
often it is called and basically have a matrix of its load. And
from there figure out if the issue is that:

 1). The drivers allocoate/bounce/deallocate buffers on every interrupt
    (bad, driver should be using some form of dma pool and most of the
    ivtv do that)

 2). The buffers allocated to the drivers are above the 4GB and we end
    up bouncing it needlessly. That can happen if the dom0 has most of
    the precious memory under 4GB. However, that is usually not the case
    as the domain isusually allocated from the top of the memory. The
    fix for that was to set dom0_mem=3Dmax:XX. .. but with Dom0 kernels
    before 3.1, the parameter would be ignored, so you had to use
    'mem=3DXX' on the Linux command line as well.

 3). Where did you get the load values? Was it dom0? or domU?



> =

> ??
> Carsten.
> ??
> -----Urspr??ngliche Nachricht-----
> An:konrad.wilk <konrad.wilk@oracle.com>; =

> CC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com=
>; =

> Von:Carsten Schiers <carsten@schiers.de>
> Gesendet:Mi 29.06.2011 23:17
> Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memor=
y upgrade?
> > Lets first do the c) experiment as that will likely explain your load a=
verage increase.
> ...
> > >c). If you want to see if the fault here lies in the bounce buffer =

> > being used more
> > >often in the DomU b/c you have 8GB of memory now and you end up using =

> > more pages
> > >past 4GB (in DomU), I can cook up a patch to figure this out. But an =

> > easier way is
> > >to just do (on the Xen hypervisor line): mem=3D4G and that will make =

> > think you only have
> > >4GB of physical RAM. ??If the load comes back to the normal "amount" =

> > then the likely
> > >culprit is that and we can think on how to fix this.
> =

> You are on the right track. Load was going down to "normal" 10% when redu=
cing
> Xen to 4GB by the parameter. Load seems to be still a little, little bit =
lower
> with Xenified Kernel (8-9%), but this is drastically lower than the 20% w=
e had
> before.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 14:31:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 14:31:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUJH6-0007cK-SF; Sat, 26 Nov 2011 14:30:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hedayati.mo@gmail.com>) id 1RUJH5-0007cF-Hr
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 14:30:39 +0000
X-Env-Sender: hedayati.mo@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322314290!3156795!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17670 invoked from network); 26 Nov 2011 13:31:30 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 13:31:30 -0000
Received: by wwo1 with SMTP id 1so6375608wwo.24
	for <xen-devel@lists.xensource.com>;
	Sat, 26 Nov 2011 05:31:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=cbn/ayBgF74zdI9B+Ww93mDfqWdRy/OQ99tCOzqxZaI=;
	b=O2RuFfwcx7l17J6GcsRX9h1XPo2Vh2j/W3nuYvXWfMasJf6ESOkOvahlqbnu2jO27f
	BLIjesssqs2TfPIpz/7F9bv4OBfXQgooSop2JBWBvMkzVQ2R3ugoC4YW8LMCiksFYTdu
	ndYzt7b30XqZ9gygQDst0PD/m0yYgdYfYAiuk=
Received: by 10.216.15.14 with SMTP id e14mr539633wee.21.1322314290106; Sat,
	26 Nov 2011 05:31:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.65.212 with HTTP; Sat, 26 Nov 2011 05:30:49 -0800 (PST)
From: Mohammad Hedayati <hedayati.mo@gmail.com>
Date: Sat, 26 Nov 2011 17:00:49 +0330
Message-ID: <CABA5EEtQUCn_CMirxPwrctqVcQnxa9LEoDgt_eeiFnuXsM+JGg@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xenloop alloc_vm_area crashes domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I am trying to port Xenloop to Xen 4.0.1 and 2.6.35. It uses the
following piece of code to map a granted page:

	xfc->descriptor_vmarea = alloc_vm_area(PAGE_SIZE);
	xfc->fifo_vmarea = alloc_vm_area( MAX_FIFO_PAGES*PAGE_SIZE );
	if(!xfc->descriptor_vmarea || !xfc->fifo_vmarea) {
		EPRINTK("error: cannot allocate memory for descriptor OR FIFO\n");
		goto err;
	}

	gnttab_set_map_op(&map_op, (unsigned long)xfc->descriptor_vmarea->addr,
				GNTMAP_host_map, remote_gref, remote_domid);
	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &map_op, 1);

but alloc_vm_area fails and crashes domU. in_interrupt() returns 256
and I think this is the cause. Any idea about what should I do?
Thanks,
- Mohammad

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 14:31:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 14:31:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUJH6-0007cK-SF; Sat, 26 Nov 2011 14:30:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hedayati.mo@gmail.com>) id 1RUJH5-0007cF-Hr
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 14:30:39 +0000
X-Env-Sender: hedayati.mo@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322314290!3156795!1
X-Originating-IP: [74.125.82.43]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17670 invoked from network); 26 Nov 2011 13:31:30 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 13:31:30 -0000
Received: by wwo1 with SMTP id 1so6375608wwo.24
	for <xen-devel@lists.xensource.com>;
	Sat, 26 Nov 2011 05:31:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=cbn/ayBgF74zdI9B+Ww93mDfqWdRy/OQ99tCOzqxZaI=;
	b=O2RuFfwcx7l17J6GcsRX9h1XPo2Vh2j/W3nuYvXWfMasJf6ESOkOvahlqbnu2jO27f
	BLIjesssqs2TfPIpz/7F9bv4OBfXQgooSop2JBWBvMkzVQ2R3ugoC4YW8LMCiksFYTdu
	ndYzt7b30XqZ9gygQDst0PD/m0yYgdYfYAiuk=
Received: by 10.216.15.14 with SMTP id e14mr539633wee.21.1322314290106; Sat,
	26 Nov 2011 05:31:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.65.212 with HTTP; Sat, 26 Nov 2011 05:30:49 -0800 (PST)
From: Mohammad Hedayati <hedayati.mo@gmail.com>
Date: Sat, 26 Nov 2011 17:00:49 +0330
Message-ID: <CABA5EEtQUCn_CMirxPwrctqVcQnxa9LEoDgt_eeiFnuXsM+JGg@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] xenloop alloc_vm_area crashes domU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I am trying to port Xenloop to Xen 4.0.1 and 2.6.35. It uses the
following piece of code to map a granted page:

	xfc->descriptor_vmarea = alloc_vm_area(PAGE_SIZE);
	xfc->fifo_vmarea = alloc_vm_area( MAX_FIFO_PAGES*PAGE_SIZE );
	if(!xfc->descriptor_vmarea || !xfc->fifo_vmarea) {
		EPRINTK("error: cannot allocate memory for descriptor OR FIFO\n");
		goto err;
	}

	gnttab_set_map_op(&map_op, (unsigned long)xfc->descriptor_vmarea->addr,
				GNTMAP_host_map, remote_gref, remote_domid);
	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &map_op, 1);

but alloc_vm_area fails and crashes domU. in_interrupt() returns 256
and I think this is the cause. Any idea about what should I do?
Thanks,
- Mohammad

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 15:29:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 15:29:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUKB1-0008Cj-VJ; Sat, 26 Nov 2011 15:28:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUKB0-0008Cd-T1
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 15:28:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322321273!5069100!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6558 invoked from network); 26 Nov 2011 15:27:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 15:27:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,575,1315180800"; 
   d="scan'208";a="9140859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 15:27:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 15:27:52 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUKAS-0005Zh-2m;
	Sat, 26 Nov 2011 15:27:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUKAS-0007QX-2K;
	Sat, 26 Nov 2011 15:27:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10092-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 15:27:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10092: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10092 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10092/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install    fail in 10062 REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10062
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 10062

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2          fail in 10062 like 9955

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 15:29:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 15:29:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUKB1-0008Cj-VJ; Sat, 26 Nov 2011 15:28:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUKB0-0008Cd-T1
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 15:28:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322321273!5069100!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6558 invoked from network); 26 Nov 2011 15:27:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 15:27:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,575,1315180800"; 
   d="scan'208";a="9140859"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 15:27:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 15:27:52 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUKAS-0005Zh-2m;
	Sat, 26 Nov 2011 15:27:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUKAS-0007QX-2K;
	Sat, 26 Nov 2011 15:27:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10092-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 15:27:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10092: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10092 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10092/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install    fail in 10062 REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10062
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                    fail pass in 10062

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2          fail in 10062 like 9955

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 16:13:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 16:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUKrd-0001CC-DO; Sat, 26 Nov 2011 16:12:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RUKrc-0001C6-DI
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 16:12:28 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322323913!3161117!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19790 invoked from network); 26 Nov 2011 16:11:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2011 16:11:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAQGBmnF013199
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 26 Nov 2011 16:11:49 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAQGBlGi023743
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 26 Nov 2011 16:11:47 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAQGBgAv026831; Sat, 26 Nov 2011 10:11:42 -0600
MIME-Version: 1.0
Message-ID: <a930b4cd-e6df-44de-9907-1f9149bd4ccc@default>
Date: Sat, 26 Nov 2011 08:11:32 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <20171.55835.240381.351382@mariner.uk.xensource.com>
	<2b60cfe7-2c97-45ef-bf89-88cd01cff1d3@default
	20174.36841.738985.984736@mariner.uk.xensource.com>
In-Reply-To: <20174.36841.738985.984736@mariner.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0  (410211) [OL
	12.0.6607.1000]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4ED10FC5.004D,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Konrad Wilk <konrad.wilk@oracle.com>,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Thursday, November 24, 2011 11:42 AM
> To: Dan Magenheimer
> Cc: xen-devel@lists.xensource.com; stefano.stabellini@eu.citrix.com
> Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness
> 
> Dan Magenheimer writes ("Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-pars> No, it doesn't.  I
> agree it *could* if parse_string is
> > used/called differently.  The caller simply needs to
> > ensure that the declared buffer is at least one larger
> > than the data to be matched which is true for both
> > callers.
> 
> Urgh.  So in the previous code the buffer was a byte too big ?
> 
> I think functions with prototypes like
>      f(int len, char *buf)
> should take buf[len], not buf[len+1].

FWIW, I agree completely.  I didn't write this code from
scratch, I heavily leveraged it from elsewhere (don't
recall exactly where, maybe xentop?).

If necessary, I will rewrite the callers and API but
I was just trying to fix an annoying bug expeditiously.
Let me know if you won't accept it as the one-line
ugly fix.
 
> > P.S. Please note that I am still not receiving email
> > >from the xen-devel reflector (and am on vacation this
> > week so probably won't be looking into it... my best
> > guess is that the Oracle spam filter isn't happy with
> > the new source of the xen-devel messages, as some
> > other Oracle folk are having problems too).
> 
> Hrmm.  If this is still a problem when you get back please let me know.

Still a problem.  Konrad filed an internal bug report
(Oracle has an Exchange-like mail server that is eat-
your-own-dog-food) but the US holiday weekend, which
many turn into a whole week, means it's probably not
even getting looked at yet by Oracle's IT group.

It may be unrelated to the xen.org server change but
the coincidence is suspicious.

Interestingly, I got precisely one xen-devel email in
the last week which is what led me to the spam filter
theory... though I have gotten every xen-changelog email.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 16:13:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 16:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUKrd-0001CC-DO; Sat, 26 Nov 2011 16:12:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RUKrc-0001C6-DI
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 16:12:28 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322323913!3161117!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19790 invoked from network); 26 Nov 2011 16:11:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Nov 2011 16:11:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAQGBmnF013199
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 26 Nov 2011 16:11:49 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAQGBlGi023743
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 26 Nov 2011 16:11:47 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAQGBgAv026831; Sat, 26 Nov 2011 10:11:42 -0600
MIME-Version: 1.0
Message-ID: <a930b4cd-e6df-44de-9907-1f9149bd4ccc@default>
Date: Sat, 26 Nov 2011 08:11:32 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <20171.55835.240381.351382@mariner.uk.xensource.com>
	<2b60cfe7-2c97-45ef-bf89-88cd01cff1d3@default
	20174.36841.738985.984736@mariner.uk.xensource.com>
In-Reply-To: <20174.36841.738985.984736@mariner.uk.xensource.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0  (410211) [OL
	12.0.6607.1000]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4ED10FC5.004D,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Konrad Wilk <konrad.wilk@oracle.com>,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: Thursday, November 24, 2011 11:42 AM
> To: Dan Magenheimer
> Cc: xen-devel@lists.xensource.com; stefano.stabellini@eu.citrix.com
> Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness
> 
> Dan Magenheimer writes ("Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-pars> No, it doesn't.  I
> agree it *could* if parse_string is
> > used/called differently.  The caller simply needs to
> > ensure that the declared buffer is at least one larger
> > than the data to be matched which is true for both
> > callers.
> 
> Urgh.  So in the previous code the buffer was a byte too big ?
> 
> I think functions with prototypes like
>      f(int len, char *buf)
> should take buf[len], not buf[len+1].

FWIW, I agree completely.  I didn't write this code from
scratch, I heavily leveraged it from elsewhere (don't
recall exactly where, maybe xentop?).

If necessary, I will rewrite the callers and API but
I was just trying to fix an annoying bug expeditiously.
Let me know if you won't accept it as the one-line
ugly fix.
 
> > P.S. Please note that I am still not receiving email
> > >from the xen-devel reflector (and am on vacation this
> > week so probably won't be looking into it... my best
> > guess is that the Oracle spam filter isn't happy with
> > the new source of the xen-devel messages, as some
> > other Oracle folk are having problems too).
> 
> Hrmm.  If this is still a problem when you get back please let me know.

Still a problem.  Konrad filed an internal bug report
(Oracle has an Exchange-like mail server that is eat-
your-own-dog-food) but the US holiday weekend, which
many turn into a whole week, means it's probably not
even getting looked at yet by Oracle's IT group.

It may be unrelated to the xen.org server change but
the coincidence is suspicious.

Interestingly, I got precisely one xen-devel email in
the last week which is what led me to the spam filter
theory... though I have gotten every xen-changelog email.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 19:50:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 19:50:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUOFQ-0003gQ-IW; Sat, 26 Nov 2011 19:49:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUOFO-0003gK-US
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 19:49:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322336920!3180874!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28791 invoked from network); 26 Nov 2011 19:48:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 19:48:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,576,1315180800"; 
   d="scan'208";a="9141599"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 19:48:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 19:48:39 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUOEp-00070s-OO;
	Sat, 26 Nov 2011 19:48:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUOEp-0006zp-Ey;
	Sat, 26 Nov 2011 19:48:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10098-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 19:48:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10098: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10098 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10098/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate           fail    like 9951
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 19:50:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 19:50:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUOFQ-0003gQ-IW; Sat, 26 Nov 2011 19:49:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUOFO-0003gK-US
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 19:49:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322336920!3180874!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28791 invoked from network); 26 Nov 2011 19:48:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 19:48:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,576,1315180800"; 
   d="scan'208";a="9141599"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 19:48:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 19:48:39 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUOEp-00070s-OO;
	Sat, 26 Nov 2011 19:48:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUOEp-0006zp-Ey;
	Sat, 26 Nov 2011 19:48:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10098-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 19:48:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10098: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10098 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10098/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate           fail    like 9951
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 23:44:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 23:44:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RURur-0008Ij-GJ; Sat, 26 Nov 2011 23:44:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RURuq-0008IY-2z
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 23:44:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322351022!5162743!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1889 invoked from network); 26 Nov 2011 23:43:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 23:43:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,577,1315180800"; 
   d="scan'208";a="9142059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 23:43:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 23:43:41 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RURuH-0008IJ-FL;
	Sat, 26 Nov 2011 23:43:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RURuH-0005oK-D2;
	Sat, 26 Nov 2011 23:43:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10105-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 23:43:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10105: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10105 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10105/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Nov 26 23:44:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 26 Nov 2011 23:44:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RURur-0008Ij-GJ; Sat, 26 Nov 2011 23:44:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RURuq-0008IY-2z
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 23:44:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322351022!5162743!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1889 invoked from network); 26 Nov 2011 23:43:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Nov 2011 23:43:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,577,1315180800"; 
   d="scan'208";a="9142059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Nov 2011 23:43:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 26 Nov 2011 23:43:41 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RURuH-0008IJ-FL;
	Sat, 26 Nov 2011 23:43:41 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RURuH-0005oK-D2;
	Sat, 26 Nov 2011 23:43:41 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10105-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 26 Nov 2011 23:43:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10105: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10105 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10105/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 01:57:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 01:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUTyT-0005Fi-CO; Sun, 27 Nov 2011 01:56:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>)
	id 1RUTyR-0005Fa-AJ; Sun, 27 Nov 2011 01:56:07 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322358902!45537128!1
X-Originating-IP: [74.207.240.146]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18155 invoked from network); 27 Nov 2011 01:55:03 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2011 01:55:03 -0000
Received: from saboo.goop.org (unknown
	[IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 81681425;
	Sat, 26 Nov 2011 17:55:35 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id D0A202066F;
	Sat, 26 Nov 2011 17:55:34 -0800 (PST)
Message-ID: <4ED19896.6040201@goop.org>
Date: Sat, 26 Nov 2011 17:55:34 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111251201421.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111251201421.31179@kaball-desktop>
X-Enigmail-Version: 1.3.3
Cc: xen-arm@lists.xensource.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [RFC] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7
 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/25/2011 06:06 AM, Stefano Stabellini wrote:
> Hi everybody,
> a few weeks ago a small group of hackers started working from scratch on
> a Cortex-A15 Xen port, exploiting all the latest hardware virtualization
> extensions.
>
> The port can now boot dom0 all the way to a shell prompt,

Congratulations!

>  so we are
> planning to make an announcement to various Open Source communities
> regarding ARMv7 with virt extensions support in Xen. The intention is to
> get more parties interested and engaged in Xen on ARM in general, and
> also to get feedback.  We propose to send the email below, to the
> following mailings lists:
>
> virtualization@lists.linux-foundation.org
> linux-kernel@vger.kernel.org
> linux-arm-kernel@lists.infradead.org
> android-virt@lists.cs.columbia.edu
> linaro-dev@lists.linaro.org
KVM <kvm@vger.kernel.org> (seriously!)

Good work!

    J(!)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 01:57:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 01:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUTyT-0005Fi-CO; Sun, 27 Nov 2011 01:56:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>)
	id 1RUTyR-0005Fa-AJ; Sun, 27 Nov 2011 01:56:07 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322358902!45537128!1
X-Originating-IP: [74.207.240.146]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18155 invoked from network); 27 Nov 2011 01:55:03 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2011 01:55:03 -0000
Received: from saboo.goop.org (unknown
	[IPv6:2001:470:1f05:899:f2de:f1ff:fe5c:34ed])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 81681425;
	Sat, 26 Nov 2011 17:55:35 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id D0A202066F;
	Sat, 26 Nov 2011 17:55:34 -0800 (PST)
Message-ID: <4ED19896.6040201@goop.org>
Date: Sat, 26 Nov 2011 17:55:34 -0800
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111251201421.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111251201421.31179@kaball-desktop>
X-Enigmail-Version: 1.3.3
Cc: xen-arm@lists.xensource.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [RFC] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7
 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/25/2011 06:06 AM, Stefano Stabellini wrote:
> Hi everybody,
> a few weeks ago a small group of hackers started working from scratch on
> a Cortex-A15 Xen port, exploiting all the latest hardware virtualization
> extensions.
>
> The port can now boot dom0 all the way to a shell prompt,

Congratulations!

>  so we are
> planning to make an announcement to various Open Source communities
> regarding ARMv7 with virt extensions support in Xen. The intention is to
> get more parties interested and engaged in Xen on ARM in general, and
> also to get feedback.  We propose to send the email below, to the
> following mailings lists:
>
> virtualization@lists.linux-foundation.org
> linux-kernel@vger.kernel.org
> linux-arm-kernel@lists.infradead.org
> android-virt@lists.cs.columbia.edu
> linaro-dev@lists.linaro.org
KVM <kvm@vger.kernel.org> (seriously!)

Good work!

    J(!)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 03:31:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 03:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUVSK-0007M3-Kl; Sun, 27 Nov 2011 03:31:04 +0000
Message-Id: <E1RUVSK-0007M3-Kl@lists.xen.org>
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72) id 1RUVSJ-0007Ly-5d
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 03:31:03 +0000
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322364627!5926192!1
X-Originating-IP: [183.24.212.205]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17577 invoked from network); 27 Nov 2011 03:30:27 -0000
Received: from unknown (HELO PC-201103111254) (183.24.212.205)
	by server-4.tower-21.messagelabs.com with SMTP;
	27 Nov 2011 03:30:27 -0000
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 11:30:39 +0800
Subject: [Xen-devel] =?gb2312?b?s8LPyMn6o7oxMzcxMDEwMzE3OKOsUVE6NDAzODg4?=
	=?gb2312?b?MzIz?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5287361938264263294=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
From: xen-devel-bounces@lists.xensource.com

--===============5287361938264263294==
Content-Type: TEXT/HTML

£¨´ú£©£¨¿ª£©£¨·¢£©£¨Æ±£©

£¨¼Û£©£¨¸ñ£©£¨ÓÅ£©£¨»Ý£©

£¨Ñ飩£¨ºó£©£¨¸¶£©£¨¿î£©

£¨ºÏ£©£¨×÷£©£¨Ó䣩£¨¿ì£©

ÁªÏµÈË£º³ÂÏÈÉú

ÁªÏµµç»°£º13710103178£¬qq£º403888323



--===============5287361938264263294==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5287361938264263294==--

From xen-devel-bounces@lists.xensource.com Sun Nov 27 03:31:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 03:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUVSK-0007M3-Kl; Sun, 27 Nov 2011 03:31:04 +0000
Message-Id: <E1RUVSK-0007M3-Kl@lists.xen.org>
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72) id 1RUVSJ-0007Ly-5d
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 03:31:03 +0000
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322364627!5926192!1
X-Originating-IP: [183.24.212.205]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17577 invoked from network); 27 Nov 2011 03:30:27 -0000
Received: from unknown (HELO PC-201103111254) (183.24.212.205)
	by server-4.tower-21.messagelabs.com with SMTP;
	27 Nov 2011 03:30:27 -0000
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 11:30:39 +0800
Subject: [Xen-devel] =?gb2312?b?s8LPyMn6o7oxMzcxMDEwMzE3OKOsUVE6NDAzODg4?=
	=?gb2312?b?MzIz?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5287361938264263294=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
From: xen-devel-bounces@lists.xensource.com

--===============5287361938264263294==
Content-Type: TEXT/HTML

£¨´ú£©£¨¿ª£©£¨·¢£©£¨Æ±£©

£¨¼Û£©£¨¸ñ£©£¨ÓÅ£©£¨»Ý£©

£¨Ñ飩£¨ºó£©£¨¸¶£©£¨¿î£©

£¨ºÏ£©£¨×÷£©£¨Ó䣩£¨¿ì£©

ÁªÏµÈË£º³ÂÏÈÉú

ÁªÏµµç»°£º13710103178£¬qq£º403888323



--===============5287361938264263294==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5287361938264263294==--

From xen-devel-bounces@lists.xensource.com Sun Nov 27 03:48:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 03:48:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUViY-0007b5-GZ; Sun, 27 Nov 2011 03:47:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUViW-0007ax-Ng
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 03:47:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322365634!5942971!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13432 invoked from network); 27 Nov 2011 03:47:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2011 03:47:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,577,1315180800"; 
   d="scan'208";a="9142522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Nov 2011 03:47:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 27 Nov 2011 03:47:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUVhx-0001Cd-NI;
	Sun, 27 Nov 2011 03:47:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUVhx-0005LP-9T;
	Sun, 27 Nov 2011 03:47:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10112-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 27 Nov 2011 03:47:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10112: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10112 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10112/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-win         14 guest-start.2               fail pass in 10105

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 10105 never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 03:48:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 03:48:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUViY-0007b5-GZ; Sun, 27 Nov 2011 03:47:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUViW-0007ax-Ng
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 03:47:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322365634!5942971!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13432 invoked from network); 27 Nov 2011 03:47:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2011 03:47:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,577,1315180800"; 
   d="scan'208";a="9142522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Nov 2011 03:47:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 27 Nov 2011 03:47:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUVhx-0001Cd-NI;
	Sun, 27 Nov 2011 03:47:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUVhx-0005LP-9T;
	Sun, 27 Nov 2011 03:47:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10112-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 27 Nov 2011 03:47:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10112: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10112 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10112/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-win         14 guest-start.2               fail pass in 10105

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 10105 never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 10:11:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 10:11:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUbgx-0004BH-8n; Sun, 27 Nov 2011 10:10:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RUbgv-0004BC-Ja
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 10:10:33 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322388598!4820867!1
X-Originating-IP: [134.134.136.24]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26978 invoked from network); 27 Nov 2011 10:09:59 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-182.messagelabs.com with SMTP;
	27 Nov 2011 10:09:59 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 27 Nov 2011 02:09:58 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="80340740"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 27 Nov 2011 02:09:56 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 27 Nov 2011 18:09:55 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 27 Nov 2011 18:09:55 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Sun, 27 Nov 2011 18:09:42 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Sun, 27 Nov 2011 18:09:38 +0800
Thread-Topic: [Xen-devel] [PATCH 2/6] X86: expose Intel new features to dom0
Thread-Index: AcyqxyD2xVLTpRIQT2mTEGvcNH2GLACJXjyA
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B2@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7C@shsmsx502.ccr.corp.intel.com>
	<20111124162834.GA20715@andromeda.dapyr.net>
	<4ECE80700200007800063105@nat28.tlf.novell.com>
In-Reply-To: <4ECE80700200007800063105@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/6] X86: expose Intel new features to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 24.11.11 at 17:28, Konrad Rzeszutek Wilk <konrad@darnok.org>
>>>> wrote: 
>> On Thu, Nov 24, 2011 at 11:51:37PM +0800, Liu, Jinsong wrote:
>>> X86: expose Intel new features to dom0
>>> 
>>> This patch expose Intel new features to dom0, including
>> FMA/AVX2/BMI1/BMI2/LZCNT/MOVBE.
>> 
>> And has it been tested with 3.1 pvops kernel?
>> Does it need a patch in the pvops kernel as well?
> 
> No - these are all unprivileged instructions not requiring any OS
> support. 
> 
> Jan
> 

Yes, agree.

Thanks,
Jinsong

>>> 
>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>> 
>>> diff -r 38b25f3b2bca xen/arch/x86/traps.c
>>> --- a/xen/arch/x86/traps.c	Thu Nov 17 17:54:17 2011 +0800
>>> +++ b/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
>>> @@ -826,8 +826,11 @@ static void pv_cpuid(struct cpu_user_reg
>>> 
>>>      case 0x00000007:
>>>          if ( regs->ecx == 0 )
>>> -            b &= (cpufeat_mask(X86_FEATURE_FSGSBASE) |
>>> -                  cpufeat_mask(X86_FEATURE_ERMS));
>>> +            b &= (cpufeat_mask(X86_FEATURE_BMI1) |
>>> +                  cpufeat_mask(X86_FEATURE_AVX2) |
>>> +                  cpufeat_mask(X86_FEATURE_BMI2) |
>>> +                  cpufeat_mask(X86_FEATURE_ERMS) |
>>> +                  cpufeat_mask(X86_FEATURE_FSGSBASE));         
>>>              else b = 0;
>>>          a = c = d = 0;
>>> diff -r 38b25f3b2bca xen/include/asm-x86/cpufeature.h
>>> --- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 17:54:17 2011
>>> +0800 +++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01
>>>  2011 +0800 @@ -93,6 +93,7 @@ #define X86_FEATURE_TM2		(4*32+ 8) /*
>>>  Thermal Monitor 2 */ #define X86_FEATURE_SSSE3	(4*32+ 9) /*
>>>  Supplemental Streaming SIMD Extensions-3 */ #define
>>> X86_FEATURE_CID		(4*32+10) /* Context ID */ +#define
>>>  X86_FEATURE_FMA		(4*32+12) /* Fused Multiply Add */ #define
>>>  X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */ #define
>>>  X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
>>>  #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
>>>  @@ -100,6 +101,7 @@ #define X86_FEATURE_SSE4_1	(4*32+19) /*
>>>  Streaming SIMD Extensions 4.1 */ #define
>>> X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
>>>  #define X86_FEATURE_X2APIC	(4*32+21) /* Extended xAPIC */ +#define
>>>  X86_FEATURE_MOVBE	(4*32+22) /* movbe instruction */ #define
>>>  X86_FEATURE_POPCNT	(4*32+23) /* POPCNT instruction */ #define
>>> X86_FEATURE_TSC_DEADLINE (4*32+24) /* "tdt" TSC Deadline Timer */
>>> #define X86_FEATURE_AES		(4*32+25) /* AES instructions */ @@ -145,7
>>> +147,10 @@   
>>> 
>>>  /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx),
>>>  word 7 */ #define X86_FEATURE_FSGSBASE	(7*32+ 0) /*
>>> {RD,WR}{FS,GS}BASE instructions */ +#define X86_FEATURE_BMI1	(7*32+
>>> 3) /* 1st bit manipulation extensions */ +#define
>>>  X86_FEATURE_AVX2	(7*32+ 5) /* AVX2 instructions */ #define
>>> X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection
>>>  */ +#define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation
>>> extensions */ #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP
>>> MOVSB/STOSB */  
>>> 
>>>  #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 10:11:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 10:11:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUbgx-0004BH-8n; Sun, 27 Nov 2011 10:10:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RUbgv-0004BC-Ja
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 10:10:33 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322388598!4820867!1
X-Originating-IP: [134.134.136.24]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26978 invoked from network); 27 Nov 2011 10:09:59 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-12.tower-182.messagelabs.com with SMTP;
	27 Nov 2011 10:09:59 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 27 Nov 2011 02:09:58 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="80340740"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 27 Nov 2011 02:09:56 -0800
Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 27 Nov 2011 18:09:55 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 27 Nov 2011 18:09:55 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Sun, 27 Nov 2011 18:09:42 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Sun, 27 Nov 2011 18:09:38 +0800
Thread-Topic: [Xen-devel] [PATCH 2/6] X86: expose Intel new features to dom0
Thread-Index: AcyqxyD2xVLTpRIQT2mTEGvcNH2GLACJXjyA
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B2@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7C@shsmsx502.ccr.corp.intel.com>
	<20111124162834.GA20715@andromeda.dapyr.net>
	<4ECE80700200007800063105@nat28.tlf.novell.com>
In-Reply-To: <4ECE80700200007800063105@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2/6] X86: expose Intel new features to dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 24.11.11 at 17:28, Konrad Rzeszutek Wilk <konrad@darnok.org>
>>>> wrote: 
>> On Thu, Nov 24, 2011 at 11:51:37PM +0800, Liu, Jinsong wrote:
>>> X86: expose Intel new features to dom0
>>> 
>>> This patch expose Intel new features to dom0, including
>> FMA/AVX2/BMI1/BMI2/LZCNT/MOVBE.
>> 
>> And has it been tested with 3.1 pvops kernel?
>> Does it need a patch in the pvops kernel as well?
> 
> No - these are all unprivileged instructions not requiring any OS
> support. 
> 
> Jan
> 

Yes, agree.

Thanks,
Jinsong

>>> 
>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>> 
>>> diff -r 38b25f3b2bca xen/arch/x86/traps.c
>>> --- a/xen/arch/x86/traps.c	Thu Nov 17 17:54:17 2011 +0800
>>> +++ b/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
>>> @@ -826,8 +826,11 @@ static void pv_cpuid(struct cpu_user_reg
>>> 
>>>      case 0x00000007:
>>>          if ( regs->ecx == 0 )
>>> -            b &= (cpufeat_mask(X86_FEATURE_FSGSBASE) |
>>> -                  cpufeat_mask(X86_FEATURE_ERMS));
>>> +            b &= (cpufeat_mask(X86_FEATURE_BMI1) |
>>> +                  cpufeat_mask(X86_FEATURE_AVX2) |
>>> +                  cpufeat_mask(X86_FEATURE_BMI2) |
>>> +                  cpufeat_mask(X86_FEATURE_ERMS) |
>>> +                  cpufeat_mask(X86_FEATURE_FSGSBASE));         
>>>              else b = 0;
>>>          a = c = d = 0;
>>> diff -r 38b25f3b2bca xen/include/asm-x86/cpufeature.h
>>> --- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 17:54:17 2011
>>> +0800 +++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01
>>>  2011 +0800 @@ -93,6 +93,7 @@ #define X86_FEATURE_TM2		(4*32+ 8) /*
>>>  Thermal Monitor 2 */ #define X86_FEATURE_SSSE3	(4*32+ 9) /*
>>>  Supplemental Streaming SIMD Extensions-3 */ #define
>>> X86_FEATURE_CID		(4*32+10) /* Context ID */ +#define
>>>  X86_FEATURE_FMA		(4*32+12) /* Fused Multiply Add */ #define
>>>  X86_FEATURE_CX16        (4*32+13) /* CMPXCHG16B */ #define
>>>  X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
>>>  #define X86_FEATURE_PDCM	(4*32+15) /* Perf/Debug Capability MSR */
>>>  @@ -100,6 +101,7 @@ #define X86_FEATURE_SSE4_1	(4*32+19) /*
>>>  Streaming SIMD Extensions 4.1 */ #define
>>> X86_FEATURE_SSE4_2	(4*32+20) /* Streaming SIMD Extensions 4.2 */
>>>  #define X86_FEATURE_X2APIC	(4*32+21) /* Extended xAPIC */ +#define
>>>  X86_FEATURE_MOVBE	(4*32+22) /* movbe instruction */ #define
>>>  X86_FEATURE_POPCNT	(4*32+23) /* POPCNT instruction */ #define
>>> X86_FEATURE_TSC_DEADLINE (4*32+24) /* "tdt" TSC Deadline Timer */
>>> #define X86_FEATURE_AES		(4*32+25) /* AES instructions */ @@ -145,7
>>> +147,10 @@   
>>> 
>>>  /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx),
>>>  word 7 */ #define X86_FEATURE_FSGSBASE	(7*32+ 0) /*
>>> {RD,WR}{FS,GS}BASE instructions */ +#define X86_FEATURE_BMI1	(7*32+
>>> 3) /* 1st bit manipulation extensions */ +#define
>>>  X86_FEATURE_AVX2	(7*32+ 5) /* AVX2 instructions */ #define
>>> X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection
>>>  */ +#define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation
>>> extensions */ #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP
>>> MOVSB/STOSB */  
>>> 
>>>  #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 10:18:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 10:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUbnl-0004NK-7G; Sun, 27 Nov 2011 10:17:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RUbnj-0004ND-Uv
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 10:17:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322389020!3238224!1
X-Originating-IP: [134.134.136.24]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24716 invoked from network); 27 Nov 2011 10:17:01 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-174.messagelabs.com with SMTP;
	27 Nov 2011 10:17:01 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 27 Nov 2011 02:17:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="80342020"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 27 Nov 2011 02:16:59 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 27 Nov 2011 18:16:58 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Sun, 27 Nov 2011 18:16:45 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Sun, 27 Nov 2011 18:16:42 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: Acyrdo7/AlFiv1sRQPeC4SdWqN6QbwBdh/Fw
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
In-Reply-To: <4ECFA6C302000078000634A1@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> X86: Disable PCID/INVPCID for dom0
>> 
>> PCID (Process-context identifier) is a facility by which a logical
>> processor may cache information for multiple linear-address spaces.
>> INVPCID is an new instruction to invalidate TLB. Refer latest Intel
>> SDM
>> http://www.intel.com/content/www/us/en/processors/architectures-software-develo
>> per-manuals.html  
>> 
>> We disable PCID/INVPCID for dom0 and pv. Exposing them into dom0 and
>> pv may result in performance regression, and it would trigger GP or
>> UD depending on whether platform suppport INVPCID or not.
>> 
>> This patch disable PCID/INVPCID for dom0.
> 
> Do we really need to disable it, rather than making it work?
> Conceptually the feature seems usable, and the instruction would
> need replacement by a hypercall anyway (just like invlpg).
> 
> Jan
> 

It's a design choice.
Exposing PCID/INVPCID to pv would involve some additional task, like coordinated PCID allocation algorithm, or change vmm vcpu context swich, which would make it complex. However, exposing PCID/INVPCID to pv has not obvious benefit or even result in performance regression. So we choose to disable PCID/INVPCID to pv.

Thanks,
Jinsong

>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r 519a0e3c982d xen/arch/x86/traps.c
>> --- a/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
>> +++ b/xen/arch/x86/traps.c	Thu Nov 17 18:41:59 2011 +0800
>> @@ -813,6 +813,7 @@ static void pv_cpuid(struct cpu_user_reg
>>              __clear_bit(X86_FEATURE_CX16 % 32, &c);
>>          __clear_bit(X86_FEATURE_XTPR % 32, &c);
>>          __clear_bit(X86_FEATURE_PDCM % 32, &c);
>> +        __clear_bit(X86_FEATURE_PCID % 32, &c);
>>          __clear_bit(X86_FEATURE_DCA % 32, &c);
>>          if ( !xsave_enabled(current) )
>>          {
>> diff -r 519a0e3c982d xen/include/asm-x86/cpufeature.h
>> --- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
>> +++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:41:59 2011
>>  +0800 @@ -97,6 +97,7 @@ #define X86_FEATURE_CX16        (4*32+13)
>>  /* CMPXCHG16B */ #define X86_FEATURE_XTPR	(4*32+14) /* Send Task
>>  Priority Messages */ #define X86_FEATURE_PDCM	(4*32+15) /*
>> Perf/Debug Capability MSR */ +#define X86_FEATURE_PCID	(4*32+17) /*
>>  Process Context ID */ #define X86_FEATURE_DCA		(4*32+18) /* Direct
>>  Cache Access */ #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming
>>  SIMD Extensions 4.1 */ #define X86_FEATURE_SSE4_2	(4*32+20) /*
>>  Streaming SIMD Extensions 4.2 */ @@ -152,6 +153,7 @@ #define
>>  X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection
>>  */ #define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation
>> extensions */ #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP
>> MOVSB/STOSB */ +#define X86_FEATURE_INVPCID	(7*32+10) /* Invalidate
>> Process Context ID */  
>> 
>>  #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
>>  #define boot_cpu_has(bit)	test_bit(bit,
>> boot_cpu_data.x86_capability) 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 10:18:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 10:18:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUbnl-0004NK-7G; Sun, 27 Nov 2011 10:17:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RUbnj-0004ND-Uv
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 10:17:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322389020!3238224!1
X-Originating-IP: [134.134.136.24]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24716 invoked from network); 27 Nov 2011 10:17:01 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-174.messagelabs.com with SMTP;
	27 Nov 2011 10:17:01 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 27 Nov 2011 02:17:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="80342020"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 27 Nov 2011 02:16:59 -0800
Received: from shsmsx602.ccr.corp.intel.com (10.239.4.104) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Sun, 27 Nov 2011 18:16:58 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	SHSMSX602.ccr.corp.intel.com ([10.239.4.104]) with mapi;
	Sun, 27 Nov 2011 18:16:45 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Sun, 27 Nov 2011 18:16:42 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: Acyrdo7/AlFiv1sRQPeC4SdWqN6QbwBdh/Fw
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
In-Reply-To: <4ECFA6C302000078000634A1@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> X86: Disable PCID/INVPCID for dom0
>> 
>> PCID (Process-context identifier) is a facility by which a logical
>> processor may cache information for multiple linear-address spaces.
>> INVPCID is an new instruction to invalidate TLB. Refer latest Intel
>> SDM
>> http://www.intel.com/content/www/us/en/processors/architectures-software-develo
>> per-manuals.html  
>> 
>> We disable PCID/INVPCID for dom0 and pv. Exposing them into dom0 and
>> pv may result in performance regression, and it would trigger GP or
>> UD depending on whether platform suppport INVPCID or not.
>> 
>> This patch disable PCID/INVPCID for dom0.
> 
> Do we really need to disable it, rather than making it work?
> Conceptually the feature seems usable, and the instruction would
> need replacement by a hypercall anyway (just like invlpg).
> 
> Jan
> 

It's a design choice.
Exposing PCID/INVPCID to pv would involve some additional task, like coordinated PCID allocation algorithm, or change vmm vcpu context swich, which would make it complex. However, exposing PCID/INVPCID to pv has not obvious benefit or even result in performance regression. So we choose to disable PCID/INVPCID to pv.

Thanks,
Jinsong

>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r 519a0e3c982d xen/arch/x86/traps.c
>> --- a/xen/arch/x86/traps.c	Thu Nov 17 18:06:01 2011 +0800
>> +++ b/xen/arch/x86/traps.c	Thu Nov 17 18:41:59 2011 +0800
>> @@ -813,6 +813,7 @@ static void pv_cpuid(struct cpu_user_reg
>>              __clear_bit(X86_FEATURE_CX16 % 32, &c);
>>          __clear_bit(X86_FEATURE_XTPR % 32, &c);
>>          __clear_bit(X86_FEATURE_PDCM % 32, &c);
>> +        __clear_bit(X86_FEATURE_PCID % 32, &c);
>>          __clear_bit(X86_FEATURE_DCA % 32, &c);
>>          if ( !xsave_enabled(current) )
>>          {
>> diff -r 519a0e3c982d xen/include/asm-x86/cpufeature.h
>> --- a/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:06:01 2011 +0800
>> +++ b/xen/include/asm-x86/cpufeature.h	Thu Nov 17 18:41:59 2011
>>  +0800 @@ -97,6 +97,7 @@ #define X86_FEATURE_CX16        (4*32+13)
>>  /* CMPXCHG16B */ #define X86_FEATURE_XTPR	(4*32+14) /* Send Task
>>  Priority Messages */ #define X86_FEATURE_PDCM	(4*32+15) /*
>> Perf/Debug Capability MSR */ +#define X86_FEATURE_PCID	(4*32+17) /*
>>  Process Context ID */ #define X86_FEATURE_DCA		(4*32+18) /* Direct
>>  Cache Access */ #define X86_FEATURE_SSE4_1	(4*32+19) /* Streaming
>>  SIMD Extensions 4.1 */ #define X86_FEATURE_SSE4_2	(4*32+20) /*
>>  Streaming SIMD Extensions 4.2 */ @@ -152,6 +153,7 @@ #define
>>  X86_FEATURE_SMEP	(7*32+ 7) /* Supervisor Mode Execution Protection
>>  */ #define X86_FEATURE_BMI2	(7*32+ 8) /* 2nd bit manipulation
>> extensions */ #define X86_FEATURE_ERMS	(7*32+ 9) /* Enhanced REP
>> MOVSB/STOSB */ +#define X86_FEATURE_INVPCID	(7*32+10) /* Invalidate
>> Process Context ID */  
>> 
>>  #define cpu_has(c, bit)		test_bit(bit, (c)->x86_capability)
>>  #define boot_cpu_has(bit)	test_bit(bit,
>> boot_cpu_data.x86_capability) 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 15:52:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 15:52:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUh0W-0007aM-50; Sun, 27 Nov 2011 15:51:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUh0U-0007aH-DN
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 15:51:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1322379422!4919636!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6313 invoked from network); 27 Nov 2011 07:37:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2011 07:37:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,578,1315180800"; 
   d="scan'208";a="9143019"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Nov 2011 07:36:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 27 Nov 2011 07:36:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUZIH-0002bE-KJ;
	Sun, 27 Nov 2011 07:36:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUZIH-0004LE-Hf;
	Sun, 27 Nov 2011 07:36:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10117-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 27 Nov 2011 07:36:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10117: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10117 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10117/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 15:52:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 15:52:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUh0W-0007aM-50; Sun, 27 Nov 2011 15:51:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUh0U-0007aH-DN
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 15:51:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1322379422!4919636!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6313 invoked from network); 27 Nov 2011 07:37:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2011 07:37:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,578,1315180800"; 
   d="scan'208";a="9143019"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Nov 2011 07:36:57 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 27 Nov 2011 07:36:57 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUZIH-0002bE-KJ;
	Sun, 27 Nov 2011 07:36:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUZIH-0004LE-Hf;
	Sun, 27 Nov 2011 07:36:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10117-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 27 Nov 2011 07:36:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10117: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10117 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10117/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 16:08:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 16:08:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUhGX-00006T-FH; Sun, 27 Nov 2011 16:07:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUhGV-000069-SE
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 16:07:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322410024!3270522!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1147 invoked from network); 27 Nov 2011 16:07:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2011 16:07:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,579,1315180800"; 
   d="scan'208";a="9144986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Nov 2011 16:06:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 27 Nov 2011 16:06:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUhFX-0005K3-T9;
	Sun, 27 Nov 2011 16:06:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUhFX-0002ls-Se;
	Sun, 27 Nov 2011 16:06:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10129-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 27 Nov 2011 16:06:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10129: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10129 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10129/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10117

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2          fail in 10117 like 9955

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 16:08:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 16:08:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUhGX-00006T-FH; Sun, 27 Nov 2011 16:07:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUhGV-000069-SE
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 16:07:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322410024!3270522!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1147 invoked from network); 27 Nov 2011 16:07:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2011 16:07:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,579,1315180800"; 
   d="scan'208";a="9144986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Nov 2011 16:06:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 27 Nov 2011 16:06:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUhFX-0005K3-T9;
	Sun, 27 Nov 2011 16:06:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUhFX-0002ls-Se;
	Sun, 27 Nov 2011 16:06:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10129-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 27 Nov 2011 16:06:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10129: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10129 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10129/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10117

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2          fail in 10117 like 9955

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 16:25:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 16:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUhWe-0000Rm-9G; Sun, 27 Nov 2011 16:24:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RUhWd-0000Rf-93
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 16:24:19 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322410979!58484605!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31569 invoked from network); 27 Nov 2011 16:22:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2011 16:22:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,579,1315180800"; 
   d="scan'208";a="9145028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Nov 2011 16:23:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 27 Nov 2011 16:23:43 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RUhW3-0005Pu-ES;
	Sun, 27 Nov 2011 16:23:43 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RUhVo-0003ID-Na;
	Sun, 27 Nov 2011 16:23:28 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Sun, 27 Nov 2011 16:23:26 +0000
Message-ID: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Ian.Jackson@eu.citrix.com, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
	fix OpRegion mapping.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


The OpRegion shouldn't be mapped 1:1 because the address in the host
can't be used in the guest directly.

This patch traps read and write access to the opregion of the Intel
GPU config space (offset 0xfc).

To work correctly this patch needs a change in hvmloader.

HVMloader will allocate 2 pages for the OpRegion and write this address
on the config space of the Intel GPU. Qemu will trap and map the host
OpRegion to the guest. Any write to this offset after that won't have
any effect. Any read of this config space offset will return the address
in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |    8 ++--
 hw/pass-through.h |    4 ++
 hw/pt-graphics.c  |   96 ++++++++++++++++++++++++++++++++++++++++++----------
 3 files changed, 85 insertions(+), 23 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 919937f..976d28f 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -1455,8 +1455,7 @@ out:
     return index;
 }
 
-static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
-                                int len)
+void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len)
 {
     struct pt_dev *assigned_device = (struct pt_dev *)d;
     struct pci_dev *pci_dev = assigned_device->pci_dev;
@@ -1637,7 +1636,7 @@ exit:
     return;
 }
 
-static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
+uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
 {
     struct pt_dev *assigned_device = (struct pt_dev *)d;
     struct pci_dev *pci_dev = assigned_device->pci_dev;
@@ -4191,7 +4190,8 @@ static struct pt_dev * register_real_device(PCIBus *e_bus,
     /* Register device */
     assigned_device = (struct pt_dev *) pci_register_device(e_bus, e_dev_name,
                                 sizeof(struct pt_dev), e_devfn,
-                                pt_pci_read_config, pt_pci_write_config);
+                                gfx_passthru ? vgapt_pci_read_config : pt_pci_read_config,
+                                gfx_passthru ? vgapt_pci_write_config : pt_pci_write_config);
     if ( assigned_device == NULL )
     {
         PT_LOG("Error: couldn't register real device\n");
diff --git a/hw/pass-through.h b/hw/pass-through.h
index 884139c..c898c7c 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -422,6 +422,10 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
            uint16_t did, const char *name, uint16_t revision);
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
+void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
+uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len);
+uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len);
+void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len);
 
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..33cbff5 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -13,6 +13,8 @@
 extern int gfx_passthru;
 extern int igd_passthru;
 
+static uint32_t igd_guest_opregion = 0;
+
 static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
 {
     PT_LOG("pch_map_irq called\n");
@@ -37,6 +39,77 @@ void intel_pch_init(PCIBus *bus)
                         pch_map_irq, "intel_bridge_1f");
 }
 
+static void igd_write_opregion(PCIDevice *pci_dev, uint32_t val, int len)
+{
+    struct pt_dev *real_dev = (struct pt_dev *)pci_dev;
+    uint32_t host_opregion = 0;
+    int ret;
+
+    if ( igd_guest_opregion || len != 4 )
+        return;
+
+    host_opregion = pt_pci_host_read(real_dev->pci_dev,
+            PCI_INTEL_OPREGION, len);
+    igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff);
+    PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opregion);
+
+    ret = xc_domain_memory_mapping(xc_handle, domid,
+            igd_guest_opregion >> XC_PAGE_SHIFT,
+            host_opregion >> XC_PAGE_SHIFT,
+            2,
+            DPCI_ADD_MAPPING);
+
+    if ( ret != 0 )
+    {
+        PT_LOG("Error: Can't map opregion\n");
+        igd_guest_opregion = 0;
+    }
+}
+
+void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
+{
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG("vgapt_pci_write_config: %x:%x.%x: addr=%x len=%x val=%x\n",
+            pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
+            PCI_FUNC(pci_dev->devfn), config_addr, len, val);
+#endif
+
+    if ( igd_passthru )
+    {
+        switch ( config_addr )
+        {
+            case 0xfc : /* Opregion */
+                igd_write_opregion(pci_dev, val, len);
+                return;
+        }
+    }
+
+    pt_pci_write_config(pci_dev, config_addr, val, len);
+}
+
+uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len)
+{
+    uint32_t val;
+
+    val = pt_pci_read_config(pci_dev, config_addr, len);
+
+    if ( igd_passthru )
+    {
+        switch ( config_addr )
+        {
+            case 0xfc: /* OpRegion */
+                if ( igd_guest_opregion )
+                    val = igd_guest_opregion;
+                break;
+        }
+    }
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "vgapt_pci_read_config: %x:%x.%x: addr=%x len=%x val=%x\n",
+            config_addr, len, val);
+#endif
+    return val;
+}
+
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -99,7 +172,6 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 int register_vga_regions(struct pt_dev *real_device)
 {
     u16 vendor_id;
-    int igd_opregion;
     int ret = 0;
 
     if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
@@ -117,19 +189,6 @@ int register_vga_regions(struct pt_dev *real_device)
             0x20,
             DPCI_ADD_MAPPING);
 
-    /* 1:1 map ASL Storage register value */
-    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
-    if ( (vendor_id == PCI_VENDOR_ID_INTEL ) && igd_opregion )
-    {
-        ret |= xc_domain_memory_mapping(xc_handle, domid,
-                igd_opregion >> XC_PAGE_SHIFT,
-                igd_opregion >> XC_PAGE_SHIFT,
-                2,
-                DPCI_ADD_MAPPING);
-        PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
-    }
-
     if ( ret != 0 )
         PT_LOG("VGA region mapping failed\n");
 
@@ -141,7 +200,7 @@ int register_vga_regions(struct pt_dev *real_device)
  */
 int unregister_vga_regions(struct pt_dev *real_device)
 {
-    u32 vendor_id, igd_opregion;
+    u32 vendor_id;
     int ret = 0;
 
     if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
@@ -160,12 +219,11 @@ int unregister_vga_regions(struct pt_dev *real_device)
             DPCI_REMOVE_MAPPING);
 
     vendor_id = pt_pci_host_read(real_device->pci_dev, PCI_VENDOR_ID, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
-    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_opregion )
+    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_guest_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,
-                igd_opregion >> XC_PAGE_SHIFT,
-                igd_opregion >> XC_PAGE_SHIFT,
+                igd_guest_opregion >> XC_PAGE_SHIFT,
+                igd_guest_opregion >> XC_PAGE_SHIFT,
                 2,
                 DPCI_REMOVE_MAPPING);
     }

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Sun Nov 27 16:25:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 16:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUhWe-0000Rm-9G; Sun, 27 Nov 2011 16:24:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RUhWd-0000Rf-93
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 16:24:19 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322410979!58484605!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31569 invoked from network); 27 Nov 2011 16:22:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2011 16:22:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,579,1315180800"; 
   d="scan'208";a="9145028"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Nov 2011 16:23:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 27 Nov 2011 16:23:43 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RUhW3-0005Pu-ES;
	Sun, 27 Nov 2011 16:23:43 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RUhVo-0003ID-Na;
	Sun, 27 Nov 2011 16:23:28 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Sun, 27 Nov 2011 16:23:26 +0000
Message-ID: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Ian.Jackson@eu.citrix.com, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
	fix OpRegion mapping.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


The OpRegion shouldn't be mapped 1:1 because the address in the host
can't be used in the guest directly.

This patch traps read and write access to the opregion of the Intel
GPU config space (offset 0xfc).

To work correctly this patch needs a change in hvmloader.

HVMloader will allocate 2 pages for the OpRegion and write this address
on the config space of the Intel GPU. Qemu will trap and map the host
OpRegion to the guest. Any write to this offset after that won't have
any effect. Any read of this config space offset will return the address
in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |    8 ++--
 hw/pass-through.h |    4 ++
 hw/pt-graphics.c  |   96 ++++++++++++++++++++++++++++++++++++++++++----------
 3 files changed, 85 insertions(+), 23 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 919937f..976d28f 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -1455,8 +1455,7 @@ out:
     return index;
 }
 
-static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val,
-                                int len)
+void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len)
 {
     struct pt_dev *assigned_device = (struct pt_dev *)d;
     struct pci_dev *pci_dev = assigned_device->pci_dev;
@@ -1637,7 +1636,7 @@ exit:
     return;
 }
 
-static uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
+uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len)
 {
     struct pt_dev *assigned_device = (struct pt_dev *)d;
     struct pci_dev *pci_dev = assigned_device->pci_dev;
@@ -4191,7 +4190,8 @@ static struct pt_dev * register_real_device(PCIBus *e_bus,
     /* Register device */
     assigned_device = (struct pt_dev *) pci_register_device(e_bus, e_dev_name,
                                 sizeof(struct pt_dev), e_devfn,
-                                pt_pci_read_config, pt_pci_write_config);
+                                gfx_passthru ? vgapt_pci_read_config : pt_pci_read_config,
+                                gfx_passthru ? vgapt_pci_write_config : pt_pci_write_config);
     if ( assigned_device == NULL )
     {
         PT_LOG("Error: couldn't register real device\n");
diff --git a/hw/pass-through.h b/hw/pass-through.h
index 884139c..c898c7c 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -422,6 +422,10 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
            uint16_t did, const char *name, uint16_t revision);
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
+void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
+uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len);
+uint32_t pt_pci_read_config(PCIDevice *d, uint32_t address, int len);
+void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, int len);
 
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..33cbff5 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -13,6 +13,8 @@
 extern int gfx_passthru;
 extern int igd_passthru;
 
+static uint32_t igd_guest_opregion = 0;
+
 static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
 {
     PT_LOG("pch_map_irq called\n");
@@ -37,6 +39,77 @@ void intel_pch_init(PCIBus *bus)
                         pch_map_irq, "intel_bridge_1f");
 }
 
+static void igd_write_opregion(PCIDevice *pci_dev, uint32_t val, int len)
+{
+    struct pt_dev *real_dev = (struct pt_dev *)pci_dev;
+    uint32_t host_opregion = 0;
+    int ret;
+
+    if ( igd_guest_opregion || len != 4 )
+        return;
+
+    host_opregion = pt_pci_host_read(real_dev->pci_dev,
+            PCI_INTEL_OPREGION, len);
+    igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff);
+    PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opregion);
+
+    ret = xc_domain_memory_mapping(xc_handle, domid,
+            igd_guest_opregion >> XC_PAGE_SHIFT,
+            host_opregion >> XC_PAGE_SHIFT,
+            2,
+            DPCI_ADD_MAPPING);
+
+    if ( ret != 0 )
+    {
+        PT_LOG("Error: Can't map opregion\n");
+        igd_guest_opregion = 0;
+    }
+}
+
+void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
+{
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG("vgapt_pci_write_config: %x:%x.%x: addr=%x len=%x val=%x\n",
+            pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->devfn),
+            PCI_FUNC(pci_dev->devfn), config_addr, len, val);
+#endif
+
+    if ( igd_passthru )
+    {
+        switch ( config_addr )
+        {
+            case 0xfc : /* Opregion */
+                igd_write_opregion(pci_dev, val, len);
+                return;
+        }
+    }
+
+    pt_pci_write_config(pci_dev, config_addr, val, len);
+}
+
+uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr, int len)
+{
+    uint32_t val;
+
+    val = pt_pci_read_config(pci_dev, config_addr, len);
+
+    if ( igd_passthru )
+    {
+        switch ( config_addr )
+        {
+            case 0xfc: /* OpRegion */
+                if ( igd_guest_opregion )
+                    val = igd_guest_opregion;
+                break;
+        }
+    }
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "vgapt_pci_read_config: %x:%x.%x: addr=%x len=%x val=%x\n",
+            config_addr, len, val);
+#endif
+    return val;
+}
+
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -99,7 +172,6 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 int register_vga_regions(struct pt_dev *real_device)
 {
     u16 vendor_id;
-    int igd_opregion;
     int ret = 0;
 
     if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
@@ -117,19 +189,6 @@ int register_vga_regions(struct pt_dev *real_device)
             0x20,
             DPCI_ADD_MAPPING);
 
-    /* 1:1 map ASL Storage register value */
-    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
-    if ( (vendor_id == PCI_VENDOR_ID_INTEL ) && igd_opregion )
-    {
-        ret |= xc_domain_memory_mapping(xc_handle, domid,
-                igd_opregion >> XC_PAGE_SHIFT,
-                igd_opregion >> XC_PAGE_SHIFT,
-                2,
-                DPCI_ADD_MAPPING);
-        PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
-    }
-
     if ( ret != 0 )
         PT_LOG("VGA region mapping failed\n");
 
@@ -141,7 +200,7 @@ int register_vga_regions(struct pt_dev *real_device)
  */
 int unregister_vga_regions(struct pt_dev *real_device)
 {
-    u32 vendor_id, igd_opregion;
+    u32 vendor_id;
     int ret = 0;
 
     if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
@@ -160,12 +219,11 @@ int unregister_vga_regions(struct pt_dev *real_device)
             DPCI_REMOVE_MAPPING);
 
     vendor_id = pt_pci_host_read(real_device->pci_dev, PCI_VENDOR_ID, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
-    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_opregion )
+    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_guest_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,
-                igd_opregion >> XC_PAGE_SHIFT,
-                igd_opregion >> XC_PAGE_SHIFT,
+                igd_guest_opregion >> XC_PAGE_SHIFT,
+                igd_guest_opregion >> XC_PAGE_SHIFT,
                 2,
                 DPCI_REMOVE_MAPPING);
     }

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Sun Nov 27 20:36:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 20:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUlRk-00033e-3g; Sun, 27 Nov 2011 20:35:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUlRi-00033Z-4L
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 20:35:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322426094!3271329!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 355 invoked from network); 27 Nov 2011 20:34:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2011 20:34:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,579,1315180800"; 
   d="scan'208";a="9145962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Nov 2011 20:34:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 27 Nov 2011 20:34:54 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUlR8-0006lW-Em;
	Sun, 27 Nov 2011 20:34:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUlR8-00062m-Co;
	Sun, 27 Nov 2011 20:34:54 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10132-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 27 Nov 2011 20:34:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10132: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10132 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10132/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 10117

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2          fail in 10117 like 9955

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 20:36:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 20:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUlRk-00033e-3g; Sun, 27 Nov 2011 20:35:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUlRi-00033Z-4L
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 20:35:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322426094!3271329!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 355 invoked from network); 27 Nov 2011 20:34:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Nov 2011 20:34:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,579,1315180800"; 
   d="scan'208";a="9145962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Nov 2011 20:34:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 27 Nov 2011 20:34:54 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUlR8-0006lW-Em;
	Sun, 27 Nov 2011 20:34:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUlR8-00062m-Co;
	Sun, 27 Nov 2011 20:34:54 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10132-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 27 Nov 2011 20:34:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10132: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10132 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10132/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 10117

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2          fail in 10117 like 9955

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmtI-0003yn-Jz; Sun, 27 Nov 2011 22:08:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmtG-0003yJ-Rb
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:08:03 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322431646!5165384!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22886 invoked from network); 27 Nov 2011 22:07:27 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2011 22:07:27 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 90B8F540FF; Sun, 27 Nov 2011 23:07:26 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:04 +0100
Message-Id: <1322431628-21760-2-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
Cc: Bastian Blank <waldi@debian.org>
Subject: [Xen-devel] [PATCH 1/5] xen/sys/hypervisor: Export
	guest_properties/is_initial_domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/sys-hypervisor.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 1e0fe01..d0916e8 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -355,6 +355,35 @@ static void xen_properties_destroy(void)
 	sysfs_remove_group(hypervisor_kobj, &xen_properties_group);
 }
 
+/* xen guest properties info */
+
+static ssize_t is_initial_domain_show(struct hyp_sysfs_attr *attr, char *buffer)
+{
+	return sprintf(buffer, "%d\n", xen_initial_domain());
+}
+
+HYPERVISOR_ATTR_RO(is_initial_domain);
+
+static struct attribute *xen_guest_properties_attrs[] = {
+	&is_initial_domain_attr.attr,
+	NULL
+};
+
+static struct attribute_group xen_guest_properties_group = {
+	.name = "guest_properties",
+	.attrs = xen_guest_properties_attrs,
+};
+
+static int __init xen_guest_properties_init(void)
+{
+	return sysfs_create_group(hypervisor_kobj, &xen_guest_properties_group);
+}
+
+static void xen_guest_properties_destroy(void)
+{
+	sysfs_remove_group(hypervisor_kobj, &xen_guest_properties_group);
+}
+
 static int __init hyper_sysfs_init(void)
 {
 	int ret;
@@ -377,9 +406,14 @@ static int __init hyper_sysfs_init(void)
 	ret = xen_properties_init();
 	if (ret)
 		goto prop_out;
+	ret = xen_guest_properties_init();
+	if (ret)
+		goto gprop_out;
 
 	goto out;
 
+gprop_out:
+	xen_properties_destroy();
 prop_out:
 	xen_sysfs_uuid_destroy();
 uuid_out:
@@ -394,6 +428,7 @@ out:
 
 static void __exit hyper_sysfs_exit(void)
 {
+	xen_guest_properties_destroy();
 	xen_properties_destroy();
 	xen_compilation_destroy();
 	xen_sysfs_uuid_destroy();
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmt7-0003yC-Eu; Sun, 27 Nov 2011 22:07:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmt5-0003y7-K1
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:07:51 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322431635!4803922!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3541 invoked from network); 27 Nov 2011 22:07:16 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2011 22:07:16 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id A739A540FF; Sun, 27 Nov 2011 23:07:14 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:03 +0100
Message-Id: <1322431628-21760-1-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
Subject: [Xen-devel] [PATCH 0/5] Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Over a year ago I started a discussion about xenfs. This is the first
try to add the stuff in xenfs as regular devices and a sysfs file.

Patches for xen tools will follow.

Bastian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmt7-0003yC-Eu; Sun, 27 Nov 2011 22:07:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmt5-0003y7-K1
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:07:51 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322431635!4803922!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3541 invoked from network); 27 Nov 2011 22:07:16 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2011 22:07:16 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id A739A540FF; Sun, 27 Nov 2011 23:07:14 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:03 +0100
Message-Id: <1322431628-21760-1-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
Subject: [Xen-devel] [PATCH 0/5] Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Over a year ago I started a discussion about xenfs. This is the first
try to add the stuff in xenfs as regular devices and a sysfs file.

Patches for xen tools will follow.

Bastian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmtI-0003yn-Jz; Sun, 27 Nov 2011 22:08:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmtG-0003yJ-Rb
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:08:03 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322431646!5165384!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22886 invoked from network); 27 Nov 2011 22:07:27 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2011 22:07:27 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 90B8F540FF; Sun, 27 Nov 2011 23:07:26 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:04 +0100
Message-Id: <1322431628-21760-2-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
Cc: Bastian Blank <waldi@debian.org>
Subject: [Xen-devel] [PATCH 1/5] xen/sys/hypervisor: Export
	guest_properties/is_initial_domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/sys-hypervisor.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 1e0fe01..d0916e8 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -355,6 +355,35 @@ static void xen_properties_destroy(void)
 	sysfs_remove_group(hypervisor_kobj, &xen_properties_group);
 }
 
+/* xen guest properties info */
+
+static ssize_t is_initial_domain_show(struct hyp_sysfs_attr *attr, char *buffer)
+{
+	return sprintf(buffer, "%d\n", xen_initial_domain());
+}
+
+HYPERVISOR_ATTR_RO(is_initial_domain);
+
+static struct attribute *xen_guest_properties_attrs[] = {
+	&is_initial_domain_attr.attr,
+	NULL
+};
+
+static struct attribute_group xen_guest_properties_group = {
+	.name = "guest_properties",
+	.attrs = xen_guest_properties_attrs,
+};
+
+static int __init xen_guest_properties_init(void)
+{
+	return sysfs_create_group(hypervisor_kobj, &xen_guest_properties_group);
+}
+
+static void xen_guest_properties_destroy(void)
+{
+	sysfs_remove_group(hypervisor_kobj, &xen_guest_properties_group);
+}
+
 static int __init hyper_sysfs_init(void)
 {
 	int ret;
@@ -377,9 +406,14 @@ static int __init hyper_sysfs_init(void)
 	ret = xen_properties_init();
 	if (ret)
 		goto prop_out;
+	ret = xen_guest_properties_init();
+	if (ret)
+		goto gprop_out;
 
 	goto out;
 
+gprop_out:
+	xen_properties_destroy();
 prop_out:
 	xen_sysfs_uuid_destroy();
 uuid_out:
@@ -394,6 +428,7 @@ out:
 
 static void __exit hyper_sysfs_exit(void)
 {
+	xen_guest_properties_destroy();
 	xen_properties_destroy();
 	xen_compilation_destroy();
 	xen_sysfs_uuid_destroy();
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmtK-0003z9-2C; Sun, 27 Nov 2011 22:08:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmtI-0003yL-Az
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:08:04 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322431648!4870618!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20367 invoked from network); 27 Nov 2011 22:07:29 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2011 22:07:29 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 1B711540FF; Sun, 27 Nov 2011 23:07:28 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:06 +0100
Message-Id: <1322431628-21760-4-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
Cc: Bastian Blank <waldi@debian.org>
Subject: [Xen-devel] [PATCH 3/5] xen/privcmd: Remove unused support for arch
	specific privcmp mmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

---
 drivers/xen/privcmd.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 863fbd0..c13d26a 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -365,7 +365,6 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
-#ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -398,7 +397,6 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
 	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
 }
-#endif
 
 const struct file_operations xen_privcmd_fops = {
 	.owner = THIS_MODULE,
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmtK-0003z9-2C; Sun, 27 Nov 2011 22:08:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmtI-0003yL-Az
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:08:04 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322431648!4870618!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20367 invoked from network); 27 Nov 2011 22:07:29 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2011 22:07:29 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 1B711540FF; Sun, 27 Nov 2011 23:07:28 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:06 +0100
Message-Id: <1322431628-21760-4-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
Cc: Bastian Blank <waldi@debian.org>
Subject: [Xen-devel] [PATCH 3/5] xen/privcmd: Remove unused support for arch
	specific privcmp mmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

---
 drivers/xen/privcmd.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 863fbd0..c13d26a 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -365,7 +365,6 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
-#ifndef HAVE_ARCH_PRIVCMD_MMAP
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -398,7 +397,6 @@ static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
 {
 	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
 }
-#endif
 
 const struct file_operations xen_privcmd_fops = {
 	.owner = THIS_MODULE,
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmtE-0003yR-6k; Sun, 27 Nov 2011 22:08:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmtD-0003yK-0y
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:07:59 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322431632!47281271!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32752 invoked from network); 27 Nov 2011 22:07:12 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2011 22:07:12 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 783955415A; Sun, 27 Nov 2011 23:07:27 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:05 +0100
Message-Id: <1322431628-21760-3-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
Cc: Bastian Blank <waldi@debian.org>
Subject: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to arbitrary hypercalls is currently provided via xenfs. This
adds a standard character device to handle this. The support in xenfs
remains for backward compatibility and uses the device driver code.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/Kconfig         |    7 +
 drivers/xen/Makefile        |    2 +
 drivers/xen/privcmd.c       |  437 +++++++++++++++++++++++++++++++++++++++++++
 drivers/xen/privcmd.h       |    3 +
 drivers/xen/xenfs/Makefile  |    2 +-
 drivers/xen/xenfs/privcmd.c |  400 ---------------------------------------
 drivers/xen/xenfs/super.c   |    3 +-
 drivers/xen/xenfs/xenfs.h   |    1 -
 8 files changed, 452 insertions(+), 403 deletions(-)
 create mode 100644 drivers/xen/privcmd.c
 create mode 100644 drivers/xen/privcmd.h
 delete mode 100644 drivers/xen/xenfs/privcmd.c

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 5f7ff8e..eb7574c 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -86,6 +86,7 @@ config XEN_BACKEND
 
 config XENFS
 	tristate "Xen filesystem"
+	select XEN_PRIVCMD
 	default y
 	help
 	  The xen filesystem provides a way for domains to share
@@ -181,4 +182,10 @@ config XEN_PCIDEV_BACKEND
 	  xen-pciback.hide=(03:00.0)(04:00.0)
 
 	  If in doubt, say m.
+
+config XEN_PRIVCMD
+	tristate
+	depends on XEN_DOM0
+	default m
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 72bbb27..c35f65d 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -19,9 +19,11 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
+obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
 
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
+xen-privcmd-y				:= privcmd.o
 
 xen-platform-pci-y			:= platform-pci.o
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
new file mode 100644
index 0000000..863fbd0
--- /dev/null
+++ b/drivers/xen/privcmd.c
@@ -0,0 +1,437 @@
+/******************************************************************************
+ * privcmd.c
+ *
+ * Interface to privileged domain-0 commands.
+ *
+ * Copyright (c) 2002-2004, K A Fraser, B Dragovic
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/errno.h>
+#include <linux/mm.h>
+#include <linux/mman.h>
+#include <linux/uaccess.h>
+#include <linux/swap.h>
+#include <linux/highmem.h>
+#include <linux/pagemap.h>
+#include <linux/seq_file.h>
+#include <linux/miscdevice.h>
+
+#include <asm/pgalloc.h>
+#include <asm/pgtable.h>
+#include <asm/tlb.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+#include <xen/xen.h>
+#include <xen/privcmd.h>
+#include <xen/interface/xen.h>
+#include <xen/features.h>
+#include <xen/page.h>
+#include <xen/xen-ops.h>
+
+#include "privcmd.h"
+
+MODULE_LICENSE("GPL");
+
+#ifndef HAVE_ARCH_PRIVCMD_MMAP
+static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
+#endif
+
+static long privcmd_ioctl_hypercall(void __user *udata)
+{
+	struct privcmd_hypercall hypercall;
+	long ret;
+
+	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
+		return -EFAULT;
+
+	ret = privcmd_call(hypercall.op,
+			   hypercall.arg[0], hypercall.arg[1],
+			   hypercall.arg[2], hypercall.arg[3],
+			   hypercall.arg[4]);
+
+	return ret;
+}
+
+static void free_page_list(struct list_head *pages)
+{
+	struct page *p, *n;
+
+	list_for_each_entry_safe(p, n, pages, lru)
+		__free_page(p);
+
+	INIT_LIST_HEAD(pages);
+}
+
+/*
+ * Given an array of items in userspace, return a list of pages
+ * containing the data.  If copying fails, either because of memory
+ * allocation failure or a problem reading user memory, return an
+ * error code; its up to the caller to dispose of any partial list.
+ */
+static int gather_array(struct list_head *pagelist,
+			unsigned nelem, size_t size,
+			void __user *data)
+{
+	unsigned pageidx;
+	void *pagedata;
+	int ret;
+
+	if (size > PAGE_SIZE)
+		return 0;
+
+	pageidx = PAGE_SIZE;
+	pagedata = NULL;	/* quiet, gcc */
+	while (nelem--) {
+		if (pageidx > PAGE_SIZE-size) {
+			struct page *page = alloc_page(GFP_KERNEL);
+
+			ret = -ENOMEM;
+			if (page == NULL)
+				goto fail;
+
+			pagedata = page_address(page);
+
+			list_add_tail(&page->lru, pagelist);
+			pageidx = 0;
+		}
+
+		ret = -EFAULT;
+		if (copy_from_user(pagedata + pageidx, data, size))
+			goto fail;
+
+		data += size;
+		pageidx += size;
+	}
+
+	ret = 0;
+
+fail:
+	return ret;
+}
+
+/*
+ * Call function "fn" on each element of the array fragmented
+ * over a list of pages.
+ */
+static int traverse_pages(unsigned nelem, size_t size,
+			  struct list_head *pos,
+			  int (*fn)(void *data, void *state),
+			  void *state)
+{
+	void *pagedata;
+	unsigned pageidx;
+	int ret = 0;
+
+	BUG_ON(size > PAGE_SIZE);
+
+	pageidx = PAGE_SIZE;
+	pagedata = NULL;	/* hush, gcc */
+
+	while (nelem--) {
+		if (pageidx > PAGE_SIZE-size) {
+			struct page *page;
+			pos = pos->next;
+			page = list_entry(pos, struct page, lru);
+			pagedata = page_address(page);
+			pageidx = 0;
+		}
+
+		ret = (*fn)(pagedata + pageidx, state);
+		if (ret)
+			break;
+		pageidx += size;
+	}
+
+	return ret;
+}
+
+struct mmap_mfn_state {
+	unsigned long va;
+	struct vm_area_struct *vma;
+	domid_t domain;
+};
+
+static int mmap_mfn_range(void *data, void *state)
+{
+	struct privcmd_mmap_entry *msg = data;
+	struct mmap_mfn_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	int rc;
+
+	/* Do not allow range to wrap the address space. */
+	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
+	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
+		return -EINVAL;
+
+	/* Range chunks must be contiguous in va space. */
+	if ((msg->va != st->va) ||
+	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
+		return -EINVAL;
+
+	rc = xen_remap_domain_mfn_range(vma,
+					msg->va & PAGE_MASK,
+					msg->mfn, msg->npages,
+					vma->vm_page_prot,
+					st->domain);
+	if (rc < 0)
+		return rc;
+
+	st->va += msg->npages << PAGE_SHIFT;
+
+	return 0;
+}
+
+static long privcmd_ioctl_mmap(void __user *udata)
+{
+	struct privcmd_mmap mmapcmd;
+	struct mm_struct *mm = current->mm;
+	struct vm_area_struct *vma;
+	int rc;
+	LIST_HEAD(pagelist);
+	struct mmap_mfn_state state;
+
+	if (!xen_initial_domain())
+		return -EPERM;
+
+	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
+		return -EFAULT;
+
+	rc = gather_array(&pagelist,
+			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
+			  mmapcmd.entry);
+
+	if (rc || list_empty(&pagelist))
+		goto out;
+
+	down_write(&mm->mmap_sem);
+
+	{
+		struct page *page = list_first_entry(&pagelist,
+						     struct page, lru);
+		struct privcmd_mmap_entry *msg = page_address(page);
+
+		vma = find_vma(mm, msg->va);
+		rc = -EINVAL;
+
+		if (!vma || (msg->va != vma->vm_start) ||
+		    !privcmd_enforce_singleshot_mapping(vma))
+			goto out_up;
+	}
+
+	state.va = vma->vm_start;
+	state.vma = vma;
+	state.domain = mmapcmd.dom;
+
+	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
+			    &pagelist,
+			    mmap_mfn_range, &state);
+
+
+out_up:
+	up_write(&mm->mmap_sem);
+
+out:
+	free_page_list(&pagelist);
+
+	return rc;
+}
+
+struct mmap_batch_state {
+	domid_t domain;
+	unsigned long va;
+	struct vm_area_struct *vma;
+	int err;
+
+	xen_pfn_t __user *user;
+};
+
+static int mmap_batch_fn(void *data, void *state)
+{
+	xen_pfn_t *mfnp = data;
+	struct mmap_batch_state *st = state;
+
+	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
+				       st->vma->vm_page_prot, st->domain) < 0) {
+		*mfnp |= 0xf0000000U;
+		st->err++;
+	}
+	st->va += PAGE_SIZE;
+
+	return 0;
+}
+
+static int mmap_return_errors(void *data, void *state)
+{
+	xen_pfn_t *mfnp = data;
+	struct mmap_batch_state *st = state;
+
+	return put_user(*mfnp, st->user++);
+}
+
+static struct vm_operations_struct privcmd_vm_ops;
+
+static long privcmd_ioctl_mmap_batch(void __user *udata)
+{
+	int ret;
+	struct privcmd_mmapbatch m;
+	struct mm_struct *mm = current->mm;
+	struct vm_area_struct *vma;
+	unsigned long nr_pages;
+	LIST_HEAD(pagelist);
+	struct mmap_batch_state state;
+
+	if (!xen_initial_domain())
+		return -EPERM;
+
+	if (copy_from_user(&m, udata, sizeof(m)))
+		return -EFAULT;
+
+	nr_pages = m.num;
+	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
+		return -EINVAL;
+
+	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
+			   m.arr);
+
+	if (ret || list_empty(&pagelist))
+		goto out;
+
+	down_write(&mm->mmap_sem);
+
+	vma = find_vma(mm, m.addr);
+	ret = -EINVAL;
+	if (!vma ||
+	    vma->vm_ops != &privcmd_vm_ops ||
+	    (m.addr != vma->vm_start) ||
+	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
+	    !privcmd_enforce_singleshot_mapping(vma)) {
+		up_write(&mm->mmap_sem);
+		goto out;
+	}
+
+	state.domain = m.dom;
+	state.vma = vma;
+	state.va = m.addr;
+	state.err = 0;
+
+	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
+			     &pagelist, mmap_batch_fn, &state);
+
+	up_write(&mm->mmap_sem);
+
+	if (state.err > 0) {
+		state.user = m.arr;
+		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
+			       &pagelist,
+			       mmap_return_errors, &state);
+	}
+
+out:
+	free_page_list(&pagelist);
+
+	return ret;
+}
+
+static long privcmd_ioctl(struct file *file,
+			  unsigned int cmd, unsigned long data)
+{
+	int ret = -ENOSYS;
+	void __user *udata = (void __user *) data;
+
+	switch (cmd) {
+	case IOCTL_PRIVCMD_HYPERCALL:
+		ret = privcmd_ioctl_hypercall(udata);
+		break;
+
+	case IOCTL_PRIVCMD_MMAP:
+		ret = privcmd_ioctl_mmap(udata);
+		break;
+
+	case IOCTL_PRIVCMD_MMAPBATCH:
+		ret = privcmd_ioctl_mmap_batch(udata);
+		break;
+
+	default:
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
+#ifndef HAVE_ARCH_PRIVCMD_MMAP
+static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
+{
+	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
+	       vma, vma->vm_start, vma->vm_end,
+	       vmf->pgoff, vmf->virtual_address);
+
+	return VM_FAULT_SIGBUS;
+}
+
+static struct vm_operations_struct privcmd_vm_ops = {
+	.fault = privcmd_fault
+};
+
+static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	/* Unsupported for auto-translate guests. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
+	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
+	 * how to recreate these mappings */
+	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
+	vma->vm_ops = &privcmd_vm_ops;
+	vma->vm_private_data = NULL;
+
+	return 0;
+}
+
+static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
+{
+	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
+}
+#endif
+
+const struct file_operations xen_privcmd_fops = {
+	.owner = THIS_MODULE,
+	.unlocked_ioctl = privcmd_ioctl,
+	.mmap = privcmd_mmap,
+};
+EXPORT_SYMBOL_GPL(xen_privcmd_fops);
+
+static struct miscdevice privcmd_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/privcmd",
+	.fops = &xen_privcmd_fops,
+};
+
+static int __init privcmd_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&privcmd_dev);
+	if (err != 0) {
+		printk(KERN_ERR "Could not register privcmd device\n");
+		return err;
+	}
+	return 0;
+}
+
+static void __exit privcmd_exit(void)
+{
+	misc_deregister(&privcmd_dev);
+}
+
+module_init(privcmd_init);
+module_exit(privcmd_exit);
diff --git a/drivers/xen/privcmd.h b/drivers/xen/privcmd.h
new file mode 100644
index 0000000..14facae
--- /dev/null
+++ b/drivers/xen/privcmd.h
@@ -0,0 +1,3 @@
+#include <linux/fs.h>
+
+extern const struct file_operations xen_privcmd_fops;
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 4fde944..5d45ff1 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o privcmd.o
+xenfs-y			  = super.o xenbus.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
deleted file mode 100644
index dbd3b16..0000000
--- a/drivers/xen/xenfs/privcmd.c
+++ /dev/null
@@ -1,400 +0,0 @@
-/******************************************************************************
- * privcmd.c
- *
- * Interface to privileged domain-0 commands.
- *
- * Copyright (c) 2002-2004, K A Fraser, B Dragovic
- */
-
-#include <linux/kernel.h>
-#include <linux/sched.h>
-#include <linux/slab.h>
-#include <linux/string.h>
-#include <linux/errno.h>
-#include <linux/mm.h>
-#include <linux/mman.h>
-#include <linux/uaccess.h>
-#include <linux/swap.h>
-#include <linux/highmem.h>
-#include <linux/pagemap.h>
-#include <linux/seq_file.h>
-
-#include <asm/pgalloc.h>
-#include <asm/pgtable.h>
-#include <asm/tlb.h>
-#include <asm/xen/hypervisor.h>
-#include <asm/xen/hypercall.h>
-
-#include <xen/xen.h>
-#include <xen/privcmd.h>
-#include <xen/interface/xen.h>
-#include <xen/features.h>
-#include <xen/page.h>
-#include <xen/xen-ops.h>
-
-#ifndef HAVE_ARCH_PRIVCMD_MMAP
-static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
-#endif
-
-static long privcmd_ioctl_hypercall(void __user *udata)
-{
-	struct privcmd_hypercall hypercall;
-	long ret;
-
-	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
-		return -EFAULT;
-
-	ret = privcmd_call(hypercall.op,
-			   hypercall.arg[0], hypercall.arg[1],
-			   hypercall.arg[2], hypercall.arg[3],
-			   hypercall.arg[4]);
-
-	return ret;
-}
-
-static void free_page_list(struct list_head *pages)
-{
-	struct page *p, *n;
-
-	list_for_each_entry_safe(p, n, pages, lru)
-		__free_page(p);
-
-	INIT_LIST_HEAD(pages);
-}
-
-/*
- * Given an array of items in userspace, return a list of pages
- * containing the data.  If copying fails, either because of memory
- * allocation failure or a problem reading user memory, return an
- * error code; its up to the caller to dispose of any partial list.
- */
-static int gather_array(struct list_head *pagelist,
-			unsigned nelem, size_t size,
-			void __user *data)
-{
-	unsigned pageidx;
-	void *pagedata;
-	int ret;
-
-	if (size > PAGE_SIZE)
-		return 0;
-
-	pageidx = PAGE_SIZE;
-	pagedata = NULL;	/* quiet, gcc */
-	while (nelem--) {
-		if (pageidx > PAGE_SIZE-size) {
-			struct page *page = alloc_page(GFP_KERNEL);
-
-			ret = -ENOMEM;
-			if (page == NULL)
-				goto fail;
-
-			pagedata = page_address(page);
-
-			list_add_tail(&page->lru, pagelist);
-			pageidx = 0;
-		}
-
-		ret = -EFAULT;
-		if (copy_from_user(pagedata + pageidx, data, size))
-			goto fail;
-
-		data += size;
-		pageidx += size;
-	}
-
-	ret = 0;
-
-fail:
-	return ret;
-}
-
-/*
- * Call function "fn" on each element of the array fragmented
- * over a list of pages.
- */
-static int traverse_pages(unsigned nelem, size_t size,
-			  struct list_head *pos,
-			  int (*fn)(void *data, void *state),
-			  void *state)
-{
-	void *pagedata;
-	unsigned pageidx;
-	int ret = 0;
-
-	BUG_ON(size > PAGE_SIZE);
-
-	pageidx = PAGE_SIZE;
-	pagedata = NULL;	/* hush, gcc */
-
-	while (nelem--) {
-		if (pageidx > PAGE_SIZE-size) {
-			struct page *page;
-			pos = pos->next;
-			page = list_entry(pos, struct page, lru);
-			pagedata = page_address(page);
-			pageidx = 0;
-		}
-
-		ret = (*fn)(pagedata + pageidx, state);
-		if (ret)
-			break;
-		pageidx += size;
-	}
-
-	return ret;
-}
-
-struct mmap_mfn_state {
-	unsigned long va;
-	struct vm_area_struct *vma;
-	domid_t domain;
-};
-
-static int mmap_mfn_range(void *data, void *state)
-{
-	struct privcmd_mmap_entry *msg = data;
-	struct mmap_mfn_state *st = state;
-	struct vm_area_struct *vma = st->vma;
-	int rc;
-
-	/* Do not allow range to wrap the address space. */
-	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
-	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
-		return -EINVAL;
-
-	/* Range chunks must be contiguous in va space. */
-	if ((msg->va != st->va) ||
-	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
-		return -EINVAL;
-
-	rc = xen_remap_domain_mfn_range(vma,
-					msg->va & PAGE_MASK,
-					msg->mfn, msg->npages,
-					vma->vm_page_prot,
-					st->domain);
-	if (rc < 0)
-		return rc;
-
-	st->va += msg->npages << PAGE_SHIFT;
-
-	return 0;
-}
-
-static long privcmd_ioctl_mmap(void __user *udata)
-{
-	struct privcmd_mmap mmapcmd;
-	struct mm_struct *mm = current->mm;
-	struct vm_area_struct *vma;
-	int rc;
-	LIST_HEAD(pagelist);
-	struct mmap_mfn_state state;
-
-	if (!xen_initial_domain())
-		return -EPERM;
-
-	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
-		return -EFAULT;
-
-	rc = gather_array(&pagelist,
-			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
-			  mmapcmd.entry);
-
-	if (rc || list_empty(&pagelist))
-		goto out;
-
-	down_write(&mm->mmap_sem);
-
-	{
-		struct page *page = list_first_entry(&pagelist,
-						     struct page, lru);
-		struct privcmd_mmap_entry *msg = page_address(page);
-
-		vma = find_vma(mm, msg->va);
-		rc = -EINVAL;
-
-		if (!vma || (msg->va != vma->vm_start) ||
-		    !privcmd_enforce_singleshot_mapping(vma))
-			goto out_up;
-	}
-
-	state.va = vma->vm_start;
-	state.vma = vma;
-	state.domain = mmapcmd.dom;
-
-	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
-			    &pagelist,
-			    mmap_mfn_range, &state);
-
-
-out_up:
-	up_write(&mm->mmap_sem);
-
-out:
-	free_page_list(&pagelist);
-
-	return rc;
-}
-
-struct mmap_batch_state {
-	domid_t domain;
-	unsigned long va;
-	struct vm_area_struct *vma;
-	int err;
-
-	xen_pfn_t __user *user;
-};
-
-static int mmap_batch_fn(void *data, void *state)
-{
-	xen_pfn_t *mfnp = data;
-	struct mmap_batch_state *st = state;
-
-	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-				       st->vma->vm_page_prot, st->domain) < 0) {
-		*mfnp |= 0xf0000000U;
-		st->err++;
-	}
-	st->va += PAGE_SIZE;
-
-	return 0;
-}
-
-static int mmap_return_errors(void *data, void *state)
-{
-	xen_pfn_t *mfnp = data;
-	struct mmap_batch_state *st = state;
-
-	return put_user(*mfnp, st->user++);
-}
-
-static struct vm_operations_struct privcmd_vm_ops;
-
-static long privcmd_ioctl_mmap_batch(void __user *udata)
-{
-	int ret;
-	struct privcmd_mmapbatch m;
-	struct mm_struct *mm = current->mm;
-	struct vm_area_struct *vma;
-	unsigned long nr_pages;
-	LIST_HEAD(pagelist);
-	struct mmap_batch_state state;
-
-	if (!xen_initial_domain())
-		return -EPERM;
-
-	if (copy_from_user(&m, udata, sizeof(m)))
-		return -EFAULT;
-
-	nr_pages = m.num;
-	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
-		return -EINVAL;
-
-	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
-			   m.arr);
-
-	if (ret || list_empty(&pagelist))
-		goto out;
-
-	down_write(&mm->mmap_sem);
-
-	vma = find_vma(mm, m.addr);
-	ret = -EINVAL;
-	if (!vma ||
-	    vma->vm_ops != &privcmd_vm_ops ||
-	    (m.addr != vma->vm_start) ||
-	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
-	    !privcmd_enforce_singleshot_mapping(vma)) {
-		up_write(&mm->mmap_sem);
-		goto out;
-	}
-
-	state.domain = m.dom;
-	state.vma = vma;
-	state.va = m.addr;
-	state.err = 0;
-
-	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
-			     &pagelist, mmap_batch_fn, &state);
-
-	up_write(&mm->mmap_sem);
-
-	if (state.err > 0) {
-		state.user = m.arr;
-		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
-			       &pagelist,
-			       mmap_return_errors, &state);
-	}
-
-out:
-	free_page_list(&pagelist);
-
-	return ret;
-}
-
-static long privcmd_ioctl(struct file *file,
-			  unsigned int cmd, unsigned long data)
-{
-	int ret = -ENOSYS;
-	void __user *udata = (void __user *) data;
-
-	switch (cmd) {
-	case IOCTL_PRIVCMD_HYPERCALL:
-		ret = privcmd_ioctl_hypercall(udata);
-		break;
-
-	case IOCTL_PRIVCMD_MMAP:
-		ret = privcmd_ioctl_mmap(udata);
-		break;
-
-	case IOCTL_PRIVCMD_MMAPBATCH:
-		ret = privcmd_ioctl_mmap_batch(udata);
-		break;
-
-	default:
-		ret = -EINVAL;
-		break;
-	}
-
-	return ret;
-}
-
-#ifndef HAVE_ARCH_PRIVCMD_MMAP
-static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
-{
-	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
-	       vma, vma->vm_start, vma->vm_end,
-	       vmf->pgoff, vmf->virtual_address);
-
-	return VM_FAULT_SIGBUS;
-}
-
-static struct vm_operations_struct privcmd_vm_ops = {
-	.fault = privcmd_fault
-};
-
-static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
-{
-	/* Unsupported for auto-translate guests. */
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return -ENOSYS;
-
-	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
-	 * how to recreate these mappings */
-	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
-	vma->vm_ops = &privcmd_vm_ops;
-	vma->vm_private_data = NULL;
-
-	return 0;
-}
-
-static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
-{
-	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
-}
-#endif
-
-const struct file_operations privcmd_file_ops = {
-	.unlocked_ioctl = privcmd_ioctl,
-	.mmap = privcmd_mmap,
-};
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 1aa3897..a55fbf9 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -16,6 +16,7 @@
 #include <xen/xen.h>
 
 #include "xenfs.h"
+#include "../privcmd.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -84,7 +85,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 		[1] = {},
 		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
-		{ "privcmd", &privcmd_file_ops, S_IRUSR|S_IWUSR },
+		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
 	};
 	int rc;
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index b68aa62..5056306 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -2,7 +2,6 @@
 #define _XENFS_XENBUS_H
 
 extern const struct file_operations xenbus_file_ops;
-extern const struct file_operations privcmd_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmtE-0003yR-6k; Sun, 27 Nov 2011 22:08:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmtD-0003yK-0y
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:07:59 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322431632!47281271!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32752 invoked from network); 27 Nov 2011 22:07:12 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2011 22:07:12 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 783955415A; Sun, 27 Nov 2011 23:07:27 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:05 +0100
Message-Id: <1322431628-21760-3-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
Cc: Bastian Blank <waldi@debian.org>
Subject: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to arbitrary hypercalls is currently provided via xenfs. This
adds a standard character device to handle this. The support in xenfs
remains for backward compatibility and uses the device driver code.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/Kconfig         |    7 +
 drivers/xen/Makefile        |    2 +
 drivers/xen/privcmd.c       |  437 +++++++++++++++++++++++++++++++++++++++++++
 drivers/xen/privcmd.h       |    3 +
 drivers/xen/xenfs/Makefile  |    2 +-
 drivers/xen/xenfs/privcmd.c |  400 ---------------------------------------
 drivers/xen/xenfs/super.c   |    3 +-
 drivers/xen/xenfs/xenfs.h   |    1 -
 8 files changed, 452 insertions(+), 403 deletions(-)
 create mode 100644 drivers/xen/privcmd.c
 create mode 100644 drivers/xen/privcmd.h
 delete mode 100644 drivers/xen/xenfs/privcmd.c

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 5f7ff8e..eb7574c 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -86,6 +86,7 @@ config XEN_BACKEND
 
 config XENFS
 	tristate "Xen filesystem"
+	select XEN_PRIVCMD
 	default y
 	help
 	  The xen filesystem provides a way for domains to share
@@ -181,4 +182,10 @@ config XEN_PCIDEV_BACKEND
 	  xen-pciback.hide=(03:00.0)(04:00.0)
 
 	  If in doubt, say m.
+
+config XEN_PRIVCMD
+	tristate
+	depends on XEN_DOM0
+	default m
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 72bbb27..c35f65d 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -19,9 +19,11 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
+obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
 
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
+xen-privcmd-y				:= privcmd.o
 
 xen-platform-pci-y			:= platform-pci.o
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
new file mode 100644
index 0000000..863fbd0
--- /dev/null
+++ b/drivers/xen/privcmd.c
@@ -0,0 +1,437 @@
+/******************************************************************************
+ * privcmd.c
+ *
+ * Interface to privileged domain-0 commands.
+ *
+ * Copyright (c) 2002-2004, K A Fraser, B Dragovic
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/errno.h>
+#include <linux/mm.h>
+#include <linux/mman.h>
+#include <linux/uaccess.h>
+#include <linux/swap.h>
+#include <linux/highmem.h>
+#include <linux/pagemap.h>
+#include <linux/seq_file.h>
+#include <linux/miscdevice.h>
+
+#include <asm/pgalloc.h>
+#include <asm/pgtable.h>
+#include <asm/tlb.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+#include <xen/xen.h>
+#include <xen/privcmd.h>
+#include <xen/interface/xen.h>
+#include <xen/features.h>
+#include <xen/page.h>
+#include <xen/xen-ops.h>
+
+#include "privcmd.h"
+
+MODULE_LICENSE("GPL");
+
+#ifndef HAVE_ARCH_PRIVCMD_MMAP
+static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
+#endif
+
+static long privcmd_ioctl_hypercall(void __user *udata)
+{
+	struct privcmd_hypercall hypercall;
+	long ret;
+
+	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
+		return -EFAULT;
+
+	ret = privcmd_call(hypercall.op,
+			   hypercall.arg[0], hypercall.arg[1],
+			   hypercall.arg[2], hypercall.arg[3],
+			   hypercall.arg[4]);
+
+	return ret;
+}
+
+static void free_page_list(struct list_head *pages)
+{
+	struct page *p, *n;
+
+	list_for_each_entry_safe(p, n, pages, lru)
+		__free_page(p);
+
+	INIT_LIST_HEAD(pages);
+}
+
+/*
+ * Given an array of items in userspace, return a list of pages
+ * containing the data.  If copying fails, either because of memory
+ * allocation failure or a problem reading user memory, return an
+ * error code; its up to the caller to dispose of any partial list.
+ */
+static int gather_array(struct list_head *pagelist,
+			unsigned nelem, size_t size,
+			void __user *data)
+{
+	unsigned pageidx;
+	void *pagedata;
+	int ret;
+
+	if (size > PAGE_SIZE)
+		return 0;
+
+	pageidx = PAGE_SIZE;
+	pagedata = NULL;	/* quiet, gcc */
+	while (nelem--) {
+		if (pageidx > PAGE_SIZE-size) {
+			struct page *page = alloc_page(GFP_KERNEL);
+
+			ret = -ENOMEM;
+			if (page == NULL)
+				goto fail;
+
+			pagedata = page_address(page);
+
+			list_add_tail(&page->lru, pagelist);
+			pageidx = 0;
+		}
+
+		ret = -EFAULT;
+		if (copy_from_user(pagedata + pageidx, data, size))
+			goto fail;
+
+		data += size;
+		pageidx += size;
+	}
+
+	ret = 0;
+
+fail:
+	return ret;
+}
+
+/*
+ * Call function "fn" on each element of the array fragmented
+ * over a list of pages.
+ */
+static int traverse_pages(unsigned nelem, size_t size,
+			  struct list_head *pos,
+			  int (*fn)(void *data, void *state),
+			  void *state)
+{
+	void *pagedata;
+	unsigned pageidx;
+	int ret = 0;
+
+	BUG_ON(size > PAGE_SIZE);
+
+	pageidx = PAGE_SIZE;
+	pagedata = NULL;	/* hush, gcc */
+
+	while (nelem--) {
+		if (pageidx > PAGE_SIZE-size) {
+			struct page *page;
+			pos = pos->next;
+			page = list_entry(pos, struct page, lru);
+			pagedata = page_address(page);
+			pageidx = 0;
+		}
+
+		ret = (*fn)(pagedata + pageidx, state);
+		if (ret)
+			break;
+		pageidx += size;
+	}
+
+	return ret;
+}
+
+struct mmap_mfn_state {
+	unsigned long va;
+	struct vm_area_struct *vma;
+	domid_t domain;
+};
+
+static int mmap_mfn_range(void *data, void *state)
+{
+	struct privcmd_mmap_entry *msg = data;
+	struct mmap_mfn_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	int rc;
+
+	/* Do not allow range to wrap the address space. */
+	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
+	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
+		return -EINVAL;
+
+	/* Range chunks must be contiguous in va space. */
+	if ((msg->va != st->va) ||
+	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
+		return -EINVAL;
+
+	rc = xen_remap_domain_mfn_range(vma,
+					msg->va & PAGE_MASK,
+					msg->mfn, msg->npages,
+					vma->vm_page_prot,
+					st->domain);
+	if (rc < 0)
+		return rc;
+
+	st->va += msg->npages << PAGE_SHIFT;
+
+	return 0;
+}
+
+static long privcmd_ioctl_mmap(void __user *udata)
+{
+	struct privcmd_mmap mmapcmd;
+	struct mm_struct *mm = current->mm;
+	struct vm_area_struct *vma;
+	int rc;
+	LIST_HEAD(pagelist);
+	struct mmap_mfn_state state;
+
+	if (!xen_initial_domain())
+		return -EPERM;
+
+	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
+		return -EFAULT;
+
+	rc = gather_array(&pagelist,
+			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
+			  mmapcmd.entry);
+
+	if (rc || list_empty(&pagelist))
+		goto out;
+
+	down_write(&mm->mmap_sem);
+
+	{
+		struct page *page = list_first_entry(&pagelist,
+						     struct page, lru);
+		struct privcmd_mmap_entry *msg = page_address(page);
+
+		vma = find_vma(mm, msg->va);
+		rc = -EINVAL;
+
+		if (!vma || (msg->va != vma->vm_start) ||
+		    !privcmd_enforce_singleshot_mapping(vma))
+			goto out_up;
+	}
+
+	state.va = vma->vm_start;
+	state.vma = vma;
+	state.domain = mmapcmd.dom;
+
+	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
+			    &pagelist,
+			    mmap_mfn_range, &state);
+
+
+out_up:
+	up_write(&mm->mmap_sem);
+
+out:
+	free_page_list(&pagelist);
+
+	return rc;
+}
+
+struct mmap_batch_state {
+	domid_t domain;
+	unsigned long va;
+	struct vm_area_struct *vma;
+	int err;
+
+	xen_pfn_t __user *user;
+};
+
+static int mmap_batch_fn(void *data, void *state)
+{
+	xen_pfn_t *mfnp = data;
+	struct mmap_batch_state *st = state;
+
+	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
+				       st->vma->vm_page_prot, st->domain) < 0) {
+		*mfnp |= 0xf0000000U;
+		st->err++;
+	}
+	st->va += PAGE_SIZE;
+
+	return 0;
+}
+
+static int mmap_return_errors(void *data, void *state)
+{
+	xen_pfn_t *mfnp = data;
+	struct mmap_batch_state *st = state;
+
+	return put_user(*mfnp, st->user++);
+}
+
+static struct vm_operations_struct privcmd_vm_ops;
+
+static long privcmd_ioctl_mmap_batch(void __user *udata)
+{
+	int ret;
+	struct privcmd_mmapbatch m;
+	struct mm_struct *mm = current->mm;
+	struct vm_area_struct *vma;
+	unsigned long nr_pages;
+	LIST_HEAD(pagelist);
+	struct mmap_batch_state state;
+
+	if (!xen_initial_domain())
+		return -EPERM;
+
+	if (copy_from_user(&m, udata, sizeof(m)))
+		return -EFAULT;
+
+	nr_pages = m.num;
+	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
+		return -EINVAL;
+
+	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
+			   m.arr);
+
+	if (ret || list_empty(&pagelist))
+		goto out;
+
+	down_write(&mm->mmap_sem);
+
+	vma = find_vma(mm, m.addr);
+	ret = -EINVAL;
+	if (!vma ||
+	    vma->vm_ops != &privcmd_vm_ops ||
+	    (m.addr != vma->vm_start) ||
+	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
+	    !privcmd_enforce_singleshot_mapping(vma)) {
+		up_write(&mm->mmap_sem);
+		goto out;
+	}
+
+	state.domain = m.dom;
+	state.vma = vma;
+	state.va = m.addr;
+	state.err = 0;
+
+	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
+			     &pagelist, mmap_batch_fn, &state);
+
+	up_write(&mm->mmap_sem);
+
+	if (state.err > 0) {
+		state.user = m.arr;
+		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
+			       &pagelist,
+			       mmap_return_errors, &state);
+	}
+
+out:
+	free_page_list(&pagelist);
+
+	return ret;
+}
+
+static long privcmd_ioctl(struct file *file,
+			  unsigned int cmd, unsigned long data)
+{
+	int ret = -ENOSYS;
+	void __user *udata = (void __user *) data;
+
+	switch (cmd) {
+	case IOCTL_PRIVCMD_HYPERCALL:
+		ret = privcmd_ioctl_hypercall(udata);
+		break;
+
+	case IOCTL_PRIVCMD_MMAP:
+		ret = privcmd_ioctl_mmap(udata);
+		break;
+
+	case IOCTL_PRIVCMD_MMAPBATCH:
+		ret = privcmd_ioctl_mmap_batch(udata);
+		break;
+
+	default:
+		ret = -EINVAL;
+		break;
+	}
+
+	return ret;
+}
+
+#ifndef HAVE_ARCH_PRIVCMD_MMAP
+static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
+{
+	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
+	       vma, vma->vm_start, vma->vm_end,
+	       vmf->pgoff, vmf->virtual_address);
+
+	return VM_FAULT_SIGBUS;
+}
+
+static struct vm_operations_struct privcmd_vm_ops = {
+	.fault = privcmd_fault
+};
+
+static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	/* Unsupported for auto-translate guests. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
+	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
+	 * how to recreate these mappings */
+	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
+	vma->vm_ops = &privcmd_vm_ops;
+	vma->vm_private_data = NULL;
+
+	return 0;
+}
+
+static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
+{
+	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
+}
+#endif
+
+const struct file_operations xen_privcmd_fops = {
+	.owner = THIS_MODULE,
+	.unlocked_ioctl = privcmd_ioctl,
+	.mmap = privcmd_mmap,
+};
+EXPORT_SYMBOL_GPL(xen_privcmd_fops);
+
+static struct miscdevice privcmd_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/privcmd",
+	.fops = &xen_privcmd_fops,
+};
+
+static int __init privcmd_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&privcmd_dev);
+	if (err != 0) {
+		printk(KERN_ERR "Could not register privcmd device\n");
+		return err;
+	}
+	return 0;
+}
+
+static void __exit privcmd_exit(void)
+{
+	misc_deregister(&privcmd_dev);
+}
+
+module_init(privcmd_init);
+module_exit(privcmd_exit);
diff --git a/drivers/xen/privcmd.h b/drivers/xen/privcmd.h
new file mode 100644
index 0000000..14facae
--- /dev/null
+++ b/drivers/xen/privcmd.h
@@ -0,0 +1,3 @@
+#include <linux/fs.h>
+
+extern const struct file_operations xen_privcmd_fops;
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 4fde944..5d45ff1 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o privcmd.o
+xenfs-y			  = super.o xenbus.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
deleted file mode 100644
index dbd3b16..0000000
--- a/drivers/xen/xenfs/privcmd.c
+++ /dev/null
@@ -1,400 +0,0 @@
-/******************************************************************************
- * privcmd.c
- *
- * Interface to privileged domain-0 commands.
- *
- * Copyright (c) 2002-2004, K A Fraser, B Dragovic
- */
-
-#include <linux/kernel.h>
-#include <linux/sched.h>
-#include <linux/slab.h>
-#include <linux/string.h>
-#include <linux/errno.h>
-#include <linux/mm.h>
-#include <linux/mman.h>
-#include <linux/uaccess.h>
-#include <linux/swap.h>
-#include <linux/highmem.h>
-#include <linux/pagemap.h>
-#include <linux/seq_file.h>
-
-#include <asm/pgalloc.h>
-#include <asm/pgtable.h>
-#include <asm/tlb.h>
-#include <asm/xen/hypervisor.h>
-#include <asm/xen/hypercall.h>
-
-#include <xen/xen.h>
-#include <xen/privcmd.h>
-#include <xen/interface/xen.h>
-#include <xen/features.h>
-#include <xen/page.h>
-#include <xen/xen-ops.h>
-
-#ifndef HAVE_ARCH_PRIVCMD_MMAP
-static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
-#endif
-
-static long privcmd_ioctl_hypercall(void __user *udata)
-{
-	struct privcmd_hypercall hypercall;
-	long ret;
-
-	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
-		return -EFAULT;
-
-	ret = privcmd_call(hypercall.op,
-			   hypercall.arg[0], hypercall.arg[1],
-			   hypercall.arg[2], hypercall.arg[3],
-			   hypercall.arg[4]);
-
-	return ret;
-}
-
-static void free_page_list(struct list_head *pages)
-{
-	struct page *p, *n;
-
-	list_for_each_entry_safe(p, n, pages, lru)
-		__free_page(p);
-
-	INIT_LIST_HEAD(pages);
-}
-
-/*
- * Given an array of items in userspace, return a list of pages
- * containing the data.  If copying fails, either because of memory
- * allocation failure or a problem reading user memory, return an
- * error code; its up to the caller to dispose of any partial list.
- */
-static int gather_array(struct list_head *pagelist,
-			unsigned nelem, size_t size,
-			void __user *data)
-{
-	unsigned pageidx;
-	void *pagedata;
-	int ret;
-
-	if (size > PAGE_SIZE)
-		return 0;
-
-	pageidx = PAGE_SIZE;
-	pagedata = NULL;	/* quiet, gcc */
-	while (nelem--) {
-		if (pageidx > PAGE_SIZE-size) {
-			struct page *page = alloc_page(GFP_KERNEL);
-
-			ret = -ENOMEM;
-			if (page == NULL)
-				goto fail;
-
-			pagedata = page_address(page);
-
-			list_add_tail(&page->lru, pagelist);
-			pageidx = 0;
-		}
-
-		ret = -EFAULT;
-		if (copy_from_user(pagedata + pageidx, data, size))
-			goto fail;
-
-		data += size;
-		pageidx += size;
-	}
-
-	ret = 0;
-
-fail:
-	return ret;
-}
-
-/*
- * Call function "fn" on each element of the array fragmented
- * over a list of pages.
- */
-static int traverse_pages(unsigned nelem, size_t size,
-			  struct list_head *pos,
-			  int (*fn)(void *data, void *state),
-			  void *state)
-{
-	void *pagedata;
-	unsigned pageidx;
-	int ret = 0;
-
-	BUG_ON(size > PAGE_SIZE);
-
-	pageidx = PAGE_SIZE;
-	pagedata = NULL;	/* hush, gcc */
-
-	while (nelem--) {
-		if (pageidx > PAGE_SIZE-size) {
-			struct page *page;
-			pos = pos->next;
-			page = list_entry(pos, struct page, lru);
-			pagedata = page_address(page);
-			pageidx = 0;
-		}
-
-		ret = (*fn)(pagedata + pageidx, state);
-		if (ret)
-			break;
-		pageidx += size;
-	}
-
-	return ret;
-}
-
-struct mmap_mfn_state {
-	unsigned long va;
-	struct vm_area_struct *vma;
-	domid_t domain;
-};
-
-static int mmap_mfn_range(void *data, void *state)
-{
-	struct privcmd_mmap_entry *msg = data;
-	struct mmap_mfn_state *st = state;
-	struct vm_area_struct *vma = st->vma;
-	int rc;
-
-	/* Do not allow range to wrap the address space. */
-	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
-	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
-		return -EINVAL;
-
-	/* Range chunks must be contiguous in va space. */
-	if ((msg->va != st->va) ||
-	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
-		return -EINVAL;
-
-	rc = xen_remap_domain_mfn_range(vma,
-					msg->va & PAGE_MASK,
-					msg->mfn, msg->npages,
-					vma->vm_page_prot,
-					st->domain);
-	if (rc < 0)
-		return rc;
-
-	st->va += msg->npages << PAGE_SHIFT;
-
-	return 0;
-}
-
-static long privcmd_ioctl_mmap(void __user *udata)
-{
-	struct privcmd_mmap mmapcmd;
-	struct mm_struct *mm = current->mm;
-	struct vm_area_struct *vma;
-	int rc;
-	LIST_HEAD(pagelist);
-	struct mmap_mfn_state state;
-
-	if (!xen_initial_domain())
-		return -EPERM;
-
-	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
-		return -EFAULT;
-
-	rc = gather_array(&pagelist,
-			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
-			  mmapcmd.entry);
-
-	if (rc || list_empty(&pagelist))
-		goto out;
-
-	down_write(&mm->mmap_sem);
-
-	{
-		struct page *page = list_first_entry(&pagelist,
-						     struct page, lru);
-		struct privcmd_mmap_entry *msg = page_address(page);
-
-		vma = find_vma(mm, msg->va);
-		rc = -EINVAL;
-
-		if (!vma || (msg->va != vma->vm_start) ||
-		    !privcmd_enforce_singleshot_mapping(vma))
-			goto out_up;
-	}
-
-	state.va = vma->vm_start;
-	state.vma = vma;
-	state.domain = mmapcmd.dom;
-
-	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
-			    &pagelist,
-			    mmap_mfn_range, &state);
-
-
-out_up:
-	up_write(&mm->mmap_sem);
-
-out:
-	free_page_list(&pagelist);
-
-	return rc;
-}
-
-struct mmap_batch_state {
-	domid_t domain;
-	unsigned long va;
-	struct vm_area_struct *vma;
-	int err;
-
-	xen_pfn_t __user *user;
-};
-
-static int mmap_batch_fn(void *data, void *state)
-{
-	xen_pfn_t *mfnp = data;
-	struct mmap_batch_state *st = state;
-
-	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-				       st->vma->vm_page_prot, st->domain) < 0) {
-		*mfnp |= 0xf0000000U;
-		st->err++;
-	}
-	st->va += PAGE_SIZE;
-
-	return 0;
-}
-
-static int mmap_return_errors(void *data, void *state)
-{
-	xen_pfn_t *mfnp = data;
-	struct mmap_batch_state *st = state;
-
-	return put_user(*mfnp, st->user++);
-}
-
-static struct vm_operations_struct privcmd_vm_ops;
-
-static long privcmd_ioctl_mmap_batch(void __user *udata)
-{
-	int ret;
-	struct privcmd_mmapbatch m;
-	struct mm_struct *mm = current->mm;
-	struct vm_area_struct *vma;
-	unsigned long nr_pages;
-	LIST_HEAD(pagelist);
-	struct mmap_batch_state state;
-
-	if (!xen_initial_domain())
-		return -EPERM;
-
-	if (copy_from_user(&m, udata, sizeof(m)))
-		return -EFAULT;
-
-	nr_pages = m.num;
-	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
-		return -EINVAL;
-
-	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
-			   m.arr);
-
-	if (ret || list_empty(&pagelist))
-		goto out;
-
-	down_write(&mm->mmap_sem);
-
-	vma = find_vma(mm, m.addr);
-	ret = -EINVAL;
-	if (!vma ||
-	    vma->vm_ops != &privcmd_vm_ops ||
-	    (m.addr != vma->vm_start) ||
-	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
-	    !privcmd_enforce_singleshot_mapping(vma)) {
-		up_write(&mm->mmap_sem);
-		goto out;
-	}
-
-	state.domain = m.dom;
-	state.vma = vma;
-	state.va = m.addr;
-	state.err = 0;
-
-	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
-			     &pagelist, mmap_batch_fn, &state);
-
-	up_write(&mm->mmap_sem);
-
-	if (state.err > 0) {
-		state.user = m.arr;
-		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
-			       &pagelist,
-			       mmap_return_errors, &state);
-	}
-
-out:
-	free_page_list(&pagelist);
-
-	return ret;
-}
-
-static long privcmd_ioctl(struct file *file,
-			  unsigned int cmd, unsigned long data)
-{
-	int ret = -ENOSYS;
-	void __user *udata = (void __user *) data;
-
-	switch (cmd) {
-	case IOCTL_PRIVCMD_HYPERCALL:
-		ret = privcmd_ioctl_hypercall(udata);
-		break;
-
-	case IOCTL_PRIVCMD_MMAP:
-		ret = privcmd_ioctl_mmap(udata);
-		break;
-
-	case IOCTL_PRIVCMD_MMAPBATCH:
-		ret = privcmd_ioctl_mmap_batch(udata);
-		break;
-
-	default:
-		ret = -EINVAL;
-		break;
-	}
-
-	return ret;
-}
-
-#ifndef HAVE_ARCH_PRIVCMD_MMAP
-static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
-{
-	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
-	       vma, vma->vm_start, vma->vm_end,
-	       vmf->pgoff, vmf->virtual_address);
-
-	return VM_FAULT_SIGBUS;
-}
-
-static struct vm_operations_struct privcmd_vm_ops = {
-	.fault = privcmd_fault
-};
-
-static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
-{
-	/* Unsupported for auto-translate guests. */
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return -ENOSYS;
-
-	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
-	 * how to recreate these mappings */
-	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
-	vma->vm_ops = &privcmd_vm_ops;
-	vma->vm_private_data = NULL;
-
-	return 0;
-}
-
-static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
-{
-	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
-}
-#endif
-
-const struct file_operations privcmd_file_ops = {
-	.unlocked_ioctl = privcmd_ioctl,
-	.mmap = privcmd_mmap,
-};
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 1aa3897..a55fbf9 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -16,6 +16,7 @@
 #include <xen/xen.h>
 
 #include "xenfs.h"
+#include "../privcmd.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -84,7 +85,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 		[1] = {},
 		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
-		{ "privcmd", &privcmd_file_ops, S_IRUSR|S_IWUSR },
+		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
 	};
 	int rc;
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index b68aa62..5056306 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -2,7 +2,6 @@
 #define _XENFS_XENBUS_H
 
 extern const struct file_operations xenbus_file_ops;
-extern const struct file_operations privcmd_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmtK-0003zS-NL; Sun, 27 Nov 2011 22:08:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmtJ-0003yQ-EF
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:08:05 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322431649!5166627!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16474 invoked from network); 27 Nov 2011 22:07:30 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2011 22:07:30 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 55FC55415A; Sun, 27 Nov 2011 23:07:29 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:08 +0100
Message-Id: <1322431628-21760-6-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
Cc: Bastian Blank <waldi@debian.org>
Subject: [Xen-devel] [PATCH 5/5] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access for xenstored to the event channel and pre-allocated ring is
managed via xenfs.  This adds its own device driver featuring mmap for
the ring and an ioctl for the event channel.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/Makefile             |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   79 +++++++++++++++++++++++++++++++
 include/xen/xenbus_dev.h                |   41 ++++++++++++++++
 3 files changed, 121 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.c
 create mode 100644 include/xen/xenbus_dev.h

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index a2ea363..7e1aa85 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -10,4 +10,5 @@ xenbus-objs += xenbus_probe.o
 xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
 xenbus-objs += $(xenbus-be-objs-y)
 
+obj-$(CONFIG_XEN_DOM0) += xenbus_dev_backend.o
 obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
new file mode 100644
index 0000000..5d77cee
--- /dev/null
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -0,0 +1,79 @@
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/mm.h>
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+
+#include <xen/page.h>
+#include <xen/xenbus_dev.h>
+
+#include "xenbus_comms.h"
+
+MODULE_LICENSE("GPL");
+
+static long xenbusd_ioctl(struct file *file, unsigned int cmd, unsigned long data)
+{
+	if (!capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
+	switch (cmd) {
+		case IOCTL_XENBUSD_EVTCHN:
+			if (xen_store_evtchn > 0)
+				return xen_store_evtchn;
+			return -EINVAL;
+
+		default:
+			return -ENOTTY;
+	}
+}
+
+static int xenbusd_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	size_t size = vma->vm_end - vma->vm_start;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
+	if ((size > PAGE_SIZE) || (vma->vm_pgoff != 0))
+		return -EINVAL;
+
+	if (remap_pfn_range(vma, vma->vm_start,
+			    virt_to_pfn(xen_store_interface),
+			    size, vma->vm_page_prot))
+		return -EAGAIN;
+
+	return 0;
+}
+
+const struct file_operations xenbusd_fops = {
+	.mmap = xenbusd_mmap,
+	.unlocked_ioctl = xenbusd_ioctl,
+};
+
+static struct miscdevice xenbusd_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbusd",
+	.fops = &xenbusd_fops,
+};
+
+static int __init xenbusd_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbusd_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus device\n");
+	return err;
+}
+
+static void __exit xenbusd_exit(void)
+{
+	misc_deregister(&xenbusd_dev);
+}
+
+module_init(xenbusd_init);
+module_exit(xenbusd_exit);
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
new file mode 100644
index 0000000..f551404
--- /dev/null
+++ b/include/xen/xenbus_dev.h
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * evtchn.h
+ *
+ * Interface to /dev/xen/xenbusd.
+ *
+ * Copyright (c) 2011 Bastian Blank <waldi@debian.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __LINUX_XEN_XENBUS_DEV_H__
+#define __LINUX_XEN_XENBUS_DEV_H__
+
+#include <linux/ioctl.h>
+
+#define IOCTL_XENBUSD_EVTCHN				\
+	_IOC(_IOC_NONE, 'X', 0, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmtK-0003zS-NL; Sun, 27 Nov 2011 22:08:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmtJ-0003yQ-EF
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:08:05 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322431649!5166627!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16474 invoked from network); 27 Nov 2011 22:07:30 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2011 22:07:30 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 55FC55415A; Sun, 27 Nov 2011 23:07:29 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:08 +0100
Message-Id: <1322431628-21760-6-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
Cc: Bastian Blank <waldi@debian.org>
Subject: [Xen-devel] [PATCH 5/5] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access for xenstored to the event channel and pre-allocated ring is
managed via xenfs.  This adds its own device driver featuring mmap for
the ring and an ioctl for the event channel.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/Makefile             |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   79 +++++++++++++++++++++++++++++++
 include/xen/xenbus_dev.h                |   41 ++++++++++++++++
 3 files changed, 121 insertions(+), 0 deletions(-)
 create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.c
 create mode 100644 include/xen/xenbus_dev.h

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index a2ea363..7e1aa85 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -10,4 +10,5 @@ xenbus-objs += xenbus_probe.o
 xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
 xenbus-objs += $(xenbus-be-objs-y)
 
+obj-$(CONFIG_XEN_DOM0) += xenbus_dev_backend.o
 obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
new file mode 100644
index 0000000..5d77cee
--- /dev/null
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -0,0 +1,79 @@
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/mm.h>
+#include <linux/fs.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+
+#include <xen/page.h>
+#include <xen/xenbus_dev.h>
+
+#include "xenbus_comms.h"
+
+MODULE_LICENSE("GPL");
+
+static long xenbusd_ioctl(struct file *file, unsigned int cmd, unsigned long data)
+{
+	if (!capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
+	switch (cmd) {
+		case IOCTL_XENBUSD_EVTCHN:
+			if (xen_store_evtchn > 0)
+				return xen_store_evtchn;
+			return -EINVAL;
+
+		default:
+			return -ENOTTY;
+	}
+}
+
+static int xenbusd_mmap(struct file *file, struct vm_area_struct *vma)
+{
+	size_t size = vma->vm_end - vma->vm_start;
+
+	if (!capable(CAP_SYS_ADMIN))
+		return -EACCES;
+
+	if ((size > PAGE_SIZE) || (vma->vm_pgoff != 0))
+		return -EINVAL;
+
+	if (remap_pfn_range(vma, vma->vm_start,
+			    virt_to_pfn(xen_store_interface),
+			    size, vma->vm_page_prot))
+		return -EAGAIN;
+
+	return 0;
+}
+
+const struct file_operations xenbusd_fops = {
+	.mmap = xenbusd_mmap,
+	.unlocked_ioctl = xenbusd_ioctl,
+};
+
+static struct miscdevice xenbusd_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbusd",
+	.fops = &xenbusd_fops,
+};
+
+static int __init xenbusd_init(void)
+{
+	int err;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbusd_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus device\n");
+	return err;
+}
+
+static void __exit xenbusd_exit(void)
+{
+	misc_deregister(&xenbusd_dev);
+}
+
+module_init(xenbusd_init);
+module_exit(xenbusd_exit);
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
new file mode 100644
index 0000000..f551404
--- /dev/null
+++ b/include/xen/xenbus_dev.h
@@ -0,0 +1,41 @@
+/******************************************************************************
+ * evtchn.h
+ *
+ * Interface to /dev/xen/xenbusd.
+ *
+ * Copyright (c) 2011 Bastian Blank <waldi@debian.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __LINUX_XEN_XENBUS_DEV_H__
+#define __LINUX_XEN_XENBUS_DEV_H__
+
+#include <linux/ioctl.h>
+
+#define IOCTL_XENBUSD_EVTCHN				\
+	_IOC(_IOC_NONE, 'X', 0, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmtN-000400-7X; Sun, 27 Nov 2011 22:08:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmtK-0003ya-UM
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:08:07 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322431649!6008647!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20579 invoked from network); 27 Nov 2011 22:07:30 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2011 22:07:30 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 9F9CB54229; Sun, 27 Nov 2011 23:07:28 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:07 +0100
Message-Id: <1322431628-21760-5-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
Cc: Bastian Blank <waldi@debian.org>
Subject: [Xen-devel] [PATCH 4/5] xen: Add xenbus device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to xenbus is currently handled via xenfs. This adds a device
driver for xenbus and makes xenfs use this code.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/Makefile              |    1 +
 drivers/xen/xenbus/xenbus_comms.h        |    4 +
 drivers/xen/xenbus/xenbus_dev_frontend.c |  624 ++++++++++++++++++++++++++++++
 drivers/xen/xenfs/Makefile               |    2 +-
 drivers/xen/xenfs/super.c                |    3 +-
 drivers/xen/xenfs/xenbus.c               |  593 ----------------------------
 drivers/xen/xenfs/xenfs.h                |    1 -
 7 files changed, 632 insertions(+), 596 deletions(-)
 create mode 100644 drivers/xen/xenbus/xenbus_dev_frontend.c
 delete mode 100644 drivers/xen/xenfs/xenbus.c

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index 8dca685..a2ea363 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -1,4 +1,5 @@
 obj-y	+= xenbus.o
+obj-y	+= xenbus_dev_frontend.o
 
 xenbus-objs =
 xenbus-objs += xenbus_client.o
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index c21db75..6e42800 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -31,6 +31,8 @@
 #ifndef _XENBUS_COMMS_H
 #define _XENBUS_COMMS_H
 
+#include <linux/fs.h>
+
 int xs_init(void);
 int xb_init_comms(void);
 
@@ -43,4 +45,6 @@ int xs_input_avail(void);
 extern struct xenstore_domain_interface *xen_store_interface;
 extern int xen_store_evtchn;
 
+extern const struct file_operations xen_xenbus_fops;
+
 #endif /* _XENBUS_COMMS_H */
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
new file mode 100644
index 0000000..fb30cff
--- /dev/null
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -0,0 +1,624 @@
+/*
+ * Driver giving user-space access to the kernel's xenbus connection
+ * to xenstore.
+ *
+ * Copyright (c) 2005, Christian Limpach
+ * Copyright (c) 2005, Rusty Russell, IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Changes:
+ * 2008-10-07  Alex Zeffertt    Replaced /proc/xen/xenbus with xenfs filesystem
+ *                              and /proc/xen compatibility mount point.
+ *                              Turned xenfs into a loadable module.
+ */
+
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/uio.h>
+#include <linux/notifier.h>
+#include <linux/wait.h>
+#include <linux/fs.h>
+#include <linux/poll.h>
+#include <linux/mutex.h>
+#include <linux/sched.h>
+#include <linux/spinlock.h>
+#include <linux/mount.h>
+#include <linux/pagemap.h>
+#include <linux/uaccess.h>
+#include <linux/init.h>
+#include <linux/namei.h>
+#include <linux/string.h>
+#include <linux/slab.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+
+#include "xenbus_comms.h"
+
+#include <xen/xenbus.h>
+#include <asm/xen/hypervisor.h>
+
+MODULE_LICENSE("GPL");
+
+/*
+ * An element of a list of outstanding transactions, for which we're
+ * still waiting a reply.
+ */
+struct xenbus_transaction_holder {
+	struct list_head list;
+	struct xenbus_transaction handle;
+};
+
+/*
+ * A buffer of data on the queue.
+ */
+struct read_buffer {
+	struct list_head list;
+	unsigned int cons;
+	unsigned int len;
+	char msg[];
+};
+
+struct xenbus_file_priv {
+	/*
+	 * msgbuffer_mutex is held while partial requests are built up
+	 * and complete requests are acted on.  It therefore protects
+	 * the "transactions" and "watches" lists, and the partial
+	 * request length and buffer.
+	 *
+	 * reply_mutex protects the reply being built up to return to
+	 * usermode.  It nests inside msgbuffer_mutex but may be held
+	 * alone during a watch callback.
+	 */
+	struct mutex msgbuffer_mutex;
+
+	/* In-progress transactions */
+	struct list_head transactions;
+
+	/* Active watches. */
+	struct list_head watches;
+
+	/* Partial request. */
+	unsigned int len;
+	union {
+		struct xsd_sockmsg msg;
+		char buffer[PAGE_SIZE];
+	} u;
+
+	/* Response queue. */
+	struct mutex reply_mutex;
+	struct list_head read_buffers;
+	wait_queue_head_t read_waitq;
+
+};
+
+/* Read out any raw xenbus messages queued up. */
+static ssize_t xenbus_file_read(struct file *filp,
+			       char __user *ubuf,
+			       size_t len, loff_t *ppos)
+{
+	struct xenbus_file_priv *u = filp->private_data;
+	struct read_buffer *rb;
+	unsigned i;
+	int ret;
+
+	mutex_lock(&u->reply_mutex);
+again:
+	while (list_empty(&u->read_buffers)) {
+		mutex_unlock(&u->reply_mutex);
+		if (filp->f_flags & O_NONBLOCK)
+			return -EAGAIN;
+
+		ret = wait_event_interruptible(u->read_waitq,
+					       !list_empty(&u->read_buffers));
+		if (ret)
+			return ret;
+		mutex_lock(&u->reply_mutex);
+	}
+
+	rb = list_entry(u->read_buffers.next, struct read_buffer, list);
+	i = 0;
+	while (i < len) {
+		unsigned sz = min((unsigned)len - i, rb->len - rb->cons);
+
+		ret = copy_to_user(ubuf + i, &rb->msg[rb->cons], sz);
+
+		i += sz - ret;
+		rb->cons += sz - ret;
+
+		if (ret != 0) {
+			if (i == 0)
+				i = -EFAULT;
+			goto out;
+		}
+
+		/* Clear out buffer if it has been consumed */
+		if (rb->cons == rb->len) {
+			list_del(&rb->list);
+			kfree(rb);
+			if (list_empty(&u->read_buffers))
+				break;
+			rb = list_entry(u->read_buffers.next,
+					struct read_buffer, list);
+		}
+	}
+	if (i == 0)
+		goto again;
+
+out:
+	mutex_unlock(&u->reply_mutex);
+	return i;
+}
+
+/*
+ * Add a buffer to the queue.  Caller must hold the appropriate lock
+ * if the queue is not local.  (Commonly the caller will build up
+ * multiple queued buffers on a temporary local list, and then add it
+ * to the appropriate list under lock once all the buffers have een
+ * successfully allocated.)
+ */
+static int queue_reply(struct list_head *queue, const void *data, size_t len)
+{
+	struct read_buffer *rb;
+
+	if (len == 0)
+		return 0;
+
+	rb = kmalloc(sizeof(*rb) + len, GFP_KERNEL);
+	if (rb == NULL)
+		return -ENOMEM;
+
+	rb->cons = 0;
+	rb->len = len;
+
+	memcpy(rb->msg, data, len);
+
+	list_add_tail(&rb->list, queue);
+	return 0;
+}
+
+/*
+ * Free all the read_buffer s on a list.
+ * Caller must have sole reference to list.
+ */
+static void queue_cleanup(struct list_head *list)
+{
+	struct read_buffer *rb;
+
+	while (!list_empty(list)) {
+		rb = list_entry(list->next, struct read_buffer, list);
+		list_del(list->next);
+		kfree(rb);
+	}
+}
+
+struct watch_adapter {
+	struct list_head list;
+	struct xenbus_watch watch;
+	struct xenbus_file_priv *dev_data;
+	char *token;
+};
+
+static void free_watch_adapter(struct watch_adapter *watch)
+{
+	kfree(watch->watch.node);
+	kfree(watch->token);
+	kfree(watch);
+}
+
+static struct watch_adapter *alloc_watch_adapter(const char *path,
+						 const char *token)
+{
+	struct watch_adapter *watch;
+
+	watch = kzalloc(sizeof(*watch), GFP_KERNEL);
+	if (watch == NULL)
+		goto out_fail;
+
+	watch->watch.node = kstrdup(path, GFP_KERNEL);
+	if (watch->watch.node == NULL)
+		goto out_free;
+
+	watch->token = kstrdup(token, GFP_KERNEL);
+	if (watch->token == NULL)
+		goto out_free;
+
+	return watch;
+
+out_free:
+	free_watch_adapter(watch);
+
+out_fail:
+	return NULL;
+}
+
+static void watch_fired(struct xenbus_watch *watch,
+			const char **vec,
+			unsigned int len)
+{
+	struct watch_adapter *adap;
+	struct xsd_sockmsg hdr;
+	const char *path, *token;
+	int path_len, tok_len, body_len, data_len = 0;
+	int ret;
+	LIST_HEAD(staging_q);
+
+	adap = container_of(watch, struct watch_adapter, watch);
+
+	path = vec[XS_WATCH_PATH];
+	token = adap->token;
+
+	path_len = strlen(path) + 1;
+	tok_len = strlen(token) + 1;
+	if (len > 2)
+		data_len = vec[len] - vec[2] + 1;
+	body_len = path_len + tok_len + data_len;
+
+	hdr.type = XS_WATCH_EVENT;
+	hdr.len = body_len;
+
+	mutex_lock(&adap->dev_data->reply_mutex);
+
+	ret = queue_reply(&staging_q, &hdr, sizeof(hdr));
+	if (!ret)
+		ret = queue_reply(&staging_q, path, path_len);
+	if (!ret)
+		ret = queue_reply(&staging_q, token, tok_len);
+	if (!ret && len > 2)
+		ret = queue_reply(&staging_q, vec[2], data_len);
+
+	if (!ret) {
+		/* success: pass reply list onto watcher */
+		list_splice_tail(&staging_q, &adap->dev_data->read_buffers);
+		wake_up(&adap->dev_data->read_waitq);
+	} else
+		queue_cleanup(&staging_q);
+
+	mutex_unlock(&adap->dev_data->reply_mutex);
+}
+
+static int xenbus_write_transaction(unsigned msg_type,
+				    struct xenbus_file_priv *u)
+{
+	int rc;
+	void *reply;
+	struct xenbus_transaction_holder *trans = NULL;
+	LIST_HEAD(staging_q);
+
+	if (msg_type == XS_TRANSACTION_START) {
+		trans = kmalloc(sizeof(*trans), GFP_KERNEL);
+		if (!trans) {
+			rc = -ENOMEM;
+			goto out;
+		}
+	}
+
+	reply = xenbus_dev_request_and_reply(&u->u.msg);
+	if (IS_ERR(reply)) {
+		kfree(trans);
+		rc = PTR_ERR(reply);
+		goto out;
+	}
+
+	if (msg_type == XS_TRANSACTION_START) {
+		trans->handle.id = simple_strtoul(reply, NULL, 0);
+
+		list_add(&trans->list, &u->transactions);
+	} else if (msg_type == XS_TRANSACTION_END) {
+		list_for_each_entry(trans, &u->transactions, list)
+			if (trans->handle.id == u->u.msg.tx_id)
+				break;
+		BUG_ON(&trans->list == &u->transactions);
+		list_del(&trans->list);
+
+		kfree(trans);
+	}
+
+	mutex_lock(&u->reply_mutex);
+	rc = queue_reply(&staging_q, &u->u.msg, sizeof(u->u.msg));
+	if (!rc)
+		rc = queue_reply(&staging_q, reply, u->u.msg.len);
+	if (!rc) {
+		list_splice_tail(&staging_q, &u->read_buffers);
+		wake_up(&u->read_waitq);
+	} else {
+		queue_cleanup(&staging_q);
+	}
+	mutex_unlock(&u->reply_mutex);
+
+	kfree(reply);
+
+out:
+	return rc;
+}
+
+static int xenbus_write_watch(unsigned msg_type, struct xenbus_file_priv *u)
+{
+	struct watch_adapter *watch, *tmp_watch;
+	char *path, *token;
+	int err, rc;
+	LIST_HEAD(staging_q);
+
+	path = u->u.buffer + sizeof(u->u.msg);
+	token = memchr(path, 0, u->u.msg.len);
+	if (token == NULL) {
+		rc = -EILSEQ;
+		goto out;
+	}
+	token++;
+
+	if (msg_type == XS_WATCH) {
+		watch = alloc_watch_adapter(path, token);
+		if (watch == NULL) {
+			rc = -ENOMEM;
+			goto out;
+		}
+
+		watch->watch.callback = watch_fired;
+		watch->dev_data = u;
+
+		err = register_xenbus_watch(&watch->watch);
+		if (err) {
+			free_watch_adapter(watch);
+			rc = err;
+			goto out;
+		}
+		list_add(&watch->list, &u->watches);
+	} else {
+		list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
+			if (!strcmp(watch->token, token) &&
+			    !strcmp(watch->watch.node, path)) {
+				unregister_xenbus_watch(&watch->watch);
+				list_del(&watch->list);
+				free_watch_adapter(watch);
+				break;
+			}
+		}
+	}
+
+	/* Success.  Synthesize a reply to say all is OK. */
+	{
+		struct {
+			struct xsd_sockmsg hdr;
+			char body[3];
+		} __packed reply = {
+			{
+				.type = msg_type,
+				.len = sizeof(reply.body)
+			},
+			"OK"
+		};
+
+		mutex_lock(&u->reply_mutex);
+		rc = queue_reply(&u->read_buffers, &reply, sizeof(reply));
+		wake_up(&u->read_waitq);
+		mutex_unlock(&u->reply_mutex);
+	}
+
+out:
+	return rc;
+}
+
+static ssize_t xenbus_file_write(struct file *filp,
+				const char __user *ubuf,
+				size_t len, loff_t *ppos)
+{
+	struct xenbus_file_priv *u = filp->private_data;
+	uint32_t msg_type;
+	int rc = len;
+	int ret;
+	LIST_HEAD(staging_q);
+
+	/*
+	 * We're expecting usermode to be writing properly formed
+	 * xenbus messages.  If they write an incomplete message we
+	 * buffer it up.  Once it is complete, we act on it.
+	 */
+
+	/*
+	 * Make sure concurrent writers can't stomp all over each
+	 * other's messages and make a mess of our partial message
+	 * buffer.  We don't make any attemppt to stop multiple
+	 * writers from making a mess of each other's incomplete
+	 * messages; we're just trying to guarantee our own internal
+	 * consistency and make sure that single writes are handled
+	 * atomically.
+	 */
+	mutex_lock(&u->msgbuffer_mutex);
+
+	/* Get this out of the way early to avoid confusion */
+	if (len == 0)
+		goto out;
+
+	/* Can't write a xenbus message larger we can buffer */
+	if ((len + u->len) > sizeof(u->u.buffer)) {
+		/* On error, dump existing buffer */
+		u->len = 0;
+		rc = -EINVAL;
+		goto out;
+	}
+
+	ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
+
+	if (ret != 0) {
+		rc = -EFAULT;
+		goto out;
+	}
+
+	/* Deal with a partial copy. */
+	len -= ret;
+	rc = len;
+
+	u->len += len;
+
+	/* Return if we haven't got a full message yet */
+	if (u->len < sizeof(u->u.msg))
+		goto out;	/* not even the header yet */
+
+	/* If we're expecting a message that's larger than we can
+	   possibly send, dump what we have and return an error. */
+	if ((sizeof(u->u.msg) + u->u.msg.len) > sizeof(u->u.buffer)) {
+		rc = -E2BIG;
+		u->len = 0;
+		goto out;
+	}
+
+	if (u->len < (sizeof(u->u.msg) + u->u.msg.len))
+		goto out;	/* incomplete data portion */
+
+	/*
+	 * OK, now we have a complete message.  Do something with it.
+	 */
+
+	msg_type = u->u.msg.type;
+
+	switch (msg_type) {
+	case XS_WATCH:
+	case XS_UNWATCH:
+		/* (Un)Ask for some path to be watched for changes */
+		ret = xenbus_write_watch(msg_type, u);
+		break;
+
+	default:
+		/* Send out a transaction */
+		ret = xenbus_write_transaction(msg_type, u);
+		break;
+	}
+	if (ret != 0)
+		rc = ret;
+
+	/* Buffered message consumed */
+	u->len = 0;
+
+ out:
+	mutex_unlock(&u->msgbuffer_mutex);
+	return rc;
+}
+
+static int xenbus_file_open(struct inode *inode, struct file *filp)
+{
+	struct xenbus_file_priv *u;
+
+	if (xen_store_evtchn == 0)
+		return -ENOENT;
+
+	nonseekable_open(inode, filp);
+
+	u = kzalloc(sizeof(*u), GFP_KERNEL);
+	if (u == NULL)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&u->transactions);
+	INIT_LIST_HEAD(&u->watches);
+	INIT_LIST_HEAD(&u->read_buffers);
+	init_waitqueue_head(&u->read_waitq);
+
+	mutex_init(&u->reply_mutex);
+	mutex_init(&u->msgbuffer_mutex);
+
+	filp->private_data = u;
+
+	return 0;
+}
+
+static int xenbus_file_release(struct inode *inode, struct file *filp)
+{
+	struct xenbus_file_priv *u = filp->private_data;
+	struct xenbus_transaction_holder *trans, *tmp;
+	struct watch_adapter *watch, *tmp_watch;
+	struct read_buffer *rb, *tmp_rb;
+
+	/*
+	 * No need for locking here because there are no other users,
+	 * by definition.
+	 */
+
+	list_for_each_entry_safe(trans, tmp, &u->transactions, list) {
+		xenbus_transaction_end(trans->handle, 1);
+		list_del(&trans->list);
+		kfree(trans);
+	}
+
+	list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
+		unregister_xenbus_watch(&watch->watch);
+		list_del(&watch->list);
+		free_watch_adapter(watch);
+	}
+
+	list_for_each_entry_safe(rb, tmp_rb, &u->read_buffers, list) {
+		list_del(&rb->list);
+		kfree(rb);
+	}
+	kfree(u);
+
+	return 0;
+}
+
+static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
+{
+	struct xenbus_file_priv *u = file->private_data;
+
+	poll_wait(file, &u->read_waitq, wait);
+	if (!list_empty(&u->read_buffers))
+		return POLLIN | POLLRDNORM;
+	return 0;
+}
+
+const struct file_operations xen_xenbus_fops = {
+	.read = xenbus_file_read,
+	.write = xenbus_file_write,
+	.open = xenbus_file_open,
+	.release = xenbus_file_release,
+	.poll = xenbus_file_poll,
+	.llseek = no_llseek,
+};
+EXPORT_SYMBOL_GPL(xen_xenbus_fops);
+
+static struct miscdevice xenbus_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbus",
+	.fops = &xen_xenbus_fops,
+};
+
+static int __init xenbus_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbus_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus device\n");
+	return err;
+}
+
+static void __exit xenbus_exit(void)
+{
+	misc_deregister(&xenbus_dev);
+}
+
+module_init(xenbus_init);
+module_exit(xenbus_exit);
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 5d45ff1..b019865 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o
+xenfs-y			  = super.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index a55fbf9..a84b53c 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -17,6 +17,7 @@
 
 #include "xenfs.h"
 #include "../privcmd.h"
+#include "../xenbus/xenbus_comms.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -83,7 +84,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
 	static struct tree_descr xenfs_files[] = {
 		[1] = {},
-		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
+		{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
 		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
diff --git a/drivers/xen/xenfs/xenbus.c b/drivers/xen/xenfs/xenbus.c
deleted file mode 100644
index bbd000f..0000000
--- a/drivers/xen/xenfs/xenbus.c
+++ /dev/null
@@ -1,593 +0,0 @@
-/*
- * Driver giving user-space access to the kernel's xenbus connection
- * to xenstore.
- *
- * Copyright (c) 2005, Christian Limpach
- * Copyright (c) 2005, Rusty Russell, IBM Corporation
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation; or, when distributed
- * separately from the Linux kernel or incorporated into other
- * software packages, subject to the following license:
- *
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this source file (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use, copy, modify,
- * merge, publish, distribute, sublicense, and/or sell copies of the Software,
- * and to permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
- * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
- * IN THE SOFTWARE.
- *
- * Changes:
- * 2008-10-07  Alex Zeffertt    Replaced /proc/xen/xenbus with xenfs filesystem
- *                              and /proc/xen compatibility mount point.
- *                              Turned xenfs into a loadable module.
- */
-
-#include <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/uio.h>
-#include <linux/notifier.h>
-#include <linux/wait.h>
-#include <linux/fs.h>
-#include <linux/poll.h>
-#include <linux/mutex.h>
-#include <linux/sched.h>
-#include <linux/spinlock.h>
-#include <linux/mount.h>
-#include <linux/pagemap.h>
-#include <linux/uaccess.h>
-#include <linux/init.h>
-#include <linux/namei.h>
-#include <linux/string.h>
-#include <linux/slab.h>
-
-#include "xenfs.h"
-#include "../xenbus/xenbus_comms.h"
-
-#include <xen/xenbus.h>
-#include <asm/xen/hypervisor.h>
-
-/*
- * An element of a list of outstanding transactions, for which we're
- * still waiting a reply.
- */
-struct xenbus_transaction_holder {
-	struct list_head list;
-	struct xenbus_transaction handle;
-};
-
-/*
- * A buffer of data on the queue.
- */
-struct read_buffer {
-	struct list_head list;
-	unsigned int cons;
-	unsigned int len;
-	char msg[];
-};
-
-struct xenbus_file_priv {
-	/*
-	 * msgbuffer_mutex is held while partial requests are built up
-	 * and complete requests are acted on.  It therefore protects
-	 * the "transactions" and "watches" lists, and the partial
-	 * request length and buffer.
-	 *
-	 * reply_mutex protects the reply being built up to return to
-	 * usermode.  It nests inside msgbuffer_mutex but may be held
-	 * alone during a watch callback.
-	 */
-	struct mutex msgbuffer_mutex;
-
-	/* In-progress transactions */
-	struct list_head transactions;
-
-	/* Active watches. */
-	struct list_head watches;
-
-	/* Partial request. */
-	unsigned int len;
-	union {
-		struct xsd_sockmsg msg;
-		char buffer[PAGE_SIZE];
-	} u;
-
-	/* Response queue. */
-	struct mutex reply_mutex;
-	struct list_head read_buffers;
-	wait_queue_head_t read_waitq;
-
-};
-
-/* Read out any raw xenbus messages queued up. */
-static ssize_t xenbus_file_read(struct file *filp,
-			       char __user *ubuf,
-			       size_t len, loff_t *ppos)
-{
-	struct xenbus_file_priv *u = filp->private_data;
-	struct read_buffer *rb;
-	unsigned i;
-	int ret;
-
-	mutex_lock(&u->reply_mutex);
-again:
-	while (list_empty(&u->read_buffers)) {
-		mutex_unlock(&u->reply_mutex);
-		if (filp->f_flags & O_NONBLOCK)
-			return -EAGAIN;
-
-		ret = wait_event_interruptible(u->read_waitq,
-					       !list_empty(&u->read_buffers));
-		if (ret)
-			return ret;
-		mutex_lock(&u->reply_mutex);
-	}
-
-	rb = list_entry(u->read_buffers.next, struct read_buffer, list);
-	i = 0;
-	while (i < len) {
-		unsigned sz = min((unsigned)len - i, rb->len - rb->cons);
-
-		ret = copy_to_user(ubuf + i, &rb->msg[rb->cons], sz);
-
-		i += sz - ret;
-		rb->cons += sz - ret;
-
-		if (ret != 0) {
-			if (i == 0)
-				i = -EFAULT;
-			goto out;
-		}
-
-		/* Clear out buffer if it has been consumed */
-		if (rb->cons == rb->len) {
-			list_del(&rb->list);
-			kfree(rb);
-			if (list_empty(&u->read_buffers))
-				break;
-			rb = list_entry(u->read_buffers.next,
-					struct read_buffer, list);
-		}
-	}
-	if (i == 0)
-		goto again;
-
-out:
-	mutex_unlock(&u->reply_mutex);
-	return i;
-}
-
-/*
- * Add a buffer to the queue.  Caller must hold the appropriate lock
- * if the queue is not local.  (Commonly the caller will build up
- * multiple queued buffers on a temporary local list, and then add it
- * to the appropriate list under lock once all the buffers have een
- * successfully allocated.)
- */
-static int queue_reply(struct list_head *queue, const void *data, size_t len)
-{
-	struct read_buffer *rb;
-
-	if (len == 0)
-		return 0;
-
-	rb = kmalloc(sizeof(*rb) + len, GFP_KERNEL);
-	if (rb == NULL)
-		return -ENOMEM;
-
-	rb->cons = 0;
-	rb->len = len;
-
-	memcpy(rb->msg, data, len);
-
-	list_add_tail(&rb->list, queue);
-	return 0;
-}
-
-/*
- * Free all the read_buffer s on a list.
- * Caller must have sole reference to list.
- */
-static void queue_cleanup(struct list_head *list)
-{
-	struct read_buffer *rb;
-
-	while (!list_empty(list)) {
-		rb = list_entry(list->next, struct read_buffer, list);
-		list_del(list->next);
-		kfree(rb);
-	}
-}
-
-struct watch_adapter {
-	struct list_head list;
-	struct xenbus_watch watch;
-	struct xenbus_file_priv *dev_data;
-	char *token;
-};
-
-static void free_watch_adapter(struct watch_adapter *watch)
-{
-	kfree(watch->watch.node);
-	kfree(watch->token);
-	kfree(watch);
-}
-
-static struct watch_adapter *alloc_watch_adapter(const char *path,
-						 const char *token)
-{
-	struct watch_adapter *watch;
-
-	watch = kzalloc(sizeof(*watch), GFP_KERNEL);
-	if (watch == NULL)
-		goto out_fail;
-
-	watch->watch.node = kstrdup(path, GFP_KERNEL);
-	if (watch->watch.node == NULL)
-		goto out_free;
-
-	watch->token = kstrdup(token, GFP_KERNEL);
-	if (watch->token == NULL)
-		goto out_free;
-
-	return watch;
-
-out_free:
-	free_watch_adapter(watch);
-
-out_fail:
-	return NULL;
-}
-
-static void watch_fired(struct xenbus_watch *watch,
-			const char **vec,
-			unsigned int len)
-{
-	struct watch_adapter *adap;
-	struct xsd_sockmsg hdr;
-	const char *path, *token;
-	int path_len, tok_len, body_len, data_len = 0;
-	int ret;
-	LIST_HEAD(staging_q);
-
-	adap = container_of(watch, struct watch_adapter, watch);
-
-	path = vec[XS_WATCH_PATH];
-	token = adap->token;
-
-	path_len = strlen(path) + 1;
-	tok_len = strlen(token) + 1;
-	if (len > 2)
-		data_len = vec[len] - vec[2] + 1;
-	body_len = path_len + tok_len + data_len;
-
-	hdr.type = XS_WATCH_EVENT;
-	hdr.len = body_len;
-
-	mutex_lock(&adap->dev_data->reply_mutex);
-
-	ret = queue_reply(&staging_q, &hdr, sizeof(hdr));
-	if (!ret)
-		ret = queue_reply(&staging_q, path, path_len);
-	if (!ret)
-		ret = queue_reply(&staging_q, token, tok_len);
-	if (!ret && len > 2)
-		ret = queue_reply(&staging_q, vec[2], data_len);
-
-	if (!ret) {
-		/* success: pass reply list onto watcher */
-		list_splice_tail(&staging_q, &adap->dev_data->read_buffers);
-		wake_up(&adap->dev_data->read_waitq);
-	} else
-		queue_cleanup(&staging_q);
-
-	mutex_unlock(&adap->dev_data->reply_mutex);
-}
-
-static int xenbus_write_transaction(unsigned msg_type,
-				    struct xenbus_file_priv *u)
-{
-	int rc;
-	void *reply;
-	struct xenbus_transaction_holder *trans = NULL;
-	LIST_HEAD(staging_q);
-
-	if (msg_type == XS_TRANSACTION_START) {
-		trans = kmalloc(sizeof(*trans), GFP_KERNEL);
-		if (!trans) {
-			rc = -ENOMEM;
-			goto out;
-		}
-	}
-
-	reply = xenbus_dev_request_and_reply(&u->u.msg);
-	if (IS_ERR(reply)) {
-		kfree(trans);
-		rc = PTR_ERR(reply);
-		goto out;
-	}
-
-	if (msg_type == XS_TRANSACTION_START) {
-		trans->handle.id = simple_strtoul(reply, NULL, 0);
-
-		list_add(&trans->list, &u->transactions);
-	} else if (msg_type == XS_TRANSACTION_END) {
-		list_for_each_entry(trans, &u->transactions, list)
-			if (trans->handle.id == u->u.msg.tx_id)
-				break;
-		BUG_ON(&trans->list == &u->transactions);
-		list_del(&trans->list);
-
-		kfree(trans);
-	}
-
-	mutex_lock(&u->reply_mutex);
-	rc = queue_reply(&staging_q, &u->u.msg, sizeof(u->u.msg));
-	if (!rc)
-		rc = queue_reply(&staging_q, reply, u->u.msg.len);
-	if (!rc) {
-		list_splice_tail(&staging_q, &u->read_buffers);
-		wake_up(&u->read_waitq);
-	} else {
-		queue_cleanup(&staging_q);
-	}
-	mutex_unlock(&u->reply_mutex);
-
-	kfree(reply);
-
-out:
-	return rc;
-}
-
-static int xenbus_write_watch(unsigned msg_type, struct xenbus_file_priv *u)
-{
-	struct watch_adapter *watch, *tmp_watch;
-	char *path, *token;
-	int err, rc;
-	LIST_HEAD(staging_q);
-
-	path = u->u.buffer + sizeof(u->u.msg);
-	token = memchr(path, 0, u->u.msg.len);
-	if (token == NULL) {
-		rc = -EILSEQ;
-		goto out;
-	}
-	token++;
-
-	if (msg_type == XS_WATCH) {
-		watch = alloc_watch_adapter(path, token);
-		if (watch == NULL) {
-			rc = -ENOMEM;
-			goto out;
-		}
-
-		watch->watch.callback = watch_fired;
-		watch->dev_data = u;
-
-		err = register_xenbus_watch(&watch->watch);
-		if (err) {
-			free_watch_adapter(watch);
-			rc = err;
-			goto out;
-		}
-		list_add(&watch->list, &u->watches);
-	} else {
-		list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
-			if (!strcmp(watch->token, token) &&
-			    !strcmp(watch->watch.node, path)) {
-				unregister_xenbus_watch(&watch->watch);
-				list_del(&watch->list);
-				free_watch_adapter(watch);
-				break;
-			}
-		}
-	}
-
-	/* Success.  Synthesize a reply to say all is OK. */
-	{
-		struct {
-			struct xsd_sockmsg hdr;
-			char body[3];
-		} __packed reply = {
-			{
-				.type = msg_type,
-				.len = sizeof(reply.body)
-			},
-			"OK"
-		};
-
-		mutex_lock(&u->reply_mutex);
-		rc = queue_reply(&u->read_buffers, &reply, sizeof(reply));
-		wake_up(&u->read_waitq);
-		mutex_unlock(&u->reply_mutex);
-	}
-
-out:
-	return rc;
-}
-
-static ssize_t xenbus_file_write(struct file *filp,
-				const char __user *ubuf,
-				size_t len, loff_t *ppos)
-{
-	struct xenbus_file_priv *u = filp->private_data;
-	uint32_t msg_type;
-	int rc = len;
-	int ret;
-	LIST_HEAD(staging_q);
-
-	/*
-	 * We're expecting usermode to be writing properly formed
-	 * xenbus messages.  If they write an incomplete message we
-	 * buffer it up.  Once it is complete, we act on it.
-	 */
-
-	/*
-	 * Make sure concurrent writers can't stomp all over each
-	 * other's messages and make a mess of our partial message
-	 * buffer.  We don't make any attemppt to stop multiple
-	 * writers from making a mess of each other's incomplete
-	 * messages; we're just trying to guarantee our own internal
-	 * consistency and make sure that single writes are handled
-	 * atomically.
-	 */
-	mutex_lock(&u->msgbuffer_mutex);
-
-	/* Get this out of the way early to avoid confusion */
-	if (len == 0)
-		goto out;
-
-	/* Can't write a xenbus message larger we can buffer */
-	if ((len + u->len) > sizeof(u->u.buffer)) {
-		/* On error, dump existing buffer */
-		u->len = 0;
-		rc = -EINVAL;
-		goto out;
-	}
-
-	ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
-
-	if (ret != 0) {
-		rc = -EFAULT;
-		goto out;
-	}
-
-	/* Deal with a partial copy. */
-	len -= ret;
-	rc = len;
-
-	u->len += len;
-
-	/* Return if we haven't got a full message yet */
-	if (u->len < sizeof(u->u.msg))
-		goto out;	/* not even the header yet */
-
-	/* If we're expecting a message that's larger than we can
-	   possibly send, dump what we have and return an error. */
-	if ((sizeof(u->u.msg) + u->u.msg.len) > sizeof(u->u.buffer)) {
-		rc = -E2BIG;
-		u->len = 0;
-		goto out;
-	}
-
-	if (u->len < (sizeof(u->u.msg) + u->u.msg.len))
-		goto out;	/* incomplete data portion */
-
-	/*
-	 * OK, now we have a complete message.  Do something with it.
-	 */
-
-	msg_type = u->u.msg.type;
-
-	switch (msg_type) {
-	case XS_WATCH:
-	case XS_UNWATCH:
-		/* (Un)Ask for some path to be watched for changes */
-		ret = xenbus_write_watch(msg_type, u);
-		break;
-
-	default:
-		/* Send out a transaction */
-		ret = xenbus_write_transaction(msg_type, u);
-		break;
-	}
-	if (ret != 0)
-		rc = ret;
-
-	/* Buffered message consumed */
-	u->len = 0;
-
- out:
-	mutex_unlock(&u->msgbuffer_mutex);
-	return rc;
-}
-
-static int xenbus_file_open(struct inode *inode, struct file *filp)
-{
-	struct xenbus_file_priv *u;
-
-	if (xen_store_evtchn == 0)
-		return -ENOENT;
-
-	nonseekable_open(inode, filp);
-
-	u = kzalloc(sizeof(*u), GFP_KERNEL);
-	if (u == NULL)
-		return -ENOMEM;
-
-	INIT_LIST_HEAD(&u->transactions);
-	INIT_LIST_HEAD(&u->watches);
-	INIT_LIST_HEAD(&u->read_buffers);
-	init_waitqueue_head(&u->read_waitq);
-
-	mutex_init(&u->reply_mutex);
-	mutex_init(&u->msgbuffer_mutex);
-
-	filp->private_data = u;
-
-	return 0;
-}
-
-static int xenbus_file_release(struct inode *inode, struct file *filp)
-{
-	struct xenbus_file_priv *u = filp->private_data;
-	struct xenbus_transaction_holder *trans, *tmp;
-	struct watch_adapter *watch, *tmp_watch;
-	struct read_buffer *rb, *tmp_rb;
-
-	/*
-	 * No need for locking here because there are no other users,
-	 * by definition.
-	 */
-
-	list_for_each_entry_safe(trans, tmp, &u->transactions, list) {
-		xenbus_transaction_end(trans->handle, 1);
-		list_del(&trans->list);
-		kfree(trans);
-	}
-
-	list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
-		unregister_xenbus_watch(&watch->watch);
-		list_del(&watch->list);
-		free_watch_adapter(watch);
-	}
-
-	list_for_each_entry_safe(rb, tmp_rb, &u->read_buffers, list) {
-		list_del(&rb->list);
-		kfree(rb);
-	}
-	kfree(u);
-
-	return 0;
-}
-
-static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
-{
-	struct xenbus_file_priv *u = file->private_data;
-
-	poll_wait(file, &u->read_waitq, wait);
-	if (!list_empty(&u->read_buffers))
-		return POLLIN | POLLRDNORM;
-	return 0;
-}
-
-const struct file_operations xenbus_file_ops = {
-	.read = xenbus_file_read,
-	.write = xenbus_file_write,
-	.open = xenbus_file_open,
-	.release = xenbus_file_release,
-	.poll = xenbus_file_poll,
-	.llseek = no_llseek,
-};
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index 5056306..6b80c77 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -1,7 +1,6 @@
 #ifndef _XENFS_XENBUS_H
 #define _XENFS_XENBUS_H
 
-extern const struct file_operations xenbus_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:08:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:08:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmtN-000400-7X; Sun, 27 Nov 2011 22:08:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RUmtK-0003ya-UM
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:08:07 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322431649!6008647!1
X-Originating-IP: [82.139.201.20]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20579 invoked from network); 27 Nov 2011 22:07:30 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Nov 2011 22:07:30 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 9F9CB54229; Sun, 27 Nov 2011 23:07:28 +0100 (CET)
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xensource.com
Date: Sun, 27 Nov 2011 23:07:07 +0100
Message-Id: <1322431628-21760-5-git-send-email-waldi@debian.org>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
Cc: Bastian Blank <waldi@debian.org>
Subject: [Xen-devel] [PATCH 4/5] xen: Add xenbus device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Access to xenbus is currently handled via xenfs. This adds a device
driver for xenbus and makes xenfs use this code.

Signed-off-by: Bastian Blank <waldi@debian.org>
---
 drivers/xen/xenbus/Makefile              |    1 +
 drivers/xen/xenbus/xenbus_comms.h        |    4 +
 drivers/xen/xenbus/xenbus_dev_frontend.c |  624 ++++++++++++++++++++++++++++++
 drivers/xen/xenfs/Makefile               |    2 +-
 drivers/xen/xenfs/super.c                |    3 +-
 drivers/xen/xenfs/xenbus.c               |  593 ----------------------------
 drivers/xen/xenfs/xenfs.h                |    1 -
 7 files changed, 632 insertions(+), 596 deletions(-)
 create mode 100644 drivers/xen/xenbus/xenbus_dev_frontend.c
 delete mode 100644 drivers/xen/xenfs/xenbus.c

diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
index 8dca685..a2ea363 100644
--- a/drivers/xen/xenbus/Makefile
+++ b/drivers/xen/xenbus/Makefile
@@ -1,4 +1,5 @@
 obj-y	+= xenbus.o
+obj-y	+= xenbus_dev_frontend.o
 
 xenbus-objs =
 xenbus-objs += xenbus_client.o
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index c21db75..6e42800 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -31,6 +31,8 @@
 #ifndef _XENBUS_COMMS_H
 #define _XENBUS_COMMS_H
 
+#include <linux/fs.h>
+
 int xs_init(void);
 int xb_init_comms(void);
 
@@ -43,4 +45,6 @@ int xs_input_avail(void);
 extern struct xenstore_domain_interface *xen_store_interface;
 extern int xen_store_evtchn;
 
+extern const struct file_operations xen_xenbus_fops;
+
 #endif /* _XENBUS_COMMS_H */
diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
new file mode 100644
index 0000000..fb30cff
--- /dev/null
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -0,0 +1,624 @@
+/*
+ * Driver giving user-space access to the kernel's xenbus connection
+ * to xenstore.
+ *
+ * Copyright (c) 2005, Christian Limpach
+ * Copyright (c) 2005, Rusty Russell, IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Changes:
+ * 2008-10-07  Alex Zeffertt    Replaced /proc/xen/xenbus with xenfs filesystem
+ *                              and /proc/xen compatibility mount point.
+ *                              Turned xenfs into a loadable module.
+ */
+
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/uio.h>
+#include <linux/notifier.h>
+#include <linux/wait.h>
+#include <linux/fs.h>
+#include <linux/poll.h>
+#include <linux/mutex.h>
+#include <linux/sched.h>
+#include <linux/spinlock.h>
+#include <linux/mount.h>
+#include <linux/pagemap.h>
+#include <linux/uaccess.h>
+#include <linux/init.h>
+#include <linux/namei.h>
+#include <linux/string.h>
+#include <linux/slab.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+
+#include "xenbus_comms.h"
+
+#include <xen/xenbus.h>
+#include <asm/xen/hypervisor.h>
+
+MODULE_LICENSE("GPL");
+
+/*
+ * An element of a list of outstanding transactions, for which we're
+ * still waiting a reply.
+ */
+struct xenbus_transaction_holder {
+	struct list_head list;
+	struct xenbus_transaction handle;
+};
+
+/*
+ * A buffer of data on the queue.
+ */
+struct read_buffer {
+	struct list_head list;
+	unsigned int cons;
+	unsigned int len;
+	char msg[];
+};
+
+struct xenbus_file_priv {
+	/*
+	 * msgbuffer_mutex is held while partial requests are built up
+	 * and complete requests are acted on.  It therefore protects
+	 * the "transactions" and "watches" lists, and the partial
+	 * request length and buffer.
+	 *
+	 * reply_mutex protects the reply being built up to return to
+	 * usermode.  It nests inside msgbuffer_mutex but may be held
+	 * alone during a watch callback.
+	 */
+	struct mutex msgbuffer_mutex;
+
+	/* In-progress transactions */
+	struct list_head transactions;
+
+	/* Active watches. */
+	struct list_head watches;
+
+	/* Partial request. */
+	unsigned int len;
+	union {
+		struct xsd_sockmsg msg;
+		char buffer[PAGE_SIZE];
+	} u;
+
+	/* Response queue. */
+	struct mutex reply_mutex;
+	struct list_head read_buffers;
+	wait_queue_head_t read_waitq;
+
+};
+
+/* Read out any raw xenbus messages queued up. */
+static ssize_t xenbus_file_read(struct file *filp,
+			       char __user *ubuf,
+			       size_t len, loff_t *ppos)
+{
+	struct xenbus_file_priv *u = filp->private_data;
+	struct read_buffer *rb;
+	unsigned i;
+	int ret;
+
+	mutex_lock(&u->reply_mutex);
+again:
+	while (list_empty(&u->read_buffers)) {
+		mutex_unlock(&u->reply_mutex);
+		if (filp->f_flags & O_NONBLOCK)
+			return -EAGAIN;
+
+		ret = wait_event_interruptible(u->read_waitq,
+					       !list_empty(&u->read_buffers));
+		if (ret)
+			return ret;
+		mutex_lock(&u->reply_mutex);
+	}
+
+	rb = list_entry(u->read_buffers.next, struct read_buffer, list);
+	i = 0;
+	while (i < len) {
+		unsigned sz = min((unsigned)len - i, rb->len - rb->cons);
+
+		ret = copy_to_user(ubuf + i, &rb->msg[rb->cons], sz);
+
+		i += sz - ret;
+		rb->cons += sz - ret;
+
+		if (ret != 0) {
+			if (i == 0)
+				i = -EFAULT;
+			goto out;
+		}
+
+		/* Clear out buffer if it has been consumed */
+		if (rb->cons == rb->len) {
+			list_del(&rb->list);
+			kfree(rb);
+			if (list_empty(&u->read_buffers))
+				break;
+			rb = list_entry(u->read_buffers.next,
+					struct read_buffer, list);
+		}
+	}
+	if (i == 0)
+		goto again;
+
+out:
+	mutex_unlock(&u->reply_mutex);
+	return i;
+}
+
+/*
+ * Add a buffer to the queue.  Caller must hold the appropriate lock
+ * if the queue is not local.  (Commonly the caller will build up
+ * multiple queued buffers on a temporary local list, and then add it
+ * to the appropriate list under lock once all the buffers have een
+ * successfully allocated.)
+ */
+static int queue_reply(struct list_head *queue, const void *data, size_t len)
+{
+	struct read_buffer *rb;
+
+	if (len == 0)
+		return 0;
+
+	rb = kmalloc(sizeof(*rb) + len, GFP_KERNEL);
+	if (rb == NULL)
+		return -ENOMEM;
+
+	rb->cons = 0;
+	rb->len = len;
+
+	memcpy(rb->msg, data, len);
+
+	list_add_tail(&rb->list, queue);
+	return 0;
+}
+
+/*
+ * Free all the read_buffer s on a list.
+ * Caller must have sole reference to list.
+ */
+static void queue_cleanup(struct list_head *list)
+{
+	struct read_buffer *rb;
+
+	while (!list_empty(list)) {
+		rb = list_entry(list->next, struct read_buffer, list);
+		list_del(list->next);
+		kfree(rb);
+	}
+}
+
+struct watch_adapter {
+	struct list_head list;
+	struct xenbus_watch watch;
+	struct xenbus_file_priv *dev_data;
+	char *token;
+};
+
+static void free_watch_adapter(struct watch_adapter *watch)
+{
+	kfree(watch->watch.node);
+	kfree(watch->token);
+	kfree(watch);
+}
+
+static struct watch_adapter *alloc_watch_adapter(const char *path,
+						 const char *token)
+{
+	struct watch_adapter *watch;
+
+	watch = kzalloc(sizeof(*watch), GFP_KERNEL);
+	if (watch == NULL)
+		goto out_fail;
+
+	watch->watch.node = kstrdup(path, GFP_KERNEL);
+	if (watch->watch.node == NULL)
+		goto out_free;
+
+	watch->token = kstrdup(token, GFP_KERNEL);
+	if (watch->token == NULL)
+		goto out_free;
+
+	return watch;
+
+out_free:
+	free_watch_adapter(watch);
+
+out_fail:
+	return NULL;
+}
+
+static void watch_fired(struct xenbus_watch *watch,
+			const char **vec,
+			unsigned int len)
+{
+	struct watch_adapter *adap;
+	struct xsd_sockmsg hdr;
+	const char *path, *token;
+	int path_len, tok_len, body_len, data_len = 0;
+	int ret;
+	LIST_HEAD(staging_q);
+
+	adap = container_of(watch, struct watch_adapter, watch);
+
+	path = vec[XS_WATCH_PATH];
+	token = adap->token;
+
+	path_len = strlen(path) + 1;
+	tok_len = strlen(token) + 1;
+	if (len > 2)
+		data_len = vec[len] - vec[2] + 1;
+	body_len = path_len + tok_len + data_len;
+
+	hdr.type = XS_WATCH_EVENT;
+	hdr.len = body_len;
+
+	mutex_lock(&adap->dev_data->reply_mutex);
+
+	ret = queue_reply(&staging_q, &hdr, sizeof(hdr));
+	if (!ret)
+		ret = queue_reply(&staging_q, path, path_len);
+	if (!ret)
+		ret = queue_reply(&staging_q, token, tok_len);
+	if (!ret && len > 2)
+		ret = queue_reply(&staging_q, vec[2], data_len);
+
+	if (!ret) {
+		/* success: pass reply list onto watcher */
+		list_splice_tail(&staging_q, &adap->dev_data->read_buffers);
+		wake_up(&adap->dev_data->read_waitq);
+	} else
+		queue_cleanup(&staging_q);
+
+	mutex_unlock(&adap->dev_data->reply_mutex);
+}
+
+static int xenbus_write_transaction(unsigned msg_type,
+				    struct xenbus_file_priv *u)
+{
+	int rc;
+	void *reply;
+	struct xenbus_transaction_holder *trans = NULL;
+	LIST_HEAD(staging_q);
+
+	if (msg_type == XS_TRANSACTION_START) {
+		trans = kmalloc(sizeof(*trans), GFP_KERNEL);
+		if (!trans) {
+			rc = -ENOMEM;
+			goto out;
+		}
+	}
+
+	reply = xenbus_dev_request_and_reply(&u->u.msg);
+	if (IS_ERR(reply)) {
+		kfree(trans);
+		rc = PTR_ERR(reply);
+		goto out;
+	}
+
+	if (msg_type == XS_TRANSACTION_START) {
+		trans->handle.id = simple_strtoul(reply, NULL, 0);
+
+		list_add(&trans->list, &u->transactions);
+	} else if (msg_type == XS_TRANSACTION_END) {
+		list_for_each_entry(trans, &u->transactions, list)
+			if (trans->handle.id == u->u.msg.tx_id)
+				break;
+		BUG_ON(&trans->list == &u->transactions);
+		list_del(&trans->list);
+
+		kfree(trans);
+	}
+
+	mutex_lock(&u->reply_mutex);
+	rc = queue_reply(&staging_q, &u->u.msg, sizeof(u->u.msg));
+	if (!rc)
+		rc = queue_reply(&staging_q, reply, u->u.msg.len);
+	if (!rc) {
+		list_splice_tail(&staging_q, &u->read_buffers);
+		wake_up(&u->read_waitq);
+	} else {
+		queue_cleanup(&staging_q);
+	}
+	mutex_unlock(&u->reply_mutex);
+
+	kfree(reply);
+
+out:
+	return rc;
+}
+
+static int xenbus_write_watch(unsigned msg_type, struct xenbus_file_priv *u)
+{
+	struct watch_adapter *watch, *tmp_watch;
+	char *path, *token;
+	int err, rc;
+	LIST_HEAD(staging_q);
+
+	path = u->u.buffer + sizeof(u->u.msg);
+	token = memchr(path, 0, u->u.msg.len);
+	if (token == NULL) {
+		rc = -EILSEQ;
+		goto out;
+	}
+	token++;
+
+	if (msg_type == XS_WATCH) {
+		watch = alloc_watch_adapter(path, token);
+		if (watch == NULL) {
+			rc = -ENOMEM;
+			goto out;
+		}
+
+		watch->watch.callback = watch_fired;
+		watch->dev_data = u;
+
+		err = register_xenbus_watch(&watch->watch);
+		if (err) {
+			free_watch_adapter(watch);
+			rc = err;
+			goto out;
+		}
+		list_add(&watch->list, &u->watches);
+	} else {
+		list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
+			if (!strcmp(watch->token, token) &&
+			    !strcmp(watch->watch.node, path)) {
+				unregister_xenbus_watch(&watch->watch);
+				list_del(&watch->list);
+				free_watch_adapter(watch);
+				break;
+			}
+		}
+	}
+
+	/* Success.  Synthesize a reply to say all is OK. */
+	{
+		struct {
+			struct xsd_sockmsg hdr;
+			char body[3];
+		} __packed reply = {
+			{
+				.type = msg_type,
+				.len = sizeof(reply.body)
+			},
+			"OK"
+		};
+
+		mutex_lock(&u->reply_mutex);
+		rc = queue_reply(&u->read_buffers, &reply, sizeof(reply));
+		wake_up(&u->read_waitq);
+		mutex_unlock(&u->reply_mutex);
+	}
+
+out:
+	return rc;
+}
+
+static ssize_t xenbus_file_write(struct file *filp,
+				const char __user *ubuf,
+				size_t len, loff_t *ppos)
+{
+	struct xenbus_file_priv *u = filp->private_data;
+	uint32_t msg_type;
+	int rc = len;
+	int ret;
+	LIST_HEAD(staging_q);
+
+	/*
+	 * We're expecting usermode to be writing properly formed
+	 * xenbus messages.  If they write an incomplete message we
+	 * buffer it up.  Once it is complete, we act on it.
+	 */
+
+	/*
+	 * Make sure concurrent writers can't stomp all over each
+	 * other's messages and make a mess of our partial message
+	 * buffer.  We don't make any attemppt to stop multiple
+	 * writers from making a mess of each other's incomplete
+	 * messages; we're just trying to guarantee our own internal
+	 * consistency and make sure that single writes are handled
+	 * atomically.
+	 */
+	mutex_lock(&u->msgbuffer_mutex);
+
+	/* Get this out of the way early to avoid confusion */
+	if (len == 0)
+		goto out;
+
+	/* Can't write a xenbus message larger we can buffer */
+	if ((len + u->len) > sizeof(u->u.buffer)) {
+		/* On error, dump existing buffer */
+		u->len = 0;
+		rc = -EINVAL;
+		goto out;
+	}
+
+	ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
+
+	if (ret != 0) {
+		rc = -EFAULT;
+		goto out;
+	}
+
+	/* Deal with a partial copy. */
+	len -= ret;
+	rc = len;
+
+	u->len += len;
+
+	/* Return if we haven't got a full message yet */
+	if (u->len < sizeof(u->u.msg))
+		goto out;	/* not even the header yet */
+
+	/* If we're expecting a message that's larger than we can
+	   possibly send, dump what we have and return an error. */
+	if ((sizeof(u->u.msg) + u->u.msg.len) > sizeof(u->u.buffer)) {
+		rc = -E2BIG;
+		u->len = 0;
+		goto out;
+	}
+
+	if (u->len < (sizeof(u->u.msg) + u->u.msg.len))
+		goto out;	/* incomplete data portion */
+
+	/*
+	 * OK, now we have a complete message.  Do something with it.
+	 */
+
+	msg_type = u->u.msg.type;
+
+	switch (msg_type) {
+	case XS_WATCH:
+	case XS_UNWATCH:
+		/* (Un)Ask for some path to be watched for changes */
+		ret = xenbus_write_watch(msg_type, u);
+		break;
+
+	default:
+		/* Send out a transaction */
+		ret = xenbus_write_transaction(msg_type, u);
+		break;
+	}
+	if (ret != 0)
+		rc = ret;
+
+	/* Buffered message consumed */
+	u->len = 0;
+
+ out:
+	mutex_unlock(&u->msgbuffer_mutex);
+	return rc;
+}
+
+static int xenbus_file_open(struct inode *inode, struct file *filp)
+{
+	struct xenbus_file_priv *u;
+
+	if (xen_store_evtchn == 0)
+		return -ENOENT;
+
+	nonseekable_open(inode, filp);
+
+	u = kzalloc(sizeof(*u), GFP_KERNEL);
+	if (u == NULL)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&u->transactions);
+	INIT_LIST_HEAD(&u->watches);
+	INIT_LIST_HEAD(&u->read_buffers);
+	init_waitqueue_head(&u->read_waitq);
+
+	mutex_init(&u->reply_mutex);
+	mutex_init(&u->msgbuffer_mutex);
+
+	filp->private_data = u;
+
+	return 0;
+}
+
+static int xenbus_file_release(struct inode *inode, struct file *filp)
+{
+	struct xenbus_file_priv *u = filp->private_data;
+	struct xenbus_transaction_holder *trans, *tmp;
+	struct watch_adapter *watch, *tmp_watch;
+	struct read_buffer *rb, *tmp_rb;
+
+	/*
+	 * No need for locking here because there are no other users,
+	 * by definition.
+	 */
+
+	list_for_each_entry_safe(trans, tmp, &u->transactions, list) {
+		xenbus_transaction_end(trans->handle, 1);
+		list_del(&trans->list);
+		kfree(trans);
+	}
+
+	list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
+		unregister_xenbus_watch(&watch->watch);
+		list_del(&watch->list);
+		free_watch_adapter(watch);
+	}
+
+	list_for_each_entry_safe(rb, tmp_rb, &u->read_buffers, list) {
+		list_del(&rb->list);
+		kfree(rb);
+	}
+	kfree(u);
+
+	return 0;
+}
+
+static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
+{
+	struct xenbus_file_priv *u = file->private_data;
+
+	poll_wait(file, &u->read_waitq, wait);
+	if (!list_empty(&u->read_buffers))
+		return POLLIN | POLLRDNORM;
+	return 0;
+}
+
+const struct file_operations xen_xenbus_fops = {
+	.read = xenbus_file_read,
+	.write = xenbus_file_write,
+	.open = xenbus_file_open,
+	.release = xenbus_file_release,
+	.poll = xenbus_file_poll,
+	.llseek = no_llseek,
+};
+EXPORT_SYMBOL_GPL(xen_xenbus_fops);
+
+static struct miscdevice xenbus_dev = {
+	.minor = MISC_DYNAMIC_MINOR,
+	.name = "xen/xenbus",
+	.fops = &xen_xenbus_fops,
+};
+
+static int __init xenbus_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = misc_register(&xenbus_dev);
+	if (err)
+		printk(KERN_ERR "Could not register xenbus device\n");
+	return err;
+}
+
+static void __exit xenbus_exit(void)
+{
+	misc_deregister(&xenbus_dev);
+}
+
+module_init(xenbus_init);
+module_exit(xenbus_exit);
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 5d45ff1..b019865 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,4 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o
+xenfs-y			  = super.o
 xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index a55fbf9..a84b53c 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -17,6 +17,7 @@
 
 #include "xenfs.h"
 #include "../privcmd.h"
+#include "../xenbus/xenbus_comms.h"
 
 #include <asm/xen/hypervisor.h>
 
@@ -83,7 +84,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
 	static struct tree_descr xenfs_files[] = {
 		[1] = {},
-		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
+		{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
 		{ "capabilities", &capabilities_file_ops, S_IRUGO },
 		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
 		{""},
diff --git a/drivers/xen/xenfs/xenbus.c b/drivers/xen/xenfs/xenbus.c
deleted file mode 100644
index bbd000f..0000000
--- a/drivers/xen/xenfs/xenbus.c
+++ /dev/null
@@ -1,593 +0,0 @@
-/*
- * Driver giving user-space access to the kernel's xenbus connection
- * to xenstore.
- *
- * Copyright (c) 2005, Christian Limpach
- * Copyright (c) 2005, Rusty Russell, IBM Corporation
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation; or, when distributed
- * separately from the Linux kernel or incorporated into other
- * software packages, subject to the following license:
- *
- * Permission is hereby granted, free of charge, to any person obtaining a copy
- * of this source file (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use, copy, modify,
- * merge, publish, distribute, sublicense, and/or sell copies of the Software,
- * and to permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
- * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
- * IN THE SOFTWARE.
- *
- * Changes:
- * 2008-10-07  Alex Zeffertt    Replaced /proc/xen/xenbus with xenfs filesystem
- *                              and /proc/xen compatibility mount point.
- *                              Turned xenfs into a loadable module.
- */
-
-#include <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/uio.h>
-#include <linux/notifier.h>
-#include <linux/wait.h>
-#include <linux/fs.h>
-#include <linux/poll.h>
-#include <linux/mutex.h>
-#include <linux/sched.h>
-#include <linux/spinlock.h>
-#include <linux/mount.h>
-#include <linux/pagemap.h>
-#include <linux/uaccess.h>
-#include <linux/init.h>
-#include <linux/namei.h>
-#include <linux/string.h>
-#include <linux/slab.h>
-
-#include "xenfs.h"
-#include "../xenbus/xenbus_comms.h"
-
-#include <xen/xenbus.h>
-#include <asm/xen/hypervisor.h>
-
-/*
- * An element of a list of outstanding transactions, for which we're
- * still waiting a reply.
- */
-struct xenbus_transaction_holder {
-	struct list_head list;
-	struct xenbus_transaction handle;
-};
-
-/*
- * A buffer of data on the queue.
- */
-struct read_buffer {
-	struct list_head list;
-	unsigned int cons;
-	unsigned int len;
-	char msg[];
-};
-
-struct xenbus_file_priv {
-	/*
-	 * msgbuffer_mutex is held while partial requests are built up
-	 * and complete requests are acted on.  It therefore protects
-	 * the "transactions" and "watches" lists, and the partial
-	 * request length and buffer.
-	 *
-	 * reply_mutex protects the reply being built up to return to
-	 * usermode.  It nests inside msgbuffer_mutex but may be held
-	 * alone during a watch callback.
-	 */
-	struct mutex msgbuffer_mutex;
-
-	/* In-progress transactions */
-	struct list_head transactions;
-
-	/* Active watches. */
-	struct list_head watches;
-
-	/* Partial request. */
-	unsigned int len;
-	union {
-		struct xsd_sockmsg msg;
-		char buffer[PAGE_SIZE];
-	} u;
-
-	/* Response queue. */
-	struct mutex reply_mutex;
-	struct list_head read_buffers;
-	wait_queue_head_t read_waitq;
-
-};
-
-/* Read out any raw xenbus messages queued up. */
-static ssize_t xenbus_file_read(struct file *filp,
-			       char __user *ubuf,
-			       size_t len, loff_t *ppos)
-{
-	struct xenbus_file_priv *u = filp->private_data;
-	struct read_buffer *rb;
-	unsigned i;
-	int ret;
-
-	mutex_lock(&u->reply_mutex);
-again:
-	while (list_empty(&u->read_buffers)) {
-		mutex_unlock(&u->reply_mutex);
-		if (filp->f_flags & O_NONBLOCK)
-			return -EAGAIN;
-
-		ret = wait_event_interruptible(u->read_waitq,
-					       !list_empty(&u->read_buffers));
-		if (ret)
-			return ret;
-		mutex_lock(&u->reply_mutex);
-	}
-
-	rb = list_entry(u->read_buffers.next, struct read_buffer, list);
-	i = 0;
-	while (i < len) {
-		unsigned sz = min((unsigned)len - i, rb->len - rb->cons);
-
-		ret = copy_to_user(ubuf + i, &rb->msg[rb->cons], sz);
-
-		i += sz - ret;
-		rb->cons += sz - ret;
-
-		if (ret != 0) {
-			if (i == 0)
-				i = -EFAULT;
-			goto out;
-		}
-
-		/* Clear out buffer if it has been consumed */
-		if (rb->cons == rb->len) {
-			list_del(&rb->list);
-			kfree(rb);
-			if (list_empty(&u->read_buffers))
-				break;
-			rb = list_entry(u->read_buffers.next,
-					struct read_buffer, list);
-		}
-	}
-	if (i == 0)
-		goto again;
-
-out:
-	mutex_unlock(&u->reply_mutex);
-	return i;
-}
-
-/*
- * Add a buffer to the queue.  Caller must hold the appropriate lock
- * if the queue is not local.  (Commonly the caller will build up
- * multiple queued buffers on a temporary local list, and then add it
- * to the appropriate list under lock once all the buffers have een
- * successfully allocated.)
- */
-static int queue_reply(struct list_head *queue, const void *data, size_t len)
-{
-	struct read_buffer *rb;
-
-	if (len == 0)
-		return 0;
-
-	rb = kmalloc(sizeof(*rb) + len, GFP_KERNEL);
-	if (rb == NULL)
-		return -ENOMEM;
-
-	rb->cons = 0;
-	rb->len = len;
-
-	memcpy(rb->msg, data, len);
-
-	list_add_tail(&rb->list, queue);
-	return 0;
-}
-
-/*
- * Free all the read_buffer s on a list.
- * Caller must have sole reference to list.
- */
-static void queue_cleanup(struct list_head *list)
-{
-	struct read_buffer *rb;
-
-	while (!list_empty(list)) {
-		rb = list_entry(list->next, struct read_buffer, list);
-		list_del(list->next);
-		kfree(rb);
-	}
-}
-
-struct watch_adapter {
-	struct list_head list;
-	struct xenbus_watch watch;
-	struct xenbus_file_priv *dev_data;
-	char *token;
-};
-
-static void free_watch_adapter(struct watch_adapter *watch)
-{
-	kfree(watch->watch.node);
-	kfree(watch->token);
-	kfree(watch);
-}
-
-static struct watch_adapter *alloc_watch_adapter(const char *path,
-						 const char *token)
-{
-	struct watch_adapter *watch;
-
-	watch = kzalloc(sizeof(*watch), GFP_KERNEL);
-	if (watch == NULL)
-		goto out_fail;
-
-	watch->watch.node = kstrdup(path, GFP_KERNEL);
-	if (watch->watch.node == NULL)
-		goto out_free;
-
-	watch->token = kstrdup(token, GFP_KERNEL);
-	if (watch->token == NULL)
-		goto out_free;
-
-	return watch;
-
-out_free:
-	free_watch_adapter(watch);
-
-out_fail:
-	return NULL;
-}
-
-static void watch_fired(struct xenbus_watch *watch,
-			const char **vec,
-			unsigned int len)
-{
-	struct watch_adapter *adap;
-	struct xsd_sockmsg hdr;
-	const char *path, *token;
-	int path_len, tok_len, body_len, data_len = 0;
-	int ret;
-	LIST_HEAD(staging_q);
-
-	adap = container_of(watch, struct watch_adapter, watch);
-
-	path = vec[XS_WATCH_PATH];
-	token = adap->token;
-
-	path_len = strlen(path) + 1;
-	tok_len = strlen(token) + 1;
-	if (len > 2)
-		data_len = vec[len] - vec[2] + 1;
-	body_len = path_len + tok_len + data_len;
-
-	hdr.type = XS_WATCH_EVENT;
-	hdr.len = body_len;
-
-	mutex_lock(&adap->dev_data->reply_mutex);
-
-	ret = queue_reply(&staging_q, &hdr, sizeof(hdr));
-	if (!ret)
-		ret = queue_reply(&staging_q, path, path_len);
-	if (!ret)
-		ret = queue_reply(&staging_q, token, tok_len);
-	if (!ret && len > 2)
-		ret = queue_reply(&staging_q, vec[2], data_len);
-
-	if (!ret) {
-		/* success: pass reply list onto watcher */
-		list_splice_tail(&staging_q, &adap->dev_data->read_buffers);
-		wake_up(&adap->dev_data->read_waitq);
-	} else
-		queue_cleanup(&staging_q);
-
-	mutex_unlock(&adap->dev_data->reply_mutex);
-}
-
-static int xenbus_write_transaction(unsigned msg_type,
-				    struct xenbus_file_priv *u)
-{
-	int rc;
-	void *reply;
-	struct xenbus_transaction_holder *trans = NULL;
-	LIST_HEAD(staging_q);
-
-	if (msg_type == XS_TRANSACTION_START) {
-		trans = kmalloc(sizeof(*trans), GFP_KERNEL);
-		if (!trans) {
-			rc = -ENOMEM;
-			goto out;
-		}
-	}
-
-	reply = xenbus_dev_request_and_reply(&u->u.msg);
-	if (IS_ERR(reply)) {
-		kfree(trans);
-		rc = PTR_ERR(reply);
-		goto out;
-	}
-
-	if (msg_type == XS_TRANSACTION_START) {
-		trans->handle.id = simple_strtoul(reply, NULL, 0);
-
-		list_add(&trans->list, &u->transactions);
-	} else if (msg_type == XS_TRANSACTION_END) {
-		list_for_each_entry(trans, &u->transactions, list)
-			if (trans->handle.id == u->u.msg.tx_id)
-				break;
-		BUG_ON(&trans->list == &u->transactions);
-		list_del(&trans->list);
-
-		kfree(trans);
-	}
-
-	mutex_lock(&u->reply_mutex);
-	rc = queue_reply(&staging_q, &u->u.msg, sizeof(u->u.msg));
-	if (!rc)
-		rc = queue_reply(&staging_q, reply, u->u.msg.len);
-	if (!rc) {
-		list_splice_tail(&staging_q, &u->read_buffers);
-		wake_up(&u->read_waitq);
-	} else {
-		queue_cleanup(&staging_q);
-	}
-	mutex_unlock(&u->reply_mutex);
-
-	kfree(reply);
-
-out:
-	return rc;
-}
-
-static int xenbus_write_watch(unsigned msg_type, struct xenbus_file_priv *u)
-{
-	struct watch_adapter *watch, *tmp_watch;
-	char *path, *token;
-	int err, rc;
-	LIST_HEAD(staging_q);
-
-	path = u->u.buffer + sizeof(u->u.msg);
-	token = memchr(path, 0, u->u.msg.len);
-	if (token == NULL) {
-		rc = -EILSEQ;
-		goto out;
-	}
-	token++;
-
-	if (msg_type == XS_WATCH) {
-		watch = alloc_watch_adapter(path, token);
-		if (watch == NULL) {
-			rc = -ENOMEM;
-			goto out;
-		}
-
-		watch->watch.callback = watch_fired;
-		watch->dev_data = u;
-
-		err = register_xenbus_watch(&watch->watch);
-		if (err) {
-			free_watch_adapter(watch);
-			rc = err;
-			goto out;
-		}
-		list_add(&watch->list, &u->watches);
-	} else {
-		list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
-			if (!strcmp(watch->token, token) &&
-			    !strcmp(watch->watch.node, path)) {
-				unregister_xenbus_watch(&watch->watch);
-				list_del(&watch->list);
-				free_watch_adapter(watch);
-				break;
-			}
-		}
-	}
-
-	/* Success.  Synthesize a reply to say all is OK. */
-	{
-		struct {
-			struct xsd_sockmsg hdr;
-			char body[3];
-		} __packed reply = {
-			{
-				.type = msg_type,
-				.len = sizeof(reply.body)
-			},
-			"OK"
-		};
-
-		mutex_lock(&u->reply_mutex);
-		rc = queue_reply(&u->read_buffers, &reply, sizeof(reply));
-		wake_up(&u->read_waitq);
-		mutex_unlock(&u->reply_mutex);
-	}
-
-out:
-	return rc;
-}
-
-static ssize_t xenbus_file_write(struct file *filp,
-				const char __user *ubuf,
-				size_t len, loff_t *ppos)
-{
-	struct xenbus_file_priv *u = filp->private_data;
-	uint32_t msg_type;
-	int rc = len;
-	int ret;
-	LIST_HEAD(staging_q);
-
-	/*
-	 * We're expecting usermode to be writing properly formed
-	 * xenbus messages.  If they write an incomplete message we
-	 * buffer it up.  Once it is complete, we act on it.
-	 */
-
-	/*
-	 * Make sure concurrent writers can't stomp all over each
-	 * other's messages and make a mess of our partial message
-	 * buffer.  We don't make any attemppt to stop multiple
-	 * writers from making a mess of each other's incomplete
-	 * messages; we're just trying to guarantee our own internal
-	 * consistency and make sure that single writes are handled
-	 * atomically.
-	 */
-	mutex_lock(&u->msgbuffer_mutex);
-
-	/* Get this out of the way early to avoid confusion */
-	if (len == 0)
-		goto out;
-
-	/* Can't write a xenbus message larger we can buffer */
-	if ((len + u->len) > sizeof(u->u.buffer)) {
-		/* On error, dump existing buffer */
-		u->len = 0;
-		rc = -EINVAL;
-		goto out;
-	}
-
-	ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
-
-	if (ret != 0) {
-		rc = -EFAULT;
-		goto out;
-	}
-
-	/* Deal with a partial copy. */
-	len -= ret;
-	rc = len;
-
-	u->len += len;
-
-	/* Return if we haven't got a full message yet */
-	if (u->len < sizeof(u->u.msg))
-		goto out;	/* not even the header yet */
-
-	/* If we're expecting a message that's larger than we can
-	   possibly send, dump what we have and return an error. */
-	if ((sizeof(u->u.msg) + u->u.msg.len) > sizeof(u->u.buffer)) {
-		rc = -E2BIG;
-		u->len = 0;
-		goto out;
-	}
-
-	if (u->len < (sizeof(u->u.msg) + u->u.msg.len))
-		goto out;	/* incomplete data portion */
-
-	/*
-	 * OK, now we have a complete message.  Do something with it.
-	 */
-
-	msg_type = u->u.msg.type;
-
-	switch (msg_type) {
-	case XS_WATCH:
-	case XS_UNWATCH:
-		/* (Un)Ask for some path to be watched for changes */
-		ret = xenbus_write_watch(msg_type, u);
-		break;
-
-	default:
-		/* Send out a transaction */
-		ret = xenbus_write_transaction(msg_type, u);
-		break;
-	}
-	if (ret != 0)
-		rc = ret;
-
-	/* Buffered message consumed */
-	u->len = 0;
-
- out:
-	mutex_unlock(&u->msgbuffer_mutex);
-	return rc;
-}
-
-static int xenbus_file_open(struct inode *inode, struct file *filp)
-{
-	struct xenbus_file_priv *u;
-
-	if (xen_store_evtchn == 0)
-		return -ENOENT;
-
-	nonseekable_open(inode, filp);
-
-	u = kzalloc(sizeof(*u), GFP_KERNEL);
-	if (u == NULL)
-		return -ENOMEM;
-
-	INIT_LIST_HEAD(&u->transactions);
-	INIT_LIST_HEAD(&u->watches);
-	INIT_LIST_HEAD(&u->read_buffers);
-	init_waitqueue_head(&u->read_waitq);
-
-	mutex_init(&u->reply_mutex);
-	mutex_init(&u->msgbuffer_mutex);
-
-	filp->private_data = u;
-
-	return 0;
-}
-
-static int xenbus_file_release(struct inode *inode, struct file *filp)
-{
-	struct xenbus_file_priv *u = filp->private_data;
-	struct xenbus_transaction_holder *trans, *tmp;
-	struct watch_adapter *watch, *tmp_watch;
-	struct read_buffer *rb, *tmp_rb;
-
-	/*
-	 * No need for locking here because there are no other users,
-	 * by definition.
-	 */
-
-	list_for_each_entry_safe(trans, tmp, &u->transactions, list) {
-		xenbus_transaction_end(trans->handle, 1);
-		list_del(&trans->list);
-		kfree(trans);
-	}
-
-	list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
-		unregister_xenbus_watch(&watch->watch);
-		list_del(&watch->list);
-		free_watch_adapter(watch);
-	}
-
-	list_for_each_entry_safe(rb, tmp_rb, &u->read_buffers, list) {
-		list_del(&rb->list);
-		kfree(rb);
-	}
-	kfree(u);
-
-	return 0;
-}
-
-static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
-{
-	struct xenbus_file_priv *u = file->private_data;
-
-	poll_wait(file, &u->read_waitq, wait);
-	if (!list_empty(&u->read_buffers))
-		return POLLIN | POLLRDNORM;
-	return 0;
-}
-
-const struct file_operations xenbus_file_ops = {
-	.read = xenbus_file_read,
-	.write = xenbus_file_write,
-	.open = xenbus_file_open,
-	.release = xenbus_file_release,
-	.poll = xenbus_file_poll,
-	.llseek = no_llseek,
-};
diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
index 5056306..6b80c77 100644
--- a/drivers/xen/xenfs/xenfs.h
+++ b/drivers/xen/xenfs/xenfs.h
@@ -1,7 +1,6 @@
 #ifndef _XENFS_XENBUS_H
 #define _XENFS_XENBUS_H
 
-extern const struct file_operations xenbus_file_ops;
 extern const struct file_operations xsd_kva_file_ops;
 extern const struct file_operations xsd_port_file_ops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:13:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmyV-0004nS-FP; Sun, 27 Nov 2011 22:13:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RUmyU-0004n0-DN
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:13:26 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322431969!3243362!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28214 invoked from network); 27 Nov 2011 22:12:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2011 22:12:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pARMChNn017520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 27 Nov 2011 22:12:44 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pARMCgSo020345
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 27 Nov 2011 22:12:43 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pARMCbWd025809; Sun, 27 Nov 2011 16:12:37 -0600
MIME-Version: 1.0
Message-ID: <ef2b1f70-35f3-470d-bbf8-9c0419893708@default>
Date: Sun, 27 Nov 2011 14:12:26 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
References: <20171.55835.240381.351382@mariner.uk.xensource.com>
	<2b60cfe7-2c97-45ef-bf89-88cd01cff1d3@default
	20174.36841.738985.984736@mariner.uk.xensource.com
	a930b4cd-e6df-44de-9907-1f9149bd4ccc@default>
In-Reply-To: <a930b4cd-e6df-44de-9907-1f9149bd4ccc@default>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0  (410211) [OL
	12.0.6607.1000]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A020201.4ED2B5DD.0017,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Konrad Wilk <konrad.wilk@oracle.com>,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > > P.S. Please note that I am still not receiving email
> > > >from the xen-devel reflector (and am on vacation this
> > > week so probably won't be looking into it... my best
> > > guess is that the Oracle spam filter isn't happy with
> > > the new source of the xen-devel messages, as some
> > > other Oracle folk are having problems too).
> >
> > Hrmm.  If this is still a problem when you get back please let me know.
> 
> Still a problem.  Konrad filed an internal bug report
> (Oracle has an Exchange-like mail server that is eat-
> your-own-dog-food) but the US holiday weekend, which
> many turn into a whole week, means it's probably not
> even getting looked at yet by Oracle's IT group.
> 
> It may be unrelated to the xen.org server change but
> the coincidence is suspicious.
> 
> Interestingly, I got precisely one xen-devel email in
> the last week which is what led me to the spam filter
> theory... though I have gotten every xen-changelog email.

AFAICT, the problem is now resolved, as of sometime
early Sunday AM GMT.  I haven't heard from Konrad
or other Oracle xen-devel subscribers but will assume
theirs is fixed as well.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Nov 27 22:13:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 27 Nov 2011 22:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUmyV-0004nS-FP; Sun, 27 Nov 2011 22:13:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RUmyU-0004n0-DN
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 22:13:26 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1322431969!3243362!1
X-Originating-IP: [141.146.126.227]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28214 invoked from network); 27 Nov 2011 22:12:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Nov 2011 22:12:50 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pARMChNn017520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 27 Nov 2011 22:12:44 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pARMCgSo020345
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 27 Nov 2011 22:12:43 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pARMCbWd025809; Sun, 27 Nov 2011 16:12:37 -0600
MIME-Version: 1.0
Message-ID: <ef2b1f70-35f3-470d-bbf8-9c0419893708@default>
Date: Sun, 27 Nov 2011 14:12:26 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
References: <20171.55835.240381.351382@mariner.uk.xensource.com>
	<2b60cfe7-2c97-45ef-bf89-88cd01cff1d3@default
	20174.36841.738985.984736@mariner.uk.xensource.com
	a930b4cd-e6df-44de-9907-1f9149bd4ccc@default>
In-Reply-To: <a930b4cd-e6df-44de-9907-1f9149bd4ccc@default>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0  (410211) [OL
	12.0.6607.1000]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A020201.4ED2B5DD.0017,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Konrad Wilk <konrad.wilk@oracle.com>,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > > P.S. Please note that I am still not receiving email
> > > >from the xen-devel reflector (and am on vacation this
> > > week so probably won't be looking into it... my best
> > > guess is that the Oracle spam filter isn't happy with
> > > the new source of the xen-devel messages, as some
> > > other Oracle folk are having problems too).
> >
> > Hrmm.  If this is still a problem when you get back please let me know.
> 
> Still a problem.  Konrad filed an internal bug report
> (Oracle has an Exchange-like mail server that is eat-
> your-own-dog-food) but the US holiday weekend, which
> many turn into a whole week, means it's probably not
> even getting looked at yet by Oracle's IT group.
> 
> It may be unrelated to the xen.org server change but
> the coincidence is suspicious.
> 
> Interestingly, I got precisely one xen-devel email in
> the last week which is what led me to the spam filter
> theory... though I have gotten every xen-changelog email.

AFAICT, the problem is now resolved, as of sometime
early Sunday AM GMT.  I haven't heard from Konrad
or other Oracle xen-devel subscribers but will assume
theirs is fixed as well.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 00:50:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 00:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUpPd-0006i2-K6; Mon, 28 Nov 2011 00:49:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUpPb-0006hx-HH
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 00:49:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322441340!6579187!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2396 invoked from network); 28 Nov 2011 00:49:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 00:49:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,580,1315180800"; 
   d="scan'208";a="9147154"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 00:48:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 00:48:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUpP1-0008Ap-Ku;
	Mon, 28 Nov 2011 00:48:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUpP1-0000UA-KL;
	Mon, 28 Nov 2011 00:48:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10135-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 00:48:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10135 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10135/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 00:50:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 00:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUpPd-0006i2-K6; Mon, 28 Nov 2011 00:49:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUpPb-0006hx-HH
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 00:49:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322441340!6579187!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2396 invoked from network); 28 Nov 2011 00:49:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 00:49:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,580,1315180800"; 
   d="scan'208";a="9147154"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 00:48:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 00:48:59 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUpP1-0008Ap-Ku;
	Mon, 28 Nov 2011 00:48:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUpP1-0000UA-KL;
	Mon, 28 Nov 2011 00:48:59 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10135-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 00:48:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10135 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10135/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 04:42:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 04:42:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUt2h-0005Nz-L8; Mon, 28 Nov 2011 04:42:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUt2h-0005Nu-02
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 04:42:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322455295!5795361!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2315 invoked from network); 28 Nov 2011 04:41:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 04:41:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,581,1315180800"; 
   d="scan'208";a="9148037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 04:41:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 04:41:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUt25-00012R-Sl;
	Mon, 28 Nov 2011 04:41:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUt25-00034t-SN;
	Mon, 28 Nov 2011 04:41:33 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10138-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 04:41:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10138: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10138 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10138/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 04:42:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 04:42:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUt2h-0005Nz-L8; Mon, 28 Nov 2011 04:42:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUt2h-0005Nu-02
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 04:42:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322455295!5795361!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2315 invoked from network); 28 Nov 2011 04:41:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 04:41:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,581,1315180800"; 
   d="scan'208";a="9148037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 04:41:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 04:41:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUt25-00012R-Sl;
	Mon, 28 Nov 2011 04:41:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUt25-00034t-SN;
	Mon, 28 Nov 2011 04:41:33 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10138-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 04:41:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10138: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10138 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10138/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 07:46:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 07:46:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUvuV-0006vf-36; Mon, 28 Nov 2011 07:45:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RUvuT-0006va-P5
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 07:45:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322466317!3323671!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2497 invoked from network); 28 Nov 2011 07:45:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 07:45:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 28 Nov 2011 07:45:16 +0000
Message-Id: <4ED34A1A020000780006394A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 28 Nov 2011 07:45:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4ECFB05B.2060501@citrix.com>
	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>
	<4ECFBC35.7080202@citrix.com>
	<4ECFD531020000780006366D@nat28.tlf.novell.com>
	<4ECFCA61.1090401@citrix.com> <4ECFD528.2090102@citrix.com>
In-Reply-To: <4ECFD528.2090102@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
 the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.11.11 at 18:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> After comparing the Xen parsing code with the Linux parsing code, with
> the correct idea of what we are trying to do, Xen still lacks the
> ability to specify an exact offset using the newer style.  I will
> implement this.

What am I overlooking? set_kexec_crash_area_size() takes the new
syntax into consideration, and kexec_reserve_area() gets called only
afterwards.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 07:46:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 07:46:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUvuV-0006vf-36; Mon, 28 Nov 2011 07:45:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RUvuT-0006va-P5
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 07:45:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322466317!3323671!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2497 invoked from network); 28 Nov 2011 07:45:18 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 07:45:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 28 Nov 2011 07:45:16 +0000
Message-Id: <4ED34A1A020000780006394A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 28 Nov 2011 07:45:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4ECFB05B.2060501@citrix.com>
	<4ECFC3F902000078000635FF@nat28.tlf.novell.com>
	<4ECFBC35.7080202@citrix.com>
	<4ECFD531020000780006366D@nat28.tlf.novell.com>
	<4ECFCA61.1090401@citrix.com> <4ECFD528.2090102@citrix.com>
In-Reply-To: <4ECFD528.2090102@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: Clean up logic to choose a range for
 the crash kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.11.11 at 18:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> After comparing the Xen parsing code with the Linux parsing code, with
> the correct idea of what we are trying to do, Xen still lacks the
> ability to specify an exact offset using the newer style.  I will
> implement this.

What am I overlooking? set_kexec_crash_area_size() takes the new
syntax into consideration, and kexec_reserve_area() gets called only
afterwards.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 07:48:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 07:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUvwe-0006zs-M5; Mon, 28 Nov 2011 07:48:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RUvwd-0006zl-PI
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 07:48:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322466333!46065655!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11306 invoked from network); 28 Nov 2011 07:45:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 07:45:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 28 Nov 2011 07:47:33 +0000
Message-Id: <4ED34AA2020000780006394D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 28 Nov 2011 07:47:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> This patch disable PCID/INVPCID for dom0.
>> 
>> Do we really need to disable it, rather than making it work?
>> Conceptually the feature seems usable, and the instruction would
>> need replacement by a hypercall anyway (just like invlpg).
> 
> It's a design choice.
> Exposing PCID/INVPCID to pv would involve some additional task, like 
> coordinated PCID allocation algorithm, or change vmm vcpu context swich, 
> which would make it complex. However, exposing PCID/INVPCID to pv has not 
> obvious benefit or even result in performance regression.

Would you mind elaborating on that statement?

Jan

> So we choose to disable PCID/INVPCID to pv.
> 
> Thanks,
> Jinsong



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 07:48:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 07:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUvwe-0006zs-M5; Mon, 28 Nov 2011 07:48:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RUvwd-0006zl-PI
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 07:48:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322466333!46065655!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11306 invoked from network); 28 Nov 2011 07:45:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 07:45:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 28 Nov 2011 07:47:33 +0000
Message-Id: <4ED34AA2020000780006394D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 28 Nov 2011 07:47:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
In-Reply-To: <BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Jan Beulich wrote:
>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> This patch disable PCID/INVPCID for dom0.
>> 
>> Do we really need to disable it, rather than making it work?
>> Conceptually the feature seems usable, and the instruction would
>> need replacement by a hypercall anyway (just like invlpg).
> 
> It's a design choice.
> Exposing PCID/INVPCID to pv would involve some additional task, like 
> coordinated PCID allocation algorithm, or change vmm vcpu context swich, 
> which would make it complex. However, exposing PCID/INVPCID to pv has not 
> obvious benefit or even result in performance regression.

Would you mind elaborating on that statement?

Jan

> So we choose to disable PCID/INVPCID to pv.
> 
> Thanks,
> Jinsong



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 08:45:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 08:45:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUwpu-0008CQ-8Z; Mon, 28 Nov 2011 08:45:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUwpr-0008CL-UR
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 08:45:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322469876!4476209!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29332 invoked from network); 28 Nov 2011 08:44:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 08:44:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9152817"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 08:44:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 08:44:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUwpG-0002XL-UY;
	Mon, 28 Nov 2011 08:44:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUwpG-0006ng-Tz;
	Mon, 28 Nov 2011 08:44:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10145-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 08:44:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10145: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10145 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10145/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 08:45:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 08:45:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUwpu-0008CQ-8Z; Mon, 28 Nov 2011 08:45:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUwpr-0008CL-UR
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 08:45:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322469876!4476209!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29332 invoked from network); 28 Nov 2011 08:44:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 08:44:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9152817"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 08:44:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 08:44:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RUwpG-0002XL-UY;
	Mon, 28 Nov 2011 08:44:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RUwpG-0006ng-Tz;
	Mon, 28 Nov 2011 08:44:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10145-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 08:44:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10145: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10145 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10145/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:05:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:05:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUx8k-0000Lj-Ta; Mon, 28 Nov 2011 09:04:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RUx8j-0000La-HW
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 09:04:41 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322471044!4938751!1
X-Originating-IP: [216.32.181.184]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32285 invoked from network); 28 Nov 2011 09:04:05 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-3.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	28 Nov 2011 09:04:05 -0000
Received: from mail157-ch1-R.bigfish.com (10.43.68.252) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.22; Mon, 28 Nov 2011 09:03:18 +0000
Received: from mail157-ch1 (localhost [127.0.0.1])	by
	mail157-ch1-R.bigfish.com (Postfix) with ESMTP id 9DBC62001D3;
	Mon, 28 Nov 2011 09:05:44 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dK1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail157-ch1 (localhost.localdomain [127.0.0.1]) by mail157-ch1
	(MessageSwitch) id 1322471144560113_9996;
	Mon, 28 Nov 2011 09:05:44 +0000 (UTC)
Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.243])	by mail157-ch1.bigfish.com (Postfix) with ESMTP id
	8328F100048;	Mon, 28 Nov 2011 09:05:44 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server id
	14.1.225.22; Mon, 28 Nov 2011 09:03:16 +0000
X-WSS-ID: 0LVD56O-01-0C2-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DD1E1028103;	Mon, 28 Nov 2011 03:04:00 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 28 Nov 2011 03:04:04 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 28 Nov 2011 03:04:01 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 28 Nov 2011
	04:03:59 -0500
Message-ID: <4ED34E7E.2050205@amd.com>
Date: Mon, 28 Nov 2011 10:03:58 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Bastian Blank <waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0/5] Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/27/11 23:07, Bastian Blank wrote:
> Over a year ago I started a discussion about xenfs. This is the first
> try to add the stuff in xenfs as regular devices and a sysfs file.

Is this intended to go into the xen kernel?

Christoph


> Patches for xen tools will follow.
>
> Bastian


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:05:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:05:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUx8k-0000Lj-Ta; Mon, 28 Nov 2011 09:04:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RUx8j-0000La-HW
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 09:04:41 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322471044!4938751!1
X-Originating-IP: [216.32.181.184]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32285 invoked from network); 28 Nov 2011 09:04:05 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-3.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	28 Nov 2011 09:04:05 -0000
Received: from mail157-ch1-R.bigfish.com (10.43.68.252) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.22; Mon, 28 Nov 2011 09:03:18 +0000
Received: from mail157-ch1 (localhost [127.0.0.1])	by
	mail157-ch1-R.bigfish.com (Postfix) with ESMTP id 9DBC62001D3;
	Mon, 28 Nov 2011 09:05:44 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dK1432N98dKzz1202hzzz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 13,
Received: from mail157-ch1 (localhost.localdomain [127.0.0.1]) by mail157-ch1
	(MessageSwitch) id 1322471144560113_9996;
	Mon, 28 Nov 2011 09:05:44 +0000 (UTC)
Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.243])	by mail157-ch1.bigfish.com (Postfix) with ESMTP id
	8328F100048;	Mon, 28 Nov 2011 09:05:44 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server id
	14.1.225.22; Mon, 28 Nov 2011 09:03:16 +0000
X-WSS-ID: 0LVD56O-01-0C2-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2DD1E1028103;	Mon, 28 Nov 2011 03:04:00 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 28 Nov 2011 03:04:04 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 28 Nov 2011 03:04:01 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 28 Nov 2011
	04:03:59 -0500
Message-ID: <4ED34E7E.2050205@amd.com>
Date: Mon, 28 Nov 2011 10:03:58 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Bastian Blank <waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
In-Reply-To: <1322431628-21760-1-git-send-email-waldi@debian.org>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0/5] Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/27/11 23:07, Bastian Blank wrote:
> Over a year ago I started a discussion about xenfs. This is the first
> try to add the stuff in xenfs as regular devices and a sysfs file.

Is this intended to go into the xen kernel?

Christoph


> Patches for xen tools will follow.
>
> Bastian


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:32:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUxZ4-0001LW-Pf; Mon, 28 Nov 2011 09:31:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RUxZ3-0001LK-Lx
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 09:31:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322472677!6074200!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27089 invoked from network); 28 Nov 2011 09:31:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 09:31:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9154797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 09:31:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 09:31:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
In-Reply-To: <4ED34E7E.2050205@amd.com>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<4ED34E7E.2050205@amd.com>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 09:31:11 +0000
Message-ID: <1322472671.11846.9.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Bastian Blank <waldi@debian.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/5] Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 09:03 +0000, Christoph Egger wrote:
> On 11/27/11 23:07, Bastian Blank wrote:
> > Over a year ago I started a discussion about xenfs. This is the first
> > try to add the stuff in xenfs as regular devices and a sysfs file.
> 
> Is this intended to go into the xen kernel?

No, these are Linux kernel patches.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:32:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:32:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUxZ4-0001LW-Pf; Mon, 28 Nov 2011 09:31:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RUxZ3-0001LK-Lx
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 09:31:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322472677!6074200!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27089 invoked from network); 28 Nov 2011 09:31:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 09:31:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9154797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 09:31:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 09:31:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
In-Reply-To: <4ED34E7E.2050205@amd.com>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<4ED34E7E.2050205@amd.com>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 09:31:11 +0000
Message-ID: <1322472671.11846.9.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Bastian Blank <waldi@debian.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/5] Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 09:03 +0000, Christoph Egger wrote:
> On 11/27/11 23:07, Bastian Blank wrote:
> > Over a year ago I started a discussion about xenfs. This is the first
> > try to add the stuff in xenfs as regular devices and a sysfs file.
> 
> Is this intended to go into the xen kernel?

No, these are Linux kernel patches.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:37:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:37:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUxdq-0001Tj-Hv; Mon, 28 Nov 2011 09:36:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RUxdo-0001TX-Rd
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 09:36:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322472973!4059951!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4191 invoked from network); 28 Nov 2011 09:36:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 09:36:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 28 Nov 2011 09:36:12 +0000
Message-Id: <4ED3641A0200007800063991@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 28 Nov 2011 09:36:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com>
	<20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org>
	<20110901141754.76cef93b.akpm@linux-foundation.org>
	<4E60C067.4010600@citrix.com>
	<20110902153204.59a928c1.akpm@linux-foundation.org>
	<20110906163553.GA28971@dumpdata.com>
	<20111105133846.GA4415@phenom.dumpdata.com>
	<20111107203613.GA6546@phenom.dumpdata.com>
In-Reply-To: <20111107203613.GA6546@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] mm: sync vmalloc address space page tables
 in alloc_vm_area()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.11.11 at 21:36, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> Patch included as attachment for easier review..

I just noticed that this patch made it upstream meanwhile, and that I
should have paid more attention earlier: Once again this adds x86
specific bits to (supposedly) architecture independent Xen code
(lookup_address(), use of GNTMAP_contains_pte). Unless everyone
agrees that x86 is going to remain the only architecture Xen will support
going forward (no ia64, no ARM, nothing else), patches doing so (at
least outside proper #ifdef-s or alike) should really be rejected.

Besides that, the patch also appears to close the road to running
backends in HVM - use of GNTMAP_contains_pte isn't permitted for
paging_mode_external() guests, so it's even a step backwards for
x86.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:37:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:37:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUxdq-0001Tj-Hv; Mon, 28 Nov 2011 09:36:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RUxdo-0001TX-Rd
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 09:36:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322472973!4059951!1
X-Originating-IP: [130.57.49.28]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4191 invoked from network); 28 Nov 2011 09:36:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 09:36:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 28 Nov 2011 09:36:12 +0000
Message-Id: <4ED3641A0200007800063991@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 28 Nov 2011 09:36:10 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com>
	<20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org>
	<20110901141754.76cef93b.akpm@linux-foundation.org>
	<4E60C067.4010600@citrix.com>
	<20110902153204.59a928c1.akpm@linux-foundation.org>
	<20110906163553.GA28971@dumpdata.com>
	<20111105133846.GA4415@phenom.dumpdata.com>
	<20111107203613.GA6546@phenom.dumpdata.com>
In-Reply-To: <20111107203613.GA6546@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] mm: sync vmalloc address space page tables
 in alloc_vm_area()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.11.11 at 21:36, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> Patch included as attachment for easier review..

I just noticed that this patch made it upstream meanwhile, and that I
should have paid more attention earlier: Once again this adds x86
specific bits to (supposedly) architecture independent Xen code
(lookup_address(), use of GNTMAP_contains_pte). Unless everyone
agrees that x86 is going to remain the only architecture Xen will support
going forward (no ia64, no ARM, nothing else), patches doing so (at
least outside proper #ifdef-s or alike) should really be rejected.

Besides that, the patch also appears to close the road to running
backends in HVM - use of GNTMAP_contains_pte isn't permitted for
paging_mode_external() guests, so it's even a step backwards for
x86.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:40:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUxhL-0001mK-WA; Mon, 28 Nov 2011 09:40:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RUxhK-0001lK-OG
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 09:40:26 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322473170!49987022!1
X-Originating-IP: [216.32.180.16]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26406 invoked from network); 28 Nov 2011 09:39:31 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE009.bigfish.com) (216.32.180.16)
	by server-13.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	28 Nov 2011 09:39:31 -0000
Received: from mail104-va3-R.bigfish.com (10.7.14.236) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.22; Mon, 28 Nov 2011 09:39:03 +0000
Received: from mail104-va3 (localhost [127.0.0.1])	by
	mail104-va3-R.bigfish.com (Postfix) with ESMTP id 7D6F33400F6;
	Mon, 28 Nov 2011 09:37:23 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dK936eK1432N98dKzz1202hzzz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail104-va3 (localhost.localdomain [127.0.0.1]) by mail104-va3
	(MessageSwitch) id 1322473043239693_14502;
	Mon, 28 Nov 2011 09:37:23 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.240])	by
	mail104-va3.bigfish.com (Postfix) with ESMTP id 347A94C0046;
	Mon, 28 Nov 2011 09:37:23 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.22; Mon, 28 Nov 2011 09:39:01 +0000
X-WSS-ID: 0LVD6U9-01-2CW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D1C41028100;	Mon, 28 Nov 2011 03:39:44 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 28 Nov 2011 03:39:49 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 28 Nov 2011 03:39:45 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 28 Nov 2011
	04:39:44 -0500
Message-ID: <4ED356DF.7060108@amd.com>
Date: Mon, 28 Nov 2011 10:39:43 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<4ED34E7E.2050205@amd.com>
	<1322472671.11846.9.camel@dagon.hellion.org.uk>
In-Reply-To: <1322472671.11846.9.camel@dagon.hellion.org.uk>
X-OriginatorOrg: amd.com
Cc: Bastian Blank <waldi@debian.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/5] Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/28/11 10:31, Ian Campbell wrote:
> On Mon, 2011-11-28 at 09:03 +0000, Christoph Egger wrote:
>> On 11/27/11 23:07, Bastian Blank wrote:
>>> Over a year ago I started a discussion about xenfs. This is the first
>>> try to add the stuff in xenfs as regular devices and a sysfs file.
>>
>> Is this intended to go into the xen kernel?
>
> No, these are Linux kernel patches.

Shouldn't they go to lkml instead?

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:40:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:40:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUxhL-0001mK-WA; Mon, 28 Nov 2011 09:40:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RUxhK-0001lK-OG
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 09:40:26 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322473170!49987022!1
X-Originating-IP: [216.32.180.16]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26406 invoked from network); 28 Nov 2011 09:39:31 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE009.bigfish.com) (216.32.180.16)
	by server-13.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	28 Nov 2011 09:39:31 -0000
Received: from mail104-va3-R.bigfish.com (10.7.14.236) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.22; Mon, 28 Nov 2011 09:39:03 +0000
Received: from mail104-va3 (localhost [127.0.0.1])	by
	mail104-va3-R.bigfish.com (Postfix) with ESMTP id 7D6F33400F6;
	Mon, 28 Nov 2011 09:37:23 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dK936eK1432N98dKzz1202hzzz2dh668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail104-va3 (localhost.localdomain [127.0.0.1]) by mail104-va3
	(MessageSwitch) id 1322473043239693_14502;
	Mon, 28 Nov 2011 09:37:23 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.240])	by
	mail104-va3.bigfish.com (Postfix) with ESMTP id 347A94C0046;
	Mon, 28 Nov 2011 09:37:23 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.22; Mon, 28 Nov 2011 09:39:01 +0000
X-WSS-ID: 0LVD6U9-01-2CW-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2D1C41028100;	Mon, 28 Nov 2011 03:39:44 -0600 (CST)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 28 Nov 2011 03:39:49 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag01.amd.com
	(163.181.55.1) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 28 Nov 2011 03:39:45 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 28 Nov 2011
	04:39:44 -0500
Message-ID: <4ED356DF.7060108@amd.com>
Date: Mon, 28 Nov 2011 10:39:43 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<4ED34E7E.2050205@amd.com>
	<1322472671.11846.9.camel@dagon.hellion.org.uk>
In-Reply-To: <1322472671.11846.9.camel@dagon.hellion.org.uk>
X-OriginatorOrg: amd.com
Cc: Bastian Blank <waldi@debian.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/5] Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/28/11 10:31, Ian Campbell wrote:
> On Mon, 2011-11-28 at 09:03 +0000, Christoph Egger wrote:
>> On 11/27/11 23:07, Bastian Blank wrote:
>>> Over a year ago I started a discussion about xenfs. This is the first
>>> try to add the stuff in xenfs as regular devices and a sysfs file.
>>
>> Is this intended to go into the xen kernel?
>
> No, these are Linux kernel patches.

Shouldn't they go to lkml instead?

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:46:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUxn7-00029J-Vi; Mon, 28 Nov 2011 09:46:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anitawang1989@gmail.com>) id 1RUBq8-0001Um-So
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 06:34:21 +0000
X-Env-Sender: anitawang1989@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322289226!6420704!1
X-Originating-IP: [216.139.236.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14745 invoked from network); 26 Nov 2011 06:33:47 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Nov 2011 06:33:47 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <anitawang1989@gmail.com>) id 1RUBpZ-0008IV-S5
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 22:33:45 -0800
Date: Fri, 25 Nov 2011 22:33:45 -0800 (PST)
From: anita <anitawang1989@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322289225863-5024421.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 28 Nov 2011 09:46:25 +0000
Subject: [Xen-devel] 2 questions about hypercall
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGksIEkndmUgYmVlbiByZWFkaW5nIHRoZSB4ZW4gc291cmNlIGNvZGUgcmVjZW50bHksIGFuZCBJ
IGhhdmUgZ290IDIKcXVlc3Rpb25zIGFib3V0IGh5cGVyY2FsbC4KCjEuIEkgZmluZCAyIGhlYWRl
ciBmaWxlcyBuYW1lZCBoeXBlcmNhbGwuaCBpbiB0aGUgZGlyZWN0b3J5IApsaW51eC9hcmNoL3g4
Ni9pbmNsdWRlLiBPbmUgaXMgaW4gdGhlIHN1Yi1kaXJlY3RvcnkKL21hY2gteGVuL2FzbS9oeXBl
cmNhbGwuaCwgYW5kIHRoZSBvdGhlciBpcyAvYXNtL3hlbi9oeXBlcmNhbGwuaC4gIEFmdGVyCmNv
bXBhcmluZyB0aGVzZSB0d28sIEkgZmluZCB0aGVpciBjb250ZW50cyBhcmUgc2ltaWxhciBidXQg
ZGlmZmVyZW50LCBhbmQgSQpjYW4ndCBmaWd1cmUgb3V0IHdoYXQncyB0aGUgZGlmZmVyZW5jZSBi
ZXR3ZWVuIHRoZW0sIHdoYXQgdGhlaXIgcHVycG9zZXMgYXJlCiwgYW5kIHdoZW4ga2VybmVsIHdh
bnQgdG8gdHJhcCBpbnRvIHhlbiBoeXBlcnZpc29yLCB3aGljaCBvbmUgd2lsbCBrZXJuZWwKY2hv
b3Nl77yfCgoyLiBJIGZpbmQgdGhhdCB0aGUgeGVuIHRvb2xzIGFsc28gdXNlZCBoeXBlcmNhbGwu
IE15IHF1ZXN0aW9uIGlzIGhvdyBkb2VzCnRvb2xzIHVzZWQgaXQgPyBpcyB0aGUgcHJvY2VzcyB0
aGUgc2FtZSBhcyB0aGUga2VybmVsLCBvciB4ZW4gdG9vbHMgdXNlCmh5cGVyY2FsbCBpbiBhIGRp
ZmZlcmVudCB3YXk/CgotLQpWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVu
LjEwNDU3MTIubjUubmFiYmxlLmNvbS8yLXF1ZXN0aW9ucy1hYm91dC1oeXBlcmNhbGwtdHA1MDI0
NDIxcDUwMjQ0MjEuaHRtbApTZW50IGZyb20gdGhlIFhlbiAtIERldiBtYWlsaW5nIGxpc3QgYXJj
aGl2ZSBhdCBOYWJibGUuY29tLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291
cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:46:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUxn7-00029J-Vi; Mon, 28 Nov 2011 09:46:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anitawang1989@gmail.com>) id 1RUBq8-0001Um-So
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 06:34:21 +0000
X-Env-Sender: anitawang1989@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322289226!6420704!1
X-Originating-IP: [216.139.236.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14745 invoked from network); 26 Nov 2011 06:33:47 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-2.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Nov 2011 06:33:47 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <anitawang1989@gmail.com>) id 1RUBpZ-0008IV-S5
	for xen-devel@lists.xensource.com; Fri, 25 Nov 2011 22:33:45 -0800
Date: Fri, 25 Nov 2011 22:33:45 -0800 (PST)
From: anita <anitawang1989@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322289225863-5024421.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 28 Nov 2011 09:46:25 +0000
Subject: [Xen-devel] 2 questions about hypercall
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGksIEkndmUgYmVlbiByZWFkaW5nIHRoZSB4ZW4gc291cmNlIGNvZGUgcmVjZW50bHksIGFuZCBJ
IGhhdmUgZ290IDIKcXVlc3Rpb25zIGFib3V0IGh5cGVyY2FsbC4KCjEuIEkgZmluZCAyIGhlYWRl
ciBmaWxlcyBuYW1lZCBoeXBlcmNhbGwuaCBpbiB0aGUgZGlyZWN0b3J5IApsaW51eC9hcmNoL3g4
Ni9pbmNsdWRlLiBPbmUgaXMgaW4gdGhlIHN1Yi1kaXJlY3RvcnkKL21hY2gteGVuL2FzbS9oeXBl
cmNhbGwuaCwgYW5kIHRoZSBvdGhlciBpcyAvYXNtL3hlbi9oeXBlcmNhbGwuaC4gIEFmdGVyCmNv
bXBhcmluZyB0aGVzZSB0d28sIEkgZmluZCB0aGVpciBjb250ZW50cyBhcmUgc2ltaWxhciBidXQg
ZGlmZmVyZW50LCBhbmQgSQpjYW4ndCBmaWd1cmUgb3V0IHdoYXQncyB0aGUgZGlmZmVyZW5jZSBi
ZXR3ZWVuIHRoZW0sIHdoYXQgdGhlaXIgcHVycG9zZXMgYXJlCiwgYW5kIHdoZW4ga2VybmVsIHdh
bnQgdG8gdHJhcCBpbnRvIHhlbiBoeXBlcnZpc29yLCB3aGljaCBvbmUgd2lsbCBrZXJuZWwKY2hv
b3Nl77yfCgoyLiBJIGZpbmQgdGhhdCB0aGUgeGVuIHRvb2xzIGFsc28gdXNlZCBoeXBlcmNhbGwu
IE15IHF1ZXN0aW9uIGlzIGhvdyBkb2VzCnRvb2xzIHVzZWQgaXQgPyBpcyB0aGUgcHJvY2VzcyB0
aGUgc2FtZSBhcyB0aGUga2VybmVsLCBvciB4ZW4gdG9vbHMgdXNlCmh5cGVyY2FsbCBpbiBhIGRp
ZmZlcmVudCB3YXk/CgotLQpWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVu
LjEwNDU3MTIubjUubmFiYmxlLmNvbS8yLXF1ZXN0aW9ucy1hYm91dC1oeXBlcmNhbGwtdHA1MDI0
NDIxcDUwMjQ0MjEuaHRtbApTZW50IGZyb20gdGhlIFhlbiAtIERldiBtYWlsaW5nIGxpc3QgYXJj
aGl2ZSBhdCBOYWJibGUuY29tLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291
cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:46:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUxn8-00029Q-Ay; Mon, 28 Nov 2011 09:46:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RUTwT-0005Ex-1X
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 01:54:05 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322358780!45537051!1
X-Originating-IP: [216.139.236.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17245 invoked from network); 27 Nov 2011 01:53:01 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Nov 2011 01:53:01 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RUTvy-0005fx-97
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 17:53:34 -0800
Date: Sat, 26 Nov 2011 17:53:34 -0800 (PST)
From: sandr8 <sandr8@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322358814275-5025774.post@n5.nabble.com>
In-Reply-To: <20111031182220.GZ12984@reaktio.net>
References: <20111031182220.GZ12984@reaktio.net>
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 28 Nov 2011 09:46:25 +0000
Subject: Re: [Xen-devel] Xen 4.1.1 HVM guest cdrom trouble, lost interrupts,
 ata failed commands (frozen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

  I am seeing exactly the same behavior... did you manage to get around this
issue?

thank you!
-alessandro-

--
View this message in context: http://xen.1045712.n5.nabble.com/Xen-4-1-1-HVM-guest-cdrom-trouble-lost-interrupts-ata-failed-commands-frozen-tp4953147p5025774.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 09:46:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 09:46:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUxn8-00029Q-Ay; Mon, 28 Nov 2011 09:46:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RUTwT-0005Ex-1X
	for xen-devel@lists.xensource.com; Sun, 27 Nov 2011 01:54:05 +0000
X-Env-Sender: sandr8@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322358780!45537051!1
X-Originating-IP: [216.139.236.26]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17245 invoked from network); 27 Nov 2011 01:53:01 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Nov 2011 01:53:01 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <sandr8@gmail.com>) id 1RUTvy-0005fx-97
	for xen-devel@lists.xensource.com; Sat, 26 Nov 2011 17:53:34 -0800
Date: Sat, 26 Nov 2011 17:53:34 -0800 (PST)
From: sandr8 <sandr8@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1322358814275-5025774.post@n5.nabble.com>
In-Reply-To: <20111031182220.GZ12984@reaktio.net>
References: <20111031182220.GZ12984@reaktio.net>
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 28 Nov 2011 09:46:25 +0000
Subject: Re: [Xen-devel] Xen 4.1.1 HVM guest cdrom trouble, lost interrupts,
 ata failed commands (frozen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

  I am seeing exactly the same behavior... did you manage to get around this
issue?

thank you!
-alessandro-

--
View this message in context: http://xen.1045712.n5.nabble.com/Xen-4-1-1-HVM-guest-cdrom-trouble-lost-interrupts-ata-failed-commands-frozen-tp4953147p5025774.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 10:01:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 10:01:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUy16-0002bQ-W2; Mon, 28 Nov 2011 10:00:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RUy15-0002bL-5g
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 10:00:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322473877!5222747!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25958 invoked from network); 28 Nov 2011 09:51:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 09:51:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9155989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 09:51:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 09:51:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
In-Reply-To: <4ED356DF.7060108@amd.com>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<4ED34E7E.2050205@amd.com>
	<1322472671.11846.9.camel@dagon.hellion.org.uk>
	<4ED356DF.7060108@amd.com>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 09:51:13 +0000
Message-ID: <1322473873.11846.17.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Bastian Blank <waldi@debian.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/5] Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 09:39 +0000, Christoph Egger wrote:
> On 11/28/11 10:31, Ian Campbell wrote:
> > On Mon, 2011-11-28 at 09:03 +0000, Christoph Egger wrote:
> >> On 11/27/11 23:07, Bastian Blank wrote:
> >>> Over a year ago I started a discussion about xenfs. This is the first
> >>> try to add the stuff in xenfs as regular devices and a sysfs file.
> >>
> >> Is this intended to go into the xen kernel?
> >
> > No, these are Linux kernel patches.
> 
> Shouldn't they go to lkml instead?

Ideally they would go to both lists and whoever is listed in MAINTAINERS
for these files.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 10:01:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 10:01:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUy16-0002bQ-W2; Mon, 28 Nov 2011 10:00:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RUy15-0002bL-5g
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 10:00:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322473877!5222747!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25958 invoked from network); 28 Nov 2011 09:51:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 09:51:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9155989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 09:51:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 09:51:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
In-Reply-To: <4ED356DF.7060108@amd.com>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<4ED34E7E.2050205@amd.com>
	<1322472671.11846.9.camel@dagon.hellion.org.uk>
	<4ED356DF.7060108@amd.com>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 09:51:13 +0000
Message-ID: <1322473873.11846.17.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Bastian Blank <waldi@debian.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/5] Move stuff out of xenfs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 09:39 +0000, Christoph Egger wrote:
> On 11/28/11 10:31, Ian Campbell wrote:
> > On Mon, 2011-11-28 at 09:03 +0000, Christoph Egger wrote:
> >> On 11/27/11 23:07, Bastian Blank wrote:
> >>> Over a year ago I started a discussion about xenfs. This is the first
> >>> try to add the stuff in xenfs as regular devices and a sysfs file.
> >>
> >> Is this intended to go into the xen kernel?
> >
> > No, these are Linux kernel patches.
> 
> Shouldn't they go to lkml instead?

Ideally they would go to both lists and whoever is listed in MAINTAINERS
for these files.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 10:07:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 10:07:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUy7E-0002kL-UO; Mon, 28 Nov 2011 10:07:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RUy7C-0002k3-MU; Mon, 28 Nov 2011 10:07:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322474760!45682001!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8915 invoked from network); 28 Nov 2011 10:06:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 10:06:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9156521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 10:06:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 10:06:34 +0000
Date: Mon, 28 Nov 2011 10:07:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jeremy Fitzhardinge <jeremy@goop.org>
In-Reply-To: <4ED19896.6040201@goop.org>
Message-ID: <alpine.DEB.2.00.1111281006490.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111251201421.31179@kaball-desktop>
	<4ED19896.6040201@goop.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7
 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 27 Nov 2011, Jeremy Fitzhardinge wrote:
> On 11/25/2011 06:06 AM, Stefano Stabellini wrote:
> > Hi everybody,
> > a few weeks ago a small group of hackers started working from scratch on
> > a Cortex-A15 Xen port, exploiting all the latest hardware virtualization
> > extensions.
> >
> > The port can now boot dom0 all the way to a shell prompt,
> 
> Congratulations!

Thanks!

> >  so we are
> > planning to make an announcement to various Open Source communities
> > regarding ARMv7 with virt extensions support in Xen. The intention is to
> > get more parties interested and engaged in Xen on ARM in general, and
> > also to get feedback.  We propose to send the email below, to the
> > following mailings lists:
> >
> > virtualization@lists.linux-foundation.org
> > linux-kernel@vger.kernel.org
> > linux-arm-kernel@lists.infradead.org
> > android-virt@lists.cs.columbia.edu
> > linaro-dev@lists.linaro.org
> KVM <kvm@vger.kernel.org> (seriously!)

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 10:07:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 10:07:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUy7E-0002kL-UO; Mon, 28 Nov 2011 10:07:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RUy7C-0002k3-MU; Mon, 28 Nov 2011 10:07:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322474760!45682001!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8915 invoked from network); 28 Nov 2011 10:06:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 10:06:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9156521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 10:06:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 10:06:34 +0000
Date: Mon, 28 Nov 2011 10:07:12 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jeremy Fitzhardinge <jeremy@goop.org>
In-Reply-To: <4ED19896.6040201@goop.org>
Message-ID: <alpine.DEB.2.00.1111281006490.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111251201421.31179@kaball-desktop>
	<4ED19896.6040201@goop.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7
 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 27 Nov 2011, Jeremy Fitzhardinge wrote:
> On 11/25/2011 06:06 AM, Stefano Stabellini wrote:
> > Hi everybody,
> > a few weeks ago a small group of hackers started working from scratch on
> > a Cortex-A15 Xen port, exploiting all the latest hardware virtualization
> > extensions.
> >
> > The port can now boot dom0 all the way to a shell prompt,
> 
> Congratulations!

Thanks!

> >  so we are
> > planning to make an announcement to various Open Source communities
> > regarding ARMv7 with virt extensions support in Xen. The intention is to
> > get more parties interested and engaged in Xen on ARM in general, and
> > also to get feedback.  We propose to send the email below, to the
> > following mailings lists:
> >
> > virtualization@lists.linux-foundation.org
> > linux-kernel@vger.kernel.org
> > linux-arm-kernel@lists.infradead.org
> > android-virt@lists.cs.columbia.edu
> > linaro-dev@lists.linaro.org
> KVM <kvm@vger.kernel.org> (seriously!)

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 10:19:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 10:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUyIw-00030f-F8; Mon, 28 Nov 2011 10:19:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RUyIv-00030a-DA
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 10:19:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322475521!5871618!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15382 invoked from network); 28 Nov 2011 10:18:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 10:18:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9157083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 10:18:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 10:18:39 +0000
Date: Mon, 28 Nov 2011 10:19:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: sandr8 <sandr8@gmail.com>
In-Reply-To: <1322358814275-5025774.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1111281019200.31179@kaball-desktop>
References: <20111031182220.GZ12984@reaktio.net>
	<1322358814275-5025774.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.1.1 HVM guest cdrom trouble, lost interrupts,
 ata failed commands (frozen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 27 Nov 2011, sandr8 wrote:
> Hi,
> 
>   I am seeing exactly the same behavior... did you manage to get around this
> issue?

it is fixed in xen 4.1.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 10:19:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 10:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUyIw-00030f-F8; Mon, 28 Nov 2011 10:19:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RUyIv-00030a-DA
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 10:19:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322475521!5871618!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15382 invoked from network); 28 Nov 2011 10:18:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 10:18:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9157083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 10:18:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 10:18:39 +0000
Date: Mon, 28 Nov 2011 10:19:32 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: sandr8 <sandr8@gmail.com>
In-Reply-To: <1322358814275-5025774.post@n5.nabble.com>
Message-ID: <alpine.DEB.2.00.1111281019200.31179@kaball-desktop>
References: <20111031182220.GZ12984@reaktio.net>
	<1322358814275-5025774.post@n5.nabble.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.1.1 HVM guest cdrom trouble, lost interrupts,
 ata failed commands (frozen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 27 Nov 2011, sandr8 wrote:
> Hi,
> 
>   I am seeing exactly the same behavior... did you manage to get around this
> issue?

it is fixed in xen 4.1.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 10:20:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 10:20:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUyJb-00032N-TE; Mon, 28 Nov 2011 10:19:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RUyJZ-00031p-UF
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 10:19:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322475562!5317154!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5071 invoked from network); 28 Nov 2011 10:19:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 10:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9157105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 10:19:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 10:19:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4ED3641A0200007800063991@nat28.tlf.novell.com>
References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com>
	<20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org>
	<20110901141754.76cef93b.akpm@linux-foundation.org>
	<4E60C067.4010600@citrix.com>
	<20110902153204.59a928c1.akpm@linux-foundation.org>
	<20110906163553.GA28971@dumpdata.com>
	<20111105133846.GA4415@phenom.dumpdata.com>
	<20111107203613.GA6546@phenom.dumpdata.com>
	<4ED3641A0200007800063991@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 10:19:20 +0000
Message-ID: <1322475560.11846.26.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] mm: sync vmalloc address space page tables
 in alloc_vm_area()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 09:36 +0000, Jan Beulich wrote:
> >>> On 07.11.11 at 21:36, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > Patch included as attachment for easier review..
> 
> I just noticed that this patch made it upstream meanwhile, and that I
> should have paid more attention earlier: Once again this adds x86
> specific bits to (supposedly) architecture independent Xen code
> (lookup_address(), use of GNTMAP_contains_pte). Unless everyone
> agrees that x86 is going to remain the only architecture Xen will support
> going forward (no ia64, no ARM, nothing else), patches doing so (at
> least outside proper #ifdef-s or alike) should really be rejected.

I think it is up to those interested in such architectures to ensure
that a working baseline exists in the first place.

The ARM stuff hasn't even been submitted yet. When the arm stuff is
submitted it will naturally include fixes for these sorts issues as
necessary and at that point we can talk about regressions and reviewing
patches in order to avoid them (until then we can't really know what a
"regression" is). There is nothing unusual about that and nothing about
patches we take right now commit us to never supporting another arch in
the future so lets not get carried away here.

The IA64 support in mainline Linux does not appear to have anyone
interested in working on it. AFAICT it hasn't really been touched (other
than odd fixes and tree-wide cleanups) since it was first committed
(circa 2.6.25 IIRC). It doesn't even build right now and looks like it
hasn't built since at least 2.6.36, based on the one failure I happened
to look at.

I know you've been working on fixing up the hypervisor side of ia64
support things recently but it is not clear that there is an existing or
viable user or developer base for that port right now.

> Besides that, the patch also appears to close the road to running
> backends in HVM - use of GNTMAP_contains_pte isn't permitted for
> paging_mode_external() guests, so it's even a step backwards for
> x86.

That is a bigger concern.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 10:20:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 10:20:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUyJb-00032N-TE; Mon, 28 Nov 2011 10:19:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RUyJZ-00031p-UF
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 10:19:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322475562!5317154!1
X-Originating-IP: [62.200.22.115]
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5071 invoked from network); 28 Nov 2011 10:19:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 10:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9157105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 10:19:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 10:19:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4ED3641A0200007800063991@nat28.tlf.novell.com>
References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com>
	<20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org>
	<20110901141754.76cef93b.akpm@linux-foundation.org>
	<4E60C067.4010600@citrix.com>
	<20110902153204.59a928c1.akpm@linux-foundation.org>
	<20110906163553.GA28971@dumpdata.com>
	<20111105133846.GA4415@phenom.dumpdata.com>
	<20111107203613.GA6546@phenom.dumpdata.com>
	<4ED3641A0200007800063991@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 10:19:20 +0000
Message-ID: <1322475560.11846.26.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] mm: sync vmalloc address space page tables
 in alloc_vm_area()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 09:36 +0000, Jan Beulich wrote:
> >>> On 07.11.11 at 21:36, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > Patch included as attachment for easier review..
> 
> I just noticed that this patch made it upstream meanwhile, and that I
> should have paid more attention earlier: Once again this adds x86
> specific bits to (supposedly) architecture independent Xen code
> (lookup_address(), use of GNTMAP_contains_pte). Unless everyone
> agrees that x86 is going to remain the only architecture Xen will support
> going forward (no ia64, no ARM, nothing else), patches doing so (at
> least outside proper #ifdef-s or alike) should really be rejected.

I think it is up to those interested in such architectures to ensure
that a working baseline exists in the first place.

The ARM stuff hasn't even been submitted yet. When the arm stuff is
submitted it will naturally include fixes for these sorts issues as
necessary and at that point we can talk about regressions and reviewing
patches in order to avoid them (until then we can't really know what a
"regression" is). There is nothing unusual about that and nothing about
patches we take right now commit us to never supporting another arch in
the future so lets not get carried away here.

The IA64 support in mainline Linux does not appear to have anyone
interested in working on it. AFAICT it hasn't really been touched (other
than odd fixes and tree-wide cleanups) since it was first committed
(circa 2.6.25 IIRC). It doesn't even build right now and looks like it
hasn't built since at least 2.6.36, based on the one failure I happened
to look at.

I know you've been working on fixing up the hypervisor side of ia64
support things recently but it is not clear that there is an existing or
viable user or developer base for that port right now.

> Besides that, the patch also appears to close the road to running
> backends in HVM - use of GNTMAP_contains_pte isn't permitted for
> paging_mode_external() guests, so it's even a step backwards for
> x86.

That is a bigger concern.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 11:38:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 11:38:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUzWY-0003gu-0W; Mon, 28 Nov 2011 11:37:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RUzWV-0003gn-PZ
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 11:37:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322480177!58999984!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15796 invoked from network); 28 Nov 2011 11:36:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 11:36:18 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="19446750"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 06:36:51 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 28 Nov 2011
	06:36:51 -0500
Message-ID: <4ED37251.8040908@citrix.com>
Date: Mon, 28 Nov 2011 11:36:49 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com>	
	<20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org>	
	<20110901141754.76cef93b.akpm@linux-foundation.org>	
	<4E60C067.4010600@citrix.com>	
	<20110902153204.59a928c1.akpm@linux-foundation.org>	
	<20110906163553.GA28971@dumpdata.com>	
	<20111105133846.GA4415@phenom.dumpdata.com>	
	<20111107203613.GA6546@phenom.dumpdata.com>	
	<4ED3641A0200007800063991@nat28.tlf.novell.com>
	<1322475560.11846.26.camel@dagon.hellion.org.uk>
In-Reply-To: <1322475560.11846.26.camel@dagon.hellion.org.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] mm: sync vmalloc address space page tables
 in alloc_vm_area()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 28/11/11 10:19, Ian Campbell wrote:
> On Mon, 2011-11-28 at 09:36 +0000, Jan Beulich wrote:
>> Besides that, the patch also appears to close the road to running
>> backends in HVM - use of GNTMAP_contains_pte isn't permitted for
>> paging_mode_external() guests, so it's even a step backwards for
>> x86.
> 
> That is a bigger concern.

Daniel de Graaf has a patch series for this.

http://lists.xen.org/archives/html/xen-devel/2011-10/msg01484.html

Specifically: [PATCH 1/6] xenbus: Support HVM backends

http://lists.xen.org/archives/html/xen-devel/2011-10/msg01486.html

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 11:38:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 11:38:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUzWY-0003gu-0W; Mon, 28 Nov 2011 11:37:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RUzWV-0003gn-PZ
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 11:37:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322480177!58999984!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15796 invoked from network); 28 Nov 2011 11:36:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 11:36:18 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="19446750"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 06:36:51 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 28 Nov 2011
	06:36:51 -0500
Message-ID: <4ED37251.8040908@citrix.com>
Date: Mon, 28 Nov 2011 11:36:49 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com>	
	<20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org>	
	<20110901141754.76cef93b.akpm@linux-foundation.org>	
	<4E60C067.4010600@citrix.com>	
	<20110902153204.59a928c1.akpm@linux-foundation.org>	
	<20110906163553.GA28971@dumpdata.com>	
	<20111105133846.GA4415@phenom.dumpdata.com>	
	<20111107203613.GA6546@phenom.dumpdata.com>	
	<4ED3641A0200007800063991@nat28.tlf.novell.com>
	<1322475560.11846.26.camel@dagon.hellion.org.uk>
In-Reply-To: <1322475560.11846.26.camel@dagon.hellion.org.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] mm: sync vmalloc address space page tables
 in alloc_vm_area()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 28/11/11 10:19, Ian Campbell wrote:
> On Mon, 2011-11-28 at 09:36 +0000, Jan Beulich wrote:
>> Besides that, the patch also appears to close the road to running
>> backends in HVM - use of GNTMAP_contains_pte isn't permitted for
>> paging_mode_external() guests, so it's even a step backwards for
>> x86.
> 
> That is a bigger concern.

Daniel de Graaf has a patch series for this.

http://lists.xen.org/archives/html/xen-devel/2011-10/msg01484.html

Specifically: [PATCH 1/6] xenbus: Support HVM backends

http://lists.xen.org/archives/html/xen-devel/2011-10/msg01486.html

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 11:49:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 11:49:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUzi7-0004Je-QH; Mon, 28 Nov 2011 11:49:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RUzi6-0004JJ-RD
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 11:49:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322480926!6061417!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21793 invoked from network); 28 Nov 2011 11:48:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 11:48:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9159796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:48:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 11:48:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 28 Nov 2011 11:48:46 +0000
In-Reply-To: <4ED37251.8040908@citrix.com>
References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com>
	<20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org>
	<20110901141754.76cef93b.akpm@linux-foundation.org>
	<4E60C067.4010600@citrix.com>
	<20110902153204.59a928c1.akpm@linux-foundation.org>
	<20110906163553.GA28971@dumpdata.com>
	<20111105133846.GA4415@phenom.dumpdata.com>
	<20111107203613.GA6546@phenom.dumpdata.com>
	<4ED3641A0200007800063991@nat28.tlf.novell.com>
	<1322475560.11846.26.camel@dagon.hellion.org.uk>
	<4ED37251.8040908@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322480926.1005.287.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] mm: sync vmalloc address space page tables
 in alloc_vm_area()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 11:36 +0000, David Vrabel wrote:
> On 28/11/11 10:19, Ian Campbell wrote:
> > On Mon, 2011-11-28 at 09:36 +0000, Jan Beulich wrote:
> >> Besides that, the patch also appears to close the road to running
> >> backends in HVM - use of GNTMAP_contains_pte isn't permitted for
> >> paging_mode_external() guests, so it's even a step backwards for
> >> x86.
> > 
> > That is a bigger concern.
> 
> Daniel de Graaf has a patch series for this.
> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg01484.html
> 
> Specifically: [PATCH 1/6] xenbus: Support HVM backends
> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg01486.html

I'd forgotten about that, thanks!

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 11:49:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 11:49:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUzi7-0004Je-QH; Mon, 28 Nov 2011 11:49:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RUzi6-0004JJ-RD
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 11:49:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322480926!6061417!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21793 invoked from network); 28 Nov 2011 11:48:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 11:48:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9159796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:48:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 11:48:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 28 Nov 2011 11:48:46 +0000
In-Reply-To: <4ED37251.8040908@citrix.com>
References: <1314877863-21977-1-git-send-email-david.vrabel@citrix.com>
	<20110901161134.GA8979@dumpdata.com> <4E5FED1A.1000300@goop.org>
	<20110901141754.76cef93b.akpm@linux-foundation.org>
	<4E60C067.4010600@citrix.com>
	<20110902153204.59a928c1.akpm@linux-foundation.org>
	<20110906163553.GA28971@dumpdata.com>
	<20111105133846.GA4415@phenom.dumpdata.com>
	<20111107203613.GA6546@phenom.dumpdata.com>
	<4ED3641A0200007800063991@nat28.tlf.novell.com>
	<1322475560.11846.26.camel@dagon.hellion.org.uk>
	<4ED37251.8040908@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322480926.1005.287.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] mm: sync vmalloc address space page tables
 in alloc_vm_area()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 11:36 +0000, David Vrabel wrote:
> On 28/11/11 10:19, Ian Campbell wrote:
> > On Mon, 2011-11-28 at 09:36 +0000, Jan Beulich wrote:
> >> Besides that, the patch also appears to close the road to running
> >> backends in HVM - use of GNTMAP_contains_pte isn't permitted for
> >> paging_mode_external() guests, so it's even a step backwards for
> >> x86.
> > 
> > That is a bigger concern.
> 
> Daniel de Graaf has a patch series for this.
> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg01484.html
> 
> Specifically: [PATCH 1/6] xenbus: Support HVM backends
> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg01486.html

I'd forgotten about that, thanks!

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 11:59:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 11:59:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUzr5-0004jO-Vl; Mon, 28 Nov 2011 11:58:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUzr4-0004j7-Jj
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 11:58:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322481482!5312016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28936 invoked from network); 28 Nov 2011 11:58:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 11:58:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9160049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:58:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:58:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RUzqU-0003V6-0J	for xen-devel@lists.xensource.com;
	Mon, 28 Nov 2011 11:58:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RUzqT-0002c8-Vi	for
	xen-devel@lists.xensource.com; Mon, 28 Nov 2011 11:58:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.30537.970866.190935@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 11:58:01 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-10135-mainreport@xen.org>
References: <osstest-10135-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 10135: regressions - FAIL"):
> flight 10135 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10135/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-i386-rhel6hvm-intel  7 redhat-install       fail REGR. vs. 9956

My bisector wasn't able to finger an exact changeset due to a blocking
bug in the vicinity, but:

  pass      24183:53bec838bb08  Merge
  blocked   24184:4ecd3615e726  tools: use system installed libaio by default.
  blocked   24185:f88c745575bb  docs: remove some fatally out of date ...
  fail      24186:7aa5838499d1  tools: use system libaio for blktap1 as well.

Here the "system installed libaio" is that from Debian squeeze.

So for now I have applied the changeset below in the hope of getting a
pass and push.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1322481443 0
# Node ID a9c67c2daf4b0181ef2581471ea920eecb495616
# Parent  95d4e2e0bed374602b5a78ee004b057ad8715d65
tools: Revert to our built-in aio

These two changesets:
   24184:4ecd3615e726  tools: use system installed libaio by default.
   24186:7aa5838499d1  tools: use system libaio for blktap1 as well.
cause HVM guest installs (both Windows and Redhat) to fail on Debian
squeeze with xl.  So change the default for now.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 95d4e2e0bed3 -r a9c67c2daf4b Config.mk
--- a/Config.mk	Fri Nov 25 20:32:05 2011 +0000
+++ b/Config.mk	Mon Nov 28 11:57:23 2011 +0000
@@ -232,7 +232,7 @@ PYTHON_TOOLS       ?= y
 OCAML_TOOLS        ?= y
 CONFIG_MINITERM    ?= n
 CONFIG_LOMOUNT     ?= n
-CONFIG_SYSTEM_LIBAIO ?= y
+CONFIG_SYSTEM_LIBAIO ?= n
 
 ifeq ($(OCAML_TOOLS),y)
 OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 11:59:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 11:59:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUzr5-0004jO-Vl; Mon, 28 Nov 2011 11:58:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RUzr4-0004j7-Jj
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 11:58:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322481482!5312016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28936 invoked from network); 28 Nov 2011 11:58:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 11:58:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9160049"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:58:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:58:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RUzqU-0003V6-0J	for xen-devel@lists.xensource.com;
	Mon, 28 Nov 2011 11:58:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RUzqT-0002c8-Vi	for
	xen-devel@lists.xensource.com; Mon, 28 Nov 2011 11:58:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.30537.970866.190935@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 11:58:01 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-10135-mainreport@xen.org>
References: <osstest-10135-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 10135: regressions - FAIL"):
> flight 10135 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10135/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking:
>  test-amd64-i386-rhel6hvm-intel  7 redhat-install       fail REGR. vs. 9956

My bisector wasn't able to finger an exact changeset due to a blocking
bug in the vicinity, but:

  pass      24183:53bec838bb08  Merge
  blocked   24184:4ecd3615e726  tools: use system installed libaio by default.
  blocked   24185:f88c745575bb  docs: remove some fatally out of date ...
  fail      24186:7aa5838499d1  tools: use system libaio for blktap1 as well.

Here the "system installed libaio" is that from Debian squeeze.

So for now I have applied the changeset below in the hope of getting a
pass and push.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1322481443 0
# Node ID a9c67c2daf4b0181ef2581471ea920eecb495616
# Parent  95d4e2e0bed374602b5a78ee004b057ad8715d65
tools: Revert to our built-in aio

These two changesets:
   24184:4ecd3615e726  tools: use system installed libaio by default.
   24186:7aa5838499d1  tools: use system libaio for blktap1 as well.
cause HVM guest installs (both Windows and Redhat) to fail on Debian
squeeze with xl.  So change the default for now.

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 95d4e2e0bed3 -r a9c67c2daf4b Config.mk
--- a/Config.mk	Fri Nov 25 20:32:05 2011 +0000
+++ b/Config.mk	Mon Nov 28 11:57:23 2011 +0000
@@ -232,7 +232,7 @@ PYTHON_TOOLS       ?= y
 OCAML_TOOLS        ?= y
 CONFIG_MINITERM    ?= n
 CONFIG_LOMOUNT     ?= n
-CONFIG_SYSTEM_LIBAIO ?= y
+CONFIG_SYSTEM_LIBAIO ?= n
 
 ifeq ($(OCAML_TOOLS),y)
 OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:00:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:00:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUzsW-0004r6-2w; Mon, 28 Nov 2011 12:00:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RUzsU-0004nv-NH
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:00:06 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322481570!5285682!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11226 invoked from network); 28 Nov 2011 11:59:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 11:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9160092"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:59:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:59:30 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RUzru-0003Vc-5R;
	Mon, 28 Nov 2011 11:59:30 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RUzrf-0004pE-4I;
	Mon, 28 Nov 2011 11:59:15 +0000
Date: Mon, 28 Nov 2011 11:59:14 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111128115914.GD32513@spongy.cam.xci-test.com>
References: <4EA698C8.8030603@amd.com> <CACC6B9F.23926%keir.xen@gmail.com>
	<CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
	<4ECD30330200007800062C2E@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ECD30330200007800062C2E@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Christoph Egger <Christoph.Egger@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11 04:41, Jan Beulich wrote:
> >>> On 23.11.11 at 17:31, Jean Guyader <jean.guyader@gmail.com> wrote:
> > On 25 October 2011 13:35, Keir Fraser <keir.xen@gmail.com> wrote:
> >> On 25/10/2011 12:08, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
> >>
> >>>
> >>> Hi,
> >>>
> >>> Compiling the xen kernel fails with:
> >>>
> >>> xen/arch/x86/domain.c: In function 'alloc_domain_struct'
> >>> xen/arch/x86/domain.c:191: error: negative width in bit-field '<anonymous>'
> >>
> >> Problem is that struct domain has grown bigger than a page for some reason,
> >> in your build environment.
> >>
> >> I can't reproduce this.
> >>
> >>> Removing the line
> >>>
> >>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> >>>
> >>> makes xen kernel compile again.
> >>
> >> But not actually work properly. We only allocate a single page for the
> >> domain struct. If the struct is bigger than a page, you'll get memory
> >> corruption at run time.
> >>
> > 
> > Is there a reason for that?
> 
> Of course there is: Post-boot there shouldn't be any allocations of
> order greater than zero. This is a generally advisable thing, given that
> Xen can't reclaim memory arbitrarily from domains, and in particular
> also necessary for tmem.
> 
> > What would be the recommended to add something
> > into the struct domain now if we can't make it bigger than a page.
> 
> Put a pointer to your data (or larger parts that are already there)
> instead of the data itself into struct domain, and allocate it
> separately. (You may have seen a patch from Olaf Hering late
> yesterday or earlier today that moved the mem_event pieces out
> of there for this very reason.)
> 
> 

I've printed sizeof (struct domain) on boot with xen-unstable and it's
exactly a PAGE big. That mean that if I want a add a value to the struct
domain (event a pointer) I will have to make some room first.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:00:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:00:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RUzsW-0004r6-2w; Mon, 28 Nov 2011 12:00:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RUzsU-0004nv-NH
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:00:06 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322481570!5285682!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11226 invoked from network); 28 Nov 2011 11:59:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 11:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9160092"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:59:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:59:30 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RUzru-0003Vc-5R;
	Mon, 28 Nov 2011 11:59:30 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RUzrf-0004pE-4I;
	Mon, 28 Nov 2011 11:59:15 +0000
Date: Mon, 28 Nov 2011 11:59:14 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111128115914.GD32513@spongy.cam.xci-test.com>
References: <4EA698C8.8030603@amd.com> <CACC6B9F.23926%keir.xen@gmail.com>
	<CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
	<4ECD30330200007800062C2E@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ECD30330200007800062C2E@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Christoph Egger <Christoph.Egger@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 23/11 04:41, Jan Beulich wrote:
> >>> On 23.11.11 at 17:31, Jean Guyader <jean.guyader@gmail.com> wrote:
> > On 25 October 2011 13:35, Keir Fraser <keir.xen@gmail.com> wrote:
> >> On 25/10/2011 12:08, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
> >>
> >>>
> >>> Hi,
> >>>
> >>> Compiling the xen kernel fails with:
> >>>
> >>> xen/arch/x86/domain.c: In function 'alloc_domain_struct'
> >>> xen/arch/x86/domain.c:191: error: negative width in bit-field '<anonymous>'
> >>
> >> Problem is that struct domain has grown bigger than a page for some reason,
> >> in your build environment.
> >>
> >> I can't reproduce this.
> >>
> >>> Removing the line
> >>>
> >>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> >>>
> >>> makes xen kernel compile again.
> >>
> >> But not actually work properly. We only allocate a single page for the
> >> domain struct. If the struct is bigger than a page, you'll get memory
> >> corruption at run time.
> >>
> > 
> > Is there a reason for that?
> 
> Of course there is: Post-boot there shouldn't be any allocations of
> order greater than zero. This is a generally advisable thing, given that
> Xen can't reclaim memory arbitrarily from domains, and in particular
> also necessary for tmem.
> 
> > What would be the recommended to add something
> > into the struct domain now if we can't make it bigger than a page.
> 
> Put a pointer to your data (or larger parts that are already there)
> instead of the data itself into struct domain, and allocate it
> separately. (You may have seen a patch from Olaf Hering late
> yesterday or earlier today that moved the mem_event pieces out
> of there for this very reason.)
> 
> 

I've printed sizeof (struct domain) on boot with xen-unstable and it's
exactly a PAGE big. That mean that if I want a add a value to the struct
domain (event a pointer) I will have to make some room first.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:17:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09S-0005M4-KT; Mon, 28 Nov 2011 12:17:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09R-0005Lq-5N
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:37 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322482579!58587648!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30585 invoked from network); 28 Nov 2011 12:16:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="172010691"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:04 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:03 -0500
MIME-Version: 1.0
X-Mercurial-Node: 346b54217c4c3fcdebfde41d636d0ec1c11a7672
Message-ID: <346b54217c4c3fcdebfd.1322482533@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322482532@cosworth.uk.xensource.com>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:33 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 5] Add an ACPI device exposing a package
 called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322482488 0
# Node ID 346b54217c4c3fcdebfde41d636d0ec1c11a7672
# Parent  a9c67c2daf4b0181ef2581471ea920eecb495616
Add an ACPI device exposing a package called ADDR, evaluating to two
integers, and with _CID and _DDN set to "VM_Gen_Counter".

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r a9c67c2daf4b -r 346b54217c4c tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 12:14:48 2011 +0000
@@ -47,6 +47,7 @@ struct acpi_info {
     uint32_t pci_min, pci_len;  /* 4, 8 - PCI I/O hole boundaries */
     uint32_t madt_csum_addr;    /* 12   - Address of MADT checksum */
     uint32_t madt_lapic0_addr;  /* 16   - Address of first MADT LAPIC struct */
+    uint32_t vm_gid_addr;       /* 20   - Address of VM generation id buffer */
 };
 
 /* Number of processor objects in the chosen DSDT. */
diff -r a9c67c2daf4b -r 346b54217c4c tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Mon Nov 28 12:14:48 2011 +0000
@@ -55,7 +55,8 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
            PMIN, 32,
            PLEN, 32,
            MSUA, 32, /* MADT checksum address */
-           MAPA, 32  /* MADT LAPIC0 address */
+           MAPA, 32, /* MADT LAPIC0 address */
+           VGIA, 32  /* VM generation id address */
        }
 
         /* Fix HCT test for 0x400 pci memory:
@@ -396,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
                         IRQNoFlags () {7}
                     })
                 } 
+
+                Device(VGID) {
+                    Name(_HID, "ACPI0001")
+                    Name(_UID, 0x00)
+                    Name(_CID, "VM_Gen_Counter")
+                    Name(_DDN, "VM_Gen_Counter")
+                    Method(_STA, 0, NotSerialized)
+                    {
+                        If(LEqual(\_SB.VGIA, 0x00000000)) {
+                            Return(0x00)
+                        } Else {
+                            Return(0x0F)
+                        }
+                    }
+                    Name(PKG, Package ()
+                    {
+                        0x00000000,
+                        0x00000000
+                    })
+                    Method(ADDR, 0, NotSerialized)
+                    {
+                        Store(\_SB.VGIA, Index(PKG, 0))
+                        Return(PKG)
+                    }
+                }
             }
         }
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:17:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09S-0005M4-KT; Mon, 28 Nov 2011 12:17:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09R-0005Lq-5N
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:37 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322482579!58587648!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30585 invoked from network); 28 Nov 2011 12:16:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="172010691"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:04 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:03 -0500
MIME-Version: 1.0
X-Mercurial-Node: 346b54217c4c3fcdebfde41d636d0ec1c11a7672
Message-ID: <346b54217c4c3fcdebfd.1322482533@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322482532@cosworth.uk.xensource.com>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:33 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 5] Add an ACPI device exposing a package
 called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322482488 0
# Node ID 346b54217c4c3fcdebfde41d636d0ec1c11a7672
# Parent  a9c67c2daf4b0181ef2581471ea920eecb495616
Add an ACPI device exposing a package called ADDR, evaluating to two
integers, and with _CID and _DDN set to "VM_Gen_Counter".

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r a9c67c2daf4b -r 346b54217c4c tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 12:14:48 2011 +0000
@@ -47,6 +47,7 @@ struct acpi_info {
     uint32_t pci_min, pci_len;  /* 4, 8 - PCI I/O hole boundaries */
     uint32_t madt_csum_addr;    /* 12   - Address of MADT checksum */
     uint32_t madt_lapic0_addr;  /* 16   - Address of first MADT LAPIC struct */
+    uint32_t vm_gid_addr;       /* 20   - Address of VM generation id buffer */
 };
 
 /* Number of processor objects in the chosen DSDT. */
diff -r a9c67c2daf4b -r 346b54217c4c tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Mon Nov 28 12:14:48 2011 +0000
@@ -55,7 +55,8 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
            PMIN, 32,
            PLEN, 32,
            MSUA, 32, /* MADT checksum address */
-           MAPA, 32  /* MADT LAPIC0 address */
+           MAPA, 32, /* MADT LAPIC0 address */
+           VGIA, 32  /* VM generation id address */
        }
 
         /* Fix HCT test for 0x400 pci memory:
@@ -396,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
                         IRQNoFlags () {7}
                     })
                 } 
+
+                Device(VGID) {
+                    Name(_HID, "ACPI0001")
+                    Name(_UID, 0x00)
+                    Name(_CID, "VM_Gen_Counter")
+                    Name(_DDN, "VM_Gen_Counter")
+                    Method(_STA, 0, NotSerialized)
+                    {
+                        If(LEqual(\_SB.VGIA, 0x00000000)) {
+                            Return(0x00)
+                        } Else {
+                            Return(0x0F)
+                        }
+                    }
+                    Name(PKG, Package ()
+                    {
+                        0x00000000,
+                        0x00000000
+                    })
+                    Method(ADDR, 0, NotSerialized)
+                    {
+                        Store(\_SB.VGIA, Index(PKG, 0))
+                        Return(PKG)
+                    }
+                }
             }
         }
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:17:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09R-0005Lr-7Z; Mon, 28 Nov 2011 12:17:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09Q-0005Lk-1b
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:36 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322482589!54868599!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9324 invoked from network); 28 Nov 2011 12:16:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="19447523"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:03 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:03 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:32 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 5] Add support for a VM generation ID
	virtual device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The following patch series adds support for a VM generation ID
virtual device.
The basic requirements of this device are as follows:

- It must be exposed somewhere in ACPI namespace with a _CID of
  "VM_Gen_Counter".
- It must also include a _DDN of "VM_Gen_Counter".
- It must contain a _HID object but no particular value is
  required.
- It must expose a package called ADDR which evaluates to two
  integers; the first being the low order 32-bits of a guest
  physical address (GPA), the second by the high order 32-bits of
  the GPA. This GPA is the address of an 8-byte aligned 8-byte
  buffer containing the VM generation ID.
  This buffer must not be in ranges supported as AddressRangeMemory
  or AddressRangeACPI and must not be mapped by any PTE with caching
  disabled.

The semantics of the VM generation ID itself are left up to the tools
but it must be possible to change it each time the VM is booted,
migrated, or restored from a saved image.

Patch 1 adds the device and an acpi_info field to allow population
of the ADDR package.
Patch 2 adds ctype infrastructure to hvloader in preparation for...
Patch 3 adds all the code to plumb the value of a new 'generation_id'
parameter in the VM config through to the VM generation id buffer at
VM boot time.
Patch 4 adds code to do the same at VM migrate or restore time.
Patch 5 is some code tidy-up facilitated by the patch 4.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:17:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09R-0005Lr-7Z; Mon, 28 Nov 2011 12:17:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09Q-0005Lk-1b
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:36 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322482589!54868599!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9324 invoked from network); 28 Nov 2011 12:16:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="19447523"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:03 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:03 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:32 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 5] Add support for a VM generation ID
	virtual device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The following patch series adds support for a VM generation ID
virtual device.
The basic requirements of this device are as follows:

- It must be exposed somewhere in ACPI namespace with a _CID of
  "VM_Gen_Counter".
- It must also include a _DDN of "VM_Gen_Counter".
- It must contain a _HID object but no particular value is
  required.
- It must expose a package called ADDR which evaluates to two
  integers; the first being the low order 32-bits of a guest
  physical address (GPA), the second by the high order 32-bits of
  the GPA. This GPA is the address of an 8-byte aligned 8-byte
  buffer containing the VM generation ID.
  This buffer must not be in ranges supported as AddressRangeMemory
  or AddressRangeACPI and must not be mapped by any PTE with caching
  disabled.

The semantics of the VM generation ID itself are left up to the tools
but it must be possible to change it each time the VM is booted,
migrated, or restored from a saved image.

Patch 1 adds the device and an acpi_info field to allow population
of the ADDR package.
Patch 2 adds ctype infrastructure to hvloader in preparation for...
Patch 3 adds all the code to plumb the value of a new 'generation_id'
parameter in the VM config through to the VM generation id buffer at
VM boot time.
Patch 4 adds code to do the same at VM migrate or restore time.
Patch 5 is some code tidy-up facilitated by the patch 4.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:17:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09W-0005MU-1n; Mon, 28 Nov 2011 12:17:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09V-0005M0-0O
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:41 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322482579!58587648!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30635 invoked from network); 28 Nov 2011 12:16:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="172010693"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:05 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:05 -0500
MIME-Version: 1.0
X-Mercurial-Node: 3886d406c13aa66b2af123d52a1bef8b6f41d144
Message-ID: <3886d406c13aa66b2af1.1322482535@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322482532@cosworth.uk.xensource.com>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:35 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 5] Allocate an 8 byte buffer to contain the
 VM generation id and populate it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322482488 0
# Node ID 3886d406c13aa66b2af123d52a1bef8b6f41d144
# Parent  b383a1053d1d5e598bb39923eee8cec57e5666e9
Allocate an 8 byte buffer to contain the VM generation id and populate it
at boot time with a value read from "platform/generation_id". Also add
code to libxl to populate this xenstore key with the value of a new
'generation_id' parameter in the VM config file.
Populate the ADDR package of VM_Gen_Counter ACPI device such that the first
integer evaluates to the low order 32 bits of the buffer address and the
second integer evaluates to the high order 32 bits of the buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r b383a1053d1d -r 3886d406c13a tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 12:14:48 2011 +0000
@@ -297,6 +297,20 @@ static int construct_secondary_tables(un
     return nr_tables;
 }
 
+unsigned long new_vm_gid(void)
+{
+    uint64_t gid;
+    unsigned char *buf;
+
+    buf = mem_alloc(8, 8);
+    if (!buf) return 0;
+
+    gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
+    *(uint64_t *)buf = gid;
+
+    return virt_to_phys(buf);    
+}
+
 void acpi_build_tables(struct acpi_config *config, unsigned int physical)
 {
     struct acpi_info *acpi_info;
@@ -309,6 +323,7 @@ void acpi_build_tables(struct acpi_confi
     unsigned char       *dsdt;
     unsigned long        secondary_tables[16];
     int                  nr_secondaries, i;
+    unsigned long        vm_gid_addr;
 
     /* Allocate and initialise the acpi info area. */
     mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
@@ -421,12 +436,16 @@ void acpi_build_tables(struct acpi_confi
                  offsetof(struct acpi_20_rsdp, extended_checksum),
                  sizeof(struct acpi_20_rsdp));
 
+    vm_gid_addr = new_vm_gid();
+    if (!vm_gid_addr) goto oom;
+
     acpi_info->com1_present = uart_exists(0x3f8);
     acpi_info->com2_present = uart_exists(0x2f8);
     acpi_info->lpt1_present = lpt_exists(0x378);
     acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
     acpi_info->pci_min = pci_mem_start;
     acpi_info->pci_len = pci_mem_end - pci_mem_start;
+    acpi_info->vm_gid_addr = vm_gid_addr;
 
     return;
 
diff -r b383a1053d1d -r 3886d406c13a tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
@@ -205,6 +205,78 @@ strlen(const char *s)
     return i;
 }
 
+static inline int __digit(char c, int base)
+{
+    int d = -1;
+
+    if ( (c >= '0') && (c <= '9') )
+        d = c - '0';
+
+    if ( (c >= 'A') && (c <= 'Z') )
+        d = c - 'A' + 10;
+
+    if ( (c >= 'a') && (c <= 'z') )
+        d = c - 'a' + 10;
+
+    if (d >= base)
+        d = -1;
+
+    return d;
+}
+
+long long
+strtoll(const char *s, char **end, int base)
+{
+    long long v = 0;
+    int sign = 1;
+
+    while ( (*s != '\0') && isspace(*s) )
+        s++;
+
+    if ( *s == '\0' ) goto out;
+
+    if ( *s == '-' ) {
+        sign = -1;
+        s++;
+    } else {
+        if ( *s == '+' )
+            s++;
+    }
+
+    if ( *s == '\0' ) goto out;
+
+    if ( *s == '0' ) {
+        s++;
+        if ( *s == '\0' ) goto out;
+
+        if ( *s == 'x' ) {
+            if ( base != 0 && base != 16) goto out;
+            base = 16;
+            s++;
+        } else {
+            if ( base != 0 && base != 8) goto out;
+            base = 8;
+        }
+    } else {
+        if (base != 0 && base != 10) goto out;
+        base = 10;
+    }
+
+    while ( *s != '\0' ) {
+        int d = __digit(*s, base);
+
+        if ( d < 0 ) goto out;
+
+        v = (v * base) + d;
+        s++;
+    }
+
+out:
+    if (end) *end = (char *)s;
+
+    return sign * v;
+}
+
 void *
 memset(void *s, int c, unsigned n)
 {
diff -r b383a1053d1d -r 3886d406c13a tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
@@ -152,6 +152,7 @@ int strncmp(const char *s1, const char *
 char *strcpy(char *dest, const char *src);
 char *strncpy(char *dest, const char *src, unsigned n);
 unsigned strlen(const char *s);
+long long strtoll(const char *s, char **end, int base);
 int memcmp(const void *s1, const void *s2, unsigned n);
 void *memcpy(void *dest, const void *src, unsigned n);
 void *memmove(void *dest, const void *src, unsigned n);
diff -r b383a1053d1d -r 3886d406c13a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/libxl_create.c	Mon Nov 28 12:14:48 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.generation_id = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -191,13 +192,15 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 7, sizeof(char *));
+        localents = libxl__calloc(gc, 9, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
         localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
         localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[6] = "platform/generation-id";
+        localents[7] = libxl__sprintf(gc, "0x%llx", info->u.hvm.generation_id);
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r b383a1053d1d -r 3886d406c13a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Nov 28 12:14:48 2011 +0000
@@ -176,6 +176,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("generation_id", uint64),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r b383a1053d1d -r 3886d406c13a tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Mon Nov 28 12:14:48 2011 +0000
@@ -232,7 +232,35 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
+                          long long *value_r) {
+    long long ll;
+    XLU_ConfigSetting *set;
+    int e;
+    char *ep;
 
+    e= find_atom(cfg,n,&set);  if (e) return e;
+    errno= 0; ll= strtoll(set->values[0], &ep, 0);
+    e= errno;
+    if (errno) {
+        e= errno;
+        assert(e==EINVAL || e==ERANGE);
+        fprintf(cfg->report,
+                "%s:%d: warning: parameter `%s' could not be parsed"
+                " as a number: %s\n",
+                cfg->filename, set->lineno, n, strerror(e));
+        return e;
+    }
+    if (*ep || ep==set->values[0]) {
+        fprintf(cfg->report,
+                "%s:%d: warning: parameter `%s' is not a valid number\n",
+                cfg->filename, set->lineno, n);
+        return EINVAL;
+    }
+    *value_r= ll;
+    return 0;
+}
+ 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
     XLU_ConfigSetting *set;
diff -r b383a1053d1d -r 3886d406c13a tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/libxlutil.h	Mon Nov 28 12:14:48 2011 +0000
@@ -48,6 +48,7 @@ void xlu_cfg_destroy(XLU_Config*);
 int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r);
 int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char **value_r); /* free/strdup version */
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r);
+int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long long *value_r);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r b383a1053d1d -r 3886d406c13a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 12:14:48 2011 +0000
@@ -355,6 +355,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(generation_id %llx)\n", b_info->u.hvm.generation_id);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -523,6 +524,7 @@ static void parse_config_data(const char
 {
     const char *buf;
     long l;
+    long long ll;
     XLU_Config *config;
     XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
@@ -699,6 +701,8 @@ static void parse_config_data(const char
             b_info->u.hvm.timer_mode = l;
         if (!xlu_cfg_get_long (config, "nestedhvm", &l))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long_long (config, "generation_id", &ll))
+            b_info->u.hvm.generation_id = ll;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:17:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09W-0005MU-1n; Mon, 28 Nov 2011 12:17:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09V-0005M0-0O
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:41 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322482579!58587648!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30635 invoked from network); 28 Nov 2011 12:16:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="172010693"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:05 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:05 -0500
MIME-Version: 1.0
X-Mercurial-Node: 3886d406c13aa66b2af123d52a1bef8b6f41d144
Message-ID: <3886d406c13aa66b2af1.1322482535@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322482532@cosworth.uk.xensource.com>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:35 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 5] Allocate an 8 byte buffer to contain the
 VM generation id and populate it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322482488 0
# Node ID 3886d406c13aa66b2af123d52a1bef8b6f41d144
# Parent  b383a1053d1d5e598bb39923eee8cec57e5666e9
Allocate an 8 byte buffer to contain the VM generation id and populate it
at boot time with a value read from "platform/generation_id". Also add
code to libxl to populate this xenstore key with the value of a new
'generation_id' parameter in the VM config file.
Populate the ADDR package of VM_Gen_Counter ACPI device such that the first
integer evaluates to the low order 32 bits of the buffer address and the
second integer evaluates to the high order 32 bits of the buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r b383a1053d1d -r 3886d406c13a tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 12:14:48 2011 +0000
@@ -297,6 +297,20 @@ static int construct_secondary_tables(un
     return nr_tables;
 }
 
+unsigned long new_vm_gid(void)
+{
+    uint64_t gid;
+    unsigned char *buf;
+
+    buf = mem_alloc(8, 8);
+    if (!buf) return 0;
+
+    gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
+    *(uint64_t *)buf = gid;
+
+    return virt_to_phys(buf);    
+}
+
 void acpi_build_tables(struct acpi_config *config, unsigned int physical)
 {
     struct acpi_info *acpi_info;
@@ -309,6 +323,7 @@ void acpi_build_tables(struct acpi_confi
     unsigned char       *dsdt;
     unsigned long        secondary_tables[16];
     int                  nr_secondaries, i;
+    unsigned long        vm_gid_addr;
 
     /* Allocate and initialise the acpi info area. */
     mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
@@ -421,12 +436,16 @@ void acpi_build_tables(struct acpi_confi
                  offsetof(struct acpi_20_rsdp, extended_checksum),
                  sizeof(struct acpi_20_rsdp));
 
+    vm_gid_addr = new_vm_gid();
+    if (!vm_gid_addr) goto oom;
+
     acpi_info->com1_present = uart_exists(0x3f8);
     acpi_info->com2_present = uart_exists(0x2f8);
     acpi_info->lpt1_present = lpt_exists(0x378);
     acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
     acpi_info->pci_min = pci_mem_start;
     acpi_info->pci_len = pci_mem_end - pci_mem_start;
+    acpi_info->vm_gid_addr = vm_gid_addr;
 
     return;
 
diff -r b383a1053d1d -r 3886d406c13a tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
@@ -205,6 +205,78 @@ strlen(const char *s)
     return i;
 }
 
+static inline int __digit(char c, int base)
+{
+    int d = -1;
+
+    if ( (c >= '0') && (c <= '9') )
+        d = c - '0';
+
+    if ( (c >= 'A') && (c <= 'Z') )
+        d = c - 'A' + 10;
+
+    if ( (c >= 'a') && (c <= 'z') )
+        d = c - 'a' + 10;
+
+    if (d >= base)
+        d = -1;
+
+    return d;
+}
+
+long long
+strtoll(const char *s, char **end, int base)
+{
+    long long v = 0;
+    int sign = 1;
+
+    while ( (*s != '\0') && isspace(*s) )
+        s++;
+
+    if ( *s == '\0' ) goto out;
+
+    if ( *s == '-' ) {
+        sign = -1;
+        s++;
+    } else {
+        if ( *s == '+' )
+            s++;
+    }
+
+    if ( *s == '\0' ) goto out;
+
+    if ( *s == '0' ) {
+        s++;
+        if ( *s == '\0' ) goto out;
+
+        if ( *s == 'x' ) {
+            if ( base != 0 && base != 16) goto out;
+            base = 16;
+            s++;
+        } else {
+            if ( base != 0 && base != 8) goto out;
+            base = 8;
+        }
+    } else {
+        if (base != 0 && base != 10) goto out;
+        base = 10;
+    }
+
+    while ( *s != '\0' ) {
+        int d = __digit(*s, base);
+
+        if ( d < 0 ) goto out;
+
+        v = (v * base) + d;
+        s++;
+    }
+
+out:
+    if (end) *end = (char *)s;
+
+    return sign * v;
+}
+
 void *
 memset(void *s, int c, unsigned n)
 {
diff -r b383a1053d1d -r 3886d406c13a tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
@@ -152,6 +152,7 @@ int strncmp(const char *s1, const char *
 char *strcpy(char *dest, const char *src);
 char *strncpy(char *dest, const char *src, unsigned n);
 unsigned strlen(const char *s);
+long long strtoll(const char *s, char **end, int base);
 int memcmp(const void *s1, const void *s2, unsigned n);
 void *memcpy(void *dest, const void *src, unsigned n);
 void *memmove(void *dest, const void *src, unsigned n);
diff -r b383a1053d1d -r 3886d406c13a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/libxl_create.c	Mon Nov 28 12:14:48 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.generation_id = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -191,13 +192,15 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 7, sizeof(char *));
+        localents = libxl__calloc(gc, 9, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
         localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
         localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[6] = "platform/generation-id";
+        localents[7] = libxl__sprintf(gc, "0x%llx", info->u.hvm.generation_id);
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r b383a1053d1d -r 3886d406c13a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Nov 28 12:14:48 2011 +0000
@@ -176,6 +176,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("generation_id", uint64),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r b383a1053d1d -r 3886d406c13a tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Mon Nov 28 12:14:48 2011 +0000
@@ -232,7 +232,35 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
+                          long long *value_r) {
+    long long ll;
+    XLU_ConfigSetting *set;
+    int e;
+    char *ep;
 
+    e= find_atom(cfg,n,&set);  if (e) return e;
+    errno= 0; ll= strtoll(set->values[0], &ep, 0);
+    e= errno;
+    if (errno) {
+        e= errno;
+        assert(e==EINVAL || e==ERANGE);
+        fprintf(cfg->report,
+                "%s:%d: warning: parameter `%s' could not be parsed"
+                " as a number: %s\n",
+                cfg->filename, set->lineno, n, strerror(e));
+        return e;
+    }
+    if (*ep || ep==set->values[0]) {
+        fprintf(cfg->report,
+                "%s:%d: warning: parameter `%s' is not a valid number\n",
+                cfg->filename, set->lineno, n);
+        return EINVAL;
+    }
+    *value_r= ll;
+    return 0;
+}
+ 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
     XLU_ConfigSetting *set;
diff -r b383a1053d1d -r 3886d406c13a tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/libxlutil.h	Mon Nov 28 12:14:48 2011 +0000
@@ -48,6 +48,7 @@ void xlu_cfg_destroy(XLU_Config*);
 int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r);
 int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char **value_r); /* free/strdup version */
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r);
+int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long long *value_r);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r b383a1053d1d -r 3886d406c13a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 12:14:48 2011 +0000
@@ -355,6 +355,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(generation_id %llx)\n", b_info->u.hvm.generation_id);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -523,6 +524,7 @@ static void parse_config_data(const char
 {
     const char *buf;
     long l;
+    long long ll;
     XLU_Config *config;
     XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
@@ -699,6 +701,8 @@ static void parse_config_data(const char
             b_info->u.hvm.timer_mode = l;
         if (!xlu_cfg_get_long (config, "nestedhvm", &l))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long_long (config, "generation_id", &ll))
+            b_info->u.hvm.generation_id = ll;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:17:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09X-0005Mj-Gc; Mon, 28 Nov 2011 12:17:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09V-0005Ll-I4
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:41 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322482589!54868599!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9356 invoked from network); 28 Nov 2011 12:16:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="19447524"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:04 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:04 -0500
MIME-Version: 1.0
X-Mercurial-Node: b383a1053d1d5e598bb39923eee8cec57e5666e9
Message-ID: <b383a1053d1d5e598bb3.1322482534@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322482532@cosworth.uk.xensource.com>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:34 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 5] Add 'ctype' infrastructure to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322482488 0
# Node ID b383a1053d1d5e598bb39923eee8cec57e5666e9
# Parent  346b54217c4c3fcdebfde41d636d0ec1c11a7672
Add 'ctype' infrastructure to hvmloader.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/Makefile	Mon Nov 28 12:14:48 2011 +0000
@@ -30,7 +30,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
 OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
-OBJS += e820.o pci.o pir.o
+OBJS += e820.o pci.o pir.o ctype.o
 ifeq ($(debug),y)
 OBJS += tests.o
 endif
diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/ctype.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/ctype.c	Mon Nov 28 12:14:48 2011 +0000
@@ -0,0 +1,27 @@
+#include "ctype.h"
+
+const unsigned char _ctype[] = {
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 0-7 */
+_C,_C|_S,_C|_S,_C|_S,_C|_S,_C|_S,_C,_C,         /* 8-15 */
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 16-23 */
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 24-31 */
+_S|_SP,_P,_P,_P,_P,_P,_P,_P,                    /* 32-39 */
+_P,_P,_P,_P,_P,_P,_P,_P,                        /* 40-47 */
+_D,_D,_D,_D,_D,_D,_D,_D,                        /* 48-55 */
+_D,_D,_P,_P,_P,_P,_P,_P,                        /* 56-63 */
+_P,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U,      /* 64-71 */
+_U,_U,_U,_U,_U,_U,_U,_U,                        /* 72-79 */
+_U,_U,_U,_U,_U,_U,_U,_U,                        /* 80-87 */
+_U,_U,_U,_P,_P,_P,_P,_P,                        /* 88-95 */
+_P,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L,      /* 96-103 */
+_L,_L,_L,_L,_L,_L,_L,_L,                        /* 104-111 */
+_L,_L,_L,_L,_L,_L,_L,_L,                        /* 112-119 */
+_L,_L,_L,_P,_P,_P,_P,_C,                        /* 120-127 */
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 128-143 */
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 144-159 */
+_S|_SP,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,   /* 160-175 */
+_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,       /* 176-191 */
+_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,       /* 192-207 */
+_U,_U,_U,_U,_U,_U,_U,_P,_U,_U,_U,_U,_U,_U,_U,_L,       /* 208-223 */
+_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,       /* 224-239 */
+_L,_L,_L,_L,_L,_L,_L,_P,_L,_L,_L,_L,_L,_L,_L,_L};      /* 240-255 */
diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/ctype.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/ctype.h	Mon Nov 28 12:14:48 2011 +0000
@@ -0,0 +1,30 @@
+#ifndef __HVMLOADER_CTYPE_H__
+#define __HVMLOADER_CTYPE_H__
+
+#define _U	0x01	/* upper */
+#define _L	0x02	/* lower */
+#define _D	0x04	/* digit */
+#define _C	0x08	/* cntrl */
+#define _P	0x10	/* punct */
+#define _S	0x20	/* white space (space/lf/tab) */
+#define _X	0x40	/* hex digit */
+#define _SP	0x80	/* hard space (0x20) */
+
+extern const unsigned char _ctype[];
+
+#define __ismask(x) (_ctype[(int)(unsigned char)(x)])
+
+#define isalnum(c)	((__ismask(c)&(_U|_L|_D)) != 0)
+#define isalpha(c)	((__ismask(c)&(_U|_L)) != 0)
+#define iscntrl(c)	((__ismask(c)&(_C)) != 0)
+#define isdigit(c)	((__ismask(c)&(_D)) != 0)
+#define isgraph(c)	((__ismask(c)&(_P|_U|_L|_D)) != 0)
+#define islower(c)	((__ismask(c)&(_L)) != 0)
+#define isprint(c)	((__ismask(c)&(_P|_U|_L|_D|_SP)) != 0)
+#define ispunct(c)	((__ismask(c)&(_P)) != 0)
+#define isspace(c)	((__ismask(c)&(_S)) != 0)
+#define isupper(c)	((__ismask(c)&(_U)) != 0)
+#define isxdigit(c)	((__ismask(c)&(_D|_X)) != 0)
+
+#endif /* __HVMLOADER_CTYPE_H__ */
+
diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
@@ -21,6 +21,7 @@
 #include "util.h"
 #include "config.h"
 #include "hypercall.h"
+#include "ctype.h"
 #include <stdint.h>
 #include <xen/xen.h>
 #include <xen/memory.h>
diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
@@ -225,8 +225,6 @@ void perform_tests(void);
 #define perform_tests() ((void)0)
 #endif
 
-#define isdigit(c) ((c) >= '0' && (c) <= '9')
-
 extern char _start[], _end[];
 
 #endif /* __HVMLOADER_UTIL_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:17:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09X-0005Mj-Gc; Mon, 28 Nov 2011 12:17:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09V-0005Ll-I4
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:41 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322482589!54868599!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9356 invoked from network); 28 Nov 2011 12:16:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="19447524"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:04 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:04 -0500
MIME-Version: 1.0
X-Mercurial-Node: b383a1053d1d5e598bb39923eee8cec57e5666e9
Message-ID: <b383a1053d1d5e598bb3.1322482534@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322482532@cosworth.uk.xensource.com>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:34 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 5] Add 'ctype' infrastructure to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322482488 0
# Node ID b383a1053d1d5e598bb39923eee8cec57e5666e9
# Parent  346b54217c4c3fcdebfde41d636d0ec1c11a7672
Add 'ctype' infrastructure to hvmloader.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/Makefile	Mon Nov 28 12:14:48 2011 +0000
@@ -30,7 +30,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
 OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
-OBJS += e820.o pci.o pir.o
+OBJS += e820.o pci.o pir.o ctype.o
 ifeq ($(debug),y)
 OBJS += tests.o
 endif
diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/ctype.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/ctype.c	Mon Nov 28 12:14:48 2011 +0000
@@ -0,0 +1,27 @@
+#include "ctype.h"
+
+const unsigned char _ctype[] = {
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 0-7 */
+_C,_C|_S,_C|_S,_C|_S,_C|_S,_C|_S,_C,_C,         /* 8-15 */
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 16-23 */
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 24-31 */
+_S|_SP,_P,_P,_P,_P,_P,_P,_P,                    /* 32-39 */
+_P,_P,_P,_P,_P,_P,_P,_P,                        /* 40-47 */
+_D,_D,_D,_D,_D,_D,_D,_D,                        /* 48-55 */
+_D,_D,_P,_P,_P,_P,_P,_P,                        /* 56-63 */
+_P,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U,      /* 64-71 */
+_U,_U,_U,_U,_U,_U,_U,_U,                        /* 72-79 */
+_U,_U,_U,_U,_U,_U,_U,_U,                        /* 80-87 */
+_U,_U,_U,_P,_P,_P,_P,_P,                        /* 88-95 */
+_P,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L,      /* 96-103 */
+_L,_L,_L,_L,_L,_L,_L,_L,                        /* 104-111 */
+_L,_L,_L,_L,_L,_L,_L,_L,                        /* 112-119 */
+_L,_L,_L,_P,_P,_P,_P,_C,                        /* 120-127 */
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 128-143 */
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 144-159 */
+_S|_SP,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,   /* 160-175 */
+_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,       /* 176-191 */
+_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,       /* 192-207 */
+_U,_U,_U,_U,_U,_U,_U,_P,_U,_U,_U,_U,_U,_U,_U,_L,       /* 208-223 */
+_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,       /* 224-239 */
+_L,_L,_L,_L,_L,_L,_L,_P,_L,_L,_L,_L,_L,_L,_L,_L};      /* 240-255 */
diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/ctype.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/ctype.h	Mon Nov 28 12:14:48 2011 +0000
@@ -0,0 +1,30 @@
+#ifndef __HVMLOADER_CTYPE_H__
+#define __HVMLOADER_CTYPE_H__
+
+#define _U	0x01	/* upper */
+#define _L	0x02	/* lower */
+#define _D	0x04	/* digit */
+#define _C	0x08	/* cntrl */
+#define _P	0x10	/* punct */
+#define _S	0x20	/* white space (space/lf/tab) */
+#define _X	0x40	/* hex digit */
+#define _SP	0x80	/* hard space (0x20) */
+
+extern const unsigned char _ctype[];
+
+#define __ismask(x) (_ctype[(int)(unsigned char)(x)])
+
+#define isalnum(c)	((__ismask(c)&(_U|_L|_D)) != 0)
+#define isalpha(c)	((__ismask(c)&(_U|_L)) != 0)
+#define iscntrl(c)	((__ismask(c)&(_C)) != 0)
+#define isdigit(c)	((__ismask(c)&(_D)) != 0)
+#define isgraph(c)	((__ismask(c)&(_P|_U|_L|_D)) != 0)
+#define islower(c)	((__ismask(c)&(_L)) != 0)
+#define isprint(c)	((__ismask(c)&(_P|_U|_L|_D|_SP)) != 0)
+#define ispunct(c)	((__ismask(c)&(_P)) != 0)
+#define isspace(c)	((__ismask(c)&(_S)) != 0)
+#define isupper(c)	((__ismask(c)&(_U)) != 0)
+#define isxdigit(c)	((__ismask(c)&(_D|_X)) != 0)
+
+#endif /* __HVMLOADER_CTYPE_H__ */
+
diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
@@ -21,6 +21,7 @@
 #include "util.h"
 #include "config.h"
 #include "hypercall.h"
+#include "ctype.h"
 #include <stdint.h>
 #include <xen/xen.h>
 #include <xen/memory.h>
diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
@@ -225,8 +225,6 @@ void perform_tests(void);
 #define perform_tests() ((void)0)
 #endif
 
-#define isdigit(c) ((c) >= '0' && (c) <= '9')
-
 extern char _start[], _end[];
 
 #endif /* __HVMLOADER_UTIL_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:18:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:18:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09a-0005NP-48; Mon, 28 Nov 2011 12:17:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09W-0005MD-PN
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:42 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322482611!47370516!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2543 invoked from network); 28 Nov 2011 12:16:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="172010695"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:07 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:06 -0500
MIME-Version: 1.0
X-Mercurial-Node: 57100f663da56491619ac6f49eae17f9dd5a71e9
Message-ID: <57100f663da56491619a.1322482537@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322482532@cosworth.uk.xensource.com>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:37 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 5 of 5] Modify init_vm86_tss() to take advantage
 of the new set_param() function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322482489 0
# Node ID 57100f663da56491619ac6f49eae17f9dd5a71e9
# Parent  c4613164ee1c5f3bf2085008359ebb5b7924c660
Modify init_vm86_tss() to take advantage of the new set_param() function.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r c4613164ee1c -r 57100f663da5 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Mon Nov 28 12:14:49 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Mon Nov 28 12:14:49 2011 +0000
@@ -344,14 +344,11 @@ static void cmos_write_memory_size(void)
 static void init_vm86_tss(void)
 {
     void *tss;
-    struct xen_hvm_param p;
 
     tss = mem_alloc(128, 128);
     memset(tss, 0, 128);
-    p.domid = DOMID_SELF;
-    p.index = HVM_PARAM_VM86_TSS;
-    p.value = virt_to_phys(tss);
-    hypercall_hvm_op(HVMOP_set_param, &p);
+
+    set_param(HVM_PARAM_VM86_TSS, virt_to_phys(tss));
     printf("vm86 TSS at %08lx\n", virt_to_phys(tss));
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:18:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:18:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09a-0005NP-48; Mon, 28 Nov 2011 12:17:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09W-0005MD-PN
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:42 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322482611!47370516!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2543 invoked from network); 28 Nov 2011 12:16:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="172010695"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:07 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:06 -0500
MIME-Version: 1.0
X-Mercurial-Node: 57100f663da56491619ac6f49eae17f9dd5a71e9
Message-ID: <57100f663da56491619a.1322482537@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322482532@cosworth.uk.xensource.com>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:37 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 5 of 5] Modify init_vm86_tss() to take advantage
 of the new set_param() function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322482489 0
# Node ID 57100f663da56491619ac6f49eae17f9dd5a71e9
# Parent  c4613164ee1c5f3bf2085008359ebb5b7924c660
Modify init_vm86_tss() to take advantage of the new set_param() function.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r c4613164ee1c -r 57100f663da5 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c	Mon Nov 28 12:14:49 2011 +0000
+++ b/tools/firmware/hvmloader/hvmloader.c	Mon Nov 28 12:14:49 2011 +0000
@@ -344,14 +344,11 @@ static void cmos_write_memory_size(void)
 static void init_vm86_tss(void)
 {
     void *tss;
-    struct xen_hvm_param p;
 
     tss = mem_alloc(128, 128);
     memset(tss, 0, 128);
-    p.domid = DOMID_SELF;
-    p.index = HVM_PARAM_VM86_TSS;
-    p.value = virt_to_phys(tss);
-    hypercall_hvm_op(HVMOP_set_param, &p);
+
+    set_param(HVM_PARAM_VM86_TSS, virt_to_phys(tss));
     printf("vm86 TSS at %08lx\n", virt_to_phys(tss));
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:18:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09a-0005Na-Gq; Mon, 28 Nov 2011 12:17:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09X-0005M3-52
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:43 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322482589!54868599!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9398 invoked from network); 28 Nov 2011 12:16:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="19447525"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:06 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:06 -0500
MIME-Version: 1.0
X-Mercurial-Node: c4613164ee1c5f3bf2085008359ebb5b7924c660
Message-ID: <c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322482532@cosworth.uk.xensource.com>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:36 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 4 of 5] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322482489 0
# Node ID c4613164ee1c5f3bf2085008359ebb5b7924c660
# Parent  3886d406c13aa66b2af123d52a1bef8b6f41d144
Add code to track the address of the VM generation id buffer across a
save/restore or migrate and inject a new value.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 3886d406c13a -r c4613164ee1c tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 12:14:49 2011 +0000
@@ -23,6 +23,7 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include <xen/hvm/params.h>
 
 #define align16(sz)        (((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -308,6 +309,7 @@ unsigned long new_vm_gid(void)
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;
 
+    set_param(HVM_PARAM_VM_GENERATION_ID_ADDR, virt_to_phys(buf));
     return virt_to_phys(buf);    
 }
 
diff -r 3886d406c13a -r c4613164ee1c tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:49 2011 +0000
@@ -26,6 +26,7 @@
 #include <xen/xen.h>
 #include <xen/memory.h>
 #include <xen/sched.h>
+#include <xen/hvm/hvm_op.h>
 
 void wrmsr(uint32_t idx, uint64_t v)
 {
@@ -792,6 +793,17 @@ int hpet_exists(unsigned long hpet_base)
     return ((hpet_id >> 16) == 0x8086);
 }
 
+void set_param(int param, uint64_t value)
+{
+    struct xen_hvm_param p;
+
+    p.domid = DOMID_SELF;
+    p.index = param;
+    p.value = value;
+    if ( hypercall_hvm_op(HVMOP_set_param, &p) != 0 )
+        BUG();
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 3886d406c13a -r c4613164ee1c tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:49 2011 +0000
@@ -228,6 +228,8 @@ void perform_tests(void);
 
 extern char _start[], _end[];
 
+void set_param(int param, uint64_t value);
+
 #endif /* __HVMLOADER_UTIL_H__ */
 
 /*
diff -r 3886d406c13a -r c4613164ee1c tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Mon Nov 28 12:14:49 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  uint64_t gid)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r 3886d406c13a -r c4613164ee1c tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Mon Nov 28 12:14:49 2011 +0000
@@ -676,6 +676,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1386,6 +1399,34 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                unsigned int offset;
+                unsigned char *buf;
+
+                /*
+                 * Map the VM generation id buffer and inject the new value.
+                 */
+
+                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+            
+                if ( (pfn >= dinfo->p2m_size) ||
+                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                {
+                    ERROR("generation id buffer frame is bad");
+                    goto out;
+                }
+
+                mfn = ctx->p2m[pfn];
+                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                           PROT_READ | PROT_WRITE, mfn);
+                *(unsigned long long *)(buf + offset) = gid;
+                munmap(buf, PAGE_SIZE);
+
+                xc_set_hvm_param(xch, dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                                 pagebuf.vm_gid_addr);
+            }
+
             break;  /* our work here is done */
         }
 
diff -r 3886d406c13a -r c4613164ee1c tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Mon Nov 28 12:14:49 2011 +0000
@@ -1518,6 +1518,17 @@ int xc_domain_save(xc_interface *xch, in
             PERROR("Error when writing the viridian flag");
             goto out;
         }
+
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                         (unsigned long *)&chunk.data);
+
+        if ((chunk.data != 0) && wrexact(io_fd, &chunk, sizeof(chunk)))
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
     }
 
     if ( !callbacks->checkpoint )
diff -r 3886d406c13a -r c4613164ee1c tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxc/xenguest.h	Mon Nov 28 12:14:49 2011 +0000
@@ -71,12 +71,14 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r 3886d406c13a -r c4613164ee1c tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Mon Nov 28 12:14:49 2011 +0000
@@ -135,6 +135,7 @@
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 3886d406c13a -r c4613164ee1c tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Nov 28 12:14:49 2011 +0000
@@ -340,16 +340,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    uint64_t gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        gid = info->u.hvm.generation_id;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -357,7 +360,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, gid);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff -r 3886d406c13a -r c4613164ee1c tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Mon Nov 28 12:14:49 2011 +0000
@@ -24,6 +24,7 @@ main(int argc, char **argv)
     int io_fd, ret;
     int superpages;
     unsigned long store_mfn, console_mfn;
+    uint64_t gid;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
@@ -40,13 +41,18 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    gid = strtoll(argv[9], NULL, 0);
+    else
+	    gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            gid);
 
     if ( ret == 0 )
     {
diff -r 3886d406c13a -r c4613164ee1c xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/xen/include/public/hvm/params.h	Mon Nov 28 12:14:49 2011 +0000
@@ -142,6 +142,9 @@
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
 
-#define HVM_NR_PARAMS          27
+/* Address of VM generation id buffer */
+#define HVM_PARAM_VM_GENERATION_ID_ADDR 27
+
+#define HVM_NR_PARAMS          28
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:18:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09a-0005Na-Gq; Mon, 28 Nov 2011 12:17:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV09X-0005M3-52
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:43 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322482589!54868599!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9398 invoked from network); 28 Nov 2011 12:16:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315195200"; d="scan'208";a="19447525"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 07:17:06 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 07:17:06 -0500
MIME-Version: 1.0
X-Mercurial-Node: c4613164ee1c5f3bf2085008359ebb5b7924c660
Message-ID: <c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322482532@cosworth.uk.xensource.com>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 28 Nov 2011 12:15:36 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 4 of 5] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322482489 0
# Node ID c4613164ee1c5f3bf2085008359ebb5b7924c660
# Parent  3886d406c13aa66b2af123d52a1bef8b6f41d144
Add code to track the address of the VM generation id buffer across a
save/restore or migrate and inject a new value.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 3886d406c13a -r c4613164ee1c tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 12:14:49 2011 +0000
@@ -23,6 +23,7 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include <xen/hvm/params.h>
 
 #define align16(sz)        (((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -308,6 +309,7 @@ unsigned long new_vm_gid(void)
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;
 
+    set_param(HVM_PARAM_VM_GENERATION_ID_ADDR, virt_to_phys(buf));
     return virt_to_phys(buf);    
 }
 
diff -r 3886d406c13a -r c4613164ee1c tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:49 2011 +0000
@@ -26,6 +26,7 @@
 #include <xen/xen.h>
 #include <xen/memory.h>
 #include <xen/sched.h>
+#include <xen/hvm/hvm_op.h>
 
 void wrmsr(uint32_t idx, uint64_t v)
 {
@@ -792,6 +793,17 @@ int hpet_exists(unsigned long hpet_base)
     return ((hpet_id >> 16) == 0x8086);
 }
 
+void set_param(int param, uint64_t value)
+{
+    struct xen_hvm_param p;
+
+    p.domid = DOMID_SELF;
+    p.index = param;
+    p.value = value;
+    if ( hypercall_hvm_op(HVMOP_set_param, &p) != 0 )
+        BUG();
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 3886d406c13a -r c4613164ee1c tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:49 2011 +0000
@@ -228,6 +228,8 @@ void perform_tests(void);
 
 extern char _start[], _end[];
 
+void set_param(int param, uint64_t value);
+
 #endif /* __HVMLOADER_UTIL_H__ */
 
 /*
diff -r 3886d406c13a -r c4613164ee1c tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Mon Nov 28 12:14:49 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  uint64_t gid)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r 3886d406c13a -r c4613164ee1c tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Mon Nov 28 12:14:49 2011 +0000
@@ -676,6 +676,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1386,6 +1399,34 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                unsigned int offset;
+                unsigned char *buf;
+
+                /*
+                 * Map the VM generation id buffer and inject the new value.
+                 */
+
+                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+            
+                if ( (pfn >= dinfo->p2m_size) ||
+                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                {
+                    ERROR("generation id buffer frame is bad");
+                    goto out;
+                }
+
+                mfn = ctx->p2m[pfn];
+                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                           PROT_READ | PROT_WRITE, mfn);
+                *(unsigned long long *)(buf + offset) = gid;
+                munmap(buf, PAGE_SIZE);
+
+                xc_set_hvm_param(xch, dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                                 pagebuf.vm_gid_addr);
+            }
+
             break;  /* our work here is done */
         }
 
diff -r 3886d406c13a -r c4613164ee1c tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Mon Nov 28 12:14:49 2011 +0000
@@ -1518,6 +1518,17 @@ int xc_domain_save(xc_interface *xch, in
             PERROR("Error when writing the viridian flag");
             goto out;
         }
+
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = 0;
+        xc_get_hvm_param(xch, dom, HVM_PARAM_VM_GENERATION_ID_ADDR,
+                         (unsigned long *)&chunk.data);
+
+        if ((chunk.data != 0) && wrexact(io_fd, &chunk, sizeof(chunk)))
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
     }
 
     if ( !callbacks->checkpoint )
diff -r 3886d406c13a -r c4613164ee1c tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxc/xenguest.h	Mon Nov 28 12:14:49 2011 +0000
@@ -71,12 +71,14 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r 3886d406c13a -r c4613164ee1c tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Mon Nov 28 12:14:49 2011 +0000
@@ -135,6 +135,7 @@
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 3886d406c13a -r c4613164ee1c tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Nov 28 12:14:49 2011 +0000
@@ -340,16 +340,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    uint64_t gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        gid = info->u.hvm.generation_id;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -357,7 +360,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, gid);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff -r 3886d406c13a -r c4613164ee1c tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Mon Nov 28 12:14:48 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Mon Nov 28 12:14:49 2011 +0000
@@ -24,6 +24,7 @@ main(int argc, char **argv)
     int io_fd, ret;
     int superpages;
     unsigned long store_mfn, console_mfn;
+    uint64_t gid;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
@@ -40,13 +41,18 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    gid = strtoll(argv[9], NULL, 0);
+    else
+	    gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            gid);
 
     if ( ret == 0 )
     {
diff -r 3886d406c13a -r c4613164ee1c xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Mon Nov 28 12:14:48 2011 +0000
+++ b/xen/include/public/hvm/params.h	Mon Nov 28 12:14:49 2011 +0000
@@ -142,6 +142,9 @@
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
 
-#define HVM_NR_PARAMS          27
+/* Address of VM generation id buffer */
+#define HVM_PARAM_VM_GENERATION_ID_ADDR 27
+
+#define HVM_NR_PARAMS          28
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:18:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:18:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09m-0005Rs-0R; Mon, 28 Nov 2011 12:17:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RV09k-0005Ov-FM
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:56 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322482640!6095110!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24775 invoked from network); 28 Nov 2011 12:17:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:17:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9160544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 12:17:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 12:17:12 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RV092-0003c7-MX;
	Mon, 28 Nov 2011 12:17:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RV08n-0004tB-Nj;
	Mon, 28 Nov 2011 12:16:57 +0000
Date: Mon, 28 Nov 2011 12:16:57 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111128121657.GF32513@spongy.cam.xci-test.com>
References: <4EA698C8.8030603@amd.com> <CACC6B9F.23926%keir.xen@gmail.com>
	<CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
	<4ECD30330200007800062C2E@nat28.tlf.novell.com>
	<20111128115914.GD32513@spongy.cam.xci-test.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111128115914.GD32513@spongy.cam.xci-test.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Christoph Egger <Christoph.Egger@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 28/11 11:59, Jean Guyader wrote:
> On 23/11 04:41, Jan Beulich wrote:
> > >>> On 23.11.11 at 17:31, Jean Guyader <jean.guyader@gmail.com> wrote:
> > > On 25 October 2011 13:35, Keir Fraser <keir.xen@gmail.com> wrote:
> > >> On 25/10/2011 12:08, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
> > >>
> > >>>
> > >>> Hi,
> > >>>
> > >>> Compiling the xen kernel fails with:
> > >>>
> > >>> xen/arch/x86/domain.c: In function 'alloc_domain_struct'
> > >>> xen/arch/x86/domain.c:191: error: negative width in bit-field '<anonymous>'
> > >>
> > >> Problem is that struct domain has grown bigger than a page for some reason,
> > >> in your build environment.
> > >>
> > >> I can't reproduce this.
> > >>
> > >>> Removing the line
> > >>>
> > >>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> > >>>
> > >>> makes xen kernel compile again.
> > >>
> > >> But not actually work properly. We only allocate a single page for the
> > >> domain struct. If the struct is bigger than a page, you'll get memory
> > >> corruption at run time.
> > >>
> > > 
> > > Is there a reason for that?
> > 
> > Of course there is: Post-boot there shouldn't be any allocations of
> > order greater than zero. This is a generally advisable thing, given that
> > Xen can't reclaim memory arbitrarily from domains, and in particular
> > also necessary for tmem.
> > 
> > > What would be the recommended to add something
> > > into the struct domain now if we can't make it bigger than a page.
> > 
> > Put a pointer to your data (or larger parts that are already there)
> > instead of the data itself into struct domain, and allocate it
> > separately. (You may have seen a patch from Olaf Hering late
> > yesterday or earlier today that moved the mem_event pieces out
> > of there for this very reason.)
> > 
> > 
> 
> I've printed sizeof (struct domain) on boot with xen-unstable and it's
> exactly a PAGE big. That mean that if I want a add a value to the struct
> domain (event a pointer) I will have to make some room first.
> 

I can see two candidates, that could be turned into pointers in arch_domain
for x86:

    /* nestedhvm: translate l2 guest physical to host physical */
    struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
    mm_lock_t nested_p2m_lock;
or
    struct PITState vpit;

Let me know which one I should pick. Maybe I should modify both to save
some space for later.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:18:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:18:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV09m-0005Rs-0R; Mon, 28 Nov 2011 12:17:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RV09k-0005Ov-FM
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:17:56 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322482640!6095110!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24775 invoked from network); 28 Nov 2011 12:17:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:17:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9160544"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 12:17:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 12:17:12 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RV092-0003c7-MX;
	Mon, 28 Nov 2011 12:17:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RV08n-0004tB-Nj;
	Mon, 28 Nov 2011 12:16:57 +0000
Date: Mon, 28 Nov 2011 12:16:57 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111128121657.GF32513@spongy.cam.xci-test.com>
References: <4EA698C8.8030603@amd.com> <CACC6B9F.23926%keir.xen@gmail.com>
	<CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
	<4ECD30330200007800062C2E@nat28.tlf.novell.com>
	<20111128115914.GD32513@spongy.cam.xci-test.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111128115914.GD32513@spongy.cam.xci-test.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Christoph Egger <Christoph.Egger@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 28/11 11:59, Jean Guyader wrote:
> On 23/11 04:41, Jan Beulich wrote:
> > >>> On 23.11.11 at 17:31, Jean Guyader <jean.guyader@gmail.com> wrote:
> > > On 25 October 2011 13:35, Keir Fraser <keir.xen@gmail.com> wrote:
> > >> On 25/10/2011 12:08, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
> > >>
> > >>>
> > >>> Hi,
> > >>>
> > >>> Compiling the xen kernel fails with:
> > >>>
> > >>> xen/arch/x86/domain.c: In function 'alloc_domain_struct'
> > >>> xen/arch/x86/domain.c:191: error: negative width in bit-field '<anonymous>'
> > >>
> > >> Problem is that struct domain has grown bigger than a page for some reason,
> > >> in your build environment.
> > >>
> > >> I can't reproduce this.
> > >>
> > >>> Removing the line
> > >>>
> > >>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
> > >>>
> > >>> makes xen kernel compile again.
> > >>
> > >> But not actually work properly. We only allocate a single page for the
> > >> domain struct. If the struct is bigger than a page, you'll get memory
> > >> corruption at run time.
> > >>
> > > 
> > > Is there a reason for that?
> > 
> > Of course there is: Post-boot there shouldn't be any allocations of
> > order greater than zero. This is a generally advisable thing, given that
> > Xen can't reclaim memory arbitrarily from domains, and in particular
> > also necessary for tmem.
> > 
> > > What would be the recommended to add something
> > > into the struct domain now if we can't make it bigger than a page.
> > 
> > Put a pointer to your data (or larger parts that are already there)
> > instead of the data itself into struct domain, and allocate it
> > separately. (You may have seen a patch from Olaf Hering late
> > yesterday or earlier today that moved the mem_event pieces out
> > of there for this very reason.)
> > 
> > 
> 
> I've printed sizeof (struct domain) on boot with xen-unstable and it's
> exactly a PAGE big. That mean that if I want a add a value to the struct
> domain (event a pointer) I will have to make some room first.
> 

I can see two candidates, that could be turned into pointers in arch_domain
for x86:

    /* nestedhvm: translate l2 guest physical to host physical */
    struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
    mm_lock_t nested_p2m_lock;
or
    struct PITState vpit;

Let me know which one I should pick. Maybe I should modify both to save
some space for later.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:28:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:28:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0K8-0006UL-Dx; Mon, 28 Nov 2011 12:28:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV0K6-0006UG-Jf
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:28:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322483282!3387746!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18598 invoked from network); 28 Nov 2011 12:28:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:28:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9160813"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 12:28:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 12:28:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV0JV-0003fm-9W	for xen-devel@lists.xensource.com;
	Mon, 28 Nov 2011 12:28:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV0JV-0002iH-8e	for
	xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:28:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.32337.102834.867932@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 12:28:01 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH 1/2] libxl: open logs with O_APPEND
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Logfiles should always be opened for append.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r a9c67c2daf4b tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Nov 28 12:25:52 2011 +0000
@@ -830,7 +830,7 @@ int libxl__create_device_model(libxl__gc
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
 
     libxl_create_logfile(ctx, libxl__sprintf(gc, "qemu-dm-%s", info->dom_name), &logfile);
-    logfile_w = open(logfile, O_WRONLY|O_CREAT, 0644);
+    logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
     free(logfile);
     null = open("/dev/null", O_RDONLY);
 
diff -r a9c67c2daf4b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 12:25:52 2011 +0000
@@ -1597,7 +1597,8 @@ start:
             exit(-1);
         }
 
-        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT, 0644) )<0);
+        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT|O_APPEND,
+                                   0644) )<0);
         free(fullname);
         free(name);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:28:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:28:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0K8-0006UL-Dx; Mon, 28 Nov 2011 12:28:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV0K6-0006UG-Jf
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:28:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322483282!3387746!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18598 invoked from network); 28 Nov 2011 12:28:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:28:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9160813"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 12:28:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 12:28:01 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV0JV-0003fm-9W	for xen-devel@lists.xensource.com;
	Mon, 28 Nov 2011 12:28:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV0JV-0002iH-8e	for
	xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:28:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.32337.102834.867932@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 12:28:01 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH 1/2] libxl: open logs with O_APPEND
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Logfiles should always be opened for append.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r a9c67c2daf4b tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Nov 28 12:25:52 2011 +0000
@@ -830,7 +830,7 @@ int libxl__create_device_model(libxl__gc
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
 
     libxl_create_logfile(ctx, libxl__sprintf(gc, "qemu-dm-%s", info->dom_name), &logfile);
-    logfile_w = open(logfile, O_WRONLY|O_CREAT, 0644);
+    logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
     free(logfile);
     null = open("/dev/null", O_RDONLY);
 
diff -r a9c67c2daf4b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 12:25:52 2011 +0000
@@ -1597,7 +1597,8 @@ start:
             exit(-1);
         }
 
-        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT, 0644) )<0);
+        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT|O_APPEND,
+                                   0644) )<0);
         free(fullname);
         free(name);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:29:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:29:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0KN-0006V6-Qa; Mon, 28 Nov 2011 12:28:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RV0KM-0006Ul-Iq
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:28:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322483298!5292501!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5286 invoked from network); 28 Nov 2011 12:28:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 12:28:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RV0Jl-000LCx-37; Mon, 28 Nov 2011 12:28:17 +0000
Date: Mon, 28 Nov 2011 12:28:17 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20111128122817.GA79829@ocelot.phlegethon.org>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<b383a1053d1d5e598bb3.1322482534@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b383a1053d1d5e598bb3.1322482534@cosworth.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] Add 'ctype' infrastructure to
	hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:15 +0000 on 28 Nov (1322482534), Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322482488 0
> # Node ID b383a1053d1d5e598bb39923eee8cec57e5666e9
> # Parent  346b54217c4c3fcdebfde41d636d0ec1c11a7672
> Add 'ctype' infrastructure to hvmloader.

Where did this ctype code come from?  Is it appropriately licensed?

Cheers,

Tim

> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/Makefile
> --- a/tools/firmware/hvmloader/Makefile	Mon Nov 28 12:14:48 2011 +0000
> +++ b/tools/firmware/hvmloader/Makefile	Mon Nov 28 12:14:48 2011 +0000
> @@ -30,7 +30,7 @@ CFLAGS += $(CFLAGS_xeninclude)
>  
>  OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
>  OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
> -OBJS += e820.o pci.o pir.o
> +OBJS += e820.o pci.o pir.o ctype.o
>  ifeq ($(debug),y)
>  OBJS += tests.o
>  endif
> diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/ctype.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/hvmloader/ctype.c	Mon Nov 28 12:14:48 2011 +0000
> @@ -0,0 +1,27 @@
> +#include "ctype.h"
> +
> +const unsigned char _ctype[] = {
> +_C,_C,_C,_C,_C,_C,_C,_C,                        /* 0-7 */
> +_C,_C|_S,_C|_S,_C|_S,_C|_S,_C|_S,_C,_C,         /* 8-15 */
> +_C,_C,_C,_C,_C,_C,_C,_C,                        /* 16-23 */
> +_C,_C,_C,_C,_C,_C,_C,_C,                        /* 24-31 */
> +_S|_SP,_P,_P,_P,_P,_P,_P,_P,                    /* 32-39 */
> +_P,_P,_P,_P,_P,_P,_P,_P,                        /* 40-47 */
> +_D,_D,_D,_D,_D,_D,_D,_D,                        /* 48-55 */
> +_D,_D,_P,_P,_P,_P,_P,_P,                        /* 56-63 */
> +_P,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U,      /* 64-71 */
> +_U,_U,_U,_U,_U,_U,_U,_U,                        /* 72-79 */
> +_U,_U,_U,_U,_U,_U,_U,_U,                        /* 80-87 */
> +_U,_U,_U,_P,_P,_P,_P,_P,                        /* 88-95 */
> +_P,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L,      /* 96-103 */
> +_L,_L,_L,_L,_L,_L,_L,_L,                        /* 104-111 */
> +_L,_L,_L,_L,_L,_L,_L,_L,                        /* 112-119 */
> +_L,_L,_L,_P,_P,_P,_P,_C,                        /* 120-127 */
> +0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 128-143 */
> +0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 144-159 */
> +_S|_SP,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,   /* 160-175 */
> +_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,       /* 176-191 */
> +_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,       /* 192-207 */
> +_U,_U,_U,_U,_U,_U,_U,_P,_U,_U,_U,_U,_U,_U,_U,_L,       /* 208-223 */
> +_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,       /* 224-239 */
> +_L,_L,_L,_L,_L,_L,_L,_P,_L,_L,_L,_L,_L,_L,_L,_L};      /* 240-255 */
> diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/ctype.h
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/hvmloader/ctype.h	Mon Nov 28 12:14:48 2011 +0000
> @@ -0,0 +1,30 @@
> +#ifndef __HVMLOADER_CTYPE_H__
> +#define __HVMLOADER_CTYPE_H__
> +
> +#define _U	0x01	/* upper */
> +#define _L	0x02	/* lower */
> +#define _D	0x04	/* digit */
> +#define _C	0x08	/* cntrl */
> +#define _P	0x10	/* punct */
> +#define _S	0x20	/* white space (space/lf/tab) */
> +#define _X	0x40	/* hex digit */
> +#define _SP	0x80	/* hard space (0x20) */
> +
> +extern const unsigned char _ctype[];
> +
> +#define __ismask(x) (_ctype[(int)(unsigned char)(x)])
> +
> +#define isalnum(c)	((__ismask(c)&(_U|_L|_D)) != 0)
> +#define isalpha(c)	((__ismask(c)&(_U|_L)) != 0)
> +#define iscntrl(c)	((__ismask(c)&(_C)) != 0)
> +#define isdigit(c)	((__ismask(c)&(_D)) != 0)
> +#define isgraph(c)	((__ismask(c)&(_P|_U|_L|_D)) != 0)
> +#define islower(c)	((__ismask(c)&(_L)) != 0)
> +#define isprint(c)	((__ismask(c)&(_P|_U|_L|_D|_SP)) != 0)
> +#define ispunct(c)	((__ismask(c)&(_P)) != 0)
> +#define isspace(c)	((__ismask(c)&(_S)) != 0)
> +#define isupper(c)	((__ismask(c)&(_U)) != 0)
> +#define isxdigit(c)	((__ismask(c)&(_D|_X)) != 0)
> +
> +#endif /* __HVMLOADER_CTYPE_H__ */
> +
> diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/util.c
> --- a/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
> +++ b/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
> @@ -21,6 +21,7 @@
>  #include "util.h"
>  #include "config.h"
>  #include "hypercall.h"
> +#include "ctype.h"
>  #include <stdint.h>
>  #include <xen/xen.h>
>  #include <xen/memory.h>
> diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/util.h
> --- a/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
> +++ b/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
> @@ -225,8 +225,6 @@ void perform_tests(void);
>  #define perform_tests() ((void)0)
>  #endif
>  
> -#define isdigit(c) ((c) >= '0' && (c) <= '9')
> -
>  extern char _start[], _end[];
>  
>  #endif /* __HVMLOADER_UTIL_H__ */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:29:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:29:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0KN-0006V6-Qa; Mon, 28 Nov 2011 12:28:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RV0KM-0006Ul-Iq
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:28:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322483298!5292501!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5286 invoked from network); 28 Nov 2011 12:28:18 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 12:28:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RV0Jl-000LCx-37; Mon, 28 Nov 2011 12:28:17 +0000
Date: Mon, 28 Nov 2011 12:28:17 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20111128122817.GA79829@ocelot.phlegethon.org>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<b383a1053d1d5e598bb3.1322482534@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <b383a1053d1d5e598bb3.1322482534@cosworth.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 5] Add 'ctype' infrastructure to
	hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:15 +0000 on 28 Nov (1322482534), Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322482488 0
> # Node ID b383a1053d1d5e598bb39923eee8cec57e5666e9
> # Parent  346b54217c4c3fcdebfde41d636d0ec1c11a7672
> Add 'ctype' infrastructure to hvmloader.

Where did this ctype code come from?  Is it appropriately licensed?

Cheers,

Tim

> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/Makefile
> --- a/tools/firmware/hvmloader/Makefile	Mon Nov 28 12:14:48 2011 +0000
> +++ b/tools/firmware/hvmloader/Makefile	Mon Nov 28 12:14:48 2011 +0000
> @@ -30,7 +30,7 @@ CFLAGS += $(CFLAGS_xeninclude)
>  
>  OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
>  OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
> -OBJS += e820.o pci.o pir.o
> +OBJS += e820.o pci.o pir.o ctype.o
>  ifeq ($(debug),y)
>  OBJS += tests.o
>  endif
> diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/ctype.c
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/hvmloader/ctype.c	Mon Nov 28 12:14:48 2011 +0000
> @@ -0,0 +1,27 @@
> +#include "ctype.h"
> +
> +const unsigned char _ctype[] = {
> +_C,_C,_C,_C,_C,_C,_C,_C,                        /* 0-7 */
> +_C,_C|_S,_C|_S,_C|_S,_C|_S,_C|_S,_C,_C,         /* 8-15 */
> +_C,_C,_C,_C,_C,_C,_C,_C,                        /* 16-23 */
> +_C,_C,_C,_C,_C,_C,_C,_C,                        /* 24-31 */
> +_S|_SP,_P,_P,_P,_P,_P,_P,_P,                    /* 32-39 */
> +_P,_P,_P,_P,_P,_P,_P,_P,                        /* 40-47 */
> +_D,_D,_D,_D,_D,_D,_D,_D,                        /* 48-55 */
> +_D,_D,_P,_P,_P,_P,_P,_P,                        /* 56-63 */
> +_P,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U,      /* 64-71 */
> +_U,_U,_U,_U,_U,_U,_U,_U,                        /* 72-79 */
> +_U,_U,_U,_U,_U,_U,_U,_U,                        /* 80-87 */
> +_U,_U,_U,_P,_P,_P,_P,_P,                        /* 88-95 */
> +_P,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L,      /* 96-103 */
> +_L,_L,_L,_L,_L,_L,_L,_L,                        /* 104-111 */
> +_L,_L,_L,_L,_L,_L,_L,_L,                        /* 112-119 */
> +_L,_L,_L,_P,_P,_P,_P,_C,                        /* 120-127 */
> +0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 128-143 */
> +0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 144-159 */
> +_S|_SP,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,   /* 160-175 */
> +_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,       /* 176-191 */
> +_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,       /* 192-207 */
> +_U,_U,_U,_U,_U,_U,_U,_P,_U,_U,_U,_U,_U,_U,_U,_L,       /* 208-223 */
> +_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,       /* 224-239 */
> +_L,_L,_L,_L,_L,_L,_L,_P,_L,_L,_L,_L,_L,_L,_L,_L};      /* 240-255 */
> diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/ctype.h
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/firmware/hvmloader/ctype.h	Mon Nov 28 12:14:48 2011 +0000
> @@ -0,0 +1,30 @@
> +#ifndef __HVMLOADER_CTYPE_H__
> +#define __HVMLOADER_CTYPE_H__
> +
> +#define _U	0x01	/* upper */
> +#define _L	0x02	/* lower */
> +#define _D	0x04	/* digit */
> +#define _C	0x08	/* cntrl */
> +#define _P	0x10	/* punct */
> +#define _S	0x20	/* white space (space/lf/tab) */
> +#define _X	0x40	/* hex digit */
> +#define _SP	0x80	/* hard space (0x20) */
> +
> +extern const unsigned char _ctype[];
> +
> +#define __ismask(x) (_ctype[(int)(unsigned char)(x)])
> +
> +#define isalnum(c)	((__ismask(c)&(_U|_L|_D)) != 0)
> +#define isalpha(c)	((__ismask(c)&(_U|_L)) != 0)
> +#define iscntrl(c)	((__ismask(c)&(_C)) != 0)
> +#define isdigit(c)	((__ismask(c)&(_D)) != 0)
> +#define isgraph(c)	((__ismask(c)&(_P|_U|_L|_D)) != 0)
> +#define islower(c)	((__ismask(c)&(_L)) != 0)
> +#define isprint(c)	((__ismask(c)&(_P|_U|_L|_D|_SP)) != 0)
> +#define ispunct(c)	((__ismask(c)&(_P)) != 0)
> +#define isspace(c)	((__ismask(c)&(_S)) != 0)
> +#define isupper(c)	((__ismask(c)&(_U)) != 0)
> +#define isxdigit(c)	((__ismask(c)&(_D|_X)) != 0)
> +
> +#endif /* __HVMLOADER_CTYPE_H__ */
> +
> diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/util.c
> --- a/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
> +++ b/tools/firmware/hvmloader/util.c	Mon Nov 28 12:14:48 2011 +0000
> @@ -21,6 +21,7 @@
>  #include "util.h"
>  #include "config.h"
>  #include "hypercall.h"
> +#include "ctype.h"
>  #include <stdint.h>
>  #include <xen/xen.h>
>  #include <xen/memory.h>
> diff -r 346b54217c4c -r b383a1053d1d tools/firmware/hvmloader/util.h
> --- a/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
> +++ b/tools/firmware/hvmloader/util.h	Mon Nov 28 12:14:48 2011 +0000
> @@ -225,8 +225,6 @@ void perform_tests(void);
>  #define perform_tests() ((void)0)
>  #endif
>  
> -#define isdigit(c) ((c) >= '0' && (c) <= '9')
> -
>  extern char _start[], _end[];
>  
>  #endif /* __HVMLOADER_UTIL_H__ */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:30:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0M5-0006fm-KE; Mon, 28 Nov 2011 12:30:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV0M3-0006f4-L4
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:30:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322483403!5920636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18701 invoked from network); 28 Nov 2011 12:30:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:30:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9160868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 12:30:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 12:30:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV0LS-0003gb-FN	for xen-devel@lists.xensource.com;
	Mon, 28 Nov 2011 12:30:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV0LS-0002ig-EU	for
	xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:30:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.32458.436431.927443@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 12:30:02 +0000
To: xen-devel@lists.xensource.com
In-Reply-To: <20179.32337.102834.867932@mariner.uk.xensource.com>
References: <20179.32337.102834.867932@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] [PATCH 2/2] qemu-dm: open char devices "file:..." with
	O_APPEND
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The "file:..." character open method is used by serial and parallel
ports, to divert the output to a file (and these devices never produce
any input).  This is like a logfile, and so should be opened for
append.

In qemu-xen-unstable, this is used only for the qemu stderr by libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/qemu-char.c b/qemu-char.c
index 35e428d..324ed16 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -588,7 +588,7 @@ static CharDriverState *qemu_chr_open_file_out(const char *file_out)
 {
     int fd_out;
 
-    TFR(fd_out = open(file_out, O_WRONLY | O_TRUNC | O_CREAT | O_BINARY, 0666));
+    TFR(fd_out = open(file_out, O_WRONLY | O_TRUNC | O_CREAT | O_BINARY | O_APPEND, 0666));
     if (fd_out < 0)
         return NULL;
     return qemu_chr_open_fd(-1, fd_out);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:30:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:30:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0M5-0006fm-KE; Mon, 28 Nov 2011 12:30:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV0M3-0006f4-L4
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:30:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322483403!5920636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18701 invoked from network); 28 Nov 2011 12:30:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:30:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,583,1315180800"; 
   d="scan'208";a="9160868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 12:30:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 12:30:02 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV0LS-0003gb-FN	for xen-devel@lists.xensource.com;
	Mon, 28 Nov 2011 12:30:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV0LS-0002ig-EU	for
	xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:30:02 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.32458.436431.927443@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 12:30:02 +0000
To: xen-devel@lists.xensource.com
In-Reply-To: <20179.32337.102834.867932@mariner.uk.xensource.com>
References: <20179.32337.102834.867932@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] [PATCH 2/2] qemu-dm: open char devices "file:..." with
	O_APPEND
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The "file:..." character open method is used by serial and parallel
ports, to divert the output to a file (and these devices never produce
any input).  This is like a logfile, and so should be opened for
append.

In qemu-xen-unstable, this is used only for the qemu stderr by libxl.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/qemu-char.c b/qemu-char.c
index 35e428d..324ed16 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -588,7 +588,7 @@ static CharDriverState *qemu_chr_open_file_out(const char *file_out)
 {
     int fd_out;
 
-    TFR(fd_out = open(file_out, O_WRONLY | O_TRUNC | O_CREAT | O_BINARY, 0666));
+    TFR(fd_out = open(file_out, O_WRONLY | O_TRUNC | O_CREAT | O_BINARY | O_APPEND, 0666));
     if (fd_out < 0)
         return NULL;
     return qemu_chr_open_fd(-1, fd_out);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:32:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0Nl-0006qe-6X; Mon, 28 Nov 2011 12:32:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RV0Nj-0006q4-4W
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:32:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322483506!4978455!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMjA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8923 invoked from network); 28 Nov 2011 12:31:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 12:31:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 28 Nov 2011 12:31:46 +0000
Message-Id: <4ED38D400200007800063A35@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 28 Nov 2011 12:31:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@eu.citrix.com>
References: <4EA698C8.8030603@amd.com> <CACC6B9F.23926%keir.xen@gmail.com>
	<CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
	<4ECD30330200007800062C2E@nat28.tlf.novell.com>
	<20111128115914.GD32513@spongy.cam.xci-test.com>
	<20111128121657.GF32513@spongy.cam.xci-test.com>
In-Reply-To: <20111128121657.GF32513@spongy.cam.xci-test.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger <Christoph.Egger@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 28.11.11 at 13:16, Jean Guyader <jean.guyader@eu.citrix.com> wrote:
> On 28/11 11:59, Jean Guyader wrote:
>> On 23/11 04:41, Jan Beulich wrote:
>> > >>> On 23.11.11 at 17:31, Jean Guyader <jean.guyader@gmail.com> wrote:
>> > > On 25 October 2011 13:35, Keir Fraser <keir.xen@gmail.com> wrote:
>> > >> On 25/10/2011 12:08, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
>> > >>
>> > >>>
>> > >>> Hi,
>> > >>>
>> > >>> Compiling the xen kernel fails with:
>> > >>>
>> > >>> xen/arch/x86/domain.c: In function 'alloc_domain_struct'
>> > >>> xen/arch/x86/domain.c:191: error: negative width in bit-field '<anonymous>'
>> > >>
>> > >> Problem is that struct domain has grown bigger than a page for some 
> reason,
>> > >> in your build environment.
>> > >>
>> > >> I can't reproduce this.
>> > >>
>> > >>> Removing the line
>> > >>>
>> > >>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>> > >>>
>> > >>> makes xen kernel compile again.
>> > >>
>> > >> But not actually work properly. We only allocate a single page for the
>> > >> domain struct. If the struct is bigger than a page, you'll get memory
>> > >> corruption at run time.
>> > >>
>> > > 
>> > > Is there a reason for that?
>> > 
>> > Of course there is: Post-boot there shouldn't be any allocations of
>> > order greater than zero. This is a generally advisable thing, given that
>> > Xen can't reclaim memory arbitrarily from domains, and in particular
>> > also necessary for tmem.
>> > 
>> > > What would be the recommended to add something
>> > > into the struct domain now if we can't make it bigger than a page.
>> > 
>> > Put a pointer to your data (or larger parts that are already there)
>> > instead of the data itself into struct domain, and allocate it
>> > separately. (You may have seen a patch from Olaf Hering late
>> > yesterday or earlier today that moved the mem_event pieces out
>> > of there for this very reason.)
>> > 
>> > 
>> 
>> I've printed sizeof (struct domain) on boot with xen-unstable and it's
>> exactly a PAGE big. That mean that if I want a add a value to the struct
>> domain (event a pointer) I will have to make some room first.
>> 
> 
> I can see two candidates, that could be turned into pointers in arch_domain
> for x86:
> 
>     /* nestedhvm: translate l2 guest physical to host physical */
>     struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
>     mm_lock_t nested_p2m_lock;
> or
>     struct PITState vpit;
> 
> Let me know which one I should pick. Maybe I should modify both to save
> some space for later.

As written earlier, I think you should leverage Olaf Hering's patch to
split out the three "struct mem_event_domain" instances. Other
candidates would be the watchdog related items or the evtchn array
(the latter would need to be converted to a simple pointer anyway
at some point in order to support more than 4096 event channels
per domain).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:32:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:32:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0Nl-0006qe-6X; Mon, 28 Nov 2011 12:32:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RV0Nj-0006q4-4W
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:32:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322483506!4978455!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMjA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8923 invoked from network); 28 Nov 2011 12:31:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 12:31:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 28 Nov 2011 12:31:46 +0000
Message-Id: <4ED38D400200007800063A35@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 28 Nov 2011 12:31:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@eu.citrix.com>
References: <4EA698C8.8030603@amd.com> <CACC6B9F.23926%keir.xen@gmail.com>
	<CAEBdQ92Dx_mLWU5qsQ8gNgLQ+bvr2ec+Y1Fr-i06=ExBa0B4Tg@mail.gmail.com>
	<4ECD30330200007800062C2E@nat28.tlf.novell.com>
	<20111128115914.GD32513@spongy.cam.xci-test.com>
	<20111128121657.GF32513@spongy.cam.xci-test.com>
In-Reply-To: <20111128121657.GF32513@spongy.cam.xci-test.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger <Christoph.Egger@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] xen kernel: build failure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 28.11.11 at 13:16, Jean Guyader <jean.guyader@eu.citrix.com> wrote:
> On 28/11 11:59, Jean Guyader wrote:
>> On 23/11 04:41, Jan Beulich wrote:
>> > >>> On 23.11.11 at 17:31, Jean Guyader <jean.guyader@gmail.com> wrote:
>> > > On 25 October 2011 13:35, Keir Fraser <keir.xen@gmail.com> wrote:
>> > >> On 25/10/2011 12:08, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
>> > >>
>> > >>>
>> > >>> Hi,
>> > >>>
>> > >>> Compiling the xen kernel fails with:
>> > >>>
>> > >>> xen/arch/x86/domain.c: In function 'alloc_domain_struct'
>> > >>> xen/arch/x86/domain.c:191: error: negative width in bit-field '<anonymous>'
>> > >>
>> > >> Problem is that struct domain has grown bigger than a page for some 
> reason,
>> > >> in your build environment.
>> > >>
>> > >> I can't reproduce this.
>> > >>
>> > >>> Removing the line
>> > >>>
>> > >>> BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
>> > >>>
>> > >>> makes xen kernel compile again.
>> > >>
>> > >> But not actually work properly. We only allocate a single page for the
>> > >> domain struct. If the struct is bigger than a page, you'll get memory
>> > >> corruption at run time.
>> > >>
>> > > 
>> > > Is there a reason for that?
>> > 
>> > Of course there is: Post-boot there shouldn't be any allocations of
>> > order greater than zero. This is a generally advisable thing, given that
>> > Xen can't reclaim memory arbitrarily from domains, and in particular
>> > also necessary for tmem.
>> > 
>> > > What would be the recommended to add something
>> > > into the struct domain now if we can't make it bigger than a page.
>> > 
>> > Put a pointer to your data (or larger parts that are already there)
>> > instead of the data itself into struct domain, and allocate it
>> > separately. (You may have seen a patch from Olaf Hering late
>> > yesterday or earlier today that moved the mem_event pieces out
>> > of there for this very reason.)
>> > 
>> > 
>> 
>> I've printed sizeof (struct domain) on boot with xen-unstable and it's
>> exactly a PAGE big. That mean that if I want a add a value to the struct
>> domain (event a pointer) I will have to make some room first.
>> 
> 
> I can see two candidates, that could be turned into pointers in arch_domain
> for x86:
> 
>     /* nestedhvm: translate l2 guest physical to host physical */
>     struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
>     mm_lock_t nested_p2m_lock;
> or
>     struct PITState vpit;
> 
> Let me know which one I should pick. Maybe I should modify both to save
> some space for later.

As written earlier, I think you should leverage Olaf Hering's patch to
split out the three "struct mem_event_domain" instances. Other
candidates would be the watchdog related items or the evtchn array
(the latter would need to be converted to a simple pointer anyway
at some point in order to support more than 4096 event channels
per domain).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:33:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0Oc-0006xC-Li; Mon, 28 Nov 2011 12:33:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RV0Ob-0006wx-RW
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:33:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322483446!46121598!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4556 invoked from network); 28 Nov 2011 12:30:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 12:30:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RV0O6-000LDj-DA; Mon, 28 Nov 2011 12:32:46 +0000
Date: Mon, 28 Nov 2011 12:32:46 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20111128123246.GB79829@ocelot.phlegethon.org>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4 of 5] Add code to track the address of the
	VM generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:15 +0000 on 28 Nov (1322482536), Paul Durrant wrote:
> --- a/xen/include/public/hvm/params.h	Mon Nov 28 12:14:48 2011 +0000
> +++ b/xen/include/public/hvm/params.h	Mon Nov 28 12:14:49 2011 +0000
> @@ -142,6 +142,9 @@
>  /* Boolean: Enable nestedhvm (hvm only) */
>  #define HVM_PARAM_NESTEDHVM    24
>  
> -#define HVM_NR_PARAMS          27
> +/* Address of VM generation id buffer */
> +#define HVM_PARAM_VM_GENERATION_ID_ADDR 27
> +
> +#define HVM_NR_PARAMS          28
>  
>  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */

Since the hypervisor doesn't use this value, I don't think this is the
right place for it to live.  Tools-only VM metadata should probably go
in xenstore or in the toolstacks' own datastructures. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:33:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0Oc-0006xC-Li; Mon, 28 Nov 2011 12:33:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RV0Ob-0006wx-RW
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:33:18 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322483446!46121598!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4556 invoked from network); 28 Nov 2011 12:30:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 12:30:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RV0O6-000LDj-DA; Mon, 28 Nov 2011 12:32:46 +0000
Date: Mon, 28 Nov 2011 12:32:46 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20111128123246.GB79829@ocelot.phlegethon.org>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4 of 5] Add code to track the address of the
	VM generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:15 +0000 on 28 Nov (1322482536), Paul Durrant wrote:
> --- a/xen/include/public/hvm/params.h	Mon Nov 28 12:14:48 2011 +0000
> +++ b/xen/include/public/hvm/params.h	Mon Nov 28 12:14:49 2011 +0000
> @@ -142,6 +142,9 @@
>  /* Boolean: Enable nestedhvm (hvm only) */
>  #define HVM_PARAM_NESTEDHVM    24
>  
> -#define HVM_NR_PARAMS          27
> +/* Address of VM generation id buffer */
> +#define HVM_PARAM_VM_GENERATION_ID_ADDR 27
> +
> +#define HVM_NR_PARAMS          28
>  
>  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */

Since the hypervisor doesn't use this value, I don't think this is the
right place for it to live.  Tools-only VM metadata should probably go
in xenstore or in the toolstacks' own datastructures. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:45:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:45:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0aF-0007Oi-1G; Mon, 28 Nov 2011 12:45:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RV0aD-0007Od-TH
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:45:18 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322484260!42699309!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NDk2NzA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12873 invoked from network); 28 Nov 2011 12:44:21 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 12:44:21 -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 C281F159C;
	Mon, 28 Nov 2011 14:44:45 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A54EC20083; Mon, 28 Nov 2011 14:44:45 +0200 (EET)
Date: Mon, 28 Nov 2011 14:44:45 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: sandr8 <sandr8@gmail.com>
Message-ID: <20111128124445.GB12984@reaktio.net>
References: <20111031182220.GZ12984@reaktio.net>
	<1322358814275-5025774.post@n5.nabble.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322358814275-5025774.post@n5.nabble.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen 4.1.1 HVM guest cdrom trouble, lost	interrupts,
	ata failed commands (frozen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Nov 26, 2011 at 05:53:34PM -0800, sandr8 wrote:
> Hi,
> 
>   I am seeing exactly the same behavior... did you manage to get around this
> issue?
> 

Yep, as stated in my original email, upgrading to Xen 4.1.2 fixes the problem.
I'm not aware of any workarounds if you're still using Xen 4.1.1.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:45:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:45:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0aF-0007Oi-1G; Mon, 28 Nov 2011 12:45:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RV0aD-0007Od-TH
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:45:18 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322484260!42699309!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NDk2NzA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12873 invoked from network); 28 Nov 2011 12:44:21 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 12:44:21 -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 C281F159C;
	Mon, 28 Nov 2011 14:44:45 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A54EC20083; Mon, 28 Nov 2011 14:44:45 +0200 (EET)
Date: Mon, 28 Nov 2011 14:44:45 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: sandr8 <sandr8@gmail.com>
Message-ID: <20111128124445.GB12984@reaktio.net>
References: <20111031182220.GZ12984@reaktio.net>
	<1322358814275-5025774.post@n5.nabble.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322358814275-5025774.post@n5.nabble.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen 4.1.1 HVM guest cdrom trouble, lost	interrupts,
	ata failed commands (frozen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Nov 26, 2011 at 05:53:34PM -0800, sandr8 wrote:
> Hi,
> 
>   I am seeing exactly the same behavior... did you manage to get around this
> issue?
> 

Yep, as stated in my original email, upgrading to Xen 4.1.2 fixes the problem.
I'm not aware of any workarounds if you're still using Xen 4.1.1.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:47:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:47:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0av-0007QK-FT; Mon, 28 Nov 2011 12:46:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RV0at-0007Q4-A2
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:45:59 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322484322!4902551!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NDk2NzA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11019 invoked from network); 28 Nov 2011 12:45:23 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 12:45:23 -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 42BCD16F0;
	Mon, 28 Nov 2011 14:45:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1EF7920083; Mon, 28 Nov 2011 14:45:22 +0200 (EET)
Date: Mon, 28 Nov 2011 14:45:22 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111128124522.GC12984@reaktio.net>
References: <20111031182220.GZ12984@reaktio.net>
	<1322358814275-5025774.post@n5.nabble.com>
	<alpine.DEB.2.00.1111281019200.31179@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111281019200.31179@kaball-desktop>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	sandr8 <sandr8@gmail.com>
Subject: Re: [Xen-devel] Xen 4.1.1 HVM guest cdrom trouble, lost	interrupts,
	ata failed commands (frozen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 10:19:32AM +0000, Stefano Stabellini wrote:
> On Sun, 27 Nov 2011, sandr8 wrote:
> > Hi,
> > 
> >   I am seeing exactly the same behavior... did you manage to get around this
> > issue?
> 
> it is fixed in xen 4.1.2
> 

Btw are there any known workarounds for <= 4.1.1 ?

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:47:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:47:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0av-0007QK-FT; Mon, 28 Nov 2011 12:46:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RV0at-0007Q4-A2
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:45:59 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322484322!4902551!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0NDk2NzA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11019 invoked from network); 28 Nov 2011 12:45:23 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 12:45:23 -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 42BCD16F0;
	Mon, 28 Nov 2011 14:45:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1EF7920083; Mon, 28 Nov 2011 14:45:22 +0200 (EET)
Date: Mon, 28 Nov 2011 14:45:22 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20111128124522.GC12984@reaktio.net>
References: <20111031182220.GZ12984@reaktio.net>
	<1322358814275-5025774.post@n5.nabble.com>
	<alpine.DEB.2.00.1111281019200.31179@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1111281019200.31179@kaball-desktop>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	sandr8 <sandr8@gmail.com>
Subject: Re: [Xen-devel] Xen 4.1.1 HVM guest cdrom trouble, lost	interrupts,
	ata failed commands (frozen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 10:19:32AM +0000, Stefano Stabellini wrote:
> On Sun, 27 Nov 2011, sandr8 wrote:
> > Hi,
> > 
> >   I am seeing exactly the same behavior... did you manage to get around this
> > issue?
> 
> it is fixed in xen 4.1.2
> 

Btw are there any known workarounds for <= 4.1.1 ?

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0hX-0007pO-QI; Mon, 28 Nov 2011 12:52:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hV-0007om-UY
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:52:50 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322484733!5343655!2
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20832 invoked from network); 28 Nov 2011 12:52:13 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:13 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=BZIykXyqEeyIWTeFjjqpmMXFoThsnfWxXGOurQMNCvnWqjT4hXe6vLqU
	v0j7PxlYeavynmQzqEdXjTZC9O9fpQGbNt0m4v0UAiBnqvUqVu6Syp3rz
	rr55qtvkPI+4z7igYJ37ZJmbx+Zbq6QuGfuSwlWYrVtPfpoYd0BVTDYeS
	p53Dwz9Ryn4tpNqYmI5eSZ88yb8iFt1yw9K8zKHfomhoeIQ7PiTtuK275
	TM4GCs44McP1HsHUYaUSWXT3Pz3Dp;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484734; x=1354020734;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=8kIxHDbZ086yWrc6EqH3K9BFkGGoGBjIGXEl2fyz5QU=;
	b=q+DhaZKlaA7fV+v0IPP3nMIO+gUkpUUCgDRVD8ykZFAMnSVv8JXt6qd/
	RFKrsWs6Jt73oiu3P1gkwH+N6Tv7aLFUuBlst4wgKXiQZFclKpLol+Cwz
	Sm6x3dVsLlge9JOIkTA4yeJjoR0xPpvCiJZeE+NpGpubjeaU8YdPRydxF
	czSXvt8FDpRsxyfc7eLyBYaretB7kmG0JwCPuE0R4MZL1FUEwdKCqO8HP
	MN0eThaTes9pXdrUpMjboVNn7yR29;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342802"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="124293989"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 2A20395B561;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============6135696626582972432=="
MIME-Version: 1.0
X-Mercurial-Node: 3a817a14e6a29657c8f798987ccb1568a586ea70
Message-Id: <3a817a14e6a29657c8f7.1322484360@nehalem1>
In-Reply-To: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:46:00 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 5] xl sched-credit: support long options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6135696626582972432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

The help text of xl sched-credit supported long options. Neither the man page
nor the implementation did.

Signed-off-by: juergen.gross@ts.fujitsu.com


2 files changed, 26 insertions(+), 7 deletions(-)
docs/man/xl.pod.1        |   15 ++++++++++-----
tools/libxl/xl_cmdimpl.c |   18 ++++++++++++++++--



--===============6135696626582972432==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-5.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1322483011 -3600
# Node ID 3a817a14e6a29657c8f798987ccb1568a586ea70
# Parent  95d4e2e0bed374602b5a78ee004b057ad8715d65
xl sched-credit: support long options

The help text of xl sched-credit supported long options. Neither the man page
nor the implementation did.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 95d4e2e0bed3 -r 3a817a14e6a2 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Fri Nov 25 20:32:05 2011 +0000
+++ b/docs/man/xl.pod.1	Mon Nov 28 13:23:31 2011 +0100
@@ -579,25 +579,30 @@ default B<credit> is used for scheduling
 
 =over 4
 
-=item B<sched-credit> [ B<-d> I<domain-id> [ B<-w>[B<=>I<WEIGHT>] | B<-c>[B<=>I<CAP>] ] ]
+=item B<sched-credit> [I<OPTIONS>]
 
-Set credit scheduler parameters.  The credit scheduler is a
+Set or get credit scheduler parameters.  The credit scheduler is a
 proportional fair share CPU scheduler built from the ground up to be
 work conserving on SMP hosts.
 
 Each domain (including Domain0) is assigned a weight and a cap.
 
-B<PARAMETERS>
+B<OPTIONS>
 
 =over 4
 
-=item I<WEIGHT>
+=item B<-d DOMAIN>, B<--domain=DOMAIN>
+
+Specify domain for which scheduler parameters are to be modified or retrieved.
+Mandatory for modifying scheduler parameters.
+
+=item B<-w WEIGHT>, B<--weight=WEIGHT>
 
 A domain with a weight of 512 will get twice as much CPU as a domain
 with a weight of 256 on a contended host. Legal weights range from 1
 to 65535 and the default is 256.
 
-=item I<CAP>
+=item B<-c CAP>, B<--cap=CAP>
 
 The cap optionally fixes the maximum amount of CPU a domain will be
 able to consume, even if the host system has idle CPU cycles. The cap
diff -r 95d4e2e0bed3 -r 3a817a14e6a2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 20:32:05 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:23:31 2011 +0100
@@ -3720,8 +3720,19 @@ int main_sched_credit(int argc, char **a
     const char *dom = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
     int opt, rc;
-
-    while ((opt = def_getopt(argc, argv, "d:w:c:", "sched-credit", 0)) != -1) {
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"domain", 1, 0, 'd'},
+        {"weight", 1, 0, 'w'},
+        {"cap", 1, 0, 'c'},
+        {"help", 0, 0, 'h'},
+        {0, 0, 0, 0}
+    };
+
+    while (1) {
+        opt = getopt_long(argc, argv, "d:w:c:h", long_options, &option_index);
+        if (opt == -1)
+            break;
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3736,6 +3747,9 @@ int main_sched_credit(int argc, char **a
             cap = strtol(optarg, NULL, 10);
             opt_c = 1;
             break;
+        case 'h':
+            help("sched-credit");
+            return 0;
         }
     }
 

--===============6135696626582972432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6135696626582972432==--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0hX-0007pO-QI; Mon, 28 Nov 2011 12:52:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hV-0007om-UY
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:52:50 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322484733!5343655!2
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20832 invoked from network); 28 Nov 2011 12:52:13 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:13 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=BZIykXyqEeyIWTeFjjqpmMXFoThsnfWxXGOurQMNCvnWqjT4hXe6vLqU
	v0j7PxlYeavynmQzqEdXjTZC9O9fpQGbNt0m4v0UAiBnqvUqVu6Syp3rz
	rr55qtvkPI+4z7igYJ37ZJmbx+Zbq6QuGfuSwlWYrVtPfpoYd0BVTDYeS
	p53Dwz9Ryn4tpNqYmI5eSZ88yb8iFt1yw9K8zKHfomhoeIQ7PiTtuK275
	TM4GCs44McP1HsHUYaUSWXT3Pz3Dp;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484734; x=1354020734;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=8kIxHDbZ086yWrc6EqH3K9BFkGGoGBjIGXEl2fyz5QU=;
	b=q+DhaZKlaA7fV+v0IPP3nMIO+gUkpUUCgDRVD8ykZFAMnSVv8JXt6qd/
	RFKrsWs6Jt73oiu3P1gkwH+N6Tv7aLFUuBlst4wgKXiQZFclKpLol+Cwz
	Sm6x3dVsLlge9JOIkTA4yeJjoR0xPpvCiJZeE+NpGpubjeaU8YdPRydxF
	czSXvt8FDpRsxyfc7eLyBYaretB7kmG0JwCPuE0R4MZL1FUEwdKCqO8HP
	MN0eThaTes9pXdrUpMjboVNn7yR29;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342802"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="124293989"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 2A20395B561;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============6135696626582972432=="
MIME-Version: 1.0
X-Mercurial-Node: 3a817a14e6a29657c8f798987ccb1568a586ea70
Message-Id: <3a817a14e6a29657c8f7.1322484360@nehalem1>
In-Reply-To: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:46:00 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 5] xl sched-credit: support long options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6135696626582972432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

The help text of xl sched-credit supported long options. Neither the man page
nor the implementation did.

Signed-off-by: juergen.gross@ts.fujitsu.com


2 files changed, 26 insertions(+), 7 deletions(-)
docs/man/xl.pod.1        |   15 ++++++++++-----
tools/libxl/xl_cmdimpl.c |   18 ++++++++++++++++--



--===============6135696626582972432==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-5.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1322483011 -3600
# Node ID 3a817a14e6a29657c8f798987ccb1568a586ea70
# Parent  95d4e2e0bed374602b5a78ee004b057ad8715d65
xl sched-credit: support long options

The help text of xl sched-credit supported long options. Neither the man page
nor the implementation did.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 95d4e2e0bed3 -r 3a817a14e6a2 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Fri Nov 25 20:32:05 2011 +0000
+++ b/docs/man/xl.pod.1	Mon Nov 28 13:23:31 2011 +0100
@@ -579,25 +579,30 @@ default B<credit> is used for scheduling
 
 =over 4
 
-=item B<sched-credit> [ B<-d> I<domain-id> [ B<-w>[B<=>I<WEIGHT>] | B<-c>[B<=>I<CAP>] ] ]
+=item B<sched-credit> [I<OPTIONS>]
 
-Set credit scheduler parameters.  The credit scheduler is a
+Set or get credit scheduler parameters.  The credit scheduler is a
 proportional fair share CPU scheduler built from the ground up to be
 work conserving on SMP hosts.
 
 Each domain (including Domain0) is assigned a weight and a cap.
 
-B<PARAMETERS>
+B<OPTIONS>
 
 =over 4
 
-=item I<WEIGHT>
+=item B<-d DOMAIN>, B<--domain=DOMAIN>
+
+Specify domain for which scheduler parameters are to be modified or retrieved.
+Mandatory for modifying scheduler parameters.
+
+=item B<-w WEIGHT>, B<--weight=WEIGHT>
 
 A domain with a weight of 512 will get twice as much CPU as a domain
 with a weight of 256 on a contended host. Legal weights range from 1
 to 65535 and the default is 256.
 
-=item I<CAP>
+=item B<-c CAP>, B<--cap=CAP>
 
 The cap optionally fixes the maximum amount of CPU a domain will be
 able to consume, even if the host system has idle CPU cycles. The cap
diff -r 95d4e2e0bed3 -r 3a817a14e6a2 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Nov 25 20:32:05 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:23:31 2011 +0100
@@ -3720,8 +3720,19 @@ int main_sched_credit(int argc, char **a
     const char *dom = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
     int opt, rc;
-
-    while ((opt = def_getopt(argc, argv, "d:w:c:", "sched-credit", 0)) != -1) {
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"domain", 1, 0, 'd'},
+        {"weight", 1, 0, 'w'},
+        {"cap", 1, 0, 'c'},
+        {"help", 0, 0, 'h'},
+        {0, 0, 0, 0}
+    };
+
+    while (1) {
+        opt = getopt_long(argc, argv, "d:w:c:h", long_options, &option_index);
+        if (opt == -1)
+            break;
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3736,6 +3747,9 @@ int main_sched_credit(int argc, char **a
             cap = strtol(optarg, NULL, 10);
             opt_c = 1;
             break;
+        case 'h':
+            help("sched-credit");
+            return 0;
         }
     }
 

--===============6135696626582972432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6135696626582972432==--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0hY-0007pd-Ka; Mon, 28 Nov 2011 12:52:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hW-0007or-LX
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:52:51 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322484733!5343655!4
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20878 invoked from network); 28 Nov 2011 12:52:14 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:14 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=mk0oM0HbyuI6gkoLzuZLzgUcbXoM62tsHGamRvsfweU47rTPm+AAfO0K
	EbdsBZAfSA7zp4/gEP7yoBZHpYkYO3kNfVawfjZwN/xI6EL68ALzLyNIf
	xH95tRrnozLvfYSDy4iOJyWOrAr68ElaUMxdQ+ttcs3akMWhCqWJvEkpu
	IwakdRZSSedVJXHcVbdy08RwRFYzFe0QBYvIztzMW8wTpAOq8pOc0Ju/Q
	z7r8HTQ3usuCg+3ZdGi2tKkrx0ebq;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484734; x=1354020734;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=WMWAffceF20qzEM+meJxzFOGGAH3GhxuARk1tI5xwcc=;
	b=Tz54gpSjENNsyZwh+cy1pWG8ABj+SjL5tLIzs7Fp83CADiZJZ0ZvEnPH
	WWSvenzuyPxvOyqDWCfsvUGBFsqgULeCaPFH1MENBNFENpFABS+SuYU8F
	2hldwit09UFrlXdoAS7B7CFxpLo0/3OVHPeTd2TgYVB3vq9pmtnLhYKg+
	vIxiiR7ZhFA395KhoqUaNBVlKekAe7Sp9ZbWjiHpUiulXzvh/nh8P4T4x
	kqTEQHfhYY29xNAUhkYOVJNodtm5r;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342804"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:14 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="124293991"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 67EF695B567;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============5902672993926594007=="
MIME-Version: 1.0
X-Mercurial-Node: 49e94f727d87b5f04834056175c12c5a8654f6db
Message-Id: <49e94f727d87b5f04834.1322484364@nehalem1>
In-Reply-To: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:46:04 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 5] Support of xl sched-sedf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5902672993926594007==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Supports the xl subcommand sched-sedf.
The man page is only a minimal version (copy from xm man page without
examples). BTW: the xm man page seems not to be in sync with xm sched-sedf -h
regarding the time units. I used milliseconds in the xl implementation.
Only minimal semantical checks of parameters.

Signed-off-by: juergen.gross@ts.fujitsu.com


7 files changed, 293 insertions(+)
docs/man/xl.pod.1           |   42 ++++++++++
tools/libxl/libxl.c         |   52 +++++++++++++
tools/libxl/libxl.h         |    4 +
tools/libxl/libxl_types.idl |    8 ++
tools/libxl/xl.h            |    1 
tools/libxl/xl_cmdimpl.c    |  170 +++++++++++++++++++++++++++++++++++++++++++
tools/libxl/xl_cmdtable.c   |   16 ++++



--===============5902672993926594007==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-5.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1322483837 -3600
# Node ID 49e94f727d87b5f04834056175c12c5a8654f6db
# Parent  40d8819d98ff7a1fb6d1992ad35d980f1a7d6876
Support of xl sched-sedf

Supports the xl subcommand sched-sedf.
The man page is only a minimal version (copy from xm man page without
examples). BTW: the xm man page seems not to be in sync with xm sched-sedf -h
regarding the time units. I used milliseconds in the xl implementation.
Only minimal semantical checks of parameters.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 40d8819d98ff -r 49e94f727d87 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Nov 28 13:31:37 2011 +0100
+++ b/docs/man/xl.pod.1	Mon Nov 28 13:37:17 2011 +0100
@@ -645,6 +645,48 @@ Restrict output to domains in the specif
 
 =back
 
+=item B<sched-sedf> [I<OPTIONS>]
+
+Set or get Simple EDF (Earliest Deadline First) scheduler parameters. This
+scheduler provides weighted CPU sharing in an intuitive way and uses
+realtime-algorithms to ensure time guarantees.  For more information see
+docs/misc/sedf_scheduler_mini-HOWTO.txt in the Xen distribution.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-d DOMAIN>, B<--domain=DOMAIN>
+
+Specify domain for which scheduler parameters are to be modified or retrieved.
+Mandatory for modifying scheduler parameters.
+
+=item B<-p PERIOD>, B<--period=PERIOD>
+
+The normal EDF scheduling usage in milliseconds.
+
+=item B<-s SLICE>, B<--slice=SLICE>
+
+The normal EDF scheduling usage in milliseconds.
+
+=item B<-l LATENCY>, B<--latency=LATENCY>
+
+Scaled period if domain is doing heavy I/O.
+
+=item B<-e EXTRA>, B<--extra=EXTRA>
+
+Flag for allowing domain to run in extra time (0 or 1).
+
+=item B<-w WEIGHT>, B<--weight=WEIGHT>
+
+Another way of setting CPU slice.
+
+=item B<-c CPUPOOL>, B<--cpupool=CPUPOOL>
+
+Restrict output to domains in the specified cpupool.
+
+=back
+
 =back
 
 =head1 CPUPOOLS COMMANDS
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Nov 28 13:37:17 2011 +0100
@@ -2782,6 +2782,58 @@ int libxl_sched_credit2_domain_set(libxl
     return 0;
 }
 
+int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
+                                libxl_sched_sedf *scinfo)
+{
+    uint64_t period;
+    uint64_t slice;
+    uint64_t latency;
+    uint16_t extratime;
+    uint16_t weight;
+    int rc;
+
+    rc = xc_sedf_domain_get(ctx->xch, domid, &period, &slice, &latency,
+                            &extratime, &weight);
+    if (rc != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain sched sedf");
+        return ERROR_FAIL;
+    }
+
+    scinfo->period = period / 1000000;
+    scinfo->slice = slice / 1000000;
+    scinfo->latency = latency / 1000000;
+    scinfo->extratime = extratime;
+    scinfo->weight = weight;
+
+    return 0;
+}
+
+int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
+                                libxl_sched_sedf *scinfo)
+{
+    xc_domaininfo_t domaininfo;
+    int rc;
+
+    rc = xc_domain_getinfolist(ctx->xch, domid, 1, &domaininfo);
+    if (rc < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
+        return ERROR_FAIL;
+    }
+    if (rc != 1 || domaininfo.domain != domid)
+        return ERROR_INVAL;
+
+
+    rc = xc_sedf_domain_set(ctx->xch, domid, scinfo->period * 1000000,
+                            scinfo->slice * 1000000, scinfo->latency * 1000000,
+                            scinfo->extratime, scinfo->weight);
+    if ( rc < 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting domain sched sedf");
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
 static int trigger_type_from_string(char *trigger_name)
 {
     if (!strcmp(trigger_name, "nmi"))
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/libxl.h	Mon Nov 28 13:37:17 2011 +0100
@@ -571,6 +571,10 @@ int libxl_sched_credit2_domain_get(libxl
                                    libxl_sched_credit2 *scinfo);
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
                                    libxl_sched_credit2 *scinfo);
+int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
+                                libxl_sched_sedf *scinfo);
+int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
+                                libxl_sched_sedf *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
                        char *trigger_name, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Mon Nov 28 13:37:17 2011 +0100
@@ -379,3 +379,11 @@ libxl_sched_credit2 = Struct("sched_cred
 libxl_sched_credit2 = Struct("sched_credit2", [
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_sched_sedf = Struct("sched_sedf", [
+    ("period", integer),
+    ("slice", integer),
+    ("latency", integer),
+    ("extratime", integer),
+    ("weight", integer),
+    ], dispose_fn=None)
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/xl.h	Mon Nov 28 13:37:17 2011 +0100
@@ -56,6 +56,7 @@ int main_memset(int argc, char **argv);
 int main_memset(int argc, char **argv);
 int main_sched_credit(int argc, char **argv);
 int main_sched_credit2(int argc, char **argv);
+int main_sched_sedf(int argc, char **argv);
 int main_domid(int argc, char **argv);
 int main_domname(int argc, char **argv);
 int main_rename(int argc, char **argv);
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:37:17 2011 +0100
@@ -3770,6 +3770,58 @@ static int sched_credit2_domain_output(
     return 0;
 }
 
+static int sched_sedf_domain_get(
+    int domid, libxl_sched_sedf *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_sedf_domain_get(ctx, domid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_sedf_domain_get failed.\n");
+
+    return rc;
+}
+
+static int sched_sedf_domain_set(
+    int domid, libxl_sched_sedf *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_sedf_domain_set(ctx, domid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_sedf_domain_set failed.\n");
+
+    return rc;
+}
+
+static int sched_sedf_domain_output(
+    int domid)
+{
+    char *domname;
+    libxl_sched_sedf scinfo;
+    int rc;
+
+    if (domid < 0) {
+        printf("%-33s %4s %6s %-6s %7s %5s %6s\n", "Name", "ID", "Period",
+               "Slice", "Latency", "Extra", "Weight");
+        return 0;
+    }
+    rc = sched_sedf_domain_get(domid, &scinfo);
+    if (rc)
+        return rc;
+    domname = libxl_domid_to_name(ctx, domid);
+    printf("%-33s %4d %6d %6d %7d %5d %6d\n",
+        domname,
+        domid,
+        scinfo.period,
+        scinfo.slice,
+        scinfo.latency,
+        scinfo.extratime,
+        scinfo.weight);
+    free(domname);
+    return 0;
+}
+
 static int sched_domain_output(
     uint32_t sched, int (*output)(int), const char *cpupool)
 {
@@ -3973,6 +4025,124 @@ int main_sched_credit2(int argc, char **
             if (opt_w)
                 scinfo.weight = weight;
             rc = sched_credit2_domain_set(domid, &scinfo);
+            if (rc)
+                return -rc;
+        }
+    }
+
+    return 0;
+}
+
+int main_sched_sedf(int argc, char **argv)
+{
+    libxl_sched_sedf scinfo;
+    const char *dom = NULL;
+    const char *cpupool = NULL;
+    int period = 0, opt_p = 0;
+    int slice = 0, opt_s = 0;
+    int latency = 0, opt_l = 0;
+    int extra = 0, opt_e = 0;
+    int weight = 0, opt_w = 0;
+    int opt, rc;
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"period", 1, 0, 'p'},
+        {"slice", 1, 0, 's'},
+        {"latency", 1, 0, 'l'},
+        {"extra", 1, 0, 'e'},
+        {"weight", 1, 0, 'w'},
+        {"cpupool", 1, 0, 'c'},
+        {"help", 0, 0, 'h'},
+        {0, 0, 0, 0}
+    };
+
+    while (1) {
+        opt = getopt_long(argc, argv, "d:p:s:l:e:w:c:h", long_options,
+                          &option_index);
+        if (opt == -1)
+            break;
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+        case 'd':
+            dom = optarg;
+            break;
+        case 'p':
+            period = strtol(optarg, NULL, 10);
+            opt_p = 1;
+            break;
+        case 's':
+            slice = strtol(optarg, NULL, 10);
+            opt_s = 1;
+            break;
+        case 'l':
+            latency = strtol(optarg, NULL, 10);
+            opt_l = 1;
+            break;
+        case 'e':
+            extra = strtol(optarg, NULL, 10);
+            opt_e = 1;
+            break;
+        case 'w':
+            weight = strtol(optarg, NULL, 10);
+            opt_w = 1;
+            break;
+        case 'c':
+            cpupool = optarg;
+            break;
+        case 'h':
+            help("sched-sedf");
+            return 0;
+        }
+    }
+
+    if (cpupool && (dom || opt_p || opt_s || opt_l || opt_e || opt_w)) {
+        fprintf(stderr, "Specifying a cpupool is not allowed with other "
+                "options.\n");
+        return 1;
+    }
+    if (!dom && (opt_p || opt_s || opt_l || opt_e || opt_w)) {
+        fprintf(stderr, "Must specify a domain.\n");
+        return 1;
+    }
+    if (opt_w && (opt_p || opt_s)) {
+        fprintf(stderr, "Specifying a weight AND period or slice is not "
+                "allowed.\n");
+    }
+
+    if (!dom) { /* list all domain's credit scheduler info */
+        return -sched_domain_output(XEN_SCHEDULER_SEDF,
+                                    sched_sedf_domain_output, cpupool);
+    } else {
+        find_domain(dom);
+
+        rc = sched_sedf_domain_get(domid, &scinfo);
+        if (rc)
+            return -rc;
+
+        if (!opt_p && !opt_s && !opt_l && !opt_e && !opt_w) {
+            /* output sedf scheduler info */
+            sched_sedf_domain_output(-1);
+            return -sched_sedf_domain_output(domid);
+        } else { /* set sedf scheduler paramaters */
+            if (opt_p) {
+                scinfo.period = period;
+                scinfo.weight = 0;
+            }
+            if (opt_s) {
+                scinfo.slice = slice;
+                scinfo.weight = 0;
+            }
+            if (opt_l)
+                scinfo.latency = latency;
+            if (opt_e)
+                scinfo.extratime = extra;
+            if (opt_w) {
+                scinfo.weight = weight;
+                scinfo.period = 0;
+                scinfo.slice = 0;
+            }
+            rc = sched_sedf_domain_set(domid, &scinfo);
             if (rc)
                 return -rc;
         }
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:37:17 2011 +0100
@@ -205,6 +205,22 @@ struct cmd_spec cmd_table[] = {
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
       "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
       "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
+    },
+    { "sched-sedf",
+      &main_sched_sedf, 0,
+      "Get/set sedf scheduler parameters",
+      "[options]",
+      "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
+      "-p MS, --period=MS             Relative deadline(ms)\n"
+      "-s MS, --slice=MS              Worst-case execution time(ms).\n"
+      "                               (slice < period)\n"
+      "-l MS, --latency=MS            Scaled period (ms) when domain\n"
+      "                               performs heavy I/O\n"
+      "-e FLAG, --extra=FLAG          Flag (0 or 1) controls if domain\n"
+      "                               can run in extra time\n"
+      "-w FLOAT, --weight=FLOAT       CPU Period/slice (do not set with\n"
+      "                               --period/--slice)\n"
+      "-c CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "domid",
       &main_domid, 0,

--===============5902672993926594007==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5902672993926594007==--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0hY-0007pd-Ka; Mon, 28 Nov 2011 12:52:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hW-0007or-LX
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:52:51 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322484733!5343655!4
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20878 invoked from network); 28 Nov 2011 12:52:14 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:14 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=mk0oM0HbyuI6gkoLzuZLzgUcbXoM62tsHGamRvsfweU47rTPm+AAfO0K
	EbdsBZAfSA7zp4/gEP7yoBZHpYkYO3kNfVawfjZwN/xI6EL68ALzLyNIf
	xH95tRrnozLvfYSDy4iOJyWOrAr68ElaUMxdQ+ttcs3akMWhCqWJvEkpu
	IwakdRZSSedVJXHcVbdy08RwRFYzFe0QBYvIztzMW8wTpAOq8pOc0Ju/Q
	z7r8HTQ3usuCg+3ZdGi2tKkrx0ebq;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484734; x=1354020734;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=WMWAffceF20qzEM+meJxzFOGGAH3GhxuARk1tI5xwcc=;
	b=Tz54gpSjENNsyZwh+cy1pWG8ABj+SjL5tLIzs7Fp83CADiZJZ0ZvEnPH
	WWSvenzuyPxvOyqDWCfsvUGBFsqgULeCaPFH1MENBNFENpFABS+SuYU8F
	2hldwit09UFrlXdoAS7B7CFxpLo0/3OVHPeTd2TgYVB3vq9pmtnLhYKg+
	vIxiiR7ZhFA395KhoqUaNBVlKekAe7Sp9ZbWjiHpUiulXzvh/nh8P4T4x
	kqTEQHfhYY29xNAUhkYOVJNodtm5r;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342804"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:14 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="124293991"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 67EF695B567;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============5902672993926594007=="
MIME-Version: 1.0
X-Mercurial-Node: 49e94f727d87b5f04834056175c12c5a8654f6db
Message-Id: <49e94f727d87b5f04834.1322484364@nehalem1>
In-Reply-To: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:46:04 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 5 of 5] Support of xl sched-sedf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5902672993926594007==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Supports the xl subcommand sched-sedf.
The man page is only a minimal version (copy from xm man page without
examples). BTW: the xm man page seems not to be in sync with xm sched-sedf -h
regarding the time units. I used milliseconds in the xl implementation.
Only minimal semantical checks of parameters.

Signed-off-by: juergen.gross@ts.fujitsu.com


7 files changed, 293 insertions(+)
docs/man/xl.pod.1           |   42 ++++++++++
tools/libxl/libxl.c         |   52 +++++++++++++
tools/libxl/libxl.h         |    4 +
tools/libxl/libxl_types.idl |    8 ++
tools/libxl/xl.h            |    1 
tools/libxl/xl_cmdimpl.c    |  170 +++++++++++++++++++++++++++++++++++++++++++
tools/libxl/xl_cmdtable.c   |   16 ++++



--===============5902672993926594007==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-5.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1322483837 -3600
# Node ID 49e94f727d87b5f04834056175c12c5a8654f6db
# Parent  40d8819d98ff7a1fb6d1992ad35d980f1a7d6876
Support of xl sched-sedf

Supports the xl subcommand sched-sedf.
The man page is only a minimal version (copy from xm man page without
examples). BTW: the xm man page seems not to be in sync with xm sched-sedf -h
regarding the time units. I used milliseconds in the xl implementation.
Only minimal semantical checks of parameters.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 40d8819d98ff -r 49e94f727d87 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Nov 28 13:31:37 2011 +0100
+++ b/docs/man/xl.pod.1	Mon Nov 28 13:37:17 2011 +0100
@@ -645,6 +645,48 @@ Restrict output to domains in the specif
 
 =back
 
+=item B<sched-sedf> [I<OPTIONS>]
+
+Set or get Simple EDF (Earliest Deadline First) scheduler parameters. This
+scheduler provides weighted CPU sharing in an intuitive way and uses
+realtime-algorithms to ensure time guarantees.  For more information see
+docs/misc/sedf_scheduler_mini-HOWTO.txt in the Xen distribution.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-d DOMAIN>, B<--domain=DOMAIN>
+
+Specify domain for which scheduler parameters are to be modified or retrieved.
+Mandatory for modifying scheduler parameters.
+
+=item B<-p PERIOD>, B<--period=PERIOD>
+
+The normal EDF scheduling usage in milliseconds.
+
+=item B<-s SLICE>, B<--slice=SLICE>
+
+The normal EDF scheduling usage in milliseconds.
+
+=item B<-l LATENCY>, B<--latency=LATENCY>
+
+Scaled period if domain is doing heavy I/O.
+
+=item B<-e EXTRA>, B<--extra=EXTRA>
+
+Flag for allowing domain to run in extra time (0 or 1).
+
+=item B<-w WEIGHT>, B<--weight=WEIGHT>
+
+Another way of setting CPU slice.
+
+=item B<-c CPUPOOL>, B<--cpupool=CPUPOOL>
+
+Restrict output to domains in the specified cpupool.
+
+=back
+
 =back
 
 =head1 CPUPOOLS COMMANDS
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Nov 28 13:37:17 2011 +0100
@@ -2782,6 +2782,58 @@ int libxl_sched_credit2_domain_set(libxl
     return 0;
 }
 
+int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
+                                libxl_sched_sedf *scinfo)
+{
+    uint64_t period;
+    uint64_t slice;
+    uint64_t latency;
+    uint16_t extratime;
+    uint16_t weight;
+    int rc;
+
+    rc = xc_sedf_domain_get(ctx->xch, domid, &period, &slice, &latency,
+                            &extratime, &weight);
+    if (rc != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain sched sedf");
+        return ERROR_FAIL;
+    }
+
+    scinfo->period = period / 1000000;
+    scinfo->slice = slice / 1000000;
+    scinfo->latency = latency / 1000000;
+    scinfo->extratime = extratime;
+    scinfo->weight = weight;
+
+    return 0;
+}
+
+int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
+                                libxl_sched_sedf *scinfo)
+{
+    xc_domaininfo_t domaininfo;
+    int rc;
+
+    rc = xc_domain_getinfolist(ctx->xch, domid, 1, &domaininfo);
+    if (rc < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
+        return ERROR_FAIL;
+    }
+    if (rc != 1 || domaininfo.domain != domid)
+        return ERROR_INVAL;
+
+
+    rc = xc_sedf_domain_set(ctx->xch, domid, scinfo->period * 1000000,
+                            scinfo->slice * 1000000, scinfo->latency * 1000000,
+                            scinfo->extratime, scinfo->weight);
+    if ( rc < 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting domain sched sedf");
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
 static int trigger_type_from_string(char *trigger_name)
 {
     if (!strcmp(trigger_name, "nmi"))
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/libxl.h	Mon Nov 28 13:37:17 2011 +0100
@@ -571,6 +571,10 @@ int libxl_sched_credit2_domain_get(libxl
                                    libxl_sched_credit2 *scinfo);
 int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
                                    libxl_sched_credit2 *scinfo);
+int libxl_sched_sedf_domain_get(libxl_ctx *ctx, uint32_t domid,
+                                libxl_sched_sedf *scinfo);
+int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
+                                libxl_sched_sedf *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
                        char *trigger_name, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Mon Nov 28 13:37:17 2011 +0100
@@ -379,3 +379,11 @@ libxl_sched_credit2 = Struct("sched_cred
 libxl_sched_credit2 = Struct("sched_credit2", [
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_sched_sedf = Struct("sched_sedf", [
+    ("period", integer),
+    ("slice", integer),
+    ("latency", integer),
+    ("extratime", integer),
+    ("weight", integer),
+    ], dispose_fn=None)
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/xl.h	Mon Nov 28 13:37:17 2011 +0100
@@ -56,6 +56,7 @@ int main_memset(int argc, char **argv);
 int main_memset(int argc, char **argv);
 int main_sched_credit(int argc, char **argv);
 int main_sched_credit2(int argc, char **argv);
+int main_sched_sedf(int argc, char **argv);
 int main_domid(int argc, char **argv);
 int main_domname(int argc, char **argv);
 int main_rename(int argc, char **argv);
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:37:17 2011 +0100
@@ -3770,6 +3770,58 @@ static int sched_credit2_domain_output(
     return 0;
 }
 
+static int sched_sedf_domain_get(
+    int domid, libxl_sched_sedf *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_sedf_domain_get(ctx, domid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_sedf_domain_get failed.\n");
+
+    return rc;
+}
+
+static int sched_sedf_domain_set(
+    int domid, libxl_sched_sedf *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_sedf_domain_set(ctx, domid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_sedf_domain_set failed.\n");
+
+    return rc;
+}
+
+static int sched_sedf_domain_output(
+    int domid)
+{
+    char *domname;
+    libxl_sched_sedf scinfo;
+    int rc;
+
+    if (domid < 0) {
+        printf("%-33s %4s %6s %-6s %7s %5s %6s\n", "Name", "ID", "Period",
+               "Slice", "Latency", "Extra", "Weight");
+        return 0;
+    }
+    rc = sched_sedf_domain_get(domid, &scinfo);
+    if (rc)
+        return rc;
+    domname = libxl_domid_to_name(ctx, domid);
+    printf("%-33s %4d %6d %6d %7d %5d %6d\n",
+        domname,
+        domid,
+        scinfo.period,
+        scinfo.slice,
+        scinfo.latency,
+        scinfo.extratime,
+        scinfo.weight);
+    free(domname);
+    return 0;
+}
+
 static int sched_domain_output(
     uint32_t sched, int (*output)(int), const char *cpupool)
 {
@@ -3973,6 +4025,124 @@ int main_sched_credit2(int argc, char **
             if (opt_w)
                 scinfo.weight = weight;
             rc = sched_credit2_domain_set(domid, &scinfo);
+            if (rc)
+                return -rc;
+        }
+    }
+
+    return 0;
+}
+
+int main_sched_sedf(int argc, char **argv)
+{
+    libxl_sched_sedf scinfo;
+    const char *dom = NULL;
+    const char *cpupool = NULL;
+    int period = 0, opt_p = 0;
+    int slice = 0, opt_s = 0;
+    int latency = 0, opt_l = 0;
+    int extra = 0, opt_e = 0;
+    int weight = 0, opt_w = 0;
+    int opt, rc;
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"period", 1, 0, 'p'},
+        {"slice", 1, 0, 's'},
+        {"latency", 1, 0, 'l'},
+        {"extra", 1, 0, 'e'},
+        {"weight", 1, 0, 'w'},
+        {"cpupool", 1, 0, 'c'},
+        {"help", 0, 0, 'h'},
+        {0, 0, 0, 0}
+    };
+
+    while (1) {
+        opt = getopt_long(argc, argv, "d:p:s:l:e:w:c:h", long_options,
+                          &option_index);
+        if (opt == -1)
+            break;
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+        case 'd':
+            dom = optarg;
+            break;
+        case 'p':
+            period = strtol(optarg, NULL, 10);
+            opt_p = 1;
+            break;
+        case 's':
+            slice = strtol(optarg, NULL, 10);
+            opt_s = 1;
+            break;
+        case 'l':
+            latency = strtol(optarg, NULL, 10);
+            opt_l = 1;
+            break;
+        case 'e':
+            extra = strtol(optarg, NULL, 10);
+            opt_e = 1;
+            break;
+        case 'w':
+            weight = strtol(optarg, NULL, 10);
+            opt_w = 1;
+            break;
+        case 'c':
+            cpupool = optarg;
+            break;
+        case 'h':
+            help("sched-sedf");
+            return 0;
+        }
+    }
+
+    if (cpupool && (dom || opt_p || opt_s || opt_l || opt_e || opt_w)) {
+        fprintf(stderr, "Specifying a cpupool is not allowed with other "
+                "options.\n");
+        return 1;
+    }
+    if (!dom && (opt_p || opt_s || opt_l || opt_e || opt_w)) {
+        fprintf(stderr, "Must specify a domain.\n");
+        return 1;
+    }
+    if (opt_w && (opt_p || opt_s)) {
+        fprintf(stderr, "Specifying a weight AND period or slice is not "
+                "allowed.\n");
+    }
+
+    if (!dom) { /* list all domain's credit scheduler info */
+        return -sched_domain_output(XEN_SCHEDULER_SEDF,
+                                    sched_sedf_domain_output, cpupool);
+    } else {
+        find_domain(dom);
+
+        rc = sched_sedf_domain_get(domid, &scinfo);
+        if (rc)
+            return -rc;
+
+        if (!opt_p && !opt_s && !opt_l && !opt_e && !opt_w) {
+            /* output sedf scheduler info */
+            sched_sedf_domain_output(-1);
+            return -sched_sedf_domain_output(domid);
+        } else { /* set sedf scheduler paramaters */
+            if (opt_p) {
+                scinfo.period = period;
+                scinfo.weight = 0;
+            }
+            if (opt_s) {
+                scinfo.slice = slice;
+                scinfo.weight = 0;
+            }
+            if (opt_l)
+                scinfo.latency = latency;
+            if (opt_e)
+                scinfo.extratime = extra;
+            if (opt_w) {
+                scinfo.weight = weight;
+                scinfo.period = 0;
+                scinfo.slice = 0;
+            }
+            rc = sched_sedf_domain_set(domid, &scinfo);
             if (rc)
                 return -rc;
         }
diff -r 40d8819d98ff -r 49e94f727d87 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:31:37 2011 +0100
+++ b/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:37:17 2011 +0100
@@ -205,6 +205,22 @@ struct cmd_spec cmd_table[] = {
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
       "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
       "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
+    },
+    { "sched-sedf",
+      &main_sched_sedf, 0,
+      "Get/set sedf scheduler parameters",
+      "[options]",
+      "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
+      "-p MS, --period=MS             Relative deadline(ms)\n"
+      "-s MS, --slice=MS              Worst-case execution time(ms).\n"
+      "                               (slice < period)\n"
+      "-l MS, --latency=MS            Scaled period (ms) when domain\n"
+      "                               performs heavy I/O\n"
+      "-e FLAG, --extra=FLAG          Flag (0 or 1) controls if domain\n"
+      "                               can run in extra time\n"
+      "-w FLOAT, --weight=FLOAT       CPU Period/slice (do not set with\n"
+      "                               --period/--slice)\n"
+      "-c CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "domid",
       &main_domid, 0,

--===============5902672993926594007==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5902672993926594007==--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0hY-0007pV-6q; Mon, 28 Nov 2011 12:52:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hW-0007op-8S
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:52:50 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322484733!5343655!3
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20846 invoked from network); 28 Nov 2011 12:52:14 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:14 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=XLEBGpgrwjUR04uE4UFSE8In153zjJMmsAIbDOSeiRttghjO5o8a+eRb
	W/k7j5tou1ZjJu7482RU3RQNZiizFTvaVAAfFQ82PwMfSkOMZ7ea1ch2g
	hEYwv9xr2XSopmNNwFXg22wTFlC7/g2oDATxt8aB67CLxgvSPAxESd8it
	lcnDmj6ObkdiERxVqMsyBpbEWy2qbiHsTz5WSgEdjyO0hLPaouNDCr/n+
	Q9zcdfxzWJXqDMVGt2aSO71nqHei1;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484734; x=1354020734;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=H6OVBidh7L/biY7StFe5bhU8nHiXxKqcIC2c0r7ipJk=;
	b=hCP3W80ZPJ3jJxdZO4GS4M7Elh3SGpxA8hP4h5NQIfpUG6C/jCtDedHh
	iFvBM8dpssQXg6F/AQq9YOay1VvWXkz9GzWmCHN5AjaGr/wNZ9SrEP/FH
	iR/UKYfV63SvFmhirTDrA60hzXkave1HQNPCo6mbOIsGe+OP8ku+i655K
	5sDwNdpw9wwd+TccC0N7N/fhMuzkPT94tfBNXTXFj11f6qQmmk/fCy7Mf
	4HWgvZ7Mk2qwk1553/L7zjcI6fIbR;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342803"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="124293990"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 4828795B561;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============6967168488690256163=="
MIME-Version: 1.0
X-Mercurial-Node: 442f86914b6027a3b7e484a46970834c1673b8d7
Message-Id: <442f86914b6027a3b7e4.1322484362@nehalem1>
In-Reply-To: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:46:02 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 5] Support of xl sched-credit2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6967168488690256163==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Supports the xl subcommand sched-credit2.

Signed-off-by: juergen.gross@ts.fujitsu.com


7 files changed, 220 insertions(+)
docs/man/xl.pod.1           |   29 ++++++++++
tools/libxl/libxl.c         |   53 ++++++++++++++++++
tools/libxl/libxl.h         |    4 +
tools/libxl/libxl_types.idl |    4 +
tools/libxl/xl.h            |    1 
tools/libxl/xl_cmdimpl.c    |  121 +++++++++++++++++++++++++++++++++++++++++++
tools/libxl/xl_cmdtable.c   |    8 ++



--===============6967168488690256163==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-5.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1322483487 -3600
# Node ID 442f86914b6027a3b7e484a46970834c1673b8d7
# Parent  8bb677cf78c3868c96e97962477f229367f01dd6
Support of xl sched-credit2

Supports the xl subcommand sched-credit2.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 8bb677cf78c3 -r 442f86914b60 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Nov 28 13:27:15 2011 +0100
+++ b/docs/man/xl.pod.1	Mon Nov 28 13:31:27 2011 +0100
@@ -616,6 +616,35 @@ Restrict output to domains in the specif
 
 =back
 
+=item B<sched-credit2> [I<OPTIONS>]
+
+Set or get credit2 scheduler parameters.  The credit2 scheduler is a
+proportional fair share CPU scheduler built from the ground up to be
+work conserving on SMP hosts.
+
+Each domain (including Domain0) is assigned a weight.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-d DOMAIN>, B<--domain=DOMAIN>
+
+Specify domain for which scheduler parameters are to be modified or retrieved.
+Mandatory for modifying scheduler parameters.
+
+=item B<-w WEIGHT>, B<--weight=WEIGHT>
+
+A domain with a weight of 512 will get twice as much CPU as a domain
+with a weight of 256 on a contended host. Legal weights range from 1
+to 65535 and the default is 256.
+
+=item B<-p CPUPOOL>, B<--cpupool=CPUPOOL>
+
+Restrict output to domains in the specified cpupool.
+
+=back
+
 =back
 
 =head1 CPUPOOLS COMMANDS
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Nov 28 13:31:27 2011 +0100
@@ -2729,6 +2729,59 @@ int libxl_sched_credit_domain_set(libxl_
     return 0;
 }
 
+int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
+                                   libxl_sched_credit2 *scinfo)
+{
+    struct xen_domctl_sched_credit2 sdom;
+    int rc;
+
+    rc = xc_sched_credit2_domain_get(ctx->xch, domid, &sdom);
+    if (rc != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                         "getting domain sched credit2");
+        return ERROR_FAIL;
+    }
+
+    scinfo->weight = sdom.weight;
+
+    return 0;
+}
+
+int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
+                                   libxl_sched_credit2 *scinfo)
+{
+    struct xen_domctl_sched_credit2 sdom;
+    xc_domaininfo_t domaininfo;
+    int rc;
+
+    rc = xc_domain_getinfolist(ctx->xch, domid, 1, &domaininfo);
+    if (rc < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
+        return ERROR_FAIL;
+    }
+    if (rc != 1 || domaininfo.domain != domid)
+        return ERROR_INVAL;
+
+
+    if (scinfo->weight < 1 || scinfo->weight > 65535) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
+            "Cpu weight out of range, valid values are within range from "
+            "1 to 65535");
+        return ERROR_INVAL;
+    }
+
+    sdom.weight = scinfo->weight;
+
+    rc = xc_sched_credit2_domain_set(ctx->xch, domid, &sdom);
+    if ( rc < 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                         "setting domain sched credit2");
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
 static int trigger_type_from_string(char *trigger_name)
 {
     if (!strcmp(trigger_name, "nmi"))
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/libxl.h	Mon Nov 28 13:31:27 2011 +0100
@@ -567,6 +567,10 @@ int libxl_sched_credit_domain_get(libxl_
                                   libxl_sched_credit *scinfo);
 int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
                                   libxl_sched_credit *scinfo);
+int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
+                                   libxl_sched_credit2 *scinfo);
+int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
+                                   libxl_sched_credit2 *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
                        char *trigger_name, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Mon Nov 28 13:31:27 2011 +0100
@@ -375,3 +375,7 @@ libxl_sched_credit = Struct("sched_credi
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
+
+libxl_sched_credit2 = Struct("sched_credit2", [
+    ("weight", integer),
+    ], dispose_fn=None)
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/xl.h	Mon Nov 28 13:31:27 2011 +0100
@@ -55,6 +55,7 @@ int main_memmax(int argc, char **argv);
 int main_memmax(int argc, char **argv);
 int main_memset(int argc, char **argv);
 int main_sched_credit(int argc, char **argv);
+int main_sched_credit2(int argc, char **argv);
 int main_domid(int argc, char **argv);
 int main_domname(int argc, char **argv);
 int main_rename(int argc, char **argv);
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:31:27 2011 +0100
@@ -3723,6 +3723,53 @@ static int sched_credit_domain_output(
     return 0;
 }
 
+static int sched_credit2_domain_get(
+    int domid, libxl_sched_credit2 *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit2_domain_get(ctx, domid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit2_domain_get failed.\n");
+
+    return rc;
+}
+
+static int sched_credit2_domain_set(
+    int domid, libxl_sched_credit2 *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit2_domain_set(ctx, domid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit2_domain_set failed.\n");
+
+    return rc;
+}
+
+static int sched_credit2_domain_output(
+    int domid)
+{
+    char *domname;
+    libxl_sched_credit2 scinfo;
+    int rc;
+
+    if (domid < 0) {
+        printf("%-33s %4s %6s\n", "Name", "ID", "Weight");
+        return 0;
+    }
+    rc = sched_credit2_domain_get(domid, &scinfo);
+    if (rc)
+        return rc;
+    domname = libxl_domid_to_name(ctx, domid);
+    printf("%-33s %4d %6d\n",
+        domname,
+        domid,
+        scinfo.weight);
+    free(domname);
+    return 0;
+}
+
 static int sched_domain_output(
     uint32_t sched, int (*output)(int), const char *cpupool)
 {
@@ -3852,6 +3899,80 @@ int main_sched_credit(int argc, char **a
             if (opt_c)
                 scinfo.cap = cap;
             rc = sched_credit_domain_set(domid, &scinfo);
+            if (rc)
+                return -rc;
+        }
+    }
+
+    return 0;
+}
+
+int main_sched_credit2(int argc, char **argv)
+{
+    libxl_sched_credit2 scinfo;
+    const char *dom = NULL;
+    const char *cpupool = NULL;
+    int weight = 256, opt_w = 0;
+    int opt, rc;
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"domain", 1, 0, 'd'},
+        {"weight", 1, 0, 'w'},
+        {"cpupool", 1, 0, 'p'},
+        {"help", 0, 0, 'h'},
+        {0, 0, 0, 0}
+    };
+
+    while (1) {
+        opt = getopt_long(argc, argv, "d:w:p:h", long_options, &option_index);
+        if (opt == -1)
+            break;
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+        case 'd':
+            dom = optarg;
+            break;
+        case 'w':
+            weight = strtol(optarg, NULL, 10);
+            opt_w = 1;
+            break;
+        case 'p':
+            cpupool = optarg;
+            break;
+        case 'h':
+            help("sched-credit");
+            return 0;
+        }
+    }
+
+    if (cpupool && (dom || opt_w)) {
+        fprintf(stderr, "Specifying a cpupool is not allowed with other "
+                "options.\n");
+        return 1;
+    }
+    if (!dom && opt_w) {
+        fprintf(stderr, "Must specify a domain.\n");
+        return 1;
+    }
+
+    if (!dom) { /* list all domain's credit scheduler info */
+        return -sched_domain_output(XEN_SCHEDULER_CREDIT2,
+                                    sched_credit2_domain_output, cpupool);
+    } else {
+        find_domain(dom);
+
+        rc = sched_credit2_domain_get(domid, &scinfo);
+        if (rc)
+            return -rc;
+
+        if (!opt_w) { /* output credit2 scheduler info */
+            sched_credit2_domain_output(-1);
+            return -sched_credit2_domain_output(domid);
+        } else { /* set credit2 scheduler paramaters */
+            if (opt_w)
+                scinfo.weight = weight;
+            rc = sched_credit2_domain_set(domid, &scinfo);
             if (rc)
                 return -rc;
         }
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:31:27 2011 +0100
@@ -196,6 +196,14 @@ struct cmd_spec cmd_table[] = {
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
       "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
       "-c CAP, --cap=CAP              Cap (int)\n"
+      "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
+    },
+    { "sched-credit2",
+      &main_sched_credit2, 0,
+      "Get/set credit2 scheduler parameters",
+      "[-d <Domain> [-w[=WEIGHT]]] [-p CPUPOOL]",
+      "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
+      "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
       "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "domid",

--===============6967168488690256163==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6967168488690256163==--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0hY-0007pV-6q; Mon, 28 Nov 2011 12:52:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hW-0007op-8S
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:52:50 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322484733!5343655!3
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20846 invoked from network); 28 Nov 2011 12:52:14 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:14 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=XLEBGpgrwjUR04uE4UFSE8In153zjJMmsAIbDOSeiRttghjO5o8a+eRb
	W/k7j5tou1ZjJu7482RU3RQNZiizFTvaVAAfFQ82PwMfSkOMZ7ea1ch2g
	hEYwv9xr2XSopmNNwFXg22wTFlC7/g2oDATxt8aB67CLxgvSPAxESd8it
	lcnDmj6ObkdiERxVqMsyBpbEWy2qbiHsTz5WSgEdjyO0hLPaouNDCr/n+
	Q9zcdfxzWJXqDMVGt2aSO71nqHei1;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484734; x=1354020734;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=H6OVBidh7L/biY7StFe5bhU8nHiXxKqcIC2c0r7ipJk=;
	b=hCP3W80ZPJ3jJxdZO4GS4M7Elh3SGpxA8hP4h5NQIfpUG6C/jCtDedHh
	iFvBM8dpssQXg6F/AQq9YOay1VvWXkz9GzWmCHN5AjaGr/wNZ9SrEP/FH
	iR/UKYfV63SvFmhirTDrA60hzXkave1HQNPCo6mbOIsGe+OP8ku+i655K
	5sDwNdpw9wwd+TccC0N7N/fhMuzkPT94tfBNXTXFj11f6qQmmk/fCy7Mf
	4HWgvZ7Mk2qwk1553/L7zjcI6fIbR;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342803"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="124293990"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 4828795B561;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============6967168488690256163=="
MIME-Version: 1.0
X-Mercurial-Node: 442f86914b6027a3b7e484a46970834c1673b8d7
Message-Id: <442f86914b6027a3b7e4.1322484362@nehalem1>
In-Reply-To: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:46:02 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 5] Support of xl sched-credit2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6967168488690256163==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Supports the xl subcommand sched-credit2.

Signed-off-by: juergen.gross@ts.fujitsu.com


7 files changed, 220 insertions(+)
docs/man/xl.pod.1           |   29 ++++++++++
tools/libxl/libxl.c         |   53 ++++++++++++++++++
tools/libxl/libxl.h         |    4 +
tools/libxl/libxl_types.idl |    4 +
tools/libxl/xl.h            |    1 
tools/libxl/xl_cmdimpl.c    |  121 +++++++++++++++++++++++++++++++++++++++++++
tools/libxl/xl_cmdtable.c   |    8 ++



--===============6967168488690256163==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-5.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1322483487 -3600
# Node ID 442f86914b6027a3b7e484a46970834c1673b8d7
# Parent  8bb677cf78c3868c96e97962477f229367f01dd6
Support of xl sched-credit2

Supports the xl subcommand sched-credit2.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 8bb677cf78c3 -r 442f86914b60 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Nov 28 13:27:15 2011 +0100
+++ b/docs/man/xl.pod.1	Mon Nov 28 13:31:27 2011 +0100
@@ -616,6 +616,35 @@ Restrict output to domains in the specif
 
 =back
 
+=item B<sched-credit2> [I<OPTIONS>]
+
+Set or get credit2 scheduler parameters.  The credit2 scheduler is a
+proportional fair share CPU scheduler built from the ground up to be
+work conserving on SMP hosts.
+
+Each domain (including Domain0) is assigned a weight.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-d DOMAIN>, B<--domain=DOMAIN>
+
+Specify domain for which scheduler parameters are to be modified or retrieved.
+Mandatory for modifying scheduler parameters.
+
+=item B<-w WEIGHT>, B<--weight=WEIGHT>
+
+A domain with a weight of 512 will get twice as much CPU as a domain
+with a weight of 256 on a contended host. Legal weights range from 1
+to 65535 and the default is 256.
+
+=item B<-p CPUPOOL>, B<--cpupool=CPUPOOL>
+
+Restrict output to domains in the specified cpupool.
+
+=back
+
 =back
 
 =head1 CPUPOOLS COMMANDS
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Nov 28 13:31:27 2011 +0100
@@ -2729,6 +2729,59 @@ int libxl_sched_credit_domain_set(libxl_
     return 0;
 }
 
+int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
+                                   libxl_sched_credit2 *scinfo)
+{
+    struct xen_domctl_sched_credit2 sdom;
+    int rc;
+
+    rc = xc_sched_credit2_domain_get(ctx->xch, domid, &sdom);
+    if (rc != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                         "getting domain sched credit2");
+        return ERROR_FAIL;
+    }
+
+    scinfo->weight = sdom.weight;
+
+    return 0;
+}
+
+int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
+                                   libxl_sched_credit2 *scinfo)
+{
+    struct xen_domctl_sched_credit2 sdom;
+    xc_domaininfo_t domaininfo;
+    int rc;
+
+    rc = xc_domain_getinfolist(ctx->xch, domid, 1, &domaininfo);
+    if (rc < 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
+        return ERROR_FAIL;
+    }
+    if (rc != 1 || domaininfo.domain != domid)
+        return ERROR_INVAL;
+
+
+    if (scinfo->weight < 1 || scinfo->weight > 65535) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
+            "Cpu weight out of range, valid values are within range from "
+            "1 to 65535");
+        return ERROR_INVAL;
+    }
+
+    sdom.weight = scinfo->weight;
+
+    rc = xc_sched_credit2_domain_set(ctx->xch, domid, &sdom);
+    if ( rc < 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                         "setting domain sched credit2");
+        return ERROR_FAIL;
+    }
+
+    return 0;
+}
+
 static int trigger_type_from_string(char *trigger_name)
 {
     if (!strcmp(trigger_name, "nmi"))
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/libxl.h	Mon Nov 28 13:31:27 2011 +0100
@@ -567,6 +567,10 @@ int libxl_sched_credit_domain_get(libxl_
                                   libxl_sched_credit *scinfo);
 int libxl_sched_credit_domain_set(libxl_ctx *ctx, uint32_t domid,
                                   libxl_sched_credit *scinfo);
+int libxl_sched_credit2_domain_get(libxl_ctx *ctx, uint32_t domid,
+                                   libxl_sched_credit2 *scinfo);
+int libxl_sched_credit2_domain_set(libxl_ctx *ctx, uint32_t domid,
+                                   libxl_sched_credit2 *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
                        char *trigger_name, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Mon Nov 28 13:31:27 2011 +0100
@@ -375,3 +375,7 @@ libxl_sched_credit = Struct("sched_credi
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
+
+libxl_sched_credit2 = Struct("sched_credit2", [
+    ("weight", integer),
+    ], dispose_fn=None)
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/xl.h	Mon Nov 28 13:31:27 2011 +0100
@@ -55,6 +55,7 @@ int main_memmax(int argc, char **argv);
 int main_memmax(int argc, char **argv);
 int main_memset(int argc, char **argv);
 int main_sched_credit(int argc, char **argv);
+int main_sched_credit2(int argc, char **argv);
 int main_domid(int argc, char **argv);
 int main_domname(int argc, char **argv);
 int main_rename(int argc, char **argv);
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:31:27 2011 +0100
@@ -3723,6 +3723,53 @@ static int sched_credit_domain_output(
     return 0;
 }
 
+static int sched_credit2_domain_get(
+    int domid, libxl_sched_credit2 *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit2_domain_get(ctx, domid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit2_domain_get failed.\n");
+
+    return rc;
+}
+
+static int sched_credit2_domain_set(
+    int domid, libxl_sched_credit2 *scinfo)
+{
+    int rc;
+
+    rc = libxl_sched_credit2_domain_set(ctx, domid, scinfo);
+    if (rc)
+        fprintf(stderr, "libxl_sched_credit2_domain_set failed.\n");
+
+    return rc;
+}
+
+static int sched_credit2_domain_output(
+    int domid)
+{
+    char *domname;
+    libxl_sched_credit2 scinfo;
+    int rc;
+
+    if (domid < 0) {
+        printf("%-33s %4s %6s\n", "Name", "ID", "Weight");
+        return 0;
+    }
+    rc = sched_credit2_domain_get(domid, &scinfo);
+    if (rc)
+        return rc;
+    domname = libxl_domid_to_name(ctx, domid);
+    printf("%-33s %4d %6d\n",
+        domname,
+        domid,
+        scinfo.weight);
+    free(domname);
+    return 0;
+}
+
 static int sched_domain_output(
     uint32_t sched, int (*output)(int), const char *cpupool)
 {
@@ -3852,6 +3899,80 @@ int main_sched_credit(int argc, char **a
             if (opt_c)
                 scinfo.cap = cap;
             rc = sched_credit_domain_set(domid, &scinfo);
+            if (rc)
+                return -rc;
+        }
+    }
+
+    return 0;
+}
+
+int main_sched_credit2(int argc, char **argv)
+{
+    libxl_sched_credit2 scinfo;
+    const char *dom = NULL;
+    const char *cpupool = NULL;
+    int weight = 256, opt_w = 0;
+    int opt, rc;
+    int option_index = 0;
+    static struct option long_options[] = {
+        {"domain", 1, 0, 'd'},
+        {"weight", 1, 0, 'w'},
+        {"cpupool", 1, 0, 'p'},
+        {"help", 0, 0, 'h'},
+        {0, 0, 0, 0}
+    };
+
+    while (1) {
+        opt = getopt_long(argc, argv, "d:w:p:h", long_options, &option_index);
+        if (opt == -1)
+            break;
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+        case 'd':
+            dom = optarg;
+            break;
+        case 'w':
+            weight = strtol(optarg, NULL, 10);
+            opt_w = 1;
+            break;
+        case 'p':
+            cpupool = optarg;
+            break;
+        case 'h':
+            help("sched-credit");
+            return 0;
+        }
+    }
+
+    if (cpupool && (dom || opt_w)) {
+        fprintf(stderr, "Specifying a cpupool is not allowed with other "
+                "options.\n");
+        return 1;
+    }
+    if (!dom && opt_w) {
+        fprintf(stderr, "Must specify a domain.\n");
+        return 1;
+    }
+
+    if (!dom) { /* list all domain's credit scheduler info */
+        return -sched_domain_output(XEN_SCHEDULER_CREDIT2,
+                                    sched_credit2_domain_output, cpupool);
+    } else {
+        find_domain(dom);
+
+        rc = sched_credit2_domain_get(domid, &scinfo);
+        if (rc)
+            return -rc;
+
+        if (!opt_w) { /* output credit2 scheduler info */
+            sched_credit2_domain_output(-1);
+            return -sched_credit2_domain_output(domid);
+        } else { /* set credit2 scheduler paramaters */
+            if (opt_w)
+                scinfo.weight = weight;
+            rc = sched_credit2_domain_set(domid, &scinfo);
             if (rc)
                 return -rc;
         }
diff -r 8bb677cf78c3 -r 442f86914b60 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:27:15 2011 +0100
+++ b/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:31:27 2011 +0100
@@ -196,6 +196,14 @@ struct cmd_spec cmd_table[] = {
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
       "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
       "-c CAP, --cap=CAP              Cap (int)\n"
+      "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
+    },
+    { "sched-credit2",
+      &main_sched_credit2, 0,
+      "Get/set credit2 scheduler parameters",
+      "[-d <Domain> [-w[=WEIGHT]]] [-p CPUPOOL]",
+      "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
+      "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
       "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "domid",

--===============6967168488690256163==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6967168488690256163==--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0hW-0007p8-D8; Mon, 28 Nov 2011 12:52:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hV-0007ol-FC
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:52:49 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322484733!5343655!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20820 invoked from network); 28 Nov 2011 12:52:13 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:13 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:
	Content-Transfer-Encoding:Subject:Message-Id:Date:From:To;
	b=bminimbeNwf1eTbfMaNmUnv6ipO0Woa/0cHmNHVjUiYiNOqmxIUIC5cW
	XmsZlSdM6Vbtziwq6ZI8s6hjSoHFIRlEioiy9eHkuc5ewLhyoBvHcPGwH
	iwATrsS3SuKbupqlJItXZNB4J+UGnIE+fusrVlpR8UOqEf/9+QQGv0zaX
	NpRuliR3bs54EGrVwrB59jArG6PTS3cPU97I+iF4HH2j1vJ8ZUrkPxtoH
	M/zuq50BbQywOEvR/WS6XrO/9DTqp;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484734; x=1354020734;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to;
	bh=rgFxeKLcWhCA3nJ7WB/AuCil7OR7INQW4A0dbsALQjI=;
	b=d7PBulH5YFDnfkrcS8yrNsgtG8kWj09ge/5FzKWNs022tocRg5f05035
	/L1S1szPJVDKf4C12Cj37ijSWHVw9W6+7LYH2lcSYESAFVVGAB04R15+7
	SoOODiCCcqspPgixObdLYnw0gpEujih3TVWXUTnndgX8IlS4MZUgJkOia
	0/zfaJA0y22ZyE19vnDFnYU16GCRZxf8tJl11LzzZ0Fh5IZ7QL2yI3tty
	edZQHcQpHjdMCvA+T1/+aJskuHGLG;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342801"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="124293988"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 1908695B4EF;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:45:59 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 5] v2: xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series enhances scheduler support of xl.

Patch 1: xl sched-credit: support long options
Patch 2: Support cpupools in xl sched-credit
Patch 3: Support of xl sched-credit2
Patch 4: Correct error message in libxl_sched_credit_domain_get()
Patch 5: Support of xl sched-sedf

Changes since v1:
- trim code lines to <80 characters

7 files changed, 641 insertions(+), 38 deletions(-)
docs/man/xl.pod.1           |   90 ++++++++-
tools/libxl/libxl.c         |  108 ++++++++++
tools/libxl/libxl.h         |    8 
tools/libxl/libxl_types.idl |   13 +
tools/libxl/xl.h            |    2 
tools/libxl/xl_cmdimpl.c    |  429 +++++++++++++++++++++++++++++++++++++++----
tools/libxl/xl_cmdtable.c   |   29 ++

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0hW-0007p8-D8; Mon, 28 Nov 2011 12:52:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hV-0007ol-FC
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:52:49 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322484733!5343655!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20820 invoked from network); 28 Nov 2011 12:52:13 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:13 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:
	Content-Transfer-Encoding:Subject:Message-Id:Date:From:To;
	b=bminimbeNwf1eTbfMaNmUnv6ipO0Woa/0cHmNHVjUiYiNOqmxIUIC5cW
	XmsZlSdM6Vbtziwq6ZI8s6hjSoHFIRlEioiy9eHkuc5ewLhyoBvHcPGwH
	iwATrsS3SuKbupqlJItXZNB4J+UGnIE+fusrVlpR8UOqEf/9+QQGv0zaX
	NpRuliR3bs54EGrVwrB59jArG6PTS3cPU97I+iF4HH2j1vJ8ZUrkPxtoH
	M/zuq50BbQywOEvR/WS6XrO/9DTqp;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484734; x=1354020734;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to;
	bh=rgFxeKLcWhCA3nJ7WB/AuCil7OR7INQW4A0dbsALQjI=;
	b=d7PBulH5YFDnfkrcS8yrNsgtG8kWj09ge/5FzKWNs022tocRg5f05035
	/L1S1szPJVDKf4C12Cj37ijSWHVw9W6+7LYH2lcSYESAFVVGAB04R15+7
	SoOODiCCcqspPgixObdLYnw0gpEujih3TVWXUTnndgX8IlS4MZUgJkOia
	0/zfaJA0y22ZyE19vnDFnYU16GCRZxf8tJl11LzzZ0Fh5IZ7QL2yI3tty
	edZQHcQpHjdMCvA+T1/+aJskuHGLG;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342801"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="124293988"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 1908695B4EF;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:45:59 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 5] v2: xl scheduler support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series enhances scheduler support of xl.

Patch 1: xl sched-credit: support long options
Patch 2: Support cpupools in xl sched-credit
Patch 3: Support of xl sched-credit2
Patch 4: Correct error message in libxl_sched_credit_domain_get()
Patch 5: Support of xl sched-sedf

Changes since v1:
- trim code lines to <80 characters

7 files changed, 641 insertions(+), 38 deletions(-)
docs/man/xl.pod.1           |   90 ++++++++-
tools/libxl/libxl.c         |  108 ++++++++++
tools/libxl/libxl.h         |    8 
tools/libxl/libxl_types.idl |   13 +
tools/libxl/xl.h            |    2 
tools/libxl/xl_cmdimpl.c    |  429 +++++++++++++++++++++++++++++++++++++++----
tools/libxl/xl_cmdtable.c   |   29 ++

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0ht-0007uq-Py; Mon, 28 Nov 2011 12:53:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hs-0007sP-3F
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:53:12 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322484755!3333901!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16040 invoked from network); 28 Nov 2011 12:52:35 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:35 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=KYG0IBYx6bqApGK+UXzwA7OuxVN+FfPufOYf/+Ov8ZQRJeOi2k0Vfv/F
	xk8pJigAM6CDzkafpn/yXV759dm44KG0xcRdr3wNM1mIWRMit1dj4/+1I
	Lzi/LpwRPQM9ckofFiviN+U+1dAWhVZZHm49MuKXqWuMXJQEFhLafA5Zp
	ThnLWePM0BMohM4DKhE5O4UKbm3o6SjSOpWWWKvNYB1787OzmVf+fje9e
	cJF0praBclbja+4dBDX8DIA9IB1Zr;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484756; x=1354020756;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=qEchrSo7gMGMxrQ6Rp086wIKVWg47t61AP1sL8bIIR8=;
	b=dFNyQP11Kd/sWcVX9S1ZN3zPe2CZLBN3sgbc7l3YyntbVWUSTiol0QLU
	EohCqXYdZbHoNop6Q5yZdtGFHgtnbBLA95kFjwrDsWtuDTgsXabtkUczy
	rqs1kEVyf5s2sR5Jzvzd8H7YsES1KSNKAW2AruqXf1pDFfBgKpB1qElrq
	T62kQ41jMZww0WW3TwKUC4te0ZJqe8dOXTYsKTw3rZtOqLtkFopuI3FcJ
	q/wB1y7bX+kHMS0E8plqMNgSFEwwr;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342872"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:36 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="123923365"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 3B33295B564;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============7667589256324783455=="
MIME-Version: 1.0
X-Mercurial-Node: 8bb677cf78c3868c96e97962477f229367f01dd6
Message-Id: <8bb677cf78c3868c96e9.1322484361@nehalem1>
In-Reply-To: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:46:01 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 5] Support cpupools in xl sched-credit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7667589256324783455==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Adds cpupool awareness to output of xl sched-credit. Output can now be
restricted to a specific cpupool. The domains are printed for each cpupool
seperately.

The loop over cpupools and domains is seperated from the main command
implementation to be able to support other schedulers as well.

Signed-off-by: juergen.gross@ts.fujitsu.com


5 files changed, 101 insertions(+), 30 deletions(-)
docs/man/xl.pod.1           |    4 +
tools/libxl/libxl.c         |    1 
tools/libxl/libxl_types.idl |    1 
tools/libxl/xl_cmdimpl.c    |  120 ++++++++++++++++++++++++++++++++-----------
tools/libxl/xl_cmdtable.c   |    5 +



--===============7667589256324783455==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-5.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1322483235 -3600
# Node ID 8bb677cf78c3868c96e97962477f229367f01dd6
# Parent  3a817a14e6a29657c8f798987ccb1568a586ea70
Support cpupools in xl sched-credit

Adds cpupool awareness to output of xl sched-credit. Output can now be
restricted to a specific cpupool. The domains are printed for each cpupool
seperately.

The loop over cpupools and domains is seperated from the main command
implementation to be able to support other schedulers as well.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 3a817a14e6a2 -r 8bb677cf78c3 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Nov 28 13:23:31 2011 +0100
+++ b/docs/man/xl.pod.1	Mon Nov 28 13:27:15 2011 +0100
@@ -610,6 +610,10 @@ 50 is half a CPU, 400 is 4 CPUs, etc. Th
 50 is half a CPU, 400 is 4 CPUs, etc. The default, 0, means there is
 no upper cap.
 
+=item B<-p CPUPOOL>, B<--cpupool=CPUPOOL>
+
+Restrict output to domains in the specified cpupool.
+
 =back
 
 =back
diff -r 3a817a14e6a2 -r 8bb677cf78c3 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Nov 28 13:23:31 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Nov 28 13:27:15 2011 +0100
@@ -361,6 +361,7 @@ static void xcinfo2xlinfo(const xc_domai
     xlinfo->cpu_time = xcinfo->cpu_time;
     xlinfo->vcpu_max_id = xcinfo->max_vcpu_id;
     xlinfo->vcpu_online = xcinfo->nr_online_vcpus;
+    xlinfo->cpupool = xcinfo->cpupool;
 }
 
 libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain)
diff -r 3a817a14e6a2 -r 8bb677cf78c3 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Nov 28 13:23:31 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Mon Nov 28 13:27:15 2011 +0100
@@ -109,6 +109,7 @@ SHUTDOWN_* constant."""),
     ("cpu_time",    uint64),
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
+    ("cpupool",     uint32),
     ], dispose_fn=None)
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
diff -r 3a817a14e6a2 -r 8bb677cf78c3 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:23:31 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:27:15 2011 +0100
@@ -3699,25 +3699,90 @@ static int sched_credit_domain_set(
     return rc;
 }
 
-static void sched_credit_domain_output(
-    int domid, libxl_sched_credit *scinfo)
+static int sched_credit_domain_output(
+    int domid)
 {
     char *domname;
+    libxl_sched_credit scinfo;
+    int rc;
+
+    if (domid < 0) {
+        printf("%-33s %4s %6s %4s\n", "Name", "ID", "Weight", "Cap");
+        return 0;
+    }
+    rc = sched_credit_domain_get(domid, &scinfo);
+    if (rc)
+        return rc;
     domname = libxl_domid_to_name(ctx, domid);
     printf("%-33s %4d %6d %4d\n",
         domname,
         domid,
-        scinfo->weight,
-        scinfo->cap);
+        scinfo.weight,
+        scinfo.cap);
     free(domname);
+    return 0;
+}
+
+static int sched_domain_output(
+    uint32_t sched, int (*output)(int), const char *cpupool)
+{
+    libxl_dominfo *info;
+    libxl_cpupoolinfo *poolinfo = NULL;
+    uint32_t poolid;
+    char *poolname;
+    int nb_domain, n_pools = 0, i, p;
+    int rc = 0;
+
+    if (cpupool) {
+        if (cpupool_qualifier_to_cpupoolid(cpupool, &poolid, NULL) ||
+            !libxl_cpupoolid_to_name(ctx, poolid)) {
+            fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
+            return -ERROR_FAIL;
+        }
+    }
+
+    info = libxl_list_domain(ctx, &nb_domain);
+    if (!info) {
+        fprintf(stderr, "libxl_domain_infolist failed.\n");
+        return 1;
+    }
+    poolinfo = libxl_list_cpupool(ctx, &n_pools);
+    if (!poolinfo) {
+        fprintf(stderr, "error getting cpupool info\n");
+        return -ERROR_NOMEM;
+    }
+
+    for (p = 0; !rc && (p < n_pools); p++) {
+        if ((poolinfo[p].sched_id != sched) ||
+            (cpupool && (poolid != poolinfo[p].poolid)))
+            continue;
+
+        poolname = libxl_cpupoolid_to_name(ctx, poolinfo[p].poolid);
+        printf("Cpupool %s:\n", poolname);
+        free(poolname);
+
+        output(-1);
+        for (i = 0; i < nb_domain; i++) {
+            if (info[i].cpupool != poolinfo[p].poolid)
+                continue;
+            rc = output(info[i].domid);
+            if (rc)
+                break;
+        }
+    }
+    if (poolinfo) {
+        for (p = 0; p < n_pools; p++) {
+            libxl_cpupoolinfo_dispose(poolinfo + p);
+        }
+    }
+    return 0;
 }
 
 int main_sched_credit(int argc, char **argv)
 {
-    libxl_dominfo *info;
     libxl_sched_credit scinfo;
-    int nb_domain, i;
-    const char *dom = NULL;
+    const char *dom = NULL;
+    const char *cpupool = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
     int opt, rc;
     int option_index = 0;
@@ -3725,12 +3790,14 @@ int main_sched_credit(int argc, char **a
         {"domain", 1, 0, 'd'},
         {"weight", 1, 0, 'w'},
         {"cap", 1, 0, 'c'},
-        {"help", 0, 0, 'h'},
-        {0, 0, 0, 0}
-    };
-
-    while (1) {
-        opt = getopt_long(argc, argv, "d:w:c:h", long_options, &option_index);
+        {"cpupool", 1, 0, 'p'},
+        {"help", 0, 0, 'h'},
+        {0, 0, 0, 0}
+    };
+
+    while (1) {
+        opt = getopt_long(argc, argv, "d:w:c:p:h", long_options,
+                          &option_index);
         if (opt == -1)
             break;
         switch (opt) {
@@ -3747,31 +3814,28 @@ int main_sched_credit(int argc, char **a
             cap = strtol(optarg, NULL, 10);
             opt_c = 1;
             break;
+        case 'p':
+            cpupool = optarg;
+            break;
         case 'h':
             help("sched-credit");
             return 0;
         }
     }
 
+    if (cpupool && (dom || opt_w || opt_c)) {
+        fprintf(stderr, "Specifying a cpupool is not allowed with other "
+                "options.\n");
+        return 1;
+    }
     if (!dom && (opt_w || opt_c)) {
         fprintf(stderr, "Must specify a domain.\n");
         return 1;
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        info = libxl_list_domain(ctx, &nb_domain);
-        if (!info) {
-            fprintf(stderr, "libxl_domain_infolist failed.\n");
-            return 1;
-        }
-
-        printf("%-33s %4s %6s %4s\n", "Name", "ID", "Weight", "Cap");
-        for (i = 0; i < nb_domain; i++) {
-            rc = sched_credit_domain_get(info[i].domid, &scinfo);
-            if (rc)
-                return -rc;
-            sched_credit_domain_output(info[i].domid, &scinfo);
-        }
+        return -sched_domain_output(XEN_SCHEDULER_CREDIT,
+                                    sched_credit_domain_output, cpupool);
     } else {
         find_domain(dom);
 
@@ -3780,8 +3844,8 @@ int main_sched_credit(int argc, char **a
             return -rc;
 
         if (!opt_w && !opt_c) { /* output credit scheduler info */
-            printf("%-33s %4s %6s %4s\n", "Name", "ID", "Weight", "Cap");
-            sched_credit_domain_output(domid, &scinfo);
+            sched_credit_domain_output(-1);
+            return -sched_credit_domain_output(domid);
         } else { /* set credit scheduler paramaters */
             if (opt_w)
                 scinfo.weight = weight;
diff -r 3a817a14e6a2 -r 8bb677cf78c3 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:23:31 2011 +0100
+++ b/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:27:15 2011 +0100
@@ -192,10 +192,11 @@ struct cmd_spec cmd_table[] = {
     { "sched-credit",
       &main_sched_credit, 0,
       "Get/set credit scheduler parameters",
-      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]]",
+      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-p CPUPOOL]",
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
       "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
-      "-c CAP, --cap=CAP              Cap (int)"
+      "-c CAP, --cap=CAP              Cap (int)\n"
+      "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "domid",
       &main_domid, 0,

--===============7667589256324783455==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7667589256324783455==--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0ht-0007uq-Py; Mon, 28 Nov 2011 12:53:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hs-0007sP-3F
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:53:12 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322484755!3333901!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16040 invoked from network); 28 Nov 2011 12:52:35 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:35 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=KYG0IBYx6bqApGK+UXzwA7OuxVN+FfPufOYf/+Ov8ZQRJeOi2k0Vfv/F
	xk8pJigAM6CDzkafpn/yXV759dm44KG0xcRdr3wNM1mIWRMit1dj4/+1I
	Lzi/LpwRPQM9ckofFiviN+U+1dAWhVZZHm49MuKXqWuMXJQEFhLafA5Zp
	ThnLWePM0BMohM4DKhE5O4UKbm3o6SjSOpWWWKvNYB1787OzmVf+fje9e
	cJF0praBclbja+4dBDX8DIA9IB1Zr;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484756; x=1354020756;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=qEchrSo7gMGMxrQ6Rp086wIKVWg47t61AP1sL8bIIR8=;
	b=dFNyQP11Kd/sWcVX9S1ZN3zPe2CZLBN3sgbc7l3YyntbVWUSTiol0QLU
	EohCqXYdZbHoNop6Q5yZdtGFHgtnbBLA95kFjwrDsWtuDTgsXabtkUczy
	rqs1kEVyf5s2sR5Jzvzd8H7YsES1KSNKAW2AruqXf1pDFfBgKpB1qElrq
	T62kQ41jMZww0WW3TwKUC4te0ZJqe8dOXTYsKTw3rZtOqLtkFopuI3FcJ
	q/wB1y7bX+kHMS0E8plqMNgSFEwwr;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342872"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:36 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="123923365"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 3B33295B564;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============7667589256324783455=="
MIME-Version: 1.0
X-Mercurial-Node: 8bb677cf78c3868c96e97962477f229367f01dd6
Message-Id: <8bb677cf78c3868c96e9.1322484361@nehalem1>
In-Reply-To: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:46:01 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 5] Support cpupools in xl sched-credit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7667589256324783455==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Adds cpupool awareness to output of xl sched-credit. Output can now be
restricted to a specific cpupool. The domains are printed for each cpupool
seperately.

The loop over cpupools and domains is seperated from the main command
implementation to be able to support other schedulers as well.

Signed-off-by: juergen.gross@ts.fujitsu.com


5 files changed, 101 insertions(+), 30 deletions(-)
docs/man/xl.pod.1           |    4 +
tools/libxl/libxl.c         |    1 
tools/libxl/libxl_types.idl |    1 
tools/libxl/xl_cmdimpl.c    |  120 ++++++++++++++++++++++++++++++++-----------
tools/libxl/xl_cmdtable.c   |    5 +



--===============7667589256324783455==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-5.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1322483235 -3600
# Node ID 8bb677cf78c3868c96e97962477f229367f01dd6
# Parent  3a817a14e6a29657c8f798987ccb1568a586ea70
Support cpupools in xl sched-credit

Adds cpupool awareness to output of xl sched-credit. Output can now be
restricted to a specific cpupool. The domains are printed for each cpupool
seperately.

The loop over cpupools and domains is seperated from the main command
implementation to be able to support other schedulers as well.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 3a817a14e6a2 -r 8bb677cf78c3 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Nov 28 13:23:31 2011 +0100
+++ b/docs/man/xl.pod.1	Mon Nov 28 13:27:15 2011 +0100
@@ -610,6 +610,10 @@ 50 is half a CPU, 400 is 4 CPUs, etc. Th
 50 is half a CPU, 400 is 4 CPUs, etc. The default, 0, means there is
 no upper cap.
 
+=item B<-p CPUPOOL>, B<--cpupool=CPUPOOL>
+
+Restrict output to domains in the specified cpupool.
+
 =back
 
 =back
diff -r 3a817a14e6a2 -r 8bb677cf78c3 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Nov 28 13:23:31 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Nov 28 13:27:15 2011 +0100
@@ -361,6 +361,7 @@ static void xcinfo2xlinfo(const xc_domai
     xlinfo->cpu_time = xcinfo->cpu_time;
     xlinfo->vcpu_max_id = xcinfo->max_vcpu_id;
     xlinfo->vcpu_online = xcinfo->nr_online_vcpus;
+    xlinfo->cpupool = xcinfo->cpupool;
 }
 
 libxl_dominfo * libxl_list_domain(libxl_ctx *ctx, int *nb_domain)
diff -r 3a817a14e6a2 -r 8bb677cf78c3 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Nov 28 13:23:31 2011 +0100
+++ b/tools/libxl/libxl_types.idl	Mon Nov 28 13:27:15 2011 +0100
@@ -109,6 +109,7 @@ SHUTDOWN_* constant."""),
     ("cpu_time",    uint64),
     ("vcpu_max_id", uint32),
     ("vcpu_online", uint32),
+    ("cpupool",     uint32),
     ], dispose_fn=None)
 
 libxl_cpupoolinfo = Struct("cpupoolinfo", [
diff -r 3a817a14e6a2 -r 8bb677cf78c3 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:23:31 2011 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 13:27:15 2011 +0100
@@ -3699,25 +3699,90 @@ static int sched_credit_domain_set(
     return rc;
 }
 
-static void sched_credit_domain_output(
-    int domid, libxl_sched_credit *scinfo)
+static int sched_credit_domain_output(
+    int domid)
 {
     char *domname;
+    libxl_sched_credit scinfo;
+    int rc;
+
+    if (domid < 0) {
+        printf("%-33s %4s %6s %4s\n", "Name", "ID", "Weight", "Cap");
+        return 0;
+    }
+    rc = sched_credit_domain_get(domid, &scinfo);
+    if (rc)
+        return rc;
     domname = libxl_domid_to_name(ctx, domid);
     printf("%-33s %4d %6d %4d\n",
         domname,
         domid,
-        scinfo->weight,
-        scinfo->cap);
+        scinfo.weight,
+        scinfo.cap);
     free(domname);
+    return 0;
+}
+
+static int sched_domain_output(
+    uint32_t sched, int (*output)(int), const char *cpupool)
+{
+    libxl_dominfo *info;
+    libxl_cpupoolinfo *poolinfo = NULL;
+    uint32_t poolid;
+    char *poolname;
+    int nb_domain, n_pools = 0, i, p;
+    int rc = 0;
+
+    if (cpupool) {
+        if (cpupool_qualifier_to_cpupoolid(cpupool, &poolid, NULL) ||
+            !libxl_cpupoolid_to_name(ctx, poolid)) {
+            fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
+            return -ERROR_FAIL;
+        }
+    }
+
+    info = libxl_list_domain(ctx, &nb_domain);
+    if (!info) {
+        fprintf(stderr, "libxl_domain_infolist failed.\n");
+        return 1;
+    }
+    poolinfo = libxl_list_cpupool(ctx, &n_pools);
+    if (!poolinfo) {
+        fprintf(stderr, "error getting cpupool info\n");
+        return -ERROR_NOMEM;
+    }
+
+    for (p = 0; !rc && (p < n_pools); p++) {
+        if ((poolinfo[p].sched_id != sched) ||
+            (cpupool && (poolid != poolinfo[p].poolid)))
+            continue;
+
+        poolname = libxl_cpupoolid_to_name(ctx, poolinfo[p].poolid);
+        printf("Cpupool %s:\n", poolname);
+        free(poolname);
+
+        output(-1);
+        for (i = 0; i < nb_domain; i++) {
+            if (info[i].cpupool != poolinfo[p].poolid)
+                continue;
+            rc = output(info[i].domid);
+            if (rc)
+                break;
+        }
+    }
+    if (poolinfo) {
+        for (p = 0; p < n_pools; p++) {
+            libxl_cpupoolinfo_dispose(poolinfo + p);
+        }
+    }
+    return 0;
 }
 
 int main_sched_credit(int argc, char **argv)
 {
-    libxl_dominfo *info;
     libxl_sched_credit scinfo;
-    int nb_domain, i;
-    const char *dom = NULL;
+    const char *dom = NULL;
+    const char *cpupool = NULL;
     int weight = 256, cap = 0, opt_w = 0, opt_c = 0;
     int opt, rc;
     int option_index = 0;
@@ -3725,12 +3790,14 @@ int main_sched_credit(int argc, char **a
         {"domain", 1, 0, 'd'},
         {"weight", 1, 0, 'w'},
         {"cap", 1, 0, 'c'},
-        {"help", 0, 0, 'h'},
-        {0, 0, 0, 0}
-    };
-
-    while (1) {
-        opt = getopt_long(argc, argv, "d:w:c:h", long_options, &option_index);
+        {"cpupool", 1, 0, 'p'},
+        {"help", 0, 0, 'h'},
+        {0, 0, 0, 0}
+    };
+
+    while (1) {
+        opt = getopt_long(argc, argv, "d:w:c:p:h", long_options,
+                          &option_index);
         if (opt == -1)
             break;
         switch (opt) {
@@ -3747,31 +3814,28 @@ int main_sched_credit(int argc, char **a
             cap = strtol(optarg, NULL, 10);
             opt_c = 1;
             break;
+        case 'p':
+            cpupool = optarg;
+            break;
         case 'h':
             help("sched-credit");
             return 0;
         }
     }
 
+    if (cpupool && (dom || opt_w || opt_c)) {
+        fprintf(stderr, "Specifying a cpupool is not allowed with other "
+                "options.\n");
+        return 1;
+    }
     if (!dom && (opt_w || opt_c)) {
         fprintf(stderr, "Must specify a domain.\n");
         return 1;
     }
 
     if (!dom) { /* list all domain's credit scheduler info */
-        info = libxl_list_domain(ctx, &nb_domain);
-        if (!info) {
-            fprintf(stderr, "libxl_domain_infolist failed.\n");
-            return 1;
-        }
-
-        printf("%-33s %4s %6s %4s\n", "Name", "ID", "Weight", "Cap");
-        for (i = 0; i < nb_domain; i++) {
-            rc = sched_credit_domain_get(info[i].domid, &scinfo);
-            if (rc)
-                return -rc;
-            sched_credit_domain_output(info[i].domid, &scinfo);
-        }
+        return -sched_domain_output(XEN_SCHEDULER_CREDIT,
+                                    sched_credit_domain_output, cpupool);
     } else {
         find_domain(dom);
 
@@ -3780,8 +3844,8 @@ int main_sched_credit(int argc, char **a
             return -rc;
 
         if (!opt_w && !opt_c) { /* output credit scheduler info */
-            printf("%-33s %4s %6s %4s\n", "Name", "ID", "Weight", "Cap");
-            sched_credit_domain_output(domid, &scinfo);
+            sched_credit_domain_output(-1);
+            return -sched_credit_domain_output(domid);
         } else { /* set credit scheduler paramaters */
             if (opt_w)
                 scinfo.weight = weight;
diff -r 3a817a14e6a2 -r 8bb677cf78c3 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:23:31 2011 +0100
+++ b/tools/libxl/xl_cmdtable.c	Mon Nov 28 13:27:15 2011 +0100
@@ -192,10 +192,11 @@ struct cmd_spec cmd_table[] = {
     { "sched-credit",
       &main_sched_credit, 0,
       "Get/set credit scheduler parameters",
-      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]]",
+      "[-d <Domain> [-w[=WEIGHT]|-c[=CAP]]] [-p CPUPOOL]",
       "-d DOMAIN, --domain=DOMAIN     Domain to modify\n"
       "-w WEIGHT, --weight=WEIGHT     Weight (int)\n"
-      "-c CAP, --cap=CAP              Cap (int)"
+      "-c CAP, --cap=CAP              Cap (int)\n"
+      "-p CPUPOOL, --cpupool=CPUPOOL  Restrict output to CPUPOOL"
     },
     { "domid",
       &main_domid, 0,

--===============7667589256324783455==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7667589256324783455==--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0ht-0007ua-98; Mon, 28 Nov 2011 12:53:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hr-0007sM-Vx
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:53:12 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322484755!3333901!2
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16051 invoked from network); 28 Nov 2011 12:52:35 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:35 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=vN39MJfgDd9Q9DEV5BejC/9Z2LVmMtxbhJJLW2eEK5cED4kL42dqYnSz
	+A5CinCQDCUGEE2TEEsAh4LZ8uyWizqO2qpBpcxIMt9EpxT8Nx4WhdY+3
	CA0kTaKZLuCpK8ZniuE3+T4inohEhlDMGVFRkTJJcWgULSFQersMF9QHq
	HrNx59WifKafFLjRY7CFTZ5tfhHKGBWnSRg5Tajkgz2OeKCoKczLOs1E7
	gIHdWGRgMvoFs9wLo6sdYNLLbzzzZ;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484756; x=1354020756;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=lmi2MZzHvgInq+Yd7ovmOxkLMFb3E8O/lsQiaLi6/KE=;
	b=vHuR140NClD9sS8O4l8n/lE7zjm+0NC8aXnX1rSbTJeHQiLkUNUGfpSl
	YkTfZEoILmFk0vZHhGcwHZwGK4cmiZvz1QelZfpGqlrNUfKlJ5fF2aU0p
	hXI+/JA8FQ09gdXHllVTiHOVkgir3NgXKe3XxROK7vjucsK786KbntFEf
	vTELGoexm81s7Cng0U9IEp+owQ2bWnfshJ1l8z5An06SW201xve74ihi2
	1jWvpTlc+ZCHncn+j7LD/mUqrjIDK;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342874"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:36 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="123923366"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 554E695B564;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============3848021963136984830=="
MIME-Version: 1.0
X-Mercurial-Node: 40d8819d98ff7a1fb6d1992ad35d980f1a7d6876
Message-Id: <40d8819d98ff7a1fb6d1.1322484363@nehalem1>
In-Reply-To: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:46:03 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 5] Correct error message
	in	libxl_sched_credit_domain_get()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3848021963136984830==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Just a typo...

Signed-off-by: juergen.gross@ts.fujitsu.com


1 file changed, 1 insertion(+), 1 deletion(-)
tools/libxl/libxl.c |    2 +-



--===============3848021963136984830==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-5.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1322483497 -3600
# Node ID 40d8819d98ff7a1fb6d1992ad35d980f1a7d6876
# Parent  442f86914b6027a3b7e484a46970834c1673b8d7
Correct error message in libxl_sched_credit_domain_get()

Just a typo...

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 442f86914b60 -r 40d8819d98ff tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Nov 28 13:31:27 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Nov 28 13:31:37 2011 +0100
@@ -2679,7 +2679,7 @@ int libxl_sched_credit_domain_get(libxl_
 
     rc = xc_sched_credit_domain_get(ctx->xch, domid, &sdom);
     if (rc != 0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting domain sched credit");
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain sched credit");
         return ERROR_FAIL;
     }
 

--===============3848021963136984830==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3848021963136984830==--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 12:53:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 12:53:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0ht-0007ua-98; Mon, 28 Nov 2011 12:53:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RV0hr-0007sM-Vx
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 12:53:12 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322484755!3333901!2
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMzk5Mw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16051 invoked from network); 28 Nov 2011 12:52:35 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 12:52:35 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=vN39MJfgDd9Q9DEV5BejC/9Z2LVmMtxbhJJLW2eEK5cED4kL42dqYnSz
	+A5CinCQDCUGEE2TEEsAh4LZ8uyWizqO2qpBpcxIMt9EpxT8Nx4WhdY+3
	CA0kTaKZLuCpK8ZniuE3+T4inohEhlDMGVFRkTJJcWgULSFQersMF9QHq
	HrNx59WifKafFLjRY7CFTZ5tfhHKGBWnSRg5Tajkgz2OeKCoKczLOs1E7
	gIHdWGRgMvoFs9wLo6sdYNLLbzzzZ;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=juergen.gross@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1322484756; x=1354020756;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=lmi2MZzHvgInq+Yd7ovmOxkLMFb3E8O/lsQiaLi6/KE=;
	b=vHuR140NClD9sS8O4l8n/lE7zjm+0NC8aXnX1rSbTJeHQiLkUNUGfpSl
	YkTfZEoILmFk0vZHhGcwHZwGK4cmiZvz1QelZfpGqlrNUfKlJ5fF2aU0p
	hXI+/JA8FQ09gdXHllVTiHOVkgir3NgXKe3XxROK7vjucsK786KbntFEf
	vTELGoexm81s7Cng0U9IEp+owQ2bWnfshJ1l8z5An06SW201xve74ihi2
	1jWvpTlc+ZCHncn+j7LD/mUqrjIDK;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="94342874"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:36 +0100
X-IronPort-AV: E=Sophos;i="4.69,583,1315173600"; d="scan'208";a="123923366"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 28 Nov 2011 13:52:13 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 554E695B564;
	Mon, 28 Nov 2011 13:52:13 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============3848021963136984830=="
MIME-Version: 1.0
X-Mercurial-Node: 40d8819d98ff7a1fb6d1992ad35d980f1a7d6876
Message-Id: <40d8819d98ff7a1fb6d1.1322484363@nehalem1>
In-Reply-To: <patchbomb.1322484359@nehalem1>
Date: Mon, 28 Nov 2011 13:46:03 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 4 of 5] Correct error message
	in	libxl_sched_credit_domain_get()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3848021963136984830==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

Just a typo...

Signed-off-by: juergen.gross@ts.fujitsu.com


1 file changed, 1 insertion(+), 1 deletion(-)
tools/libxl/libxl.c |    2 +-



--===============3848021963136984830==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-5.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1322483497 -3600
# Node ID 40d8819d98ff7a1fb6d1992ad35d980f1a7d6876
# Parent  442f86914b6027a3b7e484a46970834c1673b8d7
Correct error message in libxl_sched_credit_domain_get()

Just a typo...

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 442f86914b60 -r 40d8819d98ff tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Nov 28 13:31:27 2011 +0100
+++ b/tools/libxl/libxl.c	Mon Nov 28 13:31:37 2011 +0100
@@ -2679,7 +2679,7 @@ int libxl_sched_credit_domain_get(libxl_
 
     rc = xc_sched_credit_domain_get(ctx->xch, domid, &sdom);
     if (rc != 0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting domain sched credit");
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain sched credit");
         return ERROR_FAIL;
     }
 

--===============3848021963136984830==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3848021963136984830==--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:09:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0xY-0000W0-8S; Mon, 28 Nov 2011 13:09:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV0xW-0000Vv-9c
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:09:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322485726!4955074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7387 invoked from network); 28 Nov 2011 13:08:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 13:08:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9161844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 13:08:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 13:08:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 13:08:45 +0000
In-Reply-To: <20179.32337.102834.867932@mariner.uk.xensource.com>
References: <20179.32337.102834.867932@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322485725.1005.290.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: open logs with O_APPEND
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 12:28 +0000, Ian Jackson wrote:
> Logfiles should always be opened for append.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Both this and the 2/2 patch look sensible to me and are:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> diff -r a9c67c2daf4b tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Mon Nov 28 11:57:23 2011 +0000
> +++ b/tools/libxl/libxl_dm.c	Mon Nov 28 12:25:52 2011 +0000
> @@ -830,7 +830,7 @@ int libxl__create_device_model(libxl__gc
>      libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
>  
>      libxl_create_logfile(ctx, libxl__sprintf(gc, "qemu-dm-%s", info->dom_name), &logfile);
> -    logfile_w = open(logfile, O_WRONLY|O_CREAT, 0644);
> +    logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
>      free(logfile);
>      null = open("/dev/null", O_RDONLY);
>  
> diff -r a9c67c2daf4b tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 11:57:23 2011 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 12:25:52 2011 +0000
> @@ -1597,7 +1597,8 @@ start:
>              exit(-1);
>          }
>  
> -        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT, 0644) )<0);
> +        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT|O_APPEND,
> +                                   0644) )<0);

fullname here came from libxl_create_logfile so has been rotated such
that the file will be empty. I don't think O_APPEND is harmful or wrong
given this though.

Do we need to arrange for libxl_create_logfile to be called for some of
these others though?

Ian.

>          free(fullname);
>          free(name);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:09:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:09:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV0xY-0000W0-8S; Mon, 28 Nov 2011 13:09:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV0xW-0000Vv-9c
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:09:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322485726!4955074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7387 invoked from network); 28 Nov 2011 13:08:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 13:08:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9161844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 13:08:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 13:08:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 13:08:45 +0000
In-Reply-To: <20179.32337.102834.867932@mariner.uk.xensource.com>
References: <20179.32337.102834.867932@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322485725.1005.290.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: open logs with O_APPEND
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 12:28 +0000, Ian Jackson wrote:
> Logfiles should always be opened for append.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Both this and the 2/2 patch look sensible to me and are:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> diff -r a9c67c2daf4b tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Mon Nov 28 11:57:23 2011 +0000
> +++ b/tools/libxl/libxl_dm.c	Mon Nov 28 12:25:52 2011 +0000
> @@ -830,7 +830,7 @@ int libxl__create_device_model(libxl__gc
>      libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
>  
>      libxl_create_logfile(ctx, libxl__sprintf(gc, "qemu-dm-%s", info->dom_name), &logfile);
> -    logfile_w = open(logfile, O_WRONLY|O_CREAT, 0644);
> +    logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
>      free(logfile);
>      null = open("/dev/null", O_RDONLY);
>  
> diff -r a9c67c2daf4b tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Nov 28 11:57:23 2011 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Nov 28 12:25:52 2011 +0000
> @@ -1597,7 +1597,8 @@ start:
>              exit(-1);
>          }
>  
> -        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT, 0644) )<0);
> +        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT|O_APPEND,
> +                                   0644) )<0);

fullname here came from libxl_create_logfile so has been rotated such
that the file will be empty. I don't think O_APPEND is harmful or wrong
given this though.

Do we need to arrange for libxl_create_logfile to be called for some of
these others though?

Ian.

>          free(fullname);
>          free(name);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:23:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1AZ-0000he-K9; Mon, 28 Nov 2011 13:22:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV1AY-0000hW-2f
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:22:50 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322486533!4437112!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23476 invoked from network); 28 Nov 2011 13:22:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 13:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9162130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 13:21:44 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 28 Nov 2011
	13:21:44 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Mon, 28 Nov 2011 13:21:47 +0000
Thread-Topic: [Xen-devel] [PATCH 2 of 5] Add 'ctype' infrastructure to
	hvmloader
Thread-Index: AcytyTewmCRdwQ7fQPaKBPl5N9PYiAABzmag
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4DC6@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<b383a1053d1d5e598bb3.1322482534@cosworth.uk.xensource.com>
	<20111128122817.GA79829@ocelot.phlegethon.org>
In-Reply-To: <20111128122817.GA79829@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 5] Add 'ctype' infrastructure to
 hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: 28 November 2011 12:28
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2 of 5] Add 'ctype' infrastructure
> to hvmloader
> 
> At 12:15 +0000 on 28 Nov (1322482534), Paul Durrant wrote:
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1322482488 0
> #
> > Node ID b383a1053d1d5e598bb39923eee8cec57e5666e9
> > # Parent  346b54217c4c3fcdebfde41d636d0ec1c11a7672
> > Add 'ctype' infrastructure to hvmloader.
> 
> Where did this ctype code come from?  Is it appropriately licensed?
> 

Tim,

It's the minios one that's already in the Xen mercurial repo. which IIRC is BSD licensed, so I thought it was a reasonably safe one to grab.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:23:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1AZ-0000he-K9; Mon, 28 Nov 2011 13:22:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV1AY-0000hW-2f
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:22:50 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322486533!4437112!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23476 invoked from network); 28 Nov 2011 13:22:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 13:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9162130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 13:21:44 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 28 Nov 2011
	13:21:44 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Mon, 28 Nov 2011 13:21:47 +0000
Thread-Topic: [Xen-devel] [PATCH 2 of 5] Add 'ctype' infrastructure to
	hvmloader
Thread-Index: AcytyTewmCRdwQ7fQPaKBPl5N9PYiAABzmag
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4DC6@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<b383a1053d1d5e598bb3.1322482534@cosworth.uk.xensource.com>
	<20111128122817.GA79829@ocelot.phlegethon.org>
In-Reply-To: <20111128122817.GA79829@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 5] Add 'ctype' infrastructure to
 hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: 28 November 2011 12:28
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2 of 5] Add 'ctype' infrastructure
> to hvmloader
> 
> At 12:15 +0000 on 28 Nov (1322482534), Paul Durrant wrote:
> > # HG changeset patch
> > # User Paul Durrant <paul.durrant@citrix.com> # Date 1322482488 0
> #
> > Node ID b383a1053d1d5e598bb39923eee8cec57e5666e9
> > # Parent  346b54217c4c3fcdebfde41d636d0ec1c11a7672
> > Add 'ctype' infrastructure to hvmloader.
> 
> Where did this ctype code come from?  Is it appropriately licensed?
> 

Tim,

It's the minios one that's already in the Xen mercurial repo. which IIRC is BSD licensed, so I thought it was a reasonably safe one to grab.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:27:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1EN-0000qB-9g; Mon, 28 Nov 2011 13:26:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV1EM-0000pp-8g
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:26:46 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322486768!6078211!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6806 invoked from network); 28 Nov 2011 13:26:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 13:26:09 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9162229"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 13:26:07 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 28 Nov 2011
	13:26:07 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Mon, 28 Nov 2011 13:26:11 +0000
Thread-Topic: [Xen-devel] [PATCH 4 of 5] Add code to track the address of
	the VM generation id buffer across a
Thread-Index: AcytyddVoC9Bm7GlRZWD/nHfI4BDywABttug
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4DCC@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
	<20111128123246.GB79829@ocelot.phlegethon.org>
In-Reply-To: <20111128123246.GB79829@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] Add code to track the address of the
 VM generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: 28 November 2011 12:33
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 4 of 5] Add code to track the
> address of the VM generation id buffer across a
> 
> At 12:15 +0000 on 28 Nov (1322482536), Paul Durrant wrote:
> > --- a/xen/include/public/hvm/params.h	Mon Nov 28 12:14:48 2011
> +0000
> > +++ b/xen/include/public/hvm/params.h	Mon Nov 28 12:14:49 2011
> +0000
> > @@ -142,6 +142,9 @@
> >  /* Boolean: Enable nestedhvm (hvm only) */
> >  #define HVM_PARAM_NESTEDHVM    24
> >
> > -#define HVM_NR_PARAMS          27
> > +/* Address of VM generation id buffer */ #define
> > +HVM_PARAM_VM_GENERATION_ID_ADDR 27
> > +
> > +#define HVM_NR_PARAMS          28
> >
> >  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> 
> Since the hypervisor doesn't use this value, I don't think this is
> the right place for it to live.  Tools-only VM metadata should
> probably go in xenstore or in the toolstacks' own datastructures.
> 

Yes, I was a little unsure about that. Is there any precedent for getting information from hvmloader out to the tools? Writing guest physical addresses into xenstore seems like the wrong thing to but apart from HVM params or the shared hvm info page, I couldn't think of another way apart from putting the VM generation id in a static well-known place.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:27:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:27:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1EN-0000qB-9g; Mon, 28 Nov 2011 13:26:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV1EM-0000pp-8g
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:26:46 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322486768!6078211!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6806 invoked from network); 28 Nov 2011 13:26:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 13:26:09 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9162229"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 13:26:07 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 28 Nov 2011
	13:26:07 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Mon, 28 Nov 2011 13:26:11 +0000
Thread-Topic: [Xen-devel] [PATCH 4 of 5] Add code to track the address of
	the VM generation id buffer across a
Thread-Index: AcytyddVoC9Bm7GlRZWD/nHfI4BDywABttug
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4DCC@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
	<20111128123246.GB79829@ocelot.phlegethon.org>
In-Reply-To: <20111128123246.GB79829@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] Add code to track the address of the
 VM generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xen.org]
> Sent: 28 November 2011 12:33
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 4 of 5] Add code to track the
> address of the VM generation id buffer across a
> 
> At 12:15 +0000 on 28 Nov (1322482536), Paul Durrant wrote:
> > --- a/xen/include/public/hvm/params.h	Mon Nov 28 12:14:48 2011
> +0000
> > +++ b/xen/include/public/hvm/params.h	Mon Nov 28 12:14:49 2011
> +0000
> > @@ -142,6 +142,9 @@
> >  /* Boolean: Enable nestedhvm (hvm only) */
> >  #define HVM_PARAM_NESTEDHVM    24
> >
> > -#define HVM_NR_PARAMS          27
> > +/* Address of VM generation id buffer */ #define
> > +HVM_PARAM_VM_GENERATION_ID_ADDR 27
> > +
> > +#define HVM_NR_PARAMS          28
> >
> >  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> 
> Since the hypervisor doesn't use this value, I don't think this is
> the right place for it to live.  Tools-only VM metadata should
> probably go in xenstore or in the toolstacks' own datastructures.
> 

Yes, I was a little unsure about that. Is there any precedent for getting information from hvmloader out to the tools? Writing guest physical addresses into xenstore seems like the wrong thing to but apart from HVM params or the shared hvm info page, I couldn't think of another way apart from putting the VM generation id in a static well-known place.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:39:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1Qa-00018Q-JH; Mon, 28 Nov 2011 13:39:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV1QY-00018J-T2
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:39:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322487526!4973426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20941 invoked from network); 28 Nov 2011 13:38:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 13:38:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9162526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 13:38:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 13:38:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 13:38:45 +0000
In-Reply-To: <20179.30537.970866.190935@mariner.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322487525.1005.293.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 11:58 +0000, Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 10135: regressions - FAIL"):
> > flight 10135 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/10135/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking:
> >  test-amd64-i386-rhel6hvm-intel  7 redhat-install       fail REGR. vs. 9956
> 
> My bisector wasn't able to finger an exact changeset due to a blocking
> bug in the vicinity, but:
> 
>   pass      24183:53bec838bb08  Merge
>   blocked   24184:4ecd3615e726  tools: use system installed libaio by default.
>   blocked   24185:f88c745575bb  docs: remove some fatally out of date ...
>   fail      24186:7aa5838499d1  tools: use system libaio for blktap1 as well.
> 
> Here the "system installed libaio" is that from Debian squeeze.

This is really weird since nothing in the failings tests even exercises
this stuff. Only blktap (1 and 2) uses aio and the the tests don't use
it and neither does qemu-dm which is the only other thing I can think
of. I'm setting up a repro to see if I can figure out what is going
wrong.

> So for now I have applied the changeset below in the hope of getting a
> pass and push.

I think that's best for now.

Ian.

> 
> Ian.
> 
> # HG changeset patch
> # User Ian Jackson <Ian.Jackson@eu.citrix.com>
> # Date 1322481443 0
> # Node ID a9c67c2daf4b0181ef2581471ea920eecb495616
> # Parent  95d4e2e0bed374602b5a78ee004b057ad8715d65
> tools: Revert to our built-in aio
> 
> These two changesets:
>    24184:4ecd3615e726  tools: use system installed libaio by default.
>    24186:7aa5838499d1  tools: use system libaio for blktap1 as well.
> cause HVM guest installs (both Windows and Redhat) to fail on Debian
> squeeze with xl.  So change the default for now.
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff -r 95d4e2e0bed3 -r a9c67c2daf4b Config.mk
> --- a/Config.mk	Fri Nov 25 20:32:05 2011 +0000
> +++ b/Config.mk	Mon Nov 28 11:57:23 2011 +0000
> @@ -232,7 +232,7 @@ PYTHON_TOOLS       ?= y
>  OCAML_TOOLS        ?= y
>  CONFIG_MINITERM    ?= n
>  CONFIG_LOMOUNT     ?= n
> -CONFIG_SYSTEM_LIBAIO ?= y
> +CONFIG_SYSTEM_LIBAIO ?= n
>  
>  ifeq ($(OCAML_TOOLS),y)
>  OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:39:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:39:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1Qa-00018Q-JH; Mon, 28 Nov 2011 13:39:24 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV1QY-00018J-T2
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:39:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322487526!4973426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20941 invoked from network); 28 Nov 2011 13:38:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 13:38:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9162526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 13:38:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 13:38:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 13:38:45 +0000
In-Reply-To: <20179.30537.970866.190935@mariner.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322487525.1005.293.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 11:58 +0000, Ian Jackson wrote:
> xen.org writes ("[xen-unstable test] 10135: regressions - FAIL"):
> > flight 10135 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/10135/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking:
> >  test-amd64-i386-rhel6hvm-intel  7 redhat-install       fail REGR. vs. 9956
> 
> My bisector wasn't able to finger an exact changeset due to a blocking
> bug in the vicinity, but:
> 
>   pass      24183:53bec838bb08  Merge
>   blocked   24184:4ecd3615e726  tools: use system installed libaio by default.
>   blocked   24185:f88c745575bb  docs: remove some fatally out of date ...
>   fail      24186:7aa5838499d1  tools: use system libaio for blktap1 as well.
> 
> Here the "system installed libaio" is that from Debian squeeze.

This is really weird since nothing in the failings tests even exercises
this stuff. Only blktap (1 and 2) uses aio and the the tests don't use
it and neither does qemu-dm which is the only other thing I can think
of. I'm setting up a repro to see if I can figure out what is going
wrong.

> So for now I have applied the changeset below in the hope of getting a
> pass and push.

I think that's best for now.

Ian.

> 
> Ian.
> 
> # HG changeset patch
> # User Ian Jackson <Ian.Jackson@eu.citrix.com>
> # Date 1322481443 0
> # Node ID a9c67c2daf4b0181ef2581471ea920eecb495616
> # Parent  95d4e2e0bed374602b5a78ee004b057ad8715d65
> tools: Revert to our built-in aio
> 
> These two changesets:
>    24184:4ecd3615e726  tools: use system installed libaio by default.
>    24186:7aa5838499d1  tools: use system libaio for blktap1 as well.
> cause HVM guest installs (both Windows and Redhat) to fail on Debian
> squeeze with xl.  So change the default for now.
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff -r 95d4e2e0bed3 -r a9c67c2daf4b Config.mk
> --- a/Config.mk	Fri Nov 25 20:32:05 2011 +0000
> +++ b/Config.mk	Mon Nov 28 11:57:23 2011 +0000
> @@ -232,7 +232,7 @@ PYTHON_TOOLS       ?= y
>  OCAML_TOOLS        ?= y
>  CONFIG_MINITERM    ?= n
>  CONFIG_LOMOUNT     ?= n
> -CONFIG_SYSTEM_LIBAIO ?= y
> +CONFIG_SYSTEM_LIBAIO ?= n
>  
>  ifeq ($(OCAML_TOOLS),y)
>  OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1a5-0001J0-NK; Mon, 28 Nov 2011 13:49:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RV1a5-0001Iv-6O
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:49:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322488116!5289557!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19774 invoked from network); 28 Nov 2011 13:48:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 13:48:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RV1ZS-000LPd-Dr; Mon, 28 Nov 2011 13:48:34 +0000
Date: Mon, 28 Nov 2011 13:48:34 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20111128134834.GC79829@ocelot.phlegethon.org>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
	<20111128123246.GB79829@ocelot.phlegethon.org>
	<291EDFCB1E9E224A99088639C4762022B5988E4DCC@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4DCC@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] Add code to track the address of the
	VM generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 13:26 +0000 on 28 Nov (1322486771), Paul Durrant wrote:
> > > +/* Address of VM generation id buffer */ #define
> > > +HVM_PARAM_VM_GENERATION_ID_ADDR 27
> > > +
> > > +#define HVM_NR_PARAMS          28
> > >
> > >  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> > 
> > Since the hypervisor doesn't use this value, I don't think this is
> > the right place for it to live.  Tools-only VM metadata should
> > probably go in xenstore or in the toolstacks' own datastructures.
> > 
> 
> Yes, I was a little unsure about that. Is there any precedent for
> getting information from hvmloader out to the tools? Writing guest
> physical addresses into xenstore seems like the wrong thing to but
> apart from HVM params or the shared hvm info page, I couldn't think of
> another way apart from putting the VM generation id in a static
> well-known place. 

Presumably in this case the tools can find the address by walking the
ACPI tables, just like the guest OS would. :P  Not very pretty, though. 

I don't think there's anything wrong with putting a GPA into
xenstore.  All the other tools interactions are in guest-physical
addressing already.  IIRC HVMloader's xenbus client doesn't have a
xenstore_write() but it shouldn't be hard to add.  

I can't think of another way to pass data from hvmloader to the
tools right now -- I think the hvm-info page should probably be
replaced entirely with xenstore keys at some point. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1a5-0001J0-NK; Mon, 28 Nov 2011 13:49:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RV1a5-0001Iv-6O
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:49:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322488116!5289557!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19774 invoked from network); 28 Nov 2011 13:48:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 13:48:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RV1ZS-000LPd-Dr; Mon, 28 Nov 2011 13:48:34 +0000
Date: Mon, 28 Nov 2011 13:48:34 +0000
From: Tim Deegan <tim@xen.org>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20111128134834.GC79829@ocelot.phlegethon.org>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
	<20111128123246.GB79829@ocelot.phlegethon.org>
	<291EDFCB1E9E224A99088639C4762022B5988E4DCC@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4DCC@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] Add code to track the address of the
	VM generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 13:26 +0000 on 28 Nov (1322486771), Paul Durrant wrote:
> > > +/* Address of VM generation id buffer */ #define
> > > +HVM_PARAM_VM_GENERATION_ID_ADDR 27
> > > +
> > > +#define HVM_NR_PARAMS          28
> > >
> > >  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> > 
> > Since the hypervisor doesn't use this value, I don't think this is
> > the right place for it to live.  Tools-only VM metadata should
> > probably go in xenstore or in the toolstacks' own datastructures.
> > 
> 
> Yes, I was a little unsure about that. Is there any precedent for
> getting information from hvmloader out to the tools? Writing guest
> physical addresses into xenstore seems like the wrong thing to but
> apart from HVM params or the shared hvm info page, I couldn't think of
> another way apart from putting the VM generation id in a static
> well-known place. 

Presumably in this case the tools can find the address by walking the
ACPI tables, just like the guest OS would. :P  Not very pretty, though. 

I don't think there's anything wrong with putting a GPA into
xenstore.  All the other tools interactions are in guest-physical
addressing already.  IIRC HVMloader's xenbus client doesn't have a
xenstore_write() but it shouldn't be hard to add.  

I can't think of another way to pass data from hvmloader to the
tools right now -- I think the hvm-info page should probably be
replaced entirely with xenstore keys at some point. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:50:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:50:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1au-0001LC-5h; Mon, 28 Nov 2011 13:50:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RV1at-0001Kz-4T
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:50:03 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322488165!3384057!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32605 invoked from network); 28 Nov 2011 13:49:25 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-8.tower-174.messagelabs.com with SMTP;
	28 Nov 2011 13:49:25 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 508D01AAE0B;
	Mon, 28 Nov 2011 14:49:24 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id 8qyCdep02v-G; Mon, 28 Nov 2011 14:49:24 +0100 (CET)
Received: from [10.0.0.1] (p5DCB7919.dip.t-dialin.net [93.203.121.25])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Mon, 28 Nov 2011 14:49:24 +0100 (CET)
Message-ID: <4ED39164.5040203@hfp.de>
Date: Mon, 28 Nov 2011 14:49:24 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>, 
	xen-devel@lists.xensource.com
Subject: [Xen-devel] State of GPLPV tests - 28.11.11
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello James,

I am still running tests 7 days a week on two test systems. Results are 
quite discouraging though. After experiencing crash after crash I wanted 
to test if the configuration I called "stable" (Xen 4.0.1, GPLPV 
0.11.0.213, dom0 kernel 2.6.32.18-pvops0-ak3) was stable indeed. But 
even that config crashed when running my torture test. It is stable on 
our production systems - running other workloads of course.

 > One thing I thought of... virtualisation gives an interesting
 > opportunity to exaggerate race conditions. If you have 8 vCPU's in a
 > DomU but only let one or two physical CPUs service those 8 vCPU's,then
 > it can give rise to race conditions which could only be rarely seen
 > (or never seen) in normal operation. It's awful for performance but
 > if you could try that and see if it gives rise to crashes a bit
 > more frequently it might help us track down the problem.

What exactly is the config you are talking about in terms of Xen/dom0 
command line? In terms of domU config files?

As always, I monitor your mercurial repo ;-) How would you see the 
relationship of commits 952+953 to our problem? 952 seems to affect LSO 
in some way since LsoV1TransmitComplete.TcpPayload is finally wrong 
(could it be negative since tx_length is smaller than the fixed 
tx_length?). What about 953?

One more thought: As mentioned earlier crashes often occurred after an 
uptime of 9-10 days and these crashes occurred too consistently to be a 
"by chance" event. In my torture tests I am NOT USING a Windows NTP 
service (I use the meinberg NTP daemon on Windows). But on production I 
do. Can you see any possible impact here?

Regards Andreas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:50:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:50:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1au-0001LC-5h; Mon, 28 Nov 2011 13:50:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RV1at-0001Kz-4T
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:50:03 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322488165!3384057!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32605 invoked from network); 28 Nov 2011 13:49:25 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-8.tower-174.messagelabs.com with SMTP;
	28 Nov 2011 13:49:25 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 508D01AAE0B;
	Mon, 28 Nov 2011 14:49:24 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id 8qyCdep02v-G; Mon, 28 Nov 2011 14:49:24 +0100 (CET)
Received: from [10.0.0.1] (p5DCB7919.dip.t-dialin.net [93.203.121.25])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Mon, 28 Nov 2011 14:49:24 +0100 (CET)
Message-ID: <4ED39164.5040203@hfp.de>
Date: Mon, 28 Nov 2011 14:49:24 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>, 
	xen-devel@lists.xensource.com
Subject: [Xen-devel] State of GPLPV tests - 28.11.11
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello James,

I am still running tests 7 days a week on two test systems. Results are 
quite discouraging though. After experiencing crash after crash I wanted 
to test if the configuration I called "stable" (Xen 4.0.1, GPLPV 
0.11.0.213, dom0 kernel 2.6.32.18-pvops0-ak3) was stable indeed. But 
even that config crashed when running my torture test. It is stable on 
our production systems - running other workloads of course.

 > One thing I thought of... virtualisation gives an interesting
 > opportunity to exaggerate race conditions. If you have 8 vCPU's in a
 > DomU but only let one or two physical CPUs service those 8 vCPU's,then
 > it can give rise to race conditions which could only be rarely seen
 > (or never seen) in normal operation. It's awful for performance but
 > if you could try that and see if it gives rise to crashes a bit
 > more frequently it might help us track down the problem.

What exactly is the config you are talking about in terms of Xen/dom0 
command line? In terms of domU config files?

As always, I monitor your mercurial repo ;-) How would you see the 
relationship of commits 952+953 to our problem? 952 seems to affect LSO 
in some way since LsoV1TransmitComplete.TcpPayload is finally wrong 
(could it be negative since tx_length is smaller than the fixed 
tx_length?). What about 953?

One more thought: As mentioned earlier crashes often occurred after an 
uptime of 9-10 days and these crashes occurred too consistently to be a 
"by chance" event. In my torture tests I am NOT USING a Windows NTP 
service (I use the meinberg NTP daemon on Windows). But on production I 
do. Can you see any possible impact here?

Regards Andreas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:50:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:50:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1bV-0001OD-Jw; Mon, 28 Nov 2011 13:50:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RV1bT-0001Np-St
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:50:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322488203!4966930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27933 invoked from network); 28 Nov 2011 13:50:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 13:50:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9162875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 13:50:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 13:50:03 +0000
Date: Mon, 28 Nov 2011 13:50:57 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20111128124522.GC12984@reaktio.net>
Message-ID: <alpine.DEB.2.00.1111281350120.31179@kaball-desktop>
References: <20111031182220.GZ12984@reaktio.net>
	<1322358814275-5025774.post@n5.nabble.com>
	<alpine.DEB.2.00.1111281019200.31179@kaball-desktop>
	<20111128124522.GC12984@reaktio.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-988113412-1322488272=:31179"
Cc: sandr8 <sandr8@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.1.1 HVM guest cdrom trouble, lost interrupts,
 ata failed commands (frozen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-988113412-1322488272=:31179
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 28 Nov 2011, Pasi Kärkkäinen wrote:
> On Mon, Nov 28, 2011 at 10:19:32AM +0000, Stefano Stabellini wrote:
> > On Sun, 27 Nov 2011, sandr8 wrote:
> > > Hi,
> > > 
> > >   I am seeing exactly the same behavior... did you manage to get around this
> > > issue?
> > 
> > it is fixed in xen 4.1.2
> > 
> 
> Btw are there any known workarounds for <= 4.1.1 ?


you can apply the following change to the guest kernel:

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 8214724..6b57f90 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -308,8 +308,7 @@ int __init pci_xen_init(void)
 
 int __init pci_xen_hvm_init(void)
 {
-       if (!xen_feature(XENFEAT_hvm_pirqs))
-               return 0;
+       return 0;
 
 #ifdef CONFIG_ACPI
        /*


or you can apply the following change to xen:

diff -r e73ada19a69d xen/common/kernel.c
--- a/xen/common/kernel.c       Thu Nov 17 09:13:25 2011 +0000
+++ b/xen/common/kernel.c       Mon Nov 28 10:24:24 2011 +0000
@@ -294,8 +294,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDL
                              (1U << XENFEAT_gnttab_map_avail_bits);
             else
                 fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
-                             (1U << XENFEAT_hvm_callback_vector) |
-                             (1U << XENFEAT_hvm_pirqs);
+                             (1U << XENFEAT_hvm_callback_vector);
 #endif
             break;
         default:
--8323329-988113412-1322488272=:31179
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-988113412-1322488272=:31179--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 13:50:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 13:50:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1bV-0001OD-Jw; Mon, 28 Nov 2011 13:50:41 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RV1bT-0001Np-St
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 13:50:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322488203!4966930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27933 invoked from network); 28 Nov 2011 13:50:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 13:50:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9162875"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 13:50:03 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 13:50:03 +0000
Date: Mon, 28 Nov 2011 13:50:57 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20111128124522.GC12984@reaktio.net>
Message-ID: <alpine.DEB.2.00.1111281350120.31179@kaball-desktop>
References: <20111031182220.GZ12984@reaktio.net>
	<1322358814275-5025774.post@n5.nabble.com>
	<alpine.DEB.2.00.1111281019200.31179@kaball-desktop>
	<20111128124522.GC12984@reaktio.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-988113412-1322488272=:31179"
Cc: sandr8 <sandr8@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Xen 4.1.1 HVM guest cdrom trouble, lost interrupts,
 ata failed commands (frozen)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-988113412-1322488272=:31179
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 28 Nov 2011, Pasi Kärkkäinen wrote:
> On Mon, Nov 28, 2011 at 10:19:32AM +0000, Stefano Stabellini wrote:
> > On Sun, 27 Nov 2011, sandr8 wrote:
> > > Hi,
> > > 
> > >   I am seeing exactly the same behavior... did you manage to get around this
> > > issue?
> > 
> > it is fixed in xen 4.1.2
> > 
> 
> Btw are there any known workarounds for <= 4.1.1 ?


you can apply the following change to the guest kernel:

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 8214724..6b57f90 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -308,8 +308,7 @@ int __init pci_xen_init(void)
 
 int __init pci_xen_hvm_init(void)
 {
-       if (!xen_feature(XENFEAT_hvm_pirqs))
-               return 0;
+       return 0;
 
 #ifdef CONFIG_ACPI
        /*


or you can apply the following change to xen:

diff -r e73ada19a69d xen/common/kernel.c
--- a/xen/common/kernel.c       Thu Nov 17 09:13:25 2011 +0000
+++ b/xen/common/kernel.c       Mon Nov 28 10:24:24 2011 +0000
@@ -294,8 +294,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDL
                              (1U << XENFEAT_gnttab_map_avail_bits);
             else
                 fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
-                             (1U << XENFEAT_hvm_callback_vector) |
-                             (1U << XENFEAT_hvm_pirqs);
+                             (1U << XENFEAT_hvm_callback_vector);
 #endif
             break;
         default:
--8323329-988113412-1322488272=:31179
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-988113412-1322488272=:31179--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 14:13:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 14:13:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1wv-0001we-Ik; Mon, 28 Nov 2011 14:12:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV1wt-0001wZ-Q3
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 14:12:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322489502!59028211!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4952 invoked from network); 28 Nov 2011 14:11:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 14:11:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9163643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 14:11:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 14:11:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: anita <anitawang1989@gmail.com>
Date: Mon, 28 Nov 2011 14:11:55 +0000
In-Reply-To: <1322289225863-5024421.post@n5.nabble.com>
References: <1322289225863-5024421.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322489515.1005.296.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 2 questions about hypercall
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU2F0LCAyMDExLTExLTI2IGF0IDA2OjMzICswMDAwLCBhbml0YSB3cm90ZToKPiBIaSwgSSd2
ZSBiZWVuIHJlYWRpbmcgdGhlIHhlbiBzb3VyY2UgY29kZSByZWNlbnRseSwgYW5kIEkgaGF2ZSBn
b3QgMgo+IHF1ZXN0aW9ucyBhYm91dCBoeXBlcmNhbGwuCj4gCj4gMS4gSSBmaW5kIDIgaGVhZGVy
IGZpbGVzIG5hbWVkIGh5cGVyY2FsbC5oIGluIHRoZSBkaXJlY3RvcnkgCj4gbGludXgvYXJjaC94
ODYvaW5jbHVkZS4gT25lIGlzIGluIHRoZSBzdWItZGlyZWN0b3J5Cj4gL21hY2gteGVuL2FzbS9o
eXBlcmNhbGwuaCwgYW5kIHRoZSBvdGhlciBpcyAvYXNtL3hlbi9oeXBlcmNhbGwuaC4gIEFmdGVy
Cj4gY29tcGFyaW5nIHRoZXNlIHR3bywgSSBmaW5kIHRoZWlyIGNvbnRlbnRzIGFyZSBzaW1pbGFy
IGJ1dCBkaWZmZXJlbnQsIGFuZCBJCj4gY2FuJ3QgZmlndXJlIG91dCB3aGF0J3MgdGhlIGRpZmZl
cmVuY2UgYmV0d2VlbiB0aGVtLCB3aGF0IHRoZWlyIHB1cnBvc2VzIGFyZQo+ICwgYW5kIHdoZW4g
a2VybmVsIHdhbnQgdG8gdHJhcCBpbnRvIHhlbiBoeXBlcnZpc29yLCB3aGljaCBvbmUgd2lsbCBr
ZXJuZWwKPiBjaG9vc2XvvJ8KClRoaXMgaXMgbm90IHRoZSBYZW4gc291cmNlIGNvZGUuIFlvdSBh
cHBlYXIgdG8gYmUgbG9va2luZyBhdCBhIGxpbnV4CnNvdXJjZSB0cmVlIGJ1dCB5b3UgaGF2ZW4n
dCBzYWlkIHdoaWNoLgoKPiAyLiBJIGZpbmQgdGhhdCB0aGUgeGVuIHRvb2xzIGFsc28gdXNlZCBo
eXBlcmNhbGwuIE15IHF1ZXN0aW9uIGlzIGhvdyBkb2VzCj4gdG9vbHMgdXNlZCBpdCA/IGlzIHRo
ZSBwcm9jZXNzIHRoZSBzYW1lIGFzIHRoZSBrZXJuZWwsIG9yIHhlbiB0b29scyB1c2UKPiBoeXBl
cmNhbGwgaW4gYSBkaWZmZXJlbnQgd2F5PwoKVGhleSB1c2UgbGlieGVuY3RybCB3aGljaCBpbiB0
dXJuIHVzZXMgYSBzcGVjaWFsIGlvY3RsCm9uIC9wcm9jL3hlbi9wcml2Y21kIHRvIG1ha2UgaHlw
ZXJjYWxscy4KCklhbi4KCj4gCj4gLS0KPiBWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBo
dHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS8yLXF1ZXN0aW9ucy1hYm91dC1oeXBlcmNh
bGwtdHA1MDI0NDIxcDUwMjQ0MjEuaHRtbAo+IFNlbnQgZnJvbSB0aGUgWGVuIC0gRGV2IG1haWxp
bmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCj4gCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Nov 28 14:13:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 14:13:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV1wv-0001we-Ik; Mon, 28 Nov 2011 14:12:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV1wt-0001wZ-Q3
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 14:12:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322489502!59028211!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4952 invoked from network); 28 Nov 2011 14:11:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 14:11:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9163643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 14:11:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 14:11:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: anita <anitawang1989@gmail.com>
Date: Mon, 28 Nov 2011 14:11:55 +0000
In-Reply-To: <1322289225863-5024421.post@n5.nabble.com>
References: <1322289225863-5024421.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322489515.1005.296.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 2 questions about hypercall
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU2F0LCAyMDExLTExLTI2IGF0IDA2OjMzICswMDAwLCBhbml0YSB3cm90ZToKPiBIaSwgSSd2
ZSBiZWVuIHJlYWRpbmcgdGhlIHhlbiBzb3VyY2UgY29kZSByZWNlbnRseSwgYW5kIEkgaGF2ZSBn
b3QgMgo+IHF1ZXN0aW9ucyBhYm91dCBoeXBlcmNhbGwuCj4gCj4gMS4gSSBmaW5kIDIgaGVhZGVy
IGZpbGVzIG5hbWVkIGh5cGVyY2FsbC5oIGluIHRoZSBkaXJlY3RvcnkgCj4gbGludXgvYXJjaC94
ODYvaW5jbHVkZS4gT25lIGlzIGluIHRoZSBzdWItZGlyZWN0b3J5Cj4gL21hY2gteGVuL2FzbS9o
eXBlcmNhbGwuaCwgYW5kIHRoZSBvdGhlciBpcyAvYXNtL3hlbi9oeXBlcmNhbGwuaC4gIEFmdGVy
Cj4gY29tcGFyaW5nIHRoZXNlIHR3bywgSSBmaW5kIHRoZWlyIGNvbnRlbnRzIGFyZSBzaW1pbGFy
IGJ1dCBkaWZmZXJlbnQsIGFuZCBJCj4gY2FuJ3QgZmlndXJlIG91dCB3aGF0J3MgdGhlIGRpZmZl
cmVuY2UgYmV0d2VlbiB0aGVtLCB3aGF0IHRoZWlyIHB1cnBvc2VzIGFyZQo+ICwgYW5kIHdoZW4g
a2VybmVsIHdhbnQgdG8gdHJhcCBpbnRvIHhlbiBoeXBlcnZpc29yLCB3aGljaCBvbmUgd2lsbCBr
ZXJuZWwKPiBjaG9vc2XvvJ8KClRoaXMgaXMgbm90IHRoZSBYZW4gc291cmNlIGNvZGUuIFlvdSBh
cHBlYXIgdG8gYmUgbG9va2luZyBhdCBhIGxpbnV4CnNvdXJjZSB0cmVlIGJ1dCB5b3UgaGF2ZW4n
dCBzYWlkIHdoaWNoLgoKPiAyLiBJIGZpbmQgdGhhdCB0aGUgeGVuIHRvb2xzIGFsc28gdXNlZCBo
eXBlcmNhbGwuIE15IHF1ZXN0aW9uIGlzIGhvdyBkb2VzCj4gdG9vbHMgdXNlZCBpdCA/IGlzIHRo
ZSBwcm9jZXNzIHRoZSBzYW1lIGFzIHRoZSBrZXJuZWwsIG9yIHhlbiB0b29scyB1c2UKPiBoeXBl
cmNhbGwgaW4gYSBkaWZmZXJlbnQgd2F5PwoKVGhleSB1c2UgbGlieGVuY3RybCB3aGljaCBpbiB0
dXJuIHVzZXMgYSBzcGVjaWFsIGlvY3RsCm9uIC9wcm9jL3hlbi9wcml2Y21kIHRvIG1ha2UgaHlw
ZXJjYWxscy4KCklhbi4KCj4gCj4gLS0KPiBWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBo
dHRwOi8veGVuLjEwNDU3MTIubjUubmFiYmxlLmNvbS8yLXF1ZXN0aW9ucy1hYm91dC1oeXBlcmNh
bGwtdHA1MDI0NDIxcDUwMjQ0MjEuaHRtbAo+IFNlbnQgZnJvbSB0aGUgWGVuIC0gRGV2IG1haWxp
bmcgbGlzdCBhcmNoaXZlIGF0IE5hYmJsZS5jb20uCj4gCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94
ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Nov 28 14:25:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 14:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV292-00029X-0n; Mon, 28 Nov 2011 14:25:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RV291-00029S-4I
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 14:25:19 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322490281!3406698!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31486 invoked from network); 28 Nov 2011 14:24:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 14:24:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172025920"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 09:24:41 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 28 Nov 2011
	09:24:41 -0500
Message-ID: <4ED399A7.1070108@citrix.com>
Date: Mon, 28 Nov 2011 14:24:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Subject: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
to reduce unaligned writes, but pass the resulting pointer back to
machine_crash_shutdown() which performs writes on the possibly unaligned
data structure.  There are also plenty of other writes on the kexec path
which are possibly or certainly unaligned.

What is the reason for wanting to reduce unaligned writes?

Would a better solution be to just ensure that the crash note itself is
properly aligned?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 14:25:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 14:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV292-00029X-0n; Mon, 28 Nov 2011 14:25:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RV291-00029S-4I
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 14:25:19 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322490281!3406698!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31486 invoked from network); 28 Nov 2011 14:24:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 14:24:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172025920"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 09:24:41 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 28 Nov 2011
	09:24:41 -0500
Message-ID: <4ED399A7.1070108@citrix.com>
Date: Mon, 28 Nov 2011 14:24:39 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Subject: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
to reduce unaligned writes, but pass the resulting pointer back to
machine_crash_shutdown() which performs writes on the possibly unaligned
data structure.  There are also plenty of other writes on the kexec path
which are possibly or certainly unaligned.

What is the reason for wanting to reduce unaligned writes?

Would a better solution be to just ensure that the crash note itself is
properly aligned?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 14:37:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 14:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV2Jx-0002Lb-9i; Mon, 28 Nov 2011 14:36:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV2Jv-0002LW-L9
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 14:36:35 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322490957!5360422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19830 invoked from network); 28 Nov 2011 14:35:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 14:35:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9164715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 14:35:57 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 28 Nov 2011
	14:35:57 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Mon, 28 Nov 2011 14:36:01 +0000
Thread-Topic: [Xen-devel] [PATCH 4 of 5] Add code to track the address of
	the VM generation id buffer across a
Thread-Index: Acyt1G+n3q4cgL+bSAWS5Nl/sa6iLwABjUbw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4DE4@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
	<20111128123246.GB79829@ocelot.phlegethon.org>
	<291EDFCB1E9E224A99088639C4762022B5988E4DCC@LONPMAILBOX01.citrite.net>
	<20111128134834.GC79829@ocelot.phlegethon.org>
In-Reply-To: <20111128134834.GC79829@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] Add code to track the address of the
 VM generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> 
> Presumably in this case the tools can find the address by walking
> the ACPI tables, just like the guest OS would. :P  Not very pretty,
> though.
>

Erk, no! That would not be pretty.
 
> I don't think there's anything wrong with putting a GPA into
> xenstore.  All the other tools interactions are in guest-physical
> addressing already.  IIRC HVMloader's xenbus client doesn't have a
> xenstore_write() but it shouldn't be hard to add.
> 

OK, I'll go with that. Re-worked series coming up...

> I can't think of another way to pass data from hvmloader to the
> tools right now -- I think the hvm-info page should probably be
> replaced entirely with xenstore keys at some point.
> 

Yes, that was why I moved acpi_enabled out of there. Didn't really want to put something else in there :-)

 Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 14:37:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 14:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV2Jx-0002Lb-9i; Mon, 28 Nov 2011 14:36:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RV2Jv-0002LW-L9
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 14:36:35 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322490957!5360422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19830 invoked from network); 28 Nov 2011 14:35:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 14:35:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9164715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 14:35:57 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 28 Nov 2011
	14:35:57 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Tim (Xen.org)" <tim@xen.org>
Date: Mon, 28 Nov 2011 14:36:01 +0000
Thread-Topic: [Xen-devel] [PATCH 4 of 5] Add code to track the address of
	the VM generation id buffer across a
Thread-Index: Acyt1G+n3q4cgL+bSAWS5Nl/sa6iLwABjUbw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4DE4@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322482532@cosworth.uk.xensource.com>
	<c4613164ee1c5f3bf208.1322482536@cosworth.uk.xensource.com>
	<20111128123246.GB79829@ocelot.phlegethon.org>
	<291EDFCB1E9E224A99088639C4762022B5988E4DCC@LONPMAILBOX01.citrite.net>
	<20111128134834.GC79829@ocelot.phlegethon.org>
In-Reply-To: <20111128134834.GC79829@ocelot.phlegethon.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 5] Add code to track the address of the
 VM generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> 
> Presumably in this case the tools can find the address by walking
> the ACPI tables, just like the guest OS would. :P  Not very pretty,
> though.
>

Erk, no! That would not be pretty.
 
> I don't think there's anything wrong with putting a GPA into
> xenstore.  All the other tools interactions are in guest-physical
> addressing already.  IIRC HVMloader's xenbus client doesn't have a
> xenstore_write() but it shouldn't be hard to add.
> 

OK, I'll go with that. Re-worked series coming up...

> I can't think of another way to pass data from hvmloader to the
> tools right now -- I think the hvm-info page should probably be
> replaced entirely with xenstore keys at some point.
> 

Yes, that was why I moved acpi_enabled out of there. Didn't really want to put something else in there :-)

 Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 14:43:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 14:43:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV2Qf-0002V4-5z; Mon, 28 Nov 2011 14:43:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RV2Qc-0002Uu-Sa
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 14:43:31 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322491373!3398058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17092 invoked from network); 28 Nov 2011 14:42:54 -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;
	28 Nov 2011 14:42:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9164984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 14:42:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 14:42:53 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RV2Q1-0004K2-1g;
	Mon, 28 Nov 2011 14:42:53 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RV2Pm-0007Lm-1o;
	Mon, 28 Nov 2011 14:42:38 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 14:42:37 +0000
Message-ID: <1322491357-28225-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH] x86: Move nested_p2m per domain data into its
	own struct.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


An upcoming change may require to increase the size of struct domain
(for x86). The result is a build failure because struct domain gets
larger than a page.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 xen/arch/x86/domain.c        |    5 +++++
 xen/arch/x86/mm/hap/hap.c    |    4 ++--
 xen/arch/x86/mm/mm-locks.h   |    4 ++--
 xen/arch/x86/mm/p2m.c        |   13 ++++++-------
 xen/include/asm-x86/domain.h |    9 +++++++--
 5 files changed, 22 insertions(+), 13 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-x86-Move-nested_p2m-per-domain-data-into-its-own-str.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-x86-Move-nested_p2m-per-domain-data-into-its-own-str.patch"

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index b8a64c3..d0a5e4e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -598,6 +598,11 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
         /* For Guest vMCE MSRs virtualization */
         vmce_init_msr(d);
+
+        d->arch.nested_p2m = xzalloc(struct nested_p2m_per_domain);
+        rc = -ENOMEM;
+        if ( d->arch.nested_p2m == NULL )
+            goto fail;
     }
 
     if ( is_hvm_domain(d) )
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 9f6b990..03d31b9 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -607,7 +607,7 @@ int hap_enable(struct domain *d, u32 mode)
     }
 
     for (i = 0; i < MAX_NESTEDP2M; i++) {
-        rv = p2m_alloc_table(d->arch.nested_p2m[i]);
+        rv = p2m_alloc_table(d->arch.nested_p2m->nested_p2m[i]);
         if ( rv != 0 )
            goto out;
     }
@@ -626,7 +626,7 @@ void hap_final_teardown(struct domain *d)
 
     /* Destroy nestedp2m's first */
     for (i = 0; i < MAX_NESTEDP2M; i++) {
-        p2m_teardown(d->arch.nested_p2m[i]);
+        p2m_teardown(d->arch.nested_p2m->nested_p2m[i]);
     }
 
     if ( d->arch.paging.hap.total_pages != 0 )
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 738b27c..f545984 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -160,8 +160,8 @@ declare_mm_lock(shr)
  *   (i.e. assigning a p2m table to be the shadow of that cr3 */
 
 declare_mm_lock(nestedp2m)
-#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
-#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
+#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m->nested_p2m_lock)
+#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m->nested_p2m_lock)
 
 /* P2M lock (per-p2m-table)
  * 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 51a0096..4eb1fd9 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -96,9 +96,9 @@ p2m_init_nestedp2m(struct domain *d)
     uint8_t i;
     struct p2m_domain *p2m;
 
-    mm_lock_init(&d->arch.nested_p2m_lock);
+    mm_lock_init(&d->arch.nested_p2m->nested_p2m_lock);
     for (i = 0; i < MAX_NESTEDP2M; i++) {
-        d->arch.nested_p2m[i] = p2m = xzalloc(struct p2m_domain);
+        d->arch.nested_p2m->nested_p2m[i] = p2m = xzalloc(struct p2m_domain);
         if (p2m == NULL)
             return -ENOMEM;
         if ( !zalloc_cpumask_var(&p2m->dirty_cpumask) )
@@ -376,11 +376,10 @@ static void p2m_teardown_nestedp2m(struct domain *d)
     uint8_t i;
 
     for (i = 0; i < MAX_NESTEDP2M; i++) {
-        if ( !d->arch.nested_p2m[i] )
+        if ( !d->arch.nested_p2m->nested_p2m[i] )
             continue;
-        free_cpumask_var(d->arch.nested_p2m[i]->dirty_cpumask);
-        xfree(d->arch.nested_p2m[i]);
-        d->arch.nested_p2m[i] = NULL;
+        free_cpumask_var(d->arch.nested_p2m->nested_p2m[i]->dirty_cpumask);
+        d->arch.nested_p2m->nested_p2m[i] = NULL;
     }
 }
 
@@ -1328,7 +1327,7 @@ p2m_flush_nestedp2m(struct domain *d)
 {
     int i;
     for ( i = 0; i < MAX_NESTEDP2M; i++ )
-        p2m_flush_table(d->arch.nested_p2m[i]);
+        p2m_flush_table(d->arch.nested_p2m->nested_p2m[i]);
 }
 
 struct p2m_domain *
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 00bbaeb..a543f6a 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -238,6 +238,12 @@ struct pv_domain
     unsigned int nr_e820;
 };
 
+struct nested_p2m_per_domain
+{
+    struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
+    mm_lock_t nested_p2m_lock;
+};
+
 struct arch_domain
 {
 #ifdef CONFIG_X86_64
@@ -274,8 +280,7 @@ struct arch_domain
     int page_alloc_unlock_level;
 
     /* nestedhvm: translate l2 guest physical to host physical */
-    struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
-    mm_lock_t nested_p2m_lock;
+    struct nested_p2m_per_domain *nested_p2m;
 
     /* NB. protected by d->event_lock and by irq_desc[irq].lock */
     struct radix_tree_root irq_pirq;

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 14:43:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 14:43:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV2Qf-0002V4-5z; Mon, 28 Nov 2011 14:43:33 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RV2Qc-0002Uu-Sa
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 14:43:31 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322491373!3398058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17092 invoked from network); 28 Nov 2011 14:42:54 -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;
	28 Nov 2011 14:42:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9164984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 14:42:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 14:42:53 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RV2Q1-0004K2-1g;
	Mon, 28 Nov 2011 14:42:53 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RV2Pm-0007Lm-1o;
	Mon, 28 Nov 2011 14:42:38 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 14:42:37 +0000
Message-ID: <1322491357-28225-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Jean Guyader <jean.guyader@eu.citrix.com>
Subject: [Xen-devel] [PATCH] x86: Move nested_p2m per domain data into its
	own struct.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


An upcoming change may require to increase the size of struct domain
(for x86). The result is a build failure because struct domain gets
larger than a page.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 xen/arch/x86/domain.c        |    5 +++++
 xen/arch/x86/mm/hap/hap.c    |    4 ++--
 xen/arch/x86/mm/mm-locks.h   |    4 ++--
 xen/arch/x86/mm/p2m.c        |   13 ++++++-------
 xen/include/asm-x86/domain.h |    9 +++++++--
 5 files changed, 22 insertions(+), 13 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-x86-Move-nested_p2m-per-domain-data-into-its-own-str.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-x86-Move-nested_p2m-per-domain-data-into-its-own-str.patch"

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index b8a64c3..d0a5e4e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -598,6 +598,11 @@ int arch_domain_create(struct domain *d, unsigned int domcr_flags)
 
         /* For Guest vMCE MSRs virtualization */
         vmce_init_msr(d);
+
+        d->arch.nested_p2m = xzalloc(struct nested_p2m_per_domain);
+        rc = -ENOMEM;
+        if ( d->arch.nested_p2m == NULL )
+            goto fail;
     }
 
     if ( is_hvm_domain(d) )
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 9f6b990..03d31b9 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -607,7 +607,7 @@ int hap_enable(struct domain *d, u32 mode)
     }
 
     for (i = 0; i < MAX_NESTEDP2M; i++) {
-        rv = p2m_alloc_table(d->arch.nested_p2m[i]);
+        rv = p2m_alloc_table(d->arch.nested_p2m->nested_p2m[i]);
         if ( rv != 0 )
            goto out;
     }
@@ -626,7 +626,7 @@ void hap_final_teardown(struct domain *d)
 
     /* Destroy nestedp2m's first */
     for (i = 0; i < MAX_NESTEDP2M; i++) {
-        p2m_teardown(d->arch.nested_p2m[i]);
+        p2m_teardown(d->arch.nested_p2m->nested_p2m[i]);
     }
 
     if ( d->arch.paging.hap.total_pages != 0 )
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 738b27c..f545984 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -160,8 +160,8 @@ declare_mm_lock(shr)
  *   (i.e. assigning a p2m table to be the shadow of that cr3 */
 
 declare_mm_lock(nestedp2m)
-#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
-#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
+#define nestedp2m_lock(d)   mm_lock(nestedp2m, &(d)->arch.nested_p2m->nested_p2m_lock)
+#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m->nested_p2m_lock)
 
 /* P2M lock (per-p2m-table)
  * 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 51a0096..4eb1fd9 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -96,9 +96,9 @@ p2m_init_nestedp2m(struct domain *d)
     uint8_t i;
     struct p2m_domain *p2m;
 
-    mm_lock_init(&d->arch.nested_p2m_lock);
+    mm_lock_init(&d->arch.nested_p2m->nested_p2m_lock);
     for (i = 0; i < MAX_NESTEDP2M; i++) {
-        d->arch.nested_p2m[i] = p2m = xzalloc(struct p2m_domain);
+        d->arch.nested_p2m->nested_p2m[i] = p2m = xzalloc(struct p2m_domain);
         if (p2m == NULL)
             return -ENOMEM;
         if ( !zalloc_cpumask_var(&p2m->dirty_cpumask) )
@@ -376,11 +376,10 @@ static void p2m_teardown_nestedp2m(struct domain *d)
     uint8_t i;
 
     for (i = 0; i < MAX_NESTEDP2M; i++) {
-        if ( !d->arch.nested_p2m[i] )
+        if ( !d->arch.nested_p2m->nested_p2m[i] )
             continue;
-        free_cpumask_var(d->arch.nested_p2m[i]->dirty_cpumask);
-        xfree(d->arch.nested_p2m[i]);
-        d->arch.nested_p2m[i] = NULL;
+        free_cpumask_var(d->arch.nested_p2m->nested_p2m[i]->dirty_cpumask);
+        d->arch.nested_p2m->nested_p2m[i] = NULL;
     }
 }
 
@@ -1328,7 +1327,7 @@ p2m_flush_nestedp2m(struct domain *d)
 {
     int i;
     for ( i = 0; i < MAX_NESTEDP2M; i++ )
-        p2m_flush_table(d->arch.nested_p2m[i]);
+        p2m_flush_table(d->arch.nested_p2m->nested_p2m[i]);
 }
 
 struct p2m_domain *
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 00bbaeb..a543f6a 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -238,6 +238,12 @@ struct pv_domain
     unsigned int nr_e820;
 };
 
+struct nested_p2m_per_domain
+{
+    struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
+    mm_lock_t nested_p2m_lock;
+};
+
 struct arch_domain
 {
 #ifdef CONFIG_X86_64
@@ -274,8 +280,7 @@ struct arch_domain
     int page_alloc_unlock_level;
 
     /* nestedhvm: translate l2 guest physical to host physical */
-    struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
-    mm_lock_t nested_p2m_lock;
+    struct nested_p2m_per_domain *nested_p2m;
 
     /* NB. protected by d->event_lock and by irq_desc[irq].lock */
     struct radix_tree_root irq_pirq;

--------------true
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------true--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:05:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV2lU-0002lz-5v; Mon, 28 Nov 2011 15:05:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RV2lS-0002lu-9g
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:05:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322492665!6130418!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMjA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23784 invoked from network); 28 Nov 2011 15:04:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 15:04:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 28 Nov 2011 15:04:25 +0000
Message-Id: <4ED3B1080200007800063AD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 28 Nov 2011 15:04:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@eu.citrix.com>
References: <1322491357-28225-1-git-send-email-jean.guyader@eu.citrix.com>
In-Reply-To: <1322491357-28225-1-git-send-email-jean.guyader@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86: Move nested_p2m per domain data into
 its own struct.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 28.11.11 at 15:42, Jean Guyader <jean.guyader@eu.citrix.com> wrote:
>--- a/xen/include/asm-x86/domain.h
>+++ b/xen/include/asm-x86/domain.h
>@@ -238,6 +238,12 @@ struct pv_domain
>     unsigned int nr_e820;
> };
> 
>+struct nested_p2m_per_domain
>+{
>+    struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
>+    mm_lock_t nested_p2m_lock;

So you call these nested_p2m* but the container ...

>+};
>+
> struct arch_domain
> {
> #ifdef CONFIG_X86_64
>@@ -274,8 +280,7 @@ struct arch_domain
>     int page_alloc_unlock_level;
> 
>     /* nestedhvm: translate l2 guest physical to host physical */
>-    struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
>-    mm_lock_t nested_p2m_lock;
>+    struct nested_p2m_per_domain *nested_p2m;

... is also called this way. Pretty redundant, just requiring extra
typing and eventually leading to ugly to read wrapped lines.

Jan

> 
>     /* NB. protected by d->event_lock and by irq_desc[irq].lock */
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:05:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV2lU-0002lz-5v; Mon, 28 Nov 2011 15:05:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RV2lS-0002lu-9g
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:05:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322492665!6130418!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMjA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23784 invoked from network); 28 Nov 2011 15:04:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 15:04:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 28 Nov 2011 15:04:25 +0000
Message-Id: <4ED3B1080200007800063AD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 28 Nov 2011 15:04:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@eu.citrix.com>
References: <1322491357-28225-1-git-send-email-jean.guyader@eu.citrix.com>
In-Reply-To: <1322491357-28225-1-git-send-email-jean.guyader@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86: Move nested_p2m per domain data into
 its own struct.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 28.11.11 at 15:42, Jean Guyader <jean.guyader@eu.citrix.com> wrote:
>--- a/xen/include/asm-x86/domain.h
>+++ b/xen/include/asm-x86/domain.h
>@@ -238,6 +238,12 @@ struct pv_domain
>     unsigned int nr_e820;
> };
> 
>+struct nested_p2m_per_domain
>+{
>+    struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
>+    mm_lock_t nested_p2m_lock;

So you call these nested_p2m* but the container ...

>+};
>+
> struct arch_domain
> {
> #ifdef CONFIG_X86_64
>@@ -274,8 +280,7 @@ struct arch_domain
>     int page_alloc_unlock_level;
> 
>     /* nestedhvm: translate l2 guest physical to host physical */
>-    struct p2m_domain *nested_p2m[MAX_NESTEDP2M];
>-    mm_lock_t nested_p2m_lock;
>+    struct nested_p2m_per_domain *nested_p2m;

... is also called this way. Pretty redundant, just requiring extra
typing and eventually leading to ugly to read wrapped lines.

Jan

> 
>     /* NB. protected by d->event_lock and by irq_desc[irq].lock */
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:21:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:21:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV319-0002xP-Ne; Mon, 28 Nov 2011 15:21:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV317-0002xK-H7
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:21:13 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322493530!54021423!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27536 invoked from network); 28 Nov 2011 15:18:51 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 15:18:51 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASFKWdh010405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 10:20:33 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASFKVrD010400;
	Mon, 28 Nov 2011 10:20:32 -0500
Date: Mon, 28 Nov 2011 11:20:31 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: David Vrabel <david.vrabel@citrix.com>, dgdegra@tycho.nsa.gov
Message-ID: <20111128152031.GB9655@andromeda.dapyr.net>
References: <4E5FED1A.1000300@goop.org>
	<20110901141754.76cef93b.akpm@linux-foundation.org>
	<4E60C067.4010600@citrix.com>
	<20110902153204.59a928c1.akpm@linux-foundation.org>
	<20110906163553.GA28971@dumpdata.com>
	<20111105133846.GA4415@phenom.dumpdata.com>
	<20111107203613.GA6546@phenom.dumpdata.com>
	<4ED3641A0200007800063991@nat28.tlf.novell.com>
	<1322475560.11846.26.camel@dagon.hellion.org.uk>
	<4ED37251.8040908@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED37251.8040908@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] mm: sync vmalloc address space page tables
	in alloc_vm_area()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 11:36:49AM +0000, David Vrabel wrote:
> On 28/11/11 10:19, Ian Campbell wrote:
> > On Mon, 2011-11-28 at 09:36 +0000, Jan Beulich wrote:
> >> Besides that, the patch also appears to close the road to running
> >> backends in HVM - use of GNTMAP_contains_pte isn't permitted for
> >> paging_mode_external() guests, so it's even a step backwards for
> >> x86.
> > 
> > That is a bigger concern.
> 
> Daniel de Graaf has a patch series for this.
> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg01484.html
> 
> Specifically: [PATCH 1/6] xenbus: Support HVM backends

Hmm, and I somehow loss track of those.

Daniel,

Could you repost that patch series on top of v3.2-rc3 please?
Or perhaps all of the patches you have so far in one big shot?

> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg01486.html
> 
> David
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:21:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:21:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV319-0002xP-Ne; Mon, 28 Nov 2011 15:21:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV317-0002xK-H7
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:21:13 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322493530!54021423!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27536 invoked from network); 28 Nov 2011 15:18:51 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 15:18:51 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASFKWdh010405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 10:20:33 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASFKVrD010400;
	Mon, 28 Nov 2011 10:20:32 -0500
Date: Mon, 28 Nov 2011 11:20:31 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: David Vrabel <david.vrabel@citrix.com>, dgdegra@tycho.nsa.gov
Message-ID: <20111128152031.GB9655@andromeda.dapyr.net>
References: <4E5FED1A.1000300@goop.org>
	<20110901141754.76cef93b.akpm@linux-foundation.org>
	<4E60C067.4010600@citrix.com>
	<20110902153204.59a928c1.akpm@linux-foundation.org>
	<20110906163553.GA28971@dumpdata.com>
	<20111105133846.GA4415@phenom.dumpdata.com>
	<20111107203613.GA6546@phenom.dumpdata.com>
	<4ED3641A0200007800063991@nat28.tlf.novell.com>
	<1322475560.11846.26.camel@dagon.hellion.org.uk>
	<4ED37251.8040908@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED37251.8040908@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] mm: sync vmalloc address space page tables
	in alloc_vm_area()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 11:36:49AM +0000, David Vrabel wrote:
> On 28/11/11 10:19, Ian Campbell wrote:
> > On Mon, 2011-11-28 at 09:36 +0000, Jan Beulich wrote:
> >> Besides that, the patch also appears to close the road to running
> >> backends in HVM - use of GNTMAP_contains_pte isn't permitted for
> >> paging_mode_external() guests, so it's even a step backwards for
> >> x86.
> > 
> > That is a bigger concern.
> 
> Daniel de Graaf has a patch series for this.
> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg01484.html
> 
> Specifically: [PATCH 1/6] xenbus: Support HVM backends

Hmm, and I somehow loss track of those.

Daniel,

Could you repost that patch series on top of v3.2-rc3 please?
Or perhaps all of the patches you have so far in one big shot?

> 
> http://lists.xen.org/archives/html/xen-devel/2011-10/msg01486.html
> 
> David
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:23:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV32Z-00030r-7X; Mon, 28 Nov 2011 15:22:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV32Y-00030k-71
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:22:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322493700!54558689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20217 invoked from network); 28 Nov 2011 15:21:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 15:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9166239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 15:21:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 15:21:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 15:21:54 +0000
In-Reply-To: <1322487525.1005.293.camel@zakaz.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
	<1322487525.1005.293.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322493714.20646.5.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 13:38 +0000, Ian Campbell wrote:
> On Mon, 2011-11-28 at 11:58 +0000, Ian Jackson wrote:
> > xen.org writes ("[xen-unstable test] 10135: regressions - FAIL"):
> > > flight 10135 xen-unstable real [real]
> > > http://www.chiark.greenend.org.uk/~xensrcts/logs/10135/
> > > 
> > > Regressions :-(
> > > 
> > > Tests which did not succeed and are blocking:
> > >  test-amd64-i386-rhel6hvm-intel  7 redhat-install       fail REGR. vs. 9956
> > 
> > My bisector wasn't able to finger an exact changeset due to a blocking
> > bug in the vicinity, but:
> > 
> >   pass      24183:53bec838bb08  Merge
> >   blocked   24184:4ecd3615e726  tools: use system installed libaio by default.
> >   blocked   24185:f88c745575bb  docs: remove some fatally out of date ...
> >   fail      24186:7aa5838499d1  tools: use system libaio for blktap1 as well.
> > 
> > Here the "system installed libaio" is that from Debian squeeze.
> 
> This is really weird since nothing in the failings tests even exercises
> this stuff. Only blktap (1 and 2) uses aio and the the tests don't use
> it and neither does qemu-dm which is the only other thing I can think
> of.

Turns out the test system is using the 2.6.32 kernel from xen.git and
hence is using tapdisk2 for the guest cdrom drive.

>  I'm setting up a repro to see if I can figure out what is going
> wrong.

I didn't get as far a reproing but I realised that the issue was that
libaio was not installed on the target and so tapdisk was failing to run
but error handling was broken so we didn't notice apart from some
messages deep in the logs. The following fixes the error handling:

8>-------------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322493402 0
# Node ID 35883c0b285c8dfce341bdd04deda53ab6db03cf
# Parent  f688f1c8205f90bbfbd6900ccd410382c676b47f
libxl: propagate error from tap_ctl_spawn.

Failure here means that a disk will not be correctly setup. I briefly
scanned tools/blktap2/control.c for other goto constructs which did not
set their err variable but didn't see any others.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f688f1c8205f -r 35883c0b285c tools/blktap2/control/tap-ctl-create.c
--- a/tools/blktap2/control/tap-ctl-create.c	Mon Nov 28 12:59:15 2011 +0000
+++ b/tools/blktap2/control/tap-ctl-create.c	Mon Nov 28 15:16:42 2011 +0000
@@ -44,8 +44,10 @@ tap_ctl_create(const char *params, char 
 		return err;
 
 	id = tap_ctl_spawn();
-	if (id < 0)
+	if (id < 0) {
+		err = id;
 		goto destroy;
+	}
 
 	err = tap_ctl_attach(id, minor);
 	if (err)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:23:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV32Z-00030r-7X; Mon, 28 Nov 2011 15:22:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV32Y-00030k-71
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:22:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322493700!54558689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20217 invoked from network); 28 Nov 2011 15:21:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 15:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9166239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 15:21:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 15:21:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 15:21:54 +0000
In-Reply-To: <1322487525.1005.293.camel@zakaz.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
	<1322487525.1005.293.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322493714.20646.5.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 13:38 +0000, Ian Campbell wrote:
> On Mon, 2011-11-28 at 11:58 +0000, Ian Jackson wrote:
> > xen.org writes ("[xen-unstable test] 10135: regressions - FAIL"):
> > > flight 10135 xen-unstable real [real]
> > > http://www.chiark.greenend.org.uk/~xensrcts/logs/10135/
> > > 
> > > Regressions :-(
> > > 
> > > Tests which did not succeed and are blocking:
> > >  test-amd64-i386-rhel6hvm-intel  7 redhat-install       fail REGR. vs. 9956
> > 
> > My bisector wasn't able to finger an exact changeset due to a blocking
> > bug in the vicinity, but:
> > 
> >   pass      24183:53bec838bb08  Merge
> >   blocked   24184:4ecd3615e726  tools: use system installed libaio by default.
> >   blocked   24185:f88c745575bb  docs: remove some fatally out of date ...
> >   fail      24186:7aa5838499d1  tools: use system libaio for blktap1 as well.
> > 
> > Here the "system installed libaio" is that from Debian squeeze.
> 
> This is really weird since nothing in the failings tests even exercises
> this stuff. Only blktap (1 and 2) uses aio and the the tests don't use
> it and neither does qemu-dm which is the only other thing I can think
> of.

Turns out the test system is using the 2.6.32 kernel from xen.git and
hence is using tapdisk2 for the guest cdrom drive.

>  I'm setting up a repro to see if I can figure out what is going
> wrong.

I didn't get as far a reproing but I realised that the issue was that
libaio was not installed on the target and so tapdisk was failing to run
but error handling was broken so we didn't notice apart from some
messages deep in the logs. The following fixes the error handling:

8>-------------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322493402 0
# Node ID 35883c0b285c8dfce341bdd04deda53ab6db03cf
# Parent  f688f1c8205f90bbfbd6900ccd410382c676b47f
libxl: propagate error from tap_ctl_spawn.

Failure here means that a disk will not be correctly setup. I briefly
scanned tools/blktap2/control.c for other goto constructs which did not
set their err variable but didn't see any others.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f688f1c8205f -r 35883c0b285c tools/blktap2/control/tap-ctl-create.c
--- a/tools/blktap2/control/tap-ctl-create.c	Mon Nov 28 12:59:15 2011 +0000
+++ b/tools/blktap2/control/tap-ctl-create.c	Mon Nov 28 15:16:42 2011 +0000
@@ -44,8 +44,10 @@ tap_ctl_create(const char *params, char 
 		return err;
 
 	id = tap_ctl_spawn();
-	if (id < 0)
+	if (id < 0) {
+		err = id;
 		goto destroy;
+	}
 
 	err = tap_ctl_attach(id, minor);
 	if (err)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:29:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:29:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV38o-0003Nw-P1; Mon, 28 Nov 2011 15:29:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV38n-0003Nd-MU
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:29:10 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322494111!3230353!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 520 invoked from network); 28 Nov 2011 15:28:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 15:28:32 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASFSUM1011952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 10:28:30 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASFSTXS011950;
	Mon, 28 Nov 2011 10:28:29 -0500
Date: Mon, 28 Nov 2011 11:28:29 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Carsten Schiers <carsten@schiers.de>, zhenzhong.duan@oracle.com,
	lersek@redhat.com
Message-ID: <20111128152829.GC9655@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"konrad.wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:
> I got the values in DomU. I will have
> 
>   - aprox. 5% load in DomU with 2.6.34 Xenified Kernel
>   - aprox. 15% load in DomU with 2.6.32.46 Jeremy or 3.1.2 Kernel with one card attached
>   - aprox. 30% load in DomU with 2.6.32.46 Jeremy or 3.1.2 Kernel with two cards attached

HA!

I just wonder if the issue is that the reporting of CPU spent is wrong.
Laszlo Ersek and Zhenzhong Duan have both reported a bug in the pvops
code when it came to account of CPU time.

> 
> I looked through my old mails from you and you explained already the necessity of double
> bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
> Xenified kernel not have this kind of issue?

That is a puzzle. It should not. The code is very much the same - both
use the generic SWIOTLB which has not changed for years.
> 
> The driver in question is nearly identical between the two kernel versions. It is in
> Drivers/media/dvb/ttpci by the way and when I understood the code right, the allo in 
> question is:
> 
>         /* allocate and init buffers */
>         av7110->debi_virt = pci_alloc_consistent(pdev, 8192, &av7110->debi_bus);

Good. So it allocates it during init and uses it.
>         if (!av7110->debi_virt)
>                 goto err_saa71466_vfree_4;
> 
> isn't it? I think the cards are constantly transferring the stream received through DMA. 

Yeah, and that memory is set aside for the life of the driver. So there
should be no bounce buffering happening (as it allocated the memory
below the 4GB mark).
> 
> I have set dom0_mem=512M by the way, shall I change that in some way?

Does the reporting (CPU usage of DomU) change in any way with that?
> 
> I can try out some things, if you want me to. But I have no idea what to do and where to
> start, so I rely on your help...
> 
> Carsten.
> 
> -----Urspr?ngliche Nachricht-----
> Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] Im Auftrag von Konrad Rzeszutek Wilk
> Gesendet: Freitag, 25. November 2011 19:43
> An: Carsten Schiers
> Cc: xen-devel; konrad.wilk
> Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)
> 
> On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:
> > Hello again, I would like to come back to that thing...sorry that I did not have the time up to now.
> > 
> > ??
> > We (now) speak about
> > 
> > ??
> > *	Xen 4.1.2
> > *	Dom0 is Jeremy's 2.6.32.46 64 bit
> > *	DomU in question is now 3.1.2 64 bit
> > *	Same thing if DomU is also 2.6.32.46
> > *	DomU owns two PCI cards (DVB-C) that o DMA
> > *	Machine has 8GB, Dom0 pinned at 512MB
> > 
> > ??
> > As compared to 2.6.34 Kernel with backported patches, the load on the DomU is at least twice as high. It
> > 
> > will be "close to normal" if I reduce the memory used to 4GB.
> 
> That is in the dom0 or just in general on the machine?
> > 
> > ??
> > As you can see from the attachment, you once had an idea. So should we try to find something...?
> 
> I think that was to instrument swiotlb to give an idea of how
> often it is called and basically have a matrix of its load. And
> from there figure out if the issue is that:
> 
>  1). The drivers allocoate/bounce/deallocate buffers on every interrupt
>     (bad, driver should be using some form of dma pool and most of the
>     ivtv do that)
> 
>  2). The buffers allocated to the drivers are above the 4GB and we end
>     up bouncing it needlessly. That can happen if the dom0 has most of
>     the precious memory under 4GB. However, that is usually not the case
>     as the domain isusually allocated from the top of the memory. The
>     fix for that was to set dom0_mem=max:XX. .. but with Dom0 kernels
>     before 3.1, the parameter would be ignored, so you had to use
>     'mem=XX' on the Linux command line as well.
> 
>  3). Where did you get the load values? Was it dom0? or domU?
> 
> 
> 
> > 
> > ??
> > Carsten.
> > ??
> > -----Urspr??ngliche Nachricht-----
> > An:konrad.wilk <konrad.wilk@oracle.com>; 
> > CC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com>; 
> > Von:Carsten Schiers <carsten@schiers.de>
> > Gesendet:Mi 29.06.2011 23:17
> > Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memory upgrade?
> > > Lets first do the c) experiment as that will likely explain your load average increase.
> > ...
> > > >c). If you want to see if the fault here lies in the bounce buffer 
> > > being used more
> > > >often in the DomU b/c you have 8GB of memory now and you end up using 
> > > more pages
> > > >past 4GB (in DomU), I can cook up a patch to figure this out. But an 
> > > easier way is
> > > >to just do (on the Xen hypervisor line): mem=4G and that will make 
> > > think you only have
> > > >4GB of physical RAM. ??If the load comes back to the normal "amount" 
> > > then the likely
> > > >culprit is that and we can think on how to fix this.
> > 
> > You are on the right track. Load was going down to "normal" 10% when reducing
> > Xen to 4GB by the parameter. Load seems to be still a little, little bit lower
> > with Xenified Kernel (8-9%), but this is drastically lower than the 20% we had
> > before.
> 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:29:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:29:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV38o-0003Nw-P1; Mon, 28 Nov 2011 15:29:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV38n-0003Nd-MU
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:29:10 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322494111!3230353!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 520 invoked from network); 28 Nov 2011 15:28:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 15:28:32 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASFSUM1011952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 10:28:30 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASFSTXS011950;
	Mon, 28 Nov 2011 10:28:29 -0500
Date: Mon, 28 Nov 2011 11:28:29 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Carsten Schiers <carsten@schiers.de>, zhenzhong.duan@oracle.com,
	lersek@redhat.com
Message-ID: <20111128152829.GC9655@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"konrad.wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:
> I got the values in DomU. I will have
> 
>   - aprox. 5% load in DomU with 2.6.34 Xenified Kernel
>   - aprox. 15% load in DomU with 2.6.32.46 Jeremy or 3.1.2 Kernel with one card attached
>   - aprox. 30% load in DomU with 2.6.32.46 Jeremy or 3.1.2 Kernel with two cards attached

HA!

I just wonder if the issue is that the reporting of CPU spent is wrong.
Laszlo Ersek and Zhenzhong Duan have both reported a bug in the pvops
code when it came to account of CPU time.

> 
> I looked through my old mails from you and you explained already the necessity of double
> bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
> Xenified kernel not have this kind of issue?

That is a puzzle. It should not. The code is very much the same - both
use the generic SWIOTLB which has not changed for years.
> 
> The driver in question is nearly identical between the two kernel versions. It is in
> Drivers/media/dvb/ttpci by the way and when I understood the code right, the allo in 
> question is:
> 
>         /* allocate and init buffers */
>         av7110->debi_virt = pci_alloc_consistent(pdev, 8192, &av7110->debi_bus);

Good. So it allocates it during init and uses it.
>         if (!av7110->debi_virt)
>                 goto err_saa71466_vfree_4;
> 
> isn't it? I think the cards are constantly transferring the stream received through DMA. 

Yeah, and that memory is set aside for the life of the driver. So there
should be no bounce buffering happening (as it allocated the memory
below the 4GB mark).
> 
> I have set dom0_mem=512M by the way, shall I change that in some way?

Does the reporting (CPU usage of DomU) change in any way with that?
> 
> I can try out some things, if you want me to. But I have no idea what to do and where to
> start, so I rely on your help...
> 
> Carsten.
> 
> -----Urspr?ngliche Nachricht-----
> Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] Im Auftrag von Konrad Rzeszutek Wilk
> Gesendet: Freitag, 25. November 2011 19:43
> An: Carsten Schiers
> Cc: xen-devel; konrad.wilk
> Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)
> 
> On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:
> > Hello again, I would like to come back to that thing...sorry that I did not have the time up to now.
> > 
> > ??
> > We (now) speak about
> > 
> > ??
> > *	Xen 4.1.2
> > *	Dom0 is Jeremy's 2.6.32.46 64 bit
> > *	DomU in question is now 3.1.2 64 bit
> > *	Same thing if DomU is also 2.6.32.46
> > *	DomU owns two PCI cards (DVB-C) that o DMA
> > *	Machine has 8GB, Dom0 pinned at 512MB
> > 
> > ??
> > As compared to 2.6.34 Kernel with backported patches, the load on the DomU is at least twice as high. It
> > 
> > will be "close to normal" if I reduce the memory used to 4GB.
> 
> That is in the dom0 or just in general on the machine?
> > 
> > ??
> > As you can see from the attachment, you once had an idea. So should we try to find something...?
> 
> I think that was to instrument swiotlb to give an idea of how
> often it is called and basically have a matrix of its load. And
> from there figure out if the issue is that:
> 
>  1). The drivers allocoate/bounce/deallocate buffers on every interrupt
>     (bad, driver should be using some form of dma pool and most of the
>     ivtv do that)
> 
>  2). The buffers allocated to the drivers are above the 4GB and we end
>     up bouncing it needlessly. That can happen if the dom0 has most of
>     the precious memory under 4GB. However, that is usually not the case
>     as the domain isusually allocated from the top of the memory. The
>     fix for that was to set dom0_mem=max:XX. .. but with Dom0 kernels
>     before 3.1, the parameter would be ignored, so you had to use
>     'mem=XX' on the Linux command line as well.
> 
>  3). Where did you get the load values? Was it dom0? or domU?
> 
> 
> 
> > 
> > ??
> > Carsten.
> > ??
> > -----Urspr??ngliche Nachricht-----
> > An:konrad.wilk <konrad.wilk@oracle.com>; 
> > CC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com>; 
> > Von:Carsten Schiers <carsten@schiers.de>
> > Gesendet:Mi 29.06.2011 23:17
> > Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memory upgrade?
> > > Lets first do the c) experiment as that will likely explain your load average increase.
> > ...
> > > >c). If you want to see if the fault here lies in the bounce buffer 
> > > being used more
> > > >often in the DomU b/c you have 8GB of memory now and you end up using 
> > > more pages
> > > >past 4GB (in DomU), I can cook up a patch to figure this out. But an 
> > > easier way is
> > > >to just do (on the Xen hypervisor line): mem=4G and that will make 
> > > think you only have
> > > >4GB of physical RAM. ??If the load comes back to the normal "amount" 
> > > then the likely
> > > >culprit is that and we can think on how to fix this.
> > 
> > You are on the right track. Load was going down to "normal" 10% when reducing
> > Xen to 4GB by the parameter. Load seems to be still a little, little bit lower
> > with Xenified Kernel (8-9%), but this is drastically lower than the 20% we had
> > before.
> 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:31:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3Ai-0003gx-AO; Mon, 28 Nov 2011 15:31:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV3Ah-0003g7-2X
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:31:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322494228!5347469!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6949 invoked from network); 28 Nov 2011 15:30:29 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 15:30:29 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASFURpd012223
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 10:30:28 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASFURsj012220;
	Mon, 28 Nov 2011 10:30:27 -0500
Date: Mon, 28 Nov 2011 11:30:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111128153027.GD9655@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed0ade0.2336.3bb50750629d7fd5@uhura.space.zz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4ed0ade0.2336.3bb50750629d7fd5@uhura.space.zz>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"konrad.wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Nov 26, 2011 at 10:14:08AM +0100, Carsten Schiers wrote:
> To add (read from some munin statistics I made over the time):
> 
>   - with load I mean the %CPU of xentop
>   - there is no change in CPU usage of the DomU or Dom0

Uhh, which matrix are using for that? CPU usage...? This is if you
change the DomU or the amount of memory the guest has? This is not
the load number (xentop value)?

>   - xenpm shows the core dedicated to that DomU is doing more work
> 
> Also I need to say that reduction to 4GB was performed by Xen parameter.
> 
> Carsten.
> 
> 
> -----Urspr?ngliche Nachricht-----
> Von: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] 
> Gesendet: Freitag, 25. November 2011 19:43
> An: Carsten Schiers
> Cc: konrad.wilk; xen-devel
> Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)
> 
> On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:
> > Hello again, I would like to come back to that thing...sorry that I did not have the time up to now.
> > 
> > ??
> > We (now) speak about
> > 
> > ??
> > *	Xen 4.1.2
> > *	Dom0 is Jeremy's 2.6.32.46 64 bit
> > *	DomU in question is now 3.1.2 64 bit
> > *	Same thing if DomU is also 2.6.32.46
> > *	DomU owns two PCI cards (DVB-C) that o DMA
> > *	Machine has 8GB, Dom0 pinned at 512MB
> > 
> > ??
> > As compared to 2.6.34 Kernel with backported patches, the load on the DomU is at least twice as high. It
> > 
> > will be "close to normal" if I reduce the memory used to 4GB.
> 
> That is in the dom0 or just in general on the machine?
> > 
> > ??
> > As you can see from the attachment, you once had an idea. So should we try to find something...?
> 
> I think that was to instrument swiotlb to give an idea of how
> often it is called and basically have a matrix of its load. And
> from there figure out if the issue is that:
> 
>  1). The drivers allocoate/bounce/deallocate buffers on every interrupt
>     (bad, driver should be using some form of dma pool and most of the
>     ivtv do that)
> 
>  2). The buffers allocated to the drivers are above the 4GB and we end
>     up bouncing it needlessly. That can happen if the dom0 has most of
>     the precious memory under 4GB. However, that is usually not the case
>     as the domain isusually allocated from the top of the memory. The
>     fix for that was to set dom0_mem=max:XX. .. but with Dom0 kernels
>     before 3.1, the parameter would be ignored, so you had to use
>     'mem=XX' on the Linux command line as well.
> 
>  3). Where did you get the load values? Was it dom0? or domU?
> 
> 
> 
> > 
> > ??
> > Carsten.
> > ??
> > -----Urspr??ngliche Nachricht-----
> > An:konrad.wilk <konrad.wilk@oracle.com>; 
> > CC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com>; 
> > Von:Carsten Schiers <carsten@schiers.de>
> > Gesendet:Mi 29.06.2011 23:17
> > Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memory upgrade?
> > > Lets first do the c) experiment as that will likely explain your load average increase.
> > ...
> > > >c). If you want to see if the fault here lies in the bounce buffer 
> > > being used more
> > > >often in the DomU b/c you have 8GB of memory now and you end up using 
> > > more pages
> > > >past 4GB (in DomU), I can cook up a patch to figure this out. But an 
> > > easier way is
> > > >to just do (on the Xen hypervisor line): mem=4G and that will make 
> > > think you only have
> > > >4GB of physical RAM. ??If the load comes back to the normal "amount" 
> > > then the likely
> > > >culprit is that and we can think on how to fix this.
> > 
> > You are on the right track. Load was going down to "normal" 10% when reducing
> > Xen to 4GB by the parameter. Load seems to be still a little, little bit lower
> > with Xenified Kernel (8-9%), but this is drastically lower than the 20% we had
> > before.
> 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:31:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:31:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3Ai-0003gx-AO; Mon, 28 Nov 2011 15:31:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV3Ah-0003g7-2X
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:31:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322494228!5347469!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6949 invoked from network); 28 Nov 2011 15:30:29 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 15:30:29 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASFURpd012223
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 10:30:28 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASFURsj012220;
	Mon, 28 Nov 2011 10:30:27 -0500
Date: Mon, 28 Nov 2011 11:30:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20111128153027.GD9655@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed0ade0.2336.3bb50750629d7fd5@uhura.space.zz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4ed0ade0.2336.3bb50750629d7fd5@uhura.space.zz>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"konrad.wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Nov 26, 2011 at 10:14:08AM +0100, Carsten Schiers wrote:
> To add (read from some munin statistics I made over the time):
> 
>   - with load I mean the %CPU of xentop
>   - there is no change in CPU usage of the DomU or Dom0

Uhh, which matrix are using for that? CPU usage...? This is if you
change the DomU or the amount of memory the guest has? This is not
the load number (xentop value)?

>   - xenpm shows the core dedicated to that DomU is doing more work
> 
> Also I need to say that reduction to 4GB was performed by Xen parameter.
> 
> Carsten.
> 
> 
> -----Urspr?ngliche Nachricht-----
> Von: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org] 
> Gesendet: Freitag, 25. November 2011 19:43
> An: Carsten Schiers
> Cc: konrad.wilk; xen-devel
> Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)
> 
> On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:
> > Hello again, I would like to come back to that thing...sorry that I did not have the time up to now.
> > 
> > ??
> > We (now) speak about
> > 
> > ??
> > *	Xen 4.1.2
> > *	Dom0 is Jeremy's 2.6.32.46 64 bit
> > *	DomU in question is now 3.1.2 64 bit
> > *	Same thing if DomU is also 2.6.32.46
> > *	DomU owns two PCI cards (DVB-C) that o DMA
> > *	Machine has 8GB, Dom0 pinned at 512MB
> > 
> > ??
> > As compared to 2.6.34 Kernel with backported patches, the load on the DomU is at least twice as high. It
> > 
> > will be "close to normal" if I reduce the memory used to 4GB.
> 
> That is in the dom0 or just in general on the machine?
> > 
> > ??
> > As you can see from the attachment, you once had an idea. So should we try to find something...?
> 
> I think that was to instrument swiotlb to give an idea of how
> often it is called and basically have a matrix of its load. And
> from there figure out if the issue is that:
> 
>  1). The drivers allocoate/bounce/deallocate buffers on every interrupt
>     (bad, driver should be using some form of dma pool and most of the
>     ivtv do that)
> 
>  2). The buffers allocated to the drivers are above the 4GB and we end
>     up bouncing it needlessly. That can happen if the dom0 has most of
>     the precious memory under 4GB. However, that is usually not the case
>     as the domain isusually allocated from the top of the memory. The
>     fix for that was to set dom0_mem=max:XX. .. but with Dom0 kernels
>     before 3.1, the parameter would be ignored, so you had to use
>     'mem=XX' on the Linux command line as well.
> 
>  3). Where did you get the load values? Was it dom0? or domU?
> 
> 
> 
> > 
> > ??
> > Carsten.
> > ??
> > -----Urspr??ngliche Nachricht-----
> > An:konrad.wilk <konrad.wilk@oracle.com>; 
> > CC:linux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com>; 
> > Von:Carsten Schiers <carsten@schiers.de>
> > Gesendet:Mi 29.06.2011 23:17
> > Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: Load increase after memory upgrade?
> > > Lets first do the c) experiment as that will likely explain your load average increase.
> > ...
> > > >c). If you want to see if the fault here lies in the bounce buffer 
> > > being used more
> > > >often in the DomU b/c you have 8GB of memory now and you end up using 
> > > more pages
> > > >past 4GB (in DomU), I can cook up a patch to figure this out. But an 
> > > easier way is
> > > >to just do (on the Xen hypervisor line): mem=4G and that will make 
> > > think you only have
> > > >4GB of physical RAM. ??If the load comes back to the normal "amount" 
> > > then the likely
> > > >culprit is that and we can think on how to fix this.
> > 
> > You are on the right track. Load was going down to "normal" 10% when reducing
> > Xen to 4GB by the parameter. Load seems to be still a little, little bit lower
> > with Xenified Kernel (8-9%), but this is drastically lower than the 20% we had
> > before.
> 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:35:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3El-00047R-2S; Mon, 28 Nov 2011 15:35:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV3Ej-000479-DK
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:35:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322494481!4993340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26746 invoked from network); 28 Nov 2011 15:34:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 15:34:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9166728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 15:34:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 15:34:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV3E8-0004bU-M1; Mon, 28 Nov 2011 15:34:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV3E8-0003F3-LC;
	Mon, 28 Nov 2011 15:34:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.43536.644117.489480@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 15:34:40 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111071027390.3519@kaball-desktop>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-9-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-10-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-11-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-12-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-13-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1111071027390.3519@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 12/13] libxl: New API for
	providing	OS events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH RFC v2 12/13] libxl: New API for providing OS events to libxl"):
> On Fri, 28 Oct 2011, Ian Jackson wrote:
> > + * There are two approaches available.  The first is appropriate for
> > + * simple programs handling reasonably small numbers of domains:
> > + *
> > + *   for (;;) {
> > + *      libxl_osevent_beforepoll(...)
> > + *      poll();
> > + *      libxl_osevent_afterpoll(...);
> > + *      for (;;) {
> > + *        r=libxl_event_check(...);
> > + *        if (r==LIBXL_NOT_READY) break;
> > + *        if (r) handle failure;
> > + *        do something with the event;
> > + *      }
> > + *   }
> 
> It is good that you included an example here but it doesn't follow the
> CODING_STYLE

I guess you mean the inner indent level being 2 and the missing spaces
near "r=".  Fixed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:35:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3El-00047R-2S; Mon, 28 Nov 2011 15:35:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV3Ej-000479-DK
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:35:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322494481!4993340!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26746 invoked from network); 28 Nov 2011 15:34:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 15:34:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9166728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 15:34:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 15:34:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV3E8-0004bU-M1; Mon, 28 Nov 2011 15:34:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV3E8-0003F3-LC;
	Mon, 28 Nov 2011 15:34:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.43536.644117.489480@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 15:34:40 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111071027390.3519@kaball-desktop>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-9-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-10-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-11-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-12-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-13-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1111071027390.3519@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 12/13] libxl: New API for
	providing	OS events to libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH RFC v2 12/13] libxl: New API for providing OS events to libxl"):
> On Fri, 28 Oct 2011, Ian Jackson wrote:
> > + * There are two approaches available.  The first is appropriate for
> > + * simple programs handling reasonably small numbers of domains:
> > + *
> > + *   for (;;) {
> > + *      libxl_osevent_beforepoll(...)
> > + *      poll();
> > + *      libxl_osevent_afterpoll(...);
> > + *      for (;;) {
> > + *        r=libxl_event_check(...);
> > + *        if (r==LIBXL_NOT_READY) break;
> > + *        if (r) handle failure;
> > + *        do something with the event;
> > + *      }
> > + *   }
> 
> It is good that you included an example here but it doesn't follow the
> CODING_STYLE

I guess you mean the inner indent level being 2 and the missing spaces
near "r=".  Fixed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:41:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:41:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3K5-0004d3-Jn; Mon, 28 Nov 2011 15:40:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV3K4-0004cu-Il
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:40:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322494772!58623295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1718 invoked from network); 28 Nov 2011 15:39:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 15:39:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9166986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 15:40:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 15:40:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Mon, 28 Nov 2011 15:40:13 +0000
In-Reply-To: <20111128152829.GC9655@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322494816.20646.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "lersek@redhat.com" <lersek@redhat.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"konrad.wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 15:28 +0000, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:

> > I looked through my old mails from you and you explained already the necessity of double
> > bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
> > Xenified kernel not have this kind of issue?
> 
> That is a puzzle. It should not. The code is very much the same - both
> use the generic SWIOTLB which has not changed for years.

The swiotlb-xen used by classic-xen kernels (which I assume is what
Carsten means by "Xenified") isn't exactly the same as the stuff in
mainline Linux, it's been heavily refactored for one thing. It's not
impossible that mainline is bouncing something it doesn't really need
to.

It's also possible that the dma mask of the device is different/wrong in
mainline leading to such additional bouncing.

I guess it's also possible that the classic-Xen kernels are playing fast
and loose by not bouncing something they should (although if so they
appear to be getting away with it...) or that there is some difference
which really means mainline needs to bounce while classic-Xen doesn't.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:41:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:41:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3K5-0004d3-Jn; Mon, 28 Nov 2011 15:40:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV3K4-0004cu-Il
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:40:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322494772!58623295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1718 invoked from network); 28 Nov 2011 15:39:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 15:39:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9166986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 15:40:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 15:40:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Mon, 28 Nov 2011 15:40:13 +0000
In-Reply-To: <20111128152829.GC9655@andromeda.dapyr.net>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322494816.20646.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "lersek@redhat.com" <lersek@redhat.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"konrad.wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 15:28 +0000, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:

> > I looked through my old mails from you and you explained already the necessity of double
> > bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
> > Xenified kernel not have this kind of issue?
> 
> That is a puzzle. It should not. The code is very much the same - both
> use the generic SWIOTLB which has not changed for years.

The swiotlb-xen used by classic-xen kernels (which I assume is what
Carsten means by "Xenified") isn't exactly the same as the stuff in
mainline Linux, it's been heavily refactored for one thing. It's not
impossible that mainline is bouncing something it doesn't really need
to.

It's also possible that the dma mask of the device is different/wrong in
mainline leading to such additional bouncing.

I guess it's also possible that the classic-Xen kernels are playing fast
and loose by not bouncing something they should (although if so they
appear to be getting away with it...) or that there is some difference
which really means mainline needs to bounce while classic-Xen doesn't.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:48:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:48:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3Qt-0005Cr-9P; Mon, 28 Nov 2011 15:47:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV3Qs-0005CZ-Gj
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:47:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322495201!45744848!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29134 invoked from network); 28 Nov 2011 15:46:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 15:46:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9167277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 15:47:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 15:47:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV3Q8-0004fg-OO; Mon, 28 Nov 2011 15:47:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV3Q8-0004cs-NJ;
	Mon, 28 Nov 2011 15:47:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.44280.709362.448756@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 15:47:04 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1320055382.23193.38.camel@zakaz.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-8-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-9-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-10-git-send-email-ian.jackson@eu.citrix.com>
	<1320055382.23193.38.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 09/13] libxl: introduce lock
	in	libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH RFC v2 09/13] libxl: introduce lock in libxl_ctx"):
> On Fri, 2011-10-28 at 19:37 +0100, Ian Jackson wrote:
> > +    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
> 
> Is this subtly different to
>        ctx->lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> in some way I'm missing?

I have added a comment about this.  (In my own tree; I'll repost the
series shortly.)

> > +    pthread_mutex_t lock; /* protects data structures hanging off the ctx */
> > +      /* always use MUTEX_LOCK and MUTEX_UNLOCK to manipulate this */
> 
> MUTEX is something of an implementation detail (although I admit we are
> unlikely to use anything else), perhaps CTX_(UN)LOCK?

Renamed.

> Perhaps give the variable a less obvious name to help discourage direct
> use?

I think the comment right next to it ought to be sufficient.

> > +#define MUTEX_LOCK do {                                 \
> > +        int mutex_r = pthread_mutex_lock(&CTX->lock);   \
> > +        assert(!mutex_r);                               \
> 
> This assert is to catch EINVAL ("the mutex has not been properly
> initialized") rather than EDEADLK ("the mutex is already locked by the
> calling thread") since we asked for a non-error-checking recursive lock?

Yes.

> Since it is OK to take this lock recursively then it might be as well to
> say so explicitly?
> 
> This is the first lock in libxl so I guess there isn't much of a locking
> hierarchy yet. Are there any particular considerations which a caller
> must make wrt its own locking?

I have added a comment explaining this.  No requirements are imposed
on libxl's caller.  (Other than the reentrancy ones on callbacks.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:48:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:48:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3Qt-0005Cr-9P; Mon, 28 Nov 2011 15:47:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV3Qs-0005CZ-Gj
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:47:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322495201!45744848!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29134 invoked from network); 28 Nov 2011 15:46:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 15:46:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9167277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 15:47:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 15:47:05 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV3Q8-0004fg-OO; Mon, 28 Nov 2011 15:47:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV3Q8-0004cs-NJ;
	Mon, 28 Nov 2011 15:47:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.44280.709362.448756@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 15:47:04 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1320055382.23193.38.camel@zakaz.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-8-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-9-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-10-git-send-email-ian.jackson@eu.citrix.com>
	<1320055382.23193.38.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 09/13] libxl: introduce lock
	in	libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH RFC v2 09/13] libxl: introduce lock in libxl_ctx"):
> On Fri, 2011-10-28 at 19:37 +0100, Ian Jackson wrote:
> > +    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
> 
> Is this subtly different to
>        ctx->lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> in some way I'm missing?

I have added a comment about this.  (In my own tree; I'll repost the
series shortly.)

> > +    pthread_mutex_t lock; /* protects data structures hanging off the ctx */
> > +      /* always use MUTEX_LOCK and MUTEX_UNLOCK to manipulate this */
> 
> MUTEX is something of an implementation detail (although I admit we are
> unlikely to use anything else), perhaps CTX_(UN)LOCK?

Renamed.

> Perhaps give the variable a less obvious name to help discourage direct
> use?

I think the comment right next to it ought to be sufficient.

> > +#define MUTEX_LOCK do {                                 \
> > +        int mutex_r = pthread_mutex_lock(&CTX->lock);   \
> > +        assert(!mutex_r);                               \
> 
> This assert is to catch EINVAL ("the mutex has not been properly
> initialized") rather than EDEADLK ("the mutex is already locked by the
> calling thread") since we asked for a non-error-checking recursive lock?

Yes.

> Since it is OK to take this lock recursively then it might be as well to
> say so explicitly?
> 
> This is the first lock in libxl so I guess there isn't much of a locking
> hierarchy yet. Are there any particular considerations which a caller
> must make wrt its own locking?

I have added a comment explaining this.  No requirements are imposed
on libxl's caller.  (Other than the reentrancy ones on callbacks.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:53:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3W0-0005WP-7R; Mon, 28 Nov 2011 15:53:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RV3Vx-0005W4-Tn
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:53:06 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322495545!4996437!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.6 required=7.0 tests=FROM_EXCESS_QP,HTML_90_100,
	HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30102 invoked from network); 28 Nov 2011 15:52:28 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 15:52:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=E3ljJkY1nh6a1ekrDc6TFJ60ymTpH
	NVrjgfRw2789OE=; b=UpEHSBzzDUsgz60cY6cJ1ku1StCilIQXm6/PEJQ3g/lfF
	IUv7uvineNkOxxw/C/803urhp0ypeIUNDQvvLukGNjDEsyrd42h7D/ZPJJLzhQc/
	t/Cu8VObPs7a/yoMmHUKOZxjcuwlb8qZRMrRJxQR7dtC3Sq+6mB5CPW1M7XMM0=
Received: (qmail 8419 invoked from network); 28 Nov 2011 16:52:24 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.8.102)
	by mail.zeus06.de with ESMTPA; 28 Nov 2011 16:52:24 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 4A1922C51B;
	Mon, 28 Nov 2011 16:52:24 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id MOxy+90bRDZu; Mon, 28 Nov 2011 16:52:17 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 99DAD2C51A;
	Mon, 28 Nov 2011 16:52:17 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>, 
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Mon, 28 Nov 2011 16:52:17 +0100
Mime-Version: 1.0
In-Reply-To: <20111128152829.GC9655@andromeda.dapyr.net>
References: <20111128152829.GC9655@andromeda.dapyr.net>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ed3ae31.27d6.75459bdc74d06555@uhura.space.zz>
Cc: =?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7373466658977440381=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============7373466658977440381==
Content-Type: multipart/alternative; 
 boundary="=_NUWQF-8k01W10DsG1N5+EZa3ojZPE3HDoZ4sFFhq0eeh0y-I"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_NUWQF-8k01W10DsG1N5+EZa3ojZPE3HDoZ4sFFhq0eeh0y-I
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,=0D=0A=0D=0A=C2=A0=0D=0Alet me try to explain a bit more. Here you see=
 the output of my xentop munin graph for a=0D=0A=0D=0Aweek. Only take a l=
ook at the bluish buckle. Notice the small step in front=3F So it's the C=
PU=0D=0A=0D=0Apermille used by the DomU that owns the cards. The small bu=
ckle is when I only put in=20=0D=0A=0D=0Aone PCI card. Afterwards it's co=
nstantly noticable higher load. See that Dom0 (green) is=20=0D=0A=0D=0Ano=
t impacted. I am back to the Xenified kernel, as you can see.=0D=0A=0D=0A=
=C2=A0=0D=0A=0D=0A=C2=A0=0D=0AIn the next picture you see the output of x=
enpm visualized. So this might be an indicator that=0D=0A=0D=0Arealy some=
thing happens. It's only the core that I dedicated to that DomU. I have a=
 three-core=0D=0A=0D=0AAMD CPU by the way:=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=C2=
=A0=0D=0AIn CPU usage of the Dom0, there is nothing to see:=0D=0A=0D=0A=C2=
=A0=0D=0A=0D=0A=C2=A0=0D=0AIn CPU usage of the DomU, there is also not mu=
ch to see, eventually a very slight change of=0D=0A=0D=0Amix:=0D=0A=0D=0A=
=C2=A0=0D=0A=0D=0A=C2=A0=0D=0AThere is a slight increase in sleaping jobs=
 at the time slot in question, I guess nothing we ca=0D=0A=0D=0Adirectly =
map to the issue:=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=C2=A0=0D=0AIf you need ot=
her charts, I can try to produce them.=20=0D=0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=
Carsten.=0D=0A=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-----=0D=
=0AAn:Carsten Schiers <carsten@schiers.de>; zhenzhong.duan@oracle.com; le=
rsek@redhat.com;=20=0D=0ACC:xen-devel <xen-devel@lists.xensource.com>; ko=
nrad.wilk <konrad.wilk@oracle.com>;=20=0D=0AVon:Konrad Rzeszutek Wilk <ko=
nrad@darnok.org>=0D=0AGesendet:Mo 28.11.2011 16:33=0D=0ABetreff:Re: [Xen-=
devel] Load increase after memory upgrade (part2)=0D=0AOn Fri, Nov 25, 20=
11 at 11:11:55PM +0100, Carsten Schiers wrote:=0D=0A> I got the values in=
 DomU. I will have=0D=0A>=20=0D=0A> =C2=A0 - aprox. 5% load in DomU with =
2.6.34 Xenified Kernel=0D=0A> =C2=A0 - aprox. 15% load in DomU with 2.6.3=
2.46 Jeremy or 3.1.2 Kernel with one card attached=0D=0A> =C2=A0 - aprox.=
 30% load in DomU with 2.6.32.46 Jeremy or 3.1.2 Kernel with two cards at=
tached=0D=0A=0D=0AHA!=0D=0A=0D=0AI just wonder if the issue is that the r=
eporting of CPU spent is wrong.=0D=0ALaszlo Ersek and Zhenzhong Duan have=
 both reported a bug in the pvops=0D=0Acode when it came to account of CP=
U time.=0D=0A=0D=0A>=20=0D=0A> I looked through my old mails from you and=
 you explained already the necessity of double=0D=0A> bounce buffering (P=
CI->below 4GB->above 4GB). What I don't understand is: why does the=0D=0A=
> Xenified kernel not have this kind of issue=3F=0D=0A=0D=0AThat is a puz=
zle. It should not. The code is very much the same - both=0D=0Ause the ge=
neric SWIOTLB which has not changed for years.=0D=0A>=20=0D=0A> The drive=
r in question is nearly identical between the two kernel versions. It is =
in=0D=0A> Drivers/media/dvb/ttpci by the way and when I understood the co=
de right, the allo in=20=0D=0A> question is:=0D=0A>=20=0D=0A> =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 /* allocate and init buffers */=0D=0A> =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 av7110->debi_virt =3D pci_alloc_consistent(pdev, 8192, &av7110->d=
ebi_bus);=0D=0A=0D=0AGood. So it allocates it during init and uses it.=0D=
=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!av7110->debi_virt)=0D=0A> =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto err_saa71466_vfree_4;=0D=
=0A>=20=0D=0A> isn't it=3F I think the cards are constantly transferring =
the stream received through DMA.=20=0D=0A=0D=0AYeah, and that memory is s=
et aside for the life of the driver. So there=0D=0Ashould be no bounce bu=
ffering happening (as it allocated the memory=0D=0Abelow the 4GB mark).=0D=
=0A>=20=0D=0A> I have set dom0_mem=3D512M by the way, shall I change that=
 in some way=3F=0D=0A=0D=0ADoes the reporting (CPU usage of DomU) change =
in any way with that=3F=0D=0A>=20=0D=0A> I can try out some things, if yo=
u want me to. But I have no idea what to do and where to=0D=0A> start, so=
 I rely on your help...=0D=0A>=20=0D=0A> Carsten.=0D=0A>=20=0D=0A> -----U=
rspr=3Fngliche Nachricht-----=0D=0A> Von: xen-devel-bounces@lists.xensour=
ce.com [mailto:xen-devel-bounces@lists.xensource.com] Im Auftrag von Konr=
ad Rzeszutek Wilk=0D=0A> Gesendet: Freitag, 25. November 2011 19:43=0D=0A=
> An: Carsten Schiers=0D=0A> Cc: xen-devel; konrad.wilk=0D=0A> Betreff: R=
e: [Xen-devel] Load increase after memory upgrade (part2)=0D=0A>=20=0D=0A=
> On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:=0D=0A>=
 > Hello again, I would like to come back to that thing...sorry that I di=
d not have the time up to now.=0D=0A> >=20=0D=0A> > =3F=3F=0D=0A> > We (n=
ow) speak about=0D=0A> >=20=0D=0A> > =3F=3F=0D=0A> > *Xen 4.1.2=0D=0A> > =
*Dom0 is Jeremy's 2.6.32.46 64 bit=0D=0A> > *DomU in question is now 3.1.=
2 64 bit=0D=0A> > *Same thing if DomU is also 2.6.32.46=0D=0A> > *DomU ow=
ns two PCI cards (DVB-C) that o DMA=0D=0A> > *Machine has 8GB, Dom0 pinne=
d at 512MB=0D=0A> >=20=0D=0A> > =3F=3F=0D=0A> > As compared to 2.6.34 Ker=
nel with backported patches, the load on the DomU is at least twice as hi=
gh. It=0D=0A> >=20=0D=0A> > will be "close to normal" if I reduce the mem=
ory used to 4GB.=0D=0A>=20=0D=0A> That is in the dom0 or just in general =
on the machine=3F=0D=0A> >=20=0D=0A> > =3F=3F=0D=0A> > As you can see fro=
m the attachment, you once had an idea. So should we try to find somethin=
g...=3F=0D=0A>=20=0D=0A> I think that was to instrument swiotlb to give a=
n idea of how=0D=0A> often it is called and basically have a matrix of it=
s load. And=0D=0A> from there figure out if the issue is that:=0D=0A>=20=0D=
=0A> =C2=A01). The drivers allocoate/bounce/deallocate buffers on every i=
nterrupt=0D=0A> =C2=A0 =C2=A0 (bad, driver should be using some form of d=
ma pool and most of the=0D=0A> =C2=A0 =C2=A0 ivtv do that)=0D=0A>=20=0D=0A=
> =C2=A02). The buffers allocated to the drivers are above the 4GB and we=
 end=0D=0A> =C2=A0 =C2=A0 up bouncing it needlessly. That can happen if t=
he dom0 has most of=0D=0A> =C2=A0 =C2=A0 the precious memory under 4GB. H=
owever, that is usually not the case=0D=0A> =C2=A0 =C2=A0 as the domain i=
susually allocated from the top of the memory. The=0D=0A> =C2=A0 =C2=A0 f=
ix for that was to set dom0_mem=3Dmax:XX. .. but with Dom0 kernels=0D=0A>=
 =C2=A0 =C2=A0 before 3.1, the parameter would be ignored, so you had to =
use=0D=0A> =C2=A0 =C2=A0 'mem=3DXX' on the Linux command line as well.=0D=
=0A>=20=0D=0A> =C2=A03). Where did you get the load values=3F Was it dom0=
=3F or domU=3F=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> >=20=0D=0A> > =3F=3F=0D=
=0A> > Carsten.=0D=0A> > =3F=3F=0D=0A> > -----Urspr=3F=3Fngliche Nachrich=
t-----=0D=0A> > An:konrad.wilk <konrad.wilk@oracle.com>;=20=0D=0A> > CC:l=
inux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com>;=20=
=0D=0A> > Von:Carsten Schiers <carsten@schiers.de>=0D=0A> > Gesendet:Mi 2=
9.06.2011 23:17=0D=0A> > Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: =
Load increase after memory upgrade=3F=0D=0A> > > Lets first do the c) exp=
eriment as that will likely explain your load average increase.=0D=0A> > =
=2E..=0D=0A> > > >c). If you want to see if the fault here lies in the bo=
unce buffer=20=0D=0A> > > being used more=0D=0A> > > >often in the DomU b=
/c you have 8GB of memory now and you end up using=20=0D=0A> > > more pag=
es=0D=0A> > > >past 4GB (in DomU), I can cook up a patch to figure this o=
ut. But an=20=0D=0A> > > easier way is=0D=0A> > > >to just do (on the Xen=
 hypervisor line): mem=3D4G and that will make=20=0D=0A> > > think you on=
ly have=0D=0A> > > >4GB of physical RAM. =3F=3FIf the load comes back to =
the normal "amount"=20=0D=0A> > > then the likely=0D=0A> > > >culprit is =
that and we can think on how to fix this.=0D=0A> >=20=0D=0A> > You are on=
 the right track. Load was going down to "normal" 10% when reducing=0D=0A=
> > Xen to 4GB by the parameter. Load seems to be still a little, little =
bit lower=0D=0A> > with Xenified Kernel (8-9%), but this is drastically l=
ower than the 20% we had=0D=0A> > before.=0D=0A>=20=0D=0A> > ____________=
___________________________________=0D=0A> > Xen-devel mailing list=0D=0A=
> > Xen-devel@lists.xensource.com=0D=0A> > http://lists.xensource.com/xen=
-devel=0D=0A>=20=0D=0A>=20=0D=0A> _______________________________________=
________=0D=0A> Xen-devel mailing list=0D=0A> Xen-devel@lists.xensource.c=
om=0D=0A> http://lists.xensource.com/xen-devel=0D=0A>=20=0D=0A=0D=0A_____=
__________________________________________=0D=0AXen-devel mailing list=0D=
=0AXen-devel@lists.xensource.com=0D=0Ahttp://lists.xensource.com/xen-deve=
l=0D=0A
--=_NUWQF-8k01W10DsG1N5+EZa3ojZPE3HDoZ4sFFhq0eeh0y-I
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv
bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+PGh0bWw+
CjxoZWFkPgogIDxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iWmFyYWZhIFdlYkFj
Y2VzcyB2Ny4wLjItMjk0NzAiPgogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4KICA8dGl0bGU+QVc6IFtYZW4t
ZGV2ZWxdIExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5IHVwZ3JhZGUgKHBhcnQyKTwvdGl0
bGU+CiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KICAgICAgYm9keQ0KICAgICAgew0KICAg
ICAgICBmb250LWZhbWlseTogQXJpYWwsIFZlcmRhbmEsIFNhbnMtU2VyaWYgISBpbXBvcnRh
bnQ7DQogICAgICAgIGZvbnQtc2l6ZTogMTJweDsNCiAgICAgICAgcGFkZGluZzogNXB4IDVw
eCA1cHggNXB4Ow0KICAgICAgICBtYXJnaW46IDBweDsNCiAgICAgICAgYm9yZGVyLXN0eWxl
OiBub25lOw0KICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmZmOw0KICAgICAgfQ0K
DQogICAgICBwLCB1bCwgbGkNCiAgICAgIHsNCiAgICAgICAgbWFyZ2luLXRvcDogMHB4Ow0K
ICAgICAgICBtYXJnaW4tYm90dG9tOiAwcHg7DQogICAgICB9DQogIDwvc3R5bGU+CjwvaGVh
ZD4KPGJvZHk+CjxwPkhpLDwvcD48cD4mbmJzcDs8L3A+PHA+bGV0IG1lIHRyeSB0byBleHBs
YWluIGEgYml0IG1vcmUuIEhlcmUgeW91IHNlZSB0aGUgb3V0cHV0IG9mIG15IHhlbnRvcCBt
dW5pbiBncmFwaCBmb3IgYTwvcD48cD53ZWVrLiBPbmx5IHRha2UgYSBsb29rIGF0IHRoZSBi
bHVpc2ggYnVja2xlLiBOb3RpY2UgdGhlIHNtYWxsIHN0ZXAgaW4gZnJvbnQ/IFNvIGl0JiMz
OTtzIHRoZSBDUFU8L3A+PHA+cGVybWlsbGUgdXNlZCBieSB0aGUgRG9tVSB0aGF0IG93bnMg
dGhlIGNhcmRzLiBUaGUgc21hbGwgYnVja2xlIGlzIHdoZW4gSSBvbmx5IHB1dCBpbiA8L3A+
PHA+b25lIFBDSSBjYXJkLiBBZnRlcndhcmRzIGl0JiMzOTtzIGNvbnN0YW50bHkgbm90aWNh
YmxlIGhpZ2hlciBsb2FkLiBTZWUgdGhhdCBEb20wIChncmVlbikgaXMgPC9wPjxwPm5vdCBp
bXBhY3RlZC4gSSBhbSBiYWNrIHRvIHRoZSBYZW5pZmllZCBrZXJuZWwsIGFzIHlvdSBjYW4g
c2VlLjwvcD48cD4mbmJzcDs8L3A+PHA+PGltZyBhbHQ9IiIgc3JjPSJkYXRhOmltYWdlL3Bu
ZztiYXNlNjQsaVZCT1J3MEtHZ29BQUFBTlNVaEVVZ0FBQWZFQUFBR0VDQUlBQUFDcHY0NVlB
QUFnQUVsRVFWUjRuTzI5ZjNSVTFiMzN2OE1rRUFKbVFpQ1dZRG9RTVNRd2t5QWRpajhlOWZI
YmRhdFdYYWdGTHZXcXZiMjFwYmY0STRCV3k3SUw1MUdxVDRVU2JUQmxsaFhTYUJETVRFS0NY
TFdJSkNwM0dSMm9UUUVSRTJoUmhKbE15SS85ejEzcitlTjgvOWpKenM3WjU1elpjMmJPelBu
eGVhMVpzMmJPZk00NW43Tm5uL2U4WjgrWnowWi9CUUFBQUd4QloyY255bllPQUFBQVFCcm83
T3pjdVhQbnFLWmpBQUFBd01yczNMa1ROQjBBQU1BbWdLWURBQURZQjlCMEFBQUErd0NhRGdB
QVlDVmFPTmhYUWRNQlFCbUVVTFpUU0FJelpHdUdISnpEeU1nSVVYUFFkTUFPR0NjZmRNdjhn
N1JzMWlETW9LZG15TUVoREEwTmZmcnBwNkZRNlB6NTg2MnRyZXhMb09uTzRyNzc3dnZwVDMv
S0x2bVAvL2lQKysrL1A1VnRJb1FRUWprNU9aZGRkbGxOVGMzNjlldlBuajJiV3BwcFJsRnJF
a3AyaWdxVllZRXpnNTZhSVFjbmNQTGt5WTZPanE2dXJ0T25UN2UydG43NjZhZnNxNkRwemlJ
YWpTNWF0R2puenAzazZhdXZ2dXIxZW1PeFdDcmJwR2R5TkJyOTZLT1Bmdm5MWDVhV2xwNDRj
U0xWWE5NSGFMcHpjbkFDNzcvLy92bno1OVZlQlUxM0hFZVBIdjNXdDc1MTdOaXhZOGVPelo0
OW03enZRME5ER3pac21EVnIxdFNwVTFlc1dISGh3Z1VTakJCNjhjVVhQUjVQWGw1ZVRVM05r
U05IK0EzeVovS1RUejc1b3gvOWlEenU3Ky8vOTMvLzk4c3V1K3l5eXk3N3lVOSswdC9mVDll
cXE2dWJPM2Z1NU1tVEZ5NWMrSmUvL0dYSGpoM3o1ODhuTy9yNDQ0OUoyTi8vL3ZjZi9PQUgw
NlpObXpKbHl2ZS8vLzB6Wjg3SWRxb3ZRN29RTWZCYjVoL3c4WW9aYW14V28wRVNIb2dHQ0tG
bm4zMjJwS1Nrb0tEZy92dnZqOGZqR09QcnI3OSsxNjVkTk9ia3laT3paODltNWFDOHZQeVRU
ejRoajNmczJFRWVmUExKSitYbDVWaTlWMmowRnZMZ2d3OCttRE5uenU5Kzk3dWtEZ0ZJQzZE
cFR1UlBmL3FUMSt2MWVyMk5qWTFreVc5Kzg1dnZmZTk3cDA2ZHVuRGh3bjMzM2Zlem4vMk1M
RWNJclZpeDRvc3Z2b2hHbzA4OTlaVGY3K2UzeGl2bXlaTW52L1d0YjVISGp6NzY2SzIzM25y
bXpKbSt2cjUvK1pkL3FhMnRwV3N0WDc3ODg4OC9qMGFqVHovOTlQVHAwKys1NXg3NjlMdmYv
UzRKcTZxcWV1dXR0Mkt4MlBuejU5ZXVYYnQ2OVdyWlR2VmxpTlY5dXNoNGVuMTkvVzIzM1Nh
WW9leXBSb01rUEJBTkVFSmtzMmZPbkxuMTFsdlhyVnVITVc1cmE2dXNyQndlSGlZeFAvN3hq
NTk1NWhsMnJaLy8vT2QxZFhVWTQxT25UazJmUHAybzg3WnQyOWFzV1lQVmU0VkdiOEVZdDdT
MHpKbzFhOCtlUFVubEQ0Z0QxNzBBQ2l4WnNtVHAwcVgwcWNmak9YYnNHSG5jMTlkMytlV1hr
OGNJb1hQbnpwSEgwV2cwTnplWDN4UXZlWmN1WGNyTHl5T1BTMHRMUC92c00vTDRyMy85NjV3
NWMraGEvL3puUCttV1pVOFZkeFNOUm1mTm1pWGJxYjRNY1FxYTN0SFJzWGp4WW1wT0UyWW9l
NnJSSUFrUFJBT0UwTi8rOWpmeStMUFBQcnZpaWl2SVk3L2YvK3FycjlLRjBXaVVYV3Z2M3Iw
clZxekFHRC96ekRPelpzM2F2bjA3eHZpSFAvemhtMisraWRWN2hVWnYrZjN2ZjE5YVd0cloy
WmxVOG9BTzRMb1hZSndkTzNaY2ZmWFZWMTk5OVovKzlDZXlKRGMzbHgwdXlNbkpJY3ZWaEVs
N0lmbU9UeDY3WEs2aG9TSHllSEJ3a0VxVjlwYnAwL2ZlZSsrNjY2NHJLQ2hRUzB3a3cwbVRK
dEVjQ0VORFE1TW1UZExlZ3VJdVB2MzAwL256NTdPL0ZpVE1VUFpVWDRQUWhleDRqdXdseGMz
dTJiT25vcUppYUdobzFhcFZXN1pza2ExMThlTEZiMy83MnhoanI5Y2JDb1d1dWVZYWpQRzN2
LzF0SXYxcXZVS2p0OHliTisreHh4N2owd1BTQzF6M0Fveno2YWVmbHBhVy92M3ZmKy9wNlNr
dExUMTY5Q2pHdUt5czdJc3Z2dUNEOVduNmswOCtlZSs5OTVMSHBhV2wxRC8rOWE5L0xTMHRG
ZGt5ZlRwbnpwekd4c2J6NTgrUGpJeDg4ODAzQ1UyMFlvWWVqK2UvLy91LzJTVWZmZlNSeCtQ
UjNnTC80TXlaTXhVVkZRY1BIbVRqRTJZb2U2cXZRUkxDK3ZTLy9lMXYxUDZQakl4NHZkN2Ey
bHFQeHpNd01NQ3ZlT09OTi83NXozOG1RejErdjMvUG5qMDMzWFFUZVVtdFYyajBsbE9uVGwx
NTVaV2JOMjlPS25rZ0tlQzZGMkNjYURTNmNPSENOOTU0Z3p4OS9mWFh5WFV2VHovOTlLMjMz
dHJUMHpNNE9Qanh4eCtUNytNNFNVMG4xNzJzWGJ1V3ZlN2w0WWNmcHVPODMvLys5eDk1NUJH
UkxkT25NMmJNMkxOblR6d2UvL3ZmLzc1aXhRcDltdjUvL3MvL1diSmt5ZnZ2dngrUHgrUHgr
S0ZEaHhZdlhreDF4KzEyMDVFRXhTM1RCOS85N25mcEQ0a1V0UXpWTnF1dlFSS0NFUHJCRDM1
dzl1elpzMmZQM25iYmJYU1lIbVBjMk5pSUVIcjU1WmNWVjN6bW1XZm16SmxETFB3TEw3eHd4
UlZYUFB2c3MrUWx0VjZoM1Z0T256NWRVVkVSQ0FTU3loOFFCNjU3QWNhNTc3NzdxSWdRZnZu
TFg5NTMzMzNEdzhPQlFJQmNkTEZvMFNMNjI2bjRnRUJPVHM2MGFkT3FxNnZYclZ0SHIwN0JH
TWRpc1FjZWVHRDY5T25UcDA5LzRJRUg2SFdUZ3ByK3hodHZ6SnMzeitWeWZmdmIzOTZ5Wllz
K1RSOFpHZG15Wll2WDY1MHlaY3FVS1ZPOFh1L3ZmLzk3K3VxbVRadW1UWnVtc1dYMkFZdDJo
bXFiMWRjZ0NVSE1kUy8zM1hjZnZad0dZL3phYTYvTm56OS9jSEJRY2NValI0N2s1dWFTdnhT
Y09YTW1OemVYZnFkUjZ4VUplMHR2YjI5bFplVnZmdk9icEE0QlNBdWc2UUJnYzI2Ly9YYjZq
d1RBQnNCMUx3RGdVSWFIaCt2cjY2dXFxdWpsaklBTmtJazRhRG9BT0FXRWtNZmpnU3NMYlVa
cmErdWxTNWZJNDB1WExzRjFMd0FBQUJhbXM3UHprMDgrR1J3Y0hCd2MvT1NUVDdxNnV0aFhR
ZE1CQUFDc1JIOS8vK0hEaDhQaGNEZ2M3dXpzWkg4UHg2RHBBQUFBbGdiRzB3RUFBT3dEYURv
QUFJQ0ZjZEMxakQwSER2UWNPSkR0TEFBQUFES0hiVFY5TUI3ZmR0MTEyNjY3YmpBZXozWXVB
QUFBR2NLMm12NlgzLzB1NFBFRVBKNi9RQ1YrQUFDY2lrMDAvZnlwVTVzcktvaW1iNjZvT0gv
cVZMWXpBZ0FBTUlSWUxOYloyVW12WlpUTlBaa2RUVzlxYXFxcXFzckx5NnV1cnU3bzZNQVlm
L0hGRjlkZWUrM2t5Wk92dmZaYVVzWlRaTW40Qmg5NGdBZzZ1VFU5OEVER2pnVUFBQ0NUSER4
NDhOaXhZNWN1WGJwMDZkTFJvMGRseForem8rbjMzSE5QZDNkM2YzLy85dTNiWjg2Y2lURmV1
WExsaGcwYit2djdOMnpZc0dyVktzRWxNcDU0NGdueTRQVHAweUpwWElwRVJNSkV0aWE0UjVF
d3lFbzhETElTRHpOblZsZ3NzVFR1MFp4WkpVVW9GS0lGZklhSGgwT2hFUHRxbHNkZVRwdzRR
YVltbURselpsOWZIOGE0cjYrUHFMeklFaGxVMHovODhFT1J2WCt6ZmJ0SW1NaldCUGNvRWda
WmlZZEJWdUpoNXN3S2l5V1d4ajJhTTZ1a01LTlBKL1QyOWk1WnNtVHYzcjBZNDBtVEpwRlBu
cUdoSVpmTEpiaUVNdlRQZjM3ejBrdVAvL3puK1BCaFNaSUdEeDZVSklrODFyai9mN0ZZd2hq
QnJRbnU4WC8rNTM4Z0s4Z0tzbUx2aHpvNk1ybEg4MlQxLytMeGIxNTZhYUM3TzFubGpFYWpw
aHRQeHhoM2RuWjZQSjVYWG5tRlBDMHVMcFo1Y0pFbE1wNTQ0Z2xKa2lSSjZ1M3RsUVRBWFYw
aVlTSmJFOXlqU0Joa0pSNEdXWW1IbVRNclNTeXhOTzdSVkZrWklhM1owZlQ2K3ZxU2twSjkr
L2JSSlN0V3JLQmo1V1FxTEpFbE1xaW1Bd0FBbUI5OSttbkc2MTVrYzRCZHZIang4ODgvWDda
c1dWNWUzalhYWEhQcTFDbU1zY2dTR2VEVGRjUUloa0ZXNG1HUVZWSmg0Tk9UeGJ6ajZXa0hm
RG9BQUJaQ245Q1orcnFYOUFJK1hVZU1ZQmhrSlI0R1dTVVZCajQ5V2NDbkF3QUFtQkY5UW1m
UzYxNk1BSHk2amhqQk1NaEtQQXl5U2lvTWZIcDZzYWVtQXdBQW1COTlRdWVJK3VtWExsMDZj
ZUxFVDMvNlUwbVMrdnI2ZW50NysvcjZ5R09OK3hNZEhRbGpCTGNtdU1jalI0NUFWcEFWWk1Y
ZTQ2NnVUTzdSUEZsOThjVVhKMDZjMEZFNVFDYmlNbXlpNlFUdzZRQUFXQWg5UXVkRVRZZnhk
UEVZd1RESVNqd01za29xRE1iVGs4V0ptZzRBQUdCK2pKQkJlMm82K0hUeEdNRXd5RW84RExK
S0tneDhlbnF4cDZZREFBQ1lIeDBxOTlaYmIzVjNkL2YxOVEwTkRTa0daTG5lQzEzUzNOeGNY
bDd1Y3JubXpadlgzTnlNazV6bmlBQStYVWVNWUZqR3NrSjF5SVJaSlJVR1dTVVZCajQ5S2I3
NTVwdWVucDVEaHc2MXRyWWVPblNvcDZmbm0yKytZUU95NmROWlRTOHNMQXlIdy9GNFBCUUt1
ZDF1ckhlZUk1RW1Cc3dNMVhRQXNEMnA2T2ZnNEdCZlgxOTNkL2RiYjczRkxqZUxwdnQ4dm5B
NFBEQXdFQXFGYW1wcXNONTVqa2hMZ1U4WGp4RU15MHhXcUE0RkFnR3paWlZzR0dTVlZCajQ5
UFJpRmswL2ZQaHdZV0VoUXFpd3NQRHc0Y000dFhtTzRONmk5NmdPZFpSdE1rTW1jQS8zUnQv
cm51ZElHN05vK3Z6NTgrbll5MVZYWFlWaG5xTjBiTXB5V2FFNkZFUkJzMldWYkJoa2xWUVkr
UFQwWWhaTkx5b3FvbU12TTJiTXdERFBrU01KQkFMK01VMEhBTnVURmlFMVJiMFgyVHhIR09P
bXBpYVB4K055dWViT25mdjY2NjlqbU9jb0hadXlYRlpCRlBTRFQwOHlSakRNbkZsSjROTlR4
aFNhYmhEZzA2MU9FQVdsQ0Z6M0FqZ0ZmVUxuaUxxTUJQRHBPbUlFd3pLVGxSOEZwUUJjbjU1
Y2pHQ1lPYk9Td0tlbmpDTTBIYkFvcktackE1ZXhBellnTGJybkNFMEhueTRlSXhobU5wOU9M
bzl4Y2xzbEcyYk9yQ1R3NmVuR0pwb3VteE1EN3ExNnY5a3JCWkJJNUYzZWh1eG5DL2R3bjhL
OTdqa3hZckVZekVlcWpEbWRpNk96Q2lCQm4rNEhuNTVrbURtemtzQ25KOC9CZ3dlUEhUdDI2
ZEtsUzVjdUhUMTY5T0RCZyt5cjl0UjB3S293bXE0TlhNWU8yQUI5UWhjS2hjZy82akhHdzhQ
RG9WQ0lmZFdlbWc0K1hUeEdNQ3hEL3lOZHMxLzB1cGNBeWxoV3lZWkJWa21GZ1U5UEZ2RHBn
R1ZnTlQwQmdtRUFZR0wwQ1YwMEdvWHhkSlVHTmFWemNYSlc0Tk4xeEFpR21UTXJDWHg2dWpI
TG5CakR3OE1iTjI0c0xTM055Y2toeTFPWkV3T3dLT0RUQVVlaFR6L04rejlTVnRNM2JkcTBZ
TUdDN3U3dWtaRVJzaVNWT1RIQXA0dkhDSWFCVHhjUGc2eVNDZ09mbml4RXhLbVVtMVRUUFI2
UDdOZmJWT2JFQUN3SytIVEFVZWhUem5BNGZPSENoVkFvOU0wMzMzenp6VGR0Ylczc3EyYlJk
SmZMOWRCREQwMmRPdFhqOGV6WnN3ZW5OaWRHMzk2OWtrQk5ldHpWSlZLOVhtUnJnbnZzN2Uy
RnJEUmkwSnI5K05FeW9hd0N5T0Z0Wlkrc0pFbnEvK01mTTdsSDgyU2xlMDZNVHo3NXBMVzE5
ZVRKazIrOTlWWTRIRDUrL0RqN3FsazBmZWJNbWFGUWlNeUpNV3ZXTEp6YW5CaUFSUUdmRGpn
S0kzVFZMSnErYXRXcVVDaEU1c1FvS1NuQnFjMkpBZVBwNGpHQ1lUQ2VMaDRHV1NVVkJ1UHB5
V0xHMzBqNU9URk9uejU5d3cwMzVPWGxsWmVYazRIMVZPYkVBQ3dLK0hUQVVSaWhybkI5ZW1M
QVQwbmcwNU1KZzZ5U0NnT2ZubDdzcWVtQVJRR2ZEamdLSTJUUW5wb09QbDA4UmpBTWZMcDRH
R1NWVkJqNDlQUmlUMDBITEFyNGRIRmdwaWNib0Uvb29INjZlb09hMHJrNE9Tdnc2ZUl4Z1VE
QWhGbnBDQU9mbml5T3FNc0k4eHpaNDk2N1lZL2dQRWQ5bTcxWnp6Ykw5MTdIdDRERjczWFBj
d1QxMDFVeHAzTnhjbGJnMDVPSVFVZ29MTU5aSlI4R1BqMVpIT0hUQ1RDZWJuVmdQRDBKa09O
YndQcm9FenFvbjY3ZW9LWjBMazdPQ254NkVqSGcwM1dGbVNvckkyVFFucG9PV0JUdzZVa0FQ
dDM2NkJNNk05WUdNQWp3NlRwaUJNUEFwNHVIZ1U5UEtneDhlcktZc1g0NlA4OFJZZVBHalhR
aHpIUGtRRmhOUjNWSTZ4SnM4T25nMDYyUFB2MDBvNllUWkpyZTFkVTFlL1pzdWhEbU9VcDlV
NWJMaXRYMGQzdDlhcHFPNmhENGRQRHArc0pNbFpVKzViU0dwdmYzOTN1OTNnTUhEdENGTU0r
UkEyRTEzWStDUVJSVURodlRkRWNEUHQzNnBFVklUYXJwYTlldWZmNzU1OW1GTU0rUkE3Tmk1
em02eTlld3ZteVRZbVRQNFRLWTUwaEN5SXhaSmRsV0VzeHpsUHc4UnpKTXF1azVPVG15aXVv
d3o1RURrZmwwdjRwUDk2TWcrSFR3NlRaQW4zS2E5N29YL2pkU2RpSE1jNVQ2cGl5WDFZVHJY
amI3Wk1KTmg5ZXBwanU1clNRMC9odXlpYkpLUGd6RzAxUEVGSnJPejNQRXZrUWV3RHhIRG1U
Qzlla0IrYUE1SFY0SG55NUpFelFkc0NocGtWTlRhTHBCZ0UvWEVTTVlaZ2FmUHY2VGFRQkpB
WVRxa0pQYlNrS0lEcitZS0t2a3c4Q25weGQ3YWpwZ1VSUjlPcjFRM1Q5UjA5V3VpbkVLaktZ
REZrV2YwSmwzUEQzdGdFL1hFU01ZbGtXZnJxYnBmaFIwY2x1QlQ5Y1hacXFzakpCQmUybzZZ
RkVVZlhwdzdFSjFYdE96azZWSkFKOXVmZlFKblNOOHVteE9qTjdlWHBHYTlDYzZPaExHQ0c1
TmNJOUhqaHlCckRSaTJEa3hqangvTzNuc1I4Rzd2QTJvRHQzbGJSaU5ES0MrelY0L0NqcTVy
ZnE4WGdraDAyV1ZaRnYxOWZYaHJpN2RlMFIxS05rOUNtYTFmR09aMGUyZ2UwNE1qUEhBd01B
Nzc3elQydHA2OXV4WjJVczIwWFFDK0hTcm8ralR5WVhxUWZaYUYvS1N3eTk5QVo4dUdYbVJm
a2JhVnAvUUVVRS9kdXpZVjE5OXRXL2Z2dlBuejdPdjJsUFQ2UUNXOXNWZTVoeGhkSEpXaXVQ
cDVNcEZ2NUttTzdtdFlEeGRrdVRLbTg3eDlMS3lkRzBxN2VQcGI3LzlOcFhyTDcvOHNxT2pn
MzNWbnBvK0RoZ1pTNkY4ZlRvZFBRZWZ6Z0krWFVyL0NUNWVEZFRFUGwybTFjZVBIMmVmSnRE
MGd3Y1BWbFJVNU9Ua1lJeFhyMTdkMk5pb0w0bk1vSERkaStZYlkwN240dVNzbEs5UG42anBv
d1c4d0tlRFQ1Y004T2tJa1Q5em1kbW5wL1FiNlZWWFhkWFcxa2IrMi9uNTU1L1BuVHRYWHhL
WkFYeTYxZEh3NmZScElCQUFueTVKNCtxVDdUeXlTdHBQY0lRa2hBS0JnSmw5ZWtxMWR2UHk4
dUx4T05IMGMrZk9GUlFVNkV0Q0JsOFZvS21wcWFxcUtpOHZyN3E2bWd3UHBUSW5ocS9PTi80
T2FUU29LWjJMazdOQ2EvYWpOZnRId3liNmRQYlNSdkRwa2pUbTB4RXlWMWJKaDVuUXAwdkk3
RDRkNjliMG0yKytlY2VPSFFpaDA2ZFByMTY5ZXZueTVmcVNVSVRWOUh2dXVhZTd1N3UvdjMv
Nzl1Mms1bUlxYzJLTXY5UGcweTBGcSttS1BoM1ZqUTNDZ0U5bk5OMjVHT1BUTTlhdytwUXpK
VTAvZmZyMG5YZmVXVkJRVUZCUXNIejU4bi84NHgvNmtsQkVzUzdqaVJNblBCNFBUbTFPakY2
ZmIvUzNEdkRwYWRxVVNYeTZUTk9kM0ZiZzB5WEpvVDVkRzNQVjJ1M3Q3VjJ5Wk1uZXZYdHhh
bk5pNExJeVZJZnVmcktNblRjQTdzMS9qOWJzdi91QmJhTkxBbWgwZm94SHkwWWZCMUJIMlNZ
L0NvNHZNVUhPV2JzbnV1UHdIbDZXN2o1QVd6WHRXK2J1ZGMrSllkNy9rY28wdmJPejArUHh2
UExLSytScEtuTmk5UHA4SWwrZ3pPbGNuSnhWUXA4K09sRUcrSFFKZkxva1NZNzI2U01qSTdK
QkdJS3lwaU4xVWtsQ0JydTErdnI2a3BLU2ZmdjIwU1dwekltUjRVRXhJRjBrSEUrZk1KZ080
K25RdzQwZlR6ZjB5aUxkNGprME5QVHBwNStHUXFIejU4KzN0cmF5TDVsbFRnelprb3NYTDZZ
eUp3YjRkUEVZd1REeitIVDJxWlBiQ255NkpHWEVwNnRyU0xaOCtzbVRKenM2T3JxNnVrNmZQ
dDNhMnZycHA1K3lyOXIwZjZUZzA2MEorUFFrZ0I0dVplUzZsNG03U0s5dDF5ZDA3Ny8vdnF6
R0MwczJ4MTdTRHZoMEhUR0NZU2J4NmJLYms5c0tmTG9rWmNPbk0wL2h1aGZEQVo5dWRYaWZ6
bFlDVUxnNUdlamhVaFo4ZW5yM2FJUU0ybFBUd2FlTHh3aUdaY3VuYTJ1Nms5c0tmTG9rWmMy
bmt4RVlpL2wweFo4dXJUTDJBajdkb2xCTnAxSWVsQTJnZzArblFBK1hzdWZUMDdSZkkyVFFK
ajVkUHMrUnp6YzZDNHpYSzFsdDVoY25aK1hkc0FldDJVL21yeUh6SE4zbGJaQUNxRyt6Vi9I
ZXlXM0Y5bkFUWlpWa1cvV2xOcytSaE5JOXo5RllxK0t5c3ZFbC9CNFJTcjBkVXBublNBT2Jh
RG9CZkxyVm9UNDlJcWxjNkFJK25RSTlYQUtmcmtBQ1RkKzllN2ZINDhuSnliSFcyQXVNcDR2
SENJWmxlRHc5aUlLajE3MUVZRHhkQlJoUGw3SjMzWXR3czJ1SEdTR0RDVFI5NXN5WnI3MzIy
dERRa0JIN1RqdmcwNjBPMWZRRTloeDh1Z1ErWFpLa1RQdjA4YktBMXZYcFJVVkYwV2pVaUIw
YkFmaDBIVEdDWVJuMjZYN3EwelZ2VG00cjhPbVNsSEdmanBEbGZmcFRUejIxY2VQRy92NStJ
L2FkZHNDbld4M3c2VWtBUFZ6SytIZzZHcHRieXJvK3ZibTVlY3FVS1dtL2xwSGZtc2lzUnVM
ekhJRlBGNDhSRE12MDlla0JCRDQ5UVF6NGRDbExQajJaWnRjT1M0dWN5a2lnNlNVbEpjM056
UWFOcDdPYUxqS3JVWEx6SEkzZG5ENWhvNlZnTlIxOGVnTEFwMHZaOGVscGJIWWpkRFdCcGhj
V0ZobzNuczVxdXNpc1Jrbk5jeVRTK3VaMExrN09Dbng2RWpIZzB5WHc2UXBrY3p5ZDFYU1JX
WTJTbXVkSXl1QjhKWENmcnZ2eGVZNll1WTIwN2syUWM5YnVZWjRqS1NQekhMRXRuRlpWMFQz
UGtUWUpORDFqYzJLSXpHcWtjNTRqOE9ucENBT2ZMaDRHUGoycE1QRHA2Y1VzYzllSnpHcWtj
NTRqaHc4NFdnb1lUMDhDNk40U2pLY3JrRURUYzNKeWpOZ3I3LzFGWmpYU09jOFIrUFIwaElG
UEZ3OERuNTVVR1BqMDlKSkEwK2ZNbVhQMjdGa2pkbXdFNE5PdER2aDBjWUlvQ04wNy9SZTIy
ZDZuUC8vODh3OCsrT0RGaXhlTjJIZmFBWit1STBZd0RIeTZlRmhtc21JMTNUeFo2UWhMMWFj
ekp6ajRkSnpkMzBqVER2aDBxd00rWFJ6dzZaSWsxL1MwYmRER1B0MWFnRS9YRVNNWUJqNWRQ
QXg4ZWxKaDROUFRpMDAwWFRZbmhrVG1DcUQzQW5YcjRkNE05M1JPREVsOUhvd0o5eWJJT1Z2
M0RkNEdLZEdzTC9hL1Qzc0w4THJCYmordHFwS2RPVEVPSGp4WVVWRkJybjVadlhwMVkyTmpl
bmVmWHNDbjY0Z1JEQU9mTGg0R1BqMnBNS3Y0OU5IU1hWYjM2VmRkZFZWYld4dTkzSER1M0xs
R0pKRXVZRHpkNnNCNHVqZ3duaTVKbVIxUE4wQlZqSkRCQkpxZWw1Y1hqOGVKcHA4N2Q2Nmdv
TUNJSk5JRitIUWRNWUpoNE5QRnc4Q25KeFZtRlovT2E3b2xmZnJOTjkrOFk4Y09oTkRwMDZk
WHIxNjlmUGx5STVKSUYrRFRyUTc0ZEhIQXAwdFM1bnk2Zk9ERnVqNzk5T25UZDk1NVowRkJR
VUZCd2ZMbHkvL3hqMzhZa1VTNkFKK3VJMFl3REh5NmVCajQ5S1RDVXZIcG80MlF6QjUxK25T
a29PbVc5T2tabzdtNXVieTgzT1Z5elpzM3I3bTVHYWMySjRaRmZib3pTNzJ6UncwK1had2dD
c29VellHa3Z3WFV4dE9WTkQxMWpOQlNzMmg2WVdGaE9CeU94K09oVU1qdGR1UFU1c1N3cWs5
SHlJeFpTWkprWkZacW1nNCtYVHVHMVhUelpLVWpESHg2ZWxIVjlQZmVlNitxcWlvM043ZXFx
dXI5OTk4M1l0OHNQcDh2SEE0UERBeUVRcUdhbWhxYzJwd1lGdlhwVmtvMWZZQlAxd2Y0ZE1s
SW54NUV3ZkVsa2kxOCtxSkZpMTU0NFlWb05QckNDeS80ZkQ0ajlzMXkrUERod3NKQ2hGQmhZ
ZUhodzRkeGFuTmk5RjE3clNSUXZSNTNkWWxVcisvYnV6Y3RNZmp3NGQ3ZTNnVDErRTJZbGNG
dGhlckc1eHhnNThUbzNleExPQ2VHMDlxS3ZRK2lZRWZaSnRKbnpKTlZzbTBsU1ZML0gvK29l
NCswQmNUM21QZ2NMQ3VURU9xcWVXUjhDYk9jVlpVVTJ5SFRjMks0WEs2QmdRR01jVHdlbHdt
b0VjeWZQNStPdlZ4MTFWVTR0VGt4d0tkYkNQRHArZ0NmTG9GUFYwSlYwOWx5WFJrbzNWVlVW
RVRIWG1iTW1JRlRteE1EeHRQVG1aVWtTVVptRlFnRTZHTVlUeGVQZ2ZGMHljang5UGF5cDhl
WFNMWVlUK2NyTWhwYWw3R3BxY25qOGJoY3JybHo1NzcrK3VzNHRUa3h3S2RiaUhGREJENDlH
Y0NuU3diNGROS3FvMjFMc0kxUHR5TGcwdzNKU3BJa0k3TUtvaUFkZmdHZkxoNERQbDB5d0tk
VFFiZWhUN2NpNE5PdGlGOUYwOEduYXdNK1hRS2Zyb1E5TlozNmRPMjMzSFRPeFpFK1hVM1R3
YWRyeDRCUGw4Q25LMkZQVFovdzQ3V0ZqSXlGVWswZmZoU2tQNU9DVHhkSGJpY2RDZmgwSG50
cU92ajBkR1lsU1pMQlBwMmVQK0RUeFdOWTZURlBWanJDd0tlbkY1dG91bXllbzRnME9oZko2
Rnd3V1orTlJYeU9sYXpua1BGNzc0WTlRUlNrajJHZUk4SDdCbTlERUFVYnZBMm96cm50RUVU
QjlKNDF0RlZwbnh6ZFBqdkRrYVhuT2JJVzFLYzMrQm9pRW9wSTROTXQ0RDNSbXYxKzhPbkp4
SkNmSDZpalJIWElERm5wRGdPZm5sN3NxZWtUQnNVc05FaHRvVlRUaDVxbXczaTZHakpOZDJh
M0ljQjRPbzhOTlIzVm9RWmZnMGlQTjUxekFaOE9QbDBnaHNnTjI4UE5rSlh1TVBEcDZjV0dt
azUrR3JXa2k3RlFxdWtEZkhxeThKcWU3WXl5aHRFK0hkV2hpQVErUFh0UVRRZWZuczZzSkVr
eTJLZExFYmcrUFlrWThPa1V3MzA2TGVZMUp1VmtqK0tYRzJtSEdTR0RadEgwNGVIaGpSczNs
cGFXNXVUa2tLb3krdWM1c3BwUEh5OU1hUHBValdCY3g4R25pd0UrbldMNGVMcW1wcWVPRVZw
cUZrM2Z0R25UZ2dVTHVydTdSMFpHeUJMOTh4eFp6YWZMTk4wa1dja3cxS2NyYWpyNGRMVVlj
cTBMK0hRSmZMb1NadEYwajhjVENvWFlKZnJuT2JLYVR4L1AwUHlwR2dENDlHU2hzbUtaSG00
WW1mSHBxQTZCVDA4YWw4djEwRU1QVFowNjFlUHg3Tm16QjZjeXp4RkMrNjc5VFJBRk84bzJC
VkhRQXZNYzBReWRPYzhSbmRzSTVqa1NpNkY5bS9ad00yU2xyNjJrbE9jNWlranBuT2VJdHVy
b1BFZGxaYU1hZ2hBdUs0dElpTXlzMUZHMktmVjJ5UFE4UnhsbTVzeVpvVkNJekhNMGE5WXNu
TW84UitEVExRWDQ5R1JodTdjMWVyaGhUTGlRUEgwYmxJK25NeVpkZnZWNmFoaWhwV2JSOUZX
clZvVkNJVExQVVVsSkNVNWxuaU9yamFmTE5OMHNXVTBFeHRQRnd6SXduaDVFUVQrTXAzT2Fi
dFI0dW9xbXczaTZGcWRQbjc3aGhodnk4dkxLeTh2SndMcitlWTdBcDFzSzhPbkp3bXQ2dGpQ
S0d1RFRlY3lpNldrQmZIbzZzNW9JK0hUeE1DZjRkRlNIMk1uQmRXOUtNREcxVGZuQnAzUFlV
OVBCcDFzSThPbkpRalhkbjZVZVBuNGRTTGJ4ajFVeFM5Y0d3YWViQ3pXZnJ2YVdtOFhsSVNU
Ujg4UThXVTBFZkRvZmxxMSt4V3Q2aHQvQnpaczNpMmg2NW56NldDWjZ1dC9FTjVIMTZlU1VI
TDk0Y2FLbUM1YkQxTTdLQ0JtMHA2YkxmSG9hUDhZTkFURUZKWnlIZFgxNnR2cFYxbjM2dUhY
Tk5tbG9BYVNzNmZRWTFUUTlMWWR2aEF6YVJOTW56SW5oOVRiNEdtaHRlNG5Vc0ZlcVNYK2lv
ME54dWV5K3Q3YzNMVEdTSkIwNWNrUmhPYW12UDVhbldiTEtWRnVOejRNeGNVNk1JOC9mTGlX
YUV5UHRXU1djWCtMSWtTTTBSbTArQ3FQZlFkSzM3L0kyK01kNmVJYmZ3UVpmZzhpOEVDSlo5
ZlgxNGE0dTNWblJGaERmb3p3R0lXL2R1RDVRM1dndmU1cWRWNGZlQittTUdWNXZpdWNYeklt
UkdFV2Zib0VoZGZEcHB2SHBkR1pVcllUSDdIbDZSM0xGWVgyNkgzeDZ5ajQ5RUFqUW4zekJw
NXNMeGZGMGpkWTN5OGoxUkUwM1MxWVRjY2g0ZXNMZnZzZ2xIK1N4V3RmSzVIaTZYKzk0dXRx
bmtjaW1HbndOdktiekd6UjZQQjNWb2RUSDAwbExCZ0lCVWxOM3duVXZpVFE5UWZrbXplUUpS
c2lnUFRVZGZMcUZNSlZQRjdtZUlUaFdXWnZ0V2dZWmRzWE4ramxOMTdIM1ZCSlc5dW1aNzcw
SXBmNU5oZjRzNFo5WTdWSy9UMDhtR1NOazBKNmFEajVkRnFOOUFvTlBwekYrQVovT2E3cnNZ
dTAwWnVXcjgvRUxlVTFYREpNaHkwcnQwNU5IZ2RFQUFDQUFTVVJCVkV2UXA4dXU1eHR0RFFi
eHkwTDBYL2ZDYWJxTzd1ZG5XeklkUHAxdldQRHArZ0dmcnJvSEUxLzVZeXFmcnEzcGRNaFZr
cVNJTlBiRmYwelJqR2prMFVsMnVDVDlFelZkNU91RkRCMnJzQWtrMUhReVNLMTdGMEtrejZm
em11N25mTHFncWlUVnNFYklvTGswZmVQR2pXUkNESnphbkJqZzArVXhtcDBlZkxxVXlLY1Rl
U0xlTXpoMjhzdUVnT3B2R3JOcThEWHdDM2xOVnd5VEpaOUduMzRYNTlObFQ4bVNkM3NUZjN2
Z0Uwc2lLd044T24xY3kvbDBYdFBCcHllZ3E2dHI5dXpaVk5OVG1STURmTHFNVkV5WjBWakNw
eE5acEQralNSTTFuUldGdE9mRHUxMlpwZ2VaLzFMeXdXcC80ayt2VDFmVWRIMjdFSGYzUWVa
VFRmZU8xRFFkZkhxcTlQZjNlNzNlQXdjT1VFMVBaVTRNNnRPMUwzVXltMDhudmNHSXJMVGxC
bnk2eFBsMG1SVFNVUmRGbnk3VDlEUm1kWmV2SWFHbSsxRndQSXpyNmhGSnVWOWx3S2VUYnc4
MGY5cWsyajgvS0Y1T3F1YUlkZnQwK3JkdE5VMWYvdU1Yd2FlbnhOcTFhNTkvL25tTU1kVjAz
WE5pQkZGdy9kaU1BWDRVSkRYc1JXcnpaKzJleklsQnF1OGJzeGUvWVZ0Ty9WNXRUZ3hKY3ph
TTBmdDA1N08rYkJPcVEzYy9PVG9IQWwxKzk1TmxxRzUwSm9TT3NrM2tzUjhGMTVkdEltdlJ4
OHJIV0tlbkI2STZ0TDVzazRRUTJmdmRUNWJSZDNOOTJTYTBaai9kNzJnL2w2U09zUnpJSHNr
Vy9DaEl0aUNiVFVKSCs1QWM2UGtsV3lKclNkTHJ4ak12SzR0STZPNG55NElvMkhONHdudEhz
eVhuTDk4T2ZQNzBUS2ZIcnRqbXNyVklKdVQ5N1pqNDNwRnM2ZU83ZDQ3MmdTQUtrbnQySGhJ
TlZSRS9pMjArSndhWldwcUNVNWdUSTRpQ2Qva2EyRyttNE5QQnB3dkdrTEdPUUNEQS93Wkkz
aURpMDhtVjBlSStYZkduVHUzQ0kyUUpjY1RFMk5JQXNpOFVHYytCaHZuSGd1bGFKQ0FpSVZ4
V3h1NUNyVXNrYUN1RUpNYW4wNTlHMlorTHBiRXJ4OG0zQjlxU05KUFIvTWNPYXZuR012cXZI
elp6OXVhcjg3RXhOSksyQUEzajEyVnY1Qm9oOHY3Nko3NlBwRUZRQkpIYjhzWXk0dFA5RTMy
NkgzeDZzbENmcm50T2pBbnY5SnI5YXBwdW9rdEJKbXE2RVJneDFKc3V6RGFlVGdZclpMcER0
WW1vQUJVbW1TNm9TUW5WS1lsUlBWNXUxRFNML0FBYmtSQXIwNnltKzVuY0FvRkFJQkR3andr
dUc4UEtvbUtYa09YR1A1WjluckZ0NGgrYnQ1UGMweVV5VFdkSHEwbFRreHZSV1hZSmVjd3Vv
ZG9ha2NaM1FUOHF5STJHMGUzVGw5aE55VDVnZUUxSEVhU2g2WDUxcHdqajZYS29wdXVlRTRQ
MTZTZ3kzcVc0L211YTZ0dmcwODNrMDNuM2grb1FGWHBmblU4V3crb0NVYlRsRzh1SS9sS1pE
azdVVTdMQnpaczNrekR5RXBHaFFDQWdqZjFiM2MvMFpLcWVyS1pMWTdKT3dsZ1hLVXZTajRL
MVpVOEh4MzczWXgyOW9vMmxXWkViWFVLMklNdUt5aXRwSmVxQzcySXVQNU01WWxsaWZMYXlH
L3ZOTzhVd2pSZ3BrVStuUiswSG41NFpxS1lUYVVCcjltdHJlc0x6UERQUTM5ekFwNXZCcDh2
TXI4elpLY3FsWXJ6SXphL3lPS2l5QzNZNWtSNFJwVlBjam81czFZNDlxUDQwcUJLVHJwdWt0
d1VTYWpyMTZWSUV5VFRkUDZicGlsMElmSG82b1pydWU5ZEgzeGp6KzNTWnBodmswelhHbXND
blM0eFAxNzZKT0VGaVBOT3lLWTBZVnRQTms1V09NSkhFMURZbCsxUXp3cWVqaVpwTzl3ZytQ
Uk9NKzNUbXc5WVBQajJScG1jWFh0TlJuWmhKTjhDblM0RjArajVEYjZuNGROdmMwdHNDa3BK
UEp3LzhFelY5OUZVbHdLZW5FMFdmN25lOFR4LzlRVXo5TXl4YlBuMzBsemNWVGMrd1R5Y2xV
OUNhL2RxbnZYa2NNZmgwZndaOXVwLzhLa0MwUGpDNlVOeW5xemtxSTJUUW5wb09QcDJGWEFW
aDNKY0EzWXhxZWdUSngxNVFGbnc2K2F0TFFrMDN6NDN0NFk2OXBmZndVUjNTOXVueVY1VlFQ
TkZBMDVPR25lZW93ZHZnZTlmbmZkZUxJc2o3cnRkUFprSlJtbDNJSkRNS0JWR1EzTi9sYlpB
TW1DVW5PRFluanRvOFB0bWE1K2pkUHE4a1NkNTN2Yko1amhxOERWSm01em55MW5rYmZBM2VP
aTlhczUrMGxkcjlUMi9mcnZFcXVmLzEvOTZjTU9ZdWI4TmR2b1pVWXRnZWJwNnNrbTJydTd3
TnRXVlA2OTRqaXFCazk2Z1JFd2dFYUtzdWJ5enI4M3FES09oOTF5c2hKR3R6RkVGcTh4enhh
blBreUJGeWpzdVd3enhIaVVuS3B5ditEU1FyVUovdU44WktCMWtib2xMOWd5VmpJKzlCK20x
M29rLzNvNkRSUGwxMmpPT1hrSU5QdDlRdHZZZlBPL0hnMlBYUXBHUG85dWxxMzVLTmtFRjdh
am83bms3ZWRYcnEwcE01aUlKbUcwLzNHek9lUG40QzFDSHloeFR0VFNscXVuRlh6YXRwdXNo
NCt2S05aZnF5a2wwdFRxNjVsbEJpVFRmUHlEWGJ2YzJUbFk0dzg0eW5zNjFLeHRQSE5YM3Nw
MUZXMHdYSDAzMTFQdEIwblJCTmx6VTkxWFEwOXZkdTJ2UW11UlRFei93anc2RHRqMjRjamY2
dFRqcytZeVB2ZmpxQ3FkZW42MDQxeVB3SmlQNUhodG94Uzl6QXAvdlQ3ZFA5R2o0OWdxU0px
cUxtMC8xY255UWRUTmtxR1lBOU5WM1pwelAvVnlabk5TblNsQkNqZmJwL29xWWI1OVBwUDBl
ME44VjNTaU95R3Y4cll3byt2YmJzYVgxWitibS8waEQ3Qmo0ZGZMcWFUMGVjcHF1ZHpySWxw
RXlzWXIxSkkyVFFicG8rcWhTY1QyZi9ta3ora0IzVVczWlpHeDNlM3ovMjcyb3BvbWRpU1pI
dHkyNko4ekVlV3B4RTRib1hza1RBcCt0T1ZmV1V0b0pQSndjT1BwMDJRdG8zU0ZYYnJ6VHFr
cXhQOTZ0NEtjbmVtdDdVMUZSVlZaV1hsMWRkWGQzUjBZSDF6bk5FUEJmdjArVUYyQkF5eUtk
cmk3THFCenVqNldtYzM1MWNHS3NnQ3BxYjRnT2tpVDQ5MmIra3l1TEhDMWhUQnlTN1BuM05m
clJtdnc2Zkx0NVdmSnRZeUtmTFZNWWtXZWtPUzlHbnM1cWVkcC9PdHphOVJTUUZueTRyamtZ
RzkvaHk4eFFqdE5Rc21uN1BQZmQwZDNmMzkvZHYzNzZkMU5IVk44OFJHUkxsZmJxc0FKdGYv
Wk16S2ZqTEovUjQvd0NpZjFFTG92RUNmb3E3U0RZOWNuRzY3S2E5bGovaEx3MUpIcVBpMXNp
b0M5WDAwWjhyR1UzWDQ5UEZFdE9vSjJVSm40N0cvdllDUHQxUW55Nzc0NmppcjNUOHFZRWk0
NTJRMW1MelQ2eEZUREZDUzgyaTZaUVRKMDU0UEI2c2Q1NGowdnE4VDFlOHRZKzVQRUZ6ellm
UkpkUjcwaDlENUJYdkpvYXg2NUxlSTQybDJ0TTFvYzYxMmdkUFFwK082aEQ1d1YyaDQzTEdl
VHlaT2tTK0xyQkhJVTMwNlJxZmhWcUZKeWZ1am1pNlgxM1RoZjVIV2p2aG01WmdXeWxxdXJW
OHVxeDdteUVyM1dIWjllbXlLbUNzVDZkTCtEWW5DL25lUHVwUm1Hckp0SXdsYTlmbzZXYUVo
SnBMMDN0N2U1Y3NXYkozNzE2c2Q1Nmo5V1diVUFUZHZiT012ZmVQelYwaXV3K2lJSm4zcE9m
dytDd3FkRFlaOWpHaWM5OXdzNmpRT1doUUhXcDY5RkUvQ2pZOStpaU5aMStWM1krL3VyUE1q
NEo0WnhtS0lEcHZDNDFrSDdQNXlPWndrVzJmTE9rNVhCWWs4KzhFME4wN3k2UUF1dnVCYldq
TmZqcURqMkp1ZUdkWlJFS3lvNUNZT1dLQ1NqUFJLTjdUZU9WMmlLRFI5K3VCYldST0dUTFAw
ZWhzUnlMekhBVW01Q1pySzlwaXNzZUJRRUN4UC9oUjhPNEh0cW4xRnZQY3kzcDQxdlBKNG4z
cUxZQW42b05NTjJSS0luK1ZPZGZvN0ZFb2drZ2ZhM3IwMFNDWkVTa3lQdHRVSUJDZ3ZkSG04
eHhoakRzN096MGV6eXV2dkVLZTZwdm55Sy9rMDlXc2VtM1owL1RqbEg2SzhqZGZuWStVbkth
VEV0RGI2T1hlRXlkUEdmMk5tNm5mVCtNM2I5NGNHQ000Tm4wQmF3VDhZN1lGTVdXNzJhdnU2
QU9hMVlSdkF4T1hzSFhrWlY4cVpRZEk4aHd0a0QzMlI2M2cySmlWaE5EeWpXV3MrMURiTHo4
ZnplakZBMlBKU3dqMStueWpqY240OU9EWXBZVEorblIyWDhHeCt1QWtINXFuckswVXY3dFkx
NmRMQVpUaHJIcmY5YVZyVTRLSlpjdW44L2FjbFJUYXIyaWY5NCtOb05McnFmd282QnRyTHFv
em8rWDE3ZTNUNit2clMwcEs5dTNiUjVmb20rZEk3VzFRZTRPRDNFMDJINHJzaWpmRjViSzMw
RC94cVVad2NPeXZhM3p2MU40Um43UGlFa1VKUUl4a0syYkYxNlRtTjB2M3FORmMydTNtWnc5
OFRFbVRIVThuUDBXSXZFSCtpWS9WYnBZWW5oYnYzc1lsa1BWR1lKc2lsUzJvYWJyYWtBdjdV
YXA0eHZINW9MSFpTMlQ5ME9hYWppWnk4ZUpGbmZNY1JaQ2dUMGNSWkpJUlJrV2Zuc2FzRWtx
QXRuTWhOeVBhYWp3bEpVMFg5T2xwYnl2eFRkR0dJai9MMDZjWjl1a29na1NNc3l3cnRka2tS
TEx5dmV1VG1PTk41UUFGbXlzclBsMUQwTWxONDNTV05aZGl2N0s1cHFjRnF1a2FLaWFORmNn
MnlHdEl5UmZnUnN4ZjFFUk9GUjNiVDhyV3BUMkJ4SWxSVFNlL2w0NzVJTUZMWDlMeU50R0NI
dlNwMmpqTTZHY3crU2JCZkI3clRpYjFONVNtTFhFUE5EYVNlZ0t5MXB2UXdobnBSYkwrbytN
MjJwRWlhTUlHeFc2Q0Rhc1dESnFlR0cyZlRpLy9rc1kwRkRlbTJlVWxQRlZVYlJjVnNnakNq
V1VpNTROZ1ZpSjlrWGN1ZkFJWjh1bXM5elRTcHl1YUtYOGlUU2NqMSt6M0t2NXhldHZLcDJU
QStUZVVobWxvdWl3cnRZNHFtSlZjMDdsK3hXWTEzb0I2dndJcVpzVmYwQ25lL1dnbmw1MFg5
SEhhZlRxL0hEUTlNVTg4OFlUR0o2cjRKNjN1MitoMzhNQzRMZ2l0eGVRanBkV3FxM1pIOWNR
a0pvZDBKYU80QmZrM3FySDVZOGViUWwzSzJkRjIzVytUU0VQeENmdTVpOXY4U3I1VjM1dVZv
SWtTZWNuUi85L0szcjZBOHR1dEwxdUpPMTZKK1ZNcjM2VCtNU01zNzFycCtFNlR5b21zcU9u
SjN0UlNva2V0b0VMTWV3R2FuaGlxNmJ4UFY3d3RieXdqNnFEMnV4eFowcnZaTnhvV0dWY1Qy
WW9rUmxtaG1FamZoajNzL05lOGtNbXlJanZsTTZSN2xBbmNlRXdFb1RYN05kcUJYY1czWVk4
OGJTWjVjc08xWmVPN1VCRmN4YXhvUE4zNGFDTWtlbmMwZkRyZE9LNHRZMXRHZmdoam1aQTlz
am53TjhXMll0K0YwVERhVnV4N1BmRjlKMWxOYUlUSWhMVDV0cHJRSDVqRGtXV2xxQlFLeVNz
ZDQvSWZ2OGkvS2RwWnlScWNKcW02dTRtZGh3MVRTSHZzTU1lYks4TDBGcjdQS0xXUGJHdnlO
M3JpYmJSSjJYZFF2UitLK1BUZXpUN1pPeXZTdGNhYkZEUmRBem9uQmhxcldBLzNWci9YbUEw
RHJkbFBIcHNoVDdpSGUzMzNNQ2RHWXZUNGRJRXdrYTBKN2xFa0RMSWlOK3JUa2FJL1hiTWZy
ZGtQYldYMXJBUVRTK01lelpNVitQVEVhSXlud3cxdWNJT2JxVzZnNllrQm53NVpRVmJXeWtv
d01mRHA0dGhUMCtFR043akJ6ZVEzMFBURWdFK0hyQ0FyYTJVbG1CajRkSEdzcE9raWMyS0lO
REhjNEFZM3VHWDlSalc5NmNjLy92cnp6OU9sazFiU2RKRTVNVWhqZ1UrSHJDQXJTMlFsbUpp
OWZYckE0OW04WU1GZmZ2ZTd3ZjcrMUhYU1Nwb3VNaWVHU0JQRERXNXdnMXZXYjZ5bWsxdmQv
L3BmZjN2cnJSUjEwa3Fhcmpnbnh0R2pSeDk3N0xFTkR6Lzg2SjEzL24vWFg3L3V2dnNlZSt5
eG45MTExMk9QUFVZZWE5elgvdkNIQ1dNRXR5YTR4NS84NUNlUUZXUUZXYkgzajl4eVN5YjNh
SjZzaUdxdC8rbFB4elg5K3V2L3RuOS9panBwSlUwWG1ST0RQRGgrL0xqSUJ2dmZmVmNrVEdS
cmduc1VDWU9zeE1NZ0svRXdjMmFGeFJKTDR4NU5tQlVaZTNuMy8vNWZ4NDI5aU15SlFSNE1E
QXlJYlBDYjdkdEZ3a1MySnJoSGtURElTandNc2hJUE0yZFdXQ3l4Tk83UmhGazFQZkRBMXlk
UGlteEtCQ3RwdXNpY0dFbHRjT2pzMlRTbGxrNGdLM0VnSzNITW1SVTJhMkxtekVvRUsybDZR
cnJUUFZzckFBQ0F0YkNWcGdNQUFEZ2MwSFQ5TkRVMVZWVlY1ZVhsVlZkWGQzUjBZR1pXVlZO
bHhTOHhRMWFOalkwVkZSVm15NHF3Y2VQR0xMNkpHdjNLVkZrTkR3OXYzTGl4dExRMEp5ZkhW
SW14elZWY1hHeVNySnFibTh2THkxMHUxN3g1ODVxYm00M2JOV2k2ZnU2NTU1N3U3dTcrL3Y3
dDI3ZXoxK0ZrVjlQNXJOVHl6RzVXOTk1Nzc0a1RKMkt4MkovLy9PZHNuWGlLTGRQVjFUVjc5
dXdzdm9sOFZ0bnRVUVErcTAyYk5pMVlzS0M3dTN0a1pNUlVpVkVPSFRyMHExLzl5aVJaRlJZ
V2hzUGhlRHdlQ29YY2JyZHh1d1pOVHdNblRwendlRHowcVJuT1FNeGxwYmdrODhoeWlNZmpy
Ny8rdXMvbnkySkttTW1xdjcvZjYvVWVPSERBREc4aXpRb2hkTmxsbHhVVUZOeDY2NjBuVHB3
d1NWWWVqeWNVQ21VM0dSYStlOTk2NjYxZmZ2bGx0dkloMEt4OFBsODRIQjRZR0FpRlFqVTFO
Y2J0RVRROVZYcDdlNWNzV2JKMzcxNjZ4QXh5d0dmRkw4bDZWdVRiY1ZGUjBmdnZ2MitTck5h
dVhmdjg4ODlqRTd5Si9QdDE1c3laMnRyYVpjdVdtU1FybDh2MTBFTVBUWjA2MWVQeDdObXpK
NHRaWWFYbU9uanc0TDMzM3B2RmxQREVyQTRmUGx4WVdJZ1FLaXdzUEh6NHNIRTdCVTFQaWM3
T1RvL0g4OG9ycjdBTHN5NEhmRmFLZVdZOUs0d3hHWHU1OHNvclRaSVZHUnJPK3VDMTJ2c1Zp
OFh5OHZLeWtoTG1zcG81YzJZb0ZDS0RDYk5temNwV1ZueGloSnR2dnZtamp6N0tWa3FZeTJy
Ky9QbDA3T1dxcTY0eWJyK2c2ZnFwcjY4dktTblp0MitmYkhsMk5aM1BTaTNQN0dhMWR1M2Fz
MmZQeG1LeDExNTc3ZkxMTHpkSlZwUXN2b2xxV1gzOTlkZFBQUEdFMysvUFJsSUtXYTFhdFNv
VUNwSEJoSktTa3F4a3BaZ1l4dmlkZDk2NTRZWWJzcFVTVnNxcXFLaUlqcjNNbURIRHVGMkRw
dXNIVGVUaXhZdXlKZWJNNnVMRmkyYklxcUdob2JTMGRQTGt5ZC81em5mKzY3LytLL01wS1di
RnZwU1ZsQlN6SWcveTgvTnZ2dm5teno3N3pDUlpuVDU5K29ZYmJzakx5eXN2TDgvaXdMcmlt
M2pqalRlKzhjWWIyVXBKTWF1bXBpYVB4K055dWViT25mdjY2NjhidDJ2UWRBQUFBUHNBbWc0
QUFHQWZRTk1CQUFEc0EyZzZBQUNBZlFCTkJ3QUFzQStnNlFBQUFQWUJOQjBBQU1BK2dLWURU
aWVMbDZJRFFOb0JUYmN3QXdNRER6Lzg4S3haczZaUG4vN01NODlrT3gyemd4QjY3cm5uTU1h
Ly9lMXZRY2NUMHQzZGpSQ0NlV1pFTUZYWEFrMjNNT3ZYcjcvenpqdS8vUExMcjcvKytwRkhI
c2wyT21ZSElWUlpXVGt5TXJKZ3dZS3NuM2ptWi9QbXpaTW1UZHE4ZVhPMkU3RUFwdXBhb09r
V1pzNmNPYklweWRuK1JCOGpoTmF2WDE5UVVFQXJmR2E5MjJVRmhOQjExMTIzYWRPbTY2Ky9u
bTBjV2FPOThNSUxNMmJNS0NvcTJqNDJ5N0F6bSt2bW0yLys4WTkvZlBQTk41T25OVFUxWkc2
SDl2YjJ4WXNYWTR5N3Vyb3FLeXZ6OC9NM2JOakF0bWUyRXM0aWZOY2kvU28zTjVmT2lmSHpu
Ly84My83dDN6REc5OTU3NzVvMWEraUthVThHTk4zQ3VGeXVvYUVoZG9tYXBqLzMzSFBSYVBU
QkJ4L01hSDRtQXlHMGMrZk9TWk1tN2RxMVM3R2h5T050MjdiRllySFcxdFpzelI5aUJxTFI2
TFJwMDc3ODhzdHAwNlpGbzFHTThaWXRXMWF0V29VeFhybHk1ZGF0V3pIR1BwL3Z4UmRmakVh
ajI3ZHZkNmFVVTlTNjF0RFEwTUdEQjJmUG5vMHhIaHdjL043M3Z2ZUxYL3ppZTkvNzN1RGdv
SEhKZ0taYkdBMmZQamc0eUdyNnBVdVhNcDJjK2REUWNmWXhQZCtjckZNdExTMjAvbFJMU3d2
RytOeTVjMjYzKy9qeDQyNjMrNnV2dnNJWTUrYm14bUl4akhFc0ZuTnlXMkdsN3JSdDJ6YVB4
ek5wMGlTRVVFNU9Ebm1wcTZzTElkVFYxV1ZvTXFEcEZxYTJ0dmJPTysvczdlMDlmLzU4Ylcw
dHhuam16Sm43OXUzcjcrK3ZxNnR6K05kaEhrRk5WM3pzTk5hc1dVTitkWC9tbVdmb1FNR0tG
U3V1dnZycWxTdFhrcWRlci9jUGYvaERMQmI3NHgvLzZPUzJ3a3JkSmo4L3Y3VzFOUmFMaFVJ
aHNpUVdpMVZYVjk5NjY2M1YxZFg5L2YzR0pRT2FibUhpOGZndmYvbkxtVE5uMHV0ZTZ1dnIz
VzczakJrenRtN2RxcUhwemp3RCtSTlBWaEJWTVFZN3Nybkt5OHMvL3ZoampQSEhIMzljWGw1
T0ZyYTN0eU9FMnR2YnlkUE96czZLaW9yOC9QeDE2OVpObWpTSkxIUmdXMkdsYnZQVVUwKzUz
VzYzMi8zc3M4K1NKZmZmZi8vcTFhc3h4di82ci8vNndBTVA4Q3VtQzlCMEFBRDBNenc4L01Z
YmJ5eFlzQ0RiaVFDamdLWURBS0FUTWxoY1hsNmVyVmxOQUI3UWRBQUFBUHNBbWc0QUFHQWZy
S0hwenZ6aEJRQUFJRm1TMDNTa2dtSmtUazdPdDc3MXJWLzg0aGZrSXRaTWN2TGt5V1hMbGsy
ZVBIblpzbVdmZi81NWh2ZWVNZmoyNTVmRTQvR0hIbnFvcEtSRTdaM0NHRGMzTjNzOG5yeTh2
TzkrOTdzOVBUM1llUTJJRUNvdUxzWktUY0dqMWppQlFNQTI1b1B2U00zTnpRc1hMcHc4ZWZL
U0pVdmVlZWNkTE5aSitMV2FtNXZMeTh0ZExsZDVlZm51M2JzemN6aEd3NHNoZjk3eFRjSERO
Nm5JV2pLUzEvUUlkMVBSOUpHUmtWT25UcTFhdGVvLy8vTS9SVkpKSTNmZmZmZUdEUnY2Ky9z
M2JOaXdZc1dLRE84OXcyaGZxbGhiVzF0VFV4T0pSRVpHUnRTMlVGeGMzTkhSTVRBd0VBcUY3
cmpqRHV5d0JzUVlyMW16NXZISEg4ZEtUY0dqMkRoSGpod2hKM0RHY3M0QTdPR3NXTEVpRW9u
RTQvSGR1M2RmZnZubFdLeVQ4R3U1M2U2MnRyWjRQQjRPaDkxdWQwYU93M0Q0OTUwLzcvaW00
T0diVkdRdEdRWnFPbmx3NnRRcDh0Zlk5OTU3cjZxcUtqYzN0NnFxNnIzMzNpTXgzL25PZDFh
dVhEbHYzanp5UndieW1jWVdTYUFMMlMzekZUbGtGQmNYOS9YMVlZejcrdnBzL3c5dmJVMHZM
UzE5KysyM3RiZFFYRnk4Zi85K0ltUXpac3pBRG12QXI3Lyt1cWlvNlBUcDAxaXBLWGo0eG9u
SDQ0c1dMZnJUbi81a1kwMG54R0t4cHFZbWN1V2llQ2RoMTZxdXJtNXZieDhZR05pM2J4K3BH
Mk1ERUVKdXQ3dWdvT0NXVzI0NWNlSUVWai92MktiZ1VXdFM3YlZrR0s3cFEwTkR1Ym01R09Q
S3lzcVhYMzQ1Rm92VjE5ZFhWVldSR0ZyUGM5cTBhWFJkdGtpQ2JHdFlyQ0xIcEVtVGhvZUhy
N3Z1dXFHaElaZkxKZElRMWtWYjAxMHUxNFlOR3dvS0Nzckt5bDU3N1RYRkxUUTJObDV4eFJW
VHAwNWR0MjRkYVM1SE5lQ3p6ejVML2d5Q2xacUNoMitjUng5OTlJYy8vQ0cyM1E4L3NzT2hn
MVFmZnZnaEZ1NGtzclU2T3p1TGlvb1FRa1ZGUlViL1N6N0RuRDE3dHJhMmR0bXlaVmpsdkpN
MUJZOWlreVpjUzBibWZMckw1U0lENjlGb2xLZzhZdjY1aDlTTEpHQk8weE5XNUNndUxqNXo1
Z3gyaHMzVTF2U2lvcUpRS0RRd01ORFIwVUdHakRVNGNPREFuRGx6c0pNYWNIQndzS3lzakJj
WDJoUThmT09RSHN1UFFWc2QvbGlpMGVpdVhic1dMVnFFaytrazdGb1ZGUlhoY0RnZWo0ZENv
Y3JLU3FOU3p4TDkvZjE1ZVhsWS9ieGptNEpIclVtMTE1Smg3SGo2RjE5ODhhTWYvWWpVaTFE
MDZiSjd2a2dDM1ZyQ3h5eDMzWFhYNDQ4L0hvL0hIMy84Y1dLZ2JJeTJwdDkrKysyMGIybWNl
Q01qSTBlUEh2WDVmS1J1akhNYXNMR3g4ZHBycjJXWHlKcUNSNk54N0NUb2VPTGgzSC8vL1Nk
UG5vekg0MDFOVFdSVVNxU1Q4R3NWRmhhR3crR0JnWUcydGpiYmpLY1RMbHk0c0duVEpyL2Zq
NVhPTzc0cGVQZ21GVmxMaG9HYW5wT1RjL25sbC8vc1p6OGp0VG9QSGp4WVdWbnBjcmtxS3l2
cGVMcnNuaStTZ0NhQ3hUVDl4SWtUUzVjdUpWY3ZuRHg1VXFRaHJJaGk0OGlXOVBUMExGMjZO
RGMzMStQeE5EYzMweFg1N1pTVWxLeGR1elllajJQSE5DREdlT25TcGV5UUZOOFVtR3N1amNh
eGphYnpIU2tZRE02Yk55ODNOM2ZSb2tYaGNCaXJ0SU9zQmZpMUdoc2J5WGZ4dVhQbk5qVTFa
ZnpJRElHMDBwUXBVMjY2NmFiUFB2c01LNTEzZkZOZ2dhNmx1SlkyUmwzTENBQUFBR1FlYS96
blNBUDRnQUVBQUtCWVh0TUJBQUFBQ21nNkFBQ0FmY2ljcG91TWlzRElDUUFBUUNwazdqZlNO
R282U0w4SXI3enl5cFZYWHBtWGw3ZDQ4ZUlEQnc0b3h2RDFKUnhTNlVXR1NFOTJRcGtYR1h5
emlIUXFmV3RaQ1A0QStTSTJyRHlTNjlQNUpScGJwaHNYV1V0RzhwcStaci84QnBwdVN1Nisr
KzZQUC82NHY3Ly9sVmRlVWJzeW5hOHY0YlJLTHl6YS9jbzVaVjVrc0VjbjBxbFNXY3RDc0Fl
b1VjU0dsaExTV0tLNFRSa2FhOGt3U3RNLyt1aWp4WXNYdTF3dTlnTkhWcWZsNk5HajExeHpU
VjVlM3Z6NTgwbkpNUko4OXV6WkcyKzhjY2VPSFZpbFNvenNvNHpmenRLbFM4bXNpZncvU2h6
SXFWT244dkx5TGwyNnhML0UxNWR3VktVWEdkclM3Snd5THpJVWowNmpVNld5bG9WZ0QxQ3Rp
QTFiU2todGlXeWJzcm94SW12Sk1FclRmVDdmMXExYjZiODJzRktkbGlWTGxyejY2cXZ4ZUx5
dHJXMysvUGtrSmhLSjFOVFUwQUplL0w5UE1kZGQrTzNzMnJXTEZBVmJzbVRKM3IxN1JSckNy
dnpqSC8vdysvMlBQUEtJNHF0OGZRbEhWWHFSb1MzTnppbnpJb00vT3UxT2xjcGFGb0k5UUxV
aU5td3BJYlVsUEd6ZEdQRzFLRVpwZW01dUx2bjdLTHV1ckU1TGJtNHVkZHlrdWd0Q3FMcTZ1
cVNrcEx1N20wVHlWV0l3MTEzNDdRd09EbDU1NVpXdnZmWmFaV1dsUm8xWjIvUGhoeC9PbXpk
dnc0WU53OFBEaWdGOGZRbm5WSHJoU2VqVEhWTG1SWWJzMEJKMnFsVFdzaERzQVNvV3NlRkxD
YWtWRitLaGRXT1NXb3RnbEtaN3ZkNnRXN2NPREF5dzY4b2UrLzMrbHBhVy92NStkdm1aTTJm
MjdOa3piOTQ4OGoxWDBhZFBuanlaL1dMQ2J3ZGovTXd6enhRVUZLZ1Y0M1VDRFEwTmZyK2ZE
Rmlwd2RlWGNFNmxGeDV0WFhaT21SY1o3TkdKZEtwVTFySVE3QUVxRnJIaEIzNEZoNExadWpI
aWExR00wdlFQUHZpZ3VycWFHQm02THJzZGpQR3hZOGR1dXVtbS9QeDhhbk5vVEVORHc5S2xT
Mk94R0Y4bEJtUDg4TU1QazdYSVUzNDdHT04vL3ZPZnhjWEZtWjlpeVR5Z2lWeThlQkVMMUpk
d1RxVVhGbGxiMFlWc2pCUEt2TWpnbTBXa1V3bXVaVjM0QTFRc1lpTXJKYVM0UkxIcDJMb3hp
bXRwWTg5Nkw4UER3Ny8vL2U4ZmZ2amhiQ2NDQUFDUVVlejVQMUtFVUUxTkRSbTlBUUFBY0E3
MjFIUUFBQUJuQXBvT0FBQmdINkRlQ3dBQWdIMndaTDBYUUFSOXBUbll0MVd3dm9RTmdObzRH
ckFGYlpxYm14Y3VYRGg1OHVRbFM1YVEvMnp6OERFaWExa0kvcXhwYm03MmVEemttcWllbmg2
czFEZEUxSkp2S0IybGNwTFdkQ2tndjRHbW14TjlwVGtvNHZVbGJBRFV4bEZEVnRCbXhZb1Zr
VWdrSG8vdjNyMzc4c3N2VjF5Rmp4Rlp5M0t3WjAxeGNYRkhSOGZBd0VBb0ZMcmpqanV3ZXQv
UWxqaStvWFNVeWpGSzA0MnI5MElyQjdTM3Q3T2xGUUExZEpUbVNLcStoSjJBMmpnc2FnVnRZ
ckZZVTFQVGdnVUxOTmJsWTBUV3NoQXlUZCsvZnovUmRESVR0RnJmRUxHdGlnMGxYaXJIS0Uw
M3J0N0xsaTFiVnExYWhURmV1WExsMXExYkUrYnNjUFNWNWtpcXZvUnRnTm80TWhRTDJ0Qnh1
UTgvL0ZCdFJUNUdaQzFyd2JaSlkyUGpGVmRjTVhYcTFIWHIxbW4zallTYXJ0aFFTWlhLTVVy
VGphdjNjdTdjT2JmYmZmejRjYmZiL2RWWFg0a2NwR1BSVjVvajJmb1M5Z0JxNC9Db0ZiU0pS
cU83ZHUxYXRHaVJ4cnA4ak1oYUZrSlI5dzRjT0RCbnpoeXMzamRFZkxxc29aSXRsV09VcGh0
YTcyWEZpaFZYWDMwMXFid0lxS0d2TkFkMlpJRmlxSTJqRGUwaDk5OS8vOG1USitQeGVGTlRF
eGxrNE9GalJOYXlITEt6Wm1SazVPalJvejZmcjdhMkZxdjNEVzFONXh0S1I2a2NvelRkMEhv
djdlM3RDQ0ZTSVIxUUEwMUVzRFFIVHI2K2hBMFFhU3NuMThhaFRSRU1CdWZObTVlYm03dG8w
YUp3T0N4N1ZTMUdjUzNyd3A4MTVFRkpTY25hdFd2SmdEUGZOeFRQdFlSTnA5Z3p0YkZudlJj
QXQzYyt0UUFBRm1SSlJFRlVBQUJuQXY4akJRQUFzQStnNlFBQUFQWUJOQjBBQU1BK0dLWHBN
TWdPQUFDUWVZejZqUlEwM1NSQUpaT2tFUG5aWDYxeDJMb296a0g3cVBuMjFGSEF4UHp3QjhY
S0k2bWJKSExnZkwwWEhkZWhKSDh0WTBSK0EwMDNNMURKUkFmYXZWZXhjV1IxVVJ5QzRGR3pB
VG9LbUpnZmpZT2lkWk5FRGx5dE1JNkpOSjJ0M01KWGQ5bXlaWXZINHlFMVlaeDJNbVFlcUdR
aWpuWnY1QnRIclM2S3ZSRS9hc1VBOFFJbUZrSjJVSXAxa3hJZU9GL3Z4U3lhTHF2Y3dsZDNt
VFp0V2lBUWlFUWk3TjlOQVNPQVNpWkpvWDBLOFkyaldCZkY5b2dmTlIrUVZBRVRxOEFmRkY4
M0tlR0IwK0VhdHQ2TFdUUmRWcm1Gcis3eTVwdHYzbmJiYmZQbno1OCtmZnF2Zi8xcjhhU0Jw
SUJLSnNtUzBLZkxHa2V0TG9xOUVUOXEyYXZKRmpDeEJQeEI4WFdUQkErY0w0eGpGazJYVlc3
aHE3c1Fob2VIRHh3NFVGQlFJSjQwSUE1VU10R0I5aW1rMFRqT0VYU1dwSHk2amdJbTVrZnhv
R1IxazBRT1hLMHdqbGswblI0SnFkeWlXTjBGSVRScDBxUzVjK2UrK09LTDRra0Q0cUNKUUNV
VGJXVE5SUmV5TVJxTkE1b3Vhd0crUFJVN3BOVlJQQ2haM1NTUk16Rmh2UmVSWktEZUN3QUFn
SDJBLzVFQ0FBRFlCOUIwQUFBQSt3Q2FEZ0FBWUI4eXJla2FQNmNBQUFBQUtaTE4zMGhCMHcy
Q0xjSFIzTnhjWGw3dWNybkt5OHQzNzk2dEdNKy9sVkR2UlNPbXViblo0L0dRNjE1NmVucXdV
cGtPcThPM0EzK01JZ1ZNdEF1aFpPWllNb0JJNDRpY2lYd00zOWtTa3JTbSsxRlFkZ05OTnhX
eUVoeHV0N3V0clMwZWo0ZkRZYmZicmJnSy8wWkF2UmVOVjR1TGl6czZPZ1lHQmtLaDBCMTMz
SUhWeTNSWUhiWWQrR01VTENVa2k3SGxXUy9TT0NKbkloL0RkN2FFR0tqcENLSDE2OWNYRkJU
VTFOVFFKZnpZaTNaTkdNWHRBR3J3SlRpcXE2dmIyOXNIQmdiMjdkdTNlUEZpeGJVUVFtNjN1
NkNnNEpaYmJqbHg0Z1NHZWkrSk5IMy8vdjNrTkdQL0dNS1g2YkE2ZkRzb0hxTkk1UllhdzNj
MjI2RGRPQ0puSWgrajF0azBNRmJUbjN2dXVXZzArdUNERDdJTDJjY0phOEtvYlFkUWhDL0Iw
ZG5aV1ZSVWhCQXFLaXBpLzZiTWMvYnMyZHJhMm1YTGxtR285NktwNlkyTmpWZGNjY1hVcVZQ
WHJWdEhHNGY0RlZtWkRxdURsUDVBSkR0R2tjb3RmQXpiMmV4QndzWVJPUlA1R01YT3BvMnht
czUvZE1zMFBXRk5HTFh0QUlyd0pUZ3FLaXJDNFhBOEhnK0ZRcFdWbGRxcjkvZjM1K1hsWWFq
M0lqWStjT0RBZ1RsejV0Q25mSmtPcThPM2crd1lSUXFZcU1YUXptWWJ0QnRINUV6VWlKRjFO
ZzJNMVhUdGhVaXNKb3d0QitDTWhqWmFZV0ZoT0J3ZUdCaG9hMnRURzhValhMaHdZZE9tVFg2
L0gwTzlsMFJkYm1SazVPalJvejZmcjdhMkZxdVg2YkE2YkR2d3h5aFN3RVF0aHUxc05rQ2tj
VVRPUk1VWVdXZExTT1kwSFUyRURkQ29DY052QnhDQk5scGpZNlBINHlGRmRacWFtbVN2MHFj
SW9TbFRwdHgwMDAyZmZmWVpobm92RXkvTVVHeXVrcEtTdFd2WHh1TnhyRlNtdytydzdaQ3dG
SWxpQVJNK2h1OXNOa0NrY1VUT1JENkc3MndKZ1hvdkFBQUE5Z0grUndvQUFHQWZRTk1CQUFE
c0EyZzZBQUNBZmNpY3Bxc051MnNNeHljY3I0ZWhmQUFBQUpiTS9VYXFXMzlCMDhWUnJES1Jz
QlFKLzFiYXI0QkpVckFGYzNqNFlqaE9LSStqWGJtbHVMaFljUzIrSThYajhZY2Vlb2lVcjdE
WitTdXJzNlNqUEE3ZnBDSnJ5VWhhMDRNb0tMdUJwcHNIdnNxRVNDa1N2aG50V3NCRUJGbkJI
QjYrR0k0VHl1Tm9WSGRaczJiTjQ0OC9ycmdXMzVGcWEydHJhbW9pa2NqSXlFZ0cwczRZc202
anJ6d09oVFpwVW1zUmpOTDBMVnUyZUR3ZWw4dEZQNDBSUWkrODhNS01HVE9LaW9xMmI5OU9O
OGl1cmxidmhkMXlaMmRuWldWbGZuNStiVzB0ZVluZkZ5QXJ3YUZkaWdTcGxPQ3dYd0dUaFBB
RmMzajRZamlPS284ajYxcGZmLzExVVZIUjZkT25OVlpoTzFKcGFlbmJiNytkaVVRemlGcTMw
VmNlUjdGSlJZcnFFSXpTOUduVHBnVUNnVWdrTWpBd1FOZmR0bTFiTEJacmJXMWwrejI3dWxx
OUYzYkxDeGN1Ykdob2lNVmlMNzMwRW5tSjM1ZkRrWlhYb0YvbHRFdVJ5RXB3Q0s1bE0vaUNP
VHg4TVJ6bmxNZmhLN2M4Kyt5enExZXYxbGhGMXBGY0x0ZUdEUnNLQ2dyS3lzcllLWmd0aldL
M1VUeURSTXJqOEUwcXNoYkZLRTEvODgwM2I3dnR0dm56NTArZlB2M1h2LzQxV1hkd2NKQnVo
OTBtZmF4Vzc0WGRjbTV1Yml3V3d4aEhvMUh5RXI4dko2TllYa093Rkltc0JJZjlDcGdraEMr
WXc4TVh3M0ZJZVJ5K2F3ME9EcGFWbFduWGhzTVRPMUpSVVZFb0ZCb1lHT2pvNkZBYmhiY2Nh
dDFHUjNrY3ZrbEYxbUl4ZGp4OWVIajR3SUVEQlFVRldGM0gyY2VLOVY1bXo1N05mdEF0V3JT
SStQVDYrbnAyWFhaZmpvV3ZNaUZlaW9RdHdXSFhBaWJpYVBScXZoaU9FOHJqS0ZadWFXeHN2
UGJhYXpYVzRqdlM3YmZmVGpYZGZwOS90TnZvSzQrRHVTWVZYSXZGS0Uwbm4xZWtjTUdMTDc2
SWxYUWNUUVJqckZqdjVROS8rRU5CUVFGOWV1alFvWXFLaXZ6OC9QWHIxN1BiWWZmbFdHUk5l
dkhpUmNWU0pMSzNqQVN6SlRqc1Y4QWtXZFJzQjFZcWh1T0U4amg4MThJWUwxMjZWRForSW1z
cnZpUDE5UFFzWGJvME56Zlg0L0UwTnpkbjhoQXlBRDE4ZmVWeE1OZWtpbXRwQS9WZUFBQUE3
QVA4anhRQUFNQStnS1lEQUFEWUI5QjBBQUFBKzJCMlRZZkJlZ0FBQUhITS9oc3BhSHFLSkZW
bGdsK0MxRXQ1MkJLUkxxMVczVVc3U296OUVPbGFmRnZadU42TE5pS0MyZHpjWEY1ZTduSzV5
c3ZMZCsvZVRaY24xYldTMXZTSUpMK0JwcHNaOFhvUmlrMnRVY3JEeG1qM09zWHFMZ21yeE5n
UGthN0Z0NVZkNjcwa1JLUnZ1TjN1dHJhMmVEd2VEb2ZwZktUSmRpMmpORjJ4M2t0dGJXMStm
djZDQlFzNk96c3h4dSs5OTE1VlZWVnVibTVWVlJXNXFQNmpqejVhdkhneFdZdHRpTE5uejk1
NDQ0MDdkdXdRUENxQUoyRzlDUDU5RkNubFlVdTB6eCsrdW90SWxSZ2JvOUcxK0xheVpiMFhF
WkJLVlNXVzZ1cnE5dmIyZ1lHQmZmdjJMVjY4R092cVdrWnB1bUs5bC9yNitsZ3MxdERRNFBW
Nk1jYVZsWlV2di93eStVZG9WVlVWeHRqbjgyM2R1cFdkU2hVaEZJbEVhbXBxT2pvNkJBOEo0
QkdwRjhHL2p3bExlZGdWN2ZPSHIrNGlVaVhHcm1oM0xiNnRiRm52UlJ4WlZTVVpuWjJkUlVW
RkNLR2lvaUpTSGtCSDF6SksweFhydlpBNkxiRllqQlFWY2JsY3RISkxibTR1eGpnM056Y2Fq
Y3IyV0YxZFhWSlMwdDNkTFhoSWdBekJlaEd5OTFHd2xJY3RTZWpUWmRWZFJLckUySktFWFl0
dksxdldlMGtLV1ZVbGxvcUtpbkE0SEkvSFE2RlFaV1VsMXRXMWpCMVBsOVY3SWE2OG9hRmg0
Y0tGV01tbmU3M2VyVnUzc3VVVkVVSm56cHpaczJmUHZIbnp5SmM0SUNuRTYwWEkzc2VFcFR4
c2pQYkpvMUhkeFZHQ0x0SzErTGF5ZDcyWGhMQlZsWGdLQ3d2RDRmREF3RUJiV3hzZFR5ZGsz
NmVUVHhWWnZSY3lubDVSVVhIbzBDR004Y0dEQnlzcksxMHVWMlZsSmVrWkgzendRWFYxTmZs
b2toMUpRMFBEMHFWTGlhOEh4RUVUVWF3eUlZc2hDL2xTSGs1QXNTbGt6YVZSM2NWUm1pN1N0
Zmkyc25lOUZ3MUlLN0ZWbGJDU2tmSjRQRVEybTVxYVpLc0w3c2dDYzljQkFBQUFnbVIvam1r
QUFBQWdYWmo5ZjZRQUFBQ0FPS0RwQUFBQTlzR01tZzZqTkFBQUFQb3c4RGRTa0dZejBOemN2
SERod3NtVEp5OVpzdVNkZDk1UmpPSGZSOGNXNWRCWHcwU3RBb3lkVU90SUlxVkkyQmhiZGkx
V0RNbEY5L3c1SmRKSmVGRVZPWDlsSkszcEVuY0RUVGN6SzFhc2lFUWk4WGg4OSs3ZGwxOSt1
VVlrKzM0NXRpaUh2aG9taWhWZ2JJWmlSeElwUlNLTHNYZlhrdFZIWWx0R3BKUHdMU2wrL2xL
TTBuUkZGNDhRV3I5K2ZVRkJRVTFORFZhcTkwSlhGRWtkRUNjV2l6VTFOUzFZc0VBamhtMTJ4
eGJsb0NSVnc0UmZZbGZZamlSU2lvU1BzWEhYNHVzanNTMGowa21RU2swWWtmT1hrbEdmamhC
Njdybm5vdEhvZ3c4K2lKWCtSNnEySXBBSzlDdmhoeDkrcUIxR0h6dThLRWV5TlV6NEpiWkUx
cEZFU3BId01UYnVXbng5SkxabHhEdUpyQ2FNNFBsTHliU21zOGFIci9laXRpS1FJdEZvZE5l
dVhZc1dMZEtJWVp2ZHlVVTVkTlF3NFpmWUZiWWppWlFpNFdQczJyVVU2eVBKZkxwNEo1SFZo
QkU1ZnlrR2F2cmt5Wk5sSlNWbGtlRFRNOEQ5OTk5Lzh1VEplRHplMU5RMFk4WU1qVWkyMlIx
YmxFTmZEUk9OQ2pDMlFhTWppWnl3Tk1hdVhVdXhQaExiTXVLZGhLMEpJMzcrVWd6VTlJY2Zm
amcvUDE4Mm5zNEc4UFZlMEVSRURnRFFKaGdNenBzM0x6YzNkOUdpUmVGd21DeVV0UzNmN0E0
dnlrRVJyR0dpVVFIR05paDJKSUxHT2M0dnQydlhrdFZINHM4cHhVNmllQ2F5TldFMG1sME5z
ODlkQndBQUFJaGp4djhjQVFBQUFQb0FUUWNBQUxBUG9Pa0FBQUQyd2V5YURvUDFBQUFBNHBp
OTNndG9lb3FJRkRCSnBaU0h6UkQ1MmQrWjlWNTRSTnFLVlFtMVFpaTJoRDlNa2NvdHpjM05I
bytIWEJ2VDA5T0RkWlhIU1ZyVEF4eWc2V1pHcElDSjdsSWVka1g3cUoxWjcwVU53UjZpVVFq
RnhyQ0hLVks1cGJpNHVLT2pZMkJnSUJRSzNYSEhIVmhYZVJ5ak5KMTM4WWk3aUxXbXBxYWpv
d05qM043ZXZuanhZcXhVQVlaRW5qMTc5c1liYjl5eFk0ZmdVUUU4R2dWTUNNbVc4ckF4Mmtm
dDVIb3ZQQ0k5UkxzUWlvM2hEMU83Y2t0eGNmSCsvZnVKcHBOL0dPa29qNU01bjg1citwWXRX
MWF0V29VeFhybHk1ZGF0VzdIU1Awc1JRcEZJaEtvL29BL3RBaVpZVnlrUEc2TjkxSTZ0OTZL
SVNBL1JMb1JpWTNnTlJKcVZXeG9iRzYrNDRvcXBVNmV1VzdlT2RDUWQ1WEd5b09tRGc0UGs4
Ymx6NTl4dTkvSGp4OTF1OTFkZmZZV1ZLc0FnaEtxcnEwdEtTcnE3dTBXT0IrQkpXTUNFa0d3
cER4dVQwS2M3dHQ0TFQ4THVrYkFRaW8zaEQxT3djc3VCQXdmbXpKbURkWlhITVZEVFpmVmVa
czZjdVcvZnZ2NysvcnE2T3JyS2loVXJycjc2NnBVclY1S25pajc5ekpremUvYnNtVGR2SHZs
NkN5U0ZTQUdURkV0NTJBL3RvM1ptdlJjMUV2YVFoSVZRYkF4N21JS1ZXMFpHUm80ZVBlcnor
V3ByYTdHdThqZ0dhcnFzM2t0OWZiM2I3WjR4WThiV3JWdnB3dmIyZG9SUWUzczdlYXBZQVlh
ODFORFFzSFRwVXVMaUFYSFFSQlFMbUFpVzhuQUNzdWFpQzlrWVo5Wjc0UkZwS3l4UUNNV1c4
SWNwWG5tcHBLUms3ZHExOFhnYzZ5cVBBL1ZlQUFBQTdJUFovM01FQUFBQWlBT2FEZ0FBWUI5
QTB3RUFBT3hENWpRZGh0MEJBQUNNSm5PL2tZS21ad0QrSGRGWFpjS1pCVXl3MHYrZmVaeFo3
NFZ2RnZIVG43MDZ6cFlYVnZCbkdkOGwrTE5NWkRzaTlacGtKSy9wZGR3Tk5OMWtzRTJ0cjhx
RVl3dVlpUFJTSjlkNzRkc25ZWXNwRmc2eW1ScndaeG5mSmZpelRIQTdDZXMxeVRCSzAyV2Y1
K1QraFJkZW1ERmpSbEZSMGZidDJ4Vmp5SVAxNjljWEZCVFUxTlRnc1UvMTNOemM2dXBxS0E4
Z0NQK09KRnRsd3JFRlRCQkNicmU3b0tEZ2xsdHVrYzJRVG5GeXZaZGtOVjJ0Y0pETk5KM0Fu
bVdLblVSMmxvbHNoNUt3WGhNbG81cStiZHUyV0N6VzJ0cEtEbEpOMDU5NzdybG9OUHJnZ3cv
U1Y0ZUdoZzRlUERoNzl1eUVHUUk0SFZVbW5GekFCR044OXV6WjJ0cmFaY3VXS2I3cTVIb3Z5
V3E2V3VFZysybTY3Q3pqdXdSL2xvbHNoNUN3WGhPTDRacE9xN3NnaEFZSEI5bFgrUml5a1Aw
czJyWnRtOGZqSWVWSGNuSnlSQTRKNE4rUlpLdE1PTG1BQ2FHL3Z6OHZMMC94SlNmWGUwbFcw
OVVLQjlsUDAvSEVzMHlqUzlDelRHUTdXTGhlRThVb1RlZXJ1L0R2cUdJRkdOblc4dlB6VzF0
Ylk3RllLQlN5WlQ4d0FyYWg5RldaY0hJQkU0enhoUXNYTm0zYTVQZjdGVjkxY3IwWEhlUHBp
bUUyTzVmNXMweXhTOGpPTXBIdGlOUnJrbUdVcHZQVlhYaE5WNndBSTl2YVUwODk1WGE3M1c3
M3M4OCthN04rWUFSb0lsaHZsUWxuRmpEQlkwMHhaY3FVbTI2NjZiUFBQcU1MMlJobjFudmh1
eGEvQkt1TE5SdWc2Tnd0RFgrVzhWMkNQOHV3UU9VbFdYT1JlazNhUUwwWEFBQUErd0QvSXdV
QUFMQVBvT2tBQUFEMkFUUWRBQURBUG9DbUE0Q3BnZCtyZ0tRQVRRY0FCWFFyYWRvbFdHT0Rh
ZGtYUXVpNTU1N0RHUC8ydDc5TlpZTUlvYzJiTjZlZUdGL2hwTG01dWJ5ODNPVnlsWmVYNzk2
OVcyM3ZzdXMxNHZINFF3ODlSTW9TcU9YRFYyVVJ1ZlNEejFDazRJL0lXdnl1ZFZ5SEFwb09B
QW80U3RNckt5dEhSa1lXTEZpUW9xWlhWRlJjdUhBaHhjVDRDaWR1dDd1dHJTMGVqNGZEWWJm
YnJaMERmVnhiVzF0VFV4T0pSRVpHUmpUMkphdktJcEk1bjZGSXdSL3h0ZmdjUU5NQklGVVV6
eXMwc2ZUUWxpMWJQQjZQeStXaVRrckU1Y2xjR0xtdnJhM056ODlmc0dCQloyY254cml6czdP
eXNqSS9QNysydHBiZE1ydDNmbDlIang2OTVwcHI4dkx5NXMrZlQydHdKcFFEaE5CMTExMjNh
ZE9tNjYrL25nUy85OTU3VlZWVnVibTVWVlZWZEZwZ1diRW14ZTBFQW9IZi9PWTNkS2Y4ZG1w
cWFrank3ZTN0aXhjdjFrNk1WamlwcnE1dWIyOGZHQmpZdDIrZjlscnN3WmFXbHI3OTl0c2FB
VmlwS2d0U0t2aWoxb1kwdzZRSy9pUmNDelFkQU5LUDJsbkVsaDZhTm0xYUlCQ0lSQ0lEQXdN
SlYxUU1vSHBkWDE4Zmk4VWFHaHE4WGkvR2VPSENoUTBORGJGWTdLV1hYbUxqWllXUFpQdGFz
bVRKcTYrK0dvL0gyOXJhNXMrZkwzNmtPM2Z1bkRScDBxNWR1OGdHS3lzclgzNzU1VmdzVmw5
ZlgxVlZoWldLTlNsdTUrTEZpMWRlZWVYWFgzK3R0cDB0Vzdhc1dyVUtZN3h5NWNxdFc3ZHFa
TVZXT09uczdDd3FLa0lJRlJVVmRYVjFhUjhMZmV4eXVUWnMyRkJRVUZCV1ZzWk9jczJpVnFo
SHUrQVBuNkY0d1IrUnRVRFRBU0Q5OEdjUlgzcm96VGZmdk8yMjIrYlBuejk5K3ZSZi8vclhh
aXVxYlprdGhSU0x4VERHc1ZpTUZKbkp6YzBsUzZMUktJbFJMSHdrMjFkdWJpNTE3dUxGa2Zq
UEdKZkxSZmVlbTV1TGxZbzFxVzNubVdlZStkV3ZmcVcyblhQbnpybmQ3dVBIajd2ZDdxKysr
a290SlZtRms0cUtpbkE0SEkvSFE2RlFaV1dsNExFVUZSV0ZRcUdCZ1lHT2pvN2k0bUxGZUky
cUxCb0ZmL2dNQlF2K0NLNEZtZzRBNlljL2k5UktEdzBQRHg4NGNLQ2dvSUE4blR4NXNscVJY
b0ppS1NUaVp4c2FHaFl1WElneFhyUm9FZkhwOWZYMUpFWng3N0o5K2YzK2xwYVcvdjUrM1Vl
cTRkTTFXb1pkSG8xRzU4NmRxN1lkalBHS0ZTdXV2dnJxbFN0WHF1WERWemdwTEN3TWg4TURB
d050YlczaTQrbTMzMzQ3MVhRMW5WVXIxS05kOElmUFVLVGdqL2hhb09rQWtIN1FSTEJTNlNI
eTBxUkprK2JPbmZ2aWl5K1NGUjkrK09IOC9IeU5rMUN4RkJJWlQ2K29xRGgwNkJERytOQ2hR
eFVWRmZuNStldlhyMWZiTzcrdlk4ZU8zWFRUVFdRSlhhaGpMT2pnd1lPVmxaVXVsNnV5c3BL
T3B5dkdLMjVuOCtiTmF0dkJHTGUzdHlPRTJ0dmJOZkpodVhqeFltTmpJL21PTW5mdTNLYW1K
cEcxTU1ZOVBUMUxseTdOemMzMWVEek56YzJLeWF0VlpkRXUrTU5uS0ZMd1IyUXQvaWo0SlFr
QlRRZUFMSk9VQ3dNQWJVRFRBU0RMZ0tZRGFRUTBIUUFBd0Q2QXBnTUFBTmdIMEhRQUFBRDdB
Sm9PQUFCZ0gwRFRBV3ZRMHRMUzJ0bzZORFRVMnRyYTB0SWl1SXIycTJvQjBXZzBGQW9weG11
c0JRQm1BRFFkc0FZdExTM3Z2dnZ1WC8vNjE3Lzg1Uy9wVWxXMTdYejAwVWY4U3lEbGdDVUFU
UWVzUVV0THk3Rmp4OExoOExGang2aTh5aDYwdExSMGQzZUh3K0dqUjQrcUxaUnRrOS9SaFFz
WDJ0dmJGVFU5SEE3djM3Ky90N2MzclVjR0FPa0VOQjJ3QmkwdExlZk9uYVAzZENIN29LV2w1
YXV2dm9wR28yVE9kY1dGc20zeU8vcmdndzk2ZW5vVVh4b1pHZW50N2QyM2IxLzZEZ3NBMGd4
b09tQU5XbHBhUmtaRzNucnJyWkdSRVNxNDRYQTRHbzFTbGVjbG5sOG8yNmJpanRUR3pVZEdS
czZjT1FPYURwZ1owSFRBR3JBS1N4OGZQWG8wSEE1M2QzZnIwSFNaY1BPdjhnOWFXbHIyNzkv
LzVaZGZwdlBBQUNDdGdLWURBQURZQjlCMEFBQUErd0NhRGdBQVlCOUEwd0VBQU93RGFEb0FB
SUI5QUUwSEFBQ3dEK09hM3RuWnVSTUFBQUN3UGdnRUhRQUF3RGI4LzFETSs3NmVBZ3hWQUFB
QUFFbEZUa1N1UW1DQyIgLz48YnIgLz4mbmJzcDs8L3A+PHA+SW4gdGhlIG5leHQgcGljdHVy
ZSB5b3Ugc2VlIHRoZSBvdXRwdXQgb2YgeGVucG0gdmlzdWFsaXplZC4gU28gdGhpcyBtaWdo
dCBiZSBhbiBpbmRpY2F0b3IgdGhhdDwvcD48cD5yZWFseSBzb21ldGhpbmcgaGFwcGVucy4g
SXQmIzM5O3Mgb25seSB0aGUgY29yZSB0aGF0IEkgZGVkaWNhdGVkIHRvIHRoYXQgRG9tVS4g
SSBoYXZlIGEgdGhyZWUtY29yZTwvcD48cD5BTUQgQ1BVIGJ5IHRoZSB3YXk6PC9wPjxwPiZu
YnNwOzwvcD48cD48aW1nIGFsdD0iIiBzcmM9ImRhdGE6aW1hZ2UvcG5nO2Jhc2U2NCxpVkJP
UncwS0dnb0FBQUFOU1VoRVVnQUFBZkVBQUFFa0NBSUFBQUN3bzUrMkFBQWdBRWxFUVZSNG5P
MmRhM1JVVlpyM043a1pBcWFTUUJpQ1VDRmdTSUNBWW1nRVdtM2FHVHM5UFRSZUFycG93T25W
MHpockFJMEdkSTJqaTZZQnRVVUgydVlpTFNPR1lCUk1WUzRJZ2tZa2FiVVg0U1pta1lBaEYw
RXVxVXV1Kzh1c05SL3EvYkRmUG4wNGw2cGRweTduOXYrdFo1MXpzcyt1dmYvbnFWTlBudXlx
UEVXK0FRQUFZQWthR3h1SjNob0FBQUJFZ2NiR3hyMTc5LzcvbUU0QkFBQ1ltYjE3OXlLbUF3
Q0FSVUJNQndBQTY0Q1lEZ0FBMWdFeEhRQUF6RVMxRFBGWnhIUVFWd2doa2dPRGMvVG8wZkhq
eHh0VHJSRlVHVUdEUFJrYUdtTFJIREVkeEFPMWwzcFVZbm84NDBoeGNmSEJnd2ZqTmwxWUdD
R2VHa0dERFJrWUdEaDkrclRMNWJwKy9YcE5UWTM0RkdJNm9HZlBubDIwYUZGbVptWktTc285
OTl5emYvLysyTTJsTGFickdEaFNVMVA3K3ZwaU5IaE5UYzFQZnZLVDFOVFV6TXpNSjU1NG9x
dXJLNnlIR3lHZUdrR0QzV2hyYXp0MDZGQlRVMU43ZTN0TlRjM3AwNmZGWnhIVDdjNzU4K2Yv
NFIvK1lkdTJiVmV1WFBINy9TZE9uSGo0NFlkak41M3BZbnBNcDM3d3dRZmRibmRQVDA5WFY5
ZktsU3QvOHBPZmhQVndJOFJUSTJpd0cxOTg4Y1gxNjlmVnppS20yNTNISDMvOEQzLzRnK0lw
UXNpbVRadXlzN1BUMHRLV0wxL3U5L3VGZGtrM3hjZXlBNy9mdjJ6WnNyUzB0REZqeG16ZXZG
a2Uwd2NHQnNyTHkwZVBIajE4K1BEUzB0S2JOMi9LaHhLUVBKWVFzbTNidHR6YzNKU1VsS2xU
cDM3MjJXZTdkKytlUEhseWNuTHl6Smt6VDU0OHlUa0ZwZFRuOC8zcnYvN3I3YmZmZnZ2dHQv
LzYxNy8yK1h5S1V3djA5Zld0V2JObTFLaFJEb2ZqbFZkZWlkeGpIby9udHR0dWs3Y0hRWEc2
K2ZQbnYvZmVlMEtmdHJhMnNXUEhpa05BWGw3ZXFWT24yUEh1M2J2WndhbFRwL0x5OHFpNnI5
VGFoV3Y1eTEvK01tN2N1TmRmZnoyc1N3QlJCekhkN293Wk0rYnk1Y3VLcHdnaEpTVWxYVjFk
WFYxZEpTVWx6ejc3ck5BdTZhYjRXSFpRVmxiR0J1bnM3SHpvb1lma2NmbmxsMTkrOE1FSEwx
MjZkUFBteldYTGx2MzJ0NzhOTXBya1IwTElva1dMTGw2ODZQRjRmdmU3MzQwY09mTFJSeDhW
ZnZ6UmozN0VQOFV6enp3ajZQeW5mL3Fuc3JLeUlGZEhLVjIzYnQwLy91TS9YcnAwNmRxMWE2
dFhyNDdjWXdjT0hMai8vdnNWNTFKRGNicmEydHFDZ29MQndVSFc1OGtubjl5NGNhUDRVU3RY
cnR5MmJSdWw5TktsU3lOSGptVFJlZXZXclU4OTlSUlY5NVZhTzd1VzZ1cnEwYU5ISHpod0lD
ejlRQnY0M0FzSVJsSlNVbjkvditJcFFzaTMzMzdManMrZlAzL0hIWGNJN1pKdWlvOWxCK1BH
alJNRytlYWJiK1F4M2VsMG5qdDNqaDEzZG5hT0dUTW15R2lTSHdraFY2NWNZY2NlajBmeVkx
SlNFdjhVT1RrNTU4K2ZGM1NPR3pjdXlOVlJTdSs0NHc3NVMwYXp4NzcrK3V2YzNOeHdYNE5x
MHhVWEY3Lzc3cnRDbzhmakVUL3E0TUdEcGFXbGxOS05HemVPSGoxNng0NGRsTkxISG52c280
OCtvdXErVW1zbmhQejNmLzkzVGs1T1kyTmpXT0pCaE9CekwwQ1o0SG42d01BQU8rN3Y3eGRD
WkZneFBURXhVVHlJUEtZbkpTV0psemlHRFJzV1pEVEpqOEdWaERXRlJLZmF4WXI3eTM4WGF2
UFlKNTk4TW1IQ0JMV1lxTGI0RTJTNkF3Y081T2ZuRHd3TUxGbXk1STAzM3BBOHFxZW5aOEtF
Q1pUUzZkT251MXl1ZSsrOWwxSTZZY0lFRnZyVmZLWFdUZ2laT0hIaTJyVnJGY1dER0lIUHZR
QlZIbi84OFMxYnRpaWVFcWVCMzM3N3JaQzZKaVVsQ2FuZmxTdFgrUFAwOCtmUHk4UHgrUEhq
di92dXUrQWlJNHpwUEZQazVPU0kvNTdJeWNsUkhGTWdaSjdPNmJHS2lvcWNuSnltcHFiZzho
UlJtMjVvYUdqNjlPbGxaV1ZPcDdPM3QxZit3UHZ2djMvZnZuM0Z4Y1dVMHVMaTRnTUhEanp3
d0FQc2xKcXYxTm9KSVpjdVhabzBhZExtelpzMVhBTFFBRDczQW9KeC92ejVzV1BIL3VsUGY3
cDY5YXJmNzI5c2JCUSs5MElJK2VkLy91ZnU3dTd1N3U2Zi8vem53aEx6ckZtelhucnBKWS9I
ODkxMzN6M3l5Q01oMTlQWklHek5WeDZPZi9lNzM1V1VsTFMwdFBUMzk1ODhlWkl0QzBod09C
ekNILzQwL0pqT004V2FOV3VFdGVtSEhucm82YWVmVmh4VDRQbm5uMWRjVHcvTFk2KysrdXFF
Q1JQT25EbWpPRVZJMUthamxGWlVWQkJDZHU3Y3FmakFqUnMzamhzM2pxWHdXN1pzdWVPT096
WnQyc1JPcWZsS3JaMWRTM3Q3ZTM1Ky9vWU5HN1JkQ0FnTGZPNEZoT0RNbVRPLy9PVXZIUTVI
U2twS2NYR3g4UGwwOGNjcWxpMWJ4ajRLUWluOTZxdXY3cnJycnFTa0pLZlR1VzNidHVBeDNl
ZnovZXBYdnhvK2ZIaDJkcmJpNTE0R0J3YzNiTmpnZERxVGs1T25UWnRXVVZFaEgyMzkrdlVq
Um95UVA1WXpwdk5NNGZWNlY2eFlNWExreUpFalI2NVlzY0xyOVNxT0tkRFgxN2RxMWFyTXpN
eU1qSXpYWG50Tm04ZUlqSjZlSHNYcEZGR2JqbEs2Zi8vK3laTW5xNzFUOHZYWFh5Y2xKWFYz
ZDFOS3U3cTZrcEtTL3ZyWHZ3YjNsVnE3Y0MwZEhSMEZCUVV2di93eXYzNFFDeERUZ1NwcTRR
eW9ZUnlQL2VJWHY5aTdkNi9lS2tCTXdPZGVnRWFNRTZITWdoRThOamc0dUgzNzlzTENRdUhq
ak1CaVNJSTRZanJneFFnUnlsd1l3V09FRUtmVGlVOFdXcGlhbWhxaFhrVmZYeDgrOXdJQUFD
YW1zYkh4MUtsVC9mMzkvZjM5cDA2ZGtueG9DakVkQUFETWhNL25PM0hpaE52dGRydmRqWTJO
NHZmR0tXSTZBQUNZR3F5bkF3Q0FkVUJNQndBQUUyT2p6eksySERuU2N1U0kzaW9BQUNCK1dE
YW05L3Y5VytmTjJ6cHZYdi9maWxZREFJRGxzV3hNLyt6MTF6YzRuUnVjenM5UWxSOEFZRmNz
RXRPdlg3cTBPVCtmeGZUTitmblhMMTNTV3hFQUFNUUVyOWZiMk5nb2ZKWlJxRTNFc0VoTXIx
eXhnZ1YwWnBVclZ1aXRDQUFBWWtKRFE4TzVjK2Y2K3ZyNit2ck9uajNiME5BZ1BtdVJtTTU0
NFlVWDJFRjdlenRQL3o2K0dxYzhvM0hPeU5NTnF2aTdRUlYvTjJPcW9uekNvamlqTVZXRmhj
dmxFb3I1REE0T3Vsd3U4VmxyeHZRdnYveVNwLytOSFR0NHV2R014amtqVHplbzR1OEdWZnpk
akttSzhnbUw0b3pHVkJVV3RzalQrL3I2V2x0YmYvT2Izd1FDZ2M3T3p2LzkzLy90N094a3gw
RzI3ZWZPaGV6RE9Scm5qSmN1WFlJcXFJSXE4ZmIvdk41NHptZ2NWZDk5OTExcmE2dUdMTjdq
OFZoL1BaM3h3Z3N2QkFLQlFDRFEwZEVSNElBMk5mRjA0eG1OYzBhZWJsREYzdzJxK0xzWlUx
V0FUMWdVWnpTVXFsaUVRV3ZHZEFBQU1EN2FBcDB0UHZmQ1FKNnVvUTluTjZqaTd3WlZZWFZE
bmg0dTVsaFBGNzZQVVdpcHJLd3NMQ3hNVGs2ZU1XUEdvVU9IS0tYZmZmZmQzTGx6VTFKUzVz
NmRxL2dWNXNqVEFRQW1RbHUwTk5QblhzUXgvZEZISDIxdWJ2YjVmRHQyN0JnMWFoU2xkUEhp
eGVYbDVUNmZyN3k4Zk1tU0pmS0hJMC9YMEllekcxVHhkNE9xc0xvaFR3OFhjK1RwRE1Xdi9t
cHRiWFU2blpUU1VhTkdkWFoyVWtvN096dFpsSmVBUEIwQVlDSzB4VWt6ZmU1Rkh0TTdPanBt
elpwMThPQkJTbWxDUWdMN2kyTmdZQ0F4TVZIY2JlREtsUnR2dmJWdTVVcDY0a1FnRU9nOGVE
QVFDTERqSUZ2YTFCU3lEK2RvbkROMmRIUkFGVlJCbFhqcmUvdnRlTTVvSEZYLzUvZmZlT3V0
M3VibTZFWlJROGYweHNaR3A5TzVaODhlOW1OV1ZoYnlkQUNBWmRBV0o4MVVQMTBjMDdkdjM1
NmRuVjFYVnllMGxKYVdDdXZwcGFXbDhvZGpQVjFESDg1dVVNWGZEYXJDNm9iMTlIQ1JCSEVK
Um9ucDVGYmtMVDA5UFJjdlhwd3paMDV5Y3ZLOTk5NTdTYW55SXZKMEFJQ0owQll0elJIVG93
THlkQTE5T0x0QkZYODNxQXFyRy9MMGNMRmpUQWNBQU9NVGl6Qm96WmlPUEoyL0QyYzNxT0x2
QmxWaGRVT2VIbDBzRXRNbGRSbXh4UlpiYkEyKzFWYVg4ZkRodzgzTnpaMmRuUU1EQTRvZExC
TFRHY2pUTmZUaDdBWlYvTjJnS3F4dXlOUEQ0c2FOR3kwdExjZVBINitwcVRsKy9IaExTOHVO
R3pmRUhhd1owd0VBd1BoRUV1NzYrL3M3T3p1Ym01c1BIejRzYnJkbVRFZWV6dCtIc3h0VThY
ZURxckM2SVUrUExrYUo2Zks2alBJVzFHVUVBRmlKV01SU284UjBocnplaTdnRmRSbkRIUXFx
K0llQ0t2NmhrS2VITlpSTjgzUkc4SmlPdW93QUFDc1JsYkJwbW5vdjhoYlVaWVFxcUxLWXFn
RHFNa1pjbDlIRU1SMTFHUUVBVmtKYm5EUnJYVVo1QytveWhqc1VWUEVQQlZYOFEyRTlQYXlo
WXIyZWJ0Q1lIckl1STZVVWRSa0JBRllpS3NIVG9ERTlLaUJQMTlDSHN4dFU4WGVEcXJDNklV
K1BMdGFNNlFBQVlIeTBCVHF2MTJ1YTd5T05FT1RwR3Zwd2RvTXEvbTVRRlZZMzVPbmgwdERR
Y083Y3ViNit2cjYrdnJObnp6WTBOSWpQV2lTbW95NGp0dGhpYTY2dHRycU1sRktYeThVKzFV
MHBIUndjZExsYzRyTVdpZWtNNU9rYStuQjJneXIrYmxBVlZqZms2ZUZpaXp5ZGdmVjBBSUNK
MEJib1BCNFAxdE5WSEdySXpBV3ErTHRCRlg4M1k2b0tJRStQTmthSjZUeFZHRkdYRVFCZ0pi
UkZTN1ArSDZtOENpUHFNb1k3RkZUeER3VlYvRU1oVHc5cnFLam42U3lJQzZIY05ERmRYb1VS
ZFJrQkFGWkNXNXgwdTkwM2I5NTB1VnczYnR5NGNlTkdiVzJ0K0t4eFk3cThDaU5QWGNaSFRv
d25BYkxtNEZ3U0lPdzR5SFpSMC9pUWZUaEg0NXl4cUtNSXFxQUtxc1RialcvUGpPZU14bEds
dVM3anFWT25hbXBxMnRyYURoOCs3SGE3TDF5NElENXIzSmd1cjhMSVU1ZVJCQWdNQm9NWjN6
VG42Y0V4Ymt5WFYySGtxY3ZJbkZYVVVjVGowMFZONDNtNjhZekdPU05QTjZpQ0t2dW80aFFX
eFJtTm8wcHpURGZIZTZROFZSaDU2akx5dUJnR2c4RjBOMXZrNlJHQ1BCMnFvTXBjcWppRklV
L254NW94SFFhRHdReHVpT21oUVo0T1ZWQmxMbFdjd3BDbjgyT1JtQzdVWlNRQk1yMXpPcmJZ
WW91dHdiZWE2ekxhcTM0NmlmYXZZczdSTEo5UFFSVlV4VUlWcHpEazZXTHNWWmVSeDhVd0dB
eW11Mm1PNmZhcW44NmNoVHdkcXFES0ZLbzRoU0ZQRnhPRlBIMzM3dDJabVptWm1abnZ2UE9P
TmhFYWNMbGNreVpOU2tsSmVlQ0JCOWkvai9MVVplUnhNUXdHZytsdW1tTzZ4dnJwZnI5Zk9N
N0l5R2hxYW1wcWFzck16TlFtUWdQWjJka3VsOHZ2OTd0Y3JxVkxsMUsrdW96TVdjalRvUXFx
VEtHS1V4anlkSDVVWS9xRUNSTjI3ZG8xTURCQWRZcnBvMGFOY3JsY3ZiMjlMcGRyOU9qUmxL
OHVJNCtMWVRBWVRIZUxkMjJBaG9hRytmUG41K2ZuNzl1M2IrZk9uUmtaR1JrWkdidDM3OVlt
UWdOVlZWVVRKa3dZUG56NHFsV3JrcEtTS09veVFoVlVXVTRWUVYzRzhPc3lSbFEvM2UxMjMz
MzMzVE5uenBTOHRScFBYQzZYMCtta3FNc0lnOEVzWkpIazZWUkRUQmZlRi8zem4vKzhiOSsr
L1B6OHVYUG5IanQyVEpzSWJRd05EWjArZmJxd3NQRDN2Lzg5UlYxR3FJSXF5Nm5pRkliMWRE
RWFZM3BtWm1aalk2T3doajR3TUxCejU4NEpFeVpvRTZFQlZxQng3Tml4Ly9WZi84V1dYRkNY
RVFhRFdjYWk5UjRwYjB4WGZGOVUvR0VZQTRJOEhhcWd5bHlxT0lVaFR3OENiMHpmdFd0WC9O
OFhqUkRrNlRBWXpDeG04ZS9FaUFySTA2RUtxc3lsaWxNWTh2UWdXRE9tb3k2ajNiYWQwL1hY
Z0MyMmtXdzExMldVWU0yWXprQ2ViaDlWQVdKRVZjYjBsWkZWY1FwRG5zNlBOV002ektURzlw
dzlkVmNMZzBWaVdFOFBEZkowczZ0aWU1NmhBc2pUTGFHS1V4anlkSDVDeFBTR2hvYjgvUHho
dzRaUlNwOTQ0b21LaW9wWWlGQ2txcW9xTHk4dk1URng0c1NKVlZWVkZIVVpiV0JzejlsVGQ3
VXdXQ1NtVDU1KzU1MTMxdGJXRWtJb3BSY3ZYc3pOemRVbVFnUHA2ZWx1dDV2VlpYUTRIQlIx
R1cyZ2l1MTVoZ29nVDdlRUtrNWh5Tk1sOVBiMkhqdDJyS2FtcHJ1N1czSXFSRXhQVGs3Misv
MHNwbCs5ZWpVdExVMnppSEFwS2lweXU5MnNMdVBNbVRNcDZqTGF3TmllczZmdWFtR3dTRXh6
VEdjQi9keTVjei84OEVOZFhkMzE2OWZGWjBQRTlBVUxGdXpldlpzUTB0N2Uvc1FUVHl4YXRF
aWJDQTJjT0hFaVBUMmRFSktlbm43aXhBbUt1b3cyVUJVZ2hJN25VaFVnZHZlVk5WUVIxR1VN
dnk3ajBhTkhoWEI5K2ZMbFE0Y09pYytHaU9udDdlMExGeTVNUzB0TFMwdGJ0R2pSOTk5L0gr
NzBtcGs4ZWJLdzluTG5uWGRTMUdXMGdiRTlaMC9kMWNKZ2taam1QRjBTcXk5Y3VDRCswYmlm
ZThuSXlCRFdYbGpOR2RSbHRMd3F0dWNaS29EMWRFdW80aFNHOVhReEViMUh5bGJTMVg2TUta
V1ZsVTZuTXpFeE1UYzM5LzMzMzZlb3kyZ0RZM3ZPbnJxcmhjRWlzWGpYMm1XSWcvaUZDeGZp
K1I2cEJwQ25tMTBWMi9NTUZVQ2ViZ2xWbk1LUXA0dlJHTk9KakxTMHRMVnIxMm9URVIrUXA1
dmQySjZ6cCs1cVliQklUUDg4M2ZnZ1R6ZTdLcmJuR1NxQVBOMFNxamlGSVUvbng3anZrWVlG
NmpKYVk5czVmWHFBOFBiVVhTMjIyRWF5MVZ5WE1hTDNTQThlUEppYm16dHMyREJoQlVaNzNJ
MDl5TlBOcm9ydGVZWUtJRSszaENwT1ljalQ1UXdORFVrV1lSZ2hZbnBPVHM3Um8wY0pJVGR2
M2x5OWV2WExMNzhjaVloWWcvVjBzeHZiYy9iVVhTME1Gb2xGRXRNSEJnWk9uejd0Y3JtdVg3
OWVVMU1qUGhWNlBYMXdjREFoSWFHdnI4L2o4V1JrWkdnV0VRZVFwNXRkRmR2ekRCVkFubTRK
Vlp6Q2tLZUxhV3RyTzNUb1VGTlRVM3Q3ZTAxTnplblRwOFZudWQ0am5UeDVzc3ZsT25yMGFE
eGp1dmdqTjFsWldSUjFHVzFnYksvWUhySUZCak9YYVk3cFgzenhoYVRHaXhpdTkwZ1BIRGlR
bloyZG5wNitjK2RPYlNJaTRmang0ODgvL3p4RlhVWWJxR0o3ZWJlQVNreTNzNitzb1lwVEdQ
SjBma3p3dVplU2twTExseTlUMUdXMGdiRzlZanU1TmJJcmRvUEJUR1Q2eEhRZGF3TXdHaG9h
bGk1ZHlvNVJsOUh5cWdJcWRSa0Q1TzliY1U4Nys4b2FxZ2pxTW9aZmx6RTRScThOc0dEQmdx
Kysrb29kb3k2ajVZM3RGZHNsWjlWNndtQm1zWGpuNlVhb0RYRHMyTEg3N3J0UCtCRjFHUzJ2
aXUzbDNjUzl4QzEyOXBVMVZIRUt3M282UDRhdURYRC8vZmQvK09HSHdvK295Mmg1WTN1MWR2
Rlp0WjR3bUZuTXZ1K1I4b004M2V5cTJGN2VUZHhMM0dKblgxbERGYWN3NU9uOHFNYjBqejc2
cUtTa2hCMnZXclVxTFMxdDBxUkpmLzNyWDJNaElsb2dUemU3c2IxYXUzQldmQXlEbWRUaUhk
UG56WnQzOU9oUlNxbkw1Wm8yYmRxVksxYzJiZHIwMDUvK05CWWlvZ1h5ZExPclludWhXK0RX
ckZ3NEt4emIyVmZXVU1VcERIazZQNm94L2JiYmJ2UDcvWlRTMWF0WC8vNzN2NmVVWHIxNmRl
VElrYkVRRVRtb3kyaU5yYVF1bzNETTJ1VmJJMmpHRmx0dFc4MTFHWU9qR3ROSGpoeDU1Y29W
U21sSlNRbDdvOUxuODkxMjIyM1JuVDY2SUU4M3V5cTJGN29GbFBKMHNkblpWOVpReFNrTWVU
by9xakg5b1ljZTJyUnAwOFdMRnpNek03dTd1eW1sbjN6eXlZOS8vT05ZaUlnV1dFODN1N0c5
K0VkeHU5eDBGd3lEYWJaNHgvVFRwMC9uNStlbnBhVnQzcnladFpTVWxMaGNybGlJaUJiSTA4
MnVpdTJGYmdIazZWWlh4U2tNZVRvL3h2MHM0K0RnNElzdnZwaVRrOE8ra1lPaUxxTU5qTzNW
anVXbXUyQVlUTFBwR2ROMStjK2o5ZXZYVDVreXBibTVlV2hvaUxXZ0xxUGxWYkU5MjNVVUlV
KzN2aXBPWWNqVCtURnVUSGM2blpLbEh0Umx0THl4dmRxeDNIUVhESU5wTnR2RjlNVEV4Tldy
Vnc4ZlB0enBkQjQ0Y0lDaUxxTU5WQVZFZFJrN2lvcUVZOVl1MzlyWlY5WlFSVkNYTWM1MUdY
VmsxS2hSTHBmTDcvZTdYSzdSbzBkVDFHVzBnYkc5MnJIY2RCY01nMmsyMjcxSHVtVEpFcGZM
MWR2YjYzSzVzck96S2VveTJrQVYyN01kMXRQdG9JcFRHTmJUK1ZHTjZXKy8vZmJ5NWN2Rkxj
dVdMZHU5ZTNjc1JDalMzdDUrMzMzM0pTY241K1hsc1lWMTFHVzB2TEc5MnJIY2RCY01nMm0y
ZU1mMHZMeThscFlXY1V0TFM4dWtTWk5pSVNKYUlFODN1eXEyWnp2azZYWlF4U2tNZVRvL3Fq
RTlPVG01cjY5UDNOTGIyNXVTa2hJTEVkRUNlYnJaamUzVmp1V211MkFZVExQRk82WVhGQlEw
TkRTSVd6Nzk5Tk9wVTZmR1FrUzBRSjV1ZGxWc3p3NlFwOXRCRmFjdzVPbjhxTWIwZDk1NVor
TEVpWFYxZFY2djErdjExdGJXNXVibXZ2dnV1N0VRRVRtb3kyaU5yVkJ0TVVBVWpsR1hFVnNy
YmVOZGw1RlN1bi8vL3VMaTR0VFUxTlRVMU5teloxZFZWVVYzN3FpRFBOM3NxdGllM0pxbkJ4
bk16cjZ5aGlwT1ljalQrVEh1WnhrMWdQVjBzeHZiRTFFY0owRmp1dTZDWVRETmhwZ2VHdVRw
WmxmRjlnUjV1bTFVY1FwRG5zNlBjV002RWNGYVVKZlI4c2IyQkhrNnpBWm14NWd1YVVGZFJz
dXJZbnVDUE4wMnFqaUZJVS9ueDlBeC9mYmJiMDlMU3lzcEtXbHRiYVdveTJnRFkzdUNQSjNQ
VjdwcmdFVml0b3Zwaks2dXJyS3lzamx6NWxEVVpiU0Jxc0RmNmpMUzhYK3Z5NmhZa1RGZys3
cU1BV0pFVmVINmlxQXVZOXpxTXBKYmNUZ2NpeGN2L3Y3Nzc2TTdQUTllcnpjNU9abWlMcU1O
ak8wSjhuUStYK211QVJhSjZaeW5kM1YxclZ5NThwZS8vR1VzUkFUaDJyVnJMN3p3UW5GeE1V
VmRSaHVvWW51QzlYUStYeGxRbFladVdFK1BMbUdzdmR5NGNTTXRMUzBXSWhSaGZ4K2twcVl1
V0xEZy9QbnpGSFVaYldCc1Q1Q244L2xLZHcyd1NNeDJNVjBEeU5QTnJvcnRDZkowUGw4WlVK
V0dicEZreEFFUzlvekkwLzgvM2QzZEsxZXVYTGh3WVN4RVJBdms2V1kzdGlmSTAvbDhwYnNH
M2MzVVRvaDNUSmU4UjVxZW52N1lZNDkxZDNmSFFrUzBRSjV1ZGxWc1Q1Q25oK01yUTZuUzBB
MTVlblF4K21jWk9VRmRSbXRzVVpkUmc2OTBWNkxqMXRRZTBLRXVvK2xBbm01MlZXeFBrS2VI
NHl0RHFkTFFEWGw2ZEZHTjZaOS8vbmxoWVdGU1VsSmhZZUVYWDN3Umk3bWpEdGJUelc1c1Q3
Q2VIbzZ2N0d5bTlrQzhZL3EwYWRPMmJObmk4WGkyYk5sU1ZGUVVpN21qRHZKMHM2dGllNEk4
UFJ4ZkdVcVZobTdJMDZPTGFreFBURXpzN2UybGxQcjlmc2svNHNlVEYxOThFWFVaN1dOc1Q1
Q25oK01yTzV1cFBhREQ1MTRVaitOSlUxUFQyTEZqaGRsUmw5SHlxdGllSUUvbjloVnprWEZV
YWVpR1BEMjY4SDZXVVZMS1BBNzRmTDdwMDZjZk9YSkVtQlIxR1MxdmJFK1FwM1A3Q2s3UVhZ
TjI4WGI3TE9PcVZhdGVlKzAxS3ZvckFYVVpMYThxZ0xxTVlmb3FRSXlsS2x4ZmtjZ3FJTEk3
Skt3WjQ2Q0tjOFo0MTJYVW5XSERoa24rUGtCZFJzc2IyeFBrNmR5K2doTjAxNkJkZkp6ejlM
ZmZmbnY1OHVYaWxtWExsdTNldlRzV0lvSWo1T21veTJoNVZXeFBzSjdPN2FzQTF0T2pLbDV3
S2ZzTElLWitpSGRNejh2TGEybHBFYmUwdExSTW1qUXBGaUtDSThSMDFHVzB2TEU5UVo3TzdT
czRJVVplallOajR4M1RrNU9UKy9yNnhDMjl2YjBwS1NteEVCRXRrS2ViWFJYYkUrVHAzTDRL
SUUrUHFuamgwSUo1ZWtGQlFVTkRnN2psMDA4L25UcDFhaXhFUkF0NW5oNndkeFpqT21ON2dq
eWQyMWR3UW95OEdnZkh4anVtdi9QT094TW5UcXlycS9ONnZWNnZ0N2EyTmpjMzk5MTMzNDJG
aUdnaHhQU09vaUtlcDl5WW1ZdWRWYkU5UVo3Tzdhc0E4dlNvaWhjT0xaaW5VMHIzNzk5ZlhG
eWNtcHFhbXBvNmUvYnNxcXFxV0NpSUNwSzZqSUcvVld2cm5LNS85VFZzK2Jlb3l4aXVyMngr
aDBmRkEySlB4dlB1UWwzRzBJanpkT0hYSVlrc1FTQVd6ZklNcFVwNG1vU25MSUE4UFZRZjRk
QlFxalIwaXpCUEQ0VDVmVStLdDU4d2puQnN6VHpkZEFneFhldzZIcWZEOUxXQVVreVhIOHRO
ZCtYNk9nMU9pSW9IeEo0VW40bTVlTVQwa0NCUE42bXFBUEwwOFBzSWg0WlNwYUdid2ZQMEFK
RjJqcFlmYkJmVEt5b3E4dlB6azVPVFo4eVljZWpRSVJwT1hVYXg2M2ljRHRQUjJGNXlMSndu
eU5PRCtnMU9pTndEWWsrS3p3aG5KWjJqSnQ1dU1YM3AwcVd0cmExZXIzZmZ2bjFaV1ZrMG5M
cU15Tk5OcEVyOE5BbkhBVFBrNlFHVnV5dUtxb1JQY01sTk9BdzVGT3RqelB1S1U1alI4blFl
dDRjV2I3ZVl6dkQ3L2UrLy96NzdVZzcrdW94aTEvRTRIYWFqc2Iza1dEaFBESnlueDBGRGtQ
SDVuUkIxa2JwN1h1S0VxQXdTQ0NkUGo0b0g3QmpUV2ZXdWpJd005dVY1L0hVWk8rZk9EWWlx
MWhGVFZhcXptNm9BK1h0MXZZQ3A2aktLbGNmSVY1MXpJNjNMS1BTSmo2cHc3eXNTY1YxRzhX
dWNaMFpKSC9FZEpmYXFiK1pNd2MrUy9zSVdkUm0xd05aZVdKMFovcnFNOGwrMk1NTWEyMHVP
aGZQRURIbDY3TVFFR1ZiaUloNlIwYjN3U0FhTWlwaklaUkJackpEOEtKRXFQeHZSMUhiTDAx
ZXRXdFhkM2UzMWV2ZnYzejltekJnYVRsMUdyS2ViU0pYNGFSS09BNFpmVHhmYWlDeTR4SG85
WFQ0cHo3STd6d2V1K1ZXSnI1Y28vVlpqejJBUTVVS2o0SzZBK3E5MjRXYVFkeE1QSlg1MlF2
YVJkSkRNcUxpZUx1bU05ZlR3MkxWclYwNU9Ua3BLeWozMzNQUEpKNS9RY09veVNyekg0M2VZ
WHNiMmttUGhQQWthMDNXWExWY2JveWtVMjBPNklrYnVrZzhvSDErdFJjMUNkcEJmU0ZTZHJh
QkJtRVh4RXFMZ1JydkZkQTBvNXVsQnZHK2ZqRGo0TFlnOFhkSkhhRmJzRmxEL3JST3VyeFNu
RUh0RDRnU0pQTUhVOG5UeFQyeVpXTzI2Skg0SXlNS3grRmd0VDVlSVpLcUN5SllMVXpQSkt6
cVNia0g2aUVVaVR6Y0V5TlBWek1oT1lIdkpNZWVqWTZkSFBFWGcxcWdhVXBKY0lYK2Y0Qk54
ZWthaW1jZDdJYWNJTWxySUMrUlhycThSbGVkRjdxVkFOTzQ5eFBUUUlFOVg2eFA4RmpSeW5o
N2NvcTRxNUdBOHFuZ1NUODZob3BpZkdsTVZwekRrNmZ4WUpLYkw2ektpZXArazhwenVHb0pY
eFpNY0I5UnJNY2IwbWVXY0YxdExib2xTWFVhaFhmRXM2akxHRnVUcGFuMkNPRUZIVllLMkFQ
TDBDUHFZV2hXbk1OM3o5SURTeWd6eTlKaUQ5WFExTTdJVDJGNXl6UG5vR0ltQjJkT0krbnE2
MnRsSURERTlOTWpUMWZvRXZ3V1JweFBrNlRxcDRoU0dQSjBmNDhiMHlzckt3c0xDeU9zeUJn
eWNva3FmNDVoSk5iSVQyRjV5elBub0dJbUIyZE5JMER4ZDNqbENzMTFNZi9UUlI1dWJtMzAr
MzQ0ZE8xZ2xBTTY2akFIWnIySTFueG90VDJkU2thY1Q1T25oOURHMUtrNWhSc2pUNVoyUnAy
dWt0YlhWNlhSUzdycU1pdDQzaGNWT3FwR2R3UGFTWTg1SHgwZ01EQlpBbmg0ak9qbzZaczJh
ZGZEZ1FjcGRsekZBYnFuTEdLUTZvOUVxSUFhaVhUK1A5UWxabjlMSWRSa0RzbHFNNG0yTWZC
Vmt5Nk9LV2ZBK2luZXB0ajZtVmhVZ3hEZHpaanhuNUZjbGZsWEsrMFQrcXJkalhjYkd4a2Fu
MDdsbnp4NzJJMmRkUnNWZmlwSC9VbzJEeFVpbndUMGdsaWNjY3o0NlJtSmdzQUR5OUtpemZm
djI3T3pzdXJvNm9ZV3pMbU5BYWNsTTBhYzJXVThQZVF0aVBaMWdQVjBuVlp6QzRyT2VMbEhG
amdKWVQ0OFc1Rlo2ZW5vNDZ6SXFPcGJIOVhwWmdFZ1BvajYra1QwZ2xpY2NjejQ2Um1KZ3NB
RHlkQ05nMGp4ZGZOUEVRbFhJV3hCNU92bGJDZktRZzVrM0l6YW1LazVoeU5QNXNXWk1WM3dD
REd1QlcyTjZMTVkzc2hQRTJvUmp6a2RIVndiL3ZEQTdHTnNGa0tmckNQSjB4VDRoNzBKNzV1
bVNTUzJmRVJ0VEZhY3c1T244V0NTbWkrc3lxbFZjTTBJTlFyVmFnRUpGd0JpTmIrVDZsTHJV
WmVRY0gxczdiOFd2eWlqZWU4SVdkUmxEZ3p4ZHNVOXdKM0FPWmJFOFhkN0w4aG14TVZWeEN0
TXJUdy9TZ1NCUGp5cTRXS2dBQUJWRVNVUkJWQVBCMTlQRng0YXlBTmJUNDc2ZXJ2ZEZ3MHhn
SkZSTWo5QVEwME1UUEUrWFBCa0JYYjkxL3BhbkZuazY4dlFJK3BoYUZhY3c1T244R0RlbUM1
OU1GMW80NnpMeVBHSEVTQ1ZRQXNqVHRlYnBtaTlLNzR1R21jQ0lwanc5eUNscFQ3dkZkSVk0
cG11dXk2aG15TlA1aDRwZHRVaXhObkZIenR4VG15cDVMOHRueE1aVXhTbk1SSGw2UVBaQ1E1
NStDK0tZcnJrdVk1Qm54UWdXaUZlZWJxaXJWcnh3RGNORXhTY3dtQVpUYkZWclYraUptQjVK
WFVhMVNuVkdxTXNvVkNJTXhMSXVvM2hya0xxTUFWSEZPNkVsM0ZxRDJsVFpzQUtpTVZVRkRG
eVhNV1FmeGJ0ZC92cnFLRUpkUmhIaW1CNUpYVVkxQzZzM1ovK0FiSFU0K0RpQitPYnBNWm9s
UW1GcVVrTmFFTWZ5T3dRRzAyRHlKbmw3a1A3STA3bnFNakozaGJ1UXAvamNDTnVpRHRWdlRS
SU8rYXY2aWJzcFBrUll1UlpyRUxld0E1NjF2T0JmNlNMcHB1WUJ3VmRxZDYyNG5mbEswazE4
SVlJVFNLaVl6cjlHTEg4NkpLNFRxMUo3bWl5L2NtMU1WWnpDZEZsUEQ5bEhIQm5ZTHVTTTRo
TzJpK25rVmlpbFBIVVplWjZ0V0pqYTB4bTcwWWdzVnZMY1hzYThYa2lGMmRIc0Z0TTFvRGxQ
RDI3SXA2QUtxbUtraWxPWU1mUDBTRlVocG9kRXh6d2RCb1BCd2pQRTlKQWdUNGNxcURLWEtr
NWh5TlA1c1VoTUYrb3lCdlN1NVlZdHR0aGl5N05GWGNiUUlFK0hLcWd5bHlwT1ljalQrYkZt
VElmQllEQ2pHMko2U0pDblF4VlVtVXNWcHpEazZmeVlLYWJ6MUdYa2NURU1Cb1BwYjMrTDZa
VlBQbm50NHNWb3hVa3p4WFNldW96TVdjalRvUXFxVEtHS1U1aTE4L1FOVHVmbUtWTStlLzMx
ZnA4djhqaHBwcGpPVTVlUng4VXdHQXltdjRsaU9yTnRQLzd4dDRjUFJ4Z256UlRURmVzeW5q
MTdkdTNhdGVWcjFqeXpjT0ZQNTg5L2R0bXl0V3ZYL3ZiaGg5ZXVYY3VPZzJ6TEhuc3NaQi9P
MFRobi9QV3ZmdzFWVUFWVjR1M1RQL3RaUEdjMGppb1d0Wjc3elcvK0h0UG56Ly8yNDQ4ampK
Tm1pdWs4ZFJuWndZVUxGM2dHOUgzNktVODNudEU0WitUcEJsWDgzYUNLdjVzeFZWRStZVkdj
MFlDcTJOckxwMy80ZyszV1huanFNcktEM3Q1ZW5nRnY3TmpCMDQxbk5NNFplYnBCRlg4M3FP
THZaa3hWbEU5WUZHYzBvS3JLRlN1dXRiWHhETVdEbVdJNlQxM0dzQVljNk82T2tyUm9BbFg4
UUJVL3hsUkZqU3JNbUtwNE1GTk1EMGx6dEw4eEJBQUF6SVdsWWpvQUFOZ2N4SFR0VkZaV0Zo
WVdKaWNuejVneDQ5Q2hRMVQwUFI2R1VpVnZNWUtxaW9xSy9QeDhvNmxpdlBqaWl6bytpVUh1
SzBPcEdod2NmUEhGRjNOeWNvWU5HMllvWVdKM1pXVmxHVVJWVlZWVlhsNWVZbUxpeElrVHE2
cXFZamMxWXJwMkhuMzAwZWJtWnAvUHQyUEhEdkhuY1BTTjZYSlZhanIxVmJWMDZkTFcxbGF2
MTd0djN6NjlYbmlLbm1scWFobzdkcXlPVDZKY2xiNTNGRU91YXYzNjlWT21UR2x1Ymg0YUdq
S1VNSUhqeDQ4Ly8venpCbEdWbnA3dWRydjlmci9MNVhJNEhMR2JHakU5Q3JTMnRqcWRUdUZI
STd3Q3FVeVZZa3Y4a1dqdysvM3Z2LzkrVVZHUmpwS29TSlhQNTVzK2ZmcVJJMGVNOENRS3Fn
Z2h0OTkrZTFwYVdrbEpTV3RycTBGVU9aMU9sOHVscnhneDh0dTdwS1RrOHVYTGV1bGhDS3FL
aW9yY2JuZHZiNi9MNVpvNWMyYnNaa1JNajVTT2pvNVpzMllkUEhoUWFERkNPSkNya3Jmb3Jv
cjlkWnlSa2ZIRkYxOFlSTldxVmF0ZWUrMDFhb0FuVWY1OGRYVjFsWldWelprenh5Q3FFaE1U
VjY5ZVBYejRjS2ZUZWVEQUFSMVZVU1YzTlRRMExGMjZWRWRKOUZaVkowNmNTRTlQSjRTa3A2
ZWZPSEVpZHBNaXBrZEVZMk9qMCtuY3MyZVB1RkgzY0NCWHBhaFRkMVdVVXJiMk1tblNKSU9v
WWt2RHVpOWVxejFmWHE4M09UbFpGMGxVcG1yVXFGRXVsNHN0Sm93ZVBWb3ZWWEpoakFVTEZu
ejExVmQ2U2FJeVZaTW5UeGJXWHU2ODg4N1l6WXVZcnAzdDI3ZG5aMmZYMWRWSjJ2V042WEpW
YWpyMVZiVnExYXJ1N202djE3dC8vLzR4WThZWVJKV0FqaytpbXFwcjE2Njk4TUlMeGNYRmVv
aFNVTFZreVJLWHk4VVdFN0t6czNWUnBTaU1VbnJzMkxINzdydFBMMGxVU1ZWR1JvYXc5cEta
bVJtN3FSSFR0VU51cGFlblI5SmlURlU5UFQxR1VMVnIxNjZjbkp5VWxKUjc3cm5uazA4K2li
OGtSVlhpVTdwSVVsVEZEbEpUVXhjc1dIRCsvSG1EcUdwdmI3L3Z2dnVTazVQejh2SjBYRmhY
ZkJMdnYvLytEei84VUM5Smlxb3FLeXVkVG1kaVltSnVidTc3Nzc4ZnU2a1Iwd0VBd0RvZ3Bn
TUFnSFZBVEFjQUFPdUFtQTRBQU5ZQk1SMEFBS3dEWWpvQUFGZ0h4SFFBQUxBT2lPbkFPdWo0
b1hJQURBSmlldnpvN2UxZHMyYk42TkdqUjQ0Y3VYSGpScjNsbUJoQ3lLdXZ2a29wZmVXVlZ4
REhJNkc1dVprUWdpK1RpUkJEM1pDSTZmSGp1ZWVlVzdodzRlWExsNjlkdS9iMDAwL3JMY2ZF
RUVJS0NncUdob2FtVEptaSswdkkxR3pldkRraElXSHo1czE2Q3pFM2hyb2hFZFBqeDdoeDR5
VGZJQzUrK29WalFzaHp6ejJYbHBZbUZPVFUvUzR4R29TUWVmUG1yVisvZnY3OCtXSy9TZnk1
WmN1V3pNek1qSXlNSFgvN3ZtQjRVc0tDQlF1ZWZQTEpCUXNXc0I5bnpwekp2c0NodnI3K3Jy
dnVvcFEyTlRVVkZCU2twcWFXbDVlTFhhMlhZR01pdnlIWjNaaVVsQ1I4SjhiS2xTdC85YXRm
VVVxWExsMzYxRk5QQ1ErTXVoakU5UGlSbUpnNE1EQWdibEdMNmErKytxckg0L20zZi91M3VP
b3pENFNRdlh2M0ppUWt2UGZlZTRvK1pNZGJ0MjcxZXIwMU5UVjZmUk9Jd2ZGNFBDTkdqTGg4
K2ZLSUVTTThIZytsOUkwMzNsaXlaQW1sZFBIaXhXKysrU2FsdEtpbzZJOS8vS1BINDlteFl3
ZEN1UnBxTitUQXdFQkRROFBZc1dNcHBmMzkvUTgrK09DLy8vdS9QL2pnZy8zOS9iRVRnNWdl
UDRMazZmMzkvZUtZM3RmWEYyOXhwaUpJSEJjZkM2OGNCQ05GcXF1cmhTSlQxZFhWbE5LclY2
ODZISTRMRnk0NEhJNGZmdmlCVXBxVWxPVDFlaW1sWHE4WGJsUkRmaE51M2JyVjZYUW1KQ1FR
UW9ZTkc4Wk9OVFUxRVVLYW1wcGlLZ1l4UFg2VWxaVXRYTGl3bzZQait2WHJaV1ZsbE5KUm8w
YlYxZFg1Zkw1dDI3YmhEMXQrT0dPNjRqRVFlT3FwcDloNzlSczNiaFJXQTBwTFMrKysrKzdG
aXhlekg2ZFBuLzZuUC8zSjYvVysvZmJiY0tNYThwc3ROVFcxcHFiRzYvVzZYQzdXNHZWNlo4
eVlVVkpTTW1QR0RKL1BGenN4aU9ueHcrLzMvOGQvL01lb1VhT0V6NzFzMzc3ZDRYQmtabWEr
K2VhYlFXSTZYa3NTNUM4aFNXbFR4VDRVbnJ5VnZMeThreWRQVWtwUG5qeVpsNWZIR3V2cjZ3
a2g5ZlgxN01mR3hzYjgvUHpVMU5Sbm4zMDJJU0dCTmNLTkV1UTMyMHN2dmVSd09Cd094NlpO
bTFqTDh1WExuM2ppQ1VycDQ0OC92bUxGQ3ZrRG93VmlPZ0FnQklPRGd4OSsrT0dVS1ZQMEZn
SkNnNWdPQUFnR1d4SE95OHZUNjZ0TFFGZ2dwZ01BZ0hWQVRBY0FBT3VBbUE0QUFOWWh2SmhP
VkpEM2xOYzJhV3RybXpOblRrcEt5cHc1Y3k1ZXZCajlTekVoVlZWVmVYbDVpWW1KZVhsNUgz
endnV0lmdjkrL2V2WHE3T3hzd2RYeUZzRGpFL0VkbTVXVkpXNkpyMWlqc0dmUG5rbVRKaVVu
Sjk5MTExMUhqaHloZkM5U3VhdXJxcXFjVG1keWN2S1BmdlNqbHBhV3VGNkRNWkI3Z01jbk1Y
cHBoeDNUQXpKVG5GdGUyK1NSUng0cEx5LzMrWHpsNWVXbHBhWGE1Rm9NaDhOUlcxdnI5L3Zk
YnJmRDRWRHNVMVpXTm5QbXpETm56Z3dORGFtMWdMQjg4dFJUVDYxYnQwNzQwYll4L1pGSEhq
bDU4cVRQNTl1elp3LzdWMXVlRjZuYzFWbFpXWWNPSGVydDdYVzVYUC95TC84U0wva0dRdTRC
SHAvRTZLVWRxNWd1LzUvSnJLeXN6czVPU21sblp5ZitWNXN4WThhTSt2cjYzdDdldXJvNlZs
NURUazVPenRHalI0TzNBSDZmWEx0MkxTTWpvNzI5WFdpeGJVd1h1SFRwVW5KeWNsOWZIOCtM
Vk83cXJLeXNqei8rbU1XdnpNek1PQWcyR25JUDhQZ2tSaS90V01WMGVXMlRoSVNFd2NIQmVm
UG1EUXdNSkNZbVJxamJHalEyTm1aa1pCQkNNakl5MVA1ak9ERXhzYnk4UEMwdGJmejQ4ZnYz
NzFkc0FmdysyYlJwRS92WER3R2J4L1R2di8rK3VMaVkvVEhOOHlLVnU3cWlvdUtPTys0WVBu
ejRzODgrYTgrWHR0d0RQRDZKMFVzN3JubDZWMWNYUlo0dUlqOC8zKzEyKy8xK2w4dFZVRkNn
MkNjakk4UGxjdlgyOWg0NmRJaXRBc3RiQUtkUCt2djd4NDhmTC9uMWFlZVkvdVdYWDA2Y09M
Rzh2SHh3Y0pEeXZVaUR1UHJJa1NQanhvMkx2V3JqSXZkQUVKL0U2S1VkcTVndXIyM3k4TU1Q
cjF1M3p1LzNyMXUzN3JISEh0TW0xMktrcDZlNzNlN2UzdDdhMmxxMTlmUmYvT0lYd3RQTVht
YnlGc0RwazRxS2lybHo1MG9hYlJ2VGQrM2FWVnhjL1Bubm53c3RQQzlTUlZjUERRMmRQWHUy
cUtpSXZkaHRpTndESVgwU281ZDJyR0s2dkxaSmEydnI3Tm16MlJ2QmJXMXQydVJhaklxS0Ns
YThMVGMzdDdLeWtqVksvTm5TMGpKNzl1eWtwQ1NuMDFsVlZhWFlBaFI5SXI4elo4K2VMZjZU
TnVUSHQ2eU41UEo3ZW5vVVg2UWhiMGoyOE96czdGV3JWdm45ZmgydVJHL2tIbEQwU1h4ZTJy
SDZMQ01BQUlENGcvODVBZ0FBNjRDWURnQUExZ0V4SFFBQXJBTmlPZ0FBV0lmNDFYdkJHNnJ5
RWhBOFBxbXFxcG82ZFdwS1NzcXNXYk9PSFRzbXRHL1lzTUVtenVUeGdGb2ZNZkppR3VKNzJJ
YWY5SmRmUGsrVkVybXI4ZEpXclBjUzhvYVUxOXVKU3VXYzhHTzYwb2NaNVQzbDlWNkVFYlFK
dFFCcUpTQ0MrNlMwdFBUTW1UTit2LytERHo0WU0yWU1hL3o2NjY5WmJJcXRZbVBBNHdIRlBo
S0NGTk9RVklDeEc4TGw4MVFwVVhPMVRlNUdSZVIrNDdraDVmVjJvbEk1SjFZeFhmNS9wTUlJ
Mm9SYUFMVVNFRHcrOFhxOWxaV1Y3TXZEL0g3L3RHblQvdWQvL3NkV3p1VHhnTGlQSExWaUd1
SUtNSVNRZSs2NVovSGl4Uk1uVGhTK1o5bmFpQytmdjNLTDNOVzJ1aHNscVBrdCtBMHBJSzYz
RTNubG5GakZkSG05RjJFRWJVSXRnRm9KaUpBK0VmNDYvdkxMTHltbHp6enpEUHNmUC9zNGs4
Y0RrajV5MUlwcGlDdkFFRUthbTV2WmRzU0lFVEc4Sk1NZ3Zuek95aTJLcnJiUDNTaEgwVzho
YjBpR3VONU9WQ3JuSUUvWEFVa0pDQjZmZUR5ZTk5NTdiOXEwYVpUU2hJU0U0RzltV0JJZUQ0
ajd5RkVzcGlHcEFDT3NzMU43M0t1S0JYQW9SK1VXdWF2dDRLNlFTUHdXL0lha3NubzdhdU9F
UmF4aXVyemVpekNDTnFIV1FMRUVSSENmTEYrK3ZLMnR6ZS8zVjFaV1N2NGNzNGt6ZVR3UXBJ
K0FZakVOU1FVWXU4VjBlUUdja0ZWSzFGeHRCM2NGUWVJM25odFNYbTlIUG80R1loWFQ1ZlZl
eUsxb2sydHEySVhMaTBKSWZDSnh6cC8vL09lSkV5Y21KU1ZObXpiTjdYWkxCb3liZUIzaDhZ
QmlINGwvRkl0cHlDdkFVRHZGZE1VQ09NR3JsTWhkalplMjNHODhONlRFYnowOVBZcitEeGZV
ZXdFQUFPdUEvemtDQUFEcmdKZ09BQURXQVRFZEFBQ3NBMkk2QUlZRzcxZUJzRUJNQjBBQnpa
RTA2aUU0eUlCUm1Zc1E4dXFycjFKS1gzbmxsVWdHSklSczNydzVjbUdLVlZEeTh2SVNFeFB6
OHZJKytPQUR0ZGtsbjllUWwvZVIwOWJXTm1mT25KU1VsRGx6NWx5OGVKSGUrakVRZm9YeUZw
NUhCWms5eUhXRkJERWRBQVZzRmRNTENncUdob2FtVEprU1lVelB6OCsvZWZObWhNTGtWVkFj
RGtkdGJhM2Y3M2U3M1dwZjJ5dG9FSTZEbFBjUnoxVmVYdTd6K2NyTHkwdExTem1WeXhYS1d6
Z2ZKWmxkZmhWcUxVRkFUQWRBQWNYWEZTRWtLU2xweG93Wmh3NGRvcFMrOGNZYlRxY3pNVEZS
eUtSNHNqeEpGc2EyWldWbHFhbXBVNlpNYVd4c3BKUTJOallXRkJTa3BxYVdsWldKUnhiUExw
L3I3Tm16OTk1N2IzSnk4dVRKazRWYWdDSERBU0ZrM3J4NTY5ZXZuejkvUHV2OCtlZWZGeFlX
SmlVbEZSWVdzditJSVlSczJiSWxNek16SXlOang0NGRhdU5zMkxEaDVaZGZGaWFWanpOejVr
d212cjYrL3E2Nzdnb3VUS2lDTW1QR2pQcjYrdDdlM3JxNnV1Q1BFbCtzWW5rZmlUZXlzckk2
T3pzcHBaMmRuU3pPRWtJY0RrZGFXdHJQZnZhejF0Wld4VWZKRlFacENmSW8rZXhxMHlHbUF4
QXBhcStpZ1lHQmhvYUdzV1BIVWtwSGpCaXhZY09HTTJmTzlQYjJobnlnWWdjaFhtL2Z2dDNy
OWU3YXRXdjY5T21VMHFsVHArN2F0Y3ZyOWI3MTFsdmkvdUxaNVhQTm1qWHIzWGZmOWZ2OXRi
VzFreWRQNXIvU3ZYdjNKaVFrdlBmZWUyekFnb0tDblR0M2VyM2U3ZHUzRnhZV3NqNWJ0Mjcx
ZXIwMU5UVnFlU2docEtlblo5S2tTZGV1WFZNYjU0MDMzbGl5WkFtbGRQSGl4VysrK1dZUVZl
SXFLSTJOalJrWkdZU1FqSXdNZVJrRGlRYmhXSzI4ajVpRWhJVEJ3Y0Y1OCtZTkRBeUk2NnQw
ZDNlWGxaWE5tVE9IVTZGYVMvQkhxYzJPbUE1QTlKRy9pclp1M2VwME9sbXBtV0hEaGxGS1Av
cm9vNS8vL09lVEowOGVPWExrZi83bmY2bzlVRzNrL3Y1K0lhWjd2VjVLcWRmclRVNU9wcFFt
SlNXeEZvL0h3L3JJWjVmUGxaU1VKR1R1UXArd3JwUWRKeVltQ3JNbkpTV3g5djcrL3VBWHlO
bzNidHo0L1BQUHE0MXo5ZXBWaDhOeDRjSUZoOFB4d3c4L3FFbVNWRUhKejg5M3U5MSt2OS9s
Y2hVVUZIQmVpMko1SHdsWldWbGRYVjFVbGlsVFNuMCtIM3N1ZUJRcXRvUjhsTnJzaU9rQVJC
LzVxeWcxTmJXbXBzYnI5YnBjTHZIWndjSEJJMGVPcEtXbHNSOVRVbEtFdjlrVkdUVnFWRjFk
bmMvbjI3WnRteERUV1Q2N2E5ZXVxVk9uVWtxblRadkc4dlR0MjdlelBvcXpTK1lxTGk2dXJx
NzIrWHlhcnpSSW5oN0VNK0oyajhlVG01dXJOZzZsdExTMDlPNjc3dzVTeDFoZUJTVTlQZDN0
ZHZmMjl0Ylcxdkt2cHl1Vzk1SHc4TU1QcjF1M3p1LzNyMXUzamxYNlpOeThlWFA5K3ZYRnhj
V2NDaFVydDRSOGxOcnNpT2tBUkI5eUs1VFNsMTU2eWVGd09CeU9UWnMyaWRlNEV4SVNjbk56
Ly9qSFA3SUhybG16SmpVMU5jaUxjUHYyN1E2SEl6TXo4ODAzMzVTc3ArZm41eDgvZnB4U2V2
ejQ4Zno4L05UVTFPZWVlMDV0ZHZsYzU4NmRlK0NCQjFpTDBLaGhMYWlob2FHZ29DQXhNYkdn
b0VCWVQxZnNyempPNXMyYjFjYWhsTmJYMXhOQzZ1dnJnK2dSMDlQVFUxRlJ3ZjVHeWMzTnJh
eXM1SGtVVlNudkl4SGYydG82ZS9aczlyMUNiVzF0d2ppMzNYYmJBdzg4Y1A3OGVjVkh5UlhL
VzNpdVMyMTI4VlhJVzBLQ21BNkF6bkMrVmdIZ0FURWRBSjFCVEFkUkJERWRBQUNzQTJJNkFB
QllCOFIwQUFDd0RvanBBQUJnSFJEVGdUbW9ycTZ1cWFrWkdCaW9xYW1wcnE3bWZFandzMm9k
UEI2UHkrVlM3Qi9rVVFBWUFjUjBZQTZxcTZzLy9mVFRiNzc1NXJQUFBvdFdWRlViNTZ1dnZw
S2ZRaWdIcGdBeEhaaUQ2dXJxYytmT3VkM3VjK2ZPQ2VGVmNsQmRYZDNjM094MnU4K2VQYXZX
S0JsVFB0SE5temZyNitzVlk3cmI3Zjc0NDQ4N09qcWllbVVBUkJQRWRHQU9xcXVycjE2OUtt
eUZSdkZCZFhYMUR6Lzg0UEY0MkRlMUt6Wkt4cFJQOUplLy9LV2xwVVh4MU5EUVVFZEhSMTFk
WGZRdUM0QW9nNWdPekVGMWRmWFEwTkRodzRlSGhvYUVnT3QydXowZWp4RGw1U0ZlM2lnWlUz
RWl0WFh6b2FHaHJxNHV4SFJnWkJEVGdUa1FSMWpoK096WnMyNjN1N201V1VOTWx3UnUrVm41
UVhWMTljY2ZmM3o1OHVWb1hoZ0FVUVV4SFFBQXJBTmlPZ0FBV0FmRWRBQUFzQTZJNlFBQVlC
MFEwd0VBd0RvZ3BnTUFnSFg0ZTB4dmJHemNDd0FBd1B3UUJIUUFBTEFNL3c4ekFuMmUwNzdS
bGdBQUFBQkpSVTVFcmtKZ2dnPT0iIC8+PC9wPjxwPiZuYnNwOzwvcD48cD5JbiBDUFUgdXNh
Z2Ugb2YgdGhlIERvbTAsIHRoZXJlIGlzIG5vdGhpbmcgdG8gc2VlOjwvcD48cD4mbmJzcDs8
L3A+PHA+PGltZyBhbHQ9IiIgc3JjPSJkYXRhOmltYWdlL3BuZztiYXNlNjQsaVZCT1J3MEtH
Z29BQUFBTlNVaEVVZ0FBQWZFQUFBRnNDQUlBQUFCVHFCZTNBQUFnQUVsRVFWUjRuTzJkZjNR
VGRici94eWFwSlNocEc4b0Mxa0JoUzB0cGk3WGNVcmk3WHI2ZTd4VkZkLzJSVnRjVlBmZXND
L2RjUUN1UjVld2VQVzR2b0xzS2dxWFFxeGVGV2l5aVRkcFNZTld0YUZHNWgyckx4VXAvUVZO
RWZqWEpoS2I5L1BNOVovL2crOGVzczhQOHlxZHAwc3hNM3Evem5EbnBKNStaZWMrVHlidFBK
NU9uelA4Q0FBQXdCRzF0YlV5OE5RQUFBSWdDYlcxdGUvZnUvYnVuRXdBQUFIcG03OTY5OEhR
QUFEQUk4SFFBQURBTzhIUUFBREFPOEhRQUFOQVREUktFejhMVEFZZ0pETVBFVzRJbU5JQVlN
VG82eXJrNVBCMkFpVUFMZnFvRkRTQVdoRUtoYjc3NXh1MTJYNzU4dWJHeFVmZ1VQQjNFbk03
T3psLys4cGRwYVduSnljbDMzbm5uL3YzN3VYSG1SNlpNbWZMd3d3K2ZQMytlSDVkdVJIZjJw
QVhCV3RBQW9rNVBUMDlMUzh2eDQ4ZlBuajNiMk5qNHpUZmZDSitGcDRQWWN2cjA2Wi84NUNj
N2R1eTRjT0VDeTdLZmYvNzVndzgreUQzRk84N2c0T0N2ZnZXclgvemlGNkp4SWJxekp5MEkx
b0lHRUhVKysreXp5NWN2S3owTFR3ZXg1ZEZISC8zem4vOHMrNVRRY1g3NDRRZXIxU29kbDUy
c05Nai82UEY0NXMrZmI3RllIQTdIcmwyN3VNSHZ2dnZ1dnZ2dW16eDU4czAzMy95di8vcXZn
NE9EM0xqZjcvLzFyMzl0dFZxblRadTJlZk5tZmlPaFVNamxjazJkT25YU3BFbE9wL1BxMWF2
MFI4MkoyYng1YzBaR2h0VnFYYmx5SmN1eWhKQ2xTNWZ1MjdlUG45UFQwek45K25UaCt6TXJL
K3ZycjcvbUhyLzU1cHZjZzYrLy9qb3JLMHRGa3RJNGZ5eGZmUEhGekprelgzMzExVEVkQXRB
ajhIUVFXNlpObTNidTNEblpwNFNPZlBIaXhTaDZ1dDF1ZisrOTkxaVc3ZW5wZWVxcHA3akIz
TnpjSTBlTytQMyt5NWN2cjFtejVySEhIdVBHbjMzMjJmdnZ2Ly84K2ZQbno1Ky83Nzc3K0ky
OCtPS0xkOTk5ZDE5ZjM5V3JWNTk0NG9uZi92YTM5RWZOaVZtK2ZQbmc0T0RnNE9EeTVjdWZl
KzQ1UWtoVFUxTk9UczdJeUFnMzU2bW5udHEwYVpOd3JWV3JWdTNZc1lNUTB0ZlhkOHN0dDNE
dXZIMzc5dFdyVjZ0SVVocm5qcVdob1dIcTFLa0hEeDRjazM2Z1dYRGZDNGduWnJONWVIaFk5
aW5lUGMrZlAvL0VFMC9jZi8vOW9uSFp5U3FEL0krWm1abmJ0bTNyNit0VFV1WHorYVpPbmNv
OW5qbHo1bmZmZmNjOS92YmJiL21OT0J5T1U2ZE9jWSs5WHUrMGFkT1V0aVlMd3pEZmZ2c3Q5
L2owNmRPMzNYWWI5N2k0dVBpZGQ5N2hCMzArbjNDdER6NzR3T2wwRWtJMmJkbzBkZXBVN28r
TVJ4NTU1TU1QUDFTUnBEVE9NTXpycjc4K1k4YU10cmEyTVlrSDJnZjN2WUQ0b0Y2bmM5eDY2
NjBQUHZpZzErdmx4cE9Ta2tLaGtIQm1LQlJLU2txUzNZTHNqMjF0YmZmZGQxOTZldnJzMmJN
NU55U0VmUHJwcDB1V0xMRmFyZHhPYjdycEptN2NaREx4dXhzZUh1WTNZamFiR1FIOGZObERr
SDFLdUZtejJjdzlQbmp3WUhaMmRpZ1VLaTh2MzdwMXEyaXRvYUdoMjIrL25SQ3lZTUVDdDl1
OWVQRmlRc2p0dDkvT1diK1NKS1Z4aG1GbXo1NzkvUFBQUytVQlhZUDdYa0RjZVBUUlIxOTc3
VFhacDVRK3dYTTRIUC96UC84akhQbnFxNjhjRG9kMHB0bHM1dXZjQ3hjdWlEWTRPanJxZHJ0
LzhwT2ZjRC9PbkRtenRyYjI4dVhMbzZPalY2NWM0U2ZQbURGRHRrN1B6TXpzNysrbk9FUjVo
SFg2dDk5K08zUG1URjdWZ2dVTEtpb3FIQTVITUJpVXJ2anpuLy84M1hmZkxTNHVKb1FVRnhj
ZlBIandycnZ1VXBla05NNHdURjlmMzV3NWM3WnMyUkx4Z1FDdGdmdGVRRHc1ZmZyMDlPblRk
KzdjK2NNUFA3QXMyOWJXSnIzdlJjUi8vdWQvRmhVVmZmYlpaeXpMc2l4NzdOaXhoUXNYeXJw
U1VWSFJDeSs4NFBQNSt2djdIM3JvSVg2RFpXVmwzM3p6VFRBWWRMdmRkcnVkRzB4TFN6dDQ4
Q0RMc3Q5OTk1M1Q2ZVFuUC9QTU13ODg4TUQzMzMvLy9mZmZDNituLy9HUGYxeStmSGxYVjlm
dzhQREpreWU1U3lMME1BeHozMzMzY1pmcDc3MzMzb3FLQ3Y2cDJ0cGFobUYyNzk0dHUrS21U
WnRtenB6SmxmQ3Z2ZmJhYmJmZHRubnpablZKU3VQY3Nadzllelk3Tzd1eXNuSk0rb0Ztd1gw
dklNNTBkSFQ4NGhlL3NObHN5Y25KeGNYRnd2dlRaZWVQam81dTNicDF3WUlGTjk5ODg4MDMz
N3hnd1lMWFgzOWRkdVpYWDMyMWNPRkNzOW5zY0RoMjdOakJiM0Rmdm4zWjJkbG1zM24rL1Bs
TlRVM2M0UHZ2dno5NzlteVR5WFQ3N2JkdjNicVZuK3p6K1g3MXExOU5talFwSXlQamozLzhv
OFZpNGNaSFJrWXFLeXNkRG9mRllzbkx5NnV0clIzVFVRdnZlM25paVNjQ2dRRC8xUDc5Kytm
T25hdjBNY09KRXlmTVpqTjN0LzdnNEtEWmJPYi9hbEdTcERUT0grUEF3RUJPVHM2TEw3NDRw
a01BZWdTZURzQS82T3pzbkRWclZxejNzbUxGaXIxNzk4WjZMOENvNEw0WEFNS3dkdTNhaXhj
dkRnd01MRisrZk4yNmRiSGIwY2pJU0hWMWRXNXVMbjg3SXdCalJXVGk4SFFBeEx6NjZxdDJ1
MzN5NU1tUFB2cm8wTkJRN0hiRU1JekQ0Y0NkaFdBOE5EWTJYcnQyalh0ODdkbzEzUGNDQUFB
NnBxMnQ3ZXV2dng0ZUhoNGVIdjc2NjYrUEh6OHVmQmFlRGdBQWVpSVFDSHorK2VjZWo4Zmo4
YlMxdFFrL2ZpZndkQUFBMERXNG5nNEFBTVlCbmc0QUFEb21nZTVsN0RwNnRPdm8wWGlyQUFD
QWljT3duajdNc3R1WExObStaTWt3eThaYkN3QUFUQkNHOWZTL3Z2cHFwY05SNlhEOEZZMy9B
UUNKaWtFOC9YSmYzNWJzYk03VHQyUm5YMVp1bkEwQUFMckc3L2UzdGJYeDl6TDYvWDdoczFy
eDlOcmEydXpzYkl2RlVsQlEwTkxTUWdqcDcrOHZMUzFOVGs0dUxTM2wrb2hLUjNqcW5ueVNN
M1F1NnA1OE1qNkhBUUFBTWFhMXRmWFVxVlBYcmwyN2R1MWFaMmRuYTJ1cjhGbXRlUHJqanov
ZTNkM3Q5L3ZmZmZmZDlQUjBRa2haV1puTDVRb0VBaTZYcTd5OFhIWkV4TWFORzdrSFo4K2Vw
ZG5wdFk0T21tazBXNlBjSTgwMHFLS2ZCbFgwMDdTcGl0QUppK0lldGFscVRMamRicjVmME1q
SWlOdnRGajZyRlUvbllGbjJ2ZmZleTgvUEo0VFk3WGJ1SDk5NHZWNnVCYlowUk1UR2pSdXZk
ekRYTzVqMnh2L0xQVkNQd0paQ21tazBXNlBjSTgwMHFJS3F4RkZGS1N5S2U5U09xb2g5VWg5
MU92bngzNENscHFaKzl0bG5oSkNrcENUdWQxRW9GREtaVExJalBLRUxGNjVVVlcxWXRZcnN6
Ynpld1F5L1BlZDZCOE05VmxuKzdkaWtzSE1vdDBhNXgvOTNNdndlb1FxcUVrZlY5UTRtdEh0
Qzk2Z2RWWDlqMlN0VlZjSDI5ckZhcGMvbjA4SDFkQTd1MnN1Y09YTUlJZW5wNmFLcVhEb2ln
cS9UQno3SnYwN3grNVBVWnRKTW85a2E1UjVwcGtFVlZDV09La3BoVWR5amhsUmR2eDRMRjlX
S3A2OVpzK2I4K2ZOK3YzLy8vdjNjZnoxM09wMzgxWFB1ZjNGSlIwVHdubzVBSUJCYWowZzlY
Ui8zdmRUVTFNeVlNU001T2ZuT08rLzh5MS8rUWdqcDdlMHRLU214V0N5TEZ5L3U2K3VUSFJH
Qk9oMnFvRXBmcWlpRm9VNFhvcHZyNmVNSGRUb0NnZEJOUk9ycGVycnZaWnlnVG9jcXFOS1hL
a3BocU5PRkpFU2RmdTNhdGU3dTd0Lzg1amZYT3hqdkp3dXd4QkpMTERXKzdPL3Y3Kzd1anVE
dWRUM2Q5ekpPVUtkREZWVHBTeFdsTU5UcDlCalQweEVJQkVMckVhbW5KMUQvZE5UcFVBVlYr
bEpGS1F4MXVoQ1JpWXN3cHFjakVBaUUxZ09lSGhiVTZWQUZWZnBTUlNrTWRicVFoUEIwM1Bl
Q0paWlk2bXNaOFgwdjZoakUwemxRcDBNVlZPbExGYVV3MU9uMEdOUFRFUWdFUXVzUmthY2ZP
WEtrdmIzZDYvV0dRaUhaQ2NiMGROVHBVQVZWdWxCRktReDFPcytWSzFlNnVycU9IVHZXMk5o
NDdOaXhycTZ1SzFldUNDY1kwOU1SQ0FSQzZ6RytheS9EdzhOZXI3ZTl2ZjNJa1NQQ2NXTjZP
dXAwcUlJcVhhaWlGSVk2blI2RGVEcnVlOEVTU3l6MXRjUjlMK0ZCblE1VlVLVXZWWlRDVUtm
VFkweFBSeUFRQ0sxSGxEd2QvVjcrRWRxc1hLQUtxaEpIRmFVdzFPa3FKSVNuSXhBSWhOWURm
UmxWRUgxR092QkpQczFuRk4xNy9pWHNITXF0VWU3eGhIc0ZWRUVWVkFtWHBEWnpJdmVvSFZY
UitvelVtSjdPZ1RvZGdVRG9KbkR0SlN5NG5nNVZVS1V2VlpUQ2NEMmRIcTE0ZWwxZFhXNXVy
c1ZpS1Nnb2FHbHBJWVF3QXJnNS9mMzlwYVdseWNuSnBhV2wvZjM5MG8yZ1RrY2dFTHFKU0Qz
ZDcvZnI0UCtSUHZ6d3crM3Q3WUZBWU5ldVhYYTduUkRDV3psUFdWbVp5K1VLQkFJdWw2dTh2
Rnk2RWRUcFVBVlYrbEpGS1F4MXVwRFcxdFpUcDA1ZHUzYnQyclZybloyZHJhMnR3bWUxNHVr
ODNkM2REb2VERU1Jd3pLMjMzbXExV3Bjdlg5N2QzVTBJc2R2dFhxK1hFT0wxZWpuZkY0RTZI
WUZBNkNZaTlYUzMyejB5TXNJOUhoa1pjYnZkd21lMTVla0RBd05GUlVVZmZQQUJQekk0T0Zo
UlVWRlNVa0lJU1VwSzRvNGtGQXFaVENiaGlxRUxGNjVVVlcxWXRZcnN6Ynpld1hoM2xsN3ZZ
TGpIS2t0U214bDJEdVhXS1BjNDhFaytWRUVWVkFtWGdVMkZFN2xIN2FqNkc4dGVxYW9LdHJl
UDFTZDFVNmUzdGJVNUhJNDllL2FJeHYxK3Y4VmlJWVNrcDZlalRrY2dFQWFKU090MG44K25n
K3ZwMWRYVkdSa1p6YzNOb3ZGTGx5NXQzTGl4dUxpWUVPSjBPdm5yNlU2blU3b1JYRStIS3Fq
U2x5cEtZYmllVG85V1BKMjVrYUdoSWU1QlNrcktzbVhMVHA4K1RRanA3ZTB0S1NteFdDeUxG
eS91Nit1VGJnUjFPZ0tCMEUzZ2U2UmhRWjBPVlZDbEwxV1V3bENuQytGTW5MZnloUEIwQkFL
QjBIcEU2dWtlaitmcTFhdHV0L3ZLbFN0WHJseHBhbW9TUG1zUVQwZS9GNmlDS2oycThxTGZ5
OWo3dlh6OTlkZU5qWTA5UFQxSGpoenhlRHhuenB3UlBtc1FUK2RBblk1QUlIUVR4djZNTkNy
Z2VqcFVRWlcrVkZFS3cvVjBJWW40R1NrQ2dVQm9QVkNuaHdWMU9sUkJsYjVVVVFwRG5VNlBN
VDBkZ1VBZ3RCN3dkQlZ3M3d0VVFaVWVWWGx4Mzh1NC84K1JDSU40T2dmcWRBUUNvWnN3ZHYv
MHFJRHI2VkFGVmZwU1JTa00xOU9GNktZdjQvaEJuWTVBSUhRVGlkQS9mWnlnVG9jcXFOS1hL
a3BocU5PRm9FNUhJQkFJN1lXeCs2ZVBFOXozQWxWUXBVZFZYdHozZ3Z0ZVZFQ2Rqa0FnZEJQ
b0RSQVdYRStIS3FqU2x5cEtZYmllTGdUOTB4RUlCRUo3QVU4UEMrcDBxSUlxZmFtaUZJWTZY
VWhDZUxyb00xSXNzY1FTUzQwdm8vVVpxVEU5blFOMU9sUkJsYjVVVVFwRG5hNUNRbmc2QW9G
QWFEMk1mZDlMWFYxZGJtNnV4V0lwS0Nob2FXa2hoUFQzOTVlV2xpWW5KNWVXbHZiMzk4dU9p
RUNkRGxWUXBTOVZsTUpRcDZ1Z1VVOS8rT0dIMjl2YkE0SEFybDI3N0hZN0lhU3NyTXpsY2dV
Q0FaZkxWVjVlTGpzaUFuVTZBb0hRVFJqYjAzbTZ1N3NkRGdjaHhHNjNlNzFlUW9qWDYrVmNY
am9pQW5VNlZFR1Z2bFJSQ2tPZFRvKzJQSDFnWUtDb3FPaUREejRnaENRbEpYRzl4MEtoa01s
a2toM2hDVjI0Y0tXcWFzT3FWV1J2NXZVT0Jrc3NzY1JTNDh1L3NleVZxcXBnZS90WWZWSWYx
OU1KSVcxdGJRNkhZOCtlUGR5UDZlbnBvcXBjT2lJQ2RUcFVRWlcrVkZFS1E1MU9qMVk4dmJx
Nk9pTWpvN201bVI5eE9wMzgxWE9uMHlrN0lnTFgweEVJaEc3QzJQZTlNRGN5TkRUVTI5dGJV
bEppc1ZnV0wxN2MxOWRIQ0pHT2lFQ2REbFZRcFM5VmxNSlFwNHNJQm9NZmYveHhZMlBqK2ZQ
blJVOXB4ZE9qQXVwMEJBS2htNGpVMHpsRFAzWHExTVdMRjV1Ym15OWZ2aXg4MXBpZWpqb2Rx
cUJLRjZvb2hhRk9GL0xSUngveGRuM3UzRG51Q3owOEJ2RjA5SHZCRWtzczliV011TitMeUt2
UG5Ea2ovTkVnbnM2Qk9oMnFvRXBmcWlpRm9VNFhvby9QU0tNQ3JxY2pFQWpkQkhydGhnVjFP
bFJCbGI1VVVRcERuUzRrRVQwZGdVQWd0Qjd3OUxDZ1RvY3FxTktYS2twaHFOUHBNWWluNDc0
WExMSEVVbC9MaU85N1NjVFBTRkduUXhWVTZVSVZwVERVNlZKR1IwZEZGMkU0ak9ucENBUUNv
ZlVZaDZlSFFxRnZ2dm5HN1haZnZueTVzYkZSK0pReFBSMTFPbFJCbFM1VVVRcERuUzZrcDZl
bnBhWGwrUEhqWjgrZWJXeHMvT2FiYjRUUEd0UFRFUWdFUXVzUnFhZC85dGxub2g0dlFvenA2
YWpUb1FxcWRLR0tVaGpxZEhvTTR1bTQ3d1ZMTExIVTF6TGkrMTdVTVlpbmM2Qk9oeXFvMHBj
cVNtR28wK2t4cHFjakVBaUUxZ09lSGhiVTZWQUZWZnBTUlNrTWRUbzl4dlIwQkFLQjBIckEw
OE9DT2gycW9FcGZxaWlGb1U2bnh5Q2VqdnRlc01RU1MzMHQ0M25meTV0dnZwbVdscGFXbHZi
Zi8vM2YwZDE5ZEVHZERsVlFwUzlWbE1KUXA5T2o2T2tzeS9LUFUxTlRqeDgvZnZ6NDhiUzB0
RmlJaUJhNG5vNUFJSFFURSt6cHQ5OStlMDFOVFNnVUloUGk2Y3lQU0VmNHdmNysvdExTMHVU
azVOTFMwdjcrZnVsR1VLZERGVlRwU3hXbE1OVHA5Q2g2ZW10cjY5S2xTN096czk5OTk5M2R1
M2VucHFhbXBxYSsrZWFic1JEQkkvSjAwYk5sWldVdWx5c1FDTGhjcnZMeWN1bnFxTk1SQ0lS
dUlpNmZrWG84bmp2dXVLT3dzTkR0ZHNkaTl5SkVubjdycmJkYXJkYmx5NWQzZDNjVFF1eDJ1
OWZySllSNHZWNjczUzVkSFhVNlZFR1Z2bFJSQ2tPZFRvK2lwL09maTc3MTFsdnZ2dnR1ZG5a
MmFXbnB4eDkvSEFzUlBOTGFmSEJ3c0tLaW9xU2toQkNTbEpRME1qSkNDQW1GUWlhVFNUZ3Rk
T0hDbGFxcURhdFdrYjJaMXpzWUxMSEVFa3VOTC8vR3NsZXFxb0x0N2RGMVVVVlBUMHRMYTJ0
cjQ2K2hoMEtoM2J0MzMzNzc3ZEhkdlFpcHB4TkMvSDYveFdJaGhLU25wNk5PaHlxb01wSXFT
bUdvMCtsUjlIVFp6MFdGTjhQRUFxbW5YN3AwYWVQR2pjWEZ4WVFRcDlQSlgwOTNPcDNTMVhF
OUhZRkE2Q1ltMk5OcmFtb201bk5SRHVaRytKR1VsSlJseTVhZFBuMmFFTkxiMjF0U1VtS3hX
Qll2WHR6WDF5ZmRDT3AwcUlJcWZhbWlGSVk2blI2RGZJK1VBM1U2QW9IUVRjRFRWUkQxQmhq
NEpKL211N25kZS80bDdCektyVkh1OFlSN0JWUkJGVlFKbDZRMmN5TDNxQjFWK0o4WTRVR2Rq
a0FnZEJPbzA4T0M2K2xRQlZYNlVrVXBETmZUNlRHbXB5TVFDSVRXQTU0ZUZ0VHBVQVZWK2xK
RktReDFPajNHOUhRRUFvSFFlc0RUVmNCOUwxQUZWWHBVNWNWOUw3anZSUVhVNlFnRVFqZUJP
ajBzdUo0T1ZWQ2xMMVdVd25BOW5SNWplam9DZ1VCb1BlRHBZVUdkRGxWUXBTOVZsTUpRcDlO
alRFOUhJQkFJclFjOFhRWGM5d0pWVUtWSFZWN2M5NEw3WGxSQW5ZNUFJSFFUcU5QRGd1dnBV
QVZWK2xKRktRelgwK2t4cHFjakVBaUUxZ09lSGhiVTZWQUZWZnBTUlNrTWRUbzl4dlIwQkFL
QjBIckEwMVhBZlM5UUJWVjZWT1hGZlMrNDcwVUYxT2tJQkVJM2dUbzlMTGllRGxWUXBTOVZs
TUp3UFowZXJYZzY4eVA4U0g5L2YybHBhWEp5Y21scGFYOS92K3lJQ05UcENBUkNOMkZzVCtj
UWVucFpXWm5MNVFvRUFpNlhxN3k4WEhaRUJPcDBxSUlxZmFtaUZJWTZuUjd0ZXJyZGJ2ZDZ2
WVFRcjlkcnQ5dGxSMFNnVGtjZ0VMcUpSUFAwcEtTa2taRVJRa2dvRkRLWlRMSWpQS0VMRjY1
VVZXMVl0WXJzemJ6ZXdYaDNsbDd2WUxqSEtrdFNteGwyRHVYV0tQYzQ4RWsrVkVFVlZBbVhn
VTJGRTdsSDdhajZHOHRlcWFvS3RyZEgxMFcxNitucDZlbWlxbHc2SWdKMU9nS0IwRTBrV3Az
dWREcjVxK2RPcDFOMlJBU3VwME1WVk9sTEZhVXdYRStuUnl1ZXp0d0lJYVMzdDdla3BNUmlz
U3hldkxpdnIwOTJSQVRxZEFRQ29ac3d0cWRIQmRUcFVBVlYrbEpGS1F4MU9qM0c5SFFFQW9I
UWVzRFRWVUMvRjZpQ0tqMnE4cUxmQy9xOXFJQTZIWUZBNkNaUXA0Y0YxOU9oQ3FyMHBZcFNH
SzZuMDJOTVQwY2dFQWl0Qnp3OUxLalRvUXFxOUtXS1VoanFkSG9NNHVtaXowaXh4QkpMTERX
K3hHZWs0VUdkRGxWUXBTOVZsTUpRcDlOalRFOUhJQkFJclFjOFBTeW8wNkVLcXZTbGlsSVk2
blI2ak9ucENBUUNvZldBcDRjRmRUcFVRWlcrVkZFS1E1MU9qMEU4SGZlOVlJa2xsdnBhNHI2
WDhLQk9oeXFvMHBjcVNtR28wK2t4cHFjakVBaUUxZ09lSGhiVTZWQUZWZnBTUlNrTWRUbzl4
dlIwQkFLQjBIckEwOE9DT2gycW9FcGZxaWlGb1U2bnh5Q2VqdnRlc01RU1MzMHRjZDlMZUZD
blF4VlU2VXNWcFREVTZmUVkwOU1SQ0FSQzY1Rm9uczRJNEViNisvdExTMHVUazVOTFMwdjcr
L3VscTZCT2h5cW8wcGNxU21HbzArblJ0S2VMUnNyS3lsd3VWeUFRY0xsYzVlWGwwbFZRcHlN
UUNOMUVBbnI2cmJmZWFyVmFseTlmM3QzZFRRaXgyKzFlcjVjUTR2VjY3WGE3ZEJYVTZWQUZW
ZnBTUlNrTWRUbzkydlYwanNIQndZcUtpcEtTRWtKSVVsTFN5TWdJSVNRVUNwbE1KdUcwMElV
TFY2cXFOcXhhUmZabVh1OWdzTVFTU3l3MXZ2d2J5MTZwcWdxMnQwZlhNN1h1NllRUXY5OXZz
VmdJSWVucDZhalRvUXFxaktTS1VoanFkSHEwN3VtWExsM2F1SEZqY1hFeEljVHBkUExYMDUx
T3AzUXlycWNqRUFqZFJLSjVPbmZIUzBwS3lySmx5MDZmUGswSTZlM3RMU2twc1Znc2l4Y3Y3
dXZyazY2Q09oMnFvRXBmcWlpRm9VNm5SN3VlSGdHbzB4RUloRzRDbmg0VzFPbFFCVlg2VWtV
cERIVTZQUWJ4ZFBSN3dSSkxMUFcxUkwrWDhLQk9oeXFvMHBjcVNtR28wK2t4cHFjakVBaUUx
Z09lSGhiVTZWQUZWZnBTUlNrTWRUbzl4dlIwQkFLQjBIckEwOE9DT2gycW9FcGZxaWlGb1U2
bnh5Q2VqdnRlc01RU1MzMHRjZDlMZUZDbjYxSlZwU1pWYVROWGhsTkZLUXgxT2ozRzlIU0Vu
a0xCMHhFSWd3YzhQU3lvMC9Xb2lsbDlXSU9xdEprcjQ2bWlGSVk2blI1amVqcENSNkhrNlFp
RXdRT2Vyb0xvTTlLQlQvSnBQcVBvM3ZNdlllZFFibzF5anlmY0s2QktOR2VCNjZBR1ZXa3pW
OFpUNWYxa0Fhbk5uTWc5YWtjVlBpTU5EK3AwUFFicWRFU0NCdXIwc09CNnVoNVY0WHA2SXF1
aUZJYnI2ZlFZMDlNUk9nclU2WWdFRFhoNldGQ25LODZwVkx0bE1KNnFVS2NudGlwS1lhalQ2
VEdtcHlQRVVYbGp4RjFQQjNQOVJ6ZS93ZE1ySlE4bVBsSHhUZ3ZDYUtGMFVzSFRWY0I5TDJw
ektwa0Zyb1BNNnNQOFVoT3FmcnpqNVFZOVd4WmNyMlE0emZIS2xSWmZRVzJlVjlGUTVVMkUr
MTcraFB0ZUl1VWZkWG9jeTFMdEZYck02c09paUxza1h0ajF5aHZxZEc1RU5EaVJMNU4ya2tO
MUNGcjZxeXVlU1loRlZpc2xQMHFEYnB1S0p4WHE5TEQ4M2RNcm1ZRXQrVFNwai80VlJ0SHVK
THVXMzVUdzdJbXVxaTM1bkQrcWUzcThyc1l5UC82KzRSUEYvOGlzUGh4RFZkS3pvdklmdVZJ
L2MwUWZCc2pPaVZ5Vndpc29yMGN3SGttdXh0Rm1SMFBYMDIvTVRDVGlLK1cyVnNtUWlzd3do
azZUOWtybWVpV1Q3em9vZjFFUm50N2YzMTlhV3BxY25GeGFXdHJmM3krZHNISGpScjdLdThI
Q3dyMDJVWXdKM2gyTkhobFBqN2VxdjJzVGVycEU3UVMvVFAvNG95SGVhVkhYT2ZHNTBuSkUv
ZkJsM2krQzRpT3k5NUhpekI4OXZlNnBweTcxOWtiTEovWGs2V1ZsWlM2WEt4QUl1Rnl1OHZK
eTZZU05HemR5dWM3L0pQL3ZyOFNQcjRmMDFicE85NnY0dXJUcVY1NGplckdsTDd6c3BvUm5U
M1JWNWJzTy92MmtWRDBkYVRZMUhsV3l1MU1TeGdmTnBpSlRKYnU3ditjcTNKdDJZRXYrMzAr
bkRzVzNhOFNxcEFjclVuWERzNEl6bk4rVXJCN1pzNTNwb0ZLbE5JZkcxR2cyUlprdXhUZk9q
eGtZazNpMWsrSEhEZjZ5TnZNR0Q1RUxwZDNKbmxveUw5Q1BubDdwY0d5Wk4rK3ZyNzQ2SEFp
TTN5ZjE1T2wydTkzcjlSSkN2RjZ2M1c2WFR0aTRjV1BZbHdHQlFDQzBFRUpQNTJMSFAvL3p0
MGVPak5NbjllVHBTVWxKSXlNamhKQlFLR1F5bWJqQnpzN081NTkvM3JWdTNiTVBQUEIvbGk1
OTdva25ubi8rK2Q4KytPRHp6ei9QUFZaWlZqenlTTmc1bEZ1ajNPTy8vZHUvUVJWVVFaVncr
Y3c5OTB6a0hyV2ppbk90OWIvNXpUODhmZW5TYnc4ZkhxZFA2c25UMDlQVHc5YnAzSU16Wjg3
UWJERHd5U2MwMDJpMlJybEhtbWxRUlQ4TnF1aW5hVk1Wb1JNV3hUMXFVQlYzN2VXVFAvODU0
YTY5T0oxTy9ucTYwK21VVHVBOVBSZ00wbXp3eXE1ZE5OTm90a2E1UjVwcFVFVS9EYXJvcDJs
VEZhRVRGc1U5YWxCVjNaTlBYdXJwb2RrVURYcnk5TjdlM3BLU0VvdkZzbmp4NHI2K1B1a0Uz
dE1wQ1owL0h5VnAwUVNxNklFcWVyU3BpbWhWbURaVjBhQW5UdzlMZTN0N3ZDVUFBRUE4TVpT
bkF3QkFnZ05QajV5NnVycmMzRnlMeFZKUVVORFMwa0lJWVg1RVU2cWtJMXBRVlZ0Ym01MmRy
VFZWSEgvNHd4L2krQ0txbkZlYVVqVXlNdktIUC94aHhvd1pOOTEwazZhRUNkT1ZucDZ1RVZY
MTlmVlpXVmttazJuMjdObjE5Zld4MnpVOFBYSWVmdmpoOXZiMlFDQ3dhOWN1NFgwNDhmVjBx
U29sbmZGVjlmampqM2QzZC92OS9uZmZmVGRlYnp6WnpCdy9mbno2OU9seGZCR2xxdUo3Um5G
SVZiMzAwa3Z6NXMxcmIyOGZIUjNWbERDZVk4ZU8vZTUzdjlPSXFpbFRwbmc4SHBabDNXNjN6
V2FMM2E3aDZWR2d1N3ZiNFhEd1AycmhIVWdrcW1SSEpoNlJCcFpsMzN2dnZmejgvRGhLSWdK
VmdVQmd3WUlGUjQ4ZTFjS0x5S3RpR09iV1cyKzFXcTNMbHkvdjd1N1dpQ3FIdytGMnUrTXJS
b2owOUY2K2ZQbTVjK2ZpcFllRFY1V2ZuKy94ZUlMQm9OdnRMaXdzak4wZTRlbmpaV0Jnb0tp
bzZJTVBQdUJIdEdBSFVsWFNrYmlyNHY0NlRrMU4vZXl6enpTaWFzMmFOWC82MDUrSUJsNUU2
ZXMxT0RoWVVWRlJVbEtpRVZVbWsybnQycldUSmsxeU9Cd0hEeDZNb3lvaWw2N1cxdGJISDM4
OGpwTElqYW8rLy96ektWT21NQXd6WmNxVXp6Ly9QSFk3aGFlUGk3YTJOb2ZEc1dmUEh1Rmcz
TzFBcWtwV1o5eFZFVUs0YXk5ejVzelJpQ3J1MG5EY0wxNHJ2VjUrdjk5aXNjUkZFcEdvc3R2
dGJyZWJ1NWd3ZGVyVWVLbVNDdU5ZdG16WlYxOTlGUzlKUktKcTd0eTUvTFdYbi83MHA3SGJM
enc5Y3FxcnF6TXlNcHFibTBYajhmVjBxU29sbmZGVnRXYk5tdlBuei92OS92Mzc5MCtiTmsw
anFuamkrQ0lxcWJwMDZkTEdqUnVMaTR2aklVcEdWWGw1dWR2dDVpNG1aR1JreEVXVnJEQkN5
TWNmZi95em4vMHNYcEtJbktyVTFGVCsya3RhV2xyc2RnMVBqeHptUm9hR2hrUWoybFExTkRT
a0JWVTFOVFV6WnN4SVRrNis4ODQ3Ly9LWHYweThKRmxWd3FmaUlrbFdGZmNnSlNWbDJiSmxw
MCtmMW9pcXMyZlAvdXhuUDdOWUxGbFpXWEc4c0M3N0l2Nzg1ejkvLy8zMzR5VkpWbFZkWFoz
RDRUQ1pUTE5telhydnZmZGl0MnQ0T2dBQUdBZDRPZ0FBR0FkNE9nQUFHQWQ0T2dBQUdBZDRP
Z0FBR0FkNE9nQUFHQWQ0T2dBQUdBZDRPa2hRNG5nSE9nQ3hBNTZ1SjRMQjRMcDE2NlpPblhy
TExiZHMyclFwM25MMEFjTXdyN3p5Q2lIazVaZGZobzlUMHQ3ZXpqQU0vc2tNSlpvNngrRHBl
bUw5K3ZVUFBQREF1WFBuTGwyNjlNd3p6OFJiamo1Z0dDWW5KMmQwZEhUZXZIbHhmNy9waFMx
YnRpUWxKVzNac2lYZVF2U0JwczR4ZUxxZW1EbHpwdWgva0F0UElQNHh3ekRyMTYrM1dxMThT
OCs0bjJkeGhHR1lKVXVXdlBUU1MwdVhMaFdtU0pTNjExNTdMUzB0TFRVMWRkZVAvMXc0a1pP
MmJObXlwNTU2YXRteVpkeVBoWVdGM0Q5Mk9IVG8wTUtGQ3draHg0OGZ6OG5KU1VsSmNibGN3
cXpHUzNCOGtaNWozQWxtTnB2NS80bXhhdFdxWC8vNjE0U1F4eDkvZlBYcTFmeUtVUmNEVDlj
VEpwTXBGSC83NEhnQUFCeHpTVVJCVkFvSlI1UTgvWlZYWHZINWZFOC8vZlNFNnRNa0RNUHMz
YnMzS1NscDM3NTlzdW5pSG0vZnZ0M3Y5emMyTnNicjM0Wm9CNS9QTjNueTVIUG56azJlUE5u
bjh4RkN0bTdkV2w1ZVRnZ3BLeXZidG0wYklTUS9QLytOTjk3dytYeTdkdTFLV0N2blVUckhR
cUZRYTJ2cjlPblRDU0hEdzhOMzMzMzN2Ly83djk5OTk5M0R3OE94RXdOUDF4TXFkZnJ3OExE
UTA2OWR1emJSNHJTS2lvOExIL052TXpoVVEwTUQzM3lxb2FHQkVQTEREei9ZYkxZelo4N1li
TGFMRnk4U1FzeG1zOS92SjRUNC9YNWtUSHBlYmQrKzNlRndKQ1VsTVF4ejAwMDNjVThkUDM2
Y1laamp4NC9IVkF3OFhVOVVWRlE4OE1BREF3TURseTlmcnFpb0lJVFk3ZmJtNXVaQUlMQmp4
dzc4Q1N3THBhZkxQazVNVnE5ZXpYMEN2Mm5USnY0cWdkUHB2T09PTzhyS3lyZ2ZGeXhZc0hQ
blRyL2YvMS8vOVYvSW1QVDhTVWxKYVd4czlQdjlicmViRy9INy9RVUZCY3VYTHk4b0tBZ0VB
ckVUQTAvWEV5ekwvc2QvL0lmZGJ1ZnZlNm11cnJiWmJHbHBhZHUyYlZQeDlFUisxMG5mYjZJ
K3FMSnpTQUluTFNzcjYrVEprNFNRa3lkUFptVmxjWU9IRGgxaUdPYlFvVVBjajIxdGJkbloy
U2twS2M4OTkxeFNVaEkzbUxBWms1NC9MN3p3Z3MxbXM5bHNtemR2NWtaV3JsejUyR09QRVVJ
ZWZmVFJKNTk4VXJwaXRJQ25Bd0FpWkdSazVQMzMzNTgzYjE2OGhZQi9BRThIQUVRQ2Q2VTRL
eXNyWHYvU0JNZ0NUd2NBQU9NQVR3Y0FBT01BVHdjQUFPTXdOazluRklpaW9JVDk2RHhhMEx3
b3d0Y3VQVDJkY2kwRE05YWtjU005UFQwbEpTWEp5Y2tsSlNXOXZiMFRvbFFyMEdTc3ZyN2U0
WEJZTEpaLytxZC82dXJxa2gweEtudjI3Smt6WjQ3RllsbTRjT0hSbzBjSklmWDE5ZlBuejA5
T1RpNHFLdnI0NDQ5VjFxMnNyQnpQT1RaMlQrK1FCRHhkZTFDbWNmWHExUnMyYkJqcldrWWxy
S2VMUmg1NjZDR1h5eFVJQkZ3dWw5UHBqS0V5cmFLZXNmVDA5SmFXbG1BdzZIYTc3Ny8vZnRr
Um8vTFFRdytkUEhreUVBanMyYk9IKzJheTArbnM2T2hnV2ZiQWdRUFRwazFUV3ZIRWlSTVpH
Umw4WWlNNHgyTGw2VnUzYm5VNEhDYVRpZjlsdm1qUkl1N20xdHJhMnRMU1V0azUwbEtvczdO
ejhlTEZGb3RsN3R5NTNDODNobUh1dlBQT3NyS3kyYk5uODkrQUFDSm8zUG5TcFV1cHFhbG56
NTRkMDFvR0pxeW4yMncycTlWNnp6MzNkSGQzRTBMUzA5TzlYaThoeE92MUptWkhnYkNlZnZq
d1ljN0IwOUxTWkVjTVQxOWZuOFZpNGIvWDdmZjc2K3JxbE83K1pGazJMeS92N2JmZjVoTWJ3
VGtXSzArZlBIbHlaV1ZsUjBkSE1CamtSdmJ0MjhkWmNGRlIwUWNmZkNBN2gwak9rcUtpb25m
ZWVZZGwyYWFtcHJsejUzSVQrRWFna3lkUHBqbklCSVRHblRkdjNzeDlDV0pNYXhrWW1zTS9m
LzU4UlVWRlNVa0pJU1FwS1dsa1pHVEpraVdoVU1oa01zVmVvT1pRejFodGJlMXR0OTAyYWRL
azU1NTdqc3VQZE1UWWZQLzk5OFhGeFh3TFZmNXE1NWRmZmlrNy85bG5uMzNra1VlSUlMRVJu
R094OHZRUFAvenczbnZ2blR0MzdpMjMzUEw3My8rZUVESThQRHhuenB6OSsvZHpUU2xsNXhE
SldXSTJtL25Lbld1YndGZjAwc21BSjJ4bWhvZUhNek16UmEwbkVqeWZsSWNmQ0FRc0Znc2hK
RDA5ZlhCd2tLQk9EOGZSbzBkbnpweXBQbUk4dnZ6eXk5bXpaN3RjcnBHUkVYN1E1L1B0Mjdj
dkx5OVBkaFd1UDR6d1drVUU1MWhzcjZlUGpJd2NQWHJVYXJWeVAyN2F0TWxxdGZLOVRHWG5K
Q2NuYzMvWWNoUVhGemMwTkFqYkk4RFRhUWliR2Y0SzJKaldNalkwaDMvMTZ0V1hYbnFwdUxp
WUVQTGdndzl1MkxDQlpka05Help3NVZXaUVUWmpvNk9qbloyZCtmbjVYSHNpMlJGRFVsTlRV
MXhjL09tbm4vSWpLMWV1N09ucFlWbTJycTR1N0hVblByRVJuR094OG5UdTkweFNVdEtzV2JQ
ZWVPTU5idkRDaFF2cDZlbGNPemVsT2V2V3JVdEpTZUczZWVyVXFidnV1b3Nia2JwNWdudVFM
TXlOOElPaWFZc1dMZHEvZjcvNldva0RUZEs0cDI2KytlYTc3cnJyOU9uVGhKRHU3dTVGaXha
eGQzSDA5UFRFUVhmOG9NOVlSa2JHbWpWcldKYVZIVEVxb3Z3TURRMjk5ZFpiczJmUE5wdk5l
WGw1SG8rSG42YTBPdmNnZ25OczR1NWxIQmtaZWYzMTE5ZXRXMGN6R1FBQVFBUk0zSGVPR0lZ
cExDemtQc01GQUFBUUMvQTlVZ0FBTUE3d2RBQUFNQTd3ZEFBQU1BNmE2L2NDeGdsTmd3aHAy
dzNocThsMWdFa29hSkltVFpHMHAwZmlRUFBlbCtZbmNVNHoyWnVDd2lhTlpkbTFhOWR5dlFH
NGFmWDE5VmxaV1NhVEtTc3I2OENCQXpTN0hydW5yejRzRG5pNmxxQnBFS0hTZGtQVUFTWkJH
Rk5YRFQ1RjBwNGVpWWI2ZTE4bFA0WS96YVNab2ZISmlvcUt3c0xDam80TzdsdVpoQkNiemRi
VTFNU3lyTWZqc2Rsc05MdU9sYWNMQjduSDB1NHUwbDR1M09UMTY5ZGJyZGJDd2tLYUF3QWlh
QnBFS0xYZGtIYUFTUkRvdTJySXBralUweU54b0t6blJQbEpoTk9Na1hRSGtvNUltVEZqeGtj
ZmZTUWNLU2dvT0hUb1VEQVliRzV1WHJod0ljMnVKODdUcGQxZHBMMWN1TW12dlBLS3orZDcr
dW1uYVE0QWlLQnBFS0hVZGtQYUFTWkJvTytxSVUyUnFLZEhRa0hqNmRMOEpNNXBKdXdPcERR
aXhHUXl1Vnd1cTlXYW1abkpmU1d3cmEwdE5UV1ZZWmpVMUZSUkp3OGxZdTdwdzhQRDNHTnBk
eGRwTHhkdXhRU3NkNkxJbUJwRUNOdHV5SGFBU1JBb2t5Wk5rV3hQajhRaHJLZEw4NU5vcHhu
ZkhVaGxoQ2MxTmRYdGRnZUR3WmFXRnU3emh1enNiSS9IdzdLczIrM095Y21oMldPc1BOMXV0
emMzTndjQ2dSMDdkZ2duQ0x1N1NIdTVFSHpkZjl4UU5vaVF0dDJRN1FDVElGQW1UWlFpYVUr
UFJFUDkzU3FibjRRNnpZVGRnWlJHaEt4WXNZTDNkSzYybURKbGlzZmpDUWFEVFUxTmNiNmVY
bDFkYmJQWjB0TFN0bTNieGdoNm93dTd1MGg3dVJCNCtyaVJiUkFoeWlxWGNGSGJEVkVIbUlT
Q0pta2tYSk9jb2FHaGlWTWNiMFRIemcrcXpPSHlreUNuR1hmSXd1NUEwaEVpeVZoWFY5ZWlS
WXZNWnJQRDRhaXZyeWVFMU5iV09od096amJyNnVwb2RvMTdHUUVBd0RqZ08wY0FBR0FjNE9r
QUFHQWM0T2tBQUdBY0p0clRjZkVkQUFCaUJ6NGpOUm8wVFVpRXJ4MTNHMnlDdjVvMHh5NU5r
YlJ0VHVKQWM1cEo4NE1PT2Vxbm1iUzdTd1R2eWpGNyt2VktjU1NtQzJpV01UVWg0ZHR1NEVV
azRaSWdmVmFsYlk3aG9Ubk5wUGxKNUE0NU5HOHhwZTR1bXZCMGhtRmVlKzIxdExTMDFOUlUv
cDlLaTM3aGZQWFZWd3NYTHVRNndIQWpzaDFnUUdTRWJVSWliTHZCVURTak1EeGhQVjJVSXFX
Mk9RbUZ5bW1ta3A4RTdKQkQ4eFpUNnU2aUZVL2Z2bjI3Mys5dmJHd1Uva0lXVHM3UHo5KzJi
WnZ3WDgzS2RvQUJFVURUaEVUYWRrTzlHWVhob1hubkNGT2sxRFluY1ZBL3paVHlrOGdkY3RU
ZllrcmRYYlRpNmNQRHcxSkJ3c2Rtczlubjh3blhrdTBBQThZS1RSTVNwYlliS3Mwb0RBL2xP
MGVhSW1IYm5NU0J2dGVOTUQ4SjNpR0hxTDdGbExxN2FNWFR3ejVlc0dEQnRtM2IrRGFOUktF
RERCZ1RsRTFJWk50dXFEZWpNRHcwN3h4UmlxUnRjeElFeXROTWxCOTB5RkYvaXlsMWQ5R29w
ek0zUWdqNTRvc3ZDZ29La3BLUytNbXlIV0RBbUJEbG1XdXlJVTJtYk9zU1VUT0t4RUY2Y2hL
RjdpWFNEaDZpdGprSkFzMXBKczJQN0ZvSmd1eGJUSlF4YVhjWDJUTlRIZHpMQ0FBQXhnSGZJ
d1VBQU9NQVR3Y0FBT01BVHdjQUFPTVFXMDlYdXRTT2EvRUFBQkFMNHZNWnFkS3RCVUFkMlhz
emVMak9MVFJOU0ZpV1hidDJiVVpHQnI4cEEvK0tyYSt2bno5L2ZuSnljbEZSRWZmbFpHblNw
QW1SSWsyK1VidVhVSjVtb3F4S2lVcjNFbDBnelpqMDJDUHJrQ1BOZkZqR2ZpOWpoempnNlJP
R1NycjR6aTAwVFVncUtpb0tDd3M3T2pwR1IwY3B0NjlmbkU1blIwY0h5N0lIRGh5WU5tMmE4
Q2srYVVvSkVTSk5qbEc3bDlDY1ppcFo1WWxLOXhKZElEMGk2YkZIMWlHSGg4OThXR0xvNmFK
ZnlHMXRiVGs1T1NrcEtSVVZGVXFlam40djZqQUtMU09FblZ0b21wRE1tREhqbzQ4K2t0MStq
SlRISGIvZlgxZFhOMi9lUEg1RW1EU2xoQWhSU2o0eFhQY1NtdE9NUTVwVklWSHBYcUlMcEJs
VE9uWVNVWWNjYWVaVmlHMmRMbnhxL3Z6NU5UVTFmcisvcXFwS3lkUFI3NFVHYWNzSVllY1dt
aVlrSnBQSjVYSlpyZGJNekV6Uk40OWlxanhlOEgrNmZ2bmxsL3lnTUdsS0NaRWlUYjVSdTVl
b24yWkVJYXRDb3RLOVJFY0lNNlowN0pGMXlKRzJabEpoNGp6ZGJEYjcvWDVDaU0vblUvSjA5
SHVoUk5neVFxbHppMG9Ua3RUVVZMZmJIUXdHVzFwYWhCZnBqUHBtSTRUNGZMNTkrL2JsNWVW
eFA0cVNwcFFRV1lUSk4zYjNrckNubVNpcklxTFN2VVJmOEJtVFBmYklPdVFvdmNHVm1EaFB6
OHZMNCtyMDZ1cHFmbno2OU9uQ1gvTG85MEtEcUdXRXRITkwyQ1lrSzFhczRDMU1xV3VtWVZp
NWNtVlBUdy9Mc25WMWRmemZzNktrS1NWRWlqRDV4dTVlb242YXlXWlZSRlM2bCtnSVljYWt4
eDVaaHh5aTBKcEpoVmg1T25NamhKQmp4NDVsWjJlbnBLU3NYNytlWDJYbnpwMVdxNVgvRWYx
ZTFPSFNJbW9aSWR1NVJkU0VSSlRNcnE2dVJZc1dtYzFtaDhOUlgxOVA1RjR2dy9EV1cyL05u
ajNiYkRibjVlVjVQQjV1VUpRMGFVSUlkYjhYSHNOMEw2RTV6V1N6S3NwWVZMcVg2QUpweHNJ
ZU8yV0hIQ0xKZkZqUTd3VUFBSXdEdmtjS0FBREdBWjRPQUFER0FaNE9BQURHSVQ3OVh1SzFI
UUFBTURhNi9Jd1VGcTlDVDA5UFNVbEpjbkp5U1VsSmIyK3Y3Qnhwc3c2YTloMEdoaVpwMGpt
SmZJOEFUY2FFRnNIZDlXL1VqQ2tkVjJWbEpUOUkyZTlGMUNXR0pzOGl4dXpweGN4Ym9vQ25h
NHFISG5ySTVYSUZBZ0dYeStWME9tWG5TSnQxMExUdk1EQTBTVk9hazVobkkwM0dlRVM5U295
YU1kRnhuVGh4Z3VzS3gvMUkwKzlGdGtzTWZaNDVZdWpwb2w5Y24zNzZhVzV1cnRsc3pzM041
VzY4ZHpnY1o4NmNJWVI4OTkxM0RvZURYOFZzTmhjVUZMUzB0TWh1Qi9kUXFwT2VudTcxZWdr
aFhxOVgvZXN6MG1ZZDZ1MDdEQXhOMHBUbUpPWjVTSCthU1h1VkdEVmp3dU5pV1RZdkwrL3R0
OStXSHF4S3Z4ZHBseGo2UFBQRXRrNFhQcFdUazdONzkyN3VlNlM1dWJtRWtKVXJWKzdjdVpO
aG1OMjdkei81NUpQOHpGQW8xTnJhT24zNmRObnRTSDhFUXBLU2trWkdScFlzV1JJS2haVDZ2
UkM1WmgzU2tjU0JKbWxLY3hMemJLUTh6WWhjcnhLalpreDRYTTgrKyt3amp6eENKQWVyM3U5
RjJpV0dQczg4RStmcEpwT0o3L2RpTnBzSklYdjI3TG4zM252dnZQUE9GU3RXdlAzMjI0U1E3
ZHUzYzErK1ltN3M5d0pQcHljOVBYMXdjSkJRL0dLWE51dFFiOTloWUdpU3BqUW5NYzlHeXRO
TXRsZUpVVE1tUEM3T3hFUlhGTUwyZTVGMmlhRi9PL1BFczA3djcrK2ZOR25TeXkrL2JMVmF1
VC9OVWxKU0doc2IvWDYvMiswV1hXOFJialk1T1ZuVTdCVHdQUGpnZ3hzMmJHQlpkc09HRFZ5
bElFWGFySU9tZlllQm9VbWEwaHlqT3BRNk5Ca2pDcjFLakpveDJlUGlCMm42dlVpN3hGRG1X
VWlzUEoyNUVVSklhMnRyVGs2T3lXVEt5Y25oRHl3N083dTN0NWUvZ1B2Q0N5L1liRGFiemJa
NTgyYm14disvSS94MXQyN2RPcTRuRE0wUkpocmQzZDJMRmkzaS9sVktUMDhQTnlqS2xiUlpo
Mno3anNTQkptblNPYkluWjRKQWt6R2kwSXpJZUJsVE9TNytSOUVjMlg0djBpNHhzbmxXUjVm
M01nSUFBSkFGM3lNRkFBRGpBRThIQUFEakFFOEhBQURqb0k5K0x3QUFBR2pBWjZSR0k3TFdK
UkcwbFRBU1NOcFlRY2JHeW9SbGJNeWUvaGJ6bGlqZzZab2lzdFlsRWJTVk1CSkkybGhCeHNi
S2hHVXNocDR1ZTZ2bSt2WHJyVlpyWVdFaEllVFlzV1B6NXMwVC9ZZFNNRTRpYTEwU1FWc0pJ
NEdralJWa2JLeE1XTVppVzZkTFBmMlZWMTd4K1h4UFAvMDBJV1QrL1BrMU5UVit2NytxcWdx
ZUhpMGlhMTBTUVZzSkk0R2tqUlZrYkt4TVdNWW0ydE9GM2NqTVpqUGZBUWFlSGkwaWExMFNR
VnNKSTRHa2pSVmtiS3hNV01ZbTJ0T0ZQK2JtNW5KMWVuVjFOVHc5V2tUV3VpU0N0aEpHQWtr
Yks4allXSm13ak1YSzAyVnZqQkhOYkcxdC9lbFBmNXFTa3VKeXVlRHAwU0t5MWlVUnRKVXdF
a2phV0VIR3hzcUVaVXdyOXpMQzB3RUFZUHhvNVh1azhIUUFBQmcvV3ZGMEFBQUE0d2VlRGdB
QXhpSE9ucjV6NTg3Smt5ZUh2ZkNDS3pNQUFFQkRuRDhqblQ1OStva1RKMFM3aUhocmdOQTFp
R0JaZHUzYXRSa1pHZnpMbDhpTk9FaWt2VGc0S2lzckUvQ2twWC92Qy9Pelo4K2VPWFBtV0N5
V2hRc1hIajE2Tk1ZYTQ0bjBTSVdHbVo2ZUxydFdmWDE5VmxhV3lXVEt5c282Y09BQU4rSndP
TGo3WHJxNnVtaDJQV1pQNzdndWp2R2MwTUovSk0zdkl1S3RBVUxYSUtLaW9xS3dzTENqbzJO
MGRKUitMUU1UV1M4T1FzaUpFeWU0WDQwVEpsVlRoRDF3VVg0ZWV1aWhreWRQQmdLQlBYdjJH
UHM3UnlwSHVucjE2ZzBiTnNpdVpiUFptcHFhV0piMWVEemMveU5OVDA5dmFXa0pCb051dC92
KysrK24yWFdzUEgzcjFxME9oOE5rTXZHL3pELzk5TlBjM0Z5ejJaeWJtOHY5UDFMWkc5aWx2
LytsNVFDRHZqSEswRFNJbURGanhrY2ZmVFRXdFF4TVpMMDRXSmJOeTh0NysrMjNFL2FzVXo5
d2xmejA5ZlZaTEJiaHQ4cU5pdWhJTDEyNmxKcWFldmJzV2RuSkJRVUZodzRkQ2dhRHpjM05D
eGN1SklTa3A2Y2ZQbnlZODNUS2YvNGVLMCtmUEhseVpXVmxSMGRITUJqa1JuSnljbmJ2M3Mx
OWF6UTNONWZmb0hRWHN2c1YvWWkrTVVyUU5JZ3dtVXd1bDh0cXRXWm1abkwvQWppUkczR1FT
SHR4UFB2c3M5eFgreEwyckZNL2NLWDhmUC85OThYRnhjODg4MHhzeFdrQTZaRnUzcno1c2Nj
ZVU1cmYxdGFXbXByS01FeHFhdXJ4NDhjSkliVzF0YmZkZHR1a1NaT2VlKzY1V1BWN29mVDBE
ei84OE41Nzc1MDdkKzR0dDl6eSs5Ly9uaEJpTXBuNDdpNW1zNW5mb0hRWHN2c1YvWWkrTVVy
UU5JaElUVTExdTkzQllMQ2xwWVc3dEpmSWpUaElwTDA0a3BLU292dk5POTJoZnRTeStmbnl5
eTluejU3dGNybEdSa1ltUkdQY2tCN3A4UEJ3Wm1ZbVo5YXlaR2RuZXp3ZWxtWGRibmRPVG83
d3FhTkhqODZjT1pObXY3RzluajR5TW5MMDZGR3IxVXFvNi9UazVPVHU3bTdwZmxWK1JOOFlJ
VFFOSWxhc1dNRjdPbWRQaWR5SWcwVGFpNE1uWWM4NnlnUG5wOVhVMUJRWEYzT1hYbzJON0pI
VzF0YVdscGFxckRWbHloU1B4eE1NQnB1YW1yanI2WVNRMGRIUnpzN08vUHo4aW9vS21sM0h5
dE81Mzh4SlNVbXpaczE2NDQwM0NDR3RyYTA1T1RrbWt5a25KNGMvVk9tNjY5YXRTMGxKa2Iz
Q0xod1Vyb0srTVVKbzJrcDBkWFV0V3JUSWJEWTdISTc2K25xbHRSS0h5SHB4OENUZ1dVZnp4
aFJPbGwxcmFHaG9ndVJPT0xKSHVtalJJdTVTcDNDYThNZmEybHFIdzhIWlpsMWRIYitkakl5
TU5XdldzQ3hMczJ1dDlIdUpGcG9TQXdBQUU0elJ2a2NLVHdjQUpESkc4M1FBQUVoazRPa0FB
R0FjTk8zcEdyeGVEd0FBV21aQ1B5T056SjNoNldPQzVrVVJ2bmJjL2VuMTlmWHo1ODlQVGs0
dUtpcjYrT09QSjBxc1ZxQkptclRmaXpTTmlRUE5DU1BOVCtKVWFaSDFlK0VRZHNpSklHTmo5
dlRya29DbmF4REtwUEd0SjV4T1owZEhCOHV5Qnc0Y21EWnRXb3pWYVJUMXBLbjBoRkhwNEdG
VXhuVENpUEtUQ08vb3lQcTlFSVVPUXByd2RHbS9GMmxkMzluWnVYanhZb3ZGTW5mdVhPNVhQ
ZmVzMld3dUtDaG9hV21KNEhnQUIwM1NwSzBuL0g1L1hWM2R2SG56WWlsTnU2Z25UYWtuakhv
SEQyTkRjOEpJODVOUTcrZ3g5WHRSNnBDakNVK1g5bnVSS2lzcUtucm5uWGRZbG0xcWFwbzdk
eTQvSGdxRldsdGJwMCtmSHNIeEFBNmFwSWxhVC9CL0ZYNzU1WmV4bEtaZDFKT20xQk5HdllP
SGdhRThZYVQ1U1p4MzlGajd2U2gxeU5HRXAwdjd2VWlWbWMxbXZuTG5tdTV1Mzc2ZCt4b1ZQ
ekxXNHdFY1laTW0yM3JDNS9QdDI3Y3ZMeTh2bHRLMFM5ZzZYZG9USm13SEQyTVQ5b1NSelUr
Q3ZLTWo2UGVpMUVGSUU1N09JZXozUWlTOVhJcUxpeHNhR2dLQkFEK1NrcExTMk5qbzkvdmRi
amUvMmVuVHB5ZHM1Umd4WVU4Q1VldUpsU3RYOXZUMHNDeGJWMWRIMmRMVGVLZ25UYmJmUzln
T0hrYUY4b1NSelU4aWVIcGsvVjU0dEZpbmM3OW5oUDFlaUtTWHk2bFRwKzY2Nnk1dWhCdDg0
WVVYYkRhYnpXYmJ2SGt6UDIzbnpwMVdxelVSem9Pb3dOd0lQeWlhSm1vOThkWmJiODJlUGR0
c051Zmw1WGs4bm9tVHF3MW9raWJiNzBYYXdTTkJrRDFod3A1bXNuazJKS0lqcGV6M0loMlBJ
R05HNi9jQ0FBQ0pqS2EvY3dRQUFHQk13Tk1CQU1BNHdOTUJBTUE0d05NQjBEVDR2QXFNQ1hn
NkFESkU3S1JSdDJDVkRVWmxYd3pEdlBMS0s0U1FsMTkrZVR3YlpCaG15NVl0NHhjbTdaUlNY
MStmbFpWbE1wbXlzcklPSERpZ3RIZlIvUm9zeTY1ZHU1YjducjJTSHZVZVBrb0twV3RKTmRN
Y2w4cmVWWTRyTFBCMEFHUklLRS9QeWNrWkhSMmROMi9lT0QwOU96djc2dFdyNHhRbTdaUmlz
OW1hbXBwWWx2VjRQUHgvNlZUU3dEK3VxS2dvTEN6czZPZ1lIUjFWMlplb2h3K05jdWxhS3Qx
ZFZJNUxxWU9RVkFNOEhZRHhJdnUrWW01c1JrVFQxRWg5eS94YUZSVVZLU2twOCtiTmEydHJJ
NFMwdGJYbDVPU2twS1JVVkZRSXR5emN1M1JmMGdaS3NnY2kxYk5reVpLWFhucHA2ZEtsM09S
UFAvMDBOemZYYkRibjV1WnkzNXBoR09hMTExNUxTMHRMVFUzZHRXdVgwbllxS3l0ZmZQRkZm
cWZTN1JRV0ZuTGlEeDA2dEhEaFFuVmhmS2VVZ29LQ1E0Y09CWVBCNXVabTliV0VCenRqeG95
UFB2cElaUUtSNitIRE1Jek5ack5hcmZmY2N3Ly9CY213YTBrMTB4eVgwbmJnNlFCRUg2VjNr
YkFaRVUxVEkvVXQ4MzVkWFYzdDkvdHJhbW9XTEZoQUNKay9mMzVOVFkzZjc2K3FxaExPVjIr
RnBOUkFLYXlldlh2M0ppVWw3ZHUzajl0Z1RrN083dDI3L1g1L2RYVjFibTR1TjJmNzl1MSt2
Nyt4c1ZHcERtVVlabWhvYU02Y09aY3VYVkxhenRhdFc4dkx5d2toWldWbDI3WnRVMUVsN0pU
UzF0YVdtcHJLTUV4cWFxcDZHd1poUWt3bWs4dmxzbHF0bVptWlN0OExVK3JoYy83OCtZcUtp
cEtTa2pHdEplM3VvbjVjU3R1QnB3TVFmYVR2SW1reklwcW1SaXBiSGg0ZTVqM2Q3L2NUUXZ4
K3Y4VmlJWVNZeldadXhPZnpjWE5vV2lGSkd5aU45VWk1eHlhVGlkKzcyV3pteG9lSGg5VVBr
QnZmdEduVDczNzNPNlh0L1BERER6YWI3Y3laTXphYjdlTEZpMHFTUkoxU3NyT3pQUjRQeTdK
dXR6c25KNGZ5V0ZKVFU5MXVkekFZYkdscFVlcFhMdHZEaHlNUUNIQ3ZCZVZhMHU0dVlZOUxh
ZS93ZEFDaWovUmRKTnVNaUlScmFpVEZicmMzTnpjSEFvRWRPM2J3bnM3VnN6VTFOZlBuenll
RTVPWGxjWFY2ZFhVMU4wZDI3MkViS0kzMVNGWHFkSlhNQ01kOVB0K3NXYk9VdGtNSWNUcWRk
OXh4UjFsWm1aSWVhYWVVS1ZPbWVEeWVZRERZMU5SRWZ6MTl4WW9Wdktjci9XMGgyOE9IRUhM
MTZ0V1hYbnFwdUxpWWNpM1o3aTVoajB0cDcvQjBBS0lQY3lORXJoa1I5NVI2VXlNcDFkWFZO
cHN0TFMxdDI3WnRvdXZwMmRuWng0NGRJNFFjTzNZc096czdKU1ZsL2ZyMVNudVg3a3ZhUUls
RWRDMm90YlUxSnlmSFpETGw1T1R3MTlObDU4dHVaOHVXTFVyYklZUWNPblNJWVpoRGh3NnA2
QkV5TkRSVVcxdkwvWTB5YTlhc3VybzZtclVJSVYxZFhZc1dMVEtielE2SG83NitYbGE4dElj
UHQvck5OOTk4MTExM25UNTlla3hyQ1RYVEhGZlk3Y2lPaEFXZURrQ2NHVk1WQm9BNjhIUUE0
Z3c4SFVRUmVEb0FBQmdIZURvQUFCZ0hlRG9BQUJnSGVEb0FBQmdIZURyUUJ3ME5EWTJOamFG
UXFMR3hzYUdoZ1hJVjlXZVZKdmg4UHJmYkxUdGZaUzBBdEFBOEhlaURob2FHVHo3NTVILy85
My8vK3RlL1JzdFZsYmJ6MVZkZlNaK0NsUU5kQUU4SCtxQ2hvZUhVcVZNZWorZlVxVk84dllv
ZU5EUTB0TGUzZXp5ZXpzNU9wVUhSTnFVN3VucjE2cUZEaDJROTNlUHhIRDU4ZUdCZ0lLcEhC
a0EwZ2FjRGZkRFEwUERERHovd1MzNVErS0Nob2VIaXhZcytuNC83VC9heWc2SnRTbmYweFJk
ZmRIVjF5VDQxT2pvNk1ERFEzTndjdmNNQ0lNckEwNEUrYUdob0dCMGRQWExreU9qb0tHKzRI
by9INS9QeExpKzFlT21nYUp1eU8xSzZiajQ2T2pvNE9BaFBCMW9Hbmc3MGdkQmgrY2Vkblow
ZWo2ZTl2VDBDVHhjWnQvUlo2WU9HaG9iRGh3K2ZPM2N1bWdjR1FGU0Jwd01BZ0hHQXB3TUFn
SEdBcHdNQWdIR0Fwd01BZ0hHQXB3TUFnSEdBcHdNQWdISDRoNmUzdGJYdEJRQUFvSDhZR0Rv
QUFCaUcvdzlSMWorN1dPODFFUUFBQUFCSlJVNUVya0pnZ2c9PSIgLz48L3A+PHA+Jm5ic3A7
PC9wPjxwPkluIENQVSB1c2FnZSBvZiB0aGUgRG9tVSwgdGhlcmUgaXMgYWxzbyBub3QgbXVj
aCB0byBzZWUsIGV2ZW50dWFsbHkgYSB2ZXJ5IHNsaWdodCBjaGFuZ2Ugb2Y8L3A+PHA+bWl4
OjwvcD48cD4mbmJzcDs8L3A+PHA+PGltZyBhbHQ9IiIgc3JjPSJkYXRhOmltYWdlL3BuZzti
YXNlNjQsaVZCT1J3MEtHZ29BQUFBTlNVaEVVZ0FBQWZFQUFBRnNDQUlBQUFCVHFCZTNBQUFn
QUVsRVFWUjRuTzJkZTNBVVpiNzNtOHhNQ0lObUpnbGhBNFloQVVNdUpNRVFEZ0t2VXJ6V2Uw
VFJYWEVEdXF4b25WcFhUaDFBSXhHdDlXaXhXVUIyQlFRbGtDTUhoUkFJb3VuSkRiTENoa3Np
Y0lwQXdpS1N5QjNrbXBucHllMzU1NjE2LytEOW8zZmJabnBtK3BsT1pxWXYzMC85cW12eXpE
UGQzMzZtK3p1LzlQVDhIdWJ2QUFBQWRFRnpjek1UYlEwQUFBQUdnZWJtNXUzYnQvL0Qwd2tB
QUFBdHMzMzdkbmc2QUFEb0JIZzZBQURvQjNnNkFBRG9CM2c2QUFCb2lXb0o0bWZoNlFDRUJZ
WmhvaTFCRlJwQW1PanY3K2ZkSEo0T1FDUlFnNStxUVFNSUI3Mjl2YWRQbjJaWjlzNmRPelUx
TmVLbjRPa2c3TFMzdC8vcVY3OUtTRWlJalkyZFBIbnlybDI3K0hibW44VEh4Ny80NG92WHIx
OFgycVVyMFp3OXFVR3dHalNBUWFlenM3T2hvYUdscGVYU3BVczFOVFduVDU4V1B3dFBCK0hs
N05tenYvakZMelp1M1BqVFR6OXhISGYwNk5FWFhuaUJmMHB3bkd2WHJ2M21ONy81NVM5LzZk
TXVSblAycEFiQmF0QUFCcDBqUjQ3Y3VYTW4wTFB3ZEJCZVhucnBwYi84NVM5K254STd6czJi
TjYxV3E3VGRiK2RBamNLZlRxY3pPenZiWXJFNEhJN05temZ6alQvODhNT3p6ejQ3ZlBqd29V
T0gvdXUvL3V1MWE5ZjRkcmZiL2R2Zi90WnF0WTRjT1hMVnFsWENTbnA3ZTB0S1NrYU1HREZz
MkxDaW9xSjc5KzdSN3pVdlp0V3FWY25KeVZhcmRlSENoUnpIRVVKbXpKaXhZOGNPb1U5bloy
ZEtTb3I0L0V4UFR6OTE2aFQvK1BQUFArY2ZuRHAxS2owOVBZaWtRTzNDdm56MzNYZWpSNC8r
K09PUFE5b0ZvRVhnNlNDOGpCdzU4dkxseTM2ZkVqdnlyVnUzQnRIVGs1S1NkdS9lelhGY1oy
Zm5hNis5eGpkbVpXWHQzNy9mN1hiZnVYTm44ZUxGTDcvOE10LysxbHR2UGZmY2M5ZXZYNzkr
L2Zxenp6NHJyT1RERHo5ODZxbW5MbHk0Y08vZXZWZGVlZVgzdi84OS9WN3pZbWJQbm4zdDJy
VnIxNjdObmozNzdiZmZKb1RVMXRabVptYjI5Zlh4ZlY1NzdiV1ZLMWVLWC9YR0cyOXMzTGlS
RUhMaHdvV0hIbnFJZCtjTkd6WXNXclFvaUtSQTdmeStWRmRYanhneFl1L2V2U0hwQjZvRjk3
MkFhR0kybTN0NmV2dytKYmpuOWV2WFgzbmxsZWVlZTg2bjNXL25JSTNDbjZtcHFldlhyNzl3
NFVJZ1ZTNlhhOFNJRWZ6ajBhTkgvL0RERC96ajc3Ly9YbGlKdytFNGMrWU0vL2pxMWFzalI0
NE10RGEvTUF6ei9mZmY4NC9QbmozN3lDT1A4SThMQ3d1Ly9QSkxvZEhsY29sZjlmWFhYeGNW
RlJGQ1ZxNWNPV0xFQ1A2ZmpGLy8rdGZmZlBOTkVFbUIyaG1HK2VTVFQwYU5HdFhjM0J5U2VL
QitjTjhMaUE3QjgzU2VoeDkrK0lVWFhyaDY5U3JmSGhNVDA5dmJLKzdaMjlzYkV4UGpkdzEr
LzJ4dWJuNzIyV2NURXhQVDB0SjROeVNFSERwMGFQcjA2VmFybGQvb2tDRkQrSGFUeVNSc3Jx
ZW5SMWlKMld4bVJBajkvZTZDMzZmRXF6V2J6Znpqdlh2M1ptUms5UGIyenA4L2Y5MjZkVDZ2
NnVycUdqTm1EQ0ZrNHNTSkxNcysvdmpqaEpBeFk4YncxaDlJVXFCMmhtSFMwdExlZWVjZHFU
eWdhWERmQzRnYUw3MzAwdHExYS8wK0ZlZ2JQSWZEOFQvLzh6L2lsdVBIanpzY0RtbFBzOWtz
NUxrLy9mU1R6d3I3Ky90Wmx2M0ZMMzdCL3psNjlPaUtpb283ZCs3MDkvZmZ2WHRYNkR4cTFD
aS9lWHBxYXVyRml4Y3BkdEUvNGp6OSsrKy9IejE2dEtCcTRzU0p4Y1hGRG9mRDYvVktYL2pr
azAvdTNMbXpzTENRRUZKWVdMaDM3OTZaTTJjR2x4U29uV0dZQ3hjdWpCczNidlhxMVlwM0JL
Z04zUGNDb3NuWnMyZFRVbEkyYmRwMDgrWk5qdU9hbTV1bDk3MzQ4S2MvL2FtZ29PRElrU01j
eDNFY2Qvanc0VW1USnZsMXBZS0NnZzgrK01EbGNsMjhlSEh1M0xuQ0N1Zk5tM2Y2OUdtdjE4
dXliRkpTRXQrWWtKQ3dkKzllanVOKytPR0hvcUlpb2ZPYmI3NzUvUFBQMzdoeDQ4YU5HK0xy
NlgvODR4OW56NTU5N3R5NW5wNmVreWRQOHBkRTZHRVk1dGxubitVdjB6L3p6RFBGeGNYQ1V4
VVZGUXpEYk5teXhlOExWNjVjT1hyMGFENkZYN3QyN1NPUFBMSnExYXJna2dLMTgvdHk2ZEts
akl5TTB0TFNrUFFEMVlMN1hrQ1VhV3RyKytVdmYybXoyV0pqWXdzTEM4WDNwL3Z0MzkvZnYy
N2R1b2tUSnc0ZE9uVG8wS0VUSjA3ODVKTlAvUFk4ZnZ6NHBFbVR6R2F6dytIWXVIR2pzTUlk
TzNaa1pHU1l6ZWJzN096YTJscSs4YXV2dmtwTFN6T1pUR1BHakZtM2JwM1EyZVZ5L2VZM3Z4
azJiRmh5Y3ZJZi8vaEhpOFhDdC9mMTlaV1dsam9jRG92RmtwT1RVMUZSRWRKZWkrOTdlZVdW
Vnp3ZWovRFVybDI3eG84ZkgraHJoaE1uVHBqTlp2NXUvV3ZYcnBuTlp1Ry9sa0NTQXJVTCsz
amx5cFhNek13UFAvd3dwRjBBV2dTZURzRFB0TGUzangwN050eGJtVE5uenZidDI4TzlGYUJY
Y044TEFESXNXYkxrMXExYlY2NWNtVDE3OXRLbFM4TzNvYjYrdnJLeXNxeXNMT0YyUmdCQ3hj
ZkU0ZWtBK1BMeHh4OG5KU1VOSHo3OHBaZGU2dXJxQ3QrR0dJWnhPQnk0c3hBTWhKcWFtdTd1
YnY1eGQzYzM3bnNCQUFBTjA5emNmT3JVcVo2ZW5wNmVubE9uVHJXMHRJaWZoYWNEQUlDVzhI
ZzhSNDhlZFRxZFRxZXp1YmxaL1BVN2dhY0RBSUNtd2ZWMEFBRFFEL0IwQUFEUU1BYTZsL0Zj
WStPNXhzWm9xd0FBZ01paFcwL3Y0YmdOMDZkdm1ENjloK09pclFVQUFDS0ViajM5Yng5L1hP
cHdsRG9jZjBQaGZ3Q0FVZEdKcDkrNWNHRjFSZ2J2NmFzek11NEVMcHdOQUFDYXh1MTJOemMz
Qy9jeXV0MXU4Yk5xOFhScEhlcUxGeTlPbXpZdE5qWjIyclJwZkIxUmFZdEE1YXV2OG9iT1Ir
V3JyMFo2QndBQUlDSTBOVFdkT1hPbXU3dTd1N3U3dmIyOXFhbEovS3hhUEoxSDdPbno1czBy
S1NueGVEd2xKU1h6NTgvMzIrTERlKys5UndpNWRPa1N6YmE2MjlwaysxQ3VpcVliVk5GM2d5
cjZibEJGMzAyZHFoVEFzcXhRTDZpdnI0OWxXZkd6NnZYMHBLUWtmdUticTFldjhpV3dwUzAr
dlBmZWUvZmJtTmFhLzNPL2paRU56K3A4MlQ2VXE2THBCbFZRRlJWVmhjeFdGYXBTNTFoRldK
VmluOVJxbmg0VEU4Ti9GdlgyOXBwTUpyOHRBcjAvL1hUM3M4K1d2L0VHMlo3NmYwOE9JOXRU
NzdjeHdaZTlXOGJKOXVuNVFyNFA1UmFoQ3FxaW9tcFo2Z29WcWxMbldFVlkxZi9qdUx1ZmZl
WnRiUTNWSjEwdWx3YXVwL09JUFQweE1kRW5LNWUyK01EbjZWY081dDZuK0FnbEZhbXlmU2hY
UmRNTnFxQXFLcXI0UEYxdHF0UTVWcEZXZGY5K09GeFV2WjVlVkZRa1hEM241K0tTdHZqQWV6
b0NnUkNDOTNTRUdrT3BwMnZzdmhmaDdwY2ZmL3h4NnRTcEZvdmw4Y2NmdjNEaGd0OFdINUNu
UXhWVStRVHlkUFdxVXVycFdycWVQa0NRcHlNUVBvRThYYjJoMU5PMWROL0xBRUdlRGxWUTVS
UEkwOVdyQ25tNkxNalRFUWlFWmtLcHAydnB2cGNCZ2p3ZHFxQUtxalNqeWdqM3ZRd1E1T2tJ
QkVJem9kVFREVkUvdmJ1N3U2T2o0M2UvKzkzOU51WUVPK2QrRzNQMTRNVGdTMUtSS3R2bnlz
RmMyVDZVVzRRcXFJSXFxQkl2TDE2ODJOSFJvYUIrZ0krSis2QVRUK2RCbm81QUlEUVRBOGpU
Z3p5clEwOVgzVld6VUZZRlZWQUZWVVpSQlUrWEJYazZBb0hRVE9BN1VsbVFwME1WVkVHVlps
VEIwMlZCbm81QUlEUVRpang5Ly83OXJhMnRWNjllN2UzdDlkdEJ2WjdPc3V5NGNlTmlZMk5u
enB6SmwyTU1NczhSRC9KMHFJSXFxTktNS2tXZWZ2ZnUzWFBuemgwK2ZMaW1wdWJ3NGNQbnpw
MjdlL2V1dUlONlBUMDVPWmxsV1k3aldKWmRzR0FCb1p2bmlHYWdFUWdFSXZveHNHc3ZQVDA5
VjY5ZWJXMXQzYjkvdjdoZHZaNmVsSlRFc3F6WDYyVlpkc1NJRVlSNm5pUFZmUnFIc2lxb2dp
cW9Nb29xbzExUHI2cXFHak5tekxCaHd4WXZYbXcybXduMVBFZjNLZVlmd1JKTExMR003bEx4
UEVmQlVhK25DN0FzNjNBNENPWTVnaXFvZ2lvOXFUSmFuazRJNmUvdlAzMzZkRlpXMXAvKzlD
ZUNlWTRRQ0lTZVlwQThYVFAxWHZnSmoxSlNVdjd6UC8rVHYrU0NlWTZnQ3FxZ1NqK3FqT2Jw
Q2tDZWprQWdOQk9veXlnTDhuU29naXFvMG93cTVPbXlJRTlISUJDYUNYaTZMTWpUb1FxcW9F
b3pxZ3g0M3dzOTRqa3hhR3JWWTRrbGxsaEdkNmw0VGd5MzI0MzVTSkVqUUJWVVFaWEtWQ25O
MDV1YW1zNmNPZFBkM2QzZDNkM2UzdDdVMUNSK1ZvZWVqa0FnRUJvSXBaN09zaXgvZXpjaHBL
K3ZqMlZaOGJNNjlIVFZmUnFIc2lxb2dpcW9Nb29xNU9teUlFOUhJQkNhQ2FXZTduSzVjRDNk
VHhnOVI0QXFxSUtxNktveTJuMHZWVlZWNmVucEpwTXBMUzJ0cXFxS1VNK0pnVUFnRUJvSW8v
Mk9ORDQrM3VsMDhuTmkyR3cyUWowbmh1bytqVU5aRlZSQkZWUVpSZFVBUEoySWZtcWtHVS9Q
emMxMU9wMzhuQmo1K2ZtRWVrNE1CQUtCMEVBbzlYU24wM252M2oyV1plL2V2WHYzN3QzYTJs
cnhzK3IxOUtOSGo4Ykh4ek1NRXg4ZmYvVG9VVUk5SjhhVmc3azBOZWs5Sy9ObCsxemRORTIy
RCtVV29RcXFvQXFxeEV2RmMyS2NPbldxcHFhbXM3TnovLzc5VHFmei9Qbno0bWZWNituang0
OFhycjA4K3VpamhIcE9EQVFDZ2RCQUdPMDdVcnZkTGx4N1NVaElJTlJ6WXFqdXFsa29xNElx
cUlJcW82Z3kybmVrbFpXVkRvZkRaREtOSFR0MjkrN2RoSHBPREFRQ2dkQkFHQzFQVndEeWRL
aUNLcWpTakNwNHVpekkweEVJaEdZQ25pNEw4blNvZ2lxbzBvd3FlTG9zeU5NUkNJUm1RcW1u
bzM2Ni96QjZqZ0JWVUFWVjBWV0Z1b3hCd0R4SFdHS0pwYmFXaXVjNVF2MzBhSDhhcXpOSGdD
cW9ncXJvcWtLZUxndXVweU1RQ00wRTZxZkxnandkcXFBS3FqU2pDdmU5eUlJOEhZRkFhQ2FN
Vmh0QUFjalRvUXFxb0VvenFveFdQNTBSa1ppWVNERFBFUUtCMEZNWXpkTUZEaDgrL082Nzd4
TE1jd1JWVUFWVmVsSmxXRStmUFh2MjVjdVhDZVk1UWlBUWVvcEIrbzVVWTU3ZTFOUzBZTUVD
L2pIbU9ZSXFxSUlxM2FoU1BNK1JEeHJ6OUZtelpoMC9mcHgvakhtT0VBaUVmc0tBOTcwY09I
RGdpU2VlRVA3RVBFZFFCVlZRcFI5VkJyejI4dVNUVDM3MTFWZkNuNWpuQ0lGQTZDY002T21o
Z2p3ZHFxQUtxalNqQ3I4amxRVjVPZ0tCMEV3WThIcDZxQ0JQaHlxb2dpck5xRUtlTGd2eWRB
UUNvWmxBbmg0RThad1lKOWc1OXlscTBwT0tWTmsrVnc3bTB0UzJwOWtpVkVFVlZFR1ZlS2w0
VGd4Q2lOZnJQWERnUUUxTnpmWHIxMzJlMG9tbjh5QlBSeUFRbWdtbGVUcHY2R2ZPbkxsMTYx
WmRYZDJkTzNmRXorclEwMVYzMVN5VVZVRVZWRUdWVVZRcDlmUnZ2LzFXc092TGx5ODNORFNJ
bjlXaHB5TVFDSVFHUXFtbiszajErZlBueFgvcTBOTlY5MmtjeXFxZ0NxcWd5aWlxOEIycExN
alRFUWlFWnNKb3RYYjcrdnJlZi8vOVVhTkdEUmt5aEdFWVFqMG5odW8ralVOWkZWUkJGVlFa
UlpYUlBIM0ZpaFVUSmt4b2JXM3Q3Ky9uV3lqbnhFQWdFQWdOaE5FODNlRndzQ3dyYnFHY0Uw
TjFuOGFockFxcW9BcXFqS0xLYUw4ak5abE1TNVlzR1Rac21NUGgyTHQzTDZHZUUrTStSYTE2
TExIRUVzdm9MaFhQaWFIVjcwaVRrcEpZbHVVNGptWFpFU05HRU9vNU1WVDNhYXpPSEFHcW9B
cXFvcXRxWUhsNmYzKy96MFVZSHZWNit2ejU4MW1XOVhxOUxNc21KeWNUNmpreEVBZ0VRZ014
QUUvdjdlMDlmZm8weTdKMzd0eXBxYWtSUDZWZVQ3OTA2ZElUVHp4aHNWalMwOVA1Qyt1VWMy
S283dE00bEZWQkZWUkJsVkZVS2ZYMHpzN09ob2FHbHBhV1M1Y3UxZFRVbkQ1OVd2eXNlajFk
QWNqVEVRaUVaa0twcHg4NWNzU254b3NZSFhxNjZqNk5RMWtWVkVFVlZCbEZsZEh1ZTFFQThu
UUVBcUdaZ0tmTGdqd2RxcUFLcWpTakNwNHVDL0owQkFLaG1ZQ25Cd0h6SEVFVlZFR1Z0bFFO
Wko2aklPakUwM21RcHlNUUNNMEU4blJaY0QwZHFxQUtxalNqQ3A0dUMvSjBCQUtobVlpaXAz
LysrZWNKQ1FrSkNRbi8vZC8vSFE0Umd3WHlkS2lDS3FqU2pLb0llenJIY2NKanU5M2UwdExT
MHRLU2tKQVFEaEdEQmZKMEJBS2htWWl3cDQ4Wk02YTh2THkzdDVkRXlkTVpFWHdMNWptQ0tx
aUNLdjJvaXJDbk56VTF6Wmd4SXlNalkrZk9uVnUyYkxIYjdYYTcvZlBQUHcrSENMOElWaTZB
ZVk0UUNJUitJaXJYMDUxTzUyT1BQWmFmbis4ejVWQUVZQmptNFljZnRscXRzMmZQN3Vqb0lK
am5DS3FnQ3FyMHBDckNuaTU4TDdwMTY5YWRPM2RtWkdSTW16YnR3SUVENFJBUmhHdlhyaFVY
RjArZE9wVmduaU1zc2NSU1IwdkY4eHdGSjZDbkp5UWtORGMzQzlmUWUzdDd0MnpaTW1iTW1N
SGRQQTF1dDl0aXNSRE1jd1JWVUFWVmVsSVY0VHpkNy9laTRwdGhJc1B0MjdmZmUrKzl3c0pD
Z25tT0VBaUVuaUxDbmw1ZVhoNzU3MFhGOEhlOHhNWEZ6Wm8xNit6WnN3VHpIRUVWVkVHVm5s
VGhkNlN5SUU5SElCQ2FDWGk2TE1qVG9RcXFvRW96cXVEcHNpQlBSeUFRbWdsNHVpekkwNkVL
cXFCS002cmc2VUVRejRsQlU2c2VTeXl4eERLNlM4eUpJUS95ZEtpQ0txalNqQ3JrNmJMZ2Vq
b0NnZEJNd05ObFFaNE9WVkFGVlpwUkJVK1hCWGs2QW9IUVRNRFRaVUdlRGxWUUJWV2FVV1ZN
VDMvLy9mZERuUk1EZ1VBZ05CQUc5UFNXbHBhVWxCVEIweW5ueEZEZHAzRW9xNElxcUlJcW82
Z3ltcWQ3UEo2SkV5YzJOallLbms0NUp3WUNnVUJvSUl6bTZZc1hMLzd6bi85TVJKUFlVYzZK
Y2VWZ0xrMU5lcy9LZk5rK1Z6ZE5rKzFEdVVXb2dpcW9naXJ4TXRKellrU2RJVU9HK0V3elRU
a25CZ0tCUUdnZ2pKYW5Dd2g1T3VXY0dLcTdhaGJLcXFBS3FxREtLS3JnNlpSellpQVFDSVFH
d3JDZVRnL3lkS2lDS3FqU2pDcDR1aXpJMHhFSWhHWUNuaTRMOG5Tb2dpcW8wb3dxZUxvc3lO
TVJDSVJtQXA0dUMvSjBxSUlxcU5LTUtuaDZFRERQRVpaWVlxbXRKZVk1a2dkNU9sUkJGVlJw
UmhYeWRGbHdQUjJCUUdnbTRPbXlJRStIS3FpQ0tzMm9ncWZMZ2p3ZGdVQm9KdURwc2lCUGh5
cW9naXJOcURLYXAxZFVWR1JrWkZnc2xyeTh2SWFHQm9KNWpoQUloSjdDYUo2K1lNR0NqbzRP
dDl1OWMrZk94TVJFZ25tT29BcXFvRXBQcW96bTZUd2N4KzNldlRzM041ZGduaU1FQXFHbk1L
Q244N05oMk8zMkkwZU9FTXh6QkZWUUJWVTZVbVc0ZVk1NCtHc3Y0OGFOSTVqbkNJRkE2Q21N
bHFjdlhyejQrdlhyYnJkNzE2NWRJMGVPSkpqbkNLcWdDcXIwcE1wb25sNWVYajVxMUtqWTJO
akpreWYvOWE5L0paam5DSUZBNkNtTTV1a0tRSjRPVlZBRlZacFJCVStYQlhrNkFvSFFUTURU
WlVHZURsVlFCVldhVVFWUGx3VjVPZ0tCMEV6QTA0TWduaFBqQkR2blBrVk5lbEtSS3R2bnlz
RmNtdHIyTkZ1RUtxaUNLcWdTTHpFbmhqekkweEVJaEdZQ2Vib3N1SjRPVlZBRlZacFJCVStY
QlhrNkFvSFFUTURUWlVHZURsVlFCVldhVVFWUGx3VjVPZ0tCMEV3WXpkTXJLeXV6c3JJVXpJ
bWh1ay9qVUZZRlZWQUZWVVpSWlRSUGYvSEZGMXRiV3owZXorYk5tL2txakpSellpQVFDSVFH
d21pZUx0RFIwZUZ3T0FqMW5CaXErelFPWlZWUUJWVlFaUlJWeHZUMEsxZXVGQlFVZlAzMTE0
UjZUb3o3RkxYcXNjUVNTeXlqdXpUaW5Cak56YzBPaDJQYnRtMzhuNVJ6WXFqdTAxaWRPUUpV
UVJWVVJWZVYwZkwwc3JLeTVPVGt1cm82b1lWeVRnd0VBb0hRUUJqTjA1a0g2ZXJxb3B3VFEz
V2Z4cUdzQ3FxZ0NxcU1vc3BvbnE0QTVPa0lCRUl6QVUrWEJYazZWRUVWVkdsR0ZUeGRGdVRw
Q0FSQ013RlBsd1Y1T2xSQkZWUnBSaFU4WFJiazZRZ0VRak1CVHc4QzVqbUNLcWlDS20ycHdq
eEg4aUJQUnlBUW1nbms2YkxnZWpwVVFSVlVhVVlWUEYwVzVPa0lCRUl6QVUrWEJYazZWRUVW
VkdsR0ZUeGRGdVRwQ0FSQ00yRTBUeGNxdlFndG1PY0lxcUFLcXZTanltaWV6aVAyZE14emhF
QWc5QlB3ZE14ekJGVlFCVlg2VVFWUHh6eEhXR0tKcFc2V1Jwem5pRHpvNlpqbkNLcWdDcXIw
b3dwNU91WTVRaUFRK2dtamViclBQRWVFRU14ekJGVlFCVlg2VVdVMFQxY0E4blFFQXFHWmdL
ZkxnandkcXFBS3FqU2pDcDR1Qy9KMEJBS2htWUNueTRJOEhhcWdDcW8wb3dxZUhnVHhuQmcw
dGVxeHhOSVF5OVVUNzVkR1c0UEtsOUViSDh5SklRL3lkS2lDcWdlaWxHRVc3Vk9kS2pXTkZi
Tm9uekJLa1ZhRlBGMFdYRTlISU1UQkxOckhlOWI5MHVpTFVXZndReVQyOU1nRlBGMFdtVHo5
d1NOYkRUbUNOS0JLTTZvQ3VPUmdxbG85MExGaUZ1MWoyaGhtMFQ1U2pIY3dRSjcrejRpQ0tu
aTZMTUh5OUZMa0xJakJqSDhjUytIZXhBRFh3RWUwOGxBdGhOVFRJeGZ3ZEZtQzVPbi9TRmhF
eDdjYWNnUnBRSlZXVkFVeXlrRlVsVnV5ZDBDckt2M1pzSDVWa1NxYnpTai83MEd5WmsyOGd6
NURKT3dDOHZUSVFUVW5oczlSVy9xUFlOb2VDS0ZkL3lFWkNnMkV6enZZRnVEWlFWbS9zaWdW
SlhlRHVGckpKbVJXRzNTN1ArY3hnNXF0KzY2a1ZQSXZTemhHSXp6eHdCRDUvY2ZMNzc0TTFu
SCtUMCt2Zk8yMTJ6LytPRmcrcVNWUHA1b1RvNVM1c2pwWEdEWGZ3MXIwL3BIaTFQdWxvbTlJ
U24vK0JseUkzSks5NGovRm5jVTlBM1dqWE5YUGY3WXh2M3J0VStrbUtGWDUzV0x3bzhwM3JF
VGJFaHJ2bHpMOFdQMTg5b3BlSXZTL3NqcVhYaFcvc3o3cjhhdktSNTY0cDZBcVVKOUFZeVU5
Uy8rUlQ0VTBWdjlNRG53MktsVVZmRldCZ21samNnL21CczgvK0IwTXNnWnhuaTZiemRDb3Vs
L0s1QjU4b0p0NEtHUlVTVDRWb3A2blM1MkI4aDBNZUZ3OWVLcnlRK3IzdEdJVzdSTTh2ZFRo
V0QxaHd0OCsvcmpINHhtNFQyckowMm5teFBEdjRBaUVUNGl2eGJVRi91eEhoUFV0K09lbis4
OS9pdCtVSUs5cUV4bWwzNWZUdktIUmZ0UEZuczdIeHYvMXY3N2Z2MytBUHFrbFQvYzdKMFo3
ZS9zNzc3eFRzblRwVzg4Ly83OW56SGo3bFZmKzdkLys3ZTFYWG5ubm5YZUNMOTk4K21uWlBy
OS80UVhaUHBSYmhDcW9naXFvRWk5NTExcjJ1OS85N09relpueS9iOThBZlZKTG5rNHpKd1lo
NVB6NTh6UnI4eHc4S051SGNsVTAzYUNLdmh0VTBYZURLdnB1NmxSRi9ubnQ1ZUJmL21LNGF5
ODBjMklRUXJ4ZUw4M2E3bTdlTE51SGNsVTAzYUNLdmh0VTBYZURLdnB1NmxSRkNLbDg5ZFhi
blowMFBXblFrcWZUeklsQnY3YmU2OWNIVDlxZ0FWWDBRQlU5VUVXUE9sWFJveVZQbDZWMXNH
ZHJCUUFBYmFFclR3Y0FBSU1EVDFkSVpXVmxWbGFXeFdMSnk4dHJhR2dnb2dsVVZhVksycUlH
VlJVVkZSa1pHV3BUeGZQKysrOUg4VTBNY2x5cFNsVmZYOS83Nzc4L2F0U29JVU9HUkV0WThM
RktURXhVaWFxcXFxcjA5SFNUeVpTV2xsWlZWUlZ1QWZCMGhiejQ0b3V0cmEwZWoyZno1czNp
bTNDaTYrbFNWWUYwUmxmVmdnVUxPam82M0c3M3pwMDdvM1h1K1IyWmxwYVdsSlNVS0w2SlVs
WFJQYUo0cEtwV3JGZ3hZY0tFMXRiVy92NSs5YWdTT0h6NDhMdnZ2cXNTVmZIeDhVNm5rK000
bG1WdE5sdTRCY0RUQjBwSFI0ZkQ0UkQrVk1NWlNDU3EvTFpFSGg4TkhNZnQzcjA3TnpjM2lw
S0lTSlhINDVrNGNXSmpZNk1hM2tSQkZjTXdEei84c05WcW5UMTdka2RIaDBwVU9Sd09sbVdq
SzBaQWVtelBuajM3OHVYTDBkTERJNmpLemMxMU9wMWVyNWRsMmZ6OC9IQnZGNTQrSUs1Y3VW
SlFVUEQxMTE4TExXcXdBNmtxYVV2VVZmSC9JTnZ0OWlOSGpxaEUxZUxGaS8vODV6OFRGYnlK
MHZmcjJyVnJ4Y1hGVTZkT1ZZa3FrOG0wWk1tU1ljT0dPUnlPdlh2M3FrUVZUMU5UMDRJRkM2
SW9pVHlvNnVqUm8vSHg4UXpEeE1mSEh6MTZOTnliaHFjcnA3bTUyZUZ3Yk51MlRkd1lkVHVR
cXZLck0rcXFDQ0g4dFpkeDQ4YXBSQlYvYVRqcUY2OER2Vjl1dDl0aXNVUkZFcEdvU2twS1ls
bVd2NTR3WXNRSWxhamltVFZyMXZIang2TWxpVWhValI4L1hyajI4dWlqajRaNzYvQjBoWlNW
bFNVbko5ZlYxZm0wUjlmVHBhb0M2WXl1cXNXTEYxKy9mdDN0ZHUvYXRXdmt5SkVxVVNVUXhU
Y3hrS3JidDIrLzk5NTdoWVdGMFJEbFI5WDgrZk5abHVXdkp5UW5KNnRFRlNIa3dJRURUenp4
UkZUMDhFaFYyZTEyNGRwTFFrSkN1QVhBMHhYQ1BFaFhWNWRQaXpwVmRYVjFxVUZWZVhuNXFG
R2pZbU5qSjArZS9OZS8valh5a3Z5cUVqOFZGVWwrVmZFUDR1TGlaczJhZGZic1daV291blRw
MGhOUFBHR3hXTkxUMDZOMVlkM3ZPL2prazA5KzlkVlhVZEVUU0ZWbFphWEQ0VENaVEdQSGp0
MjllM2U0QmNEVEFRQkFQOERUQVFCQVA4RFRBUUJBUDhEVEFRQkFQOERUQVFCQVA4RFRBUUJB
UDhEVEFRQkFQOERUZ1VHSjRrM29BSVFQZUxxVzhIcTlTNWN1SFRGaXhFTVBQYlJ5NWNwb3k5
RUdETU9zV2JPR0VQTFJSeC9CeHlscGJXMWxHQWFUekZDaXFtTU1ucTRsbGkxYjl2enp6MSsr
ZlBuMjdkdHZ2dmxtdE9Wb0E0WmhNak16Ky92N0oweVlFUFh6VFN1c1hyMDZKaVptOWVyVjBS
YWlEVlIxak1IVHRjVG8wYU45WmlJWEgwRENZNFpobGkxYlpyVmFoY0tlVVQvT29nakRNTk9u
VDEreFlzV01HVFBFUStRemRHdlhyazFJU0xEYjdadi9PY1d3a1FkdDFxeFpyNzMyMnF4WnMv
Zy84L1B6K2VrZDZ1dnJKMDJhUkFocGFXbkp6TXlNaTRzcktTa1JqMnEwQkVjWDZUSEdIMkJt
czFtWUdlT05OOTc0N1c5L1N3aFpzR0RCb2tXTGhCY091aGg0dXBZd21VeTl2YjNpbGtDZXZt
Yk5HcGZMOWZycnIwZFVueXBoR0diNzl1MHhNVEU3ZHV6d08xejg0dzBiTnJqZDdwcWFtbWpO
SEtJZVhDN1g4T0hETDErK1BIejRjSmZMUlFoWnQyN2QvUG56Q1NIejVzMWJ2MzQ5SVNRM04v
ZlRUejkxdVZ5Yk4yODJySlVMQkRyR2VudDdtNXFhVWxKU0NDRTlQVDFQUGZYVXYvLzd2ei8x
MUZNOVBUM2hFd05QMXhKQjh2U2VuaDZ4cDNkM2QwZGFuRm9KNHVQaXg4SnBCb2VxcnE0V1Ns
QlZWMWNUUW03ZXZHbXoyYzZmUDIrejJXN2R1a1VJTVp2TmJyZWJFT0oydXpGaTB1TnF3NFlO
RG9jakppYUdZWmdoUTRid1Q3VzB0REFNMDlMU0VsWXg4SFF0VVZ4Yy9Qenp6MSs1Y3VYT25U
dkZ4Y1dFa0tTa3BMcTZPby9IczNIalJ2d0w3QmRLVC9mNzJKZ3NXclNJL3daKzVjcVZ3bFdD
b3FLaXh4NTdiTjY4ZWZ5ZkV5ZE8zTFJwazl2dC9xLy8raStNbVBUNGlZdUxxNm1wY2J2ZExN
dnlMVzYzT3k4dmIvYnMyWGw1ZVI2UEozeGk0T2xhZ3VPNC8vaVAvMGhLU2hMdWV5a3JLN1Ba
YkFrSkNldlhydy9pNlVZKzY2VG5tMDgxVkw5OWlJRUhMVDA5L2VUSms0U1FreWRQcHFlbjg0
MzE5ZlVNdzlUWDEvTi9OamMzWjJSa3hNWEZ2ZjMyMnpFeE1YeWpZVWRNZXZ4ODhNRUhOcHZO
WnJPdFdyV0tiMW00Y09ITEw3OU1DSG5wcFpkZWZmVlY2UXNIQzNnNkFFQWhmWDE5WDMzMTFZ
UUpFNkl0QlB3TVBCMEFvQVQrU25GNmVucTBaalVCZm9HbkF3Q0Fmb0NuQXdDQWZvQ25Bd0NB
ZmdqTjA1a0FES0lndzM1MVBsaDBkblpPblRvMU5qWjI2dFNwUC83NG85OCtWVlZWNmVucEpw
TXBQVDE5ejU0OWhCQ080NVlzV1pLY25Eem9iNmdtb0JtMGJkdTJqUnMzem1LeFRKbzBxYkd4
a1R4NE9pUW1Ka1pXY3BSUmRwaEp4OUJvbEphV0JqbS9wSTVhVlZXVm5aMGRHeHRiVUZCdzRN
QUJtazJFN3VsdGtvQ25xNG01YytlV2xKUjRQSjZTa3BLaW9pSy9mV3cyVzIxdExjZHhUcWZU
WnJNUlFvcUxpL1B6ODl2YTJ2cjcrNFpJZDJ3QUFCa2ZTVVJCVkNNcVZ4M1FETnJjdVhOUG5q
enA4WGkyYmR2bTgxdlRSWXNXTFYrK1BBSTYxWU95d3l6SUdCcUJFeWRPOEdsVDhHN2lEa1ZG
UlcxdGJSekg3ZG16WitUSWtUUmJDWmVucjF1M3p1RndtRXdtNFdObnlwUXAvTTJ0RlJVVjA2
Wk44OXRIbXZ1M3Q3Yy8vdmpqRm90bC9QangvTWNVd3pDVEowK2VOMjllV2xxYThBc0lJSkNZ
bUhqMTZsVkN5TldyVndPZE5ubDVlZlgxOVY2dnQ2NnVqaS9mTVdyVXFHKy8vVGFTT2xVRnph
QUpYTGh3d1dLeENML1V2WDM3dHQxdXYzVHBVcmhGcWdwbGg1bUF6eGdhQVk3amNuSnl2dmpp
aTVBOG5jZnRkbGRXVmxMZU14b3VUeDgrZkhocGFXbGJXNXZYNitWYmR1ell3VnR3UVVIQjEx
OS83YmVQZEg4S0NncSsvUEpManVOcWEydkhqeC9QZHhBS2dRNGZQcHhtSncxRlRFeE1YMS9m
OU9uVGUzdDdUU2FUM3o3TnpjMTJ1NTFoR0x2ZHp2OVMyV1F5bFpTVVdLM1cxTlRVWGJ0MlJW
Wnk5S0VaTko0Yk4yNFVGaGFLaTJLdVdyV0sveTJKb1ZCMm1QRkl4OUFJdlBYV1c3Lys5YThK
eGFVSW53N0N4YjFqeDQ3UmJDaGNudjdOTjk4ODg4d3o0OGVQZitpaGgvN3doejhRUW5wNmVz
YU5HN2RyMXk2K0tLWGZQdEw5TVp2TlF1Yk9sMDBRLy9BUEYycWtKQ1ltWHJ0MmpRUk5vREl5
TXB4T0o4ZHhMTXRtWm1ZU1F1eDJPOHV5WHErM29hSEJhSmVHQ2QyZ0VVS09IVHVXbHBaV1Vs
TFMxOWZIdC9UMDlLU21wb2E3Z29jS1VYYVlFWDlqYUJENDJpODAzMEZLbjNXNVhEdDI3TWpK
eWFIWlVIaXZwL2YxOVRVMk5scXRWdjdQbFN0WFdxMVdvWmFwM3o2eHNiRWRIUjNDczRXRmhk
WFYxZUx5Q1BEMDRMend3Z3ZMbHkvbk9HNzU4dVY4WGlBbFBqN2U2WFI2dmQ3YTJscitRdWVj
T1hNRVR6ZmdoVTZhUVNzdkx5OHNMRHgwNkpDNFViaVFhRFNVSFdaK3g5Qm9oSlNuTDF5NHNM
T3prK080eXNyS2hJUUVtdldIeTlQNXo2S1ltSml4WThkKyt1bW5mT05QUC8yVW1KaklsM01M
MUdmcDBxVnhjWEhDT3MrY09UTno1a3krUmVybThIUXBIUjBkVTZaTXNWZ3MvL0l2LzlMWjJj
azMrZ3hVUlVVRlh6UnU3Tml4bFpXVmhKQno1ODVObVRMRmJEWTdISTZxcXFvbzZJNHFOSVBH
UEVoWFZ4Y2haTXFVS1FhOFZFV1VIbVoreDlCb2lFY3ArREZHQ05tNmRXdGFXcHJaYk03SnlY
RTZuVFRyajl5OWpIMTlmWjk4OHNuU3BVdHBPZ01BQUZCQTVINXp4REJNZm40Ky8xMDVBQUNB
Y0lEZmtRSUFnSDZBcHdNQWdINkFwd01BZ0g1UVhiMFhNRUJvQ25GSTN6aURGK0tnR1RScEh5
TVh5VkYybUJsNXhPamRVbHdUSmlMMVhoYnQ4dzJEdlRjcWg2WVFCNC80alRONElRN0tlaTgr
Zll4Y0pFZlpZV2JrRWVPUmRVdWZtakFScWZkQzUrblNlekNsMVYya3RWejR6c3VXTGJOYXJm
bjUrVFE3QUh5Z0wxM2k5NDB6WUNFT1FqZG8wajVHTHBLajdEQXo4b2p4QlBmMFFEVmh3bHp2
UmFtblM2dTdTR3U1OEozWHJGbmpjcmxlZi8xMW1oMEFQdENYTHBHK2NjWXN4RUhvQmszYXg4
aEZjcFFkWmtZZU1aN2dudTYzSmd5ZkJJZXoza3VJbnQ3VDA4TS9sbFoza2RaeTRWOW90Q1J4
Y0tFc1hVSWtoNWRoQzNFUXVrR1Q5akZ5a1J4bGg1bVJSNHdudUtjSHFna1Q1bm92ZEo2ZWxK
UlVWMWZuOFhnMmJ0d283aUN1N2lLdDVVTHdjLzhCUTFPSWcwYzgxQVl2eEVFemFOSStSaTZT
byt3d00vS0k4VkQ2bTlBdEl2VmU2RHk5ckt6TVpyTWxKQ1NzWDcrZUVkVkdGMWQza2RaeW9k
OW5FQWdGcFV1a0xVWXJ4RUV6YU5JK1JpNlNvK3d3TS9LSVNVZURCTFk3b1YzVjlWNEFBQUNF
Ry96bUNBQUE5QU04SFFBQTlBTThIUUFBOUVPa1BSMFgzd0VBSUh6Z08xSzlFVkloRG9aaCtO
dUVhVjZsWTVSVkx6SHlvSVY2bVBFdFZWVlY2ZW5wSnBNcFBUMTl6NTQ5RWRRYmZXamNVdHBI
ZXFyS0VyS24zeS8xRFhpNnFxQXZ4RUVJV2JSbzBmTGx5ME45bGY1UVhDVEhzSU5Hcys5U1o3
RFpiTFcxdFJ6SE9aMU9mb1pTbzBIamxuNzdDS2VxTE9IeWRJWmgxcTVkbTVDUVlMZmJoVW1s
ZlQ2Q2poOC9QbW5TSkw0Q0ROL2l0d0lNQ0FuNlFoeTNiOSsyMisyWExsMEs2Vlc2UkZuMUVp
TVBHczIrTXd4anM5bXNWdXZUVHovTlR4eWZsNWRYWDEvdjlYcnI2dW9tVFpvVVNjRXFRWm1u
aTA5VldjTG82UnMyYkhDNzNUVTFOZUszWE53NU56ZDMvZnIxSE1jSkxYNHJ3SUNRb0MvRXNX
clZxcGRmZmpuVVYra1NaZFZMakR4bzlQdCsvZnIxNHVMaXFWT25Fa0thbTV2dGRqdkRNSGE3
dmFXbEpWSmlWWVF5VHhlZnFyS0UwZE43ZW5xa0VzV1B6V2F6eStVU3Y4cHZCUmdRRXBTRk9I
cDZlbEpUVTRYemlyNThoeTVSVnIzRXlJTVcwcjU3UEI2THhVSUl5Y2pJY0RxZEhNZXhMSnVa
bVJrQm5XcERnYWY3bktxeWhOSFRaUjlQbkRoeC9mcjFRcGxHRXFBQ0RBZ0p5a0ljRlJVVjA2
Wk5DL1ZWZWtWWjlSSWpEeHI5dnQrN2QyL0ZpaFdGaFlXRWtQajRlS2ZUNmZWNmEydHJjVDJk
c28vUHFTcEw1RHo5d1R0bEdFTElkOTk5bDVlWHg1Y2k0M3Y2clFBRFFvS21FQWNoWk1xVUtl
SmlwMzVmWlJ5VVZTOHg4cURSajlqUW9VTm56cHg1OXV4WlFraEZSWVhENGVDTFBsVldWa1pC
ZC9TUUhqK0U0aGdqa2xOVkZ0ekxDQUFBK2dHL0l3VUFBUDBBVHdjQUFQMEFUd2NBQVAwUVhr
OFBkS2tkMStJQkFDQWNST2M3MGtCZis0TGdTQWU4cXFySzRYRHd0eCtjTzNmT2J4OHBWVlZW
MmRuWnNiR3hCUVVGL085MXhlK203aWVLNURodXlaSWx5Y25Kd2tEUjFDR1JIdkI2cmZmaTl6
RHpHWitCSDJiaDNvdElRbk5pYnR1MmJkeTRjUmFMWmRLa1NZMk5qWDdYbyt6STlDSDBleG5i
ZkFPZUhtSEVnNWFZbU5qUTBPRDFlbG1XZmU2NTUvejJrVkpVVk5UVzFzWngzSjQ5ZTBhT0hD
bCtpcjZzaEhZcExpN096ODl2YTJ2cjcrL25XMmpxa0VpSFZOLzFYc1Q3RzJoOFFqM005SDIr
Qno4eDU4NmRlL0xrU1kvSHMyM2J0a0MvMGxKMlpQb1FSay8zK2VCcWJtN096TXlNaTRzckxp
NE81T21vOTBLRHo2R3piOTgrL3RBUlQwRkxjL0s0M2U3S3lzb0pFeVlJTFNHVmxkQXVvMGFO
K3ZiYmI4VXROSFZJR0VuMUVuM1hleEVmUW9IR0o5VERURHFHZW9MbXhDU0VYTGh3d1dLeGRI
ZDNTOWVnN01qMElieDV1dmlwN096czh2Snl0OXY5MldlZkJmSjAxSHVoUVR4b0ZSVVZqenp5
eUxCaHc5NSsrMjF4MlEzWmswMjR6SExzMkRHaE1hU3lFdHJGWkRLVmxKUllyZGJVMUZUKzF4
ejBkVWpFMVV2MFhlL0ZKeUh6T3o3S0RqUHhHT29KbWhQenhvMGJoWVdGYjc3NXB0ODFET1RJ
RklpY3A1dk5acmZiVFFoeHVWeUJQQjMxWG1qd08rQ05qWTJqUjQ4TzNzY0hsOHUxWThlT25K
d2MvczlReTBwb0Y3dmR6cktzMSt0dGFHamd2endJcVE2SlVMMUUzL1ZleElkUW9QRlJjSmp4
Q0dPb0oyUlB6R1BIanFXbHBaV1VsUFQxOWZsZHd3Q1BUSjdJZVhwT1RnNmZwNWVWbFFudEtT
a3A0Zzl3MUh1aHdXZkErL3Y3Mjl2YmMzTnppNHVMQS9YeFllSENoWjJkblJ6SFZWWldDdjhZ
aGxwV1Fydk1tVE5IT0hONEw2YXZReUt1WHFMdmVpL2lReWpRK0NnNHpNaURZNmduZ3ArWTVl
WGxoWVdGaHc0ZENyS0dnUnlaQXVIeWRPWkJDQ0dIRHgvT3lNaUlpNHRidG15WjhKSk5telpa
clZiaFQ5UjdDWTUwVlBrSHljbkppeGN2NXFzV1Mvc1F5ZEcyZGV2V3RMUTBzOW1jazVQamRE
cjV4bERMU21pWGMrZk9UWmt5eFd3Mk94eU9xcW9xRXFBT2ljK2c4ZU1wcmw2aTEzb3Ywa05J
T2o3S0RqUHBHT29EQlNkbVYxY1hrWXdZNVpFWkhOUjdBUUFBL1lEZmtRSUFnSDZBcHdNQWdI
NkFwd01BZ0g2SVRyMlhhSzBIQUFEMGpTYS9JNFhGQjRHbUNJbTBqOEcvN2xZMmFIcXQ5MElE
emI0cnEzbWlENElVWWdweWxnWHFVRnBhU245dWh1enBoY3hXbjRDbnF3cWFJaVNCK2hoMllK
VU5tcjdydlFTSFp0K1YxVHpSQjlKOXB6KzVmSHFlT0hHQ3IrcEYrZkl3ZXJyUEI4NmhRNGV5
c3JMTVpuTldWaFovNDczRDRUaC8vandoNUljZmZuQTRITUpMekdaelhsNWVRME9EMy9YZ0hz
cmcwQlFoQ2RUSHNFT3FiTkQwWGU4bE9KUWpwcURtaVQ2UTdqdERYZXRHZkJweUhKZVRrL1BG
RjErb3d0Tjl4R1ZtWm03WnNvWC9IV2xXVmhZaFpPSENoWnMyYldJWVpzdVdMYSsrK3FyUXM3
ZTN0Nm1wS1NVbHhlOTZwSDhDTVRSRlNBTDFNZXpBS2hzMGZkZDdDUTdOdml1cmVhSVBBdTA3
VGEwYjhXbjQxbHR2OFQ5UlZxT25tMHdtb2Q2TDJXd21oR3pidHUyWlo1NlpQSG55bkRsenZ2
amlDMExJaGcwYitCOU5NUS9XZTRHbjAwTlRoQ1JRSDhNT3JMSkIwM2U5bCtDRXRPOGgxVHpS
R1Q2Rm1BaEZyUnZ4YWNpYllVaFhKcUtacDErOGVISFlzR0VmZmZTUjFXcmw2N3ZHeGNYVjFO
UzQzVzZXWlgydXQ0aFhHeHNicTc5Q25ZTUZUUkdTUUgwTTYrbktCazNmOVY2Q1E3bnZDbXFl
NkFhL2haaG9hdDM0UFEyam42ZExiNHhwYW1yS3pNdzBtVXlabVpuQ201cVJrZkhqano4S0pi
dy8rT0FEbTgxbXM5bFdyVnJGaU1vbStIeE1MVjI2bEs4SlE3bVRoc0p2RVJLZnNaTDI4VHZP
eGtIWm9PbTEzZ3NOTkNQR0gwdXlOVTkwU2FCOTk2bDE0M2ZFL0o2R1lmUjB2MUJ1REFBQVFG
akI3MGdCQUVBL3dOTUJBRUEvd05NQkFFQS9hS1BlQ3dBQUFCcndIYW5lUU9rU0JXRFFRZ1Vq
RmlvUks4UVVzcWR2WmJiNkJEeGRWYUIwaVFJd2FLR0NFUXVWaUJWaUNxT24rNzNGY3RteVpW
YXJOVDgvbnhCeStQRGhDUk1tK014UUNnWUlTcGNvQUlNV0toaXhVSWxZSWFidzV1bFNUMSt6
Wm8zTDVYcjk5ZGNKSWRuWjJlWGw1VzYzKzdQUFBvT25EeFlvWGFJQURGcW9ZTVJDSldLRm1D
THQ2ZUpLYkdheldhZ0FBMDhmTEZDNlJBRVl0RkRCaUlWS3hBb3hSZHJUeFg5bVpXWHhlWHBa
V1JrOGZiQkE2UklGWU5CQ0JTTVdLaEVyeEJRdVQvZDdZNHhQejZhbXBrY2ZmVFF1THE2a3BB
U2VQbGlnZElrQ01HaWhnaEVMbFlnVllsTEx2WXp3ZEFBQUdEaHErUjBwUEIwQUFBYU9Xandk
QUFEQXdJR25Bd0NBZm9peXAyL2F0R240OE9HeUYxNXdaUVlBQUdpSThuZWtLU2twSjA2YzhO
bUU0clVCUWxjZ29xcXFLanM3T3pZMnRxQ2c0TUNCQTN5THcrSGd2M0EvZCs1Y3BNU3FCZm82
SktXbHBlTDd1QWJ4TmdGdFFiUGpmdTk4RTBoTVRJeUlVclhBY2R5U0pVdVNrNU9EakZ0VlZW
VjZlcnJKWkVwUFQ5K3padzlSZEdLRzdPbHQ5MzFqSUFlMGVDSnBZUk9LMXdZRWdnOWpVVkZS
VzFzYngzRjc5dXdaT1hJa0lTUXhNYkdob2NIcjliSXMrOXh6ejBWS3BscWdyRU55NHNRSi9w
emsvOFN4S3V2cGdaNWF0R2pSOHVYTHc2Qkl2UlFYRitmbjU3ZTF0ZlgzOXdmcVk3UFphbXRy
T1k1ek9wMDJtNDBvT2pIRDVlbnIxcTF6T0J3bWswbjRVRHAwNkZCV1ZwYlpiTTdLeXVMbkl3
MytNUzdlcU04bUdOU05rWU5tSE54dWQyVmxKVDhaYkdKaTRyNTkrL2hESnlFaElmd0MxUVZO
TFE2TzQzSnljcjc0NGd2eDRXcXoyYXhXNjlOUFAyM01TYzlsUGQzditOeStmZHR1dC9QVHlo
dUhVYU5HZmZ2dHQ4SDc1T1hsMWRmWGU3M2V1cnE2U1pNbUVVVW5acmc4ZmZqdzRhV2xwVzF0
YlY2dmwyL0p6TXpjc21VTC82dlJyS3dzWVlYU1RmamRycytmcUJzVEhObHhFUDcvUFhic0dD
R2tvcUxpa1VjZUdUWnMyTnR2djIyMFFoeUVyaGJIVzIrOXhmKzB6MmRzcjErL1hseGNQSFhx
MUVnSVZSazBwNXQwZkZhdFd2WHl5eStIVTVjYU1abE1KU1VsVnFzMU5UVjExNjVkZnZzME56
ZmI3WGFHWWV4MmUwdExDMUYwWW9iTDA3LzU1cHRubm5sbS9QanhEejMwMEIvKzhBZCtsNFRx
TG1heldWaWhkQk4rdCt2ekorckdCSWRtSEZ3dTE0NGRPM0p5Y3NTTmpZMk5vMGVQRHBzdWxV
SlRpeU1tSmliUUJYU1B4Mk94V0NLZ1UyMVFubTdpOGVucDZVbE5UZVVOeTFEWTdYYVdaYjFl
YjBORFE2RHZFakl5TXB4T0o4ZHhMTXRtWm1hS242SS9NY043UGIydnI2K3hzZEZxdFJMcVBE
MDJObGI2YjZ6VTA4Vi9vbTZNbE9EanNIRGh3czdPVG83aktpc3JoWC9vK3Z2NzI5dmJjM056
aTR1TEk2SlJSWVJVaDhSbmJPL2R1N2RpeFlyQ3dzSXc2bE1yTktlYnovaFVWRlJNbXpZdHZM
SlV5Wnc1Y3dSUEQ1UTN4TWZITzUxT3I5ZGJXMXZMWDA4bm9aK1k0ZkowUHBlSmlZa1pPM2Jz
cDU5K1NnaHBhbXJLek13MG1VeVptWm44OVhUaTc1aFl1blJwWEZ5YzN5dnNnYjZiUXQwWU1U
UWp0blhyMXJTME5MUFpuSk9UNDNRNmhWY2xKeWN2WHJ5WTQ3Z282STRxTkxVNEJId096cUZE
aDg2Y09mUHMyYk1SMHFvT2FBNHp2K016WmNxVVFGY2U5TTI1YytlbVRKbGlOcHNkRGtkVlZS
WGY2RE5pRlJVVkRvZUR0ODNLeWtxaTZNUlVTNzJYd1VKVllnQUFJTUxvN1hlazhIUUFnSkhS
bTZjREFJQ1JnYWNEQUlCK1VMV25xL0I2UFFBQXFKbUlma2VxekozaDZTRkJVN3BFL043eHQ4
clNGS1BRTWNycXZVaXJjeGdIbW5OLzI3WnQ0OGFOczFnc2t5Wk5hbXhzSkE4ZWVKRlNHaDJr
K3k1dGtSSm9jTVJIblN3aGUvcDlTY0RUVlFWbDZSSWVvZXdHVFRFS0hhT3Mzb3UwT29mUkNI
NXV6cDA3OStUSmt4NlBaOXUyYmZ3ZDJjWTVsNlg3TG0wSmhNOG8rUngxc29UTDA2WDFYcVFm
MGUzdDdZOC8vcmpGWWhrL2ZqeGZIWkIvMW13MjUrWGxOVFEwK04xREVCeWEwaVU4NHJJYk5N
VW9kSXl5ZWkvUzZoeEdnL0xjdkhEaGdzVmk2ZTd1Wm94WElVZlk5eUF0UG9oSFZYclV5Ukl1
VDVmV2V5R1NJNkNnb09ETEw3L2tPSzYydG5iOCtQRkNlMjl2YjFOVFUwcEtpdDlYZ2VEUWxD
N2hFWmZkb0NsR29XT1UxWHVSVnVjd0dqVG41bzBiTndvTEM5OTg4MDJoeFRnVmNxVDdMbTJS
SWg3VlFGV0dnaEF1VDVmV2U1SEtNcHZOUXViT0Y5M2RzR0VEL3pNcW9TV2tuUUdFcm5RSmta
VGRvQ2xHb1dPVTFYc0pVcDNESU1pZW04ZU9IVXRMU3lzcEtlbnI2eE8zRzZGQ2puVGZBNDJH
RCtKUkRWSmxLQkRodlo0dXJ2ZENKTFZjQ2dzTHE2dXJQUjZQMEJJWEYxZFRVK04ydTFtV0ZW
YWJrcExDMXc0RU5GQ1dMdkVwdTBGVGpFTEhLS3YzNHJjNmg2RUk3akxsNWVXRmhZVkNJUkFC
STFUSWtlNTdvTkdRNG5kVW81K244NThxNG5vdlJGTEw1Y3laTXpObnp1UmIrTVlQUHZqQVpy
UFpiTFpWcTFZSjNUWnQybVMxV3BHdFUwSlp1c1NuN0liZlloVEdRVm05RjJsMUR1UEFQSWpR
R0tSUFYxY1gvOEFJRlhJQzdidTRoY2lObU05VGxKdldXNzBYQUFBd01xcit6UkVBQUlDUWdL
Y0RBSUIrZ0tjREFJQitnS2NEb0dyd2ZSVUlDWGc2QUg1UTdLU0Ric0ZCVmpnbzIySVlaczJh
TllTUWp6NzZhQ0FyWkJobTllclZBeGNtcll0Q1UxZEhlcjhHVFFtanFxcXE3T3pzMk5qWWdv
SUM4VS9aZzkvNklhME9SRlBMUmRwSHVoN3BwaFhjaHdKUEI4QVBodkwwek16TS92NytDUk1t
RE5EVE16SXk3dDI3TjBCaDByb285SFYxeE51bEtXRlVWRlRVMXRiR2NkeWVQWHRHamh4SnFW
eGFIWWltbG92ZkNqQitxd3hKTmNEVEFSZ29mczhyNXNGaVJEUkZqWUt2V1hoVmNYRnhYRnpj
aEFrVG1wdWJDU0hOemMyWm1abHhjWEhGeGNYaU5ZdTNMdDJXdElDUzN4MlI2cGsrZmZxS0ZT
dG16SmpCZHo1MDZGQldWcGJaYk03S3l1Si9JOE13ek5xMWF4TVNFdXgyKytiTm13T3RwN1Mw
OU1NUFB4UTJLbDFQZm40K0w3Nit2bDYyUW81UUY0VytybzU0Wi8yV01QSTdHbTYzdTdLeWNz
S0VDWHdIYVVVYW4xY0ZxUTRrVzh0RjNDZlFldURwQUF3K2djNGljVEVpbXFKR3dkY3MrSFZa
V1puYjdTNHZMNTg0Y1NJaEpEczd1N3k4M08xMmYvYlpaK0wrd1VzaEJTcWdKS3RuKy9idE1U
RXhPM2JzNEZlWW1abTVaY3NXdDl0ZFZsYVdsWlhGOTltd1lZUGI3YTZwcVFtVWh6SU0wOVhW
Tlc3Y3VOdTNid2RhejdwMTYrYlBuMDhJbVRkdjN2cjE2NE9vRXRkRm9hK3JJeDRReWhKRy9J
ZGlZbUtpK01mcXdTdlNCS29PUkZQTFJkd24wSHJnNlFBTVB0S3pTRnFNaUthb1VaQTE5L1Qw
Q0o3dWRyc0pJVzYzbTYrQ1lqYWIrUmFYeThYM29TbUZKQzJnRk9xZThvOU5KcE93ZGJQWnpM
ZjM5UFFFMzBHK2ZlWEtsZSsrKzI2ZzlkeThlZE5tczUwL2Y5NW1zOTI2ZFN1UUpKKzZLUFIx
ZGNUYTZFc1l1Vnl1SFR0MjVPVGtpQnVEVktUeFd4MklwcGFMVDU5QVZZYmc2UUFNUHRLenlH
OHhJaUpYMUVoS1VsSlNYVjJkeCtQWnVIR2o0T2w4UGx0ZVhwNmRuVTBJeWNuSjRmUDBzckl5
dm8vZnJjc1dVQXAxVDRQazZVRkdSdHp1Y3JuR2poMGJhRDJFa0tLaW9zY2VlMnpldkhtQjlF
anJvdERYMVJGcm95bGh0SERod3M3T1RvN2pLaXNyRXhJU2hQYmdGV21rMVlGb2FybEkrd1Nx
TWdSUEIyRHdZUjZFK0N0R3hEOFZ2S2lSbExLeU1wdk5scENRc0g3OWVwL3I2UmtaR1ljUEh5
YUVIRDU4T0NNakl5NHVidG15WllHMkx0Mld0SUFTVVhRdHFLbXBLVE16MDJReVpXWm1DdGZU
L2ZiM3U1N1ZxMWNIV2c4aHBMNitubUdZK3ZyNklIckVkSFYxMGRUVmtiNWZma3NZK1lqZnVu
VnJXbHFhMld6T3ljbHhPcDNDZW53cTB2aThTbG9kU0txWlpyOWsxK08zUlJaNE9nQlJKcVFz
RElEZ3dOTUJpREx3ZERDSXdOTUJBRUEvd05NQkFFQS93Tk1CQUVBL3dOTUJBRUEvd05PQk5x
aXVycTZwcWVudDdhMnBxYW11cnFaOFNmQm5BM1Z3dVZ3c3kvcnRIK1JWQUtnQmVEclFCdFhW
MVFjUEh2ejczLy8rdDcvOWJiQmNOZEI2amg4L0xuMEtWZzQwQVR3ZGFJUHE2dW96Wjg0NG5j
NHpaODRJOXVyem9McTZ1clcxMWVsMHRyZTNCMnIwV2FkMFEvZnUzYXV2ci9mcjZVNm5jOSsr
ZlZldVhCblVQUU5nTUlHbkEyMVFYVjE5OCtaTllTazBpaDlVVjFmZnVuWEw1WEx4dnduMDIr
aXpUdW1HdnZ2dXUzUG56dmw5cXIrLy84cVZLM1YxZFlPM1d3QU1NdkIwb0EycXE2djcrL3Yz
NzkvZjM5OHZHSzdUNlhTNVhJTExTeTFlMnVpelRyOGJDblRkdkwrLy85cTFhL0Iwb0diZzZV
QWJpQjFXZU56ZTN1NTBPbHRiV3hWNHVvOXhTNStWUHFpdXJ0NjNiOS9seTVjSGM4Y0FHRlRn
NlFBQW9CL2c2UUFBb0IvZzZRQUFvQi9nNlFBQW9CL2c2UUFBb0IvZzZRQUFvQjkrOXZUbTV1
YnRBQUFBdEE4RFF3Y0FBTjN3L3dIU0wwMUtqNEZMZ2dBQUFBQkpSVTVFcmtKZ2dnPT0iIC8+
PC9wPjxwPiZuYnNwOzwvcD48cD5UaGVyZSBpcyBhIHNsaWdodCBpbmNyZWFzZSBpbiBzbGVh
cGluZyBqb2JzIGF0IHRoZSB0aW1lIHNsb3QgaW4gcXVlc3Rpb24sIEkgZ3Vlc3Mgbm90aGlu
ZyB3ZSBjYTwvcD48cD5kaXJlY3RseSBtYXAgdG8gdGhlIGlzc3VlOjwvcD48cD4mbmJzcDs8
L3A+PHA+PGltZyBhbHQ9IiIgc3JjPSJkYXRhOmltYWdlL3BuZztiYXNlNjQsaVZCT1J3MEtH
Z29BQUFBTlNVaEVVZ0FBQWZFQUFBRnNDQUlBQUFCVHFCZTNBQUFnQUVsRVFWUjRuTzJkZjNR
VDVaNy9oeWFwYllDbVB5akxMME4vMkphMmdCZktiYXRYT1h5dGlGZGR2TjYweTdyK1dBOWUz
TE9JbGxiRXk5SERjZ0JscjdKb0xWWTlYS0VXQ21xVGxsYnh4NjJGOUtwN0xBSmlMMm1iMG9M
eXM4MlBOdTN6ejU1ei8rRDd4N1BPanZOTWttbWFaRExKKzNVK1owNzY1Sm1aOXp5WnZQdkpr
OGxudU84QkFBQkVCVmFybFZOYUF3QUFnQ0JndFZyMzc5Ly92NTVPQUFBQXFKbjkrL2ZEMHdF
QUlFcUFwd01BUVBRQVR3Y0FnT2dCbmc0QUFHcWlpVUg0TER3ZGdDRERjWnpTRWlKQ0F3Z3A0
K1BqMU0zaDZRQ0Vsa2p3MDBqUUFFS0h4K1A1N3J2dnpHYnoxYXRYbTV1YmhVL0IwMEdZNEg0
bUtTbnBvWWNldW5qeG90S0tRa1VrK0dra2FBQWhvcWVucDYydHJiT3pzNysvdjdtNStidnZ2
aE0rQzA4SFlZSjNtUXNYTHZ6elAvL3pQLzdqUHlxckozUkVncDlHZ2dZUUlvNGZQMzcxNmxW
dno4TFRRWmdRdXN5bFM1ZjBlajNmdm12WHJybHo1MDZaTW9VUTRuUTYvL1ZmLzNYNjlPblRw
MDkvNG9rbm5FNG43VFl5TXJKaHc0YTB0RFNEd2ZEeXl5L1RSby9IVTExZFBXUEdqTVRFUkpQ
SmRQMzZkZHB1c1ZqeTgvTjFPcDNSYU55N2Q2K1B4Z2x0UWY2Ujd0aXhJejA5WGEvWFAvcm9v
eTZYaXhCeSsrMjNIemh3Z08vVDA5TXphOVlzNFRzek16UHo1TW1UOVBFNzc3eERINXc4ZVRJ
ek05T0hUbS90L0dqLzlhOS9uVE5uenAvKzlLY0pIUUpRTC9CMEVDYUVubjc1OG1XaHA1dE1K
bjRxNXRsbm4xMjFhdFdGQ3hjR0J3ZnZ2dnZ1eXNwSzJyNXAwNmF5c3JLK3ZyNHJWNjQ4L2ZU
VHRQR2xsMTY2NjY2Nyt2cjZybCsvL3NnamovemhEMytnN1dscGFZY09IWEs1WEQwOVBZOC8v
cmlQeGdsdFFmNlIwa080Y09IQ3FsV3JObTdjU0FocGFXbkp5OHNiR3h1amZSNS8vUEh0Mjdj
TDExcTNidDNycjc5T0NPbnI2NXMyYlJwMTV6MTc5anoxMUZNK2RIcHJwNlBkMU5RMFk4YU1E
ejc0WUVMNlFZU0Q2MTVBUk1CNytzV0xGeDk1NUpINzc3K2ZiKy92NytlN3paNDkrK3pacy9U
eDk5OS9QMmZPSFBwNDd0eTU3Q2xxTkJyUG5EbERIdzhPRHM2Y09aTStuamR2M3U3ZHUvdjYr
b1NkSlJzbnRBWDVSL3JERHovUXgyZlBucDA3ZHk1OVhGUlU5TjU3Ny9HTnc4UER3clUrL1BC
RGs4bEVDTm0rZmZ1TUdUUG9oNFBmLy83M0gzMzBrUStkM3RvNWp2dXYvL3F2MmJOblc2M1dB
QTRCUkQ2NDdnVW9EUDhkNmZUcDB4OTg4TUhCd1VHK1hkaE5vOUY0UEI3NmVIUjBWS3ZWOHUy
am82T2liV3ExV2s0QW5iMGhoRml0MXQvKzlyZXBxYWtaR1JuVUU3MDFUbWdMa29jaitaVGtJ
WHp3d1FjNU9Ua2VqNmVpb3VLMTExNFRyVFUwTkhUenpUY1RRZ29MQzgxbWMwbEpDU0hrNXB0
dnB0YnZUYWUzZG83ak1qSXlubnZ1T1ZZZWlBSnczUXRRSG0vZjJvbmFaOCtlelNlNTMzLy8v
ZXpacytsanlUeDkzcng1ZHJ2ZDJ4N0h4OGZOWnZNLy9NTS8rR2dNWUF0K0VlYnBQL3p3QS85
UlkzeDh2TEN3c0xLeTBtZzB1dDF1ZHNVNzc3enovZmZmTHlvcUlvUVVGUlY5OE1FSHk1Y3Y5
NjNUV3p2SGNYMTlmVmxaV1R0MzdweVFlQkQ1NExvWEVCSEk5UFFOR3pid2s5RXJWNjU4NXBs
bmFQdnp6ei9QenFmL3gzLzh4NnBWcTdxN3UwZEhSNy85OWxzNmQwRUlLUzh2Lys2Nzc5eHV0
OWxzVGt0TDg5RTRvUzNJUDlMZi92YTNGeTlldkhqeDRyMzMzc3QvSlVBSXFhK3Y1emp1cmJm
ZWtseHgrL2J0YytiTW9TbjhxNisrT25mdTNCMDdkdmpXNmEyZGptcC9mMzlPVHM2MmJkc21w
QjlFT0xqdUJVUUVNajNkNFhBODl0aGowNlpObXpadDJtT1BQZVp3T0dqN3lNakkrdlhyVTFK
U2twT1RkKzNhUlJ2SHhzYTJiZHRtTkJwMU9sMUJRVUY5ZlQxdFAzRGdRRTVPamxhcnpjL1Bi
MmxwOGRFNG9TM0lQMUwrdXBkSEhubUV2M1NIRUhMdzRNSHM3R3gyRW9ueXpUZmZhTFZhK25Y
eGhRc1h0RnJ0Zi8vM2Yvdlc2YTJkSDlXQmdZRzh2THlYWG5wcFFvY0ExQXM4SFlEd2NkOTk5
KzNmdjE5cEZVRGQ0TG9YQUpSbmJHeXN0cloyd1lJRi9PV01BQVNHeU1UaDZRQW9BTWR4UnFN
UlZ4YUN5ZFBjM0R3eU1rSWZqNHlNNExvWEFBQlFNVmFyOWVUSms2T2pvNk9qb3lkUG51enM3
QlErQzA4SEFBQTE0WFE2VDV3NFliRllMQmFMMVdvVmZnbFA0T2tBQUtCcU1KOE9BQURSQXp3
ZEFBQlVUQXhkeTloOTdGajNzV05LcXdBQWdQQVJ0WjQrNm5MdHVlMjJQYmZkTnVweUthMEZB
QURDUk5SNitsLys5S2R0UnVNMm8vRXZLUDhQQUloVm9zVFRyL2IxN2N6Sm9aNitNeWZuYWtC
bHJ3RUFJUEp4T0J4V3E1Vy9scEd2aVVTSlhFOXZiR3pNek16VWFEUVpHUm1OalkyRUVMdmRY
bHBhR2g4ZlgxcGFLcW92MnZEWVk5VFFhVFE4OXBoQ3FnRUFJTFMwdDdlZk9YTm1aR1JrWkdU
azlPblQ3ZTN0d21jajE5T1RrcElzRm92TDVUS2J6UWFEZ1JCU1hsNWVYVjN0ZERxcnE2c3JL
aXJZVlRadjNrd0lFZDQweHdjanAwNzU3U056VTNLNlFaWDhibEFsdnh0VXllOFdtYW9Dd0d3
MjgxV0R4c2JHekdhejhObkk5ZlNGQ3hkYUxCWmF3SHJ4NHNXRWtMUzBOSHB6bk1IQlFjbVMx
dFRUdi9ycUt6bmJ2eWJqeHNFeU55V25HMVRKN3daVjhydEJsZnh1a2FrcUFOU2FwNTg0Y1NJ
cEtZbmp1S1NrcEJNblRoQkM0dUxpNkg4bmo4ZWowV2lFblQwLy9YU3RwbWJUdW5Ya3hJbi8r
Wi8vSVNkTzNMaHh3L2ZTMDlibXQ4OW9lN3ZmUGpMM0NGVlFCVlZRSlZ6KzNlVzZWbFBqN3Vx
YXFEY09EdytyY2o0OU96dWJuM3U1NVpaYkNDR3BxYWwrOC9RYk4yNE1EQXpja0FIcDdQVGJS
K2FtNUhTREt2bmRvRXArTjZpUzN5MENWWVhDT1NQWDA1T1RrL201bDVTVUZFS0l5V1RpNTlQ
NWUzUUpvWjRPQUFDcUlEQnZWT3QxTHcwTkRVYWpVYVBSeko4Ly85Q2hRNFNRM3Q3ZTR1Smlu
VTVYVWxMU0ozVzFJdkwwaVhhREt2bmRvRXArTjZpUzJTMHdiMVRyZkhvQUlFOW5zVnF0VnF0
VmFSVUFBQWtDTXpxMVh2Y1NBTWpUMlc2K1BSMWpKYjhiVk1udkJsVXl1d1ZtZE1qVFl4ZnJ6
eWd0QklBSUpldEdGZzFGOWg2WTBhbjF1cGNBUUo0dTZtYTFXck51WkNGUEQwcTNNS3V5V3Ey
dHJhMSs3Y2JIcG9UL3pxTjdyR1IyWS90WUJTaWlLaFEyR0lXZURuaXNWaXVYZFFONXVocVJ0
SnZBdGhCY1laSjdDZWt1UWdkTmVuem5QU0VsTUtPTG9mcnB5Tk5GM2Z4Nk9zWktmamRoSHg5
MktVZFZhMnVyWHhPeFdxMEx5d2FvM1FUMkNnby9wUVgzMDRPb2haVVgrYS9nRFY1NUl5ZDZq
MFIrbmk0eWNSRlI2T21BaC9mMGdOTVFwZVlaSXhrNm5uN2QxdThXL0hiZ3NtNndqak9odlFU
M1U1cmtJY3RwRWM0Z0tUaDVMWUsraUZ6V2pVbStSeVpEWUVZWEU1NCtNakppczluV3JsMTc0
OGFOYjc3NTVzYU5HNE9EZzc2WHBMUFRiNStCZ1FHL2ZXVHVVUkZWVnF1MXNHeVF5N3BCYzZ1
SnFxTHBaT3lNbGJkUm91Tnc1TWdSMnNkcXRaWU5sbVhkeUJyY1g4aTMwTGx2bWFwYVcxdTk3
WXZmWTlhTnJQdis1UnN1NjBaaDJTQjlGZWl6d2ozeXF2aDJxb0h2U2RkdGJXMDkrYzQ3L0tz
Wm1DclJIb1VhaEV2YWsvWXBHeXp6M1hPU1kxVTJXQmJ3ZVVXMWxRMlcwUkVXdmtmQ2RyYmI3
WGFielJaQW5hK1k4SFFLOG5RaGZLNDNtVVJQdlZPbDN2QjJVRllCYkR0L2RRUWZkR0Q1UDMx
dlZxWUdZUWQrRjZLWGp4VmovU1hDWGRCTVg5Z3pnSkVSRFFLZjFmS05vaGFyNEVPTTVOQk5h
UDU2UWdNN29XM3k3NDdKdkVjbVNTaHNNQW85blovRHNucmhmMGN6a3VhSWVXRkJ2MnBDK05H
U2ZSdklVV1cxV2srKzg0N2ZNMTR0MXlkSW5oSTBjNVMwU0w2ZHptNExYWUFQZm9hRUh5dmYw
TjM1aHN1NnNiQnNnSDM1ckQ4N0VSVkQrL3p2aEVZako1TE45eVM3NXJIYm1aQXFmbXNMeXdi
WWR1Ri9EanBXdkNwK2ZJUkx1bTZ3eGtwbU43YVBwS2RIL255NmI2TFEwNFh2WHNrRXdScGh1
YWZ3SkF2aU5rVUdGTUQzKy9Ta1YvYkNnQnUvVEJJbkwwUHlyT0RkaDEreUtUbnZSOTQ4WGVS
cnZvUGRpN2VkaWo0UWVQdS93dmFVVkJ1d0t0SFdoTU1sYkJFK3VOSEllUnN4djBwRXV3NXNE
UDBlcWNqVDVaOWR3WHEzQnVCeW4zenlTVmRYMStEZ29NZmprZXdRYlo0dSttOHMrWExTcHlh
YUkyUjUvMkpuTW5tNnlMQmtxdkloaHQ5czJVQ1pYMCtYdkJKQUNGM3hENTFML1o3QkF3TURm
bFh4ZS9UOWxtQlZpVjQ3dXFQQXJqQ3hDdjVSOFZFMlVDYXlKOVpEK2F6WnQ1LytvWE9wWCt1
aEw0MWYweEh1a2RYalRaVmt0OVZMTy8wNnFmQ0VrZFFqM0tPa0xmcFFKWE9zdktsaTIrbC9D
OUVyNkhkVFdWTC9oSVMySHZCNUpUckg2RmthaWp6OTJyVnIzZDNkSFIwZHpjM05IUjBkM2Qz
ZDE2NWRFM2FJTmsrWFBCSFpGR09pRWF4L3krd0x6eHNXVFdxQ0pjYjZ5OCtWM0M4LzgvcldJ
L1JRK1ZrTTMwR21QQjQ1UFlPWVR3bTM1czJTZ2hJK1VsUkVaQTcxWk00cjlsazVXNXVNM1ky
T2pnNE9EbloxZFgzeXlTZkM5aWowZE9GL2JHOHZudndjUWVpa1dWNisrWkdmSTRpc21kVXBV
NVhWK3dRQ3YzRnZ1Wkp3WGZZQUpmOHAwaXpQOTA3NUtXbkpJUktKWi9FOTdLTFhqalpLanBW
b2EreUhOdmEvSFNjdnI1VFRoeE5reEQ2TVJ1YW1RcUZxOHB1S1lsVSt6aXZKczkzYmVjNi9F
WHc3d3lROTNSdlI1dWx5WG40ZmtlVWx0ZWV5ZnBGV1M3cFNBSWdNWFg3STJYZ0E2d3FQM2Nj
SXlEbXVTWFlRZFE1WWlmWG5tUlpSQ3dMQnhpVFBLOUd6dmxjL2N2Skl6SGs2SnlBMU5aVVFZ
cmZiUzB0TDQrUGpTMHRMN1hZN3V3cjE5TW5rQ0NJakUyMHE2K2RKRXI4NXVHUitLcGtGaS9Z
b1AzUHh1MGNmNCtCTmxkK3g4bjJBZkFjZlBZVnptbnhQMFpES1VTVXpuNUtjamZVMnBIS0dQ
YkR6S3JCTlFWWDRWVTNtdkdMUE1lVHAwblIwZER6Ly9QT0VrUEx5Y3Y0K1J4VVZGV3pQeWVm
cGZrTmt3WkxmN0xONXJtVG1HOXo1Vm0vSnRad0Q4WDE5Z3N3dHlGK0w3K3pqdjRqZjhMYXV0
NkhHN0RaQ1p2QkpCajF0Sk04Y21lOWwwZXFpa3pOWW5xNitlaStyVnEwNmYvNDhJU1F0TFcz
UTMvMUlPVFhuQ0ZBRlZWQVZPNnBpMU5QYjI5c2ZmdmhoK2pndUxvN2UzY1BqOFdnMEdtRTN6
MDgvWGF1cDJiUnUzZStXbnVDeWJtQ0pKWlpZUnZqeTd5N1h0Wm9hZDFmWFJGMVIzWFVaVjZ4
WThmWFhYOVBIcWFtcHlOT2hDcXFnS2pwVXhXS2Uvdm5ubjk5eHh4MzhueWFUaVo5UE41bE1i
UDh3ektjakVBaEVVQ0lXUGYzT08rODhjdVFJLzJkdmIyOXhjYkZPcHlzcEtlbnI2MlA3STAr
SEtxaUNLcldvVXVhNmw5cmEyc2NmZjV3UVVsNWVQbjM2OUVPSERvVkNSTEJBbm81QUlOUVNB
WHU2dytHd0Judy9VcVBSMk5QVDA5TFNjdHR0dDMzNTVaZTV1Ym1CaVFnUHlOT2hDcXFnU2ky
cUF2YjA5dmIyTTJmT2pJeU1qSXlNbkQ1OXVyMjlYZmlzSDAvWGFEUWpJeVByMXExNzlkVlhS
MGRIdFZwdFlDTENBL0owQkFLaGxnalkwODFtTTcwQ2tCQXlOalptTnB1Rnovcng5T3pzN0Mr
KytHTEpraVhkM2QwMm0rM21tMjhPVEVSNFFKNE9WVkFGVldwUnBVeWVmdURBZ2VuVHB6Lzc3
TE9Fa0NlZWVLSzJ0all3RWVFQmVUb0NnVkJMQk96cHc4UERnYytucXd2azZWQUZWVkNsRmxX
eFcrOUZQc2pURVFpRVdpSmdUNS9VNzBqYjI5dHpjbkttVEpsQ0NGbXpaazE5ZlgxZ0lrTE55
TWlJeldaYnUzWXRsM1dEdjl1NjcrWHFwWjErK3l3c0cvRGJSK1llb1FxcW9BcXFoRXU3M1c2
ejJmcjcreWRxZDlURWVTdWZtS2ZmY3NzdExTMHRITWNSUW5wN2UrZlBueCtJNDRZTDVPa0lC
RUl0RVhDZWJyRllybCsvYmphYnIxMjdkdTNhdFphV0Z1R3pmanhkcDlPNVhDN3E2WmN1WGRM
cjlZR0pDQStZVDRjcXFJSXF0YWdLMk5OUG5qelozTnpjMDlQenlTZWZXQ3lXYytmT0NaLzE0
K2tyVnF4NDU1MTNPSTdyNys5ZnMyYk42dFdyQXhNUkhwQ25JeEFJdFlReTM1SDI5L2MvOE1B
RGVyMWVyOWV2WHIzNnh4OS9ESVdJWUlFOEhhcWdDcXJVb2txWjcwalZCZkowQkFLaGxzQzFq
UDVCbmc1VlVBVlZhbEdGdW96K1FaNk9RQ0RVRXNwNHVvSjFHY2ZHeHJaczJUSjc5dXdwVTZi
UUMyL3NkbnRwYVdsOGZIeHBhYW5kYm1kWFFaNE9WVkFGVldwUnBZeW5LMWlYY2V2V3JibTV1
VjFkWGVQajQ3U2x2THljdjg5UlJVVUZ1d3J5ZEFRQ29aWlFwbjY2Z25VWmpVYWpxSVprV2xv
YTdrY0tWVkFGVmRHaEt1YnFNbW8wbXFlZmZqb3hNZEZvTkg3d3dRZUVrTGk0T0ZvMTJPUHhh
RFFhWVdmUFR6OWRxNm5adEc2ZDR2Y0N4eEpMTExHVXMveTd5M1d0cHNiZDFUVlJiNXhVL1hR
RlNVdExNNXZOTHBmTGJEYlBtREdERUpLYW1vbzhIYXFnQ3FxaVE1VXllYnFDVkZSVW1NMW10
OXR0TnB2VDA5TUpJU2FUaVo5UE41bE03Q3FZVDBjZ0VHb0paZXFuSzNndFkzOS8veDEzM0tI
VDZUSXpNK21IaTk3ZTN1TGlZcDFPVjFKUzB0Zlh4NjZDUEIycW9BcXExS0lxNXE1bERBRGs2
UWdFUWkyaFRHMEFOZDVqT3RMK0cwOW9VMUFGVlZBVkk2b200K2trNFBycGFyekhOQUtCUUVS
K0tPUHBhcnpIZEtUOU41N1FwcUFLcXFBcVJsUXA0K25xQW5rNkFvRlFTd1RyTzlMbzkvUkkr
Mjg4b1UxQkZWUkJWWXlvVXNiVDFYS1BhUXJ5ZEFRQ29aWlE1cm9YdGR4amVtUmt4R2F6clYy
N2xvdTh1NE5INWozTG9RcXFvRXBaVlhhNzNXYXo5ZmYzVDlMOUp1YnBhcnpITkFLQlFFUitL
RFAzb3NaN1RFZmFyTm1FTmdWVlVBVlZNYUlLOTVqMkQvSjBCQUtobHNBOXB2MkRQQjJxb0Fx
cTFLSUs5NWoyRC9KMEJBS2hsbEFtVDZmZmpucjdNOUpBbmc1VlVBVlZhbEUxbVR6ZDdYWi8v
dm5uemMzTkZ5OWVGRDNsdjRhWDIrM210eElYRnhld2lEQ0FQQjJCUUtnbEF2WjBhdWhuenB5
NWZQbnkwYU5IcjE2OUtueldqNmNYRnhjLzk5eHpseTlmdm56NWNsVlYxYTkvL2V2QVJBUUFK
NEMyMk8zMjB0TFMrUGo0MHRKU3U5M09yb0k4SGFxZ0NxclVvaXBnVC8vc3M4OTR1ejUvL254
Ylc1dndXVCtlZnU3Y3VaVXJWeVltSnVyMStudnV1Y2Rtc3dVbUlnRFllWjd5OG5MK1BrY1ZG
UlhzS3NqVEVRaUVXaUpnVHhkNTlibHo1NFIvUnU1M3BCekhUWjgrWGEvWHIxcTFpdjR2U1V0
THcvMUlvUXFxb0NvNlZNWG90WXdYTGx5b3JLd3NMaTRtaE1URnhkRzdaWHM4SG8xR0krem0r
ZW1uYXpVMW05YXRVL3hlNEZoaWlTV1djcFovZDdtdTFkUzR1N29tNm9xVHFyWDd0Ny85YmVY
S2xmUTNSeXRYcmhRbCtlSEI0WERvZERwQ1NHcHFLdkowcUlJcXFJb09WY3JVVDErMmJObm16
WnZwZDZTYk5tMWF0bXhaWUNJQzVzcVZLNXMzYnk0cUtpS0VtRXdtZmo3ZFpES3huVEdmamtB
ZzFCTEtlTHBXcTNXNVhQU3gwK21rK1hKNG9GZThKQ1FrckZpeDR1elpzNFNRM3Q3ZTR1Smlu
VTVYVWxMUzE5Zkhyb0k4SGFxZ0NxclVva3FaMzVFV0ZSVnQzcno1eXBVclY2NWMyYkpsQzgy
WEl4Yms2UWdFUWkyaHpIZWtQL3p3UTFsWldXSmlZbUppWWxsWldYZDNkMkFpd2dQeWRLaUNL
cWhTaTZwSjV1bmo0K09pU1JoS3BGLzNNaUdRcHlNUUNMWEVaRHpkNC9GODk5MTNaclA1NnRX
cnpjM053cWY4ZURxOWE1MWFRSjRPVlZBRlZXcFJGYkNuOS9UMHRMVzFkWFoyOXZmM056YzNm
L2ZkZDhKbi9YajZuRGx6MkJveEVRdnlkQVFDb1pZSTJOT1BIejh1cXZFaXhJK243OXExNjhr
bm54d2FHZ3BzMzJFR2VUcFVRUlZVcVVXVk10ZTljQXloRUJFc2tLY2pFQWkxQk82SjRZdVJr
UkdiemJaMjdWb3U4dTRPSHBuM0xJY3FxSUlxWlZYWjdYYWJ6ZGJmM3g5Y000d1NUNmNnVDBj
Z0VHb0paZkwwNzcvLy91Njc3NmIxWHU2KysyNzZlODZJQmZQcFVBVlZVS1VXVmNwNGVrRkJ3
UXN2dkVCL1I3cDU4K2JDd3NKUWlBZ1d5Tk1SQ0lSYVFobFAxK3Yxd25vdmVyMCtGQ0tDQmZK
MHFJSXFxRktMS21VOHZhcXFhc3VXTFh5OWw2cXFxbENJQ0JiSTB4RUloRm9pVXE1bGpPUXJH
cEduUXhWVVFaVmFWT0ZhUnY4Z1QwY2dFR3FKR1BYMExWdTI4QjhMN0haN2FXbHBmSHg4YVdt
cDNXNW5PeU5QaHlxb2dpcTFxSXBGVCsvczdKdzFheGJ2NmVYbDVmeDlqaW9xS3RqK3lOTVJD
SVJhSXVZODNlbDBGaFlXSGp0MmpQZjB0TFEwM0k4VXFxQUtxcUpEVmN4NSt2cjE2M2Z0MmtV
STRUMDlMaTV1Ykd5TUVPTHhlRFFhamJDejU2ZWZydFhVYkZxM1R2RjdnV09KSlpaWXlsbisz
ZVc2VmxQajd1b0tybk5LZXpwdm93cGU0akpseWhUUmxUYXBxYW5JMDZFS3FxQXFPbFNGTlUr
Zk1XTkdSMGZIK1BoNEpGeTJ5R3N3bVV6OGZMckpaR0o3WWo0ZGdVQ29KY0xxNlgvKzg1L256
cDByeXBTVnVqS2QzMmx2YjI5eGNiRk9weXNwS2VucjYyTjdJaytIS3FpQ0tyV29VdXczUjZI
WWE0aEFubzVBSU5RU01mY2RhUUFnVDRjcXFJSXF0YWhTeHRQLzlyZS9yVnk1a3RiYVhibHk1
Ymx6NTBJaElsZ2dUMGNnRUdvSlpUeDkyYkpsbXpkdnZuejU4dVhMbHpkdDJyUnMyYkpRaUFn
V3lOT2hDcXFnU2kycWxQRjByVllyckxXcjArbENJU0pZSUU5SElCQnFDV1U4dmFpb2FQUG16
WHl0M2FLaW9sQ0lDQmJJMDZFS3FxQktMYXFVOGZRZmZ2aWhyS3dzTVRFeE1UR3hyS3lzdTdz
N0ZDSW1qL0FlMDNMdS9Zb2xsbGhpcWV3Uzk1ajJEL0owcUlJcXFGS0xLbHpMNkIvTXB5TVFD
TFVFUE4wL3lOT2hDcXFnU2kycTRPbitRWjZPUUNEVUV2QjAveUJQaHlxb2dpcTFxRkxHMDZk
TW1SS0t2WVlJNU9rSUJFSXRvWXluejVrejUrTEZpNkhZY1NoQW5nNVZVQVZWYWxHbGpLZnYy
clhyeVNlZkhCb2FDc1crZlZOZlg1K1RrNlBUNlJZdFd0VFcxa1prMzJNYWdVQWdJajhVcTdX
clZQMzBoeDkrMkdhek9SeU85OTkvUHpVMWxjaSt4M1NrL1RlZTBLYWdDcXFnS2taVXhlaDNw
QzZYNjlDaFF3c1hMaVN5N3pHTlFDQVFrUit4Nk9uMGswRnljdkx4NDhlSjdIdE1MeXdia0hP
UDErMTN2TzIzejRaVkgvcnRJM09QVUFWVlVBVlZ3bVZZN3pITjA5N2VucE9UUTY5K1diTm1U
WDE5ZlhCMzd4YzY5NUtWbFVWazMyTWFnVUFnSWorVXlkTnZ1ZVdXbHBZV09vM2UyOXM3Zi83
OFVJaVFaUDM2OVJjdlhuUTRIQWNQSHB3NWN5YVJmWS9wU0pzMW05Q21vQXFxb0NwR1ZDbmo2
VHFkenVWeVVVKy9kT21TWHE4UGhRaEo2dXJxWnMrZUhSOGZ2M1RwMGs4Ly9aVEl2c2MwQW9G
QVJING80K2tyVnF4NDU1MTNPSTdyNys5ZnMyYk42dFdyUXlFaVdDQlBoeXFvZ2lxMXFGTEcw
L3Y3K3g5NDRBRjZQOUxWcTFmLytPT1BvUkFSTEpDbkl4QUl0VVFzWHZjeVVaQ25ReFZVUVpW
YVZNSFQvWU04SFlGQXFDV1U4ZlR2di8vKzdydnZwbk12ZDk5OTk5bXpaME1oSWxnZ1Q0Y3Fx
SUlxdGFoU3h0TUxDZ3BlZU9FRmVvL3B6WnMzRnhZV2hrSkVzRUNlamtBZzFCTEtlTHBlcjNl
NVhQU3gwK2tNNTdXTUFZQThIYXFnQ3FyVW9rb1pUNitxcXRxeVpRdk4wN2RzMlZKVlZSVUtF
Wk5uWkdURVpyT3RYYnVXVS9wZTRGaGlpU1dXY3BaMnU5MW1zL1gzOXdmWERLVTluUzNIR1A2
NmpBR0FQQjJxb0FxcTFLSUsxNzM0Qi9QcENBUkNMUUZQOXcveWRLaUNLcWhTaXlwbFBQM3c0
Y05HbzNIS2xDa3FtbnRCSUJDSXlBOWxQRDB0TGUzZ3dZTWVqeWNVK3c0NnlOT2hDcXFnU2ky
cWxQSDA1T1RrNGVIaFVPdzRGQ0JQUnlBUWFnbGxQUDNGRjEvY3NtV0wwK2tNeGI2RER2SjBx
SUlxcUZLTEttVTh2Ykd4OGFhYmJsTGtXc2FHaG9ZRkN4Ym9kTHBGaXhhMXRiVVJRdXgyZTJs
cGFYeDhmR2xwcWQxdVoxZEJubzVBSU5RU3luaDZlbnA2WTJPakl2UHBEejMwVUZkWGw5UHAz
THQzTDcxVFhYbDVPWCtmbzRxS0NuWVY1T2xRQlZWUXBSWlZ5bmg2VWxLUzR2UHBOcHZOYURR
U1F0TFMwbkEvVWdRQ0VSMFJvL1BwQXdNRFM1WXMrZkRERHdraGNYRnhZMk5qaEJDUHg2UFJh
SVRkUEQvOWRLMm1adE82ZFJGNGQzRDVmYUFLcXFBcWRsVDkzZVc2VmxQajd1b0tybWY2OFhS
bGF3TllyVmFqMGJodjN6NzZaMnBxS3ZKMEJBSVJIUkZ6dnlPdHJhMU5UMDgvZXZRbzMySXlt
Zmo1ZEpQSnhLNkMrWFNvZ2lxb1VvdXFtUE4wMGVlRG9hR2gzdDdlNHVKaW5VNVhVbExTMTlm
SHJvSThIWUZBcUNXVThYVFVaWlN6S1RYbUNGQUZWVkNsckNxRjgzU0h3L0hDQ3k5czNibzFG
Q0tDQmZKMEJBS2hsbEIrN21Wb2FDZ3BLU2tVSW9JRjhuU29naXFvVW9zcWhUM2Q0L0hVMTll
bnA2ZUhRa1N3UUo2T1FDRFVFZ3JQcDArWk1zVm9OQjQrZkRnVUlvSUY4blNvZ2lxb1Vvc3E1
ZWRlSWgvazZRZ0VRaTBCVC9jUDhuU29naXFvVW91cWNIdTZ1dTR4UFRJeVlyUFoxcTVkeXls
OUwzQXNzY1FTU3psTHU5MXVzOW42Ky91RGE0YXk4dlN4c2JGMzNubm41cHR2WHIxNmRYQjNI
MXlRcDBNVlZFR1ZXbFFwTnZmUzFOUlVVRkR3bTkvODV2ang0NkZRRUVRd240NUFJTlFTQ25q
NmlSTW5mdk9iM3hRVUZEUTFOWVZpMzBFSGVUcFVRUlZVcVVWVnVEMTk5ZXJWTjk5ODg5dHZ2
MDNMMjZvQzVPa0lCRUl0Z2U5SS9ZTThIYXFnQ3FyVW9nclhNdm9IZVRvQ2dWQkx3TlA5Z3p3
ZHFxQUtxdFNpS3VZOG5aM3RzZHZ0cGFXbDhmSHhwYVdsZHJ1ZFhRVjVPZ0tCVUV2RW5LZFRo
SjVlWGw3TzMrZW9vcUtDN1l3OEhhcWdDcXJVb2dxZVR0TFMwbkEvVWdRQ0VSMEJUeWR4Y1hI
MHdrcVB4NlBSYUlUZFBELzlkSzJtWnRPNmRSRjRkM0Q1ZmFBS3FxQXFkbFQ5M2VXNlZsUGo3
dW9Lcm1lcXlkTlRVMU9ScHlNUWlPZ0k1T25FWkRMeDgra21rNG50alBsMHFJSXFxRktMcXBq
emRQYTNUcjI5dmNYRnhUcWRycVNrcEsrdmoxMEZlVG9DZ1ZCTHhKeW5Cd0R5ZEtpQ0txaFNp
eXA0dW4rUXB5TVFDTFVFUE4wL3lOT2hDcXFnU2kycTRPbitRWjZPUUNEVUV2QjAveUJQaHlx
b2dpcTFxSUtuK3dkNU9nS0JVRXZBMC8yRFBCMnFvQXFxMUtJS251NkxrWkVSbTgyMmR1MWFU
dWw3Z1dPSkpaWll5bG5hN1hhYnpkYmYzeDljTTR3U1Q2Y2dUNGNxcUlJcXRhaENudTRmektj
akVBaTFCRHpkUDhqVG9RcXFvRW90cXVEcC9rR2Vqa0FnMUJMd2RQOGdUNGNxcUlJcXRhaUNw
L3NIZVRvQ2dWQkx3TlA5Z3p3ZHFxQUtxdFNpQ3A1TzdIWjdhV2xwZkh4OGFXbXAzVzVuT3lC
UFJ5QVFhZ25lMHhzZWYveEtiMit3ZkZKTm5sNWVYczdmNTZpaW9vTHRnRHdkcXFBS3F0U2lp
dmYwYlVianp0emN2L3pwVDZOTzUrUjlVazJlbnBhV2h2dVJJaENJNkFpaHA5TjQvVGUvK2VH
VFR5YnBrMnJ5OUxpNHVMR3hNVUtJeCtQUmFEUzA4ZlRwMDg4OTkxejFoZzNQUHZEQS83djk5
bzJQUFBMRUUwOXNmT1NSNTU1N3p2ZnltWHZ1OGR2bkR3OCs2TGVQekQxQ0ZWUkJGVlFKbDlT
MXF0YXUvVDlQdi8zMkh6NytlSkkrcVNaUFQwMU45WnVuRTBMT25Uc25aMnZPTDc3dzIwZm1w
dVIwZ3lyNTNhQktmamVva3Q4dE1sV1JuK2RldnZqUC80eTV1UmVUeWNUUHA1dE1KcllEOVhT
MzJ5MW5hOWYyN3ZYYlIrYW01SFNES3ZuZG9FcCtONmlTM3kweVZSRkNHaDU3N0VwUGo1eWVj
bENUcC9mMjloWVhGK3QwdXBLU2tyNitQcllEOVhTWmVDNWVESjYwb0FGVjhvRXErVUNWZkNK
VGxYelU1Ty9QQ0E0QUFCNkZTVVJCVk9sKzZlcnFVbG9DQUFBb1NWUjVPZ0FBeERqdzlBQnBh
R2hZc0dDQlRxZGJ0R2hSVzFzYklZVDdtWWhTeGJaRWdxcjYrdnFjbkp4SVUwWFpzbVdMZ2kr
aWovTXFvbFNOalkxdDJiSmw5dXpaVTZaTVVVcVk3N0ZLVFUyTkVGV05qWTJabVprYWpTWWpJ
Nk94c1RIVUF1RHBBZkxRUXc5MWRYVTVuYzY5ZS9jS0w4SlIxdE5aVmQ1MEtxdnE0WWNmdHRs
c0RvZmovZmZmVitxOUp6a3luWjJkczJiTlV2QkZaRlVwZTBaUldGVmJ0MjdOemMzdDZ1b2FI
eCtQSEZVOEhSMGR6ei8vZklTb1NrcEtzbGdzTHBmTGJEWWJESVpRQzRDblR4YWJ6V1kwR3Zr
L0krRWRTQmhWa2kzaFI2VEI1WElkT25SbzRjS0ZDa29pQWxWT3A3T3dzUERZc1dPUjhDTHlx
amlPbXo1OXVsNnZYN1ZxbGMxbWl4QlZScVBSYkRZcks0YUhQYmRYclZwMS92eDVwZlJRZUZV
TEZ5NjBXQ3h1dDl0c05pOWV2RGpVKzRXblQ0cUJnWUVsUzVaOCtPR0hmRXNrMkFHcmltMVJY
Qlg5Z0p5Y25IejgrUEVJVWJWKy9mcGR1M2FSQ0hnUjJkZnJ3b1VMbFpXVnhjWEZFYUpLbzlF
OC9mVFRpWW1KUnFQeGd3OCtpQkJWbFBiMjlvY2ZmbGhCU2VTWHFrNmNPSkdVbE1SeFhGSlMw
b2tUSjBLOWEzaDY0Rml0VnFQUnVHL2ZQbUdqNG5iQXFwTFVxYmdxUWdpZGU4bkt5b29RVlhS
cVdQSEphMit2bDhQaDBPbDBpa2dpaktxMHREU3oyVXpuRTJiTW1CRWhxaWdyVnF6NCt1dXZs
WkpFR0ZYWjJkbjgzTXN0dDl3UzZyM0Qwd09rdHJZMlBUMzk2Tkdqb25abFBaMVY1VTJuc3Fy
V3IxOS84ZUpGaDhOeDhPREJtVE5uUm9ncUhnVmZSRytxcmx5NXNubno1cUtpSWlWRVNhaXFx
S2d3bTgxMFBpRTlQVDFDVkJGQ1B2Lzg4enZ1dUVNUlBSUldWWEp5TWovM2twS1NFbW9COFBR
QTRYN0owTkNRcUNVeVZRME5EVVdDcXJxNnV0bXpaOGZIeHk5ZHV2VFRUejhOdnlSSlZjS25G
SkVrcVlvK1NFaElXTEZpeGRtelp5TkVWWDkvL3gxMzNLSFQ2VEl6TTVXYVdKZDhCZSs4ODg0
alI0NG9vc2VicW9hR0JxUFJxTkZvNXMrZmYralFvVkFMZ0tjREFFRDBBRThIQUlEb0FaNE9B
QURSQXp3ZEFBQ2lCM2c2QUFCRUQvQjBBQUNJSHVEcEFBQVFQY0RUQVpnVUNsN01EZ0FMUEIx
STQzYTdOMnpZTUdQR2pHblRwbTNmdmwxcE9jckRjZHdycjd4Q0NIbjU1WmZoNDRTUXJxNHVq
dU53SXhvU1llY0dQQjFJVTFWVjljQURENXcvZi83S2xTdlBQUE9NMG5LVWgrTzR2THk4OGZI
eDNOeGN4ZCsza2NET25Udmo0dUoyN3R5cHRCRGxpYWh6QTU0T3BKa3paNDdvcnVmQ2s1Vi96
SEZjVlZXVlhxL25pNGdxZms2SENJN2picnZ0dHExYnQ5NSsrKzNDd3hjTnk2dXZ2cHFTa3BL
Y25MejM1MXNWUit1QXJGaXg0dkhISDEreFlnWDljL0hpeGZRV0VLMnRyYmZlZWlzaHBMT3pN
eTh2THlFaG9icTZXamhpU2drT0hleTVRVThNclZiTDN4bGozYnAxLy9Jdi8wSUllZmpoaDU5
NjZpbCt4YUNMZ2FjRGFUUWFqY2ZqRWJaNDgvUlhYbmxsZUhqNHlTZWZES3Urc01OeDNQNzkr
K1BpNGc0Y09DQTVGUFR4bmoxN0hBNUhjM096VW5jZ0NRL0R3OE5UcDA0OWYvNzgxS2xUaDRl
SENTR3Z2ZlphUlVVRklhUzh2SHozN3QyRWtJVUxGNzd4eGh2RHc4Tjc5KzZOU2l2bjhYWnVl
RHllOXZiMldiTm1FVUpHUjBmdnV1dXVmL3UzZjd2cnJydEdSMGRESndhZURxVHhrYWVQam80
S1BYMWtaQ1RjNHBUQWg0OExIL052MStoMnNhYW1KcjVNVlZOVEV5SGswcVZMQm9QaDNMbHpC
b1BoOHVYTGhCQ3RWdXR3T0FnaERvY2p1a2VEUFIvMjdObGpOQnJqNHVJNGpwc3laUXA5cXJP
emsrTzR6czdPa0lxQnB3TnBLaXNySDNqZ2dZR0JnYXRYcjFaV1ZoSkMwdExTamg0OTZuUTZY
My85OWVqK0tDMkpURStYZkJ4OVBQWFVVL1NiOCszYnQvTXpDU2FUNlZlLytsVjVlVG45czdD
dzhNMDMzM1E0SEcrLy9YWjBqd2I3dWlja0pEUTNOenNjRHJQWlRGc2NEc2VpUll0V3JWcTFh
TkVpcDlNWk9qSHdkQ0NOeStYNjkzLy85N1MwTlA2Nmw5cmFXb1BCa0pLU3NudjNiaCtlSHEz
dlh2WjlLNnFxS3RtSFJPbUFaR1ptZnZ2dHQ0U1FiNy85TmpNemt6YTJ0clp5SE5mYTJrci90
RnF0T1RrNUNRa0pHemR1akl1TG80MVJPUnJzNi83aWl5OGFEQWFEd2JCanh3N2E4dWlqajY1
WnM0WVE4ay8vOUUrUFBmWVl1Mkt3Z0tjREFFTEkyTmpZa1NOSGNuTnpsUllTSzhEVEFRQ2hn
czRtWjJabUtuWG5reGdFbmc0QUFORURQQjBBQUtLSE1IbTY4SHVrWUcwd1dKc0NBSUNvWVdL
ZXpubEI1czVneENwQytQcW1wcVlTUW5wNmVvcUxpK1BqNDR1TGkzdDdleVhYYW14c3pNek0x
R2cwbVptWmh3OGZwaTM1K2ZueDhmRkxsaXo1L1BQUHczb01RY1hsY2ozOTlOUHA2ZW44T2Qv
WTJHZzBHblU2M2E5Ly9ldnU3bTdKdGRoQkMzcCtvd2pzNmJGdjM3NnNyQ3lkVG5mcnJiY2VP
M1pNY2kyMmo1d3hqSHpZMFdCYldOaGpEOEJVV1NidTZWazN4QUZQajJxZWV1cXBUWnMyRVVK
Kzk3dmZWVmRYTzUzTzZ1cHFrOGtrMmRsZ01MUzB0TGhjTG92RllqQVlDQ0VtaytuVXFWTXVs
K3Z3NGNNelo4NE1wL0xnVWxsWnVYang0bE9uVG8yUGo5T1cxTlRVdHJZMnQ5dHROcHZ2di85
K3liVzhEVnJVdkJlRXA4ZTMzMzdyZERyMzdkdm43VGUwYkI4NVk2Z2krTkh3MGNMREhudFF6
b3BRZWZwcnI3MW1OQm8xR28zd2Y0Nm81K25UcDB0S1NuUTZYWFoyTnMzZzJCYU80eW9yS3hN
U0VuSnpjNjFXNi8vSjhGbGtRN0xRQkFpQUsxZXVKQ2NuOS9mM0UwSlNVMU1IQndjSklZT0Rn
OTdldElzV0xXcHRiWFc3M1VlUEhxVkZQeWdPaDZPaG9VSFZGN1RObmozN3M4OCtFN2FrcHFa
Ky9QSEg5RDJaa3BJaXVaYTNRWXVPMDFKNGV2RDA5ZlhwZERyZnZ5N20rOGdaUTdYQWpvYmsr
UEN3eDg1eG5NRmcwT3YxOTl4emo4MW1DMHhHcUR4OTZ0U3AyN1p0TzNYcWxOdnRGcTR1N0xO
a3laTDMzbnZQNVhLMXRMUmtaMmRMdG5BY1YxdGI2M0E0NnVycUNnc0xKVGZGTVVVMllxZlFS
S2pac1dNSC9hRUVJU1F1TG01c2JPeTIyMjd6ZUR3YWpVYXl2OVZxVFU1TzVqZ3VPVG1aL3cw
MC93bjBxNisrQ3BQdUVLRFJhS3FycS9WNi9ieDU4dzRlUEVnSXFhK3ZuenQzYm1KaTRzYU5H
NzBOaUxkQmk0N1RVbmg2VUg3ODhjZWlvaUxmaFR5RmZlU01vVnBnUjROdEVlTHQyQzlldkZo
WldWbGNYQnlZakZCNStrY2ZmWFR2dmZkbVoyZFBtemJ0ajMvOEk3KzZzSTlXcStVbmoyaEpC
TGFGNHppK1pJUk9weE1xRVQ0V0ZkbUluVUlUSVdWMGRIVGV2SG04TmFlbXBsNjRjSUg0ek5O
emNuSXNGb3ZMNVRLYnpYbDVlWHo3OFBEd2dRTUhDZ29LUXE4NlZDUW5KNXZOWnJmYjNkYldK
cG9oUFhiczJKdzVjeVRYOGpab1VYQmFpazRQUXNoWFgzMlZrWkZSWFYwOU5qYm1iUzF2Zlh5
TW9TcGdSNE50OFFaNzdFNm5VMmgzRXlLMDgrbGpZMlBIamgzVDYvWDB6MW16WmdrenRhS2lv
cWFtSm1IcEE3YUY0N2kzM25xTDV1bjUrZm5DZGgrUFk2ZlFSRWlwcjY4dkxTM2wvM3p3d1Fj
M2JkcmtjcmsyYmRyMCs5Ly9YbktWcEtRa2k4WGlkcnRiV2xyb2ZQcWpqejdhMDlQamNya2FH
aHBVL2VINnZ2dnU0ejJkZCtmeDhmSFRwMDh2WExpUWxzUmg4VFpvVVhCYWlrNlB1cnE2b3FL
aUw3Lzgwc2Nxa24zOGpxRXFFSTJHWkF1TDVMRmZ2MzU5NjlhdFJVVkZnU2tKbGFmVFhEc3VM
bTcrL1BsdnZQRUdiWHp6elRmMWVqM2YvOHlaTTh1WEwwOUlTT0RueDlrV2ZqNDlKeWVubzZP
RDM3THcyMkhXMHlVTFRZQ0pzbXpaTWpySlFMSFpiTXVXTGFOZjAvZjA5TkJHMGF0ZlgxOVB5
OUhObnorL29hR0JFUEx1dSs5bVpHUm90ZHFDZ2dLTHhSSk8vY0dsdTd0NzJiSmxXcTNXYURR
Mk5qYVNuMC9GOVBUMDlldlh1MXd1MmswMElPeWdzU2V3U2hHZEhxTGpHaG9hSXN4b3NIMGt4
MUNOaUVaRHNrVnlOSVRIVGx0dXV1bW01Y3VYbnoxN05qQWxZYjJXTVFBbXMzRVVtZ0FBeEJx
Ui9qdlNnRDJkUTZFSkFFRHNFZW1lRGdBQVFEN3dkQUFBaUI2aXpkTlYvYVVUQUFCTWttaXI5
d0pQRHgxeTZyMndmZVNzcFZJd0lFSXdHa0lVSEkwSmUvb3BKdURwTVlLY2VpOXNIemxycVJR
TWlCQ01oaEFGUnlOVW5zN1dlMkh6K2krLy9ITEJnZ1ZhclhiQmdnWDBad2djVTkyRmJXRnJ3
bGl0VmxyZHBiS3lFcDRlT3VUVWUySDd5RmxMcFdCQWhHQTBoQ2c0R3FIeWREbjFYdkx5OHVo
dlJHdHJheGNzV0VDa3FydXdMV3hObVB6OC9McTZPb2ZEVVZOVEEwOFBIWExxdmJCOTVLeWxV
akFnUWpBYVFoUWNqVkI1dXB4Nkx4cU5obFpsR1I0ZTFtcTFSS3E2QzlzaVdTV0czdzQ4UFhU
SXFmZkM5cEd6bGtyQmdBakJhQWhSY0RSQ081OHVxdmNTSHg4dkxDQXBtYWVMcXJ1d0xXeE5t
SUtDQXBxbjE5Yld3dE5EaDV4Nkwyd2ZPV3VwRkF5SUVJeUdFQVZISTFTZVR2Tm9VYjJYRFJz
MjBGb3U5TS8yOXZhOHZEeU5ScE9YbHllYVR4ZFdkeEcxc0RWaE9qbzZhSFdYcXFvcWVIcm9r
RlB2aGUwanVWWjBnQUVSZ3RFUW91Qm9SRmE5RjNaVDhHZ0FBSkJQWlAzbUNKNE9BQUNUSWJJ
OEhRQUF3R1NBcHdNQVFQUVFXWjd1YmFZRk16QUFBQ0NIU1ArT0ZFUU9LT2doQWdNaUJLTWhS
RTMxWHQ1bEFwNGVJNkNnaHdnTWlCQ01oaEExMVh1UjZlbkNMSDdxMUtuRVMzV1hwVXVYbHBl
WFoyUmtsSmVYMDVhcXFxckV4RVMrdWd1L0tYN0xiTDBYRUI1UTBFTUVCa1FJUmtPSW11cTlU
Q2hQcjZtcG1UNTlPblZ3eVYrTmRuVjEwU1gxZldGMWw0S0NBdUYrK2Nkc3ZSY1FIbERRUXdR
R1JBaEdRNGlhNnIzSTkvVDYrdnJrNU9Uang0L1RQeVdydTdCTFVYVVhmci84WTdiZUN3Z1BL
T2doQWdNaUJLTWhSRTMxWG1SNmVuTno4NHdaTS9qNUUrSWxUMmVYZkhVWFdvV1IzeS8vbUsz
M0FzSURDbnFJd0lBSXdXZ0lVVk85RjVtZXJ0ZnJSUmZHU0ZaM1laZDhkUmUrZnJwb08yeTlG
eEFlVU5CREJBWkVDRVpEQ09xOUFBQUFDQUtSOVpzakFBQUFrd0dlRGdBQTBRTThIUUFBb29k
d2VIcGdFKzZZcGdjQWdJa1NqdTlJNGVuUkFRcDZpTUNBQ01Gb0NGRlR2WmNiVE1EVFl3UVU5
QkNCQVJHQzBSQ2lwbm92TWozZGFyWG01ZVVsSkNSVVZsYlNEbXlkRnByamE3WGFSWXNXdGJX
MVNhNEZJZ2NVOUJDQkFSR0MwUkNpcG5vdk1qMDlQeisvcnE3TzRYRFUxTlRRRHQ3cXRIZzhu
dmIyOWxtelprbXVCU0lIRlBRUWdRRVJndEVRb3FaNkx6STlYYXZWOHRWZGFBZTJUc3VlUFh1
TVJtTmNYQnpmd3E0RklnY1U5QkNCQVJHQzBSQ2lwbm92TWoyOW9LQ0FadHkxdGJXMEExdW5K
U0Vob2JtNTJlRndtTTFtMm9kZEMwUU9LT2doQWdNaUJLTWhSRTMxWG1SNmVrZEhSMDVPVGtK
Q1FsVlZsYmM2TFMrKytLTEJZREFZRER0MjdLQXQ3Rm9nY2tCQkR4RVlFQ0VZRFNHbzl3SUFB
Q0FJNEhla0FBQVFQY0RUQVFBZ2VvQ25Bd0JBOUJDSm5vNEplZ0FBQ0F4OFJ3cmtnb0llSWpB
Z1FqQWFRdFJVNzRYNzZDTnh3Tk5qQXhUMEVJRUJFWUxSRUtLbWVpOHlQWjM3K2M2aXVibTV3
anVMQ3F1N2RIWjIwdW91MWRYVi9FWkVpVC9IY2ErKyttcEtTa3B5Y3ZMZXZYdTlyUVhDQUFw
NmlNQ0FDTUZvQ0ZGVHZSZjVubDViVyt0d09PcnE2Z29MQy9sMllYV1hoUXNYdnZIR0c4UER3
M3YzN2hYNXVQRHhuajE3SEE1SGMzTXpQVWh2YTRGUWc0SWVJakFnUWpBYVF0UlU3MFcrcDlQ
S0xRNkhRNmZURVovVlhSd09odzlQSHgwZEZiWjdXd3VFR2hUMEVJRUJFWUxSRUtLbWVpL3lQ
ZjJ0dDk2aWVYcCtmajZScXU1U1dGajQ1cHR2T2h5T3Q5OSsyNGVuaXg1N1d3dUVHaFQwRUlF
QkVZTFJFS0ttZWk4VG5VL1B5Y25wNk9nZ1V0VmRyRllycmU2eWNlUEd1TGc0d2x4WFE2UThu
VjBMaEFjVTlCQ0JBUkdDMFJBU2hmVmU1R2ZRWTJOalI0NGN5YzNOblpEdXdOWUNBSURvSmxT
L09aTHA2WFJ1UFRNejg5TlBQNTNReGdOWUN3QUFvcDVJL0IwcEFBQ0F3SUNuQXdCQTlLQzhw
MGYrdFN2ZXJzTWhnaThZd2k0S0FBQWtVRUc5bDNBNnB0OTlUZklMWVZXRGdoNGlZbWRBMkhj
NjJ5TG51Qm9iRzQxR0k3MnVvN3U3VzNJNzBVRmpZMk4rZm41OGZQeVNKVXMrLy94emIzMjhq
UWJIY2FtcHFZSHRldUwzcm1zVUJ6dzkrczVJU1ZEUVEwU3NEUWg3bmd0YjVCeFhhbXBxVzF1
YjIrMDJtODMzMzMrL2p5MnJIWlBKZE9yVUtaZkxkZmp3NFprelowcjI4VFlhaEpDbm5ucHEw
NlpOZ2UwNlZKN096bGR3VE9VV0lxTzZDL3RwNFBUcDB5VWxKVHFkTGpzN20vOEh5SEZjVlZX
VlhxOWZ2SGl4Wkl1a0hzbUtOSkw1aVBEUHFxcXF4TVJFZmkzQ25KR1NDcU1BRlBRUUVXc0Q0
dHZUWlk3R3h4OS9URjBzSlNWRmNqc2N4eTFkdXJTOHZEd2pJNk84dkR5SStzT1B3K0ZvYUdq
d2RzbTF0OUc0Y3VWS2NuSnlmMzkvWURzTnE2ZUxLcmRJOW1UN2lMYS9aTW1TOTk1N3orVnl0
YlMwWkdkbjgzMWVlZVdWNGVIaEo1OThVckpGVWc5YmtVYk9zZkJyRlJRVXlGY1lCYUNnaDRo
WUd4RGZuaTdudU9ycjYrZk9uWnVZbUxoeDQwWmhIOUZickt1cml5Nm5UcDBhMUNNSUsvd1V5
bGRmZlNYWndkdG83Tml4WTgyYU5RSHZOK1NlUGpvNnludW9xSEtMNUdPMmoyajdXcTJXejZa
cDNSamFaMlJrUkNSQTJDS3BSMVNSaHQyWHBFSy9hMGtxakFKUTBFTkVyQTJJM3p4ZC9uRWRP
M1pzenB3NWt0dmgzNTZTZTFRWHc4UERCdzRjNEpNL2J3aEhZM1IwZE42OGVaMmRuUUh2TkZT
ZW5wYVdkdlRvVWFmVCtmcnJyN012ejRRZXg4ZkgyMncydnIyb3FLaXBxY25wZElxRXNWTDk2
aEZWcEdIM0phbUtYNHZQN21mTm1pWDhWeXlwTUFwQVFROFJzVFlndnQ5bE1vOXJmSHo4OU9u
VEN4Y3VyS3lzbE54T2RIajZvNDgrMnRQVDQzSzVHaG9haFBNcUl0alJxSyt2THkwdG5jeXVR
K1hwdGJXMUJvTWhKU1ZsOSs3ZDNqeWQreVdTZlFnaEd6WnNTRWhJNFA4OGMrYk04dVhMYVl1
M1hKNXRrZFFqcWtqRDdrdFNJYjhXUDUvKzVwdHY2dlY2M3dxakFCVDBFQkU3QXlMNVJoQzF5
QmtOMmprOVBYMzkrdlV1bDh2YmxvbjZQZjNkZDkvTnlNalFhclVGQlFVV2k0VTIraDBOUXNp
eVpjc09Ianc0bVYycjRGckdFS0ZTMlFBQTRBUGxmM09rRlBCMEFFRDBFYnVlRGdBQTBRYzhI
UUFBb2dmMWVicms5d3lZU0FFQUFLTEc3MGdsZHdkUER3TnlYbTYyai9BOENiaUVSZmhoYTNG
SXRtUm1abW8wbXN6TXpNT0hEOHZjVHJSbUlYS095MXRObUczYnRrWFpnT3pidHk4ckswdW4w
OTE2NjYzSGpoMlQ3QlBZR2VXWENYdDYxbzBzVWNEVFl3bzVReTNaWnpJbExNSVBXNHVEYlRF
WURDMHRMUzZYeTJLeEdBd0dtZHVoUk9zWjYvdTRKR3ZDZlBQTk4rbnA2VkUySUwvNzNlKysv
ZlpicDlPNWI5OCtINzlIQytDTThrc0lQWjJUVVhHRnJlNGlXZTlGcTlVdVdyU29yYTJOMzJ4
c1ZseUpCQUx6OUVtV3NBZy9iQzBPdG1YUm9rV3RyYTF1dC92bzBhTzMzbnFyek8xUVJHK0hx
S2x3NHZ2MFlHdkN1Rnl1Z29LQ1AvLzV6MUhtNlR4OWZYMDZuVTcwSzNkS1lHZVVYMExyNlg0
cnJvaXF1N0F0RkkvSDA5N2VQbXZXTEJMYkZWY2lnY0E4ZlpJbExNSVBXNHVEYmJGYXJjbkp5
UnpISlNjbmUvc3hkMHhWT0NIK1RnKzJKc3l6eno1TGYzUWFsWjcrNDQ4L0ZoVVZQZlBNTTVM
UEJuWkcrU1cwbnU2MzRvcW91Z3Zic21mUEhxUFJHQmNYeC8xY080V0w0WW9ya1VBQW5qNzVF
aFlLSXFwTUltekp5Y214V0N3dWw4dHNOdWZsNVUxb081SXBEbEcvdGZuTjAwVTFZZWhiT3lx
L1kvanFxNjh5TWpLcXE2dkh4c1o4OXd6c2pQSkdhRDFkK0tlY0NqQnNTMEpDUW5OenM4UGhN
SnZOZkorWXJiZ1NDUVRnNlpNdllhRUliQzBPVVV0U1VwTEZZbkc3M1MwdExUNW1QMk9rd2du
RnQzNGZOV0hVZnVBaTZ1cnFpb3FLdnZ6eVM5L2RBanVqZkJNK1Q1ZFpBVWJVOHVLTEx4b01C
b1BCc0dQSERyNVB6RlpjVVJidWwvQ05mdnRNdm9SRitLSDYyY29rd3BiNitucjZJWEwrL1Br
TkRRMzhpbksySXh5aTZQQjBPYWVIajFvMzZqMXdTVVNqTVRRMFJHU2NHNUpuMUVSUjM3V01B
QUFBdktHKzN4d0JBQUR3Qmp3ZEFBQ2lCM2c2QUFCRUR4SHQ2Wml2QndDQUNSSEM3MGpsZUhH
dytvQ2dJM3g5YVowV09TVXMySUllM2twOHFBNTJRT1RrSE96aFIwZW13bzVHWTJOamZuNStm
SHo4a2lWTGZQOTRtNjN1b3ZaNkw1S2pJYXJsd3VLdHp5UkhZOEtlYm1XQXAwYzNmSjBXT1NV
czJJSWVraVUrVkkyb2NJM3Y4OVBiNFVmTldjMlBoc2xrT25YcWxNdmxPbno0OE15Wk03MzFa
NnU3UkZPOUYzNDB2Tlg1RVNMWlovS2pFU3BQWjdQNEw3Lzhjc0dDQlZxdGRzR0NCZlJTZkxZ
UGZTeXM3a0tpNk94WEk1SjFXbnlYc0JBVjlHQmJWQTA3SUw3UFQyK0hIeDFuTlRzYURvZWpv
YUVoTnpkWHNqOWIzU1dhNnIwSVI4TmJuUjhoYkorZ2pFYjQ4dlM4dkR6Nis4L2EydG9GQ3ha
STlxRUlxN3Q0NndQQ0ExdW54WGNKQzdhZ0I5dWlhdGdCOFgxK2Vqdjg2RGlyUmFQQlR6NElm
OVF0aEszdUVrMzFYb1NqNGEzT2p4QzJUMUJHSTN5ZXJ0Rm9hSjJXNGVGaHJWWXIyWWV0N3NM
MkFXR0RyZFBpdDRRRlc5Q0RiVkV2a29Wci9PYnBrb2NmQldlMTVHZ01EdzhmT0hDQUw2NG5n
cTN1RWpYMVhyd1ZOV0xyQmJId2ZZSXlHaUgwOVBqNGVKdk54djhwbWFlTCtyRFZYUWhUeXdX
RURWR2RGamtsTE5pQ0hqNUtmS2dPeWNJMXZ0OTczZzVmMWY1RkVZM0dvNDgrMnRQVDQzSzVH
aG9hdk0wMjhMQ0hyL1lCWWM4TnlUby9JcnoxaWRBOGZjT0dEYlRpQ3YyenZiMDlMeTlQbzlI
azVlWHh2aURxdzFaM0lVd3RGeEEyUkhWYXVGOGlXY0tDTGVqaG84U0g2dkE5SUh5amNCWDI4
Q1hYVWlPaTBYajMzWGN6TWpLMFdtMUJRWUhGWXFHTk1qL0UrK2lwRmlUUERXRXRGeUtqM292
d3FZQ1ZvTjRMQUFCRUR4SDlteU1BQUFBVEFwNE9BQURSQXp3ZEFBQ2lCM2c2QUJFTnZxOENF
d0tlRG9BRUFUdHAwQzNZeHdhRHNpK080MTU1NVJWQ3lNc3Z2enlaRFhJY3QzUG56c2tMWThz
S05UWTJabVptYWpTYXpNek13NGNQZTl1NzZIb05sOHYxOU5OUDA5L1plOVBEMXFpUmMra0hX
OE5IVHEwYjlyamsxQUlLNERvVWVEb0FFc1NVcCtmbDVZMlBqK2ZtNWs3UzAzTnljcTVmdno1
SllXeFpJWVBCME5MUzRuSzVMQmFMNzd0MEN2ZGJXVm01ZVBIaVU2ZE9qWStQZSt2UDFxaVJv
NXl0NFNPbjFnMTdYUEpyQWNIVEFaZ3NrdThyN3BmRmlGNTc3VFdqMGFqUmFQaE1TazZXSjhy
Q2lPQVd1N201dWZRV3UxYXJOUzh2THlFaG9iS3lVcmhsNGQ3WmZaMCtmYnFrcEVTbjAyVm5a
L1Bab2w4NzREanV0dHR1MjdwMTYrMjMzMDQ3UzVabWV2WFZWMU5TVXBLVGsvZnUzZXR0Tzl1
MmJYdnBwWmY0bmJMYldieDRNUlhmMnRwNjY2MjMraGJHbHhWYXRHaFJhMnVyMiswK2V2U283
N1dFQnp0Nzl1elBQdnZNUndjZVlZMGFqdU1NQm9OZXI3L25ubnY0bjBPSzF2Sld3OGQzclJ2
MnVPVFhBb0tuQXpCWnZMMkxoTVdJcGs2ZHVtM2J0bE9uVHJuZGJyOHJTbmJnL2JxMnR0Ymhj
TlRWMVJVV0ZoSkM4dlB6NitycUhBNUhUVTJOc0wvdlVraExsaXg1NzczM1hDNVhTMHRMZG5h
Mi9DUGR2MzkvWEZ6Y2dRTUg2QWJabjN4ekhMZG56eDZIdzlIYzNPeXR3QVBIY1VORFExbFpX
VmV1WFBHMm5kZGVlNjJpb29JUVVsNWV2bnYzYmgrcWhHV0ZyRlpyY25JeXgzSEp5Y25zais5
Rkd2akhHbzJtdXJwYXI5ZlBtemZQeHkzTzZUOUZVWTJhaXhjdlZsWldGaGNYUzY0aVdjTkhj
anUrajB0K0xTQjRPZ0NUaFgwWHNjV0lQdnJvbzN2dnZUYzdPM3ZhdEdsLy9PTWZ2YTNvYmN1
am82TzhwOU5TU0E2SFE2ZlRFVUswV2kxZkhJbjJrVk1LU2F2VjhwazczMmRDUjBvZnM2V1pP
STRiSFIzMWZZQzBmZnYyN2M4Ly83eTM3Vnk2ZE1sZ01KdzdkODVnTUZ5K2ZObWJKRkZab1p5
Y0hJdkY0bks1ekdaelhsNmV6R05KVGs0Mm04MXV0N3V0clkzV05QZUdaSTBhcDlOSlh3c1di
elY4Zk5lNllZOUxmaTBnZURvQWs0VjlGMGtXSXlLRWpJMk5IVHQyVEsvWDB6OUZKWXhZMHRM
U2poNDk2blE2WDMvOWRkN1RhVDViVjFlWG41OVBDQ2tvS0tCNWVtMXRMZTBqdVhmUnZvcUtp
cHFhbXB4T1o4Qkg2aU5QOXpFeXd2Ymg0ZUg1OCtkNzJ3NGh4R1F5L2VwWHZ5b3ZML2VtaHkw
cmxKU1VaTEZZM0c1M1MwdUwvUG4wKys2N2ovZDBiNTh0dk5Xb3VYNzkrdGF0VzR1S2lpVFhZ
bXY0eUtsMXd4NlgvRnBBOEhRQUpndjNTNGhVTVNMNlZGeGMzUHo1ODk5NDR3MjZvcWlFRVV0
dGJhM0JZRWhKU2RtOWU3ZG9QajBuSjZlam80TVEwdEhSa1pPVGs1Q1FVRlZWNVczdjdMN09u
RG16ZlBseTJzSTNCakFYeEpabWt1L3BoSkNkTzNkNjJ3NGhwTFcxbGVPNDF0WldIM3FFREEw
TjFkZlgwODhvOCtmUGIyaG9rTE1XSWFTN3UzdlpzbVZhcmRab05EWTJOa3FLWjJ2VTBOVnZ1
dW1tNWN1WG56MTdWbkl0dG9hUFpLMGJ2OGNscHhZUTIrSVhlRG9BQ2pPaExBd0EzOERUQVZB
WWVEb0lJdkIwQUFDSUh1RHBBQUFRUGNEVEFRQWdlb0NuQXdCQTlBQlBCK3FncWFtcHViblo0
L0UwTnpjM05UWEpYTVgzczk0NkRBOFBtODFteWY0KzFnSWdFb0NuQTNYUTFOVDB4UmRmZlAv
OTkzLzV5MStDNWFyZXR2UDExMSt6VDhIS2dTcUFwd04xME5UVWRPYk1HWXZGY3ViTUdkNWVS
USthbXBxNnVyb3NGc3ZwMDZlOU5ZcTJ5ZTdvK3ZYcnJhMnRrcDV1c1ZnKy92ampnWUdCb0I0
WkFNRUVuZzdVUVZOVDA2VkxsL2dsM3loODBOVFVkUG55NWVIaFlmcGJQc2xHMFRiWkhmMzFy
My90N3U2V2ZHcDhmSHhnWU9EbzBhUEJPeXdBZ2d3OEhhaURwcWFtOGZIeFR6NzVaSHg4bkRk
Y2k4VXlQRHpNdXp4cjhXeWphSnVTTy9JMmJ6NCtQbjdod2dWNE9vaGs0T2xBSFFnZGxuOTgr
dlJwaThYUzFkVVZnS2VMakp0OWxuM1ExTlQwOGNjZm56OS9QcGdIQmtCUWdhY0RBRUQwQUU4
SEFJRG9BWjRPQUFEUkF6d2RBQUNpQjNnNkFBQkVEL0IwQUFDSUh2N1AwNjFXNjM0QUFBRHFo
NE9oQXdCQTFQRC9BWjRFWUVWMjZ4WHVBQUFBQUVsRlRrU3VRbUNDIiAvPjwvcD48cD4mbmJz
cDs8L3A+PHA+SWYgeW91IG5lZWQgb3RoZXIgY2hhcnRzLCBJIGNhbiB0cnkgdG8gcHJvZHVj
ZSB0aGVtLiA8L3A+PHA+Jm5ic3A7PC9wPjxwPkJSLDxiciAvPkNhcnN0ZW4uPC9wPjxwPiZu
YnNwOzwvcD48YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6IDJweCBzb2xpZCAjMzI1
RkJBOyBwYWRkaW5nLWxlZnQ6IDVweDttYXJnaW4tbGVmdDo1cHg7Ij4tLS0tLVVyc3ByJnV1
bWw7bmdsaWNoZSBOYWNocmljaHQtLS0tLTxiciAvPjxzdHJvbmc+QW46PC9zdHJvbmc+CUNh
cnN0ZW4gU2NoaWVycyAmbHQ7Y2Fyc3RlbkBzY2hpZXJzLmRlJmd0Ozsgemhlbnpob25nLmR1
YW5Ab3JhY2xlLmNvbTsgbGVyc2VrQHJlZGhhdC5jb207IDxiciAvPjxzdHJvbmc+Q0M6PC9z
dHJvbmc+CXhlbi1kZXZlbCAmbHQ7eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20mZ3Q7
OyBrb25yYWQud2lsayAmbHQ7a29ucmFkLndpbGtAb3JhY2xlLmNvbSZndDs7IDxiciAvPjxz
dHJvbmc+Vm9uOjwvc3Ryb25nPglLb25yYWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJhZEBk
YXJub2sub3JnJmd0OzxiciAvPjxzdHJvbmc+R2VzZW5kZXQ6PC9zdHJvbmc+CU1vIDI4LjEx
LjIwMTEgMTY6MzM8YnIgLz48c3Ryb25nPkJldHJlZmY6PC9zdHJvbmc+CVJlOiBbWGVuLWRl
dmVsXSBMb2FkIGluY3JlYXNlIGFmdGVyIG1lbW9yeSB1cGdyYWRlIChwYXJ0Mik8YnIgLz5P
biBGcmksIE5vdiAyNSwgMjAxMSBhdCAxMToxMTo1NVBNICswMTAwLCBDYXJzdGVuIFNjaGll
cnMgd3JvdGU6PGJyIC8+Jmd0OyBJIGdvdCB0aGUgdmFsdWVzIGluIERvbVUuIEkgd2lsbCBo
YXZlPGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7ICZuYnNwOyAtIGFwcm94LiA1JSBsb2FkIGluIERv
bVUgd2l0aCAyLjYuMzQgWGVuaWZpZWQgS2VybmVsPGJyIC8+Jmd0OyAmbmJzcDsgLSBhcHJv
eC4gMTUlIGxvYWQgaW4gRG9tVSB3aXRoIDIuNi4zMi40NiBKZXJlbXkgb3IgMy4xLjIgS2Vy
bmVsIHdpdGggb25lIGNhcmQgYXR0YWNoZWQ8YnIgLz4mZ3Q7ICZuYnNwOyAtIGFwcm94LiAz
MCUgbG9hZCBpbiBEb21VIHdpdGggMi42LjMyLjQ2IEplcmVteSBvciAzLjEuMiBLZXJuZWwg
d2l0aCB0d28gY2FyZHMgYXR0YWNoZWQ8YnIgLz48YnIgLz5IQSE8YnIgLz48YnIgLz5JIGp1
c3Qgd29uZGVyIGlmIHRoZSBpc3N1ZSBpcyB0aGF0IHRoZSByZXBvcnRpbmcgb2YgQ1BVIHNw
ZW50IGlzIHdyb25nLjxiciAvPkxhc3psbyBFcnNlayBhbmQgWmhlbnpob25nIER1YW4gaGF2
ZSBib3RoIHJlcG9ydGVkIGEgYnVnIGluIHRoZSBwdm9wczxiciAvPmNvZGUgd2hlbiBpdCBj
YW1lIHRvIGFjY291bnQgb2YgQ1BVIHRpbWUuPGJyIC8+PGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7
IEkgbG9va2VkIHRocm91Z2ggbXkgb2xkIG1haWxzIGZyb20geW91IGFuZCB5b3UgZXhwbGFp
bmVkIGFscmVhZHkgdGhlIG5lY2Vzc2l0eSBvZiBkb3VibGU8YnIgLz4mZ3Q7IGJvdW5jZSBi
dWZmZXJpbmcgKFBDSS0mZ3Q7YmVsb3cgNEdCLSZndDthYm92ZSA0R0IpLiBXaGF0IEkgZG9u
JiMzOTt0IHVuZGVyc3RhbmQgaXM6IHdoeSBkb2VzIHRoZTxiciAvPiZndDsgWGVuaWZpZWQg
a2VybmVsIG5vdCBoYXZlIHRoaXMga2luZCBvZiBpc3N1ZT88YnIgLz48YnIgLz5UaGF0IGlz
IGEgcHV6emxlLiBJdCBzaG91bGQgbm90LiBUaGUgY29kZSBpcyB2ZXJ5IG11Y2ggdGhlIHNh
bWUgLSBib3RoPGJyIC8+dXNlIHRoZSBnZW5lcmljIFNXSU9UTEIgd2hpY2ggaGFzIG5vdCBj
aGFuZ2VkIGZvciB5ZWFycy48YnIgLz4mZ3Q7IDxiciAvPiZndDsgVGhlIGRyaXZlciBpbiBx
dWVzdGlvbiBpcyBuZWFybHkgaWRlbnRpY2FsIGJldHdlZW4gdGhlIHR3byBrZXJuZWwgdmVy
c2lvbnMuIEl0IGlzIGluPGJyIC8+Jmd0OyBEcml2ZXJzL21lZGlhL2R2Yi90dHBjaSBieSB0
aGUgd2F5IGFuZCB3aGVuIEkgdW5kZXJzdG9vZCB0aGUgY29kZSByaWdodCwgdGhlIGFsbG8g
aW4gPGJyIC8+Jmd0OyBxdWVzdGlvbiBpczo8YnIgLz4mZ3Q7IDxiciAvPiZndDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8qIGFsbG9jYXRlIGFuZCBpbml0IGJ1ZmZlcnMgKi88
YnIgLz4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhdjcxMTAtJmd0O2RlYmlf
dmlydCA9IHBjaV9hbGxvY19jb25zaXN0ZW50KHBkZXYsIDgxOTIsICZhbXA7YXY3MTEwLSZn
dDtkZWJpX2J1cyk7PGJyIC8+PGJyIC8+R29vZC4gU28gaXQgYWxsb2NhdGVzIGl0IGR1cmlu
ZyBpbml0IGFuZCB1c2VzIGl0LjxiciAvPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IGlmICghYXY3MTEwLSZndDtkZWJpX3ZpcnQpPGJyIC8+Jmd0OyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGdvdG8gZXJyX3Nh
YTcxNDY2X3ZmcmVlXzQ7PGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7IGlzbiYjMzk7dCBpdD8gSSB0
aGluayB0aGUgY2FyZHMgYXJlIGNvbnN0YW50bHkgdHJhbnNmZXJyaW5nIHRoZSBzdHJlYW0g
cmVjZWl2ZWQgdGhyb3VnaCBETUEuIDxiciAvPjxiciAvPlllYWgsIGFuZCB0aGF0IG1lbW9y
eSBpcyBzZXQgYXNpZGUgZm9yIHRoZSBsaWZlIG9mIHRoZSBkcml2ZXIuIFNvIHRoZXJlPGJy
IC8+c2hvdWxkIGJlIG5vIGJvdW5jZSBidWZmZXJpbmcgaGFwcGVuaW5nIChhcyBpdCBhbGxv
Y2F0ZWQgdGhlIG1lbW9yeTxiciAvPmJlbG93IHRoZSA0R0IgbWFyaykuPGJyIC8+Jmd0OyA8
YnIgLz4mZ3Q7IEkgaGF2ZSBzZXQgZG9tMF9tZW09NTEyTSBieSB0aGUgd2F5LCBzaGFsbCBJ
IGNoYW5nZSB0aGF0IGluIHNvbWUgd2F5PzxiciAvPjxiciAvPkRvZXMgdGhlIHJlcG9ydGlu
ZyAoQ1BVIHVzYWdlIG9mIERvbVUpIGNoYW5nZSBpbiBhbnkgd2F5IHdpdGggdGhhdD88YnIg
Lz4mZ3Q7IDxiciAvPiZndDsgSSBjYW4gdHJ5IG91dCBzb21lIHRoaW5ncywgaWYgeW91IHdh
bnQgbWUgdG8uIEJ1dCBJIGhhdmUgbm8gaWRlYSB3aGF0IHRvIGRvIGFuZCB3aGVyZSB0bzxi
ciAvPiZndDsgc3RhcnQsIHNvIEkgcmVseSBvbiB5b3VyIGhlbHAuLi48YnIgLz4mZ3Q7IDxi
ciAvPiZndDsgQ2Fyc3Rlbi48YnIgLz4mZ3Q7IDxiciAvPiZndDsgLS0tLS1VcnNwcj9uZ2xp
Y2hlIE5hY2hyaWNodC0tLS0tPGJyIC8+Jmd0OyBWb246IHhlbi1kZXZlbC1ib3VuY2VzQGxp
c3RzLnhlbnNvdXJjZS5jb20gW21haWx0bzp4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW5z
b3VyY2UuY29tXSBJbSBBdWZ0cmFnIHZvbiBLb25yYWQgUnplc3p1dGVrIFdpbGs8YnIgLz4m
Z3Q7IEdlc2VuZGV0OiBGcmVpdGFnLCAyNS4gTm92ZW1iZXIgMjAxMSAxOTo0MzxiciAvPiZn
dDsgQW46IENhcnN0ZW4gU2NoaWVyczxiciAvPiZndDsgQ2M6IHhlbi1kZXZlbDsga29ucmFk
LndpbGs8YnIgLz4mZ3Q7IEJldHJlZmY6IFJlOiBbWGVuLWRldmVsXSBMb2FkIGluY3JlYXNl
IGFmdGVyIG1lbW9yeSB1cGdyYWRlIChwYXJ0Mik8YnIgLz4mZ3Q7IDxiciAvPiZndDsgT24g
VGh1LCBOb3YgMjQsIDIwMTEgYXQgMDE6Mjg6NDRQTSArMDEwMCwgQ2Fyc3RlbiBTY2hpZXJz
IHdyb3RlOjxiciAvPiZndDsgJmd0OyBIZWxsbyBhZ2FpbiwgSSB3b3VsZCBsaWtlIHRvIGNv
bWUgYmFjayB0byB0aGF0IHRoaW5nLi4uc29ycnkgdGhhdCBJIGRpZCBub3QgaGF2ZSB0aGUg
dGltZSB1cCB0byBub3cuPGJyIC8+Jmd0OyAmZ3Q7IDxiciAvPiZndDsgJmd0OyA/PzxiciAv
PiZndDsgJmd0OyBXZSAobm93KSBzcGVhayBhYm91dDxiciAvPiZndDsgJmd0OyA8YnIgLz4m
Z3Q7ICZndDsgPz88YnIgLz4mZ3Q7ICZndDsgKglYZW4gNC4xLjI8YnIgLz4mZ3Q7ICZndDsg
KglEb20wIGlzIEplcmVteSYjMzk7cyAyLjYuMzIuNDYgNjQgYml0PGJyIC8+Jmd0OyAmZ3Q7
ICoJRG9tVSBpbiBxdWVzdGlvbiBpcyBub3cgMy4xLjIgNjQgYml0PGJyIC8+Jmd0OyAmZ3Q7
ICoJU2FtZSB0aGluZyBpZiBEb21VIGlzIGFsc28gMi42LjMyLjQ2PGJyIC8+Jmd0OyAmZ3Q7
ICoJRG9tVSBvd25zIHR3byBQQ0kgY2FyZHMgKERWQi1DKSB0aGF0IG8gRE1BPGJyIC8+Jmd0
OyAmZ3Q7ICoJTWFjaGluZSBoYXMgOEdCLCBEb20wIHBpbm5lZCBhdCA1MTJNQjxiciAvPiZn
dDsgJmd0OyA8YnIgLz4mZ3Q7ICZndDsgPz88YnIgLz4mZ3Q7ICZndDsgQXMgY29tcGFyZWQg
dG8gMi42LjM0IEtlcm5lbCB3aXRoIGJhY2twb3J0ZWQgcGF0Y2hlcywgdGhlIGxvYWQgb24g
dGhlIERvbVUgaXMgYXQgbGVhc3QgdHdpY2UgYXMgaGlnaC4gSXQ8YnIgLz4mZ3Q7ICZndDsg
PGJyIC8+Jmd0OyAmZ3Q7IHdpbGwgYmUgJnF1b3Q7Y2xvc2UgdG8gbm9ybWFsJnF1b3Q7IGlm
IEkgcmVkdWNlIHRoZSBtZW1vcnkgdXNlZCB0byA0R0IuPGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7
IFRoYXQgaXMgaW4gdGhlIGRvbTAgb3IganVzdCBpbiBnZW5lcmFsIG9uIHRoZSBtYWNoaW5l
PzxiciAvPiZndDsgJmd0OyA8YnIgLz4mZ3Q7ICZndDsgPz88YnIgLz4mZ3Q7ICZndDsgQXMg
eW91IGNhbiBzZWUgZnJvbSB0aGUgYXR0YWNobWVudCwgeW91IG9uY2UgaGFkIGFuIGlkZWEu
IFNvIHNob3VsZCB3ZSB0cnkgdG8gZmluZCBzb21ldGhpbmcuLi4/PGJyIC8+Jmd0OyA8YnIg
Lz4mZ3Q7IEkgdGhpbmsgdGhhdCB3YXMgdG8gaW5zdHJ1bWVudCBzd2lvdGxiIHRvIGdpdmUg
YW4gaWRlYSBvZiBob3c8YnIgLz4mZ3Q7IG9mdGVuIGl0IGlzIGNhbGxlZCBhbmQgYmFzaWNh
bGx5IGhhdmUgYSBtYXRyaXggb2YgaXRzIGxvYWQuIEFuZDxiciAvPiZndDsgZnJvbSB0aGVy
ZSBmaWd1cmUgb3V0IGlmIHRoZSBpc3N1ZSBpcyB0aGF0OjxiciAvPiZndDsgPGJyIC8+Jmd0
OyAmbmJzcDsxKS4gVGhlIGRyaXZlcnMgYWxsb2NvYXRlL2JvdW5jZS9kZWFsbG9jYXRlIGJ1
ZmZlcnMgb24gZXZlcnkgaW50ZXJydXB0PGJyIC8+Jmd0OyAmbmJzcDsgJm5ic3A7IChiYWQs
IGRyaXZlciBzaG91bGQgYmUgdXNpbmcgc29tZSBmb3JtIG9mIGRtYSBwb29sIGFuZCBtb3N0
IG9mIHRoZTxiciAvPiZndDsgJm5ic3A7ICZuYnNwOyBpdnR2IGRvIHRoYXQpPGJyIC8+Jmd0
OyA8YnIgLz4mZ3Q7ICZuYnNwOzIpLiBUaGUgYnVmZmVycyBhbGxvY2F0ZWQgdG8gdGhlIGRy
aXZlcnMgYXJlIGFib3ZlIHRoZSA0R0IgYW5kIHdlIGVuZDxiciAvPiZndDsgJm5ic3A7ICZu
YnNwOyB1cCBib3VuY2luZyBpdCBuZWVkbGVzc2x5LiBUaGF0IGNhbiBoYXBwZW4gaWYgdGhl
IGRvbTAgaGFzIG1vc3Qgb2Y8YnIgLz4mZ3Q7ICZuYnNwOyAmbmJzcDsgdGhlIHByZWNpb3Vz
IG1lbW9yeSB1bmRlciA0R0IuIEhvd2V2ZXIsIHRoYXQgaXMgdXN1YWxseSBub3QgdGhlIGNh
c2U8YnIgLz4mZ3Q7ICZuYnNwOyAmbmJzcDsgYXMgdGhlIGRvbWFpbiBpc3VzdWFsbHkgYWxs
b2NhdGVkIGZyb20gdGhlIHRvcCBvZiB0aGUgbWVtb3J5LiBUaGU8YnIgLz4mZ3Q7ICZuYnNw
OyAmbmJzcDsgZml4IGZvciB0aGF0IHdhcyB0byBzZXQgZG9tMF9tZW09bWF4OlhYLiAuLiBi
dXQgd2l0aCBEb20wIGtlcm5lbHM8YnIgLz4mZ3Q7ICZuYnNwOyAmbmJzcDsgYmVmb3JlIDMu
MSwgdGhlIHBhcmFtZXRlciB3b3VsZCBiZSBpZ25vcmVkLCBzbyB5b3UgaGFkIHRvIHVzZTxi
ciAvPiZndDsgJm5ic3A7ICZuYnNwOyAmIzM5O21lbT1YWCYjMzk7IG9uIHRoZSBMaW51eCBj
b21tYW5kIGxpbmUgYXMgd2VsbC48YnIgLz4mZ3Q7IDxiciAvPiZndDsgJm5ic3A7MykuIFdo
ZXJlIGRpZCB5b3UgZ2V0IHRoZSBsb2FkIHZhbHVlcz8gV2FzIGl0IGRvbTA/IG9yIGRvbVU/
PGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7IDxiciAvPiZndDsgPGJyIC8+Jmd0OyAmZ3Q7IDxiciAv
PiZndDsgJmd0OyA/PzxiciAvPiZndDsgJmd0OyBDYXJzdGVuLjxiciAvPiZndDsgJmd0OyA/
PzxiciAvPiZndDsgJmd0OyAtLS0tLVVyc3ByPz9uZ2xpY2hlIE5hY2hyaWNodC0tLS0tPGJy
IC8+Jmd0OyAmZ3Q7IEFuOmtvbnJhZC53aWxrICZsdDtrb25yYWQud2lsa0BvcmFjbGUuY29t
Jmd0OzsgPGJyIC8+Jmd0OyAmZ3Q7IENDOmxpbnV4ICZsdDtsaW51eEBlaWtlbGVuYm9vbS5p
dCZndDs7IHhlbi1kZXZlbCAmbHQ7eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20mZ3Q7
OyA8YnIgLz4mZ3Q7ICZndDsgVm9uOkNhcnN0ZW4gU2NoaWVycyAmbHQ7Y2Fyc3RlbkBzY2hp
ZXJzLmRlJmd0OzxiciAvPiZndDsgJmd0OyBHZXNlbmRldDpNaSAyOS4wNi4yMDExIDIzOjE3
PGJyIC8+Jmd0OyAmZ3Q7IEJldHJlZmY6QVc6IFJlOiBSZTogUmU6IEFXOiBSZTogW1hlbi1k
ZXZlbF0gQVc6IExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5IHVwZ3JhZGU/PGJyIC8+Jmd0
OyAmZ3Q7ICZndDsgTGV0cyBmaXJzdCBkbyB0aGUgYykgZXhwZXJpbWVudCBhcyB0aGF0IHdp
bGwgbGlrZWx5IGV4cGxhaW4geW91ciBsb2FkIGF2ZXJhZ2UgaW5jcmVhc2UuPGJyIC8+Jmd0
OyAmZ3Q7IC4uLjxiciAvPiZndDsgJmd0OyAmZ3Q7ICZndDtjKS4gSWYgeW91IHdhbnQgdG8g
c2VlIGlmIHRoZSBmYXVsdCBoZXJlIGxpZXMgaW4gdGhlIGJvdW5jZSBidWZmZXIgPGJyIC8+
Jmd0OyAmZ3Q7ICZndDsgYmVpbmcgdXNlZCBtb3JlPGJyIC8+Jmd0OyAmZ3Q7ICZndDsgJmd0
O29mdGVuIGluIHRoZSBEb21VIGIvYyB5b3UgaGF2ZSA4R0Igb2YgbWVtb3J5IG5vdyBhbmQg
eW91IGVuZCB1cCB1c2luZyA8YnIgLz4mZ3Q7ICZndDsgJmd0OyBtb3JlIHBhZ2VzPGJyIC8+
Jmd0OyAmZ3Q7ICZndDsgJmd0O3Bhc3QgNEdCIChpbiBEb21VKSwgSSBjYW4gY29vayB1cCBh
IHBhdGNoIHRvIGZpZ3VyZSB0aGlzIG91dC4gQnV0IGFuIDxiciAvPiZndDsgJmd0OyAmZ3Q7
IGVhc2llciB3YXkgaXM8YnIgLz4mZ3Q7ICZndDsgJmd0OyAmZ3Q7dG8ganVzdCBkbyAob24g
dGhlIFhlbiBoeXBlcnZpc29yIGxpbmUpOiBtZW09NEcgYW5kIHRoYXQgd2lsbCBtYWtlIDxi
ciAvPiZndDsgJmd0OyAmZ3Q7IHRoaW5rIHlvdSBvbmx5IGhhdmU8YnIgLz4mZ3Q7ICZndDsg
Jmd0OyAmZ3Q7NEdCIG9mIHBoeXNpY2FsIFJBTS4gPz9JZiB0aGUgbG9hZCBjb21lcyBiYWNr
IHRvIHRoZSBub3JtYWwgJnF1b3Q7YW1vdW50JnF1b3Q7IDxiciAvPiZndDsgJmd0OyAmZ3Q7
IHRoZW4gdGhlIGxpa2VseTxiciAvPiZndDsgJmd0OyAmZ3Q7ICZndDtjdWxwcml0IGlzIHRo
YXQgYW5kIHdlIGNhbiB0aGluayBvbiBob3cgdG8gZml4IHRoaXMuPGJyIC8+Jmd0OyAmZ3Q7
IDxiciAvPiZndDsgJmd0OyBZb3UgYXJlIG9uIHRoZSByaWdodCB0cmFjay4gTG9hZCB3YXMg
Z29pbmcgZG93biB0byAmcXVvdDtub3JtYWwmcXVvdDsgMTAlIHdoZW4gcmVkdWNpbmc8YnIg
Lz4mZ3Q7ICZndDsgWGVuIHRvIDRHQiBieSB0aGUgcGFyYW1ldGVyLiBMb2FkIHNlZW1zIHRv
IGJlIHN0aWxsIGEgbGl0dGxlLCBsaXR0bGUgYml0IGxvd2VyPGJyIC8+Jmd0OyAmZ3Q7IHdp
dGggWGVuaWZpZWQgS2VybmVsICg4LTklKSwgYnV0IHRoaXMgaXMgZHJhc3RpY2FsbHkgbG93
ZXIgdGhhbiB0aGUgMjAlIHdlIGhhZDxiciAvPiZndDsgJmd0OyBiZWZvcmUuPGJyIC8+Jmd0
OyA8YnIgLz4mZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnIgLz4mZ3Q7ICZndDsgWGVuLWRldmVsIG1haWxpbmcgbGlzdDxiciAv
PiZndDsgJmd0OyBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbTxiciAvPiZndDsgJmd0
OyBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWw8YnIgLz4mZ3Q7IDxiciAv
PiZndDsgPGJyIC8+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxiciAvPiZndDsgWGVuLWRldmVsIG1haWxpbmcgbGlzdDxiciAvPiZndDsg
WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb208YnIgLz4mZ3Q7IGh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbDxiciAvPiZndDsgPGJyIC8+PGJyIC8+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgLz5YZW4tZGV2ZWwg
bWFpbGluZyBsaXN0PGJyIC8+WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb208YnIgLz5o
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWw8YnIgLz48L2Jsb2NrcXVvdGU+
CjwvYm9keT4KPC9odG1sPg==
--=_NUWQF-8k01W10DsG1N5+EZa3ojZPE3HDoZ4sFFhq0eeh0y-I--



--===============7373466658977440381==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7373466658977440381==--



From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:53:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:53:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3W0-0005WP-7R; Mon, 28 Nov 2011 15:53:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RV3Vx-0005W4-Tn
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:53:06 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322495545!4996437!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.6 required=7.0 tests=FROM_EXCESS_QP,HTML_90_100,
	HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30102 invoked from network); 28 Nov 2011 15:52:28 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 15:52:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=E3ljJkY1nh6a1ekrDc6TFJ60ymTpH
	NVrjgfRw2789OE=; b=UpEHSBzzDUsgz60cY6cJ1ku1StCilIQXm6/PEJQ3g/lfF
	IUv7uvineNkOxxw/C/803urhp0ypeIUNDQvvLukGNjDEsyrd42h7D/ZPJJLzhQc/
	t/Cu8VObPs7a/yoMmHUKOZxjcuwlb8qZRMrRJxQR7dtC3Sq+6mB5CPW1M7XMM0=
Received: (qmail 8419 invoked from network); 28 Nov 2011 16:52:24 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@84.46.8.102)
	by mail.zeus06.de with ESMTPA; 28 Nov 2011 16:52:24 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 4A1922C51B;
	Mon, 28 Nov 2011 16:52:24 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id MOxy+90bRDZu; Mon, 28 Nov 2011 16:52:17 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 99DAD2C51A;
	Mon, 28 Nov 2011 16:52:17 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>, 
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Mon, 28 Nov 2011 16:52:17 +0100
Mime-Version: 1.0
In-Reply-To: <20111128152829.GC9655@andromeda.dapyr.net>
References: <20111128152829.GC9655@andromeda.dapyr.net>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ed3ae31.27d6.75459bdc74d06555@uhura.space.zz>
Cc: =?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7373466658977440381=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============7373466658977440381==
Content-Type: multipart/alternative; 
 boundary="=_NUWQF-8k01W10DsG1N5+EZa3ojZPE3HDoZ4sFFhq0eeh0y-I"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_NUWQF-8k01W10DsG1N5+EZa3ojZPE3HDoZ4sFFhq0eeh0y-I
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,=0D=0A=0D=0A=C2=A0=0D=0Alet me try to explain a bit more. Here you see=
 the output of my xentop munin graph for a=0D=0A=0D=0Aweek. Only take a l=
ook at the bluish buckle. Notice the small step in front=3F So it's the C=
PU=0D=0A=0D=0Apermille used by the DomU that owns the cards. The small bu=
ckle is when I only put in=20=0D=0A=0D=0Aone PCI card. Afterwards it's co=
nstantly noticable higher load. See that Dom0 (green) is=20=0D=0A=0D=0Ano=
t impacted. I am back to the Xenified kernel, as you can see.=0D=0A=0D=0A=
=C2=A0=0D=0A=0D=0A=C2=A0=0D=0AIn the next picture you see the output of x=
enpm visualized. So this might be an indicator that=0D=0A=0D=0Arealy some=
thing happens. It's only the core that I dedicated to that DomU. I have a=
 three-core=0D=0A=0D=0AAMD CPU by the way:=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=C2=
=A0=0D=0AIn CPU usage of the Dom0, there is nothing to see:=0D=0A=0D=0A=C2=
=A0=0D=0A=0D=0A=C2=A0=0D=0AIn CPU usage of the DomU, there is also not mu=
ch to see, eventually a very slight change of=0D=0A=0D=0Amix:=0D=0A=0D=0A=
=C2=A0=0D=0A=0D=0A=C2=A0=0D=0AThere is a slight increase in sleaping jobs=
 at the time slot in question, I guess nothing we ca=0D=0A=0D=0Adirectly =
map to the issue:=0D=0A=0D=0A=C2=A0=0D=0A=0D=0A=C2=A0=0D=0AIf you need ot=
her charts, I can try to produce them.=20=0D=0A=0D=0A=C2=A0=0D=0ABR,=0D=0A=
Carsten.=0D=0A=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-----=0D=
=0AAn:Carsten Schiers <carsten@schiers.de>; zhenzhong.duan@oracle.com; le=
rsek@redhat.com;=20=0D=0ACC:xen-devel <xen-devel@lists.xensource.com>; ko=
nrad.wilk <konrad.wilk@oracle.com>;=20=0D=0AVon:Konrad Rzeszutek Wilk <ko=
nrad@darnok.org>=0D=0AGesendet:Mo 28.11.2011 16:33=0D=0ABetreff:Re: [Xen-=
devel] Load increase after memory upgrade (part2)=0D=0AOn Fri, Nov 25, 20=
11 at 11:11:55PM +0100, Carsten Schiers wrote:=0D=0A> I got the values in=
 DomU. I will have=0D=0A>=20=0D=0A> =C2=A0 - aprox. 5% load in DomU with =
2.6.34 Xenified Kernel=0D=0A> =C2=A0 - aprox. 15% load in DomU with 2.6.3=
2.46 Jeremy or 3.1.2 Kernel with one card attached=0D=0A> =C2=A0 - aprox.=
 30% load in DomU with 2.6.32.46 Jeremy or 3.1.2 Kernel with two cards at=
tached=0D=0A=0D=0AHA!=0D=0A=0D=0AI just wonder if the issue is that the r=
eporting of CPU spent is wrong.=0D=0ALaszlo Ersek and Zhenzhong Duan have=
 both reported a bug in the pvops=0D=0Acode when it came to account of CP=
U time.=0D=0A=0D=0A>=20=0D=0A> I looked through my old mails from you and=
 you explained already the necessity of double=0D=0A> bounce buffering (P=
CI->below 4GB->above 4GB). What I don't understand is: why does the=0D=0A=
> Xenified kernel not have this kind of issue=3F=0D=0A=0D=0AThat is a puz=
zle. It should not. The code is very much the same - both=0D=0Ause the ge=
neric SWIOTLB which has not changed for years.=0D=0A>=20=0D=0A> The drive=
r in question is nearly identical between the two kernel versions. It is =
in=0D=0A> Drivers/media/dvb/ttpci by the way and when I understood the co=
de right, the allo in=20=0D=0A> question is:=0D=0A>=20=0D=0A> =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 /* allocate and init buffers */=0D=0A> =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 av7110->debi_virt =3D pci_alloc_consistent(pdev, 8192, &av7110->d=
ebi_bus);=0D=0A=0D=0AGood. So it allocates it during init and uses it.=0D=
=0A> =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!av7110->debi_virt)=0D=0A> =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 goto err_saa71466_vfree_4;=0D=
=0A>=20=0D=0A> isn't it=3F I think the cards are constantly transferring =
the stream received through DMA.=20=0D=0A=0D=0AYeah, and that memory is s=
et aside for the life of the driver. So there=0D=0Ashould be no bounce bu=
ffering happening (as it allocated the memory=0D=0Abelow the 4GB mark).=0D=
=0A>=20=0D=0A> I have set dom0_mem=3D512M by the way, shall I change that=
 in some way=3F=0D=0A=0D=0ADoes the reporting (CPU usage of DomU) change =
in any way with that=3F=0D=0A>=20=0D=0A> I can try out some things, if yo=
u want me to. But I have no idea what to do and where to=0D=0A> start, so=
 I rely on your help...=0D=0A>=20=0D=0A> Carsten.=0D=0A>=20=0D=0A> -----U=
rspr=3Fngliche Nachricht-----=0D=0A> Von: xen-devel-bounces@lists.xensour=
ce.com [mailto:xen-devel-bounces@lists.xensource.com] Im Auftrag von Konr=
ad Rzeszutek Wilk=0D=0A> Gesendet: Freitag, 25. November 2011 19:43=0D=0A=
> An: Carsten Schiers=0D=0A> Cc: xen-devel; konrad.wilk=0D=0A> Betreff: R=
e: [Xen-devel] Load increase after memory upgrade (part2)=0D=0A>=20=0D=0A=
> On Thu, Nov 24, 2011 at 01:28:44PM +0100, Carsten Schiers wrote:=0D=0A>=
 > Hello again, I would like to come back to that thing...sorry that I di=
d not have the time up to now.=0D=0A> >=20=0D=0A> > =3F=3F=0D=0A> > We (n=
ow) speak about=0D=0A> >=20=0D=0A> > =3F=3F=0D=0A> > *Xen 4.1.2=0D=0A> > =
*Dom0 is Jeremy's 2.6.32.46 64 bit=0D=0A> > *DomU in question is now 3.1.=
2 64 bit=0D=0A> > *Same thing if DomU is also 2.6.32.46=0D=0A> > *DomU ow=
ns two PCI cards (DVB-C) that o DMA=0D=0A> > *Machine has 8GB, Dom0 pinne=
d at 512MB=0D=0A> >=20=0D=0A> > =3F=3F=0D=0A> > As compared to 2.6.34 Ker=
nel with backported patches, the load on the DomU is at least twice as hi=
gh. It=0D=0A> >=20=0D=0A> > will be "close to normal" if I reduce the mem=
ory used to 4GB.=0D=0A>=20=0D=0A> That is in the dom0 or just in general =
on the machine=3F=0D=0A> >=20=0D=0A> > =3F=3F=0D=0A> > As you can see fro=
m the attachment, you once had an idea. So should we try to find somethin=
g...=3F=0D=0A>=20=0D=0A> I think that was to instrument swiotlb to give a=
n idea of how=0D=0A> often it is called and basically have a matrix of it=
s load. And=0D=0A> from there figure out if the issue is that:=0D=0A>=20=0D=
=0A> =C2=A01). The drivers allocoate/bounce/deallocate buffers on every i=
nterrupt=0D=0A> =C2=A0 =C2=A0 (bad, driver should be using some form of d=
ma pool and most of the=0D=0A> =C2=A0 =C2=A0 ivtv do that)=0D=0A>=20=0D=0A=
> =C2=A02). The buffers allocated to the drivers are above the 4GB and we=
 end=0D=0A> =C2=A0 =C2=A0 up bouncing it needlessly. That can happen if t=
he dom0 has most of=0D=0A> =C2=A0 =C2=A0 the precious memory under 4GB. H=
owever, that is usually not the case=0D=0A> =C2=A0 =C2=A0 as the domain i=
susually allocated from the top of the memory. The=0D=0A> =C2=A0 =C2=A0 f=
ix for that was to set dom0_mem=3Dmax:XX. .. but with Dom0 kernels=0D=0A>=
 =C2=A0 =C2=A0 before 3.1, the parameter would be ignored, so you had to =
use=0D=0A> =C2=A0 =C2=A0 'mem=3DXX' on the Linux command line as well.=0D=
=0A>=20=0D=0A> =C2=A03). Where did you get the load values=3F Was it dom0=
=3F or domU=3F=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> >=20=0D=0A> > =3F=3F=0D=
=0A> > Carsten.=0D=0A> > =3F=3F=0D=0A> > -----Urspr=3F=3Fngliche Nachrich=
t-----=0D=0A> > An:konrad.wilk <konrad.wilk@oracle.com>;=20=0D=0A> > CC:l=
inux <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com>;=20=
=0D=0A> > Von:Carsten Schiers <carsten@schiers.de>=0D=0A> > Gesendet:Mi 2=
9.06.2011 23:17=0D=0A> > Betreff:AW: Re: Re: Re: AW: Re: [Xen-devel] AW: =
Load increase after memory upgrade=3F=0D=0A> > > Lets first do the c) exp=
eriment as that will likely explain your load average increase.=0D=0A> > =
=2E..=0D=0A> > > >c). If you want to see if the fault here lies in the bo=
unce buffer=20=0D=0A> > > being used more=0D=0A> > > >often in the DomU b=
/c you have 8GB of memory now and you end up using=20=0D=0A> > > more pag=
es=0D=0A> > > >past 4GB (in DomU), I can cook up a patch to figure this o=
ut. But an=20=0D=0A> > > easier way is=0D=0A> > > >to just do (on the Xen=
 hypervisor line): mem=3D4G and that will make=20=0D=0A> > > think you on=
ly have=0D=0A> > > >4GB of physical RAM. =3F=3FIf the load comes back to =
the normal "amount"=20=0D=0A> > > then the likely=0D=0A> > > >culprit is =
that and we can think on how to fix this.=0D=0A> >=20=0D=0A> > You are on=
 the right track. Load was going down to "normal" 10% when reducing=0D=0A=
> > Xen to 4GB by the parameter. Load seems to be still a little, little =
bit lower=0D=0A> > with Xenified Kernel (8-9%), but this is drastically l=
ower than the 20% we had=0D=0A> > before.=0D=0A>=20=0D=0A> > ____________=
___________________________________=0D=0A> > Xen-devel mailing list=0D=0A=
> > Xen-devel@lists.xensource.com=0D=0A> > http://lists.xensource.com/xen=
-devel=0D=0A>=20=0D=0A>=20=0D=0A> _______________________________________=
________=0D=0A> Xen-devel mailing list=0D=0A> Xen-devel@lists.xensource.c=
om=0D=0A> http://lists.xensource.com/xen-devel=0D=0A>=20=0D=0A=0D=0A_____=
__________________________________________=0D=0AXen-devel mailing list=0D=
=0AXen-devel@lists.xensource.com=0D=0Ahttp://lists.xensource.com/xen-deve=
l=0D=0A
--=_NUWQF-8k01W10DsG1N5+EZa3ojZPE3HDoZ4sFFhq0eeh0y-I
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv
bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+PGh0bWw+
CjxoZWFkPgogIDxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iWmFyYWZhIFdlYkFj
Y2VzcyB2Ny4wLjItMjk0NzAiPgogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4KICA8dGl0bGU+QVc6IFtYZW4t
ZGV2ZWxdIExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5IHVwZ3JhZGUgKHBhcnQyKTwvdGl0
bGU+CiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4KICAgICAgYm9keQ0KICAgICAgew0KICAg
ICAgICBmb250LWZhbWlseTogQXJpYWwsIFZlcmRhbmEsIFNhbnMtU2VyaWYgISBpbXBvcnRh
bnQ7DQogICAgICAgIGZvbnQtc2l6ZTogMTJweDsNCiAgICAgICAgcGFkZGluZzogNXB4IDVw
eCA1cHggNXB4Ow0KICAgICAgICBtYXJnaW46IDBweDsNCiAgICAgICAgYm9yZGVyLXN0eWxl
OiBub25lOw0KICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjZmZmZmZmOw0KICAgICAgfQ0K
DQogICAgICBwLCB1bCwgbGkNCiAgICAgIHsNCiAgICAgICAgbWFyZ2luLXRvcDogMHB4Ow0K
ICAgICAgICBtYXJnaW4tYm90dG9tOiAwcHg7DQogICAgICB9DQogIDwvc3R5bGU+CjwvaGVh
ZD4KPGJvZHk+CjxwPkhpLDwvcD48cD4mbmJzcDs8L3A+PHA+bGV0IG1lIHRyeSB0byBleHBs
YWluIGEgYml0IG1vcmUuIEhlcmUgeW91IHNlZSB0aGUgb3V0cHV0IG9mIG15IHhlbnRvcCBt
dW5pbiBncmFwaCBmb3IgYTwvcD48cD53ZWVrLiBPbmx5IHRha2UgYSBsb29rIGF0IHRoZSBi
bHVpc2ggYnVja2xlLiBOb3RpY2UgdGhlIHNtYWxsIHN0ZXAgaW4gZnJvbnQ/IFNvIGl0JiMz
OTtzIHRoZSBDUFU8L3A+PHA+cGVybWlsbGUgdXNlZCBieSB0aGUgRG9tVSB0aGF0IG93bnMg
dGhlIGNhcmRzLiBUaGUgc21hbGwgYnVja2xlIGlzIHdoZW4gSSBvbmx5IHB1dCBpbiA8L3A+
PHA+b25lIFBDSSBjYXJkLiBBZnRlcndhcmRzIGl0JiMzOTtzIGNvbnN0YW50bHkgbm90aWNh
YmxlIGhpZ2hlciBsb2FkLiBTZWUgdGhhdCBEb20wIChncmVlbikgaXMgPC9wPjxwPm5vdCBp
bXBhY3RlZC4gSSBhbSBiYWNrIHRvIHRoZSBYZW5pZmllZCBrZXJuZWwsIGFzIHlvdSBjYW4g
c2VlLjwvcD48cD4mbmJzcDs8L3A+PHA+PGltZyBhbHQ9IiIgc3JjPSJkYXRhOmltYWdlL3Bu
ZztiYXNlNjQsaVZCT1J3MEtHZ29BQUFBTlNVaEVVZ0FBQWZFQUFBR0VDQUlBQUFDcHY0NVlB
QUFnQUVsRVFWUjRuTzI5ZjNSVTFiMzN2OE1rRUFKbVFpQ1dZRG9RTVNRd2t5QWRpajhlOWZI
YmRhdFdYYWdGTHZXcXZiMjFwYmY0STRCV3k3SUw1MUdxVDRVU2JUQmxsaFhTYUJETVRFS0NY
TFdJSkNwM0dSMm9UUUVSRTJoUmhKbE15SS85ejEzcitlTjgvOWpKenM3WjU1elpjMmJPelBu
eGVhMVpzMmJPZk00NW43Tm5uL2U4WjgrWnowWi9CUUFBQUd4QloyY255bllPQUFBQVFCcm83
T3pjdVhQbnFLWmpBQUFBd01yczNMa1ROQjBBQU1BbWdLWURBQURZQjlCMEFBQUErd0NhRGdB
QVlDVmFPTmhYUWRNQlFCbUVVTFpUU0FJelpHdUdISnpEeU1nSVVYUFFkTUFPR0NjZmRNdjhn
N1JzMWlETW9LZG15TUVoREEwTmZmcnBwNkZRNlB6NTg2MnRyZXhMb09uTzRyNzc3dnZwVDMv
S0x2bVAvL2lQKysrL1A1VnRJb1FRUWprNU9aZGRkbGxOVGMzNjlldlBuajJiV3BwcFJsRnJF
a3AyaWdxVllZRXpnNTZhSVFjbmNQTGt5WTZPanE2dXJ0T25UN2UydG43NjZhZnNxNkRwemlJ
YWpTNWF0R2puenAzazZhdXZ2dXIxZW1PeFdDcmJwR2R5TkJyOTZLT1Bmdm5MWDVhV2xwNDRj
U0xWWE5NSGFMcHpjbkFDNzcvLy92bno1OVZlQlUxM0hFZVBIdjNXdDc1MTdOaXhZOGVPelo0
OW03enZRME5ER3pac21EVnIxdFNwVTFlc1dISGh3Z1VTakJCNjhjVVhQUjVQWGw1ZVRVM05r
U05IK0EzeVovS1RUejc1b3gvOWlEenU3Ky8vOTMvLzk4c3V1K3l5eXk3N3lVOSswdC9mVDll
cXE2dWJPM2Z1NU1tVEZ5NWMrSmUvL0dYSGpoM3o1ODhuTy9yNDQ0OUoyTi8vL3ZjZi9PQUgw
NlpObXpKbHl2ZS8vLzB6Wjg3SWRxb3ZRN29RTWZCYjVoL3c4WW9aYW14V28wRVNIb2dHQ0tG
bm4zMjJwS1Nrb0tEZy92dnZqOGZqR09QcnI3OSsxNjVkTk9ia3laT3paODltNWFDOHZQeVRU
ejRoajNmczJFRWVmUExKSitYbDVWaTlWMmowRnZMZ2d3OCttRE5uenU5Kzk3dWtEZ0ZJQzZE
cFR1UlBmL3FUMSt2MWVyMk5qWTFreVc5Kzg1dnZmZTk3cDA2ZHVuRGh3bjMzM2Zlem4vMk1M
RWNJclZpeDRvc3Z2b2hHbzA4OTlaVGY3K2UzeGl2bXlaTW52L1d0YjVISGp6NzY2SzIzM25y
bXpKbSt2cjUvK1pkL3FhMnRwV3N0WDc3ODg4OC9qMGFqVHovOTlQVHAwKys1NXg3NjlMdmYv
UzRKcTZxcWV1dXR0Mkt4MlBuejU5ZXVYYnQ2OVdyWlR2VmxpTlY5dXNoNGVuMTkvVzIzM1Nh
WW9leXBSb01rUEJBTkVFSmtzMmZPbkxuMTFsdlhyVnVITVc1cmE2dXNyQndlSGlZeFAvN3hq
NTk1NWhsMnJaLy8vT2QxZFhVWTQxT25UazJmUHAybzg3WnQyOWFzV1lQVmU0VkdiOEVZdDdT
MHpKbzFhOCtlUFVubEQ0Z0QxNzBBQ2l4WnNtVHAwcVgwcWNmak9YYnNHSG5jMTlkMytlV1hr
OGNJb1hQbnpwSEgwV2cwTnplWDN4UXZlWmN1WGNyTHl5T1BTMHRMUC92c00vTDRyMy85NjV3
NWMraGEvL3puUCttV1pVOFZkeFNOUm1mTm1pWGJxYjRNY1FxYTN0SFJzWGp4WW1wT0UyWW9l
NnJSSUFrUFJBT0UwTi8rOWpmeStMUFBQcnZpaWl2SVk3L2YvK3FycjlLRjBXaVVYV3Z2M3Iw
clZxekFHRC96ekRPelpzM2F2bjA3eHZpSFAvemhtMisraWRWN2hVWnYrZjN2ZjE5YVd0cloy
WmxVOG9BTzRMb1hZSndkTzNaY2ZmWFZWMTk5OVovKzlDZXlKRGMzbHgwdXlNbkpJY3ZWaEVs
N0lmbU9UeDY3WEs2aG9TSHllSEJ3a0VxVjlwYnAwL2ZlZSsrNjY2NHJLQ2hRUzB3a3cwbVRK
dEVjQ0VORFE1TW1UZExlZ3VJdVB2MzAwL256NTdPL0ZpVE1VUFpVWDRQUWhleDRqdXdseGMz
dTJiT25vcUppYUdobzFhcFZXN1pza2ExMThlTEZiMy83MnhoanI5Y2JDb1d1dWVZYWpQRzN2
LzF0SXYxcXZVS2p0OHliTisreHh4N2owd1BTQzF6M0Fveno2YWVmbHBhVy92M3ZmKy9wNlNr
dExUMTY5Q2pHdUt5czdJc3Z2dUNEOVduNmswOCtlZSs5OTVMSHBhV2wxRC8rOWE5L0xTMHRG
ZGt5ZlRwbnpwekd4c2J6NTgrUGpJeDg4ODAzQ1UyMFlvWWVqK2UvLy91LzJTVWZmZlNSeCtQ
UjNnTC80TXlaTXhVVkZRY1BIbVRqRTJZb2U2cXZRUkxDK3ZTLy9lMXYxUDZQakl4NHZkN2Ey
bHFQeHpNd01NQ3ZlT09OTi83NXozOG1RejErdjMvUG5qMDMzWFFUZVVtdFYyajBsbE9uVGwx
NTVaV2JOMjlPS25rZ0tlQzZGMkNjYURTNmNPSENOOTU0Z3p4OS9mWFh5WFV2VHovOTlLMjMz
dHJUMHpNNE9Qanh4eCtUNytNNFNVMG4xNzJzWGJ1V3ZlN2w0WWNmcHVPODMvLys5eDk1NUJH
UkxkT25NMmJNMkxOblR6d2UvL3ZmLzc1aXhRcDltdjUvL3MvL1diSmt5ZnZ2dngrUHgrUHgr
S0ZEaHhZdlhreDF4KzEyMDVFRXhTM1RCOS85N25mcEQ0a1V0UXpWTnF1dlFSS0NFUHJCRDM1
dzl1elpzMmZQM25iYmJYU1lIbVBjMk5pSUVIcjU1WmNWVjN6bW1XZm16SmxETFB3TEw3eHd4
UlZYUFB2c3MrUWx0VjZoM1Z0T256NWRVVkVSQ0FTU3loOFFCNjU3QWNhNTc3NzdxSWdRZnZu
TFg5NTMzMzNEdzhPQlFJQmNkTEZvMFNMNjI2bjRnRUJPVHM2MGFkT3FxNnZYclZ0SHIwN0JH
TWRpc1FjZWVHRDY5T25UcDA5LzRJRUg2SFdUZ3ByK3hodHZ6SnMzeitWeWZmdmIzOTZ5Wllz
K1RSOFpHZG15Wll2WDY1MHlaY3FVS1ZPOFh1L3ZmLzk3K3VxbVRadW1UWnVtc1dYMkFZdDJo
bXFiMWRjZ0NVSE1kUy8zM1hjZnZad0dZL3phYTYvTm56OS9jSEJRY2NValI0N2s1dWFTdnhT
Y09YTW1OemVYZnFkUjZ4VUplMHR2YjI5bFplVnZmdk9icEE0QlNBdWc2UUJnYzI2Ly9YYjZq
d1RBQnNCMUx3RGdVSWFIaCt2cjY2dXFxdWpsaklBTmtJazRhRG9BT0FXRWtNZmpnU3NMYlVa
cmErdWxTNWZJNDB1WExzRjFMd0FBQUJhbXM3UHprMDgrR1J3Y0hCd2MvT1NUVDdxNnV0aFhR
ZE1CQUFDc1JIOS8vK0hEaDhQaGNEZ2M3dXpzWkg4UHg2RHBBQUFBbGdiRzB3RUFBT3dEYURv
QUFJQ0ZjZEMxakQwSER2UWNPSkR0TEFBQUFES0hiVFY5TUI3ZmR0MTEyNjY3YmpBZXozWXVB
QUFBR2NLMm12NlgzLzB1NFBFRVBKNi9RQ1YrQUFDY2lrMDAvZnlwVTVzcktvaW1iNjZvT0gv
cVZMWXpBZ0FBTUlSWUxOYloyVW12WlpUTlBaa2RUVzlxYXFxcXFzckx5NnV1cnU3bzZNQVlm
L0hGRjlkZWUrM2t5Wk92dmZaYVVzWlRaTW40Qmg5NGdBZzZ1VFU5OEVER2pnVUFBQ0NUSER4
NDhOaXhZNWN1WGJwMDZkTFJvMGRseForem8rbjMzSE5QZDNkM2YzLy85dTNiWjg2Y2lURmV1
WExsaGcwYit2djdOMnpZc0dyVktzRWxNcDU0NGdueTRQVHAweUpwWElwRVJNSkV0aWE0UjVF
d3lFbzhETElTRHpOblZsZ3NzVFR1MFp4WkpVVW9GS0lGZklhSGgwT2hFUHRxbHNkZVRwdzRR
YVltbURselpsOWZIOGE0cjYrUHFMeklFaGxVMHovODhFT1J2WCt6ZmJ0SW1NaldCUGNvRWda
WmlZZEJWdUpoNXN3S2l5V1d4ajJhTTZ1a01LTlBKL1QyOWk1WnNtVHYzcjBZNDBtVEpwRlBu
cUdoSVpmTEpiaUVNdlRQZjM3ejBrdVAvL3puK1BCaFNaSUdEeDZVSklrODFyai9mN0ZZd2hq
QnJRbnU4WC8rNTM4Z0s4Z0tzbUx2aHpvNk1ybEg4MlQxLytMeGIxNTZhYUM3TzFubGpFYWpw
aHRQeHhoM2RuWjZQSjVYWG5tRlBDMHVMcFo1Y0pFbE1wNTQ0Z2xKa2lSSjZ1M3RsUVRBWFYw
aVlTSmJFOXlqU0Joa0pSNEdXWW1IbVRNclNTeXhOTzdSVkZrWklhM1owZlQ2K3ZxU2twSjkr
L2JSSlN0V3JLQmo1V1FxTEpFbE1xaW1Bd0FBbUI5OSttbkc2MTVrYzRCZHZIang4ODgvWDda
c1dWNWUzalhYWEhQcTFDbU1zY2dTR2VEVGRjUUloa0ZXNG1HUVZWSmg0Tk9UeGJ6ajZXa0hm
RG9BQUJaQ245Q1orcnFYOUFJK1hVZU1ZQmhrSlI0R1dTVVZCajQ5V2NDbkF3QUFtQkY5UW1m
UzYxNk1BSHk2amhqQk1NaEtQQXl5U2lvTWZIcDZzYWVtQXdBQW1COTlRdWVJK3VtWExsMDZj
ZUxFVDMvNlUwbVMrdnI2ZW50NysvcjZ5R09OK3hNZEhRbGpCTGNtdU1jalI0NUFWcEFWWk1Y
ZTQ2NnVUTzdSUEZsOThjVVhKMDZjMEZFNVFDYmlNbXlpNlFUdzZRQUFXQWg5UXVkRVRZZnhk
UEVZd1RESVNqd01za29xRE1iVGs4V0ptZzRBQUdCK2pKQkJlMm82K0hUeEdNRXd5RW84RExK
S0tneDhlbnF4cDZZREFBQ1lIeDBxOTlaYmIzVjNkL2YxOVEwTkRTa0daTG5lQzEzUzNOeGNY
bDd1Y3JubXpadlgzTnlNazV6bmlBQStYVWVNWUZqR3NrSjF5SVJaSlJVR1dTVVZCajQ5S2I3
NTVwdWVucDVEaHc2MXRyWWVPblNvcDZmbm0yKytZUU95NmROWlRTOHNMQXlIdy9GNFBCUUt1
ZDF1ckhlZUk1RW1Cc3dNMVhRQXNEMnA2T2ZnNEdCZlgxOTNkL2RiYjczRkxqZUxwdnQ4dm5B
NFBEQXdFQXFGYW1wcXNONTVqa2hMZ1U4WGp4RU15MHhXcUE0RkFnR3paWlZzR0dTVlZCajQ5
UFJpRmswL2ZQaHdZV0VoUXFpd3NQRHc0Y000dFhtTzRONmk5NmdPZFpSdE1rTW1jQS8zUnQv
cm51ZElHN05vK3Z6NTgrbll5MVZYWFlWaG5xTjBiTXB5V2FFNkZFUkJzMldWYkJoa2xWUVkr
UFQwWWhaTkx5b3FvbU12TTJiTXdERFBrU01KQkFMK01VMEhBTnVURmlFMVJiMFgyVHhIR09P
bXBpYVB4K055dWViT25mdjY2NjlqbU9jb0hadXlYRlpCRlBTRFQwOHlSakRNbkZsSjROTlR4
aFNhYmhEZzA2MU9FQVdsQ0Z6M0FqZ0ZmVUxuaUxxTUJQRHBPbUlFd3pLVGxSOEZwUUJjbjU1
Y2pHQ1lPYk9Td0tlbmpDTTBIYkFvcktackE1ZXhBellnTGJybkNFMEhueTRlSXhobU5wOU9M
bzl4Y2xzbEcyYk9yQ1R3NmVuR0pwb3VteE1EN3ExNnY5a3JCWkJJNUYzZWh1eG5DL2R3bjhL
OTdqa3hZckVZekVlcWpEbWRpNk96Q2lCQm4rNEhuNTVrbURtemtzQ25KOC9CZ3dlUEhUdDI2
ZEtsUzVjdUhUMTY5T0RCZyt5cjl0UjB3S293bXE0TlhNWU8yQUI5UWhjS2hjZy82akhHdzhQ
RG9WQ0lmZFdlbWc0K1hUeEdNQ3hEL3lOZHMxLzB1cGNBeWxoV3lZWkJWa21GZ1U5UEZ2RHBn
R1ZnTlQwQmdtRUFZR0wwQ1YwMEdvWHhkSlVHTmFWemNYSlc0Tk4xeEFpR21UTXJDWHg2dWpI
TG5CakR3OE1iTjI0c0xTM055Y2toeTFPWkV3T3dLT0RUQVVlaFR6L04rejlTVnRNM2JkcTBZ
TUdDN3U3dWtaRVJzaVNWT1RIQXA0dkhDSWFCVHhjUGc2eVNDZ09mbml4RXhLbVVtMVRUUFI2
UDdOZmJWT2JFQUN3SytIVEFVZWhUem5BNGZPSENoVkFvOU0wMzMzenp6VGR0Ylczc3EyYlJk
SmZMOWRCREQwMmRPdFhqOGV6WnN3ZW5OaWRHMzk2OWtrQk5ldHpWSlZLOVhtUnJnbnZzN2Uy
RnJEUmkwSnI5K05FeW9hd0N5T0Z0Wlkrc0pFbnEvK01mTTdsSDgyU2xlMDZNVHo3NXBMVzE5
ZVRKazIrOTlWWTRIRDUrL0RqN3FsazBmZWJNbWFGUWlNeUpNV3ZXTEp6YW5CaUFSUUdmRGpn
S0kzVFZMSnErYXRXcVVDaEU1c1FvS1NuQnFjMkpBZVBwNGpHQ1lUQ2VMaDRHV1NVVkJ1UHB5
V0xHMzBqNU9URk9uejU5d3cwMzVPWGxsWmVYazRIMVZPYkVBQ3dLK0hUQVVSaWhybkI5ZW1M
QVQwbmcwNU1KZzZ5U0NnT2ZubDdzcWVtQVJRR2ZEamdLSTJUUW5wb09QbDA4UmpBTWZMcDRH
R1NWVkJqNDlQUmlUMDBITEFyNGRIRmdwaWNib0Uvb29INjZlb09hMHJrNE9Tdnc2ZUl4Z1VE
QWhGbnBDQU9mbml5T3FNc0k4eHpaNDk2N1lZL2dQRWQ5bTcxWnp6Ykw5MTdIdDRERjczWFBj
d1QxMDFVeHAzTnhjbGJnMDVPSVFVZ29MTU5aSlI4R1BqMVpIT0hUQ1RDZWJuVmdQRDBKa09O
YndQcm9FenFvbjY3ZW9LWjBMazdPQ254NkVqSGcwM1dGbVNvckkyVFFucG9PV0JUdzZVa0FQ
dDM2NkJNNk05WUdNQWp3NlRwaUJNUEFwNHVIZ1U5UEtneDhlcktZc1g0NlA4OFJZZVBHalhR
aHpIUGtRRmhOUjNWSTZ4SnM4T25nMDYyUFB2MDBvNllUWkpyZTFkVTFlL1pzdWhEbU9VcDlV
NWJMaXRYMGQzdDlhcHFPNmhENGRQRHArc0pNbFpVKzViU0dwdmYzOTN1OTNnTUhEdENGTU0r
UkEyRTEzWStDUVJSVURodlRkRWNEUHQzNnBFVklUYXJwYTlldWZmNzU1OW1GTU0rUkE3Tmk1
em02eTlld3ZteVRZbVRQNFRLWTUwaEN5SXhaSmRsV0VzeHpsUHc4UnpKTXF1azVPVG15aXVv
d3o1RURrZmwwdjRwUDk2TWcrSFR3NlRaQW4zS2E5N29YL2pkU2RpSE1jNVQ2cGl5WDFZVHJY
amI3Wk1KTmg5ZXBwanU1clNRMC9odXlpYkpLUGd6RzAxUEVGSnJPejNQRXZrUWV3RHhIRG1U
Qzlla0IrYUE1SFY0SG55NUpFelFkc0NocGtWTlRhTHBCZ0UvWEVTTVlaZ2FmUHY2VGFRQkpB
WVRxa0pQYlNrS0lEcitZS0t2a3c4Q25weGQ3YWpwZ1VSUjlPcjFRM1Q5UjA5V3VpbkVLaktZ
REZrV2YwSmwzUEQzdGdFL1hFU01ZbGtXZnJxYnBmaFIwY2x1QlQ5Y1hacXFzakpCQmUybzZZ
RkVVZlhwdzdFSjFYdE96azZWSkFKOXVmZlFKblNOOHVteE9qTjdlWHBHYTlDYzZPaExHQ0c1
TmNJOUhqaHlCckRSaTJEa3hqangvTzNuc1I4Rzd2QTJvRHQzbGJSaU5ES0MrelY0L0NqcTVy
ZnE4WGdraDAyV1ZaRnYxOWZYaHJpN2RlMFIxS05rOUNtYTFmR09aMGUyZ2UwNE1qUEhBd01B
Nzc3elQydHA2OXV4WjJVczIwWFFDK0hTcm8ralR5WVhxUWZaYUYvS1N3eTk5QVo4dUdYbVJm
a2JhVnAvUUVVRS9kdXpZVjE5OXRXL2Z2dlBuejdPdjJsUFQ2UUNXOXNWZTVoeGhkSEpXaXVQ
cDVNcEZ2NUttTzdtdFlEeGRrdVRLbTg3eDlMS3lkRzBxN2VQcGI3LzlOcFhyTDcvOHNxT2pn
MzNWbnBvK0RoZ1pTNkY4ZlRvZFBRZWZ6Z0krWFVyL0NUNWVEZFRFUGwybTFjZVBIMmVmSnRE
MGd3Y1BWbFJVNU9Ua1lJeFhyMTdkMk5pb0w0bk1vSERkaStZYlkwN240dVNzbEs5UG42anBv
d1c4d0tlRFQ1Y004T2tJa1Q5em1kbW5wL1FiNlZWWFhkWFcxa2IrMi9uNTU1L1BuVHRYWHhL
WkFYeTYxZEh3NmZScElCQUFueTVKNCtxVDdUeXlTdHBQY0lRa2hBS0JnSmw5ZWtxMWR2UHk4
dUx4T05IMGMrZk9GUlFVNkV0Q0JsOFZvS21wcWFxcUtpOHZyN3E2bWd3UHBUSW5ocS9PTi80
T2FUU29LWjJMazdOQ2EvYWpOZnRId3liNmRQYlNSdkRwa2pUbTB4RXlWMWJKaDVuUXAwdkk3
RDRkNjliMG0yKytlY2VPSFFpaDA2ZFByMTY5ZXZueTVmcVNVSVRWOUh2dXVhZTd1N3UvdjMv
Nzl1Mms1bUlxYzJLTXY5UGcweTBGcSttS1BoM1ZqUTNDZ0U5bk5OMjVHT1BUTTlhdytwUXpK
VTAvZmZyMG5YZmVXVkJRVUZCUXNIejU4bi84NHgvNmtsQkVzUzdqaVJNblBCNFBUbTFPakY2
ZmIvUzNEdkRwYWRxVVNYeTZUTk9kM0ZiZzB5WEpvVDVkRzNQVjJ1M3Q3VjJ5Wk1uZXZYdHhh
bk5pNExJeVZJZnVmcktNblRjQTdzMS9qOWJzdi91QmJhTkxBbWgwZm94SHkwWWZCMUJIMlNZ
L0NvNHZNVUhPV2JzbnV1UHdIbDZXN2o1QVd6WHRXK2J1ZGMrSllkNy9rY28wdmJPejArUHh2
UExLSytScEtuTmk5UHA4SWwrZ3pPbGNuSnhWUXA4K09sRUcrSFFKZkxva1NZNzI2U01qSTdK
QkdJS3lwaU4xVWtsQ0JydTErdnI2a3BLU2ZmdjIwU1dwekltUjRVRXhJRjBrSEUrZk1KZ080
K25RdzQwZlR6ZjB5aUxkNGprME5QVHBwNStHUXFIejU4KzN0cmF5TDVsbFRnelprb3NYTDZZ
eUp3YjRkUEVZd1REeitIVDJxWlBiQ255NkpHWEVwNnRyU0xaOCtzbVRKenM2T3JxNnVrNmZQ
dDNhMnZycHA1K3lyOXIwZjZUZzA2MEorUFFrZ0I0dVplUzZsNG03U0s5dDF5ZDA3Ny8vdnF6
R0MwczJ4MTdTRHZoMEhUR0NZU2J4NmJLYms5c0tmTG9rWmNPbk0wL2h1aGZEQVo5dWRYaWZ6
bFlDVUxnNUdlamhVaFo4ZW5yM2FJUU0ybFBUd2FlTHh3aUdaY3VuYTJ1Nms5c0tmTG9rWmMy
bmt4RVlpL2wweFo4dXJUTDJBajdkb2xCTnAxSWVsQTJnZzArblFBK1hzdWZUMDdSZkkyVFFK
ajVkUHMrUnp6YzZDNHpYSzFsdDVoY25aK1hkc0FldDJVL21yeUh6SE4zbGJaQUNxRyt6Vi9I
ZXlXM0Y5bkFUWlpWa1cvV2xOcytSaE5JOXo5RllxK0t5c3ZFbC9CNFJTcjBkVXBublNBT2Jh
RG9CZkxyVm9UNDlJcWxjNkFJK25RSTlYQUtmcmtBQ1RkKzllN2ZINDhuSnliSFcyQXVNcDR2
SENJWmxlRHc5aUlLajE3MUVZRHhkQlJoUGw3SjMzWXR3czJ1SEdTR0RDVFI5NXN5WnI3MzIy
dERRa0JIN1RqdmcwNjBPMWZRRTloeDh1Z1ErWFpLa1RQdjA4YktBMXZYcFJVVkYwV2pVaUIw
YkFmaDBIVEdDWVJuMjZYN3EwelZ2VG00cjhPbVNsSEdmanBEbGZmcFRUejIxY2VQRy92NStJ
L2FkZHNDbld4M3c2VWtBUFZ6SytIZzZHcHRieXJvK3ZibTVlY3FVS1dtL2xwSGZtc2lzUnVM
ekhJRlBGNDhSRE12MDlla0JCRDQ5UVF6NGRDbExQajJaWnRjT1M0dWN5a2lnNlNVbEpjM056
UWFOcDdPYUxqS3JVWEx6SEkzZG5ENWhvNlZnTlIxOGVnTEFwMHZaOGVscGJIWWpkRFdCcGhj
V0ZobzNuczVxdXNpc1Jrbk5jeVRTK3VaMExrN09Dbng2RWpIZzB5WHc2UXBrY3p5ZDFYU1JX
WTJTbXVkSXl1QjhKWENmcnZ2eGVZNll1WTIwN2syUWM5YnVZWjRqS1NQekhMRXRuRlpWMFQz
UGtUWUpORDFqYzJLSXpHcWtjNTRqOE9ucENBT2ZMaDRHUGoycE1QRHA2Y1VzYzllSnpHcWtj
NTRqaHc4NFdnb1lUMDhDNk40U2pLY3JrRURUYzNKeWpOZ3I3LzFGWmpYU09jOFIrUFIwaElG
UEZ3OERuNTVVR1BqMDlKSkEwK2ZNbVhQMjdGa2pkbXdFNE5PdER2aDBjWUlvQ04wNy9SZTIy
ZDZuUC8vODh3OCsrT0RGaXhlTjJIZmFBWit1STBZd0RIeTZlRmhtc21JMTNUeFo2UWhMMWFj
ekp6ajRkSnpkMzBqVER2aDBxd00rWFJ6dzZaSWsxL1MwYmRER1B0MWFnRS9YRVNNWUJqNWRQ
QXg4ZWxKaDROUFRpMDAwWFRZbmhrVG1DcUQzQW5YcjRkNE05M1JPREVsOUhvd0o5eWJJT1Z2
M0RkNEdLZEdzTC9hL1Qzc0w4THJCYmordHFwS2RPVEVPSGp4WVVWRkJybjVadlhwMVkyTmpl
bmVmWHNDbjY0Z1JEQU9mTGg0R1BqMnBNS3Y0OU5IU1hWYjM2VmRkZFZWYld4dTkzSER1M0xs
R0pKRXVZRHpkNnNCNHVqZ3duaTVKbVIxUE4wQlZqSkRCQkpxZWw1Y1hqOGVKcHA4N2Q2Nmdv
TUNJSk5JRitIUWRNWUpoNE5QRnc4Q25KeFZtRlovT2E3b2xmZnJOTjkrOFk4Y09oTkRwMDZk
WHIxNjlmUGx5STVKSUYrRFRyUTc0ZEhIQXAwdFM1bnk2Zk9ERnVqNzk5T25UZDk1NVowRkJR
VUZCd2ZMbHkvL3hqMzhZa1VTNkFKK3VJMFl3REh5NmVCajQ5S1RDVXZIcG80MlF6QjUxK25T
a29PbVc5T2tabzdtNXVieTgzT1Z5elpzM3I3bTVHYWMySjRaRmZib3pTNzJ6UncwK1had2dD
c29VellHa3Z3WFV4dE9WTkQxMWpOQlNzMmg2WVdGaE9CeU94K09oVU1qdGR1UFU1c1N3cWs5
SHlJeFpTWkprWkZacW1nNCtYVHVHMVhUelpLVWpESHg2ZWxIVjlQZmVlNitxcWlvM043ZXFx
dXI5OTk4M1l0OHNQcDh2SEE0UERBeUVRcUdhbWhxYzJwd1lGdlhwVmtvMWZZQlAxd2Y0ZE1s
SW54NUV3ZkVsa2kxOCtxSkZpMTU0NFlWb05QckNDeS80ZkQ0ajlzMXkrUERod3NKQ2hGQmhZ
ZUhodzRkeGFuTmk5RjE3clNSUXZSNTNkWWxVcisvYnV6Y3RNZmp3NGQ3ZTNnVDErRTJZbGNG
dGhlckc1eHhnNThUbzNleExPQ2VHMDlxS3ZRK2lZRWZaSnRKbnpKTlZzbTBsU1ZML0gvK29l
NCswQmNUM21QZ2NMQ3VURU9xcWVXUjhDYk9jVlpVVTJ5SFRjMks0WEs2QmdRR01jVHdlbHdt
b0VjeWZQNStPdlZ4MTFWVTR0VGt4d0tkYkNQRHArZ0NmTG9GUFYwSlYwOWx5WFJrbzNWVlVW
RVRIWG1iTW1JRlRteE1EeHRQVG1aVWtTVVptRlFnRTZHTVlUeGVQZ2ZGMHljang5UGF5cDhl
WFNMWVlUK2NyTWhwYWw3R3BxY25qOGJoY3JybHo1NzcrK3VzNHRUa3h3S2RiaUhGREJENDlH
Y0NuU3diNGROS3FvMjFMc0kxUHR5TGcwdzNKU3BJa0k3TUtvaUFkZmdHZkxoNERQbDB5d0tk
VFFiZWhUN2NpNE5PdGlGOUYwOEduYXdNK1hRS2Zyb1E5TlozNmRPMjMzSFRPeFpFK1hVM1R3
YWRyeDRCUGw4Q25LMkZQVFovdzQ3V0ZqSXlGVWswZmZoU2tQNU9DVHhkSGJpY2RDZmgwSG50
cU92ajBkR1lsU1pMQlBwMmVQK0RUeFdOWTZURlBWanJDd0tlbkY1dG91bXllbzRnME9oZko2
Rnd3V1orTlJYeU9sYXpua1BGNzc0WTlRUlNrajJHZUk4SDdCbTlERUFVYnZBMm96cm50RUVU
QjlKNDF0RlZwbnh6ZFBqdkRrYVhuT2JJVzFLYzMrQm9pRW9wSTROTXQ0RDNSbXYxKzhPbkp4
SkNmSDZpalJIWElERm5wRGdPZm5sN3NxZWtUQnNVc05FaHRvVlRUaDVxbXczaTZHakpOZDJh
M0ljQjRPbzhOTlIzVm9RWmZnMGlQTjUxekFaOE9QbDBnaHNnTjI4UE5rSlh1TVBEcDZjV0dt
azUrR3JXa2k3RlFxdWtEZkhxeThKcWU3WXl5aHRFK0hkV2hpQVErUFh0UVRRZWZuczZzSkVr
eTJLZExFYmcrUFlrWThPa1V3MzA2TGVZMUp1VmtqK0tYRzJtSEdTR0RadEgwNGVIaGpSczNs
cGFXNXVUa2tLb3krdWM1c3BwUEh5OU1hUHBValdCY3g4R25pd0UrbldMNGVMcW1wcWVPRVZw
cUZrM2Z0R25UZ2dVTHVydTdSMFpHeUJMOTh4eFp6YWZMTk4wa1dja3cxS2NyYWpyNGRMVVlj
cTBMK0hRSmZMb1NadEYwajhjVENvWFlKZnJuT2JLYVR4L1AwUHlwR2dENDlHU2hzbUtaSG00
WW1mSHBxQTZCVDA4YWw4djEwRU1QVFowNjFlUHg3Tm16QjZjeXp4RkMrNjc5VFJBRk84bzJC
VkhRQXZNYzBReWRPYzhSbmRzSTVqa1NpNkY5bS9ad00yU2xyNjJrbE9jNWlranBuT2VJdHVy
b1BFZGxaYU1hZ2hBdUs0dElpTXlzMUZHMktmVjJ5UFE4UnhsbTVzeVpvVkNJekhNMGE5WXNu
TW84UitEVExRWDQ5R1JodTdjMWVyaGhUTGlRUEgwYmxJK25NeVpkZnZWNmFoaWhwV2JSOUZX
clZvVkNJVExQVVVsSkNVNWxuaU9yamFmTE5OMHNXVTBFeHRQRnd6SXduaDVFUVQrTXAzT2Fi
dFI0dW9xbXczaTZGcWRQbjc3aGhodnk4dkxLeTh2SndMcitlWTdBcDFzSzhPbkp3bXQ2dGpQ
S0d1RFRlY3lpNldrQmZIbzZzNW9JK0hUeE1DZjRkRlNIMk1uQmRXOUtNREcxVGZuQnAzUFlV
OVBCcDFzSThPbkpRalhkbjZVZVBuNGRTTGJ4ajFVeFM5Y0d3YWViQ3pXZnJ2YVdtOFhsSVNU
Ujg4UThXVTBFZkRvZmxxMSt4V3Q2aHQvQnpaczNpMmg2NW56NldDWjZ1dC9FTjVIMTZlU1VI
TDk0Y2FLbUM1YkQxTTdLQ0JtMHA2YkxmSG9hUDhZTkFURUZKWnlIZFgxNnR2cFYxbjM2dUhY
Tk5tbG9BYVNzNmZRWTFUUTlMWWR2aEF6YVJOTW56SW5oOVRiNEdtaHRlNG5Vc0ZlcVNYK2lv
ME54dWV5K3Q3YzNMVEdTSkIwNWNrUmhPYW12UDVhbldiTEtWRnVOejRNeGNVNk1JOC9mTGlX
YUV5UHRXU1djWCtMSWtTTTBSbTArQ3FQZlFkSzM3L0kyK01kNmVJYmZ3UVpmZzhpOEVDSlo5
ZlgxNGE0dTNWblJGaERmb3p3R0lXL2R1RDVRM1dndmU1cWRWNGZlQittTUdWNXZpdWNYeklt
UkdFV2Zib0VoZGZEcHB2SHBkR1pVcllUSDdIbDZSM0xGWVgyNkgzeDZ5ajQ5RUFqUW4zekJw
NXNMeGZGMGpkWTN5OGoxUkUwM1MxWVRjY2g0ZXNMZnZzZ2xIK1N4V3RmSzVIaTZYKzk0dXRx
bmtjaW1HbndOdktiekd6UjZQQjNWb2RUSDAwbExCZ0lCVWxOM3duVXZpVFE5UWZrbXplUUpS
c2lnUFRVZGZMcUZNSlZQRjdtZUlUaFdXWnZ0V2dZWmRzWE4ramxOMTdIM1ZCSlc5dW1aNzcw
SXBmNU5oZjRzNFo5WTdWSy9UMDhtR1NOazBKNmFEajVkRnFOOUFvTlBwekYrQVovT2E3cnNZ
dTAwWnVXcjgvRUxlVTFYREpNaHkwcnQwNU5IZ2RFQUFDQUFTVVJCVkV2UXA4dXU1eHR0RFFi
eHkwTDBYL2ZDYWJxTzd1ZG5XeklkUHAxdldQRHArZ0dmcnJvSEUxLzVZeXFmcnEzcGRNaFZr
cVNJTlBiRmYwelJqR2prMFVsMnVDVDlFelZkNU91RkRCMnJzQWtrMUhReVNLMTdGMEtrejZm
em11N25mTHFncWlUVnNFYklvTGswZmVQR2pXUkNESnphbkJqZzArVXhtcDBlZkxxVXlLY1Rl
U0xlTXpoMjhzdUVnT3B2R3JOcThEWHdDM2xOVnd5VEpaOUduMzRYNTlObFQ4bVNkM3NUZjN2
Z0Uwc2lLd044T24xY3kvbDBYdFBCcHllZ3E2dHI5dXpaVk5OVG1STURmTHFNVkV5WjBWakNw
eE5acEQralNSTTFuUldGdE9mRHUxMlpwZ2VaLzFMeXdXcC80ayt2VDFmVWRIMjdFSGYzUWVa
VFRmZU8xRFFkZkhxcTlQZjNlNzNlQXdjT1VFMVBaVTRNNnRPMUwzVXltMDhudmNHSXJMVGxC
bnk2eFBsMG1SVFNVUmRGbnk3VDlEUm1kWmV2SWFHbSsxRndQSXpyNmhGSnVWOWx3S2VUYnc4
MGY5cWsyajgvS0Y1T3F1YUlkZnQwK3JkdE5VMWYvdU1Yd2FlbnhOcTFhNTkvL25tTU1kVjAz
WE5pQkZGdy9kaU1BWDRVSkRYc1JXcnpaKzJleklsQnF1OGJzeGUvWVZ0Ty9WNXRUZ3hKY3ph
TTBmdDA1N08rYkJPcVEzYy9PVG9IQWwxKzk1TmxxRzUwSm9TT3NrM2tzUjhGMTVkdEltdlJ4
OHJIV0tlbkI2STZ0TDVzazRRUTJmdmRUNWJSZDNOOTJTYTBaai9kNzJnL2w2U09zUnpJSHNr
Vy9DaEl0aUNiVFVKSCs1QWM2UGtsV3lKclNkTHJ4ak12SzR0STZPNG55NElvMkhONHdudEhz
eVhuTDk4T2ZQNzBUS2ZIcnRqbXNyVklKdVQ5N1pqNDNwRnM2ZU83ZDQ3MmdTQUtrbnQySGhJ
TlZSRS9pMjArSndhWldwcUNVNWdUSTRpQ2Qva2EyRyttNE5QQnB3dkdrTEdPUUNEQS93Wkkz
aURpMDhtVjBlSStYZkduVHUzQ0kyUUpjY1RFMk5JQXNpOFVHYytCaHZuSGd1bGFKQ0FpSVZ4
V3h1NUNyVXNrYUN1RUpNYW4wNTlHMlorTHBiRXJ4OG0zQjlxU05KUFIvTWNPYXZuR012cXZI
elp6OXVhcjg3RXhOSksyQUEzajEyVnY1Qm9oOHY3Nko3NlBwRUZRQkpIYjhzWXk0dFA5RTMy
NkgzeDZzbENmcm50T2pBbnY5SnI5YXBwdW9rdEJKbXE2RVJneDFKc3V6RGFlVGdZclpMcER0
WW1vQUJVbW1TNm9TUW5WS1lsUlBWNXUxRFNML0FBYmtSQXIwNnltKzVuY0FvRkFJQkR3andr
dUc4UEtvbUtYa09YR1A1WjluckZ0NGgrYnQ1UGMweVV5VFdkSHEwbFRreHZSV1hZSmVjd3Vv
ZG9ha2NaM1FUOHF5STJHMGUzVGw5aE55VDVnZUUxSEVhU2g2WDUxcHdqajZYS29wdXVlRTRQ
MTZTZ3kzcVc0L211YTZ0dmcwODNrMDNuM2grb1FGWHBmblU4V3crb0NVYlRsRzh1SS9sS1pE
azdVVTdMQnpaczNrekR5RXBHaFFDQWdqZjFiM2MvMFpLcWVyS1pMWTdKT3dsZ1hLVXZTajRL
MVpVOEh4MzczWXgyOW9vMmxXWkViWFVLMklNdUt5aXRwSmVxQzcySXVQNU01WWxsaWZMYXlH
L3ZOTzhVd2pSZ3BrVStuUiswSG41NFpxS1lUYVVCcjltdHJlc0x6UERQUTM5ekFwNXZCcDh2
TXI4elpLY3FsWXJ6SXphL3lPS2l5QzNZNWtSNFJwVlBjam81czFZNDlxUDQwcUJLVHJwdWt0
d1VTYWpyMTZWSUV5VFRkUDZicGlsMElmSG82b1pydWU5ZEgzeGp6KzNTWnBodmswelhHbXND
blM0eFAxNzZKT0VGaVBOT3lLWTBZVnRQTms1V09NSkhFMURZbCsxUXp3cWVqaVpwTzl3ZytQ
Uk9NKzNUbXc5WVBQajJScG1jWFh0TlJuWmhKTjhDblM0RjArajVEYjZuNGROdmMwdHNDa3BK
UEp3LzhFelY5OUZVbHdLZW5FMFdmN25lOFR4LzlRVXo5TXl4YlBuMzBsemNWVGMrd1R5Y2xV
OUNhL2RxbnZYa2NNZmgwZndaOXVwLzhLa0MwUGpDNlVOeW5xemtxSTJUUW5wb09QcDJGWEFW
aDNKY0EzWXhxZWdUSngxNVFGbnc2K2F0TFFrMDN6NDN0NFk2OXBmZndVUjNTOXVueVY1VlFQ
TkZBMDVPR25lZW93ZHZnZTlmbmZkZUxJc2o3cnRkUFprSlJtbDNJSkRNS0JWR1EzTi9sYlpB
TW1DVW5PRFluanRvOFB0bWE1K2pkUHE4a1NkNTN2Yko1amhxOERWSm01em55MW5rYmZBM2VP
aTlhczUrMGxkcjlUMi9mcnZFcXVmLzEvOTZjTU9ZdWI4TmR2b1pVWXRnZWJwNnNrbTJydTd3
TnRXVlA2OTRqaXFCazk2Z1JFd2dFYUtzdWJ5enI4M3FES09oOTF5c2hKR3R6RkVGcTh4enhh
blBreUJGeWpzdVd3enhIaVVuS3B5ditEU1FyVUovdU44WktCMWtib2xMOWd5VmpJKzlCK20x
M29rLzNvNkRSUGwxMmpPT1hrSU5QdDlRdHZZZlBPL0hnMlBYUXBHUG85dWxxMzVLTmtFRjdh
am83bms3ZWRYcnEwcE01aUlKbUcwLzNHek9lUG40QzFDSHloeFR0VFNscXVuRlh6YXRwdXNo
NCt2S05aZnF5a2wwdFRxNjVsbEJpVFRmUHlEWGJ2YzJUbFk0dzg0eW5zNjFLeHRQSE5YM3Nw
MUZXMHdYSDAzMTFQdEIwblJCTmx6VTkxWFEwOXZkdTJ2UW11UlRFei93anc2RHRqMjRjamY2
dFRqcytZeVB2ZmpxQ3FkZW42MDQxeVB3SmlQNUhodG94Uzl6QXAvdlQ3ZFA5R2o0OWdxU0px
cUxtMC8xY255UWRUTmtxR1lBOU5WM1pwelAvVnlabk5TblNsQkNqZmJwL29xWWI1OVBwUDBl
ME44VjNTaU95R3Y4cll3byt2YmJzYVgxWitibS8waEQ3Qmo0ZGZMcWFUMGVjcHF1ZHpySWxw
RXlzWXIxSkkyVFFicG8rcWhTY1QyZi9ta3ora0IzVVczWlpHeDNlM3ovMjcyb3BvbWRpU1pI
dHkyNko4ekVlV3B4RTRib1hza1RBcCt0T1ZmV1V0b0pQSndjT1BwMDJRdG8zU0ZYYnJ6VHFr
cXhQOTZ0NEtjbmVtdDdVMUZSVlZaV1hsMWRkWGQzUjBZSDF6bk5FUEJmdjArVUYyQkF5eUtk
cmk3THFCenVqNldtYzM1MWNHS3NnQ3BxYjRnT2tpVDQ5MmIra3l1TEhDMWhUQnlTN1BuM05m
clJtdnc2Zkx0NVdmSnRZeUtmTFZNWWtXZWtPUzlHbnM1cWVkcC9PdHphOVJTUUZueTRyamtZ
RzkvaHk4eFFqdE5Rc21uN1BQZmQwZDNmMzkvZHYzNzZkMU5IVk44OFJHUkxsZmJxc0FKdGYv
Wk16S2ZqTEovUjQvd0NpZjFFTG92RUNmb3E3U0RZOWNuRzY3S2E5bGovaEx3MUpIcVBpMXNp
b0M5WDAwWjhyR1UzWDQ5UEZFdE9vSjJVSm40N0cvdllDUHQxUW55Nzc0NmppcjNUOHFZRWk0
NTJRMW1MelQ2eEZUREZDUzgyaTZaUVRKMDU0UEI2c2Q1NGowdnE4VDFlOHRZKzVQRUZ6ellm
UkpkUjcwaDlENUJYdkpvYXg2NUxlSTQybDJ0TTFvYzYxMmdkUFFwK082aEQ1d1YyaDQzTEdl
VHlaT2tTK0xyQkhJVTMwNlJxZmhWcUZKeWZ1am1pNlgxM1RoZjVIV2p2aG01WmdXeWxxdXJW
OHVxeDdteUVyM1dIWjllbXlLbUNzVDZkTCtEWW5DL25lUHVwUm1Hckp0SXdsYTlmbzZXYUVo
SnBMMDN0N2U1Y3NXYkozNzE2c2Q1Nmo5V1diVUFUZHZiT012ZmVQelYwaXV3K2lJSm4zcE9m
dytDd3FkRFlaOWpHaWM5OXdzNmpRT1doUUhXcDY5RkUvQ2pZOStpaU5aMStWM1krL3VyUE1q
NEo0WnhtS0lEcHZDNDFrSDdQNXlPWndrVzJmTE9rNVhCWWs4KzhFME4wN3k2UUF1dnVCYldq
TmZqcURqMkp1ZUdkWlJFS3lvNUNZT1dLQ1NqUFJLTjdUZU9WMmlLRFI5K3VCYldST0dUTFAw
ZWhzUnlMekhBVW01Q1pySzlwaXNzZUJRRUN4UC9oUjhPNEh0cW4xRnZQY3kzcDQxdlBKNG4z
cUxZQW42b05NTjJSS0luK1ZPZGZvN0ZFb2drZ2ZhM3IwMFNDWkVTa3lQdHRVSUJDZ3ZkSG04
eHhoakRzN096MGV6eXV2dkVLZTZwdm55Sy9rMDlXc2VtM1owL1RqbEg2SzhqZGZuWStVbkth
VEV0RGI2T1hlRXlkUEdmMk5tNm5mVCtNM2I5NGNHQ000Tm4wQmF3VDhZN1lGTVdXNzJhdnU2
QU9hMVlSdkF4T1hzSFhrWlY4cVpRZEk4aHd0a0QzMlI2M2cySmlWaE5EeWpXV3MrMURiTHo4
ZnplakZBMlBKU3dqMStueWpqY240OU9EWXBZVEorblIyWDhHeCt1QWtINXFuckswVXY3dFkx
NmRMQVpUaHJIcmY5YVZyVTRLSlpjdW44L2FjbFJUYXIyaWY5NCtOb05McnFmd282QnRyTHFv
em8rWDE3ZTNUNit2clMwcEs5dTNiUjVmb20rZEk3VzFRZTRPRDNFMDJINHJzaWpmRjViSzMw
RC94cVVad2NPeXZhM3p2MU40Um43UGlFa1VKUUl4a0syYkYxNlRtTjB2M3FORmMydTNtWnc5
OFRFbVRIVThuUDBXSXZFSCtpWS9WYnBZWW5oYnYzc1lsa1BWR1lKc2lsUzJvYWJyYWtBdjdV
YXA0eHZINW9MSFpTMlQ5ME9hYWppWnk4ZUpGbmZNY1JaQ2dUMGNSWkpJUlJrV2Zuc2FzRWtx
QXRuTWhOeVBhYWp3bEpVMFg5T2xwYnl2eFRkR0dJai9MMDZjWjl1a29na1NNc3l3cnRka2tS
TEx5dmV1VG1PTk41UUFGbXlzclBsMUQwTWxONDNTV05aZGl2N0s1cHFjRnF1a2FLaWFORmNn
MnlHdEl5UmZnUnN4ZjFFUk9GUjNiVDhyV3BUMkJ4SWxSVFNlL2w0NzVJTUZMWDlMeU50R0NI
dlNwMmpqTTZHY3crU2JCZkI3clRpYjFONVNtTFhFUE5EYVNlZ0t5MXB2UXdobnBSYkwrbytN
MjJwRWlhTUlHeFc2Q0Rhc1dESnFlR0cyZlRpLy9rc1kwRkRlbTJlVWxQRlZVYlJjVnNnakNq
V1VpNTROZ1ZpSjlrWGN1ZkFJWjh1bXM5elRTcHl1YUtYOGlUU2NqMSt6M0t2NXhldHZLcDJU
QStUZVVobWxvdWl3cnRZNHFtSlZjMDdsK3hXWTEzb0I2dndJcVpzVmYwQ25lL1dnbmw1MFg5
SEhhZlRxL0hEUTlNVTg4OFlUR0o2cjRKNjN1MitoMzhNQzRMZ2l0eGVRanBkV3FxM1pIOWNR
a0pvZDBKYU80QmZrM3FySDVZOGViUWwzSzJkRjIzVytUU0VQeENmdTVpOXY4U3I1VjM1dVZv
SWtTZWNuUi85L0szcjZBOHR1dEwxdUpPMTZKK1ZNcjM2VCtNU01zNzFycCtFNlR5b21zcU9u
SjN0UlNva2V0b0VMTWV3R2FuaGlxNmJ4UFY3d3RieXdqNnFEMnV4eFowcnZaTnhvV0dWY1Qy
WW9rUmxtaG1FamZoajNzL05lOGtNbXlJanZsTTZSN2xBbmNlRXdFb1RYN05kcUJYY1czWVk4
OGJTWjVjc08xWmVPN1VCRmN4YXhvUE4zNGFDTWtlbmMwZkRyZE9LNHRZMXRHZmdoam1aQTlz
am53TjhXMll0K0YwVERhVnV4N1BmRjlKMWxOYUlUSWhMVDV0cHJRSDVqRGtXV2xxQlFLeVNz
ZDQvSWZ2OGkvS2RwWnlScWNKcW02dTRtZGh3MVRTSHZzTU1lYks4TDBGcjdQS0xXUGJHdnlO
M3JpYmJSSjJYZFF2UitLK1BUZXpUN1pPeXZTdGNhYkZEUmRBem9uQmhxcldBLzNWci9YbUEw
RHJkbFBIcHNoVDdpSGUzMzNNQ2RHWXZUNGRJRXdrYTBKN2xFa0RMSWlOK3JUa2FJL1hiTWZy
ZGtQYldYMXJBUVRTK01lelpNVitQVEVhSXlud3cxdWNJT2JxVzZnNllrQm53NVpRVmJXeWtv
d01mRHA0dGhUMCtFR043akJ6ZVEzMFBURWdFK0hyQ0FyYTJVbG1CajRkSEdzcE9raWMyS0lO
REhjNEFZM3VHWDlSalc5NmNjLy92cnp6OU9sazFiU2RKRTVNVWhqZ1UrSHJDQXJTMlFsbUpp
OWZYckE0OW04WU1GZmZ2ZTd3ZjcrMUhYU1Nwb3VNaWVHU0JQRERXNXdnMXZXYjZ5bWsxdmQv
L3BmZjN2cnJSUjEwa3Fhcmpnbnh0R2pSeDk3N0xFTkR6Lzg2SjEzL24vWFg3L3V2dnNlZSt5
eG45MTExMk9QUFVZZWE5elgvdkNIQ1dNRXR5YTR4NS84NUNlUUZXUUZXYkgzajl4eVN5YjNh
SjZzaUdxdC8rbFB4elg5K3V2L3RuOS9panBwSlUwWG1ST0RQRGgrL0xqSUJ2dmZmVmNrVEdS
cmduc1VDWU9zeE1NZ0svRXdjMmFGeFJKTDR4NU5tQlVaZTNuMy8vNWZ4NDI5aU15SlFSNE1E
QXlJYlBDYjdkdEZ3a1MySnJoSGtURElTandNc2hJUE0yZFdXQ3l4Tk83UmhGazFQZkRBMXlk
UGlteEtCQ3RwdXNpY0dFbHRjT2pzMlRTbGxrNGdLM0VnSzNITW1SVTJhMkxtekVvRUsybDZR
cnJUUFZzckFBQ0F0YkNWcGdNQUFEZ2MwSFQ5TkRVMVZWVlY1ZVhsVlZkWGQzUjBZR1pXVlZO
bHhTOHhRMWFOalkwVkZSVm15NHF3Y2VQR0xMNkpHdjNLVkZrTkR3OXYzTGl4dExRMEp5ZkhW
SW14elZWY1hHeVNySnFibTh2THkxMHUxN3g1ODVxYm00M2JOV2k2ZnU2NTU1N3U3dTcrL3Y3
dDI3ZXoxK0ZrVjlQNXJOVHl6RzVXOTk1Nzc0a1RKMkt4MkovLy9PZHNuWGlLTGRQVjFUVjc5
dXdzdm9sOFZ0bnRVUVErcTAyYk5pMVlzS0M3dTN0a1pNUlVpVkVPSFRyMHExLzl5aVJaRlJZ
V2hzUGhlRHdlQ29YY2JyZHh1d1pOVHdNblRwendlRHowcVJuT1FNeGxwYmdrODhoeWlNZmpy
Ny8rdXMvbnkySkttTW1xdjcvZjYvVWVPSERBREc4aXpRb2hkTmxsbHhVVUZOeDY2NjBuVHB3
d1NWWWVqeWNVQ21VM0dSYStlOTk2NjYxZmZ2bGx0dkloMEt4OFBsODRIQjRZR0FpRlFqVTFO
Y2J0RVRROVZYcDdlNWNzV2JKMzcxNjZ4QXh5d0dmRkw4bDZWdVRiY1ZGUjBmdnZ2MitTck5h
dVhmdjg4ODlqRTd5Si9QdDE1c3laMnRyYVpjdVdtU1FybDh2MTBFTVBUWjA2MWVQeDdObXpK
NHRaWWFYbU9uanc0TDMzM3B2RmxQREVyQTRmUGx4WVdJZ1FLaXdzUEh6NHNIRTdCVTFQaWM3
T1RvL0g4OG9ycjdBTHN5NEhmRmFLZVdZOUs0d3hHWHU1OHNvclRaSVZHUnJPK3VDMTJ2c1Zp
OFh5OHZLeWtoTG1zcG81YzJZb0ZDS0RDYk5temNwV1ZueGloSnR2dnZtamp6N0tWa3FZeTJy
Ky9QbDA3T1dxcTY0eWJyK2c2ZnFwcjY4dktTblp0MitmYkhsMk5aM1BTaTNQN0dhMWR1M2Fz
MmZQeG1LeDExNTc3ZkxMTHpkSlZwUXN2b2xxV1gzOTlkZFBQUEdFMysvUFJsSUtXYTFhdFNv
VUNwSEJoSktTa3F4a3BaZ1l4dmlkZDk2NTRZWWJzcFVTVnNxcXFLaUlqcjNNbURIRHVGMkRw
dXNIVGVUaXhZdXlKZWJNNnVMRmkyYklxcUdob2JTMGRQTGt5ZC81em5mKzY3LytLL01wS1di
RnZwU1ZsQlN6SWcveTgvTnZ2dm5teno3N3pDUlpuVDU5K29ZYmJzakx5eXN2TDgvaXdMcmlt
M2pqalRlKzhjWWIyVXBKTWF1bXBpYVB4K055dWViT25mdjY2NjhidDJ2UWRBQUFBUHNBbWc0
QUFHQWZRTk1CQUFEc0EyZzZBQUNBZlFCTkJ3QUFzQStnNlFBQUFQWUJOQjBBQU1BK2dLWURU
aWVMbDZJRFFOb0JUYmN3QXdNRER6Lzg4S3haczZaUG4vN01NODlrT3gyemd4QjY3cm5uTU1h
Ly9lMXZRY2NUMHQzZGpSQ0NlV1pFTUZYWEFrMjNNT3ZYcjcvenpqdS8vUExMcjcvKytwRkhI
c2wyT21ZSElWUlpXVGt5TXJKZ3dZS3NuM2ptWi9QbXpaTW1UZHE4ZVhPMkU3RUFwdXBhb09r
V1pzNmNPYklweWRuK1JCOGpoTmF2WDE5UVVFQXJmR2E5MjJVRmhOQjExMTIzYWRPbTY2Ky9u
bTBjV2FPOThNSUxNMmJNS0NvcTJqNDJ5N0F6bSt2bW0yLys4WTkvZlBQTk41T25OVFUxWkc2
SDl2YjJ4WXNYWTR5N3Vyb3FLeXZ6OC9NM2JOakF0bWUyRXM0aWZOY2kvU28zTjVmT2lmSHpu
Ly84My83dDN6REc5OTU3NzVvMWEraUthVThHTk4zQ3VGeXVvYUVoZG9tYXBqLzMzSFBSYVBU
QkJ4L01hSDRtQXlHMGMrZk9TWk1tN2RxMVM3R2h5T050MjdiRllySFcxdFpzelI5aUJxTFI2
TFJwMDc3ODhzdHAwNlpGbzFHTThaWXRXMWF0V29VeFhybHk1ZGF0V3pIR1BwL3Z4UmRmakVh
ajI3ZHZkNmFVVTlTNjF0RFEwTUdEQjJmUG5vMHhIaHdjL043M3Z2ZUxYL3ppZTkvNzN1RGdv
SEhKZ0taYkdBMmZQamc0eUdyNnBVdVhNcDJjK2REUWNmWXhQZCtjckZNdExTMjAvbFJMU3d2
RytOeTVjMjYzKy9qeDQyNjMrNnV2dnNJWTUrYm14bUl4akhFc0ZuTnlXMkdsN3JSdDJ6YVB4
ek5wMGlTRVVFNU9Ebm1wcTZzTElkVFYxV1ZvTXFEcEZxYTJ0dmJPTysvczdlMDlmLzU4Ylcw
dHhuam16Sm43OXUzcjcrK3ZxNnR6K05kaEhrRk5WM3pzTk5hc1dVTitkWC9tbVdmb1FNR0tG
U3V1dnZycWxTdFhrcWRlci9jUGYvaERMQmI3NHgvLzZPUzJ3a3JkSmo4L3Y3VzFOUmFMaFVJ
aHNpUVdpMVZYVjk5NjY2M1YxZFg5L2YzR0pRT2FibUhpOGZndmYvbkxtVE5uMHV0ZTZ1dnIz
VzczakJrenRtN2RxcUhwemp3RCtSTlBWaEJWTVFZN3Nybkt5OHMvL3ZoampQSEhIMzljWGw1
T0ZyYTN0eU9FMnR2YnlkUE96czZLaW9yOC9QeDE2OVpObWpTSkxIUmdXMkdsYnZQVVUwKzUz
VzYzMi8zc3M4K1NKZmZmZi8vcTFhc3h4di82ci8vNndBTVA4Q3VtQzlCMEFBRDBNenc4L01Z
YmJ5eFlzQ0RiaVFDamdLWURBS0FUTWxoY1hsNmVyVmxOQUI3UWRBQUFBUHNBbWc0QUFHQWZy
S0hwenZ6aEJRQUFJRm1TMDNTa2dtSmtUazdPdDc3MXJWLzg0aGZrSXRaTWN2TGt5V1hMbGsy
ZVBIblpzbVdmZi81NWh2ZWVNZmoyNTVmRTQvR0hIbnFvcEtSRTdaM0NHRGMzTjNzOG5yeTh2
TzkrOTdzOVBUM1llUTJJRUNvdUxzWktUY0dqMWppQlFNQTI1b1B2U00zTnpRc1hMcHc4ZWZL
U0pVdmVlZWNkTE5aSitMV2FtNXZMeTh0ZExsZDVlZm51M2JzemN6aEd3NHNoZjk3eFRjSERO
Nm5JV2pLUzEvUUlkMVBSOUpHUmtWT25UcTFhdGVvLy8vTS9SVkpKSTNmZmZmZUdEUnY2Ky9z
M2JOaXdZc1dLRE84OXcyaGZxbGhiVzF0VFV4T0pSRVpHUnRTMlVGeGMzTkhSTVRBd0VBcUY3
cmpqRHV5d0JzUVlyMW16NXZISEg4ZEtUY0dqMkRoSGpod2hKM0RHY3M0QTdPR3NXTEVpRW9u
RTQvSGR1M2RmZnZubFdLeVQ4R3U1M2U2MnRyWjRQQjRPaDkxdWQwYU93M0Q0OTUwLzcvaW00
T0diVkdRdEdRWnFPbmx3NnRRcDh0Zlk5OTU3cjZxcUtqYzN0NnFxNnIzMzNpTXgzL25PZDFh
dVhEbHYzanp5UndieW1jWVdTYUFMMlMzekZUbGtGQmNYOS9YMVlZejcrdnBzL3c5dmJVMHZM
UzE5KysyM3RiZFFYRnk4Zi85K0ltUXpac3pBRG12QXI3Lyt1cWlvNlBUcDAxaXBLWGo0eG9u
SDQ0c1dMZnJUbi81a1kwMG54R0t4cHFZbWN1V2llQ2RoMTZxdXJtNXZieDhZR05pM2J4K3BH
Mk1ERUVKdXQ3dWdvT0NXVzI0NWNlSUVWai92MktiZ1VXdFM3YlZrR0s3cFEwTkR1Ym01R09Q
S3lzcVhYMzQ1Rm92VjE5ZFhWVldSR0ZyUGM5cTBhWFJkdGtpQ2JHdFlyQ0xIcEVtVGhvZUhy
N3Z1dXFHaElaZkxKZElRMWtWYjAxMHUxNFlOR3dvS0Nzckt5bDU3N1RYRkxUUTJObDV4eFJW
VHAwNWR0MjRkYVM1SE5lQ3p6ejVML2d5Q2xacUNoMitjUng5OTlJYy8vQ0cyM1E4L3NzT2hn
MVFmZnZnaEZ1NGtzclU2T3p1TGlvb1FRa1ZGUlViL1N6N0RuRDE3dHJhMmR0bXlaVmpsdkpN
MUJZOWlreVpjUzBibWZMckw1U0lENjlGb2xLZzhZdjY1aDlTTEpHQk8weE5XNUNndUxqNXo1
Z3gyaHMzVTF2U2lvcUpRS0RRd01ORFIwVUdHakRVNGNPREFuRGx6c0pNYWNIQndzS3lzakJj
WDJoUThmT09RSHN1UFFWc2QvbGlpMGVpdVhic1dMVnFFaytrazdGb1ZGUlhoY0RnZWo0ZENv
Y3JLU3FOU3p4TDkvZjE1ZVhsWS9ieGptNEpIclVtMTE1Smg3SGo2RjE5ODhhTWYvWWpVaTFE
MDZiSjd2a2dDM1ZyQ3h5eDMzWFhYNDQ4L0hvL0hIMy84Y1dLZ2JJeTJwdDkrKysyMGIybWNl
Q01qSTBlUEh2WDVmS1J1akhNYXNMR3g4ZHBycjJXWHlKcUNSNk54N0NUb2VPTGgzSC8vL1Nk
UG5vekg0MDFOVFdSVVNxU1Q4R3NWRmhhR3crR0JnWUcydGpiYmpLY1RMbHk0c0duVEpyL2Zq
NVhPTzc0cGVQZ21GVmxMaG9HYW5wT1RjL25sbC8vc1p6OGp0VG9QSGp4WVdWbnBjcmtxS3l2
cGVMcnNuaStTZ0NhQ3hUVDl4SWtUUzVjdUpWY3ZuRHg1VXFRaHJJaGk0OGlXOVBUMExGMjZO
RGMzMStQeE5EYzMweFg1N1pTVWxLeGR1elllajJQSE5DREdlT25TcGV5UUZOOFVtR3N1amNh
eGphYnpIU2tZRE02Yk55ODNOM2ZSb2tYaGNCaXJ0SU9zQmZpMUdoc2J5WGZ4dVhQbk5qVTFa
ZnpJRElHMDBwUXBVMjY2NmFiUFB2c01LNTEzZkZOZ2dhNmx1SlkyUmwzTENBQUFBR1FlYS96
blNBUDRnQUVBQUtCWVh0TUJBQUFBQ21nNkFBQ0FmY2ljcG91TWlzRElDUUFBUUNwazdqZlNO
R282U0w4SXI3enl5cFZYWHBtWGw3ZDQ4ZUlEQnc0b3h2RDFKUnhTNlVXR1NFOTJRcGtYR1h5
emlIUXFmV3RaQ1A0QStTSTJyRHlTNjlQNUpScGJwaHNYV1V0RzhwcStaci84QnBwdVN1Nisr
KzZQUC82NHY3Ly9sVmRlVWJzeW5hOHY0YlJLTHl6YS9jbzVaVjVrc0VjbjBxbFNXY3RDc0Fl
b1VjU0dsaExTV0tLNFRSa2FhOGt3U3RNLyt1aWp4WXNYdTF3dTlnTkhWcWZsNk5HajExeHpU
VjVlM3Z6NTgwbkpNUko4OXV6WkcyKzhjY2VPSFZpbFNvenNvNHpmenRLbFM4bXNpZncvU2h6
SXFWT244dkx5TGwyNnhML0UxNWR3VktVWEdkclM3Snd5THpJVWowNmpVNld5bG9WZ0QxQ3Rp
QTFiU2todGlXeWJzcm94SW12Sk1FclRmVDdmMXExYjZiODJzRktkbGlWTGxyejY2cXZ4ZUx5
dHJXMysvUGtrSmhLSjFOVFUwQUplL0w5UE1kZGQrTzNzMnJXTEZBVmJzbVRKM3IxN1JSckNy
dnpqSC8vdysvMlBQUEtJNHF0OGZRbEhWWHFSb1MzTnppbnpJb00vT3UxT2xjcGFGb0k5UUxV
aU5td3BJYlVsUEd6ZEdQRzFLRVpwZW01dUx2bjdLTHV1ckU1TGJtNHVkZHlrdWd0Q3FMcTZ1
cVNrcEx1N20wVHlWV0l3MTEzNDdRd09EbDU1NVpXdnZmWmFaV1dsUm8xWjIvUGhoeC9PbXpk
dnc0WU53OFBEaWdGOGZRbm5WSHJoU2VqVEhWTG1SWWJzMEJKMnFsVFdzaERzQVNvV3NlRkxD
YWtWRitLaGRXT1NXb3RnbEtaN3ZkNnRXN2NPREF5dzY4b2UrLzMrbHBhVy92NStkdm1aTTJm
MjdOa3piOTQ4OGoxWDBhZFBuanlaL1dMQ2J3ZGovTXd6enhRVUZLZ1Y0M1VDRFEwTmZyK2ZE
Rmlwd2RlWGNFNmxGeDV0WFhaT21SY1o3TkdKZEtwVTFySVE3QUVxRnJIaEIzNEZoNExadWpI
aWExR00wdlFQUHZpZ3VycWFHQm02THJzZGpQR3hZOGR1dXVtbS9QeDhhbk5vVEVORHc5S2xT
Mk94R0Y4bEJtUDg4TU1QazdYSVUzNDdHT04vL3ZPZnhjWEZtWjlpeVR5Z2lWeThlQkVMMUpk
d1RxVVhGbGxiMFlWc2pCUEt2TWpnbTBXa1V3bXVaVjM0QTFRc1lpTXJKYVM0UkxIcDJMb3hp
bXRwWTg5Nkw4UER3Ny8vL2U4ZmZ2amhiQ2NDQUFDUVVlejVQMUtFVUUxTkRSbTlBUUFBY0E3
MjFIUUFBQUJuQXBvT0FBQmdINkRlQ3dBQWdIMndaTDBYUUFSOXBUbll0MVd3dm9RTmdObzRH
ckFGYlpxYm14Y3VYRGg1OHVRbFM1YVEvMnp6OERFaWExa0kvcXhwYm03MmVEemttcWllbmg2
czFEZEUxSkp2S0IybGNwTFdkQ2tndjRHbW14TjlwVGtvNHZVbGJBRFV4bEZEVnRCbXhZb1Zr
VWdrSG8vdjNyMzc4c3N2VjF5Rmp4Rlp5M0t3WjAxeGNYRkhSOGZBd0VBb0ZMcmpqanV3ZXQv
UWxqaStvWFNVeWpGSzA0MnI5MElyQjdTM3Q3T2xGUUExZEpUbVNLcStoSjJBMmpnc2FnVnRZ
ckZZVTFQVGdnVUxOTmJsWTBUV3NoQXlUZCsvZnovUmRESVR0RnJmRUxHdGlnMGxYaXJIS0Uw
M3J0N0xsaTFiVnExYWhURmV1WExsMXExYkUrYnNjUFNWNWtpcXZvUnRnTm80TWhRTDJ0Qnh1
UTgvL0ZCdFJUNUdaQzFyd2JaSlkyUGpGVmRjTVhYcTFIWHIxbW4zallTYXJ0aFFTWlhLTVVy
VGphdjNjdTdjT2JmYmZmejRjYmZiL2RWWFg0a2NwR1BSVjVvajJmb1M5Z0JxNC9Db0ZiU0pS
cU83ZHUxYXRHaVJ4cnA4ak1oYUZrSlI5dzRjT0RCbnpoeXMzamRFZkxxc29aSXRsV09VcGh0
YTcyWEZpaFZYWDMwMXFid0lxS0d2TkFkMlpJRmlxSTJqRGUwaDk5OS8vOG1USitQeGVGTlRF
eGxrNE9GalJOYXlITEt6Wm1SazVPalJvejZmcjdhMkZxdjNEVzFONXh0S1I2a2NvelRkMEhv
djdlM3RDQ0ZTSVIxUUEwMUVzRFFIVHI2K2hBMFFhU3NuMThhaFRSRU1CdWZObTVlYm03dG8w
YUp3T0N4N1ZTMUdjUzNyd3A4MTVFRkpTY25hdFd2SmdEUGZOeFRQdFlSTnA5Z3p0YkZudlJj
QXQzYyt0UUFBRm1SSlJFRlVBQUJuQXY4akJRQUFzQStnNlFBQUFQWUJOQjBBQU1BK0dLWHBN
TWdPQUFDUWVZejZqUlEwM1NSQUpaT2tFUG5aWDYxeDJMb296a0g3cVBuMjFGSEF4UHp3QjhY
S0k2bWJKSExnZkwwWEhkZWhKSDh0WTBSK0EwMDNNMURKUkFmYXZWZXhjV1IxVVJ5QzRGR3pB
VG9LbUpnZmpZT2lkWk5FRGx5dE1JNkpOSjJ0M01KWGQ5bXlaWXZINHlFMVlaeDJNbVFlcUdR
aWpuWnY1QnRIclM2S3ZSRS9hc1VBOFFJbUZrSjJVSXAxa3hJZU9GL3Z4U3lhTHF2Y3dsZDNt
VFp0V2lBUWlFUWk3TjlOQVNPQVNpWkpvWDBLOFkyaldCZkY5b2dmTlIrUVZBRVRxOEFmRkY4
M0tlR0IwK0VhdHQ2TFdUUmRWcm1Gcis3eTVwdHYzbmJiYmZQbno1OCtmZnF2Zi8xcjhhU0Jw
SUJLSnNtUzBLZkxHa2V0TG9xOUVUOXEyYXZKRmpDeEJQeEI4WFdUQkErY0w0eGpGazJYVlc3
aHE3c1Fob2VIRHh3NFVGQlFJSjQwSUE1VU10R0I5aW1rMFRqT0VYU1dwSHk2amdJbTVrZnhv
R1IxazBRT1hLMHdqbGswblI0SnFkeWlXTjBGSVRScDBxUzVjK2UrK09LTDRra0Q0cUNKUUNV
VGJXVE5SUmV5TVJxTkE1b3Vhd0crUFJVN3BOVlJQQ2haM1NTUk16Rmh2UmVSWktEZUN3QUFn
SDJBLzVFQ0FBRFlCOUIwQUFBQSt3Q2FEZ0FBWUI4eXJla2FQNmNBQUFBQUtaTE4zMGhCMHcy
Q0xjSFIzTnhjWGw3dWNybkt5OHQzNzk2dEdNKy9sVkR2UlNPbXViblo0L0dRNjE1NmVucXdV
cGtPcThPM0EzK01JZ1ZNdEF1aFpPWllNb0JJNDRpY2lYd00zOWtTa3JTbSsxRlFkZ05OTnhX
eUVoeHV0N3V0clMwZWo0ZkRZYmZicmJnSy8wWkF2UmVOVjR1TGl6czZPZ1lHQmtLaDBCMTMz
SUhWeTNSWUhiWWQrR01VTENVa2k3SGxXUy9TT0NKbkloL0RkN2FFR0tqcENLSDE2OWNYRkJU
VTFOVFFKZnpZaTNaTkdNWHRBR3J3SlRpcXE2dmIyOXNIQmdiMjdkdTNlUEZpeGJVUVFtNjN1
NkNnNEpaYmJqbHg0Z1NHZWkrSk5IMy8vdjNrTkdQL0dNS1g2YkE2ZkRzb0hxTkk1UllhdzNj
MjI2RGRPQ0puSWgrajF0azBNRmJUbjN2dXVXZzArdUNERDdJTDJjY0phOEtvYlFkUWhDL0Iw
ZG5aV1ZSVWhCQXFLaXBpLzZiTWMvYnMyZHJhMm1YTGxtR285NktwNlkyTmpWZGNjY1hVcVZQ
WHJWdEhHNGY0RlZtWkRxdURsUDVBSkR0R2tjb3RmQXpiMmV4QndzWVJPUlA1R01YT3BvMnht
czUvZE1zMFBXRk5HTFh0QUlyd0pUZ3FLaXJDNFhBOEhnK0ZRcFdWbGRxcjkvZjM1K1hsWWFq
M0lqWStjT0RBZ1RsejV0Q25mSmtPcThPM2crd1lSUXFZcU1YUXptWWJ0QnRINUV6VWlKRjFO
ZzJNMVhUdGhVaXNKb3d0QitDTWhqWmFZV0ZoT0J3ZUdCaG9hMnRURzhValhMaHdZZE9tVFg2
L0gwTzlsMFJkYm1SazVPalJvejZmcjdhMkZxdVg2YkE2YkR2d3h5aFN3RVF0aHUxc05rQ2tj
VVRPUk1VWVdXZExTT1kwSFUyRURkQ29DY052QnhDQk5scGpZNlBINHlGRmRacWFtbVN2MHFj
SW9TbFRwdHgwMDAyZmZmWVpobm92RXkvTVVHeXVrcEtTdFd2WHh1TnhyRlNtdytydzdaQ3dG
SWxpQVJNK2h1OXNOa0NrY1VUT1JENkc3MndKZ1hvdkFBQUE5Z0grUndvQUFHQWZRTk1CQUFE
c0EyZzZBQUNBZmNpY3Bxc051MnNNeHljY3I0ZWhmQUFBQUpiTS9VYXFXMzlCMDhWUnJES1Jz
QlFKLzFiYXI0QkpVckFGYzNqNFlqaE9LSStqWGJtbHVMaFljUzIrSThYajhZY2Vlb2lVcjdE
WitTdXJzNlNqUEE3ZnBDSnJ5VWhhMDRNb0tMdUJwcHNIdnNxRVNDa1N2aG50V3NCRUJGbkJI
QjYrR0k0VHl1Tm9WSGRaczJiTjQ0OC9ycmdXMzVGcWEydHJhbW9pa2NqSXlFZ0cwczRZc202
anJ6d09oVFpwVW1zUmpOTDBMVnUyZUR3ZWw4dEZQNDBSUWkrODhNS01HVE9LaW9xMmI5OU9O
OGl1cmxidmhkMXlaMmRuWldWbGZuNStiVzB0ZVluZkZ5QXJ3YUZkaWdTcGxPQ3dYd0dUaFBB
RmMzajRZamlPS284ajYxcGZmLzExVVZIUjZkT25OVlpoTzFKcGFlbmJiNytkaVVRemlGcTMw
VmNlUjdGSlJZcnFFSXpTOUduVHBnVUNnVWdrTWpBd1FOZmR0bTFiTEJacmJXMWwrejI3dWxx
OUYzYkxDeGN1Ykdob2lNVmlMNzMwRW5tSjM1ZkRrWlhYb0YvbHRFdVJ5RXB3Q0s1bE0vaUNP
VHg4TVJ6bmxNZmhLN2M4Kyt5enExZXYxbGhGMXBGY0x0ZUdEUnNLQ2dyS3lzcllLWmd0aldL
M1VUeURSTXJqOEUwcXNoYkZLRTEvODgwM2I3dnR0dm56NTArZlB2M1h2LzQxV1hkd2NKQnVo
OTBtZmF4Vzc0WGRjbTV1Yml3V3d4aEhvMUh5RXI4dko2TllYa093Rkltc0JJZjlDcGdraEMr
WXc4TVh3M0ZJZVJ5K2F3ME9EcGFWbFduWGhzTVRPMUpSVVZFb0ZCb1lHT2pvNkZBYmhiY2Nh
dDFHUjNrY3ZrbEYxbUl4ZGp4OWVIajR3SUVEQlFVRldGM0gyY2VLOVY1bXo1N05mdEF0V3JT
SStQVDYrbnAyWFhaZmpvV3ZNaUZlaW9RdHdXSFhBaWJpYVBScXZoaU9FOHJqS0ZadWFXeHN2
UGJhYXpYVzRqdlM3YmZmVGpYZGZwOS90TnZvSzQrRHVTWVZYSXZGS0Uwbm4xZWtjTUdMTDc2
SWxYUWNUUVJqckZqdjVROS8rRU5CUVFGOWV1alFvWXFLaXZ6OC9QWHIxN1BiWWZmbFdHUk5l
dkhpUmNWU0pMSzNqQVN6SlRqc1Y4QWtXZFJzQjFZcWh1T0U4amg4MThJWUwxMjZWRForSW1z
cnZpUDE5UFFzWGJvME56Zlg0L0UwTnpkbjhoQXlBRDE4ZmVWeE1OZWtpbXRwQS9WZUFBQUE3
QVA4anhRQUFNQStnS1lEQUFEWUI5QjBBQUFBKzJCMlRZZkJlZ0FBQUhITS9oc3BhSHFLSkZW
bGdsK0MxRXQ1MkJLUkxxMVczVVc3U296OUVPbGFmRnZadU42TE5pS0MyZHpjWEY1ZTduSzV5
c3ZMZCsvZVRaY24xYldTMXZTSUpMK0JwcHNaOFhvUmlrMnRVY3JEeG1qM09zWHFMZ21yeE5n
UGthN0Z0NVZkNjcwa1JLUnZ1TjN1dHJhMmVEd2VEb2ZwZktUSmRpMmpORjJ4M2t0dGJXMStm
djZDQlFzNk96c3h4dSs5OTE1VlZWVnVibTVWVlJXNXFQNmpqejVhdkhneFdZdHRpTE5uejk1
NDQ0MDdkdXdRUENxQUoyRzlDUDU5RkNubFlVdTB6eCsrdW90SWxSZ2JvOUcxK0xheVpiMFhF
WkJLVlNXVzZ1cnE5dmIyZ1lHQmZmdjJMVjY4R092cVdrWnB1bUs5bC9yNitsZ3MxdERRNFBW
Nk1jYVZsWlV2di93eStVZG9WVlVWeHRqbjgyM2R1cFdkU2hVaEZJbEVhbXBxT2pvNkJBOEo0
QkdwRjhHL2p3bExlZGdWN2ZPSHIrNGlVaVhHcm1oM0xiNnRiRm52UlJ4WlZTVVpuWjJkUlVW
RkNLR2lvaUpTSGtCSDF6SksweFhydlpBNkxiRllqQlFWY2JsY3RISkxibTR1eGpnM056Y2Fq
Y3IyV0YxZFhWSlMwdDNkTFhoSWdBekJlaEd5OTFHd2xJY3RTZWpUWmRWZFJLckUySktFWFl0
dksxdldlMGtLV1ZVbGxvcUtpbkE0SEkvSFE2RlFaV1VsMXRXMWpCMVBsOVY3SWE2OG9hRmg0
Y0tGV01tbmU3M2VyVnUzc3VVVkVVSm56cHpaczJmUHZIbnp5SmM0SUNuRTYwWEkzc2VFcFR4
c2pQYkpvMUhkeFZHQ0x0SzErTGF5ZDcyWGhMQlZsWGdLQ3d2RDRmREF3RUJiV3hzZFR5ZGsz
NmVUVHhWWnZSY3lubDVSVVhIbzBDR004Y0dEQnlzcksxMHVWMlZsSmVrWkgzendRWFYxTmZs
b2toMUpRMFBEMHFWTGlhOEh4RUVUVWF3eUlZc2hDL2xTSGs1QXNTbGt6YVZSM2NWUm1pN1N0
Zmkyc25lOUZ3MUlLN0ZWbGJDU2tmSjRQRVEybTVxYVpLc0w3c2dDYzljQkFBQUFnbVIvam1r
QUFBQWdYWmo5ZjZRQUFBQ0FPS0RwQUFBQTlzR01tZzZqTkFBQUFQb3c4RGRTa0dZejBOemN2
SERod3NtVEp5OVpzdVNkZDk1UmpPSGZSOGNXNWRCWHcwU3RBb3lkVU90SUlxVkkyQmhiZGkx
V0RNbEY5L3c1SmRKSmVGRVZPWDlsSkszcEVuY0RUVGN6SzFhc2lFUWk4WGg4OSs3ZGwxOSt1
VVlrKzM0NXRpaUh2aG9taWhWZ2JJWmlSeElwUlNLTHNYZlhrdFZIWWx0R3BKUHdMU2wrL2xL
TTBuUkZGNDhRV3I5K2ZVRkJRVTFORFZhcTkwSlhGRWtkRUNjV2l6VTFOUzFZc0VBamhtMTJ4
eGJsb0NSVnc0UmZZbGZZamlSU2lvU1BzWEhYNHVzanNTMGowa21RU2swWWtmT1hrbEdmamhC
Njdybm5vdEhvZ3c4K2lKWCtSNnEySXBBSzlDdmhoeDkrcUIxR0h6dThLRWV5TlV6NEpiWkUx
cEZFU3BId01UYnVXbng5SkxabHhEdUpyQ2FNNFBsTHliU21zOGFIci9laXRpS1FJdEZvZE5l
dVhZc1dMZEtJWVp2ZHlVVTVkTlF3NFpmWUZiWWppWlFpNFdQczJyVVU2eVBKZkxwNEo1SFZo
QkU1ZnlrR2F2cmt5Wk5sSlNWbGtlRFRNOEQ5OTk5Lzh1VEplRHplMU5RMFk4WU1qVWkyMlIx
YmxFTmZEUk9OQ2pDMlFhTWppWnl3Tk1hdVhVdXhQaExiTXVLZGhLMEpJMzcrVWd6VTlJY2Zm
amcvUDE4Mm5zNEc4UFZlMEVSRURnRFFKaGdNenBzM0x6YzNkOUdpUmVGd21DeVV0UzNmN0E0
dnlrRVJyR0dpVVFIR05paDJKSUxHT2M0dnQydlhrdFZINHM4cHhVNmllQ2F5TldFMG1sME5z
ODlkQndBQUFJaGp4djhjQVFBQUFQb0FUUWNBQUxBUG9Pa0FBQUQyd2V5YURvUDFBQUFBNHBp
OTNndG9lb3FJRkRCSnBaU0h6UkQ1MmQrWjlWNTRSTnFLVlFtMVFpaTJoRDlNa2NvdHpjM05I
bytIWEJ2VDA5T0RkWlhIU1ZyVEF4eWc2V1pHcElDSjdsSWVka1g3cUoxWjcwVU53UjZpVVFq
RnhyQ0hLVks1cGJpNHVLT2pZMkJnSUJRSzNYSEhIVmhYZVJ5ak5KMTM4WWk3aUxXbXBxYWpv
d05qM043ZXZuanhZcXhVQVlaRW5qMTc5c1liYjl5eFk0ZmdVUUU4R2dWTUNNbVc4ckF4Mmtm
dDVIb3ZQQ0k5UkxzUWlvM2hEMU83Y2t0eGNmSCsvZnVKcHBOL0dPa29qNU01bjg1citwWXRX
MWF0V29VeFhybHk1ZGF0VzdIU1Awc1JRcEZJaEtvL29BL3RBaVpZVnlrUEc2TjkxSTZ0OTZL
SVNBL1JMb1JpWTNnTlJKcVZXeG9iRzYrNDRvcXBVNmV1VzdlT2RDUWQ1WEd5b09tRGc0UGs4
Ymx6NTl4dTkvSGp4OTF1OTFkZmZZV1ZLc0FnaEtxcnEwdEtTcnE3dTBXT0IrQkpXTUNFa0d3
cER4dVQwS2M3dHQ0TFQ4THVrYkFRaW8zaEQxT3djc3VCQXdmbXpKbURkWlhITVZEVFpmVmVa
czZjdVcvZnZ2NysvcnE2T3JyS2loVXJycjc2NnBVclY1S25pajc5ekpremUvYnNtVGR2SHZs
NkN5U0ZTQUdURkV0NTJBL3RvM1ptdlJjMUV2YVFoSVZRYkF4N21JS1ZXMFpHUm80ZVBlcnor
V3ByYTdHdThqZ0dhcnFzM2t0OWZiM2I3WjR4WThiV3JWdnB3dmIyZG9SUWUzczdlYXBZQVlh
ODFORFFzSFRwVXVMaUFYSFFSQlFMbUFpVzhuQUNzdWFpQzlrWVo5Wjc0UkZwS3l4UUNNV1c4
SWNwWG5tcHBLUms3ZHExOFhnYzZ5cVBBL1ZlQUFBQTdJUFovM01FQUFBQWlBT2FEZ0FBWUI5
QTB3RUFBT3hENWpRZGh0MEJBQUNNSm5PL2tZS21ad0QrSGRGWFpjS1pCVXl3MHYrZmVaeFo3
NFZ2RnZIVG43MDZ6cFlYVnZCbkdkOGwrTE5NWkRzaTlacGtKSy9wZGR3Tk5OMWtzRTJ0cjhx
RVl3dVlpUFJTSjlkNzRkc25ZWXNwRmc2eW1ScndaeG5mSmZpelRIQTdDZXMxeVRCSzAyV2Y1
K1QraFJkZW1ERmpSbEZSMGZidDJ4Vmp5SVAxNjljWEZCVFUxTlRnc1UvMTNOemM2dXBxS0E4
Z0NQK09KRnRsd3JFRlRCQkNicmU3b0tEZ2xsdHVrYzJRVG5GeXZaZGtOVjJ0Y0pETk5KM0Fu
bVdLblVSMmxvbHNoNUt3WGhNbG81cStiZHUyV0N6VzJ0cEtEbEpOMDU5NzdybG9OUHJnZ3cv
U1Y0ZUdoZzRlUERoNzl1eUVHUUk0SFZVbW5GekFCR044OXV6WjJ0cmFaY3VXS2I3cTVIb3Z5
V3E2V3VFZysybTY3Q3pqdXdSL2xvbHNoNUN3WGhPTDRacE9xN3NnaEFZSEI5bFgrUml5a1Aw
czJyWnRtOGZqSWVWSGNuSnlSQTRKNE4rUlpLdE1PTG1BQ2FHL3Z6OHZMMC94SlNmWGUwbFcw
OVVLQjlsUDAvSEVzMHlqUzlDelRHUTdXTGhlRThVb1RlZXJ1L0R2cUdJRkdOblc4dlB6VzF0
Ylk3RllLQlN5WlQ4d0FyYWg5RldaY0hJQkU0enhoUXNYTm0zYTVQZjdGVjkxY3IwWEhlUHBp
bUUyTzVmNXMweXhTOGpPTXBIdGlOUnJrbUdVcHZQVlhYaE5WNndBSTl2YVUwODk1WGE3M1c3
M3M4OCthN04rWUFSb0lsaHZsUWxuRmpEQlkwMHhaY3FVbTI2NjZiUFBQcU1MMlJobjFudmh1
eGEvQkt1TE5SdWc2Tnd0RFgrVzhWMkNQOHV3UU9VbFdYT1JlazNhUUwwWEFBQUErd0QvSXdV
QUFMQVBvT2tBQUFEMkFUUWRBQURBUG9DbUE0Q3BnZCtyZ0tRQVRRY0FCWFFyYWRvbFdHT0Rh
ZGtYUXVpNTU1N0RHUC8ydDc5TlpZTUlvYzJiTjZlZUdGL2hwTG01dWJ5ODNPVnlsWmVYNzk2
OVcyM3ZzdXMxNHZINFF3ODlSTW9TcU9YRFYyVVJ1ZlNEejFDazRJL0lXdnl1ZFZ5SEFwb09B
QW80U3RNckt5dEhSa1lXTEZpUW9xWlhWRlJjdUhBaHhjVDRDaWR1dDd1dHJTMGVqNGZEWWJm
YnJaMERmVnhiVzF0VFV4T0pSRVpHUmpUMkphdktJcEk1bjZGSXdSL3h0ZmdjUU5NQklGVVV6
eXMwc2ZUUWxpMWJQQjZQeStXaVRrckU1Y2xjR0xtdnJhM056ODlmc0dCQloyY254cml6czdP
eXNqSS9QNysydHBiZE1ydDNmbDlIang2OTVwcHI4dkx5NXMrZlQydHdKcFFEaE5CMTExMjNh
ZE9tNjYrL25nUy85OTU3VlZWVnVibTVWVlZWZEZwZ1diRW14ZTBFQW9IZi9PWTNkS2Y4ZG1w
cWFrank3ZTN0aXhjdjFrNk1WamlwcnE1dWIyOGZHQmpZdDIrZjlscnN3WmFXbHI3OTl0c2FB
VmlwS2d0U0t2aWoxb1kwdzZRSy9pUmNDelFkQU5LUDJsbkVsaDZhTm0xYUlCQ0lSQ0lEQXdN
SlYxUU1vSHBkWDE4Zmk4VWFHaHE4WGkvR2VPSENoUTBORGJGWTdLV1hYbUxqWllXUFpQdGFz
bVRKcTYrK0dvL0gyOXJhNXMrZkwzNmtPM2Z1bkRScDBxNWR1OGdHS3lzclgzNzU1VmdzVmw5
ZlgxVlZoWldLTlNsdTUrTEZpMWRlZWVYWFgzK3R0cDB0Vzdhc1dyVUtZN3h5NWNxdFc3ZHFa
TVZXT09uczdDd3FLa0lJRlJVVmRYVjFhUjhMZmV4eXVUWnMyRkJRVUZCV1ZzWk9jczJpVnFo
SHUrQVBuNkY0d1IrUnRVRFRBU0Q5OEdjUlgzcm96VGZmdk8yMjIrYlBuejk5K3ZSZi8vclhh
aXVxYlprdGhSU0x4VERHc1ZpTUZKbkp6YzBsUzZMUktJbFJMSHdrMjFkdWJpNTE3dUxGa2Zq
UEdKZkxSZmVlbTV1TGxZbzFxVzNubVdlZStkV3ZmcVcyblhQbnpybmQ3dVBIajd2ZDdxKysr
a290SlZtRms0cUtpbkE0SEkvSFE2RlFaV1dsNExFVUZSV0ZRcUdCZ1lHT2pvN2k0bUxGZUky
cUxCb0ZmL2dNQlF2K0NLNEZtZzRBNlljL2k5UktEdzBQRHg4NGNLQ2dvSUE4blR4NXNscVJY
b0ppS1NUaVp4c2FHaFl1WElneFhyUm9FZkhwOWZYMUpFWng3N0o5K2YzK2xwYVcvdjUrM1Vl
cTRkTTFXb1pkSG8xRzU4NmRxN1lkalBHS0ZTdXV2dnJxbFN0WHF1WERWemdwTEN3TWg4TURB
d050YlczaTQrbTMzMzQ3MVhRMW5WVXIxS05kOElmUFVLVGdqL2hhb09rQWtIN1FSTEJTNlNI
eTBxUkprK2JPbmZ2aWl5K1NGUjkrK09IOC9IeU5rMUN4RkJJWlQ2K29xRGgwNkJERytOQ2hR
eFVWRmZuNStldlhyMWZiTzcrdlk4ZU8zWFRUVFdRSlhhaGpMT2pnd1lPVmxaVXVsNnV5c3BL
T3B5dkdLMjVuOCtiTmF0dkJHTGUzdHlPRTJ0dmJOZkpodVhqeFltTmpJL21PTW5mdTNLYW1K
cEcxTU1ZOVBUMUxseTdOemMzMWVEek56YzJLeWF0VlpkRXUrTU5uS0ZMd1IyUXQvaWo0SlFr
QlRRZUFMSk9VQ3dNQWJVRFRBU0RMZ0tZRGFRUTBIUUFBd0Q2QXBnTUFBTmdIMEhRQUFBRDdB
Sm9PQUFCZ0gwRFRBV3ZRMHRMUzJ0bzZORFRVMnRyYTB0SWl1SXIycTJvQjBXZzBGQW9weG11
c0JRQm1BRFFkc0FZdExTM3Z2dnZ1WC8vNjE3Lzg1Uy9wVWxXMTdYejAwVWY4U3lEbGdDVUFU
UWVzUVV0THk3Rmp4OExoOExGang2aTh5aDYwdExSMGQzZUh3K0dqUjQrcUxaUnRrOS9SaFFz
WDJ0dmJGVFU5SEE3djM3Ky90N2MzclVjR0FPa0VOQjJ3QmkwdExlZk9uYVAzZENIN29LV2w1
YXV2dm9wR28yVE9kY1dGc20zeU8vcmdndzk2ZW5vVVh4b1pHZW50N2QyM2IxLzZEZ3NBMGd4
b09tQU5XbHBhUmtaRzNucnJyWkdSRVNxNDRYQTRHbzFTbGVjbG5sOG8yNmJpanRUR3pVZEdS
czZjT1FPYURwZ1owSFRBR3JBS1N4OGZQWG8wSEE1M2QzZnIwSFNaY1BPdjhnOWFXbHIyNzkv
LzVaZGZwdlBBQUNDdGdLWURBQURZQjlCMEFBQUErd0NhRGdBQVlCOUEwd0VBQU93RGFEb0FB
SUI5QUUwSEFBQ3dEK09hM3RuWnVSTUFBQUN3UGdnRUhRQUF3RGI4LzFETSs3NmVBZ3hWQUFB
QUFFbEZUa1N1UW1DQyIgLz48YnIgLz4mbmJzcDs8L3A+PHA+SW4gdGhlIG5leHQgcGljdHVy
ZSB5b3Ugc2VlIHRoZSBvdXRwdXQgb2YgeGVucG0gdmlzdWFsaXplZC4gU28gdGhpcyBtaWdo
dCBiZSBhbiBpbmRpY2F0b3IgdGhhdDwvcD48cD5yZWFseSBzb21ldGhpbmcgaGFwcGVucy4g
SXQmIzM5O3Mgb25seSB0aGUgY29yZSB0aGF0IEkgZGVkaWNhdGVkIHRvIHRoYXQgRG9tVS4g
SSBoYXZlIGEgdGhyZWUtY29yZTwvcD48cD5BTUQgQ1BVIGJ5IHRoZSB3YXk6PC9wPjxwPiZu
YnNwOzwvcD48cD48aW1nIGFsdD0iIiBzcmM9ImRhdGE6aW1hZ2UvcG5nO2Jhc2U2NCxpVkJP
UncwS0dnb0FBQUFOU1VoRVVnQUFBZkVBQUFFa0NBSUFBQUN3bzUrMkFBQWdBRWxFUVZSNG5P
MmRhM1JVVlpyM043a1pBcWFTUUJpQ1VDRmdTSUNBWW1nRVdtM2FHVHM5UFRSZUFycG93T25W
MHpockFJMEdkSTJqaTZZQnRVVUgydVlpTFNPR1lCUk1WUzRJZ2tZa2FiVVg0U1pta1lBaEYw
RXVxVXV1Kzh1c05SL3EvYkRmUG4wNGw2cGRweTduOXYrdFo1MXpzcyt1dmYvbnFWTlBudXlx
UEVXK0FRQUFZQWthR3h1SjNob0FBQUJFZ2NiR3hyMTc5LzcvbUU0QkFBQ1ltYjE3OXlLbUF3
Q0FSVUJNQndBQTY0Q1lEZ0FBMWdFeEhRQUF6RVMxRFBGWnhIUVFWd2doa2dPRGMvVG8wZkhq
eHh0VHJSRlVHVUdEUFJrYUdtTFJIREVkeEFPMWwzcFVZbm84NDBoeGNmSEJnd2ZqTmwxWUdD
R2VHa0dERFJrWUdEaDkrclRMNWJwKy9YcE5UWTM0RkdJNm9HZlBubDIwYUZGbVptWktTc285
OTl5emYvLysyTTJsTGFickdEaFNVMVA3K3ZwaU5IaE5UYzFQZnZLVDFOVFV6TXpNSjU1NG9x
dXJLNnlIR3lHZUdrR0QzV2hyYXp0MDZGQlRVMU43ZTN0TlRjM3AwNmZGWnhIVDdjNzU4K2Yv
NFIvK1lkdTJiVmV1WFBINy9TZE9uSGo0NFlkak41M3BZbnBNcDM3d3dRZmRibmRQVDA5WFY5
ZktsU3QvOHBPZmhQVndJOFJUSTJpd0cxOTg4Y1gxNjlmVnppS20yNTNISDMvOEQzLzRnK0lw
UXNpbVRadXlzN1BUMHRLV0wxL3U5L3VGZGtrM3hjZXlBNy9mdjJ6WnNyUzB0REZqeG16ZXZG
a2Uwd2NHQnNyTHkwZVBIajE4K1BEUzB0S2JOMi9LaHhLUVBKWVFzbTNidHR6YzNKU1VsS2xU
cDM3MjJXZTdkKytlUEhseWNuTHl6Smt6VDU0OHlUa0ZwZFRuOC8zcnYvN3I3YmZmZnZ2dHQv
LzYxNy8yK1h5S1V3djA5Zld0V2JObTFLaFJEb2ZqbFZkZWlkeGpIby9udHR0dWs3Y0hRWEc2
K2ZQbnYvZmVlMEtmdHJhMnNXUEhpa05BWGw3ZXFWT24yUEh1M2J2WndhbFRwL0x5OHFpNnI5
VGFoV3Y1eTEvK01tN2N1TmRmZnoyc1N3QlJCekhkN293Wk0rYnk1Y3VLcHdnaEpTVWxYVjFk
WFYxZEpTVWx6ejc3ck5BdTZhYjRXSFpRVmxiR0J1bnM3SHpvb1lma2NmbmxsMTkrOE1FSEwx
MjZkUFBteldYTGx2MzJ0NzhOTXBya1IwTElva1dMTGw2ODZQRjRmdmU3MzQwY09mTFJSeDhW
ZnZ6UmozN0VQOFV6enp3ajZQeW5mL3Fuc3JLeUlGZEhLVjIzYnQwLy91TS9YcnAwNmRxMWE2
dFhyNDdjWXdjT0hMai8vdnNWNTFKRGNicmEydHFDZ29MQndVSFc1OGtubjl5NGNhUDRVU3RY
cnR5MmJSdWw5TktsU3lOSGptVFJlZXZXclU4OTlSUlY5NVZhTzd1VzZ1cnEwYU5ISHpod0lD
ejlRQnY0M0FzSVJsSlNVbjkvditJcFFzaTMzMzdManMrZlAzL0hIWGNJN1pKdWlvOWxCK1BH
alJNRytlYWJiK1F4M2VsMG5qdDNqaDEzZG5hT0dUTW15R2lTSHdraFY2NWNZY2NlajBmeVkx
SlNFdjhVT1RrNTU4K2ZGM1NPR3pjdXlOVlJTdSs0NHc3NVMwYXp4NzcrK3V2YzNOeHdYNE5x
MHhVWEY3Lzc3cnRDbzhmakVUL3E0TUdEcGFXbGxOS05HemVPSGoxNng0NGRsTkxISG52c280
OCtvdXErVW1zbmhQejNmLzkzVGs1T1kyTmpXT0pCaE9CekwwQ1o0SG42d01BQU8rN3Y3eGRD
WkZneFBURXhVVHlJUEtZbkpTV0psemlHRFJzV1pEVEpqOEdWaERXRlJLZmF4WXI3eTM4WGF2
UFlKNTk4TW1IQ0JMV1lxTGI0RTJTNkF3Y081T2ZuRHd3TUxGbXk1STAzM3BBOHFxZW5aOEtF
Q1pUUzZkT251MXl1ZSsrOWwxSTZZY0lFRnZyVmZLWFdUZ2laT0hIaTJyVnJGY1dER0lIUHZR
QlZIbi84OFMxYnRpaWVFcWVCMzM3N3JaQzZKaVVsQ2FuZmxTdFgrUFAwOCtmUHk4UHgrUEhq
di92dXUrQWlJNHpwUEZQazVPU0kvNTdJeWNsUkhGTWdaSjdPNmJHS2lvcWNuSnltcHFiZzho
UlJtMjVvYUdqNjlPbGxaV1ZPcDdPM3QxZit3UHZ2djMvZnZuM0Z4Y1dVMHVMaTRnTUhEanp3
d0FQc2xKcXYxTm9KSVpjdVhabzBhZExtelpzMVhBTFFBRDczQW9KeC92ejVzV1BIL3VsUGY3
cDY5YXJmNzI5c2JCUSs5MElJK2VkLy91ZnU3dTd1N3U2Zi8vem53aEx6ckZtelhucnBKWS9I
ODkxMzN6M3l5Q01oMTlQWklHek5WeDZPZi9lNzM1V1VsTFMwdFBUMzk1ODhlWkl0QzBod09C
ekNILzQwL0pqT004V2FOV3VFdGVtSEhucm82YWVmVmh4VDRQbm5uMWRjVHcvTFk2KysrdXFF
Q1JQT25EbWpPRVZJMUthamxGWlVWQkJDZHU3Y3FmakFqUnMzamhzM2pxWHdXN1pzdWVPT096
WnQyc1JPcWZsS3JaMWRTM3Q3ZTM1Ky9vWU5HN1JkQ0FnTGZPNEZoT0RNbVRPLy9PVXZIUTVI
U2twS2NYR3g4UGwwOGNjcWxpMWJ4ajRLUWluOTZxdXY3cnJycnFTa0pLZlR1VzNidHVBeDNl
ZnovZXBYdnhvK2ZIaDJkcmJpNTE0R0J3YzNiTmpnZERxVGs1T25UWnRXVVZFaEgyMzkrdlVq
Um95UVA1WXpwdk5NNGZWNlY2eFlNWExreUpFalI2NVlzY0xyOVNxT0tkRFgxN2RxMWFyTXpN
eU1qSXpYWG50Tm04ZUlqSjZlSHNYcEZGR2JqbEs2Zi8vK3laTW5xNzFUOHZYWFh5Y2xKWFYz
ZDFOS3U3cTZrcEtTL3ZyWHZ3YjNsVnE3Y0MwZEhSMEZCUVV2di93eXYzNFFDeERUZ1NwcTRR
eW9ZUnlQL2VJWHY5aTdkNi9lS2tCTXdPZGVnRWFNRTZITWdoRThOamc0dUgzNzlzTENRdUhq
ak1CaVNJSTRZanJneFFnUnlsd1l3V09FRUtmVGlVOFdXcGlhbWhxaFhrVmZYeDgrOXdJQUFD
YW1zYkh4MUtsVC9mMzkvZjM5cDA2ZGtueG9DakVkQUFETWhNL25PM0hpaE52dGRydmRqWTJO
NHZmR0tXSTZBQUNZR3F5bkF3Q0FkVUJNQndBQUUyT2p6eksySERuU2N1U0kzaW9BQUNCK1dE
YW05L3Y5VytmTjJ6cHZYdi9maWxZREFJRGxzV3hNLyt6MTF6YzRuUnVjenM5UWxSOEFZRmNz
RXRPdlg3cTBPVCtmeGZUTitmblhMMTNTV3hFQUFNUUVyOWZiMk5nb2ZKWlJxRTNFc0VoTXIx
eXhnZ1YwWnBVclZ1aXRDQUFBWWtKRFE4TzVjK2Y2K3ZyNit2ck9uajNiME5BZ1BtdVJtTTU0
NFlVWDJFRjdlenRQL3o2K0dxYzhvM0hPeU5NTnF2aTdRUlYvTjJPcW9uekNvamlqTVZXRmhj
dmxFb3I1REE0T3Vsd3U4VmxyeHZRdnYveVNwLytOSFR0NHV2R014amtqVHplbzR1OEdWZnpk
akttSzhnbUw0b3pHVkJVV3RzalQrL3I2V2x0YmYvT2Izd1FDZ2M3T3p2LzkzLy90N094a3gw
RzI3ZWZPaGV6RE9Scm5qSmN1WFlJcXFJSXE4ZmIvdk41NHptZ2NWZDk5OTExcmE2dUdMTjdq
OFZoL1BaM3h3Z3N2QkFLQlFDRFEwZEVSNElBMk5mRjA0eG1OYzBhZWJsREYzdzJxK0xzWlUx
V0FUMWdVWnpTVXFsaUVRV3ZHZEFBQU1EN2FBcDB0UHZmQ1FKNnVvUTluTjZqaTd3WlZZWFZE
bmg0dTVsaFBGNzZQVVdpcHJLd3NMQ3hNVGs2ZU1XUEdvVU9IS0tYZmZmZmQzTGx6VTFKUzVz
NmRxL2dWNXNqVEFRQW1RbHUwTk5QblhzUXgvZEZISDIxdWJ2YjVmRHQyN0JnMWFoU2xkUEhp
eGVYbDVUNmZyN3k4Zk1tU0pmS0hJMC9YMEllekcxVHhkNE9xc0xvaFR3OFhjK1RwRE1Xdi9t
cHRiWFU2blpUU1VhTkdkWFoyVWtvN096dFpsSmVBUEIwQVlDSzB4VWt6ZmU1Rkh0TTdPanBt
elpwMThPQkJTbWxDUWdMN2kyTmdZQ0F4TVZIY2JlREtsUnR2dmJWdTVVcDY0a1FnRU9nOGVE
QVFDTERqSUZ2YTFCU3lEK2RvbkROMmRIUkFGVlJCbFhqcmUvdnRlTTVvSEZYLzUvZmZlT3V0
M3VibTZFWlJROGYweHNaR3A5TzVaODhlOW1OV1ZoYnlkQUNBWmRBV0o4MVVQMTBjMDdkdjM1
NmRuVjFYVnllMGxKYVdDdXZwcGFXbDhvZGpQVjFESDg1dVVNWGZEYXJDNm9iMTlIQ1JCSEVK
Um9ucDVGYmtMVDA5UFJjdlhwd3paMDV5Y3ZLOTk5NTdTYW55SXZKMEFJQ0owQll0elJIVG93
THlkQTE5T0x0QkZYODNxQXFyRy9MMGNMRmpUQWNBQU9NVGl6Qm96WmlPUEoyL0QyYzNxT0x2
QmxWaGRVT2VIbDBzRXRNbGRSbXh4UlpiYkEyKzFWYVg4ZkRodzgzTnpaMmRuUU1EQTRvZExC
TFRHY2pUTmZUaDdBWlYvTjJnS3F4dXlOUEQ0c2FOR3kwdExjZVBINitwcVRsKy9IaExTOHVO
R3pmRUhhd1owd0VBd1BoRUV1NzYrL3M3T3p1Ym01c1BIejRzYnJkbVRFZWV6dCtIc3h0VThY
ZURxckM2SVUrUExrYUo2Zks2alBJVzFHVUVBRmlKV01SU284UjBocnplaTdnRmRSbkRIUXFx
K0llQ0t2NmhrS2VITlpSTjgzUkc4SmlPdW93QUFDc1JsYkJwbW5vdjhoYlVaWVFxcUxLWXFn
RHFNa1pjbDlIRU1SMTFHUUVBVmtKYm5EUnJYVVo1QytveWhqc1VWUEVQQlZYOFEyRTlQYXlo
WXIyZWJ0Q1lIckl1STZVVWRSa0JBRllpS3NIVG9ERTlLaUJQMTlDSHN4dFU4WGVEcXJDNklV
K1BMdGFNNlFBQVlIeTBCVHF2MTJ1YTd5T05FT1RwR3Zwd2RvTXEvbTVRRlZZMzVPbmgwdERR
Y083Y3ViNit2cjYrdnJObnp6WTBOSWpQV2lTbW95NGp0dGhpYTY2dHRycU1sRktYeThVKzFV
MHBIUndjZExsYzRyTVdpZWtNNU9rYStuQjJneXIrYmxBVlZqZms2ZUZpaXp5ZGdmVjBBSUNK
MEJib1BCNFAxdE5WSEdySXpBV3ErTHRCRlg4M1k2b0tJRStQTmthSjZUeFZHRkdYRVFCZ0pi
UkZTN1ArSDZtOENpUHFNb1k3RkZUeER3VlYvRU1oVHc5cnFLam42U3lJQzZIY05ERmRYb1VS
ZFJrQkFGWkNXNXgwdTkwM2I5NTB1VnczYnR5NGNlTkdiVzJ0K0t4eFk3cThDaU5QWGNaSFRv
d25BYkxtNEZ3U0lPdzR5SFpSMC9pUWZUaEg0NXl4cUtNSXFxQUtxc1RialcvUGpPZU14bEds
dVM3anFWT25hbXBxMnRyYURoOCs3SGE3TDF5NElENXIzSmd1cjhMSVU1ZVJCQWdNQm9NWjN6
VG42Y0V4Ymt5WFYySGtxY3ZJbkZYVVVjVGowMFZONDNtNjhZekdPU05QTjZpQ0t2dW80aFFX
eFJtTm8wcHpURGZIZTZROFZSaDU2akx5dUJnR2c4RjBOMXZrNlJHQ1BCMnFvTXBjcWppRklV
L254NW94SFFhRHdReHVpT21oUVo0T1ZWQmxMbFdjd3BDbjgyT1JtQzdVWlNRQk1yMXpPcmJZ
WW91dHdiZWE2ekxhcTM0NmlmYXZZczdSTEo5UFFSVlV4VUlWcHpEazZXTHNWWmVSeDhVd0dB
eW11Mm1PNmZhcW44NmNoVHdkcXFES0ZLbzRoU0ZQRnhPRlBIMzM3dDJabVptWm1abnZ2UE9P
TmhFYWNMbGNreVpOU2tsSmVlQ0JCOWkvai9MVVplUnhNUXdHZytsdW1tTzZ4dnJwZnI5Zk9N
N0l5R2hxYW1wcWFzck16TlFtUWdQWjJka3VsOHZ2OTd0Y3JxVkxsMUsrdW96TVdjalRvUXFx
VEtHS1V4anlkSDVVWS9xRUNSTjI3ZG8xTURCQWRZcnBvMGFOY3JsY3ZiMjlMcGRyOU9qUmxL
OHVJNCtMWVRBWVRIZUxkMjJBaG9hRytmUG41K2ZuNzl1M2IrZk9uUmtaR1JrWkdidDM3OVlt
UWdOVlZWVVRKa3dZUG56NHFsV3JrcEtTS09veVFoVlVXVTRWUVYzRzhPc3lSbFEvM2UxMjMz
MzMzVE5uenBTOHRScFBYQzZYMCtta3FNc0lnOEVzWkpIazZWUkRUQmZlRi8zem4vKzhiOSsr
L1B6OHVYUG5IanQyVEpzSWJRd05EWjArZmJxd3NQRDN2Lzg5UlYxR3FJSXF5Nm5pRkliMWRE
RWFZM3BtWm1aalk2T3doajR3TUxCejU4NEpFeVpvRTZFQlZxQng3Tml4Ly9WZi84V1dYRkNY
RVFhRFdjYWk5UjRwYjB4WGZGOVUvR0VZQTRJOEhhcWd5bHlxT0lVaFR3OENiMHpmdFd0WC9O
OFhqUkRrNlRBWXpDeG04ZS9FaUFySTA2RUtxc3lsaWxNWTh2UWdXRE9tb3k2ajNiYWQwL1hY
Z0MyMmtXdzExMldVWU0yWXprQ2ViaDlWQVdKRVZjYjBsWkZWY1FwRG5zNlBOV002ektURzlw
dzlkVmNMZzBWaVdFOFBEZkowczZ0aWU1NmhBc2pUTGFHS1V4anlkSDVDeFBTR2hvYjgvUHho
dzRaUlNwOTQ0b21LaW9wWWlGQ2txcW9xTHk4dk1URng0c1NKVlZWVkZIVVpiV0JzejlsVGQ3
VXdXQ1NtVDU1KzU1MTMxdGJXRWtJb3BSY3ZYc3pOemRVbVFnUHA2ZWx1dDV2VlpYUTRIQlIx
R1cyZ2l1MTVoZ29nVDdlRUtrNWh5Tk1sOVBiMkhqdDJyS2FtcHJ1N1czSXFSRXhQVGs3Misv
MHNwbCs5ZWpVdExVMnppSEFwS2lweXU5MnNMdVBNbVRNcDZqTGF3TmllczZmdWFtR3dTRXh6
VEdjQi9keTVjei84OEVOZFhkMzE2OWZGWjBQRTlBVUxGdXpldlpzUTB0N2Uvc1FUVHl4YXRF
aWJDQTJjT0hFaVBUMmRFSktlbm43aXhBbUt1b3cyVUJVZ2hJN25VaFVnZHZlVk5WUVIxR1VN
dnk3ajBhTkhoWEI5K2ZMbFE0Y09pYytHaU9udDdlMExGeTVNUzB0TFMwdGJ0R2pSOTk5L0gr
NzBtcGs4ZWJLdzluTG5uWGRTMUdXMGdiRTlaMC9kMWNKZ2taam1QRjBTcXk5Y3VDRCswYmlm
ZThuSXlCRFdYbGpOR2RSbHRMd3F0dWNaS29EMWRFdW80aFNHOVhReEViMUh5bGJTMVg2TUta
V1ZsVTZuTXpFeE1UYzM5LzMzMzZlb3kyZ0RZM3ZPbnJxcmhjRWlzWGpYMm1XSWcvaUZDeGZp
K1I2cEJwQ25tMTBWMi9NTUZVQ2ViZ2xWbk1LUXA0dlJHTk9KakxTMHRMVnIxMm9URVIrUXA1
dmQySjZ6cCs1cVliQklUUDg4M2ZnZ1R6ZTdLcmJuR1NxQVBOMFNxamlGSVUvbng3anZrWVlG
NmpKYVk5czVmWHFBOFBiVVhTMjIyRWF5MVZ5WE1hTDNTQThlUEppYm16dHMyREJoQlVaNzNJ
MDl5TlBOcm9ydGVZWUtJRSszaENwT1ljalQ1UXdORFVrV1lSZ2hZbnBPVHM3Um8wY0pJVGR2
M2x5OWV2WExMNzhjaVloWWcvVjBzeHZiYy9iVVhTME1Gb2xGRXRNSEJnWk9uejd0Y3JtdVg3
OWVVMU1qUGhWNlBYMXdjREFoSWFHdnI4L2o4V1JrWkdnV0VRZVFwNXRkRmR2ekRCVkFubTRK
Vlp6Q2tLZUxhV3RyTzNUb1VGTlRVM3Q3ZTAxTnplblRwOFZudWQ0am5UeDVzc3ZsT25yMGFE
eGp1dmdqTjFsWldSUjFHVzFnYksvWUhySUZCak9YYVk3cFgzenhoYVRHaXhpdTkwZ1BIRGlR
bloyZG5wNitjK2RPYlNJaTRmang0ODgvL3p4RlhVWWJxR0o3ZWJlQVNreTNzNitzb1lwVEdQ
SjBma3p3dVplU2twTExseTlUMUdXMGdiRzlZanU1TmJJcmRvUEJUR1Q2eEhRZGF3TXdHaG9h
bGk1ZHlvNVJsOUh5cWdJcWRSa0Q1TzliY1U4Nys4b2FxZ2pxTW9aZmx6RTRScThOc0dEQmdx
Kysrb29kb3k2ajVZM3RGZHNsWjlWNndtQm1zWGpuNlVhb0RYRHMyTEg3N3J0UCtCRjFHUzJ2
aXUzbDNjUzl4QzEyOXBVMVZIRUt3M282UDRhdURYRC8vZmQvK09HSHdvK295Mmg1WTN1MWR2
Rlp0WjR3bUZuTXZ1K1I4b004M2V5cTJGN2VUZHhMM0dKblgxbERGYWN3NU9uOHFNYjBqejc2
cUtTa2hCMnZXclVxTFMxdDBxUkpmLzNyWDJNaElsb2dUemU3c2IxYXUzQldmQXlEbWRUaUhk
UG56WnQzOU9oUlNxbkw1Wm8yYmRxVksxYzJiZHIwMDUvK05CWWlvZ1h5ZExPclludWhXK0RX
ckZ3NEt4emIyVmZXVU1VcERIazZQNm94L2JiYmJ2UDcvWlRTMWF0WC8vNzN2NmVVWHIxNmRl
VElrYkVRRVRtb3kyaU5yYVF1bzNETTJ1VmJJMmpHRmx0dFc4MTFHWU9qR3ROSGpoeDU1Y29W
U21sSlNRbDdvOUxuODkxMjIyM1JuVDY2SUU4M3V5cTJGN29GbFBKMHNkblpWOVpReFNrTWVU
by9xakg5b1ljZTJyUnAwOFdMRnpNek03dTd1eW1sbjN6eXlZOS8vT05ZaUlnV1dFODN1N0c5
K0VkeHU5eDBGd3lEYWJaNHgvVFRwMC9uNStlbnBhVnQzcnladFpTVWxMaGNybGlJaUJiSTA4
MnVpdTJGYmdIazZWWlh4U2tNZVRvL3h2MHM0K0RnNElzdnZwaVRrOE8ra1lPaUxxTU5qTzNW
anVXbXUyQVlUTFBwR2ROMStjK2o5ZXZYVDVreXBibTVlV2hvaUxXZ0xxUGxWYkU5MjNVVUlV
KzN2aXBPWWNqVCtURnVUSGM2blpLbEh0Umx0THl4dmRxeDNIUVhESU5wTnR2RjlNVEV4Tldy
Vnc4ZlB0enBkQjQ0Y0lDaUxxTU5WQVZFZFJrN2lvcUVZOVl1MzlyWlY5WlFSVkNYTWM1MUdY
VmsxS2hSTHBmTDcvZTdYSzdSbzBkVDFHVzBnYkc5MnJIY2RCY01nMmsyMjcxSHVtVEpFcGZM
MWR2YjYzSzVzck96S2VveTJrQVYyN01kMXRQdG9JcFRHTmJUK1ZHTjZXKy8vZmJ5NWN2Rkxj
dVdMZHU5ZTNjc1JDalMzdDUrMzMzM0pTY241K1hsc1lWMTFHVzB2TEc5MnJIY2RCY01nMm0y
ZU1mMHZMeThscFlXY1V0TFM4dWtTWk5pSVNKYUlFODN1eXEyWnp2azZYWlF4U2tNZVRvL3Fq
RTlPVG01cjY5UDNOTGIyNXVTa2hJTEVkRUNlYnJaamUzVmp1V211MkFZVExQRk82WVhGQlEw
TkRTSVd6Nzk5Tk9wVTZmR1FrUzBRSjV1ZGxWc3p3NlFwOXRCRmFjdzVPbjhxTWIwZDk1NVor
TEVpWFYxZFY2djErdjExdGJXNXVibXZ2dnV1N0VRRVRtb3kyaU5yVkJ0TVVBVWpsR1hFVnNy
YmVOZGw1RlN1bi8vL3VMaTR0VFUxTlRVMU5teloxZFZWVVYzN3FpRFBOM3NxdGllM0pxbkJ4
bk16cjZ5aGlwT1ljalQrVEh1WnhrMWdQVjBzeHZiRTFFY0owRmp1dTZDWVRETmhwZ2VHdVRw
WmxmRjlnUjV1bTFVY1FwRG5zNlBjV002RWNGYVVKZlI4c2IyQkhrNnpBWm14NWd1YVVGZFJz
dXJZbnVDUE4wMnFqaUZJVS9ueDlBeC9mYmJiMDlMU3lzcEtXbHRiYVdveTJnRFkzdUNQSjNQ
VjdwcmdFVml0b3Zwaks2dXJyS3lzamx6NWxEVVpiU0Jxc0RmNmpMUzhYK3Z5NmhZa1RGZys3
cU1BV0pFVmVINmlxQXVZOXpxTXBKYmNUZ2NpeGN2L3Y3Nzc2TTdQUTllcnpjNU9abWlMcU1O
ak8wSjhuUStYK211QVJhSjZaeW5kM1YxclZ5NThwZS8vR1VzUkFUaDJyVnJMN3p3UW5GeE1V
VmRSaHVvWW51QzlYUStYeGxRbFladVdFK1BMbUdzdmR5NGNTTXRMUzBXSWhSaGZ4K2twcVl1
V0xEZy9QbnpGSFVaYldCc1Q1Q244L2xLZHcyd1NNeDJNVjBEeU5QTnJvcnRDZkowUGw4WlVK
V0dicEZreEFFUzlvekkwLzgvM2QzZEsxZXVYTGh3WVN4RVJBdms2V1kzdGlmSTAvbDhwYnNH
M2MzVVRvaDNUSmU4UjVxZW52N1lZNDkxZDNmSFFrUzBRSjV1ZGxWc1Q1Q25oK01yUTZuUzBB
MTVlblF4K21jWk9VRmRSbXRzVVpkUmc2OTBWNkxqMXRRZTBLRXVvK2xBbm01MlZXeFBrS2VI
NHl0RHFkTFFEWGw2ZEZHTjZaOS8vbmxoWVdGU1VsSmhZZUVYWDN3Umk3bWpEdGJUelc1c1Q3
Q2VIbzZ2N0d5bTlrQzhZL3EwYWRPMmJObmk4WGkyYk5sU1ZGUVVpN21qRHZKMHM2dGllNEk4
UFJ4ZkdVcVZobTdJMDZPTGFreFBURXpzN2UybGxQcjlmc2svNHNlVEYxOThFWFVaN1dOc1Q1
Q25oK01yTzV1cFBhREQ1MTRVaitOSlUxUFQyTEZqaGRsUmw5SHlxdGllSUUvbjloVnprWEZV
YWVpR1BEMjY4SDZXVVZMS1BBNzRmTDdwMDZjZk9YSkVtQlIxR1MxdmJFK1FwM1A3Q2s3UVhZ
TjI4WGI3TE9PcVZhdGVlKzAxS3ZvckFYVVpMYThxZ0xxTVlmb3FRSXlsS2x4ZmtjZ3FJTEk3
Skt3WjQ2Q0tjOFo0MTJYVW5XSERoa24rUGtCZFJzc2IyeFBrNmR5K2doTjAxNkJkZkp6ejlM
ZmZmbnY1OHVYaWxtWExsdTNldlRzV0lvSWo1T21veTJoNVZXeFBzSjdPN2FzQTF0T2pLbDV3
S2ZzTElLWitpSGRNejh2TGEybHBFYmUwdExSTW1qUXBGaUtDSThSMDFHVzB2TEU5UVo3TzdT
czRJVVplallOajR4M1RrNU9UKy9yNnhDMjl2YjBwS1NteEVCRXRrS2ViWFJYYkUrVHAzTDRL
SUUrUHFuamgwSUo1ZWtGQlFVTkRnN2psMDA4L25UcDFhaXhFUkF0NW5oNndkeFpqT21ON2dq
eWQyMWR3UW95OEdnZkh4anVtdi9QT094TW5UcXlycS9ONnZWNnZ0N2EyTmpjMzk5MTMzNDJG
aUdnaHhQU09vaUtlcDl5WW1ZdWRWYkU5UVo3Tzdhc0E4dlNvaWhjT0xaaW5VMHIzNzk5ZlhG
eWNtcHFhbXBvNmUvYnNxcXFxV0NpSUNwSzZqSUcvVld2cm5LNS85VFZzK2Jlb3l4aXVyMngr
aDBmRkEySlB4dlB1UWwzRzBJanpkT0hYSVlrc1FTQVd6ZklNcFVwNG1vU25MSUE4UFZRZjRk
QlFxalIwaXpCUEQ0VDVmVStLdDU4d2puQnN6VHpkZEFneFhldzZIcWZEOUxXQVVreVhIOHRO
ZCtYNk9nMU9pSW9IeEo0VW40bTVlTVQwa0NCUE42bXFBUEwwOFBzSWg0WlNwYUdid2ZQMEFK
RjJqcFlmYkJmVEt5b3E4dlB6azVPVFo4eVljZWpRSVJwT1hVYXg2M2ljRHRQUjJGNXlMSndu
eU5PRCtnMU9pTndEWWsrS3p3aG5KWjJqSnQ1dU1YM3AwcVd0cmExZXIzZmZ2bjFaV1ZrMG5M
cU15Tk5OcEVyOE5BbkhBVFBrNlFHVnV5dUtxb1JQY01sTk9BdzVGT3RqelB1S1U1alI4blFl
dDRjV2I3ZVl6dkQ3L2UrLy96NzdVZzcrdW94aTEvRTRIYWFqc2Iza1dEaFBESnlueDBGRGtQ
SDVuUkIxa2JwN1h1S0VxQXdTQ0NkUGo0b0g3QmpUV2ZXdWpJd005dVY1L0hVWk8rZk9EWWlx
MWhGVFZhcXptNm9BK1h0MXZZQ3A2aktLbGNmSVY1MXpJNjNMS1BTSmo2cHc3eXNTY1YxRzhX
dWNaMFpKSC9FZEpmYXFiK1pNd2MrUy9zSVdkUm0xd05aZVdKMFovcnFNOGwrMk1NTWEyMHVP
aGZQRURIbDY3TVFFR1ZiaUloNlIwYjN3U0FhTWlwaklaUkJackpEOEtKRXFQeHZSMUhiTDAx
ZXRXdFhkM2UzMWV2ZnYzejltekJnYVRsMUdyS2ViU0pYNGFSS09BNFpmVHhmYWlDeTR4SG85
WFQ0cHo3STd6d2V1K1ZXSnI1Y28vVlpqejJBUTVVS2o0SzZBK3E5MjRXYVFkeE1QSlg1MlF2
YVJkSkRNcUxpZUx1bU05ZlR3MkxWclYwNU9Ua3BLeWozMzNQUEpKNS9RY09veVNyekg0M2VZ
WHNiMmttUGhQQWthMDNXWExWY2JveWtVMjBPNklrYnVrZzhvSDErdFJjMUNkcEJmU0ZTZHJh
QkJtRVh4RXFMZ1JydkZkQTBvNXVsQnZHK2ZqRGo0TFlnOFhkSkhhRmJzRmxEL3JST3VyeFNu
RUh0RDRnU0pQTUhVOG5UeFQyeVpXTzI2Skg0SXlNS3grRmd0VDVlSVpLcUN5SllMVXpQSkt6
cVNia0g2aUVVaVR6Y0V5TlBWek1oT1lIdkpNZWVqWTZkSFBFWGcxcWdhVXBKY0lYK2Y0Qk54
ZWthaW1jZDdJYWNJTWxySUMrUlhycThSbGVkRjdxVkFOTzQ5eFBUUUlFOVg2eFA4RmpSeW5o
N2NvcTRxNUdBOHFuZ1NUODZob3BpZkdsTVZwekRrNmZ4WUpLYkw2ektpZXArazhwenVHb0pY
eFpNY0I5UnJNY2IwbWVXY0YxdExib2xTWFVhaFhmRXM2akxHRnVUcGFuMkNPRUZIVllLMkFQ
TDBDUHFZV2hXbk1OM3o5SURTeWd6eTlKaUQ5WFExTTdJVDJGNXl6UG5vR0ltQjJkT0krbnE2
MnRsSURERTlOTWpUMWZvRXZ3V1JweFBrNlRxcDRoU0dQSjBmNDhiMHlzckt3c0xDeU9zeUJn
eWNva3FmNDVoSk5iSVQyRjV5elBub0dJbUIyZE5JMER4ZDNqbENzMTFNZi9UUlI1dWJtMzAr
MzQ0ZE8xZ2xBTTY2akFIWnIySTFueG90VDJkU2thY1Q1T25oOURHMUtrNWhSc2pUNVoyUnAy
dWt0YlhWNlhSUzdycU1pdDQzaGNWT3FwR2R3UGFTWTg1SHgwZ01EQlpBbmg0ak9qbzZaczJh
ZGZEZ1FjcGRsekZBYnFuTEdLUTZvOUVxSUFhaVhUK1A5UWxabjlMSWRSa0RzbHFNNG0yTWZC
Vmt5Nk9LV2ZBK2luZXB0ajZtVmhVZ3hEZHpaanhuNUZjbGZsWEsrMFQrcXJkalhjYkd4a2Fu
MDdsbnp4NzJJMmRkUnNWZmlwSC9VbzJEeFVpbndUMGdsaWNjY3o0NlJtSmdzQUR5OUtpemZm
djI3T3pzdXJvNm9ZV3pMbU5BYWNsTTBhYzJXVThQZVF0aVBaMWdQVjBuVlp6QzRyT2VMbEhG
amdKWVQ0OFc1Rlo2ZW5vNDZ6SXFPcGJIOVhwWmdFZ1BvajYra1QwZ2xpY2NjejQ2Um1KZ3NB
RHlkQ05nMGp4ZGZOUEVRbFhJV3hCNU92bGJDZktRZzVrM0l6YW1LazVoeU5QNXNXWk1WM3dD
REd1QlcyTjZMTVkzc2hQRTJvUmp6a2RIVndiL3ZEQTdHTnNGa0tmckNQSjB4VDRoNzBKNzV1
bVNTUzJmRVJ0VEZhY3c1T244V0NTbWkrc3lxbFZjTTBJTlFyVmFnRUpGd0JpTmIrVDZsTHJV
WmVRY0gxczdiOFd2eWlqZWU4SVdkUmxEZ3p4ZHNVOXdKM0FPWmJFOFhkN0w4aG14TVZWeEN0
TXJUdy9TZ1NCUGp5cTRXS2dBQUJWRVNVUkJWQVBCMTlQRng0YXlBTmJUNDc2ZXJ2ZEZ3MHhn
SkZSTWo5QVEwME1UUEUrWFBCa0JYYjkxL3BhbkZuazY4dlFJK3BoYUZhY3c1T244R0RlbUM1
OU1GMW80NnpMeVBHSEVTQ1ZRQXNqVHRlYnBtaTlLNzR1R21jQ0lwanc5eUNscFQ3dkZkSVk0
cG11dXk2aG15TlA1aDRwZHRVaXhObkZIenR4VG15cDVMOHRueE1aVXhTbk1SSGw2UVBaQ1E1
NStDK0tZcnJrdVk1Qm54UWdXaUZlZWJxaXJWcnh3RGNORXhTY3dtQVpUYkZWclYraUptQjVK
WFVhMVNuVkdxTXNvVkNJTXhMSXVvM2hya0xxTUFWSEZPNkVsM0ZxRDJsVFpzQUtpTVZVRkRG
eVhNV1FmeGJ0ZC92cnFLRUpkUmhIaW1CNUpYVVkxQzZzM1ovK0FiSFU0K0RpQitPYnBNWm9s
UW1GcVVrTmFFTWZ5T3dRRzAyRHlKbmw3a1A3STA3bnFNakozaGJ1UXAvamNDTnVpRHRWdlRS
SU8rYXY2aWJzcFBrUll1UlpyRUxld0E1NjF2T0JmNlNMcHB1WUJ3VmRxZDYyNG5mbEswazE4
SVlJVFNLaVl6cjlHTEg4NkpLNFRxMUo3bWl5L2NtMU1WWnpDZEZsUEQ5bEhIQm5ZTHVTTTRo
TzJpK25rVmlpbFBIVVplWjZ0V0pqYTB4bTcwWWdzVnZMY1hzYThYa2lGMmRIc0Z0TTFvRGxQ
RDI3SXA2QUtxbUtraWxPWU1mUDBTRlVocG9kRXh6d2RCb1BCd2pQRTlKQWdUNGNxcURLWEtr
NWh5TlA1c1VoTUYrb3lCdlN1NVlZdHR0aGl5N05GWGNiUUlFK0hLcWd5bHlwT1ljalQrYkZt
VElmQllEQ2pHMko2U0pDblF4VlVtVXNWcHpEazZmeVlLYWJ6MUdYa2NURU1Cb1BwYjMrTDZa
VlBQbm50NHNWb3hVa3p4WFNldW96TVdjalRvUXFxVEtHS1U1aTE4L1FOVHVmbUtWTStlLzMx
ZnA4djhqaHBwcGpPVTVlUng4VXdHQXltdjRsaU9yTnRQLzd4dDRjUFJ4Z256UlRURmVzeW5q
MTdkdTNhdGVWcjFqeXpjT0ZQNTg5L2R0bXl0V3ZYL3ZiaGg5ZXVYY3VPZzJ6TEhuc3NaQi9P
MFRobi9QV3ZmdzFWVUFWVjR1M1RQL3RaUEdjMGppb1d0Wjc3elcvK0h0UG56Ly8yNDQ4ampK
Tm1pdWs4ZFJuWndZVUxGM2dHOUgzNktVODNudEU0WitUcEJsWDgzYUNLdjVzeFZWRStZVkdj
MFlDcTJOckxwMy80ZyszV1huanFNcktEM3Q1ZW5nRnY3TmpCMDQxbk5NNFplYnBCRlg4M3FP
THZaa3hWbEU5WUZHYzBvS3JLRlN1dXRiWHhETVdEbVdJNlQxM0dzQVljNk82T2tyUm9BbFg4
UUJVL3hsUkZqU3JNbUtwNE1GTk1EMGx6dEw4eEJBQUF6SVdsWWpvQUFOZ2N4SFR0VkZaV0Zo
WVdKaWNuejVneDQ5Q2hRMVQwUFI2R1VpVnZNWUtxaW9xSy9QeDhvNmxpdlBqaWl6bytpVUh1
SzBPcEdod2NmUEhGRjNOeWNvWU5HMllvWVdKM1pXVmxHVVJWVlZWVlhsNWVZbUxpeElrVHE2
cXFZamMxWXJwMkhuMzAwZWJtWnAvUHQyUEhEdkhuY1BTTjZYSlZhanIxVmJWMDZkTFcxbGF2
MTd0djN6NjlYbmlLbm1scWFobzdkcXlPVDZKY2xiNTNGRU91YXYzNjlWT21UR2x1Ymg0YUdq
S1VNSUhqeDQ4Ly8venpCbEdWbnA3dWRydjlmci9MNVhJNEhMR2JHakU5Q3JTMnRqcWRUdUZI
STd3Q3FVeVZZa3Y4a1dqdysvM3Z2LzkrVVZHUmpwS29TSlhQNTVzK2ZmcVJJMGVNOENRS3Fn
Z2h0OTkrZTFwYVdrbEpTV3RycTBGVU9aMU9sOHVscnhneDh0dTdwS1RrOHVYTGV1bGhDS3FL
aW9yY2JuZHZiNi9MNVpvNWMyYnNaa1JNajVTT2pvNVpzMllkUEhoUWFERkNPSkNya3Jmb3Jv
cjlkWnlSa2ZIRkYxOFlSTldxVmF0ZWUrMDFhb0FuVWY1OGRYVjFsWldWelprenh5Q3FFaE1U
VjY5ZVBYejRjS2ZUZWVEQUFSMVZVU1YzTlRRMExGMjZWRWRKOUZaVkowNmNTRTlQSjRTa3A2
ZWZPSEVpZHBNaXBrZEVZMk9qMCtuY3MyZVB1RkgzY0NCWHBhaFRkMVdVVXJiMk1tblNKSU9v
WWt2RHVpOWVxejFmWHE4M09UbFpGMGxVcG1yVXFGRXVsNHN0Sm93ZVBWb3ZWWEpoakFVTEZu
ejExVmQ2U2FJeVZaTW5UeGJXWHU2ODg4N1l6WXVZcnAzdDI3ZG5aMmZYMWRWSjJ2V042WEpW
YWpyMVZiVnExYXJ1N202djE3dC8vLzR4WThZWVJKV0FqaytpbXFwcjE2Njk4TUlMeGNYRmVv
aFNVTFZreVJLWHk4VVdFN0t6czNWUnBTaU1VbnJzMkxINzdydFBMMGxVU1ZWR1JvYXc5cEta
bVJtN3FSSFR0VU51cGFlblI5SmlURlU5UFQxR1VMVnIxNjZjbkp5VWxKUjc3cm5uazA4K2li
OGtSVlhpVTdwSVVsVEZEbEpUVXhjc1dIRCsvSG1EcUdwdmI3L3Z2dnVTazVQejh2SjBYRmhY
ZkJMdnYvLytEei84VUM5Smlxb3FLeXVkVG1kaVltSnVidTc3Nzc4ZnU2a1Iwd0VBd0RvZ3Bn
TUFnSFZBVEFjQUFPdUFtQTRBQU5ZQk1SMEFBS3dEWWpvQUFGZ0h4SFFBQUxBT2lPbkFPdWo0
b1hJQURBSmlldnpvN2UxZHMyYk42TkdqUjQ0Y3VYSGpScjNsbUJoQ3lLdXZ2a29wZmVXVlZ4
REhJNkc1dVprUWdpK1RpUkJEM1pDSTZmSGp1ZWVlVzdodzRlWExsNjlkdS9iMDAwL3JMY2ZF
RUVJS0NncUdob2FtVEptaSswdkkxR3pldkRraElXSHo1czE2Q3pFM2hyb2hFZFBqeDdoeDR5
VGZJQzUrK29WalFzaHp6ejJYbHBZbUZPVFUvUzR4R29TUWVmUG1yVisvZnY3OCtXSy9TZnk1
WmN1V3pNek1qSXlNSFgvN3ZtQjRVc0tDQlF1ZWZQTEpCUXNXc0I5bnpwekp2c0NodnI3K3Jy
dnVvcFEyTlRVVkZCU2twcWFXbDVlTFhhMlhZR01pdnlIWjNaaVVsQ1I4SjhiS2xTdC85YXRm
VVVxWExsMzYxRk5QQ1ErTXVoakU5UGlSbUpnNE1EQWdibEdMNmErKytxckg0L20zZi91M3VP
b3pENFNRdlh2M0ppUWt2UGZlZTRvK1pNZGJ0MjcxZXIwMU5UVjZmUk9Jd2ZGNFBDTkdqTGg4
K2ZLSUVTTThIZytsOUkwMzNsaXlaQW1sZFBIaXhXKysrU2FsdEtpbzZJOS8vS1BINDlteFl3
ZEN1UnBxTitUQXdFQkRROFBZc1dNcHBmMzkvUTgrK09DLy8vdS9QL2pnZy8zOS9iRVRnNWdl
UDRMazZmMzkvZUtZM3RmWEYyOXhwaUpJSEJjZkM2OGNCQ05GcXF1cmhTSlQxZFhWbE5LclY2
ODZISTRMRnk0NEhJNGZmdmlCVXBxVWxPVDFlaW1sWHE4WGJsUkRmaE51M2JyVjZYUW1KQ1FR
UW9ZTkc4Wk9OVFUxRVVLYW1wcGlLZ1l4UFg2VWxaVXRYTGl3bzZQait2WHJaV1ZsbE5KUm8w
YlYxZFg1Zkw1dDI3YmhEMXQrT0dPNjRqRVFlT3FwcDloNzlSczNiaFJXQTBwTFMrKysrKzdG
aXhlekg2ZFBuLzZuUC8zSjYvVysvZmJiY0tNYThwc3ROVFcxcHFiRzYvVzZYQzdXNHZWNlo4
eVlVVkpTTW1QR0RKL1BGenN4aU9ueHcrLzMvOGQvL01lb1VhT0V6NzFzMzc3ZDRYQmtabWEr
K2VhYlFXSTZYa3NTNUM4aFNXbFR4VDRVbnJ5VnZMeThreWRQVWtwUG5qeVpsNWZIR3V2cjZ3
a2g5ZlgxN01mR3hzYjgvUHpVMU5Sbm4zMDJJU0dCTmNLTkV1UTMyMHN2dmVSd09Cd094NlpO
bTFqTDh1WExuM2ppQ1VycDQ0OC92bUxGQ3ZrRG93VmlPZ0FnQklPRGd4OSsrT0dVS1ZQMEZn
SkNnNWdPQUFnR1d4SE95OHZUNjZ0TFFGZ2dwZ01BZ0hWQVRBY0FBT3VBbUE0QUFOWWh2SmhP
VkpEM2xOYzJhV3RybXpOblRrcEt5cHc1Y3k1ZXZCajlTekVoVlZWVmVYbDVpWW1KZVhsNUgz
endnV0lmdjkrL2V2WHE3T3hzd2RYeUZzRGpFL0VkbTVXVkpXNkpyMWlqc0dmUG5rbVRKaVVu
Sjk5MTExMUhqaHloZkM5U3VhdXJxcXFjVG1keWN2S1BmdlNqbHBhV3VGNkRNWkI3Z01jbk1Y
cHBoeDNUQXpKVG5GdGUyK1NSUng0cEx5LzMrWHpsNWVXbHBhWGE1Rm9NaDhOUlcxdnI5L3Zk
YnJmRDRWRHNVMVpXTm5QbXpETm56Z3dORGFtMWdMQjg4dFJUVDYxYnQwNzQwYll4L1pGSEhq
bDU4cVRQNTl1elp3LzdWMXVlRjZuYzFWbFpXWWNPSGVydDdYVzVYUC95TC84U0wva0dRdTRC
SHAvRTZLVWRxNWd1LzUvSnJLeXN6czVPU21sblp5ZitWNXN4WThhTSt2cjYzdDdldXJvNlZs
NURUazVPenRHalI0TzNBSDZmWEx0MkxTTWpvNzI5WFdpeGJVd1h1SFRwVW5KeWNsOWZIOCtM
Vk83cXJLeXNqei8rbU1XdnpNek1PQWcyR25JUDhQZ2tSaS90V01WMGVXMlRoSVNFd2NIQmVm
UG1EUXdNSkNZbVJxamJHalEyTm1aa1pCQkNNakl5MVA1ak9ERXhzYnk4UEMwdGJmejQ4ZnYz
NzFkc0FmdysyYlJwRS92WER3R2J4L1R2di8rK3VMaVkvVEhOOHlLVnU3cWlvdUtPTys0WVBu
ejRzODgrYTgrWHR0d0RQRDZKMFVzN3JubDZWMWNYUlo0dUlqOC8zKzEyKy8xK2w4dFZVRkNn
MkNjakk4UGxjdlgyOWg0NmRJaXRBc3RiQUtkUCt2djd4NDhmTC9uMWFlZVkvdVdYWDA2Y09M
Rzh2SHh3Y0pEeXZVaUR1UHJJa1NQanhvMkx2V3JqSXZkQUVKL0U2S1VkcTVndXIyM3k4TU1Q
cjF1M3p1LzNyMXUzN3JISEh0TW0xMktrcDZlNzNlN2UzdDdhMmxxMTlmUmYvT0lYd3RQTVht
YnlGc0RwazRxS2lybHo1MG9hYlJ2VGQrM2FWVnhjL1Bubm53c3RQQzlTUlZjUERRMmRQWHUy
cUtpSXZkaHRpTndESVgwU281ZDJyR0s2dkxaSmEydnI3Tm16MlJ2QmJXMXQydVJhaklxS0Ns
YThMVGMzdDdLeWtqVksvTm5TMGpKNzl1eWtwQ1NuMDFsVlZhWFlBaFI5SXI4elo4K2VMZjZU
TnVUSHQ2eU41UEo3ZW5vVVg2UWhiMGoyOE96czdGV3JWdm45ZmgydVJHL2tIbEQwU1h4ZTJy
SDZMQ01BQUlENGcvODVBZ0FBNjRDWURnQUExZ0V4SFFBQXJBTmlPZ0FBV0lmNDFYdkJHNnJ5
RWhBOFBxbXFxcG82ZFdwS1NzcXNXYk9PSFRzbXRHL1lzTUVtenVUeGdGb2ZNZkppR3VKNzJJ
YWY5SmRmUGsrVkVybXI4ZEpXclBjUzhvYVUxOXVKU3VXYzhHTzYwb2NaNVQzbDlWNkVFYlFK
dFFCcUpTQ0MrNlMwdFBUTW1UTit2LytERHo0WU0yWU1hL3o2NjY5WmJJcXRZbVBBNHdIRlBo
S0NGTk9RVklDeEc4TGw4MVFwVVhPMVRlNUdSZVIrNDdraDVmVjJvbEk1SjFZeFhmNS9wTUlJ
Mm9SYUFMVVNFRHcrOFhxOWxaV1Y3TXZEL0g3L3RHblQvdWQvL3NkV3p1VHhnTGlQSExWaUd1
SUtNSVNRZSs2NVovSGl4Uk1uVGhTK1o5bmFpQytmdjNLTDNOVzJ1aHNscVBrdCtBMHBJSzYz
RTNubG5GakZkSG05RjJFRWJVSXRnRm9KaUpBK0VmNDYvdkxMTHltbHp6enpEUHNmUC9zNGs4
Y0RrajV5MUlwcGlDdkFFRUthbTV2WmRzU0lFVEc4Sk1NZ3Zuek95aTJLcnJiUDNTaEgwVzho
YjBpR3VONU9WQ3JuSUUvWEFVa0pDQjZmZUR5ZTk5NTdiOXEwYVpUU2hJU0U0RzltV0JJZUQ0
ajd5RkVzcGlHcEFDT3NzMU43M0t1S0JYQW9SK1VXdWF2dDRLNlFTUHdXL0lha3NubzdhdU9F
UmF4aXVyemVpekNDTnFIV1FMRUVSSENmTEYrK3ZLMnR6ZS8zVjFaV1N2NGNzNGt6ZVR3UXBJ
K0FZakVOU1FVWXU4VjBlUUdja0ZWSzFGeHRCM2NGUWVJM25odFNYbTlIUG80R1loWFQ1ZlZl
eUsxb2sydHEySVhMaTBKSWZDSnh6cC8vL09lSkV5Y21KU1ZObXpiTjdYWkxCb3liZUIzaDhZ
QmlINGwvRkl0cHlDdkFVRHZGZE1VQ09NR3JsTWhkalplMjNHODhONlRFYnowOVBZcitEeGZV
ZXdFQUFPdUEvemtDQUFEcmdKZ09BQURXQVRFZEFBQ3NBMkk2QUlZRzcxZUJzRUJNQjBBQnpa
RTA2aUU0eUlCUm1Zc1E4dXFycjFKS1gzbmxsVWdHSklSczNydzVjbUdLVlZEeTh2SVNFeFB6
OHZJKytPQUR0ZGtsbjllUWwvZVIwOWJXTm1mT25KU1VsRGx6NWx5OGVKSGUrakVRZm9YeUZw
NUhCWms5eUhXRkJERWRBQVZzRmRNTENncUdob2FtVEprU1lVelB6OCsvZWZObWhNTGtWVkFj
RGtkdGJhM2Y3M2U3M1dwZjJ5dG9FSTZEbFBjUnoxVmVYdTd6K2NyTHkwdExTem1WeXhYS1d6
Z2ZKWmxkZmhWcUxVRkFUQWRBQWNYWEZTRWtLU2xweG93Wmh3NGRvcFMrOGNZYlRxY3pNVEZS
eUtSNHNqeEpGc2EyWldWbHFhbXBVNlpNYVd4c3BKUTJOallXRkJTa3BxYVdsWldKUnhiUExw
L3I3Tm16OTk1N2IzSnk4dVRKazRWYWdDSERBU0ZrM3J4NTY5ZXZuejkvUHV2OCtlZWZGeFlX
SmlVbEZSWVdzditJSVlSczJiSWxNek16SXlOang0NGRhdU5zMkxEaDVaZGZGaWFWanpOejVr
d212cjYrL3E2Nzdnb3VUS2lDTW1QR2pQcjYrdDdlM3JxNnV1Q1BFbCtzWW5rZmlUZXlzckk2
T3pzcHBaMmRuU3pPRWtJY0RrZGFXdHJQZnZhejF0Wld4VWZKRlFacENmSW8rZXhxMHlHbUF4
QXBhcStpZ1lHQmhvYUdzV1BIVWtwSGpCaXhZY09HTTJmTzlQYjJobnlnWWdjaFhtL2Z2dDNy
OWU3YXRXdjY5T21VMHFsVHArN2F0Y3ZyOWI3MTFsdmkvdUxaNVhQTm1qWHIzWGZmOWZ2OXRi
VzFreWRQNXIvU3ZYdjNKaVFrdlBmZWUyekFnb0tDblR0M2VyM2U3ZHUzRnhZV3NqNWJ0Mjcx
ZXIwMU5UVnFlU2docEtlblo5S2tTZGV1WFZNYjU0MDMzbGl5WkFtbGRQSGl4VysrK1dZUVZl
SXFLSTJOalJrWkdZU1FqSXdNZVJrRGlRYmhXSzI4ajVpRWhJVEJ3Y0Y1OCtZTkRBeUk2NnQw
ZDNlWGxaWE5tVE9IVTZGYVMvQkhxYzJPbUE1QTlKRy9pclp1M2VwME9sbXBtV0hEaGxGS1Av
cm9vNS8vL09lVEowOGVPWExrZi83bmY2bzlVRzNrL3Y1K0lhWjd2VjVLcWRmclRVNU9wcFFt
SlNXeEZvL0h3L3JJWjVmUGxaU1VKR1R1UXArd3JwUWRKeVltQ3JNbkpTV3g5djcrL3VBWHlO
bzNidHo0L1BQUHE0MXo5ZXBWaDhOeDRjSUZoOFB4d3c4L3FFbVNWRUhKejg5M3U5MSt2OS9s
Y2hVVUZIQmVpMko1SHdsWldWbGRYVjFVbGlsVFNuMCtIM3N1ZUJRcXRvUjhsTnJzaU9rQVJC
LzVxeWcxTmJXbXBzYnI5YnBjTHZIWndjSEJJMGVPcEtXbHNSOVRVbEtFdjlrVkdUVnFWRjFk
bmMvbjI3WnRteERUV1Q2N2E5ZXVxVk9uVWtxblRadkc4dlR0MjdlelBvcXpTK1lxTGk2dXJx
NzIrWHlhcnpSSW5oN0VNK0oyajhlVG01dXJOZzZsdExTMDlPNjc3dzVTeDFoZUJTVTlQZDN0
ZHZmMjl0Ylcxdkt2cHl1Vzk1SHc4TU1QcjF1M3p1LzNyMXUzamxYNlpOeThlWFA5K3ZYRnhj
V2NDaFVydDRSOGxOcnNpT2tBUkI5eUs1VFNsMTU2eWVGd09CeU9UWnMyaWRlNEV4SVNjbk56
Ly9qSFA3SUhybG16SmpVMU5jaUxjUHYyN1E2SEl6TXo4ODAzMzVTc3ArZm41eDgvZnB4U2V2
ejQ4Zno4L05UVTFPZWVlMDV0ZHZsYzU4NmRlK0NCQjFpTDBLaGhMYWlob2FHZ29DQXhNYkdn
b0VCWVQxZnNyempPNXMyYjFjYWhsTmJYMXhOQzZ1dnJnK2dSMDlQVFUxRlJ3ZjVHeWMzTnJh
eXM1SGtVVlNudkl4SGYydG82ZS9aczlyMUNiVzF0d2ppMzNYYmJBdzg4Y1A3OGVjVkh5UlhL
VzNpdVMyMTI4VlhJVzBLQ21BNkF6bkMrVmdIZ0FURWRBSjFCVEFkUkJERWRBQUNzQTJJNkFB
QllCOFIwQUFDd0RvanBBQUJnSFJEVGdUbW9ycTZ1cWFrWkdCaW9xYW1wcnE3bWZFandzMm9k
UEI2UHkrVlM3Qi9rVVFBWUFjUjBZQTZxcTZzLy9mVFRiNzc1NXJQUFBvdFdWRlViNTZ1dnZw
S2ZRaWdIcGdBeEhaaUQ2dXJxYytmT3VkM3VjK2ZPQ2VGVmNsQmRYZDNjM094MnU4K2VQYXZX
S0JsVFB0SE5temZyNitzVlk3cmI3Zjc0NDQ4N09qcWllbVVBUkJQRWRHQU9xcXVycjE2OUtt
eUZSdkZCZFhYMUR6Lzg0UEY0MkRlMUt6Wkt4cFJQOUplLy9LV2xwVVh4MU5EUVVFZEhSMTFk
WGZRdUM0QW9nNWdPekVGMWRmWFEwTkRodzRlSGhvYUVnT3QydXowZWp4RGw1U0ZlM2lnWlUz
RWl0WFh6b2FHaHJxNHV4SFJnWkJEVGdUa1FSMWpoK096WnMyNjN1N201V1VOTWx3UnUrVm41
UVhWMTljY2ZmM3o1OHVWb1hoZ0FVUVV4SFFBQXJBTmlPZ0FBV0FmRWRBQUFzQTZJNlFBQVlC
MFEwd0VBd0RvZ3BnTUFnSFg0ZTB4dmJHemNDd0FBd1B3UUJIUUFBTEFNL3c4ekFuMmUwNzdS
bGdBQUFBQkpSVTVFcmtKZ2dnPT0iIC8+PC9wPjxwPiZuYnNwOzwvcD48cD5JbiBDUFUgdXNh
Z2Ugb2YgdGhlIERvbTAsIHRoZXJlIGlzIG5vdGhpbmcgdG8gc2VlOjwvcD48cD4mbmJzcDs8
L3A+PHA+PGltZyBhbHQ9IiIgc3JjPSJkYXRhOmltYWdlL3BuZztiYXNlNjQsaVZCT1J3MEtH
Z29BQUFBTlNVaEVVZ0FBQWZFQUFBRnNDQUlBQUFCVHFCZTNBQUFnQUVsRVFWUjRuTzJkZjNR
VGRici94eWFwSlNocEc4b0Mxa0JoUzB0cGk3WGNVcmk3WHI2ZTd4VkZkLzJSVnRjVlBmZXND
L2RjUUN1UjVld2VQVzR2b0xzS2dxWFFxeGVGV2l5aVRkcFNZTld0YUZHNWgyckx4VXAvUVZO
RWZqWEpoS2I5L1BNOVovL2crOGVzczhQOHlxZHAwc3hNM3Evem5EbnBKNStaZWMrVHlidFBK
NU9uelA4Q0FBQXdCRzF0YlV5OE5RQUFBSWdDYlcxdGUvZnUvYnVuRXdBQUFIcG03OTY5OEhR
QUFEQUk4SFFBQURBTzhIUUFBREFPOEhRQUFOQVREUktFejhMVEFZZ0pETVBFVzRJbU5JQVlN
VG82eXJrNVBCMkFpVUFMZnFvRkRTQVdoRUtoYjc3NXh1MTJYNzU4dWJHeFVmZ1VQQjNFbk03
T3psLys4cGRwYVduSnljbDMzbm5uL3YzN3VYSG1SNlpNbWZMd3d3K2ZQMytlSDVkdVJIZjJw
QVhCV3RBQW9rNVBUMDlMUzh2eDQ4ZlBuajNiMk5qNHpUZmZDSitGcDRQWWN2cjA2Wi84NUNj
N2R1eTRjT0VDeTdLZmYvNzVndzgreUQzRk84N2c0T0N2ZnZXclgvemlGNkp4SWJxekp5MEkx
b0lHRUhVKysreXp5NWN2S3owTFR3ZXg1ZEZISC8zem4vOHMrNVRRY1g3NDRRZXIxU29kbDUy
c05Nai82UEY0NXMrZmI3RllIQTdIcmwyN3VNSHZ2dnZ1dnZ2dW16eDU4czAzMy95di8vcXZn
NE9EM0xqZjcvLzFyMzl0dFZxblRadTJlZk5tZmlPaFVNamxjazJkT25YU3BFbE9wL1BxMWF2
MFI4MkoyYng1YzBaR2h0VnFYYmx5SmN1eWhKQ2xTNWZ1MjdlUG45UFQwek45K25UaCt6TXJL
K3ZycjcvbUhyLzU1cHZjZzYrLy9qb3JLMHRGa3RJNGZ5eGZmUEhGekprelgzMzExVEVkQXRB
ajhIUVFXNlpObTNidTNEblpwNFNPZlBIaXhTaDZ1dDF1ZisrOTkxaVc3ZW5wZWVxcHA3akIz
TnpjSTBlTytQMyt5NWN2cjFtejVySEhIdVBHbjMzMjJmdnZ2Ly84K2ZQbno1Ky83Nzc3K0ky
OCtPS0xkOTk5ZDE5ZjM5V3JWNTk0NG9uZi92YTM5RWZOaVZtK2ZQbmc0T0RnNE9EeTVjdWZl
KzQ1UWtoVFUxTk9UczdJeUFnMzU2bW5udHEwYVpOd3JWV3JWdTNZc1lNUTB0ZlhkOHN0dDNE
dXZIMzc5dFdyVjZ0SVVocm5qcVdob1dIcTFLa0hEeDRjazM2Z1dYRGZDNGduWnJONWVIaFk5
aW5lUGMrZlAvL0VFMC9jZi8vOW9uSFp5U3FEL0krWm1abmJ0bTNyNit0VFV1WHorYVpPbmNv
OW5qbHo1bmZmZmNjOS92YmJiL21OT0J5T1U2ZE9jWSs5WHUrMGFkT1V0aVlMd3pEZmZ2c3Q5
L2owNmRPMzNYWWI5N2k0dVBpZGQ5N2hCMzArbjNDdER6NzR3T2wwRWtJMmJkbzBkZXBVN28r
TVJ4NTU1TU1QUDFTUnBEVE9NTXpycjc4K1k4YU10cmEyTVlrSDJnZjN2WUQ0b0Y2bmM5eDY2
NjBQUHZpZzErdmx4cE9Ta2tLaGtIQm1LQlJLU2txUzNZTHNqMjF0YmZmZGQxOTZldnJzMmJN
NU55U0VmUHJwcDB1V0xMRmFyZHhPYjdycEptN2NaREx4dXhzZUh1WTNZamFiR1FIOGZObERr
SDFLdUZtejJjdzlQbmp3WUhaMmRpZ1VLaTh2MzdwMXEyaXRvYUdoMjIrL25SQ3lZTUVDdDl1
OWVQRmlRc2p0dDkvT1diK1NKS1Z4aG1GbXo1NzkvUFBQUytVQlhZUDdYa0RjZVBUUlIxOTc3
VFhacDVRK3dYTTRIUC96UC84akhQbnFxNjhjRG9kMHB0bHM1dXZjQ3hjdWlEWTRPanJxZHJ0
LzhwT2ZjRC9PbkRtenRyYjI4dVhMbzZPalY2NWM0U2ZQbURGRHRrN1B6TXpzNysrbk9FUjVo
SFg2dDk5K08zUG1URjdWZ2dVTEtpb3FIQTVITUJpVXJ2anpuLy84M1hmZkxTNHVKb1FVRnhj
ZlBIandycnZ1VXBla05NNHdURjlmMzV3NWM3WnMyUkx4Z1FDdGdmdGVRRHc1ZmZyMDlPblRk
KzdjK2NNUFA3QXMyOWJXSnIzdlJjUi8vdWQvRmhVVmZmYlpaeXpMc2l4NzdOaXhoUXNYeXJw
U1VWSFJDeSs4NFBQNSt2djdIM3JvSVg2RFpXVmwzM3p6VFRBWWRMdmRkcnVkRzB4TFN6dDQ4
Q0RMc3Q5OTk1M1Q2ZVFuUC9QTU13ODg4TUQzMzMvLy9mZmZDNituLy9HUGYxeStmSGxYVjlm
dzhQREpreWU1U3lMME1BeHozMzMzY1pmcDc3MzMzb3FLQ3Y2cDJ0cGFobUYyNzk0dHUrS21U
WnRtenB6SmxmQ3Z2ZmJhYmJmZHRubnpablZKU3VQY3Nadzllelk3Tzd1eXNuSk0rb0Ztd1gw
dklNNTBkSFQ4NGhlL3NObHN5Y25KeGNYRnd2dlRaZWVQam81dTNicDF3WUlGTjk5ODg4MDMz
N3hnd1lMWFgzOWRkdVpYWDMyMWNPRkNzOW5zY0RoMjdOakJiM0Rmdm4zWjJkbG1zM24rL1Bs
TlRVM2M0UHZ2dno5NzlteVR5WFQ3N2JkdjNicVZuK3p6K1g3MXExOU5talFwSXlQamozLzhv
OFZpNGNaSFJrWXFLeXNkRG9mRllzbkx5NnV0clIzVFVRdnZlM25paVNjQ2dRRC8xUDc5Kytm
T25hdjBNY09KRXlmTVpqTjN0LzdnNEtEWmJPYi9hbEdTcERUT0grUEF3RUJPVHM2TEw3NDRw
a01BZWdTZURzQS82T3pzbkRWclZxejNzbUxGaXIxNzk4WjZMOENvNEw0WEFNS3dkdTNhaXhj
dkRnd01MRisrZk4yNmRiSGIwY2pJU0hWMWRXNXVMbjg3SXdCalJXVGk4SFFBeEx6NjZxdDJ1
MzN5NU1tUFB2cm8wTkJRN0hiRU1JekQ0Y0NkaFdBOE5EWTJYcnQyalh0ODdkbzEzUGNDQUFB
NnBxMnQ3ZXV2dng0ZUhoNGVIdjc2NjYrUEh6OHVmQmFlRGdBQWVpSVFDSHorK2VjZWo4Zmo4
YlMxdFFrL2ZpZndkQUFBMERXNG5nNEFBTVlCbmc0QUFEb21nZTVsN0RwNnRPdm8wWGlyQUFD
QWljT3duajdNc3R1WExObStaTWt3eThaYkN3QUFUQkNHOWZTL3Z2cHFwY05SNlhEOEZZMy9B
UUNKaWtFOC9YSmYzNWJzYk03VHQyUm5YMVp1bkEwQUFMckc3L2UzdGJYeDl6TDYvWDdoczFy
eDlOcmEydXpzYkl2RlVsQlEwTkxTUWdqcDcrOHZMUzFOVGs0dUxTM2wrb2hLUjNqcW5ueVNN
M1F1NnA1OE1qNkhBUUFBTWFhMXRmWFVxVlBYcmwyN2R1MWFaMmRuYTJ1cjhGbXRlUHJqanov
ZTNkM3Q5L3ZmZmZmZDlQUjBRa2haV1puTDVRb0VBaTZYcTd5OFhIWkV4TWFORzdrSFo4K2Vw
ZG5wdFk0T21tazBXNlBjSTgwMHFLS2ZCbFgwMDdTcGl0QUppK0lldGFscVRMamRicjVmME1q
SWlOdnRGajZyRlUvbllGbjJ2ZmZleTgvUEo0VFk3WGJ1SDk5NHZWNnVCYlowUk1UR2pSdXZk
ekRYTzVqMnh2L0xQVkNQd0paQ21tazBXNlBjSTgwMHFJS3F4RkZGS1N5S2U5U09xb2g5VWg5
MU92bngzNENscHFaKzl0bG5oSkNrcENUdWQxRW9GREtaVExJalBLRUxGNjVVVlcxWXRZcnN6
Ynpld1F5L1BlZDZCOE05VmxuKzdkaWtzSE1vdDBhNXgvOTNNdndlb1FxcUVrZlY5UTRtdEh0
Qzk2Z2RWWDlqMlN0VlZjSDI5ckZhcGMvbjA4SDFkQTd1MnN1Y09YTUlJZW5wNmFLcVhEb2ln
cS9UQno3SnYwN3grNVBVWnRKTW85a2E1UjVwcGtFVlZDV09La3BoVWR5amhsUmR2eDRMRjlX
S3A2OVpzK2I4K2ZOK3YzLy8vdjNjZnoxM09wMzgxWFB1ZjNGSlIwVHdubzVBSUJCYWowZzlY
Ui8zdmRUVTFNeVlNU001T2ZuT08rLzh5MS8rUWdqcDdlMHRLU214V0N5TEZ5L3U2K3VUSFJH
Qk9oMnFvRXBmcWlpRm9VNFhvcHZyNmVNSGRUb0NnZEJOUk9ycGVycnZaWnlnVG9jcXFOS1hL
a3BocU5PRkpFU2RmdTNhdGU3dTd0Lzg1amZYT3hqdkp3dXd4QkpMTERXKzdPL3Y3Kzd1anVE
dWRUM2Q5ekpPVUtkREZWVHBTeFdsTU5UcDlCalQweEVJQkVMckVhbW5KMUQvZE5UcFVBVlYr
bEpGS1F4MXVoQ1JpWXN3cHFjakVBaUUxZ09lSGhiVTZWQUZWZnBTUlNrTWRicVFoUEIwM1Bl
Q0paWlk2bXNaOFgwdjZoakUwemxRcDBNVlZPbExGYVV3MU9uMEdOUFRFUWdFUXVzUmthY2ZP
WEtrdmIzZDYvV0dRaUhaQ2NiMGROVHBVQVZWdWxCRktReDFPcytWSzFlNnVycU9IVHZXMk5o
NDdOaXhycTZ1SzFldUNDY1kwOU1SQ0FSQzZ6RytheS9EdzhOZXI3ZTl2ZjNJa1NQQ2NXTjZP
dXAwcUlJcVhhaWlGSVk2blI2RGVEcnVlOEVTU3l6MXRjUjlMK0ZCblE1VlVLVXZWWlRDVUtm
VFkweFBSeUFRQ0sxSGxEd2QvVjcrRWRxc1hLQUtxaEpIRmFVdzFPa3FKSVNuSXhBSWhOWURm
UmxWRUgxR092QkpQczFuRk4xNy9pWHNITXF0VWU3eGhIc0ZWRUVWVkFtWHBEWnpJdmVvSFZY
UitvelVtSjdPZ1RvZGdVRG9KbkR0SlN5NG5nNVZVS1V2VlpUQ2NEMmRIcTE0ZWwxZFhXNXVy
c1ZpS1Nnb2FHbHBJWVF3QXJnNS9mMzlwYVdseWNuSnBhV2wvZjM5MG8yZ1RrY2dFTHFKU0Qz
ZDcvZnI0UCtSUHZ6d3crM3Q3WUZBWU5ldVhYYTduUkRDV3psUFdWbVp5K1VLQkFJdWw2dTh2
Rnk2RWRUcFVBVlYrbEpGS1F4MXVwRFcxdFpUcDA1ZHUzYnQyclZybloyZHJhMnR3bWUxNHVr
ODNkM2REb2VERU1Jd3pLMjMzbXExV3Bjdlg5N2QzVTBJc2R2dFhxK1hFT0wxZWpuZkY0RTZI
WUZBNkNZaTlYUzMyejB5TXNJOUhoa1pjYnZkd21lMTVla0RBd05GUlVVZmZQQUJQekk0T0Zo
UlVWRlNVa0lJU1VwSzRvNGtGQXFaVENiaGlxRUxGNjVVVlcxWXRZcnN6Ynpld1hoM2xsN3ZZ
TGpIS2t0U214bDJEdVhXS1BjNDhFaytWRUVWVkFtWGdVMkZFN2xIN2FqNkc4dGVxYW9LdHJl
UDFTZDFVNmUzdGJVNUhJNDllL2FJeHYxK3Y4VmlJWVNrcDZlalRrY2dFQWFKU090MG44K25n
K3ZwMWRYVkdSa1p6YzNOb3ZGTGx5NXQzTGl4dUxpWUVPSjBPdm5yNlU2blU3b1JYRStIS3Fq
U2x5cEtZYmllVG85V1BKMjVrYUdoSWU1QlNrcktzbVhMVHA4K1RRanA3ZTB0S1NteFdDeUxG
eS91Nit1VGJnUjFPZ0tCMEUzZ2U2UmhRWjBPVlZDbEwxV1V3bENuQytGTW5MZnloUEIwQkFL
QjBIcEU2dWtlaitmcTFhdHV0L3ZLbFN0WHJseHBhbW9TUG1zUVQwZS9GNmlDS2oycThxTGZ5
OWo3dlh6OTlkZU5qWTA5UFQxSGpoenhlRHhuenB3UlBtc1FUK2RBblk1QUlIUVR4djZNTkNy
Z2VqcFVRWlcrVkZFS3cvVjBJWW40R1NrQ2dVQm9QVkNuaHdWMU9sUkJsYjVVVVFwRG5VNlBN
VDBkZ1VBZ3RCN3dkQlZ3M3d0VVFaVWVWWGx4Mzh1NC84K1JDSU40T2dmcWRBUUNvWnN3ZHYv
MHFJRHI2VkFGVmZwU1JTa00xOU9GNktZdjQvaEJuWTVBSUhRVGlkQS9mWnlnVG9jcXFOS1hL
a3BocU5PRm9FNUhJQkFJN1lXeCs2ZVBFOXozQWxWUXBVZFZYdHozZ3Z0ZVZFQ2Rqa0FnZEJQ
b0RSQVdYRStIS3FqU2x5cEtZYmllTGdUOTB4RUlCRUo3QVU4UEMrcDBxSUlxZmFtaUZJWTZY
VWhDZUxyb00xSXNzY1FTUzQwdm8vVVpxVEU5blFOMU9sUkJsYjVVVVFwRG5hNUNRbmc2QW9G
QWFEMk1mZDlMWFYxZGJtNnV4V0lwS0Nob2FXa2hoUFQzOTVlV2xpWW5KNWVXbHZiMzk4dU9p
RUNkRGxWUXBTOVZsTUpRcDZ1Z1VVOS8rT0dIMjl2YkE0SEFybDI3N0hZN0lhU3NyTXpsY2dV
Q0FaZkxWVjVlTGpzaUFuVTZBb0hRVFJqYjAzbTZ1N3NkRGdjaHhHNjNlNzFlUW9qWDYrVmNY
am9pQW5VNlZFR1Z2bFJSQ2tPZFRvKzJQSDFnWUtDb3FPaUREejRnaENRbEpYRzl4MEtoa01s
a2toM2hDVjI0Y0tXcWFzT3FWV1J2NXZVT0Jrc3NzY1JTNDh1L3NleVZxcXBnZS90WWZWSWYx
OU1KSVcxdGJRNkhZOCtlUGR5UDZlbnBvcXBjT2lJQ2RUcFVRWlcrVkZFS1E1MU9qMVk4dmJx
Nk9pTWpvN201bVI5eE9wMzgxWE9uMHlrN0lnTFgweEVJaEc3QzJQZTlNRGN5TkRUVTI5dGJV
bEppc1ZnV0wxN2MxOWRIQ0pHT2lFQ2REbFZRcFM5VmxNSlFwNHNJQm9NZmYveHhZMlBqK2ZQ
blJVOXB4ZE9qQXVwMEJBS2htNGpVMHpsRFAzWHExTVdMRjV1Ym15OWZ2aXg4MXBpZWpqb2Rx
cUJLRjZvb2hhRk9GL0xSUngveGRuM3UzRG51Q3owOEJ2RjA5SHZCRWtzczliV011TitMeUt2
UG5Ea2ovTkVnbnM2Qk9oMnFvRXBmcWlpRm9VNFhvby9QU0tNQ3JxY2pFQWpkQkhydGhnVjFP
bFJCbGI1VVVRcERuUzRrRVQwZGdVQWd0Qjd3OUxDZ1RvY3FxTktYS2twaHFOUHBNWWluNDc0
WExMSEVVbC9MaU85N1NjVFBTRkduUXhWVTZVSVZwVERVNlZKR1IwZEZGMkU0ak9ucENBUUNv
ZlVZaDZlSFFxRnZ2dm5HN1haZnZueTVzYkZSK0pReFBSMTFPbFJCbFM1VVVRcERuUzZrcDZl
bnBhWGwrUEhqWjgrZWJXeHMvT2FiYjRUUEd0UFRFUWdFUXVzUnFhZC85dGxub2g0dlFvenA2
YWpUb1FxcWRLR0tVaGpxZEhvTTR1bTQ3d1ZMTExIVTF6TGkrMTdVTVlpbmM2Qk9oeXFvMHBj
cVNtR28wK2t4cHFjakVBaUUxZ09lSGhiVTZWQUZWZnBTUlNrTWRUbzl4dlIwQkFLQjBIckEw
OE9DT2gycW9FcGZxaWlGb1U2bnh5Q2VqdnRlc01RU1MzMHQ0M25meTV0dnZwbVdscGFXbHZi
Zi8vM2YwZDE5ZEVHZERsVlFwUzlWbE1KUXA5T2o2T2tzeS9LUFUxTlRqeDgvZnZ6NDhiUzB0
RmlJaUJhNG5vNUFJSFFURSt6cHQ5OStlMDFOVFNnVUloUGk2Y3lQU0VmNHdmNysvdExTMHVU
azVOTFMwdjcrZnVsR1VLZERGVlRwU3hXbE1OVHA5Q2g2ZW10cjY5S2xTN096czk5OTk5M2R1
M2VucHFhbXBxYSsrZWFic1JEQkkvSjAwYk5sWldVdWx5c1FDTGhjcnZMeWN1bnFxTk1SQ0lS
dUlpNmZrWG84bmp2dXVLT3dzTkR0ZHNkaTl5SkVubjdycmJkYXJkYmx5NWQzZDNjVFF1eDJ1
OWZySllSNHZWNjczUzVkSFhVNlZFR1Z2bFJSQ2tPZFRvK2lwL09maTc3MTFsdnZ2dnR1ZG5a
MmFXbnB4eDkvSEFzUlBOTGFmSEJ3c0tLaW9xU2toQkNTbEpRME1qSkNDQW1GUWlhVFNUZ3Rk
T0hDbGFxcURhdFdrYjJaMXpzWUxMSEVFa3VOTC8vR3NsZXFxb0x0N2RGMVVVVlBUMHRMYTJ0
cjQ2K2hoMEtoM2J0MzMzNzc3ZEhkdlFpcHB4TkMvSDYveFdJaGhLU25wNk5PaHlxb01wSXFT
bUdvMCtsUjlIVFp6MFdGTjhQRUFxbW5YN3AwYWVQR2pjWEZ4WVFRcDlQSlgwOTNPcDNTMVhF
OUhZRkE2Q1ltMk5OcmFtb201bk5SRHVaRytKR1VsSlJseTVhZFBuMmFFTkxiMjF0U1VtS3hX
Qll2WHR6WDF5ZmRDT3AwcUlJcWZhbWlGSVk2blI2RGZJK1VBM1U2QW9IUVRjRFRWUkQxQmhq
NEpKL211N25kZS80bDdCektyVkh1OFlSN0JWUkJGVlFKbDZRMmN5TDNxQjFWK0o4WTRVR2Rq
a0FnZEJPbzA4T0M2K2xRQlZYNlVrVXBETmZUNlRHbXB5TVFDSVRXQTU0ZUZ0VHBVQVZWK2xK
RktReDFPajNHOUhRRUFvSFFlc0RUVmNCOUwxQUZWWHBVNWNWOUw3anZSUVhVNlFnRVFqZUJP
ajBzdUo0T1ZWQ2xMMVdVd25BOW5SNWplam9DZ1VCb1BlRHBZVUdkRGxWUXBTOVZsTUpRcDlO
alRFOUhJQkFJclFjOFhRWGM5d0pWVUtWSFZWN2M5NEw3WGxSQW5ZNUFJSFFUcU5QRGd1dnBV
QVZWK2xKRktRelgwK2t4cHFjakVBaUUxZ09lSGhiVTZWQUZWZnBTUlNrTWRUbzl4dlIwQkFL
QjBIckEwMVhBZlM5UUJWVjZWT1hGZlMrNDcwVUYxT2tJQkVJM2dUbzlMTGllRGxWUXBTOVZs
TUp3UFowZXJYZzY4eVA4U0g5L2YybHBhWEp5Y21scGFYOS92K3lJQ05UcENBUkNOMkZzVCtj
UWVucFpXWm5MNVFvRUFpNlhxN3k4WEhaRUJPcDBxSUlxZmFtaUZJWTZuUjd0ZXJyZGJ2ZDZ2
WVFRcjlkcnQ5dGxSMFNnVGtjZ0VMcUpSUFAwcEtTa2taRVJRa2dvRkRLWlRMSWpQS0VMRjY1
VVZXMVl0WXJzemJ6ZXdYaDNsbDd2WUxqSEtrdFNteGwyRHVYV0tQYzQ4RWsrVkVFVlZBbVhn
VTJGRTdsSDdhajZHOHRlcWFvS3RyZEgxMFcxNitucDZlbWlxbHc2SWdKMU9nS0IwRTBrV3Az
dWREcjVxK2RPcDFOMlJBU3VwME1WVk9sTEZhVXdYRStuUnl1ZXp0d0lJYVMzdDdla3BNUmlz
U3hldkxpdnIwOTJSQVRxZEFRQ29ac3d0cWRIQmRUcFVBVlYrbEpGS1F4MU9qM0c5SFFFQW9I
UWVzRFRWVUMvRjZpQ0tqMnE4cUxmQy9xOXFJQTZIWUZBNkNaUXA0Y0YxOU9oQ3FyMHBZcFNH
SzZuMDJOTVQwY2dFQWl0Qnp3OUxLalRvUXFxOUtXS1VoanFkSG9NNHVtaXowaXh4QkpMTERX
K3hHZWs0VUdkRGxWUXBTOVZsTUpRcDlOalRFOUhJQkFJclFjOFBTeW8wNkVLcXZTbGlsSVk2
blI2ak9ucENBUUNvZldBcDRjRmRUcFVRWlcrVkZFS1E1MU9qMEU4SGZlOVlJa2xsdnBhNHI2
WDhLQk9oeXFvMHBjcVNtR28wK2t4cHFjakVBaUUxZ09lSGhiVTZWQUZWZnBTUlNrTWRUbzl4
dlIwQkFLQjBIckEwOE9DT2gycW9FcGZxaWlGb1U2bnh5Q2VqdnRlc01RU1MzMHRjZDlMZUZD
blF4VlU2VXNWcFREVTZmUVkwOU1SQ0FSQzY1Rm9uczRJNEViNisvdExTMHVUazVOTFMwdjcr
L3VscTZCT2h5cW8wcGNxU21HbzArblJ0S2VMUnNyS3lsd3VWeUFRY0xsYzVlWGwwbFZRcHlN
UUNOMUVBbnI2cmJmZWFyVmFseTlmM3QzZFRRaXgyKzFlcjVjUTR2VjY3WGE3ZEJYVTZWQUZW
ZnBTUlNrTWRUbzkydlYwanNIQndZcUtpcEtTRWtKSVVsTFN5TWdJSVNRVUNwbE1KdUcwMElV
TFY2cXFOcXhhUmZabVh1OWdzTVFTU3l3MXZ2d2J5MTZwcWdxMnQwZlhNN1h1NllRUXY5OXZz
VmdJSWVucDZhalRvUXFxaktTS1VoanFkSHEwN3VtWExsM2F1SEZqY1hFeEljVHBkUExYMDUx
T3AzUXlycWNqRUFqZFJLSjVPbmZIUzBwS3lySmx5MDZmUGswSTZlM3RMU2twc1Znc2l4Y3Y3
dXZyazY2Q09oMnFvRXBmcWlpRm9VNm5SN3VlSGdHbzB4RUloRzRDbmg0VzFPbFFCVlg2VWtV
cERIVTZQUWJ4ZFBSN3dSSkxMUFcxUkwrWDhLQk9oeXFvMHBjcVNtR28wK2t4cHFjakVBaUUx
Z09lSGhiVTZWQUZWZnBTUlNrTWRUbzl4dlIwQkFLQjBIckEwOE9DT2gycW9FcGZxaWlGb1U2
bnh5Q2VqdnRlc01RU1MzMHRjZDlMZUZDbjYxSlZwU1pWYVROWGhsTkZLUXgxT2ozRzlIU0Vu
a0xCMHhFSWd3YzhQU3lvMC9Xb2lsbDlXSU9xdEprcjQ2bWlGSVk2blI1amVqcENSNkhrNlFp
RXdRT2Vyb0xvTTlLQlQvSnBQcVBvM3ZNdlllZFFibzF5anlmY0s2QktOR2VCNjZBR1ZXa3pW
OFpUNWYxa0Fhbk5uTWc5YWtjVlBpTU5EK3AwUFFicWRFU0NCdXIwc09CNnVoNVY0WHA2SXF1
aUZJYnI2ZlFZMDlNUk9nclU2WWdFRFhoNldGQ25LODZwVkx0bE1KNnFVS2NudGlwS1lhalQ2
VEdtcHlQRVVYbGp4RjFQQjNQOVJ6ZS93ZE1ySlE4bVBsSHhUZ3ZDYUtGMFVzSFRWY0I5TDJw
ektwa0Zyb1BNNnNQOFVoT3FmcnpqNVFZOVd4WmNyMlE0emZIS2xSWmZRVzJlVjlGUTVVMkUr
MTcraFB0ZUl1VWZkWG9jeTFMdEZYck02c09paUxza1h0ajF5aHZxZEc1RU5EaVJMNU4ya2tO
MUNGcjZxeXVlU1loRlZpc2xQMHFEYnB1S0p4WHE5TEQ4M2RNcm1ZRXQrVFNwai80VlJ0SHVK
THVXMzVUdzdJbXVxaTM1bkQrcWUzcThyc1l5UC82KzRSUEYvOGlzUGh4RFZkS3pvdklmdVZJ
L2MwUWZCc2pPaVZ5Vndpc29yMGN3SGttdXh0Rm1SMFBYMDIvTVRDVGlLK1cyVnNtUWlzd3do
azZUOWtybWVpV1Q3em9vZjFFUm50N2YzMTlhV3BxY25GeGFXdHJmM3krZHNISGpScjdLdThI
Q3dyMDJVWXdKM2gyTkhobFBqN2VxdjJzVGVycEU3UVMvVFAvNG95SGVhVkhYT2ZHNTBuSkUv
ZkJsM2krQzRpT3k5NUhpekI4OXZlNnBweTcxOWtiTEovWGs2V1ZsWlM2WEt4QUl1Rnl1OHZK
eTZZU05HemR5dWM3L0pQL3ZyOFNQcjRmMDFicE85NnY0dXJUcVY1NGplckdsTDd6c3BvUm5U
M1JWNWJzTy92MmtWRDBkYVRZMUhsV3l1MU1TeGdmTnBpSlRKYnU3ditjcTNKdDJZRXYrMzAr
bkRzVzNhOFNxcEFjclVuWERzNEl6bk4rVXJCN1pzNTNwb0ZLbE5JZkcxR2cyUlprdXhUZk9q
eGtZazNpMWsrSEhEZjZ5TnZNR0Q1RUxwZDNKbmxveUw5Q1BubDdwY0d5Wk4rK3ZyNzQ2SEFp
TTN5ZjE1T2wydTkzcjlSSkN2RjZ2M1c2WFR0aTRjV1BZbHdHQlFDQzBFRUpQNTJMSFAvL3p0
MGVPak5NbjllVHBTVWxKSXlNamhKQlFLR1F5bWJqQnpzN081NTkvM3JWdTNiTVBQUEIvbGk1
OTdva25ubi8rK2Q4KytPRHp6ei9QUFZaWlZqenlTTmc1bEZ1ajNPTy8vZHUvUVJWVVFaVncr
Y3c5OTB6a0hyV2ppbk90OWIvNXpUODhmZW5TYnc4ZkhxZFA2c25UMDlQVHc5YnAzSU16Wjg3
UWJERHd5U2MwMDJpMlJybEhtbWxRUlQ4TnF1aW5hVk1Wb1JNV3hUMXFVQlYzN2VXVFAvODU0
YTY5T0oxTy9ucTYwK21VVHVBOVBSZ00wbXp3eXE1ZE5OTm90a2E1UjVwcFVFVS9EYXJvcDJs
VEZhRVRGc1U5YWxCVjNaTlBYdXJwb2RrVURYcnk5TjdlM3BLU0VvdkZzbmp4NHI2K1B1a0Uz
dE1wQ1owL0h5VnAwUVNxNklFcWVyU3BpbWhWbURaVjBhQW5UdzlMZTN0N3ZDVUFBRUE4TVpT
bkF3QkFnZ05QajV5NnVycmMzRnlMeFZKUVVORFMwa0lJWVg1RVU2cWtJMXBRVlZ0Ym01MmRy
VFZWSEgvNHd4L2krQ0txbkZlYVVqVXlNdktIUC94aHhvd1pOOTEwazZhRUNkT1ZucDZ1RVZY
MTlmVlpXVmttazJuMjdObjE5Zld4MnpVOFBYSWVmdmpoOXZiMlFDQ3dhOWN1NFgwNDhmVjBx
U29sbmZGVjlmampqM2QzZC92OS9uZmZmVGRlYnp6WnpCdy9mbno2OU9seGZCR2xxdUo3Um5G
SVZiMzAwa3Z6NXMxcmIyOGZIUjNWbERDZVk4ZU8vZTUzdjlPSXFpbFRwbmc4SHBabDNXNjN6
V2FMM2E3aDZWR2d1N3ZiNFhEd1AycmhIVWdrcW1SSEpoNlJCcFpsMzN2dnZmejgvRGhLSWdK
VmdVQmd3WUlGUjQ4ZTFjS0x5S3RpR09iV1cyKzFXcTNMbHkvdjd1N1dpQ3FIdytGMnUrTXJS
b2owOUY2K2ZQbTVjK2ZpcFllRFY1V2ZuKy94ZUlMQm9OdnRMaXdzak4wZTRlbmpaV0Jnb0tp
bzZJTVBQdUJIdEdBSFVsWFNrYmlyNHY0NlRrMU4vZXl6enpTaWFzMmFOWC82MDUrSUJsNUU2
ZXMxT0RoWVVWRlJVbEtpRVZVbWsybnQycldUSmsxeU9Cd0hEeDZNb3lvaWw2N1cxdGJISDM4
OGpwTElqYW8rLy96ektWT21NQXd6WmNxVXp6Ly9QSFk3aGFlUGk3YTJOb2ZEc1dmUEh1Rmcz
TzFBcWtwV1o5eFZFVUs0YXk5ejVzelJpQ3J1MG5EY0wxNHJ2VjUrdjk5aXNjUkZFcEdvc3R2
dGJyZWJ1NWd3ZGVyVWVLbVNDdU5ZdG16WlYxOTlGUzlKUktKcTd0eTUvTFdYbi83MHA3SGJM
enc5Y3FxcnF6TXlNcHFibTBYajhmVjBxU29sbmZGVnRXYk5tdlBuei92OS92Mzc5MCtiTmsw
anFuamkrQ0lxcWJwMDZkTEdqUnVMaTR2aklVcEdWWGw1dWR2dDVpNG1aR1JreEVXVnJEQkN5
TWNmZi95em4vMHNYcEtJbktyVTFGVCsya3RhV2xyc2RnMVBqeHptUm9hR2hrUWoybFExTkRT
a0JWVTFOVFV6WnN4SVRrNis4ODQ3Ly9LWHYweThKRmxWd3FmaUlrbFdGZmNnSlNWbDJiSmxw
MCtmMW9pcXMyZlAvdXhuUDdOWUxGbFpXWEc4c0M3N0l2Nzg1ejkvLy8zMzR5VkpWbFZkWFoz
RDRUQ1pUTE5telhydnZmZGl0MnQ0T2dBQUdBZDRPZ0FBR0FkNE9nQUFHQWQ0T2dBQUdBZDRP
Z0FBR0FkNE9nQUFHQWQ0T2dBQUdBZDRPa2hRNG5nSE9nQ3hBNTZ1SjRMQjRMcDE2NlpPblhy
TExiZHMyclFwM25MMEFjTXdyN3p5Q2lIazVaZGZobzlUMHQ3ZXpqQU0vc2tNSlpvNngrRHBl
bUw5K3ZVUFBQREF1WFBuTGwyNjlNd3p6OFJiamo1Z0dDWW5KMmQwZEhUZXZIbHhmNy9waFMx
YnRpUWxKVzNac2lYZVF2U0JwczR4ZUxxZW1EbHpwdWgva0F0UElQNHh3ekRyMTYrM1dxMThT
OCs0bjJkeGhHR1lKVXVXdlBUU1MwdVhMaFdtU0pTNjExNTdMUzB0TFRVMWRkZVAvMXc0a1pP
MmJObXlwNTU2YXRteVpkeVBoWVdGM0Q5Mk9IVG8wTUtGQ3draHg0OGZ6OG5KU1VsSmNibGN3
cXpHUzNCOGtaNWozQWxtTnB2NS80bXhhdFdxWC8vNjE0U1F4eDkvZlBYcTFmeUtVUmNEVDlj
VEpwTXBGSC83NEhnQUFCeHpTVVJCVkFvSlI1UTgvWlZYWHZINWZFOC8vZlNFNnRNa0RNUHMz
YnMzS1NscDM3NTlzdW5pSG0vZnZ0M3Y5emMyTnNicjM0Wm9CNS9QTjNueTVIUG56azJlUE5u
bjh4RkN0bTdkV2w1ZVRnZ3BLeXZidG0wYklTUS9QLytOTjk3dytYeTdkdTFLV0N2blVUckhR
cUZRYTJ2cjlPblRDU0hEdzhOMzMzMzN2Ly83djk5OTk5M0R3OE94RXdOUDF4TXFkZnJ3OExE
UTA2OWR1emJSNHJTS2lvOExIL052TXpoVVEwTUQzM3lxb2FHQkVQTEREei9ZYkxZelo4N1li
TGFMRnk4U1FzeG1zOS92SjRUNC9YNWtUSHBlYmQrKzNlRndKQ1VsTVF4ejAwMDNjVThkUDM2
Y1laamp4NC9IVkF3OFhVOVVWRlE4OE1BREF3TURseTlmcnFpb0lJVFk3ZmJtNXVaQUlMQmp4
dzc4Q1N3THBhZkxQazVNVnE5ZXpYMEN2Mm5USnY0cWdkUHB2T09PTzhyS3lyZ2ZGeXhZc0hQ
blRyL2YvMS8vOVYvSW1QVDhTVWxKYVd4czlQdjlicmViRy9INy9RVUZCY3VYTHk4b0tBZ0VB
ckVUQTAvWEV5ekwvc2QvL0lmZGJ1ZnZlNm11cnJiWmJHbHBhZHUyYlZQeDlFUisxMG5mYjZJ
K3FMSnpTQUluTFNzcjYrVEprNFNRa3lkUFptVmxjWU9IRGgxaUdPYlFvVVBjajIxdGJkbloy
U2twS2M4OTkxeFNVaEkzbUxBWms1NC9MN3p3Z3MxbXM5bHNtemR2NWtaV3JsejUyR09QRVVJ
ZWZmVFJKNTk4VXJwaXRJQ25Bd0FpWkdSazVQMzMzNTgzYjE2OGhZQi9BRThIQUVRQ2Q2VTRL
eXNyWHYvU0JNZ0NUd2NBQU9NQVR3Y0FBT01BVHdjQUFPTXdOazluRklpaW9JVDk2RHhhMEx3
b3d0Y3VQVDJkY2kwRE05YWtjU005UFQwbEpTWEp5Y2tsSlNXOXZiMFRvbFFyMEdTc3ZyN2U0
WEJZTEpaLytxZC82dXJxa2gweEtudjI3Smt6WjQ3RllsbTRjT0hSbzBjSklmWDE5ZlBuejA5
T1RpNHFLdnI0NDQ5VjFxMnNyQnpQT1RaMlQrK1FCRHhkZTFDbWNmWHExUnMyYkJqcldrWWxy
S2VMUmg1NjZDR1h5eFVJQkZ3dWw5UHBqS0V5cmFLZXNmVDA5SmFXbG1BdzZIYTc3Ny8vZnRr
Um8vTFFRdytkUEhreUVBanMyYk9IKzJheTArbnM2T2hnV2ZiQWdRUFRwazFUV3ZIRWlSTVpH
Umw4WWlNNHgyTGw2VnUzYm5VNEhDYVRpZjlsdm1qUkl1N20xdHJhMnRMU1V0azUwbEtvczdO
ejhlTEZGb3RsN3R5NTNDODNobUh1dlBQT3NyS3kyYk5uODkrQUFDSm8zUG5TcFV1cHFhbG56
NTRkMDFvR0pxeW4yMncycTlWNnp6MzNkSGQzRTBMUzA5TzlYaThoeE92MUptWkhnYkNlZnZq
d1ljN0IwOUxTWkVjTVQxOWZuOFZpNGIvWDdmZjc2K3JxbE83K1pGazJMeS92N2JmZjVoTWJ3
VGtXSzArZlBIbHlaV1ZsUjBkSE1CamtSdmJ0MjhkWmNGRlIwUWNmZkNBN2gwak9rcUtpb25m
ZWVZZGwyYWFtcHJsejUzSVQrRWFna3lkUHBqbklCSVRHblRkdjNzeDlDV0pNYXhrWW1zTS9m
LzU4UlVWRlNVa0pJU1FwS1dsa1pHVEpraVdoVU1oa01zVmVvT1pRejFodGJlMXR0OTAyYWRL
azU1NTdqc3VQZE1UWWZQLzk5OFhGeFh3TFZmNXE1NWRmZmlrNy85bG5uMzNra1VlSUlMRVJu
R094OHZRUFAvenczbnZ2blR0MzdpMjMzUEw3My8rZUVESThQRHhuenB6OSsvZHpUU2xsNXhE
SldXSTJtL25Lbld1YndGZjAwc21BSjJ4bWhvZUhNek16UmEwbkVqeWZsSWNmQ0FRc0Znc2hK
RDA5ZlhCd2tLQk9EOGZSbzBkbnpweXBQbUk4dnZ6eXk5bXpaN3RjcnBHUkVYN1E1L1B0Mjdj
dkx5OVBkaFd1UDR6d1drVUU1MWhzcjZlUGpJd2NQWHJVYXJWeVAyN2F0TWxxdGZLOVRHWG5K
Q2NuYzMvWWNoUVhGemMwTkFqYkk4RFRhUWliR2Y0SzJKaldNalkwaDMvMTZ0V1hYbnFwdUxp
WUVQTGdndzl1MkxDQlpka05Help3NVZXaUVUWmpvNk9qbloyZCtmbjVYSHNpMlJGRFVsTlRV
MXhjL09tbm4vSWpLMWV1N09ucFlWbTJycTR1N0hVblByRVJuR094OG5UdTkweFNVdEtzV2JQ
ZWVPTU5idkRDaFF2cDZlbGNPemVsT2V2V3JVdEpTZUczZWVyVXFidnV1b3Nia2JwNWdudVFM
TXlOOElPaWFZc1dMZHEvZjcvNldva0RUZEs0cDI2KytlYTc3cnJyOU9uVGhKRHU3dTVGaXha
eGQzSDA5UFRFUVhmOG9NOVlSa2JHbWpWcldKYVZIVEVxb3Z3TURRMjk5ZFpiczJmUE5wdk5l
WGw1SG8rSG42YTBPdmNnZ25OczR1NWxIQmtaZWYzMTE5ZXRXMGN6R1FBQVFBUk0zSGVPR0lZ
cExDemtQc01GQUFBUUMvQTlVZ0FBTUE3d2RBQUFNQTd3ZEFBQU1BNmE2L2NDeGdsTmd3aHAy
dzNocThsMWdFa29hSkltVFpHMHAwZmlRUFBlbCtZbmNVNHoyWnVDd2lhTlpkbTFhOWR5dlFH
NGFmWDE5VmxaV1NhVEtTc3I2OENCQXpTN0hydW5yejRzRG5pNmxxQnBFS0hTZGtQVUFTWkJH
Rk5YRFQ1RjBwNGVpWWI2ZTE4bFA0WS96YVNab2ZISmlvcUt3c0xDam80TzdsdVpoQkNiemRi
VTFNU3lyTWZqc2Rsc05MdU9sYWNMQjduSDB1NHUwbDR1M09UMTY5ZGJyZGJDd2tLYUF3QWlh
QnBFS0xYZGtIYUFTUkRvdTJySXBralUweU54b0t6blJQbEpoTk9Na1hRSGtvNUltVEZqeGtj
ZmZTUWNLU2dvT0hUb1VEQVliRzV1WHJod0ljMnVKODdUcGQxZHBMMWN1TW12dlBLS3orZDcr
dW1uYVE0QWlLQnBFS0hVZGtQYUFTWkJvTytxSVUyUnFLZEhRa0hqNmRMOEpNNXBKdXdPcERR
aXhHUXl1Vnd1cTlXYW1abkpmU1d3cmEwdE5UV1ZZWmpVMUZSUkp3OGxZdTdwdzhQRDNHTnBk
eGRwTHhkdXhRU3NkNkxJbUJwRUNOdHV5SGFBU1JBb2t5Wk5rV3hQajhRaHJLZEw4NU5vcHhu
ZkhVaGxoQ2MxTmRYdGRnZUR3WmFXRnU3emh1enNiSS9IdzdLczIrM095Y21oMldPc1BOMXV0
emMzTndjQ2dSMDdkZ2duQ0x1N1NIdTVFSHpkZjl4UU5vaVF0dDJRN1FDVElGQW1UWlFpYVUr
UFJFUDkzU3FibjRRNnpZVGRnWlJHaEt4WXNZTDNkSzYybURKbGlzZmpDUWFEVFUxTmNiNmVY
bDFkYmJQWjB0TFN0bTNieGdoNm93dTd1MGg3dVJCNCtyaVJiUkFoeWlxWGNGSGJEVkVIbUlT
Q0pta2tYSk9jb2FHaGlWTWNiMFRIemcrcXpPSHlreUNuR1hmSXd1NUEwaEVpeVZoWFY5ZWlS
WXZNWnJQRDRhaXZyeWVFMU5iV09od096amJyNnVwb2RvMTdHUUVBd0RqZ08wY0FBR0FjNE9r
QUFHQWM0T2tBQUdBY0p0clRjZkVkQUFCaUJ6NGpOUm8wVFVpRXJ4MTNHMnlDdjVvMHh5NU5r
YlJ0VHVKQWM1cEo4NE1PT2Vxbm1iUzdTd1R2eWpGNyt2VktjU1NtQzJpV01UVWg0ZHR1NEVV
azRaSWdmVmFsYlk3aG9Ubk5wUGxKNUE0NU5HOHhwZTR1bXZCMGhtRmVlKzIxdExTMDFOUlUv
cDlLaTM3aGZQWFZWd3NYTHVRNndIQWpzaDFnUUdTRWJVSWliTHZCVURTak1EeGhQVjJVSXFX
Mk9RbUZ5bW1ta3A4RTdKQkQ4eFpUNnU2aUZVL2Z2bjI3Mys5dmJHd1Uva0lXVHM3UHo5KzJi
WnZ3WDgzS2RvQUJFVURUaEVUYWRrTzlHWVhob1hubkNGT2sxRFluY1ZBL3paVHlrOGdkY3RU
ZllrcmRYYlRpNmNQRHcxSkJ3c2Rtczlubjh3blhrdTBBQThZS1RSTVNwYlliS3Mwb0RBL2xP
MGVhSW1IYm5NU0J2dGVOTUQ4SjNpR0hxTDdGbExxN2FNWFR3ejVlc0dEQnRtM2IrRGFOUktF
RERCZ1RsRTFJWk50dXFEZWpNRHcwN3h4UmlxUnRjeElFeXROTWxCOTB5RkYvaXlsMWQ5R29w
ek0zUWdqNTRvc3ZDZ29La3BLUytNbXlIV0RBbUJEbG1XdXlJVTJtYk9zU1VUT0t4RUY2Y2hL
RjdpWFNEaDZpdGprSkFzMXBKczJQN0ZvSmd1eGJUSlF4YVhjWDJUTlRIZHpMQ0FBQXhnSGZJ
d1VBQU9NQVR3Y0FBT01BVHdjQUFPTVFXMDlYdXRTT2EvRUFBQkFMNHZNWnFkS3RCVUFkMlhz
emVMak9MVFJOU0ZpV1hidDJiVVpHQnI4cEEvK0tyYSt2bno5L2ZuSnljbEZSRWZmbFpHblNw
QW1SSWsyK1VidVhVSjVtb3F4S2lVcjNFbDBnelpqMDJDUHJrQ1BOZkZqR2ZpOWpoempnNlJP
R1NycjR6aTAwVFVncUtpb0tDd3M3T2pwR1IwY3B0NjlmbkU1blIwY0h5N0lIRGh5WU5tMmE4
Q2srYVVvSkVTSk5qbEc3bDlDY1ppcFo1WWxLOXhKZElEMGk2YkZIMWlHSGg4OThXR0xvNmFK
ZnlHMXRiVGs1T1NrcEtSVVZGVXFlam40djZqQUtMU09FblZ0b21wRE1tREhqbzQ4K2t0MStq
SlRISGIvZlgxZFhOMi9lUEg1RW1EU2xoQWhSU2o0eFhQY1NtdE9NUTVwVklWSHBYcUlMcEJs
VE9uWVNVWWNjYWVaVmlHMmRMbnhxL3Z6NU5UVTFmcisvcXFwS3lkUFI3NFVHYWNzSVllY1dt
aVlrSnBQSjVYSlpyZGJNekV6Uk40OWlxanhlOEgrNmZ2bmxsL3lnTUdsS0NaRWlUYjVSdTVl
b24yWkVJYXRDb3RLOVJFY0lNNlowN0pGMXlKRzJabEpoNGp6ZGJEYjcvWDVDaU0vblUvSjA5
SHVoUk5neVFxbHppMG9Ua3RUVVZMZmJIUXdHVzFwYWhCZnBqUHBtSTRUNGZMNTkrL2JsNWVW
eFA0cVNwcFFRV1lUSk4zYjNrckNubVNpcklxTFN2VVJmOEJtVFBmYklPdVFvdmNHVm1EaFB6
OHZMNCtyMDZ1cHFmbno2OU9uQ1gvTG85MEtEcUdXRXRITkwyQ1lrSzFhczRDMU1xV3VtWVZp
NWNtVlBUdy9Mc25WMWRmemZzNktrS1NWRWlqRDV4dTVlb242YXlXWlZSRlM2bCtnSVljYWt4
eDVaaHh5aTBKcEpoVmg1T25NamhKQmp4NDVsWjJlbnBLU3NYNytlWDJYbnpwMVdxNVgvRWYx
ZTFPSFNJbW9aSWR1NVJkU0VSSlRNcnE2dVJZc1dtYzFtaDhOUlgxOVA1RjR2dy9EV1cyL05u
ajNiYkRibjVlVjVQQjV1VUpRMGFVSUlkYjhYSHNOMEw2RTV6V1N6S3NwWVZMcVg2QUpweHNJ
ZU8yV0hIQ0xKZkZqUTd3VUFBSXdEdmtjS0FBREdBWjRPQUFER0FaNE9BQURHSVQ3OVh1SzFI
UUFBTURhNi9Jd1VGcTlDVDA5UFNVbEpjbkp5U1VsSmIyK3Y3Qnhwc3c2YTloMEdoaVpwMGpt
SmZJOEFUY2FFRnNIZDlXL1VqQ2tkVjJWbEpUOUkyZTlGMUNXR0pzOGl4dXpweGN4Ym9vQ25h
NHFISG5ySTVYSUZBZ0dYeStWME9tWG5TSnQxMExUdk1EQTBTVk9hazVobkkwM0dlRVM5U295
YU1kRnhuVGh4Z3VzS3gvMUkwKzlGdGtzTWZaNDVZdWpwb2w5Y24zNzZhVzV1cnRsc3pzM041
VzY4ZHpnY1o4NmNJWVI4OTkxM0RvZURYOFZzTmhjVUZMUzB0TWh1Qi9kUXFwT2VudTcxZWdr
aFhxOVgvZXN6MG1ZZDZ1MDdEQXhOMHBUbUpPWjVTSCthU1h1VkdEVmp3dU5pV1RZdkwrL3R0
OStXSHF4S3Z4ZHBseGo2UFBQRXRrNFhQcFdUazdONzkyN3VlNlM1dWJtRWtKVXJWKzdjdVpO
aG1OMjdkei81NUpQOHpGQW8xTnJhT24zNmRObnRTSDhFUXBLU2trWkdScFlzV1JJS2haVDZ2
UkM1WmgzU2tjU0JKbWxLY3hMemJLUTh6WWhjcnhLalpreDRYTTgrKyt3amp6eENKQWVyM3U5
RjJpV0dQczg4RStmcEpwT0o3L2RpTnBzSklYdjI3TG4zM252dnZQUE9GU3RXdlAzMjI0U1E3
ZHUzYzErK1ltN3M5d0pQcHljOVBYMXdjSkJRL0dLWE51dFFiOTloWUdpU3BqUW5NYzlHeXRO
TXRsZUpVVE1tUEM3T3hFUlhGTUwyZTVGMmlhRi9PL1BFczA3djcrK2ZOR25TeXkrL2JMVmF1
VC9OVWxKU0doc2IvWDYvMiswV1hXOFJialk1T1ZuVTdCVHdQUGpnZ3hzMmJHQlpkc09HRFZ5
bElFWGFySU9tZlllQm9VbWEwaHlqT3BRNk5Ca2pDcjFLakpveDJlUGlCMm42dlVpN3hGRG1X
VWlzUEoyNUVVSklhMnRyVGs2T3lXVEt5Y25oRHl3N083dTN0NWUvZ1B2Q0N5L1liRGFiemJa
NTgyYm14disvSS94MXQyN2RPcTRuRE0wUkpocmQzZDJMRmkzaS9sVktUMDhQTnlqS2xiUlpo
Mno3anNTQkptblNPYkluWjRKQWt6R2kwSXpJZUJsVE9TNytSOUVjMlg0djBpNHhzbmxXUjVm
M01nSUFBSkFGM3lNRkFBRGpBRThIQUFEakFFOEhBQURqb0k5K0x3QUFBR2pBWjZSR0k3TFdK
UkcwbFRBU1NOcFlRY2JHeW9SbGJNeWUvaGJ6bGlqZzZab2lzdFlsRWJTVk1CSkkybGhCeHNi
S2hHVXNocDR1ZTZ2bSt2WHJyVlpyWVdFaEllVFlzV1B6NXMwVC9ZZFNNRTRpYTEwU1FWc0pJ
NEdralJWa2JLeE1XTVppVzZkTFBmMlZWMTd4K1h4UFAvMDBJV1QrL1BrMU5UVit2NytxcWdx
ZUhpMGlhMTBTUVZzSkk0R2tqUlZrYkt4TVdNWW0ydE9GM2NqTVpqUGZBUWFlSGkwaWExMFNR
VnNKSTRHa2pSVmtiS3hNV01ZbTJ0T0ZQK2JtNW5KMWVuVjFOVHc5V2tUV3VpU0N0aEpHQWtr
Yks4allXSm13ak1YSzAyVnZqQkhOYkcxdC9lbFBmNXFTa3VKeXVlRHAwU0t5MWlVUnRKVXdF
a2phV0VIR3hzcUVaVXdyOXpMQzB3RUFZUHhvNVh1azhIUUFBQmcvV3ZGMEFBQUE0d2VlRGdB
QXhpSE9ucjV6NTg3Smt5ZUh2ZkNDS3pNQUFFQkRuRDhqblQ1OStva1RKMFM3aUhocmdOQTFp
R0JaZHUzYXRSa1pHZnpMbDhpTk9FaWt2VGc0S2lzckUvQ2twWC92Qy9Pelo4K2VPWFBtV0N5
V2hRc1hIajE2Tk1ZYTQ0bjBTSVdHbVo2ZUxydFdmWDE5VmxhV3lXVEt5c282Y09BQU4rSndP
TGo3WHJxNnVtaDJQV1pQNzdndWp2R2MwTUovSk0zdkl1S3RBVUxYSUtLaW9xS3dzTENqbzJO
MGRKUitMUU1UV1M4T1FzaUpFeWU0WDQwVEpsVlRoRDF3VVg0ZWV1aWhreWRQQmdLQlBYdjJH
UHM3UnlwSHVucjE2ZzBiTnNpdVpiUFptcHFhV0piMWVEemMveU5OVDA5dmFXa0pCb051dC92
KysrK24yWFdzUEgzcjFxME9oOE5rTXZHL3pELzk5TlBjM0Z5ejJaeWJtOHY5UDFMWkc5aWx2
LytsNVFDRHZqSEswRFNJbURGanhrY2ZmVFRXdFF4TVpMMDRXSmJOeTh0NysrMjNFL2FzVXo5
d2xmejA5ZlZaTEJiaHQ4cU5pdWhJTDEyNmxKcWFldmJzV2RuSkJRVUZodzRkQ2dhRHpjM05D
eGN1SklTa3A2Y2ZQbnlZODNUS2YvNGVLMCtmUEhseVpXVmxSMGRITUJqa1JuSnljbmJ2M3Mx
OWF6UTNONWZmb0hRWHN2c1YvWWkrTVVyUU5JZ3dtVXd1bDh0cXRXWm1abkwvQWppUkczR1FT
SHR4UFB2c3M5eFgreEwyckZNL2NLWDhmUC85OThYRnhjODg4MHhzeFdrQTZaRnUzcno1c2Nj
ZVU1cmYxdGFXbXByS01FeHFhdXJ4NDhjSkliVzF0YmZkZHR1a1NaT2VlKzY1V1BWN29mVDBE
ei84OE41Nzc1MDdkKzR0dDl6eSs5Ly9uaEJpTXBuNDdpNW1zNW5mb0hRWHN2c1YvWWkrTVVy
UU5JaElUVTExdTkzQllMQ2xwWVc3dEpmSWpUaElwTDA0a3BLU292dk5POTJoZnRTeStmbnl5
eTluejU3dGNybEdSa1ltUkdQY2tCN3A4UEJ3Wm1ZbVo5YXlaR2RuZXp3ZWxtWGRibmRPVG83
d3FhTkhqODZjT1pObXY3RzluajR5TW5MMDZGR3IxVXFvNi9UazVPVHU3bTdwZmxWK1JOOFlJ
VFFOSWxhc1dNRjdPbWRQaWR5SWcwVGFpNE1uWWM4NnlnUG5wOVhVMUJRWEYzT1hYbzJON0pI
VzF0YVdscGFxckRWbHloU1B4eE1NQnB1YW1yanI2WVNRMGRIUnpzN08vUHo4aW9vS21sM0h5
dE81Mzh4SlNVbXpaczE2NDQwM0NDR3RyYTA1T1RrbWt5a25KNGMvVk9tNjY5YXRTMGxKa2Iz
Q0xod1Vyb0srTVVKbzJrcDBkWFV0V3JUSWJEWTdISTc2K25xbHRSS0h5SHB4OENUZ1dVZnp4
aFJPbGwxcmFHaG9ndVJPT0xKSHVtalJJdTVTcDNDYThNZmEybHFIdzhIWlpsMWRIYitkakl5
TU5XdldzQ3hMczJ1dDlIdUpGcG9TQXdBQUU0elJ2a2NLVHdjQUpESkc4M1FBQUVoazRPa0FB
R0FjTk8zcEdyeGVEd0FBV21aQ1B5T056SjNoNldPQzVrVVJ2bmJjL2VuMTlmWHo1ODlQVGs0
dUtpcjYrT09QSjBxc1ZxQkptclRmaXpTTmlRUE5DU1BOVCtKVWFaSDFlK0VRZHNpSklHTmo5
dlRya29DbmF4REtwUEd0SjV4T1owZEhCOHV5Qnc0Y21EWnRXb3pWYVJUMXBLbjBoRkhwNEdG
VXhuVENpUEtUQ08vb3lQcTlFSVVPUXByd2RHbS9GMmxkMzluWnVYanhZb3ZGTW5mdVhPNVhQ
ZmVzMld3dUtDaG9hV21KNEhnQUIwM1NwSzBuL0g1L1hWM2R2SG56WWlsTnU2Z25UYWtuakhv
SEQyTkRjOEpJODVOUTcrZ3g5WHRSNnBDakNVK1g5bnVSS2lzcUtucm5uWGRZbG0xcWFwbzdk
eTQvSGdxRldsdGJwMCtmSHNIeEFBNmFwSWxhVC9CL0ZYNzU1WmV4bEtaZDFKT20xQk5HdllP
SGdhRThZYVQ1U1p4MzlGajd2U2gxeU5HRXAwdjd2VWlWbWMxbXZuTG5tdTV1Mzc2ZCt4b1ZQ
ekxXNHdFY1laTW0yM3JDNS9QdDI3Y3ZMeTh2bHRLMFM5ZzZYZG9USm13SEQyTVQ5b1NSelUr
Q3ZLTWo2UGVpMUVGSUU1N09JZXozUWlTOVhJcUxpeHNhR2dLQkFEK1NrcExTMk5qbzkvdmRi
amUvMmVuVHB5ZHM1Umd4WVU4Q1VldUpsU3RYOXZUMHNDeGJWMWRIMmRMVGVLZ25UYmJmUzln
T0hrYUY4b1NSelU4aWVIcGsvVjU0dEZpbmM3OW5oUDFlaUtTWHk2bFRwKzY2Nnk1dWhCdDg0
WVVYYkRhYnpXYmJ2SGt6UDIzbnpwMVdxelVSem9Pb3dOd0lQeWlhSm1vOThkWmJiODJlUGR0
c051Zmw1WGs4bm9tVHF3MW9raWJiNzBYYXdTTkJrRDFod3A1bXNuazJKS0lqcGV6M0loMlBJ
R05HNi9jQ0FBQ0pqS2EvY3dRQUFHQk13Tk1CQU1BNHdOTUJBTUE0d05NQjBEVDR2QXFNQ1hn
NkFESkU3S1JSdDJDVkRVWmxYd3pEdlBMS0s0U1FsMTkrZVR3YlpCaG15NVl0NHhjbTdaUlNY
MStmbFpWbE1wbXlzcklPSERpZ3RIZlIvUm9zeTY1ZHU1YjducjJTSHZVZVBrb0twV3RKTmRN
Y2w4cmVWWTRyTFBCMEFHUklLRS9QeWNrWkhSMmROMi9lT0QwOU96djc2dFdyNHhRbTdaUmlz
OW1hbXBwWWx2VjRQUHgvNlZUU3dEK3VxS2dvTEN6czZPZ1lIUjFWMlplb2h3K05jdWxhS3Qx
ZFZJNUxxWU9RVkFNOEhZRHhJdnUrWW01c1JrVFQxRWg5eS94YUZSVVZLU2twOCtiTmEydHJJ
NFMwdGJYbDVPU2twS1JVVkZRSXR5emN1M1JmMGdaS3NnY2kxYk5reVpLWFhucHA2ZEtsM09S
UFAvMDBOemZYYkRibjV1WnkzNXBoR09hMTExNUxTMHRMVFUzZHRXdVgwbllxS3l0ZmZQRkZm
cWZTN1JRV0ZuTGlEeDA2dEhEaFFuVmhmS2VVZ29LQ1E0Y09CWVBCNXVabTliV0VCenRqeG95
UFB2cElaUUtSNitIRE1Jek5ack5hcmZmY2N3Ly9CY213YTBrMTB4eVgwbmJnNlFCRUg2VjNr
YkFaRVUxVEkvVXQ4MzVkWFYzdDkvdHJhbW9XTEZoQUNKay9mMzVOVFkzZjc2K3FxaExPVjIr
RnBOUkFLYXlldlh2M0ppVWw3ZHUzajl0Z1RrN083dDI3L1g1L2RYVjFibTR1TjJmNzl1MSt2
Nyt4c1ZHcERtVVlabWhvYU02Y09aY3VYVkxhenRhdFc4dkx5d2toWldWbDI3WnRVMUVsN0pU
UzF0YVdtcHJLTUV4cWFxcDZHd1poUWt3bWs4dmxzbHF0bVptWlN0OExVK3JoYy83OCtZcUtp
cEtTa2pHdEplM3VvbjVjU3R1QnB3TVFmYVR2SW1reklwcW1SaXBiSGg0ZTVqM2Q3L2NUUXZ4
K3Y4VmlJWVNZeldadXhPZnpjWE5vV2lGSkd5aU45VWk1eHlhVGlkKzcyV3pteG9lSGg5VVBr
QnZmdEduVDczNzNPNlh0L1BERER6YWI3Y3laTXphYjdlTEZpMHFTUkoxU3NyT3pQUjRQeTdK
dXR6c25KNGZ5V0ZKVFU5MXVkekFZYkdscFVlcFhMdHZEaHlNUUNIQ3ZCZVZhMHU0dVlZOUxh
ZS93ZEFDaWovUmRKTnVNaUlScmFpVEZicmMzTnpjSEFvRWRPM2J3bnM3VnN6VTFOZlBuenll
RTVPWGxjWFY2ZFhVMU4wZDI3MkViS0kzMVNGWHFkSlhNQ01kOVB0K3NXYk9VdGtNSWNUcWRk
OXh4UjFsWm1aSWVhYWVVS1ZPbWVEeWVZRERZMU5SRWZ6MTl4WW9Wdktjci9XMGgyOE9IRUhM
MTZ0V1hYbnFwdUxpWWNpM1o3aTVoajB0cDcvQjBBS0lQY3lORXJoa1I5NVI2VXlNcDFkWFZO
cHN0TFMxdDI3WnRvdXZwMmRuWng0NGRJNFFjTzNZc096czdKU1ZsL2ZyMVNudVg3a3ZhUUls
RWRDMm90YlUxSnlmSFpETGw1T1R3MTlObDU4dHVaOHVXTFVyYklZUWNPblNJWVpoRGh3NnA2
QkV5TkRSVVcxdkwvWTB5YTlhc3VybzZtclVJSVYxZFhZc1dMVEtielE2SG83NitYbGE4dElj
UHQvck5OOTk4MTExM25UNTlla3hyQ1RYVEhGZlk3Y2lPaEFXZURrQ2NHVk1WQm9BNjhIUUE0
Z3c4SFVRUmVEb0FBQmdIZURvQUFCZ0hlRG9BQUJnSGVEb0FBQmdIZURyUUJ3ME5EWTJOamFG
UXFMR3hzYUdoZ1hJVjlXZVZKdmg4UHJmYkxUdGZaUzBBdEFBOEhlaURob2FHVHo3NTVILy85
My8vK3RlL1JzdFZsYmJ6MVZkZlNaK0NsUU5kQUU4SCtxQ2hvZUhVcVZNZWorZlVxVk84dllv
ZU5EUTB0TGUzZXp5ZXpzNU9wVUhSTnFVN3VucjE2cUZEaDJROTNlUHhIRDU4ZUdCZ0lLcEhC
a0EwZ2FjRGZkRFEwUERERHovd1MzNVErS0Nob2VIaXhZcytuNC83VC9heWc2SnRTbmYweFJk
ZmRIVjF5VDQxT2pvNk1ERFEzTndjdmNNQ0lNckEwNEUrYUdob0dCMGRQWExreU9qb0tHKzRI
by9INS9QeExpKzFlT21nYUp1eU8xSzZiajQ2T2pvNE9BaFBCMW9Hbmc3MGdkQmgrY2Vkblow
ZWo2ZTl2VDBDVHhjWnQvUlo2WU9HaG9iRGh3K2ZPM2N1bWdjR1FGU0Jwd01BZ0hHQXB3TUFn
SEdBcHdNQWdIR0Fwd01BZ0hHQXB3TUFnSEdBcHdNQWdISDRoNmUzdGJYdEJRQUFvSDhZR0Rv
QUFCaUcvdzlSMWorN1dPODFFUUFBQUFCSlJVNUVya0pnZ2c9PSIgLz48L3A+PHA+Jm5ic3A7
PC9wPjxwPkluIENQVSB1c2FnZSBvZiB0aGUgRG9tVSwgdGhlcmUgaXMgYWxzbyBub3QgbXVj
aCB0byBzZWUsIGV2ZW50dWFsbHkgYSB2ZXJ5IHNsaWdodCBjaGFuZ2Ugb2Y8L3A+PHA+bWl4
OjwvcD48cD4mbmJzcDs8L3A+PHA+PGltZyBhbHQ9IiIgc3JjPSJkYXRhOmltYWdlL3BuZzti
YXNlNjQsaVZCT1J3MEtHZ29BQUFBTlNVaEVVZ0FBQWZFQUFBRnNDQUlBQUFCVHFCZTNBQUFn
QUVsRVFWUjRuTzJkZTNBVVpiNzNtOHhNQ0lObUpnbGhBNFloQVVNdUpNRVFEZ0t2VXJ6V2Uw
VFJYWEVEdXF4b25WcFhUaDFBSXhHdDlXaXhXVUIyQlFRbGtDTUhoUkFJb3VuSkRiTENoa3Np
Y0lwQXdpS1N5QjNrbXBucHllMzU1NjE2LytEOW8zZmJabnBtK3BsT1pxWXYzMC85cW12eXpE
UGQzMzZtK3p1LzlQVDhIdWJ2QUFBQWRFRnpjek1UYlEwQUFBQUdnZWJtNXUzYnQvL0Qwd2tB
QUFBdHMzMzdkbmc2QUFEb0JIZzZBQURvQjNnNkFBRG9CM2c2QUFCb2lXb0o0bWZoNlFDRUJZ
WmhvaTFCRlJwQW1PanY3K2ZkSEo0T1FDUlFnNStxUVFNSUI3Mjl2YWRQbjJaWjlzNmRPelUx
TmVLbjRPa2c3TFMzdC8vcVY3OUtTRWlJalkyZFBIbnlybDI3K0hibW44VEh4Ny80NG92WHIx
OFgycVVyMFp3OXFVR3dHalNBUWFlenM3T2hvYUdscGVYU3BVczFOVFduVDU4V1B3dFBCK0hs
N05tenYvakZMelp1M1BqVFR6OXhISGYwNk5FWFhuaUJmMHB3bkd2WHJ2M21ONy81NVM5LzZk
TXVSblAycEFiQmF0QUFCcDBqUjQ3Y3VYTW4wTFB3ZEJCZVhucnBwYi84NVM5K254STd6czJi
TjYxV3E3VGRiK2RBamNLZlRxY3pPenZiWXJFNEhJN05temZ6alQvODhNT3p6ejQ3ZlBqd29V
T0gvdXUvL3V1MWE5ZjRkcmZiL2R2Zi90WnF0WTRjT1hMVnFsWENTbnA3ZTB0S1NrYU1HREZz
MkxDaW9xSjc5KzdSN3pVdlp0V3FWY25KeVZhcmRlSENoUnpIRVVKbXpKaXhZOGNPb1U5bloy
ZEtTb3I0L0V4UFR6OTE2aFQvK1BQUFArY2ZuRHAxS2owOVBZaWtRTzNDdm56MzNYZWpSNC8r
K09PUFE5b0ZvRVhnNlNDOGpCdzU4dkxseTM2ZkVqdnlyVnUzQnRIVGs1S1NkdS9lelhGY1oy
Zm5hNis5eGpkbVpXWHQzNy9mN1hiZnVYTm44ZUxGTDcvOE10LysxbHR2UGZmY2M5ZXZYNzkr
L2Zxenp6NHJyT1RERHo5ODZxbW5MbHk0Y08vZXZWZGVlZVgzdi84OS9WN3pZbWJQbm4zdDJy
VnIxNjdObmozNzdiZmZKb1RVMXRabVptYjI5Zlh4ZlY1NzdiV1ZLMWVLWC9YR0cyOXMzTGlS
RUhMaHdvV0hIbnFJZCtjTkd6WXNXclFvaUtSQTdmeStWRmRYanhneFl1L2V2U0hwQjZvRjk3
MkFhR0kybTN0NmV2dytKYmpuOWV2WFgzbmxsZWVlZTg2bjNXL25JSTNDbjZtcHFldlhyNzl3
NFVJZ1ZTNlhhOFNJRWZ6ajBhTkgvL0RERC96ajc3Ly9YbGlKdytFNGMrWU0vL2pxMWFzalI0
NE10RGEvTUF6ei9mZmY4NC9QbmozN3lDT1A4SThMQ3d1Ly9QSkxvZEhsY29sZjlmWFhYeGNW
RlJGQ1ZxNWNPV0xFQ1A2ZmpGLy8rdGZmZlBOTkVFbUIyaG1HK2VTVFQwYU5HdFhjM0J5U2VL
QitjTjhMaUE3QjgzU2VoeDkrK0lVWFhyaDY5U3JmSGhNVDA5dmJLKzdaMjlzYkV4UGpkdzEr
LzJ4dWJuNzIyV2NURXhQVDB0SjROeVNFSERwMGFQcjA2VmFybGQvb2tDRkQrSGFUeVNSc3Jx
ZW5SMWlKMld4bVJBajkvZTZDMzZmRXF6V2J6Znpqdlh2M1ptUms5UGIyenA4L2Y5MjZkVDZ2
NnVycUdqTm1EQ0ZrNHNTSkxNcysvdmpqaEpBeFk4YncxaDlJVXFCMmhtSFMwdExlZWVjZHFU
eWdhWERmQzRnYUw3MzAwdHExYS8wK0ZlZ2JQSWZEOFQvLzh6L2lsdVBIanpzY0RtbFBzOWtz
NUxrLy9mU1R6d3I3Ky90Wmx2M0ZMMzdCL3psNjlPaUtpb283ZCs3MDkvZmZ2WHRYNkR4cTFD
aS9lWHBxYXVyRml4Y3BkdEUvNGp6OSsrKy9IejE2dEtCcTRzU0p4Y1hGRG9mRDYvVktYL2pr
azAvdTNMbXpzTENRRUZKWVdMaDM3OTZaTTJjR2x4U29uV0dZQ3hjdWpCczNidlhxMVlwM0JL
Z04zUGNDb3NuWnMyZFRVbEkyYmRwMDgrWk5qdU9hbTV1bDk3MzQ4S2MvL2FtZ29PRElrU01j
eDNFY2Qvanc0VW1USnZsMXBZS0NnZzgrK01EbGNsMjhlSEh1M0xuQ0N1Zk5tM2Y2OUdtdjE4
dXliRkpTRXQrWWtKQ3dkKzllanVOKytPR0hvcUlpb2ZPYmI3NzUvUFBQMzdoeDQ4YU5HK0xy
NlgvODR4OW56NTU5N3R5NW5wNmVreWRQOHBkRTZHRVk1dGxubitVdjB6L3p6RFBGeGNYQ1V4
VVZGUXpEYk5teXhlOExWNjVjT1hyMGFENkZYN3QyN1NPUFBMSnExYXJna2dLMTgvdHk2ZEts
akl5TTB0TFNrUFFEMVlMN1hrQ1VhV3RyKytVdmYybXoyV0pqWXdzTEM4WDNwL3Z0MzkvZnYy
N2R1b2tUSnc0ZE9uVG8wS0VUSjA3ODVKTlAvUFk4ZnZ6NHBFbVR6R2F6dytIWXVIR2pzTUlk
TzNaa1pHU1l6ZWJzN096YTJscSs4YXV2dmtwTFN6T1pUR1BHakZtM2JwM1EyZVZ5L2VZM3Z4
azJiRmh5Y3ZJZi8vaEhpOFhDdC9mMTlaV1dsam9jRG92RmtwT1RVMUZSRWRKZWkrOTdlZVdW
Vnp3ZWovRFVybDI3eG84ZkgraHJoaE1uVHBqTlp2NXUvV3ZYcnBuTlp1Ry9sa0NTQXJVTCsz
amx5cFhNek13UFAvd3dwRjBBV2dTZURzRFB0TGUzangwN050eGJtVE5uenZidDI4TzlGYUJY
Y044TEFESXNXYkxrMXExYlY2NWNtVDE3OXRLbFM4TzNvYjYrdnJLeXNxeXNMT0YyUmdCQ3hj
ZkU0ZWtBK1BMeHh4OG5KU1VOSHo3OHBaZGU2dXJxQ3QrR0dJWnhPQnk0c3hBTWhKcWFtdTd1
YnY1eGQzYzM3bnNCQUFBTjA5emNmT3JVcVo2ZW5wNmVubE9uVHJXMHRJaWZoYWNEQUlDVzhI
ZzhSNDhlZFRxZFRxZXp1YmxaL1BVN2dhY0RBSUNtd2ZWMEFBRFFEL0IwQUFEUU1BYTZsL0Zj
WStPNXhzWm9xd0FBZ01paFcwL3Y0YmdOMDZkdm1ENjloK09pclFVQUFDS0ViajM5Yng5L1hP
cHdsRG9jZjBQaGZ3Q0FVZEdKcDkrNWNHRjFSZ2J2NmFzek11NEVMcHdOQUFDYXh1MTJOemMz
Qy9jeXV0MXU4Yk5xOFhScEhlcUxGeTlPbXpZdE5qWjIyclJwZkIxUmFZdEE1YXV2OG9iT1Ir
V3JyMFo2QndBQUlDSTBOVFdkT1hPbXU3dTd1N3U3dmIyOXFhbEovS3hhUEoxSDdPbno1czBy
S1NueGVEd2xKU1h6NTgvMzIrTERlKys5UndpNWRPa1N6YmE2MjlwaysxQ3VpcVliVk5GM2d5
cjZibEJGMzAyZHFoVEFzcXhRTDZpdnI0OWxXZkd6NnZYMHBLUWtmdUticTFldjhpV3dwUzAr
dlBmZWUvZmJtTmFhLzNPL2paRU56K3A4MlQ2VXE2THBCbFZRRlJWVmhjeFdGYXBTNTFoRldK
VmluOVJxbmg0VEU4Ti9GdlgyOXBwTUpyOHRBcjAvL1hUM3M4K1d2L0VHMlo3NmYwOE9JOXRU
NzdjeHdaZTlXOGJKOXVuNVFyNFA1UmFoQ3FxaW9tcFo2Z29WcWxMbldFVlkxZi9qdUx1ZmZl
WnRiUTNWSjEwdWx3YXVwL09JUFQweE1kRW5LNWUyK01EbjZWY081dDZuK0FnbEZhbXlmU2hY
UmRNTnFxQXFLcXI0UEYxdHF0UTVWcEZXZGY5K09GeFV2WjVlVkZRa1hEM241K0tTdHZqQWV6
b0NnUkNDOTNTRUdrT3BwMnZzdmhmaDdwY2ZmL3h4NnRTcEZvdmw4Y2NmdjNEaGd0OFdINUNu
UXhWVStRVHlkUFdxVXVycFdycWVQa0NRcHlNUVBvRThYYjJoMU5PMWROL0xBRUdlRGxWUTVS
UEkwOVdyQ25tNkxNalRFUWlFWmtLcHAydnB2cGNCZ2p3ZHFxQUtxalNqeWdqM3ZRd1E1T2tJ
QkVJem9kVFREVkUvdmJ1N3U2T2o0M2UvKzkzOU51WUVPK2QrRzNQMTRNVGdTMUtSS3R2bnlz
RmMyVDZVVzRRcXFJSXFxQkl2TDE2ODJOSFJvYUIrZ0krSis2QVRUK2RCbm81QUlEUVRBOGpU
Z3p5clEwOVgzVld6VUZZRlZWQUZWVVpSQlUrWEJYazZBb0hRVE9BN1VsbVFwME1WVkVHVlps
VEIwMlZCbm81QUlEUVRpang5Ly83OXJhMnRWNjllN2UzdDlkdEJ2WjdPc3V5NGNlTmlZMk5u
enB6SmwyTU1NczhSRC9KMHFJSXFxTktNS2tXZWZ2ZnUzWFBuemgwK2ZMaW1wdWJ3NGNQbnpw
MjdlL2V1dUlONlBUMDVPWmxsV1k3aldKWmRzR0FCb1p2bmlHYWdFUWdFSXZveHNHc3ZQVDA5
VjY5ZWJXMXQzYjkvdjdoZHZaNmVsSlRFc3F6WDYyVlpkc1NJRVlSNm5pUFZmUnFIc2lxb2dp
cW9Nb29xbzExUHI2cXFHak5tekxCaHd4WXZYbXcybXduMVBFZjNLZVlmd1JKTExMR003bEx4
UEVmQlVhK25DN0FzNjNBNENPWTVnaXFvZ2lvOXFUSmFuazRJNmUvdlAzMzZkRlpXMXAvKzlD
ZUNlWTRRQ0lTZVlwQThYVFAxWHZnSmoxSlNVdjd6UC8rVHYrU0NlWTZnQ3FxZ1NqK3FqT2Jw
Q2tDZWprQWdOQk9veXlnTDhuU29naXFvMG93cTVPbXlJRTlISUJDYUNYaTZMTWpUb1FxcW9F
b3pxZ3g0M3dzOTRqa3hhR3JWWTRrbGxsaEdkNmw0VGd5MzI0MzVTSkVqUUJWVVFaWEtWQ25O
MDV1YW1zNmNPZFBkM2QzZDNkM2UzdDdVMUNSK1ZvZWVqa0FnRUJvSXBaN09zaXgvZXpjaHBL
K3ZqMlZaOGJNNjlIVFZmUnFIc2lxb2dpcW9Nb29xNU9teUlFOUhJQkNhQ2FXZTduSzVjRDNk
VHhnOVI0QXFxSUtxNktveTJuMHZWVlZWNmVucEpwTXBMUzJ0cXFxS1VNK0pnVUFnRUJvSW8v
Mk9ORDQrM3VsMDhuTmkyR3cyUWowbmh1bytqVU5aRlZSQkZWUVpSZFVBUEoySWZtcWtHVS9Q
emMxMU9wMzhuQmo1K2ZtRWVrNE1CQUtCMEVBbzlYU24wM252M2oyV1plL2V2WHYzN3QzYTJs
cnhzK3IxOUtOSGo4Ykh4ek1NRXg4ZmYvVG9VVUk5SjhhVmc3azBOZWs5Sy9ObCsxemRORTIy
RCtVV29RcXFvQXFxeEV2RmMyS2NPbldxcHFhbXM3TnovLzc5VHFmei9Qbno0bWZWNituang0
OFhycjA4K3VpamhIcE9EQVFDZ2RCQUdPMDdVcnZkTGx4N1NVaElJTlJ6WXFqdXFsa29xNElx
cUlJcW82Z3kybmVrbFpXVkRvZkRaREtOSFR0MjkrN2RoSHBPREFRQ2dkQkFHQzFQVndEeWRL
aUNLcWpTakNwNHVpekkweEVJaEdZQ25pNEw4blNvZ2lxbzBvd3FlTG9zeU5NUkNJUm1RcW1u
bzM2Ni96QjZqZ0JWVUFWVjBWV0Z1b3hCd0R4SFdHS0pwYmFXaXVjNVF2MzBhSDhhcXpOSGdD
cW9ncXJvcWtLZUxndXVweU1RQ00wRTZxZkxnandkcXFBS3FqU2pDdmU5eUlJOEhZRkFhQ2FN
Vmh0QUFjalRvUXFxb0VvenFveFdQNTBSa1ppWVNERFBFUUtCMEZNWXpkTUZEaDgrL082Nzd4
TE1jd1JWVUFWVmVsSmxXRStmUFh2MjVjdVhDZVk1UWlBUWVvcEIrbzVVWTU3ZTFOUzBZTUVD
L2pIbU9ZSXFxSUlxM2FoU1BNK1JEeHJ6OUZtelpoMC9mcHgvakhtT0VBaUVmc0tBOTcwY09I
RGdpU2VlRVA3RVBFZFFCVlZRcFI5VkJyejI4dVNUVDM3MTFWZkNuNWpuQ0lGQTZDY002T21o
Z2p3ZHFxQUtxalNqQ3I4amxRVjVPZ0tCMEV3WThIcDZxQ0JQaHlxb2dpck5xRUtlTGd2eWRB
UUNvWmxBbmg0RThad1lKOWc1OXlscTBwT0tWTmsrVnc3bTB0UzJwOWtpVkVFVlZFR1ZlS2w0
VGd4Q2lOZnJQWERnUUUxTnpmWHIxMzJlMG9tbjh5QlBSeUFRbWdtbGVUcHY2R2ZPbkxsMTYx
WmRYZDJkTzNmRXorclEwMVYzMVN5VVZVRVZWRUdWVVZRcDlmUnZ2LzFXc092TGx5ODNORFNJ
bjlXaHB5TVFDSVFHUXFtbiszajErZlBueFgvcTBOTlY5MmtjeXFxZ0NxcWd5aWlxOEIycExN
alRFUWlFWnNKb3RYYjcrdnJlZi8vOVVhTkdEUmt5aEdFWVFqMG5odW8ralVOWkZWUkJGVlFa
UlpYUlBIM0ZpaFVUSmt4b2JXM3Q3Ky9uV3lqbnhFQWdFQWdOaE5FODNlRndzQ3dyYnFHY0Uw
TjFuOGFockFxcW9BcXFqS0xLYUw4ak5abE1TNVlzR1Rac21NUGgyTHQzTDZHZUUrTStSYTE2
TExIRUVzdm9MaFhQaWFIVjcwaVRrcEpZbHVVNGptWFpFU05HRU9vNU1WVDNhYXpPSEFHcW9B
cXFvcXRxWUhsNmYzKy96MFVZSHZWNit2ejU4MW1XOVhxOUxNc21KeWNUNmpreEVBZ0VRZ014
QUUvdjdlMDlmZm8weTdKMzd0eXBxYWtSUDZWZVQ3OTA2ZElUVHp4aHNWalMwOVA1Qyt1VWMy
S283dE00bEZWQkZWUkJsVkZVS2ZYMHpzN09ob2FHbHBhV1M1Y3UxZFRVbkQ1OVd2eXNlajFk
QWNqVEVRaUVaa0twcHg4NWNzU254b3NZSFhxNjZqNk5RMWtWVkVFVlZCbEZsZEh1ZTFFQThu
UUVBcUdaZ0tmTGdqd2RxcUFLcWpTakNwNHVDL0owQkFLaG1ZQ25Cd0h6SEVFVlZFR1Z0bFFO
Wko2aklPakUwM21RcHlNUUNNMEU4blJaY0QwZHFxQUtxalNqQ3A0dUMvSjBCQUtobVlpaXAz
LysrZWNKQ1FrSkNRbi8vZC8vSFE0Umd3WHlkS2lDS3FqU2pLb0llenJIY2NKanU5M2UwdExT
MHRLU2tKQVFEaEdEQmZKMEJBS2htWWl3cDQ4Wk02YTh2THkzdDVkRXlkTVpFWHdMNWptQ0tx
aUNLdjJvaXJDbk56VTF6Wmd4SXlNalkrZk9uVnUyYkxIYjdYYTcvZlBQUHcrSENMOElWaTZB
ZVk0UUNJUitJaXJYMDUxTzUyT1BQWmFmbis4ejVWQUVZQmptNFljZnRscXRzMmZQN3Vqb0lK
am5DS3FnQ3FyMHBDckNuaTU4TDdwMTY5YWRPM2RtWkdSTW16YnR3SUVENFJBUmhHdlhyaFVY
RjArZE9wVmduaU1zc2NSU1IwdkY4eHdGSjZDbkp5UWtORGMzQzlmUWUzdDd0MnpaTW1iTW1N
SGRQQTF1dDl0aXNSRE1jd1JWVUFWVmVsSVY0VHpkNy9laTRwdGhJc1B0MjdmZmUrKzl3c0pD
Z25tT0VBaUVuaUxDbmw1ZVhoNzU3MFhGOEhlOHhNWEZ6Wm8xNit6WnN3VHpIRUVWVkVHVm5s
VGhkNlN5SUU5SElCQ2FDWGk2TE1qVG9RcXFvRW96cXVEcHNpQlBSeUFRbWdsNHVpekkwNkVL
cXFCS002cmc2VUVRejRsQlU2c2VTeXl4eERLNlM4eUpJUS95ZEtpQ0txalNqQ3JrNmJMZ2Vq
b0NnZEJNd05ObFFaNE9WVkFGVlpwUkJVK1hCWGs2QW9IUVRNRFRaVUdlRGxWUUJWV2FVV1ZN
VDMvLy9mZERuUk1EZ1VBZ05CQUc5UFNXbHBhVWxCVEIweW5ueEZEZHAzRW9xNElxcUlJcW82
Z3ltcWQ3UEo2SkV5YzJOallLbms0NUp3WUNnVUJvSUl6bTZZc1hMLzd6bi85TVJKUFlVYzZK
Y2VWZ0xrMU5lcy9LZk5rK1Z6ZE5rKzFEdVVXb2dpcW9naXJ4TXRKellrU2RJVU9HK0V3elRU
a25CZ0tCUUdnZ2pKYW5Dd2g1T3VXY0dLcTdhaGJLcXFBS3FxREtLS3JnNlpSellpQVFDSVFH
d3JDZVRnL3lkS2lDS3FqU2pDcDR1aXpJMHhFSWhHWUNuaTRMOG5Tb2dpcW8wb3dxZUxvc3lO
TVJDSVJtQXA0dUMvSjBxSUlxcU5LTUtuaDZFRERQRVpaWVlxbXRKZVk1a2dkNU9sUkJGVlJw
UmhYeWRGbHdQUjJCUUdnbTRPbXlJRStIS3FpQ0tzMm9ncWZMZ2p3ZGdVQm9KdURwc2lCUGh5
cW9naXJOcURLYXAxZFVWR1JrWkZnc2xyeTh2SWFHQm9KNWpoQUloSjdDYUo2K1lNR0NqbzRP
dDl1OWMrZk94TVJFZ25tT29BcXFvRXBQcW96bTZUd2N4KzNldlRzM041ZGduaU1FQXFHbk1L
Q244N05oMk8zMkkwZU9FTXh6QkZWUUJWVTZVbVc0ZVk1NCtHc3Y0OGFOSTVqbkNJRkE2Q21N
bHFjdlhyejQrdlhyYnJkNzE2NWRJMGVPSkpqbkNLcWdDcXIwcE1wb25sNWVYajVxMUtqWTJO
akpreWYvOWE5L0paam5DSUZBNkNtTTV1a0tRSjRPVlZBRlZacFJCVStYQlhrNkFvSFFUTURU
WlVHZURsVlFCVldhVVFWUGx3VjVPZ0tCMEV6QTA0TWduaFBqQkR2blBrVk5lbEtSS3R2bnlz
RmNtdHIyTkZ1RUtxaUNLcWdTTHpFbmhqekkweEVJaEdZQ2Vib3N1SjRPVlZBRlZacFJCVStY
QlhrNkFvSFFUTURUWlVHZURsVlFCVldhVVFWUGx3VjVPZ0tCMEV3WXpkTXJLeXV6c3JJVXpJ
bWh1ay9qVUZZRlZWQUZWVVpSWlRSUGYvSEZGMXRiV3owZXorYk5tL2txakpSellpQVFDSVFH
d21pZUx0RFIwZUZ3T0FqMW5CaXErelFPWlZWUUJWVlFaUlJWeHZUMEsxZXVGQlFVZlAzMTE0
UjZUb3o3RkxYcXNjUVNTeXlqdXpUaW5Cak56YzBPaDJQYnRtMzhuNVJ6WXFqdTAxaWRPUUpV
UVJWVVJWZVYwZkwwc3JLeTVPVGt1cm82b1lWeVRnd0VBb0hRUUJqTjA1a0g2ZXJxb3B3VFEz
V2Z4cUdzQ3FxZ0NxcU1vc3BvbnE0QTVPa0lCRUl6QVUrWEJYazZWRUVWVkdsR0ZUeGRGdVRw
Q0FSQ013RlBsd1Y1T2xSQkZWUnBSaFU4WFJiazZRZ0VRak1CVHc4QzVqbUNLcWlDS20ycHdq
eEg4aUJQUnlBUW1nbms2YkxnZWpwVVFSVlVhVVlWUEYwVzVPa0lCRUl6QVUrWEJYazZWRUVW
VkdsR0ZUeGRGdVRwQ0FSQ00yRTBUeGNxdlFndG1PY0lxcUFLcXZTanltaWV6aVAyZE14emhF
QWc5QlB3ZE14ekJGVlFCVlg2VVFWUHh6eEhXR0tKcFc2V1Jwem5pRHpvNlpqbkNLcWdDcXIw
b3dwNU91WTVRaUFRK2dtamViclBQRWVFRU14ekJGVlFCVlg2VVdVMFQxY0E4blFFQXFHWmdL
ZkxnandkcXFBS3FqU2pDcDR1Qy9KMEJBS2htWUNueTRJOEhhcWdDcW8wb3dxZUhnVHhuQmcw
dGVxeHhOSVF5OVVUNzVkR1c0UEtsOUViSDh5SklRL3lkS2lDcWdlaWxHRVc3Vk9kS2pXTkZi
Tm9uekJLa1ZhRlBGMFdYRTlISU1UQkxOckhlOWI5MHVpTFVXZndReVQyOU1nRlBGMFdtVHo5
d1NOYkRUbUNOS0JLTTZvQ3VPUmdxbG85MExGaUZ1MWoyaGhtMFQ1U2pIY3dRSjcrejRpQ0tu
aTZMTUh5OUZMa0xJakJqSDhjUytIZXhBRFh3RWUwOGxBdGhOVFRJeGZ3ZEZtQzVPbi9TRmhF
eDdjYWNnUnBRSlZXVkFVeXlrRlVsVnV5ZDBDckt2M1pzSDVWa1NxYnpTai83MEd5WmsyOGd6
NURKT3dDOHZUSVFUVW5oczlSVy9xUFlOb2VDS0ZkL3lFWkNnMkV6enZZRnVEWlFWbS9zaWdW
SlhlRHVGckpKbVJXRzNTN1ArY3hnNXF0KzY2a1ZQSXZTemhHSXp6eHdCRDUvY2ZMNzc0TTFu
SCtUMCt2Zk8yMTJ6LytPRmcrcVNWUHA1b1RvNVM1c2pwWEdEWGZ3MXIwL3BIaTFQdWxvbTlJ
U24vK0JseUkzSks5NGovRm5jVTlBM1dqWE5YUGY3WXh2M3J0VStrbUtGWDUzV0x3bzhwM3JF
VGJFaHJ2bHpMOFdQMTg5b3BlSXZTL3NqcVhYaFcvc3o3cjhhdktSNTY0cDZBcVVKOUFZeVU5
Uy8rUlQ0VTBWdjlNRG53MktsVVZmRldCZ21samNnL21CczgvK0IwTXNnWnhuaTZiemRDb3Vs
L0s1QjU4b0p0NEtHUlVTVDRWb3A2blM1MkI4aDBNZUZ3OWVLcnlRK3IzdEdJVzdSTTh2ZFRo
V0QxaHd0OCsvcmpINHhtNFQyckowMm5teFBEdjRBaUVUNGl2eGJVRi91eEhoUFV0K09lbis4
OS9pdCtVSUs5cUV4bWwzNWZUdktIUmZ0UEZuczdIeHYvMXY3N2Z2MytBUHFrbFQvYzdKMFo3
ZS9zNzc3eFRzblRwVzg4Ly83OW56SGo3bFZmKzdkLys3ZTFYWG5ubm5YZUNMOTk4K21uWlBy
OS80UVhaUHBSYmhDcW9naXFvRWk5NTExcjJ1OS85N09relpueS9iOThBZlZKTG5rNHpKd1lo
NVB6NTh6UnI4eHc4S051SGNsVTAzYUNLdmh0VTBYZURLdnB1NmxSRi9ubnQ1ZUJmL21LNGF5
ODBjMklRUXJ4ZUw4M2E3bTdlTE51SGNsVTAzYUNLdmh0VTBYZURLdnB1NmxSRkNLbDg5ZFhi
blowMFBXblFrcWZUeklsQnY3YmU2OWNIVDlxZ0FWWDBRQlU5VUVXUE9sWFJveVZQbDZWMXNH
ZHJCUUFBYmFFclR3Y0FBSU1EVDFkSVpXVmxWbGFXeFdMSnk4dHJhR2dnb2dsVVZhVksycUlH
VlJVVkZSa1pHV3BUeGZQKysrOUg4VTBNY2x5cFNsVmZYOS83Nzc4L2F0U29JVU9HUkV0WThM
RktURXhVaWFxcXFxcjA5SFNUeVpTV2xsWlZWUlZ1QWZCMGhiejQ0b3V0cmEwZWoyZno1czNp
bTNDaTYrbFNWWUYwUmxmVmdnVUxPam82M0c3M3pwMDdvM1h1K1IyWmxwYVdsSlNVS0w2SlVs
WFJQYUo0cEtwV3JGZ3hZY0tFMXRiVy92NSs5YWdTT0h6NDhMdnZ2cXNTVmZIeDhVNm5rK000
bG1WdE5sdTRCY0RUQjBwSFI0ZkQ0UkQrVk1NWlNDU3EvTFpFSGg4TkhNZnQzcjA3TnpjM2lw
S0lTSlhINDVrNGNXSmpZNk1hM2tSQkZjTXdEei84c05WcW5UMTdka2RIaDBwVU9Sd09sbVdq
SzBaQWVtelBuajM3OHVYTDBkTERJNmpLemMxMU9wMWVyNWRsMmZ6OC9IQnZGNTQrSUs1Y3VW
SlFVUEQxMTE4TExXcXdBNmtxYVV2VVZmSC9JTnZ0OWlOSGpxaEUxZUxGaS8vODV6OFRGYnlK
MHZmcjJyVnJ4Y1hGVTZkT1ZZa3FrOG0wWk1tU1ljT0dPUnlPdlh2M3FrUVZUMU5UMDRJRkM2
SW9pVHlvNnVqUm8vSHg4UXpEeE1mSEh6MTZOTnliaHFjcnA3bTUyZUZ3Yk51MlRkd1lkVHVR
cXZLck0rcXFDQ0g4dFpkeDQ4YXBSQlYvYVRqcUY2OER2Vjl1dDl0aXNVUkZFcEdvU2twS1ls
bVd2NTR3WXNRSWxhamltVFZyMXZIang2TWxpVWhValI4L1hyajI4dWlqajRaNzYvQjBoWlNW
bFNVbko5ZlYxZm0wUjlmVHBhb0M2WXl1cXNXTEYxKy9mdDN0ZHUvYXRXdmt5SkVxVVNVUXhU
Y3hrS3JidDIrLzk5NTdoWVdGMFJEbFI5WDgrZk5abHVXdkp5UW5KNnRFRlNIa3dJRURUenp4
UkZUMDhFaFYyZTEyNGRwTFFrSkN1QVhBMHhYQ1BFaFhWNWRQaXpwVmRYVjFxVUZWZVhuNXFG
R2pZbU5qSjArZS9OZS8valh5a3Z5cUVqOFZGVWwrVmZFUDR1TGlaczJhZGZic1daV291blRw
MGhOUFBHR3hXTkxUMDZOMVlkM3ZPL2prazA5KzlkVlhVZEVUU0ZWbFphWEQ0VENaVEdQSGp0
MjllM2U0QmNEVEFRQkFQOERUQVFCQVA4RFRBUUJBUDhEVEFRQkFQOERUQVFCQVA4RFRBUUJB
UDhEVEFRQkFQOERUZ1VHSjRrM29BSVFQZUxxVzhIcTlTNWN1SFRGaXhFTVBQYlJ5NWNwb3k5
RUdETU9zV2JPR0VQTFJSeC9CeHlscGJXMWxHQWFUekZDaXFtTU1ucTRsbGkxYjl2enp6MSsr
ZlBuMjdkdHZ2dmxtdE9Wb0E0WmhNak16Ky92N0oweVlFUFh6VFN1c1hyMDZKaVptOWVyVjBS
YWlEVlIxak1IVHRjVG8wYU45WmlJWEgwRENZNFpobGkxYlpyVmFoY0tlVVQvT29nakRNTk9u
VDEreFlzV01HVFBFUStRemRHdlhyazFJU0xEYjdadi9PY1d3a1FkdDFxeFpyNzMyMnF4WnMv
Zy84L1B6K2VrZDZ1dnJKMDJhUkFocGFXbkp6TXlNaTRzcktTa1JqMnEwQkVjWDZUSEdIMkJt
czFtWUdlT05OOTc0N1c5L1N3aFpzR0RCb2tXTGhCY091aGg0dXBZd21VeTl2YjNpbGtDZXZt
Yk5HcGZMOWZycnIwZFVueXBoR0diNzl1MHhNVEU3ZHV6d08xejg0dzBiTnJqZDdwcWFtbWpO
SEtJZVhDN1g4T0hETDErK1BIejRjSmZMUlFoWnQyN2QvUG56Q1NIejVzMWJ2MzQ5SVNRM04v
ZlRUejkxdVZ5Yk4yODJySlVMQkRyR2VudDdtNXFhVWxKU0NDRTlQVDFQUGZYVXYvLzd2ei8x
MUZNOVBUM2hFd05QMXhKQjh2U2VuaDZ4cDNkM2QwZGFuRm9KNHVQaXg4SnBCb2VxcnE0V1Ns
QlZWMWNUUW03ZXZHbXoyYzZmUDIrejJXN2R1a1VJTVp2TmJyZWJFT0oydXpGaTB1TnF3NFlO
RG9jakppYUdZWmdoUTRid1Q3VzB0REFNMDlMU0VsWXg4SFF0VVZ4Yy9Qenp6MSs1Y3VYT25U
dkZ4Y1dFa0tTa3BMcTZPby9IczNIalJ2d0w3QmRLVC9mNzJKZ3NXclNJL3daKzVjcVZ3bFdD
b3FLaXh4NTdiTjY4ZWZ5ZkV5ZE8zTFJwazl2dC9xLy8raStNbVBUNGlZdUxxNm1wY2J2ZExN
dnlMVzYzT3k4dmIvYnMyWGw1ZVI2UEozeGk0T2xhZ3VPNC8vaVAvMGhLU2hMdWV5a3JLN1Ba
YkFrSkNldlhydy9pNlVZKzY2VG5tMDgxVkw5OWlJRUhMVDA5L2VUSms0U1FreWRQcHFlbjg0
MzE5ZlVNdzlUWDEvTi9OamMzWjJSa3hNWEZ2ZjMyMnpFeE1YeWpZVWRNZXZ4ODhNRUhOcHZO
WnJPdFdyV0tiMW00Y09ITEw3OU1DSG5wcFpkZWZmVlY2UXNIQzNnNkFFQWhmWDE5WDMzMTFZ
UUpFNkl0QlB3TVBCMEFvQVQrU25GNmVucTBaalVCZm9HbkF3Q0Fmb0NuQXdDQWZvQ25Bd0NB
ZmdqTjA1a0FES0lndzM1MVBsaDBkblpPblRvMU5qWjI2dFNwUC83NG85OCtWVlZWNmVucEpw
TXBQVDE5ejU0OWhCQ080NVlzV1pLY25Eem9iNmdtb0JtMGJkdTJqUnMzem1LeFRKbzBxYkd4
a1R4NE9pUW1Ka1pXY3BSUmRwaEp4OUJvbEphV0JqbS9wSTVhVlZXVm5aMGRHeHRiVUZCdzRN
QUJtazJFN3VsdGtvQ25xNG01YytlV2xKUjRQSjZTa3BLaW9pSy9mV3cyVzIxdExjZHhUcWZU
WnJNUlFvcUxpL1B6ODl2YTJ2cjcrNFpJZDJ3QUFCa2ZTVVJCVkNNcVZ4M1FETnJjdVhOUG5q
enA4WGkyYmR2bTgxdlRSWXNXTFYrK1BBSTYxWU95d3l6SUdCcUJFeWRPOEdsVDhHN2lEa1ZG
UlcxdGJSekg3ZG16WitUSWtUUmJDWmVucjF1M3p1RndtRXdtNFdObnlwUXAvTTJ0RlJVVjA2
Wk44OXRIbXZ1M3Q3Yy8vdmpqRm90bC9QangvTWNVd3pDVEowK2VOMjllV2xxYThBc0lJSkNZ
bUhqMTZsVkN5TldyVndPZE5ubDVlZlgxOVY2dnQ2NnVqaS9mTVdyVXFHKy8vVGFTT2xVRnph
QUpYTGh3d1dLeENML1V2WDM3dHQxdXYzVHBVcmhGcWdwbGg1bUF6eGdhQVk3amNuSnl2dmpp
aTVBOG5jZnRkbGRXVmxMZU14b3VUeDgrZkhocGFXbGJXNXZYNitWYmR1ell3VnR3UVVIQjEx
OS83YmVQZEg4S0NncSsvUEpManVOcWEydkhqeC9QZHhBS2dRNGZQcHhtSncxRlRFeE1YMS9m
OU9uVGUzdDdUU2FUM3o3TnpjMTJ1NTFoR0x2ZHp2OVMyV1F5bFpTVVdLM1cxTlRVWGJ0MlJW
Wnk5S0VaTko0Yk4yNFVGaGFLaTJLdVdyV0sveTJKb1ZCMm1QRkl4OUFJdlBYV1c3Lys5YThK
eGFVSW53N0N4YjFqeDQ3UmJDaGNudjdOTjk4ODg4d3o0OGVQZitpaGgvN3doejhRUW5wNmVz
YU5HN2RyMXk2K0tLWGZQdEw5TVp2TlF1Yk9sMDBRLy9BUEYycWtKQ1ltWHJ0MmpRUk5vREl5
TXB4T0o4ZHhMTXRtWm1ZU1F1eDJPOHV5WHErM29hSEJhSmVHQ2QyZ0VVS09IVHVXbHBaV1Vs
TFMxOWZIdC9UMDlLU21wb2E3Z29jS1VYYVlFWDlqYUJENDJpODAzMEZLbjNXNVhEdDI3TWpK
eWFIWlVIaXZwL2YxOVRVMk5scXRWdjdQbFN0WFdxMVdvWmFwM3o2eHNiRWRIUjNDczRXRmhk
WFYxZUx5Q1BEMDRMend3Z3ZMbHkvbk9HNzU4dVY4WGlBbFBqN2U2WFI2dmQ3YTJscitRdWVj
T1hNRVR6ZmdoVTZhUVNzdkx5OHNMRHgwNkpDNFViaVFhRFNVSFdaK3g5Qm9oSlNuTDF5NHNM
T3prK080eXNyS2hJUUVtdldIeTlQNXo2S1ltSml4WThkKyt1bW5mT05QUC8yVW1KaklsM01M
MUdmcDBxVnhjWEhDT3MrY09UTno1a3krUmVybThIUXBIUjBkVTZaTXNWZ3MvL0l2LzlMWjJj
azMrZ3hVUlVVRlh6UnU3Tml4bFpXVmhKQno1ODVObVRMRmJEWTdISTZxcXFvbzZJNHFOSVBH
UEVoWFZ4Y2haTXFVS1FhOFZFV1VIbVoreDlCb2lFY3ArREZHQ05tNmRXdGFXcHJaYk03SnlY
RTZuVFRyajl5OWpIMTlmWjk4OHNuU3BVdHBPZ01BQUZCQTVINXp4REJNZm40Ky8xMDVBQUNB
Y0lEZmtRSUFnSDZBcHdNQWdINkFwd01BZ0g1UVhiMFhNRUJvQ25GSTN6aURGK0tnR1RScEh5
TVh5VkYybUJsNXhPamRVbHdUSmlMMVhoYnQ4dzJEdlRjcWg2WVFCNC80alRONElRN0tlaTgr
Zll4Y0pFZlpZV2JrRWVPUmRVdWZtakFScWZkQzUrblNlekNsMVYya3RWejR6c3VXTGJOYXJm
bjUrVFE3QUh5Z0wxM2k5NDB6WUNFT1FqZG8wajVHTHBLajdEQXo4b2p4QlBmMFFEVmh3bHp2
UmFtblM2dTdTR3U1OEozWHJGbmpjcmxlZi8xMW1oMEFQdENYTHBHK2NjWXN4RUhvQmszYXg4
aEZjcFFkWmtZZU1aN2dudTYzSmd5ZkJJZXoza3VJbnQ3VDA4TS9sbFoza2RaeTRWOW90Q1J4
Y0tFc1hVSWtoNWRoQzNFUXVrR1Q5akZ5a1J4bGg1bVJSNHdudUtjSHFna1Q1bm92ZEo2ZWxK
UlVWMWZuOFhnMmJ0d283aUN1N2lLdDVVTHdjLzhCUTFPSWcwYzgxQVl2eEVFemFOSStSaTZT
byt3d00vS0k4VkQ2bTlBdEl2VmU2RHk5ckt6TVpyTWxKQ1NzWDcrZUVkVkdGMWQza2RaeW9k
OW5FQWdGcFV1a0xVWXJ4RUV6YU5JK1JpNlNvK3d3TS9LSVNVZURCTFk3b1YzVjlWNEFBQUNF
Ry96bUNBQUE5QU04SFFBQTlBTThIUUFBOUVPa1BSMFgzd0VBSUh6Z08xSzlFVkloRG9aaCtO
dUVhVjZsWTVSVkx6SHlvSVY2bVBFdFZWVlY2ZW5wSnBNcFBUMTl6NTQ5RWRRYmZXamNVdHBI
ZXFyS0VyS24zeS8xRFhpNnFxQXZ4RUVJV2JSbzBmTGx5ME45bGY1UVhDVEhzSU5Hcys5U1o3
RFpiTFcxdFJ6SE9aMU9mb1pTbzBIamxuNzdDS2VxTE9IeWRJWmgxcTVkbTVDUVlMZmJoVW1s
ZlQ2Q2poOC9QbW5TSkw0Q0ROL2l0d0lNQ0FuNlFoeTNiOSsyMisyWExsMEs2Vlc2UkZuMUVp
TVBHczIrTXd4anM5bXNWdXZUVHovTlR4eWZsNWRYWDEvdjlYcnI2dW9tVFpvVVNjRXFRWm1u
aTA5VldjTG82UnMyYkhDNzNUVTFOZUszWE53NU56ZDMvZnIxSE1jSkxYNHJ3SUNRb0MvRXNX
clZxcGRmZmpuVVYra1NaZFZMakR4bzlQdCsvZnIxNHVMaXFWT25Fa0thbTV2dGRqdkRNSGE3
dmFXbEpWSmlWWVF5VHhlZnFyS0UwZE43ZW5xa0VzV1B6V2F6eStVU3Y4cHZCUmdRRXBTRk9I
cDZlbEpUVTRYemlyNThoeTVSVnIzRXlJTVcwcjU3UEI2THhVSUl5Y2pJY0RxZEhNZXhMSnVa
bVJrQm5XcERnYWY3bktxeWhOSFRaUjlQbkRoeC9mcjFRcGxHRXFBQ0RBZ0p5a0ljRlJVVjA2
Wk5DL1ZWZWtWWjlSSWpEeHI5dnQrN2QyL0ZpaFdGaFlXRWtQajRlS2ZUNmZWNmEydHJjVDJk
c28vUHFTcEw1RHo5d1R0bEdFTElkOTk5bDVlWHg1Y2k0M3Y2clFBRFFvS21FQWNoWk1xVUtl
SmlwMzVmWlJ5VVZTOHg4cURSajlqUW9VTm56cHg1OXV4WlFraEZSWVhENGVDTFBsVldWa1pC
ZC9TUUhqK0U0aGdqa2xOVkZ0ekxDQUFBK2dHL0l3VUFBUDBBVHdjQUFQMEFUd2NBQVAwUVhr
OFBkS2tkMStJQkFDQWNST2M3MGtCZis0TGdTQWU4cXFySzRYRHd0eCtjTzNmT2J4OHBWVlZW
MmRuWnNiR3hCUVVGL085MXhlK203aWVLNURodXlaSWx5Y25Kd2tEUjFDR1JIdkI2cmZmaTl6
RHpHWitCSDJiaDNvdElRbk5pYnR1MmJkeTRjUmFMWmRLa1NZMk5qWDdYbyt6STlDSDBleG5i
ZkFPZUhtSEVnNWFZbU5qUTBPRDFlbG1XZmU2NTUvejJrVkpVVk5UVzFzWngzSjQ5ZTBhT0hD
bCtpcjZzaEhZcExpN096ODl2YTJ2cjcrL25XMmpxa0VpSFZOLzFYc1Q3RzJoOFFqM005SDIr
Qno4eDU4NmRlL0xrU1kvSHMyM2J0a0MvMGxKMlpQb1FSay8zK2VCcWJtN096TXlNaTRzckxp
NE81T21vOTBLRHo2R3piOTgrL3RBUlQwRkxjL0s0M2U3S3lzb0pFeVlJTFNHVmxkQXVvMGFO
K3ZiYmI4VXROSFZJR0VuMUVuM1hleEVmUW9IR0o5VERURHFHZW9MbXhDU0VYTGh3d1dLeGRI
ZDNTOWVnN01qMElieDV1dmlwN096czh2Snl0OXY5MldlZkJmSjAxSHVoUVR4b0ZSVVZqenp5
eUxCaHc5NSsrMjF4MlEzWmswMjR6SExzMkRHaE1hU3lFdHJGWkRLVmxKUllyZGJVMUZUKzF4
ejBkVWpFMVV2MFhlL0ZKeUh6T3o3S0RqUHhHT29KbWhQenhvMGJoWVdGYjc3NXB0ODFET1RJ
RklpY3A1dk5acmZiVFFoeHVWeUJQQjMxWG1qd08rQ05qWTJqUjQ4TzNzY0hsOHUxWThlT25K
d2MvczlReTBwb0Y3dmR6cktzMSt0dGFHamd2endJcVE2SlVMMUUzL1ZleElkUW9QRlJjSmp4
Q0dPb0oyUlB6R1BIanFXbHBaV1VsUFQxOWZsZHd3Q1BUSjdJZVhwT1RnNmZwNWVWbFFudEtT
a3A0Zzl3MUh1aHdXZkErL3Y3Mjl2YmMzTnppNHVMQS9YeFllSENoWjJkblJ6SFZWWldDdjhZ
aGxwV1Fydk1tVE5IT0hONEw2YXZReUt1WHFMdmVpL2lReWpRK0NnNHpNaURZNmduZ3ArWTVl
WGxoWVdGaHc0ZENyS0dnUnlaQXVIeWRPWkJDQ0dIRHgvT3lNaUlpNHRidG15WjhKSk5telpa
clZiaFQ5UjdDWTUwVlBrSHljbkppeGN2NXFzV1Mvc1F5ZEcyZGV2V3RMUTBzOW1jazVQamRE
cjV4bERMU21pWGMrZk9UWmt5eFd3Mk94eU9xcW9xRXFBT2ljK2c4ZU1wcmw2aTEzb3Ywa05J
T2o3S0RqUHBHT29EQlNkbVYxY1hrWXdZNVpFWkhOUjdBUUFBL1lEZmtRSUFnSDZBcHdNQWdI
NkFwd01BZ0g2SVRyMlhhSzBIQUFEMGpTYS9JNFhGQjRHbUNJbTBqOEcvN2xZMmFIcXQ5MElE
emI0cnEzbWlENElVWWdweWxnWHFVRnBhU245dWh1enBoY3hXbjRDbnF3cWFJaVNCK2hoMllK
VU5tcjdydlFTSFp0K1YxVHpSQjlKOXB6KzVmSHFlT0hHQ3IrcEYrZkl3ZXJyUEI4NmhRNGV5
c3JMTVpuTldWaFovNDczRDRUaC8vandoNUljZmZuQTRITUpMekdaelhsNWVRME9EMy9YZ0hz
cmcwQlFoQ2RUSHNFT3FiTkQwWGU4bE9KUWpwcURtaVQ2UTdqdERYZXRHZkJweUhKZVRrL1BG
RjErb3d0Tjl4R1ZtWm03WnNvWC9IV2xXVmhZaFpPSENoWnMyYldJWVpzdVdMYSsrK3FyUXM3
ZTN0Nm1wS1NVbHhlOTZwSDhDTVRSRlNBTDFNZXpBS2hzMGZkZDdDUTdOdml1cmVhSVBBdTA3
VGEwYjhXbjQxbHR2OFQ5UlZxT25tMHdtb2Q2TDJXd21oR3pidHUyWlo1NlpQSG55bkRsenZ2
amlDMExJaGcwYitCOU5NUS9XZTRHbjAwTlRoQ1JRSDhNT3JMSkIwM2U5bCtDRXRPOGgxVHpS
R1Q2Rm1BaEZyUnZ4YWNpYllVaFhKcUtacDErOGVISFlzR0VmZmZTUjFXcmw2N3ZHeGNYVjFO
UzQzVzZXWlgydXQ0aFhHeHNicTc5Q25ZTUZUUkdTUUgwTTYrbktCazNmOVY2Q1E3bnZDbXFl
NkFhL2haaG9hdDM0UFEyam42ZExiNHhwYW1yS3pNdzBtVXlabVpuQ201cVJrZkhqano4S0pi
dy8rT0FEbTgxbXM5bFdyVnJGaU1vbStIeE1MVjI2bEs4SlE3bVRoc0p2RVJLZnNaTDI4VHZP
eGtIWm9PbTEzZ3NOTkNQR0gwdXlOVTkwU2FCOTk2bDE0M2ZFL0o2R1lmUjB2MUJ1REFBQVFG
akI3MGdCQUVBL3dOTUJBRUEvd05NQkFFQS9hS1BlQ3dBQUFCcndIYW5lUU9rU0JXRFFRZ1Vq
RmlvUks4UVVzcWR2WmJiNkJEeGRWYUIwaVFJd2FLR0NFUXVWaUJWaUNxT24rNzNGY3RteVpW
YXJOVDgvbnhCeStQRGhDUk1tK014UUNnWUlTcGNvQUlNV0toaXhVSWxZSWFidzV1bFNUMSt6
Wm8zTDVYcjk5ZGNKSWRuWjJlWGw1VzYzKzdQUFBvT25EeFlvWGFJQURGcW9ZTVJDSldLRm1D
THQ2ZUpLYkdheldhZ0FBMDhmTEZDNlJBRVl0RkRCaUlWS3hBb3hSZHJUeFg5bVpXWHhlWHBa
V1JrOGZiQkE2UklGWU5CQ0JTTVdLaEVyeEJRdVQvZDdZNHhQejZhbXBrY2ZmVFF1THE2a3BB
U2VQbGlnZElrQ01HaWhnaEVMbFlnVllsTEx2WXp3ZEFBQUdEaHErUjBwUEIwQUFBYU9Xandk
QUFEQXdJR25Bd0NBZm9peXAyL2F0R240OE9HeUYxNXdaUVlBQUdpSThuZWtLU2twSjA2YzhO
bUU0clVCUWxjZ29xcXFLanM3T3pZMnRxQ2c0TUNCQTN5THcrSGd2M0EvZCs1Y3BNU3FCZm82
SktXbHBlTDd1QWJ4TmdGdFFiUGpmdTk4RTBoTVRJeUlVclhBY2R5U0pVdVNrNU9EakZ0VlZW
VjZlcnJKWkVwUFQ5K3padzlSZEdLRzdPbHQ5MzFqSUFlMGVDSnBZUk9LMXdZRWdnOWpVVkZS
VzFzYngzRjc5dXdaT1hJa0lTUXhNYkdob2NIcjliSXMrOXh6ejBWS3BscWdyRU55NHNRSi9w
emsvOFN4S3V2cGdaNWF0R2pSOHVYTHc2Qkl2UlFYRitmbjU3ZTF0ZlgzOXdmcVk3UFphbXRy
T1k1ek9wMDJtNDBvT2pIRDVlbnIxcTF6T0J3bWswbjRVRHAwNkZCV1ZwYlpiTTdLeXVMbkl3
MytNUzdlcU04bUdOU05rWU5tSE54dWQyVmxKVDhaYkdKaTRyNTkrL2hESnlFaElmd0MxUVZO
TFE2TzQzSnljcjc0NGd2eDRXcXoyYXhXNjlOUFAyM01TYzlsUGQzditOeStmZHR1dC9QVHlo
dUhVYU5HZmZ2dHQ4SDc1T1hsMWRmWGU3M2V1cnE2U1pNbUVVVW5acmc4ZmZqdzRhV2xwVzF0
YlY2dmwyL0p6TXpjc21VTC82dlJyS3dzWVlYU1RmamRycytmcUJzVEhObHhFUDcvUFhic0dD
R2tvcUxpa1VjZUdUWnMyTnR2djIyMFFoeUVyaGJIVzIrOXhmKzB6MmRzcjErL1hseGNQSFhx
MUVnSVZSazBwNXQwZkZhdFd2WHl5eStIVTVjYU1abE1KU1VsVnFzMU5UVjExNjVkZnZzME56
ZmI3WGFHWWV4MmUwdExDMUYwWW9iTDA3LzU1cHRubm5sbS9QanhEejMwMEIvKzhBZCtsNFRx
TG1heldWaWhkQk4rdCt2ekorckdCSWRtSEZ3dTE0NGRPM0p5Y3NTTmpZMk5vMGVQRHBzdWxV
SlRpeU1tSmliUUJYU1B4Mk94V0NLZ1UyMVFubTdpOGVucDZVbE5UZVVOeTFEWTdYYVdaYjFl
YjBORFE2RHZFakl5TXB4T0o4ZHhMTXRtWm1hS242SS9NY043UGIydnI2K3hzZEZxdFJMcVBE
MDJObGI2YjZ6VTA4Vi9vbTZNbE9EanNIRGh3czdPVG83aktpc3JoWC9vK3Z2NzI5dmJjM056
aTR1TEk2SlJSWVJVaDhSbmJPL2R1N2RpeFlyQ3dzSXc2bE1yTktlYnovaFVWRlJNbXpZdHZM
SlV5Wnc1Y3dSUEQ1UTN4TWZITzUxT3I5ZGJXMXZMWDA4bm9aK1k0ZkowUHBlSmlZa1pPM2Jz
cDU5K1NnaHBhbXJLek13MG1VeVptWm44OVhUaTc1aFl1blJwWEZ5YzN5dnNnYjZiUXQwWU1U
UWp0blhyMXJTME5MUFpuSk9UNDNRNmhWY2xKeWN2WHJ5WTQ3Z282STRxTkxVNEJId096cUZE
aDg2Y09mUHMyYk1SMHFvT2FBNHp2K016WmNxVVFGY2U5TTI1YytlbVRKbGlOcHNkRGtkVlZS
WGY2RE5pRlJVVkRvZUR0ODNLeWtxaTZNUlVTNzJYd1VKVllnQUFJTUxvN1hlazhIUUFnSkhS
bTZjREFJQ1JnYWNEQUlCK1VMV25xL0I2UFFBQXFKbUlma2VxekozaDZTRkJVN3BFL043eHQ4
clNGS1BRTWNycXZVaXJjeGdIbW5OLzI3WnQ0OGFOczFnc2t5Wk5hbXhzSkE4ZWVKRlNHaDJr
K3k1dGtSSm9jTVJIblN3aGUvcDlTY0RUVlFWbDZSSWVvZXdHVFRFS0hhT3Mzb3UwT29mUkNI
NXV6cDA3OStUSmt4NlBaOXUyYmZ3ZDJjWTVsNlg3TG0wSmhNOG8rUngxc29UTDA2WDFYcVFm
MGUzdDdZOC8vcmpGWWhrL2ZqeGZIWkIvMW13MjUrWGxOVFEwK04xREVCeWEwaVU4NHJJYk5N
VW9kSXl5ZWkvUzZoeEdnL0xjdkhEaGdzVmk2ZTd1Wm94WElVZlk5eUF0UG9oSFZYclV5Ukl1
VDVmV2V5R1NJNkNnb09ETEw3L2tPSzYydG5iOCtQRkNlMjl2YjFOVFUwcEtpdDlYZ2VEUWxD
N2hFWmZkb0NsR29XT1UxWHVSVnVjd0dqVG41bzBiTndvTEM5OTg4MDJoeFRnVmNxVDdMbTJS
SWg3VlFGV0dnaEF1VDVmV2U1SEtNcHZOUXViT0Y5M2RzR0VEL3pNcW9TV2tuUUdFcm5RSmta
VGRvQ2xHb1dPVTFYc0pVcDNESU1pZW04ZU9IVXRMU3lzcEtlbnI2eE8zRzZGQ2puVGZBNDJH
RCtKUkRWSmxLQkRodlo0dXJ2ZENKTFZjQ2dzTHE2dXJQUjZQMEJJWEYxZFRVK04ydTFtV0ZW
YWJrcExDMXc0RU5GQ1dMdkVwdTBGVGpFTEhLS3YzNHJjNmg2RUk3akxsNWVXRmhZVkNJUkFC
STFUSWtlNTdvTkdRNG5kVW81K244NThxNG5vdlJGTEw1Y3laTXpObnp1UmIrTVlQUHZqQVpy
UFpiTFpWcTFZSjNUWnQybVMxV3BHdFUwSlp1c1NuN0liZlloVEdRVm05RjJsMUR1UEFQSWpR
R0tSUFYxY1gvOEFJRlhJQzdidTRoY2lObU05VGxKdldXNzBYQUFBd01xcit6UkVBQUlDUWdL
Y0RBSUIrZ0tjREFJQitnS2NEb0dyd2ZSVUlDWGc2QUg1UTdLU0Ric0ZCVmpnbzIySVlaczJh
TllTUWp6NzZhQ0FyWkJobTllclZBeGNtcll0Q1UxZEhlcjhHVFFtanFxcXE3T3pzMk5qWWdv
SUM4VS9aZzkvNklhME9SRlBMUmRwSHVoN3BwaFhjaHdKUEI4QVBodkwwek16TS92NytDUk1t
RE5EVE16SXk3dDI3TjBCaDByb285SFYxeE51bEtXRlVWRlRVMXRiR2NkeWVQWHRHamh4SnFW
eGFIWWltbG92ZkNqQitxd3hKTmNEVEFSZ29mczhyNXNGaVJEUkZqWUt2V1hoVmNYRnhYRnpj
aEFrVG1wdWJDU0hOemMyWm1abHhjWEhGeGNYaU5ZdTNMdDJXdElDUzN4MlI2cGsrZmZxS0ZT
dG16SmpCZHo1MDZGQldWcGJaYk03S3l1Si9JOE13ek5xMWF4TVNFdXgyKytiTm13T3RwN1Mw
OU1NUFB4UTJLbDFQZm40K0w3Nit2bDYyUW81UUY0VytybzU0Wi8yV01QSTdHbTYzdTdLeWNz
S0VDWHdIYVVVYW4xY0ZxUTRrVzh0RjNDZlFldURwQUF3K2djNGljVEVpbXFKR3dkY3MrSFZa
V1puYjdTNHZMNTg0Y1NJaEpEczd1N3k4M08xMmYvYlpaK0wrd1VzaEJTcWdKS3RuKy9idE1U
RXhPM2JzNEZlWW1abTVaY3NXdDl0ZFZsYVdsWlhGOTltd1lZUGI3YTZwcVFtVWh6SU0wOVhW
Tlc3Y3VOdTNid2RhejdwMTYrYlBuMDhJbVRkdjN2cjE2NE9vRXRkRm9hK3JJeDRReWhKRy9J
ZGlZbUtpK01mcXdTdlNCS29PUkZQTFJkd24wSHJnNlFBTVB0S3pTRnFNaUthb1VaQTE5L1Qw
Q0o3dWRyc0pJVzYzbTYrQ1lqYWIrUmFYeThYM29TbUZKQzJnRk9xZThvOU5KcE93ZGJQWnpM
ZjM5UFFFMzBHK2ZlWEtsZSsrKzI2ZzlkeThlZE5tczUwL2Y5NW1zOTI2ZFN1UUpKKzZLUFIx
ZGNUYTZFc1l1Vnl1SFR0MjVPVGtpQnVEVktUeFd4MklwcGFMVDU5QVZZYmc2UUFNUHRLenlH
OHhJaUpYMUVoS1VsSlNYVjJkeCtQWnVIR2o0T2w4UGx0ZVhwNmRuVTBJeWNuSjRmUDBzckl5
dm8vZnJjc1dVQXAxVDRQazZVRkdSdHp1Y3JuR2poMGJhRDJFa0tLaW9zY2VlMnpldkhtQjlF
anJvdERYMVJGcm95bGh0SERod3M3T1RvN2pLaXNyRXhJU2hQYmdGV21rMVlGb2FybEkrd1Nx
TWdSUEIyRHdZUjZFK0N0R3hEOFZ2S2lSbExLeU1wdk5scENRc0g3OWVwL3I2UmtaR1ljUEh5
YUVIRDU4T0NNakl5NHVidG15WllHMkx0Mld0SUFTVVhRdHFLbXBLVE16MDJReVpXWm1DdGZU
L2ZiM3U1N1ZxMWNIV2c4aHBMNitubUdZK3ZyNklIckVkSFYxMGRUVmtiNWZma3NZK1lqZnVu
VnJXbHFhMld6T3ljbHhPcDNDZW53cTB2aThTbG9kU0txWlpyOWsxK08zUlJaNE9nQlJKcVFz
RElEZ3dOTUJpREx3ZERDSXdOTUJBRUEvd05NQkFFQS93Tk1CQUVBL3dOTUJBRUEvd05PQk5x
aXVycTZwcWVudDdhMnBxYW11cnFaOFNmQm5BM1Z3dVZ3c3kvcnRIK1JWQUtnQmVEclFCdFhW
MVFjUEh2ejczLy8rdDcvOWJiQmNOZEI2amg4L0xuMEtWZzQwQVR3ZGFJUHE2dW96Wjg0NG5j
NHpaODRJOXVyem9McTZ1clcxMWVsMHRyZTNCMnIwV2FkMFEvZnUzYXV2ci9mcjZVNm5jOSsr
ZlZldVhCblVQUU5nTUlHbkEyMVFYVjE5OCtaTllTazBpaDlVVjFmZnVuWEw1WEx4dnduMDIr
aXpUdW1HdnZ2dXUzUG56dmw5cXIrLy84cVZLM1YxZFlPM1d3QU1NdkIwb0EycXE2djcrL3Yz
NzkvZjM5OHZHSzdUNlhTNVhJTExTeTFlMnVpelRyOGJDblRkdkwrLy85cTFhL0Iwb0diZzZV
QWJpQjFXZU56ZTN1NTBPbHRiV3hWNHVvOXhTNStWUHFpdXJ0NjNiOS9seTVjSGM4Y0FHRlRn
NlFBQW9CL2c2UUFBb0IvZzZRQUFvQi9nNlFBQW9CL2c2UUFBb0IvZzZRQUFvQjkrOXZUbTV1
YnRBQUFBdEE4RFF3Y0FBTjN3L3dIU0wwMUtqNEZMZ2dBQUFBQkpSVTVFcmtKZ2dnPT0iIC8+
PC9wPjxwPiZuYnNwOzwvcD48cD5UaGVyZSBpcyBhIHNsaWdodCBpbmNyZWFzZSBpbiBzbGVh
cGluZyBqb2JzIGF0IHRoZSB0aW1lIHNsb3QgaW4gcXVlc3Rpb24sIEkgZ3Vlc3Mgbm90aGlu
ZyB3ZSBjYTwvcD48cD5kaXJlY3RseSBtYXAgdG8gdGhlIGlzc3VlOjwvcD48cD4mbmJzcDs8
L3A+PHA+PGltZyBhbHQ9IiIgc3JjPSJkYXRhOmltYWdlL3BuZztiYXNlNjQsaVZCT1J3MEtH
Z29BQUFBTlNVaEVVZ0FBQWZFQUFBRnNDQUlBQUFCVHFCZTNBQUFnQUVsRVFWUjRuTzJkZjNR
VDVaNy9oeWFwYllDbVB5akxMME4vMkphMmdCZktiYXRYT1h5dGlGZGR2TjYweTdyK1dBOWUz
TE9JbGxiRXk5SERjZ0JscjdKb0xWWTlYS0VXQ21xVGxsYnh4NjJGOUtwN0xBSmlMMm1iMG9M
eXM4MlBOdTN6ejU1ei8rRDd4N1BPanZOTWttbWFaRExKKzNVK1owNzY1Sm1aOXp5WnZQdkpr
OGxudU84QkFBQkVCVmFybFZOYUF3QUFnQ0JndFZyMzc5Ly92NTVPQUFBQXFKbjkrL2ZEMHdF
QUlFcUFwd01BUVBRQVR3Y0FnT2dCbmc0QUFHcWlpVUg0TER3ZGdDRERjWnpTRWlKQ0F3Z3A0
K1BqMU0zaDZRQ0Vsa2p3MDBqUUFFS0h4K1A1N3J2dnpHYnoxYXRYbTV1YmhVL0IwMEdZNEg0
bUtTbnBvWWNldW5qeG90S0tRa1VrK0dra2FBQWhvcWVucDYydHJiT3pzNysvdjdtNStidnZ2
aE0rQzA4SFlZSjNtUXNYTHZ6elAvL3pQLzdqUHlxckozUkVncDlHZ2dZUUlvNGZQMzcxNmxW
dno4TFRRWmdRdXN5bFM1ZjBlajNmdm12WHJybHo1MDZaTW9VUTRuUTYvL1ZmLzNYNjlPblRw
MDkvNG9rbm5FNG43VFl5TXJKaHc0YTB0RFNEd2ZEeXl5L1RSby9IVTExZFBXUEdqTVRFUkpQ
SmRQMzZkZHB1c1ZqeTgvTjFPcDNSYU55N2Q2K1B4Z2x0UWY2Ujd0aXhJejA5WGEvWFAvcm9v
eTZYaXhCeSsrMjNIemh3Z08vVDA5TXphOVlzNFRzek16UHo1TW1UOVBFNzc3eERINXc4ZVRJ
ek05T0hUbS90L0dqLzlhOS9uVE5uenAvKzlLY0pIUUpRTC9CMEVDYUVubjc1OG1XaHA1dE1K
bjRxNXRsbm4xMjFhdFdGQ3hjR0J3ZnZ2dnZ1eXNwSzJyNXAwNmF5c3JLK3ZyNHJWNjQ4L2ZU
VHRQR2xsMTY2NjY2Nyt2cjZybCsvL3NnamovemhEMytnN1dscGFZY09IWEs1WEQwOVBZOC8v
cmlQeGdsdFFmNlIwa080Y09IQ3FsV3JObTdjU0FocGFXbkp5OHNiR3h1amZSNS8vUEh0Mjdj
TDExcTNidDNycjc5T0NPbnI2NXMyYlJwMTV6MTc5anoxMUZNK2RIcHJwNlBkMU5RMFk4YU1E
ejc0WUVMNlFZU0Q2MTVBUk1CNytzV0xGeDk1NUpINzc3K2ZiKy92NytlN3paNDkrK3pacy9U
eDk5OS9QMmZPSFBwNDd0eTU3Q2xxTkJyUG5EbERIdzhPRHM2Y09aTStuamR2M3U3ZHUvdjYr
b1NkSlJzbnRBWDVSL3JERHovUXgyZlBucDA3ZHk1OVhGUlU5TjU3Ny9HTnc4UER3clUrL1BC
RGs4bEVDTm0rZmZ1TUdUUG9oNFBmLy83M0gzMzBrUStkM3RvNWp2dXYvL3F2MmJOblc2M1dB
QTRCUkQ2NDdnVW9EUDhkNmZUcDB4OTg4TUhCd1VHK1hkaE5vOUY0UEI3NmVIUjBWS3ZWOHUy
am82T2liV3ExV2s0QW5iMGhoRml0MXQvKzlyZXBxYWtaR1JuVUU3MDFUbWdMa29jaitaVGtJ
WHp3d1FjNU9Ua2VqNmVpb3VLMTExNFRyVFUwTkhUenpUY1RRZ29MQzgxbWMwbEpDU0hrNXB0
dnB0YnZUYWUzZG83ak1qSXlubnZ1T1ZZZWlBSnczUXRRSG0vZjJvbmFaOCtlelNlNTMzLy8v
ZXpacytsanlUeDkzcng1ZHJ2ZDJ4N0h4OGZOWnZNLy9NTS8rR2dNWUF0K0VlYnBQL3p3QS85
UlkzeDh2TEN3c0xLeTBtZzB1dDF1ZHNVNzc3enovZmZmTHlvcUlvUVVGUlY5OE1FSHk1Y3Y5
NjNUV3p2SGNYMTlmVmxaV1R0MzdweVFlQkQ1NExvWEVCSEk5UFFOR3pid2s5RXJWNjU4NXBs
bmFQdnp6ei9QenFmL3gzLzh4NnBWcTdxN3UwZEhSNy85OWxzNmQwRUlLUzh2Lys2Nzc5eHV0
OWxzVGt0TDg5RTRvUzNJUDlMZi92YTNGeTlldkhqeDRyMzMzc3QvSlVBSXFhK3Y1emp1cmJm
ZWtseHgrL2J0YytiTW9TbjhxNisrT25mdTNCMDdkdmpXNmEyZGptcC9mMzlPVHM2MmJkc21w
QjlFT0xqdUJVUUVNajNkNFhBODl0aGowNlpObXpadDJtT1BQZVp3T0dqN3lNakkrdlhyVTFK
U2twT1RkKzNhUlJ2SHhzYTJiZHRtTkJwMU9sMUJRVUY5ZlQxdFAzRGdRRTVPamxhcnpjL1Bi
MmxwOGRFNG9TM0lQMUwrdXBkSEhubUV2M1NIRUhMdzRNSHM3R3gyRW9ueXpUZmZhTFZhK25Y
eGhRc1h0RnJ0Zi8vM2Yvdlc2YTJkSDlXQmdZRzh2THlYWG5wcFFvY0ExQXM4SFlEd2NkOTk5
KzNmdjE5cEZVRGQ0TG9YQUpSbmJHeXN0cloyd1lJRi9PV01BQVNHeU1UaDZRQW9BTWR4UnFN
UlZ4YUN5ZFBjM0R3eU1rSWZqNHlNNExvWEFBQlFNVmFyOWVUSms2T2pvNk9qb3lkUG51enM3
QlErQzA4SEFBQTE0WFE2VDV3NFliRllMQmFMMVdvVmZnbFA0T2tBQUtCcU1KOE9BQURSQXp3
ZEFBQlVUQXhkeTloOTdGajNzV05LcXdBQWdQQVJ0WjQrNm5MdHVlMjJQYmZkTnVweUthMEZB
QURDUk5SNitsLys5S2R0UnVNMm8vRXZLUDhQQUloVm9zVFRyL2IxN2N6Sm9aNitNeWZuYWtC
bHJ3RUFJUEp4T0J4V3E1Vy9scEd2aVVTSlhFOXZiR3pNek16VWFEUVpHUm1OalkyRUVMdmRY
bHBhR2g4ZlgxcGFLcW92MnZEWVk5VFFhVFE4OXBoQ3FnRUFJTFMwdDdlZk9YTm1aR1JrWkdU
azlPblQ3ZTN0d21jajE5T1RrcElzRm92TDVUS2J6UWFEZ1JCU1hsNWVYVjN0ZERxcnE2c3JL
aXJZVlRadjNrd0lFZDQweHdjanAwNzU3U056VTNLNlFaWDhibEFsdnh0VXllOFdtYW9Dd0d3
MjgxV0R4c2JHekdhejhObkk5ZlNGQ3hkYUxCWmF3SHJ4NHNXRWtMUzBOSHB6bk1IQlFjbVMx
dFRUdi9ycUt6bmJ2eWJqeHNFeU55V25HMVRKN3daVjhydEJsZnh1a2FrcUFOU2FwNTg0Y1NJ
cEtZbmp1S1NrcEJNblRoQkM0dUxpNkg4bmo4ZWowV2lFblQwLy9YU3RwbWJUdW5Ya3hJbi8r
Wi8vSVNkTzNMaHh3L2ZTMDlibXQ4OW9lN3ZmUGpMM0NGVlFCVlZRSlZ6KzNlVzZWbFBqN3Vx
YXFEY09EdytyY2o0OU96dWJuM3U1NVpaYkNDR3BxYWwrOC9RYk4yNE1EQXpja0FIcDdQVGJS
K2FtNUhTREt2bmRvRXArTjZpUzN5MENWWVhDT1NQWDA1T1RrL201bDVTVUZFS0l5V1RpNTlQ
NWUzUUpvWjRPQUFDcUlEQnZWT3QxTHcwTkRVYWpVYVBSeko4Ly85Q2hRNFNRM3Q3ZTR1Smlu
VTVYVWxMU0ozVzFJdkwwaVhhREt2bmRvRXArTjZpUzJTMHdiMVRyZkhvQUlFOW5zVnF0VnF0
VmFSVUFBQWtDTXpxMVh2Y1NBTWpUMlc2K1BSMWpKYjhiVk1udkJsVXl1d1ZtZE1qVFl4ZnJ6
eWd0QklBSUpldEdGZzFGOWg2WTBhbjF1cGNBUUo0dTZtYTFXck51WkNGUEQwcTNNS3V5V3Ey
dHJhMSs3Y2JIcG9UL3pxTjdyR1IyWS90WUJTaWlLaFEyR0lXZURuaXNWaXVYZFFONXVocVJ0
SnZBdGhCY1laSjdDZWt1UWdkTmVuem5QU0VsTUtPTG9mcnB5Tk5GM2Z4Nk9zWktmamRoSHg5
MktVZFZhMnVyWHhPeFdxMEx5d2FvM1FUMkNnby9wUVgzMDRPb2haVVgrYS9nRFY1NUl5ZDZq
MFIrbmk0eWNSRlI2T21BaC9mMGdOTVFwZVlaSXhrNm5uN2QxdThXL0hiZ3NtNndqak9odlFU
M1U1cmtJY3RwRWM0Z0tUaDVMWUsraUZ6V2pVbStSeVpEWUVZWEU1NCtNakppczluV3JsMTc0
OGFOYjc3NTVzYU5HNE9EZzc2WHBMUFRiNStCZ1FHL2ZXVHVVUkZWVnF1MXNHeVF5N3BCYzZ1
SnFxTHBaT3lNbGJkUm91Tnc1TWdSMnNkcXRaWU5sbVhkeUJyY1g4aTMwTGx2bWFwYVcxdTk3
WXZmWTlhTnJQdis1UnN1NjBaaDJTQjlGZWl6d2ozeXF2aDJxb0h2U2RkdGJXMDkrYzQ3L0tz
Wm1DclJIb1VhaEV2YWsvWXBHeXp6M1hPU1kxVTJXQmJ3ZVVXMWxRMlcwUkVXdmtmQ2RyYmI3
WGFielJaQW5hK1k4SFFLOG5RaGZLNDNtVVJQdlZPbDN2QjJVRllCYkR0L2RRUWZkR0Q1UDMx
dlZxWUdZUWQrRjZLWGp4VmovU1hDWGRCTVg5Z3pnSkVSRFFLZjFmS05vaGFyNEVPTTVOQk5h
UDU2UWdNN29XM3k3NDdKdkVjbVNTaHNNQW85blovRHNucmhmMGN6a3VhSWVXRkJ2MnBDK05H
U2ZSdklVV1cxV2srKzg0N2ZNMTR0MXlkSW5oSTBjNVMwU0w2ZHptNExYWUFQZm9hRUh5dmYw
TjM1aHN1NnNiQnNnSDM1ckQ4N0VSVkQrL3p2aEVZako1TE45eVM3NXJIYm1aQXFmbXNMeXdi
WWR1Ri9EanBXdkNwK2ZJUkx1bTZ3eGtwbU43YVBwS2RIL255NmI2TFEwNFh2WHNrRXdScGh1
YWZ3SkF2aU5rVUdGTUQzKy9Ta1YvYkNnQnUvVEJJbkwwUHlyT0RkaDEreUtUbnZSOTQ4WGVS
cnZvUGRpN2VkaWo0UWVQdS93dmFVVkJ1d0t0SFdoTU1sYkJFK3VOSEllUnN4djBwRXV3NXNE
UDBlcWNqVDVaOWR3WHEzQnVCeW4zenlTVmRYMStEZ29NZmprZXdRYlo0dSttOHMrWExTcHlh
YUkyUjUvMkpuTW5tNnlMQmtxdkloaHQ5czJVQ1pYMCtYdkJKQUNGM3hENTFML1o3QkF3TURm
bFh4ZS9UOWxtQlZpVjQ3dXFQQXJqQ3hDdjVSOFZFMlVDYXlKOVpEK2F6WnQ1LytvWE9wWCt1
aEw0MWYweEh1a2RYalRaVmt0OVZMTy8wNnFmQ0VrZFFqM0tPa0xmcFFKWE9zdktsaTIrbC9D
OUVyNkhkVFdWTC9oSVMySHZCNUpUckg2RmthaWp6OTJyVnIzZDNkSFIwZHpjM05IUjBkM2Qz
ZDE2NWRFM2FJTmsrWFBCSFpGR09pRWF4L3krd0x6eHNXVFdxQ0pjYjZ5OCtWM0M4LzgvcldJ
L1JRK1ZrTTMwR21QQjQ1UFlPWVR3bTM1czJTZ2hJK1VsUkVaQTcxWk00cjlsazVXNXVNM1ky
T2pnNE9EbloxZFgzeXlTZkM5aWowZE9GL2JHOHZudndjUWVpa1dWNisrWkdmSTRpc21kVXBV
NVhWK3dRQ3YzRnZ1Wkp3WGZZQUpmOHAwaXpQOTA3NUtXbkpJUktKWi9FOTdLTFhqalpLanBW
b2EreUhOdmEvSFNjdnI1VFRoeE5reEQ2TVJ1YW1RcUZxOHB1S1lsVSt6aXZKczkzYmVjNi9F
WHc3d3lROTNSdlI1dWx5WG40ZmtlVWx0ZWV5ZnBGV1M3cFNBSWdNWFg3STJYZ0E2d3FQM2Nj
SXlEbXVTWFlRZFE1WWlmWG5tUlpSQ3dMQnhpVFBLOUd6dmxjL2N2Skl6SGs2SnlBMU5aVVFZ
cmZiUzB0TDQrUGpTMHRMN1hZN3V3cjE5TW5rQ0NJakUyMHE2K2RKRXI4NXVHUitLcGtGaS9Z
b1AzUHh1MGNmNCtCTmxkK3g4bjJBZkFjZlBZVnptbnhQMFpES1VTVXpuNUtjamZVMnBIS0dQ
YkR6S3JCTlFWWDRWVTNtdkdMUE1lVHAwblIwZER6Ly9QT0VrUEx5Y3Y0K1J4VVZGV3pQeWVm
cGZrTmt3WkxmN0xONXJtVG1HOXo1Vm0vSnRad0Q4WDE5Z3N3dHlGK0w3K3pqdjRqZjhMYXV0
NkhHN0RaQ1p2QkpCajF0Sk04Y21lOWwwZXFpa3pOWW5xNitlaStyVnEwNmYvNDhJU1F0TFcz
UTMvMUlPVFhuQ0ZBRlZWQVZPNnBpMU5QYjI5c2ZmdmhoK2pndUxvN2UzY1BqOFdnMEdtRTN6
MDgvWGF1cDJiUnUzZStXbnVDeWJtQ0pKWlpZUnZqeTd5N1h0Wm9hZDFmWFJGMVIzWFVaVjZ4
WThmWFhYOVBIcWFtcHlOT2hDcXFnS2pwVXhXS2Uvdm5ubjk5eHh4MzhueWFUaVo5UE41bE1i
UDh3ektjakVBaEVVQ0lXUGYzT08rODhjdVFJLzJkdmIyOXhjYkZPcHlzcEtlbnI2MlA3STAr
SEtxaUNLcldvVXVhNmw5cmEyc2NmZjV3UVVsNWVQbjM2OUVPSERvVkNSTEJBbm81QUlOUVNB
WHU2dytHd0Judy9VcVBSMk5QVDA5TFNjdHR0dDMzNTVaZTV1Ym1CaVFnUHlOT2hDcXFnU2ky
cUF2YjA5dmIyTTJmT2pJeU1qSXlNbkQ1OXVyMjlYZmlzSDAvWGFEUWpJeVByMXExNzlkVlhS
MGRIdFZwdFlDTENBL0owQkFLaGxnalkwODFtTTcwQ2tCQXlOalptTnB1Rnovcng5T3pzN0Mr
KytHTEpraVhkM2QwMm0rM21tMjhPVEVSNFFKNE9WVkFGVldwUnBVeWVmdURBZ2VuVHB6Lzc3
TE9Fa0NlZWVLSzJ0all3RWVFQmVUb0NnVkJMQk96cHc4UERnYytucXd2azZWQUZWVkNsRmxX
eFcrOUZQc2pURVFpRVdpSmdUNS9VNzBqYjI5dHpjbkttVEpsQ0NGbXpaazE5ZlgxZ0lrTE55
TWlJeldaYnUzWXRsM1dEdjl1NjcrWHFwWjErK3l3c0cvRGJSK1llb1FxcW9BcXFoRXU3M1c2
ejJmcjcreWRxZDlURWVTdWZtS2ZmY3NzdExTMHRITWNSUW5wN2UrZlBueCtJNDRZTDVPa0lC
RUl0RVhDZWJyRllybCsvYmphYnIxMjdkdTNhdFphV0Z1R3pmanhkcDlPNVhDN3E2WmN1WGRM
cjlZR0pDQStZVDRjcXFJSXF0YWdLMk5OUG5qelozTnpjMDlQenlTZWZXQ3lXYytmT0NaLzE0
K2tyVnF4NDU1MTNPSTdyNys5ZnMyYk42dFdyQXhNUkhwQ25JeEFJdFlReTM1SDI5L2MvOE1B
RGVyMWVyOWV2WHIzNnh4OS9ESVdJWUlFOEhhcWdDcXJVb2txWjcwalZCZkowQkFLaGxzQzFq
UDVCbmc1VlVBVlZhbEdGdW96K1FaNk9RQ0RVRXNwNHVvSjFHY2ZHeHJaczJUSjc5dXdwVTZi
UUMyL3NkbnRwYVdsOGZIeHBhYW5kYm1kWFFaNE9WVkFGVldwUnBZeW5LMWlYY2V2V3JibTV1
VjFkWGVQajQ3U2x2THljdjg5UlJVVUZ1d3J5ZEFRQ29aWlFwbjY2Z25VWmpVYWpxSVprV2xv
YTdrY0tWVkFGVmRHaEt1YnFNbW8wbXFlZmZqb3hNZEZvTkg3d3dRZUVrTGk0T0ZvMTJPUHhh
RFFhWVdmUFR6OWRxNm5adEc2ZDR2Y0N4eEpMTExHVXMveTd5M1d0cHNiZDFUVlJiNXhVL1hR
RlNVdExNNXZOTHBmTGJEYlBtREdERUpLYW1vbzhIYXFnQ3FxaVE1VXllYnFDVkZSVW1NMW10
OXR0TnB2VDA5TUpJU2FUaVo5UE41bE03Q3FZVDBjZ0VHb0paZXFuSzNndFkzOS8veDEzM0tI
VDZUSXpNK21IaTk3ZTN1TGlZcDFPVjFKUzB0Zlh4NjZDUEIycW9BcXExS0lxNXE1bERBRGs2
UWdFUWkyaFRHMEFOZDVqT3RMK0cwOW9VMUFGVlZBVkk2b200K2trNFBycGFyekhOQUtCUUVS
K0tPUHBhcnpIZEtUOU41N1FwcUFLcXFBcVJsUXA0K25xQW5rNkFvRlFTd1RyTzlMbzkvUkkr
Mjg4b1UxQkZWUkJWWXlvVXNiVDFYS1BhUXJ5ZEFRQ29aWlE1cm9YdGR4amVtUmt4R2F6clYy
N2xvdTh1NE5INWozTG9RcXFvRXBaVlhhNzNXYXo5ZmYzVDlMOUp1YnBhcnpITkFLQlFFUitL
RFAzb3NaN1RFZmFyTm1FTmdWVlVBVlZNYUlLOTVqMkQvSjBCQUtobHNBOXB2MkRQQjJxb0Fx
cTFLSUs5NWoyRC9KMEJBS2hsbEFtVDZmZmpucjdNOUpBbmc1VlVBVlZhbEUxbVR6ZDdYWi8v
dm5uemMzTkZ5OWVGRDNsdjRhWDIrM210eElYRnhld2lEQ0FQQjJCUUtnbEF2WjBhdWhuenB5
NWZQbnkwYU5IcjE2OUtueldqNmNYRnhjLzk5eHpseTlmdm56NWNsVlYxYTkvL2V2QVJBUUFK
NEMyMk8zMjB0TFMrUGo0MHRKU3U5M09yb0k4SGFxZ0NxclVvaXBnVC8vc3M4OTR1ejUvL254
Ylc1dndXVCtlZnU3Y3VaVXJWeVltSnVyMStudnV1Y2Rtc3dVbUlnRFllWjd5OG5MK1BrY1ZG
UlhzS3NqVEVRaUVXaUpnVHhkNTlibHo1NFIvUnU1M3BCekhUWjgrWGEvWHIxcTFpdjR2U1V0
THcvMUlvUXFxb0NvNlZNWG90WXdYTGx5b3JLd3NMaTRtaE1URnhkRzdaWHM4SG8xR0krem0r
ZW1uYXpVMW05YXRVL3hlNEZoaWlTV1djcFovZDdtdTFkUzR1N29tNm9xVHFyWDd0Ny85YmVY
S2xmUTNSeXRYcmhRbCtlSEI0WERvZERwQ1NHcHFLdkowcUlJcXFJb09WY3JVVDErMmJObm16
WnZwZDZTYk5tMWF0bXhaWUNJQzVzcVZLNXMzYnk0cUtpS0VtRXdtZmo3ZFpES3huVEdmamtB
ZzFCTEtlTHBXcTNXNVhQU3gwK21rK1hKNG9GZThKQ1FrckZpeDR1elpzNFNRM3Q3ZTR1Smlu
VTVYVWxMUzE5Zkhyb0k4SGFxZ0NxclVva3FaMzVFV0ZSVnQzcno1eXBVclY2NWMyYkpsQzgy
WEl4Yms2UWdFUWkyaHpIZWtQL3p3UTFsWldXSmlZbUppWWxsWldYZDNkMkFpd2dQeWRLaUNL
cWhTaTZwSjV1bmo0K09pU1JoS3BGLzNNaUdRcHlNUUNMWEVaRHpkNC9GODk5MTNaclA1NnRX
cnpjM053cWY4ZURxOWE1MWFRSjRPVlZBRlZXcFJGYkNuOS9UMHRMVzFkWFoyOXZmM056YzNm
L2ZkZDhKbi9YajZuRGx6MkJveEVRdnlkQVFDb1pZSTJOT1BIejh1cXZFaXhJK243OXExNjhr
bm54d2FHZ3BzMzJFR2VUcFVRUlZVcVVXVk10ZTljQXloRUJFc2tLY2pFQWkxQk82SjRZdVJr
UkdiemJaMjdWb3U4dTRPSHBuM0xJY3FxSUlxWlZYWjdYYWJ6ZGJmM3g5Y000d1NUNmNnVDBj
Z0VHb0paZkwwNzcvLy91Njc3NmIxWHU2KysyNzZlODZJQmZQcFVBVlZVS1VXVmNwNGVrRkJ3
UXN2dkVCL1I3cDU4K2JDd3NKUWlBZ1d5Tk1SQ0lSYVFobFAxK3Yxd25vdmVyMCtGQ0tDQmZK
MHFJSXFxRktMS21VOHZhcXFhc3VXTFh5OWw2cXFxbENJQ0JiSTB4RUloRm9pVXE1bGpPUXJH
cEduUXhWVVFaVmFWT0ZhUnY4Z1QwY2dFR3FKR1BYMExWdTI4QjhMN0haN2FXbHBmSHg4YVdt
cDNXNW5PeU5QaHlxb2dpcTFxSXBGVCsvczdKdzFheGJ2NmVYbDVmeDlqaW9xS3RqK3lOTVJD
SVJhSXVZODNlbDBGaFlXSGp0MmpQZjB0TFEwM0k4VXFxQUtxcUpEVmN4NSt2cjE2M2Z0MmtV
STRUMDlMaTV1Ykd5TUVPTHhlRFFhamJDejU2ZWZydFhVYkZxM1R2RjdnV09KSlpaWXlsbisz
ZVc2VmxQajd1b0tybk5LZXpwdm93cGU0akpseWhUUmxUYXBxYW5JMDZFS3FxQXFPbFNGTlUr
Zk1XTkdSMGZIK1BoNEpGeTJ5R3N3bVV6OGZMckpaR0o3WWo0ZGdVQ29KY0xxNlgvKzg1L256
cDByeXBTVnVqS2QzMmx2YjI5eGNiRk9weXNwS2VucjYyTjdJaytIS3FpQ0tyV29VdXczUjZI
WWE0aEFubzVBSU5RU01mY2RhUUFnVDRjcXFJSXF0YWhTeHRQLzlyZS9yVnk1a3RiYVhibHk1
Ymx6NTBJaElsZ2dUMGNnRUdvSlpUeDkyYkpsbXpkdnZuejU4dVhMbHpkdDJyUnMyYkpRaUFn
V3lOT2hDcXFnU2kycWxQRjByVllyckxXcjArbENJU0pZSUU5SElCQnFDV1U4dmFpb2FQUG16
WHl0M2FLaW9sQ0lDQmJJMDZFS3FxQktMYXFVOGZRZmZ2aWhyS3dzTVRFeE1UR3hyS3lzdTdz
N0ZDSW1qL0FlMDNMdS9Zb2xsbGhpcWV3Uzk1ajJEL0owcUlJcXFGS0xLbHpMNkIvTXB5TVFD
TFVFUE4wL3lOT2hDcXFnU2kycTRPbitRWjZPUUNEVUV2QjAveUJQaHlxb2dpcTFxRkxHMDZk
TW1SS0t2WVlJNU9rSUJFSXRvWXluejVrejUrTEZpNkhZY1NoQW5nNVZVQVZWYWxHbGpLZnYy
clhyeVNlZkhCb2FDc1crZlZOZlg1K1RrNlBUNlJZdFd0VFcxa1prMzJNYWdVQWdJajhVcTdX
clZQMzBoeDkrMkdhek9SeU85OTkvUHpVMWxjaSt4M1NrL1RlZTBLYWdDcXFnS2taVXhlaDNw
QzZYNjlDaFF3c1hMaVN5N3pHTlFDQVFrUit4Nk9uMGswRnljdkx4NDhlSjdIdE1MeXdia0hP
UDErMTN2TzIzejRaVkgvcnRJM09QVUFWVlVBVlZ3bVZZN3pITjA5N2VucE9UUTY5K1diTm1U
WDE5ZlhCMzd4YzY5NUtWbFVWazMyTWFnVUFnSWorVXlkTnZ1ZVdXbHBZV09vM2UyOXM3Zi83
OFVJaVFaUDM2OVJjdlhuUTRIQWNQSHB3NWN5YVJmWS9wU0pzMW05Q21vQXFxb0NwR1ZDbmo2
VHFkenVWeVVVKy9kT21TWHE4UGhRaEo2dXJxWnMrZUhSOGZ2M1RwMGs4Ly9aVEl2c2MwQW9G
QVJING80K2tyVnF4NDU1MTNPSTdyNys5ZnMyYk42dFdyUXlFaVdDQlBoeXFvZ2lxMXFGTEcw
L3Y3K3g5NDRBRjZQOUxWcTFmLytPT1BvUkFSTEpDbkl4QUl0VVFzWHZjeVVaQ25ReFZVUVpW
YVZNSFQvWU04SFlGQXFDV1U4ZlR2di8vKzdydnZwbk12ZDk5OTk5bXpaME1oSWxnZ1Q0Y3Fx
SUlxdGFoU3h0TUxDZ3BlZU9FRmVvL3B6WnMzRnhZV2hrSkVzRUNlamtBZzFCTEtlTHBlcjNl
NVhQU3gwK2tNNTdXTUFZQThIYXFnQ3FyVW9rb1pUNitxcXRxeVpRdk4wN2RzMlZKVlZSVUtF
Wk5uWkdURVpyT3RYYnVXVS9wZTRGaGlpU1dXY3BaMnU5MW1zL1gzOXdmWERLVTluUzNIR1A2
NmpBR0FQQjJxb0FxcTFLSUsxNzM0Qi9QcENBUkNMUUZQOXcveWRLaUNLcWhTaXlwbFBQM3c0
Y05HbzNIS2xDa3FtbnRCSUJDSXlBOWxQRDB0TGUzZ3dZTWVqeWNVK3c0NnlOT2hDcXFnU2ky
cWxQSDA1T1RrNGVIaFVPdzRGQ0JQUnlBUWFnbGxQUDNGRjEvY3NtV0wwK2tNeGI2RER2SjBx
SUlxcUZLTEttVTh2Ykd4OGFhYmJsTGtXc2FHaG9ZRkN4Ym9kTHBGaXhhMXRiVVJRdXgyZTJs
cGFYeDhmR2xwcWQxdVoxZEJubzVBSU5RU3luaDZlbnA2WTJPakl2UHBEejMwVUZkWGw5UHAz
THQzTDcxVFhYbDVPWCtmbzRxS0NuWVY1T2xRQlZWUXBSWlZ5bmg2VWxLUzR2UHBOcHZOYURR
U1F0TFMwbkEvVWdRQ0VSMFJvL1BwQXdNRFM1WXMrZkRERHdraGNYRnhZMk5qaEJDUHg2UFJh
SVRkUEQvOWRLMm1adE82ZFJGNGQzRDVmYUFLcXFBcWRsVDkzZVc2VmxQajd1b0tybWY2OFhS
bGF3TllyVmFqMGJodjN6NzZaMnBxS3ZKMEJBSVJIUkZ6dnlPdHJhMU5UMDgvZXZRbzMySXlt
Zmo1ZEpQSnhLNkMrWFNvZ2lxb1VvdXFtUE4wMGVlRG9hR2gzdDdlNHVKaW5VNVhVbExTMTlm
SHJvSThIWUZBcUNXVThYVFVaWlN6S1RYbUNGQUZWVkNsckNxRjgzU0h3L0hDQ3k5czNibzFG
Q0tDQmZKMEJBS2hsbEIrN21Wb2FDZ3BLU2tVSW9JRjhuU29naXFvVW9zcWhUM2Q0L0hVMTll
bnA2ZUhRa1N3UUo2T1FDRFVFZ3JQcDArWk1zVm9OQjQrZkRnVUlvSUY4blNvZ2lxb1Vvc3E1
ZWRlSWgvazZRZ0VRaTBCVC9jUDhuU29naXFvVW91cWNIdTZ1dTR4UFRJeVlyUFoxcTVkeXls
OUwzQXNzY1FTU3psTHU5MXVzOW42Ky91RGE0YXk4dlN4c2JGMzNubm41cHR2WHIxNmRYQjNI
MXlRcDBNVlZFR1ZXbFFwTnZmUzFOUlVVRkR3bTkvODV2ang0NkZRRUVRd240NUFJTlFTQ25q
NmlSTW5mdk9iM3hRVUZEUTFOWVZpMzBFSGVUcFVRUlZVcVVWVnVEMTk5ZXJWTjk5ODg5dHZ2
MDNMMjZvQzVPa0lCRUl0Z2U5SS9ZTThIYXFnQ3FyVW9nclhNdm9IZVRvQ2dWQkx3TlA5Z3p3
ZHFxQUtxdFNpS3VZOG5aM3RzZHZ0cGFXbDhmSHhwYVdsZHJ1ZFhRVjVPZ0tCVUV2RW5LZFRo
SjVlWGw3TzMrZW9vcUtDN1l3OEhhcWdDcXJVb2dxZVR0TFMwbkEvVWdRQ0VSMEJUeWR4Y1hI
MHdrcVB4NlBSYUlUZFBELzlkSzJtWnRPNmRSRjRkM0Q1ZmFBS3FxQXFkbFQ5M2VXNlZsUGo3
dW9Lcm1lcXlkTlRVMU9ScHlNUWlPZ0k1T25FWkRMeDgra21rNG50alBsMHFJSXFxRktMcXBq
emRQYTNUcjI5dmNYRnhUcWRycVNrcEsrdmoxMEZlVG9DZ1ZCTHhKeW5Cd0R5ZEtpQ0txaFNp
eXA0dW4rUXB5TVFDTFVFUE4wL3lOT2hDcXFnU2kycTRPbitRWjZPUUNEVUV2QjAveUJQaHlx
b2dpcTFxSUtuK3dkNU9nS0JVRXZBMC8yRFBCMnFvQXFxMUtJS251NkxrWkVSbTgyMmR1MWFU
dWw3Z1dPSkpaWll5bG5hN1hhYnpkYmYzeDljTTR3U1Q2Y2dUNGNxcUlJcXRhaENudTRmektj
akVBaTFCRHpkUDhqVG9RcXFvRW90cXVEcC9rR2Vqa0FnMUJMd2RQOGdUNGNxcUlJcXRhaUNw
L3NIZVRvQ2dWQkx3TlA5Z3p3ZHFxQUtxdFNpQ3A1TzdIWjdhV2xwZkh4OGFXbXAzVzVuT3lC
UFJ5QVFhZ25lMHhzZWYveEtiMit3ZkZKTm5sNWVYczdmNTZpaW9vTHRnRHdkcXFBS3F0U2lp
dmYwYlVianp0emN2L3pwVDZOTzUrUjlVazJlbnBhV2h2dVJJaENJNkFpaHA5TjQvVGUvK2VH
VFR5YnBrMnJ5OUxpNHVMR3hNVUtJeCtQUmFEUzA4ZlRwMDg4OTkxejFoZzNQUHZEQS83djk5
bzJQUFBMRUUwOXNmT1NSNTU1N3p2ZnltWHZ1OGR2bkR3OCs2TGVQekQxQ0ZWUkJGVlFKbDlT
MXF0YXUvVDlQdi8zMkh6NytlSkkrcVNaUFQwMU45WnVuRTBMT25Uc25aMnZPTDc3dzIwZm1w
dVIwZ3lyNTNhQktmamVva3Q4dE1sV1JuK2RldnZqUC80eTV1UmVUeWNUUHA1dE1KcllEOVhT
MzJ5MW5hOWYyN3ZYYlIrYW01SFNES3ZuZG9FcCtONmlTM3kweVZSRkNHaDU3N0VwUGo1eWVj
bENUcC9mMjloWVhGK3QwdXBLU2tyNitQcllEOVhTWmVDNWVESjYwb0FGVjhvRXErVUNWZkNK
VGxYelU1Ty9QQ0E0QUFCNkZTVVJCVk9sKzZlcnFVbG9DQUFBb1NWUjVPZ0FBeERqdzlBQnBh
R2hZc0dDQlRxZGJ0R2hSVzFzYklZVDdtWWhTeGJaRWdxcjYrdnFjbkp4SVUwWFpzbVdMZ2kr
aWovTXFvbFNOalkxdDJiSmw5dXpaVTZaTVVVcVk3N0ZLVFUyTkVGV05qWTJabVprYWpTWWpJ
Nk94c1RIVUF1RHBBZkxRUXc5MWRYVTVuYzY5ZS9jS0w4SlIxdE5aVmQ1MEtxdnE0WWNmdHRs
c0RvZmovZmZmVitxOUp6a3luWjJkczJiTlV2QkZaRlVwZTBaUldGVmJ0MjdOemMzdDZ1b2FI
eCtQSEZVOEhSMGR6ei8vZklTb1NrcEtzbGdzTHBmTGJEWWJESVpRQzRDblR4YWJ6V1kwR3Zr
L0krRWRTQmhWa2kzaFI2VEI1WElkT25SbzRjS0ZDa29pQWxWT3A3T3dzUERZc1dPUjhDTHlx
amlPbXo1OXVsNnZYN1ZxbGMxbWl4QlZScVBSYkRZcks0YUhQYmRYclZwMS92eDVwZlJRZUZV
TEZ5NjBXQ3h1dDl0c05pOWV2RGpVKzRXblQ0cUJnWUVsUzVaOCtPR0hmRXNrMkFHcmltMVJY
Qlg5Z0p5Y25IejgrUEVJVWJWKy9mcGR1M2FSQ0hnUjJkZnJ3b1VMbFpXVnhjWEZFYUpLbzlF
OC9mVFRpWW1KUnFQeGd3OCtpQkJWbFBiMjlvY2ZmbGhCU2VTWHFrNmNPSkdVbE1SeFhGSlMw
b2tUSjBLOWEzaDY0Rml0VnFQUnVHL2ZQbUdqNG5iQXFwTFVxYmdxUWdpZGU4bkt5b29RVlhS
cVdQSEphMit2bDhQaDBPbDBpa2dpaktxMHREU3oyVXpuRTJiTW1CRWhxaWdyVnF6NCt1dXZs
WkpFR0ZYWjJkbjgzTXN0dDl3UzZyM0Qwd09rdHJZMlBUMzk2Tkdqb25abFBaMVY1VTJuc3Fy
V3IxOS84ZUpGaDhOeDhPREJtVE5uUm9ncUhnVmZSRytxcmx5NXNubno1cUtpSWlWRVNhaXFx
S2d3bTgxMFBpRTlQVDFDVkJGQ1B2Lzg4enZ1dUVNUlBSUldWWEp5TWovM2twS1NFbW9COFBR
QTRYN0owTkNRcUNVeVZRME5EVVdDcXJxNnV0bXpaOGZIeHk5ZHV2VFRUejhOdnlSSlZjS25G
SkVrcVlvK1NFaElXTEZpeGRtelp5TkVWWDkvL3gxMzNLSFQ2VEl6TTVXYVdKZDhCZSs4ODg0
alI0NG9vc2VicW9hR0JxUFJxTkZvNXMrZmYralFvVkFMZ0tjREFFRDBBRThIQUlEb0FaNE9B
QURSQXp3ZEFBQ2lCM2c2QUFCRUQvQjBBQUNJSHVEcEFBQVFQY0RUQVpnVUNsN01EZ0FMUEIx
STQzYTdOMnpZTUdQR2pHblRwbTNmdmwxcE9jckRjZHdycjd4Q0NIbjU1WmZoNDRTUXJxNHVq
dU53SXhvU1llY0dQQjFJVTFWVjljQURENXcvZi83S2xTdlBQUE9NMG5LVWgrTzR2THk4OGZI
eDNOeGN4ZCsza2NET25Udmo0dUoyN3R5cHRCRGxpYWh6QTU0T3BKa3paNDdvcnVmQ2s1Vi96
SEZjVlZXVlhxL25pNGdxZms2SENJN2picnZ0dHExYnQ5NSsrKzNDd3hjTnk2dXZ2cHFTa3BL
Y25MejM1MXNWUit1QXJGaXg0dkhISDEreFlnWDljL0hpeGZRV0VLMnRyYmZlZWlzaHBMT3pN
eTh2THlFaG9icTZXamhpU2drT0hleTVRVThNclZiTDN4bGozYnAxLy9Jdi8wSUllZmpoaDU5
NjZpbCt4YUNMZ2FjRGFUUWFqY2ZqRWJaNDgvUlhYbmxsZUhqNHlTZWZES3Urc01OeDNQNzkr
K1BpNGc0Y09DQTVGUFR4bmoxN0hBNUhjM096VW5jZ0NRL0R3OE5UcDA0OWYvNzgxS2xUaDRl
SENTR3Z2ZlphUlVVRklhUzh2SHozN3QyRWtJVUxGNzd4eGh2RHc4Tjc5KzZOU2l2bjhYWnVl
RHllOXZiMldiTm1FVUpHUjBmdnV1dXVmL3UzZjd2cnJydEdSMGRESndhZURxVHhrYWVQam80
S1BYMWtaQ1RjNHBUQWg0OExIL052MStoMnNhYW1KcjVNVlZOVEV5SGswcVZMQm9QaDNMbHpC
b1BoOHVYTGhCQ3RWdXR3T0FnaERvY2p1a2VEUFIvMjdObGpOQnJqNHVJNGpwc3laUXA5cXJP
emsrTzR6czdPa0lxQnB3TnBLaXNySDNqZ2dZR0JnYXRYcjFaV1ZoSkMwdExTamg0OTZuUTZY
My85OWVqK0tDMkpURStYZkJ4OVBQWFVVL1NiOCszYnQvTXpDU2FUNlZlLytsVjVlVG45czdD
dzhNMDMzM1E0SEcrLy9YWjBqd2I3dWlja0pEUTNOenNjRHJQWlRGc2NEc2VpUll0V3JWcTFh
TkVpcDlNWk9qSHdkQ0NOeStYNjkzLy85N1MwTlA2Nmw5cmFXb1BCa0pLU3NudjNiaCtlSHEz
dlh2WjlLNnFxS3RtSFJPbUFaR1ptZnZ2dHQ0U1FiNy85TmpNemt6YTJ0clp5SE5mYTJrci90
RnF0T1RrNUNRa0pHemR1akl1TG80MVJPUnJzNi83aWl5OGFEQWFEd2JCanh3N2E4dWlqajY1
WnM0WVE4ay8vOUUrUFBmWVl1Mkt3Z0tjREFFTEkyTmpZa1NOSGNuTnpsUllTSzhEVEFRQ2hn
czRtWjJabUtuWG5reGdFbmc0QUFORURQQjBBQUtLSE1IbTY4SHVrWUcwd1dKc0NBSUNvWVdL
ZXpubEI1czVneENwQytQcW1wcVlTUW5wNmVvcUxpK1BqNDR1TGkzdDdleVhYYW14c3pNek0x
R2cwbVptWmh3OGZwaTM1K2ZueDhmRkxsaXo1L1BQUHczb01RY1hsY2ozOTlOUHA2ZW44T2Qv
WTJHZzBHblU2M2E5Ly9ldnU3bTdKdGRoQkMzcCtvd2pzNmJGdjM3NnNyQ3lkVG5mcnJiY2VP
M1pNY2kyMmo1d3hqSHpZMFdCYldOaGpEOEJVV1NidTZWazN4QUZQajJxZWV1cXBUWnMyRVVK
Kzk3dmZWVmRYTzUzTzZ1cHFrOGtrMmRsZ01MUzB0TGhjTG92RllqQVlDQ0VtaytuVXFWTXVs
K3Z3NGNNelo4NE1wL0xnVWxsWnVYang0bE9uVG8yUGo5T1cxTlRVdHJZMnQ5dHROcHZ2di85
K3liVzhEVnJVdkJlRXA4ZTMzMzdyZERyMzdkdm43VGUwYkI4NVk2Z2krTkh3MGNMREhudFF6
b3BRZWZwcnI3MW1OQm8xR28zd2Y0Nm81K25UcDB0S1NuUTZYWFoyTnMzZzJCYU80eW9yS3hN
U0VuSnpjNjFXNi8vSjhGbGtRN0xRQkFpQUsxZXVKQ2NuOS9mM0UwSlNVMU1IQndjSklZT0Rn
OTdldElzV0xXcHRiWFc3M1VlUEhxVkZQeWdPaDZPaG9VSFZGN1RObmozN3M4OCtFN2FrcHFa
Ky9QSEg5RDJaa3BJaXVaYTNRWXVPMDFKNGV2RDA5ZlhwZERyZnZ5N20rOGdaUTdYQWpvYmsr
UEN3eDg1eG5NRmcwT3YxOTl4emo4MW1DMHhHcUR4OTZ0U3AyN1p0TzNYcWxOdnRGcTR1N0xO
a3laTDMzbnZQNVhLMXRMUmtaMmRMdG5BY1YxdGI2M0E0NnVycUNnc0xKVGZGTVVVMllxZlFS
S2pac1dNSC9hRUVJU1F1TG01c2JPeTIyMjd6ZUR3YWpVYXl2OVZxVFU1TzVqZ3VPVG1aL3cw
MC93bjBxNisrQ3BQdUVLRFJhS3FycS9WNi9ieDU4dzRlUEVnSXFhK3ZuenQzYm1KaTRzYU5H
NzBOaUxkQmk0N1RVbmg2VUg3ODhjZWlvaUxmaFR5RmZlU01vVnBnUjROdEVlTHQyQzlldkZo
WldWbGNYQnlZakZCNStrY2ZmWFR2dmZkbVoyZFBtemJ0ajMvOEk3KzZzSTlXcStVbmoyaEpC
TGFGNHppK1pJUk9weE1xRVQ0V0ZkbUluVUlUSVdWMGRIVGV2SG04TmFlbXBsNjRjSUg0ek5O
emNuSXNGb3ZMNVRLYnpYbDVlWHo3OFBEd2dRTUhDZ29LUXE4NlZDUW5KNXZOWnJmYjNkYldK
cG9oUFhiczJKdzVjeVRYOGpab1VYQmFpazRQUXNoWFgzMlZrWkZSWFYwOU5qYm1iUzF2Zlh5
TW9TcGdSNE50OFFaNzdFNm5VMmgzRXlLMDgrbGpZMlBIamgzVDYvWDB6MW16WmdrenRhS2lv
cWFtSm1IcEE3YUY0N2kzM25xTDV1bjUrZm5DZGgrUFk2ZlFSRWlwcjY4dkxTM2wvM3p3d1Fj
M2JkcmtjcmsyYmRyMCs5Ly9YbktWcEtRa2k4WGlkcnRiV2xyb2ZQcWpqejdhMDlQamNya2FH
aHBVL2VINnZ2dnU0ejJkZCtmeDhmSFRwMDh2WExpUWxzUmg4VFpvVVhCYWlrNlB1cnE2b3FL
aUw3Lzgwc2Nxa24zOGpxRXFFSTJHWkF1TDVMRmZ2MzU5NjlhdFJVVkZnU2tKbGFmVFhEc3VM
bTcrL1BsdnZQRUdiWHp6elRmMWVqM2YvOHlaTTh1WEwwOUlTT0RueDlrV2ZqNDlKeWVubzZP
RDM3THcyMkhXMHlVTFRZQ0pzbXpaTWpySlFMSFpiTXVXTGFOZjAvZjA5TkJHMGF0ZlgxOVB5
OUhObnorL29hR0JFUEx1dSs5bVpHUm90ZHFDZ2dLTHhSSk8vY0dsdTd0NzJiSmxXcTNXYURR
Mk5qYVNuMC9GOVBUMDlldlh1MXd1MmswMElPeWdzU2V3U2hHZEhxTGpHaG9hSXN4b3NIMGt4
MUNOaUVaRHNrVnlOSVRIVGx0dXV1bW01Y3VYbnoxN05qQWxZYjJXTVFBbXMzRVVtZ0FBeEJx
Ui9qdlNnRDJkUTZFSkFFRHNFZW1lRGdBQVFEN3dkQUFBaUI2aXpkTlYvYVVUQUFCTWttaXI5
d0pQRHgxeTZyMndmZVNzcFZJd0lFSXdHa0lVSEkwSmUvb3BKdURwTVlLY2VpOXNIemxycVJR
TWlCQ01oaEFGUnlOVW5zN1dlMkh6K2krLy9ITEJnZ1ZhclhiQmdnWDBad2djVTkyRmJXRnJ3
bGl0VmxyZHBiS3lFcDRlT3VUVWUySDd5RmxMcFdCQWhHQTBoQ2c0R3FIeWREbjFYdkx5OHVo
dlJHdHJheGNzV0VDa3FydXdMV3hObVB6OC9McTZPb2ZEVVZOVEEwOFBIWExxdmJCOTVLeWxV
akFnUWpBYVFoUWNqVkI1dXB4Nkx4cU5obFpsR1I0ZTFtcTFSS3E2QzlzaVdTV0czdzQ4UFhU
SXFmZkM5cEd6bGtyQmdBakJhQWhSY0RSQ081OHVxdmNTSHg4dkxDQXBtYWVMcXJ1d0xXeE5t
SUtDQXBxbjE5Yld3dE5EaDV4Nkwyd2ZPV3VwRkF5SUVJeUdFQVZISTFTZVR2Tm9VYjJYRFJz
MjBGb3U5TS8yOXZhOHZEeU5ScE9YbHllYVR4ZFdkeEcxc0RWaE9qbzZhSFdYcXFvcWVIcm9r
RlB2aGUwanVWWjBnQUVSZ3RFUW91Qm9SRmE5RjNaVDhHZ0FBSkJQWlAzbUNKNE9BQUNUSWJJ
OEhRQUF3R1NBcHdNQVFQUVFXWjd1YmFZRk16QUFBQ0NIU1ArT0ZFUU9LT2doQWdNaUJLTWhS
RTMxWHQ1bEFwNGVJNkNnaHdnTWlCQ01oaEExMVh1UjZlbkNMSDdxMUtuRVMzV1hwVXVYbHBl
WFoyUmtsSmVYMDVhcXFxckV4RVMrdWd1L0tYN0xiTDBYRUI1UTBFTUVCa1FJUmtPSW11cTlU
Q2hQcjZtcG1UNTlPblZ3eVYrTmRuVjEwU1gxZldGMWw0S0NBdUYrK2Nkc3ZSY1FIbERRUXdR
R1JBaEdRNGlhNnIzSTkvVDYrdnJrNU9Uang0L1RQeVdydTdCTFVYVVhmci84WTdiZUN3Z1BL
T2doQWdNaUJLTWhSRTMxWG1SNmVuTno4NHdaTS9qNUUrSWxUMmVYZkhVWFdvV1IzeS8vbUsz
M0FzSURDbnFJd0lBSXdXZ0lVVk85RjVtZXJ0ZnJSUmZHU0ZaM1laZDhkUmUrZnJwb08yeTlG
eEFlVU5CREJBWkVDRVpEQ09xOUFBQUFDQUtSOVpzakFBQUFrd0dlRGdBQTBRTThIUUFBb29k
d2VIcGdFKzZZcGdjQWdJa1NqdTlJNGVuUkFRcDZpTUNBQ01Gb0NGRlR2WmNiVE1EVFl3UVU5
QkNCQVJHQzBSQ2lwbm92TWozZGFyWG01ZVVsSkNSVVZsYlNEbXlkRnByamE3WGFSWXNXdGJX
MVNhNEZJZ2NVOUJDQkFSR0MwUkNpcG5vdk1qMDlQeisvcnE3TzRYRFUxTlRRRHQ3cXRIZzhu
dmIyOWxtelprbXVCU0lIRlBRUWdRRVJndEVRb3FaNkx6STlYYXZWOHRWZGFBZTJUc3VlUFh1
TVJtTmNYQnpmd3E0RklnY1U5QkNCQVJHQzBSQ2lwbm92TWoyOW9LQ0FadHkxdGJXMEExdW5K
U0Vob2JtNTJlRndtTTFtMm9kZEMwUU9LT2doQWdNaUJLTWhSRTMxWG1SNmVrZEhSMDVPVGtK
Q1FsVlZsYmM2TFMrKytLTEJZREFZRER0MjdLQXQ3Rm9nY2tCQkR4RVlFQ0VZRFNHbzl3SUFB
Q0FJNEhla0FBQVFQY0RUQVFBZ2VvQ25Bd0JBOUJDSm5vNEplZ0FBQ0F4OFJ3cmtnb0llSWpB
Z1FqQWFRdFJVNzRYNzZDTnh3Tk5qQXhUMEVJRUJFWUxSRUtLbWVpOHlQWjM3K2M2aXVibTV3
anVMQ3F1N2RIWjIwdW91MWRYVi9FWkVpVC9IY2ErKyttcEtTa3B5Y3ZMZXZYdTlyUVhDQUFw
NmlNQ0FDTUZvQ0ZGVHZSZjVubDViVyt0d09PcnE2Z29MQy9sMllYV1hoUXNYdnZIR0c4UER3
M3YzN2hYNXVQRHhuajE3SEE1SGMzTXpQVWh2YTRGUWc0SWVJakFnUWpBYVF0UlU3MFcrcDlQ
S0xRNkhRNmZURVovVlhSd09odzlQSHgwZEZiWjdXd3VFR2hUMEVJRUJFWUxSRUtLbWVpL3lQ
ZjJ0dDk2aWVYcCtmajZScXU1U1dGajQ1cHR2T2h5T3Q5OSsyNGVuaXg1N1d3dUVHaFQwRUlF
QkVZTFJFS0ttZWk4VG5VL1B5Y25wNk9nZ1V0VmRyRllycmU2eWNlUEd1TGc0d2x4WFE2UThu
VjBMaEFjVTlCQ0JBUkdDMFJBU2hmVmU1R2ZRWTJOalI0NGN5YzNOblpEdXdOWUNBSURvSmxT
L09aTHA2WFJ1UFRNejg5TlBQNTNReGdOWUN3QUFvcDVJL0IwcEFBQ0F3SUNuQXdCQTlLQzhw
MGYrdFN2ZXJzTWhnaThZd2k0S0FBQWtVRUc5bDNBNnB0OTlUZklMWVZXRGdoNGlZbWRBMkhj
NjJ5TG51Qm9iRzQxR0k3MnVvN3U3VzNJNzBVRmpZMk4rZm41OGZQeVNKVXMrLy94emIzMjhq
UWJIY2FtcHFZSHRldUwzcm1zVUJ6dzkrczVJU1ZEUVEwU3NEUWg3bmd0YjVCeFhhbXBxVzF1
YjIrMDJtODMzMzMrL2p5MnJIWlBKZE9yVUtaZkxkZmp3NFprelowcjI4VFlhaEpDbm5ucHEw
NlpOZ2UwNlZKN096bGR3VE9VV0lxTzZDL3RwNFBUcDB5VWxKVHFkTGpzN20vOEh5SEZjVlZX
VlhxOWZ2SGl4Wkl1a0hzbUtOSkw1aVBEUHFxcXF4TVJFZmkzQ25KR1NDcU1BRlBRUUVXc0Q0
dHZUWlk3R3h4OS9URjBzSlNWRmNqc2N4eTFkdXJTOHZEd2pJNk84dkR5SStzT1B3K0ZvYUdq
d2RzbTF0OUc0Y3VWS2NuSnlmMzkvWURzTnE2ZUxLcmRJOW1UN2lMYS9aTW1TOTk1N3orVnl0
YlMwWkdkbjgzMWVlZVdWNGVIaEo1OThVckpGVWc5YmtVYk9zZkJyRlJRVXlGY1lCYUNnaDRo
WUd4RGZuaTdudU9ycjYrZk9uWnVZbUxoeDQwWmhIOUZickt1cml5Nm5UcDBhMUNNSUsvd1V5
bGRmZlNYWndkdG83Tml4WTgyYU5RSHZOK1NlUGpvNnludW9xSEtMNUdPMmoyajdXcTJXejZa
cDNSamFaMlJrUkNSQTJDS3BSMVNSaHQyWHBFSy9hMGtxakFKUTBFTkVyQTJJM3p4ZC9uRWRP
M1pzenB3NWt0dmgzNTZTZTFRWHc4UERCdzRjNEpNL2J3aEhZM1IwZE42OGVaMmRuUUh2TkZT
ZW5wYVdkdlRvVWFmVCtmcnJyN012ejRRZXg4ZkgyMncydnIyb3FLaXBxY25wZElxRXNWTDk2
aEZWcEdIM0phbUtYNHZQN21mTm1pWDhWeXlwTUFwQVFROFJzVFlndnQ5bE1vOXJmSHo4OU9u
VEN4Y3VyS3lzbE54T2RIajZvNDgrMnRQVDQzSzVHaG9haFBNcUl0alJxSyt2THkwdG5jeXVR
K1hwdGJXMUJvTWhKU1ZsOSs3ZDNqeWQreVdTZlFnaEd6WnNTRWhJNFA4OGMrYk04dVhMYVl1
M1hKNXRrZFFqcWtqRDdrdFNJYjhXUDUvKzVwdHY2dlY2M3dxakFCVDBFQkU3QXlMNVJoQzF5
QmtOMmprOVBYMzkrdlV1bDh2YmxvbjZQZjNkZDkvTnlNalFhclVGQlFVV2k0VTIraDBOUXNp
eVpjc09Ianc0bVYycjRGckdFS0ZTMlFBQTRBUGxmM09rRlBCMEFFRDBFYnVlRGdBQTBRYzhI
UUFBb2dmMWVicms5d3lZU0FFQUFLTEc3MGdsZHdkUER3TnlYbTYyai9BOENiaUVSZmhoYTNG
SXRtUm1abW8wbXN6TXpNT0hEOHZjVHJSbUlYS095MXRObUczYnRrWFpnT3pidHk4ckswdW4w
OTE2NjYzSGpoMlQ3QlBZR2VXWENYdDYxbzBzVWNEVFl3bzVReTNaWnpJbExNSVBXNHVEYlRF
WURDMHRMUzZYeTJLeEdBd0dtZHVoUk9zWjYvdTRKR3ZDZlBQTk4rbnA2VkUySUwvNzNlKysv
ZlpicDlPNWI5OCtINzlIQytDTThrc0lQWjJUVVhHRnJlNGlXZTlGcTlVdVdyU29yYTJOMzJ4
c1ZseUpCQUx6OUVtV3NBZy9iQzBPdG1YUm9rV3RyYTF1dC92bzBhTzMzbnFyek8xUVJHK0hx
S2x3NHZ2MFlHdkN1Rnl1Z29LQ1AvLzV6MUhtNlR4OWZYMDZuVTcwSzNkS1lHZVVYMExyNlg0
cnJvaXF1N0F0RkkvSDA5N2VQbXZXTEJMYkZWY2lnY0E4ZlpJbExNSVBXNHVEYmJGYXJjbkp5
UnpISlNjbmUvc3hkMHhWT0NIK1RnKzJKc3l6eno1TGYzUWFsWjcrNDQ4L0ZoVVZQZlBNTTVM
UEJuWkcrU1cwbnU2MzRvcW91Z3Zic21mUEhxUFJHQmNYeC8xY080V0w0WW9ya1VBQW5qNzVF
aFlLSXFwTUltekp5Y214V0N3dWw4dHNOdWZsNVUxb081SXBEbEcvdGZuTjAwVTFZZWhiT3lx
L1kvanFxNjh5TWpLcXE2dkh4c1o4OXd6c2pQSkdhRDFkK0tlY0NqQnNTMEpDUW5OenM4UGhN
SnZOZkorWXJiZ1NDUVRnNlpNdllhRUliQzBPVVV0U1VwTEZZbkc3M1MwdExUNW1QMk9rd2du
RnQzNGZOV0hVZnVBaTZ1cnFpb3FLdnZ6eVM5L2RBanVqZkJNK1Q1ZFpBVWJVOHVLTEx4b01C
b1BCc0dQSERyNVB6RlpjVVJidWwvQ05mdnRNdm9SRitLSDYyY29rd3BiNitucjZJWEwrL1Br
TkRRMzhpbksySXh5aTZQQjBPYWVIajFvMzZqMXdTVVNqTVRRMFJHU2NHNUpuMUVSUjM3V01B
QUFBdktHKzN4d0JBQUR3Qmp3ZEFBQ2lCM2c2QUFCRUR4SHQ2Wml2QndDQUNSSEM3MGpsZUhH
dytvQ2dJM3g5YVowV09TVXMySUllM2twOHFBNTJRT1RrSE96aFIwZW13bzVHWTJOamZuNStm
SHo4a2lWTGZQOTRtNjN1b3ZaNkw1S2pJYXJsd3VLdHp5UkhZOEtlYm1XQXAwYzNmSjBXT1NV
czJJSWVraVUrVkkyb2NJM3Y4OVBiNFVmTldjMlBoc2xrT25YcWxNdmxPbno0OE15Wk03MzFa
NnU3UkZPOUYzNDB2Tlg1RVNMWlovS2pFU3BQWjdQNEw3Lzhjc0dDQlZxdGRzR0NCZlJTZkxZ
UGZTeXM3a0tpNk94WEk1SjFXbnlYc0JBVjlHQmJWQTA3SUw3UFQyK0hIeDFuTlRzYURvZWpv
YUVoTnpkWHNqOWIzU1dhNnIwSVI4TmJuUjhoYkorZ2pFYjQ4dlM4dkR6Nis4L2EydG9GQ3ha
STlxRUlxN3Q0NndQQ0ExdW54WGNKQzdhZ0I5dWlhdGdCOFgxK2Vqdjg2RGlyUmFQQlR6NElm
OVF0aEszdUVrMzFYb1NqNGEzT2p4QzJUMUJHSTN5ZXJ0Rm9hSjJXNGVGaHJWWXIyWWV0N3NM
MkFXR0RyZFBpdDRRRlc5Q0RiVkV2a29Wci9PYnBrb2NmQldlMTVHZ01EdzhmT0hDQUw2NG5n
cTN1RWpYMVhyd1ZOV0xyQmJId2ZZSXlHaUgwOVBqNGVKdk54djhwbWFlTCtyRFZYUWhUeXdX
RURWR2RGamtsTE5pQ0hqNUtmS2dPeWNJMXZ0OTczZzVmMWY1RkVZM0dvNDgrMnRQVDQzSzVH
aG9hdk0wMjhMQ0hyL1lCWWM4TnlUby9JcnoxaWRBOGZjT0dEYlRpQ3YyenZiMDlMeTlQbzlI
azVlWHh2aURxdzFaM0lVd3RGeEEyUkhWYXVGOGlXY0tDTGVqaG84U0g2dkE5SUh5amNCWDI4
Q1hYVWlPaTBYajMzWGN6TWpLMFdtMUJRWUhGWXFHTk1qL0UrK2lwRmlUUERXRXRGeUtqM292
d3FZQ1ZvTjRMQUFCRUR4SDlteU1BQUFBVEFwNE9BQURSQXp3ZEFBQ2lCM2c2QUJFTnZxOENF
d0tlRG9BRUFUdHAwQzNZeHdhRHNpK080MTU1NVJWQ3lNc3Z2enlaRFhJY3QzUG56c2tMWThz
S05UWTJabVptYWpTYXpNek13NGNQZTl1NzZIb05sOHYxOU5OUDA5L1plOVBEMXFpUmMra0hX
OE5IVHEwYjlyamsxQUlLNERvVWVEb0FFc1NVcCtmbDVZMlBqK2ZtNWs3UzAzTnljcTVmdno1
SllXeFpJWVBCME5MUzRuSzVMQmFMNzd0MEN2ZGJXVm01ZVBIaVU2ZE9qWStQZSt2UDFxaVJv
NXl0NFNPbjFnMTdYUEpyQWNIVEFaZ3NrdThyN3BmRmlGNTc3VFdqMGFqUmFQaE1TazZXSjhy
Q2lPQVd1N201dWZRV3UxYXJOUzh2THlFaG9iS3lVcmhsNGQ3WmZaMCtmYnFrcEVTbjAyVm5a
L1Bab2w4NzREanV0dHR1MjdwMTYrMjMzMDQ3UzVabWV2WFZWMU5TVXBLVGsvZnUzZXR0Tzl1
MmJYdnBwWmY0bmJMYldieDRNUlhmMnRwNjY2MjMraGJHbHhWYXRHaFJhMnVyMiswK2V2U283
N1dFQnp0Nzl1elBQdnZNUndjZVlZMGFqdU1NQm9OZXI3L25ubnY0bjBPSzF2Sld3OGQzclJ2
MnVPVFhBb0tuQXpCWnZMMkxoTVdJcGs2ZHVtM2J0bE9uVHJuZGJyOHJTbmJnL2JxMnR0Ymhj
TlRWMVJVV0ZoSkM4dlB6NitycUhBNUhUVTJOc0wvdlVraExsaXg1NzczM1hDNVhTMHRMZG5h
Mi9DUGR2MzkvWEZ6Y2dRTUg2QWJabjN4ekhMZG56eDZIdzlIYzNPeXR3QVBIY1VORFExbFpX
VmV1WFBHMm5kZGVlNjJpb29JUVVsNWV2bnYzYmgrcWhHV0ZyRlpyY25JeXgzSEp5Y25zais5
Rkd2akhHbzJtdXJwYXI5ZlBtemZQeHkzTzZUOUZVWTJhaXhjdlZsWldGaGNYUzY0aVdjTkhj
anUrajB0K0xTQjRPZ0NUaFgwWHNjV0lQdnJvbzN2dnZUYzdPM3ZhdEdsLy9PTWZ2YTNvYmN1
am82TzhwOU5TU0E2SFE2ZlRFVUswV2kxZkhJbjJrVk1LU2F2VjhwazczMmRDUjBvZnM2V1pP
STRiSFIzMWZZQzBmZnYyN2M4Ly83eTM3Vnk2ZE1sZ01KdzdkODVnTUZ5K2ZObWJKRkZab1p5
Y0hJdkY0bks1ekdaelhsNmV6R05KVGs0Mm04MXV0N3V0clkzV05QZUdaSTBhcDlOSlh3c1di
elY4Zk5lNllZOUxmaTBnZURvQWs0VjlGMGtXSXlLRWpJMk5IVHQyVEsvWDB6OUZKWXhZMHRM
U2poNDk2blE2WDMvOWRkN1RhVDViVjFlWG41OVBDQ2tvS0tCNWVtMXRMZTBqdVhmUnZvcUtp
cHFhbXB4T1o4Qkg2aU5QOXpFeXd2Ymg0ZUg1OCtkNzJ3NGh4R1F5L2VwWHZ5b3ZML2VtaHkw
cmxKU1VaTEZZM0c1M1MwdUwvUG4wKys2N2ovZDBiNTh0dk5Xb3VYNzkrdGF0VzR1S2lpVFhZ
bXY0eUtsMXd4NlgvRnBBOEhRQUpndjNTNGhVTVNMNlZGeGMzUHo1ODk5NDR3MjZvcWlFRVV0
dGJhM0JZRWhKU2RtOWU3ZG9QajBuSjZlam80TVEwdEhSa1pPVGs1Q1FVRlZWNVczdjdMN09u
RG16ZlBseTJzSTNCakFYeEpabWt1L3BoSkNkTzNkNjJ3NGhwTFcxbGVPNDF0WldIM3FFREEw
TjFkZlgwODhvOCtmUGIyaG9rTE1XSWFTN3UzdlpzbVZhcmRab05EWTJOa3FLWjJ2VTBOVnZ1
dW1tNWN1WG56MTdWbkl0dG9hUFpLMGJ2OGNscHhZUTIrSVhlRG9BQ2pPaExBd0EzOERUQVZB
WWVEb0lJdkIwQUFDSUh1RHBBQUFRUGNEVEFRQWdlb0NuQXdCQTlBQlBCK3FncWFtcHViblo0
L0UwTnpjM05UWEpYTVgzczk0NkRBOFBtODFteWY0KzFnSWdFb0NuQTNYUTFOVDB4UmRmZlAv
OTkzLzV5MStDNWFyZXR2UDExMSt6VDhIS2dTcUFwd04xME5UVWRPYk1HWXZGY3ViTUdkNWVS
USthbXBxNnVyb3NGc3ZwMDZlOU5ZcTJ5ZTdvK3ZYcnJhMnRrcDV1c1ZnKy92ampnWUdCb0I0
WkFNRUVuZzdVUVZOVDA2VkxsL2dsM3loODBOVFVkUG55NWVIaFlmcGJQc2xHMFRiWkhmMzFy
My90N3U2V2ZHcDhmSHhnWU9EbzBhUEJPeXdBZ2d3OEhhaURwcWFtOGZIeFR6NzVaSHg4bkRk
Y2k4VXlQRHpNdXp4cjhXeWphSnVTTy9JMmJ6NCtQbjdod2dWNE9vaGs0T2xBSFFnZGxuOTgr
dlJwaThYUzFkVVZnS2VMakp0OWxuM1ExTlQwOGNjZm56OS9QcGdIQmtCUWdhY0RBRUQwQUU4
SEFJRG9BWjRPQUFEUkF6d2RBQUNpQjNnNkFBQkVEL0IwQUFDSUh2N1AwNjFXNjM0QUFBRHFo
NE9oQXdCQTFQRC9BWjRFWUVWMjZ4WHVBQUFBQUVsRlRrU3VRbUNDIiAvPjwvcD48cD4mbmJz
cDs8L3A+PHA+SWYgeW91IG5lZWQgb3RoZXIgY2hhcnRzLCBJIGNhbiB0cnkgdG8gcHJvZHVj
ZSB0aGVtLiA8L3A+PHA+Jm5ic3A7PC9wPjxwPkJSLDxiciAvPkNhcnN0ZW4uPC9wPjxwPiZu
YnNwOzwvcD48YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6IDJweCBzb2xpZCAjMzI1
RkJBOyBwYWRkaW5nLWxlZnQ6IDVweDttYXJnaW4tbGVmdDo1cHg7Ij4tLS0tLVVyc3ByJnV1
bWw7bmdsaWNoZSBOYWNocmljaHQtLS0tLTxiciAvPjxzdHJvbmc+QW46PC9zdHJvbmc+CUNh
cnN0ZW4gU2NoaWVycyAmbHQ7Y2Fyc3RlbkBzY2hpZXJzLmRlJmd0Ozsgemhlbnpob25nLmR1
YW5Ab3JhY2xlLmNvbTsgbGVyc2VrQHJlZGhhdC5jb207IDxiciAvPjxzdHJvbmc+Q0M6PC9z
dHJvbmc+CXhlbi1kZXZlbCAmbHQ7eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20mZ3Q7
OyBrb25yYWQud2lsayAmbHQ7a29ucmFkLndpbGtAb3JhY2xlLmNvbSZndDs7IDxiciAvPjxz
dHJvbmc+Vm9uOjwvc3Ryb25nPglLb25yYWQgUnplc3p1dGVrIFdpbGsgJmx0O2tvbnJhZEBk
YXJub2sub3JnJmd0OzxiciAvPjxzdHJvbmc+R2VzZW5kZXQ6PC9zdHJvbmc+CU1vIDI4LjEx
LjIwMTEgMTY6MzM8YnIgLz48c3Ryb25nPkJldHJlZmY6PC9zdHJvbmc+CVJlOiBbWGVuLWRl
dmVsXSBMb2FkIGluY3JlYXNlIGFmdGVyIG1lbW9yeSB1cGdyYWRlIChwYXJ0Mik8YnIgLz5P
biBGcmksIE5vdiAyNSwgMjAxMSBhdCAxMToxMTo1NVBNICswMTAwLCBDYXJzdGVuIFNjaGll
cnMgd3JvdGU6PGJyIC8+Jmd0OyBJIGdvdCB0aGUgdmFsdWVzIGluIERvbVUuIEkgd2lsbCBo
YXZlPGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7ICZuYnNwOyAtIGFwcm94LiA1JSBsb2FkIGluIERv
bVUgd2l0aCAyLjYuMzQgWGVuaWZpZWQgS2VybmVsPGJyIC8+Jmd0OyAmbmJzcDsgLSBhcHJv
eC4gMTUlIGxvYWQgaW4gRG9tVSB3aXRoIDIuNi4zMi40NiBKZXJlbXkgb3IgMy4xLjIgS2Vy
bmVsIHdpdGggb25lIGNhcmQgYXR0YWNoZWQ8YnIgLz4mZ3Q7ICZuYnNwOyAtIGFwcm94LiAz
MCUgbG9hZCBpbiBEb21VIHdpdGggMi42LjMyLjQ2IEplcmVteSBvciAzLjEuMiBLZXJuZWwg
d2l0aCB0d28gY2FyZHMgYXR0YWNoZWQ8YnIgLz48YnIgLz5IQSE8YnIgLz48YnIgLz5JIGp1
c3Qgd29uZGVyIGlmIHRoZSBpc3N1ZSBpcyB0aGF0IHRoZSByZXBvcnRpbmcgb2YgQ1BVIHNw
ZW50IGlzIHdyb25nLjxiciAvPkxhc3psbyBFcnNlayBhbmQgWmhlbnpob25nIER1YW4gaGF2
ZSBib3RoIHJlcG9ydGVkIGEgYnVnIGluIHRoZSBwdm9wczxiciAvPmNvZGUgd2hlbiBpdCBj
YW1lIHRvIGFjY291bnQgb2YgQ1BVIHRpbWUuPGJyIC8+PGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7
IEkgbG9va2VkIHRocm91Z2ggbXkgb2xkIG1haWxzIGZyb20geW91IGFuZCB5b3UgZXhwbGFp
bmVkIGFscmVhZHkgdGhlIG5lY2Vzc2l0eSBvZiBkb3VibGU8YnIgLz4mZ3Q7IGJvdW5jZSBi
dWZmZXJpbmcgKFBDSS0mZ3Q7YmVsb3cgNEdCLSZndDthYm92ZSA0R0IpLiBXaGF0IEkgZG9u
JiMzOTt0IHVuZGVyc3RhbmQgaXM6IHdoeSBkb2VzIHRoZTxiciAvPiZndDsgWGVuaWZpZWQg
a2VybmVsIG5vdCBoYXZlIHRoaXMga2luZCBvZiBpc3N1ZT88YnIgLz48YnIgLz5UaGF0IGlz
IGEgcHV6emxlLiBJdCBzaG91bGQgbm90LiBUaGUgY29kZSBpcyB2ZXJ5IG11Y2ggdGhlIHNh
bWUgLSBib3RoPGJyIC8+dXNlIHRoZSBnZW5lcmljIFNXSU9UTEIgd2hpY2ggaGFzIG5vdCBj
aGFuZ2VkIGZvciB5ZWFycy48YnIgLz4mZ3Q7IDxiciAvPiZndDsgVGhlIGRyaXZlciBpbiBx
dWVzdGlvbiBpcyBuZWFybHkgaWRlbnRpY2FsIGJldHdlZW4gdGhlIHR3byBrZXJuZWwgdmVy
c2lvbnMuIEl0IGlzIGluPGJyIC8+Jmd0OyBEcml2ZXJzL21lZGlhL2R2Yi90dHBjaSBieSB0
aGUgd2F5IGFuZCB3aGVuIEkgdW5kZXJzdG9vZCB0aGUgY29kZSByaWdodCwgdGhlIGFsbG8g
aW4gPGJyIC8+Jmd0OyBxdWVzdGlvbiBpczo8YnIgLz4mZ3Q7IDxiciAvPiZndDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8qIGFsbG9jYXRlIGFuZCBpbml0IGJ1ZmZlcnMgKi88
YnIgLz4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhdjcxMTAtJmd0O2RlYmlf
dmlydCA9IHBjaV9hbGxvY19jb25zaXN0ZW50KHBkZXYsIDgxOTIsICZhbXA7YXY3MTEwLSZn
dDtkZWJpX2J1cyk7PGJyIC8+PGJyIC8+R29vZC4gU28gaXQgYWxsb2NhdGVzIGl0IGR1cmlu
ZyBpbml0IGFuZCB1c2VzIGl0LjxiciAvPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IGlmICghYXY3MTEwLSZndDtkZWJpX3ZpcnQpPGJyIC8+Jmd0OyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGdvdG8gZXJyX3Nh
YTcxNDY2X3ZmcmVlXzQ7PGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7IGlzbiYjMzk7dCBpdD8gSSB0
aGluayB0aGUgY2FyZHMgYXJlIGNvbnN0YW50bHkgdHJhbnNmZXJyaW5nIHRoZSBzdHJlYW0g
cmVjZWl2ZWQgdGhyb3VnaCBETUEuIDxiciAvPjxiciAvPlllYWgsIGFuZCB0aGF0IG1lbW9y
eSBpcyBzZXQgYXNpZGUgZm9yIHRoZSBsaWZlIG9mIHRoZSBkcml2ZXIuIFNvIHRoZXJlPGJy
IC8+c2hvdWxkIGJlIG5vIGJvdW5jZSBidWZmZXJpbmcgaGFwcGVuaW5nIChhcyBpdCBhbGxv
Y2F0ZWQgdGhlIG1lbW9yeTxiciAvPmJlbG93IHRoZSA0R0IgbWFyaykuPGJyIC8+Jmd0OyA8
YnIgLz4mZ3Q7IEkgaGF2ZSBzZXQgZG9tMF9tZW09NTEyTSBieSB0aGUgd2F5LCBzaGFsbCBJ
IGNoYW5nZSB0aGF0IGluIHNvbWUgd2F5PzxiciAvPjxiciAvPkRvZXMgdGhlIHJlcG9ydGlu
ZyAoQ1BVIHVzYWdlIG9mIERvbVUpIGNoYW5nZSBpbiBhbnkgd2F5IHdpdGggdGhhdD88YnIg
Lz4mZ3Q7IDxiciAvPiZndDsgSSBjYW4gdHJ5IG91dCBzb21lIHRoaW5ncywgaWYgeW91IHdh
bnQgbWUgdG8uIEJ1dCBJIGhhdmUgbm8gaWRlYSB3aGF0IHRvIGRvIGFuZCB3aGVyZSB0bzxi
ciAvPiZndDsgc3RhcnQsIHNvIEkgcmVseSBvbiB5b3VyIGhlbHAuLi48YnIgLz4mZ3Q7IDxi
ciAvPiZndDsgQ2Fyc3Rlbi48YnIgLz4mZ3Q7IDxiciAvPiZndDsgLS0tLS1VcnNwcj9uZ2xp
Y2hlIE5hY2hyaWNodC0tLS0tPGJyIC8+Jmd0OyBWb246IHhlbi1kZXZlbC1ib3VuY2VzQGxp
c3RzLnhlbnNvdXJjZS5jb20gW21haWx0bzp4ZW4tZGV2ZWwtYm91bmNlc0BsaXN0cy54ZW5z
b3VyY2UuY29tXSBJbSBBdWZ0cmFnIHZvbiBLb25yYWQgUnplc3p1dGVrIFdpbGs8YnIgLz4m
Z3Q7IEdlc2VuZGV0OiBGcmVpdGFnLCAyNS4gTm92ZW1iZXIgMjAxMSAxOTo0MzxiciAvPiZn
dDsgQW46IENhcnN0ZW4gU2NoaWVyczxiciAvPiZndDsgQ2M6IHhlbi1kZXZlbDsga29ucmFk
LndpbGs8YnIgLz4mZ3Q7IEJldHJlZmY6IFJlOiBbWGVuLWRldmVsXSBMb2FkIGluY3JlYXNl
IGFmdGVyIG1lbW9yeSB1cGdyYWRlIChwYXJ0Mik8YnIgLz4mZ3Q7IDxiciAvPiZndDsgT24g
VGh1LCBOb3YgMjQsIDIwMTEgYXQgMDE6Mjg6NDRQTSArMDEwMCwgQ2Fyc3RlbiBTY2hpZXJz
IHdyb3RlOjxiciAvPiZndDsgJmd0OyBIZWxsbyBhZ2FpbiwgSSB3b3VsZCBsaWtlIHRvIGNv
bWUgYmFjayB0byB0aGF0IHRoaW5nLi4uc29ycnkgdGhhdCBJIGRpZCBub3QgaGF2ZSB0aGUg
dGltZSB1cCB0byBub3cuPGJyIC8+Jmd0OyAmZ3Q7IDxiciAvPiZndDsgJmd0OyA/PzxiciAv
PiZndDsgJmd0OyBXZSAobm93KSBzcGVhayBhYm91dDxiciAvPiZndDsgJmd0OyA8YnIgLz4m
Z3Q7ICZndDsgPz88YnIgLz4mZ3Q7ICZndDsgKglYZW4gNC4xLjI8YnIgLz4mZ3Q7ICZndDsg
KglEb20wIGlzIEplcmVteSYjMzk7cyAyLjYuMzIuNDYgNjQgYml0PGJyIC8+Jmd0OyAmZ3Q7
ICoJRG9tVSBpbiBxdWVzdGlvbiBpcyBub3cgMy4xLjIgNjQgYml0PGJyIC8+Jmd0OyAmZ3Q7
ICoJU2FtZSB0aGluZyBpZiBEb21VIGlzIGFsc28gMi42LjMyLjQ2PGJyIC8+Jmd0OyAmZ3Q7
ICoJRG9tVSBvd25zIHR3byBQQ0kgY2FyZHMgKERWQi1DKSB0aGF0IG8gRE1BPGJyIC8+Jmd0
OyAmZ3Q7ICoJTWFjaGluZSBoYXMgOEdCLCBEb20wIHBpbm5lZCBhdCA1MTJNQjxiciAvPiZn
dDsgJmd0OyA8YnIgLz4mZ3Q7ICZndDsgPz88YnIgLz4mZ3Q7ICZndDsgQXMgY29tcGFyZWQg
dG8gMi42LjM0IEtlcm5lbCB3aXRoIGJhY2twb3J0ZWQgcGF0Y2hlcywgdGhlIGxvYWQgb24g
dGhlIERvbVUgaXMgYXQgbGVhc3QgdHdpY2UgYXMgaGlnaC4gSXQ8YnIgLz4mZ3Q7ICZndDsg
PGJyIC8+Jmd0OyAmZ3Q7IHdpbGwgYmUgJnF1b3Q7Y2xvc2UgdG8gbm9ybWFsJnF1b3Q7IGlm
IEkgcmVkdWNlIHRoZSBtZW1vcnkgdXNlZCB0byA0R0IuPGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7
IFRoYXQgaXMgaW4gdGhlIGRvbTAgb3IganVzdCBpbiBnZW5lcmFsIG9uIHRoZSBtYWNoaW5l
PzxiciAvPiZndDsgJmd0OyA8YnIgLz4mZ3Q7ICZndDsgPz88YnIgLz4mZ3Q7ICZndDsgQXMg
eW91IGNhbiBzZWUgZnJvbSB0aGUgYXR0YWNobWVudCwgeW91IG9uY2UgaGFkIGFuIGlkZWEu
IFNvIHNob3VsZCB3ZSB0cnkgdG8gZmluZCBzb21ldGhpbmcuLi4/PGJyIC8+Jmd0OyA8YnIg
Lz4mZ3Q7IEkgdGhpbmsgdGhhdCB3YXMgdG8gaW5zdHJ1bWVudCBzd2lvdGxiIHRvIGdpdmUg
YW4gaWRlYSBvZiBob3c8YnIgLz4mZ3Q7IG9mdGVuIGl0IGlzIGNhbGxlZCBhbmQgYmFzaWNh
bGx5IGhhdmUgYSBtYXRyaXggb2YgaXRzIGxvYWQuIEFuZDxiciAvPiZndDsgZnJvbSB0aGVy
ZSBmaWd1cmUgb3V0IGlmIHRoZSBpc3N1ZSBpcyB0aGF0OjxiciAvPiZndDsgPGJyIC8+Jmd0
OyAmbmJzcDsxKS4gVGhlIGRyaXZlcnMgYWxsb2NvYXRlL2JvdW5jZS9kZWFsbG9jYXRlIGJ1
ZmZlcnMgb24gZXZlcnkgaW50ZXJydXB0PGJyIC8+Jmd0OyAmbmJzcDsgJm5ic3A7IChiYWQs
IGRyaXZlciBzaG91bGQgYmUgdXNpbmcgc29tZSBmb3JtIG9mIGRtYSBwb29sIGFuZCBtb3N0
IG9mIHRoZTxiciAvPiZndDsgJm5ic3A7ICZuYnNwOyBpdnR2IGRvIHRoYXQpPGJyIC8+Jmd0
OyA8YnIgLz4mZ3Q7ICZuYnNwOzIpLiBUaGUgYnVmZmVycyBhbGxvY2F0ZWQgdG8gdGhlIGRy
aXZlcnMgYXJlIGFib3ZlIHRoZSA0R0IgYW5kIHdlIGVuZDxiciAvPiZndDsgJm5ic3A7ICZu
YnNwOyB1cCBib3VuY2luZyBpdCBuZWVkbGVzc2x5LiBUaGF0IGNhbiBoYXBwZW4gaWYgdGhl
IGRvbTAgaGFzIG1vc3Qgb2Y8YnIgLz4mZ3Q7ICZuYnNwOyAmbmJzcDsgdGhlIHByZWNpb3Vz
IG1lbW9yeSB1bmRlciA0R0IuIEhvd2V2ZXIsIHRoYXQgaXMgdXN1YWxseSBub3QgdGhlIGNh
c2U8YnIgLz4mZ3Q7ICZuYnNwOyAmbmJzcDsgYXMgdGhlIGRvbWFpbiBpc3VzdWFsbHkgYWxs
b2NhdGVkIGZyb20gdGhlIHRvcCBvZiB0aGUgbWVtb3J5LiBUaGU8YnIgLz4mZ3Q7ICZuYnNw
OyAmbmJzcDsgZml4IGZvciB0aGF0IHdhcyB0byBzZXQgZG9tMF9tZW09bWF4OlhYLiAuLiBi
dXQgd2l0aCBEb20wIGtlcm5lbHM8YnIgLz4mZ3Q7ICZuYnNwOyAmbmJzcDsgYmVmb3JlIDMu
MSwgdGhlIHBhcmFtZXRlciB3b3VsZCBiZSBpZ25vcmVkLCBzbyB5b3UgaGFkIHRvIHVzZTxi
ciAvPiZndDsgJm5ic3A7ICZuYnNwOyAmIzM5O21lbT1YWCYjMzk7IG9uIHRoZSBMaW51eCBj
b21tYW5kIGxpbmUgYXMgd2VsbC48YnIgLz4mZ3Q7IDxiciAvPiZndDsgJm5ic3A7MykuIFdo
ZXJlIGRpZCB5b3UgZ2V0IHRoZSBsb2FkIHZhbHVlcz8gV2FzIGl0IGRvbTA/IG9yIGRvbVU/
PGJyIC8+Jmd0OyA8YnIgLz4mZ3Q7IDxiciAvPiZndDsgPGJyIC8+Jmd0OyAmZ3Q7IDxiciAv
PiZndDsgJmd0OyA/PzxiciAvPiZndDsgJmd0OyBDYXJzdGVuLjxiciAvPiZndDsgJmd0OyA/
PzxiciAvPiZndDsgJmd0OyAtLS0tLVVyc3ByPz9uZ2xpY2hlIE5hY2hyaWNodC0tLS0tPGJy
IC8+Jmd0OyAmZ3Q7IEFuOmtvbnJhZC53aWxrICZsdDtrb25yYWQud2lsa0BvcmFjbGUuY29t
Jmd0OzsgPGJyIC8+Jmd0OyAmZ3Q7IENDOmxpbnV4ICZsdDtsaW51eEBlaWtlbGVuYm9vbS5p
dCZndDs7IHhlbi1kZXZlbCAmbHQ7eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20mZ3Q7
OyA8YnIgLz4mZ3Q7ICZndDsgVm9uOkNhcnN0ZW4gU2NoaWVycyAmbHQ7Y2Fyc3RlbkBzY2hp
ZXJzLmRlJmd0OzxiciAvPiZndDsgJmd0OyBHZXNlbmRldDpNaSAyOS4wNi4yMDExIDIzOjE3
PGJyIC8+Jmd0OyAmZ3Q7IEJldHJlZmY6QVc6IFJlOiBSZTogUmU6IEFXOiBSZTogW1hlbi1k
ZXZlbF0gQVc6IExvYWQgaW5jcmVhc2UgYWZ0ZXIgbWVtb3J5IHVwZ3JhZGU/PGJyIC8+Jmd0
OyAmZ3Q7ICZndDsgTGV0cyBmaXJzdCBkbyB0aGUgYykgZXhwZXJpbWVudCBhcyB0aGF0IHdp
bGwgbGlrZWx5IGV4cGxhaW4geW91ciBsb2FkIGF2ZXJhZ2UgaW5jcmVhc2UuPGJyIC8+Jmd0
OyAmZ3Q7IC4uLjxiciAvPiZndDsgJmd0OyAmZ3Q7ICZndDtjKS4gSWYgeW91IHdhbnQgdG8g
c2VlIGlmIHRoZSBmYXVsdCBoZXJlIGxpZXMgaW4gdGhlIGJvdW5jZSBidWZmZXIgPGJyIC8+
Jmd0OyAmZ3Q7ICZndDsgYmVpbmcgdXNlZCBtb3JlPGJyIC8+Jmd0OyAmZ3Q7ICZndDsgJmd0
O29mdGVuIGluIHRoZSBEb21VIGIvYyB5b3UgaGF2ZSA4R0Igb2YgbWVtb3J5IG5vdyBhbmQg
eW91IGVuZCB1cCB1c2luZyA8YnIgLz4mZ3Q7ICZndDsgJmd0OyBtb3JlIHBhZ2VzPGJyIC8+
Jmd0OyAmZ3Q7ICZndDsgJmd0O3Bhc3QgNEdCIChpbiBEb21VKSwgSSBjYW4gY29vayB1cCBh
IHBhdGNoIHRvIGZpZ3VyZSB0aGlzIG91dC4gQnV0IGFuIDxiciAvPiZndDsgJmd0OyAmZ3Q7
IGVhc2llciB3YXkgaXM8YnIgLz4mZ3Q7ICZndDsgJmd0OyAmZ3Q7dG8ganVzdCBkbyAob24g
dGhlIFhlbiBoeXBlcnZpc29yIGxpbmUpOiBtZW09NEcgYW5kIHRoYXQgd2lsbCBtYWtlIDxi
ciAvPiZndDsgJmd0OyAmZ3Q7IHRoaW5rIHlvdSBvbmx5IGhhdmU8YnIgLz4mZ3Q7ICZndDsg
Jmd0OyAmZ3Q7NEdCIG9mIHBoeXNpY2FsIFJBTS4gPz9JZiB0aGUgbG9hZCBjb21lcyBiYWNr
IHRvIHRoZSBub3JtYWwgJnF1b3Q7YW1vdW50JnF1b3Q7IDxiciAvPiZndDsgJmd0OyAmZ3Q7
IHRoZW4gdGhlIGxpa2VseTxiciAvPiZndDsgJmd0OyAmZ3Q7ICZndDtjdWxwcml0IGlzIHRo
YXQgYW5kIHdlIGNhbiB0aGluayBvbiBob3cgdG8gZml4IHRoaXMuPGJyIC8+Jmd0OyAmZ3Q7
IDxiciAvPiZndDsgJmd0OyBZb3UgYXJlIG9uIHRoZSByaWdodCB0cmFjay4gTG9hZCB3YXMg
Z29pbmcgZG93biB0byAmcXVvdDtub3JtYWwmcXVvdDsgMTAlIHdoZW4gcmVkdWNpbmc8YnIg
Lz4mZ3Q7ICZndDsgWGVuIHRvIDRHQiBieSB0aGUgcGFyYW1ldGVyLiBMb2FkIHNlZW1zIHRv
IGJlIHN0aWxsIGEgbGl0dGxlLCBsaXR0bGUgYml0IGxvd2VyPGJyIC8+Jmd0OyAmZ3Q7IHdp
dGggWGVuaWZpZWQgS2VybmVsICg4LTklKSwgYnV0IHRoaXMgaXMgZHJhc3RpY2FsbHkgbG93
ZXIgdGhhbiB0aGUgMjAlIHdlIGhhZDxiciAvPiZndDsgJmd0OyBiZWZvcmUuPGJyIC8+Jmd0
OyA8YnIgLz4mZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnIgLz4mZ3Q7ICZndDsgWGVuLWRldmVsIG1haWxpbmcgbGlzdDxiciAv
PiZndDsgJmd0OyBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbTxiciAvPiZndDsgJmd0
OyBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWw8YnIgLz4mZ3Q7IDxiciAv
PiZndDsgPGJyIC8+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxiciAvPiZndDsgWGVuLWRldmVsIG1haWxpbmcgbGlzdDxiciAvPiZndDsg
WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb208YnIgLz4mZ3Q7IGh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbDxiciAvPiZndDsgPGJyIC8+PGJyIC8+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgLz5YZW4tZGV2ZWwg
bWFpbGluZyBsaXN0PGJyIC8+WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb208YnIgLz5o
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWw8YnIgLz48L2Jsb2NrcXVvdGU+
CjwvYm9keT4KPC9odG1sPg==
--=_NUWQF-8k01W10DsG1N5+EZa3ojZPE3HDoZ4sFFhq0eeh0y-I--



--===============7373466658977440381==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7373466658977440381==--



From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:59:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3bo-0005nx-GG; Mon, 28 Nov 2011 15:59:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV3bm-0005ns-I3
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:59:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322495881!54906183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30833 invoked from network); 28 Nov 2011 15:58:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 15:58:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9167630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 15:58:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 15:58:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV3bG-0004jc-Uf; Mon, 28 Nov 2011 15:58:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV3bG-0006bA-Sm;
	Mon, 28 Nov 2011 15:58:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.44970.879966.457764@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 15:58:34 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20179.44280.709362.448756@mariner.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-8-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-9-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-10-git-send-email-ian.jackson@eu.citrix.com>
	<1320055382.23193.38.camel@zakaz.uk.xensource.com>
	<20179.44280.709362.448756@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH RFC v2 09/13] libxl: introduce lock
	in	libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] [PATCH RFC v2 09/13] libxl: introduce lock in libxl_ctx"):
> Ian Campbell writes ("Re: [Xen-devel] [PATCH RFC v2 09/13] libxl: introduce lock in libxl_ctx"):
> > Since it is OK to take this lock recursively then it might be as well to
> > say so explicitly?
> > 
> > This is the first lock in libxl so I guess there isn't much of a locking
> > hierarchy yet. Are there any particular considerations which a caller
> > must make wrt its own locking?
> 
> I have added a comment explaining this.  No requirements are imposed
> on libxl's caller.  (Other than the reentrancy ones on callbacks.)

In fact this turns out not to be true.  I will document the
restrictions.  Good question BTW.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 15:59:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 15:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3bo-0005nx-GG; Mon, 28 Nov 2011 15:59:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV3bm-0005ns-I3
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 15:59:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322495881!54906183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30833 invoked from network); 28 Nov 2011 15:58:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 15:58:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9167630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 15:58:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 15:58:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV3bG-0004jc-Uf; Mon, 28 Nov 2011 15:58:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV3bG-0006bA-Sm;
	Mon, 28 Nov 2011 15:58:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.44970.879966.457764@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 15:58:34 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20179.44280.709362.448756@mariner.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-8-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-9-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-10-git-send-email-ian.jackson@eu.citrix.com>
	<1320055382.23193.38.camel@zakaz.uk.xensource.com>
	<20179.44280.709362.448756@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH RFC v2 09/13] libxl: introduce lock
	in	libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] [PATCH RFC v2 09/13] libxl: introduce lock in libxl_ctx"):
> Ian Campbell writes ("Re: [Xen-devel] [PATCH RFC v2 09/13] libxl: introduce lock in libxl_ctx"):
> > Since it is OK to take this lock recursively then it might be as well to
> > say so explicitly?
> > 
> > This is the first lock in libxl so I guess there isn't much of a locking
> > hierarchy yet. Are there any particular considerations which a caller
> > must make wrt its own locking?
> 
> I have added a comment explaining this.  No requirements are imposed
> on libxl's caller.  (Other than the reentrancy ones on callbacks.)

In fact this turns out not to be true.  I will document the
restrictions.  Good question BTW.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:04:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:04:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3gX-0006S2-8H; Mon, 28 Nov 2011 16:04:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV3gW-0006Rm-Du
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:04:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322496202!6104651!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8421 invoked from network); 28 Nov 2011 16:03:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:03:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9167790"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:03:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:03:22 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RV3ft-0004lG-UM;
	Mon, 28 Nov 2011 16:03:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RV3ft-0007zR-Tv;
	Mon, 28 Nov 2011 16:03:21 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10157-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 16:03:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10157: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10157 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10157/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 10145
 test-amd64-amd64-win         14 guest-start.2               fail pass in 10145

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2          fail in 10145 like 9955
 test-amd64-amd64-win         16 leak-check/check      fail in 10145 never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:04:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:04:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3gX-0006S2-8H; Mon, 28 Nov 2011 16:04:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV3gW-0006Rm-Du
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:04:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322496202!6104651!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8421 invoked from network); 28 Nov 2011 16:03:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:03:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9167790"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:03:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:03:22 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RV3ft-0004lG-UM;
	Mon, 28 Nov 2011 16:03:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RV3ft-0007zR-Tv;
	Mon, 28 Nov 2011 16:03:21 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10157-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 16:03:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10157: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10157 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10157/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install           fail REGR. vs. 9956
 test-amd64-i386-rhel6hvm-amd  7 redhat-install             fail REGR. vs. 9956
 test-amd64-amd64-xl-win       7 windows-install            fail REGR. vs. 9956
 test-amd64-i386-xl-win-vcpus1  7 windows-install           fail REGR. vs. 9956
 test-i386-i386-xl-win         7 windows-install            fail REGR. vs. 9956

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 10145
 test-amd64-amd64-win         14 guest-start.2               fail pass in 10145

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2          fail in 10145 like 9955
 test-amd64-amd64-win         16 leak-check/check      fail in 10145 never pass

version targeted for testing:
 xen                  95d4e2e0bed3
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 906 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3ta-0006io-2j; Mon, 28 Nov 2011 16:17:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tY-0006iE-7E
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4932 invoked from network); 28 Nov 2011 16:16:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456949"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:53 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRw015081;
	Mon, 28 Nov 2011 08:16:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: 844117c5a51e03a2fb0e454354b382c4e6d1a530
Message-ID: <844117c5a51e03a2fb0e.1322497081@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:01 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 04 of 12] xenalyze: Introduce generic summary
	functionality
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Allow generic processing of hvm traces to generate summary
information, connected to specific exit reasons.

This makes hvm_generic_postprocess the default handler (which
means it can be overriden in hvm_set_postprocess()), and
also replaces hvm_exception_nmi_generic_postprocess with the
hvm_generic_postprocess.

Also add a handler for exits without an HVM trace, and make
a header for hvm_pf_xen_summary().

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 47d436ca14d1 -r 844117c5a51e xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -953,6 +953,7 @@ char * hvm_trap_name[HVM_TRAP_MAX] = {
 
 
 enum {
+    HVM_EVENT_HANDLER_NONE = 0,
     HVM_EVENT_HANDLER_PF_XEN = 1,
     HVM_EVENT_HANDLER_PF_INJECT,
     HVM_EVENT_HANDLER_INJ_EXC,
@@ -984,7 +985,7 @@ enum {
     HVM_EVENT_HANDLER_MAX
 };
 char * hvm_event_handler_name[HVM_EVENT_HANDLER_MAX] = {
-    NULL,
+    "(no handler)",
     "pf_xen",
     "pf_inject",
     "inj_exc",
@@ -1343,6 +1344,7 @@ struct hvm_data {
         struct event_cycle_summary cr_write[CR_MAX];
         struct event_cycle_summary cr3_write_resyncs[RESYNCS_MAX+1];
         struct event_cycle_summary vmcall[HYPERCALL_MAX+1];
+        struct event_cycle_summary generic[HVM_EVENT_HANDLER_MAX];
         struct hvm_gi_struct {
             int count;
             struct cycle_summary runtime[GUEST_INTERRUPT_CASE_MAX];
@@ -3073,12 +3075,12 @@ int __hvm_set_summary_handler(struct hvm
     return -EINVAL;
 }
 
-void hvm_exception_nmi_generic_postprocess(struct hvm_data *h);
+void hvm_generic_postprocess(struct hvm_data *h);
 
 static int hvm_set_postprocess(struct hvm_data *h, void (*s)(struct hvm_data *h))
 {
     if ( h->post_process == NULL
-        || h->post_process == hvm_exception_nmi_generic_postprocess )
+        || h->post_process == hvm_generic_postprocess )
     {
         h->post_process = s;
         return 0;
@@ -3099,26 +3101,35 @@ static inline int is_valid_addr64(unsign
 
 void hvm_pf_xen_summary(struct hvm_data *h, void *d) {
     int i,j, k;
-    
+
+    printf("   page_fault\n");
     for(i=0; i<PF_XEN_MAX; i++)
     {
-        PRINT_SUMMARY(h->summary.pf_xen[i],
-                      "   %-25s ", pf_xen_name[i]);
+        if( pf_xen_name[i] )
+        {
+            PRINT_SUMMARY(h->summary.pf_xen[i],
+                          "     %-25s ", pf_xen_name[i]);
+        }
+        else
+        {
+            PRINT_SUMMARY(h->summary.pf_xen[i],
+                          "     [%23d] ", i);
+        }
         switch(i){
         case PF_XEN_NON_EMULATE:
             for(j=0; j<PF_XEN_NON_EMUL_MAX; j++)
                 PRINT_SUMMARY(h->summary.pf_xen_non_emul[j],
-                              "    *%-13s ", pf_xen_non_emul_name[j]);
+                              "      *%-13s ", pf_xen_non_emul_name[j]);
             break;
         case PF_XEN_EMULATE:
             for(j=0; j<PF_XEN_EMUL_MAX; j++) {
                 PRINT_SUMMARY(h->summary.pf_xen_emul[j],
-                              "    *%-13s ", pf_xen_emul_name[j]);
+                              "      *%-13s ", pf_xen_emul_name[j]);
                 if(j == PF_XEN_EMUL_EARLY_UNSHADOW) {
                     int k;
                     for(k=0; k<5; k++) {
                         PRINT_SUMMARY(h->summary.pf_xen_emul_early_unshadow[k],
-                                      "      +[%d] ", k);
+                                      "        +[%d] ", k);
                     }
                 }
             }
@@ -3126,14 +3137,14 @@ void hvm_pf_xen_summary(struct hvm_data 
         case PF_XEN_FIXUP:
             for(j=0; j<PF_XEN_FIXUP_MAX; j++) {
                 PRINT_SUMMARY(h->summary.pf_xen_fixup[j],
-                              "    *%-13s ", pf_xen_fixup_name[j]);
+                              "      *%-13s ", pf_xen_fixup_name[j]);
                 if(j == PF_XEN_FIXUP_UNSYNC ) {
                     for(k=0; k<PF_XEN_FIXUP_UNSYNC_RESYNC_MAX; k++) {
                         PRINT_SUMMARY(h->summary.pf_xen_fixup_unsync_resync[k],
-                                      "      +[%3d] ", k);
+                                      "       +[%3d] ", k);
                     }
                     PRINT_SUMMARY(h->summary.pf_xen_fixup_unsync_resync[k],
-                                  "      +[max] ");
+                                  "        +[max] ");
                 }
             }
             break;
@@ -4552,6 +4563,10 @@ void hvm_intr_process(struct hvm_data *h
         update_eip(&h->v->d->interrupt_eip_list, rip, 0, 0, NULL);
     }
 
+    /* Disable generic postprocessing */
+    /* FIXME: Do the summary stuff in a post-processor */
+    h->post_process = NULL;
+
     if(opt.summary_info) {
         if(opt.summary)
             hvm_set_summary_handler(h, hvm_intr_summary, NULL);
@@ -4631,25 +4646,6 @@ void hvm_pf_inject_process(struct record
     }
 }
 
-void hvm_exception_nmi_generic_postprocess(struct hvm_data *h)
-{
-    static int warned = 0;
-    if(opt.dump_cooked)
-    {
-        printf(" %s exnmi no_handler\n",
-               h->dump_header);
-    }
-
-    if(opt.summary_info)
-        update_summary(&h->summary.pf_xen[PF_XEN_NO_HANDLER],
-                       h->arc_cycles);
-
-    if(!warned) {
-        warned++;
-        fprintf(warn, "Strange, no handler for exnmi!\n");
-    }
-}
-
 void hvm_npf_process(struct record_info *ri, struct hvm_data *h)
 {
     struct {
@@ -4694,31 +4690,86 @@ void hvm_rdtsc_process(struct record_inf
     h->last_rdtsc = r->tsc;
 }
 
+void hvm_generic_summary(struct hvm_data *h, void *data)
+{
+    int evt = (int)data;
+
+    assert(evt < HVM_EVENT_HANDLER_MAX);
+
+    PRINT_SUMMARY(h->summary.generic[evt],
+                  "   %s ", hvm_event_handler_name[evt]);
+
+}
+
 void hvm_generic_postprocess(struct hvm_data *h)
 {
+    int evt = 0;
+    static unsigned registered[HVM_EVENT_HANDLER_MAX] = { 0 };
+
+    if ( h->inflight.generic.event )
+        evt = (h->inflight.generic.event - TRC_HVM_HANDLER) & ~TRC_64_FLAG;
+    else  {
+        static unsigned warned[HVM_EXIT_REASON_MAX] = { 0 };
+        /* Some exits we don't expect a handler; just return */
+        if(opt.svm_mode)
+        {
+        }
+        else
+        {
+            switch(h->exit_reason)
+            {
+                /* These just need us to go through the return path */
+            case EXIT_REASON_PENDING_INTERRUPT:
+            case EXIT_REASON_TPR_BELOW_THRESHOLD:
+                /* Not much to log now; may need later */
+            case EXIT_REASON_WBINVD:
+                return;
+            default:
+                break;
+            }
+        }
+        if ( !warned[h->exit_reason] )
+        {
+            /* If we aren't a known exception, warn and log results */
+            fprintf(warn, "%s: Strange, exit %x missing a handler\n",
+                    __func__, h->exit_reason);
+            warned[h->exit_reason]=1;
+        }
+    }
+
+    if ( evt > HVM_EVENT_HANDLER_MAX || evt < 0)
+    {
+        fprintf(warn, "%s: invalid hvm event %x\n",
+                __func__, h->inflight.generic.event);
+        error(ERR_RECORD, NULL);
+        return;
+    }
+
     if(opt.summary_info) {
+        update_summary(&h->summary.generic[evt],
+                       h->arc_cycles);
+
+        /* NB that h->exit_reason may be 0, so we offset by 1 */
+        if ( registered[evt] )
+        {
+            static unsigned warned[HVM_EXIT_REASON_MAX] = { 0 };
+            if ( registered[evt] != h->exit_reason+1 && !warned[h->exit_reason])
+            {
+                fprintf(warn, "%s: HVM evt %x in %x and %x!\n",
+                        __func__, evt, registered[evt]-1, h->exit_reason);
+                warned[h->exit_reason]=1;
+            }
+        }
+        else
+        {
+            int ret;
+            if((ret=__hvm_set_summary_handler(h, hvm_generic_summary, (void *)evt)))
+                fprintf(stderr, "%s: hvm_set_summary_handler returned %d\n",
+                        __func__, ret);
+            registered[evt]=h->exit_reason+1;
+        }
         /* HLT checked at hvm_vmexit_close() */
     }
-
-    if(opt.dump_cooked)
-    {
-        int i, evt = h->event_handler;
-
-        if(evt < HVM_EVENT_HANDLER_MAX)
-            printf(" %s %s [",
-                   h->dump_header,
-                   hvm_event_handler_name[evt]);
-        else
-            printf(" %s %d [",
-                   h->dump_header,
-                   evt);
-        
-        for(i=0; i<4; i++) {
-            printf(" %x", h->inflight.generic.d[i]);
-        }
-
-        printf(" ]\n");
-    }
 }
 
 void hvm_generic_dump(struct record_info *ri, char * prefix)
@@ -4878,18 +4929,15 @@ needs_vmexit:
     case TRC_HVM_CLTS:
     case TRC_HVM_LMSW:
     case TRC_HVM_LMSW64:
-    default:
-        if ( h->post_process != NULL )
-            fprintf(warn, "Strange, h->postprocess already set!\n");
-        /* Guest NMI should expect h->postprocess to be set.
-           FIXME: Handle NMI specially. */
+    case TRC_HVM_NMI:
     case TRC_HVM_CR_READ:
     case TRC_HVM_CR_READ64:
-    case TRC_HVM_NMI:
-        /* FIXME: Really should check to make sure post_process is NULL or the exnmi default... */
+    default:
+        if ( h->post_process != hvm_generic_postprocess )
+            fprintf(warn, "%s: Strange, h->postprocess set!\n",
+                __func__);
         h->inflight.generic.event = ri->event;
         bcopy(h->d, h->inflight.generic.d, sizeof(unsigned int) * 4); 
-        h->post_process = hvm_generic_postprocess;
         if(opt.dump_all)
         {
             hvm_generic_dump(ri, "]");
@@ -5168,18 +5216,8 @@ void hvm_vmexit_process(struct record_in
     h->wrmap_bf = 0;
     h->short_summary_done = 0;
 
-    h->post_process = NULL;
-    if(!opt.svm_mode)
-    {
-        switch(h->exit_reason)
-        {
-        case EXIT_REASON_EXCEPTION_NMI:
-            h->post_process = hvm_exception_nmi_generic_postprocess;
-            break;
-        default:
-            ;
-        }
-    }
+    h->post_process = hvm_generic_postprocess;
+    h->inflight.generic.event = 0;
   
     {
         struct time_struct t;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3ta-0006io-2j; Mon, 28 Nov 2011 16:17:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tY-0006iE-7E
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4932 invoked from network); 28 Nov 2011 16:16:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456949"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:53 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRw015081;
	Mon, 28 Nov 2011 08:16:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: 844117c5a51e03a2fb0e454354b382c4e6d1a530
Message-ID: <844117c5a51e03a2fb0e.1322497081@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:01 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 04 of 12] xenalyze: Introduce generic summary
	functionality
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Allow generic processing of hvm traces to generate summary
information, connected to specific exit reasons.

This makes hvm_generic_postprocess the default handler (which
means it can be overriden in hvm_set_postprocess()), and
also replaces hvm_exception_nmi_generic_postprocess with the
hvm_generic_postprocess.

Also add a handler for exits without an HVM trace, and make
a header for hvm_pf_xen_summary().

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 47d436ca14d1 -r 844117c5a51e xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -953,6 +953,7 @@ char * hvm_trap_name[HVM_TRAP_MAX] = {
 
 
 enum {
+    HVM_EVENT_HANDLER_NONE = 0,
     HVM_EVENT_HANDLER_PF_XEN = 1,
     HVM_EVENT_HANDLER_PF_INJECT,
     HVM_EVENT_HANDLER_INJ_EXC,
@@ -984,7 +985,7 @@ enum {
     HVM_EVENT_HANDLER_MAX
 };
 char * hvm_event_handler_name[HVM_EVENT_HANDLER_MAX] = {
-    NULL,
+    "(no handler)",
     "pf_xen",
     "pf_inject",
     "inj_exc",
@@ -1343,6 +1344,7 @@ struct hvm_data {
         struct event_cycle_summary cr_write[CR_MAX];
         struct event_cycle_summary cr3_write_resyncs[RESYNCS_MAX+1];
         struct event_cycle_summary vmcall[HYPERCALL_MAX+1];
+        struct event_cycle_summary generic[HVM_EVENT_HANDLER_MAX];
         struct hvm_gi_struct {
             int count;
             struct cycle_summary runtime[GUEST_INTERRUPT_CASE_MAX];
@@ -3073,12 +3075,12 @@ int __hvm_set_summary_handler(struct hvm
     return -EINVAL;
 }
 
-void hvm_exception_nmi_generic_postprocess(struct hvm_data *h);
+void hvm_generic_postprocess(struct hvm_data *h);
 
 static int hvm_set_postprocess(struct hvm_data *h, void (*s)(struct hvm_data *h))
 {
     if ( h->post_process == NULL
-        || h->post_process == hvm_exception_nmi_generic_postprocess )
+        || h->post_process == hvm_generic_postprocess )
     {
         h->post_process = s;
         return 0;
@@ -3099,26 +3101,35 @@ static inline int is_valid_addr64(unsign
 
 void hvm_pf_xen_summary(struct hvm_data *h, void *d) {
     int i,j, k;
-    
+
+    printf("   page_fault\n");
     for(i=0; i<PF_XEN_MAX; i++)
     {
-        PRINT_SUMMARY(h->summary.pf_xen[i],
-                      "   %-25s ", pf_xen_name[i]);
+        if( pf_xen_name[i] )
+        {
+            PRINT_SUMMARY(h->summary.pf_xen[i],
+                          "     %-25s ", pf_xen_name[i]);
+        }
+        else
+        {
+            PRINT_SUMMARY(h->summary.pf_xen[i],
+                          "     [%23d] ", i);
+        }
         switch(i){
         case PF_XEN_NON_EMULATE:
             for(j=0; j<PF_XEN_NON_EMUL_MAX; j++)
                 PRINT_SUMMARY(h->summary.pf_xen_non_emul[j],
-                              "    *%-13s ", pf_xen_non_emul_name[j]);
+                              "      *%-13s ", pf_xen_non_emul_name[j]);
             break;
         case PF_XEN_EMULATE:
             for(j=0; j<PF_XEN_EMUL_MAX; j++) {
                 PRINT_SUMMARY(h->summary.pf_xen_emul[j],
-                              "    *%-13s ", pf_xen_emul_name[j]);
+                              "      *%-13s ", pf_xen_emul_name[j]);
                 if(j == PF_XEN_EMUL_EARLY_UNSHADOW) {
                     int k;
                     for(k=0; k<5; k++) {
                         PRINT_SUMMARY(h->summary.pf_xen_emul_early_unshadow[k],
-                                      "      +[%d] ", k);
+                                      "        +[%d] ", k);
                     }
                 }
             }
@@ -3126,14 +3137,14 @@ void hvm_pf_xen_summary(struct hvm_data 
         case PF_XEN_FIXUP:
             for(j=0; j<PF_XEN_FIXUP_MAX; j++) {
                 PRINT_SUMMARY(h->summary.pf_xen_fixup[j],
-                              "    *%-13s ", pf_xen_fixup_name[j]);
+                              "      *%-13s ", pf_xen_fixup_name[j]);
                 if(j == PF_XEN_FIXUP_UNSYNC ) {
                     for(k=0; k<PF_XEN_FIXUP_UNSYNC_RESYNC_MAX; k++) {
                         PRINT_SUMMARY(h->summary.pf_xen_fixup_unsync_resync[k],
-                                      "      +[%3d] ", k);
+                                      "       +[%3d] ", k);
                     }
                     PRINT_SUMMARY(h->summary.pf_xen_fixup_unsync_resync[k],
-                                  "      +[max] ");
+                                  "        +[max] ");
                 }
             }
             break;
@@ -4552,6 +4563,10 @@ void hvm_intr_process(struct hvm_data *h
         update_eip(&h->v->d->interrupt_eip_list, rip, 0, 0, NULL);
     }
 
+    /* Disable generic postprocessing */
+    /* FIXME: Do the summary stuff in a post-processor */
+    h->post_process = NULL;
+
     if(opt.summary_info) {
         if(opt.summary)
             hvm_set_summary_handler(h, hvm_intr_summary, NULL);
@@ -4631,25 +4646,6 @@ void hvm_pf_inject_process(struct record
     }
 }
 
-void hvm_exception_nmi_generic_postprocess(struct hvm_data *h)
-{
-    static int warned = 0;
-    if(opt.dump_cooked)
-    {
-        printf(" %s exnmi no_handler\n",
-               h->dump_header);
-    }
-
-    if(opt.summary_info)
-        update_summary(&h->summary.pf_xen[PF_XEN_NO_HANDLER],
-                       h->arc_cycles);
-
-    if(!warned) {
-        warned++;
-        fprintf(warn, "Strange, no handler for exnmi!\n");
-    }
-}
-
 void hvm_npf_process(struct record_info *ri, struct hvm_data *h)
 {
     struct {
@@ -4694,31 +4690,86 @@ void hvm_rdtsc_process(struct record_inf
     h->last_rdtsc = r->tsc;
 }
 
+void hvm_generic_summary(struct hvm_data *h, void *data)
+{
+    int evt = (int)data;
+
+    assert(evt < HVM_EVENT_HANDLER_MAX);
+
+    PRINT_SUMMARY(h->summary.generic[evt],
+                  "   %s ", hvm_event_handler_name[evt]);
+
+}
+
 void hvm_generic_postprocess(struct hvm_data *h)
 {
+    int evt = 0;
+    static unsigned registered[HVM_EVENT_HANDLER_MAX] = { 0 };
+
+    if ( h->inflight.generic.event )
+        evt = (h->inflight.generic.event - TRC_HVM_HANDLER) & ~TRC_64_FLAG;
+    else  {
+        static unsigned warned[HVM_EXIT_REASON_MAX] = { 0 };
+        /* Some exits we don't expect a handler; just return */
+        if(opt.svm_mode)
+        {
+        }
+        else
+        {
+            switch(h->exit_reason)
+            {
+                /* These just need us to go through the return path */
+            case EXIT_REASON_PENDING_INTERRUPT:
+            case EXIT_REASON_TPR_BELOW_THRESHOLD:
+                /* Not much to log now; may need later */
+            case EXIT_REASON_WBINVD:
+                return;
+            default:
+                break;
+            }
+        }
+        if ( !warned[h->exit_reason] )
+        {
+            /* If we aren't a known exception, warn and log results */
+            fprintf(warn, "%s: Strange, exit %x missing a handler\n",
+                    __func__, h->exit_reason);
+            warned[h->exit_reason]=1;
+        }
+    }
+
+    if ( evt > HVM_EVENT_HANDLER_MAX || evt < 0)
+    {
+        fprintf(warn, "%s: invalid hvm event %x\n",
+                __func__, h->inflight.generic.event);
+        error(ERR_RECORD, NULL);
+        return;
+    }
+
     if(opt.summary_info) {
+        update_summary(&h->summary.generic[evt],
+                       h->arc_cycles);
+
+        /* NB that h->exit_reason may be 0, so we offset by 1 */
+        if ( registered[evt] )
+        {
+            static unsigned warned[HVM_EXIT_REASON_MAX] = { 0 };
+            if ( registered[evt] != h->exit_reason+1 && !warned[h->exit_reason])
+            {
+                fprintf(warn, "%s: HVM evt %x in %x and %x!\n",
+                        __func__, evt, registered[evt]-1, h->exit_reason);
+                warned[h->exit_reason]=1;
+            }
+        }
+        else
+        {
+            int ret;
+            if((ret=__hvm_set_summary_handler(h, hvm_generic_summary, (void *)evt)))
+                fprintf(stderr, "%s: hvm_set_summary_handler returned %d\n",
+                        __func__, ret);
+            registered[evt]=h->exit_reason+1;
+        }
         /* HLT checked at hvm_vmexit_close() */
     }
-
-    if(opt.dump_cooked)
-    {
-        int i, evt = h->event_handler;
-
-        if(evt < HVM_EVENT_HANDLER_MAX)
-            printf(" %s %s [",
-                   h->dump_header,
-                   hvm_event_handler_name[evt]);
-        else
-            printf(" %s %d [",
-                   h->dump_header,
-                   evt);
-        
-        for(i=0; i<4; i++) {
-            printf(" %x", h->inflight.generic.d[i]);
-        }
-
-        printf(" ]\n");
-    }
 }
 
 void hvm_generic_dump(struct record_info *ri, char * prefix)
@@ -4878,18 +4929,15 @@ needs_vmexit:
     case TRC_HVM_CLTS:
     case TRC_HVM_LMSW:
     case TRC_HVM_LMSW64:
-    default:
-        if ( h->post_process != NULL )
-            fprintf(warn, "Strange, h->postprocess already set!\n");
-        /* Guest NMI should expect h->postprocess to be set.
-           FIXME: Handle NMI specially. */
+    case TRC_HVM_NMI:
     case TRC_HVM_CR_READ:
     case TRC_HVM_CR_READ64:
-    case TRC_HVM_NMI:
-        /* FIXME: Really should check to make sure post_process is NULL or the exnmi default... */
+    default:
+        if ( h->post_process != hvm_generic_postprocess )
+            fprintf(warn, "%s: Strange, h->postprocess set!\n",
+                __func__);
         h->inflight.generic.event = ri->event;
         bcopy(h->d, h->inflight.generic.d, sizeof(unsigned int) * 4); 
-        h->post_process = hvm_generic_postprocess;
         if(opt.dump_all)
         {
             hvm_generic_dump(ri, "]");
@@ -5168,18 +5216,8 @@ void hvm_vmexit_process(struct record_in
     h->wrmap_bf = 0;
     h->short_summary_done = 0;
 
-    h->post_process = NULL;
-    if(!opt.svm_mode)
-    {
-        switch(h->exit_reason)
-        {
-        case EXIT_REASON_EXCEPTION_NMI:
-            h->post_process = hvm_exception_nmi_generic_postprocess;
-            break;
-        default:
-            ;
-        }
-    }
+    h->post_process = hvm_generic_postprocess;
+    h->inflight.generic.event = 0;
   
     {
         struct time_struct t;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tf-0006lt-Ft; Mon, 28 Nov 2011 16:17:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3td-0006iT-Sr
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:34 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322497014!4938512!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21087 invoked from network); 28 Nov 2011 16:16:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047135"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:55 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS1015081;
	Mon, 28 Nov 2011 08:16:54 -0800
MIME-Version: 1.0
X-Mercurial-Node: c9f583c65e0758a29a34c53e6dcb78abf70529cf
Message-ID: <c9f583c65e0758a29a34.1322497084@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:04 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 07 of 12] xenalyze: Handle MMIO records from
	different vmexits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

handle_mmio() is called in Xen as a generic way to do emulation;
in VMX, this at least includes not only EXCEPTION_NMI (page faults
in shadow mode) and NPF (nested page fault in HAP mode), but also
APIC_ACCESS and sometimes even CR_ACCESS.

This patch allows xenalyze to process and summarize mmio records
for different vmexits separately.

The change that causes the biggest number of line changes is pulling
the MMIO information out of pf_xen_extra and in its own struct, which
is kept separate from the inflight union.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 910605f7ade3 -r c9f583c65e07 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -1252,6 +1252,20 @@ char * pf_xen_name[PF_XEN_MAX] = {
 
 #define CORR_VA_INVALID (0ULL-1)
 
+enum {
+    NONPF_MMIO_APIC,
+    NONPF_MMIO_NPF,
+    NONPF_MMIO_UNKNOWN,
+    NONPF_MMIO_MAX
+};
+
+struct mmio_info {
+    unsigned long long gpa;
+    unsigned long long va; /* Filled only by shadow */
+    unsigned data;
+    unsigned data_valid:1, is_write:1;
+};
+
 struct pf_xen_extra {
     unsigned long long va;
     union {
@@ -1302,9 +1316,7 @@ struct pf_xen_extra {
     /* Flags */
     unsigned corr_valid:1,
         corr_is_kernel:1,
-        va_is_kernel:1,
-        mmio_data_valid:1,
-        mmio_is_write:1;
+        va_is_kernel:1;
 };
 
 struct pcpu_info;
@@ -1351,6 +1363,7 @@ struct hvm_data {
         struct event_cycle_summary cr3_write_resyncs[RESYNCS_MAX+1];
         struct event_cycle_summary vmcall[HYPERCALL_MAX+1];
         struct event_cycle_summary generic[HVM_EVENT_HANDLER_MAX];
+        struct event_cycle_summary mmio[NONPF_MMIO_MAX];
         struct hvm_gi_struct {
             int count;
             struct cycle_summary runtime[GUEST_INTERRUPT_CASE_MAX];
@@ -1367,33 +1380,37 @@ struct hvm_data {
     } summary;
 
     /* In-flight accumulation information */
-    union {
-        struct {
-            unsigned port:31,
-                is_write:1;
-            unsigned int val;
-        } io;
-        struct pf_xen_extra pf_xen;
-        struct {
-            unsigned cr;
-            unsigned long long val;
-            int repromote;
-        } cr_write;
-        struct {
-            unsigned addr;
-            unsigned long long val;
-        } msr;
-        struct {
-            unsigned int event;
-            uint32_t d[4];
-        } generic;
-        struct {
-            unsigned eax;
-        } vmcall;
-        struct {
-            unsigned vec;
-        } intr;
-    } inflight;
+    struct {
+        union {
+            struct {
+                unsigned port:31,
+                    is_write:1;
+                unsigned int val;
+            } io;
+            struct pf_xen_extra pf_xen;
+            struct {
+                unsigned cr;
+                unsigned long long val;
+                int repromote;
+            } cr_write;
+            struct {
+                unsigned addr;
+                unsigned long long val;
+            } msr;
+            struct {
+                unsigned int event;
+                uint32_t d[4];
+            } generic;
+            struct {
+                unsigned eax;
+            } vmcall;
+            struct {
+                unsigned vec;
+            } intr;
+        };
+        /* MMIO gets its separate area, since many exits may use it */
+        struct mmio_info mmio;
+    }inflight;
     int resyncs;
     void (*post_process)(struct hvm_data *);
     tsc_t exit_tsc, arc_cycles, entry_tsc;
@@ -3309,6 +3326,7 @@ void pf_preprocess(struct pf_xen_extra *
 
 void hvm_pf_xen_preprocess(unsigned event, struct hvm_data *h) {
     struct pf_xen_extra *e = &h->inflight.pf_xen;
+    struct mmio_info *m = &h->inflight.mmio;
     struct hvm_pf_xen_record *r = (typeof(r))h->d;
 
     if(event == TRC_HVM_PF_XEN64)
@@ -3325,7 +3343,7 @@ void hvm_pf_xen_preprocess(unsigned even
         e->error_code = r->x32.error_code;
     }
 
-    if(e->mmio_data_valid)
+    if(m->data_valid)
         e->pf_case = PF_XEN_MMIO;
     else
     {
@@ -3363,8 +3381,11 @@ void hvm_pf_xen_postprocess(struct hvm_d
     struct pf_xen_extra *e = &h->inflight.pf_xen;
 
     if(opt.summary_info) {
-        update_summary(&h->summary.pf_xen[e->pf_case],
-                       h->arc_cycles);
+        if(e->pf_case)
+            update_summary(&h->summary.pf_xen[e->pf_case],
+                           h->arc_cycles);
+        else
+            fprintf(warn, "Strange, pf_case 0!\n");
         switch(e->pf_case)
         {
         case PF_XEN_EMULATE:
@@ -3530,7 +3551,7 @@ struct outstanding_ipi *find_vec(struct 
 
 void hvm_vlapic_icr_handler(struct hvm_data *h)
 {
-    struct pf_xen_extra *e = &h->inflight.pf_xen;
+    struct mmio_info *m = &h->inflight.mmio;
     union {
         unsigned int val;
         struct {
@@ -3544,7 +3565,7 @@ void hvm_vlapic_icr_handler(struct hvm_d
                 _res2:2,
                 dest_shorthand:2;
         };
-    } icr = { .val = e->data };
+    } icr = { .val = m->data };
 
     void ipi_send(struct vcpu_data *ov, int vec)
     {
@@ -3590,7 +3611,7 @@ void hvm_vlapic_icr_handler(struct hvm_d
                    o->count);
     }
 
-    if(e->mmio_is_write) {
+    if(m->is_write) {
         if(opt.dump_all || opt.dump_cooked) {
             printf("              [vla] d%dv%d icr vec %d %s\n",
                    h->v->d->did, h->v->vid,
@@ -3657,9 +3678,9 @@ void hvm_vlapic_eoi_handler(struct hvm_d
 
 void hvm_vlapic_handler(struct hvm_data *h)
 {
-    struct pf_xen_extra *e = &h->inflight.pf_xen;
-
-    switch(e->gpa) {
+    struct mmio_info *m = &h->inflight.mmio;
+
+    switch(m->gpa) {
     case 0xfee00300:
         hvm_vlapic_icr_handler(h);
         break;
@@ -3673,14 +3694,56 @@ void hvm_vlapic_handler(struct hvm_data 
 /* Also called by shadow_mmio_postprocess */
 void enumerate_mmio(struct hvm_data *h)
 {
-    struct pf_xen_extra *e = &h->inflight.pf_xen;
-
-    if ( e->mmio_data_valid )
-        update_io_address(&h->summary.io.mmio, e->gpa, e->mmio_is_write, h->arc_cycles, e->va);
+    struct mmio_info *m = &h->inflight.mmio;
+
+    if ( m->data_valid )
+        update_io_address(&h->summary.io.mmio, m->gpa, m->is_write, h->arc_cycles, m->va);
+}
+
+void hvm_mmio_summary(struct hvm_data *h, void *data)
+{
+    int reason=(int)data;
+
+    PRINT_SUMMARY(h->summary.mmio[reason],
+                  "   mmio ");
 }
 
 void hvm_mmio_assist_postprocess(struct hvm_data *h)
 {
+    int reason;
+
+    switch(h->exit_reason)
+    {
+    case VMEXIT_NPF:
+    case EXIT_REASON_EPT_VIOLATION:
+        reason=NONPF_MMIO_NPF;
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        break;
+    case EXIT_REASON_APIC_ACCESS:
+        reason=NONPF_MMIO_APIC;
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        break;
+    default:
+    {
+        static int warned = 0;
+        if (!warned)
+        {
+            fprintf(stderr, "%s: Strange, MMIO with unexpected exit reason %d\n",
+                    __func__, h->exit_reason);
+            warned=1;
+        }
+        reason=NONPF_MMIO_UNKNOWN;
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        break;
+    }
+    }
+
+    if(opt.summary_info)
+    {
+        update_summary(&h->summary.mmio[reason],
+                       h->arc_cycles);
+    }
+
     if ( opt.with_mmio_enumeration )
         enumerate_mmio(h);
 }
@@ -3688,8 +3751,7 @@ void hvm_mmio_assist_postprocess(struct 
 #define HVM_IO_ASSIST_WRITE 0x200
 void hvm_mmio_assist_process(struct record_info *ri, struct hvm_data *h)
 {
-    struct pf_xen_extra *e = &h->inflight.pf_xen;
-
+    struct mmio_info *m = &h->inflight.mmio;
     union {
         struct {
             unsigned int gpa;
@@ -3711,30 +3773,32 @@ void hvm_mmio_assist_process(struct reco
     } mevt = { .event = ri->event };
 
     if(mevt.x64) {
-        e->gpa = r->x64.gpa;
-        e->data = r->x64.data;
+        m->gpa = r->x64.gpa;
+        m->data = r->x64.data;
         if(ri->extra_words*(sizeof(unsigned int))==sizeof(r->x64))
-            e->mmio_data_valid=1;
+            m->data_valid=1;
     } else {
-        e->gpa = r->x32.gpa;
-        e->data = r->x32.data;
+        m->gpa = r->x32.gpa;
+        m->data = r->x32.data;
         if(ri->extra_words*(sizeof(unsigned int))==sizeof(r->x32))
-            e->mmio_data_valid=1;
-    }
-
-    e->mmio_is_write = mevt.write;
+            m->data_valid=1;
+    }
+
+    m->is_write = mevt.write;
 
     if(opt.dump_all)
     {
-        if(e->mmio_data_valid)
-            printf("]%s mmio_assist %c gpa %llx data %x\n", h->dump_header,
-                   mevt.write?'w':'r', e->gpa, e->data);
+        if(m->data_valid)
+            printf("]%s mmio_assist %c gpa %llx data %x\n",
+                   h->dump_header,
+                   mevt.write?'w':'r',
+                   m->gpa, m->data);
         else
             printf("]%s mmio_assist %c gpa %llx (no data)\n", h->dump_header,
-                   mevt.write?'w':'r', e->gpa);
-    }
-
-    if((e->gpa & 0xfffff000) == 0xfee00000)
+                   mevt.write?'w':'r', m->gpa);
+    }
+
+    if((m->gpa & 0xfffff000) == 0xfee00000)
         hvm_vlapic_handler(h);
 
     /* Catch MMIOs that don't go through the shadow code; tolerate
@@ -5857,6 +5921,7 @@ void shadow_emulate_other_process(struct
 
     e->gfn = r.gfn;
     e->va = r.va;
+    e->pf_case = sevt.minor;
 
     pf_preprocess(e, h->v->guest_paging_levels);
 
@@ -6035,10 +6100,15 @@ void shadow_fixup_process(struct record_
 void shadow_mmio_postprocess(struct hvm_data *h)
 {
     struct pf_xen_extra *e = &h->inflight.pf_xen;
+    struct mmio_info *m = &h->inflight.mmio;
 
     if ( opt.summary_info )
     {
-        update_summary(&h->summary.pf_xen[e->pf_case], h->arc_cycles);
+        if(e->pf_case)
+            update_summary(&h->summary.pf_xen[e->pf_case],
+                           h->arc_cycles);
+        else
+            fprintf(warn, "Strange, pf_case 0!\n");
 
         hvm_update_short_summary(h, HVM_SHORT_SUMMARY_MMIO);
     }
@@ -6048,23 +6118,23 @@ void shadow_mmio_postprocess(struct hvm_
 
     if ( opt.dump_cooked )
     {
-        if(e->mmio_data_valid)
+        if(m->data_valid)
             printf(" %s %smmio %s va %llx eip %llx%s gpa %llx data %x\n",
                    h->dump_header,
                    (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
-                   e->mmio_is_write?"write":"read",
+                   m->is_write?"write":"read",
                    e->va,
                    h->rip, find_symbol(h->rip),
-                   e->gpa,
-                   e->data);
+                   m->gpa,
+                   m->data);
         else
             printf(" %s %smmio %s va %llx eip %llx%s gpa %llx (no data)\n",
                    h->dump_header,
                    (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
-                   e->mmio_is_write?"write":"read",
-                   e->va,
+                   m->is_write?"write":"read",
+                   m->va,
                    h->rip, find_symbol(h->rip),
-                   e->gpa);
+                   m->gpa);
     }
 
 }
@@ -6072,6 +6142,7 @@ void shadow_mmio_postprocess(struct hvm_
 void shadow_mmio_process(struct record_info *ri, struct hvm_data *h)
 {
     struct pf_xen_extra *e = &h->inflight.pf_xen;
+    struct mmio_info *m = &h->inflight.mmio;
     union {
         /* for PAE, guest_l1e may be 64 while guest_va may be 32;
            so put it first for alignment sake. */
@@ -6104,7 +6175,7 @@ void shadow_mmio_process(struct record_i
             error(ERR_RECORD, ri);
             return;
         }
-        e->va = r->gpl2.va;
+        e->va = m->va = r->gpl2.va;
         break;
     case 4:
         if(sizeof(r->gpl4) != ri->extra_words * 4)
@@ -6115,7 +6186,7 @@ void shadow_mmio_process(struct record_i
             error(ERR_RECORD, ri);
             return;
         }
-        e->va = r->gpl4.va;
+        e->va = m->va = r->gpl4.va;
         break;
     }
 
@@ -6135,7 +6206,11 @@ void shadow_propagate_postprocess(struct
 
     if ( opt.summary_info )
     {
-        update_summary(&h->summary.pf_xen[e->pf_case], h->arc_cycles);
+        if(e->pf_case)
+            update_summary(&h->summary.pf_xen[e->pf_case],
+                           h->arc_cycles);
+        else
+            fprintf(warn, "Strange, pf_case 0!\n");
 
         hvm_update_short_summary(h, HVM_SHORT_SUMMARY_PROPAGATE);
     }
@@ -6255,20 +6330,20 @@ void shadow_fault_generic_dump(unsigned 
 
 void shadow_fault_generic_postprocess(struct hvm_data *h)
 {
-    union shadow_event sevt = { .event = h->inflight.generic.event };
+    struct pf_xen_extra *e = &h->inflight.pf_xen;
+    if ( e->pf_case < PF_XEN_NOT_SHADOW || e->pf_case > PF_XEN_LAST_FAULT )
+    {
+        fprintf(warn, "%s: Strange, unexpected case %d\n",
+                __func__, e->pf_case);
+        return;
+    }
+
     if(opt.summary_info) {
-        update_summary(&h->summary.pf_xen[sevt.minor],
-                       h->arc_cycles);
+        update_summary(&h->summary.pf_xen[e->pf_case],
+                           h->arc_cycles);
 
         hvm_update_short_summary(h, HVM_SHORT_SUMMARY_PROPAGATE);
     }
-
-    if(opt.dump_cooked)
-    {
-        shadow_fault_generic_dump(h->inflight.generic.event,
-                            h->inflight.generic.d,
-                            " ", h->dump_header);
-    }
 }
 
 void shadow_fault_generic_process(struct record_info *ri, struct hvm_data *h)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tf-0006lt-Ft; Mon, 28 Nov 2011 16:17:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3td-0006iT-Sr
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:34 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322497014!4938512!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21087 invoked from network); 28 Nov 2011 16:16:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047135"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:55 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS1015081;
	Mon, 28 Nov 2011 08:16:54 -0800
MIME-Version: 1.0
X-Mercurial-Node: c9f583c65e0758a29a34c53e6dcb78abf70529cf
Message-ID: <c9f583c65e0758a29a34.1322497084@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:04 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 07 of 12] xenalyze: Handle MMIO records from
	different vmexits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

handle_mmio() is called in Xen as a generic way to do emulation;
in VMX, this at least includes not only EXCEPTION_NMI (page faults
in shadow mode) and NPF (nested page fault in HAP mode), but also
APIC_ACCESS and sometimes even CR_ACCESS.

This patch allows xenalyze to process and summarize mmio records
for different vmexits separately.

The change that causes the biggest number of line changes is pulling
the MMIO information out of pf_xen_extra and in its own struct, which
is kept separate from the inflight union.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 910605f7ade3 -r c9f583c65e07 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -1252,6 +1252,20 @@ char * pf_xen_name[PF_XEN_MAX] = {
 
 #define CORR_VA_INVALID (0ULL-1)
 
+enum {
+    NONPF_MMIO_APIC,
+    NONPF_MMIO_NPF,
+    NONPF_MMIO_UNKNOWN,
+    NONPF_MMIO_MAX
+};
+
+struct mmio_info {
+    unsigned long long gpa;
+    unsigned long long va; /* Filled only by shadow */
+    unsigned data;
+    unsigned data_valid:1, is_write:1;
+};
+
 struct pf_xen_extra {
     unsigned long long va;
     union {
@@ -1302,9 +1316,7 @@ struct pf_xen_extra {
     /* Flags */
     unsigned corr_valid:1,
         corr_is_kernel:1,
-        va_is_kernel:1,
-        mmio_data_valid:1,
-        mmio_is_write:1;
+        va_is_kernel:1;
 };
 
 struct pcpu_info;
@@ -1351,6 +1363,7 @@ struct hvm_data {
         struct event_cycle_summary cr3_write_resyncs[RESYNCS_MAX+1];
         struct event_cycle_summary vmcall[HYPERCALL_MAX+1];
         struct event_cycle_summary generic[HVM_EVENT_HANDLER_MAX];
+        struct event_cycle_summary mmio[NONPF_MMIO_MAX];
         struct hvm_gi_struct {
             int count;
             struct cycle_summary runtime[GUEST_INTERRUPT_CASE_MAX];
@@ -1367,33 +1380,37 @@ struct hvm_data {
     } summary;
 
     /* In-flight accumulation information */
-    union {
-        struct {
-            unsigned port:31,
-                is_write:1;
-            unsigned int val;
-        } io;
-        struct pf_xen_extra pf_xen;
-        struct {
-            unsigned cr;
-            unsigned long long val;
-            int repromote;
-        } cr_write;
-        struct {
-            unsigned addr;
-            unsigned long long val;
-        } msr;
-        struct {
-            unsigned int event;
-            uint32_t d[4];
-        } generic;
-        struct {
-            unsigned eax;
-        } vmcall;
-        struct {
-            unsigned vec;
-        } intr;
-    } inflight;
+    struct {
+        union {
+            struct {
+                unsigned port:31,
+                    is_write:1;
+                unsigned int val;
+            } io;
+            struct pf_xen_extra pf_xen;
+            struct {
+                unsigned cr;
+                unsigned long long val;
+                int repromote;
+            } cr_write;
+            struct {
+                unsigned addr;
+                unsigned long long val;
+            } msr;
+            struct {
+                unsigned int event;
+                uint32_t d[4];
+            } generic;
+            struct {
+                unsigned eax;
+            } vmcall;
+            struct {
+                unsigned vec;
+            } intr;
+        };
+        /* MMIO gets its separate area, since many exits may use it */
+        struct mmio_info mmio;
+    }inflight;
     int resyncs;
     void (*post_process)(struct hvm_data *);
     tsc_t exit_tsc, arc_cycles, entry_tsc;
@@ -3309,6 +3326,7 @@ void pf_preprocess(struct pf_xen_extra *
 
 void hvm_pf_xen_preprocess(unsigned event, struct hvm_data *h) {
     struct pf_xen_extra *e = &h->inflight.pf_xen;
+    struct mmio_info *m = &h->inflight.mmio;
     struct hvm_pf_xen_record *r = (typeof(r))h->d;
 
     if(event == TRC_HVM_PF_XEN64)
@@ -3325,7 +3343,7 @@ void hvm_pf_xen_preprocess(unsigned even
         e->error_code = r->x32.error_code;
     }
 
-    if(e->mmio_data_valid)
+    if(m->data_valid)
         e->pf_case = PF_XEN_MMIO;
     else
     {
@@ -3363,8 +3381,11 @@ void hvm_pf_xen_postprocess(struct hvm_d
     struct pf_xen_extra *e = &h->inflight.pf_xen;
 
     if(opt.summary_info) {
-        update_summary(&h->summary.pf_xen[e->pf_case],
-                       h->arc_cycles);
+        if(e->pf_case)
+            update_summary(&h->summary.pf_xen[e->pf_case],
+                           h->arc_cycles);
+        else
+            fprintf(warn, "Strange, pf_case 0!\n");
         switch(e->pf_case)
         {
         case PF_XEN_EMULATE:
@@ -3530,7 +3551,7 @@ struct outstanding_ipi *find_vec(struct 
 
 void hvm_vlapic_icr_handler(struct hvm_data *h)
 {
-    struct pf_xen_extra *e = &h->inflight.pf_xen;
+    struct mmio_info *m = &h->inflight.mmio;
     union {
         unsigned int val;
         struct {
@@ -3544,7 +3565,7 @@ void hvm_vlapic_icr_handler(struct hvm_d
                 _res2:2,
                 dest_shorthand:2;
         };
-    } icr = { .val = e->data };
+    } icr = { .val = m->data };
 
     void ipi_send(struct vcpu_data *ov, int vec)
     {
@@ -3590,7 +3611,7 @@ void hvm_vlapic_icr_handler(struct hvm_d
                    o->count);
     }
 
-    if(e->mmio_is_write) {
+    if(m->is_write) {
         if(opt.dump_all || opt.dump_cooked) {
             printf("              [vla] d%dv%d icr vec %d %s\n",
                    h->v->d->did, h->v->vid,
@@ -3657,9 +3678,9 @@ void hvm_vlapic_eoi_handler(struct hvm_d
 
 void hvm_vlapic_handler(struct hvm_data *h)
 {
-    struct pf_xen_extra *e = &h->inflight.pf_xen;
-
-    switch(e->gpa) {
+    struct mmio_info *m = &h->inflight.mmio;
+
+    switch(m->gpa) {
     case 0xfee00300:
         hvm_vlapic_icr_handler(h);
         break;
@@ -3673,14 +3694,56 @@ void hvm_vlapic_handler(struct hvm_data 
 /* Also called by shadow_mmio_postprocess */
 void enumerate_mmio(struct hvm_data *h)
 {
-    struct pf_xen_extra *e = &h->inflight.pf_xen;
-
-    if ( e->mmio_data_valid )
-        update_io_address(&h->summary.io.mmio, e->gpa, e->mmio_is_write, h->arc_cycles, e->va);
+    struct mmio_info *m = &h->inflight.mmio;
+
+    if ( m->data_valid )
+        update_io_address(&h->summary.io.mmio, m->gpa, m->is_write, h->arc_cycles, m->va);
+}
+
+void hvm_mmio_summary(struct hvm_data *h, void *data)
+{
+    int reason=(int)data;
+
+    PRINT_SUMMARY(h->summary.mmio[reason],
+                  "   mmio ");
 }
 
 void hvm_mmio_assist_postprocess(struct hvm_data *h)
 {
+    int reason;
+
+    switch(h->exit_reason)
+    {
+    case VMEXIT_NPF:
+    case EXIT_REASON_EPT_VIOLATION:
+        reason=NONPF_MMIO_NPF;
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        break;
+    case EXIT_REASON_APIC_ACCESS:
+        reason=NONPF_MMIO_APIC;
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        break;
+    default:
+    {
+        static int warned = 0;
+        if (!warned)
+        {
+            fprintf(stderr, "%s: Strange, MMIO with unexpected exit reason %d\n",
+                    __func__, h->exit_reason);
+            warned=1;
+        }
+        reason=NONPF_MMIO_UNKNOWN;
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        break;
+    }
+    }
+
+    if(opt.summary_info)
+    {
+        update_summary(&h->summary.mmio[reason],
+                       h->arc_cycles);
+    }
+
     if ( opt.with_mmio_enumeration )
         enumerate_mmio(h);
 }
@@ -3688,8 +3751,7 @@ void hvm_mmio_assist_postprocess(struct 
 #define HVM_IO_ASSIST_WRITE 0x200
 void hvm_mmio_assist_process(struct record_info *ri, struct hvm_data *h)
 {
-    struct pf_xen_extra *e = &h->inflight.pf_xen;
-
+    struct mmio_info *m = &h->inflight.mmio;
     union {
         struct {
             unsigned int gpa;
@@ -3711,30 +3773,32 @@ void hvm_mmio_assist_process(struct reco
     } mevt = { .event = ri->event };
 
     if(mevt.x64) {
-        e->gpa = r->x64.gpa;
-        e->data = r->x64.data;
+        m->gpa = r->x64.gpa;
+        m->data = r->x64.data;
         if(ri->extra_words*(sizeof(unsigned int))==sizeof(r->x64))
-            e->mmio_data_valid=1;
+            m->data_valid=1;
     } else {
-        e->gpa = r->x32.gpa;
-        e->data = r->x32.data;
+        m->gpa = r->x32.gpa;
+        m->data = r->x32.data;
         if(ri->extra_words*(sizeof(unsigned int))==sizeof(r->x32))
-            e->mmio_data_valid=1;
-    }
-
-    e->mmio_is_write = mevt.write;
+            m->data_valid=1;
+    }
+
+    m->is_write = mevt.write;
 
     if(opt.dump_all)
     {
-        if(e->mmio_data_valid)
-            printf("]%s mmio_assist %c gpa %llx data %x\n", h->dump_header,
-                   mevt.write?'w':'r', e->gpa, e->data);
+        if(m->data_valid)
+            printf("]%s mmio_assist %c gpa %llx data %x\n",
+                   h->dump_header,
+                   mevt.write?'w':'r',
+                   m->gpa, m->data);
         else
             printf("]%s mmio_assist %c gpa %llx (no data)\n", h->dump_header,
-                   mevt.write?'w':'r', e->gpa);
-    }
-
-    if((e->gpa & 0xfffff000) == 0xfee00000)
+                   mevt.write?'w':'r', m->gpa);
+    }
+
+    if((m->gpa & 0xfffff000) == 0xfee00000)
         hvm_vlapic_handler(h);
 
     /* Catch MMIOs that don't go through the shadow code; tolerate
@@ -5857,6 +5921,7 @@ void shadow_emulate_other_process(struct
 
     e->gfn = r.gfn;
     e->va = r.va;
+    e->pf_case = sevt.minor;
 
     pf_preprocess(e, h->v->guest_paging_levels);
 
@@ -6035,10 +6100,15 @@ void shadow_fixup_process(struct record_
 void shadow_mmio_postprocess(struct hvm_data *h)
 {
     struct pf_xen_extra *e = &h->inflight.pf_xen;
+    struct mmio_info *m = &h->inflight.mmio;
 
     if ( opt.summary_info )
     {
-        update_summary(&h->summary.pf_xen[e->pf_case], h->arc_cycles);
+        if(e->pf_case)
+            update_summary(&h->summary.pf_xen[e->pf_case],
+                           h->arc_cycles);
+        else
+            fprintf(warn, "Strange, pf_case 0!\n");
 
         hvm_update_short_summary(h, HVM_SHORT_SUMMARY_MMIO);
     }
@@ -6048,23 +6118,23 @@ void shadow_mmio_postprocess(struct hvm_
 
     if ( opt.dump_cooked )
     {
-        if(e->mmio_data_valid)
+        if(m->data_valid)
             printf(" %s %smmio %s va %llx eip %llx%s gpa %llx data %x\n",
                    h->dump_header,
                    (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
-                   e->mmio_is_write?"write":"read",
+                   m->is_write?"write":"read",
                    e->va,
                    h->rip, find_symbol(h->rip),
-                   e->gpa,
-                   e->data);
+                   m->gpa,
+                   m->data);
         else
             printf(" %s %smmio %s va %llx eip %llx%s gpa %llx (no data)\n",
                    h->dump_header,
                    (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
-                   e->mmio_is_write?"write":"read",
-                   e->va,
+                   m->is_write?"write":"read",
+                   m->va,
                    h->rip, find_symbol(h->rip),
-                   e->gpa);
+                   m->gpa);
     }
 
 }
@@ -6072,6 +6142,7 @@ void shadow_mmio_postprocess(struct hvm_
 void shadow_mmio_process(struct record_info *ri, struct hvm_data *h)
 {
     struct pf_xen_extra *e = &h->inflight.pf_xen;
+    struct mmio_info *m = &h->inflight.mmio;
     union {
         /* for PAE, guest_l1e may be 64 while guest_va may be 32;
            so put it first for alignment sake. */
@@ -6104,7 +6175,7 @@ void shadow_mmio_process(struct record_i
             error(ERR_RECORD, ri);
             return;
         }
-        e->va = r->gpl2.va;
+        e->va = m->va = r->gpl2.va;
         break;
     case 4:
         if(sizeof(r->gpl4) != ri->extra_words * 4)
@@ -6115,7 +6186,7 @@ void shadow_mmio_process(struct record_i
             error(ERR_RECORD, ri);
             return;
         }
-        e->va = r->gpl4.va;
+        e->va = m->va = r->gpl4.va;
         break;
     }
 
@@ -6135,7 +6206,11 @@ void shadow_propagate_postprocess(struct
 
     if ( opt.summary_info )
     {
-        update_summary(&h->summary.pf_xen[e->pf_case], h->arc_cycles);
+        if(e->pf_case)
+            update_summary(&h->summary.pf_xen[e->pf_case],
+                           h->arc_cycles);
+        else
+            fprintf(warn, "Strange, pf_case 0!\n");
 
         hvm_update_short_summary(h, HVM_SHORT_SUMMARY_PROPAGATE);
     }
@@ -6255,20 +6330,20 @@ void shadow_fault_generic_dump(unsigned 
 
 void shadow_fault_generic_postprocess(struct hvm_data *h)
 {
-    union shadow_event sevt = { .event = h->inflight.generic.event };
+    struct pf_xen_extra *e = &h->inflight.pf_xen;
+    if ( e->pf_case < PF_XEN_NOT_SHADOW || e->pf_case > PF_XEN_LAST_FAULT )
+    {
+        fprintf(warn, "%s: Strange, unexpected case %d\n",
+                __func__, e->pf_case);
+        return;
+    }
+
     if(opt.summary_info) {
-        update_summary(&h->summary.pf_xen[sevt.minor],
-                       h->arc_cycles);
+        update_summary(&h->summary.pf_xen[e->pf_case],
+                           h->arc_cycles);
 
         hvm_update_short_summary(h, HVM_SHORT_SUMMARY_PROPAGATE);
     }
-
-    if(opt.dump_cooked)
-    {
-        shadow_fault_generic_dump(h->inflight.generic.event,
-                            h->inflight.generic.d,
-                            " ", h->dump_header);
-    }
 }
 
 void shadow_fault_generic_process(struct record_info *ri, struct hvm_data *h)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3td-0006kH-3N; Mon, 28 Nov 2011 16:17:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tb-0006jI-LA
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:32 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322496999!50058610!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25290 invoked from network); 28 Nov 2011 16:16:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047142"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:57 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS3015081;
	Mon, 28 Nov 2011 08:16:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 46c366d71c74a60173a5b914702ba8b12efdcf61
Message-ID: <46c366d71c74a60173a5.1322497086@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:06 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 09 of 12] xenalyze: Sort cr3 enumerated values
	by start time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a new sort method to sort by start time, rather than by total
time, and make it the default.

Really should make it command-line switchable, but I'll leave that
improvement until later.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 3c6da152c844 -r 46c366d71c74 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -4144,7 +4144,7 @@ void cr3_dump_list(struct cr3_value_stru
     struct cr3_value_struct **qsort_array;
     int i, N=0;
 
-    int cr3_compare(const void *_a, const void *_b) {
+    int cr3_compare_total(const void *_a, const void *_b) {
         struct cr3_value_struct *a=*(typeof(&a))_a;
         struct cr3_value_struct *b=*(typeof(&a))_b;
 
@@ -4161,6 +4161,18 @@ void cr3_dump_list(struct cr3_value_stru
             return -1;
     }
 
+    int cr3_compare_start(const void *_a, const void *_b) {
+        struct cr3_value_struct *a=*(typeof(&a))_a;
+        struct cr3_value_struct *b=*(typeof(&a))_b;
+
+        if(a->first_time > b->first_time)
+            return 1;
+        else if(b->first_time == a->first_time)
+            return 0;
+        else
+            return -1;
+    }
+
     if(!head)
         return;
 
@@ -4180,7 +4192,7 @@ void cr3_dump_list(struct cr3_value_stru
 
     /* Sort the array by time */
     qsort(qsort_array, N, sizeof(struct eip_list_struct *),
-          cr3_compare);
+          cr3_compare_start);
 
     /* WARNING: don't use N after this point unless you copy this variable */
 #if 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3td-0006kH-3N; Mon, 28 Nov 2011 16:17:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tb-0006jI-LA
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:32 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322496999!50058610!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25290 invoked from network); 28 Nov 2011 16:16:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047142"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:57 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS3015081;
	Mon, 28 Nov 2011 08:16:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 46c366d71c74a60173a5b914702ba8b12efdcf61
Message-ID: <46c366d71c74a60173a5.1322497086@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:06 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 09 of 12] xenalyze: Sort cr3 enumerated values
	by start time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a new sort method to sort by start time, rather than by total
time, and make it the default.

Really should make it command-line switchable, but I'll leave that
improvement until later.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 3c6da152c844 -r 46c366d71c74 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -4144,7 +4144,7 @@ void cr3_dump_list(struct cr3_value_stru
     struct cr3_value_struct **qsort_array;
     int i, N=0;
 
-    int cr3_compare(const void *_a, const void *_b) {
+    int cr3_compare_total(const void *_a, const void *_b) {
         struct cr3_value_struct *a=*(typeof(&a))_a;
         struct cr3_value_struct *b=*(typeof(&a))_b;
 
@@ -4161,6 +4161,18 @@ void cr3_dump_list(struct cr3_value_stru
             return -1;
     }
 
+    int cr3_compare_start(const void *_a, const void *_b) {
+        struct cr3_value_struct *a=*(typeof(&a))_a;
+        struct cr3_value_struct *b=*(typeof(&a))_b;
+
+        if(a->first_time > b->first_time)
+            return 1;
+        else if(b->first_time == a->first_time)
+            return 0;
+        else
+            return -1;
+    }
+
     if(!head)
         return;
 
@@ -4180,7 +4192,7 @@ void cr3_dump_list(struct cr3_value_stru
 
     /* Sort the array by time */
     qsort(qsort_array, N, sizeof(struct eip_list_struct *),
-          cr3_compare);
+          cr3_compare_start);
 
     /* WARNING: don't use N after this point unless you copy this variable */
 #if 0

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tc-0006k2-JB; Mon, 28 Nov 2011 16:17:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3ta-0006iH-50
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:30 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322497010!3423854!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17133 invoked from network); 28 Nov 2011 16:16:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047104"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:52 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRv015081;
	Mon, 28 Nov 2011 08:16:51 -0800
MIME-Version: 1.0
X-Mercurial-Node: 47d436ca14d1394268d28996edf31ef0345bf61b
Message-ID: <47d436ca14d1394268d2.1322497080@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:00 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 03 of 12] xenalyze: Function-ize setting of
	h->post_process
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce hvm_set_postprocess, so that we can make changes
to the setting and warning all in one place.

Special-case hvm_exception_nmi_generic_postprocess for now
to avoid regression; will get rid of it in the next c/s

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 6650e492be5d -r 47d436ca14d1 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -3073,6 +3073,20 @@ int __hvm_set_summary_handler(struct hvm
     return -EINVAL;
 }
 
+void hvm_exception_nmi_generic_postprocess(struct hvm_data *h);
+
+static int hvm_set_postprocess(struct hvm_data *h, void (*s)(struct hvm_data *h))
+{
+    if ( h->post_process == NULL
+        || h->post_process == hvm_exception_nmi_generic_postprocess )
+    {
+        h->post_process = s;
+        return 0;
+    }
+    else
+        return 1;
+}
+
 #define SIGN_EXTENDED_BITS (~((1ULL<<48)-1))
 #define HIGH_BIT(_v) ((_v) & (1ULL<<47))
 static inline int is_valid_addr64(unsigned long long va)
@@ -3416,7 +3430,8 @@ void hvm_pf_xen_process(struct record_in
                    e->pt_index[4]);
     }
 
-    h->post_process = hvm_pf_xen_postprocess;
+    if ( hvm_set_postprocess(h, hvm_pf_xen_postprocess) )
+         fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 char * hvm_vlapic_icr_dest_shorthand_name[4] = {
@@ -3703,10 +3718,9 @@ void hvm_mmio_assist_process(struct reco
     if((e->gpa & 0xfffff000) == 0xfee00000)
         hvm_vlapic_handler(h);
 
-    /* Catch MMIOs that don't go through the shadow code */
-    if ( h->post_process == NULL )
-        h->post_process = hvm_mmio_assist_postprocess;
-        
+    /* Catch MMIOs that don't go through the shadow code; tolerate
+     * failures to set (probably shadow_mmio) */
+    hvm_set_postprocess(h, hvm_mmio_assist_postprocess);
 }
 
 void hvm_inj_virq_process(struct record_info *ri, struct hvm_data *h) {
@@ -3889,10 +3903,12 @@ void hvm_io_assist_process(struct record
 
     if(mevt.write) {
         h->inflight.io.is_write = 1;
-        h->post_process = hvm_io_write_postprocess;
+        if ( hvm_set_postprocess(h, hvm_io_write_postprocess) )
+             fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
     } else {
         h->inflight.io.is_write = 0;
-        h->post_process = hvm_io_read_postprocess;
+        if ( hvm_set_postprocess(h, hvm_io_read_postprocess) )
+             fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
     }
 
     if(opt.dump_all)
@@ -4234,7 +4250,6 @@ void hvm_cr_write_postprocess(struct hvm
     }
 }
 
-void hvm_exception_nmi_generic_postprocess(struct hvm_data *h);
 void hvm_cr_write_process(struct record_info *ri, struct hvm_data *h)
 {
     union {
@@ -4258,13 +4273,11 @@ void hvm_cr_write_process(struct record_
         h->inflight.cr_write.val = val = r->x32.val;
     }
 
-    /* In real mode, cr accesses may cause EXNMI vmexits */
-    if ( !h->post_process
-         || (!opt.svm_mode
-             && h->post_process == hvm_exception_nmi_generic_postprocess) )
-        h->post_process = hvm_cr_write_postprocess;
-    else
-        fprintf(warn, "Strange, h->postprocess already set!\n");
+    /* In vmx, in real mode, cr accesses may cause EXNMI vmexits.
+     * Account them under that heading; otherwise, complain */
+    if ( hvm_set_postprocess(h, hvm_cr_write_postprocess) )
+        fprintf(warn, "%s: Strange, h->postprocess already set!\n",
+            __func__);
 
     if(opt.dump_all)
     {
@@ -4326,7 +4339,8 @@ void hvm_msr_write_process(struct record
                r->addr, r->val);
     }
 
-    h->post_process = hvm_msr_write_postprocess;
+    if ( hvm_set_postprocess(h, hvm_msr_write_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 /* msr_read */
@@ -4371,7 +4385,8 @@ void hvm_msr_read_process(struct record_
                r->addr, r->val);
     }
 
-    h->post_process = hvm_msr_read_postprocess;
+    if ( hvm_set_postprocess(h, hvm_msr_read_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void hvm_vmcall_summary(struct hvm_data *h, void *d)
@@ -4421,10 +4436,10 @@ void hvm_vmcall_process(struct record_in
                    r->eax);
     }
 
-    if(opt.summary) {
-        h->inflight.vmcall.eax = r->eax;
-        h->post_process = hvm_vmcall_postprocess;
-    }
+    h->inflight.vmcall.eax = r->eax;
+
+    if ( hvm_set_postprocess(h, hvm_vmcall_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void hvm_inj_exc_process(struct record_info *ri, struct hvm_data *h)
@@ -5640,8 +5655,8 @@ void shadow_emulate_process(struct recor
                flag_string(e), e->flags,
                e->pt_level, e->corresponding_va);
 
-    h->post_process = shadow_emulate_postprocess;
-
+    if ( hvm_set_postprocess(h, shadow_emulate_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 struct shadow_emulate_other {
@@ -5776,7 +5791,8 @@ void shadow_unsync_process(struct record
                e->pt_level,
                e->corresponding_va);
 
-    h->post_process = shadow_unsync_postprocess;
+    if ( hvm_set_postprocess(h, shadow_unsync_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 #endif
 
@@ -5802,7 +5818,8 @@ void shadow_emulate_other_process(struct
                e->gfn,
                e->va);
 
-    h->post_process = shadow_fault_generic_postprocess;
+    if ( hvm_set_postprocess(h, shadow_fault_generic_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void shadow_fixup_postprocess(struct hvm_data *h)
@@ -5962,7 +5979,8 @@ void shadow_fixup_process(struct record_
                    flag_string(e));
     }
 
-    h->post_process = shadow_fixup_postprocess;
+    if ( hvm_set_postprocess(h, shadow_fixup_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void shadow_mmio_postprocess(struct hvm_data *h)
@@ -6058,7 +6076,8 @@ void shadow_mmio_process(struct record_i
                 (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
                 e->va);
 
-    h->post_process = shadow_mmio_postprocess;
+    if ( hvm_set_postprocess(h, shadow_mmio_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void shadow_propagate_postprocess(struct hvm_data *h)
@@ -6150,7 +6169,8 @@ void shadow_propagate_process(struct rec
                e->va, e->gl1e, e->flags,
                flag_string(e));
 
-    h->post_process = shadow_propagate_postprocess;
+    if ( hvm_set_postprocess(h, shadow_propagate_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void shadow_fault_generic_dump(unsigned int event, uint32_t *d, char *prefix,
@@ -6216,7 +6236,8 @@ void shadow_fault_generic_process(struct
                                   "]", ri->dump_header);
 
     h->inflight.pf_xen.pf_case = sevt.minor;
-    h->post_process = shadow_fault_generic_postprocess;
+    if ( hvm_set_postprocess(h, shadow_fault_generic_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void shadow_resync_process(struct record_info *ri, struct hvm_data *h)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tf-0006lg-2J; Mon, 28 Nov 2011 16:17:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3td-0006im-AG
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:33 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5145 invoked from network); 28 Nov 2011 16:16:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456955"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:58 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS4015081;
	Mon, 28 Nov 2011 08:16:57 -0800
MIME-Version: 1.0
X-Mercurial-Node: dab5ba28630aa9148958284eaeb4cf9f6ae2c212
Message-ID: <dab5ba28630aa9148958.1322497087@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:07 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 10 of 12] xenalyze: Enable more cr3 output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Some of the cr3 ouptut was #if 0'd out.  Put it back in.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 46c366d71c74 -r dab5ba28630a xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -4220,8 +4220,7 @@ void cr3_dump_list(struct cr3_value_stru
         print_cycle_percent_summary(&p->hv_time, p->run_time, desc);
 
         hvm_short_summary(&p->hvm, p->run_time, "           + ");
-#if 0
-        printf("            Seen: %4lu.%09lu-%4lu.%09lu switch %d flush %d\n",
+        printf("            Seen: %4u.%09u-%4u.%09u switch %d flush %d\n",
                first.s, first.ns,
                last.s, last.ns,
                p->switch_count, p->flush_count);
@@ -4231,7 +4230,6 @@ void cr3_dump_list(struct cr3_value_stru
                    p->destroy.switch_count,
                    p->destroy.fixup_user,
                    p->destroy.emulate_corr_user);
-#endif
     }
 
     free(qsort_array);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tc-0006k2-JB; Mon, 28 Nov 2011 16:17:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3ta-0006iH-50
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:30 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322497010!3423854!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17133 invoked from network); 28 Nov 2011 16:16:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047104"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:52 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRv015081;
	Mon, 28 Nov 2011 08:16:51 -0800
MIME-Version: 1.0
X-Mercurial-Node: 47d436ca14d1394268d28996edf31ef0345bf61b
Message-ID: <47d436ca14d1394268d2.1322497080@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:00 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 03 of 12] xenalyze: Function-ize setting of
	h->post_process
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce hvm_set_postprocess, so that we can make changes
to the setting and warning all in one place.

Special-case hvm_exception_nmi_generic_postprocess for now
to avoid regression; will get rid of it in the next c/s

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 6650e492be5d -r 47d436ca14d1 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -3073,6 +3073,20 @@ int __hvm_set_summary_handler(struct hvm
     return -EINVAL;
 }
 
+void hvm_exception_nmi_generic_postprocess(struct hvm_data *h);
+
+static int hvm_set_postprocess(struct hvm_data *h, void (*s)(struct hvm_data *h))
+{
+    if ( h->post_process == NULL
+        || h->post_process == hvm_exception_nmi_generic_postprocess )
+    {
+        h->post_process = s;
+        return 0;
+    }
+    else
+        return 1;
+}
+
 #define SIGN_EXTENDED_BITS (~((1ULL<<48)-1))
 #define HIGH_BIT(_v) ((_v) & (1ULL<<47))
 static inline int is_valid_addr64(unsigned long long va)
@@ -3416,7 +3430,8 @@ void hvm_pf_xen_process(struct record_in
                    e->pt_index[4]);
     }
 
-    h->post_process = hvm_pf_xen_postprocess;
+    if ( hvm_set_postprocess(h, hvm_pf_xen_postprocess) )
+         fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 char * hvm_vlapic_icr_dest_shorthand_name[4] = {
@@ -3703,10 +3718,9 @@ void hvm_mmio_assist_process(struct reco
     if((e->gpa & 0xfffff000) == 0xfee00000)
         hvm_vlapic_handler(h);
 
-    /* Catch MMIOs that don't go through the shadow code */
-    if ( h->post_process == NULL )
-        h->post_process = hvm_mmio_assist_postprocess;
-        
+    /* Catch MMIOs that don't go through the shadow code; tolerate
+     * failures to set (probably shadow_mmio) */
+    hvm_set_postprocess(h, hvm_mmio_assist_postprocess);
 }
 
 void hvm_inj_virq_process(struct record_info *ri, struct hvm_data *h) {
@@ -3889,10 +3903,12 @@ void hvm_io_assist_process(struct record
 
     if(mevt.write) {
         h->inflight.io.is_write = 1;
-        h->post_process = hvm_io_write_postprocess;
+        if ( hvm_set_postprocess(h, hvm_io_write_postprocess) )
+             fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
     } else {
         h->inflight.io.is_write = 0;
-        h->post_process = hvm_io_read_postprocess;
+        if ( hvm_set_postprocess(h, hvm_io_read_postprocess) )
+             fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
     }
 
     if(opt.dump_all)
@@ -4234,7 +4250,6 @@ void hvm_cr_write_postprocess(struct hvm
     }
 }
 
-void hvm_exception_nmi_generic_postprocess(struct hvm_data *h);
 void hvm_cr_write_process(struct record_info *ri, struct hvm_data *h)
 {
     union {
@@ -4258,13 +4273,11 @@ void hvm_cr_write_process(struct record_
         h->inflight.cr_write.val = val = r->x32.val;
     }
 
-    /* In real mode, cr accesses may cause EXNMI vmexits */
-    if ( !h->post_process
-         || (!opt.svm_mode
-             && h->post_process == hvm_exception_nmi_generic_postprocess) )
-        h->post_process = hvm_cr_write_postprocess;
-    else
-        fprintf(warn, "Strange, h->postprocess already set!\n");
+    /* In vmx, in real mode, cr accesses may cause EXNMI vmexits.
+     * Account them under that heading; otherwise, complain */
+    if ( hvm_set_postprocess(h, hvm_cr_write_postprocess) )
+        fprintf(warn, "%s: Strange, h->postprocess already set!\n",
+            __func__);
 
     if(opt.dump_all)
     {
@@ -4326,7 +4339,8 @@ void hvm_msr_write_process(struct record
                r->addr, r->val);
     }
 
-    h->post_process = hvm_msr_write_postprocess;
+    if ( hvm_set_postprocess(h, hvm_msr_write_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 /* msr_read */
@@ -4371,7 +4385,8 @@ void hvm_msr_read_process(struct record_
                r->addr, r->val);
     }
 
-    h->post_process = hvm_msr_read_postprocess;
+    if ( hvm_set_postprocess(h, hvm_msr_read_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void hvm_vmcall_summary(struct hvm_data *h, void *d)
@@ -4421,10 +4436,10 @@ void hvm_vmcall_process(struct record_in
                    r->eax);
     }
 
-    if(opt.summary) {
-        h->inflight.vmcall.eax = r->eax;
-        h->post_process = hvm_vmcall_postprocess;
-    }
+    h->inflight.vmcall.eax = r->eax;
+
+    if ( hvm_set_postprocess(h, hvm_vmcall_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void hvm_inj_exc_process(struct record_info *ri, struct hvm_data *h)
@@ -5640,8 +5655,8 @@ void shadow_emulate_process(struct recor
                flag_string(e), e->flags,
                e->pt_level, e->corresponding_va);
 
-    h->post_process = shadow_emulate_postprocess;
-
+    if ( hvm_set_postprocess(h, shadow_emulate_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 struct shadow_emulate_other {
@@ -5776,7 +5791,8 @@ void shadow_unsync_process(struct record
                e->pt_level,
                e->corresponding_va);
 
-    h->post_process = shadow_unsync_postprocess;
+    if ( hvm_set_postprocess(h, shadow_unsync_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 #endif
 
@@ -5802,7 +5818,8 @@ void shadow_emulate_other_process(struct
                e->gfn,
                e->va);
 
-    h->post_process = shadow_fault_generic_postprocess;
+    if ( hvm_set_postprocess(h, shadow_fault_generic_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void shadow_fixup_postprocess(struct hvm_data *h)
@@ -5962,7 +5979,8 @@ void shadow_fixup_process(struct record_
                    flag_string(e));
     }
 
-    h->post_process = shadow_fixup_postprocess;
+    if ( hvm_set_postprocess(h, shadow_fixup_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void shadow_mmio_postprocess(struct hvm_data *h)
@@ -6058,7 +6076,8 @@ void shadow_mmio_process(struct record_i
                 (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
                 e->va);
 
-    h->post_process = shadow_mmio_postprocess;
+    if ( hvm_set_postprocess(h, shadow_mmio_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void shadow_propagate_postprocess(struct hvm_data *h)
@@ -6150,7 +6169,8 @@ void shadow_propagate_process(struct rec
                e->va, e->gl1e, e->flags,
                flag_string(e));
 
-    h->post_process = shadow_propagate_postprocess;
+    if ( hvm_set_postprocess(h, shadow_propagate_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void shadow_fault_generic_dump(unsigned int event, uint32_t *d, char *prefix,
@@ -6216,7 +6236,8 @@ void shadow_fault_generic_process(struct
                                   "]", ri->dump_header);
 
     h->inflight.pf_xen.pf_case = sevt.minor;
-    h->post_process = shadow_fault_generic_postprocess;
+    if ( hvm_set_postprocess(h, shadow_fault_generic_postprocess) )
+        fprintf(warn, "%s: Strange, postprocess already set\n", __func__);
 }
 
 void shadow_resync_process(struct record_info *ri, struct hvm_data *h)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tf-0006lg-2J; Mon, 28 Nov 2011 16:17:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3td-0006im-AG
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:33 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5145 invoked from network); 28 Nov 2011 16:16:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456955"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:58 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS4015081;
	Mon, 28 Nov 2011 08:16:57 -0800
MIME-Version: 1.0
X-Mercurial-Node: dab5ba28630aa9148958284eaeb4cf9f6ae2c212
Message-ID: <dab5ba28630aa9148958.1322497087@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:07 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 10 of 12] xenalyze: Enable more cr3 output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Some of the cr3 ouptut was #if 0'd out.  Put it back in.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 46c366d71c74 -r dab5ba28630a xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -4220,8 +4220,7 @@ void cr3_dump_list(struct cr3_value_stru
         print_cycle_percent_summary(&p->hv_time, p->run_time, desc);
 
         hvm_short_summary(&p->hvm, p->run_time, "           + ");
-#if 0
-        printf("            Seen: %4lu.%09lu-%4lu.%09lu switch %d flush %d\n",
+        printf("            Seen: %4u.%09u-%4u.%09u switch %d flush %d\n",
                first.s, first.ns,
                last.s, last.ns,
                p->switch_count, p->flush_count);
@@ -4231,7 +4230,6 @@ void cr3_dump_list(struct cr3_value_stru
                    p->destroy.switch_count,
                    p->destroy.fixup_user,
                    p->destroy.emulate_corr_user);
-#endif
     }
 
     free(qsort_array);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tU-0006iB-Lk; Mon, 28 Nov 2011 16:17:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tT-0006i1-D0
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4847 invoked from network); 28 Nov 2011 16:16:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456944"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:49 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRs015081;
	Mon, 28 Nov 2011 08:16:48 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:17:57 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 00 of 12] xenalyze: Lots of updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Updates made recently.  Improved areas include:
* Handling of generic records
* Handling of VMEXITs that have multiple kinds of traces
* Handling of MMIO records for non-pagefault traces
* Handling of cr3 enumeration avlues
* Speed improvement for dump mode

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3ta-0006j7-Sa; Mon, 28 Nov 2011 16:17:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tY-0006iS-R6
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5071 invoked from network); 28 Nov 2011 16:16:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456953"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:56 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS2015081;
	Mon, 28 Nov 2011 08:16:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3c6da152c844f110e7e1becf3efda651cb912274
Message-ID: <3c6da152c844f110e7e1.1322497085@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:05 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 08 of 12] xenalyze: Add option to skip vga range
	in MMIO	enumeration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Emulations to the VGA range during boot can be extremely numerous,
sometimes causing out-of-memory errors.  Add an option to
skip the VGA range (0xa0000-0xbffff) during enumeration, and
enable it by default.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r c9f583c65e07 -r 3c6da152c844 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -48,6 +48,15 @@ struct array_struct {
     int count;
 };
 
+#define warn_once(_x...)                          \
+    do {                                          \
+        static int _w=1;                          \
+        if ( _w ) {                               \
+            _w=0;                                 \
+            fprintf(warn, ##_x);                  \
+        }                                         \
+    } while(0)                                    \
+        
 /* -- Global variables -- */
 struct {
     int fd;
@@ -160,6 +169,7 @@ struct {
         with_mmio_enumeration:1,
         with_interrupt_eip_enumeration:1,
         show_default_domain_summary:1,
+        mmio_enumeration_skip_vga:1,
         progress:1,
         svm_mode:1,
         summary:1,
@@ -234,6 +244,7 @@ struct {
     .with_mmio_enumeration = 0,
     .with_interrupt_eip_enumeration = 0,
     .show_default_domain_summary = 0,
+    .mmio_enumeration_skip_vga = 1,
     .progress = 0,
     .svm_mode = 0,
     .summary = 0,
@@ -3692,10 +3703,21 @@ void hvm_vlapic_handler(struct hvm_data 
 }
 
 /* Also called by shadow_mmio_postprocess */
+#define MMIO_VGA_START (0xa0000)
+#define MMIO_VGA_END   (0xbffff)
 void enumerate_mmio(struct hvm_data *h)
 {
     struct mmio_info *m = &h->inflight.mmio;
 
+    /* Skip vga area */
+    if ( opt.mmio_enumeration_skip_vga
+         && m->gpa >= MMIO_VGA_START
+         && m->gpa <  MMIO_VGA_END)
+    {
+        warn_once("WARNING: Not enumerationg MMIO in VGA range.  Use --mmio-enumeration-skip-vga=0 to override.\n");
+        return;
+    }
+
     if ( m->data_valid )
         update_io_address(&h->summary.io.mmio, m->gpa, m->is_write, h->arc_cycles, m->va);
 }
@@ -9464,6 +9486,7 @@ enum {
     OPT_INTERVAL_DOMAIN_GRANT_MAPS,
     /* Summary info */
     OPT_SHOW_DEFAULT_DOMAIN_SUMMARY,
+    OPT_MMIO_ENUMERATION_SKIP_VGA,
     OPT_SAMPLE_SIZE,
     OPT_REPORT_PCPU,
     /* Guest info */
@@ -9649,6 +9672,14 @@ error_t cmd_parser(int key, char *arg, s
             argp_usage(state);
         break;
     }
+    case OPT_MMIO_ENUMERATION_SKIP_VGA:
+    {
+        char * inval;
+        opt.mmio_enumeration_skip_vga = (int)strtol(arg, &inval, 0);
+        if( inval == arg )
+            argp_usage(state);
+        break;
+    }
     case OPT_SCATTERPLOT_INTERRUPT_EIP:
     {
         char * inval;
@@ -10182,6 +10213,12 @@ const struct argp_option cmd_opts[] =  {
       .group = OPT_GROUP_SUMMARY,
       .doc = "Show default domain information on summary", },
 
+    { .name = "mmio-enumeration-skip-vga",
+      .key = OPT_MMIO_ENUMERATION_SKIP_VGA,
+      .arg = "[0|1]",
+      .group = OPT_GROUP_SUMMARY,
+      .doc = "Control whether we enumerate MMIO accesses to the VGA area, which can be extremly high during boot.  Default: 0", },
+
     { .name = "sample-size",
       .key = OPT_SAMPLE_SIZE,
       .arg = "size",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3td-0006ka-Jw; Mon, 28 Nov 2011 16:17:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tc-0006iM-1K
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:32 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322497014!4938512!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21010 invoked from network); 28 Nov 2011 16:16:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047113"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:53 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRx015081;
	Mon, 28 Nov 2011 08:16:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 463ac7003722170266cf16661bda17288ccc7b89
Message-ID: <463ac7003722170266cf.1322497082@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:02 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 05 of 12] xenalyze: Handle new hvm_event traces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 844117c5a51e -r 463ac7003722 trace.h
--- a/trace.h	Mon Nov 28 16:16:23 2011 +0000
+++ b/trace.h	Mon Nov 28 16:16:23 2011 +0000
@@ -162,6 +162,9 @@
 #define TRC_HVM_RDTSC           (TRC_HVM_HANDLER + 0x1a)
 #define TRC_HVM_INTR_WINDOW     (TRC_HVM_HANDLER + 0x20)
 #define TRC_HVM_NPF             (TRC_HVM_HANDLER + 0x21)
+#define TRC_HVM_REALMODE_EMULATE (TRC_HVM_HANDLER + 0x22)
+#define TRC_HVM_TRAP             (TRC_HVM_HANDLER + 0x23)
+#define TRC_HVM_TRAP_DEBUG       (TRC_HVM_HANDLER + 0x24)
 
 #define TRC_HVM_IOPORT_WRITE    (TRC_HVM_HANDLER + 0x216)
 #define TRC_HVM_IOMEM_WRITE     (TRC_HVM_HANDLER + 0x217)
diff -r 844117c5a51e -r 463ac7003722 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -982,6 +982,9 @@ enum {
     HVM_EVENT_RDTSC,
     HVM_EVENT_INTR_WINDOW=0x20, /* Oops... skipped 0x1b-1f */
     HVM_EVENT_NPF,
+    HVM_EVENT_REALMODE_EMULATE,
+    HVM_EVENT_TRAP,
+    HVM_EVENT_TRAP_DEBUG,
     HVM_EVENT_HANDLER_MAX
 };
 char * hvm_event_handler_name[HVM_EVENT_HANDLER_MAX] = {
@@ -1014,6 +1017,9 @@ char * hvm_event_handler_name[HVM_EVENT_
     "rdtsc",
     [HVM_EVENT_INTR_WINDOW]="intr_window",
     "npf",
+    "realmode_emulate",
+    "trap",
+    "trap_debug",
 };
 
 enum {
@@ -4930,6 +4936,9 @@ needs_vmexit:
     case TRC_HVM_LMSW:
     case TRC_HVM_LMSW64:
     case TRC_HVM_NMI:
+    case TRC_HVM_REALMODE_EMULATE:
+    case TRC_HVM_TRAP:
+    case TRC_HVM_TRAP_DEBUG:
     case TRC_HVM_CR_READ:
     case TRC_HVM_CR_READ64:
     default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3td-0006ka-Jw; Mon, 28 Nov 2011 16:17:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tc-0006iM-1K
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:32 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322497014!4938512!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21010 invoked from network); 28 Nov 2011 16:16:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047113"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:53 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRx015081;
	Mon, 28 Nov 2011 08:16:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 463ac7003722170266cf16661bda17288ccc7b89
Message-ID: <463ac7003722170266cf.1322497082@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:02 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 05 of 12] xenalyze: Handle new hvm_event traces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 844117c5a51e -r 463ac7003722 trace.h
--- a/trace.h	Mon Nov 28 16:16:23 2011 +0000
+++ b/trace.h	Mon Nov 28 16:16:23 2011 +0000
@@ -162,6 +162,9 @@
 #define TRC_HVM_RDTSC           (TRC_HVM_HANDLER + 0x1a)
 #define TRC_HVM_INTR_WINDOW     (TRC_HVM_HANDLER + 0x20)
 #define TRC_HVM_NPF             (TRC_HVM_HANDLER + 0x21)
+#define TRC_HVM_REALMODE_EMULATE (TRC_HVM_HANDLER + 0x22)
+#define TRC_HVM_TRAP             (TRC_HVM_HANDLER + 0x23)
+#define TRC_HVM_TRAP_DEBUG       (TRC_HVM_HANDLER + 0x24)
 
 #define TRC_HVM_IOPORT_WRITE    (TRC_HVM_HANDLER + 0x216)
 #define TRC_HVM_IOMEM_WRITE     (TRC_HVM_HANDLER + 0x217)
diff -r 844117c5a51e -r 463ac7003722 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -982,6 +982,9 @@ enum {
     HVM_EVENT_RDTSC,
     HVM_EVENT_INTR_WINDOW=0x20, /* Oops... skipped 0x1b-1f */
     HVM_EVENT_NPF,
+    HVM_EVENT_REALMODE_EMULATE,
+    HVM_EVENT_TRAP,
+    HVM_EVENT_TRAP_DEBUG,
     HVM_EVENT_HANDLER_MAX
 };
 char * hvm_event_handler_name[HVM_EVENT_HANDLER_MAX] = {
@@ -1014,6 +1017,9 @@ char * hvm_event_handler_name[HVM_EVENT_
     "rdtsc",
     [HVM_EVENT_INTR_WINDOW]="intr_window",
     "npf",
+    "realmode_emulate",
+    "trap",
+    "trap_debug",
 };
 
 enum {
@@ -4930,6 +4936,9 @@ needs_vmexit:
     case TRC_HVM_LMSW:
     case TRC_HVM_LMSW64:
     case TRC_HVM_NMI:
+    case TRC_HVM_REALMODE_EMULATE:
+    case TRC_HVM_TRAP:
+    case TRC_HVM_TRAP_DEBUG:
     case TRC_HVM_CR_READ:
     case TRC_HVM_CR_READ64:
     default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3ta-0006j7-Sa; Mon, 28 Nov 2011 16:17:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tY-0006iS-R6
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5071 invoked from network); 28 Nov 2011 16:16:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:23 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456953"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:56 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS2015081;
	Mon, 28 Nov 2011 08:16:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3c6da152c844f110e7e1becf3efda651cb912274
Message-ID: <3c6da152c844f110e7e1.1322497085@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:05 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 08 of 12] xenalyze: Add option to skip vga range
	in MMIO	enumeration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Emulations to the VGA range during boot can be extremely numerous,
sometimes causing out-of-memory errors.  Add an option to
skip the VGA range (0xa0000-0xbffff) during enumeration, and
enable it by default.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r c9f583c65e07 -r 3c6da152c844 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -48,6 +48,15 @@ struct array_struct {
     int count;
 };
 
+#define warn_once(_x...)                          \
+    do {                                          \
+        static int _w=1;                          \
+        if ( _w ) {                               \
+            _w=0;                                 \
+            fprintf(warn, ##_x);                  \
+        }                                         \
+    } while(0)                                    \
+        
 /* -- Global variables -- */
 struct {
     int fd;
@@ -160,6 +169,7 @@ struct {
         with_mmio_enumeration:1,
         with_interrupt_eip_enumeration:1,
         show_default_domain_summary:1,
+        mmio_enumeration_skip_vga:1,
         progress:1,
         svm_mode:1,
         summary:1,
@@ -234,6 +244,7 @@ struct {
     .with_mmio_enumeration = 0,
     .with_interrupt_eip_enumeration = 0,
     .show_default_domain_summary = 0,
+    .mmio_enumeration_skip_vga = 1,
     .progress = 0,
     .svm_mode = 0,
     .summary = 0,
@@ -3692,10 +3703,21 @@ void hvm_vlapic_handler(struct hvm_data 
 }
 
 /* Also called by shadow_mmio_postprocess */
+#define MMIO_VGA_START (0xa0000)
+#define MMIO_VGA_END   (0xbffff)
 void enumerate_mmio(struct hvm_data *h)
 {
     struct mmio_info *m = &h->inflight.mmio;
 
+    /* Skip vga area */
+    if ( opt.mmio_enumeration_skip_vga
+         && m->gpa >= MMIO_VGA_START
+         && m->gpa <  MMIO_VGA_END)
+    {
+        warn_once("WARNING: Not enumerationg MMIO in VGA range.  Use --mmio-enumeration-skip-vga=0 to override.\n");
+        return;
+    }
+
     if ( m->data_valid )
         update_io_address(&h->summary.io.mmio, m->gpa, m->is_write, h->arc_cycles, m->va);
 }
@@ -9464,6 +9486,7 @@ enum {
     OPT_INTERVAL_DOMAIN_GRANT_MAPS,
     /* Summary info */
     OPT_SHOW_DEFAULT_DOMAIN_SUMMARY,
+    OPT_MMIO_ENUMERATION_SKIP_VGA,
     OPT_SAMPLE_SIZE,
     OPT_REPORT_PCPU,
     /* Guest info */
@@ -9649,6 +9672,14 @@ error_t cmd_parser(int key, char *arg, s
             argp_usage(state);
         break;
     }
+    case OPT_MMIO_ENUMERATION_SKIP_VGA:
+    {
+        char * inval;
+        opt.mmio_enumeration_skip_vga = (int)strtol(arg, &inval, 0);
+        if( inval == arg )
+            argp_usage(state);
+        break;
+    }
     case OPT_SCATTERPLOT_INTERRUPT_EIP:
     {
         char * inval;
@@ -10182,6 +10213,12 @@ const struct argp_option cmd_opts[] =  {
       .group = OPT_GROUP_SUMMARY,
       .doc = "Show default domain information on summary", },
 
+    { .name = "mmio-enumeration-skip-vga",
+      .key = OPT_MMIO_ENUMERATION_SKIP_VGA,
+      .arg = "[0|1]",
+      .group = OPT_GROUP_SUMMARY,
+      .doc = "Control whether we enumerate MMIO accesses to the VGA area, which can be extremly high during boot.  Default: 0", },
+
     { .name = "sample-size",
       .key = OPT_SAMPLE_SIZE,
       .arg = "size",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tj-0006nl-44; Mon, 28 Nov 2011 16:17:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3th-0006jc-9M
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:37 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5209 invoked from network); 28 Nov 2011 16:16:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456956"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:17:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:17:00 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS6015081;
	Mon, 28 Nov 2011 08:16:59 -0800
MIME-Version: 1.0
X-Mercurial-Node: 223e8ad4c7557960e29a7c294bb94723b2cd7f09
Message-ID: <223e8ad4c7557960e29a.1322497089@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:09 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 12 of 12] xenalyze: Make max_active_pcpu
	calculation smarter
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

oprofile reports that during summary runs, over 30% of the
time processing is spent in choose_next_record.  As a first
step towards eliminating the loop found in that function,
take out the calculation of P.max_active_pcpu, and make it
smarter.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r b7d88a8858b7 -r 223e8ad4c755 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -8675,6 +8675,21 @@ void deactivate_pcpu(struct pcpu_info *p
         lose_vcpu(p->current, p->last_tsc);
     }
     p->active = 0;
+    if ( p->pid == P.max_active_pcpu )
+    {
+        int i, max_active_pcpu = -1;
+        for(i=0; i<=P.max_active_pcpu; i++)
+        {
+            if(!P.pcpu[i].active)
+                continue;
+
+            max_active_pcpu = i;
+        }
+        P.max_active_pcpu = max_active_pcpu;
+        fprintf(warn, "%s: Setting max_active_pcpu to %d\n",
+                __func__, max_active_pcpu);
+    }
+        
 }
 
 /* Helper function to process tsc-related record info */
@@ -9304,17 +9319,20 @@ char * pcpu_string(int pcpu)
 
 struct pcpu_info * choose_next_record(void)
 {
-    int i, max_active_pcpu = -1;
+    int i;
     struct pcpu_info * p, *min_p=NULL;
     loff_t min_offset = 0;
 
+    /* Need to:
+     * - find the pcpu with the lowest order_tsc
+     * - Find the lowest file offset
+     */
     for(i=0; i<=P.max_active_pcpu; i++)
     {
         p = P.pcpu+i;
         if(!p->active)
             continue;
 
-        max_active_pcpu = i;
         if(!min_p || p->order_tsc < min_p->order_tsc)
             min_p = p;
 
@@ -9322,13 +9340,11 @@ struct pcpu_info * choose_next_record(vo
             min_offset = p->file_offset;
     }
 
-    P.max_active_pcpu = max_active_pcpu;
-
     if(opt.progress && min_offset >= G.progress.update_offset)
         progress_update(min_offset);
 
     /* If there are active pcpus, make sure we chose one */
-    assert(min_p || (max_active_pcpu==-1));
+    assert(min_p || (P.max_active_pcpu==-1));
 
     return min_p;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tU-0006iB-Lk; Mon, 28 Nov 2011 16:17:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tT-0006i1-D0
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:23 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4847 invoked from network); 28 Nov 2011 16:16:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456944"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:49 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRs015081;
	Mon, 28 Nov 2011 08:16:48 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:17:57 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 00 of 12] xenalyze: Lots of updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Updates made recently.  Improved areas include:
* Handling of generic records
* Handling of VMEXITs that have multiple kinds of traces
* Handling of MMIO records for non-pagefault traces
* Handling of cr3 enumeration avlues
* Speed improvement for dump mode

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tj-0006nl-44; Mon, 28 Nov 2011 16:17:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3th-0006jc-9M
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:37 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5209 invoked from network); 28 Nov 2011 16:16:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456956"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:17:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:17:00 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS6015081;
	Mon, 28 Nov 2011 08:16:59 -0800
MIME-Version: 1.0
X-Mercurial-Node: 223e8ad4c7557960e29a7c294bb94723b2cd7f09
Message-ID: <223e8ad4c7557960e29a.1322497089@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:09 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 12 of 12] xenalyze: Make max_active_pcpu
	calculation smarter
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

oprofile reports that during summary runs, over 30% of the
time processing is spent in choose_next_record.  As a first
step towards eliminating the loop found in that function,
take out the calculation of P.max_active_pcpu, and make it
smarter.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r b7d88a8858b7 -r 223e8ad4c755 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -8675,6 +8675,21 @@ void deactivate_pcpu(struct pcpu_info *p
         lose_vcpu(p->current, p->last_tsc);
     }
     p->active = 0;
+    if ( p->pid == P.max_active_pcpu )
+    {
+        int i, max_active_pcpu = -1;
+        for(i=0; i<=P.max_active_pcpu; i++)
+        {
+            if(!P.pcpu[i].active)
+                continue;
+
+            max_active_pcpu = i;
+        }
+        P.max_active_pcpu = max_active_pcpu;
+        fprintf(warn, "%s: Setting max_active_pcpu to %d\n",
+                __func__, max_active_pcpu);
+    }
+        
 }
 
 /* Helper function to process tsc-related record info */
@@ -9304,17 +9319,20 @@ char * pcpu_string(int pcpu)
 
 struct pcpu_info * choose_next_record(void)
 {
-    int i, max_active_pcpu = -1;
+    int i;
     struct pcpu_info * p, *min_p=NULL;
     loff_t min_offset = 0;
 
+    /* Need to:
+     * - find the pcpu with the lowest order_tsc
+     * - Find the lowest file offset
+     */
     for(i=0; i<=P.max_active_pcpu; i++)
     {
         p = P.pcpu+i;
         if(!p->active)
             continue;
 
-        max_active_pcpu = i;
         if(!min_p || p->order_tsc < min_p->order_tsc)
             min_p = p;
 
@@ -9322,13 +9340,11 @@ struct pcpu_info * choose_next_record(vo
             min_offset = p->file_offset;
     }
 
-    P.max_active_pcpu = max_active_pcpu;
-
     if(opt.progress && min_offset >= G.progress.update_offset)
         progress_update(min_offset);
 
     /* If there are active pcpus, make sure we chose one */
-    assert(min_p || (max_active_pcpu==-1));
+    assert(min_p || (P.max_active_pcpu==-1));
 
     return min_p;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tb-0006jW-Fr; Mon, 28 Nov 2011 16:17:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tZ-0006iA-Ax
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322497010!3423854!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17079 invoked from network); 28 Nov 2011 16:16:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047098"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:50 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRt015081;
	Mon, 28 Nov 2011 08:16:49 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2e85d4c4042e319b4a712fa6d05494126d238f3b
Message-ID: <2e85d4c4042e319b4a71.1322497078@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:17:58 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 01 of 12] xenalyze: Allow several summary
	handlers to register	on a single vmexit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VMX tends to have several distinct kinds of handlers for a single
vmexit type; notably, EXCEPTION_NMI gets page faults, other traps,
emulations, and sometimes other kinds of traps as well; while for
SVM, each different trap has a different call type.

This patch introduces a signal-style callback mechanism that allows
several callbacks to be attached to a given exit reason.  Each of these
callbacks will be called in the case of a summary event.

In order to distinguish different kinds of callbacks, the callback also
includes a value which is passed as-is to the function when it's called.
It's the size of a pointer so that it can be used as a pointer if necessary;
typically it will probably be a small integer value.

Each vmexit should only register a handler once with any given data value;
there is some syntactic sugar to make sure this happens.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 288573cb0f11 -r 2e85d4c4042e xenalyze.c
--- a/xenalyze.c	Fri Oct 07 11:49:04 2011 +0100
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -1308,6 +1308,14 @@ struct pcpu_info;
 #define RESYNCS_MAX 17
 #define PF_XEN_FIXUP_UNSYNC_RESYNC_MAX 2
 
+struct hvm_data;
+
+struct hvm_summary_handler_node {
+    void (*handler)(struct hvm_data *, void* data);
+    void *data;
+    struct hvm_summary_handler_node *next;
+};
+
 struct hvm_data {
     /* Summary information */
     int init;
@@ -1318,7 +1326,7 @@ struct hvm_data {
     /* SVM / VMX compatibility. FIXME - should be global */
     char ** exit_reason_name;
     int exit_reason_max;
-    void (* exit_reason_summary_handler[HVM_EXIT_REASON_MAX])(struct hvm_data *);
+    struct hvm_summary_handler_node *exit_reason_summary_handler_list[HVM_EXIT_REASON_MAX];
 
     /* Information about particular exit reasons */
     struct {
@@ -3011,23 +3019,58 @@ void hvm_short_summary(struct hvm_short_
     }
 }
 
-void hvm_set_summary_handler(struct hvm_data *h, void (*s)(struct hvm_data *h)) {
+/* Wrapper to try to make sure this is only called once per
+ * call site, rather than walking through the list each time */
+#define hvm_set_summary_handler(_h, _s, _d)                             \
+    do {                                                                \
+        static int done=0;                                              \
+        int ret;                                                        \
+        if(!done) {                                                     \
+            if ((ret=__hvm_set_summary_handler(_h, _s, _d)))            \
+                fprintf(stderr, "%s: hvm_set_summary_handler returned %d\n", \
+                        __func__, ret);                                 \
+            done=1;                                                     \
+        }                                                               \
+    } while(0)
+
+int __hvm_set_summary_handler(struct hvm_data *h, void (*s)(struct hvm_data *h, void*d), void*d) {
     /* Set summary handler */
     if(h->exit_reason < h->exit_reason_max)
     {
-        if(h->exit_reason_summary_handler[h->exit_reason])
+        struct hvm_summary_handler_node *p, **q;
+
+        /* Find the end of the list, checking to make sure there are no
+         * duplicates along the way */
+        q=&h->exit_reason_summary_handler_list[h->exit_reason];
+        p = *q;
+        while(p)
         {
-            if(h->exit_reason_summary_handler[h->exit_reason]!= s)
-                fprintf(warn, "Strange, unexpected summary handler for exit_reason %s (%d!)\n",
-                        h->exit_reason_name[h->exit_reason], h->exit_reason);
-        }
-        else
-        {
-            h->exit_reason_summary_handler[h->exit_reason] = s;
-            fprintf(warn, "Setting exit_reason %s (%d) summary handler\n",
-                    h->exit_reason_name[h->exit_reason], h->exit_reason);
-        }
-    }
+            if(p->handler == s && p->data == d)
+            {
+                fprintf(stderr, "%s: Unexpected duplicate handler %p,%p\n",
+                        __func__, s, d);
+                error(ERR_STRICT, NULL);
+            return -EBUSY;
+            }
+            q=&p->next;
+            p=*q;
+        }
+
+        assert(p==NULL);
+
+        /* Insert the new handler */
+        p=malloc(sizeof(*p));
+        if (!p) {
+            fprintf(stderr, "%s: Malloc failed!\n", __func__);
+            error(ERR_SYSTEM, NULL);
+        }
+        p->handler=s;
+        p->data = d;
+        p->next=*q;
+        *q=p;
+        return 0;
+    }
+    return -EINVAL;
 }
 
 #define SIGN_EXTENDED_BITS (~((1ULL<<48)-1))
@@ -3040,7 +3083,7 @@ static inline int is_valid_addr64(unsign
         return ((va & SIGN_EXTENDED_BITS) == 0);
 }
 
-void hvm_pf_xen_summary(struct hvm_data *h) {
+void hvm_pf_xen_summary(struct hvm_data *h, void *d) {
     int i,j, k;
     
     for(i=0; i<PF_XEN_MAX; i++)
@@ -3314,7 +3357,7 @@ void hvm_pf_xen_postprocess(struct hvm_d
         }
 
         /* Set summary handler */
-        hvm_set_summary_handler(h, hvm_pf_xen_summary);
+        hvm_set_summary_handler(h, hvm_pf_xen_summary, NULL);
     }
 
     if(opt.dump_cooked)
@@ -4061,7 +4104,7 @@ void cr3_dump_list(struct cr3_value_stru
     free(qsort_array);
 }
 
-void hvm_cr3_write_summary(struct hvm_data *h) {
+void hvm_cr3_write_summary(struct hvm_data *h, void *data) {
     int j;
 
     for(j=0; j<RESYNCS_MAX; j++)
@@ -4071,7 +4114,7 @@ void hvm_cr3_write_summary(struct hvm_da
                   "     *[MAX] ");
 }
 
-void hvm_cr_write_summary(struct hvm_data *h)
+void hvm_cr_write_summary(struct hvm_data *h, void *data)
 {
     int i;
 
@@ -4081,7 +4124,7 @@ void hvm_cr_write_summary(struct hvm_dat
                       "   cr%d ", i);
         switch(i) {
         case 3:
-            hvm_cr3_write_summary(h);
+            hvm_cr3_write_summary(h, NULL);
             break;
         }
     }
@@ -4168,11 +4211,11 @@ void hvm_cr_write_postprocess(struct hvm
         if ( opt.svm_mode ) {
             /* For svm, only need a summary for cr3 */
             if ( h->exit_reason == VMEXIT_CR3_WRITE )
-                hvm_set_summary_handler(h, hvm_cr3_write_summary);
+                hvm_set_summary_handler(h, hvm_cr3_write_summary, NULL);
         } else {
             /* For vmx, real mode may cause EXNMI exits on cr accesses */
             if ( h->exit_reason !=  EXIT_REASON_EXCEPTION_NMI )
-                hvm_set_summary_handler(h, hvm_cr_write_summary);
+                hvm_set_summary_handler(h, hvm_cr_write_summary, NULL);
         }
     }
 }
@@ -4229,7 +4272,7 @@ void hvm_cr_write_process(struct record_
 }
 
 /* msr_write */
-void hvm_msr_write_summary(struct hvm_data *h)
+void hvm_msr_write_summary(struct hvm_data *h, void *d)
 {
 }
 
@@ -4247,7 +4290,7 @@ void hvm_msr_write_postprocess(struct hv
     }
 
     /* Set summary handler */
-    hvm_set_summary_handler(h, hvm_msr_write_summary);
+    hvm_set_summary_handler(h, hvm_msr_write_summary, NULL);
 }
 
 void hvm_msr_write_process(struct record_info *ri, struct hvm_data *h)
@@ -4274,7 +4317,7 @@ void hvm_msr_write_process(struct record
 }
 
 /* msr_read */
-void hvm_msr_read_summary(struct hvm_data *h)
+void hvm_msr_read_summary(struct hvm_data *h, void *d)
 {
 }
 
@@ -4292,7 +4335,7 @@ void hvm_msr_read_postprocess(struct hvm
     }
 
     /* Set summary handler */
-    hvm_set_summary_handler(h, hvm_msr_read_summary);
+    hvm_set_summary_handler(h, hvm_msr_read_summary, NULL);
 }
 
 void hvm_msr_read_process(struct record_info *ri, struct hvm_data *h)
@@ -4318,7 +4361,7 @@ void hvm_msr_read_process(struct record_
     h->post_process = hvm_msr_read_postprocess;
 }
 
-void hvm_vmcall_summary(struct hvm_data *h)
+void hvm_vmcall_summary(struct hvm_data *h, void *d)
 {
     int i;
 
@@ -4343,6 +4386,7 @@ void hvm_vmcall_postprocess(struct hvm_d
         else
             update_summary(&h->summary.vmcall[HYPERCALL_MAX],
                        h->arc_cycles);
+        hvm_set_summary_handler(h, hvm_vmcall_summary, NULL);
     }
 }
 
@@ -4365,7 +4409,6 @@ void hvm_vmcall_process(struct record_in
     }
 
     if(opt.summary) {
-        hvm_set_summary_handler(h, hvm_vmcall_summary);
         h->inflight.vmcall.eax = r->eax;
         h->post_process = hvm_vmcall_postprocess;
     }
@@ -4391,7 +4434,7 @@ void hvm_inj_exc_process(struct record_i
     
 }
 
-void hvm_intr_summary(struct hvm_data *h)
+void hvm_intr_summary(struct hvm_data *h, void *d)
 {
     int i;
 
@@ -4483,7 +4526,7 @@ void hvm_intr_process(struct hvm_data *h
 
     if(opt.summary_info) {
         if(opt.summary)
-            hvm_set_summary_handler(h, hvm_intr_summary);
+            hvm_set_summary_handler(h, hvm_intr_summary, NULL);
 
         if(vec < EXTERNAL_INTERRUPT_MAX)
             h->summary.extint[vec]++;
@@ -5321,6 +5364,8 @@ void hvm_summary(struct hvm_data *h) {
 
    printf("Exit reasons:\n");
    for(i=0; i<h->exit_reason_max; i++) {
+       struct hvm_summary_handler_node *p;
+
        if ( h->exit_reason_name[i] )
            PRINT_SUMMARY(h->summary.exit_reason[i],
                          " %-20s ", h->exit_reason_name[i]);
@@ -5328,8 +5373,12 @@ void hvm_summary(struct hvm_data *h) {
            PRINT_SUMMARY(h->summary.exit_reason[i],
                          " %20d ", i);
 
-       if(h->exit_reason_summary_handler[i])
-           h->exit_reason_summary_handler[i](h);
+       p=h->exit_reason_summary_handler_list[i];
+       while(p)
+       {
+           p->handler(h, p->data);
+           p=p->next;
+       }
    }
 
    printf("Guest interrupt counts:\n");
@@ -6238,7 +6287,7 @@ void shadow_process(struct pcpu_info *p)
     if(sevt.minor <= PF_XEN_LAST_FAULT)  {
         h->inflight.pf_xen.pf_case = sevt.minor;
         if(opt.summary) {
-            hvm_set_summary_handler(h, hvm_pf_xen_summary);
+            hvm_set_summary_handler(h, hvm_pf_xen_summary, NULL);
         }
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3tb-0006jW-Fr; Mon, 28 Nov 2011 16:17:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tZ-0006iA-Ax
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:29 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322497010!3423854!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17079 invoked from network); 28 Nov 2011 16:16:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047098"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:50 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRt015081;
	Mon, 28 Nov 2011 08:16:49 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2e85d4c4042e319b4a712fa6d05494126d238f3b
Message-ID: <2e85d4c4042e319b4a71.1322497078@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:17:58 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 01 of 12] xenalyze: Allow several summary
	handlers to register	on a single vmexit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VMX tends to have several distinct kinds of handlers for a single
vmexit type; notably, EXCEPTION_NMI gets page faults, other traps,
emulations, and sometimes other kinds of traps as well; while for
SVM, each different trap has a different call type.

This patch introduces a signal-style callback mechanism that allows
several callbacks to be attached to a given exit reason.  Each of these
callbacks will be called in the case of a summary event.

In order to distinguish different kinds of callbacks, the callback also
includes a value which is passed as-is to the function when it's called.
It's the size of a pointer so that it can be used as a pointer if necessary;
typically it will probably be a small integer value.

Each vmexit should only register a handler once with any given data value;
there is some syntactic sugar to make sure this happens.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 288573cb0f11 -r 2e85d4c4042e xenalyze.c
--- a/xenalyze.c	Fri Oct 07 11:49:04 2011 +0100
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -1308,6 +1308,14 @@ struct pcpu_info;
 #define RESYNCS_MAX 17
 #define PF_XEN_FIXUP_UNSYNC_RESYNC_MAX 2
 
+struct hvm_data;
+
+struct hvm_summary_handler_node {
+    void (*handler)(struct hvm_data *, void* data);
+    void *data;
+    struct hvm_summary_handler_node *next;
+};
+
 struct hvm_data {
     /* Summary information */
     int init;
@@ -1318,7 +1326,7 @@ struct hvm_data {
     /* SVM / VMX compatibility. FIXME - should be global */
     char ** exit_reason_name;
     int exit_reason_max;
-    void (* exit_reason_summary_handler[HVM_EXIT_REASON_MAX])(struct hvm_data *);
+    struct hvm_summary_handler_node *exit_reason_summary_handler_list[HVM_EXIT_REASON_MAX];
 
     /* Information about particular exit reasons */
     struct {
@@ -3011,23 +3019,58 @@ void hvm_short_summary(struct hvm_short_
     }
 }
 
-void hvm_set_summary_handler(struct hvm_data *h, void (*s)(struct hvm_data *h)) {
+/* Wrapper to try to make sure this is only called once per
+ * call site, rather than walking through the list each time */
+#define hvm_set_summary_handler(_h, _s, _d)                             \
+    do {                                                                \
+        static int done=0;                                              \
+        int ret;                                                        \
+        if(!done) {                                                     \
+            if ((ret=__hvm_set_summary_handler(_h, _s, _d)))            \
+                fprintf(stderr, "%s: hvm_set_summary_handler returned %d\n", \
+                        __func__, ret);                                 \
+            done=1;                                                     \
+        }                                                               \
+    } while(0)
+
+int __hvm_set_summary_handler(struct hvm_data *h, void (*s)(struct hvm_data *h, void*d), void*d) {
     /* Set summary handler */
     if(h->exit_reason < h->exit_reason_max)
     {
-        if(h->exit_reason_summary_handler[h->exit_reason])
+        struct hvm_summary_handler_node *p, **q;
+
+        /* Find the end of the list, checking to make sure there are no
+         * duplicates along the way */
+        q=&h->exit_reason_summary_handler_list[h->exit_reason];
+        p = *q;
+        while(p)
         {
-            if(h->exit_reason_summary_handler[h->exit_reason]!= s)
-                fprintf(warn, "Strange, unexpected summary handler for exit_reason %s (%d!)\n",
-                        h->exit_reason_name[h->exit_reason], h->exit_reason);
-        }
-        else
-        {
-            h->exit_reason_summary_handler[h->exit_reason] = s;
-            fprintf(warn, "Setting exit_reason %s (%d) summary handler\n",
-                    h->exit_reason_name[h->exit_reason], h->exit_reason);
-        }
-    }
+            if(p->handler == s && p->data == d)
+            {
+                fprintf(stderr, "%s: Unexpected duplicate handler %p,%p\n",
+                        __func__, s, d);
+                error(ERR_STRICT, NULL);
+            return -EBUSY;
+            }
+            q=&p->next;
+            p=*q;
+        }
+
+        assert(p==NULL);
+
+        /* Insert the new handler */
+        p=malloc(sizeof(*p));
+        if (!p) {
+            fprintf(stderr, "%s: Malloc failed!\n", __func__);
+            error(ERR_SYSTEM, NULL);
+        }
+        p->handler=s;
+        p->data = d;
+        p->next=*q;
+        *q=p;
+        return 0;
+    }
+    return -EINVAL;
 }
 
 #define SIGN_EXTENDED_BITS (~((1ULL<<48)-1))
@@ -3040,7 +3083,7 @@ static inline int is_valid_addr64(unsign
         return ((va & SIGN_EXTENDED_BITS) == 0);
 }
 
-void hvm_pf_xen_summary(struct hvm_data *h) {
+void hvm_pf_xen_summary(struct hvm_data *h, void *d) {
     int i,j, k;
     
     for(i=0; i<PF_XEN_MAX; i++)
@@ -3314,7 +3357,7 @@ void hvm_pf_xen_postprocess(struct hvm_d
         }
 
         /* Set summary handler */
-        hvm_set_summary_handler(h, hvm_pf_xen_summary);
+        hvm_set_summary_handler(h, hvm_pf_xen_summary, NULL);
     }
 
     if(opt.dump_cooked)
@@ -4061,7 +4104,7 @@ void cr3_dump_list(struct cr3_value_stru
     free(qsort_array);
 }
 
-void hvm_cr3_write_summary(struct hvm_data *h) {
+void hvm_cr3_write_summary(struct hvm_data *h, void *data) {
     int j;
 
     for(j=0; j<RESYNCS_MAX; j++)
@@ -4071,7 +4114,7 @@ void hvm_cr3_write_summary(struct hvm_da
                   "     *[MAX] ");
 }
 
-void hvm_cr_write_summary(struct hvm_data *h)
+void hvm_cr_write_summary(struct hvm_data *h, void *data)
 {
     int i;
 
@@ -4081,7 +4124,7 @@ void hvm_cr_write_summary(struct hvm_dat
                       "   cr%d ", i);
         switch(i) {
         case 3:
-            hvm_cr3_write_summary(h);
+            hvm_cr3_write_summary(h, NULL);
             break;
         }
     }
@@ -4168,11 +4211,11 @@ void hvm_cr_write_postprocess(struct hvm
         if ( opt.svm_mode ) {
             /* For svm, only need a summary for cr3 */
             if ( h->exit_reason == VMEXIT_CR3_WRITE )
-                hvm_set_summary_handler(h, hvm_cr3_write_summary);
+                hvm_set_summary_handler(h, hvm_cr3_write_summary, NULL);
         } else {
             /* For vmx, real mode may cause EXNMI exits on cr accesses */
             if ( h->exit_reason !=  EXIT_REASON_EXCEPTION_NMI )
-                hvm_set_summary_handler(h, hvm_cr_write_summary);
+                hvm_set_summary_handler(h, hvm_cr_write_summary, NULL);
         }
     }
 }
@@ -4229,7 +4272,7 @@ void hvm_cr_write_process(struct record_
 }
 
 /* msr_write */
-void hvm_msr_write_summary(struct hvm_data *h)
+void hvm_msr_write_summary(struct hvm_data *h, void *d)
 {
 }
 
@@ -4247,7 +4290,7 @@ void hvm_msr_write_postprocess(struct hv
     }
 
     /* Set summary handler */
-    hvm_set_summary_handler(h, hvm_msr_write_summary);
+    hvm_set_summary_handler(h, hvm_msr_write_summary, NULL);
 }
 
 void hvm_msr_write_process(struct record_info *ri, struct hvm_data *h)
@@ -4274,7 +4317,7 @@ void hvm_msr_write_process(struct record
 }
 
 /* msr_read */
-void hvm_msr_read_summary(struct hvm_data *h)
+void hvm_msr_read_summary(struct hvm_data *h, void *d)
 {
 }
 
@@ -4292,7 +4335,7 @@ void hvm_msr_read_postprocess(struct hvm
     }
 
     /* Set summary handler */
-    hvm_set_summary_handler(h, hvm_msr_read_summary);
+    hvm_set_summary_handler(h, hvm_msr_read_summary, NULL);
 }
 
 void hvm_msr_read_process(struct record_info *ri, struct hvm_data *h)
@@ -4318,7 +4361,7 @@ void hvm_msr_read_process(struct record_
     h->post_process = hvm_msr_read_postprocess;
 }
 
-void hvm_vmcall_summary(struct hvm_data *h)
+void hvm_vmcall_summary(struct hvm_data *h, void *d)
 {
     int i;
 
@@ -4343,6 +4386,7 @@ void hvm_vmcall_postprocess(struct hvm_d
         else
             update_summary(&h->summary.vmcall[HYPERCALL_MAX],
                        h->arc_cycles);
+        hvm_set_summary_handler(h, hvm_vmcall_summary, NULL);
     }
 }
 
@@ -4365,7 +4409,6 @@ void hvm_vmcall_process(struct record_in
     }
 
     if(opt.summary) {
-        hvm_set_summary_handler(h, hvm_vmcall_summary);
         h->inflight.vmcall.eax = r->eax;
         h->post_process = hvm_vmcall_postprocess;
     }
@@ -4391,7 +4434,7 @@ void hvm_inj_exc_process(struct record_i
     
 }
 
-void hvm_intr_summary(struct hvm_data *h)
+void hvm_intr_summary(struct hvm_data *h, void *d)
 {
     int i;
 
@@ -4483,7 +4526,7 @@ void hvm_intr_process(struct hvm_data *h
 
     if(opt.summary_info) {
         if(opt.summary)
-            hvm_set_summary_handler(h, hvm_intr_summary);
+            hvm_set_summary_handler(h, hvm_intr_summary, NULL);
 
         if(vec < EXTERNAL_INTERRUPT_MAX)
             h->summary.extint[vec]++;
@@ -5321,6 +5364,8 @@ void hvm_summary(struct hvm_data *h) {
 
    printf("Exit reasons:\n");
    for(i=0; i<h->exit_reason_max; i++) {
+       struct hvm_summary_handler_node *p;
+
        if ( h->exit_reason_name[i] )
            PRINT_SUMMARY(h->summary.exit_reason[i],
                          " %-20s ", h->exit_reason_name[i]);
@@ -5328,8 +5373,12 @@ void hvm_summary(struct hvm_data *h) {
            PRINT_SUMMARY(h->summary.exit_reason[i],
                          " %20d ", i);
 
-       if(h->exit_reason_summary_handler[i])
-           h->exit_reason_summary_handler[i](h);
+       p=h->exit_reason_summary_handler_list[i];
+       while(p)
+       {
+           p->handler(h, p->data);
+           p=p->next;
+       }
    }
 
    printf("Guest interrupt counts:\n");
@@ -6238,7 +6287,7 @@ void shadow_process(struct pcpu_info *p)
     if(sevt.minor <= PF_XEN_LAST_FAULT)  {
         h->inflight.pf_xen.pf_case = sevt.minor;
         if(opt.summary) {
-            hvm_set_summary_handler(h, hvm_pf_xen_summary);
+            hvm_set_summary_handler(h, hvm_pf_xen_summary, NULL);
         }
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3te-0006kr-0n; Mon, 28 Nov 2011 16:17:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tc-0006jb-6U
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:32 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322496999!50058610!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25317 invoked from network); 28 Nov 2011 16:16:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047149"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:59 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS5015081;
	Mon, 28 Nov 2011 08:16:58 -0800
MIME-Version: 1.0
X-Mercurial-Node: b7d88a8858b74d778b21ec7894fc274793c5afe7
Message-ID: <b7d88a8858b74d778b21.1322497088@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:08 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 11 of 12] xenalyze: Optimize pcpu_string
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

pcpu_string() is called on every line of the dump output,
and the basic loop is O(N) with the number of pcpus.  There
was an optimization that would be O(1), but it had a bug so that
it never actually went into effect.

Put the optimization into effect, so that only the bits that need
to change are changed.

This means, however, that when other things change, like power
states or lost records, that other parts of the string need to
be redrawn.  Put in hooks to redraw when these kinds of things
change.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r dab5ba28630a -r b7d88a8858b7 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -1942,6 +1942,7 @@ struct {
 
 /* Function prototypes */
 char * pcpu_string(int pcpu);
+void pcpu_string_draw(struct pcpu_info *p);
 void process_generic(struct record_info *ri);
 void dump_generic(FILE *f, struct record_info *ri);
 ssize_t __read_record(int fd, struct trace_record *rec, loff_t offset);
@@ -6970,6 +6971,7 @@ void vcpu_prev_update(struct pcpu_info *
 set:
     pcpu_runstate_update(p, tsc);
     p->current = NULL;
+    pcpu_string_draw(p);
     runstate_update(prev, new_runstate, tsc);
 }
 
@@ -7051,6 +7053,7 @@ void vcpu_next_update(struct pcpu_info *
 
     next->p = p;
     p->current = next;
+    pcpu_string_draw(p);
     p->time.tsc = tsc;
     p->lost_record.seen_valid_schedule = 1;
 }
@@ -7089,6 +7092,7 @@ void vcpu_start(struct pcpu_info *p, str
     runstate_update(v, RUNSTATE_RUNNING, p->first_tsc);
     p->time.tsc = p->first_tsc;
     p->current = v;
+    pcpu_string_draw(p);
     v->p = p;
 }
 
@@ -7524,6 +7528,7 @@ void sched_default_vcpu_activate(struct 
     v->runstate.state = RUNSTATE_RUNNING;
 
     p->current = v;
+    pcpu_string_draw(p);
 }
 
 void sched_default_domain_init(void)
@@ -7825,7 +7830,10 @@ void pm_process(struct pcpu_info *p) {
                    ri->dump_header,
                    ri->d[0]);
         if ( ri->d[0] <= CSTATE_MAX )
+        {
             p->power_state=ri->d[0];
+            pcpu_string_draw(p);
+        }
         break;
     case TRC_PM_IDLE_EXIT:
         if (opt.dump_all )
@@ -7837,6 +7845,7 @@ void pm_process(struct pcpu_info *p) {
             printf("Strange, pm_idle_end %d, power_state %d!\n",
                    ri->d[0], p->power_state);
         p->power_state = 0;
+        pcpu_string_draw(p);
         break;
     default:
         if(opt.dump_all || opt.dump_cooked) {
@@ -8437,6 +8446,7 @@ void process_lost_records(struct pcpu_in
 
     p->lost_record.active = 1;
     p->lost_record.tsc = first_tsc;
+    pcpu_string_draw(p);
     
     {
         /* Any vcpu which is not actively running may be scheduled on the
@@ -8520,6 +8530,7 @@ void process_lost_records_end(struct pcp
         
         
         p->lost_record.active = 0;
+        pcpu_string_draw(p);
         P.lost_cpus--;
         if(P.lost_cpus < 0) {
             fprintf(warn, "ERROR: lost_cpus fell below 0 for pcpu %d!\n",
@@ -9230,38 +9241,59 @@ ssize_t read_record(int fd, struct pcpu_
     return ri->size;
 }
 
-/* WARNING not thread-safe */
+/*
+ * This funciton gets called for every record when doing dump.  Try to
+ * make it efficient by changing the minimum amount from the last
+ * call.  Do this by:
+ * - Keeping track of the last pcpu called, so we can just set that to -
+ * - Keeping track of how many pcpus we've "drawn", and only "drawing" new ones
+ * - Updating the current one
+ *
+ * FIXME: Need to deal with pcpu states changing...
+ * 
+ * WARNING not thread-safe
+ */
+
+char __pcpu_string[MAX_CPUS+1] = { 0 };
+void pcpu_string_draw(struct pcpu_info *p)
+{
+    char *s = __pcpu_string;
+    int i=p->pid;
+
+    if(p->lost_record.active)
+        s[i]='l';
+    else if (!p->current)
+        s[i]=' ';
+    else if (p->current->d->did == DEFAULT_DOMAIN)
+        s[i]='.';
+    else if (p->current->d->did == IDLE_DOMAIN)
+    {
+        if ( opt.dump_show_power_states )
+            s[i]=p->power_state+'0';
+        else
+            s[i]='-';
+    }
+    else
+        s[i]='|';
+}
+
 char * pcpu_string(int pcpu)
 {
-    static char s[MAX_CPUS+1] = { 0 };
+    char *s = __pcpu_string;
     static int max_active_pcpu=-1, last_pcpu=-1;
     
     assert(P.max_active_pcpu < MAX_CPUS);
     assert(pcpu <= P.max_active_pcpu);
 
     if(last_pcpu >= 0)
-        s[last_pcpu]='-';
+        pcpu_string_draw(P.pcpu+last_pcpu);
 
     if(P.max_active_pcpu > max_active_pcpu)
     {
         int i;
-        for(i=max_active_pcpu + 1; i<= P.max_active_pcpu; i++) {
-            if(P.pcpu[i].lost_record.active)
-                s[i]='l';
-            else if (!P.pcpu[i].current)
-                s[i]=' ';
-            else if (P.pcpu[i].current->d->did == DEFAULT_DOMAIN)
-                s[i]='.';
-            else if (P.pcpu[i].current->d->did == IDLE_DOMAIN)
-            {
-                if ( opt.dump_show_power_states )
-                    s[i]=P.pcpu[i].power_state+'0';
-                else
-                    s[i]='-';
-            }
-            else
-                s[i]='|';
-        }
+        for(i=max_active_pcpu + 1; i<= P.max_active_pcpu; i++) 
+            pcpu_string_draw(P.pcpu+i);
+        max_active_pcpu=P.max_active_pcpu;
     }
 
     s[pcpu]='x';

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3te-0006kr-0n; Mon, 28 Nov 2011 16:17:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tc-0006jb-6U
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:32 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322496999!50058610!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25317 invoked from network); 28 Nov 2011 16:16:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047149"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:59 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS5015081;
	Mon, 28 Nov 2011 08:16:58 -0800
MIME-Version: 1.0
X-Mercurial-Node: b7d88a8858b74d778b21ec7894fc274793c5afe7
Message-ID: <b7d88a8858b74d778b21.1322497088@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:08 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 11 of 12] xenalyze: Optimize pcpu_string
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

pcpu_string() is called on every line of the dump output,
and the basic loop is O(N) with the number of pcpus.  There
was an optimization that would be O(1), but it had a bug so that
it never actually went into effect.

Put the optimization into effect, so that only the bits that need
to change are changed.

This means, however, that when other things change, like power
states or lost records, that other parts of the string need to
be redrawn.  Put in hooks to redraw when these kinds of things
change.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r dab5ba28630a -r b7d88a8858b7 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -1942,6 +1942,7 @@ struct {
 
 /* Function prototypes */
 char * pcpu_string(int pcpu);
+void pcpu_string_draw(struct pcpu_info *p);
 void process_generic(struct record_info *ri);
 void dump_generic(FILE *f, struct record_info *ri);
 ssize_t __read_record(int fd, struct trace_record *rec, loff_t offset);
@@ -6970,6 +6971,7 @@ void vcpu_prev_update(struct pcpu_info *
 set:
     pcpu_runstate_update(p, tsc);
     p->current = NULL;
+    pcpu_string_draw(p);
     runstate_update(prev, new_runstate, tsc);
 }
 
@@ -7051,6 +7053,7 @@ void vcpu_next_update(struct pcpu_info *
 
     next->p = p;
     p->current = next;
+    pcpu_string_draw(p);
     p->time.tsc = tsc;
     p->lost_record.seen_valid_schedule = 1;
 }
@@ -7089,6 +7092,7 @@ void vcpu_start(struct pcpu_info *p, str
     runstate_update(v, RUNSTATE_RUNNING, p->first_tsc);
     p->time.tsc = p->first_tsc;
     p->current = v;
+    pcpu_string_draw(p);
     v->p = p;
 }
 
@@ -7524,6 +7528,7 @@ void sched_default_vcpu_activate(struct 
     v->runstate.state = RUNSTATE_RUNNING;
 
     p->current = v;
+    pcpu_string_draw(p);
 }
 
 void sched_default_domain_init(void)
@@ -7825,7 +7830,10 @@ void pm_process(struct pcpu_info *p) {
                    ri->dump_header,
                    ri->d[0]);
         if ( ri->d[0] <= CSTATE_MAX )
+        {
             p->power_state=ri->d[0];
+            pcpu_string_draw(p);
+        }
         break;
     case TRC_PM_IDLE_EXIT:
         if (opt.dump_all )
@@ -7837,6 +7845,7 @@ void pm_process(struct pcpu_info *p) {
             printf("Strange, pm_idle_end %d, power_state %d!\n",
                    ri->d[0], p->power_state);
         p->power_state = 0;
+        pcpu_string_draw(p);
         break;
     default:
         if(opt.dump_all || opt.dump_cooked) {
@@ -8437,6 +8446,7 @@ void process_lost_records(struct pcpu_in
 
     p->lost_record.active = 1;
     p->lost_record.tsc = first_tsc;
+    pcpu_string_draw(p);
     
     {
         /* Any vcpu which is not actively running may be scheduled on the
@@ -8520,6 +8530,7 @@ void process_lost_records_end(struct pcp
         
         
         p->lost_record.active = 0;
+        pcpu_string_draw(p);
         P.lost_cpus--;
         if(P.lost_cpus < 0) {
             fprintf(warn, "ERROR: lost_cpus fell below 0 for pcpu %d!\n",
@@ -9230,38 +9241,59 @@ ssize_t read_record(int fd, struct pcpu_
     return ri->size;
 }
 
-/* WARNING not thread-safe */
+/*
+ * This funciton gets called for every record when doing dump.  Try to
+ * make it efficient by changing the minimum amount from the last
+ * call.  Do this by:
+ * - Keeping track of the last pcpu called, so we can just set that to -
+ * - Keeping track of how many pcpus we've "drawn", and only "drawing" new ones
+ * - Updating the current one
+ *
+ * FIXME: Need to deal with pcpu states changing...
+ * 
+ * WARNING not thread-safe
+ */
+
+char __pcpu_string[MAX_CPUS+1] = { 0 };
+void pcpu_string_draw(struct pcpu_info *p)
+{
+    char *s = __pcpu_string;
+    int i=p->pid;
+
+    if(p->lost_record.active)
+        s[i]='l';
+    else if (!p->current)
+        s[i]=' ';
+    else if (p->current->d->did == DEFAULT_DOMAIN)
+        s[i]='.';
+    else if (p->current->d->did == IDLE_DOMAIN)
+    {
+        if ( opt.dump_show_power_states )
+            s[i]=p->power_state+'0';
+        else
+            s[i]='-';
+    }
+    else
+        s[i]='|';
+}
+
 char * pcpu_string(int pcpu)
 {
-    static char s[MAX_CPUS+1] = { 0 };
+    char *s = __pcpu_string;
     static int max_active_pcpu=-1, last_pcpu=-1;
     
     assert(P.max_active_pcpu < MAX_CPUS);
     assert(pcpu <= P.max_active_pcpu);
 
     if(last_pcpu >= 0)
-        s[last_pcpu]='-';
+        pcpu_string_draw(P.pcpu+last_pcpu);
 
     if(P.max_active_pcpu > max_active_pcpu)
     {
         int i;
-        for(i=max_active_pcpu + 1; i<= P.max_active_pcpu; i++) {
-            if(P.pcpu[i].lost_record.active)
-                s[i]='l';
-            else if (!P.pcpu[i].current)
-                s[i]=' ';
-            else if (P.pcpu[i].current->d->did == DEFAULT_DOMAIN)
-                s[i]='.';
-            else if (P.pcpu[i].current->d->did == IDLE_DOMAIN)
-            {
-                if ( opt.dump_show_power_states )
-                    s[i]=P.pcpu[i].power_state+'0';
-                else
-                    s[i]='-';
-            }
-            else
-                s[i]='|';
-        }
+        for(i=max_active_pcpu + 1; i<= P.max_active_pcpu; i++) 
+            pcpu_string_draw(P.pcpu+i);
+        max_active_pcpu=P.max_active_pcpu;
     }
 
     s[pcpu]='x';

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3te-0006lL-Lf; Mon, 28 Nov 2011 16:17:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tc-0006iP-RB
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:33 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322497014!4938512!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21057 invoked from network); 28 Nov 2011 16:16:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047116"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:54 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS0015081;
	Mon, 28 Nov 2011 08:16:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 910605f7ade3e4100dbf4f84094af74f7c9f0300
Message-ID: <910605f7ade3e4100dbf.1322497083@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:03 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 06 of 12] xenalyze: Relocate pio and mmio
	enumaration structs	to their own sub-struct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In preparation for the next patch, which does some MMIO reorganizing.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 463ac7003722 -r 910605f7ade3 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -1361,7 +1361,9 @@ struct hvm_data {
         /* IPI Latency */
         struct event_cycle_summary ipi_latency;
         int ipi_count[256];
-        struct io_address *mmio, *pio;
+        struct {
+            struct io_address *mmio, *pio;
+        } io;
     } summary;
 
     /* In-flight accumulation information */
@@ -3674,7 +3676,7 @@ void enumerate_mmio(struct hvm_data *h)
     struct pf_xen_extra *e = &h->inflight.pf_xen;
 
     if ( e->mmio_data_valid )
-        update_io_address(&h->summary.mmio, e->gpa, e->mmio_is_write, h->arc_cycles, e->va);
+        update_io_address(&h->summary.io.mmio, e->gpa, e->mmio_is_write, h->arc_cycles, e->va);
 }
 
 void hvm_mmio_assist_postprocess(struct hvm_data *h)
@@ -3874,7 +3876,7 @@ void hvm_io_write_postprocess(struct hvm
                h->inflight.io.val);
     }
     if(opt.with_pio_enumeration)
-        update_io_address(&h->summary.pio, h->inflight.io.port, 1, h->arc_cycles, 0);
+        update_io_address(&h->summary.io.pio, h->inflight.io.port, 1, h->arc_cycles, 0);
 }
 
 void hvm_io_read_postprocess(struct hvm_data *h)
@@ -3886,7 +3888,7 @@ void hvm_io_read_postprocess(struct hvm_
                h->inflight.io.val);
     }
     if(opt.with_pio_enumeration)
-        update_io_address(&h->summary.pio, h->inflight.io.port, 0, h->arc_cycles, 0);
+        update_io_address(&h->summary.io.pio, h->inflight.io.port, 0, h->arc_cycles, 0);
     if(opt.scatterplot_io && h->inflight.io.port == opt.scatterplot_io_port)
         scatterplot_vs_time(h->exit_tsc, P.now - h->exit_tsc);
 }
@@ -5492,8 +5494,8 @@ void hvm_summary(struct hvm_data *h) {
        if(h->summary.ipi_count[i])
            printf("    [%3d] %10d\n",
                   i, h->summary.ipi_count[i]);
-   hvm_io_address_summary(h->summary.pio, "IO address summary:");
-   hvm_io_address_summary(h->summary.mmio, "MMIO address summary:");
+   hvm_io_address_summary(h->summary.io.pio, "IO address summary:");
+   hvm_io_address_summary(h->summary.io.mmio, "MMIO address summary:");
 }
 
 /* ---- Shadow records ---- */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3te-0006lL-Lf; Mon, 28 Nov 2011 16:17:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tc-0006iP-RB
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:33 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322497014!4938512!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3MDk=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21057 invoked from network); 28 Nov 2011 16:16:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="172047116"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:54 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlS0015081;
	Mon, 28 Nov 2011 08:16:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 910605f7ade3e4100dbf4f84094af74f7c9f0300
Message-ID: <910605f7ade3e4100dbf.1322497083@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:18:03 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 06 of 12] xenalyze: Relocate pio and mmio
	enumaration structs	to their own sub-struct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In preparation for the next patch, which does some MMIO reorganizing.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 463ac7003722 -r 910605f7ade3 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -1361,7 +1361,9 @@ struct hvm_data {
         /* IPI Latency */
         struct event_cycle_summary ipi_latency;
         int ipi_count[256];
-        struct io_address *mmio, *pio;
+        struct {
+            struct io_address *mmio, *pio;
+        } io;
     } summary;
 
     /* In-flight accumulation information */
@@ -3674,7 +3676,7 @@ void enumerate_mmio(struct hvm_data *h)
     struct pf_xen_extra *e = &h->inflight.pf_xen;
 
     if ( e->mmio_data_valid )
-        update_io_address(&h->summary.mmio, e->gpa, e->mmio_is_write, h->arc_cycles, e->va);
+        update_io_address(&h->summary.io.mmio, e->gpa, e->mmio_is_write, h->arc_cycles, e->va);
 }
 
 void hvm_mmio_assist_postprocess(struct hvm_data *h)
@@ -3874,7 +3876,7 @@ void hvm_io_write_postprocess(struct hvm
                h->inflight.io.val);
     }
     if(opt.with_pio_enumeration)
-        update_io_address(&h->summary.pio, h->inflight.io.port, 1, h->arc_cycles, 0);
+        update_io_address(&h->summary.io.pio, h->inflight.io.port, 1, h->arc_cycles, 0);
 }
 
 void hvm_io_read_postprocess(struct hvm_data *h)
@@ -3886,7 +3888,7 @@ void hvm_io_read_postprocess(struct hvm_
                h->inflight.io.val);
     }
     if(opt.with_pio_enumeration)
-        update_io_address(&h->summary.pio, h->inflight.io.port, 0, h->arc_cycles, 0);
+        update_io_address(&h->summary.io.pio, h->inflight.io.port, 0, h->arc_cycles, 0);
     if(opt.scatterplot_io && h->inflight.io.port == opt.scatterplot_io_port)
         scatterplot_vs_time(h->exit_tsc, P.now - h->exit_tsc);
 }
@@ -5492,8 +5494,8 @@ void hvm_summary(struct hvm_data *h) {
        if(h->summary.ipi_count[i])
            printf("    [%3d] %10d\n",
                   i, h->summary.ipi_count[i]);
-   hvm_io_address_summary(h->summary.pio, "IO address summary:");
-   hvm_io_address_summary(h->summary.mmio, "MMIO address summary:");
+   hvm_io_address_summary(h->summary.io.pio, "IO address summary:");
+   hvm_io_address_summary(h->summary.io.mmio, "MMIO address summary:");
 }
 
 /* ---- Shadow records ---- */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3ta-0006iv-F5; Mon, 28 Nov 2011 16:17:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tY-0006i4-IM
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4880 invoked from network); 28 Nov 2011 16:16:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:18 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456947"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:51 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRu015081;
	Mon, 28 Nov 2011 08:16:50 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6650e492be5d5dfca72875f89b8de0d63304d69d
Message-ID: <6650e492be5d5dfca728.1322497079@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:17:59 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 02 of 12] xenalyze: Reorganize cr trace handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Reorganize the CR trace handling to take advantage of the
new summary handling. In particular, SVM has an exit per
CR register, while VMX has one exit for all CR accesses.
This allows them to coexist.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 2e85d4c4042e -r 6650e492be5d xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -4104,7 +4104,7 @@ void cr3_dump_list(struct cr3_value_stru
     free(qsort_array);
 }
 
-void hvm_cr3_write_summary(struct hvm_data *h, void *data) {
+void hvm_cr3_write_summary(struct hvm_data *h) {
     int j;
 
     for(j=0; j<RESYNCS_MAX; j++)
@@ -4116,18 +4116,12 @@ void hvm_cr3_write_summary(struct hvm_da
 
 void hvm_cr_write_summary(struct hvm_data *h, void *data)
 {
-    int i;
-
-    for(i=0; i<CR_MAX; i++)
-    {
-        PRINT_SUMMARY(h->summary.cr_write[i],
-                      "   cr%d ", i);
-        switch(i) {
-        case 3:
-            hvm_cr3_write_summary(h, NULL);
-            break;
-        }
-    }
+    int cr=(int)data;
+
+    PRINT_SUMMARY(h->summary.cr_write[cr],
+                  "   cr%d ", cr);
+    if ( cr==3 )
+        hvm_cr3_write_summary(h);
 }
 
 void hvm_cr_write_postprocess(struct hvm_data *h)
@@ -4208,20 +4202,39 @@ void hvm_cr_write_postprocess(struct hvm
     /* FIXME - deal with cr_read_summary */
     if(h->exit_reason < h->exit_reason_max)
     {
-        if ( opt.svm_mode ) {
-            /* For svm, only need a summary for cr3 */
-            if ( h->exit_reason == VMEXIT_CR3_WRITE )
-                hvm_set_summary_handler(h, hvm_cr3_write_summary, NULL);
-        } else {
-            /* For vmx, real mode may cause EXNMI exits on cr accesses */
-            if ( h->exit_reason !=  EXIT_REASON_EXCEPTION_NMI )
-                hvm_set_summary_handler(h, hvm_cr_write_summary, NULL);
+        /* Want a different "set" for each cr */
+        switch(h->inflight.cr_write.cr)
+        {
+#define case_cr(_x)                                                     \
+            case (_x):                                                  \
+                hvm_set_summary_handler(h, hvm_cr_write_summary, (void *)(_x)); \
+                break                              
+            case_cr(0);
+            case_cr(1);
+            case_cr(2);
+            case_cr(3);
+            case_cr(4);
+            case_cr(5);
+            case_cr(6);
+            case_cr(7);
+            case_cr(8);
+            case_cr(9);
+            case_cr(10);
+            case_cr(11);
+            case_cr(12);
+            case_cr(13);
+            case_cr(14);
+            case_cr(15);
+#undef case_cr
+        default:
+            fprintf(stderr, "Unexpected cr: %d\n", h->inflight.cr_write.cr);
+            error(ERR_SANITY, NULL);
+            break;
         }
     }
 }
 
 void hvm_exception_nmi_generic_postprocess(struct hvm_data *h);
-
 void hvm_cr_write_process(struct record_info *ri, struct hvm_data *h)
 {
     union {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:17:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:17:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV3ta-0006iv-F5; Mon, 28 Nov 2011 16:17:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RV3tY-0006i4-IM
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:17:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322496976!54909400!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDE3NDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4880 invoked from network); 28 Nov 2011 16:16:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:16:18 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208";a="19456947"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 11:16:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 11:16:51 -0500
Received: from [127.0.1.1] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pASGGlRu015081;
	Mon, 28 Nov 2011 08:16:50 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6650e492be5d5dfca72875f89b8de0d63304d69d
Message-ID: <6650e492be5d5dfca728.1322497079@elijah>
In-Reply-To: <patchbomb.1322497077@elijah>
References: <patchbomb.1322497077@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 28 Nov 2011 16:17:59 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 02 of 12] xenalyze: Reorganize cr trace handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Reorganize the CR trace handling to take advantage of the
new summary handling. In particular, SVM has an exit per
CR register, while VMX has one exit for all CR accesses.
This allows them to coexist.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 2e85d4c4042e -r 6650e492be5d xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
@@ -4104,7 +4104,7 @@ void cr3_dump_list(struct cr3_value_stru
     free(qsort_array);
 }
 
-void hvm_cr3_write_summary(struct hvm_data *h, void *data) {
+void hvm_cr3_write_summary(struct hvm_data *h) {
     int j;
 
     for(j=0; j<RESYNCS_MAX; j++)
@@ -4116,18 +4116,12 @@ void hvm_cr3_write_summary(struct hvm_da
 
 void hvm_cr_write_summary(struct hvm_data *h, void *data)
 {
-    int i;
-
-    for(i=0; i<CR_MAX; i++)
-    {
-        PRINT_SUMMARY(h->summary.cr_write[i],
-                      "   cr%d ", i);
-        switch(i) {
-        case 3:
-            hvm_cr3_write_summary(h, NULL);
-            break;
-        }
-    }
+    int cr=(int)data;
+
+    PRINT_SUMMARY(h->summary.cr_write[cr],
+                  "   cr%d ", cr);
+    if ( cr==3 )
+        hvm_cr3_write_summary(h);
 }
 
 void hvm_cr_write_postprocess(struct hvm_data *h)
@@ -4208,20 +4202,39 @@ void hvm_cr_write_postprocess(struct hvm
     /* FIXME - deal with cr_read_summary */
     if(h->exit_reason < h->exit_reason_max)
     {
-        if ( opt.svm_mode ) {
-            /* For svm, only need a summary for cr3 */
-            if ( h->exit_reason == VMEXIT_CR3_WRITE )
-                hvm_set_summary_handler(h, hvm_cr3_write_summary, NULL);
-        } else {
-            /* For vmx, real mode may cause EXNMI exits on cr accesses */
-            if ( h->exit_reason !=  EXIT_REASON_EXCEPTION_NMI )
-                hvm_set_summary_handler(h, hvm_cr_write_summary, NULL);
+        /* Want a different "set" for each cr */
+        switch(h->inflight.cr_write.cr)
+        {
+#define case_cr(_x)                                                     \
+            case (_x):                                                  \
+                hvm_set_summary_handler(h, hvm_cr_write_summary, (void *)(_x)); \
+                break                              
+            case_cr(0);
+            case_cr(1);
+            case_cr(2);
+            case_cr(3);
+            case_cr(4);
+            case_cr(5);
+            case_cr(6);
+            case_cr(7);
+            case_cr(8);
+            case_cr(9);
+            case_cr(10);
+            case_cr(11);
+            case_cr(12);
+            case_cr(13);
+            case_cr(14);
+            case_cr(15);
+#undef case_cr
+        default:
+            fprintf(stderr, "Unexpected cr: %d\n", h->inflight.cr_write.cr);
+            error(ERR_SANITY, NULL);
+            break;
         }
     }
 }
 
 void hvm_exception_nmi_generic_postprocess(struct hvm_data *h);
-
 void hvm_cr_write_process(struct record_info *ri, struct hvm_data *h)
 {
     union {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:28:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:28:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV43Y-0000P1-DQ; Mon, 28 Nov 2011 16:27:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV43X-0000Ow-L6
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:27:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322497620!56856581!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15226 invoked from network); 28 Nov 2011 16:27:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:27:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9168400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:26:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 16:26:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Mon, 28 Nov 2011 16:26:53 +0000
In-Reply-To: <1322431628-21760-3-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322497613.20646.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-11-27 at 22:07 +0000, Bastian Blank wrote:
> @@ -84,7 +85,7 @@ static int xenfs_fill_super(struct super_block *sb,
> void *data, int silent)
>                 [1] = {},
>                 { "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
>                 { "capabilities", &capabilities_file_ops, S_IRUGO },
> -               { "privcmd", &privcmd_file_ops, S_IRUSR|S_IWUSR },
> +               { "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
>                 {""},
>         };
>         int rc; 

I wonder if we could do something dumb like make /proc/xen/privcmd by a
symlink to /dev/xen/privcmd instead of introducing this cross module
dependency?

The main reason would be to avoid the select since selecting on user
visible symbols is a recipe for confusion and is generally advised
against.

Perhaps the xen-privcmd.ko should simply call a newly introduced
xenfs_register()? This would be a nop if CONFIG_XENFS=n and therefore
the select would not be necessary. If COFIG_XENFS=[my] then modprobe
will do the right thing.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:28:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:28:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV43Y-0000P1-DQ; Mon, 28 Nov 2011 16:27:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV43X-0000Ow-L6
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:27:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322497620!56856581!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15226 invoked from network); 28 Nov 2011 16:27:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:27:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9168400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:26:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 16:26:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Mon, 28 Nov 2011 16:26:53 +0000
In-Reply-To: <1322431628-21760-3-git-send-email-waldi@debian.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322497613.20646.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2011-11-27 at 22:07 +0000, Bastian Blank wrote:
> @@ -84,7 +85,7 @@ static int xenfs_fill_super(struct super_block *sb,
> void *data, int silent)
>                 [1] = {},
>                 { "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
>                 { "capabilities", &capabilities_file_ops, S_IRUGO },
> -               { "privcmd", &privcmd_file_ops, S_IRUSR|S_IWUSR },
> +               { "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
>                 {""},
>         };
>         int rc; 

I wonder if we could do something dumb like make /proc/xen/privcmd by a
symlink to /dev/xen/privcmd instead of introducing this cross module
dependency?

The main reason would be to avoid the select since selecting on user
visible symbols is a recipe for confusion and is generally advised
against.

Perhaps the xen-privcmd.ko should simply call a newly introduced
xenfs_register()? This would be a nop if CONFIG_XENFS=n and therefore
the select would not be necessary. If COFIG_XENFS=[my] then modprobe
will do the right thing.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:41:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:41:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4GB-0000c7-Tp; Mon, 28 Nov 2011 16:40:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4GA-0000c2-KZ
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:40:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322498414!5365948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14681 invoked from network); 28 Nov 2011 16:40:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:40:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9168743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:40:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:40:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4FZ-0004yS-8h; Mon, 28 Nov 2011 16:40:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4FY-0005Ze-OS;
	Mon, 28 Nov 2011 16:40:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.47462.815671.301622@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 16:40:06 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
	after	statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration after statement"):
> I think it would make sense to add to the CODING_STYLE that variable
> declarations shouldn't be mixed with code, unless part of a macro or an
> alloca-like construct.

I think this is a silly rule.  In my proposed commit message I
advanced three reasons for allowing declaration after statement:

> >  * It allows variables to be more often initialised as they are
> >    declared, thus reducing the occurrence of uninitialised variable
> >    errors.
> > 
> >  * Certain alloca-like constructs (arrays allocated at runtime on the
> >    stack) can more often be written without a spurious { } block.
> >    Such blocks are confusing to read.
> >
> >  * It makes it easier to write and use macros which declare and
> >    initialise formulaic variables and do other function setup code,
> >    because there is no need to worry that such macros might be
> >    incompatible with each other or have strict ordering constraints.

Of these the first two improvements would be banned by your proposed
coding style rule.

I don't understand what the harm is in allowing declarations, with
initialisation, freely mixed with code.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:41:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:41:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4GB-0000c7-Tp; Mon, 28 Nov 2011 16:40:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4GA-0000c2-KZ
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:40:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322498414!5365948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14681 invoked from network); 28 Nov 2011 16:40:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:40:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; 
   d="scan'208";a="9168743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:40:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:40:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4FZ-0004yS-8h; Mon, 28 Nov 2011 16:40:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4FY-0005Ze-OS;
	Mon, 28 Nov 2011 16:40:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.47462.815671.301622@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 16:40:06 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
	after	statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration after statement"):
> I think it would make sense to add to the CODING_STYLE that variable
> declarations shouldn't be mixed with code, unless part of a macro or an
> alloca-like construct.

I think this is a silly rule.  In my proposed commit message I
advanced three reasons for allowing declaration after statement:

> >  * It allows variables to be more often initialised as they are
> >    declared, thus reducing the occurrence of uninitialised variable
> >    errors.
> > 
> >  * Certain alloca-like constructs (arrays allocated at runtime on the
> >    stack) can more often be written without a spurious { } block.
> >    Such blocks are confusing to read.
> >
> >  * It makes it easier to write and use macros which declare and
> >    initialise formulaic variables and do other function setup code,
> >    because there is no need to worry that such macros might be
> >    incompatible with each other or have strict ordering constraints.

Of these the first two improvements would be banned by your proposed
coding style rule.

I don't understand what the harm is in allowing declarations, with
initialisation, freely mixed with code.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:47:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4MI-0000pt-PI; Mon, 28 Nov 2011 16:47:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RV4MH-0000pj-9K
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:47:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322498790!5294571!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQwODczMw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28210 invoked from network); 28 Nov 2011 16:46:32 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 16:46:32 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pASGjfom008640
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 28 Nov 2011 16:45:42 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pASGjeZ5013723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 28 Nov 2011 16:45:41 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pASGjYcO030124; Mon, 28 Nov 2011 10:45:35 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 28 Nov 2011 08:45:34 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 3AE0E41C10;
	Mon, 28 Nov 2011 11:45:17 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pASGjG9T027070;
	Mon, 28 Nov 2011 11:45:16 -0500
Date: Mon, 28 Nov 2011 11:45:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111128164516.GA26664@phenom.dumpdata.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322494816.20646.14.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4ED3BAB7.001B,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 03:40:13PM +0000, Ian Campbell wrote:
> On Mon, 2011-11-28 at 15:28 +0000, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:
> 
> > > I looked through my old mails from you and you explained already the necessity of double
> > > bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
> > > Xenified kernel not have this kind of issue?
> > 
> > That is a puzzle. It should not. The code is very much the same - both
> > use the generic SWIOTLB which has not changed for years.
> 
> The swiotlb-xen used by classic-xen kernels (which I assume is what
> Carsten means by "Xenified") isn't exactly the same as the stuff in
> mainline Linux, it's been heavily refactored for one thing. It's not
> impossible that mainline is bouncing something it doesn't really need
> to.

The usage, at least with 'pci_alloc_coherent' is that there is no bouncing
being done. The alloc_coherent will allocate a nice page, underneath the 4GB
mark and give it to the driver. The driver can use it as it wishes and there
is no need to bounce buffer.

But I can't find the implementation of that in the classic Xen-SWIOTLB. It looks
as if it is using map_single which would be taking the memory out of the
pool for a very long time, instead of allocating memory and "swizzling" the MFNs.
[Note, I looked at the 2.6.18 hg tree for classic, the 2.6.34 is probably
improved much better so let me check that]

Carsten, let me prep up a patch that will print some diagnostic information
during the runtime - to see how often it does the bounce, the usage, etc..

> 
> It's also possible that the dma mask of the device is different/wrong in
> mainline leading to such additional bouncing.

If one were to use map_page and such - yes. But the alloc_coherent bypasses
that and ends up allocating it right under the 4GB (or rather it allocates
based on the dev->coherent_mask and swizzles the MFNs as required).

> 
> I guess it's also possible that the classic-Xen kernels are playing fast
> and loose by not bouncing something they should (although if so they
> appear to be getting away with it...) or that there is some difference
> which really means mainline needs to bounce while classic-Xen doesn't.

<nods> Could be very well.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:47:28 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4MI-0000pt-PI; Mon, 28 Nov 2011 16:47:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RV4MH-0000pj-9K
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:47:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322498790!5294571!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQwODczMw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28210 invoked from network); 28 Nov 2011 16:46:32 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 16:46:32 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pASGjfom008640
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 28 Nov 2011 16:45:42 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pASGjeZ5013723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 28 Nov 2011 16:45:41 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pASGjYcO030124; Mon, 28 Nov 2011 10:45:35 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 28 Nov 2011 08:45:34 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 3AE0E41C10;
	Mon, 28 Nov 2011 11:45:17 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pASGjG9T027070;
	Mon, 28 Nov 2011 11:45:16 -0500
Date: Mon, 28 Nov 2011 11:45:16 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111128164516.GA26664@phenom.dumpdata.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322494816.20646.14.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4ED3BAB7.001B,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 03:40:13PM +0000, Ian Campbell wrote:
> On Mon, 2011-11-28 at 15:28 +0000, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:
> 
> > > I looked through my old mails from you and you explained already the necessity of double
> > > bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
> > > Xenified kernel not have this kind of issue?
> > 
> > That is a puzzle. It should not. The code is very much the same - both
> > use the generic SWIOTLB which has not changed for years.
> 
> The swiotlb-xen used by classic-xen kernels (which I assume is what
> Carsten means by "Xenified") isn't exactly the same as the stuff in
> mainline Linux, it's been heavily refactored for one thing. It's not
> impossible that mainline is bouncing something it doesn't really need
> to.

The usage, at least with 'pci_alloc_coherent' is that there is no bouncing
being done. The alloc_coherent will allocate a nice page, underneath the 4GB
mark and give it to the driver. The driver can use it as it wishes and there
is no need to bounce buffer.

But I can't find the implementation of that in the classic Xen-SWIOTLB. It looks
as if it is using map_single which would be taking the memory out of the
pool for a very long time, instead of allocating memory and "swizzling" the MFNs.
[Note, I looked at the 2.6.18 hg tree for classic, the 2.6.34 is probably
improved much better so let me check that]

Carsten, let me prep up a patch that will print some diagnostic information
during the runtime - to see how often it does the bounce, the usage, etc..

> 
> It's also possible that the dma mask of the device is different/wrong in
> mainline leading to such additional bouncing.

If one were to use map_page and such - yes. But the alloc_coherent bypasses
that and ends up allocating it right under the 4GB (or rather it allocates
based on the dev->coherent_mask and swizzles the MFNs as required).

> 
> I guess it's also possible that the classic-Xen kernels are playing fast
> and loose by not bouncing something they should (although if so they
> appear to be getting away with it...) or that there is some difference
> which really means mainline needs to bounce while classic-Xen doesn't.

<nods> Could be very well.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Ox-00017e-HH; Mon, 28 Nov 2011 16:49:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ov-00015r-Vc
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322498914!55190484!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20681 invoked from network); 28 Nov 2011 16:48:35 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-27.messagelabs.com with SMTP;
	28 Nov 2011 16:48:35 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnF13010796; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQN030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:03 -0500
Message-Id: <1322498951-4392-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 04/12] xen/blkback: use grant-table.c hypercall
	wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/block/xen-blkback/blkback.c |   29 ++++-------------------------
 1 files changed, 4 insertions(+), 25 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 15ec4db..1e256dc 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -324,6 +324,7 @@ struct seg_buf {
 static void xen_blkbk_unmap(struct pending_req *req)
 {
 	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 	unsigned int i, invcount = 0;
 	grant_handle_t handle;
 	int ret;
@@ -335,25 +336,12 @@ static void xen_blkbk_unmap(struct pending_req *req)
 		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
 				    GNTMAP_host_map, handle);
 		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
+		pages[invcount] = virt_to_page(vaddr(req, i));
 		invcount++;
 	}
 
-	ret = HYPERVISOR_grant_table_op(
-		GNTTABOP_unmap_grant_ref, unmap, invcount);
+	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
 	BUG_ON(ret);
-	/*
-	 * Note, we use invcount, so nr->pages, so we can't index
-	 * using vaddr(req, i).
-	 */
-	for (i = 0; i < invcount; i++) {
-		ret = m2p_remove_override(
-			virt_to_page(unmap[i].host_addr), false);
-		if (ret) {
-			pr_alert(DRV_PFX "Failed to remove M2P override for %lx\n",
-				 (unsigned long)unmap[i].host_addr);
-			continue;
-		}
-	}
 }
 
 static int xen_blkbk_map(struct blkif_request *req,
@@ -381,7 +369,7 @@ static int xen_blkbk_map(struct blkif_request *req,
 				  pending_req->blkif->domid);
 	}
 
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, nseg);
+	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
 	BUG_ON(ret);
 
 	/*
@@ -401,15 +389,6 @@ static int xen_blkbk_map(struct blkif_request *req,
 		if (ret)
 			continue;
 
-		ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr),
-			blkbk->pending_page(pending_req, i), NULL);
-		if (ret) {
-			pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n",
-				 (unsigned long)map[i].dev_bus_addr, ret);
-			/* We could switch over to GNTTABOP_copy */
-			continue;
-		}
-
 		seg[i].buf  = map[i].dev_bus_addr |
 			(req->u.rw.seg[i].first_sect << 9);
 	}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Ox-00017e-HH; Mon, 28 Nov 2011 16:49:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ov-00015r-Vc
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322498914!55190484!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20681 invoked from network); 28 Nov 2011 16:48:35 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-27.messagelabs.com with SMTP;
	28 Nov 2011 16:48:35 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnF13010796; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQN030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:03 -0500
Message-Id: <1322498951-4392-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 04/12] xen/blkback: use grant-table.c hypercall
	wrappers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/block/xen-blkback/blkback.c |   29 ++++-------------------------
 1 files changed, 4 insertions(+), 25 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 15ec4db..1e256dc 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -324,6 +324,7 @@ struct seg_buf {
 static void xen_blkbk_unmap(struct pending_req *req)
 {
 	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 	unsigned int i, invcount = 0;
 	grant_handle_t handle;
 	int ret;
@@ -335,25 +336,12 @@ static void xen_blkbk_unmap(struct pending_req *req)
 		gnttab_set_unmap_op(&unmap[invcount], vaddr(req, i),
 				    GNTMAP_host_map, handle);
 		pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
+		pages[invcount] = virt_to_page(vaddr(req, i));
 		invcount++;
 	}
 
-	ret = HYPERVISOR_grant_table_op(
-		GNTTABOP_unmap_grant_ref, unmap, invcount);
+	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
 	BUG_ON(ret);
-	/*
-	 * Note, we use invcount, so nr->pages, so we can't index
-	 * using vaddr(req, i).
-	 */
-	for (i = 0; i < invcount; i++) {
-		ret = m2p_remove_override(
-			virt_to_page(unmap[i].host_addr), false);
-		if (ret) {
-			pr_alert(DRV_PFX "Failed to remove M2P override for %lx\n",
-				 (unsigned long)unmap[i].host_addr);
-			continue;
-		}
-	}
 }
 
 static int xen_blkbk_map(struct blkif_request *req,
@@ -381,7 +369,7 @@ static int xen_blkbk_map(struct blkif_request *req,
 				  pending_req->blkif->domid);
 	}
 
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, nseg);
+	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
 	BUG_ON(ret);
 
 	/*
@@ -401,15 +389,6 @@ static int xen_blkbk_map(struct blkif_request *req,
 		if (ret)
 			continue;
 
-		ret = m2p_add_override(PFN_DOWN(map[i].dev_bus_addr),
-			blkbk->pending_page(pending_req, i), NULL);
-		if (ret) {
-			pr_alert(DRV_PFX "Failed to install M2P override for %lx (ret: %d)\n",
-				 (unsigned long)map[i].dev_bus_addr, ret);
-			/* We could switch over to GNTTABOP_copy */
-			continue;
-		}
-
 		seg[i].buf  = map[i].dev_bus_addr |
 			(req->u.rw.seg[i].first_sect << 9);
 	}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Ow-00016y-34; Mon, 28 Nov 2011 16:49:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ou-000166-M1
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:52 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322498927!54571791!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4578 invoked from network); 28 Nov 2011 16:48:48 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-27.messagelabs.com with SMTP;
	28 Nov 2011 16:48:48 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnGpt015028; Mon, 28 Nov 2011 16:49:16 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQV030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:11 -0500
Message-Id: <1322498951-4392-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 12/12] xen/gntalloc: fix reference counts on
	multi-page mappings
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When a multi-page mapping of gntalloc is created, the reference counts
of all pages in the vma are incremented. However, the vma open/close
operations only adjusted the reference count of the first page in the
mapping, leaking the other pages. Store a struct in the vm_private_data
to track the original page count to properly free the pages when the
last reference to the vma is closed.

Reported-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntalloc.c |   56 ++++++++++++++++++++++++++++++++++++-----------
 1 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 7b936cc..e2400c8 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -99,6 +99,12 @@ struct gntalloc_file_private_data {
 	uint64_t index;
 };
 
+struct gntalloc_vma_private_data {
+	struct gntalloc_gref *gref;
+	int users;
+	int count;
+};
+
 static void __del_gref(struct gntalloc_gref *gref);
 
 static void do_cleanup(void)
@@ -451,25 +457,39 @@ static long gntalloc_ioctl(struct file *filp, unsigned int cmd,
 
 static void gntalloc_vma_open(struct vm_area_struct *vma)
 {
-	struct gntalloc_gref *gref = vma->vm_private_data;
-	if (!gref)
+	struct gntalloc_vma_private_data *priv = vma->vm_private_data;
+
+	if (!priv)
 		return;
 
 	mutex_lock(&gref_mutex);
-	gref->users++;
+	priv->users++;
 	mutex_unlock(&gref_mutex);
 }
 
 static void gntalloc_vma_close(struct vm_area_struct *vma)
 {
-	struct gntalloc_gref *gref = vma->vm_private_data;
-	if (!gref)
+	struct gntalloc_vma_private_data *priv = vma->vm_private_data;
+	struct gntalloc_gref *gref, *next;
+	int i;
+
+	if (!priv)
 		return;
 
 	mutex_lock(&gref_mutex);
-	gref->users--;
-	if (gref->users == 0)
-		__del_gref(gref);
+	priv->users--;
+	if (priv->users == 0) {
+		gref = priv->gref;
+		for (i = 0; i < priv->count; i++) {
+			gref->users--;
+			next = list_entry(gref->next_gref.next,
+					  struct gntalloc_gref, next_gref);
+			if (gref->users == 0)
+				__del_gref(gref);
+			gref = next;
+		}
+		kfree(priv);
+	}
 	mutex_unlock(&gref_mutex);
 }
 
@@ -481,19 +501,25 @@ static struct vm_operations_struct gntalloc_vmops = {
 static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 {
 	struct gntalloc_file_private_data *priv = filp->private_data;
+	struct gntalloc_vma_private_data *vm_priv;
 	struct gntalloc_gref *gref;
 	int count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
 	int rv, i;
 
-	pr_debug("%s: priv %p, page %lu+%d\n", __func__,
-		       priv, vma->vm_pgoff, count);
-
 	if (!(vma->vm_flags & VM_SHARED)) {
 		printk(KERN_ERR "%s: Mapping must be shared.\n", __func__);
 		return -EINVAL;
 	}
 
+	vm_priv = kmalloc(sizeof(*vm_priv), GFP_KERNEL);
+	if (!vm_priv)
+		return -ENOMEM;
+
 	mutex_lock(&gref_mutex);
+
+	pr_debug("%s: priv %p,%p, page %lu+%d\n", __func__,
+		       priv, vm_priv, vma->vm_pgoff, count);
+
 	gref = find_grefs(priv, vma->vm_pgoff << PAGE_SHIFT, count);
 	if (gref == NULL) {
 		rv = -ENOENT;
@@ -502,9 +528,13 @@ static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 		goto out_unlock;
 	}
 
-	vma->vm_private_data = gref;
+	vm_priv->gref = gref;
+	vm_priv->users = 1;
+	vm_priv->count = count;
+
+	vma->vm_private_data = vm_priv;
 
-	vma->vm_flags |= VM_RESERVED;
+	vma->vm_flags |= VM_RESERVED | VM_DONTEXPAND;
 
 	vma->vm_ops = &gntalloc_vmops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Ow-00016y-34; Mon, 28 Nov 2011 16:49:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ou-000166-M1
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:52 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322498927!54571791!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4578 invoked from network); 28 Nov 2011 16:48:48 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-27.messagelabs.com with SMTP;
	28 Nov 2011 16:48:48 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnGpt015028; Mon, 28 Nov 2011 16:49:16 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQV030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:11 -0500
Message-Id: <1322498951-4392-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 12/12] xen/gntalloc: fix reference counts on
	multi-page mappings
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When a multi-page mapping of gntalloc is created, the reference counts
of all pages in the vma are incremented. However, the vma open/close
operations only adjusted the reference count of the first page in the
mapping, leaking the other pages. Store a struct in the vm_private_data
to track the original page count to properly free the pages when the
last reference to the vma is closed.

Reported-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntalloc.c |   56 ++++++++++++++++++++++++++++++++++++-----------
 1 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 7b936cc..e2400c8 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -99,6 +99,12 @@ struct gntalloc_file_private_data {
 	uint64_t index;
 };
 
+struct gntalloc_vma_private_data {
+	struct gntalloc_gref *gref;
+	int users;
+	int count;
+};
+
 static void __del_gref(struct gntalloc_gref *gref);
 
 static void do_cleanup(void)
@@ -451,25 +457,39 @@ static long gntalloc_ioctl(struct file *filp, unsigned int cmd,
 
 static void gntalloc_vma_open(struct vm_area_struct *vma)
 {
-	struct gntalloc_gref *gref = vma->vm_private_data;
-	if (!gref)
+	struct gntalloc_vma_private_data *priv = vma->vm_private_data;
+
+	if (!priv)
 		return;
 
 	mutex_lock(&gref_mutex);
-	gref->users++;
+	priv->users++;
 	mutex_unlock(&gref_mutex);
 }
 
 static void gntalloc_vma_close(struct vm_area_struct *vma)
 {
-	struct gntalloc_gref *gref = vma->vm_private_data;
-	if (!gref)
+	struct gntalloc_vma_private_data *priv = vma->vm_private_data;
+	struct gntalloc_gref *gref, *next;
+	int i;
+
+	if (!priv)
 		return;
 
 	mutex_lock(&gref_mutex);
-	gref->users--;
-	if (gref->users == 0)
-		__del_gref(gref);
+	priv->users--;
+	if (priv->users == 0) {
+		gref = priv->gref;
+		for (i = 0; i < priv->count; i++) {
+			gref->users--;
+			next = list_entry(gref->next_gref.next,
+					  struct gntalloc_gref, next_gref);
+			if (gref->users == 0)
+				__del_gref(gref);
+			gref = next;
+		}
+		kfree(priv);
+	}
 	mutex_unlock(&gref_mutex);
 }
 
@@ -481,19 +501,25 @@ static struct vm_operations_struct gntalloc_vmops = {
 static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 {
 	struct gntalloc_file_private_data *priv = filp->private_data;
+	struct gntalloc_vma_private_data *vm_priv;
 	struct gntalloc_gref *gref;
 	int count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
 	int rv, i;
 
-	pr_debug("%s: priv %p, page %lu+%d\n", __func__,
-		       priv, vma->vm_pgoff, count);
-
 	if (!(vma->vm_flags & VM_SHARED)) {
 		printk(KERN_ERR "%s: Mapping must be shared.\n", __func__);
 		return -EINVAL;
 	}
 
+	vm_priv = kmalloc(sizeof(*vm_priv), GFP_KERNEL);
+	if (!vm_priv)
+		return -ENOMEM;
+
 	mutex_lock(&gref_mutex);
+
+	pr_debug("%s: priv %p,%p, page %lu+%d\n", __func__,
+		       priv, vm_priv, vma->vm_pgoff, count);
+
 	gref = find_grefs(priv, vma->vm_pgoff << PAGE_SHIFT, count);
 	if (gref == NULL) {
 		rv = -ENOENT;
@@ -502,9 +528,13 @@ static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 		goto out_unlock;
 	}
 
-	vma->vm_private_data = gref;
+	vm_priv->gref = gref;
+	vm_priv->users = 1;
+	vm_priv->count = count;
+
+	vma->vm_private_data = vm_priv;
 
-	vma->vm_flags |= VM_RESERVED;
+	vma->vm_flags |= VM_RESERVED | VM_DONTEXPAND;
 
 	vma->vm_ops = &gntalloc_vmops;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4P1-0001Ad-Oa; Mon, 28 Nov 2011 16:49:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Oz-00016U-8u
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322498958!6695734!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28347 invoked from network); 28 Nov 2011 16:49:19 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-216.messagelabs.com with SMTP;
	28 Nov 2011 16:49:19 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnF13010794; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQK030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:00 -0500
Message-Id: <1322498951-4392-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 01/12] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
that ring mappings can be done without using GNTMAP_contains_pte which
is not supported on HVM.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
 1 files changed, 125 insertions(+), 30 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..688c4b4 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -32,16 +32,27 @@
 
 #include <linux/slab.h>
 #include <linux/types.h>
+#include <linux/spinlock.h>
 #include <linux/vmalloc.h>
 #include <linux/export.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/event_channel.h>
+#include <xen/balloon.h>
 #include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct xenbus_map_node {
+	struct list_head next;
+	struct page *page;
+	grant_handle_t handle;
+};
+
+static DEFINE_SPINLOCK(xenbus_valloc_lock);
+static LIST_HEAD(xenbus_valloc_pages);
+
 const char *xenbus_strstate(enum xenbus_state state)
 {
 	static const char *const name[] = {
@@ -420,21 +431,8 @@ int xenbus_free_evtchn(struct xenbus_device *dev, int port)
 EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 
 
-/**
- * xenbus_map_ring_valloc
- * @dev: xenbus device
- * @gnt_ref: grant reference
- * @vaddr: pointer to address to be filled out by mapping
- *
- * Based on Rusty Russell's skeleton driver's map_page.
- * Map a page of memory into this domain from another domain's grant table.
- * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
- * page to that address, and sets *vaddr to that address.
- * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
- * or -ENOMEM on error. If an error is returned, device will switch to
- * XenbusStateClosing and the error message will be saved in XenStore.
- */
-int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
+                                     int gnt_ref, void **vaddr)
 {
 	struct gnttab_map_grant_ref op = {
 		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
@@ -469,6 +467,64 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 	*vaddr = area->addr;
 	return 0;
 }
+
+static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
+                                     int gnt_ref, void **vaddr)
+{
+	struct xenbus_map_node *node;
+	int err;
+	void *addr;
+
+	*vaddr = NULL;
+
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
+	err = alloc_xenballooned_pages(1, &node->page, false);
+	if (err)
+		goto out_err;
+
+	addr = pfn_to_kaddr(page_to_pfn(node->page));
+
+	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	if (err)
+		goto out_err;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
+
+	*vaddr = addr;
+	return 0;
+
+ out_err:
+	free_xenballooned_pages(1, &node->page);
+	kfree(node);
+	return err;
+}
+
+/**
+ * xenbus_map_ring_valloc
+ * @dev: xenbus device
+ * @gnt_ref: grant reference
+ * @vaddr: pointer to address to be filled out by mapping
+ *
+ * Based on Rusty Russell's skeleton driver's map_page.
+ * Map a page of memory into this domain from another domain's grant table.
+ * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
+ * page to that address, and sets *vaddr to that address.
+ * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
+ * or -ENOMEM on error. If an error is returned, device will switch to
+ * XenbusStateClosing and the error message will be saved in XenStore.
+ */
+int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
+	else
+		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
+}
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
 
@@ -510,20 +566,7 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring);
 
-
-/**
- * xenbus_unmap_ring_vfree
- * @dev: xenbus device
- * @vaddr: addr to unmap
- *
- * Based on Rusty Russell's skeleton driver's unmap_page.
- * Unmap a page of memory in this domain that was imported from another domain.
- * Use xenbus_unmap_ring_vfree if you mapped in your memory with
- * xenbus_map_ring_valloc (it will free the virtual address space).
- * Returns 0 on success and returns GNTST_* on error
- * (see xen/include/interface/grant_table.h).
- */
-int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 {
 	struct vm_struct *area;
 	struct gnttab_unmap_grant_ref op = {
@@ -566,8 +609,60 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 
 	return op.status;
 }
-EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
+static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
+{
+	int rv;
+	struct xenbus_map_node *node;
+	void *addr;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		addr = pfn_to_kaddr(page_to_pfn(node->page));
+		if (addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
+	}
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
+
+	if (!node) {
+		xenbus_dev_error(dev, -ENOENT,
+				 "can't find mapped virtual address %p", vaddr);
+		return -ENOENT;
+	}
+
+	rv = xenbus_unmap_ring(dev, node->handle, addr);
+
+	if (!rv)
+		free_xenballooned_pages(1, &node->page);
+
+	kfree(node);
+	return rv;
+}
+
+/**
+ * xenbus_unmap_ring_vfree
+ * @dev: xenbus device
+ * @vaddr: addr to unmap
+ *
+ * Based on Rusty Russell's skeleton driver's unmap_page.
+ * Unmap a page of memory in this domain that was imported from another domain.
+ * Use xenbus_unmap_ring_vfree if you mapped in your memory with
+ * xenbus_map_ring_valloc (it will free the virtual address space).
+ * Returns 0 on success and returns GNTST_* on error
+ * (see xen/include/interface/grant_table.h).
+ */
+int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
+	else
+		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
+}
+EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
 /**
  * xenbus_unmap_ring
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Oy-00018J-PI; Mon, 28 Nov 2011 16:49:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ow-000164-GH
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322498923!45753917!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23238 invoked from network); 28 Nov 2011 16:48:43 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-27.messagelabs.com with SMTP;
	28 Nov 2011 16:48:43 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015021; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQR030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:07 -0500
Message-Id: <1322498951-4392-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 08/12] xen/gntalloc: Change gref_lock to a mutex
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The event channel release function cannot be called under a spinlock
because it can attempt to acquire a mutex due to the event channel
reference acquired when setting up unmap notifications.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/gntalloc.c |   41 +++++++++++++++++++++--------------------
 1 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index e1c4c6e..2a7e9f8 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -74,7 +74,7 @@ MODULE_PARM_DESC(limit, "Maximum number of grants that may be allocated by "
 		"the gntalloc device");
 
 static LIST_HEAD(gref_list);
-static DEFINE_SPINLOCK(gref_lock);
+static DEFINE_MUTEX(gref_mutex);
 static int gref_size;
 
 struct notify_info {
@@ -143,15 +143,15 @@ static int add_grefs(struct ioctl_gntalloc_alloc_gref *op,
 	}
 
 	/* Add to gref lists. */
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	list_splice_tail(&queue_gref, &gref_list);
 	list_splice_tail(&queue_file, &priv->list);
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 
 	return 0;
 
 undo:
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	gref_size -= (op->count - i);
 
 	list_for_each_entry(gref, &queue_file, next_file) {
@@ -167,7 +167,7 @@ undo:
 	 */
 	if (unlikely(!list_empty(&queue_gref)))
 		list_splice_tail(&queue_gref, &gref_list);
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 	return rc;
 }
 
@@ -251,7 +251,7 @@ static int gntalloc_release(struct inode *inode, struct file *filp)
 
 	pr_debug("%s: priv %p\n", __func__, priv);
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	while (!list_empty(&priv->list)) {
 		gref = list_entry(priv->list.next,
 			struct gntalloc_gref, next_file);
@@ -261,7 +261,7 @@ static int gntalloc_release(struct inode *inode, struct file *filp)
 			__del_gref(gref);
 	}
 	kfree(priv);
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 
 	return 0;
 }
@@ -286,21 +286,21 @@ static long gntalloc_ioctl_alloc(struct gntalloc_file_private_data *priv,
 		goto out;
 	}
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	/* Clean up pages that were at zero (local) users but were still mapped
 	 * by remote domains. Since those pages count towards the limit that we
 	 * are about to enforce, removing them here is a good idea.
 	 */
 	do_cleanup();
 	if (gref_size + op.count > limit) {
-		spin_unlock(&gref_lock);
+		mutex_unlock(&gref_mutex);
 		rc = -ENOSPC;
 		goto out_free;
 	}
 	gref_size += op.count;
 	op.index = priv->index;
 	priv->index += op.count * PAGE_SIZE;
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 
 	rc = add_grefs(&op, gref_ids, priv);
 	if (rc < 0)
@@ -343,7 +343,7 @@ static long gntalloc_ioctl_dealloc(struct gntalloc_file_private_data *priv,
 		goto dealloc_grant_out;
 	}
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	gref = find_grefs(priv, op.index, op.count);
 	if (gref) {
 		/* Remove from the file list only, and decrease reference count.
@@ -363,7 +363,7 @@ static long gntalloc_ioctl_dealloc(struct gntalloc_file_private_data *priv,
 
 	do_cleanup();
 
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 dealloc_grant_out:
 	return rc;
 }
@@ -383,7 +383,7 @@ static long gntalloc_ioctl_unmap_notify(struct gntalloc_file_private_data *priv,
 	index = op.index & ~(PAGE_SIZE - 1);
 	pgoff = op.index & (PAGE_SIZE - 1);
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 
 	gref = find_grefs(priv, index, 1);
 	if (!gref) {
@@ -400,8 +400,9 @@ static long gntalloc_ioctl_unmap_notify(struct gntalloc_file_private_data *priv,
 	gref->notify.pgoff = pgoff;
 	gref->notify.event = op.event_channel_port;
 	rc = 0;
+
  unlock_out:
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 	return rc;
 }
 
@@ -433,9 +434,9 @@ static void gntalloc_vma_open(struct vm_area_struct *vma)
 	if (!gref)
 		return;
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	gref->users++;
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 }
 
 static void gntalloc_vma_close(struct vm_area_struct *vma)
@@ -444,11 +445,11 @@ static void gntalloc_vma_close(struct vm_area_struct *vma)
 	if (!gref)
 		return;
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	gref->users--;
 	if (gref->users == 0)
 		__del_gref(gref);
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 }
 
 static struct vm_operations_struct gntalloc_vmops = {
@@ -471,7 +472,7 @@ static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 		return -EINVAL;
 	}
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	gref = find_grefs(priv, vma->vm_pgoff << PAGE_SHIFT, count);
 	if (gref == NULL) {
 		rv = -ENOENT;
@@ -499,7 +500,7 @@ static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 	rv = 0;
 
 out_unlock:
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 	return rv;
 }
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4P1-0001Ad-Oa; Mon, 28 Nov 2011 16:49:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Oz-00016U-8u
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322498958!6695734!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28347 invoked from network); 28 Nov 2011 16:49:19 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-216.messagelabs.com with SMTP;
	28 Nov 2011 16:49:19 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnF13010794; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQK030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:00 -0500
Message-Id: <1322498951-4392-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 01/12] xenbus: Support HVM backends
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add HVM implementations of xenbus_(map,unmap)_ring_v(alloc,free) so
that ring mappings can be done without using GNTMAP_contains_pte which
is not supported on HVM.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |  155 +++++++++++++++++++++++++++++-------
 1 files changed, 125 insertions(+), 30 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 1906125..688c4b4 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -32,16 +32,27 @@
 
 #include <linux/slab.h>
 #include <linux/types.h>
+#include <linux/spinlock.h>
 #include <linux/vmalloc.h>
 #include <linux/export.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/page.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/event_channel.h>
+#include <xen/balloon.h>
 #include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct xenbus_map_node {
+	struct list_head next;
+	struct page *page;
+	grant_handle_t handle;
+};
+
+static DEFINE_SPINLOCK(xenbus_valloc_lock);
+static LIST_HEAD(xenbus_valloc_pages);
+
 const char *xenbus_strstate(enum xenbus_state state)
 {
 	static const char *const name[] = {
@@ -420,21 +431,8 @@ int xenbus_free_evtchn(struct xenbus_device *dev, int port)
 EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
 
 
-/**
- * xenbus_map_ring_valloc
- * @dev: xenbus device
- * @gnt_ref: grant reference
- * @vaddr: pointer to address to be filled out by mapping
- *
- * Based on Rusty Russell's skeleton driver's map_page.
- * Map a page of memory into this domain from another domain's grant table.
- * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
- * page to that address, and sets *vaddr to that address.
- * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
- * or -ENOMEM on error. If an error is returned, device will switch to
- * XenbusStateClosing and the error message will be saved in XenStore.
- */
-int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+static int xenbus_map_ring_valloc_pv(struct xenbus_device *dev,
+                                     int gnt_ref, void **vaddr)
 {
 	struct gnttab_map_grant_ref op = {
 		.flags = GNTMAP_host_map | GNTMAP_contains_pte,
@@ -469,6 +467,64 @@ int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
 	*vaddr = area->addr;
 	return 0;
 }
+
+static int xenbus_map_ring_valloc_hvm(struct xenbus_device *dev,
+                                     int gnt_ref, void **vaddr)
+{
+	struct xenbus_map_node *node;
+	int err;
+	void *addr;
+
+	*vaddr = NULL;
+
+	node = kzalloc(sizeof(*node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
+	err = alloc_xenballooned_pages(1, &node->page, false);
+	if (err)
+		goto out_err;
+
+	addr = pfn_to_kaddr(page_to_pfn(node->page));
+
+	err = xenbus_map_ring(dev, gnt_ref, &node->handle, addr);
+	if (err)
+		goto out_err;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_add(&node->next, &xenbus_valloc_pages);
+	spin_unlock(&xenbus_valloc_lock);
+
+	*vaddr = addr;
+	return 0;
+
+ out_err:
+	free_xenballooned_pages(1, &node->page);
+	kfree(node);
+	return err;
+}
+
+/**
+ * xenbus_map_ring_valloc
+ * @dev: xenbus device
+ * @gnt_ref: grant reference
+ * @vaddr: pointer to address to be filled out by mapping
+ *
+ * Based on Rusty Russell's skeleton driver's map_page.
+ * Map a page of memory into this domain from another domain's grant table.
+ * xenbus_map_ring_valloc allocates a page of virtual address space, maps the
+ * page to that address, and sets *vaddr to that address.
+ * Returns 0 on success, and GNTST_* (see xen/include/interface/grant_table.h)
+ * or -ENOMEM on error. If an error is returned, device will switch to
+ * XenbusStateClosing and the error message will be saved in XenStore.
+ */
+int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_map_ring_valloc_pv(dev, gnt_ref, vaddr);
+	else
+		return xenbus_map_ring_valloc_hvm(dev, gnt_ref, vaddr);
+}
 EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 
 
@@ -510,20 +566,7 @@ int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 }
 EXPORT_SYMBOL_GPL(xenbus_map_ring);
 
-
-/**
- * xenbus_unmap_ring_vfree
- * @dev: xenbus device
- * @vaddr: addr to unmap
- *
- * Based on Rusty Russell's skeleton driver's unmap_page.
- * Unmap a page of memory in this domain that was imported from another domain.
- * Use xenbus_unmap_ring_vfree if you mapped in your memory with
- * xenbus_map_ring_valloc (it will free the virtual address space).
- * Returns 0 on success and returns GNTST_* on error
- * (see xen/include/interface/grant_table.h).
- */
-int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+static int xenbus_unmap_ring_vfree_pv(struct xenbus_device *dev, void *vaddr)
 {
 	struct vm_struct *area;
 	struct gnttab_unmap_grant_ref op = {
@@ -566,8 +609,60 @@ int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
 
 	return op.status;
 }
-EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
+static int xenbus_unmap_ring_vfree_hvm(struct xenbus_device *dev, void *vaddr)
+{
+	int rv;
+	struct xenbus_map_node *node;
+	void *addr;
+
+	spin_lock(&xenbus_valloc_lock);
+	list_for_each_entry(node, &xenbus_valloc_pages, next) {
+		addr = pfn_to_kaddr(page_to_pfn(node->page));
+		if (addr == vaddr) {
+			list_del(&node->next);
+			goto found;
+		}
+	}
+	node = NULL;
+ found:
+	spin_unlock(&xenbus_valloc_lock);
+
+	if (!node) {
+		xenbus_dev_error(dev, -ENOENT,
+				 "can't find mapped virtual address %p", vaddr);
+		return -ENOENT;
+	}
+
+	rv = xenbus_unmap_ring(dev, node->handle, addr);
+
+	if (!rv)
+		free_xenballooned_pages(1, &node->page);
+
+	kfree(node);
+	return rv;
+}
+
+/**
+ * xenbus_unmap_ring_vfree
+ * @dev: xenbus device
+ * @vaddr: addr to unmap
+ *
+ * Based on Rusty Russell's skeleton driver's unmap_page.
+ * Unmap a page of memory in this domain that was imported from another domain.
+ * Use xenbus_unmap_ring_vfree if you mapped in your memory with
+ * xenbus_map_ring_valloc (it will free the virtual address space).
+ * Returns 0 on success and returns GNTST_* on error
+ * (see xen/include/interface/grant_table.h).
+ */
+int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
+{
+	if (xen_pv_domain())
+		return xenbus_unmap_ring_vfree_pv(dev, vaddr);
+	else
+		return xenbus_unmap_ring_vfree_hvm(dev, vaddr);
+}
+EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 
 /**
  * xenbus_unmap_ring
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Oz-00018v-CT; Mon, 28 Nov 2011 16:49:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ow-00016B-Vo
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322498957!5005609!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18696 invoked from network); 28 Nov 2011 16:49:18 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-182.messagelabs.com with SMTP;
	28 Nov 2011 16:49:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnF13010795; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQM030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:02 -0500
Message-Id: <1322498951-4392-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 03/12] xen/grant-table: Support mappings
	required by blkback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Allow mappings without GNTMAP_contains_pte and allow unmapping to
specify if the PTEs should be cleared.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   23 ++++-------------------
 include/xen/grant_table.h |    2 +-
 3 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index afca14d..65bff07 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -312,7 +312,8 @@ static int __unmap_grant_pages(struct grant_map *map, int offset, int pages)
 		}
 	}
 
-	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset, pages);
+	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset,
+	                        pages, true);
 	if (err)
 		return err;
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..a02d139 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -472,24 +472,9 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 				(map_ops[i].host_addr & ~PAGE_MASK));
 			mfn = pte_mfn(*pte);
 		} else {
-			/* If you really wanted to do this:
-			 * mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
-			 *
-			 * The reason we do not implement it is b/c on the
-			 * unmap path (gnttab_unmap_refs) we have no means of
-			 * checking whether the page is !GNTMAP_contains_pte.
-			 *
-			 * That is without some extra data-structure to carry
-			 * the struct page, bool clear_pte, and list_head next
-			 * tuples and deal with allocation/delallocation, etc.
-			 *
-			 * The users of this API set the GNTMAP_contains_pte
-			 * flag so lets just return not supported until it
-			 * becomes neccessary to implement.
-			 */
-			return -EOPNOTSUPP;
+			mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
 		}
-		ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]);
+		ret = m2p_add_override(mfn, pages[i], kmap_ops ? &kmap_ops[i] : NULL);
 		if (ret)
 			return ret;
 	}
@@ -499,7 +484,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		struct page **pages, unsigned int count)
+		struct page **pages, unsigned int count, bool clear_pte)
 {
 	int i, ret;
 
@@ -511,7 +496,7 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		return ret;
 
 	for (i = 0; i < count; i++) {
-		ret = m2p_remove_override(pages[i], true /* clear the PTE */);
+		ret = m2p_remove_override(pages[i], clear_pte);
 		if (ret)
 			return ret;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e2dfc..37da54d 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -158,6 +158,6 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 			struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count);
+		      struct page **pages, unsigned int count, bool clear_pte);
 
 #endif /* __ASM_GNTTAB_H__ */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Oy-00018J-PI; Mon, 28 Nov 2011 16:49:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ow-000164-GH
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322498923!45753917!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23238 invoked from network); 28 Nov 2011 16:48:43 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-27.messagelabs.com with SMTP;
	28 Nov 2011 16:48:43 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015021; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQR030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:07 -0500
Message-Id: <1322498951-4392-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 08/12] xen/gntalloc: Change gref_lock to a mutex
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The event channel release function cannot be called under a spinlock
because it can attempt to acquire a mutex due to the event channel
reference acquired when setting up unmap notifications.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/gntalloc.c |   41 +++++++++++++++++++++--------------------
 1 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index e1c4c6e..2a7e9f8 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -74,7 +74,7 @@ MODULE_PARM_DESC(limit, "Maximum number of grants that may be allocated by "
 		"the gntalloc device");
 
 static LIST_HEAD(gref_list);
-static DEFINE_SPINLOCK(gref_lock);
+static DEFINE_MUTEX(gref_mutex);
 static int gref_size;
 
 struct notify_info {
@@ -143,15 +143,15 @@ static int add_grefs(struct ioctl_gntalloc_alloc_gref *op,
 	}
 
 	/* Add to gref lists. */
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	list_splice_tail(&queue_gref, &gref_list);
 	list_splice_tail(&queue_file, &priv->list);
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 
 	return 0;
 
 undo:
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	gref_size -= (op->count - i);
 
 	list_for_each_entry(gref, &queue_file, next_file) {
@@ -167,7 +167,7 @@ undo:
 	 */
 	if (unlikely(!list_empty(&queue_gref)))
 		list_splice_tail(&queue_gref, &gref_list);
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 	return rc;
 }
 
@@ -251,7 +251,7 @@ static int gntalloc_release(struct inode *inode, struct file *filp)
 
 	pr_debug("%s: priv %p\n", __func__, priv);
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	while (!list_empty(&priv->list)) {
 		gref = list_entry(priv->list.next,
 			struct gntalloc_gref, next_file);
@@ -261,7 +261,7 @@ static int gntalloc_release(struct inode *inode, struct file *filp)
 			__del_gref(gref);
 	}
 	kfree(priv);
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 
 	return 0;
 }
@@ -286,21 +286,21 @@ static long gntalloc_ioctl_alloc(struct gntalloc_file_private_data *priv,
 		goto out;
 	}
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	/* Clean up pages that were at zero (local) users but were still mapped
 	 * by remote domains. Since those pages count towards the limit that we
 	 * are about to enforce, removing them here is a good idea.
 	 */
 	do_cleanup();
 	if (gref_size + op.count > limit) {
-		spin_unlock(&gref_lock);
+		mutex_unlock(&gref_mutex);
 		rc = -ENOSPC;
 		goto out_free;
 	}
 	gref_size += op.count;
 	op.index = priv->index;
 	priv->index += op.count * PAGE_SIZE;
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 
 	rc = add_grefs(&op, gref_ids, priv);
 	if (rc < 0)
@@ -343,7 +343,7 @@ static long gntalloc_ioctl_dealloc(struct gntalloc_file_private_data *priv,
 		goto dealloc_grant_out;
 	}
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	gref = find_grefs(priv, op.index, op.count);
 	if (gref) {
 		/* Remove from the file list only, and decrease reference count.
@@ -363,7 +363,7 @@ static long gntalloc_ioctl_dealloc(struct gntalloc_file_private_data *priv,
 
 	do_cleanup();
 
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 dealloc_grant_out:
 	return rc;
 }
@@ -383,7 +383,7 @@ static long gntalloc_ioctl_unmap_notify(struct gntalloc_file_private_data *priv,
 	index = op.index & ~(PAGE_SIZE - 1);
 	pgoff = op.index & (PAGE_SIZE - 1);
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 
 	gref = find_grefs(priv, index, 1);
 	if (!gref) {
@@ -400,8 +400,9 @@ static long gntalloc_ioctl_unmap_notify(struct gntalloc_file_private_data *priv,
 	gref->notify.pgoff = pgoff;
 	gref->notify.event = op.event_channel_port;
 	rc = 0;
+
  unlock_out:
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 	return rc;
 }
 
@@ -433,9 +434,9 @@ static void gntalloc_vma_open(struct vm_area_struct *vma)
 	if (!gref)
 		return;
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	gref->users++;
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 }
 
 static void gntalloc_vma_close(struct vm_area_struct *vma)
@@ -444,11 +445,11 @@ static void gntalloc_vma_close(struct vm_area_struct *vma)
 	if (!gref)
 		return;
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	gref->users--;
 	if (gref->users == 0)
 		__del_gref(gref);
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 }
 
 static struct vm_operations_struct gntalloc_vmops = {
@@ -471,7 +472,7 @@ static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 		return -EINVAL;
 	}
 
-	spin_lock(&gref_lock);
+	mutex_lock(&gref_mutex);
 	gref = find_grefs(priv, vma->vm_pgoff << PAGE_SHIFT, count);
 	if (gref == NULL) {
 		rv = -ENOENT;
@@ -499,7 +500,7 @@ static int gntalloc_mmap(struct file *filp, struct vm_area_struct *vma)
 	rv = 0;
 
 out_unlock:
-	spin_unlock(&gref_lock);
+	mutex_unlock(&gref_mutex);
 	return rv;
 }
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Oz-00018v-CT; Mon, 28 Nov 2011 16:49:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ow-00016B-Vo
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322498957!5005609!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18696 invoked from network); 28 Nov 2011 16:49:18 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-182.messagelabs.com with SMTP;
	28 Nov 2011 16:49:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnF13010795; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQM030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:02 -0500
Message-Id: <1322498951-4392-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 03/12] xen/grant-table: Support mappings
	required by blkback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Allow mappings without GNTMAP_contains_pte and allow unmapping to
specify if the PTEs should be cleared.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   23 ++++-------------------
 include/xen/grant_table.h |    2 +-
 3 files changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index afca14d..65bff07 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -312,7 +312,8 @@ static int __unmap_grant_pages(struct grant_map *map, int offset, int pages)
 		}
 	}
 
-	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset, pages);
+	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset,
+	                        pages, true);
 	if (err)
 		return err;
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bf1c094..a02d139 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -472,24 +472,9 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 				(map_ops[i].host_addr & ~PAGE_MASK));
 			mfn = pte_mfn(*pte);
 		} else {
-			/* If you really wanted to do this:
-			 * mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
-			 *
-			 * The reason we do not implement it is b/c on the
-			 * unmap path (gnttab_unmap_refs) we have no means of
-			 * checking whether the page is !GNTMAP_contains_pte.
-			 *
-			 * That is without some extra data-structure to carry
-			 * the struct page, bool clear_pte, and list_head next
-			 * tuples and deal with allocation/delallocation, etc.
-			 *
-			 * The users of this API set the GNTMAP_contains_pte
-			 * flag so lets just return not supported until it
-			 * becomes neccessary to implement.
-			 */
-			return -EOPNOTSUPP;
+			mfn = PFN_DOWN(map_ops[i].dev_bus_addr);
 		}
-		ret = m2p_add_override(mfn, pages[i], &kmap_ops[i]);
+		ret = m2p_add_override(mfn, pages[i], kmap_ops ? &kmap_ops[i] : NULL);
 		if (ret)
 			return ret;
 	}
@@ -499,7 +484,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		struct page **pages, unsigned int count)
+		struct page **pages, unsigned int count, bool clear_pte)
 {
 	int i, ret;
 
@@ -511,7 +496,7 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 		return ret;
 
 	for (i = 0; i < count; i++) {
-		ret = m2p_remove_override(pages[i], true /* clear the PTE */);
+		ret = m2p_remove_override(pages[i], clear_pte);
 		if (ret)
 			return ret;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e2dfc..37da54d 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -158,6 +158,6 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 			struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count);
+		      struct page **pages, unsigned int count, bool clear_pte);
 
 #endif /* __ASM_GNTTAB_H__ */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Oz-00019F-RD; Mon, 28 Nov 2011 16:49:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ox-00016A-0P
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322498958!442349!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7451 invoked from network); 28 Nov 2011 16:49:18 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-182.messagelabs.com with SMTP;
	28 Nov 2011 16:49:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015025; Mon, 28 Nov 2011 16:49:16 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQU030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:10 -0500
Message-Id: <1322498951-4392-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 11/12] xen/gntalloc: release grant references on
	page free
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

gnttab_end_foreign_access_ref does not return the grant reference it is
passed to the free list; gnttab_free_grant_reference needs to be
explicitly called. While gnttab_end_foreign_access provides a wrapper
for this, it is unsuitable because it does not return errors.

Reported-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntalloc.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 60eee4e..7b936cc 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -191,6 +191,8 @@ static void __del_gref(struct gntalloc_gref *gref)
 
 		if (!gnttab_end_foreign_access_ref(gref->gref_id, 0))
 			return;
+
+		gnttab_free_grant_reference(gref->gref_id);
 	}
 
 	gref_size--;
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4P1-0001A5-50; Mon, 28 Nov 2011 16:49:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ox-00016I-G8
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322498958!6138480!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28314 invoked from network); 28 Nov 2011 16:49:18 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-21.messagelabs.com with SMTP;
	28 Nov 2011 16:49:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015022; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQS030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:08 -0500
Message-Id: <1322498951-4392-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 09/12] xen/gnt{dev,
	alloc}: reserve event channels for notify
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When using the unmap notify ioctl, the event channel used for
notification needs to be reserved to avoid it being deallocated prior to
sending the notification.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/gntalloc.c |   21 ++++++++++++++++++++-
 drivers/xen/gntdev.c   |   31 ++++++++++++++++++++++++++++++-
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 2a7e9f8..60eee4e 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -178,8 +178,10 @@ static void __del_gref(struct gntalloc_gref *gref)
 		tmp[gref->notify.pgoff] = 0;
 		kunmap(gref->page);
 	}
-	if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT)
+	if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT) {
 		notify_remote_via_evtchn(gref->notify.event);
+		evtchn_put(gref->notify.event);
+	}
 
 	gref->notify.flags = 0;
 
@@ -396,6 +398,23 @@ static long gntalloc_ioctl_unmap_notify(struct gntalloc_file_private_data *priv,
 		goto unlock_out;
 	}
 
+	/* We need to grab a reference to the event channel we are going to use
+	 * to send the notify before releasing the reference we may already have
+	 * (if someone has called this ioctl twice). This is required so that
+	 * it is possible to change the clear_byte part of the notification
+	 * without disturbing the event channel part, which may now be the last
+	 * reference to that event channel.
+	 */
+	if (op.action & UNMAP_NOTIFY_SEND_EVENT) {
+		if (evtchn_get(op.event_channel_port)) {
+			rc = -EINVAL;
+			goto unlock_out;
+		}
+	}
+
+	if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT)
+		evtchn_put(gref->notify.event);
+
 	gref->notify.flags = op.action;
 	gref->notify.pgoff = pgoff;
 	gref->notify.event = op.event_channel_port;
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 65bff07..4e189f5 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -193,8 +193,10 @@ static void gntdev_put_map(struct grant_map *map)
 
 	atomic_sub(map->count, &pages_mapped);
 
-	if (map->notify.flags & UNMAP_NOTIFY_SEND_EVENT)
+	if (map->notify.flags & UNMAP_NOTIFY_SEND_EVENT) {
 		notify_remote_via_evtchn(map->notify.event);
+		evtchn_put(map->notify.event);
+	}
 
 	if (map->pages) {
 		if (!use_ptemod)
@@ -600,6 +602,8 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u)
 	struct ioctl_gntdev_unmap_notify op;
 	struct grant_map *map;
 	int rc;
+	int out_flags;
+	unsigned int out_event;
 
 	if (copy_from_user(&op, u, sizeof(op)))
 		return -EFAULT;
@@ -607,6 +611,21 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u)
 	if (op.action & ~(UNMAP_NOTIFY_CLEAR_BYTE|UNMAP_NOTIFY_SEND_EVENT))
 		return -EINVAL;
 
+	/* We need to grab a reference to the event channel we are going to use
+	 * to send the notify before releasing the reference we may already have
+	 * (if someone has called this ioctl twice). This is required so that
+	 * it is possible to change the clear_byte part of the notification
+	 * without disturbing the event channel part, which may now be the last
+	 * reference to that event channel.
+	 */
+	if (op.action & UNMAP_NOTIFY_SEND_EVENT) {
+		if (evtchn_get(op.event_channel_port))
+			return -EINVAL;
+	}
+
+	out_flags = op.action;
+	out_event = op.event_channel_port;
+
 	spin_lock(&priv->lock);
 
 	list_for_each_entry(map, &priv->maps, next) {
@@ -625,12 +644,22 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u)
 		goto unlock_out;
 	}
 
+	out_flags = map->notify.flags;
+	out_event = map->notify.event;
+
 	map->notify.flags = op.action;
 	map->notify.addr = op.index - (map->index << PAGE_SHIFT);
 	map->notify.event = op.event_channel_port;
+
 	rc = 0;
+
  unlock_out:
 	spin_unlock(&priv->lock);
+
+	/* Drop the reference to the event channel we did not save in the map */
+	if (out_flags & UNMAP_NOTIFY_SEND_EVENT)
+		evtchn_put(out_event);
+
 	return rc;
 }
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Oy-000189-BM; Mon, 28 Nov 2011 16:49:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ow-000161-CK
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322498957!3411328!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 659 invoked from network); 28 Nov 2011 16:49:17 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-174.messagelabs.com with SMTP;
	28 Nov 2011 16:49:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnF13010793; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQJ030566; 
	Mon, 28 Nov 2011 11:49:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:48:59 -0500
Message-Id: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <20111128152031.GB9655@andromeda.dapyr.net>
References: <20111128152031.GB9655@andromeda.dapyr.net>
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 00/12] HVM backends and gnt/event fixups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Reposting my current list of un-applied patches on top of v3.2-rc3

xen/{net,blk}back support for running in HVM:
[PATCH 01/12] xenbus: Support HVM backends
[PATCH 02/12] xenbus: Use grant-table wrapper functions
[PATCH 03/12] xen/grant-table: Support mappings required by blkback
[PATCH 04/12] xen/blkback: use grant-table.c hypercall wrappers
[PATCH 05/12] xen/netback: Enable netback on HVM guests
[PATCH 06/12] xen/blkback: Enable blkback on HVM guests

Event channel reference counts (these are on konrad/stable/for-linus-3.3
already, just reposted for reference):
[PATCH 07/12] xen/event: Add reference counting to event channels
[PATCH 08/12] xen/gntalloc: Change gref_lock to a mutex
[PATCH 09/12] xen/gnt{dev,alloc}: reserve event channels for notify

Fix on top of #7-9 (this could also be merged into #7):
[PATCH 10/12] xen/events: prevent calling evtchn_get on invalid channels

Fixes for gntalloc reference/page leaks:
[PATCH 11/12] xen/gntalloc: release grant references on page free
[PATCH 12/12] xen/gntalloc: fix reference counts on multi-page mappings

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4P0-00019s-N6; Mon, 28 Nov 2011 16:49:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ox-00016H-EP
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322498958!4129388!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3641 invoked from network); 28 Nov 2011 16:49:18 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-21.messagelabs.com with SMTP;
	28 Nov 2011 16:49:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015018; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQO030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:04 -0500
Message-Id: <1322498951-4392-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 05/12] xen/netback: Enable netback on HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 0cb594c..951c713 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1638,7 +1638,7 @@ static int __init netback_init(void)
 	int rc = 0;
 	int group;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return -ENODEV;
 
 	xen_netbk_group_nr = num_online_cpus();
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Ox-000181-UF; Mon, 28 Nov 2011 16:49:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ow-000162-8t
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322498957!3426073!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14530 invoked from network); 28 Nov 2011 16:49:17 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-174.messagelabs.com with SMTP;
	28 Nov 2011 16:49:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015017; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQL030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:01 -0500
Message-Id: <1322498951-4392-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 02/12] xenbus: Use grant-table wrapper functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The gnttab_set_{map,unmap}_op functions should be used instead of
directly populating the fields of gnttab_map_grant_ref.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |   17 +++++++----------
 1 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 688c4b4..a90f959 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -545,12 +545,10 @@ EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 		    grant_handle_t *handle, void *vaddr)
 {
-	struct gnttab_map_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-		.flags     = GNTMAP_host_map,
-		.ref       = gnt_ref,
-		.dom       = dev->otherend_id,
-	};
+	struct gnttab_map_grant_ref op;
+
+	gnttab_set_map_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, gnt_ref,
+	                  dev->otherend_id);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
 		BUG();
@@ -677,10 +675,9 @@ EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 int xenbus_unmap_ring(struct xenbus_device *dev,
 		      grant_handle_t handle, void *vaddr)
 {
-	struct gnttab_unmap_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-		.handle    = handle,
-	};
+	struct gnttab_unmap_grant_ref op;
+
+	gnttab_set_unmap_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, handle);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
 		BUG();
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4P0-00019R-9b; Mon, 28 Nov 2011 16:49:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ox-00016F-BL
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322498958!5003691!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11959 invoked from network); 28 Nov 2011 16:49:18 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-14.tower-182.messagelabs.com with SMTP;
	28 Nov 2011 16:49:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015020; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQQ030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:06 -0500
Message-Id: <1322498951-4392-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 07/12] xen/event: Add reference counting to
	event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Event channels exposed to userspace by the evtchn module may be used by
other modules in an asynchronous manner, which requires that reference
counting be used to prevent the event channel from being closed before
the signals are delivered.

The reference count on new event channels defaults to -1 which indicates
the event channel is not referenced outside the kernel; evtchn_get fails
if called on such an event channel. The event channels made visible to
userspace by evtchn have a normal reference count.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/events.c |   74 +++++++++++++++++++++++++++++++++++++++++++++++++-
 drivers/xen/evtchn.c |    2 +-
 include/xen/events.h |    7 +++++
 3 files changed, 81 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6e075cd..a3bcd61 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -87,6 +87,7 @@ enum xen_irq_type {
  */
 struct irq_info {
 	struct list_head list;
+	int refcnt;
 	enum xen_irq_type type;	/* type */
 	unsigned irq;
 	unsigned short evtchn;	/* event channel */
@@ -406,6 +407,7 @@ static void xen_irq_init(unsigned irq)
 		panic("Unable to allocate metadata for IRQ%d\n", irq);
 
 	info->type = IRQT_UNBOUND;
+	info->refcnt = -1;
 
 	irq_set_handler_data(irq, info);
 
@@ -469,6 +471,8 @@ static void xen_free_irq(unsigned irq)
 
 	irq_set_handler_data(irq, NULL);
 
+	WARN_ON(info->refcnt > 0);
+
 	kfree(info);
 
 	/* Legacy IRQ descriptors are managed by the arch. */
@@ -637,7 +641,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi,
 	if (irq != -1) {
 		printk(KERN_INFO "xen_map_pirq_gsi: returning irq %d for gsi %u\n",
 		       irq, gsi);
-		goto out;	/* XXX need refcount? */
+		goto out;
 	}
 
 	irq = xen_allocate_irq_gsi(gsi);
@@ -939,9 +943,16 @@ static void unbind_from_irq(unsigned int irq)
 {
 	struct evtchn_close close;
 	int evtchn = evtchn_from_irq(irq);
+	struct irq_info *info = irq_get_handler_data(irq);
 
 	mutex_lock(&irq_mapping_update_lock);
 
+	if (info->refcnt > 0) {
+		info->refcnt--;
+		if (info->refcnt != 0)
+			goto done;
+	}
+
 	if (VALID_EVTCHN(evtchn)) {
 		close.port = evtchn;
 		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
@@ -970,6 +981,7 @@ static void unbind_from_irq(unsigned int irq)
 
 	xen_free_irq(irq);
 
+ done:
 	mutex_unlock(&irq_mapping_update_lock);
 }
 
@@ -1065,6 +1077,66 @@ void unbind_from_irqhandler(unsigned int irq, void *dev_id)
 }
 EXPORT_SYMBOL_GPL(unbind_from_irqhandler);
 
+int evtchn_make_refcounted(unsigned int evtchn)
+{
+	int irq = evtchn_to_irq[evtchn];
+	struct irq_info *info;
+
+	if (irq == -1)
+		return -ENOENT;
+
+	info = irq_get_handler_data(irq);
+
+	if (!info)
+		return -ENOENT;
+
+	WARN_ON(info->refcnt != -1);
+
+	info->refcnt = 1;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(evtchn_make_refcounted);
+
+int evtchn_get(unsigned int evtchn)
+{
+	int irq;
+	struct irq_info *info;
+	int err = -ENOENT;
+
+	mutex_lock(&irq_mapping_update_lock);
+
+	irq = evtchn_to_irq[evtchn];
+	if (irq == -1)
+		goto done;
+
+	info = irq_get_handler_data(irq);
+
+	if (!info)
+		goto done;
+
+	err = -EINVAL;
+	if (info->refcnt <= 0)
+		goto done;
+
+	info->refcnt++;
+	err = 0;
+ done:
+	mutex_unlock(&irq_mapping_update_lock);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(evtchn_get);
+
+void evtchn_put(unsigned int evtchn)
+{
+	int irq = evtchn_to_irq[evtchn];
+	if (WARN_ON(irq == -1))
+		return;
+	unbind_from_irq(irq);
+}
+EXPORT_SYMBOL_GPL(evtchn_put);
+
 void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)
 {
 	int irq = per_cpu(ipi_to_irq, cpu)[vector];
diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index dbc13e9..b1f60a0 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -268,7 +268,7 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
 	rc = bind_evtchn_to_irqhandler(port, evtchn_interrupt, IRQF_DISABLED,
 				       u->name, (void *)(unsigned long)port);
 	if (rc >= 0)
-		rc = 0;
+		rc = evtchn_make_refcounted(port);
 
 	return rc;
 }
diff --git a/include/xen/events.h b/include/xen/events.h
index d287997..0f77370 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -37,6 +37,13 @@ int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain,
  */
 void unbind_from_irqhandler(unsigned int irq, void *dev_id);
 
+/*
+ * Allow extra references to event channels exposed to userspace by evtchn
+ */
+int evtchn_make_refcounted(unsigned int evtchn);
+int evtchn_get(unsigned int evtchn);
+void evtchn_put(unsigned int evtchn);
+
 void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector);
 int resend_irq_on_evtchn(unsigned int irq);
 void rebind_evtchn_irq(int evtchn, int irq);
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4P2-0001B8-5a; Mon, 28 Nov 2011 16:50:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Oz-00016W-DQ
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322498958!5344435!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11179 invoked from network); 28 Nov 2011 16:49:19 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-216.messagelabs.com with SMTP;
	28 Nov 2011 16:49:19 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015024; Mon, 28 Nov 2011 16:49:16 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQT030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:09 -0500
Message-Id: <1322498951-4392-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 10/12] xen/events: prevent calling evtchn_get on
	invalid channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The event channel number provided to evtchn_get can be provided by
userspace, so needs to be checked against the maximum number of event
channels prior to using it to index into evtchn_to_irq.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/events.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index a3bcd61..e5e5812 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1104,6 +1104,9 @@ int evtchn_get(unsigned int evtchn)
 	struct irq_info *info;
 	int err = -ENOENT;
 
+	if (evtchn >= NR_EVENT_CHANNELS)
+		return -EINVAL;
+
 	mutex_lock(&irq_mapping_update_lock);
 
 	irq = evtchn_to_irq[evtchn];
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4P1-0001A5-50; Mon, 28 Nov 2011 16:49:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ox-00016I-G8
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-21.messagelabs.com!1322498958!6138480!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28314 invoked from network); 28 Nov 2011 16:49:18 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-21.messagelabs.com with SMTP;
	28 Nov 2011 16:49:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015022; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQS030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:08 -0500
Message-Id: <1322498951-4392-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 09/12] xen/gnt{dev,
	alloc}: reserve event channels for notify
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When using the unmap notify ioctl, the event channel used for
notification needs to be reserved to avoid it being deallocated prior to
sending the notification.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/gntalloc.c |   21 ++++++++++++++++++++-
 drivers/xen/gntdev.c   |   31 ++++++++++++++++++++++++++++++-
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 2a7e9f8..60eee4e 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -178,8 +178,10 @@ static void __del_gref(struct gntalloc_gref *gref)
 		tmp[gref->notify.pgoff] = 0;
 		kunmap(gref->page);
 	}
-	if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT)
+	if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT) {
 		notify_remote_via_evtchn(gref->notify.event);
+		evtchn_put(gref->notify.event);
+	}
 
 	gref->notify.flags = 0;
 
@@ -396,6 +398,23 @@ static long gntalloc_ioctl_unmap_notify(struct gntalloc_file_private_data *priv,
 		goto unlock_out;
 	}
 
+	/* We need to grab a reference to the event channel we are going to use
+	 * to send the notify before releasing the reference we may already have
+	 * (if someone has called this ioctl twice). This is required so that
+	 * it is possible to change the clear_byte part of the notification
+	 * without disturbing the event channel part, which may now be the last
+	 * reference to that event channel.
+	 */
+	if (op.action & UNMAP_NOTIFY_SEND_EVENT) {
+		if (evtchn_get(op.event_channel_port)) {
+			rc = -EINVAL;
+			goto unlock_out;
+		}
+	}
+
+	if (gref->notify.flags & UNMAP_NOTIFY_SEND_EVENT)
+		evtchn_put(gref->notify.event);
+
 	gref->notify.flags = op.action;
 	gref->notify.pgoff = pgoff;
 	gref->notify.event = op.event_channel_port;
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 65bff07..4e189f5 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -193,8 +193,10 @@ static void gntdev_put_map(struct grant_map *map)
 
 	atomic_sub(map->count, &pages_mapped);
 
-	if (map->notify.flags & UNMAP_NOTIFY_SEND_EVENT)
+	if (map->notify.flags & UNMAP_NOTIFY_SEND_EVENT) {
 		notify_remote_via_evtchn(map->notify.event);
+		evtchn_put(map->notify.event);
+	}
 
 	if (map->pages) {
 		if (!use_ptemod)
@@ -600,6 +602,8 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u)
 	struct ioctl_gntdev_unmap_notify op;
 	struct grant_map *map;
 	int rc;
+	int out_flags;
+	unsigned int out_event;
 
 	if (copy_from_user(&op, u, sizeof(op)))
 		return -EFAULT;
@@ -607,6 +611,21 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u)
 	if (op.action & ~(UNMAP_NOTIFY_CLEAR_BYTE|UNMAP_NOTIFY_SEND_EVENT))
 		return -EINVAL;
 
+	/* We need to grab a reference to the event channel we are going to use
+	 * to send the notify before releasing the reference we may already have
+	 * (if someone has called this ioctl twice). This is required so that
+	 * it is possible to change the clear_byte part of the notification
+	 * without disturbing the event channel part, which may now be the last
+	 * reference to that event channel.
+	 */
+	if (op.action & UNMAP_NOTIFY_SEND_EVENT) {
+		if (evtchn_get(op.event_channel_port))
+			return -EINVAL;
+	}
+
+	out_flags = op.action;
+	out_event = op.event_channel_port;
+
 	spin_lock(&priv->lock);
 
 	list_for_each_entry(map, &priv->maps, next) {
@@ -625,12 +644,22 @@ static long gntdev_ioctl_notify(struct gntdev_priv *priv, void __user *u)
 		goto unlock_out;
 	}
 
+	out_flags = map->notify.flags;
+	out_event = map->notify.event;
+
 	map->notify.flags = op.action;
 	map->notify.addr = op.index - (map->index << PAGE_SHIFT);
 	map->notify.event = op.event_channel_port;
+
 	rc = 0;
+
  unlock_out:
 	spin_unlock(&priv->lock);
+
+	/* Drop the reference to the event channel we did not save in the map */
+	if (out_flags & UNMAP_NOTIFY_SEND_EVENT)
+		evtchn_put(out_event);
+
 	return rc;
 }
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4P0-00019R-9b; Mon, 28 Nov 2011 16:49:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ox-00016F-BL
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322498958!5003691!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11959 invoked from network); 28 Nov 2011 16:49:18 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-14.tower-182.messagelabs.com with SMTP;
	28 Nov 2011 16:49:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015020; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQQ030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:06 -0500
Message-Id: <1322498951-4392-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 07/12] xen/event: Add reference counting to
	event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Event channels exposed to userspace by the evtchn module may be used by
other modules in an asynchronous manner, which requires that reference
counting be used to prevent the event channel from being closed before
the signals are delivered.

The reference count on new event channels defaults to -1 which indicates
the event channel is not referenced outside the kernel; evtchn_get fails
if called on such an event channel. The event channels made visible to
userspace by evtchn have a normal reference count.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/events.c |   74 +++++++++++++++++++++++++++++++++++++++++++++++++-
 drivers/xen/evtchn.c |    2 +-
 include/xen/events.h |    7 +++++
 3 files changed, 81 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6e075cd..a3bcd61 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -87,6 +87,7 @@ enum xen_irq_type {
  */
 struct irq_info {
 	struct list_head list;
+	int refcnt;
 	enum xen_irq_type type;	/* type */
 	unsigned irq;
 	unsigned short evtchn;	/* event channel */
@@ -406,6 +407,7 @@ static void xen_irq_init(unsigned irq)
 		panic("Unable to allocate metadata for IRQ%d\n", irq);
 
 	info->type = IRQT_UNBOUND;
+	info->refcnt = -1;
 
 	irq_set_handler_data(irq, info);
 
@@ -469,6 +471,8 @@ static void xen_free_irq(unsigned irq)
 
 	irq_set_handler_data(irq, NULL);
 
+	WARN_ON(info->refcnt > 0);
+
 	kfree(info);
 
 	/* Legacy IRQ descriptors are managed by the arch. */
@@ -637,7 +641,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi,
 	if (irq != -1) {
 		printk(KERN_INFO "xen_map_pirq_gsi: returning irq %d for gsi %u\n",
 		       irq, gsi);
-		goto out;	/* XXX need refcount? */
+		goto out;
 	}
 
 	irq = xen_allocate_irq_gsi(gsi);
@@ -939,9 +943,16 @@ static void unbind_from_irq(unsigned int irq)
 {
 	struct evtchn_close close;
 	int evtchn = evtchn_from_irq(irq);
+	struct irq_info *info = irq_get_handler_data(irq);
 
 	mutex_lock(&irq_mapping_update_lock);
 
+	if (info->refcnt > 0) {
+		info->refcnt--;
+		if (info->refcnt != 0)
+			goto done;
+	}
+
 	if (VALID_EVTCHN(evtchn)) {
 		close.port = evtchn;
 		if (HYPERVISOR_event_channel_op(EVTCHNOP_close, &close) != 0)
@@ -970,6 +981,7 @@ static void unbind_from_irq(unsigned int irq)
 
 	xen_free_irq(irq);
 
+ done:
 	mutex_unlock(&irq_mapping_update_lock);
 }
 
@@ -1065,6 +1077,66 @@ void unbind_from_irqhandler(unsigned int irq, void *dev_id)
 }
 EXPORT_SYMBOL_GPL(unbind_from_irqhandler);
 
+int evtchn_make_refcounted(unsigned int evtchn)
+{
+	int irq = evtchn_to_irq[evtchn];
+	struct irq_info *info;
+
+	if (irq == -1)
+		return -ENOENT;
+
+	info = irq_get_handler_data(irq);
+
+	if (!info)
+		return -ENOENT;
+
+	WARN_ON(info->refcnt != -1);
+
+	info->refcnt = 1;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(evtchn_make_refcounted);
+
+int evtchn_get(unsigned int evtchn)
+{
+	int irq;
+	struct irq_info *info;
+	int err = -ENOENT;
+
+	mutex_lock(&irq_mapping_update_lock);
+
+	irq = evtchn_to_irq[evtchn];
+	if (irq == -1)
+		goto done;
+
+	info = irq_get_handler_data(irq);
+
+	if (!info)
+		goto done;
+
+	err = -EINVAL;
+	if (info->refcnt <= 0)
+		goto done;
+
+	info->refcnt++;
+	err = 0;
+ done:
+	mutex_unlock(&irq_mapping_update_lock);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(evtchn_get);
+
+void evtchn_put(unsigned int evtchn)
+{
+	int irq = evtchn_to_irq[evtchn];
+	if (WARN_ON(irq == -1))
+		return;
+	unbind_from_irq(irq);
+}
+EXPORT_SYMBOL_GPL(evtchn_put);
+
 void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)
 {
 	int irq = per_cpu(ipi_to_irq, cpu)[vector];
diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
index dbc13e9..b1f60a0 100644
--- a/drivers/xen/evtchn.c
+++ b/drivers/xen/evtchn.c
@@ -268,7 +268,7 @@ static int evtchn_bind_to_user(struct per_user_data *u, int port)
 	rc = bind_evtchn_to_irqhandler(port, evtchn_interrupt, IRQF_DISABLED,
 				       u->name, (void *)(unsigned long)port);
 	if (rc >= 0)
-		rc = 0;
+		rc = evtchn_make_refcounted(port);
 
 	return rc;
 }
diff --git a/include/xen/events.h b/include/xen/events.h
index d287997..0f77370 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -37,6 +37,13 @@ int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain,
  */
 void unbind_from_irqhandler(unsigned int irq, void *dev_id);
 
+/*
+ * Allow extra references to event channels exposed to userspace by evtchn
+ */
+int evtchn_make_refcounted(unsigned int evtchn);
+int evtchn_get(unsigned int evtchn);
+void evtchn_put(unsigned int evtchn);
+
 void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector);
 int resend_irq_on_evtchn(unsigned int irq);
 void rebind_evtchn_irq(int evtchn, int irq);
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Ox-000181-UF; Mon, 28 Nov 2011 16:49:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ow-000162-8t
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-174.messagelabs.com!1322498957!3426073!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14530 invoked from network); 28 Nov 2011 16:49:17 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-174.messagelabs.com with SMTP;
	28 Nov 2011 16:49:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015017; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQL030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:01 -0500
Message-Id: <1322498951-4392-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 02/12] xenbus: Use grant-table wrapper functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The gnttab_set_{map,unmap}_op functions should be used instead of
directly populating the fields of gnttab_map_grant_ref.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_client.c |   17 +++++++----------
 1 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index 688c4b4..a90f959 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -545,12 +545,10 @@ EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
 int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
 		    grant_handle_t *handle, void *vaddr)
 {
-	struct gnttab_map_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-		.flags     = GNTMAP_host_map,
-		.ref       = gnt_ref,
-		.dom       = dev->otherend_id,
-	};
+	struct gnttab_map_grant_ref op;
+
+	gnttab_set_map_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, gnt_ref,
+	                  dev->otherend_id);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1))
 		BUG();
@@ -677,10 +675,9 @@ EXPORT_SYMBOL_GPL(xenbus_unmap_ring_vfree);
 int xenbus_unmap_ring(struct xenbus_device *dev,
 		      grant_handle_t handle, void *vaddr)
 {
-	struct gnttab_unmap_grant_ref op = {
-		.host_addr = (unsigned long)vaddr,
-		.handle    = handle,
-	};
+	struct gnttab_unmap_grant_ref op;
+
+	gnttab_set_unmap_op(&op, (phys_addr_t)vaddr, GNTMAP_host_map, handle);
 
 	if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1))
 		BUG();
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Oz-00019F-RD; Mon, 28 Nov 2011 16:49:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ox-00016A-0P
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322498958!442349!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7451 invoked from network); 28 Nov 2011 16:49:18 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-182.messagelabs.com with SMTP;
	28 Nov 2011 16:49:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015025; Mon, 28 Nov 2011 16:49:16 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQU030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:10 -0500
Message-Id: <1322498951-4392-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 11/12] xen/gntalloc: release grant references on
	page free
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

gnttab_end_foreign_access_ref does not return the grant reference it is
passed to the free list; gnttab_free_grant_reference needs to be
explicitly called. While gnttab_end_foreign_access provides a wrapper
for this, it is unsuitable because it does not return errors.

Reported-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/gntalloc.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c
index 60eee4e..7b936cc 100644
--- a/drivers/xen/gntalloc.c
+++ b/drivers/xen/gntalloc.c
@@ -191,6 +191,8 @@ static void __del_gref(struct gntalloc_gref *gref)
 
 		if (!gnttab_end_foreign_access_ref(gref->gref_id, 0))
 			return;
+
+		gnttab_free_grant_reference(gref->gref_id);
 	}
 
 	gref_size--;
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4P0-00019s-N6; Mon, 28 Nov 2011 16:49:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ox-00016H-EP
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322498958!4129388!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3641 invoked from network); 28 Nov 2011 16:49:18 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-21.messagelabs.com with SMTP;
	28 Nov 2011 16:49:18 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015018; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQO030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:04 -0500
Message-Id: <1322498951-4392-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 05/12] xen/netback: Enable netback on HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/net/xen-netback/netback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 0cb594c..951c713 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1638,7 +1638,7 @@ static int __init netback_init(void)
 	int rc = 0;
 	int group;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return -ENODEV;
 
 	xen_netbk_group_nr = num_online_cpus();
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4P2-0001B8-5a; Mon, 28 Nov 2011 16:50:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Oz-00016W-DQ
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322498958!5344435!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11179 invoked from network); 28 Nov 2011 16:49:19 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-216.messagelabs.com with SMTP;
	28 Nov 2011 16:49:19 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015024; Mon, 28 Nov 2011 16:49:16 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQT030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:09 -0500
Message-Id: <1322498951-4392-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 10/12] xen/events: prevent calling evtchn_get on
	invalid channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The event channel number provided to evtchn_get can be provided by
userspace, so needs to be checked against the maximum number of event
channels prior to using it to index into evtchn_to_irq.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/events.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index a3bcd61..e5e5812 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1104,6 +1104,9 @@ int evtchn_get(unsigned int evtchn)
 	struct irq_info *info;
 	int err = -ENOENT;
 
+	if (evtchn >= NR_EVENT_CHANNELS)
+		return -EINVAL;
+
 	mutex_lock(&irq_mapping_update_lock);
 
 	irq = evtchn_to_irq[evtchn];
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Oy-000189-BM; Mon, 28 Nov 2011 16:49:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4Ow-000161-CK
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:49:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322498957!3411328!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 659 invoked from network); 28 Nov 2011 16:49:17 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-174.messagelabs.com with SMTP;
	28 Nov 2011 16:49:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnF13010793; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQJ030566; 
	Mon, 28 Nov 2011 11:49:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:48:59 -0500
Message-Id: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <20111128152031.GB9655@andromeda.dapyr.net>
References: <20111128152031.GB9655@andromeda.dapyr.net>
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 00/12] HVM backends and gnt/event fixups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Reposting my current list of un-applied patches on top of v3.2-rc3

xen/{net,blk}back support for running in HVM:
[PATCH 01/12] xenbus: Support HVM backends
[PATCH 02/12] xenbus: Use grant-table wrapper functions
[PATCH 03/12] xen/grant-table: Support mappings required by blkback
[PATCH 04/12] xen/blkback: use grant-table.c hypercall wrappers
[PATCH 05/12] xen/netback: Enable netback on HVM guests
[PATCH 06/12] xen/blkback: Enable blkback on HVM guests

Event channel reference counts (these are on konrad/stable/for-linus-3.3
already, just reposted for reference):
[PATCH 07/12] xen/event: Add reference counting to event channels
[PATCH 08/12] xen/gntalloc: Change gref_lock to a mutex
[PATCH 09/12] xen/gnt{dev,alloc}: reserve event channels for notify

Fix on top of #7-9 (this could also be merged into #7):
[PATCH 10/12] xen/events: prevent calling evtchn_get on invalid channels

Fixes for gntalloc reference/page leaks:
[PATCH 11/12] xen/gntalloc: release grant references on page free
[PATCH 12/12] xen/gntalloc: fix reference counts on multi-page mappings

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4PC-0001MV-Sm; Mon, 28 Nov 2011 16:50:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4P9-0001Cd-PI
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:50:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322498958!5289242!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8147 invoked from network); 28 Nov 2011 16:49:19 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-16.tower-216.messagelabs.com with SMTP;
	28 Nov 2011 16:49:19 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015019; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQP030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:05 -0500
Message-Id: <1322498951-4392-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 06/12] xen/blkback: Enable blkback on HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/block/xen-blkback/blkback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 1e256dc..fbffdf0 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -823,7 +823,7 @@ static int __init xen_blkif_init(void)
 	int i, mmap_pages;
 	int rc = 0;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return -ENODEV;
 
 	blkbk = kzalloc(sizeof(struct xen_blkbk), GFP_KERNEL);
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:50:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4PC-0001MV-Sm; Mon, 28 Nov 2011 16:50:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV4P9-0001Cd-PI
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:50:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322498958!5289242!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8147 invoked from network); 28 Nov 2011 16:49:19 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-16.tower-216.messagelabs.com with SMTP;
	28 Nov 2011 16:49:19 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASGnFpt015019; Mon, 28 Nov 2011 16:49:15 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASGnCQP030566; 
	Mon, 28 Nov 2011 11:49:15 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: konrad.wilk@oracle.com
Date: Mon, 28 Nov 2011 11:49:05 -0500
Message-Id: <1322498951-4392-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <20111128152031.GB9655@andromeda.dapyr.net>
	<1322498951-4392-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com,
	david.vrabel@citrix.com, JBeulich@suse.com, Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 06/12] xen/blkback: Enable blkback on HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/block/xen-blkback/blkback.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 1e256dc..fbffdf0 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -823,7 +823,7 @@ static int __init xen_blkif_init(void)
 	int i, mmap_pages;
 	int rc = 0;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return -ENODEV;
 
 	blkbk = kzalloc(sizeof(struct xen_blkbk), GFP_KERNEL);
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:58:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:58:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Wo-0003Sp-3b; Mon, 28 Nov 2011 16:58:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RV4Wn-0003Sg-9S
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:58:01 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322499444!5369996!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU2MzA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31595 invoked from network); 28 Nov 2011 16:57:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-216.messagelabs.com with SMTP;
	28 Nov 2011 16:57:24 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pASGuYTD019462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 28 Nov 2011 11:56:34 -0500
Received: from [10.34.1.169] (dhcp-1-169.brq.redhat.com [10.34.1.169])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pASGuX8a019899; Mon, 28 Nov 2011 11:56:33 -0500
Message-ID: <4ED3BD99.8050902@redhat.com>
Date: Mon, 28 Nov 2011 17:58:01 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14
	Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>	
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>	
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322494816.20646.14.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"konrad.wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/28/11 16:40, Ian Campbell wrote:
> On Mon, 2011-11-28 at 15:28 +0000, Konrad Rzeszutek Wilk wrote:
>> On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:
>
>>> I looked through my old mails from you and you explained already the necessity of double
>>> bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
>>> Xenified kernel not have this kind of issue?
>>
>> That is a puzzle. It should not. The code is very much the same - both
>> use the generic SWIOTLB which has not changed for years.
>
> The swiotlb-xen used by classic-xen kernels (which I assume is what
> Carsten means by "Xenified") isn't exactly the same as the stuff in
> mainline Linux, it's been heavily refactored for one thing. It's not
> impossible that mainline is bouncing something it doesn't really need
> to.

Please excuse me if I'm completely mistaken; my only point of reference 
is that we recently had to backport 
<http://xenbits.xensource.com/hg/linux-2.6.18-xen.hg/rev/940>.

> It's also possible that the dma mask of the device is different/wrong in
> mainline leading to such additional bouncing.

dma_alloc_coherent() -- which I guess is the precursor of 
pci_alloc_consistent() -- asks xen_create_contiguous_region() to back 
the vaddr range with frames machine-addressible inside the device's dma 
mask. xen_create_contiguous_region() seems to land in a XENMEM_exchange 
hypercall (among others). Perhaps this extra layer of indirection allows 
the driver to use low pages directly, without bounce buffers.

> I guess it's also possible that the classic-Xen kernels are playing fast
> and loose by not bouncing something they should (although if so they
> appear to be getting away with it...) or that there is some difference
> which really means mainline needs to bounce while classic-Xen doesn't.

I'm sorry if what I just posted is painfully stupid. I'm taking the risk 
for the 1% chance that it could be helpful.

Wrt. the idle time accounting problem, after Niall's two pings, I'm also 
waiting for a verdict, and/or for myself finding the time and fishing 
out the current patches.

Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 16:58:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 16:58:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Wo-0003Sp-3b; Mon, 28 Nov 2011 16:58:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RV4Wn-0003Sg-9S
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 16:58:01 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322499444!5369996!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU2MzA=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31595 invoked from network); 28 Nov 2011 16:57:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-216.messagelabs.com with SMTP;
	28 Nov 2011 16:57:24 -0000
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pASGuYTD019462
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 28 Nov 2011 11:56:34 -0500
Received: from [10.34.1.169] (dhcp-1-169.brq.redhat.com [10.34.1.169])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pASGuX8a019899; Mon, 28 Nov 2011 11:56:33 -0500
Message-ID: <4ED3BD99.8050902@redhat.com>
Date: Mon, 28 Nov 2011 17:58:01 +0100
From: Laszlo Ersek <lersek@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14
	Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>	
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>	
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322494816.20646.14.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"konrad.wilk" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/28/11 16:40, Ian Campbell wrote:
> On Mon, 2011-11-28 at 15:28 +0000, Konrad Rzeszutek Wilk wrote:
>> On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:
>
>>> I looked through my old mails from you and you explained already the necessity of double
>>> bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
>>> Xenified kernel not have this kind of issue?
>>
>> That is a puzzle. It should not. The code is very much the same - both
>> use the generic SWIOTLB which has not changed for years.
>
> The swiotlb-xen used by classic-xen kernels (which I assume is what
> Carsten means by "Xenified") isn't exactly the same as the stuff in
> mainline Linux, it's been heavily refactored for one thing. It's not
> impossible that mainline is bouncing something it doesn't really need
> to.

Please excuse me if I'm completely mistaken; my only point of reference 
is that we recently had to backport 
<http://xenbits.xensource.com/hg/linux-2.6.18-xen.hg/rev/940>.

> It's also possible that the dma mask of the device is different/wrong in
> mainline leading to such additional bouncing.

dma_alloc_coherent() -- which I guess is the precursor of 
pci_alloc_consistent() -- asks xen_create_contiguous_region() to back 
the vaddr range with frames machine-addressible inside the device's dma 
mask. xen_create_contiguous_region() seems to land in a XENMEM_exchange 
hypercall (among others). Perhaps this extra layer of indirection allows 
the driver to use low pages directly, without bounce buffers.

> I guess it's also possible that the classic-Xen kernels are playing fast
> and loose by not bouncing something they should (although if so they
> appear to be getting away with it...) or that there is some difference
> which really means mainline needs to bounce while classic-Xen doesn't.

I'm sorry if what I just posted is painfully stupid. I'm taking the risk 
for the 1% chance that it could be helpful.

Wrt. the idle time accounting problem, after Niall's two pings, I'm also 
waiting for a verdict, and/or for myself finding the time and fishing 
out the current patches.

Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Z4-0003du-Ng; Mon, 28 Nov 2011 17:00:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4Z3-0003dW-6e
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322499585!4557211!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12943 invoked from network); 28 Nov 2011 16:59:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YS-00055V-BK; Mon, 28 Nov 2011 16:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YS-0000c9-99;
	Mon, 28 Nov 2011 16:59:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:27 +0000
Message-ID: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH RFC v3 00/13] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a revised RFC version of my event handling API proposal.

It consists of 10 rather uninteresting preparatory, stylistic
and bugfix patches, plus 3 with some meat in:
  02/13  libxenstore: Provide xs_check_watch
  12/13  libxl: New API for providing OS events to libxl
  13/13  libxl: New event generation API

This series now builds and links but I have still not tested it.
I have rebased it to current xen-unstable non-staging, and addressed
the comments.

Of these I think the following may be useful to apply right away:
  03/13  libxl: Provide a version of bsd's queue.h as _libxl_list.h

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4Z4-0003du-Ng; Mon, 28 Nov 2011 17:00:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4Z3-0003dW-6e
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322499585!4557211!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12943 invoked from network); 28 Nov 2011 16:59:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YS-00055V-BK; Mon, 28 Nov 2011 16:59:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YS-0000c9-99;
	Mon, 28 Nov 2011 16:59:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:27 +0000
Message-ID: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH RFC v3 00/13] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a revised RFC version of my event handling API proposal.

It consists of 10 rather uninteresting preparatory, stylistic
and bugfix patches, plus 3 with some meat in:
  02/13  libxenstore: Provide xs_check_watch
  12/13  libxl: New API for providing OS events to libxl
  13/13  libxl: New event generation API

This series now builds and links but I have still not tested it.
I have rebased it to current xen-unstable non-staging, and addressed
the comments.

Of these I think the following may be useful to apply right away:
  03/13  libxl: Provide a version of bsd's queue.h as _libxl_list.h

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZD-0003gI-Oi; Mon, 28 Nov 2011 17:00:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZB-0003eA-Ef
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29160 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169233"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055e-Du; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cZ-CO;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:32 +0000
Message-ID: <1322499580-2322-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/13] libxl: idl: Provide struct and union tags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Instead of generating:

   typedef struct {
     ...
   } libxl_foo;

Produce:

   typedef struct libxl_foo {
     ...
   } libxl_foo;

This makes it possible to refer to libxl idl-generated structs and
unions, as incomplete types, before they have been defined.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/gentypes.py |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index d8f43e3..7ca6375 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -56,7 +56,7 @@ def libxl_C_type_define(ty, indent = ""):
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
-            s += "typedef %s {\n" % ty.kind
+            s += "typedef %s %s {\n" % (ty.kind, ty.typename)
 
         for f in ty.fields:
             if f.comment is not None:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZD-0003gI-Oi; Mon, 28 Nov 2011 17:00:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZB-0003eA-Ef
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29160 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169233"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055e-Du; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cZ-CO;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:32 +0000
Message-ID: <1322499580-2322-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/13] libxl: idl: Provide struct and union tags
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Instead of generating:

   typedef struct {
     ...
   } libxl_foo;

Produce:

   typedef struct libxl_foo {
     ...
   } libxl_foo;

This makes it possible to refer to libxl idl-generated structs and
unions, as incomplete types, before they have been defined.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/gentypes.py |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index d8f43e3..7ca6375 100644
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -56,7 +56,7 @@ def libxl_C_type_define(ty, indent = ""):
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
-            s += "typedef %s {\n" % ty.kind
+            s += "typedef %s %s {\n" % (ty.kind, ty.typename)
 
         for f in ty.fields:
             if f.comment is not None:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZD-0003fo-3B; Mon, 28 Nov 2011 17:00:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZA-0003e6-Po
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29057 invoked from network); 28 Nov 2011 16:59:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169229"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055Z-BF; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cN-9h;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:29 +0000
Message-ID: <1322499580-2322-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/13] libxenstore: Provide xs_check_watch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Event-driven programs want to wait until the xs_fileno triggers for
reading, and then repeatedly call xs_check_watch.

Also xs_read_watch exposes a useless "num" out parameter, which should
always (if things aren't going hideously wrong) be at least 2 and
which the caller shouldn't be interested in.  So xs_check_watch
doesn't have one of those.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/xenstore/xs.c |   89 ++++++++++++++++++++++++++++++++++++++++++++-------
 tools/xenstore/xs.h |   16 +++++++++
 2 files changed, 93 insertions(+), 12 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index c72ea83..5d0b567 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -132,7 +132,23 @@ struct xs_handle {
 
 #endif
 
-static int read_message(struct xs_handle *h);
+static int read_message(struct xs_handle *h, int nonblocking);
+
+static void setnonblock(int fd, int nonblock) {
+	int esave = errno;
+	int flags = fcntl(fd, F_GETFL);
+	if (flags == -1)
+		goto out;
+
+	if (nonblock)
+		flags |= O_NONBLOCK;
+	else
+		flags &= ~O_NONBLOCK;
+
+	fcntl(fd, F_SETFL, flags);
+out:
+	errno = esave;
+}
 
 int xs_fileno(struct xs_handle *h)
 {
@@ -327,8 +343,16 @@ void xs_close(struct xs_handle* xsh)
 		xs_daemon_close(xsh);
 }
 
-static bool read_all(int fd, void *data, unsigned int len)
+static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
+	/* With nonblocking, either reads either everything requested,
+	 * or nothing. */
 {
+	if (!len)
+		return true;
+
+	if (nonblocking)
+		setnonblock(fd, 1);
+
 	while (len) {
 		int done;
 
@@ -336,18 +360,28 @@ static bool read_all(int fd, void *data, unsigned int len)
 		if (done < 0) {
 			if (errno == EINTR)
 				continue;
-			return false;
+			goto out_false;
 		}
 		if (done == 0) {
 			/* It closed fd on us?  EBADF is appropriate. */
 			errno = EBADF;
-			return false;
+			goto out_false;
 		}
 		data += done;
 		len -= done;
+
+		if (nonblocking) {
+			setnonblock(fd, 0);
+			nonblocking = 0;
+		}
 	}
 
 	return true;
+
+out_false:
+	if (nonblocking)
+		setnonblock(fd, 0);
+	return false;
 }
 
 #ifdef XSTEST
@@ -376,7 +410,7 @@ static void *read_reply(
 	read_from_thread = read_thread_exists(h);
 
 	/* Read from comms channel ourselves if there is no reader thread. */
-	if (!read_from_thread && (read_message(h) == -1))
+	if (!read_from_thread && (read_message(h, 0) == -1))
 		return NULL;
 
 	mutex_lock(&h->reply_mutex);
@@ -695,7 +729,8 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token)
  * Returns array of two pointers: path and token, or NULL.
  * Call free() after use.
  */
-char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
+				  int nonblocking)
 {
 	struct xs_stored_msg *msg;
 	char **ret, *strings, c = 0;
@@ -709,14 +744,20 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	 * we haven't called xs_watch.	Presumably the application
 	 * will do so later; in the meantime we just block.
 	 */
-	while (list_empty(&h->watch_list) && h->fd != -1)
+	while (list_empty(&h->watch_list) && h->fd != -1) {
+		if (nonblocking) {
+			mutex_unlock(&h->watch_mutex);
+			errno = EAGAIN;
+			return 0;
+		}
 		condvar_wait(&h->watch_condvar, &h->watch_mutex);
+	}
 #else /* !defined(USE_PTHREAD) */
 	/* Read from comms channel ourselves if there are no threads
 	 * and therefore no reader thread. */
 
 	assert(!read_thread_exists(h)); /* not threadsafe but worth a check */
-	if ((read_message(h) == -1))
+	if ((read_message(h, nonblocking) == -1))
 		return NULL;
 
 #endif /* !defined(USE_PTHREAD) */
@@ -762,6 +803,24 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	return ret;
 }
 
+char **xs_check_watch(struct xs_handle *h)
+{
+	unsigned int num;
+	char **ret;
+	ret = read_watch_internal(h, &num, 1);
+	if (ret) assert(num >= 2);
+	return ret;
+}
+
+/* Find out what node change was on (will block if nothing pending).
+ * Returns array of two pointers: path and token, or NULL.
+ * Call free() after use.
+ */
+char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+{
+	return read_watch_internal(h, num, 0);
+}
+
 /* Remove a watch on a node.
  * Returns false on failure (no watch on that node).
  */
@@ -942,11 +1001,17 @@ char *xs_debug_command(struct xs_handle *h, const char *cmd,
 			ARRAY_SIZE(iov), NULL);
 }
 
-static int read_message(struct xs_handle *h)
+static int read_message(struct xs_handle *h, int nonblocking)
 {
 	/* IMPORTANT: It is forbidden to call this function without
 	 * acquiring the request lock and checking that h->read_thr_exists
 	 * is false.  See "Lock discipline" in struct xs_handle, above. */
+
+	/* If nonblocking==1, this function will always read either
+	 * nothing, returning -1 and setting errno==EAGAIN, or we read
+	 * whole amount requested.  Ie as soon as we have the start of
+	 * the message we block until we get all of it.
+	 */
          
 	struct xs_stored_msg *msg = NULL;
 	char *body = NULL;
@@ -958,7 +1023,7 @@ static int read_message(struct xs_handle *h)
 	if (msg == NULL)
 		goto error;
 	cleanup_push(free, msg);
-	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr))) { /* Cancellation point */
+	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
 	}
@@ -968,7 +1033,7 @@ static int read_message(struct xs_handle *h)
 	if (body == NULL)
 		goto error_freemsg;
 	cleanup_push(free, body);
-	if (!read_all(h->fd, body, msg->hdr.len)) { /* Cancellation point */
+	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
 	}
@@ -1023,7 +1088,7 @@ static void *read_thread(void *arg)
 	struct xs_handle *h = arg;
 	int fd;
 
-	while (read_message(h) != -1)
+	while (read_message(h, 0) != -1)
 		continue;
 
 	/* An error return from read_message leaves the socket in an undefined
diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
index 1cbe255..63f535d 100644
--- a/tools/xenstore/xs.h
+++ b/tools/xenstore/xs.h
@@ -135,6 +135,22 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token);
 /* Return the FD to poll on to see if a watch has fired. */
 int xs_fileno(struct xs_handle *h);
 
+/* Check for node changes.  On success, returns a non-NULL pointer ret
+ * such that ret[0] and ret[1] are valid C strings, namely the
+ * triggering path (see docs/misc/xenstore.txt) and the token (from
+ * xs_watch).  On error return value is NULL setting errno.
+ * 
+ * Callers should, after xs_fileno has become readable, repeatedly
+ * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
+ * (If the fd became readable, xs_check_watch is allowed to make it no
+ * longer show up as readable even if future calls to xs_check_watch
+ * will return more watch events.)
+ *
+ * After the caller is finished with the returned information it
+ * should be freed all in one go with free(ret).
+ */
+char **xs_check_watch(struct xs_handle *h);
+
 /* Find out what node change was on (will block if nothing pending).
  * Returns array containing the path and token. Use XS_WATCH_* to access these
  * elements. Call free() after use.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZD-0003fo-3B; Mon, 28 Nov 2011 17:00:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZA-0003e6-Po
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29057 invoked from network); 28 Nov 2011 16:59:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169229"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055Z-BF; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cN-9h;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:29 +0000
Message-ID: <1322499580-2322-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 02/13] libxenstore: Provide xs_check_watch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Event-driven programs want to wait until the xs_fileno triggers for
reading, and then repeatedly call xs_check_watch.

Also xs_read_watch exposes a useless "num" out parameter, which should
always (if things aren't going hideously wrong) be at least 2 and
which the caller shouldn't be interested in.  So xs_check_watch
doesn't have one of those.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/xenstore/xs.c |   89 ++++++++++++++++++++++++++++++++++++++++++++-------
 tools/xenstore/xs.h |   16 +++++++++
 2 files changed, 93 insertions(+), 12 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index c72ea83..5d0b567 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -132,7 +132,23 @@ struct xs_handle {
 
 #endif
 
-static int read_message(struct xs_handle *h);
+static int read_message(struct xs_handle *h, int nonblocking);
+
+static void setnonblock(int fd, int nonblock) {
+	int esave = errno;
+	int flags = fcntl(fd, F_GETFL);
+	if (flags == -1)
+		goto out;
+
+	if (nonblock)
+		flags |= O_NONBLOCK;
+	else
+		flags &= ~O_NONBLOCK;
+
+	fcntl(fd, F_SETFL, flags);
+out:
+	errno = esave;
+}
 
 int xs_fileno(struct xs_handle *h)
 {
@@ -327,8 +343,16 @@ void xs_close(struct xs_handle* xsh)
 		xs_daemon_close(xsh);
 }
 
-static bool read_all(int fd, void *data, unsigned int len)
+static bool read_all(int fd, void *data, unsigned int len, int nonblocking)
+	/* With nonblocking, either reads either everything requested,
+	 * or nothing. */
 {
+	if (!len)
+		return true;
+
+	if (nonblocking)
+		setnonblock(fd, 1);
+
 	while (len) {
 		int done;
 
@@ -336,18 +360,28 @@ static bool read_all(int fd, void *data, unsigned int len)
 		if (done < 0) {
 			if (errno == EINTR)
 				continue;
-			return false;
+			goto out_false;
 		}
 		if (done == 0) {
 			/* It closed fd on us?  EBADF is appropriate. */
 			errno = EBADF;
-			return false;
+			goto out_false;
 		}
 		data += done;
 		len -= done;
+
+		if (nonblocking) {
+			setnonblock(fd, 0);
+			nonblocking = 0;
+		}
 	}
 
 	return true;
+
+out_false:
+	if (nonblocking)
+		setnonblock(fd, 0);
+	return false;
 }
 
 #ifdef XSTEST
@@ -376,7 +410,7 @@ static void *read_reply(
 	read_from_thread = read_thread_exists(h);
 
 	/* Read from comms channel ourselves if there is no reader thread. */
-	if (!read_from_thread && (read_message(h) == -1))
+	if (!read_from_thread && (read_message(h, 0) == -1))
 		return NULL;
 
 	mutex_lock(&h->reply_mutex);
@@ -695,7 +729,8 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token)
  * Returns array of two pointers: path and token, or NULL.
  * Call free() after use.
  */
-char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
+				  int nonblocking)
 {
 	struct xs_stored_msg *msg;
 	char **ret, *strings, c = 0;
@@ -709,14 +744,20 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	 * we haven't called xs_watch.	Presumably the application
 	 * will do so later; in the meantime we just block.
 	 */
-	while (list_empty(&h->watch_list) && h->fd != -1)
+	while (list_empty(&h->watch_list) && h->fd != -1) {
+		if (nonblocking) {
+			mutex_unlock(&h->watch_mutex);
+			errno = EAGAIN;
+			return 0;
+		}
 		condvar_wait(&h->watch_condvar, &h->watch_mutex);
+	}
 #else /* !defined(USE_PTHREAD) */
 	/* Read from comms channel ourselves if there are no threads
 	 * and therefore no reader thread. */
 
 	assert(!read_thread_exists(h)); /* not threadsafe but worth a check */
-	if ((read_message(h) == -1))
+	if ((read_message(h, nonblocking) == -1))
 		return NULL;
 
 #endif /* !defined(USE_PTHREAD) */
@@ -762,6 +803,24 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 	return ret;
 }
 
+char **xs_check_watch(struct xs_handle *h)
+{
+	unsigned int num;
+	char **ret;
+	ret = read_watch_internal(h, &num, 1);
+	if (ret) assert(num >= 2);
+	return ret;
+}
+
+/* Find out what node change was on (will block if nothing pending).
+ * Returns array of two pointers: path and token, or NULL.
+ * Call free() after use.
+ */
+char **xs_read_watch(struct xs_handle *h, unsigned int *num)
+{
+	return read_watch_internal(h, num, 0);
+}
+
 /* Remove a watch on a node.
  * Returns false on failure (no watch on that node).
  */
@@ -942,11 +1001,17 @@ char *xs_debug_command(struct xs_handle *h, const char *cmd,
 			ARRAY_SIZE(iov), NULL);
 }
 
-static int read_message(struct xs_handle *h)
+static int read_message(struct xs_handle *h, int nonblocking)
 {
 	/* IMPORTANT: It is forbidden to call this function without
 	 * acquiring the request lock and checking that h->read_thr_exists
 	 * is false.  See "Lock discipline" in struct xs_handle, above. */
+
+	/* If nonblocking==1, this function will always read either
+	 * nothing, returning -1 and setting errno==EAGAIN, or we read
+	 * whole amount requested.  Ie as soon as we have the start of
+	 * the message we block until we get all of it.
+	 */
          
 	struct xs_stored_msg *msg = NULL;
 	char *body = NULL;
@@ -958,7 +1023,7 @@ static int read_message(struct xs_handle *h)
 	if (msg == NULL)
 		goto error;
 	cleanup_push(free, msg);
-	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr))) { /* Cancellation point */
+	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
 	}
@@ -968,7 +1033,7 @@ static int read_message(struct xs_handle *h)
 	if (body == NULL)
 		goto error_freemsg;
 	cleanup_push(free, body);
-	if (!read_all(h->fd, body, msg->hdr.len)) { /* Cancellation point */
+	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
 	}
@@ -1023,7 +1088,7 @@ static void *read_thread(void *arg)
 	struct xs_handle *h = arg;
 	int fd;
 
-	while (read_message(h) != -1)
+	while (read_message(h, 0) != -1)
 		continue;
 
 	/* An error return from read_message leaves the socket in an undefined
diff --git a/tools/xenstore/xs.h b/tools/xenstore/xs.h
index 1cbe255..63f535d 100644
--- a/tools/xenstore/xs.h
+++ b/tools/xenstore/xs.h
@@ -135,6 +135,22 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token);
 /* Return the FD to poll on to see if a watch has fired. */
 int xs_fileno(struct xs_handle *h);
 
+/* Check for node changes.  On success, returns a non-NULL pointer ret
+ * such that ret[0] and ret[1] are valid C strings, namely the
+ * triggering path (see docs/misc/xenstore.txt) and the token (from
+ * xs_watch).  On error return value is NULL setting errno.
+ * 
+ * Callers should, after xs_fileno has become readable, repeatedly
+ * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
+ * (If the fd became readable, xs_check_watch is allowed to make it no
+ * longer show up as readable even if future calls to xs_check_watch
+ * will return more watch events.)
+ *
+ * After the caller is finished with the returned information it
+ * should be freed all in one go with free(ret).
+ */
+char **xs_check_watch(struct xs_handle *h);
+
 /* Find out what node change was on (will block if nothing pending).
  * Returns array containing the path and token. Use XS_WATCH_* to access these
  * elements. Call free() after use.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZC-0003f4-52; Mon, 28 Nov 2011 17:00:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZA-0003dy-5W
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29038 invoked from network); 28 Nov 2011 16:59:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169228"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055Y-9x; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cL-97;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 28 Nov 2011 16:59:28 +0000
Message-ID: <1322499580-2322-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/13] libxl: Make libxl__xs_* more const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paths and values which are not modified by these functions should be
declared as "const char *" not "char *".

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    9 +++++----
 tools/libxl/libxl_xshelp.c   |    9 +++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..bfc74c9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -172,18 +172,19 @@ _hidden char *libxl__dirname(libxl__gc *gc, const char *s);
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char **kvs);
+                             const char *dir, char **kvs);
 _hidden int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
+               const char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
    /* Each fn returns 0 on success.
     * On error: returns -1, sets errno (no logging) */
 
 _hidden char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid);
    /* On error: logs, returns NULL, sets errno. */
 
-_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path);
+_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
+                             const char *path);
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
-                                   char *path, unsigned int *nb);
+                                   const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 4b09be3..bc4e7e4 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -49,7 +49,7 @@ char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
 }
 
 int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char *kvs[])
+                     const char *dir, char *kvs[])
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
@@ -69,7 +69,7 @@ int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
 }
 
 int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...)
+                    const char *path, const char *fmt, ...)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *s;
@@ -87,7 +87,7 @@ int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
     return 0;
 }
 
-char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path)
+char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *ptr;
@@ -113,7 +113,8 @@ char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
-char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t, char *path, unsigned int *nb)
+char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, unsigned int *nb)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **ret = NULL;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZC-0003f4-52; Mon, 28 Nov 2011 17:00:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZA-0003dy-5W
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29038 invoked from network); 28 Nov 2011 16:59:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169228"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055Y-9x; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cL-97;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 28 Nov 2011 16:59:28 +0000
Message-ID: <1322499580-2322-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/13] libxl: Make libxl__xs_* more const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paths and values which are not modified by these functions should be
declared as "const char *" not "char *".

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |    9 +++++----
 tools/libxl/libxl_xshelp.c   |    9 +++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..bfc74c9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -172,18 +172,19 @@ _hidden char *libxl__dirname(libxl__gc *gc, const char *s);
 _hidden char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length);
 
 _hidden int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char **kvs);
+                             const char *dir, char **kvs);
 _hidden int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
+               const char *path, const char *fmt, ...) PRINTF_ATTRIBUTE(4, 5);
    /* Each fn returns 0 on success.
     * On error: returns -1, sets errno (no logging) */
 
 _hidden char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid);
    /* On error: logs, returns NULL, sets errno. */
 
-_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path);
+_hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
+                             const char *path);
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
-                                   char *path, unsigned int *nb);
+                                   const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
 
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index 4b09be3..bc4e7e4 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -49,7 +49,7 @@ char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
 }
 
 int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
-                    char *dir, char *kvs[])
+                     const char *dir, char *kvs[])
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
@@ -69,7 +69,7 @@ int libxl__xs_writev(libxl__gc *gc, xs_transaction_t t,
 }
 
 int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
-                   char *path, const char *fmt, ...)
+                    const char *path, const char *fmt, ...)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *s;
@@ -87,7 +87,7 @@ int libxl__xs_write(libxl__gc *gc, xs_transaction_t t,
     return 0;
 }
 
-char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, char *path)
+char * libxl__xs_read(libxl__gc *gc, xs_transaction_t t, const char *path)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *ptr;
@@ -113,7 +113,8 @@ char *libxl__xs_get_dompath(libxl__gc *gc, uint32_t domid)
     return s;
 }
 
-char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t, char *path, unsigned int *nb)
+char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
+                           const char *path, unsigned int *nb)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **ret = NULL;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZC-0003fY-JG; Mon, 28 Nov 2011 17:00:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZA-0003e4-NH
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29083 invoked from network); 28 Nov 2011 16:59:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055b-CU; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cV-Bk;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:31 +0000
Message-ID: <1322499580-2322-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/13] libxl: idl: support new "c_only" type
	attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This provides for fields in libxl datatypes which are only present in
the C version of structures.  This is useful, for example, when a
libxl datatype wants to contain fields which are used by libxl
internally and which are only present in the structure to avoid
additional memory allocation inconvenience.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/gentest.py    |    2 ++
 tools/libxl/libxltypes.py |    4 +++-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
index 05e77cc..9b2812e 100644
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -56,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
         s += "%s = rand() %% 2;\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
+    elif ty.c_only:
+        pass
     elif ty.typename in handcoded:
         raise Exception("Gen for handcoded %s" % ty.typename)
     else:
diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py
index 55056c2..dfca943 100644
--- a/tools/libxl/libxltypes.py
+++ b/tools/libxl/libxltypes.py
@@ -33,6 +33,8 @@ class Type(object):
         if self.passby not in [PASS_BY_VALUE, PASS_BY_REFERENCE]:
             raise ValueError
 
+        self.c_only = kwargs.setdefault('c_only', False)
+
         if typename is None: # Anonymous type
             self.typename = None
             self.rawname = None
@@ -50,7 +52,7 @@ class Type(object):
 
         self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
 
-        if self.typename is not None:
+        if self.typename is not None and not self.c_only:
             self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
         else:
             self.json_fn = kwargs.setdefault('json_fn', None)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZC-0003fY-JG; Mon, 28 Nov 2011 17:00:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZA-0003e4-NH
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29083 invoked from network); 28 Nov 2011 16:59:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055b-CU; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cV-Bk;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:31 +0000
Message-ID: <1322499580-2322-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 04/13] libxl: idl: support new "c_only" type
	attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This provides for fields in libxl datatypes which are only present in
the C version of structures.  This is useful, for example, when a
libxl datatype wants to contain fields which are used by libxl
internally and which are only present in the structure to avoid
additional memory allocation inconvenience.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/gentest.py    |    2 ++
 tools/libxl/libxltypes.py |    4 +++-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
index 05e77cc..9b2812e 100644
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -56,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
         s += "%s = rand() %% 2;\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
+    elif ty.c_only:
+        pass
     elif ty.typename in handcoded:
         raise Exception("Gen for handcoded %s" % ty.typename)
     else:
diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py
index 55056c2..dfca943 100644
--- a/tools/libxl/libxltypes.py
+++ b/tools/libxl/libxltypes.py
@@ -33,6 +33,8 @@ class Type(object):
         if self.passby not in [PASS_BY_VALUE, PASS_BY_REFERENCE]:
             raise ValueError
 
+        self.c_only = kwargs.setdefault('c_only', False)
+
         if typename is None: # Anonymous type
             self.typename = None
             self.rawname = None
@@ -50,7 +52,7 @@ class Type(object):
 
         self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
 
-        if self.typename is not None:
+        if self.typename is not None and not self.c_only:
             self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
         else:
             self.json_fn = kwargs.setdefault('json_fn', None)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZE-0003gY-BZ; Mon, 28 Nov 2011 17:00:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZB-0003eB-Hu
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29182 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169234"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055f-ES; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cd-Dc;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:33 +0000
Message-ID: <1322499580-2322-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/13] libxl: permit declaration after statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

GCC and C99 allow declarations to be mixed with code.  This is a good
idea because:

 * It allows variables to be more often initialised as they are
   declared, thus reducing the occurrence of uninitialised variable
   errors.

 * Certain alloca-like constructs (arrays allocated at runtime on the
   stack) can more often be written without a spurious { } block.
   Such blocks are confusing to read.

 * It makes it easier to write and use macros which declare and
   initialise formulaic variables and do other function setup code,
   because there is no need to worry that such macros might be
   incompatible with each other or have strict ordering constraints.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index f363da2..4e0f3fb 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,8 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
+CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+	-Wno-declaration-after-statement
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZE-0003gY-BZ; Mon, 28 Nov 2011 17:00:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZB-0003eB-Hu
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29182 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169234"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055f-ES; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cd-Dc;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:33 +0000
Message-ID: <1322499580-2322-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/13] libxl: permit declaration after statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

GCC and C99 allow declarations to be mixed with code.  This is a good
idea because:

 * It allows variables to be more often initialised as they are
   declared, thus reducing the occurrence of uninitialised variable
   errors.

 * Certain alloca-like constructs (arrays allocated at runtime on the
   stack) can more often be written without a spurious { } block.
   Such blocks are confusing to read.

 * It makes it easier to write and use macros which declare and
   initialise formulaic variables and do other function setup code,
   because there is no need to worry that such macros might be
   incompatible with each other or have strict ordering constraints.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index f363da2..4e0f3fb 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,8 @@ MINOR = 0
 XLUMAJOR = 1.0
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations
+CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+	-Wno-declaration-after-statement
 CFLAGS += -I. -fPIC
 
 ifeq ($(CONFIG_Linux),y)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZH-0003jJ-MS; Mon, 28 Nov 2011 17:00:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZC-0003eL-AJ
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29242 invoked from network); 28 Nov 2011 16:59:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169241"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055y-NA; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000eA-LZ;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:40 +0000
Message-ID: <1322499580-2322-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/13] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace the existing API for retrieving high-level events (events
about domains, etc.) from libxl with a new one.

This changes the definition and semantics of the `libxl_event'
structure, and replaces the calls for obtaining information about
domain death and disk eject events.

This is an incompatible change, sorry.  The alternative was to try to
provide both the previous horrid API and the new one, and would also
involve never using the name `libxl_event' for the new interface.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |  306 +++++++++++++++++++++++++++++------------
 tools/libxl/libxl.h          |   55 ++-------
 tools/libxl/libxl_event.c    |  187 +++++++++++++++++++++++---
 tools/libxl/libxl_event.h    |  180 ++++++++++++++++++++++++-
 tools/libxl/libxl_internal.c |    6 +
 tools/libxl/libxl_internal.h |   72 ++++++++++-
 tools/libxl/libxl_types.idl  |   35 ++++-
 tools/libxl/xl_cmdimpl.c     |  261 +++++++++++++++++++++---------------
 8 files changed, 828 insertions(+), 274 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b977f7c..95925ef 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -62,6 +62,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     ctx->osevent_hooks = 0;
 
+    ctx->fd_polls = 0;
     ctx->fd_beforepolled = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -70,6 +71,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_SLIST_INIT(&ctx->watch_freeslots);
     libxl__ev_fd_init(&ctx->watch_efd);
 
+    LIBXL_TAILQ_INIT(&ctx->death_list);
+    libxl__ev_xswatch_init(&ctx->death_watch);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -97,6 +101,13 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return 0;
 }
 
+static void free_disable_deaths(libxl__gc *gc,
+                                struct libxl__evgen_domain_death_list *l) {
+    libxl_evgen_domain_death *death;
+    while ((death = LIBXL_TAILQ_FIRST(l)))
+        libxl__evdisable_domain_death(gc, death);
+}
+
 int libxl_ctx_free(libxl_ctx *ctx)
 {
     int i;
@@ -104,6 +115,9 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     if (!ctx) return 0;
 
+    free_disable_deaths(gc, &CTX->death_list);
+    free_disable_deaths(gc, &CTX->death_reported);
+
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
     libxl__ev_fd_deregister(gc, &ctx->watch_efd);
@@ -115,6 +129,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
 
+    free(ctx->fd_polls);
     free(ctx->fd_beforepolled);
     free(ctx->watch_slots);
 
@@ -614,117 +629,175 @@ int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
     return 0;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_domain_death *evg;
+    uint32_t domid;
+    int rc;
 
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter)
-{
-    waiter->path = strdup("@releaseDomain");
-    if (asprintf(&(waiter->token), "%d", LIBXL_EVENT_TYPE_DOMAIN_DEATH) < 0)
-        return -1;
-    if (!xs_watch(ctx->xsh, waiter->path, waiter->token))
-        return -1;
-    return 0;
-}
+    CTX_LOCK;
 
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
-{
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    int i, rc = -1;
-    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+    evg = LIBXL_TAILQ_FIRST(&CTX->death_list);
+    if (!evg) goto out;
 
-    if (!domid)
-        domid = guest_domid;
+    domid = evg->domid;
 
-    for (i = 0; i < num_disks; i++) {
-        if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
-                     libxl__xs_get_dompath(&gc, domid),
-                     libxl__device_disk_dev_number(disks[i].vdev,
-                                                   NULL, NULL)) < 0)
-            goto out;
-        if (asprintf(&(waiter[i].token), "%d", LIBXL_EVENT_TYPE_DISK_EJECT) < 0)
+    for (;;) {
+        int nentries = LIBXL_TAILQ_NEXT(evg, entry) ? 200 : 1;
+        xc_domaininfo_t domaininfos[nentries];
+        const xc_domaininfo_t *got = domaininfos, *gotend;
+
+        rc = xc_domain_getinfolist(CTX->xch, domid, nentries, domaininfos);
+        if (rc == -1) {
+            LIBXL__EVENT_DISASTER(gc, "xc_domain_getinfolist failed while"
+                                  " processing @releaseDomain watch event",
+                                  errno, 0);
             goto out;
-        xs_watch(ctx->xsh, waiter[i].path, waiter[i].token);
+        }
+        gotend = &domaininfos[rc];
+
+        for (;;) {
+            if (!evg)
+                goto all_reported;
+
+            if (!rc || got->domain > evg->domid) {
+                /* ie, the list doesn't contain evg->domid any more so
+                 * the domain has been destroyed */
+                libxl_evgen_domain_death *evg_next;
+
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(gc, ev);
+
+                evg->death_reported = 1;
+                evg_next = LIBXL_TAILQ_NEXT(evg, entry);
+                LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+                LIBXL_TAILQ_INSERT_HEAD(&CTX->death_reported, evg, entry);
+                evg = evg_next;
+
+                continue;
+            }
+            
+            if (got == gotend)
+                break;
+
+            if (got->domain < evg->domid) {
+                got++;
+                continue;
+            }
+
+            assert(evg->domid == got->domain);
+
+            if (!evg->shutdown_reported &&
+                (got->flags & XEN_DOMINF_shutdown)) {
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_SHUTDOWN, got->domain);
+                if (!ev) goto out;
+                
+                ev->u.domain_shutdown.shutdown_reason =
+                    (got->flags >> XEN_DOMINF_shutdownshift) &
+                    XEN_DOMINF_shutdownmask;
+                libxl__event_occurred(gc, ev);
+
+                evg->shutdown_reported = 1;
+            }
+            evg = LIBXL_TAILQ_NEXT(evg, entry);
+        }
+
+        assert(rc); /* rc==0 results in us eating all evgs and quitting */
+        domid = gotend[-1].domain;
     }
-    rc = 0;
-out:
-    libxl__free_all(&gc);
-    return rc;
+ all_reported:
+ out:
+
+    CTX_UNLOCK;
 }
 
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event)
-{
-    unsigned int num;
-    char **events = xs_read_watch(ctx->xsh, &num);
-    if (num != 2) {
-        free(events);
-        return ERROR_FAIL;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
+    GC_INIT(ctx);
+    libxl_evgen_domain_death *evg, *evg_search;
+    int rc;
+    
+    CTX_LOCK;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->domid = domid;
+    evg->user = user;
+
+    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,
+                              evg->domid > evg_search->domid);
+
+    if (!libxl__ev_xswatch_isregistered(&ctx->death_watch)) {
+        rc = libxl__ev_xswatch_register(gc, &ctx->death_watch,
+                        domain_death_xswatch_callback, "@releaseDomain");
+        if (rc) { libxl__evdisable_domain_death(gc, evg); goto out; }
     }
-    event->path = strdup(events[XS_WATCH_PATH]);
-    event->token = strdup(events[XS_WATCH_TOKEN]);
-    event->type = atoi(event->token);
-    free(events);
-    return 0;
-}
 
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter)
-{
-    if (!xs_unwatch(ctx->xsh, waiter->path, waiter->token))
-        return ERROR_FAIL;
-    else
-        return 0;
-}
+    rc = 0;
 
-int libxl_free_event(libxl_event *event)
-{
-    free(event->path);
-    free(event->token);
-    return 0;
-}
+ out:
+    CTX_UNLOCK;
+    return rc;
+};
 
-int libxl_free_waiter(libxl_waiter *waiter)
-{
-    free(waiter->path);
-    free(waiter->token);
-    return 0;
-}
+void libxl__evdisable_domain_death(libxl__gc *gc,
+                                   libxl_evgen_domain_death *evg) {
+    CTX_LOCK;
 
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info)
-{
-    if (libxl_domain_info(ctx, info, domid) < 0)
-        return 0;
+    if (!evg->death_reported)
+        LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+    else
+        LIBXL_TAILQ_REMOVE(&CTX->death_reported, evg, entry);
 
-    if (info->running || (!info->shutdown && !info->dying))
-        return ERROR_INVAL;
+    free(evg);
+
+    if (!LIBXL_TAILQ_FIRST(&CTX->death_list) &&
+        libxl__ev_xswatch_isregistered(&CTX->death_watch))
+        libxl__ev_xswatch_deregister(gc, &CTX->death_watch);
 
-    return 1;
+    CTX_UNLOCK;
 }
 
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
-{
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *path;
+void libxl_evdisable_domain_death(libxl_ctx *ctx,
+                                  libxl_evgen_domain_death *evg) {
+    GC_INIT(ctx);
+    libxl__evdisable_domain_death(gc, evg);
+    GC_FREE;
+}
+
+static void disk_eject_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *watch,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_domain_death *evg = (void*)watch;
+    int rc;
     char *backend;
     char *value;
     char backend_type[BACKEND_STRING_SIZE+1];
 
-    value = libxl__xs_read(&gc, XBT_NULL, event->path);
+    value = libxl__xs_read(gc, XBT_NULL, wpath);
 
-    if (!value || strcmp(value,  "eject")) {
-        libxl__free_all(&gc);
-        return 0;
+    if (!value || strcmp(value,  "eject"))
+        return;
+
+    rc = libxl__xs_write(gc, XBT_NULL, wpath, "");
+    if (rc) {
+        LIBXL__EVENT_DISASTER(gc, "xs_write failed acknowledging eject",
+                              errno, LIBXL_EVENT_TYPE_DISK_EJECT);
+        return;
     }
 
-    path = strdup(event->path);
-    path[strlen(path) - 6] = '\0';
-    backend = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend", path));
+    libxl_event *ev = NEW_EVENT(gc, DISK_EJECT, evg->domid);
+    libxl_device_disk *disk = &ev->u.disk_eject.disk;
+    
+    backend = libxl__xs_read(gc, XBT_NULL,
+                             libxl__sprintf(gc, "%.*s/backend",
+                                            (int)strlen(wpath)-6, wpath));
 
     sscanf(backend,
-            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
-            &disk->backend_domid, backend_type);
+            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE)
+           "[a-z]/%*d/%*d",
+           &disk->backend_domid, backend_type);
     if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) {
         disk->backend = LIBXL_DISK_BACKEND_TAP;
     } else if (!strcmp(backend_type, "qdisk")) {
@@ -733,19 +806,72 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
         disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
     }
 
-    disk->pdev_path = strdup("");
+    disk->pdev_path = strdup(""); /* xxx fixme malloc failure */
     disk->format = LIBXL_DISK_FORMAT_EMPTY;
     /* this value is returned to the user: do not free right away */
-    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "%s/dev", backend), NULL);
+    disk->vdev = xs_read(CTX->xsh, XBT_NULL,
+                         libxl__sprintf(gc, "%s/dev", backend), NULL);
     disk->removable = 1;
     disk->readwrite = 0;
     disk->is_cdrom = 1;
 
-    free(path);
-    libxl__free_all(&gc);
-    return 1;
+    libxl__event_occurred(gc, ev);
 }
 
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t guest_domid,
+                              const char *vdev, libxl_ev_user user,
+                              libxl_evgen_disk_eject **evgen_out) {
+    GC_INIT(ctx);
+    int rc;
+    char *path;
+    libxl_evgen_disk_eject *evg = NULL;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->user = user;
+
+    evg->vdev = strdup(vdev);
+    if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
+
+    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+    evg->domid = domid;
+
+    if (!domid)
+        domid = guest_domid;
+
+    path = libxl__sprintf(gc, "%s/device/vbd/%d/eject",
+                 libxl__xs_get_dompath(gc, domid),
+                 libxl__device_disk_dev_number(vdev, NULL, NULL));
+    if (!path) { rc = ERROR_NOMEM; goto out; }
+
+    rc = libxl__ev_xswatch_register(gc, &evg->watch,
+                                    disk_eject_xswatch_callback, path);
+    if (rc) goto out;
+
+    GC_FREE;
+    return 0;
+
+ out:
+    if (evg)
+        libxl__evdisable_disk_eject(gc, evg);
+    GC_FREE;
+    return rc;
+}
+
+void libxl__evdisable_disk_eject(libxl__gc *gc, libxl_evgen_disk_eject *evg) {
+    if (libxl__ev_xswatch_isregistered(&evg->watch))
+        libxl__ev_xswatch_deregister(gc, &evg->watch);
+
+    free(evg->vdev);
+    free(evg);
+}
+
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
+    GC_INIT(ctx);
+    libxl__evdisable_disk_eject(gc, evg);
+    GC_FREE;
+}    
+
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
 {
     libxl__gc gc = LIBXL_INIT_GC(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 13baa1b..7b33e12 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -53,7 +53,10 @@
  *    A public function may be called from within libxl; the call
  *    context initialisation macros will make sure that the internal
  *    caller's context is reused (eg, so that the same xenstore
- *    transaction is used).
+ *    transaction is used).  But in-libxl callers of libxl public
+ *    functions should note that any libxl public function may cause
+ *    recursively reentry into libxl via the application's event
+ *    callback hook.
  *
  *    Public functions have names like libxl_foobar.
  *
@@ -152,6 +155,8 @@ void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
 
 typedef uint32_t libxl_hwcap[8];
 
+typedef uint64_t libxl_ev_user;
+
 typedef struct {
     uint32_t size;          /* number of bytes in map */
     uint8_t *map;
@@ -200,6 +205,9 @@ typedef struct {
     int v;
 } libxl_enum_string_table;
 
+struct libxl_event;
+typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;
+
 typedef struct libxl__ctx libxl_ctx;
 
 #include "_libxl_types.h"
@@ -298,51 +306,6 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
-/* events handling */
-
-typedef struct {
-    /* event type */
-    libxl_event_type type;
-    /* data for internal use of the library */
-    char *path;
-    char *token;
-} libxl_event;
-
-typedef struct {
-    char *path;
-    char *token;
-} libxl_waiter;
-
-
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd);
-/* waiter is allocated by the caller */
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter);
-/* waiter is a preallocated array of num_disks libxl_waiter elements */
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter);
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event);
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter);
-int libxl_free_event(libxl_event *event);
-int libxl_free_waiter(libxl_waiter *waiter);
-
-/*
- * Returns:
- *  - 0 if the domain is dead but there is no cleanup to be done. e.g
- *    because someone else has already done it.
- *  - 1 if the domain is dead and there is cleanup to be done.
- *
- * Can return error if the domain exists and is still running.
- *
- * *info will contain valid domain state iff 1 is returned. In
- * particular if 1 is returned then info->shutdown_reason is
- * guaranteed to be valid since by definition the domain is
- * (shutdown||dying))
- */
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info);
-
-/*
- * Returns true and fills *disk if the caller should eject the disk
- */
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk);
 
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index b2377ea..5fb13b9 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -487,9 +487,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w) {
  * osevent poll
  */
 
-int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
-                             struct pollfd *fds, int *timeout_upd,
-                             struct timeval now) {
+static int beforepoll_unlocked(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now) {
     libxl__ev_fd *efd;
     int i;
 
@@ -500,9 +500,6 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
      * the fds array corresponds to a slot in fd_beforepolled.
      */
 
-    GC_INIT(ctx);
-    CTX_LOCK;
-
     if (*nfds_io) {
         /*
          * As an optimisation, we don't touch fd_beforepolled_used
@@ -574,16 +571,25 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
             *timeout_upd = our_timeout;
     }
 
-    CTX_UNLOCK;
-    GC_FREE;
     return rc;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
                              struct timeval now) {
-    int i;
+
     GC_INIT(ctx);
     CTX_LOCK;
+    int rc = beforepoll_unlocked(gc, nfds_io, fds, timeout_upd, now);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static void afterpoll_unlocked(libxl__gc *gc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now) {
+    int i;
 
     assert(nfds <= CTX->fd_beforepolled_used);
 
@@ -619,12 +625,17 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(gc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_unlocked(gc, nfds, fds, now);
     CTX_UNLOCK;
     GC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -682,11 +693,10 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
                type ? libxl_event_type_to_string(type) : "",
                type ? ")" : "");
 
-    /*
-     * FIXME: This should call the "disaster" hook supplied to
-     * libxl_event_register_callbacks, which will be introduced in the
-     * next patch.
-     */
+    if (CTX->event_hooks && CTX->event_hooks->disaster) {
+        CTX->event_hooks->disaster(CTX->event_hooks_user, type, msg, errnoval);
+        return;
+    }
 
     const char verybad[] =
         "DISASTER in event loop not handled by libxl application";
@@ -696,6 +706,151 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
 }
 
 /*
+ * Event retrieval etc.
+ */
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                  const libxl_event_hooks *hooks, void *user) {
+    ctx->event_hooks = hooks;
+    ctx->event_hooks_user = user;
+}
+
+void libxl__event_occurred(libxl__gc *gc, libxl_event *event) {
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__free_all will call the callback, just before exit
+         * from libxl.  This helps avoid reentrancy bugs: parts of
+         * libxl that call libxl__event_occurred do not have to worry
+         * that libxl might be reentered at that point. */
+        LIBXL_TAILQ_INSERT_TAIL(&gc->occurred_for_callback, event, link);
+        return;
+    } else {
+        LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+    }
+}
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event) {
+    libxl_event_dispose(event);
+    free(event);
+}
+
+libxl_event *libxl__event_new(libxl__gc *gc,
+                              libxl_event_type type, uint32_t domid) {
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(gc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_unlocked(libxl__gc *gc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user) {
+    libxl_event *ev;
+    int rc;
+
+    LIBXL_TAILQ_FOREACH(ev, &CTX->occurred, link) {
+        if (!(typemask & (1UL << ev->type)))
+            continue;
+
+        if (pred && !pred(ev, pred_user))
+            continue;
+
+        /* got one! */
+        LIBXL_TAILQ_REMOVE(&CTX->occurred, ev, link);
+        *event_r = ev;
+        rc = 0;
+        goto out;
+    }
+    rc = ERROR_NOT_READY;
+
+ out:
+    return rc;
+}
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *pred, void *pred_user) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *pred, void *pred_user) {
+    int rc;
+    struct timeval now;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        int timeout;
+
+        for (;;) {
+            int nfds = CTX->fd_polls_allocd;
+            timeout = -1;
+            rc = beforepoll_unlocked(gc, &nfds, CTX->fd_polls, &timeout, now);
+            if (!rc) break;
+            if (rc != ERROR_BUFFERFULL) goto out;
+            
+            struct pollfd *newarray =
+                (nfds > INT_MAX / sizeof(struct pollfd) / 2) ? 0 :
+                realloc(CTX->fd_polls, sizeof(*newarray) * nfds);
+            
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+
+            CTX->fd_polls_allocd = nfds;
+        }
+
+        rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+        if (rc < 0) {
+            if (errno == EINTR) continue;
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno, "poll failed");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        afterpoll_unlocked(gc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+        /* we unlock and free the gc each time we go through this loop,
+         * so that (a) we don't accumulate garbage and (b) any events
+         * which are to be dispatched by callback are actually delivered
+         * in a timely fashion.
+         */
+        CTX_UNLOCK;
+        libxl__free_all(gc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 25efbdf..bbe1ed0 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,178 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ */
+
+#define LIBXL_EVENTMASK_ALL (~(unsigned long)0)
+
+typedef int libxl_event_predicate(const libxl_event*, void *user);
+  /* Return value is 0 if the event is unwanted or non-0 if it is.
+   * Predicates are not allowed to fail.
+   */
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *predicate, void *predicate_user);
+  /* Searches for an event, already-happened, which matches typemask
+   * and predicate.  predicate==0 matches any event.
+   * libxl_event_check returns the event, which must then later be
+   * freed by the caller using libxl_event_free.
+   *
+   * Returns ERROR_NOT_READY if no such event has happened.
+   */
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *predicate, void *predicate_user);
+  /* Like libxl_event_check but blocks if no suitable events are
+   * available, until some are.  Uses libxl_osevent_beforepoll/
+   * _afterpoll so may be inefficient if very many domains are being
+   * handled by a single program.
+   */
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event);
+
+
+/* Alternatively or additionally, the application may also use this: */
+
+typedef struct libxl_event_hooks {
+    uint64_t event_occurs_mask;
+    void (*event_occurs)(void *user, const libxl_event *event);
+    void (*disaster)(void *user, libxl_event_type type,
+                     const char *msg, int errnoval);
+} libxl_event_hooks;
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                                    const libxl_event_hooks *hooks, void *user);
+  /*
+   * Arranges that libxl will henceforth call event_occurs for any
+   * events whose type is set in event_occurs_mask, rather than
+   * queueing the event for retrieval by libxl_event_check/wait.
+   * Events whose bit is clear in mask are not affected.
+   *
+   * event becomes owned by the application and must be freed, either
+   * by event_occurs or later.
+   *
+   * event_occurs may be NULL if mask is 0.
+   *
+   * libxl_event_register_callback also provides a way for libxl to
+   * report to the application that there was a problem reporting
+   * events; this can occur due to lack of host memory during event
+   * handling, or other wholly unrecoverable errors from system calls
+   * made by libxl.  This will not happen for frivolous reasons - only
+   * if the system, or the Xen components of it, are badly broken.
+   *
+   * msg and errnoval will describe the action that libxl was trying
+   * to do, and type specifies the type of libxl events which may be
+   * missing.  type may be 0 in which case events of all types may be
+   * missing.
+   *
+   * disaster may be NULL.  If it is, or if _register_callbacks has
+   * not been called, errors of this kind are fatal to the entire
+   * application: libxl will print messages to its logs and to stderr
+   * and call exit(-1).
+   *
+   * If disaster returns, it may be the case that some or all future
+   * libxl calls will return errors; likewise it may be the case that
+   * no more events (of the specified type, if applicable) can be
+   * produced.  An application which supplies a disaster function
+   * should normally react either by exiting, or by (when it has
+   * returned to its main event loop) shutting down libxl with
+   * libxl_ctx_free and perhaps trying to restart it with
+   * libxl_ctx_init.
+   *
+   * In any case before calling disaster, libxl will have logged a
+   * message with level XTL_CRITICAL.
+   *
+   * Reentrancy: it IS permitted to call libxl from within
+   * event_occurs.  It is NOT permitted to call libxl from within
+   * disaster.
+   *
+   * libxl_event_register_callbacks may be called as many times, with
+   * different parameters, as the application likes; the most recent
+   * call determines the libxl behaviour.  However it is NOT safe to
+   * call _register_callbacks concurrently with, or reentrantly from,
+   * any other libxl function.
+   *
+   * Calls to _register_callbacks do not affect events which have
+   * already occurred.
+   */
+
+
+/*
+ * Events are only generated if they have been requested.
+ * The following functions request the generation of specific events.
+ *
+ * Each set of functions for controlling event generation has this form:
+ *
+ *   typedef struct libxl__evgen_FOO libxl__evgen_FOO;
+ *   int libxl_evenable_FOO(libxl_ctx *ctx, FURTHER PARAMETERS,
+ *                          libxl_ev_user user, libxl__evgen_FOO **evgen_out);
+ *   void libxl_evdisable_FOO(libxl_ctx *ctx, libxl__evgen_FOO *evgen);
+ *
+ * The evenable function arranges that the events (as described in the
+ * doc comment for the individual function) will start to be generated
+ * by libxl.  On success, *evgen_out is set to a non-null pointer to
+ * an opaque struct.
+ *
+ * The user value is returned in the generated events and may be
+ * used by the caller for whatever it likes.  The type ev_user is
+ * guaranteed to be an unsigned integer type which is at least
+ * as big as uint64_t and is also guaranteed to be big enough to
+ * contain any intptr_t value.
+ *
+ * If it becomes desirable to stop generation of the relevant events,
+ * or to reclaim the resources in libxl associated with the evgen
+ * structure, the same evgen value should be passed to the evdisable
+ * function.  However, note that events which occurred prior to the
+ * evdisable call may still be returned.
+ *
+ * The caller may enable identical events more than once.  If they do
+ * so, each actual occurrence will generate several events to be
+ * returned by libxl_event_check, with the appropriate user value(s).
+ * Aside from this, each occurrence of each event is returned by
+ * libxl_event_check exactly once.
+ *
+ * An evgen is associated with the libxl_ctx used for its creation.
+ * After libxl_ctx_free, all corresponding evgen handles become
+ * invalid and must no longer be passed to evdisable.
+ *
+ * Events enabled with evenable prior to a fork and libxl_ctx_postfork
+ * are no longer generated after the fork/postfork; however the evgen
+ * structures are still valid and must be passed to evdisable if the
+ * memory they use should not be leaked.
+ *
+ * Applications should ensure that they eventually retrieve every
+ * event using libxl_event_check or libxl_event_wait, since events
+ * which occur but are not retreived by the application will be queued
+ * inside libxl indefinitely.  libxl_event_check/_wait may be O(n)
+ * where n is the number of queued events which do not match the
+ * criteria specified in the arguments to check/wait.
+ */
+
+typedef struct libxl__evgen_domain_death libxl_evgen_domain_death;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                         libxl_ev_user, libxl_evgen_domain_death **evgen_out);
+void libxl_evdisable_domain_death(libxl_ctx *ctx, libxl_evgen_domain_death*);
+  /* Arranges for the generation of DOMAIN_SHUTDOWN and DOMAIN_DESTROY
+   * events.  A domain which is destroyed before it shuts down
+   * may generate only a DESTROY event.
+   */
+
+typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
+                        libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject*);
+  /* Arranges for the generation of DISK_EJECT events.  A copy of the
+   * string *vdev will be made for libxl's internal use, and a pointer
+   * to this (or some other) copy will be returned as the vdev
+   * member of event.u.
+   */
+
 
 /*======================================================================*/
 
@@ -36,10 +208,10 @@
  *      poll();
  *      libxl_osevent_afterpoll(...);
  *      for (;;) {
- *        r=libxl_event_check(...);
- *        if (r==LIBXL_NOT_READY) break;
- *        if (r) handle failure;
- *        do something with the event;
+ *          r = libxl_event_check(...);
+ *          if (r==LIBXL_NOT_READY) break;
+ *          if (r) goto error_out;
+ *          do something with the event;
  *      }
  *   }
  *
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index a2e5820..314ae0d 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -74,6 +74,12 @@ void libxl__free_all(libxl__gc *gc)
     free(gc->alloc_ptrs);
     gc->alloc_ptrs = 0;
     gc->alloc_maxsize = 0;
+
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &gc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&gc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3e461fa..23f9f0e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -154,11 +154,44 @@ typedef struct libxl__ev_watch_slot {
     
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
+
+/*
+ * evgen structures, which are the state we use for generating
+ * events for the caller.
+ *
+ * In general in each case there's an internal and an external
+ * version of the _evdisable_FOO function; the internal one is
+ * used during cleanup.
+ */
+
+struct libxl__evgen_domain_death {
+    uint32_t domid;
+    unsigned shutdown_reported:1, death_reported:1;
+    LIBXL_TAILQ_ENTRY(libxl_evgen_domain_death) entry;
+        /* on list .death_reported ? CTX->death_list : CTX->death_reported */
+    libxl_ev_user user;
+};
+_hidden void
+libxl__evdisable_domain_death(libxl__gc*, libxl_evgen_domain_death*);
+
+struct libxl__evgen_disk_eject {
+    libxl__ev_xswatch watch;
+    uint32_t domid;
+    libxl_ev_user user;
+    char *vdev;
+};
+_hidden void
+libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
+
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    const libxl_event_hooks *event_hooks;
+    void *event_hooks_user;
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
        *
@@ -171,10 +204,15 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    LIBXL_TAILQ_HEAD(, libxl_event) occurred;
+
     int osevent_in_hook;
     const libxl_osevent_hooks *osevent_hooks;
     void *osevent_user;
 
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
     int fd_beforepolled_allocd, fd_beforepolled_used;
     libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -186,6 +224,11 @@ struct libxl__ctx {
     uint32_t watch_counter; /* helps disambiguate slot reuse */
     libxl__ev_fd watch_efd;
 
+    LIBXL_TAILQ_HEAD(libxl__evgen_domain_death_list, libxl_evgen_domain_death)
+        death_list /* sorted by domid */,
+        death_reported;
+    libxl__ev_xswatch death_watch;
+    
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -221,6 +264,7 @@ struct libxl__gc {
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
+    LIBXL_TAILQ_HEAD(, libxl_event) occurred_for_callback;
 };
 
 #define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
@@ -243,7 +287,9 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
 _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
-/* if this is the outermost libxl callframe then free all pointers in @gc */
+/* if this is the outermost libxl callframe then free all pointers in @gc
+ *  and report all occurred events via callback, if applicable.
+ * May reenters the application so must not be called with ctx locked. */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
 _hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
@@ -393,6 +439,25 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 
+/*
+ * Other event-handling support provided by the libxl event core to
+ * the rest of libxl.
+ */
+
+_hidden void libxl__event_occurred(libxl__gc*, libxl_event *event);
+  /* Arranges to notify the application that the event has occurred.
+   * event should be suitable for passing to libxl_event_free. */
+
+_hidden libxl_event *libxl__event_new(libxl__gc*, libxl_event_type,
+                                      uint32_t domid);
+  /* Convenience function.
+   * Allocates a new libxl_event, fills in domid and type.
+   * If allocation fails, calls _disaster, and returns NULL. */
+
+#define NEW_EVENT(gc, type, domid)                              \
+    libxl__event_new((gc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
 _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
                                    libxl_event_type type /* may be 0 */,
                                    const char *file, int line);
@@ -404,6 +469,9 @@ _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
    * libxl__ev_FOO_callback or an application event), but are
    * prevented from doing so due to eg lack of memory.
    *
+   * See the "disaster" member of libxl_event_hooks and associated
+   * comment in libxl_event.h.
+   *
    * NB that this function may return and the caller isn't supposed to
    * then crash, although it may fail (and henceforth leave things in
    * a state where many or all calls fail).
@@ -884,7 +952,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  */
 
 #define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
-#define GC_FREE       libxl__free_all(gc)
+#define GC_FREE       libxl__free_all(gc) /* MUST NOT CALL WITH CTX LOCKED */
 #define CTX           libxl__gc_owner(gc)
 
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 2299908..0e4e12f 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -75,11 +75,6 @@ libxl_action_on_shutdown = Enumeration("action_on_shutdown", [
     (6, "COREDUMP_RESTART"),
     ])
 
-libxl_event_type = Enumeration("event_type", [
-    (1, "DOMAIN_DEATH"),
-    (2, "DISK_EJECT"),
-    ])
-
 libxl_button = Enumeration("button", [
     (1, "POWER"),
     (2, "SLEEP"),
@@ -374,3 +369,33 @@ libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
+
+libxl_event_type = Enumeration("event_type", [
+    (1, "DOMAIN_SHUTDOWN"),
+    (2, "DOMAIN_DESTROY"),
+    (3, "DISK_EJECT"),
+    ])
+
+libxl_ev_user = Number("libxl_ev_user")
+
+libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, c_only=True)
+
+libxl_event = Struct("event",[
+    ("link",     libxl_ev_link,0,
+     "for use by libxl; caller may use this once the event has been"
+     " returned by libxl_event_{check,wait}"),
+    ("domid",    libxl_domid),
+    ("domuuid",  libxl_uuid),
+    ("for_user", libxl_ev_user),
+    ("type",     libxl_event_type),
+    ("u", KeyedUnion(None, libxl_event_type, "type",
+          [("domain_shutdown", Struct(None, [
+                                             ("shutdown_reason", uint8),
+                                      ])),
+           ("domain_destroy", Struct(None, [])),
+           ("disk_eject", Struct(None, [
+                                        ("vdev", string),
+                                        ("disk", libxl_device_disk),
+                                 ])),
+           ]))])
+
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 080aa2b..b9ce2ec 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1142,14 +1142,16 @@ skip_vfb:
     xlu_cfg_destroy(config);
 }
 
-/* Returns 1 if domain should be restarted, 2 if domain should be renamed then restarted  */
-static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                               libxl_domain_config *d_config, libxl_dominfo *info)
+/* Returns 1 if domain should be restarted,
+ * 2 if domain should be renamed then restarted, or 0 */
+static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
+                               libxl_event *event,
+                               libxl_domain_config *d_config)
 {
     int restart = 0;
     libxl_action_on_shutdown action;
 
-    switch (info->shutdown_reason) {
+    switch (event->u.domain_shutdown.shutdown_reason) {
     case SHUTDOWN_poweroff:
         action = d_config->on_poweroff;
         break;
@@ -1166,11 +1168,14 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *even
         action = d_config->on_watchdog;
         break;
     default:
-        LOG("Unknown shutdown reason code %d. Destroying domain.", info->shutdown_reason);
+        LOG("Unknown shutdown reason code %d. Destroying domain.",
+            event->u.domain_shutdown.shutdown_reason);
         action = LIBXL_ACTION_ON_SHUTDOWN_DESTROY;
     }
 
-    LOG("Action for shutdown reason code %d is %s", info->shutdown_reason, action_on_shutdown_names[action]);
+    LOG("Action for shutdown reason code %d is %s",
+        event->u.domain_shutdown.shutdown_reason,
+        action_on_shutdown_names[action]);
 
     if (action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY || action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART) {
         char *corefile;
@@ -1235,7 +1240,7 @@ static void replace_string(char **str, const char *val)
 
 
 static int preserve_domain(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                           libxl_domain_config *d_config, libxl_dominfo *info)
+                           libxl_domain_config *d_config)
 {
     time_t now;
     struct tm tm;
@@ -1347,6 +1352,24 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     _exit(1);
 }
 
+static int domain_wait_event(libxl_event **event_r) {
+    int ret;
+    for (;;) {
+        ret = libxl_event_wait(ctx, event_r, LIBXL_EVENTMASK_ALL, 0,0);
+        if (ret) {
+            LOG("Domain %d, failed to get event, quitting (rc=%d)", domid, ret);
+            return ret;
+        }
+        if ((*event_r)->domid != domid) {
+            LOG("INTERNAL PROBLEM - ignoring unexpected event for"
+                " domain %d (expected %d)", (*event_r)->domid, domid);
+            libxl_event_free(ctx, *event_r);
+            continue;
+        }
+        return ret;
+    }
+}
+
 static int create_domain(struct domain_create *dom_info)
 {
     libxl_domain_config d_config;
@@ -1360,10 +1383,11 @@ static int create_domain(struct domain_create *dom_info)
     const char *restore_file = dom_info->restore_file;
     int migrate_fd = dom_info->migrate_fd;
 
-    int fd, i;
+    int i;
     int need_daemon = daemonize;
     int ret, rc;
-    libxl_waiter *w1 = NULL, *w2 = NULL;
+    libxl_evgen_domain_death *deathw = NULL;
+    libxl_evgen_disk_eject **diskws = NULL; /* one per disk */
     void *config_data = 0;
     int config_len = 0;
     int restore_fd = -1;
@@ -1611,92 +1635,104 @@ start:
     }
     LOG("Waiting for domain %s (domid %d) to die [pid %ld]",
         d_config.c_info.name, domid, (long)getpid());
-    w1 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter) * d_config.num_disks);
-    w2 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter));
-    libxl_wait_for_disk_ejects(ctx, domid, d_config.disks, d_config.num_disks, w1);
-    libxl_wait_for_domain_death(ctx, domid, w2);
-    libxl_get_wait_fd(ctx, &fd);
-    while (1) {
-        int ret;
-        fd_set rfds;
-        libxl_dominfo info;
-        libxl_event event;
-        libxl_device_disk disk;
 
-        FD_ZERO(&rfds);
-        FD_SET(fd, &rfds);
+    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+    if (ret) goto error_out;
 
-        ret = select(fd + 1, &rfds, NULL, NULL, NULL);
-        if (!ret)
-            continue;
-        libxl_get_event(ctx, &event);
-        switch (event.type) {
-            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
-                ret = libxl_event_get_domain_death_info(ctx, domid, &event, &info);
-
-                if (ret < 0) {
-                    libxl_free_event(&event);
-                    continue;
+    if (!diskws) {
+        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
+        for (i = 0; i < d_config.num_disks; i++)
+            diskws[i] = NULL;
+    }
+    for (i = 0; i < d_config.num_disks; i++) {
+        ret = libxl_evenable_disk_eject(ctx, domid, d_config.disks[i].vdev,
+                                        0, &diskws[i]);
+        if (ret) goto error_out;
+    }
+    while (1) {
+        libxl_event *event;
+        ret = domain_wait_event(&event);
+        if (ret) goto error_out;
+
+        switch (event->type) {
+
+        case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+            LOG("Domain %d has shut down, reason code %d 0x%x", domid,
+                event->u.domain_shutdown.shutdown_reason,
+                event->u.domain_shutdown.shutdown_reason);
+            switch (handle_domain_death(ctx, domid, event, &d_config)) {
+            case 2:
+                if (!preserve_domain(ctx, domid, event, &d_config)) {
+                    /* If we fail then exit leaving the old domain in place. */
+                    ret = -1;
+                    goto out;
                 }
 
-                LOG("Domain %d is dead", domid);
-
-                if (ret) {
-                    switch (handle_domain_death(ctx, domid, &event, &d_config, &info)) {
-                    case 2:
-                        if (!preserve_domain(ctx, domid, &event, &d_config, &info)) {
-                            /* If we fail then exit leaving the old domain in place. */
-                            ret = -1;
-                            goto out;
-                        }
-
-                        /* Otherwise fall through and restart. */
-                    case 1:
-
-                        for (i = 0; i < d_config.num_disks; i++)
-                            libxl_free_waiter(&w1[i]);
-                        libxl_free_waiter(w2);
-                        free(w1);
-                        free(w2);
-
-                        /*
-                         * Do not attempt to reconnect if we come round again due to a
-                         * guest reboot -- the stdin/out will be disconnected by then.
-                         */
-                        dom_info->console_autoconnect = 0;
-
-                        /* Some settings only make sense on first boot. */
-                        paused = 0;
-                        if (common_domname
-                            && strcmp(d_config.c_info.name, common_domname)) {
-                            d_config.c_info.name = strdup(common_domname);
-                        }
-
-                        /*
-                         * XXX FIXME: If this sleep is not there then domain
-                         * re-creation fails sometimes.
-                         */
-                        LOG("Done. Rebooting now");
-                        sleep(2);
-                        goto start;
-                    case 0:
-                        LOG("Done. Exiting now");
-                        ret = 0;
-                        goto out;
-                    }
-                } else {
-                    LOG("Unable to get domain death info, quitting");
-                    goto out;
+                /* Otherwise fall through and restart. */
+            case 1:
+                libxl_event_free(ctx, event);
+                libxl_evdisable_domain_death(ctx, deathw);
+                deathw = NULL;
+                for (i = 0; i < d_config.num_disks; i++) {
+                    libxl_evdisable_disk_eject(ctx, diskws[i]);
+                    diskws[i] = NULL;
                 }
-                break;
-            case LIBXL_EVENT_TYPE_DISK_EJECT:
-                if (libxl_event_get_disk_eject_info(ctx, domid, &event, &disk)) {
-                    libxl_cdrom_insert(ctx, domid, &disk);
-                    libxl_device_disk_dispose(&disk);
+                /* discard any other events which may have been generated */
+                while (!(ret = libxl_event_check(ctx, &event,
+                                                 LIBXL_EVENTMASK_ALL, 0,0))) {
+                    libxl_event_free(ctx, event);
                 }
-                break;
+                if (ret != ERROR_NOT_READY) {
+                    LOG("warning, libxl_event_check (cleanup) failed (rc=%d)",
+                        ret);
+                }
+
+                /*
+                 * Do not attempt to reconnect if we come round again due to a
+                 * guest reboot -- the stdin/out will be disconnected by then.
+                 */
+                dom_info->console_autoconnect = 0;
+
+                /* Some settings only make sense on first boot. */
+                paused = 0;
+                if (common_domname
+                    && strcmp(d_config.c_info.name, common_domname)) {
+                    d_config.c_info.name = strdup(common_domname);
+                }
+
+                /*
+                 * XXX FIXME: If this sleep is not there then domain
+                 * re-creation fails sometimes.
+                 */
+                LOG("Done. Rebooting now");
+                sleep(2);
+                goto start;
+
+            case 0:
+                LOG("Done. Exiting now");
+                ret = 0;
+                goto out;
+
+            default:
+                abort();
+            }
+
+        case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+            LOG("Domain %d has been destroyed.", domid);
+            ret = 0;
+            goto out;
+
+        case LIBXL_EVENT_TYPE_DISK_EJECT:
+            /* XXX what is this for? */
+            libxl_cdrom_insert(ctx, domid, &event->u.disk_eject.disk);
+            libxl_device_disk_dispose(&event->u.disk_eject.disk);
+            break;
+
+        default:
+            LOG("warning, got unexpected event type %d", event->type);
         }
-        libxl_free_event(&event);
+
+        libxl_event_free(ctx, event);
     }
 
 error_out:
@@ -2179,43 +2215,46 @@ static void destroy_domain(const char *p)
 static void shutdown_domain(const char *p, int wait)
 {
     int rc;
+    libxl_event *event;
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid, 0);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
-        libxl_waiter waiter;
-        int fd;
-
-        libxl_wait_for_domain_death(ctx, domid, &waiter);
+        libxl_evgen_domain_death *deathw;
 
-        libxl_get_wait_fd(ctx, &fd);
-
-        while (wait) {
-            fd_set rfds;
-            libxl_event event;
-            libxl_dominfo info;
+        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+        if (rc) {
+            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
+            exit(-1);
+        }
 
-            FD_ZERO(&rfds);
-            FD_SET(fd, &rfds);
+        for (;;) {
+            rc = domain_wait_event(&event);
+            if (rc) exit(-1);
 
-            if (!select(fd + 1, &rfds, NULL, NULL, NULL))
-                continue;
+            switch (event->type) {
 
-            libxl_get_event(ctx, &event);
+            case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+                LOG("Domain %d has been destroyed", domid);
+                goto done;
 
-            if (event.type == LIBXL_EVENT_TYPE_DOMAIN_DEATH) {
-                if (libxl_event_get_domain_death_info(ctx, domid, &event, &info) < 0)
-                    continue;
+            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+                LOG("Domain %d has been shut down, reason code %d %x", domid,
+                    event->u.domain_shutdown.shutdown_reason,
+                    event->u.domain_shutdown.shutdown_reason);
+                goto done;
 
-                LOG("Domain %d is dead", domid);
-                wait = 0;
+            default:
+                LOG("Unexpected event type %d", event->type);
+                break;
             }
-
-            libxl_free_event(&event);
+            libxl_event_free(ctx, event);
         }
-        libxl_free_waiter(&waiter);
+    done:
+        libxl_event_free(ctx, event);
+        libxl_evdisable_domain_death(ctx, deathw);
     }
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZH-0003jJ-MS; Mon, 28 Nov 2011 17:00:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZC-0003eL-AJ
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29242 invoked from network); 28 Nov 2011 16:59:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169241"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055y-NA; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000eA-LZ;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:40 +0000
Message-ID: <1322499580-2322-14-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/13] libxl: New event generation API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Replace the existing API for retrieving high-level events (events
about domains, etc.) from libxl with a new one.

This changes the definition and semantics of the `libxl_event'
structure, and replaces the calls for obtaining information about
domain death and disk eject events.

This is an incompatible change, sorry.  The alternative was to try to
provide both the previous horrid API and the new one, and would also
involve never using the name `libxl_event' for the new interface.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |  306 +++++++++++++++++++++++++++++------------
 tools/libxl/libxl.h          |   55 ++-------
 tools/libxl/libxl_event.c    |  187 +++++++++++++++++++++++---
 tools/libxl/libxl_event.h    |  180 ++++++++++++++++++++++++-
 tools/libxl/libxl_internal.c |    6 +
 tools/libxl/libxl_internal.h |   72 ++++++++++-
 tools/libxl/libxl_types.idl  |   35 ++++-
 tools/libxl/xl_cmdimpl.c     |  261 +++++++++++++++++++++---------------
 8 files changed, 828 insertions(+), 274 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b977f7c..95925ef 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -62,6 +62,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     ctx->osevent_hooks = 0;
 
+    ctx->fd_polls = 0;
     ctx->fd_beforepolled = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -70,6 +71,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_SLIST_INIT(&ctx->watch_freeslots);
     libxl__ev_fd_init(&ctx->watch_efd);
 
+    LIBXL_TAILQ_INIT(&ctx->death_list);
+    libxl__ev_xswatch_init(&ctx->death_watch);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -97,6 +101,13 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return 0;
 }
 
+static void free_disable_deaths(libxl__gc *gc,
+                                struct libxl__evgen_domain_death_list *l) {
+    libxl_evgen_domain_death *death;
+    while ((death = LIBXL_TAILQ_FIRST(l)))
+        libxl__evdisable_domain_death(gc, death);
+}
+
 int libxl_ctx_free(libxl_ctx *ctx)
 {
     int i;
@@ -104,6 +115,9 @@ int libxl_ctx_free(libxl_ctx *ctx)
 
     if (!ctx) return 0;
 
+    free_disable_deaths(gc, &CTX->death_list);
+    free_disable_deaths(gc, &CTX->death_reported);
+
     for (i = 0; i < ctx->watch_nslots; i++)
         assert(!libxl__watch_slot_contents(gc, i));
     libxl__ev_fd_deregister(gc, &ctx->watch_efd);
@@ -115,6 +129,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
 
+    free(ctx->fd_polls);
     free(ctx->fd_beforepolled);
     free(ctx->watch_slots);
 
@@ -614,117 +629,175 @@ int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid, int req)
     return 0;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_domain_death *evg;
+    uint32_t domid;
+    int rc;
 
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter)
-{
-    waiter->path = strdup("@releaseDomain");
-    if (asprintf(&(waiter->token), "%d", LIBXL_EVENT_TYPE_DOMAIN_DEATH) < 0)
-        return -1;
-    if (!xs_watch(ctx->xsh, waiter->path, waiter->token))
-        return -1;
-    return 0;
-}
+    CTX_LOCK;
 
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
-{
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    int i, rc = -1;
-    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+    evg = LIBXL_TAILQ_FIRST(&CTX->death_list);
+    if (!evg) goto out;
 
-    if (!domid)
-        domid = guest_domid;
+    domid = evg->domid;
 
-    for (i = 0; i < num_disks; i++) {
-        if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
-                     libxl__xs_get_dompath(&gc, domid),
-                     libxl__device_disk_dev_number(disks[i].vdev,
-                                                   NULL, NULL)) < 0)
-            goto out;
-        if (asprintf(&(waiter[i].token), "%d", LIBXL_EVENT_TYPE_DISK_EJECT) < 0)
+    for (;;) {
+        int nentries = LIBXL_TAILQ_NEXT(evg, entry) ? 200 : 1;
+        xc_domaininfo_t domaininfos[nentries];
+        const xc_domaininfo_t *got = domaininfos, *gotend;
+
+        rc = xc_domain_getinfolist(CTX->xch, domid, nentries, domaininfos);
+        if (rc == -1) {
+            LIBXL__EVENT_DISASTER(gc, "xc_domain_getinfolist failed while"
+                                  " processing @releaseDomain watch event",
+                                  errno, 0);
             goto out;
-        xs_watch(ctx->xsh, waiter[i].path, waiter[i].token);
+        }
+        gotend = &domaininfos[rc];
+
+        for (;;) {
+            if (!evg)
+                goto all_reported;
+
+            if (!rc || got->domain > evg->domid) {
+                /* ie, the list doesn't contain evg->domid any more so
+                 * the domain has been destroyed */
+                libxl_evgen_domain_death *evg_next;
+
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(gc, ev);
+
+                evg->death_reported = 1;
+                evg_next = LIBXL_TAILQ_NEXT(evg, entry);
+                LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+                LIBXL_TAILQ_INSERT_HEAD(&CTX->death_reported, evg, entry);
+                evg = evg_next;
+
+                continue;
+            }
+            
+            if (got == gotend)
+                break;
+
+            if (got->domain < evg->domid) {
+                got++;
+                continue;
+            }
+
+            assert(evg->domid == got->domain);
+
+            if (!evg->shutdown_reported &&
+                (got->flags & XEN_DOMINF_shutdown)) {
+                libxl_event *ev = NEW_EVENT(gc, DOMAIN_SHUTDOWN, got->domain);
+                if (!ev) goto out;
+                
+                ev->u.domain_shutdown.shutdown_reason =
+                    (got->flags >> XEN_DOMINF_shutdownshift) &
+                    XEN_DOMINF_shutdownmask;
+                libxl__event_occurred(gc, ev);
+
+                evg->shutdown_reported = 1;
+            }
+            evg = LIBXL_TAILQ_NEXT(evg, entry);
+        }
+
+        assert(rc); /* rc==0 results in us eating all evgs and quitting */
+        domid = gotend[-1].domain;
     }
-    rc = 0;
-out:
-    libxl__free_all(&gc);
-    return rc;
+ all_reported:
+ out:
+
+    CTX_UNLOCK;
 }
 
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event)
-{
-    unsigned int num;
-    char **events = xs_read_watch(ctx->xsh, &num);
-    if (num != 2) {
-        free(events);
-        return ERROR_FAIL;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
+    GC_INIT(ctx);
+    libxl_evgen_domain_death *evg, *evg_search;
+    int rc;
+    
+    CTX_LOCK;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->domid = domid;
+    evg->user = user;
+
+    LIBXL_TAILQ_INSERT_SORTED(&ctx->death_list, entry, evg, evg_search, ,
+                              evg->domid > evg_search->domid);
+
+    if (!libxl__ev_xswatch_isregistered(&ctx->death_watch)) {
+        rc = libxl__ev_xswatch_register(gc, &ctx->death_watch,
+                        domain_death_xswatch_callback, "@releaseDomain");
+        if (rc) { libxl__evdisable_domain_death(gc, evg); goto out; }
     }
-    event->path = strdup(events[XS_WATCH_PATH]);
-    event->token = strdup(events[XS_WATCH_TOKEN]);
-    event->type = atoi(event->token);
-    free(events);
-    return 0;
-}
 
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter)
-{
-    if (!xs_unwatch(ctx->xsh, waiter->path, waiter->token))
-        return ERROR_FAIL;
-    else
-        return 0;
-}
+    rc = 0;
 
-int libxl_free_event(libxl_event *event)
-{
-    free(event->path);
-    free(event->token);
-    return 0;
-}
+ out:
+    CTX_UNLOCK;
+    return rc;
+};
 
-int libxl_free_waiter(libxl_waiter *waiter)
-{
-    free(waiter->path);
-    free(waiter->token);
-    return 0;
-}
+void libxl__evdisable_domain_death(libxl__gc *gc,
+                                   libxl_evgen_domain_death *evg) {
+    CTX_LOCK;
 
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info)
-{
-    if (libxl_domain_info(ctx, info, domid) < 0)
-        return 0;
+    if (!evg->death_reported)
+        LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+    else
+        LIBXL_TAILQ_REMOVE(&CTX->death_reported, evg, entry);
 
-    if (info->running || (!info->shutdown && !info->dying))
-        return ERROR_INVAL;
+    free(evg);
+
+    if (!LIBXL_TAILQ_FIRST(&CTX->death_list) &&
+        libxl__ev_xswatch_isregistered(&CTX->death_watch))
+        libxl__ev_xswatch_deregister(gc, &CTX->death_watch);
 
-    return 1;
+    CTX_UNLOCK;
 }
 
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk)
-{
-    libxl__gc gc = LIBXL_INIT_GC(ctx);
-    char *path;
+void libxl_evdisable_domain_death(libxl_ctx *ctx,
+                                  libxl_evgen_domain_death *evg) {
+    GC_INIT(ctx);
+    libxl__evdisable_domain_death(gc, evg);
+    GC_FREE;
+}
+
+static void disk_eject_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch *watch,
+                                        const char *wpath, const char *epath) {
+    libxl_evgen_domain_death *evg = (void*)watch;
+    int rc;
     char *backend;
     char *value;
     char backend_type[BACKEND_STRING_SIZE+1];
 
-    value = libxl__xs_read(&gc, XBT_NULL, event->path);
+    value = libxl__xs_read(gc, XBT_NULL, wpath);
 
-    if (!value || strcmp(value,  "eject")) {
-        libxl__free_all(&gc);
-        return 0;
+    if (!value || strcmp(value,  "eject"))
+        return;
+
+    rc = libxl__xs_write(gc, XBT_NULL, wpath, "");
+    if (rc) {
+        LIBXL__EVENT_DISASTER(gc, "xs_write failed acknowledging eject",
+                              errno, LIBXL_EVENT_TYPE_DISK_EJECT);
+        return;
     }
 
-    path = strdup(event->path);
-    path[strlen(path) - 6] = '\0';
-    backend = libxl__xs_read(&gc, XBT_NULL, libxl__sprintf(&gc, "%s/backend", path));
+    libxl_event *ev = NEW_EVENT(gc, DISK_EJECT, evg->domid);
+    libxl_device_disk *disk = &ev->u.disk_eject.disk;
+    
+    backend = libxl__xs_read(gc, XBT_NULL,
+                             libxl__sprintf(gc, "%.*s/backend",
+                                            (int)strlen(wpath)-6, wpath));
 
     sscanf(backend,
-            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE) "[a-z]/%*d/%*d",
-            &disk->backend_domid, backend_type);
+            "/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE)
+           "[a-z]/%*d/%*d",
+           &disk->backend_domid, backend_type);
     if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) {
         disk->backend = LIBXL_DISK_BACKEND_TAP;
     } else if (!strcmp(backend_type, "qdisk")) {
@@ -733,19 +806,72 @@ int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event
         disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
     }
 
-    disk->pdev_path = strdup("");
+    disk->pdev_path = strdup(""); /* xxx fixme malloc failure */
     disk->format = LIBXL_DISK_FORMAT_EMPTY;
     /* this value is returned to the user: do not free right away */
-    disk->vdev = xs_read(ctx->xsh, XBT_NULL, libxl__sprintf(&gc, "%s/dev", backend), NULL);
+    disk->vdev = xs_read(CTX->xsh, XBT_NULL,
+                         libxl__sprintf(gc, "%s/dev", backend), NULL);
     disk->removable = 1;
     disk->readwrite = 0;
     disk->is_cdrom = 1;
 
-    free(path);
-    libxl__free_all(&gc);
-    return 1;
+    libxl__event_occurred(gc, ev);
 }
 
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t guest_domid,
+                              const char *vdev, libxl_ev_user user,
+                              libxl_evgen_disk_eject **evgen_out) {
+    GC_INIT(ctx);
+    int rc;
+    char *path;
+    libxl_evgen_disk_eject *evg = NULL;
+
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->user = user;
+
+    evg->vdev = strdup(vdev);
+    if (!evg->vdev) { rc = ERROR_NOMEM; goto out; }
+
+    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+    evg->domid = domid;
+
+    if (!domid)
+        domid = guest_domid;
+
+    path = libxl__sprintf(gc, "%s/device/vbd/%d/eject",
+                 libxl__xs_get_dompath(gc, domid),
+                 libxl__device_disk_dev_number(vdev, NULL, NULL));
+    if (!path) { rc = ERROR_NOMEM; goto out; }
+
+    rc = libxl__ev_xswatch_register(gc, &evg->watch,
+                                    disk_eject_xswatch_callback, path);
+    if (rc) goto out;
+
+    GC_FREE;
+    return 0;
+
+ out:
+    if (evg)
+        libxl__evdisable_disk_eject(gc, evg);
+    GC_FREE;
+    return rc;
+}
+
+void libxl__evdisable_disk_eject(libxl__gc *gc, libxl_evgen_disk_eject *evg) {
+    if (libxl__ev_xswatch_isregistered(&evg->watch))
+        libxl__ev_xswatch_deregister(gc, &evg->watch);
+
+    free(evg->vdev);
+    free(evg);
+}
+
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject *evg) {
+    GC_INIT(ctx);
+    libxl__evdisable_disk_eject(gc, evg);
+    GC_FREE;
+}    
+
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force)
 {
     libxl__gc gc = LIBXL_INIT_GC(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 13baa1b..7b33e12 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -53,7 +53,10 @@
  *    A public function may be called from within libxl; the call
  *    context initialisation macros will make sure that the internal
  *    caller's context is reused (eg, so that the same xenstore
- *    transaction is used).
+ *    transaction is used).  But in-libxl callers of libxl public
+ *    functions should note that any libxl public function may cause
+ *    recursively reentry into libxl via the application's event
+ *    callback hook.
  *
  *    Public functions have names like libxl_foobar.
  *
@@ -152,6 +155,8 @@ void libxl_key_value_list_dispose(libxl_key_value_list *kvl);
 
 typedef uint32_t libxl_hwcap[8];
 
+typedef uint64_t libxl_ev_user;
+
 typedef struct {
     uint32_t size;          /* number of bytes in map */
     uint8_t *map;
@@ -200,6 +205,9 @@ typedef struct {
     int v;
 } libxl_enum_string_table;
 
+struct libxl_event;
+typedef LIBXL_TAILQ_ENTRY(struct libxl_event) libxl_ev_link;
+
 typedef struct libxl__ctx libxl_ctx;
 
 #include "_libxl_types.h"
@@ -298,51 +306,6 @@ int libxl_run_bootloader(libxl_ctx *ctx,
 
   /* 0 means ERROR_ENOMEM, which we have logged */
 
-/* events handling */
-
-typedef struct {
-    /* event type */
-    libxl_event_type type;
-    /* data for internal use of the library */
-    char *path;
-    char *token;
-} libxl_event;
-
-typedef struct {
-    char *path;
-    char *token;
-} libxl_waiter;
-
-
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd);
-/* waiter is allocated by the caller */
-int libxl_wait_for_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_waiter *waiter);
-/* waiter is a preallocated array of num_disks libxl_waiter elements */
-int libxl_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter);
-int libxl_get_event(libxl_ctx *ctx, libxl_event *event);
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter);
-int libxl_free_event(libxl_event *event);
-int libxl_free_waiter(libxl_waiter *waiter);
-
-/*
- * Returns:
- *  - 0 if the domain is dead but there is no cleanup to be done. e.g
- *    because someone else has already done it.
- *  - 1 if the domain is dead and there is cleanup to be done.
- *
- * Can return error if the domain exists and is still running.
- *
- * *info will contain valid domain state iff 1 is returned. In
- * particular if 1 is returned then info->shutdown_reason is
- * guaranteed to be valid since by definition the domain is
- * (shutdown||dying))
- */
-int libxl_event_get_domain_death_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_dominfo *info);
-
-/*
- * Returns true and fills *disk if the caller should eject the disk
- */
-int libxl_event_get_disk_eject_info(libxl_ctx *ctx, uint32_t domid, libxl_event *event, libxl_device_disk *disk);
 
 int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
                         const char *old_name, const char *new_name);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index b2377ea..5fb13b9 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -487,9 +487,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w) {
  * osevent poll
  */
 
-int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
-                             struct pollfd *fds, int *timeout_upd,
-                             struct timeval now) {
+static int beforepoll_unlocked(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now) {
     libxl__ev_fd *efd;
     int i;
 
@@ -500,9 +500,6 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
      * the fds array corresponds to a slot in fd_beforepolled.
      */
 
-    GC_INIT(ctx);
-    CTX_LOCK;
-
     if (*nfds_io) {
         /*
          * As an optimisation, we don't touch fd_beforepolled_used
@@ -574,16 +571,25 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
             *timeout_upd = our_timeout;
     }
 
-    CTX_UNLOCK;
-    GC_FREE;
     return rc;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
                              struct timeval now) {
-    int i;
+
     GC_INIT(ctx);
     CTX_LOCK;
+    int rc = beforepoll_unlocked(gc, nfds_io, fds, timeout_upd, now);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static void afterpoll_unlocked(libxl__gc *gc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now) {
+    int i;
 
     assert(nfds <= CTX->fd_beforepolled_used);
 
@@ -619,12 +625,17 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(gc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_unlocked(gc, nfds, fds, now);
     CTX_UNLOCK;
     GC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -682,11 +693,10 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
                type ? libxl_event_type_to_string(type) : "",
                type ? ")" : "");
 
-    /*
-     * FIXME: This should call the "disaster" hook supplied to
-     * libxl_event_register_callbacks, which will be introduced in the
-     * next patch.
-     */
+    if (CTX->event_hooks && CTX->event_hooks->disaster) {
+        CTX->event_hooks->disaster(CTX->event_hooks_user, type, msg, errnoval);
+        return;
+    }
 
     const char verybad[] =
         "DISASTER in event loop not handled by libxl application";
@@ -696,6 +706,151 @@ void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
 }
 
 /*
+ * Event retrieval etc.
+ */
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                  const libxl_event_hooks *hooks, void *user) {
+    ctx->event_hooks = hooks;
+    ctx->event_hooks_user = user;
+}
+
+void libxl__event_occurred(libxl__gc *gc, libxl_event *event) {
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__free_all will call the callback, just before exit
+         * from libxl.  This helps avoid reentrancy bugs: parts of
+         * libxl that call libxl__event_occurred do not have to worry
+         * that libxl might be reentered at that point. */
+        LIBXL_TAILQ_INSERT_TAIL(&gc->occurred_for_callback, event, link);
+        return;
+    } else {
+        LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+    }
+}
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event) {
+    libxl_event_dispose(event);
+    free(event);
+}
+
+libxl_event *libxl__event_new(libxl__gc *gc,
+                              libxl_event_type type, uint32_t domid) {
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(gc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_unlocked(libxl__gc *gc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user) {
+    libxl_event *ev;
+    int rc;
+
+    LIBXL_TAILQ_FOREACH(ev, &CTX->occurred, link) {
+        if (!(typemask & (1UL << ev->type)))
+            continue;
+
+        if (pred && !pred(ev, pred_user))
+            continue;
+
+        /* got one! */
+        LIBXL_TAILQ_REMOVE(&CTX->occurred, ev, link);
+        *event_r = ev;
+        rc = 0;
+        goto out;
+    }
+    rc = ERROR_NOT_READY;
+
+ out:
+    return rc;
+}
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *pred, void *pred_user) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *pred, void *pred_user) {
+    int rc;
+    struct timeval now;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_unlocked(gc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        int timeout;
+
+        for (;;) {
+            int nfds = CTX->fd_polls_allocd;
+            timeout = -1;
+            rc = beforepoll_unlocked(gc, &nfds, CTX->fd_polls, &timeout, now);
+            if (!rc) break;
+            if (rc != ERROR_BUFFERFULL) goto out;
+            
+            struct pollfd *newarray =
+                (nfds > INT_MAX / sizeof(struct pollfd) / 2) ? 0 :
+                realloc(CTX->fd_polls, sizeof(*newarray) * nfds);
+            
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+
+            CTX->fd_polls_allocd = nfds;
+        }
+
+        rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+        if (rc < 0) {
+            if (errno == EINTR) continue;
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno, "poll failed");
+            rc = ERROR_FAIL;
+            goto out;
+        }
+
+        rc = libxl__gettimeofday(gc, &now);
+        if (rc) goto out;
+
+        afterpoll_unlocked(gc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+        /* we unlock and free the gc each time we go through this loop,
+         * so that (a) we don't accumulate garbage and (b) any events
+         * which are to be dispatched by callback are actually delivered
+         * in a timely fashion.
+         */
+        CTX_UNLOCK;
+        libxl__free_all(gc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+/*
  * Local variables:
  * mode: C
  * c-basic-offset: 4
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 25efbdf..bbe1ed0 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,178 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ */
+
+#define LIBXL_EVENTMASK_ALL (~(unsigned long)0)
+
+typedef int libxl_event_predicate(const libxl_event*, void *user);
+  /* Return value is 0 if the event is unwanted or non-0 if it is.
+   * Predicates are not allowed to fail.
+   */
+
+int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
+                      unsigned long typemask,
+                      libxl_event_predicate *predicate, void *predicate_user);
+  /* Searches for an event, already-happened, which matches typemask
+   * and predicate.  predicate==0 matches any event.
+   * libxl_event_check returns the event, which must then later be
+   * freed by the caller using libxl_event_free.
+   *
+   * Returns ERROR_NOT_READY if no such event has happened.
+   */
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     unsigned long typemask,
+                     libxl_event_predicate *predicate, void *predicate_user);
+  /* Like libxl_event_check but blocks if no suitable events are
+   * available, until some are.  Uses libxl_osevent_beforepoll/
+   * _afterpoll so may be inefficient if very many domains are being
+   * handled by a single program.
+   */
+
+void libxl_event_free(libxl_ctx *ctx, libxl_event *event);
+
+
+/* Alternatively or additionally, the application may also use this: */
+
+typedef struct libxl_event_hooks {
+    uint64_t event_occurs_mask;
+    void (*event_occurs)(void *user, const libxl_event *event);
+    void (*disaster)(void *user, libxl_event_type type,
+                     const char *msg, int errnoval);
+} libxl_event_hooks;
+
+void libxl_event_register_callbacks(libxl_ctx *ctx,
+                                    const libxl_event_hooks *hooks, void *user);
+  /*
+   * Arranges that libxl will henceforth call event_occurs for any
+   * events whose type is set in event_occurs_mask, rather than
+   * queueing the event for retrieval by libxl_event_check/wait.
+   * Events whose bit is clear in mask are not affected.
+   *
+   * event becomes owned by the application and must be freed, either
+   * by event_occurs or later.
+   *
+   * event_occurs may be NULL if mask is 0.
+   *
+   * libxl_event_register_callback also provides a way for libxl to
+   * report to the application that there was a problem reporting
+   * events; this can occur due to lack of host memory during event
+   * handling, or other wholly unrecoverable errors from system calls
+   * made by libxl.  This will not happen for frivolous reasons - only
+   * if the system, or the Xen components of it, are badly broken.
+   *
+   * msg and errnoval will describe the action that libxl was trying
+   * to do, and type specifies the type of libxl events which may be
+   * missing.  type may be 0 in which case events of all types may be
+   * missing.
+   *
+   * disaster may be NULL.  If it is, or if _register_callbacks has
+   * not been called, errors of this kind are fatal to the entire
+   * application: libxl will print messages to its logs and to stderr
+   * and call exit(-1).
+   *
+   * If disaster returns, it may be the case that some or all future
+   * libxl calls will return errors; likewise it may be the case that
+   * no more events (of the specified type, if applicable) can be
+   * produced.  An application which supplies a disaster function
+   * should normally react either by exiting, or by (when it has
+   * returned to its main event loop) shutting down libxl with
+   * libxl_ctx_free and perhaps trying to restart it with
+   * libxl_ctx_init.
+   *
+   * In any case before calling disaster, libxl will have logged a
+   * message with level XTL_CRITICAL.
+   *
+   * Reentrancy: it IS permitted to call libxl from within
+   * event_occurs.  It is NOT permitted to call libxl from within
+   * disaster.
+   *
+   * libxl_event_register_callbacks may be called as many times, with
+   * different parameters, as the application likes; the most recent
+   * call determines the libxl behaviour.  However it is NOT safe to
+   * call _register_callbacks concurrently with, or reentrantly from,
+   * any other libxl function.
+   *
+   * Calls to _register_callbacks do not affect events which have
+   * already occurred.
+   */
+
+
+/*
+ * Events are only generated if they have been requested.
+ * The following functions request the generation of specific events.
+ *
+ * Each set of functions for controlling event generation has this form:
+ *
+ *   typedef struct libxl__evgen_FOO libxl__evgen_FOO;
+ *   int libxl_evenable_FOO(libxl_ctx *ctx, FURTHER PARAMETERS,
+ *                          libxl_ev_user user, libxl__evgen_FOO **evgen_out);
+ *   void libxl_evdisable_FOO(libxl_ctx *ctx, libxl__evgen_FOO *evgen);
+ *
+ * The evenable function arranges that the events (as described in the
+ * doc comment for the individual function) will start to be generated
+ * by libxl.  On success, *evgen_out is set to a non-null pointer to
+ * an opaque struct.
+ *
+ * The user value is returned in the generated events and may be
+ * used by the caller for whatever it likes.  The type ev_user is
+ * guaranteed to be an unsigned integer type which is at least
+ * as big as uint64_t and is also guaranteed to be big enough to
+ * contain any intptr_t value.
+ *
+ * If it becomes desirable to stop generation of the relevant events,
+ * or to reclaim the resources in libxl associated with the evgen
+ * structure, the same evgen value should be passed to the evdisable
+ * function.  However, note that events which occurred prior to the
+ * evdisable call may still be returned.
+ *
+ * The caller may enable identical events more than once.  If they do
+ * so, each actual occurrence will generate several events to be
+ * returned by libxl_event_check, with the appropriate user value(s).
+ * Aside from this, each occurrence of each event is returned by
+ * libxl_event_check exactly once.
+ *
+ * An evgen is associated with the libxl_ctx used for its creation.
+ * After libxl_ctx_free, all corresponding evgen handles become
+ * invalid and must no longer be passed to evdisable.
+ *
+ * Events enabled with evenable prior to a fork and libxl_ctx_postfork
+ * are no longer generated after the fork/postfork; however the evgen
+ * structures are still valid and must be passed to evdisable if the
+ * memory they use should not be leaked.
+ *
+ * Applications should ensure that they eventually retrieve every
+ * event using libxl_event_check or libxl_event_wait, since events
+ * which occur but are not retreived by the application will be queued
+ * inside libxl indefinitely.  libxl_event_check/_wait may be O(n)
+ * where n is the number of queued events which do not match the
+ * criteria specified in the arguments to check/wait.
+ */
+
+typedef struct libxl__evgen_domain_death libxl_evgen_domain_death;
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                         libxl_ev_user, libxl_evgen_domain_death **evgen_out);
+void libxl_evdisable_domain_death(libxl_ctx *ctx, libxl_evgen_domain_death*);
+  /* Arranges for the generation of DOMAIN_SHUTDOWN and DOMAIN_DESTROY
+   * events.  A domain which is destroyed before it shuts down
+   * may generate only a DESTROY event.
+   */
+
+typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
+int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char *vdev,
+                        libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
+void libxl_evdisable_disk_eject(libxl_ctx *ctx, libxl_evgen_disk_eject*);
+  /* Arranges for the generation of DISK_EJECT events.  A copy of the
+   * string *vdev will be made for libxl's internal use, and a pointer
+   * to this (or some other) copy will be returned as the vdev
+   * member of event.u.
+   */
+
 
 /*======================================================================*/
 
@@ -36,10 +208,10 @@
  *      poll();
  *      libxl_osevent_afterpoll(...);
  *      for (;;) {
- *        r=libxl_event_check(...);
- *        if (r==LIBXL_NOT_READY) break;
- *        if (r) handle failure;
- *        do something with the event;
+ *          r = libxl_event_check(...);
+ *          if (r==LIBXL_NOT_READY) break;
+ *          if (r) goto error_out;
+ *          do something with the event;
  *      }
  *   }
  *
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index a2e5820..314ae0d 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -74,6 +74,12 @@ void libxl__free_all(libxl__gc *gc)
     free(gc->alloc_ptrs);
     gc->alloc_ptrs = 0;
     gc->alloc_maxsize = 0;
+
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &gc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&gc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3e461fa..23f9f0e 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -154,11 +154,44 @@ typedef struct libxl__ev_watch_slot {
     
 libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
 
+
+/*
+ * evgen structures, which are the state we use for generating
+ * events for the caller.
+ *
+ * In general in each case there's an internal and an external
+ * version of the _evdisable_FOO function; the internal one is
+ * used during cleanup.
+ */
+
+struct libxl__evgen_domain_death {
+    uint32_t domid;
+    unsigned shutdown_reported:1, death_reported:1;
+    LIBXL_TAILQ_ENTRY(libxl_evgen_domain_death) entry;
+        /* on list .death_reported ? CTX->death_list : CTX->death_reported */
+    libxl_ev_user user;
+};
+_hidden void
+libxl__evdisable_domain_death(libxl__gc*, libxl_evgen_domain_death*);
+
+struct libxl__evgen_disk_eject {
+    libxl__ev_xswatch watch;
+    uint32_t domid;
+    libxl_ev_user user;
+    char *vdev;
+};
+_hidden void
+libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
+
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    const libxl_event_hooks *event_hooks;
+    void *event_hooks_user;
+
     pthread_mutex_t lock; /* protects data structures hanging off the ctx */
       /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
        *
@@ -171,10 +204,15 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    LIBXL_TAILQ_HEAD(, libxl_event) occurred;
+
     int osevent_in_hook;
     const libxl_osevent_hooks *osevent_hooks;
     void *osevent_user;
 
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
     int fd_beforepolled_allocd, fd_beforepolled_used;
     libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -186,6 +224,11 @@ struct libxl__ctx {
     uint32_t watch_counter; /* helps disambiguate slot reuse */
     libxl__ev_fd watch_efd;
 
+    LIBXL_TAILQ_HEAD(libxl__evgen_domain_death_list, libxl_evgen_domain_death)
+        death_list /* sorted by domid */,
+        death_reported;
+    libxl__ev_xswatch death_watch;
+    
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -221,6 +264,7 @@ struct libxl__gc {
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
+    LIBXL_TAILQ_HEAD(, libxl_event) occurred_for_callback;
 };
 
 #define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
@@ -243,7 +287,9 @@ static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
  */
 /* register @ptr in @gc for free on exit from outermost libxl callframe. */
 _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
-/* if this is the outermost libxl callframe then free all pointers in @gc */
+/* if this is the outermost libxl callframe then free all pointers in @gc
+ *  and report all occurred events via callback, if applicable.
+ * May reenters the application so must not be called with ctx locked. */
 _hidden void libxl__free_all(libxl__gc *gc);
 /* allocate and zero @bytes. (similar to a gc'd malloc(3)+memzero()) */
 _hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
@@ -393,6 +439,25 @@ static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
 
 
 
+/*
+ * Other event-handling support provided by the libxl event core to
+ * the rest of libxl.
+ */
+
+_hidden void libxl__event_occurred(libxl__gc*, libxl_event *event);
+  /* Arranges to notify the application that the event has occurred.
+   * event should be suitable for passing to libxl_event_free. */
+
+_hidden libxl_event *libxl__event_new(libxl__gc*, libxl_event_type,
+                                      uint32_t domid);
+  /* Convenience function.
+   * Allocates a new libxl_event, fills in domid and type.
+   * If allocation fails, calls _disaster, and returns NULL. */
+
+#define NEW_EVENT(gc, type, domid)                              \
+    libxl__event_new((gc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
 _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
                                    libxl_event_type type /* may be 0 */,
                                    const char *file, int line);
@@ -404,6 +469,9 @@ _hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
    * libxl__ev_FOO_callback or an application event), but are
    * prevented from doing so due to eg lack of memory.
    *
+   * See the "disaster" member of libxl_event_hooks and associated
+   * comment in libxl_event.h.
+   *
    * NB that this function may return and the caller isn't supposed to
    * then crash, although it may fail (and henceforth leave things in
    * a state where many or all calls fail).
@@ -884,7 +952,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  */
 
 #define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
-#define GC_FREE       libxl__free_all(gc)
+#define GC_FREE       libxl__free_all(gc) /* MUST NOT CALL WITH CTX LOCKED */
 #define CTX           libxl__gc_owner(gc)
 
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 2299908..0e4e12f 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -75,11 +75,6 @@ libxl_action_on_shutdown = Enumeration("action_on_shutdown", [
     (6, "COREDUMP_RESTART"),
     ])
 
-libxl_event_type = Enumeration("event_type", [
-    (1, "DOMAIN_DEATH"),
-    (2, "DISK_EJECT"),
-    ])
-
 libxl_button = Enumeration("button", [
     (1, "POWER"),
     (2, "SLEEP"),
@@ -374,3 +369,33 @@ libxl_sched_credit = Struct("sched_credit", [
     ("weight", integer),
     ("cap", integer),
     ], dispose_fn=None)
+
+libxl_event_type = Enumeration("event_type", [
+    (1, "DOMAIN_SHUTDOWN"),
+    (2, "DOMAIN_DESTROY"),
+    (3, "DISK_EJECT"),
+    ])
+
+libxl_ev_user = Number("libxl_ev_user")
+
+libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, c_only=True)
+
+libxl_event = Struct("event",[
+    ("link",     libxl_ev_link,0,
+     "for use by libxl; caller may use this once the event has been"
+     " returned by libxl_event_{check,wait}"),
+    ("domid",    libxl_domid),
+    ("domuuid",  libxl_uuid),
+    ("for_user", libxl_ev_user),
+    ("type",     libxl_event_type),
+    ("u", KeyedUnion(None, libxl_event_type, "type",
+          [("domain_shutdown", Struct(None, [
+                                             ("shutdown_reason", uint8),
+                                      ])),
+           ("domain_destroy", Struct(None, [])),
+           ("disk_eject", Struct(None, [
+                                        ("vdev", string),
+                                        ("disk", libxl_device_disk),
+                                 ])),
+           ]))])
+
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 080aa2b..b9ce2ec 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1142,14 +1142,16 @@ skip_vfb:
     xlu_cfg_destroy(config);
 }
 
-/* Returns 1 if domain should be restarted, 2 if domain should be renamed then restarted  */
-static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                               libxl_domain_config *d_config, libxl_dominfo *info)
+/* Returns 1 if domain should be restarted,
+ * 2 if domain should be renamed then restarted, or 0 */
+static int handle_domain_death(libxl_ctx *ctx, uint32_t domid,
+                               libxl_event *event,
+                               libxl_domain_config *d_config)
 {
     int restart = 0;
     libxl_action_on_shutdown action;
 
-    switch (info->shutdown_reason) {
+    switch (event->u.domain_shutdown.shutdown_reason) {
     case SHUTDOWN_poweroff:
         action = d_config->on_poweroff;
         break;
@@ -1166,11 +1168,14 @@ static int handle_domain_death(libxl_ctx *ctx, uint32_t domid, libxl_event *even
         action = d_config->on_watchdog;
         break;
     default:
-        LOG("Unknown shutdown reason code %d. Destroying domain.", info->shutdown_reason);
+        LOG("Unknown shutdown reason code %d. Destroying domain.",
+            event->u.domain_shutdown.shutdown_reason);
         action = LIBXL_ACTION_ON_SHUTDOWN_DESTROY;
     }
 
-    LOG("Action for shutdown reason code %d is %s", info->shutdown_reason, action_on_shutdown_names[action]);
+    LOG("Action for shutdown reason code %d is %s",
+        event->u.domain_shutdown.shutdown_reason,
+        action_on_shutdown_names[action]);
 
     if (action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY || action == LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_RESTART) {
         char *corefile;
@@ -1235,7 +1240,7 @@ static void replace_string(char **str, const char *val)
 
 
 static int preserve_domain(libxl_ctx *ctx, uint32_t domid, libxl_event *event,
-                           libxl_domain_config *d_config, libxl_dominfo *info)
+                           libxl_domain_config *d_config)
 {
     time_t now;
     struct tm tm;
@@ -1347,6 +1352,24 @@ static int autoconnect_console(libxl_ctx *ctx, uint32_t domid, void *priv)
     _exit(1);
 }
 
+static int domain_wait_event(libxl_event **event_r) {
+    int ret;
+    for (;;) {
+        ret = libxl_event_wait(ctx, event_r, LIBXL_EVENTMASK_ALL, 0,0);
+        if (ret) {
+            LOG("Domain %d, failed to get event, quitting (rc=%d)", domid, ret);
+            return ret;
+        }
+        if ((*event_r)->domid != domid) {
+            LOG("INTERNAL PROBLEM - ignoring unexpected event for"
+                " domain %d (expected %d)", (*event_r)->domid, domid);
+            libxl_event_free(ctx, *event_r);
+            continue;
+        }
+        return ret;
+    }
+}
+
 static int create_domain(struct domain_create *dom_info)
 {
     libxl_domain_config d_config;
@@ -1360,10 +1383,11 @@ static int create_domain(struct domain_create *dom_info)
     const char *restore_file = dom_info->restore_file;
     int migrate_fd = dom_info->migrate_fd;
 
-    int fd, i;
+    int i;
     int need_daemon = daemonize;
     int ret, rc;
-    libxl_waiter *w1 = NULL, *w2 = NULL;
+    libxl_evgen_domain_death *deathw = NULL;
+    libxl_evgen_disk_eject **diskws = NULL; /* one per disk */
     void *config_data = 0;
     int config_len = 0;
     int restore_fd = -1;
@@ -1611,92 +1635,104 @@ start:
     }
     LOG("Waiting for domain %s (domid %d) to die [pid %ld]",
         d_config.c_info.name, domid, (long)getpid());
-    w1 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter) * d_config.num_disks);
-    w2 = (libxl_waiter*) xmalloc(sizeof(libxl_waiter));
-    libxl_wait_for_disk_ejects(ctx, domid, d_config.disks, d_config.num_disks, w1);
-    libxl_wait_for_domain_death(ctx, domid, w2);
-    libxl_get_wait_fd(ctx, &fd);
-    while (1) {
-        int ret;
-        fd_set rfds;
-        libxl_dominfo info;
-        libxl_event event;
-        libxl_device_disk disk;
 
-        FD_ZERO(&rfds);
-        FD_SET(fd, &rfds);
+    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+    if (ret) goto error_out;
 
-        ret = select(fd + 1, &rfds, NULL, NULL, NULL);
-        if (!ret)
-            continue;
-        libxl_get_event(ctx, &event);
-        switch (event.type) {
-            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
-                ret = libxl_event_get_domain_death_info(ctx, domid, &event, &info);
-
-                if (ret < 0) {
-                    libxl_free_event(&event);
-                    continue;
+    if (!diskws) {
+        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
+        for (i = 0; i < d_config.num_disks; i++)
+            diskws[i] = NULL;
+    }
+    for (i = 0; i < d_config.num_disks; i++) {
+        ret = libxl_evenable_disk_eject(ctx, domid, d_config.disks[i].vdev,
+                                        0, &diskws[i]);
+        if (ret) goto error_out;
+    }
+    while (1) {
+        libxl_event *event;
+        ret = domain_wait_event(&event);
+        if (ret) goto error_out;
+
+        switch (event->type) {
+
+        case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+            LOG("Domain %d has shut down, reason code %d 0x%x", domid,
+                event->u.domain_shutdown.shutdown_reason,
+                event->u.domain_shutdown.shutdown_reason);
+            switch (handle_domain_death(ctx, domid, event, &d_config)) {
+            case 2:
+                if (!preserve_domain(ctx, domid, event, &d_config)) {
+                    /* If we fail then exit leaving the old domain in place. */
+                    ret = -1;
+                    goto out;
                 }
 
-                LOG("Domain %d is dead", domid);
-
-                if (ret) {
-                    switch (handle_domain_death(ctx, domid, &event, &d_config, &info)) {
-                    case 2:
-                        if (!preserve_domain(ctx, domid, &event, &d_config, &info)) {
-                            /* If we fail then exit leaving the old domain in place. */
-                            ret = -1;
-                            goto out;
-                        }
-
-                        /* Otherwise fall through and restart. */
-                    case 1:
-
-                        for (i = 0; i < d_config.num_disks; i++)
-                            libxl_free_waiter(&w1[i]);
-                        libxl_free_waiter(w2);
-                        free(w1);
-                        free(w2);
-
-                        /*
-                         * Do not attempt to reconnect if we come round again due to a
-                         * guest reboot -- the stdin/out will be disconnected by then.
-                         */
-                        dom_info->console_autoconnect = 0;
-
-                        /* Some settings only make sense on first boot. */
-                        paused = 0;
-                        if (common_domname
-                            && strcmp(d_config.c_info.name, common_domname)) {
-                            d_config.c_info.name = strdup(common_domname);
-                        }
-
-                        /*
-                         * XXX FIXME: If this sleep is not there then domain
-                         * re-creation fails sometimes.
-                         */
-                        LOG("Done. Rebooting now");
-                        sleep(2);
-                        goto start;
-                    case 0:
-                        LOG("Done. Exiting now");
-                        ret = 0;
-                        goto out;
-                    }
-                } else {
-                    LOG("Unable to get domain death info, quitting");
-                    goto out;
+                /* Otherwise fall through and restart. */
+            case 1:
+                libxl_event_free(ctx, event);
+                libxl_evdisable_domain_death(ctx, deathw);
+                deathw = NULL;
+                for (i = 0; i < d_config.num_disks; i++) {
+                    libxl_evdisable_disk_eject(ctx, diskws[i]);
+                    diskws[i] = NULL;
                 }
-                break;
-            case LIBXL_EVENT_TYPE_DISK_EJECT:
-                if (libxl_event_get_disk_eject_info(ctx, domid, &event, &disk)) {
-                    libxl_cdrom_insert(ctx, domid, &disk);
-                    libxl_device_disk_dispose(&disk);
+                /* discard any other events which may have been generated */
+                while (!(ret = libxl_event_check(ctx, &event,
+                                                 LIBXL_EVENTMASK_ALL, 0,0))) {
+                    libxl_event_free(ctx, event);
                 }
-                break;
+                if (ret != ERROR_NOT_READY) {
+                    LOG("warning, libxl_event_check (cleanup) failed (rc=%d)",
+                        ret);
+                }
+
+                /*
+                 * Do not attempt to reconnect if we come round again due to a
+                 * guest reboot -- the stdin/out will be disconnected by then.
+                 */
+                dom_info->console_autoconnect = 0;
+
+                /* Some settings only make sense on first boot. */
+                paused = 0;
+                if (common_domname
+                    && strcmp(d_config.c_info.name, common_domname)) {
+                    d_config.c_info.name = strdup(common_domname);
+                }
+
+                /*
+                 * XXX FIXME: If this sleep is not there then domain
+                 * re-creation fails sometimes.
+                 */
+                LOG("Done. Rebooting now");
+                sleep(2);
+                goto start;
+
+            case 0:
+                LOG("Done. Exiting now");
+                ret = 0;
+                goto out;
+
+            default:
+                abort();
+            }
+
+        case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+            LOG("Domain %d has been destroyed.", domid);
+            ret = 0;
+            goto out;
+
+        case LIBXL_EVENT_TYPE_DISK_EJECT:
+            /* XXX what is this for? */
+            libxl_cdrom_insert(ctx, domid, &event->u.disk_eject.disk);
+            libxl_device_disk_dispose(&event->u.disk_eject.disk);
+            break;
+
+        default:
+            LOG("warning, got unexpected event type %d", event->type);
         }
-        libxl_free_event(&event);
+
+        libxl_event_free(ctx, event);
     }
 
 error_out:
@@ -2179,43 +2215,46 @@ static void destroy_domain(const char *p)
 static void shutdown_domain(const char *p, int wait)
 {
     int rc;
+    libxl_event *event;
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid, 0);
     if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); }
 
     if (wait) {
-        libxl_waiter waiter;
-        int fd;
-
-        libxl_wait_for_domain_death(ctx, domid, &waiter);
+        libxl_evgen_domain_death *deathw;
 
-        libxl_get_wait_fd(ctx, &fd);
-
-        while (wait) {
-            fd_set rfds;
-            libxl_event event;
-            libxl_dominfo info;
+        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+        if (rc) {
+            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
+            exit(-1);
+        }
 
-            FD_ZERO(&rfds);
-            FD_SET(fd, &rfds);
+        for (;;) {
+            rc = domain_wait_event(&event);
+            if (rc) exit(-1);
 
-            if (!select(fd + 1, &rfds, NULL, NULL, NULL))
-                continue;
+            switch (event->type) {
 
-            libxl_get_event(ctx, &event);
+            case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+                LOG("Domain %d has been destroyed", domid);
+                goto done;
 
-            if (event.type == LIBXL_EVENT_TYPE_DOMAIN_DEATH) {
-                if (libxl_event_get_domain_death_info(ctx, domid, &event, &info) < 0)
-                    continue;
+            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+                LOG("Domain %d has been shut down, reason code %d %x", domid,
+                    event->u.domain_shutdown.shutdown_reason,
+                    event->u.domain_shutdown.shutdown_reason);
+                goto done;
 
-                LOG("Domain %d is dead", domid);
-                wait = 0;
+            default:
+                LOG("Unexpected event type %d", event->type);
+                break;
             }
-
-            libxl_free_event(&event);
+            libxl_event_free(ctx, event);
         }
-        libxl_free_waiter(&waiter);
+    done:
+        libxl_event_free(ctx, event);
+        libxl_evdisable_domain_death(ctx, deathw);
     }
 }
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZF-0003hK-8W; Mon, 28 Nov 2011 17:00:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZB-0003e7-EM
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29141 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055a-Bv; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cR-Aw;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:30 +0000
Message-ID: <1322499580-2322-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/13] libxl: Provide a version of bsd's queue.h
	as _libxl_list.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We would like some linked list macros which are (a) well known to be
sane and (b) typesafe.  BSD's queue.h meets these criteria.

We also provide some simple perlery to arrange to add the libxl_
namespace prefix to the macros.  This will allow us to #include
_libxl_list.h in our public header file without clashing with anyone
else who is also using another version of queue.h.

(A note on copyright: The FreeBSD files we are adding have an
[L]GPL-compatible licence, so there is no need to change our COPYING.
Although FreeBSD's queue.3 still contains the advertising clause, this
has been withdrawn by UCB as recorded in the FreeBSD COPYRIGHT file,
which is included in tools/libxl/external/ for reference.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
Tested-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/Makefile                 |   10 +-
 tools/libxl/bsd-sys-queue-h-seddery  |   70 +++
 tools/libxl/external/README          |   14 +
 tools/libxl/external/bsd-COPYRIGHT   |  126 ++++
 tools/libxl/external/bsd-queue.3     | 1044 ++++++++++++++++++++++++++++++++++
 tools/libxl/external/bsd-sys-queue.h |  637 +++++++++++++++++++++
 6 files changed, 1898 insertions(+), 3 deletions(-)
 create mode 100755 tools/libxl/bsd-sys-queue-h-seddery
 create mode 100644 tools/libxl/external/README
 create mode 100644 tools/libxl/external/bsd-COPYRIGHT
 create mode 100644 tools/libxl/external/bsd-queue.3
 create mode 100644 tools/libxl/external/bsd-sys-queue.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a7a4625..f363da2 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -42,7 +42,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o
@@ -55,7 +55,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
-testidl.c: libxl_types.idl gentest.py libxl.h
+testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
 	mv testidl.c.new testidl.c
 
@@ -63,7 +63,7 @@ testidl.c: libxl_types.idl gentest.py libxl.h
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
 
-$(LIBXLU_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 
 %.c %.h: %.y
 	@rm -f $*.[ch]
@@ -81,6 +81,10 @@ _libxl_paths.h: genpath
 	rm -f $@.tmp
 	$(call move-if-changed,$@.2.tmp,$@)
 
+_libxl_list.h: bsd-sys-queue-h-seddery external/bsd-sys-queue.h
+	perl ./$^ --prefix=libxl >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl_paths.c: _libxl_paths.h
 
 libxl.h: _libxl_types.h
diff --git a/tools/libxl/bsd-sys-queue-h-seddery b/tools/libxl/bsd-sys-queue-h-seddery
new file mode 100755
index 0000000..c0aa079
--- /dev/null
+++ b/tools/libxl/bsd-sys-queue-h-seddery
@@ -0,0 +1,70 @@
+#!/usr/bin/perl -p
+#
+# This script is part of the Xen build system.  It has a very
+# permissive licence to avoid complicating the licence of the
+# generated header file and to allow this seddery to be reused by
+# other projects.
+#
+# Permission is hereby granted, free of charge, to any person
+# obtaining a copy of this individual file (the "Software"), to deal
+# in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute,
+# sublicense, and/or sell copies of the Software, and to permit
+# persons to whom the Software is furnished to do so, subject to the
+# following conditions:
+#
+# The above copyright notice and this permission notice shall be
+# included in all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+# BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+# ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+#
+# Copyright (C) 2011 Citrix Ltd
+
+our $namespace, $ucnamespace;
+
+BEGIN {
+    die unless @ARGV;
+    $namespace = pop @ARGV;
+    $namespace =~ s/^--prefix=// or die;
+    $ucnamespace = uc $namespace;
+
+    print <<END or die $!;
+/*
+ * DO NOT EDIT THIS FILE
+ *
+ * Generated automatically by bsd-sys-queue-h-seddery to
+ *  - introduce ${ucnamespace}_ and ${namespace}_ namespace prefixes
+ *  - turn "struct type" into "type" so that type arguments
+ *     to the macros are type names not struct tags
+ *  - remove the reference to sys/cdefs.h, which is not needed
+ *
+ * The purpose of this seddery is to allow the resulting file to be
+ * freely included by software which might also want to include other
+ * list macros; to make it usable when struct tags are not being used
+ * or not known; to make it more portable.
+ */
+END
+}
+
+s/\b( _SYS_QUEUE |
+      SLIST | LIST | STAILQ | TAILQ | QUEUE
+      )/${ucnamespace}_$1/xg;
+
+s/\b( TRACEBUF | TRASHIT |
+      QMD_
+      )/${ucnamespace}__$1/xg;
+
+s/\b(
+      qm_
+      )/${namespace}__$1/xg;
+
+s/\b struct \s+ type \b/type/xg;
+
+s,^\#include.*sys/cdefs.*,/* $& */,xg;
diff --git a/tools/libxl/external/README b/tools/libxl/external/README
new file mode 100644
index 0000000..8c8beea
--- /dev/null
+++ b/tools/libxl/external/README
@@ -0,0 +1,14 @@
+WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY (apart from this README)
+-----------------------------------------------------------------------
+
+These files were obtained elsewhere and should only be updated by
+copying new versions from the source location, as documented below:
+
+bsd-COPYRIGHT
+bsd-sys-queue.h
+bsd-queue.3
+
+  Obtained from the FreeBSD SVN using the following commands:
+    svn co -r 221843 svn://svn.freebsd.org/base/head/sys/sys/
+    svn co -r 221843 svn://svn.freebsd.org/base/head/share/man/man3
+    svn cat -r 221843 http://svn.freebsd.org/base/head/COPYRIGHT >tools/libxl/external/bsd-COPYRIGHT
diff --git a/tools/libxl/external/bsd-COPYRIGHT b/tools/libxl/external/bsd-COPYRIGHT
new file mode 100644
index 0000000..6dc5d16
--- /dev/null
+++ b/tools/libxl/external/bsd-COPYRIGHT
@@ -0,0 +1,126 @@
+# $FreeBSD$
+#	@(#)COPYRIGHT	8.2 (Berkeley) 3/21/94
+
+The compilation of software known as FreeBSD is distributed under the
+following terms:
+
+Copyright (c) 1992-2011 The FreeBSD Project. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+The 4.4BSD and 4.4BSD-Lite software is distributed under the following
+terms:
+
+All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite
+Releases is copyrighted by The Regents of the University of California.
+
+Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
+	The Regents of the University of California.  All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+3. All advertising materials mentioning features or use of this software
+   must display the following acknowledgement:
+This product includes software developed by the University of
+California, Berkeley and its contributors.
+4. Neither the name of the University nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+The Institute of Electrical and Electronics Engineers and the American
+National Standards Committee X3, on Information Processing Systems have
+given us permission to reprint portions of their documentation.
+
+In the following statement, the phrase ``this text'' refers to portions
+of the system documentation.
+
+Portions of this text are reprinted and reproduced in electronic form in
+the second BSD Networking Software Release, from IEEE Std 1003.1-1988, IEEE
+Standard Portable Operating System Interface for Computer Environments
+(POSIX), copyright C 1988 by the Institute of Electrical and Electronics
+Engineers, Inc.  In the event of any discrepancy between these versions
+and the original IEEE Standard, the original IEEE Standard is the referee
+document.
+
+In the following statement, the phrase ``This material'' refers to portions
+of the system documentation.
+
+This material is reproduced with permission from American National
+Standards Committee X3, on Information Processing Systems.  Computer and
+Business Equipment Manufacturers Association (CBEMA), 311 First St., NW,
+Suite 500, Washington, DC 20001-2178.  The developmental work of
+Programming Language C was completed by the X3J11 Technical Committee.
+
+The views and conclusions contained in the software and documentation are
+those of the authors and should not be interpreted as representing official
+policies, either expressed or implied, of the Regents of the University
+of California.
+
+
+NOTE: The copyright of UC Berkeley's Berkeley Software Distribution ("BSD")
+source has been updated.  The copyright addendum may be found at
+ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change and is
+included below.
+
+July 22, 1999
+
+To All Licensees, Distributors of Any Version of BSD:
+
+As you know, certain of the Berkeley Software Distribution ("BSD") source
+code files require that further distributions of products containing all or
+portions of the software, acknowledge within their advertising materials
+that such products contain software developed by UC Berkeley and its
+contributors.
+
+Specifically, the provision reads:
+
+"     * 3. All advertising materials mentioning features or use of this software
+      *    must display the following acknowledgement:
+      *    This product includes software developed by the University of
+      *    California, Berkeley and its contributors."
+
+Effective immediately, licensees and distributors are no longer required to
+include the acknowledgement within advertising materials.  Accordingly, the
+foregoing paragraph of those BSD Unix files containing it is hereby deleted
+in its entirety.
+
+William Hoskins
+Director, Office of Technology Licensing
+University of California, Berkeley
diff --git a/tools/libxl/external/bsd-queue.3 b/tools/libxl/external/bsd-queue.3
new file mode 100644
index 0000000..007ca5c
--- /dev/null
+++ b/tools/libxl/external/bsd-queue.3
@@ -0,0 +1,1044 @@
+.\" Copyright (c) 1993
+.\"	The Regents of the University of California.  All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"	@(#)queue.3	8.2 (Berkeley) 1/24/94
+.\" $FreeBSD$
+.\"
+.Dd May 13, 2011
+.Dt QUEUE 3
+.Os
+.Sh NAME
+.Nm SLIST_EMPTY ,
+.Nm SLIST_ENTRY ,
+.Nm SLIST_FIRST ,
+.Nm SLIST_FOREACH ,
+.Nm SLIST_FOREACH_SAFE ,
+.Nm SLIST_HEAD ,
+.Nm SLIST_HEAD_INITIALIZER ,
+.Nm SLIST_INIT ,
+.Nm SLIST_INSERT_AFTER ,
+.Nm SLIST_INSERT_HEAD ,
+.Nm SLIST_NEXT ,
+.Nm SLIST_REMOVE_AFTER ,
+.Nm SLIST_REMOVE_HEAD ,
+.Nm SLIST_REMOVE ,
+.Nm SLIST_SWAP ,
+.Nm STAILQ_CONCAT ,
+.Nm STAILQ_EMPTY ,
+.Nm STAILQ_ENTRY ,
+.Nm STAILQ_FIRST ,
+.Nm STAILQ_FOREACH ,
+.Nm STAILQ_FOREACH_SAFE ,
+.Nm STAILQ_HEAD ,
+.Nm STAILQ_HEAD_INITIALIZER ,
+.Nm STAILQ_INIT ,
+.Nm STAILQ_INSERT_AFTER ,
+.Nm STAILQ_INSERT_HEAD ,
+.Nm STAILQ_INSERT_TAIL ,
+.Nm STAILQ_LAST ,
+.Nm STAILQ_NEXT ,
+.Nm STAILQ_REMOVE_AFTER ,
+.Nm STAILQ_REMOVE_HEAD ,
+.Nm STAILQ_REMOVE ,
+.Nm STAILQ_SWAP ,
+.Nm LIST_EMPTY ,
+.Nm LIST_ENTRY ,
+.Nm LIST_FIRST ,
+.Nm LIST_FOREACH ,
+.Nm LIST_FOREACH_SAFE ,
+.Nm LIST_HEAD ,
+.Nm LIST_HEAD_INITIALIZER ,
+.Nm LIST_INIT ,
+.Nm LIST_INSERT_AFTER ,
+.Nm LIST_INSERT_BEFORE ,
+.Nm LIST_INSERT_HEAD ,
+.Nm LIST_NEXT ,
+.Nm LIST_REMOVE ,
+.Nm LIST_SWAP ,
+.Nm TAILQ_CONCAT ,
+.Nm TAILQ_EMPTY ,
+.Nm TAILQ_ENTRY ,
+.Nm TAILQ_FIRST ,
+.Nm TAILQ_FOREACH ,
+.Nm TAILQ_FOREACH_SAFE ,
+.Nm TAILQ_FOREACH_REVERSE ,
+.Nm TAILQ_FOREACH_REVERSE_SAFE ,
+.Nm TAILQ_HEAD ,
+.Nm TAILQ_HEAD_INITIALIZER ,
+.Nm TAILQ_INIT ,
+.Nm TAILQ_INSERT_AFTER ,
+.Nm TAILQ_INSERT_BEFORE ,
+.Nm TAILQ_INSERT_HEAD ,
+.Nm TAILQ_INSERT_TAIL ,
+.Nm TAILQ_LAST ,
+.Nm TAILQ_NEXT ,
+.Nm TAILQ_PREV ,
+.Nm TAILQ_REMOVE ,
+.Nm TAILQ_SWAP
+.Nd implementations of singly-linked lists, singly-linked tail queues,
+lists and tail queues
+.Sh SYNOPSIS
+.In sys/queue.h
+.\"
+.Fn SLIST_EMPTY "SLIST_HEAD *head"
+.Fn SLIST_ENTRY "TYPE"
+.Fn SLIST_FIRST "SLIST_HEAD *head"
+.Fn SLIST_FOREACH "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_FOREACH_SAFE "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME" "TYPE *temp_var"
+.Fn SLIST_HEAD "HEADNAME" "TYPE"
+.Fn SLIST_HEAD_INITIALIZER "SLIST_HEAD head"
+.Fn SLIST_INIT "SLIST_HEAD *head"
+.Fn SLIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_INSERT_HEAD "SLIST_HEAD *head" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_NEXT "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_AFTER "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_HEAD "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE "SLIST_HEAD *head" "TYPE *elm" "TYPE" "SLIST_ENTRY NAME"
+.Fn SLIST_SWAP "SLIST_HEAD *head1" "SLIST_HEAD *head2" "SLIST_ENTRY NAME"
+.\"
+.Fn STAILQ_CONCAT "STAILQ_HEAD *head1" "STAILQ_HEAD *head2"
+.Fn STAILQ_EMPTY "STAILQ_HEAD *head"
+.Fn STAILQ_ENTRY "TYPE"
+.Fn STAILQ_FIRST "STAILQ_HEAD *head"
+.Fn STAILQ_FOREACH "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_FOREACH_SAFE "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn STAILQ_HEAD "HEADNAME" "TYPE"
+.Fn STAILQ_HEAD_INITIALIZER "STAILQ_HEAD head"
+.Fn STAILQ_INIT "STAILQ_HEAD *head"
+.Fn STAILQ_INSERT_AFTER "STAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_HEAD "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_TAIL "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_LAST "STAILQ_HEAD *head" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_NEXT "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_AFTER "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_HEAD "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE "STAILQ_HEAD *head" "TYPE *elm" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_SWAP "STAILQ_HEAD *head1" "STAILQ_HEAD *head2" "STAILQ_ENTRY NAME"
+.\"
+.Fn LIST_EMPTY "LIST_HEAD *head"
+.Fn LIST_ENTRY "TYPE"
+.Fn LIST_FIRST "LIST_HEAD *head"
+.Fn LIST_FOREACH "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME"
+.Fn LIST_FOREACH_SAFE "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME" "TYPE *temp_var"
+.Fn LIST_HEAD "HEADNAME" "TYPE"
+.Fn LIST_HEAD_INITIALIZER "LIST_HEAD head"
+.Fn LIST_INIT "LIST_HEAD *head"
+.Fn LIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_HEAD "LIST_HEAD *head" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_NEXT "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_REMOVE "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_SWAP "LIST_HEAD *head1" "LIST_HEAD *head2" "TYPE" "LIST_ENTRY NAME"
+.\"
+.Fn TAILQ_CONCAT "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TAILQ_ENTRY NAME"
+.Fn TAILQ_EMPTY "TAILQ_HEAD *head"
+.Fn TAILQ_ENTRY "TYPE"
+.Fn TAILQ_FIRST "TAILQ_HEAD *head"
+.Fn TAILQ_FOREACH "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_SAFE "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_FOREACH_REVERSE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_REVERSE_SAFE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_HEAD "HEADNAME" "TYPE"
+.Fn TAILQ_HEAD_INITIALIZER "TAILQ_HEAD head"
+.Fn TAILQ_INIT "TAILQ_HEAD *head"
+.Fn TAILQ_INSERT_AFTER "TAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_HEAD "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_TAIL "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_LAST "TAILQ_HEAD *head" "HEADNAME"
+.Fn TAILQ_NEXT "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_PREV "TYPE *elm" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_REMOVE "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_SWAP "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TYPE" "TAILQ_ENTRY NAME"
+.\"
+.Sh DESCRIPTION
+These macros define and operate on four types of data structures:
+singly-linked lists, singly-linked tail queues, lists, and tail queues.
+All four structures support the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry at the head of the list.
+.It
+Insertion of a new entry after any element in the list.
+.It
+O(1) removal of an entry from the head of the list.
+.It
+Forward traversal through the list.
+.It
+Swawpping the contents of two lists.
+.El
+.Pp
+Singly-linked lists are the simplest of the four data structures
+and support only the above functionality.
+Singly-linked lists are ideal for applications with large datasets
+and few or no removals,
+or for implementing a LIFO queue.
+Singly-linked lists add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+O(n) removal of any entry in the list.
+.El
+.Pp
+Singly-linked tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+O(n) removal of any entry in the list.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+Singly-linked tailqs are ideal for applications with large datasets and
+few or no removals,
+or for implementing a FIFO queue.
+.Pp
+All doubly linked types of data structures (lists and tail queues)
+additionally allow:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry before any element in the list.
+.It
+O(1) removal of any entry in the list.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+Each element requires two pointers rather than one.
+.It
+Code size and execution time of operations (except for removal) is about
+twice that of the singly-linked data-structures.
+.El
+.Pp
+Linked lists are the simplest of the doubly linked data structures and support
+only the above functionality over singly-linked lists.
+.Pp
+Tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+They may be traversed backwards, from tail to head.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions and removals must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+In the macro definitions,
+.Fa TYPE
+is the name of a user defined structure,
+that must contain a field of type
+.Li SLIST_ENTRY ,
+.Li STAILQ_ENTRY ,
+.Li LIST_ENTRY ,
+or
+.Li TAILQ_ENTRY ,
+named
+.Fa NAME .
+The argument
+.Fa HEADNAME
+is the name of a user defined structure that must be declared
+using the macros
+.Li SLIST_HEAD ,
+.Li STAILQ_HEAD ,
+.Li LIST_HEAD ,
+or
+.Li TAILQ_HEAD .
+See the examples below for further explanation of how these
+macros are used.
+.Sh SINGLY-LINKED LISTS
+A singly-linked list is headed by a structure defined by the
+.Nm SLIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are singly linked for minimum space and pointer manipulation
+overhead at the expense of O(n) removal for arbitrary elements.
+New elements can be added to the list after an existing element or
+at the head of the list.
+An
+.Fa SLIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+SLIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm SLIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm SLIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm SLIST_FIRST
+returns the first element in the list or NULL if the list is empty.
+.Pp
+The macro
+.Nm SLIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+.Pp
+The macro
+.Nm SLIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+However, unlike
+.Fn SLIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm SLIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm SLIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm SLIST_NEXT
+returns the next element in the list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the list. Unlike
+.Fa SLIST_REMOVE ,
+this macro does not traverse the entire list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_HEAD
+removes the element
+.Fa elm
+from the head of the list.
+For optimum efficiency,
+elements being removed from the head of the list should explicitly use
+this macro instead of the generic
+.Fa SLIST_REMOVE
+macro.
+.Pp
+The macro
+.Nm SLIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm SLIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED LIST EXAMPLE
+.Bd -literal
+SLIST_HEAD(slisthead, entry) head =
+    SLIST_HEAD_INITIALIZER(head);
+struct slisthead *headp;		/* Singly-linked List head. */
+struct entry {
+	...
+	SLIST_ENTRY(entry) entries;	/* Singly-linked List. */
+	...
+} *n1, *n2, *n3, *np;
+
+SLIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+SLIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+SLIST_INSERT_AFTER(n1, n2, entries);
+
+SLIST_REMOVE(&head, n2, entry, entries);/* Deletion. */
+free(n2);
+
+n3 = SLIST_FIRST(&head);
+SLIST_REMOVE_HEAD(&head, entries);	/* Deletion from the head. */
+free(n3);
+					/* Forward traversal. */
+SLIST_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+SLIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	SLIST_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+
+while (!SLIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = SLIST_FIRST(&head);
+	SLIST_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+.Ed
+.Sh SINGLY-LINKED TAIL QUEUES
+A singly-linked tail queue is headed by a structure defined by the
+.Nm STAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are singly linked for minimum space and pointer
+manipulation overhead at the expense of O(n) removal for arbitrary
+elements.
+New elements can be added to the tail queue after an existing element,
+at the head of the tail queue, or at the end of the tail queue.
+A
+.Fa STAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+STAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm STAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm STAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm STAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm STAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm STAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+.Pp
+The macro
+.Nm STAILQ_FOREACH_SAFE
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+However, unlike
+.Fn STAILQ_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm STAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm STAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm STAILQ_NEXT
+returns the next item on the tail queue, or NULL this item is the last.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the tail queue. Unlike
+.Fa STAILQ_REMOVE ,
+this macro does not traverse the entire tail queue.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_HEAD
+removes the element at the head of the tail queue.
+For optimum efficiency,
+elements being removed from the head of the tail queue should
+use this macro explicitly rather than the generic
+.Fa STAILQ_REMOVE
+macro.
+.Pp
+The macro
+.Nm STAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm STAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED TAIL QUEUE EXAMPLE
+.Bd -literal
+STAILQ_HEAD(stailhead, entry) head =
+    STAILQ_HEAD_INITIALIZER(head);
+struct stailhead *headp;		/* Singly-linked tail queue head. */
+struct entry {
+	...
+	STAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+STAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+STAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+STAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+STAILQ_INSERT_AFTER(&head, n1, n2, entries);
+					/* Deletion. */
+STAILQ_REMOVE(&head, n2, entry, entries);
+free(n2);
+					/* Deletion from the head. */
+n3 = STAILQ_FIRST(&head);
+STAILQ_REMOVE_HEAD(&head, entries);
+free(n3);
+					/* Forward traversal. */
+STAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+STAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	STAILQ_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+					/* TailQ Deletion. */
+while (!STAILQ_EMPTY(&head)) {
+	n1 = STAILQ_FIRST(&head);
+	STAILQ_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = STAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = STAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+STAILQ_INIT(&head);
+.Ed
+.Sh LISTS
+A list is headed by a structure defined by the
+.Nm LIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the list.
+New elements can be added to the list after an existing element,
+before an existing element, or at the head of the list.
+A
+.Fa LIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+LIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm LIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm LIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm LIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm LIST_FIRST
+returns the first element in the list or NULL if the list
+is empty.
+.Pp
+The macro
+.Nm LIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macro
+.Nm LIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+However, unlike
+.Fn LIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm LIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm LIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm LIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_NEXT
+returns the next element in the list, or NULL if this is the last.
+.Pp
+The macro
+.Nm LIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm LIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh LIST EXAMPLE
+.Bd -literal
+LIST_HEAD(listhead, entry) head =
+    LIST_HEAD_INITIALIZER(head);
+struct listhead *headp;			/* List head. */
+struct entry {
+	...
+	LIST_ENTRY(entry) entries;	/* List. */
+	...
+} *n1, *n2, *n3, *np, *np_temp;
+
+LIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+LIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+LIST_INSERT_AFTER(n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+LIST_INSERT_BEFORE(n2, n3, entries);
+
+LIST_REMOVE(n2, entries);		/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+LIST_FOREACH(np, &head, entries)
+	np-> ...
+
+					/* Safe forward traversal. */
+LIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	LIST_REMOVE(np, entries);
+	free(np);
+}
+
+while (!LIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = LIST_FIRST(&head);
+	LIST_REMOVE(n1, entries);
+	free(n1);
+}
+
+n1 = LIST_FIRST(&head);			/* Faster List Deletion. */
+while (n1 != NULL) {
+	n2 = LIST_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+LIST_INIT(&head);
+.Ed
+.Sh TAIL QUEUES
+A tail queue is headed by a structure defined by the
+.Nm TAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the tail queue.
+New elements can be added to the tail queue after an existing element,
+before an existing element, at the head of the tail queue,
+or at the end of the tail queue.
+A
+.Fa TAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+TAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm TAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm TAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm TAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm TAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm TAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Fa var
+is set to
+.Dv NULL
+if the loop completes normally, or if there were no elements.
+.Pp
+The macro
+.Nm TAILQ_FOREACH_REVERSE
+traverses the tail queue referenced by
+.Fa head
+in the reverse direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macros
+.Nm TAILQ_FOREACH_SAFE
+and
+.Nm TAILQ_FOREACH_REVERSE_SAFE
+traverse the list referenced by
+.Fa head
+in the forward or reverse direction respectively,
+assigning each element in turn to
+.Fa var .
+However, unlike their unsafe counterparts,
+.Nm TAILQ_FOREACH
+and
+.Nm TAILQ_FOREACH_REVERSE
+permit to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm TAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm TAILQ_NEXT
+returns the next item on the tail queue, or NULL if this item is the last.
+.Pp
+The macro
+.Nm TAILQ_PREV
+returns the previous item on the tail queue, or NULL if this item
+is the first.
+.Pp
+The macro
+.Nm TAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm TAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh TAIL QUEUE EXAMPLE
+.Bd -literal
+TAILQ_HEAD(tailhead, entry) head =
+    TAILQ_HEAD_INITIALIZER(head);
+struct tailhead *headp;			/* Tail queue head. */
+struct entry {
+	...
+	TAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+TAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+TAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+TAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+TAILQ_INSERT_AFTER(&head, n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+TAILQ_INSERT_BEFORE(n2, n3, entries);
+
+TAILQ_REMOVE(&head, n2, entries);	/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+TAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+TAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	TAILQ_REMOVE(&head, np, entries);
+	free(np);
+}
+					/* Reverse traversal. */
+TAILQ_FOREACH_REVERSE(np, &head, tailhead, entries)
+	np-> ...
+					/* TailQ Deletion. */
+while (!TAILQ_EMPTY(&head)) {
+	n1 = TAILQ_FIRST(&head);
+	TAILQ_REMOVE(&head, n1, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = TAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = TAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+TAILQ_INIT(&head);
+.Ed
+.Sh SEE ALSO
+.Xr tree 3
+.Sh HISTORY
+The
+.Nm queue
+functions first appeared in
+.Bx 4.4 .
diff --git a/tools/libxl/external/bsd-sys-queue.h b/tools/libxl/external/bsd-sys-queue.h
new file mode 100644
index 0000000..274e636
--- /dev/null
+++ b/tools/libxl/external/bsd-sys-queue.h
@@ -0,0 +1,637 @@
+/*-
+ * Copyright (c) 1991, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 4. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ *	@(#)queue.h	8.5 (Berkeley) 8/20/94
+ * $FreeBSD$
+ */
+
+#ifndef _SYS_QUEUE_H_
+#define	_SYS_QUEUE_H_
+
+#include <sys/cdefs.h>
+
+/*
+ * This file defines four types of data structures: singly-linked lists,
+ * singly-linked tail queues, lists and tail queues.
+ *
+ * A singly-linked list is headed by a single forward pointer. The elements
+ * are singly linked for minimum space and pointer manipulation overhead at
+ * the expense of O(n) removal for arbitrary elements. New elements can be
+ * added to the list after an existing element or at the head of the list.
+ * Elements being removed from the head of the list should use the explicit
+ * macro for this purpose for optimum efficiency. A singly-linked list may
+ * only be traversed in the forward direction.  Singly-linked lists are ideal
+ * for applications with large datasets and few or no removals or for
+ * implementing a LIFO queue.
+ *
+ * A singly-linked tail queue is headed by a pair of pointers, one to the
+ * head of the list and the other to the tail of the list. The elements are
+ * singly linked for minimum space and pointer manipulation overhead at the
+ * expense of O(n) removal for arbitrary elements. New elements can be added
+ * to the list after an existing element, at the head of the list, or at the
+ * end of the list. Elements being removed from the head of the tail queue
+ * should use the explicit macro for this purpose for optimum efficiency.
+ * A singly-linked tail queue may only be traversed in the forward direction.
+ * Singly-linked tail queues are ideal for applications with large datasets
+ * and few or no removals or for implementing a FIFO queue.
+ *
+ * A list is headed by a single forward pointer (or an array of forward
+ * pointers for a hash table header). The elements are doubly linked
+ * so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before
+ * or after an existing element or at the head of the list. A list
+ * may only be traversed in the forward direction.
+ *
+ * A tail queue is headed by a pair of pointers, one to the head of the
+ * list and the other to the tail of the list. The elements are doubly
+ * linked so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before or
+ * after an existing element, at the head of the list, or at the end of
+ * the list. A tail queue may be traversed in either direction.
+ *
+ * For details on the use of these macros, see the queue(3) manual page.
+ *
+ *
+ *				SLIST	LIST	STAILQ	TAILQ
+ * _HEAD			+	+	+	+
+ * _HEAD_INITIALIZER		+	+	+	+
+ * _ENTRY			+	+	+	+
+ * _INIT			+	+	+	+
+ * _EMPTY			+	+	+	+
+ * _FIRST			+	+	+	+
+ * _NEXT			+	+	+	+
+ * _PREV			-	-	-	+
+ * _LAST			-	-	+	+
+ * _FOREACH			+	+	+	+
+ * _FOREACH_SAFE		+	+	+	+
+ * _FOREACH_REVERSE		-	-	-	+
+ * _FOREACH_REVERSE_SAFE	-	-	-	+
+ * _INSERT_HEAD			+	+	+	+
+ * _INSERT_BEFORE		-	+	-	+
+ * _INSERT_AFTER		+	+	+	+
+ * _INSERT_TAIL			-	-	+	+
+ * _CONCAT			-	-	+	+
+ * _REMOVE_AFTER		+	-	+	-
+ * _REMOVE_HEAD			+	-	+	-
+ * _REMOVE			+	+	+	+
+ * _SWAP			+	+	+	+
+ *
+ */
+#ifdef QUEUE_MACRO_DEBUG
+/* Store the last 2 places the queue element or head was altered */
+struct qm_trace {
+	char * lastfile;
+	int lastline;
+	char * prevfile;
+	int prevline;
+};
+
+#define	TRACEBUF	struct qm_trace trace;
+#define	TRASHIT(x)	do {(x) = (void *)-1;} while (0)
+#define	QMD_SAVELINK(name, link)	void **name = (void *)&(link)
+
+#define	QMD_TRACE_HEAD(head) do {					\
+	(head)->trace.prevline = (head)->trace.lastline;		\
+	(head)->trace.prevfile = (head)->trace.lastfile;		\
+	(head)->trace.lastline = __LINE__;				\
+	(head)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#define	QMD_TRACE_ELEM(elem) do {					\
+	(elem)->trace.prevline = (elem)->trace.lastline;		\
+	(elem)->trace.prevfile = (elem)->trace.lastfile;		\
+	(elem)->trace.lastline = __LINE__;				\
+	(elem)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#else
+#define	QMD_TRACE_ELEM(elem)
+#define	QMD_TRACE_HEAD(head)
+#define	QMD_SAVELINK(name, link)
+#define	TRACEBUF
+#define	TRASHIT(x)
+#endif	/* QUEUE_MACRO_DEBUG */
+
+/*
+ * Singly-linked List declarations.
+ */
+#define	SLIST_HEAD(name, type)						\
+struct name {								\
+	struct type *slh_first;	/* first element */			\
+}
+
+#define	SLIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	SLIST_ENTRY(type)						\
+struct {								\
+	struct type *sle_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked List functions.
+ */
+#define	SLIST_EMPTY(head)	((head)->slh_first == NULL)
+
+#define	SLIST_FIRST(head)	((head)->slh_first)
+
+#define	SLIST_FOREACH(var, head, field)					\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var);							\
+	    (var) = SLIST_NEXT((var), field))
+
+#define	SLIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var) && ((tvar) = SLIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	SLIST_FOREACH_PREVPTR(var, varp, head, field)			\
+	for ((varp) = &SLIST_FIRST((head));				\
+	    ((var) = *(varp)) != NULL;					\
+	    (varp) = &SLIST_NEXT((var), field))
+
+#define	SLIST_INIT(head) do {						\
+	SLIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	SLIST_INSERT_AFTER(slistelm, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_NEXT((slistelm), field);	\
+	SLIST_NEXT((slistelm), field) = (elm);				\
+} while (0)
+
+#define	SLIST_INSERT_HEAD(head, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_FIRST((head));			\
+	SLIST_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	SLIST_NEXT(elm, field)	((elm)->field.sle_next)
+
+#define	SLIST_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.sle_next);			\
+	if (SLIST_FIRST((head)) == (elm)) {				\
+		SLIST_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = SLIST_FIRST((head));		\
+		while (SLIST_NEXT(curelm, field) != (elm))		\
+			curelm = SLIST_NEXT(curelm, field);		\
+		SLIST_REMOVE_AFTER(curelm, field);			\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define SLIST_REMOVE_AFTER(elm, field) do {				\
+	SLIST_NEXT(elm, field) =					\
+	    SLIST_NEXT(SLIST_NEXT(elm, field), field);			\
+} while (0)
+
+#define	SLIST_REMOVE_HEAD(head, field) do {				\
+	SLIST_FIRST((head)) = SLIST_NEXT(SLIST_FIRST((head)), field);	\
+} while (0)
+
+#define SLIST_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = SLIST_FIRST(head1);			\
+	SLIST_FIRST(head1) = SLIST_FIRST(head2);			\
+	SLIST_FIRST(head2) = swap_first;				\
+} while (0)
+
+/*
+ * Singly-linked Tail queue declarations.
+ */
+#define	STAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *stqh_first;/* first element */			\
+	struct type **stqh_last;/* addr of last next element */		\
+}
+
+#define	STAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).stqh_first }
+
+#define	STAILQ_ENTRY(type)						\
+struct {								\
+	struct type *stqe_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked Tail queue functions.
+ */
+#define	STAILQ_CONCAT(head1, head2) do {				\
+	if (!STAILQ_EMPTY((head2))) {					\
+		*(head1)->stqh_last = (head2)->stqh_first;		\
+		(head1)->stqh_last = (head2)->stqh_last;		\
+		STAILQ_INIT((head2));					\
+	}								\
+} while (0)
+
+#define	STAILQ_EMPTY(head)	((head)->stqh_first == NULL)
+
+#define	STAILQ_FIRST(head)	((head)->stqh_first)
+
+#define	STAILQ_FOREACH(var, head, field)				\
+	for((var) = STAILQ_FIRST((head));				\
+	   (var);							\
+	   (var) = STAILQ_NEXT((var), field))
+
+
+#define	STAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = STAILQ_FIRST((head));				\
+	    (var) && ((tvar) = STAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	STAILQ_INIT(head) do {						\
+	STAILQ_FIRST((head)) = NULL;					\
+	(head)->stqh_last = &STAILQ_FIRST((head));			\
+} while (0)
+
+#define	STAILQ_INSERT_AFTER(head, tqelm, elm, field) do {		\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_NEXT((tqelm), field)) == NULL)\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_NEXT((tqelm), field) = (elm);				\
+} while (0)
+
+#define	STAILQ_INSERT_HEAD(head, elm, field) do {			\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_FIRST((head))) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	STAILQ_INSERT_TAIL(head, elm, field) do {			\
+	STAILQ_NEXT((elm), field) = NULL;				\
+	*(head)->stqh_last = (elm);					\
+	(head)->stqh_last = &STAILQ_NEXT((elm), field);			\
+} while (0)
+
+#define	STAILQ_LAST(head, type, field)					\
+	(STAILQ_EMPTY((head)) ?						\
+		NULL :							\
+	        ((struct type *)(void *)				\
+		((char *)((head)->stqh_last) - __offsetof(struct type, field))))
+
+#define	STAILQ_NEXT(elm, field)	((elm)->field.stqe_next)
+
+#define	STAILQ_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.stqe_next);			\
+	if (STAILQ_FIRST((head)) == (elm)) {				\
+		STAILQ_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = STAILQ_FIRST((head));		\
+		while (STAILQ_NEXT(curelm, field) != (elm))		\
+			curelm = STAILQ_NEXT(curelm, field);		\
+		STAILQ_REMOVE_AFTER(head, curelm, field);		\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define STAILQ_REMOVE_AFTER(head, elm, field) do {			\
+	if ((STAILQ_NEXT(elm, field) =					\
+	     STAILQ_NEXT(STAILQ_NEXT(elm, field), field)) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+} while (0)
+
+#define	STAILQ_REMOVE_HEAD(head, field) do {				\
+	if ((STAILQ_FIRST((head)) =					\
+	     STAILQ_NEXT(STAILQ_FIRST((head)), field)) == NULL)		\
+		(head)->stqh_last = &STAILQ_FIRST((head));		\
+} while (0)
+
+#define STAILQ_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = STAILQ_FIRST(head1);			\
+	struct type **swap_last = (head1)->stqh_last;			\
+	STAILQ_FIRST(head1) = STAILQ_FIRST(head2);			\
+	(head1)->stqh_last = (head2)->stqh_last;			\
+	STAILQ_FIRST(head2) = swap_first;				\
+	(head2)->stqh_last = swap_last;					\
+	if (STAILQ_EMPTY(head1))					\
+		(head1)->stqh_last = &STAILQ_FIRST(head1);		\
+	if (STAILQ_EMPTY(head2))					\
+		(head2)->stqh_last = &STAILQ_FIRST(head2);		\
+} while (0)
+
+
+/*
+ * List declarations.
+ */
+#define	LIST_HEAD(name, type)						\
+struct name {								\
+	struct type *lh_first;	/* first element */			\
+}
+
+#define	LIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	LIST_ENTRY(type)						\
+struct {								\
+	struct type *le_next;	/* next element */			\
+	struct type **le_prev;	/* address of previous next element */	\
+}
+
+/*
+ * List functions.
+ */
+
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_LIST_CHECK_HEAD(head, field) do {				\
+	if (LIST_FIRST((head)) != NULL &&				\
+	    LIST_FIRST((head))->field.le_prev !=			\
+	     &LIST_FIRST((head)))					\
+		panic("Bad list head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_NEXT(elm, field) do {				\
+	if (LIST_NEXT((elm), field) != NULL &&				\
+	    LIST_NEXT((elm), field)->field.le_prev !=			\
+	     &((elm)->field.le_next))					\
+	     	panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.le_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_LIST_CHECK_HEAD(head, field)
+#define	QMD_LIST_CHECK_NEXT(elm, field)
+#define	QMD_LIST_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	LIST_EMPTY(head)	((head)->lh_first == NULL)
+
+#define	LIST_FIRST(head)	((head)->lh_first)
+
+#define	LIST_FOREACH(var, head, field)					\
+	for ((var) = LIST_FIRST((head));				\
+	    (var);							\
+	    (var) = LIST_NEXT((var), field))
+
+#define	LIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = LIST_FIRST((head));				\
+	    (var) && ((tvar) = LIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	LIST_INIT(head) do {						\
+	LIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	LIST_INSERT_AFTER(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_NEXT(listelm, field);				\
+	if ((LIST_NEXT((elm), field) = LIST_NEXT((listelm), field)) != NULL)\
+		LIST_NEXT((listelm), field)->field.le_prev =		\
+		    &LIST_NEXT((elm), field);				\
+	LIST_NEXT((listelm), field) = (elm);				\
+	(elm)->field.le_prev = &LIST_NEXT((listelm), field);		\
+} while (0)
+
+#define	LIST_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_PREV(listelm, field);				\
+	(elm)->field.le_prev = (listelm)->field.le_prev;		\
+	LIST_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.le_prev = (elm);				\
+	(listelm)->field.le_prev = &LIST_NEXT((elm), field);		\
+} while (0)
+
+#define	LIST_INSERT_HEAD(head, elm, field) do {				\
+	QMD_LIST_CHECK_HEAD((head), field);				\
+	if ((LIST_NEXT((elm), field) = LIST_FIRST((head))) != NULL)	\
+		LIST_FIRST((head))->field.le_prev = &LIST_NEXT((elm), field);\
+	LIST_FIRST((head)) = (elm);					\
+	(elm)->field.le_prev = &LIST_FIRST((head));			\
+} while (0)
+
+#define	LIST_NEXT(elm, field)	((elm)->field.le_next)
+
+#define	LIST_REMOVE(elm, field) do {					\
+	QMD_SAVELINK(oldnext, (elm)->field.le_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.le_prev);			\
+	QMD_LIST_CHECK_NEXT(elm, field);				\
+	QMD_LIST_CHECK_PREV(elm, field);				\
+	if (LIST_NEXT((elm), field) != NULL)				\
+		LIST_NEXT((elm), field)->field.le_prev = 		\
+		    (elm)->field.le_prev;				\
+	*(elm)->field.le_prev = LIST_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+} while (0)
+
+#define LIST_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_tmp = LIST_FIRST((head1));			\
+	LIST_FIRST((head1)) = LIST_FIRST((head2));			\
+	LIST_FIRST((head2)) = swap_tmp;					\
+	if ((swap_tmp = LIST_FIRST((head1))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head1));		\
+	if ((swap_tmp = LIST_FIRST((head2))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head2));		\
+} while (0)
+
+/*
+ * Tail queue declarations.
+ */
+#define	TAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *tqh_first;	/* first element */			\
+	struct type **tqh_last;	/* addr of last next element */		\
+	TRACEBUF							\
+}
+
+#define	TAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).tqh_first }
+
+#define	TAILQ_ENTRY(type)						\
+struct {								\
+	struct type *tqe_next;	/* next element */			\
+	struct type **tqe_prev;	/* address of previous next element */	\
+	TRACEBUF							\
+}
+
+/*
+ * Tail queue functions.
+ */
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_TAILQ_CHECK_HEAD(head, field) do {				\
+	if (!TAILQ_EMPTY(head) &&					\
+	    TAILQ_FIRST((head))->field.tqe_prev !=			\
+	     &TAILQ_FIRST((head)))					\
+		panic("Bad tailq head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_TAIL(head, field) do {				\
+	if (*(head)->tqh_last != NULL)					\
+	    	panic("Bad tailq NEXT(%p->tqh_last) != NULL", (head)); 	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_NEXT(elm, field) do {				\
+	if (TAILQ_NEXT((elm), field) != NULL &&				\
+	    TAILQ_NEXT((elm), field)->field.tqe_prev !=			\
+	     &((elm)->field.tqe_next))					\
+		panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.tqe_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_TAILQ_CHECK_HEAD(head, field)
+#define	QMD_TAILQ_CHECK_TAIL(head, headname)
+#define	QMD_TAILQ_CHECK_NEXT(elm, field)
+#define	QMD_TAILQ_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	TAILQ_CONCAT(head1, head2, field) do {				\
+	if (!TAILQ_EMPTY(head2)) {					\
+		*(head1)->tqh_last = (head2)->tqh_first;		\
+		(head2)->tqh_first->field.tqe_prev = (head1)->tqh_last;	\
+		(head1)->tqh_last = (head2)->tqh_last;			\
+		TAILQ_INIT((head2));					\
+		QMD_TRACE_HEAD(head1);					\
+		QMD_TRACE_HEAD(head2);					\
+	}								\
+} while (0)
+
+#define	TAILQ_EMPTY(head)	((head)->tqh_first == NULL)
+
+#define	TAILQ_FIRST(head)	((head)->tqh_first)
+
+#define	TAILQ_FOREACH(var, head, field)					\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var);							\
+	    (var) = TAILQ_NEXT((var), field))
+
+#define	TAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var) && ((tvar) = TAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	TAILQ_FOREACH_REVERSE(var, head, headname, field)		\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var);							\
+	    (var) = TAILQ_PREV((var), headname, field))
+
+#define	TAILQ_FOREACH_REVERSE_SAFE(var, head, headname, field, tvar)	\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var) && ((tvar) = TAILQ_PREV((var), headname, field), 1);	\
+	    (var) = (tvar))
+
+#define	TAILQ_INIT(head) do {						\
+	TAILQ_FIRST((head)) = NULL;					\
+	(head)->tqh_last = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+} while (0)
+
+#define	TAILQ_INSERT_AFTER(head, listelm, elm, field) do {		\
+	QMD_TAILQ_CHECK_NEXT(listelm, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_NEXT((listelm), field)) != NULL)\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    &TAILQ_NEXT((elm), field);				\
+	else {								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	TAILQ_NEXT((listelm), field) = (elm);				\
+	(elm)->field.tqe_prev = &TAILQ_NEXT((listelm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_TAILQ_CHECK_PREV(listelm, field);				\
+	(elm)->field.tqe_prev = (listelm)->field.tqe_prev;		\
+	TAILQ_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.tqe_prev = (elm);				\
+	(listelm)->field.tqe_prev = &TAILQ_NEXT((elm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_HEAD(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_HEAD(head, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_FIRST((head))) != NULL)	\
+		TAILQ_FIRST((head))->field.tqe_prev =			\
+		    &TAILQ_NEXT((elm), field);				\
+	else								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+	TAILQ_FIRST((head)) = (elm);					\
+	(elm)->field.tqe_prev = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_INSERT_TAIL(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_TAIL(head, field);				\
+	TAILQ_NEXT((elm), field) = NULL;				\
+	(elm)->field.tqe_prev = (head)->tqh_last;			\
+	*(head)->tqh_last = (elm);					\
+	(head)->tqh_last = &TAILQ_NEXT((elm), field);			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_LAST(head, headname)					\
+	(*(((struct headname *)((head)->tqh_last))->tqh_last))
+
+#define	TAILQ_NEXT(elm, field) ((elm)->field.tqe_next)
+
+#define	TAILQ_PREV(elm, headname, field)				\
+	(*(((struct headname *)((elm)->field.tqe_prev))->tqh_last))
+
+#define	TAILQ_REMOVE(head, elm, field) do {				\
+	QMD_SAVELINK(oldnext, (elm)->field.tqe_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.tqe_prev);			\
+	QMD_TAILQ_CHECK_NEXT(elm, field);				\
+	QMD_TAILQ_CHECK_PREV(elm, field);				\
+	if ((TAILQ_NEXT((elm), field)) != NULL)				\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    (elm)->field.tqe_prev;				\
+	else {								\
+		(head)->tqh_last = (elm)->field.tqe_prev;		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	*(elm)->field.tqe_prev = TAILQ_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define TAILQ_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_first = (head1)->tqh_first;			\
+	struct type **swap_last = (head1)->tqh_last;			\
+	(head1)->tqh_first = (head2)->tqh_first;			\
+	(head1)->tqh_last = (head2)->tqh_last;				\
+	(head2)->tqh_first = swap_first;				\
+	(head2)->tqh_last = swap_last;					\
+	if ((swap_first = (head1)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head1)->tqh_first;	\
+	else								\
+		(head1)->tqh_last = &(head1)->tqh_first;		\
+	if ((swap_first = (head2)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head2)->tqh_first;	\
+	else								\
+		(head2)->tqh_last = &(head2)->tqh_first;		\
+} while (0)
+
+#endif /* !_SYS_QUEUE_H_ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZF-0003hK-8W; Mon, 28 Nov 2011 17:00:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZB-0003e7-EM
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29141 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055a-Bv; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cR-Aw;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:30 +0000
Message-ID: <1322499580-2322-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 03/13] libxl: Provide a version of bsd's queue.h
	as _libxl_list.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We would like some linked list macros which are (a) well known to be
sane and (b) typesafe.  BSD's queue.h meets these criteria.

We also provide some simple perlery to arrange to add the libxl_
namespace prefix to the macros.  This will allow us to #include
_libxl_list.h in our public header file without clashing with anyone
else who is also using another version of queue.h.

(A note on copyright: The FreeBSD files we are adding have an
[L]GPL-compatible licence, so there is no need to change our COPYING.
Although FreeBSD's queue.3 still contains the advertising clause, this
has been withdrawn by UCB as recorded in the FreeBSD COPYRIGHT file,
which is included in tools/libxl/external/ for reference.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.campbell@citrix.com>
Tested-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 tools/libxl/Makefile                 |   10 +-
 tools/libxl/bsd-sys-queue-h-seddery  |   70 +++
 tools/libxl/external/README          |   14 +
 tools/libxl/external/bsd-COPYRIGHT   |  126 ++++
 tools/libxl/external/bsd-queue.3     | 1044 ++++++++++++++++++++++++++++++++++
 tools/libxl/external/bsd-sys-queue.h |  637 +++++++++++++++++++++
 6 files changed, 1898 insertions(+), 3 deletions(-)
 create mode 100755 tools/libxl/bsd-sys-queue-h-seddery
 create mode 100644 tools/libxl/external/README
 create mode 100644 tools/libxl/external/bsd-COPYRIGHT
 create mode 100644 tools/libxl/external/bsd-queue.3
 create mode 100644 tools/libxl/external/bsd-sys-queue.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a7a4625..f363da2 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -42,7 +42,7 @@ LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
 
-AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h
+AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
 AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
 LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
 	libxlu_disk_l.o libxlu_disk.o
@@ -55,7 +55,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
 testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight)
-testidl.c: libxl_types.idl gentest.py libxl.h
+testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 	$(PYTHON) gentest.py libxl_types.idl testidl.c.new
 	mv testidl.c.new testidl.c
 
@@ -63,7 +63,7 @@ testidl.c: libxl_types.idl gentest.py libxl.h
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
 
-$(LIBXLU_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): $(AUTOINCS)
 
 %.c %.h: %.y
 	@rm -f $*.[ch]
@@ -81,6 +81,10 @@ _libxl_paths.h: genpath
 	rm -f $@.tmp
 	$(call move-if-changed,$@.2.tmp,$@)
 
+_libxl_list.h: bsd-sys-queue-h-seddery external/bsd-sys-queue.h
+	perl ./$^ --prefix=libxl >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 libxl_paths.c: _libxl_paths.h
 
 libxl.h: _libxl_types.h
diff --git a/tools/libxl/bsd-sys-queue-h-seddery b/tools/libxl/bsd-sys-queue-h-seddery
new file mode 100755
index 0000000..c0aa079
--- /dev/null
+++ b/tools/libxl/bsd-sys-queue-h-seddery
@@ -0,0 +1,70 @@
+#!/usr/bin/perl -p
+#
+# This script is part of the Xen build system.  It has a very
+# permissive licence to avoid complicating the licence of the
+# generated header file and to allow this seddery to be reused by
+# other projects.
+#
+# Permission is hereby granted, free of charge, to any person
+# obtaining a copy of this individual file (the "Software"), to deal
+# in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute,
+# sublicense, and/or sell copies of the Software, and to permit
+# persons to whom the Software is furnished to do so, subject to the
+# following conditions:
+#
+# The above copyright notice and this permission notice shall be
+# included in all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+# BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+# ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+#
+# Copyright (C) 2011 Citrix Ltd
+
+our $namespace, $ucnamespace;
+
+BEGIN {
+    die unless @ARGV;
+    $namespace = pop @ARGV;
+    $namespace =~ s/^--prefix=// or die;
+    $ucnamespace = uc $namespace;
+
+    print <<END or die $!;
+/*
+ * DO NOT EDIT THIS FILE
+ *
+ * Generated automatically by bsd-sys-queue-h-seddery to
+ *  - introduce ${ucnamespace}_ and ${namespace}_ namespace prefixes
+ *  - turn "struct type" into "type" so that type arguments
+ *     to the macros are type names not struct tags
+ *  - remove the reference to sys/cdefs.h, which is not needed
+ *
+ * The purpose of this seddery is to allow the resulting file to be
+ * freely included by software which might also want to include other
+ * list macros; to make it usable when struct tags are not being used
+ * or not known; to make it more portable.
+ */
+END
+}
+
+s/\b( _SYS_QUEUE |
+      SLIST | LIST | STAILQ | TAILQ | QUEUE
+      )/${ucnamespace}_$1/xg;
+
+s/\b( TRACEBUF | TRASHIT |
+      QMD_
+      )/${ucnamespace}__$1/xg;
+
+s/\b(
+      qm_
+      )/${namespace}__$1/xg;
+
+s/\b struct \s+ type \b/type/xg;
+
+s,^\#include.*sys/cdefs.*,/* $& */,xg;
diff --git a/tools/libxl/external/README b/tools/libxl/external/README
new file mode 100644
index 0000000..8c8beea
--- /dev/null
+++ b/tools/libxl/external/README
@@ -0,0 +1,14 @@
+WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY (apart from this README)
+-----------------------------------------------------------------------
+
+These files were obtained elsewhere and should only be updated by
+copying new versions from the source location, as documented below:
+
+bsd-COPYRIGHT
+bsd-sys-queue.h
+bsd-queue.3
+
+  Obtained from the FreeBSD SVN using the following commands:
+    svn co -r 221843 svn://svn.freebsd.org/base/head/sys/sys/
+    svn co -r 221843 svn://svn.freebsd.org/base/head/share/man/man3
+    svn cat -r 221843 http://svn.freebsd.org/base/head/COPYRIGHT >tools/libxl/external/bsd-COPYRIGHT
diff --git a/tools/libxl/external/bsd-COPYRIGHT b/tools/libxl/external/bsd-COPYRIGHT
new file mode 100644
index 0000000..6dc5d16
--- /dev/null
+++ b/tools/libxl/external/bsd-COPYRIGHT
@@ -0,0 +1,126 @@
+# $FreeBSD$
+#	@(#)COPYRIGHT	8.2 (Berkeley) 3/21/94
+
+The compilation of software known as FreeBSD is distributed under the
+following terms:
+
+Copyright (c) 1992-2011 The FreeBSD Project. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+The 4.4BSD and 4.4BSD-Lite software is distributed under the following
+terms:
+
+All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite
+Releases is copyrighted by The Regents of the University of California.
+
+Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
+	The Regents of the University of California.  All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+3. All advertising materials mentioning features or use of this software
+   must display the following acknowledgement:
+This product includes software developed by the University of
+California, Berkeley and its contributors.
+4. Neither the name of the University nor the names of its contributors
+   may be used to endorse or promote products derived from this software
+   without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
+
+The Institute of Electrical and Electronics Engineers and the American
+National Standards Committee X3, on Information Processing Systems have
+given us permission to reprint portions of their documentation.
+
+In the following statement, the phrase ``this text'' refers to portions
+of the system documentation.
+
+Portions of this text are reprinted and reproduced in electronic form in
+the second BSD Networking Software Release, from IEEE Std 1003.1-1988, IEEE
+Standard Portable Operating System Interface for Computer Environments
+(POSIX), copyright C 1988 by the Institute of Electrical and Electronics
+Engineers, Inc.  In the event of any discrepancy between these versions
+and the original IEEE Standard, the original IEEE Standard is the referee
+document.
+
+In the following statement, the phrase ``This material'' refers to portions
+of the system documentation.
+
+This material is reproduced with permission from American National
+Standards Committee X3, on Information Processing Systems.  Computer and
+Business Equipment Manufacturers Association (CBEMA), 311 First St., NW,
+Suite 500, Washington, DC 20001-2178.  The developmental work of
+Programming Language C was completed by the X3J11 Technical Committee.
+
+The views and conclusions contained in the software and documentation are
+those of the authors and should not be interpreted as representing official
+policies, either expressed or implied, of the Regents of the University
+of California.
+
+
+NOTE: The copyright of UC Berkeley's Berkeley Software Distribution ("BSD")
+source has been updated.  The copyright addendum may be found at
+ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change and is
+included below.
+
+July 22, 1999
+
+To All Licensees, Distributors of Any Version of BSD:
+
+As you know, certain of the Berkeley Software Distribution ("BSD") source
+code files require that further distributions of products containing all or
+portions of the software, acknowledge within their advertising materials
+that such products contain software developed by UC Berkeley and its
+contributors.
+
+Specifically, the provision reads:
+
+"     * 3. All advertising materials mentioning features or use of this software
+      *    must display the following acknowledgement:
+      *    This product includes software developed by the University of
+      *    California, Berkeley and its contributors."
+
+Effective immediately, licensees and distributors are no longer required to
+include the acknowledgement within advertising materials.  Accordingly, the
+foregoing paragraph of those BSD Unix files containing it is hereby deleted
+in its entirety.
+
+William Hoskins
+Director, Office of Technology Licensing
+University of California, Berkeley
diff --git a/tools/libxl/external/bsd-queue.3 b/tools/libxl/external/bsd-queue.3
new file mode 100644
index 0000000..007ca5c
--- /dev/null
+++ b/tools/libxl/external/bsd-queue.3
@@ -0,0 +1,1044 @@
+.\" Copyright (c) 1993
+.\"	The Regents of the University of California.  All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"    notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"    notice, this list of conditions and the following disclaimer in the
+.\"    documentation and/or other materials provided with the distribution.
+.\" 3. All advertising materials mentioning features or use of this software
+.\"    must display the following acknowledgement:
+.\"	This product includes software developed by the University of
+.\"	California, Berkeley and its contributors.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\"    may be used to endorse or promote products derived from this software
+.\"    without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"	@(#)queue.3	8.2 (Berkeley) 1/24/94
+.\" $FreeBSD$
+.\"
+.Dd May 13, 2011
+.Dt QUEUE 3
+.Os
+.Sh NAME
+.Nm SLIST_EMPTY ,
+.Nm SLIST_ENTRY ,
+.Nm SLIST_FIRST ,
+.Nm SLIST_FOREACH ,
+.Nm SLIST_FOREACH_SAFE ,
+.Nm SLIST_HEAD ,
+.Nm SLIST_HEAD_INITIALIZER ,
+.Nm SLIST_INIT ,
+.Nm SLIST_INSERT_AFTER ,
+.Nm SLIST_INSERT_HEAD ,
+.Nm SLIST_NEXT ,
+.Nm SLIST_REMOVE_AFTER ,
+.Nm SLIST_REMOVE_HEAD ,
+.Nm SLIST_REMOVE ,
+.Nm SLIST_SWAP ,
+.Nm STAILQ_CONCAT ,
+.Nm STAILQ_EMPTY ,
+.Nm STAILQ_ENTRY ,
+.Nm STAILQ_FIRST ,
+.Nm STAILQ_FOREACH ,
+.Nm STAILQ_FOREACH_SAFE ,
+.Nm STAILQ_HEAD ,
+.Nm STAILQ_HEAD_INITIALIZER ,
+.Nm STAILQ_INIT ,
+.Nm STAILQ_INSERT_AFTER ,
+.Nm STAILQ_INSERT_HEAD ,
+.Nm STAILQ_INSERT_TAIL ,
+.Nm STAILQ_LAST ,
+.Nm STAILQ_NEXT ,
+.Nm STAILQ_REMOVE_AFTER ,
+.Nm STAILQ_REMOVE_HEAD ,
+.Nm STAILQ_REMOVE ,
+.Nm STAILQ_SWAP ,
+.Nm LIST_EMPTY ,
+.Nm LIST_ENTRY ,
+.Nm LIST_FIRST ,
+.Nm LIST_FOREACH ,
+.Nm LIST_FOREACH_SAFE ,
+.Nm LIST_HEAD ,
+.Nm LIST_HEAD_INITIALIZER ,
+.Nm LIST_INIT ,
+.Nm LIST_INSERT_AFTER ,
+.Nm LIST_INSERT_BEFORE ,
+.Nm LIST_INSERT_HEAD ,
+.Nm LIST_NEXT ,
+.Nm LIST_REMOVE ,
+.Nm LIST_SWAP ,
+.Nm TAILQ_CONCAT ,
+.Nm TAILQ_EMPTY ,
+.Nm TAILQ_ENTRY ,
+.Nm TAILQ_FIRST ,
+.Nm TAILQ_FOREACH ,
+.Nm TAILQ_FOREACH_SAFE ,
+.Nm TAILQ_FOREACH_REVERSE ,
+.Nm TAILQ_FOREACH_REVERSE_SAFE ,
+.Nm TAILQ_HEAD ,
+.Nm TAILQ_HEAD_INITIALIZER ,
+.Nm TAILQ_INIT ,
+.Nm TAILQ_INSERT_AFTER ,
+.Nm TAILQ_INSERT_BEFORE ,
+.Nm TAILQ_INSERT_HEAD ,
+.Nm TAILQ_INSERT_TAIL ,
+.Nm TAILQ_LAST ,
+.Nm TAILQ_NEXT ,
+.Nm TAILQ_PREV ,
+.Nm TAILQ_REMOVE ,
+.Nm TAILQ_SWAP
+.Nd implementations of singly-linked lists, singly-linked tail queues,
+lists and tail queues
+.Sh SYNOPSIS
+.In sys/queue.h
+.\"
+.Fn SLIST_EMPTY "SLIST_HEAD *head"
+.Fn SLIST_ENTRY "TYPE"
+.Fn SLIST_FIRST "SLIST_HEAD *head"
+.Fn SLIST_FOREACH "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_FOREACH_SAFE "TYPE *var" "SLIST_HEAD *head" "SLIST_ENTRY NAME" "TYPE *temp_var"
+.Fn SLIST_HEAD "HEADNAME" "TYPE"
+.Fn SLIST_HEAD_INITIALIZER "SLIST_HEAD head"
+.Fn SLIST_INIT "SLIST_HEAD *head"
+.Fn SLIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_INSERT_HEAD "SLIST_HEAD *head" "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_NEXT "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_AFTER "TYPE *elm" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE_HEAD "SLIST_HEAD *head" "SLIST_ENTRY NAME"
+.Fn SLIST_REMOVE "SLIST_HEAD *head" "TYPE *elm" "TYPE" "SLIST_ENTRY NAME"
+.Fn SLIST_SWAP "SLIST_HEAD *head1" "SLIST_HEAD *head2" "SLIST_ENTRY NAME"
+.\"
+.Fn STAILQ_CONCAT "STAILQ_HEAD *head1" "STAILQ_HEAD *head2"
+.Fn STAILQ_EMPTY "STAILQ_HEAD *head"
+.Fn STAILQ_ENTRY "TYPE"
+.Fn STAILQ_FIRST "STAILQ_HEAD *head"
+.Fn STAILQ_FOREACH "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_FOREACH_SAFE "TYPE *var" "STAILQ_HEAD *head" "STAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn STAILQ_HEAD "HEADNAME" "TYPE"
+.Fn STAILQ_HEAD_INITIALIZER "STAILQ_HEAD head"
+.Fn STAILQ_INIT "STAILQ_HEAD *head"
+.Fn STAILQ_INSERT_AFTER "STAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_HEAD "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_INSERT_TAIL "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_LAST "STAILQ_HEAD *head" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_NEXT "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_AFTER "STAILQ_HEAD *head" "TYPE *elm" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE_HEAD "STAILQ_HEAD *head" "STAILQ_ENTRY NAME"
+.Fn STAILQ_REMOVE "STAILQ_HEAD *head" "TYPE *elm" "TYPE" "STAILQ_ENTRY NAME"
+.Fn STAILQ_SWAP "STAILQ_HEAD *head1" "STAILQ_HEAD *head2" "STAILQ_ENTRY NAME"
+.\"
+.Fn LIST_EMPTY "LIST_HEAD *head"
+.Fn LIST_ENTRY "TYPE"
+.Fn LIST_FIRST "LIST_HEAD *head"
+.Fn LIST_FOREACH "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME"
+.Fn LIST_FOREACH_SAFE "TYPE *var" "LIST_HEAD *head" "LIST_ENTRY NAME" "TYPE *temp_var"
+.Fn LIST_HEAD "HEADNAME" "TYPE"
+.Fn LIST_HEAD_INITIALIZER "LIST_HEAD head"
+.Fn LIST_INIT "LIST_HEAD *head"
+.Fn LIST_INSERT_AFTER "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_INSERT_HEAD "LIST_HEAD *head" "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_NEXT "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_REMOVE "TYPE *elm" "LIST_ENTRY NAME"
+.Fn LIST_SWAP "LIST_HEAD *head1" "LIST_HEAD *head2" "TYPE" "LIST_ENTRY NAME"
+.\"
+.Fn TAILQ_CONCAT "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TAILQ_ENTRY NAME"
+.Fn TAILQ_EMPTY "TAILQ_HEAD *head"
+.Fn TAILQ_ENTRY "TYPE"
+.Fn TAILQ_FIRST "TAILQ_HEAD *head"
+.Fn TAILQ_FOREACH "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_SAFE "TYPE *var" "TAILQ_HEAD *head" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_FOREACH_REVERSE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_FOREACH_REVERSE_SAFE "TYPE *var" "TAILQ_HEAD *head" "HEADNAME" "TAILQ_ENTRY NAME" "TYPE *temp_var"
+.Fn TAILQ_HEAD "HEADNAME" "TYPE"
+.Fn TAILQ_HEAD_INITIALIZER "TAILQ_HEAD head"
+.Fn TAILQ_INIT "TAILQ_HEAD *head"
+.Fn TAILQ_INSERT_AFTER "TAILQ_HEAD *head" "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_BEFORE "TYPE *listelm" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_HEAD "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_INSERT_TAIL "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_LAST "TAILQ_HEAD *head" "HEADNAME"
+.Fn TAILQ_NEXT "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_PREV "TYPE *elm" "HEADNAME" "TAILQ_ENTRY NAME"
+.Fn TAILQ_REMOVE "TAILQ_HEAD *head" "TYPE *elm" "TAILQ_ENTRY NAME"
+.Fn TAILQ_SWAP "TAILQ_HEAD *head1" "TAILQ_HEAD *head2" "TYPE" "TAILQ_ENTRY NAME"
+.\"
+.Sh DESCRIPTION
+These macros define and operate on four types of data structures:
+singly-linked lists, singly-linked tail queues, lists, and tail queues.
+All four structures support the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry at the head of the list.
+.It
+Insertion of a new entry after any element in the list.
+.It
+O(1) removal of an entry from the head of the list.
+.It
+Forward traversal through the list.
+.It
+Swawpping the contents of two lists.
+.El
+.Pp
+Singly-linked lists are the simplest of the four data structures
+and support only the above functionality.
+Singly-linked lists are ideal for applications with large datasets
+and few or no removals,
+or for implementing a LIFO queue.
+Singly-linked lists add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+O(n) removal of any entry in the list.
+.El
+.Pp
+Singly-linked tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+O(n) removal of any entry in the list.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+Singly-linked tailqs are ideal for applications with large datasets and
+few or no removals,
+or for implementing a FIFO queue.
+.Pp
+All doubly linked types of data structures (lists and tail queues)
+additionally allow:
+.Bl -enum -compact -offset indent
+.It
+Insertion of a new entry before any element in the list.
+.It
+O(1) removal of any entry in the list.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+Each element requires two pointers rather than one.
+.It
+Code size and execution time of operations (except for removal) is about
+twice that of the singly-linked data-structures.
+.El
+.Pp
+Linked lists are the simplest of the doubly linked data structures and support
+only the above functionality over singly-linked lists.
+.Pp
+Tail queues add the following functionality:
+.Bl -enum -compact -offset indent
+.It
+Entries can be added at the end of a list.
+.It
+They may be traversed backwards, from tail to head.
+.It
+They may be concatenated.
+.El
+However:
+.Bl -enum -compact -offset indent
+.It
+All list insertions and removals must specify the head of the list.
+.It
+Each head entry requires two pointers rather than one.
+.It
+Code size is about 15% greater and operations run about 20% slower
+than singly-linked lists.
+.El
+.Pp
+In the macro definitions,
+.Fa TYPE
+is the name of a user defined structure,
+that must contain a field of type
+.Li SLIST_ENTRY ,
+.Li STAILQ_ENTRY ,
+.Li LIST_ENTRY ,
+or
+.Li TAILQ_ENTRY ,
+named
+.Fa NAME .
+The argument
+.Fa HEADNAME
+is the name of a user defined structure that must be declared
+using the macros
+.Li SLIST_HEAD ,
+.Li STAILQ_HEAD ,
+.Li LIST_HEAD ,
+or
+.Li TAILQ_HEAD .
+See the examples below for further explanation of how these
+macros are used.
+.Sh SINGLY-LINKED LISTS
+A singly-linked list is headed by a structure defined by the
+.Nm SLIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are singly linked for minimum space and pointer manipulation
+overhead at the expense of O(n) removal for arbitrary elements.
+New elements can be added to the list after an existing element or
+at the head of the list.
+An
+.Fa SLIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+SLIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm SLIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm SLIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm SLIST_FIRST
+returns the first element in the list or NULL if the list is empty.
+.Pp
+The macro
+.Nm SLIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+.Pp
+The macro
+.Nm SLIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in
+turn to
+.Fa var .
+However, unlike
+.Fn SLIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm SLIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm SLIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm SLIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm SLIST_NEXT
+returns the next element in the list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the list. Unlike
+.Fa SLIST_REMOVE ,
+this macro does not traverse the entire list.
+.Pp
+The macro
+.Nm SLIST_REMOVE_HEAD
+removes the element
+.Fa elm
+from the head of the list.
+For optimum efficiency,
+elements being removed from the head of the list should explicitly use
+this macro instead of the generic
+.Fa SLIST_REMOVE
+macro.
+.Pp
+The macro
+.Nm SLIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm SLIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED LIST EXAMPLE
+.Bd -literal
+SLIST_HEAD(slisthead, entry) head =
+    SLIST_HEAD_INITIALIZER(head);
+struct slisthead *headp;		/* Singly-linked List head. */
+struct entry {
+	...
+	SLIST_ENTRY(entry) entries;	/* Singly-linked List. */
+	...
+} *n1, *n2, *n3, *np;
+
+SLIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+SLIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+SLIST_INSERT_AFTER(n1, n2, entries);
+
+SLIST_REMOVE(&head, n2, entry, entries);/* Deletion. */
+free(n2);
+
+n3 = SLIST_FIRST(&head);
+SLIST_REMOVE_HEAD(&head, entries);	/* Deletion from the head. */
+free(n3);
+					/* Forward traversal. */
+SLIST_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+SLIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	SLIST_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+
+while (!SLIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = SLIST_FIRST(&head);
+	SLIST_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+.Ed
+.Sh SINGLY-LINKED TAIL QUEUES
+A singly-linked tail queue is headed by a structure defined by the
+.Nm STAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are singly linked for minimum space and pointer
+manipulation overhead at the expense of O(n) removal for arbitrary
+elements.
+New elements can be added to the tail queue after an existing element,
+at the head of the tail queue, or at the end of the tail queue.
+A
+.Fa STAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+STAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm STAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm STAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm STAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm STAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm STAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+.Pp
+The macro
+.Nm STAILQ_FOREACH_SAFE
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element
+in turn to
+.Fa var .
+However, unlike
+.Fn STAILQ_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm STAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm STAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm STAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm STAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm STAILQ_NEXT
+returns the next item on the tail queue, or NULL this item is the last.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_AFTER
+removes the element after
+.Fa elm
+from the tail queue. Unlike
+.Fa STAILQ_REMOVE ,
+this macro does not traverse the entire tail queue.
+.Pp
+The macro
+.Nm STAILQ_REMOVE_HEAD
+removes the element at the head of the tail queue.
+For optimum efficiency,
+elements being removed from the head of the tail queue should
+use this macro explicitly rather than the generic
+.Fa STAILQ_REMOVE
+macro.
+.Pp
+The macro
+.Nm STAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm STAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh SINGLY-LINKED TAIL QUEUE EXAMPLE
+.Bd -literal
+STAILQ_HEAD(stailhead, entry) head =
+    STAILQ_HEAD_INITIALIZER(head);
+struct stailhead *headp;		/* Singly-linked tail queue head. */
+struct entry {
+	...
+	STAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+STAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+STAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+STAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+STAILQ_INSERT_AFTER(&head, n1, n2, entries);
+					/* Deletion. */
+STAILQ_REMOVE(&head, n2, entry, entries);
+free(n2);
+					/* Deletion from the head. */
+n3 = STAILQ_FIRST(&head);
+STAILQ_REMOVE_HEAD(&head, entries);
+free(n3);
+					/* Forward traversal. */
+STAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+STAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	STAILQ_REMOVE(&head, np, entry, entries);
+	free(np);
+}
+					/* TailQ Deletion. */
+while (!STAILQ_EMPTY(&head)) {
+	n1 = STAILQ_FIRST(&head);
+	STAILQ_REMOVE_HEAD(&head, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = STAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = STAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+STAILQ_INIT(&head);
+.Ed
+.Sh LISTS
+A list is headed by a structure defined by the
+.Nm LIST_HEAD
+macro.
+This structure contains a single pointer to the first element
+on the list.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the list.
+New elements can be added to the list after an existing element,
+before an existing element, or at the head of the list.
+A
+.Fa LIST_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+LIST_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Fa HEADNAME
+is the name of the structure to be defined, and
+.Fa TYPE
+is the type of the elements to be linked into the list.
+A pointer to the head of the list can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm LIST_HEAD_INITIALIZER
+evaluates to an initializer for the list
+.Fa head .
+.Pp
+The macro
+.Nm LIST_EMPTY
+evaluates to true if there are no elements in the list.
+.Pp
+The macro
+.Nm LIST_ENTRY
+declares a structure that connects the elements in
+the list.
+.Pp
+The macro
+.Nm LIST_FIRST
+returns the first element in the list or NULL if the list
+is empty.
+.Pp
+The macro
+.Nm LIST_FOREACH
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macro
+.Nm LIST_FOREACH_SAFE
+traverses the list referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+However, unlike
+.Fn LIST_FOREACH
+here it is permitted to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm LIST_INIT
+initializes the list referenced by
+.Fa head .
+.Pp
+The macro
+.Nm LIST_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the list.
+.Pp
+The macro
+.Nm LIST_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm LIST_NEXT
+returns the next element in the list, or NULL if this is the last.
+.Pp
+The macro
+.Nm LIST_REMOVE
+removes the element
+.Fa elm
+from the list.
+.Pp
+The macro
+.Nm LIST_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh LIST EXAMPLE
+.Bd -literal
+LIST_HEAD(listhead, entry) head =
+    LIST_HEAD_INITIALIZER(head);
+struct listhead *headp;			/* List head. */
+struct entry {
+	...
+	LIST_ENTRY(entry) entries;	/* List. */
+	...
+} *n1, *n2, *n3, *np, *np_temp;
+
+LIST_INIT(&head);			/* Initialize the list. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+LIST_INSERT_HEAD(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+LIST_INSERT_AFTER(n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+LIST_INSERT_BEFORE(n2, n3, entries);
+
+LIST_REMOVE(n2, entries);		/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+LIST_FOREACH(np, &head, entries)
+	np-> ...
+
+					/* Safe forward traversal. */
+LIST_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	LIST_REMOVE(np, entries);
+	free(np);
+}
+
+while (!LIST_EMPTY(&head)) {		/* List Deletion. */
+	n1 = LIST_FIRST(&head);
+	LIST_REMOVE(n1, entries);
+	free(n1);
+}
+
+n1 = LIST_FIRST(&head);			/* Faster List Deletion. */
+while (n1 != NULL) {
+	n2 = LIST_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+LIST_INIT(&head);
+.Ed
+.Sh TAIL QUEUES
+A tail queue is headed by a structure defined by the
+.Nm TAILQ_HEAD
+macro.
+This structure contains a pair of pointers,
+one to the first element in the tail queue and the other to
+the last element in the tail queue.
+The elements are doubly linked so that an arbitrary element can be
+removed without traversing the tail queue.
+New elements can be added to the tail queue after an existing element,
+before an existing element, at the head of the tail queue,
+or at the end of the tail queue.
+A
+.Fa TAILQ_HEAD
+structure is declared as follows:
+.Bd -literal -offset indent
+TAILQ_HEAD(HEADNAME, TYPE) head;
+.Ed
+.Pp
+where
+.Li HEADNAME
+is the name of the structure to be defined, and
+.Li TYPE
+is the type of the elements to be linked into the tail queue.
+A pointer to the head of the tail queue can later be declared as:
+.Bd -literal -offset indent
+struct HEADNAME *headp;
+.Ed
+.Pp
+(The names
+.Li head
+and
+.Li headp
+are user selectable.)
+.Pp
+The macro
+.Nm TAILQ_HEAD_INITIALIZER
+evaluates to an initializer for the tail queue
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_CONCAT
+concatenates the tail queue headed by
+.Fa head2
+onto the end of the one headed by
+.Fa head1
+removing all entries from the former.
+.Pp
+The macro
+.Nm TAILQ_EMPTY
+evaluates to true if there are no items on the tail queue.
+.Pp
+The macro
+.Nm TAILQ_ENTRY
+declares a structure that connects the elements in
+the tail queue.
+.Pp
+The macro
+.Nm TAILQ_FIRST
+returns the first item on the tail queue or NULL if the tail queue
+is empty.
+.Pp
+The macro
+.Nm TAILQ_FOREACH
+traverses the tail queue referenced by
+.Fa head
+in the forward direction, assigning each element in turn to
+.Fa var .
+.Fa var
+is set to
+.Dv NULL
+if the loop completes normally, or if there were no elements.
+.Pp
+The macro
+.Nm TAILQ_FOREACH_REVERSE
+traverses the tail queue referenced by
+.Fa head
+in the reverse direction, assigning each element in turn to
+.Fa var .
+.Pp
+The macros
+.Nm TAILQ_FOREACH_SAFE
+and
+.Nm TAILQ_FOREACH_REVERSE_SAFE
+traverse the list referenced by
+.Fa head
+in the forward or reverse direction respectively,
+assigning each element in turn to
+.Fa var .
+However, unlike their unsafe counterparts,
+.Nm TAILQ_FOREACH
+and
+.Nm TAILQ_FOREACH_REVERSE
+permit to both remove
+.Fa var
+as well as free it from within the loop safely without interfering with the
+traversal.
+.Pp
+The macro
+.Nm TAILQ_INIT
+initializes the tail queue referenced by
+.Fa head .
+.Pp
+The macro
+.Nm TAILQ_INSERT_HEAD
+inserts the new element
+.Fa elm
+at the head of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_TAIL
+inserts the new element
+.Fa elm
+at the end of the tail queue.
+.Pp
+The macro
+.Nm TAILQ_INSERT_AFTER
+inserts the new element
+.Fa elm
+after the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_INSERT_BEFORE
+inserts the new element
+.Fa elm
+before the element
+.Fa listelm .
+.Pp
+The macro
+.Nm TAILQ_LAST
+returns the last item on the tail queue.
+If the tail queue is empty the return value is
+.Dv NULL .
+.Pp
+The macro
+.Nm TAILQ_NEXT
+returns the next item on the tail queue, or NULL if this item is the last.
+.Pp
+The macro
+.Nm TAILQ_PREV
+returns the previous item on the tail queue, or NULL if this item
+is the first.
+.Pp
+The macro
+.Nm TAILQ_REMOVE
+removes the element
+.Fa elm
+from the tail queue.
+.Pp
+The macro
+.Nm TAILQ_SWAP
+swaps the contents of
+.Fa head1
+and
+.Fa head2 .
+.Sh TAIL QUEUE EXAMPLE
+.Bd -literal
+TAILQ_HEAD(tailhead, entry) head =
+    TAILQ_HEAD_INITIALIZER(head);
+struct tailhead *headp;			/* Tail queue head. */
+struct entry {
+	...
+	TAILQ_ENTRY(entry) entries;	/* Tail queue. */
+	...
+} *n1, *n2, *n3, *np;
+
+TAILQ_INIT(&head);			/* Initialize the queue. */
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the head. */
+TAILQ_INSERT_HEAD(&head, n1, entries);
+
+n1 = malloc(sizeof(struct entry));	/* Insert at the tail. */
+TAILQ_INSERT_TAIL(&head, n1, entries);
+
+n2 = malloc(sizeof(struct entry));	/* Insert after. */
+TAILQ_INSERT_AFTER(&head, n1, n2, entries);
+
+n3 = malloc(sizeof(struct entry));	/* Insert before. */
+TAILQ_INSERT_BEFORE(n2, n3, entries);
+
+TAILQ_REMOVE(&head, n2, entries);	/* Deletion. */
+free(n2);
+					/* Forward traversal. */
+TAILQ_FOREACH(np, &head, entries)
+	np-> ...
+					/* Safe forward traversal. */
+TAILQ_FOREACH_SAFE(np, &head, entries, np_temp) {
+	np->do_stuff();
+	...
+	TAILQ_REMOVE(&head, np, entries);
+	free(np);
+}
+					/* Reverse traversal. */
+TAILQ_FOREACH_REVERSE(np, &head, tailhead, entries)
+	np-> ...
+					/* TailQ Deletion. */
+while (!TAILQ_EMPTY(&head)) {
+	n1 = TAILQ_FIRST(&head);
+	TAILQ_REMOVE(&head, n1, entries);
+	free(n1);
+}
+					/* Faster TailQ Deletion. */
+n1 = TAILQ_FIRST(&head);
+while (n1 != NULL) {
+	n2 = TAILQ_NEXT(n1, entries);
+	free(n1);
+	n1 = n2;
+}
+TAILQ_INIT(&head);
+.Ed
+.Sh SEE ALSO
+.Xr tree 3
+.Sh HISTORY
+The
+.Nm queue
+functions first appeared in
+.Bx 4.4 .
diff --git a/tools/libxl/external/bsd-sys-queue.h b/tools/libxl/external/bsd-sys-queue.h
new file mode 100644
index 0000000..274e636
--- /dev/null
+++ b/tools/libxl/external/bsd-sys-queue.h
@@ -0,0 +1,637 @@
+/*-
+ * Copyright (c) 1991, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 4. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ *	@(#)queue.h	8.5 (Berkeley) 8/20/94
+ * $FreeBSD$
+ */
+
+#ifndef _SYS_QUEUE_H_
+#define	_SYS_QUEUE_H_
+
+#include <sys/cdefs.h>
+
+/*
+ * This file defines four types of data structures: singly-linked lists,
+ * singly-linked tail queues, lists and tail queues.
+ *
+ * A singly-linked list is headed by a single forward pointer. The elements
+ * are singly linked for minimum space and pointer manipulation overhead at
+ * the expense of O(n) removal for arbitrary elements. New elements can be
+ * added to the list after an existing element or at the head of the list.
+ * Elements being removed from the head of the list should use the explicit
+ * macro for this purpose for optimum efficiency. A singly-linked list may
+ * only be traversed in the forward direction.  Singly-linked lists are ideal
+ * for applications with large datasets and few or no removals or for
+ * implementing a LIFO queue.
+ *
+ * A singly-linked tail queue is headed by a pair of pointers, one to the
+ * head of the list and the other to the tail of the list. The elements are
+ * singly linked for minimum space and pointer manipulation overhead at the
+ * expense of O(n) removal for arbitrary elements. New elements can be added
+ * to the list after an existing element, at the head of the list, or at the
+ * end of the list. Elements being removed from the head of the tail queue
+ * should use the explicit macro for this purpose for optimum efficiency.
+ * A singly-linked tail queue may only be traversed in the forward direction.
+ * Singly-linked tail queues are ideal for applications with large datasets
+ * and few or no removals or for implementing a FIFO queue.
+ *
+ * A list is headed by a single forward pointer (or an array of forward
+ * pointers for a hash table header). The elements are doubly linked
+ * so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before
+ * or after an existing element or at the head of the list. A list
+ * may only be traversed in the forward direction.
+ *
+ * A tail queue is headed by a pair of pointers, one to the head of the
+ * list and the other to the tail of the list. The elements are doubly
+ * linked so that an arbitrary element can be removed without a need to
+ * traverse the list. New elements can be added to the list before or
+ * after an existing element, at the head of the list, or at the end of
+ * the list. A tail queue may be traversed in either direction.
+ *
+ * For details on the use of these macros, see the queue(3) manual page.
+ *
+ *
+ *				SLIST	LIST	STAILQ	TAILQ
+ * _HEAD			+	+	+	+
+ * _HEAD_INITIALIZER		+	+	+	+
+ * _ENTRY			+	+	+	+
+ * _INIT			+	+	+	+
+ * _EMPTY			+	+	+	+
+ * _FIRST			+	+	+	+
+ * _NEXT			+	+	+	+
+ * _PREV			-	-	-	+
+ * _LAST			-	-	+	+
+ * _FOREACH			+	+	+	+
+ * _FOREACH_SAFE		+	+	+	+
+ * _FOREACH_REVERSE		-	-	-	+
+ * _FOREACH_REVERSE_SAFE	-	-	-	+
+ * _INSERT_HEAD			+	+	+	+
+ * _INSERT_BEFORE		-	+	-	+
+ * _INSERT_AFTER		+	+	+	+
+ * _INSERT_TAIL			-	-	+	+
+ * _CONCAT			-	-	+	+
+ * _REMOVE_AFTER		+	-	+	-
+ * _REMOVE_HEAD			+	-	+	-
+ * _REMOVE			+	+	+	+
+ * _SWAP			+	+	+	+
+ *
+ */
+#ifdef QUEUE_MACRO_DEBUG
+/* Store the last 2 places the queue element or head was altered */
+struct qm_trace {
+	char * lastfile;
+	int lastline;
+	char * prevfile;
+	int prevline;
+};
+
+#define	TRACEBUF	struct qm_trace trace;
+#define	TRASHIT(x)	do {(x) = (void *)-1;} while (0)
+#define	QMD_SAVELINK(name, link)	void **name = (void *)&(link)
+
+#define	QMD_TRACE_HEAD(head) do {					\
+	(head)->trace.prevline = (head)->trace.lastline;		\
+	(head)->trace.prevfile = (head)->trace.lastfile;		\
+	(head)->trace.lastline = __LINE__;				\
+	(head)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#define	QMD_TRACE_ELEM(elem) do {					\
+	(elem)->trace.prevline = (elem)->trace.lastline;		\
+	(elem)->trace.prevfile = (elem)->trace.lastfile;		\
+	(elem)->trace.lastline = __LINE__;				\
+	(elem)->trace.lastfile = __FILE__;				\
+} while (0)
+
+#else
+#define	QMD_TRACE_ELEM(elem)
+#define	QMD_TRACE_HEAD(head)
+#define	QMD_SAVELINK(name, link)
+#define	TRACEBUF
+#define	TRASHIT(x)
+#endif	/* QUEUE_MACRO_DEBUG */
+
+/*
+ * Singly-linked List declarations.
+ */
+#define	SLIST_HEAD(name, type)						\
+struct name {								\
+	struct type *slh_first;	/* first element */			\
+}
+
+#define	SLIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	SLIST_ENTRY(type)						\
+struct {								\
+	struct type *sle_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked List functions.
+ */
+#define	SLIST_EMPTY(head)	((head)->slh_first == NULL)
+
+#define	SLIST_FIRST(head)	((head)->slh_first)
+
+#define	SLIST_FOREACH(var, head, field)					\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var);							\
+	    (var) = SLIST_NEXT((var), field))
+
+#define	SLIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = SLIST_FIRST((head));				\
+	    (var) && ((tvar) = SLIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	SLIST_FOREACH_PREVPTR(var, varp, head, field)			\
+	for ((varp) = &SLIST_FIRST((head));				\
+	    ((var) = *(varp)) != NULL;					\
+	    (varp) = &SLIST_NEXT((var), field))
+
+#define	SLIST_INIT(head) do {						\
+	SLIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	SLIST_INSERT_AFTER(slistelm, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_NEXT((slistelm), field);	\
+	SLIST_NEXT((slistelm), field) = (elm);				\
+} while (0)
+
+#define	SLIST_INSERT_HEAD(head, elm, field) do {			\
+	SLIST_NEXT((elm), field) = SLIST_FIRST((head));			\
+	SLIST_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	SLIST_NEXT(elm, field)	((elm)->field.sle_next)
+
+#define	SLIST_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.sle_next);			\
+	if (SLIST_FIRST((head)) == (elm)) {				\
+		SLIST_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = SLIST_FIRST((head));		\
+		while (SLIST_NEXT(curelm, field) != (elm))		\
+			curelm = SLIST_NEXT(curelm, field);		\
+		SLIST_REMOVE_AFTER(curelm, field);			\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define SLIST_REMOVE_AFTER(elm, field) do {				\
+	SLIST_NEXT(elm, field) =					\
+	    SLIST_NEXT(SLIST_NEXT(elm, field), field);			\
+} while (0)
+
+#define	SLIST_REMOVE_HEAD(head, field) do {				\
+	SLIST_FIRST((head)) = SLIST_NEXT(SLIST_FIRST((head)), field);	\
+} while (0)
+
+#define SLIST_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = SLIST_FIRST(head1);			\
+	SLIST_FIRST(head1) = SLIST_FIRST(head2);			\
+	SLIST_FIRST(head2) = swap_first;				\
+} while (0)
+
+/*
+ * Singly-linked Tail queue declarations.
+ */
+#define	STAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *stqh_first;/* first element */			\
+	struct type **stqh_last;/* addr of last next element */		\
+}
+
+#define	STAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).stqh_first }
+
+#define	STAILQ_ENTRY(type)						\
+struct {								\
+	struct type *stqe_next;	/* next element */			\
+}
+
+/*
+ * Singly-linked Tail queue functions.
+ */
+#define	STAILQ_CONCAT(head1, head2) do {				\
+	if (!STAILQ_EMPTY((head2))) {					\
+		*(head1)->stqh_last = (head2)->stqh_first;		\
+		(head1)->stqh_last = (head2)->stqh_last;		\
+		STAILQ_INIT((head2));					\
+	}								\
+} while (0)
+
+#define	STAILQ_EMPTY(head)	((head)->stqh_first == NULL)
+
+#define	STAILQ_FIRST(head)	((head)->stqh_first)
+
+#define	STAILQ_FOREACH(var, head, field)				\
+	for((var) = STAILQ_FIRST((head));				\
+	   (var);							\
+	   (var) = STAILQ_NEXT((var), field))
+
+
+#define	STAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = STAILQ_FIRST((head));				\
+	    (var) && ((tvar) = STAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	STAILQ_INIT(head) do {						\
+	STAILQ_FIRST((head)) = NULL;					\
+	(head)->stqh_last = &STAILQ_FIRST((head));			\
+} while (0)
+
+#define	STAILQ_INSERT_AFTER(head, tqelm, elm, field) do {		\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_NEXT((tqelm), field)) == NULL)\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_NEXT((tqelm), field) = (elm);				\
+} while (0)
+
+#define	STAILQ_INSERT_HEAD(head, elm, field) do {			\
+	if ((STAILQ_NEXT((elm), field) = STAILQ_FIRST((head))) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+	STAILQ_FIRST((head)) = (elm);					\
+} while (0)
+
+#define	STAILQ_INSERT_TAIL(head, elm, field) do {			\
+	STAILQ_NEXT((elm), field) = NULL;				\
+	*(head)->stqh_last = (elm);					\
+	(head)->stqh_last = &STAILQ_NEXT((elm), field);			\
+} while (0)
+
+#define	STAILQ_LAST(head, type, field)					\
+	(STAILQ_EMPTY((head)) ?						\
+		NULL :							\
+	        ((struct type *)(void *)				\
+		((char *)((head)->stqh_last) - __offsetof(struct type, field))))
+
+#define	STAILQ_NEXT(elm, field)	((elm)->field.stqe_next)
+
+#define	STAILQ_REMOVE(head, elm, type, field) do {			\
+	QMD_SAVELINK(oldnext, (elm)->field.stqe_next);			\
+	if (STAILQ_FIRST((head)) == (elm)) {				\
+		STAILQ_REMOVE_HEAD((head), field);			\
+	}								\
+	else {								\
+		struct type *curelm = STAILQ_FIRST((head));		\
+		while (STAILQ_NEXT(curelm, field) != (elm))		\
+			curelm = STAILQ_NEXT(curelm, field);		\
+		STAILQ_REMOVE_AFTER(head, curelm, field);		\
+	}								\
+	TRASHIT(*oldnext);						\
+} while (0)
+
+#define STAILQ_REMOVE_AFTER(head, elm, field) do {			\
+	if ((STAILQ_NEXT(elm, field) =					\
+	     STAILQ_NEXT(STAILQ_NEXT(elm, field), field)) == NULL)	\
+		(head)->stqh_last = &STAILQ_NEXT((elm), field);		\
+} while (0)
+
+#define	STAILQ_REMOVE_HEAD(head, field) do {				\
+	if ((STAILQ_FIRST((head)) =					\
+	     STAILQ_NEXT(STAILQ_FIRST((head)), field)) == NULL)		\
+		(head)->stqh_last = &STAILQ_FIRST((head));		\
+} while (0)
+
+#define STAILQ_SWAP(head1, head2, type) do {				\
+	struct type *swap_first = STAILQ_FIRST(head1);			\
+	struct type **swap_last = (head1)->stqh_last;			\
+	STAILQ_FIRST(head1) = STAILQ_FIRST(head2);			\
+	(head1)->stqh_last = (head2)->stqh_last;			\
+	STAILQ_FIRST(head2) = swap_first;				\
+	(head2)->stqh_last = swap_last;					\
+	if (STAILQ_EMPTY(head1))					\
+		(head1)->stqh_last = &STAILQ_FIRST(head1);		\
+	if (STAILQ_EMPTY(head2))					\
+		(head2)->stqh_last = &STAILQ_FIRST(head2);		\
+} while (0)
+
+
+/*
+ * List declarations.
+ */
+#define	LIST_HEAD(name, type)						\
+struct name {								\
+	struct type *lh_first;	/* first element */			\
+}
+
+#define	LIST_HEAD_INITIALIZER(head)					\
+	{ NULL }
+
+#define	LIST_ENTRY(type)						\
+struct {								\
+	struct type *le_next;	/* next element */			\
+	struct type **le_prev;	/* address of previous next element */	\
+}
+
+/*
+ * List functions.
+ */
+
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_LIST_CHECK_HEAD(head, field) do {				\
+	if (LIST_FIRST((head)) != NULL &&				\
+	    LIST_FIRST((head))->field.le_prev !=			\
+	     &LIST_FIRST((head)))					\
+		panic("Bad list head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_NEXT(elm, field) do {				\
+	if (LIST_NEXT((elm), field) != NULL &&				\
+	    LIST_NEXT((elm), field)->field.le_prev !=			\
+	     &((elm)->field.le_next))					\
+	     	panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_LIST_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.le_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_LIST_CHECK_HEAD(head, field)
+#define	QMD_LIST_CHECK_NEXT(elm, field)
+#define	QMD_LIST_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	LIST_EMPTY(head)	((head)->lh_first == NULL)
+
+#define	LIST_FIRST(head)	((head)->lh_first)
+
+#define	LIST_FOREACH(var, head, field)					\
+	for ((var) = LIST_FIRST((head));				\
+	    (var);							\
+	    (var) = LIST_NEXT((var), field))
+
+#define	LIST_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = LIST_FIRST((head));				\
+	    (var) && ((tvar) = LIST_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	LIST_INIT(head) do {						\
+	LIST_FIRST((head)) = NULL;					\
+} while (0)
+
+#define	LIST_INSERT_AFTER(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_NEXT(listelm, field);				\
+	if ((LIST_NEXT((elm), field) = LIST_NEXT((listelm), field)) != NULL)\
+		LIST_NEXT((listelm), field)->field.le_prev =		\
+		    &LIST_NEXT((elm), field);				\
+	LIST_NEXT((listelm), field) = (elm);				\
+	(elm)->field.le_prev = &LIST_NEXT((listelm), field);		\
+} while (0)
+
+#define	LIST_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_LIST_CHECK_PREV(listelm, field);				\
+	(elm)->field.le_prev = (listelm)->field.le_prev;		\
+	LIST_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.le_prev = (elm);				\
+	(listelm)->field.le_prev = &LIST_NEXT((elm), field);		\
+} while (0)
+
+#define	LIST_INSERT_HEAD(head, elm, field) do {				\
+	QMD_LIST_CHECK_HEAD((head), field);				\
+	if ((LIST_NEXT((elm), field) = LIST_FIRST((head))) != NULL)	\
+		LIST_FIRST((head))->field.le_prev = &LIST_NEXT((elm), field);\
+	LIST_FIRST((head)) = (elm);					\
+	(elm)->field.le_prev = &LIST_FIRST((head));			\
+} while (0)
+
+#define	LIST_NEXT(elm, field)	((elm)->field.le_next)
+
+#define	LIST_REMOVE(elm, field) do {					\
+	QMD_SAVELINK(oldnext, (elm)->field.le_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.le_prev);			\
+	QMD_LIST_CHECK_NEXT(elm, field);				\
+	QMD_LIST_CHECK_PREV(elm, field);				\
+	if (LIST_NEXT((elm), field) != NULL)				\
+		LIST_NEXT((elm), field)->field.le_prev = 		\
+		    (elm)->field.le_prev;				\
+	*(elm)->field.le_prev = LIST_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+} while (0)
+
+#define LIST_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_tmp = LIST_FIRST((head1));			\
+	LIST_FIRST((head1)) = LIST_FIRST((head2));			\
+	LIST_FIRST((head2)) = swap_tmp;					\
+	if ((swap_tmp = LIST_FIRST((head1))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head1));		\
+	if ((swap_tmp = LIST_FIRST((head2))) != NULL)			\
+		swap_tmp->field.le_prev = &LIST_FIRST((head2));		\
+} while (0)
+
+/*
+ * Tail queue declarations.
+ */
+#define	TAILQ_HEAD(name, type)						\
+struct name {								\
+	struct type *tqh_first;	/* first element */			\
+	struct type **tqh_last;	/* addr of last next element */		\
+	TRACEBUF							\
+}
+
+#define	TAILQ_HEAD_INITIALIZER(head)					\
+	{ NULL, &(head).tqh_first }
+
+#define	TAILQ_ENTRY(type)						\
+struct {								\
+	struct type *tqe_next;	/* next element */			\
+	struct type **tqe_prev;	/* address of previous next element */	\
+	TRACEBUF							\
+}
+
+/*
+ * Tail queue functions.
+ */
+#if (defined(_KERNEL) && defined(INVARIANTS))
+#define	QMD_TAILQ_CHECK_HEAD(head, field) do {				\
+	if (!TAILQ_EMPTY(head) &&					\
+	    TAILQ_FIRST((head))->field.tqe_prev !=			\
+	     &TAILQ_FIRST((head)))					\
+		panic("Bad tailq head %p first->prev != head", (head));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_TAIL(head, field) do {				\
+	if (*(head)->tqh_last != NULL)					\
+	    	panic("Bad tailq NEXT(%p->tqh_last) != NULL", (head)); 	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_NEXT(elm, field) do {				\
+	if (TAILQ_NEXT((elm), field) != NULL &&				\
+	    TAILQ_NEXT((elm), field)->field.tqe_prev !=			\
+	     &((elm)->field.tqe_next))					\
+		panic("Bad link elm %p next->prev != elm", (elm));	\
+} while (0)
+
+#define	QMD_TAILQ_CHECK_PREV(elm, field) do {				\
+	if (*(elm)->field.tqe_prev != (elm))				\
+		panic("Bad link elm %p prev->next != elm", (elm));	\
+} while (0)
+#else
+#define	QMD_TAILQ_CHECK_HEAD(head, field)
+#define	QMD_TAILQ_CHECK_TAIL(head, headname)
+#define	QMD_TAILQ_CHECK_NEXT(elm, field)
+#define	QMD_TAILQ_CHECK_PREV(elm, field)
+#endif /* (_KERNEL && INVARIANTS) */
+
+#define	TAILQ_CONCAT(head1, head2, field) do {				\
+	if (!TAILQ_EMPTY(head2)) {					\
+		*(head1)->tqh_last = (head2)->tqh_first;		\
+		(head2)->tqh_first->field.tqe_prev = (head1)->tqh_last;	\
+		(head1)->tqh_last = (head2)->tqh_last;			\
+		TAILQ_INIT((head2));					\
+		QMD_TRACE_HEAD(head1);					\
+		QMD_TRACE_HEAD(head2);					\
+	}								\
+} while (0)
+
+#define	TAILQ_EMPTY(head)	((head)->tqh_first == NULL)
+
+#define	TAILQ_FIRST(head)	((head)->tqh_first)
+
+#define	TAILQ_FOREACH(var, head, field)					\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var);							\
+	    (var) = TAILQ_NEXT((var), field))
+
+#define	TAILQ_FOREACH_SAFE(var, head, field, tvar)			\
+	for ((var) = TAILQ_FIRST((head));				\
+	    (var) && ((tvar) = TAILQ_NEXT((var), field), 1);		\
+	    (var) = (tvar))
+
+#define	TAILQ_FOREACH_REVERSE(var, head, headname, field)		\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var);							\
+	    (var) = TAILQ_PREV((var), headname, field))
+
+#define	TAILQ_FOREACH_REVERSE_SAFE(var, head, headname, field, tvar)	\
+	for ((var) = TAILQ_LAST((head), headname);			\
+	    (var) && ((tvar) = TAILQ_PREV((var), headname, field), 1);	\
+	    (var) = (tvar))
+
+#define	TAILQ_INIT(head) do {						\
+	TAILQ_FIRST((head)) = NULL;					\
+	(head)->tqh_last = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+} while (0)
+
+#define	TAILQ_INSERT_AFTER(head, listelm, elm, field) do {		\
+	QMD_TAILQ_CHECK_NEXT(listelm, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_NEXT((listelm), field)) != NULL)\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    &TAILQ_NEXT((elm), field);				\
+	else {								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	TAILQ_NEXT((listelm), field) = (elm);				\
+	(elm)->field.tqe_prev = &TAILQ_NEXT((listelm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_BEFORE(listelm, elm, field) do {			\
+	QMD_TAILQ_CHECK_PREV(listelm, field);				\
+	(elm)->field.tqe_prev = (listelm)->field.tqe_prev;		\
+	TAILQ_NEXT((elm), field) = (listelm);				\
+	*(listelm)->field.tqe_prev = (elm);				\
+	(listelm)->field.tqe_prev = &TAILQ_NEXT((elm), field);		\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+	QMD_TRACE_ELEM(&listelm->field);				\
+} while (0)
+
+#define	TAILQ_INSERT_HEAD(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_HEAD(head, field);				\
+	if ((TAILQ_NEXT((elm), field) = TAILQ_FIRST((head))) != NULL)	\
+		TAILQ_FIRST((head))->field.tqe_prev =			\
+		    &TAILQ_NEXT((elm), field);				\
+	else								\
+		(head)->tqh_last = &TAILQ_NEXT((elm), field);		\
+	TAILQ_FIRST((head)) = (elm);					\
+	(elm)->field.tqe_prev = &TAILQ_FIRST((head));			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_INSERT_TAIL(head, elm, field) do {			\
+	QMD_TAILQ_CHECK_TAIL(head, field);				\
+	TAILQ_NEXT((elm), field) = NULL;				\
+	(elm)->field.tqe_prev = (head)->tqh_last;			\
+	*(head)->tqh_last = (elm);					\
+	(head)->tqh_last = &TAILQ_NEXT((elm), field);			\
+	QMD_TRACE_HEAD(head);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define	TAILQ_LAST(head, headname)					\
+	(*(((struct headname *)((head)->tqh_last))->tqh_last))
+
+#define	TAILQ_NEXT(elm, field) ((elm)->field.tqe_next)
+
+#define	TAILQ_PREV(elm, headname, field)				\
+	(*(((struct headname *)((elm)->field.tqe_prev))->tqh_last))
+
+#define	TAILQ_REMOVE(head, elm, field) do {				\
+	QMD_SAVELINK(oldnext, (elm)->field.tqe_next);			\
+	QMD_SAVELINK(oldprev, (elm)->field.tqe_prev);			\
+	QMD_TAILQ_CHECK_NEXT(elm, field);				\
+	QMD_TAILQ_CHECK_PREV(elm, field);				\
+	if ((TAILQ_NEXT((elm), field)) != NULL)				\
+		TAILQ_NEXT((elm), field)->field.tqe_prev = 		\
+		    (elm)->field.tqe_prev;				\
+	else {								\
+		(head)->tqh_last = (elm)->field.tqe_prev;		\
+		QMD_TRACE_HEAD(head);					\
+	}								\
+	*(elm)->field.tqe_prev = TAILQ_NEXT((elm), field);		\
+	TRASHIT(*oldnext);						\
+	TRASHIT(*oldprev);						\
+	QMD_TRACE_ELEM(&(elm)->field);					\
+} while (0)
+
+#define TAILQ_SWAP(head1, head2, type, field) do {			\
+	struct type *swap_first = (head1)->tqh_first;			\
+	struct type **swap_last = (head1)->tqh_last;			\
+	(head1)->tqh_first = (head2)->tqh_first;			\
+	(head1)->tqh_last = (head2)->tqh_last;				\
+	(head2)->tqh_first = swap_first;				\
+	(head2)->tqh_last = swap_last;					\
+	if ((swap_first = (head1)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head1)->tqh_first;	\
+	else								\
+		(head1)->tqh_last = &(head1)->tqh_first;		\
+	if ((swap_first = (head2)->tqh_first) != NULL)			\
+		swap_first->field.tqe_prev = &(head2)->tqh_first;	\
+	else								\
+		(head2)->tqh_last = &(head2)->tqh_first;		\
+} while (0)
+
+#endif /* !_SYS_QUEUE_H_ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZF-0003hk-N9; Mon, 28 Nov 2011 17:00:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZC-0003eJ-1S
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322499593!5382824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31696 invoked from network); 28 Nov 2011 16:59:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055r-Ke; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000ct-Gh;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:37 +0000
Message-ID: <1322499580-2322-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/13] libxl: make libxl__[v]log const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |    4 ++--
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d767ce3..ae28cb0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -179,7 +179,7 @@ char *libxl__dirname(libxl__gc *gc, const char *s)
 
 void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file, int line, const char *func,
-             char *fmt, va_list ap)
+             const char *fmt, va_list ap)
 {
     char *enomem = "[out of memory formatting log message]";
     char *base = NULL;
@@ -206,7 +206,7 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file, int line, const char *func,
-            char *fmt, ...)
+            const char *fmt, ...)
 {
     va_list ap;
     va_start(ap, fmt);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 41de6fd..1d1dc35 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -80,13 +80,13 @@
 _hidden void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file /* may be 0 */, int line /* ignored if !file */,
              const char *func /* may be 0 */,
-             char *fmt, va_list al)
+             const char *fmt, va_list al)
      __attribute__((format(printf,7,0)));
 
 _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file /* may be 0 */, int line /* ignored if !file */,
             const char *func /* may be 0 */,
-            char *fmt, ...)
+            const char *fmt, ...)
      __attribute__((format(printf,7,8)));
 
      /* these functions preserve errno (saving and restoring) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZF-0003hk-N9; Mon, 28 Nov 2011 17:00:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZC-0003eJ-1S
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322499593!5382824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31696 invoked from network); 28 Nov 2011 16:59:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169239"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055r-Ke; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000ct-Gh;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:37 +0000
Message-ID: <1322499580-2322-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/13] libxl: make libxl__[v]log const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.c |    4 ++--
 tools/libxl/libxl_internal.h |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d767ce3..ae28cb0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -179,7 +179,7 @@ char *libxl__dirname(libxl__gc *gc, const char *s)
 
 void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file, int line, const char *func,
-             char *fmt, va_list ap)
+             const char *fmt, va_list ap)
 {
     char *enomem = "[out of memory formatting log message]";
     char *base = NULL;
@@ -206,7 +206,7 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file, int line, const char *func,
-            char *fmt, ...)
+            const char *fmt, ...)
 {
     va_list ap;
     va_start(ap, fmt);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 41de6fd..1d1dc35 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -80,13 +80,13 @@
 _hidden void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
              const char *file /* may be 0 */, int line /* ignored if !file */,
              const char *func /* may be 0 */,
-             char *fmt, va_list al)
+             const char *fmt, va_list al)
      __attribute__((format(printf,7,0)));
 
 _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
             const char *file /* may be 0 */, int line /* ignored if !file */,
             const char *func /* may be 0 */,
-            char *fmt, ...)
+            const char *fmt, ...)
      __attribute__((format(printf,7,8)));
 
      /* these functions preserve errno (saving and restoring) */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZG-0003iL-LX; Mon, 28 Nov 2011 17:00:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZC-0003eH-3M
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29228 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055t-LF; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000d0-KC;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:38 +0000
Message-ID: <1322499580-2322-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/13] libxl: make libxl__free_all idempotent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ae28cb0..a2e5820 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -72,6 +72,8 @@ void libxl__free_all(libxl__gc *gc)
         free(ptr);
     }
     free(gc->alloc_ptrs);
+    gc->alloc_ptrs = 0;
+    gc->alloc_maxsize = 0;
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZG-0003iL-LX; Mon, 28 Nov 2011 17:00:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZC-0003eH-3M
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29228 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055t-LF; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000d0-KC;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:38 +0000
Message-ID: <1322499580-2322-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/13] libxl: make libxl__free_all idempotent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ae28cb0..a2e5820 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -72,6 +72,8 @@ void libxl__free_all(libxl__gc *gc)
         free(ptr);
     }
     free(gc->alloc_ptrs);
+    gc->alloc_ptrs = 0;
+    gc->alloc_maxsize = 0;
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZG-0003i3-7A; Mon, 28 Nov 2011 17:00:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZB-0003eG-Vg
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29210 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169237"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055i-GG; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cl-Eo;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:35 +0000
Message-ID: <1322499580-2322-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/13] libxl: Rationalise #includes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_internal.h now #includes libxl.h and various system headers.

This
 1. makes the order of header inclusion more predictable
 2. explicitly allows libxl_internal.h to use objects defined in libxl.h
 3. removes the need for individual files to include these headers

Also
 - remove some unnecessary #includes of libxl_utils.h,
   flexarray.h, etc. in some libxl*.c files,
 - include libxl_osdeps.h at the top of libxl_internal.h
 - add missing includes of libxl_osdeps.h to a couple of files
 - change libxl.h to libxl_internal.h in a couple of files

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c            |    3 ---
 tools/libxl/libxl_blktap2.c    |    1 -
 tools/libxl/libxl_bootloader.c |    4 ----
 tools/libxl/libxl_cpuid.c      |    4 ----
 tools/libxl/libxl_create.c     |    4 +---
 tools/libxl/libxl_device.c     |    1 -
 tools/libxl/libxl_dm.c         |    4 +---
 tools/libxl/libxl_dom.c        |    1 -
 tools/libxl/libxl_exec.c       |    1 -
 tools/libxl/libxl_flask.c      |    3 ++-
 tools/libxl/libxl_internal.c   |    4 ----
 tools/libxl/libxl_internal.h   |    5 +++++
 tools/libxl/libxl_json.c       |    3 ++-
 tools/libxl/libxl_noblktap2.c  |    2 --
 tools/libxl/libxl_nocpuid.c    |    2 +-
 tools/libxl/libxl_paths.c      |    2 +-
 tools/libxl/libxl_pci.c        |    5 -----
 tools/libxl/libxl_qmp.c        |    2 ++
 tools/libxl/libxl_utils.c      |    1 -
 tools/libxl/libxl_uuid.c       |    4 ++++
 tools/libxl/libxl_xshelp.c     |    1 -
 21 files changed, 19 insertions(+), 38 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a171142..bc17b15 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -31,10 +31,7 @@
 #include <inttypes.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PAGE_TO_MEMKB(pages) ((pages) * 4)
 #define BACKEND_STRING_SIZE 5
diff --git a/tools/libxl/libxl_blktap2.c b/tools/libxl/libxl_blktap2.c
index c8d9148..acf4110 100644
--- a/tools/libxl/libxl_blktap2.c
+++ b/tools/libxl/libxl_blktap2.c
@@ -12,7 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 9ca364e..75de288 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -14,7 +14,6 @@
 
 #include "libxl_osdeps.h"
 
-#include <string.h>
 #include <unistd.h>
 #include <fcntl.h>
 #include <termios.h>
@@ -22,11 +21,8 @@
 #include <sys/stat.h>
 #include <sys/types.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
-#include "flexarray.h"
-
 #define XENCONSOLED_BUF_SIZE 16
 #define BOOTLOADER_BUF_SIZE 4096
 #define BOOTLOADER_TIMEOUT 1
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 78bcab5..56a00cd 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -10,10 +10,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include <string.h>
-
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ab7d901..8e16ac4 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -26,10 +26,8 @@
 #include <xc_dom.h>
 #include <xenguest.h>
 #include <assert.h>
-#include "libxl.h"
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 void libxl_domain_config_dispose(libxl_domain_config *d_config)
 {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index a53fb70..46254ea 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -24,7 +24,6 @@
 #include <unistd.h>
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bf38877..2231f59 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -24,10 +24,8 @@
 #include <unistd.h>
 #include <fcntl.h>
 #include <assert.h>
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "libxl.h"
-#include "flexarray.h"
 
 static const char *libxl_tapif_script(libxl__gc *gc)
 {
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index d810655..68766af 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -32,7 +32,6 @@
 
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 1a62d47..52d40d1 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -28,7 +28,6 @@
 #include <signal.h> /* for SIGKILL */
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
diff --git a/tools/libxl/libxl_flask.c b/tools/libxl/libxl_flask.c
index c8d0594..6b548dd 100644
--- a/tools/libxl/libxl_flask.c
+++ b/tools/libxl/libxl_flask.c
@@ -7,13 +7,14 @@
  *  as published by the Free Software Foundation.
  */
 
+#include "libxl_osdeps.h"
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
 #include <xenctrl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 int libxl_flask_context_to_sid(libxl_ctx *ctx, char *buf, size_t len,
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..d767ce3 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -16,8 +16,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <stdarg.h>
-#include <string.h>
 
 #include <sys/types.h>
 #include <sys/stat.h>
@@ -25,9 +23,7 @@
 #include <sys/mman.h>
 #include <unistd.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
-#include "libxl_utils.h"
 
 int libxl__error_set(libxl__gc *gc, int code)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 950c466..cda6fc1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -17,14 +17,19 @@
 #ifndef LIBXL_INTERNAL_H
 #define LIBXL_INTERNAL_H
 
+#include "libxl_osdeps.h"
+
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <string.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include "libxl.h"
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
 #define _protected __attribute__((visibility("protected")))
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index fd5e2aa..c0f869e 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -12,6 +12,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <assert.h>
 #include <string.h>
 #include <math.h>
@@ -19,7 +21,6 @@
 #include <yajl/yajl_parse.h>
 #include <yajl/yajl_gen.h>
 
-#include <libxl.h>
 #include "libxl_internal.h"
 
 /* #define DEBUG_ANSWER */
diff --git a/tools/libxl/libxl_noblktap2.c b/tools/libxl/libxl_noblktap2.c
index 704d03f..3307551 100644
--- a/tools/libxl/libxl_noblktap2.c
+++ b/tools/libxl/libxl_noblktap2.c
@@ -12,8 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 int libxl__blktap_enabled(libxl__gc *gc)
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index d63757f..2e9490c 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -10,7 +10,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 
 void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
 {
diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index 64f662d..fa80056 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -12,7 +12,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 #include "_libxl_paths.h"
 
 const char *libxl_sbindir_path(void)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4186cf8..63c3050 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -17,7 +17,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <string.h>
 #include <stdlib.h>
 #include <sys/types.h>
 #include <fcntl.h>
@@ -27,15 +26,11 @@
 #include <sys/stat.h>
 #include <signal.h>
 #include <unistd.h> /* for write, unlink and close */
-#include <stdint.h>
 #include <inttypes.h>
 #include <dirent.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PCI_BDF                "%04x:%02x:%02x.%01x"
 #define PCI_BDF_SHORT          "%02x:%02x.%01x"
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..c7696d7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -18,6 +18,8 @@
  * Specification, see in the QEMU repository.
  */
 
+#include "libxl_osdeps.h"
+
 #include <unistd.h>
 #include <sys/un.h>
 #include <sys/queue.h>
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1fa2c0f..f1f2a6d 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -28,7 +28,6 @@
 #include <unistd.h>
 #include <assert.h>
 
-#include "libxl_utils.h"
 #include "libxl_internal.h"
 
 struct schedid_name {
diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
index e837228..80ab789 100644
--- a/tools/libxl/libxl_uuid.c
+++ b/tools/libxl/libxl_uuid.c
@@ -12,8 +12,12 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <libxl_uuid.h>
 
+#include "libxl_internal.h"
+
 #if defined(__linux__)
 
 int libxl_uuid_is_nil(libxl_uuid *uuid)
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index bc4e7e4..ea835e2 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -21,7 +21,6 @@
 #include <stdarg.h>
 #include <inttypes.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZG-0003i3-7A; Mon, 28 Nov 2011 17:00:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZB-0003eG-Vg
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29210 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169237"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055i-GG; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cl-Eo;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:35 +0000
Message-ID: <1322499580-2322-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 08/13] libxl: Rationalise #includes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

libxl_internal.h now #includes libxl.h and various system headers.

This
 1. makes the order of header inclusion more predictable
 2. explicitly allows libxl_internal.h to use objects defined in libxl.h
 3. removes the need for individual files to include these headers

Also
 - remove some unnecessary #includes of libxl_utils.h,
   flexarray.h, etc. in some libxl*.c files,
 - include libxl_osdeps.h at the top of libxl_internal.h
 - add missing includes of libxl_osdeps.h to a couple of files
 - change libxl.h to libxl_internal.h in a couple of files

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c            |    3 ---
 tools/libxl/libxl_blktap2.c    |    1 -
 tools/libxl/libxl_bootloader.c |    4 ----
 tools/libxl/libxl_cpuid.c      |    4 ----
 tools/libxl/libxl_create.c     |    4 +---
 tools/libxl/libxl_device.c     |    1 -
 tools/libxl/libxl_dm.c         |    4 +---
 tools/libxl/libxl_dom.c        |    1 -
 tools/libxl/libxl_exec.c       |    1 -
 tools/libxl/libxl_flask.c      |    3 ++-
 tools/libxl/libxl_internal.c   |    4 ----
 tools/libxl/libxl_internal.h   |    5 +++++
 tools/libxl/libxl_json.c       |    3 ++-
 tools/libxl/libxl_noblktap2.c  |    2 --
 tools/libxl/libxl_nocpuid.c    |    2 +-
 tools/libxl/libxl_paths.c      |    2 +-
 tools/libxl/libxl_pci.c        |    5 -----
 tools/libxl/libxl_qmp.c        |    2 ++
 tools/libxl/libxl_utils.c      |    1 -
 tools/libxl/libxl_uuid.c       |    4 ++++
 tools/libxl/libxl_xshelp.c     |    1 -
 21 files changed, 19 insertions(+), 38 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a171142..bc17b15 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -31,10 +31,7 @@
 #include <inttypes.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PAGE_TO_MEMKB(pages) ((pages) * 4)
 #define BACKEND_STRING_SIZE 5
diff --git a/tools/libxl/libxl_blktap2.c b/tools/libxl/libxl_blktap2.c
index c8d9148..acf4110 100644
--- a/tools/libxl/libxl_blktap2.c
+++ b/tools/libxl/libxl_blktap2.c
@@ -12,7 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
 #include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index 9ca364e..75de288 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -14,7 +14,6 @@
 
 #include "libxl_osdeps.h"
 
-#include <string.h>
 #include <unistd.h>
 #include <fcntl.h>
 #include <termios.h>
@@ -22,11 +21,8 @@
 #include <sys/stat.h>
 #include <sys/types.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
-#include "flexarray.h"
-
 #define XENCONSOLED_BUF_SIZE 16
 #define BOOTLOADER_BUF_SIZE 4096
 #define BOOTLOADER_TIMEOUT 1
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 78bcab5..56a00cd 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -10,10 +10,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include <string.h>
-
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 void libxl_cpuid_dispose(libxl_cpuid_policy_list *p_cpuid_list)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ab7d901..8e16ac4 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -26,10 +26,8 @@
 #include <xc_dom.h>
 #include <xenguest.h>
 #include <assert.h>
-#include "libxl.h"
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 void libxl_domain_config_dispose(libxl_domain_config *d_config)
 {
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index a53fb70..46254ea 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -24,7 +24,6 @@
 #include <unistd.h>
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bf38877..2231f59 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -24,10 +24,8 @@
 #include <unistd.h>
 #include <fcntl.h>
 #include <assert.h>
-#include "libxl_utils.h"
+
 #include "libxl_internal.h"
-#include "libxl.h"
-#include "flexarray.h"
 
 static const char *libxl_tapif_script(libxl__gc *gc)
 {
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index d810655..68766af 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -32,7 +32,6 @@
 
 #include <xen/hvm/hvm_info_table.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 1a62d47..52d40d1 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -28,7 +28,6 @@
 #include <signal.h> /* for SIGKILL */
 #include <fcntl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 static int call_waitpid(pid_t (*waitpid_cb)(pid_t, int *, int), pid_t pid, int *status, int options)
diff --git a/tools/libxl/libxl_flask.c b/tools/libxl/libxl_flask.c
index c8d0594..6b548dd 100644
--- a/tools/libxl/libxl_flask.c
+++ b/tools/libxl/libxl_flask.c
@@ -7,13 +7,14 @@
  *  as published by the Free Software Foundation.
  */
 
+#include "libxl_osdeps.h"
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
 #include <xenctrl.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 int libxl_flask_context_to_sid(libxl_ctx *ctx, char *buf, size_t len,
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..d767ce3 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -16,8 +16,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <stdarg.h>
-#include <string.h>
 
 #include <sys/types.h>
 #include <sys/stat.h>
@@ -25,9 +23,7 @@
 #include <sys/mman.h>
 #include <unistd.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
-#include "libxl_utils.h"
 
 int libxl__error_set(libxl__gc *gc, int code)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 950c466..cda6fc1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -17,14 +17,19 @@
 #ifndef LIBXL_INTERNAL_H
 #define LIBXL_INTERNAL_H
 
+#include "libxl_osdeps.h"
+
 #include <stdint.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#include <string.h>
 
 #include <xs.h>
 #include <xenctrl.h>
 #include "xentoollog.h"
 
+#include "libxl.h"
+
 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
 #define _hidden __attribute__((visibility("hidden")))
 #define _protected __attribute__((visibility("protected")))
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index fd5e2aa..c0f869e 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -12,6 +12,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <assert.h>
 #include <string.h>
 #include <math.h>
@@ -19,7 +21,6 @@
 #include <yajl/yajl_parse.h>
 #include <yajl/yajl_gen.h>
 
-#include <libxl.h>
 #include "libxl_internal.h"
 
 /* #define DEBUG_ANSWER */
diff --git a/tools/libxl/libxl_noblktap2.c b/tools/libxl/libxl_noblktap2.c
index 704d03f..3307551 100644
--- a/tools/libxl/libxl_noblktap2.c
+++ b/tools/libxl/libxl_noblktap2.c
@@ -12,8 +12,6 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
-#include "libxl_osdeps.h"
 #include "libxl_internal.h"
 
 int libxl__blktap_enabled(libxl__gc *gc)
diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c
index d63757f..2e9490c 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -10,7 +10,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 
 void libxl_cpuid_destroy(libxl_cpuid_policy_list *p_cpuid_list)
 {
diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index 64f662d..fa80056 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -12,7 +12,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl.h"
+#include "libxl_internal.h"
 #include "_libxl_paths.h"
 
 const char *libxl_sbindir_path(void)
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 4186cf8..63c3050 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -17,7 +17,6 @@
 #include "libxl_osdeps.h"
 
 #include <stdio.h>
-#include <string.h>
 #include <stdlib.h>
 #include <sys/types.h>
 #include <fcntl.h>
@@ -27,15 +26,11 @@
 #include <sys/stat.h>
 #include <signal.h>
 #include <unistd.h> /* for write, unlink and close */
-#include <stdint.h>
 #include <inttypes.h>
 #include <dirent.h>
 #include <assert.h>
 
-#include "libxl.h"
-#include "libxl_utils.h"
 #include "libxl_internal.h"
-#include "flexarray.h"
 
 #define PCI_BDF                "%04x:%02x:%02x.%01x"
 #define PCI_BDF_SHORT          "%02x:%02x.%01x"
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..c7696d7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -18,6 +18,8 @@
  * Specification, see in the QEMU repository.
  */
 
+#include "libxl_osdeps.h"
+
 #include <unistd.h>
 #include <sys/un.h>
 #include <sys/queue.h>
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 1fa2c0f..f1f2a6d 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -28,7 +28,6 @@
 #include <unistd.h>
 #include <assert.h>
 
-#include "libxl_utils.h"
 #include "libxl_internal.h"
 
 struct schedid_name {
diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
index e837228..80ab789 100644
--- a/tools/libxl/libxl_uuid.c
+++ b/tools/libxl/libxl_uuid.c
@@ -12,8 +12,12 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h"
+
 #include <libxl_uuid.h>
 
+#include "libxl_internal.h"
+
 #if defined(__linux__)
 
 int libxl_uuid_is_nil(libxl_uuid *uuid)
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index bc4e7e4..ea835e2 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -21,7 +21,6 @@
 #include <stdarg.h>
 #include <inttypes.h>
 
-#include "libxl.h"
 #include "libxl_internal.h"
 
 char **libxl__xs_kvs_of_flexarray(libxl__gc *gc, flexarray_t *array, int length)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZH-0003if-2H; Mon, 28 Nov 2011 17:00:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZC-0003eK-7M
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322499593!3418460!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7449 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055k-HK; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cp-G5;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:36 +0000
Message-ID: <1322499580-2322-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/13] libxl: introduce lock in libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This lock will be used to protect data structures which will be hung
off the libxl_ctx in subsequent patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    6 ++++++
 tools/libxl/libxl_internal.h |   27 +++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bc17b15..7488538 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 {
     libxl_ctx *ctx;
     struct stat stat_buf;
+    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
 
     if (version != LIBXL_VERSION)
         return ERROR_VERSION;
@@ -54,6 +55,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
+    /* This somewhat convoluted approach is needed because
+     * PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is defined to be valid
+     * only as an initialiser, not as an expression. */
+    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index cda6fc1..41de6fd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -23,6 +23,7 @@
 #include <stdarg.h>
 #include <stdlib.h>
 #include <string.h>
+#include <pthread.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -95,6 +96,18 @@ struct libxl__ctx {
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    pthread_mutex_t lock; /* protects data structures hanging off the ctx */
+      /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
+       *
+       * You may acquire this mutex recursively if it is convenient to
+       * do so.  You may not acquire this lock at the same time as any
+       * other lock.  If you need to call application code outside
+       * libxl (ie, a callback) with this lock held then it is
+       * necessaray to impose restrictions on the caller to maintain a
+       * proper lock hierarchy, and these restrictions must then be
+       * documented in the libxl public interface.
+       */
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -668,6 +681,20 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 #define CTX           libxl__gc_owner(gc)
 
 
+/* Locking functions.  See comment for "lock" member of libxl__ctx. */
+
+#define CTX_LOCK do {                                   \
+        int mutex_r = pthread_mutex_lock(&CTX->lock);   \
+        assert(!mutex_r);                               \
+    } while(0)
+
+#define CTX_UNLOCK do {                                 \
+        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
+        assert(!mutex_r);                               \
+    } while(0)
+        
+
+
 /*
  * Inserts "elm_new" into the sorted list "head".
  *
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZH-0003if-2H; Mon, 28 Nov 2011 17:00:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZC-0003eK-7M
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322499593!3418460!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7449 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:51 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055k-HK; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000cp-G5;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:36 +0000
Message-ID: <1322499580-2322-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/13] libxl: introduce lock in libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This lock will be used to protect data structures which will be hung
off the libxl_ctx in subsequent patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |    6 ++++++
 tools/libxl/libxl_internal.h |   27 +++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index bc17b15..7488538 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -41,6 +41,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 {
     libxl_ctx *ctx;
     struct stat stat_buf;
+    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
 
     if (version != LIBXL_VERSION)
         return ERROR_VERSION;
@@ -54,6 +55,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     memset(ctx, 0, sizeof(libxl_ctx));
     ctx->lg = lg;
 
+    /* This somewhat convoluted approach is needed because
+     * PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is defined to be valid
+     * only as an initialiser, not as an expression. */
+    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index cda6fc1..41de6fd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -23,6 +23,7 @@
 #include <stdarg.h>
 #include <stdlib.h>
 #include <string.h>
+#include <pthread.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -95,6 +96,18 @@ struct libxl__ctx {
     xc_interface *xch;
     struct xs_handle *xsh;
 
+    pthread_mutex_t lock; /* protects data structures hanging off the ctx */
+      /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
+       *
+       * You may acquire this mutex recursively if it is convenient to
+       * do so.  You may not acquire this lock at the same time as any
+       * other lock.  If you need to call application code outside
+       * libxl (ie, a callback) with this lock held then it is
+       * necessaray to impose restrictions on the caller to maintain a
+       * proper lock hierarchy, and these restrictions must then be
+       * documented in the libxl public interface.
+       */
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -668,6 +681,20 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 #define CTX           libxl__gc_owner(gc)
 
 
+/* Locking functions.  See comment for "lock" member of libxl__ctx. */
+
+#define CTX_LOCK do {                                   \
+        int mutex_r = pthread_mutex_lock(&CTX->lock);   \
+        assert(!mutex_r);                               \
+    } while(0)
+
+#define CTX_UNLOCK do {                                 \
+        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
+        assert(!mutex_r);                               \
+    } while(0)
+        
+
+
 /*
  * Inserts "elm_new" into the sorted list "head".
  *
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZI-0003je-3D; Mon, 28 Nov 2011 17:00:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZC-0003eM-Dt
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322499593!3418460!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7465 invoked from network); 28 Nov 2011 16:59:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055u-Lq; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000e6-Kt;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:39 +0000
Message-ID: <1322499580-2322-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/13] libxl: New API for providing OS events to
	libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We provide a new set of functions and related structures
  libxl_osevent_*
which are to be used by event-driven applications to receive
information from libxl about which fds libxl is interested in, and
what timeouts libxl is waiting for, and to pass back to libxl
information about which fds are readable/writeable etc., and which
timeouts have occurred.  Ie, low-level events.

In this patch, this new machinery is still all unused.  Callers will
appear in the next patch in the series, which introduces a new API for
applications to receive high-level events about actual domains etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |   25 ++
 tools/libxl/libxl.h          |    6 +
 tools/libxl/libxl_event.c    |  704 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  199 ++++++++++++
 tools/libxl/libxl_internal.h |  213 +++++++++++++-
 6 files changed, 1145 insertions(+), 4 deletions(-)
 create mode 100644 tools/libxl/libxl_event.c
 create mode 100644 tools/libxl/libxl_event.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 4e0f3fb..3d575b8 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -38,7 +38,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7488538..b977f7c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -60,6 +60,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    ctx->osevent_hooks = 0;
+
+    ctx->fd_beforepolled = 0;
+    LIBXL_LIST_INIT(&ctx->efds);
+    LIBXL_TAILQ_INIT(&ctx->etimes);
+
+    ctx->watch_slots = 0;
+    LIBXL_SLIST_INIT(&ctx->watch_freeslots);
+    libxl__ev_fd_init(&ctx->watch_efd);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -89,10 +99,25 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
 int libxl_ctx_free(libxl_ctx *ctx)
 {
+    int i;
+    GC_INIT(ctx);
+
     if (!ctx) return 0;
+
+    for (i = 0; i < ctx->watch_nslots; i++)
+        assert(!libxl__watch_slot_contents(gc, i));
+    libxl__ev_fd_deregister(gc, &ctx->watch_efd);
+
+    assert(LIBXL_LIST_EMPTY(&ctx->efds));
+    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
+
     if (ctx->xch) xc_interface_close(ctx->xch);
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
+
+    free(ctx->fd_beforepolled);
+    free(ctx->watch_slots);
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6ce3d83..13baa1b 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -137,6 +137,7 @@
 #include <xen/sysctl.h>
 
 #include <libxl_uuid.h>
+#include <_libxl_list.h>
 
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
@@ -222,6 +223,9 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOT_READY = -10,
+    ERROR_OSEVENT_REG_FAIL = -11,
+    ERROR_BUFFERFULL = -12,
 };
 
 #define LIBXL_VERSION 0
@@ -634,6 +638,8 @@ const char *libxl_xen_script_dir_path(void);
 const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 
+#include <libxl_event.h>
+
 #endif /* LIBXL_H */
 
 /*
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
new file mode 100644
index 0000000..b2377ea
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,704 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal event machinery for use by other parts of libxl
+ */
+
+#include <poll.h>
+
+#include "libxl_internal.h"
+
+#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
+    (CTX->osevent_hooks                                                 \
+     ? (CTX->osevent_in_hook++,                                         \
+        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
+        CTX->osevent_in_hook--)                                         \
+     : defval)
+
+#define OSEVENT_HOOK(hookname,...)                      \
+    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
+
+#define OSEVENT_HOOK_VOID(hookname,...)                 \
+    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)
+
+/*
+ * fd events
+ */
+
+int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
+                          libxl__ev_fd_callback *func,
+                          int fd, short events) {
+    int rc;
+
+    assert(fd >= 0);
+
+    CTX_LOCK;
+
+    rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev);
+    if (rc) goto out;
+
+    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
+
+    ev->fd = fd;
+    ev->events = events;
+    ev->in_beforepolled = -1;
+    ev->func = func;
+
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_fd_modify(libxl__gc *gc, libxl__ev_fd *ev, short events) {
+    int rc;
+
+    CTX_LOCK;
+    assert(libxl__ev_fd_isregistered(ev));
+
+    rc = OSEVENT_HOOK(fd_modify, ev->fd, &ev->for_app_reg, events);
+    if (rc) goto out;
+
+    ev->events = events;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd *ev) {
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(ev))
+        goto out;
+
+    OSEVENT_HOOK_VOID(fd_deregister, ev->fd, ev->for_app_reg);
+    LIBXL_LIST_REMOVE(ev, entry);
+    ev->fd = -1;
+
+    if (ev->in_beforepolled >= 0 &&
+        ev->in_beforepolled < CTX->fd_beforepolled_used)
+        /* remove stale reference */
+        CTX->fd_beforepolled[ev->in_beforepolled] = NULL;
+
+ out:
+    CTX_UNLOCK;
+}
+
+/*
+ * timeouts
+ */
+
+
+int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r) {
+    int rc = gettimeofday(now_r, 0);
+    if (rc) {
+        LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "gettimeofday failed");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+static int time_rel_to_abs(libxl__gc *gc, int ms, struct timeval *abs_out) {
+    int rc;
+    struct timeval additional = {
+        .tv_sec = ms / 1000,
+        .tv_usec = (ms % 1000) * 1000
+    };
+    struct timeval now;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) return rc;
+
+    timeradd(&now, &additional, abs_out);
+    return 0;
+}
+
+static void time_insert_finite(libxl__gc *gc, libxl__ev_time *ev) {
+    libxl__ev_time *evsearch;
+    LIBXL_TAILQ_INSERT_SORTED(&CTX->etimes, entry, ev, evsearch, ,
+                              timercmp(&ev->abs, &evsearch->abs, >));
+    ev->infinite = 0;
+}
+
+static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
+                                struct timeval abs) {
+    int rc;
+    
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    if (rc) return rc;
+
+    ev->infinite = 0;
+    ev->abs = abs;
+    time_insert_finite(gc, ev);
+
+    return 0;
+}
+
+static void time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
+    if (!ev->infinite) {
+        OSEVENT_HOOK_VOID(timeout_deregister, &ev->for_app_reg);
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    }
+}
+    
+
+int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                struct timeval abs) {
+    int rc;
+    
+    CTX_LOCK;
+
+    rc = time_register_finite(gc, ev, abs);
+    if (rc) goto out;
+
+    ev->func = func;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+
+int libxl__ev_time_register_rel(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                int milliseconds /* as for poll(2) */) {
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    if (milliseconds < 0) {
+        ev->infinite = 1;
+    } else {
+        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        if (rc) goto out;
+
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    }
+
+    ev->func = func;
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return 0;
+}
+
+int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
+                              struct timeval abs) {
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (ev->infinite) {
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    } else {
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        if (rc) goto out;
+
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+        ev->abs = abs;
+        time_insert_finite(gc, ev);
+    }
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
+                              int milliseconds) {
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (milliseconds < 0) {
+        time_deregister(gc, ev);
+        ev->infinite = 1;
+        rc = 0;
+        goto out;
+    }
+
+    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    if (rc) goto out;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return 0;
+}
+
+void libxl__ev_time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
+    CTX_LOCK;
+
+    if (!libxl__ev_time_isregistered(ev))
+        goto out;
+        
+    time_deregister(gc, ev);
+    ev->func = 0;
+
+ out:
+    CTX_UNLOCK;
+    return;
+}
+
+
+/*
+ * xenstore watches
+ */
+
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum) {
+    libxl__ev_watch_slot *slot = &CTX->watch_slots[slotnum];
+    libxl__ev_watch_slot *slotcontents = LIBXL_SLIST_NEXT(slot, empty);
+
+    if (slotcontents == NULL ||
+        ((uintptr_t)slotcontents >= (uintptr_t)CTX->watch_slots &&
+         (uintptr_t)slotcontents < (uintptr_t)(CTX->watch_slots +
+                                               CTX->watch_nslots)))
+        /* An empty slot has either a NULL pointer (end of the
+         * free list), or a pointer to another entry in the array.
+         * So we can do a bounds check to distinguish empty from
+         * full slots.
+         */
+        /* We need to do the comparisons as uintptr_t because
+         * comparing pointers which are not in the same object is
+         * undefined behaviour; if the compiler managed to figure
+         * out that watch_slots[0..watch_nslots-1] is all of the
+         * whole array object it could prove that the above bounds
+         * check was always true if it was legal, and remove it!
+         *
+         * uintptr_t because even on a machine with signed
+         * pointers, objects do not cross zero; whereas on
+         * machines with unsigned pointers, they may cross
+         * 0x8bazillion.
+         */
+        return NULL;
+
+        /* see comment near libxl__ev_watch_slot definition */
+    return (void*)slotcontents;
+}
+
+static void watchfd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                             int fd, short events, short revents) {
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(gc, "cannot check/read watches", errno, 0);
+            return;
+        }
+
+        const char *epath = event[0];
+        const char *token = event[1];
+        int slotnum;
+        uint32_t counterval;
+        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);
+        if (rc != 2) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "watch epath=%s token=%s: failed to parse token",
+                       epath, token);
+            /* oh well */
+            goto ignore;
+        }
+        if (slotnum < 0 || slotnum >= CTX->watch_nslots) {
+            /* perhaps in the future we will make the watchslots array shrink */
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "watch epath=%s token=%s:"
+                       " slotnum %d out of range [0,%d>",
+                       epath, token, slotnum, CTX->watch_nslots);
+            goto ignore;
+        }
+
+        libxl__ev_xswatch *w = libxl__watch_slot_contents(gc, slotnum);
+
+        if (!w) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: empty slot",
+                       epath, token);
+            goto ignore;
+        }
+        
+        if (w->counterval != counterval) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: counter != %"PRIx32,
+                       epath, token, w->counterval);
+            goto ignore;
+        }
+
+        /* Now it's possible, though unlikely, that this was an event
+         * from a previous use of the same slot with the same counterval.
+         *
+         * In that case either:
+         *  - the event path is a child of the watch path, in
+         *    which case this watch would really have generated this
+         *    event if it had been registered soon enough and we are
+         *    OK to give this possibly-spurious event to the caller; or
+         * - it is not, in which case we must suppress it as the
+         *   caller should not see events for unrelated paths.
+         *
+         * See also docs/misc/xenstore.txt.
+         */
+        size_t epathlen = strlen(epath);
+        size_t wpathlen = strlen(w->path);
+        if (epathlen < wpathlen ||
+            memcmp(epath, w->path, wpathlen) ||
+            (epathlen > wpathlen && epath[wpathlen] != '/')) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: not child of wpath=%s",
+                       epath, token, w->path);
+            goto ignore;
+        }
+
+        /* At last, we have checked everything! */
+        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                   "watch event: epath=%s token=%s wpath=%s w=%p",
+                   epath, token, w->path, w);
+        w->callback(gc, w, w->path, epath);
+
+    ignore:
+        free(event);
+    }
+}
+
+static char *watch_token(libxl__gc *gc, int slotnum, uint32_t counterval) {
+    return libxl__sprintf(gc, "%d/%"PRIx32, slotnum, counterval);
+}
+
+int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
+                               libxl__ev_xswatch_callback *func,
+                               const char *path /* copied */) {
+    libxl__ev_watch_slot *use = NULL;
+    char *path_copy = NULL;
+    int rc;
+
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(&CTX->watch_efd)) {
+        rc = libxl__ev_fd_register(gc, &CTX->watch_efd, watchfd_callback,
+                                   xs_fileno(CTX->xsh), POLLIN);
+        if (rc) goto out_rc;
+    }
+
+    if (LIBXL_SLIST_EMPTY(&CTX->watch_freeslots)) {
+        /* Free list is empty so there is not in fact a linked
+         * free list in the array and we can safely realloc it */
+        int newarraysize = (CTX->watch_nslots + 1) << 2;
+        int i;
+        libxl__ev_watch_slot *newarray =
+            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
+        if (!newarray) goto out_nomem;
+        for (i=CTX->watch_nslots; i<newarraysize; i++)
+            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
+                                    &newarray[i], empty);
+        CTX->watch_slots = newarray;
+        CTX->watch_nslots = newarraysize;
+    }
+    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
+    assert(use);
+    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
+
+    path_copy = strdup(path);
+    if (!path_copy) goto out_nomem;
+
+    int slotnum = use - CTX->watch_slots;
+    w->counterval = CTX->watch_counter++;
+
+    rc = xs_watch(CTX->xsh, path, watch_token(gc, slotnum, w->counterval));
+    if (rc) {
+        LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                            "create watch for path %s", path);
+        rc = ERROR_FAIL;
+        goto out_rc;
+    }
+
+    w->slotnum = slotnum;
+    w->path = path_copy;
+    w->callback = func;
+    /* we look a bit behind the curtain of LIBXL_SLIST, to explictly
+     * assign to the pointer that's the next link.  See the comment
+     * by the definitionn of libxl__ev_watch_slot */
+    use->empty.sle_next = (void*)w;
+
+    CTX_UNLOCK;
+    return 0;
+
+ out_nomem:
+    rc = ERROR_NOMEM;
+ out_rc:
+    if (use)
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
+    if (path_copy)
+        free(path_copy);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w) {
+    /* it is legal to deregister from within _callback */
+    CTX_LOCK;
+
+    if (w->slotnum >= 0) {
+        char *token = watch_token(gc, w->slotnum, w->counterval);
+        int rc = xs_unwatch(CTX->xsh, w->path, token);
+        if (rc)
+            /* Oh well, we will just get watch events forever more
+             * and ignore them.  But we should complain to the log. */
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                                "remove watch for path %s", w->path);
+
+        libxl__ev_watch_slot *slot = &CTX->watch_slots[w->slotnum];
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, slot, empty);
+    }
+
+    free(w->path);
+    w->path = NULL;
+
+    CTX_UNLOCK;
+}
+
+/*
+ * osevent poll
+ */
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now) {
+    libxl__ev_fd *efd;
+    int i;
+
+    /*
+     * In order to be able to efficiently find the libxl__ev_fd
+     * for a struct poll during _afterpoll, we maintain a shadow
+     * data structure in CTX->fd_beforepolled: each slot in
+     * the fds array corresponds to a slot in fd_beforepolled.
+     */
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    if (*nfds_io) {
+        /*
+         * As an optimisation, we don't touch fd_beforepolled_used
+         * if *nfds_io is zero on entry, since in that case the
+         * caller just wanted to know how big an array to give us.
+         *
+         * If !*nfds_io, the unconditional parts below are guaranteed
+         * not to mess with fd_beforepolled... or any in_beforepolled.
+         */
+
+        /* Remove all the old references into beforepolled */
+        for (i = 0; i < CTX->fd_beforepolled_used; i++) {
+            efd = CTX->fd_beforepolled[i];
+            if (efd) {
+                assert(efd->in_beforepolled == i);
+                efd->in_beforepolled = -1;
+                CTX->fd_beforepolled[i] = NULL;
+            }
+        }
+        CTX->fd_beforepolled_used = 0;
+
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_beforepolled_allocd < *nfds_io) {
+            assert(*nfds_io < INT_MAX / sizeof(libxl__ev_fd*) / 2);
+            libxl__ev_fd **newarray =
+                realloc(CTX->fd_beforepolled, sizeof(*newarray) * *nfds_io);
+            if (!newarray)
+                return ERROR_NOMEM;
+            CTX->fd_beforepolled = newarray;
+            CTX->fd_beforepolled_allocd = *nfds_io;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            CTX->fd_beforepolled[used] = efd;
+            efd->in_beforepolled = used;
+        }
+        used++;
+    }
+    int rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    if (*nfds_io) {
+        CTX->fd_beforepolled_used = used;
+    }
+
+    *nfds_io = used;
+
+    libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+    if (etime) {
+        int our_timeout;
+        struct timeval rel;
+        static struct timeval zero;
+
+        timersub(&etime->abs, &now, &rel);
+
+        if (timercmp(&rel, &zero, <)) {
+            our_timeout = 0;
+        } else if (rel.tv_sec >= 2000000) {
+            our_timeout = 2000000000;
+        } else {
+            our_timeout = rel.tv_sec * 1000 + (rel.tv_usec + 999) / 1000;
+        }
+        if (*timeout_upd < 0 || our_timeout < *timeout_upd)
+            *timeout_upd = our_timeout;
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now) {
+    int i;
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(nfds <= CTX->fd_beforepolled_used);
+
+    for (i = 0; i < nfds; i++) {
+        if (!fds[i].revents)
+            continue;
+
+        libxl__ev_fd *efd = CTX->fd_beforepolled[i];
+        if (!efd)
+            continue;
+
+        assert(efd->in_beforepolled == i);
+        assert(fds[i].fd == efd->fd);
+
+        int revents = fds[i].revents & efd->events;
+        if (!revents)
+            continue;
+
+        efd->func(gc, efd, efd->fd, efd->events, revents);
+    }
+
+    for (;;) {
+        libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+        if (!etime)
+            break;
+
+        assert(!etime->infinite);
+
+        if (timercmp(&etime->abs, &now, >))
+            break;
+
+        time_deregister(gc, etime);
+
+        etime->func(gc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+/*
+ * osevent hook and callback machinery
+ */
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    ctx->osevent_hooks = hooks;
+    ctx->osevent_user = user;
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents) {
+    libxl__ev_fd *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(gc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl) {
+    libxl__ev_time *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(gc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line) {
+    libxl__log(CTX, XTL_CRITICAL, errnoval, file, line,
+               "DISASTER in event loop: %s%s%s%s",
+               msg,
+               type ? " (relates to event type " : "",
+               type ? libxl_event_type_to_string(type) : "",
+               type ? ")" : "");
+
+    /*
+     * FIXME: This should call the "disaster" hook supplied to
+     * libxl_event_register_callbacks, which will be introduced in the
+     * next patch.
+     */
+
+    const char verybad[] =
+        "DISASTER in event loop not handled by libxl application";
+    LIBXL__LOG(CTX, XTL_CRITICAL, verybad);
+    fprintf(stderr, "libxl: fatal error, exiting program: %s\n", verybad);
+    exit(-1);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
new file mode 100644
index 0000000..25efbdf
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,199 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ * Author Ian Jackson <ian.jackson@eu.citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_EVENT_H
+#define LIBXL_EVENT_H
+
+#include <libxl.h>
+
+
+/*======================================================================*/
+
+/*
+ * OS event handling - passing low-level OS events to libxl
+ *
+ * Event-driven programs must use these facilities to allow libxl
+ * to become aware of readability/writeability of file descriptors
+ * and the occurrence of timeouts.
+ *
+ * There are two approaches available.  The first is appropriate for
+ * simple programs handling reasonably small numbers of domains:
+ *
+ *   for (;;) {
+ *      libxl_osevent_beforepoll(...)
+ *      poll();
+ *      libxl_osevent_afterpoll(...);
+ *      for (;;) {
+ *        r=libxl_event_check(...);
+ *        if (r==LIBXL_NOT_READY) break;
+ *        if (r) handle failure;
+ *        do something with the event;
+ *      }
+ *   }
+ *
+ * The second approach uses libxl_osevent_register_hooks and is
+ * suitable for programs which are already using a callback-based
+ * event library.
+ *
+ * An application may freely mix the two styles of interaction.
+ */
+
+struct pollfd;
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now);
+  /* The caller should provide beforepoll with some space for libxl's
+   * fds, and tell libxl how much space is available by setting *nfds_io.
+   * fds points to the start of this space (and fds may be a pointer into
+   * a larger array, for example, if the application has some fds of
+   * its own that it is interested in).
+   *
+   * On return *nfds_io will in any case have been updated by libxl
+   * according to how many fds libxl wants to poll on.
+   *
+   * If the space was sufficient, libxl fills in fds[0..<new
+   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
+   * and returns ok.
+   *
+   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
+   * return; *nfds_io on return will be greater than the value on
+   * entry; *timeout_upd may or may not have been updated; and
+   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
+   * the application needs to make more space (enough space for
+   * *nfds_io struct pollfd) and then call beforepoll again, before
+   * entering poll(2).  Typically this will involve calling realloc.
+   *
+   * The application may call beforepoll with fds==NULL and
+   * *nfds_io==0 in order to find out how much space is needed.
+   *
+   * *timeout_upd is as for poll(2): it's in milliseconds, and
+   * negative values mean no timeout (infinity).
+   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
+   */
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now);
+  /* nfds and fds[0..nfds] must be from the most recent call to
+   * _beforepoll, as modified by poll.
+   *
+   * This function actually performs all of the IO and other actions,
+   * and generates events (libxl_event), which are implied by either
+   * (a) the time of day or (b) both (i) the returned information from
+   * _beforepoll, and (ii) the results from poll specified in
+   * fds[0..nfds-1].  Generated events can then be retrieved by
+   * libxl_event_check.
+   */
+
+
+typedef struct libxl_osevent_hooks {
+  int (*fd_register)(void *user, int fd, void **for_app_registration_out,
+                     short events, void *for_libxl);
+  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
+                   short events);
+  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
+  int (*timeout_register)(void *user, void **for_app_registration_out,
+                          struct timeval abs, void *for_libxl);
+  int (*timeout_modify)(void *user, void **for_app_registration_update,
+                         struct timeval abs);
+  void (*timeout_deregister)(void *user, void *for_app_registration_io);
+} libxl_osevent_hooks;
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user);
+  /* The application which calls register_fd_hooks promises to
+   * maintain a register of fds and timeouts that libxl is interested
+   * in, and make calls into libxl (libxl_osevent_occurred_*)
+   * when those fd events and timeouts occur.  This is more efficient
+   * than _beforepoll/_afterpoll if there are many fds (which can
+   * happen if the same libxl application is managing many domains).
+   *
+   * For an fd event, events is as for poll().  register or modify may
+   * be called with events==0, in which case it must still work
+   * normally, just not generate any events.
+   *
+   * For a timeout event, milliseconds is as for poll().
+   * Specifically, negative values of milliseconds mean NO TIMEOUT.
+   * This is used by libxl to temporarily disable a timeout.
+   *
+   * If the register or modify hook succeeds it may update
+   * *for_app_registration_out/_update and must then return 0.
+   * On entry to register, *for_app_registration_out is always NULL.
+   *
+   * A registration or modification hook may fail, in which case it
+   * must leave the registration state of the fd or timeout unchanged.
+   * It may then either return ERROR_OSEVENT_REG_FAIL or any positive
+   * int.  The value returned will be passed up through libxl and
+   * eventually returned back to the application.  When register
+   * fails, any value stored into *for_registration_out is ignored by
+   * libxl; when modify fails, any changed value stored into
+   * *for_registration_update is honoured by libxl and will be passed
+   * to future modify or deregister calls.
+   *
+   * libxl will only attempt to register one callback for any one fd.
+   * libxl will remember the value stored in *for_app_registration_io
+   * by a successful call to register or modify and pass it into
+   * subsequent calls to modify or deregister.
+   *
+   * register_fd_hooks may be called only once for each libxl_ctx.
+   * libxl may make calls to register/modify/deregister from within
+   * any libxl function (indeed, it will usually call register from
+   * register_event_hooks).  Conversely, the application MUST NOT make
+   * the event occurrence calls (libxl_osevent_occurred_*) into libxl
+   * reentrantly from within libxl (for example, from within the
+   * register/modify functions).
+   *
+   * Lock hierarchy: the register/modify/deregister functions may be
+   * called with locks held.  These locks (the "libxl internal locks")
+   * are inside the libxl_ctx.  Therefore, if those register functions
+   * acquire any locks of their own ("caller register locks") outside
+   * libxl, to avoid deadlock one of the following must hold for each
+   * such caller register lock:
+   *  (a) "acquire libxl internal locks before caller register lock":
+   *      No libxl function may be called with the caller register
+   *      lock held.
+   *  (b) "acquire caller register lock before libxl internal locks":
+   *      No libxl function may be called _without_ the caller
+   *      register lock held.
+   * Of these we would normally recommend (a).
+   *
+   * The value *hooks is not copied and must outlast the libxl_ctx.
+   */
+
+/* It is NOT legal to call _occurred_ reentrantly within any libxl
+ * function.  Specifically it is NOT legal to call it from within
+ * a register callback.  Conversely, libxl MAY call register/deregister
+ * from within libxl_event_registered_call_*.
+ */
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents);
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+  /* Implicitly, on entry to this function the timeout has been
+   * deregistered.  If _occurred_timeout is called, libxl will not
+   * call timeout_deregister; if it wants to requeue the timeout it
+   * will call timeout_register again.
+   */
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1d1dc35..3e461fa 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -24,6 +24,9 @@
 #include <stdlib.h>
 #include <string.h>
 #include <pthread.h>
+#include <inttypes.h>
+#include <assert.h>
+#include <sys/poll.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -91,6 +94,66 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
      /* these functions preserve errno (saving and restoring) */
 
+typedef struct libxl__gc libxl__gc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* all private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    int fd;
+    short events;
+    int in_beforepolled; /* -1 means not in fd_beforepolled */
+    void *for_app_reg;
+    libxl__ev_fd_callback *func;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__gc *gc, libxl__ev_time *ev,
+                                     const struct timeval *requested_abs);
+struct libxl__ev_time {
+    /* all private for libxl__ev_time... */
+    int infinite; /* not registered in list or with app if infinite */
+    LIBXL_TAILQ_ENTRY(libxl__ev_time) entry;
+    struct timeval abs;
+    void *for_app_reg;
+    libxl__ev_time_callback *func;
+};
+
+typedef struct libxl__ev_xswatch libxl__ev_xswatch;
+typedef void libxl__ev_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+struct libxl__ev_xswatch {
+    /* caller should include this in their own struct */
+    /* contents are private to xswatch_register */
+    int slotnum;
+    uint32_t counterval;
+    char *path;
+    libxl__ev_xswatch_callback *callback;
+};
+
+/*
+ * An entry in the watch_slots table is either:
+ *  1. an entry in the free list, ie NULL or pointer to next free list entry
+ *  2. an pointer to a libxl__ev_xswatch
+ *
+ * But we don't want to use unions or type-punning because the
+ * compiler might "prove" that our code is wrong and misoptimise it.
+ *
+ * The rules say that all struct pointers have identical
+ * representation and alignment requirements (C99+TC1+TC2 6.2.5p26) so
+ * what we do is simply declare our array as containing only the free
+ * list pointers, and explicitly convert from and to our actual
+ * xswatch pointers when we store and retrieve them.
+ */
+typedef struct libxl__ev_watch_slot {
+    LIBXL_SLIST_ENTRY(struct libxl__ev_watch_slot) empty;
+} libxl__ev_watch_slot;
+    
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
@@ -108,6 +171,21 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    int osevent_in_hook;
+    const libxl_osevent_hooks *osevent_hooks;
+    void *osevent_user;
+
+    int fd_beforepolled_allocd, fd_beforepolled_used;
+    libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
+    LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
+    LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
+
+    libxl__ev_watch_slot *watch_slots;
+    int watch_nslots;
+    LIBXL_SLIST_HEAD(, libxl__ev_watch_slot) watch_freeslots;
+    uint32_t watch_counter; /* helps disambiguate slot reuse */
+    libxl__ev_fd watch_efd;
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -138,12 +216,12 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-typedef struct {
+struct libxl__gc {
     /* mini-GC */
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
-} libxl__gc;
+};
 
 #define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
@@ -204,9 +282,136 @@ _hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
                                    const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
-
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Event generation functions provided by the libxl event core to the
+ * rest of libxl.  Implemented in terms of _beforepoll/_afterpoll
+ * and/or the fd registration machinery, as provided by the
+ * application.
+ *
+ * Semantics are similar to those of the fd and timeout registration
+ * functions provided to libxl_osevent_register_hooks.
+ *
+ * Non-0 returns from libxl__ev_{modify,deregister} have already been
+ * logged by the core and should be returned unmodified to libxl's
+ * caller; NB that they may be valid libxl error codes but they may
+ * also be positive numbers supplied by the caller.
+ *
+ * In each case, there is a libxl__ev_FOO structure which can be in
+ * one of three states:
+ *
+ *   Undefined   - Might contain anything.  All-bits-zero is
+ *                 an undefined state.
+ *
+ *   Idle        - Struct contents are defined enough to pass to any
+ *                 libxl__ev_FOO function but not registered and
+ *                 callback will not be called.  The struct does not
+ *                 contain references to any allocated resources so
+ *                 can be thrown away.
+ *
+ *   Active      - Request for events has been registered and events
+ *                 may be generated.  _deregister must be called to
+ *                 reclaim resources.
+ *
+ * These functions are provided for each kind of event KIND:
+ *
+ *   int libxl__ev_KIND_register(libxl__gc *gc, libxl__ev_KIND *GEN,
+ *                              libxl__ev_KIND_callback *FUNC,
+ *                              DETAILS);
+ *      On entry *GEN must be in state Undefined or Idle.
+ *      Returns a libxl error code; on error return *GEN is Idle.
+ *      On successful return *GEN is Active and FUNC wil be
+ *      called by the event machinery in future.  FUNC will
+ *      not be called from within the call to _register.
+ *
+ *  void libxl__ev_KIND_deregister(libxl__gc *gc, libxl__ev_KIND *GEN_upd);
+ *      On entry *GEN must be in state Active or Idle.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  void libxl__ev_KIND_init(libxl__ev_KIND *GEN);
+ *      Provided for initialising an Undefined KIND.
+ *      On entry *GEN must be in state Idle or Undefined.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  int libxl__ev_KIND_isregistered(const libxl__ev_KIND *GEN);
+ *      On entry *GEN must be Idle or Active.
+ *      Returns nonzero if it is Active, zero otherwise.
+ *      Cannot fail.
+ *
+ *  int libxl__ev_KiND_modify(libxl__gc*, libxl__ev_KIND *GEN,
+ *                            DETAILS);
+ *      Only provided for some kinds of generator.
+ *      On entry *GEN must be Active and on return, whether successful
+ *      or not, it will be Active.
+ *      Returns a libxl error code; on error the modification
+ *      is not effective.
+ *
+ * All of these functions are fully threadsafe and may be called by
+ * general code in libxl even from within event callback FUNCs.
+ */
+
+
+_hidden int libxl__ev_fd_register(libxl__gc*, libxl__ev_fd *ev_out,
+                                  libxl__ev_fd_callback*,
+                                  int fd, short events /* as for poll(2) */);
+_hidden int libxl__ev_fd_modify(libxl__gc*, libxl__ev_fd *ev,
+                                short events);
+_hidden void libxl__ev_fd_deregister(libxl__gc*, libxl__ev_fd *ev);
+static inline void libxl__ev_fd_init(libxl__ev_fd *efd)
+                    { efd->fd = -1; }
+static inline int libxl__ev_fd_isregistered(libxl__ev_fd *efd)
+                    { return efd->fd >= 0; }
+
+_hidden int libxl__ev_time_register_rel(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_register_abs(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        struct timeval);
+_hidden int libxl__ev_time_modify_rel(libxl__gc*, libxl__ev_time *ev,
+                                      int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_modify_abs(libxl__gc*, libxl__ev_time *ev,
+                                      struct timeval);
+_hidden void libxl__ev_time_deregister(libxl__gc*, libxl__ev_time *ev);
+static inline void libxl__ev_time_init(libxl__ev_time *ev)
+                { ev->func = 0; }
+static inline int libxl__ev_time_isregistered(libxl__ev_time *ev)
+                { return !!ev->func; }
+
+
+_hidden int libxl__ev_xswatch_register(libxl__gc*, libxl__ev_xswatch *xsw_out,
+                                       libxl__ev_xswatch_callback*,
+                                       const char *path /* copied */);
+_hidden void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch*);
+
+static inline void libxl__ev_xswatch_init(libxl__ev_xswatch *xswatch_out)
+                { xswatch_out->slotnum = -1; }
+static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
+                { return xw->slotnum >= 0; }
+
+
+
+_hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
+                                   libxl_event_type type /* may be 0 */,
+                                   const char *file, int line);
+  /*
+   * In general, call this via the macro LIBXL__EVENT_DISASTER.
+   *
+   * Event-generating functions may call this if they might have
+   * wanted to generate an event (either an internal one ie a
+   * libxl__ev_FOO_callback or an application event), but are
+   * prevented from doing so due to eg lack of memory.
+   *
+   * NB that this function may return and the caller isn't supposed to
+   * then crash, although it may fail (and henceforth leave things in
+   * a state where many or all calls fail).
+   */
+#define LIBXL__EVENT_DISASTER(gc, msg, errnoval, type) \
+    libxl__event_disaster(gc, msg, errnoval, type, __FILE__, __LINE__)
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -531,6 +736,8 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
 _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b);
 
+_hidden int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r);
+
 #define STRINGIFY(x) #x
 #define TOSTRING(x) STRINGIFY(x)
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZI-0003je-3D; Mon, 28 Nov 2011 17:00:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZC-0003eM-Dt
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322499593!3418460!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7465 invoked from network); 28 Nov 2011 16:59:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055u-Lq; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000e6-Kt;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:39 +0000
Message-ID: <1322499580-2322-13-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/13] libxl: New API for providing OS events to
	libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We provide a new set of functions and related structures
  libxl_osevent_*
which are to be used by event-driven applications to receive
information from libxl about which fds libxl is interested in, and
what timeouts libxl is waiting for, and to pass back to libxl
information about which fds are readable/writeable etc., and which
timeouts have occurred.  Ie, low-level events.

In this patch, this new machinery is still all unused.  Callers will
appear in the next patch in the series, which introduces a new API for
applications to receive high-level events about actual domains etc.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/Makefile         |    2 +-
 tools/libxl/libxl.c          |   25 ++
 tools/libxl/libxl.h          |    6 +
 tools/libxl/libxl_event.c    |  704 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  199 ++++++++++++
 tools/libxl/libxl_internal.h |  213 +++++++++++++-
 6 files changed, 1145 insertions(+), 4 deletions(-)
 create mode 100644 tools/libxl/libxl_event.c
 create mode 100644 tools/libxl/libxl_event.h

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 4e0f3fb..3d575b8 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -38,7 +38,7 @@ LIBXL_LIBS += -lyajl
 LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
 			libxl_internal.o libxl_utils.o libxl_uuid.o libxl_json.o \
-			libxl_qmp.o $(LIBXL_OBJS-y)
+			libxl_qmp.o libxl_event.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
 $(LIBXL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenguest) $(CFLAGS_libxenstore) $(CFLAGS_libblktapctl)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 7488538..b977f7c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -60,6 +60,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
      * only as an initialiser, not as an expression. */
     memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
 
+    ctx->osevent_hooks = 0;
+
+    ctx->fd_beforepolled = 0;
+    LIBXL_LIST_INIT(&ctx->efds);
+    LIBXL_TAILQ_INIT(&ctx->etimes);
+
+    ctx->watch_slots = 0;
+    LIBXL_SLIST_INIT(&ctx->watch_freeslots);
+    libxl__ev_fd_init(&ctx->watch_efd);
+
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
                      "failed to stat %s", XENSTORE_PID_FILE);
@@ -89,10 +99,25 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
 int libxl_ctx_free(libxl_ctx *ctx)
 {
+    int i;
+    GC_INIT(ctx);
+
     if (!ctx) return 0;
+
+    for (i = 0; i < ctx->watch_nslots; i++)
+        assert(!libxl__watch_slot_contents(gc, i));
+    libxl__ev_fd_deregister(gc, &ctx->watch_efd);
+
+    assert(LIBXL_LIST_EMPTY(&ctx->efds));
+    assert(LIBXL_TAILQ_EMPTY(&ctx->etimes));
+
     if (ctx->xch) xc_interface_close(ctx->xch);
     libxl_version_info_dispose(&ctx->version_info);
     if (ctx->xsh) xs_daemon_close(ctx->xsh);
+
+    free(ctx->fd_beforepolled);
+    free(ctx->watch_slots);
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6ce3d83..13baa1b 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -137,6 +137,7 @@
 #include <xen/sysctl.h>
 
 #include <libxl_uuid.h>
+#include <_libxl_list.h>
 
 typedef uint8_t libxl_mac[6];
 #define LIBXL_MAC_FMT "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx"
@@ -222,6 +223,9 @@ enum {
     ERROR_BADFAIL = -7,
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
+    ERROR_NOT_READY = -10,
+    ERROR_OSEVENT_REG_FAIL = -11,
+    ERROR_BUFFERFULL = -12,
 };
 
 #define LIBXL_VERSION 0
@@ -634,6 +638,8 @@ const char *libxl_xen_script_dir_path(void);
 const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 
+#include <libxl_event.h>
+
 #endif /* LIBXL_H */
 
 /*
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
new file mode 100644
index 0000000..b2377ea
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,704 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+/*
+ * Internal event machinery for use by other parts of libxl
+ */
+
+#include <poll.h>
+
+#include "libxl_internal.h"
+
+#define OSEVENT_HOOK_INTERN(defval, hookname, ...)                      \
+    (CTX->osevent_hooks                                                 \
+     ? (CTX->osevent_in_hook++,                                         \
+        CTX->osevent_hooks->hookname(CTX->osevent_user, __VA_ARGS__),   \
+        CTX->osevent_in_hook--)                                         \
+     : defval)
+
+#define OSEVENT_HOOK(hookname,...)                      \
+    OSEVENT_HOOK_INTERN(0, hookname, __VA_ARGS__)
+
+#define OSEVENT_HOOK_VOID(hookname,...)                 \
+    OSEVENT_HOOK_INTERN((void)0, hookname, __VA_ARGS__)
+
+/*
+ * fd events
+ */
+
+int libxl__ev_fd_register(libxl__gc *gc, libxl__ev_fd *ev,
+                          libxl__ev_fd_callback *func,
+                          int fd, short events) {
+    int rc;
+
+    assert(fd >= 0);
+
+    CTX_LOCK;
+
+    rc = OSEVENT_HOOK(fd_register, fd, &ev->for_app_reg, events, ev);
+    if (rc) goto out;
+
+    LIBXL_LIST_INSERT_HEAD(&CTX->efds, ev, entry);
+
+    ev->fd = fd;
+    ev->events = events;
+    ev->in_beforepolled = -1;
+    ev->func = func;
+
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_fd_modify(libxl__gc *gc, libxl__ev_fd *ev, short events) {
+    int rc;
+
+    CTX_LOCK;
+    assert(libxl__ev_fd_isregistered(ev));
+
+    rc = OSEVENT_HOOK(fd_modify, ev->fd, &ev->for_app_reg, events);
+    if (rc) goto out;
+
+    ev->events = events;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd *ev) {
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(ev))
+        goto out;
+
+    OSEVENT_HOOK_VOID(fd_deregister, ev->fd, ev->for_app_reg);
+    LIBXL_LIST_REMOVE(ev, entry);
+    ev->fd = -1;
+
+    if (ev->in_beforepolled >= 0 &&
+        ev->in_beforepolled < CTX->fd_beforepolled_used)
+        /* remove stale reference */
+        CTX->fd_beforepolled[ev->in_beforepolled] = NULL;
+
+ out:
+    CTX_UNLOCK;
+}
+
+/*
+ * timeouts
+ */
+
+
+int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r) {
+    int rc = gettimeofday(now_r, 0);
+    if (rc) {
+        LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "gettimeofday failed");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
+static int time_rel_to_abs(libxl__gc *gc, int ms, struct timeval *abs_out) {
+    int rc;
+    struct timeval additional = {
+        .tv_sec = ms / 1000,
+        .tv_usec = (ms % 1000) * 1000
+    };
+    struct timeval now;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) return rc;
+
+    timeradd(&now, &additional, abs_out);
+    return 0;
+}
+
+static void time_insert_finite(libxl__gc *gc, libxl__ev_time *ev) {
+    libxl__ev_time *evsearch;
+    LIBXL_TAILQ_INSERT_SORTED(&CTX->etimes, entry, ev, evsearch, ,
+                              timercmp(&ev->abs, &evsearch->abs, >));
+    ev->infinite = 0;
+}
+
+static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
+                                struct timeval abs) {
+    int rc;
+    
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    if (rc) return rc;
+
+    ev->infinite = 0;
+    ev->abs = abs;
+    time_insert_finite(gc, ev);
+
+    return 0;
+}
+
+static void time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
+    if (!ev->infinite) {
+        OSEVENT_HOOK_VOID(timeout_deregister, &ev->for_app_reg);
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    }
+}
+    
+
+int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                struct timeval abs) {
+    int rc;
+    
+    CTX_LOCK;
+
+    rc = time_register_finite(gc, ev, abs);
+    if (rc) goto out;
+
+    ev->func = func;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+
+int libxl__ev_time_register_rel(libxl__gc *gc, libxl__ev_time *ev,
+                                libxl__ev_time_callback *func,
+                                int milliseconds /* as for poll(2) */) {
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    if (milliseconds < 0) {
+        ev->infinite = 1;
+    } else {
+        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        if (rc) goto out;
+
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    }
+
+    ev->func = func;
+    rc = 0;
+
+ out:
+    CTX_UNLOCK;
+    return 0;
+}
+
+int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
+                              struct timeval abs) {
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (ev->infinite) {
+        rc = time_register_finite(gc, ev, abs);
+        if (rc) goto out;
+    } else {
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        if (rc) goto out;
+
+        LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+        ev->abs = abs;
+        time_insert_finite(gc, ev);
+    }
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return rc;
+}
+
+int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
+                              int milliseconds) {
+    struct timeval abs;
+    int rc;
+
+    CTX_LOCK;
+
+    assert(libxl__ev_time_isregistered(ev));
+
+    if (milliseconds < 0) {
+        time_deregister(gc, ev);
+        ev->infinite = 1;
+        rc = 0;
+        goto out;
+    }
+
+    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    if (rc) goto out;
+
+    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    if (rc) goto out;
+
+    rc = 0;
+ out:
+    CTX_UNLOCK;
+    return 0;
+}
+
+void libxl__ev_time_deregister(libxl__gc *gc, libxl__ev_time *ev) {
+    CTX_LOCK;
+
+    if (!libxl__ev_time_isregistered(ev))
+        goto out;
+        
+    time_deregister(gc, ev);
+    ev->func = 0;
+
+ out:
+    CTX_UNLOCK;
+    return;
+}
+
+
+/*
+ * xenstore watches
+ */
+
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum) {
+    libxl__ev_watch_slot *slot = &CTX->watch_slots[slotnum];
+    libxl__ev_watch_slot *slotcontents = LIBXL_SLIST_NEXT(slot, empty);
+
+    if (slotcontents == NULL ||
+        ((uintptr_t)slotcontents >= (uintptr_t)CTX->watch_slots &&
+         (uintptr_t)slotcontents < (uintptr_t)(CTX->watch_slots +
+                                               CTX->watch_nslots)))
+        /* An empty slot has either a NULL pointer (end of the
+         * free list), or a pointer to another entry in the array.
+         * So we can do a bounds check to distinguish empty from
+         * full slots.
+         */
+        /* We need to do the comparisons as uintptr_t because
+         * comparing pointers which are not in the same object is
+         * undefined behaviour; if the compiler managed to figure
+         * out that watch_slots[0..watch_nslots-1] is all of the
+         * whole array object it could prove that the above bounds
+         * check was always true if it was legal, and remove it!
+         *
+         * uintptr_t because even on a machine with signed
+         * pointers, objects do not cross zero; whereas on
+         * machines with unsigned pointers, they may cross
+         * 0x8bazillion.
+         */
+        return NULL;
+
+        /* see comment near libxl__ev_watch_slot definition */
+    return (void*)slotcontents;
+}
+
+static void watchfd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                             int fd, short events, short revents) {
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(gc, "cannot check/read watches", errno, 0);
+            return;
+        }
+
+        const char *epath = event[0];
+        const char *token = event[1];
+        int slotnum;
+        uint32_t counterval;
+        int rc = sscanf(token, "%d/%"SCNx32, &slotnum, &counterval);
+        if (rc != 2) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "watch epath=%s token=%s: failed to parse token",
+                       epath, token);
+            /* oh well */
+            goto ignore;
+        }
+        if (slotnum < 0 || slotnum >= CTX->watch_nslots) {
+            /* perhaps in the future we will make the watchslots array shrink */
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "watch epath=%s token=%s:"
+                       " slotnum %d out of range [0,%d>",
+                       epath, token, slotnum, CTX->watch_nslots);
+            goto ignore;
+        }
+
+        libxl__ev_xswatch *w = libxl__watch_slot_contents(gc, slotnum);
+
+        if (!w) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: empty slot",
+                       epath, token);
+            goto ignore;
+        }
+        
+        if (w->counterval != counterval) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: counter != %"PRIx32,
+                       epath, token, w->counterval);
+            goto ignore;
+        }
+
+        /* Now it's possible, though unlikely, that this was an event
+         * from a previous use of the same slot with the same counterval.
+         *
+         * In that case either:
+         *  - the event path is a child of the watch path, in
+         *    which case this watch would really have generated this
+         *    event if it had been registered soon enough and we are
+         *    OK to give this possibly-spurious event to the caller; or
+         * - it is not, in which case we must suppress it as the
+         *   caller should not see events for unrelated paths.
+         *
+         * See also docs/misc/xenstore.txt.
+         */
+        size_t epathlen = strlen(epath);
+        size_t wpathlen = strlen(w->path);
+        if (epathlen < wpathlen ||
+            memcmp(epath, w->path, wpathlen) ||
+            (epathlen > wpathlen && epath[wpathlen] != '/')) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                       "watch epath=%s token=%s: not child of wpath=%s",
+                       epath, token, w->path);
+            goto ignore;
+        }
+
+        /* At last, we have checked everything! */
+        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG,
+                   "watch event: epath=%s token=%s wpath=%s w=%p",
+                   epath, token, w->path, w);
+        w->callback(gc, w, w->path, epath);
+
+    ignore:
+        free(event);
+    }
+}
+
+static char *watch_token(libxl__gc *gc, int slotnum, uint32_t counterval) {
+    return libxl__sprintf(gc, "%d/%"PRIx32, slotnum, counterval);
+}
+
+int libxl__ev_xswatch_register(libxl__gc *gc, libxl__ev_xswatch *w,
+                               libxl__ev_xswatch_callback *func,
+                               const char *path /* copied */) {
+    libxl__ev_watch_slot *use = NULL;
+    char *path_copy = NULL;
+    int rc;
+
+    CTX_LOCK;
+
+    if (!libxl__ev_fd_isregistered(&CTX->watch_efd)) {
+        rc = libxl__ev_fd_register(gc, &CTX->watch_efd, watchfd_callback,
+                                   xs_fileno(CTX->xsh), POLLIN);
+        if (rc) goto out_rc;
+    }
+
+    if (LIBXL_SLIST_EMPTY(&CTX->watch_freeslots)) {
+        /* Free list is empty so there is not in fact a linked
+         * free list in the array and we can safely realloc it */
+        int newarraysize = (CTX->watch_nslots + 1) << 2;
+        int i;
+        libxl__ev_watch_slot *newarray =
+            realloc(CTX->watch_slots, sizeof(*newarray) * newarraysize);
+        if (!newarray) goto out_nomem;
+        for (i=CTX->watch_nslots; i<newarraysize; i++)
+            LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots,
+                                    &newarray[i], empty);
+        CTX->watch_slots = newarray;
+        CTX->watch_nslots = newarraysize;
+    }
+    use = LIBXL_SLIST_FIRST(&CTX->watch_freeslots);
+    assert(use);
+    LIBXL_SLIST_REMOVE_HEAD(&CTX->watch_freeslots, empty);
+
+    path_copy = strdup(path);
+    if (!path_copy) goto out_nomem;
+
+    int slotnum = use - CTX->watch_slots;
+    w->counterval = CTX->watch_counter++;
+
+    rc = xs_watch(CTX->xsh, path, watch_token(gc, slotnum, w->counterval));
+    if (rc) {
+        LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                            "create watch for path %s", path);
+        rc = ERROR_FAIL;
+        goto out_rc;
+    }
+
+    w->slotnum = slotnum;
+    w->path = path_copy;
+    w->callback = func;
+    /* we look a bit behind the curtain of LIBXL_SLIST, to explictly
+     * assign to the pointer that's the next link.  See the comment
+     * by the definitionn of libxl__ev_watch_slot */
+    use->empty.sle_next = (void*)w;
+
+    CTX_UNLOCK;
+    return 0;
+
+ out_nomem:
+    rc = ERROR_NOMEM;
+ out_rc:
+    if (use)
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, use, empty);
+    if (path_copy)
+        free(path_copy);
+    CTX_UNLOCK;
+    return rc;
+}
+
+void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w) {
+    /* it is legal to deregister from within _callback */
+    CTX_LOCK;
+
+    if (w->slotnum >= 0) {
+        char *token = watch_token(gc, w->slotnum, w->counterval);
+        int rc = xs_unwatch(CTX->xsh, w->path, token);
+        if (rc)
+            /* Oh well, we will just get watch events forever more
+             * and ignore them.  But we should complain to the log. */
+            LIBXL__LOG_ERRNOVAL(CTX, LIBXL__LOG_ERROR, errno,
+                                "remove watch for path %s", w->path);
+
+        libxl__ev_watch_slot *slot = &CTX->watch_slots[w->slotnum];
+        LIBXL_SLIST_INSERT_HEAD(&CTX->watch_freeslots, slot, empty);
+    }
+
+    free(w->path);
+    w->path = NULL;
+
+    CTX_UNLOCK;
+}
+
+/*
+ * osevent poll
+ */
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now) {
+    libxl__ev_fd *efd;
+    int i;
+
+    /*
+     * In order to be able to efficiently find the libxl__ev_fd
+     * for a struct poll during _afterpoll, we maintain a shadow
+     * data structure in CTX->fd_beforepolled: each slot in
+     * the fds array corresponds to a slot in fd_beforepolled.
+     */
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    if (*nfds_io) {
+        /*
+         * As an optimisation, we don't touch fd_beforepolled_used
+         * if *nfds_io is zero on entry, since in that case the
+         * caller just wanted to know how big an array to give us.
+         *
+         * If !*nfds_io, the unconditional parts below are guaranteed
+         * not to mess with fd_beforepolled... or any in_beforepolled.
+         */
+
+        /* Remove all the old references into beforepolled */
+        for (i = 0; i < CTX->fd_beforepolled_used; i++) {
+            efd = CTX->fd_beforepolled[i];
+            if (efd) {
+                assert(efd->in_beforepolled == i);
+                efd->in_beforepolled = -1;
+                CTX->fd_beforepolled[i] = NULL;
+            }
+        }
+        CTX->fd_beforepolled_used = 0;
+
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_beforepolled_allocd < *nfds_io) {
+            assert(*nfds_io < INT_MAX / sizeof(libxl__ev_fd*) / 2);
+            libxl__ev_fd **newarray =
+                realloc(CTX->fd_beforepolled, sizeof(*newarray) * *nfds_io);
+            if (!newarray)
+                return ERROR_NOMEM;
+            CTX->fd_beforepolled = newarray;
+            CTX->fd_beforepolled_allocd = *nfds_io;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            CTX->fd_beforepolled[used] = efd;
+            efd->in_beforepolled = used;
+        }
+        used++;
+    }
+    int rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    if (*nfds_io) {
+        CTX->fd_beforepolled_used = used;
+    }
+
+    *nfds_io = used;
+
+    libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+    if (etime) {
+        int our_timeout;
+        struct timeval rel;
+        static struct timeval zero;
+
+        timersub(&etime->abs, &now, &rel);
+
+        if (timercmp(&rel, &zero, <)) {
+            our_timeout = 0;
+        } else if (rel.tv_sec >= 2000000) {
+            our_timeout = 2000000000;
+        } else {
+            our_timeout = rel.tv_sec * 1000 + (rel.tv_usec + 999) / 1000;
+        }
+        if (*timeout_upd < 0 || our_timeout < *timeout_upd)
+            *timeout_upd = our_timeout;
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now) {
+    int i;
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(nfds <= CTX->fd_beforepolled_used);
+
+    for (i = 0; i < nfds; i++) {
+        if (!fds[i].revents)
+            continue;
+
+        libxl__ev_fd *efd = CTX->fd_beforepolled[i];
+        if (!efd)
+            continue;
+
+        assert(efd->in_beforepolled == i);
+        assert(fds[i].fd == efd->fd);
+
+        int revents = fds[i].revents & efd->events;
+        if (!revents)
+            continue;
+
+        efd->func(gc, efd, efd->fd, efd->events, revents);
+    }
+
+    for (;;) {
+        libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
+        if (!etime)
+            break;
+
+        assert(!etime->infinite);
+
+        if (timercmp(&etime->abs, &now, >))
+            break;
+
+        time_deregister(gc, etime);
+
+        etime->func(gc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+/*
+ * osevent hook and callback machinery
+ */
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user) {
+    GC_INIT(ctx);
+    CTX_LOCK;
+    ctx->osevent_hooks = hooks;
+    ctx->osevent_user = user;
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents) {
+    libxl__ev_fd *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(gc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl) {
+    libxl__ev_time *ev = for_libxl;
+
+    GC_INIT(ctx);
+    CTX_LOCK;
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(gc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    GC_FREE;
+}
+
+void libxl__event_disaster(libxl__gc *gc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line) {
+    libxl__log(CTX, XTL_CRITICAL, errnoval, file, line,
+               "DISASTER in event loop: %s%s%s%s",
+               msg,
+               type ? " (relates to event type " : "",
+               type ? libxl_event_type_to_string(type) : "",
+               type ? ")" : "");
+
+    /*
+     * FIXME: This should call the "disaster" hook supplied to
+     * libxl_event_register_callbacks, which will be introduced in the
+     * next patch.
+     */
+
+    const char verybad[] =
+        "DISASTER in event loop not handled by libxl application";
+    LIBXL__LOG(CTX, XTL_CRITICAL, verybad);
+    fprintf(stderr, "libxl: fatal error, exiting program: %s\n", verybad);
+    exit(-1);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
new file mode 100644
index 0000000..25efbdf
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,199 @@
+/*
+ * Copyright (C) 2011      Citrix Ltd.
+ * Author Ian Jackson <ian.jackson@eu.citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_EVENT_H
+#define LIBXL_EVENT_H
+
+#include <libxl.h>
+
+
+/*======================================================================*/
+
+/*
+ * OS event handling - passing low-level OS events to libxl
+ *
+ * Event-driven programs must use these facilities to allow libxl
+ * to become aware of readability/writeability of file descriptors
+ * and the occurrence of timeouts.
+ *
+ * There are two approaches available.  The first is appropriate for
+ * simple programs handling reasonably small numbers of domains:
+ *
+ *   for (;;) {
+ *      libxl_osevent_beforepoll(...)
+ *      poll();
+ *      libxl_osevent_afterpoll(...);
+ *      for (;;) {
+ *        r=libxl_event_check(...);
+ *        if (r==LIBXL_NOT_READY) break;
+ *        if (r) handle failure;
+ *        do something with the event;
+ *      }
+ *   }
+ *
+ * The second approach uses libxl_osevent_register_hooks and is
+ * suitable for programs which are already using a callback-based
+ * event library.
+ *
+ * An application may freely mix the two styles of interaction.
+ */
+
+struct pollfd;
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now);
+  /* The caller should provide beforepoll with some space for libxl's
+   * fds, and tell libxl how much space is available by setting *nfds_io.
+   * fds points to the start of this space (and fds may be a pointer into
+   * a larger array, for example, if the application has some fds of
+   * its own that it is interested in).
+   *
+   * On return *nfds_io will in any case have been updated by libxl
+   * according to how many fds libxl wants to poll on.
+   *
+   * If the space was sufficient, libxl fills in fds[0..<new
+   * *nfds_io>] suitably for poll(2), updates *timeout_upd if needed,
+   * and returns ok.
+   *
+   * If space was insufficient, fds[0..<old *nfds_io>] is undefined on
+   * return; *nfds_io on return will be greater than the value on
+   * entry; *timeout_upd may or may not have been updated; and
+   * libxl_osevent_beforepoll returns ERROR_BUFERFULL.  In this case
+   * the application needs to make more space (enough space for
+   * *nfds_io struct pollfd) and then call beforepoll again, before
+   * entering poll(2).  Typically this will involve calling realloc.
+   *
+   * The application may call beforepoll with fds==NULL and
+   * *nfds_io==0 in order to find out how much space is needed.
+   *
+   * *timeout_upd is as for poll(2): it's in milliseconds, and
+   * negative values mean no timeout (infinity).
+   * libxl_osevent_beforepoll will only reduce the timeout, naturally.
+   */
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now);
+  /* nfds and fds[0..nfds] must be from the most recent call to
+   * _beforepoll, as modified by poll.
+   *
+   * This function actually performs all of the IO and other actions,
+   * and generates events (libxl_event), which are implied by either
+   * (a) the time of day or (b) both (i) the returned information from
+   * _beforepoll, and (ii) the results from poll specified in
+   * fds[0..nfds-1].  Generated events can then be retrieved by
+   * libxl_event_check.
+   */
+
+
+typedef struct libxl_osevent_hooks {
+  int (*fd_register)(void *user, int fd, void **for_app_registration_out,
+                     short events, void *for_libxl);
+  int (*fd_modify)(void *user, int fd, void **for_app_registration_update,
+                   short events);
+  void (*fd_deregister)(void *user, int fd, void *for_app_registration);
+  int (*timeout_register)(void *user, void **for_app_registration_out,
+                          struct timeval abs, void *for_libxl);
+  int (*timeout_modify)(void *user, void **for_app_registration_update,
+                         struct timeval abs);
+  void (*timeout_deregister)(void *user, void *for_app_registration_io);
+} libxl_osevent_hooks;
+
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user);
+  /* The application which calls register_fd_hooks promises to
+   * maintain a register of fds and timeouts that libxl is interested
+   * in, and make calls into libxl (libxl_osevent_occurred_*)
+   * when those fd events and timeouts occur.  This is more efficient
+   * than _beforepoll/_afterpoll if there are many fds (which can
+   * happen if the same libxl application is managing many domains).
+   *
+   * For an fd event, events is as for poll().  register or modify may
+   * be called with events==0, in which case it must still work
+   * normally, just not generate any events.
+   *
+   * For a timeout event, milliseconds is as for poll().
+   * Specifically, negative values of milliseconds mean NO TIMEOUT.
+   * This is used by libxl to temporarily disable a timeout.
+   *
+   * If the register or modify hook succeeds it may update
+   * *for_app_registration_out/_update and must then return 0.
+   * On entry to register, *for_app_registration_out is always NULL.
+   *
+   * A registration or modification hook may fail, in which case it
+   * must leave the registration state of the fd or timeout unchanged.
+   * It may then either return ERROR_OSEVENT_REG_FAIL or any positive
+   * int.  The value returned will be passed up through libxl and
+   * eventually returned back to the application.  When register
+   * fails, any value stored into *for_registration_out is ignored by
+   * libxl; when modify fails, any changed value stored into
+   * *for_registration_update is honoured by libxl and will be passed
+   * to future modify or deregister calls.
+   *
+   * libxl will only attempt to register one callback for any one fd.
+   * libxl will remember the value stored in *for_app_registration_io
+   * by a successful call to register or modify and pass it into
+   * subsequent calls to modify or deregister.
+   *
+   * register_fd_hooks may be called only once for each libxl_ctx.
+   * libxl may make calls to register/modify/deregister from within
+   * any libxl function (indeed, it will usually call register from
+   * register_event_hooks).  Conversely, the application MUST NOT make
+   * the event occurrence calls (libxl_osevent_occurred_*) into libxl
+   * reentrantly from within libxl (for example, from within the
+   * register/modify functions).
+   *
+   * Lock hierarchy: the register/modify/deregister functions may be
+   * called with locks held.  These locks (the "libxl internal locks")
+   * are inside the libxl_ctx.  Therefore, if those register functions
+   * acquire any locks of their own ("caller register locks") outside
+   * libxl, to avoid deadlock one of the following must hold for each
+   * such caller register lock:
+   *  (a) "acquire libxl internal locks before caller register lock":
+   *      No libxl function may be called with the caller register
+   *      lock held.
+   *  (b) "acquire caller register lock before libxl internal locks":
+   *      No libxl function may be called _without_ the caller
+   *      register lock held.
+   * Of these we would normally recommend (a).
+   *
+   * The value *hooks is not copied and must outlast the libxl_ctx.
+   */
+
+/* It is NOT legal to call _occurred_ reentrantly within any libxl
+ * function.  Specifically it is NOT legal to call it from within
+ * a register callback.  Conversely, libxl MAY call register/deregister
+ * from within libxl_event_registered_call_*.
+ */
+
+void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
+                               int fd, short events, short revents);
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+  /* Implicitly, on entry to this function the timeout has been
+   * deregistered.  If _occurred_timeout is called, libxl will not
+   * call timeout_deregister; if it wants to requeue the timeout it
+   * will call timeout_register again.
+   */
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1d1dc35..3e461fa 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -24,6 +24,9 @@
 #include <stdlib.h>
 #include <string.h>
 #include <pthread.h>
+#include <inttypes.h>
+#include <assert.h>
+#include <sys/poll.h>
 
 #include <xs.h>
 #include <xenctrl.h>
@@ -91,6 +94,66 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
      /* these functions preserve errno (saving and restoring) */
 
+typedef struct libxl__gc libxl__gc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__gc *gc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* all private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    int fd;
+    short events;
+    int in_beforepolled; /* -1 means not in fd_beforepolled */
+    void *for_app_reg;
+    libxl__ev_fd_callback *func;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__gc *gc, libxl__ev_time *ev,
+                                     const struct timeval *requested_abs);
+struct libxl__ev_time {
+    /* all private for libxl__ev_time... */
+    int infinite; /* not registered in list or with app if infinite */
+    LIBXL_TAILQ_ENTRY(libxl__ev_time) entry;
+    struct timeval abs;
+    void *for_app_reg;
+    libxl__ev_time_callback *func;
+};
+
+typedef struct libxl__ev_xswatch libxl__ev_xswatch;
+typedef void libxl__ev_xswatch_callback(libxl__gc *gc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+struct libxl__ev_xswatch {
+    /* caller should include this in their own struct */
+    /* contents are private to xswatch_register */
+    int slotnum;
+    uint32_t counterval;
+    char *path;
+    libxl__ev_xswatch_callback *callback;
+};
+
+/*
+ * An entry in the watch_slots table is either:
+ *  1. an entry in the free list, ie NULL or pointer to next free list entry
+ *  2. an pointer to a libxl__ev_xswatch
+ *
+ * But we don't want to use unions or type-punning because the
+ * compiler might "prove" that our code is wrong and misoptimise it.
+ *
+ * The rules say that all struct pointers have identical
+ * representation and alignment requirements (C99+TC1+TC2 6.2.5p26) so
+ * what we do is simply declare our array as containing only the free
+ * list pointers, and explicitly convert from and to our actual
+ * xswatch pointers when we store and retrieve them.
+ */
+typedef struct libxl__ev_watch_slot {
+    LIBXL_SLIST_ENTRY(struct libxl__ev_watch_slot) empty;
+} libxl__ev_watch_slot;
+    
+libxl__ev_xswatch *libxl__watch_slot_contents(libxl__gc *gc, int slotnum);
+
 struct libxl__ctx {
     xentoollog_logger *lg;
     xc_interface *xch;
@@ -108,6 +171,21 @@ struct libxl__ctx {
        * documented in the libxl public interface.
        */
 
+    int osevent_in_hook;
+    const libxl_osevent_hooks *osevent_hooks;
+    void *osevent_user;
+
+    int fd_beforepolled_allocd, fd_beforepolled_used;
+    libxl__ev_fd **fd_beforepolled; /* see libxl_osevent_beforepoll */
+    LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
+    LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
+
+    libxl__ev_watch_slot *watch_slots;
+    int watch_nslots;
+    LIBXL_SLIST_HEAD(, libxl__ev_watch_slot) watch_freeslots;
+    uint32_t watch_counter; /* helps disambiguate slot reuse */
+    libxl__ev_fd watch_efd;
+
     /* for callers who reap children willy-nilly; caller must only
      * set this after libxl_init and before any other call - or
      * may leave them untouched */
@@ -138,12 +216,12 @@ typedef struct {
 
 #define PRINTF_ATTRIBUTE(x, y) __attribute__((format(printf, x, y)))
 
-typedef struct {
+struct libxl__gc {
     /* mini-GC */
     int alloc_maxsize;
     void **alloc_ptrs;
     libxl_ctx *owner;
-} libxl__gc;
+};
 
 #define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
 static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
@@ -204,9 +282,136 @@ _hidden char *libxl__xs_read(libxl__gc *gc, xs_transaction_t t,
 _hidden char **libxl__xs_directory(libxl__gc *gc, xs_transaction_t t,
                                    const char *path, unsigned int *nb);
    /* On error: returns NULL, sets errno (no logging) */
-
 _hidden char *libxl__xs_libxl_path(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Event generation functions provided by the libxl event core to the
+ * rest of libxl.  Implemented in terms of _beforepoll/_afterpoll
+ * and/or the fd registration machinery, as provided by the
+ * application.
+ *
+ * Semantics are similar to those of the fd and timeout registration
+ * functions provided to libxl_osevent_register_hooks.
+ *
+ * Non-0 returns from libxl__ev_{modify,deregister} have already been
+ * logged by the core and should be returned unmodified to libxl's
+ * caller; NB that they may be valid libxl error codes but they may
+ * also be positive numbers supplied by the caller.
+ *
+ * In each case, there is a libxl__ev_FOO structure which can be in
+ * one of three states:
+ *
+ *   Undefined   - Might contain anything.  All-bits-zero is
+ *                 an undefined state.
+ *
+ *   Idle        - Struct contents are defined enough to pass to any
+ *                 libxl__ev_FOO function but not registered and
+ *                 callback will not be called.  The struct does not
+ *                 contain references to any allocated resources so
+ *                 can be thrown away.
+ *
+ *   Active      - Request for events has been registered and events
+ *                 may be generated.  _deregister must be called to
+ *                 reclaim resources.
+ *
+ * These functions are provided for each kind of event KIND:
+ *
+ *   int libxl__ev_KIND_register(libxl__gc *gc, libxl__ev_KIND *GEN,
+ *                              libxl__ev_KIND_callback *FUNC,
+ *                              DETAILS);
+ *      On entry *GEN must be in state Undefined or Idle.
+ *      Returns a libxl error code; on error return *GEN is Idle.
+ *      On successful return *GEN is Active and FUNC wil be
+ *      called by the event machinery in future.  FUNC will
+ *      not be called from within the call to _register.
+ *
+ *  void libxl__ev_KIND_deregister(libxl__gc *gc, libxl__ev_KIND *GEN_upd);
+ *      On entry *GEN must be in state Active or Idle.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  void libxl__ev_KIND_init(libxl__ev_KIND *GEN);
+ *      Provided for initialising an Undefined KIND.
+ *      On entry *GEN must be in state Idle or Undefined.
+ *      On return it is Idle.  (Idempotent.)
+ *
+ *  int libxl__ev_KIND_isregistered(const libxl__ev_KIND *GEN);
+ *      On entry *GEN must be Idle or Active.
+ *      Returns nonzero if it is Active, zero otherwise.
+ *      Cannot fail.
+ *
+ *  int libxl__ev_KiND_modify(libxl__gc*, libxl__ev_KIND *GEN,
+ *                            DETAILS);
+ *      Only provided for some kinds of generator.
+ *      On entry *GEN must be Active and on return, whether successful
+ *      or not, it will be Active.
+ *      Returns a libxl error code; on error the modification
+ *      is not effective.
+ *
+ * All of these functions are fully threadsafe and may be called by
+ * general code in libxl even from within event callback FUNCs.
+ */
+
+
+_hidden int libxl__ev_fd_register(libxl__gc*, libxl__ev_fd *ev_out,
+                                  libxl__ev_fd_callback*,
+                                  int fd, short events /* as for poll(2) */);
+_hidden int libxl__ev_fd_modify(libxl__gc*, libxl__ev_fd *ev,
+                                short events);
+_hidden void libxl__ev_fd_deregister(libxl__gc*, libxl__ev_fd *ev);
+static inline void libxl__ev_fd_init(libxl__ev_fd *efd)
+                    { efd->fd = -1; }
+static inline int libxl__ev_fd_isregistered(libxl__ev_fd *efd)
+                    { return efd->fd >= 0; }
+
+_hidden int libxl__ev_time_register_rel(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_register_abs(libxl__gc*, libxl__ev_time *ev_out,
+                                        libxl__ev_time_callback*,
+                                        struct timeval);
+_hidden int libxl__ev_time_modify_rel(libxl__gc*, libxl__ev_time *ev,
+                                      int milliseconds /* as for poll(2) */);
+_hidden int libxl__ev_time_modify_abs(libxl__gc*, libxl__ev_time *ev,
+                                      struct timeval);
+_hidden void libxl__ev_time_deregister(libxl__gc*, libxl__ev_time *ev);
+static inline void libxl__ev_time_init(libxl__ev_time *ev)
+                { ev->func = 0; }
+static inline int libxl__ev_time_isregistered(libxl__ev_time *ev)
+                { return !!ev->func; }
+
+
+_hidden int libxl__ev_xswatch_register(libxl__gc*, libxl__ev_xswatch *xsw_out,
+                                       libxl__ev_xswatch_callback*,
+                                       const char *path /* copied */);
+_hidden void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch*);
+
+static inline void libxl__ev_xswatch_init(libxl__ev_xswatch *xswatch_out)
+                { xswatch_out->slotnum = -1; }
+static inline int libxl__ev_xswatch_isregistered(const libxl__ev_xswatch *xw)
+                { return xw->slotnum >= 0; }
+
+
+
+_hidden void libxl__event_disaster(libxl__gc*, const char *msg, int errnoval,
+                                   libxl_event_type type /* may be 0 */,
+                                   const char *file, int line);
+  /*
+   * In general, call this via the macro LIBXL__EVENT_DISASTER.
+   *
+   * Event-generating functions may call this if they might have
+   * wanted to generate an event (either an internal one ie a
+   * libxl__ev_FOO_callback or an application event), but are
+   * prevented from doing so due to eg lack of memory.
+   *
+   * NB that this function may return and the caller isn't supposed to
+   * then crash, although it may fail (and henceforth leave things in
+   * a state where many or all calls fail).
+   */
+#define LIBXL__EVENT_DISASTER(gc, msg, errnoval, type) \
+    libxl__event_disaster(gc, msg, errnoval, type, __FILE__, __LINE__)
+
+
 /* from xl_dom */
 _hidden libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
@@ -531,6 +736,8 @@ _hidden int libxl__parse_mac(const char *s, libxl_mac mac);
 /* compare mac address @a and @b. 0 if the same, -ve if a<b and +ve if a>b */
 _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b);
 
+_hidden int libxl__gettimeofday(libxl__gc *gc, struct timeval *now_r);
+
 #define STRINGIFY(x) #x
 #define TOSTRING(x) STRINGIFY(x)
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZE-0003gq-QB; Mon, 28 Nov 2011 17:00:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZB-0003eC-M5
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29196 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169235"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055g-Ex; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000ch-EC;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:34 +0000
Message-ID: <1322499580-2322-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/13] libxl: internal convenience macros
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide some macros which are useful shorthands for use within libxl:
  * GC_INIT to initialise a gc from a ctx and GC_FREE to free it
  * CTX(gc) to give you back the ctx
  * LIBXL_TAILQ_INSERT_SORTED for inserting things into sorted lists

These will be used by later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   48 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index bfc74c9..950c466 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -646,6 +646,54 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 _hidden libxl_device_model_version
 libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Convenience macros.
+ */
+
+
+/*
+ * All of these assume (or define)
+ *    libxl__gc *gc;
+ * as a local variable.
+ */
+
+#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+#define GC_FREE       libxl__free_all(gc)
+#define CTX           libxl__gc_owner(gc)
+
+
+/*
+ * Inserts "elm_new" into the sorted list "head".
+ *
+ * "elm_search" must be a loop search variable of the same type as
+ * "elm_new".  "new_after_search_p" must be an expression which is
+ * true iff the element "elm_new" sorts after the element
+ * "elm_search".
+ *
+ * "search_body" can be empty, or some declaration(s) and statement(s)
+ * needed for "new_after_search_p".
+ */
+#define LIBXL_TAILQ_INSERT_SORTED(head, entry, elm_new, elm_search,     \
+                                  search_body, new_after_search_p)      \
+    do {                                                                \
+        for ((elm_search) = LIBXL_TAILQ_FIRST((head));                  \
+             (elm_search);                                              \
+             (elm_search) = LIBXL_TAILQ_NEXT((elm_search), entry)) {    \
+            search_body;                                                \
+            if (!(new_after_search_p))                                  \
+                break;                                                  \
+        }                                                               \
+        /* now elm_search is either the element before which we want    \
+         * to place elm_new, or NULL meaning we want to put elm_new at  \
+         * the end */                                                   \
+        if ((elm_search))                                               \
+            LIBXL_TAILQ_INSERT_BEFORE((elm_search), (elm_new), entry);  \
+        else                                                            \
+            LIBXL_TAILQ_INSERT_TAIL((head), (elm_new), entry);          \
+    } while(0)
+
+
 #endif
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:00:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4ZE-0003gq-QB; Mon, 28 Nov 2011 17:00:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4ZB-0003eC-M5
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:00:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322499591!5005186!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29196 invoked from network); 28 Nov 2011 16:59:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 16:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169235"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 16:59:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 16:59:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4YZ-00055g-Ex; Mon, 28 Nov 2011 16:59:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4YZ-0000ch-EC;
	Mon, 28 Nov 2011 16:59:51 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 28 Nov 2011 16:59:34 +0000
Message-ID: <1322499580-2322-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/13] libxl: internal convenience macros
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide some macros which are useful shorthands for use within libxl:
  * GC_INIT to initialise a gc from a ctx and GC_FREE to free it
  * CTX(gc) to give you back the ctx
  * LIBXL_TAILQ_INSERT_SORTED for inserting things into sorted lists

These will be used by later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   48 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index bfc74c9..950c466 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -646,6 +646,54 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 _hidden libxl_device_model_version
 libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
+
+/*
+ * Convenience macros.
+ */
+
+
+/*
+ * All of these assume (or define)
+ *    libxl__gc *gc;
+ * as a local variable.
+ */
+
+#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+#define GC_FREE       libxl__free_all(gc)
+#define CTX           libxl__gc_owner(gc)
+
+
+/*
+ * Inserts "elm_new" into the sorted list "head".
+ *
+ * "elm_search" must be a loop search variable of the same type as
+ * "elm_new".  "new_after_search_p" must be an expression which is
+ * true iff the element "elm_new" sorts after the element
+ * "elm_search".
+ *
+ * "search_body" can be empty, or some declaration(s) and statement(s)
+ * needed for "new_after_search_p".
+ */
+#define LIBXL_TAILQ_INSERT_SORTED(head, entry, elm_new, elm_search,     \
+                                  search_body, new_after_search_p)      \
+    do {                                                                \
+        for ((elm_search) = LIBXL_TAILQ_FIRST((head));                  \
+             (elm_search);                                              \
+             (elm_search) = LIBXL_TAILQ_NEXT((elm_search), entry)) {    \
+            search_body;                                                \
+            if (!(new_after_search_p))                                  \
+                break;                                                  \
+        }                                                               \
+        /* now elm_search is either the element before which we want    \
+         * to place elm_new, or NULL meaning we want to put elm_new at  \
+         * the end */                                                   \
+        if ((elm_search))                                               \
+            LIBXL_TAILQ_INSERT_BEFORE((elm_search), (elm_new), entry);  \
+        else                                                            \
+            LIBXL_TAILQ_INSERT_TAIL((head), (elm_new), entry);          \
+    } while(0)
+
+
 #endif
 
 /*
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:12:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4kU-0006Km-O3; Mon, 28 Nov 2011 17:12:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4kS-0006K3-Qm
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:12:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322500292!3240107!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3803 invoked from network); 28 Nov 2011 17:11:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 17:11:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 17:11:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 17:11:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4jr-0005AZ-Px; Mon, 28 Nov 2011 17:11:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4jr-0000yb-P4;
	Mon, 28 Nov 2011 17:11:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.49347.763236.517872@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 17:11:31 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK6QsoZtpqitdOjeD6MgYhVB6k3cVQYbiaprdMo5ui3HyQ@mail.gmail.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1320055865.23193.45.camel@zakaz.uk.xensource.com>
	<CAPLaKK511W3q3YA+wFv=AJxqFQAFyaChRXuBCd_Sh=kMz6yQ8Q@mail.gmail.com>
	<20171.51198.221057.507056@mariner.uk.xensource.com>
	<CAPLaKK6QsoZtpqitdOjeD6MgYhVB6k3cVQYbiaprdMo5ui3HyQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 00/13] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH RFC v2 00/13] New event A=
PI"):
> 2011/11/22 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > I'm afraid I don't know. =A0With my upstream hat on, for applying
> > patches, I have an absolutely hideous script. =A0(Below but don't read
> > it if you want to keep your lunch.) =A0With my contributor hat on I
> > almost always use git.
> =

> Thanks for the script, I will try to import this series later this
> week if I can get my hands on an unused virtualization server (right
> now all my available servers are busy). Shouldn't we agree on having
> only one repository format? Either git or mercurial is fine for me,
> but it will avoid this kind of situations.

Well, with my contributor hat on you can pry my git out of my cold
dead fingers.

With my upstream hat on, I'm happy to accept patches generated by any
reasonable vcs (or none).  But I don't think we have a consensus to
change xen-unstable to git.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:12:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:12:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4kU-0006Km-O3; Mon, 28 Nov 2011 17:12:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4kS-0006K3-Qm
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:12:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322500292!3240107!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3803 invoked from network); 28 Nov 2011 17:11:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 17:11:32 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169516"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 17:11:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 17:11:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4jr-0005AZ-Px; Mon, 28 Nov 2011 17:11:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4jr-0000yb-P4;
	Mon, 28 Nov 2011 17:11:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.49347.763236.517872@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 17:11:31 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK6QsoZtpqitdOjeD6MgYhVB6k3cVQYbiaprdMo5ui3HyQ@mail.gmail.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1320055865.23193.45.camel@zakaz.uk.xensource.com>
	<CAPLaKK511W3q3YA+wFv=AJxqFQAFyaChRXuBCd_Sh=kMz6yQ8Q@mail.gmail.com>
	<20171.51198.221057.507056@mariner.uk.xensource.com>
	<CAPLaKK6QsoZtpqitdOjeD6MgYhVB6k3cVQYbiaprdMo5ui3HyQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 00/13] New event API
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH RFC v2 00/13] New event A=
PI"):
> 2011/11/22 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > I'm afraid I don't know. =A0With my upstream hat on, for applying
> > patches, I have an absolutely hideous script. =A0(Below but don't read
> > it if you want to keep your lunch.) =A0With my contributor hat on I
> > almost always use git.
> =

> Thanks for the script, I will try to import this series later this
> week if I can get my hands on an unused virtualization server (right
> now all my available servers are busy). Shouldn't we agree on having
> only one repository format? Either git or mercurial is fine for me,
> but it will avoid this kind of situations.

Well, with my contributor hat on you can pry my git out of my cold
dead fingers.

With my upstream hat on, I'm happy to accept patches generated by any
reasonable vcs (or none).  But I don't think we have a consensus to
change xen-unstable to git.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:17:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4pC-0006g4-Nk; Mon, 28 Nov 2011 17:17:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4pB-0006fq-2G
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:17:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322500584!5030722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5571 invoked from network); 28 Nov 2011 17:16:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 17:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 17:16:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 17:16:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4oa-0005Cb-8t; Mon, 28 Nov 2011 17:16:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4oa-0000zK-74;
	Mon, 28 Nov 2011 17:16:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.49640.205484.358827@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 17:16:24 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322485725.1005.290.camel@zakaz.uk.xensource.com>
References: <20179.32337.102834.867932@mariner.uk.xensource.com>
	<1322485725.1005.290.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: open logs with O_APPEND
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/2] libxl: open logs with O_APPEND"):
> On Mon, 2011-11-28 at 12:28 +0000, Ian Jackson wrote:
> > Logfiles should always be opened for append.
> > 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Both this and the 2/2 patch look sensible to me and are:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.  I will apply then.

> > -        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT, 0644) )<0);
> > +        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT|O_APPEND,
> > +                                   0644) )<0);
> 
> fullname here came from libxl_create_logfile so has been rotated such
> that the file will be empty. I don't think O_APPEND is harmful or wrong
> given this though.

O_APPEND sets a flag which applies throughout the future life of the
open-file, so that even if the file later grows for some reason,
writes will never overwrite existing data.

> Do we need to arrange for libxl_create_logfile to be called for some of
> these others though?

The one in libxl_create_device_model came from libxl_create_logfile
too.

Obviously the one in qemu can't call libxl_create_logfile but in our
setup it's fed /dev/stderr anyway.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:17:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:17:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV4pC-0006g4-Nk; Mon, 28 Nov 2011 17:17:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV4pB-0006fq-2G
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:17:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322500584!5030722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5571 invoked from network); 28 Nov 2011 17:16:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 17:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9169603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 17:16:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 17:16:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV4oa-0005Cb-8t; Mon, 28 Nov 2011 17:16:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV4oa-0000zK-74;
	Mon, 28 Nov 2011 17:16:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.49640.205484.358827@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 17:16:24 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322485725.1005.290.camel@zakaz.uk.xensource.com>
References: <20179.32337.102834.867932@mariner.uk.xensource.com>
	<1322485725.1005.290.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl: open logs with O_APPEND
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/2] libxl: open logs with O_APPEND"):
> On Mon, 2011-11-28 at 12:28 +0000, Ian Jackson wrote:
> > Logfiles should always be opened for append.
> > 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Both this and the 2/2 patch look sensible to me and are:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.  I will apply then.

> > -        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT, 0644) )<0);
> > +        CHK_ERRNO(( logfile = open(fullname, O_WRONLY|O_CREAT|O_APPEND,
> > +                                   0644) )<0);
> 
> fullname here came from libxl_create_logfile so has been rotated such
> that the file will be empty. I don't think O_APPEND is harmful or wrong
> given this though.

O_APPEND sets a flag which applies throughout the future life of the
open-file, so that even if the file later grows for some reason,
writes will never overwrite existing data.

> Do we need to arrange for libxl_create_logfile to be called for some of
> these others though?

The one in libxl_create_device_model came from libxl_create_logfile
too.

Obviously the one in qemu can't call libxl_create_logfile but in our
setup it's fed /dev/stderr anyway.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:32:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:32:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV53Y-0007Iy-Ta; Mon, 28 Nov 2011 17:31:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RV53X-0007Ih-EF
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:31:51 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322501473!3246869!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE4NDMw\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1508 invoked from network); 28 Nov 2011 17:31:13 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-174.messagelabs.com with SMTP;
	28 Nov 2011 17:31:13 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 28 Nov 2011 09:31:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="80739105"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 28 Nov 2011 09:31:09 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 29 Nov 2011 01:31:09 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 29 Nov 2011 01:31:08 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Tue, 29 Nov 2011 01:31:07 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 29 Nov 2011 01:31:05 +0800
Thread-Topic: [Xen-devel] [PATCH] scheduler rate controller
Thread-Index: AcyZ4Rf7B2HWuje3SsSqNqOisGKDgwUEEO3w
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F340768D793@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB5EF9@shsmsx502.ccr.corp.intel.com>
	<1319789425.19320.12.camel@Abyss>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB61F2@shsmsx502.ccr.corp.intel.com>
	<1319796584.19320.31.camel@Abyss>	<1319818714.21033.414.camel@elijah>
	<C10D3FB0CD45994C8A51FEC1227CE22F34B3905D03@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
In-Reply-To: <CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	George Dunlap <george.dunlap@citrix.com>, "Duan, 
	Jiangang" <jiangang.duan@intel.com>, Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, George

Sorry for the late. I also met issues to boot up xen according to your patc=
h, which is same as credit_3.patch that I attached.
So I modified it to the credit_1.patch and credit_2.patch, both of which wo=
rk well.
1) credit_1 adopts "scheduling frequency counting" to decide the value of s=
ched_ratelimit_us, which makes it adaptive.
2) credit_2 adopts the constant sched_ratelimit_us value 1000.=20

Although the performance comparison data is still in process, I want to hea=
r some feedbacks from you.=20
I think I shall share the data very soon when the system becomes stable.


Best regards,

Lv, Hui


-----Original Message-----
From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George Dunl=
ap
Sent: Thursday, November 03, 2011 12:29 PM
To: Lv, Hui
Cc: George Dunlap; Dario Faggioli; Tian, Kevin; xen-devel@lists.xensource.c=
om; Keir (Xen.org); Dong, Eddie; Duan, Jiangang
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller

On Sat, Oct 29, 2011 at 11:05 AM, Lv, Hui <hui.lv@intel.com> wrote:
> I have tried one way very similar as your idea.
> 1) to check whether current running vcpu runs less than 1ms, if yes, we w=
ill return current vcpu directly without preemption.
> It try to guarantee vcpu to run as long as 1ms, if it wants.
> It can reduce the scheduling frequency to some degree, but not very signi=
ficant. Because 1ms is too light/weak with comparison to 10ms delay (SRC pa=
tch used).

Hey Hui,  Sorry for the delay in response -- FYI I'm at the XenSummit Korea=
 now, and I'll be on holiday next week.

Do you have the patch that you wrote for the 1ms delay handy, and any numbe=
rs that you ran?  I'm a bit surprised that a 1ms delay didn't have much eff=
ect; but in any case, it seems dialing that up should have a similar effect=
 -- e.g., if we changed that to 10ms, then it should have a similar effect =
to the patch that you sent before.

> As you said, if applying the seveal_ms_delay, it will happen whenever=20
> system is normal or not (excessive frequency). It may possible have=20
> the consequence that 1)under normal condition, it will produce worse=20
> Qos than that without applying such delay,

Perhaps; but the current credit scheduler may already allow a VM to run exc=
lusively for 30ms, so I don't think that overall it should have a big influ=
ence.

> 2) under excessive frequency condition, the mitigation effect of 1ms-dela=
y may be too weak. In addition, your idea is to delay scheduling instead of=
 reducing, which means the total number of scheduling would probably not ch=
ange.

Well it will prevent preemption; so as long as at least one VM does not yie=
ld, it will reduce the number of schedule events to 1000 times per second. =
 If all VMs yield, then you can't really reduce the number of scheduling ev=
ents anyway (even with your preemption-disable patch).

> I think one possible solution, is to make the value of 1ms-delay=20
> adaptive according to the system status (low load or high load). If=20
> so, SRC patch just covered the excessive condition currently :).=20
> That's why I mentioned to treat normal and excessive conditions=20
> separately and don't influence the normal case as much as possible.=20
> Because we never know the consequence without amount of testing work.=20
> :)

Yes, exactly. :-)

> Some of my stupid thinking :)

Well, you've obviously done a lot more looking recently than I have. :-)

I'm attaching a prototype minimum timeslice patch that I threw together las=
t week.  It currently hangs during boot, but it will give you the idea of w=
hat I was thinking of.

Hui, can you let me know what you think of the idea, and if you find it int=
eresting, could you try to fix it up, and test it?  Testing it with bigger =
values like 5ms would be really interesting.

 -George

>
> Best regards,
>
> Lv, Hui
>
>
> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@citrix.com]
> Sent: Saturday, October 29, 2011 12:19 AM
> To: Dario Faggioli
> Cc: Lv, Hui; George Dunlap; Duan, Jiangang; Tian, Kevin;=20
> xen-devel@lists.xensource.com; Keir (Xen.org); Dong, Eddie
> Subject: RE: [Xen-devel] [PATCH] scheduler rate controller
>
> On Fri, 2011-10-28 at 11:09 +0100, Dario Faggioli wrote:
>> Not sure yet, I can imagine it's tricky and I need to dig a bit more=20
>> in the code, but I'll let know if I found a way of doing that...
>
> There are lots of reasons why the SCHEDULE_SOFTIRQ gets raised. =A0But I =
think we want to focus on the scheduler itself raising it as a result of th=
e .wake() callback. =A0Whether the .wake() happens as a result of a HW inte=
rrupt or something else, I don't think really matters.
>
> Dario and Hui, =A0neither of you have commented on my idea, which is simp=
ly don't preempt a VM if it has run for less than some amount of time (say,=
 500us or 1ms). =A0If a higher-priority VM is woken up, see how long the cu=
rrent VM has run. =A0If it's less than 1ms, set a 1ms timer and call schedu=
le() then.
>
>> > > More generally speaking, I see how this feature can be useful,=20
>> > > and I also think it could live in the generic schedule.c code,=20
>> > > but (as George was saying) the algorithm by which rate-limiting=20
>> > > is happening needs to be well known, documented and exposed to=20
>> > > the user (more than by means of a couple of perf-counters).
>> > >
>> >
>> > One question is that, what is the right palace to document such inform=
ation? I'd like to make it as clear as possible to the users.
>> >
>> Well, don't know, maybe a WARN (a WARN_ONCE alike thing would=20
>> probably be better), or in general something that leave a footstep in=20
>> the logs, so that one can find out by means of `xl dmesg' or related.=20
>> Obviously, I'm not suggesting of printk-ing each suppressed schedule=20
>> invocation, or the overhead would get even worse... :-P
>>
>> I'm thinking of something that happens the very first time the=20
>> limiting fires, or maybe oncee some period/number of suppressions,=20
>> just to remind the user that he's getting weird behaviour because=20
>> _he_enabled_ rate-limiting. Hopefully, that might also be useful for=20
>> the user itself to fine tune the limiting parameters, although I=20
>> think the perf-counters are already quite well suited for this.
>
> As much as possible, we want the system to Just Work. =A0Under normal cir=
cumstances it wouldn't be too unusual for a VM to have a several-ms delay b=
etween receiving a physical interrupt and being scheduled; I think that if =
the 1ms delay works, having it on all the time would probably be the best s=
olution. =A0That's another reason I'm in favor of trying it -- it's simple =
and easy to understand, and doesn't require detecting when to "turn it on".
>
> =A0-George
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_
Content-Type: application/octet-stream; name="credit_1.patch"
Content-Description: credit_1.patch
Content-Disposition: attachment; filename="credit_1.patch"; size=5123;
	creation-date="Tue, 29 Nov 2011 01:15:20 GMT";
	modification-date="Mon, 28 Nov 2011 18:16:38 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtcnVOIHhlbi5vcmkvY29tbW9uL3NjaGVkX2NyZWRpdC5jIHhlbi9jb21tb24vc2NoZWRf
Y3JlZGl0LmMKLS0tIHhlbi5vcmkvY29tbW9uL3NjaGVkX2NyZWRpdC5jCTIwMTEtMTEtMjggMDg6
NTA6NTguMDAwMDAwMDAwIC0wNTAwCisrKyB4ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCTIwMTEt
MTEtMjggMDE6NDE6MTMuMDAwMDAwMDAwIC0wNTAwCkBAIC0xMTUsNiArMTE1LDEwIEBACiBib29s
ZWFuX3BhcmFtKCJzY2hlZF9jcmVkaXRfZGVmYXVsdF95aWVsZCIsIHNjaGVkX2NyZWRpdF9kZWZh
dWx0X3lpZWxkKTsKIAogLyoKKyAqIFNjaGVkdWxlciBnZW5lcmljIHBhcmFtZXRlcnMKKyAqLwor
ZXh0ZXJuIGludCBzY2hlZF9yYXRlbGltaXRfdXM7CisvKgogICogUGh5c2ljYWwgQ1BVCiAgKi8K
IHN0cnVjdCBjc2NoZWRfcGNwdSB7CkBAIC0xMjk3LDEwICsxMzAxLDI3IEBACiAgICAgc3RydWN0
IGNzY2hlZF9wcml2YXRlICpwcnYgPSBDU0NIRURfUFJJVihvcHMpOwogICAgIHN0cnVjdCBjc2No
ZWRfdmNwdSAqc25leHQ7CiAgICAgc3RydWN0IHRhc2tfc2xpY2UgcmV0OworICAgIHNfdGltZV90
IHJ1bnRpbWUsIHRzbGljZTsKKyAgICBzdHJ1Y3Qgc2NoZWR1bGVfZGF0YSAqc2Q7CiAKICAgICBD
U0NIRURfU1RBVF9DUkFOSyhzY2hlZHVsZSk7CiAgICAgQ1NDSEVEX1ZDUFVfQ0hFQ0soY3VycmVu
dCk7CiAKKyAgICBzZCA9ICZ0aGlzX2NwdShzY2hlZHVsZV9kYXRhKTsKKyAgICBzZC0+c19jc251
bSsrOworICAgIGlmICgobm93IC0gc2QtPnNfc3JjX2IpID49IE1JTExJU0VDUyhTQ0hFRF9TUkNf
SU5URVJWQUwpKQorICAgIHsKKyAgICAgICAgaWYgKHNkLT5zX2NzbnVtID49IFNDSEVEX1NSQ19U
SFJFU0hPTEQpCisgICAgICAgICAgICBzY2hlZF9yYXRlbGltaXRfdXMgPSAxMDAwOworICAgICAg
ICBlbHNlCisgICAgICAgICAgICBzY2hlZF9yYXRlbGltaXRfdXMgPSAwOworCXNkLT5zX3NyY19i
ID0gbm93OworCXNkLT5zX2NzbnVtID0gMDsKKyAgICB9CisgICAgICAgIAorICAgIHJ1bnRpbWUg
PSBub3cgLSBjdXJyZW50LT5ydW5zdGF0ZS5zdGF0ZV9lbnRyeV90aW1lOworICAgIGlmICggcnVu
dGltZSA8IDAgKSAvKiBEb2VzIHRoaXMgZXZlciBoYXBwZW4/ICovCisgICAgICAgIHJ1bnRpbWUg
PSAwOwogICAgIGlmICggIWlzX2lkbGVfdmNwdShzY3Vyci0+dmNwdSkgKQogICAgIHsKICAgICAg
ICAgLyogVXBkYXRlIGNyZWRpdHMgb2YgYSBub24taWRsZSBWQ1BVLiAqLwpAQCAtMTMxMiw3ICsx
MzMzLDMzIEBACiAgICAgICAgIC8qIFJlLWluc3RhdGUgYSBib29zdGVkIGlkbGUgVkNQVSBhcyBu
b3JtYWwtaWRsZS4gKi8KICAgICAgICAgc2N1cnItPnByaSA9IENTQ0hFRF9QUklfSURMRTsKICAg
ICB9Ci0KKyAgICAvKiBJZiB3ZSBoYXZlIHNjaGVkdWxlIHJhdGUgbGltaXRpbmcgZW5hYmxlZCwg
Y2hlY2sgdG8gc2VlCisgICAgICogaG93IGxvbmcgd2UndmUgcnVuIGZvci4gKi8KKyAgCisgICAg
aWYgKCBzY2hlZF9yYXRlbGltaXRfdXMKKyAgICAgICAgICYmIHZjcHVfcnVubmFibGUoY3VycmVu
dCkKKyAgICAgICAgICYmICFpc19pZGxlX3ZjcHUoY3VycmVudCkKKyAgICAgICAgICYmIHJ1bnRp
bWUgPCBNSUNST1NFQ1Moc2NoZWRfcmF0ZWxpbWl0X3VzKSApCisgICAgeworICAgICAgICBzbmV4
dCA9IHNjdXJyOworICAgICAgICBwZXJmY19pbmNyKGRlbGF5X21zKTsKKyAgICAgICAgLyogRklY
TUU6IFVzZSBwcnYtPnRzbGljZV9tcyBpZiB3ZSdyZSBhbHNvIHRoZSBoZWFkIG9mIGh0ZSBxdWV1
ZSAqLworICAgICAgICAvL3RzbGljZSA9IE1JQ1JPU0VDUyhzY2hlZF9yYXRlbGltaXRfdXMpOwor
ICAgICAgICB0c2xpY2UgPSBNSUxMSVNFQ1Moc2NoZWRfcmF0ZWxpbWl0X3VzKTsKKwlyZXQudGlt
ZSA9IHRzbGljZTsKKwlyZXQudGFzayA9IHNuZXh0LT52Y3B1OworCXJldC5taWdyYXRlZCA9IDA7
CisJQ1NDSEVEX1ZDUFVfQ0hFQ0socmV0LnRhc2spOworICAgIAlyZXR1cm4gcmV0OworICAgIH0K
KyAgICBlbHNlCisgICAgeworICAgICAgICAvKgorICAgICAgICAgKiBTZWxlY3QgbmV4dCBydW5u
YWJsZSBsb2NhbCBWQ1BVIChpZSB0b3Agb2YgbG9jYWwgcnVucSkKKyAgICAgICAgICovCisgICAg
ICAgIHRzbGljZSA9IE1JTExJU0VDUyhDU0NIRURfTVNFQ1NfUEVSX1RTTElDRSk7CisgICAgfQor
ICAgIAogICAgIC8qCiAgICAgICogU2VsZWN0IG5leHQgcnVubmFibGUgbG9jYWwgVkNQVSAoaWUg
dG9wIG9mIGxvY2FsIHJ1bnEpCiAgICAgICovCkBAIC0xMzcwLDggKzE0MTcsOCBAQAogICAgIC8q
CiAgICAgICogUmV0dXJuIHRhc2sgdG8gcnVuIG5leHQuLi4KICAgICAgKi8KLSAgICByZXQudGlt
ZSA9IChpc19pZGxlX3ZjcHUoc25leHQtPnZjcHUpID8KLSAgICAgICAgICAgICAgICAtMSA6IE1J
TExJU0VDUyhDU0NIRURfTVNFQ1NfUEVSX1RTTElDRSkpOworICAgIHJldC50aW1lID0gKGlzX2lk
bGVfdmNwdShzbmV4dC0+dmNwdSkpID8KKyAgICAgICAgICAgICAgICAtMSA6IHRzbGljZTsKICAg
ICByZXQudGFzayA9IHNuZXh0LT52Y3B1OwogCiAgICAgQ1NDSEVEX1ZDUFVfQ0hFQ0socmV0LnRh
c2spOwpkaWZmIC1ydU4geGVuLm9yaS9jb21tb24vc2NoZWR1bGUuYyB4ZW4vY29tbW9uL3NjaGVk
dWxlLmMKLS0tIHhlbi5vcmkvY29tbW9uL3NjaGVkdWxlLmMJMjAxMS0xMS0yOCAwODo1MDo1OC4w
MDAwMDAwMDAgLTA1MDAKKysrIHhlbi9jb21tb24vc2NoZWR1bGUuYwkyMDExLTExLTI4IDAxOjE3
OjMwLjAwMDAwMDAwMCAtMDUwMApAQCAtNDcsNiArNDcsMTAgQEAKIGJvb2xfdCBzY2hlZF9zbXRf
cG93ZXJfc2F2aW5ncyA9IDA7CiBib29sZWFuX3BhcmFtKCJzY2hlZF9zbXRfcG93ZXJfc2F2aW5n
cyIsIHNjaGVkX3NtdF9wb3dlcl9zYXZpbmdzKTsKIAorLyogRGVmYXVsdCBzY2hlZHVsaW5nIHJh
dGUgbGltaXQ6IDFtcyAqLworaW50IHNjaGVkX3JhdGVsaW1pdF91cyA9IDEwMDA7CitpbnRlZ2Vy
X3BhcmFtKCJzY2hlZF9yYXRlbGltaXRfdXMiLCBzY2hlZF9yYXRlbGltaXRfdXMpOworCiAvKiBW
YXJpb3VzIHRpbWVyIGhhbmRsZXJzLiAqLwogc3RhdGljIHZvaWQgc190aW1lcl9mbih2b2lkICp1
bnVzZWQpOwogc3RhdGljIHZvaWQgdmNwdV9wZXJpb2RpY190aW1lcl9mbih2b2lkICpkYXRhKTsK
QEAgLTExOTcsNiArMTIwMSw4IEBACiAgICAgc2QtPmN1cnIgPSBpZGxlX3ZjcHVbY3B1XTsKICAg
ICBpbml0X3RpbWVyKCZzZC0+c190aW1lciwgc190aW1lcl9mbiwgTlVMTCwgY3B1KTsKICAgICBh
dG9taWNfc2V0KCZzZC0+dXJnZW50X2NvdW50LCAwKTsKKyAgICBzZC0+c19jc251bT0wOworICAg
IHNkLT5zX3NyY19iPTA7CiAKICAgICAvKiBCb290IENQVSBpcyBkZWFsdCB3aXRoIGxhdGVyIGlu
IHNjaGVkdWxlX2luaXQoKS4gKi8KICAgICBpZiAoIGNwdSA9PSAwICkKZGlmZiAtcnVOIHhlbi5v
cmkvaW5jbHVkZS94ZW4vcGVyZmNfZGVmbi5oIHhlbi9pbmNsdWRlL3hlbi9wZXJmY19kZWZuLmgK
LS0tIHhlbi5vcmkvaW5jbHVkZS94ZW4vcGVyZmNfZGVmbi5oCTIwMTEtMTEtMjggMDg6NTA6NTgu
MDAwMDAwMDAwIC0wNTAwCisrKyB4ZW4vaW5jbHVkZS94ZW4vcGVyZmNfZGVmbi5oCTIwMTEtMTEt
MjggMDE6MTc6MzAuMDAwMDAwMDAwIC0wNTAwCkBAIC0yMCw2ICsyMCw3IEBACiBQRVJGQ09VTlRF
UihzY2hlZHVsZSwgICAgICAgICAgICAgICAiY3NjaGVkOiBzY2hlZHVsZSIpCiBQRVJGQ09VTlRF
UihhY2N0X3J1biwgICAgICAgICAgICAgICAiY3NjaGVkOiBhY2N0X3J1biIpCiBQRVJGQ09VTlRF
UihhY2N0X25vX3dvcmssICAgICAgICAgICAiY3NjaGVkOiBhY2N0X25vX3dvcmsiKQorUEVSRkNP
VU5URVIoZGVsYXlfbXMsCQkgICAgImNzY2hlZDogMW1zIGRlbGF5IikKIFBFUkZDT1VOVEVSKGFj
Y3RfYmFsYW5jZSwgICAgICAgICAgICJjc2NoZWQ6IGFjY3RfYmFsYW5jZSIpCiBQRVJGQ09VTlRF
UihhY2N0X3Jlb3JkZXIsICAgICAgICAgICAiY3NjaGVkOiBhY2N0X3Jlb3JkZXIiKQogUEVSRkNP
VU5URVIoYWNjdF9taW5fY3JlZGl0LCAgICAgICAgImNzY2hlZDogYWNjdF9taW5fY3JlZGl0IikK
ZGlmZiAtcnVOIHhlbi5vcmkvaW5jbHVkZS94ZW4vc2NoZWQtaWYuaCB4ZW4vaW5jbHVkZS94ZW4v
c2NoZWQtaWYuaAotLS0geGVuLm9yaS9pbmNsdWRlL3hlbi9zY2hlZC1pZi5oCTIwMTEtMTEtMjgg
MDg6NTA6NTguMDAwMDAwMDAwIC0wNTAwCisrKyB4ZW4vaW5jbHVkZS94ZW4vc2NoZWQtaWYuaAky
MDExLTExLTI4IDAxOjE3OjMwLjAwMDAwMDAwMCAtMDUwMApAQCAtMTUsNiArMTUsMTAgQEAKIAog
LyogY3B1cyBjdXJyZW50bHkgaW4gbm8gY3B1cG9vbCAqLwogZXh0ZXJuIGNwdW1hc2tfdCBjcHVw
b29sX2ZyZWVfY3B1czsKKy8qIFRoZSBwZXJpb2QgdGhhdCBTUkMgdXBkYXRlZCBzY2hlZHVsZXIg
ZnJlcXVlbmN5ICovCisjZGVmaW5lIFNDSEVEX1NSQ19JTlRFUlZBTCAgICAgICAxMAorLyogVGhy
ZXNob2xkIHRvIHRyaWdnZXIgU1JDLCAgKi8KKyNkZWZpbmUgU0NIRURfU1JDX1RIUkVTSE9MRCAg
ICAgNTAKIAogLyoKICAqIEluIG9yZGVyIHRvIGFsbG93IGEgc2NoZWR1bGVyIHRvIHJlbWFwIHRo
ZSBsb2NrLT5jcHUgbWFwcGluZywKQEAgLTMyLDYgKzM2LDkgQEAKICAgICBzdHJ1Y3QgdmNwdSAg
ICAgICAgKmN1cnI7ICAgICAgICAgICAvKiBjdXJyZW50IHRhc2sgICAgICAgICAgICAgICAgICAg
ICovCiAgICAgdm9pZCAgICAgICAgICAgICAgICpzY2hlZF9wcml2OwogICAgIHN0cnVjdCB0aW1l
ciAgICAgICAgc190aW1lcjsgICAgICAgIC8qIHNjaGVkdWxpbmcgdGltZXIgICAgICAgICAgICAg
ICAgKi8KKyAgICBpbnQgICAgICAgICAgICAgICAgIHNfY3NudW07ICAgICAgICAvKiBzY2hlZHVs
aW5nIG51bWJlciBiYXNlZCBvbiBsYXN0IHBlcmlvZCAqLworICAgIHNfdGltZV90ICAgICAgICAg
ICAgc19zcmNfYjsgICAgICAgIC8qIFNSQyBjb250aW5nIHN0YXJ0IHBvaW50ICovCisgICAgYm9v
bF90ICAgICAgICAgICAgICBzX3NyY19jOyAgICAgICAgLyppbmRpY2F0ZSB3aGV0aGVyIHNyYyBz
aG91bGQgYmUgdHJpZ2dlcmVkICovCiAgICAgYXRvbWljX3QgICAgICAgICAgICB1cmdlbnRfY291
bnQ7ICAgLyogaG93IG1hbnkgdXJnZW50IHZjcHVzICAgICAgICAgICAqLwogfTsKIAo=

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_
Content-Type: application/octet-stream; name="credit_2.patch"
Content-Description: credit_2.patch
Content-Disposition: attachment; filename="credit_2.patch"; size=3454;
	creation-date="Tue, 29 Nov 2011 01:15:20 GMT";
	modification-date="Mon, 28 Nov 2011 18:16:38 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtcnVOIHhlbi5vcmkvY29tbW9uL3NjaGVkX2NyZWRpdC5jIHhlbi9jb21tb24vc2NoZWRf
Y3JlZGl0LmMKLS0tIHhlbi5vcmkvY29tbW9uL3NjaGVkX2NyZWRpdC5jCTIwMTEtMTEtMjggMDg6
NTA6NTguMDAwMDAwMDAwIC0wNTAwCisrKyB4ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCTIwMTEt
MTEtMjggMTA6MDU6MDUuMDAwMDAwMDAwIC0wNTAwCkBAIC0xMTUsNiArMTE1LDEwIEBACiBib29s
ZWFuX3BhcmFtKCJzY2hlZF9jcmVkaXRfZGVmYXVsdF95aWVsZCIsIHNjaGVkX2NyZWRpdF9kZWZh
dWx0X3lpZWxkKTsKIAogLyoKKyAqIFNjaGVkdWxlciBnZW5lcmljIHBhcmFtZXRlcnMKKyAqLwor
ZXh0ZXJuIGludCBzY2hlZF9yYXRlbGltaXRfdXM7CisvKgogICogUGh5c2ljYWwgQ1BVCiAgKi8K
IHN0cnVjdCBjc2NoZWRfcGNwdSB7CkBAIC0xMjk3LDEwICsxMzAxLDE1IEBACiAgICAgc3RydWN0
IGNzY2hlZF9wcml2YXRlICpwcnYgPSBDU0NIRURfUFJJVihvcHMpOwogICAgIHN0cnVjdCBjc2No
ZWRfdmNwdSAqc25leHQ7CiAgICAgc3RydWN0IHRhc2tfc2xpY2UgcmV0OworICAgIHNfdGltZV90
IHJ1bnRpbWUsIHRzbGljZTsKKyAgICBzdHJ1Y3Qgc2NoZWR1bGVfZGF0YSAqc2Q7CiAKICAgICBD
U0NIRURfU1RBVF9DUkFOSyhzY2hlZHVsZSk7CiAgICAgQ1NDSEVEX1ZDUFVfQ0hFQ0soY3VycmVu
dCk7CiAKKyAgICBydW50aW1lID0gbm93IC0gY3VycmVudC0+cnVuc3RhdGUuc3RhdGVfZW50cnlf
dGltZTsKKyAgICBpZiAoIHJ1bnRpbWUgPCAwICkgLyogRG9lcyB0aGlzIGV2ZXIgaGFwcGVuPyAq
LworICAgICAgICBydW50aW1lID0gMDsKICAgICBpZiAoICFpc19pZGxlX3ZjcHUoc2N1cnItPnZj
cHUpICkKICAgICB7CiAgICAgICAgIC8qIFVwZGF0ZSBjcmVkaXRzIG9mIGEgbm9uLWlkbGUgVkNQ
VS4gKi8KQEAgLTEzMTIsNyArMTMyMSwzMyBAQAogICAgICAgICAvKiBSZS1pbnN0YXRlIGEgYm9v
c3RlZCBpZGxlIFZDUFUgYXMgbm9ybWFsLWlkbGUuICovCiAgICAgICAgIHNjdXJyLT5wcmkgPSBD
U0NIRURfUFJJX0lETEU7CiAgICAgfQotCisgICAgLyogSWYgd2UgaGF2ZSBzY2hlZHVsZSByYXRl
IGxpbWl0aW5nIGVuYWJsZWQsIGNoZWNrIHRvIHNlZQorICAgICAqIGhvdyBsb25nIHdlJ3ZlIHJ1
biBmb3IuICovCisgIAorICAgIGlmICggc2NoZWRfcmF0ZWxpbWl0X3VzCisgICAgICAgICAmJiB2
Y3B1X3J1bm5hYmxlKGN1cnJlbnQpCisgICAgICAgICAmJiAhaXNfaWRsZV92Y3B1KGN1cnJlbnQp
CisgICAgICAgICAmJiBydW50aW1lIDwgTUlDUk9TRUNTKHNjaGVkX3JhdGVsaW1pdF91cykgKQor
ICAgIHsKKyAgICAgICAgc25leHQgPSBzY3VycjsKKyAgICAgICAgcGVyZmNfaW5jcihkZWxheV9t
cyk7CisgICAgICAgIC8qIEZJWE1FOiBVc2UgcHJ2LT50c2xpY2VfbXMgaWYgd2UncmUgYWxzbyB0
aGUgaGVhZCBvZiBodGUgcXVldWUgKi8KKyAgICAgICAgLy90c2xpY2UgPSBNSUNST1NFQ1Moc2No
ZWRfcmF0ZWxpbWl0X3VzKTsKKyAgICAgICAgdHNsaWNlID0gTUlMTElTRUNTKHNjaGVkX3JhdGVs
aW1pdF91cyk7CisJcmV0LnRpbWUgPSB0c2xpY2U7CisJcmV0LnRhc2sgPSBzbmV4dC0+dmNwdTsK
KwlyZXQubWlncmF0ZWQgPSAwOworCUNTQ0hFRF9WQ1BVX0NIRUNLKHJldC50YXNrKTsKKyAgICAJ
cmV0dXJuIHJldDsKKyAgICB9CisgICAgZWxzZQorICAgIHsKKyAgICAgICAgLyoKKyAgICAgICAg
ICogU2VsZWN0IG5leHQgcnVubmFibGUgbG9jYWwgVkNQVSAoaWUgdG9wIG9mIGxvY2FsIHJ1bnEp
CisgICAgICAgICAqLworICAgICAgICB0c2xpY2UgPSBNSUxMSVNFQ1MoQ1NDSEVEX01TRUNTX1BF
Ul9UU0xJQ0UpOworICAgIH0KKyAgICAKICAgICAvKgogICAgICAqIFNlbGVjdCBuZXh0IHJ1bm5h
YmxlIGxvY2FsIFZDUFUgKGllIHRvcCBvZiBsb2NhbCBydW5xKQogICAgICAqLwpAQCAtMTM3MCw4
ICsxNDA1LDggQEAKICAgICAvKgogICAgICAqIFJldHVybiB0YXNrIHRvIHJ1biBuZXh0Li4uCiAg
ICAgICovCi0gICAgcmV0LnRpbWUgPSAoaXNfaWRsZV92Y3B1KHNuZXh0LT52Y3B1KSA/Ci0gICAg
ICAgICAgICAgICAgLTEgOiBNSUxMSVNFQ1MoQ1NDSEVEX01TRUNTX1BFUl9UU0xJQ0UpKTsKKyAg
ICByZXQudGltZSA9IChpc19pZGxlX3ZjcHUoc25leHQtPnZjcHUpKSA/CisgICAgICAgICAgICAg
ICAgLTEgOiB0c2xpY2U7CiAgICAgcmV0LnRhc2sgPSBzbmV4dC0+dmNwdTsKIAogICAgIENTQ0hF
RF9WQ1BVX0NIRUNLKHJldC50YXNrKTsKZGlmZiAtcnVOIHhlbi5vcmkvY29tbW9uL3NjaGVkdWxl
LmMgeGVuL2NvbW1vbi9zY2hlZHVsZS5jCi0tLSB4ZW4ub3JpL2NvbW1vbi9zY2hlZHVsZS5jCTIw
MTEtMTEtMjggMDg6NTA6NTguMDAwMDAwMDAwIC0wNTAwCisrKyB4ZW4vY29tbW9uL3NjaGVkdWxl
LmMJMjAxMS0xMS0yOCAxMDoxMzowNi4wMDAwMDAwMDAgLTA1MDAKQEAgLTQ3LDYgKzQ3LDEwIEBA
CiBib29sX3Qgc2NoZWRfc210X3Bvd2VyX3NhdmluZ3MgPSAwOwogYm9vbGVhbl9wYXJhbSgic2No
ZWRfc210X3Bvd2VyX3NhdmluZ3MiLCBzY2hlZF9zbXRfcG93ZXJfc2F2aW5ncyk7CiAKKy8qIERl
ZmF1bHQgc2NoZWR1bGluZyByYXRlIGxpbWl0OiAxbXMgKi8KK2ludCBzY2hlZF9yYXRlbGltaXRf
dXMgPSAxMDAwOworaW50ZWdlcl9wYXJhbSgic2NoZWRfcmF0ZWxpbWl0X3VzIiwgc2NoZWRfcmF0
ZWxpbWl0X3VzKTsKKwogLyogVmFyaW91cyB0aW1lciBoYW5kbGVycy4gKi8KIHN0YXRpYyB2b2lk
IHNfdGltZXJfZm4odm9pZCAqdW51c2VkKTsKIHN0YXRpYyB2b2lkIHZjcHVfcGVyaW9kaWNfdGlt
ZXJfZm4odm9pZCAqZGF0YSk7CmRpZmYgLXJ1TiB4ZW4ub3JpL2luY2x1ZGUveGVuL3BlcmZjX2Rl
Zm4uaCB4ZW4vaW5jbHVkZS94ZW4vcGVyZmNfZGVmbi5oCi0tLSB4ZW4ub3JpL2luY2x1ZGUveGVu
L3BlcmZjX2RlZm4uaAkyMDExLTExLTI4IDA4OjUwOjU4LjAwMDAwMDAwMCAtMDUwMAorKysgeGVu
L2luY2x1ZGUveGVuL3BlcmZjX2RlZm4uaAkyMDExLTExLTI4IDAxOjE3OjMwLjAwMDAwMDAwMCAt
MDUwMApAQCAtMjAsNiArMjAsNyBAQAogUEVSRkNPVU5URVIoc2NoZWR1bGUsICAgICAgICAgICAg
ICAgImNzY2hlZDogc2NoZWR1bGUiKQogUEVSRkNPVU5URVIoYWNjdF9ydW4sICAgICAgICAgICAg
ICAgImNzY2hlZDogYWNjdF9ydW4iKQogUEVSRkNPVU5URVIoYWNjdF9ub193b3JrLCAgICAgICAg
ICAgImNzY2hlZDogYWNjdF9ub193b3JrIikKK1BFUkZDT1VOVEVSKGRlbGF5X21zLAkJICAgICJj
c2NoZWQ6IDFtcyBkZWxheSIpCiBQRVJGQ09VTlRFUihhY2N0X2JhbGFuY2UsICAgICAgICAgICAi
Y3NjaGVkOiBhY2N0X2JhbGFuY2UiKQogUEVSRkNPVU5URVIoYWNjdF9yZW9yZGVyLCAgICAgICAg
ICAgImNzY2hlZDogYWNjdF9yZW9yZGVyIikKIFBFUkZDT1VOVEVSKGFjY3RfbWluX2NyZWRpdCwg
ICAgICAgICJjc2NoZWQ6IGFjY3RfbWluX2NyZWRpdCIpCg==

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_
Content-Type: application/octet-stream; name="credit_3.patch"
Content-Description: credit_3.patch
Content-Disposition: attachment; filename="credit_3.patch"; size=3390;
	creation-date="Tue, 29 Nov 2011 01:15:20 GMT";
	modification-date="Mon, 28 Nov 2011 18:16:38 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtcnVOIHhlbi5vcmkvY29tbW9uL3NjaGVkX2NyZWRpdC5jIHhlbi5kdXAvY29tbW9uL3Nj
aGVkX2NyZWRpdC5jCi0tLSB4ZW4ub3JpL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwkyMDExLTExLTI4
IDA4OjUwOjU4LjAwMDAwMDAwMCAtMDUwMAorKysgeGVuLmR1cC9jb21tb24vc2NoZWRfY3JlZGl0
LmMJMjAxMS0xMS0yOCAxMTo0NTowNy4wMDAwMDAwMDAgLTA1MDAKQEAgLTExNSw2ICsxMTUsMTAg
QEAKIGJvb2xlYW5fcGFyYW0oInNjaGVkX2NyZWRpdF9kZWZhdWx0X3lpZWxkIiwgc2NoZWRfY3Jl
ZGl0X2RlZmF1bHRfeWllbGQpOwogCiAvKgorICogU2NoZWR1bGVyIGdlbmVyaWMgcGFyYW1ldGVy
cworICovCitleHRlcm4gaW50IHNjaGVkX3JhdGVsaW1pdF91czsKKy8qCiAgKiBQaHlzaWNhbCBD
UFUKICAqLwogc3RydWN0IGNzY2hlZF9wY3B1IHsKQEAgLTEyOTcsMTAgKzEzMDEsMTQgQEAKICAg
ICBzdHJ1Y3QgY3NjaGVkX3ByaXZhdGUgKnBydiA9IENTQ0hFRF9QUklWKG9wcyk7CiAgICAgc3Ry
dWN0IGNzY2hlZF92Y3B1ICpzbmV4dDsKICAgICBzdHJ1Y3QgdGFza19zbGljZSByZXQ7CisgICAg
c190aW1lX3QgcnVudGltZSwgdHNsaWNlOwogCiAgICAgQ1NDSEVEX1NUQVRfQ1JBTksoc2NoZWR1
bGUpOwogICAgIENTQ0hFRF9WQ1BVX0NIRUNLKGN1cnJlbnQpOwogCisgICAgcnVudGltZSA9IG5v
dyAtIGN1cnJlbnQtPnJ1bnN0YXRlLnN0YXRlX2VudHJ5X3RpbWU7CisgICAgaWYgKCBydW50aW1l
IDwgMCApIC8qIERvZXMgdGhpcyBldmVyIGhhcHBlbj8gKi8KKyAgICAgICAgcnVudGltZSA9IDA7
CiAgICAgaWYgKCAhaXNfaWRsZV92Y3B1KHNjdXJyLT52Y3B1KSApCiAgICAgewogICAgICAgICAv
KiBVcGRhdGUgY3JlZGl0cyBvZiBhIG5vbi1pZGxlIFZDUFUuICovCkBAIC0xMzIxLDcgKzEzMjks
MjggQEAKICAgICBlbHNlCiAgICAgICAgIEJVR19PTiggaXNfaWRsZV92Y3B1KGN1cnJlbnQpIHx8
IGxpc3RfZW1wdHkocnVucSkgKTsKIAotICAgIHNuZXh0ID0gX19ydW5xX2VsZW0ocnVucS0+bmV4
dCk7CisgICAgLyogSWYgd2UgaGF2ZSBzY2hlZHVsZSByYXRlIGxpbWl0aW5nIGVuYWJsZWQsIGNo
ZWNrIHRvIHNlZQorICAgICAqIGhvdyBsb25nIHdlJ3ZlIHJ1biBmb3IuICovCisgICAgaWYgKCBz
Y2hlZF9yYXRlbGltaXRfdXMKKyAgICAgICAgICYmIHZjcHVfcnVubmFibGUoY3VycmVudCkKKyAg
ICAgICAgICYmICFpc19pZGxlX3ZjcHUoY3VycmVudCkKKyAgICAgICAgICYmIHJ1bnRpbWUgPCBN
SUNST1NFQ1Moc2NoZWRfcmF0ZWxpbWl0X3VzKSApCisgICAgeworICAgICAgICBzbmV4dCA9IHNj
dXJyOworICAgICAgICBwZXJmY19pbmNyKGRlbGF5X21zKTsKKyAgICAgICAgLyogRklYTUU6IFVz
ZSBwcnYtPnRzbGljZV9tcyBpZiB3ZSdyZSBhbHNvIHRoZSBoZWFkIG9mIGh0ZSBxdWV1ZSAqLwor
ICAgICAgICAvL3RzbGljZSA9IE1JQ1JPU0VDUyhzY2hlZF9yYXRlbGltaXRfdXMpOworICAgICAg
ICB0c2xpY2UgPSBNSUxMSVNFQ1Moc2NoZWRfcmF0ZWxpbWl0X3VzKTsKKyAgICB9CisgICAgZWxz
ZQorICAgIHsKKyAgICAgICAgLyoKKyAgICAgICAgICogU2VsZWN0IG5leHQgcnVubmFibGUgbG9j
YWwgVkNQVSAoaWUgdG9wIG9mIGxvY2FsIHJ1bnEpCisgICAgICAgICAqLworICAgICAgICBzbmV4
dCA9IF9fcnVucV9lbGVtKHJ1bnEtPm5leHQpOworICAgICAgICB0c2xpY2UgPSBNSUxMSVNFQ1Mo
Q1NDSEVEX01TRUNTX1BFUl9UU0xJQ0UpOworICAgIH0KKwogICAgIHJldC5taWdyYXRlZCA9IDA7
CiAKICAgICAvKiBUYXNrbGV0IHdvcmsgKHdoaWNoIHJ1bnMgaW4gaWRsZSBWQ1BVIGNvbnRleHQp
IG92ZXJyaWRlcyBhbGwgZWxzZS4gKi8KQEAgLTEzNzAsOCArMTM5OSw4IEBACiAgICAgLyoKICAg
ICAgKiBSZXR1cm4gdGFzayB0byBydW4gbmV4dC4uLgogICAgICAqLwotICAgIHJldC50aW1lID0g
KGlzX2lkbGVfdmNwdShzbmV4dC0+dmNwdSkgPwotICAgICAgICAgICAgICAgIC0xIDogTUlMTElT
RUNTKENTQ0hFRF9NU0VDU19QRVJfVFNMSUNFKSk7CisgICAgcmV0LnRpbWUgPSAoaXNfaWRsZV92
Y3B1KHNuZXh0LT52Y3B1KSkgPworICAgICAgICAgICAgICAgIC0xIDogdHNsaWNlOwogICAgIHJl
dC50YXNrID0gc25leHQtPnZjcHU7CiAKICAgICBDU0NIRURfVkNQVV9DSEVDSyhyZXQudGFzayk7
CmRpZmYgLXJ1TiB4ZW4ub3JpL2NvbW1vbi9zY2hlZHVsZS5jIHhlbi5kdXAvY29tbW9uL3NjaGVk
dWxlLmMKLS0tIHhlbi5vcmkvY29tbW9uL3NjaGVkdWxlLmMJMjAxMS0xMS0yOCAwODo1MDo1OC4w
MDAwMDAwMDAgLTA1MDAKKysrIHhlbi5kdXAvY29tbW9uL3NjaGVkdWxlLmMJMjAxMS0xMS0yOCAx
MTo0NToyMy4wMDAwMDAwMDAgLTA1MDAKQEAgLTQ3LDYgKzQ3LDEwIEBACiBib29sX3Qgc2NoZWRf
c210X3Bvd2VyX3NhdmluZ3MgPSAwOwogYm9vbGVhbl9wYXJhbSgic2NoZWRfc210X3Bvd2VyX3Nh
dmluZ3MiLCBzY2hlZF9zbXRfcG93ZXJfc2F2aW5ncyk7CiAKKy8qIERlZmF1bHQgc2NoZWR1bGlu
ZyByYXRlIGxpbWl0OiAxbXMgKi8KK2ludCBzY2hlZF9yYXRlbGltaXRfdXMgPSAxMDAwOworaW50
ZWdlcl9wYXJhbSgic2NoZWRfcmF0ZWxpbWl0X3VzIiwgc2NoZWRfcmF0ZWxpbWl0X3VzKTsKKwog
LyogVmFyaW91cyB0aW1lciBoYW5kbGVycy4gKi8KIHN0YXRpYyB2b2lkIHNfdGltZXJfZm4odm9p
ZCAqdW51c2VkKTsKIHN0YXRpYyB2b2lkIHZjcHVfcGVyaW9kaWNfdGltZXJfZm4odm9pZCAqZGF0
YSk7CmRpZmYgLXJ1TiB4ZW4ub3JpL2luY2x1ZGUveGVuL3BlcmZjX2RlZm4uaCB4ZW4uZHVwL2lu
Y2x1ZGUveGVuL3BlcmZjX2RlZm4uaAotLS0geGVuLm9yaS9pbmNsdWRlL3hlbi9wZXJmY19kZWZu
LmgJMjAxMS0xMS0yOCAwODo1MDo1OC4wMDAwMDAwMDAgLTA1MDAKKysrIHhlbi5kdXAvaW5jbHVk
ZS94ZW4vcGVyZmNfZGVmbi5oCTIwMTEtMTEtMjggMDE6MTc6MzEuMDAwMDAwMDAwIC0wNTAwCkBA
IC0yMCw2ICsyMCw3IEBACiBQRVJGQ09VTlRFUihzY2hlZHVsZSwgICAgICAgICAgICAgICAiY3Nj
aGVkOiBzY2hlZHVsZSIpCiBQRVJGQ09VTlRFUihhY2N0X3J1biwgICAgICAgICAgICAgICAiY3Nj
aGVkOiBhY2N0X3J1biIpCiBQRVJGQ09VTlRFUihhY2N0X25vX3dvcmssICAgICAgICAgICAiY3Nj
aGVkOiBhY2N0X25vX3dvcmsiKQorUEVSRkNPVU5URVIoZGVsYXlfbXMsCQkgICAgImNzY2hlZDog
MW1zIGRlbGF5IikKIFBFUkZDT1VOVEVSKGFjY3RfYmFsYW5jZSwgICAgICAgICAgICJjc2NoZWQ6
IGFjY3RfYmFsYW5jZSIpCiBQRVJGQ09VTlRFUihhY2N0X3Jlb3JkZXIsICAgICAgICAgICAiY3Nj
aGVkOiBhY2N0X3Jlb3JkZXIiKQogUEVSRkNPVU5URVIoYWNjdF9taW5fY3JlZGl0LCAgICAgICAg
ImNzY2hlZDogYWNjdF9taW5fY3JlZGl0IikK

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:32:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:32:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV53Y-0007Iy-Ta; Mon, 28 Nov 2011 17:31:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hui.lv@intel.com>) id 1RV53X-0007Ih-EF
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:31:51 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322501473!3246869!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzE4NDMw\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1508 invoked from network); 28 Nov 2011 17:31:13 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-174.messagelabs.com with SMTP;
	28 Nov 2011 17:31:13 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 28 Nov 2011 09:31:11 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="80739105"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 28 Nov 2011 09:31:09 -0800
Received: from pgsmsx104.gar.corp.intel.com (10.221.44.91) by
	pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 29 Nov 2011 01:31:09 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 29 Nov 2011 01:31:08 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Tue, 29 Nov 2011 01:31:07 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Tue, 29 Nov 2011 01:31:05 +0800
Thread-Topic: [Xen-devel] [PATCH] scheduler rate controller
Thread-Index: AcyZ4Rf7B2HWuje3SsSqNqOisGKDgwUEEO3w
Message-ID: <C10D3FB0CD45994C8A51FEC1227CE22F37499C2733@shsmsx502.ccr.corp.intel.com>
References: <C10D3FB0CD45994C8A51FEC1227CE22F340768D793@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB5EF9@shsmsx502.ccr.corp.intel.com>
	<1319789425.19320.12.camel@Abyss>
	<C10D3FB0CD45994C8A51FEC1227CE22F3428CB61F2@shsmsx502.ccr.corp.intel.com>
	<1319796584.19320.31.camel@Abyss>	<1319818714.21033.414.camel@elijah>
	<C10D3FB0CD45994C8A51FEC1227CE22F34B3905D03@shsmsx502.ccr.corp.intel.com>
	<CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
In-Reply-To: <CAFLBxZa5v_YgnC1LTa4a5wis4h6eQPijCAfUDLDsR4ucMuBXWg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed;
	boundary="_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_"
MIME-Version: 1.0
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	George Dunlap <george.dunlap@citrix.com>, "Duan, 
	Jiangang" <jiangang.duan@intel.com>, Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, George

Sorry for the late. I also met issues to boot up xen according to your patc=
h, which is same as credit_3.patch that I attached.
So I modified it to the credit_1.patch and credit_2.patch, both of which wo=
rk well.
1) credit_1 adopts "scheduling frequency counting" to decide the value of s=
ched_ratelimit_us, which makes it adaptive.
2) credit_2 adopts the constant sched_ratelimit_us value 1000.=20

Although the performance comparison data is still in process, I want to hea=
r some feedbacks from you.=20
I think I shall share the data very soon when the system becomes stable.


Best regards,

Lv, Hui


-----Original Message-----
From: dunlapg@gmail.com [mailto:dunlapg@gmail.com] On Behalf Of George Dunl=
ap
Sent: Thursday, November 03, 2011 12:29 PM
To: Lv, Hui
Cc: George Dunlap; Dario Faggioli; Tian, Kevin; xen-devel@lists.xensource.c=
om; Keir (Xen.org); Dong, Eddie; Duan, Jiangang
Subject: Re: [Xen-devel] [PATCH] scheduler rate controller

On Sat, Oct 29, 2011 at 11:05 AM, Lv, Hui <hui.lv@intel.com> wrote:
> I have tried one way very similar as your idea.
> 1) to check whether current running vcpu runs less than 1ms, if yes, we w=
ill return current vcpu directly without preemption.
> It try to guarantee vcpu to run as long as 1ms, if it wants.
> It can reduce the scheduling frequency to some degree, but not very signi=
ficant. Because 1ms is too light/weak with comparison to 10ms delay (SRC pa=
tch used).

Hey Hui,  Sorry for the delay in response -- FYI I'm at the XenSummit Korea=
 now, and I'll be on holiday next week.

Do you have the patch that you wrote for the 1ms delay handy, and any numbe=
rs that you ran?  I'm a bit surprised that a 1ms delay didn't have much eff=
ect; but in any case, it seems dialing that up should have a similar effect=
 -- e.g., if we changed that to 10ms, then it should have a similar effect =
to the patch that you sent before.

> As you said, if applying the seveal_ms_delay, it will happen whenever=20
> system is normal or not (excessive frequency). It may possible have=20
> the consequence that 1)under normal condition, it will produce worse=20
> Qos than that without applying such delay,

Perhaps; but the current credit scheduler may already allow a VM to run exc=
lusively for 30ms, so I don't think that overall it should have a big influ=
ence.

> 2) under excessive frequency condition, the mitigation effect of 1ms-dela=
y may be too weak. In addition, your idea is to delay scheduling instead of=
 reducing, which means the total number of scheduling would probably not ch=
ange.

Well it will prevent preemption; so as long as at least one VM does not yie=
ld, it will reduce the number of schedule events to 1000 times per second. =
 If all VMs yield, then you can't really reduce the number of scheduling ev=
ents anyway (even with your preemption-disable patch).

> I think one possible solution, is to make the value of 1ms-delay=20
> adaptive according to the system status (low load or high load). If=20
> so, SRC patch just covered the excessive condition currently :).=20
> That's why I mentioned to treat normal and excessive conditions=20
> separately and don't influence the normal case as much as possible.=20
> Because we never know the consequence without amount of testing work.=20
> :)

Yes, exactly. :-)

> Some of my stupid thinking :)

Well, you've obviously done a lot more looking recently than I have. :-)

I'm attaching a prototype minimum timeslice patch that I threw together las=
t week.  It currently hangs during boot, but it will give you the idea of w=
hat I was thinking of.

Hui, can you let me know what you think of the idea, and if you find it int=
eresting, could you try to fix it up, and test it?  Testing it with bigger =
values like 5ms would be really interesting.

 -George

>
> Best regards,
>
> Lv, Hui
>
>
> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@citrix.com]
> Sent: Saturday, October 29, 2011 12:19 AM
> To: Dario Faggioli
> Cc: Lv, Hui; George Dunlap; Duan, Jiangang; Tian, Kevin;=20
> xen-devel@lists.xensource.com; Keir (Xen.org); Dong, Eddie
> Subject: RE: [Xen-devel] [PATCH] scheduler rate controller
>
> On Fri, 2011-10-28 at 11:09 +0100, Dario Faggioli wrote:
>> Not sure yet, I can imagine it's tricky and I need to dig a bit more=20
>> in the code, but I'll let know if I found a way of doing that...
>
> There are lots of reasons why the SCHEDULE_SOFTIRQ gets raised. =A0But I =
think we want to focus on the scheduler itself raising it as a result of th=
e .wake() callback. =A0Whether the .wake() happens as a result of a HW inte=
rrupt or something else, I don't think really matters.
>
> Dario and Hui, =A0neither of you have commented on my idea, which is simp=
ly don't preempt a VM if it has run for less than some amount of time (say,=
 500us or 1ms). =A0If a higher-priority VM is woken up, see how long the cu=
rrent VM has run. =A0If it's less than 1ms, set a 1ms timer and call schedu=
le() then.
>
>> > > More generally speaking, I see how this feature can be useful,=20
>> > > and I also think it could live in the generic schedule.c code,=20
>> > > but (as George was saying) the algorithm by which rate-limiting=20
>> > > is happening needs to be well known, documented and exposed to=20
>> > > the user (more than by means of a couple of perf-counters).
>> > >
>> >
>> > One question is that, what is the right palace to document such inform=
ation? I'd like to make it as clear as possible to the users.
>> >
>> Well, don't know, maybe a WARN (a WARN_ONCE alike thing would=20
>> probably be better), or in general something that leave a footstep in=20
>> the logs, so that one can find out by means of `xl dmesg' or related.=20
>> Obviously, I'm not suggesting of printk-ing each suppressed schedule=20
>> invocation, or the overhead would get even worse... :-P
>>
>> I'm thinking of something that happens the very first time the=20
>> limiting fires, or maybe oncee some period/number of suppressions,=20
>> just to remind the user that he's getting weird behaviour because=20
>> _he_enabled_ rate-limiting. Hopefully, that might also be useful for=20
>> the user itself to fine tune the limiting parameters, although I=20
>> think the perf-counters are already quite well suited for this.
>
> As much as possible, we want the system to Just Work. =A0Under normal cir=
cumstances it wouldn't be too unusual for a VM to have a several-ms delay b=
etween receiving a physical interrupt and being scheduled; I think that if =
the 1ms delay works, having it on all the time would probably be the best s=
olution. =A0That's another reason I'm in favor of trying it -- it's simple =
and easy to understand, and doesn't require detecting when to "turn it on".
>
> =A0-George
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_
Content-Type: application/octet-stream; name="credit_1.patch"
Content-Description: credit_1.patch
Content-Disposition: attachment; filename="credit_1.patch"; size=5123;
	creation-date="Tue, 29 Nov 2011 01:15:20 GMT";
	modification-date="Mon, 28 Nov 2011 18:16:38 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtcnVOIHhlbi5vcmkvY29tbW9uL3NjaGVkX2NyZWRpdC5jIHhlbi9jb21tb24vc2NoZWRf
Y3JlZGl0LmMKLS0tIHhlbi5vcmkvY29tbW9uL3NjaGVkX2NyZWRpdC5jCTIwMTEtMTEtMjggMDg6
NTA6NTguMDAwMDAwMDAwIC0wNTAwCisrKyB4ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCTIwMTEt
MTEtMjggMDE6NDE6MTMuMDAwMDAwMDAwIC0wNTAwCkBAIC0xMTUsNiArMTE1LDEwIEBACiBib29s
ZWFuX3BhcmFtKCJzY2hlZF9jcmVkaXRfZGVmYXVsdF95aWVsZCIsIHNjaGVkX2NyZWRpdF9kZWZh
dWx0X3lpZWxkKTsKIAogLyoKKyAqIFNjaGVkdWxlciBnZW5lcmljIHBhcmFtZXRlcnMKKyAqLwor
ZXh0ZXJuIGludCBzY2hlZF9yYXRlbGltaXRfdXM7CisvKgogICogUGh5c2ljYWwgQ1BVCiAgKi8K
IHN0cnVjdCBjc2NoZWRfcGNwdSB7CkBAIC0xMjk3LDEwICsxMzAxLDI3IEBACiAgICAgc3RydWN0
IGNzY2hlZF9wcml2YXRlICpwcnYgPSBDU0NIRURfUFJJVihvcHMpOwogICAgIHN0cnVjdCBjc2No
ZWRfdmNwdSAqc25leHQ7CiAgICAgc3RydWN0IHRhc2tfc2xpY2UgcmV0OworICAgIHNfdGltZV90
IHJ1bnRpbWUsIHRzbGljZTsKKyAgICBzdHJ1Y3Qgc2NoZWR1bGVfZGF0YSAqc2Q7CiAKICAgICBD
U0NIRURfU1RBVF9DUkFOSyhzY2hlZHVsZSk7CiAgICAgQ1NDSEVEX1ZDUFVfQ0hFQ0soY3VycmVu
dCk7CiAKKyAgICBzZCA9ICZ0aGlzX2NwdShzY2hlZHVsZV9kYXRhKTsKKyAgICBzZC0+c19jc251
bSsrOworICAgIGlmICgobm93IC0gc2QtPnNfc3JjX2IpID49IE1JTExJU0VDUyhTQ0hFRF9TUkNf
SU5URVJWQUwpKQorICAgIHsKKyAgICAgICAgaWYgKHNkLT5zX2NzbnVtID49IFNDSEVEX1NSQ19U
SFJFU0hPTEQpCisgICAgICAgICAgICBzY2hlZF9yYXRlbGltaXRfdXMgPSAxMDAwOworICAgICAg
ICBlbHNlCisgICAgICAgICAgICBzY2hlZF9yYXRlbGltaXRfdXMgPSAwOworCXNkLT5zX3NyY19i
ID0gbm93OworCXNkLT5zX2NzbnVtID0gMDsKKyAgICB9CisgICAgICAgIAorICAgIHJ1bnRpbWUg
PSBub3cgLSBjdXJyZW50LT5ydW5zdGF0ZS5zdGF0ZV9lbnRyeV90aW1lOworICAgIGlmICggcnVu
dGltZSA8IDAgKSAvKiBEb2VzIHRoaXMgZXZlciBoYXBwZW4/ICovCisgICAgICAgIHJ1bnRpbWUg
PSAwOwogICAgIGlmICggIWlzX2lkbGVfdmNwdShzY3Vyci0+dmNwdSkgKQogICAgIHsKICAgICAg
ICAgLyogVXBkYXRlIGNyZWRpdHMgb2YgYSBub24taWRsZSBWQ1BVLiAqLwpAQCAtMTMxMiw3ICsx
MzMzLDMzIEBACiAgICAgICAgIC8qIFJlLWluc3RhdGUgYSBib29zdGVkIGlkbGUgVkNQVSBhcyBu
b3JtYWwtaWRsZS4gKi8KICAgICAgICAgc2N1cnItPnByaSA9IENTQ0hFRF9QUklfSURMRTsKICAg
ICB9Ci0KKyAgICAvKiBJZiB3ZSBoYXZlIHNjaGVkdWxlIHJhdGUgbGltaXRpbmcgZW5hYmxlZCwg
Y2hlY2sgdG8gc2VlCisgICAgICogaG93IGxvbmcgd2UndmUgcnVuIGZvci4gKi8KKyAgCisgICAg
aWYgKCBzY2hlZF9yYXRlbGltaXRfdXMKKyAgICAgICAgICYmIHZjcHVfcnVubmFibGUoY3VycmVu
dCkKKyAgICAgICAgICYmICFpc19pZGxlX3ZjcHUoY3VycmVudCkKKyAgICAgICAgICYmIHJ1bnRp
bWUgPCBNSUNST1NFQ1Moc2NoZWRfcmF0ZWxpbWl0X3VzKSApCisgICAgeworICAgICAgICBzbmV4
dCA9IHNjdXJyOworICAgICAgICBwZXJmY19pbmNyKGRlbGF5X21zKTsKKyAgICAgICAgLyogRklY
TUU6IFVzZSBwcnYtPnRzbGljZV9tcyBpZiB3ZSdyZSBhbHNvIHRoZSBoZWFkIG9mIGh0ZSBxdWV1
ZSAqLworICAgICAgICAvL3RzbGljZSA9IE1JQ1JPU0VDUyhzY2hlZF9yYXRlbGltaXRfdXMpOwor
ICAgICAgICB0c2xpY2UgPSBNSUxMSVNFQ1Moc2NoZWRfcmF0ZWxpbWl0X3VzKTsKKwlyZXQudGlt
ZSA9IHRzbGljZTsKKwlyZXQudGFzayA9IHNuZXh0LT52Y3B1OworCXJldC5taWdyYXRlZCA9IDA7
CisJQ1NDSEVEX1ZDUFVfQ0hFQ0socmV0LnRhc2spOworICAgIAlyZXR1cm4gcmV0OworICAgIH0K
KyAgICBlbHNlCisgICAgeworICAgICAgICAvKgorICAgICAgICAgKiBTZWxlY3QgbmV4dCBydW5u
YWJsZSBsb2NhbCBWQ1BVIChpZSB0b3Agb2YgbG9jYWwgcnVucSkKKyAgICAgICAgICovCisgICAg
ICAgIHRzbGljZSA9IE1JTExJU0VDUyhDU0NIRURfTVNFQ1NfUEVSX1RTTElDRSk7CisgICAgfQor
ICAgIAogICAgIC8qCiAgICAgICogU2VsZWN0IG5leHQgcnVubmFibGUgbG9jYWwgVkNQVSAoaWUg
dG9wIG9mIGxvY2FsIHJ1bnEpCiAgICAgICovCkBAIC0xMzcwLDggKzE0MTcsOCBAQAogICAgIC8q
CiAgICAgICogUmV0dXJuIHRhc2sgdG8gcnVuIG5leHQuLi4KICAgICAgKi8KLSAgICByZXQudGlt
ZSA9IChpc19pZGxlX3ZjcHUoc25leHQtPnZjcHUpID8KLSAgICAgICAgICAgICAgICAtMSA6IE1J
TExJU0VDUyhDU0NIRURfTVNFQ1NfUEVSX1RTTElDRSkpOworICAgIHJldC50aW1lID0gKGlzX2lk
bGVfdmNwdShzbmV4dC0+dmNwdSkpID8KKyAgICAgICAgICAgICAgICAtMSA6IHRzbGljZTsKICAg
ICByZXQudGFzayA9IHNuZXh0LT52Y3B1OwogCiAgICAgQ1NDSEVEX1ZDUFVfQ0hFQ0socmV0LnRh
c2spOwpkaWZmIC1ydU4geGVuLm9yaS9jb21tb24vc2NoZWR1bGUuYyB4ZW4vY29tbW9uL3NjaGVk
dWxlLmMKLS0tIHhlbi5vcmkvY29tbW9uL3NjaGVkdWxlLmMJMjAxMS0xMS0yOCAwODo1MDo1OC4w
MDAwMDAwMDAgLTA1MDAKKysrIHhlbi9jb21tb24vc2NoZWR1bGUuYwkyMDExLTExLTI4IDAxOjE3
OjMwLjAwMDAwMDAwMCAtMDUwMApAQCAtNDcsNiArNDcsMTAgQEAKIGJvb2xfdCBzY2hlZF9zbXRf
cG93ZXJfc2F2aW5ncyA9IDA7CiBib29sZWFuX3BhcmFtKCJzY2hlZF9zbXRfcG93ZXJfc2F2aW5n
cyIsIHNjaGVkX3NtdF9wb3dlcl9zYXZpbmdzKTsKIAorLyogRGVmYXVsdCBzY2hlZHVsaW5nIHJh
dGUgbGltaXQ6IDFtcyAqLworaW50IHNjaGVkX3JhdGVsaW1pdF91cyA9IDEwMDA7CitpbnRlZ2Vy
X3BhcmFtKCJzY2hlZF9yYXRlbGltaXRfdXMiLCBzY2hlZF9yYXRlbGltaXRfdXMpOworCiAvKiBW
YXJpb3VzIHRpbWVyIGhhbmRsZXJzLiAqLwogc3RhdGljIHZvaWQgc190aW1lcl9mbih2b2lkICp1
bnVzZWQpOwogc3RhdGljIHZvaWQgdmNwdV9wZXJpb2RpY190aW1lcl9mbih2b2lkICpkYXRhKTsK
QEAgLTExOTcsNiArMTIwMSw4IEBACiAgICAgc2QtPmN1cnIgPSBpZGxlX3ZjcHVbY3B1XTsKICAg
ICBpbml0X3RpbWVyKCZzZC0+c190aW1lciwgc190aW1lcl9mbiwgTlVMTCwgY3B1KTsKICAgICBh
dG9taWNfc2V0KCZzZC0+dXJnZW50X2NvdW50LCAwKTsKKyAgICBzZC0+c19jc251bT0wOworICAg
IHNkLT5zX3NyY19iPTA7CiAKICAgICAvKiBCb290IENQVSBpcyBkZWFsdCB3aXRoIGxhdGVyIGlu
IHNjaGVkdWxlX2luaXQoKS4gKi8KICAgICBpZiAoIGNwdSA9PSAwICkKZGlmZiAtcnVOIHhlbi5v
cmkvaW5jbHVkZS94ZW4vcGVyZmNfZGVmbi5oIHhlbi9pbmNsdWRlL3hlbi9wZXJmY19kZWZuLmgK
LS0tIHhlbi5vcmkvaW5jbHVkZS94ZW4vcGVyZmNfZGVmbi5oCTIwMTEtMTEtMjggMDg6NTA6NTgu
MDAwMDAwMDAwIC0wNTAwCisrKyB4ZW4vaW5jbHVkZS94ZW4vcGVyZmNfZGVmbi5oCTIwMTEtMTEt
MjggMDE6MTc6MzAuMDAwMDAwMDAwIC0wNTAwCkBAIC0yMCw2ICsyMCw3IEBACiBQRVJGQ09VTlRF
UihzY2hlZHVsZSwgICAgICAgICAgICAgICAiY3NjaGVkOiBzY2hlZHVsZSIpCiBQRVJGQ09VTlRF
UihhY2N0X3J1biwgICAgICAgICAgICAgICAiY3NjaGVkOiBhY2N0X3J1biIpCiBQRVJGQ09VTlRF
UihhY2N0X25vX3dvcmssICAgICAgICAgICAiY3NjaGVkOiBhY2N0X25vX3dvcmsiKQorUEVSRkNP
VU5URVIoZGVsYXlfbXMsCQkgICAgImNzY2hlZDogMW1zIGRlbGF5IikKIFBFUkZDT1VOVEVSKGFj
Y3RfYmFsYW5jZSwgICAgICAgICAgICJjc2NoZWQ6IGFjY3RfYmFsYW5jZSIpCiBQRVJGQ09VTlRF
UihhY2N0X3Jlb3JkZXIsICAgICAgICAgICAiY3NjaGVkOiBhY2N0X3Jlb3JkZXIiKQogUEVSRkNP
VU5URVIoYWNjdF9taW5fY3JlZGl0LCAgICAgICAgImNzY2hlZDogYWNjdF9taW5fY3JlZGl0IikK
ZGlmZiAtcnVOIHhlbi5vcmkvaW5jbHVkZS94ZW4vc2NoZWQtaWYuaCB4ZW4vaW5jbHVkZS94ZW4v
c2NoZWQtaWYuaAotLS0geGVuLm9yaS9pbmNsdWRlL3hlbi9zY2hlZC1pZi5oCTIwMTEtMTEtMjgg
MDg6NTA6NTguMDAwMDAwMDAwIC0wNTAwCisrKyB4ZW4vaW5jbHVkZS94ZW4vc2NoZWQtaWYuaAky
MDExLTExLTI4IDAxOjE3OjMwLjAwMDAwMDAwMCAtMDUwMApAQCAtMTUsNiArMTUsMTAgQEAKIAog
LyogY3B1cyBjdXJyZW50bHkgaW4gbm8gY3B1cG9vbCAqLwogZXh0ZXJuIGNwdW1hc2tfdCBjcHVw
b29sX2ZyZWVfY3B1czsKKy8qIFRoZSBwZXJpb2QgdGhhdCBTUkMgdXBkYXRlZCBzY2hlZHVsZXIg
ZnJlcXVlbmN5ICovCisjZGVmaW5lIFNDSEVEX1NSQ19JTlRFUlZBTCAgICAgICAxMAorLyogVGhy
ZXNob2xkIHRvIHRyaWdnZXIgU1JDLCAgKi8KKyNkZWZpbmUgU0NIRURfU1JDX1RIUkVTSE9MRCAg
ICAgNTAKIAogLyoKICAqIEluIG9yZGVyIHRvIGFsbG93IGEgc2NoZWR1bGVyIHRvIHJlbWFwIHRo
ZSBsb2NrLT5jcHUgbWFwcGluZywKQEAgLTMyLDYgKzM2LDkgQEAKICAgICBzdHJ1Y3QgdmNwdSAg
ICAgICAgKmN1cnI7ICAgICAgICAgICAvKiBjdXJyZW50IHRhc2sgICAgICAgICAgICAgICAgICAg
ICovCiAgICAgdm9pZCAgICAgICAgICAgICAgICpzY2hlZF9wcml2OwogICAgIHN0cnVjdCB0aW1l
ciAgICAgICAgc190aW1lcjsgICAgICAgIC8qIHNjaGVkdWxpbmcgdGltZXIgICAgICAgICAgICAg
ICAgKi8KKyAgICBpbnQgICAgICAgICAgICAgICAgIHNfY3NudW07ICAgICAgICAvKiBzY2hlZHVs
aW5nIG51bWJlciBiYXNlZCBvbiBsYXN0IHBlcmlvZCAqLworICAgIHNfdGltZV90ICAgICAgICAg
ICAgc19zcmNfYjsgICAgICAgIC8qIFNSQyBjb250aW5nIHN0YXJ0IHBvaW50ICovCisgICAgYm9v
bF90ICAgICAgICAgICAgICBzX3NyY19jOyAgICAgICAgLyppbmRpY2F0ZSB3aGV0aGVyIHNyYyBz
aG91bGQgYmUgdHJpZ2dlcmVkICovCiAgICAgYXRvbWljX3QgICAgICAgICAgICB1cmdlbnRfY291
bnQ7ICAgLyogaG93IG1hbnkgdXJnZW50IHZjcHVzICAgICAgICAgICAqLwogfTsKIAo=

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_
Content-Type: application/octet-stream; name="credit_2.patch"
Content-Description: credit_2.patch
Content-Disposition: attachment; filename="credit_2.patch"; size=3454;
	creation-date="Tue, 29 Nov 2011 01:15:20 GMT";
	modification-date="Mon, 28 Nov 2011 18:16:38 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtcnVOIHhlbi5vcmkvY29tbW9uL3NjaGVkX2NyZWRpdC5jIHhlbi9jb21tb24vc2NoZWRf
Y3JlZGl0LmMKLS0tIHhlbi5vcmkvY29tbW9uL3NjaGVkX2NyZWRpdC5jCTIwMTEtMTEtMjggMDg6
NTA6NTguMDAwMDAwMDAwIC0wNTAwCisrKyB4ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jCTIwMTEt
MTEtMjggMTA6MDU6MDUuMDAwMDAwMDAwIC0wNTAwCkBAIC0xMTUsNiArMTE1LDEwIEBACiBib29s
ZWFuX3BhcmFtKCJzY2hlZF9jcmVkaXRfZGVmYXVsdF95aWVsZCIsIHNjaGVkX2NyZWRpdF9kZWZh
dWx0X3lpZWxkKTsKIAogLyoKKyAqIFNjaGVkdWxlciBnZW5lcmljIHBhcmFtZXRlcnMKKyAqLwor
ZXh0ZXJuIGludCBzY2hlZF9yYXRlbGltaXRfdXM7CisvKgogICogUGh5c2ljYWwgQ1BVCiAgKi8K
IHN0cnVjdCBjc2NoZWRfcGNwdSB7CkBAIC0xMjk3LDEwICsxMzAxLDE1IEBACiAgICAgc3RydWN0
IGNzY2hlZF9wcml2YXRlICpwcnYgPSBDU0NIRURfUFJJVihvcHMpOwogICAgIHN0cnVjdCBjc2No
ZWRfdmNwdSAqc25leHQ7CiAgICAgc3RydWN0IHRhc2tfc2xpY2UgcmV0OworICAgIHNfdGltZV90
IHJ1bnRpbWUsIHRzbGljZTsKKyAgICBzdHJ1Y3Qgc2NoZWR1bGVfZGF0YSAqc2Q7CiAKICAgICBD
U0NIRURfU1RBVF9DUkFOSyhzY2hlZHVsZSk7CiAgICAgQ1NDSEVEX1ZDUFVfQ0hFQ0soY3VycmVu
dCk7CiAKKyAgICBydW50aW1lID0gbm93IC0gY3VycmVudC0+cnVuc3RhdGUuc3RhdGVfZW50cnlf
dGltZTsKKyAgICBpZiAoIHJ1bnRpbWUgPCAwICkgLyogRG9lcyB0aGlzIGV2ZXIgaGFwcGVuPyAq
LworICAgICAgICBydW50aW1lID0gMDsKICAgICBpZiAoICFpc19pZGxlX3ZjcHUoc2N1cnItPnZj
cHUpICkKICAgICB7CiAgICAgICAgIC8qIFVwZGF0ZSBjcmVkaXRzIG9mIGEgbm9uLWlkbGUgVkNQ
VS4gKi8KQEAgLTEzMTIsNyArMTMyMSwzMyBAQAogICAgICAgICAvKiBSZS1pbnN0YXRlIGEgYm9v
c3RlZCBpZGxlIFZDUFUgYXMgbm9ybWFsLWlkbGUuICovCiAgICAgICAgIHNjdXJyLT5wcmkgPSBD
U0NIRURfUFJJX0lETEU7CiAgICAgfQotCisgICAgLyogSWYgd2UgaGF2ZSBzY2hlZHVsZSByYXRl
IGxpbWl0aW5nIGVuYWJsZWQsIGNoZWNrIHRvIHNlZQorICAgICAqIGhvdyBsb25nIHdlJ3ZlIHJ1
biBmb3IuICovCisgIAorICAgIGlmICggc2NoZWRfcmF0ZWxpbWl0X3VzCisgICAgICAgICAmJiB2
Y3B1X3J1bm5hYmxlKGN1cnJlbnQpCisgICAgICAgICAmJiAhaXNfaWRsZV92Y3B1KGN1cnJlbnQp
CisgICAgICAgICAmJiBydW50aW1lIDwgTUlDUk9TRUNTKHNjaGVkX3JhdGVsaW1pdF91cykgKQor
ICAgIHsKKyAgICAgICAgc25leHQgPSBzY3VycjsKKyAgICAgICAgcGVyZmNfaW5jcihkZWxheV9t
cyk7CisgICAgICAgIC8qIEZJWE1FOiBVc2UgcHJ2LT50c2xpY2VfbXMgaWYgd2UncmUgYWxzbyB0
aGUgaGVhZCBvZiBodGUgcXVldWUgKi8KKyAgICAgICAgLy90c2xpY2UgPSBNSUNST1NFQ1Moc2No
ZWRfcmF0ZWxpbWl0X3VzKTsKKyAgICAgICAgdHNsaWNlID0gTUlMTElTRUNTKHNjaGVkX3JhdGVs
aW1pdF91cyk7CisJcmV0LnRpbWUgPSB0c2xpY2U7CisJcmV0LnRhc2sgPSBzbmV4dC0+dmNwdTsK
KwlyZXQubWlncmF0ZWQgPSAwOworCUNTQ0hFRF9WQ1BVX0NIRUNLKHJldC50YXNrKTsKKyAgICAJ
cmV0dXJuIHJldDsKKyAgICB9CisgICAgZWxzZQorICAgIHsKKyAgICAgICAgLyoKKyAgICAgICAg
ICogU2VsZWN0IG5leHQgcnVubmFibGUgbG9jYWwgVkNQVSAoaWUgdG9wIG9mIGxvY2FsIHJ1bnEp
CisgICAgICAgICAqLworICAgICAgICB0c2xpY2UgPSBNSUxMSVNFQ1MoQ1NDSEVEX01TRUNTX1BF
Ul9UU0xJQ0UpOworICAgIH0KKyAgICAKICAgICAvKgogICAgICAqIFNlbGVjdCBuZXh0IHJ1bm5h
YmxlIGxvY2FsIFZDUFUgKGllIHRvcCBvZiBsb2NhbCBydW5xKQogICAgICAqLwpAQCAtMTM3MCw4
ICsxNDA1LDggQEAKICAgICAvKgogICAgICAqIFJldHVybiB0YXNrIHRvIHJ1biBuZXh0Li4uCiAg
ICAgICovCi0gICAgcmV0LnRpbWUgPSAoaXNfaWRsZV92Y3B1KHNuZXh0LT52Y3B1KSA/Ci0gICAg
ICAgICAgICAgICAgLTEgOiBNSUxMSVNFQ1MoQ1NDSEVEX01TRUNTX1BFUl9UU0xJQ0UpKTsKKyAg
ICByZXQudGltZSA9IChpc19pZGxlX3ZjcHUoc25leHQtPnZjcHUpKSA/CisgICAgICAgICAgICAg
ICAgLTEgOiB0c2xpY2U7CiAgICAgcmV0LnRhc2sgPSBzbmV4dC0+dmNwdTsKIAogICAgIENTQ0hF
RF9WQ1BVX0NIRUNLKHJldC50YXNrKTsKZGlmZiAtcnVOIHhlbi5vcmkvY29tbW9uL3NjaGVkdWxl
LmMgeGVuL2NvbW1vbi9zY2hlZHVsZS5jCi0tLSB4ZW4ub3JpL2NvbW1vbi9zY2hlZHVsZS5jCTIw
MTEtMTEtMjggMDg6NTA6NTguMDAwMDAwMDAwIC0wNTAwCisrKyB4ZW4vY29tbW9uL3NjaGVkdWxl
LmMJMjAxMS0xMS0yOCAxMDoxMzowNi4wMDAwMDAwMDAgLTA1MDAKQEAgLTQ3LDYgKzQ3LDEwIEBA
CiBib29sX3Qgc2NoZWRfc210X3Bvd2VyX3NhdmluZ3MgPSAwOwogYm9vbGVhbl9wYXJhbSgic2No
ZWRfc210X3Bvd2VyX3NhdmluZ3MiLCBzY2hlZF9zbXRfcG93ZXJfc2F2aW5ncyk7CiAKKy8qIERl
ZmF1bHQgc2NoZWR1bGluZyByYXRlIGxpbWl0OiAxbXMgKi8KK2ludCBzY2hlZF9yYXRlbGltaXRf
dXMgPSAxMDAwOworaW50ZWdlcl9wYXJhbSgic2NoZWRfcmF0ZWxpbWl0X3VzIiwgc2NoZWRfcmF0
ZWxpbWl0X3VzKTsKKwogLyogVmFyaW91cyB0aW1lciBoYW5kbGVycy4gKi8KIHN0YXRpYyB2b2lk
IHNfdGltZXJfZm4odm9pZCAqdW51c2VkKTsKIHN0YXRpYyB2b2lkIHZjcHVfcGVyaW9kaWNfdGlt
ZXJfZm4odm9pZCAqZGF0YSk7CmRpZmYgLXJ1TiB4ZW4ub3JpL2luY2x1ZGUveGVuL3BlcmZjX2Rl
Zm4uaCB4ZW4vaW5jbHVkZS94ZW4vcGVyZmNfZGVmbi5oCi0tLSB4ZW4ub3JpL2luY2x1ZGUveGVu
L3BlcmZjX2RlZm4uaAkyMDExLTExLTI4IDA4OjUwOjU4LjAwMDAwMDAwMCAtMDUwMAorKysgeGVu
L2luY2x1ZGUveGVuL3BlcmZjX2RlZm4uaAkyMDExLTExLTI4IDAxOjE3OjMwLjAwMDAwMDAwMCAt
MDUwMApAQCAtMjAsNiArMjAsNyBAQAogUEVSRkNPVU5URVIoc2NoZWR1bGUsICAgICAgICAgICAg
ICAgImNzY2hlZDogc2NoZWR1bGUiKQogUEVSRkNPVU5URVIoYWNjdF9ydW4sICAgICAgICAgICAg
ICAgImNzY2hlZDogYWNjdF9ydW4iKQogUEVSRkNPVU5URVIoYWNjdF9ub193b3JrLCAgICAgICAg
ICAgImNzY2hlZDogYWNjdF9ub193b3JrIikKK1BFUkZDT1VOVEVSKGRlbGF5X21zLAkJICAgICJj
c2NoZWQ6IDFtcyBkZWxheSIpCiBQRVJGQ09VTlRFUihhY2N0X2JhbGFuY2UsICAgICAgICAgICAi
Y3NjaGVkOiBhY2N0X2JhbGFuY2UiKQogUEVSRkNPVU5URVIoYWNjdF9yZW9yZGVyLCAgICAgICAg
ICAgImNzY2hlZDogYWNjdF9yZW9yZGVyIikKIFBFUkZDT1VOVEVSKGFjY3RfbWluX2NyZWRpdCwg
ICAgICAgICJjc2NoZWQ6IGFjY3RfbWluX2NyZWRpdCIpCg==

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_
Content-Type: application/octet-stream; name="credit_3.patch"
Content-Description: credit_3.patch
Content-Disposition: attachment; filename="credit_3.patch"; size=3390;
	creation-date="Tue, 29 Nov 2011 01:15:20 GMT";
	modification-date="Mon, 28 Nov 2011 18:16:38 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtcnVOIHhlbi5vcmkvY29tbW9uL3NjaGVkX2NyZWRpdC5jIHhlbi5kdXAvY29tbW9uL3Nj
aGVkX2NyZWRpdC5jCi0tLSB4ZW4ub3JpL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwkyMDExLTExLTI4
IDA4OjUwOjU4LjAwMDAwMDAwMCAtMDUwMAorKysgeGVuLmR1cC9jb21tb24vc2NoZWRfY3JlZGl0
LmMJMjAxMS0xMS0yOCAxMTo0NTowNy4wMDAwMDAwMDAgLTA1MDAKQEAgLTExNSw2ICsxMTUsMTAg
QEAKIGJvb2xlYW5fcGFyYW0oInNjaGVkX2NyZWRpdF9kZWZhdWx0X3lpZWxkIiwgc2NoZWRfY3Jl
ZGl0X2RlZmF1bHRfeWllbGQpOwogCiAvKgorICogU2NoZWR1bGVyIGdlbmVyaWMgcGFyYW1ldGVy
cworICovCitleHRlcm4gaW50IHNjaGVkX3JhdGVsaW1pdF91czsKKy8qCiAgKiBQaHlzaWNhbCBD
UFUKICAqLwogc3RydWN0IGNzY2hlZF9wY3B1IHsKQEAgLTEyOTcsMTAgKzEzMDEsMTQgQEAKICAg
ICBzdHJ1Y3QgY3NjaGVkX3ByaXZhdGUgKnBydiA9IENTQ0hFRF9QUklWKG9wcyk7CiAgICAgc3Ry
dWN0IGNzY2hlZF92Y3B1ICpzbmV4dDsKICAgICBzdHJ1Y3QgdGFza19zbGljZSByZXQ7CisgICAg
c190aW1lX3QgcnVudGltZSwgdHNsaWNlOwogCiAgICAgQ1NDSEVEX1NUQVRfQ1JBTksoc2NoZWR1
bGUpOwogICAgIENTQ0hFRF9WQ1BVX0NIRUNLKGN1cnJlbnQpOwogCisgICAgcnVudGltZSA9IG5v
dyAtIGN1cnJlbnQtPnJ1bnN0YXRlLnN0YXRlX2VudHJ5X3RpbWU7CisgICAgaWYgKCBydW50aW1l
IDwgMCApIC8qIERvZXMgdGhpcyBldmVyIGhhcHBlbj8gKi8KKyAgICAgICAgcnVudGltZSA9IDA7
CiAgICAgaWYgKCAhaXNfaWRsZV92Y3B1KHNjdXJyLT52Y3B1KSApCiAgICAgewogICAgICAgICAv
KiBVcGRhdGUgY3JlZGl0cyBvZiBhIG5vbi1pZGxlIFZDUFUuICovCkBAIC0xMzIxLDcgKzEzMjks
MjggQEAKICAgICBlbHNlCiAgICAgICAgIEJVR19PTiggaXNfaWRsZV92Y3B1KGN1cnJlbnQpIHx8
IGxpc3RfZW1wdHkocnVucSkgKTsKIAotICAgIHNuZXh0ID0gX19ydW5xX2VsZW0ocnVucS0+bmV4
dCk7CisgICAgLyogSWYgd2UgaGF2ZSBzY2hlZHVsZSByYXRlIGxpbWl0aW5nIGVuYWJsZWQsIGNo
ZWNrIHRvIHNlZQorICAgICAqIGhvdyBsb25nIHdlJ3ZlIHJ1biBmb3IuICovCisgICAgaWYgKCBz
Y2hlZF9yYXRlbGltaXRfdXMKKyAgICAgICAgICYmIHZjcHVfcnVubmFibGUoY3VycmVudCkKKyAg
ICAgICAgICYmICFpc19pZGxlX3ZjcHUoY3VycmVudCkKKyAgICAgICAgICYmIHJ1bnRpbWUgPCBN
SUNST1NFQ1Moc2NoZWRfcmF0ZWxpbWl0X3VzKSApCisgICAgeworICAgICAgICBzbmV4dCA9IHNj
dXJyOworICAgICAgICBwZXJmY19pbmNyKGRlbGF5X21zKTsKKyAgICAgICAgLyogRklYTUU6IFVz
ZSBwcnYtPnRzbGljZV9tcyBpZiB3ZSdyZSBhbHNvIHRoZSBoZWFkIG9mIGh0ZSBxdWV1ZSAqLwor
ICAgICAgICAvL3RzbGljZSA9IE1JQ1JPU0VDUyhzY2hlZF9yYXRlbGltaXRfdXMpOworICAgICAg
ICB0c2xpY2UgPSBNSUxMSVNFQ1Moc2NoZWRfcmF0ZWxpbWl0X3VzKTsKKyAgICB9CisgICAgZWxz
ZQorICAgIHsKKyAgICAgICAgLyoKKyAgICAgICAgICogU2VsZWN0IG5leHQgcnVubmFibGUgbG9j
YWwgVkNQVSAoaWUgdG9wIG9mIGxvY2FsIHJ1bnEpCisgICAgICAgICAqLworICAgICAgICBzbmV4
dCA9IF9fcnVucV9lbGVtKHJ1bnEtPm5leHQpOworICAgICAgICB0c2xpY2UgPSBNSUxMSVNFQ1Mo
Q1NDSEVEX01TRUNTX1BFUl9UU0xJQ0UpOworICAgIH0KKwogICAgIHJldC5taWdyYXRlZCA9IDA7
CiAKICAgICAvKiBUYXNrbGV0IHdvcmsgKHdoaWNoIHJ1bnMgaW4gaWRsZSBWQ1BVIGNvbnRleHQp
IG92ZXJyaWRlcyBhbGwgZWxzZS4gKi8KQEAgLTEzNzAsOCArMTM5OSw4IEBACiAgICAgLyoKICAg
ICAgKiBSZXR1cm4gdGFzayB0byBydW4gbmV4dC4uLgogICAgICAqLwotICAgIHJldC50aW1lID0g
KGlzX2lkbGVfdmNwdShzbmV4dC0+dmNwdSkgPwotICAgICAgICAgICAgICAgIC0xIDogTUlMTElT
RUNTKENTQ0hFRF9NU0VDU19QRVJfVFNMSUNFKSk7CisgICAgcmV0LnRpbWUgPSAoaXNfaWRsZV92
Y3B1KHNuZXh0LT52Y3B1KSkgPworICAgICAgICAgICAgICAgIC0xIDogdHNsaWNlOwogICAgIHJl
dC50YXNrID0gc25leHQtPnZjcHU7CiAKICAgICBDU0NIRURfVkNQVV9DSEVDSyhyZXQudGFzayk7
CmRpZmYgLXJ1TiB4ZW4ub3JpL2NvbW1vbi9zY2hlZHVsZS5jIHhlbi5kdXAvY29tbW9uL3NjaGVk
dWxlLmMKLS0tIHhlbi5vcmkvY29tbW9uL3NjaGVkdWxlLmMJMjAxMS0xMS0yOCAwODo1MDo1OC4w
MDAwMDAwMDAgLTA1MDAKKysrIHhlbi5kdXAvY29tbW9uL3NjaGVkdWxlLmMJMjAxMS0xMS0yOCAx
MTo0NToyMy4wMDAwMDAwMDAgLTA1MDAKQEAgLTQ3LDYgKzQ3LDEwIEBACiBib29sX3Qgc2NoZWRf
c210X3Bvd2VyX3NhdmluZ3MgPSAwOwogYm9vbGVhbl9wYXJhbSgic2NoZWRfc210X3Bvd2VyX3Nh
dmluZ3MiLCBzY2hlZF9zbXRfcG93ZXJfc2F2aW5ncyk7CiAKKy8qIERlZmF1bHQgc2NoZWR1bGlu
ZyByYXRlIGxpbWl0OiAxbXMgKi8KK2ludCBzY2hlZF9yYXRlbGltaXRfdXMgPSAxMDAwOworaW50
ZWdlcl9wYXJhbSgic2NoZWRfcmF0ZWxpbWl0X3VzIiwgc2NoZWRfcmF0ZWxpbWl0X3VzKTsKKwog
LyogVmFyaW91cyB0aW1lciBoYW5kbGVycy4gKi8KIHN0YXRpYyB2b2lkIHNfdGltZXJfZm4odm9p
ZCAqdW51c2VkKTsKIHN0YXRpYyB2b2lkIHZjcHVfcGVyaW9kaWNfdGltZXJfZm4odm9pZCAqZGF0
YSk7CmRpZmYgLXJ1TiB4ZW4ub3JpL2luY2x1ZGUveGVuL3BlcmZjX2RlZm4uaCB4ZW4uZHVwL2lu
Y2x1ZGUveGVuL3BlcmZjX2RlZm4uaAotLS0geGVuLm9yaS9pbmNsdWRlL3hlbi9wZXJmY19kZWZu
LmgJMjAxMS0xMS0yOCAwODo1MDo1OC4wMDAwMDAwMDAgLTA1MDAKKysrIHhlbi5kdXAvaW5jbHVk
ZS94ZW4vcGVyZmNfZGVmbi5oCTIwMTEtMTEtMjggMDE6MTc6MzEuMDAwMDAwMDAwIC0wNTAwCkBA
IC0yMCw2ICsyMCw3IEBACiBQRVJGQ09VTlRFUihzY2hlZHVsZSwgICAgICAgICAgICAgICAiY3Nj
aGVkOiBzY2hlZHVsZSIpCiBQRVJGQ09VTlRFUihhY2N0X3J1biwgICAgICAgICAgICAgICAiY3Nj
aGVkOiBhY2N0X3J1biIpCiBQRVJGQ09VTlRFUihhY2N0X25vX3dvcmssICAgICAgICAgICAiY3Nj
aGVkOiBhY2N0X25vX3dvcmsiKQorUEVSRkNPVU5URVIoZGVsYXlfbXMsCQkgICAgImNzY2hlZDog
MW1zIGRlbGF5IikKIFBFUkZDT1VOVEVSKGFjY3RfYmFsYW5jZSwgICAgICAgICAgICJjc2NoZWQ6
IGFjY3RfYmFsYW5jZSIpCiBQRVJGQ09VTlRFUihhY2N0X3Jlb3JkZXIsICAgICAgICAgICAiY3Nj
aGVkOiBhY2N0X3Jlb3JkZXIiKQogUEVSRkNPVU5URVIoYWNjdF9taW5fY3JlZGl0LCAgICAgICAg
ImNzY2hlZDogYWNjdF9taW5fY3JlZGl0IikK

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--_004_C10D3FB0CD45994C8A51FEC1227CE22F37499C2733shsmsx502ccrc_--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:40:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5Bz-0007jH-C5; Mon, 28 Nov 2011 17:40:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV5Bx-0007j6-Ew
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:40:33 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322501996!6152250!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13532 invoked from network); 28 Nov 2011 17:39:57 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 17:39:57 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 280755415A; Mon, 28 Nov 2011 18:39:55 +0100 (CET)
Date: Mon, 28 Nov 2011 18:39:54 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111128173954.GA6828@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
	<1322497613.20646.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322497613.20646.19.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 04:26:53PM +0000, Ian Campbell wrote:
> I wonder if we could do something dumb like make /proc/xen/privcmd by a
> symlink to /dev/xen/privcmd instead of introducing this cross module
> dependency?

Sure. However this make a dependency from kernel to the userspace naming
policy. And the xenfs module still needs some sort of dependency on
privcmd, so it gets loaded.

> The main reason would be to avoid the select since selecting on user
> visible symbols is a recipe for confusion and is generally advised
> against.

Right. It is just the easiest solution.

> Perhaps the xen-privcmd.ko should simply call a newly introduced
> xenfs_register()? This would be a nop if CONFIG_XENFS=n and therefore
> the select would not be necessary. If COFIG_XENFS=[my] then modprobe
> will do the right thing.

This would be not backward compatible. And I'd like to avoid a
dependency from privcmd to xenfs.

Bastian

-- 
Not one hundred percent efficient, of course ... but nothing ever is.
		-- Kirk, "Metamorphosis", stardate 3219.8

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:40:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:40:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5Bz-0007jH-C5; Mon, 28 Nov 2011 17:40:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV5Bx-0007j6-Ew
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:40:33 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322501996!6152250!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13532 invoked from network); 28 Nov 2011 17:39:57 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 17:39:57 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 280755415A; Mon, 28 Nov 2011 18:39:55 +0100 (CET)
Date: Mon, 28 Nov 2011 18:39:54 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111128173954.GA6828@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
	<1322497613.20646.19.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322497613.20646.19.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 04:26:53PM +0000, Ian Campbell wrote:
> I wonder if we could do something dumb like make /proc/xen/privcmd by a
> symlink to /dev/xen/privcmd instead of introducing this cross module
> dependency?

Sure. However this make a dependency from kernel to the userspace naming
policy. And the xenfs module still needs some sort of dependency on
privcmd, so it gets loaded.

> The main reason would be to avoid the select since selecting on user
> visible symbols is a recipe for confusion and is generally advised
> against.

Right. It is just the easiest solution.

> Perhaps the xen-privcmd.ko should simply call a newly introduced
> xenfs_register()? This would be a nop if CONFIG_XENFS=n and therefore
> the select would not be necessary. If COFIG_XENFS=[my] then modprobe
> will do the right thing.

This would be not backward compatible. And I'd like to avoid a
dependency from privcmd to xenfs.

Bastian

-- 
Not one hundred percent efficient, of course ... but nothing ever is.
		-- Kirk, "Metamorphosis", stardate 3219.8

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:44:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5FM-0007tA-0q; Mon, 28 Nov 2011 17:44:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV5FK-0007so-CF
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:44:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322502172!54919271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21164 invoked from network); 28 Nov 2011 17:42:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 17:42:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9170296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 17:43:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 17:43:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV5Ej-0005MA-JM; Mon, 28 Nov 2011 17:43:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV5Ej-0001aL-IO;
	Mon, 28 Nov 2011 17:43:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.51261.558434.937765@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 17:43:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322493714.20646.5.camel@zakaz.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
	<1322487525.1005.293.camel@zakaz.uk.xensource.com>
	<1322493714.20646.5.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL"):
> On Mon, 2011-11-28 at 13:38 +0000, Ian Campbell wrote:
> >  I'm setting up a repro to see if I can figure out what is going
> > wrong.
> 
> I didn't get as far a reproing but I realised that the issue was that
> libaio was not installed on the target and so tapdisk was failing to run
> but error handling was broken so we didn't notice apart from some
> messages deep in the logs. The following fixes the error handling:

Thanks, applied.  (I have also fixed the tester.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:44:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:44:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5FM-0007tA-0q; Mon, 28 Nov 2011 17:44:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV5FK-0007so-CF
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:44:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322502172!54919271!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21164 invoked from network); 28 Nov 2011 17:42:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 17:42:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9170296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 17:43:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 17:43:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV5Ej-0005MA-JM; Mon, 28 Nov 2011 17:43:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV5Ej-0001aL-IO;
	Mon, 28 Nov 2011 17:43:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.51261.558434.937765@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 17:43:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322493714.20646.5.camel@zakaz.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
	<1322487525.1005.293.camel@zakaz.uk.xensource.com>
	<1322493714.20646.5.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL"):
> On Mon, 2011-11-28 at 13:38 +0000, Ian Campbell wrote:
> >  I'm setting up a repro to see if I can figure out what is going
> > wrong.
> 
> I didn't get as far a reproing but I realised that the issue was that
> libaio was not installed on the target and so tapdisk was failing to run
> but error handling was broken so we didn't notice apart from some
> messages deep in the logs. The following fixes the error handling:

Thanks, applied.  (I have also fixed the tester.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:51:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:51:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5Lu-00088L-18; Mon, 28 Nov 2011 17:50:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV5Ls-00088C-CI
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:50:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322502611!5324205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3023 invoked from network); 28 Nov 2011 17:50:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 17:50:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9170411"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 17:50:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 17:50:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV5LG-0005OX-SA; Mon, 28 Nov 2011 17:50:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV5LG-0001bJ-RB;
	Mon, 28 Nov 2011 17:50:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.51666.829995.721200@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 17:50:10 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322233395-29575-1-git-send-email-anthony.perard@citrix.com>
References: <1322233395-29575-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Apply CLOEXEC to the restore_fd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anthony PERARD writes ("[Xen-devel] [PATCH] xl: Apply CLOEXEC to the restore_fd."):
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 080aa2b..8bdfc32 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1382,6 +1382,7 @@ static int create_domain(struct domain_create *dom_info)
>  
>          restore_fd = migrate_fd >= 0 ? migrate_fd :
>              open(restore_file, O_RDONLY);
> +        libxl_fd_set_cloexec(restore_fd);

I don't think it's really sensible for this function to set cloexec on
a descriptor provided by its caller.  I'm afraid that although it
makes the code longer, I would prefer it if the cloexec was set at
each point when the fd is opened.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:51:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:51:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5Lu-00088L-18; Mon, 28 Nov 2011 17:50:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV5Ls-00088C-CI
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:50:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322502611!5324205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3023 invoked from network); 28 Nov 2011 17:50:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 17:50:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9170411"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 17:50:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 17:50:11 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RV5LG-0005OX-SA; Mon, 28 Nov 2011 17:50:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RV5LG-0001bJ-RB;
	Mon, 28 Nov 2011 17:50:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20179.51666.829995.721200@mariner.uk.xensource.com>
Date: Mon, 28 Nov 2011 17:50:10 +0000
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322233395-29575-1-git-send-email-anthony.perard@citrix.com>
References: <1322233395-29575-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Apply CLOEXEC to the restore_fd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Anthony PERARD writes ("[Xen-devel] [PATCH] xl: Apply CLOEXEC to the restore_fd."):
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 080aa2b..8bdfc32 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1382,6 +1382,7 @@ static int create_domain(struct domain_create *dom_info)
>  
>          restore_fd = migrate_fd >= 0 ? migrate_fd :
>              open(restore_file, O_RDONLY);
> +        libxl_fd_set_cloexec(restore_fd);

I don't think it's really sensible for this function to set cloexec on
a descriptor provided by its caller.  I'm afraid that although it
makes the code longer, I would prefer it if the cloexec was set at
each point when the fd is opened.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:58:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5T5-0008OW-V9; Mon, 28 Nov 2011 17:58:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV5T4-0008OR-H3
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:58:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322503057!3438726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1374 invoked from network); 28 Nov 2011 17:57:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 17:57:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9170582"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 17:57:37 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 17:57:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20179.32458.436431.927443@mariner.uk.xensource.com>
References: <20179.32337.102834.867932@mariner.uk.xensource.com>
	<20179.32458.436431.927443@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 17:57:36 +0000
Message-ID: <1322503056.11846.28.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/2] qemu-dm: open char devices "file:..."
 with O_APPEND
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 12:30 +0000, Ian Jackson wrote:
> The "file:..." character open method is used by serial and parallel
> ports, to divert the output to a file (and these devices never produce
> any input).  This is like a logfile, and so should be opened for
> append.
> 
> In qemu-xen-unstable, this is used only for the qemu stderr by libxl.

Do we need a similar patch for qemu upstream?

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff --git a/qemu-char.c b/qemu-char.c
> index 35e428d..324ed16 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -588,7 +588,7 @@ static CharDriverState *qemu_chr_open_file_out(const char *file_out)
>  {
>      int fd_out;
>  
> -    TFR(fd_out = open(file_out, O_WRONLY | O_TRUNC | O_CREAT | O_BINARY, 0666));
> +    TFR(fd_out = open(file_out, O_WRONLY | O_TRUNC | O_CREAT | O_BINARY | O_APPEND, 0666));
>      if (fd_out < 0)
>          return NULL;
>      return qemu_chr_open_fd(-1, fd_out);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 17:58:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 17:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5T5-0008OW-V9; Mon, 28 Nov 2011 17:58:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV5T4-0008OR-H3
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 17:58:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322503057!3438726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1374 invoked from network); 28 Nov 2011 17:57:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 17:57:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9170582"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 17:57:37 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 17:57:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20179.32458.436431.927443@mariner.uk.xensource.com>
References: <20179.32337.102834.867932@mariner.uk.xensource.com>
	<20179.32458.436431.927443@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 17:57:36 +0000
Message-ID: <1322503056.11846.28.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/2] qemu-dm: open char devices "file:..."
 with O_APPEND
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 12:30 +0000, Ian Jackson wrote:
> The "file:..." character open method is used by serial and parallel
> ports, to divert the output to a file (and these devices never produce
> any input).  This is like a logfile, and so should be opened for
> append.
> 
> In qemu-xen-unstable, this is used only for the qemu stderr by libxl.

Do we need a similar patch for qemu upstream?

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> diff --git a/qemu-char.c b/qemu-char.c
> index 35e428d..324ed16 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -588,7 +588,7 @@ static CharDriverState *qemu_chr_open_file_out(const char *file_out)
>  {
>      int fd_out;
>  
> -    TFR(fd_out = open(file_out, O_WRONLY | O_TRUNC | O_CREAT | O_BINARY, 0666));
> +    TFR(fd_out = open(file_out, O_WRONLY | O_TRUNC | O_CREAT | O_BINARY | O_APPEND, 0666));
>      if (fd_out < 0)
>          return NULL;
>      return qemu_chr_open_fd(-1, fd_out);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:01:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5Vk-00006p-Hs; Mon, 28 Nov 2011 18:01:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV5Vj-00006W-7H
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:00:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322503222!3240605!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25883 invoked from network); 28 Nov 2011 18:00:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 18:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9170616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 18:00:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 18:00:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <bastian@waldi.eu.org>
In-Reply-To: <20111128173954.GA6828@wavehammer.waldi.eu.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
	<1322497613.20646.19.camel@zakaz.uk.xensource.com>
	<20111128173954.GA6828@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 18:00:21 +0000
Message-ID: <1322503221.11846.29.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 17:39 +0000, Bastian Blank wrote:
> On Mon, Nov 28, 2011 at 04:26:53PM +0000, Ian Campbell wrote:
> > I wonder if we could do something dumb like make /proc/xen/privcmd by a
> > symlink to /dev/xen/privcmd instead of introducing this cross module
> > dependency?
> 
> Sure. However this make a dependency from kernel to the userspace naming
> policy. And the xenfs module still needs some sort of dependency on
> privcmd, so it gets loaded.
> 
> > The main reason would be to avoid the select since selecting on user
> > visible symbols is a recipe for confusion and is generally advised
> > against.
> 
> Right. It is just the easiest solution.

XENFS could depend on XEN_PRIVCMD and whatever else it needs?

> > Perhaps the xen-privcmd.ko should simply call a newly introduced
> > xenfs_register()? This would be a nop if CONFIG_XENFS=n and therefore
> > the select would not be necessary. If COFIG_XENFS=[my] then modprobe
> > will do the right thing.
> 
> This would be not backward compatible. And I'd like to avoid a
> dependency from privcmd to xenfs.

That's a reasonable goal.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:01:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5Vk-00006p-Hs; Mon, 28 Nov 2011 18:01:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV5Vj-00006W-7H
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:00:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322503222!3240605!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25883 invoked from network); 28 Nov 2011 18:00:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 18:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9170616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 18:00:22 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 18:00:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <bastian@waldi.eu.org>
In-Reply-To: <20111128173954.GA6828@wavehammer.waldi.eu.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
	<1322497613.20646.19.camel@zakaz.uk.xensource.com>
	<20111128173954.GA6828@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 18:00:21 +0000
Message-ID: <1322503221.11846.29.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 17:39 +0000, Bastian Blank wrote:
> On Mon, Nov 28, 2011 at 04:26:53PM +0000, Ian Campbell wrote:
> > I wonder if we could do something dumb like make /proc/xen/privcmd by a
> > symlink to /dev/xen/privcmd instead of introducing this cross module
> > dependency?
> 
> Sure. However this make a dependency from kernel to the userspace naming
> policy. And the xenfs module still needs some sort of dependency on
> privcmd, so it gets loaded.
> 
> > The main reason would be to avoid the select since selecting on user
> > visible symbols is a recipe for confusion and is generally advised
> > against.
> 
> Right. It is just the easiest solution.

XENFS could depend on XEN_PRIVCMD and whatever else it needs?

> > Perhaps the xen-privcmd.ko should simply call a newly introduced
> > xenfs_register()? This would be a nop if CONFIG_XENFS=n and therefore
> > the select would not be necessary. If COFIG_XENFS=[my] then modprobe
> > will do the right thing.
> 
> This would be not backward compatible. And I'd like to avoid a
> dependency from privcmd to xenfs.

That's a reasonable goal.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:11:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5fU-0000PT-QB; Mon, 28 Nov 2011 18:11:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV5fT-0000PO-L6
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:11:04 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322503821!5390594!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4135 invoked from network); 28 Nov 2011 18:10:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 18:10:23 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASIAIEq022860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 13:10:18 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASIAISf022857;
	Mon, 28 Nov 2011 13:10:18 -0500
Date: Mon, 28 Nov 2011 14:10:18 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Bastian Blank <waldi@debian.org>
Message-ID: <20111128181018.GA21369@andromeda.dapyr.net>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-5-git-send-email-waldi@debian.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322431628-21760-5-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Add xenbus device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 27, 2011 at 11:07:07PM +0100, Bastian Blank wrote:
> Access to xenbus is currently handled via xenfs. This adds a device
> driver for xenbus and makes xenfs use this code.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/xenbus/Makefile              |    1 +
>  drivers/xen/xenbus/xenbus_comms.h        |    4 +
>  drivers/xen/xenbus/xenbus_dev_frontend.c |  624 ++++++++++++++++++++++++++++++
>  drivers/xen/xenfs/Makefile               |    2 +-
>  drivers/xen/xenfs/super.c                |    3 +-
>  drivers/xen/xenfs/xenbus.c               |  593 ----------------------------
>  drivers/xen/xenfs/xenfs.h                |    1 -

Can you use 'git mv' please?

This looks  ike you are just moving the file around.

>  7 files changed, 632 insertions(+), 596 deletions(-)
>  create mode 100644 drivers/xen/xenbus/xenbus_dev_frontend.c
>  delete mode 100644 drivers/xen/xenfs/xenbus.c
> 
> diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
> index 8dca685..a2ea363 100644
> --- a/drivers/xen/xenbus/Makefile
> +++ b/drivers/xen/xenbus/Makefile
> @@ -1,4 +1,5 @@
>  obj-y	+= xenbus.o
> +obj-y	+= xenbus_dev_frontend.o
>  
>  xenbus-objs =
>  xenbus-objs += xenbus_client.o
> diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
> index c21db75..6e42800 100644
> --- a/drivers/xen/xenbus/xenbus_comms.h
> +++ b/drivers/xen/xenbus/xenbus_comms.h
> @@ -31,6 +31,8 @@
>  #ifndef _XENBUS_COMMS_H
>  #define _XENBUS_COMMS_H
>  
> +#include <linux/fs.h>
> +
>  int xs_init(void);
>  int xb_init_comms(void);
>  
> @@ -43,4 +45,6 @@ int xs_input_avail(void);
>  extern struct xenstore_domain_interface *xen_store_interface;
>  extern int xen_store_evtchn;
>  
> +extern const struct file_operations xen_xenbus_fops;
> +
>  #endif /* _XENBUS_COMMS_H */
> diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
> new file mode 100644
> index 0000000..fb30cff
> --- /dev/null
> +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
> @@ -0,0 +1,624 @@
> +/*
> + * Driver giving user-space access to the kernel's xenbus connection
> + * to xenstore.
> + *
> + * Copyright (c) 2005, Christian Limpach
> + * Copyright (c) 2005, Rusty Russell, IBM Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Changes:
> + * 2008-10-07  Alex Zeffertt    Replaced /proc/xen/xenbus with xenfs filesystem
> + *                              and /proc/xen compatibility mount point.
> + *                              Turned xenfs into a loadable module.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/uio.h>
> +#include <linux/notifier.h>
> +#include <linux/wait.h>
> +#include <linux/fs.h>
> +#include <linux/poll.h>
> +#include <linux/mutex.h>
> +#include <linux/sched.h>
> +#include <linux/spinlock.h>
> +#include <linux/mount.h>
> +#include <linux/pagemap.h>
> +#include <linux/uaccess.h>
> +#include <linux/init.h>
> +#include <linux/namei.h>
> +#include <linux/string.h>
> +#include <linux/slab.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +
> +#include "xenbus_comms.h"
> +
> +#include <xen/xenbus.h>
> +#include <asm/xen/hypervisor.h>
> +
> +MODULE_LICENSE("GPL");
> +
> +/*
> + * An element of a list of outstanding transactions, for which we're
> + * still waiting a reply.
> + */
> +struct xenbus_transaction_holder {
> +	struct list_head list;
> +	struct xenbus_transaction handle;
> +};
> +
> +/*
> + * A buffer of data on the queue.
> + */
> +struct read_buffer {
> +	struct list_head list;
> +	unsigned int cons;
> +	unsigned int len;
> +	char msg[];
> +};
> +
> +struct xenbus_file_priv {
> +	/*
> +	 * msgbuffer_mutex is held while partial requests are built up
> +	 * and complete requests are acted on.  It therefore protects
> +	 * the "transactions" and "watches" lists, and the partial
> +	 * request length and buffer.
> +	 *
> +	 * reply_mutex protects the reply being built up to return to
> +	 * usermode.  It nests inside msgbuffer_mutex but may be held
> +	 * alone during a watch callback.
> +	 */
> +	struct mutex msgbuffer_mutex;
> +
> +	/* In-progress transactions */
> +	struct list_head transactions;
> +
> +	/* Active watches. */
> +	struct list_head watches;
> +
> +	/* Partial request. */
> +	unsigned int len;
> +	union {
> +		struct xsd_sockmsg msg;
> +		char buffer[PAGE_SIZE];
> +	} u;
> +
> +	/* Response queue. */
> +	struct mutex reply_mutex;
> +	struct list_head read_buffers;
> +	wait_queue_head_t read_waitq;
> +
> +};
> +
> +/* Read out any raw xenbus messages queued up. */
> +static ssize_t xenbus_file_read(struct file *filp,
> +			       char __user *ubuf,
> +			       size_t len, loff_t *ppos)
> +{
> +	struct xenbus_file_priv *u = filp->private_data;
> +	struct read_buffer *rb;
> +	unsigned i;
> +	int ret;
> +
> +	mutex_lock(&u->reply_mutex);
> +again:
> +	while (list_empty(&u->read_buffers)) {
> +		mutex_unlock(&u->reply_mutex);
> +		if (filp->f_flags & O_NONBLOCK)
> +			return -EAGAIN;
> +
> +		ret = wait_event_interruptible(u->read_waitq,
> +					       !list_empty(&u->read_buffers));
> +		if (ret)
> +			return ret;
> +		mutex_lock(&u->reply_mutex);
> +	}
> +
> +	rb = list_entry(u->read_buffers.next, struct read_buffer, list);
> +	i = 0;
> +	while (i < len) {
> +		unsigned sz = min((unsigned)len - i, rb->len - rb->cons);
> +
> +		ret = copy_to_user(ubuf + i, &rb->msg[rb->cons], sz);
> +
> +		i += sz - ret;
> +		rb->cons += sz - ret;
> +
> +		if (ret != 0) {
> +			if (i == 0)
> +				i = -EFAULT;
> +			goto out;
> +		}
> +
> +		/* Clear out buffer if it has been consumed */
> +		if (rb->cons == rb->len) {
> +			list_del(&rb->list);
> +			kfree(rb);
> +			if (list_empty(&u->read_buffers))
> +				break;
> +			rb = list_entry(u->read_buffers.next,
> +					struct read_buffer, list);
> +		}
> +	}
> +	if (i == 0)
> +		goto again;
> +
> +out:
> +	mutex_unlock(&u->reply_mutex);
> +	return i;
> +}
> +
> +/*
> + * Add a buffer to the queue.  Caller must hold the appropriate lock
> + * if the queue is not local.  (Commonly the caller will build up
> + * multiple queued buffers on a temporary local list, and then add it
> + * to the appropriate list under lock once all the buffers have een
> + * successfully allocated.)
> + */
> +static int queue_reply(struct list_head *queue, const void *data, size_t len)
> +{
> +	struct read_buffer *rb;
> +
> +	if (len == 0)
> +		return 0;
> +
> +	rb = kmalloc(sizeof(*rb) + len, GFP_KERNEL);
> +	if (rb == NULL)
> +		return -ENOMEM;
> +
> +	rb->cons = 0;
> +	rb->len = len;
> +
> +	memcpy(rb->msg, data, len);
> +
> +	list_add_tail(&rb->list, queue);
> +	return 0;
> +}
> +
> +/*
> + * Free all the read_buffer s on a list.
> + * Caller must have sole reference to list.
> + */
> +static void queue_cleanup(struct list_head *list)
> +{
> +	struct read_buffer *rb;
> +
> +	while (!list_empty(list)) {
> +		rb = list_entry(list->next, struct read_buffer, list);
> +		list_del(list->next);
> +		kfree(rb);
> +	}
> +}
> +
> +struct watch_adapter {
> +	struct list_head list;
> +	struct xenbus_watch watch;
> +	struct xenbus_file_priv *dev_data;
> +	char *token;
> +};
> +
> +static void free_watch_adapter(struct watch_adapter *watch)
> +{
> +	kfree(watch->watch.node);
> +	kfree(watch->token);
> +	kfree(watch);
> +}
> +
> +static struct watch_adapter *alloc_watch_adapter(const char *path,
> +						 const char *token)
> +{
> +	struct watch_adapter *watch;
> +
> +	watch = kzalloc(sizeof(*watch), GFP_KERNEL);
> +	if (watch == NULL)
> +		goto out_fail;
> +
> +	watch->watch.node = kstrdup(path, GFP_KERNEL);
> +	if (watch->watch.node == NULL)
> +		goto out_free;
> +
> +	watch->token = kstrdup(token, GFP_KERNEL);
> +	if (watch->token == NULL)
> +		goto out_free;
> +
> +	return watch;
> +
> +out_free:
> +	free_watch_adapter(watch);
> +
> +out_fail:
> +	return NULL;
> +}
> +
> +static void watch_fired(struct xenbus_watch *watch,
> +			const char **vec,
> +			unsigned int len)
> +{
> +	struct watch_adapter *adap;
> +	struct xsd_sockmsg hdr;
> +	const char *path, *token;
> +	int path_len, tok_len, body_len, data_len = 0;
> +	int ret;
> +	LIST_HEAD(staging_q);
> +
> +	adap = container_of(watch, struct watch_adapter, watch);
> +
> +	path = vec[XS_WATCH_PATH];
> +	token = adap->token;
> +
> +	path_len = strlen(path) + 1;
> +	tok_len = strlen(token) + 1;
> +	if (len > 2)
> +		data_len = vec[len] - vec[2] + 1;
> +	body_len = path_len + tok_len + data_len;
> +
> +	hdr.type = XS_WATCH_EVENT;
> +	hdr.len = body_len;
> +
> +	mutex_lock(&adap->dev_data->reply_mutex);
> +
> +	ret = queue_reply(&staging_q, &hdr, sizeof(hdr));
> +	if (!ret)
> +		ret = queue_reply(&staging_q, path, path_len);
> +	if (!ret)
> +		ret = queue_reply(&staging_q, token, tok_len);
> +	if (!ret && len > 2)
> +		ret = queue_reply(&staging_q, vec[2], data_len);
> +
> +	if (!ret) {
> +		/* success: pass reply list onto watcher */
> +		list_splice_tail(&staging_q, &adap->dev_data->read_buffers);
> +		wake_up(&adap->dev_data->read_waitq);
> +	} else
> +		queue_cleanup(&staging_q);
> +
> +	mutex_unlock(&adap->dev_data->reply_mutex);
> +}
> +
> +static int xenbus_write_transaction(unsigned msg_type,
> +				    struct xenbus_file_priv *u)
> +{
> +	int rc;
> +	void *reply;
> +	struct xenbus_transaction_holder *trans = NULL;
> +	LIST_HEAD(staging_q);
> +
> +	if (msg_type == XS_TRANSACTION_START) {
> +		trans = kmalloc(sizeof(*trans), GFP_KERNEL);
> +		if (!trans) {
> +			rc = -ENOMEM;
> +			goto out;
> +		}
> +	}
> +
> +	reply = xenbus_dev_request_and_reply(&u->u.msg);
> +	if (IS_ERR(reply)) {
> +		kfree(trans);
> +		rc = PTR_ERR(reply);
> +		goto out;
> +	}
> +
> +	if (msg_type == XS_TRANSACTION_START) {
> +		trans->handle.id = simple_strtoul(reply, NULL, 0);
> +
> +		list_add(&trans->list, &u->transactions);
> +	} else if (msg_type == XS_TRANSACTION_END) {
> +		list_for_each_entry(trans, &u->transactions, list)
> +			if (trans->handle.id == u->u.msg.tx_id)
> +				break;
> +		BUG_ON(&trans->list == &u->transactions);
> +		list_del(&trans->list);
> +
> +		kfree(trans);
> +	}
> +
> +	mutex_lock(&u->reply_mutex);
> +	rc = queue_reply(&staging_q, &u->u.msg, sizeof(u->u.msg));
> +	if (!rc)
> +		rc = queue_reply(&staging_q, reply, u->u.msg.len);
> +	if (!rc) {
> +		list_splice_tail(&staging_q, &u->read_buffers);
> +		wake_up(&u->read_waitq);
> +	} else {
> +		queue_cleanup(&staging_q);
> +	}
> +	mutex_unlock(&u->reply_mutex);
> +
> +	kfree(reply);
> +
> +out:
> +	return rc;
> +}
> +
> +static int xenbus_write_watch(unsigned msg_type, struct xenbus_file_priv *u)
> +{
> +	struct watch_adapter *watch, *tmp_watch;
> +	char *path, *token;
> +	int err, rc;
> +	LIST_HEAD(staging_q);
> +
> +	path = u->u.buffer + sizeof(u->u.msg);
> +	token = memchr(path, 0, u->u.msg.len);
> +	if (token == NULL) {
> +		rc = -EILSEQ;
> +		goto out;
> +	}
> +	token++;
> +
> +	if (msg_type == XS_WATCH) {
> +		watch = alloc_watch_adapter(path, token);
> +		if (watch == NULL) {
> +			rc = -ENOMEM;
> +			goto out;
> +		}
> +
> +		watch->watch.callback = watch_fired;
> +		watch->dev_data = u;
> +
> +		err = register_xenbus_watch(&watch->watch);
> +		if (err) {
> +			free_watch_adapter(watch);
> +			rc = err;
> +			goto out;
> +		}
> +		list_add(&watch->list, &u->watches);
> +	} else {
> +		list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
> +			if (!strcmp(watch->token, token) &&
> +			    !strcmp(watch->watch.node, path)) {
> +				unregister_xenbus_watch(&watch->watch);
> +				list_del(&watch->list);
> +				free_watch_adapter(watch);
> +				break;
> +			}
> +		}
> +	}
> +
> +	/* Success.  Synthesize a reply to say all is OK. */
> +	{
> +		struct {
> +			struct xsd_sockmsg hdr;
> +			char body[3];
> +		} __packed reply = {
> +			{
> +				.type = msg_type,
> +				.len = sizeof(reply.body)
> +			},
> +			"OK"
> +		};
> +
> +		mutex_lock(&u->reply_mutex);
> +		rc = queue_reply(&u->read_buffers, &reply, sizeof(reply));
> +		wake_up(&u->read_waitq);
> +		mutex_unlock(&u->reply_mutex);
> +	}
> +
> +out:
> +	return rc;
> +}
> +
> +static ssize_t xenbus_file_write(struct file *filp,
> +				const char __user *ubuf,
> +				size_t len, loff_t *ppos)
> +{
> +	struct xenbus_file_priv *u = filp->private_data;
> +	uint32_t msg_type;
> +	int rc = len;
> +	int ret;
> +	LIST_HEAD(staging_q);
> +
> +	/*
> +	 * We're expecting usermode to be writing properly formed
> +	 * xenbus messages.  If they write an incomplete message we
> +	 * buffer it up.  Once it is complete, we act on it.
> +	 */
> +
> +	/*
> +	 * Make sure concurrent writers can't stomp all over each
> +	 * other's messages and make a mess of our partial message
> +	 * buffer.  We don't make any attemppt to stop multiple
> +	 * writers from making a mess of each other's incomplete
> +	 * messages; we're just trying to guarantee our own internal
> +	 * consistency and make sure that single writes are handled
> +	 * atomically.
> +	 */
> +	mutex_lock(&u->msgbuffer_mutex);
> +
> +	/* Get this out of the way early to avoid confusion */
> +	if (len == 0)
> +		goto out;
> +
> +	/* Can't write a xenbus message larger we can buffer */
> +	if ((len + u->len) > sizeof(u->u.buffer)) {
> +		/* On error, dump existing buffer */
> +		u->len = 0;
> +		rc = -EINVAL;
> +		goto out;
> +	}
> +
> +	ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
> +
> +	if (ret != 0) {
> +		rc = -EFAULT;
> +		goto out;
> +	}
> +
> +	/* Deal with a partial copy. */
> +	len -= ret;
> +	rc = len;
> +
> +	u->len += len;
> +
> +	/* Return if we haven't got a full message yet */
> +	if (u->len < sizeof(u->u.msg))
> +		goto out;	/* not even the header yet */
> +
> +	/* If we're expecting a message that's larger than we can
> +	   possibly send, dump what we have and return an error. */
> +	if ((sizeof(u->u.msg) + u->u.msg.len) > sizeof(u->u.buffer)) {
> +		rc = -E2BIG;
> +		u->len = 0;
> +		goto out;
> +	}
> +
> +	if (u->len < (sizeof(u->u.msg) + u->u.msg.len))
> +		goto out;	/* incomplete data portion */
> +
> +	/*
> +	 * OK, now we have a complete message.  Do something with it.
> +	 */
> +
> +	msg_type = u->u.msg.type;
> +
> +	switch (msg_type) {
> +	case XS_WATCH:
> +	case XS_UNWATCH:
> +		/* (Un)Ask for some path to be watched for changes */
> +		ret = xenbus_write_watch(msg_type, u);
> +		break;
> +
> +	default:
> +		/* Send out a transaction */
> +		ret = xenbus_write_transaction(msg_type, u);
> +		break;
> +	}
> +	if (ret != 0)
> +		rc = ret;
> +
> +	/* Buffered message consumed */
> +	u->len = 0;
> +
> + out:
> +	mutex_unlock(&u->msgbuffer_mutex);
> +	return rc;
> +}
> +
> +static int xenbus_file_open(struct inode *inode, struct file *filp)
> +{
> +	struct xenbus_file_priv *u;
> +
> +	if (xen_store_evtchn == 0)
> +		return -ENOENT;
> +
> +	nonseekable_open(inode, filp);
> +
> +	u = kzalloc(sizeof(*u), GFP_KERNEL);
> +	if (u == NULL)
> +		return -ENOMEM;
> +
> +	INIT_LIST_HEAD(&u->transactions);
> +	INIT_LIST_HEAD(&u->watches);
> +	INIT_LIST_HEAD(&u->read_buffers);
> +	init_waitqueue_head(&u->read_waitq);
> +
> +	mutex_init(&u->reply_mutex);
> +	mutex_init(&u->msgbuffer_mutex);
> +
> +	filp->private_data = u;
> +
> +	return 0;
> +}
> +
> +static int xenbus_file_release(struct inode *inode, struct file *filp)
> +{
> +	struct xenbus_file_priv *u = filp->private_data;
> +	struct xenbus_transaction_holder *trans, *tmp;
> +	struct watch_adapter *watch, *tmp_watch;
> +	struct read_buffer *rb, *tmp_rb;
> +
> +	/*
> +	 * No need for locking here because there are no other users,
> +	 * by definition.
> +	 */
> +
> +	list_for_each_entry_safe(trans, tmp, &u->transactions, list) {
> +		xenbus_transaction_end(trans->handle, 1);
> +		list_del(&trans->list);
> +		kfree(trans);
> +	}
> +
> +	list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
> +		unregister_xenbus_watch(&watch->watch);
> +		list_del(&watch->list);
> +		free_watch_adapter(watch);
> +	}
> +
> +	list_for_each_entry_safe(rb, tmp_rb, &u->read_buffers, list) {
> +		list_del(&rb->list);
> +		kfree(rb);
> +	}
> +	kfree(u);
> +
> +	return 0;
> +}
> +
> +static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
> +{
> +	struct xenbus_file_priv *u = file->private_data;
> +
> +	poll_wait(file, &u->read_waitq, wait);
> +	if (!list_empty(&u->read_buffers))
> +		return POLLIN | POLLRDNORM;
> +	return 0;
> +}
> +
> +const struct file_operations xen_xenbus_fops = {
> +	.read = xenbus_file_read,
> +	.write = xenbus_file_write,
> +	.open = xenbus_file_open,
> +	.release = xenbus_file_release,
> +	.poll = xenbus_file_poll,
> +	.llseek = no_llseek,
> +};
> +EXPORT_SYMBOL_GPL(xen_xenbus_fops);
> +
> +static struct miscdevice xenbus_dev = {
> +	.minor = MISC_DYNAMIC_MINOR,
> +	.name = "xen/xenbus",
> +	.fops = &xen_xenbus_fops,
> +};
> +
> +static int __init xenbus_init(void)
> +{
> +	int err;
> +
> +	if (!xen_domain())
> +		return -ENODEV;
> +
> +	err = misc_register(&xenbus_dev);
> +	if (err)
> +		printk(KERN_ERR "Could not register xenbus device\n");
> +	return err;
> +}
> +
> +static void __exit xenbus_exit(void)
> +{
> +	misc_deregister(&xenbus_dev);
> +}
> +
> +module_init(xenbus_init);
> +module_exit(xenbus_exit);
> diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
> index 5d45ff1..b019865 100644
> --- a/drivers/xen/xenfs/Makefile
> +++ b/drivers/xen/xenfs/Makefile
> @@ -1,4 +1,4 @@
>  obj-$(CONFIG_XENFS) += xenfs.o
>  
> -xenfs-y			  = super.o xenbus.o
> +xenfs-y			  = super.o
>  xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
> diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
> index a55fbf9..a84b53c 100644
> --- a/drivers/xen/xenfs/super.c
> +++ b/drivers/xen/xenfs/super.c
> @@ -17,6 +17,7 @@
>  
>  #include "xenfs.h"
>  #include "../privcmd.h"
> +#include "../xenbus/xenbus_comms.h"
>  
>  #include <asm/xen/hypervisor.h>
>  
> @@ -83,7 +84,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
>  {
>  	static struct tree_descr xenfs_files[] = {
>  		[1] = {},
> -		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
> +		{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
>  		{ "capabilities", &capabilities_file_ops, S_IRUGO },
>  		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
>  		{""},
> diff --git a/drivers/xen/xenfs/xenbus.c b/drivers/xen/xenfs/xenbus.c
> deleted file mode 100644
> index bbd000f..0000000
> --- a/drivers/xen/xenfs/xenbus.c
> +++ /dev/null
> @@ -1,593 +0,0 @@
> -/*
> - * Driver giving user-space access to the kernel's xenbus connection
> - * to xenstore.
> - *
> - * Copyright (c) 2005, Christian Limpach
> - * Copyright (c) 2005, Rusty Russell, IBM Corporation
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License version 2
> - * as published by the Free Software Foundation; or, when distributed
> - * separately from the Linux kernel or incorporated into other
> - * software packages, subject to the following license:
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a copy
> - * of this source file (the "Software"), to deal in the Software without
> - * restriction, including without limitation the rights to use, copy, modify,
> - * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> - * and to permit persons to whom the Software is furnished to do so, subject to
> - * the following conditions:
> - *
> - * The above copyright notice and this permission notice shall be included in
> - * all copies or substantial portions of the Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> - * IN THE SOFTWARE.
> - *
> - * Changes:
> - * 2008-10-07  Alex Zeffertt    Replaced /proc/xen/xenbus with xenfs filesystem
> - *                              and /proc/xen compatibility mount point.
> - *                              Turned xenfs into a loadable module.
> - */
> -
> -#include <linux/kernel.h>
> -#include <linux/errno.h>
> -#include <linux/uio.h>
> -#include <linux/notifier.h>
> -#include <linux/wait.h>
> -#include <linux/fs.h>
> -#include <linux/poll.h>
> -#include <linux/mutex.h>
> -#include <linux/sched.h>
> -#include <linux/spinlock.h>
> -#include <linux/mount.h>
> -#include <linux/pagemap.h>
> -#include <linux/uaccess.h>
> -#include <linux/init.h>
> -#include <linux/namei.h>
> -#include <linux/string.h>
> -#include <linux/slab.h>
> -
> -#include "xenfs.h"
> -#include "../xenbus/xenbus_comms.h"
> -
> -#include <xen/xenbus.h>
> -#include <asm/xen/hypervisor.h>
> -
> -/*
> - * An element of a list of outstanding transactions, for which we're
> - * still waiting a reply.
> - */
> -struct xenbus_transaction_holder {
> -	struct list_head list;
> -	struct xenbus_transaction handle;
> -};
> -
> -/*
> - * A buffer of data on the queue.
> - */
> -struct read_buffer {
> -	struct list_head list;
> -	unsigned int cons;
> -	unsigned int len;
> -	char msg[];
> -};
> -
> -struct xenbus_file_priv {
> -	/*
> -	 * msgbuffer_mutex is held while partial requests are built up
> -	 * and complete requests are acted on.  It therefore protects
> -	 * the "transactions" and "watches" lists, and the partial
> -	 * request length and buffer.
> -	 *
> -	 * reply_mutex protects the reply being built up to return to
> -	 * usermode.  It nests inside msgbuffer_mutex but may be held
> -	 * alone during a watch callback.
> -	 */
> -	struct mutex msgbuffer_mutex;
> -
> -	/* In-progress transactions */
> -	struct list_head transactions;
> -
> -	/* Active watches. */
> -	struct list_head watches;
> -
> -	/* Partial request. */
> -	unsigned int len;
> -	union {
> -		struct xsd_sockmsg msg;
> -		char buffer[PAGE_SIZE];
> -	} u;
> -
> -	/* Response queue. */
> -	struct mutex reply_mutex;
> -	struct list_head read_buffers;
> -	wait_queue_head_t read_waitq;
> -
> -};
> -
> -/* Read out any raw xenbus messages queued up. */
> -static ssize_t xenbus_file_read(struct file *filp,
> -			       char __user *ubuf,
> -			       size_t len, loff_t *ppos)
> -{
> -	struct xenbus_file_priv *u = filp->private_data;
> -	struct read_buffer *rb;
> -	unsigned i;
> -	int ret;
> -
> -	mutex_lock(&u->reply_mutex);
> -again:
> -	while (list_empty(&u->read_buffers)) {
> -		mutex_unlock(&u->reply_mutex);
> -		if (filp->f_flags & O_NONBLOCK)
> -			return -EAGAIN;
> -
> -		ret = wait_event_interruptible(u->read_waitq,
> -					       !list_empty(&u->read_buffers));
> -		if (ret)
> -			return ret;
> -		mutex_lock(&u->reply_mutex);
> -	}
> -
> -	rb = list_entry(u->read_buffers.next, struct read_buffer, list);
> -	i = 0;
> -	while (i < len) {
> -		unsigned sz = min((unsigned)len - i, rb->len - rb->cons);
> -
> -		ret = copy_to_user(ubuf + i, &rb->msg[rb->cons], sz);
> -
> -		i += sz - ret;
> -		rb->cons += sz - ret;
> -
> -		if (ret != 0) {
> -			if (i == 0)
> -				i = -EFAULT;
> -			goto out;
> -		}
> -
> -		/* Clear out buffer if it has been consumed */
> -		if (rb->cons == rb->len) {
> -			list_del(&rb->list);
> -			kfree(rb);
> -			if (list_empty(&u->read_buffers))
> -				break;
> -			rb = list_entry(u->read_buffers.next,
> -					struct read_buffer, list);
> -		}
> -	}
> -	if (i == 0)
> -		goto again;
> -
> -out:
> -	mutex_unlock(&u->reply_mutex);
> -	return i;
> -}
> -
> -/*
> - * Add a buffer to the queue.  Caller must hold the appropriate lock
> - * if the queue is not local.  (Commonly the caller will build up
> - * multiple queued buffers on a temporary local list, and then add it
> - * to the appropriate list under lock once all the buffers have een
> - * successfully allocated.)
> - */
> -static int queue_reply(struct list_head *queue, const void *data, size_t len)
> -{
> -	struct read_buffer *rb;
> -
> -	if (len == 0)
> -		return 0;
> -
> -	rb = kmalloc(sizeof(*rb) + len, GFP_KERNEL);
> -	if (rb == NULL)
> -		return -ENOMEM;
> -
> -	rb->cons = 0;
> -	rb->len = len;
> -
> -	memcpy(rb->msg, data, len);
> -
> -	list_add_tail(&rb->list, queue);
> -	return 0;
> -}
> -
> -/*
> - * Free all the read_buffer s on a list.
> - * Caller must have sole reference to list.
> - */
> -static void queue_cleanup(struct list_head *list)
> -{
> -	struct read_buffer *rb;
> -
> -	while (!list_empty(list)) {
> -		rb = list_entry(list->next, struct read_buffer, list);
> -		list_del(list->next);
> -		kfree(rb);
> -	}
> -}
> -
> -struct watch_adapter {
> -	struct list_head list;
> -	struct xenbus_watch watch;
> -	struct xenbus_file_priv *dev_data;
> -	char *token;
> -};
> -
> -static void free_watch_adapter(struct watch_adapter *watch)
> -{
> -	kfree(watch->watch.node);
> -	kfree(watch->token);
> -	kfree(watch);
> -}
> -
> -static struct watch_adapter *alloc_watch_adapter(const char *path,
> -						 const char *token)
> -{
> -	struct watch_adapter *watch;
> -
> -	watch = kzalloc(sizeof(*watch), GFP_KERNEL);
> -	if (watch == NULL)
> -		goto out_fail;
> -
> -	watch->watch.node = kstrdup(path, GFP_KERNEL);
> -	if (watch->watch.node == NULL)
> -		goto out_free;
> -
> -	watch->token = kstrdup(token, GFP_KERNEL);
> -	if (watch->token == NULL)
> -		goto out_free;
> -
> -	return watch;
> -
> -out_free:
> -	free_watch_adapter(watch);
> -
> -out_fail:
> -	return NULL;
> -}
> -
> -static void watch_fired(struct xenbus_watch *watch,
> -			const char **vec,
> -			unsigned int len)
> -{
> -	struct watch_adapter *adap;
> -	struct xsd_sockmsg hdr;
> -	const char *path, *token;
> -	int path_len, tok_len, body_len, data_len = 0;
> -	int ret;
> -	LIST_HEAD(staging_q);
> -
> -	adap = container_of(watch, struct watch_adapter, watch);
> -
> -	path = vec[XS_WATCH_PATH];
> -	token = adap->token;
> -
> -	path_len = strlen(path) + 1;
> -	tok_len = strlen(token) + 1;
> -	if (len > 2)
> -		data_len = vec[len] - vec[2] + 1;
> -	body_len = path_len + tok_len + data_len;
> -
> -	hdr.type = XS_WATCH_EVENT;
> -	hdr.len = body_len;
> -
> -	mutex_lock(&adap->dev_data->reply_mutex);
> -
> -	ret = queue_reply(&staging_q, &hdr, sizeof(hdr));
> -	if (!ret)
> -		ret = queue_reply(&staging_q, path, path_len);
> -	if (!ret)
> -		ret = queue_reply(&staging_q, token, tok_len);
> -	if (!ret && len > 2)
> -		ret = queue_reply(&staging_q, vec[2], data_len);
> -
> -	if (!ret) {
> -		/* success: pass reply list onto watcher */
> -		list_splice_tail(&staging_q, &adap->dev_data->read_buffers);
> -		wake_up(&adap->dev_data->read_waitq);
> -	} else
> -		queue_cleanup(&staging_q);
> -
> -	mutex_unlock(&adap->dev_data->reply_mutex);
> -}
> -
> -static int xenbus_write_transaction(unsigned msg_type,
> -				    struct xenbus_file_priv *u)
> -{
> -	int rc;
> -	void *reply;
> -	struct xenbus_transaction_holder *trans = NULL;
> -	LIST_HEAD(staging_q);
> -
> -	if (msg_type == XS_TRANSACTION_START) {
> -		trans = kmalloc(sizeof(*trans), GFP_KERNEL);
> -		if (!trans) {
> -			rc = -ENOMEM;
> -			goto out;
> -		}
> -	}
> -
> -	reply = xenbus_dev_request_and_reply(&u->u.msg);
> -	if (IS_ERR(reply)) {
> -		kfree(trans);
> -		rc = PTR_ERR(reply);
> -		goto out;
> -	}
> -
> -	if (msg_type == XS_TRANSACTION_START) {
> -		trans->handle.id = simple_strtoul(reply, NULL, 0);
> -
> -		list_add(&trans->list, &u->transactions);
> -	} else if (msg_type == XS_TRANSACTION_END) {
> -		list_for_each_entry(trans, &u->transactions, list)
> -			if (trans->handle.id == u->u.msg.tx_id)
> -				break;
> -		BUG_ON(&trans->list == &u->transactions);
> -		list_del(&trans->list);
> -
> -		kfree(trans);
> -	}
> -
> -	mutex_lock(&u->reply_mutex);
> -	rc = queue_reply(&staging_q, &u->u.msg, sizeof(u->u.msg));
> -	if (!rc)
> -		rc = queue_reply(&staging_q, reply, u->u.msg.len);
> -	if (!rc) {
> -		list_splice_tail(&staging_q, &u->read_buffers);
> -		wake_up(&u->read_waitq);
> -	} else {
> -		queue_cleanup(&staging_q);
> -	}
> -	mutex_unlock(&u->reply_mutex);
> -
> -	kfree(reply);
> -
> -out:
> -	return rc;
> -}
> -
> -static int xenbus_write_watch(unsigned msg_type, struct xenbus_file_priv *u)
> -{
> -	struct watch_adapter *watch, *tmp_watch;
> -	char *path, *token;
> -	int err, rc;
> -	LIST_HEAD(staging_q);
> -
> -	path = u->u.buffer + sizeof(u->u.msg);
> -	token = memchr(path, 0, u->u.msg.len);
> -	if (token == NULL) {
> -		rc = -EILSEQ;
> -		goto out;
> -	}
> -	token++;
> -
> -	if (msg_type == XS_WATCH) {
> -		watch = alloc_watch_adapter(path, token);
> -		if (watch == NULL) {
> -			rc = -ENOMEM;
> -			goto out;
> -		}
> -
> -		watch->watch.callback = watch_fired;
> -		watch->dev_data = u;
> -
> -		err = register_xenbus_watch(&watch->watch);
> -		if (err) {
> -			free_watch_adapter(watch);
> -			rc = err;
> -			goto out;
> -		}
> -		list_add(&watch->list, &u->watches);
> -	} else {
> -		list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
> -			if (!strcmp(watch->token, token) &&
> -			    !strcmp(watch->watch.node, path)) {
> -				unregister_xenbus_watch(&watch->watch);
> -				list_del(&watch->list);
> -				free_watch_adapter(watch);
> -				break;
> -			}
> -		}
> -	}
> -
> -	/* Success.  Synthesize a reply to say all is OK. */
> -	{
> -		struct {
> -			struct xsd_sockmsg hdr;
> -			char body[3];
> -		} __packed reply = {
> -			{
> -				.type = msg_type,
> -				.len = sizeof(reply.body)
> -			},
> -			"OK"
> -		};
> -
> -		mutex_lock(&u->reply_mutex);
> -		rc = queue_reply(&u->read_buffers, &reply, sizeof(reply));
> -		wake_up(&u->read_waitq);
> -		mutex_unlock(&u->reply_mutex);
> -	}
> -
> -out:
> -	return rc;
> -}
> -
> -static ssize_t xenbus_file_write(struct file *filp,
> -				const char __user *ubuf,
> -				size_t len, loff_t *ppos)
> -{
> -	struct xenbus_file_priv *u = filp->private_data;
> -	uint32_t msg_type;
> -	int rc = len;
> -	int ret;
> -	LIST_HEAD(staging_q);
> -
> -	/*
> -	 * We're expecting usermode to be writing properly formed
> -	 * xenbus messages.  If they write an incomplete message we
> -	 * buffer it up.  Once it is complete, we act on it.
> -	 */
> -
> -	/*
> -	 * Make sure concurrent writers can't stomp all over each
> -	 * other's messages and make a mess of our partial message
> -	 * buffer.  We don't make any attemppt to stop multiple
> -	 * writers from making a mess of each other's incomplete
> -	 * messages; we're just trying to guarantee our own internal
> -	 * consistency and make sure that single writes are handled
> -	 * atomically.
> -	 */
> -	mutex_lock(&u->msgbuffer_mutex);
> -
> -	/* Get this out of the way early to avoid confusion */
> -	if (len == 0)
> -		goto out;
> -
> -	/* Can't write a xenbus message larger we can buffer */
> -	if ((len + u->len) > sizeof(u->u.buffer)) {
> -		/* On error, dump existing buffer */
> -		u->len = 0;
> -		rc = -EINVAL;
> -		goto out;
> -	}
> -
> -	ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
> -
> -	if (ret != 0) {
> -		rc = -EFAULT;
> -		goto out;
> -	}
> -
> -	/* Deal with a partial copy. */
> -	len -= ret;
> -	rc = len;
> -
> -	u->len += len;
> -
> -	/* Return if we haven't got a full message yet */
> -	if (u->len < sizeof(u->u.msg))
> -		goto out;	/* not even the header yet */
> -
> -	/* If we're expecting a message that's larger than we can
> -	   possibly send, dump what we have and return an error. */
> -	if ((sizeof(u->u.msg) + u->u.msg.len) > sizeof(u->u.buffer)) {
> -		rc = -E2BIG;
> -		u->len = 0;
> -		goto out;
> -	}
> -
> -	if (u->len < (sizeof(u->u.msg) + u->u.msg.len))
> -		goto out;	/* incomplete data portion */
> -
> -	/*
> -	 * OK, now we have a complete message.  Do something with it.
> -	 */
> -
> -	msg_type = u->u.msg.type;
> -
> -	switch (msg_type) {
> -	case XS_WATCH:
> -	case XS_UNWATCH:
> -		/* (Un)Ask for some path to be watched for changes */
> -		ret = xenbus_write_watch(msg_type, u);
> -		break;
> -
> -	default:
> -		/* Send out a transaction */
> -		ret = xenbus_write_transaction(msg_type, u);
> -		break;
> -	}
> -	if (ret != 0)
> -		rc = ret;
> -
> -	/* Buffered message consumed */
> -	u->len = 0;
> -
> - out:
> -	mutex_unlock(&u->msgbuffer_mutex);
> -	return rc;
> -}
> -
> -static int xenbus_file_open(struct inode *inode, struct file *filp)
> -{
> -	struct xenbus_file_priv *u;
> -
> -	if (xen_store_evtchn == 0)
> -		return -ENOENT;
> -
> -	nonseekable_open(inode, filp);
> -
> -	u = kzalloc(sizeof(*u), GFP_KERNEL);
> -	if (u == NULL)
> -		return -ENOMEM;
> -
> -	INIT_LIST_HEAD(&u->transactions);
> -	INIT_LIST_HEAD(&u->watches);
> -	INIT_LIST_HEAD(&u->read_buffers);
> -	init_waitqueue_head(&u->read_waitq);
> -
> -	mutex_init(&u->reply_mutex);
> -	mutex_init(&u->msgbuffer_mutex);
> -
> -	filp->private_data = u;
> -
> -	return 0;
> -}
> -
> -static int xenbus_file_release(struct inode *inode, struct file *filp)
> -{
> -	struct xenbus_file_priv *u = filp->private_data;
> -	struct xenbus_transaction_holder *trans, *tmp;
> -	struct watch_adapter *watch, *tmp_watch;
> -	struct read_buffer *rb, *tmp_rb;
> -
> -	/*
> -	 * No need for locking here because there are no other users,
> -	 * by definition.
> -	 */
> -
> -	list_for_each_entry_safe(trans, tmp, &u->transactions, list) {
> -		xenbus_transaction_end(trans->handle, 1);
> -		list_del(&trans->list);
> -		kfree(trans);
> -	}
> -
> -	list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
> -		unregister_xenbus_watch(&watch->watch);
> -		list_del(&watch->list);
> -		free_watch_adapter(watch);
> -	}
> -
> -	list_for_each_entry_safe(rb, tmp_rb, &u->read_buffers, list) {
> -		list_del(&rb->list);
> -		kfree(rb);
> -	}
> -	kfree(u);
> -
> -	return 0;
> -}
> -
> -static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
> -{
> -	struct xenbus_file_priv *u = file->private_data;
> -
> -	poll_wait(file, &u->read_waitq, wait);
> -	if (!list_empty(&u->read_buffers))
> -		return POLLIN | POLLRDNORM;
> -	return 0;
> -}
> -
> -const struct file_operations xenbus_file_ops = {
> -	.read = xenbus_file_read,
> -	.write = xenbus_file_write,
> -	.open = xenbus_file_open,
> -	.release = xenbus_file_release,
> -	.poll = xenbus_file_poll,
> -	.llseek = no_llseek,
> -};
> diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
> index 5056306..6b80c77 100644
> --- a/drivers/xen/xenfs/xenfs.h
> +++ b/drivers/xen/xenfs/xenfs.h
> @@ -1,7 +1,6 @@
>  #ifndef _XENFS_XENBUS_H
>  #define _XENFS_XENBUS_H
>  
> -extern const struct file_operations xenbus_file_ops;
>  extern const struct file_operations xsd_kva_file_ops;
>  extern const struct file_operations xsd_port_file_ops;
>  
> -- 
> 1.7.7.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:11:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:11:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5fU-0000PT-QB; Mon, 28 Nov 2011 18:11:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV5fT-0000PO-L6
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:11:04 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322503821!5390594!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4135 invoked from network); 28 Nov 2011 18:10:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 18:10:23 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASIAIEq022860
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 13:10:18 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASIAISf022857;
	Mon, 28 Nov 2011 13:10:18 -0500
Date: Mon, 28 Nov 2011 14:10:18 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Bastian Blank <waldi@debian.org>
Message-ID: <20111128181018.GA21369@andromeda.dapyr.net>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-5-git-send-email-waldi@debian.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322431628-21760-5-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4/5] xen: Add xenbus device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 27, 2011 at 11:07:07PM +0100, Bastian Blank wrote:
> Access to xenbus is currently handled via xenfs. This adds a device
> driver for xenbus and makes xenfs use this code.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/xenbus/Makefile              |    1 +
>  drivers/xen/xenbus/xenbus_comms.h        |    4 +
>  drivers/xen/xenbus/xenbus_dev_frontend.c |  624 ++++++++++++++++++++++++++++++
>  drivers/xen/xenfs/Makefile               |    2 +-
>  drivers/xen/xenfs/super.c                |    3 +-
>  drivers/xen/xenfs/xenbus.c               |  593 ----------------------------
>  drivers/xen/xenfs/xenfs.h                |    1 -

Can you use 'git mv' please?

This looks  ike you are just moving the file around.

>  7 files changed, 632 insertions(+), 596 deletions(-)
>  create mode 100644 drivers/xen/xenbus/xenbus_dev_frontend.c
>  delete mode 100644 drivers/xen/xenfs/xenbus.c
> 
> diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
> index 8dca685..a2ea363 100644
> --- a/drivers/xen/xenbus/Makefile
> +++ b/drivers/xen/xenbus/Makefile
> @@ -1,4 +1,5 @@
>  obj-y	+= xenbus.o
> +obj-y	+= xenbus_dev_frontend.o
>  
>  xenbus-objs =
>  xenbus-objs += xenbus_client.o
> diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
> index c21db75..6e42800 100644
> --- a/drivers/xen/xenbus/xenbus_comms.h
> +++ b/drivers/xen/xenbus/xenbus_comms.h
> @@ -31,6 +31,8 @@
>  #ifndef _XENBUS_COMMS_H
>  #define _XENBUS_COMMS_H
>  
> +#include <linux/fs.h>
> +
>  int xs_init(void);
>  int xb_init_comms(void);
>  
> @@ -43,4 +45,6 @@ int xs_input_avail(void);
>  extern struct xenstore_domain_interface *xen_store_interface;
>  extern int xen_store_evtchn;
>  
> +extern const struct file_operations xen_xenbus_fops;
> +
>  #endif /* _XENBUS_COMMS_H */
> diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c b/drivers/xen/xenbus/xenbus_dev_frontend.c
> new file mode 100644
> index 0000000..fb30cff
> --- /dev/null
> +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
> @@ -0,0 +1,624 @@
> +/*
> + * Driver giving user-space access to the kernel's xenbus connection
> + * to xenstore.
> + *
> + * Copyright (c) 2005, Christian Limpach
> + * Copyright (c) 2005, Rusty Russell, IBM Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Changes:
> + * 2008-10-07  Alex Zeffertt    Replaced /proc/xen/xenbus with xenfs filesystem
> + *                              and /proc/xen compatibility mount point.
> + *                              Turned xenfs into a loadable module.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/errno.h>
> +#include <linux/uio.h>
> +#include <linux/notifier.h>
> +#include <linux/wait.h>
> +#include <linux/fs.h>
> +#include <linux/poll.h>
> +#include <linux/mutex.h>
> +#include <linux/sched.h>
> +#include <linux/spinlock.h>
> +#include <linux/mount.h>
> +#include <linux/pagemap.h>
> +#include <linux/uaccess.h>
> +#include <linux/init.h>
> +#include <linux/namei.h>
> +#include <linux/string.h>
> +#include <linux/slab.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +
> +#include "xenbus_comms.h"
> +
> +#include <xen/xenbus.h>
> +#include <asm/xen/hypervisor.h>
> +
> +MODULE_LICENSE("GPL");
> +
> +/*
> + * An element of a list of outstanding transactions, for which we're
> + * still waiting a reply.
> + */
> +struct xenbus_transaction_holder {
> +	struct list_head list;
> +	struct xenbus_transaction handle;
> +};
> +
> +/*
> + * A buffer of data on the queue.
> + */
> +struct read_buffer {
> +	struct list_head list;
> +	unsigned int cons;
> +	unsigned int len;
> +	char msg[];
> +};
> +
> +struct xenbus_file_priv {
> +	/*
> +	 * msgbuffer_mutex is held while partial requests are built up
> +	 * and complete requests are acted on.  It therefore protects
> +	 * the "transactions" and "watches" lists, and the partial
> +	 * request length and buffer.
> +	 *
> +	 * reply_mutex protects the reply being built up to return to
> +	 * usermode.  It nests inside msgbuffer_mutex but may be held
> +	 * alone during a watch callback.
> +	 */
> +	struct mutex msgbuffer_mutex;
> +
> +	/* In-progress transactions */
> +	struct list_head transactions;
> +
> +	/* Active watches. */
> +	struct list_head watches;
> +
> +	/* Partial request. */
> +	unsigned int len;
> +	union {
> +		struct xsd_sockmsg msg;
> +		char buffer[PAGE_SIZE];
> +	} u;
> +
> +	/* Response queue. */
> +	struct mutex reply_mutex;
> +	struct list_head read_buffers;
> +	wait_queue_head_t read_waitq;
> +
> +};
> +
> +/* Read out any raw xenbus messages queued up. */
> +static ssize_t xenbus_file_read(struct file *filp,
> +			       char __user *ubuf,
> +			       size_t len, loff_t *ppos)
> +{
> +	struct xenbus_file_priv *u = filp->private_data;
> +	struct read_buffer *rb;
> +	unsigned i;
> +	int ret;
> +
> +	mutex_lock(&u->reply_mutex);
> +again:
> +	while (list_empty(&u->read_buffers)) {
> +		mutex_unlock(&u->reply_mutex);
> +		if (filp->f_flags & O_NONBLOCK)
> +			return -EAGAIN;
> +
> +		ret = wait_event_interruptible(u->read_waitq,
> +					       !list_empty(&u->read_buffers));
> +		if (ret)
> +			return ret;
> +		mutex_lock(&u->reply_mutex);
> +	}
> +
> +	rb = list_entry(u->read_buffers.next, struct read_buffer, list);
> +	i = 0;
> +	while (i < len) {
> +		unsigned sz = min((unsigned)len - i, rb->len - rb->cons);
> +
> +		ret = copy_to_user(ubuf + i, &rb->msg[rb->cons], sz);
> +
> +		i += sz - ret;
> +		rb->cons += sz - ret;
> +
> +		if (ret != 0) {
> +			if (i == 0)
> +				i = -EFAULT;
> +			goto out;
> +		}
> +
> +		/* Clear out buffer if it has been consumed */
> +		if (rb->cons == rb->len) {
> +			list_del(&rb->list);
> +			kfree(rb);
> +			if (list_empty(&u->read_buffers))
> +				break;
> +			rb = list_entry(u->read_buffers.next,
> +					struct read_buffer, list);
> +		}
> +	}
> +	if (i == 0)
> +		goto again;
> +
> +out:
> +	mutex_unlock(&u->reply_mutex);
> +	return i;
> +}
> +
> +/*
> + * Add a buffer to the queue.  Caller must hold the appropriate lock
> + * if the queue is not local.  (Commonly the caller will build up
> + * multiple queued buffers on a temporary local list, and then add it
> + * to the appropriate list under lock once all the buffers have een
> + * successfully allocated.)
> + */
> +static int queue_reply(struct list_head *queue, const void *data, size_t len)
> +{
> +	struct read_buffer *rb;
> +
> +	if (len == 0)
> +		return 0;
> +
> +	rb = kmalloc(sizeof(*rb) + len, GFP_KERNEL);
> +	if (rb == NULL)
> +		return -ENOMEM;
> +
> +	rb->cons = 0;
> +	rb->len = len;
> +
> +	memcpy(rb->msg, data, len);
> +
> +	list_add_tail(&rb->list, queue);
> +	return 0;
> +}
> +
> +/*
> + * Free all the read_buffer s on a list.
> + * Caller must have sole reference to list.
> + */
> +static void queue_cleanup(struct list_head *list)
> +{
> +	struct read_buffer *rb;
> +
> +	while (!list_empty(list)) {
> +		rb = list_entry(list->next, struct read_buffer, list);
> +		list_del(list->next);
> +		kfree(rb);
> +	}
> +}
> +
> +struct watch_adapter {
> +	struct list_head list;
> +	struct xenbus_watch watch;
> +	struct xenbus_file_priv *dev_data;
> +	char *token;
> +};
> +
> +static void free_watch_adapter(struct watch_adapter *watch)
> +{
> +	kfree(watch->watch.node);
> +	kfree(watch->token);
> +	kfree(watch);
> +}
> +
> +static struct watch_adapter *alloc_watch_adapter(const char *path,
> +						 const char *token)
> +{
> +	struct watch_adapter *watch;
> +
> +	watch = kzalloc(sizeof(*watch), GFP_KERNEL);
> +	if (watch == NULL)
> +		goto out_fail;
> +
> +	watch->watch.node = kstrdup(path, GFP_KERNEL);
> +	if (watch->watch.node == NULL)
> +		goto out_free;
> +
> +	watch->token = kstrdup(token, GFP_KERNEL);
> +	if (watch->token == NULL)
> +		goto out_free;
> +
> +	return watch;
> +
> +out_free:
> +	free_watch_adapter(watch);
> +
> +out_fail:
> +	return NULL;
> +}
> +
> +static void watch_fired(struct xenbus_watch *watch,
> +			const char **vec,
> +			unsigned int len)
> +{
> +	struct watch_adapter *adap;
> +	struct xsd_sockmsg hdr;
> +	const char *path, *token;
> +	int path_len, tok_len, body_len, data_len = 0;
> +	int ret;
> +	LIST_HEAD(staging_q);
> +
> +	adap = container_of(watch, struct watch_adapter, watch);
> +
> +	path = vec[XS_WATCH_PATH];
> +	token = adap->token;
> +
> +	path_len = strlen(path) + 1;
> +	tok_len = strlen(token) + 1;
> +	if (len > 2)
> +		data_len = vec[len] - vec[2] + 1;
> +	body_len = path_len + tok_len + data_len;
> +
> +	hdr.type = XS_WATCH_EVENT;
> +	hdr.len = body_len;
> +
> +	mutex_lock(&adap->dev_data->reply_mutex);
> +
> +	ret = queue_reply(&staging_q, &hdr, sizeof(hdr));
> +	if (!ret)
> +		ret = queue_reply(&staging_q, path, path_len);
> +	if (!ret)
> +		ret = queue_reply(&staging_q, token, tok_len);
> +	if (!ret && len > 2)
> +		ret = queue_reply(&staging_q, vec[2], data_len);
> +
> +	if (!ret) {
> +		/* success: pass reply list onto watcher */
> +		list_splice_tail(&staging_q, &adap->dev_data->read_buffers);
> +		wake_up(&adap->dev_data->read_waitq);
> +	} else
> +		queue_cleanup(&staging_q);
> +
> +	mutex_unlock(&adap->dev_data->reply_mutex);
> +}
> +
> +static int xenbus_write_transaction(unsigned msg_type,
> +				    struct xenbus_file_priv *u)
> +{
> +	int rc;
> +	void *reply;
> +	struct xenbus_transaction_holder *trans = NULL;
> +	LIST_HEAD(staging_q);
> +
> +	if (msg_type == XS_TRANSACTION_START) {
> +		trans = kmalloc(sizeof(*trans), GFP_KERNEL);
> +		if (!trans) {
> +			rc = -ENOMEM;
> +			goto out;
> +		}
> +	}
> +
> +	reply = xenbus_dev_request_and_reply(&u->u.msg);
> +	if (IS_ERR(reply)) {
> +		kfree(trans);
> +		rc = PTR_ERR(reply);
> +		goto out;
> +	}
> +
> +	if (msg_type == XS_TRANSACTION_START) {
> +		trans->handle.id = simple_strtoul(reply, NULL, 0);
> +
> +		list_add(&trans->list, &u->transactions);
> +	} else if (msg_type == XS_TRANSACTION_END) {
> +		list_for_each_entry(trans, &u->transactions, list)
> +			if (trans->handle.id == u->u.msg.tx_id)
> +				break;
> +		BUG_ON(&trans->list == &u->transactions);
> +		list_del(&trans->list);
> +
> +		kfree(trans);
> +	}
> +
> +	mutex_lock(&u->reply_mutex);
> +	rc = queue_reply(&staging_q, &u->u.msg, sizeof(u->u.msg));
> +	if (!rc)
> +		rc = queue_reply(&staging_q, reply, u->u.msg.len);
> +	if (!rc) {
> +		list_splice_tail(&staging_q, &u->read_buffers);
> +		wake_up(&u->read_waitq);
> +	} else {
> +		queue_cleanup(&staging_q);
> +	}
> +	mutex_unlock(&u->reply_mutex);
> +
> +	kfree(reply);
> +
> +out:
> +	return rc;
> +}
> +
> +static int xenbus_write_watch(unsigned msg_type, struct xenbus_file_priv *u)
> +{
> +	struct watch_adapter *watch, *tmp_watch;
> +	char *path, *token;
> +	int err, rc;
> +	LIST_HEAD(staging_q);
> +
> +	path = u->u.buffer + sizeof(u->u.msg);
> +	token = memchr(path, 0, u->u.msg.len);
> +	if (token == NULL) {
> +		rc = -EILSEQ;
> +		goto out;
> +	}
> +	token++;
> +
> +	if (msg_type == XS_WATCH) {
> +		watch = alloc_watch_adapter(path, token);
> +		if (watch == NULL) {
> +			rc = -ENOMEM;
> +			goto out;
> +		}
> +
> +		watch->watch.callback = watch_fired;
> +		watch->dev_data = u;
> +
> +		err = register_xenbus_watch(&watch->watch);
> +		if (err) {
> +			free_watch_adapter(watch);
> +			rc = err;
> +			goto out;
> +		}
> +		list_add(&watch->list, &u->watches);
> +	} else {
> +		list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
> +			if (!strcmp(watch->token, token) &&
> +			    !strcmp(watch->watch.node, path)) {
> +				unregister_xenbus_watch(&watch->watch);
> +				list_del(&watch->list);
> +				free_watch_adapter(watch);
> +				break;
> +			}
> +		}
> +	}
> +
> +	/* Success.  Synthesize a reply to say all is OK. */
> +	{
> +		struct {
> +			struct xsd_sockmsg hdr;
> +			char body[3];
> +		} __packed reply = {
> +			{
> +				.type = msg_type,
> +				.len = sizeof(reply.body)
> +			},
> +			"OK"
> +		};
> +
> +		mutex_lock(&u->reply_mutex);
> +		rc = queue_reply(&u->read_buffers, &reply, sizeof(reply));
> +		wake_up(&u->read_waitq);
> +		mutex_unlock(&u->reply_mutex);
> +	}
> +
> +out:
> +	return rc;
> +}
> +
> +static ssize_t xenbus_file_write(struct file *filp,
> +				const char __user *ubuf,
> +				size_t len, loff_t *ppos)
> +{
> +	struct xenbus_file_priv *u = filp->private_data;
> +	uint32_t msg_type;
> +	int rc = len;
> +	int ret;
> +	LIST_HEAD(staging_q);
> +
> +	/*
> +	 * We're expecting usermode to be writing properly formed
> +	 * xenbus messages.  If they write an incomplete message we
> +	 * buffer it up.  Once it is complete, we act on it.
> +	 */
> +
> +	/*
> +	 * Make sure concurrent writers can't stomp all over each
> +	 * other's messages and make a mess of our partial message
> +	 * buffer.  We don't make any attemppt to stop multiple
> +	 * writers from making a mess of each other's incomplete
> +	 * messages; we're just trying to guarantee our own internal
> +	 * consistency and make sure that single writes are handled
> +	 * atomically.
> +	 */
> +	mutex_lock(&u->msgbuffer_mutex);
> +
> +	/* Get this out of the way early to avoid confusion */
> +	if (len == 0)
> +		goto out;
> +
> +	/* Can't write a xenbus message larger we can buffer */
> +	if ((len + u->len) > sizeof(u->u.buffer)) {
> +		/* On error, dump existing buffer */
> +		u->len = 0;
> +		rc = -EINVAL;
> +		goto out;
> +	}
> +
> +	ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
> +
> +	if (ret != 0) {
> +		rc = -EFAULT;
> +		goto out;
> +	}
> +
> +	/* Deal with a partial copy. */
> +	len -= ret;
> +	rc = len;
> +
> +	u->len += len;
> +
> +	/* Return if we haven't got a full message yet */
> +	if (u->len < sizeof(u->u.msg))
> +		goto out;	/* not even the header yet */
> +
> +	/* If we're expecting a message that's larger than we can
> +	   possibly send, dump what we have and return an error. */
> +	if ((sizeof(u->u.msg) + u->u.msg.len) > sizeof(u->u.buffer)) {
> +		rc = -E2BIG;
> +		u->len = 0;
> +		goto out;
> +	}
> +
> +	if (u->len < (sizeof(u->u.msg) + u->u.msg.len))
> +		goto out;	/* incomplete data portion */
> +
> +	/*
> +	 * OK, now we have a complete message.  Do something with it.
> +	 */
> +
> +	msg_type = u->u.msg.type;
> +
> +	switch (msg_type) {
> +	case XS_WATCH:
> +	case XS_UNWATCH:
> +		/* (Un)Ask for some path to be watched for changes */
> +		ret = xenbus_write_watch(msg_type, u);
> +		break;
> +
> +	default:
> +		/* Send out a transaction */
> +		ret = xenbus_write_transaction(msg_type, u);
> +		break;
> +	}
> +	if (ret != 0)
> +		rc = ret;
> +
> +	/* Buffered message consumed */
> +	u->len = 0;
> +
> + out:
> +	mutex_unlock(&u->msgbuffer_mutex);
> +	return rc;
> +}
> +
> +static int xenbus_file_open(struct inode *inode, struct file *filp)
> +{
> +	struct xenbus_file_priv *u;
> +
> +	if (xen_store_evtchn == 0)
> +		return -ENOENT;
> +
> +	nonseekable_open(inode, filp);
> +
> +	u = kzalloc(sizeof(*u), GFP_KERNEL);
> +	if (u == NULL)
> +		return -ENOMEM;
> +
> +	INIT_LIST_HEAD(&u->transactions);
> +	INIT_LIST_HEAD(&u->watches);
> +	INIT_LIST_HEAD(&u->read_buffers);
> +	init_waitqueue_head(&u->read_waitq);
> +
> +	mutex_init(&u->reply_mutex);
> +	mutex_init(&u->msgbuffer_mutex);
> +
> +	filp->private_data = u;
> +
> +	return 0;
> +}
> +
> +static int xenbus_file_release(struct inode *inode, struct file *filp)
> +{
> +	struct xenbus_file_priv *u = filp->private_data;
> +	struct xenbus_transaction_holder *trans, *tmp;
> +	struct watch_adapter *watch, *tmp_watch;
> +	struct read_buffer *rb, *tmp_rb;
> +
> +	/*
> +	 * No need for locking here because there are no other users,
> +	 * by definition.
> +	 */
> +
> +	list_for_each_entry_safe(trans, tmp, &u->transactions, list) {
> +		xenbus_transaction_end(trans->handle, 1);
> +		list_del(&trans->list);
> +		kfree(trans);
> +	}
> +
> +	list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
> +		unregister_xenbus_watch(&watch->watch);
> +		list_del(&watch->list);
> +		free_watch_adapter(watch);
> +	}
> +
> +	list_for_each_entry_safe(rb, tmp_rb, &u->read_buffers, list) {
> +		list_del(&rb->list);
> +		kfree(rb);
> +	}
> +	kfree(u);
> +
> +	return 0;
> +}
> +
> +static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
> +{
> +	struct xenbus_file_priv *u = file->private_data;
> +
> +	poll_wait(file, &u->read_waitq, wait);
> +	if (!list_empty(&u->read_buffers))
> +		return POLLIN | POLLRDNORM;
> +	return 0;
> +}
> +
> +const struct file_operations xen_xenbus_fops = {
> +	.read = xenbus_file_read,
> +	.write = xenbus_file_write,
> +	.open = xenbus_file_open,
> +	.release = xenbus_file_release,
> +	.poll = xenbus_file_poll,
> +	.llseek = no_llseek,
> +};
> +EXPORT_SYMBOL_GPL(xen_xenbus_fops);
> +
> +static struct miscdevice xenbus_dev = {
> +	.minor = MISC_DYNAMIC_MINOR,
> +	.name = "xen/xenbus",
> +	.fops = &xen_xenbus_fops,
> +};
> +
> +static int __init xenbus_init(void)
> +{
> +	int err;
> +
> +	if (!xen_domain())
> +		return -ENODEV;
> +
> +	err = misc_register(&xenbus_dev);
> +	if (err)
> +		printk(KERN_ERR "Could not register xenbus device\n");
> +	return err;
> +}
> +
> +static void __exit xenbus_exit(void)
> +{
> +	misc_deregister(&xenbus_dev);
> +}
> +
> +module_init(xenbus_init);
> +module_exit(xenbus_exit);
> diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
> index 5d45ff1..b019865 100644
> --- a/drivers/xen/xenfs/Makefile
> +++ b/drivers/xen/xenfs/Makefile
> @@ -1,4 +1,4 @@
>  obj-$(CONFIG_XENFS) += xenfs.o
>  
> -xenfs-y			  = super.o xenbus.o
> +xenfs-y			  = super.o
>  xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
> diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
> index a55fbf9..a84b53c 100644
> --- a/drivers/xen/xenfs/super.c
> +++ b/drivers/xen/xenfs/super.c
> @@ -17,6 +17,7 @@
>  
>  #include "xenfs.h"
>  #include "../privcmd.h"
> +#include "../xenbus/xenbus_comms.h"
>  
>  #include <asm/xen/hypervisor.h>
>  
> @@ -83,7 +84,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
>  {
>  	static struct tree_descr xenfs_files[] = {
>  		[1] = {},
> -		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
> +		{ "xenbus", &xen_xenbus_fops, S_IRUSR|S_IWUSR },
>  		{ "capabilities", &capabilities_file_ops, S_IRUGO },
>  		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
>  		{""},
> diff --git a/drivers/xen/xenfs/xenbus.c b/drivers/xen/xenfs/xenbus.c
> deleted file mode 100644
> index bbd000f..0000000
> --- a/drivers/xen/xenfs/xenbus.c
> +++ /dev/null
> @@ -1,593 +0,0 @@
> -/*
> - * Driver giving user-space access to the kernel's xenbus connection
> - * to xenstore.
> - *
> - * Copyright (c) 2005, Christian Limpach
> - * Copyright (c) 2005, Rusty Russell, IBM Corporation
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License version 2
> - * as published by the Free Software Foundation; or, when distributed
> - * separately from the Linux kernel or incorporated into other
> - * software packages, subject to the following license:
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a copy
> - * of this source file (the "Software"), to deal in the Software without
> - * restriction, including without limitation the rights to use, copy, modify,
> - * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> - * and to permit persons to whom the Software is furnished to do so, subject to
> - * the following conditions:
> - *
> - * The above copyright notice and this permission notice shall be included in
> - * all copies or substantial portions of the Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> - * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> - * IN THE SOFTWARE.
> - *
> - * Changes:
> - * 2008-10-07  Alex Zeffertt    Replaced /proc/xen/xenbus with xenfs filesystem
> - *                              and /proc/xen compatibility mount point.
> - *                              Turned xenfs into a loadable module.
> - */
> -
> -#include <linux/kernel.h>
> -#include <linux/errno.h>
> -#include <linux/uio.h>
> -#include <linux/notifier.h>
> -#include <linux/wait.h>
> -#include <linux/fs.h>
> -#include <linux/poll.h>
> -#include <linux/mutex.h>
> -#include <linux/sched.h>
> -#include <linux/spinlock.h>
> -#include <linux/mount.h>
> -#include <linux/pagemap.h>
> -#include <linux/uaccess.h>
> -#include <linux/init.h>
> -#include <linux/namei.h>
> -#include <linux/string.h>
> -#include <linux/slab.h>
> -
> -#include "xenfs.h"
> -#include "../xenbus/xenbus_comms.h"
> -
> -#include <xen/xenbus.h>
> -#include <asm/xen/hypervisor.h>
> -
> -/*
> - * An element of a list of outstanding transactions, for which we're
> - * still waiting a reply.
> - */
> -struct xenbus_transaction_holder {
> -	struct list_head list;
> -	struct xenbus_transaction handle;
> -};
> -
> -/*
> - * A buffer of data on the queue.
> - */
> -struct read_buffer {
> -	struct list_head list;
> -	unsigned int cons;
> -	unsigned int len;
> -	char msg[];
> -};
> -
> -struct xenbus_file_priv {
> -	/*
> -	 * msgbuffer_mutex is held while partial requests are built up
> -	 * and complete requests are acted on.  It therefore protects
> -	 * the "transactions" and "watches" lists, and the partial
> -	 * request length and buffer.
> -	 *
> -	 * reply_mutex protects the reply being built up to return to
> -	 * usermode.  It nests inside msgbuffer_mutex but may be held
> -	 * alone during a watch callback.
> -	 */
> -	struct mutex msgbuffer_mutex;
> -
> -	/* In-progress transactions */
> -	struct list_head transactions;
> -
> -	/* Active watches. */
> -	struct list_head watches;
> -
> -	/* Partial request. */
> -	unsigned int len;
> -	union {
> -		struct xsd_sockmsg msg;
> -		char buffer[PAGE_SIZE];
> -	} u;
> -
> -	/* Response queue. */
> -	struct mutex reply_mutex;
> -	struct list_head read_buffers;
> -	wait_queue_head_t read_waitq;
> -
> -};
> -
> -/* Read out any raw xenbus messages queued up. */
> -static ssize_t xenbus_file_read(struct file *filp,
> -			       char __user *ubuf,
> -			       size_t len, loff_t *ppos)
> -{
> -	struct xenbus_file_priv *u = filp->private_data;
> -	struct read_buffer *rb;
> -	unsigned i;
> -	int ret;
> -
> -	mutex_lock(&u->reply_mutex);
> -again:
> -	while (list_empty(&u->read_buffers)) {
> -		mutex_unlock(&u->reply_mutex);
> -		if (filp->f_flags & O_NONBLOCK)
> -			return -EAGAIN;
> -
> -		ret = wait_event_interruptible(u->read_waitq,
> -					       !list_empty(&u->read_buffers));
> -		if (ret)
> -			return ret;
> -		mutex_lock(&u->reply_mutex);
> -	}
> -
> -	rb = list_entry(u->read_buffers.next, struct read_buffer, list);
> -	i = 0;
> -	while (i < len) {
> -		unsigned sz = min((unsigned)len - i, rb->len - rb->cons);
> -
> -		ret = copy_to_user(ubuf + i, &rb->msg[rb->cons], sz);
> -
> -		i += sz - ret;
> -		rb->cons += sz - ret;
> -
> -		if (ret != 0) {
> -			if (i == 0)
> -				i = -EFAULT;
> -			goto out;
> -		}
> -
> -		/* Clear out buffer if it has been consumed */
> -		if (rb->cons == rb->len) {
> -			list_del(&rb->list);
> -			kfree(rb);
> -			if (list_empty(&u->read_buffers))
> -				break;
> -			rb = list_entry(u->read_buffers.next,
> -					struct read_buffer, list);
> -		}
> -	}
> -	if (i == 0)
> -		goto again;
> -
> -out:
> -	mutex_unlock(&u->reply_mutex);
> -	return i;
> -}
> -
> -/*
> - * Add a buffer to the queue.  Caller must hold the appropriate lock
> - * if the queue is not local.  (Commonly the caller will build up
> - * multiple queued buffers on a temporary local list, and then add it
> - * to the appropriate list under lock once all the buffers have een
> - * successfully allocated.)
> - */
> -static int queue_reply(struct list_head *queue, const void *data, size_t len)
> -{
> -	struct read_buffer *rb;
> -
> -	if (len == 0)
> -		return 0;
> -
> -	rb = kmalloc(sizeof(*rb) + len, GFP_KERNEL);
> -	if (rb == NULL)
> -		return -ENOMEM;
> -
> -	rb->cons = 0;
> -	rb->len = len;
> -
> -	memcpy(rb->msg, data, len);
> -
> -	list_add_tail(&rb->list, queue);
> -	return 0;
> -}
> -
> -/*
> - * Free all the read_buffer s on a list.
> - * Caller must have sole reference to list.
> - */
> -static void queue_cleanup(struct list_head *list)
> -{
> -	struct read_buffer *rb;
> -
> -	while (!list_empty(list)) {
> -		rb = list_entry(list->next, struct read_buffer, list);
> -		list_del(list->next);
> -		kfree(rb);
> -	}
> -}
> -
> -struct watch_adapter {
> -	struct list_head list;
> -	struct xenbus_watch watch;
> -	struct xenbus_file_priv *dev_data;
> -	char *token;
> -};
> -
> -static void free_watch_adapter(struct watch_adapter *watch)
> -{
> -	kfree(watch->watch.node);
> -	kfree(watch->token);
> -	kfree(watch);
> -}
> -
> -static struct watch_adapter *alloc_watch_adapter(const char *path,
> -						 const char *token)
> -{
> -	struct watch_adapter *watch;
> -
> -	watch = kzalloc(sizeof(*watch), GFP_KERNEL);
> -	if (watch == NULL)
> -		goto out_fail;
> -
> -	watch->watch.node = kstrdup(path, GFP_KERNEL);
> -	if (watch->watch.node == NULL)
> -		goto out_free;
> -
> -	watch->token = kstrdup(token, GFP_KERNEL);
> -	if (watch->token == NULL)
> -		goto out_free;
> -
> -	return watch;
> -
> -out_free:
> -	free_watch_adapter(watch);
> -
> -out_fail:
> -	return NULL;
> -}
> -
> -static void watch_fired(struct xenbus_watch *watch,
> -			const char **vec,
> -			unsigned int len)
> -{
> -	struct watch_adapter *adap;
> -	struct xsd_sockmsg hdr;
> -	const char *path, *token;
> -	int path_len, tok_len, body_len, data_len = 0;
> -	int ret;
> -	LIST_HEAD(staging_q);
> -
> -	adap = container_of(watch, struct watch_adapter, watch);
> -
> -	path = vec[XS_WATCH_PATH];
> -	token = adap->token;
> -
> -	path_len = strlen(path) + 1;
> -	tok_len = strlen(token) + 1;
> -	if (len > 2)
> -		data_len = vec[len] - vec[2] + 1;
> -	body_len = path_len + tok_len + data_len;
> -
> -	hdr.type = XS_WATCH_EVENT;
> -	hdr.len = body_len;
> -
> -	mutex_lock(&adap->dev_data->reply_mutex);
> -
> -	ret = queue_reply(&staging_q, &hdr, sizeof(hdr));
> -	if (!ret)
> -		ret = queue_reply(&staging_q, path, path_len);
> -	if (!ret)
> -		ret = queue_reply(&staging_q, token, tok_len);
> -	if (!ret && len > 2)
> -		ret = queue_reply(&staging_q, vec[2], data_len);
> -
> -	if (!ret) {
> -		/* success: pass reply list onto watcher */
> -		list_splice_tail(&staging_q, &adap->dev_data->read_buffers);
> -		wake_up(&adap->dev_data->read_waitq);
> -	} else
> -		queue_cleanup(&staging_q);
> -
> -	mutex_unlock(&adap->dev_data->reply_mutex);
> -}
> -
> -static int xenbus_write_transaction(unsigned msg_type,
> -				    struct xenbus_file_priv *u)
> -{
> -	int rc;
> -	void *reply;
> -	struct xenbus_transaction_holder *trans = NULL;
> -	LIST_HEAD(staging_q);
> -
> -	if (msg_type == XS_TRANSACTION_START) {
> -		trans = kmalloc(sizeof(*trans), GFP_KERNEL);
> -		if (!trans) {
> -			rc = -ENOMEM;
> -			goto out;
> -		}
> -	}
> -
> -	reply = xenbus_dev_request_and_reply(&u->u.msg);
> -	if (IS_ERR(reply)) {
> -		kfree(trans);
> -		rc = PTR_ERR(reply);
> -		goto out;
> -	}
> -
> -	if (msg_type == XS_TRANSACTION_START) {
> -		trans->handle.id = simple_strtoul(reply, NULL, 0);
> -
> -		list_add(&trans->list, &u->transactions);
> -	} else if (msg_type == XS_TRANSACTION_END) {
> -		list_for_each_entry(trans, &u->transactions, list)
> -			if (trans->handle.id == u->u.msg.tx_id)
> -				break;
> -		BUG_ON(&trans->list == &u->transactions);
> -		list_del(&trans->list);
> -
> -		kfree(trans);
> -	}
> -
> -	mutex_lock(&u->reply_mutex);
> -	rc = queue_reply(&staging_q, &u->u.msg, sizeof(u->u.msg));
> -	if (!rc)
> -		rc = queue_reply(&staging_q, reply, u->u.msg.len);
> -	if (!rc) {
> -		list_splice_tail(&staging_q, &u->read_buffers);
> -		wake_up(&u->read_waitq);
> -	} else {
> -		queue_cleanup(&staging_q);
> -	}
> -	mutex_unlock(&u->reply_mutex);
> -
> -	kfree(reply);
> -
> -out:
> -	return rc;
> -}
> -
> -static int xenbus_write_watch(unsigned msg_type, struct xenbus_file_priv *u)
> -{
> -	struct watch_adapter *watch, *tmp_watch;
> -	char *path, *token;
> -	int err, rc;
> -	LIST_HEAD(staging_q);
> -
> -	path = u->u.buffer + sizeof(u->u.msg);
> -	token = memchr(path, 0, u->u.msg.len);
> -	if (token == NULL) {
> -		rc = -EILSEQ;
> -		goto out;
> -	}
> -	token++;
> -
> -	if (msg_type == XS_WATCH) {
> -		watch = alloc_watch_adapter(path, token);
> -		if (watch == NULL) {
> -			rc = -ENOMEM;
> -			goto out;
> -		}
> -
> -		watch->watch.callback = watch_fired;
> -		watch->dev_data = u;
> -
> -		err = register_xenbus_watch(&watch->watch);
> -		if (err) {
> -			free_watch_adapter(watch);
> -			rc = err;
> -			goto out;
> -		}
> -		list_add(&watch->list, &u->watches);
> -	} else {
> -		list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
> -			if (!strcmp(watch->token, token) &&
> -			    !strcmp(watch->watch.node, path)) {
> -				unregister_xenbus_watch(&watch->watch);
> -				list_del(&watch->list);
> -				free_watch_adapter(watch);
> -				break;
> -			}
> -		}
> -	}
> -
> -	/* Success.  Synthesize a reply to say all is OK. */
> -	{
> -		struct {
> -			struct xsd_sockmsg hdr;
> -			char body[3];
> -		} __packed reply = {
> -			{
> -				.type = msg_type,
> -				.len = sizeof(reply.body)
> -			},
> -			"OK"
> -		};
> -
> -		mutex_lock(&u->reply_mutex);
> -		rc = queue_reply(&u->read_buffers, &reply, sizeof(reply));
> -		wake_up(&u->read_waitq);
> -		mutex_unlock(&u->reply_mutex);
> -	}
> -
> -out:
> -	return rc;
> -}
> -
> -static ssize_t xenbus_file_write(struct file *filp,
> -				const char __user *ubuf,
> -				size_t len, loff_t *ppos)
> -{
> -	struct xenbus_file_priv *u = filp->private_data;
> -	uint32_t msg_type;
> -	int rc = len;
> -	int ret;
> -	LIST_HEAD(staging_q);
> -
> -	/*
> -	 * We're expecting usermode to be writing properly formed
> -	 * xenbus messages.  If they write an incomplete message we
> -	 * buffer it up.  Once it is complete, we act on it.
> -	 */
> -
> -	/*
> -	 * Make sure concurrent writers can't stomp all over each
> -	 * other's messages and make a mess of our partial message
> -	 * buffer.  We don't make any attemppt to stop multiple
> -	 * writers from making a mess of each other's incomplete
> -	 * messages; we're just trying to guarantee our own internal
> -	 * consistency and make sure that single writes are handled
> -	 * atomically.
> -	 */
> -	mutex_lock(&u->msgbuffer_mutex);
> -
> -	/* Get this out of the way early to avoid confusion */
> -	if (len == 0)
> -		goto out;
> -
> -	/* Can't write a xenbus message larger we can buffer */
> -	if ((len + u->len) > sizeof(u->u.buffer)) {
> -		/* On error, dump existing buffer */
> -		u->len = 0;
> -		rc = -EINVAL;
> -		goto out;
> -	}
> -
> -	ret = copy_from_user(u->u.buffer + u->len, ubuf, len);
> -
> -	if (ret != 0) {
> -		rc = -EFAULT;
> -		goto out;
> -	}
> -
> -	/* Deal with a partial copy. */
> -	len -= ret;
> -	rc = len;
> -
> -	u->len += len;
> -
> -	/* Return if we haven't got a full message yet */
> -	if (u->len < sizeof(u->u.msg))
> -		goto out;	/* not even the header yet */
> -
> -	/* If we're expecting a message that's larger than we can
> -	   possibly send, dump what we have and return an error. */
> -	if ((sizeof(u->u.msg) + u->u.msg.len) > sizeof(u->u.buffer)) {
> -		rc = -E2BIG;
> -		u->len = 0;
> -		goto out;
> -	}
> -
> -	if (u->len < (sizeof(u->u.msg) + u->u.msg.len))
> -		goto out;	/* incomplete data portion */
> -
> -	/*
> -	 * OK, now we have a complete message.  Do something with it.
> -	 */
> -
> -	msg_type = u->u.msg.type;
> -
> -	switch (msg_type) {
> -	case XS_WATCH:
> -	case XS_UNWATCH:
> -		/* (Un)Ask for some path to be watched for changes */
> -		ret = xenbus_write_watch(msg_type, u);
> -		break;
> -
> -	default:
> -		/* Send out a transaction */
> -		ret = xenbus_write_transaction(msg_type, u);
> -		break;
> -	}
> -	if (ret != 0)
> -		rc = ret;
> -
> -	/* Buffered message consumed */
> -	u->len = 0;
> -
> - out:
> -	mutex_unlock(&u->msgbuffer_mutex);
> -	return rc;
> -}
> -
> -static int xenbus_file_open(struct inode *inode, struct file *filp)
> -{
> -	struct xenbus_file_priv *u;
> -
> -	if (xen_store_evtchn == 0)
> -		return -ENOENT;
> -
> -	nonseekable_open(inode, filp);
> -
> -	u = kzalloc(sizeof(*u), GFP_KERNEL);
> -	if (u == NULL)
> -		return -ENOMEM;
> -
> -	INIT_LIST_HEAD(&u->transactions);
> -	INIT_LIST_HEAD(&u->watches);
> -	INIT_LIST_HEAD(&u->read_buffers);
> -	init_waitqueue_head(&u->read_waitq);
> -
> -	mutex_init(&u->reply_mutex);
> -	mutex_init(&u->msgbuffer_mutex);
> -
> -	filp->private_data = u;
> -
> -	return 0;
> -}
> -
> -static int xenbus_file_release(struct inode *inode, struct file *filp)
> -{
> -	struct xenbus_file_priv *u = filp->private_data;
> -	struct xenbus_transaction_holder *trans, *tmp;
> -	struct watch_adapter *watch, *tmp_watch;
> -	struct read_buffer *rb, *tmp_rb;
> -
> -	/*
> -	 * No need for locking here because there are no other users,
> -	 * by definition.
> -	 */
> -
> -	list_for_each_entry_safe(trans, tmp, &u->transactions, list) {
> -		xenbus_transaction_end(trans->handle, 1);
> -		list_del(&trans->list);
> -		kfree(trans);
> -	}
> -
> -	list_for_each_entry_safe(watch, tmp_watch, &u->watches, list) {
> -		unregister_xenbus_watch(&watch->watch);
> -		list_del(&watch->list);
> -		free_watch_adapter(watch);
> -	}
> -
> -	list_for_each_entry_safe(rb, tmp_rb, &u->read_buffers, list) {
> -		list_del(&rb->list);
> -		kfree(rb);
> -	}
> -	kfree(u);
> -
> -	return 0;
> -}
> -
> -static unsigned int xenbus_file_poll(struct file *file, poll_table *wait)
> -{
> -	struct xenbus_file_priv *u = file->private_data;
> -
> -	poll_wait(file, &u->read_waitq, wait);
> -	if (!list_empty(&u->read_buffers))
> -		return POLLIN | POLLRDNORM;
> -	return 0;
> -}
> -
> -const struct file_operations xenbus_file_ops = {
> -	.read = xenbus_file_read,
> -	.write = xenbus_file_write,
> -	.open = xenbus_file_open,
> -	.release = xenbus_file_release,
> -	.poll = xenbus_file_poll,
> -	.llseek = no_llseek,
> -};
> diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
> index 5056306..6b80c77 100644
> --- a/drivers/xen/xenfs/xenfs.h
> +++ b/drivers/xen/xenfs/xenfs.h
> @@ -1,7 +1,6 @@
>  #ifndef _XENFS_XENBUS_H
>  #define _XENFS_XENBUS_H
>  
> -extern const struct file_operations xenbus_file_ops;
>  extern const struct file_operations xsd_kva_file_ops;
>  extern const struct file_operations xsd_port_file_ops;
>  
> -- 
> 1.7.7.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:15:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5ja-0000rX-9F; Mon, 28 Nov 2011 18:15:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV5jY-0000qs-PC
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:15:16 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322504046!45763657!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12053 invoked from network); 28 Nov 2011 18:14:07 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 18:14:07 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASIEdb1023053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 13:14:39 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASIEdev023051;
	Mon, 28 Nov 2011 13:14:39 -0500
Date: Mon, 28 Nov 2011 14:14:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Bastian Blank <waldi@debian.org>
Message-ID: <20111128181439.GB21369@andromeda.dapyr.net>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-2-git-send-email-waldi@debian.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322431628-21760-2-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/5] xen/sys/hypervisor: Export
	guest_properties/is_initial_domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 27, 2011 at 11:07:04PM +0100, Bastian Blank wrote:
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/sys-hypervisor.c |   35 +++++++++++++++++++++++++++++++++++

You also need a patch to the Documentation ABI (sysfs something).


>  1 files changed, 35 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 1e0fe01..d0916e8 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -355,6 +355,35 @@ static void xen_properties_destroy(void)
>  	sysfs_remove_group(hypervisor_kobj, &xen_properties_group);
>  }
>  
> +/* xen guest properties info */

Properties is plural, but this is a single attribute.

The 'guest_properties' does not tell _what_ type of property this
is? Nor its purpose. Perhaps the name 'is_initial_domain' would be a
better name? What is the purpose of this attribute? Who/what tools
benefit from this? Is there a corresponding patch in the Xen tool stack
to utilize this?

Thanks!
> +
> +static ssize_t is_initial_domain_show(struct hyp_sysfs_attr *attr, char *buffer)
> +{
> +	return sprintf(buffer, "%d\n", xen_initial_domain());
> +}
> +
> +HYPERVISOR_ATTR_RO(is_initial_domain);
> +
> +static struct attribute *xen_guest_properties_attrs[] = {
> +	&is_initial_domain_attr.attr,
> +	NULL
> +};
> +
> +static struct attribute_group xen_guest_properties_group = {
> +	.name = "guest_properties",
> +	.attrs = xen_guest_properties_attrs,
> +};
> +
> +static int __init xen_guest_properties_init(void)
> +{
> +	return sysfs_create_group(hypervisor_kobj, &xen_guest_properties_group);
> +}
> +
> +static void xen_guest_properties_destroy(void)
> +{
> +	sysfs_remove_group(hypervisor_kobj, &xen_guest_properties_group);
> +}
> +
>  static int __init hyper_sysfs_init(void)
>  {
>  	int ret;
> @@ -377,9 +406,14 @@ static int __init hyper_sysfs_init(void)
>  	ret = xen_properties_init();
>  	if (ret)
>  		goto prop_out;
> +	ret = xen_guest_properties_init();
> +	if (ret)
> +		goto gprop_out;
>  
>  	goto out;
>  
> +gprop_out:
> +	xen_properties_destroy();
>  prop_out:
>  	xen_sysfs_uuid_destroy();
>  uuid_out:
> @@ -394,6 +428,7 @@ out:
>  
>  static void __exit hyper_sysfs_exit(void)
>  {
> +	xen_guest_properties_destroy();
>  	xen_properties_destroy();
>  	xen_compilation_destroy();
>  	xen_sysfs_uuid_destroy();
> -- 
> 1.7.7.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:15:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:15:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5ja-0000rX-9F; Mon, 28 Nov 2011 18:15:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV5jY-0000qs-PC
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:15:16 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322504046!45763657!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12053 invoked from network); 28 Nov 2011 18:14:07 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 18:14:07 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASIEdb1023053
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 13:14:39 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASIEdev023051;
	Mon, 28 Nov 2011 13:14:39 -0500
Date: Mon, 28 Nov 2011 14:14:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Bastian Blank <waldi@debian.org>
Message-ID: <20111128181439.GB21369@andromeda.dapyr.net>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-2-git-send-email-waldi@debian.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322431628-21760-2-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/5] xen/sys/hypervisor: Export
	guest_properties/is_initial_domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 27, 2011 at 11:07:04PM +0100, Bastian Blank wrote:
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/sys-hypervisor.c |   35 +++++++++++++++++++++++++++++++++++

You also need a patch to the Documentation ABI (sysfs something).


>  1 files changed, 35 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> index 1e0fe01..d0916e8 100644
> --- a/drivers/xen/sys-hypervisor.c
> +++ b/drivers/xen/sys-hypervisor.c
> @@ -355,6 +355,35 @@ static void xen_properties_destroy(void)
>  	sysfs_remove_group(hypervisor_kobj, &xen_properties_group);
>  }
>  
> +/* xen guest properties info */

Properties is plural, but this is a single attribute.

The 'guest_properties' does not tell _what_ type of property this
is? Nor its purpose. Perhaps the name 'is_initial_domain' would be a
better name? What is the purpose of this attribute? Who/what tools
benefit from this? Is there a corresponding patch in the Xen tool stack
to utilize this?

Thanks!
> +
> +static ssize_t is_initial_domain_show(struct hyp_sysfs_attr *attr, char *buffer)
> +{
> +	return sprintf(buffer, "%d\n", xen_initial_domain());
> +}
> +
> +HYPERVISOR_ATTR_RO(is_initial_domain);
> +
> +static struct attribute *xen_guest_properties_attrs[] = {
> +	&is_initial_domain_attr.attr,
> +	NULL
> +};
> +
> +static struct attribute_group xen_guest_properties_group = {
> +	.name = "guest_properties",
> +	.attrs = xen_guest_properties_attrs,
> +};
> +
> +static int __init xen_guest_properties_init(void)
> +{
> +	return sysfs_create_group(hypervisor_kobj, &xen_guest_properties_group);
> +}
> +
> +static void xen_guest_properties_destroy(void)
> +{
> +	sysfs_remove_group(hypervisor_kobj, &xen_guest_properties_group);
> +}
> +
>  static int __init hyper_sysfs_init(void)
>  {
>  	int ret;
> @@ -377,9 +406,14 @@ static int __init hyper_sysfs_init(void)
>  	ret = xen_properties_init();
>  	if (ret)
>  		goto prop_out;
> +	ret = xen_guest_properties_init();
> +	if (ret)
> +		goto gprop_out;
>  
>  	goto out;
>  
> +gprop_out:
> +	xen_properties_destroy();
>  prop_out:
>  	xen_sysfs_uuid_destroy();
>  uuid_out:
> @@ -394,6 +428,7 @@ out:
>  
>  static void __exit hyper_sysfs_exit(void)
>  {
> +	xen_guest_properties_destroy();
>  	xen_properties_destroy();
>  	xen_compilation_destroy();
>  	xen_sysfs_uuid_destroy();
> -- 
> 1.7.7.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:23:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:23:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5qq-0001Mc-85; Mon, 28 Nov 2011 18:22:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV5qp-0001ML-6W
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:22:47 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322504527!3421513!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31481 invoked from network); 28 Nov 2011 18:22:09 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 18:22:09 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASIM5LF023309
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 13:22:05 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASIM55f023307;
	Mon, 28 Nov 2011 13:22:05 -0500
Date: Mon, 28 Nov 2011 14:22:05 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Bastian Blank <waldi@debian.org>
Message-ID: <20111128182205.GC21369@andromeda.dapyr.net>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322431628-21760-3-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 27, 2011 at 11:07:05PM +0100, Bastian Blank wrote:
> Access to arbitrary hypercalls is currently provided via xenfs. This
> adds a standard character device to handle this. The support in xenfs

Ok, what is the benefit of that? You mentioned in the prologue "about a
year ago I started", but you didn't provide any links to the
conversation. Could you include the details please?

> remains for backward compatibility and uses the device driver code.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/Kconfig         |    7 +
>  drivers/xen/Makefile        |    2 +
>  drivers/xen/privcmd.c       |  437 +++++++++++++++++++++++++++++++++++++++++++
>  drivers/xen/privcmd.h       |    3 +
>  drivers/xen/xenfs/Makefile  |    2 +-
>  drivers/xen/xenfs/privcmd.c |  400 ---------------------------------------

It looks like you are doing a move of the file. Can you use 'git mv'
instead please.

If it breaks compile build, you can modify the Kconfig to inhibit the
build (say make it dependent on a symbol that won't be turned on).

And then in a later patch, reenable the Kconfig. The idea here is to
keep 'git bisection working properly'.

Another way to make this work is to provide some scaffolding code in the
existing code so that it can build in another directory. And then
in another patch remove it.

>  drivers/xen/xenfs/super.c   |    3 +-
>  drivers/xen/xenfs/xenfs.h   |    1 -
>  8 files changed, 452 insertions(+), 403 deletions(-)
>  create mode 100644 drivers/xen/privcmd.c
>  create mode 100644 drivers/xen/privcmd.h
>  delete mode 100644 drivers/xen/xenfs/privcmd.c
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 5f7ff8e..eb7574c 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -86,6 +86,7 @@ config XEN_BACKEND
>  
>  config XENFS
>  	tristate "Xen filesystem"
> +	select XEN_PRIVCMD
>  	default y
>  	help
>  	  The xen filesystem provides a way for domains to share
> @@ -181,4 +182,10 @@ config XEN_PCIDEV_BACKEND
>  	  xen-pciback.hide=(03:00.0)(04:00.0)
>  
>  	  If in doubt, say m.
> +
> +config XEN_PRIVCMD
> +	tristate
> +	depends on XEN_DOM0

Would it be possible for HVM domains that have the backend drivers in
them (so blkback for example) to use these hypercalls? If so should this
XEN_DOM0 be perhaps changed to something else?

> +	default m
> +
>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 72bbb27..c35f65d 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -19,9 +19,11 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
>  obj-$(CONFIG_XEN_DOM0)			+= pci.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> +obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
>  
>  xen-evtchn-y				:= evtchn.o
>  xen-gntdev-y				:= gntdev.o
>  xen-gntalloc-y				:= gntalloc.o
> +xen-privcmd-y				:= privcmd.o
>  
>  xen-platform-pci-y			:= platform-pci.o
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> new file mode 100644
> index 0000000..863fbd0
> --- /dev/null
> +++ b/drivers/xen/privcmd.c
> @@ -0,0 +1,437 @@
> +/******************************************************************************
> + * privcmd.c
> + *
> + * Interface to privileged domain-0 commands.
> + *
> + * Copyright (c) 2002-2004, K A Fraser, B Dragovic
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/sched.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/errno.h>
> +#include <linux/mm.h>
> +#include <linux/mman.h>
> +#include <linux/uaccess.h>
> +#include <linux/swap.h>
> +#include <linux/highmem.h>
> +#include <linux/pagemap.h>
> +#include <linux/seq_file.h>
> +#include <linux/miscdevice.h>
> +
> +#include <asm/pgalloc.h>
> +#include <asm/pgtable.h>
> +#include <asm/tlb.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +
> +#include <xen/xen.h>
> +#include <xen/privcmd.h>
> +#include <xen/interface/xen.h>
> +#include <xen/features.h>
> +#include <xen/page.h>
> +#include <xen/xen-ops.h>
> +
> +#include "privcmd.h"
> +
> +MODULE_LICENSE("GPL");
> +
> +#ifndef HAVE_ARCH_PRIVCMD_MMAP
> +static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
> +#endif
> +
> +static long privcmd_ioctl_hypercall(void __user *udata)
> +{
> +	struct privcmd_hypercall hypercall;
> +	long ret;
> +
> +	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
> +		return -EFAULT;
> +
> +	ret = privcmd_call(hypercall.op,
> +			   hypercall.arg[0], hypercall.arg[1],
> +			   hypercall.arg[2], hypercall.arg[3],
> +			   hypercall.arg[4]);
> +
> +	return ret;
> +}
> +
> +static void free_page_list(struct list_head *pages)
> +{
> +	struct page *p, *n;
> +
> +	list_for_each_entry_safe(p, n, pages, lru)
> +		__free_page(p);
> +
> +	INIT_LIST_HEAD(pages);
> +}
> +
> +/*
> + * Given an array of items in userspace, return a list of pages
> + * containing the data.  If copying fails, either because of memory
> + * allocation failure or a problem reading user memory, return an
> + * error code; its up to the caller to dispose of any partial list.
> + */
> +static int gather_array(struct list_head *pagelist,
> +			unsigned nelem, size_t size,
> +			void __user *data)
> +{
> +	unsigned pageidx;
> +	void *pagedata;
> +	int ret;
> +
> +	if (size > PAGE_SIZE)
> +		return 0;
> +
> +	pageidx = PAGE_SIZE;
> +	pagedata = NULL;	/* quiet, gcc */
> +	while (nelem--) {
> +		if (pageidx > PAGE_SIZE-size) {
> +			struct page *page = alloc_page(GFP_KERNEL);
> +
> +			ret = -ENOMEM;
> +			if (page == NULL)
> +				goto fail;
> +
> +			pagedata = page_address(page);
> +
> +			list_add_tail(&page->lru, pagelist);
> +			pageidx = 0;
> +		}
> +
> +		ret = -EFAULT;
> +		if (copy_from_user(pagedata + pageidx, data, size))
> +			goto fail;
> +
> +		data += size;
> +		pageidx += size;
> +	}
> +
> +	ret = 0;
> +
> +fail:
> +	return ret;
> +}
> +
> +/*
> + * Call function "fn" on each element of the array fragmented
> + * over a list of pages.
> + */
> +static int traverse_pages(unsigned nelem, size_t size,
> +			  struct list_head *pos,
> +			  int (*fn)(void *data, void *state),
> +			  void *state)
> +{
> +	void *pagedata;
> +	unsigned pageidx;
> +	int ret = 0;
> +
> +	BUG_ON(size > PAGE_SIZE);
> +
> +	pageidx = PAGE_SIZE;
> +	pagedata = NULL;	/* hush, gcc */
> +
> +	while (nelem--) {
> +		if (pageidx > PAGE_SIZE-size) {
> +			struct page *page;
> +			pos = pos->next;
> +			page = list_entry(pos, struct page, lru);
> +			pagedata = page_address(page);
> +			pageidx = 0;
> +		}
> +
> +		ret = (*fn)(pagedata + pageidx, state);
> +		if (ret)
> +			break;
> +		pageidx += size;
> +	}
> +
> +	return ret;
> +}
> +
> +struct mmap_mfn_state {
> +	unsigned long va;
> +	struct vm_area_struct *vma;
> +	domid_t domain;
> +};
> +
> +static int mmap_mfn_range(void *data, void *state)
> +{
> +	struct privcmd_mmap_entry *msg = data;
> +	struct mmap_mfn_state *st = state;
> +	struct vm_area_struct *vma = st->vma;
> +	int rc;
> +
> +	/* Do not allow range to wrap the address space. */
> +	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
> +	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
> +		return -EINVAL;
> +
> +	/* Range chunks must be contiguous in va space. */
> +	if ((msg->va != st->va) ||
> +	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
> +		return -EINVAL;
> +
> +	rc = xen_remap_domain_mfn_range(vma,
> +					msg->va & PAGE_MASK,
> +					msg->mfn, msg->npages,
> +					vma->vm_page_prot,
> +					st->domain);
> +	if (rc < 0)
> +		return rc;
> +
> +	st->va += msg->npages << PAGE_SHIFT;
> +
> +	return 0;
> +}
> +
> +static long privcmd_ioctl_mmap(void __user *udata)
> +{
> +	struct privcmd_mmap mmapcmd;
> +	struct mm_struct *mm = current->mm;
> +	struct vm_area_struct *vma;
> +	int rc;
> +	LIST_HEAD(pagelist);
> +	struct mmap_mfn_state state;
> +
> +	if (!xen_initial_domain())
> +		return -EPERM;
> +
> +	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
> +		return -EFAULT;
> +
> +	rc = gather_array(&pagelist,
> +			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
> +			  mmapcmd.entry);
> +
> +	if (rc || list_empty(&pagelist))
> +		goto out;
> +
> +	down_write(&mm->mmap_sem);
> +
> +	{
> +		struct page *page = list_first_entry(&pagelist,
> +						     struct page, lru);
> +		struct privcmd_mmap_entry *msg = page_address(page);
> +
> +		vma = find_vma(mm, msg->va);
> +		rc = -EINVAL;
> +
> +		if (!vma || (msg->va != vma->vm_start) ||
> +		    !privcmd_enforce_singleshot_mapping(vma))
> +			goto out_up;
> +	}
> +
> +	state.va = vma->vm_start;
> +	state.vma = vma;
> +	state.domain = mmapcmd.dom;
> +
> +	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
> +			    &pagelist,
> +			    mmap_mfn_range, &state);
> +
> +
> +out_up:
> +	up_write(&mm->mmap_sem);
> +
> +out:
> +	free_page_list(&pagelist);
> +
> +	return rc;
> +}
> +
> +struct mmap_batch_state {
> +	domid_t domain;
> +	unsigned long va;
> +	struct vm_area_struct *vma;
> +	int err;
> +
> +	xen_pfn_t __user *user;
> +};
> +
> +static int mmap_batch_fn(void *data, void *state)
> +{
> +	xen_pfn_t *mfnp = data;
> +	struct mmap_batch_state *st = state;
> +
> +	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> +				       st->vma->vm_page_prot, st->domain) < 0) {
> +		*mfnp |= 0xf0000000U;
> +		st->err++;
> +	}
> +	st->va += PAGE_SIZE;
> +
> +	return 0;
> +}
> +
> +static int mmap_return_errors(void *data, void *state)
> +{
> +	xen_pfn_t *mfnp = data;
> +	struct mmap_batch_state *st = state;
> +
> +	return put_user(*mfnp, st->user++);
> +}
> +
> +static struct vm_operations_struct privcmd_vm_ops;
> +
> +static long privcmd_ioctl_mmap_batch(void __user *udata)
> +{
> +	int ret;
> +	struct privcmd_mmapbatch m;
> +	struct mm_struct *mm = current->mm;
> +	struct vm_area_struct *vma;
> +	unsigned long nr_pages;
> +	LIST_HEAD(pagelist);
> +	struct mmap_batch_state state;
> +
> +	if (!xen_initial_domain())
> +		return -EPERM;
> +
> +	if (copy_from_user(&m, udata, sizeof(m)))
> +		return -EFAULT;
> +
> +	nr_pages = m.num;
> +	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> +		return -EINVAL;
> +
> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> +			   m.arr);
> +
> +	if (ret || list_empty(&pagelist))
> +		goto out;
> +
> +	down_write(&mm->mmap_sem);
> +
> +	vma = find_vma(mm, m.addr);
> +	ret = -EINVAL;
> +	if (!vma ||
> +	    vma->vm_ops != &privcmd_vm_ops ||
> +	    (m.addr != vma->vm_start) ||
> +	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
> +	    !privcmd_enforce_singleshot_mapping(vma)) {
> +		up_write(&mm->mmap_sem);
> +		goto out;
> +	}
> +
> +	state.domain = m.dom;
> +	state.vma = vma;
> +	state.va = m.addr;
> +	state.err = 0;
> +
> +	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> +			     &pagelist, mmap_batch_fn, &state);
> +
> +	up_write(&mm->mmap_sem);
> +
> +	if (state.err > 0) {
> +		state.user = m.arr;
> +		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> +			       &pagelist,
> +			       mmap_return_errors, &state);
> +	}
> +
> +out:
> +	free_page_list(&pagelist);
> +
> +	return ret;
> +}
> +
> +static long privcmd_ioctl(struct file *file,
> +			  unsigned int cmd, unsigned long data)
> +{
> +	int ret = -ENOSYS;
> +	void __user *udata = (void __user *) data;
> +
> +	switch (cmd) {
> +	case IOCTL_PRIVCMD_HYPERCALL:
> +		ret = privcmd_ioctl_hypercall(udata);
> +		break;
> +
> +	case IOCTL_PRIVCMD_MMAP:
> +		ret = privcmd_ioctl_mmap(udata);
> +		break;
> +
> +	case IOCTL_PRIVCMD_MMAPBATCH:
> +		ret = privcmd_ioctl_mmap_batch(udata);
> +		break;
> +
> +	default:
> +		ret = -EINVAL;
> +		break;
> +	}
> +
> +	return ret;
> +}
> +
> +#ifndef HAVE_ARCH_PRIVCMD_MMAP
> +static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> +{
> +	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> +	       vma, vma->vm_start, vma->vm_end,
> +	       vmf->pgoff, vmf->virtual_address);
> +
> +	return VM_FAULT_SIGBUS;
> +}
> +
> +static struct vm_operations_struct privcmd_vm_ops = {
> +	.fault = privcmd_fault
> +};
> +
> +static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> +	/* Unsupported for auto-translate guests. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return -ENOSYS;
> +
> +	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
> +	 * how to recreate these mappings */
> +	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
> +	vma->vm_ops = &privcmd_vm_ops;
> +	vma->vm_private_data = NULL;
> +
> +	return 0;
> +}
> +
> +static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
> +{
> +	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> +}
> +#endif
> +
> +const struct file_operations xen_privcmd_fops = {
> +	.owner = THIS_MODULE,
> +	.unlocked_ioctl = privcmd_ioctl,
> +	.mmap = privcmd_mmap,
> +};
> +EXPORT_SYMBOL_GPL(xen_privcmd_fops);
> +
> +static struct miscdevice privcmd_dev = {
> +	.minor = MISC_DYNAMIC_MINOR,
> +	.name = "xen/privcmd",
> +	.fops = &xen_privcmd_fops,
> +};
> +
> +static int __init privcmd_init(void)
> +{
> +	int err;
> +
> +	if (!xen_domain())
> +		return -ENODEV;
> +
> +	err = misc_register(&privcmd_dev);
> +	if (err != 0) {
> +		printk(KERN_ERR "Could not register privcmd device\n");
> +		return err;
> +	}
> +	return 0;
> +}
> +
> +static void __exit privcmd_exit(void)
> +{
> +	misc_deregister(&privcmd_dev);
> +}
> +
> +module_init(privcmd_init);
> +module_exit(privcmd_exit);
> diff --git a/drivers/xen/privcmd.h b/drivers/xen/privcmd.h
> new file mode 100644
> index 0000000..14facae
> --- /dev/null
> +++ b/drivers/xen/privcmd.h
> @@ -0,0 +1,3 @@
> +#include <linux/fs.h>
> +
> +extern const struct file_operations xen_privcmd_fops;
> diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
> index 4fde944..5d45ff1 100644
> --- a/drivers/xen/xenfs/Makefile
> +++ b/drivers/xen/xenfs/Makefile
> @@ -1,4 +1,4 @@
>  obj-$(CONFIG_XENFS) += xenfs.o
>  
> -xenfs-y			  = super.o xenbus.o privcmd.o
> +xenfs-y			  = super.o xenbus.o
>  xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
> diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
> deleted file mode 100644
> index dbd3b16..0000000
> --- a/drivers/xen/xenfs/privcmd.c
> +++ /dev/null
> @@ -1,400 +0,0 @@
> -/******************************************************************************
> - * privcmd.c
> - *
> - * Interface to privileged domain-0 commands.
> - *
> - * Copyright (c) 2002-2004, K A Fraser, B Dragovic
> - */
> -
> -#include <linux/kernel.h>
> -#include <linux/sched.h>
> -#include <linux/slab.h>
> -#include <linux/string.h>
> -#include <linux/errno.h>
> -#include <linux/mm.h>
> -#include <linux/mman.h>
> -#include <linux/uaccess.h>
> -#include <linux/swap.h>
> -#include <linux/highmem.h>
> -#include <linux/pagemap.h>
> -#include <linux/seq_file.h>
> -
> -#include <asm/pgalloc.h>
> -#include <asm/pgtable.h>
> -#include <asm/tlb.h>
> -#include <asm/xen/hypervisor.h>
> -#include <asm/xen/hypercall.h>
> -
> -#include <xen/xen.h>
> -#include <xen/privcmd.h>
> -#include <xen/interface/xen.h>
> -#include <xen/features.h>
> -#include <xen/page.h>
> -#include <xen/xen-ops.h>
> -
> -#ifndef HAVE_ARCH_PRIVCMD_MMAP
> -static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
> -#endif
> -
> -static long privcmd_ioctl_hypercall(void __user *udata)
> -{
> -	struct privcmd_hypercall hypercall;
> -	long ret;
> -
> -	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
> -		return -EFAULT;
> -
> -	ret = privcmd_call(hypercall.op,
> -			   hypercall.arg[0], hypercall.arg[1],
> -			   hypercall.arg[2], hypercall.arg[3],
> -			   hypercall.arg[4]);
> -
> -	return ret;
> -}
> -
> -static void free_page_list(struct list_head *pages)
> -{
> -	struct page *p, *n;
> -
> -	list_for_each_entry_safe(p, n, pages, lru)
> -		__free_page(p);
> -
> -	INIT_LIST_HEAD(pages);
> -}
> -
> -/*
> - * Given an array of items in userspace, return a list of pages
> - * containing the data.  If copying fails, either because of memory
> - * allocation failure or a problem reading user memory, return an
> - * error code; its up to the caller to dispose of any partial list.
> - */
> -static int gather_array(struct list_head *pagelist,
> -			unsigned nelem, size_t size,
> -			void __user *data)
> -{
> -	unsigned pageidx;
> -	void *pagedata;
> -	int ret;
> -
> -	if (size > PAGE_SIZE)
> -		return 0;
> -
> -	pageidx = PAGE_SIZE;
> -	pagedata = NULL;	/* quiet, gcc */
> -	while (nelem--) {
> -		if (pageidx > PAGE_SIZE-size) {
> -			struct page *page = alloc_page(GFP_KERNEL);
> -
> -			ret = -ENOMEM;
> -			if (page == NULL)
> -				goto fail;
> -
> -			pagedata = page_address(page);
> -
> -			list_add_tail(&page->lru, pagelist);
> -			pageidx = 0;
> -		}
> -
> -		ret = -EFAULT;
> -		if (copy_from_user(pagedata + pageidx, data, size))
> -			goto fail;
> -
> -		data += size;
> -		pageidx += size;
> -	}
> -
> -	ret = 0;
> -
> -fail:
> -	return ret;
> -}
> -
> -/*
> - * Call function "fn" on each element of the array fragmented
> - * over a list of pages.
> - */
> -static int traverse_pages(unsigned nelem, size_t size,
> -			  struct list_head *pos,
> -			  int (*fn)(void *data, void *state),
> -			  void *state)
> -{
> -	void *pagedata;
> -	unsigned pageidx;
> -	int ret = 0;
> -
> -	BUG_ON(size > PAGE_SIZE);
> -
> -	pageidx = PAGE_SIZE;
> -	pagedata = NULL;	/* hush, gcc */
> -
> -	while (nelem--) {
> -		if (pageidx > PAGE_SIZE-size) {
> -			struct page *page;
> -			pos = pos->next;
> -			page = list_entry(pos, struct page, lru);
> -			pagedata = page_address(page);
> -			pageidx = 0;
> -		}
> -
> -		ret = (*fn)(pagedata + pageidx, state);
> -		if (ret)
> -			break;
> -		pageidx += size;
> -	}
> -
> -	return ret;
> -}
> -
> -struct mmap_mfn_state {
> -	unsigned long va;
> -	struct vm_area_struct *vma;
> -	domid_t domain;
> -};
> -
> -static int mmap_mfn_range(void *data, void *state)
> -{
> -	struct privcmd_mmap_entry *msg = data;
> -	struct mmap_mfn_state *st = state;
> -	struct vm_area_struct *vma = st->vma;
> -	int rc;
> -
> -	/* Do not allow range to wrap the address space. */
> -	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
> -	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
> -		return -EINVAL;
> -
> -	/* Range chunks must be contiguous in va space. */
> -	if ((msg->va != st->va) ||
> -	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
> -		return -EINVAL;
> -
> -	rc = xen_remap_domain_mfn_range(vma,
> -					msg->va & PAGE_MASK,
> -					msg->mfn, msg->npages,
> -					vma->vm_page_prot,
> -					st->domain);
> -	if (rc < 0)
> -		return rc;
> -
> -	st->va += msg->npages << PAGE_SHIFT;
> -
> -	return 0;
> -}
> -
> -static long privcmd_ioctl_mmap(void __user *udata)
> -{
> -	struct privcmd_mmap mmapcmd;
> -	struct mm_struct *mm = current->mm;
> -	struct vm_area_struct *vma;
> -	int rc;
> -	LIST_HEAD(pagelist);
> -	struct mmap_mfn_state state;
> -
> -	if (!xen_initial_domain())
> -		return -EPERM;
> -
> -	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
> -		return -EFAULT;
> -
> -	rc = gather_array(&pagelist,
> -			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
> -			  mmapcmd.entry);
> -
> -	if (rc || list_empty(&pagelist))
> -		goto out;
> -
> -	down_write(&mm->mmap_sem);
> -
> -	{
> -		struct page *page = list_first_entry(&pagelist,
> -						     struct page, lru);
> -		struct privcmd_mmap_entry *msg = page_address(page);
> -
> -		vma = find_vma(mm, msg->va);
> -		rc = -EINVAL;
> -
> -		if (!vma || (msg->va != vma->vm_start) ||
> -		    !privcmd_enforce_singleshot_mapping(vma))
> -			goto out_up;
> -	}
> -
> -	state.va = vma->vm_start;
> -	state.vma = vma;
> -	state.domain = mmapcmd.dom;
> -
> -	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
> -			    &pagelist,
> -			    mmap_mfn_range, &state);
> -
> -
> -out_up:
> -	up_write(&mm->mmap_sem);
> -
> -out:
> -	free_page_list(&pagelist);
> -
> -	return rc;
> -}
> -
> -struct mmap_batch_state {
> -	domid_t domain;
> -	unsigned long va;
> -	struct vm_area_struct *vma;
> -	int err;
> -
> -	xen_pfn_t __user *user;
> -};
> -
> -static int mmap_batch_fn(void *data, void *state)
> -{
> -	xen_pfn_t *mfnp = data;
> -	struct mmap_batch_state *st = state;
> -
> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> -				       st->vma->vm_page_prot, st->domain) < 0) {
> -		*mfnp |= 0xf0000000U;
> -		st->err++;
> -	}
> -	st->va += PAGE_SIZE;
> -
> -	return 0;
> -}
> -
> -static int mmap_return_errors(void *data, void *state)
> -{
> -	xen_pfn_t *mfnp = data;
> -	struct mmap_batch_state *st = state;
> -
> -	return put_user(*mfnp, st->user++);
> -}
> -
> -static struct vm_operations_struct privcmd_vm_ops;
> -
> -static long privcmd_ioctl_mmap_batch(void __user *udata)
> -{
> -	int ret;
> -	struct privcmd_mmapbatch m;
> -	struct mm_struct *mm = current->mm;
> -	struct vm_area_struct *vma;
> -	unsigned long nr_pages;
> -	LIST_HEAD(pagelist);
> -	struct mmap_batch_state state;
> -
> -	if (!xen_initial_domain())
> -		return -EPERM;
> -
> -	if (copy_from_user(&m, udata, sizeof(m)))
> -		return -EFAULT;
> -
> -	nr_pages = m.num;
> -	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> -		return -EINVAL;
> -
> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> -			   m.arr);
> -
> -	if (ret || list_empty(&pagelist))
> -		goto out;
> -
> -	down_write(&mm->mmap_sem);
> -
> -	vma = find_vma(mm, m.addr);
> -	ret = -EINVAL;
> -	if (!vma ||
> -	    vma->vm_ops != &privcmd_vm_ops ||
> -	    (m.addr != vma->vm_start) ||
> -	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
> -	    !privcmd_enforce_singleshot_mapping(vma)) {
> -		up_write(&mm->mmap_sem);
> -		goto out;
> -	}
> -
> -	state.domain = m.dom;
> -	state.vma = vma;
> -	state.va = m.addr;
> -	state.err = 0;
> -
> -	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> -			     &pagelist, mmap_batch_fn, &state);
> -
> -	up_write(&mm->mmap_sem);
> -
> -	if (state.err > 0) {
> -		state.user = m.arr;
> -		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> -			       &pagelist,
> -			       mmap_return_errors, &state);
> -	}
> -
> -out:
> -	free_page_list(&pagelist);
> -
> -	return ret;
> -}
> -
> -static long privcmd_ioctl(struct file *file,
> -			  unsigned int cmd, unsigned long data)
> -{
> -	int ret = -ENOSYS;
> -	void __user *udata = (void __user *) data;
> -
> -	switch (cmd) {
> -	case IOCTL_PRIVCMD_HYPERCALL:
> -		ret = privcmd_ioctl_hypercall(udata);
> -		break;
> -
> -	case IOCTL_PRIVCMD_MMAP:
> -		ret = privcmd_ioctl_mmap(udata);
> -		break;
> -
> -	case IOCTL_PRIVCMD_MMAPBATCH:
> -		ret = privcmd_ioctl_mmap_batch(udata);
> -		break;
> -
> -	default:
> -		ret = -EINVAL;
> -		break;
> -	}
> -
> -	return ret;
> -}
> -
> -#ifndef HAVE_ARCH_PRIVCMD_MMAP
> -static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> -{
> -	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> -	       vma, vma->vm_start, vma->vm_end,
> -	       vmf->pgoff, vmf->virtual_address);
> -
> -	return VM_FAULT_SIGBUS;
> -}
> -
> -static struct vm_operations_struct privcmd_vm_ops = {
> -	.fault = privcmd_fault
> -};
> -
> -static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
> -{
> -	/* Unsupported for auto-translate guests. */
> -	if (xen_feature(XENFEAT_auto_translated_physmap))
> -		return -ENOSYS;
> -
> -	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
> -	 * how to recreate these mappings */
> -	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
> -	vma->vm_ops = &privcmd_vm_ops;
> -	vma->vm_private_data = NULL;
> -
> -	return 0;
> -}
> -
> -static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
> -{
> -	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> -}
> -#endif
> -
> -const struct file_operations privcmd_file_ops = {
> -	.unlocked_ioctl = privcmd_ioctl,
> -	.mmap = privcmd_mmap,
> -};
> diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
> index 1aa3897..a55fbf9 100644
> --- a/drivers/xen/xenfs/super.c
> +++ b/drivers/xen/xenfs/super.c
> @@ -16,6 +16,7 @@
>  #include <xen/xen.h>
>  
>  #include "xenfs.h"
> +#include "../privcmd.h"
>  
>  #include <asm/xen/hypervisor.h>
>  
> @@ -84,7 +85,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
>  		[1] = {},
>  		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
>  		{ "capabilities", &capabilities_file_ops, S_IRUGO },
> -		{ "privcmd", &privcmd_file_ops, S_IRUSR|S_IWUSR },
> +		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
>  		{""},
>  	};
>  	int rc;
> diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
> index b68aa62..5056306 100644
> --- a/drivers/xen/xenfs/xenfs.h
> +++ b/drivers/xen/xenfs/xenfs.h
> @@ -2,7 +2,6 @@
>  #define _XENFS_XENBUS_H
>  
>  extern const struct file_operations xenbus_file_ops;
> -extern const struct file_operations privcmd_file_ops;
>  extern const struct file_operations xsd_kva_file_ops;
>  extern const struct file_operations xsd_port_file_ops;
>  
> -- 
> 1.7.7.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:23:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:23:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5qq-0001Mc-85; Mon, 28 Nov 2011 18:22:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV5qp-0001ML-6W
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:22:47 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322504527!3421513!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31481 invoked from network); 28 Nov 2011 18:22:09 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 18:22:09 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASIM5LF023309
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 13:22:05 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASIM55f023307;
	Mon, 28 Nov 2011 13:22:05 -0500
Date: Mon, 28 Nov 2011 14:22:05 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Bastian Blank <waldi@debian.org>
Message-ID: <20111128182205.GC21369@andromeda.dapyr.net>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322431628-21760-3-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 27, 2011 at 11:07:05PM +0100, Bastian Blank wrote:
> Access to arbitrary hypercalls is currently provided via xenfs. This
> adds a standard character device to handle this. The support in xenfs

Ok, what is the benefit of that? You mentioned in the prologue "about a
year ago I started", but you didn't provide any links to the
conversation. Could you include the details please?

> remains for backward compatibility and uses the device driver code.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/Kconfig         |    7 +
>  drivers/xen/Makefile        |    2 +
>  drivers/xen/privcmd.c       |  437 +++++++++++++++++++++++++++++++++++++++++++
>  drivers/xen/privcmd.h       |    3 +
>  drivers/xen/xenfs/Makefile  |    2 +-
>  drivers/xen/xenfs/privcmd.c |  400 ---------------------------------------

It looks like you are doing a move of the file. Can you use 'git mv'
instead please.

If it breaks compile build, you can modify the Kconfig to inhibit the
build (say make it dependent on a symbol that won't be turned on).

And then in a later patch, reenable the Kconfig. The idea here is to
keep 'git bisection working properly'.

Another way to make this work is to provide some scaffolding code in the
existing code so that it can build in another directory. And then
in another patch remove it.

>  drivers/xen/xenfs/super.c   |    3 +-
>  drivers/xen/xenfs/xenfs.h   |    1 -
>  8 files changed, 452 insertions(+), 403 deletions(-)
>  create mode 100644 drivers/xen/privcmd.c
>  create mode 100644 drivers/xen/privcmd.h
>  delete mode 100644 drivers/xen/xenfs/privcmd.c
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 5f7ff8e..eb7574c 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -86,6 +86,7 @@ config XEN_BACKEND
>  
>  config XENFS
>  	tristate "Xen filesystem"
> +	select XEN_PRIVCMD
>  	default y
>  	help
>  	  The xen filesystem provides a way for domains to share
> @@ -181,4 +182,10 @@ config XEN_PCIDEV_BACKEND
>  	  xen-pciback.hide=(03:00.0)(04:00.0)
>  
>  	  If in doubt, say m.
> +
> +config XEN_PRIVCMD
> +	tristate
> +	depends on XEN_DOM0

Would it be possible for HVM domains that have the backend drivers in
them (so blkback for example) to use these hypercalls? If so should this
XEN_DOM0 be perhaps changed to something else?

> +	default m
> +
>  endmenu
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 72bbb27..c35f65d 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -19,9 +19,11 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
>  obj-$(CONFIG_XEN_DOM0)			+= pci.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
> +obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
>  
>  xen-evtchn-y				:= evtchn.o
>  xen-gntdev-y				:= gntdev.o
>  xen-gntalloc-y				:= gntalloc.o
> +xen-privcmd-y				:= privcmd.o
>  
>  xen-platform-pci-y			:= platform-pci.o
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> new file mode 100644
> index 0000000..863fbd0
> --- /dev/null
> +++ b/drivers/xen/privcmd.c
> @@ -0,0 +1,437 @@
> +/******************************************************************************
> + * privcmd.c
> + *
> + * Interface to privileged domain-0 commands.
> + *
> + * Copyright (c) 2002-2004, K A Fraser, B Dragovic
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/sched.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/errno.h>
> +#include <linux/mm.h>
> +#include <linux/mman.h>
> +#include <linux/uaccess.h>
> +#include <linux/swap.h>
> +#include <linux/highmem.h>
> +#include <linux/pagemap.h>
> +#include <linux/seq_file.h>
> +#include <linux/miscdevice.h>
> +
> +#include <asm/pgalloc.h>
> +#include <asm/pgtable.h>
> +#include <asm/tlb.h>
> +#include <asm/xen/hypervisor.h>
> +#include <asm/xen/hypercall.h>
> +
> +#include <xen/xen.h>
> +#include <xen/privcmd.h>
> +#include <xen/interface/xen.h>
> +#include <xen/features.h>
> +#include <xen/page.h>
> +#include <xen/xen-ops.h>
> +
> +#include "privcmd.h"
> +
> +MODULE_LICENSE("GPL");
> +
> +#ifndef HAVE_ARCH_PRIVCMD_MMAP
> +static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
> +#endif
> +
> +static long privcmd_ioctl_hypercall(void __user *udata)
> +{
> +	struct privcmd_hypercall hypercall;
> +	long ret;
> +
> +	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
> +		return -EFAULT;
> +
> +	ret = privcmd_call(hypercall.op,
> +			   hypercall.arg[0], hypercall.arg[1],
> +			   hypercall.arg[2], hypercall.arg[3],
> +			   hypercall.arg[4]);
> +
> +	return ret;
> +}
> +
> +static void free_page_list(struct list_head *pages)
> +{
> +	struct page *p, *n;
> +
> +	list_for_each_entry_safe(p, n, pages, lru)
> +		__free_page(p);
> +
> +	INIT_LIST_HEAD(pages);
> +}
> +
> +/*
> + * Given an array of items in userspace, return a list of pages
> + * containing the data.  If copying fails, either because of memory
> + * allocation failure or a problem reading user memory, return an
> + * error code; its up to the caller to dispose of any partial list.
> + */
> +static int gather_array(struct list_head *pagelist,
> +			unsigned nelem, size_t size,
> +			void __user *data)
> +{
> +	unsigned pageidx;
> +	void *pagedata;
> +	int ret;
> +
> +	if (size > PAGE_SIZE)
> +		return 0;
> +
> +	pageidx = PAGE_SIZE;
> +	pagedata = NULL;	/* quiet, gcc */
> +	while (nelem--) {
> +		if (pageidx > PAGE_SIZE-size) {
> +			struct page *page = alloc_page(GFP_KERNEL);
> +
> +			ret = -ENOMEM;
> +			if (page == NULL)
> +				goto fail;
> +
> +			pagedata = page_address(page);
> +
> +			list_add_tail(&page->lru, pagelist);
> +			pageidx = 0;
> +		}
> +
> +		ret = -EFAULT;
> +		if (copy_from_user(pagedata + pageidx, data, size))
> +			goto fail;
> +
> +		data += size;
> +		pageidx += size;
> +	}
> +
> +	ret = 0;
> +
> +fail:
> +	return ret;
> +}
> +
> +/*
> + * Call function "fn" on each element of the array fragmented
> + * over a list of pages.
> + */
> +static int traverse_pages(unsigned nelem, size_t size,
> +			  struct list_head *pos,
> +			  int (*fn)(void *data, void *state),
> +			  void *state)
> +{
> +	void *pagedata;
> +	unsigned pageidx;
> +	int ret = 0;
> +
> +	BUG_ON(size > PAGE_SIZE);
> +
> +	pageidx = PAGE_SIZE;
> +	pagedata = NULL;	/* hush, gcc */
> +
> +	while (nelem--) {
> +		if (pageidx > PAGE_SIZE-size) {
> +			struct page *page;
> +			pos = pos->next;
> +			page = list_entry(pos, struct page, lru);
> +			pagedata = page_address(page);
> +			pageidx = 0;
> +		}
> +
> +		ret = (*fn)(pagedata + pageidx, state);
> +		if (ret)
> +			break;
> +		pageidx += size;
> +	}
> +
> +	return ret;
> +}
> +
> +struct mmap_mfn_state {
> +	unsigned long va;
> +	struct vm_area_struct *vma;
> +	domid_t domain;
> +};
> +
> +static int mmap_mfn_range(void *data, void *state)
> +{
> +	struct privcmd_mmap_entry *msg = data;
> +	struct mmap_mfn_state *st = state;
> +	struct vm_area_struct *vma = st->vma;
> +	int rc;
> +
> +	/* Do not allow range to wrap the address space. */
> +	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
> +	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
> +		return -EINVAL;
> +
> +	/* Range chunks must be contiguous in va space. */
> +	if ((msg->va != st->va) ||
> +	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
> +		return -EINVAL;
> +
> +	rc = xen_remap_domain_mfn_range(vma,
> +					msg->va & PAGE_MASK,
> +					msg->mfn, msg->npages,
> +					vma->vm_page_prot,
> +					st->domain);
> +	if (rc < 0)
> +		return rc;
> +
> +	st->va += msg->npages << PAGE_SHIFT;
> +
> +	return 0;
> +}
> +
> +static long privcmd_ioctl_mmap(void __user *udata)
> +{
> +	struct privcmd_mmap mmapcmd;
> +	struct mm_struct *mm = current->mm;
> +	struct vm_area_struct *vma;
> +	int rc;
> +	LIST_HEAD(pagelist);
> +	struct mmap_mfn_state state;
> +
> +	if (!xen_initial_domain())
> +		return -EPERM;
> +
> +	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
> +		return -EFAULT;
> +
> +	rc = gather_array(&pagelist,
> +			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
> +			  mmapcmd.entry);
> +
> +	if (rc || list_empty(&pagelist))
> +		goto out;
> +
> +	down_write(&mm->mmap_sem);
> +
> +	{
> +		struct page *page = list_first_entry(&pagelist,
> +						     struct page, lru);
> +		struct privcmd_mmap_entry *msg = page_address(page);
> +
> +		vma = find_vma(mm, msg->va);
> +		rc = -EINVAL;
> +
> +		if (!vma || (msg->va != vma->vm_start) ||
> +		    !privcmd_enforce_singleshot_mapping(vma))
> +			goto out_up;
> +	}
> +
> +	state.va = vma->vm_start;
> +	state.vma = vma;
> +	state.domain = mmapcmd.dom;
> +
> +	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
> +			    &pagelist,
> +			    mmap_mfn_range, &state);
> +
> +
> +out_up:
> +	up_write(&mm->mmap_sem);
> +
> +out:
> +	free_page_list(&pagelist);
> +
> +	return rc;
> +}
> +
> +struct mmap_batch_state {
> +	domid_t domain;
> +	unsigned long va;
> +	struct vm_area_struct *vma;
> +	int err;
> +
> +	xen_pfn_t __user *user;
> +};
> +
> +static int mmap_batch_fn(void *data, void *state)
> +{
> +	xen_pfn_t *mfnp = data;
> +	struct mmap_batch_state *st = state;
> +
> +	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> +				       st->vma->vm_page_prot, st->domain) < 0) {
> +		*mfnp |= 0xf0000000U;
> +		st->err++;
> +	}
> +	st->va += PAGE_SIZE;
> +
> +	return 0;
> +}
> +
> +static int mmap_return_errors(void *data, void *state)
> +{
> +	xen_pfn_t *mfnp = data;
> +	struct mmap_batch_state *st = state;
> +
> +	return put_user(*mfnp, st->user++);
> +}
> +
> +static struct vm_operations_struct privcmd_vm_ops;
> +
> +static long privcmd_ioctl_mmap_batch(void __user *udata)
> +{
> +	int ret;
> +	struct privcmd_mmapbatch m;
> +	struct mm_struct *mm = current->mm;
> +	struct vm_area_struct *vma;
> +	unsigned long nr_pages;
> +	LIST_HEAD(pagelist);
> +	struct mmap_batch_state state;
> +
> +	if (!xen_initial_domain())
> +		return -EPERM;
> +
> +	if (copy_from_user(&m, udata, sizeof(m)))
> +		return -EFAULT;
> +
> +	nr_pages = m.num;
> +	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> +		return -EINVAL;
> +
> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> +			   m.arr);
> +
> +	if (ret || list_empty(&pagelist))
> +		goto out;
> +
> +	down_write(&mm->mmap_sem);
> +
> +	vma = find_vma(mm, m.addr);
> +	ret = -EINVAL;
> +	if (!vma ||
> +	    vma->vm_ops != &privcmd_vm_ops ||
> +	    (m.addr != vma->vm_start) ||
> +	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
> +	    !privcmd_enforce_singleshot_mapping(vma)) {
> +		up_write(&mm->mmap_sem);
> +		goto out;
> +	}
> +
> +	state.domain = m.dom;
> +	state.vma = vma;
> +	state.va = m.addr;
> +	state.err = 0;
> +
> +	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> +			     &pagelist, mmap_batch_fn, &state);
> +
> +	up_write(&mm->mmap_sem);
> +
> +	if (state.err > 0) {
> +		state.user = m.arr;
> +		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> +			       &pagelist,
> +			       mmap_return_errors, &state);
> +	}
> +
> +out:
> +	free_page_list(&pagelist);
> +
> +	return ret;
> +}
> +
> +static long privcmd_ioctl(struct file *file,
> +			  unsigned int cmd, unsigned long data)
> +{
> +	int ret = -ENOSYS;
> +	void __user *udata = (void __user *) data;
> +
> +	switch (cmd) {
> +	case IOCTL_PRIVCMD_HYPERCALL:
> +		ret = privcmd_ioctl_hypercall(udata);
> +		break;
> +
> +	case IOCTL_PRIVCMD_MMAP:
> +		ret = privcmd_ioctl_mmap(udata);
> +		break;
> +
> +	case IOCTL_PRIVCMD_MMAPBATCH:
> +		ret = privcmd_ioctl_mmap_batch(udata);
> +		break;
> +
> +	default:
> +		ret = -EINVAL;
> +		break;
> +	}
> +
> +	return ret;
> +}
> +
> +#ifndef HAVE_ARCH_PRIVCMD_MMAP
> +static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> +{
> +	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> +	       vma, vma->vm_start, vma->vm_end,
> +	       vmf->pgoff, vmf->virtual_address);
> +
> +	return VM_FAULT_SIGBUS;
> +}
> +
> +static struct vm_operations_struct privcmd_vm_ops = {
> +	.fault = privcmd_fault
> +};
> +
> +static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> +	/* Unsupported for auto-translate guests. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return -ENOSYS;
> +
> +	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
> +	 * how to recreate these mappings */
> +	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
> +	vma->vm_ops = &privcmd_vm_ops;
> +	vma->vm_private_data = NULL;
> +
> +	return 0;
> +}
> +
> +static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
> +{
> +	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> +}
> +#endif
> +
> +const struct file_operations xen_privcmd_fops = {
> +	.owner = THIS_MODULE,
> +	.unlocked_ioctl = privcmd_ioctl,
> +	.mmap = privcmd_mmap,
> +};
> +EXPORT_SYMBOL_GPL(xen_privcmd_fops);
> +
> +static struct miscdevice privcmd_dev = {
> +	.minor = MISC_DYNAMIC_MINOR,
> +	.name = "xen/privcmd",
> +	.fops = &xen_privcmd_fops,
> +};
> +
> +static int __init privcmd_init(void)
> +{
> +	int err;
> +
> +	if (!xen_domain())
> +		return -ENODEV;
> +
> +	err = misc_register(&privcmd_dev);
> +	if (err != 0) {
> +		printk(KERN_ERR "Could not register privcmd device\n");
> +		return err;
> +	}
> +	return 0;
> +}
> +
> +static void __exit privcmd_exit(void)
> +{
> +	misc_deregister(&privcmd_dev);
> +}
> +
> +module_init(privcmd_init);
> +module_exit(privcmd_exit);
> diff --git a/drivers/xen/privcmd.h b/drivers/xen/privcmd.h
> new file mode 100644
> index 0000000..14facae
> --- /dev/null
> +++ b/drivers/xen/privcmd.h
> @@ -0,0 +1,3 @@
> +#include <linux/fs.h>
> +
> +extern const struct file_operations xen_privcmd_fops;
> diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
> index 4fde944..5d45ff1 100644
> --- a/drivers/xen/xenfs/Makefile
> +++ b/drivers/xen/xenfs/Makefile
> @@ -1,4 +1,4 @@
>  obj-$(CONFIG_XENFS) += xenfs.o
>  
> -xenfs-y			  = super.o xenbus.o privcmd.o
> +xenfs-y			  = super.o xenbus.o
>  xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
> diff --git a/drivers/xen/xenfs/privcmd.c b/drivers/xen/xenfs/privcmd.c
> deleted file mode 100644
> index dbd3b16..0000000
> --- a/drivers/xen/xenfs/privcmd.c
> +++ /dev/null
> @@ -1,400 +0,0 @@
> -/******************************************************************************
> - * privcmd.c
> - *
> - * Interface to privileged domain-0 commands.
> - *
> - * Copyright (c) 2002-2004, K A Fraser, B Dragovic
> - */
> -
> -#include <linux/kernel.h>
> -#include <linux/sched.h>
> -#include <linux/slab.h>
> -#include <linux/string.h>
> -#include <linux/errno.h>
> -#include <linux/mm.h>
> -#include <linux/mman.h>
> -#include <linux/uaccess.h>
> -#include <linux/swap.h>
> -#include <linux/highmem.h>
> -#include <linux/pagemap.h>
> -#include <linux/seq_file.h>
> -
> -#include <asm/pgalloc.h>
> -#include <asm/pgtable.h>
> -#include <asm/tlb.h>
> -#include <asm/xen/hypervisor.h>
> -#include <asm/xen/hypercall.h>
> -
> -#include <xen/xen.h>
> -#include <xen/privcmd.h>
> -#include <xen/interface/xen.h>
> -#include <xen/features.h>
> -#include <xen/page.h>
> -#include <xen/xen-ops.h>
> -
> -#ifndef HAVE_ARCH_PRIVCMD_MMAP
> -static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
> -#endif
> -
> -static long privcmd_ioctl_hypercall(void __user *udata)
> -{
> -	struct privcmd_hypercall hypercall;
> -	long ret;
> -
> -	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
> -		return -EFAULT;
> -
> -	ret = privcmd_call(hypercall.op,
> -			   hypercall.arg[0], hypercall.arg[1],
> -			   hypercall.arg[2], hypercall.arg[3],
> -			   hypercall.arg[4]);
> -
> -	return ret;
> -}
> -
> -static void free_page_list(struct list_head *pages)
> -{
> -	struct page *p, *n;
> -
> -	list_for_each_entry_safe(p, n, pages, lru)
> -		__free_page(p);
> -
> -	INIT_LIST_HEAD(pages);
> -}
> -
> -/*
> - * Given an array of items in userspace, return a list of pages
> - * containing the data.  If copying fails, either because of memory
> - * allocation failure or a problem reading user memory, return an
> - * error code; its up to the caller to dispose of any partial list.
> - */
> -static int gather_array(struct list_head *pagelist,
> -			unsigned nelem, size_t size,
> -			void __user *data)
> -{
> -	unsigned pageidx;
> -	void *pagedata;
> -	int ret;
> -
> -	if (size > PAGE_SIZE)
> -		return 0;
> -
> -	pageidx = PAGE_SIZE;
> -	pagedata = NULL;	/* quiet, gcc */
> -	while (nelem--) {
> -		if (pageidx > PAGE_SIZE-size) {
> -			struct page *page = alloc_page(GFP_KERNEL);
> -
> -			ret = -ENOMEM;
> -			if (page == NULL)
> -				goto fail;
> -
> -			pagedata = page_address(page);
> -
> -			list_add_tail(&page->lru, pagelist);
> -			pageidx = 0;
> -		}
> -
> -		ret = -EFAULT;
> -		if (copy_from_user(pagedata + pageidx, data, size))
> -			goto fail;
> -
> -		data += size;
> -		pageidx += size;
> -	}
> -
> -	ret = 0;
> -
> -fail:
> -	return ret;
> -}
> -
> -/*
> - * Call function "fn" on each element of the array fragmented
> - * over a list of pages.
> - */
> -static int traverse_pages(unsigned nelem, size_t size,
> -			  struct list_head *pos,
> -			  int (*fn)(void *data, void *state),
> -			  void *state)
> -{
> -	void *pagedata;
> -	unsigned pageidx;
> -	int ret = 0;
> -
> -	BUG_ON(size > PAGE_SIZE);
> -
> -	pageidx = PAGE_SIZE;
> -	pagedata = NULL;	/* hush, gcc */
> -
> -	while (nelem--) {
> -		if (pageidx > PAGE_SIZE-size) {
> -			struct page *page;
> -			pos = pos->next;
> -			page = list_entry(pos, struct page, lru);
> -			pagedata = page_address(page);
> -			pageidx = 0;
> -		}
> -
> -		ret = (*fn)(pagedata + pageidx, state);
> -		if (ret)
> -			break;
> -		pageidx += size;
> -	}
> -
> -	return ret;
> -}
> -
> -struct mmap_mfn_state {
> -	unsigned long va;
> -	struct vm_area_struct *vma;
> -	domid_t domain;
> -};
> -
> -static int mmap_mfn_range(void *data, void *state)
> -{
> -	struct privcmd_mmap_entry *msg = data;
> -	struct mmap_mfn_state *st = state;
> -	struct vm_area_struct *vma = st->vma;
> -	int rc;
> -
> -	/* Do not allow range to wrap the address space. */
> -	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
> -	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
> -		return -EINVAL;
> -
> -	/* Range chunks must be contiguous in va space. */
> -	if ((msg->va != st->va) ||
> -	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
> -		return -EINVAL;
> -
> -	rc = xen_remap_domain_mfn_range(vma,
> -					msg->va & PAGE_MASK,
> -					msg->mfn, msg->npages,
> -					vma->vm_page_prot,
> -					st->domain);
> -	if (rc < 0)
> -		return rc;
> -
> -	st->va += msg->npages << PAGE_SHIFT;
> -
> -	return 0;
> -}
> -
> -static long privcmd_ioctl_mmap(void __user *udata)
> -{
> -	struct privcmd_mmap mmapcmd;
> -	struct mm_struct *mm = current->mm;
> -	struct vm_area_struct *vma;
> -	int rc;
> -	LIST_HEAD(pagelist);
> -	struct mmap_mfn_state state;
> -
> -	if (!xen_initial_domain())
> -		return -EPERM;
> -
> -	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
> -		return -EFAULT;
> -
> -	rc = gather_array(&pagelist,
> -			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
> -			  mmapcmd.entry);
> -
> -	if (rc || list_empty(&pagelist))
> -		goto out;
> -
> -	down_write(&mm->mmap_sem);
> -
> -	{
> -		struct page *page = list_first_entry(&pagelist,
> -						     struct page, lru);
> -		struct privcmd_mmap_entry *msg = page_address(page);
> -
> -		vma = find_vma(mm, msg->va);
> -		rc = -EINVAL;
> -
> -		if (!vma || (msg->va != vma->vm_start) ||
> -		    !privcmd_enforce_singleshot_mapping(vma))
> -			goto out_up;
> -	}
> -
> -	state.va = vma->vm_start;
> -	state.vma = vma;
> -	state.domain = mmapcmd.dom;
> -
> -	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
> -			    &pagelist,
> -			    mmap_mfn_range, &state);
> -
> -
> -out_up:
> -	up_write(&mm->mmap_sem);
> -
> -out:
> -	free_page_list(&pagelist);
> -
> -	return rc;
> -}
> -
> -struct mmap_batch_state {
> -	domid_t domain;
> -	unsigned long va;
> -	struct vm_area_struct *vma;
> -	int err;
> -
> -	xen_pfn_t __user *user;
> -};
> -
> -static int mmap_batch_fn(void *data, void *state)
> -{
> -	xen_pfn_t *mfnp = data;
> -	struct mmap_batch_state *st = state;
> -
> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> -				       st->vma->vm_page_prot, st->domain) < 0) {
> -		*mfnp |= 0xf0000000U;
> -		st->err++;
> -	}
> -	st->va += PAGE_SIZE;
> -
> -	return 0;
> -}
> -
> -static int mmap_return_errors(void *data, void *state)
> -{
> -	xen_pfn_t *mfnp = data;
> -	struct mmap_batch_state *st = state;
> -
> -	return put_user(*mfnp, st->user++);
> -}
> -
> -static struct vm_operations_struct privcmd_vm_ops;
> -
> -static long privcmd_ioctl_mmap_batch(void __user *udata)
> -{
> -	int ret;
> -	struct privcmd_mmapbatch m;
> -	struct mm_struct *mm = current->mm;
> -	struct vm_area_struct *vma;
> -	unsigned long nr_pages;
> -	LIST_HEAD(pagelist);
> -	struct mmap_batch_state state;
> -
> -	if (!xen_initial_domain())
> -		return -EPERM;
> -
> -	if (copy_from_user(&m, udata, sizeof(m)))
> -		return -EFAULT;
> -
> -	nr_pages = m.num;
> -	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> -		return -EINVAL;
> -
> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> -			   m.arr);
> -
> -	if (ret || list_empty(&pagelist))
> -		goto out;
> -
> -	down_write(&mm->mmap_sem);
> -
> -	vma = find_vma(mm, m.addr);
> -	ret = -EINVAL;
> -	if (!vma ||
> -	    vma->vm_ops != &privcmd_vm_ops ||
> -	    (m.addr != vma->vm_start) ||
> -	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
> -	    !privcmd_enforce_singleshot_mapping(vma)) {
> -		up_write(&mm->mmap_sem);
> -		goto out;
> -	}
> -
> -	state.domain = m.dom;
> -	state.vma = vma;
> -	state.va = m.addr;
> -	state.err = 0;
> -
> -	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> -			     &pagelist, mmap_batch_fn, &state);
> -
> -	up_write(&mm->mmap_sem);
> -
> -	if (state.err > 0) {
> -		state.user = m.arr;
> -		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> -			       &pagelist,
> -			       mmap_return_errors, &state);
> -	}
> -
> -out:
> -	free_page_list(&pagelist);
> -
> -	return ret;
> -}
> -
> -static long privcmd_ioctl(struct file *file,
> -			  unsigned int cmd, unsigned long data)
> -{
> -	int ret = -ENOSYS;
> -	void __user *udata = (void __user *) data;
> -
> -	switch (cmd) {
> -	case IOCTL_PRIVCMD_HYPERCALL:
> -		ret = privcmd_ioctl_hypercall(udata);
> -		break;
> -
> -	case IOCTL_PRIVCMD_MMAP:
> -		ret = privcmd_ioctl_mmap(udata);
> -		break;
> -
> -	case IOCTL_PRIVCMD_MMAPBATCH:
> -		ret = privcmd_ioctl_mmap_batch(udata);
> -		break;
> -
> -	default:
> -		ret = -EINVAL;
> -		break;
> -	}
> -
> -	return ret;
> -}
> -
> -#ifndef HAVE_ARCH_PRIVCMD_MMAP
> -static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> -{
> -	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
> -	       vma, vma->vm_start, vma->vm_end,
> -	       vmf->pgoff, vmf->virtual_address);
> -
> -	return VM_FAULT_SIGBUS;
> -}
> -
> -static struct vm_operations_struct privcmd_vm_ops = {
> -	.fault = privcmd_fault
> -};
> -
> -static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
> -{
> -	/* Unsupported for auto-translate guests. */
> -	if (xen_feature(XENFEAT_auto_translated_physmap))
> -		return -ENOSYS;
> -
> -	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
> -	 * how to recreate these mappings */
> -	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
> -	vma->vm_ops = &privcmd_vm_ops;
> -	vma->vm_private_data = NULL;
> -
> -	return 0;
> -}
> -
> -static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
> -{
> -	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
> -}
> -#endif
> -
> -const struct file_operations privcmd_file_ops = {
> -	.unlocked_ioctl = privcmd_ioctl,
> -	.mmap = privcmd_mmap,
> -};
> diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
> index 1aa3897..a55fbf9 100644
> --- a/drivers/xen/xenfs/super.c
> +++ b/drivers/xen/xenfs/super.c
> @@ -16,6 +16,7 @@
>  #include <xen/xen.h>
>  
>  #include "xenfs.h"
> +#include "../privcmd.h"
>  
>  #include <asm/xen/hypervisor.h>
>  
> @@ -84,7 +85,7 @@ static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
>  		[1] = {},
>  		{ "xenbus", &xenbus_file_ops, S_IRUSR|S_IWUSR },
>  		{ "capabilities", &capabilities_file_ops, S_IRUGO },
> -		{ "privcmd", &privcmd_file_ops, S_IRUSR|S_IWUSR },
> +		{ "privcmd", &xen_privcmd_fops, S_IRUSR|S_IWUSR },
>  		{""},
>  	};
>  	int rc;
> diff --git a/drivers/xen/xenfs/xenfs.h b/drivers/xen/xenfs/xenfs.h
> index b68aa62..5056306 100644
> --- a/drivers/xen/xenfs/xenfs.h
> +++ b/drivers/xen/xenfs/xenfs.h
> @@ -2,7 +2,6 @@
>  #define _XENFS_XENBUS_H
>  
>  extern const struct file_operations xenbus_file_ops;
> -extern const struct file_operations privcmd_file_ops;
>  extern const struct file_operations xsd_kva_file_ops;
>  extern const struct file_operations xsd_port_file_ops;
>  
> -- 
> 1.7.7.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:24:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5sW-0001Ur-Vj; Mon, 28 Nov 2011 18:24:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV5sV-0001UO-Aq
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:24:31 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322504634!6705538!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30875 invoked from network); 28 Nov 2011 18:23:55 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 18:23:55 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 533E55415A; Mon, 28 Nov 2011 19:23:53 +0100 (CET)
Date: Mon, 28 Nov 2011 19:23:53 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111128182353.GB6828@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
	<1322497613.20646.19.camel@zakaz.uk.xensource.com>
	<20111128173954.GA6828@wavehammer.waldi.eu.org>
	<1322503221.11846.29.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322503221.11846.29.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 06:00:21PM +0000, Ian Campbell wrote:
> On Mon, 2011-11-28 at 17:39 +0000, Bastian Blank wrote:
> > On Mon, Nov 28, 2011 at 04:26:53PM +0000, Ian Campbell wrote:
> > > The main reason would be to avoid the select since selecting on user
> > > visible symbols is a recipe for confusion and is generally advised
> > > against.
> > Right. It is just the easiest solution.
> XENFS could depend on XEN_PRIVCMD and whatever else it needs?

This makes sure the module is built. But it does not make sure it is
also loaded.

Bastian

-- 
Another dream that failed.  There's nothing sadder.
		-- Kirk, "This side of Paradise", stardate 3417.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:24:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV5sW-0001Ur-Vj; Mon, 28 Nov 2011 18:24:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV5sV-0001UO-Aq
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:24:31 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322504634!6705538!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30875 invoked from network); 28 Nov 2011 18:23:55 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 18:23:55 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 533E55415A; Mon, 28 Nov 2011 19:23:53 +0100 (CET)
Date: Mon, 28 Nov 2011 19:23:53 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111128182353.GB6828@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
	<1322497613.20646.19.camel@zakaz.uk.xensource.com>
	<20111128173954.GA6828@wavehammer.waldi.eu.org>
	<1322503221.11846.29.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322503221.11846.29.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 06:00:21PM +0000, Ian Campbell wrote:
> On Mon, 2011-11-28 at 17:39 +0000, Bastian Blank wrote:
> > On Mon, Nov 28, 2011 at 04:26:53PM +0000, Ian Campbell wrote:
> > > The main reason would be to avoid the select since selecting on user
> > > visible symbols is a recipe for confusion and is generally advised
> > > against.
> > Right. It is just the easiest solution.
> XENFS could depend on XEN_PRIVCMD and whatever else it needs?

This makes sure the module is built. But it does not make sure it is
also loaded.

Bastian

-- 
Another dream that failed.  There's nothing sadder.
		-- Kirk, "This side of Paradise", stardate 3417.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:38:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:38:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV65f-00028t-4d; Mon, 28 Nov 2011 18:38:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV65d-00028Q-Nd
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:38:06 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322505446!3401461!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23933 invoked from network); 28 Nov 2011 18:37:28 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 18:37:28 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASIbNg5023988
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 13:37:23 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASIbNX7023986;
	Mon, 28 Nov 2011 13:37:23 -0500
Date: Mon, 28 Nov 2011 14:37:23 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Bastian Blank <waldi@debian.org>, dgdegra@tycho.nsa.gov
Message-ID: <20111128183723.GD21369@andromeda.dapyr.net>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-6-git-send-email-waldi@debian.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322431628-21760-6-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/5] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 27, 2011 at 11:07:08PM +0100, Bastian Blank wrote:
> Access for xenstored to the event channel and pre-allocated ring is
> managed via xenfs.  This adds its own device driver featuring mmap for
> the ring and an ioctl for the event channel.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/xenbus/Makefile             |    1 +
>  drivers/xen/xenbus/xenbus_dev_backend.c |   79 +++++++++++++++++++++++++++++++
>  include/xen/xenbus_dev.h                |   41 ++++++++++++++++
>  3 files changed, 121 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.c
>  create mode 100644 include/xen/xenbus_dev.h
> 
> diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
> index a2ea363..7e1aa85 100644
> --- a/drivers/xen/xenbus/Makefile
> +++ b/drivers/xen/xenbus/Makefile
> @@ -10,4 +10,5 @@ xenbus-objs += xenbus_probe.o
>  xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
>  xenbus-objs += $(xenbus-be-objs-y)
>  
> +obj-$(CONFIG_XEN_DOM0) += xenbus_dev_backend.o

I think this needs to depend on XEN_BACKEND ?

You could have a dom0 without any backends .. (Which is one of the goals
of disegragated device driver domains).

>  obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
> new file mode 100644
> index 0000000..5d77cee
> --- /dev/null
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.c
> @@ -0,0 +1,79 @@
> +#include <linux/slab.h>
> +#include <linux/types.h>
> +#include <linux/mm.h>
> +#include <linux/fs.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +
> +#include <xen/page.h>
> +#include <xen/xenbus_dev.h>
> +
> +#include "xenbus_comms.h"
> +
> +MODULE_LICENSE("GPL");
> +
> +static long xenbusd_ioctl(struct file *file, unsigned int cmd, unsigned long data)
> +{
> +	if (!capable(CAP_SYS_ADMIN))
> +		return -EACCES;
> +
> +	switch (cmd) {
> +		case IOCTL_XENBUSD_EVTCHN:
> +			if (xen_store_evtchn > 0)
> +				return xen_store_evtchn;
> +			return -EINVAL;

Not -ENODEV? After all, the command arguments were OK, it is just that
the eventchannel has not been set.

> +
> +		default:
> +			return -ENOTTY;
> +	}
> +}
> +
> +static int xenbusd_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> +	size_t size = vma->vm_end - vma->vm_start;
> +
> +	if (!capable(CAP_SYS_ADMIN))
> +		return -EACCES;
> +
> +	if ((size > PAGE_SIZE) || (vma->vm_pgoff != 0))
> +		return -EINVAL;
> +
> +	if (remap_pfn_range(vma, vma->vm_start,
> +			    virt_to_pfn(xen_store_interface),
> +			    size, vma->vm_page_prot))
> +		return -EAGAIN;
> +
> +	return 0;
> +}
> +
> +const struct file_operations xenbusd_fops = {
> +	.mmap = xenbusd_mmap,
> +	.unlocked_ioctl = xenbusd_ioctl,
> +};
> +
> +static struct miscdevice xenbusd_dev = {
> +	.minor = MISC_DYNAMIC_MINOR,
> +	.name = "xen/xenbusd",
> +	.fops = &xenbusd_fops,
> +};
> +
> +static int __init xenbusd_init(void)
> +{
> +	int err;
> +
> +	if (!xen_initial_domain())

With the disgregated domains (and the patches that Daniel posted), I
think this needs to relax a bit. Perhaps just make it 'xen_domain'?

Lets CC him here.
> +		return -ENODEV;
> +
> +	err = misc_register(&xenbusd_dev);
> +	if (err)
> +		printk(KERN_ERR "Could not register xenbus device\n");
> +	return err;
> +}
> +
> +static void __exit xenbusd_exit(void)
> +{
> +	misc_deregister(&xenbusd_dev);
> +}
> +
> +module_init(xenbusd_init);
> +module_exit(xenbusd_exit);
> diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
> new file mode 100644
> index 0000000..f551404
> --- /dev/null
> +++ b/include/xen/xenbus_dev.h
> @@ -0,0 +1,41 @@
> +/******************************************************************************
> + * evtchn.h
> + *
> + * Interface to /dev/xen/xenbusd.
> + *
> + * Copyright (c) 2011 Bastian Blank <waldi@debian.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef __LINUX_XEN_XENBUS_DEV_H__
> +#define __LINUX_XEN_XENBUS_DEV_H__
> +
> +#include <linux/ioctl.h>
> +
> +#define IOCTL_XENBUSD_EVTCHN				\
> +	_IOC(_IOC_NONE, 'X', 0, 0)

_IOC_READ ?

So why 'X', not 'B' for bus?

> +
> +#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
> -- 
> 1.7.7.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:38:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:38:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV65f-00028t-4d; Mon, 28 Nov 2011 18:38:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV65d-00028Q-Nd
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:38:06 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322505446!3401461!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23933 invoked from network); 28 Nov 2011 18:37:28 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 18:37:28 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASIbNg5023988
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 13:37:23 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASIbNX7023986;
	Mon, 28 Nov 2011 13:37:23 -0500
Date: Mon, 28 Nov 2011 14:37:23 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Bastian Blank <waldi@debian.org>, dgdegra@tycho.nsa.gov
Message-ID: <20111128183723.GD21369@andromeda.dapyr.net>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-6-git-send-email-waldi@debian.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322431628-21760-6-git-send-email-waldi@debian.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/5] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Nov 27, 2011 at 11:07:08PM +0100, Bastian Blank wrote:
> Access for xenstored to the event channel and pre-allocated ring is
> managed via xenfs.  This adds its own device driver featuring mmap for
> the ring and an ioctl for the event channel.
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> ---
>  drivers/xen/xenbus/Makefile             |    1 +
>  drivers/xen/xenbus/xenbus_dev_backend.c |   79 +++++++++++++++++++++++++++++++
>  include/xen/xenbus_dev.h                |   41 ++++++++++++++++
>  3 files changed, 121 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/xen/xenbus/xenbus_dev_backend.c
>  create mode 100644 include/xen/xenbus_dev.h
> 
> diff --git a/drivers/xen/xenbus/Makefile b/drivers/xen/xenbus/Makefile
> index a2ea363..7e1aa85 100644
> --- a/drivers/xen/xenbus/Makefile
> +++ b/drivers/xen/xenbus/Makefile
> @@ -10,4 +10,5 @@ xenbus-objs += xenbus_probe.o
>  xenbus-be-objs-$(CONFIG_XEN_BACKEND) += xenbus_probe_backend.o
>  xenbus-objs += $(xenbus-be-objs-y)
>  
> +obj-$(CONFIG_XEN_DOM0) += xenbus_dev_backend.o

I think this needs to depend on XEN_BACKEND ?

You could have a dom0 without any backends .. (Which is one of the goals
of disegragated device driver domains).

>  obj-$(CONFIG_XEN_XENBUS_FRONTEND) += xenbus_probe_frontend.o
> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
> new file mode 100644
> index 0000000..5d77cee
> --- /dev/null
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.c
> @@ -0,0 +1,79 @@
> +#include <linux/slab.h>
> +#include <linux/types.h>
> +#include <linux/mm.h>
> +#include <linux/fs.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +
> +#include <xen/page.h>
> +#include <xen/xenbus_dev.h>
> +
> +#include "xenbus_comms.h"
> +
> +MODULE_LICENSE("GPL");
> +
> +static long xenbusd_ioctl(struct file *file, unsigned int cmd, unsigned long data)
> +{
> +	if (!capable(CAP_SYS_ADMIN))
> +		return -EACCES;
> +
> +	switch (cmd) {
> +		case IOCTL_XENBUSD_EVTCHN:
> +			if (xen_store_evtchn > 0)
> +				return xen_store_evtchn;
> +			return -EINVAL;

Not -ENODEV? After all, the command arguments were OK, it is just that
the eventchannel has not been set.

> +
> +		default:
> +			return -ENOTTY;
> +	}
> +}
> +
> +static int xenbusd_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> +	size_t size = vma->vm_end - vma->vm_start;
> +
> +	if (!capable(CAP_SYS_ADMIN))
> +		return -EACCES;
> +
> +	if ((size > PAGE_SIZE) || (vma->vm_pgoff != 0))
> +		return -EINVAL;
> +
> +	if (remap_pfn_range(vma, vma->vm_start,
> +			    virt_to_pfn(xen_store_interface),
> +			    size, vma->vm_page_prot))
> +		return -EAGAIN;
> +
> +	return 0;
> +}
> +
> +const struct file_operations xenbusd_fops = {
> +	.mmap = xenbusd_mmap,
> +	.unlocked_ioctl = xenbusd_ioctl,
> +};
> +
> +static struct miscdevice xenbusd_dev = {
> +	.minor = MISC_DYNAMIC_MINOR,
> +	.name = "xen/xenbusd",
> +	.fops = &xenbusd_fops,
> +};
> +
> +static int __init xenbusd_init(void)
> +{
> +	int err;
> +
> +	if (!xen_initial_domain())

With the disgregated domains (and the patches that Daniel posted), I
think this needs to relax a bit. Perhaps just make it 'xen_domain'?

Lets CC him here.
> +		return -ENODEV;
> +
> +	err = misc_register(&xenbusd_dev);
> +	if (err)
> +		printk(KERN_ERR "Could not register xenbus device\n");
> +	return err;
> +}
> +
> +static void __exit xenbusd_exit(void)
> +{
> +	misc_deregister(&xenbusd_dev);
> +}
> +
> +module_init(xenbusd_init);
> +module_exit(xenbusd_exit);
> diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
> new file mode 100644
> index 0000000..f551404
> --- /dev/null
> +++ b/include/xen/xenbus_dev.h
> @@ -0,0 +1,41 @@
> +/******************************************************************************
> + * evtchn.h
> + *
> + * Interface to /dev/xen/xenbusd.
> + *
> + * Copyright (c) 2011 Bastian Blank <waldi@debian.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Software Foundation; or, when distributed
> + * separately from the Linux kernel or incorporated into other
> + * software packages, subject to the following license:
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this source file (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy, modify,
> + * merge, publish, distribute, sublicense, and/or sell copies of the Software,
> + * and to permit persons to whom the Software is furnished to do so, subject to
> + * the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef __LINUX_XEN_XENBUS_DEV_H__
> +#define __LINUX_XEN_XENBUS_DEV_H__
> +
> +#include <linux/ioctl.h>
> +
> +#define IOCTL_XENBUSD_EVTCHN				\
> +	_IOC(_IOC_NONE, 'X', 0, 0)

_IOC_READ ?

So why 'X', not 'B' for bus?

> +
> +#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
> -- 
> 1.7.7.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV66e-0002El-L7; Mon, 28 Nov 2011 18:39:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV66d-0002E5-5A
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:39:07 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322505478!54924524!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26011 invoked from network); 28 Nov 2011 18:37:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 18:37:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id E48135415A; Mon, 28 Nov 2011 19:38:30 +0100 (CET)
Date: Mon, 28 Nov 2011 19:38:30 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111128183830.GC6828@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel@lists.xensource.com
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-2-git-send-email-waldi@debian.org>
	<20111128181439.GB21369@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111128181439.GB21369@andromeda.dapyr.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/5] xen/sys/hypervisor: Export
 guest_properties/is_initial_domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 02:14:39PM -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Nov 27, 2011 at 11:07:04PM +0100, Bastian Blank wrote:
> > diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> > index 1e0fe01..d0916e8 100644
> > --- a/drivers/xen/sys-hypervisor.c
> > +++ b/drivers/xen/sys-hypervisor.c
> > @@ -355,6 +355,35 @@ static void xen_properties_destroy(void)
> >  	sysfs_remove_group(hypervisor_kobj, &xen_properties_group);
> >  }
> >  
> > +/* xen guest properties info */
> 
> Properties is plural, but this is a single attribute.

Just like the old /proc/xen/capabilites, it only supported one attribute
ever. However it could export a flag for hvm domain.

>                      Perhaps the name 'is_initial_domain' would be a
> better name?

It is already called this was.

>              What is the purpose of this attribute?

Replace /proc/xen/capabilities. See
<20100605162947.GA31336@wavehammer.waldi.eu.org>

>                                                     Who/what tools
> benefit from this?

The init scripts are the only users.

Bastian

-- 
Deflector shields just came on, Captain.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:39:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV66e-0002El-L7; Mon, 28 Nov 2011 18:39:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV66d-0002E5-5A
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:39:07 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322505478!54924524!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26011 invoked from network); 28 Nov 2011 18:37:58 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 18:37:58 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id E48135415A; Mon, 28 Nov 2011 19:38:30 +0100 (CET)
Date: Mon, 28 Nov 2011 19:38:30 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111128183830.GC6828@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel@lists.xensource.com
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-2-git-send-email-waldi@debian.org>
	<20111128181439.GB21369@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111128181439.GB21369@andromeda.dapyr.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1/5] xen/sys/hypervisor: Export
 guest_properties/is_initial_domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 02:14:39PM -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Nov 27, 2011 at 11:07:04PM +0100, Bastian Blank wrote:
> > diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> > index 1e0fe01..d0916e8 100644
> > --- a/drivers/xen/sys-hypervisor.c
> > +++ b/drivers/xen/sys-hypervisor.c
> > @@ -355,6 +355,35 @@ static void xen_properties_destroy(void)
> >  	sysfs_remove_group(hypervisor_kobj, &xen_properties_group);
> >  }
> >  
> > +/* xen guest properties info */
> 
> Properties is plural, but this is a single attribute.

Just like the old /proc/xen/capabilites, it only supported one attribute
ever. However it could export a flag for hvm domain.

>                      Perhaps the name 'is_initial_domain' would be a
> better name?

It is already called this was.

>              What is the purpose of this attribute?

Replace /proc/xen/capabilities. See
<20100605162947.GA31336@wavehammer.waldi.eu.org>

>                                                     Who/what tools
> benefit from this?

The init scripts are the only users.

Bastian

-- 
Deflector shields just came on, Captain.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:47:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV6E0-0002aq-JR; Mon, 28 Nov 2011 18:46:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV6Dy-0002ai-QQ
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:46:43 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322505965!5948257!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23234 invoked from network); 28 Nov 2011 18:46:06 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 18:46:06 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 94A975415A; Mon, 28 Nov 2011 19:46:04 +0100 (CET)
Date: Mon, 28 Nov 2011 19:46:04 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111128184604.GE6828@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel@lists.xensource.com
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
	<20111128182205.GC21369@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111128182205.GC21369@andromeda.dapyr.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 02:22:05PM -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Nov 27, 2011 at 11:07:05PM +0100, Bastian Blank wrote:
> > Access to arbitrary hypercalls is currently provided via xenfs. This
> > adds a standard character device to handle this. The support in xenfs
> Ok, what is the benefit of that? You mentioned in the prologue "about a
> year ago I started", but you didn't provide any links to the
> conversation. Could you include the details please?

<20100605162947.GA31336@wavehammer.waldi.eu.org>

> It looks like you are doing a move of the file. Can you use 'git mv'
> instead please.

I did actually. But git format-patch need an option to provide diffs of
moves.

> If it breaks compile build, you can modify the Kconfig to inhibit the
> build (say make it dependent on a symbol that won't be turned on).

No, it does not break the build.

> > +config XEN_PRIVCMD
> > +	tristate
> > +	depends on XEN_DOM0
> 
> Would it be possible for HVM domains that have the backend drivers in
> them (so blkback for example) to use these hypercalls? If so should this
> XEN_DOM0 be perhaps changed to something else?

The depends is wrong, privcmd can be used in any domain. Currently it
can be only activated through XENFS, but this should be changed.

Bastian

-- 
Love sometimes expresses itself in sacrifice.
		-- Kirk, "Metamorphosis", stardate 3220.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:47:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV6E0-0002aq-JR; Mon, 28 Nov 2011 18:46:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV6Dy-0002ai-QQ
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:46:43 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322505965!5948257!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23234 invoked from network); 28 Nov 2011 18:46:06 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 18:46:06 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 94A975415A; Mon, 28 Nov 2011 19:46:04 +0100 (CET)
Date: Mon, 28 Nov 2011 19:46:04 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111128184604.GE6828@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel@lists.xensource.com
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
	<20111128182205.GC21369@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111128182205.GC21369@andromeda.dapyr.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 02:22:05PM -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Nov 27, 2011 at 11:07:05PM +0100, Bastian Blank wrote:
> > Access to arbitrary hypercalls is currently provided via xenfs. This
> > adds a standard character device to handle this. The support in xenfs
> Ok, what is the benefit of that? You mentioned in the prologue "about a
> year ago I started", but you didn't provide any links to the
> conversation. Could you include the details please?

<20100605162947.GA31336@wavehammer.waldi.eu.org>

> It looks like you are doing a move of the file. Can you use 'git mv'
> instead please.

I did actually. But git format-patch need an option to provide diffs of
moves.

> If it breaks compile build, you can modify the Kconfig to inhibit the
> build (say make it dependent on a symbol that won't be turned on).

No, it does not break the build.

> > +config XEN_PRIVCMD
> > +	tristate
> > +	depends on XEN_DOM0
> 
> Would it be possible for HVM domains that have the backend drivers in
> them (so blkback for example) to use these hypercalls? If so should this
> XEN_DOM0 be perhaps changed to something else?

The depends is wrong, privcmd can be used in any domain. Currently it
can be only activated through XENFS, but this should be changed.

Bastian

-- 
Love sometimes expresses itself in sacrifice.
		-- Kirk, "Metamorphosis", stardate 3220.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:53:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV6Kb-0002ov-99; Mon, 28 Nov 2011 18:53:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV6KZ-0002op-HR
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:53:31 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322506374!5381262!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 318 invoked from network); 28 Nov 2011 18:52:55 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 18:52:55 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 25EBF5415A; Mon, 28 Nov 2011 19:52:54 +0100 (CET)
Date: Mon, 28 Nov 2011 19:52:53 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111128185253.GA8846@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, dgdegra@tycho.nsa.gov,
	xen-devel@lists.xensource.com
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-6-git-send-email-waldi@debian.org>
	<20111128183723.GD21369@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111128183723.GD21369@andromeda.dapyr.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: dgdegra@tycho.nsa.gov, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/5] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 02:37:23PM -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Nov 27, 2011 at 11:07:08PM +0100, Bastian Blank wrote:
> > +obj-$(CONFIG_XEN_DOM0) += xenbus_dev_backend.o
> I think this needs to depend on XEN_BACKEND ?

Right.

> > +		case IOCTL_XENBUSD_EVTCHN:
> > +			if (xen_store_evtchn > 0)
> > +				return xen_store_evtchn;
> > +			return -EINVAL;
> 
> Not -ENODEV? After all, the command arguments were OK, it is just that
> the eventchannel has not been set.

Ups.

> > +	if (!xen_initial_domain())
> 
> With the disgregated domains (and the patches that Daniel posted), I
> think this needs to relax a bit. Perhaps just make it 'xen_domain'?

Right now, xenstored needs to run where the communication ring is
located. And this ring is allocated in dom0. How would any domU run
without xenstored available?

> > +#define IOCTL_XENBUSD_EVTCHN				\
> > +	_IOC(_IOC_NONE, 'X', 0, 0)
> _IOC_READ ?

No. It does not communicate via the parameter, only the return value.

Bastian

-- 
Schshschshchsch.
		-- The Gorn, "Arena", stardate 3046.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 18:53:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 18:53:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV6Kb-0002ov-99; Mon, 28 Nov 2011 18:53:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV6KZ-0002op-HR
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 18:53:31 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322506374!5381262!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 318 invoked from network); 28 Nov 2011 18:52:55 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 18:52:55 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 25EBF5415A; Mon, 28 Nov 2011 19:52:54 +0100 (CET)
Date: Mon, 28 Nov 2011 19:52:53 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20111128185253.GA8846@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, dgdegra@tycho.nsa.gov,
	xen-devel@lists.xensource.com
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-6-git-send-email-waldi@debian.org>
	<20111128183723.GD21369@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111128183723.GD21369@andromeda.dapyr.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: dgdegra@tycho.nsa.gov, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/5] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 02:37:23PM -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Nov 27, 2011 at 11:07:08PM +0100, Bastian Blank wrote:
> > +obj-$(CONFIG_XEN_DOM0) += xenbus_dev_backend.o
> I think this needs to depend on XEN_BACKEND ?

Right.

> > +		case IOCTL_XENBUSD_EVTCHN:
> > +			if (xen_store_evtchn > 0)
> > +				return xen_store_evtchn;
> > +			return -EINVAL;
> 
> Not -ENODEV? After all, the command arguments were OK, it is just that
> the eventchannel has not been set.

Ups.

> > +	if (!xen_initial_domain())
> 
> With the disgregated domains (and the patches that Daniel posted), I
> think this needs to relax a bit. Perhaps just make it 'xen_domain'?

Right now, xenstored needs to run where the communication ring is
located. And this ring is allocated in dom0. How would any domU run
without xenstored available?

> > +#define IOCTL_XENBUSD_EVTCHN				\
> > +	_IOC(_IOC_NONE, 'X', 0, 0)
> _IOC_READ ?

No. It does not communicate via the parameter, only the return value.

Bastian

-- 
Schshschshchsch.
		-- The Gorn, "Arena", stardate 3046.2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 19:10:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 19:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV6aZ-0003OA-Oz; Mon, 28 Nov 2011 19:10:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV6aY-0003NW-2B
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 19:10:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322507365!5358743!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 634 invoked from network); 28 Nov 2011 19:09:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 19:09:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9171438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 19:09:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 19:09:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RV6Zw-0005qB-N1;
	Mon, 28 Nov 2011 19:09:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RV6Zw-0004A5-Hr;
	Mon, 28 Nov 2011 19:09:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10168-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 19:09:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10168: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10168 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10168/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-pv           13 guest-localmigrate.2       fail REGR. vs. 9956
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10     fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a9c67c2daf4b
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 921 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 19:10:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 19:10:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV6aZ-0003OA-Oz; Mon, 28 Nov 2011 19:10:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RV6aY-0003NW-2B
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 19:10:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322507365!5358743!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 634 invoked from network); 28 Nov 2011 19:09:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 19:09:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9171438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 19:09:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 19:09:24 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RV6Zw-0005qB-N1;
	Mon, 28 Nov 2011 19:09:24 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RV6Zw-0004A5-Hr;
	Mon, 28 Nov 2011 19:09:24 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10168-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 19:09:24 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10168: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10168 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10168/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-i386-pv           13 guest-localmigrate.2       fail REGR. vs. 9956
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10     fail REGR. vs. 9956

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a9c67c2daf4b
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 921 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 19:13:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 19:13:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV6dg-0003by-Da; Mon, 28 Nov 2011 19:13:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV6df-0003bq-5N
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 19:13:15 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322507529!54927506!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16801 invoked from network); 28 Nov 2011 19:12:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-27.messagelabs.com with SMTP;
	28 Nov 2011 19:12:09 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASJBx13007174; Mon, 28 Nov 2011 19:11:59 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASJBxkX008143; 
	Mon, 28 Nov 2011 14:11:59 -0500
Message-ID: <4ED3DD13.3050102@tycho.nsa.gov>
Date: Mon, 28 Nov 2011 14:12:19 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Bastian Blank <bastian@waldi.eu.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-6-git-send-email-waldi@debian.org>
	<20111128183723.GD21369@andromeda.dapyr.net>
	<20111128185253.GA8846@wavehammer.waldi.eu.org>
In-Reply-To: <20111128185253.GA8846@wavehammer.waldi.eu.org>
X-Enigmail-Version: 1.3.2
Subject: Re: [Xen-devel] [PATCH 5/5] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/28/2011 01:52 PM, Bastian Blank wrote:
> On Mon, Nov 28, 2011 at 02:37:23PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Sun, Nov 27, 2011 at 11:07:08PM +0100, Bastian Blank wrote:
>>> +	if (!xen_initial_domain())
>>
>> With the disgregated domains (and the patches that Daniel posted), I
>> think this needs to relax a bit. Perhaps just make it 'xen_domain'?

What we want is for this device to appear any time xenstored is in
the local domain. In xenbus_probe, I use the xen_start_info structure
to determine this - xen_start_info->store_evtchn is nonzero if there
is a remote xenstored.

> Right now, xenstored needs to run where the communication ring is
> located. And this ring is allocated in dom0. How would any domU run
> without xenstored available?
> 

A domU can run just fine without xenstored available - in particular,
it is possible to run xenstored itself in a domU. This requires either
dom0 patches to enable xenbus to be relocated after launch, or for
xenstored to be started prior to the Linux initial domain. In both
cases, it also requires a modified domain builder that doesn't talk
to xenstored.

This change is only important if xenstored is running in a Linux-based
stub domain instead of a minios-based one.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 19:13:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 19:13:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV6dg-0003by-Da; Mon, 28 Nov 2011 19:13:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RV6df-0003bq-5N
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 19:13:15 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322507529!54927506!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16801 invoked from network); 28 Nov 2011 19:12:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-27.messagelabs.com with SMTP;
	28 Nov 2011 19:12:09 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pASJBx13007174; Mon, 28 Nov 2011 19:11:59 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pASJBxkX008143; 
	Mon, 28 Nov 2011 14:11:59 -0500
Message-ID: <4ED3DD13.3050102@tycho.nsa.gov>
Date: Mon, 28 Nov 2011 14:12:19 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Bastian Blank <bastian@waldi.eu.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-6-git-send-email-waldi@debian.org>
	<20111128183723.GD21369@andromeda.dapyr.net>
	<20111128185253.GA8846@wavehammer.waldi.eu.org>
In-Reply-To: <20111128185253.GA8846@wavehammer.waldi.eu.org>
X-Enigmail-Version: 1.3.2
Subject: Re: [Xen-devel] [PATCH 5/5] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/28/2011 01:52 PM, Bastian Blank wrote:
> On Mon, Nov 28, 2011 at 02:37:23PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Sun, Nov 27, 2011 at 11:07:08PM +0100, Bastian Blank wrote:
>>> +	if (!xen_initial_domain())
>>
>> With the disgregated domains (and the patches that Daniel posted), I
>> think this needs to relax a bit. Perhaps just make it 'xen_domain'?

What we want is for this device to appear any time xenstored is in
the local domain. In xenbus_probe, I use the xen_start_info structure
to determine this - xen_start_info->store_evtchn is nonzero if there
is a remote xenstored.

> Right now, xenstored needs to run where the communication ring is
> located. And this ring is allocated in dom0. How would any domU run
> without xenstored available?
> 

A domU can run just fine without xenstored available - in particular,
it is possible to run xenstored itself in a domU. This requires either
dom0 patches to enable xenbus to be relocated after launch, or for
xenstored to be started prior to the Linux initial domain. In both
cases, it also requires a modified domain builder that doesn't talk
to xenstored.

This change is only important if xenstored is running in a Linux-based
stub domain instead of a minios-based one.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 19:14:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 19:14:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV6eK-0003h7-88; Mon, 28 Nov 2011 19:13:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV6eI-0003gA-F8
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 19:13:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322507598!5950555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32692 invoked from network); 28 Nov 2011 19:13:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 19:13:18 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9171469"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 19:13:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 19:13:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <bastian@waldi.eu.org>
In-Reply-To: <20111128182353.GB6828@wavehammer.waldi.eu.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
	<1322497613.20646.19.camel@zakaz.uk.xensource.com>
	<20111128173954.GA6828@wavehammer.waldi.eu.org>
	<1322503221.11846.29.camel@dagon.hellion.org.uk>
	<20111128182353.GB6828@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 19:13:16 +0000
Message-ID: <1322507596.11846.30.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 18:23 +0000, Bastian Blank wrote:
> On Mon, Nov 28, 2011 at 06:00:21PM +0000, Ian Campbell wrote:
> > On Mon, 2011-11-28 at 17:39 +0000, Bastian Blank wrote:
> > > On Mon, Nov 28, 2011 at 04:26:53PM +0000, Ian Campbell wrote:
> > > > The main reason would be to avoid the select since selecting on user
> > > > visible symbols is a recipe for confusion and is generally advised
> > > > against.
> > > Right. It is just the easiest solution.
> > XENFS could depend on XEN_PRIVCMD and whatever else it needs?
> 
> This makes sure the module is built. But it does not make sure it is
> also loaded.

Since xenfs uses symbols from xen-privcmd "modprobe xenfs" will also
cause xen-privcmd to be loaded.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 19:14:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 19:14:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV6eK-0003h7-88; Mon, 28 Nov 2011 19:13:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RV6eI-0003gA-F8
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 19:13:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322507598!5950555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32692 invoked from network); 28 Nov 2011 19:13:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 19:13:18 -0000
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; 
   d="scan'208";a="9171469"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 19:13:17 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 28 Nov 2011 19:13:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <bastian@waldi.eu.org>
In-Reply-To: <20111128182353.GB6828@wavehammer.waldi.eu.org>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-3-git-send-email-waldi@debian.org>
	<1322497613.20646.19.camel@zakaz.uk.xensource.com>
	<20111128173954.GA6828@wavehammer.waldi.eu.org>
	<1322503221.11846.29.camel@dagon.hellion.org.uk>
	<20111128182353.GB6828@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
Date: Mon, 28 Nov 2011 19:13:16 +0000
Message-ID: <1322507596.11846.30.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen: Add privcmd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 18:23 +0000, Bastian Blank wrote:
> On Mon, Nov 28, 2011 at 06:00:21PM +0000, Ian Campbell wrote:
> > On Mon, 2011-11-28 at 17:39 +0000, Bastian Blank wrote:
> > > On Mon, Nov 28, 2011 at 04:26:53PM +0000, Ian Campbell wrote:
> > > > The main reason would be to avoid the select since selecting on user
> > > > visible symbols is a recipe for confusion and is generally advised
> > > > against.
> > > Right. It is just the easiest solution.
> > XENFS could depend on XEN_PRIVCMD and whatever else it needs?
> 
> This makes sure the module is built. But it does not make sure it is
> also loaded.

Since xenfs uses symbols from xen-privcmd "modprobe xenfs" will also
cause xen-privcmd to be loaded.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 19:43:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 19:43:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV76V-0004uu-H8; Mon, 28 Nov 2011 19:43:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV76U-0004ug-5d
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 19:43:02 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322509345!460838!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2567 invoked from network); 28 Nov 2011 19:42:25 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 19:42:25 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 61B445415A; Mon, 28 Nov 2011 20:42:24 +0100 (CET)
Date: Mon, 28 Nov 2011 20:42:24 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111128194224.GA9766@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel@lists.xensource.com
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-6-git-send-email-waldi@debian.org>
	<20111128183723.GD21369@andromeda.dapyr.net>
	<20111128185253.GA8846@wavehammer.waldi.eu.org>
	<4ED3DD13.3050102@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED3DD13.3050102@tycho.nsa.gov>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/5] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 02:12:19PM -0500, Daniel De Graaf wrote:
> On 11/28/2011 01:52 PM, Bastian Blank wrote:
> > On Mon, Nov 28, 2011 at 02:37:23PM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Sun, Nov 27, 2011 at 11:07:08PM +0100, Bastian Blank wrote:
> >>> +	if (!xen_initial_domain())
> >>
> >> With the disgregated domains (and the patches that Daniel posted), I
> >> think this needs to relax a bit. Perhaps just make it 'xen_domain'?
> 
> What we want is for this device to appear any time xenstored is in
> the local domain. In xenbus_probe, I use the xen_start_info structure
> to determine this - xen_start_info->store_evtchn is nonzero if there
> is a remote xenstored.

Ah. I missed this change. So the best way to do this is to register the
device from xenstored_local_init.

Bastian

-- 
Prepare for tomorrow -- get ready.
		-- Edith Keeler, "The City On the Edge of Forever",
		   stardate unknown

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 19:43:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 19:43:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV76V-0004uu-H8; Mon, 28 Nov 2011 19:43:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bastian@waldi.eu.org>) id 1RV76U-0004ug-5d
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 19:43:02 +0000
X-Env-Sender: bastian@waldi.eu.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1322509345!460838!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2567 invoked from network); 28 Nov 2011 19:42:25 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Nov 2011 19:42:25 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 61B445415A; Mon, 28 Nov 2011 20:42:24 +0100 (CET)
Date: Mon, 28 Nov 2011 20:42:24 +0100
From: Bastian Blank <bastian@waldi.eu.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20111128194224.GA9766@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <bastian@waldi.eu.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel@lists.xensource.com
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-6-git-send-email-waldi@debian.org>
	<20111128183723.GD21369@andromeda.dapyr.net>
	<20111128185253.GA8846@wavehammer.waldi.eu.org>
	<4ED3DD13.3050102@tycho.nsa.gov>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED3DD13.3050102@tycho.nsa.gov>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 5/5] xen: Add xenbusd device driver
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 02:12:19PM -0500, Daniel De Graaf wrote:
> On 11/28/2011 01:52 PM, Bastian Blank wrote:
> > On Mon, Nov 28, 2011 at 02:37:23PM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Sun, Nov 27, 2011 at 11:07:08PM +0100, Bastian Blank wrote:
> >>> +	if (!xen_initial_domain())
> >>
> >> With the disgregated domains (and the patches that Daniel posted), I
> >> think this needs to relax a bit. Perhaps just make it 'xen_domain'?
> 
> What we want is for this device to appear any time xenstored is in
> the local domain. In xenbus_probe, I use the xen_start_info structure
> to determine this - xen_start_info->store_evtchn is nonzero if there
> is a remote xenstored.

Ah. I missed this change. So the best way to do this is to register the
device from xenstored_local_init.

Bastian

-- 
Prepare for tomorrow -- get ready.
		-- Edith Keeler, "The City On the Edge of Forever",
		   stardate unknown

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 22:11:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 22:11:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV9P5-00077c-Gy; Mon, 28 Nov 2011 22:10:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <wcohen@redhat.com>) id 1RV9P3-000773-Ma
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 22:10:22 +0000
X-Env-Sender: wcohen@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322518183!6173331!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU2MzY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23729 invoked from network); 28 Nov 2011 22:09:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	28 Nov 2011 22:09:44 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pASM9ZZ9018633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 28 Nov 2011 17:09:35 -0500
Received: from [10.11.231.236] (deploy7.rdu.redhat.com [10.11.231.236])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pASM9YQ1022937; Mon, 28 Nov 2011 17:09:34 -0500
Message-ID: <4ED4069E.7030307@redhat.com>
Date: Mon, 28 Nov 2011 17:09:34 -0500
From: William Cohen <wcohen@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1
	Thunderbird/3.1.16
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary="------------040805060702070905020204"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------040805060702070905020204
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 

I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?

-Will

--------------040805060702070905020204
Content-Type: text/x-patch;
 name="oprofile-0.9.7-xen.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="oprofile-0.9.7-xen.patch"

diff -up oprofile-0.9.7/daemon/init.c.xen oprofile-0.9.7/daemon/init.c
--- oprofile-0.9.7/daemon/init.c.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/init.c	2011-11-28 16:25:07.577000010 -0500
@@ -312,6 +312,8 @@ static void opd_26_init(void)
 
 	opd_create_vmlinux(vmlinux, kernel_range);
 	opd_create_xen(xenimage, xen_range);
+	if (xen_passive_setup)
+		opd_create_passive(xen_passive_setup);
 
 	opd_buf_size = opd_read_fs_int("/dev/oprofile/", "buffer_size", 1);
 	kernel_pointer_size = opd_read_fs_int("/dev/oprofile/", "pointer_size", 1);
diff -up oprofile-0.9.7/daemon/opd_kernel.c.xen oprofile-0.9.7/daemon/opd_kernel.c
--- oprofile-0.9.7/daemon/opd_kernel.c.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/opd_kernel.c	2011-11-28 16:25:07.579000010 -0500
@@ -34,11 +34,22 @@ static struct kernel_image vmlinux_image
 
 static struct kernel_image xen_image;
 
+static struct kernel_image xen_image_anon;
+static struct kernel_image vmlinux_image_anon;
+
+static LIST_HEAD(passive_vmlinux);
+static LIST_HEAD(passive_xen);
+static LIST_HEAD(passive_apps);
+static LIST_HEAD(passive_modules);
+static LIST_HEAD(passive_xen_anon);
+
 void opd_create_vmlinux(char const * name, char const * arg)
 {
 	/* vmlinux is *not* on the list of modules */
 	list_init(&vmlinux_image.list);
 
+	list_init(&vmlinux_image_anon.list);
+
 	/* for no vmlinux */
 	if (no_vmlinux) {
 		vmlinux_image.name = "no-vmlinux";
@@ -57,13 +68,22 @@ void opd_create_vmlinux(char const * nam
 		        vmlinux_image.start, vmlinux_image.end);
 		exit(EXIT_FAILURE);
 	}
+
+	vmlinux_image_anon.name  = "vmlinux-unknown";
+	vmlinux_image_anon.start = vmlinux_image.start;
+	vmlinux_image_anon.end   = vmlinux_image.end;
+
 }
 
 void opd_create_xen(char const * name, char const * arg)
 {
+	int stat;
+
 	/* xen is *not* on the list of modules */
 	list_init(&xen_image.list);
 
+	list_init(&xen_image_anon.list);
+
 	/* for no xen */
 	if (no_xen) {
 		xen_image.name = "no-xen";
@@ -72,18 +92,106 @@ void opd_create_xen(char const * name, c
 
 	xen_image.name = xstrdup(name);
 
-	sscanf(arg, "%llx,%llx", &xen_image.start, &xen_image.end);
+	stat = sscanf(arg, "%llx,%llx", &xen_image.start, &xen_image.end);
+
+	xen_image_anon.name  = "xen-unknown";
+	xen_image_anon.start = xen_image.start;
+	xen_image_anon.end   = xen_image.end;
 
 	verbprintf(vmisc, "xen_start = %llx, xen_end = %llx\n",
 	           xen_image.start, xen_image.end);
 
-	if (!xen_image.start && !xen_image.end) {
+	if ( stat != 2 ) {
 		fprintf(stderr, "error: mis-parsed xen range: %llx-%llx\n",
 		        xen_image.start, xen_image.end);
 		exit(EXIT_FAILURE);
 	}
+
 }
 
+void opd_create_passive_domain(int id, char const * image_kernel, 
+			       char const * range, char const * image_xen)
+{
+	char file[64];
+	struct kernel_image * image;
+	int stat;
+
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(image_kernel);
+	image->start = image->end = 0; 
+	stat = sscanf(range, "%llx,%llx", &image->start, &image->end);
+	image->id = id;
+	list_add(&image->list, &passive_vmlinux);
+	
+	if ( stat != 2 ) {
+		fprintf(stderr, "error: mis-parsed passive domain range for "
+			"domain %d: %llx-%llx\n", id, image->start, image->end);
+		exit(EXIT_FAILURE);
+	}
+
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(image_xen);
+	image->start = xen_image.start;
+	image->end = xen_image.end;
+	image->id = id;
+	list_add(&image->list, &passive_xen);
+
+	sprintf(file, "domain%d-apps", id);
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(file);
+	image->start = 0; 
+	image->end = 0;
+	image->id = id;
+	list_add(&image->list, &passive_apps);
+
+	sprintf(file, "domain%d-modules", id);
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(file);
+	image->start = 0; 
+	image->end = 0;
+	stat = sscanf(range, "%llx,%llx", &image->start, &image->end);
+	image->id = id;
+	list_add(&image->list, &passive_modules);
+
+	sprintf(file, "domain%d-xen-unknown", id);
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(file);
+	image->start = xen_image.start; 
+	image->end = xen_image.end;
+	image->id = id;
+	list_add(&image->list, &passive_xen_anon);
+
+}
+
+void opd_create_passive(char const *setup_file)
+{
+	FILE *fp;
+	int id=0;
+	char image_kernel[128+1];
+	char range[128+1];
+	char image_xen[128+1];
+	int stat;
+
+	image_kernel[0] = range[0] = image_xen[0] = 0;
+
+	fp = fopen(setup_file, "r");
+
+	if (!fp) {
+		fprintf(stderr, "error: Could not open Xen passive domain "
+			"setup file %s\n", setup_file);
+		exit(EXIT_FAILURE);
+	}
+
+	while (1) {
+		stat = fscanf(fp, "%d %128s %128s %128s", &id, image_kernel, range, 
+			image_xen);
+		if ( stat != 4 )
+			return;
+		opd_create_passive_domain(id, image_kernel, range, image_xen);
+	}
+
+	fclose(fp);
+}
 
 /**
  * Allocate and initialise a kernel image description
@@ -210,6 +318,75 @@ struct kernel_image * find_kernel_image(
 	struct list_head * pos;
 	struct kernel_image * image = &vmlinux_image;
 
+	if (current_domain != COORDINATOR_DOMAIN) {
+		/* we rely on cpu_mode value (i.e. trans->in_kernel)
+		 * to search the right image type: xen, kernel or user
+		 * We cannot use address ranges since hypervisor does not
+		 * share the same address space with fully virtualized guests,
+		 * and thus address ranges can overlap  */
+		switch ( trans->in_kernel ) {
+
+		/* user mode */
+		case 1:
+			list_for_each(pos, &passive_apps) {
+				image = list_entry(pos, struct kernel_image, list);
+				if (image->id == current_domain) 
+					return image;
+			}
+			return NULL;
+
+		/* kernel mode */
+		case 2:
+			list_for_each(pos, &passive_vmlinux) {
+				image = list_entry(pos, struct kernel_image, list);
+				if ( (image->id == current_domain)
+				     && ( (image->start == 0 && image->end == 0)
+					  || (image->start <= trans->pc 
+					      && image->end > trans->pc) ) )
+						return image;
+			}
+			/* if not in kernel image range then it should be a module */ 
+			list_for_each(pos, &passive_modules) {
+				image = list_entry(pos, struct kernel_image, list);
+				if (image->id == current_domain) 
+					return image;
+			}
+			/* This should not happen if the kernel and user level 
+                           oprofile code are sane and in sync */
+			return NULL;
+
+		/* hypervisor mode */
+		case 3:
+			list_for_each(pos, &passive_xen) {
+				image = list_entry(pos, struct kernel_image, list);
+				if (image->id == current_domain
+				    && image->start <= trans->pc 
+				    && image->end > trans->pc) 
+					return image;
+			}
+			list_for_each(pos, &passive_xen_anon) {
+				image = list_entry(pos, struct kernel_image, list);
+				if (image->id == current_domain)
+					return image;
+			}
+			return NULL;
+
+		default:
+			printf("Unexpected error on passive mode: CPU mode is "
+			       "%d for domain %d\n", trans->in_kernel, current_domain);
+			return NULL;
+		}
+		
+		
+	}
+
+	if (xen_image.start <= trans->pc && xen_image.end > trans->pc)
+		return &xen_image;
+ 
+	if (trans->in_kernel == 2) {
+		return &xen_image_anon;
+	}
+
 	if (no_vmlinux)
 		return image;
 
@@ -222,8 +399,5 @@ struct kernel_image * find_kernel_image(
 			return image;
 	}
 
-	if (xen_image.start <= trans->pc && xen_image.end > trans->pc)
-		return &xen_image;
-
-	return NULL;
+	return &vmlinux_image_anon;
 }
diff -up oprofile-0.9.7/daemon/opd_kernel.h.xen oprofile-0.9.7/daemon/opd_kernel.h
--- oprofile-0.9.7/daemon/opd_kernel.h.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/opd_kernel.h	2011-11-28 16:25:07.580000010 -0500
@@ -23,8 +23,12 @@ struct transient;
 /** create the kernel image */
 void opd_create_vmlinux(char const * name, char const * arg);
 
+/** create Xen image */
 void opd_create_xen(char const * name, char const * arg);
 
+/** create Xen passive domain images */
+void opd_create_passive(char const *setup_file);
+
 /** opd_reread_module_info - parse /proc/modules for kernel modules */
 void opd_reread_module_info(void);
 
@@ -33,6 +37,7 @@ struct kernel_image {
 	char * name;
 	vma_t start;
 	vma_t end;
+	int id;
 	struct list_head list;
 };
 
diff -up oprofile-0.9.7/daemon/opd_sfile.c.xen oprofile-0.9.7/daemon/opd_sfile.c
--- oprofile-0.9.7/daemon/opd_sfile.c.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/opd_sfile.c	2011-11-28 16:25:07.582000010 -0500
@@ -240,7 +240,7 @@ struct sfile * sfile_find(struct transie
 	}
 
 	/* we might need a kernel image start/end to hash on */
-	if (trans->in_kernel) {
+	else if (trans->in_kernel) {
 		ki = find_kernel_image(trans);
 		if (!ki) {
 			verbprintf(vsamples, "Lost kernel sample %llx\n", trans->pc);
diff -up oprofile-0.9.7/daemon/opd_trans.c.xen oprofile-0.9.7/daemon/opd_trans.c
--- oprofile-0.9.7/daemon/opd_trans.c.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/opd_trans.c	2011-11-28 16:25:07.584000010 -0500
@@ -31,6 +31,8 @@
 #include <stdio.h>
 #include <errno.h>
 
+int32_t current_domain = COORDINATOR_DOMAIN;
+
 extern size_t kernel_pointer_size;
 
 
@@ -203,6 +205,9 @@ static void code_kernel_enter(struct tra
 {
 	verbprintf(vmisc, "KERNEL_ENTER_SWITCH to kernel\n");
 	trans->in_kernel = 1;
+	/* if in passive domain mode cpu mode should be incremented */
+	if (current_domain != COORDINATOR_DOMAIN)
+		trans->in_kernel++;
 	clear_trans_current(trans);
 	/* subtlety: we must keep trans->cookie cached,
 	 * even though it's meaningless for the kernel -
@@ -216,6 +221,9 @@ static void code_user_enter(struct trans
 {
 	verbprintf(vmisc, "USER_ENTER_SWITCH to user-space\n");
 	trans->in_kernel = 0;
+	/* if in passive domain mode cpu mode should be incremented */
+	if (current_domain != COORDINATOR_DOMAIN)
+		trans->in_kernel++;
 	clear_trans_current(trans);
 	clear_trans_last(trans);
 }
@@ -244,17 +252,34 @@ static void code_trace_begin(struct tran
 static void code_xen_enter(struct transient * trans)
 {
 	verbprintf(vmisc, "XEN_ENTER_SWITCH to xen\n");
-	trans->in_kernel = 1;
+	trans->in_kernel = 2;
+	/* if in passive domain mode cpu mode should be incremented */
+	if (current_domain != COORDINATOR_DOMAIN)
+		trans->in_kernel++;
 	trans->current = NULL;
 	/* subtlety: we must keep trans->cookie cached, even though it's
-	 * meaningless for Xen - we won't necessarily get a cookie switch
-	 * on Xen exit. See comments in opd_sfile.c. It seems that we can
-	 * get away with in_kernel = 1 as long as we supply the correct
-	 * Xen image, and its address range in startup find_kernel_image
-	 * is modified to look in the Xen image also
-	 */
+	 * meaningless for Xen - same reason as for kernel */
 }
 
+static void code_domain_switch(struct transient *trans)
+{
+	/* While processing passive domain samples we ensure (in_kernel!=0)
+	 * We do this in order to ignore cookies for passive domain samples 
+	 * But, we have to remember the kernel value for coordinator domain, 
+	 * so we do the safe thing: increment when leaving the coordinator
+	 * domain and decrement when returning to it 
+ 	 */
+	if (current_domain == COORDINATOR_DOMAIN)
+		trans->in_kernel++;
+
+	trans->current = NULL;
+	current_domain = (int32_t) pop_buffer_value(trans);
+
+	/* If returning to coordinator domain restore the kernel value */
+	if (current_domain == COORDINATOR_DOMAIN)
+		trans->in_kernel--;
+}
+ 
 extern void code_spu_profiling(struct transient * trans);
 extern void code_spu_ctx_switch(struct transient * trans);
 
@@ -278,7 +303,7 @@ handler_t handlers[LAST_CODE + 1] = {
 	&code_spu_profiling,
 	&code_spu_ctx_switch,
 #else
-	&code_unknown,
+ 	&code_domain_switch,
 	&code_unknown,
 #endif
 	&code_ibs_fetch_sample,
diff -up oprofile-0.9.7/daemon/opd_trans.h.xen oprofile-0.9.7/daemon/opd_trans.h
--- oprofile-0.9.7/daemon/opd_trans.h.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/opd_trans.h	2011-11-28 16:25:07.585000010 -0500
@@ -21,6 +21,10 @@
 
 #include <stdint.h>
 
+#define COORDINATOR_DOMAIN -1
+
+extern int32_t current_domain;
+
 struct sfile;
 struct anon_mapping;
 
diff -up oprofile-0.9.7/daemon/oprofiled.c.xen oprofile-0.9.7/daemon/oprofiled.c
--- oprofile-0.9.7/daemon/oprofiled.c.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/oprofiled.c	2011-11-28 16:25:07.587000010 -0500
@@ -71,6 +71,7 @@ char * session_dir;
 int no_xen;
 char * xenimage;
 char * xen_range;
+char * xen_passive_setup;
 static char * verbose;
 static char * binary_name_filter;
 static char * events;
@@ -91,6 +92,7 @@ static struct poptOption options[] = {
 	{ "xen-range", 0, POPT_ARG_STRING, &xen_range, 0, "Xen VMA range", "start-end", },
 	{ "xen-image", 0, POPT_ARG_STRING, &xenimage, 0, "Xen image", "file", },
 	{ "image", 0, POPT_ARG_STRING, &binary_name_filter, 0, "image name filter", "profile these comma separated image" },
+	{ "xen-passive-setup", 0, POPT_ARG_STRING, &xen_passive_setup, 0, "Xen passive domain setup file", "filename", },
 	{ "separate-lib", 0, POPT_ARG_INT, &separate_lib, 0, "separate library samples for each distinct application", "[0|1]", },
 	{ "separate-kernel", 0, POPT_ARG_INT, &separate_kernel, 0, "separate kernel samples for each distinct application", "[0|1]", },
 	{ "separate-thread", 0, POPT_ARG_INT, &separate_thread, 0, "thread-profiling mode", "[0|1]" },
diff -up oprofile-0.9.7/daemon/oprofiled.h.xen oprofile-0.9.7/daemon/oprofiled.h
--- oprofile-0.9.7/daemon/oprofiled.h.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/oprofiled.h	2011-11-28 16:25:07.588000010 -0500
@@ -65,5 +65,6 @@ extern char * kernel_range;
 extern int no_xen;
 extern char * xenimage;
 extern char * xen_range;
+extern char * xen_passive_setup;
 
 #endif /* OPROFILED_H */
diff -up oprofile-0.9.7/doc/opcontrol.1.in.xen oprofile-0.9.7/doc/opcontrol.1.in
--- oprofile-0.9.7/doc/opcontrol.1.in.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/doc/opcontrol.1.in	2011-11-28 16:25:07.590000010 -0500
@@ -158,12 +158,41 @@ Xen image
 .br
 .TP
 .BI "--active-domains="<list>
-List of domain ids participating in a multi-domain profiling session. If 
+List of domain ids participating in a multi-domain profiling session. 
+Each of the specified domains must run an instance of oprofile. The 
+sequence of opcontrol commands in each domain must follow a given 
+order which is specified in the oprofile user manual. If 
 more than one domain is specified in <list> they should be separated using 
 commas. This option can only be used in domain 0 which is the only domain 
 that can coordinate a multi-domain profiling session. Including domain 0 in 
 the list of active domains is optional. (e.g. --active-domains=2,5,6 and 
---active-domains=0,2,5,6 are equivalent)
+--active-domains=0,2,5,6 are equivalent).
+This option can only be specified
+if --start-daemon is also specified and it is only 
+valid for the current run of the oprofile daemon; e.g. the list 
+of active domains is not persistent.
+.br
+.TP
+.BI "--passive-domains="<list> or "--domains="<list>
+List of domain ids to be profiled, separated by commas. 
+As opposed to the --active-domains option, the domains specified with this
+option do not need to run oprofile. This makes 
+profiling multiple domains easier. However, with the passive-domains option, 
+samples in user level processes and kernel modules cannot be 
+mapped to specific symbols and are aggregated
+under a generic class. Both --active-domains and --passive-domains 
+options can be specified in the same command, but the same domain cannot be
+specified in both options. This option can only be specified if either --start
+or --start-daemon is specified on the same command and it is only valid for 
+the current run of the oprofile daemon; e.g. the list of passive domains is 
+not persistent.
+.br
+.TP
+.BI "--passive-images="<list> or "--domains-images="<list>
+List of kernel images associated with the domains specified in the
+--passive-domains option, also separated by commas. The association
+between the images and domains is based on the order they are
+specified in both options.
 .br
 
 .SH ENVIRONMENT
diff -up oprofile-0.9.7/libpp/format_output.cpp.xen oprofile-0.9.7/libpp/format_output.cpp
--- oprofile-0.9.7/libpp/format_output.cpp.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/libpp/format_output.cpp	2011-11-28 16:25:07.592000010 -0500
@@ -287,8 +287,8 @@ string formatter::format_app_name(field_
 {
 	return get_image_name(f.symbol.app_name,
 		long_filenames 
-			? image_name_storage::int_real_filename
-			: image_name_storage::int_real_basename,
+			? image_name_storage::int_filename
+			: image_name_storage::int_basename,
 		extra_found_images);
 }
 
diff -up oprofile-0.9.7/utils/opcontrol.xen oprofile-0.9.7/utils/opcontrol
--- oprofile-0.9.7/utils/opcontrol.xen	2011-07-20 15:36:48.000000000 -0400
+++ oprofile-0.9.7/utils/opcontrol	2011-11-28 16:28:56.431000248 -0500
@@ -236,9 +236,16 @@ opcontrol: usage:
    --note-table-size             kernel notes buffer size in notes units (2.4
                                  kernel)
 
-   --xen                         Xen image (for Xen only)
-   --active-domains=<list>       List of domains in profiling session (for Xen)
-                                 (list contains domain ids separated by commas)
+   --xen=file                    Xen image (for Xen only)
+   --active-domains=id[,ids]     list of domains in multiple domain profiling session (Xen)
+                                 (detailed profiling of user level and kernel modules code)
+                                 (requires running oprofile on these domains)
+   --passive-domains=id[,ids]    list of domains to be profiled (Xen).
+     or --domains=id[,ids]       (coarse profiling of user level and kernel modules code)
+                                 (no need to run oprofile on these domains)
+   --passive-images=file[,files] list of kernel images associated with each passive domain
+     or 
+   --domain-images=file[,files]
 EOF
 }
 
@@ -388,6 +395,9 @@ do_init()
 	SETUP_FILE="$SETUP_DIR/daemonrc"
 	SEC_SETUP_FILE="$SETUP_DIR/daemonrc_new"
 
+	# location for passing info about passive domains to daemon
+	PASSIVE_SETUP_FILE="$SETUP_DIR/xendomain.setup"
+
 	# initialize daemon vars
 	decide_oprofile_device_mount
 	CPUTYPE=`cat $MOUNT/cpu_type`
@@ -539,7 +549,7 @@ do_load_setup()
 }
 
 
-check_valid_args()
+check_valid_vmlinux()
 {
 	if test -z "$VMLINUX"; then
 		echo "No vmlinux file specified. You must specify the correct vmlinux file, e.g." >&2
@@ -560,8 +570,12 @@ check_valid_args()
 
 	echo "The specified vmlinux file \"$VMLINUX\" doesn't exist." >&2
 	exit 1
+}
+
 
 # similar check for Xen image
+check_valid_xen()
+{
 	if test -f "$XENIMAGE"; then
 		return
 	fi
@@ -622,6 +636,77 @@ get_image_range()
 }
 
 
+set_passive_domain()
+{
+	DOMAIN_ID=$1
+	FILE_IMAGE=$2
+	XEN_IMAGE=$3
+
+	if test "$FILE_IMAGE" = "none"; then
+		RANGE="0,0"
+		FILE_IMAGE="domain$DOMAIN_ID-kernel"
+	else
+		# Find VMA range for passive domain kernel image 
+		range_info=`objdump -h $FILE_IMAGE 2>/dev/null | grep " .text "`
+		tmp1=`echo $range_info | awk '{print $4}'`	
+		tmp_length=`echo $range_info | awk  '{print $3}'`
+		tmp2=`objdump -h $FILE_IMAGE --adjust-vma=0x$tmp_length 2>/dev/null | grep " .text " | awk  '{print $4}'`
+
+		if test -z "$tmp1" -o -z "$tmp2"; then
+			echo "The specified file $FILE_IMAGE does not seem to be valid" >&2
+			echo "Make sure you are using the non-compressed image file (e.g. vmlinux not vmlinuz)" >&2
+			vecho "found start as \"$tmp1\", end as \"$tmp2\"" >&2
+			exit 1
+		fi
+		RANGE="`echo $tmp1`,`echo $tmp2`"
+	fi
+	echo " $DOMAIN_ID $FILE_IMAGE $RANGE $XEN_IMAGE" >> $PASSIVE_SETUP_FILE
+}
+
+
+set_passive_domain_config()
+{
+
+	create_dir "$SETUP_DIR"
+
+	touch $PASSIVE_SETUP_FILE
+	chmod 644 $PASSIVE_SETUP_FILE
+	>$PASSIVE_SETUP_FILE
+
+	NDOMAINS=`echo "$PASSIVE_DOMAINS" | awk -F',' '{print NF}'`
+
+	if test -n "$PASSIVE_IMAGES"; then
+		NIMAGES=`echo "$PASSIVE_IMAGES" | awk -F',' '{print NF}'`
+		if [ $NDOMAINS != $NIMAGES ]; then
+			echo "# of passive domains and # of passive images doesn't match." >&2
+			do_help
+			exit 1
+		fi
+
+		for (( i=1; i<=$NDOMAINS; i++ )); do
+			ID=`echo "$PASSIVE_DOMAINS" | awk -F"," '{print $'$i'}'`
+			FILE=`echo "$PASSIVE_IMAGES" | awk -F',' '{print $'$i'}'`
+			if test ! -f "$FILE"; then
+				echo "Image $FILE for passive domain $ID not found." >&2
+				return 1
+			fi
+			LNK_KERNEL=/boot/domain$ID-kernel
+			ln -sf $FILE $LNK_KERNEL
+			LNK_XEN=/boot/domain$ID-xen
+			ln -sf $XENIMAGE $LNK_XEN
+			set_passive_domain $ID $LNK_KERNEL $LNK_XEN 
+		done
+	else
+			for (( i=1; i<=$NDOMAINS; i++ )); do
+				ID=`echo "$PASSIVE_DOMAINS" | awk -F"," '{print $'$i'}'`
+				LNK_XEN=/boot/domain$ID-xen
+				set_passive_domain $ID none $LNK_XEN
+		done 
+
+	fi
+}
+
+  
 # validate --separate= parameters. This function is called with IFS=,
 # so on each argument is splitted
 validate_separate_args()
@@ -932,10 +1017,20 @@ do_options()
 				DO_SETUP=yes
 				;;
 			--active-domains)
-				error_if_invalid_arg $arg $val
+				error_if_invalid_arg "$arg" "$val"
 				ACTIVE_DOMAINS=$val
 				DO_SETUP=yes
 				;;
+			--passive-domains|--domains)
+				error_if_invalid_arg "$arg" "$val"
+				PASSIVE_DOMAINS=$val
+				DO_SETUP=yes
+				;;
+			--passive-images|--domain-images)
+				error_if_invalid_arg "$arg" "$val"
+				PASSIVE_IMAGES=$val
+				DO_SETUP=yes
+				;;
 			--note-table-size)
 				if test "$KERNEL_SUPPORT" = "yes"; then
 					echo "\"$arg\" meaningless on this kernel" >&2
@@ -1366,6 +1461,16 @@ check_event_mapping_data()
 			exit 1
 		fi
 	fi
+
+	if test -n "$ACTIVE_DOMAINS" -a "$START_DAEMON" != "yes"; then
+		echo "Option \"--active-domains\" can only be used with option \"-start-daemon\"." >&2
+		exit 1
+	fi
+
+	if test -n "$PASSIVE_DOMAINS" -a "$START_DAEMON" != "yes" -a "$START" != "yes"; then
+		echo "Option \"--passive-domains\" or "--domains" can only be used with option \"--start-daemon\" or \"--start\"." >&2
+		exit 1
+	fi
 }
 
 
@@ -1404,6 +1509,15 @@ do_param_setup()
 		fi
 	fi
 
+	if test -n "$PASSIVE_DOMAINS"; then
+		if test "$KERNEL_SUPPORT" = "yes"; then
+			echo $PASSIVE_DOMAINS >$MOUNT/passive_domains
+			set_passive_domain_config
+		else
+			echo "passive-domains not supported - ignored" >&2
+		fi
+	fi
+	
 	if test $NOTE_SIZE != 0; then
 		set_param notesize $NOTE_SIZE
 	fi
@@ -1566,7 +1680,8 @@ do_start_daemon()
 	fi
 
 	do_setup
-	check_valid_args
+ 	check_valid_vmlinux
+ 	check_valid_xen
 	get_image_range "linux"
 	get_image_range "xen"
 	do_param_setup
@@ -1600,6 +1715,10 @@ do_start_daemon()
 		OPD_ARGS="$OPD_ARGS --image=$IMAGE_FILTER"
 	fi
 
+	if ! test -z "$PASSIVE_DOMAINS"; then
+		OPD_ARGS="$OPD_ARGS --xen-passive-setup=$PASSIVE_SETUP_FILE"
+	fi
+
 	if test -n "$VERBOSE"; then
 		OPD_ARGS="$OPD_ARGS --verbose=$VERBOSE"
 	fi
@@ -1805,6 +1924,8 @@ do_save_session()
 	fi
 
 	hup_daemon
+
+	rm -f /boot/domain-*-kernel /boot/domain-*-xen
 }
 
 
@@ -1855,7 +1976,8 @@ do_operations()
 	fi
 
 	if test "$SETUP" = "yes"; then
-		check_valid_args
+		check_valid_vmlinux
+		check_valid_xen
 		do_save_setup
 	fi
 

--------------040805060702070905020204
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040805060702070905020204--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 22:11:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 22:11:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV9P5-00077c-Gy; Mon, 28 Nov 2011 22:10:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <wcohen@redhat.com>) id 1RV9P3-000773-Ma
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 22:10:22 +0000
X-Env-Sender: wcohen@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322518183!6173331!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU2MzY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23729 invoked from network); 28 Nov 2011 22:09:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	28 Nov 2011 22:09:44 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pASM9ZZ9018633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 28 Nov 2011 17:09:35 -0500
Received: from [10.11.231.236] (deploy7.rdu.redhat.com [10.11.231.236])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pASM9YQ1022937; Mon, 28 Nov 2011 17:09:34 -0500
Message-ID: <4ED4069E.7030307@redhat.com>
Date: Mon, 28 Nov 2011 17:09:34 -0500
From: William Cohen <wcohen@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1
	Thunderbird/3.1.16
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary="------------040805060702070905020204"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------040805060702070905020204
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 

I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?

-Will

--------------040805060702070905020204
Content-Type: text/x-patch;
 name="oprofile-0.9.7-xen.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="oprofile-0.9.7-xen.patch"

diff -up oprofile-0.9.7/daemon/init.c.xen oprofile-0.9.7/daemon/init.c
--- oprofile-0.9.7/daemon/init.c.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/init.c	2011-11-28 16:25:07.577000010 -0500
@@ -312,6 +312,8 @@ static void opd_26_init(void)
 
 	opd_create_vmlinux(vmlinux, kernel_range);
 	opd_create_xen(xenimage, xen_range);
+	if (xen_passive_setup)
+		opd_create_passive(xen_passive_setup);
 
 	opd_buf_size = opd_read_fs_int("/dev/oprofile/", "buffer_size", 1);
 	kernel_pointer_size = opd_read_fs_int("/dev/oprofile/", "pointer_size", 1);
diff -up oprofile-0.9.7/daemon/opd_kernel.c.xen oprofile-0.9.7/daemon/opd_kernel.c
--- oprofile-0.9.7/daemon/opd_kernel.c.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/opd_kernel.c	2011-11-28 16:25:07.579000010 -0500
@@ -34,11 +34,22 @@ static struct kernel_image vmlinux_image
 
 static struct kernel_image xen_image;
 
+static struct kernel_image xen_image_anon;
+static struct kernel_image vmlinux_image_anon;
+
+static LIST_HEAD(passive_vmlinux);
+static LIST_HEAD(passive_xen);
+static LIST_HEAD(passive_apps);
+static LIST_HEAD(passive_modules);
+static LIST_HEAD(passive_xen_anon);
+
 void opd_create_vmlinux(char const * name, char const * arg)
 {
 	/* vmlinux is *not* on the list of modules */
 	list_init(&vmlinux_image.list);
 
+	list_init(&vmlinux_image_anon.list);
+
 	/* for no vmlinux */
 	if (no_vmlinux) {
 		vmlinux_image.name = "no-vmlinux";
@@ -57,13 +68,22 @@ void opd_create_vmlinux(char const * nam
 		        vmlinux_image.start, vmlinux_image.end);
 		exit(EXIT_FAILURE);
 	}
+
+	vmlinux_image_anon.name  = "vmlinux-unknown";
+	vmlinux_image_anon.start = vmlinux_image.start;
+	vmlinux_image_anon.end   = vmlinux_image.end;
+
 }
 
 void opd_create_xen(char const * name, char const * arg)
 {
+	int stat;
+
 	/* xen is *not* on the list of modules */
 	list_init(&xen_image.list);
 
+	list_init(&xen_image_anon.list);
+
 	/* for no xen */
 	if (no_xen) {
 		xen_image.name = "no-xen";
@@ -72,18 +92,106 @@ void opd_create_xen(char const * name, c
 
 	xen_image.name = xstrdup(name);
 
-	sscanf(arg, "%llx,%llx", &xen_image.start, &xen_image.end);
+	stat = sscanf(arg, "%llx,%llx", &xen_image.start, &xen_image.end);
+
+	xen_image_anon.name  = "xen-unknown";
+	xen_image_anon.start = xen_image.start;
+	xen_image_anon.end   = xen_image.end;
 
 	verbprintf(vmisc, "xen_start = %llx, xen_end = %llx\n",
 	           xen_image.start, xen_image.end);
 
-	if (!xen_image.start && !xen_image.end) {
+	if ( stat != 2 ) {
 		fprintf(stderr, "error: mis-parsed xen range: %llx-%llx\n",
 		        xen_image.start, xen_image.end);
 		exit(EXIT_FAILURE);
 	}
+
 }
 
+void opd_create_passive_domain(int id, char const * image_kernel, 
+			       char const * range, char const * image_xen)
+{
+	char file[64];
+	struct kernel_image * image;
+	int stat;
+
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(image_kernel);
+	image->start = image->end = 0; 
+	stat = sscanf(range, "%llx,%llx", &image->start, &image->end);
+	image->id = id;
+	list_add(&image->list, &passive_vmlinux);
+	
+	if ( stat != 2 ) {
+		fprintf(stderr, "error: mis-parsed passive domain range for "
+			"domain %d: %llx-%llx\n", id, image->start, image->end);
+		exit(EXIT_FAILURE);
+	}
+
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(image_xen);
+	image->start = xen_image.start;
+	image->end = xen_image.end;
+	image->id = id;
+	list_add(&image->list, &passive_xen);
+
+	sprintf(file, "domain%d-apps", id);
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(file);
+	image->start = 0; 
+	image->end = 0;
+	image->id = id;
+	list_add(&image->list, &passive_apps);
+
+	sprintf(file, "domain%d-modules", id);
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(file);
+	image->start = 0; 
+	image->end = 0;
+	stat = sscanf(range, "%llx,%llx", &image->start, &image->end);
+	image->id = id;
+	list_add(&image->list, &passive_modules);
+
+	sprintf(file, "domain%d-xen-unknown", id);
+	image = xmalloc(sizeof(struct kernel_image));
+	image->name = xstrdup(file);
+	image->start = xen_image.start; 
+	image->end = xen_image.end;
+	image->id = id;
+	list_add(&image->list, &passive_xen_anon);
+
+}
+
+void opd_create_passive(char const *setup_file)
+{
+	FILE *fp;
+	int id=0;
+	char image_kernel[128+1];
+	char range[128+1];
+	char image_xen[128+1];
+	int stat;
+
+	image_kernel[0] = range[0] = image_xen[0] = 0;
+
+	fp = fopen(setup_file, "r");
+
+	if (!fp) {
+		fprintf(stderr, "error: Could not open Xen passive domain "
+			"setup file %s\n", setup_file);
+		exit(EXIT_FAILURE);
+	}
+
+	while (1) {
+		stat = fscanf(fp, "%d %128s %128s %128s", &id, image_kernel, range, 
+			image_xen);
+		if ( stat != 4 )
+			return;
+		opd_create_passive_domain(id, image_kernel, range, image_xen);
+	}
+
+	fclose(fp);
+}
 
 /**
  * Allocate and initialise a kernel image description
@@ -210,6 +318,75 @@ struct kernel_image * find_kernel_image(
 	struct list_head * pos;
 	struct kernel_image * image = &vmlinux_image;
 
+	if (current_domain != COORDINATOR_DOMAIN) {
+		/* we rely on cpu_mode value (i.e. trans->in_kernel)
+		 * to search the right image type: xen, kernel or user
+		 * We cannot use address ranges since hypervisor does not
+		 * share the same address space with fully virtualized guests,
+		 * and thus address ranges can overlap  */
+		switch ( trans->in_kernel ) {
+
+		/* user mode */
+		case 1:
+			list_for_each(pos, &passive_apps) {
+				image = list_entry(pos, struct kernel_image, list);
+				if (image->id == current_domain) 
+					return image;
+			}
+			return NULL;
+
+		/* kernel mode */
+		case 2:
+			list_for_each(pos, &passive_vmlinux) {
+				image = list_entry(pos, struct kernel_image, list);
+				if ( (image->id == current_domain)
+				     && ( (image->start == 0 && image->end == 0)
+					  || (image->start <= trans->pc 
+					      && image->end > trans->pc) ) )
+						return image;
+			}
+			/* if not in kernel image range then it should be a module */ 
+			list_for_each(pos, &passive_modules) {
+				image = list_entry(pos, struct kernel_image, list);
+				if (image->id == current_domain) 
+					return image;
+			}
+			/* This should not happen if the kernel and user level 
+                           oprofile code are sane and in sync */
+			return NULL;
+
+		/* hypervisor mode */
+		case 3:
+			list_for_each(pos, &passive_xen) {
+				image = list_entry(pos, struct kernel_image, list);
+				if (image->id == current_domain
+				    && image->start <= trans->pc 
+				    && image->end > trans->pc) 
+					return image;
+			}
+			list_for_each(pos, &passive_xen_anon) {
+				image = list_entry(pos, struct kernel_image, list);
+				if (image->id == current_domain)
+					return image;
+			}
+			return NULL;
+
+		default:
+			printf("Unexpected error on passive mode: CPU mode is "
+			       "%d for domain %d\n", trans->in_kernel, current_domain);
+			return NULL;
+		}
+		
+		
+	}
+
+	if (xen_image.start <= trans->pc && xen_image.end > trans->pc)
+		return &xen_image;
+ 
+	if (trans->in_kernel == 2) {
+		return &xen_image_anon;
+	}
+
 	if (no_vmlinux)
 		return image;
 
@@ -222,8 +399,5 @@ struct kernel_image * find_kernel_image(
 			return image;
 	}
 
-	if (xen_image.start <= trans->pc && xen_image.end > trans->pc)
-		return &xen_image;
-
-	return NULL;
+	return &vmlinux_image_anon;
 }
diff -up oprofile-0.9.7/daemon/opd_kernel.h.xen oprofile-0.9.7/daemon/opd_kernel.h
--- oprofile-0.9.7/daemon/opd_kernel.h.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/opd_kernel.h	2011-11-28 16:25:07.580000010 -0500
@@ -23,8 +23,12 @@ struct transient;
 /** create the kernel image */
 void opd_create_vmlinux(char const * name, char const * arg);
 
+/** create Xen image */
 void opd_create_xen(char const * name, char const * arg);
 
+/** create Xen passive domain images */
+void opd_create_passive(char const *setup_file);
+
 /** opd_reread_module_info - parse /proc/modules for kernel modules */
 void opd_reread_module_info(void);
 
@@ -33,6 +37,7 @@ struct kernel_image {
 	char * name;
 	vma_t start;
 	vma_t end;
+	int id;
 	struct list_head list;
 };
 
diff -up oprofile-0.9.7/daemon/opd_sfile.c.xen oprofile-0.9.7/daemon/opd_sfile.c
--- oprofile-0.9.7/daemon/opd_sfile.c.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/opd_sfile.c	2011-11-28 16:25:07.582000010 -0500
@@ -240,7 +240,7 @@ struct sfile * sfile_find(struct transie
 	}
 
 	/* we might need a kernel image start/end to hash on */
-	if (trans->in_kernel) {
+	else if (trans->in_kernel) {
 		ki = find_kernel_image(trans);
 		if (!ki) {
 			verbprintf(vsamples, "Lost kernel sample %llx\n", trans->pc);
diff -up oprofile-0.9.7/daemon/opd_trans.c.xen oprofile-0.9.7/daemon/opd_trans.c
--- oprofile-0.9.7/daemon/opd_trans.c.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/opd_trans.c	2011-11-28 16:25:07.584000010 -0500
@@ -31,6 +31,8 @@
 #include <stdio.h>
 #include <errno.h>
 
+int32_t current_domain = COORDINATOR_DOMAIN;
+
 extern size_t kernel_pointer_size;
 
 
@@ -203,6 +205,9 @@ static void code_kernel_enter(struct tra
 {
 	verbprintf(vmisc, "KERNEL_ENTER_SWITCH to kernel\n");
 	trans->in_kernel = 1;
+	/* if in passive domain mode cpu mode should be incremented */
+	if (current_domain != COORDINATOR_DOMAIN)
+		trans->in_kernel++;
 	clear_trans_current(trans);
 	/* subtlety: we must keep trans->cookie cached,
 	 * even though it's meaningless for the kernel -
@@ -216,6 +221,9 @@ static void code_user_enter(struct trans
 {
 	verbprintf(vmisc, "USER_ENTER_SWITCH to user-space\n");
 	trans->in_kernel = 0;
+	/* if in passive domain mode cpu mode should be incremented */
+	if (current_domain != COORDINATOR_DOMAIN)
+		trans->in_kernel++;
 	clear_trans_current(trans);
 	clear_trans_last(trans);
 }
@@ -244,17 +252,34 @@ static void code_trace_begin(struct tran
 static void code_xen_enter(struct transient * trans)
 {
 	verbprintf(vmisc, "XEN_ENTER_SWITCH to xen\n");
-	trans->in_kernel = 1;
+	trans->in_kernel = 2;
+	/* if in passive domain mode cpu mode should be incremented */
+	if (current_domain != COORDINATOR_DOMAIN)
+		trans->in_kernel++;
 	trans->current = NULL;
 	/* subtlety: we must keep trans->cookie cached, even though it's
-	 * meaningless for Xen - we won't necessarily get a cookie switch
-	 * on Xen exit. See comments in opd_sfile.c. It seems that we can
-	 * get away with in_kernel = 1 as long as we supply the correct
-	 * Xen image, and its address range in startup find_kernel_image
-	 * is modified to look in the Xen image also
-	 */
+	 * meaningless for Xen - same reason as for kernel */
 }
 
+static void code_domain_switch(struct transient *trans)
+{
+	/* While processing passive domain samples we ensure (in_kernel!=0)
+	 * We do this in order to ignore cookies for passive domain samples 
+	 * But, we have to remember the kernel value for coordinator domain, 
+	 * so we do the safe thing: increment when leaving the coordinator
+	 * domain and decrement when returning to it 
+ 	 */
+	if (current_domain == COORDINATOR_DOMAIN)
+		trans->in_kernel++;
+
+	trans->current = NULL;
+	current_domain = (int32_t) pop_buffer_value(trans);
+
+	/* If returning to coordinator domain restore the kernel value */
+	if (current_domain == COORDINATOR_DOMAIN)
+		trans->in_kernel--;
+}
+ 
 extern void code_spu_profiling(struct transient * trans);
 extern void code_spu_ctx_switch(struct transient * trans);
 
@@ -278,7 +303,7 @@ handler_t handlers[LAST_CODE + 1] = {
 	&code_spu_profiling,
 	&code_spu_ctx_switch,
 #else
-	&code_unknown,
+ 	&code_domain_switch,
 	&code_unknown,
 #endif
 	&code_ibs_fetch_sample,
diff -up oprofile-0.9.7/daemon/opd_trans.h.xen oprofile-0.9.7/daemon/opd_trans.h
--- oprofile-0.9.7/daemon/opd_trans.h.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/opd_trans.h	2011-11-28 16:25:07.585000010 -0500
@@ -21,6 +21,10 @@
 
 #include <stdint.h>
 
+#define COORDINATOR_DOMAIN -1
+
+extern int32_t current_domain;
+
 struct sfile;
 struct anon_mapping;
 
diff -up oprofile-0.9.7/daemon/oprofiled.c.xen oprofile-0.9.7/daemon/oprofiled.c
--- oprofile-0.9.7/daemon/oprofiled.c.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/oprofiled.c	2011-11-28 16:25:07.587000010 -0500
@@ -71,6 +71,7 @@ char * session_dir;
 int no_xen;
 char * xenimage;
 char * xen_range;
+char * xen_passive_setup;
 static char * verbose;
 static char * binary_name_filter;
 static char * events;
@@ -91,6 +92,7 @@ static struct poptOption options[] = {
 	{ "xen-range", 0, POPT_ARG_STRING, &xen_range, 0, "Xen VMA range", "start-end", },
 	{ "xen-image", 0, POPT_ARG_STRING, &xenimage, 0, "Xen image", "file", },
 	{ "image", 0, POPT_ARG_STRING, &binary_name_filter, 0, "image name filter", "profile these comma separated image" },
+	{ "xen-passive-setup", 0, POPT_ARG_STRING, &xen_passive_setup, 0, "Xen passive domain setup file", "filename", },
 	{ "separate-lib", 0, POPT_ARG_INT, &separate_lib, 0, "separate library samples for each distinct application", "[0|1]", },
 	{ "separate-kernel", 0, POPT_ARG_INT, &separate_kernel, 0, "separate kernel samples for each distinct application", "[0|1]", },
 	{ "separate-thread", 0, POPT_ARG_INT, &separate_thread, 0, "thread-profiling mode", "[0|1]" },
diff -up oprofile-0.9.7/daemon/oprofiled.h.xen oprofile-0.9.7/daemon/oprofiled.h
--- oprofile-0.9.7/daemon/oprofiled.h.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/daemon/oprofiled.h	2011-11-28 16:25:07.588000010 -0500
@@ -65,5 +65,6 @@ extern char * kernel_range;
 extern int no_xen;
 extern char * xenimage;
 extern char * xen_range;
+extern char * xen_passive_setup;
 
 #endif /* OPROFILED_H */
diff -up oprofile-0.9.7/doc/opcontrol.1.in.xen oprofile-0.9.7/doc/opcontrol.1.in
--- oprofile-0.9.7/doc/opcontrol.1.in.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/doc/opcontrol.1.in	2011-11-28 16:25:07.590000010 -0500
@@ -158,12 +158,41 @@ Xen image
 .br
 .TP
 .BI "--active-domains="<list>
-List of domain ids participating in a multi-domain profiling session. If 
+List of domain ids participating in a multi-domain profiling session. 
+Each of the specified domains must run an instance of oprofile. The 
+sequence of opcontrol commands in each domain must follow a given 
+order which is specified in the oprofile user manual. If 
 more than one domain is specified in <list> they should be separated using 
 commas. This option can only be used in domain 0 which is the only domain 
 that can coordinate a multi-domain profiling session. Including domain 0 in 
 the list of active domains is optional. (e.g. --active-domains=2,5,6 and 
---active-domains=0,2,5,6 are equivalent)
+--active-domains=0,2,5,6 are equivalent).
+This option can only be specified
+if --start-daemon is also specified and it is only 
+valid for the current run of the oprofile daemon; e.g. the list 
+of active domains is not persistent.
+.br
+.TP
+.BI "--passive-domains="<list> or "--domains="<list>
+List of domain ids to be profiled, separated by commas. 
+As opposed to the --active-domains option, the domains specified with this
+option do not need to run oprofile. This makes 
+profiling multiple domains easier. However, with the passive-domains option, 
+samples in user level processes and kernel modules cannot be 
+mapped to specific symbols and are aggregated
+under a generic class. Both --active-domains and --passive-domains 
+options can be specified in the same command, but the same domain cannot be
+specified in both options. This option can only be specified if either --start
+or --start-daemon is specified on the same command and it is only valid for 
+the current run of the oprofile daemon; e.g. the list of passive domains is 
+not persistent.
+.br
+.TP
+.BI "--passive-images="<list> or "--domains-images="<list>
+List of kernel images associated with the domains specified in the
+--passive-domains option, also separated by commas. The association
+between the images and domains is based on the order they are
+specified in both options.
 .br
 
 .SH ENVIRONMENT
diff -up oprofile-0.9.7/libpp/format_output.cpp.xen oprofile-0.9.7/libpp/format_output.cpp
--- oprofile-0.9.7/libpp/format_output.cpp.xen	2011-07-04 22:25:04.000000000 -0400
+++ oprofile-0.9.7/libpp/format_output.cpp	2011-11-28 16:25:07.592000010 -0500
@@ -287,8 +287,8 @@ string formatter::format_app_name(field_
 {
 	return get_image_name(f.symbol.app_name,
 		long_filenames 
-			? image_name_storage::int_real_filename
-			: image_name_storage::int_real_basename,
+			? image_name_storage::int_filename
+			: image_name_storage::int_basename,
 		extra_found_images);
 }
 
diff -up oprofile-0.9.7/utils/opcontrol.xen oprofile-0.9.7/utils/opcontrol
--- oprofile-0.9.7/utils/opcontrol.xen	2011-07-20 15:36:48.000000000 -0400
+++ oprofile-0.9.7/utils/opcontrol	2011-11-28 16:28:56.431000248 -0500
@@ -236,9 +236,16 @@ opcontrol: usage:
    --note-table-size             kernel notes buffer size in notes units (2.4
                                  kernel)
 
-   --xen                         Xen image (for Xen only)
-   --active-domains=<list>       List of domains in profiling session (for Xen)
-                                 (list contains domain ids separated by commas)
+   --xen=file                    Xen image (for Xen only)
+   --active-domains=id[,ids]     list of domains in multiple domain profiling session (Xen)
+                                 (detailed profiling of user level and kernel modules code)
+                                 (requires running oprofile on these domains)
+   --passive-domains=id[,ids]    list of domains to be profiled (Xen).
+     or --domains=id[,ids]       (coarse profiling of user level and kernel modules code)
+                                 (no need to run oprofile on these domains)
+   --passive-images=file[,files] list of kernel images associated with each passive domain
+     or 
+   --domain-images=file[,files]
 EOF
 }
 
@@ -388,6 +395,9 @@ do_init()
 	SETUP_FILE="$SETUP_DIR/daemonrc"
 	SEC_SETUP_FILE="$SETUP_DIR/daemonrc_new"
 
+	# location for passing info about passive domains to daemon
+	PASSIVE_SETUP_FILE="$SETUP_DIR/xendomain.setup"
+
 	# initialize daemon vars
 	decide_oprofile_device_mount
 	CPUTYPE=`cat $MOUNT/cpu_type`
@@ -539,7 +549,7 @@ do_load_setup()
 }
 
 
-check_valid_args()
+check_valid_vmlinux()
 {
 	if test -z "$VMLINUX"; then
 		echo "No vmlinux file specified. You must specify the correct vmlinux file, e.g." >&2
@@ -560,8 +570,12 @@ check_valid_args()
 
 	echo "The specified vmlinux file \"$VMLINUX\" doesn't exist." >&2
 	exit 1
+}
+
 
 # similar check for Xen image
+check_valid_xen()
+{
 	if test -f "$XENIMAGE"; then
 		return
 	fi
@@ -622,6 +636,77 @@ get_image_range()
 }
 
 
+set_passive_domain()
+{
+	DOMAIN_ID=$1
+	FILE_IMAGE=$2
+	XEN_IMAGE=$3
+
+	if test "$FILE_IMAGE" = "none"; then
+		RANGE="0,0"
+		FILE_IMAGE="domain$DOMAIN_ID-kernel"
+	else
+		# Find VMA range for passive domain kernel image 
+		range_info=`objdump -h $FILE_IMAGE 2>/dev/null | grep " .text "`
+		tmp1=`echo $range_info | awk '{print $4}'`	
+		tmp_length=`echo $range_info | awk  '{print $3}'`
+		tmp2=`objdump -h $FILE_IMAGE --adjust-vma=0x$tmp_length 2>/dev/null | grep " .text " | awk  '{print $4}'`
+
+		if test -z "$tmp1" -o -z "$tmp2"; then
+			echo "The specified file $FILE_IMAGE does not seem to be valid" >&2
+			echo "Make sure you are using the non-compressed image file (e.g. vmlinux not vmlinuz)" >&2
+			vecho "found start as \"$tmp1\", end as \"$tmp2\"" >&2
+			exit 1
+		fi
+		RANGE="`echo $tmp1`,`echo $tmp2`"
+	fi
+	echo " $DOMAIN_ID $FILE_IMAGE $RANGE $XEN_IMAGE" >> $PASSIVE_SETUP_FILE
+}
+
+
+set_passive_domain_config()
+{
+
+	create_dir "$SETUP_DIR"
+
+	touch $PASSIVE_SETUP_FILE
+	chmod 644 $PASSIVE_SETUP_FILE
+	>$PASSIVE_SETUP_FILE
+
+	NDOMAINS=`echo "$PASSIVE_DOMAINS" | awk -F',' '{print NF}'`
+
+	if test -n "$PASSIVE_IMAGES"; then
+		NIMAGES=`echo "$PASSIVE_IMAGES" | awk -F',' '{print NF}'`
+		if [ $NDOMAINS != $NIMAGES ]; then
+			echo "# of passive domains and # of passive images doesn't match." >&2
+			do_help
+			exit 1
+		fi
+
+		for (( i=1; i<=$NDOMAINS; i++ )); do
+			ID=`echo "$PASSIVE_DOMAINS" | awk -F"," '{print $'$i'}'`
+			FILE=`echo "$PASSIVE_IMAGES" | awk -F',' '{print $'$i'}'`
+			if test ! -f "$FILE"; then
+				echo "Image $FILE for passive domain $ID not found." >&2
+				return 1
+			fi
+			LNK_KERNEL=/boot/domain$ID-kernel
+			ln -sf $FILE $LNK_KERNEL
+			LNK_XEN=/boot/domain$ID-xen
+			ln -sf $XENIMAGE $LNK_XEN
+			set_passive_domain $ID $LNK_KERNEL $LNK_XEN 
+		done
+	else
+			for (( i=1; i<=$NDOMAINS; i++ )); do
+				ID=`echo "$PASSIVE_DOMAINS" | awk -F"," '{print $'$i'}'`
+				LNK_XEN=/boot/domain$ID-xen
+				set_passive_domain $ID none $LNK_XEN
+		done 
+
+	fi
+}
+
+  
 # validate --separate= parameters. This function is called with IFS=,
 # so on each argument is splitted
 validate_separate_args()
@@ -932,10 +1017,20 @@ do_options()
 				DO_SETUP=yes
 				;;
 			--active-domains)
-				error_if_invalid_arg $arg $val
+				error_if_invalid_arg "$arg" "$val"
 				ACTIVE_DOMAINS=$val
 				DO_SETUP=yes
 				;;
+			--passive-domains|--domains)
+				error_if_invalid_arg "$arg" "$val"
+				PASSIVE_DOMAINS=$val
+				DO_SETUP=yes
+				;;
+			--passive-images|--domain-images)
+				error_if_invalid_arg "$arg" "$val"
+				PASSIVE_IMAGES=$val
+				DO_SETUP=yes
+				;;
 			--note-table-size)
 				if test "$KERNEL_SUPPORT" = "yes"; then
 					echo "\"$arg\" meaningless on this kernel" >&2
@@ -1366,6 +1461,16 @@ check_event_mapping_data()
 			exit 1
 		fi
 	fi
+
+	if test -n "$ACTIVE_DOMAINS" -a "$START_DAEMON" != "yes"; then
+		echo "Option \"--active-domains\" can only be used with option \"-start-daemon\"." >&2
+		exit 1
+	fi
+
+	if test -n "$PASSIVE_DOMAINS" -a "$START_DAEMON" != "yes" -a "$START" != "yes"; then
+		echo "Option \"--passive-domains\" or "--domains" can only be used with option \"--start-daemon\" or \"--start\"." >&2
+		exit 1
+	fi
 }
 
 
@@ -1404,6 +1509,15 @@ do_param_setup()
 		fi
 	fi
 
+	if test -n "$PASSIVE_DOMAINS"; then
+		if test "$KERNEL_SUPPORT" = "yes"; then
+			echo $PASSIVE_DOMAINS >$MOUNT/passive_domains
+			set_passive_domain_config
+		else
+			echo "passive-domains not supported - ignored" >&2
+		fi
+	fi
+	
 	if test $NOTE_SIZE != 0; then
 		set_param notesize $NOTE_SIZE
 	fi
@@ -1566,7 +1680,8 @@ do_start_daemon()
 	fi
 
 	do_setup
-	check_valid_args
+ 	check_valid_vmlinux
+ 	check_valid_xen
 	get_image_range "linux"
 	get_image_range "xen"
 	do_param_setup
@@ -1600,6 +1715,10 @@ do_start_daemon()
 		OPD_ARGS="$OPD_ARGS --image=$IMAGE_FILTER"
 	fi
 
+	if ! test -z "$PASSIVE_DOMAINS"; then
+		OPD_ARGS="$OPD_ARGS --xen-passive-setup=$PASSIVE_SETUP_FILE"
+	fi
+
 	if test -n "$VERBOSE"; then
 		OPD_ARGS="$OPD_ARGS --verbose=$VERBOSE"
 	fi
@@ -1805,6 +1924,8 @@ do_save_session()
 	fi
 
 	hup_daemon
+
+	rm -f /boot/domain-*-kernel /boot/domain-*-xen
 }
 
 
@@ -1855,7 +1976,8 @@ do_operations()
 	fi
 
 	if test "$SETUP" = "yes"; then
-		check_valid_args
+		check_valid_vmlinux
+		check_valid_xen
 		do_save_setup
 	fi
 

--------------040805060702070905020204
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040805060702070905020204--


From xen-devel-bounces@lists.xensource.com Mon Nov 28 22:47:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 22:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV9y6-0007dG-0m; Mon, 28 Nov 2011 22:46:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV9y2-0007dB-Ta
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 22:46:31 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322520351!4159623!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23579 invoked from network); 28 Nov 2011 22:45:52 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 22:45:52 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASMjj8T008516
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 17:45:45 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASMjjOd008514;
	Mon, 28 Nov 2011 17:45:45 -0500
Date: Mon, 28 Nov 2011 18:45:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: William Cohen <wcohen@redhat.com>
Message-ID: <20111128224545.GA7821@andromeda.dapyr.net>
References: <4ED4069E.7030307@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED4069E.7030307@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 

There was one posted some time ago.. Ah:
http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz

I think that ones works , thought I haven't had a chance to test it
myself.
> 
> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?

Well, the desire is to get a performance tool in upstream that works
with Xen very very very much.

The upstream is using the 'perf' framework which is different from oprofile
and there hasn't been any patches to take advantage of it.

So to answer your question:
 1). Its awesome you have posted a patch. Will need to spend some time
     with it and and with the version that was posted to see if there is
     something missing. Sadly, the kernel patch is not very
     upstream-compatible as is. But it will get to folks be able to
     do some perf analysis instead of using benchmark tools.

 2). In the future we need to work out the optimal performance tool. It
     might be oprofile or it might be perf (or it might be both?!). Or
     it might something that has not yet been posted?

You wouldn't by any chance be interested in looking at the performance
"stuff" and figure out what is the best route/tools to use with upstream
kernels?

> 
> -Will

> diff -up oprofile-0.9.7/daemon/init.c.xen oprofile-0.9.7/daemon/init.c
> --- oprofile-0.9.7/daemon/init.c.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/init.c	2011-11-28 16:25:07.577000010 -0500
> @@ -312,6 +312,8 @@ static void opd_26_init(void)
>  
>  	opd_create_vmlinux(vmlinux, kernel_range);
>  	opd_create_xen(xenimage, xen_range);
> +	if (xen_passive_setup)
> +		opd_create_passive(xen_passive_setup);
>  
>  	opd_buf_size = opd_read_fs_int("/dev/oprofile/", "buffer_size", 1);
>  	kernel_pointer_size = opd_read_fs_int("/dev/oprofile/", "pointer_size", 1);
> diff -up oprofile-0.9.7/daemon/opd_kernel.c.xen oprofile-0.9.7/daemon/opd_kernel.c
> --- oprofile-0.9.7/daemon/opd_kernel.c.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/opd_kernel.c	2011-11-28 16:25:07.579000010 -0500
> @@ -34,11 +34,22 @@ static struct kernel_image vmlinux_image
>  
>  static struct kernel_image xen_image;
>  
> +static struct kernel_image xen_image_anon;
> +static struct kernel_image vmlinux_image_anon;
> +
> +static LIST_HEAD(passive_vmlinux);
> +static LIST_HEAD(passive_xen);
> +static LIST_HEAD(passive_apps);
> +static LIST_HEAD(passive_modules);
> +static LIST_HEAD(passive_xen_anon);
> +
>  void opd_create_vmlinux(char const * name, char const * arg)
>  {
>  	/* vmlinux is *not* on the list of modules */
>  	list_init(&vmlinux_image.list);
>  
> +	list_init(&vmlinux_image_anon.list);
> +
>  	/* for no vmlinux */
>  	if (no_vmlinux) {
>  		vmlinux_image.name = "no-vmlinux";
> @@ -57,13 +68,22 @@ void opd_create_vmlinux(char const * nam
>  		        vmlinux_image.start, vmlinux_image.end);
>  		exit(EXIT_FAILURE);
>  	}
> +
> +	vmlinux_image_anon.name  = "vmlinux-unknown";
> +	vmlinux_image_anon.start = vmlinux_image.start;
> +	vmlinux_image_anon.end   = vmlinux_image.end;
> +
>  }
>  
>  void opd_create_xen(char const * name, char const * arg)
>  {
> +	int stat;
> +
>  	/* xen is *not* on the list of modules */
>  	list_init(&xen_image.list);
>  
> +	list_init(&xen_image_anon.list);
> +
>  	/* for no xen */
>  	if (no_xen) {
>  		xen_image.name = "no-xen";
> @@ -72,18 +92,106 @@ void opd_create_xen(char const * name, c
>  
>  	xen_image.name = xstrdup(name);
>  
> -	sscanf(arg, "%llx,%llx", &xen_image.start, &xen_image.end);
> +	stat = sscanf(arg, "%llx,%llx", &xen_image.start, &xen_image.end);
> +
> +	xen_image_anon.name  = "xen-unknown";
> +	xen_image_anon.start = xen_image.start;
> +	xen_image_anon.end   = xen_image.end;
>  
>  	verbprintf(vmisc, "xen_start = %llx, xen_end = %llx\n",
>  	           xen_image.start, xen_image.end);
>  
> -	if (!xen_image.start && !xen_image.end) {
> +	if ( stat != 2 ) {
>  		fprintf(stderr, "error: mis-parsed xen range: %llx-%llx\n",
>  		        xen_image.start, xen_image.end);
>  		exit(EXIT_FAILURE);
>  	}
> +
>  }
>  
> +void opd_create_passive_domain(int id, char const * image_kernel, 
> +			       char const * range, char const * image_xen)
> +{
> +	char file[64];
> +	struct kernel_image * image;
> +	int stat;
> +
> +	image = xmalloc(sizeof(struct kernel_image));
> +	image->name = xstrdup(image_kernel);
> +	image->start = image->end = 0; 
> +	stat = sscanf(range, "%llx,%llx", &image->start, &image->end);
> +	image->id = id;
> +	list_add(&image->list, &passive_vmlinux);
> +	
> +	if ( stat != 2 ) {
> +		fprintf(stderr, "error: mis-parsed passive domain range for "
> +			"domain %d: %llx-%llx\n", id, image->start, image->end);
> +		exit(EXIT_FAILURE);
> +	}
> +
> +	image = xmalloc(sizeof(struct kernel_image));
> +	image->name = xstrdup(image_xen);
> +	image->start = xen_image.start;
> +	image->end = xen_image.end;
> +	image->id = id;
> +	list_add(&image->list, &passive_xen);
> +
> +	sprintf(file, "domain%d-apps", id);
> +	image = xmalloc(sizeof(struct kernel_image));
> +	image->name = xstrdup(file);
> +	image->start = 0; 
> +	image->end = 0;
> +	image->id = id;
> +	list_add(&image->list, &passive_apps);
> +
> +	sprintf(file, "domain%d-modules", id);
> +	image = xmalloc(sizeof(struct kernel_image));
> +	image->name = xstrdup(file);
> +	image->start = 0; 
> +	image->end = 0;
> +	stat = sscanf(range, "%llx,%llx", &image->start, &image->end);
> +	image->id = id;
> +	list_add(&image->list, &passive_modules);
> +
> +	sprintf(file, "domain%d-xen-unknown", id);
> +	image = xmalloc(sizeof(struct kernel_image));
> +	image->name = xstrdup(file);
> +	image->start = xen_image.start; 
> +	image->end = xen_image.end;
> +	image->id = id;
> +	list_add(&image->list, &passive_xen_anon);
> +
> +}
> +
> +void opd_create_passive(char const *setup_file)
> +{
> +	FILE *fp;
> +	int id=0;
> +	char image_kernel[128+1];
> +	char range[128+1];
> +	char image_xen[128+1];
> +	int stat;
> +
> +	image_kernel[0] = range[0] = image_xen[0] = 0;
> +
> +	fp = fopen(setup_file, "r");
> +
> +	if (!fp) {
> +		fprintf(stderr, "error: Could not open Xen passive domain "
> +			"setup file %s\n", setup_file);
> +		exit(EXIT_FAILURE);
> +	}
> +
> +	while (1) {
> +		stat = fscanf(fp, "%d %128s %128s %128s", &id, image_kernel, range, 
> +			image_xen);
> +		if ( stat != 4 )
> +			return;
> +		opd_create_passive_domain(id, image_kernel, range, image_xen);
> +	}
> +
> +	fclose(fp);
> +}
>  
>  /**
>   * Allocate and initialise a kernel image description
> @@ -210,6 +318,75 @@ struct kernel_image * find_kernel_image(
>  	struct list_head * pos;
>  	struct kernel_image * image = &vmlinux_image;
>  
> +	if (current_domain != COORDINATOR_DOMAIN) {
> +		/* we rely on cpu_mode value (i.e. trans->in_kernel)
> +		 * to search the right image type: xen, kernel or user
> +		 * We cannot use address ranges since hypervisor does not
> +		 * share the same address space with fully virtualized guests,
> +		 * and thus address ranges can overlap  */
> +		switch ( trans->in_kernel ) {
> +
> +		/* user mode */
> +		case 1:
> +			list_for_each(pos, &passive_apps) {
> +				image = list_entry(pos, struct kernel_image, list);
> +				if (image->id == current_domain) 
> +					return image;
> +			}
> +			return NULL;
> +
> +		/* kernel mode */
> +		case 2:
> +			list_for_each(pos, &passive_vmlinux) {
> +				image = list_entry(pos, struct kernel_image, list);
> +				if ( (image->id == current_domain)
> +				     && ( (image->start == 0 && image->end == 0)
> +					  || (image->start <= trans->pc 
> +					      && image->end > trans->pc) ) )
> +						return image;
> +			}
> +			/* if not in kernel image range then it should be a module */ 
> +			list_for_each(pos, &passive_modules) {
> +				image = list_entry(pos, struct kernel_image, list);
> +				if (image->id == current_domain) 
> +					return image;
> +			}
> +			/* This should not happen if the kernel and user level 
> +                           oprofile code are sane and in sync */
> +			return NULL;
> +
> +		/* hypervisor mode */
> +		case 3:
> +			list_for_each(pos, &passive_xen) {
> +				image = list_entry(pos, struct kernel_image, list);
> +				if (image->id == current_domain
> +				    && image->start <= trans->pc 
> +				    && image->end > trans->pc) 
> +					return image;
> +			}
> +			list_for_each(pos, &passive_xen_anon) {
> +				image = list_entry(pos, struct kernel_image, list);
> +				if (image->id == current_domain)
> +					return image;
> +			}
> +			return NULL;
> +
> +		default:
> +			printf("Unexpected error on passive mode: CPU mode is "
> +			       "%d for domain %d\n", trans->in_kernel, current_domain);
> +			return NULL;
> +		}
> +		
> +		
> +	}
> +
> +	if (xen_image.start <= trans->pc && xen_image.end > trans->pc)
> +		return &xen_image;
> + 
> +	if (trans->in_kernel == 2) {
> +		return &xen_image_anon;
> +	}
> +
>  	if (no_vmlinux)
>  		return image;
>  
> @@ -222,8 +399,5 @@ struct kernel_image * find_kernel_image(
>  			return image;
>  	}
>  
> -	if (xen_image.start <= trans->pc && xen_image.end > trans->pc)
> -		return &xen_image;
> -
> -	return NULL;
> +	return &vmlinux_image_anon;
>  }
> diff -up oprofile-0.9.7/daemon/opd_kernel.h.xen oprofile-0.9.7/daemon/opd_kernel.h
> --- oprofile-0.9.7/daemon/opd_kernel.h.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/opd_kernel.h	2011-11-28 16:25:07.580000010 -0500
> @@ -23,8 +23,12 @@ struct transient;
>  /** create the kernel image */
>  void opd_create_vmlinux(char const * name, char const * arg);
>  
> +/** create Xen image */
>  void opd_create_xen(char const * name, char const * arg);
>  
> +/** create Xen passive domain images */
> +void opd_create_passive(char const *setup_file);
> +
>  /** opd_reread_module_info - parse /proc/modules for kernel modules */
>  void opd_reread_module_info(void);
>  
> @@ -33,6 +37,7 @@ struct kernel_image {
>  	char * name;
>  	vma_t start;
>  	vma_t end;
> +	int id;
>  	struct list_head list;
>  };
>  
> diff -up oprofile-0.9.7/daemon/opd_sfile.c.xen oprofile-0.9.7/daemon/opd_sfile.c
> --- oprofile-0.9.7/daemon/opd_sfile.c.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/opd_sfile.c	2011-11-28 16:25:07.582000010 -0500
> @@ -240,7 +240,7 @@ struct sfile * sfile_find(struct transie
>  	}
>  
>  	/* we might need a kernel image start/end to hash on */
> -	if (trans->in_kernel) {
> +	else if (trans->in_kernel) {
>  		ki = find_kernel_image(trans);
>  		if (!ki) {
>  			verbprintf(vsamples, "Lost kernel sample %llx\n", trans->pc);
> diff -up oprofile-0.9.7/daemon/opd_trans.c.xen oprofile-0.9.7/daemon/opd_trans.c
> --- oprofile-0.9.7/daemon/opd_trans.c.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/opd_trans.c	2011-11-28 16:25:07.584000010 -0500
> @@ -31,6 +31,8 @@
>  #include <stdio.h>
>  #include <errno.h>
>  
> +int32_t current_domain = COORDINATOR_DOMAIN;
> +
>  extern size_t kernel_pointer_size;
>  
>  
> @@ -203,6 +205,9 @@ static void code_kernel_enter(struct tra
>  {
>  	verbprintf(vmisc, "KERNEL_ENTER_SWITCH to kernel\n");
>  	trans->in_kernel = 1;
> +	/* if in passive domain mode cpu mode should be incremented */
> +	if (current_domain != COORDINATOR_DOMAIN)
> +		trans->in_kernel++;
>  	clear_trans_current(trans);
>  	/* subtlety: we must keep trans->cookie cached,
>  	 * even though it's meaningless for the kernel -
> @@ -216,6 +221,9 @@ static void code_user_enter(struct trans
>  {
>  	verbprintf(vmisc, "USER_ENTER_SWITCH to user-space\n");
>  	trans->in_kernel = 0;
> +	/* if in passive domain mode cpu mode should be incremented */
> +	if (current_domain != COORDINATOR_DOMAIN)
> +		trans->in_kernel++;
>  	clear_trans_current(trans);
>  	clear_trans_last(trans);
>  }
> @@ -244,17 +252,34 @@ static void code_trace_begin(struct tran
>  static void code_xen_enter(struct transient * trans)
>  {
>  	verbprintf(vmisc, "XEN_ENTER_SWITCH to xen\n");
> -	trans->in_kernel = 1;
> +	trans->in_kernel = 2;
> +	/* if in passive domain mode cpu mode should be incremented */
> +	if (current_domain != COORDINATOR_DOMAIN)
> +		trans->in_kernel++;
>  	trans->current = NULL;
>  	/* subtlety: we must keep trans->cookie cached, even though it's
> -	 * meaningless for Xen - we won't necessarily get a cookie switch
> -	 * on Xen exit. See comments in opd_sfile.c. It seems that we can
> -	 * get away with in_kernel = 1 as long as we supply the correct
> -	 * Xen image, and its address range in startup find_kernel_image
> -	 * is modified to look in the Xen image also
> -	 */
> +	 * meaningless for Xen - same reason as for kernel */
>  }
>  
> +static void code_domain_switch(struct transient *trans)
> +{
> +	/* While processing passive domain samples we ensure (in_kernel!=0)
> +	 * We do this in order to ignore cookies for passive domain samples 
> +	 * But, we have to remember the kernel value for coordinator domain, 
> +	 * so we do the safe thing: increment when leaving the coordinator
> +	 * domain and decrement when returning to it 
> + 	 */
> +	if (current_domain == COORDINATOR_DOMAIN)
> +		trans->in_kernel++;
> +
> +	trans->current = NULL;
> +	current_domain = (int32_t) pop_buffer_value(trans);
> +
> +	/* If returning to coordinator domain restore the kernel value */
> +	if (current_domain == COORDINATOR_DOMAIN)
> +		trans->in_kernel--;
> +}
> + 
>  extern void code_spu_profiling(struct transient * trans);
>  extern void code_spu_ctx_switch(struct transient * trans);
>  
> @@ -278,7 +303,7 @@ handler_t handlers[LAST_CODE + 1] = {
>  	&code_spu_profiling,
>  	&code_spu_ctx_switch,
>  #else
> -	&code_unknown,
> + 	&code_domain_switch,
>  	&code_unknown,
>  #endif
>  	&code_ibs_fetch_sample,
> diff -up oprofile-0.9.7/daemon/opd_trans.h.xen oprofile-0.9.7/daemon/opd_trans.h
> --- oprofile-0.9.7/daemon/opd_trans.h.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/opd_trans.h	2011-11-28 16:25:07.585000010 -0500
> @@ -21,6 +21,10 @@
>  
>  #include <stdint.h>
>  
> +#define COORDINATOR_DOMAIN -1
> +
> +extern int32_t current_domain;
> +
>  struct sfile;
>  struct anon_mapping;
>  
> diff -up oprofile-0.9.7/daemon/oprofiled.c.xen oprofile-0.9.7/daemon/oprofiled.c
> --- oprofile-0.9.7/daemon/oprofiled.c.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/oprofiled.c	2011-11-28 16:25:07.587000010 -0500
> @@ -71,6 +71,7 @@ char * session_dir;
>  int no_xen;
>  char * xenimage;
>  char * xen_range;
> +char * xen_passive_setup;
>  static char * verbose;
>  static char * binary_name_filter;
>  static char * events;
> @@ -91,6 +92,7 @@ static struct poptOption options[] = {
>  	{ "xen-range", 0, POPT_ARG_STRING, &xen_range, 0, "Xen VMA range", "start-end", },
>  	{ "xen-image", 0, POPT_ARG_STRING, &xenimage, 0, "Xen image", "file", },
>  	{ "image", 0, POPT_ARG_STRING, &binary_name_filter, 0, "image name filter", "profile these comma separated image" },
> +	{ "xen-passive-setup", 0, POPT_ARG_STRING, &xen_passive_setup, 0, "Xen passive domain setup file", "filename", },
>  	{ "separate-lib", 0, POPT_ARG_INT, &separate_lib, 0, "separate library samples for each distinct application", "[0|1]", },
>  	{ "separate-kernel", 0, POPT_ARG_INT, &separate_kernel, 0, "separate kernel samples for each distinct application", "[0|1]", },
>  	{ "separate-thread", 0, POPT_ARG_INT, &separate_thread, 0, "thread-profiling mode", "[0|1]" },
> diff -up oprofile-0.9.7/daemon/oprofiled.h.xen oprofile-0.9.7/daemon/oprofiled.h
> --- oprofile-0.9.7/daemon/oprofiled.h.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/oprofiled.h	2011-11-28 16:25:07.588000010 -0500
> @@ -65,5 +65,6 @@ extern char * kernel_range;
>  extern int no_xen;
>  extern char * xenimage;
>  extern char * xen_range;
> +extern char * xen_passive_setup;
>  
>  #endif /* OPROFILED_H */
> diff -up oprofile-0.9.7/doc/opcontrol.1.in.xen oprofile-0.9.7/doc/opcontrol.1.in
> --- oprofile-0.9.7/doc/opcontrol.1.in.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/doc/opcontrol.1.in	2011-11-28 16:25:07.590000010 -0500
> @@ -158,12 +158,41 @@ Xen image
>  .br
>  .TP
>  .BI "--active-domains="<list>
> -List of domain ids participating in a multi-domain profiling session. If 
> +List of domain ids participating in a multi-domain profiling session. 
> +Each of the specified domains must run an instance of oprofile. The 
> +sequence of opcontrol commands in each domain must follow a given 
> +order which is specified in the oprofile user manual. If 
>  more than one domain is specified in <list> they should be separated using 
>  commas. This option can only be used in domain 0 which is the only domain 
>  that can coordinate a multi-domain profiling session. Including domain 0 in 
>  the list of active domains is optional. (e.g. --active-domains=2,5,6 and 
> ---active-domains=0,2,5,6 are equivalent)
> +--active-domains=0,2,5,6 are equivalent).
> +This option can only be specified
> +if --start-daemon is also specified and it is only 
> +valid for the current run of the oprofile daemon; e.g. the list 
> +of active domains is not persistent.
> +.br
> +.TP
> +.BI "--passive-domains="<list> or "--domains="<list>
> +List of domain ids to be profiled, separated by commas. 
> +As opposed to the --active-domains option, the domains specified with this
> +option do not need to run oprofile. This makes 
> +profiling multiple domains easier. However, with the passive-domains option, 
> +samples in user level processes and kernel modules cannot be 
> +mapped to specific symbols and are aggregated
> +under a generic class. Both --active-domains and --passive-domains 
> +options can be specified in the same command, but the same domain cannot be
> +specified in both options. This option can only be specified if either --start
> +or --start-daemon is specified on the same command and it is only valid for 
> +the current run of the oprofile daemon; e.g. the list of passive domains is 
> +not persistent.
> +.br
> +.TP
> +.BI "--passive-images="<list> or "--domains-images="<list>
> +List of kernel images associated with the domains specified in the
> +--passive-domains option, also separated by commas. The association
> +between the images and domains is based on the order they are
> +specified in both options.
>  .br
>  
>  .SH ENVIRONMENT
> diff -up oprofile-0.9.7/libpp/format_output.cpp.xen oprofile-0.9.7/libpp/format_output.cpp
> --- oprofile-0.9.7/libpp/format_output.cpp.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/libpp/format_output.cpp	2011-11-28 16:25:07.592000010 -0500
> @@ -287,8 +287,8 @@ string formatter::format_app_name(field_
>  {
>  	return get_image_name(f.symbol.app_name,
>  		long_filenames 
> -			? image_name_storage::int_real_filename
> -			: image_name_storage::int_real_basename,
> +			? image_name_storage::int_filename
> +			: image_name_storage::int_basename,
>  		extra_found_images);
>  }
>  
> diff -up oprofile-0.9.7/utils/opcontrol.xen oprofile-0.9.7/utils/opcontrol
> --- oprofile-0.9.7/utils/opcontrol.xen	2011-07-20 15:36:48.000000000 -0400
> +++ oprofile-0.9.7/utils/opcontrol	2011-11-28 16:28:56.431000248 -0500
> @@ -236,9 +236,16 @@ opcontrol: usage:
>     --note-table-size             kernel notes buffer size in notes units (2.4
>                                   kernel)
>  
> -   --xen                         Xen image (for Xen only)
> -   --active-domains=<list>       List of domains in profiling session (for Xen)
> -                                 (list contains domain ids separated by commas)
> +   --xen=file                    Xen image (for Xen only)
> +   --active-domains=id[,ids]     list of domains in multiple domain profiling session (Xen)
> +                                 (detailed profiling of user level and kernel modules code)
> +                                 (requires running oprofile on these domains)
> +   --passive-domains=id[,ids]    list of domains to be profiled (Xen).
> +     or --domains=id[,ids]       (coarse profiling of user level and kernel modules code)
> +                                 (no need to run oprofile on these domains)
> +   --passive-images=file[,files] list of kernel images associated with each passive domain
> +     or 
> +   --domain-images=file[,files]
>  EOF
>  }
>  
> @@ -388,6 +395,9 @@ do_init()
>  	SETUP_FILE="$SETUP_DIR/daemonrc"
>  	SEC_SETUP_FILE="$SETUP_DIR/daemonrc_new"
>  
> +	# location for passing info about passive domains to daemon
> +	PASSIVE_SETUP_FILE="$SETUP_DIR/xendomain.setup"
> +
>  	# initialize daemon vars
>  	decide_oprofile_device_mount
>  	CPUTYPE=`cat $MOUNT/cpu_type`
> @@ -539,7 +549,7 @@ do_load_setup()
>  }
>  
>  
> -check_valid_args()
> +check_valid_vmlinux()
>  {
>  	if test -z "$VMLINUX"; then
>  		echo "No vmlinux file specified. You must specify the correct vmlinux file, e.g." >&2
> @@ -560,8 +570,12 @@ check_valid_args()
>  
>  	echo "The specified vmlinux file \"$VMLINUX\" doesn't exist." >&2
>  	exit 1
> +}
> +
>  
>  # similar check for Xen image
> +check_valid_xen()
> +{
>  	if test -f "$XENIMAGE"; then
>  		return
>  	fi
> @@ -622,6 +636,77 @@ get_image_range()
>  }
>  
>  
> +set_passive_domain()
> +{
> +	DOMAIN_ID=$1
> +	FILE_IMAGE=$2
> +	XEN_IMAGE=$3
> +
> +	if test "$FILE_IMAGE" = "none"; then
> +		RANGE="0,0"
> +		FILE_IMAGE="domain$DOMAIN_ID-kernel"
> +	else
> +		# Find VMA range for passive domain kernel image 
> +		range_info=`objdump -h $FILE_IMAGE 2>/dev/null | grep " .text "`
> +		tmp1=`echo $range_info | awk '{print $4}'`	
> +		tmp_length=`echo $range_info | awk  '{print $3}'`
> +		tmp2=`objdump -h $FILE_IMAGE --adjust-vma=0x$tmp_length 2>/dev/null | grep " .text " | awk  '{print $4}'`
> +
> +		if test -z "$tmp1" -o -z "$tmp2"; then
> +			echo "The specified file $FILE_IMAGE does not seem to be valid" >&2
> +			echo "Make sure you are using the non-compressed image file (e.g. vmlinux not vmlinuz)" >&2
> +			vecho "found start as \"$tmp1\", end as \"$tmp2\"" >&2
> +			exit 1
> +		fi
> +		RANGE="`echo $tmp1`,`echo $tmp2`"
> +	fi
> +	echo " $DOMAIN_ID $FILE_IMAGE $RANGE $XEN_IMAGE" >> $PASSIVE_SETUP_FILE
> +}
> +
> +
> +set_passive_domain_config()
> +{
> +
> +	create_dir "$SETUP_DIR"
> +
> +	touch $PASSIVE_SETUP_FILE
> +	chmod 644 $PASSIVE_SETUP_FILE
> +	>$PASSIVE_SETUP_FILE
> +
> +	NDOMAINS=`echo "$PASSIVE_DOMAINS" | awk -F',' '{print NF}'`
> +
> +	if test -n "$PASSIVE_IMAGES"; then
> +		NIMAGES=`echo "$PASSIVE_IMAGES" | awk -F',' '{print NF}'`
> +		if [ $NDOMAINS != $NIMAGES ]; then
> +			echo "# of passive domains and # of passive images doesn't match." >&2
> +			do_help
> +			exit 1
> +		fi
> +
> +		for (( i=1; i<=$NDOMAINS; i++ )); do
> +			ID=`echo "$PASSIVE_DOMAINS" | awk -F"," '{print $'$i'}'`
> +			FILE=`echo "$PASSIVE_IMAGES" | awk -F',' '{print $'$i'}'`
> +			if test ! -f "$FILE"; then
> +				echo "Image $FILE for passive domain $ID not found." >&2
> +				return 1
> +			fi
> +			LNK_KERNEL=/boot/domain$ID-kernel
> +			ln -sf $FILE $LNK_KERNEL
> +			LNK_XEN=/boot/domain$ID-xen
> +			ln -sf $XENIMAGE $LNK_XEN
> +			set_passive_domain $ID $LNK_KERNEL $LNK_XEN 
> +		done
> +	else
> +			for (( i=1; i<=$NDOMAINS; i++ )); do
> +				ID=`echo "$PASSIVE_DOMAINS" | awk -F"," '{print $'$i'}'`
> +				LNK_XEN=/boot/domain$ID-xen
> +				set_passive_domain $ID none $LNK_XEN
> +		done 
> +
> +	fi
> +}
> +
> +  
>  # validate --separate= parameters. This function is called with IFS=,
>  # so on each argument is splitted
>  validate_separate_args()
> @@ -932,10 +1017,20 @@ do_options()
>  				DO_SETUP=yes
>  				;;
>  			--active-domains)
> -				error_if_invalid_arg $arg $val
> +				error_if_invalid_arg "$arg" "$val"
>  				ACTIVE_DOMAINS=$val
>  				DO_SETUP=yes
>  				;;
> +			--passive-domains|--domains)
> +				error_if_invalid_arg "$arg" "$val"
> +				PASSIVE_DOMAINS=$val
> +				DO_SETUP=yes
> +				;;
> +			--passive-images|--domain-images)
> +				error_if_invalid_arg "$arg" "$val"
> +				PASSIVE_IMAGES=$val
> +				DO_SETUP=yes
> +				;;
>  			--note-table-size)
>  				if test "$KERNEL_SUPPORT" = "yes"; then
>  					echo "\"$arg\" meaningless on this kernel" >&2
> @@ -1366,6 +1461,16 @@ check_event_mapping_data()
>  			exit 1
>  		fi
>  	fi
> +
> +	if test -n "$ACTIVE_DOMAINS" -a "$START_DAEMON" != "yes"; then
> +		echo "Option \"--active-domains\" can only be used with option \"-start-daemon\"." >&2
> +		exit 1
> +	fi
> +
> +	if test -n "$PASSIVE_DOMAINS" -a "$START_DAEMON" != "yes" -a "$START" != "yes"; then
> +		echo "Option \"--passive-domains\" or "--domains" can only be used with option \"--start-daemon\" or \"--start\"." >&2
> +		exit 1
> +	fi
>  }
>  
>  
> @@ -1404,6 +1509,15 @@ do_param_setup()
>  		fi
>  	fi
>  
> +	if test -n "$PASSIVE_DOMAINS"; then
> +		if test "$KERNEL_SUPPORT" = "yes"; then
> +			echo $PASSIVE_DOMAINS >$MOUNT/passive_domains
> +			set_passive_domain_config
> +		else
> +			echo "passive-domains not supported - ignored" >&2
> +		fi
> +	fi
> +	
>  	if test $NOTE_SIZE != 0; then
>  		set_param notesize $NOTE_SIZE
>  	fi
> @@ -1566,7 +1680,8 @@ do_start_daemon()
>  	fi
>  
>  	do_setup
> -	check_valid_args
> + 	check_valid_vmlinux
> + 	check_valid_xen
>  	get_image_range "linux"
>  	get_image_range "xen"
>  	do_param_setup
> @@ -1600,6 +1715,10 @@ do_start_daemon()
>  		OPD_ARGS="$OPD_ARGS --image=$IMAGE_FILTER"
>  	fi
>  
> +	if ! test -z "$PASSIVE_DOMAINS"; then
> +		OPD_ARGS="$OPD_ARGS --xen-passive-setup=$PASSIVE_SETUP_FILE"
> +	fi
> +
>  	if test -n "$VERBOSE"; then
>  		OPD_ARGS="$OPD_ARGS --verbose=$VERBOSE"
>  	fi
> @@ -1805,6 +1924,8 @@ do_save_session()
>  	fi
>  
>  	hup_daemon
> +
> +	rm -f /boot/domain-*-kernel /boot/domain-*-xen
>  }
>  
>  
> @@ -1855,7 +1976,8 @@ do_operations()
>  	fi
>  
>  	if test "$SETUP" = "yes"; then
> -		check_valid_args
> +		check_valid_vmlinux
> +		check_valid_xen
>  		do_save_setup
>  	fi
>  

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 22:47:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 22:47:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RV9y6-0007dG-0m; Mon, 28 Nov 2011 22:46:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RV9y2-0007dB-Ta
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 22:46:31 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322520351!4159623!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23579 invoked from network); 28 Nov 2011 22:45:52 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Nov 2011 22:45:52 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pASMjj8T008516
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 28 Nov 2011 17:45:45 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pASMjjOd008514;
	Mon, 28 Nov 2011 17:45:45 -0500
Date: Mon, 28 Nov 2011 18:45:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: William Cohen <wcohen@redhat.com>
Message-ID: <20111128224545.GA7821@andromeda.dapyr.net>
References: <4ED4069E.7030307@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED4069E.7030307@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 

There was one posted some time ago.. Ah:
http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz

I think that ones works , thought I haven't had a chance to test it
myself.
> 
> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?

Well, the desire is to get a performance tool in upstream that works
with Xen very very very much.

The upstream is using the 'perf' framework which is different from oprofile
and there hasn't been any patches to take advantage of it.

So to answer your question:
 1). Its awesome you have posted a patch. Will need to spend some time
     with it and and with the version that was posted to see if there is
     something missing. Sadly, the kernel patch is not very
     upstream-compatible as is. But it will get to folks be able to
     do some perf analysis instead of using benchmark tools.

 2). In the future we need to work out the optimal performance tool. It
     might be oprofile or it might be perf (or it might be both?!). Or
     it might something that has not yet been posted?

You wouldn't by any chance be interested in looking at the performance
"stuff" and figure out what is the best route/tools to use with upstream
kernels?

> 
> -Will

> diff -up oprofile-0.9.7/daemon/init.c.xen oprofile-0.9.7/daemon/init.c
> --- oprofile-0.9.7/daemon/init.c.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/init.c	2011-11-28 16:25:07.577000010 -0500
> @@ -312,6 +312,8 @@ static void opd_26_init(void)
>  
>  	opd_create_vmlinux(vmlinux, kernel_range);
>  	opd_create_xen(xenimage, xen_range);
> +	if (xen_passive_setup)
> +		opd_create_passive(xen_passive_setup);
>  
>  	opd_buf_size = opd_read_fs_int("/dev/oprofile/", "buffer_size", 1);
>  	kernel_pointer_size = opd_read_fs_int("/dev/oprofile/", "pointer_size", 1);
> diff -up oprofile-0.9.7/daemon/opd_kernel.c.xen oprofile-0.9.7/daemon/opd_kernel.c
> --- oprofile-0.9.7/daemon/opd_kernel.c.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/opd_kernel.c	2011-11-28 16:25:07.579000010 -0500
> @@ -34,11 +34,22 @@ static struct kernel_image vmlinux_image
>  
>  static struct kernel_image xen_image;
>  
> +static struct kernel_image xen_image_anon;
> +static struct kernel_image vmlinux_image_anon;
> +
> +static LIST_HEAD(passive_vmlinux);
> +static LIST_HEAD(passive_xen);
> +static LIST_HEAD(passive_apps);
> +static LIST_HEAD(passive_modules);
> +static LIST_HEAD(passive_xen_anon);
> +
>  void opd_create_vmlinux(char const * name, char const * arg)
>  {
>  	/* vmlinux is *not* on the list of modules */
>  	list_init(&vmlinux_image.list);
>  
> +	list_init(&vmlinux_image_anon.list);
> +
>  	/* for no vmlinux */
>  	if (no_vmlinux) {
>  		vmlinux_image.name = "no-vmlinux";
> @@ -57,13 +68,22 @@ void opd_create_vmlinux(char const * nam
>  		        vmlinux_image.start, vmlinux_image.end);
>  		exit(EXIT_FAILURE);
>  	}
> +
> +	vmlinux_image_anon.name  = "vmlinux-unknown";
> +	vmlinux_image_anon.start = vmlinux_image.start;
> +	vmlinux_image_anon.end   = vmlinux_image.end;
> +
>  }
>  
>  void opd_create_xen(char const * name, char const * arg)
>  {
> +	int stat;
> +
>  	/* xen is *not* on the list of modules */
>  	list_init(&xen_image.list);
>  
> +	list_init(&xen_image_anon.list);
> +
>  	/* for no xen */
>  	if (no_xen) {
>  		xen_image.name = "no-xen";
> @@ -72,18 +92,106 @@ void opd_create_xen(char const * name, c
>  
>  	xen_image.name = xstrdup(name);
>  
> -	sscanf(arg, "%llx,%llx", &xen_image.start, &xen_image.end);
> +	stat = sscanf(arg, "%llx,%llx", &xen_image.start, &xen_image.end);
> +
> +	xen_image_anon.name  = "xen-unknown";
> +	xen_image_anon.start = xen_image.start;
> +	xen_image_anon.end   = xen_image.end;
>  
>  	verbprintf(vmisc, "xen_start = %llx, xen_end = %llx\n",
>  	           xen_image.start, xen_image.end);
>  
> -	if (!xen_image.start && !xen_image.end) {
> +	if ( stat != 2 ) {
>  		fprintf(stderr, "error: mis-parsed xen range: %llx-%llx\n",
>  		        xen_image.start, xen_image.end);
>  		exit(EXIT_FAILURE);
>  	}
> +
>  }
>  
> +void opd_create_passive_domain(int id, char const * image_kernel, 
> +			       char const * range, char const * image_xen)
> +{
> +	char file[64];
> +	struct kernel_image * image;
> +	int stat;
> +
> +	image = xmalloc(sizeof(struct kernel_image));
> +	image->name = xstrdup(image_kernel);
> +	image->start = image->end = 0; 
> +	stat = sscanf(range, "%llx,%llx", &image->start, &image->end);
> +	image->id = id;
> +	list_add(&image->list, &passive_vmlinux);
> +	
> +	if ( stat != 2 ) {
> +		fprintf(stderr, "error: mis-parsed passive domain range for "
> +			"domain %d: %llx-%llx\n", id, image->start, image->end);
> +		exit(EXIT_FAILURE);
> +	}
> +
> +	image = xmalloc(sizeof(struct kernel_image));
> +	image->name = xstrdup(image_xen);
> +	image->start = xen_image.start;
> +	image->end = xen_image.end;
> +	image->id = id;
> +	list_add(&image->list, &passive_xen);
> +
> +	sprintf(file, "domain%d-apps", id);
> +	image = xmalloc(sizeof(struct kernel_image));
> +	image->name = xstrdup(file);
> +	image->start = 0; 
> +	image->end = 0;
> +	image->id = id;
> +	list_add(&image->list, &passive_apps);
> +
> +	sprintf(file, "domain%d-modules", id);
> +	image = xmalloc(sizeof(struct kernel_image));
> +	image->name = xstrdup(file);
> +	image->start = 0; 
> +	image->end = 0;
> +	stat = sscanf(range, "%llx,%llx", &image->start, &image->end);
> +	image->id = id;
> +	list_add(&image->list, &passive_modules);
> +
> +	sprintf(file, "domain%d-xen-unknown", id);
> +	image = xmalloc(sizeof(struct kernel_image));
> +	image->name = xstrdup(file);
> +	image->start = xen_image.start; 
> +	image->end = xen_image.end;
> +	image->id = id;
> +	list_add(&image->list, &passive_xen_anon);
> +
> +}
> +
> +void opd_create_passive(char const *setup_file)
> +{
> +	FILE *fp;
> +	int id=0;
> +	char image_kernel[128+1];
> +	char range[128+1];
> +	char image_xen[128+1];
> +	int stat;
> +
> +	image_kernel[0] = range[0] = image_xen[0] = 0;
> +
> +	fp = fopen(setup_file, "r");
> +
> +	if (!fp) {
> +		fprintf(stderr, "error: Could not open Xen passive domain "
> +			"setup file %s\n", setup_file);
> +		exit(EXIT_FAILURE);
> +	}
> +
> +	while (1) {
> +		stat = fscanf(fp, "%d %128s %128s %128s", &id, image_kernel, range, 
> +			image_xen);
> +		if ( stat != 4 )
> +			return;
> +		opd_create_passive_domain(id, image_kernel, range, image_xen);
> +	}
> +
> +	fclose(fp);
> +}
>  
>  /**
>   * Allocate and initialise a kernel image description
> @@ -210,6 +318,75 @@ struct kernel_image * find_kernel_image(
>  	struct list_head * pos;
>  	struct kernel_image * image = &vmlinux_image;
>  
> +	if (current_domain != COORDINATOR_DOMAIN) {
> +		/* we rely on cpu_mode value (i.e. trans->in_kernel)
> +		 * to search the right image type: xen, kernel or user
> +		 * We cannot use address ranges since hypervisor does not
> +		 * share the same address space with fully virtualized guests,
> +		 * and thus address ranges can overlap  */
> +		switch ( trans->in_kernel ) {
> +
> +		/* user mode */
> +		case 1:
> +			list_for_each(pos, &passive_apps) {
> +				image = list_entry(pos, struct kernel_image, list);
> +				if (image->id == current_domain) 
> +					return image;
> +			}
> +			return NULL;
> +
> +		/* kernel mode */
> +		case 2:
> +			list_for_each(pos, &passive_vmlinux) {
> +				image = list_entry(pos, struct kernel_image, list);
> +				if ( (image->id == current_domain)
> +				     && ( (image->start == 0 && image->end == 0)
> +					  || (image->start <= trans->pc 
> +					      && image->end > trans->pc) ) )
> +						return image;
> +			}
> +			/* if not in kernel image range then it should be a module */ 
> +			list_for_each(pos, &passive_modules) {
> +				image = list_entry(pos, struct kernel_image, list);
> +				if (image->id == current_domain) 
> +					return image;
> +			}
> +			/* This should not happen if the kernel and user level 
> +                           oprofile code are sane and in sync */
> +			return NULL;
> +
> +		/* hypervisor mode */
> +		case 3:
> +			list_for_each(pos, &passive_xen) {
> +				image = list_entry(pos, struct kernel_image, list);
> +				if (image->id == current_domain
> +				    && image->start <= trans->pc 
> +				    && image->end > trans->pc) 
> +					return image;
> +			}
> +			list_for_each(pos, &passive_xen_anon) {
> +				image = list_entry(pos, struct kernel_image, list);
> +				if (image->id == current_domain)
> +					return image;
> +			}
> +			return NULL;
> +
> +		default:
> +			printf("Unexpected error on passive mode: CPU mode is "
> +			       "%d for domain %d\n", trans->in_kernel, current_domain);
> +			return NULL;
> +		}
> +		
> +		
> +	}
> +
> +	if (xen_image.start <= trans->pc && xen_image.end > trans->pc)
> +		return &xen_image;
> + 
> +	if (trans->in_kernel == 2) {
> +		return &xen_image_anon;
> +	}
> +
>  	if (no_vmlinux)
>  		return image;
>  
> @@ -222,8 +399,5 @@ struct kernel_image * find_kernel_image(
>  			return image;
>  	}
>  
> -	if (xen_image.start <= trans->pc && xen_image.end > trans->pc)
> -		return &xen_image;
> -
> -	return NULL;
> +	return &vmlinux_image_anon;
>  }
> diff -up oprofile-0.9.7/daemon/opd_kernel.h.xen oprofile-0.9.7/daemon/opd_kernel.h
> --- oprofile-0.9.7/daemon/opd_kernel.h.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/opd_kernel.h	2011-11-28 16:25:07.580000010 -0500
> @@ -23,8 +23,12 @@ struct transient;
>  /** create the kernel image */
>  void opd_create_vmlinux(char const * name, char const * arg);
>  
> +/** create Xen image */
>  void opd_create_xen(char const * name, char const * arg);
>  
> +/** create Xen passive domain images */
> +void opd_create_passive(char const *setup_file);
> +
>  /** opd_reread_module_info - parse /proc/modules for kernel modules */
>  void opd_reread_module_info(void);
>  
> @@ -33,6 +37,7 @@ struct kernel_image {
>  	char * name;
>  	vma_t start;
>  	vma_t end;
> +	int id;
>  	struct list_head list;
>  };
>  
> diff -up oprofile-0.9.7/daemon/opd_sfile.c.xen oprofile-0.9.7/daemon/opd_sfile.c
> --- oprofile-0.9.7/daemon/opd_sfile.c.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/opd_sfile.c	2011-11-28 16:25:07.582000010 -0500
> @@ -240,7 +240,7 @@ struct sfile * sfile_find(struct transie
>  	}
>  
>  	/* we might need a kernel image start/end to hash on */
> -	if (trans->in_kernel) {
> +	else if (trans->in_kernel) {
>  		ki = find_kernel_image(trans);
>  		if (!ki) {
>  			verbprintf(vsamples, "Lost kernel sample %llx\n", trans->pc);
> diff -up oprofile-0.9.7/daemon/opd_trans.c.xen oprofile-0.9.7/daemon/opd_trans.c
> --- oprofile-0.9.7/daemon/opd_trans.c.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/opd_trans.c	2011-11-28 16:25:07.584000010 -0500
> @@ -31,6 +31,8 @@
>  #include <stdio.h>
>  #include <errno.h>
>  
> +int32_t current_domain = COORDINATOR_DOMAIN;
> +
>  extern size_t kernel_pointer_size;
>  
>  
> @@ -203,6 +205,9 @@ static void code_kernel_enter(struct tra
>  {
>  	verbprintf(vmisc, "KERNEL_ENTER_SWITCH to kernel\n");
>  	trans->in_kernel = 1;
> +	/* if in passive domain mode cpu mode should be incremented */
> +	if (current_domain != COORDINATOR_DOMAIN)
> +		trans->in_kernel++;
>  	clear_trans_current(trans);
>  	/* subtlety: we must keep trans->cookie cached,
>  	 * even though it's meaningless for the kernel -
> @@ -216,6 +221,9 @@ static void code_user_enter(struct trans
>  {
>  	verbprintf(vmisc, "USER_ENTER_SWITCH to user-space\n");
>  	trans->in_kernel = 0;
> +	/* if in passive domain mode cpu mode should be incremented */
> +	if (current_domain != COORDINATOR_DOMAIN)
> +		trans->in_kernel++;
>  	clear_trans_current(trans);
>  	clear_trans_last(trans);
>  }
> @@ -244,17 +252,34 @@ static void code_trace_begin(struct tran
>  static void code_xen_enter(struct transient * trans)
>  {
>  	verbprintf(vmisc, "XEN_ENTER_SWITCH to xen\n");
> -	trans->in_kernel = 1;
> +	trans->in_kernel = 2;
> +	/* if in passive domain mode cpu mode should be incremented */
> +	if (current_domain != COORDINATOR_DOMAIN)
> +		trans->in_kernel++;
>  	trans->current = NULL;
>  	/* subtlety: we must keep trans->cookie cached, even though it's
> -	 * meaningless for Xen - we won't necessarily get a cookie switch
> -	 * on Xen exit. See comments in opd_sfile.c. It seems that we can
> -	 * get away with in_kernel = 1 as long as we supply the correct
> -	 * Xen image, and its address range in startup find_kernel_image
> -	 * is modified to look in the Xen image also
> -	 */
> +	 * meaningless for Xen - same reason as for kernel */
>  }
>  
> +static void code_domain_switch(struct transient *trans)
> +{
> +	/* While processing passive domain samples we ensure (in_kernel!=0)
> +	 * We do this in order to ignore cookies for passive domain samples 
> +	 * But, we have to remember the kernel value for coordinator domain, 
> +	 * so we do the safe thing: increment when leaving the coordinator
> +	 * domain and decrement when returning to it 
> + 	 */
> +	if (current_domain == COORDINATOR_DOMAIN)
> +		trans->in_kernel++;
> +
> +	trans->current = NULL;
> +	current_domain = (int32_t) pop_buffer_value(trans);
> +
> +	/* If returning to coordinator domain restore the kernel value */
> +	if (current_domain == COORDINATOR_DOMAIN)
> +		trans->in_kernel--;
> +}
> + 
>  extern void code_spu_profiling(struct transient * trans);
>  extern void code_spu_ctx_switch(struct transient * trans);
>  
> @@ -278,7 +303,7 @@ handler_t handlers[LAST_CODE + 1] = {
>  	&code_spu_profiling,
>  	&code_spu_ctx_switch,
>  #else
> -	&code_unknown,
> + 	&code_domain_switch,
>  	&code_unknown,
>  #endif
>  	&code_ibs_fetch_sample,
> diff -up oprofile-0.9.7/daemon/opd_trans.h.xen oprofile-0.9.7/daemon/opd_trans.h
> --- oprofile-0.9.7/daemon/opd_trans.h.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/opd_trans.h	2011-11-28 16:25:07.585000010 -0500
> @@ -21,6 +21,10 @@
>  
>  #include <stdint.h>
>  
> +#define COORDINATOR_DOMAIN -1
> +
> +extern int32_t current_domain;
> +
>  struct sfile;
>  struct anon_mapping;
>  
> diff -up oprofile-0.9.7/daemon/oprofiled.c.xen oprofile-0.9.7/daemon/oprofiled.c
> --- oprofile-0.9.7/daemon/oprofiled.c.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/oprofiled.c	2011-11-28 16:25:07.587000010 -0500
> @@ -71,6 +71,7 @@ char * session_dir;
>  int no_xen;
>  char * xenimage;
>  char * xen_range;
> +char * xen_passive_setup;
>  static char * verbose;
>  static char * binary_name_filter;
>  static char * events;
> @@ -91,6 +92,7 @@ static struct poptOption options[] = {
>  	{ "xen-range", 0, POPT_ARG_STRING, &xen_range, 0, "Xen VMA range", "start-end", },
>  	{ "xen-image", 0, POPT_ARG_STRING, &xenimage, 0, "Xen image", "file", },
>  	{ "image", 0, POPT_ARG_STRING, &binary_name_filter, 0, "image name filter", "profile these comma separated image" },
> +	{ "xen-passive-setup", 0, POPT_ARG_STRING, &xen_passive_setup, 0, "Xen passive domain setup file", "filename", },
>  	{ "separate-lib", 0, POPT_ARG_INT, &separate_lib, 0, "separate library samples for each distinct application", "[0|1]", },
>  	{ "separate-kernel", 0, POPT_ARG_INT, &separate_kernel, 0, "separate kernel samples for each distinct application", "[0|1]", },
>  	{ "separate-thread", 0, POPT_ARG_INT, &separate_thread, 0, "thread-profiling mode", "[0|1]" },
> diff -up oprofile-0.9.7/daemon/oprofiled.h.xen oprofile-0.9.7/daemon/oprofiled.h
> --- oprofile-0.9.7/daemon/oprofiled.h.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/daemon/oprofiled.h	2011-11-28 16:25:07.588000010 -0500
> @@ -65,5 +65,6 @@ extern char * kernel_range;
>  extern int no_xen;
>  extern char * xenimage;
>  extern char * xen_range;
> +extern char * xen_passive_setup;
>  
>  #endif /* OPROFILED_H */
> diff -up oprofile-0.9.7/doc/opcontrol.1.in.xen oprofile-0.9.7/doc/opcontrol.1.in
> --- oprofile-0.9.7/doc/opcontrol.1.in.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/doc/opcontrol.1.in	2011-11-28 16:25:07.590000010 -0500
> @@ -158,12 +158,41 @@ Xen image
>  .br
>  .TP
>  .BI "--active-domains="<list>
> -List of domain ids participating in a multi-domain profiling session. If 
> +List of domain ids participating in a multi-domain profiling session. 
> +Each of the specified domains must run an instance of oprofile. The 
> +sequence of opcontrol commands in each domain must follow a given 
> +order which is specified in the oprofile user manual. If 
>  more than one domain is specified in <list> they should be separated using 
>  commas. This option can only be used in domain 0 which is the only domain 
>  that can coordinate a multi-domain profiling session. Including domain 0 in 
>  the list of active domains is optional. (e.g. --active-domains=2,5,6 and 
> ---active-domains=0,2,5,6 are equivalent)
> +--active-domains=0,2,5,6 are equivalent).
> +This option can only be specified
> +if --start-daemon is also specified and it is only 
> +valid for the current run of the oprofile daemon; e.g. the list 
> +of active domains is not persistent.
> +.br
> +.TP
> +.BI "--passive-domains="<list> or "--domains="<list>
> +List of domain ids to be profiled, separated by commas. 
> +As opposed to the --active-domains option, the domains specified with this
> +option do not need to run oprofile. This makes 
> +profiling multiple domains easier. However, with the passive-domains option, 
> +samples in user level processes and kernel modules cannot be 
> +mapped to specific symbols and are aggregated
> +under a generic class. Both --active-domains and --passive-domains 
> +options can be specified in the same command, but the same domain cannot be
> +specified in both options. This option can only be specified if either --start
> +or --start-daemon is specified on the same command and it is only valid for 
> +the current run of the oprofile daemon; e.g. the list of passive domains is 
> +not persistent.
> +.br
> +.TP
> +.BI "--passive-images="<list> or "--domains-images="<list>
> +List of kernel images associated with the domains specified in the
> +--passive-domains option, also separated by commas. The association
> +between the images and domains is based on the order they are
> +specified in both options.
>  .br
>  
>  .SH ENVIRONMENT
> diff -up oprofile-0.9.7/libpp/format_output.cpp.xen oprofile-0.9.7/libpp/format_output.cpp
> --- oprofile-0.9.7/libpp/format_output.cpp.xen	2011-07-04 22:25:04.000000000 -0400
> +++ oprofile-0.9.7/libpp/format_output.cpp	2011-11-28 16:25:07.592000010 -0500
> @@ -287,8 +287,8 @@ string formatter::format_app_name(field_
>  {
>  	return get_image_name(f.symbol.app_name,
>  		long_filenames 
> -			? image_name_storage::int_real_filename
> -			: image_name_storage::int_real_basename,
> +			? image_name_storage::int_filename
> +			: image_name_storage::int_basename,
>  		extra_found_images);
>  }
>  
> diff -up oprofile-0.9.7/utils/opcontrol.xen oprofile-0.9.7/utils/opcontrol
> --- oprofile-0.9.7/utils/opcontrol.xen	2011-07-20 15:36:48.000000000 -0400
> +++ oprofile-0.9.7/utils/opcontrol	2011-11-28 16:28:56.431000248 -0500
> @@ -236,9 +236,16 @@ opcontrol: usage:
>     --note-table-size             kernel notes buffer size in notes units (2.4
>                                   kernel)
>  
> -   --xen                         Xen image (for Xen only)
> -   --active-domains=<list>       List of domains in profiling session (for Xen)
> -                                 (list contains domain ids separated by commas)
> +   --xen=file                    Xen image (for Xen only)
> +   --active-domains=id[,ids]     list of domains in multiple domain profiling session (Xen)
> +                                 (detailed profiling of user level and kernel modules code)
> +                                 (requires running oprofile on these domains)
> +   --passive-domains=id[,ids]    list of domains to be profiled (Xen).
> +     or --domains=id[,ids]       (coarse profiling of user level and kernel modules code)
> +                                 (no need to run oprofile on these domains)
> +   --passive-images=file[,files] list of kernel images associated with each passive domain
> +     or 
> +   --domain-images=file[,files]
>  EOF
>  }
>  
> @@ -388,6 +395,9 @@ do_init()
>  	SETUP_FILE="$SETUP_DIR/daemonrc"
>  	SEC_SETUP_FILE="$SETUP_DIR/daemonrc_new"
>  
> +	# location for passing info about passive domains to daemon
> +	PASSIVE_SETUP_FILE="$SETUP_DIR/xendomain.setup"
> +
>  	# initialize daemon vars
>  	decide_oprofile_device_mount
>  	CPUTYPE=`cat $MOUNT/cpu_type`
> @@ -539,7 +549,7 @@ do_load_setup()
>  }
>  
>  
> -check_valid_args()
> +check_valid_vmlinux()
>  {
>  	if test -z "$VMLINUX"; then
>  		echo "No vmlinux file specified. You must specify the correct vmlinux file, e.g." >&2
> @@ -560,8 +570,12 @@ check_valid_args()
>  
>  	echo "The specified vmlinux file \"$VMLINUX\" doesn't exist." >&2
>  	exit 1
> +}
> +
>  
>  # similar check for Xen image
> +check_valid_xen()
> +{
>  	if test -f "$XENIMAGE"; then
>  		return
>  	fi
> @@ -622,6 +636,77 @@ get_image_range()
>  }
>  
>  
> +set_passive_domain()
> +{
> +	DOMAIN_ID=$1
> +	FILE_IMAGE=$2
> +	XEN_IMAGE=$3
> +
> +	if test "$FILE_IMAGE" = "none"; then
> +		RANGE="0,0"
> +		FILE_IMAGE="domain$DOMAIN_ID-kernel"
> +	else
> +		# Find VMA range for passive domain kernel image 
> +		range_info=`objdump -h $FILE_IMAGE 2>/dev/null | grep " .text "`
> +		tmp1=`echo $range_info | awk '{print $4}'`	
> +		tmp_length=`echo $range_info | awk  '{print $3}'`
> +		tmp2=`objdump -h $FILE_IMAGE --adjust-vma=0x$tmp_length 2>/dev/null | grep " .text " | awk  '{print $4}'`
> +
> +		if test -z "$tmp1" -o -z "$tmp2"; then
> +			echo "The specified file $FILE_IMAGE does not seem to be valid" >&2
> +			echo "Make sure you are using the non-compressed image file (e.g. vmlinux not vmlinuz)" >&2
> +			vecho "found start as \"$tmp1\", end as \"$tmp2\"" >&2
> +			exit 1
> +		fi
> +		RANGE="`echo $tmp1`,`echo $tmp2`"
> +	fi
> +	echo " $DOMAIN_ID $FILE_IMAGE $RANGE $XEN_IMAGE" >> $PASSIVE_SETUP_FILE
> +}
> +
> +
> +set_passive_domain_config()
> +{
> +
> +	create_dir "$SETUP_DIR"
> +
> +	touch $PASSIVE_SETUP_FILE
> +	chmod 644 $PASSIVE_SETUP_FILE
> +	>$PASSIVE_SETUP_FILE
> +
> +	NDOMAINS=`echo "$PASSIVE_DOMAINS" | awk -F',' '{print NF}'`
> +
> +	if test -n "$PASSIVE_IMAGES"; then
> +		NIMAGES=`echo "$PASSIVE_IMAGES" | awk -F',' '{print NF}'`
> +		if [ $NDOMAINS != $NIMAGES ]; then
> +			echo "# of passive domains and # of passive images doesn't match." >&2
> +			do_help
> +			exit 1
> +		fi
> +
> +		for (( i=1; i<=$NDOMAINS; i++ )); do
> +			ID=`echo "$PASSIVE_DOMAINS" | awk -F"," '{print $'$i'}'`
> +			FILE=`echo "$PASSIVE_IMAGES" | awk -F',' '{print $'$i'}'`
> +			if test ! -f "$FILE"; then
> +				echo "Image $FILE for passive domain $ID not found." >&2
> +				return 1
> +			fi
> +			LNK_KERNEL=/boot/domain$ID-kernel
> +			ln -sf $FILE $LNK_KERNEL
> +			LNK_XEN=/boot/domain$ID-xen
> +			ln -sf $XENIMAGE $LNK_XEN
> +			set_passive_domain $ID $LNK_KERNEL $LNK_XEN 
> +		done
> +	else
> +			for (( i=1; i<=$NDOMAINS; i++ )); do
> +				ID=`echo "$PASSIVE_DOMAINS" | awk -F"," '{print $'$i'}'`
> +				LNK_XEN=/boot/domain$ID-xen
> +				set_passive_domain $ID none $LNK_XEN
> +		done 
> +
> +	fi
> +}
> +
> +  
>  # validate --separate= parameters. This function is called with IFS=,
>  # so on each argument is splitted
>  validate_separate_args()
> @@ -932,10 +1017,20 @@ do_options()
>  				DO_SETUP=yes
>  				;;
>  			--active-domains)
> -				error_if_invalid_arg $arg $val
> +				error_if_invalid_arg "$arg" "$val"
>  				ACTIVE_DOMAINS=$val
>  				DO_SETUP=yes
>  				;;
> +			--passive-domains|--domains)
> +				error_if_invalid_arg "$arg" "$val"
> +				PASSIVE_DOMAINS=$val
> +				DO_SETUP=yes
> +				;;
> +			--passive-images|--domain-images)
> +				error_if_invalid_arg "$arg" "$val"
> +				PASSIVE_IMAGES=$val
> +				DO_SETUP=yes
> +				;;
>  			--note-table-size)
>  				if test "$KERNEL_SUPPORT" = "yes"; then
>  					echo "\"$arg\" meaningless on this kernel" >&2
> @@ -1366,6 +1461,16 @@ check_event_mapping_data()
>  			exit 1
>  		fi
>  	fi
> +
> +	if test -n "$ACTIVE_DOMAINS" -a "$START_DAEMON" != "yes"; then
> +		echo "Option \"--active-domains\" can only be used with option \"-start-daemon\"." >&2
> +		exit 1
> +	fi
> +
> +	if test -n "$PASSIVE_DOMAINS" -a "$START_DAEMON" != "yes" -a "$START" != "yes"; then
> +		echo "Option \"--passive-domains\" or "--domains" can only be used with option \"--start-daemon\" or \"--start\"." >&2
> +		exit 1
> +	fi
>  }
>  
>  
> @@ -1404,6 +1509,15 @@ do_param_setup()
>  		fi
>  	fi
>  
> +	if test -n "$PASSIVE_DOMAINS"; then
> +		if test "$KERNEL_SUPPORT" = "yes"; then
> +			echo $PASSIVE_DOMAINS >$MOUNT/passive_domains
> +			set_passive_domain_config
> +		else
> +			echo "passive-domains not supported - ignored" >&2
> +		fi
> +	fi
> +	
>  	if test $NOTE_SIZE != 0; then
>  		set_param notesize $NOTE_SIZE
>  	fi
> @@ -1566,7 +1680,8 @@ do_start_daemon()
>  	fi
>  
>  	do_setup
> -	check_valid_args
> + 	check_valid_vmlinux
> + 	check_valid_xen
>  	get_image_range "linux"
>  	get_image_range "xen"
>  	do_param_setup
> @@ -1600,6 +1715,10 @@ do_start_daemon()
>  		OPD_ARGS="$OPD_ARGS --image=$IMAGE_FILTER"
>  	fi
>  
> +	if ! test -z "$PASSIVE_DOMAINS"; then
> +		OPD_ARGS="$OPD_ARGS --xen-passive-setup=$PASSIVE_SETUP_FILE"
> +	fi
> +
>  	if test -n "$VERBOSE"; then
>  		OPD_ARGS="$OPD_ARGS --verbose=$VERBOSE"
>  	fi
> @@ -1805,6 +1924,8 @@ do_save_session()
>  	fi
>  
>  	hup_daemon
> +
> +	rm -f /boot/domain-*-kernel /boot/domain-*-xen
>  }
>  
>  
> @@ -1855,7 +1976,8 @@ do_operations()
>  	fi
>  
>  	if test "$SETUP" = "yes"; then
> -		check_valid_args
> +		check_valid_vmlinux
> +		check_valid_xen
>  		do_save_setup
>  	fi
>  

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 23:18:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 23:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVAS6-0007uv-N5; Mon, 28 Nov 2011 23:17:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RVAS5-0007un-8A
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 23:17:33 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322522213!5374587!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23627 invoked from network); 28 Nov 2011 23:16:56 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-13.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Nov 2011 23:16:56 -0000
Received: from mail.bendigoit.com.au ([203.16.207.99])
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RVARN-0008GH-1g; Tue, 29 Nov 2011 10:16:49 +1100
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 29 Nov 2011 10:16:48 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EDFF48@trantor>
In-Reply-To: <4ED39164.5040203@hfp.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: State of GPLPV tests - 28.11.11
Thread-Index: Acyt1JNaLVnuYkxSRwy6sd8vMjnJigATklZw
References: <4ED39164.5040203@hfp.de>
From: "James Harper" <james.harper@bendigoit.com.au>
To: "Andreas Kinzler" <ml-xen-devel@hfp.de>,
	<xen-devel@lists.xensource.com>
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] State of GPLPV tests - 28.11.11
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hello James,
> 
> I am still running tests 7 days a week on two test systems. Results
are quite
> discouraging though. After experiencing crash after crash I wanted to
test if
> the configuration I called "stable" (Xen 4.0.1, GPLPV 0.11.0.213, dom0
kernel
> 2.6.32.18-pvops0-ak3) was stable indeed. But even that config crashed
when
> running my torture test. It is stable on our production systems -
running
> other workloads of course.

What crash are you getting these days? Is it the same one as you used to
get?

>  > One thing I thought of... virtualisation gives an interesting  >
opportunity to
> exaggerate race conditions. If you have 8 vCPU's in a  > DomU but only
let
> one or two physical CPUs service those 8 vCPU's,then  > it can give
rise to
> race conditions which could only be rarely seen  > (or never seen) in
normal
> operation. It's awful for performance but  > if you could try that and
see if it
> gives rise to crashes a bit  > more frequently it might help us track
down the
> problem.
> 
> What exactly is the config you are talking about in terms of Xen/dom0
> command line? In terms of domU config files?

I don't remember the exact syntax, but if you specify vcpus=4 but only
let the DomU run on one physical cpu it might trip up more often, if the
problem is caused by a race. If the problem is an arithmetic error in
xennet then it won't help.

> 
> As always, I monitor your mercurial repo ;-) How would you see the
> relationship of commits 952+953 to our problem? 952 seems to affect
LSO in
> some way since LsoV1TransmitComplete.TcpPayload is finally wrong
(could it
> be negative since tx_length is smaller than the fixed tx_length?).
What about
> 953?

Not sure.

> One more thought: As mentioned earlier crashes often occurred after an
> uptime of 9-10 days and these crashes occurred too consistently to be
a "by
> chance" event. In my torture tests I am NOT USING a Windows NTP
service (I
> use the meinberg NTP daemon on Windows). But on production I do. Can
> you see any possible impact here?
> 

It's certainly more likely for a stray UDP packet to cause an upset I
guess. As the packets pass through a Linux firewall (iptables in Dom0)
it's more likely that errant TCP packets will be dropped there.

Do you have a crash dump against 0.11.0.323?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 23:18:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 23:18:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVAS6-0007uv-N5; Mon, 28 Nov 2011 23:17:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RVAS5-0007un-8A
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 23:17:33 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322522213!5374587!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23627 invoked from network); 28 Nov 2011 23:16:56 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-13.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Nov 2011 23:16:56 -0000
Received: from mail.bendigoit.com.au ([203.16.207.99])
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RVARN-0008GH-1g; Tue, 29 Nov 2011 10:16:49 +1100
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 29 Nov 2011 10:16:48 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EDFF48@trantor>
In-Reply-To: <4ED39164.5040203@hfp.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: State of GPLPV tests - 28.11.11
Thread-Index: Acyt1JNaLVnuYkxSRwy6sd8vMjnJigATklZw
References: <4ED39164.5040203@hfp.de>
From: "James Harper" <james.harper@bendigoit.com.au>
To: "Andreas Kinzler" <ml-xen-devel@hfp.de>,
	<xen-devel@lists.xensource.com>
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] State of GPLPV tests - 28.11.11
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Hello James,
> 
> I am still running tests 7 days a week on two test systems. Results
are quite
> discouraging though. After experiencing crash after crash I wanted to
test if
> the configuration I called "stable" (Xen 4.0.1, GPLPV 0.11.0.213, dom0
kernel
> 2.6.32.18-pvops0-ak3) was stable indeed. But even that config crashed
when
> running my torture test. It is stable on our production systems -
running
> other workloads of course.

What crash are you getting these days? Is it the same one as you used to
get?

>  > One thing I thought of... virtualisation gives an interesting  >
opportunity to
> exaggerate race conditions. If you have 8 vCPU's in a  > DomU but only
let
> one or two physical CPUs service those 8 vCPU's,then  > it can give
rise to
> race conditions which could only be rarely seen  > (or never seen) in
normal
> operation. It's awful for performance but  > if you could try that and
see if it
> gives rise to crashes a bit  > more frequently it might help us track
down the
> problem.
> 
> What exactly is the config you are talking about in terms of Xen/dom0
> command line? In terms of domU config files?

I don't remember the exact syntax, but if you specify vcpus=4 but only
let the DomU run on one physical cpu it might trip up more often, if the
problem is caused by a race. If the problem is an arithmetic error in
xennet then it won't help.

> 
> As always, I monitor your mercurial repo ;-) How would you see the
> relationship of commits 952+953 to our problem? 952 seems to affect
LSO in
> some way since LsoV1TransmitComplete.TcpPayload is finally wrong
(could it
> be negative since tx_length is smaller than the fixed tx_length?).
What about
> 953?

Not sure.

> One more thought: As mentioned earlier crashes often occurred after an
> uptime of 9-10 days and these crashes occurred too consistently to be
a "by
> chance" event. In my torture tests I am NOT USING a Windows NTP
service (I
> use the meinberg NTP daemon on Windows). But on production I do. Can
> you see any possible impact here?
> 

It's certainly more likely for a stray UDP packet to cause an upset I
guess. As the packets pass through a Linux firewall (iptables in Dom0)
it's more likely that errant TCP packets will be dropped there.

Do you have a crash dump against 0.11.0.323?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 23:26:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 23:26:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVAZo-00087Y-SY; Mon, 28 Nov 2011 23:25:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVAZn-00087T-6t
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 23:25:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322522694!5362057!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7487 invoked from network); 28 Nov 2011 23:24:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 23:24:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,587,1315180800"; 
   d="scan'208";a="9173653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 23:24:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 23:24:54 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVAZC-0007Ew-25;
	Mon, 28 Nov 2011 23:24:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVAZC-0001qF-1Y;
	Mon, 28 Nov 2011 23:24:54 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10176-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 23:24:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10176: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10176 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10176/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a2cb7ed6d0a2
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a2cb7ed6d0a2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a2cb7ed6d0a2
+ branch=xen-unstable
+ revision=a2cb7ed6d0a2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a2cb7ed6d0a2 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 67 changesets with 122 changes to 76 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 23:26:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 23:26:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVAZo-00087Y-SY; Mon, 28 Nov 2011 23:25:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVAZn-00087T-6t
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 23:25:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322522694!5362057!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDc3Nw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7487 invoked from network); 28 Nov 2011 23:24:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 23:24:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,587,1315180800"; 
   d="scan'208";a="9173653"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Nov 2011 23:24:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 28 Nov 2011 23:24:54 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVAZC-0007Ew-25;
	Mon, 28 Nov 2011 23:24:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVAZC-0001qF-1Y;
	Mon, 28 Nov 2011 23:24:54 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10176-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 28 Nov 2011 23:24:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10176: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10176 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10176/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail    like 9955
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a2cb7ed6d0a2
baseline version:
 xen                  0a0c02a61676

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Anil Madhavapeddy <anil@recoil.org>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a2cb7ed6d0a2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable a2cb7ed6d0a2
+ branch=xen-unstable
+ revision=a2cb7ed6d0a2
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a2cb7ed6d0a2 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 67 changesets with 122 changes to 76 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 23:41:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 23:41:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVApC-0002E4-5d; Mon, 28 Nov 2011 23:41:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RVAp6-0002Dt-Qt
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 23:41:21 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322523641!5993059!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10068 invoked from network); 28 Nov 2011 23:40:42 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 23:40:42 -0000
Received: by qadz3 with SMTP id z3so1194508qad.9
	for <xen-devel@lists.xensource.com>;
	Mon, 28 Nov 2011 15:40:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=9HYZVoJwlTK8n3TSzmfJTJzwANHEXZzS2sD+Vm5BGYI=;
	b=XWiBHn6/jZj90yjX7V4rOkCZ5Cpgo/0H5CZ5G5Q9Oc96QkRIeWwkBOnPTKhmnb8zrG
	6GAzVhegwtQh7MbJjBLQ==
Received: by 10.224.206.132 with SMTP id fu4mr21109847qab.20.1322523641371;
	Mon, 28 Nov 2011 15:40:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.206.132 with SMTP id fu4mr21109828qab.20.1322523641193;
	Mon, 28 Nov 2011 15:40:41 -0800 (PST)
Received: by 10.229.142.196 with HTTP; Mon, 28 Nov 2011 15:40:41 -0800 (PST)
In-Reply-To: <20111123103852.GG16665@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
Date: Mon, 28 Nov 2011 15:40:41 -0800
Message-ID: <CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Amit Shah <amit.shah@redhat.com>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Amit,

You said that the work would be serialized "due to port additions
being on work items on the same workqueue".  I'm not seeing that.
I've double checked this by using a mutex_trylock in
hvc_console::hvc_alloc(), and here's the relevant output from dmesg:

root@myubuntu:~# dmesg | grep MBH
[3307216.210274] MBH: got hvc_ports_mutex
[3307216.210690] MBH: trylock of hvc_ports_mutex failed
[3307216.211143] MBH: got hvc_ports_mutex

This is in a system with two virtio console ports, each of which is a
console.  I think if the VIRTIO_CONSOLE_CONSOLE_PORT message handling
were actually being serialized, the trylock should never fail.

What's the source of the serialization for the workqueue items?  At
first reading it looks like the control_work_handler gets called for
each virtio interrupt?

Miche


On Wed, Nov 23, 2011 at 2:38 AM, Amit Shah <amit.shah@redhat.com> wrote:
> On (Thu) 17 Nov 2011 [10:57:37], Miche Baker-Harvey wrote:
>> Rusty, Michael, Stephen, et al,
>>
>> Thanks for your comments on these patches.
>>
>> For what I'm trying to do, all three patches are necessary, but maybe
>> I'm going about it the wrong way. Your input would be appreciated.
>> I'm in no way claiming that these patches are "right", just that it's
>> working for me, and that what's in the current pool is not.
>>
>> What I'm trying to do is:
>> On X86,
>> under KVM,
>> start a virtio console device,
>> with multiple ports on the device,
>> at least one of which is also a console (as well as ttyS0).
>>
>> (Eventually, we want to be able to add virtio console ports on the
>> fly, and to have multiple virtio console ports be consoles.)
>
> Are you using kvm-tool to do this? =A0QEMU can already hot-plug ports
> and virtio-console (virtio-serial) devices.
>
>> When all three of the patches are in place, this works great. (By
>> great, I mean that getty's start up on all of ttyS0, hvc0 and hvc1,
>> and console output goes to ttyS0 and to hvc0.
>> "who" shows three users: =A0ttyS0, hvc0, and hvc1.
>> "cat /proc/consoles" shows both ttyS0 and hvc0.
>> I can use all three getty's, and console output really does appear on
>> both the consoles.
>>
>> Based on Rusty's comments, I tried removing each of the patches
>> individually. Here's what happens today. I've seen other failure modes
>> depending on what precisely I'm passing the guest.
>> There's three patches:
>> 1/3 "fix locking of vtermno"
>> 2/3 "enforce one-time initialization with hvc_init
>> "3/3 "use separate struct console * for each console"
>>
>> If I remove the "fix locking of vtermno", I only get one virtio
>> console terminal. =A0"who" shows the ttyS0 and the hvc0, and I can log
>> into the gettys on both. I don't get the second virtio console getty.
>> Interestingly, hvc0 shows up in /proc/consoles twice, and in fact the
>> console output is dumped twice to hvc0 (as you'd expect from looking
>> at printk.c, each line appears twice, followed by the next line.)
>
> I don't really understand why. =A0"fix locking of vtermno" adds locks in
> init_port_console(), which is called from add_port(), which should be
> serialised due to port additions being on work items on the same
> workqueue. =A0I don't see a race here.
>
>> If I remove the "enforce one-time initialization with hvc_init" patch,
>> which makes sure only a single thread is doing the hvc_init, and gates
>> anyone from continuing until it has completed, I get different
>> failures, including hangs, and dereferences of NULL pointers.
>>
>> If I remove the "use separate struct console * for each console"patch,
>> what I'm seeing now is that while all of ttyS0, hvc0, and hvc1 are
>> present with gettys running on them, of the three, only ttyS0 is a
>> console.
>
> I don't see any difference in my testing with and without these
> patches.
>
> This is how I tested with qemu:
>
> ./x86_64-softmmu/qemu-system-x86_64 -m 512 -smp 2 -chardev
> socket,path=3D/tmp/foo,server,nowait,id=3Dfoo -chardev
> socket,path=3D/tmp/bar,server,nowait,id=3Dbar -device virtio-serial
> -device virtconsole,chardev=3Dfoo,nr=3D4 -device
> virtconsole,chardev=3Dbar,nr=3D3 -net none =A0-kernel
> /home/amit/src/linux/arch/x86/boot/bzImage -append 'root=3D/dev/sda1
> console=3Dtty0 console=3DttyS0' -initrd /tmp/initramfs.img
> /guests/f14-nolvm.qcow2 -enable-kvm -snapshot
>
> With this setup, with and without patches, I can spawn two consoles
> via:
>
> /sbin/agetty /dev/hvc0 9600 vt100
> /sbin/agetty /dev/hvc1 9600 vt100
>
> (Strange thing is, the second one gives a 'password incorrect' error
> on login attempts, while the first one logs in fine. =A0I do remember
> testing multiple consoles just fine a year and a half back, so no idea
> why this isn't behaving as expected -- but it mostly looks like a
> userspace issue rather than kernel one.)
>
> As mentioned earlier, I've not looked at the hvc code, but given my
> testing results, I'd like to first understand what you're seeing and
> what your environment is.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Nov 28 23:41:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 28 Nov 2011 23:41:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVApC-0002E4-5d; Mon, 28 Nov 2011 23:41:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RVAp6-0002Dt-Qt
	for xen-devel@lists.xensource.com; Mon, 28 Nov 2011 23:41:21 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322523641!5993059!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10068 invoked from network); 28 Nov 2011 23:40:42 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Nov 2011 23:40:42 -0000
Received: by qadz3 with SMTP id z3so1194508qad.9
	for <xen-devel@lists.xensource.com>;
	Mon, 28 Nov 2011 15:40:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=9HYZVoJwlTK8n3TSzmfJTJzwANHEXZzS2sD+Vm5BGYI=;
	b=XWiBHn6/jZj90yjX7V4rOkCZ5Cpgo/0H5CZ5G5Q9Oc96QkRIeWwkBOnPTKhmnb8zrG
	6GAzVhegwtQh7MbJjBLQ==
Received: by 10.224.206.132 with SMTP id fu4mr21109847qab.20.1322523641371;
	Mon, 28 Nov 2011 15:40:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.206.132 with SMTP id fu4mr21109828qab.20.1322523641193;
	Mon, 28 Nov 2011 15:40:41 -0800 (PST)
Received: by 10.229.142.196 with HTTP; Mon, 28 Nov 2011 15:40:41 -0800 (PST)
In-Reply-To: <20111123103852.GG16665@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
Date: Mon, 28 Nov 2011 15:40:41 -0800
Message-ID: <CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Amit Shah <amit.shah@redhat.com>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Amit,

You said that the work would be serialized "due to port additions
being on work items on the same workqueue".  I'm not seeing that.
I've double checked this by using a mutex_trylock in
hvc_console::hvc_alloc(), and here's the relevant output from dmesg:

root@myubuntu:~# dmesg | grep MBH
[3307216.210274] MBH: got hvc_ports_mutex
[3307216.210690] MBH: trylock of hvc_ports_mutex failed
[3307216.211143] MBH: got hvc_ports_mutex

This is in a system with two virtio console ports, each of which is a
console.  I think if the VIRTIO_CONSOLE_CONSOLE_PORT message handling
were actually being serialized, the trylock should never fail.

What's the source of the serialization for the workqueue items?  At
first reading it looks like the control_work_handler gets called for
each virtio interrupt?

Miche


On Wed, Nov 23, 2011 at 2:38 AM, Amit Shah <amit.shah@redhat.com> wrote:
> On (Thu) 17 Nov 2011 [10:57:37], Miche Baker-Harvey wrote:
>> Rusty, Michael, Stephen, et al,
>>
>> Thanks for your comments on these patches.
>>
>> For what I'm trying to do, all three patches are necessary, but maybe
>> I'm going about it the wrong way. Your input would be appreciated.
>> I'm in no way claiming that these patches are "right", just that it's
>> working for me, and that what's in the current pool is not.
>>
>> What I'm trying to do is:
>> On X86,
>> under KVM,
>> start a virtio console device,
>> with multiple ports on the device,
>> at least one of which is also a console (as well as ttyS0).
>>
>> (Eventually, we want to be able to add virtio console ports on the
>> fly, and to have multiple virtio console ports be consoles.)
>
> Are you using kvm-tool to do this? =A0QEMU can already hot-plug ports
> and virtio-console (virtio-serial) devices.
>
>> When all three of the patches are in place, this works great. (By
>> great, I mean that getty's start up on all of ttyS0, hvc0 and hvc1,
>> and console output goes to ttyS0 and to hvc0.
>> "who" shows three users: =A0ttyS0, hvc0, and hvc1.
>> "cat /proc/consoles" shows both ttyS0 and hvc0.
>> I can use all three getty's, and console output really does appear on
>> both the consoles.
>>
>> Based on Rusty's comments, I tried removing each of the patches
>> individually. Here's what happens today. I've seen other failure modes
>> depending on what precisely I'm passing the guest.
>> There's three patches:
>> 1/3 "fix locking of vtermno"
>> 2/3 "enforce one-time initialization with hvc_init
>> "3/3 "use separate struct console * for each console"
>>
>> If I remove the "fix locking of vtermno", I only get one virtio
>> console terminal. =A0"who" shows the ttyS0 and the hvc0, and I can log
>> into the gettys on both. I don't get the second virtio console getty.
>> Interestingly, hvc0 shows up in /proc/consoles twice, and in fact the
>> console output is dumped twice to hvc0 (as you'd expect from looking
>> at printk.c, each line appears twice, followed by the next line.)
>
> I don't really understand why. =A0"fix locking of vtermno" adds locks in
> init_port_console(), which is called from add_port(), which should be
> serialised due to port additions being on work items on the same
> workqueue. =A0I don't see a race here.
>
>> If I remove the "enforce one-time initialization with hvc_init" patch,
>> which makes sure only a single thread is doing the hvc_init, and gates
>> anyone from continuing until it has completed, I get different
>> failures, including hangs, and dereferences of NULL pointers.
>>
>> If I remove the "use separate struct console * for each console"patch,
>> what I'm seeing now is that while all of ttyS0, hvc0, and hvc1 are
>> present with gettys running on them, of the three, only ttyS0 is a
>> console.
>
> I don't see any difference in my testing with and without these
> patches.
>
> This is how I tested with qemu:
>
> ./x86_64-softmmu/qemu-system-x86_64 -m 512 -smp 2 -chardev
> socket,path=3D/tmp/foo,server,nowait,id=3Dfoo -chardev
> socket,path=3D/tmp/bar,server,nowait,id=3Dbar -device virtio-serial
> -device virtconsole,chardev=3Dfoo,nr=3D4 -device
> virtconsole,chardev=3Dbar,nr=3D3 -net none =A0-kernel
> /home/amit/src/linux/arch/x86/boot/bzImage -append 'root=3D/dev/sda1
> console=3Dtty0 console=3DttyS0' -initrd /tmp/initramfs.img
> /guests/f14-nolvm.qcow2 -enable-kvm -snapshot
>
> With this setup, with and without patches, I can spawn two consoles
> via:
>
> /sbin/agetty /dev/hvc0 9600 vt100
> /sbin/agetty /dev/hvc1 9600 vt100
>
> (Strange thing is, the second one gives a 'password incorrect' error
> on login attempts, while the first one logs in fine. =A0I do remember
> testing multiple consoles just fine a year and a half back, so no idea
> why this isn't behaving as expected -- but it mostly looks like a
> userspace issue rather than kernel one.)
>
> As mentioned earlier, I've not looked at the hvc code, but given my
> testing results, I'd like to first understand what you're seeing and
> what your environment is.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 01:02:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 01:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVC53-0003VY-Qk; Tue, 29 Nov 2011 01:01:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RVC51-0002Oc-Ab
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 01:01:51 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322528434!47761897!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31792 invoked from network); 29 Nov 2011 01:00:35 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 01:00:35 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pAT11981009771
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 28 Nov 2011 17:01:11 -0800
Received: by bkbzt12 with SMTP id zt12so12149730bkb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 28 Nov 2011 17:01:08 -0800 (PST)
Received: by 10.205.132.146 with SMTP id hu18mr47778967bkc.123.1322528468304; 
	Mon, 28 Nov 2011 17:01:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.177.19 with HTTP; Mon, 28 Nov 2011 17:00:28 -0800 (PST)
In-Reply-To: <CAP8mzPO8w3RPtE-y6bzh7x=OZ0PJ+mPWQX+TFVDxY7+v5YXSsw@mail.gmail.com>
References: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
	<CAP8mzPO8w3RPtE-y6bzh7x=OZ0PJ+mPWQX+TFVDxY7+v5YXSsw@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 28 Nov 2011 17:00:28 -0800
Message-ID: <CAP8mzPOn39R4=LTKS3EAtF85uDEVY4czKkdAOwyUiuCjw=OtgQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 3 V7] libxc: checkpoint compression
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0184550072877816048=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0184550072877816048==
Content-Type: multipart/alternative; boundary=000e0ce02ace8f04d304b2d527f6

--000e0ce02ace8f04d304b2d527f6
Content-Type: text/plain; charset=ISO-8859-1

ping!

On Fri, Nov 18, 2011 at 12:06 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> Ian,
>  Do you have any other comments for this patch set?
>
> thanks
> shriram
>
>
> On Mon, Nov 14, 2011 at 2:51 PM, <rshriram@cs.ubc.ca> wrote:
>
>> This patch series adds checkpoint compression functionality, while
>> running under Remus.
>>
>> Changes since last version:
>> 1. renamed page_aligned_alloc to xc_memalign and declare it as a global
>>   function in xenctrl.h, instead of declaring it in xc_private.h
>>
>> Shriram
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>
>

--000e0ce02ace8f04d304b2d527f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

ping!<br><br><div class=3D"gmail_quote">On Fri, Nov 18, 2011 at 12:06 PM, S=
hriram Rajagopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.=
ca">rshriram@cs.ubc.ca</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex;">

Ian,<br>=A0Do you have any other comments for this patch set?<br><br>thanks=
<span class=3D"HOEnZb"><font color=3D"#888888"><br>shriram</font></span><di=
v class=3D"HOEnZb"><div class=3D"h5"><br><br><div class=3D"gmail_quote">On =
Mon, Nov 14, 2011 at 2:51 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:rshr=
iram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;</span> wrote:<=
br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">This patch series adds checkpoint compressio=
n functionality, while<br>
running under Remus.<br>
<br>
Changes since last version:<br>
1. renamed page_aligned_alloc to xc_memalign and declare it as a global<br>
 =A0 function in xenctrl.h, instead of declaring it in xc_private.h<br>
<br>
Shriram<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve=
l@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>
</div></div></blockquote></div><br>

--000e0ce02ace8f04d304b2d527f6--


--===============0184550072877816048==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0184550072877816048==--


From xen-devel-bounces@lists.xensource.com Tue Nov 29 01:02:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 01:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVC53-0003VY-Qk; Tue, 29 Nov 2011 01:01:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RVC51-0002Oc-Ab
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 01:01:51 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322528434!47761897!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31792 invoked from network); 29 Nov 2011 01:00:35 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 01:00:35 -0000
Received: from mail-bw0-f43.google.com (mail-bw0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id pAT11981009771
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 28 Nov 2011 17:01:11 -0800
Received: by bkbzt12 with SMTP id zt12so12149730bkb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 28 Nov 2011 17:01:08 -0800 (PST)
Received: by 10.205.132.146 with SMTP id hu18mr47778967bkc.123.1322528468304; 
	Mon, 28 Nov 2011 17:01:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.177.19 with HTTP; Mon, 28 Nov 2011 17:00:28 -0800 (PST)
In-Reply-To: <CAP8mzPO8w3RPtE-y6bzh7x=OZ0PJ+mPWQX+TFVDxY7+v5YXSsw@mail.gmail.com>
References: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
	<CAP8mzPO8w3RPtE-y6bzh7x=OZ0PJ+mPWQX+TFVDxY7+v5YXSsw@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 28 Nov 2011 17:00:28 -0800
Message-ID: <CAP8mzPOn39R4=LTKS3EAtF85uDEVY4czKkdAOwyUiuCjw=OtgQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 0 of 3 V7] libxc: checkpoint compression
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0184550072877816048=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0184550072877816048==
Content-Type: multipart/alternative; boundary=000e0ce02ace8f04d304b2d527f6

--000e0ce02ace8f04d304b2d527f6
Content-Type: text/plain; charset=ISO-8859-1

ping!

On Fri, Nov 18, 2011 at 12:06 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> Ian,
>  Do you have any other comments for this patch set?
>
> thanks
> shriram
>
>
> On Mon, Nov 14, 2011 at 2:51 PM, <rshriram@cs.ubc.ca> wrote:
>
>> This patch series adds checkpoint compression functionality, while
>> running under Remus.
>>
>> Changes since last version:
>> 1. renamed page_aligned_alloc to xc_memalign and declare it as a global
>>   function in xenctrl.h, instead of declaring it in xc_private.h
>>
>> Shriram
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>
>

--000e0ce02ace8f04d304b2d527f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

ping!<br><br><div class=3D"gmail_quote">On Fri, Nov 18, 2011 at 12:06 PM, S=
hriram Rajagopalan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.=
ca">rshriram@cs.ubc.ca</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex;">

Ian,<br>=A0Do you have any other comments for this patch set?<br><br>thanks=
<span class=3D"HOEnZb"><font color=3D"#888888"><br>shriram</font></span><di=
v class=3D"HOEnZb"><div class=3D"h5"><br><br><div class=3D"gmail_quote">On =
Mon, Nov 14, 2011 at 2:51 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:rshr=
iram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;</span> wrote:<=
br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">This patch series adds checkpoint compressio=
n functionality, while<br>
running under Remus.<br>
<br>
Changes since last version:<br>
1. renamed page_aligned_alloc to xc_memalign and declare it as a global<br>
 =A0 function in xenctrl.h, instead of declaring it in xc_private.h<br>
<br>
Shriram<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve=
l@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
</blockquote></div><br>
</div></div></blockquote></div><br>

--000e0ce02ace8f04d304b2d527f6--


--===============0184550072877816048==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0184550072877816048==--


From xen-devel-bounces@lists.xensource.com Tue Nov 29 04:44:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 04:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVFX6-0000cL-Gm; Tue, 29 Nov 2011 04:43:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVFX5-0000cG-D9
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 04:43:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322541745!4605505!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13704 invoked from network); 29 Nov 2011 04:42:26 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 04:42:26 -0000
Received: by ggnr4 with SMTP id r4so9755349ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 28 Nov 2011 20:42:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=DoF86AgkTeJWkY6EFLqyIPO2IFbMdFXMK+MLP7gWi2Q=;
	b=Ym8lfsU1HJJEDI5+wtE9l975aSr86bR2wMRHTt6pQPOb/X7MUvtb93qIeg5M8XN/lv
	G5OuScjh1ezU8Z/6ytJrBIvJo+ynJgPYjly9GGkn/mSkMARwDxHg9xzvfA5fyje48msT
	SVGxCwuUZSLlJfdYlU+B42Xzy8B9G9nlOtvF4=
Received: by 10.101.199.13 with SMTP id b13mr5202122anq.59.1322541744742;
	Mon, 28 Nov 2011 20:42:24 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id r4sm98654547anl.5.2011.11.28.20.42.19
	(version=SSLv3 cipher=OTHER); Mon, 28 Nov 2011 20:42:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 28 Nov 2011 20:42:16 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAF9A2A8.25D24%keir.xen@gmail.com>
Thread-Topic: Unaligned writes on the kexec path
Thread-Index: AcyuUUT+M+Yb7BAUg0a7oUupwAjMGQ==
In-Reply-To: <4ED399A7.1070108@citrix.com>
Mime-version: 1.0
Cc: horms@verge.net.au
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> Hello,
> 
> In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()

The patch is by Simon Horman, cc'ed, not me.

> to reduce unaligned writes, but pass the resulting pointer back to
> machine_crash_shutdown() which performs writes on the possibly unaligned
> data structure.  There are also plenty of other writes on the kexec path
> which are possibly or certainly unaligned.
> 
> What is the reason for wanting to reduce unaligned writes?

The patch is solving an IA64 issue. Machine_crash_shutdown is arch specific.

> Would a better solution be to just ensure that the crash note itself is
> properly aligned?

Could be.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 04:44:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 04:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVFX6-0000cL-Gm; Tue, 29 Nov 2011 04:43:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVFX5-0000cG-D9
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 04:43:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322541745!4605505!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13704 invoked from network); 29 Nov 2011 04:42:26 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 04:42:26 -0000
Received: by ggnr4 with SMTP id r4so9755349ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 28 Nov 2011 20:42:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=DoF86AgkTeJWkY6EFLqyIPO2IFbMdFXMK+MLP7gWi2Q=;
	b=Ym8lfsU1HJJEDI5+wtE9l975aSr86bR2wMRHTt6pQPOb/X7MUvtb93qIeg5M8XN/lv
	G5OuScjh1ezU8Z/6ytJrBIvJo+ynJgPYjly9GGkn/mSkMARwDxHg9xzvfA5fyje48msT
	SVGxCwuUZSLlJfdYlU+B42Xzy8B9G9nlOtvF4=
Received: by 10.101.199.13 with SMTP id b13mr5202122anq.59.1322541744742;
	Mon, 28 Nov 2011 20:42:24 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id r4sm98654547anl.5.2011.11.28.20.42.19
	(version=SSLv3 cipher=OTHER); Mon, 28 Nov 2011 20:42:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 28 Nov 2011 20:42:16 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAF9A2A8.25D24%keir.xen@gmail.com>
Thread-Topic: Unaligned writes on the kexec path
Thread-Index: AcyuUUT+M+Yb7BAUg0a7oUupwAjMGQ==
In-Reply-To: <4ED399A7.1070108@citrix.com>
Mime-version: 1.0
Cc: horms@verge.net.au
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> Hello,
> 
> In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()

The patch is by Simon Horman, cc'ed, not me.

> to reduce unaligned writes, but pass the resulting pointer back to
> machine_crash_shutdown() which performs writes on the possibly unaligned
> data structure.  There are also plenty of other writes on the kexec path
> which are possibly or certainly unaligned.
> 
> What is the reason for wanting to reduce unaligned writes?

The patch is solving an IA64 issue. Machine_crash_shutdown is arch specific.

> Would a better solution be to just ensure that the crash note itself is
> properly aligned?

Could be.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 04:50:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 04:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVFdu-0000lg-Dt; Tue, 29 Nov 2011 04:50:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVFdt-0000lY-GW
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 04:50:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322542168!5953101!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDg4Ng==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31776 invoked from network); 29 Nov 2011 04:49:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 04:49:28 -0000
X-IronPort-AV: E=Sophos;i="4.69,589,1315180800"; 
   d="scan'208";a="9174972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 04:49:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 04:49:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVFdI-0000Zu-3O;
	Tue, 29 Nov 2011 04:49:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVFdH-0003eV-T4;
	Tue, 29 Nov 2011 04:49:27 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10182-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 04:49:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10182: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10182 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10182/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10176
 test-i386-i386-win           14 guest-start.2      fail in 10176 pass in 10182

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a2cb7ed6d0a2
baseline version:
 xen                  a2cb7ed6d0a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 04:50:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 04:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVFdu-0000lg-Dt; Tue, 29 Nov 2011 04:50:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVFdt-0000lY-GW
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 04:50:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322542168!5953101!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDg4Ng==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31776 invoked from network); 29 Nov 2011 04:49:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 04:49:28 -0000
X-IronPort-AV: E=Sophos;i="4.69,589,1315180800"; 
   d="scan'208";a="9174972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 04:49:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 04:49:28 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVFdI-0000Zu-3O;
	Tue, 29 Nov 2011 04:49:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVFdH-0003eV-T4;
	Tue, 29 Nov 2011 04:49:27 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10182-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 04:49:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10182: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10182 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10182/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10176
 test-i386-i386-win           14 guest-start.2      fail in 10176 pass in 10182

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  a2cb7ed6d0a2
baseline version:
 xen                  a2cb7ed6d0a2

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 05:53:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 05:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVGcB-0001JF-MA; Tue, 29 Nov 2011 05:52:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <horms@verge.net.au>) id 1RVGcA-0001J6-CY
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 05:52:22 +0000
X-Env-Sender: horms@verge.net.au
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322545904!5384110!1
X-Originating-IP: [202.4.237.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17208 invoked from network); 29 Nov 2011 05:51:45 -0000
Received: from kirsty.vergenet.net (HELO kirsty.vergenet.net) (202.4.237.240)
	by server-6.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 05:51:45 -0000
Received: from joe.kanocho.kobe.vergenet.net
	(221x245x165x18.ap221.ftth.ucom.ne.jp [221.245.165.18])
	by kirsty.vergenet.net (Postfix) with ESMTP id 2165025BE05;
	Tue, 29 Nov 2011 16:51:41 +1100 (EST)
Received: by joe.kanocho.kobe.vergenet.net (Postfix, from userid 7100)
	id 53DF028A02E; Tue, 29 Nov 2011 14:51:39 +0900 (JST)
Date: Tue, 29 Nov 2011 14:51:39 +0900
From: Simon Horman <horms@verge.net.au>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111129055139.GB3222@verge.net.au>
References: <4ED399A7.1070108@citrix.com> <CAF9A2A8.25D24%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF9A2A8.25D24%keir.xen@gmail.com>
Organisation: Horms Solutions Ltd.
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Keir, Hi Andrew,

On Mon, Nov 28, 2011 at 08:42:16PM +0000, Keir Fraser wrote:
> On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
> 
> > Hello,
> > 
> > In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
> 
> The patch is by Simon Horman, cc'ed, not me.
> 
> > to reduce unaligned writes, but pass the resulting pointer back to
> > machine_crash_shutdown() which performs writes on the possibly unaligned
> > data structure.  There are also plenty of other writes on the kexec path
> > which are possibly or certainly unaligned.
> > 
> > What is the reason for wanting to reduce unaligned writes?
> 
> The patch is solving an IA64 issue. Machine_crash_shutdown is arch specific.
> 
> > Would a better solution be to just ensure that the crash note itself is
> > properly aligned?
> 
> Could be.

Its a while since I wrote that change, but I believe that aligning
the crash note would resolve the problem that I observed.

As Keir mentions, machine_crash_shutdown() is architecture specific
and I am not sure that I see the ia64 version making any unaligned writes.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 05:53:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 05:53:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVGcB-0001JF-MA; Tue, 29 Nov 2011 05:52:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <horms@verge.net.au>) id 1RVGcA-0001J6-CY
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 05:52:22 +0000
X-Env-Sender: horms@verge.net.au
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322545904!5384110!1
X-Originating-IP: [202.4.237.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17208 invoked from network); 29 Nov 2011 05:51:45 -0000
Received: from kirsty.vergenet.net (HELO kirsty.vergenet.net) (202.4.237.240)
	by server-6.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 05:51:45 -0000
Received: from joe.kanocho.kobe.vergenet.net
	(221x245x165x18.ap221.ftth.ucom.ne.jp [221.245.165.18])
	by kirsty.vergenet.net (Postfix) with ESMTP id 2165025BE05;
	Tue, 29 Nov 2011 16:51:41 +1100 (EST)
Received: by joe.kanocho.kobe.vergenet.net (Postfix, from userid 7100)
	id 53DF028A02E; Tue, 29 Nov 2011 14:51:39 +0900 (JST)
Date: Tue, 29 Nov 2011 14:51:39 +0900
From: Simon Horman <horms@verge.net.au>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20111129055139.GB3222@verge.net.au>
References: <4ED399A7.1070108@citrix.com> <CAF9A2A8.25D24%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAF9A2A8.25D24%keir.xen@gmail.com>
Organisation: Horms Solutions Ltd.
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Keir, Hi Andrew,

On Mon, Nov 28, 2011 at 08:42:16PM +0000, Keir Fraser wrote:
> On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
> 
> > Hello,
> > 
> > In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
> 
> The patch is by Simon Horman, cc'ed, not me.
> 
> > to reduce unaligned writes, but pass the resulting pointer back to
> > machine_crash_shutdown() which performs writes on the possibly unaligned
> > data structure.  There are also plenty of other writes on the kexec path
> > which are possibly or certainly unaligned.
> > 
> > What is the reason for wanting to reduce unaligned writes?
> 
> The patch is solving an IA64 issue. Machine_crash_shutdown is arch specific.
> 
> > Would a better solution be to just ensure that the crash note itself is
> > properly aligned?
> 
> Could be.

Its a while since I wrote that change, but I believe that aligning
the crash note would resolve the problem that I observed.

As Keir mentions, machine_crash_shutdown() is architecture specific
and I am not sure that I see the ia64 version making any unaligned writes.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 08:32:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 08:32:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVJ6O-0003bu-Fs; Tue, 29 Nov 2011 08:31:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVJ6M-0003bp-Ic
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 08:31:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322555465!5095553!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTI=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18061 invoked from network); 29 Nov 2011 08:31:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 08:31:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 29 Nov 2011 08:31:04 +0000
Message-Id: <4ED4A6580200007800063F87@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 29 Nov 2011 08:31:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
	<20111128164516.GA26664@phenom.dumpdata.com>
In-Reply-To: <20111128164516.GA26664@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"lersek@redhat.com" <lersek@redhat.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Carsten Schiers <carsten@schiers.de>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 28.11.11 at 17:45, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> But I can't find the implementation of that in the classic Xen-SWIOTLB.

linux-2.6.18-xen.hg/arch/i386/kernel/pci-dma-xen.c:dma_alloc_coherent().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 08:32:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 08:32:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVJ6O-0003bu-Fs; Tue, 29 Nov 2011 08:31:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVJ6M-0003bp-Ic
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 08:31:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322555465!5095553!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyNTI=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18061 invoked from network); 29 Nov 2011 08:31:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 08:31:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 29 Nov 2011 08:31:04 +0000
Message-Id: <4ED4A6580200007800063F87@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 29 Nov 2011 08:31:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
	<20111128164516.GA26664@phenom.dumpdata.com>
In-Reply-To: <20111128164516.GA26664@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"lersek@redhat.com" <lersek@redhat.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Carsten Schiers <carsten@schiers.de>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 28.11.11 at 17:45, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> But I can't find the implementation of that in the classic Xen-SWIOTLB.

linux-2.6.18-xen.hg/arch/i386/kernel/pci-dma-xen.c:dma_alloc_coherent().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 09:32:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 09:32:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVK2W-0004gS-Ez; Tue, 29 Nov 2011 09:31:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RVK2U-0004fh-Ej
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 09:31:47 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322559068!3493828!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.1 required=7.0 tests=FROM_EXCESS_QP,HTML_50_60,
	HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11441 invoked from network); 29 Nov 2011 09:31:08 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 09:31:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=jqd1o3ruWb4QaqReTvF9aUzGojSEz
	/A6ZyN8rL2/oEE=; b=CJ4Rs7YjBFgEuL20PvH1zmJY7GzEF5gDwm7bMMTHNPL37
	Yp+yq48CEpeAAuxbqboHT2nazK9wH3fZ9jXtrP9HKGTFlYjFqyFqMadgGeNcIGCx
	d7mu1iiGtsfz44n7Qd8ZFBynF++WQEFFBauRsAUktxGeNDNju0vhmJIXu1g1yc=
Received: (qmail 19760 invoked from network); 29 Nov 2011 10:31:07 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.180.138)
	by mail.zeus06.de with ESMTPA; 29 Nov 2011 10:31:07 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id BDFC72C51B;
	Tue, 29 Nov 2011 10:31:07 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Bqtv5KSY8ANQ; Tue, 29 Nov 2011 10:31:02 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 383882C51A;
	Tue, 29 Nov 2011 10:31:02 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Jan_Beulich?= <JBeulich@suse.com>, =?utf-8?Q?Konrad_Rzesz?=
	=?utf-8?Q?utek_Wilk?= <konrad.wilk@oracle.com>
Date: Tue, 29 Nov 2011 10:31:02 +0100
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="=_mpaRqw5ZTb1NyohKK81n2EoHfBUfa6Wj7ICZiy9X+A95qsfm"
In-Reply-To: <4ED4A6580200007800063F87@nat28.tlf.novell.com>
References: <4ED4A6580200007800063F87@nat28.tlf.novell.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ed4a656.52fd.63ce1a9050a2a2e3@uhura.space.zz>
Cc: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?Ian_Campbell?= <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_mpaRqw5ZTb1NyohKK81n2EoHfBUfa6Wj7ICZiy9X+A95qsfm
Content-Type: multipart/alternative; 
 boundary="=_mpaRxkcu7CvRhUgYoUDQFC5l0pCO1fL+EfgdphTAfYTKa7HA"

--=_mpaRxkcu7CvRhUgYoUDQFC5l0pCO1fL+EfgdphTAfYTKa7HA
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I attached the actualy used 2.6.34 file here, if that helps. BR,C.=0D=0A=C2=
=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-----=0D=0AAn:Konrad Rzeszutek =
Wilk <konrad.wilk@oracle.com>;=20=0D=0ACC:Ian Campbell <Ian.Campbell@citr=
ix.com>; Konrad Rzeszutek Wilk <konrad@darnok.org>; xen-devel <xen-devel@=
lists.xensource.com>; zhenzhong.duan@oracle.com; lersek@redhat.com; Carst=
en Schiers <carsten@schiers.de>;=20=0D=0AVon:Jan Beulich <JBeulich@suse.c=
om>=0D=0AGesendet:Di 29.11.2011 09:52=0D=0ABetreff:Re: [Xen-devel] Load i=
ncrease after memory upgrade (part2)=0D=0A>>> On 28.11.11 at 17:45, Konra=
d Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:=0D=0A> But I can't find =
the implementation of that in the classic Xen-SWIOTLB.=0D=0A=0D=0Alinux-2=
=2E6.18-xen.hg/arch/i386/kernel/pci-dma-xen.c:dma_alloc_coherent().=0D=0A=
=0D=0AJan=0D=0A=0D=0A
--=_mpaRxkcu7CvRhUgYoUDQFC5l0pCO1fL+EfgdphTAfYTKa7HA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
p>I attached the actualy used 2.6.34 file here, if that helps. BR,C.<br /=
>&nbsp;</p><blockquote style=3D"border-left: 2px solid #325FBA; padding-l=
eft: 5px;margin-left:5px;">-----Urspr&uuml;ngliche Nachricht-----<br /><s=
trong>An:</strong>=09Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;=
; <br /><strong>CC:</strong>=09Ian Campbell &lt;Ian.Campbell@citrix.com&g=
t;; Konrad Rzeszutek Wilk &lt;konrad@darnok.org&gt;; xen-devel &lt;xen-de=
vel@lists.xensource.com&gt;; zhenzhong.duan@oracle.com; lersek@redhat.com=
; Carsten Schiers &lt;carsten@schiers.de&gt;; <br /><strong>Von:</strong>=
=09Jan Beulich &lt;JBeulich@suse.com&gt;<br /><strong>Gesendet:</strong>=09=
Di 29.11.2011 09:52<br /><strong>Betreff:</strong>=09Re: [Xen-devel] Load=
 increase after memory upgrade (part2)<br />&gt;&gt;&gt; On 28.11.11 at 1=
7:45, Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt; wrote:<br />&g=
t; But I can&#39;t find the implementation of that in the classic Xen-SWI=
OTLB.<br /><br />linux-2.6.18-xen.hg/arch/i386/kernel/pci-dma-xen.c:dma_a=
lloc_coherent().<br /><br />Jan<br /><br /></blockquote>=0A</body>=0A</ht=
ml>
--=_mpaRxkcu7CvRhUgYoUDQFC5l0pCO1fL+EfgdphTAfYTKa7HA--

--=_mpaRqw5ZTb1NyohKK81n2EoHfBUfa6Wj7ICZiy9X+A95qsfm
Content-Type: application/octet-stream; name=pci-dma-xen.c
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=pci-dma-xen.c

I2luY2x1ZGUgPGxpbnV4L2RtYS1tYXBwaW5nLmg+CiNpbmNsdWRlIDxsaW51eC9kbWEtZGVi
dWcuaD4KI2luY2x1ZGUgPGxpbnV4L2RtYXIuaD4KI2luY2x1ZGUgPGxpbnV4L2Jvb3RtZW0u
aD4KI2luY2x1ZGUgPGxpbnV4L2dmcC5oPgojaW5jbHVkZSA8bGludXgvcGNpLmg+CiNpbmNs
dWRlIDxsaW51eC9rbWVtbGVhay5oPgoKI2luY2x1ZGUgPGFzbS9wcm90by5oPgojaW5jbHVk
ZSA8YXNtL2RtYS5oPgojaW5jbHVkZSA8YXNtL2lvbW11Lmg+CiNpbmNsdWRlIDxhc20vZ2Fy
dC5oPgojaW5jbHVkZSA8YXNtL2NhbGdhcnkuaD4KI2luY2x1ZGUgPGFzbS9hbWRfaW9tbXUu
aD4KI2luY2x1ZGUgPGFzbS94ODZfaW5pdC5oPgoKc3RhdGljIGludCBmb3JiaWRfZGFjIF9f
cmVhZF9tb3N0bHk7CgpzdHJ1Y3QgZG1hX21hcF9vcHMgKmRtYV9vcHMgPSAmbm9tbXVfZG1h
X29wczsKRVhQT1JUX1NZTUJPTChkbWFfb3BzKTsKCnN0YXRpYyBpbnQgaW9tbXVfc2FjX2Zv
cmNlIF9fcmVhZF9tb3N0bHk7CgojaWZkZWYgQ09ORklHX0lPTU1VX0RFQlVHCmludCBwYW5p
Y19vbl9vdmVyZmxvdyBfX3JlYWRfbW9zdGx5ID0gMTsKaW50IGZvcmNlX2lvbW11IF9fcmVh
ZF9tb3N0bHkgPSAxOwojZWxzZQppbnQgcGFuaWNfb25fb3ZlcmZsb3cgX19yZWFkX21vc3Rs
eSA9IDA7CmludCBmb3JjZV9pb21tdSBfX3JlYWRfbW9zdGx5ID0gMDsKI2VuZGlmCgppbnQg
aW9tbXVfbWVyZ2UgX19yZWFkX21vc3RseSA9IDA7CgppbnQgbm9faW9tbXUgX19yZWFkX21v
c3RseTsKLyogU2V0IHRoaXMgdG8gMSBpZiB0aGVyZSBpcyBhIEhXIElPTU1VIGluIHRoZSBz
eXN0ZW0gKi8KaW50IGlvbW11X2RldGVjdGVkIF9fcmVhZF9tb3N0bHkgPSAwOwoKLyoKICog
VGhpcyB2YXJpYWJsZSBiZWNvbWVzIDEgaWYgaW9tbXU9cHQgaXMgcGFzc2VkIG9uIHRoZSBr
ZXJuZWwgY29tbWFuZCBsaW5lLgogKiBJZiB0aGlzIHZhcmlhYmxlIGlzIDEsIElPTU1VIGlt
cGxlbWVudGF0aW9ucyBkbyBubyBETUEgdHJhbnNsYXRpb24gZm9yCiAqIGRldmljZXMgYW5k
IGFsbG93IGV2ZXJ5IGRldmljZSB0byBhY2Nlc3MgdG8gd2hvbGUgcGh5c2ljYWwgbWVtb3J5
LiBUaGlzIGlzCiAqIHVzZWZ1bCBpZiBhIHVzZXIgd2FudHMgdG8gdXNlIGFuIElPTU1VIG9u
bHkgZm9yIEtWTSBkZXZpY2UgYXNzaWdubWVudCB0bwogKiBndWVzdHMgYW5kIG5vdCBmb3Ig
ZHJpdmVyIGRtYSB0cmFuc2xhdGlvbi4KICovCmludCBpb21tdV9wYXNzX3Rocm91Z2ggX19y
ZWFkX21vc3RseTsKCi8qIER1bW15IGRldmljZSB1c2VkIGZvciBOVUxMIGFyZ3VtZW50cyAo
bm9ybWFsbHkgSVNBKS4gKi8Kc3RydWN0IGRldmljZSB4ODZfZG1hX2ZhbGxiYWNrX2RldiA9
IHsKCS5pbml0X25hbWUgPSAiZmFsbGJhY2sgZGV2aWNlIiwKCS5jb2hlcmVudF9kbWFfbWFz
ayA9IElTQV9ETUFfQklUX01BU0ssCgkuZG1hX21hc2sgPSAmeDg2X2RtYV9mYWxsYmFja19k
ZXYuY29oZXJlbnRfZG1hX21hc2ssCn07CkVYUE9SVF9TWU1CT0woeDg2X2RtYV9mYWxsYmFj
a19kZXYpOwoKLyogTnVtYmVyIG9mIGVudHJpZXMgcHJlYWxsb2NhdGVkIGZvciBETUEtQVBJ
IGRlYnVnZ2luZyAqLwojZGVmaW5lIFBSRUFMTE9DX0RNQV9ERUJVR19FTlRSSUVTICAgICAg
IDMyNzY4CgppbnQgZG1hX3NldF9tYXNrKHN0cnVjdCBkZXZpY2UgKmRldiwgdTY0IG1hc2sp
CnsKCWlmICghZGV2LT5kbWFfbWFzayB8fCAhZG1hX3N1cHBvcnRlZChkZXYsIG1hc2spKQoJ
CXJldHVybiAtRUlPOwoKCSpkZXYtPmRtYV9tYXNrID0gbWFzazsKCglyZXR1cm4gMDsKfQpF
WFBPUlRfU1lNQk9MKGRtYV9zZXRfbWFzayk7CgojaWYgZGVmaW5lZChDT05GSUdfWDg2XzY0
KSAmJiAhZGVmaW5lZChDT05GSUdfTlVNQSkgJiYgIWRlZmluZWQoQ09ORklHX1hFTikKc3Rh
dGljIF9faW5pdGRhdGEgdm9pZCAqZG1hMzJfYm9vdG1lbV9wdHI7CnN0YXRpYyB1bnNpZ25l
ZCBsb25nIGRtYTMyX2Jvb3RtZW1fc2l6ZSBfX2luaXRkYXRhID0gKDEyOFVMTDw8MjApOwoK
c3RhdGljIGludCBfX2luaXQgcGFyc2VfZG1hMzJfc2l6ZV9vcHQoY2hhciAqcCkKewoJaWYg
KCFwKQoJCXJldHVybiAtRUlOVkFMOwoJZG1hMzJfYm9vdG1lbV9zaXplID0gbWVtcGFyc2Uo
cCwgJnApOwoJcmV0dXJuIDA7Cn0KZWFybHlfcGFyYW0oImRtYTMyX3NpemUiLCBwYXJzZV9k
bWEzMl9zaXplX29wdCk7Cgp2b2lkIF9faW5pdCBkbWEzMl9yZXNlcnZlX2Jvb3RtZW0odm9p
ZCkKewoJdW5zaWduZWQgbG9uZyBzaXplLCBhbGlnbjsKCWlmIChtYXhfcGZuIDw9IE1BWF9E
TUEzMl9QRk4pCgkJcmV0dXJuOwoKCS8qCgkgKiBjaGVjayBhcGVydHVyZV82NC5jIGFsbG9j
YXRlX2FwZXJ0dXJlKCkgZm9yIHJlYXNvbiBhYm91dAoJICogdXNpbmcgNTEyTSBhcyBnb2Fs
CgkgKi8KCWFsaWduID0gNjRVTEw8PDIwOwoJc2l6ZSA9IHJvdW5kdXAoZG1hMzJfYm9vdG1l
bV9zaXplLCBhbGlnbik7CglkbWEzMl9ib290bWVtX3B0ciA9IF9fYWxsb2NfYm9vdG1lbV9u
b3BhbmljKHNpemUsIGFsaWduLAoJCQkJIDUxMlVMTDw8MjApOwoJLyoKCSAqIEttZW1sZWFr
IHNob3VsZCBub3Qgc2NhbiB0aGlzIGJsb2NrIGFzIGl0IG1heSBub3QgYmUgbWFwcGVkIHZp
YSB0aGUKCSAqIGtlcm5lbCBkaXJlY3QgbWFwcGluZy4KCSAqLwoJa21lbWxlYWtfaWdub3Jl
KGRtYTMyX2Jvb3RtZW1fcHRyKTsKCWlmIChkbWEzMl9ib290bWVtX3B0cikKCQlkbWEzMl9i
b290bWVtX3NpemUgPSBzaXplOwoJZWxzZQoJCWRtYTMyX2Jvb3RtZW1fc2l6ZSA9IDA7Cn0K
c3RhdGljIHZvaWQgX19pbml0IGRtYTMyX2ZyZWVfYm9vdG1lbSh2b2lkKQp7CgoJaWYgKG1h
eF9wZm4gPD0gTUFYX0RNQTMyX1BGTikKCQlyZXR1cm47CgoJaWYgKCFkbWEzMl9ib290bWVt
X3B0cikKCQlyZXR1cm47CgoJZnJlZV9ib290bWVtKF9fcGEoZG1hMzJfYm9vdG1lbV9wdHIp
LCBkbWEzMl9ib290bWVtX3NpemUpOwoKCWRtYTMyX2Jvb3RtZW1fcHRyID0gTlVMTDsKCWRt
YTMyX2Jvb3RtZW1fc2l6ZSA9IDA7Cn0KI2Vsc2UKdm9pZCBfX2luaXQgZG1hMzJfcmVzZXJ2
ZV9ib290bWVtKHZvaWQpCnsKfQpzdGF0aWMgdm9pZCBfX2luaXQgZG1hMzJfZnJlZV9ib290
bWVtKHZvaWQpCnsKfQoKI2VuZGlmCgpzdGF0aWMgc3RydWN0IGRtYV9tYXBfb3BzIHN3aW90
bGJfZG1hX29wcyA9IHsKCS5hbGxvY19jb2hlcmVudCA9IGRtYV9nZW5lcmljX2FsbG9jX2Nv
aGVyZW50LAoJLmZyZWVfY29oZXJlbnQgPSBkbWFfZ2VuZXJpY19mcmVlX2NvaGVyZW50LAoJ
Lm1hcHBpbmdfZXJyb3IgPSBzd2lvdGxiX2RtYV9tYXBwaW5nX2Vycm9yLAoJLm1hcF9wYWdl
ID0gc3dpb3RsYl9tYXBfcGFnZSwKCS51bm1hcF9wYWdlID0gc3dpb3RsYl91bm1hcF9wYWdl
LAoJLnN5bmNfc2luZ2xlX2Zvcl9jcHUgPSBzd2lvdGxiX3N5bmNfc2luZ2xlX2Zvcl9jcHUs
Cgkuc3luY19zaW5nbGVfZm9yX2RldmljZSA9IHN3aW90bGJfc3luY19zaW5nbGVfZm9yX2Rl
dmljZSwKCS5zeW5jX3NpbmdsZV9yYW5nZV9mb3JfY3B1ID0gc3dpb3RsYl9zeW5jX3Npbmds
ZV9yYW5nZV9mb3JfY3B1LAoJLnN5bmNfc2luZ2xlX3JhbmdlX2Zvcl9kZXZpY2UgPSBzd2lv
dGxiX3N5bmNfc2luZ2xlX3JhbmdlX2Zvcl9kZXZpY2UsCgkuc3luY19zZ19mb3JfY3B1ID0g
c3dpb3RsYl9zeW5jX3NnX2Zvcl9jcHUsCgkuc3luY19zZ19mb3JfZGV2aWNlID0gc3dpb3Rs
Yl9zeW5jX3NnX2Zvcl9kZXZpY2UsCgkubWFwX3NnID0gc3dpb3RsYl9tYXBfc2dfYXR0cnMs
CgkudW5tYXBfc2cgPSBzd2lvdGxiX3VubWFwX3NnX2F0dHJzLAoJLmRtYV9zdXBwb3J0ZWQg
PSBzd2lvdGxiX2RtYV9zdXBwb3J0ZWQKfTsKCnZvaWQgX19pbml0IHBjaV9pb21tdV9hbGxv
Yyh2b2lkKQp7CgkvKiBmcmVlIHRoZSByYW5nZSBzbyBpb21tdSBjb3VsZCBnZXQgc29tZSBy
YW5nZSBsZXNzIHRoYW4gNEcgKi8KCWRtYTMyX2ZyZWVfYm9vdG1lbSgpOwoKCWlmIChwY2lf
c3dpb3RsYl9kZXRlY3QoKSkKCQlnb3RvIG91dDsKCglnYXJ0X2lvbW11X2hvbGVfaW5pdCgp
OwoKCWRldGVjdF9jYWxnYXJ5KCk7CgoJZGV0ZWN0X2ludGVsX2lvbW11KCk7CgoJLyogbmVl
ZHMgdG8gYmUgY2FsbGVkIGFmdGVyIGdhcnRfaW9tbXVfaG9sZV9pbml0ICovCglhbWRfaW9t
bXVfZGV0ZWN0KCk7Cm91dDoKCXN3aW90bGJfaW5pdCgxKTsKCWlmIChzd2lvdGxiKSB7CgkJ
cHJpbnRrKEtFUk5fSU5GTyAiUENJLURNQTogVXNpbmcgc29mdHdhcmUgYm91bmNlIGJ1ZmZl
cmluZyBmb3IgSU8gKFNXSU9UTEIpXG4iKTsKCQlkbWFfb3BzID0gJnN3aW90bGJfZG1hX29w
czsKCX0KfQoKdm9pZCAqZG1hX2dlbmVyaWNfYWxsb2NfY29oZXJlbnQoc3RydWN0IGRldmlj
ZSAqZGV2LCBzaXplX3Qgc2l6ZSwKCQkJCSBkbWFfYWRkcl90ICpkbWFfYWRkciwgZ2ZwX3Qg
ZmxhZykKewoJdW5zaWduZWQgbG9uZyBkbWFfbWFzazsKCXN0cnVjdCBwYWdlICpwYWdlOwoj
aWZuZGVmIENPTkZJR19YRU4KCWRtYV9hZGRyX3QgYWRkcjsKI2Vsc2UKCXZvaWQgKm1lbW9y
eTsKI2VuZGlmCgl1bnNpZ25lZCBpbnQgb3JkZXIgPSBnZXRfb3JkZXIoc2l6ZSk7CgoJZG1h
X21hc2sgPSBkbWFfYWxsb2NfY29oZXJlbnRfbWFzayhkZXYsIGZsYWcpOwoKI2lmbmRlZiBD
T05GSUdfWEVOCglmbGFnIHw9IF9fR0ZQX1pFUk87CmFnYWluOgojZWxzZQoJZmxhZyAmPSB+
KF9fR0ZQX0RNQSB8IF9fR0ZQX0RNQTMyKTsKI2VuZGlmCglwYWdlID0gYWxsb2NfcGFnZXNf
bm9kZShkZXZfdG9fbm9kZShkZXYpLCBmbGFnLCBvcmRlcik7CglpZiAoIXBhZ2UpCgkJcmV0
dXJuIE5VTEw7CgojaWZuZGVmIENPTkZJR19YRU4KCWFkZHIgPSBwYWdlX3RvX3BoeXMocGFn
ZSk7CglpZiAoYWRkciArIHNpemUgPiBkbWFfbWFzaykgewoJCV9fZnJlZV9wYWdlcyhwYWdl
LCBvcmRlcik7CgoJCWlmIChkbWFfbWFzayA8IERNQV9CSVRfTUFTSygzMikgJiYgIShmbGFn
ICYgR0ZQX0RNQSkpIHsKCQkJZmxhZyA9IChmbGFnICYgfkdGUF9ETUEzMikgfCBHRlBfRE1B
OwoJCQlnb3RvIGFnYWluOwoJCX0KCgkJcmV0dXJuIE5VTEw7Cgl9CgoJKmRtYV9hZGRyID0g
YWRkcjsKCXJldHVybiBwYWdlX2FkZHJlc3MocGFnZSk7CiNlbHNlCgltZW1vcnkgPSBwYWdl
X2FkZHJlc3MocGFnZSk7CglpZiAoeGVuX2NyZWF0ZV9jb250aWd1b3VzX3JlZ2lvbigodW5z
aWduZWQgbG9uZyltZW1vcnksIG9yZGVyLAoJCQkJCSBmbHM2NChkbWFfbWFzaykpKSB7CgkJ
X19mcmVlX3BhZ2VzKHBhZ2UsIG9yZGVyKTsKCQlyZXR1cm4gTlVMTDsKCX0KCgkqZG1hX2Fk
ZHIgPSB2aXJ0X3RvX2J1cyhtZW1vcnkpOwoJcmV0dXJuIG1lbXNldChtZW1vcnksIDAsIHNp
emUpOwojZW5kaWYKfQoKI2lmZGVmIENPTkZJR19YRU4Kdm9pZCBkbWFfZ2VuZXJpY19mcmVl
X2NvaGVyZW50KHN0cnVjdCBkZXZpY2UgKmRldiwgc2l6ZV90IHNpemUsIHZvaWQgKnZhZGRy
LAoJCQkgICAgICAgZG1hX2FkZHJfdCBkbWFfYWRkcikKewoJdW5zaWduZWQgaW50IG9yZGVy
ID0gZ2V0X29yZGVyKHNpemUpOwoJdW5zaWduZWQgbG9uZyB2YSA9ICh1bnNpZ25lZCBsb25n
KXZhZGRyOwoKCXhlbl9kZXN0cm95X2NvbnRpZ3VvdXNfcmVnaW9uKHZhLCBvcmRlcik7Cglm
cmVlX3BhZ2VzKHZhLCBvcmRlcik7Cn0KI2VuZGlmCgovKgogKiBTZWUgPERvY3VtZW50YXRp
b24veDg2XzY0L2Jvb3Qtb3B0aW9ucy50eHQ+IGZvciB0aGUgaW9tbXUga2VybmVsIHBhcmFt
ZXRlcgogKiBkb2N1bWVudGF0aW9uLgogKi8Kc3RhdGljIF9faW5pdCBpbnQgaW9tbXVfc2V0
dXAoY2hhciAqcCkKewoJaW9tbXVfbWVyZ2UgPSAxOwoKCWlmICghcCkKCQlyZXR1cm4gLUVJ
TlZBTDsKCgl3aGlsZSAoKnApIHsKCQlpZiAoIXN0cm5jbXAocCwgIm9mZiIsIDMpKQoJCQlu
b19pb21tdSA9IDE7CgkJLyogZ2FydF9wYXJzZV9vcHRpb25zIGhhcyBtb3JlIGZvcmNlIHN1
cHBvcnQgKi8KCQlpZiAoIXN0cm5jbXAocCwgImZvcmNlIiwgNSkpCgkJCWZvcmNlX2lvbW11
ID0gMTsKCQlpZiAoIXN0cm5jbXAocCwgIm5vZm9yY2UiLCA3KSkgewoJCQlpb21tdV9tZXJn
ZSA9IDA7CgkJCWZvcmNlX2lvbW11ID0gMDsKCQl9CgoJCWlmICghc3RybmNtcChwLCAiYmlv
bWVyZ2UiLCA4KSkgewoJCQlpb21tdV9tZXJnZSA9IDE7CgkJCWZvcmNlX2lvbW11ID0gMTsK
CQl9CgkJaWYgKCFzdHJuY21wKHAsICJwYW5pYyIsIDUpKQoJCQlwYW5pY19vbl9vdmVyZmxv
dyA9IDE7CgkJaWYgKCFzdHJuY21wKHAsICJub3BhbmljIiwgNykpCgkJCXBhbmljX29uX292
ZXJmbG93ID0gMDsKCQlpZiAoIXN0cm5jbXAocCwgIm1lcmdlIiwgNSkpIHsKCQkJaW9tbXVf
bWVyZ2UgPSAxOwoJCQlmb3JjZV9pb21tdSA9IDE7CgkJfQoJCWlmICghc3RybmNtcChwLCAi
bm9tZXJnZSIsIDcpKQoJCQlpb21tdV9tZXJnZSA9IDA7CgkJaWYgKCFzdHJuY21wKHAsICJm
b3JjZXNhYyIsIDgpKQoJCQlpb21tdV9zYWNfZm9yY2UgPSAxOwoJCWlmICghc3RybmNtcChw
LCAiYWxsb3dkYWMiLCA4KSkKCQkJZm9yYmlkX2RhYyA9IDA7CgkJaWYgKCFzdHJuY21wKHAs
ICJub2RhYyIsIDUpKQoJCQlmb3JiaWRfZGFjID0gMTsKCQlpZiAoIXN0cm5jbXAocCwgInVz
ZWRhYyIsIDYpKSB7CgkJCWZvcmJpZF9kYWMgPSAtMTsKCQkJcmV0dXJuIDE7CgkJfQojaWZk
ZWYgQ09ORklHX1NXSU9UTEIKCQlpZiAoIXN0cm5jbXAocCwgInNvZnQiLCA0KSkKCQkJc3dp
b3RsYiA9IDE7CiNlbmRpZgoJCWlmICghc3RybmNtcChwLCAicHQiLCAyKSkKCQkJaW9tbXVf
cGFzc190aHJvdWdoID0gMTsKCgkJZ2FydF9wYXJzZV9vcHRpb25zKHApOwoKI2lmZGVmIENP
TkZJR19DQUxHQVJZX0lPTU1VCgkJaWYgKCFzdHJuY21wKHAsICJjYWxnYXJ5IiwgNykpCgkJ
CXVzZV9jYWxnYXJ5ID0gMTsKI2VuZGlmIC8qIENPTkZJR19DQUxHQVJZX0lPTU1VICovCgoJ
CXAgKz0gc3RyY3NwbihwLCAiLCIpOwoJCWlmICgqcCA9PSAnLCcpCgkJCSsrcDsKCX0KCXJl
dHVybiAwOwp9CmVhcmx5X3BhcmFtKCJpb21tdSIsIGlvbW11X3NldHVwKTsKCnN0YXRpYyBp
bnQgY2hlY2tfcGFnZXNfcGh5c2ljYWxseV9jb250aWd1b3VzKHVuc2lnbmVkIGxvbmcgcGZu
LAoJCQkJCSAgICAgdW5zaWduZWQgaW50IG9mZnNldCwKCQkJCQkgICAgIHNpemVfdCBsZW5n
dGgpCnsKCXVuc2lnbmVkIGxvbmcgbmV4dF9tZm47CglpbnQgaTsKCWludCBucl9wYWdlczsK
CgluZXh0X21mbiA9IHBmbl90b19tZm4ocGZuKTsKCW5yX3BhZ2VzID0gKG9mZnNldCArIGxl
bmd0aCArIFBBR0VfU0laRS0xKSA+PiBQQUdFX1NISUZUOwoKCWZvciAoaSA9IDE7IGkgPCBu
cl9wYWdlczsgaSsrKSB7CgkJaWYgKHBmbl90b19tZm4oKytwZm4pICE9ICsrbmV4dF9tZm4p
CgkJCXJldHVybiAwOwoJfQoJcmV0dXJuIDE7Cn0KCmludCByYW5nZV9zdHJhZGRsZXNfcGFn
ZV9ib3VuZGFyeShwYWRkcl90IHAsIHNpemVfdCBzaXplKQp7Cgl1bnNpZ25lZCBsb25nIHBm
biA9IHAgPj4gUEFHRV9TSElGVDsKCXVuc2lnbmVkIGludCBvZmZzZXQgPSBwICYgflBBR0Vf
TUFTSzsKCglyZXR1cm4gKChvZmZzZXQgKyBzaXplID4gUEFHRV9TSVpFKSAmJgoJCSFjaGVj
a19wYWdlc19waHlzaWNhbGx5X2NvbnRpZ3VvdXMocGZuLCBvZmZzZXQsIHNpemUpKTsKfQoK
aW50IGRtYV9zdXBwb3J0ZWQoc3RydWN0IGRldmljZSAqZGV2LCB1NjQgbWFzaykKewoJc3Ry
dWN0IGRtYV9tYXBfb3BzICpvcHMgPSBnZXRfZG1hX29wcyhkZXYpOwoKI2lmZGVmIENPTkZJ
R19QQ0kKCWlmIChtYXNrID4gMHhmZmZmZmZmZiAmJiBmb3JiaWRfZGFjID4gMCkgewoJCWRl
dl9pbmZvKGRldiwgIlBDSTogRGlzYWxsb3dpbmcgREFDIGZvciBkZXZpY2VcbiIpOwoJCXJl
dHVybiAwOwoJfQojZW5kaWYKCglpZiAob3BzLT5kbWFfc3VwcG9ydGVkKQoJCXJldHVybiBv
cHMtPmRtYV9zdXBwb3J0ZWQoZGV2LCBtYXNrKTsKCgkvKiBDb3BpZWQgZnJvbSBpMzg2LiBE
b2Vzbid0IG1ha2UgbXVjaCBzZW5zZSwgYmVjYXVzZSBpdCB3aWxsCgkgICBvbmx5IHdvcmsg
Zm9yIHBjaV9hbGxvY19jb2hlcmVudC4KCSAgIFRoZSBjYWxsZXIganVzdCBoYXMgdG8gdXNl
IEdGUF9ETUEgaW4gdGhpcyBjYXNlLiAqLwoJaWYgKG1hc2sgPCBETUFfQklUX01BU0soMjQp
KQoJCXJldHVybiAwOwoKCS8qIFRlbGwgdGhlIGRldmljZSB0byB1c2UgU0FDIHdoZW4gSU9N
TVUgZm9yY2UgaXMgb24uICBUaGlzCgkgICBhbGxvd3MgdGhlIGRyaXZlciB0byB1c2UgY2hl
YXBlciBhY2Nlc3NlcyBpbiBzb21lIGNhc2VzLgoKCSAgIFByb2JsZW0gd2l0aCB0aGlzIGlz
IHRoYXQgaWYgd2Ugb3ZlcmZsb3cgdGhlIElPTU1VIGFyZWEgYW5kCgkgICByZXR1cm4gREFD
IGFzIGZhbGxiYWNrIGFkZHJlc3MgdGhlIGRldmljZSBtYXkgbm90IGhhbmRsZSBpdAoJICAg
Y29ycmVjdGx5LgoKCSAgIEFzIGEgc3BlY2lhbCBjYXNlIHNvbWUgY29udHJvbGxlcnMgaGF2
ZSBhIDM5Yml0IGFkZHJlc3MKCSAgIG1vZGUgdGhhdCBpcyBhcyBlZmZpY2llbnQgYXMgMzJi
aXQgKGFpYzc5eHgpLiBEb24ndCBmb3JjZQoJICAgU0FDIGZvciB0aGVzZS4gIEFzc3VtZSBh
bGwgbWFza3MgPD0gNDAgYml0cyBhcmUgb2YgdGhpcwoJICAgdHlwZS4gTm9ybWFsbHkgdGhp
cyBkb2Vzbid0IG1ha2UgYW55IGRpZmZlcmVuY2UsIGJ1dCBnaXZlcwoJICAgbW9yZSBnZW50
bGUgaGFuZGxpbmcgb2YgSU9NTVUgb3ZlcmZsb3cuICovCglpZiAoaW9tbXVfc2FjX2ZvcmNl
ICYmIChtYXNrID49IERNQV9CSVRfTUFTSyg0MCkpKSB7CgkJZGV2X2luZm8oZGV2LCAiRm9y
Y2UgU0FDIHdpdGggbWFzayAlTHhcbiIsIG1hc2spOwoJCXJldHVybiAwOwoJfQoKCXJldHVy
biAxOwp9CkVYUE9SVF9TWU1CT0woZG1hX3N1cHBvcnRlZCk7CgpzdGF0aWMgaW50IF9faW5p
dCBwY2lfaW9tbXVfaW5pdCh2b2lkKQp7CglkbWFfZGVidWdfaW5pdChQUkVBTExPQ19ETUFf
REVCVUdfRU5UUklFUyk7CgojaWZkZWYgQ09ORklHX1BDSQoJZG1hX2RlYnVnX2FkZF9idXMo
JnBjaV9idXNfdHlwZSk7CiNlbmRpZgoJeDg2X2luaXQuaW9tbXUuaW9tbXVfaW5pdCgpOwoK
I2lmbmRlZiBDT05GSUdfWEVOCglpZiAoc3dpb3RsYikgewoJCXByaW50ayhLRVJOX0lORk8g
IlBDSS1ETUE6ICIKCQkgICAgICAgIlVzaW5nIHNvZnR3YXJlIGJvdW5jZSBidWZmZXJpbmcg
Zm9yIElPIChTV0lPVExCKVxuIik7CgkJc3dpb3RsYl9wcmludF9pbmZvKCk7Cgl9IGVsc2UK
CQlzd2lvdGxiX2ZyZWUoKTsKI2VuZGlmCgoJcmV0dXJuIDA7Cn0KLyogTXVzdCBleGVjdXRl
IGFmdGVyIFBDSSBzdWJzeXN0ZW0gKi8Kcm9vdGZzX2luaXRjYWxsKHBjaV9pb21tdV9pbml0
KTsKCiNpZmRlZiBDT05GSUdfUENJCi8qIE1hbnkgVklBIGJyaWRnZXMgc2VlbSB0byBjb3Jy
dXB0IGRhdGEgZm9yIERBQy4gRGlzYWJsZSBpdCBoZXJlICovCgpzdGF0aWMgX19kZXZpbml0
IHZvaWQgdmlhX25vX2RhYyhzdHJ1Y3QgcGNpX2RldiAqZGV2KQp7CglpZiAoKGRldi0+Y2xh
c3MgPj4gOCkgPT0gUENJX0NMQVNTX0JSSURHRV9QQ0kgJiYgZm9yYmlkX2RhYyA9PSAwKSB7
CgkJZGV2X2luZm8oJmRldi0+ZGV2LCAiZGlzYWJsaW5nIERBQyBvbiBWSUEgUENJIGJyaWRn
ZVxuIik7CgkJZm9yYmlkX2RhYyA9IDE7Cgl9Cn0KREVDTEFSRV9QQ0lfRklYVVBfRklOQUwo
UENJX1ZFTkRPUl9JRF9WSUEsIFBDSV9BTllfSUQsIHZpYV9ub19kYWMpOwojZW5kaWYK
--=_mpaRqw5ZTb1NyohKK81n2EoHfBUfa6Wj7ICZiy9X+A95qsfm
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=_mpaRqw5ZTb1NyohKK81n2EoHfBUfa6Wj7ICZiy9X+A95qsfm--



From xen-devel-bounces@lists.xensource.com Tue Nov 29 09:32:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 09:32:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVK2W-0004gS-Ez; Tue, 29 Nov 2011 09:31:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RVK2U-0004fh-Ej
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 09:31:47 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322559068!3493828!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.1 required=7.0 tests=FROM_EXCESS_QP,HTML_50_60,
	HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11441 invoked from network); 29 Nov 2011 09:31:08 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 09:31:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=jqd1o3ruWb4QaqReTvF9aUzGojSEz
	/A6ZyN8rL2/oEE=; b=CJ4Rs7YjBFgEuL20PvH1zmJY7GzEF5gDwm7bMMTHNPL37
	Yp+yq48CEpeAAuxbqboHT2nazK9wH3fZ9jXtrP9HKGTFlYjFqyFqMadgGeNcIGCx
	d7mu1iiGtsfz44n7Qd8ZFBynF++WQEFFBauRsAUktxGeNDNju0vhmJIXu1g1yc=
Received: (qmail 19760 invoked from network); 29 Nov 2011 10:31:07 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.180.138)
	by mail.zeus06.de with ESMTPA; 29 Nov 2011 10:31:07 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id BDFC72C51B;
	Tue, 29 Nov 2011 10:31:07 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id Bqtv5KSY8ANQ; Tue, 29 Nov 2011 10:31:02 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 383882C51A;
	Tue, 29 Nov 2011 10:31:02 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Jan_Beulich?= <JBeulich@suse.com>, =?utf-8?Q?Konrad_Rzesz?=
	=?utf-8?Q?utek_Wilk?= <konrad.wilk@oracle.com>
Date: Tue, 29 Nov 2011 10:31:02 +0100
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="=_mpaRqw5ZTb1NyohKK81n2EoHfBUfa6Wj7ICZiy9X+A95qsfm"
In-Reply-To: <4ED4A6580200007800063F87@nat28.tlf.novell.com>
References: <4ED4A6580200007800063F87@nat28.tlf.novell.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ed4a656.52fd.63ce1a9050a2a2e3@uhura.space.zz>
Cc: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?Ian_Campbell?= <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_mpaRqw5ZTb1NyohKK81n2EoHfBUfa6Wj7ICZiy9X+A95qsfm
Content-Type: multipart/alternative; 
 boundary="=_mpaRxkcu7CvRhUgYoUDQFC5l0pCO1fL+EfgdphTAfYTKa7HA"

--=_mpaRxkcu7CvRhUgYoUDQFC5l0pCO1fL+EfgdphTAfYTKa7HA
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I attached the actualy used 2.6.34 file here, if that helps. BR,C.=0D=0A=C2=
=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-----=0D=0AAn:Konrad Rzeszutek =
Wilk <konrad.wilk@oracle.com>;=20=0D=0ACC:Ian Campbell <Ian.Campbell@citr=
ix.com>; Konrad Rzeszutek Wilk <konrad@darnok.org>; xen-devel <xen-devel@=
lists.xensource.com>; zhenzhong.duan@oracle.com; lersek@redhat.com; Carst=
en Schiers <carsten@schiers.de>;=20=0D=0AVon:Jan Beulich <JBeulich@suse.c=
om>=0D=0AGesendet:Di 29.11.2011 09:52=0D=0ABetreff:Re: [Xen-devel] Load i=
ncrease after memory upgrade (part2)=0D=0A>>> On 28.11.11 at 17:45, Konra=
d Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:=0D=0A> But I can't find =
the implementation of that in the classic Xen-SWIOTLB.=0D=0A=0D=0Alinux-2=
=2E6.18-xen.hg/arch/i386/kernel/pci-dma-xen.c:dma_alloc_coherent().=0D=0A=
=0D=0AJan=0D=0A=0D=0A
--=_mpaRxkcu7CvRhUgYoUDQFC5l0pCO1fL+EfgdphTAfYTKa7HA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
p>I attached the actualy used 2.6.34 file here, if that helps. BR,C.<br /=
>&nbsp;</p><blockquote style=3D"border-left: 2px solid #325FBA; padding-l=
eft: 5px;margin-left:5px;">-----Urspr&uuml;ngliche Nachricht-----<br /><s=
trong>An:</strong>=09Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;=
; <br /><strong>CC:</strong>=09Ian Campbell &lt;Ian.Campbell@citrix.com&g=
t;; Konrad Rzeszutek Wilk &lt;konrad@darnok.org&gt;; xen-devel &lt;xen-de=
vel@lists.xensource.com&gt;; zhenzhong.duan@oracle.com; lersek@redhat.com=
; Carsten Schiers &lt;carsten@schiers.de&gt;; <br /><strong>Von:</strong>=
=09Jan Beulich &lt;JBeulich@suse.com&gt;<br /><strong>Gesendet:</strong>=09=
Di 29.11.2011 09:52<br /><strong>Betreff:</strong>=09Re: [Xen-devel] Load=
 increase after memory upgrade (part2)<br />&gt;&gt;&gt; On 28.11.11 at 1=
7:45, Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt; wrote:<br />&g=
t; But I can&#39;t find the implementation of that in the classic Xen-SWI=
OTLB.<br /><br />linux-2.6.18-xen.hg/arch/i386/kernel/pci-dma-xen.c:dma_a=
lloc_coherent().<br /><br />Jan<br /><br /></blockquote>=0A</body>=0A</ht=
ml>
--=_mpaRxkcu7CvRhUgYoUDQFC5l0pCO1fL+EfgdphTAfYTKa7HA--

--=_mpaRqw5ZTb1NyohKK81n2EoHfBUfa6Wj7ICZiy9X+A95qsfm
Content-Type: application/octet-stream; name=pci-dma-xen.c
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=pci-dma-xen.c

I2luY2x1ZGUgPGxpbnV4L2RtYS1tYXBwaW5nLmg+CiNpbmNsdWRlIDxsaW51eC9kbWEtZGVi
dWcuaD4KI2luY2x1ZGUgPGxpbnV4L2RtYXIuaD4KI2luY2x1ZGUgPGxpbnV4L2Jvb3RtZW0u
aD4KI2luY2x1ZGUgPGxpbnV4L2dmcC5oPgojaW5jbHVkZSA8bGludXgvcGNpLmg+CiNpbmNs
dWRlIDxsaW51eC9rbWVtbGVhay5oPgoKI2luY2x1ZGUgPGFzbS9wcm90by5oPgojaW5jbHVk
ZSA8YXNtL2RtYS5oPgojaW5jbHVkZSA8YXNtL2lvbW11Lmg+CiNpbmNsdWRlIDxhc20vZ2Fy
dC5oPgojaW5jbHVkZSA8YXNtL2NhbGdhcnkuaD4KI2luY2x1ZGUgPGFzbS9hbWRfaW9tbXUu
aD4KI2luY2x1ZGUgPGFzbS94ODZfaW5pdC5oPgoKc3RhdGljIGludCBmb3JiaWRfZGFjIF9f
cmVhZF9tb3N0bHk7CgpzdHJ1Y3QgZG1hX21hcF9vcHMgKmRtYV9vcHMgPSAmbm9tbXVfZG1h
X29wczsKRVhQT1JUX1NZTUJPTChkbWFfb3BzKTsKCnN0YXRpYyBpbnQgaW9tbXVfc2FjX2Zv
cmNlIF9fcmVhZF9tb3N0bHk7CgojaWZkZWYgQ09ORklHX0lPTU1VX0RFQlVHCmludCBwYW5p
Y19vbl9vdmVyZmxvdyBfX3JlYWRfbW9zdGx5ID0gMTsKaW50IGZvcmNlX2lvbW11IF9fcmVh
ZF9tb3N0bHkgPSAxOwojZWxzZQppbnQgcGFuaWNfb25fb3ZlcmZsb3cgX19yZWFkX21vc3Rs
eSA9IDA7CmludCBmb3JjZV9pb21tdSBfX3JlYWRfbW9zdGx5ID0gMDsKI2VuZGlmCgppbnQg
aW9tbXVfbWVyZ2UgX19yZWFkX21vc3RseSA9IDA7CgppbnQgbm9faW9tbXUgX19yZWFkX21v
c3RseTsKLyogU2V0IHRoaXMgdG8gMSBpZiB0aGVyZSBpcyBhIEhXIElPTU1VIGluIHRoZSBz
eXN0ZW0gKi8KaW50IGlvbW11X2RldGVjdGVkIF9fcmVhZF9tb3N0bHkgPSAwOwoKLyoKICog
VGhpcyB2YXJpYWJsZSBiZWNvbWVzIDEgaWYgaW9tbXU9cHQgaXMgcGFzc2VkIG9uIHRoZSBr
ZXJuZWwgY29tbWFuZCBsaW5lLgogKiBJZiB0aGlzIHZhcmlhYmxlIGlzIDEsIElPTU1VIGlt
cGxlbWVudGF0aW9ucyBkbyBubyBETUEgdHJhbnNsYXRpb24gZm9yCiAqIGRldmljZXMgYW5k
IGFsbG93IGV2ZXJ5IGRldmljZSB0byBhY2Nlc3MgdG8gd2hvbGUgcGh5c2ljYWwgbWVtb3J5
LiBUaGlzIGlzCiAqIHVzZWZ1bCBpZiBhIHVzZXIgd2FudHMgdG8gdXNlIGFuIElPTU1VIG9u
bHkgZm9yIEtWTSBkZXZpY2UgYXNzaWdubWVudCB0bwogKiBndWVzdHMgYW5kIG5vdCBmb3Ig
ZHJpdmVyIGRtYSB0cmFuc2xhdGlvbi4KICovCmludCBpb21tdV9wYXNzX3Rocm91Z2ggX19y
ZWFkX21vc3RseTsKCi8qIER1bW15IGRldmljZSB1c2VkIGZvciBOVUxMIGFyZ3VtZW50cyAo
bm9ybWFsbHkgSVNBKS4gKi8Kc3RydWN0IGRldmljZSB4ODZfZG1hX2ZhbGxiYWNrX2RldiA9
IHsKCS5pbml0X25hbWUgPSAiZmFsbGJhY2sgZGV2aWNlIiwKCS5jb2hlcmVudF9kbWFfbWFz
ayA9IElTQV9ETUFfQklUX01BU0ssCgkuZG1hX21hc2sgPSAmeDg2X2RtYV9mYWxsYmFja19k
ZXYuY29oZXJlbnRfZG1hX21hc2ssCn07CkVYUE9SVF9TWU1CT0woeDg2X2RtYV9mYWxsYmFj
a19kZXYpOwoKLyogTnVtYmVyIG9mIGVudHJpZXMgcHJlYWxsb2NhdGVkIGZvciBETUEtQVBJ
IGRlYnVnZ2luZyAqLwojZGVmaW5lIFBSRUFMTE9DX0RNQV9ERUJVR19FTlRSSUVTICAgICAg
IDMyNzY4CgppbnQgZG1hX3NldF9tYXNrKHN0cnVjdCBkZXZpY2UgKmRldiwgdTY0IG1hc2sp
CnsKCWlmICghZGV2LT5kbWFfbWFzayB8fCAhZG1hX3N1cHBvcnRlZChkZXYsIG1hc2spKQoJ
CXJldHVybiAtRUlPOwoKCSpkZXYtPmRtYV9tYXNrID0gbWFzazsKCglyZXR1cm4gMDsKfQpF
WFBPUlRfU1lNQk9MKGRtYV9zZXRfbWFzayk7CgojaWYgZGVmaW5lZChDT05GSUdfWDg2XzY0
KSAmJiAhZGVmaW5lZChDT05GSUdfTlVNQSkgJiYgIWRlZmluZWQoQ09ORklHX1hFTikKc3Rh
dGljIF9faW5pdGRhdGEgdm9pZCAqZG1hMzJfYm9vdG1lbV9wdHI7CnN0YXRpYyB1bnNpZ25l
ZCBsb25nIGRtYTMyX2Jvb3RtZW1fc2l6ZSBfX2luaXRkYXRhID0gKDEyOFVMTDw8MjApOwoK
c3RhdGljIGludCBfX2luaXQgcGFyc2VfZG1hMzJfc2l6ZV9vcHQoY2hhciAqcCkKewoJaWYg
KCFwKQoJCXJldHVybiAtRUlOVkFMOwoJZG1hMzJfYm9vdG1lbV9zaXplID0gbWVtcGFyc2Uo
cCwgJnApOwoJcmV0dXJuIDA7Cn0KZWFybHlfcGFyYW0oImRtYTMyX3NpemUiLCBwYXJzZV9k
bWEzMl9zaXplX29wdCk7Cgp2b2lkIF9faW5pdCBkbWEzMl9yZXNlcnZlX2Jvb3RtZW0odm9p
ZCkKewoJdW5zaWduZWQgbG9uZyBzaXplLCBhbGlnbjsKCWlmIChtYXhfcGZuIDw9IE1BWF9E
TUEzMl9QRk4pCgkJcmV0dXJuOwoKCS8qCgkgKiBjaGVjayBhcGVydHVyZV82NC5jIGFsbG9j
YXRlX2FwZXJ0dXJlKCkgZm9yIHJlYXNvbiBhYm91dAoJICogdXNpbmcgNTEyTSBhcyBnb2Fs
CgkgKi8KCWFsaWduID0gNjRVTEw8PDIwOwoJc2l6ZSA9IHJvdW5kdXAoZG1hMzJfYm9vdG1l
bV9zaXplLCBhbGlnbik7CglkbWEzMl9ib290bWVtX3B0ciA9IF9fYWxsb2NfYm9vdG1lbV9u
b3BhbmljKHNpemUsIGFsaWduLAoJCQkJIDUxMlVMTDw8MjApOwoJLyoKCSAqIEttZW1sZWFr
IHNob3VsZCBub3Qgc2NhbiB0aGlzIGJsb2NrIGFzIGl0IG1heSBub3QgYmUgbWFwcGVkIHZp
YSB0aGUKCSAqIGtlcm5lbCBkaXJlY3QgbWFwcGluZy4KCSAqLwoJa21lbWxlYWtfaWdub3Jl
KGRtYTMyX2Jvb3RtZW1fcHRyKTsKCWlmIChkbWEzMl9ib290bWVtX3B0cikKCQlkbWEzMl9i
b290bWVtX3NpemUgPSBzaXplOwoJZWxzZQoJCWRtYTMyX2Jvb3RtZW1fc2l6ZSA9IDA7Cn0K
c3RhdGljIHZvaWQgX19pbml0IGRtYTMyX2ZyZWVfYm9vdG1lbSh2b2lkKQp7CgoJaWYgKG1h
eF9wZm4gPD0gTUFYX0RNQTMyX1BGTikKCQlyZXR1cm47CgoJaWYgKCFkbWEzMl9ib290bWVt
X3B0cikKCQlyZXR1cm47CgoJZnJlZV9ib290bWVtKF9fcGEoZG1hMzJfYm9vdG1lbV9wdHIp
LCBkbWEzMl9ib290bWVtX3NpemUpOwoKCWRtYTMyX2Jvb3RtZW1fcHRyID0gTlVMTDsKCWRt
YTMyX2Jvb3RtZW1fc2l6ZSA9IDA7Cn0KI2Vsc2UKdm9pZCBfX2luaXQgZG1hMzJfcmVzZXJ2
ZV9ib290bWVtKHZvaWQpCnsKfQpzdGF0aWMgdm9pZCBfX2luaXQgZG1hMzJfZnJlZV9ib290
bWVtKHZvaWQpCnsKfQoKI2VuZGlmCgpzdGF0aWMgc3RydWN0IGRtYV9tYXBfb3BzIHN3aW90
bGJfZG1hX29wcyA9IHsKCS5hbGxvY19jb2hlcmVudCA9IGRtYV9nZW5lcmljX2FsbG9jX2Nv
aGVyZW50LAoJLmZyZWVfY29oZXJlbnQgPSBkbWFfZ2VuZXJpY19mcmVlX2NvaGVyZW50LAoJ
Lm1hcHBpbmdfZXJyb3IgPSBzd2lvdGxiX2RtYV9tYXBwaW5nX2Vycm9yLAoJLm1hcF9wYWdl
ID0gc3dpb3RsYl9tYXBfcGFnZSwKCS51bm1hcF9wYWdlID0gc3dpb3RsYl91bm1hcF9wYWdl
LAoJLnN5bmNfc2luZ2xlX2Zvcl9jcHUgPSBzd2lvdGxiX3N5bmNfc2luZ2xlX2Zvcl9jcHUs
Cgkuc3luY19zaW5nbGVfZm9yX2RldmljZSA9IHN3aW90bGJfc3luY19zaW5nbGVfZm9yX2Rl
dmljZSwKCS5zeW5jX3NpbmdsZV9yYW5nZV9mb3JfY3B1ID0gc3dpb3RsYl9zeW5jX3Npbmds
ZV9yYW5nZV9mb3JfY3B1LAoJLnN5bmNfc2luZ2xlX3JhbmdlX2Zvcl9kZXZpY2UgPSBzd2lv
dGxiX3N5bmNfc2luZ2xlX3JhbmdlX2Zvcl9kZXZpY2UsCgkuc3luY19zZ19mb3JfY3B1ID0g
c3dpb3RsYl9zeW5jX3NnX2Zvcl9jcHUsCgkuc3luY19zZ19mb3JfZGV2aWNlID0gc3dpb3Rs
Yl9zeW5jX3NnX2Zvcl9kZXZpY2UsCgkubWFwX3NnID0gc3dpb3RsYl9tYXBfc2dfYXR0cnMs
CgkudW5tYXBfc2cgPSBzd2lvdGxiX3VubWFwX3NnX2F0dHJzLAoJLmRtYV9zdXBwb3J0ZWQg
PSBzd2lvdGxiX2RtYV9zdXBwb3J0ZWQKfTsKCnZvaWQgX19pbml0IHBjaV9pb21tdV9hbGxv
Yyh2b2lkKQp7CgkvKiBmcmVlIHRoZSByYW5nZSBzbyBpb21tdSBjb3VsZCBnZXQgc29tZSBy
YW5nZSBsZXNzIHRoYW4gNEcgKi8KCWRtYTMyX2ZyZWVfYm9vdG1lbSgpOwoKCWlmIChwY2lf
c3dpb3RsYl9kZXRlY3QoKSkKCQlnb3RvIG91dDsKCglnYXJ0X2lvbW11X2hvbGVfaW5pdCgp
OwoKCWRldGVjdF9jYWxnYXJ5KCk7CgoJZGV0ZWN0X2ludGVsX2lvbW11KCk7CgoJLyogbmVl
ZHMgdG8gYmUgY2FsbGVkIGFmdGVyIGdhcnRfaW9tbXVfaG9sZV9pbml0ICovCglhbWRfaW9t
bXVfZGV0ZWN0KCk7Cm91dDoKCXN3aW90bGJfaW5pdCgxKTsKCWlmIChzd2lvdGxiKSB7CgkJ
cHJpbnRrKEtFUk5fSU5GTyAiUENJLURNQTogVXNpbmcgc29mdHdhcmUgYm91bmNlIGJ1ZmZl
cmluZyBmb3IgSU8gKFNXSU9UTEIpXG4iKTsKCQlkbWFfb3BzID0gJnN3aW90bGJfZG1hX29w
czsKCX0KfQoKdm9pZCAqZG1hX2dlbmVyaWNfYWxsb2NfY29oZXJlbnQoc3RydWN0IGRldmlj
ZSAqZGV2LCBzaXplX3Qgc2l6ZSwKCQkJCSBkbWFfYWRkcl90ICpkbWFfYWRkciwgZ2ZwX3Qg
ZmxhZykKewoJdW5zaWduZWQgbG9uZyBkbWFfbWFzazsKCXN0cnVjdCBwYWdlICpwYWdlOwoj
aWZuZGVmIENPTkZJR19YRU4KCWRtYV9hZGRyX3QgYWRkcjsKI2Vsc2UKCXZvaWQgKm1lbW9y
eTsKI2VuZGlmCgl1bnNpZ25lZCBpbnQgb3JkZXIgPSBnZXRfb3JkZXIoc2l6ZSk7CgoJZG1h
X21hc2sgPSBkbWFfYWxsb2NfY29oZXJlbnRfbWFzayhkZXYsIGZsYWcpOwoKI2lmbmRlZiBD
T05GSUdfWEVOCglmbGFnIHw9IF9fR0ZQX1pFUk87CmFnYWluOgojZWxzZQoJZmxhZyAmPSB+
KF9fR0ZQX0RNQSB8IF9fR0ZQX0RNQTMyKTsKI2VuZGlmCglwYWdlID0gYWxsb2NfcGFnZXNf
bm9kZShkZXZfdG9fbm9kZShkZXYpLCBmbGFnLCBvcmRlcik7CglpZiAoIXBhZ2UpCgkJcmV0
dXJuIE5VTEw7CgojaWZuZGVmIENPTkZJR19YRU4KCWFkZHIgPSBwYWdlX3RvX3BoeXMocGFn
ZSk7CglpZiAoYWRkciArIHNpemUgPiBkbWFfbWFzaykgewoJCV9fZnJlZV9wYWdlcyhwYWdl
LCBvcmRlcik7CgoJCWlmIChkbWFfbWFzayA8IERNQV9CSVRfTUFTSygzMikgJiYgIShmbGFn
ICYgR0ZQX0RNQSkpIHsKCQkJZmxhZyA9IChmbGFnICYgfkdGUF9ETUEzMikgfCBHRlBfRE1B
OwoJCQlnb3RvIGFnYWluOwoJCX0KCgkJcmV0dXJuIE5VTEw7Cgl9CgoJKmRtYV9hZGRyID0g
YWRkcjsKCXJldHVybiBwYWdlX2FkZHJlc3MocGFnZSk7CiNlbHNlCgltZW1vcnkgPSBwYWdl
X2FkZHJlc3MocGFnZSk7CglpZiAoeGVuX2NyZWF0ZV9jb250aWd1b3VzX3JlZ2lvbigodW5z
aWduZWQgbG9uZyltZW1vcnksIG9yZGVyLAoJCQkJCSBmbHM2NChkbWFfbWFzaykpKSB7CgkJ
X19mcmVlX3BhZ2VzKHBhZ2UsIG9yZGVyKTsKCQlyZXR1cm4gTlVMTDsKCX0KCgkqZG1hX2Fk
ZHIgPSB2aXJ0X3RvX2J1cyhtZW1vcnkpOwoJcmV0dXJuIG1lbXNldChtZW1vcnksIDAsIHNp
emUpOwojZW5kaWYKfQoKI2lmZGVmIENPTkZJR19YRU4Kdm9pZCBkbWFfZ2VuZXJpY19mcmVl
X2NvaGVyZW50KHN0cnVjdCBkZXZpY2UgKmRldiwgc2l6ZV90IHNpemUsIHZvaWQgKnZhZGRy
LAoJCQkgICAgICAgZG1hX2FkZHJfdCBkbWFfYWRkcikKewoJdW5zaWduZWQgaW50IG9yZGVy
ID0gZ2V0X29yZGVyKHNpemUpOwoJdW5zaWduZWQgbG9uZyB2YSA9ICh1bnNpZ25lZCBsb25n
KXZhZGRyOwoKCXhlbl9kZXN0cm95X2NvbnRpZ3VvdXNfcmVnaW9uKHZhLCBvcmRlcik7Cglm
cmVlX3BhZ2VzKHZhLCBvcmRlcik7Cn0KI2VuZGlmCgovKgogKiBTZWUgPERvY3VtZW50YXRp
b24veDg2XzY0L2Jvb3Qtb3B0aW9ucy50eHQ+IGZvciB0aGUgaW9tbXUga2VybmVsIHBhcmFt
ZXRlcgogKiBkb2N1bWVudGF0aW9uLgogKi8Kc3RhdGljIF9faW5pdCBpbnQgaW9tbXVfc2V0
dXAoY2hhciAqcCkKewoJaW9tbXVfbWVyZ2UgPSAxOwoKCWlmICghcCkKCQlyZXR1cm4gLUVJ
TlZBTDsKCgl3aGlsZSAoKnApIHsKCQlpZiAoIXN0cm5jbXAocCwgIm9mZiIsIDMpKQoJCQlu
b19pb21tdSA9IDE7CgkJLyogZ2FydF9wYXJzZV9vcHRpb25zIGhhcyBtb3JlIGZvcmNlIHN1
cHBvcnQgKi8KCQlpZiAoIXN0cm5jbXAocCwgImZvcmNlIiwgNSkpCgkJCWZvcmNlX2lvbW11
ID0gMTsKCQlpZiAoIXN0cm5jbXAocCwgIm5vZm9yY2UiLCA3KSkgewoJCQlpb21tdV9tZXJn
ZSA9IDA7CgkJCWZvcmNlX2lvbW11ID0gMDsKCQl9CgoJCWlmICghc3RybmNtcChwLCAiYmlv
bWVyZ2UiLCA4KSkgewoJCQlpb21tdV9tZXJnZSA9IDE7CgkJCWZvcmNlX2lvbW11ID0gMTsK
CQl9CgkJaWYgKCFzdHJuY21wKHAsICJwYW5pYyIsIDUpKQoJCQlwYW5pY19vbl9vdmVyZmxv
dyA9IDE7CgkJaWYgKCFzdHJuY21wKHAsICJub3BhbmljIiwgNykpCgkJCXBhbmljX29uX292
ZXJmbG93ID0gMDsKCQlpZiAoIXN0cm5jbXAocCwgIm1lcmdlIiwgNSkpIHsKCQkJaW9tbXVf
bWVyZ2UgPSAxOwoJCQlmb3JjZV9pb21tdSA9IDE7CgkJfQoJCWlmICghc3RybmNtcChwLCAi
bm9tZXJnZSIsIDcpKQoJCQlpb21tdV9tZXJnZSA9IDA7CgkJaWYgKCFzdHJuY21wKHAsICJm
b3JjZXNhYyIsIDgpKQoJCQlpb21tdV9zYWNfZm9yY2UgPSAxOwoJCWlmICghc3RybmNtcChw
LCAiYWxsb3dkYWMiLCA4KSkKCQkJZm9yYmlkX2RhYyA9IDA7CgkJaWYgKCFzdHJuY21wKHAs
ICJub2RhYyIsIDUpKQoJCQlmb3JiaWRfZGFjID0gMTsKCQlpZiAoIXN0cm5jbXAocCwgInVz
ZWRhYyIsIDYpKSB7CgkJCWZvcmJpZF9kYWMgPSAtMTsKCQkJcmV0dXJuIDE7CgkJfQojaWZk
ZWYgQ09ORklHX1NXSU9UTEIKCQlpZiAoIXN0cm5jbXAocCwgInNvZnQiLCA0KSkKCQkJc3dp
b3RsYiA9IDE7CiNlbmRpZgoJCWlmICghc3RybmNtcChwLCAicHQiLCAyKSkKCQkJaW9tbXVf
cGFzc190aHJvdWdoID0gMTsKCgkJZ2FydF9wYXJzZV9vcHRpb25zKHApOwoKI2lmZGVmIENP
TkZJR19DQUxHQVJZX0lPTU1VCgkJaWYgKCFzdHJuY21wKHAsICJjYWxnYXJ5IiwgNykpCgkJ
CXVzZV9jYWxnYXJ5ID0gMTsKI2VuZGlmIC8qIENPTkZJR19DQUxHQVJZX0lPTU1VICovCgoJ
CXAgKz0gc3RyY3NwbihwLCAiLCIpOwoJCWlmICgqcCA9PSAnLCcpCgkJCSsrcDsKCX0KCXJl
dHVybiAwOwp9CmVhcmx5X3BhcmFtKCJpb21tdSIsIGlvbW11X3NldHVwKTsKCnN0YXRpYyBp
bnQgY2hlY2tfcGFnZXNfcGh5c2ljYWxseV9jb250aWd1b3VzKHVuc2lnbmVkIGxvbmcgcGZu
LAoJCQkJCSAgICAgdW5zaWduZWQgaW50IG9mZnNldCwKCQkJCQkgICAgIHNpemVfdCBsZW5n
dGgpCnsKCXVuc2lnbmVkIGxvbmcgbmV4dF9tZm47CglpbnQgaTsKCWludCBucl9wYWdlczsK
CgluZXh0X21mbiA9IHBmbl90b19tZm4ocGZuKTsKCW5yX3BhZ2VzID0gKG9mZnNldCArIGxl
bmd0aCArIFBBR0VfU0laRS0xKSA+PiBQQUdFX1NISUZUOwoKCWZvciAoaSA9IDE7IGkgPCBu
cl9wYWdlczsgaSsrKSB7CgkJaWYgKHBmbl90b19tZm4oKytwZm4pICE9ICsrbmV4dF9tZm4p
CgkJCXJldHVybiAwOwoJfQoJcmV0dXJuIDE7Cn0KCmludCByYW5nZV9zdHJhZGRsZXNfcGFn
ZV9ib3VuZGFyeShwYWRkcl90IHAsIHNpemVfdCBzaXplKQp7Cgl1bnNpZ25lZCBsb25nIHBm
biA9IHAgPj4gUEFHRV9TSElGVDsKCXVuc2lnbmVkIGludCBvZmZzZXQgPSBwICYgflBBR0Vf
TUFTSzsKCglyZXR1cm4gKChvZmZzZXQgKyBzaXplID4gUEFHRV9TSVpFKSAmJgoJCSFjaGVj
a19wYWdlc19waHlzaWNhbGx5X2NvbnRpZ3VvdXMocGZuLCBvZmZzZXQsIHNpemUpKTsKfQoK
aW50IGRtYV9zdXBwb3J0ZWQoc3RydWN0IGRldmljZSAqZGV2LCB1NjQgbWFzaykKewoJc3Ry
dWN0IGRtYV9tYXBfb3BzICpvcHMgPSBnZXRfZG1hX29wcyhkZXYpOwoKI2lmZGVmIENPTkZJ
R19QQ0kKCWlmIChtYXNrID4gMHhmZmZmZmZmZiAmJiBmb3JiaWRfZGFjID4gMCkgewoJCWRl
dl9pbmZvKGRldiwgIlBDSTogRGlzYWxsb3dpbmcgREFDIGZvciBkZXZpY2VcbiIpOwoJCXJl
dHVybiAwOwoJfQojZW5kaWYKCglpZiAob3BzLT5kbWFfc3VwcG9ydGVkKQoJCXJldHVybiBv
cHMtPmRtYV9zdXBwb3J0ZWQoZGV2LCBtYXNrKTsKCgkvKiBDb3BpZWQgZnJvbSBpMzg2LiBE
b2Vzbid0IG1ha2UgbXVjaCBzZW5zZSwgYmVjYXVzZSBpdCB3aWxsCgkgICBvbmx5IHdvcmsg
Zm9yIHBjaV9hbGxvY19jb2hlcmVudC4KCSAgIFRoZSBjYWxsZXIganVzdCBoYXMgdG8gdXNl
IEdGUF9ETUEgaW4gdGhpcyBjYXNlLiAqLwoJaWYgKG1hc2sgPCBETUFfQklUX01BU0soMjQp
KQoJCXJldHVybiAwOwoKCS8qIFRlbGwgdGhlIGRldmljZSB0byB1c2UgU0FDIHdoZW4gSU9N
TVUgZm9yY2UgaXMgb24uICBUaGlzCgkgICBhbGxvd3MgdGhlIGRyaXZlciB0byB1c2UgY2hl
YXBlciBhY2Nlc3NlcyBpbiBzb21lIGNhc2VzLgoKCSAgIFByb2JsZW0gd2l0aCB0aGlzIGlz
IHRoYXQgaWYgd2Ugb3ZlcmZsb3cgdGhlIElPTU1VIGFyZWEgYW5kCgkgICByZXR1cm4gREFD
IGFzIGZhbGxiYWNrIGFkZHJlc3MgdGhlIGRldmljZSBtYXkgbm90IGhhbmRsZSBpdAoJICAg
Y29ycmVjdGx5LgoKCSAgIEFzIGEgc3BlY2lhbCBjYXNlIHNvbWUgY29udHJvbGxlcnMgaGF2
ZSBhIDM5Yml0IGFkZHJlc3MKCSAgIG1vZGUgdGhhdCBpcyBhcyBlZmZpY2llbnQgYXMgMzJi
aXQgKGFpYzc5eHgpLiBEb24ndCBmb3JjZQoJICAgU0FDIGZvciB0aGVzZS4gIEFzc3VtZSBh
bGwgbWFza3MgPD0gNDAgYml0cyBhcmUgb2YgdGhpcwoJICAgdHlwZS4gTm9ybWFsbHkgdGhp
cyBkb2Vzbid0IG1ha2UgYW55IGRpZmZlcmVuY2UsIGJ1dCBnaXZlcwoJICAgbW9yZSBnZW50
bGUgaGFuZGxpbmcgb2YgSU9NTVUgb3ZlcmZsb3cuICovCglpZiAoaW9tbXVfc2FjX2ZvcmNl
ICYmIChtYXNrID49IERNQV9CSVRfTUFTSyg0MCkpKSB7CgkJZGV2X2luZm8oZGV2LCAiRm9y
Y2UgU0FDIHdpdGggbWFzayAlTHhcbiIsIG1hc2spOwoJCXJldHVybiAwOwoJfQoKCXJldHVy
biAxOwp9CkVYUE9SVF9TWU1CT0woZG1hX3N1cHBvcnRlZCk7CgpzdGF0aWMgaW50IF9faW5p
dCBwY2lfaW9tbXVfaW5pdCh2b2lkKQp7CglkbWFfZGVidWdfaW5pdChQUkVBTExPQ19ETUFf
REVCVUdfRU5UUklFUyk7CgojaWZkZWYgQ09ORklHX1BDSQoJZG1hX2RlYnVnX2FkZF9idXMo
JnBjaV9idXNfdHlwZSk7CiNlbmRpZgoJeDg2X2luaXQuaW9tbXUuaW9tbXVfaW5pdCgpOwoK
I2lmbmRlZiBDT05GSUdfWEVOCglpZiAoc3dpb3RsYikgewoJCXByaW50ayhLRVJOX0lORk8g
IlBDSS1ETUE6ICIKCQkgICAgICAgIlVzaW5nIHNvZnR3YXJlIGJvdW5jZSBidWZmZXJpbmcg
Zm9yIElPIChTV0lPVExCKVxuIik7CgkJc3dpb3RsYl9wcmludF9pbmZvKCk7Cgl9IGVsc2UK
CQlzd2lvdGxiX2ZyZWUoKTsKI2VuZGlmCgoJcmV0dXJuIDA7Cn0KLyogTXVzdCBleGVjdXRl
IGFmdGVyIFBDSSBzdWJzeXN0ZW0gKi8Kcm9vdGZzX2luaXRjYWxsKHBjaV9pb21tdV9pbml0
KTsKCiNpZmRlZiBDT05GSUdfUENJCi8qIE1hbnkgVklBIGJyaWRnZXMgc2VlbSB0byBjb3Jy
dXB0IGRhdGEgZm9yIERBQy4gRGlzYWJsZSBpdCBoZXJlICovCgpzdGF0aWMgX19kZXZpbml0
IHZvaWQgdmlhX25vX2RhYyhzdHJ1Y3QgcGNpX2RldiAqZGV2KQp7CglpZiAoKGRldi0+Y2xh
c3MgPj4gOCkgPT0gUENJX0NMQVNTX0JSSURHRV9QQ0kgJiYgZm9yYmlkX2RhYyA9PSAwKSB7
CgkJZGV2X2luZm8oJmRldi0+ZGV2LCAiZGlzYWJsaW5nIERBQyBvbiBWSUEgUENJIGJyaWRn
ZVxuIik7CgkJZm9yYmlkX2RhYyA9IDE7Cgl9Cn0KREVDTEFSRV9QQ0lfRklYVVBfRklOQUwo
UENJX1ZFTkRPUl9JRF9WSUEsIFBDSV9BTllfSUQsIHZpYV9ub19kYWMpOwojZW5kaWYK
--=_mpaRqw5ZTb1NyohKK81n2EoHfBUfa6Wj7ICZiy9X+A95qsfm
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=_mpaRqw5ZTb1NyohKK81n2EoHfBUfa6Wj7ICZiy9X+A95qsfm--



From xen-devel-bounces@lists.xensource.com Tue Nov 29 09:38:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 09:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVK8Q-00051j-A4; Tue, 29 Nov 2011 09:37:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RVK8O-00051N-Re
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 09:37:53 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322559435!3514344!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.3 required=7.0 tests=FROM_EXCESS_QP,HTML_60_70,
	HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11415 invoked from network); 29 Nov 2011 09:37:15 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 09:37:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=7fVcMIqsBtP/PuIYXX6c6mPb19Rm+
	f01ESwuWdHiVzg=; b=cr52cHH1iMfd7RWxNVzt3+EYkhw41D9s7Na1CSQSgO7f5
	5gNq6K0TC/xjmf6sXVLCNYMGp9jJcxP1F33SBi0UnMlKYmeCNW4sgZzS2k7bXPdb
	wmIzBGE+umytJ2ygbEnNlfZeDGn9bk3B8xtbQkQ8G0si/o3MPPlJ3D6x4AClxI=
Received: (qmail 21882 invoked from network); 29 Nov 2011 10:37:15 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.180.138)
	by mail.zeus06.de with ESMTPA; 29 Nov 2011 10:37:15 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id E9C392C51A;
	Tue, 29 Nov 2011 10:37:14 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 6eudLkVriNhw; Tue, 29 Nov 2011 10:37:12 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id A2B802C51B;
	Tue, 29 Nov 2011 10:37:12 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>, 
	=?utf-8?Q?Ian_Campbell?= <Ian.Campbell@citrix.com>
Date: Tue, 29 Nov 2011 10:37:12 +0100
Mime-Version: 1.0
In-Reply-To: <1322494816.20646.14.camel@zakaz.uk.xensource.com>
References: <1322494816.20646.14.camel@zakaz.uk.xensource.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ed4a7c8.53fb.1fc7026279874c8b@uhura.space.zz>
Cc: =?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3475373792260686772=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============3475373792260686772==
Content-Type: multipart/alternative; 
 boundary="=_8vaRUJPk8dkpUL299rGMwoZkxXI38n1cVRvVMb1phGQ5om78"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_8vaRUJPk8dkpUL299rGMwoZkxXI38n1cVRvVMb1phGQ5om78
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The swiotlb-xen used by classic-xen kernels (which I assume is what=0D=0A=
Carsten means by "Xenified") isn't exactly the same as the stuff in=0D=0A=
mainline Linux, it's been heavily refactored for one thing. It's not=0D=0A=
impossible that mainline is bouncing something it doesn't really need=0D=0A=
to.=0D=0A=0D=0AYes, it's a 2.6.34 kernel with Andrew Lyon's backported pa=
tches found here:=0D=0A=0D=0A=C2=A0=0D=0A=C2=A0 http://code.google.com/p/=
gentoo-xen-kernel/downloads/list=0D=0A=0D=0A=C2=A0=0D=0AGrC.=0D=0A=0D=0A
--=_8vaRUJPk8dkpUL299rGMwoZkxXI38n1cVRvVMb1phGQ5om78
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
br /><blockquote style=3D"border-left: 2px solid #325FBA; padding-left: 5=
px;margin-left:5px;">The swiotlb-xen used by classic-xen kernels (which I=
 assume is what<br />Carsten means by &quot;Xenified&quot;) isn&#39;t exa=
ctly the same as the stuff in<br />mainline Linux, it&#39;s been heavily =
refactored for one thing. It&#39;s not<br />impossible that mainline is b=
ouncing something it doesn&#39;t really need<br />to.<br /></blockquote><=
p>Yes, it&#39;s a 2.6.34 kernel with Andrew Lyon&#39;s backported patches=
 found here:</p><p>&nbsp;</p><p>&nbsp; http://code.google.com/p/gentoo-xe=
n-kernel/downloads/list</p><p>&nbsp;</p><p>GrC.</p>=0A</body>=0A</html>
--=_8vaRUJPk8dkpUL299rGMwoZkxXI38n1cVRvVMb1phGQ5om78--



--===============3475373792260686772==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3475373792260686772==--



From xen-devel-bounces@lists.xensource.com Tue Nov 29 09:38:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 09:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVK8Q-00051j-A4; Tue, 29 Nov 2011 09:37:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RVK8O-00051N-Re
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 09:37:53 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322559435!3514344!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.3 required=7.0 tests=FROM_EXCESS_QP,HTML_60_70,
	HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11415 invoked from network); 29 Nov 2011 09:37:15 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 09:37:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=7fVcMIqsBtP/PuIYXX6c6mPb19Rm+
	f01ESwuWdHiVzg=; b=cr52cHH1iMfd7RWxNVzt3+EYkhw41D9s7Na1CSQSgO7f5
	5gNq6K0TC/xjmf6sXVLCNYMGp9jJcxP1F33SBi0UnMlKYmeCNW4sgZzS2k7bXPdb
	wmIzBGE+umytJ2ygbEnNlfZeDGn9bk3B8xtbQkQ8G0si/o3MPPlJ3D6x4AClxI=
Received: (qmail 21882 invoked from network); 29 Nov 2011 10:37:15 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.180.138)
	by mail.zeus06.de with ESMTPA; 29 Nov 2011 10:37:15 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id E9C392C51A;
	Tue, 29 Nov 2011 10:37:14 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 6eudLkVriNhw; Tue, 29 Nov 2011 10:37:12 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id A2B802C51B;
	Tue, 29 Nov 2011 10:37:12 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>, 
	=?utf-8?Q?Ian_Campbell?= <Ian.Campbell@citrix.com>
Date: Tue, 29 Nov 2011 10:37:12 +0100
Mime-Version: 1.0
In-Reply-To: <1322494816.20646.14.camel@zakaz.uk.xensource.com>
References: <1322494816.20646.14.camel@zakaz.uk.xensource.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ed4a7c8.53fb.1fc7026279874c8b@uhura.space.zz>
Cc: =?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>,
	=?utf-8?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3475373792260686772=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============3475373792260686772==
Content-Type: multipart/alternative; 
 boundary="=_8vaRUJPk8dkpUL299rGMwoZkxXI38n1cVRvVMb1phGQ5om78"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_8vaRUJPk8dkpUL299rGMwoZkxXI38n1cVRvVMb1phGQ5om78
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The swiotlb-xen used by classic-xen kernels (which I assume is what=0D=0A=
Carsten means by "Xenified") isn't exactly the same as the stuff in=0D=0A=
mainline Linux, it's been heavily refactored for one thing. It's not=0D=0A=
impossible that mainline is bouncing something it doesn't really need=0D=0A=
to.=0D=0A=0D=0AYes, it's a 2.6.34 kernel with Andrew Lyon's backported pa=
tches found here:=0D=0A=0D=0A=C2=A0=0D=0A=C2=A0 http://code.google.com/p/=
gentoo-xen-kernel/downloads/list=0D=0A=0D=0A=C2=A0=0D=0AGrC.=0D=0A=0D=0A
--=_8vaRUJPk8dkpUL299rGMwoZkxXI38n1cVRvVMb1phGQ5om78
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
br /><blockquote style=3D"border-left: 2px solid #325FBA; padding-left: 5=
px;margin-left:5px;">The swiotlb-xen used by classic-xen kernels (which I=
 assume is what<br />Carsten means by &quot;Xenified&quot;) isn&#39;t exa=
ctly the same as the stuff in<br />mainline Linux, it&#39;s been heavily =
refactored for one thing. It&#39;s not<br />impossible that mainline is b=
ouncing something it doesn&#39;t really need<br />to.<br /></blockquote><=
p>Yes, it&#39;s a 2.6.34 kernel with Andrew Lyon&#39;s backported patches=
 found here:</p><p>&nbsp;</p><p>&nbsp; http://code.google.com/p/gentoo-xe=
n-kernel/downloads/list</p><p>&nbsp;</p><p>GrC.</p>=0A</body>=0A</html>
--=_8vaRUJPk8dkpUL299rGMwoZkxXI38n1cVRvVMb1phGQ5om78--



--===============3475373792260686772==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3475373792260686772==--



From xen-devel-bounces@lists.xensource.com Tue Nov 29 09:42:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 09:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVKCf-0005J0-99; Tue, 29 Nov 2011 09:42:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVKCd-0005It-Vi
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 09:42:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322559669!59135087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8618 invoked from network); 29 Nov 2011 09:41:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 09:41:09 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9178846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:41:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 09:41:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 29 Nov 2011 09:41:43 +0000
In-Reply-To: <CAPLaKK6usX0BPg-fm7yLVZVH4_roF320TJ0yQNGMb=EUKmSgVg@mail.gmail.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<00ea49f77bdcef16251e.1322232583@cosworth.uk.xensource.com>
	<CAPLaKK6usX0BPg-fm7yLVZVH4_roF320TJ0yQNGMb=EUKmSgVg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322559703.20646.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 15 v2] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTExLTI1IGF0IDE4OjQzICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
OgoKPiA+IGRpZmYgLXIgZGRlYWM4YjIzN2U0IC1yIDAwZWE0OWY3N2JkYyBkb2NzL2dlbi1odG1s
LWluZGV4Cj4gPiAtLS0gL2Rldi9udWxsICAgVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
Cj4gPiArKysgYi9kb2NzL2dlbi1odG1sLWluZGV4ICAgICAgIEZyaSBOb3YgMjUgMTQ6MzQ6MjEg
MjAxMSArMDAwMAo+ID4gQEAgLTAsMCArMSwxMzYgQEAKPiA+ICsjIS91c3IvYmluL3BlcmwgLXcK
PiAKPiBXaGF0IGFib3V0IHVzaW5nIHRoZSBmb2xsb3dpbmc6Cj4gCj4gIyEvdXNyL2Jpbi9lbnYg
cGVybAo+IHVzZSB3YXJuaW5nczsKWy4uLl0KCklhbiBKIHN1Z2dlc3RlZCB0byB1c2UgIi91c3Iv
YmluL2VudiBwZXJsIiBhbmQgdG8gaW52b2tlIHRoZSBzY3JpcHQgaW4KdGhlIE1ha2VmaWxlIHdp
dGggIHBlcmwgLXcgZGlyZWN0bHkgKGluIHJlYWxpdHkgb25seSB0aGUgTWFrZWZpbGUKaW52b2Nh
dGlvbiBtYXR0ZXJzKS4gU28gdGhpcyBpcyB3aGF0IHRoZSBmb2xsb3dpbmcgcmVwbGFjZW1lbnQg
cGF0Y2gKZG9lczoKCjg8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgojIEhH
IGNoYW5nZXNldCBwYXRjaAojIFVzZXIgSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4
LmNvbT4KIyBEYXRlIDEzMjI1NTk1OTQgMAojIE5vZGUgSUQgZjJiZTYyNjlkNWUyM2RmYzcxYzYy
N2FlZjU4OGFkZGRjNmEwZGE4YQojIFBhcmVudCAgZGRlYWM4YjIzN2U0ZjcxZDA1YzgxN2ZhODQz
MjQxNzg4NmU3ZTIwMgpkb2NzOiBnZW5lcmF0ZSBhbiBpbmRleCBmb3IgdGhlIGh0bWwgb3V0cHV0
CgpuYjogSSdtIG5vdCBhIFBlcmwgd2l6YXJkLi4uCgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJl
bGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgoKZGlmZiAtciBkZGVhYzhiMjM3ZTQgLXIgZjJi
ZTYyNjlkNWUyIGRvY3MvSU5ERVgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKKysrIGIvZG9jcy9JTkRFWAlUdWUgTm92IDI5IDA5OjM5OjU0IDIwMTEgKzAwMDAK
QEAgLTAsMCArMSw1IEBACittaXNjL2h2bS1lbXVsYXRlZC11bnBsdWcJWGVuIEhWTSBlbXVsYXRl
ZCBkZXZpY2UgdW5wbHVnIHByb3RvY29sCisKKyMgVGhlc2UgYXJlIG5vdCBhbGwgdGhhdCB1c2Vm
dWwgYW55bW9yZSwgaGlkZSB0aGVtIGZyb20gdGhlIGluZGV4CitpbnRlcmZhY2UvaW5kZXgJCQlO
Ty1JTkRFWAordXNlci9pbmRleAkJCU5PLUlOREVYCmRpZmYgLXIgZGRlYWM4YjIzN2U0IC1yIGYy
YmU2MjY5ZDVlMiBkb2NzL01ha2VmaWxlCi0tLSBhL2RvY3MvTWFrZWZpbGUJRnJpIE5vdiAyNSAx
MTo1MzowNiAyMDExICswMDAwCisrKyBiL2RvY3MvTWFrZWZpbGUJVHVlIE5vdiAyOSAwOTozOTo1
NCAyMDExICswMDAwCkBAIC00NSw3ICs0NSw3IEBAIHBzOiAkKERPQ19QUykKIHBkZjogJChET0Nf
UERGKQogCiAuUEhPTlk6IGh0bWwKLWh0bWw6ICQoRE9DX0hUTUwpCitodG1sOiAkKERPQ19IVE1M
KSBodG1sL2luZGV4Lmh0bWwKIAogLlBIT05ZOiB0eHQKIHR4dDogJChET0NfVFhUKQpAQCAtMTI4
LDYgKzEyOCw5IEBAIGh0bWwvJS9pbmRleC5odG1sOiBzcmMvJS50ZXgKIAkkPCAxPi9kZXYvbnVs
bCAyPi9kZXYvbnVsbCA7IGVsc2UgXAogCWVjaG8gImxhdGV4Mmh0bWwgbm90IGluc3RhbGxlZDsg
c2tpcHBpbmcgJCouIjsgZmkKIAoraHRtbC9pbmRleC5odG1sOiAkKERPQ19IVE1MKSAuL2dlbi1o
dG1sLWluZGV4IElOREVYCisJcGVybCAtdyAtLSAuL2dlbi1odG1sLWluZGV4IC1pIElOREVYIGh0
bWwgJChET0NfSFRNTCkKKwogaHRtbC8lLmh0bWw6ICUubWFya2Rvd24KIAlAJChJTlNUQUxMX0RJ
UikgJChARCkKIAlAc2V0IC1lIDsgaWYgd2hpY2ggJChNQVJLRE9XTikgMT4vZGV2L251bGwgMj4v
ZGV2L251bGw7IHRoZW4gXApkaWZmIC1yIGRkZWFjOGIyMzdlNCAtciBmMmJlNjI2OWQ1ZTIgZG9j
cy9nZW4taHRtbC1pbmRleAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi9kb2NzL2dlbi1odG1sLWluZGV4CVR1ZSBOb3YgMjkgMDk6Mzk6NTQgMjAxMSAr
MDAwMApAQCAtMCwwICsxLDEzNiBAQAorIyEvdXNyL2Jpbi9lbnYgcGVybAorCisjCisjIEdlbmVy
YXRlIGluZGV4ZXMgZm9yIGh0bWwgZG9jdW1lbnRhdGlvbgorIworCit1c2Ugc3RyaWN0OwordXNl
IHdhcm5pbmdzOworCit1c2UgR2V0b3B0OjpMb25nOwordXNlIElPOjpGaWxlOwordXNlIEZpbGU6
OkJhc2VuYW1lOwordXNlIExpc3Q6Ok1vcmVVdGlscyBxdy8gdW5pcSAvOworCitHZXRvcHQ6Okxv
bmc6OkNvbmZpZ3VyZSgnYnVuZGxpbmcnKTsKKworQEFSR1YgPj0gMiBvciBkaWU7CisKK291ciBA
ZG9jczsKK291ciBAZGlyczsKK291ciAlaW5kZXg7CisKK291ciAkb3V0ZGlyOworCitHZXRPcHRp
b25zKCJpPXMiID0+IHN1YiB7IHJlYWRfaW5kZXgoQF8pO30gKQorICAgIG9yIGRpZTsKKworKCRv
dXRkaXIsQGRvY3MpID0gQEFSR1Y7CisKK3N1YiB3cml0ZV9maWxlICgkJCkgeworICAgIG15ICgk
b3BhdGgsICRvZGF0YSkgPSBAXzsKKyAgICBwcmludCBTVERPVVQgIldyaXRpbmc6ICRvcGF0aFxu
IjsKKyAgICBteSAkb3V0ID0gbmV3IElPOjpGaWxlICIkb3BhdGgubmV3IiwgJz4nIG9yIGRpZSAi
JG9wYXRoICQhIjsKKyAgICBwcmludCAkb3V0ICRvZGF0YSBvciBkaWUgJCE7CisgICAgcmVuYW1l
ICIkb3BhdGgubmV3IiwgIiRvcGF0aCIgb3IgZGllICIkb3BhdGggJCEiOworfQorCitzdWIgbWFr
ZV9wYWdlICgkJCQpIHsKKyAgICBteSAoJGZpbGUsJHRpdGxlLCRjb250ZW50KSA9IEBfOworICAg
IG15ICRvID0gJyc7CisgICAgbXkgJGgxOworICAgIGlmICggJHRpdGxlIGVxICIiICkKKyAgICB7
CisgICAgICAgICR0aXRsZSA9ICRoMSA9ICJYZW4gRG9jdW1lbnRhdGlvbiI7CisgICAgfQorICAg
IGVsc2UKKyAgICB7CisgICAgICAgICRoMSA9ICI8YSBocmVmPVwiLi4vaW5kZXguKD86aHRtbHx0
eHQpXCI+WGVuIERvY3VtZW50YXRpb248L2E+IC0gJHRpdGxlIjsKKyAgICAgICAgJHRpdGxlID0g
IlhlbiBEb2N1bWVudGF0aW9uIC0gJHRpdGxlIjsKKyAgICB9CisgICAgJG8gLj0gPDxFTkQ7Cis8
aHRtbD48aGVhZD48dGl0bGU+JHRpdGxlPC90aXRsZT48L2hlYWQ+Cis8Ym9keT4KKzxoMT4kaDE8
L2gxPgorPHVsPgorJGNvbnRlbnQKKzwvdWw+Cis8L2JvZHk+PC9odG1sPgorRU5ECisgICAgd3Jp
dGVfZmlsZSgkZmlsZSwgJG8pOworfQorCitzdWIgbWFrZV9saW5rdGV4dCAoJCkgeworICAgIG15
ICgkbCkgPSBAXzsKKyAgICByZXR1cm4gIiQxKCQyKSIgaWYgJGwgPX4gbSxebWFuLyguKilcLihb
MC05XS4qKVwuaHRtbCw7CisgICAgJGwgPX4gcy8uKGh0bWwpJC8vZzsKKyAgICByZXR1cm4gJGlu
ZGV4eyRsfSBpZiBleGlzdHMgJGluZGV4eyRsfTsKKyAgICByZXR1cm4gYmFzZW5hbWUoJGwpOwor
fQorCitzdWIgbWFrZV9saW5rICgkJCkgeworICAgIG15ICgkcmVmLCRiYXNlKSA9IEBfOworCisg
ICAgbXkgJHR4dCA9IG1ha2VfbGlua3RleHQoJHJlZik7CisgICAgJHJlZiA9IGJhc2VuYW1lKCRy
ZWYpIGlmICRiYXNlOworCisgICAgcmV0dXJuICI8bGk+PGEgaHJlZj1cIiRyZWZcIj4kdHh0PC9h
PjwvbGk+XG4iOworfQorCitzdWIgbWFrZV9saW5rcyAoJCRAKSB7CisgICAgbXkgKCRkaXIsJGJh
c2UsQGRvY3MpID0gQF87CisgICAgbXkgJGlkeCA9ICcnOworICAgIGZvcmVhY2ggbXkgJG9mIChz
b3J0IHsgJGEgY21wICRiIH0gQGRvY3MpIHsKKyAgICAgICAgJGlkeCAuPSBtYWtlX2xpbmsoJG9m
LCRiYXNlKTsKKyAgICB9CisgICAgcmV0dXJuICRpZHg7Cit9CisKK3N1YiByZWFkX2luZGV4ICgk
JCkgeworICAgIG15ICgkb3B0LCAkdmFsKSA9IEBfOworICAgIG15ICRpZHggPSBuZXcgSU86OkZp
bGUgIiR2YWwiLCAnPCcgb3IgZGllICIkdmFsICQhIjsKKyAgICB3aGlsZSAoJF8gPSAkaWR4LT5n
ZXRsaW5lKCkpIHsKKwlzL15ccysvLzsKKwlzL1xzKyQvLzsKKwluZXh0IGlmIG0vXlwjLzsKKwlu
ZXh0IHVubGVzcyBtL1xTLzsKKwltL14oXFMrKVxzKyhcUy4qKSQvIG9yIGRpZTsKKyAgICAgICAg
JGluZGV4eyQxfSA9ICQyOworICAgIH0KK30KKworZm9yIChAZG9jcykgeyBzLF5cUSRvdXRkaXJc
RS8sLCB9CisKK0Bkb2NzID0gZ3JlcCB7IC1lICIkb3V0ZGlyLyRfIiAmJiAobWFrZV9saW5rdGV4
dCgkXykgbmUgIk5PLUlOREVYIikgfSBAZG9jczsKKworbXkgJHRvcCA9ICcnOworCitmb3JlYWNo
IG15ICRvZCAoc29ydCB7ICRhIGNtcCAkYiB9IHVuaXEgbWFwIHsgZGlybmFtZSgkXykgfSBAZG9j
cykgeworICAgIG15IEBkID0gKGdyZXAgL15cUSRvZFxFLywgQGRvY3MpOworICAgIGlmICggQGQg
PT0gMSBhbmQgJGRbMF0gZXEgIiRvZC9pbmRleC5odG1sIiApCisgICAgeworICAgICAgICAkdG9w
IC49ICI8bGk+PGEgaHJlZj1cIiR7b2R9L2luZGV4Lmh0bWxcIj4ke29kfS9pbmRleC5odG1sPC9h
PjwvbGk+XG4iOworICAgIH0KKyAgICBlbHNlCisgICAgeworCW15ICRsaW5rcyA9IG1ha2VfbGlu
a3MoJG9kLDAsQGQpOworCSR0b3AgLj0gPDxFTkQ7Cis8bGk+PGEgaHJlZj1cIiR7b2R9L2luZGV4
Lmh0bWxcIj4kb2Q8L2E+PC9saT4KKzx1bD4KKyRsaW5rcworPC91bD4KK0VORAorCisJJGxpbmtz
ID0gbWFrZV9saW5rcygkb2QsMSxAZCk7CisgICAgICAgIG15ICRpZHggPSAnJzsKKwkkaWR4IC49
IDw8RU5EOworPGxpPiRvZDwvbGk+Cis8dWw+CiskbGlua3MKKzwvdWw+CitFTkQKKyAgICAgICAg
bWFrZV9wYWdlKCIkb3V0ZGlyLyRvZC9pbmRleC5odG1sIiwgJG9kLCAkaWR4KTsKKyAgICB9Cit9
CisKK21ha2VfcGFnZSgiJG91dGRpci9pbmRleC5odG1sIiwgIiIsICR0b3ApOwoKCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Nov 29 09:42:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 09:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVKCf-0005J0-99; Tue, 29 Nov 2011 09:42:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVKCd-0005It-Vi
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 09:42:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322559669!59135087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8618 invoked from network); 29 Nov 2011 09:41:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 09:41:09 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9178846"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:41:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 09:41:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 29 Nov 2011 09:41:43 +0000
In-Reply-To: <CAPLaKK6usX0BPg-fm7yLVZVH4_roF320TJ0yQNGMb=EUKmSgVg@mail.gmail.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<00ea49f77bdcef16251e.1322232583@cosworth.uk.xensource.com>
	<CAPLaKK6usX0BPg-fm7yLVZVH4_roF320TJ0yQNGMb=EUKmSgVg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322559703.20646.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 11 of 15 v2] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDExLTExLTI1IGF0IDE4OjQzICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
OgoKPiA+IGRpZmYgLXIgZGRlYWM4YjIzN2U0IC1yIDAwZWE0OWY3N2JkYyBkb2NzL2dlbi1odG1s
LWluZGV4Cj4gPiAtLS0gL2Rldi9udWxsICAgVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
Cj4gPiArKysgYi9kb2NzL2dlbi1odG1sLWluZGV4ICAgICAgIEZyaSBOb3YgMjUgMTQ6MzQ6MjEg
MjAxMSArMDAwMAo+ID4gQEAgLTAsMCArMSwxMzYgQEAKPiA+ICsjIS91c3IvYmluL3BlcmwgLXcK
PiAKPiBXaGF0IGFib3V0IHVzaW5nIHRoZSBmb2xsb3dpbmc6Cj4gCj4gIyEvdXNyL2Jpbi9lbnYg
cGVybAo+IHVzZSB3YXJuaW5nczsKWy4uLl0KCklhbiBKIHN1Z2dlc3RlZCB0byB1c2UgIi91c3Iv
YmluL2VudiBwZXJsIiBhbmQgdG8gaW52b2tlIHRoZSBzY3JpcHQgaW4KdGhlIE1ha2VmaWxlIHdp
dGggIHBlcmwgLXcgZGlyZWN0bHkgKGluIHJlYWxpdHkgb25seSB0aGUgTWFrZWZpbGUKaW52b2Nh
dGlvbiBtYXR0ZXJzKS4gU28gdGhpcyBpcyB3aGF0IHRoZSBmb2xsb3dpbmcgcmVwbGFjZW1lbnQg
cGF0Y2gKZG9lczoKCjg8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgojIEhH
IGNoYW5nZXNldCBwYXRjaAojIFVzZXIgSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4
LmNvbT4KIyBEYXRlIDEzMjI1NTk1OTQgMAojIE5vZGUgSUQgZjJiZTYyNjlkNWUyM2RmYzcxYzYy
N2FlZjU4OGFkZGRjNmEwZGE4YQojIFBhcmVudCAgZGRlYWM4YjIzN2U0ZjcxZDA1YzgxN2ZhODQz
MjQxNzg4NmU3ZTIwMgpkb2NzOiBnZW5lcmF0ZSBhbiBpbmRleCBmb3IgdGhlIGh0bWwgb3V0cHV0
CgpuYjogSSdtIG5vdCBhIFBlcmwgd2l6YXJkLi4uCgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJl
bGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgoKZGlmZiAtciBkZGVhYzhiMjM3ZTQgLXIgZjJi
ZTYyNjlkNWUyIGRvY3MvSU5ERVgKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKKysrIGIvZG9jcy9JTkRFWAlUdWUgTm92IDI5IDA5OjM5OjU0IDIwMTEgKzAwMDAK
QEAgLTAsMCArMSw1IEBACittaXNjL2h2bS1lbXVsYXRlZC11bnBsdWcJWGVuIEhWTSBlbXVsYXRl
ZCBkZXZpY2UgdW5wbHVnIHByb3RvY29sCisKKyMgVGhlc2UgYXJlIG5vdCBhbGwgdGhhdCB1c2Vm
dWwgYW55bW9yZSwgaGlkZSB0aGVtIGZyb20gdGhlIGluZGV4CitpbnRlcmZhY2UvaW5kZXgJCQlO
Ty1JTkRFWAordXNlci9pbmRleAkJCU5PLUlOREVYCmRpZmYgLXIgZGRlYWM4YjIzN2U0IC1yIGYy
YmU2MjY5ZDVlMiBkb2NzL01ha2VmaWxlCi0tLSBhL2RvY3MvTWFrZWZpbGUJRnJpIE5vdiAyNSAx
MTo1MzowNiAyMDExICswMDAwCisrKyBiL2RvY3MvTWFrZWZpbGUJVHVlIE5vdiAyOSAwOTozOTo1
NCAyMDExICswMDAwCkBAIC00NSw3ICs0NSw3IEBAIHBzOiAkKERPQ19QUykKIHBkZjogJChET0Nf
UERGKQogCiAuUEhPTlk6IGh0bWwKLWh0bWw6ICQoRE9DX0hUTUwpCitodG1sOiAkKERPQ19IVE1M
KSBodG1sL2luZGV4Lmh0bWwKIAogLlBIT05ZOiB0eHQKIHR4dDogJChET0NfVFhUKQpAQCAtMTI4
LDYgKzEyOCw5IEBAIGh0bWwvJS9pbmRleC5odG1sOiBzcmMvJS50ZXgKIAkkPCAxPi9kZXYvbnVs
bCAyPi9kZXYvbnVsbCA7IGVsc2UgXAogCWVjaG8gImxhdGV4Mmh0bWwgbm90IGluc3RhbGxlZDsg
c2tpcHBpbmcgJCouIjsgZmkKIAoraHRtbC9pbmRleC5odG1sOiAkKERPQ19IVE1MKSAuL2dlbi1o
dG1sLWluZGV4IElOREVYCisJcGVybCAtdyAtLSAuL2dlbi1odG1sLWluZGV4IC1pIElOREVYIGh0
bWwgJChET0NfSFRNTCkKKwogaHRtbC8lLmh0bWw6ICUubWFya2Rvd24KIAlAJChJTlNUQUxMX0RJ
UikgJChARCkKIAlAc2V0IC1lIDsgaWYgd2hpY2ggJChNQVJLRE9XTikgMT4vZGV2L251bGwgMj4v
ZGV2L251bGw7IHRoZW4gXApkaWZmIC1yIGRkZWFjOGIyMzdlNCAtciBmMmJlNjI2OWQ1ZTIgZG9j
cy9nZW4taHRtbC1pbmRleAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi9kb2NzL2dlbi1odG1sLWluZGV4CVR1ZSBOb3YgMjkgMDk6Mzk6NTQgMjAxMSAr
MDAwMApAQCAtMCwwICsxLDEzNiBAQAorIyEvdXNyL2Jpbi9lbnYgcGVybAorCisjCisjIEdlbmVy
YXRlIGluZGV4ZXMgZm9yIGh0bWwgZG9jdW1lbnRhdGlvbgorIworCit1c2Ugc3RyaWN0OwordXNl
IHdhcm5pbmdzOworCit1c2UgR2V0b3B0OjpMb25nOwordXNlIElPOjpGaWxlOwordXNlIEZpbGU6
OkJhc2VuYW1lOwordXNlIExpc3Q6Ok1vcmVVdGlscyBxdy8gdW5pcSAvOworCitHZXRvcHQ6Okxv
bmc6OkNvbmZpZ3VyZSgnYnVuZGxpbmcnKTsKKworQEFSR1YgPj0gMiBvciBkaWU7CisKK291ciBA
ZG9jczsKK291ciBAZGlyczsKK291ciAlaW5kZXg7CisKK291ciAkb3V0ZGlyOworCitHZXRPcHRp
b25zKCJpPXMiID0+IHN1YiB7IHJlYWRfaW5kZXgoQF8pO30gKQorICAgIG9yIGRpZTsKKworKCRv
dXRkaXIsQGRvY3MpID0gQEFSR1Y7CisKK3N1YiB3cml0ZV9maWxlICgkJCkgeworICAgIG15ICgk
b3BhdGgsICRvZGF0YSkgPSBAXzsKKyAgICBwcmludCBTVERPVVQgIldyaXRpbmc6ICRvcGF0aFxu
IjsKKyAgICBteSAkb3V0ID0gbmV3IElPOjpGaWxlICIkb3BhdGgubmV3IiwgJz4nIG9yIGRpZSAi
JG9wYXRoICQhIjsKKyAgICBwcmludCAkb3V0ICRvZGF0YSBvciBkaWUgJCE7CisgICAgcmVuYW1l
ICIkb3BhdGgubmV3IiwgIiRvcGF0aCIgb3IgZGllICIkb3BhdGggJCEiOworfQorCitzdWIgbWFr
ZV9wYWdlICgkJCQpIHsKKyAgICBteSAoJGZpbGUsJHRpdGxlLCRjb250ZW50KSA9IEBfOworICAg
IG15ICRvID0gJyc7CisgICAgbXkgJGgxOworICAgIGlmICggJHRpdGxlIGVxICIiICkKKyAgICB7
CisgICAgICAgICR0aXRsZSA9ICRoMSA9ICJYZW4gRG9jdW1lbnRhdGlvbiI7CisgICAgfQorICAg
IGVsc2UKKyAgICB7CisgICAgICAgICRoMSA9ICI8YSBocmVmPVwiLi4vaW5kZXguKD86aHRtbHx0
eHQpXCI+WGVuIERvY3VtZW50YXRpb248L2E+IC0gJHRpdGxlIjsKKyAgICAgICAgJHRpdGxlID0g
IlhlbiBEb2N1bWVudGF0aW9uIC0gJHRpdGxlIjsKKyAgICB9CisgICAgJG8gLj0gPDxFTkQ7Cis8
aHRtbD48aGVhZD48dGl0bGU+JHRpdGxlPC90aXRsZT48L2hlYWQ+Cis8Ym9keT4KKzxoMT4kaDE8
L2gxPgorPHVsPgorJGNvbnRlbnQKKzwvdWw+Cis8L2JvZHk+PC9odG1sPgorRU5ECisgICAgd3Jp
dGVfZmlsZSgkZmlsZSwgJG8pOworfQorCitzdWIgbWFrZV9saW5rdGV4dCAoJCkgeworICAgIG15
ICgkbCkgPSBAXzsKKyAgICByZXR1cm4gIiQxKCQyKSIgaWYgJGwgPX4gbSxebWFuLyguKilcLihb
MC05XS4qKVwuaHRtbCw7CisgICAgJGwgPX4gcy8uKGh0bWwpJC8vZzsKKyAgICByZXR1cm4gJGlu
ZGV4eyRsfSBpZiBleGlzdHMgJGluZGV4eyRsfTsKKyAgICByZXR1cm4gYmFzZW5hbWUoJGwpOwor
fQorCitzdWIgbWFrZV9saW5rICgkJCkgeworICAgIG15ICgkcmVmLCRiYXNlKSA9IEBfOworCisg
ICAgbXkgJHR4dCA9IG1ha2VfbGlua3RleHQoJHJlZik7CisgICAgJHJlZiA9IGJhc2VuYW1lKCRy
ZWYpIGlmICRiYXNlOworCisgICAgcmV0dXJuICI8bGk+PGEgaHJlZj1cIiRyZWZcIj4kdHh0PC9h
PjwvbGk+XG4iOworfQorCitzdWIgbWFrZV9saW5rcyAoJCRAKSB7CisgICAgbXkgKCRkaXIsJGJh
c2UsQGRvY3MpID0gQF87CisgICAgbXkgJGlkeCA9ICcnOworICAgIGZvcmVhY2ggbXkgJG9mIChz
b3J0IHsgJGEgY21wICRiIH0gQGRvY3MpIHsKKyAgICAgICAgJGlkeCAuPSBtYWtlX2xpbmsoJG9m
LCRiYXNlKTsKKyAgICB9CisgICAgcmV0dXJuICRpZHg7Cit9CisKK3N1YiByZWFkX2luZGV4ICgk
JCkgeworICAgIG15ICgkb3B0LCAkdmFsKSA9IEBfOworICAgIG15ICRpZHggPSBuZXcgSU86OkZp
bGUgIiR2YWwiLCAnPCcgb3IgZGllICIkdmFsICQhIjsKKyAgICB3aGlsZSAoJF8gPSAkaWR4LT5n
ZXRsaW5lKCkpIHsKKwlzL15ccysvLzsKKwlzL1xzKyQvLzsKKwluZXh0IGlmIG0vXlwjLzsKKwlu
ZXh0IHVubGVzcyBtL1xTLzsKKwltL14oXFMrKVxzKyhcUy4qKSQvIG9yIGRpZTsKKyAgICAgICAg
JGluZGV4eyQxfSA9ICQyOworICAgIH0KK30KKworZm9yIChAZG9jcykgeyBzLF5cUSRvdXRkaXJc
RS8sLCB9CisKK0Bkb2NzID0gZ3JlcCB7IC1lICIkb3V0ZGlyLyRfIiAmJiAobWFrZV9saW5rdGV4
dCgkXykgbmUgIk5PLUlOREVYIikgfSBAZG9jczsKKworbXkgJHRvcCA9ICcnOworCitmb3JlYWNo
IG15ICRvZCAoc29ydCB7ICRhIGNtcCAkYiB9IHVuaXEgbWFwIHsgZGlybmFtZSgkXykgfSBAZG9j
cykgeworICAgIG15IEBkID0gKGdyZXAgL15cUSRvZFxFLywgQGRvY3MpOworICAgIGlmICggQGQg
PT0gMSBhbmQgJGRbMF0gZXEgIiRvZC9pbmRleC5odG1sIiApCisgICAgeworICAgICAgICAkdG9w
IC49ICI8bGk+PGEgaHJlZj1cIiR7b2R9L2luZGV4Lmh0bWxcIj4ke29kfS9pbmRleC5odG1sPC9h
PjwvbGk+XG4iOworICAgIH0KKyAgICBlbHNlCisgICAgeworCW15ICRsaW5rcyA9IG1ha2VfbGlu
a3MoJG9kLDAsQGQpOworCSR0b3AgLj0gPDxFTkQ7Cis8bGk+PGEgaHJlZj1cIiR7b2R9L2luZGV4
Lmh0bWxcIj4kb2Q8L2E+PC9saT4KKzx1bD4KKyRsaW5rcworPC91bD4KK0VORAorCisJJGxpbmtz
ID0gbWFrZV9saW5rcygkb2QsMSxAZCk7CisgICAgICAgIG15ICRpZHggPSAnJzsKKwkkaWR4IC49
IDw8RU5EOworPGxpPiRvZDwvbGk+Cis8dWw+CiskbGlua3MKKzwvdWw+CitFTkQKKyAgICAgICAg
bWFrZV9wYWdlKCIkb3V0ZGlyLyRvZC9pbmRleC5odG1sIiwgJG9kLCAkaWR4KTsKKyAgICB9Cit9
CisKK21ha2VfcGFnZSgiJG91dGRpci9pbmRleC5odG1sIiwgIiIsICR0b3ApOwoKCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Nov 29 09:43:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 09:43:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVKDu-0005OS-Oh; Tue, 29 Nov 2011 09:43:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RVKDs-0005O3-R8
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 09:43:33 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322559774!6044389!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.3 required=7.0 tests=FROM_EXCESS_QP,HTML_60_70,
	HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22930 invoked from network); 29 Nov 2011 09:42:55 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 09:42:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=E7N4m4uvnwCu2lTLT7MYIezwI9vkT
	emJ9J8+uJyASHY=; b=XKjdJkDjkF20TslGbH8iLmWK1mojeb+x7crUXUsisl49f
	//pCRyJpx+kwcv/gFGHPH954HfL2xHdOiHJer0cAwTlO//PciccgCadJ+1mWZFaI
	Eu5fUnvPnA+KKCLVZDNUEsNUbM9Ofdwpkkj0EbST/E+HlpFXPu9jGTeJLmNM18=
Received: (qmail 23866 invoked from network); 29 Nov 2011 10:42:54 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.180.138)
	by mail.zeus06.de with ESMTPA; 29 Nov 2011 10:42:54 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 865282C51B;
	Tue, 29 Nov 2011 10:42:54 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id f50S-GV4aoTd; Tue, 29 Nov 2011 10:42:45 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id D3B372C51A;
	Tue, 29 Nov 2011 10:42:45 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Tue, 29 Nov 2011 10:42:45 +0100
Mime-Version: 1.0
In-Reply-To: <20111128153027.GD9655@andromeda.dapyr.net>
References: <20111128153027.GD9655@andromeda.dapyr.net>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ed4a915.54fd.32c353c03909c3aa@uhura.space.zz>
Cc: =?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8311085662891811754=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============8311085662891811754==
Content-Type: multipart/alternative; 
 boundary="=_lAaRP6aG5X-34uc1sIGN5JX23YWcRTK9j+6QCmonallY6RC5"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_lAaRP6aG5X-34uc1sIGN5JX23YWcRTK9j+6QCmonallY6RC5
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=C2=A0=0D=0A=0D=0A> =C2=A0 - with load I mean the %CPU of xentop=0D=0A> =C2=
=A0 - there is no change in CPU usage of the DomU or Dom0=0D=0A=0D=0AUhh,=
 which matrix are using for that=3F CPU usage...=3F This is if you=0D=0Ac=
hange the DomU or the amount of memory the guest has=3F This is not=0D=0A=
the load number (xentop value)=3F=0D=0A=0D=0AI had a quick look into the =
munin plugin. It reads the output of "xm li", Time in seconds and normali=
zes it.=20=0D=0ABut the effect is also visible in the CPU(%) column of xe=
ntop, if the DomU is on higher load.=0D=0A=0D=0A=C2=A0=0D=0ABR,C.=0D=0A=0D=
=0A
--=_lAaRP6aG5X-34uc1sIGN5JX23YWcRTK9j+6QCmonallY6RC5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
p>&nbsp;</p><blockquote style=3D"border-left: 2px solid #325FBA; padding-=
left: 5px;margin-left:5px;">&gt; &nbsp; - with load I mean the %CPU of xe=
ntop<br />&gt; &nbsp; - there is no change in CPU usage of the DomU or Do=
m0<br /><br />Uhh, which matrix are using for that=3F CPU usage...=3F Thi=
s is if you<br />change the DomU or the amount of memory the guest has=3F=
 This is not<br />the load number (xentop value)=3F<br /></blockquote><p>=
I had a quick look into the munin plugin. It reads the output of &quot;xm=
 li&quot;, Time in seconds and normalizes it. <br />But the effect is als=
o visible in the CPU(%) column of xentop, if the DomU is on higher load.<=
/p><p>&nbsp;</p><p>BR,C.</p>=0A</body>=0A</html>
--=_lAaRP6aG5X-34uc1sIGN5JX23YWcRTK9j+6QCmonallY6RC5--



--===============8311085662891811754==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8311085662891811754==--



From xen-devel-bounces@lists.xensource.com Tue Nov 29 09:43:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 09:43:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVKDu-0005OS-Oh; Tue, 29 Nov 2011 09:43:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RVKDs-0005O3-R8
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 09:43:33 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322559774!6044389!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.3 required=7.0 tests=FROM_EXCESS_QP,HTML_60_70,
	HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22930 invoked from network); 29 Nov 2011 09:42:55 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 09:42:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=E7N4m4uvnwCu2lTLT7MYIezwI9vkT
	emJ9J8+uJyASHY=; b=XKjdJkDjkF20TslGbH8iLmWK1mojeb+x7crUXUsisl49f
	//pCRyJpx+kwcv/gFGHPH954HfL2xHdOiHJer0cAwTlO//PciccgCadJ+1mWZFaI
	Eu5fUnvPnA+KKCLVZDNUEsNUbM9Ofdwpkkj0EbST/E+HlpFXPu9jGTeJLmNM18=
Received: (qmail 23866 invoked from network); 29 Nov 2011 10:42:54 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.180.138)
	by mail.zeus06.de with ESMTPA; 29 Nov 2011 10:42:54 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 865282C51B;
	Tue, 29 Nov 2011 10:42:54 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id f50S-GV4aoTd; Tue, 29 Nov 2011 10:42:45 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id D3B372C51A;
	Tue, 29 Nov 2011 10:42:45 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Tue, 29 Nov 2011 10:42:45 +0100
Mime-Version: 1.0
In-Reply-To: <20111128153027.GD9655@andromeda.dapyr.net>
References: <20111128153027.GD9655@andromeda.dapyr.net>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ed4a915.54fd.32c353c03909c3aa@uhura.space.zz>
Cc: =?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?konrad=2Ewilk?= <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8311085662891811754=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============8311085662891811754==
Content-Type: multipart/alternative; 
 boundary="=_lAaRP6aG5X-34uc1sIGN5JX23YWcRTK9j+6QCmonallY6RC5"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_lAaRP6aG5X-34uc1sIGN5JX23YWcRTK9j+6QCmonallY6RC5
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=C2=A0=0D=0A=0D=0A> =C2=A0 - with load I mean the %CPU of xentop=0D=0A> =C2=
=A0 - there is no change in CPU usage of the DomU or Dom0=0D=0A=0D=0AUhh,=
 which matrix are using for that=3F CPU usage...=3F This is if you=0D=0Ac=
hange the DomU or the amount of memory the guest has=3F This is not=0D=0A=
the load number (xentop value)=3F=0D=0A=0D=0AI had a quick look into the =
munin plugin. It reads the output of "xm li", Time in seconds and normali=
zes it.=20=0D=0ABut the effect is also visible in the CPU(%) column of xe=
ntop, if the DomU is on higher load.=0D=0A=0D=0A=C2=A0=0D=0ABR,C.=0D=0A=0D=
=0A
--=_lAaRP6aG5X-34uc1sIGN5JX23YWcRTK9j+6QCmonallY6RC5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
p>&nbsp;</p><blockquote style=3D"border-left: 2px solid #325FBA; padding-=
left: 5px;margin-left:5px;">&gt; &nbsp; - with load I mean the %CPU of xe=
ntop<br />&gt; &nbsp; - there is no change in CPU usage of the DomU or Do=
m0<br /><br />Uhh, which matrix are using for that=3F CPU usage...=3F Thi=
s is if you<br />change the DomU or the amount of memory the guest has=3F=
 This is not<br />the load number (xentop value)=3F<br /></blockquote><p>=
I had a quick look into the munin plugin. It reads the output of &quot;xm=
 li&quot;, Time in seconds and normalizes it. <br />But the effect is als=
o visible in the CPU(%) column of xentop, if the DomU is on higher load.<=
/p><p>&nbsp;</p><p>BR,C.</p>=0A</body>=0A</html>
--=_lAaRP6aG5X-34uc1sIGN5JX23YWcRTK9j+6QCmonallY6RC5--



--===============8311085662891811754==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8311085662891811754==--



From xen-devel-bounces@lists.xensource.com Tue Nov 29 09:47:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 09:47:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVKH3-0005ao-E0; Tue, 29 Nov 2011 09:46:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RVKH2-0005aE-6L
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 09:46:48 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322559970!6126837!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.3 required=7.0 tests=FROM_EXCESS_QP,HTML_60_70,
	HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10721 invoked from network); 29 Nov 2011 09:46:11 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 09:46:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=/1uoNL1V9at72w/NeXlKk8ARy7h/h
	ofo6ymtoVcf1zg=; b=oUvobnr2yLRY8B5XjXJIP4ERYQE/u1awz0qgZtTjAPzRV
	eopNU7xDppyI9tvuZa7V7OpwxigeHSFbAP1sdCAjLhbfTtdgl2MJV5+6cTOIGh/c
	jJoL7fEhn/6OP85TowsM0y9y37Lr1cHomTEtnCtSV/objV86KMjZqqoRT0yxQ4=
Received: (qmail 25225 invoked from network); 29 Nov 2011 10:46:10 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.180.138)
	by mail.zeus06.de with ESMTPA; 29 Nov 2011 10:46:10 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 526222C51B;
	Tue, 29 Nov 2011 10:46:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 4f7Bl1t4A0dJ; Tue, 29 Nov 2011 10:46:02 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 1C4F02C51A;
	Tue, 29 Nov 2011 10:46:02 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Ian_Campbell?= <ian.campbell@citrix.com>, 
	=?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Tue, 29 Nov 2011 10:46:02 +0100
Mime-Version: 1.0
In-Reply-To: <20111128164516.GA26664@phenom.dumpdata.com>
References: <20111128164516.GA26664@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ed4a9da.55e1.1872d0d763ad1906@uhura.space.zz>
Cc: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6505958179899237990=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============6505958179899237990==
Content-Type: multipart/alternative; 
 boundary="=_qDaRfmKSaZg56dIDHyy9ea+dyyk5LeUkGoBWDZJLNcefTnWp"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_qDaRfmKSaZg56dIDHyy9ea+dyyk5LeUkGoBWDZJLNcefTnWp
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Carsten, let me prep up a patch that will print some diagnostic informati=
on=0D=0Aduring the runtime - to see how often it does the bounce, the usa=
ge, etc..=0D=0A=0D=0A=C2=A0=0D=0AJup, looking forward to implementing it.=
 I can include them into any kernel. 2.6.18 would be=0D=0A=0D=0Aa bit dif=
ficult though, as the driver pack isn't compatible any longer...so I'd pr=
efer 2.6.34 Xenified=0D=0A=0D=0Avs. 3.1.2 pvops.=0D=0A=0D=0A=C2=A0=0D=0AB=
R,C.=0D=0A=0D=0A
--=_qDaRfmKSaZg56dIDHyy9ea+dyyk5LeUkGoBWDZJLNcefTnWp
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
br /><blockquote style=3D"border-left: 2px solid #325FBA; padding-left: 5=
px;margin-left:5px;">Carsten, let me prep up a patch that will print some=
 diagnostic information<br />during the runtime - to see how often it doe=
s the bounce, the usage, etc..</blockquote><p>&nbsp;</p><p>Jup, looking f=
orward to implementing it. I can include them into any kernel. 2.6.18 wou=
ld be</p><p>a bit difficult though, as the driver pack isn&#39;t compatib=
le any longer...so I&#39;d prefer 2.6.34 Xenified</p><p>vs. 3.1.2 pvops.<=
/p><p>&nbsp;</p><p>BR,C.</p>=0A</body>=0A</html>
--=_qDaRfmKSaZg56dIDHyy9ea+dyyk5LeUkGoBWDZJLNcefTnWp--



--===============6505958179899237990==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6505958179899237990==--



From xen-devel-bounces@lists.xensource.com Tue Nov 29 09:47:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 09:47:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVKH3-0005ao-E0; Tue, 29 Nov 2011 09:46:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1RVKH2-0005aE-6L
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 09:46:48 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1322559970!6126837!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.3 required=7.0 tests=FROM_EXCESS_QP,HTML_60_70,
	HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10721 invoked from network); 29 Nov 2011 09:46:11 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 09:46:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.zeus06.de; h=subject
	:from:to:cc:date:mime-version:content-type:in-reply-to
	:references:message-id; s=beta; bh=/1uoNL1V9at72w/NeXlKk8ARy7h/h
	ofo6ymtoVcf1zg=; b=oUvobnr2yLRY8B5XjXJIP4ERYQE/u1awz0qgZtTjAPzRV
	eopNU7xDppyI9tvuZa7V7OpwxigeHSFbAP1sdCAjLhbfTtdgl2MJV5+6cTOIGh/c
	jJoL7fEhn/6OP85TowsM0y9y37Lr1cHomTEtnCtSV/objV86KMjZqqoRT0yxQ4=
Received: (qmail 25225 invoked from network); 29 Nov 2011 10:46:10 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.180.138)
	by mail.zeus06.de with ESMTPA; 29 Nov 2011 10:46:10 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 526222C51B;
	Tue, 29 Nov 2011 10:46:10 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at schiers.de
Received: from uhura.zz ([127.0.0.1])
	by localhost (uhura.space.zz [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 4f7Bl1t4A0dJ; Tue, 29 Nov 2011 10:46:02 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 1C4F02C51A;
	Tue, 29 Nov 2011 10:46:02 +0100 (CET)
From: =?utf-8?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?utf-8?Q?Ian_Campbell?= <ian.campbell@citrix.com>, 
	=?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>
Date: Tue, 29 Nov 2011 10:46:02 +0100
Mime-Version: 1.0
In-Reply-To: <20111128164516.GA26664@phenom.dumpdata.com>
References: <20111128164516.GA26664@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4ed4a9da.55e1.1872d0d763ad1906@uhura.space.zz>
Cc: =?utf-8?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?lersek=40redhat=2Ecom?= <lersek@redhat.com>,
	=?utf-8?Q?zhenzhong=2Eduan=40oracle=2Ecom?= <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6505958179899237990=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--===============6505958179899237990==
Content-Type: multipart/alternative; 
 boundary="=_qDaRfmKSaZg56dIDHyy9ea+dyyk5LeUkGoBWDZJLNcefTnWp"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_qDaRfmKSaZg56dIDHyy9ea+dyyk5LeUkGoBWDZJLNcefTnWp
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Carsten, let me prep up a patch that will print some diagnostic informati=
on=0D=0Aduring the runtime - to see how often it does the bounce, the usa=
ge, etc..=0D=0A=0D=0A=C2=A0=0D=0AJup, looking forward to implementing it.=
 I can include them into any kernel. 2.6.18 would be=0D=0A=0D=0Aa bit dif=
ficult though, as the driver pack isn't compatible any longer...so I'd pr=
efer 2.6.34 Xenified=0D=0A=0D=0Avs. 3.1.2 pvops.=0D=0A=0D=0A=C2=A0=0D=0AB=
R,C.=0D=0A=0D=0A
--=_qDaRfmKSaZg56dIDHyy9ea+dyyk5LeUkGoBWDZJLNcefTnWp
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww=
w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A  <meta name=3D"Generator"=
 content=3D"Zarafa WebAccess v7.0.2-29470">=0A  <meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html; charset=3Dutf-8">=0A  <title>AW: [Xen-deve=
l] Load increase after memory upgrade (part2)</title>=0A  <style type=3D"=
text/css">=0A      body=0D=0A      {=0D=0A        font-family: Arial, Ver=
dana, Sans-Serif ! important;=0D=0A        font-size: 12px;=0D=0A        =
padding: 5px 5px 5px 5px;=0D=0A        margin: 0px;=0D=0A        border-s=
tyle: none;=0D=0A        background-color: #ffffff;=0D=0A      }=0D=0A=0D=
=0A      p, ul, li=0D=0A      {=0D=0A        margin-top: 0px;=0D=0A      =
  margin-bottom: 0px;=0D=0A      }=0D=0A  </style>=0A</head>=0A<body>=0A<=
br /><blockquote style=3D"border-left: 2px solid #325FBA; padding-left: 5=
px;margin-left:5px;">Carsten, let me prep up a patch that will print some=
 diagnostic information<br />during the runtime - to see how often it doe=
s the bounce, the usage, etc..</blockquote><p>&nbsp;</p><p>Jup, looking f=
orward to implementing it. I can include them into any kernel. 2.6.18 wou=
ld be</p><p>a bit difficult though, as the driver pack isn&#39;t compatib=
le any longer...so I&#39;d prefer 2.6.34 Xenified</p><p>vs. 3.1.2 pvops.<=
/p><p>&nbsp;</p><p>BR,C.</p>=0A</body>=0A</html>
--=_qDaRfmKSaZg56dIDHyy9ea+dyyk5LeUkGoBWDZJLNcefTnWp--



--===============6505958179899237990==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6505958179899237990==--



From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:24:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVKqz-0005yD-TS; Tue, 29 Nov 2011 10:23:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVKqy-0005y8-C9
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:23:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322562199!6052275!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21959 invoked from network); 29 Nov 2011 10:23:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:23:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180015"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:23:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:23:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 29 Nov 2011 10:23:18 +0000
In-Reply-To: <20111128164516.GA26664@phenom.dumpdata.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
	<20111128164516.GA26664@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322562199.20646.30.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:45 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2011 at 03:40:13PM +0000, Ian Campbell wrote:
> > On Mon, 2011-11-28 at 15:28 +0000, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:
> > 
> > > > I looked through my old mails from you and you explained already the necessity of double
> > > > bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
> > > > Xenified kernel not have this kind of issue?
> > > 
> > > That is a puzzle. It should not. The code is very much the same - both
> > > use the generic SWIOTLB which has not changed for years.
> > 
> > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > mainline Linux, it's been heavily refactored for one thing. It's not
> > impossible that mainline is bouncing something it doesn't really need
> > to.
> 
> The usage, at least with 'pci_alloc_coherent' is that there is no bouncing
> being done. The alloc_coherent will allocate a nice page, underneath the 4GB
> mark and give it to the driver. The driver can use it as it wishes and there
> is no need to bounce buffer.

Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
subset of swiotlb is in use then, all the bouncing stuff _should_ be
idle/unused -- but has that been confirmed?

> 
> But I can't find the implementation of that in the classic Xen-SWIOTLB. It looks
> as if it is using map_single which would be taking the memory out of the
> pool for a very long time, instead of allocating memory and "swizzling" the MFNs.
> [Note, I looked at the 2.6.18 hg tree for classic, the 2.6.34 is probably
> improved much better so let me check that]
> 
> Carsten, let me prep up a patch that will print some diagnostic information
> during the runtime - to see how often it does the bounce, the usage, etc..
> 
> > 
> > It's also possible that the dma mask of the device is different/wrong in
> > mainline leading to such additional bouncing.
> 
> If one were to use map_page and such - yes. But the alloc_coherent bypasses
> that and ends up allocating it right under the 4GB (or rather it allocates
> based on the dev->coherent_mask and swizzles the MFNs as required).
> 
> > 
> > I guess it's also possible that the classic-Xen kernels are playing fast
> > and loose by not bouncing something they should (although if so they
> > appear to be getting away with it...) or that there is some difference
> > which really means mainline needs to bounce while classic-Xen doesn't.
> 
> <nods> Could be very well.
> > 
> > Ian.
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:24:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVKqz-0005yD-TS; Tue, 29 Nov 2011 10:23:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVKqy-0005y8-C9
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:23:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322562199!6052275!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21959 invoked from network); 29 Nov 2011 10:23:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:23:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180015"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:23:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:23:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 29 Nov 2011 10:23:18 +0000
In-Reply-To: <20111128164516.GA26664@phenom.dumpdata.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
	<20111128164516.GA26664@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322562199.20646.30.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:45 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2011 at 03:40:13PM +0000, Ian Campbell wrote:
> > On Mon, 2011-11-28 at 15:28 +0000, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:
> > 
> > > > I looked through my old mails from you and you explained already the necessity of double
> > > > bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
> > > > Xenified kernel not have this kind of issue?
> > > 
> > > That is a puzzle. It should not. The code is very much the same - both
> > > use the generic SWIOTLB which has not changed for years.
> > 
> > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > mainline Linux, it's been heavily refactored for one thing. It's not
> > impossible that mainline is bouncing something it doesn't really need
> > to.
> 
> The usage, at least with 'pci_alloc_coherent' is that there is no bouncing
> being done. The alloc_coherent will allocate a nice page, underneath the 4GB
> mark and give it to the driver. The driver can use it as it wishes and there
> is no need to bounce buffer.

Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
subset of swiotlb is in use then, all the bouncing stuff _should_ be
idle/unused -- but has that been confirmed?

> 
> But I can't find the implementation of that in the classic Xen-SWIOTLB. It looks
> as if it is using map_single which would be taking the memory out of the
> pool for a very long time, instead of allocating memory and "swizzling" the MFNs.
> [Note, I looked at the 2.6.18 hg tree for classic, the 2.6.34 is probably
> improved much better so let me check that]
> 
> Carsten, let me prep up a patch that will print some diagnostic information
> during the runtime - to see how often it does the bounce, the usage, etc..
> 
> > 
> > It's also possible that the dma mask of the device is different/wrong in
> > mainline leading to such additional bouncing.
> 
> If one were to use map_page and such - yes. But the alloc_coherent bypasses
> that and ends up allocating it right under the 4GB (or rather it allocates
> based on the dev->coherent_mask and swizzles the MFNs as required).
> 
> > 
> > I guess it's also possible that the classic-Xen kernels are playing fast
> > and loose by not bouncing something they should (although if so they
> > appear to be getting away with it...) or that there is some difference
> > which really means mainline needs to bounce while classic-Xen doesn't.
> 
> <nods> Could be very well.
> > 
> > Ian.
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:28:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:28:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVKv2-00065l-K2; Tue, 29 Nov 2011 10:28:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVKv1-00065Z-4i
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:28:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322562449!6029899!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14352 invoked from network); 29 Nov 2011 10:27:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:27:29 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180155"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:27:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:27:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:27:28 +0000
In-Reply-To: <1322499580-2322-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322562449.20646.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/13] libxl: idl: support new "c_only" type
 attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> This provides for fields in libxl datatypes which are only present in
> the C version of structures.  This is useful, for example, when a
> libxl datatype wants to contain fields which are used by libxl
> internally and which are only present in the structure to avoid
> additional memory allocation inconvenience.

I think "internal" or "private" would be a better description than "c".

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/gentest.py    |    2 ++
>  tools/libxl/libxltypes.py |    4 +++-
>  2 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
> index 05e77cc..9b2812e 100644
> --- a/tools/libxl/gentest.py
> +++ b/tools/libxl/gentest.py
> @@ -56,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
>          s += "%s = rand() %% 2;\n" % v
>      elif ty.typename in ["char *"]:
>          s += "%s = rand_str();\n" % v
> +    elif ty.c_only:
> +        pass
>      elif ty.typename in handcoded:
>          raise Exception("Gen for handcoded %s" % ty.typename)
>      else:
> diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py
> index 55056c2..dfca943 100644
> --- a/tools/libxl/libxltypes.py
> +++ b/tools/libxl/libxltypes.py
> @@ -33,6 +33,8 @@ class Type(object):
>          if self.passby not in [PASS_BY_VALUE, PASS_BY_REFERENCE]:
>              raise ValueError
>  
> +        self.c_only = kwargs.setdefault('c_only', False)
> +
>          if typename is None: # Anonymous type
>              self.typename = None
>              self.rawname = None
> @@ -50,7 +52,7 @@ class Type(object):
>  
>          self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
>  
> -        if self.typename is not None:
> +        if self.typename is not None and not self.c_only:
>              self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
>          else:
>              self.json_fn = kwargs.setdefault('json_fn', None)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:28:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:28:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVKv2-00065l-K2; Tue, 29 Nov 2011 10:28:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVKv1-00065Z-4i
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:28:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322562449!6029899!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14352 invoked from network); 29 Nov 2011 10:27:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:27:29 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180155"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:27:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:27:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:27:28 +0000
In-Reply-To: <1322499580-2322-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322562449.20646.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/13] libxl: idl: support new "c_only" type
 attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> This provides for fields in libxl datatypes which are only present in
> the C version of structures.  This is useful, for example, when a
> libxl datatype wants to contain fields which are used by libxl
> internally and which are only present in the structure to avoid
> additional memory allocation inconvenience.

I think "internal" or "private" would be a better description than "c".

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/gentest.py    |    2 ++
>  tools/libxl/libxltypes.py |    4 +++-
>  2 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
> index 05e77cc..9b2812e 100644
> --- a/tools/libxl/gentest.py
> +++ b/tools/libxl/gentest.py
> @@ -56,6 +56,8 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
>          s += "%s = rand() %% 2;\n" % v
>      elif ty.typename in ["char *"]:
>          s += "%s = rand_str();\n" % v
> +    elif ty.c_only:
> +        pass
>      elif ty.typename in handcoded:
>          raise Exception("Gen for handcoded %s" % ty.typename)
>      else:
> diff --git a/tools/libxl/libxltypes.py b/tools/libxl/libxltypes.py
> index 55056c2..dfca943 100644
> --- a/tools/libxl/libxltypes.py
> +++ b/tools/libxl/libxltypes.py
> @@ -33,6 +33,8 @@ class Type(object):
>          if self.passby not in [PASS_BY_VALUE, PASS_BY_REFERENCE]:
>              raise ValueError
>  
> +        self.c_only = kwargs.setdefault('c_only', False)
> +
>          if typename is None: # Anonymous type
>              self.typename = None
>              self.rawname = None
> @@ -50,7 +52,7 @@ class Type(object):
>  
>          self.autogenerate_dispose_fn = kwargs.setdefault('autogenerate_dispose_fn', True)
>  
> -        if self.typename is not None:
> +        if self.typename is not None and not self.c_only:
>              self.json_fn = kwargs.setdefault('json_fn', self.typename + "_gen_json")
>          else:
>              self.json_fn = kwargs.setdefault('json_fn', None)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:47:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLCc-0006LA-Ab; Tue, 29 Nov 2011 10:46:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVLCa-0006L5-K5
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:46:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322563539!5097818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5596 invoked from network); 29 Nov 2011 10:45:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:45:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180734"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:45:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:45:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:45:38 +0000
In-Reply-To: <20179.47462.815671.301622@mariner.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
	<20179.47462.815671.301622@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322563538.20646.36.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
 after	statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:40 +0000, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration after statement"):
> > I think it would make sense to add to the CODING_STYLE that variable
> > declarations shouldn't be mixed with code, unless part of a macro or an
> > alloca-like construct.
> 
> I think this is a silly rule.  In my proposed commit message I
> advanced three reasons for allowing declaration after statement:
> 
> > >  * It allows variables to be more often initialised as they are
> > >    declared, thus reducing the occurrence of uninitialised variable
> > >    errors.
> > > 
> > >  * Certain alloca-like constructs (arrays allocated at runtime on the
> > >    stack) can more often be written without a spurious { } block.
> > >    Such blocks are confusing to read.
> > >
> > >  * It makes it easier to write and use macros which declare and
> > >    initialise formulaic variables and do other function setup code,
> > >    because there is no need to worry that such macros might be
> > >    incompatible with each other or have strict ordering constraints.
> 
> Of these the first two improvements would be banned by your proposed
> coding style rule.
> 
> I don't understand what the harm is in allowing declarations, with
> initialisation, freely mixed with code.

Variable declarations should either be at the top of the function or
immediately before / as part of the block which uses them. e.g. this is
unhelpful:

void a_func(void)
{
	/* a bunch of code; */

	int bar;

	/* a bunch more code not using bar */

	bar = get_me_a_bar();

	/* use bar lots */
}

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:47:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLCc-0006LA-Ab; Tue, 29 Nov 2011 10:46:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVLCa-0006L5-K5
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:46:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322563539!5097818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5596 invoked from network); 29 Nov 2011 10:45:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:45:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180734"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:45:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:45:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:45:38 +0000
In-Reply-To: <20179.47462.815671.301622@mariner.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
	<20179.47462.815671.301622@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322563538.20646.36.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
 after	statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:40 +0000, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration after statement"):
> > I think it would make sense to add to the CODING_STYLE that variable
> > declarations shouldn't be mixed with code, unless part of a macro or an
> > alloca-like construct.
> 
> I think this is a silly rule.  In my proposed commit message I
> advanced three reasons for allowing declaration after statement:
> 
> > >  * It allows variables to be more often initialised as they are
> > >    declared, thus reducing the occurrence of uninitialised variable
> > >    errors.
> > > 
> > >  * Certain alloca-like constructs (arrays allocated at runtime on the
> > >    stack) can more often be written without a spurious { } block.
> > >    Such blocks are confusing to read.
> > >
> > >  * It makes it easier to write and use macros which declare and
> > >    initialise formulaic variables and do other function setup code,
> > >    because there is no need to worry that such macros might be
> > >    incompatible with each other or have strict ordering constraints.
> 
> Of these the first two improvements would be banned by your proposed
> coding style rule.
> 
> I don't understand what the harm is in allowing declarations, with
> initialisation, freely mixed with code.

Variable declarations should either be at the top of the function or
immediately before / as part of the block which uses them. e.g. this is
unhelpful:

void a_func(void)
{
	/* a bunch of code; */

	int bar;

	/* a bunch more code not using bar */

	bar = get_me_a_bar();

	/* use bar lots */
}

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:51:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLGU-0006U3-AQ; Tue, 29 Nov 2011 10:50:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVLGS-0006Tt-QC
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:50:17 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322563778!5462907!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5399 invoked from network); 29 Nov 2011 10:49:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:49:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172158917"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:49:38 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	05:49:37 -0500
Message-ID: <4ED4B8C0.20108@citrix.com>
Date: Tue, 29 Nov 2011 10:49:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Simon Horman <horms@verge.net.au>
References: <4ED399A7.1070108@citrix.com> <CAF9A2A8.25D24%keir.xen@gmail.com>
	<20111129055139.GB3222@verge.net.au>
In-Reply-To: <20111129055139.GB3222@verge.net.au>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 29/11/11 05:51, Simon Horman wrote:
> Hi Keir, Hi Andrew,
>
> On Mon, Nov 28, 2011 at 08:42:16PM +0000, Keir Fraser wrote:
>> On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>>
>>> Hello,
>>>
>>> In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
>> The patch is by Simon Horman, cc'ed, not me.

Right.  Sorry.  I should have remembered that basing "who wrote the
patch" on a simple hg log was not a safe bet.

>>> to reduce unaligned writes, but pass the resulting pointer back to
>>> machine_crash_shutdown() which performs writes on the possibly unaligned
>>> data structure.  There are also plenty of other writes on the kexec path
>>> which are possibly or certainly unaligned.
>>>
>>> What is the reason for wanting to reduce unaligned writes?
>> The patch is solving an IA64 issue. Machine_crash_shutdown is arch specific.
>>
>>> Would a better solution be to just ensure that the crash note itself is
>>> properly aligned?
>> Could be.
> Its a while since I wrote that change, but I believe that aligning
> the crash note would resolve the problem that I observed.
>
> As Keir mentions, machine_crash_shutdown() is architecture specific
> and I am not sure that I see the ia64 version making any unaligned writes.

Fair enough.  I will see what I can do about guaranteeing that the crash
note is aligned in the first place.

Thanks,

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:51:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLGU-0006U3-AQ; Tue, 29 Nov 2011 10:50:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVLGS-0006Tt-QC
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:50:17 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322563778!5462907!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5399 invoked from network); 29 Nov 2011 10:49:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:49:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172158917"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:49:38 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	05:49:37 -0500
Message-ID: <4ED4B8C0.20108@citrix.com>
Date: Tue, 29 Nov 2011 10:49:36 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Simon Horman <horms@verge.net.au>
References: <4ED399A7.1070108@citrix.com> <CAF9A2A8.25D24%keir.xen@gmail.com>
	<20111129055139.GB3222@verge.net.au>
In-Reply-To: <20111129055139.GB3222@verge.net.au>
X-Enigmail-Version: 1.1.2
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 29/11/11 05:51, Simon Horman wrote:
> Hi Keir, Hi Andrew,
>
> On Mon, Nov 28, 2011 at 08:42:16PM +0000, Keir Fraser wrote:
>> On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>>
>>> Hello,
>>>
>>> In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
>> The patch is by Simon Horman, cc'ed, not me.

Right.  Sorry.  I should have remembered that basing "who wrote the
patch" on a simple hg log was not a safe bet.

>>> to reduce unaligned writes, but pass the resulting pointer back to
>>> machine_crash_shutdown() which performs writes on the possibly unaligned
>>> data structure.  There are also plenty of other writes on the kexec path
>>> which are possibly or certainly unaligned.
>>>
>>> What is the reason for wanting to reduce unaligned writes?
>> The patch is solving an IA64 issue. Machine_crash_shutdown is arch specific.
>>
>>> Would a better solution be to just ensure that the crash note itself is
>>> properly aligned?
>> Could be.
> Its a while since I wrote that change, but I believe that aligning
> the crash note would resolve the problem that I observed.
>
> As Keir mentions, machine_crash_shutdown() is architecture specific
> and I am not sure that I see the ia64 version making any unaligned writes.

Fair enough.  I will see what I can do about guaranteeing that the crash
note is aligned in the first place.

Thanks,

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:54:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:54:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLJP-0006cY-U6; Tue, 29 Nov 2011 10:53:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVLJO-0006cK-6c
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:53:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322563936!50396506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24875 invoked from network); 29 Nov 2011 10:52:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:52:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:52:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:52:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:52:45 +0000
In-Reply-To: <1322563538.20646.36.camel@zakaz.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
	<20179.47462.815671.301622@mariner.uk.xensource.com>
	<1322563538.20646.36.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322563965.20646.37.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
 after	statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 10:45 +0000, Ian Campbell wrote:

> Variable declarations should either be at the top of the function or
> immediately before / as part of the block which uses them. e.g. this is
> unhelpful:

This isn't an objection to the patch BTW, I'm happy with your
reasoning...

> 
> void a_func(void)
> {
> 	/* a bunch of code; */
> 
> 	int bar;
> 
> 	/* a bunch more code not using bar */
> 
> 	bar = get_me_a_bar();
> 
> 	/* use bar lots */
> }
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:54:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:54:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLJP-0006cY-U6; Tue, 29 Nov 2011 10:53:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVLJO-0006cK-6c
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:53:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322563936!50396506!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24875 invoked from network); 29 Nov 2011 10:52:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:52:16 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:52:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:52:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:52:45 +0000
In-Reply-To: <1322563538.20646.36.camel@zakaz.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
	<20179.47462.815671.301622@mariner.uk.xensource.com>
	<1322563538.20646.36.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322563965.20646.37.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
 after	statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 10:45 +0000, Ian Campbell wrote:

> Variable declarations should either be at the top of the function or
> immediately before / as part of the block which uses them. e.g. this is
> unhelpful:

This isn't an objection to the patch BTW, I'm happy with your
reasoning...

> 
> void a_func(void)
> {
> 	/* a bunch of code; */
> 
> 	int bar;
> 
> 	/* a bunch more code not using bar */
> 
> 	bar = get_me_a_bar();
> 
> 	/* use bar lots */
> }
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:54:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLKI-0006fX-Ci; Tue, 29 Nov 2011 10:54:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVLKG-0006f7-7e
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:54:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322564005!5429967!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9869 invoked from network); 29 Nov 2011 10:53:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:53:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:53:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:53:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:53:24 +0000
In-Reply-To: <1322499580-2322-8-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-8-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322564004.20646.38.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07/13] libxl: internal convenience macros
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> Provide some macros which are useful shorthands for use within libxl:
>   * GC_INIT to initialise a gc from a ctx and GC_FREE to free it
>   * CTX(gc) to give you back the ctx
>   * LIBXL_TAILQ_INSERT_SORTED for inserting things into sorted lists
> 
> These will be used by later patches.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   48 ++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 48 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index bfc74c9..950c466 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -646,6 +646,54 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
>  _hidden libxl_device_model_version
>  libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>  
> +
> +/*
> + * Convenience macros.
> + */
> +
> +
> +/*
> + * All of these assume (or define)
> + *    libxl__gc *gc;
> + * as a local variable.
> + */
> +
> +#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
> +#define GC_FREE       libxl__free_all(gc)
> +#define CTX           libxl__gc_owner(gc)
> +
> +
> +/*
> + * Inserts "elm_new" into the sorted list "head".
> + *
> + * "elm_search" must be a loop search variable of the same type as
> + * "elm_new".  "new_after_search_p" must be an expression which is
> + * true iff the element "elm_new" sorts after the element
> + * "elm_search".
> + *
> + * "search_body" can be empty, or some declaration(s) and statement(s)
> + * needed for "new_after_search_p".
> + */
> +#define LIBXL_TAILQ_INSERT_SORTED(head, entry, elm_new, elm_search,     \
> +                                  search_body, new_after_search_p)      \
> +    do {                                                                \
> +        for ((elm_search) = LIBXL_TAILQ_FIRST((head));                  \
> +             (elm_search);                                              \
> +             (elm_search) = LIBXL_TAILQ_NEXT((elm_search), entry)) {    \
> +            search_body;                                                \
> +            if (!(new_after_search_p))                                  \
> +                break;                                                  \
> +        }                                                               \
> +        /* now elm_search is either the element before which we want    \
> +         * to place elm_new, or NULL meaning we want to put elm_new at  \
> +         * the end */                                                   \
> +        if ((elm_search))                                               \
> +            LIBXL_TAILQ_INSERT_BEFORE((elm_search), (elm_new), entry);  \
> +        else                                                            \
> +            LIBXL_TAILQ_INSERT_TAIL((head), (elm_new), entry);          \
> +    } while(0)
> +
> +
>  #endif
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:54:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLKI-0006fX-Ci; Tue, 29 Nov 2011 10:54:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVLKG-0006f7-7e
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:54:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322564005!5429967!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9869 invoked from network); 29 Nov 2011 10:53:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:53:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:53:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:53:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:53:24 +0000
In-Reply-To: <1322499580-2322-8-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-8-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322564004.20646.38.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07/13] libxl: internal convenience macros
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> Provide some macros which are useful shorthands for use within libxl:
>   * GC_INIT to initialise a gc from a ctx and GC_FREE to free it
>   * CTX(gc) to give you back the ctx
>   * LIBXL_TAILQ_INSERT_SORTED for inserting things into sorted lists
> 
> These will be used by later patches.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   48 ++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 48 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index bfc74c9..950c466 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -646,6 +646,54 @@ _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
>  _hidden libxl_device_model_version
>  libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>  
> +
> +/*
> + * Convenience macros.
> + */
> +
> +
> +/*
> + * All of these assume (or define)
> + *    libxl__gc *gc;
> + * as a local variable.
> + */
> +
> +#define GC_INIT(ctx)  libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
> +#define GC_FREE       libxl__free_all(gc)
> +#define CTX           libxl__gc_owner(gc)
> +
> +
> +/*
> + * Inserts "elm_new" into the sorted list "head".
> + *
> + * "elm_search" must be a loop search variable of the same type as
> + * "elm_new".  "new_after_search_p" must be an expression which is
> + * true iff the element "elm_new" sorts after the element
> + * "elm_search".
> + *
> + * "search_body" can be empty, or some declaration(s) and statement(s)
> + * needed for "new_after_search_p".
> + */
> +#define LIBXL_TAILQ_INSERT_SORTED(head, entry, elm_new, elm_search,     \
> +                                  search_body, new_after_search_p)      \
> +    do {                                                                \
> +        for ((elm_search) = LIBXL_TAILQ_FIRST((head));                  \
> +             (elm_search);                                              \
> +             (elm_search) = LIBXL_TAILQ_NEXT((elm_search), entry)) {    \
> +            search_body;                                                \
> +            if (!(new_after_search_p))                                  \
> +                break;                                                  \
> +        }                                                               \
> +        /* now elm_search is either the element before which we want    \
> +         * to place elm_new, or NULL meaning we want to put elm_new at  \
> +         * the end */                                                   \
> +        if ((elm_search))                                               \
> +            LIBXL_TAILQ_INSERT_BEFORE((elm_search), (elm_new), entry);  \
> +        else                                                            \
> +            LIBXL_TAILQ_INSERT_TAIL((head), (elm_new), entry);          \
> +    } while(0)
> +
> +
>  #endif
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:55:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLKx-0006jK-Rd; Tue, 29 Nov 2011 10:54:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVLKw-0006iY-HO
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:54:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322564056!3514350!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22420 invoked from network); 29 Nov 2011 10:54:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:54:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180968"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:54:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:54:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:54:15 +0000
In-Reply-To: <1322499580-2322-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322564055.20646.39.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09/13] libxl: introduce lock in libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> This lock will be used to protect data structures which will be hung
> off the libxl_ctx in subsequent patches.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c          |    6 ++++++
>  tools/libxl/libxl_internal.h |   27 +++++++++++++++++++++++++++
>  2 files changed, 33 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index bc17b15..7488538 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -41,6 +41,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>  {
>      libxl_ctx *ctx;
>      struct stat stat_buf;
> +    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
>  
>      if (version != LIBXL_VERSION)
>          return ERROR_VERSION;
> @@ -54,6 +55,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      memset(ctx, 0, sizeof(libxl_ctx));
>      ctx->lg = lg;
>  
> +    /* This somewhat convoluted approach is needed because
> +     * PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is defined to be valid
> +     * only as an initialiser, not as an expression. */
> +    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
> +
>      if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
>                       "failed to stat %s", XENSTORE_PID_FILE);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index cda6fc1..41de6fd 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -23,6 +23,7 @@
>  #include <stdarg.h>
>  #include <stdlib.h>
>  #include <string.h>
> +#include <pthread.h>
>  
>  #include <xs.h>
>  #include <xenctrl.h>
> @@ -95,6 +96,18 @@ struct libxl__ctx {
>      xc_interface *xch;
>      struct xs_handle *xsh;
>  
> +    pthread_mutex_t lock; /* protects data structures hanging off the ctx */
> +      /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
> +       *
> +       * You may acquire this mutex recursively if it is convenient to
> +       * do so.  You may not acquire this lock at the same time as any
> +       * other lock.  If you need to call application code outside
> +       * libxl (ie, a callback) with this lock held then it is
> +       * necessaray to impose restrictions on the caller to maintain a
> +       * proper lock hierarchy, and these restrictions must then be
> +       * documented in the libxl public interface.
> +       */
> +
>      /* for callers who reap children willy-nilly; caller must only
>       * set this after libxl_init and before any other call - or
>       * may leave them untouched */
> @@ -668,6 +681,20 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>  #define CTX           libxl__gc_owner(gc)
>  
> 
> +/* Locking functions.  See comment for "lock" member of libxl__ctx. */
> +
> +#define CTX_LOCK do {                                   \
> +        int mutex_r = pthread_mutex_lock(&CTX->lock);   \
> +        assert(!mutex_r);                               \
> +    } while(0)
> +
> +#define CTX_UNLOCK do {                                 \
> +        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
> +        assert(!mutex_r);                               \
> +    } while(0)
> +        
> +
> +
>  /*
>   * Inserts "elm_new" into the sorted list "head".
>   *



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:55:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLKx-0006jK-Rd; Tue, 29 Nov 2011 10:54:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVLKw-0006iY-HO
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:54:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322564056!3514350!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22420 invoked from network); 29 Nov 2011 10:54:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:54:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9180968"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:54:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:54:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:54:15 +0000
In-Reply-To: <1322499580-2322-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322564055.20646.39.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09/13] libxl: introduce lock in libxl_ctx
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> This lock will be used to protect data structures which will be hung
> off the libxl_ctx in subsequent patches.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c          |    6 ++++++
>  tools/libxl/libxl_internal.h |   27 +++++++++++++++++++++++++++
>  2 files changed, 33 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index bc17b15..7488538 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -41,6 +41,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>  {
>      libxl_ctx *ctx;
>      struct stat stat_buf;
> +    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
>  
>      if (version != LIBXL_VERSION)
>          return ERROR_VERSION;
> @@ -54,6 +55,11 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      memset(ctx, 0, sizeof(libxl_ctx));
>      ctx->lg = lg;
>  
> +    /* This somewhat convoluted approach is needed because
> +     * PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is defined to be valid
> +     * only as an initialiser, not as an expression. */
> +    memcpy(&ctx->lock, &mutex_value, sizeof(ctx->lock));
> +
>      if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
>                       "failed to stat %s", XENSTORE_PID_FILE);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index cda6fc1..41de6fd 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -23,6 +23,7 @@
>  #include <stdarg.h>
>  #include <stdlib.h>
>  #include <string.h>
> +#include <pthread.h>
>  
>  #include <xs.h>
>  #include <xenctrl.h>
> @@ -95,6 +96,18 @@ struct libxl__ctx {
>      xc_interface *xch;
>      struct xs_handle *xsh;
>  
> +    pthread_mutex_t lock; /* protects data structures hanging off the ctx */
> +      /* Always use CTX_LOCK and CTX_UNLOCK to manipulate this.
> +       *
> +       * You may acquire this mutex recursively if it is convenient to
> +       * do so.  You may not acquire this lock at the same time as any
> +       * other lock.  If you need to call application code outside
> +       * libxl (ie, a callback) with this lock held then it is
> +       * necessaray to impose restrictions on the caller to maintain a
> +       * proper lock hierarchy, and these restrictions must then be
> +       * documented in the libxl public interface.
> +       */
> +
>      /* for callers who reap children willy-nilly; caller must only
>       * set this after libxl_init and before any other call - or
>       * may leave them untouched */
> @@ -668,6 +681,20 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>  #define CTX           libxl__gc_owner(gc)
>  
> 
> +/* Locking functions.  See comment for "lock" member of libxl__ctx. */
> +
> +#define CTX_LOCK do {                                   \
> +        int mutex_r = pthread_mutex_lock(&CTX->lock);   \
> +        assert(!mutex_r);                               \
> +    } while(0)
> +
> +#define CTX_UNLOCK do {                                 \
> +        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
> +        assert(!mutex_r);                               \
> +    } while(0)
> +        
> +
> +
>  /*
>   * Inserts "elm_new" into the sorted list "head".
>   *



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMr-0006vX-7c; Tue, 29 Nov 2011 10:56:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMq-0006vB-1O
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:52 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322564148!42839582!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19943 invoked from network); 29 Nov 2011 10:55:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172159513"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:18 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:18 -0500
MIME-Version: 1.0
X-Mercurial-Node: 225da1242ba979ddc8c48767d3822e0c8d274ae1
Message-ID: <225da1242ba979ddc8c4.1322564004@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:24 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 6 of 6] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563734 0
# Node ID 225da1242ba979ddc8c48767d3822e0c8d274ae1
# Parent  acc408d667e139c6b8b96e1ec51e65d159d72b67
Add code to track the address of the VM generation id buffer across a
save/restore or migrate and inject a new value.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r acc408d667e1 -r 225da1242ba9 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
@@ -301,10 +301,14 @@ unsigned long new_vm_gid(void)
 {
     uint64_t gid;
     unsigned char *buf;
+    char addr[11];
 
     buf = mem_alloc(8, 8);
     if (!buf) return 0;
 
+    sprintf(addr, "0x%lx", virt_to_phys(buf));
+    xenstore_write("data/generation-id", addr);
+
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;
 
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Tue Nov 29 10:48:54 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  uint64_t gid)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Tue Nov 29 10:48:54 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_gid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Tue Nov 29 10:48:54 2011 +0000
@@ -676,6 +676,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1386,6 +1399,33 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                unsigned int offset;
+                unsigned char *buf;
+
+                /*
+                 * Map the VM generation id buffer and inject the new value.
+                 */
+
+                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+            
+                if ( (pfn >= dinfo->p2m_size) ||
+                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                {
+                    ERROR("generation id buffer frame is bad");
+                    goto out;
+                }
+
+                mfn = ctx->p2m[pfn];
+                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                           PROT_READ | PROT_WRITE, mfn);
+                *(unsigned long long *)(buf + offset) = gid;
+                munmap(buf, PAGE_SIZE);
+
+                *vm_gid_addr = pagebuf.vm_gid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Tue Nov 29 10:48:54 2011 +0000
@@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_gid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/xenguest.h	Tue Nov 29 10:48:54 2011 +0000
@@ -57,7 +57,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr);
 
 
 /**
@@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
+ * @parm vm_gid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid, unsigned long *vm_gid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Tue Nov 29 10:48:54 2011 +0000
@@ -135,6 +135,7 @@
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r acc408d667e1 -r 225da1242ba9 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Nov 29 10:48:54 2011 +0000
@@ -108,7 +108,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -121,9 +121,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -340,16 +342,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    uint64_t gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        gid = info->u.hvm.generation_id;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -357,7 +362,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, gid, &state->vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -523,12 +528,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_gid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_gid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -566,7 +581,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r acc408d667e1 -r 225da1242ba9 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Nov 29 10:48:54 2011 +0000
@@ -199,6 +199,8 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+
+    unsigned long vm_gid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r acc408d667e1 -r 225da1242ba9 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Tue Nov 29 10:48:54 2011 +0000
@@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_gid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_gid_addr = 0;
     }
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r acc408d667e1 -r 225da1242ba9 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Tue Nov 29 10:48:54 2011 +0000
@@ -23,7 +23,8 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_gid_addr;
+    uint64_t gid;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    gid = strtoll(argv[9], NULL, 0);
+    else
+	    gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            gid, &vm_gid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_gid_addr);
 	fflush(stdout);
     }
 
diff -r acc408d667e1 -r 225da1242ba9 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/xcutils/xc_save.c	Tue Nov 29 10:48:54 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_gid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMr-0006vX-7c; Tue, 29 Nov 2011 10:56:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMq-0006vB-1O
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:52 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322564148!42839582!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19943 invoked from network); 29 Nov 2011 10:55:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:55:53 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172159513"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:18 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:18 -0500
MIME-Version: 1.0
X-Mercurial-Node: 225da1242ba979ddc8c48767d3822e0c8d274ae1
Message-ID: <225da1242ba979ddc8c4.1322564004@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:24 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 6 of 6] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563734 0
# Node ID 225da1242ba979ddc8c48767d3822e0c8d274ae1
# Parent  acc408d667e139c6b8b96e1ec51e65d159d72b67
Add code to track the address of the VM generation id buffer across a
save/restore or migrate and inject a new value.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r acc408d667e1 -r 225da1242ba9 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
@@ -301,10 +301,14 @@ unsigned long new_vm_gid(void)
 {
     uint64_t gid;
     unsigned char *buf;
+    char addr[11];
 
     buf = mem_alloc(8, 8);
     if (!buf) return 0;
 
+    sprintf(addr, "0x%lx", virt_to_phys(buf));
+    xenstore_write("data/generation-id", addr);
+
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
     *(uint64_t *)buf = gid;
 
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Tue Nov 29 10:48:54 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  uint64_t gid)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Tue Nov 29 10:48:54 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_gid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/xc_domain_restore.c	Tue Nov 29 10:48:54 2011 +0000
@@ -676,6 +676,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1386,6 +1399,33 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                unsigned int offset;
+                unsigned char *buf;
+
+                /*
+                 * Map the VM generation id buffer and inject the new value.
+                 */
+
+                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+            
+                if ( (pfn >= dinfo->p2m_size) ||
+                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                {
+                    ERROR("generation id buffer frame is bad");
+                    goto out;
+                }
+
+                mfn = ctx->p2m[pfn];
+                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                           PROT_READ | PROT_WRITE, mfn);
+                *(unsigned long long *)(buf + offset) = gid;
+                munmap(buf, PAGE_SIZE);
+
+                *vm_gid_addr = pagebuf.vm_gid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/xc_domain_save.c	Tue Nov 29 10:48:54 2011 +0000
@@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_gid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/xenguest.h	Tue Nov 29 10:48:54 2011 +0000
@@ -57,7 +57,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr);
 
 
 /**
@@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
+ * @parm vm_gid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid, unsigned long *vm_gid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r acc408d667e1 -r 225da1242ba9 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxc/xg_save_restore.h	Tue Nov 29 10:48:54 2011 +0000
@@ -135,6 +135,7 @@
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r acc408d667e1 -r 225da1242ba9 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Nov 29 10:48:54 2011 +0000
@@ -108,7 +108,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -121,9 +121,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -340,16 +342,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    uint64_t gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        gid = info->u.hvm.generation_id;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -357,7 +362,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, gid, &state->vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -523,12 +528,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_gid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_gid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -566,7 +581,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r acc408d667e1 -r 225da1242ba9 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Nov 29 10:48:54 2011 +0000
@@ -199,6 +199,8 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+
+    unsigned long vm_gid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r acc408d667e1 -r 225da1242ba9 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Tue Nov 29 10:48:54 2011 +0000
@@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_gid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_gid_addr = 0;
     }
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r acc408d667e1 -r 225da1242ba9 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/xcutils/xc_restore.c	Tue Nov 29 10:48:54 2011 +0000
@@ -23,7 +23,8 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_gid_addr;
+    uint64_t gid;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    gid = strtoll(argv[9], NULL, 0);
+    else
+	    gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            gid, &vm_gid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_gid_addr);
 	fflush(stdout);
     }
 
diff -r acc408d667e1 -r 225da1242ba9 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/xcutils/xc_save.c	Tue Nov 29 10:48:54 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_gid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMs-0006w9-S3; Tue, 29 Nov 2011 10:56:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMr-0006ue-FD
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:53 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322564148!42839582!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19623 invoked from network); 29 Nov 2011 10:55:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:55:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172159506"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:15 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:15 -0500
MIME-Version: 1.0
X-Mercurial-Node: ec35c9c5a0c053532de953f59f7c8f28ba69167a
Message-ID: <ec35c9c5a0c053532de9.1322564000@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:20 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 6] Add 'ctype' infrastructure to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563734 0
# Node ID ec35c9c5a0c053532de953f59f7c8f28ba69167a
# Parent  ac68bd6d4853fdde5a24d78a7d0f1cee69f5416e
Add 'ctype' infrastructure to hvmloader.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r ac68bd6d4853 -r ec35c9c5a0c0 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile	Tue Nov 29 10:48:53 2011 +0000
+++ b/tools/firmware/hvmloader/Makefile	Tue Nov 29 10:48:54 2011 +0000
@@ -30,7 +30,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
 OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
-OBJS += e820.o pci.o pir.o
+OBJS += e820.o pci.o pir.o ctype.o
 ifeq ($(debug),y)
 OBJS += tests.o
 endif
diff -r ac68bd6d4853 -r ec35c9c5a0c0 tools/firmware/hvmloader/ctype.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/ctype.c	Tue Nov 29 10:48:54 2011 +0000
@@ -0,0 +1,27 @@
+#include "ctype.h"
+
+const unsigned char _ctype[] = {
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 0-7 */
+_C,_C|_S,_C|_S,_C|_S,_C|_S,_C|_S,_C,_C,         /* 8-15 */
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 16-23 */
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 24-31 */
+_S|_SP,_P,_P,_P,_P,_P,_P,_P,                    /* 32-39 */
+_P,_P,_P,_P,_P,_P,_P,_P,                        /* 40-47 */
+_D,_D,_D,_D,_D,_D,_D,_D,                        /* 48-55 */
+_D,_D,_P,_P,_P,_P,_P,_P,                        /* 56-63 */
+_P,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U,      /* 64-71 */
+_U,_U,_U,_U,_U,_U,_U,_U,                        /* 72-79 */
+_U,_U,_U,_U,_U,_U,_U,_U,                        /* 80-87 */
+_U,_U,_U,_P,_P,_P,_P,_P,                        /* 88-95 */
+_P,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L,      /* 96-103 */
+_L,_L,_L,_L,_L,_L,_L,_L,                        /* 104-111 */
+_L,_L,_L,_L,_L,_L,_L,_L,                        /* 112-119 */
+_L,_L,_L,_P,_P,_P,_P,_C,                        /* 120-127 */
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 128-143 */
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 144-159 */
+_S|_SP,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,   /* 160-175 */
+_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,       /* 176-191 */
+_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,       /* 192-207 */
+_U,_U,_U,_U,_U,_U,_U,_P,_U,_U,_U,_U,_U,_U,_U,_L,       /* 208-223 */
+_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,       /* 224-239 */
+_L,_L,_L,_L,_L,_L,_L,_P,_L,_L,_L,_L,_L,_L,_L,_L};      /* 240-255 */
diff -r ac68bd6d4853 -r ec35c9c5a0c0 tools/firmware/hvmloader/ctype.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/ctype.h	Tue Nov 29 10:48:54 2011 +0000
@@ -0,0 +1,30 @@
+#ifndef __HVMLOADER_CTYPE_H__
+#define __HVMLOADER_CTYPE_H__
+
+#define _U	0x01	/* upper */
+#define _L	0x02	/* lower */
+#define _D	0x04	/* digit */
+#define _C	0x08	/* cntrl */
+#define _P	0x10	/* punct */
+#define _S	0x20	/* white space (space/lf/tab) */
+#define _X	0x40	/* hex digit */
+#define _SP	0x80	/* hard space (0x20) */
+
+extern const unsigned char _ctype[];
+
+#define __ismask(x) (_ctype[(int)(unsigned char)(x)])
+
+#define isalnum(c)	((__ismask(c)&(_U|_L|_D)) != 0)
+#define isalpha(c)	((__ismask(c)&(_U|_L)) != 0)
+#define iscntrl(c)	((__ismask(c)&(_C)) != 0)
+#define isdigit(c)	((__ismask(c)&(_D)) != 0)
+#define isgraph(c)	((__ismask(c)&(_P|_U|_L|_D)) != 0)
+#define islower(c)	((__ismask(c)&(_L)) != 0)
+#define isprint(c)	((__ismask(c)&(_P|_U|_L|_D|_SP)) != 0)
+#define ispunct(c)	((__ismask(c)&(_P)) != 0)
+#define isspace(c)	((__ismask(c)&(_S)) != 0)
+#define isupper(c)	((__ismask(c)&(_U)) != 0)
+#define isxdigit(c)	((__ismask(c)&(_D|_X)) != 0)
+
+#endif /* __HVMLOADER_CTYPE_H__ */
+
diff -r ac68bd6d4853 -r ec35c9c5a0c0 tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:53 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
@@ -21,6 +21,7 @@
 #include "util.h"
 #include "config.h"
 #include "hypercall.h"
+#include "ctype.h"
 #include <stdint.h>
 #include <xen/xen.h>
 #include <xen/memory.h>
diff -r ac68bd6d4853 -r ec35c9c5a0c0 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:53 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
@@ -225,8 +225,6 @@ void perform_tests(void);
 #define perform_tests() ((void)0)
 #endif
 
-#define isdigit(c) ((c) >= '0' && (c) <= '9')
-
 extern char _start[], _end[];
 
 #endif /* __HVMLOADER_UTIL_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMs-0006w9-S3; Tue, 29 Nov 2011 10:56:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMr-0006ue-FD
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:53 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322564148!42839582!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19623 invoked from network); 29 Nov 2011 10:55:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:55:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172159506"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:15 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:15 -0500
MIME-Version: 1.0
X-Mercurial-Node: ec35c9c5a0c053532de953f59f7c8f28ba69167a
Message-ID: <ec35c9c5a0c053532de9.1322564000@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:20 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 2 of 6] Add 'ctype' infrastructure to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563734 0
# Node ID ec35c9c5a0c053532de953f59f7c8f28ba69167a
# Parent  ac68bd6d4853fdde5a24d78a7d0f1cee69f5416e
Add 'ctype' infrastructure to hvmloader.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r ac68bd6d4853 -r ec35c9c5a0c0 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile	Tue Nov 29 10:48:53 2011 +0000
+++ b/tools/firmware/hvmloader/Makefile	Tue Nov 29 10:48:54 2011 +0000
@@ -30,7 +30,7 @@ CFLAGS += $(CFLAGS_xeninclude)
 
 OBJS  = hvmloader.o mp_tables.o util.o smbios.o 
 OBJS += 32bitbios_support.o smp.o cacheattr.o xenbus.o
-OBJS += e820.o pci.o pir.o
+OBJS += e820.o pci.o pir.o ctype.o
 ifeq ($(debug),y)
 OBJS += tests.o
 endif
diff -r ac68bd6d4853 -r ec35c9c5a0c0 tools/firmware/hvmloader/ctype.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/ctype.c	Tue Nov 29 10:48:54 2011 +0000
@@ -0,0 +1,27 @@
+#include "ctype.h"
+
+const unsigned char _ctype[] = {
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 0-7 */
+_C,_C|_S,_C|_S,_C|_S,_C|_S,_C|_S,_C,_C,         /* 8-15 */
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 16-23 */
+_C,_C,_C,_C,_C,_C,_C,_C,                        /* 24-31 */
+_S|_SP,_P,_P,_P,_P,_P,_P,_P,                    /* 32-39 */
+_P,_P,_P,_P,_P,_P,_P,_P,                        /* 40-47 */
+_D,_D,_D,_D,_D,_D,_D,_D,                        /* 48-55 */
+_D,_D,_P,_P,_P,_P,_P,_P,                        /* 56-63 */
+_P,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U|_X,_U,      /* 64-71 */
+_U,_U,_U,_U,_U,_U,_U,_U,                        /* 72-79 */
+_U,_U,_U,_U,_U,_U,_U,_U,                        /* 80-87 */
+_U,_U,_U,_P,_P,_P,_P,_P,                        /* 88-95 */
+_P,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L|_X,_L,      /* 96-103 */
+_L,_L,_L,_L,_L,_L,_L,_L,                        /* 104-111 */
+_L,_L,_L,_L,_L,_L,_L,_L,                        /* 112-119 */
+_L,_L,_L,_P,_P,_P,_P,_C,                        /* 120-127 */
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 128-143 */
+0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,                /* 144-159 */
+_S|_SP,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,   /* 160-175 */
+_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,_P,       /* 176-191 */
+_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,_U,       /* 192-207 */
+_U,_U,_U,_U,_U,_U,_U,_P,_U,_U,_U,_U,_U,_U,_U,_L,       /* 208-223 */
+_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,_L,       /* 224-239 */
+_L,_L,_L,_L,_L,_L,_L,_P,_L,_L,_L,_L,_L,_L,_L,_L};      /* 240-255 */
diff -r ac68bd6d4853 -r ec35c9c5a0c0 tools/firmware/hvmloader/ctype.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/firmware/hvmloader/ctype.h	Tue Nov 29 10:48:54 2011 +0000
@@ -0,0 +1,30 @@
+#ifndef __HVMLOADER_CTYPE_H__
+#define __HVMLOADER_CTYPE_H__
+
+#define _U	0x01	/* upper */
+#define _L	0x02	/* lower */
+#define _D	0x04	/* digit */
+#define _C	0x08	/* cntrl */
+#define _P	0x10	/* punct */
+#define _S	0x20	/* white space (space/lf/tab) */
+#define _X	0x40	/* hex digit */
+#define _SP	0x80	/* hard space (0x20) */
+
+extern const unsigned char _ctype[];
+
+#define __ismask(x) (_ctype[(int)(unsigned char)(x)])
+
+#define isalnum(c)	((__ismask(c)&(_U|_L|_D)) != 0)
+#define isalpha(c)	((__ismask(c)&(_U|_L)) != 0)
+#define iscntrl(c)	((__ismask(c)&(_C)) != 0)
+#define isdigit(c)	((__ismask(c)&(_D)) != 0)
+#define isgraph(c)	((__ismask(c)&(_P|_U|_L|_D)) != 0)
+#define islower(c)	((__ismask(c)&(_L)) != 0)
+#define isprint(c)	((__ismask(c)&(_P|_U|_L|_D|_SP)) != 0)
+#define ispunct(c)	((__ismask(c)&(_P)) != 0)
+#define isspace(c)	((__ismask(c)&(_S)) != 0)
+#define isupper(c)	((__ismask(c)&(_U)) != 0)
+#define isxdigit(c)	((__ismask(c)&(_D|_X)) != 0)
+
+#endif /* __HVMLOADER_CTYPE_H__ */
+
diff -r ac68bd6d4853 -r ec35c9c5a0c0 tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:53 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
@@ -21,6 +21,7 @@
 #include "util.h"
 #include "config.h"
 #include "hypercall.h"
+#include "ctype.h"
 #include <stdint.h>
 #include <xen/xen.h>
 #include <xen/memory.h>
diff -r ac68bd6d4853 -r ec35c9c5a0c0 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:53 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
@@ -225,8 +225,6 @@ void perform_tests(void);
 #define perform_tests() ((void)0)
 #endif
 
-#define isdigit(c) ((c) >= '0' && (c) <= '9')
-
 extern char _start[], _end[];
 
 #endif /* __HVMLOADER_UTIL_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMn-0006up-Cl; Tue, 29 Nov 2011 10:56:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMl-0006uX-Vt
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:48 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322564148!42839582!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19585 invoked from network); 29 Nov 2011 10:55:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:55:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172159505"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:14 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:14 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:18 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 6] Add support for a VM generation ID
	virtual device (v2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The following is a revised patch series to add support for a
VM generation ID virtual device for HVM guests.
The basic requirements of this device are as follows:

- It must be exposed somewhere in ACPI namespace with a _CID of
  "VM_Gen_Counter".
- It must also include a _DDN of "VM_Gen_Counter".
- It must contain a _HID object but no particular value is
  required.
- It must expose a package called ADDR which evaluates to two
  integers; the first being the low order 32-bits of a guest
  physical address (GPA), the second by the high order 32-bits of
  the GPA. This GPA is the address of an 8-byte aligned 8-byte
  buffer containing the VM generation ID.
  This buffer must not be in ranges supported as AddressRangeMemory
  or AddressRangeACPI and must not be mapped by any PTE with caching
  disabled.

The semantics of the VM generation ID itself are left up to the tools
but it must be possible to change it each time the VM is booted,
migrated, or restored from a saved image.

Patch 1 adds the device and an acpi_info field to allow population
of the ADDR package.
Patch 2 adds ctype infrastructure to hvloader in preparation for...
Patch 3 adds all the code to plumb the value of a new 'generation_id'
parameter in the VM config through to the VM generation id buffer at
VM boot time.
Patch 4 adds an implementation of sprintf() to hvmloader.
Patch 5 adds an implementation of xenstore-write to hvmloader.
Patch 6 adds support for tracking the address of the VM generation id
buffer (via xenstore) across save/restore or migrate and updating the
value of the buffer with the value from the VM config file.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMn-0006up-Cl; Tue, 29 Nov 2011 10:56:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMl-0006uX-Vt
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:48 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322564148!42839582!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19585 invoked from network); 29 Nov 2011 10:55:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:55:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172159505"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:14 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:14 -0500
MIME-Version: 1.0
Message-ID: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:18 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 0 of 6] Add support for a VM generation ID
	virtual device (v2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The following is a revised patch series to add support for a
VM generation ID virtual device for HVM guests.
The basic requirements of this device are as follows:

- It must be exposed somewhere in ACPI namespace with a _CID of
  "VM_Gen_Counter".
- It must also include a _DDN of "VM_Gen_Counter".
- It must contain a _HID object but no particular value is
  required.
- It must expose a package called ADDR which evaluates to two
  integers; the first being the low order 32-bits of a guest
  physical address (GPA), the second by the high order 32-bits of
  the GPA. This GPA is the address of an 8-byte aligned 8-byte
  buffer containing the VM generation ID.
  This buffer must not be in ranges supported as AddressRangeMemory
  or AddressRangeACPI and must not be mapped by any PTE with caching
  disabled.

The semantics of the VM generation ID itself are left up to the tools
but it must be possible to change it each time the VM is booted,
migrated, or restored from a saved image.

Patch 1 adds the device and an acpi_info field to allow population
of the ADDR package.
Patch 2 adds ctype infrastructure to hvloader in preparation for...
Patch 3 adds all the code to plumb the value of a new 'generation_id'
parameter in the VM config through to the VM generation id buffer at
VM boot time.
Patch 4 adds an implementation of sprintf() to hvmloader.
Patch 5 adds an implementation of xenstore-write to hvmloader.
Patch 6 adds support for tracking the address of the VM generation id
buffer (via xenstore) across save/restore or migrate and updating the
value of the buffer with the value from the VM config file.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMz-0006ya-8S; Tue, 29 Nov 2011 10:57:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMx-0006w0-9D
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:59 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322564178!6792868!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24999 invoked from network); 29 Nov 2011 10:56:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:56:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="19482743"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:18 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:17 -0500
MIME-Version: 1.0
X-Mercurial-Node: acc408d667e139c6b8b96e1ec51e65d159d72b67
Message-ID: <acc408d667e139c6b8b9.1322564003@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:23 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 5 of 6] Add xenstore-write support to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563734 0
# Node ID acc408d667e139c6b8b96e1ec51e65d159d72b67
# Parent  e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
Add xenstore-write support to hvmloader.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r e9997777ab6d -r acc408d667e1 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
@@ -202,6 +202,11 @@ void xenbus_shutdown(void);
  */
 const char *xenstore_read(const char *path, const char *default_resp);
 
+/* Write a xenstore key.  @value must be a nul-terminated string. Returns
+ * zero on success or a xenstore error code on failure.
+ */
+int xenstore_write(const char *path, const char *value);
+
 /* Setup PCI bus */
 void pci_setup(void);
 
diff -r e9997777ab6d -r acc408d667e1 tools/firmware/hvmloader/xenbus.c
--- a/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 10:48:54 2011 +0000
@@ -143,17 +143,19 @@ static void ring_read(char *data, uint32
     }
 }
 
+#define MAX_SEGMENTS    3
 
-/* Send a request and wait for the answer.
- * Returns 0 for success, or an errno for error.
- * The answer is returned in a static buffer which is only
- * valid until the next call of xenbus_send(). */
-static int xenbus_send(uint32_t type, uint32_t len, const char *data,
-                       uint32_t *reply_len, const char **reply_data)
+/* Send a request. */
+static void xenbus_send(uint32_t type, ...)
 {
     struct xsd_sockmsg hdr;
+    va_list ap;
+    struct {
+        const char *data;
+        uint32_t len;
+    } seg[MAX_SEGMENTS];
     evtchn_send_t send;
-    int i;
+    int i, n;
 
     /* Not acceptable to use xenbus before setting it up */
     ASSERT(rings != NULL);
@@ -162,16 +164,37 @@ static int xenbus_send(uint32_t type, ui
     hdr.type = type;
     hdr.req_id = 0;  /* We only ever issue one request at a time */
     hdr.tx_id = 0;   /* We never use transactions */
-    hdr.len = len;
+    hdr.len = 0;
+
+    va_start(ap, type);
+    for ( i = 0; ; i++ ) {
+        seg[i].data = va_arg(ap, const char *);
+        seg[i].len = va_arg(ap, uint32_t);
+
+        if ( seg[i].data == NULL )
+            break;
+
+        hdr.len += seg[i].len;
+    }
+    n = i;
+    va_end(ap);
+
     ring_write((char *) &hdr, sizeof hdr);
-    ring_write(data, len);
+    for ( i = 0; i < n; i++ )
+        ring_write(seg[i].data, seg[i].len);
 
     /* Tell the other end about the request */
     send.port = event;
     hypercall_event_channel_op(EVTCHNOP_send, &send);
+}
 
-    /* Properly we should poll the event channel now but that involves
-     * mapping the shared-info page and handling the bitmaps. */
+/* Wait for the answer to a previous request.
+ * Returns 0 for success, or an errno for error.
+ * The answer is returned in a static buffer which is only
+ * valid until the next call of xenbus_send(). */
+static int xenbus_recv(uint32_t *reply_len, const char **reply_data)
+{
+    struct xsd_sockmsg hdr;
 
     /* Pull the reply off the ring */
     ring_read((char *) &hdr, sizeof(hdr));
@@ -182,6 +205,8 @@ static int xenbus_send(uint32_t type, ui
     /* Handle errors */
     if ( hdr.type == XS_ERROR )
     {
+        int i;
+
         *reply_len = 0;
         for ( i = 0; i < ((sizeof xsd_errors) / (sizeof xsd_errors[0])); i++ )
             if ( !strcmp(xsd_errors[i].errstring, payload) )
@@ -190,8 +215,10 @@ static int xenbus_send(uint32_t type, ui
         return EIO;
     }
 
-    *reply_data = payload;
-    *reply_len = hdr.len;
+    if ( reply_data )
+        *reply_data = payload;
+    if ( reply_len )
+        *reply_len = hdr.len;
     return 0;
 }
 
@@ -207,17 +234,34 @@ const char *xenstore_read(const char *pa
     uint32_t len = 0;
     const char *answer = NULL;
 
-    /* Include the nul in the request */
-    if ( xenbus_send(XS_READ, strlen(path) + 1, path, &len, &answer) )
+    xenbus_send(XS_READ,
+                path, strlen(path),
+                "", 1, /* nul separator */
+                NULL, 0);
+
+    if ( xenbus_recv(&len, &answer) )
         answer = NULL;
 
     if ( (default_resp != NULL) && ((answer == NULL) || (*answer == '\0')) )
         answer = default_resp;
 
-    /* We know xenbus_send() nul-terminates its answer, so just pass it on. */
+    /* We know xenbus_recv() nul-terminates its answer, so just pass it on. */
     return answer;
 }
 
+/* Write a xenstore key.  @value must be a nul-terminated string. Returns
+ * zero on success or a xenstore error code on failure.
+ */
+int xenstore_write(const char *path, const char *value)
+{
+    xenbus_send(XS_WRITE,
+                path, strlen(path),
+                "", 1, /* nul separator */
+                value, strlen(value),
+                NULL, 0);
+
+    return ( xenbus_recv(NULL, NULL) );
+}
 
 /*
  * Local variables:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMz-0006ya-8S; Tue, 29 Nov 2011 10:57:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMx-0006w0-9D
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:59 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322564178!6792868!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24999 invoked from network); 29 Nov 2011 10:56:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:56:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="19482743"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:18 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:17 -0500
MIME-Version: 1.0
X-Mercurial-Node: acc408d667e139c6b8b96e1ec51e65d159d72b67
Message-ID: <acc408d667e139c6b8b9.1322564003@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:23 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 5 of 6] Add xenstore-write support to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563734 0
# Node ID acc408d667e139c6b8b96e1ec51e65d159d72b67
# Parent  e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
Add xenstore-write support to hvmloader.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r e9997777ab6d -r acc408d667e1 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
@@ -202,6 +202,11 @@ void xenbus_shutdown(void);
  */
 const char *xenstore_read(const char *path, const char *default_resp);
 
+/* Write a xenstore key.  @value must be a nul-terminated string. Returns
+ * zero on success or a xenstore error code on failure.
+ */
+int xenstore_write(const char *path, const char *value);
+
 /* Setup PCI bus */
 void pci_setup(void);
 
diff -r e9997777ab6d -r acc408d667e1 tools/firmware/hvmloader/xenbus.c
--- a/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 10:48:54 2011 +0000
@@ -143,17 +143,19 @@ static void ring_read(char *data, uint32
     }
 }
 
+#define MAX_SEGMENTS    3
 
-/* Send a request and wait for the answer.
- * Returns 0 for success, or an errno for error.
- * The answer is returned in a static buffer which is only
- * valid until the next call of xenbus_send(). */
-static int xenbus_send(uint32_t type, uint32_t len, const char *data,
-                       uint32_t *reply_len, const char **reply_data)
+/* Send a request. */
+static void xenbus_send(uint32_t type, ...)
 {
     struct xsd_sockmsg hdr;
+    va_list ap;
+    struct {
+        const char *data;
+        uint32_t len;
+    } seg[MAX_SEGMENTS];
     evtchn_send_t send;
-    int i;
+    int i, n;
 
     /* Not acceptable to use xenbus before setting it up */
     ASSERT(rings != NULL);
@@ -162,16 +164,37 @@ static int xenbus_send(uint32_t type, ui
     hdr.type = type;
     hdr.req_id = 0;  /* We only ever issue one request at a time */
     hdr.tx_id = 0;   /* We never use transactions */
-    hdr.len = len;
+    hdr.len = 0;
+
+    va_start(ap, type);
+    for ( i = 0; ; i++ ) {
+        seg[i].data = va_arg(ap, const char *);
+        seg[i].len = va_arg(ap, uint32_t);
+
+        if ( seg[i].data == NULL )
+            break;
+
+        hdr.len += seg[i].len;
+    }
+    n = i;
+    va_end(ap);
+
     ring_write((char *) &hdr, sizeof hdr);
-    ring_write(data, len);
+    for ( i = 0; i < n; i++ )
+        ring_write(seg[i].data, seg[i].len);
 
     /* Tell the other end about the request */
     send.port = event;
     hypercall_event_channel_op(EVTCHNOP_send, &send);
+}
 
-    /* Properly we should poll the event channel now but that involves
-     * mapping the shared-info page and handling the bitmaps. */
+/* Wait for the answer to a previous request.
+ * Returns 0 for success, or an errno for error.
+ * The answer is returned in a static buffer which is only
+ * valid until the next call of xenbus_send(). */
+static int xenbus_recv(uint32_t *reply_len, const char **reply_data)
+{
+    struct xsd_sockmsg hdr;
 
     /* Pull the reply off the ring */
     ring_read((char *) &hdr, sizeof(hdr));
@@ -182,6 +205,8 @@ static int xenbus_send(uint32_t type, ui
     /* Handle errors */
     if ( hdr.type == XS_ERROR )
     {
+        int i;
+
         *reply_len = 0;
         for ( i = 0; i < ((sizeof xsd_errors) / (sizeof xsd_errors[0])); i++ )
             if ( !strcmp(xsd_errors[i].errstring, payload) )
@@ -190,8 +215,10 @@ static int xenbus_send(uint32_t type, ui
         return EIO;
     }
 
-    *reply_data = payload;
-    *reply_len = hdr.len;
+    if ( reply_data )
+        *reply_data = payload;
+    if ( reply_len )
+        *reply_len = hdr.len;
     return 0;
 }
 
@@ -207,17 +234,34 @@ const char *xenstore_read(const char *pa
     uint32_t len = 0;
     const char *answer = NULL;
 
-    /* Include the nul in the request */
-    if ( xenbus_send(XS_READ, strlen(path) + 1, path, &len, &answer) )
+    xenbus_send(XS_READ,
+                path, strlen(path),
+                "", 1, /* nul separator */
+                NULL, 0);
+
+    if ( xenbus_recv(&len, &answer) )
         answer = NULL;
 
     if ( (default_resp != NULL) && ((answer == NULL) || (*answer == '\0')) )
         answer = default_resp;
 
-    /* We know xenbus_send() nul-terminates its answer, so just pass it on. */
+    /* We know xenbus_recv() nul-terminates its answer, so just pass it on. */
     return answer;
 }
 
+/* Write a xenstore key.  @value must be a nul-terminated string. Returns
+ * zero on success or a xenstore error code on failure.
+ */
+int xenstore_write(const char *path, const char *value)
+{
+    xenbus_send(XS_WRITE,
+                path, strlen(path),
+                "", 1, /* nul separator */
+                value, strlen(value),
+                NULL, 0);
+
+    return ( xenbus_recv(NULL, NULL) );
+}
 
 /*
  * Local variables:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMx-0006xS-9S; Tue, 29 Nov 2011 10:56:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMw-0006vT-7q
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322564178!6792868!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24941 invoked from network); 29 Nov 2011 10:56:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:56:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="19482741"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:14 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:14 -0500
MIME-Version: 1.0
X-Mercurial-Node: ac68bd6d4853fdde5a24d78a7d0f1cee69f5416e
Message-ID: <ac68bd6d4853fdde5a24.1322563999@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:19 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a package
 called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563733 0
# Node ID ac68bd6d4853fdde5a24d78a7d0f1cee69f5416e
# Parent  a9c67c2daf4b0181ef2581471ea920eecb495616
Add an ACPI device exposing a package called ADDR, evaluating to two
integers, and with _CID and _DDN set to "VM_Gen_Counter".

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r a9c67c2daf4b -r ac68bd6d4853 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:53 2011 +0000
@@ -47,6 +47,7 @@ struct acpi_info {
     uint32_t pci_min, pci_len;  /* 4, 8 - PCI I/O hole boundaries */
     uint32_t madt_csum_addr;    /* 12   - Address of MADT checksum */
     uint32_t madt_lapic0_addr;  /* 16   - Address of first MADT LAPIC struct */
+    uint32_t vm_gid_addr;       /* 20   - Address of VM generation id buffer */
 };
 
 /* Number of processor objects in the chosen DSDT. */
diff -r a9c67c2daf4b -r ac68bd6d4853 tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Tue Nov 29 10:48:53 2011 +0000
@@ -55,7 +55,8 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
            PMIN, 32,
            PLEN, 32,
            MSUA, 32, /* MADT checksum address */
-           MAPA, 32  /* MADT LAPIC0 address */
+           MAPA, 32, /* MADT LAPIC0 address */
+           VGIA, 32  /* VM generation id address */
        }
 
         /* Fix HCT test for 0x400 pci memory:
@@ -396,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
                         IRQNoFlags () {7}
                     })
                 } 
+
+                Device(VGID) {
+                    Name(_HID, "ACPI0001")
+                    Name(_UID, 0x00)
+                    Name(_CID, "VM_Gen_Counter")
+                    Name(_DDN, "VM_Gen_Counter")
+                    Method(_STA, 0, NotSerialized)
+                    {
+                        If(LEqual(\_SB.VGIA, 0x00000000)) {
+                            Return(0x00)
+                        } Else {
+                            Return(0x0F)
+                        }
+                    }
+                    Name(PKG, Package ()
+                    {
+                        0x00000000,
+                        0x00000000
+                    })
+                    Method(ADDR, 0, NotSerialized)
+                    {
+                        Store(\_SB.VGIA, Index(PKG, 0))
+                        Return(PKG)
+                    }
+                }
             }
         }
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMx-0006xS-9S; Tue, 29 Nov 2011 10:56:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMw-0006vT-7q
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322564178!6792868!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24941 invoked from network); 29 Nov 2011 10:56:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:56:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="19482741"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:14 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:14 -0500
MIME-Version: 1.0
X-Mercurial-Node: ac68bd6d4853fdde5a24d78a7d0f1cee69f5416e
Message-ID: <ac68bd6d4853fdde5a24.1322563999@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:19 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a package
 called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563733 0
# Node ID ac68bd6d4853fdde5a24d78a7d0f1cee69f5416e
# Parent  a9c67c2daf4b0181ef2581471ea920eecb495616
Add an ACPI device exposing a package called ADDR, evaluating to two
integers, and with _CID and _DDN set to "VM_Gen_Counter".

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r a9c67c2daf4b -r ac68bd6d4853 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:53 2011 +0000
@@ -47,6 +47,7 @@ struct acpi_info {
     uint32_t pci_min, pci_len;  /* 4, 8 - PCI I/O hole boundaries */
     uint32_t madt_csum_addr;    /* 12   - Address of MADT checksum */
     uint32_t madt_lapic0_addr;  /* 16   - Address of first MADT LAPIC struct */
+    uint32_t vm_gid_addr;       /* 20   - Address of VM generation id buffer */
 };
 
 /* Number of processor objects in the chosen DSDT. */
diff -r a9c67c2daf4b -r ac68bd6d4853 tools/firmware/hvmloader/acpi/dsdt.asl
--- a/tools/firmware/hvmloader/acpi/dsdt.asl	Mon Nov 28 11:57:23 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Tue Nov 29 10:48:53 2011 +0000
@@ -55,7 +55,8 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
            PMIN, 32,
            PLEN, 32,
            MSUA, 32, /* MADT checksum address */
-           MAPA, 32  /* MADT LAPIC0 address */
+           MAPA, 32, /* MADT LAPIC0 address */
+           VGIA, 32  /* VM generation id address */
        }
 
         /* Fix HCT test for 0x400 pci memory:
@@ -396,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, 
                         IRQNoFlags () {7}
                     })
                 } 
+
+                Device(VGID) {
+                    Name(_HID, "ACPI0001")
+                    Name(_UID, 0x00)
+                    Name(_CID, "VM_Gen_Counter")
+                    Name(_DDN, "VM_Gen_Counter")
+                    Method(_STA, 0, NotSerialized)
+                    {
+                        If(LEqual(\_SB.VGIA, 0x00000000)) {
+                            Return(0x00)
+                        } Else {
+                            Return(0x0F)
+                        }
+                    }
+                    Name(PKG, Package ()
+                    {
+                        0x00000000,
+                        0x00000000
+                    })
+                    Method(ADDR, 0, NotSerialized)
+                    {
+                        Store(\_SB.VGIA, Index(PKG, 0))
+                        Return(PKG)
+                    }
+                }
             }
         }
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMx-0006xn-PS; Tue, 29 Nov 2011 10:56:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMw-0006vZ-Ki
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322564178!6792868!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24960 invoked from network); 29 Nov 2011 10:56:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:56:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="19482742"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:16 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:16 -0500
MIME-Version: 1.0
X-Mercurial-Node: 58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
Message-ID: <58cdfa17fb8801ab0a9e.1322564001@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:21 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 6] Allocate an 8 byte buffer to contain the
 VM generation id and populate it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563734 0
# Node ID 58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
# Parent  ec35c9c5a0c053532de953f59f7c8f28ba69167a
Allocate an 8 byte buffer to contain the VM generation id and populate it
at boot time with a value read from "platform/generation_id". Also add
code to libxl to populate this xenstore key with the value of a new
'generation_id' parameter in the VM config file.
Populate the ADDR package of VM_Gen_Counter ACPI device such that the first
integer evaluates to the low order 32 bits of the buffer address and the
second integer evaluates to the high order 32 bits of the buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
@@ -297,6 +297,20 @@ static int construct_secondary_tables(un
     return nr_tables;
 }
 
+unsigned long new_vm_gid(void)
+{
+    uint64_t gid;
+    unsigned char *buf;
+
+    buf = mem_alloc(8, 8);
+    if (!buf) return 0;
+
+    gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
+    *(uint64_t *)buf = gid;
+
+    return virt_to_phys(buf);    
+}
+
 void acpi_build_tables(struct acpi_config *config, unsigned int physical)
 {
     struct acpi_info *acpi_info;
@@ -309,6 +323,7 @@ void acpi_build_tables(struct acpi_confi
     unsigned char       *dsdt;
     unsigned long        secondary_tables[16];
     int                  nr_secondaries, i;
+    unsigned long        vm_gid_addr;
 
     /* Allocate and initialise the acpi info area. */
     mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
@@ -421,12 +436,16 @@ void acpi_build_tables(struct acpi_confi
                  offsetof(struct acpi_20_rsdp, extended_checksum),
                  sizeof(struct acpi_20_rsdp));
 
+    vm_gid_addr = new_vm_gid();
+    if (!vm_gid_addr) goto oom;
+
     acpi_info->com1_present = uart_exists(0x3f8);
     acpi_info->com2_present = uart_exists(0x2f8);
     acpi_info->lpt1_present = lpt_exists(0x378);
     acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
     acpi_info->pci_min = pci_mem_start;
     acpi_info->pci_len = pci_mem_end - pci_mem_start;
+    acpi_info->vm_gid_addr = vm_gid_addr;
 
     return;
 
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
@@ -205,6 +205,78 @@ strlen(const char *s)
     return i;
 }
 
+static inline int __digit(char c, int base)
+{
+    int d = -1;
+
+    if ( (c >= '0') && (c <= '9') )
+        d = c - '0';
+
+    if ( (c >= 'A') && (c <= 'Z') )
+        d = c - 'A' + 10;
+
+    if ( (c >= 'a') && (c <= 'z') )
+        d = c - 'a' + 10;
+
+    if (d >= base)
+        d = -1;
+
+    return d;
+}
+
+long long
+strtoll(const char *s, char **end, int base)
+{
+    long long v = 0;
+    int sign = 1;
+
+    while ( (*s != '\0') && isspace(*s) )
+        s++;
+
+    if ( *s == '\0' ) goto out;
+
+    if ( *s == '-' ) {
+        sign = -1;
+        s++;
+    } else {
+        if ( *s == '+' )
+            s++;
+    }
+
+    if ( *s == '\0' ) goto out;
+
+    if ( *s == '0' ) {
+        s++;
+        if ( *s == '\0' ) goto out;
+
+        if ( *s == 'x' ) {
+            if ( base != 0 && base != 16) goto out;
+            base = 16;
+            s++;
+        } else {
+            if ( base != 0 && base != 8) goto out;
+            base = 8;
+        }
+    } else {
+        if (base != 0 && base != 10) goto out;
+        base = 10;
+    }
+
+    while ( *s != '\0' ) {
+        int d = __digit(*s, base);
+
+        if ( d < 0 ) goto out;
+
+        v = (v * base) + d;
+        s++;
+    }
+
+out:
+    if (end) *end = (char *)s;
+
+    return sign * v;
+}
+
 void *
 memset(void *s, int c, unsigned n)
 {
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
@@ -152,6 +152,7 @@ int strncmp(const char *s1, const char *
 char *strcpy(char *dest, const char *src);
 char *strncpy(char *dest, const char *src, unsigned n);
 unsigned strlen(const char *s);
+long long strtoll(const char *s, char **end, int base);
 int memcmp(const void *s1, const void *s2, unsigned n);
 void *memcpy(void *dest, const void *src, unsigned n);
 void *memmove(void *dest, const void *src, unsigned n);
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxl_create.c	Tue Nov 29 10:48:54 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.generation_id = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -191,13 +192,15 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 7, sizeof(char *));
+        localents = libxl__calloc(gc, 9, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
         localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
         localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[6] = "platform/generation-id";
+        localents[7] = libxl__sprintf(gc, "0x%llx", info->u.hvm.generation_id);
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Nov 29 10:48:54 2011 +0000
@@ -176,6 +176,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("generation_id", uint64),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Tue Nov 29 10:48:54 2011 +0000
@@ -232,7 +232,35 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
+                          long long *value_r) {
+    long long ll;
+    XLU_ConfigSetting *set;
+    int e;
+    char *ep;
 
+    e= find_atom(cfg,n,&set);  if (e) return e;
+    errno= 0; ll= strtoll(set->values[0], &ep, 0);
+    e= errno;
+    if (errno) {
+        e= errno;
+        assert(e==EINVAL || e==ERANGE);
+        fprintf(cfg->report,
+                "%s:%d: warning: parameter `%s' could not be parsed"
+                " as a number: %s\n",
+                cfg->filename, set->lineno, n, strerror(e));
+        return e;
+    }
+    if (*ep || ep==set->values[0]) {
+        fprintf(cfg->report,
+                "%s:%d: warning: parameter `%s' is not a valid number\n",
+                cfg->filename, set->lineno, n);
+        return EINVAL;
+    }
+    *value_r= ll;
+    return 0;
+}
+ 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
     XLU_ConfigSetting *set;
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxlutil.h	Tue Nov 29 10:48:54 2011 +0000
@@ -48,6 +48,7 @@ void xlu_cfg_destroy(XLU_Config*);
 int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r);
 int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char **value_r); /* free/strdup version */
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r);
+int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long long *value_r);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 10:48:54 2011 +0000
@@ -355,6 +355,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(generation_id %llx)\n", b_info->u.hvm.generation_id);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -523,6 +524,7 @@ static void parse_config_data(const char
 {
     const char *buf;
     long l;
+    long long ll;
     XLU_Config *config;
     XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
@@ -699,6 +701,8 @@ static void parse_config_data(const char
             b_info->u.hvm.timer_mode = l;
         if (!xlu_cfg_get_long (config, "nestedhvm", &l))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long_long (config, "generation_id", &ll))
+            b_info->u.hvm.generation_id = ll;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMx-0006xn-PS; Tue, 29 Nov 2011 10:56:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMw-0006vZ-Ki
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322564178!6792868!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24960 invoked from network); 29 Nov 2011 10:56:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:56:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="19482742"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:16 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:16 -0500
MIME-Version: 1.0
X-Mercurial-Node: 58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
Message-ID: <58cdfa17fb8801ab0a9e.1322564001@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:21 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 3 of 6] Allocate an 8 byte buffer to contain the
 VM generation id and populate it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563734 0
# Node ID 58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
# Parent  ec35c9c5a0c053532de953f59f7c8f28ba69167a
Allocate an 8 byte buffer to contain the VM generation id and populate it
at boot time with a value read from "platform/generation_id". Also add
code to libxl to populate this xenstore key with the value of a new
'generation_id' parameter in the VM config file.
Populate the ADDR package of VM_Gen_Counter ACPI device such that the first
integer evaluates to the low order 32 bits of the buffer address and the
second integer evaluates to the high order 32 bits of the buffer address.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
@@ -297,6 +297,20 @@ static int construct_secondary_tables(un
     return nr_tables;
 }
 
+unsigned long new_vm_gid(void)
+{
+    uint64_t gid;
+    unsigned char *buf;
+
+    buf = mem_alloc(8, 8);
+    if (!buf) return 0;
+
+    gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
+    *(uint64_t *)buf = gid;
+
+    return virt_to_phys(buf);    
+}
+
 void acpi_build_tables(struct acpi_config *config, unsigned int physical)
 {
     struct acpi_info *acpi_info;
@@ -309,6 +323,7 @@ void acpi_build_tables(struct acpi_confi
     unsigned char       *dsdt;
     unsigned long        secondary_tables[16];
     int                  nr_secondaries, i;
+    unsigned long        vm_gid_addr;
 
     /* Allocate and initialise the acpi info area. */
     mem_hole_populate_ram(ACPI_INFO_PHYSICAL_ADDRESS >> PAGE_SHIFT, 1);
@@ -421,12 +436,16 @@ void acpi_build_tables(struct acpi_confi
                  offsetof(struct acpi_20_rsdp, extended_checksum),
                  sizeof(struct acpi_20_rsdp));
 
+    vm_gid_addr = new_vm_gid();
+    if (!vm_gid_addr) goto oom;
+
     acpi_info->com1_present = uart_exists(0x3f8);
     acpi_info->com2_present = uart_exists(0x2f8);
     acpi_info->lpt1_present = lpt_exists(0x378);
     acpi_info->hpet_present = hpet_exists(ACPI_HPET_ADDRESS);
     acpi_info->pci_min = pci_mem_start;
     acpi_info->pci_len = pci_mem_end - pci_mem_start;
+    acpi_info->vm_gid_addr = vm_gid_addr;
 
     return;
 
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
@@ -205,6 +205,78 @@ strlen(const char *s)
     return i;
 }
 
+static inline int __digit(char c, int base)
+{
+    int d = -1;
+
+    if ( (c >= '0') && (c <= '9') )
+        d = c - '0';
+
+    if ( (c >= 'A') && (c <= 'Z') )
+        d = c - 'A' + 10;
+
+    if ( (c >= 'a') && (c <= 'z') )
+        d = c - 'a' + 10;
+
+    if (d >= base)
+        d = -1;
+
+    return d;
+}
+
+long long
+strtoll(const char *s, char **end, int base)
+{
+    long long v = 0;
+    int sign = 1;
+
+    while ( (*s != '\0') && isspace(*s) )
+        s++;
+
+    if ( *s == '\0' ) goto out;
+
+    if ( *s == '-' ) {
+        sign = -1;
+        s++;
+    } else {
+        if ( *s == '+' )
+            s++;
+    }
+
+    if ( *s == '\0' ) goto out;
+
+    if ( *s == '0' ) {
+        s++;
+        if ( *s == '\0' ) goto out;
+
+        if ( *s == 'x' ) {
+            if ( base != 0 && base != 16) goto out;
+            base = 16;
+            s++;
+        } else {
+            if ( base != 0 && base != 8) goto out;
+            base = 8;
+        }
+    } else {
+        if (base != 0 && base != 10) goto out;
+        base = 10;
+    }
+
+    while ( *s != '\0' ) {
+        int d = __digit(*s, base);
+
+        if ( d < 0 ) goto out;
+
+        v = (v * base) + d;
+        s++;
+    }
+
+out:
+    if (end) *end = (char *)s;
+
+    return sign * v;
+}
+
 void *
 memset(void *s, int c, unsigned n)
 {
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
@@ -152,6 +152,7 @@ int strncmp(const char *s1, const char *
 char *strcpy(char *dest, const char *src);
 char *strncpy(char *dest, const char *src, unsigned n);
 unsigned strlen(const char *s);
+long long strtoll(const char *s, char **end, int base);
 int memcmp(const void *s1, const void *s2, unsigned n);
 void *memcpy(void *dest, const void *src, unsigned n);
 void *memmove(void *dest, const void *src, unsigned n);
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxl_create.c	Tue Nov 29 10:48:54 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.generation_id = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -191,13 +192,15 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 7, sizeof(char *));
+        localents = libxl__calloc(gc, 9, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
         localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
         localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[6] = "platform/generation-id";
+        localents[7] = libxl__sprintf(gc, "0x%llx", info->u.hvm.generation_id);
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Nov 29 10:48:54 2011 +0000
@@ -176,6 +176,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("generation_id", uint64),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Tue Nov 29 10:48:54 2011 +0000
@@ -232,7 +232,35 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
+                          long long *value_r) {
+    long long ll;
+    XLU_ConfigSetting *set;
+    int e;
+    char *ep;
 
+    e= find_atom(cfg,n,&set);  if (e) return e;
+    errno= 0; ll= strtoll(set->values[0], &ep, 0);
+    e= errno;
+    if (errno) {
+        e= errno;
+        assert(e==EINVAL || e==ERANGE);
+        fprintf(cfg->report,
+                "%s:%d: warning: parameter `%s' could not be parsed"
+                " as a number: %s\n",
+                cfg->filename, set->lineno, n, strerror(e));
+        return e;
+    }
+    if (*ep || ep==set->values[0]) {
+        fprintf(cfg->report,
+                "%s:%d: warning: parameter `%s' is not a valid number\n",
+                cfg->filename, set->lineno, n);
+        return EINVAL;
+    }
+    *value_r= ll;
+    return 0;
+}
+ 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
     XLU_ConfigSetting *set;
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/libxlutil.h	Tue Nov 29 10:48:54 2011 +0000
@@ -48,6 +48,7 @@ void xlu_cfg_destroy(XLU_Config*);
 int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r);
 int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char **value_r); /* free/strdup version */
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r);
+int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long long *value_r);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r ec35c9c5a0c0 -r 58cdfa17fb88 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 10:48:54 2011 +0000
@@ -355,6 +355,7 @@ static void printf_info(int domid,
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(generation_id %llx)\n", b_info->u.hvm.generation_id);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
@@ -523,6 +524,7 @@ static void parse_config_data(const char
 {
     const char *buf;
     long l;
+    long long ll;
     XLU_Config *config;
     XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
@@ -699,6 +701,8 @@ static void parse_config_data(const char
             b_info->u.hvm.timer_mode = l;
         if (!xlu_cfg_get_long (config, "nestedhvm", &l))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long_long (config, "generation_id", &ll))
+            b_info->u.hvm.generation_id = ll;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMp-0006vC-QL; Tue, 29 Nov 2011 10:56:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMn-0006us-Tj
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:50 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322564148!42839582!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19800 invoked from network); 29 Nov 2011 10:55:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:55:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172159509"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:17 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:17 -0500
MIME-Version: 1.0
X-Mercurial-Node: e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
Message-ID: <e9997777ab6d629b97a8.1322564002@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:22 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563734 0
# Node ID e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
# Parent  58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
Add sprintf() to hvmloader.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 58cdfa17fb88 -r e9997777ab6d tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
@@ -528,7 +528,7 @@ static char *printnum(char *p, unsigned 
     return p;
 }
 
-static void _doprint(void (*put)(char), const char *fmt, va_list ap)
+static void _doprint(void (*emit)(char**, char), char **arg, const char *fmt, va_list ap)
 {
     char *str, c;
     int lflag, zflag, nflag;
@@ -540,7 +540,7 @@ static void _doprint(void (*put)(char), 
     {
         if ( *fmt != '%' )
         {
-            put(*fmt);
+            emit(arg, *fmt);
             continue;
         }
 
@@ -571,7 +571,7 @@ static void _doprint(void (*put)(char), 
                 if ( (c == 'd') && ((long)value < 0) )
                 {
                     value = -value;
-                    put('-');
+                    emit(arg, '-');
                 }
             }
             else
@@ -580,7 +580,7 @@ static void _doprint(void (*put)(char), 
                 if ( (c == 'd') && ((int)value < 0) )
                 {
                     value = -(int)value;
-                    put('-');
+                    emit(arg, '-');
                 }
             }
             str = buffer;
@@ -588,13 +588,13 @@ static void _doprint(void (*put)(char), 
                      c == 'o' ? 8 : ((c == 'x') || (c == 'X') ? 16 : 10));
             slen = strlen(str);
             for ( i = pad - slen; i > 0; i-- )
-                put(zflag ? '0' : ' ');
+                emit(arg, zflag ? '0' : ' ');
             while ( *str )
             {
                 char ch = *str++;
                 if ( (ch >= 'a') && (c == 'X') )
                     ch += 'A'-'a';
-                put(ch);
+                emit(arg, ch);
             }
         }
         else if ( c == 's' )
@@ -603,20 +603,20 @@ static void _doprint(void (*put)(char), 
             slen = strlen(str);
             if ( nflag == 0 )
                 for ( i = pad - slen; i > 0; i-- )
-                    put(' ');
+                    emit(arg, ' ');
             while ( *str )
-                put(*str++);
+                emit(arg, *str++);
             if ( nflag )
                 for ( i = pad - slen; i > 0; i-- )
-                    put(' ');
+                    emit(arg, ' ');
         }
         else if ( c == 'c' )
         {
-            put(va_arg(ap, int));
+            emit(arg, va_arg(ap, int));
         }
         else
         {
-            put(*fmt);
+            emit(arg, *fmt);
         }
     }
 }
@@ -626,12 +626,17 @@ static void putchar(char c)
     outb(0xe9, c);
 }
 
+static void __put(char **ignore, char c)
+{
+    putchar(c);
+}
+
 int printf(const char *fmt, ...)
 {
     va_list ap;
 
     va_start(ap, fmt);
-    _doprint(putchar, fmt, ap);
+    _doprint(__put, NULL, fmt, ap);
     va_end(ap);
 
     return 0;
@@ -639,7 +644,25 @@ int printf(const char *fmt, ...)
 
 int vprintf(const char *fmt, va_list ap)
 {
-    _doprint(putchar, fmt, ap);
+    _doprint(__put, NULL, fmt, ap);
+    return 0;
+}
+
+static void __copy(char **buf, char c)
+{
+    **buf = c;
+    (*buf)++;
+}
+
+int sprintf(char *buf, const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    _doprint(__copy, &buf, fmt, ap);
+    va_end(ap);
+
+    *buf = '\0';
     return 0;
 }
 
diff -r 58cdfa17fb88 -r e9997777ab6d tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
@@ -171,6 +171,9 @@ void uuid_to_string(char *dest, uint8_t 
 int printf(const char *fmt, ...) __attribute__ ((format (printf, 1, 2)));
 int vprintf(const char *fmt, va_list ap);
 
+/* Buffer output */
+int sprintf(char *buf, const char *fmt, ...) __attribute__ ((format (printf, 2, 3)));
+
 /* Populate specified memory hole with RAM. */
 void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLMp-0006vC-QL; Tue, 29 Nov 2011 10:56:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLMn-0006us-Tj
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:56:50 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322564148!42839582!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19800 invoked from network); 29 Nov 2011 10:55:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:55:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172159509"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 05:56:17 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 05:56:17 -0500
MIME-Version: 1.0
X-Mercurial-Node: e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
Message-ID: <e9997777ab6d629b97a8.1322564002@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 10:53:22 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322563734 0
# Node ID e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
# Parent  58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
Add sprintf() to hvmloader.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 58cdfa17fb88 -r e9997777ab6d tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
@@ -528,7 +528,7 @@ static char *printnum(char *p, unsigned 
     return p;
 }
 
-static void _doprint(void (*put)(char), const char *fmt, va_list ap)
+static void _doprint(void (*emit)(char**, char), char **arg, const char *fmt, va_list ap)
 {
     char *str, c;
     int lflag, zflag, nflag;
@@ -540,7 +540,7 @@ static void _doprint(void (*put)(char), 
     {
         if ( *fmt != '%' )
         {
-            put(*fmt);
+            emit(arg, *fmt);
             continue;
         }
 
@@ -571,7 +571,7 @@ static void _doprint(void (*put)(char), 
                 if ( (c == 'd') && ((long)value < 0) )
                 {
                     value = -value;
-                    put('-');
+                    emit(arg, '-');
                 }
             }
             else
@@ -580,7 +580,7 @@ static void _doprint(void (*put)(char), 
                 if ( (c == 'd') && ((int)value < 0) )
                 {
                     value = -(int)value;
-                    put('-');
+                    emit(arg, '-');
                 }
             }
             str = buffer;
@@ -588,13 +588,13 @@ static void _doprint(void (*put)(char), 
                      c == 'o' ? 8 : ((c == 'x') || (c == 'X') ? 16 : 10));
             slen = strlen(str);
             for ( i = pad - slen; i > 0; i-- )
-                put(zflag ? '0' : ' ');
+                emit(arg, zflag ? '0' : ' ');
             while ( *str )
             {
                 char ch = *str++;
                 if ( (ch >= 'a') && (c == 'X') )
                     ch += 'A'-'a';
-                put(ch);
+                emit(arg, ch);
             }
         }
         else if ( c == 's' )
@@ -603,20 +603,20 @@ static void _doprint(void (*put)(char), 
             slen = strlen(str);
             if ( nflag == 0 )
                 for ( i = pad - slen; i > 0; i-- )
-                    put(' ');
+                    emit(arg, ' ');
             while ( *str )
-                put(*str++);
+                emit(arg, *str++);
             if ( nflag )
                 for ( i = pad - slen; i > 0; i-- )
-                    put(' ');
+                    emit(arg, ' ');
         }
         else if ( c == 'c' )
         {
-            put(va_arg(ap, int));
+            emit(arg, va_arg(ap, int));
         }
         else
         {
-            put(*fmt);
+            emit(arg, *fmt);
         }
     }
 }
@@ -626,12 +626,17 @@ static void putchar(char c)
     outb(0xe9, c);
 }
 
+static void __put(char **ignore, char c)
+{
+    putchar(c);
+}
+
 int printf(const char *fmt, ...)
 {
     va_list ap;
 
     va_start(ap, fmt);
-    _doprint(putchar, fmt, ap);
+    _doprint(__put, NULL, fmt, ap);
     va_end(ap);
 
     return 0;
@@ -639,7 +644,25 @@ int printf(const char *fmt, ...)
 
 int vprintf(const char *fmt, va_list ap)
 {
-    _doprint(putchar, fmt, ap);
+    _doprint(__put, NULL, fmt, ap);
+    return 0;
+}
+
+static void __copy(char **buf, char c)
+{
+    **buf = c;
+    (*buf)++;
+}
+
+int sprintf(char *buf, const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    _doprint(__copy, &buf, fmt, ap);
+    va_end(ap);
+
+    *buf = '\0';
     return 0;
 }
 
diff -r 58cdfa17fb88 -r e9997777ab6d tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
@@ -171,6 +171,9 @@ void uuid_to_string(char *dest, uint8_t 
 int printf(const char *fmt, ...) __attribute__ ((format (printf, 1, 2)));
 int vprintf(const char *fmt, va_list ap);
 
+/* Buffer output */
+int sprintf(char *buf, const char *fmt, ...) __attribute__ ((format (printf, 2, 3)));
+
 /* Populate specified memory hole with RAM. */
 void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLN3-00071I-VX; Tue, 29 Nov 2011 10:57:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVLN3-0006yu-85
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:57:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322564084!54133373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7332 invoked from network); 29 Nov 2011 10:54:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9181042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:56:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:56:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:56:29 +0000
In-Reply-To: <1322499580-2322-11-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-11-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322564189.20646.40.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10/13] libxl: make libxl__[v]log
 const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.c |    4 ++--
>  tools/libxl/libxl_internal.h |    4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index d767ce3..ae28cb0 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -179,7 +179,7 @@ char *libxl__dirname(libxl__gc *gc, const char *s)
>  
>  void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
>               const char *file, int line, const char *func,
> -             char *fmt, va_list ap)
> +             const char *fmt, va_list ap)
>  {
>      char *enomem = "[out of memory formatting log message]";
>      char *base = NULL;
> @@ -206,7 +206,7 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
>  
>  void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
>              const char *file, int line, const char *func,
> -            char *fmt, ...)
> +            const char *fmt, ...)
>  {
>      va_list ap;
>      va_start(ap, fmt);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 41de6fd..1d1dc35 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -80,13 +80,13 @@
>  _hidden void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
>               const char *file /* may be 0 */, int line /* ignored if !file */,
>               const char *func /* may be 0 */,
> -             char *fmt, va_list al)
> +             const char *fmt, va_list al)
>       __attribute__((format(printf,7,0)));
>  
>  _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
>              const char *file /* may be 0 */, int line /* ignored if !file */,
>              const char *func /* may be 0 */,
> -            char *fmt, ...)
> +            const char *fmt, ...)
>       __attribute__((format(printf,7,8)));
>  
>       /* these functions preserve errno (saving and restoring) */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 10:57:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 10:57:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLN3-00071I-VX; Tue, 29 Nov 2011 10:57:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVLN3-0006yu-85
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 10:57:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322564084!54133373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7332 invoked from network); 29 Nov 2011 10:54:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 10:54:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9181042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:56:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 10:56:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 10:56:29 +0000
In-Reply-To: <1322499580-2322-11-git-send-email-ian.jackson@eu.citrix.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-11-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322564189.20646.40.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10/13] libxl: make libxl__[v]log
 const-correct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.c |    4 ++--
>  tools/libxl/libxl_internal.h |    4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index d767ce3..ae28cb0 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -179,7 +179,7 @@ char *libxl__dirname(libxl__gc *gc, const char *s)
>  
>  void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
>               const char *file, int line, const char *func,
> -             char *fmt, va_list ap)
> +             const char *fmt, va_list ap)
>  {
>      char *enomem = "[out of memory formatting log message]";
>      char *base = NULL;
> @@ -206,7 +206,7 @@ void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
>  
>  void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
>              const char *file, int line, const char *func,
> -            char *fmt, ...)
> +            const char *fmt, ...)
>  {
>      va_list ap;
>      va_start(ap, fmt);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 41de6fd..1d1dc35 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -80,13 +80,13 @@
>  _hidden void libxl__logv(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
>               const char *file /* may be 0 */, int line /* ignored if !file */,
>               const char *func /* may be 0 */,
> -             char *fmt, va_list al)
> +             const char *fmt, va_list al)
>       __attribute__((format(printf,7,0)));
>  
>  _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
>              const char *file /* may be 0 */, int line /* ignored if !file */,
>              const char *func /* may be 0 */,
> -            char *fmt, ...)
> +            const char *fmt, ...)
>       __attribute__((format(printf,7,8)));
>  
>       /* these functions preserve errno (saving and restoring) */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 11:02:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 11:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLST-0008QB-1V; Tue, 29 Nov 2011 11:02:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RVLSR-0008Pr-AT
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 11:02:39 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322564492!55011484!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13812 invoked from network); 29 Nov 2011 11:01:32 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.209)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Nov 2011 11:01:32 -0000
Received: from mail5-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.22; Tue, 29 Nov 2011 11:01:18 +0000
Received: from mail5-am1 (localhost [127.0.0.1])	by mail5-am1-R.bigfish.com
	(Postfix) with ESMTP id 30D5F80296;
	Tue, 29 Nov 2011 11:01:16 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dK1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail5-am1 (localhost.localdomain [127.0.0.1]) by mail5-am1
	(MessageSwitch) id 1322564475766526_2522;
	Tue, 29 Nov 2011 11:01:15 +0000 (UTC)
Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.250])	by
	mail5-am1.bigfish.com (Postfix) with ESMTP id AC309460048;
	Tue, 29 Nov 2011 11:01:15 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server id
	14.1.225.22; Tue, 29 Nov 2011 11:01:15 +0000
X-WSS-ID: 0LVF5BB-02-AMR-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2EF6AC8147;	Tue, 29 Nov 2011 05:01:59 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 29 Nov 2011 05:02:08 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 29 Nov 2011 05:02:00 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	06:01:59 -0500
Message-ID: <4ED4BBA5.4030403@amd.com>
Date: Tue, 29 Nov 2011 12:01:57 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<e9997777ab6d629b97a8.1322564002@cosworth.uk.xensource.com>
In-Reply-To: <e9997777ab6d629b97a8.1322564002@cosworth.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/29/11 11:53, Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant<paul.durrant@citrix.com>
> # Date 1322563734 0
> # Node ID e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
> # Parent  58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
> Add sprintf() to hvmloader.

For security reasons I prefer snprintf().

Christoph


>
> Signed-off-by: Paul Durrant<paul.durrant@citrix.com>
>
> diff -r 58cdfa17fb88 -r e9997777ab6d tools/firmware/hvmloader/util.c
> --- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
> +++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
> @@ -528,7 +528,7 @@ static char *printnum(char *p, unsigned
>       return p;
>   }
>
> -static void _doprint(void (*put)(char), const char *fmt, va_list ap)
> +static void _doprint(void (*emit)(char**, char), char **arg, const char *fmt, va_list ap)
>   {
>       char *str, c;
>       int lflag, zflag, nflag;
> @@ -540,7 +540,7 @@ static void _doprint(void (*put)(char),
>       {
>           if ( *fmt != '%' )
>           {
> -            put(*fmt);
> +            emit(arg, *fmt);
>               continue;
>           }
>
> @@ -571,7 +571,7 @@ static void _doprint(void (*put)(char),
>                   if ( (c == 'd')&&  ((long)value<  0) )
>                   {
>                       value = -value;
> -                    put('-');
> +                    emit(arg, '-');
>                   }
>               }
>               else
> @@ -580,7 +580,7 @@ static void _doprint(void (*put)(char),
>                   if ( (c == 'd')&&  ((int)value<  0) )
>                   {
>                       value = -(int)value;
> -                    put('-');
> +                    emit(arg, '-');
>                   }
>               }
>               str = buffer;
> @@ -588,13 +588,13 @@ static void _doprint(void (*put)(char),
>                        c == 'o' ? 8 : ((c == 'x') || (c == 'X') ? 16 : 10));
>               slen = strlen(str);
>               for ( i = pad - slen; i>  0; i-- )
> -                put(zflag ? '0' : ' ');
> +                emit(arg, zflag ? '0' : ' ');
>               while ( *str )
>               {
>                   char ch = *str++;
>                   if ( (ch>= 'a')&&  (c == 'X') )
>                       ch += 'A'-'a';
> -                put(ch);
> +                emit(arg, ch);
>               }
>           }
>           else if ( c == 's' )
> @@ -603,20 +603,20 @@ static void _doprint(void (*put)(char),
>               slen = strlen(str);
>               if ( nflag == 0 )
>                   for ( i = pad - slen; i>  0; i-- )
> -                    put(' ');
> +                    emit(arg, ' ');
>               while ( *str )
> -                put(*str++);
> +                emit(arg, *str++);
>               if ( nflag )
>                   for ( i = pad - slen; i>  0; i-- )
> -                    put(' ');
> +                    emit(arg, ' ');
>           }
>           else if ( c == 'c' )
>           {
> -            put(va_arg(ap, int));
> +            emit(arg, va_arg(ap, int));
>           }
>           else
>           {
> -            put(*fmt);
> +            emit(arg, *fmt);
>           }
>       }
>   }
> @@ -626,12 +626,17 @@ static void putchar(char c)
>       outb(0xe9, c);
>   }
>
> +static void __put(char **ignore, char c)
> +{
> +    putchar(c);
> +}
> +
>   int printf(const char *fmt, ...)
>   {
>       va_list ap;
>
>       va_start(ap, fmt);
> -    _doprint(putchar, fmt, ap);
> +    _doprint(__put, NULL, fmt, ap);
>       va_end(ap);
>
>       return 0;
> @@ -639,7 +644,25 @@ int printf(const char *fmt, ...)
>
>   int vprintf(const char *fmt, va_list ap)
>   {
> -    _doprint(putchar, fmt, ap);
> +    _doprint(__put, NULL, fmt, ap);
> +    return 0;
> +}
> +
> +static void __copy(char **buf, char c)
> +{
> +    **buf = c;
> +    (*buf)++;
> +}
> +
> +int sprintf(char *buf, const char *fmt, ...)
> +{
> +    va_list ap;
> +
> +    va_start(ap, fmt);
> +    _doprint(__copy,&buf, fmt, ap);
> +    va_end(ap);
> +
> +    *buf = '\0';
>       return 0;
>   }
>
> diff -r 58cdfa17fb88 -r e9997777ab6d tools/firmware/hvmloader/util.h
> --- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
> +++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
> @@ -171,6 +171,9 @@ void uuid_to_string(char *dest, uint8_t
>   int printf(const char *fmt, ...) __attribute__ ((format (printf, 1, 2)));
>   int vprintf(const char *fmt, va_list ap);
>
> +/* Buffer output */
> +int sprintf(char *buf, const char *fmt, ...) __attribute__ ((format (printf, 2, 3)));
> +
>   /* Populate specified memory hole with RAM. */
>   void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns);
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 11:02:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 11:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLST-0008QB-1V; Tue, 29 Nov 2011 11:02:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RVLSR-0008Pr-AT
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 11:02:39 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322564492!55011484!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13812 invoked from network); 29 Nov 2011 11:01:32 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.209)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Nov 2011 11:01:32 -0000
Received: from mail5-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.22; Tue, 29 Nov 2011 11:01:18 +0000
Received: from mail5-am1 (localhost [127.0.0.1])	by mail5-am1-R.bigfish.com
	(Postfix) with ESMTP id 30D5F80296;
	Tue, 29 Nov 2011 11:01:16 +0000 (UTC)
X-SpamScore: -12
X-BigFish: VPS-12(zzbb2dK1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail5-am1 (localhost.localdomain [127.0.0.1]) by mail5-am1
	(MessageSwitch) id 1322564475766526_2522;
	Tue, 29 Nov 2011 11:01:15 +0000 (UTC)
Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.250])	by
	mail5-am1.bigfish.com (Postfix) with ESMTP id AC309460048;
	Tue, 29 Nov 2011 11:01:15 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server id
	14.1.225.22; Tue, 29 Nov 2011 11:01:15 +0000
X-WSS-ID: 0LVF5BB-02-AMR-02
X-M-MSG: 
Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com
	[163.181.249.72])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp02.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2EF6AC8147;	Tue, 29 Nov 2011 05:01:59 -0600 (CST)
Received: from SAUSEXDAG03.amd.com (163.181.55.3) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 29 Nov 2011 05:02:08 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 29 Nov 2011 05:02:00 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	06:01:59 -0500
Message-ID: <4ED4BBA5.4030403@amd.com>
Date: Tue, 29 Nov 2011 12:01:57 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<e9997777ab6d629b97a8.1322564002@cosworth.uk.xensource.com>
In-Reply-To: <e9997777ab6d629b97a8.1322564002@cosworth.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/29/11 11:53, Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant<paul.durrant@citrix.com>
> # Date 1322563734 0
> # Node ID e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
> # Parent  58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
> Add sprintf() to hvmloader.

For security reasons I prefer snprintf().

Christoph


>
> Signed-off-by: Paul Durrant<paul.durrant@citrix.com>
>
> diff -r 58cdfa17fb88 -r e9997777ab6d tools/firmware/hvmloader/util.c
> --- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
> +++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
> @@ -528,7 +528,7 @@ static char *printnum(char *p, unsigned
>       return p;
>   }
>
> -static void _doprint(void (*put)(char), const char *fmt, va_list ap)
> +static void _doprint(void (*emit)(char**, char), char **arg, const char *fmt, va_list ap)
>   {
>       char *str, c;
>       int lflag, zflag, nflag;
> @@ -540,7 +540,7 @@ static void _doprint(void (*put)(char),
>       {
>           if ( *fmt != '%' )
>           {
> -            put(*fmt);
> +            emit(arg, *fmt);
>               continue;
>           }
>
> @@ -571,7 +571,7 @@ static void _doprint(void (*put)(char),
>                   if ( (c == 'd')&&  ((long)value<  0) )
>                   {
>                       value = -value;
> -                    put('-');
> +                    emit(arg, '-');
>                   }
>               }
>               else
> @@ -580,7 +580,7 @@ static void _doprint(void (*put)(char),
>                   if ( (c == 'd')&&  ((int)value<  0) )
>                   {
>                       value = -(int)value;
> -                    put('-');
> +                    emit(arg, '-');
>                   }
>               }
>               str = buffer;
> @@ -588,13 +588,13 @@ static void _doprint(void (*put)(char),
>                        c == 'o' ? 8 : ((c == 'x') || (c == 'X') ? 16 : 10));
>               slen = strlen(str);
>               for ( i = pad - slen; i>  0; i-- )
> -                put(zflag ? '0' : ' ');
> +                emit(arg, zflag ? '0' : ' ');
>               while ( *str )
>               {
>                   char ch = *str++;
>                   if ( (ch>= 'a')&&  (c == 'X') )
>                       ch += 'A'-'a';
> -                put(ch);
> +                emit(arg, ch);
>               }
>           }
>           else if ( c == 's' )
> @@ -603,20 +603,20 @@ static void _doprint(void (*put)(char),
>               slen = strlen(str);
>               if ( nflag == 0 )
>                   for ( i = pad - slen; i>  0; i-- )
> -                    put(' ');
> +                    emit(arg, ' ');
>               while ( *str )
> -                put(*str++);
> +                emit(arg, *str++);
>               if ( nflag )
>                   for ( i = pad - slen; i>  0; i-- )
> -                    put(' ');
> +                    emit(arg, ' ');
>           }
>           else if ( c == 'c' )
>           {
> -            put(va_arg(ap, int));
> +            emit(arg, va_arg(ap, int));
>           }
>           else
>           {
> -            put(*fmt);
> +            emit(arg, *fmt);
>           }
>       }
>   }
> @@ -626,12 +626,17 @@ static void putchar(char c)
>       outb(0xe9, c);
>   }
>
> +static void __put(char **ignore, char c)
> +{
> +    putchar(c);
> +}
> +
>   int printf(const char *fmt, ...)
>   {
>       va_list ap;
>
>       va_start(ap, fmt);
> -    _doprint(putchar, fmt, ap);
> +    _doprint(__put, NULL, fmt, ap);
>       va_end(ap);
>
>       return 0;
> @@ -639,7 +644,25 @@ int printf(const char *fmt, ...)
>
>   int vprintf(const char *fmt, va_list ap)
>   {
> -    _doprint(putchar, fmt, ap);
> +    _doprint(__put, NULL, fmt, ap);
> +    return 0;
> +}
> +
> +static void __copy(char **buf, char c)
> +{
> +    **buf = c;
> +    (*buf)++;
> +}
> +
> +int sprintf(char *buf, const char *fmt, ...)
> +{
> +    va_list ap;
> +
> +    va_start(ap, fmt);
> +    _doprint(__copy,&buf, fmt, ap);
> +    va_end(ap);
> +
> +    *buf = '\0';
>       return 0;
>   }
>
> diff -r 58cdfa17fb88 -r e9997777ab6d tools/firmware/hvmloader/util.h
> --- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
> +++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
> @@ -171,6 +171,9 @@ void uuid_to_string(char *dest, uint8_t
>   int printf(const char *fmt, ...) __attribute__ ((format (printf, 1, 2)));
>   int vprintf(const char *fmt, va_list ap);
>
> +/* Buffer output */
> +int sprintf(char *buf, const char *fmt, ...) __attribute__ ((format (printf, 2, 3)));
> +
>   /* Populate specified memory hole with RAM. */
>   void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns);
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 11:12:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 11:12:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLbu-0000Hq-FZ; Tue, 29 Nov 2011 11:12:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RVLbs-0000Hh-Rm
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 11:12:25 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322565107!3512813!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30765 invoked from network); 29 Nov 2011 11:11:47 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.209)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Nov 2011 11:11:47 -0000
Received: from mail11-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.22; Tue, 29 Nov 2011 11:10:59 +0000
Received: from mail11-am1 (localhost [127.0.0.1])	by mail11-am1-R.bigfish.com
	(Postfix) with ESMTP id E0CC0700212;
	Tue, 29 Nov 2011 11:10:59 +0000 (UTC)
X-SpamScore: -17
X-BigFish: VPS-17(zzbb2dK542M1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail11-am1 (localhost.localdomain [127.0.0.1]) by mail11-am1
	(MessageSwitch) id 1322565059763514_11607;
	Tue, 29 Nov 2011 11:10:59 +0000 (UTC)
Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.249])	by
	mail11-am1.bigfish.com (Postfix) with ESMTP id B51EC580042;
	Tue, 29 Nov 2011 11:10:59 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS020.bigfish.com (10.3.206.23) with Microsoft SMTP Server id
	14.1.225.22; Tue, 29 Nov 2011 11:10:58 +0000
X-WSS-ID: 0LVF5RJ-01-71Y-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2653F102811A;	Tue, 29 Nov 2011 05:11:42 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 29 Nov 2011 05:11:51 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 29 Nov 2011 05:11:43 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	06:11:42 -0500
Message-ID: <4ED4BDEC.4010403@amd.com>
Date: Tue, 29 Nov 2011 12:11:40 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<e9997777ab6d629b97a8.1322564002@cosworth.uk.xensource.com>
	<4ED4BBA5.4030403@amd.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4EB6@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4EB6@LONPMAILBOX01.citrite.net>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/29/11 12:04, Paul Durrant wrote:
>> -----Original Message-----
>> From: Christoph Egger [mailto:Christoph.Egger@amd.com]
>> Sent: 29 November 2011 11:02
>> To: Paul Durrant
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
>>
>> On 11/29/11 11:53, Paul Durrant wrote:
>>> # HG changeset patch
>>> # User Paul Durrant<paul.durrant@citrix.com>  # Date 1322563734 0 #
>>> Node ID e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
>>> # Parent  58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
>>> Add sprintf() to hvmloader.
>>
>> For security reasons I prefer snprintf().
>>
>
> Given the limited usecase, I decided it wasn't worth it but
 > I can tag on a extra patch to make the conversion if you want me to.

Yes, please. This makes new code less prone to buffer overflows
in general.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 11:12:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 11:12:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLbu-0000Hq-FZ; Tue, 29 Nov 2011 11:12:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RVLbs-0000Hh-Rm
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 11:12:25 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322565107!3512813!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30765 invoked from network); 29 Nov 2011 11:11:47 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.209)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	29 Nov 2011 11:11:47 -0000
Received: from mail11-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.22; Tue, 29 Nov 2011 11:10:59 +0000
Received: from mail11-am1 (localhost [127.0.0.1])	by mail11-am1-R.bigfish.com
	(Postfix) with ESMTP id E0CC0700212;
	Tue, 29 Nov 2011 11:10:59 +0000 (UTC)
X-SpamScore: -17
X-BigFish: VPS-17(zzbb2dK542M1432N98dKzz1202hzz8275bhz2dh668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail11-am1 (localhost.localdomain [127.0.0.1]) by mail11-am1
	(MessageSwitch) id 1322565059763514_11607;
	Tue, 29 Nov 2011 11:10:59 +0000 (UTC)
Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.249])	by
	mail11-am1.bigfish.com (Postfix) with ESMTP id B51EC580042;
	Tue, 29 Nov 2011 11:10:59 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS020.bigfish.com (10.3.206.23) with Microsoft SMTP Server id
	14.1.225.22; Tue, 29 Nov 2011 11:10:58 +0000
X-WSS-ID: 0LVF5RJ-01-71Y-02
X-M-MSG: 
Received: from sausexedgep02.amd.com (sausexedgep02-ext.amd.com
	[163.181.249.73])	(using TLSv1 with cipher AES128-SHA (128/128
	bits))	(No
	client certificate requested)	by ausb3twp01.amd.com (Axway MailGate
	3.8.1)
	with ESMTP id 2653F102811A;	Tue, 29 Nov 2011 05:11:42 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 29 Nov 2011 05:11:51 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 29 Nov 2011 05:11:43 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	06:11:42 -0500
Message-ID: <4ED4BDEC.4010403@amd.com>
Date: Tue, 29 Nov 2011 12:11:40 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<e9997777ab6d629b97a8.1322564002@cosworth.uk.xensource.com>
	<4ED4BBA5.4030403@amd.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4EB6@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4EB6@LONPMAILBOX01.citrite.net>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/29/11 12:04, Paul Durrant wrote:
>> -----Original Message-----
>> From: Christoph Egger [mailto:Christoph.Egger@amd.com]
>> Sent: 29 November 2011 11:02
>> To: Paul Durrant
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
>>
>> On 11/29/11 11:53, Paul Durrant wrote:
>>> # HG changeset patch
>>> # User Paul Durrant<paul.durrant@citrix.com>  # Date 1322563734 0 #
>>> Node ID e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
>>> # Parent  58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
>>> Add sprintf() to hvmloader.
>>
>> For security reasons I prefer snprintf().
>>
>
> Given the limited usecase, I decided it wasn't worth it but
 > I can tag on a extra patch to make the conversion if you want me to.

Yes, please. This makes new code less prone to buffer overflows
in general.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 11:30:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 11:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLt2-0000bz-JD; Tue, 29 Nov 2011 11:30:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLt1-0000bu-Lh
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 11:30:07 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322564670!5386356!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20517 invoked from network); 29 Nov 2011 11:04:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 11:04:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9181367"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 11:04:30 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 29 Nov 2011
	11:04:30 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Tue, 29 Nov 2011 11:04:35 +0000
Thread-Topic: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
Thread-Index: Acyuhlw0GjN19+RzR9O7sejv/C3R4wAAB/mQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4EB6@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<e9997777ab6d629b97a8.1322564002@cosworth.uk.xensource.com>
	<4ED4BBA5.4030403@amd.com>
In-Reply-To: <4ED4BBA5.4030403@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Christoph Egger [mailto:Christoph.Egger@amd.com]
> Sent: 29 November 2011 11:02
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
> 
> On 11/29/11 11:53, Paul Durrant wrote:
> > # HG changeset patch
> > # User Paul Durrant<paul.durrant@citrix.com> # Date 1322563734 0 #
> > Node ID e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
> > # Parent  58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
> > Add sprintf() to hvmloader.
> 
> For security reasons I prefer snprintf().
> 

Given the limited usecase, I decided it wasn't worth it but I can tag on a extra patch to make the conversion if you want me to.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 11:30:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 11:30:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLt2-0000bz-JD; Tue, 29 Nov 2011 11:30:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVLt1-0000bu-Lh
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 11:30:07 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322564670!5386356!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20517 invoked from network); 29 Nov 2011 11:04:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 11:04:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9181367"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 11:04:30 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 29 Nov 2011
	11:04:30 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Tue, 29 Nov 2011 11:04:35 +0000
Thread-Topic: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
Thread-Index: Acyuhlw0GjN19+RzR9O7sejv/C3R4wAAB/mQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4EB6@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<e9997777ab6d629b97a8.1322564002@cosworth.uk.xensource.com>
	<4ED4BBA5.4030403@amd.com>
In-Reply-To: <4ED4BBA5.4030403@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Christoph Egger [mailto:Christoph.Egger@amd.com]
> Sent: 29 November 2011 11:02
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 4 of 6] Add sprintf() to hvmloader
> 
> On 11/29/11 11:53, Paul Durrant wrote:
> > # HG changeset patch
> > # User Paul Durrant<paul.durrant@citrix.com> # Date 1322563734 0 #
> > Node ID e9997777ab6d629b97a8b8f020c18f40c4cf3aa0
> > # Parent  58cdfa17fb8801ab0a9e8133e0ec2ad47a426f5d
> > Add sprintf() to hvmloader.
> 
> For security reasons I prefer snprintf().
> 

Given the limited usecase, I decided it wasn't worth it but I can tag on a extra patch to make the conversion if you want me to.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 11:36:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 11:36:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLzG-0000rM-EG; Tue, 29 Nov 2011 11:36:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVLzE-0000rE-Ov
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 11:36:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322566554!5116372!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 482 invoked from network); 29 Nov 2011 11:35:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 11:35:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 29 Nov 2011 11:35:54 +0000
Message-Id: <4ED4D1A90200007800064095@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 29 Nov 2011 11:35:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Simon Horman" <horms@verge.net.au>
References: <4ED399A7.1070108@citrix.com> <CAF9A2A8.25D24%keir.xen@gmail.com>
	<20111129055139.GB3222@verge.net.au> <4ED4B8C0.20108@citrix.com>
In-Reply-To: <4ED4B8C0.20108@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 29.11.11 at 11:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

> 
> On 29/11/11 05:51, Simon Horman wrote:
>> Hi Keir, Hi Andrew,
>>
>> On Mon, Nov 28, 2011 at 08:42:16PM +0000, Keir Fraser wrote:
>>> On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
>>> The patch is by Simon Horman, cc'ed, not me.
> 
> Right.  Sorry.  I should have remembered that basing "who wrote the
> patch" on a simple hg log was not a safe bet.

I don't think there's much room for improvement - all members of
crash_xen_info_t are of "unsigned long" type, but ELF note handling
will only ever guarantee 4-byte alignment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 11:36:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 11:36:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVLzG-0000rM-EG; Tue, 29 Nov 2011 11:36:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVLzE-0000rE-Ov
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 11:36:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322566554!5116372!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 482 invoked from network); 29 Nov 2011 11:35:55 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 11:35:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 29 Nov 2011 11:35:54 +0000
Message-Id: <4ED4D1A90200007800064095@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 29 Nov 2011 11:35:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Simon Horman" <horms@verge.net.au>
References: <4ED399A7.1070108@citrix.com> <CAF9A2A8.25D24%keir.xen@gmail.com>
	<20111129055139.GB3222@verge.net.au> <4ED4B8C0.20108@citrix.com>
In-Reply-To: <4ED4B8C0.20108@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 29.11.11 at 11:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

> 
> On 29/11/11 05:51, Simon Horman wrote:
>> Hi Keir, Hi Andrew,
>>
>> On Mon, Nov 28, 2011 at 08:42:16PM +0000, Keir Fraser wrote:
>>> On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
>>> The patch is by Simon Horman, cc'ed, not me.
> 
> Right.  Sorry.  I should have remembered that basing "who wrote the
> patch" on a simple hg log was not a safe bet.

I don't think there's much room for improvement - all members of
crash_xen_info_t are of "unsigned long" type, but ELF note handling
will only ever guarantee 4-byte alignment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 12:02:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 12:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVMNd-0001Dz-RE; Tue, 29 Nov 2011 12:01:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVMNc-0001DZ-7K
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 12:01:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322568063!3525993!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10111 invoked from network); 29 Nov 2011 12:01:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 12:01:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172165690"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 07:01:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 07:01:06 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATC14L5017453;	Tue, 29 Nov 2011 04:01:05 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6da8c30fb198adc15136a867a8303b7de3804bcf
Message-ID: <6da8c30fb198adc15136.1322568063@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 12:01:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] docs: XenBus page has been transfered to new
	wiki
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322568055 0
# Node ID 6da8c30fb198adc15136a867a8303b7de3804bcf
# Parent  fa9deee858b84d4c4fbb5f9523fa5adb7aac3a35
docs: XenBus page has been transfered to new wiki

Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>

diff -r fa9deee858b8 -r 6da8c30fb198 docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt	Tue Nov 29 11:07:59 2011 +0000
+++ b/docs/misc/xenstore.txt	Tue Nov 29 12:00:55 2011 +0000
@@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
 		r<domid>	read only
 		b<domid>	both read and write
 		n<domid>	no access
-	See http://wiki.xensource.com/xenwiki/XenBus section
+	See http://wiki.xensource.com/wiki/XenBus section
 	`Permissions' for details of the permissions system.
 
 ---------- Watches ----------

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 12:02:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 12:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVMNd-0001Dz-RE; Tue, 29 Nov 2011 12:01:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVMNc-0001DZ-7K
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 12:01:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322568063!3525993!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10111 invoked from network); 29 Nov 2011 12:01:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 12:01:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172165690"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 07:01:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 07:01:06 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATC14L5017453;	Tue, 29 Nov 2011 04:01:05 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6da8c30fb198adc15136a867a8303b7de3804bcf
Message-ID: <6da8c30fb198adc15136.1322568063@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 12:01:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] docs: XenBus page has been transfered to new
	wiki
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322568055 0
# Node ID 6da8c30fb198adc15136a867a8303b7de3804bcf
# Parent  fa9deee858b84d4c4fbb5f9523fa5adb7aac3a35
docs: XenBus page has been transfered to new wiki

Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>

diff -r fa9deee858b8 -r 6da8c30fb198 docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt	Tue Nov 29 11:07:59 2011 +0000
+++ b/docs/misc/xenstore.txt	Tue Nov 29 12:00:55 2011 +0000
@@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
 		r<domid>	read only
 		b<domid>	both read and write
 		n<domid>	no access
-	See http://wiki.xensource.com/xenwiki/XenBus section
+	See http://wiki.xensource.com/wiki/XenBus section
 	`Permissions' for details of the permissions system.
 
 ---------- Watches ----------

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 12:51:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 12:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVN9T-0001cg-Ul; Tue, 29 Nov 2011 12:51:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVN9S-0001cb-CT
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 12:51:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322571032!5497239!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2MzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2MzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27888 invoked from network); 29 Nov 2011 12:50:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 12:50:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322571031; l=1048;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=e03v1Zsjd9lFMsUedXA+BUj8UjU=;
	b=mI4EEH3rCGE/NLudmVOonPl0BoPz1XkhUA0t1o1hjmp/zo1YNlx1ba7h1w8V0V0HSy9
	sm3GkQKxY8gcleT0esGqHea1Q1WdXD1VCs60ozkZJkJH9sgSHuCkqH2AB6ogCcfomewf7
	Ykni33D5f7FzpC9Ya+aZMqhWUshUm0+gU2k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJiS0METKc
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-077-220.pools.arcor-ip.net [88.65.77.220])
	by smtp.strato.de (cohen mo33) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c04d9cnATCaxcC ;
	Tue, 29 Nov 2011 13:50:30 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 10C7918637; Tue, 29 Nov 2011 13:50:29 +0100 (CET)
Date: Tue, 29 Nov 2011 13:50:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20111129125029.GA13265@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111122113507.GA28412@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] use ncurses-config to find all curses
	related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After a split of libtinfo from libncurses in openSuSE Factory the tools
will not link anymore. In the URL below it was suggested to use
'ncurses-config --libs' to find the correct linker options. But
ncurses-config does not exist neither in SLES11 nor in openSuSE. So
check for both ncurses5-config and ncurses-config, if the latter happens
to exist in other environments.

With this change xen-unstable tools build succeeds again in SLES11 and
the latest openSuSE development branch.

http://lists.opensuse.org/opensuse-packaging/2011-11/msg00055.html

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 4319d77f5b3b config/StdGNU.mk
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -67,7 +67,7 @@ XEN_CONFIG_DIR = $(CONFIG_DIR)/xen
 XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
-CURSES_LIBS = -lncurses
+CURSES_LIBS ?= $(shell if ! ncurses5-config --libs 2>/dev/null;then if ! ncurses-config --libs 2>/dev/null;then echo -lncurses;fi;fi)
 PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 12:51:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 12:51:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVN9T-0001cg-Ul; Tue, 29 Nov 2011 12:51:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVN9S-0001cb-CT
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 12:51:10 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322571032!5497239!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2MzE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzU2MzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27888 invoked from network); 29 Nov 2011 12:50:32 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Nov 2011 12:50:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322571031; l=1048;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=e03v1Zsjd9lFMsUedXA+BUj8UjU=;
	b=mI4EEH3rCGE/NLudmVOonPl0BoPz1XkhUA0t1o1hjmp/zo1YNlx1ba7h1w8V0V0HSy9
	sm3GkQKxY8gcleT0esGqHea1Q1WdXD1VCs60ozkZJkJH9sgSHuCkqH2AB6ogCcfomewf7
	Ykni33D5f7FzpC9Ya+aZMqhWUshUm0+gU2k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJiS0METKc
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-077-220.pools.arcor-ip.net [88.65.77.220])
	by smtp.strato.de (cohen mo33) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c04d9cnATCaxcC ;
	Tue, 29 Nov 2011 13:50:30 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 10C7918637; Tue, 29 Nov 2011 13:50:29 +0100 (CET)
Date: Tue, 29 Nov 2011 13:50:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20111129125029.GA13265@aepfle.de>
References: <20111122113507.GA28412@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111122113507.GA28412@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2] use ncurses-config to find all curses
	related libs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

After a split of libtinfo from libncurses in openSuSE Factory the tools
will not link anymore. In the URL below it was suggested to use
'ncurses-config --libs' to find the correct linker options. But
ncurses-config does not exist neither in SLES11 nor in openSuSE. So
check for both ncurses5-config and ncurses-config, if the latter happens
to exist in other environments.

With this change xen-unstable tools build succeeds again in SLES11 and
the latest openSuSE development branch.

http://lists.opensuse.org/opensuse-packaging/2011-11/msg00055.html

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 4319d77f5b3b config/StdGNU.mk
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -67,7 +67,7 @@ XEN_CONFIG_DIR = $(CONFIG_DIR)/xen
 XEN_SCRIPT_DIR = $(XEN_CONFIG_DIR)/scripts
 
 SOCKET_LIBS =
-CURSES_LIBS = -lncurses
+CURSES_LIBS ?= $(shell if ! ncurses5-config --libs 2>/dev/null;then if ! ncurses-config --libs 2>/dev/null;then echo -lncurses;fi;fi)
 PTHREAD_LIBS = -lpthread
 UTIL_LIBS = -lutil
 DLOPEN_LIBS = -ldl

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 12:55:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 12:55:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVND1-0001jR-Rc; Tue, 29 Nov 2011 12:54:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVND1-0001jH-97
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 12:54:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322571251!3555378!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5977 invoked from network); 29 Nov 2011 12:54:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 12:54:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="19485569"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 07:54:10 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	07:54:10 -0500
Message-ID: <4ED4D5F1.2080000@citrix.com>
Date: Tue, 29 Nov 2011 12:54:09 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ED399A7.1070108@citrix.com> <CAF9A2A8.25D24%keir.xen@gmail.com>
	<20111129055139.GB3222@verge.net.au> <4ED4B8C0.20108@citrix.com>
	<4ED4D1A90200007800064095@nat28.tlf.novell.com>
In-Reply-To: <4ED4D1A90200007800064095@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Simon Horman <horms@verge.net.au>, Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/11 11:35, Jan Beulich wrote:
>>>> On 29.11.11 at 11:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 29/11/11 05:51, Simon Horman wrote:
>>> Hi Keir, Hi Andrew,
>>>
>>> On Mon, Nov 28, 2011 at 08:42:16PM +0000, Keir Fraser wrote:
>>>> On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
>>>> The patch is by Simon Horman, cc'ed, not me.
>> Right.  Sorry.  I should have remembered that basing "who wrote the
>> patch" on a simple hg log was not a safe bet.
> I don't think there's much room for improvement - all members of
> crash_xen_info_t are of "unsigned long" type, but ELF note handling
> will only ever guarantee 4-byte alignment.
>
> Jan
>
Depending on how flexible we want to be, we can either specify that the
name field should be 2n words long plus 1-4 bytes, which will cause it
to align to an odd number of 4 bytes, which will cause the desc field to
be aligned to 8 bytes when the type field in the note header is taken
into account.  Then, the desc field should be constrained to be (2n+1) +
1-4bytes which would cause it to have 8 byte alignment, and subsequently
8 byte align the next note.

Alternatively, we could artificially extend the name up to an odd 4 byte
alignment, and desc field up to 8 byte alignment with trailing \0's and
include this as part of their length fields.  All names should be
processed as Null terminating strings (which wont suffer from having
extra Nulls at the end) and I have yet to see processing of a note which
doesn't take the buffer and cast it to a structure pointer.  This also
wont suffer from from trailing data.

Then again, this does sound like quite a lot of work for not a lot, and
there is no guarantee that we wont break some of the more special code
which works with elf files in 'special' ways.

(What really should have happened was for ELF64 to specify 64bit
alignment of things like this, but we live and learn)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 12:55:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 12:55:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVND1-0001jR-Rc; Tue, 29 Nov 2011 12:54:51 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVND1-0001jH-97
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 12:54:51 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322571251!3555378!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5977 invoked from network); 29 Nov 2011 12:54:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 12:54:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="19485569"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 07:54:10 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	07:54:10 -0500
Message-ID: <4ED4D5F1.2080000@citrix.com>
Date: Tue, 29 Nov 2011 12:54:09 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ED399A7.1070108@citrix.com> <CAF9A2A8.25D24%keir.xen@gmail.com>
	<20111129055139.GB3222@verge.net.au> <4ED4B8C0.20108@citrix.com>
	<4ED4D1A90200007800064095@nat28.tlf.novell.com>
In-Reply-To: <4ED4D1A90200007800064095@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Simon Horman <horms@verge.net.au>, Keir Fraser <keir.xen@gmail.com>
Subject: Re: [Xen-devel] Unaligned writes on the kexec path
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/11 11:35, Jan Beulich wrote:
>>>> On 29.11.11 at 11:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 29/11/11 05:51, Simon Horman wrote:
>>> Hi Keir, Hi Andrew,
>>>
>>> On Mon, Nov 28, 2011 at 08:42:16PM +0000, Keir Fraser wrote:
>>>> On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
>>>> The patch is by Simon Horman, cc'ed, not me.
>> Right.  Sorry.  I should have remembered that basing "who wrote the
>> patch" on a simple hg log was not a safe bet.
> I don't think there's much room for improvement - all members of
> crash_xen_info_t are of "unsigned long" type, but ELF note handling
> will only ever guarantee 4-byte alignment.
>
> Jan
>
Depending on how flexible we want to be, we can either specify that the
name field should be 2n words long plus 1-4 bytes, which will cause it
to align to an odd number of 4 bytes, which will cause the desc field to
be aligned to 8 bytes when the type field in the note header is taken
into account.  Then, the desc field should be constrained to be (2n+1) +
1-4bytes which would cause it to have 8 byte alignment, and subsequently
8 byte align the next note.

Alternatively, we could artificially extend the name up to an odd 4 byte
alignment, and desc field up to 8 byte alignment with trailing \0's and
include this as part of their length fields.  All names should be
processed as Null terminating strings (which wont suffer from having
extra Nulls at the end) and I have yet to see processing of a note which
doesn't take the buffer and cast it to a structure pointer.  This also
wont suffer from from trailing data.

Then again, this does sound like quite a lot of work for not a lot, and
there is no guarantee that we wont break some of the more special code
which works with elf files in 'special' ways.

(What really should have happened was for ELF64 to specify 64bit
alignment of things like this, but we live and learn)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:44:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:44:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVNyR-0002lv-FW; Tue, 29 Nov 2011 13:43:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVNyP-0002lf-Rw
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:43:50 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322574190!5140359!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23000 invoked from network); 29 Nov 2011 13:43:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:43:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172177863"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 08:42:57 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 08:42:57 -0500
MIME-Version: 1.0
X-Mercurial-Node: e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
Message-ID: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 13:42:34 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322574114 0
# Node ID e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
# Parent  225da1242ba979ddc8c48767d3822e0c8d274ae1
Convert hvmloader sprintf() into snprintf().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 225da1242ba9 -r e1e952982cf1 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 13:41:54 2011 +0000
@@ -306,7 +306,8 @@ unsigned long new_vm_gid(void)
     buf = mem_alloc(8, 8);
     if (!buf) return 0;
 
-    sprintf(addr, "0x%lx", virt_to_phys(buf));
+    if (snprintf(addr, 11, "0x%lx", virt_to_phys(buf)) >= 11) return 0;
+
     xenstore_write("data/generation-id", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
diff -r 225da1242ba9 -r e1e952982cf1 tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 13:41:54 2011 +0000
@@ -528,7 +528,7 @@ static char *printnum(char *p, unsigned 
     return p;
 }
 
-static void _doprint(void (*emit)(char**, char), char **arg, const char *fmt, va_list ap)
+static void _doprint(void (*emit)(void *, char), void *arg, const char *fmt, va_list ap)
 {
     char *str, c;
     int lflag, zflag, nflag;
@@ -626,7 +626,7 @@ static void putchar(char c)
     outb(0xe9, c);
 }
 
-static void __put(char **ignore, char c)
+static void __put(void *arg, char c)
 {
     putchar(c);
 }
@@ -648,22 +648,42 @@ int vprintf(const char *fmt, va_list ap)
     return 0;
 }
 
-static void __copy(char **buf, char c)
+struct __copy_context {
+    char *ptr;
+    size_t emitted;
+    size_t remaining;
+};
+
+static void __copy(void *arg, char c)
 {
-    **buf = c;
-    (*buf)++;
+    struct __copy_context *ctxt = arg;
+
+    ctxt->emitted++;
+
+    if (ctxt->remaining == 0)
+        return;
+    
+    *(ctxt->ptr++) = c;
+    --ctxt->remaining;
 }
 
-int sprintf(char *buf, const char *fmt, ...)
+int snprintf(char *buf, size_t size, const char *fmt, ...)
 {
     va_list ap;
+    struct __copy_context ctxt;
+
+    ctxt.ptr = buf;
+    ctxt.emitted = 0;
+    ctxt.remaining = size;
 
     va_start(ap, fmt);
-    _doprint(__copy, &buf, fmt, ap);
+    _doprint(__copy, &ctxt, fmt, ap);
     va_end(ap);
 
-    *buf = '\0';
-    return 0;
+    if (ctxt.remaining != 0)
+        *ctxt.ptr = '\0';
+
+    return ctxt.emitted;
 }
 
 static void __attribute__((noreturn)) crash(void)
diff -r 225da1242ba9 -r e1e952982cf1 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 13:41:54 2011 +0000
@@ -172,7 +172,8 @@ int printf(const char *fmt, ...) __attri
 int vprintf(const char *fmt, va_list ap);
 
 /* Buffer output */
-int sprintf(char *buf, const char *fmt, ...) __attribute__ ((format (printf, 2, 3)));
+typedef unsigned long size_t;
+int snprintf(char *buf, size_t size, const char *fmt, ...) __attribute__ ((format (printf, 3, 4)));
 
 /* Populate specified memory hole with RAM. */
 void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:44:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:44:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVNyR-0002lv-FW; Tue, 29 Nov 2011 13:43:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVNyP-0002lf-Rw
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:43:50 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322574190!5140359!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23000 invoked from network); 29 Nov 2011 13:43:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:43:12 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172177863"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 08:42:57 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 08:42:57 -0500
MIME-Version: 1.0
X-Mercurial-Node: e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
Message-ID: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 13:42:34 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322574114 0
# Node ID e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
# Parent  225da1242ba979ddc8c48767d3822e0c8d274ae1
Convert hvmloader sprintf() into snprintf().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 225da1242ba9 -r e1e952982cf1 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 13:41:54 2011 +0000
@@ -306,7 +306,8 @@ unsigned long new_vm_gid(void)
     buf = mem_alloc(8, 8);
     if (!buf) return 0;
 
-    sprintf(addr, "0x%lx", virt_to_phys(buf));
+    if (snprintf(addr, 11, "0x%lx", virt_to_phys(buf)) >= 11) return 0;
+
     xenstore_write("data/generation-id", addr);
 
     gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
diff -r 225da1242ba9 -r e1e952982cf1 tools/firmware/hvmloader/util.c
--- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 13:41:54 2011 +0000
@@ -528,7 +528,7 @@ static char *printnum(char *p, unsigned 
     return p;
 }
 
-static void _doprint(void (*emit)(char**, char), char **arg, const char *fmt, va_list ap)
+static void _doprint(void (*emit)(void *, char), void *arg, const char *fmt, va_list ap)
 {
     char *str, c;
     int lflag, zflag, nflag;
@@ -626,7 +626,7 @@ static void putchar(char c)
     outb(0xe9, c);
 }
 
-static void __put(char **ignore, char c)
+static void __put(void *arg, char c)
 {
     putchar(c);
 }
@@ -648,22 +648,42 @@ int vprintf(const char *fmt, va_list ap)
     return 0;
 }
 
-static void __copy(char **buf, char c)
+struct __copy_context {
+    char *ptr;
+    size_t emitted;
+    size_t remaining;
+};
+
+static void __copy(void *arg, char c)
 {
-    **buf = c;
-    (*buf)++;
+    struct __copy_context *ctxt = arg;
+
+    ctxt->emitted++;
+
+    if (ctxt->remaining == 0)
+        return;
+    
+    *(ctxt->ptr++) = c;
+    --ctxt->remaining;
 }
 
-int sprintf(char *buf, const char *fmt, ...)
+int snprintf(char *buf, size_t size, const char *fmt, ...)
 {
     va_list ap;
+    struct __copy_context ctxt;
+
+    ctxt.ptr = buf;
+    ctxt.emitted = 0;
+    ctxt.remaining = size;
 
     va_start(ap, fmt);
-    _doprint(__copy, &buf, fmt, ap);
+    _doprint(__copy, &ctxt, fmt, ap);
     va_end(ap);
 
-    *buf = '\0';
-    return 0;
+    if (ctxt.remaining != 0)
+        *ctxt.ptr = '\0';
+
+    return ctxt.emitted;
 }
 
 static void __attribute__((noreturn)) crash(void)
diff -r 225da1242ba9 -r e1e952982cf1 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Nov 29 10:48:54 2011 +0000
+++ b/tools/firmware/hvmloader/util.h	Tue Nov 29 13:41:54 2011 +0000
@@ -172,7 +172,8 @@ int printf(const char *fmt, ...) __attri
 int vprintf(const char *fmt, va_list ap);
 
 /* Buffer output */
-int sprintf(char *buf, const char *fmt, ...) __attribute__ ((format (printf, 2, 3)));
+typedef unsigned long size_t;
+int snprintf(char *buf, size_t size, const char *fmt, ...) __attribute__ ((format (printf, 3, 4)));
 
 /* Populate specified memory hole with RAM. */
 void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:47:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO1g-0002tm-Fw; Tue, 29 Nov 2011 13:47:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVO1e-0002tQ-F2
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:47:10 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322574390!5485944!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17910 invoked from network); 29 Nov 2011 13:46:31 -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;
	29 Nov 2011 13:46:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172178241"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 08:46:30 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 08:46:30 -0500
MIME-Version: 1.0
X-Mercurial-Node: 54213a49fda417510155ce7fc548c4d6093fe45e
Message-ID: <54213a49fda417510155.1322574373@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 13:46:13 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] [mq]: fix-xenbus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322574219 0
# Node ID 54213a49fda417510155ce7fc548c4d6093fe45e
# Parent  e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
[mq]: fix-xenbus

diff -r e1e952982cf1 -r 54213a49fda4 tools/firmware/hvmloader/xenbus.c
--- a/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:41:54 2011 +0000
+++ b/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:43:39 2011 +0000
@@ -143,7 +143,7 @@ static void ring_read(char *data, uint32
     }
 }
 
-#define MAX_SEGMENTS    3
+#define MAX_SEGMENTS    4
 
 /* Send a request. */
 static void xenbus_send(uint32_t type, ...)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:47:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:47:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO1g-0002tm-Fw; Tue, 29 Nov 2011 13:47:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVO1e-0002tQ-F2
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:47:10 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322574390!5485944!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17910 invoked from network); 29 Nov 2011 13:46:31 -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;
	29 Nov 2011 13:46:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172178241"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 08:46:30 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 08:46:30 -0500
MIME-Version: 1.0
X-Mercurial-Node: 54213a49fda417510155ce7fc548c4d6093fe45e
Message-ID: <54213a49fda417510155.1322574373@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 13:46:13 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] [mq]: fix-xenbus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322574219 0
# Node ID 54213a49fda417510155ce7fc548c4d6093fe45e
# Parent  e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
[mq]: fix-xenbus

diff -r e1e952982cf1 -r 54213a49fda4 tools/firmware/hvmloader/xenbus.c
--- a/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:41:54 2011 +0000
+++ b/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:43:39 2011 +0000
@@ -143,7 +143,7 @@ static void ring_read(char *data, uint32
     }
 }
 
-#define MAX_SEGMENTS    3
+#define MAX_SEGMENTS    4
 
 /* Send a request. */
 static void xenbus_send(uint32_t type, ...)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:47:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO1Z-0002tR-32; Tue, 29 Nov 2011 13:47:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVO1X-0002tB-OD
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322574386!5141941!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13316 invoked from network); 29 Nov 2011 13:46:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:46:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9185911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 13:46:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 13:46:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 13:46:25 +0000
In-Reply-To: <6da8c30fb198adc15136.1322568063@cosworth.uk.xensource.com>
References: <6da8c30fb198adc15136.1322568063@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322574386.31810.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] docs: XenBus page has been transfered to
 new wiki
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 12:01 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1322568055 0
> # Node ID 6da8c30fb198adc15136a867a8303b7de3804bcf
> # Parent  fa9deee858b84d4c4fbb5f9523fa5adb7aac3a35
> docs: XenBus page has been transfered to new wiki
> 
> Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>
> 
> diff -r fa9deee858b8 -r 6da8c30fb198 docs/misc/xenstore.txt
> --- a/docs/misc/xenstore.txt	Tue Nov 29 11:07:59 2011 +0000
> +++ b/docs/misc/xenstore.txt	Tue Nov 29 12:00:55 2011 +0000
> @@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
>  		r<domid>	read only
>  		b<domid>	both read and write
>  		n<domid>	no access
> -	See http://wiki.xensource.com/xenwiki/XenBus section
> +	See http://wiki.xensource.com/wiki/XenBus section

Should s/xensource.com/xen.org/ while I'm here...

8<-------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322574371 0
# Node ID c867ef177c1f9ac2735f559dec24ff33f270ecb7
# Parent  fa9deee858b84d4c4fbb5f9523fa5adb7aac3a35
docs: XenBus page has been transfered to new wiki

Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>

diff -r fa9deee858b8 -r c867ef177c1f docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt	Tue Nov 29 11:07:59 2011 +0000
+++ b/docs/misc/xenstore.txt	Tue Nov 29 13:46:11 2011 +0000
@@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
 		r<domid>	read only
 		b<domid>	both read and write
 		n<domid>	no access
-	See http://wiki.xensource.com/xenwiki/XenBus section
+	See http://wiki.xen.org/wiki/XenBus section
 	`Permissions' for details of the permissions system.
 
 ---------- Watches ----------



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:47:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO1Z-0002tR-32; Tue, 29 Nov 2011 13:47:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVO1X-0002tB-OD
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322574386!5141941!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13316 invoked from network); 29 Nov 2011 13:46:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:46:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9185911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 13:46:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 13:46:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 13:46:25 +0000
In-Reply-To: <6da8c30fb198adc15136.1322568063@cosworth.uk.xensource.com>
References: <6da8c30fb198adc15136.1322568063@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322574386.31810.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] docs: XenBus page has been transfered to
 new wiki
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 12:01 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1322568055 0
> # Node ID 6da8c30fb198adc15136a867a8303b7de3804bcf
> # Parent  fa9deee858b84d4c4fbb5f9523fa5adb7aac3a35
> docs: XenBus page has been transfered to new wiki
> 
> Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>
> 
> diff -r fa9deee858b8 -r 6da8c30fb198 docs/misc/xenstore.txt
> --- a/docs/misc/xenstore.txt	Tue Nov 29 11:07:59 2011 +0000
> +++ b/docs/misc/xenstore.txt	Tue Nov 29 12:00:55 2011 +0000
> @@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
>  		r<domid>	read only
>  		b<domid>	both read and write
>  		n<domid>	no access
> -	See http://wiki.xensource.com/xenwiki/XenBus section
> +	See http://wiki.xensource.com/wiki/XenBus section

Should s/xensource.com/xen.org/ while I'm here...

8<-------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322574371 0
# Node ID c867ef177c1f9ac2735f559dec24ff33f270ecb7
# Parent  fa9deee858b84d4c4fbb5f9523fa5adb7aac3a35
docs: XenBus page has been transfered to new wiki

Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>

diff -r fa9deee858b8 -r c867ef177c1f docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt	Tue Nov 29 11:07:59 2011 +0000
+++ b/docs/misc/xenstore.txt	Tue Nov 29 13:46:11 2011 +0000
@@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
 		r<domid>	read only
 		b<domid>	both read and write
 		n<domid>	no access
-	See http://wiki.xensource.com/xenwiki/XenBus section
+	See http://wiki.xen.org/wiki/XenBus section
 	`Permissions' for details of the permissions system.
 
 ---------- Watches ----------



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:47:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO24-0002wy-UC; Tue, 29 Nov 2011 13:47:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVO24-0002vz-5b
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:47:36 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322574417!3555000!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22709 invoked from network); 29 Nov 2011 13:46:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:46:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172178287"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 08:46:56 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 08:46:57 -0500
MIME-Version: 1.0
X-Mercurial-Node: 51692288a6e84c941f9e5049c73b7246bab97f70
Message-ID: <51692288a6e84c941f9e.1322574410@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 13:46:50 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix hvmloader xenbus segment array length
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322574403 0
# Node ID 51692288a6e84c941f9e5049c73b7246bab97f70
# Parent  e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
Fix hvmloader xenbus segment array length.

c/s acc408d667e1 had this one too short for handling a write. This
incremental patch rectifies the problem.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r e1e952982cf1 -r 51692288a6e8 tools/firmware/hvmloader/xenbus.c
--- a/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:41:54 2011 +0000
+++ b/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:46:43 2011 +0000
@@ -143,7 +143,7 @@ static void ring_read(char *data, uint32
     }
 }
 
-#define MAX_SEGMENTS    3
+#define MAX_SEGMENTS    4
 
 /* Send a request. */
 static void xenbus_send(uint32_t type, ...)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:47:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO24-0002wy-UC; Tue, 29 Nov 2011 13:47:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVO24-0002vz-5b
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:47:36 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322574417!3555000!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22709 invoked from network); 29 Nov 2011 13:46:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:46:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="172178287"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 08:46:56 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 08:46:57 -0500
MIME-Version: 1.0
X-Mercurial-Node: 51692288a6e84c941f9e5049c73b7246bab97f70
Message-ID: <51692288a6e84c941f9e.1322574410@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 13:46:50 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Fix hvmloader xenbus segment array length
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322574403 0
# Node ID 51692288a6e84c941f9e5049c73b7246bab97f70
# Parent  e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
Fix hvmloader xenbus segment array length.

c/s acc408d667e1 had this one too short for handling a write. This
incremental patch rectifies the problem.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r e1e952982cf1 -r 51692288a6e8 tools/firmware/hvmloader/xenbus.c
--- a/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:41:54 2011 +0000
+++ b/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:46:43 2011 +0000
@@ -143,7 +143,7 @@ static void ring_read(char *data, uint32
     }
 }
 
-#define MAX_SEGMENTS    3
+#define MAX_SEGMENTS    4
 
 /* Send a request. */
 static void xenbus_send(uint32_t type, ...)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:53:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:53:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO7c-0003Sv-PG; Tue, 29 Nov 2011 13:53:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVO7b-0003Sc-N0
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:53:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322574761!3541414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24854 invoked from network); 29 Nov 2011 13:52:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:52:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186082"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 13:52:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 13:52:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 13:52:40 +0000
In-Reply-To: <1322574386.31810.3.camel@zakaz.uk.xensource.com>
References: <6da8c30fb198adc15136.1322568063@cosworth.uk.xensource.com>
	<1322574386.31810.3.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322574760.31810.4.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] docs: XenBus page has been transfered to
 new wiki
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 13:46 +0000, Ian Campbell wrote:
> On Tue, 2011-11-29 at 12:01 +0000, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1322568055 0
> > # Node ID 6da8c30fb198adc15136a867a8303b7de3804bcf
> > # Parent  fa9deee858b84d4c4fbb5f9523fa5adb7aac3a35
> > docs: XenBus page has been transfered to new wiki
> > 
> > Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>
> > 
> > diff -r fa9deee858b8 -r 6da8c30fb198 docs/misc/xenstore.txt
> > --- a/docs/misc/xenstore.txt	Tue Nov 29 11:07:59 2011 +0000
> > +++ b/docs/misc/xenstore.txt	Tue Nov 29 12:00:55 2011 +0000
> > @@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
> >  		r<domid>	read only
> >  		b<domid>	both read and write
> >  		n<domid>	no access
> > -	See http://wiki.xensource.com/xenwiki/XenBus section
> > +	See http://wiki.xensource.com/wiki/XenBus section
> 
> Should s/xensource.com/xen.org/ while I'm here...

Scratch that: I'll fold this into my "Replace references to old wiki
with ones to new" which also needs to switch to wiki.xen.org as well.
I'll send an updated version of that patch shortly...

Ian.

> 
> 8<-------------------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1322574371 0
> # Node ID c867ef177c1f9ac2735f559dec24ff33f270ecb7
> # Parent  fa9deee858b84d4c4fbb5f9523fa5adb7aac3a35
> docs: XenBus page has been transfered to new wiki
> 
> Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>
> 
> diff -r fa9deee858b8 -r c867ef177c1f docs/misc/xenstore.txt
> --- a/docs/misc/xenstore.txt	Tue Nov 29 11:07:59 2011 +0000
> +++ b/docs/misc/xenstore.txt	Tue Nov 29 13:46:11 2011 +0000
> @@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
>  		r<domid>	read only
>  		b<domid>	both read and write
>  		n<domid>	no access
> -	See http://wiki.xensource.com/xenwiki/XenBus section
> +	See http://wiki.xen.org/wiki/XenBus section
>  	`Permissions' for details of the permissions system.
>  
>  ---------- Watches ----------
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:53:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:53:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO7c-0003Sv-PG; Tue, 29 Nov 2011 13:53:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVO7b-0003Sc-N0
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:53:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322574761!3541414!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24854 invoked from network); 29 Nov 2011 13:52:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:52:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186082"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 13:52:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 13:52:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 13:52:40 +0000
In-Reply-To: <1322574386.31810.3.camel@zakaz.uk.xensource.com>
References: <6da8c30fb198adc15136.1322568063@cosworth.uk.xensource.com>
	<1322574386.31810.3.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322574760.31810.4.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] docs: XenBus page has been transfered to
 new wiki
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 13:46 +0000, Ian Campbell wrote:
> On Tue, 2011-11-29 at 12:01 +0000, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1322568055 0
> > # Node ID 6da8c30fb198adc15136a867a8303b7de3804bcf
> > # Parent  fa9deee858b84d4c4fbb5f9523fa5adb7aac3a35
> > docs: XenBus page has been transfered to new wiki
> > 
> > Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>
> > 
> > diff -r fa9deee858b8 -r 6da8c30fb198 docs/misc/xenstore.txt
> > --- a/docs/misc/xenstore.txt	Tue Nov 29 11:07:59 2011 +0000
> > +++ b/docs/misc/xenstore.txt	Tue Nov 29 12:00:55 2011 +0000
> > @@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
> >  		r<domid>	read only
> >  		b<domid>	both read and write
> >  		n<domid>	no access
> > -	See http://wiki.xensource.com/xenwiki/XenBus section
> > +	See http://wiki.xensource.com/wiki/XenBus section
> 
> Should s/xensource.com/xen.org/ while I'm here...

Scratch that: I'll fold this into my "Replace references to old wiki
with ones to new" which also needs to switch to wiki.xen.org as well.
I'll send an updated version of that patch shortly...

Ian.

> 
> 8<-------------------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1322574371 0
> # Node ID c867ef177c1f9ac2735f559dec24ff33f270ecb7
> # Parent  fa9deee858b84d4c4fbb5f9523fa5adb7aac3a35
> docs: XenBus page has been transfered to new wiki
> 
> Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>
> 
> diff -r fa9deee858b8 -r c867ef177c1f docs/misc/xenstore.txt
> --- a/docs/misc/xenstore.txt	Tue Nov 29 11:07:59 2011 +0000
> +++ b/docs/misc/xenstore.txt	Tue Nov 29 13:46:11 2011 +0000
> @@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
>  		r<domid>	read only
>  		b<domid>	both read and write
>  		n<domid>	no access
> -	See http://wiki.xensource.com/xenwiki/XenBus section
> +	See http://wiki.xen.org/wiki/XenBus section
>  	`Permissions' for details of the permissions system.
>  
>  ---------- Watches ----------
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:55:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:55:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO9U-0003Yv-FI; Tue, 29 Nov 2011 13:55:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVO9T-0003Yb-84
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:55:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322574876!3560794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31714 invoked from network); 29 Nov 2011 13:54:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186129"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 13:54:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 13:54:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 13:54:35 +0000
In-Reply-To: <732154549538fe983a8c.1322232573@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<732154549538fe983a8c.1322232573@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322574875.31810.5.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 01 of 15 v2] Replace references to old wiki
 with ones to new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 14:49 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1322221956 0
> # Node ID 732154549538fe983a8cc6ea74605e04e8ea0a64
> # Parent  1027e7d13d02143048c7d48d7960967c5b1657a8
> Replace references to old wiki with ones to new.

Updated version switches the XenBus page too and also switches
everything to wiki.xen.org instead of the xensource.com address. Please
use this instead.

8<-----------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322574811 0
# Node ID 4bdc0f7611d72d80b5d7efedc86fd70df06a6bbc
# Parent  a2cb7ed6d0a2ee5aecb3a988750ce9c8d8b718ee
Replace references to old wiki with ones to new.

I have confirmed that the relevant pages have been transitioned.

What remains is pages which have not yet been moved over:

$ rgrep xenwiki *
tools/libxen/README:http://wiki.xensource.com/xenwiki/XenApi
tools/xenballoon/xenballoond.README:http://wiki.xensource.com/xenwiki/Open_Topics_For_Discussion?action=AttachFile&do=get&target=Memory+Overcommit.pdf

Note that "PythonInXlConfig" never existed in the old wiki and does not exist
in the new. This reference was introduced by 22735:cb94dbe20f97 and was
supposed to have been written prior to the 4.1 release. I have transitioned it
anyway but it's not clear how valuable the message actually is. Perhaps we
should just remove that aspect of it?

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 README
--- a/README	Mon Nov 28 17:42:40 2011 +0000
+++ b/README	Tue Nov 29 13:53:31 2011 +0000
@@ -61,10 +61,10 @@ provided by your OS distributor:
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
 no suitable kernel is available from your OS distributor then refer to
-http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
+http://wiki.xen.org/wiki/XenDom0Kernels for suggestions for
 suitable kernels to use.
 If you are looking to compile a Dom0 kernel from source, please refer to
-http://wiki.xensource.com/xenwiki/XenParavirtOps.
+http://wiki.xen.org/wiki/XenParavirtOps.
 
 [NB. Unless noted otherwise, all the following steps should be
 performed with root privileges.]
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/vtd.txt
--- a/docs/misc/vtd.txt	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/vtd.txt	Tue Nov 29 13:53:31 2011 +0000
@@ -184,7 +184,7 @@ http://www.dell.com/content/products/cat
 - HP Compaq:  DC7800
 http://h10010.www1.hp.com/wwpc/us/en/en/WF04a/12454-12454-64287-321860-3328898.html
 
-For more information, pls refer to http://wiki.xensource.com/xenwiki/VTdHowTo.
+For more information, pls refer to http://wiki.xen.org/wiki/VTdHowTo.
 
 
 Assigning devices to HVM domains
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/xenstore.txt	Tue Nov 29 13:53:31 2011 +0000
@@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
 		r<domid>	read only
 		b<domid>	both read and write
 		n<domid>	no access
-	See http://wiki.xensource.com/xenwiki/XenBus section
+	See http://wiki.xen.org/wiki/XenBus section
 	`Permissions' for details of the permissions system.
 
 ---------- Watches ----------
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/xl-network-configuration.markdown	Tue Nov 29 13:53:31 2011 +0000
@@ -123,4 +123,4 @@ defaults to domain 0. Specifying another
 driver domain which is outside the scope of this document.
 
 [oui]: http://en.wikipedia.org/wiki/Organizationally_Unique_Identifier
-[net]: http://wiki.xen.org/xenwiki/HostConfiguration/Networking
+[net]: http://wiki.xen.org/wiki/HostConfiguration/Networking
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/src/interface.tex
--- a/docs/src/interface.tex	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/src/interface.tex	Tue Nov 29 13:53:31 2011 +0000
@@ -1579,7 +1579,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xen.org/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/src/user.tex
--- a/docs/src/user.tex	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/src/user.tex	Tue Nov 29 13:53:31 2011 +0000
@@ -2349,7 +2349,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xen.org/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Mon Nov 28 17:42:40 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Tue Nov 29 13:53:31 2011 +0000
@@ -72,7 +72,7 @@ static void parse(CfgParseContext *ctx) 
         fputs(
  "warning: Config file looks like it contains Python code.\n"
  "warning:  Arbitrary Python is no longer supported.\n"
- "warning:  See http://wiki.xen.org/xenwiki/PythonInXlConfig\n",
+ "warning:  See http://wiki.xen.org/wiki/PythonInXlConfig\n",
               ctx->cfg->report);
     }
 }
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Nov 28 17:42:40 2011 +0000
+++ b/xen/common/sched_credit2.c	Tue Nov 29 13:53:31 2011 +0000
@@ -51,7 +51,7 @@
 /*
  * WARNING: This is still in an experimental phase.  Status and work can be found at the
  * credit2 wiki page:
- *  http://wiki.xensource.com/xenwiki/Credit2_Scheduler_Development
+ *  http://wiki.xen.org/wiki/Credit2_Scheduler_Development
  * TODO:
  * + Immediate bug-fixes
  *  - Do per-runqueue, grab proper lock for dump debugkey



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:55:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:55:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO9U-0003Yv-FI; Tue, 29 Nov 2011 13:55:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVO9T-0003Yb-84
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:55:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322574876!3560794!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31714 invoked from network); 29 Nov 2011 13:54:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:54:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186129"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 13:54:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 13:54:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 13:54:35 +0000
In-Reply-To: <732154549538fe983a8c.1322232573@cosworth.uk.xensource.com>
References: <patchbomb.1322232572@cosworth.uk.xensource.com>
	<732154549538fe983a8c.1322232573@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322574875.31810.5.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 01 of 15 v2] Replace references to old wiki
 with ones to new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 14:49 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1322221956 0
> # Node ID 732154549538fe983a8cc6ea74605e04e8ea0a64
> # Parent  1027e7d13d02143048c7d48d7960967c5b1657a8
> Replace references to old wiki with ones to new.

Updated version switches the XenBus page too and also switches
everything to wiki.xen.org instead of the xensource.com address. Please
use this instead.

8<-----------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322574811 0
# Node ID 4bdc0f7611d72d80b5d7efedc86fd70df06a6bbc
# Parent  a2cb7ed6d0a2ee5aecb3a988750ce9c8d8b718ee
Replace references to old wiki with ones to new.

I have confirmed that the relevant pages have been transitioned.

What remains is pages which have not yet been moved over:

$ rgrep xenwiki *
tools/libxen/README:http://wiki.xensource.com/xenwiki/XenApi
tools/xenballoon/xenballoond.README:http://wiki.xensource.com/xenwiki/Open_Topics_For_Discussion?action=AttachFile&do=get&target=Memory+Overcommit.pdf

Note that "PythonInXlConfig" never existed in the old wiki and does not exist
in the new. This reference was introduced by 22735:cb94dbe20f97 and was
supposed to have been written prior to the 4.1 release. I have transitioned it
anyway but it's not clear how valuable the message actually is. Perhaps we
should just remove that aspect of it?

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 README
--- a/README	Mon Nov 28 17:42:40 2011 +0000
+++ b/README	Tue Nov 29 13:53:31 2011 +0000
@@ -61,10 +61,10 @@ provided by your OS distributor:
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
 no suitable kernel is available from your OS distributor then refer to
-http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
+http://wiki.xen.org/wiki/XenDom0Kernels for suggestions for
 suitable kernels to use.
 If you are looking to compile a Dom0 kernel from source, please refer to
-http://wiki.xensource.com/xenwiki/XenParavirtOps.
+http://wiki.xen.org/wiki/XenParavirtOps.
 
 [NB. Unless noted otherwise, all the following steps should be
 performed with root privileges.]
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/vtd.txt
--- a/docs/misc/vtd.txt	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/vtd.txt	Tue Nov 29 13:53:31 2011 +0000
@@ -184,7 +184,7 @@ http://www.dell.com/content/products/cat
 - HP Compaq:  DC7800
 http://h10010.www1.hp.com/wwpc/us/en/en/WF04a/12454-12454-64287-321860-3328898.html
 
-For more information, pls refer to http://wiki.xensource.com/xenwiki/VTdHowTo.
+For more information, pls refer to http://wiki.xen.org/wiki/VTdHowTo.
 
 
 Assigning devices to HVM domains
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/xenstore.txt	Tue Nov 29 13:53:31 2011 +0000
@@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
 		r<domid>	read only
 		b<domid>	both read and write
 		n<domid>	no access
-	See http://wiki.xensource.com/xenwiki/XenBus section
+	See http://wiki.xen.org/wiki/XenBus section
 	`Permissions' for details of the permissions system.
 
 ---------- Watches ----------
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/xl-network-configuration.markdown	Tue Nov 29 13:53:31 2011 +0000
@@ -123,4 +123,4 @@ defaults to domain 0. Specifying another
 driver domain which is outside the scope of this document.
 
 [oui]: http://en.wikipedia.org/wiki/Organizationally_Unique_Identifier
-[net]: http://wiki.xen.org/xenwiki/HostConfiguration/Networking
+[net]: http://wiki.xen.org/wiki/HostConfiguration/Networking
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/src/interface.tex
--- a/docs/src/interface.tex	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/src/interface.tex	Tue Nov 29 13:53:31 2011 +0000
@@ -1579,7 +1579,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xen.org/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/src/user.tex
--- a/docs/src/user.tex	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/src/user.tex	Tue Nov 29 13:53:31 2011 +0000
@@ -2349,7 +2349,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xen.org/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Mon Nov 28 17:42:40 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Tue Nov 29 13:53:31 2011 +0000
@@ -72,7 +72,7 @@ static void parse(CfgParseContext *ctx) 
         fputs(
  "warning: Config file looks like it contains Python code.\n"
  "warning:  Arbitrary Python is no longer supported.\n"
- "warning:  See http://wiki.xen.org/xenwiki/PythonInXlConfig\n",
+ "warning:  See http://wiki.xen.org/wiki/PythonInXlConfig\n",
               ctx->cfg->report);
     }
 }
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Nov 28 17:42:40 2011 +0000
+++ b/xen/common/sched_credit2.c	Tue Nov 29 13:53:31 2011 +0000
@@ -51,7 +51,7 @@
 /*
  * WARNING: This is still in an experimental phase.  Status and work can be found at the
  * credit2 wiki page:
- *  http://wiki.xensource.com/xenwiki/Credit2_Scheduler_Development
+ *  http://wiki.xen.org/wiki/Credit2_Scheduler_Development
  * TODO:
  * + Immediate bug-fixes
  *  - Do per-runqueue, grab proper lock for dump debugkey



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:56:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO9s-0003bP-Td; Tue, 29 Nov 2011 13:55:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVO9r-0003aV-C2
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:55:39 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322574476!5413364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15086 invoked from network); 29 Nov 2011 13:47:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:47:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9185951"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 13:47:48 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 29 Nov 2011
	13:47:48 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 13:47:53 +0000
Thread-Topic: [PATCH] [mq]: fix-xenbus
Thread-Index: AcyunU1F0FO4qFb4S6CkQeGh6Uf6vAAABjfg
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4EF6@LONPMAILBOX01.citrite.net>
References: <54213a49fda417510155.1322574373@cosworth.uk.xensource.com>
In-Reply-To: <54213a49fda417510155.1322574373@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] [mq]: fix-xenbus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry. Forgot to qpop/qpush before sending. Follow-up has fixed comment.

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 29 November 2011 13:46
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH] [mq]: fix-xenbus
> 
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1322574219 0 #
> Node ID 54213a49fda417510155ce7fc548c4d6093fe45e
> # Parent  e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
> [mq]: fix-xenbus
> 
> diff -r e1e952982cf1 -r 54213a49fda4
> tools/firmware/hvmloader/xenbus.c
> --- a/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:41:54 2011
> +0000
> +++ b/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:43:39 2011
> +0000
> @@ -143,7 +143,7 @@ static void ring_read(char *data, uint32
>      }
>  }
> 
> -#define MAX_SEGMENTS    3
> +#define MAX_SEGMENTS    4
> 
>  /* Send a request. */
>  static void xenbus_send(uint32_t type, ...)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:56:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVO9s-0003bP-Td; Tue, 29 Nov 2011 13:55:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVO9r-0003aV-C2
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:55:39 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322574476!5413364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15086 invoked from network); 29 Nov 2011 13:47:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:47:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; 
   d="scan'208";a="9185951"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 13:47:48 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 29 Nov 2011
	13:47:48 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 13:47:53 +0000
Thread-Topic: [PATCH] [mq]: fix-xenbus
Thread-Index: AcyunU1F0FO4qFb4S6CkQeGh6Uf6vAAABjfg
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4EF6@LONPMAILBOX01.citrite.net>
References: <54213a49fda417510155.1322574373@cosworth.uk.xensource.com>
In-Reply-To: <54213a49fda417510155.1322574373@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] [mq]: fix-xenbus
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry. Forgot to qpop/qpush before sending. Follow-up has fixed comment.

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 29 November 2011 13:46
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH] [mq]: fix-xenbus
> 
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1322574219 0 #
> Node ID 54213a49fda417510155ce7fc548c4d6093fe45e
> # Parent  e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
> [mq]: fix-xenbus
> 
> diff -r e1e952982cf1 -r 54213a49fda4
> tools/firmware/hvmloader/xenbus.c
> --- a/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:41:54 2011
> +0000
> +++ b/tools/firmware/hvmloader/xenbus.c	Tue Nov 29 13:43:39 2011
> +0000
> @@ -143,7 +143,7 @@ static void ring_read(char *data, uint32
>      }
>  }
> 
> -#define MAX_SEGMENTS    3
> +#define MAX_SEGMENTS    4
> 
>  /* Send a request. */
>  static void xenbus_send(uint32_t type, ...)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:58:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOCC-0003of-Ga; Tue, 29 Nov 2011 13:58:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RVOCB-0003o3-1x
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:58:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322575044!3547293!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23615 invoked from network); 29 Nov 2011 13:57:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:57:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19487016"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 08:57:23 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	08:57:23 -0500
Message-ID: <4ED4E4C1.10605@citrix.com>
Date: Tue, 29 Nov 2011 13:57:21 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
In-Reply-To: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/11 13:42, Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322574114 0
> # Node ID e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
> # Parent  225da1242ba979ddc8c48767d3822e0c8d274ae1
> Convert hvmloader sprintf() into snprintf().
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 225da1242ba9 -r e1e952982cf1 tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 13:41:54 2011 +0000
> @@ -306,7 +306,8 @@ unsigned long new_vm_gid(void)
>      buf = mem_alloc(8, 8);
>      if (!buf) return 0;
>  
> -    sprintf(addr, "0x%lx", virt_to_phys(buf));
> +    if (snprintf(addr, 11, "0x%lx", virt_to_phys(buf)) >= 11) return 0;
> +
>      xenstore_write("data/generation-id", addr);
>  
>      gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
> diff -r 225da1242ba9 -r e1e952982cf1 tools/firmware/hvmloader/util.c
> --- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
> +++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 13:41:54 2011 +0000
> @@ -528,7 +528,7 @@ static char *printnum(char *p, unsigned 
>      return p;
>  }
>  
> -static void _doprint(void (*emit)(char**, char), char **arg, const char *fmt, va_list ap)
> +static void _doprint(void (*emit)(void *, char), void *arg, const char *fmt, va_list ap)
>  {
>      char *str, c;
>      int lflag, zflag, nflag;
> @@ -626,7 +626,7 @@ static void putchar(char c)
>      outb(0xe9, c);
>  }
>  
> -static void __put(char **ignore, char c)
> +static void __put(void *arg, char c)
>  {
>      putchar(c);
>  }
> @@ -648,22 +648,42 @@ int vprintf(const char *fmt, va_list ap)
>      return 0;
>  }
>  
> -static void __copy(char **buf, char c)
> +struct __copy_context {
> +    char *ptr;
> +    size_t emitted;
> +    size_t remaining;
> +};
> +
> +static void __copy(void *arg, char c)
>  {
> -    **buf = c;
> -    (*buf)++;
> +    struct __copy_context *ctxt = arg;
> +
> +    ctxt->emitted++;
> +
> +    if (ctxt->remaining == 0)
> +        return;
> +    
> +    *(ctxt->ptr++) = c;
> +    --ctxt->remaining;
>  }
>  
> -int sprintf(char *buf, const char *fmt, ...)
> +int snprintf(char *buf, size_t size, const char *fmt, ...)
>  {
>      va_list ap;
> +    struct __copy_context ctxt;
> +
> +    ctxt.ptr = buf;
> +    ctxt.emitted = 0;
> +    ctxt.remaining = size;
>  
>      va_start(ap, fmt);
> -    _doprint(__copy, &buf, fmt, ap);
> +    _doprint(__copy, &ctxt, fmt, ap);
>      va_end(ap);
>  
> -    *buf = '\0';
> -    return 0;
> +    if (ctxt.remaining != 0)
> +        *ctxt.ptr = '\0';
> +
> +    return ctxt.emitted;
>  }

This doesn't return the correct value according the C99.  From the
snprintf() man page:

"The functions snprintf() and vsnprintf() do not write  more  than  size
 bytes  (including  the trailing '\0').  If the output was truncated due
 to this limit then the return value is the number  of  characters  (not
 including the trailing '\0') which would have been written to the final
 string if enough space had been available.  Thus,  a  return  value  of
 size  or  more  means  that  the output was truncated."

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 13:58:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 13:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOCC-0003of-Ga; Tue, 29 Nov 2011 13:58:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RVOCB-0003o3-1x
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 13:58:03 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322575044!3547293!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23615 invoked from network); 29 Nov 2011 13:57:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 13:57:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19487016"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 08:57:23 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	08:57:23 -0500
Message-ID: <4ED4E4C1.10605@citrix.com>
Date: Tue, 29 Nov 2011 13:57:21 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
In-Reply-To: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/11 13:42, Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322574114 0
> # Node ID e1e952982cf1d7a0c38a7822a8b5e78ba04b5ba5
> # Parent  225da1242ba979ddc8c48767d3822e0c8d274ae1
> Convert hvmloader sprintf() into snprintf().
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 225da1242ba9 -r e1e952982cf1 tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:54 2011 +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 13:41:54 2011 +0000
> @@ -306,7 +306,8 @@ unsigned long new_vm_gid(void)
>      buf = mem_alloc(8, 8);
>      if (!buf) return 0;
>  
> -    sprintf(addr, "0x%lx", virt_to_phys(buf));
> +    if (snprintf(addr, 11, "0x%lx", virt_to_phys(buf)) >= 11) return 0;
> +
>      xenstore_write("data/generation-id", addr);
>  
>      gid = strtoll(xenstore_read("platform/generation-id", "0"), NULL, 0);
> diff -r 225da1242ba9 -r e1e952982cf1 tools/firmware/hvmloader/util.c
> --- a/tools/firmware/hvmloader/util.c	Tue Nov 29 10:48:54 2011 +0000
> +++ b/tools/firmware/hvmloader/util.c	Tue Nov 29 13:41:54 2011 +0000
> @@ -528,7 +528,7 @@ static char *printnum(char *p, unsigned 
>      return p;
>  }
>  
> -static void _doprint(void (*emit)(char**, char), char **arg, const char *fmt, va_list ap)
> +static void _doprint(void (*emit)(void *, char), void *arg, const char *fmt, va_list ap)
>  {
>      char *str, c;
>      int lflag, zflag, nflag;
> @@ -626,7 +626,7 @@ static void putchar(char c)
>      outb(0xe9, c);
>  }
>  
> -static void __put(char **ignore, char c)
> +static void __put(void *arg, char c)
>  {
>      putchar(c);
>  }
> @@ -648,22 +648,42 @@ int vprintf(const char *fmt, va_list ap)
>      return 0;
>  }
>  
> -static void __copy(char **buf, char c)
> +struct __copy_context {
> +    char *ptr;
> +    size_t emitted;
> +    size_t remaining;
> +};
> +
> +static void __copy(void *arg, char c)
>  {
> -    **buf = c;
> -    (*buf)++;
> +    struct __copy_context *ctxt = arg;
> +
> +    ctxt->emitted++;
> +
> +    if (ctxt->remaining == 0)
> +        return;
> +    
> +    *(ctxt->ptr++) = c;
> +    --ctxt->remaining;
>  }
>  
> -int sprintf(char *buf, const char *fmt, ...)
> +int snprintf(char *buf, size_t size, const char *fmt, ...)
>  {
>      va_list ap;
> +    struct __copy_context ctxt;
> +
> +    ctxt.ptr = buf;
> +    ctxt.emitted = 0;
> +    ctxt.remaining = size;
>  
>      va_start(ap, fmt);
> -    _doprint(__copy, &buf, fmt, ap);
> +    _doprint(__copy, &ctxt, fmt, ap);
>      va_end(ap);
>  
> -    *buf = '\0';
> -    return 0;
> +    if (ctxt.remaining != 0)
> +        *ctxt.ptr = '\0';
> +
> +    return ctxt.emitted;
>  }

This doesn't return the correct value according the C99.  From the
snprintf() man page:

"The functions snprintf() and vsnprintf() do not write  more  than  size
 bytes  (including  the trailing '\0').  If the output was truncated due
 to this limit then the return value is the number  of  characters  (not
 including the trailing '\0') which would have been written to the final
 string if enough space had been available.  Thus,  a  return  value  of
 size  or  more  means  that  the output was truncated."

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:04:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:04:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOHl-0004D4-A8; Tue, 29 Nov 2011 14:03:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVOHj-0004Cq-HZ
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:03:47 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322575390!4264887!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20810 invoked from network); 29 Nov 2011 14:03:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:03:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 29 Nov 2011
	14:03:10 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 29 Nov 2011 14:03:16 +0000
Thread-Topic: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
Thread-Index: AcyuntKqW+lhfGfIQSi6MH5NeqMA/QAAJXrg
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4F02@LONPMAILBOX01.citrite.net>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
	<4ED4E4C1.10605@citrix.com>
In-Reply-To: <4ED4E4C1.10605@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> This doesn't return the correct value according the C99.  From the
> snprintf() man page:
> 
> "The functions snprintf() and vsnprintf() do not write  more  than
> size  bytes  (including  the trailing '\0').  If the output was
> truncated due  to this limit then the return value is the number  of
> characters  (not  including the trailing '\0') which would have been
> written to the final  string if enough space had been available.
> Thus,  a  return  value  of  size  or  more  means  that  the output
> was truncated."
> 

...and that matters because? I didn't say anywhere that the implementation was C99 compliant.

  Paul


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:04:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:04:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOHl-0004D4-A8; Tue, 29 Nov 2011 14:03:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVOHj-0004Cq-HZ
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:03:47 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322575390!4264887!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20810 invoked from network); 29 Nov 2011 14:03:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:03:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 29 Nov 2011
	14:03:10 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 29 Nov 2011 14:03:16 +0000
Thread-Topic: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
Thread-Index: AcyuntKqW+lhfGfIQSi6MH5NeqMA/QAAJXrg
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4F02@LONPMAILBOX01.citrite.net>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
	<4ED4E4C1.10605@citrix.com>
In-Reply-To: <4ED4E4C1.10605@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> This doesn't return the correct value according the C99.  From the
> snprintf() man page:
> 
> "The functions snprintf() and vsnprintf() do not write  more  than
> size  bytes  (including  the trailing '\0').  If the output was
> truncated due  to this limit then the return value is the number  of
> characters  (not  including the trailing '\0') which would have been
> written to the final  string if enough space had been available.
> Thus,  a  return  value  of  size  or  more  means  that  the output
> was truncated."
> 

...and that matters because? I didn't say anywhere that the implementation was C99 compliant.

  Paul


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:05:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:05:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOJ9-0004HB-Q4; Tue, 29 Nov 2011 14:05:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVOJ8-0004H2-6f
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:05:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322575475!5422761!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21801 invoked from network); 29 Nov 2011 14:04:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:04:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186405"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:04:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 14:04:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVOIV-0003hA-K3; Tue, 29 Nov 2011 14:04:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVOIV-0002SF-Fv;
	Tue, 29 Nov 2011 14:04:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20180.58995.480262.215965@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 14:04:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322563538.20646.36.camel@zakaz.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
	<20179.47462.815671.301622@mariner.uk.xensource.com>
	<1322563538.20646.36.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
 after	statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration after	statement"):
> Variable declarations should either be at the top of the function or
> immediately before / as part of the block which uses them. e.g. this is
> unhelpful:

I agree..

> void a_func(void)
> {
> 	/* a bunch of code; */
> 
> 	int bar;
> 
> 	/* a bunch more code not using bar */
> 
> 	bar = get_me_a_bar();
> 
> 	/* use bar lots */
> }

Yes, but would anyone really write that ?  I think the argument is
about this:

 	/* a bunch of code; */
 
 	int bar = get_me_a_bar();
 
 	/* use bar lots */

I think this is fine and I think Stefano objects.

How about:

  Declarations of automatic variables should either be at the start of
  the relevant function (or block), or as late as reasonable; in the
  latter case they should be initialised in the declaration if
  possible.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:05:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:05:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOJ9-0004HB-Q4; Tue, 29 Nov 2011 14:05:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVOJ8-0004H2-6f
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:05:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322575475!5422761!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21801 invoked from network); 29 Nov 2011 14:04:36 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:04:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186405"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:04:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 14:04:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVOIV-0003hA-K3; Tue, 29 Nov 2011 14:04:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVOIV-0002SF-Fv;
	Tue, 29 Nov 2011 14:04:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20180.58995.480262.215965@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 14:04:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1322563538.20646.36.camel@zakaz.uk.xensource.com>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
	<20179.47462.815671.301622@mariner.uk.xensource.com>
	<1322563538.20646.36.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
 after	statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration after	statement"):
> Variable declarations should either be at the top of the function or
> immediately before / as part of the block which uses them. e.g. this is
> unhelpful:

I agree..

> void a_func(void)
> {
> 	/* a bunch of code; */
> 
> 	int bar;
> 
> 	/* a bunch more code not using bar */
> 
> 	bar = get_me_a_bar();
> 
> 	/* use bar lots */
> }

Yes, but would anyone really write that ?  I think the argument is
about this:

 	/* a bunch of code; */
 
 	int bar = get_me_a_bar();
 
 	/* use bar lots */

I think this is fine and I think Stefano objects.

How about:

  Declarations of automatic variables should either be at the start of
  the relevant function (or block), or as late as reasonable; in the
  latter case they should be initialised in the declaration if
  possible.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:11:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOOr-0004Rw-MP; Tue, 29 Nov 2011 14:11:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RVOOq-0004Rl-Fq
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:11:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322575829!5473922!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23224 invoked from network); 29 Nov 2011 14:10:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19487963"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:10:29 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	09:10:29 -0500
Message-ID: <4ED4E7D3.2020604@citrix.com>
Date: Tue, 29 Nov 2011 14:10:27 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
	<4ED4E4C1.10605@citrix.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4F02@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4F02@LONPMAILBOX01.citrite.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/11 14:03, Paul Durrant wrote:
>>
>> This doesn't return the correct value according the C99.  From the
>> snprintf() man page:
>>
>> "The functions snprintf() and vsnprintf() do not write  more  than
>> size  bytes  (including  the trailing '\0').  If the output was
>> truncated due  to this limit then the return value is the number  of
>> characters  (not  including the trailing '\0') which would have been
>> written to the final  string if enough space had been available.
>> Thus,  a  return  value  of  size  or  more  means  that  the output
>> was truncated."
>>
> 
> ...and that matters because? I didn't say anywhere that the implementation was C99 compliant.

I suggest giving it a different name then.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:11:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOOr-0004Rw-MP; Tue, 29 Nov 2011 14:11:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RVOOq-0004Rl-Fq
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:11:08 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322575829!5473922!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23224 invoked from network); 29 Nov 2011 14:10:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:10:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19487963"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:10:29 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	09:10:29 -0500
Message-ID: <4ED4E7D3.2020604@citrix.com>
Date: Tue, 29 Nov 2011 14:10:27 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
	<4ED4E4C1.10605@citrix.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4F02@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4F02@LONPMAILBOX01.citrite.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/11 14:03, Paul Durrant wrote:
>>
>> This doesn't return the correct value according the C99.  From the
>> snprintf() man page:
>>
>> "The functions snprintf() and vsnprintf() do not write  more  than
>> size  bytes  (including  the trailing '\0').  If the output was
>> truncated due  to this limit then the return value is the number  of
>> characters  (not  including the trailing '\0') which would have been
>> written to the final  string if enough space had been available.
>> Thus,  a  return  value  of  size  or  more  means  that  the output
>> was truncated."
>>
> 
> ...and that matters because? I didn't say anywhere that the implementation was C99 compliant.

I suggest giving it a different name then.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:13:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOQo-0004WR-7p; Tue, 29 Nov 2011 14:13:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVOQm-0004WB-En
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:13:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322575950!5465099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4898 invoked from network); 29 Nov 2011 14:12:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:12:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186799"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:12:05 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 29 Nov 2011
	14:12:05 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 29 Nov 2011 14:12:10 +0000
Thread-Topic: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
Thread-Index: AcyuntKqW+lhfGfIQSi6MH5NeqMA/QAAZyiQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4F0C@LONPMAILBOX01.citrite.net>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
	<4ED4E4C1.10605@citrix.com>
In-Reply-To: <4ED4E4C1.10605@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: David Vrabel
> Sent: 29 November 2011 13:57
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into
> snprintf()
> 
[snip]
> > +static void __copy(void *arg, char c)
> >  {
> > -    **buf = c;
> > -    (*buf)++;
> > +    struct __copy_context *ctxt = arg;
> > +
> > +    ctxt->emitted++;
> > +
> > +    if (ctxt->remaining == 0)
> > +        return;
> > +
> > +    *(ctxt->ptr++) = c;
> > +    --ctxt->remaining;
> >  }
> >
> > -int sprintf(char *buf, const char *fmt, ...)
> > +int snprintf(char *buf, size_t size, const char *fmt, ...)
> >  {
> >      va_list ap;
> > +    struct __copy_context ctxt;
> > +
> > +    ctxt.ptr = buf;
> > +    ctxt.emitted = 0;
> > +    ctxt.remaining = size;
> >
> >      va_start(ap, fmt);
> > -    _doprint(__copy, &buf, fmt, ap);
> > +    _doprint(__copy, &ctxt, fmt, ap);
> >      va_end(ap);
> >
> > -    *buf = '\0';
> > -    return 0;
> > +    if (ctxt.remaining != 0)
> > +        *ctxt.ptr = '\0';
> > +
> > +    return ctxt.emitted;
> >  }
> 
> This doesn't return the correct value according the C99.  From the
> snprintf() man page:
> 
> "The functions snprintf() and vsnprintf() do not write  more  than
> size  bytes  (including  the trailing '\0').  If the output was
> truncated due  to this limit then the return value is the number  of
> characters  (not  including the trailing '\0') which would have been
> written to the final  string if enough space had been available.
> Thus,  a  return  value  of  size  or  more  means  that  the output
> was truncated."
> 

Actually, reading the code again, it is correct isn't it? ctxt.emitted is bumped for every character emitted by _doprint() regardless of whether it makes it into the buffer or not so in an overflow case the value returned will be the number of characters which would have been written not including the nul terminator.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:13:24 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:13:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOQo-0004WR-7p; Tue, 29 Nov 2011 14:13:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVOQm-0004WB-En
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:13:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322575950!5465099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4898 invoked from network); 29 Nov 2011 14:12:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:12:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186799"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:12:05 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 29 Nov 2011
	14:12:05 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 29 Nov 2011 14:12:10 +0000
Thread-Topic: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
Thread-Index: AcyuntKqW+lhfGfIQSi6MH5NeqMA/QAAZyiQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4F0C@LONPMAILBOX01.citrite.net>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
	<4ED4E4C1.10605@citrix.com>
In-Reply-To: <4ED4E4C1.10605@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: David Vrabel
> Sent: 29 November 2011 13:57
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into
> snprintf()
> 
[snip]
> > +static void __copy(void *arg, char c)
> >  {
> > -    **buf = c;
> > -    (*buf)++;
> > +    struct __copy_context *ctxt = arg;
> > +
> > +    ctxt->emitted++;
> > +
> > +    if (ctxt->remaining == 0)
> > +        return;
> > +
> > +    *(ctxt->ptr++) = c;
> > +    --ctxt->remaining;
> >  }
> >
> > -int sprintf(char *buf, const char *fmt, ...)
> > +int snprintf(char *buf, size_t size, const char *fmt, ...)
> >  {
> >      va_list ap;
> > +    struct __copy_context ctxt;
> > +
> > +    ctxt.ptr = buf;
> > +    ctxt.emitted = 0;
> > +    ctxt.remaining = size;
> >
> >      va_start(ap, fmt);
> > -    _doprint(__copy, &buf, fmt, ap);
> > +    _doprint(__copy, &ctxt, fmt, ap);
> >      va_end(ap);
> >
> > -    *buf = '\0';
> > -    return 0;
> > +    if (ctxt.remaining != 0)
> > +        *ctxt.ptr = '\0';
> > +
> > +    return ctxt.emitted;
> >  }
> 
> This doesn't return the correct value according the C99.  From the
> snprintf() man page:
> 
> "The functions snprintf() and vsnprintf() do not write  more  than
> size  bytes  (including  the trailing '\0').  If the output was
> truncated due  to this limit then the return value is the number  of
> characters  (not  including the trailing '\0') which would have been
> written to the final  string if enough space had been available.
> Thus,  a  return  value  of  size  or  more  means  that  the output
> was truncated."
> 

Actually, reading the code again, it is correct isn't it? ctxt.emitted is bumped for every character emitted by _doprint() regardless of whether it makes it into the buffer or not so in an overflow case the value returned will be the number of characters which would have been written not including the nul terminator.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:13:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:13:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVORM-0004Zp-T4; Tue, 29 Nov 2011 14:13:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVORL-0004ZT-9Z
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:13:43 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322575952!45886196!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30917 invoked from network); 29 Nov 2011 14:12:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:12:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186830"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:13:07 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 29 Nov 2011
	14:13:07 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 29 Nov 2011 14:13:12 +0000
Thread-Topic: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
Thread-Index: AcyuoKb627ybseFeRwWxaVDR+d+qsgAAERRw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4F0D@LONPMAILBOX01.citrite.net>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
	<4ED4E4C1.10605@citrix.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4F02@LONPMAILBOX01.citrite.net>
	<4ED4E7D3.2020604@citrix.com>
In-Reply-To: <4ED4E7D3.2020604@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: David Vrabel
[snip]
> >
> > ...and that matters because? I didn't say anywhere that the
> implementation was C99 compliant.
> 
> I suggest giving it a different name then.
> 

Should we change the name of printf() and vprintf() too then?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:13:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:13:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVORM-0004Zp-T4; Tue, 29 Nov 2011 14:13:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVORL-0004ZT-9Z
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:13:43 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322575952!45886196!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30917 invoked from network); 29 Nov 2011 14:12:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:12:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9186830"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:13:07 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 29 Nov 2011
	14:13:07 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 29 Nov 2011 14:13:12 +0000
Thread-Topic: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
Thread-Index: AcyuoKb627ybseFeRwWxaVDR+d+qsgAAERRw
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4F0D@LONPMAILBOX01.citrite.net>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>
	<4ED4E4C1.10605@citrix.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4F02@LONPMAILBOX01.citrite.net>
	<4ED4E7D3.2020604@citrix.com>
In-Reply-To: <4ED4E7D3.2020604@citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: David Vrabel
[snip]
> >
> > ...and that matters because? I didn't say anywhere that the
> implementation was C99 compliant.
> 
> I suggest giving it a different name then.
> 

Should we change the name of printf() and vprintf() too then?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:20:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOXl-00051f-GB; Tue, 29 Nov 2011 14:20:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RVOXk-00051F-Dl
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:20:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322576379!3545593!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29648 invoked from network); 29 Nov 2011 14:19:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:19:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488375"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:19:37 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	09:19:37 -0500
Message-ID: <4ED4E9F8.90208@citrix.com>
Date: Tue, 29 Nov 2011 14:19:36 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>	<4ED4E4C1.10605@citrix.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4F0C@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4F0C@LONPMAILBOX01.citrite.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/11 14:12, Paul Durrant wrote:
>> -----Original Message-----
>> From: David Vrabel
>> Sent: 29 November 2011 13:57
>> To: Paul Durrant
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into
>> snprintf()
>>
> [snip]
>>> +static void __copy(void *arg, char c)
>>>  {
>>> -    **buf = c;
>>> -    (*buf)++;
>>> +    struct __copy_context *ctxt = arg;
>>> +
>>> +    ctxt->emitted++;
>>> +
>>> +    if (ctxt->remaining == 0)
>>> +        return;
>>> +
>>> +    *(ctxt->ptr++) = c;
>>> +    --ctxt->remaining;
>>>  }
>>>
>>> -int sprintf(char *buf, const char *fmt, ...)
>>> +int snprintf(char *buf, size_t size, const char *fmt, ...)
>>>  {
>>>      va_list ap;
>>> +    struct __copy_context ctxt;
>>> +
>>> +    ctxt.ptr = buf;
>>> +    ctxt.emitted = 0;
>>> +    ctxt.remaining = size;
>>>
>>>      va_start(ap, fmt);
>>> -    _doprint(__copy, &buf, fmt, ap);
>>> +    _doprint(__copy, &ctxt, fmt, ap);
>>>      va_end(ap);
>>>
>>> -    *buf = '\0';
>>> -    return 0;
>>> +    if (ctxt.remaining != 0)
>>> +        *ctxt.ptr = '\0';
>>> +
>>> +    return ctxt.emitted;
>>>  }
>>
>> This doesn't return the correct value according the C99.  From the
>> snprintf() man page:
>>
>> "The functions snprintf() and vsnprintf() do not write  more  than
>> size  bytes  (including  the trailing '\0').  If the output was
>> truncated due  to this limit then the return value is the number  of
>> characters  (not  including the trailing '\0') which would have been
>> written to the final  string if enough space had been available.
>> Thus,  a  return  value  of  size  or  more  means  that  the output
>> was truncated."
>>
>
> Actually, reading the code again, it is correct isn't it?
> ctxt.emitted is bumped for every character emitted by _doprint()
> regardless of whether it makes it into the buffer or not so in an
> overflow case the value returned will be the number of characters
> which would have been written not including the nul terminator.

Er. Yes, it is correct. My mistake.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:20:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:20:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOXl-00051f-GB; Tue, 29 Nov 2011 14:20:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RVOXk-00051F-Dl
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:20:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322576379!3545593!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29648 invoked from network); 29 Nov 2011 14:19:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:19:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488375"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:19:37 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	09:19:37 -0500
Message-ID: <4ED4E9F8.90208@citrix.com>
Date: Tue, 29 Nov 2011 14:19:36 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Paul Durrant <Paul.Durrant@citrix.com>
References: <e1e952982cf1d7a0c38a.1322574154@cosworth.uk.xensource.com>	<4ED4E4C1.10605@citrix.com>
	<291EDFCB1E9E224A99088639C4762022B5988E4F0C@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4F0C@LONPMAILBOX01.citrite.net>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into snprintf()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/11 14:12, Paul Durrant wrote:
>> -----Original Message-----
>> From: David Vrabel
>> Sent: 29 November 2011 13:57
>> To: Paul Durrant
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH] Convert hvmloader sprintf() into
>> snprintf()
>>
> [snip]
>>> +static void __copy(void *arg, char c)
>>>  {
>>> -    **buf = c;
>>> -    (*buf)++;
>>> +    struct __copy_context *ctxt = arg;
>>> +
>>> +    ctxt->emitted++;
>>> +
>>> +    if (ctxt->remaining == 0)
>>> +        return;
>>> +
>>> +    *(ctxt->ptr++) = c;
>>> +    --ctxt->remaining;
>>>  }
>>>
>>> -int sprintf(char *buf, const char *fmt, ...)
>>> +int snprintf(char *buf, size_t size, const char *fmt, ...)
>>>  {
>>>      va_list ap;
>>> +    struct __copy_context ctxt;
>>> +
>>> +    ctxt.ptr = buf;
>>> +    ctxt.emitted = 0;
>>> +    ctxt.remaining = size;
>>>
>>>      va_start(ap, fmt);
>>> -    _doprint(__copy, &buf, fmt, ap);
>>> +    _doprint(__copy, &ctxt, fmt, ap);
>>>      va_end(ap);
>>>
>>> -    *buf = '\0';
>>> -    return 0;
>>> +    if (ctxt.remaining != 0)
>>> +        *ctxt.ptr = '\0';
>>> +
>>> +    return ctxt.emitted;
>>>  }
>>
>> This doesn't return the correct value according the C99.  From the
>> snprintf() man page:
>>
>> "The functions snprintf() and vsnprintf() do not write  more  than
>> size  bytes  (including  the trailing '\0').  If the output was
>> truncated due  to this limit then the return value is the number  of
>> characters  (not  including the trailing '\0') which would have been
>> written to the final  string if enough space had been available.
>> Thus,  a  return  value  of  size  or  more  means  that  the output
>> was truncated."
>>
>
> Actually, reading the code again, it is correct isn't it?
> ctxt.emitted is bumped for every character emitted by _doprint()
> regardless of whether it makes it into the buffer or not so in an
> overflow case the value returned will be the number of characters
> which would have been written not including the nul terminator.

Er. Yes, it is correct. My mistake.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYq-000575-QW; Tue, 29 Nov 2011 14:21:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYo-00055g-6Z
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322576446!5152993!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25899 invoked from network); 29 Nov 2011 14:20:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488413"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:46 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0M018170;	Tue, 29 Nov 2011 06:20:45 -0800
MIME-Version: 1.0
X-Mercurial-Node: 4bdc0f7611d72d80b5d7efedc86fd70df06a6bbc
Message-ID: <4bdc0f7611d72d80b5d7.1322576443@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:43 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 01 of 17 v3] Replace references to old wiki with
	ones to new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322574811 0
# Node ID 4bdc0f7611d72d80b5d7efedc86fd70df06a6bbc
# Parent  a2cb7ed6d0a2ee5aecb3a988750ce9c8d8b718ee
Replace references to old wiki with ones to new.

I have confirmed that the relevant pages have been transitioned.

What remains is pages which have not yet been moved over:

$ rgrep xenwiki *
tools/libxen/README:http://wiki.xensource.com/xenwiki/XenApi
tools/xenballoon/xenballoond.README:http://wiki.xensource.com/xenwiki/Open_Topics_For_Discussion?action=AttachFile&do=get&target=Memory+Overcommit.pdf

Note that "PythonInXlConfig" never existed in the old wiki and does not exist
in the new. This reference was introduced by 22735:cb94dbe20f97 and was
supposed to have been written prior to the 4.1 release. I have transitioned it
anyway but it's not clear how valuable the message actually is. Perhaps we
should just remove that aspect of it?

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 README
--- a/README	Mon Nov 28 17:42:40 2011 +0000
+++ b/README	Tue Nov 29 13:53:31 2011 +0000
@@ -61,10 +61,10 @@ provided by your OS distributor:
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
 no suitable kernel is available from your OS distributor then refer to
-http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
+http://wiki.xen.org/wiki/XenDom0Kernels for suggestions for
 suitable kernels to use.
 If you are looking to compile a Dom0 kernel from source, please refer to
-http://wiki.xensource.com/xenwiki/XenParavirtOps.
+http://wiki.xen.org/wiki/XenParavirtOps.
 
 [NB. Unless noted otherwise, all the following steps should be
 performed with root privileges.]
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/vtd.txt
--- a/docs/misc/vtd.txt	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/vtd.txt	Tue Nov 29 13:53:31 2011 +0000
@@ -184,7 +184,7 @@ http://www.dell.com/content/products/cat
 - HP Compaq:  DC7800
 http://h10010.www1.hp.com/wwpc/us/en/en/WF04a/12454-12454-64287-321860-3328898.html
 
-For more information, pls refer to http://wiki.xensource.com/xenwiki/VTdHowTo.
+For more information, pls refer to http://wiki.xen.org/wiki/VTdHowTo.
 
 
 Assigning devices to HVM domains
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/xenstore.txt	Tue Nov 29 13:53:31 2011 +0000
@@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
 		r<domid>	read only
 		b<domid>	both read and write
 		n<domid>	no access
-	See http://wiki.xensource.com/xenwiki/XenBus section
+	See http://wiki.xen.org/wiki/XenBus section
 	`Permissions' for details of the permissions system.
 
 ---------- Watches ----------
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/xl-network-configuration.markdown	Tue Nov 29 13:53:31 2011 +0000
@@ -123,4 +123,4 @@ defaults to domain 0. Specifying another
 driver domain which is outside the scope of this document.
 
 [oui]: http://en.wikipedia.org/wiki/Organizationally_Unique_Identifier
-[net]: http://wiki.xen.org/xenwiki/HostConfiguration/Networking
+[net]: http://wiki.xen.org/wiki/HostConfiguration/Networking
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/src/interface.tex
--- a/docs/src/interface.tex	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/src/interface.tex	Tue Nov 29 13:53:31 2011 +0000
@@ -1579,7 +1579,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xen.org/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/src/user.tex
--- a/docs/src/user.tex	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/src/user.tex	Tue Nov 29 13:53:31 2011 +0000
@@ -2349,7 +2349,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xen.org/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Mon Nov 28 17:42:40 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Tue Nov 29 13:53:31 2011 +0000
@@ -72,7 +72,7 @@ static void parse(CfgParseContext *ctx) 
         fputs(
  "warning: Config file looks like it contains Python code.\n"
  "warning:  Arbitrary Python is no longer supported.\n"
- "warning:  See http://wiki.xen.org/xenwiki/PythonInXlConfig\n",
+ "warning:  See http://wiki.xen.org/wiki/PythonInXlConfig\n",
               ctx->cfg->report);
     }
 }
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Nov 28 17:42:40 2011 +0000
+++ b/xen/common/sched_credit2.c	Tue Nov 29 13:53:31 2011 +0000
@@ -51,7 +51,7 @@
 /*
  * WARNING: This is still in an experimental phase.  Status and work can be found at the
  * credit2 wiki page:
- *  http://wiki.xensource.com/xenwiki/Credit2_Scheduler_Development
+ *  http://wiki.xen.org/wiki/Credit2_Scheduler_Development
  * TODO:
  * + Immediate bug-fixes
  *  - Do per-runqueue, grab proper lock for dump debugkey

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYq-000575-QW; Tue, 29 Nov 2011 14:21:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYo-00055g-6Z
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322576446!5152993!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25899 invoked from network); 29 Nov 2011 14:20:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488413"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:46 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0M018170;	Tue, 29 Nov 2011 06:20:45 -0800
MIME-Version: 1.0
X-Mercurial-Node: 4bdc0f7611d72d80b5d7efedc86fd70df06a6bbc
Message-ID: <4bdc0f7611d72d80b5d7.1322576443@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:43 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 01 of 17 v3] Replace references to old wiki with
	ones to new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322574811 0
# Node ID 4bdc0f7611d72d80b5d7efedc86fd70df06a6bbc
# Parent  a2cb7ed6d0a2ee5aecb3a988750ce9c8d8b718ee
Replace references to old wiki with ones to new.

I have confirmed that the relevant pages have been transitioned.

What remains is pages which have not yet been moved over:

$ rgrep xenwiki *
tools/libxen/README:http://wiki.xensource.com/xenwiki/XenApi
tools/xenballoon/xenballoond.README:http://wiki.xensource.com/xenwiki/Open_Topics_For_Discussion?action=AttachFile&do=get&target=Memory+Overcommit.pdf

Note that "PythonInXlConfig" never existed in the old wiki and does not exist
in the new. This reference was introduced by 22735:cb94dbe20f97 and was
supposed to have been written prior to the 4.1 release. I have transitioned it
anyway but it's not clear how valuable the message actually is. Perhaps we
should just remove that aspect of it?

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 README
--- a/README	Mon Nov 28 17:42:40 2011 +0000
+++ b/README	Tue Nov 29 13:53:31 2011 +0000
@@ -61,10 +61,10 @@ provided by your OS distributor:
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
 no suitable kernel is available from your OS distributor then refer to
-http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
+http://wiki.xen.org/wiki/XenDom0Kernels for suggestions for
 suitable kernels to use.
 If you are looking to compile a Dom0 kernel from source, please refer to
-http://wiki.xensource.com/xenwiki/XenParavirtOps.
+http://wiki.xen.org/wiki/XenParavirtOps.
 
 [NB. Unless noted otherwise, all the following steps should be
 performed with root privileges.]
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/vtd.txt
--- a/docs/misc/vtd.txt	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/vtd.txt	Tue Nov 29 13:53:31 2011 +0000
@@ -184,7 +184,7 @@ http://www.dell.com/content/products/cat
 - HP Compaq:  DC7800
 http://h10010.www1.hp.com/wwpc/us/en/en/WF04a/12454-12454-64287-321860-3328898.html
 
-For more information, pls refer to http://wiki.xensource.com/xenwiki/VTdHowTo.
+For more information, pls refer to http://wiki.xen.org/wiki/VTdHowTo.
 
 
 Assigning devices to HVM domains
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/xenstore.txt	Tue Nov 29 13:53:31 2011 +0000
@@ -159,7 +159,7 @@ SET_PERMS		<path>|<perm-as-string>|+?
 		r<domid>	read only
 		b<domid>	both read and write
 		n<domid>	no access
-	See http://wiki.xensource.com/xenwiki/XenBus section
+	See http://wiki.xen.org/wiki/XenBus section
 	`Permissions' for details of the permissions system.
 
 ---------- Watches ----------
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/misc/xl-network-configuration.markdown	Tue Nov 29 13:53:31 2011 +0000
@@ -123,4 +123,4 @@ defaults to domain 0. Specifying another
 driver domain which is outside the scope of this document.
 
 [oui]: http://en.wikipedia.org/wiki/Organizationally_Unique_Identifier
-[net]: http://wiki.xen.org/xenwiki/HostConfiguration/Networking
+[net]: http://wiki.xen.org/wiki/HostConfiguration/Networking
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/src/interface.tex
--- a/docs/src/interface.tex	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/src/interface.tex	Tue Nov 29 13:53:31 2011 +0000
@@ -1579,7 +1579,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xen.org/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 docs/src/user.tex
--- a/docs/src/user.tex	Mon Nov 28 17:42:40 2011 +0000
+++ b/docs/src/user.tex	Tue Nov 29 13:53:31 2011 +0000
@@ -2349,7 +2349,7 @@ This contains links to the latest versio
 documentation, including the latest version of the FAQ.
 
 Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xen.org/wiki/}\end{quote}
 The Xen project uses Bugzilla as its bug tracking system. You'll find
 the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
 
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Mon Nov 28 17:42:40 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Tue Nov 29 13:53:31 2011 +0000
@@ -72,7 +72,7 @@ static void parse(CfgParseContext *ctx) 
         fputs(
  "warning: Config file looks like it contains Python code.\n"
  "warning:  Arbitrary Python is no longer supported.\n"
- "warning:  See http://wiki.xen.org/xenwiki/PythonInXlConfig\n",
+ "warning:  See http://wiki.xen.org/wiki/PythonInXlConfig\n",
               ctx->cfg->report);
     }
 }
diff -r a2cb7ed6d0a2 -r 4bdc0f7611d7 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Nov 28 17:42:40 2011 +0000
+++ b/xen/common/sched_credit2.c	Tue Nov 29 13:53:31 2011 +0000
@@ -51,7 +51,7 @@
 /*
  * WARNING: This is still in an experimental phase.  Status and work can be found at the
  * credit2 wiki page:
- *  http://wiki.xensource.com/xenwiki/Credit2_Scheduler_Development
+ *  http://wiki.xen.org/wiki/Credit2_Scheduler_Development
  * TODO:
  * + Immediate bug-fixes
  *  - Do per-runqueue, grab proper lock for dump debugkey

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYq-00056u-D6; Tue, 29 Nov 2011 14:21:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYo-00055b-7E
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14827 invoked from network); 29 Nov 2011 14:20:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184197"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:47 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0N018170;	Tue, 29 Nov 2011 06:20:46 -0800
MIME-Version: 1.0
X-Mercurial-Node: 7b8357c91760686c0c2ea460fb26b3531ea02c8c
Message-ID: <7b8357c91760686c0c2e.1322576444@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 02 of 17 v3] docs: xlexample.hvm is missing
	"builder = 'hvm'"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 7b8357c91760686c0c2ea460fb26b3531ea02c8c
# Parent  4bdc0f7611d72d80b5d7efedc86fd70df06a6bbc
docs: xlexample.hvm is missing "builder = 'hvm'"

This is rather critical...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 4bdc0f7611d7 -r 7b8357c91760 tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Tue Nov 29 13:53:31 2011 +0000
+++ b/tools/examples/xlexample.hvm	Tue Nov 29 14:17:27 2011 +0000
@@ -5,6 +5,9 @@
 # This is a fairly minimal example of what is required for an
 # HVM guest. For a more complete guide see <XXX Document TBD>
 
+# This configures an HVM rather than PV guest
+builder = "hvm"
+
 # Guest name
 name = "example.hvm"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYq-00056u-D6; Tue, 29 Nov 2011 14:21:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYo-00055b-7E
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14827 invoked from network); 29 Nov 2011 14:20:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184197"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:47 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0N018170;	Tue, 29 Nov 2011 06:20:46 -0800
MIME-Version: 1.0
X-Mercurial-Node: 7b8357c91760686c0c2ea460fb26b3531ea02c8c
Message-ID: <7b8357c91760686c0c2e.1322576444@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 02 of 17 v3] docs: xlexample.hvm is missing
	"builder = 'hvm'"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 7b8357c91760686c0c2ea460fb26b3531ea02c8c
# Parent  4bdc0f7611d72d80b5d7efedc86fd70df06a6bbc
docs: xlexample.hvm is missing "builder = 'hvm'"

This is rather critical...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 4bdc0f7611d7 -r 7b8357c91760 tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Tue Nov 29 13:53:31 2011 +0000
+++ b/tools/examples/xlexample.hvm	Tue Nov 29 14:17:27 2011 +0000
@@ -5,6 +5,9 @@
 # This is a fairly minimal example of what is required for an
 # HVM guest. For a more complete guide see <XXX Document TBD>
 
+# This configures an HVM rather than PV guest
+builder = "hvm"
+
 # Guest name
 name = "example.hvm"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYr-00057Q-LA; Tue, 29 Nov 2011 14:21:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYo-00055k-R6
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14897 invoked from network); 29 Nov 2011 14:20:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184198"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:49 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0P018170;	Tue, 29 Nov 2011 06:20:48 -0800
MIME-Version: 1.0
X-Mercurial-Node: f0d2cd2deb2124563bf5681665840d66fab0f232
Message-ID: <f0d2cd2deb2124563bf5.1322576446@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 04 of 17 v3] docs: install html and txt versions
	of manpages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID f0d2cd2deb2124563bf5681665840d66fab0f232
# Parent  a6d252b9ec9aca04c30ade1462f58d6189225f5f
docs: install html and txt versions of manpages

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a6d252b9ec9a -r f0d2cd2deb21 docs/Docs.mk
--- a/docs/Docs.mk	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/Docs.mk	Tue Nov 29 14:17:27 2011 +0000
@@ -5,6 +5,8 @@ FIG2DEV		:= fig2dev
 LATEX2HTML	:= latex2html
 DOXYGEN		:= doxygen
 POD2MAN		:= pod2man
+POD2HTML	:= pod2html
+POD2TEXT	:= pod2text
 DOT		:= dot
 NEATO		:= neato
 MARKDOWN	:= markdown
diff -r a6d252b9ec9a -r f0d2cd2deb21 docs/Makefile
--- a/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
@@ -15,9 +15,13 @@ DOC_MARKDOWN	:= $(wildcard misc/*.markdo
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
 DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
-		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
-		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,txt/man/%.5.txt,$(DOC_MAN5SRC))
 
 GFX = $(patsubst %.fig, %.eps, $(wildcard figs/*.fig))
 
@@ -76,7 +80,7 @@ clean:
 	$(MAKE) -C xen-api clean
 	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
 	rm -rf *.ilg *.log *.ind *.toc *.bak core
-	rm -rf $(GFX) ps pdf html
+	rm -rf $(GFX) ps pdf html txt
 	rm -rf api
 	rm -rf man5
 	rm -rf man1
@@ -132,6 +136,16 @@ html/%.html: %.markdown
 	$(call move-if-changed,$@.tmp,$@) ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/man/%.1.html: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+html/man/%.5.html: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
@@ -141,3 +155,14 @@ txt/%.txt: %.markdown
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.1.txt: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.5.txt: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYr-00057Q-LA; Tue, 29 Nov 2011 14:21:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYo-00055k-R6
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14897 invoked from network); 29 Nov 2011 14:20:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184198"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:49 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0P018170;	Tue, 29 Nov 2011 06:20:48 -0800
MIME-Version: 1.0
X-Mercurial-Node: f0d2cd2deb2124563bf5681665840d66fab0f232
Message-ID: <f0d2cd2deb2124563bf5.1322576446@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:46 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 04 of 17 v3] docs: install html and txt versions
	of manpages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID f0d2cd2deb2124563bf5681665840d66fab0f232
# Parent  a6d252b9ec9aca04c30ade1462f58d6189225f5f
docs: install html and txt versions of manpages

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a6d252b9ec9a -r f0d2cd2deb21 docs/Docs.mk
--- a/docs/Docs.mk	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/Docs.mk	Tue Nov 29 14:17:27 2011 +0000
@@ -5,6 +5,8 @@ FIG2DEV		:= fig2dev
 LATEX2HTML	:= latex2html
 DOXYGEN		:= doxygen
 POD2MAN		:= pod2man
+POD2HTML	:= pod2html
+POD2TEXT	:= pod2text
 DOT		:= dot
 NEATO		:= neato
 MARKDOWN	:= markdown
diff -r a6d252b9ec9a -r f0d2cd2deb21 docs/Makefile
--- a/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
@@ -15,9 +15,13 @@ DOC_MARKDOWN	:= $(wildcard misc/*.markdo
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
 DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
-		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
-		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
+		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
+		   $(patsubst man/%.pod.5,txt/man/%.5.txt,$(DOC_MAN5SRC))
 
 GFX = $(patsubst %.fig, %.eps, $(wildcard figs/*.fig))
 
@@ -76,7 +80,7 @@ clean:
 	$(MAKE) -C xen-api clean
 	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
 	rm -rf *.ilg *.log *.ind *.toc *.bak core
-	rm -rf $(GFX) ps pdf html
+	rm -rf $(GFX) ps pdf html txt
 	rm -rf api
 	rm -rf man5
 	rm -rf man1
@@ -132,6 +136,16 @@ html/%.html: %.markdown
 	$(call move-if-changed,$@.tmp,$@) ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/man/%.1.html: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+html/man/%.5.html: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2HTML) --infile=$< --outfile=$@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
@@ -141,3 +155,14 @@ txt/%.txt: %.markdown
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.1.txt: man/%.pod.1 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+
+txt/man/%.5.txt: man/%.pod.5 Makefile
+	$(INSTALL_DIR) $(@D)
+	$(POD2TEXT) $< $@.tmp
+	$(call move-if-changed,$@.tmp,$@)
+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ1-0005EA-9N; Tue, 29 Nov 2011 14:21:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYz-00058k-5Z
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15340 invoked from network); 29 Nov 2011 14:20:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184225"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:59 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0a018170;	Tue, 29 Nov 2011 06:20:58 -0800
MIME-Version: 1.0
X-Mercurial-Node: d5c066924bdd55f1a875ec49ddd95cf23e8e0598
Message-ID: <d5c066924bdd55f1a875.1322576457@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:57 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 15 of 17 v3] docs: install txt files as html
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID d5c066924bdd55f1a875ec49ddd95cf23e8e0598
# Parent  a08afddff75b70f816d383206a0c6d2dfe0e9a7e
docs: install txt files as html

A browser will display them just fine.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a08afddff75b -r d5c066924bdd docs/INDEX
--- a/docs/INDEX	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/INDEX	Tue Nov 29 14:17:27 2011 +0000
@@ -1,5 +1,7 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
+misc/console.txt		Xen PV Console notes
+
 # These are not all that useful anymore, hide them from the index
 reference/interface/index	NO-INDEX
 reference/user/index		NO-INDEX
diff -r a08afddff75b -r d5c066924bdd docs/Makefile
--- a/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
@@ -17,7 +17,8 @@ DOC_PDF		:= $(patsubst src/%.tex,pdf/%.p
 DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
-		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC)) \
+		   $(patsubst %.txt,html/%.txt,$(wildcard misc/*.txt))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
@@ -139,6 +140,10 @@ html/%.html: %.markdown
 	$(call move-if-changed,$@.tmp,$@) ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/%.txt: %.txt
+	@$(INSTALL_DIR) $(@D)
+	cp $< $@
+
 html/man/%.1.html: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
 	$(POD2HTML) --infile=$< --outfile=$@.tmp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ1-0005EA-9N; Tue, 29 Nov 2011 14:21:39 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYz-00058k-5Z
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15340 invoked from network); 29 Nov 2011 14:20:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:59 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184225"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:59 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0a018170;	Tue, 29 Nov 2011 06:20:58 -0800
MIME-Version: 1.0
X-Mercurial-Node: d5c066924bdd55f1a875ec49ddd95cf23e8e0598
Message-ID: <d5c066924bdd55f1a875.1322576457@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:57 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 15 of 17 v3] docs: install txt files as html
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID d5c066924bdd55f1a875ec49ddd95cf23e8e0598
# Parent  a08afddff75b70f816d383206a0c6d2dfe0e9a7e
docs: install txt files as html

A browser will display them just fine.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a08afddff75b -r d5c066924bdd docs/INDEX
--- a/docs/INDEX	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/INDEX	Tue Nov 29 14:17:27 2011 +0000
@@ -1,5 +1,7 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
+misc/console.txt		Xen PV Console notes
+
 # These are not all that useful anymore, hide them from the index
 reference/interface/index	NO-INDEX
 reference/user/index		NO-INDEX
diff -r a08afddff75b -r d5c066924bdd docs/Makefile
--- a/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
@@ -17,7 +17,8 @@ DOC_PDF		:= $(patsubst src/%.tex,pdf/%.p
 DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
-		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
+		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC)) \
+		   $(patsubst %.txt,html/%.txt,$(wildcard misc/*.txt))
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \
@@ -139,6 +140,10 @@ html/%.html: %.markdown
 	$(call move-if-changed,$@.tmp,$@) ; else \
 	echo "markdown not installed; skipping $*.html."; fi
 
+html/%.txt: %.txt
+	@$(INSTALL_DIR) $(@D)
+	cp $< $@
+
 html/man/%.1.html: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
 	$(POD2HTML) --infile=$< --outfile=$@.tmp

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ5-0005IY-LO; Tue, 29 Nov 2011 14:21:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOZ3-00059j-Bo
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15442 invoked from network); 29 Nov 2011 14:21:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184229"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:21:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:21:01 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0c018170;	Tue, 29 Nov 2011 06:21:00 -0800
MIME-Version: 1.0
X-Mercurial-Node: 5b91e49d5c442ebb6dd271513764b0c8c414361b
Message-ID: <5b91e49d5c442ebb6dd2.1322576459@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 17 of 17 v3] docs: improve documantion of xl's
	viridian option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576399 0
# Node ID 5b91e49d5c442ebb6dd271513764b0c8c414361b
# Parent  447407a7984d2f2484321418ce8b1991f7f2bd51
docs: improve documantion of xl's viridian option

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 447407a7984d -r 5b91e49d5c44 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Tue Nov 29 14:19:59 2011 +0000
@@ -555,7 +555,13 @@ Windows L<http://wiki.xen.org/wiki/XenWi
 
 Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
 compatible enlightenments to the guest.  These can improve performance
-of Microsoft Windows guests (XXX which versions of Windows benefit?)
+of Microsoft Windows guests from Windows Vista and Windows 2008
+onwards and setting this option for such guests is strongly
+recommended. This option should be harmless for other versions of
+Windows (although it won't give any benefit) and the majority of other
+non-Windows OSes. However it is known to be incompatible with some
+other Operating Systems and in some circumstance can prevent Xen's own
+paravirtualisation interfaces for HVM guests from being used.
 
 =back
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ5-0005IY-LO; Tue, 29 Nov 2011 14:21:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOZ3-00059j-Bo
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15442 invoked from network); 29 Nov 2011 14:21:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184229"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:21:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:21:01 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0c018170;	Tue, 29 Nov 2011 06:21:00 -0800
MIME-Version: 1.0
X-Mercurial-Node: 5b91e49d5c442ebb6dd271513764b0c8c414361b
Message-ID: <5b91e49d5c442ebb6dd2.1322576459@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 17 of 17 v3] docs: improve documantion of xl's
	viridian option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576399 0
# Node ID 5b91e49d5c442ebb6dd271513764b0c8c414361b
# Parent  447407a7984d2f2484321418ce8b1991f7f2bd51
docs: improve documantion of xl's viridian option

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 447407a7984d -r 5b91e49d5c44 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Tue Nov 29 14:19:59 2011 +0000
@@ -555,7 +555,13 @@ Windows L<http://wiki.xen.org/wiki/XenWi
 
 Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
 compatible enlightenments to the guest.  These can improve performance
-of Microsoft Windows guests (XXX which versions of Windows benefit?)
+of Microsoft Windows guests from Windows Vista and Windows 2008
+onwards and setting this option for such guests is strongly
+recommended. This option should be harmless for other versions of
+Windows (although it won't give any benefit) and the majority of other
+non-Windows OSes. However it is known to be incompatible with some
+other Operating Systems and in some circumstance can prevent Xen's own
+paravirtualisation interfaces for HVM guests from being used.
 
 =back
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYn-00056D-W1; Tue, 29 Nov 2011 14:21:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYm-00055X-Pe
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14799 invoked from network); 29 Nov 2011 14:20:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:47 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184193"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:45 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0L018170;	Tue, 29 Nov 2011 06:20:44 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:42 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 00 of 17 v3] Documentation updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Repost of my documentation series at IanJs request.

Changes since last time: 

Invoke Perl directly

Updated Viridian description

Updated wiki transition to add XenBus and switch to wiki.xen.org

Changes since last time:

Dropped "docs: generate docs direct into final filename", using a
temp file prevents half completed docsshowing up after an error

Applied IanJ's review of my perl code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:51 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYn-00056D-W1; Tue, 29 Nov 2011 14:21:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYm-00055X-Pe
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14799 invoked from network); 29 Nov 2011 14:20:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:47 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184193"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:45 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0L018170;	Tue, 29 Nov 2011 06:20:44 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:42 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 00 of 17 v3] Documentation updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Repost of my documentation series at IanJs request.

Changes since last time: 

Invoke Perl directly

Updated Viridian description

Updated wiki transition to add XenBus and switch to wiki.xen.org

Changes since last time:

Dropped "docs: generate docs direct into final filename", using a
temp file prevents half completed docsshowing up after an error

Applied IanJ's review of my perl code.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ2-0005FY-Mq; Tue, 29 Nov 2011 14:21:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYw-00056q-C1
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15231 invoked from network); 29 Nov 2011 14:20:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184209"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:55 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0W018170;	Tue, 29 Nov 2011 06:20:54 -0800
MIME-Version: 1.0
X-Mercurial-Node: 37b46c492f8ac8d356b2b88e8ff00d359443163a
Message-ID: <37b46c492f8ac8d356b2.1322576453@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 11 of 17 v3] docs: generate an index for the
	html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 37b46c492f8ac8d356b2b88e8ff00d359443163a
# Parent  334a8606c849cbaff265181241714e527d5ecba4
docs: generate an index for the html output

nb: I'm not a Perl wizard...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 334a8606c849 -r 37b46c492f8a docs/INDEX
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/INDEX	Tue Nov 29 14:17:27 2011 +0000
@@ -0,0 +1,5 @@
+misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
+
+# These are not all that useful anymore, hide them from the index
+interface/index			NO-INDEX
+user/index			NO-INDEX
diff -r 334a8606c849 -r 37b46c492f8a docs/Makefile
--- a/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
@@ -45,7 +45,7 @@ ps: $(DOC_PS)
 pdf: $(DOC_PDF)
 
 .PHONY: html
-html: $(DOC_HTML)
+html: $(DOC_HTML) html/index.html
 
 .PHONY: txt
 txt: $(DOC_TXT)
@@ -128,6 +128,9 @@ html/%/index.html: src/%.tex
 	$< 1>/dev/null 2>/dev/null ; else \
 	echo "latex2html not installed; skipping $*."; fi
 
+html/index.html: $(DOC_HTML) ./gen-html-index INDEX
+	perl -w -- ./gen-html-index -i INDEX html $(DOC_HTML)
+
 html/%.html: %.markdown
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \
diff -r 334a8606c849 -r 37b46c492f8a docs/gen-html-index
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/gen-html-index	Tue Nov 29 14:17:27 2011 +0000
@@ -0,0 +1,136 @@
+#!/usr/bin/env perl
+
+#
+# Generate indexes for html documentation
+#
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+use IO::File;
+use File::Basename;
+use List::MoreUtils qw/ uniq /;
+
+Getopt::Long::Configure('bundling');
+
+@ARGV >= 2 or die;
+
+our @docs;
+our @dirs;
+our %index;
+
+our $outdir;
+
+GetOptions("i=s" => sub { read_index(@_);} )
+    or die;
+
+($outdir,@docs) = @ARGV;
+
+sub write_file ($$) {
+    my ($opath, $odata) = @_;
+    print STDOUT "Writing: $opath\n";
+    my $out = new IO::File "$opath.new", '>' or die "$opath $!";
+    print $out $odata or die $!;
+    rename "$opath.new", "$opath" or die "$opath $!";
+}
+
+sub make_page ($$$) {
+    my ($file,$title,$content) = @_;
+    my $o = '';
+    my $h1;
+    if ( $title eq "" )
+    {
+        $title = $h1 = "Xen Documentation";
+    }
+    else
+    {
+        $h1 = "<a href=\"../index.(?:html|txt)\">Xen Documentation</a> - $title";
+        $title = "Xen Documentation - $title";
+    }
+    $o .= <<END;
+<html><head><title>$title</title></head>
+<body>
+<h1>$h1</h1>
+<ul>
+$content
+</ul>
+</body></html>
+END
+    write_file($file, $o);
+}
+
+sub make_linktext ($) {
+    my ($l) = @_;
+    return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
+    $l =~ s/.(html)$//g;
+    return $index{$l} if exists $index{$l};
+    return basename($l);
+}
+
+sub make_link ($$) {
+    my ($ref,$base) = @_;
+
+    my $txt = make_linktext($ref);
+    $ref = basename($ref) if $base;
+
+    return "<li><a href=\"$ref\">$txt</a></li>\n";
+}
+
+sub make_links ($$@) {
+    my ($dir,$base,@docs) = @_;
+    my $idx = '';
+    foreach my $of (sort { $a cmp $b } @docs) {
+        $idx .= make_link($of,$base);
+    }
+    return $idx;
+}
+
+sub read_index ($$) {
+    my ($opt, $val) = @_;
+    my $idx = new IO::File "$val", '<' or die "$val $!";
+    while ($_ = $idx->getline()) {
+	s/^\s+//;
+	s/\s+$//;
+	next if m/^\#/;
+	next unless m/\S/;
+	m/^(\S+)\s+(\S.*)$/ or die;
+        $index{$1} = $2;
+    }
+}
+
+for (@docs) { s,^\Q$outdir\E/,, }
+
+@docs = grep { -e "$outdir/$_" && (make_linktext($_) ne "NO-INDEX") } @docs;
+
+my $top = '';
+
+foreach my $od (sort { $a cmp $b } uniq map { dirname($_) } @docs) {
+    my @d = (grep /^\Q$od\E/, @docs);
+    if ( @d == 1 and $d[0] eq "$od/index.html" )
+    {
+        $top .= "<li><a href=\"${od}/index.html\">${od}/index.html</a></li>\n";
+    }
+    else
+    {
+	my $links = make_links($od,0,@d);
+	$top .= <<END;
+<li><a href=\"${od}/index.html\">$od</a></li>
+<ul>
+$links
+</ul>
+END
+
+	$links = make_links($od,1,@d);
+        my $idx = '';
+	$idx .= <<END;
+<li>$od</li>
+<ul>
+$links
+</ul>
+END
+        make_page("$outdir/$od/index.html", $od, $idx);
+    }
+}
+
+make_page("$outdir/index.html", "", $top);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ2-0005FY-Mq; Tue, 29 Nov 2011 14:21:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYw-00056q-C1
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15231 invoked from network); 29 Nov 2011 14:20:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184209"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:55 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0W018170;	Tue, 29 Nov 2011 06:20:54 -0800
MIME-Version: 1.0
X-Mercurial-Node: 37b46c492f8ac8d356b2b88e8ff00d359443163a
Message-ID: <37b46c492f8ac8d356b2.1322576453@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:53 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 11 of 17 v3] docs: generate an index for the
	html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 37b46c492f8ac8d356b2b88e8ff00d359443163a
# Parent  334a8606c849cbaff265181241714e527d5ecba4
docs: generate an index for the html output

nb: I'm not a Perl wizard...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 334a8606c849 -r 37b46c492f8a docs/INDEX
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/INDEX	Tue Nov 29 14:17:27 2011 +0000
@@ -0,0 +1,5 @@
+misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
+
+# These are not all that useful anymore, hide them from the index
+interface/index			NO-INDEX
+user/index			NO-INDEX
diff -r 334a8606c849 -r 37b46c492f8a docs/Makefile
--- a/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
@@ -45,7 +45,7 @@ ps: $(DOC_PS)
 pdf: $(DOC_PDF)
 
 .PHONY: html
-html: $(DOC_HTML)
+html: $(DOC_HTML) html/index.html
 
 .PHONY: txt
 txt: $(DOC_TXT)
@@ -128,6 +128,9 @@ html/%/index.html: src/%.tex
 	$< 1>/dev/null 2>/dev/null ; else \
 	echo "latex2html not installed; skipping $*."; fi
 
+html/index.html: $(DOC_HTML) ./gen-html-index INDEX
+	perl -w -- ./gen-html-index -i INDEX html $(DOC_HTML)
+
 html/%.html: %.markdown
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \
diff -r 334a8606c849 -r 37b46c492f8a docs/gen-html-index
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/gen-html-index	Tue Nov 29 14:17:27 2011 +0000
@@ -0,0 +1,136 @@
+#!/usr/bin/env perl
+
+#
+# Generate indexes for html documentation
+#
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+use IO::File;
+use File::Basename;
+use List::MoreUtils qw/ uniq /;
+
+Getopt::Long::Configure('bundling');
+
+@ARGV >= 2 or die;
+
+our @docs;
+our @dirs;
+our %index;
+
+our $outdir;
+
+GetOptions("i=s" => sub { read_index(@_);} )
+    or die;
+
+($outdir,@docs) = @ARGV;
+
+sub write_file ($$) {
+    my ($opath, $odata) = @_;
+    print STDOUT "Writing: $opath\n";
+    my $out = new IO::File "$opath.new", '>' or die "$opath $!";
+    print $out $odata or die $!;
+    rename "$opath.new", "$opath" or die "$opath $!";
+}
+
+sub make_page ($$$) {
+    my ($file,$title,$content) = @_;
+    my $o = '';
+    my $h1;
+    if ( $title eq "" )
+    {
+        $title = $h1 = "Xen Documentation";
+    }
+    else
+    {
+        $h1 = "<a href=\"../index.(?:html|txt)\">Xen Documentation</a> - $title";
+        $title = "Xen Documentation - $title";
+    }
+    $o .= <<END;
+<html><head><title>$title</title></head>
+<body>
+<h1>$h1</h1>
+<ul>
+$content
+</ul>
+</body></html>
+END
+    write_file($file, $o);
+}
+
+sub make_linktext ($) {
+    my ($l) = @_;
+    return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
+    $l =~ s/.(html)$//g;
+    return $index{$l} if exists $index{$l};
+    return basename($l);
+}
+
+sub make_link ($$) {
+    my ($ref,$base) = @_;
+
+    my $txt = make_linktext($ref);
+    $ref = basename($ref) if $base;
+
+    return "<li><a href=\"$ref\">$txt</a></li>\n";
+}
+
+sub make_links ($$@) {
+    my ($dir,$base,@docs) = @_;
+    my $idx = '';
+    foreach my $of (sort { $a cmp $b } @docs) {
+        $idx .= make_link($of,$base);
+    }
+    return $idx;
+}
+
+sub read_index ($$) {
+    my ($opt, $val) = @_;
+    my $idx = new IO::File "$val", '<' or die "$val $!";
+    while ($_ = $idx->getline()) {
+	s/^\s+//;
+	s/\s+$//;
+	next if m/^\#/;
+	next unless m/\S/;
+	m/^(\S+)\s+(\S.*)$/ or die;
+        $index{$1} = $2;
+    }
+}
+
+for (@docs) { s,^\Q$outdir\E/,, }
+
+@docs = grep { -e "$outdir/$_" && (make_linktext($_) ne "NO-INDEX") } @docs;
+
+my $top = '';
+
+foreach my $od (sort { $a cmp $b } uniq map { dirname($_) } @docs) {
+    my @d = (grep /^\Q$od\E/, @docs);
+    if ( @d == 1 and $d[0] eq "$od/index.html" )
+    {
+        $top .= "<li><a href=\"${od}/index.html\">${od}/index.html</a></li>\n";
+    }
+    else
+    {
+	my $links = make_links($od,0,@d);
+	$top .= <<END;
+<li><a href=\"${od}/index.html\">$od</a></li>
+<ul>
+$links
+</ul>
+END
+
+	$links = make_links($od,1,@d);
+        my $idx = '';
+	$idx .= <<END;
+<li>$od</li>
+<ul>
+$links
+</ul>
+END
+        make_page("$outdir/$od/index.html", $od, $idx);
+    }
+}
+
+make_page("$outdir/index.html", "", $top);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYy-0005BW-Ag; Tue, 29 Nov 2011 14:21:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYw-000579-DT
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322576453!3551410!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1418 invoked from network); 29 Nov 2011 14:20:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488422"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:54 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0V018170;	Tue, 29 Nov 2011 06:20:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 334a8606c849cbaff265181241714e527d5ecba4
Message-ID: <334a8606c849cbaff265.1322576452@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 10 of 17 v3] docs: tweak markup and wording of
 qemu upstream doc slightly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 334a8606c849cbaff265181241714e527d5ecba4
# Parent  e515bb651349f69c2084e4916d999634287c1480
docs: tweak markup and wording of qemu upstream doc slightly

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r e515bb651349 -r 334a8606c849 docs/misc/qemu-upstream_howto_use_it.markdown
--- a/docs/misc/qemu-upstream_howto_use_it.markdown	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/misc/qemu-upstream_howto_use_it.markdown	Tue Nov 29 14:17:27 2011 +0000
@@ -1,11 +1,11 @@
-Help to use QEMU (upstream version) with Xen
-============================================
+Using Upstream QEMU with Xen
+============================
 
 Note
 ----
 
 All these steps will become unnecessary after the patches to integrate
-SeaBIOS/QEMU build will be applied.
+SeaBIOS/QEMU into the Xen build system have been applied.
 
 
 How to build it
@@ -15,14 +15,15 @@ How to build it
 
 The new device-model needs a different BIOS, SeaBIOS. Clone the repository from:
 
-  - git://git.qemu.org/seabios.git
-  - http://git.qemu.org/git/seabios.git
+  - [git://git.qemu.org/seabios.git]()
+  - [http://git.qemu.org/git/seabios.git]()
 
-Put the `.config` file in the appendix at the root of seabios.git and build SeaBIOS.
+Put the `.config` file in the appendix at the root of `seabios.git`
+and build SeaBIOS by typing `make`.
 
-In xen-unstable source tree, add the file `.config` with
+In the xen-unstable source tree, add the file `.config` with
 `SEABIOS_DIR = /path/to/seabios.git`.
-To build hvmloader with SeaBIOS, you propably need to `make -C tools/firmware
+To build hvmloader with SeaBIOS, you probably need to `make -C tools/firmware
 clean` first and then `make tools`, to use the new SEABIOS_DIR parameter.
 
 
@@ -30,10 +31,10 @@ clean` first and then `make tools`, to u
 
 Get QEMU upstream source from:
 
-  - git://xenbits.xensource.com/qemu-upstream-unstable.git
-  - http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
+  - [git://xenbits.xensource.com/qemu-upstream-unstable.git]()
+  - [http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git]()
 
-To configure build QEMU upstream with Xen
+To configure QEMU upstream with support for Xen:
 
     ./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I$path_to_xen_source/tools/include -I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore" --extra-ldflags="-L$path_to_xen_source/tools/libxc -L$path_to_xen_source/tools/xenstore"
 
@@ -43,15 +44,15 @@ You can also use other several options s
 How to use QEMU upstream
 ------------------------
 
-Only xl support QEMU upstream.
+Only `xl` supports QEMU upstream.
 
 To actually use it, add or change this in your VM configuration file:
 
     device_model_version = 'qemu-xen'
     device_model_override = '/path/to/qemu/i386-softmmu/qemu'
 
-NB: On qemu-upstream repository, the default binary name has been renamed to
-`qemu-system-i386`.
+NB: In the `qemu-upstream` repository, the default binary name has been
+renamed to `qemu-system-i386`.
 
 
 Appendix

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYy-0005BW-Ag; Tue, 29 Nov 2011 14:21:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYw-000579-DT
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322576453!3551410!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1418 invoked from network); 29 Nov 2011 14:20:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:56 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488422"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:54 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0V018170;	Tue, 29 Nov 2011 06:20:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 334a8606c849cbaff265181241714e527d5ecba4
Message-ID: <334a8606c849cbaff265.1322576452@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:52 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 10 of 17 v3] docs: tweak markup and wording of
 qemu upstream doc slightly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 334a8606c849cbaff265181241714e527d5ecba4
# Parent  e515bb651349f69c2084e4916d999634287c1480
docs: tweak markup and wording of qemu upstream doc slightly

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r e515bb651349 -r 334a8606c849 docs/misc/qemu-upstream_howto_use_it.markdown
--- a/docs/misc/qemu-upstream_howto_use_it.markdown	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/misc/qemu-upstream_howto_use_it.markdown	Tue Nov 29 14:17:27 2011 +0000
@@ -1,11 +1,11 @@
-Help to use QEMU (upstream version) with Xen
-============================================
+Using Upstream QEMU with Xen
+============================
 
 Note
 ----
 
 All these steps will become unnecessary after the patches to integrate
-SeaBIOS/QEMU build will be applied.
+SeaBIOS/QEMU into the Xen build system have been applied.
 
 
 How to build it
@@ -15,14 +15,15 @@ How to build it
 
 The new device-model needs a different BIOS, SeaBIOS. Clone the repository from:
 
-  - git://git.qemu.org/seabios.git
-  - http://git.qemu.org/git/seabios.git
+  - [git://git.qemu.org/seabios.git]()
+  - [http://git.qemu.org/git/seabios.git]()
 
-Put the `.config` file in the appendix at the root of seabios.git and build SeaBIOS.
+Put the `.config` file in the appendix at the root of `seabios.git`
+and build SeaBIOS by typing `make`.
 
-In xen-unstable source tree, add the file `.config` with
+In the xen-unstable source tree, add the file `.config` with
 `SEABIOS_DIR = /path/to/seabios.git`.
-To build hvmloader with SeaBIOS, you propably need to `make -C tools/firmware
+To build hvmloader with SeaBIOS, you probably need to `make -C tools/firmware
 clean` first and then `make tools`, to use the new SEABIOS_DIR parameter.
 
 
@@ -30,10 +31,10 @@ clean` first and then `make tools`, to u
 
 Get QEMU upstream source from:
 
-  - git://xenbits.xensource.com/qemu-upstream-unstable.git
-  - http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
+  - [git://xenbits.xensource.com/qemu-upstream-unstable.git]()
+  - [http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git]()
 
-To configure build QEMU upstream with Xen
+To configure QEMU upstream with support for Xen:
 
     ./configure --enable-xen --target-list=i386-softmmu --extra-cflags="-I$path_to_xen_source/tools/include -I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore" --extra-ldflags="-L$path_to_xen_source/tools/libxc -L$path_to_xen_source/tools/xenstore"
 
@@ -43,15 +44,15 @@ You can also use other several options s
 How to use QEMU upstream
 ------------------------
 
-Only xl support QEMU upstream.
+Only `xl` supports QEMU upstream.
 
 To actually use it, add or change this in your VM configuration file:
 
     device_model_version = 'qemu-xen'
     device_model_override = '/path/to/qemu/i386-softmmu/qemu'
 
-NB: On qemu-upstream repository, the default binary name has been renamed to
-`qemu-system-i386`.
+NB: In the `qemu-upstream` repository, the default binary name has been
+renamed to `qemu-system-i386`.
 
 
 Appendix

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYr-00057G-8D; Tue, 29 Nov 2011 14:21:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYo-00055i-BA
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322576446!5152993!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25941 invoked from network); 29 Nov 2011 14:20:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488414"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:48 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0O018170;	Tue, 29 Nov 2011 06:20:47 -0800
MIME-Version: 1.0
X-Mercurial-Node: a6d252b9ec9aca04c30ade1462f58d6189225f5f
Message-ID: <a6d252b9ec9aca04c30a.1322576445@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:45 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 03 of 17 v3] README: add markdown to dependency
	list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID a6d252b9ec9aca04c30ade1462f58d6189225f5f
# Parent  7b8357c91760686c0c2ea460fb26b3531ea02c8c
README: add markdown to dependency list

although this tool is strictly speaking optional we are providing various user
docs in this format so increase the changes that they will install it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7b8357c91760 -r a6d252b9ec9a README
--- a/README	Tue Nov 29 14:17:27 2011 +0000
+++ b/README	Tue Nov 29 14:17:27 2011 +0000
@@ -57,6 +57,7 @@ provided by your OS distributor:
     * GNU gettext
     * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
     * ACPI ASL compiler (iasl)
+    * markdown
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYr-00057G-8D; Tue, 29 Nov 2011 14:21:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYo-00055i-BA
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322576446!5152993!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25941 invoked from network); 29 Nov 2011 14:20:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:48 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488414"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:48 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0O018170;	Tue, 29 Nov 2011 06:20:47 -0800
MIME-Version: 1.0
X-Mercurial-Node: a6d252b9ec9aca04c30ade1462f58d6189225f5f
Message-ID: <a6d252b9ec9aca04c30a.1322576445@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:45 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 03 of 17 v3] README: add markdown to dependency
	list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID a6d252b9ec9aca04c30ade1462f58d6189225f5f
# Parent  7b8357c91760686c0c2ea460fb26b3531ea02c8c
README: add markdown to dependency list

although this tool is strictly speaking optional we are providing various user
docs in this format so increase the changes that they will install it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7b8357c91760 -r a6d252b9ec9a README
--- a/README	Tue Nov 29 14:17:27 2011 +0000
+++ b/README	Tue Nov 29 14:17:27 2011 +0000
@@ -57,6 +57,7 @@ provided by your OS distributor:
     * GNU gettext
     * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
     * ACPI ASL compiler (iasl)
+    * markdown
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYs-00057x-AF; Tue, 29 Nov 2011 14:21:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYq-00055w-Vp
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322576446!5152993!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26028 invoked from network); 29 Nov 2011 14:20:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488416"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:50 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0Q018170;	Tue, 29 Nov 2011 06:20:48 -0800
MIME-Version: 1.0
X-Mercurial-Node: ce3fa9ade7c176b4439aba566551ed2b48915d67
Message-ID: <ce3fa9ade7c176b4439a.1322576447@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 05 of 17 v3] docs: add a document describing the
 xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID ce3fa9ade7c176b4439aba566551ed2b48915d67
# Parent  f0d2cd2deb2124563bf5681665840d66fab0f232
docs: add a document describing the xl cfg file syntax

Based on an initial version by Ian Jackson.

I believe that all keys are now present in the document although there are are
various omissions in the actual documentation of them. Hopefully however this
covers the majority of the most interesting keys.

Spice section:
Signed-off-by: Zhou Peng <zhoupeng@nfs.iscas.ac.cn>

The rest:
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f0d2cd2deb21 -r ce3fa9ade7c1 docs/man/xl.cfg.pod.5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
@@ -0,0 +1,844 @@
+=head1 NAME
+
+xl.cfg - XL Domain Configuration File Syntax
+
+=head1 SYNOPSIS
+
+ /etc/xen/xldomain
+
+=head1 DESCRIPTION
+
+To create a VM (a domain in Xen terminology, sometimes called a guest)
+with xl requires the provision of a domain config file.  Typically
+these live in `/etc/xen/DOMAIN.cfg` where DOMAIN is the name of the
+domain.
+
+=head1 SYNTAX
+
+A domain config file consists of a series of C<KEY=VALUE> pairs.
+
+Some C<KEY>s are mandatory, others are global options which apply to
+any guest type while others relate only to specific guest types
+(e.g. PV or HVM guests).
+
+A value C<VALUE> is one of:
+
+=over 4
+
+=item B<"STRING">
+
+A string, surrounded by either single or double quotes.
+
+=item B<NUMBER>
+
+A number, in either decimal, octal (using a C<0> prefix) or
+hexadecimal (using an C<0x> prefix).
+
+=item B<BOOLEAN>
+
+A C<NUMBER> interpreted as C<False> (C<0>) or C<True> (any other
+value).
+
+=item B<[ VALUE, VALUE, ... ]>
+
+A list of C<VALUES> of the above types. Lists are homogeneous and are
+not nested.
+
+=back
+
+The semantics of each C<KEY> defines which form of C<VALUE> is required.
+
+=head1 OPTIONS
+
+=head2 Mandatory Configuration Items
+
+The following key is mandatory for any guest type:
+
+=over 4
+
+=item B<name="NAME">
+
+Specifies the name of the domain.  Names of domains existing on a
+single host must be unique.
+
+=back
+
+=head2 Selecting Guest Type
+
+=over 4
+
+=item B<builder="generic">
+
+Specifies that this is to be a PV domain. This is the default.
+
+=item B<builder="hvm">
+
+Specifies that this is to be an HVM domain.  That is, a fully
+virtualised computer with emulated BIOS, disk and network peripherals,
+etc.  The default is a PV domain, suitable for hosting Xen-aware guest
+operating systems.
+
+=back
+
+=head2 Global Options
+
+The following options apply to guests of any type.
+
+=over 4
+
+=item B<uuid="UUID">
+
+Specifies the UUID of the domain.  If not specified, a fresh unique
+UUID will be generated.
+
+=item B<pool="CPUPOOLNAME">
+
+Put the guest's vcpus into the named cpu pool.
+
+=item B<vcpus=N>
+
+Start the guest with N vcpus initially online.
+
+=item B<maxvcpus=M>
+
+Allow the guest to bring up a maximum of M vcpus. At start of day if
+`vcpus=N` is less than `maxvcpus=M` then the first `N` vcpus will be
+created online and the remainder will be offline.
+
+=item B<memory=MBYTES>
+
+Start the guest with MBYTES megabytes of RAM.
+
+=item B<on_poweroff="ACTION">
+
+Specifies what should be done with the domain if it shuts itself down.
+The C<ACTION>s are:
+
+=over 4
+
+=item B<destroy>
+
+destroy the domain
+     
+=item B<restart>
+
+destroy the domain and immediately create a new domain with the same
+configuration
+        
+=item B<rename-restart>
+
+rename the domain which terminated, and thenimmediately create a new
+domain with the same configuration as the original
+
+=item B<preserve>
+
+keep the domain.  It can be examined, and later destroyed with `xl
+destroy`.
+
+=item B<coredump-destroy>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+destroy the domain.
+
+=item B<coredump-restart>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+restart the domain.
+
+=back
+
+The default for C<on_poweroff> is C<destroy>.
+
+=item B<on_reboot="ACTION">
+
+Action to take if the domain shuts down with a reason code requesting
+a reboot.  Default is C<restart>.
+
+=item B<on_watchdog="ACTION">
+
+Action to take if the domain shuts down due to a Xen watchdog timeout.
+Default is C<destroy>.
+
+=item B<on_crash="ACTION">
+
+Action to take if the domain crashes.  Default is C<destroy>.
+
+=item B<seclabel="LABEL">
+
+Assign an XSM security label to this domain.
+
+=back
+
+=head2 Devices
+
+The following options define the paravirtual, emulated and physical
+devices which the guest will contain.
+
+=over 4
+
+=item B<disk=[ "DISK_SPEC_STRING", "DISK_SPEC_STRING", ...]>
+
+Specifies the disks (both emulated disks and Xen virtual block
+devices) which are to be provided to the guest, and what objects on
+the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
+
+=item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
+
+Specifies the networking provision (both emulated network adapters,
+and Xen virtual interfaces) to provided to the guest.  See
+F<docs/misc/xl-network-configuration.markdown>.
+
+=item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
+
+Specifies the paravirtual framebuffer devices which should be supplied
+to the domain.
+
+This options does not control the emulated graphics card presented to
+an HVM guest. See L<Emulated VGA Graphics Device> below for how to
+configure the emulated device.
+
+Each B<VFB_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
+settings, from the following list:
+
+=over 4
+
+=item C<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item C<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item C<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use.  The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item C<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item C<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item C<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is to not enable this mode
+
+=item C<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using C<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item C<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below or consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item C<display=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=item C<authority=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=back
+
+=item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ... ]>
+
+Specifies the host PCI devices to passthrough to this guest. Each B<PCI_SPEC_STRING>
+has the form C<[DDDD:]BB:DD.F[@VSLOT],KEY=VALUE,KEY=VALUE,...> where:
+
+=over 4
+
+=item B<DDDD:BB:DD.F>
+
+identifies the PCI device from the host perspective in domain
+(B<DDDD>), Bus (B<BB>), Device (B<DD>) and Function (B<F>) syntax. This is
+the same scheme as used in the output of C<lspci> for the device in
+question. Note: By default C<lspci> will omit the domain (B<DDDD>) if it
+is zero and it is optional here also. You may specify the function
+(B<F>) as B<*> to indicate all functions.
+
+=item B<@VSLOT>
+
+specifies the virtual device where the guest will see this
+device. This is equivalent to the B<DD> which the guest sees. In a
+guest B<DDDD> and B<BB> are C<0000:00>. XXX how does this really work?
+
+=item B<KEY=VALUE>
+
+Posible B<KEY>s are:
+
+=over 4
+
+=item B<msitranslate=BOOLEAN>
+
+XXX
+
+=item B<power_mgmt=BOOLEAN>
+
+XXX
+
+=back
+
+=back
+
+=back
+
+=head2 Paravirtualised (PV) Guest Specific Options
+
+The following options apply only to Paravirtual guests.
+
+=over 4
+
+=item B<kernel="PATHNAME">
+
+Load the specified file as the kernel image.  Either B<kernel> or
+B<bootloader> must be specified for PV guests.
+
+=item B<ramdisk="PATHNAME">
+
+Load the specified file as the ramdisk.
+
+=item B<bootloader="PROGRAM">
+
+Run C<PROGRAM> to find the kernel image and ramdisk to use.  Normally
+C<PROGRAM> would be C<pygrub>, which is an emulation of
+grub/grub2/syslinux.
+
+=item B<bootloader_args=STRING>
+
+Append B<STRING> (split into words at whitespace) to the arguments to
+the B<bootloader> program.  XXX this should be a list of strings.
+
+=item B<root="STRING">
+
+Append B<root="STRING"> to the kernel command line (Note: it is guest
+specific what meaning this has).
+
+=item B<extra="STRING">
+
+Append B<STRING> to the kernel command line. Note: it is guest
+specific what meaning this has).
+
+=item B<e820_host=BOOLEAN>
+
+Selects whether to expose the host e820 (memory map) to the guest via
+the virtual e820. When this option is false the guest psuedo-physical
+address space consists of a single contiguous RAM region. When this
+option is specified the virtual e820 instead reflects the host e820
+and contains the same PCI holes. The total amount of RAM represented
+by the memory map is always the same, this option configures only how
+it is layed out.
+
+Exposing the host e820 to the guest gives the guest kernel the
+opportunity to set aside the required part of its pseudo-physical
+address space in order to provide address space to map passedthrough
+PCI devices. It is guest Operaring System dependant whether this
+option is required, specifically it is required when using a mainline
+Linux ("pvops") kernel. This option defaults to true if any PCI
+passthrough devices are configued and false otherwise. If you do not
+configure any passthrough devices at domain creation time but expect
+to hotplug devices later then you should set this option. Conversely
+if your particular guest kernel does not require this behaviour then
+it is safe to allow this to be enabled but you may wish to disable it
+anyway.
+
+=back
+
+=head2 Fully-virtualised (HVM) Guest Specific Options
+
+The following options apply only to HVM guests.
+
+=head3 Boot Device
+
+=over 4
+
+=item B<boot=[c|d|n]>
+
+Selects the emulated virtual device to boot from. Options are hard
+disk (B<c>), cd-rom (B<d>) or network/PXE (B<n>). Multiple options can be
+given and will be attempted in the order they are given. e.g. to boot
+from cd-rom but fallback to the hard disk you can give B<dc>. The
+default is B<cd>.
+
+=back
+
+=head3 Paging
+
+The following options control the mechanisms used to virtualise guest
+memory.  The defaults are selected to give the best results for the
+common case and so you should normally leave these options
+unspecified.
+
+=over 4
+
+=item B<hap=BOOLEAN>
+
+Turns "hardware assisted paging" (the use of the hardware nested page
+table feature) on or off.  This feature is called EPT (Extended Page
+Tables) by Intel and NPT (Nested Page Tables) or RVI (Rapid
+Virtualisation Indexing) by AMD.  Affects HVM guests only.  If turned
+off, Xen will run the guest in "shadow page table" mode where the
+guest's page table updates and/or TLB flushes etc. will be emulated.
+Use of HAP is the default when available.
+
+=item B<oos=BOOLEAN>
+
+Turns "out of sync pagetables" on or off.  When running in shadow page
+table mode, the guest's page table updates may be deferred as
+specified in the Intel/AMD architecture manuals.  However this may
+expose unexpected bugs in the guest, or find bugs in Xen, so it is
+possible to disable this feature.  Use of out of sync page tables,
+when Xen thinks it appropriate, is the default.
+
+=item B<shadow_memory=MBYTES>
+
+Number of megabytes to set aside for shadowing guest pagetable pages
+(effectively acting as a cache of translated pages) or to use for HAP
+state. By default this is 1MB per guest vcpu plus 8KB per MB of guest
+RAM. You should not normally need to adjust this value. However if you
+are not using hardware assisted paging (i.e. you are using shadow
+mode) and your guest workload consists of a a very large number of
+similar processes then increasing this value may improve performance.
+
+=back
+
+=head3 Processor and Platform Features
+
+The following options allow various processor and platform level
+features to be hidden or exposed from the guest's point of view. This
+can be useful when running older guest Operating Systems which may
+misbehave when faced with more modern features. In general you should
+accept the defaults for these options wherever possible.
+
+=over 4
+
+=item B<pae=BOOLEAN>
+
+Hide or expose the IA32 Physical Address Extensions. These extensions
+make it possible for a 32 bit guest Operating System to access more
+than 4GB of RAM. Enabling PAE also enabled other features such as
+NX. PAE is required if you wish to run a 64-bit guest Operating
+System. In general you should leave this enabled and allow the guest
+Operating System to choose whether or not to use PAE. (X86 only)
+
+=item B<acpi=BOOLEAN>
+
+Expose ACPI (Advanced Configuration and Power Interface) tables from
+the virtual firmware to the guest Operating System. ACPI is required
+by most modern guest Operating Systems. This option is enabled by
+default and usually you should omit it. However it may be necessary to
+disable ACPI for compatibility with some guest Operating Systems.
+
+=item B<apic=BOOLEAN>
+
+Include information regarding APIC (Advanced Programmable Interrupt
+Controller) in the firmware/BIOS tables on a single processor
+guest. This causes the MP (multiprocessor) and PIR (PCI Interrupt
+Routing) tables to be exported by the virtual firmware. This option
+has no effect on a guest with multiple virtual CPUS as they must
+always include these tables. This option is enabled by default and you
+should usually omit it but it may be necessary to disable these
+firmware tables when using certain older guest Operating
+Systems. These tables have been superceded by newer constructs within
+the ACPI tables. (X86 only)
+
+=item B<nx=BOOLEAN>
+
+Hides or exposes the No-eXecute capability. This allows a guest
+Operating system to map pages such that they cannot be executed which
+can enhance security. This options requires that PAE also be
+enabled. (X86 only)
+
+=item B<hpet=BOOLEAN>
+
+Enables or disables HPET (High Precision Event Timer). This option is
+enabled by default and you should usually omit it. It may be necessary
+to disable the HPET in order to improve compatibility with guest
+Operating Systems (X86 only)
+
+=item B<nestedhvm=BOOLEAN>
+
+Enable or disables guest access to hardware virtualisation features,
+e.g. it allows a guest Operating System to also function as a
+hypervisor. This option is disabled by default. You may want this
+option if you want to run another hypervisor (including another copy
+of Xen) within a Xen guest or to support a guest Operating System
+which uses hardware virtualisation extensions (e.g. Windows XP
+compatibility mode on more modern Windows OS).
+
+=back 
+
+=head3 Guest Virtual Time Controls
+
+=over 4
+
+=item B<tsc_mode="MODE">
+
+Specifies how the TSC (Time Stamp Counter) should be provided to the
+guest.  XXX ???
+
+=back
+
+=head3 Support for Paravirtualisation of HVM Guests
+
+The following options allow Paravirtualised features (such as devices)
+to be exposed to the guest Operating System in an HVM guest.
+Utilising these features requires specific guest support but when
+available they will result in improved performance.
+
+=over 4
+
+=item B<xen_platform_pci=BOOLEAN>
+
+Enable or disable the Xen platform PCI device.  The presence of this
+virtual device enables a guest Operating System (subject to the
+availability of suitable drivers) to make use of paravirtualisation
+features such as disk and network devices etc. Enabling these drivers
+improves performance and is strongly recommended when available. PV
+drivers are available for various Operating Systems including HVM
+Linux L<http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers> and Microsoft
+Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
+
+=item B<viridian=BOOLEAN>
+
+Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
+compatible enlightenments to the guest.  These can improve performance
+of Microsoft Windows guests (XXX which versions of Windows benefit?)
+
+=back
+
+=head3 Emulated VGA Graphics Device
+
+The following options control the features of the emulated graphics
+device.  Many of these options behave similarly to the equivalent key
+in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
+(see above).
+
+=over 4
+
+=item B<videoram=MBYTES>
+
+Sets the amount of RAM which the emulated video card will contain,
+which in turn limits the resolutions and bit depths which will be
+available. This option is only available when using the B<stdvga>
+option (see below). The default is 8MB which is sufficient for
+e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
+amount of video ram is fixed at 4MB which is sufficient for 1024x768
+at 32 bpp.
+
+=item B<stdvga=BOOLEAN>
+
+Select a standard VGA card with VBE (VESA BIOS Extensions) as the
+emulated graphics device. The default is false which means to emulate
+a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
+later (e.g. Windows XP onwards) then you should enable this.
+
+=item B<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item B<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item B<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use. The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item B<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item B<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item B<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below of consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item B<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is not to enable this mode.
+
+=item B<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using B<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item B<nographic=BOOLEAN>
+
+Enable or disable the virtual graphics device.  The default is to
+provide a VGA graphics device but this option can be used to disable
+it.
+
+=back
+
+=head3 Spice Graphics Support
+
+The following options control the features of SPICE.
+
+=over 4
+
+=item B<spice=BOOLEAN>
+
+Allow access to the display via the SPICE protocol.  This enables the
+other SPICE-related settings.
+
+=item B<spicehost="ADDRESS">
+
+Specify the interface address to listen on if given, otherwise any
+interface.
+
+=item B<spiceport=NUMBER>
+
+Specify the port to listen on by the SPICE server if the SPICE is
+enabled.
+
+=item B<spicetls_port=NUMBER>
+
+Specify the secure port to listen on by the SPICE server if the SPICE
+is enabled. At least one of the spiceport or spicetls_port must be
+given if SPICE is enabled.  NB. the options depending on spicetls_port
+have not been supported.
+
+=item B<spicedisable_ticketing=BOOLEAN>
+
+Enable client connection without password. The default is false. If
+it's false (set to 0), spicepasswd must be set.
+
+=item B<spicepasswd="PASSWORD">
+
+Specify the ticket password which is used by a client for connection.
+
+=item B<spiceagent_mouse=BOOLEAN>
+
+Whether SPICE agent is used for client mouse mode. The default is true
+(turn on)
+
+=back
+
+=head3 Miscellaneous Emulated Hardware
+
+=over 4
+
+=item B<serial=DEVICE>
+
+Redirect the virtual serial port to B<DEVICE>. Please see the
+B<-serial> option in the L<qemu(1)> manpage for details of the valid
+B<DEVICE> options. Default is B<vc> when in graphical mode and
+B<stdio> if B<nographics=1> is used.
+
+=item B<soundhw=DEVICE>
+
+Select the virtual sound card to expose to the guest. The valid
+devices are defined by the device model configuration, please see the
+L<qemu(1)> manpage for details. The default is not to export any sound
+device.
+
+=item B<usb=BOOLEAN>
+
+Enables or disables a USB bus in the guest.
+
+=item B<usbdevice=DEVICE>
+
+Adds B<DEVICE> to the USB bus. The USB bus must also be enabled using
+B<usb=1>. The most common use for this option is B<usbdevice=tablet>
+which adds pointer device using absolute coordinates. Such devices
+function better than relative coordinate devices (such as a standard
+mouse) since many methods of exporting guest graphics (such as VNC)
+work better in this mode. Note that this is independent of the actual
+pointer device you are using on the host/client side. XXX should/could
+be a list of devices.
+
+=back
+
+=head3 Unclassified HVM Specific Options
+
+These HVM specific options have not yet been documented or
+classified. They almost certainly belong in a more appropriate
+section.
+
+=over 4
+
+=item B<vpt_align=BOOLEAN>
+
+Align the Virtual Platform Timer ??? XXX Reduces interrupts?
+
+=item B<timer_mode=NUMBER>
+
+Set mode for Virtual Timers XXX ??? should be an enum of particular
+values. See C<HVM_PARAM_TIMER_MODE> in
+F<xen/include/public/hvm/params.h>.
+
+=back
+
+=head2 Device-Model Options
+
+The following options control the selection of the device-model.  This
+is the component which provides emulation of the virtual devices to an
+HVM guest.  For a PV guest a device-model is sometimes used to provide
+backends for certain PV devices (most usually a virtual framebuffer
+device).
+
+=over 4
+
+=item B<device_model_version="DEVICE-MODEL">
+
+Selects which variant of the device-model should be used for this
+guest. Valid values are:
+
+=over 4
+
+=item B<qemu-xen-traditional>
+
+Use the device-model based upon the historical Xen fork of Qemu.  This
+device-model is currently the default.
+
+=item B<qemu-xen>
+
+use the device-model merged into the upstream Qemu project.  This
+device-model will become the default in a future version of Xen.
+
+=back
+
+It is recommended to accept the default value for new guests.  If
+you have existing guests then, depeending on the nature of the guest
+Operating System, you may wish to force them to use the device
+model which they were installed with.
+
+=item B<device_model_override="PATH">
+
+Override the path to the binary to be used as the device-model. The
+binary provided here MUST be consistent with the
+`device_model_version` which you have specified. You should not
+normally need to specify this option.
+
+=item B<device_model_stubdomain_override=BOOLEAN>
+
+Override the use of stubdomain based device-model.  Normally this will
+be automatically selected based upon the other features and options
+you have selected.
+
+=item B<device_model_args=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command
+line. Each element in the list is passed as an option to the
+device-model.
+
+=item B<device_model_args_pv=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+a PV device model only. Each element in the list is passed as an
+option to the device-model.
+
+=item B<device_model_args_hvm=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+an HVM device model only. Each element in the list is passed as an
+option to the device-model.
+
+=back
+
+=head2 Unclassified General Options
+
+These have not yet been fully documented or classified. They almost
+certainly belong in a more appropriate section.
+
+=over 4
+
+=item B<gfx_passthrough=BOOLEAN>
+
+Enable graphics device PCI passthrough. XXX which device is passed through ?
+
+=item B<nomigrate=BOOLEAN>
+
+Disable migration of this domain.  This enables certain other features
+which are incompatible with migration (currently certain TSC modes XXX
+?).
+
+=item B<pci_msitranslate=BOOLEAN>
+
+XXX
+
+=item B<pci_power_mgmt=BOOLEAN>
+
+XXX
+
+=item B<cpuid=XXX>
+
+XXX
+
+=back
+
+=head2 Keymaps
+
+The keymaps available are defined by the device-model which you are
+using. Commonly this includes:
+
+        ar  de-ch  es  fo     fr-ca  hu  ja  mk     no  pt-br  sv
+        da  en-gb  et  fr     fr-ch  is  lt  nl     pl  ru     th
+        de  en-us  fi  fr-be  hr     it  lv  nl-be  pt  sl     tr
+
+The default is B<en-us>.
+
+See L<qemu(1)> for more information.
+
+=head1 SEE ALSO
+
+=over 4
+
+=item L<xl(1)>
+
+=item F<xl-disk-configuration>
+
+=item F<xl-network-configuration>
+
+=back
+
+=head1 FILES
+
+F</etc/xen/NAME.cfg>
+F</var/xen/dump/NAME>
+F<docs/misc/tscmode.txt>
+
+=head1 BUGS
+
+This document is a work in progress and contains items which require
+further documentation and which are generally incomplete (marked with
+XXX).  However all options are included here whether or not they are
+fully documented.
+
+Patches to improve incomplete items (or any other item) would be
+greatfully received on the xen-devel@lists.xensource.com mailing
+list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
+information on how to submit a patch to Xen.
+
diff -r f0d2cd2deb21 -r ce3fa9ade7c1 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/man/xl.pod.1	Tue Nov 29 14:17:27 2011 +0000
@@ -54,7 +54,7 @@ previously, most commands take I<domain-
 
 =item B<create> [I<OPTIONS>] I<configfile>
 
-The create subcommand requires a config file: see L<xldomain.cfg> for
+The create subcommand requires a config file: see L<xl.cfg(5)> for
 full details of that file format and possible options.
 
 I<configfile> can either be an absolute path to a file, or a relative
@@ -232,7 +232,7 @@ FIXME: Why would you ever see this state
 
 The domain has crashed, which is always a violent ending.  Usually
 this state can only occur if the domain has been configured not to
-restart on crash.  See L<xldomain.cfg> for more info.
+restart on crash.  See L<xl.cfg(5)> for more info.
 
 =item B<d - dying>
 
@@ -319,8 +319,8 @@ executed the reboot action, which may be
 domain actually reboots.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_reboot> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_reboot> parameter of the domain configuration file when the
+domain was created.
 
 =item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile>
 
@@ -372,8 +372,8 @@ services must be shutdown in the domain.
 immediately after signally the domain unless that B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_shutdown> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_shutdown> parameter of the domain configuration file when the
+domain was created.
 
 B<OPTIONS>
 
@@ -699,7 +699,7 @@ The domain id of the guest domain that t
 =item I<disc-spec-component>
 
 A disc specification in the same format used for the B<disk> variable in
-the domain config file. See L<xldomain.cfg>.
+the domain config file. See F<xl-disk-configuration>.
 
 =back
 
@@ -733,9 +733,9 @@ How the device should be presented to th
 
 =item I<be-dev>
 
-the device in the backend domain (usually domain 0) to be exported; it can be a
-path to a file (file://path/to/file.iso). See B<disk> in L<xldomain.cfg> for the
-details.
+the device in the backend domain (usually domain 0) to be exported; it
+can be a path to a file (file://path/to/file.iso). See B<disk> in
+L<xl.cfg(5)> for the details.
 
 =back
 
@@ -754,7 +754,7 @@ I<VirtualDevice> is the cdrom device in 
 
 Creates a new network device in the domain specified by I<domain-id>.
 I<network-device> describes the device to attach, using the same format as the
-B<vif> string in the domain config file. See L<xldomain.cfg> for the
+B<vif> string in the domain config file. See L<xl.cfg(5)> for the
 description.
 
 =item B<network-detach> I<domain-id> I<devid|mac>
@@ -795,7 +795,7 @@ List pass-through pci devices for a doma
 
 =head1 SEE ALSO
 
-B<xldomain.cfg>(5), B<xlcpupool.cfg>(5), B<xentop>(1)
+L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
 
 =head1 AUTHOR
 
diff -r f0d2cd2deb21 -r ce3fa9ade7c1 tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/examples/xlexample.hvm	Tue Nov 29 14:17:27 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for an
-# HVM guest. For a more complete guide see <XXX Document TBD>
+# HVM guest. For a more complete guide see xl.cfg(5)
 
 # This configures an HVM rather than PV guest
 builder = "hvm"
diff -r f0d2cd2deb21 -r ce3fa9ade7c1 tools/examples/xlexample.pvlinux
--- a/tools/examples/xlexample.pvlinux	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/examples/xlexample.pvlinux	Tue Nov 29 14:17:27 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for a
-# Paravirtualised Linux guest. For a more complete guide see <XXX Document TBD>
+# Paravirtualised Linux guest. For a more complete guide see xl.cfg(5)
 
 # Guest name
 name = "example.pvlinux"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYs-00057x-AF; Tue, 29 Nov 2011 14:21:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYq-00055w-Vp
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322576446!5152993!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26028 invoked from network); 29 Nov 2011 14:20:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488416"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:50 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0Q018170;	Tue, 29 Nov 2011 06:20:48 -0800
MIME-Version: 1.0
X-Mercurial-Node: ce3fa9ade7c176b4439aba566551ed2b48915d67
Message-ID: <ce3fa9ade7c176b4439a.1322576447@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:47 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 05 of 17 v3] docs: add a document describing the
 xl cfg file syntax
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID ce3fa9ade7c176b4439aba566551ed2b48915d67
# Parent  f0d2cd2deb2124563bf5681665840d66fab0f232
docs: add a document describing the xl cfg file syntax

Based on an initial version by Ian Jackson.

I believe that all keys are now present in the document although there are are
various omissions in the actual documentation of them. Hopefully however this
covers the majority of the most interesting keys.

Spice section:
Signed-off-by: Zhou Peng <zhoupeng@nfs.iscas.ac.cn>

The rest:
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f0d2cd2deb21 -r ce3fa9ade7c1 docs/man/xl.cfg.pod.5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
@@ -0,0 +1,844 @@
+=head1 NAME
+
+xl.cfg - XL Domain Configuration File Syntax
+
+=head1 SYNOPSIS
+
+ /etc/xen/xldomain
+
+=head1 DESCRIPTION
+
+To create a VM (a domain in Xen terminology, sometimes called a guest)
+with xl requires the provision of a domain config file.  Typically
+these live in `/etc/xen/DOMAIN.cfg` where DOMAIN is the name of the
+domain.
+
+=head1 SYNTAX
+
+A domain config file consists of a series of C<KEY=VALUE> pairs.
+
+Some C<KEY>s are mandatory, others are global options which apply to
+any guest type while others relate only to specific guest types
+(e.g. PV or HVM guests).
+
+A value C<VALUE> is one of:
+
+=over 4
+
+=item B<"STRING">
+
+A string, surrounded by either single or double quotes.
+
+=item B<NUMBER>
+
+A number, in either decimal, octal (using a C<0> prefix) or
+hexadecimal (using an C<0x> prefix).
+
+=item B<BOOLEAN>
+
+A C<NUMBER> interpreted as C<False> (C<0>) or C<True> (any other
+value).
+
+=item B<[ VALUE, VALUE, ... ]>
+
+A list of C<VALUES> of the above types. Lists are homogeneous and are
+not nested.
+
+=back
+
+The semantics of each C<KEY> defines which form of C<VALUE> is required.
+
+=head1 OPTIONS
+
+=head2 Mandatory Configuration Items
+
+The following key is mandatory for any guest type:
+
+=over 4
+
+=item B<name="NAME">
+
+Specifies the name of the domain.  Names of domains existing on a
+single host must be unique.
+
+=back
+
+=head2 Selecting Guest Type
+
+=over 4
+
+=item B<builder="generic">
+
+Specifies that this is to be a PV domain. This is the default.
+
+=item B<builder="hvm">
+
+Specifies that this is to be an HVM domain.  That is, a fully
+virtualised computer with emulated BIOS, disk and network peripherals,
+etc.  The default is a PV domain, suitable for hosting Xen-aware guest
+operating systems.
+
+=back
+
+=head2 Global Options
+
+The following options apply to guests of any type.
+
+=over 4
+
+=item B<uuid="UUID">
+
+Specifies the UUID of the domain.  If not specified, a fresh unique
+UUID will be generated.
+
+=item B<pool="CPUPOOLNAME">
+
+Put the guest's vcpus into the named cpu pool.
+
+=item B<vcpus=N>
+
+Start the guest with N vcpus initially online.
+
+=item B<maxvcpus=M>
+
+Allow the guest to bring up a maximum of M vcpus. At start of day if
+`vcpus=N` is less than `maxvcpus=M` then the first `N` vcpus will be
+created online and the remainder will be offline.
+
+=item B<memory=MBYTES>
+
+Start the guest with MBYTES megabytes of RAM.
+
+=item B<on_poweroff="ACTION">
+
+Specifies what should be done with the domain if it shuts itself down.
+The C<ACTION>s are:
+
+=over 4
+
+=item B<destroy>
+
+destroy the domain
+     
+=item B<restart>
+
+destroy the domain and immediately create a new domain with the same
+configuration
+        
+=item B<rename-restart>
+
+rename the domain which terminated, and thenimmediately create a new
+domain with the same configuration as the original
+
+=item B<preserve>
+
+keep the domain.  It can be examined, and later destroyed with `xl
+destroy`.
+
+=item B<coredump-destroy>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+destroy the domain.
+
+=item B<coredump-restart>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and then
+restart the domain.
+
+=back
+
+The default for C<on_poweroff> is C<destroy>.
+
+=item B<on_reboot="ACTION">
+
+Action to take if the domain shuts down with a reason code requesting
+a reboot.  Default is C<restart>.
+
+=item B<on_watchdog="ACTION">
+
+Action to take if the domain shuts down due to a Xen watchdog timeout.
+Default is C<destroy>.
+
+=item B<on_crash="ACTION">
+
+Action to take if the domain crashes.  Default is C<destroy>.
+
+=item B<seclabel="LABEL">
+
+Assign an XSM security label to this domain.
+
+=back
+
+=head2 Devices
+
+The following options define the paravirtual, emulated and physical
+devices which the guest will contain.
+
+=over 4
+
+=item B<disk=[ "DISK_SPEC_STRING", "DISK_SPEC_STRING", ...]>
+
+Specifies the disks (both emulated disks and Xen virtual block
+devices) which are to be provided to the guest, and what objects on
+the they should map to.  See F<docs/misc/xl-disk-configuration.txt>.
+
+=item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING", ...]>
+
+Specifies the networking provision (both emulated network adapters,
+and Xen virtual interfaces) to provided to the guest.  See
+F<docs/misc/xl-network-configuration.markdown>.
+
+=item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
+
+Specifies the paravirtual framebuffer devices which should be supplied
+to the domain.
+
+This options does not control the emulated graphics card presented to
+an HVM guest. See L<Emulated VGA Graphics Device> below for how to
+configure the emulated device.
+
+Each B<VFB_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
+settings, from the following list:
+
+=over 4
+
+=item C<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item C<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item C<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use.  The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item C<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item C<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item C<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is to not enable this mode
+
+=item C<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using C<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item C<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below or consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item C<display=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=item C<authority=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=back
+
+=item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ... ]>
+
+Specifies the host PCI devices to passthrough to this guest. Each B<PCI_SPEC_STRING>
+has the form C<[DDDD:]BB:DD.F[@VSLOT],KEY=VALUE,KEY=VALUE,...> where:
+
+=over 4
+
+=item B<DDDD:BB:DD.F>
+
+identifies the PCI device from the host perspective in domain
+(B<DDDD>), Bus (B<BB>), Device (B<DD>) and Function (B<F>) syntax. This is
+the same scheme as used in the output of C<lspci> for the device in
+question. Note: By default C<lspci> will omit the domain (B<DDDD>) if it
+is zero and it is optional here also. You may specify the function
+(B<F>) as B<*> to indicate all functions.
+
+=item B<@VSLOT>
+
+specifies the virtual device where the guest will see this
+device. This is equivalent to the B<DD> which the guest sees. In a
+guest B<DDDD> and B<BB> are C<0000:00>. XXX how does this really work?
+
+=item B<KEY=VALUE>
+
+Posible B<KEY>s are:
+
+=over 4
+
+=item B<msitranslate=BOOLEAN>
+
+XXX
+
+=item B<power_mgmt=BOOLEAN>
+
+XXX
+
+=back
+
+=back
+
+=back
+
+=head2 Paravirtualised (PV) Guest Specific Options
+
+The following options apply only to Paravirtual guests.
+
+=over 4
+
+=item B<kernel="PATHNAME">
+
+Load the specified file as the kernel image.  Either B<kernel> or
+B<bootloader> must be specified for PV guests.
+
+=item B<ramdisk="PATHNAME">
+
+Load the specified file as the ramdisk.
+
+=item B<bootloader="PROGRAM">
+
+Run C<PROGRAM> to find the kernel image and ramdisk to use.  Normally
+C<PROGRAM> would be C<pygrub>, which is an emulation of
+grub/grub2/syslinux.
+
+=item B<bootloader_args=STRING>
+
+Append B<STRING> (split into words at whitespace) to the arguments to
+the B<bootloader> program.  XXX this should be a list of strings.
+
+=item B<root="STRING">
+
+Append B<root="STRING"> to the kernel command line (Note: it is guest
+specific what meaning this has).
+
+=item B<extra="STRING">
+
+Append B<STRING> to the kernel command line. Note: it is guest
+specific what meaning this has).
+
+=item B<e820_host=BOOLEAN>
+
+Selects whether to expose the host e820 (memory map) to the guest via
+the virtual e820. When this option is false the guest psuedo-physical
+address space consists of a single contiguous RAM region. When this
+option is specified the virtual e820 instead reflects the host e820
+and contains the same PCI holes. The total amount of RAM represented
+by the memory map is always the same, this option configures only how
+it is layed out.
+
+Exposing the host e820 to the guest gives the guest kernel the
+opportunity to set aside the required part of its pseudo-physical
+address space in order to provide address space to map passedthrough
+PCI devices. It is guest Operaring System dependant whether this
+option is required, specifically it is required when using a mainline
+Linux ("pvops") kernel. This option defaults to true if any PCI
+passthrough devices are configued and false otherwise. If you do not
+configure any passthrough devices at domain creation time but expect
+to hotplug devices later then you should set this option. Conversely
+if your particular guest kernel does not require this behaviour then
+it is safe to allow this to be enabled but you may wish to disable it
+anyway.
+
+=back
+
+=head2 Fully-virtualised (HVM) Guest Specific Options
+
+The following options apply only to HVM guests.
+
+=head3 Boot Device
+
+=over 4
+
+=item B<boot=[c|d|n]>
+
+Selects the emulated virtual device to boot from. Options are hard
+disk (B<c>), cd-rom (B<d>) or network/PXE (B<n>). Multiple options can be
+given and will be attempted in the order they are given. e.g. to boot
+from cd-rom but fallback to the hard disk you can give B<dc>. The
+default is B<cd>.
+
+=back
+
+=head3 Paging
+
+The following options control the mechanisms used to virtualise guest
+memory.  The defaults are selected to give the best results for the
+common case and so you should normally leave these options
+unspecified.
+
+=over 4
+
+=item B<hap=BOOLEAN>
+
+Turns "hardware assisted paging" (the use of the hardware nested page
+table feature) on or off.  This feature is called EPT (Extended Page
+Tables) by Intel and NPT (Nested Page Tables) or RVI (Rapid
+Virtualisation Indexing) by AMD.  Affects HVM guests only.  If turned
+off, Xen will run the guest in "shadow page table" mode where the
+guest's page table updates and/or TLB flushes etc. will be emulated.
+Use of HAP is the default when available.
+
+=item B<oos=BOOLEAN>
+
+Turns "out of sync pagetables" on or off.  When running in shadow page
+table mode, the guest's page table updates may be deferred as
+specified in the Intel/AMD architecture manuals.  However this may
+expose unexpected bugs in the guest, or find bugs in Xen, so it is
+possible to disable this feature.  Use of out of sync page tables,
+when Xen thinks it appropriate, is the default.
+
+=item B<shadow_memory=MBYTES>
+
+Number of megabytes to set aside for shadowing guest pagetable pages
+(effectively acting as a cache of translated pages) or to use for HAP
+state. By default this is 1MB per guest vcpu plus 8KB per MB of guest
+RAM. You should not normally need to adjust this value. However if you
+are not using hardware assisted paging (i.e. you are using shadow
+mode) and your guest workload consists of a a very large number of
+similar processes then increasing this value may improve performance.
+
+=back
+
+=head3 Processor and Platform Features
+
+The following options allow various processor and platform level
+features to be hidden or exposed from the guest's point of view. This
+can be useful when running older guest Operating Systems which may
+misbehave when faced with more modern features. In general you should
+accept the defaults for these options wherever possible.
+
+=over 4
+
+=item B<pae=BOOLEAN>
+
+Hide or expose the IA32 Physical Address Extensions. These extensions
+make it possible for a 32 bit guest Operating System to access more
+than 4GB of RAM. Enabling PAE also enabled other features such as
+NX. PAE is required if you wish to run a 64-bit guest Operating
+System. In general you should leave this enabled and allow the guest
+Operating System to choose whether or not to use PAE. (X86 only)
+
+=item B<acpi=BOOLEAN>
+
+Expose ACPI (Advanced Configuration and Power Interface) tables from
+the virtual firmware to the guest Operating System. ACPI is required
+by most modern guest Operating Systems. This option is enabled by
+default and usually you should omit it. However it may be necessary to
+disable ACPI for compatibility with some guest Operating Systems.
+
+=item B<apic=BOOLEAN>
+
+Include information regarding APIC (Advanced Programmable Interrupt
+Controller) in the firmware/BIOS tables on a single processor
+guest. This causes the MP (multiprocessor) and PIR (PCI Interrupt
+Routing) tables to be exported by the virtual firmware. This option
+has no effect on a guest with multiple virtual CPUS as they must
+always include these tables. This option is enabled by default and you
+should usually omit it but it may be necessary to disable these
+firmware tables when using certain older guest Operating
+Systems. These tables have been superceded by newer constructs within
+the ACPI tables. (X86 only)
+
+=item B<nx=BOOLEAN>
+
+Hides or exposes the No-eXecute capability. This allows a guest
+Operating system to map pages such that they cannot be executed which
+can enhance security. This options requires that PAE also be
+enabled. (X86 only)
+
+=item B<hpet=BOOLEAN>
+
+Enables or disables HPET (High Precision Event Timer). This option is
+enabled by default and you should usually omit it. It may be necessary
+to disable the HPET in order to improve compatibility with guest
+Operating Systems (X86 only)
+
+=item B<nestedhvm=BOOLEAN>
+
+Enable or disables guest access to hardware virtualisation features,
+e.g. it allows a guest Operating System to also function as a
+hypervisor. This option is disabled by default. You may want this
+option if you want to run another hypervisor (including another copy
+of Xen) within a Xen guest or to support a guest Operating System
+which uses hardware virtualisation extensions (e.g. Windows XP
+compatibility mode on more modern Windows OS).
+
+=back 
+
+=head3 Guest Virtual Time Controls
+
+=over 4
+
+=item B<tsc_mode="MODE">
+
+Specifies how the TSC (Time Stamp Counter) should be provided to the
+guest.  XXX ???
+
+=back
+
+=head3 Support for Paravirtualisation of HVM Guests
+
+The following options allow Paravirtualised features (such as devices)
+to be exposed to the guest Operating System in an HVM guest.
+Utilising these features requires specific guest support but when
+available they will result in improved performance.
+
+=over 4
+
+=item B<xen_platform_pci=BOOLEAN>
+
+Enable or disable the Xen platform PCI device.  The presence of this
+virtual device enables a guest Operating System (subject to the
+availability of suitable drivers) to make use of paravirtualisation
+features such as disk and network devices etc. Enabling these drivers
+improves performance and is strongly recommended when available. PV
+drivers are available for various Operating Systems including HVM
+Linux L<http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers> and Microsoft
+Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
+
+=item B<viridian=BOOLEAN>
+
+Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
+compatible enlightenments to the guest.  These can improve performance
+of Microsoft Windows guests (XXX which versions of Windows benefit?)
+
+=back
+
+=head3 Emulated VGA Graphics Device
+
+The following options control the features of the emulated graphics
+device.  Many of these options behave similarly to the equivalent key
+in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
+(see above).
+
+=over 4
+
+=item B<videoram=MBYTES>
+
+Sets the amount of RAM which the emulated video card will contain,
+which in turn limits the resolutions and bit depths which will be
+available. This option is only available when using the B<stdvga>
+option (see below). The default is 8MB which is sufficient for
+e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
+amount of video ram is fixed at 4MB which is sufficient for 1024x768
+at 32 bpp.
+
+=item B<stdvga=BOOLEAN>
+
+Select a standard VGA card with VBE (VESA BIOS Extensions) as the
+emulated graphics device. The default is false which means to emulate
+a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
+later (e.g. Windows XP onwards) then you should enable this.
+
+=item B<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item B<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item B<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use. The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item B<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item B<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item B<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below of consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item B<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is not to enable this mode.
+
+=item B<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using B<device_model_version="qemu-xen-traditonal"> and only if the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item B<nographic=BOOLEAN>
+
+Enable or disable the virtual graphics device.  The default is to
+provide a VGA graphics device but this option can be used to disable
+it.
+
+=back
+
+=head3 Spice Graphics Support
+
+The following options control the features of SPICE.
+
+=over 4
+
+=item B<spice=BOOLEAN>
+
+Allow access to the display via the SPICE protocol.  This enables the
+other SPICE-related settings.
+
+=item B<spicehost="ADDRESS">
+
+Specify the interface address to listen on if given, otherwise any
+interface.
+
+=item B<spiceport=NUMBER>
+
+Specify the port to listen on by the SPICE server if the SPICE is
+enabled.
+
+=item B<spicetls_port=NUMBER>
+
+Specify the secure port to listen on by the SPICE server if the SPICE
+is enabled. At least one of the spiceport or spicetls_port must be
+given if SPICE is enabled.  NB. the options depending on spicetls_port
+have not been supported.
+
+=item B<spicedisable_ticketing=BOOLEAN>
+
+Enable client connection without password. The default is false. If
+it's false (set to 0), spicepasswd must be set.
+
+=item B<spicepasswd="PASSWORD">
+
+Specify the ticket password which is used by a client for connection.
+
+=item B<spiceagent_mouse=BOOLEAN>
+
+Whether SPICE agent is used for client mouse mode. The default is true
+(turn on)
+
+=back
+
+=head3 Miscellaneous Emulated Hardware
+
+=over 4
+
+=item B<serial=DEVICE>
+
+Redirect the virtual serial port to B<DEVICE>. Please see the
+B<-serial> option in the L<qemu(1)> manpage for details of the valid
+B<DEVICE> options. Default is B<vc> when in graphical mode and
+B<stdio> if B<nographics=1> is used.
+
+=item B<soundhw=DEVICE>
+
+Select the virtual sound card to expose to the guest. The valid
+devices are defined by the device model configuration, please see the
+L<qemu(1)> manpage for details. The default is not to export any sound
+device.
+
+=item B<usb=BOOLEAN>
+
+Enables or disables a USB bus in the guest.
+
+=item B<usbdevice=DEVICE>
+
+Adds B<DEVICE> to the USB bus. The USB bus must also be enabled using
+B<usb=1>. The most common use for this option is B<usbdevice=tablet>
+which adds pointer device using absolute coordinates. Such devices
+function better than relative coordinate devices (such as a standard
+mouse) since many methods of exporting guest graphics (such as VNC)
+work better in this mode. Note that this is independent of the actual
+pointer device you are using on the host/client side. XXX should/could
+be a list of devices.
+
+=back
+
+=head3 Unclassified HVM Specific Options
+
+These HVM specific options have not yet been documented or
+classified. They almost certainly belong in a more appropriate
+section.
+
+=over 4
+
+=item B<vpt_align=BOOLEAN>
+
+Align the Virtual Platform Timer ??? XXX Reduces interrupts?
+
+=item B<timer_mode=NUMBER>
+
+Set mode for Virtual Timers XXX ??? should be an enum of particular
+values. See C<HVM_PARAM_TIMER_MODE> in
+F<xen/include/public/hvm/params.h>.
+
+=back
+
+=head2 Device-Model Options
+
+The following options control the selection of the device-model.  This
+is the component which provides emulation of the virtual devices to an
+HVM guest.  For a PV guest a device-model is sometimes used to provide
+backends for certain PV devices (most usually a virtual framebuffer
+device).
+
+=over 4
+
+=item B<device_model_version="DEVICE-MODEL">
+
+Selects which variant of the device-model should be used for this
+guest. Valid values are:
+
+=over 4
+
+=item B<qemu-xen-traditional>
+
+Use the device-model based upon the historical Xen fork of Qemu.  This
+device-model is currently the default.
+
+=item B<qemu-xen>
+
+use the device-model merged into the upstream Qemu project.  This
+device-model will become the default in a future version of Xen.
+
+=back
+
+It is recommended to accept the default value for new guests.  If
+you have existing guests then, depeending on the nature of the guest
+Operating System, you may wish to force them to use the device
+model which they were installed with.
+
+=item B<device_model_override="PATH">
+
+Override the path to the binary to be used as the device-model. The
+binary provided here MUST be consistent with the
+`device_model_version` which you have specified. You should not
+normally need to specify this option.
+
+=item B<device_model_stubdomain_override=BOOLEAN>
+
+Override the use of stubdomain based device-model.  Normally this will
+be automatically selected based upon the other features and options
+you have selected.
+
+=item B<device_model_args=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command
+line. Each element in the list is passed as an option to the
+device-model.
+
+=item B<device_model_args_pv=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+a PV device model only. Each element in the list is passed as an
+option to the device-model.
+
+=item B<device_model_args_hvm=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+an HVM device model only. Each element in the list is passed as an
+option to the device-model.
+
+=back
+
+=head2 Unclassified General Options
+
+These have not yet been fully documented or classified. They almost
+certainly belong in a more appropriate section.
+
+=over 4
+
+=item B<gfx_passthrough=BOOLEAN>
+
+Enable graphics device PCI passthrough. XXX which device is passed through ?
+
+=item B<nomigrate=BOOLEAN>
+
+Disable migration of this domain.  This enables certain other features
+which are incompatible with migration (currently certain TSC modes XXX
+?).
+
+=item B<pci_msitranslate=BOOLEAN>
+
+XXX
+
+=item B<pci_power_mgmt=BOOLEAN>
+
+XXX
+
+=item B<cpuid=XXX>
+
+XXX
+
+=back
+
+=head2 Keymaps
+
+The keymaps available are defined by the device-model which you are
+using. Commonly this includes:
+
+        ar  de-ch  es  fo     fr-ca  hu  ja  mk     no  pt-br  sv
+        da  en-gb  et  fr     fr-ch  is  lt  nl     pl  ru     th
+        de  en-us  fi  fr-be  hr     it  lv  nl-be  pt  sl     tr
+
+The default is B<en-us>.
+
+See L<qemu(1)> for more information.
+
+=head1 SEE ALSO
+
+=over 4
+
+=item L<xl(1)>
+
+=item F<xl-disk-configuration>
+
+=item F<xl-network-configuration>
+
+=back
+
+=head1 FILES
+
+F</etc/xen/NAME.cfg>
+F</var/xen/dump/NAME>
+F<docs/misc/tscmode.txt>
+
+=head1 BUGS
+
+This document is a work in progress and contains items which require
+further documentation and which are generally incomplete (marked with
+XXX).  However all options are included here whether or not they are
+fully documented.
+
+Patches to improve incomplete items (or any other item) would be
+greatfully received on the xen-devel@lists.xensource.com mailing
+list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
+information on how to submit a patch to Xen.
+
diff -r f0d2cd2deb21 -r ce3fa9ade7c1 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/man/xl.pod.1	Tue Nov 29 14:17:27 2011 +0000
@@ -54,7 +54,7 @@ previously, most commands take I<domain-
 
 =item B<create> [I<OPTIONS>] I<configfile>
 
-The create subcommand requires a config file: see L<xldomain.cfg> for
+The create subcommand requires a config file: see L<xl.cfg(5)> for
 full details of that file format and possible options.
 
 I<configfile> can either be an absolute path to a file, or a relative
@@ -232,7 +232,7 @@ FIXME: Why would you ever see this state
 
 The domain has crashed, which is always a violent ending.  Usually
 this state can only occur if the domain has been configured not to
-restart on crash.  See L<xldomain.cfg> for more info.
+restart on crash.  See L<xl.cfg(5)> for more info.
 
 =item B<d - dying>
 
@@ -319,8 +319,8 @@ executed the reboot action, which may be
 domain actually reboots.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_reboot> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_reboot> parameter of the domain configuration file when the
+domain was created.
 
 =item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile>
 
@@ -372,8 +372,8 @@ services must be shutdown in the domain.
 immediately after signally the domain unless that B<-w> flag is used.
 
 The behavior of what happens to a domain when it reboots is set by the
-B<on_shutdown> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_shutdown> parameter of the domain configuration file when the
+domain was created.
 
 B<OPTIONS>
 
@@ -699,7 +699,7 @@ The domain id of the guest domain that t
 =item I<disc-spec-component>
 
 A disc specification in the same format used for the B<disk> variable in
-the domain config file. See L<xldomain.cfg>.
+the domain config file. See F<xl-disk-configuration>.
 
 =back
 
@@ -733,9 +733,9 @@ How the device should be presented to th
 
 =item I<be-dev>
 
-the device in the backend domain (usually domain 0) to be exported; it can be a
-path to a file (file://path/to/file.iso). See B<disk> in L<xldomain.cfg> for the
-details.
+the device in the backend domain (usually domain 0) to be exported; it
+can be a path to a file (file://path/to/file.iso). See B<disk> in
+L<xl.cfg(5)> for the details.
 
 =back
 
@@ -754,7 +754,7 @@ I<VirtualDevice> is the cdrom device in 
 
 Creates a new network device in the domain specified by I<domain-id>.
 I<network-device> describes the device to attach, using the same format as the
-B<vif> string in the domain config file. See L<xldomain.cfg> for the
+B<vif> string in the domain config file. See L<xl.cfg(5)> for the
 description.
 
 =item B<network-detach> I<domain-id> I<devid|mac>
@@ -795,7 +795,7 @@ List pass-through pci devices for a doma
 
 =head1 SEE ALSO
 
-B<xldomain.cfg>(5), B<xlcpupool.cfg>(5), B<xentop>(1)
+L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
 
 =head1 AUTHOR
 
diff -r f0d2cd2deb21 -r ce3fa9ade7c1 tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/examples/xlexample.hvm	Tue Nov 29 14:17:27 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for an
-# HVM guest. For a more complete guide see <XXX Document TBD>
+# HVM guest. For a more complete guide see xl.cfg(5)
 
 # This configures an HVM rather than PV guest
 builder = "hvm"
diff -r f0d2cd2deb21 -r ce3fa9ade7c1 tools/examples/xlexample.pvlinux
--- a/tools/examples/xlexample.pvlinux	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/examples/xlexample.pvlinux	Tue Nov 29 14:17:27 2011 +0000
@@ -3,7 +3,7 @@
 # =====================================================================
 #
 # This is a fairly minimal example of what is required for a
-# Paravirtualised Linux guest. For a more complete guide see <XXX Document TBD>
+# Paravirtualised Linux guest. For a more complete guide see xl.cfg(5)
 
 # Guest name
 name = "example.pvlinux"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYv-00059N-1k; Tue, 29 Nov 2011 14:21:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYt-00056H-Ff
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15126 invoked from network); 29 Nov 2011 14:20:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184206"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0U018170;	Tue, 29 Nov 2011 06:20:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: e515bb651349f69c2084e4916d999634287c1480
Message-ID: <e515bb651349f69c2084.1322576451@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 09 of 17 v3] docs: remove non-breaking spaces
 from sedf_scheduler_mini-HOWTO.txt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6865025988204818564=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6865025988204818564==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID e515bb651349f69c2084e4916d999634287c1480
# Parent  c6a2b11a2bd442220395ae117c33925619788204
docs: remove non-breaking spaces from sedf_scheduler_mini-HOWTO.txt

This document contains several 0xa0 characters (non-breaking spaces). These do
not display correctly in (some) terminals or when the document is rendered by (some)
browsers. Re-encode them as spaces.

I'm not confident that this change will make it through being encoded as a patch
and sent through email. Its effect can be replicated with:

	perl -i -p -e 's/\xa0/ /g' docs/misc/sedf_scheduler_mini-HOWTO.txt

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c6a2b11a2bd4 -r e515bb651349 docs/misc/sedf_scheduler_mini-HOWTO.txt
--- a/docs/misc/sedf_scheduler_mini-HOWTO.txt	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/misc/sedf_scheduler_mini-HOWTO.txt	Tue Nov 29 14:17:27 2011 +0000
@@ -8,37 +8,37 @@ Overview:
   uses realtime-algorithms to ensure time guarantees.
 
 Usage:
-   -add "sched=sedf" on Xen's boot command-line
-   -create domains as usual
-   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
-    Where:
-      -period/slice are the normal EDF scheduling parameters in nanosecs
-      -latency-hint is the scaled period in case the domain is doing heavy I/O
+   -add "sched=sedf" on Xen's boot command-line
+   -create domains as usual
+   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
+    Where:
+      -period/slice are the normal EDF scheduling parameters in nanosecs
+      -latency-hint is the scaled period in case the domain is doing heavy I/O
          (unused by the currently compiled version)
-      -extra is a flag (0/1), which controls whether the domain can run in
+      -extra is a flag (0/1), which controls whether the domain can run in
        extra-time
-      -weight is mutually exclusive with period/slice and specifies another
+      -weight is mutually exclusive with period/slice and specifies another
        way of setting a domains cpu slice
 
 Examples:
- normal EDF (20ms/5ms):
-  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
+ normal EDF (20ms/5ms):
+  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
   
- best-effort domains (i.e. non-realtime):
-  xm sched-sedf <dom-id> 20000000 0 0 1 0
- 
+ best-effort domains (i.e. non-realtime):
+  xm sched-sedf <dom-id> 20000000 0 0 1 0
+ 
  normal EDF (20ms/5ms) + share of extra-time:
-  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
+  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
   
- 4 domains with weights 2:3:4:2
-  xm sched-sedf <d1> 0 0 0 0 2
-  xm sched-sedf <d2> 0 0 0 0 3
-  xm sched-sedf <d3> 0 0 0 0 4
-  xm sched-sedf <d4> 0 0 0 0 2
+ 4 domains with weights 2:3:4:2
+  xm sched-sedf <d1> 0 0 0 0 2
+  xm sched-sedf <d2> 0 0 0 0 3
+  xm sched-sedf <d3> 0 0 0 0 4
+  xm sched-sedf <d4> 0 0 0 0 2
   
- 1 fully-specified (10ms/3ms) domain, 3 other domains share
- available rest in 2:7:3 ratio:
-  xm sched-sedf <d1> 10000000 3000000 0 0 0
-  xm sched-sedf <d2> 0 0 0 0 2
-  xm sched-sedf <d3> 0 0 0 0 7
-  xm sched-sedf <d4> 0 0 0 0 3
+ 1 fully-specified (10ms/3ms) domain, 3 other domains share
+ available rest in 2:7:3 ratio:
+  xm sched-sedf <d1> 10000000 3000000 0 0 0
+  xm sched-sedf <d2> 0 0 0 0 2
+  xm sched-sedf <d3> 0 0 0 0 7
+  xm sched-sedf <d4> 0 0 0 0 3


--===============6865025988204818564==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6865025988204818564==--

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYv-00059N-1k; Tue, 29 Nov 2011 14:21:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYt-00056H-Ff
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15126 invoked from network); 29 Nov 2011 14:20:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184206"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:53 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0U018170;	Tue, 29 Nov 2011 06:20:52 -0800
MIME-Version: 1.0
X-Mercurial-Node: e515bb651349f69c2084e4916d999634287c1480
Message-ID: <e515bb651349f69c2084.1322576451@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:51 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 09 of 17 v3] docs: remove non-breaking spaces
 from sedf_scheduler_mini-HOWTO.txt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6865025988204818564=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6865025988204818564==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID e515bb651349f69c2084e4916d999634287c1480
# Parent  c6a2b11a2bd442220395ae117c33925619788204
docs: remove non-breaking spaces from sedf_scheduler_mini-HOWTO.txt

This document contains several 0xa0 characters (non-breaking spaces). These do
not display correctly in (some) terminals or when the document is rendered by (some)
browsers. Re-encode them as spaces.

I'm not confident that this change will make it through being encoded as a patch
and sent through email. Its effect can be replicated with:

	perl -i -p -e 's/\xa0/ /g' docs/misc/sedf_scheduler_mini-HOWTO.txt

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c6a2b11a2bd4 -r e515bb651349 docs/misc/sedf_scheduler_mini-HOWTO.txt
--- a/docs/misc/sedf_scheduler_mini-HOWTO.txt	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/misc/sedf_scheduler_mini-HOWTO.txt	Tue Nov 29 14:17:27 2011 +0000
@@ -8,37 +8,37 @@ Overview:
   uses realtime-algorithms to ensure time guarantees.
 
 Usage:
-   -add "sched=sedf" on Xen's boot command-line
-   -create domains as usual
-   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
-    Where:
-      -period/slice are the normal EDF scheduling parameters in nanosecs
-      -latency-hint is the scaled period in case the domain is doing heavy I/O
+   -add "sched=sedf" on Xen's boot command-line
+   -create domains as usual
+   -use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"
+    Where:
+      -period/slice are the normal EDF scheduling parameters in nanosecs
+      -latency-hint is the scaled period in case the domain is doing heavy I/O
          (unused by the currently compiled version)
-      -extra is a flag (0/1), which controls whether the domain can run in
+      -extra is a flag (0/1), which controls whether the domain can run in
        extra-time
-      -weight is mutually exclusive with period/slice and specifies another
+      -weight is mutually exclusive with period/slice and specifies another
        way of setting a domains cpu slice
 
 Examples:
- normal EDF (20ms/5ms):
-  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
+ normal EDF (20ms/5ms):
+  xm sched-sedf <dom-id> 20000000 5000000 0 0 0
   
- best-effort domains (i.e. non-realtime):
-  xm sched-sedf <dom-id> 20000000 0 0 1 0
- 
+ best-effort domains (i.e. non-realtime):
+  xm sched-sedf <dom-id> 20000000 0 0 1 0
+ 
  normal EDF (20ms/5ms) + share of extra-time:
-  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
+  xm sched-sedf <dom-id> 20000000 5000000 0 1 0
   
- 4 domains with weights 2:3:4:2
-  xm sched-sedf <d1> 0 0 0 0 2
-  xm sched-sedf <d2> 0 0 0 0 3
-  xm sched-sedf <d3> 0 0 0 0 4
-  xm sched-sedf <d4> 0 0 0 0 2
+ 4 domains with weights 2:3:4:2
+  xm sched-sedf <d1> 0 0 0 0 2
+  xm sched-sedf <d2> 0 0 0 0 3
+  xm sched-sedf <d3> 0 0 0 0 4
+  xm sched-sedf <d4> 0 0 0 0 2
   
- 1 fully-specified (10ms/3ms) domain, 3 other domains share
- available rest in 2:7:3 ratio:
-  xm sched-sedf <d1> 10000000 3000000 0 0 0
-  xm sched-sedf <d2> 0 0 0 0 2
-  xm sched-sedf <d3> 0 0 0 0 7
-  xm sched-sedf <d4> 0 0 0 0 3
+ 1 fully-specified (10ms/3ms) domain, 3 other domains share
+ available rest in 2:7:3 ratio:
+  xm sched-sedf <d1> 10000000 3000000 0 0 0
+  xm sched-sedf <d2> 0 0 0 0 2
+  xm sched-sedf <d3> 0 0 0 0 7
+  xm sched-sedf <d4> 0 0 0 0 3


--===============6865025988204818564==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6865025988204818564==--

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ0-0005Df-TU; Tue, 29 Nov 2011 14:21:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYy-00058U-O1
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322576457!4696372!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12920 invoked from network); 29 Nov 2011 14:20:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488424"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:56 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0X018170;	Tue, 29 Nov 2011 06:20:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: de618ef7df21933b40770443fc2295096df39013
Message-ID: <de618ef7df21933b4077.1322576454@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 12 of 17 v3] docs: move user and interface .tex
 documents under reference
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID de618ef7df21933b40770443fc2295096df39013
# Parent  37b46c492f8ac8d356b2b88e8ff00d359443163a
docs: move user and interface .tex documents under reference.

Taking over the top level "user" entry with a relatively obsolete document is a
bit of an annoyance but these docs are not so out of date that they should be
deleted. Move them out of the top-level instead.

(the original motivation here was to allow for user/xl-domain-cfg.markdown but
we have since decided to go with man/xl.cfg.pod.5 instead so perhaps this is a
waste of time)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 37b46c492f8a -r de618ef7df21 docs/INDEX
--- a/docs/INDEX	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/INDEX	Tue Nov 29 14:17:27 2011 +0000
@@ -1,5 +1,5 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
 # These are not all that useful anymore, hide them from the index
-interface/index			NO-INDEX
-user/index			NO-INDEX
+reference/interface/index	NO-INDEX
+reference/user/index		NO-INDEX
diff -r 37b46c492f8a -r de618ef7df21 docs/Makefile
--- a/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
@@ -14,7 +14,7 @@ DOC_TEX		:= src/user.tex src/interface.t
 DOC_MARKDOWN	:= $(wildcard misc/*.markdown)
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
-DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
+DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
 		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
@@ -119,14 +119,14 @@ ps/%.ps: %.dvi
 %.eps: %.fig
 	$(FIG2DEV) -L eps $< $@
 
-html/%/index.html: src/%.tex
+html/reference/%/index.html: src/%.tex
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(LATEX2HTML) 1>/dev/null 2>/dev/null; then \
-        echo "Running latex2html to generate $*/index.html ... "; \
+        echo "Running latex2html to generate reference/$*/index.html ... "; \
 	$(LATEX2HTML) -split 0 -show_section_numbers -toc_depth 3 -nonavigation \
 	-numbered_footnotes -local_icons -noinfo -math -dir $(@D) \
 	$< 1>/dev/null 2>/dev/null ; else \
-	echo "latex2html not installed; skipping $*."; fi
+	echo "latex2html not installed; skipping reference/$*."; fi
 
 html/index.html: $(DOC_HTML) ./gen-html-index INDEX
 	perl -w -- ./gen-html-index -i INDEX html $(DOC_HTML)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ3-0005G9-6C; Tue, 29 Nov 2011 14:21:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOZ1-000599-Q5
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322576457!4696372!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13114 invoked from network); 29 Nov 2011 14:21:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:21:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488430"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:21:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:21:00 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0b018170;	Tue, 29 Nov 2011 06:20:59 -0800
MIME-Version: 1.0
X-Mercurial-Node: 447407a7984d2f2484321418ce8b1991f7f2bd51
Message-ID: <447407a7984d2f248432.1322576458@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 16 of 17 v3] docs: xlexample.hvm: mention the
	viridian setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 447407a7984d2f2484321418ce8b1991f7f2bd51
# Parent  d5c066924bdd55f1a875ec49ddd95cf23e8e0598
docs: xlexample.hvm: mention the viridian setting.

Turning this on for Windows guests is recommended.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d5c066924bdd -r 447407a7984d tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/examples/xlexample.hvm	Tue Nov 29 14:17:27 2011 +0000
@@ -16,6 +16,11 @@ name = "example.hvm"
 # The default behavior is to generate a new UUID each time the guest is started.
 #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
 
+# Enable Microsoft Hyper-V compatibile paravirtualisation /
+# enlightenment interfaces. Turning this on can improve Windows guest
+# performance and is therefore recommended
+#viridian = 1
+
 # Initial memory allocation (MB)
 memory = 128
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ0-0005Df-TU; Tue, 29 Nov 2011 14:21:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYy-00058U-O1
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322576457!4696372!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12920 invoked from network); 29 Nov 2011 14:20:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488424"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:56 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0X018170;	Tue, 29 Nov 2011 06:20:55 -0800
MIME-Version: 1.0
X-Mercurial-Node: de618ef7df21933b40770443fc2295096df39013
Message-ID: <de618ef7df21933b4077.1322576454@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:54 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 12 of 17 v3] docs: move user and interface .tex
 documents under reference
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID de618ef7df21933b40770443fc2295096df39013
# Parent  37b46c492f8ac8d356b2b88e8ff00d359443163a
docs: move user and interface .tex documents under reference.

Taking over the top level "user" entry with a relatively obsolete document is a
bit of an annoyance but these docs are not so out of date that they should be
deleted. Move them out of the top-level instead.

(the original motivation here was to allow for user/xl-domain-cfg.markdown but
we have since decided to go with man/xl.cfg.pod.5 instead so perhaps this is a
waste of time)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 37b46c492f8a -r de618ef7df21 docs/INDEX
--- a/docs/INDEX	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/INDEX	Tue Nov 29 14:17:27 2011 +0000
@@ -1,5 +1,5 @@
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
 
 # These are not all that useful anymore, hide them from the index
-interface/index			NO-INDEX
-user/index			NO-INDEX
+reference/interface/index	NO-INDEX
+reference/user/index		NO-INDEX
diff -r 37b46c492f8a -r de618ef7df21 docs/Makefile
--- a/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/Makefile	Tue Nov 29 14:17:27 2011 +0000
@@ -14,7 +14,7 @@ DOC_TEX		:= src/user.tex src/interface.t
 DOC_MARKDOWN	:= $(wildcard misc/*.markdown)
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
-DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
+DOC_HTML	:= $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \
 		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
 		   $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \
 		   $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC))
@@ -119,14 +119,14 @@ ps/%.ps: %.dvi
 %.eps: %.fig
 	$(FIG2DEV) -L eps $< $@
 
-html/%/index.html: src/%.tex
+html/reference/%/index.html: src/%.tex
 	@$(INSTALL_DIR) $(@D)
 	@set -e ; if which $(LATEX2HTML) 1>/dev/null 2>/dev/null; then \
-        echo "Running latex2html to generate $*/index.html ... "; \
+        echo "Running latex2html to generate reference/$*/index.html ... "; \
 	$(LATEX2HTML) -split 0 -show_section_numbers -toc_depth 3 -nonavigation \
 	-numbered_footnotes -local_icons -noinfo -math -dir $(@D) \
 	$< 1>/dev/null 2>/dev/null ; else \
-	echo "latex2html not installed; skipping $*."; fi
+	echo "latex2html not installed; skipping reference/$*."; fi
 
 html/index.html: $(DOC_HTML) ./gen-html-index INDEX
 	perl -w -- ./gen-html-index -i INDEX html $(DOC_HTML)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:58 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ3-0005G9-6C; Tue, 29 Nov 2011 14:21:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOZ1-000599-Q5
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322576457!4696372!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13114 invoked from network); 29 Nov 2011 14:21:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:21:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488430"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:21:00 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:21:00 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0b018170;	Tue, 29 Nov 2011 06:20:59 -0800
MIME-Version: 1.0
X-Mercurial-Node: 447407a7984d2f2484321418ce8b1991f7f2bd51
Message-ID: <447407a7984d2f248432.1322576458@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 16 of 17 v3] docs: xlexample.hvm: mention the
	viridian setting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 447407a7984d2f2484321418ce8b1991f7f2bd51
# Parent  d5c066924bdd55f1a875ec49ddd95cf23e8e0598
docs: xlexample.hvm: mention the viridian setting.

Turning this on for Windows guests is recommended.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d5c066924bdd -r 447407a7984d tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/examples/xlexample.hvm	Tue Nov 29 14:17:27 2011 +0000
@@ -16,6 +16,11 @@ name = "example.hvm"
 # The default behavior is to generate a new UUID each time the guest is started.
 #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
 
+# Enable Microsoft Hyper-V compatibile paravirtualisation /
+# enlightenment interfaces. Turning this on can improve Windows guest
+# performance and is therefore recommended
+#viridian = 1
+
 # Initial memory allocation (MB)
 memory = 128
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYz-0005Cd-PI; Tue, 29 Nov 2011 14:21:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYx-00056p-O1
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15036 invoked from network); 29 Nov 2011 14:20:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184204"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:51 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0S018170;	Tue, 29 Nov 2011 06:20:50 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9a8406b8209ae3a36162b0929c279325d23ee89e
Message-ID: <9a8406b8209ae3a36162.1322576449@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 07 of 17 v3] xlu: add "dont_warn" to xlu_cfg_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 9a8406b8209ae3a36162b0929c279325d23ee89e
# Parent  19c600402e8008d768fd36b7a5e6cd9b109e04e4
xlu: add "dont_warn" to xlu_cfg_*

I want it for get_long but we might as well have it everywhere.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 19c600402e80 -r 9a8406b8209a tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Tue Nov 29 14:17:27 2011 +0000
@@ -165,17 +165,18 @@ static XLU_ConfigSetting *find(const XLU
 }
 
 static int find_atom(const XLU_Config *cfg, const char *n,
-                     XLU_ConfigSetting **set_r) {
+                     XLU_ConfigSetting **set_r, int dont_warn) {
     XLU_ConfigSetting *set;
 
     set= find(cfg,n);
     if (!set) return ESRCH;
 
     if (set->avalues!=1) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is"
-                " a list but should be a single value\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is"
+                    " a list but should be a single value\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *set_r= set;
@@ -183,49 +184,51 @@ static int find_atom(const XLU_Config *c
 }
 
 int xlu_cfg_get_string(const XLU_Config *cfg, const char *n,
-                       const char **value_r) {
+                       const char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     *value_r= set->values[0];
     return 0;
 }
 
 int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
-                           char **value_r) {
+                           char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     free(*value_r);
     *value_r= strdup(set->values[0]);
     return 0;
 }
 
 int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
-                     long *value_r) {
+                     long *value_r, int dont_warn) {
     long l;
     XLU_ConfigSetting *set;
     int e;
     char *ep;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     errno= 0; l= strtol(set->values[0], &ep, 0);
     e= errno;
     if (errno) {
         e= errno;
         assert(e==EINVAL || e==ERANGE);
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' could not be parsed"
-                " as a number: %s\n",
-                cfg->filename, set->lineno, n, strerror(e));
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' could not be parsed"
+                    " as a number: %s\n",
+                    cfg->filename, set->lineno, n, strerror(e));
         return e;
     }
     if (*ep || ep==set->values[0]) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is not a valid number\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is not a valid number\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *value_r= l;
diff -r 19c600402e80 -r 9a8406b8209a tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxlutil.h	Tue Nov 29 14:17:27 2011 +0000
@@ -41,13 +41,17 @@ void xlu_cfg_destroy(XLU_Config*);
  * Return values are:
  *   0        OK
  *   ESRCH    not defined
- *   EINVAL   value found but wrong format for request (prints warning)
+ *   EINVAL   value found but wrong format for request (prints warning unless dont_warn=true)
  *   ERANGE   value out of range (from strtol)
  */
 
-int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r);
-int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char **value_r); /* free/strdup version */
-int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r);
+int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r,
+                       int dont_warn);
+/* free/strdup version */
+int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
+                           char **value_r, int dont_warn);
+int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r 19c600402e80 -r 9a8406b8209a tools/libxl/xl.c
--- a/tools/libxl/xl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -62,10 +62,10 @@ static void parse_global_config(const ch
         exit(1);
     }
 
-    if (!xlu_cfg_get_long (config, "autoballoon", &l))
+    if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
-    if (!xlu_cfg_get_string (config, "lockfile", &buf))
+    if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
         e = asprintf(&lockfile, "%s/xl", (char *)libxl_lock_dir_path());
@@ -75,7 +75,7 @@ static void parse_global_config(const ch
         }
     }
 
-    if (!xlu_cfg_get_string (config, "vifscript", &buf))
+    if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
     xlu_cfg_destroy(config);
diff -r 19c600402e80 -r 9a8406b8209a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -554,7 +554,7 @@ static void parse_config_data(const char
     if (libxl_init_create_info(ctx, c_info))
         exit(1);
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf)) {
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
@@ -568,19 +568,19 @@ static void parse_config_data(const char
     }
 
     c_info->type = LIBXL_DOMAIN_TYPE_PV;
-    if (!xlu_cfg_get_string (config, "builder", &buf) &&
+    if (!xlu_cfg_get_string (config, "builder", &buf, 0) &&
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l))
+    if (!xlu_cfg_get_long (config, "hap", &l, 0))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+    if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.");
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
+    if (!xlu_cfg_get_string (config, "uuid", &buf, 0) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {
             fprintf(stderr, "Failed to parse UUID: %s\n", buf);
             exit(1);
@@ -589,10 +589,10 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l))
+    if (!xlu_cfg_get_long(config, "oos", &l, 0))
         c_info->oos = l;
 
-    if (!xlu_cfg_get_string (config, "pool", &buf)) {
+    if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
@@ -606,37 +606,37 @@ static void parse_config_data(const char
         exit(1);
 
     /* the following is the actual config parsing with overriding values in the structures */
-    if (!xlu_cfg_get_long (config, "vcpus", &l)) {
+    if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;
     }
 
-    if (!xlu_cfg_get_long (config, "maxvcpus", &l))
+    if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus = l;
 
-    if (!xlu_cfg_get_long (config, "memory", &l)) {
+    if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
     }
 
-    if (!xlu_cfg_get_long (config, "maxmem", &l))
+    if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
         b_info->max_memkb = l * 1024;
 
-    if (xlu_cfg_get_string (config, "on_poweroff", &buf))
+    if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_poweroff)) {
         fprintf(stderr, "Unknown on_poweroff action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_reboot", &buf))
+    if (xlu_cfg_get_string (config, "on_reboot", &buf, 0))
         buf = "restart";
     if (!parse_action_on_shutdown(buf, &d_config->on_reboot)) {
         fprintf(stderr, "Unknown on_reboot action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_watchdog", &buf))
+    if (xlu_cfg_get_string (config, "on_watchdog", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_watchdog)) {
         fprintf(stderr, "Unknown on_watchdog action \"%s\" specified\n", buf);
@@ -644,7 +644,7 @@ static void parse_config_data(const char
     }
 
 
-    if (xlu_cfg_get_string (config, "on_crash", &buf))
+    if (xlu_cfg_get_string (config, "on_crash", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_crash)) {
         fprintf(stderr, "Unknown on_crash action \"%s\" specified\n", buf);
@@ -654,52 +654,52 @@ static void parse_config_data(const char
     /* libxl_get_required_shadow_memory() must be called after final values
      * (default or specified) for vcpus and memory are set, because the
      * calculation depends on those values. */
-    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l)
+    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l, 0)
         ? l * 1024
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l))
+    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
         b_info->tsc_mode = l;
 
-    if (!xlu_cfg_get_long (config, "videoram", &l))
+    if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+    if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
         dm_info->gfx_passthru = l;
 
     switch(c_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        if (!xlu_cfg_get_string (config, "kernel", &buf))
+        if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
             fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "
                     "Use \"firmware_override\" instead if you really want a non-default firmware\n");
 
         xlu_cfg_replace_string (config, "firmware_override",
-                                &b_info->u.hvm.firmware);
-        if (!xlu_cfg_get_long (config, "pae", &l))
+                                &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l))
+        if (!xlu_cfg_get_long (config, "apic", &l, 0))
             b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l))
+        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
             b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l, 0))
             b_info->u.hvm.acpi_s3 = l;
-        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l, 0))
             b_info->u.hvm.acpi_s4 = l;
-        if (!xlu_cfg_get_long (config, "nx", &l))
+        if (!xlu_cfg_get_long (config, "nx", &l, 0))
             b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l))
+        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
             b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l))
+        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
             b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l))
+        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
             b_info->u.hvm.vpt_align = l;
-        if (!xlu_cfg_get_long (config, "timer_mode", &l))
+        if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
             b_info->u.hvm.timer_mode = l;
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l))
+        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -707,12 +707,12 @@ static void parse_config_data(const char
         char *cmdline = NULL;
         const char *root = NULL, *extra = "";
 
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_get_string (config, "root", &root);
-        xlu_cfg_get_string (config, "extra", &extra);
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_get_string (config, "root", &root, 0);
+        xlu_cfg_get_string (config, "extra", &extra, 0);
 
         if (root) {
             if (asprintf(&cmdline, "root=%s %s", root, extra) == -1)
@@ -726,8 +726,10 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader);
-        xlu_cfg_replace_string (config, "bootloader_args", &b_info->u.pv.bootloader_args);
+        xlu_cfg_replace_string (config, "bootloader",
+                                &b_info->u.pv.bootloader, 0);
+        xlu_cfg_replace_string (config, "bootloader_args",
+                                &b_info->u.pv.bootloader_args, 0);
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");
@@ -735,7 +737,7 @@ static void parse_config_data(const char
         }
 
         b_info->u.pv.cmdline = cmdline;
-        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path);
+        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path, 0);
         break;
     }
     default:
@@ -910,15 +912,15 @@ skip_vfb:
         }
     }
 
-    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l))
+    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l, 0))
         pci_msitranslate = l;
 
-    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l))
+    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l, 0))
         pci_power_mgmt = l;
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l)) {
+    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
         switch (c_info->type) {
         case LIBXL_DOMAIN_TYPE_HVM:
             fprintf(stderr, "Can't do e820_host in HVM mode!");
@@ -986,7 +988,7 @@ skip_vfb:
         }
         break;
     case EINVAL:    /* config option is not a list, parse as a string */
-        if (!xlu_cfg_get_string(config, "cpuid", &buf)) {
+        if (!xlu_cfg_get_string(config, "cpuid", &buf, 0)) {
             char *buf2, *p, *strtok_ptr = NULL;
             const char *errstr;
 
@@ -1034,7 +1036,7 @@ skip_vfb:
     if (libxl_init_dm_info(ctx, dm_info, c_info, b_info))
         exit(1);
     /* parse device model arguments, this works for pv, hvm and stubdom */
-    if (!xlu_cfg_get_string (config, "device_model", &buf)) {
+    if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) {
         fprintf(stderr,
                 "WARNING: ignoring device_model directive.\n"
                 "WARNING: Use \"device_model_override\" instead if you"
@@ -1053,8 +1055,8 @@ skip_vfb:
 
 
     xlu_cfg_replace_string (config, "device_model_override",
-                            &dm_info->device_model);
-    if (!xlu_cfg_get_string (config, "device_model_version", &buf)) {
+                            &dm_info->device_model, 0);
+    if (!xlu_cfg_get_string (config, "device_model_version", &buf, 0)) {
         if (!strcmp(buf, "qemu-xen-traditional")) {
             dm_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
@@ -1068,7 +1070,7 @@ skip_vfb:
         }
     } else if (dm_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l))
+    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
 #define parse_extra_args(type)                                          \
@@ -1096,46 +1098,46 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l))
+        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
             dm_info->stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l))
+        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
             dm_info->vnc = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd);
-        if (!xlu_cfg_get_long (config, "vncdisplay", &l))
+        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd, 0);
+        if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             dm_info->vncdisplay = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l))
+        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
             dm_info->vncunused = l;
-        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap);
-        if (!xlu_cfg_get_long (config, "sdl", &l))
+        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
+        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l))
+        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
             dm_info->opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l))
+        if (!xlu_cfg_get_long (config, "spice", &l, 0))
             dm_info->spice = l;
-        if (!xlu_cfg_get_long (config, "spiceport", &l))
+        if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             dm_info->spiceport = l;
-        if (!xlu_cfg_get_long (config, "spicetls_port", &l))
+        if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             dm_info->spicetls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l))
+        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost, 0);
+        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
             dm_info->spicedisable_ticketing = l;
-        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l))
+        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd, 0);
+        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
             dm_info->spiceagent_mouse = l;
         else
             dm_info->spiceagent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l))
+        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             dm_info->nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
-        xlu_cfg_replace_string (config, "serial", &dm_info->serial);
-        xlu_cfg_replace_string (config, "boot", &dm_info->boot);
-        if (!xlu_cfg_get_long (config, "usb", &l))
+        xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);
+        xlu_cfg_replace_string (config, "boot", &dm_info->boot, 0);
+        if (!xlu_cfg_get_long (config, "usb", &l, 0))
             dm_info->usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice);
-        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l))
+        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice, 0);
+        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
+        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
             dm_info->xen_platform_pci = l;
     }
 
@@ -4766,7 +4768,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "name", &buf))
+    if (!xlu_cfg_get_string (config, "name", &buf, 0))
         name = strdup(buf);
     else
         name = libxl_basename(filename);
@@ -4775,7 +4777,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "sched", &buf)) {
+    if (!xlu_cfg_get_string (config, "sched", &buf, 0)) {
         if ((schedid = libxl_name_to_schedid(ctx, buf)) < 0) {
             fprintf(stderr, "Unknown scheduler\n");
             return -ERROR_FAIL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYz-0005Cd-PI; Tue, 29 Nov 2011 14:21:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYx-00056p-O1
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15036 invoked from network); 29 Nov 2011 14:20:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184204"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:51 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0S018170;	Tue, 29 Nov 2011 06:20:50 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9a8406b8209ae3a36162b0929c279325d23ee89e
Message-ID: <9a8406b8209ae3a36162.1322576449@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:49 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 07 of 17 v3] xlu: add "dont_warn" to xlu_cfg_*
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 9a8406b8209ae3a36162b0929c279325d23ee89e
# Parent  19c600402e8008d768fd36b7a5e6cd9b109e04e4
xlu: add "dont_warn" to xlu_cfg_*

I want it for get_long but we might as well have it everywhere.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 19c600402e80 -r 9a8406b8209a tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Tue Nov 29 14:17:27 2011 +0000
@@ -165,17 +165,18 @@ static XLU_ConfigSetting *find(const XLU
 }
 
 static int find_atom(const XLU_Config *cfg, const char *n,
-                     XLU_ConfigSetting **set_r) {
+                     XLU_ConfigSetting **set_r, int dont_warn) {
     XLU_ConfigSetting *set;
 
     set= find(cfg,n);
     if (!set) return ESRCH;
 
     if (set->avalues!=1) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is"
-                " a list but should be a single value\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is"
+                    " a list but should be a single value\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *set_r= set;
@@ -183,49 +184,51 @@ static int find_atom(const XLU_Config *c
 }
 
 int xlu_cfg_get_string(const XLU_Config *cfg, const char *n,
-                       const char **value_r) {
+                       const char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     *value_r= set->values[0];
     return 0;
 }
 
 int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
-                           char **value_r) {
+                           char **value_r, int dont_warn) {
     XLU_ConfigSetting *set;
     int e;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     free(*value_r);
     *value_r= strdup(set->values[0]);
     return 0;
 }
 
 int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
-                     long *value_r) {
+                     long *value_r, int dont_warn) {
     long l;
     XLU_ConfigSetting *set;
     int e;
     char *ep;
 
-    e= find_atom(cfg,n,&set);  if (e) return e;
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
     errno= 0; l= strtol(set->values[0], &ep, 0);
     e= errno;
     if (errno) {
         e= errno;
         assert(e==EINVAL || e==ERANGE);
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' could not be parsed"
-                " as a number: %s\n",
-                cfg->filename, set->lineno, n, strerror(e));
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' could not be parsed"
+                    " as a number: %s\n",
+                    cfg->filename, set->lineno, n, strerror(e));
         return e;
     }
     if (*ep || ep==set->values[0]) {
-        fprintf(cfg->report,
-                "%s:%d: warning: parameter `%s' is not a valid number\n",
-                cfg->filename, set->lineno, n);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is not a valid number\n",
+                    cfg->filename, set->lineno, n);
         return EINVAL;
     }
     *value_r= l;
diff -r 19c600402e80 -r 9a8406b8209a tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxlutil.h	Tue Nov 29 14:17:27 2011 +0000
@@ -41,13 +41,17 @@ void xlu_cfg_destroy(XLU_Config*);
  * Return values are:
  *   0        OK
  *   ESRCH    not defined
- *   EINVAL   value found but wrong format for request (prints warning)
+ *   EINVAL   value found but wrong format for request (prints warning unless dont_warn=true)
  *   ERANGE   value out of range (from strtol)
  */
 
-int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r);
-int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char **value_r); /* free/strdup version */
-int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r);
+int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r,
+                       int dont_warn);
+/* free/strdup version */
+int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
+                           char **value_r, int dont_warn);
+int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r 19c600402e80 -r 9a8406b8209a tools/libxl/xl.c
--- a/tools/libxl/xl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -62,10 +62,10 @@ static void parse_global_config(const ch
         exit(1);
     }
 
-    if (!xlu_cfg_get_long (config, "autoballoon", &l))
+    if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
         autoballoon = l;
 
-    if (!xlu_cfg_get_string (config, "lockfile", &buf))
+    if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
         lockfile = strdup(buf);
     else {
         e = asprintf(&lockfile, "%s/xl", (char *)libxl_lock_dir_path());
@@ -75,7 +75,7 @@ static void parse_global_config(const ch
         }
     }
 
-    if (!xlu_cfg_get_string (config, "vifscript", &buf))
+    if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
     xlu_cfg_destroy(config);
diff -r 19c600402e80 -r 9a8406b8209a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -554,7 +554,7 @@ static void parse_config_data(const char
     if (libxl_init_create_info(ctx, c_info))
         exit(1);
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf)) {
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
@@ -568,19 +568,19 @@ static void parse_config_data(const char
     }
 
     c_info->type = LIBXL_DOMAIN_TYPE_PV;
-    if (!xlu_cfg_get_string (config, "builder", &buf) &&
+    if (!xlu_cfg_get_string (config, "builder", &buf, 0) &&
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l))
+    if (!xlu_cfg_get_long (config, "hap", &l, 0))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+    if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.");
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
+    if (!xlu_cfg_get_string (config, "uuid", &buf, 0) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {
             fprintf(stderr, "Failed to parse UUID: %s\n", buf);
             exit(1);
@@ -589,10 +589,10 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l))
+    if (!xlu_cfg_get_long(config, "oos", &l, 0))
         c_info->oos = l;
 
-    if (!xlu_cfg_get_string (config, "pool", &buf)) {
+    if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
@@ -606,37 +606,37 @@ static void parse_config_data(const char
         exit(1);
 
     /* the following is the actual config parsing with overriding values in the structures */
-    if (!xlu_cfg_get_long (config, "vcpus", &l)) {
+    if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
         b_info->max_vcpus = l;
         b_info->cur_vcpus = (1 << l) - 1;
     }
 
-    if (!xlu_cfg_get_long (config, "maxvcpus", &l))
+    if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus = l;
 
-    if (!xlu_cfg_get_long (config, "memory", &l)) {
+    if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
     }
 
-    if (!xlu_cfg_get_long (config, "maxmem", &l))
+    if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
         b_info->max_memkb = l * 1024;
 
-    if (xlu_cfg_get_string (config, "on_poweroff", &buf))
+    if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_poweroff)) {
         fprintf(stderr, "Unknown on_poweroff action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_reboot", &buf))
+    if (xlu_cfg_get_string (config, "on_reboot", &buf, 0))
         buf = "restart";
     if (!parse_action_on_shutdown(buf, &d_config->on_reboot)) {
         fprintf(stderr, "Unknown on_reboot action \"%s\" specified\n", buf);
         exit(1);
     }
 
-    if (xlu_cfg_get_string (config, "on_watchdog", &buf))
+    if (xlu_cfg_get_string (config, "on_watchdog", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_watchdog)) {
         fprintf(stderr, "Unknown on_watchdog action \"%s\" specified\n", buf);
@@ -644,7 +644,7 @@ static void parse_config_data(const char
     }
 
 
-    if (xlu_cfg_get_string (config, "on_crash", &buf))
+    if (xlu_cfg_get_string (config, "on_crash", &buf, 0))
         buf = "destroy";
     if (!parse_action_on_shutdown(buf, &d_config->on_crash)) {
         fprintf(stderr, "Unknown on_crash action \"%s\" specified\n", buf);
@@ -654,52 +654,52 @@ static void parse_config_data(const char
     /* libxl_get_required_shadow_memory() must be called after final values
      * (default or specified) for vcpus and memory are set, because the
      * calculation depends on those values. */
-    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l)
+    b_info->shadow_memkb = !xlu_cfg_get_long(config, "shadow_memory", &l, 0)
         ? l * 1024
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l))
+    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
         b_info->tsc_mode = l;
 
-    if (!xlu_cfg_get_long (config, "videoram", &l))
+    if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+    if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
         dm_info->gfx_passthru = l;
 
     switch(c_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        if (!xlu_cfg_get_string (config, "kernel", &buf))
+        if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
             fprintf(stderr, "WARNING: ignoring \"kernel\" directive for HVM guest. "
                     "Use \"firmware_override\" instead if you really want a non-default firmware\n");
 
         xlu_cfg_replace_string (config, "firmware_override",
-                                &b_info->u.hvm.firmware);
-        if (!xlu_cfg_get_long (config, "pae", &l))
+                                &b_info->u.hvm.firmware, 0);
+        if (!xlu_cfg_get_long (config, "pae", &l, 0))
             b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l))
+        if (!xlu_cfg_get_long (config, "apic", &l, 0))
             b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l))
+        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
             b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "acpi_s3", &l))
+        if (!xlu_cfg_get_long (config, "acpi_s3", &l, 0))
             b_info->u.hvm.acpi_s3 = l;
-        if (!xlu_cfg_get_long (config, "acpi_s4", &l))
+        if (!xlu_cfg_get_long (config, "acpi_s4", &l, 0))
             b_info->u.hvm.acpi_s4 = l;
-        if (!xlu_cfg_get_long (config, "nx", &l))
+        if (!xlu_cfg_get_long (config, "nx", &l, 0))
             b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l))
+        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
             b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l))
+        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
             b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l))
+        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
             b_info->u.hvm.vpt_align = l;
-        if (!xlu_cfg_get_long (config, "timer_mode", &l))
+        if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
             b_info->u.hvm.timer_mode = l;
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l))
+        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -707,12 +707,12 @@ static void parse_config_data(const char
         char *cmdline = NULL;
         const char *root = NULL, *extra = "";
 
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path);
-
-        xlu_cfg_get_string (config, "root", &root);
-        xlu_cfg_get_string (config, "extra", &extra);
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
+
+        xlu_cfg_get_string (config, "root", &root, 0);
+        xlu_cfg_get_string (config, "extra", &extra, 0);
 
         if (root) {
             if (asprintf(&cmdline, "root=%s %s", root, extra) == -1)
@@ -726,8 +726,10 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader);
-        xlu_cfg_replace_string (config, "bootloader_args", &b_info->u.pv.bootloader_args);
+        xlu_cfg_replace_string (config, "bootloader",
+                                &b_info->u.pv.bootloader, 0);
+        xlu_cfg_replace_string (config, "bootloader_args",
+                                &b_info->u.pv.bootloader_args, 0);
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");
@@ -735,7 +737,7 @@ static void parse_config_data(const char
         }
 
         b_info->u.pv.cmdline = cmdline;
-        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path);
+        xlu_cfg_replace_string (config, "ramdisk", &b_info->u.pv.ramdisk.path, 0);
         break;
     }
     default:
@@ -910,15 +912,15 @@ skip_vfb:
         }
     }
 
-    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l))
+    if (!xlu_cfg_get_long (config, "pci_msitranslate", &l, 0))
         pci_msitranslate = l;
 
-    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l))
+    if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l, 0))
         pci_power_mgmt = l;
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l)) {
+    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
         switch (c_info->type) {
         case LIBXL_DOMAIN_TYPE_HVM:
             fprintf(stderr, "Can't do e820_host in HVM mode!");
@@ -986,7 +988,7 @@ skip_vfb:
         }
         break;
     case EINVAL:    /* config option is not a list, parse as a string */
-        if (!xlu_cfg_get_string(config, "cpuid", &buf)) {
+        if (!xlu_cfg_get_string(config, "cpuid", &buf, 0)) {
             char *buf2, *p, *strtok_ptr = NULL;
             const char *errstr;
 
@@ -1034,7 +1036,7 @@ skip_vfb:
     if (libxl_init_dm_info(ctx, dm_info, c_info, b_info))
         exit(1);
     /* parse device model arguments, this works for pv, hvm and stubdom */
-    if (!xlu_cfg_get_string (config, "device_model", &buf)) {
+    if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) {
         fprintf(stderr,
                 "WARNING: ignoring device_model directive.\n"
                 "WARNING: Use \"device_model_override\" instead if you"
@@ -1053,8 +1055,8 @@ skip_vfb:
 
 
     xlu_cfg_replace_string (config, "device_model_override",
-                            &dm_info->device_model);
-    if (!xlu_cfg_get_string (config, "device_model_version", &buf)) {
+                            &dm_info->device_model, 0);
+    if (!xlu_cfg_get_string (config, "device_model_version", &buf, 0)) {
         if (!strcmp(buf, "qemu-xen-traditional")) {
             dm_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
@@ -1068,7 +1070,7 @@ skip_vfb:
         }
     } else if (dm_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l))
+    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
 #define parse_extra_args(type)                                          \
@@ -1096,46 +1098,46 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l))
+        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
             dm_info->stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l))
+        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
             dm_info->vnc = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd);
-        if (!xlu_cfg_get_long (config, "vncdisplay", &l))
+        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd, 0);
+        if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             dm_info->vncdisplay = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l))
+        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
             dm_info->vncunused = l;
-        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap);
-        if (!xlu_cfg_get_long (config, "sdl", &l))
+        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
+        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l))
+        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
             dm_info->opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l))
+        if (!xlu_cfg_get_long (config, "spice", &l, 0))
             dm_info->spice = l;
-        if (!xlu_cfg_get_long (config, "spiceport", &l))
+        if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             dm_info->spiceport = l;
-        if (!xlu_cfg_get_long (config, "spicetls_port", &l))
+        if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             dm_info->spicetls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l))
+        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost, 0);
+        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
             dm_info->spicedisable_ticketing = l;
-        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l))
+        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd, 0);
+        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
             dm_info->spiceagent_mouse = l;
         else
             dm_info->spiceagent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l))
+        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             dm_info->nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
-        xlu_cfg_replace_string (config, "serial", &dm_info->serial);
-        xlu_cfg_replace_string (config, "boot", &dm_info->boot);
-        if (!xlu_cfg_get_long (config, "usb", &l))
+        xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);
+        xlu_cfg_replace_string (config, "boot", &dm_info->boot, 0);
+        if (!xlu_cfg_get_long (config, "usb", &l, 0))
             dm_info->usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice);
-        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l))
+        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice, 0);
+        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
+        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
             dm_info->xen_platform_pci = l;
     }
 
@@ -4766,7 +4768,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "name", &buf))
+    if (!xlu_cfg_get_string (config, "name", &buf, 0))
         name = strdup(buf);
     else
         name = libxl_basename(filename);
@@ -4775,7 +4777,7 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
 
-    if (!xlu_cfg_get_string (config, "sched", &buf)) {
+    if (!xlu_cfg_get_string (config, "sched", &buf, 0)) {
         if ((schedid = libxl_name_to_schedid(ctx, buf)) < 0) {
             fprintf(stderr, "Unknown scheduler\n");
             return -ERROR_FAIL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYw-0005A8-H1; Tue, 29 Nov 2011 14:21:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYv-00056i-7r
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322576446!5152993!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26090 invoked from network); 29 Nov 2011 14:20:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488417"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:50 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0R018170;	Tue, 29 Nov 2011 06:20:49 -0800
MIME-Version: 1.0
X-Mercurial-Node: 19c600402e8008d768fd36b7a5e6cd9b109e04e4
Message-ID: <19c600402e8008d768fd.1322576448@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:48 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 06 of 17 v3] xl: the name field in a guest
 config file is mandatory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 19c600402e8008d768fd36b7a5e6cd9b109e04e4
# Parent  ce3fa9ade7c176b4439aba566551ed2b48915d67
xl: the name field in a guest config file is mandatory

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ce3fa9ade7c1 -r 19c600402e80 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -575,8 +575,10 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "hap", &l))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name))
-        c_info->name = strdup("test");
+    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+        fprintf(stderr, "Domain name must be specified.");
+        exit(1);
+    }
 
     if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:21:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:21:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYw-0005A8-H1; Tue, 29 Nov 2011 14:21:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYv-00056i-7r
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322576446!5152993!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26090 invoked from network); 29 Nov 2011 14:20:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488417"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:50 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0R018170;	Tue, 29 Nov 2011 06:20:49 -0800
MIME-Version: 1.0
X-Mercurial-Node: 19c600402e8008d768fd36b7a5e6cd9b109e04e4
Message-ID: <19c600402e8008d768fd.1322576448@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:48 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 06 of 17 v3] xl: the name field in a guest
 config file is mandatory
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 19c600402e8008d768fd36b7a5e6cd9b109e04e4
# Parent  ce3fa9ade7c176b4439aba566551ed2b48915d67
xl: the name field in a guest config file is mandatory

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ce3fa9ade7c1 -r 19c600402e80 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -575,8 +575,10 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "hap", &l))
         c_info->hap = l;
 
-    if (xlu_cfg_replace_string (config, "name", &c_info->name))
-        c_info->name = strdup("test");
+    if (xlu_cfg_replace_string (config, "name", &c_info->name)) {
+        fprintf(stderr, "Domain name must be specified.");
+        exit(1);
+    }
 
     if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
         if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:22:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:22:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ0-0005DJ-GZ; Tue, 29 Nov 2011 14:21:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYy-00057j-Cb
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15286 invoked from network); 29 Nov 2011 14:20:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184217"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:57 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0Y018170;	Tue, 29 Nov 2011 06:20:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 56f438c2a5aa6e11a765bc686bff7aa61d8eab7d
Message-ID: <56f438c2a5aa6e11a765.1322576455@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:55 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 13 of 17 v3] libxlu: add
	xlu_cfg_get_list_as_string_list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 56f438c2a5aa6e11a765bc686bff7aa61d8eab7d
# Parent  de618ef7df21933b40770443fc2295096df39013
libxlu: add xlu_cfg_get_list_as_string_list

Returns a cfg list as a libxl_string_list.

Use this to simplify the parsing of device model extra args.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r de618ef7df21 -r 56f438c2a5aa tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Tue Nov 29 14:17:27 2011 +0000
@@ -254,6 +254,29 @@ int xlu_cfg_get_list(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                     libxl_string_list *psl, int dont_warn) {
+    int i, rc, nr;
+    XLU_ConfigList *list;
+    libxl_string_list sl;
+
+    rc = xlu_cfg_get_list(cfg, n, &list, &nr, dont_warn);
+    if (rc)  return rc;
+
+    sl = malloc(sizeof(char*)*(nr + 1));
+    if (sl == NULL) return ENOMEM;
+
+    for (i=0; i<nr; i++) {
+        const char *a = xlu_cfg_get_listitem(list, i);
+        sl[i] = a ? strdup(a) : NULL;
+    }
+
+    sl[nr] = NULL;
+
+    *psl = sl;
+    return 0;
+}
+
 const char *xlu_cfg_get_listitem(const XLU_ConfigList *set, int entry) {
     if (entry < 0 || entry >= set->nvalues) return 0;
     return set->values[entry];
diff -r de618ef7df21 -r 56f438c2a5aa tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxlutil.h	Tue Nov 29 14:17:27 2011 +0000
@@ -58,6 +58,8 @@ int xlu_cfg_get_list(const XLU_Config*, 
                      int *entries_r /* may be 0 */,
                      int dont_warn);
   /* there is no need to free *list_r; lifetime is that of the XLU_Config */
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                                    libxl_string_list *sl, int dont_warn);
 const char *xlu_cfg_get_listitem(const XLU_ConfigList*, int entry);
   /* xlu_cfg_get_listitem cannot fail, except that if entry is
    * out of range it returns 0 (not setting errno) */
diff -r de618ef7df21 -r 56f438c2a5aa tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -529,13 +529,6 @@ static void parse_config_data(const char
     int pci_msitranslate = 1;
     int e;
 
-    XLU_ConfigList *dmargs;
-    int nr_dmargs = 0;
-    XLU_ConfigList *dmargs_hvm;
-    int nr_dmargs_hvm = 0;
-    XLU_ConfigList *dmargs_pv;
-    int nr_dmargs_pv = 0;
-
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
 
@@ -1093,19 +1086,14 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
-#define parse_extra_args(type)                                          \
-    if (!xlu_cfg_get_list(config, "device_model_args"#type,             \
-                          &dmargs##type, &nr_dmargs##type, 0))          \
-    {                                                                   \
-        int i;                                                          \
-        dm_info->extra##type =                                          \
-            xmalloc(sizeof(char*)*(nr_dmargs##type + 1));               \
-        dm_info->extra##type[nr_dmargs##type] = NULL;                   \
-        for (i=0; i<nr_dmargs##type; i++) {                             \
-            const char *a = xlu_cfg_get_listitem(dmargs##type, i);      \
-            dm_info->extra##type[i] = a ? strdup(a) : NULL;             \
-        }                                                               \
-    }                                                                   \
+#define parse_extra_args(type)                                            \
+    e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
+                                    &dm_info->extra##type, 0);            \
+    if (e && e != ESRCH) {                                                \
+        fprintf(stderr,"xl: Unable to parse device_model_args"#type".\n");\
+        exit(-ERROR_FAIL);                                                \
+    }
+
     /* parse extra args for qemu, common to both pv, hvm */
     parse_extra_args();
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:22:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:22:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZ0-0005DJ-GZ; Tue, 29 Nov 2011 14:21:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYy-00057j-Cb
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322576446!5156893!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15286 invoked from network); 29 Nov 2011 14:20:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172184217"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:57 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0Y018170;	Tue, 29 Nov 2011 06:20:56 -0800
MIME-Version: 1.0
X-Mercurial-Node: 56f438c2a5aa6e11a765bc686bff7aa61d8eab7d
Message-ID: <56f438c2a5aa6e11a765.1322576455@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:55 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 13 of 17 v3] libxlu: add
	xlu_cfg_get_list_as_string_list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID 56f438c2a5aa6e11a765bc686bff7aa61d8eab7d
# Parent  de618ef7df21933b40770443fc2295096df39013
libxlu: add xlu_cfg_get_list_as_string_list

Returns a cfg list as a libxl_string_list.

Use this to simplify the parsing of device model extra args.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r de618ef7df21 -r 56f438c2a5aa tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c	Tue Nov 29 14:17:27 2011 +0000
@@ -254,6 +254,29 @@ int xlu_cfg_get_list(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                     libxl_string_list *psl, int dont_warn) {
+    int i, rc, nr;
+    XLU_ConfigList *list;
+    libxl_string_list sl;
+
+    rc = xlu_cfg_get_list(cfg, n, &list, &nr, dont_warn);
+    if (rc)  return rc;
+
+    sl = malloc(sizeof(char*)*(nr + 1));
+    if (sl == NULL) return ENOMEM;
+
+    for (i=0; i<nr; i++) {
+        const char *a = xlu_cfg_get_listitem(list, i);
+        sl[i] = a ? strdup(a) : NULL;
+    }
+
+    sl[nr] = NULL;
+
+    *psl = sl;
+    return 0;
+}
+
 const char *xlu_cfg_get_listitem(const XLU_ConfigList *set, int entry) {
     if (entry < 0 || entry >= set->nvalues) return 0;
     return set->values[entry];
diff -r de618ef7df21 -r 56f438c2a5aa tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxlutil.h	Tue Nov 29 14:17:27 2011 +0000
@@ -58,6 +58,8 @@ int xlu_cfg_get_list(const XLU_Config*, 
                      int *entries_r /* may be 0 */,
                      int dont_warn);
   /* there is no need to free *list_r; lifetime is that of the XLU_Config */
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+                                    libxl_string_list *sl, int dont_warn);
 const char *xlu_cfg_get_listitem(const XLU_ConfigList*, int entry);
   /* xlu_cfg_get_listitem cannot fail, except that if entry is
    * out of range it returns 0 (not setting errno) */
diff -r de618ef7df21 -r 56f438c2a5aa tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -529,13 +529,6 @@ static void parse_config_data(const char
     int pci_msitranslate = 1;
     int e;
 
-    XLU_ConfigList *dmargs;
-    int nr_dmargs = 0;
-    XLU_ConfigList *dmargs_hvm;
-    int nr_dmargs_hvm = 0;
-    XLU_ConfigList *dmargs_pv;
-    int nr_dmargs_pv = 0;
-
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
 
@@ -1093,19 +1086,14 @@ skip_vfb:
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
         dm_info->device_model_stubdomain = l;
 
-#define parse_extra_args(type)                                          \
-    if (!xlu_cfg_get_list(config, "device_model_args"#type,             \
-                          &dmargs##type, &nr_dmargs##type, 0))          \
-    {                                                                   \
-        int i;                                                          \
-        dm_info->extra##type =                                          \
-            xmalloc(sizeof(char*)*(nr_dmargs##type + 1));               \
-        dm_info->extra##type[nr_dmargs##type] = NULL;                   \
-        for (i=0; i<nr_dmargs##type; i++) {                             \
-            const char *a = xlu_cfg_get_listitem(dmargs##type, i);      \
-            dm_info->extra##type[i] = a ? strdup(a) : NULL;             \
-        }                                                               \
-    }                                                                   \
+#define parse_extra_args(type)                                            \
+    e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
+                                    &dm_info->extra##type, 0);            \
+    if (e && e != ESRCH) {                                                \
+        fprintf(stderr,"xl: Unable to parse device_model_args"#type".\n");\
+        exit(-ERROR_FAIL);                                                \
+    }
+
     /* parse extra args for qemu, common to both pv, hvm */
     parse_extra_args();
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:22:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYw-0005AW-Ti; Tue, 29 Nov 2011 14:21:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYv-00056s-JA
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322576453!3551410!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1379 invoked from network); 29 Nov 2011 14:20:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488420"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:52 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0T018170;	Tue, 29 Nov 2011 06:20:51 -0800
MIME-Version: 1.0
X-Mercurial-Node: c6a2b11a2bd442220395ae117c33925619788204
Message-ID: <c6a2b11a2bd442220395.1322576450@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 08 of 17 v3] libxl: use named options for
	tsc_mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID c6a2b11a2bd442220395ae117c33925619788204
# Parent  9a8406b8209ae3a36162b0929c279325d23ee89e
libxl: use named options for tsc_mode.

Add an enum at the libxl level with a hopefully descriptive set of names.
Deprecate the use of an integer in xl cfg files.

Signed-off-by: Ian Campbell

diff -r 9a8406b8209a -r c6a2b11a2bd4 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
@@ -491,11 +491,45 @@ compatibility mode on more modern Window
 
 =item B<tsc_mode="MODE">
 
+
 Specifies how the TSC (Time Stamp Counter) should be provided to the
-guest.  XXX ???
+guest (X86 only). Specifying this option as a number is
+deprecated. Options are:
+
+=over 4
+
+=item B<"default">
+
+Guest rdtsc/p executed natively when monotonicity can be guaranteed
+and emulated otherwise (with frequency scaled if necessary).
+
+=item B<"always_emulate">
+
+Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
+always emulated and the virtual TSC will appear to increment (kernel
+and user) at a fixed 1GHz rate, regardless of the PCPU HZ rate or
+power state; Although there is an overhead associated with emulation
+this will NOT affect underlying CPU performance.
+
+=item B<"native">
+
+Guest rdtsc always executed natively (no monotonicity/frequency
+guarantees); guest rdtscp emulated at native frequency if unsupported
+by h/w, else executed natively.
+
+=item B<"native_paravirt">
+
+Same as B<native>, except xen manages TSC_AUX register so guest can
+determine when a restore/migration has occurred and assumes guest
+obtains/uses pvclock-like mechanism to adjust for monotonicity and
+frequency changes.
 
 =back
 
+=back
+
+Please see F<docs/misc/tscmode.txt> for more information on this option.
+
 =head3 Support for Paravirtualisation of HVM Guests
 
 The following options allow Paravirtualised features (such as devices)
diff -r 9a8406b8209a -r c6a2b11a2bd4 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Nov 29 14:17:27 2011 +0000
@@ -73,12 +73,29 @@ int libxl__build_pre(libxl__gc *gc, uint
               libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    int tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
                 (info->max_memkb + info->u.pv.slack_memkb));
-    xc_domain_set_tsc_info(ctx->xch, domid, info->tsc_mode, 0, 0, 0);
+    switch (info->tsc_mode) {
+    case LIBXL_TSC_MODE_DEFAULT:
+        tsc_mode = 0;
+        break;
+    case LIBXL_TSC_MODE_ALWAYS_EMULATE:
+        tsc_mode = 1;
+        break;
+    case LIBXL_TSC_MODE_NATIVE:
+        tsc_mode = 2;
+        break;
+    case LIBXL_TSC_MODE_NATIVE_PARAVIRT:
+        tsc_mode = 3;
+        break;
+    default:
+        abort();
+    }
+    xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
     if ( info->disable_migrate )
         xc_domain_disable_migrate(ctx->xch, domid);
 
diff -r 9a8406b8209a -r c6a2b11a2bd4 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Nov 29 14:17:27 2011 +0000
@@ -85,6 +85,13 @@ libxl_button = Enumeration("button", [
     (2, "SLEEP"),
     ])
 
+libxl_tsc_mode = Enumeration("tsc_mode", [
+    (0, "default"),
+    (1, "always_emulate"),
+    (2, "native"),
+    (3, "native_paravirt"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -154,7 +161,7 @@ libxl_domain_create_info = Struct("domai
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
-    ("tsc_mode",        integer),
+    ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
     ("video_memkb",     uint32),
diff -r 9a8406b8209a -r c6a2b11a2bd4 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -328,7 +328,7 @@ static void printf_info(int domid,
 
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
-    printf("\t(tsc_mode %d)\n", b_info->tsc_mode);
+    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
@@ -662,8 +662,28 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
+        const char *s = libxl_tsc_mode_to_string(l);
+        fprintf(stderr, "WARNING: specifying \"tsc_mode\" as an integer is deprecated. "
+                "Please use the named parameter variant. %s%s%s\n",
+                s ? "e.g. tsc_mode=\"" : "",
+                s ? s : "",
+                s ? "\"" : "");
+
+        if (l < LIBXL_TSC_MODE_DEFAULT ||
+            l > LIBXL_TSC_MODE_NATIVE_PARAVIRT) {
+            fprintf(stderr, "ERROR: invalid value %ld for \"tsc_mode\"\n", l);
+            exit (1);
+        }
         b_info->tsc_mode = l;
+    } else if (!xlu_cfg_get_string(config, "tsc_mode", &buf, 0)) {
+        fprintf(stderr, "got a tsc mode string: \"%s\"\n", buf);
+        if (libxl_tsc_mode_from_string(buf, &b_info->tsc_mode)) {
+            fprintf(stderr, "ERROR: invalid value \"%s\" for \"tsc_mode\"\n",
+                    buf);
+            exit (1);
+        }
+    }
 
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:22:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:22:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOYw-0005AW-Ti; Tue, 29 Nov 2011 14:21:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOYv-00056s-JA
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322576453!3551410!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1379 invoked from network); 29 Nov 2011 14:20:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:20:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488420"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:52 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0T018170;	Tue, 29 Nov 2011 06:20:51 -0800
MIME-Version: 1.0
X-Mercurial-Node: c6a2b11a2bd442220395ae117c33925619788204
Message-ID: <c6a2b11a2bd442220395.1322576450@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:50 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 08 of 17 v3] libxl: use named options for
	tsc_mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID c6a2b11a2bd442220395ae117c33925619788204
# Parent  9a8406b8209ae3a36162b0929c279325d23ee89e
libxl: use named options for tsc_mode.

Add an enum at the libxl level with a hopefully descriptive set of names.
Deprecate the use of an integer in xl cfg files.

Signed-off-by: Ian Campbell

diff -r 9a8406b8209a -r c6a2b11a2bd4 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
@@ -491,11 +491,45 @@ compatibility mode on more modern Window
 
 =item B<tsc_mode="MODE">
 
+
 Specifies how the TSC (Time Stamp Counter) should be provided to the
-guest.  XXX ???
+guest (X86 only). Specifying this option as a number is
+deprecated. Options are:
+
+=over 4
+
+=item B<"default">
+
+Guest rdtsc/p executed natively when monotonicity can be guaranteed
+and emulated otherwise (with frequency scaled if necessary).
+
+=item B<"always_emulate">
+
+Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
+always emulated and the virtual TSC will appear to increment (kernel
+and user) at a fixed 1GHz rate, regardless of the PCPU HZ rate or
+power state; Although there is an overhead associated with emulation
+this will NOT affect underlying CPU performance.
+
+=item B<"native">
+
+Guest rdtsc always executed natively (no monotonicity/frequency
+guarantees); guest rdtscp emulated at native frequency if unsupported
+by h/w, else executed natively.
+
+=item B<"native_paravirt">
+
+Same as B<native>, except xen manages TSC_AUX register so guest can
+determine when a restore/migration has occurred and assumes guest
+obtains/uses pvclock-like mechanism to adjust for monotonicity and
+frequency changes.
 
 =back
 
+=back
+
+Please see F<docs/misc/tscmode.txt> for more information on this option.
+
 =head3 Support for Paravirtualisation of HVM Guests
 
 The following options allow Paravirtualised features (such as devices)
diff -r 9a8406b8209a -r c6a2b11a2bd4 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxl_dom.c	Tue Nov 29 14:17:27 2011 +0000
@@ -73,12 +73,29 @@ int libxl__build_pre(libxl__gc *gc, uint
               libxl_domain_build_info *info, libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    int tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
                 (info->max_memkb + info->u.pv.slack_memkb));
-    xc_domain_set_tsc_info(ctx->xch, domid, info->tsc_mode, 0, 0, 0);
+    switch (info->tsc_mode) {
+    case LIBXL_TSC_MODE_DEFAULT:
+        tsc_mode = 0;
+        break;
+    case LIBXL_TSC_MODE_ALWAYS_EMULATE:
+        tsc_mode = 1;
+        break;
+    case LIBXL_TSC_MODE_NATIVE:
+        tsc_mode = 2;
+        break;
+    case LIBXL_TSC_MODE_NATIVE_PARAVIRT:
+        tsc_mode = 3;
+        break;
+    default:
+        abort();
+    }
+    xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
     if ( info->disable_migrate )
         xc_domain_disable_migrate(ctx->xch, domid);
 
diff -r 9a8406b8209a -r c6a2b11a2bd4 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Nov 29 14:17:27 2011 +0000
@@ -85,6 +85,13 @@ libxl_button = Enumeration("button", [
     (2, "SLEEP"),
     ])
 
+libxl_tsc_mode = Enumeration("tsc_mode", [
+    (0, "default"),
+    (1, "always_emulate"),
+    (2, "native"),
+    (3, "native_paravirt"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -154,7 +161,7 @@ libxl_domain_create_info = Struct("domai
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
-    ("tsc_mode",        integer),
+    ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
     ("video_memkb",     uint32),
diff -r 9a8406b8209a -r c6a2b11a2bd4 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -328,7 +328,7 @@ static void printf_info(int domid,
 
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
-    printf("\t(tsc_mode %d)\n", b_info->tsc_mode);
+    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
@@ -662,8 +662,28 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
         b_info->disable_migrate = l;
 
-    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
+    if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
+        const char *s = libxl_tsc_mode_to_string(l);
+        fprintf(stderr, "WARNING: specifying \"tsc_mode\" as an integer is deprecated. "
+                "Please use the named parameter variant. %s%s%s\n",
+                s ? "e.g. tsc_mode=\"" : "",
+                s ? s : "",
+                s ? "\"" : "");
+
+        if (l < LIBXL_TSC_MODE_DEFAULT ||
+            l > LIBXL_TSC_MODE_NATIVE_PARAVIRT) {
+            fprintf(stderr, "ERROR: invalid value %ld for \"tsc_mode\"\n", l);
+            exit (1);
+        }
         b_info->tsc_mode = l;
+    } else if (!xlu_cfg_get_string(config, "tsc_mode", &buf, 0)) {
+        fprintf(stderr, "got a tsc mode string: \"%s\"\n", buf);
+        if (libxl_tsc_mode_from_string(buf, &b_info->tsc_mode)) {
+            fprintf(stderr, "ERROR: invalid value \"%s\" for \"tsc_mode\"\n",
+                    buf);
+            exit (1);
+        }
+    }
 
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:22:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZB-0005N3-9e; Tue, 29 Nov 2011 14:21:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOZ9-0005Gs-Cu
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322576458!6100013!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27717 invoked from network); 29 Nov 2011 14:21:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:21:08 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488427"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:58 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0Z018170;	Tue, 29 Nov 2011 06:20:57 -0800
MIME-Version: 1.0
X-Mercurial-Node: a08afddff75b70f816d383206a0c6d2dfe0e9a7e
Message-ID: <a08afddff75b70f816d3.1322576456@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:56 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 14 of 17 v3] xl: make bootloader_args a list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID a08afddff75b70f816d383206a0c6d2dfe0e9a7e
# Parent  56f438c2a5aa6e11a765bc686bff7aa61d8eab7d
xl: make bootloader_args a list

This is much more natural. Continue to support the old syntax in xl but deprecate it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 56f438c2a5aa -r a08afddff75b docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
@@ -321,10 +321,11 @@ Run C<PROGRAM> to find the kernel image 
 C<PROGRAM> would be C<pygrub>, which is an emulation of
 grub/grub2/syslinux.
 
-=item B<bootloader_args=STRING>
+=item B<bootloader_args=[ "ARG", "ARG", ...]>
 
-Append B<STRING> (split into words at whitespace) to the arguments to
-the B<bootloader> program.  XXX this should be a list of strings.
+Append B<ARG>s to the arguments to the B<bootloader>
+program. Alternatively if the argument is a simple string then it will
+be split into words at whitespace (this second option is deprecated).
 
 =item B<root="STRING">
 
diff -r 56f438c2a5aa -r a08afddff75b tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxl_bootloader.c	Tue Nov 29 14:17:27 2011 +0000
@@ -58,13 +58,9 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *saveptr;
-        /* Operate on a duplicate since strtok modifes the argument */
-        char *dup = libxl__strdup(gc, info->u.pv.bootloader_args);
-        char *t = strtok_r(dup, " \t\n", &saveptr);
-        do {
-            flexarray_set(args, nr++, t);
-        } while ((t = strtok_r(NULL, " \t\n", &saveptr)));
+        char *p = info->u.pv.bootloader_args[0];
+        while (*(p++))
+            flexarray_set(args, nr++, p);
     }
 
     flexarray_set(args, nr++, disk);
diff -r 56f438c2a5aa -r a08afddff75b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Nov 29 14:17:27 2011 +0000
@@ -187,7 +187,7 @@ libxl_domain_build_info = Struct("domain
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
                                       ("bootloader", string),
-                                      ("bootloader_args", string),
+                                      ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, True),
diff -r 56f438c2a5aa -r a08afddff75b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -334,9 +334,14 @@ static void printf_info(int domid,
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
+        int i;
         printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
-        if (b_info->u.pv.bootloader_args)
-            printf("\t(bootloader_args %s)\n", b_info->u.pv.bootloader_args);
+        if (b_info->u.pv.bootloader_args) {
+            printf("\t(bootloader_args");
+            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
+                printf(" %s", b_info->u.pv.bootloader_args[i]);
+            printf(")\n");
+        }
     }
 
     printf("\t(image\n");
@@ -515,6 +520,51 @@ static void parse_disk_config(XLU_Config
     parse_disk_config_multistring(config, 1, &spec, disk);
 }
 
+static void split_string_into_string_list(const char *str,
+                                          const char *delim,
+                                          libxl_string_list *psl)
+{
+    char *s, *saveptr;
+    const char *p;
+    libxl_string_list sl;
+
+    int i = 0, nr = 0;
+
+    s = strdup(str);
+    if (s == NULL) {
+        fprintf(stderr, "unable to allocate memory to parse bootloader args\n");
+        exit(-1);
+    }
+
+    /* Count number of entries */
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        nr++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+
+    free(s);
+
+    s = strdup(str);
+
+    sl = malloc((nr+1) * sizeof (char *));
+    if (sl == NULL) {
+        fprintf(stderr, "unable to allocate memory for bootloader args\n");
+        exit(-1);
+    }
+
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        assert(i < nr);
+        sl[i] = strdup(p);
+        i++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+    sl[i] = NULL;
+
+    *psl = sl;
+
+    free(s);
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -739,10 +789,26 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader",
-                                &b_info->u.pv.bootloader, 0);
-        xlu_cfg_replace_string (config, "bootloader_args",
-                                &b_info->u.pv.bootloader_args, 0);
+        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader, 0);
+        switch (xlu_cfg_get_list_as_string_list(config, "bootloader_args",
+                                                &b_info->u.pv.bootloader_args, 1))
+        {
+
+        case 0: break; /* Success */
+        case ESRCH: break; /* Option not present */
+        case EINVAL:
+            if (!xlu_cfg_get_string(config, "bootloader_args", &buf, 0)) {
+
+                fprintf(stderr, "WARNING: Specifying \"bootloader_args\" as a string is deprecated. "
+                        "Please use a list of arguments.\n");
+                split_string_into_string_list(buf, " \t\n",
+                                              &b_info->u.pv.bootloader_args);
+            }
+            break;
+        default:
+            fprintf(stderr,"xl: Unable to parse bootloader_args.\n");
+            exit(-ERROR_FAIL);
+        }
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:22:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZB-0005N3-9e; Tue, 29 Nov 2011 14:21:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVOZ9-0005Gs-Cu
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:21:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322576458!6100013!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27717 invoked from network); 29 Nov 2011 14:21:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:21:08 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19488427"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 09:20:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 09:20:58 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATEKh0Z018170;	Tue, 29 Nov 2011 06:20:57 -0800
MIME-Version: 1.0
X-Mercurial-Node: a08afddff75b70f816d383206a0c6d2dfe0e9a7e
Message-ID: <a08afddff75b70f816d3.1322576456@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1322576442@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 14:20:56 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 14 of 17 v3] xl: make bootloader_args a list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322576247 0
# Node ID a08afddff75b70f816d383206a0c6d2dfe0e9a7e
# Parent  56f438c2a5aa6e11a765bc686bff7aa61d8eab7d
xl: make bootloader_args a list

This is much more natural. Continue to support the old syntax in xl but deprecate it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 56f438c2a5aa -r a08afddff75b docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
+++ b/docs/man/xl.cfg.pod.5	Tue Nov 29 14:17:27 2011 +0000
@@ -321,10 +321,11 @@ Run C<PROGRAM> to find the kernel image 
 C<PROGRAM> would be C<pygrub>, which is an emulation of
 grub/grub2/syslinux.
 
-=item B<bootloader_args=STRING>
+=item B<bootloader_args=[ "ARG", "ARG", ...]>
 
-Append B<STRING> (split into words at whitespace) to the arguments to
-the B<bootloader> program.  XXX this should be a list of strings.
+Append B<ARG>s to the arguments to the B<bootloader>
+program. Alternatively if the argument is a simple string then it will
+be split into words at whitespace (this second option is deprecated).
 
 =item B<root="STRING">
 
diff -r 56f438c2a5aa -r a08afddff75b tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxl_bootloader.c	Tue Nov 29 14:17:27 2011 +0000
@@ -58,13 +58,9 @@ static char **make_bootloader_args(libxl
     flexarray_set(args, nr++, libxl__sprintf(gc, "--output-directory=%s", "/var/run/libxl/"));
 
     if (info->u.pv.bootloader_args) {
-        char *saveptr;
-        /* Operate on a duplicate since strtok modifes the argument */
-        char *dup = libxl__strdup(gc, info->u.pv.bootloader_args);
-        char *t = strtok_r(dup, " \t\n", &saveptr);
-        do {
-            flexarray_set(args, nr++, t);
-        } while ((t = strtok_r(NULL, " \t\n", &saveptr)));
+        char *p = info->u.pv.bootloader_args[0];
+        while (*(p++))
+            flexarray_set(args, nr++, p);
     }
 
     flexarray_set(args, nr++, disk);
diff -r 56f438c2a5aa -r a08afddff75b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Nov 29 14:17:27 2011 +0000
@@ -187,7 +187,7 @@ libxl_domain_build_info = Struct("domain
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
                                       ("bootloader", string),
-                                      ("bootloader_args", string),
+                                      ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, True),
diff -r 56f438c2a5aa -r a08afddff75b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Nov 29 14:17:27 2011 +0000
@@ -334,9 +334,14 @@ static void printf_info(int domid,
     printf("\t(nomigrate %d)\n", b_info->disable_migrate);
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
+        int i;
         printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
-        if (b_info->u.pv.bootloader_args)
-            printf("\t(bootloader_args %s)\n", b_info->u.pv.bootloader_args);
+        if (b_info->u.pv.bootloader_args) {
+            printf("\t(bootloader_args");
+            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
+                printf(" %s", b_info->u.pv.bootloader_args[i]);
+            printf(")\n");
+        }
     }
 
     printf("\t(image\n");
@@ -515,6 +520,51 @@ static void parse_disk_config(XLU_Config
     parse_disk_config_multistring(config, 1, &spec, disk);
 }
 
+static void split_string_into_string_list(const char *str,
+                                          const char *delim,
+                                          libxl_string_list *psl)
+{
+    char *s, *saveptr;
+    const char *p;
+    libxl_string_list sl;
+
+    int i = 0, nr = 0;
+
+    s = strdup(str);
+    if (s == NULL) {
+        fprintf(stderr, "unable to allocate memory to parse bootloader args\n");
+        exit(-1);
+    }
+
+    /* Count number of entries */
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        nr++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+
+    free(s);
+
+    s = strdup(str);
+
+    sl = malloc((nr+1) * sizeof (char *));
+    if (sl == NULL) {
+        fprintf(stderr, "unable to allocate memory for bootloader args\n");
+        exit(-1);
+    }
+
+    p = strtok_r(s, delim, &saveptr);
+    do {
+        assert(i < nr);
+        sl[i] = strdup(p);
+        i++;
+    } while ((p = strtok_r(NULL, delim, &saveptr)));
+    sl[i] = NULL;
+
+    *psl = sl;
+
+    free(s);
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -739,10 +789,26 @@ static void parse_config_data(const char
             exit(1);
         }
 
-        xlu_cfg_replace_string (config, "bootloader",
-                                &b_info->u.pv.bootloader, 0);
-        xlu_cfg_replace_string (config, "bootloader_args",
-                                &b_info->u.pv.bootloader_args, 0);
+        xlu_cfg_replace_string (config, "bootloader", &b_info->u.pv.bootloader, 0);
+        switch (xlu_cfg_get_list_as_string_list(config, "bootloader_args",
+                                                &b_info->u.pv.bootloader_args, 1))
+        {
+
+        case 0: break; /* Success */
+        case ESRCH: break; /* Option not present */
+        case EINVAL:
+            if (!xlu_cfg_get_string(config, "bootloader_args", &buf, 0)) {
+
+                fprintf(stderr, "WARNING: Specifying \"bootloader_args\" as a string is deprecated. "
+                        "Please use a list of arguments.\n");
+                split_string_into_string_list(buf, " \t\n",
+                                              &b_info->u.pv.bootloader_args);
+            }
+            break;
+        default:
+            fprintf(stderr,"xl: Unable to parse bootloader_args.\n");
+            exit(-ERROR_FAIL);
+        }
 
         if (!b_info->u.pv.bootloader && !b_info->u.pv.kernel.path) {
             fprintf(stderr, "Neither kernel nor bootloader specified\n");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:22:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZa-0005kk-WF; Tue, 29 Nov 2011 14:22:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVOZZ-0005bX-CX
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:22:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322576461!50432894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32261 invoked from network); 29 Nov 2011 14:21:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9187117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:21:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 14:21:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVOYs-0003nA-CG; Tue, 29 Nov 2011 14:21:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVOYs-0002VN-BV;
	Tue, 29 Nov 2011 14:21:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20180.60010.340541.856571@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 14:21:30 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111115150024.GA21174@phenom.dumpdata.com>
References: <1321212066-10648-1-git-send-email-ian.jackson@eu.citrix.com>
	<1321212066-10648-3-git-send-email-ian.jackson@eu.citrix.com>
	<20111114184057.GB15284@phenom.dumpdata.com>
	<20162.31597.556145.478476@mariner.uk.xensource.com>
	<20111115150024.GA21174@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] docs/html/hcall: Annotations for
	two	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH 2/4] docs/html/hcall: Annotations for two hypercalls"):
> On Tue, Nov 15, 2011 at 02:47:09PM +0000, Ian Jackson wrote:
> > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH 2/4] docs/html/hcall: Annotations for two hypercalls"):
> > > On Sun, Nov 13, 2011 at 07:21:04PM +0000, Ian Jackson wrote:
> > > > Add annotations for a couple of the hypercalls:
> > > >  HYPERVISOR_set_trap_table
> > > >  HYPERVISOR_mmu_update
> > > 
> > > So I've some comments on the affects of what this hypercall expects
> > > in some details. Where would I put those? In the header file or should
> > > I do it somewhere else?
> > 
> > In the header file.
> 
> Is it OK if it runs on for pages?

Yes.  See also the approach we're taking in libxl.h.

If it really gets too long you can take it out and put it in a text or
markdown or pod file in docs/, leaving behind a reference.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:22:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOZa-0005kk-WF; Tue, 29 Nov 2011 14:22:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVOZZ-0005bX-CX
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:22:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322576461!50432894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32261 invoked from network); 29 Nov 2011 14:21:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:21:01 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9187117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:21:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 14:21:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVOYs-0003nA-CG; Tue, 29 Nov 2011 14:21:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVOYs-0002VN-BV;
	Tue, 29 Nov 2011 14:21:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20180.60010.340541.856571@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 14:21:30 +0000
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20111115150024.GA21174@phenom.dumpdata.com>
References: <1321212066-10648-1-git-send-email-ian.jackson@eu.citrix.com>
	<1321212066-10648-3-git-send-email-ian.jackson@eu.citrix.com>
	<20111114184057.GB15284@phenom.dumpdata.com>
	<20162.31597.556145.478476@mariner.uk.xensource.com>
	<20111115150024.GA21174@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] docs/html/hcall: Annotations for
	two	hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH 2/4] docs/html/hcall: Annotations for two hypercalls"):
> On Tue, Nov 15, 2011 at 02:47:09PM +0000, Ian Jackson wrote:
> > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH 2/4] docs/html/hcall: Annotations for two hypercalls"):
> > > On Sun, Nov 13, 2011 at 07:21:04PM +0000, Ian Jackson wrote:
> > > > Add annotations for a couple of the hypercalls:
> > > >  HYPERVISOR_set_trap_table
> > > >  HYPERVISOR_mmu_update
> > > 
> > > So I've some comments on the affects of what this hypercall expects
> > > in some details. Where would I put those? In the header file or should
> > > I do it somewhere else?
> > 
> > In the header file.
> 
> Is it OK if it runs on for pages?

Yes.  See also the approach we're taking in libxl.h.

If it really gets too long you can take it out and put it in a text or
markdown or pod file in docs/, leaving behind a reference.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:22:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOa7-000623-Id; Tue, 29 Nov 2011 14:22:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RVOa6-0005zW-5O
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:22:46 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322576524!6243097!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU2OTE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6350 invoked from network); 29 Nov 2011 14:22:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 14:22:04 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pATELrNv017397
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 29 Nov 2011 09:21:53 -0500
Received: from localhost (ovpn-113-104.phx2.redhat.com [10.3.113.104])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pATELouX030473; Tue, 29 Nov 2011 09:21:51 -0500
Date: Tue, 29 Nov 2011 19:51:49 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111129142149.GE2822@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On (Mon) 28 Nov 2011 [15:40:41], Miche Baker-Harvey wrote:
> Amit,
> 
> You said that the work would be serialized "due to port additions
> being on work items on the same workqueue".  I'm not seeing that.

You leave a lot of questions unanswered.  What's your environment?
Are you hot-plugging ports?  Are you using qemu?  What's your command
line?

> I've double checked this by using a mutex_trylock in
> hvc_console::hvc_alloc(), and here's the relevant output from dmesg:
> 
> root@myubuntu:~# dmesg | grep MBH
> [3307216.210274] MBH: got hvc_ports_mutex
> [3307216.210690] MBH: trylock of hvc_ports_mutex failed
> [3307216.211143] MBH: got hvc_ports_mutex
> 
> This is in a system with two virtio console ports, each of which is a
> console.  I think if the VIRTIO_CONSOLE_CONSOLE_PORT message handling
> were actually being serialized, the trylock should never fail.

Agreed.

> What's the source of the serialization for the workqueue items?  At
> first reading it looks like the control_work_handler gets called for
> each virtio interrupt?

It all depends on how you add ports.  If you're using qemu, they
happen via the control work handler.

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:22:55 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVOa7-000623-Id; Tue, 29 Nov 2011 14:22:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <amit.shah@redhat.com>) id 1RVOa6-0005zW-5O
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:22:46 +0000
X-Env-Sender: amit.shah@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322576524!6243097!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU2OTE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6350 invoked from network); 29 Nov 2011 14:22:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 14:22:04 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pATELrNv017397
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 29 Nov 2011 09:21:53 -0500
Received: from localhost (ovpn-113-104.phx2.redhat.com [10.3.113.104])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id pATELouX030473; Tue, 29 Nov 2011 09:21:51 -0500
Date: Tue, 29 Nov 2011 19:51:49 +0530
From: Amit Shah <amit.shah@redhat.com>
To: Miche Baker-Harvey <miche@google.com>
Message-ID: <20111129142149.GE2822@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

On (Mon) 28 Nov 2011 [15:40:41], Miche Baker-Harvey wrote:
> Amit,
> 
> You said that the work would be serialized "due to port additions
> being on work items on the same workqueue".  I'm not seeing that.

You leave a lot of questions unanswered.  What's your environment?
Are you hot-plugging ports?  Are you using qemu?  What's your command
line?

> I've double checked this by using a mutex_trylock in
> hvc_console::hvc_alloc(), and here's the relevant output from dmesg:
> 
> root@myubuntu:~# dmesg | grep MBH
> [3307216.210274] MBH: got hvc_ports_mutex
> [3307216.210690] MBH: trylock of hvc_ports_mutex failed
> [3307216.211143] MBH: got hvc_ports_mutex
> 
> This is in a system with two virtio console ports, each of which is a
> console.  I think if the VIRTIO_CONSOLE_CONSOLE_PORT message handling
> were actually being serialized, the trylock should never fail.

Agreed.

> What's the source of the serialization for the workqueue items?  At
> first reading it looks like the control_work_handler gets called for
> each virtio interrupt?

It all depends on how you add ports.  If you're using qemu, they
happen via the control work handler.

		Amit

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:53:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:53:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVP3e-0000m0-7r; Tue, 29 Nov 2011 14:53:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVP3d-0000lv-BO
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:53:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322578359!6037584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11375 invoked from network); 29 Nov 2011 14:52:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:52:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 14:52:39 +0000
Date: Tue, 29 Nov 2011 14:53:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: linaro-dev@lists.linaro.org, kvm@vger.kernel.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	android-virt@lists.cs.columbia.edu,
	embeddedxen-devel@lists.sourceforge.net,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
a few weeks ago I (and a few others) started hacking on a
proof-of-concept hypervisor port to Cortex-A15 which uses and requires
ARMv7 virtualization extensions. The intention of this work was to find
out how to best support ARM v7+ on Xen. See
http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
for more details. 

I am pleased to announce that significant progress has been made, and
that we now have a nascent Xen port for Cortex-A15. The port is based on
xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
the latest virtualization, LPAE, GIC and generic timer support in
hardware.

We started the work less than three months ago, but the port is already
capable of booting a Linux 3.0 based virtual machine (dom0) up to a
shell prompt on an ARM Architecture Envelope Model, configured to emulate
an A15-based Versatile Express. In this context, we wanted to thank ARM
for making the model available to us.
Now we are looking forward to porting the tools and running multiple
guests.

The code requires virtualization, LPAE and GIC support and therefore it
won't be able to run on anything older than a Cortex-A15.
On the other hand, thanks to this, it is very small and easy to read,
write and understand.
The implementation does not distinguish between PV and HVM guests: there
is just one type of guests that would be comparable to Linux PV on HVM
in the Xen X86 world, but with no need for Qemu emulation.
The code only requires minimal changes to the Linux kernel: just enough
to support PV drivers.

Even though we are currently targeting Versatile Express and Cortex-A15
we do intend to support other machines and other ARMv7 with
virtualization extensions CPUs.
We are also looking forward to ARMv8 and 64 bits support.

Given that porting Xen to Cortex-A15 could be done with so little code,
we believe that the best course of action is to merge it into
xen-unstable as quickly as possible. There are still few rough edges to
sort out but we should be able to produce a clean and digestible patch
series for submission to xen-devel within the next couple of months. I
hope to see the first patches going to the list as soon as possible.
We would very welcome any contributions, in the form of testing, code
reviews and, of course, patches! 


A git tree is available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm

the gitweb url is the following:

http://xenbits.xen.org/gitweb/?p=people/sstabellini/xen-unstable.git/.git;a=shortlog;h=refs/heads/arm

And here is the full diff:

http://xenbits.xen.org/people/sstabellini/diff


We want to point out that this effort is in addition to Samsung's
ongoing efforts to upstream Xen ARM to xen-unstable. Samsung's XenARM
port allows virtualization of Xen on ARM CPUs prior to virtualization
extensions and supports traditional PV guests.

I would like to thank Tim Deegan and Ian Campbell: if you spend some
time reading the history, you'll see that this project wouldn't have
been possible in such a short time without great contributions from
them.

Cheers,
Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 14:53:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 14:53:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVP3e-0000m0-7r; Tue, 29 Nov 2011 14:53:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVP3d-0000lv-BO
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 14:53:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322578359!6037584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11375 invoked from network); 29 Nov 2011 14:52:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 14:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 14:52:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 14:52:39 +0000
Date: Tue, 29 Nov 2011 14:53:34 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: linaro-dev@lists.linaro.org, kvm@vger.kernel.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	android-virt@lists.cs.columbia.edu,
	embeddedxen-devel@lists.sourceforge.net,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
a few weeks ago I (and a few others) started hacking on a
proof-of-concept hypervisor port to Cortex-A15 which uses and requires
ARMv7 virtualization extensions. The intention of this work was to find
out how to best support ARM v7+ on Xen. See
http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
for more details. 

I am pleased to announce that significant progress has been made, and
that we now have a nascent Xen port for Cortex-A15. The port is based on
xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
the latest virtualization, LPAE, GIC and generic timer support in
hardware.

We started the work less than three months ago, but the port is already
capable of booting a Linux 3.0 based virtual machine (dom0) up to a
shell prompt on an ARM Architecture Envelope Model, configured to emulate
an A15-based Versatile Express. In this context, we wanted to thank ARM
for making the model available to us.
Now we are looking forward to porting the tools and running multiple
guests.

The code requires virtualization, LPAE and GIC support and therefore it
won't be able to run on anything older than a Cortex-A15.
On the other hand, thanks to this, it is very small and easy to read,
write and understand.
The implementation does not distinguish between PV and HVM guests: there
is just one type of guests that would be comparable to Linux PV on HVM
in the Xen X86 world, but with no need for Qemu emulation.
The code only requires minimal changes to the Linux kernel: just enough
to support PV drivers.

Even though we are currently targeting Versatile Express and Cortex-A15
we do intend to support other machines and other ARMv7 with
virtualization extensions CPUs.
We are also looking forward to ARMv8 and 64 bits support.

Given that porting Xen to Cortex-A15 could be done with so little code,
we believe that the best course of action is to merge it into
xen-unstable as quickly as possible. There are still few rough edges to
sort out but we should be able to produce a clean and digestible patch
series for submission to xen-devel within the next couple of months. I
hope to see the first patches going to the list as soon as possible.
We would very welcome any contributions, in the form of testing, code
reviews and, of course, patches! 


A git tree is available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm

the gitweb url is the following:

http://xenbits.xen.org/gitweb/?p=people/sstabellini/xen-unstable.git/.git;a=shortlog;h=refs/heads/arm

And here is the full diff:

http://xenbits.xen.org/people/sstabellini/diff


We want to point out that this effort is in addition to Samsung's
ongoing efforts to upstream Xen ARM to xen-unstable. Samsung's XenARM
port allows virtualization of Xen on ARM CPUs prior to virtualization
extensions and supports traditional PV guests.

I would like to thank Tim Deegan and Ian Campbell: if you spend some
time reading the history, you'll see that this project wouldn't have
been possible in such a short time without great contributions from
them.

Cheers,
Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:02:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPCL-00014W-97; Tue, 29 Nov 2011 15:02:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPCJ-00014L-LS
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:02:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322578898!3553118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20603 invoked from network); 29 Nov 2011 15:01:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:01:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:01:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:01:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPBh-00040I-Hc; Tue, 29 Nov 2011 15:01:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPBh-0002c9-Fn;
	Tue, 29 Nov 2011 15:01:37 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 29 Nov 2011 15:01:29 +0000
Message-ID: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 0/4] docs/html/: Hypercall docs from headers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is the revised version of my hypercall docs series:
 - Addresses all comments from v1
 - Renamed output directory to docs/html/hypercall


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:02:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPCL-00014W-97; Tue, 29 Nov 2011 15:02:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPCJ-00014L-LS
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:02:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322578898!3553118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20603 invoked from network); 29 Nov 2011 15:01:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:01:38 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:01:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:01:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPBh-00040I-Hc; Tue, 29 Nov 2011 15:01:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPBh-0002c9-Fn;
	Tue, 29 Nov 2011 15:01:37 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 29 Nov 2011 15:01:29 +0000
Message-ID: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2 0/4] docs/html/: Hypercall docs from headers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is the revised version of my hypercall docs series:
 - Addresses all comments from v1
 - Renamed output directory to docs/html/hypercall


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:02:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPCR-00015b-Ov; Tue, 29 Nov 2011 15:02:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPCQ-00014U-5C
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:02:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322578898!3553118!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21244 invoked from network); 29 Nov 2011 15:01:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:01:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188404"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:01:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:01:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPBo-00040T-0f; Tue, 29 Nov 2011 15:01:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPBn-0002cR-WC;
	Tue, 29 Nov 2011 15:01:43 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 15:01:32 +0000
Message-ID: <1322578893-9998-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/4] docs/html/: Generate an "index.html" for
	hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Generate an "index.html" containing various useful links.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 docs/xen-headers         |   59 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h |    4 ++-
 2 files changed, 62 insertions(+), 1 deletions(-)

diff --git a/docs/xen-headers b/docs/xen-headers
index e893f91..dcf673e 100755
--- a/docs/xen-headers
+++ b/docs/xen-headers
@@ -17,6 +17,10 @@
 
 #  definitions must start in LH column
 #  extra syntax:
+#   `incontents <seq> <shortname> <anchor text html>...
+#                              make a table of contents entry; they
+#                              will be sorted by increasing seq, and
+#                              shortname will be used as the anchor target
 #    /* ` <definition>                          } parse as if <definition>
 #     * ` <definition>                          }  was not commented
 #   enum <name> { // <pattern>* => <func>()     } cross-reference
@@ -60,6 +64,8 @@ my ($basedir,@indirs) = @ARGV;
 # general globals
 our $pass;
 our %sdef; 
+our @incontents;
+our @outfiles;
 # $sdef{$type}{$name} => {
 #     DefLocs => { "$leaf_path:$lineno" => $leaf_opath ,... }
 #     Xrefs => { "$leaf_path,$lineno" => "$xref", ... }
@@ -187,6 +193,19 @@ sub out_xrefs ($) {
     @pending_xrefs = ();
 }
 
+sub incontents ($$$) {
+    my ($text, $seq, $anchor) = @_;
+    $anchor = "incontents_$anchor";
+    if ($pass==2) {
+	push @incontents, { 
+	    Seq => $seq,
+	    Href => "$leaf_opath#$anchor",
+	    Title => $text,
+	};
+    }
+    return "<a name=\"$anchor\"><strong>$text</strong></a>";
+}
+
 sub write_file ($$) {
     my ($opath, $odata) = @_;
     my $out = new IO::File "$opath.new", '>' or die "$opath $!";
@@ -242,6 +261,8 @@ sub process_file ($$) {
 	    }
 	} elsif (s/^( \s* \#define \s+ ) (\w+) ( \s+\S )
                   / $1.defmacro($2).norm($3) /xe) {
+	} elsif (s/( \`incontents \s+ (\d+) \s+ (\w+) \s+ )(\S .* \S)
+                 / norm($1).incontents($4, $2, $3) /xe) {
 	} else {
 	    if (m/^\s*\}/) {
 		$in_enum = undef;
@@ -261,11 +282,47 @@ sub process_file ($$) {
     warning("pending xrefs at end of file") if @pending_xrefs;
 
     if ($pass == 2) {
+	push @outfiles, [ $leaf, $leaf_opath ];
 	$o .= "</pre></body></html>";
 	write_file($outfile, $o);
     }
 }
 
+sub output_index () {
+    my $title = "contents - $xtitle";
+    $o = '';
+    $o .= <<END;
+<html><head><title>$title</title></head>
+<body>
+<h1>$title</h1>
+<h2>Starting points</h2>
+<ul>
+END
+    foreach my $ic (sort { $a->{Seq} <=> $b->{Seq} } @incontents) {
+	$o .= "<li><a href=\"$ic->{Href}\">$ic->{Title}</a></li>\n";
+    }
+    $o .= "</ul>\n";
+    my $forkind = sub {
+	my ($type,$desc,$pfx,$sfx) = @_;
+	$o .= "<h2>$desc</h2><ul>\n";
+	foreach my $name (sort keys %{ $sdef{$type} }) {
+	    my $href = refhref($type,$name);
+	    next unless $href =~ m/\S/;
+	    $o .= "<li><a $href>$pfx$name$sfx</a></li>\n";
+	}
+	$o .= "</ul>\n";
+    };
+    $forkind->('Func','Functions','','()');
+    $forkind->('Struct','Structs','struct ','');
+    $forkind->('Enum','Enums and sets of #defines','','');
+    $forkind->('EnumVal','Enum values and individual #defines','','');
+    $o .= "</ul>\n<h2>Files</h2><ul>\n";
+    foreach my $of (sort { $a->[0] cmp $b->[0] } @outfiles) {
+	$o .= "<li><a href=\"$of->[1]\">$of->[0]</a></li>\n";
+    }
+    $o .= "</ul></body></html>\n";
+    write_file("$outdir/index.html", $o);
+}
 
 foreach $pass (qw(1 2)) {
     find({ wanted => 
@@ -290,3 +347,5 @@ foreach $pass (qw(1 2)) {
 	 },
 	 map { "$basedir/$_" } @indirs);
 }
+
+output_index();
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index f2c9e6f..a5b6ad8 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -55,7 +55,9 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * HYPERCALLS
  */
 
-/* ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*() */
+/* `incontents 100 hcalls List of hypercalls
+ * ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*()
+ */
 
 #define __HYPERVISOR_set_trap_table        0
 #define __HYPERVISOR_mmu_update            1
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:02:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPCR-00015b-Ov; Tue, 29 Nov 2011 15:02:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPCQ-00014U-5C
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:02:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322578898!3553118!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21244 invoked from network); 29 Nov 2011 15:01:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:01:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188404"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:01:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:01:44 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPBo-00040T-0f; Tue, 29 Nov 2011 15:01:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPBn-0002cR-WC;
	Tue, 29 Nov 2011 15:01:43 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 15:01:32 +0000
Message-ID: <1322578893-9998-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/4] docs/html/: Generate an "index.html" for
	hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Generate an "index.html" containing various useful links.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 docs/xen-headers         |   59 ++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/xen.h |    4 ++-
 2 files changed, 62 insertions(+), 1 deletions(-)

diff --git a/docs/xen-headers b/docs/xen-headers
index e893f91..dcf673e 100755
--- a/docs/xen-headers
+++ b/docs/xen-headers
@@ -17,6 +17,10 @@
 
 #  definitions must start in LH column
 #  extra syntax:
+#   `incontents <seq> <shortname> <anchor text html>...
+#                              make a table of contents entry; they
+#                              will be sorted by increasing seq, and
+#                              shortname will be used as the anchor target
 #    /* ` <definition>                          } parse as if <definition>
 #     * ` <definition>                          }  was not commented
 #   enum <name> { // <pattern>* => <func>()     } cross-reference
@@ -60,6 +64,8 @@ my ($basedir,@indirs) = @ARGV;
 # general globals
 our $pass;
 our %sdef; 
+our @incontents;
+our @outfiles;
 # $sdef{$type}{$name} => {
 #     DefLocs => { "$leaf_path:$lineno" => $leaf_opath ,... }
 #     Xrefs => { "$leaf_path,$lineno" => "$xref", ... }
@@ -187,6 +193,19 @@ sub out_xrefs ($) {
     @pending_xrefs = ();
 }
 
+sub incontents ($$$) {
+    my ($text, $seq, $anchor) = @_;
+    $anchor = "incontents_$anchor";
+    if ($pass==2) {
+	push @incontents, { 
+	    Seq => $seq,
+	    Href => "$leaf_opath#$anchor",
+	    Title => $text,
+	};
+    }
+    return "<a name=\"$anchor\"><strong>$text</strong></a>";
+}
+
 sub write_file ($$) {
     my ($opath, $odata) = @_;
     my $out = new IO::File "$opath.new", '>' or die "$opath $!";
@@ -242,6 +261,8 @@ sub process_file ($$) {
 	    }
 	} elsif (s/^( \s* \#define \s+ ) (\w+) ( \s+\S )
                   / $1.defmacro($2).norm($3) /xe) {
+	} elsif (s/( \`incontents \s+ (\d+) \s+ (\w+) \s+ )(\S .* \S)
+                 / norm($1).incontents($4, $2, $3) /xe) {
 	} else {
 	    if (m/^\s*\}/) {
 		$in_enum = undef;
@@ -261,11 +282,47 @@ sub process_file ($$) {
     warning("pending xrefs at end of file") if @pending_xrefs;
 
     if ($pass == 2) {
+	push @outfiles, [ $leaf, $leaf_opath ];
 	$o .= "</pre></body></html>";
 	write_file($outfile, $o);
     }
 }
 
+sub output_index () {
+    my $title = "contents - $xtitle";
+    $o = '';
+    $o .= <<END;
+<html><head><title>$title</title></head>
+<body>
+<h1>$title</h1>
+<h2>Starting points</h2>
+<ul>
+END
+    foreach my $ic (sort { $a->{Seq} <=> $b->{Seq} } @incontents) {
+	$o .= "<li><a href=\"$ic->{Href}\">$ic->{Title}</a></li>\n";
+    }
+    $o .= "</ul>\n";
+    my $forkind = sub {
+	my ($type,$desc,$pfx,$sfx) = @_;
+	$o .= "<h2>$desc</h2><ul>\n";
+	foreach my $name (sort keys %{ $sdef{$type} }) {
+	    my $href = refhref($type,$name);
+	    next unless $href =~ m/\S/;
+	    $o .= "<li><a $href>$pfx$name$sfx</a></li>\n";
+	}
+	$o .= "</ul>\n";
+    };
+    $forkind->('Func','Functions','','()');
+    $forkind->('Struct','Structs','struct ','');
+    $forkind->('Enum','Enums and sets of #defines','','');
+    $forkind->('EnumVal','Enum values and individual #defines','','');
+    $o .= "</ul>\n<h2>Files</h2><ul>\n";
+    foreach my $of (sort { $a->[0] cmp $b->[0] } @outfiles) {
+	$o .= "<li><a href=\"$of->[1]\">$of->[0]</a></li>\n";
+    }
+    $o .= "</ul></body></html>\n";
+    write_file("$outdir/index.html", $o);
+}
 
 foreach $pass (qw(1 2)) {
     find({ wanted => 
@@ -290,3 +347,5 @@ foreach $pass (qw(1 2)) {
 	 },
 	 map { "$basedir/$_" } @indirs);
 }
+
+output_index();
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index f2c9e6f..a5b6ad8 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -55,7 +55,9 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * HYPERCALLS
  */
 
-/* ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*() */
+/* `incontents 100 hcalls List of hypercalls
+ * ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*()
+ */
 
 #define __HYPERVISOR_set_trap_table        0
 #define __HYPERVISOR_mmu_update            1
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:02:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPCQ-00015C-BF; Tue, 29 Nov 2011 15:02:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPCO-00014O-Qx
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:02:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322578898!3553118!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20930 invoked from network); 29 Nov 2011 15:01:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:01:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:01:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:01:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPBm-00040Q-Vw; Tue, 29 Nov 2011 15:01:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPBm-0002cN-Uv;
	Tue, 29 Nov 2011 15:01:42 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 15:01:31 +0000
Message-ID: <1322578893-9998-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add annotations for a couple of the hypercalls:
 HYPERVISOR_set_trap_table
 HYPERVISOR_mmu_update

We do this by
 * annotating the list of #defines for hypercall numbers
 * annotating the list of error values
 * providing a function prototype for the systematically-named functions
The header generator does the rest.

This exercise revealed a couple of infelicities:
 * In the actual source code, do_mmu_update is defined to return an int
   and do_set_trap_table a long.  However both functions return either
   -Efoo (on error) or 0 for success.
 * The error numbers are defined only in the private header file
   xen/include/xen/errno.h and then only with names which will
   typically clash with other projects.  It would be nice to include a
   public version of this header which defines XEN_E*.  But for now
   we run xen-headers on errno.h too.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 docs/Makefile                     |    2 +-
 xen/include/public/arch-x86/xen.h |    6 ++++++
 xen/include/public/xen.h          |   11 +++++++++--
 xen/include/xen/errno.h           |    5 +++++
 4 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index ad315cf..a2bbf2d 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -134,7 +134,7 @@ html/hypercall/stamp:
 	./xen-headers -O $(@D) \
 		-T 'arch-x86_64 - Xen public headers' \
 		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 \
-		../xen include/public
+		../xen include/public include/xen/errno.h
 	touch $@
 
 txt/%.txt: %.txt
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index 79ec633..d663cef 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -82,7 +82,13 @@ typedef unsigned long xen_pfn_t;
 typedef unsigned long xen_ulong_t;
 
 /*
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_set_trap_table(const struct trap_info traps[]);
+ * `
+ */
+/*
  * Send an array of these to HYPERVISOR_set_trap_table().
+ * Terminate the array with a sentinel entry, with traps[].address==0.
  * The privilege level specifies which modes may enter a trap via a software
  * interrupt. On x86/64, since rings 1 and 2 are unavailable, we allocate
  * privilege levels as follows:
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index fde9fa5..f2c9e6f 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -55,6 +55,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * HYPERCALLS
  */
 
+/* ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*() */
+
 #define __HYPERVISOR_set_trap_table        0
 #define __HYPERVISOR_mmu_update            1
 #define __HYPERVISOR_set_gdt               2
@@ -105,6 +107,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define __HYPERVISOR_arch_6               54
 #define __HYPERVISOR_arch_7               55
 
+/* ` } */
+
 /*
  * HYPERCALL COMPATIBILITY.
  */
@@ -163,8 +167,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define NR_VIRQS       24
 
 /*
- * HYPERVISOR_mmu_update(reqs, count, pdone, foreigndom)
- * 
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_mmu_update(const struct mmu_update reqs[],
+ * `                       unsigned count, unsigned *done_out,
+ * `                       unsigned foreigndom)
+ * `
  * @reqs is an array of mmu_update_t structures ((ptr, val) pairs).
  * @count is the length of the above array.
  * @pdone is an output parameter indicating number of completed operations
diff --git a/xen/include/xen/errno.h b/xen/include/xen/errno.h
index 7cf599f..39147be 100644
--- a/xen/include/xen/errno.h
+++ b/xen/include/xen/errno.h
@@ -1,6 +1,9 @@
 #ifndef _I386_ERRNO_H
 #define _I386_ERRNO_H
 
+/* ` enum neg_errnoval {  [ -Efoo for each Efoo in the list below ]  } */
+/* ` enum errnoval { */
+
 #define	EPERM		 1	/* Operation not permitted */
 #define	ENOENT		 2	/* No such file or directory */
 #define	ESRCH		 3	/* No such process */
@@ -129,4 +132,6 @@
 #define	ENOMEDIUM	123	/* No medium found */
 #define	EMEDIUMTYPE	124	/* Wrong medium type */
 
+/* ` } */
+
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:02:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPCQ-00015C-BF; Tue, 29 Nov 2011 15:02:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPCO-00014O-Qx
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:02:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322578898!3553118!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20930 invoked from network); 29 Nov 2011 15:01:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:01:43 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:01:43 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:01:43 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPBm-00040Q-Vw; Tue, 29 Nov 2011 15:01:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPBm-0002cN-Uv;
	Tue, 29 Nov 2011 15:01:42 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 15:01:31 +0000
Message-ID: <1322578893-9998-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add annotations for a couple of the hypercalls:
 HYPERVISOR_set_trap_table
 HYPERVISOR_mmu_update

We do this by
 * annotating the list of #defines for hypercall numbers
 * annotating the list of error values
 * providing a function prototype for the systematically-named functions
The header generator does the rest.

This exercise revealed a couple of infelicities:
 * In the actual source code, do_mmu_update is defined to return an int
   and do_set_trap_table a long.  However both functions return either
   -Efoo (on error) or 0 for success.
 * The error numbers are defined only in the private header file
   xen/include/xen/errno.h and then only with names which will
   typically clash with other projects.  It would be nice to include a
   public version of this header which defines XEN_E*.  But for now
   we run xen-headers on errno.h too.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 docs/Makefile                     |    2 +-
 xen/include/public/arch-x86/xen.h |    6 ++++++
 xen/include/public/xen.h          |   11 +++++++++--
 xen/include/xen/errno.h           |    5 +++++
 4 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index ad315cf..a2bbf2d 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -134,7 +134,7 @@ html/hypercall/stamp:
 	./xen-headers -O $(@D) \
 		-T 'arch-x86_64 - Xen public headers' \
 		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 \
-		../xen include/public
+		../xen include/public include/xen/errno.h
 	touch $@
 
 txt/%.txt: %.txt
diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
index 79ec633..d663cef 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -82,7 +82,13 @@ typedef unsigned long xen_pfn_t;
 typedef unsigned long xen_ulong_t;
 
 /*
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_set_trap_table(const struct trap_info traps[]);
+ * `
+ */
+/*
  * Send an array of these to HYPERVISOR_set_trap_table().
+ * Terminate the array with a sentinel entry, with traps[].address==0.
  * The privilege level specifies which modes may enter a trap via a software
  * interrupt. On x86/64, since rings 1 and 2 are unavailable, we allocate
  * privilege levels as follows:
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index fde9fa5..f2c9e6f 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -55,6 +55,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * HYPERCALLS
  */
 
+/* ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*() */
+
 #define __HYPERVISOR_set_trap_table        0
 #define __HYPERVISOR_mmu_update            1
 #define __HYPERVISOR_set_gdt               2
@@ -105,6 +107,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define __HYPERVISOR_arch_6               54
 #define __HYPERVISOR_arch_7               55
 
+/* ` } */
+
 /*
  * HYPERCALL COMPATIBILITY.
  */
@@ -163,8 +167,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
 #define NR_VIRQS       24
 
 /*
- * HYPERVISOR_mmu_update(reqs, count, pdone, foreigndom)
- * 
+ * ` enum neg_errnoval
+ * ` HYPERVISOR_mmu_update(const struct mmu_update reqs[],
+ * `                       unsigned count, unsigned *done_out,
+ * `                       unsigned foreigndom)
+ * `
  * @reqs is an array of mmu_update_t structures ((ptr, val) pairs).
  * @count is the length of the above array.
  * @pdone is an output parameter indicating number of completed operations
diff --git a/xen/include/xen/errno.h b/xen/include/xen/errno.h
index 7cf599f..39147be 100644
--- a/xen/include/xen/errno.h
+++ b/xen/include/xen/errno.h
@@ -1,6 +1,9 @@
 #ifndef _I386_ERRNO_H
 #define _I386_ERRNO_H
 
+/* ` enum neg_errnoval {  [ -Efoo for each Efoo in the list below ]  } */
+/* ` enum errnoval { */
+
 #define	EPERM		 1	/* Operation not permitted */
 #define	ENOENT		 2	/* No such file or directory */
 #define	ESRCH		 3	/* No such process */
@@ -129,4 +132,6 @@
 #define	ENOMEDIUM	123	/* No medium found */
 #define	EMEDIUMTYPE	124	/* Wrong medium type */
 
+/* ` } */
+
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:02:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPCS-00015o-6F; Tue, 29 Nov 2011 15:02:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPCQ-00014V-JP
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:02:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322578898!3553118!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21288 invoked from network); 29 Nov 2011 15:01:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:01:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188405"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:01:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:01:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPBo-00040W-UQ; Tue, 29 Nov 2011 15:01:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPBo-0002cV-Tg;
	Tue, 29 Nov 2011 15:01:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 15:01:33 +0000
Message-ID: <1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/4] docs/html/: Arrange for automatic build of
	hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

- Use index.html rather than a stamp file.
- Automatically generate dependencies.
- Wire into the docs build system

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 docs/Makefile    |    9 ++++++---
 docs/xen-headers |   14 ++++++++++++++
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index a2bbf2d..413c1a2 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -15,7 +15,8 @@ DOC_MARKDOWN	:= $(wildcard misc/*.markdown)
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
 DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
-		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
+		   html/hypercall/index.html
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN))
 
@@ -129,13 +130,15 @@ html/%.html: %.markdown
 	$(MARKDOWN) $< > $@.tmp ; \
 	$(call move-if-changed,$@.tmp,$@) ; fi
 
-html/hypercall/stamp:
+html/hypercall/index.html: ./xen-headers
+	rm -rf $(@D)
 	@$(INSTALL_DIR) $(@D)
 	./xen-headers -O $(@D) \
 		-T 'arch-x86_64 - Xen public headers' \
 		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 \
 		../xen include/public include/xen/errno.h
-	touch $@
+
+-include html/hypercall/.deps
 
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
diff --git a/docs/xen-headers b/docs/xen-headers
index dcf673e..8226d73 100755
--- a/docs/xen-headers
+++ b/docs/xen-headers
@@ -325,6 +325,12 @@ END
 }
 
 foreach $pass (qw(1 2)) {
+    my $depspath = "$outdir/.deps";
+    my $depsout;
+    if ($pass==2) {
+	$depsout = new IO::File "$depspath.new", 'w' or die $!;
+    }
+
     find({ wanted => 
 	       sub {
 		   return unless m/\.h$/;
@@ -341,11 +347,19 @@ foreach $pass (qw(1 2)) {
 		   $leaf_opath = $leaf;
 		   $leaf_opath =~ s#/#,#g;
 		   $leaf_opath .= ".html";
+		   print $depsout "$outdir/index.html: $File::Find::name\n"
+		       or die $!
+		       if $pass==2;
 		   process_file($File::Find::name, $outdir.'/'.$leaf_opath);
 	   },
 	   no_chdir => 1,
 	 },
 	 map { "$basedir/$_" } @indirs);
+
+    if ($pass==2) {
+	close $depsout or die $!;
+	rename "$depspath.new", "$depspath" or die $!;
+    }
 }
 
 output_index();
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:02:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPCS-00015o-6F; Tue, 29 Nov 2011 15:02:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPCQ-00014V-JP
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:02:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322578898!3553118!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21288 invoked from network); 29 Nov 2011 15:01:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:01:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188405"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:01:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:01:45 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPBo-00040W-UQ; Tue, 29 Nov 2011 15:01:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPBo-0002cV-Tg;
	Tue, 29 Nov 2011 15:01:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 15:01:33 +0000
Message-ID: <1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/4] docs/html/: Arrange for automatic build of
	hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

- Use index.html rather than a stamp file.
- Automatically generate dependencies.
- Wire into the docs build system

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 docs/Makefile    |    9 ++++++---
 docs/xen-headers |   14 ++++++++++++++
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/docs/Makefile b/docs/Makefile
index a2bbf2d..413c1a2 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -15,7 +15,8 @@ DOC_MARKDOWN	:= $(wildcard misc/*.markdown)
 DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
 DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
 DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
-		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN))
+		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
+		   html/hypercall/index.html
 DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN))
 
@@ -129,13 +130,15 @@ html/%.html: %.markdown
 	$(MARKDOWN) $< > $@.tmp ; \
 	$(call move-if-changed,$@.tmp,$@) ; fi
 
-html/hypercall/stamp:
+html/hypercall/index.html: ./xen-headers
+	rm -rf $(@D)
 	@$(INSTALL_DIR) $(@D)
 	./xen-headers -O $(@D) \
 		-T 'arch-x86_64 - Xen public headers' \
 		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 \
 		../xen include/public include/xen/errno.h
-	touch $@
+
+-include html/hypercall/.deps
 
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
diff --git a/docs/xen-headers b/docs/xen-headers
index dcf673e..8226d73 100755
--- a/docs/xen-headers
+++ b/docs/xen-headers
@@ -325,6 +325,12 @@ END
 }
 
 foreach $pass (qw(1 2)) {
+    my $depspath = "$outdir/.deps";
+    my $depsout;
+    if ($pass==2) {
+	$depsout = new IO::File "$depspath.new", 'w' or die $!;
+    }
+
     find({ wanted => 
 	       sub {
 		   return unless m/\.h$/;
@@ -341,11 +347,19 @@ foreach $pass (qw(1 2)) {
 		   $leaf_opath = $leaf;
 		   $leaf_opath =~ s#/#,#g;
 		   $leaf_opath .= ".html";
+		   print $depsout "$outdir/index.html: $File::Find::name\n"
+		       or die $!
+		       if $pass==2;
 		   process_file($File::Find::name, $outdir.'/'.$leaf_opath);
 	   },
 	   no_chdir => 1,
 	 },
 	 map { "$basedir/$_" } @indirs);
+
+    if ($pass==2) {
+	close $depsout or die $!;
+	rename "$depspath.new", "$depspath" or die $!;
+    }
 }
 
 output_index();
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:02:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPCO-00014k-Mk; Tue, 29 Nov 2011 15:02:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPCN-00014N-4o
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:02:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322578898!3553118!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20777 invoked from network); 29 Nov 2011 15:01:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:01:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:01:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:01:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPBl-00040N-8o; Tue, 29 Nov 2011 15:01:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPBl-0002cJ-7w;
	Tue, 29 Nov 2011 15:01:41 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 15:01:30 +0000
Message-ID: <1322578893-9998-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/4] docs/html/: Initial cut of header
	documentation massager
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

"xen-headers" generates HTML from header files.  So far this generates
just some type cross-references, if you say
   make -C docs html/hypercall/stamp

An index page, proper wiring into the build system, and a few more
annotations in the headers, and will be forthcoming.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 docs/Makefile    |    8 ++
 docs/xen-headers |  292 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 300 insertions(+), 0 deletions(-)
 create mode 100755 docs/xen-headers

diff --git a/docs/Makefile b/docs/Makefile
index 2054541..ad315cf 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -129,6 +129,14 @@ html/%.html: %.markdown
 	$(MARKDOWN) $< > $@.tmp ; \
 	$(call move-if-changed,$@.tmp,$@) ; fi
 
+html/hypercall/stamp:
+	@$(INSTALL_DIR) $(@D)
+	./xen-headers -O $(@D) \
+		-T 'arch-x86_64 - Xen public headers' \
+		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 \
+		../xen include/public
+	touch $@
+
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
diff --git a/docs/xen-headers b/docs/xen-headers
new file mode 100755
index 0000000..e893f91
--- /dev/null
+++ b/docs/xen-headers
@@ -0,0 +1,292 @@
+#!/usr/bin/perl -w
+# usage: xen-headers OPTIONS... BASE-DIR INPUT-SUB-DIR...
+#  INPUT-SUB-DIR must be a relative path, and is interpreted
+#  relative to BASE-DIR.  Only files whose names end .h are processed
+# options:
+#   -O HTML-DIR             write html to this directory (mandatory)
+#   -T EXTRA-TITLE-HTML     tail of title string (used in <title>)
+#   -X GLOB | -I GLOB       include/exclude files matching;
+#                            glob patterns matched against /INPUT-SUB-FILE
+#                            first match wins; if no match, files included
+#   -D                      increase debug
+
+# Functionality:
+#  enum values --> selected function or struct
+#  type & function names, macro definitions --> definition
+#  function or struct selected by enum ++> ref to enum value
+
+#  definitions must start in LH column
+#  extra syntax:
+#    /* ` <definition>                          } parse as if <definition>
+#     * ` <definition>                          }  was not commented
+#   enum <name> { // <pattern>* => <func>()     } cross-reference
+#   enum <name> { // <pattern>* => struct <s>   }  enum values
+#   
+
+# 1st pass: find where things are defined and what references are wanted
+# 2rd pass: write out output
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+use File::Find;
+use IO::File;
+
+Getopt::Long::Configure('bundling');
+
+our $outdir;
+our $debug=0;
+our $xtitle='';
+our @fglobs;
+
+sub includeexclude {
+    my ($yn, $optobj, $value) = @_;
+    push @fglobs, [ $value, $yn ];
+}
+
+GetOptions("O|output-dir=s" => \$outdir,
+           "D+" => \$debug,
+           "T=s" => \$xtitle,
+	   "I=s" => sub { includeexclude(1, @_); },
+	   "X=s" => sub { includeexclude(0, @_); })
+    or die;
+
+die unless defined $outdir;
+@ARGV>=2 or die;
+
+my ($basedir,@indirs) = @ARGV;
+
+# general globals
+our $pass;
+our %sdef; 
+# $sdef{$type}{$name} => {
+#     DefLocs => { "$leaf_path:$lineno" => $leaf_opath ,... }
+#     Xrefs => { "$leaf_path,$lineno" => "$xref", ... }
+#     Used => 1
+# }
+# $type might be  Func Struct Union Enum EnumVal
+
+# provided by the find() function
+our $leaf;
+our $leaf_opath;
+
+# reset at the start of each file
+our $o;
+our $in_enum;
+our @pending_xrefs;
+
+sub compile_fglobs () {
+    local ($_);
+    my $f = "sub file_wanted (\$) {\n    local (\$_) = \"/\$leaf\";\n";
+    foreach my $fglob (@fglobs) {
+	$_ = $fglob->[0];
+	$_ = "**$_**" unless m/[?*]/;
+	s/\W/\\$&/g;
+	s,\\\*\\\*,.*,g;
+	s,\\\*,[^/]*,g;
+	s,\\\?,[^/],g;
+	$f .= "    return $fglob->[1] if m,$_,o;\n";
+    }
+    $f .= "    return 1;\n}\n1;\n";
+    debug(3, $f);
+    eval $f or die "$@ ";
+}
+
+compile_fglobs();
+
+
+sub warning {
+    print STDERR "$leaf:$.: @_\n";
+}
+
+sub debug {
+    my $msglevel = scalar shift @_;
+    return unless $debug >= $msglevel;
+    print STDERR "DEBUG $pass $msglevel @_\n" or die $!;
+}
+
+sub in_enum ($$$) { $in_enum = [ @_ ]; } # [ $enumvalpfx, RefType, $refnamepfx ]
+
+sub aelem ($$$) {
+    my ($ntext,$ytext,$hparams) = @_;
+    return $ntext unless $hparams =~ m/\S/;
+    return "<a $hparams>$ytext</a>";
+}
+
+sub defn ($$$;$) {
+    my ($text,$type,$name,$hparams) = @_;
+    $hparams='' if !defined $hparams;
+    debug(2,"DEFN $. $type $name $hparams");
+    $sdef{$type}{$name}{DefLocs}{"$leaf:$."} = $leaf_opath;
+    my $xrefs = $sdef{$type}{$name}{Xrefs};
+    push @pending_xrefs, values %$xrefs if $xrefs;
+    $hparams .= " name=\"${type}_$name\"" if $sdef{$type}{$name}{Used};
+    return aelem($text, "<strong>$text</strong>", $hparams);
+}
+
+sub norm ($) {
+    local ($_) = @_;
+    my $no = '';
+    while (length) {
+	if (s/^(?:\s|^\W)+//) {
+	    $no .= $&;
+	} elsif (s/^(struct|union|enum)\s+(\w+)\b//) {
+	    $no .= ahref($&, (ucfirst $1), $2);
+	} elsif (s/^\w+\b//) {
+	    $no .= ahref($&, 'Func', $&);
+	} else {
+	    die "$_ ?";
+	}
+    }
+    return $no;
+}
+
+sub refhref ($$) {
+    my ($type,$name) = @_;
+    $sdef{$type}{$name}{Used} = 1;
+    my $locs = $sdef{$type}{$name}{DefLocs};
+    return '' unless $locs;
+    if ((scalar keys %$locs) != 1 && !$sdef{$type}{$name}{MultiWarned}) {
+	warning("multiple definitions of $type $name: $_")
+	    foreach keys %$locs;
+	$sdef{$type}{$name}{MultiWarned}=1;
+    }
+    my ($loc) = values %$locs;
+    return "href=\"$loc#${type}_$name\"";
+}
+
+sub ahref ($$$) {
+    my ($text,$type,$name) = @_;
+    return aelem($text,$text, refhref($type,$name));
+}
+
+sub defmacro ($) {
+    my ($valname) = @_;
+    if (!$in_enum) {
+	return $valname;
+    } elsif (substr($valname, 0, (length $in_enum->[0])) ne $in_enum->[0]) {
+	warning("in enum expecting $in_enum->[0]* got $valname");
+	return $valname;
+    } else {
+	my $reftype = $in_enum->[1];
+	my $refname = $in_enum->[2].substr($valname, (length $in_enum->[0]));
+	$sdef{$reftype}{$refname}{Xrefs}{$leaf,$.} =
+	    "[see <a href=\"$leaf_opath#EnumVal_$valname\">$valname</a>]";
+	$sdef{EnumVal}{$valname}{Used} = 1;
+	return defn($valname,'EnumVal',$valname, refhref($reftype,$refname));
+    }
+}
+
+sub out_xrefs ($) {
+    my ($linemapfunc) = @_;
+    foreach my $xref (@pending_xrefs) {
+	$o .= $linemapfunc->($xref);
+	$o .= "\n";
+    }
+    @pending_xrefs = ();
+}
+
+sub write_file ($$) {
+    my ($opath, $odata) = @_;
+    my $out = new IO::File "$opath.new", '>' or die "$opath $!";
+    print $out $odata or die $!;
+    rename "$opath.new", "$opath" or die "$opath $!";
+}
+
+sub process_file ($$) {
+    my ($infile, $outfile) = @_;
+    debug(1,"$pass $infile => $outfile");
+    my $in = new IO::File "$infile", '<' or die "$infile $!";
+
+    $o = '';
+    $in_enum = undef;
+    @pending_xrefs = ();
+
+    $o .= "<html><head><title>$leaf - $xtitle</title></head><body><pre>\n";
+    
+    while (<$in>) {
+	s/\&/\&amp;/g;
+	s/\</\&lt;/g;
+	s/\>/\&gt;/g;
+
+	if (m/^(.*\`)[ \t]*$/) {
+	    my $lhs = $1;
+	    out_xrefs(sub { "$1 $_[0]"; });
+	} elsif (m/^\s*$/) {
+	    out_xrefs(sub { sprintf "/* %70s */", $_[0]; });
+	}
+
+	# In case of comments, strip " /* ` " and " * ` ";
+	my $lstripped = s,^ \s* /? \* \s* \` \  ,,x ? $&: '';
+
+	# Strip trailing whitespace and perhaps trailing "*/" or "*"
+	s,(?: \s* \* /? )? \s* $,,x or die;
+	my $rstripped = $&;
+
+	# Now the actual functionality:
+
+	debug(3,"$. $_");
+
+	if (!m/^(?: __attribute__ | __pragma__ )\b/x &&
+	    s/^( (?: \w+\  )? ) (\w+[a-z]\w+) ( \( .*)$
+             / $1.defn($2,'Func',$2).norm($3) /xe) {
+	} elsif (s/^((struct|union|enum) \  (\w+)) ( \s+ \{ .* )$
+                  / defn($1,(ucfirst $2),$3).norm($4) /xe) {
+	    if ($2 eq 'enum') {
+		if (m,/[/*] (\w+)\* \=\&gt\; (\w+)\*\(\),) { 
+		    in_enum($1,'Func',$2)
+		} elsif (m,/[/*] (\w+)\* \=\&gt\; (struct) (\w+)\*,) { 
+		    in_enum($1,(ucfirst $2),$3);
+	        }
+	    }
+	} elsif (s/^( \s* \#define \s+ ) (\w+) ( \s+\S )
+                  / $1.defmacro($2).norm($3) /xe) {
+	} else {
+	    if (m/^\s*\}/) {
+		$in_enum = undef;
+	    }
+	    $_ = norm($_);
+	}
+
+	# Write the line out
+
+	if ($pass == 2) {
+	    $o .= $lstripped;
+	    $o .= $_;
+	    $o .= $rstripped;
+	}
+    }
+
+    warning("pending xrefs at end of file") if @pending_xrefs;
+
+    if ($pass == 2) {
+	$o .= "</pre></body></html>";
+	write_file($outfile, $o);
+    }
+}
+
+
+foreach $pass (qw(1 2)) {
+    find({ wanted => 
+	       sub {
+		   return unless m/\.h$/;
+		   lstat $File::Find::name or die "$File::Find::name $!";
+		   -f _ or die "$File::Find::name";
+		   substr($File::Find::name, 0, 1+length $basedir) 
+		       eq "$basedir/"
+		       or die "$File::Find::name $basedir";
+		   $leaf = substr($File::Find::name, 1+length $basedir);
+		   if (!file_wanted()) {
+		       debug(1,"$pass $File::Find::name excluded");
+		       return;
+		   }
+		   $leaf_opath = $leaf;
+		   $leaf_opath =~ s#/#,#g;
+		   $leaf_opath .= ".html";
+		   process_file($File::Find::name, $outdir.'/'.$leaf_opath);
+	   },
+	   no_chdir => 1,
+	 },
+	 map { "$basedir/$_" } @indirs);
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:02:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPCO-00014k-Mk; Tue, 29 Nov 2011 15:02:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPCN-00014N-4o
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:02:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1322578898!3553118!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20777 invoked from network); 29 Nov 2011 15:01:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:01:41 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:01:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:01:41 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPBl-00040N-8o; Tue, 29 Nov 2011 15:01:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPBl-0002cJ-7w;
	Tue, 29 Nov 2011 15:01:41 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 15:01:30 +0000
Message-ID: <1322578893-9998-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/4] docs/html/: Initial cut of header
	documentation massager
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

"xen-headers" generates HTML from header files.  So far this generates
just some type cross-references, if you say
   make -C docs html/hypercall/stamp

An index page, proper wiring into the build system, and a few more
annotations in the headers, and will be forthcoming.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 docs/Makefile    |    8 ++
 docs/xen-headers |  292 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 300 insertions(+), 0 deletions(-)
 create mode 100755 docs/xen-headers

diff --git a/docs/Makefile b/docs/Makefile
index 2054541..ad315cf 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -129,6 +129,14 @@ html/%.html: %.markdown
 	$(MARKDOWN) $< > $@.tmp ; \
 	$(call move-if-changed,$@.tmp,$@) ; fi
 
+html/hypercall/stamp:
+	@$(INSTALL_DIR) $(@D)
+	./xen-headers -O $(@D) \
+		-T 'arch-x86_64 - Xen public headers' \
+		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 \
+		../xen include/public
+	touch $@
+
 txt/%.txt: %.txt
 	$(INSTALL_DIR) $(@D)
 	cp $< $@.tmp
diff --git a/docs/xen-headers b/docs/xen-headers
new file mode 100755
index 0000000..e893f91
--- /dev/null
+++ b/docs/xen-headers
@@ -0,0 +1,292 @@
+#!/usr/bin/perl -w
+# usage: xen-headers OPTIONS... BASE-DIR INPUT-SUB-DIR...
+#  INPUT-SUB-DIR must be a relative path, and is interpreted
+#  relative to BASE-DIR.  Only files whose names end .h are processed
+# options:
+#   -O HTML-DIR             write html to this directory (mandatory)
+#   -T EXTRA-TITLE-HTML     tail of title string (used in <title>)
+#   -X GLOB | -I GLOB       include/exclude files matching;
+#                            glob patterns matched against /INPUT-SUB-FILE
+#                            first match wins; if no match, files included
+#   -D                      increase debug
+
+# Functionality:
+#  enum values --> selected function or struct
+#  type & function names, macro definitions --> definition
+#  function or struct selected by enum ++> ref to enum value
+
+#  definitions must start in LH column
+#  extra syntax:
+#    /* ` <definition>                          } parse as if <definition>
+#     * ` <definition>                          }  was not commented
+#   enum <name> { // <pattern>* => <func>()     } cross-reference
+#   enum <name> { // <pattern>* => struct <s>   }  enum values
+#   
+
+# 1st pass: find where things are defined and what references are wanted
+# 2rd pass: write out output
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+use File::Find;
+use IO::File;
+
+Getopt::Long::Configure('bundling');
+
+our $outdir;
+our $debug=0;
+our $xtitle='';
+our @fglobs;
+
+sub includeexclude {
+    my ($yn, $optobj, $value) = @_;
+    push @fglobs, [ $value, $yn ];
+}
+
+GetOptions("O|output-dir=s" => \$outdir,
+           "D+" => \$debug,
+           "T=s" => \$xtitle,
+	   "I=s" => sub { includeexclude(1, @_); },
+	   "X=s" => sub { includeexclude(0, @_); })
+    or die;
+
+die unless defined $outdir;
+@ARGV>=2 or die;
+
+my ($basedir,@indirs) = @ARGV;
+
+# general globals
+our $pass;
+our %sdef; 
+# $sdef{$type}{$name} => {
+#     DefLocs => { "$leaf_path:$lineno" => $leaf_opath ,... }
+#     Xrefs => { "$leaf_path,$lineno" => "$xref", ... }
+#     Used => 1
+# }
+# $type might be  Func Struct Union Enum EnumVal
+
+# provided by the find() function
+our $leaf;
+our $leaf_opath;
+
+# reset at the start of each file
+our $o;
+our $in_enum;
+our @pending_xrefs;
+
+sub compile_fglobs () {
+    local ($_);
+    my $f = "sub file_wanted (\$) {\n    local (\$_) = \"/\$leaf\";\n";
+    foreach my $fglob (@fglobs) {
+	$_ = $fglob->[0];
+	$_ = "**$_**" unless m/[?*]/;
+	s/\W/\\$&/g;
+	s,\\\*\\\*,.*,g;
+	s,\\\*,[^/]*,g;
+	s,\\\?,[^/],g;
+	$f .= "    return $fglob->[1] if m,$_,o;\n";
+    }
+    $f .= "    return 1;\n}\n1;\n";
+    debug(3, $f);
+    eval $f or die "$@ ";
+}
+
+compile_fglobs();
+
+
+sub warning {
+    print STDERR "$leaf:$.: @_\n";
+}
+
+sub debug {
+    my $msglevel = scalar shift @_;
+    return unless $debug >= $msglevel;
+    print STDERR "DEBUG $pass $msglevel @_\n" or die $!;
+}
+
+sub in_enum ($$$) { $in_enum = [ @_ ]; } # [ $enumvalpfx, RefType, $refnamepfx ]
+
+sub aelem ($$$) {
+    my ($ntext,$ytext,$hparams) = @_;
+    return $ntext unless $hparams =~ m/\S/;
+    return "<a $hparams>$ytext</a>";
+}
+
+sub defn ($$$;$) {
+    my ($text,$type,$name,$hparams) = @_;
+    $hparams='' if !defined $hparams;
+    debug(2,"DEFN $. $type $name $hparams");
+    $sdef{$type}{$name}{DefLocs}{"$leaf:$."} = $leaf_opath;
+    my $xrefs = $sdef{$type}{$name}{Xrefs};
+    push @pending_xrefs, values %$xrefs if $xrefs;
+    $hparams .= " name=\"${type}_$name\"" if $sdef{$type}{$name}{Used};
+    return aelem($text, "<strong>$text</strong>", $hparams);
+}
+
+sub norm ($) {
+    local ($_) = @_;
+    my $no = '';
+    while (length) {
+	if (s/^(?:\s|^\W)+//) {
+	    $no .= $&;
+	} elsif (s/^(struct|union|enum)\s+(\w+)\b//) {
+	    $no .= ahref($&, (ucfirst $1), $2);
+	} elsif (s/^\w+\b//) {
+	    $no .= ahref($&, 'Func', $&);
+	} else {
+	    die "$_ ?";
+	}
+    }
+    return $no;
+}
+
+sub refhref ($$) {
+    my ($type,$name) = @_;
+    $sdef{$type}{$name}{Used} = 1;
+    my $locs = $sdef{$type}{$name}{DefLocs};
+    return '' unless $locs;
+    if ((scalar keys %$locs) != 1 && !$sdef{$type}{$name}{MultiWarned}) {
+	warning("multiple definitions of $type $name: $_")
+	    foreach keys %$locs;
+	$sdef{$type}{$name}{MultiWarned}=1;
+    }
+    my ($loc) = values %$locs;
+    return "href=\"$loc#${type}_$name\"";
+}
+
+sub ahref ($$$) {
+    my ($text,$type,$name) = @_;
+    return aelem($text,$text, refhref($type,$name));
+}
+
+sub defmacro ($) {
+    my ($valname) = @_;
+    if (!$in_enum) {
+	return $valname;
+    } elsif (substr($valname, 0, (length $in_enum->[0])) ne $in_enum->[0]) {
+	warning("in enum expecting $in_enum->[0]* got $valname");
+	return $valname;
+    } else {
+	my $reftype = $in_enum->[1];
+	my $refname = $in_enum->[2].substr($valname, (length $in_enum->[0]));
+	$sdef{$reftype}{$refname}{Xrefs}{$leaf,$.} =
+	    "[see <a href=\"$leaf_opath#EnumVal_$valname\">$valname</a>]";
+	$sdef{EnumVal}{$valname}{Used} = 1;
+	return defn($valname,'EnumVal',$valname, refhref($reftype,$refname));
+    }
+}
+
+sub out_xrefs ($) {
+    my ($linemapfunc) = @_;
+    foreach my $xref (@pending_xrefs) {
+	$o .= $linemapfunc->($xref);
+	$o .= "\n";
+    }
+    @pending_xrefs = ();
+}
+
+sub write_file ($$) {
+    my ($opath, $odata) = @_;
+    my $out = new IO::File "$opath.new", '>' or die "$opath $!";
+    print $out $odata or die $!;
+    rename "$opath.new", "$opath" or die "$opath $!";
+}
+
+sub process_file ($$) {
+    my ($infile, $outfile) = @_;
+    debug(1,"$pass $infile => $outfile");
+    my $in = new IO::File "$infile", '<' or die "$infile $!";
+
+    $o = '';
+    $in_enum = undef;
+    @pending_xrefs = ();
+
+    $o .= "<html><head><title>$leaf - $xtitle</title></head><body><pre>\n";
+    
+    while (<$in>) {
+	s/\&/\&amp;/g;
+	s/\</\&lt;/g;
+	s/\>/\&gt;/g;
+
+	if (m/^(.*\`)[ \t]*$/) {
+	    my $lhs = $1;
+	    out_xrefs(sub { "$1 $_[0]"; });
+	} elsif (m/^\s*$/) {
+	    out_xrefs(sub { sprintf "/* %70s */", $_[0]; });
+	}
+
+	# In case of comments, strip " /* ` " and " * ` ";
+	my $lstripped = s,^ \s* /? \* \s* \` \  ,,x ? $&: '';
+
+	# Strip trailing whitespace and perhaps trailing "*/" or "*"
+	s,(?: \s* \* /? )? \s* $,,x or die;
+	my $rstripped = $&;
+
+	# Now the actual functionality:
+
+	debug(3,"$. $_");
+
+	if (!m/^(?: __attribute__ | __pragma__ )\b/x &&
+	    s/^( (?: \w+\  )? ) (\w+[a-z]\w+) ( \( .*)$
+             / $1.defn($2,'Func',$2).norm($3) /xe) {
+	} elsif (s/^((struct|union|enum) \  (\w+)) ( \s+ \{ .* )$
+                  / defn($1,(ucfirst $2),$3).norm($4) /xe) {
+	    if ($2 eq 'enum') {
+		if (m,/[/*] (\w+)\* \=\&gt\; (\w+)\*\(\),) { 
+		    in_enum($1,'Func',$2)
+		} elsif (m,/[/*] (\w+)\* \=\&gt\; (struct) (\w+)\*,) { 
+		    in_enum($1,(ucfirst $2),$3);
+	        }
+	    }
+	} elsif (s/^( \s* \#define \s+ ) (\w+) ( \s+\S )
+                  / $1.defmacro($2).norm($3) /xe) {
+	} else {
+	    if (m/^\s*\}/) {
+		$in_enum = undef;
+	    }
+	    $_ = norm($_);
+	}
+
+	# Write the line out
+
+	if ($pass == 2) {
+	    $o .= $lstripped;
+	    $o .= $_;
+	    $o .= $rstripped;
+	}
+    }
+
+    warning("pending xrefs at end of file") if @pending_xrefs;
+
+    if ($pass == 2) {
+	$o .= "</pre></body></html>";
+	write_file($outfile, $o);
+    }
+}
+
+
+foreach $pass (qw(1 2)) {
+    find({ wanted => 
+	       sub {
+		   return unless m/\.h$/;
+		   lstat $File::Find::name or die "$File::Find::name $!";
+		   -f _ or die "$File::Find::name";
+		   substr($File::Find::name, 0, 1+length $basedir) 
+		       eq "$basedir/"
+		       or die "$File::Find::name $basedir";
+		   $leaf = substr($File::Find::name, 1+length $basedir);
+		   if (!file_wanted()) {
+		       debug(1,"$pass $File::Find::name excluded");
+		       return;
+		   }
+		   $leaf_opath = $leaf;
+		   $leaf_opath =~ s#/#,#g;
+		   $leaf_opath .= ".html";
+		   process_file($File::Find::name, $outdir.'/'.$leaf_opath);
+	   },
+	   no_chdir => 1,
+	 },
+	 map { "$basedir/$_" } @indirs);
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:09:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:09:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPJD-0001xA-2V; Tue, 29 Nov 2011 15:09:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RVPJA-0001wD-Pz; Tue, 29 Nov 2011 15:09:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322579298!42886686!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13616 invoked from network); 29 Nov 2011 15:08:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:08:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:08:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:08:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lars Kurth <lars.kurth@xen.org>
Date: Tue, 29 Nov 2011 15:08:44 +0000
In-Reply-To: <4ECF8648.9020108@xen.org>
References: <4ECF8648.9020108@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322579324.31810.8.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Xen Document Day: November 29th
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Reminder: This is happening now!

Please join us on #xendocday on the Freenode IRC network.

Ian.

On Fri, 2011-11-25 at 12:12 +0000, Lars Kurth wrote:
> Hi everybody,
> 
> after the last Xen Document Day, many people asked me when we would do
> another document day. After a discussion on the mailing list, we
> settled on next Tuesday (November 29). This will be an all-day on-line
> IRC event with the aim to 
>       * Improve user documentation
>       * Improve developer documentation, including the creation of man
>         pages, etc.
> 
> There is no hard start and end to the event, but volunteers in the UK
> will be on-line on Nov 29th from around 9:00 UTC+1 until around 18:00
> UTC+1, and then volunteers from the US will take over. The event will
> be take place on freenode channel #xendocday
> 
> An intial work item lists and what we agreed on can be found on the
> Documentation Day Etherpad. Other work that needs doing is:
> 
>       * Improve user and wiki documentation 
>               * Migrate remaining wiki pages
>               * Pages that need reviewing/fixing
>               * Pages that need formatting
>               * Missing pages (many may just need to be migrated),
>                 some may be obsolete
>       * Improve developer documentation, including the creation of man
>         pages, etc.
> 
> But anyway, a long list of stuff that is needed can be found on the
> Documentation Day Etherpad. I am sure, you will find something that
> suits you. Instructions on how to use the new wiki, can be found here
> and on the front-page.
> 
> The Protocol
> 
>       * Join us on IRC: freenode channel #xendocday
>       * Tell people what you intend to work on (to avoid doing
>         something somebody else is already working on)
>       * Fix some documentation
>       * Help others
>       * And above all: have fun!
> 
> I am looking forward to the day and hopefully documentation days will
> become a regular Xen event. See you on IRC!
> 
> 
> Regards
> Lars
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:09:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:09:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPJD-0001xA-2V; Tue, 29 Nov 2011 15:09:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RVPJA-0001wD-Pz; Tue, 29 Nov 2011 15:09:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1322579298!42886686!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13616 invoked from network); 29 Nov 2011 15:08:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:08:19 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:08:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:08:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lars Kurth <lars.kurth@xen.org>
Date: Tue, 29 Nov 2011 15:08:44 +0000
In-Reply-To: <4ECF8648.9020108@xen.org>
References: <4ECF8648.9020108@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322579324.31810.8.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Xen Document Day: November 29th
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Reminder: This is happening now!

Please join us on #xendocday on the Freenode IRC network.

Ian.

On Fri, 2011-11-25 at 12:12 +0000, Lars Kurth wrote:
> Hi everybody,
> 
> after the last Xen Document Day, many people asked me when we would do
> another document day. After a discussion on the mailing list, we
> settled on next Tuesday (November 29). This will be an all-day on-line
> IRC event with the aim to 
>       * Improve user documentation
>       * Improve developer documentation, including the creation of man
>         pages, etc.
> 
> There is no hard start and end to the event, but volunteers in the UK
> will be on-line on Nov 29th from around 9:00 UTC+1 until around 18:00
> UTC+1, and then volunteers from the US will take over. The event will
> be take place on freenode channel #xendocday
> 
> An intial work item lists and what we agreed on can be found on the
> Documentation Day Etherpad. Other work that needs doing is:
> 
>       * Improve user and wiki documentation 
>               * Migrate remaining wiki pages
>               * Pages that need reviewing/fixing
>               * Pages that need formatting
>               * Missing pages (many may just need to be migrated),
>                 some may be obsolete
>       * Improve developer documentation, including the creation of man
>         pages, etc.
> 
> But anyway, a long list of stuff that is needed can be found on the
> Documentation Day Etherpad. I am sure, you will find something that
> suits you. Instructions on how to use the new wiki, can be found here
> and on the front-page.
> 
> The Protocol
> 
>       * Join us on IRC: freenode channel #xendocday
>       * Tell people what you intend to work on (to avoid doing
>         something somebody else is already working on)
>       * Fix some documentation
>       * Help others
>       * And above all: have fun!
> 
> I am looking forward to the day and hopefully documentation days will
> become a regular Xen event. See you on IRC!
> 
> 
> Regards
> Lars
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:15:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPOo-0002sH-Cj; Tue, 29 Nov 2011 15:15:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RVPOn-0002rm-GI
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:15:09 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322579669!5460118!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18092 invoked from network); 29 Nov 2011 15:14:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:14:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172194518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:14:00 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 29 Nov 2011
	10:14:00 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 10:14:01 -0500
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
	package called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJw
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724D625B9C@FTLPMAILBOX02.citrite.net>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<ac68bd6d4853fdde5a24.1322563999@cosworth.uk.xensource.com>
In-Reply-To: <ac68bd6d4853fdde5a24.1322563999@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Paul Durrant
> Sent: Tuesday, November 29, 2011 5:53 AM
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> package called ADDR, evaluating to two
> 
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1322563733 0 # Node
> ID ac68bd6d4853fdde5a24d78a7d0f1cee69f5416e
> # Parent  a9c67c2daf4b0181ef2581471ea920eecb495616
> Add an ACPI device exposing a package called ADDR, evaluating to two
> integers, and with _CID and _DDN set to "VM_Gen_Counter".
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r a9c67c2daf4b -r ac68bd6d4853
> tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 11:57:23 2011
> +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:53 2011
> +0000
> @@ -47,6 +47,7 @@ struct acpi_info {
>      uint32_t pci_min, pci_len;  /* 4, 8 - PCI I/O hole boundaries */
>      uint32_t madt_csum_addr;    /* 12   - Address of MADT checksum */
>      uint32_t madt_lapic0_addr;  /* 16   - Address of first MADT LAPIC
> struct */
> +    uint32_t vm_gid_addr;       /* 20   - Address of VM generation id
> buffer */
>  };
> 
>  /* Number of processor objects in the chosen DSDT. */ diff -r
> a9c67c2daf4b -r ac68bd6d4853 tools/firmware/hvmloader/acpi/dsdt.asl
> --- a/tools/firmware/hvmloader/acpi/dsdt.asl	Mon Nov 28 11:57:23 2011
> +0000
> +++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Tue Nov 29 10:48:53 2011
> +0000
> @@ -55,7 +55,8 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>             PMIN, 32,
>             PLEN, 32,
>             MSUA, 32, /* MADT checksum address */
> -           MAPA, 32  /* MADT LAPIC0 address */
> +           MAPA, 32, /* MADT LAPIC0 address */
> +           VGIA, 32  /* VM generation id address */
>         }
> 
>          /* Fix HCT test for 0x400 pci memory:
> @@ -396,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>                          IRQNoFlags () {7}
>                      })
>                  }
> +
> +                Device(VGID) {
> +                    Name(_HID, "ACPI0001")
> +                    Name(_UID, 0x00)
> +                    Name(_CID, "VM_Gen_Counter")
> +                    Name(_DDN, "VM_Gen_Counter")
> +                    Method(_STA, 0, NotSerialized)
> +                    {
> +                        If(LEqual(\_SB.VGIA, 0x00000000)) {
> +                            Return(0x00)
> +                        } Else {
> +                            Return(0x0F)
> +                        }
> +                    }
> +                    Name(PKG, Package ()
> +                    {
> +                        0x00000000,
> +                        0x00000000
> +                    })
> +                    Method(ADDR, 0, NotSerialized)
> +                    {
> +                        Store(\_SB.VGIA, Index(PKG, 0))
> +                        Return(PKG)
> +                    }
> +                }
>              }
>          }
>      }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Paul, perhaps a different _HID might be better. Per the 3.0 spec, ACPI0001 is for SMBus host controller device; this might lead to some confusion for an OSPM. Maybe one of the generic PNP device IDs or perhaps we need a manufacturer ID for Xen?

Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:15:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPOo-0002sH-Cj; Tue, 29 Nov 2011 15:15:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RVPOn-0002rm-GI
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:15:09 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322579669!5460118!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjYxMjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18092 invoked from network); 29 Nov 2011 15:14:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:14:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="172194518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 10:14:00 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 29 Nov 2011
	10:14:00 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 10:14:01 -0500
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
	package called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJw
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724D625B9C@FTLPMAILBOX02.citrite.net>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<ac68bd6d4853fdde5a24.1322563999@cosworth.uk.xensource.com>
In-Reply-To: <ac68bd6d4853fdde5a24.1322563999@cosworth.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Paul Durrant
> Sent: Tuesday, November 29, 2011 5:53 AM
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> package called ADDR, evaluating to two
> 
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com> # Date 1322563733 0 # Node
> ID ac68bd6d4853fdde5a24d78a7d0f1cee69f5416e
> # Parent  a9c67c2daf4b0181ef2581471ea920eecb495616
> Add an ACPI device exposing a package called ADDR, evaluating to two
> integers, and with _CID and _DDN set to "VM_Gen_Counter".
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r a9c67c2daf4b -r ac68bd6d4853
> tools/firmware/hvmloader/acpi/build.c
> --- a/tools/firmware/hvmloader/acpi/build.c	Mon Nov 28 11:57:23 2011
> +0000
> +++ b/tools/firmware/hvmloader/acpi/build.c	Tue Nov 29 10:48:53 2011
> +0000
> @@ -47,6 +47,7 @@ struct acpi_info {
>      uint32_t pci_min, pci_len;  /* 4, 8 - PCI I/O hole boundaries */
>      uint32_t madt_csum_addr;    /* 12   - Address of MADT checksum */
>      uint32_t madt_lapic0_addr;  /* 16   - Address of first MADT LAPIC
> struct */
> +    uint32_t vm_gid_addr;       /* 20   - Address of VM generation id
> buffer */
>  };
> 
>  /* Number of processor objects in the chosen DSDT. */ diff -r
> a9c67c2daf4b -r ac68bd6d4853 tools/firmware/hvmloader/acpi/dsdt.asl
> --- a/tools/firmware/hvmloader/acpi/dsdt.asl	Mon Nov 28 11:57:23 2011
> +0000
> +++ b/tools/firmware/hvmloader/acpi/dsdt.asl	Tue Nov 29 10:48:53 2011
> +0000
> @@ -55,7 +55,8 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>             PMIN, 32,
>             PLEN, 32,
>             MSUA, 32, /* MADT checksum address */
> -           MAPA, 32  /* MADT LAPIC0 address */
> +           MAPA, 32, /* MADT LAPIC0 address */
> +           VGIA, 32  /* VM generation id address */
>         }
> 
>          /* Fix HCT test for 0x400 pci memory:
> @@ -396,6 +397,31 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
>                          IRQNoFlags () {7}
>                      })
>                  }
> +
> +                Device(VGID) {
> +                    Name(_HID, "ACPI0001")
> +                    Name(_UID, 0x00)
> +                    Name(_CID, "VM_Gen_Counter")
> +                    Name(_DDN, "VM_Gen_Counter")
> +                    Method(_STA, 0, NotSerialized)
> +                    {
> +                        If(LEqual(\_SB.VGIA, 0x00000000)) {
> +                            Return(0x00)
> +                        } Else {
> +                            Return(0x0F)
> +                        }
> +                    }
> +                    Name(PKG, Package ()
> +                    {
> +                        0x00000000,
> +                        0x00000000
> +                    })
> +                    Method(ADDR, 0, NotSerialized)
> +                    {
> +                        Store(\_SB.VGIA, Index(PKG, 0))
> +                        Return(PKG)
> +                    }
> +                }
>              }
>          }
>      }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Paul, perhaps a different _HID might be better. Per the 3.0 spec, ACPI0001 is for SMBus host controller device; this might lead to some confusion for an OSPM. Maybe one of the generic PNP device IDs or perhaps we need a manufacturer ID for Xen?

Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:20:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:20:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPTf-0003DC-64; Tue, 29 Nov 2011 15:20:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVPTd-0003Cw-2G
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:20:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322579968!6111163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24229 invoked from network); 29 Nov 2011 15:19:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:19:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:19:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:19:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 15:19:27 +0000
In-Reply-To: <1322578893-9998-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322579968.31810.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/4] docs/html/: Initial cut of header
 documentation massager
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> "xen-headers" generates HTML from header files.  So far this generates
> just some type cross-references, if you say
>    make -C docs html/hypercall/stamp
> 
> An index page, proper wiring into the build system, and a few more
> annotations in the headers, and will be forthcoming.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

> [...]

> +GetOptions("O|output-dir=s" => \$outdir,
> +           "D+" => \$debug,
> +           "T=s" => \$xtitle,
> +	   "I=s" => sub { includeexclude(1, @_); },
> +	   "X=s" => sub { includeexclude(0, @_); })

Indentation is messed up (you've got a hard tab from somewhere).

With that fixed: 
Acked-by: Ian Campbell <ian.campbell@citrix.com>

(insofar as I can review Perl code...)

> +    or die;
> +
> +die unless defined $outdir;
> +@ARGV>=2 or die;
> +
> +my ($basedir,@indirs) = @ARGV;
> +
> +# general globals
> +our $pass;
> +our %sdef; 
> +# $sdef{$type}{$name} => {
> +#     DefLocs => { "$leaf_path:$lineno" => $leaf_opath ,... }
> +#     Xrefs => { "$leaf_path,$lineno" => "$xref", ... }
> +#     Used => 1
> +# }
> +# $type might be  Func Struct Union Enum EnumVal
> +
> +# provided by the find() function
> +our $leaf;
> +our $leaf_opath;
> +
> +# reset at the start of each file
> +our $o;
> +our $in_enum;
> +our @pending_xrefs;
> +
> +sub compile_fglobs () {
> +    local ($_);
> +    my $f = "sub file_wanted (\$) {\n    local (\$_) = \"/\$leaf\";\n";
> +    foreach my $fglob (@fglobs) {
> +	$_ = $fglob->[0];
> +	$_ = "**$_**" unless m/[?*]/;
> +	s/\W/\\$&/g;
> +	s,\\\*\\\*,.*,g;
> +	s,\\\*,[^/]*,g;
> +	s,\\\?,[^/],g;
> +	$f .= "    return $fglob->[1] if m,$_,o;\n";
> +    }
> +    $f .= "    return 1;\n}\n1;\n";
> +    debug(3, $f);
> +    eval $f or die "$@ ";
> +}
> +
> +compile_fglobs();
> +
> +
> +sub warning {
> +    print STDERR "$leaf:$.: @_\n";
> +}
> +
> +sub debug {
> +    my $msglevel = scalar shift @_;
> +    return unless $debug >= $msglevel;
> +    print STDERR "DEBUG $pass $msglevel @_\n" or die $!;
> +}
> +
> +sub in_enum ($$$) { $in_enum = [ @_ ]; } # [ $enumvalpfx, RefType, $refnamepfx ]
> +
> +sub aelem ($$$) {
> +    my ($ntext,$ytext,$hparams) = @_;
> +    return $ntext unless $hparams =~ m/\S/;
> +    return "<a $hparams>$ytext</a>";
> +}
> +
> +sub defn ($$$;$) {
> +    my ($text,$type,$name,$hparams) = @_;
> +    $hparams='' if !defined $hparams;
> +    debug(2,"DEFN $. $type $name $hparams");
> +    $sdef{$type}{$name}{DefLocs}{"$leaf:$."} = $leaf_opath;
> +    my $xrefs = $sdef{$type}{$name}{Xrefs};
> +    push @pending_xrefs, values %$xrefs if $xrefs;
> +    $hparams .= " name=\"${type}_$name\"" if $sdef{$type}{$name}{Used};
> +    return aelem($text, "<strong>$text</strong>", $hparams);
> +}
> +
> +sub norm ($) {
> +    local ($_) = @_;
> +    my $no = '';
> +    while (length) {
> +	if (s/^(?:\s|^\W)+//) {
> +	    $no .= $&;
> +	} elsif (s/^(struct|union|enum)\s+(\w+)\b//) {
> +	    $no .= ahref($&, (ucfirst $1), $2);
> +	} elsif (s/^\w+\b//) {
> +	    $no .= ahref($&, 'Func', $&);
> +	} else {
> +	    die "$_ ?";
> +	}
> +    }
> +    return $no;
> +}
> +
> +sub refhref ($$) {
> +    my ($type,$name) = @_;
> +    $sdef{$type}{$name}{Used} = 1;
> +    my $locs = $sdef{$type}{$name}{DefLocs};
> +    return '' unless $locs;
> +    if ((scalar keys %$locs) != 1 && !$sdef{$type}{$name}{MultiWarned}) {
> +	warning("multiple definitions of $type $name: $_")
> +	    foreach keys %$locs;
> +	$sdef{$type}{$name}{MultiWarned}=1;
> +    }
> +    my ($loc) = values %$locs;
> +    return "href=\"$loc#${type}_$name\"";
> +}
> +
> +sub ahref ($$$) {
> +    my ($text,$type,$name) = @_;
> +    return aelem($text,$text, refhref($type,$name));
> +}
> +
> +sub defmacro ($) {
> +    my ($valname) = @_;
> +    if (!$in_enum) {
> +	return $valname;
> +    } elsif (substr($valname, 0, (length $in_enum->[0])) ne $in_enum->[0]) {
> +	warning("in enum expecting $in_enum->[0]* got $valname");
> +	return $valname;
> +    } else {
> +	my $reftype = $in_enum->[1];
> +	my $refname = $in_enum->[2].substr($valname, (length $in_enum->[0]));
> +	$sdef{$reftype}{$refname}{Xrefs}{$leaf,$.} =
> +	    "[see <a href=\"$leaf_opath#EnumVal_$valname\">$valname</a>]";
> +	$sdef{EnumVal}{$valname}{Used} = 1;
> +	return defn($valname,'EnumVal',$valname, refhref($reftype,$refname));
> +    }
> +}
> +
> +sub out_xrefs ($) {
> +    my ($linemapfunc) = @_;
> +    foreach my $xref (@pending_xrefs) {
> +	$o .= $linemapfunc->($xref);
> +	$o .= "\n";
> +    }
> +    @pending_xrefs = ();
> +}
> +
> +sub write_file ($$) {
> +    my ($opath, $odata) = @_;
> +    my $out = new IO::File "$opath.new", '>' or die "$opath $!";
> +    print $out $odata or die $!;
> +    rename "$opath.new", "$opath" or die "$opath $!";
> +}
> +
> +sub process_file ($$) {
> +    my ($infile, $outfile) = @_;
> +    debug(1,"$pass $infile => $outfile");
> +    my $in = new IO::File "$infile", '<' or die "$infile $!";
> +
> +    $o = '';
> +    $in_enum = undef;
> +    @pending_xrefs = ();
> +
> +    $o .= "<html><head><title>$leaf - $xtitle</title></head><body><pre>\n";
> +    
> +    while (<$in>) {
> +	s/\&/\&amp;/g;
> +	s/\</\&lt;/g;
> +	s/\>/\&gt;/g;
> +
> +	if (m/^(.*\`)[ \t]*$/) {
> +	    my $lhs = $1;
> +	    out_xrefs(sub { "$1 $_[0]"; });
> +	} elsif (m/^\s*$/) {
> +	    out_xrefs(sub { sprintf "/* %70s */", $_[0]; });
> +	}
> +
> +	# In case of comments, strip " /* ` " and " * ` ";
> +	my $lstripped = s,^ \s* /? \* \s* \` \  ,,x ? $&: '';
> +
> +	# Strip trailing whitespace and perhaps trailing "*/" or "*"
> +	s,(?: \s* \* /? )? \s* $,,x or die;
> +	my $rstripped = $&;
> +
> +	# Now the actual functionality:
> +
> +	debug(3,"$. $_");
> +
> +	if (!m/^(?: __attribute__ | __pragma__ )\b/x &&
> +	    s/^( (?: \w+\  )? ) (\w+[a-z]\w+) ( \( .*)$
> +             / $1.defn($2,'Func',$2).norm($3) /xe) {
> +	} elsif (s/^((struct|union|enum) \  (\w+)) ( \s+ \{ .* )$
> +                  / defn($1,(ucfirst $2),$3).norm($4) /xe) {
> +	    if ($2 eq 'enum') {
> +		if (m,/[/*] (\w+)\* \=\&gt\; (\w+)\*\(\),) { 
> +		    in_enum($1,'Func',$2)
> +		} elsif (m,/[/*] (\w+)\* \=\&gt\; (struct) (\w+)\*,) { 
> +		    in_enum($1,(ucfirst $2),$3);
> +	        }
> +	    }
> +	} elsif (s/^( \s* \#define \s+ ) (\w+) ( \s+\S )
> +                  / $1.defmacro($2).norm($3) /xe) {
> +	} else {
> +	    if (m/^\s*\}/) {
> +		$in_enum = undef;
> +	    }
> +	    $_ = norm($_);
> +	}
> +
> +	# Write the line out
> +
> +	if ($pass == 2) {
> +	    $o .= $lstripped;
> +	    $o .= $_;
> +	    $o .= $rstripped;
> +	}
> +    }
> +
> +    warning("pending xrefs at end of file") if @pending_xrefs;
> +
> +    if ($pass == 2) {
> +	$o .= "</pre></body></html>";
> +	write_file($outfile, $o);
> +    }
> +}
> +
> +
> +foreach $pass (qw(1 2)) {
> +    find({ wanted => 
> +	       sub {
> +		   return unless m/\.h$/;
> +		   lstat $File::Find::name or die "$File::Find::name $!";
> +		   -f _ or die "$File::Find::name";
> +		   substr($File::Find::name, 0, 1+length $basedir) 
> +		       eq "$basedir/"
> +		       or die "$File::Find::name $basedir";
> +		   $leaf = substr($File::Find::name, 1+length $basedir);
> +		   if (!file_wanted()) {
> +		       debug(1,"$pass $File::Find::name excluded");
> +		       return;
> +		   }
> +		   $leaf_opath = $leaf;
> +		   $leaf_opath =~ s#/#,#g;
> +		   $leaf_opath .= ".html";
> +		   process_file($File::Find::name, $outdir.'/'.$leaf_opath);
> +	   },
> +	   no_chdir => 1,
> +	 },
> +	 map { "$basedir/$_" } @indirs);
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:20:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:20:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPTf-0003DC-64; Tue, 29 Nov 2011 15:20:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVPTd-0003Cw-2G
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:20:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322579968!6111163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24229 invoked from network); 29 Nov 2011 15:19:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:19:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9188971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:19:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:19:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 15:19:27 +0000
In-Reply-To: <1322578893-9998-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322579968.31810.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/4] docs/html/: Initial cut of header
 documentation massager
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> "xen-headers" generates HTML from header files.  So far this generates
> just some type cross-references, if you say
>    make -C docs html/hypercall/stamp
> 
> An index page, proper wiring into the build system, and a few more
> annotations in the headers, and will be forthcoming.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

> [...]

> +GetOptions("O|output-dir=s" => \$outdir,
> +           "D+" => \$debug,
> +           "T=s" => \$xtitle,
> +	   "I=s" => sub { includeexclude(1, @_); },
> +	   "X=s" => sub { includeexclude(0, @_); })

Indentation is messed up (you've got a hard tab from somewhere).

With that fixed: 
Acked-by: Ian Campbell <ian.campbell@citrix.com>

(insofar as I can review Perl code...)

> +    or die;
> +
> +die unless defined $outdir;
> +@ARGV>=2 or die;
> +
> +my ($basedir,@indirs) = @ARGV;
> +
> +# general globals
> +our $pass;
> +our %sdef; 
> +# $sdef{$type}{$name} => {
> +#     DefLocs => { "$leaf_path:$lineno" => $leaf_opath ,... }
> +#     Xrefs => { "$leaf_path,$lineno" => "$xref", ... }
> +#     Used => 1
> +# }
> +# $type might be  Func Struct Union Enum EnumVal
> +
> +# provided by the find() function
> +our $leaf;
> +our $leaf_opath;
> +
> +# reset at the start of each file
> +our $o;
> +our $in_enum;
> +our @pending_xrefs;
> +
> +sub compile_fglobs () {
> +    local ($_);
> +    my $f = "sub file_wanted (\$) {\n    local (\$_) = \"/\$leaf\";\n";
> +    foreach my $fglob (@fglobs) {
> +	$_ = $fglob->[0];
> +	$_ = "**$_**" unless m/[?*]/;
> +	s/\W/\\$&/g;
> +	s,\\\*\\\*,.*,g;
> +	s,\\\*,[^/]*,g;
> +	s,\\\?,[^/],g;
> +	$f .= "    return $fglob->[1] if m,$_,o;\n";
> +    }
> +    $f .= "    return 1;\n}\n1;\n";
> +    debug(3, $f);
> +    eval $f or die "$@ ";
> +}
> +
> +compile_fglobs();
> +
> +
> +sub warning {
> +    print STDERR "$leaf:$.: @_\n";
> +}
> +
> +sub debug {
> +    my $msglevel = scalar shift @_;
> +    return unless $debug >= $msglevel;
> +    print STDERR "DEBUG $pass $msglevel @_\n" or die $!;
> +}
> +
> +sub in_enum ($$$) { $in_enum = [ @_ ]; } # [ $enumvalpfx, RefType, $refnamepfx ]
> +
> +sub aelem ($$$) {
> +    my ($ntext,$ytext,$hparams) = @_;
> +    return $ntext unless $hparams =~ m/\S/;
> +    return "<a $hparams>$ytext</a>";
> +}
> +
> +sub defn ($$$;$) {
> +    my ($text,$type,$name,$hparams) = @_;
> +    $hparams='' if !defined $hparams;
> +    debug(2,"DEFN $. $type $name $hparams");
> +    $sdef{$type}{$name}{DefLocs}{"$leaf:$."} = $leaf_opath;
> +    my $xrefs = $sdef{$type}{$name}{Xrefs};
> +    push @pending_xrefs, values %$xrefs if $xrefs;
> +    $hparams .= " name=\"${type}_$name\"" if $sdef{$type}{$name}{Used};
> +    return aelem($text, "<strong>$text</strong>", $hparams);
> +}
> +
> +sub norm ($) {
> +    local ($_) = @_;
> +    my $no = '';
> +    while (length) {
> +	if (s/^(?:\s|^\W)+//) {
> +	    $no .= $&;
> +	} elsif (s/^(struct|union|enum)\s+(\w+)\b//) {
> +	    $no .= ahref($&, (ucfirst $1), $2);
> +	} elsif (s/^\w+\b//) {
> +	    $no .= ahref($&, 'Func', $&);
> +	} else {
> +	    die "$_ ?";
> +	}
> +    }
> +    return $no;
> +}
> +
> +sub refhref ($$) {
> +    my ($type,$name) = @_;
> +    $sdef{$type}{$name}{Used} = 1;
> +    my $locs = $sdef{$type}{$name}{DefLocs};
> +    return '' unless $locs;
> +    if ((scalar keys %$locs) != 1 && !$sdef{$type}{$name}{MultiWarned}) {
> +	warning("multiple definitions of $type $name: $_")
> +	    foreach keys %$locs;
> +	$sdef{$type}{$name}{MultiWarned}=1;
> +    }
> +    my ($loc) = values %$locs;
> +    return "href=\"$loc#${type}_$name\"";
> +}
> +
> +sub ahref ($$$) {
> +    my ($text,$type,$name) = @_;
> +    return aelem($text,$text, refhref($type,$name));
> +}
> +
> +sub defmacro ($) {
> +    my ($valname) = @_;
> +    if (!$in_enum) {
> +	return $valname;
> +    } elsif (substr($valname, 0, (length $in_enum->[0])) ne $in_enum->[0]) {
> +	warning("in enum expecting $in_enum->[0]* got $valname");
> +	return $valname;
> +    } else {
> +	my $reftype = $in_enum->[1];
> +	my $refname = $in_enum->[2].substr($valname, (length $in_enum->[0]));
> +	$sdef{$reftype}{$refname}{Xrefs}{$leaf,$.} =
> +	    "[see <a href=\"$leaf_opath#EnumVal_$valname\">$valname</a>]";
> +	$sdef{EnumVal}{$valname}{Used} = 1;
> +	return defn($valname,'EnumVal',$valname, refhref($reftype,$refname));
> +    }
> +}
> +
> +sub out_xrefs ($) {
> +    my ($linemapfunc) = @_;
> +    foreach my $xref (@pending_xrefs) {
> +	$o .= $linemapfunc->($xref);
> +	$o .= "\n";
> +    }
> +    @pending_xrefs = ();
> +}
> +
> +sub write_file ($$) {
> +    my ($opath, $odata) = @_;
> +    my $out = new IO::File "$opath.new", '>' or die "$opath $!";
> +    print $out $odata or die $!;
> +    rename "$opath.new", "$opath" or die "$opath $!";
> +}
> +
> +sub process_file ($$) {
> +    my ($infile, $outfile) = @_;
> +    debug(1,"$pass $infile => $outfile");
> +    my $in = new IO::File "$infile", '<' or die "$infile $!";
> +
> +    $o = '';
> +    $in_enum = undef;
> +    @pending_xrefs = ();
> +
> +    $o .= "<html><head><title>$leaf - $xtitle</title></head><body><pre>\n";
> +    
> +    while (<$in>) {
> +	s/\&/\&amp;/g;
> +	s/\</\&lt;/g;
> +	s/\>/\&gt;/g;
> +
> +	if (m/^(.*\`)[ \t]*$/) {
> +	    my $lhs = $1;
> +	    out_xrefs(sub { "$1 $_[0]"; });
> +	} elsif (m/^\s*$/) {
> +	    out_xrefs(sub { sprintf "/* %70s */", $_[0]; });
> +	}
> +
> +	# In case of comments, strip " /* ` " and " * ` ";
> +	my $lstripped = s,^ \s* /? \* \s* \` \  ,,x ? $&: '';
> +
> +	# Strip trailing whitespace and perhaps trailing "*/" or "*"
> +	s,(?: \s* \* /? )? \s* $,,x or die;
> +	my $rstripped = $&;
> +
> +	# Now the actual functionality:
> +
> +	debug(3,"$. $_");
> +
> +	if (!m/^(?: __attribute__ | __pragma__ )\b/x &&
> +	    s/^( (?: \w+\  )? ) (\w+[a-z]\w+) ( \( .*)$
> +             / $1.defn($2,'Func',$2).norm($3) /xe) {
> +	} elsif (s/^((struct|union|enum) \  (\w+)) ( \s+ \{ .* )$
> +                  / defn($1,(ucfirst $2),$3).norm($4) /xe) {
> +	    if ($2 eq 'enum') {
> +		if (m,/[/*] (\w+)\* \=\&gt\; (\w+)\*\(\),) { 
> +		    in_enum($1,'Func',$2)
> +		} elsif (m,/[/*] (\w+)\* \=\&gt\; (struct) (\w+)\*,) { 
> +		    in_enum($1,(ucfirst $2),$3);
> +	        }
> +	    }
> +	} elsif (s/^( \s* \#define \s+ ) (\w+) ( \s+\S )
> +                  / $1.defmacro($2).norm($3) /xe) {
> +	} else {
> +	    if (m/^\s*\}/) {
> +		$in_enum = undef;
> +	    }
> +	    $_ = norm($_);
> +	}
> +
> +	# Write the line out
> +
> +	if ($pass == 2) {
> +	    $o .= $lstripped;
> +	    $o .= $_;
> +	    $o .= $rstripped;
> +	}
> +    }
> +
> +    warning("pending xrefs at end of file") if @pending_xrefs;
> +
> +    if ($pass == 2) {
> +	$o .= "</pre></body></html>";
> +	write_file($outfile, $o);
> +    }
> +}
> +
> +
> +foreach $pass (qw(1 2)) {
> +    find({ wanted => 
> +	       sub {
> +		   return unless m/\.h$/;
> +		   lstat $File::Find::name or die "$File::Find::name $!";
> +		   -f _ or die "$File::Find::name";
> +		   substr($File::Find::name, 0, 1+length $basedir) 
> +		       eq "$basedir/"
> +		       or die "$File::Find::name $basedir";
> +		   $leaf = substr($File::Find::name, 1+length $basedir);
> +		   if (!file_wanted()) {
> +		       debug(1,"$pass $File::Find::name excluded");
> +		       return;
> +		   }
> +		   $leaf_opath = $leaf;
> +		   $leaf_opath =~ s#/#,#g;
> +		   $leaf_opath .= ".html";
> +		   process_file($File::Find::name, $outdir.'/'.$leaf_opath);
> +	   },
> +	   no_chdir => 1,
> +	 },
> +	 map { "$basedir/$_" } @indirs);
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:21:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:21:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPUT-0003IE-Qx; Tue, 29 Nov 2011 15:21:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVPUS-0003HX-A0
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:21:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322580022!3575754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13684 invoked from network); 29 Nov 2011 15:20:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189005"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:20:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:20:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 15:20:22 +0000
In-Reply-To: <1322578893-9998-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322580022.31810.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two
 hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> Add annotations for a couple of the hypercalls:
>  HYPERVISOR_set_trap_table
>  HYPERVISOR_mmu_update
> 
> We do this by
>  * annotating the list of #defines for hypercall numbers
>  * annotating the list of error values
>  * providing a function prototype for the systematically-named functions
> The header generator does the rest.
> 
> This exercise revealed a couple of infelicities:
>  * In the actual source code, do_mmu_update is defined to return an int
>    and do_set_trap_table a long.  However both functions return either
>    -Efoo (on error) or 0 for success.

Should that be fixed or would that do more harm than good?

>  * The error numbers are defined only in the private header file
>    xen/include/xen/errno.h and then only with names which will
>    typically clash with other projects.  It would be nice to include a
>    public version of this header which defines XEN_E*.  But for now
>    we run xen-headers on errno.h too.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  docs/Makefile                     |    2 +-
>  xen/include/public/arch-x86/xen.h |    6 ++++++
>  xen/include/public/xen.h          |   11 +++++++++--
>  xen/include/xen/errno.h           |    5 +++++
>  4 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/Makefile b/docs/Makefile
> index ad315cf..a2bbf2d 100644
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -134,7 +134,7 @@ html/hypercall/stamp:
>  	./xen-headers -O $(@D) \
>  		-T 'arch-x86_64 - Xen public headers' \
>  		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 \
> -		../xen include/public
> +		../xen include/public include/xen/errno.h
>  	touch $@
>  
>  txt/%.txt: %.txt
> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
> index 79ec633..d663cef 100644
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -82,7 +82,13 @@ typedef unsigned long xen_pfn_t;
>  typedef unsigned long xen_ulong_t;
>  
>  /*
> + * ` enum neg_errnoval
> + * ` HYPERVISOR_set_trap_table(const struct trap_info traps[]);
> + * `
> + */
> +/*
>   * Send an array of these to HYPERVISOR_set_trap_table().
> + * Terminate the array with a sentinel entry, with traps[].address==0.
>   * The privilege level specifies which modes may enter a trap via a software
>   * interrupt. On x86/64, since rings 1 and 2 are unavailable, we allocate
>   * privilege levels as follows:
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index fde9fa5..f2c9e6f 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -55,6 +55,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>   * HYPERCALLS
>   */
>  
> +/* ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*() */
> +
>  #define __HYPERVISOR_set_trap_table        0
>  #define __HYPERVISOR_mmu_update            1
>  #define __HYPERVISOR_set_gdt               2
> @@ -105,6 +107,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>  #define __HYPERVISOR_arch_6               54
>  #define __HYPERVISOR_arch_7               55
>  
> +/* ` } */
> +
>  /*
>   * HYPERCALL COMPATIBILITY.
>   */
> @@ -163,8 +167,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>  #define NR_VIRQS       24
>  
>  /*
> - * HYPERVISOR_mmu_update(reqs, count, pdone, foreigndom)
> - * 
> + * ` enum neg_errnoval
> + * ` HYPERVISOR_mmu_update(const struct mmu_update reqs[],
> + * `                       unsigned count, unsigned *done_out,
> + * `                       unsigned foreigndom)
> + * `
>   * @reqs is an array of mmu_update_t structures ((ptr, val) pairs).
>   * @count is the length of the above array.
>   * @pdone is an output parameter indicating number of completed operations
> diff --git a/xen/include/xen/errno.h b/xen/include/xen/errno.h
> index 7cf599f..39147be 100644
> --- a/xen/include/xen/errno.h
> +++ b/xen/include/xen/errno.h
> @@ -1,6 +1,9 @@
>  #ifndef _I386_ERRNO_H
>  #define _I386_ERRNO_H
>  
> +/* ` enum neg_errnoval {  [ -Efoo for each Efoo in the list below ]  } */
> +/* ` enum errnoval { */
> +
>  #define	EPERM		 1	/* Operation not permitted */
>  #define	ENOENT		 2	/* No such file or directory */
>  #define	ESRCH		 3	/* No such process */
> @@ -129,4 +132,6 @@
>  #define	ENOMEDIUM	123	/* No medium found */
>  #define	EMEDIUMTYPE	124	/* Wrong medium type */
>  
> +/* ` } */
> +
>  #endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:21:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:21:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPUT-0003IE-Qx; Tue, 29 Nov 2011 15:21:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVPUS-0003HX-A0
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:21:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322580022!3575754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13684 invoked from network); 29 Nov 2011 15:20:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189005"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:20:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:20:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 15:20:22 +0000
In-Reply-To: <1322578893-9998-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322580022.31810.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two
 hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> Add annotations for a couple of the hypercalls:
>  HYPERVISOR_set_trap_table
>  HYPERVISOR_mmu_update
> 
> We do this by
>  * annotating the list of #defines for hypercall numbers
>  * annotating the list of error values
>  * providing a function prototype for the systematically-named functions
> The header generator does the rest.
> 
> This exercise revealed a couple of infelicities:
>  * In the actual source code, do_mmu_update is defined to return an int
>    and do_set_trap_table a long.  However both functions return either
>    -Efoo (on error) or 0 for success.

Should that be fixed or would that do more harm than good?

>  * The error numbers are defined only in the private header file
>    xen/include/xen/errno.h and then only with names which will
>    typically clash with other projects.  It would be nice to include a
>    public version of this header which defines XEN_E*.  But for now
>    we run xen-headers on errno.h too.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  docs/Makefile                     |    2 +-
>  xen/include/public/arch-x86/xen.h |    6 ++++++
>  xen/include/public/xen.h          |   11 +++++++++--
>  xen/include/xen/errno.h           |    5 +++++
>  4 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/Makefile b/docs/Makefile
> index ad315cf..a2bbf2d 100644
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -134,7 +134,7 @@ html/hypercall/stamp:
>  	./xen-headers -O $(@D) \
>  		-T 'arch-x86_64 - Xen public headers' \
>  		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 \
> -		../xen include/public
> +		../xen include/public include/xen/errno.h
>  	touch $@
>  
>  txt/%.txt: %.txt
> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
> index 79ec633..d663cef 100644
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -82,7 +82,13 @@ typedef unsigned long xen_pfn_t;
>  typedef unsigned long xen_ulong_t;
>  
>  /*
> + * ` enum neg_errnoval
> + * ` HYPERVISOR_set_trap_table(const struct trap_info traps[]);
> + * `
> + */
> +/*
>   * Send an array of these to HYPERVISOR_set_trap_table().
> + * Terminate the array with a sentinel entry, with traps[].address==0.
>   * The privilege level specifies which modes may enter a trap via a software
>   * interrupt. On x86/64, since rings 1 and 2 are unavailable, we allocate
>   * privilege levels as follows:
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index fde9fa5..f2c9e6f 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -55,6 +55,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>   * HYPERCALLS
>   */
>  
> +/* ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*() */
> +
>  #define __HYPERVISOR_set_trap_table        0
>  #define __HYPERVISOR_mmu_update            1
>  #define __HYPERVISOR_set_gdt               2
> @@ -105,6 +107,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>  #define __HYPERVISOR_arch_6               54
>  #define __HYPERVISOR_arch_7               55
>  
> +/* ` } */
> +
>  /*
>   * HYPERCALL COMPATIBILITY.
>   */
> @@ -163,8 +167,11 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>  #define NR_VIRQS       24
>  
>  /*
> - * HYPERVISOR_mmu_update(reqs, count, pdone, foreigndom)
> - * 
> + * ` enum neg_errnoval
> + * ` HYPERVISOR_mmu_update(const struct mmu_update reqs[],
> + * `                       unsigned count, unsigned *done_out,
> + * `                       unsigned foreigndom)
> + * `
>   * @reqs is an array of mmu_update_t structures ((ptr, val) pairs).
>   * @count is the length of the above array.
>   * @pdone is an output parameter indicating number of completed operations
> diff --git a/xen/include/xen/errno.h b/xen/include/xen/errno.h
> index 7cf599f..39147be 100644
> --- a/xen/include/xen/errno.h
> +++ b/xen/include/xen/errno.h
> @@ -1,6 +1,9 @@
>  #ifndef _I386_ERRNO_H
>  #define _I386_ERRNO_H
>  
> +/* ` enum neg_errnoval {  [ -Efoo for each Efoo in the list below ]  } */
> +/* ` enum errnoval { */
> +
>  #define	EPERM		 1	/* Operation not permitted */
>  #define	ENOENT		 2	/* No such file or directory */
>  #define	ESRCH		 3	/* No such process */
> @@ -129,4 +132,6 @@
>  #define	ENOMEDIUM	123	/* No medium found */
>  #define	EMEDIUMTYPE	124	/* Wrong medium type */
>  
> +/* ` } */
> +
>  #endif



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:26:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:26:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPZg-0003mT-PY; Tue, 29 Nov 2011 15:26:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVPZe-0003m3-Ql
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:26:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322580329!57003424!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14180 invoked from network); 29 Nov 2011 15:25:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:25:29 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:25:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:25:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 15:25:44 +0000
In-Reply-To: <1322578893-9998-4-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322580344.31810.13.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/4] docs/html/: Generate an "index.html"
 for hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> Generate an "index.html" containing various useful links.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  docs/xen-headers         |   59 ++++++++++++++++++++++++++++++++++++++++++++++
>  xen/include/public/xen.h |    4 ++-
>  2 files changed, 62 insertions(+), 1 deletions(-)
> 
> diff --git a/docs/xen-headers b/docs/xen-headers
> index e893f91..dcf673e 100755
> --- a/docs/xen-headers
> +++ b/docs/xen-headers
> @@ -17,6 +17,10 @@
>  
>  #  definitions must start in LH column
>  #  extra syntax:
> +#   `incontents <seq> <shortname> <anchor text html>...
> +#                              make a table of contents entry; they
> +#                              will be sorted by increasing seq, and
> +#                              shortname will be used as the anchor target
>  #    /* ` <definition>                          } parse as if <definition>
>  #     * ` <definition>                          }  was not commented
>  #   enum <name> { // <pattern>* => <func>()     } cross-reference
> @@ -60,6 +64,8 @@ my ($basedir,@indirs) = @ARGV;
>  # general globals
>  our $pass;
>  our %sdef; 
> +our @incontents;
> +our @outfiles;
>  # $sdef{$type}{$name} => {
>  #     DefLocs => { "$leaf_path:$lineno" => $leaf_opath ,... }
>  #     Xrefs => { "$leaf_path,$lineno" => "$xref", ... }
> @@ -187,6 +193,19 @@ sub out_xrefs ($) {
>      @pending_xrefs = ();
>  }
>  
> +sub incontents ($$$) {
> +    my ($text, $seq, $anchor) = @_;
> +    $anchor = "incontents_$anchor";
> +    if ($pass==2) {
> +	push @incontents, { 
> +	    Seq => $seq,
> +	    Href => "$leaf_opath#$anchor",
> +	    Title => $text,
> +	};
> +    }
> +    return "<a name=\"$anchor\"><strong>$text</strong></a>";
> +}
> +
>  sub write_file ($$) {
>      my ($opath, $odata) = @_;
>      my $out = new IO::File "$opath.new", '>' or die "$opath $!";
> @@ -242,6 +261,8 @@ sub process_file ($$) {
>  	    }
>  	} elsif (s/^( \s* \#define \s+ ) (\w+) ( \s+\S )
>                    / $1.defmacro($2).norm($3) /xe) {
> +	} elsif (s/( \`incontents \s+ (\d+) \s+ (\w+) \s+ )(\S .* \S)
> +                 / norm($1).incontents($4, $2, $3) /xe) {
>  	} else {
>  	    if (m/^\s*\}/) {
>  		$in_enum = undef;
> @@ -261,11 +282,47 @@ sub process_file ($$) {
>      warning("pending xrefs at end of file") if @pending_xrefs;
>  
>      if ($pass == 2) {
> +	push @outfiles, [ $leaf, $leaf_opath ];
>  	$o .= "</pre></body></html>";
>  	write_file($outfile, $o);
>      }
>  }
>  
> +sub output_index () {
> +    my $title = "contents - $xtitle";
> +    $o = '';
> +    $o .= <<END;
> +<html><head><title>$title</title></head>
> +<body>
> +<h1>$title</h1>
> +<h2>Starting points</h2>
> +<ul>
> +END
> +    foreach my $ic (sort { $a->{Seq} <=> $b->{Seq} } @incontents) {
> +	$o .= "<li><a href=\"$ic->{Href}\">$ic->{Title}</a></li>\n";
> +    }
> +    $o .= "</ul>\n";
> +    my $forkind = sub {
> +	my ($type,$desc,$pfx,$sfx) = @_;
> +	$o .= "<h2>$desc</h2><ul>\n";
> +	foreach my $name (sort keys %{ $sdef{$type} }) {
> +	    my $href = refhref($type,$name);
> +	    next unless $href =~ m/\S/;
> +	    $o .= "<li><a $href>$pfx$name$sfx</a></li>\n";
> +	}
> +	$o .= "</ul>\n";
> +    };
> +    $forkind->('Func','Functions','','()');
> +    $forkind->('Struct','Structs','struct ','');
> +    $forkind->('Enum','Enums and sets of #defines','','');
> +    $forkind->('EnumVal','Enum values and individual #defines','','');
> +    $o .= "</ul>\n<h2>Files</h2><ul>\n";
> +    foreach my $of (sort { $a->[0] cmp $b->[0] } @outfiles) {
> +	$o .= "<li><a href=\"$of->[1]\">$of->[0]</a></li>\n";
> +    }
> +    $o .= "</ul></body></html>\n";
> +    write_file("$outdir/index.html", $o);
> +}
>  
>  foreach $pass (qw(1 2)) {
>      find({ wanted => 
> @@ -290,3 +347,5 @@ foreach $pass (qw(1 2)) {
>  	 },
>  	 map { "$basedir/$_" } @indirs);
>  }
> +
> +output_index();
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index f2c9e6f..a5b6ad8 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -55,7 +55,9 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>   * HYPERCALLS
>   */
>  
> -/* ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*() */
> +/* `incontents 100 hcalls List of hypercalls
> + * ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*()
> + */
>  
>  #define __HYPERVISOR_set_trap_table        0
>  #define __HYPERVISOR_mmu_update            1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:26:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:26:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPZg-0003mT-PY; Tue, 29 Nov 2011 15:26:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVPZe-0003m3-Ql
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:26:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322580329!57003424!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14180 invoked from network); 29 Nov 2011 15:25:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:25:29 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:25:45 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:25:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 15:25:44 +0000
In-Reply-To: <1322578893-9998-4-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322580344.31810.13.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/4] docs/html/: Generate an "index.html"
 for hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> Generate an "index.html" containing various useful links.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  docs/xen-headers         |   59 ++++++++++++++++++++++++++++++++++++++++++++++
>  xen/include/public/xen.h |    4 ++-
>  2 files changed, 62 insertions(+), 1 deletions(-)
> 
> diff --git a/docs/xen-headers b/docs/xen-headers
> index e893f91..dcf673e 100755
> --- a/docs/xen-headers
> +++ b/docs/xen-headers
> @@ -17,6 +17,10 @@
>  
>  #  definitions must start in LH column
>  #  extra syntax:
> +#   `incontents <seq> <shortname> <anchor text html>...
> +#                              make a table of contents entry; they
> +#                              will be sorted by increasing seq, and
> +#                              shortname will be used as the anchor target
>  #    /* ` <definition>                          } parse as if <definition>
>  #     * ` <definition>                          }  was not commented
>  #   enum <name> { // <pattern>* => <func>()     } cross-reference
> @@ -60,6 +64,8 @@ my ($basedir,@indirs) = @ARGV;
>  # general globals
>  our $pass;
>  our %sdef; 
> +our @incontents;
> +our @outfiles;
>  # $sdef{$type}{$name} => {
>  #     DefLocs => { "$leaf_path:$lineno" => $leaf_opath ,... }
>  #     Xrefs => { "$leaf_path,$lineno" => "$xref", ... }
> @@ -187,6 +193,19 @@ sub out_xrefs ($) {
>      @pending_xrefs = ();
>  }
>  
> +sub incontents ($$$) {
> +    my ($text, $seq, $anchor) = @_;
> +    $anchor = "incontents_$anchor";
> +    if ($pass==2) {
> +	push @incontents, { 
> +	    Seq => $seq,
> +	    Href => "$leaf_opath#$anchor",
> +	    Title => $text,
> +	};
> +    }
> +    return "<a name=\"$anchor\"><strong>$text</strong></a>";
> +}
> +
>  sub write_file ($$) {
>      my ($opath, $odata) = @_;
>      my $out = new IO::File "$opath.new", '>' or die "$opath $!";
> @@ -242,6 +261,8 @@ sub process_file ($$) {
>  	    }
>  	} elsif (s/^( \s* \#define \s+ ) (\w+) ( \s+\S )
>                    / $1.defmacro($2).norm($3) /xe) {
> +	} elsif (s/( \`incontents \s+ (\d+) \s+ (\w+) \s+ )(\S .* \S)
> +                 / norm($1).incontents($4, $2, $3) /xe) {
>  	} else {
>  	    if (m/^\s*\}/) {
>  		$in_enum = undef;
> @@ -261,11 +282,47 @@ sub process_file ($$) {
>      warning("pending xrefs at end of file") if @pending_xrefs;
>  
>      if ($pass == 2) {
> +	push @outfiles, [ $leaf, $leaf_opath ];
>  	$o .= "</pre></body></html>";
>  	write_file($outfile, $o);
>      }
>  }
>  
> +sub output_index () {
> +    my $title = "contents - $xtitle";
> +    $o = '';
> +    $o .= <<END;
> +<html><head><title>$title</title></head>
> +<body>
> +<h1>$title</h1>
> +<h2>Starting points</h2>
> +<ul>
> +END
> +    foreach my $ic (sort { $a->{Seq} <=> $b->{Seq} } @incontents) {
> +	$o .= "<li><a href=\"$ic->{Href}\">$ic->{Title}</a></li>\n";
> +    }
> +    $o .= "</ul>\n";
> +    my $forkind = sub {
> +	my ($type,$desc,$pfx,$sfx) = @_;
> +	$o .= "<h2>$desc</h2><ul>\n";
> +	foreach my $name (sort keys %{ $sdef{$type} }) {
> +	    my $href = refhref($type,$name);
> +	    next unless $href =~ m/\S/;
> +	    $o .= "<li><a $href>$pfx$name$sfx</a></li>\n";
> +	}
> +	$o .= "</ul>\n";
> +    };
> +    $forkind->('Func','Functions','','()');
> +    $forkind->('Struct','Structs','struct ','');
> +    $forkind->('Enum','Enums and sets of #defines','','');
> +    $forkind->('EnumVal','Enum values and individual #defines','','');
> +    $o .= "</ul>\n<h2>Files</h2><ul>\n";
> +    foreach my $of (sort { $a->[0] cmp $b->[0] } @outfiles) {
> +	$o .= "<li><a href=\"$of->[1]\">$of->[0]</a></li>\n";
> +    }
> +    $o .= "</ul></body></html>\n";
> +    write_file("$outdir/index.html", $o);
> +}
>  
>  foreach $pass (qw(1 2)) {
>      find({ wanted => 
> @@ -290,3 +347,5 @@ foreach $pass (qw(1 2)) {
>  	 },
>  	 map { "$basedir/$_" } @indirs);
>  }
> +
> +output_index();
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index f2c9e6f..a5b6ad8 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -55,7 +55,9 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
>   * HYPERCALLS
>   */
>  
> -/* ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*() */
> +/* `incontents 100 hcalls List of hypercalls
> + * ` enum hypercall_num { // __HYPERVISOR_* => HYPERVISOR_*()
> + */
>  
>  #define __HYPERVISOR_set_trap_table        0
>  #define __HYPERVISOR_mmu_update            1



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:27:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:27:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPZr-0003nb-6L; Tue, 29 Nov 2011 15:26:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPZo-0003mp-Mi
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:26:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322580355!5475394!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8274 invoked from network); 29 Nov 2011 15:25:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:25:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189188"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:25:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:25:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPZC-000491-La; Tue, 29 Nov 2011 15:25:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPZC-00088t-If;
	Tue, 29 Nov 2011 15:25:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20180.63874.433946.85484@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 15:25:54 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <a08afddff75b70f816d3.1322576456@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
	<a08afddff75b70f816d3.1322576456@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14 of 17 v3] xl: make bootloader_args a list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH 14 of 17 v3] xl: make bootloader_args a list"):
> xl: make bootloader_args a list
> 
> This is much more natural. Continue to support the old syntax in xl but deprecate it.

I have applied all of these.  (I fixed up an overly long line in
14/17.)

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:27:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:27:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPZr-0003nb-6L; Tue, 29 Nov 2011 15:26:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPZo-0003mp-Mi
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:26:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322580355!5475394!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8274 invoked from network); 29 Nov 2011 15:25:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:25:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189188"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:25:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:25:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPZC-000491-La; Tue, 29 Nov 2011 15:25:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPZC-00088t-If;
	Tue, 29 Nov 2011 15:25:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20180.63874.433946.85484@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 15:25:54 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <a08afddff75b70f816d3.1322576456@cosworth.uk.xensource.com>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
	<a08afddff75b70f816d3.1322576456@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 14 of 17 v3] xl: make bootloader_args a list
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH 14 of 17 v3] xl: make bootloader_args a list"):
> xl: make bootloader_args a list
> 
> This is much more natural. Continue to support the old syntax in xl but deprecate it.

I have applied all of these.  (I fixed up an overly long line in
14/17.)

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:28:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPbE-0003wv-NB; Tue, 29 Nov 2011 15:28:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVPbD-0003wS-T0
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:28:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322580442!5503120!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28090 invoked from network); 29 Nov 2011 15:27:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:27:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189243"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:27:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:27:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 15:27:22 +0000
In-Reply-To: <1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322580442.31810.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/4] docs/html/: Arrange for automatic build
 of hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> - Use index.html rather than a stamp file.
> - Automatically generate dependencies.
> - Wire into the docs build system
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Looks good.

Let me know if you want me to rebase my docs series on this. I
suspect/hope the conflicts will be trivial...

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  docs/Makefile    |    9 ++++++---
>  docs/xen-headers |   14 ++++++++++++++
>  2 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/Makefile b/docs/Makefile
> index a2bbf2d..413c1a2 100644
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -15,7 +15,8 @@ DOC_MARKDOWN	:= $(wildcard misc/*.markdown)
>  DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
>  DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
>  DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
> -		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN))
> +		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
> +		   html/hypercall/index.html
>  DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
>  		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN))
>  
> @@ -129,13 +130,15 @@ html/%.html: %.markdown
>  	$(MARKDOWN) $< > $@.tmp ; \
>  	$(call move-if-changed,$@.tmp,$@) ; fi
>  
> -html/hypercall/stamp:
> +html/hypercall/index.html: ./xen-headers
> +	rm -rf $(@D)
>  	@$(INSTALL_DIR) $(@D)
>  	./xen-headers -O $(@D) \
>  		-T 'arch-x86_64 - Xen public headers' \
>  		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 \
>  		../xen include/public include/xen/errno.h
> -	touch $@
> +
> +-include html/hypercall/.deps
>  
>  txt/%.txt: %.txt
>  	$(INSTALL_DIR) $(@D)
> diff --git a/docs/xen-headers b/docs/xen-headers
> index dcf673e..8226d73 100755
> --- a/docs/xen-headers
> +++ b/docs/xen-headers
> @@ -325,6 +325,12 @@ END
>  }
>  
>  foreach $pass (qw(1 2)) {
> +    my $depspath = "$outdir/.deps";
> +    my $depsout;
> +    if ($pass==2) {
> +	$depsout = new IO::File "$depspath.new", 'w' or die $!;
> +    }
> +
>      find({ wanted => 
>  	       sub {
>  		   return unless m/\.h$/;
> @@ -341,11 +347,19 @@ foreach $pass (qw(1 2)) {
>  		   $leaf_opath = $leaf;
>  		   $leaf_opath =~ s#/#,#g;
>  		   $leaf_opath .= ".html";
> +		   print $depsout "$outdir/index.html: $File::Find::name\n"
> +		       or die $!
> +		       if $pass==2;
>  		   process_file($File::Find::name, $outdir.'/'.$leaf_opath);
>  	   },
>  	   no_chdir => 1,
>  	 },
>  	 map { "$basedir/$_" } @indirs);
> +
> +    if ($pass==2) {
> +	close $depsout or die $!;
> +	rename "$depspath.new", "$depspath" or die $!;
> +    }
>  }
>  
>  output_index();



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:28:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPbE-0003wv-NB; Tue, 29 Nov 2011 15:28:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVPbD-0003wS-T0
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:28:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322580442!5503120!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28090 invoked from network); 29 Nov 2011 15:27:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:27:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189243"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:27:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:27:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 15:27:22 +0000
In-Reply-To: <1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322580442.31810.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/4] docs/html/: Arrange for automatic build
 of hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> - Use index.html rather than a stamp file.
> - Automatically generate dependencies.
> - Wire into the docs build system
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Looks good.

Let me know if you want me to rebase my docs series on this. I
suspect/hope the conflicts will be trivial...

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  docs/Makefile    |    9 ++++++---
>  docs/xen-headers |   14 ++++++++++++++
>  2 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/Makefile b/docs/Makefile
> index a2bbf2d..413c1a2 100644
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -15,7 +15,8 @@ DOC_MARKDOWN	:= $(wildcard misc/*.markdown)
>  DOC_PS		:= $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX))
>  DOC_PDF		:= $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX))
>  DOC_HTML	:= $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \
> -		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN))
> +		   $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \
> +		   html/hypercall/index.html
>  DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
>  		   $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN))
>  
> @@ -129,13 +130,15 @@ html/%.html: %.markdown
>  	$(MARKDOWN) $< > $@.tmp ; \
>  	$(call move-if-changed,$@.tmp,$@) ; fi
>  
> -html/hypercall/stamp:
> +html/hypercall/index.html: ./xen-headers
> +	rm -rf $(@D)
>  	@$(INSTALL_DIR) $(@D)
>  	./xen-headers -O $(@D) \
>  		-T 'arch-x86_64 - Xen public headers' \
>  		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 \
>  		../xen include/public include/xen/errno.h
> -	touch $@
> +
> +-include html/hypercall/.deps
>  
>  txt/%.txt: %.txt
>  	$(INSTALL_DIR) $(@D)
> diff --git a/docs/xen-headers b/docs/xen-headers
> index dcf673e..8226d73 100755
> --- a/docs/xen-headers
> +++ b/docs/xen-headers
> @@ -325,6 +325,12 @@ END
>  }
>  
>  foreach $pass (qw(1 2)) {
> +    my $depspath = "$outdir/.deps";
> +    my $depsout;
> +    if ($pass==2) {
> +	$depsout = new IO::File "$depspath.new", 'w' or die $!;
> +    }
> +
>      find({ wanted => 
>  	       sub {
>  		   return unless m/\.h$/;
> @@ -341,11 +347,19 @@ foreach $pass (qw(1 2)) {
>  		   $leaf_opath = $leaf;
>  		   $leaf_opath =~ s#/#,#g;
>  		   $leaf_opath .= ".html";
> +		   print $depsout "$outdir/index.html: $File::Find::name\n"
> +		       or die $!
> +		       if $pass==2;
>  		   process_file($File::Find::name, $outdir.'/'.$leaf_opath);
>  	   },
>  	   no_chdir => 1,
>  	 },
>  	 map { "$basedir/$_" } @indirs);
> +
> +    if ($pass==2) {
> +	close $depsout or die $!;
> +	rename "$depspath.new", "$depspath" or die $!;
> +    }
>  }
>  
>  output_index();



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:30:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:30:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPd2-00049G-AV; Tue, 29 Nov 2011 15:29:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPd1-00048S-15
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:29:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322580553!5436905!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30678 invoked from network); 29 Nov 2011 15:29:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:29:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:29:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:29:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPcP-0004A1-EM; Tue, 29 Nov 2011 15:29:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPcP-00089M-BJ;
	Tue, 29 Nov 2011 15:29:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20180.64073.94115.145353@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 15:29:13 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322580022.31810.11.camel@zakaz.uk.xensource.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-3-git-send-email-ian.jackson@eu.citrix.com>
	<1322580022.31810.11.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two
 hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two hypercalls"):
> On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> > This exercise revealed a couple of infelicities:
> >  * In the actual source code, do_mmu_update is defined to return an int
> >    and do_set_trap_table a long.  However both functions return either
> >    -Efoo (on error) or 0 for success.
> 
> Should that be fixed or would that do more harm than good?

I wasn't sure whether I should go through all the hypercalls checking
and perhaps fixing up their return values.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:30:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:30:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPd2-00049G-AV; Tue, 29 Nov 2011 15:29:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPd1-00048S-15
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:29:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322580553!5436905!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30678 invoked from network); 29 Nov 2011 15:29:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:29:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:29:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:29:13 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPcP-0004A1-EM; Tue, 29 Nov 2011 15:29:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPcP-00089M-BJ;
	Tue, 29 Nov 2011 15:29:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20180.64073.94115.145353@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 15:29:13 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322580022.31810.11.camel@zakaz.uk.xensource.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-3-git-send-email-ian.jackson@eu.citrix.com>
	<1322580022.31810.11.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two
 hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two hypercalls"):
> On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> > This exercise revealed a couple of infelicities:
> >  * In the actual source code, do_mmu_update is defined to return an int
> >    and do_set_trap_table a long.  However both functions return either
> >    -Efoo (on error) or 0 for success.
> 
> Should that be fixed or would that do more harm than good?

I wasn't sure whether I should go through all the hypercalls checking
and perhaps fixing up their return values.

> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:34:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:34:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPgr-0004Zr-M6; Tue, 29 Nov 2011 15:33:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVPgq-0004ZP-NU
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:33:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322580791!5403974!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23941 invoked from network); 29 Nov 2011 15:33:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:33:11 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:33:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:33:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 15:33:11 +0000
In-Reply-To: <20180.64073.94115.145353@mariner.uk.xensource.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-3-git-send-email-ian.jackson@eu.citrix.com>
	<1322580022.31810.11.camel@zakaz.uk.xensource.com>
	<20180.64073.94115.145353@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322580791.31810.15.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two
 hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 15:29 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two hypercalls"):
> > On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> > > This exercise revealed a couple of infelicities:
> > >  * In the actual source code, do_mmu_update is defined to return an int
> > >    and do_set_trap_table a long.  However both functions return either
> > >    -Efoo (on error) or 0 for success.
> > 
> > Should that be fixed or would that do more harm than good?
> 
> I wasn't sure whether I should go through all the hypercalls checking
> and perhaps fixing up their return values.

I'd definitely wait for Keir's OK before spending any time on it. Even
then it's likely to be a lot of fiddly work to convince yourself the
change is correct/safe and not an ABI wart we are stuck with...

> 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Thanks,
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:34:14 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:34:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPgr-0004Zr-M6; Tue, 29 Nov 2011 15:33:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVPgq-0004ZP-NU
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:33:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322580791!5403974!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23941 invoked from network); 29 Nov 2011 15:33:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:33:11 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:33:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 29 Nov 2011 15:33:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 15:33:11 +0000
In-Reply-To: <20180.64073.94115.145353@mariner.uk.xensource.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-3-git-send-email-ian.jackson@eu.citrix.com>
	<1322580022.31810.11.camel@zakaz.uk.xensource.com>
	<20180.64073.94115.145353@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322580791.31810.15.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two
 hypercalls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2011-11-29 at 15:29 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 2/4] docs/html/: Annotations for two hypercalls"):
> > On Tue, 2011-11-29 at 15:01 +0000, Ian Jackson wrote:
> > > This exercise revealed a couple of infelicities:
> > >  * In the actual source code, do_mmu_update is defined to return an int
> > >    and do_set_trap_table a long.  However both functions return either
> > >    -Efoo (on error) or 0 for success.
> > 
> > Should that be fixed or would that do more harm than good?
> 
> I wasn't sure whether I should go through all the hypercalls checking
> and perhaps fixing up their return values.

I'd definitely wait for Keir's OK before spending any time on it. Even
then it's likely to be a lot of fiddly work to convince yourself the
change is correct/safe and not an ABI wart we are stuck with...

> 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Thanks,
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:35:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:35:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPiB-0004hA-5W; Tue, 29 Nov 2011 15:35:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVPi9-0004gT-Jh
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:35:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322580870!5486636!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDE1OTgw\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15877 invoked from network); 29 Nov 2011 15:34:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 15:34:32 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pATFXaAB031697
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 29 Nov 2011 15:33:37 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
	pATFXXbE027501
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 29 Nov 2011 15:33:33 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pATFXQwb030186; Tue, 29 Nov 2011 09:33:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 29 Nov 2011 07:33:26 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id AD61B41C16;
	Tue, 29 Nov 2011 10:33:07 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pATFX6aU012495;
	Tue, 29 Nov 2011 10:33:06 -0500
Date: Tue, 29 Nov 2011 10:33:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111129153306.GA30908@phenom.dumpdata.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
	<20111128164516.GA26664@phenom.dumpdata.com>
	<1322562199.20646.30.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322562199.20646.30.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4ED4FB52.0006,ss=2,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 10:23:18AM +0000, Ian Campbell wrote:
> On Mon, 2011-11-28 at 16:45 +0000, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 28, 2011 at 03:40:13PM +0000, Ian Campbell wrote:
> > > On Mon, 2011-11-28 at 15:28 +0000, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:
> > > 
> > > > > I looked through my old mails from you and you explained already the necessity of double
> > > > > bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
> > > > > Xenified kernel not have this kind of issue?
> > > > 
> > > > That is a puzzle. It should not. The code is very much the same - both
> > > > use the generic SWIOTLB which has not changed for years.
> > > 
> > > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > > mainline Linux, it's been heavily refactored for one thing. It's not
> > > impossible that mainline is bouncing something it doesn't really need
> > > to.
> > 
> > The usage, at least with 'pci_alloc_coherent' is that there is no bouncing
> > being done. The alloc_coherent will allocate a nice page, underneath the 4GB
> > mark and give it to the driver. The driver can use it as it wishes and there
> > is no need to bounce buffer.
> 
> Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
> subset of swiotlb is in use then, all the bouncing stuff _should_ be
> idle/unused -- but has that been confirmed?

Nope. I hope that the diagnostic patch I have in mind will prove/disprove that.
Now I just need to find a moment to write it :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:35:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:35:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPiB-0004hA-5W; Tue, 29 Nov 2011 15:35:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVPi9-0004gT-Jh
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:35:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322580870!5486636!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDE1OTgw\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15877 invoked from network); 29 Nov 2011 15:34:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 15:34:32 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pATFXaAB031697
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 29 Nov 2011 15:33:37 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
	pATFXXbE027501
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 29 Nov 2011 15:33:33 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pATFXQwb030186; Tue, 29 Nov 2011 09:33:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 29 Nov 2011 07:33:26 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id AD61B41C16;
	Tue, 29 Nov 2011 10:33:07 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pATFX6aU012495;
	Tue, 29 Nov 2011 10:33:06 -0500
Date: Tue, 29 Nov 2011 10:33:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20111129153306.GA30908@phenom.dumpdata.com>
References: <zarafa.4ece387c.6e85.6aa0c9ca21e63bd9@uhura.space.zz>
	<zarafa.4ed012ab.3c16.45021173211daab7@uhura.space.zz>
	<20111128152829.GC9655@andromeda.dapyr.net>
	<1322494816.20646.14.camel@zakaz.uk.xensource.com>
	<20111128164516.GA26664@phenom.dumpdata.com>
	<1322562199.20646.30.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322562199.20646.30.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4ED4FB52.0006,ss=2,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Carsten Schiers <carsten@schiers.de>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 10:23:18AM +0000, Ian Campbell wrote:
> On Mon, 2011-11-28 at 16:45 +0000, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 28, 2011 at 03:40:13PM +0000, Ian Campbell wrote:
> > > On Mon, 2011-11-28 at 15:28 +0000, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Nov 25, 2011 at 11:11:55PM +0100, Carsten Schiers wrote:
> > > 
> > > > > I looked through my old mails from you and you explained already the necessity of double
> > > > > bounce buffering (PCI->below 4GB->above 4GB). What I don't understand is: why does the
> > > > > Xenified kernel not have this kind of issue?
> > > > 
> > > > That is a puzzle. It should not. The code is very much the same - both
> > > > use the generic SWIOTLB which has not changed for years.
> > > 
> > > The swiotlb-xen used by classic-xen kernels (which I assume is what
> > > Carsten means by "Xenified") isn't exactly the same as the stuff in
> > > mainline Linux, it's been heavily refactored for one thing. It's not
> > > impossible that mainline is bouncing something it doesn't really need
> > > to.
> > 
> > The usage, at least with 'pci_alloc_coherent' is that there is no bouncing
> > being done. The alloc_coherent will allocate a nice page, underneath the 4GB
> > mark and give it to the driver. The driver can use it as it wishes and there
> > is no need to bounce buffer.
> 
> Oh, I didn't realise dma_alloc_coherent was part of swiotlb now. Only a
> subset of swiotlb is in use then, all the bouncing stuff _should_ be
> idle/unused -- but has that been confirmed?

Nope. I hope that the diagnostic patch I have in mind will prove/disprove that.
Now I just need to find a moment to write it :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:50:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPx2-0005Hn-3k; Tue, 29 Nov 2011 15:50:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPx0-0005HX-6S
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:50:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322581792!5162939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5251 invoked from network); 29 Nov 2011 15:49:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:49:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:49:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:49:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPwO-0004Gu-3p; Tue, 29 Nov 2011 15:49:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPwO-0008R1-2v;
	Tue, 29 Nov 2011 15:49:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20180.65312.30358.73788@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 15:49:52 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322580442.31810.14.camel@zakaz.uk.xensource.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
	<1322580442.31810.14.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/4] docs/html/: Arrange for automatic build
 of hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 4/4] docs/html/: Arrange for automatic build of hypercall docs"):
> Let me know if you want me to rebase my docs series on this. I
> suspect/hope the conflicts will be trivial...

There was one trivial conflict.  Thanks for the acks, both series are
now in staging.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 15:50:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 15:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVPx2-0005Hn-3k; Tue, 29 Nov 2011 15:50:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVPx0-0005HX-6S
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 15:50:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322581792!5162939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5251 invoked from network); 29 Nov 2011 15:49:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 15:49:52 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9189863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:49:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 15:49:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVPwO-0004Gu-3p; Tue, 29 Nov 2011 15:49:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVPwO-0008R1-2v;
	Tue, 29 Nov 2011 15:49:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20180.65312.30358.73788@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 15:49:52 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322580442.31810.14.camel@zakaz.uk.xensource.com>
References: <1322578893-9998-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322578893-9998-5-git-send-email-ian.jackson@eu.citrix.com>
	<1322580442.31810.14.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 4/4] docs/html/: Arrange for automatic build
 of hypercall docs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 4/4] docs/html/: Arrange for automatic build of hypercall docs"):
> Let me know if you want me to rebase my docs series on this. I
> suspect/hope the conflicts will be trivial...

There was one trivial conflict.  Thanks for the acks, both series are
now in staging.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 16:06:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 16:06:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVQBk-00060N-Ql; Tue, 29 Nov 2011 16:05:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVQBj-000607-80
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 16:05:43 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322582705!6106688!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31311 invoked from network); 29 Nov 2011 16:05:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 16:05:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9190297"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 16:05:05 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 29 Nov 2011
	16:05:05 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 16:05:10 +0000
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
	package called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIA=
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4F32@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<ac68bd6d4853fdde5a24.1322563999@cosworth.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724D625B9C@FTLPMAILBOX02.citrite.net>
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724D625B9C@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ross Philipson
[snip]
> 
> Paul, perhaps a different _HID might be better. Per the 3.0 spec,
> ACPI0001 is for SMBus host controller device; this might lead to
> some confusion for an OSPM. Maybe one of the generic PNP device IDs
> or perhaps we need a manufacturer ID for Xen?
> 

I have no problem choosing a different _HID. I just don't have a good reference for what name is not going to clash with something else. Looks like ACPI0001 was a bad guess. Any better suggestions? What are the 'generic PNP device IDs'?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 16:06:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 16:06:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVQBk-00060N-Ql; Tue, 29 Nov 2011 16:05:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVQBj-000607-80
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 16:05:43 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322582705!6106688!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31311 invoked from network); 29 Nov 2011 16:05:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 16:05:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9190297"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 16:05:05 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 29 Nov 2011
	16:05:05 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ross Philipson <Ross.Philipson@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 16:05:10 +0000
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
	package called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIA=
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4F32@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<ac68bd6d4853fdde5a24.1322563999@cosworth.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724D625B9C@FTLPMAILBOX02.citrite.net>
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724D625B9C@FTLPMAILBOX02.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ross Philipson
[snip]
> 
> Paul, perhaps a different _HID might be better. Per the 3.0 spec,
> ACPI0001 is for SMBus host controller device; this might lead to
> some confusion for an OSPM. Maybe one of the generic PNP device IDs
> or perhaps we need a manufacturer ID for Xen?
> 

I have no problem choosing a different _HID. I just don't have a good reference for what name is not going to clash with something else. Looks like ACPI0001 was a bad guess. Any better suggestions? What are the 'generic PNP device IDs'?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 16:12:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 16:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVQHY-0006EB-Lf; Tue, 29 Nov 2011 16:11:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVQHX-0006Dc-03
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 16:11:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322583064!5506985!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21601 invoked from network); 29 Nov 2011 16:11:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 16:11:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19493561"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 11:11:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 11:11:03 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATGB2Em018389;	Tue, 29 Nov 2011 08:11:02 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6d7f38a5b664d893d0b0c75e4845ff4c42a183b9
Message-ID: <6d7f38a5b664d893d0b0.1322583061@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 16:11:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH DOCDAY] docs: improve index.html generation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322583040 0
# Node ID 6d7f38a5b664d893d0b0c75e4845ff4c42a183b9
# Parent  b264a2618f6cb3cdf67b1a786fa14193fcccb8e6
docs: improve index.html generation

Include hypercall documentation, fixing link generation for top level links to
use the INDEX.

Allow subsection links to be renamedi in the INDEX too.

Strip .txt suffixes as well as .html ones by moving the regex to the right
place instead of placing the literal text "(?:html|txt)" into the backlink to
the top level page. (oops)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b264a2618f6c -r 6d7f38a5b664 docs/INDEX
--- a/docs/INDEX	Tue Nov 29 15:48:08 2011 +0000
+++ b/docs/INDEX	Tue Nov 29 16:10:40 2011 +0000
@@ -1,6 +1,10 @@
+hypercall/index			Hypercall Interfaces
+
+man				Man Pages
+
+misc				Miscellaneous Documentation
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
-
-misc/console.txt		Xen PV Console notes
+misc/console			Xen PV Console notes
 
 # These are not all that useful anymore, hide them from the index
 reference/interface/index	NO-INDEX
diff -r b264a2618f6c -r 6d7f38a5b664 docs/gen-html-index
--- a/docs/gen-html-index	Tue Nov 29 15:48:08 2011 +0000
+++ b/docs/gen-html-index	Tue Nov 29 16:10:40 2011 +0000
@@ -45,7 +45,7 @@ sub make_page ($$$) {
     }
     else
     {
-        $h1 = "<a href=\"../index.(?:html|txt)\">Xen Documentation</a> - $title";
+        $h1 = "<a href=\"../index.html\">Xen Documentation</a> - $title";
         $title = "Xen Documentation - $title";
     }
     $o .= <<END;
@@ -63,7 +63,7 @@ END
 sub make_linktext ($) {
     my ($l) = @_;
     return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
-    $l =~ s/.(html)$//g;
+    $l =~ s/.(?:html|txt)$//g;
     return $index{$l} if exists $index{$l};
     return basename($l);
 }
@@ -109,13 +109,14 @@ foreach my $od (sort { $a cmp $b } uniq 
     my @d = (grep /^\Q$od\E/, @docs);
     if ( @d == 1 and $d[0] eq "$od/index.html" )
     {
-        $top .= "<li><a href=\"${od}/index.html\">${od}/index.html</a></li>\n";
+        $top .= make_link("$od/index.html", 0);
     }
     else
     {
 	my $links = make_links($od,0,@d);
+	my $secttitle = make_linktext($od);
 	$top .= <<END;
-<li><a href=\"${od}/index.html\">$od</a></li>
+<li><a href=\"${od}/index.html\">$secttitle</a></li>
 <ul>
 $links
 </ul>
@@ -124,12 +125,12 @@ END
 	$links = make_links($od,1,@d);
         my $idx = '';
 	$idx .= <<END;
-<li>$od</li>
+<li>$secttitle</li>
 <ul>
 $links
 </ul>
 END
-        make_page("$outdir/$od/index.html", $od, $idx);
+        make_page("$outdir/$od/index.html", $secttitle, $idx);
     }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 16:12:04 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 16:12:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVQHY-0006EB-Lf; Tue, 29 Nov 2011 16:11:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVQHX-0006Dc-03
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 16:11:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322583064!5506985!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21601 invoked from network); 29 Nov 2011 16:11:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 16:11:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19493561"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 11:11:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 11:11:03 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	pATGB2Em018389;	Tue, 29 Nov 2011 08:11:02 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6d7f38a5b664d893d0b0c75e4845ff4c42a183b9
Message-ID: <6d7f38a5b664d893d0b0.1322583061@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 29 Nov 2011 16:11:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH DOCDAY] docs: improve index.html generation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1322583040 0
# Node ID 6d7f38a5b664d893d0b0c75e4845ff4c42a183b9
# Parent  b264a2618f6cb3cdf67b1a786fa14193fcccb8e6
docs: improve index.html generation

Include hypercall documentation, fixing link generation for top level links to
use the INDEX.

Allow subsection links to be renamedi in the INDEX too.

Strip .txt suffixes as well as .html ones by moving the regex to the right
place instead of placing the literal text "(?:html|txt)" into the backlink to
the top level page. (oops)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b264a2618f6c -r 6d7f38a5b664 docs/INDEX
--- a/docs/INDEX	Tue Nov 29 15:48:08 2011 +0000
+++ b/docs/INDEX	Tue Nov 29 16:10:40 2011 +0000
@@ -1,6 +1,10 @@
+hypercall/index			Hypercall Interfaces
+
+man				Man Pages
+
+misc				Miscellaneous Documentation
 misc/hvm-emulated-unplug	Xen HVM emulated device unplug protocol
-
-misc/console.txt		Xen PV Console notes
+misc/console			Xen PV Console notes
 
 # These are not all that useful anymore, hide them from the index
 reference/interface/index	NO-INDEX
diff -r b264a2618f6c -r 6d7f38a5b664 docs/gen-html-index
--- a/docs/gen-html-index	Tue Nov 29 15:48:08 2011 +0000
+++ b/docs/gen-html-index	Tue Nov 29 16:10:40 2011 +0000
@@ -45,7 +45,7 @@ sub make_page ($$$) {
     }
     else
     {
-        $h1 = "<a href=\"../index.(?:html|txt)\">Xen Documentation</a> - $title";
+        $h1 = "<a href=\"../index.html\">Xen Documentation</a> - $title";
         $title = "Xen Documentation - $title";
     }
     $o .= <<END;
@@ -63,7 +63,7 @@ END
 sub make_linktext ($) {
     my ($l) = @_;
     return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
-    $l =~ s/.(html)$//g;
+    $l =~ s/.(?:html|txt)$//g;
     return $index{$l} if exists $index{$l};
     return basename($l);
 }
@@ -109,13 +109,14 @@ foreach my $od (sort { $a cmp $b } uniq 
     my @d = (grep /^\Q$od\E/, @docs);
     if ( @d == 1 and $d[0] eq "$od/index.html" )
     {
-        $top .= "<li><a href=\"${od}/index.html\">${od}/index.html</a></li>\n";
+        $top .= make_link("$od/index.html", 0);
     }
     else
     {
 	my $links = make_links($od,0,@d);
+	my $secttitle = make_linktext($od);
 	$top .= <<END;
-<li><a href=\"${od}/index.html\">$od</a></li>
+<li><a href=\"${od}/index.html\">$secttitle</a></li>
 <ul>
 $links
 </ul>
@@ -124,12 +125,12 @@ END
 	$links = make_links($od,1,@d);
         my $idx = '';
 	$idx .= <<END;
-<li>$od</li>
+<li>$secttitle</li>
 <ul>
 $links
 </ul>
 END
-        make_page("$outdir/$od/index.html", $od, $idx);
+        make_page("$outdir/$od/index.html", $secttitle, $idx);
     }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 16:25:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 16:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVQUW-0006Px-1T; Tue, 29 Nov 2011 16:25:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVQUT-0006Ps-UU
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 16:25:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322583868!3565754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8782 invoked from network); 29 Nov 2011 16:24:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 16:24:28 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9190744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 16:24:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 16:24:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVQTr-0004TD-S3; Tue, 29 Nov 2011 16:24:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVQTr-0008TN-RB;
	Tue, 29 Nov 2011 16:24:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20181.1851.830286.417692@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 16:24:27 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <6d7f38a5b664d893d0b0.1322583061@cosworth.uk.xensource.com>
References: <6d7f38a5b664d893d0b0.1322583061@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH DOCDAY] docs: improve index.html generation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH DOCDAY] docs: improve index.html generation"):
> docs: improve index.html generation

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 16:25:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 16:25:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVQUW-0006Px-1T; Tue, 29 Nov 2011 16:25:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVQUT-0006Ps-UU
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 16:25:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322583868!3565754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8782 invoked from network); 29 Nov 2011 16:24:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 16:24:28 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9190744"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 16:24:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 16:24:28 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVQTr-0004TD-S3; Tue, 29 Nov 2011 16:24:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVQTr-0008TN-RB;
	Tue, 29 Nov 2011 16:24:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20181.1851.830286.417692@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 16:24:27 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <6d7f38a5b664d893d0b0.1322583061@cosworth.uk.xensource.com>
References: <6d7f38a5b664d893d0b0.1322583061@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH DOCDAY] docs: improve index.html generation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH DOCDAY] docs: improve index.html generation"):
> docs: improve index.html generation

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 16:30:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 16:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVQZS-0006Yr-QI; Tue, 29 Nov 2011 16:30:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RVQZR-0006YX-9I
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 16:30:13 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322584174!5495590!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20376 invoked from network); 29 Nov 2011 16:29:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 16:29:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19494171"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 11:29:34 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 29 Nov 2011
	11:29:34 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 11:29:35 -0500
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
	package called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIAAAJ5LcA==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724D625BD3@FTLPMAILBOX02.citrite.net>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<ac68bd6d4853fdde5a24.1322563999@cosworth.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724D625B9C@FTLPMAILBOX02.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5988E4F32@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4F32@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Paul Durrant
> Sent: Tuesday, November 29, 2011 11:05 AM
> To: Ross Philipson; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> package called ADDR, evaluating to two
> 
> > -----Original Message-----
> > From: Ross Philipson
> [snip]
> >
> > Paul, perhaps a different _HID might be better. Per the 3.0 spec,
> > ACPI0001 is for SMBus host controller device; this might lead to some
> > confusion for an OSPM. Maybe one of the generic PNP device IDs or
> > perhaps we need a manufacturer ID for Xen?
> >
> 
> I have no problem choosing a different _HID. I just don't have a good
> reference for what name is not going to clash with something else. Looks
> like ACPI0001 was a bad guess. Any better suggestions? What are the
> 'generic PNP device IDs'?
> 
>   Paul

Well I actually brought it up as a discussion point. I have the same sort of issue - I have a generic device for a virtualized environment. I don't really want it to be recognized as anything specific. I guess I see three options:

 - Use an unassigned APCIXXXX string. I believe the _HID string values of the form "ACPIXXXX" are defined by the ACPI specs themselves so this may not work in the long run.
 - Use one of the predefined generic container EisaId PNP values. By that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at the Linux generic container driver, it doesn't do very much with these devices so that might be OK.
 - Acquire a vendor specific EisaId range for Xen (e.g. EisaId(XENABCD)). Then we could carve up the product number part of the ID as we see fit.

Anyway, just some ideas.

Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 16:30:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 16:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVQZS-0006Yr-QI; Tue, 29 Nov 2011 16:30:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RVQZR-0006YX-9I
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 16:30:13 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322584174!5495590!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20376 invoked from network); 29 Nov 2011 16:29:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 16:29:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315195200"; d="scan'208";a="19494171"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 11:29:34 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX02.citrite.net ([10.13.107.66]) with mapi; Tue, 29 Nov 2011
	11:29:34 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 11:29:35 -0500
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
	package called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIAAAJ5LcA==
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724D625BD3@FTLPMAILBOX02.citrite.net>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<ac68bd6d4853fdde5a24.1322563999@cosworth.uk.xensource.com>
	<831D55AF5A11D64C9B4B43F59EEBF720724D625B9C@FTLPMAILBOX02.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5988E4F32@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4F32@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Paul Durrant
> Sent: Tuesday, November 29, 2011 11:05 AM
> To: Ross Philipson; xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> package called ADDR, evaluating to two
> 
> > -----Original Message-----
> > From: Ross Philipson
> [snip]
> >
> > Paul, perhaps a different _HID might be better. Per the 3.0 spec,
> > ACPI0001 is for SMBus host controller device; this might lead to some
> > confusion for an OSPM. Maybe one of the generic PNP device IDs or
> > perhaps we need a manufacturer ID for Xen?
> >
> 
> I have no problem choosing a different _HID. I just don't have a good
> reference for what name is not going to clash with something else. Looks
> like ACPI0001 was a bad guess. Any better suggestions? What are the
> 'generic PNP device IDs'?
> 
>   Paul

Well I actually brought it up as a discussion point. I have the same sort of issue - I have a generic device for a virtualized environment. I don't really want it to be recognized as anything specific. I guess I see three options:

 - Use an unassigned APCIXXXX string. I believe the _HID string values of the form "ACPIXXXX" are defined by the ACPI specs themselves so this may not work in the long run.
 - Use one of the predefined generic container EisaId PNP values. By that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at the Linux generic container driver, it doesn't do very much with these devices so that might be OK.
 - Acquire a vendor specific EisaId range for Xen (e.g. EisaId(XENABCD)). Then we could carve up the product number part of the ID as we see fit.

Anyway, just some ideas.

Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 16:35:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 16:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVQdw-0006m2-J9; Tue, 29 Nov 2011 16:34:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVQdv-0006ll-9d
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 16:34:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322584453!3524547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28088 invoked from network); 29 Nov 2011 16:34:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 16:34:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9190985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 16:34:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 16:34:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVQdI-0004WT-K3; Tue, 29 Nov 2011 16:34:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVQdI-0008Ut-JH;
	Tue, 29 Nov 2011 16:34:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20181.2436.299217.351814@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 16:34:12 +0000
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a930b4cd-e6df-44de-9907-1f9149bd4ccc@default>
References: <20171.55835.240381.351382@mariner.uk.xensource.com>
	<20174.36841.738985.984736@mariner.uk.xensource.com>
	<a930b4cd-e6df-44de-9907-1f9149bd4ccc@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dan Magenheimer writes ("Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness"):
> Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > I think functions with prototypes like
> >      f(int len, char *buf)
> > should take buf[len], not buf[len+1].
> 
> FWIW, I agree completely.  I didn't write this code from
> scratch, I heavily leveraged it from elsewhere (don't
> recall exactly where, maybe xentop?).
>
> If necessary, I will rewrite the callers and API but
> I was just trying to fix an annoying bug expeditiously.
> Let me know if you won't accept it as the one-line
> ugly fix.

I really don't want to make this worse.  Previously the function would
not write past len.  So sorry, would you mind fixing the callers ?

Also if you "leveraged" this code perhaps it should be combined or the
original one fixed or something ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 16:35:19 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 16:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVQdw-0006m2-J9; Tue, 29 Nov 2011 16:34:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVQdv-0006ll-9d
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 16:34:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1322584453!3524547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28088 invoked from network); 29 Nov 2011 16:34:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 16:34:13 -0000
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; 
   d="scan'208";a="9190985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 16:34:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 16:34:12 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVQdI-0004WT-K3; Tue, 29 Nov 2011 16:34:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVQdI-0008Ut-JH;
	Tue, 29 Nov 2011 16:34:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20181.2436.299217.351814@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 16:34:12 +0000
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a930b4cd-e6df-44de-9907-1f9149bd4ccc@default>
References: <20171.55835.240381.351382@mariner.uk.xensource.com>
	<20174.36841.738985.984736@mariner.uk.xensource.com>
	<a930b4cd-e6df-44de-9907-1f9149bd4ccc@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix
 output ugliness
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dan Magenheimer writes ("Re: [Xen-devel] [PATCH] tools: misc: xen-tmem-list-parse: fix output ugliness"):
> Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> > I think functions with prototypes like
> >      f(int len, char *buf)
> > should take buf[len], not buf[len+1].
> 
> FWIW, I agree completely.  I didn't write this code from
> scratch, I heavily leveraged it from elsewhere (don't
> recall exactly where, maybe xentop?).
>
> If necessary, I will rewrite the callers and API but
> I was just trying to fix an annoying bug expeditiously.
> Let me know if you won't accept it as the one-line
> ugly fix.

I really don't want to make this worse.  Previously the function would
not write past len.  So sorry, would you mind fixing the callers ?

Also if you "leveraged" this code perhaps it should be combined or the
original one fixed or something ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:01:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVR3F-00079O-0k; Tue, 29 Nov 2011 17:01:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <brendan@cs.ubc.ca>) id 1RVR3C-00079D-FR
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:00:58 +0000
X-Env-Sender: brendan@cs.ubc.ca
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322586020!5165777!1
X-Originating-IP: [198.162.52.244]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32290 invoked from network); 29 Nov 2011 17:00:20 -0000
Received: from unknown (HELO servant.int.convergent.io) (198.162.52.244)
	by server-11.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 17:00:20 -0000
Received: from paraiba (paraiba.int.convergent.io [192.168.0.104])
	by servant.int.convergent.io (Postfix) with ESMTP id 71ACF2032E;
	Tue, 29 Nov 2011 08:59:46 -0800 (PST)
Received: by paraiba (Postfix, from userid 1002)
	id 1C4CA1AE05D0; Tue, 29 Nov 2011 08:59:43 -0800 (PST)
Date: Tue, 29 Nov 2011 08:59:43 -0800
From: Brendan Cully <brendan@cs.ubc.ca>
To: rshriram@cs.ubc.ca
Message-ID: <20111129165942.GA26785@localhost.localdomain>
Mail-Followup-To: rshriram@cs.ubc.ca, xen-devel@lists.xensource.com,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com
References: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
X-Operating-System: Linux 3.0.0-12-generic x86_64
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 3 V7] libxc: checkpoint compression
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Monday, 14 November 2011 at 14:51, rshriram@cs.ubc.ca wrote:
> This patch series adds checkpoint compression functionality, while
> running under Remus.
> 
> Changes since last version:
> 1. renamed page_aligned_alloc to xc_memalign and declare it as a global
>    function in xenctrl.h, instead of declaring it in xc_private.h

Acked-by: Brendan Cully <brendan@cs.ubc.ca>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:01:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVR3F-00079O-0k; Tue, 29 Nov 2011 17:01:01 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <brendan@cs.ubc.ca>) id 1RVR3C-00079D-FR
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:00:58 +0000
X-Env-Sender: brendan@cs.ubc.ca
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322586020!5165777!1
X-Originating-IP: [198.162.52.244]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32290 invoked from network); 29 Nov 2011 17:00:20 -0000
Received: from unknown (HELO servant.int.convergent.io) (198.162.52.244)
	by server-11.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 17:00:20 -0000
Received: from paraiba (paraiba.int.convergent.io [192.168.0.104])
	by servant.int.convergent.io (Postfix) with ESMTP id 71ACF2032E;
	Tue, 29 Nov 2011 08:59:46 -0800 (PST)
Received: by paraiba (Postfix, from userid 1002)
	id 1C4CA1AE05D0; Tue, 29 Nov 2011 08:59:43 -0800 (PST)
Date: Tue, 29 Nov 2011 08:59:43 -0800
From: Brendan Cully <brendan@cs.ubc.ca>
To: rshriram@cs.ubc.ca
Message-ID: <20111129165942.GA26785@localhost.localdomain>
Mail-Followup-To: rshriram@cs.ubc.ca, xen-devel@lists.xensource.com,
	ian.jackson@eu.citrix.com, ian.campbell@citrix.com
References: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1321311101@athos.nss.cs.ubc.ca>
X-Operating-System: Linux 3.0.0-12-generic x86_64
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 3 V7] libxc: checkpoint compression
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Monday, 14 November 2011 at 14:51, rshriram@cs.ubc.ca wrote:
> This patch series adds checkpoint compression functionality, while
> running under Remus.
> 
> Changes since last version:
> 1. renamed page_aligned_alloc to xc_memalign and declare it as a global
>    function in xenctrl.h, instead of declaring it in xc_private.h

Acked-by: Brendan Cully <brendan@cs.ubc.ca>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:05:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVR7G-0007NM-QT; Tue, 29 Nov 2011 17:05:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RVR7E-0007Mu-Vr
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:05:09 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322586269!5517192!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 870 invoked from network); 29 Nov 2011 17:04:30 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:04:30 -0000
Received: by qyk29 with SMTP id 29so3467744qyk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 09:04:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=68XkG7zLLAwL1B4nOjDFn9AFgmx7faDyVotfKQrDhLI=;
	b=e1O5ir8HRss4+GhK2owG0DxDm0AZXhTbWEz6d2f1Qasw/DsxY9YIKTsOMeOVhrZE6O
	9WXkEvymY0rZXROZVfZQ==
Received: by 10.229.67.16 with SMTP id p16mr54064qci.47.1322586268865;
	Tue, 29 Nov 2011 09:04:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.67.16 with SMTP id p16mr54047qci.47.1322586268578; Tue, 29
	Nov 2011 09:04:28 -0800 (PST)
Received: by 10.229.137.72 with HTTP; Tue, 29 Nov 2011 09:04:28 -0800 (PST)
In-Reply-To: <20111129142149.GE2822@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
Date: Tue, 29 Nov 2011 09:04:28 -0800
Message-ID: <CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Amit Shah <amit.shah@redhat.com>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Amit,
We aren't using either QEMU or kvmtool, but we are using KVM. =A0All
theissues we are seeing happen when we try to establish multiple
virtioconsoles at boot time. =A0The command line isn't relevant, but I
cantell you the protocol that's passing between the host (kvm) and
theguest (see the end of this message).
We do go through the control_work_handler(), but it's not
providingsynchronization. =A0Here's a trace of the
control_work_handler() andhandle_control_message() calls; note that
there are two concurrentcalls to control_work_handler().
I decorated control_work_handler() with a "lifetime" marker,=A0and
passedthis value to handle_control_message(), so we can see which
control
messages are being handled from which instance of
thecontrol_work_handler() thread.
Notice that we enter control_work_handler() a second time before
thehandling of the second PORT_ADD message is complete. The
firstCONSOLE_PORT message is handled by the second
control_work_handler()call, but the second is handled by the first
control_work_handler() call.

root@myubuntu:~# dmesg | grep MBH[3371055.808738]
control_work_handler #1[3371055.809372] + #1 handle_control_message
PORT_ADD[3371055.810169] - handle_control_message
PORT_ADD[3371055.810170] + #1 handle_control_message PORT_ADD
[3371055.810244] =A0control_work_handler #2[3371055.810245] + #2
handle_control_message CONSOLE_PORT[3371055.810246] =A0got
hvc_ports_mutex[3371055.810578] - handle_control_message
PORT_ADD[3371055.810579] + #1 handle_control_message
CONSOLE_PORT[3371055.810580] =A0trylock of hvc_ports_mutex
failed[3371055.811352] =A0got hvc_ports_mutex[3371055.811370] -
handle_control_message CONSOLE_PORT[3371055.816609] -
handle_control_message CONSOLE_PORT=A0=A0So, I'm guessing the bug is that
there shouldn't be two instances ofcontrol_work_handler() running
simultaneously?
Thanks,
Miche

Protocol:We set up the virtio console device registers during
initialization,specifying the multiport feature, and some number of
ports, n, where nis greater than 1.
In the guest, virtcons_probe() finds our device, and successfully
sendsthe VIRTIO_CONSOLE_DEVICE_READY=3D1 control message.
On the host, we receive the VIRTIO_CONSOLE_DEVICE_READY message,
andsend one VIRTIO_CONSOLE_PORT_ADD message via the Receive Control
queuefor each port in the number of ports. =A0These messages are
notserialized: they are all sent at once.
The VIRTIO_CONSOLE_PORT_ADD messages are received
inhandle_control_message() in virtio_console.c, and add_port() is
calledfor each. =A0After each port is added, the guest
sendsVIRTIO_CONSOLE_PORT_READY to the host, and in these messages, the
idof the port is included in the message.
On the host, in response to each VIRTIO_CONSOLE_PORT_READY=3D1
message,we may send a VIRTIO_CONSOLE_CONSOLE_PORT message.
On the guest, in response to each VIRTIO_CONSOLE_CONSOLE_PORT
message,init_port_console() is called on the individual port. =A0The
same id isused for these messages as was used for the PORT_READY
messages.
After each successful init_port_console(), the guest
sendsVIRTIO_CONSOLE_PORT_OPEN back to the host.

On Tue, Nov 29, 2011 at 6:21 AM, Amit Shah <amit.shah@redhat.com> wrote:
> Hi,
>
> On (Mon) 28 Nov 2011 [15:40:41], Miche Baker-Harvey wrote:
>> Amit,
>>
>> You said that the work would be serialized "due to port additions
>> being on work items on the same workqueue". =A0I'm not seeing that.
>
> You leave a lot of questions unanswered. =A0What's your environment?
> Are you hot-plugging ports? =A0Are you using qemu? =A0What's your command
> line?
>
>> I've double checked this by using a mutex_trylock in
>> hvc_console::hvc_alloc(), and here's the relevant output from dmesg:
>>
>> root@myubuntu:~# dmesg | grep MBH
>> [3307216.210274] MBH: got hvc_ports_mutex
>> [3307216.210690] MBH: trylock of hvc_ports_mutex failed
>> [3307216.211143] MBH: got hvc_ports_mutex
>>
>> This is in a system with two virtio console ports, each of which is a
>> console. =A0I think if the VIRTIO_CONSOLE_CONSOLE_PORT message handling
>> were actually being serialized, the trylock should never fail.
>
> Agreed.
>
>> What's the source of the serialization for the workqueue items? =A0At
>> first reading it looks like the control_work_handler gets called for
>> each virtio interrupt?
>
> It all depends on how you add ports. =A0If you're using qemu, they
> happen via the control work handler.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:05:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVR7G-0007NM-QT; Tue, 29 Nov 2011 17:05:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RVR7E-0007Mu-Vr
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:05:09 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322586269!5517192!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 870 invoked from network); 29 Nov 2011 17:04:30 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:04:30 -0000
Received: by qyk29 with SMTP id 29so3467744qyk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 09:04:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding:x-system-of-record;
	bh=68XkG7zLLAwL1B4nOjDFn9AFgmx7faDyVotfKQrDhLI=;
	b=e1O5ir8HRss4+GhK2owG0DxDm0AZXhTbWEz6d2f1Qasw/DsxY9YIKTsOMeOVhrZE6O
	9WXkEvymY0rZXROZVfZQ==
Received: by 10.229.67.16 with SMTP id p16mr54064qci.47.1322586268865;
	Tue, 29 Nov 2011 09:04:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.67.16 with SMTP id p16mr54047qci.47.1322586268578; Tue, 29
	Nov 2011 09:04:28 -0800 (PST)
Received: by 10.229.137.72 with HTTP; Tue, 29 Nov 2011 09:04:28 -0800 (PST)
In-Reply-To: <20111129142149.GE2822@amit-x200.redhat.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
Date: Tue, 29 Nov 2011 09:04:28 -0800
Message-ID: <CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Amit Shah <amit.shah@redhat.com>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Amit,
We aren't using either QEMU or kvmtool, but we are using KVM. =A0All
theissues we are seeing happen when we try to establish multiple
virtioconsoles at boot time. =A0The command line isn't relevant, but I
cantell you the protocol that's passing between the host (kvm) and
theguest (see the end of this message).
We do go through the control_work_handler(), but it's not
providingsynchronization. =A0Here's a trace of the
control_work_handler() andhandle_control_message() calls; note that
there are two concurrentcalls to control_work_handler().
I decorated control_work_handler() with a "lifetime" marker,=A0and
passedthis value to handle_control_message(), so we can see which
control
messages are being handled from which instance of
thecontrol_work_handler() thread.
Notice that we enter control_work_handler() a second time before
thehandling of the second PORT_ADD message is complete. The
firstCONSOLE_PORT message is handled by the second
control_work_handler()call, but the second is handled by the first
control_work_handler() call.

root@myubuntu:~# dmesg | grep MBH[3371055.808738]
control_work_handler #1[3371055.809372] + #1 handle_control_message
PORT_ADD[3371055.810169] - handle_control_message
PORT_ADD[3371055.810170] + #1 handle_control_message PORT_ADD
[3371055.810244] =A0control_work_handler #2[3371055.810245] + #2
handle_control_message CONSOLE_PORT[3371055.810246] =A0got
hvc_ports_mutex[3371055.810578] - handle_control_message
PORT_ADD[3371055.810579] + #1 handle_control_message
CONSOLE_PORT[3371055.810580] =A0trylock of hvc_ports_mutex
failed[3371055.811352] =A0got hvc_ports_mutex[3371055.811370] -
handle_control_message CONSOLE_PORT[3371055.816609] -
handle_control_message CONSOLE_PORT=A0=A0So, I'm guessing the bug is that
there shouldn't be two instances ofcontrol_work_handler() running
simultaneously?
Thanks,
Miche

Protocol:We set up the virtio console device registers during
initialization,specifying the multiport feature, and some number of
ports, n, where nis greater than 1.
In the guest, virtcons_probe() finds our device, and successfully
sendsthe VIRTIO_CONSOLE_DEVICE_READY=3D1 control message.
On the host, we receive the VIRTIO_CONSOLE_DEVICE_READY message,
andsend one VIRTIO_CONSOLE_PORT_ADD message via the Receive Control
queuefor each port in the number of ports. =A0These messages are
notserialized: they are all sent at once.
The VIRTIO_CONSOLE_PORT_ADD messages are received
inhandle_control_message() in virtio_console.c, and add_port() is
calledfor each. =A0After each port is added, the guest
sendsVIRTIO_CONSOLE_PORT_READY to the host, and in these messages, the
idof the port is included in the message.
On the host, in response to each VIRTIO_CONSOLE_PORT_READY=3D1
message,we may send a VIRTIO_CONSOLE_CONSOLE_PORT message.
On the guest, in response to each VIRTIO_CONSOLE_CONSOLE_PORT
message,init_port_console() is called on the individual port. =A0The
same id isused for these messages as was used for the PORT_READY
messages.
After each successful init_port_console(), the guest
sendsVIRTIO_CONSOLE_PORT_OPEN back to the host.

On Tue, Nov 29, 2011 at 6:21 AM, Amit Shah <amit.shah@redhat.com> wrote:
> Hi,
>
> On (Mon) 28 Nov 2011 [15:40:41], Miche Baker-Harvey wrote:
>> Amit,
>>
>> You said that the work would be serialized "due to port additions
>> being on work items on the same workqueue". =A0I'm not seeing that.
>
> You leave a lot of questions unanswered. =A0What's your environment?
> Are you hot-plugging ports? =A0Are you using qemu? =A0What's your command
> line?
>
>> I've double checked this by using a mutex_trylock in
>> hvc_console::hvc_alloc(), and here's the relevant output from dmesg:
>>
>> root@myubuntu:~# dmesg | grep MBH
>> [3307216.210274] MBH: got hvc_ports_mutex
>> [3307216.210690] MBH: trylock of hvc_ports_mutex failed
>> [3307216.211143] MBH: got hvc_ports_mutex
>>
>> This is in a system with two virtio console ports, each of which is a
>> console. =A0I think if the VIRTIO_CONSOLE_CONSOLE_PORT message handling
>> were actually being serialized, the trylock should never fail.
>
> Agreed.
>
>> What's the source of the serialization for the workqueue items? =A0At
>> first reading it looks like the control_work_handler gets called for
>> each virtio interrupt?
>
> It all depends on how you add ports. =A0If you're using qemu, they
> happen via the control work handler.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Amit
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:06:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:06:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVR7n-0007Rd-Cx; Tue, 29 Nov 2011 17:05:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RVR7l-0007Qi-QW
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:05:42 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322586303!5174487!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22779 invoked from network); 29 Nov 2011 17:05:03 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-2.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 17:05:03 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id D115E1AAEEF;
	Tue, 29 Nov 2011 18:05:02 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id O5nT-eMlMDLB; Tue, 29 Nov 2011 18:05:02 +0100 (CET)
Received: from [10.0.0.1] (p5DCB75F1.dip.t-dialin.net [93.203.117.241])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 29 Nov 2011 18:05:02 +0100 (CET)
Message-ID: <4ED510C0.8000202@hfp.de>
Date: Tue, 29 Nov 2011 18:05:04 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <4ED39164.5040203@hfp.de>
	<AEC6C66638C05B468B556EA548C1A77D01EDFF48@trantor>
In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01EDFF48@trantor>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] State of GPLPV tests - 28.11.11
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29.11.2011 00:16, James Harper wrote:
>> I am still running tests 7 days a week on two test systems. Results are quite
>> discouraging though. After experiencing crash after crash I wanted to test if
>> the configuration I called "stable" (Xen 4.0.1, GPLPV 0.11.0.213, dom0 kernel
>> 2.6.32.18-pvops0-ak3) was stable indeed. But even that config crashed when
>> running my torture test. It is stable on our production systems - running
>> other workloads of course.
> What crash are you getting these days? Is it the same one as you used to
> get?

Yes, still exactly the same crashes.

Good good news: I think I have found the bug. Since I am not really a 
Xen or Windows kernel developer it cannot say for sure but here is what 
I found:

When domU hang I ran xentop and found out that the number of vbd read 
requests was an number like 0x7FFFzzzz in hex which lead me to a thesis: 
GPLPV crashes as soon as the number of disk requests reaches 2^32. On my 
hardware with 5000 IIOPs/sec this is reached in
2^32 / 5000 IIOPs / 3600 sec-per-hour / 24 hours-per-day = 9.94 days
And there we go: there are the 9-10 days I was always seeing.

I studied the source code of blkback/blktap/aio and found nothing. But 
in GPLPV and its use of the ring macros I found suspicious code in every 
version of GPLPV I ever used

   while (more_to_do)
   {
     rp = xvdd->ring.sring->rsp_prod;
     KeMemoryBarrier();
     for (i = xvdd->ring.rsp_cons; i < rp; i++)
     {
       rep = XenVbd_GetResponse(xvdd, i);

If now rp is 10 for example and xvdd->ring.rsp_cons is 0xFFFFFFF7 then 
the for loop is skipped, responses are not delivered and we see the hang.

Regards Andreas


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:06:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:06:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVR7n-0007Rd-Cx; Tue, 29 Nov 2011 17:05:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RVR7l-0007Qi-QW
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:05:42 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322586303!5174487!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22779 invoked from network); 29 Nov 2011 17:05:03 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-2.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 17:05:03 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id D115E1AAEEF;
	Tue, 29 Nov 2011 18:05:02 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id O5nT-eMlMDLB; Tue, 29 Nov 2011 18:05:02 +0100 (CET)
Received: from [10.0.0.1] (p5DCB75F1.dip.t-dialin.net [93.203.117.241])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 29 Nov 2011 18:05:02 +0100 (CET)
Message-ID: <4ED510C0.8000202@hfp.de>
Date: Tue, 29 Nov 2011 18:05:04 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: James Harper <james.harper@bendigoit.com.au>
References: <4ED39164.5040203@hfp.de>
	<AEC6C66638C05B468B556EA548C1A77D01EDFF48@trantor>
In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D01EDFF48@trantor>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] State of GPLPV tests - 28.11.11
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29.11.2011 00:16, James Harper wrote:
>> I am still running tests 7 days a week on two test systems. Results are quite
>> discouraging though. After experiencing crash after crash I wanted to test if
>> the configuration I called "stable" (Xen 4.0.1, GPLPV 0.11.0.213, dom0 kernel
>> 2.6.32.18-pvops0-ak3) was stable indeed. But even that config crashed when
>> running my torture test. It is stable on our production systems - running
>> other workloads of course.
> What crash are you getting these days? Is it the same one as you used to
> get?

Yes, still exactly the same crashes.

Good good news: I think I have found the bug. Since I am not really a 
Xen or Windows kernel developer it cannot say for sure but here is what 
I found:

When domU hang I ran xentop and found out that the number of vbd read 
requests was an number like 0x7FFFzzzz in hex which lead me to a thesis: 
GPLPV crashes as soon as the number of disk requests reaches 2^32. On my 
hardware with 5000 IIOPs/sec this is reached in
2^32 / 5000 IIOPs / 3600 sec-per-hour / 24 hours-per-day = 9.94 days
And there we go: there are the 9-10 days I was always seeing.

I studied the source code of blkback/blktap/aio and found nothing. But 
in GPLPV and its use of the ring macros I found suspicious code in every 
version of GPLPV I ever used

   while (more_to_do)
   {
     rp = xvdd->ring.sring->rsp_prod;
     KeMemoryBarrier();
     for (i = xvdd->ring.rsp_cons; i < rp; i++)
     {
       rep = XenVbd_GetResponse(xvdd, i);

If now rp is 10 for example and xvdd->ring.rsp_cons is 0xFFFFFFF7 then 
the for loop is skipped, responses are not delivered and we see the hang.

Regards Andreas


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:13:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVRFI-0007rH-Uf; Tue, 29 Nov 2011 17:13:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RVRFH-0007r9-9J
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:13:27 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322586769!5178563!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9833 invoked from network); 29 Nov 2011 17:12:49 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-6.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 17:12:49 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 4147D1AAEF2;
	Tue, 29 Nov 2011 18:12:48 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id G6afnpqWbTsb; Tue, 29 Nov 2011 18:12:48 +0100 (CET)
Received: from [10.0.0.1] (p5DCB75F1.dip.t-dialin.net [93.203.117.241])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 29 Nov 2011 18:12:48 +0100 (CET)
Message-ID: <4ED51291.1010308@hfp.de>
Date: Tue, 29 Nov 2011 18:12:49 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Roderick Colenbrander <thunderbird2k@gmail.com>, 
	xen-devel@lists.xensource.com
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
In-Reply-To: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29.11.2011 16:48, Roderick Colenbrander wrote:
> Your tests are heavily stressing DomU. During any of your tests, have
> you seen DomU crashing in such a nasty way that Dom0 went down? What
> about in production? Our servers use similar software to you
> (initially Xen 4.0.1, but now Xen 4.1.1 and a Linux 2.6.32-pvops
> kernel), but a few percent of our servers go down in a very nasty way
> every day. Dom0 becomes unresponsive, it feels it 'hung' and we have
> to force reboot the boxes. Do issues like this sound familiar?

Not in this year of my stability tests. In this year I am always 
experiencing crashes of domU only. dom0 was always stable.

But last year, I hunted a very serious problem which causes nasty 
hangs/crashes in dom0 (which crashes domU as a consequence). See this 
mailing list post:
http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html

In my tests it clearly shows that if you have a CPU without ARAT and you 
don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash 
under load and/or after a while. What is your CPU?

Regards Andreas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:13:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:13:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVRFI-0007rH-Uf; Tue, 29 Nov 2011 17:13:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RVRFH-0007r9-9J
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:13:27 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322586769!5178563!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9833 invoked from network); 29 Nov 2011 17:12:49 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-6.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 17:12:49 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 4147D1AAEF2;
	Tue, 29 Nov 2011 18:12:48 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id G6afnpqWbTsb; Tue, 29 Nov 2011 18:12:48 +0100 (CET)
Received: from [10.0.0.1] (p5DCB75F1.dip.t-dialin.net [93.203.117.241])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 29 Nov 2011 18:12:48 +0100 (CET)
Message-ID: <4ED51291.1010308@hfp.de>
Date: Tue, 29 Nov 2011 18:12:49 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Roderick Colenbrander <thunderbird2k@gmail.com>, 
	xen-devel@lists.xensource.com
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
In-Reply-To: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29.11.2011 16:48, Roderick Colenbrander wrote:
> Your tests are heavily stressing DomU. During any of your tests, have
> you seen DomU crashing in such a nasty way that Dom0 went down? What
> about in production? Our servers use similar software to you
> (initially Xen 4.0.1, but now Xen 4.1.1 and a Linux 2.6.32-pvops
> kernel), but a few percent of our servers go down in a very nasty way
> every day. Dom0 becomes unresponsive, it feels it 'hung' and we have
> to force reboot the boxes. Do issues like this sound familiar?

Not in this year of my stability tests. In this year I am always 
experiencing crashes of domU only. dom0 was always stable.

But last year, I hunted a very serious problem which causes nasty 
hangs/crashes in dom0 (which crashes domU as a consequence). See this 
mailing list post:
http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html

In my tests it clearly shows that if you have a CPU without ARAT and you 
don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash 
under load and/or after a while. What is your CPU?

Regards Andreas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:20:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:20:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVRMB-00081F-0g; Tue, 29 Nov 2011 17:20:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVRM9-000819-Pz
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:20:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322587079!46330650!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22728 invoked from network); 29 Nov 2011 17:18:00 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:18:00 -0000
Received: by qadz3 with SMTP id z3so1924561qad.9
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 09:20:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=D+H5SmAzwk6mcRCwQ+KjVaGZkzgj2xIAUHCd39SbLBA=;
	b=pq+SpVmBGrc1Lxi3RB1xidr/Unk+ciJ5w7VKRkMCWpSBQXmv5hQ6KeB9KLl1XOoHhq
	0OVjW5N7ToijXZLhp8gWqaDCfglpRbw+2D6kLDxbj5ttspfK1WRy1ZSCWewpZdByMhlX
	aAPg89Q4bHIxq8o7h3zhOqGVo3ahTXEngATTs=
Received: by 10.224.27.18 with SMTP id g18mr22375227qac.59.1322587199960;
	Tue, 29 Nov 2011 09:19:59 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id bw9sm38207577qab.18.2011.11.29.09.19.57
	(version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 09:19:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 29 Nov 2011 09:19:54 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ross Philipson <Ross.Philipson@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAFA543A.25E0E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a package
	called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIAAAJ5LcAACUPfP
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724D625BD3@FTLPMAILBOX02.citrite.net>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com> wrote:

>> I have no problem choosing a different _HID. I just don't have a good
>> reference for what name is not going to clash with something else. Looks
>> like ACPI0001 was a bad guess. Any better suggestions? What are the
>> 'generic PNP device IDs'?
>> 
>>   Paul
> 
> Well I actually brought it up as a discussion point. I have the same sort of
> issue - I have a generic device for a virtualized environment. I don't really
> want it to be recognized as anything specific. I guess I see three options:
> 
>  - Use an unassigned APCIXXXX string. I believe the _HID string values of the
> form "ACPIXXXX" are defined by the ACPI specs themselves so this may not work
> in the long run.
>  - Use one of the predefined generic container EisaId PNP values. By that I
> meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at the Linux generic
> container driver, it doesn't do very much with these devices so that might be
> OK.

This option sounds reasonable. We have freedom to change it in future if it
turns out to be a bad choice, not that I can see why it would be.

 -- Keir

>  - Acquire a vendor specific EisaId range for Xen (e.g. EisaId(XENABCD)). Then
> we could carve up the product number part of the ID as we see fit.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:20:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:20:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVRMB-00081F-0g; Tue, 29 Nov 2011 17:20:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVRM9-000819-Pz
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:20:34 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322587079!46330650!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22728 invoked from network); 29 Nov 2011 17:18:00 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:18:00 -0000
Received: by qadz3 with SMTP id z3so1924561qad.9
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 09:20:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=D+H5SmAzwk6mcRCwQ+KjVaGZkzgj2xIAUHCd39SbLBA=;
	b=pq+SpVmBGrc1Lxi3RB1xidr/Unk+ciJ5w7VKRkMCWpSBQXmv5hQ6KeB9KLl1XOoHhq
	0OVjW5N7ToijXZLhp8gWqaDCfglpRbw+2D6kLDxbj5ttspfK1WRy1ZSCWewpZdByMhlX
	aAPg89Q4bHIxq8o7h3zhOqGVo3ahTXEngATTs=
Received: by 10.224.27.18 with SMTP id g18mr22375227qac.59.1322587199960;
	Tue, 29 Nov 2011 09:19:59 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id bw9sm38207577qab.18.2011.11.29.09.19.57
	(version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 09:19:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 29 Nov 2011 09:19:54 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ross Philipson <Ross.Philipson@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAFA543A.25E0E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a package
	called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIAAAJ5LcAACUPfP
In-Reply-To: <831D55AF5A11D64C9B4B43F59EEBF720724D625BD3@FTLPMAILBOX02.citrite.net>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com> wrote:

>> I have no problem choosing a different _HID. I just don't have a good
>> reference for what name is not going to clash with something else. Looks
>> like ACPI0001 was a bad guess. Any better suggestions? What are the
>> 'generic PNP device IDs'?
>> 
>>   Paul
> 
> Well I actually brought it up as a discussion point. I have the same sort of
> issue - I have a generic device for a virtualized environment. I don't really
> want it to be recognized as anything specific. I guess I see three options:
> 
>  - Use an unassigned APCIXXXX string. I believe the _HID string values of the
> form "ACPIXXXX" are defined by the ACPI specs themselves so this may not work
> in the long run.
>  - Use one of the predefined generic container EisaId PNP values. By that I
> meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at the Linux generic
> container driver, it doesn't do very much with these devices so that might be
> OK.

This option sounds reasonable. We have freedom to change it in future if it
turns out to be a bad choice, not that I can see why it would be.

 -- Keir

>  - Acquire a vendor specific EisaId range for Xen (e.g. EisaId(XENABCD)). Then
> we could carve up the product number part of the ID as we see fit.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:26:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:26:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVRRZ-0008Ac-QC; Tue, 29 Nov 2011 17:26:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVRRX-0008AU-RI
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:26:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322587529!5180300!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25134 invoked from network); 29 Nov 2011 17:25:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:25:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; 
   d="scan'208";a="9192048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 17:25:29 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 29 Nov 2011
	17:25:29 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, Ross Philipson
	<Ross.Philipson@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 17:25:34 +0000
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
	package called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIAAAJ5LcAACUPfPAAAr/AA=
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4F3D@LONPMAILBOX01.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724D625BD3@FTLPMAILBOX02.citrite.net>
	<CAFA543A.25E0E%keir.xen@gmail.com>
In-Reply-To: <CAFA543A.25E0E%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir,

Do you want me to re-send that patch or will you fix it up?

  Paul

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: 29 November 2011 09:20
> To: Ross Philipson; Paul Durrant; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing
> a package called ADDR, evaluating to two
> 
> On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com>
> wrote:
> 
> >> I have no problem choosing a different _HID. I just don't have a
> good
> >> reference for what name is not going to clash with something
> else.
> >> Looks like ACPI0001 was a bad guess. Any better suggestions? What
> are
> >> the 'generic PNP device IDs'?
> >>
> >>   Paul
> >
> > Well I actually brought it up as a discussion point. I have the
> same
> > sort of issue - I have a generic device for a virtualized
> environment.
> > I don't really want it to be recognized as anything specific. I
> guess I see three options:
> >
> >  - Use an unassigned APCIXXXX string. I believe the _HID string
> values
> > of the form "ACPIXXXX" are defined by the ACPI specs themselves so
> > this may not work in the long run.
> >  - Use one of the predefined generic container EisaId PNP values.
> By
> > that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at
> the
> > Linux generic container driver, it doesn't do very much with these
> > devices so that might be OK.
> 
> This option sounds reasonable. We have freedom to change it in
> future if it turns out to be a bad choice, not that I can see why it
> would be.
> 
>  -- Keir
> 
> >  - Acquire a vendor specific EisaId range for Xen (e.g.
> > EisaId(XENABCD)). Then we could carve up the product number part
> of the ID as we see fit.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:26:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:26:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVRRZ-0008Ac-QC; Tue, 29 Nov 2011 17:26:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVRRX-0008AU-RI
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:26:08 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322587529!5180300!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25134 invoked from network); 29 Nov 2011 17:25:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:25:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; 
   d="scan'208";a="9192048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 17:25:29 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 29 Nov 2011
	17:25:29 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, Ross Philipson
	<Ross.Philipson@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 17:25:34 +0000
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
	package called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIAAAJ5LcAACUPfPAAAr/AA=
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E4F3D@LONPMAILBOX01.citrite.net>
References: <831D55AF5A11D64C9B4B43F59EEBF720724D625BD3@FTLPMAILBOX02.citrite.net>
	<CAFA543A.25E0E%keir.xen@gmail.com>
In-Reply-To: <CAFA543A.25E0E%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Keir,

Do you want me to re-send that patch or will you fix it up?

  Paul

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: 29 November 2011 09:20
> To: Ross Philipson; Paul Durrant; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing
> a package called ADDR, evaluating to two
> 
> On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com>
> wrote:
> 
> >> I have no problem choosing a different _HID. I just don't have a
> good
> >> reference for what name is not going to clash with something
> else.
> >> Looks like ACPI0001 was a bad guess. Any better suggestions? What
> are
> >> the 'generic PNP device IDs'?
> >>
> >>   Paul
> >
> > Well I actually brought it up as a discussion point. I have the
> same
> > sort of issue - I have a generic device for a virtualized
> environment.
> > I don't really want it to be recognized as anything specific. I
> guess I see three options:
> >
> >  - Use an unassigned APCIXXXX string. I believe the _HID string
> values
> > of the form "ACPIXXXX" are defined by the ACPI specs themselves so
> > this may not work in the long run.
> >  - Use one of the predefined generic container EisaId PNP values.
> By
> > that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at
> the
> > Linux generic container driver, it doesn't do very much with these
> > devices so that might be OK.
> 
> This option sounds reasonable. We have freedom to change it in
> future if it turns out to be a bad choice, not that I can see why it
> would be.
> 
>  -- Keir
> 
> >  - Acquire a vendor specific EisaId range for Xen (e.g.
> > EisaId(XENABCD)). Then we could carve up the product number part
> of the ID as we see fit.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:46:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:46:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVRlI-00008P-PJ; Tue, 29 Nov 2011 17:46:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVRlH-00008J-Iu
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:46:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322588739!47584265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8045 invoked from network); 29 Nov 2011 17:45:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:45:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; 
   d="scan'208";a="9192366"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 17:45:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 17:45:56 +0000
Date: Tue, 29 Nov 2011 17:47:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20179.47462.815671.301622@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111291627510.31179@kaball-desktop>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
	<20179.47462.815671.301622@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
 after statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 28 Nov 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration after statement"):
> > I think it would make sense to add to the CODING_STYLE that variable
> > declarations shouldn't be mixed with code, unless part of a macro or an
> > alloca-like construct.
> 
> I think this is a silly rule.  In my proposed commit message I
> advanced three reasons for allowing declaration after statement:
> 
> > >  * It allows variables to be more often initialised as they are
> > >    declared, thus reducing the occurrence of uninitialised variable
> > >    errors.
> > > 
> > >  * Certain alloca-like constructs (arrays allocated at runtime on the
> > >    stack) can more often be written without a spurious { } block.
> > >    Such blocks are confusing to read.
> > >
> > >  * It makes it easier to write and use macros which declare and
> > >    initialise formulaic variables and do other function setup code,
> > >    because there is no need to worry that such macros might be
> > >    incompatible with each other or have strict ordering constraints.
> 
> Of these the first two improvements would be banned by your proposed
> coding style rule.

Only the first would be banned, I am OK with making an exception for
alloca constructs and macros.


> I don't understand what the harm is in allowing declarations, with
> initialisation, freely mixed with code.


It makes the code harder to read;
it makes it more difficult to rearrange local variables in the future;
it makes it more difficult to see how much stack your function is using;
it makes it more difficult to realize if you can reduce the amount of
local variables you are using.

And it violates the current coding style.

I think that declaring variables at the beginning of the function is a
good programming practice in any language.

The three most important C codebases in the Xen project are: Linux,
Qemu and Xen. None of these allow mixing declarations and code, for a
good reason. I don't think libxl should have a different code style in
this regard, it would just be confusing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:46:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:46:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVRlI-00008P-PJ; Tue, 29 Nov 2011 17:46:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVRlH-00008J-Iu
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:46:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322588739!47584265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8045 invoked from network); 29 Nov 2011 17:45:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:45:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; 
   d="scan'208";a="9192366"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 17:45:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 17:45:56 +0000
Date: Tue, 29 Nov 2011 17:47:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20179.47462.815671.301622@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111291627510.31179@kaball-desktop>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
	<20179.47462.815671.301622@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
 after statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 28 Nov 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration after statement"):
> > I think it would make sense to add to the CODING_STYLE that variable
> > declarations shouldn't be mixed with code, unless part of a macro or an
> > alloca-like construct.
> 
> I think this is a silly rule.  In my proposed commit message I
> advanced three reasons for allowing declaration after statement:
> 
> > >  * It allows variables to be more often initialised as they are
> > >    declared, thus reducing the occurrence of uninitialised variable
> > >    errors.
> > > 
> > >  * Certain alloca-like constructs (arrays allocated at runtime on the
> > >    stack) can more often be written without a spurious { } block.
> > >    Such blocks are confusing to read.
> > >
> > >  * It makes it easier to write and use macros which declare and
> > >    initialise formulaic variables and do other function setup code,
> > >    because there is no need to worry that such macros might be
> > >    incompatible with each other or have strict ordering constraints.
> 
> Of these the first two improvements would be banned by your proposed
> coding style rule.

Only the first would be banned, I am OK with making an exception for
alloca constructs and macros.


> I don't understand what the harm is in allowing declarations, with
> initialisation, freely mixed with code.


It makes the code harder to read;
it makes it more difficult to rearrange local variables in the future;
it makes it more difficult to see how much stack your function is using;
it makes it more difficult to realize if you can reduce the amount of
local variables you are using.

And it violates the current coding style.

I think that declaring variables at the beginning of the function is a
good programming practice in any language.

The three most important C codebases in the Xen project are: Linux,
Qemu and Xen. None of these allow mixing declarations and code, for a
good reason. I don't think libxl should have a different code style in
this regard, it would just be confusing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:51:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:51:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVRpy-0000Sb-6k; Tue, 29 Nov 2011 17:51:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RVRpw-0000Rs-QO
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:51:21 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322589042!3575919!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12832 invoked from network); 29 Nov 2011 17:50:43 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:50:43 -0000
Received: by qadb12 with SMTP id b12so5938749qad.9
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 09:50:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-system-of-record;
	bh=L872FKQn9ezmhGg592oZYKzIF47Jj0vBOsC9ZBKbB04=;
	b=opGV9d4H0zi2tbl7HzxZZ0tKKckdi3Kd6evHxrViCdEkxFpmpdA+vxmF14gG5nSPh2
	jcNXj+9y8FmdossRWt+g==
Received: by 10.224.33.76 with SMTP id g12mr22972832qad.46.1322589041735;
	Tue, 29 Nov 2011 09:50:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.33.76 with SMTP id g12mr22972812qad.46.1322589041614; Tue,
	29 Nov 2011 09:50:41 -0800 (PST)
Received: by 10.229.137.72 with HTTP; Tue, 29 Nov 2011 09:50:41 -0800 (PST)
In-Reply-To: <CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
Date: Tue, 29 Nov 2011 09:50:41 -0800
Message-ID: <CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Amit Shah <amit.shah@redhat.com>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Good grief!  Sorry for the spacing mess-up!  Here's a resend with reformatting.

Amit,
We aren't using either QEMU or kvmtool, but we are using KVM.  All
the issues we are seeing happen when we try to establish multiple
virtioconsoles at boot time.  The command line isn't relevant, but I
can tell you the protocol that's passing between the host (kvm) and
the guest (see the end of this message).

We do go through the control_work_handler(), but it's not
providing synchronization.  Here's a trace of the
control_work_handler() and handle_control_message() calls; note that
there are two concurrent calls to control_work_handler().

I decorated control_work_handler() with a "lifetime" marker, and
passed this value to handle_control_message(), so we can see which
control messages are being handled from which instance of
the control_work_handler() thread.

Notice that we enter control_work_handler() a second time before
the handling of the second PORT_ADD message is complete. The
first CONSOLE_PORT message is handled by the second
control_work_handler() call, but the second is handled by the first
control_work_handler() call.

root@myubuntu:~# dmesg | grep MBH
[3371055.808738] control_work_handler #1
[3371055.809372] + #1 handle_control_message PORT_ADD
[3371055.810169] - handle_control_message PORT_ADD
[3371055.810170] + #1 handle_control_message PORT_ADD
[3371055.810244]  control_work_handler #2
[3371055.810245] + #2 handle_control_message CONSOLE_PORT
[3371055.810246]  got hvc_ports_mutex
[3371055.810578] - handle_control_message PORT_ADD
[3371055.810579] + #1 handle_control_message CONSOLE_PORT
[3371055.810580]  trylock of hvc_ports_mutex failed
[3371055.811352]  got hvc_ports_mutex
[3371055.811370] - handle_control_message CONSOLE_PORT
[3371055.816609] - handle_control_message CONSOLE_PORT

So, I'm guessing the bug is that there shouldn't be two instances of
control_work_handler() running simultaneously?

Thanks,

Miche

Protocol:
We set up the virtio console device registers during initialization,
specifying the multiport feature, and some number of
ports, n, where nis greater than 1.

In the guest, virtcons_probe() finds our device, and successfully
sends the VIRTIO_CONSOLE_DEVICE_READY=1 control message.
On the host, we receive the VIRTIO_CONSOLE_DEVICE_READY message,
and send one VIRTIO_CONSOLE_PORT_ADD message via the Receive Control
queuefor each port in the number of ports.  These messages are
not serialized: they are all sent at once.

The VIRTIO_CONSOLE_PORT_ADD messages are received
in handle_control_message() in virtio_console.c, and add_port() is
called for each.  After each port is added, the guest
sendsVIRTIO_CONSOLE_PORT_READY to the host, and in these messages, the
id of the port is included in the message.

On the host, in response to each VIRTIO_CONSOLE_PORT_READY=1
message, we may send a VIRTIO_CONSOLE_CONSOLE_PORT message.
On the guest, in response to each VIRTIO_CONSOLE_CONSOLE_PORT
message, init_port_console() is called on the individual port.  The
same id is used for these messages as was used for the PORT_READY
messages.

After each successful init_port_console(), the guest
sends VIRTIO_CONSOLE_PORT_OPEN back to the host.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 17:51:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 17:51:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVRpy-0000Sb-6k; Tue, 29 Nov 2011 17:51:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <miche@google.com>) id 1RVRpw-0000Rs-QO
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 17:51:21 +0000
X-Env-Sender: miche@google.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1322589042!3575919!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12832 invoked from network); 29 Nov 2011 17:50:43 -0000
Received: from mail-qw0-f50.google.com (HELO mail-qw0-f50.google.com)
	(209.85.216.50)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 17:50:43 -0000
Received: by qadb12 with SMTP id b12so5938749qad.9
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 09:50:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-system-of-record;
	bh=L872FKQn9ezmhGg592oZYKzIF47Jj0vBOsC9ZBKbB04=;
	b=opGV9d4H0zi2tbl7HzxZZ0tKKckdi3Kd6evHxrViCdEkxFpmpdA+vxmF14gG5nSPh2
	jcNXj+9y8FmdossRWt+g==
Received: by 10.224.33.76 with SMTP id g12mr22972832qad.46.1322589041735;
	Tue, 29 Nov 2011 09:50:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.33.76 with SMTP id g12mr22972812qad.46.1322589041614; Tue,
	29 Nov 2011 09:50:41 -0800 (PST)
Received: by 10.229.137.72 with HTTP; Tue, 29 Nov 2011 09:50:41 -0800 (PST)
In-Reply-To: <CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
References: <20111108214452.28884.14840.stgit@miche.sea.corp.google.com>
	<20111108214504.28884.61814.stgit@miche.sea.corp.google.com>
	<874nybqo0o.fsf@rustcorp.com.au>
	<CAB8RdapbaueyWLJuJDE_ZdvLkRNM4sQHTxgmgO=jrnXZ6YPSmA@mail.gmail.com>
	<20111123103852.GG16665@amit-x200.redhat.com>
	<CAB8RdaoDxMCgTjuGP70bGrsrtgh=USYtU3Spo5OPtVMYAM5EzQ@mail.gmail.com>
	<20111129142149.GE2822@amit-x200.redhat.com>
	<CAB8RdapuPRym2dH_9mgmGdzpCxnP1KpS+hS8JJ-geVkga5fMcw@mail.gmail.com>
Date: Tue, 29 Nov 2011 09:50:41 -0800
Message-ID: <CAB8Rdapfuf5XH+X9gsUL+CJ9gTQcSNfq4Dj9DoYWQeFgD04ODQ@mail.gmail.com>
From: Miche Baker-Harvey <miche@google.com>
To: Amit Shah <amit.shah@redhat.com>
X-System-Of-Record: true
Cc: Stephen Rothwell <sfr@canb.auug.org.au>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Rusty Russell <rusty@rustcorp.com.au>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Anton Blanchard <anton@samba.org>, Mike Waychison <mikew@google.com>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, Eric Northrup <digitaleric@google.com>
Subject: Re: [Xen-devel] [PATCH v3 2/3] hvc_init(): Enforce one-time
	initialization.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Good grief!  Sorry for the spacing mess-up!  Here's a resend with reformatting.

Amit,
We aren't using either QEMU or kvmtool, but we are using KVM.  All
the issues we are seeing happen when we try to establish multiple
virtioconsoles at boot time.  The command line isn't relevant, but I
can tell you the protocol that's passing between the host (kvm) and
the guest (see the end of this message).

We do go through the control_work_handler(), but it's not
providing synchronization.  Here's a trace of the
control_work_handler() and handle_control_message() calls; note that
there are two concurrent calls to control_work_handler().

I decorated control_work_handler() with a "lifetime" marker, and
passed this value to handle_control_message(), so we can see which
control messages are being handled from which instance of
the control_work_handler() thread.

Notice that we enter control_work_handler() a second time before
the handling of the second PORT_ADD message is complete. The
first CONSOLE_PORT message is handled by the second
control_work_handler() call, but the second is handled by the first
control_work_handler() call.

root@myubuntu:~# dmesg | grep MBH
[3371055.808738] control_work_handler #1
[3371055.809372] + #1 handle_control_message PORT_ADD
[3371055.810169] - handle_control_message PORT_ADD
[3371055.810170] + #1 handle_control_message PORT_ADD
[3371055.810244]  control_work_handler #2
[3371055.810245] + #2 handle_control_message CONSOLE_PORT
[3371055.810246]  got hvc_ports_mutex
[3371055.810578] - handle_control_message PORT_ADD
[3371055.810579] + #1 handle_control_message CONSOLE_PORT
[3371055.810580]  trylock of hvc_ports_mutex failed
[3371055.811352]  got hvc_ports_mutex
[3371055.811370] - handle_control_message CONSOLE_PORT
[3371055.816609] - handle_control_message CONSOLE_PORT

So, I'm guessing the bug is that there shouldn't be two instances of
control_work_handler() running simultaneously?

Thanks,

Miche

Protocol:
We set up the virtio console device registers during initialization,
specifying the multiport feature, and some number of
ports, n, where nis greater than 1.

In the guest, virtcons_probe() finds our device, and successfully
sends the VIRTIO_CONSOLE_DEVICE_READY=1 control message.
On the host, we receive the VIRTIO_CONSOLE_DEVICE_READY message,
and send one VIRTIO_CONSOLE_PORT_ADD message via the Receive Control
queuefor each port in the number of ports.  These messages are
not serialized: they are all sent at once.

The VIRTIO_CONSOLE_PORT_ADD messages are received
in handle_control_message() in virtio_console.c, and add_port() is
called for each.  After each port is added, the guest
sendsVIRTIO_CONSOLE_PORT_READY to the host, and in these messages, the
id of the port is included in the message.

On the host, in response to each VIRTIO_CONSOLE_PORT_READY=1
message, we may send a VIRTIO_CONSOLE_CONSOLE_PORT message.
On the guest, in response to each VIRTIO_CONSOLE_CONSOLE_PORT
message, init_port_console() is called on the individual port.  The
same id is used for these messages as was used for the PORT_READY
messages.

After each successful init_port_console(), the guest
sends VIRTIO_CONSOLE_PORT_OPEN back to the host.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:05:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:05:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVS3E-0000xP-Rn; Tue, 29 Nov 2011 18:05:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RVS3D-0000x2-MY
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:05:03 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322589863!3598081!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24661 invoked from network); 29 Nov 2011 18:04:24 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 18:04:24 -0000
Received: by yenr9 with SMTP id r9so4584110yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 10:04:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=KeBkNLw+9PY10MK/DLg0C3ZcSQCOpk5vFD26lQdzpjs=;
	b=AWZ7/oQ0ILwz64HxMroJX1nTmWPl+DH+pnz6Ubxv36vRhajCuPCo25VNqMKBJWD3AU
	/QH2FlvAKDDKDn5fvcZ6vri+pBsRbJovzVgivQn1rw8tpJswuqDji73cIhUtwCVXdK8h
	9Or/rqIBzO3nFHse0kTFR9EKHc/3Asyrd/vSc=
MIME-Version: 1.0
Received: by 10.100.28.29 with SMTP id b29mr1960962anb.126.1322589862088; Tue,
	29 Nov 2011 10:04:22 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Tue, 29 Nov 2011 10:04:22 -0800 (PST)
In-Reply-To: <4ED51291.1010308@hfp.de>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
Date: Tue, 29 Nov 2011 10:04:22 -0800
Message-ID: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 9:12 AM, Andreas Kinzler <ml-xen-devel@hfp.de> wrote:
> On 29.11.2011 16:48, Roderick Colenbrander wrote:
>>
>> Your tests are heavily stressing DomU. During any of your tests, have
>> you seen DomU crashing in such a nasty way that Dom0 went down? What
>> about in production? Our servers use similar software to you
>> (initially Xen 4.0.1, but now Xen 4.1.1 and a Linux 2.6.32-pvops
>> kernel), but a few percent of our servers go down in a very nasty way
>> every day. Dom0 becomes unresponsive, it feels it 'hung' and we have
>> to force reboot the boxes. Do issues like this sound familiar?
>
>
> Not in this year of my stability tests. In this year I am always
> experiencing crashes of domU only. dom0 was always stable.
>
> But last year, I hunted a very serious problem which causes nasty
> hangs/crashes in dom0 (which crashes domU as a consequence). See this
> mailing list post:
> http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
>
> In my tests it clearly shows that if you have a CPU without ARAT and you
> don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash under
> load and/or after a while. What is your CPU?
>
> Regards Andreas

Most of our machines use i7 950 CPUs. They don't seem to have ARAT.
Some other machines use Xeon CPUs with ARAT support. We never had
issues on the Xeon systems, so we may actually be suffering from the
ARAT issue. Are you still using the patch you linked to in a
production environment? I wonder why a cleaned up patch like that
never made it into core.

I'm going to do some testing (may take a while).

Thanks,
Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:05:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:05:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVS3E-0000xP-Rn; Tue, 29 Nov 2011 18:05:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RVS3D-0000x2-MY
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:05:03 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322589863!3598081!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24661 invoked from network); 29 Nov 2011 18:04:24 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 18:04:24 -0000
Received: by yenr9 with SMTP id r9so4584110yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 10:04:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=KeBkNLw+9PY10MK/DLg0C3ZcSQCOpk5vFD26lQdzpjs=;
	b=AWZ7/oQ0ILwz64HxMroJX1nTmWPl+DH+pnz6Ubxv36vRhajCuPCo25VNqMKBJWD3AU
	/QH2FlvAKDDKDn5fvcZ6vri+pBsRbJovzVgivQn1rw8tpJswuqDji73cIhUtwCVXdK8h
	9Or/rqIBzO3nFHse0kTFR9EKHc/3Asyrd/vSc=
MIME-Version: 1.0
Received: by 10.100.28.29 with SMTP id b29mr1960962anb.126.1322589862088; Tue,
	29 Nov 2011 10:04:22 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Tue, 29 Nov 2011 10:04:22 -0800 (PST)
In-Reply-To: <4ED51291.1010308@hfp.de>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
Date: Tue, 29 Nov 2011 10:04:22 -0800
Message-ID: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 9:12 AM, Andreas Kinzler <ml-xen-devel@hfp.de> wrote:
> On 29.11.2011 16:48, Roderick Colenbrander wrote:
>>
>> Your tests are heavily stressing DomU. During any of your tests, have
>> you seen DomU crashing in such a nasty way that Dom0 went down? What
>> about in production? Our servers use similar software to you
>> (initially Xen 4.0.1, but now Xen 4.1.1 and a Linux 2.6.32-pvops
>> kernel), but a few percent of our servers go down in a very nasty way
>> every day. Dom0 becomes unresponsive, it feels it 'hung' and we have
>> to force reboot the boxes. Do issues like this sound familiar?
>
>
> Not in this year of my stability tests. In this year I am always
> experiencing crashes of domU only. dom0 was always stable.
>
> But last year, I hunted a very serious problem which causes nasty
> hangs/crashes in dom0 (which crashes domU as a consequence). See this
> mailing list post:
> http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
>
> In my tests it clearly shows that if you have a CPU without ARAT and you
> don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash under
> load and/or after a while. What is your CPU?
>
> Regards Andreas

Most of our machines use i7 950 CPUs. They don't seem to have ARAT.
Some other machines use Xeon CPUs with ARAT support. We never had
issues on the Xeon systems, so we may actually be suffering from the
ARAT issue. Are you still using the patch you linked to in a
production environment? I wonder why a cleaned up patch like that
never made it into core.

I'm going to do some testing (may take a while).

Thanks,
Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:07:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:07:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVS4o-00015E-IK; Tue, 29 Nov 2011 18:06:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVS4n-00014g-EQ
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:06:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322589964!5498176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2129 invoked from network); 29 Nov 2011 18:06:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 18:06:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; 
   d="scan'208";a="9192652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 18:06:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 18:06:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVS4B-000513-JU; Tue, 29 Nov 2011 18:06:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVS4B-0000Bk-Hm;
	Tue, 29 Nov 2011 18:06:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20181.7947.536791.506011@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 18:06:03 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1111291627510.31179@kaball-desktop>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
	<20179.47462.815671.301622@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1111291627510.31179@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
 after statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration after statement"):
> On Mon, 28 Nov 2011, Ian Jackson wrote:
> > I don't understand what the harm is in allowing declarations, with
> > initialisation, freely mixed with code.
> 
> 
> It makes the code harder to read;

Naturally I disagree, but this is a matter of subjective taste as far
as I can tell, unless you have something specific to point to.

> it makes it more difficult to rearrange local variables in the future;

I'm not sure what you mean by "rearrange local variables".  The style
where variables are declared only at the top of the file tends to
result in long lists of local variables in declaration statements at
the top of functions.  Those long lists make editing the function
somewhat more complex.

Declaring variables in the same statement as they are initialised
naturally makes "rearranging" them trivial.

> it makes it more difficult to see how much stack your function is using;

This is not relevant in libxl unless the objects are truly huge (in
which case they shouldn't be on the stack at all).

> it makes it more difficult to realize if you can reduce the amount of
> local variables you are using.

There is no benefit in trying to "reduce the amount of local
variables" in userland C code compiled with a reasonable optimising
compiler.  The compiler will be able to do the same liveness analysis
either way.

> And it violates the current coding style.

This is not an argument against changing the coding style.

> I think that declaring variables at the beginning of the function is a
> good programming practice in any language.

I think that initialising variables at the time they are declared,
where reasonable, is good programming practice in any language.

> The three most important C codebases in the Xen project are: Linux,
> Qemu and Xen. None of these allow mixing declarations and code, for a
> good reason. I don't think libxl should have a different code style in
> this regard, it would just be confusing.

I don't see this as a particularly relevant consideration.  There are
lots of other ways our coding style differs from (say) Linux.  Any
competent C programmer will be familiar with both styles.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:07:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:07:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVS4o-00015E-IK; Tue, 29 Nov 2011 18:06:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVS4n-00014g-EQ
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:06:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322589964!5498176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2129 invoked from network); 29 Nov 2011 18:06:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 18:06:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; 
   d="scan'208";a="9192652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 18:06:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 18:06:04 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVS4B-000513-JU; Tue, 29 Nov 2011 18:06:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVS4B-0000Bk-Hm;
	Tue, 29 Nov 2011 18:06:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20181.7947.536791.506011@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 18:06:03 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1111291627510.31179@kaball-desktop>
References: <1319827031-15395-1-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-2-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-3-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-4-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-5-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-6-git-send-email-ian.jackson@eu.citrix.com>
	<1319827031-15395-7-git-send-email-ian.jackson@eu.citrix.com>
	<1320054652.23193.28.camel@zakaz.uk.xensource.com>
	<20145.29085.278257.629473@mariner.uk.xensource.com>
	<1320263024.3084.61.camel@cthulhu.hellion.org.uk>
	<alpine.DEB.2.00.1111071033560.3519@kaball-desktop>
	<20179.47462.815671.301622@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1111291627510.31179@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration
 after statement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH RFC v2 06/13] libxl: permit declaration after statement"):
> On Mon, 28 Nov 2011, Ian Jackson wrote:
> > I don't understand what the harm is in allowing declarations, with
> > initialisation, freely mixed with code.
> 
> 
> It makes the code harder to read;

Naturally I disagree, but this is a matter of subjective taste as far
as I can tell, unless you have something specific to point to.

> it makes it more difficult to rearrange local variables in the future;

I'm not sure what you mean by "rearrange local variables".  The style
where variables are declared only at the top of the file tends to
result in long lists of local variables in declaration statements at
the top of functions.  Those long lists make editing the function
somewhat more complex.

Declaring variables in the same statement as they are initialised
naturally makes "rearranging" them trivial.

> it makes it more difficult to see how much stack your function is using;

This is not relevant in libxl unless the objects are truly huge (in
which case they shouldn't be on the stack at all).

> it makes it more difficult to realize if you can reduce the amount of
> local variables you are using.

There is no benefit in trying to "reduce the amount of local
variables" in userland C code compiled with a reasonable optimising
compiler.  The compiler will be able to do the same liveness analysis
either way.

> And it violates the current coding style.

This is not an argument against changing the coding style.

> I think that declaring variables at the beginning of the function is a
> good programming practice in any language.

I think that initialising variables at the time they are declared,
where reasonable, is good programming practice in any language.

> The three most important C codebases in the Xen project are: Linux,
> Qemu and Xen. None of these allow mixing declarations and code, for a
> good reason. I don't think libxl should have a different code style in
> this regard, it would just be confusing.

I don't see this as a particularly relevant consideration.  There are
lots of other ways our coding style differs from (say) Linux.  Any
competent C programmer will be familiar with both styles.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:17:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:17:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSEO-0001Sl-M5; Tue, 29 Nov 2011 18:16:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RVSEN-0001Sf-90
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:16:35 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322590557!6136355!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21012 invoked from network); 29 Nov 2011 18:15:57 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-12.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 18:15:57 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 4456F1AAEFD;
	Tue, 29 Nov 2011 19:15:56 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id FbjkbTk+BqC4; Tue, 29 Nov 2011 19:15:56 +0100 (CET)
Received: from [10.0.0.1] (p5DCB75F1.dip.t-dialin.net [93.203.117.241])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 29 Nov 2011 19:15:56 +0100 (CET)
Message-ID: <4ED5215D.1010403@hfp.de>
Date: Tue, 29 Nov 2011 19:15:57 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Roderick Colenbrander <thunderbird2k@gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
In-Reply-To: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> Not in this year of my stability tests. In this year I am always
>> experiencing crashes of domU only. dom0 was always stable.
>> But last year, I hunted a very serious problem which causes nasty
>> hangs/crashes in dom0 (which crashes domU as a consequence). See this
>> mailing list post:
>> http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
>> In my tests it clearly shows that if you have a CPU without ARAT and you
>> don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash under
>> load and/or after a while. What is your CPU?
> Most of our machines use i7 950 CPUs. They don't seem to have ARAT.

Yes, i7 950 does not have ARAT as it is the first Nehalem generation.

> Some other machines use Xeon CPUs with ARAT support. We never had
> issues on the Xeon systems, so we may actually be suffering from the
> ARAT issue. Are you still using the patch you linked to in a
> production environment?

Absolutely. As I mentioned I just re-performed tests recently and found 
that even Xen 4.1.1 (earlier tests were for 4.0.1) is unstable without 
my patch on non-ARAT-CPUs.

 > I wonder why a cleaned up patch like that never made it into core.

The patch actually only disables HPET broadcast which has some downsides 
because it effectively disables C3 states. Without C3 states Nehalem and 
later CPUs cannot enter turbo-mode. So there is some loss of performance.

> I'm going to do some testing (may take a while).

Please let me know. There are already some people confirming that HPET 
broadcast is buggy. With more evidence I will contact Keir again and 
suggest to have it (HPET broadcast) fixed or removed.

Regards Andreas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:17:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:17:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSEO-0001Sl-M5; Tue, 29 Nov 2011 18:16:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RVSEN-0001Sf-90
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:16:35 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322590557!6136355!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21012 invoked from network); 29 Nov 2011 18:15:57 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-12.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 18:15:57 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 4456F1AAEFD;
	Tue, 29 Nov 2011 19:15:56 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id FbjkbTk+BqC4; Tue, 29 Nov 2011 19:15:56 +0100 (CET)
Received: from [10.0.0.1] (p5DCB75F1.dip.t-dialin.net [93.203.117.241])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Tue, 29 Nov 2011 19:15:56 +0100 (CET)
Message-ID: <4ED5215D.1010403@hfp.de>
Date: Tue, 29 Nov 2011 19:15:57 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Roderick Colenbrander <thunderbird2k@gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
In-Reply-To: <CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> Not in this year of my stability tests. In this year I am always
>> experiencing crashes of domU only. dom0 was always stable.
>> But last year, I hunted a very serious problem which causes nasty
>> hangs/crashes in dom0 (which crashes domU as a consequence). See this
>> mailing list post:
>> http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
>> In my tests it clearly shows that if you have a CPU without ARAT and you
>> don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash under
>> load and/or after a while. What is your CPU?
> Most of our machines use i7 950 CPUs. They don't seem to have ARAT.

Yes, i7 950 does not have ARAT as it is the first Nehalem generation.

> Some other machines use Xeon CPUs with ARAT support. We never had
> issues on the Xeon systems, so we may actually be suffering from the
> ARAT issue. Are you still using the patch you linked to in a
> production environment?

Absolutely. As I mentioned I just re-performed tests recently and found 
that even Xen 4.1.1 (earlier tests were for 4.0.1) is unstable without 
my patch on non-ARAT-CPUs.

 > I wonder why a cleaned up patch like that never made it into core.

The patch actually only disables HPET broadcast which has some downsides 
because it effectively disables C3 states. Without C3 states Nehalem and 
later CPUs cannot enter turbo-mode. So there is some loss of performance.

> I'm going to do some testing (may take a while).

Please let me know. There are already some people confirming that HPET 
broadcast is buggy. With more evidence I will contact Keir again and 
suggest to have it (HPET broadcast) fixed or removed.

Regards Andreas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:22:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSJo-0001or-DQ; Tue, 29 Nov 2011 18:22:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RVSJm-0001oc-93
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:22:10 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322590891!5543230!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19621 invoked from network); 29 Nov 2011 18:21:32 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 18:21:32 -0000
Received: by yenr9 with SMTP id r9so4607775yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 10:21:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=A1WilIaolv0PoEX9ntQ1TNat+S74VelWVM1HqjztIdM=;
	b=kkcf7JQqP7HZJDx7/1QMu80HBNDXSrFjcKCkrv8HRNFD4OLpb9koa9WFJoPzDx/K1d
	IGQK7GevIh6XjsI3Nn2QkNqysZSRE4RoCAT44jgDeGr5i0xtYH1TzEK5G3R+zcGbluNx
	T/Szcu5ea4JTeK2edV1Dw0YQb/KRsNrvVxz5Q=
MIME-Version: 1.0
Received: by 10.236.79.38 with SMTP id h26mr71764041yhe.39.1322590891418; Tue,
	29 Nov 2011 10:21:31 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Tue, 29 Nov 2011 10:21:31 -0800 (PST)
In-Reply-To: <4ED5215D.1010403@hfp.de>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
Date: Tue, 29 Nov 2011 10:21:31 -0800
Message-ID: <CAEc3jaA3GgpGzP52D86qBMMRDNRBO7H08RDfxuF6pG609h96iA@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 10:15 AM, Andreas Kinzler <ml-xen-devel@hfp.de> wrote:
>>> Not in this year of my stability tests. In this year I am always
>>> experiencing crashes of domU only. dom0 was always stable.
>>> But last year, I hunted a very serious problem which causes nasty
>>> hangs/crashes in dom0 (which crashes domU as a consequence). See this
>>> mailing list post:
>>> http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
>>> In my tests it clearly shows that if you have a CPU without ARAT and you
>>> don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash
>>> under
>>> load and/or after a while. What is your CPU?
>>
>> Most of our machines use i7 950 CPUs. They don't seem to have ARAT.
>
>
> Yes, i7 950 does not have ARAT as it is the first Nehalem generation.
>
>
>> Some other machines use Xeon CPUs with ARAT support. We never had
>> issues on the Xeon systems, so we may actually be suffering from the
>> ARAT issue. Are you still using the patch you linked to in a
>> production environment?
>
>
> Absolutely. As I mentioned I just re-performed tests recently and found that
> even Xen 4.1.1 (earlier tests were for 4.0.1) is unstable without my patch
> on non-ARAT-CPUs.
>
>
>> I wonder why a cleaned up patch like that never made it into core.
>
> The patch actually only disables HPET broadcast which has some downsides
> because it effectively disables C3 states. Without C3 states Nehalem and
> later CPUs cannot enter turbo-mode. So there is some loss of performance.

Would disabling any low CPU power states and turbo clocks in the BIOS,
help as well? Just curious. I have seen other 'weird' performance
issues between machines using the same hardware. Some CPU intensive
algorithm could be twice as slow running on Dom0 compared to the same
kernel without Xen. On other identical systems I didn't see that
issue. I didn't have time to investigate, but I felt there may have
been BIOS setting differences.

>
>
>> I'm going to do some testing (may take a while).
>
>
> Please let me know. There are already some people confirming that HPET
> broadcast is buggy. With more evidence I will contact Keir again and suggest
> to have it (HPET broadcast) fixed or removed.
>
> Regards Andreas

Thanks,
Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:22:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSJo-0001or-DQ; Tue, 29 Nov 2011 18:22:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RVSJm-0001oc-93
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:22:10 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322590891!5543230!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19621 invoked from network); 29 Nov 2011 18:21:32 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 18:21:32 -0000
Received: by yenr9 with SMTP id r9so4607775yen.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 10:21:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=A1WilIaolv0PoEX9ntQ1TNat+S74VelWVM1HqjztIdM=;
	b=kkcf7JQqP7HZJDx7/1QMu80HBNDXSrFjcKCkrv8HRNFD4OLpb9koa9WFJoPzDx/K1d
	IGQK7GevIh6XjsI3Nn2QkNqysZSRE4RoCAT44jgDeGr5i0xtYH1TzEK5G3R+zcGbluNx
	T/Szcu5ea4JTeK2edV1Dw0YQb/KRsNrvVxz5Q=
MIME-Version: 1.0
Received: by 10.236.79.38 with SMTP id h26mr71764041yhe.39.1322590891418; Tue,
	29 Nov 2011 10:21:31 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Tue, 29 Nov 2011 10:21:31 -0800 (PST)
In-Reply-To: <4ED5215D.1010403@hfp.de>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
Date: Tue, 29 Nov 2011 10:21:31 -0800
Message-ID: <CAEc3jaA3GgpGzP52D86qBMMRDNRBO7H08RDfxuF6pG609h96iA@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 10:15 AM, Andreas Kinzler <ml-xen-devel@hfp.de> wrote:
>>> Not in this year of my stability tests. In this year I am always
>>> experiencing crashes of domU only. dom0 was always stable.
>>> But last year, I hunted a very serious problem which causes nasty
>>> hangs/crashes in dom0 (which crashes domU as a consequence). See this
>>> mailing list post:
>>> http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
>>> In my tests it clearly shows that if you have a CPU without ARAT and you
>>> don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash
>>> under
>>> load and/or after a while. What is your CPU?
>>
>> Most of our machines use i7 950 CPUs. They don't seem to have ARAT.
>
>
> Yes, i7 950 does not have ARAT as it is the first Nehalem generation.
>
>
>> Some other machines use Xeon CPUs with ARAT support. We never had
>> issues on the Xeon systems, so we may actually be suffering from the
>> ARAT issue. Are you still using the patch you linked to in a
>> production environment?
>
>
> Absolutely. As I mentioned I just re-performed tests recently and found that
> even Xen 4.1.1 (earlier tests were for 4.0.1) is unstable without my patch
> on non-ARAT-CPUs.
>
>
>> I wonder why a cleaned up patch like that never made it into core.
>
> The patch actually only disables HPET broadcast which has some downsides
> because it effectively disables C3 states. Without C3 states Nehalem and
> later CPUs cannot enter turbo-mode. So there is some loss of performance.

Would disabling any low CPU power states and turbo clocks in the BIOS,
help as well? Just curious. I have seen other 'weird' performance
issues between machines using the same hardware. Some CPU intensive
algorithm could be twice as slow running on Dom0 compared to the same
kernel without Xen. On other identical systems I didn't see that
issue. I didn't have time to investigate, but I felt there may have
been BIOS setting differences.

>
>
>> I'm going to do some testing (may take a while).
>
>
> Please let me know. There are already some people confirming that HPET
> broadcast is buggy. With more evidence I will contact Keir again and suggest
> to have it (HPET broadcast) fixed or removed.
>
> Regards Andreas

Thanks,
Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:35:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:35:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSWm-0002I8-5c; Tue, 29 Nov 2011 18:35:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVSWk-0002Hv-IW
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:35:34 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322591685!57028684!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25805 invoked from network); 29 Nov 2011 18:34:46 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 18:34:46 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATIYss3005200
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 13:34:54 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATIYsZJ005198;
	Tue, 29 Nov 2011 13:34:54 -0500
MIME-Version: 1.0
Message-Id: <patchbomb.1322591626@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 29 Nov 2011 13:33:46 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 8
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0 of 2] Documentation patches for
	HYPERVISOR_mmu_update (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Documenting some of the requirements when using HYPERVISOR_mmu_update
that are not spelled in details. It is x86_64 and Linux centric
since those are the only ones that I am quite familiar with.

Can modify them in the future to describe other architectures as well.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:35:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:35:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSWm-0002I8-5c; Tue, 29 Nov 2011 18:35:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVSWk-0002Hv-IW
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:35:34 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322591685!57028684!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25805 invoked from network); 29 Nov 2011 18:34:46 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 18:34:46 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATIYss3005200
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 13:34:54 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATIYsZJ005198;
	Tue, 29 Nov 2011 13:34:54 -0500
MIME-Version: 1.0
Message-Id: <patchbomb.1322591626@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 29 Nov 2011 13:33:46 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 8
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0 of 2] Documentation patches for
	HYPERVISOR_mmu_update (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Documenting some of the requirements when using HYPERVISOR_mmu_update
that are not spelled in details. It is x86_64 and Linux centric
since those are the only ones that I am quite familiar with.

Can modify them in the future to describe other architectures as well.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:35:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:35:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSWr-0002Ij-W5; Tue, 29 Nov 2011 18:35:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVSWr-0002I7-A8
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:35:41 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322591701!3597069!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11320 invoked from network); 29 Nov 2011 18:35:03 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 18:35:03 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATIYsfn005207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 13:34:54 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATIYsWu005205;
	Tue, 29 Nov 2011 13:34:54 -0500
MIME-Version: 1.0
X-Mercurial-Node: 789429b7859a6791cb0a08ba93064b50c9272218
Message-Id: <789429b7859a6791cb0a.1322591627@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1322591626@phenom.dumpdata.com>
References: <patchbomb.1322591626@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 29 Nov 2011 13:33:47 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 59
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1 of 2] doc: Update MMU_NORMAL_PT_UPDATE
	requirements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1322586121 18000
# Node ID 789429b7859a6791cb0a08ba93064b50c9272218
# Parent  a2cb7ed6d0a2ee5aecb3a988750ce9c8d8b718ee
doc: Update MMU_NORMAL_PT_UPDATE requirements.

There are some implicit requirements when using the hypercall
which are not mentioned.

Mainly the requirement that the pagetable be RO.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r a2cb7ed6d0a2 -r 789429b7859a xen/include/public/xen.h
--- a/xen/include/public/xen.h	Mon Nov 28 17:42:40 2011 +0000
+++ b/xen/include/public/xen.h	Tue Nov 29 12:02:01 2011 -0500
@@ -187,6 +187,40 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * FD == DOMID_XEN: Map restricted areas of Xen's heap space.
  * ptr[:2]  -- Machine address of the page-table entry to modify.
  * val      -- Value to write.
+ *
+ * There also certain implicit requirements when using this hypercall. The
+ * pages that make up a pagetable must be mapped read-only in the guest.
+ * This prevents uncontrolled guest updates to the pagetable. Xen strictly
+ * enforces this, and will disallow any pagetable update which will end up
+ * mapping pagetable page RW, and will disallow using any writable page as a
+ * pagetable. In practice it means that when constructing a page table for a
+ * process, thread, etc, we MUST be very dilligient in following these rules:
+ *  1). Start with top-level page (PGD or in Xen language: L4). Fill out
+ *      the entries.
+ *  2). Keep on going, filling out the upper (PUD or L3), and middle (PMD
+ *      or L2).
+ *  3). Start filling out the PTE table (L1) with the PTE entries. Once
+ *  	done, make sure to set each of those entries to RO (so writeable bit
+ *  	is unset). Once that has been completed, set the PMD (L2) for this
+ *  	PTE table as RO.
+ *  4). When completed with all of the PMD (L2) entries, and all of them have
+ *  	been set to RO, make sure to set RO the PUD (L3). Do the same
+ *  	operation on PGD (L4) pagetable entries that have a PUD (L3) entry.
+ *  5). Now before you can use those pages (so setting the cr3), you MUST also
+ *      pin them so that the hypervisor can verify the entries. This is done
+ *      via the HYPERVISOR_mmuext_op(MMUEXT_PIN_L4_TABLE, guest physical frame
+ *      number of the PGD (L4)). And this point the HYPERVISOR_mmuext_op(
+ *      MMUEXT_NEW_BASEPTR, guest physical frame number of the PGD (L4)) can be
+ *      issued.
+ * For 32-bit guests, the L4 is not used (as there is less pagetables), so
+ * instead use L3.
+ * At this point the pagetables can be modified using the MMU_NORMAL_PT_UPDATE
+ * hypercall. Also if so desired the OS can also try to write to the PTE
+ * and be trapped by the hypervisor (as the PTE entry is RO).
+ *
+ * To deallocate the pages, the operations are the reverse of the steps
+ * mentioned above. The argument is MMUEXT_UNPIN_TABLE for all levels and the
+ * pagetable MUST not be in use (meaning that the cr3 is not set to it).
  * 
  * ptr[1:0] == MMU_MACHPHYS_UPDATE:
  * Updates an entry in the machine->pseudo-physical mapping table.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:35:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:35:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSWr-0002Ij-W5; Tue, 29 Nov 2011 18:35:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVSWr-0002I7-A8
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:35:41 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322591701!3597069!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11320 invoked from network); 29 Nov 2011 18:35:03 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 18:35:03 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATIYsfn005207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 13:34:54 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATIYsWu005205;
	Tue, 29 Nov 2011 13:34:54 -0500
MIME-Version: 1.0
X-Mercurial-Node: 789429b7859a6791cb0a08ba93064b50c9272218
Message-Id: <789429b7859a6791cb0a.1322591627@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1322591626@phenom.dumpdata.com>
References: <patchbomb.1322591626@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 29 Nov 2011 13:33:47 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 59
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1 of 2] doc: Update MMU_NORMAL_PT_UPDATE
	requirements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1322586121 18000
# Node ID 789429b7859a6791cb0a08ba93064b50c9272218
# Parent  a2cb7ed6d0a2ee5aecb3a988750ce9c8d8b718ee
doc: Update MMU_NORMAL_PT_UPDATE requirements.

There are some implicit requirements when using the hypercall
which are not mentioned.

Mainly the requirement that the pagetable be RO.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r a2cb7ed6d0a2 -r 789429b7859a xen/include/public/xen.h
--- a/xen/include/public/xen.h	Mon Nov 28 17:42:40 2011 +0000
+++ b/xen/include/public/xen.h	Tue Nov 29 12:02:01 2011 -0500
@@ -187,6 +187,40 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * FD == DOMID_XEN: Map restricted areas of Xen's heap space.
  * ptr[:2]  -- Machine address of the page-table entry to modify.
  * val      -- Value to write.
+ *
+ * There also certain implicit requirements when using this hypercall. The
+ * pages that make up a pagetable must be mapped read-only in the guest.
+ * This prevents uncontrolled guest updates to the pagetable. Xen strictly
+ * enforces this, and will disallow any pagetable update which will end up
+ * mapping pagetable page RW, and will disallow using any writable page as a
+ * pagetable. In practice it means that when constructing a page table for a
+ * process, thread, etc, we MUST be very dilligient in following these rules:
+ *  1). Start with top-level page (PGD or in Xen language: L4). Fill out
+ *      the entries.
+ *  2). Keep on going, filling out the upper (PUD or L3), and middle (PMD
+ *      or L2).
+ *  3). Start filling out the PTE table (L1) with the PTE entries. Once
+ *  	done, make sure to set each of those entries to RO (so writeable bit
+ *  	is unset). Once that has been completed, set the PMD (L2) for this
+ *  	PTE table as RO.
+ *  4). When completed with all of the PMD (L2) entries, and all of them have
+ *  	been set to RO, make sure to set RO the PUD (L3). Do the same
+ *  	operation on PGD (L4) pagetable entries that have a PUD (L3) entry.
+ *  5). Now before you can use those pages (so setting the cr3), you MUST also
+ *      pin them so that the hypervisor can verify the entries. This is done
+ *      via the HYPERVISOR_mmuext_op(MMUEXT_PIN_L4_TABLE, guest physical frame
+ *      number of the PGD (L4)). And this point the HYPERVISOR_mmuext_op(
+ *      MMUEXT_NEW_BASEPTR, guest physical frame number of the PGD (L4)) can be
+ *      issued.
+ * For 32-bit guests, the L4 is not used (as there is less pagetables), so
+ * instead use L3.
+ * At this point the pagetables can be modified using the MMU_NORMAL_PT_UPDATE
+ * hypercall. Also if so desired the OS can also try to write to the PTE
+ * and be trapped by the hypervisor (as the PTE entry is RO).
+ *
+ * To deallocate the pages, the operations are the reverse of the steps
+ * mentioned above. The argument is MMUEXT_UNPIN_TABLE for all levels and the
+ * pagetable MUST not be in use (meaning that the cr3 is not set to it).
  * 
  * ptr[1:0] == MMU_MACHPHYS_UPDATE:
  * Updates an entry in the machine->pseudo-physical mapping table.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:36:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:36:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSWr-0002IY-Je; Tue, 29 Nov 2011 18:35:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVSWp-0002Hw-Fj
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:35:39 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322591579!46338466!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24753 invoked from network); 29 Nov 2011 18:33:00 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 18:33:00 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATIYtPF005214
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 13:34:55 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATIYtGS005212;
	Tue, 29 Nov 2011 13:34:55 -0500
MIME-Version: 1.0
X-Mercurial-Node: f2d0c5fee64cdad8c9c04bd2c7cf44a7183345d5
Message-Id: <f2d0c5fee64cdad8c9c0.1322591628@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1322591626@phenom.dumpdata.com>
References: <patchbomb.1322591626@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 29 Nov 2011 13:33:48 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 90
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2 of 2] doc: Update MMU_NORMAL_PT_UPDATE about
	the val
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1322591439 18000
# Node ID f2d0c5fee64cdad8c9c04bd2c7cf44a7183345d5
# Parent  789429b7859a6791cb0a08ba93064b50c9272218
doc: Update MMU_NORMAL_PT_UPDATE about the val.

The val is used as the pagetable entry with the machine
frame number and some page table bits. This explains
what those page table bits are.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r 789429b7859a -r f2d0c5fee64c xen/include/public/xen.h
--- a/xen/include/public/xen.h	Tue Nov 29 12:02:01 2011 -0500
+++ b/xen/include/public/xen.h	Tue Nov 29 13:30:39 2011 -0500
@@ -231,6 +231,72 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * ptr[1:0] == MMU_PT_UPDATE_PRESERVE_AD:
  * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
  * with those in @val.
+ *
+ * @val is usually the machine frame number along with some attributes.
+ * The attributes by default follow the architecture defined bits. Meaning that
+ * if this is a X86_64 machine and four page table layout is used, the layout
+ * of val is:
+ *  - 63 if set means No execute (NX)
+ *  - 46-13 the machine frame number
+ *  - 12 available for guest
+ *  - 11 available for guest
+ *  - 10 available for guest
+ *  - 9 available for guest
+ *  - 8 global
+ *  - 7 PAT (PSE is disabled, must use hypercall to make 4MB or 2MB pages)
+ *  - 6 dirty
+ *  - 5 accessed
+ *  - 4 page cached disabled
+ *  - 3 page write through
+ *  - 2 userspace accessible
+ *  - 1 writeable
+ *  - 0 present
+ *
+ *  The one bits that does not fit with the default layout is the PAGE_PSE
+ *  also called PAGE_PAT). The MMUEXT_[UN]MARK_SUPER arguments to the
+ *  HYPERVISOR_mmuext_op serve as mechanism to set a pagetable to be 4MB
+ *  (or 2MB) instead of using the PAGE_PSE bit.
+ *
+ *  The reason that the PAGE_PSE (bit 7) is not being utilized is due to Xen
+ *  using it as the Page Attribute Table (PAT) bit - for details on it please
+ *  refer to Intel SDM 10.12. The PAT allows to set the caching attributes of
+ *  pages instead of using MTRRs.
+ *
+ *  The PAT MSR is as follow (it is a 64-bit value, each entry is 8 bits):
+ *             PAT4                 PAT0
+ *   +---+----+----+----+-----+----+----+
+ *    WC | WC | WB | UC | UC- | WC | WB |  <= Linux
+ *   +---+----+----+----+-----+----+----+
+ *    WC | WT | WB | UC | UC- | WT | WB |  <= BIOS (default when machine boots)
+ *   +---+----+----+----+-----+----+----+
+ *    WC | WP | WC | UC | UC- | WT | WB |  <= Xen
+ *   +---+----+----+----+-----+----+----+
+ *
+ *  The lookup of this index table translates to looking up
+ *  Bit 7, Bit 4, and Bit 3 of val entry:
+ *
+ *  PAT/PSE (bit 7) ... PCD (bit 4) .. PWT (bit 3).
+ *
+ *  If all bits are off, then we are using PAT0. If bit 3 turned on,
+ *  then we are using PAT1, if bit 3 and bit 4, then PAT2..
+ *
+ *  As you can see, the Linux PAT1 translates to PAT4 under Xen. Which means
+ *  that if a guest that follows Linux's PAT setup and would like to set Write
+ *  Combined on pages it MUST use PAT4 entry. Meaning that Bit 7 (PAGE_PAT) is
+ *  set. For example, under Linux it only uses PAT0, PAT1, and PAT2 for the
+ *  caching as:
+ *
+ *   WB = none (so PAT0)
+ *   WC = PWT (bit 3 on)
+ *   UC = PWT | PCD (bit 3 and 4 are on).
+ *
+ * To make it work with Xen, it needs to translate the WC bit as so:
+ *
+ *  PWT (so bit 3 on) --> PAT (so bit 7 is on) and clear bit 3
+ *
+ * And to translate back it would:
+ *
+ * PAT (bit 7 on) --> PWT (bit 3 on) and clear bit 7.
  */
 #define MMU_NORMAL_PT_UPDATE      0 /* checked '*ptr = val'. ptr is MA.      */
 #define MMU_MACHPHYS_UPDATE       1 /* ptr = MA of frame to modify entry for */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:36:00 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:36:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSWr-0002IY-Je; Tue, 29 Nov 2011 18:35:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVSWp-0002Hw-Fj
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:35:39 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322591579!46338466!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24753 invoked from network); 29 Nov 2011 18:33:00 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 18:33:00 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATIYtPF005214
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 13:34:55 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATIYtGS005212;
	Tue, 29 Nov 2011 13:34:55 -0500
MIME-Version: 1.0
X-Mercurial-Node: f2d0c5fee64cdad8c9c04bd2c7cf44a7183345d5
Message-Id: <f2d0c5fee64cdad8c9c0.1322591628@phenom.dumpdata.com>
In-Reply-To: <patchbomb.1322591626@phenom.dumpdata.com>
References: <patchbomb.1322591626@phenom.dumpdata.com>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 29 Nov 2011 13:33:48 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	stefano.stabellini@eu.citrix.com, Ian.Campbell@citrix.com
Status: RO
Lines: 90
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2 of 2] doc: Update MMU_NORMAL_PT_UPDATE about
	the val
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1322591439 18000
# Node ID f2d0c5fee64cdad8c9c04bd2c7cf44a7183345d5
# Parent  789429b7859a6791cb0a08ba93064b50c9272218
doc: Update MMU_NORMAL_PT_UPDATE about the val.

The val is used as the pagetable entry with the machine
frame number and some page table bits. This explains
what those page table bits are.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff -r 789429b7859a -r f2d0c5fee64c xen/include/public/xen.h
--- a/xen/include/public/xen.h	Tue Nov 29 12:02:01 2011 -0500
+++ b/xen/include/public/xen.h	Tue Nov 29 13:30:39 2011 -0500
@@ -231,6 +231,72 @@ DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
  * ptr[1:0] == MMU_PT_UPDATE_PRESERVE_AD:
  * As MMU_NORMAL_PT_UPDATE above, but A/D bits currently in the PTE are ORed
  * with those in @val.
+ *
+ * @val is usually the machine frame number along with some attributes.
+ * The attributes by default follow the architecture defined bits. Meaning that
+ * if this is a X86_64 machine and four page table layout is used, the layout
+ * of val is:
+ *  - 63 if set means No execute (NX)
+ *  - 46-13 the machine frame number
+ *  - 12 available for guest
+ *  - 11 available for guest
+ *  - 10 available for guest
+ *  - 9 available for guest
+ *  - 8 global
+ *  - 7 PAT (PSE is disabled, must use hypercall to make 4MB or 2MB pages)
+ *  - 6 dirty
+ *  - 5 accessed
+ *  - 4 page cached disabled
+ *  - 3 page write through
+ *  - 2 userspace accessible
+ *  - 1 writeable
+ *  - 0 present
+ *
+ *  The one bits that does not fit with the default layout is the PAGE_PSE
+ *  also called PAGE_PAT). The MMUEXT_[UN]MARK_SUPER arguments to the
+ *  HYPERVISOR_mmuext_op serve as mechanism to set a pagetable to be 4MB
+ *  (or 2MB) instead of using the PAGE_PSE bit.
+ *
+ *  The reason that the PAGE_PSE (bit 7) is not being utilized is due to Xen
+ *  using it as the Page Attribute Table (PAT) bit - for details on it please
+ *  refer to Intel SDM 10.12. The PAT allows to set the caching attributes of
+ *  pages instead of using MTRRs.
+ *
+ *  The PAT MSR is as follow (it is a 64-bit value, each entry is 8 bits):
+ *             PAT4                 PAT0
+ *   +---+----+----+----+-----+----+----+
+ *    WC | WC | WB | UC | UC- | WC | WB |  <= Linux
+ *   +---+----+----+----+-----+----+----+
+ *    WC | WT | WB | UC | UC- | WT | WB |  <= BIOS (default when machine boots)
+ *   +---+----+----+----+-----+----+----+
+ *    WC | WP | WC | UC | UC- | WT | WB |  <= Xen
+ *   +---+----+----+----+-----+----+----+
+ *
+ *  The lookup of this index table translates to looking up
+ *  Bit 7, Bit 4, and Bit 3 of val entry:
+ *
+ *  PAT/PSE (bit 7) ... PCD (bit 4) .. PWT (bit 3).
+ *
+ *  If all bits are off, then we are using PAT0. If bit 3 turned on,
+ *  then we are using PAT1, if bit 3 and bit 4, then PAT2..
+ *
+ *  As you can see, the Linux PAT1 translates to PAT4 under Xen. Which means
+ *  that if a guest that follows Linux's PAT setup and would like to set Write
+ *  Combined on pages it MUST use PAT4 entry. Meaning that Bit 7 (PAGE_PAT) is
+ *  set. For example, under Linux it only uses PAT0, PAT1, and PAT2 for the
+ *  caching as:
+ *
+ *   WB = none (so PAT0)
+ *   WC = PWT (bit 3 on)
+ *   UC = PWT | PCD (bit 3 and 4 are on).
+ *
+ * To make it work with Xen, it needs to translate the WC bit as so:
+ *
+ *  PWT (so bit 3 on) --> PAT (so bit 7 is on) and clear bit 3
+ *
+ * And to translate back it would:
+ *
+ * PAT (bit 7 on) --> PWT (bit 3 on) and clear bit 7.
  */
 #define MMU_NORMAL_PT_UPDATE      0 /* checked '*ptr = val'. ptr is MA.      */
 #define MMU_MACHPHYS_UPDATE       1 /* ptr = MA of frame to modify entry for */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:48:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:48:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSir-0002mv-A9; Tue, 29 Nov 2011 18:48:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVSiq-0002mq-2M
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:48:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322592445!3559439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22521 invoked from network); 29 Nov 2011 18:47:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 18:47:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; 
   d="scan'208";a="9193171"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 18:47:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 18:47:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVSi1-0005Ex-A8; Tue, 29 Nov 2011 18:47:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVSi0-00085M-WA;
	Tue, 29 Nov 2011 18:47:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20181.10416.816658.739846@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 18:47:12 +0000
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <patchbomb.1322591626@phenom.dumpdata.com>
References: <patchbomb.1322591626@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 2] Documentation patches for
	HYPERVISOR_mmu_update (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk writes ("[PATCH 0 of 2] Documentation patches for HYPERVISOR_mmu_update (v1)."):
> Documenting some of the requirements when using HYPERVISOR_mmu_update
> that are not spelled in details. It is x86_64 and Linux centric
> since those are the only ones that I am quite familiar with.

Both applied, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:48:22 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:48:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSir-0002mv-A9; Tue, 29 Nov 2011 18:48:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVSiq-0002mq-2M
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:48:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322592445!3559439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22521 invoked from network); 29 Nov 2011 18:47:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 18:47:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; 
   d="scan'208";a="9193171"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 18:47:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 18:47:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVSi1-0005Ex-A8; Tue, 29 Nov 2011 18:47:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVSi0-00085M-WA;
	Tue, 29 Nov 2011 18:47:13 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20181.10416.816658.739846@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 18:47:12 +0000
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <patchbomb.1322591626@phenom.dumpdata.com>
References: <patchbomb.1322591626@phenom.dumpdata.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 2] Documentation patches for
	HYPERVISOR_mmu_update (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Konrad Rzeszutek Wilk writes ("[PATCH 0 of 2] Documentation patches for HYPERVISOR_mmu_update (v1)."):
> Documenting some of the requirements when using HYPERVISOR_mmu_update
> that are not spelled in details. It is x86_64 and Linux centric
> since those are the only ones that I am quite familiar with.

Both applied, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:57:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSs3-000326-M2; Tue, 29 Nov 2011 18:57:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVSs1-000321-PV
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:57:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322592985!44769470!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17050 invoked from network); 29 Nov 2011 18:56:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 18:56:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315195200"; d="scan'208";a="19499593"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 13:56:59 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	13:56:58 -0500
Message-ID: <4ED52AF9.2080200@citrix.com>
Date: Tue, 29 Nov 2011 18:56:57 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------010304000302060203010307"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------010304000302060203010307
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

As I have little to no knowledge of this stage of the boot process, is
this a sensible way to be setting up the per_cpu areas?  I have a
sneaking suspicion that it will fall over if a CPU is onlined after
boot, and may also fall over if a CPU is offlined and reonlined later. 
There appears to be no infrastructure currently in place for this type
of initialization, which is quite possibly why the code exists in its
current form.

Thanks,

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------010304000302060203010307
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 0a0c02a61676 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -154,6 +154,50 @@ void __init set_kexec_crash_area_size(u6
     }
 }
 
+/* Allocate Xen Crash Note buffers. */
+static __init int kexec_notes_init(void)
+{
+    int c;
+    Elf_Note * note;
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    int nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_into note. */
+    int cpu0_nr_bytes = nr_bytes +
+        sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    for ( c = 0; c < num_online_cpus(); ++c )
+    {
+        note = xmalloc_bytes( c ? nr_bytes : cpu0_nr_bytes );
+        if ( ! note )
+            return -ENOMEM;
+
+        per_cpu(crash_notes, c) = note;
+
+        /* Setup CORE note. */
+        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+        note = ELFNOTE_NEXT(note);
+
+        /* Setup Xen CORE note. */
+        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+                   sizeof(crash_xen_core_t));
+
+        if ( 0 == c )
+        {
+            /* Set up Xen Crash Info note. */
+            xen_crash_note = note = ELFNOTE_NEXT(note);
+            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                       sizeof(crash_xen_info_t));
+        }
+    }
+
+    return 0;
+}
+__initcall(kexec_notes_init);
+
 static void one_cpu_only(void)
 {
     /* Only allow the first cpu to continue - force other cpus to spin */
@@ -306,30 +350,6 @@ static int kexec_get_cpu(xen_kexec_range
     if ( nr == 0 )
         nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
     range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
     range->size = nr_bytes;
     return 0;

--------------010304000302060203010307
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------010304000302060203010307--


From xen-devel-bounces@lists.xensource.com Tue Nov 29 18:57:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 18:57:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSs3-000326-M2; Tue, 29 Nov 2011 18:57:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVSs1-000321-PV
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 18:57:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1322592985!44769470!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17050 invoked from network); 29 Nov 2011 18:56:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 18:56:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315195200"; d="scan'208";a="19499593"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 13:56:59 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 Nov 2011
	13:56:58 -0500
Message-ID: <4ED52AF9.2080200@citrix.com>
Date: Tue, 29 Nov 2011 18:56:57 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------010304000302060203010307"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------010304000302060203010307
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

As I have little to no knowledge of this stage of the boot process, is
this a sensible way to be setting up the per_cpu areas?  I have a
sneaking suspicion that it will fall over if a CPU is onlined after
boot, and may also fall over if a CPU is offlined and reonlined later. 
There appears to be no infrastructure currently in place for this type
of initialization, which is quite possibly why the code exists in its
current form.

Thanks,

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------010304000302060203010307
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 0a0c02a61676 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -154,6 +154,50 @@ void __init set_kexec_crash_area_size(u6
     }
 }
 
+/* Allocate Xen Crash Note buffers. */
+static __init int kexec_notes_init(void)
+{
+    int c;
+    Elf_Note * note;
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    int nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_into note. */
+    int cpu0_nr_bytes = nr_bytes +
+        sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    for ( c = 0; c < num_online_cpus(); ++c )
+    {
+        note = xmalloc_bytes( c ? nr_bytes : cpu0_nr_bytes );
+        if ( ! note )
+            return -ENOMEM;
+
+        per_cpu(crash_notes, c) = note;
+
+        /* Setup CORE note. */
+        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+        note = ELFNOTE_NEXT(note);
+
+        /* Setup Xen CORE note. */
+        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+                   sizeof(crash_xen_core_t));
+
+        if ( 0 == c )
+        {
+            /* Set up Xen Crash Info note. */
+            xen_crash_note = note = ELFNOTE_NEXT(note);
+            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                       sizeof(crash_xen_info_t));
+        }
+    }
+
+    return 0;
+}
+__initcall(kexec_notes_init);
+
 static void one_cpu_only(void)
 {
     /* Only allow the first cpu to continue - force other cpus to spin */
@@ -306,30 +350,6 @@ static int kexec_get_cpu(xen_kexec_range
     if ( nr == 0 )
         nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
     range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
     range->size = nr_bytes;
     return 0;

--------------010304000302060203010307
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------010304000302060203010307--


From xen-devel-bounces@lists.xensource.com Tue Nov 29 19:01:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 19:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSvs-0003Dn-E4; Tue, 29 Nov 2011 19:01:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVSvr-0003DM-OP
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 19:01:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322593254!3598745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15331 invoked from network); 29 Nov 2011 19:00:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 19:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; 
   d="scan'208";a="9193310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 19:00:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 19:00:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVSvF-0005JR-Kl; Tue, 29 Nov 2011 19:00:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVSvF-0003KZ-DZ;
	Tue, 29 Nov 2011 19:00:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20181.11234.856756.986930@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 19:00:50 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322562449.20646.31.camel@zakaz.uk.xensource.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-5-git-send-email-ian.jackson@eu.citrix.com>
	<1322562449.20646.31.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/13] libxl: idl: support new "c_only" type
 attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/13] libxl: idl: support new "c_only" type attribute"):
> On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> > This provides for fields in libxl datatypes which are only present in
> > the C version of structures.  This is useful, for example, when a
> > libxl datatype wants to contain fields which are used by libxl
> > internally and which are only present in the structure to avoid
> > additional memory allocation inconvenience.
> 
> I think "internal" or "private" would be a better description than "c".

OK.  I picked "private".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 19:01:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 19:01:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVSvs-0003Dn-E4; Tue, 29 Nov 2011 19:01:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVSvr-0003DM-OP
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 19:01:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322593254!3598745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15331 invoked from network); 29 Nov 2011 19:00:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 19:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; 
   d="scan'208";a="9193310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 19:00:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 19:00:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVSvF-0005JR-Kl; Tue, 29 Nov 2011 19:00:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVSvF-0003KZ-DZ;
	Tue, 29 Nov 2011 19:00:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20181.11234.856756.986930@mariner.uk.xensource.com>
Date: Tue, 29 Nov 2011 19:00:50 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322562449.20646.31.camel@zakaz.uk.xensource.com>
References: <1322499580-2322-1-git-send-email-ian.jackson@eu.citrix.com>
	<1322499580-2322-5-git-send-email-ian.jackson@eu.citrix.com>
	<1322562449.20646.31.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/13] libxl: idl: support new "c_only" type
 attribute
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 04/13] libxl: idl: support new "c_only" type attribute"):
> On Mon, 2011-11-28 at 16:59 +0000, Ian Jackson wrote:
> > This provides for fields in libxl datatypes which are only present in
> > the C version of structures.  This is useful, for example, when a
> > libxl datatype wants to contain fields which are used by libxl
> > internally and which are only present in the structure to avoid
> > additional memory allocation inconvenience.
> 
> I think "internal" or "private" would be a better description than "c".

OK.  I picked "private".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 19:10:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 19:10:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVT4L-0003Z1-Fl; Tue, 29 Nov 2011 19:10:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1RVT4J-0003Yw-Te
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 19:10:16 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322593778!5529140!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20671 invoked from network); 29 Nov 2011 19:09:38 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 19:09:38 -0000
Received: by bkbzt12 with SMTP id zt12so13857720bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 11:09:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=SG86IcAyIu8P/5sMZaQLF1SR62LSkakdCFbmVY5Ne94=;
	b=fapBJW+Ph1GAmJ81T3kujgVmWTSNvWAQOCdwNOp+du4ZpQ7aEP9yPcf4nQmjF67r7Y
	H30gDXCAWeHGr3zHDSjB/0fhJxvza0i1+2NF5X9LXyzWTlct2yGNiNSljoAXYGDZSYpq
	gAr9dDX0p+S2fe3oLxWJeKfoFzd6oGbXC11VM=
MIME-Version: 1.0
Received: by 10.204.152.83 with SMTP id f19mr51803744bkw.90.1322593777765;
	Tue, 29 Nov 2011 11:09:37 -0800 (PST)
Received: by 10.204.66.77 with HTTP; Tue, 29 Nov 2011 11:09:37 -0800 (PST)
Date: Tue, 29 Nov 2011 13:09:37 -0600
Message-ID: <CAKLFbfx+iB4=zG_D7GnUZ8pnksGVo33Eoz2PznENs5KpuQMbNA@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Guest virtual address translation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3479988054844542949=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3479988054844542949==
Content-Type: multipart/alternative; boundary=0015175d02e44e4eac04b2e45cb3

--0015175d02e44e4eac04b2e45cb3
Content-Type: text/plain; charset=ISO-8859-1

Hi All,

Are there any functions to translate a guest's virtual address to guest's
physical address (GFN) in Xen?

Thanks and regards,
~ SDK

--0015175d02e44e4eac04b2e45cb3
Content-Type: text/html; charset=ISO-8859-1

Hi All,<div><br></div><div>Are there any functions to translate a guest&#39;s virtual address to guest&#39;s physical address (GFN) in Xen?</div><div><br></div><div>Thanks and regards,<br clear="all">~ SDK<br><br>
</div>

--0015175d02e44e4eac04b2e45cb3--


--===============3479988054844542949==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3479988054844542949==--


From xen-devel-bounces@lists.xensource.com Tue Nov 29 19:10:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 19:10:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVT4L-0003Z1-Fl; Tue, 29 Nov 2011 19:10:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1RVT4J-0003Yw-Te
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 19:10:16 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322593778!5529140!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20671 invoked from network); 29 Nov 2011 19:09:38 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 19:09:38 -0000
Received: by bkbzt12 with SMTP id zt12so13857720bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 11:09:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=SG86IcAyIu8P/5sMZaQLF1SR62LSkakdCFbmVY5Ne94=;
	b=fapBJW+Ph1GAmJ81T3kujgVmWTSNvWAQOCdwNOp+du4ZpQ7aEP9yPcf4nQmjF67r7Y
	H30gDXCAWeHGr3zHDSjB/0fhJxvza0i1+2NF5X9LXyzWTlct2yGNiNSljoAXYGDZSYpq
	gAr9dDX0p+S2fe3oLxWJeKfoFzd6oGbXC11VM=
MIME-Version: 1.0
Received: by 10.204.152.83 with SMTP id f19mr51803744bkw.90.1322593777765;
	Tue, 29 Nov 2011 11:09:37 -0800 (PST)
Received: by 10.204.66.77 with HTTP; Tue, 29 Nov 2011 11:09:37 -0800 (PST)
Date: Tue, 29 Nov 2011 13:09:37 -0600
Message-ID: <CAKLFbfx+iB4=zG_D7GnUZ8pnksGVo33Eoz2PznENs5KpuQMbNA@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Guest virtual address translation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3479988054844542949=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3479988054844542949==
Content-Type: multipart/alternative; boundary=0015175d02e44e4eac04b2e45cb3

--0015175d02e44e4eac04b2e45cb3
Content-Type: text/plain; charset=ISO-8859-1

Hi All,

Are there any functions to translate a guest's virtual address to guest's
physical address (GFN) in Xen?

Thanks and regards,
~ SDK

--0015175d02e44e4eac04b2e45cb3
Content-Type: text/html; charset=ISO-8859-1

Hi All,<div><br></div><div>Are there any functions to translate a guest&#39;s virtual address to guest&#39;s physical address (GFN) in Xen?</div><div><br></div><div>Thanks and regards,<br clear="all">~ SDK<br><br>
</div>

--0015175d02e44e4eac04b2e45cb3--


--===============3479988054844542949==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3479988054844542949==--


From xen-devel-bounces@lists.xensource.com Tue Nov 29 19:14:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 19:14:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVT8M-0003g7-6M; Tue, 29 Nov 2011 19:14:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVT8K-0003fw-84
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 19:14:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322593924!54212018!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25279 invoked from network); 29 Nov 2011 19:12:05 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 19:12:05 -0000
Received: by qyk29 with SMTP id 29so3651663qyk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 11:13:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cO8iC+DtAxm74wLo/7rtTnNhRJS/OH5vdie0TvHOmus=;
	b=AeAE/2Uep54SRrVogCWWTaRPdnWewZb8em7DC8sC8omZRAV1Gm8hYQ/li/IOapd3pY
	QUYzrdY0b99TLRK5bzDFxnxk/TKHbndyAgd5T2n+I/f+kHgzqrolpw6ooowU5F6gk3KN
	/rJPAaHVPAmoLgLscpCcQrvW+v7RpqzE0YDL8=
Received: by 10.229.213.131 with SMTP id gw3mr502360qcb.298.1322594030058;
	Tue, 29 Nov 2011 11:13:50 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id o8sm12895124qaz.4.2011.11.29.11.13.46
	(version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 11:13:49 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 29 Nov 2011 11:13:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paul Durrant <Paul.Durrant@citrix.com>,
	Ross Philipson <Ross.Philipson@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAFA6EE7.25E33%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a package
	called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIAAAJ5LcAACUPfPAAAr/AAAA82dWA==
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4F3D@LONPMAILBOX01.citrite.net>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pick a name and I can fix it up. :-)

 -- Keir

On 29/11/2011 17:25, "Paul Durrant" <Paul.Durrant@citrix.com> wrote:

> Keir,
> 
> Do you want me to re-send that patch or will you fix it up?
> 
>   Paul
> 
>> -----Original Message-----
>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>> Sent: 29 November 2011 09:20
>> To: Ross Philipson; Paul Durrant; xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing
>> a package called ADDR, evaluating to two
>> 
>> On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com>
>> wrote:
>> 
>>>> I have no problem choosing a different _HID. I just don't have a
>> good
>>>> reference for what name is not going to clash with something
>> else.
>>>> Looks like ACPI0001 was a bad guess. Any better suggestions? What
>> are
>>>> the 'generic PNP device IDs'?
>>>> 
>>>>   Paul
>>> 
>>> Well I actually brought it up as a discussion point. I have the
>> same
>>> sort of issue - I have a generic device for a virtualized
>> environment.
>>> I don't really want it to be recognized as anything specific. I
>> guess I see three options:
>>> 
>>>  - Use an unassigned APCIXXXX string. I believe the _HID string
>> values
>>> of the form "ACPIXXXX" are defined by the ACPI specs themselves so
>>> this may not work in the long run.
>>>  - Use one of the predefined generic container EisaId PNP values.
>> By
>>> that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at
>> the
>>> Linux generic container driver, it doesn't do very much with these
>>> devices so that might be OK.
>> 
>> This option sounds reasonable. We have freedom to change it in
>> future if it turns out to be a bad choice, not that I can see why it
>> would be.
>> 
>>  -- Keir
>> 
>>>  - Acquire a vendor specific EisaId range for Xen (e.g.
>>> EisaId(XENABCD)). Then we could carve up the product number part
>> of the ID as we see fit.
>> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 19:14:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 19:14:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVT8M-0003g7-6M; Tue, 29 Nov 2011 19:14:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVT8K-0003fw-84
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 19:14:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322593924!54212018!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25279 invoked from network); 29 Nov 2011 19:12:05 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 19:12:05 -0000
Received: by qyk29 with SMTP id 29so3651663qyk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 11:13:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cO8iC+DtAxm74wLo/7rtTnNhRJS/OH5vdie0TvHOmus=;
	b=AeAE/2Uep54SRrVogCWWTaRPdnWewZb8em7DC8sC8omZRAV1Gm8hYQ/li/IOapd3pY
	QUYzrdY0b99TLRK5bzDFxnxk/TKHbndyAgd5T2n+I/f+kHgzqrolpw6ooowU5F6gk3KN
	/rJPAaHVPAmoLgLscpCcQrvW+v7RpqzE0YDL8=
Received: by 10.229.213.131 with SMTP id gw3mr502360qcb.298.1322594030058;
	Tue, 29 Nov 2011 11:13:50 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id o8sm12895124qaz.4.2011.11.29.11.13.46
	(version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 11:13:49 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 29 Nov 2011 11:13:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paul Durrant <Paul.Durrant@citrix.com>,
	Ross Philipson <Ross.Philipson@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAFA6EE7.25E33%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a package
	called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIAAAJ5LcAACUPfPAAAr/AAAA82dWA==
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5988E4F3D@LONPMAILBOX01.citrite.net>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pick a name and I can fix it up. :-)

 -- Keir

On 29/11/2011 17:25, "Paul Durrant" <Paul.Durrant@citrix.com> wrote:

> Keir,
> 
> Do you want me to re-send that patch or will you fix it up?
> 
>   Paul
> 
>> -----Original Message-----
>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>> Sent: 29 November 2011 09:20
>> To: Ross Philipson; Paul Durrant; xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing
>> a package called ADDR, evaluating to two
>> 
>> On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com>
>> wrote:
>> 
>>>> I have no problem choosing a different _HID. I just don't have a
>> good
>>>> reference for what name is not going to clash with something
>> else.
>>>> Looks like ACPI0001 was a bad guess. Any better suggestions? What
>> are
>>>> the 'generic PNP device IDs'?
>>>> 
>>>>   Paul
>>> 
>>> Well I actually brought it up as a discussion point. I have the
>> same
>>> sort of issue - I have a generic device for a virtualized
>> environment.
>>> I don't really want it to be recognized as anything specific. I
>> guess I see three options:
>>> 
>>>  - Use an unassigned APCIXXXX string. I believe the _HID string
>> values
>>> of the form "ACPIXXXX" are defined by the ACPI specs themselves so
>>> this may not work in the long run.
>>>  - Use one of the predefined generic container EisaId PNP values.
>> By
>>> that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at
>> the
>>> Linux generic container driver, it doesn't do very much with these
>>> devices so that might be OK.
>> 
>> This option sounds reasonable. We have freedom to change it in
>> future if it turns out to be a bad choice, not that I can see why it
>> would be.
>> 
>>  -- Keir
>> 
>>>  - Acquire a vendor specific EisaId range for Xen (e.g.
>>> EisaId(XENABCD)). Then we could carve up the product number part
>> of the ID as we see fit.
>> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 19:26:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 19:26:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVTJk-0003tg-Hx; Tue, 29 Nov 2011 19:26:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVTJi-0003tb-70
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 19:26:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322594731!556403!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24806 invoked from network); 29 Nov 2011 19:25:32 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 19:25:32 -0000
Received: by qyk29 with SMTP id 29so3667169qyk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 11:25:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0XuJInYioHTC2zj363G0oBqYQnqNaxjrvwdWfpecmm8=;
	b=bCT6YAdRB411gd+5ejTUoeXNt6FBU7c6slKgZG2TzgDrIoQ179mbFaQUcgzd4WDNXo
	ke8OohVuqsNu/M37pgsv9sbaMz19WkcKsd7EPcblqtnzR4+QTQzr5anzKlyhZBkC6EVf
	rLcZCCQUvSnh05Z84lrmhPGQsTnhGUqarBYf4=
Received: by 10.224.194.137 with SMTP id dy9mr23850250qab.65.1322594357272;
	Tue, 29 Nov 2011 11:19:17 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id ha3sm38651032qab.2.2011.11.29.11.19.05
	(version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 11:19:16 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 29 Nov 2011 11:19:03 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>
Message-ID: <CAFA7027.25E35%keir.xen@gmail.com>
Thread-Topic: [RFC] KEXEC: allocate crash note buffers at boot time
Thread-Index: Acyuy8E16kFM3ASPOUy5T1x4fLu0Mg==
In-Reply-To: <4ED52AF9.2080200@citrix.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/2011 18:56, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> Hello,
> 
> As I have little to no knowledge of this stage of the boot process, is
> this a sensible way to be setting up the per_cpu areas?  I have a
> sneaking suspicion that it will fall over if a CPU is onlined after
> boot, and may also fall over if a CPU is offlined and reonlined later.
> There appears to be no infrastructure currently in place for this type
> of initialization, which is quite possibly why the code exists in its
> current form.

No it's bad. For starters you should use for_each_online_cpu, not do an
open-coded for-loop. Secondly you should register a cpu hotplug notifier
(register_cpu_notifier()) to pick up and handle future
CPU_UP_PREPARE/CPU_UP_CANCELED/CPU_DEAD events. This can be hung off an
__initcall. See common/stop_machine.c for example, or common/timer.c, which
doesn't even require a for_each_online_cpu loop because its init code gets
run before we bring up secondary CPUs.

 -- Keir 

> Thanks,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 19:26:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 19:26:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVTJk-0003tg-Hx; Tue, 29 Nov 2011 19:26:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVTJi-0003tb-70
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 19:26:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322594731!556403!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24806 invoked from network); 29 Nov 2011 19:25:32 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 19:25:32 -0000
Received: by qyk29 with SMTP id 29so3667169qyk.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 11:25:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0XuJInYioHTC2zj363G0oBqYQnqNaxjrvwdWfpecmm8=;
	b=bCT6YAdRB411gd+5ejTUoeXNt6FBU7c6slKgZG2TzgDrIoQ179mbFaQUcgzd4WDNXo
	ke8OohVuqsNu/M37pgsv9sbaMz19WkcKsd7EPcblqtnzR4+QTQzr5anzKlyhZBkC6EVf
	rLcZCCQUvSnh05Z84lrmhPGQsTnhGUqarBYf4=
Received: by 10.224.194.137 with SMTP id dy9mr23850250qab.65.1322594357272;
	Tue, 29 Nov 2011 11:19:17 -0800 (PST)
Received: from [192.168.0.132] ([142.103.56.220])
	by mx.google.com with ESMTPS id ha3sm38651032qab.2.2011.11.29.11.19.05
	(version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 11:19:16 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 29 Nov 2011 11:19:03 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, Jan Beulich <JBeulich@suse.com>
Message-ID: <CAFA7027.25E35%keir.xen@gmail.com>
Thread-Topic: [RFC] KEXEC: allocate crash note buffers at boot time
Thread-Index: Acyuy8E16kFM3ASPOUy5T1x4fLu0Mg==
In-Reply-To: <4ED52AF9.2080200@citrix.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/2011 18:56, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> Hello,
> 
> As I have little to no knowledge of this stage of the boot process, is
> this a sensible way to be setting up the per_cpu areas?  I have a
> sneaking suspicion that it will fall over if a CPU is onlined after
> boot, and may also fall over if a CPU is offlined and reonlined later.
> There appears to be no infrastructure currently in place for this type
> of initialization, which is quite possibly why the code exists in its
> current form.

No it's bad. For starters you should use for_each_online_cpu, not do an
open-coded for-loop. Secondly you should register a cpu hotplug notifier
(register_cpu_notifier()) to pick up and handle future
CPU_UP_PREPARE/CPU_UP_CANCELED/CPU_DEAD events. This can be hung off an
__initcall. See common/stop_machine.c for example, or common/timer.c, which
doesn't even require a for_each_online_cpu loop because its init code gets
run before we bring up secondary CPUs.

 -- Keir 

> Thanks,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 19:47:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 19:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVTdr-0004EA-EK; Tue, 29 Nov 2011 19:46:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RVTdq-0004E5-F0
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 19:46:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322595980!5550757!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22997 invoked from network); 29 Nov 2011 19:46:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 19:46:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RVTdD-0002oy-1Y; Tue, 29 Nov 2011 19:46:19 +0000
Date: Tue, 29 Nov 2011 19:46:18 +0000
From: Tim Deegan <tim@xen.org>
To: Srujan Kotikela <ksrujandas@gmail.com>
Message-ID: <20111129194618.GA10787@ocelot.phlegethon.org>
References: <CAKLFbfx+iB4=zG_D7GnUZ8pnksGVo33Eoz2PznENs5KpuQMbNA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKLFbfx+iB4=zG_D7GnUZ8pnksGVo33Eoz2PznENs5KpuQMbNA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Guest virtual address translation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 13:09 -0600 on 29 Nov (1322572177), Srujan Kotikela wrote:
> Hi All,
> 
> Are there any functions to translate a guest's virtual address to guest's
> physical address (GFN) in Xen?

Yes.  In the hypervisor there's paging_gva_to_gfn().  In the tools
there's xc_translate_foreign_address()

Tim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 19:47:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 19:47:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVTdr-0004EA-EK; Tue, 29 Nov 2011 19:46:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RVTdq-0004E5-F0
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 19:46:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322595980!5550757!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22997 invoked from network); 29 Nov 2011 19:46:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 19:46:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RVTdD-0002oy-1Y; Tue, 29 Nov 2011 19:46:19 +0000
Date: Tue, 29 Nov 2011 19:46:18 +0000
From: Tim Deegan <tim@xen.org>
To: Srujan Kotikela <ksrujandas@gmail.com>
Message-ID: <20111129194618.GA10787@ocelot.phlegethon.org>
References: <CAKLFbfx+iB4=zG_D7GnUZ8pnksGVo33Eoz2PznENs5KpuQMbNA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKLFbfx+iB4=zG_D7GnUZ8pnksGVo33Eoz2PznENs5KpuQMbNA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Guest virtual address translation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 13:09 -0600 on 29 Nov (1322572177), Srujan Kotikela wrote:
> Hi All,
> 
> Are there any functions to translate a guest's virtual address to guest's
> physical address (GFN) in Xen?

Yes.  In the hypervisor there's paging_gva_to_gfn().  In the tools
there's xc_translate_foreign_address()

Tim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCi-0004h3-Sv; Tue, 29 Nov 2011 20:23:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCg-0004es-T0
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322598137!6869972!3
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTU5ODg=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21564 invoked from network); 29 Nov 2011 20:22:20 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.145) by server-2.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 20:22:20 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 2191933406B;
	Tue, 29 Nov 2011 12:22:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=VhfVq5UfazYjvA9cCWVVuA2C/V8LmLzG+h7/qOyks2EG
	IIToos/6WtoaWMqgTEzEbJ9j1nf2FlEcd2S820xDCw0GqICpQBJQuzA2FD8Fl4by
	ptk6aMT/PLM847IQhfDTqso3mgt+PFsMT30Exioh7o2iCejtVhKM/dAxjD3mL8U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=nTYxtYkbDMUrBvxPOGWumJljd7k=; b=U41QGHd9yVX
	X8NSXI7M8Ig/pFV+imNR1B/7lsYIGc9vc9kDyo9QIcJzxqgZiJmlfna8aWMMe7/4
	C/G1Oq1Cf5hLpdqO0n3HpwCKYqtcjM4TiucU0N/vDKt1TfNaLT5rQiEeGnOEfG+8
	2mCkqb7APEZ+4uTBtVOTqwq8WjfYI8JM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id D2D2A334063; 
	Tue, 29 Nov 2011 12:22:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5286ed662c1e26823999cdf3244ebe2ca9c55ec0
Message-Id: <5286ed662c1e26823999.1322598104@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:44 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 9] Tools: Add libxc wrapper for p2m audit
	domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_domain.c |  22 ++++++++++++++++++++++
 tools/libxc/xenctrl.h   |  27 +++++++++++++++++++++++++++
 2 files changed, 49 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 6626add0fef6 -r 5286ed662c1e tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1472,6 +1472,28 @@ int xc_domain_debug_control(xc_interface
     return do_domctl(xc, &domctl);
 }
 
+int xc_domain_p2m_audit(xc_interface *xch, 
+                        uint32_t domid,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,   
+                        uint64_t *p2m_bad)
+{
+    DECLARE_DOMCTL;
+    int rc;
+
+    domctl.cmd = XEN_DOMCTL_audit_p2m;
+    domctl.domain = domid;
+    rc = do_domctl(xch, &domctl);
+
+    *orphans_debug      = domctl.u.audit_p2m.orphans_debug;
+    *orphans_invalid    = domctl.u.audit_p2m.orphans_invalid;
+    *m2p_bad            = domctl.u.audit_p2m.m2p_bad;
+    *p2m_bad            = domctl.u.audit_p2m.p2m_bad;
+
+    return rc;
+}
+
 int xc_domain_set_access_required(xc_interface *xch,
                                   uint32_t domid,
                                   unsigned int required)
diff -r 6626add0fef6 -r 5286ed662c1e tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -712,6 +712,33 @@ int xc_domain_setdebugging(xc_interface 
                            unsigned int enable);
 
 /**
+ * This function audits the (top level) p2m of a domain 
+ * and returns the different error counts, if any.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id whose top level p2m we 
+ *       want to audit
+ * @parm orphans_debug count of m2p entries for valid
+ *       domain pages containing a debug value
+ * @parm orphans_invalid count of m2p entries for valid
+ *       domain pages containing an invalid value
+ * @parm m2p_bad count of m2p entries mismatching the
+ *       associated p2m entry for this domain
+ * @parm p2m_bad count of p2m entries for this domain
+ *       mismatching the associated m2p entry
+ * return 0 on success, -1 on failure
+ * errno values on failure include: 
+ *          -ENOSYS: not implemented
+ *          -EFAULT: could not copy results back to guest
+ */
+int xc_domain_p2m_audit(xc_interface *xch,
+				        uint32_t domid,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,   
+                        uint64_t *p2m_bad);
+
+/**
  * This function sets or clears the requirement that an access memory
  * event listener is required on the domain.
  *

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCY-0004e4-II; Tue, 29 Nov 2011 20:22:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCW-0004dt-Mw
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322598130!5194690!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDY3MQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32383 invoked from network); 29 Nov 2011 20:22:10 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 20:22:10 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id D6C8733406B;
	Tue, 29 Nov 2011 12:22:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=Ol50MuvWY5SrC2I8fOqqgQ
	EO/6FdV88dZWzcAATwU4oUBLNulTWZezcKldtKaz4aJLXQn0aOZDc1gn8PnPos8J
	xkZi94I1/adXPP202FBDqbvELrM/+bPmrjONOV+cBbaoDKh66wRyp8CQSFXGA7mR
	2K4hhp7tkcZ8BVVr8sVtY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=HV77lG2xYanI
	WIvmFeOUH8O0WkU=; b=g7Bw6tIvkscRVykyzwA8Emzw2a580oFUH8HaPUMNVMoY
	iyz/6PdnmEPsBRffM/5830VWNOpEU60lxkzEXFTwMY1uTbS5RVjpo5/nHM748bfd
	rCEHsU0osGB9jHGvvV9R28ptzsRaz9zb0vXvUvTdFIytqIdhKNVowmfYvYYKATw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id B1799334063; 
	Tue, 29 Nov 2011 12:22:07 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:37 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 9] MM Bug fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series includes a number of bug fixes previously
submitted, or newly found, for the mm layer.

Patches 1 and 7 are tool patches, cc'ed tool maintainers. Everything 
else is hypervisors-x86-mm.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 tools/libxc/xc_domain.c           |    2 +
 xen/arch/x86/mm/shadow/common.c   |    6 +-
 xen/arch/x86/mm/shadow/multi.c    |    2 +-
 xen/arch/x86/mm/shadow/private.h  |    7 +
 xen/arch/x86/mm/paging.c          |    2 +-
 xen/include/asm-x86/page.h        |    1 +
 xen/include/asm-x86/x86_32/page.h |   11 +++
 xen/include/asm-x86/x86_64/page.h |    5 +
 xen/arch/x86/hvm/hvm.c            |   44 +++++++----
 xen/arch/x86/hvm/svm/nestedsvm.c  |    6 -
 xen/arch/x86/hvm/vmx/vvmx.c       |   17 +---
 xen/arch/x86/domctl.c             |   30 ++++++++
 xen/arch/x86/mm/p2m-ept.c         |    1 +
 xen/arch/x86/mm/p2m-pod.c         |    5 -
 xen/arch/x86/mm/p2m-pt.c          |  137 ++++++-------------------------------
 xen/arch/x86/mm/p2m.c             |  124 +++++++++++++++++++++++++++++++---
 xen/include/asm-x86/p2m.h         |   11 +-
 xen/include/public/domctl.h       |   12 +++
 tools/libxc/xc_domain.c           |   22 ++++++
 tools/libxc/xenctrl.h             |   27 +++++++
 xen/arch/x86/mm.c                 |    3 +-
 xen/arch/x86/mm/mem_sharing.c     |    3 +
 xen/include/asm-x86/p2m.h         |    3 +-
 23 files changed, 302 insertions(+), 179 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCi-0004h3-Sv; Tue, 29 Nov 2011 20:23:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCg-0004es-T0
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322598137!6869972!3
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTU5ODg=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21564 invoked from network); 29 Nov 2011 20:22:20 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.145) by server-2.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 20:22:20 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 2191933406B;
	Tue, 29 Nov 2011 12:22:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=VhfVq5UfazYjvA9cCWVVuA2C/V8LmLzG+h7/qOyks2EG
	IIToos/6WtoaWMqgTEzEbJ9j1nf2FlEcd2S820xDCw0GqICpQBJQuzA2FD8Fl4by
	ptk6aMT/PLM847IQhfDTqso3mgt+PFsMT30Exioh7o2iCejtVhKM/dAxjD3mL8U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=nTYxtYkbDMUrBvxPOGWumJljd7k=; b=U41QGHd9yVX
	X8NSXI7M8Ig/pFV+imNR1B/7lsYIGc9vc9kDyo9QIcJzxqgZiJmlfna8aWMMe7/4
	C/G1Oq1Cf5hLpdqO0n3HpwCKYqtcjM4TiucU0N/vDKt1TfNaLT5rQiEeGnOEfG+8
	2mCkqb7APEZ+4uTBtVOTqwq8WjfYI8JM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id D2D2A334063; 
	Tue, 29 Nov 2011 12:22:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5286ed662c1e26823999cdf3244ebe2ca9c55ec0
Message-Id: <5286ed662c1e26823999.1322598104@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:44 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 9] Tools: Add libxc wrapper for p2m audit
	domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_domain.c |  22 ++++++++++++++++++++++
 tools/libxc/xenctrl.h   |  27 +++++++++++++++++++++++++++
 2 files changed, 49 insertions(+), 0 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 6626add0fef6 -r 5286ed662c1e tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1472,6 +1472,28 @@ int xc_domain_debug_control(xc_interface
     return do_domctl(xc, &domctl);
 }
 
+int xc_domain_p2m_audit(xc_interface *xch, 
+                        uint32_t domid,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,   
+                        uint64_t *p2m_bad)
+{
+    DECLARE_DOMCTL;
+    int rc;
+
+    domctl.cmd = XEN_DOMCTL_audit_p2m;
+    domctl.domain = domid;
+    rc = do_domctl(xch, &domctl);
+
+    *orphans_debug      = domctl.u.audit_p2m.orphans_debug;
+    *orphans_invalid    = domctl.u.audit_p2m.orphans_invalid;
+    *m2p_bad            = domctl.u.audit_p2m.m2p_bad;
+    *p2m_bad            = domctl.u.audit_p2m.p2m_bad;
+
+    return rc;
+}
+
 int xc_domain_set_access_required(xc_interface *xch,
                                   uint32_t domid,
                                   unsigned int required)
diff -r 6626add0fef6 -r 5286ed662c1e tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -712,6 +712,33 @@ int xc_domain_setdebugging(xc_interface 
                            unsigned int enable);
 
 /**
+ * This function audits the (top level) p2m of a domain 
+ * and returns the different error counts, if any.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id whose top level p2m we 
+ *       want to audit
+ * @parm orphans_debug count of m2p entries for valid
+ *       domain pages containing a debug value
+ * @parm orphans_invalid count of m2p entries for valid
+ *       domain pages containing an invalid value
+ * @parm m2p_bad count of m2p entries mismatching the
+ *       associated p2m entry for this domain
+ * @parm p2m_bad count of p2m entries for this domain
+ *       mismatching the associated m2p entry
+ * return 0 on success, -1 on failure
+ * errno values on failure include: 
+ *          -ENOSYS: not implemented
+ *          -EFAULT: could not copy results back to guest
+ */
+int xc_domain_p2m_audit(xc_interface *xch,
+				        uint32_t domid,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,   
+                        uint64_t *p2m_bad);
+
+/**
  * This function sets or clears the requirement that an access memory
  * event listener is required on the domain.
  *

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCY-0004e4-II; Tue, 29 Nov 2011 20:22:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCW-0004dt-Mw
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322598130!5194690!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDY3MQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32383 invoked from network); 29 Nov 2011 20:22:10 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.74) by server-14.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 20:22:10 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id D6C8733406B;
	Tue, 29 Nov 2011 12:22:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=Ol50MuvWY5SrC2I8fOqqgQ
	EO/6FdV88dZWzcAATwU4oUBLNulTWZezcKldtKaz4aJLXQn0aOZDc1gn8PnPos8J
	xkZi94I1/adXPP202FBDqbvELrM/+bPmrjONOV+cBbaoDKh66wRyp8CQSFXGA7mR
	2K4hhp7tkcZ8BVVr8sVtY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=HV77lG2xYanI
	WIvmFeOUH8O0WkU=; b=g7Bw6tIvkscRVykyzwA8Emzw2a580oFUH8HaPUMNVMoY
	iyz/6PdnmEPsBRffM/5830VWNOpEU60lxkzEXFTwMY1uTbS5RVjpo5/nHM748bfd
	rCEHsU0osGB9jHGvvV9R28ptzsRaz9zb0vXvUvTdFIytqIdhKNVowmfYvYYKATw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id B1799334063; 
	Tue, 29 Nov 2011 12:22:07 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:37 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 9] MM Bug fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series includes a number of bug fixes previously
submitted, or newly found, for the mm layer.

Patches 1 and 7 are tool patches, cc'ed tool maintainers. Everything 
else is hypervisors-x86-mm.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 tools/libxc/xc_domain.c           |    2 +
 xen/arch/x86/mm/shadow/common.c   |    6 +-
 xen/arch/x86/mm/shadow/multi.c    |    2 +-
 xen/arch/x86/mm/shadow/private.h  |    7 +
 xen/arch/x86/mm/paging.c          |    2 +-
 xen/include/asm-x86/page.h        |    1 +
 xen/include/asm-x86/x86_32/page.h |   11 +++
 xen/include/asm-x86/x86_64/page.h |    5 +
 xen/arch/x86/hvm/hvm.c            |   44 +++++++----
 xen/arch/x86/hvm/svm/nestedsvm.c  |    6 -
 xen/arch/x86/hvm/vmx/vvmx.c       |   17 +---
 xen/arch/x86/domctl.c             |   30 ++++++++
 xen/arch/x86/mm/p2m-ept.c         |    1 +
 xen/arch/x86/mm/p2m-pod.c         |    5 -
 xen/arch/x86/mm/p2m-pt.c          |  137 ++++++-------------------------------
 xen/arch/x86/mm/p2m.c             |  124 +++++++++++++++++++++++++++++++---
 xen/include/asm-x86/p2m.h         |   11 +-
 xen/include/public/domctl.h       |   12 +++
 tools/libxc/xc_domain.c           |   22 ++++++
 tools/libxc/xenctrl.h             |   27 +++++++
 xen/arch/x86/mm.c                 |    3 +-
 xen/arch/x86/mm/mem_sharing.c     |    3 +
 xen/include/asm-x86/p2m.h         |    3 +-
 23 files changed, 302 insertions(+), 179 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCf-0004fn-0t; Tue, 29 Nov 2011 20:22:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCd-0004e7-Vt
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322598137!5195703!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDY3MQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7134 invoked from network); 29 Nov 2011 20:22:17 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.74) by server-10.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 20:22:17 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id CCFA333406B;
	Tue, 29 Nov 2011 12:22:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=HElGh5tc7I73bx73jyYaTlaFK9g5GQSnCLWxeQn0+qR5
	ahezASnXzFfsd5KPYukTrW+g3NF89TZllLSBP27C8FNimqLMbLJ5RUmMB3rz8SqS
	3/GzUEOu+b/5eeX4Orwbw+X7v4z6dKMvR1ZTvKChfyd/sB9G6ANZqbteStRd4AY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=757l3LMfAxd8i3t6VtFIGnf3Nxc=; b=c2aQiAwOIl+
	7NQGCCP51OkTrRJ0w3siGtggxzjum+cAKiRsvUQgiElZEjR+mKzu4RpstvG/4xEy
	wKlPRUyYe4zKdNtmpM+pnLuU+xchCaiEjN2iJYBFjXv6kxVoyrPCtKV2drOKCo1y
	zDgSf62ZNJtatMnI1xZS0vpW3JMbJBVY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 89EB3334063; 
	Tue, 29 Nov 2011 12:22:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b2097819f2d9f70870574d6b73d5392d306e7698
Message-Id: <b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:42 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 9] x86/mm: Ensure maps used by nested hvm
 code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c           |  44 ++++++++++++++++++++++++---------------
 xen/arch/x86/hvm/svm/nestedsvm.c |   6 -----
 xen/arch/x86/hvm/vmx/vvmx.c      |  13 ++---------
 3 files changed, 30 insertions(+), 33 deletions(-)


The nested hvm code maps pages of the guest hvm. These maps live beyond
a hypervisor entry/exit pair, and thus their liveness cannot be ensured
with get_gfn/put_gfn critical sections. Ensure their liveness by
increasing the page ref count, instead.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 42e6ceb8138d -r b2097819f2d9 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1801,11 +1801,14 @@ int hvm_virtual_to_linear_addr(
     return 0;
 }
 
-/* We leave this function holding a lock on the p2m entry */
+/* On non-NULL return, we leave this function holding an additional 
+ * ref on the underlying mfn, if any */
 static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
 {
+    void *map;
     unsigned long mfn;
     p2m_type_t p2mt;
+    struct page_info *pg;
     struct domain *d = current->domain;
 
     mfn = mfn_x(writable
@@ -1828,7 +1831,12 @@ static void *__hvm_map_guest_frame(unsig
     if ( writable )
         paging_mark_dirty(d, mfn);
 
-    return map_domain_page(mfn);
+    pg = mfn_to_page(mfn);
+    page_get_owner_and_reference(pg);
+
+    map = map_domain_page(mfn);
+    put_gfn(d, gfn);
+    return map;
 }
 
 void *hvm_map_guest_frame_rw(unsigned long gfn)
@@ -1844,11 +1852,16 @@ void *hvm_map_guest_frame_ro(unsigned lo
 void hvm_unmap_guest_frame(void *p)
 {
     if ( p )
+    {
+        unsigned long mfn = xen_map_to_mfn(p);
         unmap_domain_page(p);
+        put_page(mfn_to_page(mfn));
+    }
 }
 
-static void *hvm_map_entry(unsigned long va, unsigned long *gfn)
+static void *hvm_map_entry(unsigned long va)
 {
+    unsigned long gfn;
     uint32_t pfec;
     char *v;
 
@@ -1865,11 +1878,11 @@ static void *hvm_map_entry(unsigned long
      * treat it as a kernel-mode read (i.e. no access checks).
      */
     pfec = PFEC_page_present;
-    *gfn = paging_gva_to_gfn(current, va, &pfec);
+    gfn = paging_gva_to_gfn(current, va, &pfec);
     if ( (pfec == PFEC_page_paged) || (pfec == PFEC_page_shared) )
         goto fail;
 
-    v = hvm_map_guest_frame_rw(*gfn);
+    v = hvm_map_guest_frame_rw(gfn);
     if ( v == NULL )
         goto fail;
 
@@ -1880,11 +1893,9 @@ static void *hvm_map_entry(unsigned long
     return NULL;
 }
 
-static void hvm_unmap_entry(void *p, unsigned long gfn)
+static void hvm_unmap_entry(void *p)
 {
     hvm_unmap_guest_frame(p);
-    if ( p && (gfn != INVALID_GFN) )
-        put_gfn(current->domain, gfn);
 }
 
 static int hvm_load_segment_selector(
@@ -1896,7 +1907,6 @@ static int hvm_load_segment_selector(
     int fault_type = TRAP_invalid_tss;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct vcpu *v = current;
-    unsigned long pdesc_gfn = INVALID_GFN;
 
     if ( regs->eflags & X86_EFLAGS_VM )
     {
@@ -1930,7 +1940,7 @@ static int hvm_load_segment_selector(
     if ( ((sel & 0xfff8) + 7) > desctab.limit )
         goto fail;
 
-    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_gfn);
+    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8));
     if ( pdesc == NULL )
         goto hvm_map_fail;
 
@@ -1990,7 +2000,7 @@ static int hvm_load_segment_selector(
     desc.b |= 0x100;
 
  skip_accessed_flag:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc);
 
     segr.base = (((desc.b <<  0) & 0xff000000u) |
                  ((desc.b << 16) & 0x00ff0000u) |
@@ -2006,7 +2016,7 @@ static int hvm_load_segment_selector(
     return 0;
 
  unmap_and_fail:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc);
  fail:
     hvm_inject_exception(fault_type, sel & 0xfffc, 0);
  hvm_map_fail:
@@ -2021,7 +2031,7 @@ void hvm_task_switch(
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct segment_register gdt, tr, prev_tr, segr;
     struct desc_struct *optss_desc = NULL, *nptss_desc = NULL, tss_desc;
-    unsigned long eflags, optss_gfn = INVALID_GFN, nptss_gfn = INVALID_GFN;
+    unsigned long eflags;
     int exn_raised, rc;
     struct {
         u16 back_link,__blh;
@@ -2047,11 +2057,11 @@ void hvm_task_switch(
         goto out;
     }
 
-    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), &optss_gfn);
+    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8)); 
     if ( optss_desc == NULL )
         goto out;
 
-    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), &nptss_gfn);
+    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8)); 
     if ( nptss_desc == NULL )
         goto out;
 
@@ -2216,8 +2226,8 @@ void hvm_task_switch(
     }
 
  out:
-    hvm_unmap_entry(optss_desc, optss_gfn);
-    hvm_unmap_entry(nptss_desc, nptss_gfn);
+    hvm_unmap_entry(optss_desc);
+    hvm_unmap_entry(nptss_desc);
 }
 
 #define HVMCOPY_from_guest (0u<<0)
diff -r 42e6ceb8138d -r b2097819f2d9 xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -81,10 +81,6 @@ int nestedsvm_vmcb_map(struct vcpu *v, u
         if (nv->nv_vvmcx == NULL)
             return 0;
         nv->nv_vvmcxaddr = vmcbaddr;
-        /* put_gfn here even though the map survives beyond this caller.
-         * The map can likely survive beyond a hypervisor exit, thus we
-         * need to put the gfn */
-        put_gfn(current->domain, vmcbaddr >> PAGE_SHIFT);
     }
 
     return 1;
@@ -358,7 +354,6 @@ static int nsvm_vmrun_permissionmap(stru
     ioport_80 = test_bit(0x80, ns_viomap);
     ioport_ed = test_bit(0xed, ns_viomap);
     hvm_unmap_guest_frame(ns_viomap);
-    put_gfn(current->domain, svm->ns_iomap_pa >> PAGE_SHIFT);
 
     svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
 
@@ -889,7 +884,6 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
 
     enabled = test_bit(port, io_bitmap);
     hvm_unmap_guest_frame(io_bitmap);
-    put_gfn(current->domain, gfn);
 
     if (!enabled)
         return NESTEDHVM_VMEXIT_HOST;
diff -r 42e6ceb8138d -r b2097819f2d9 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -560,10 +560,7 @@ static void __map_io_bitmap(struct vcpu 
     if (nvmx->iobitmap[index])
         hvm_unmap_guest_frame (nvmx->iobitmap[index]); 
     gpa = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, vmcs_reg);
-    nvmx->iobitmap[index] = hvm_map_guest_frame_ro (gpa >> PAGE_SHIFT);
-    /* See comment in nestedsvm_vmcb_map re putting this gfn and 
-     * liveness of the map it backs */
-    put_gfn(current->domain, gpa >> PAGE_SHIFT);
+    nvmx->iobitmap[index] = hvm_map_guest_frame_ro(gpa >> PAGE_SHIFT);
 }
 
 static inline void map_io_bitmap_all(struct vcpu *v)
@@ -581,7 +578,7 @@ static void nvmx_purge_vvmcs(struct vcpu
     __clear_current_vvmcs(v);
     if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
         hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
-    nvcpu->nv_vvmcx == NULL;
+    nvcpu->nv_vvmcx = NULL;
     nvcpu->nv_vvmcxaddr = VMCX_EADDR;
     for (i=0; i<2; i++) {
         if ( nvmx->iobitmap[i] ) {
@@ -1138,12 +1135,9 @@ int nvmx_handle_vmptrld(struct cpu_user_
 
     if ( nvcpu->nv_vvmcxaddr == VMCX_EADDR )
     {
-        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw (gpa >> PAGE_SHIFT);
+        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT);
         nvcpu->nv_vvmcxaddr = gpa;
         map_io_bitmap_all (v);
-        /* See comment in nestedsvm_vmcb_map regarding putting this 
-         * gfn and liveness of the map that uses it */
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
     }
 
     vmreturn(regs, VMSUCCEED);
@@ -1205,7 +1199,6 @@ int nvmx_handle_vmclear(struct cpu_user_
         if ( vvmcs ) 
             __set_vvmcs(vvmcs, NVMX_LAUNCH_STATE, 0);
         hvm_unmap_guest_frame(vvmcs);
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
     }
 
     vmreturn(regs, VMSUCCEED);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCf-0004fn-0t; Tue, 29 Nov 2011 20:22:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCd-0004e7-Vt
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:56 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322598137!5195703!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDY3MQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7134 invoked from network); 29 Nov 2011 20:22:17 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.74) by server-10.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 20:22:17 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id CCFA333406B;
	Tue, 29 Nov 2011 12:22:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=HElGh5tc7I73bx73jyYaTlaFK9g5GQSnCLWxeQn0+qR5
	ahezASnXzFfsd5KPYukTrW+g3NF89TZllLSBP27C8FNimqLMbLJ5RUmMB3rz8SqS
	3/GzUEOu+b/5eeX4Orwbw+X7v4z6dKMvR1ZTvKChfyd/sB9G6ANZqbteStRd4AY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=757l3LMfAxd8i3t6VtFIGnf3Nxc=; b=c2aQiAwOIl+
	7NQGCCP51OkTrRJ0w3siGtggxzjum+cAKiRsvUQgiElZEjR+mKzu4RpstvG/4xEy
	wKlPRUyYe4zKdNtmpM+pnLuU+xchCaiEjN2iJYBFjXv6kxVoyrPCtKV2drOKCo1y
	zDgSf62ZNJtatMnI1xZS0vpW3JMbJBVY=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 89EB3334063; 
	Tue, 29 Nov 2011 12:22:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b2097819f2d9f70870574d6b73d5392d306e7698
Message-Id: <b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:42 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 9] x86/mm: Ensure maps used by nested hvm
 code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c           |  44 ++++++++++++++++++++++++---------------
 xen/arch/x86/hvm/svm/nestedsvm.c |   6 -----
 xen/arch/x86/hvm/vmx/vvmx.c      |  13 ++---------
 3 files changed, 30 insertions(+), 33 deletions(-)


The nested hvm code maps pages of the guest hvm. These maps live beyond
a hypervisor entry/exit pair, and thus their liveness cannot be ensured
with get_gfn/put_gfn critical sections. Ensure their liveness by
increasing the page ref count, instead.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 42e6ceb8138d -r b2097819f2d9 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1801,11 +1801,14 @@ int hvm_virtual_to_linear_addr(
     return 0;
 }
 
-/* We leave this function holding a lock on the p2m entry */
+/* On non-NULL return, we leave this function holding an additional 
+ * ref on the underlying mfn, if any */
 static void *__hvm_map_guest_frame(unsigned long gfn, bool_t writable)
 {
+    void *map;
     unsigned long mfn;
     p2m_type_t p2mt;
+    struct page_info *pg;
     struct domain *d = current->domain;
 
     mfn = mfn_x(writable
@@ -1828,7 +1831,12 @@ static void *__hvm_map_guest_frame(unsig
     if ( writable )
         paging_mark_dirty(d, mfn);
 
-    return map_domain_page(mfn);
+    pg = mfn_to_page(mfn);
+    page_get_owner_and_reference(pg);
+
+    map = map_domain_page(mfn);
+    put_gfn(d, gfn);
+    return map;
 }
 
 void *hvm_map_guest_frame_rw(unsigned long gfn)
@@ -1844,11 +1852,16 @@ void *hvm_map_guest_frame_ro(unsigned lo
 void hvm_unmap_guest_frame(void *p)
 {
     if ( p )
+    {
+        unsigned long mfn = xen_map_to_mfn(p);
         unmap_domain_page(p);
+        put_page(mfn_to_page(mfn));
+    }
 }
 
-static void *hvm_map_entry(unsigned long va, unsigned long *gfn)
+static void *hvm_map_entry(unsigned long va)
 {
+    unsigned long gfn;
     uint32_t pfec;
     char *v;
 
@@ -1865,11 +1878,11 @@ static void *hvm_map_entry(unsigned long
      * treat it as a kernel-mode read (i.e. no access checks).
      */
     pfec = PFEC_page_present;
-    *gfn = paging_gva_to_gfn(current, va, &pfec);
+    gfn = paging_gva_to_gfn(current, va, &pfec);
     if ( (pfec == PFEC_page_paged) || (pfec == PFEC_page_shared) )
         goto fail;
 
-    v = hvm_map_guest_frame_rw(*gfn);
+    v = hvm_map_guest_frame_rw(gfn);
     if ( v == NULL )
         goto fail;
 
@@ -1880,11 +1893,9 @@ static void *hvm_map_entry(unsigned long
     return NULL;
 }
 
-static void hvm_unmap_entry(void *p, unsigned long gfn)
+static void hvm_unmap_entry(void *p)
 {
     hvm_unmap_guest_frame(p);
-    if ( p && (gfn != INVALID_GFN) )
-        put_gfn(current->domain, gfn);
 }
 
 static int hvm_load_segment_selector(
@@ -1896,7 +1907,6 @@ static int hvm_load_segment_selector(
     int fault_type = TRAP_invalid_tss;
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct vcpu *v = current;
-    unsigned long pdesc_gfn = INVALID_GFN;
 
     if ( regs->eflags & X86_EFLAGS_VM )
     {
@@ -1930,7 +1940,7 @@ static int hvm_load_segment_selector(
     if ( ((sel & 0xfff8) + 7) > desctab.limit )
         goto fail;
 
-    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8), &pdesc_gfn);
+    pdesc = hvm_map_entry(desctab.base + (sel & 0xfff8));
     if ( pdesc == NULL )
         goto hvm_map_fail;
 
@@ -1990,7 +2000,7 @@ static int hvm_load_segment_selector(
     desc.b |= 0x100;
 
  skip_accessed_flag:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc);
 
     segr.base = (((desc.b <<  0) & 0xff000000u) |
                  ((desc.b << 16) & 0x00ff0000u) |
@@ -2006,7 +2016,7 @@ static int hvm_load_segment_selector(
     return 0;
 
  unmap_and_fail:
-    hvm_unmap_entry(pdesc, pdesc_gfn);
+    hvm_unmap_entry(pdesc);
  fail:
     hvm_inject_exception(fault_type, sel & 0xfffc, 0);
  hvm_map_fail:
@@ -2021,7 +2031,7 @@ void hvm_task_switch(
     struct cpu_user_regs *regs = guest_cpu_user_regs();
     struct segment_register gdt, tr, prev_tr, segr;
     struct desc_struct *optss_desc = NULL, *nptss_desc = NULL, tss_desc;
-    unsigned long eflags, optss_gfn = INVALID_GFN, nptss_gfn = INVALID_GFN;
+    unsigned long eflags;
     int exn_raised, rc;
     struct {
         u16 back_link,__blh;
@@ -2047,11 +2057,11 @@ void hvm_task_switch(
         goto out;
     }
 
-    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8), &optss_gfn);
+    optss_desc = hvm_map_entry(gdt.base + (prev_tr.sel & 0xfff8)); 
     if ( optss_desc == NULL )
         goto out;
 
-    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8), &nptss_gfn);
+    nptss_desc = hvm_map_entry(gdt.base + (tss_sel & 0xfff8)); 
     if ( nptss_desc == NULL )
         goto out;
 
@@ -2216,8 +2226,8 @@ void hvm_task_switch(
     }
 
  out:
-    hvm_unmap_entry(optss_desc, optss_gfn);
-    hvm_unmap_entry(nptss_desc, nptss_gfn);
+    hvm_unmap_entry(optss_desc);
+    hvm_unmap_entry(nptss_desc);
 }
 
 #define HVMCOPY_from_guest (0u<<0)
diff -r 42e6ceb8138d -r b2097819f2d9 xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -81,10 +81,6 @@ int nestedsvm_vmcb_map(struct vcpu *v, u
         if (nv->nv_vvmcx == NULL)
             return 0;
         nv->nv_vvmcxaddr = vmcbaddr;
-        /* put_gfn here even though the map survives beyond this caller.
-         * The map can likely survive beyond a hypervisor exit, thus we
-         * need to put the gfn */
-        put_gfn(current->domain, vmcbaddr >> PAGE_SHIFT);
     }
 
     return 1;
@@ -358,7 +354,6 @@ static int nsvm_vmrun_permissionmap(stru
     ioport_80 = test_bit(0x80, ns_viomap);
     ioport_ed = test_bit(0xed, ns_viomap);
     hvm_unmap_guest_frame(ns_viomap);
-    put_gfn(current->domain, svm->ns_iomap_pa >> PAGE_SHIFT);
 
     svm->ns_iomap = nestedhvm_vcpu_iomap_get(ioport_80, ioport_ed);
 
@@ -889,7 +884,6 @@ nsvm_vmcb_guest_intercepts_ioio(paddr_t 
 
     enabled = test_bit(port, io_bitmap);
     hvm_unmap_guest_frame(io_bitmap);
-    put_gfn(current->domain, gfn);
 
     if (!enabled)
         return NESTEDHVM_VMEXIT_HOST;
diff -r 42e6ceb8138d -r b2097819f2d9 xen/arch/x86/hvm/vmx/vvmx.c
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -560,10 +560,7 @@ static void __map_io_bitmap(struct vcpu 
     if (nvmx->iobitmap[index])
         hvm_unmap_guest_frame (nvmx->iobitmap[index]); 
     gpa = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx, vmcs_reg);
-    nvmx->iobitmap[index] = hvm_map_guest_frame_ro (gpa >> PAGE_SHIFT);
-    /* See comment in nestedsvm_vmcb_map re putting this gfn and 
-     * liveness of the map it backs */
-    put_gfn(current->domain, gpa >> PAGE_SHIFT);
+    nvmx->iobitmap[index] = hvm_map_guest_frame_ro(gpa >> PAGE_SHIFT);
 }
 
 static inline void map_io_bitmap_all(struct vcpu *v)
@@ -581,7 +578,7 @@ static void nvmx_purge_vvmcs(struct vcpu
     __clear_current_vvmcs(v);
     if ( nvcpu->nv_vvmcxaddr != VMCX_EADDR )
         hvm_unmap_guest_frame(nvcpu->nv_vvmcx);
-    nvcpu->nv_vvmcx == NULL;
+    nvcpu->nv_vvmcx = NULL;
     nvcpu->nv_vvmcxaddr = VMCX_EADDR;
     for (i=0; i<2; i++) {
         if ( nvmx->iobitmap[i] ) {
@@ -1138,12 +1135,9 @@ int nvmx_handle_vmptrld(struct cpu_user_
 
     if ( nvcpu->nv_vvmcxaddr == VMCX_EADDR )
     {
-        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw (gpa >> PAGE_SHIFT);
+        nvcpu->nv_vvmcx = hvm_map_guest_frame_rw(gpa >> PAGE_SHIFT);
         nvcpu->nv_vvmcxaddr = gpa;
         map_io_bitmap_all (v);
-        /* See comment in nestedsvm_vmcb_map regarding putting this 
-         * gfn and liveness of the map that uses it */
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
     }
 
     vmreturn(regs, VMSUCCEED);
@@ -1205,7 +1199,6 @@ int nvmx_handle_vmclear(struct cpu_user_
         if ( vvmcs ) 
             __set_vvmcs(vvmcs, NVMX_LAUNCH_STATE, 0);
         hvm_unmap_guest_frame(vvmcs);
-        put_gfn(current->domain, gpa >> PAGE_SHIFT);
     }
 
     vmreturn(regs, VMSUCCEED);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCl-0004iC-QL; Tue, 29 Nov 2011 20:23:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCj-0004fT-Sd
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:23:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322598143!5548429!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0NTU5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20446 invoked from network); 29 Nov 2011 20:22:24 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.5) by server-8.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 20:22:24 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 1418A33406C;
	Tue, 29 Nov 2011 12:22:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=TZve+hHfv/x3CIhFv7xu23LrYK8ei4mFAJc7zDKfinsv
	tFPdNZysSfPf4iyaMAj6ZzlXhMJ5eQLMMdBwt1l7x5PHWiLJ7cQ8Uah1J/hLjZ0I
	fmYJlWL37tfbDuIIMdn9VL3J9Suhy7JMD+Isrf+wLzaRz4EjZqPM91NosO++rW0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=/vyizbZGZWfWrgUacVnNojac17k=; b=arrb/SJxGL3
	gOYnPUtqAzDVh53tl/rvZvDho7MiEQLJxquCC+zHL3PHKOm/aglzNvMmGL2/Qg2J
	doRDdjCqlFTeUUpqPAFMf0PLs544fwaJcMRcatPgAGBjYg3rqXa+ECe2hJB40ui1
	oz0vsfuOZb55eIBEZeYwXPNmxbruGwAo=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 12BC2334063; 
	Tue, 29 Nov 2011 12:22:21 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4ee6d40edc2cc6592450c0b9ef47ecd34f822e11
Message-Id: <4ee6d40edc2cc6592450.1322598106@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:46 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 9 of 9] x86/mm: Allow pages typed as log dirty
 to also be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  3 +++
 xen/include/asm-x86/p2m.h     |  3 ++-
 2 files changed, 5 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3489152b3a56 -r 4ee6d40edc2c xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -697,6 +697,9 @@ private_page_found:
     /* Update m2p entry */
     set_gpfn_from_mfn(mfn_x(page_to_mfn(page)), gfn);
 
+    /* Now that the gfn<->mfn map is properly established,
+     * marking dirty is feasible */
+    paging_mark_dirty(d, mfn_x(page_to_mfn(page)));
     put_gfn(d, gfn);
     shr_unlock();
     return 0;
diff -r 3489152b3a56 -r 4ee6d40edc2c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -163,7 +163,8 @@ typedef enum {
 /* Shared types */
 /* XXX: Sharable types could include p2m_ram_ro too, but we would need to
  * reinit the type correctly after fault */
-#define P2M_SHARABLE_TYPES (p2m_to_mask(p2m_ram_rw))
+#define P2M_SHARABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
+                            | p2m_to_mask(p2m_ram_logdirty) )
 #define P2M_SHARED_TYPES   (p2m_to_mask(p2m_ram_shared))
 
 /* Broken type: the frame backing this pfn has failed in hardware

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCl-0004iC-QL; Tue, 29 Nov 2011 20:23:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCj-0004fT-Sd
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:23:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322598143!5548429!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0NTU5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20446 invoked from network); 29 Nov 2011 20:22:24 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.5) by server-8.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 20:22:24 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 1418A33406C;
	Tue, 29 Nov 2011 12:22:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=TZve+hHfv/x3CIhFv7xu23LrYK8ei4mFAJc7zDKfinsv
	tFPdNZysSfPf4iyaMAj6ZzlXhMJ5eQLMMdBwt1l7x5PHWiLJ7cQ8Uah1J/hLjZ0I
	fmYJlWL37tfbDuIIMdn9VL3J9Suhy7JMD+Isrf+wLzaRz4EjZqPM91NosO++rW0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=/vyizbZGZWfWrgUacVnNojac17k=; b=arrb/SJxGL3
	gOYnPUtqAzDVh53tl/rvZvDho7MiEQLJxquCC+zHL3PHKOm/aglzNvMmGL2/Qg2J
	doRDdjCqlFTeUUpqPAFMf0PLs544fwaJcMRcatPgAGBjYg3rqXa+ECe2hJB40ui1
	oz0vsfuOZb55eIBEZeYwXPNmxbruGwAo=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 12BC2334063; 
	Tue, 29 Nov 2011 12:22:21 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4ee6d40edc2cc6592450c0b9ef47ecd34f822e11
Message-Id: <4ee6d40edc2cc6592450.1322598106@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:46 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 9 of 9] x86/mm: Allow pages typed as log dirty
 to also be shared
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_sharing.c |  3 +++
 xen/include/asm-x86/p2m.h     |  3 ++-
 2 files changed, 5 insertions(+), 1 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3489152b3a56 -r 4ee6d40edc2c xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -697,6 +697,9 @@ private_page_found:
     /* Update m2p entry */
     set_gpfn_from_mfn(mfn_x(page_to_mfn(page)), gfn);
 
+    /* Now that the gfn<->mfn map is properly established,
+     * marking dirty is feasible */
+    paging_mark_dirty(d, mfn_x(page_to_mfn(page)));
     put_gfn(d, gfn);
     shr_unlock();
     return 0;
diff -r 3489152b3a56 -r 4ee6d40edc2c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -163,7 +163,8 @@ typedef enum {
 /* Shared types */
 /* XXX: Sharable types could include p2m_ram_ro too, but we would need to
  * reinit the type correctly after fault */
-#define P2M_SHARABLE_TYPES (p2m_to_mask(p2m_ram_rw))
+#define P2M_SHARABLE_TYPES (p2m_to_mask(p2m_ram_rw) \
+                            | p2m_to_mask(p2m_ram_logdirty) )
 #define P2M_SHARED_TYPES   (p2m_to_mask(p2m_ram_shared))
 
 /* Broken type: the frame backing this pfn has failed in hardware

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCd-0004f1-1c; Tue, 29 Nov 2011 20:22:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCa-0004eQ-Qp
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322598109!50479209!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU0MDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14921 invoked from network); 29 Nov 2011 20:21:49 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.119) by server-4.tower-27.messagelabs.com with SMTP;
	29 Nov 2011 20:21:49 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 98E77334064;
	Tue, 29 Nov 2011 12:22:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=i3gUgatCMbnDDGl2kpidIl7rO92EHEGKk/adzg29QHQz
	Zk6IzcE2ZP5L7U4iP3N+ZQEnJG/FXiIlafBgUo+eYsAPCHEcyo0M+w3OIKW0xukZ
	/LFowmYc0b3Lp7q1Qa5WUN8hRfrh+y3Xj6e0M7l5bFdyVvtb6qlr4SRQNmDp4aw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Ecl32k1flUVCqJZx1A1iYbG7MG8=; b=ToHqvbqN5eG
	NIy8iQNnVBCOCtk6VvmnKR5sGahgga2bW8Xd6HYPQkBPB3vQ4t8JwmPzoEhg0cG/
	DcbC7iaSWQGiS5eu3qB99rfSOR8zazc3BujxJ7Vvd4zkMdUJE9pmEVfmYC3sTXgG
	Z3jSL3dblV/cnBu4rkzwhDRWr09MtJ8c=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 0417D334063; 
	Tue, 29 Nov 2011 12:22:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6626add0fef6a258388aade38e2076657cfc833b
Message-Id: <6626add0fef6a258388a.1322598103@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:43 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 9] x86/mm: Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/domctl.c       |   30 +++++++++
 xen/arch/x86/mm/p2m-ept.c   |    1 +
 xen/arch/x86/mm/p2m-pod.c   |    5 -
 xen/arch/x86/mm/p2m-pt.c    |  137 +++++++------------------------------------
 xen/arch/x86/mm/p2m.c       |  124 ++++++++++++++++++++++++++++++++++++---
 xen/include/asm-x86/p2m.h   |   11 ++-
 xen/include/public/domctl.h |   12 +++
 7 files changed, 186 insertions(+), 134 deletions(-)


The p2m audit code doesn't even compile, let alone work. It also
partially supports ept. Make it:

- compile
- lay groundwork for eventual ept support
- move out of the way of all calls and turn it into a domctl. It's
  obviously not being used by anybody presently.
- enable it via said domctl

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b2097819f2d9 -r 6626add0fef6 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1449,6 +1449,36 @@ long arch_do_domctl(
     break;
 #endif /* __x86_64__ */
 
+    case XEN_DOMCTL_audit_p2m:
+    {
+        struct domain *d;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(domctl->domain);
+        if ( d != NULL )
+        {
+            ret = -EPERM;
+            if ( (domctl->domain != DOMID_SELF) &&
+                 (d != current->domain) &&
+                 (IS_PRIV_FOR(current->domain, d)) )
+            {
+#if P2M_AUDIT
+                audit_p2m(d,
+                          &domctl->u.audit_p2m.orphans_debug,
+                          &domctl->u.audit_p2m.orphans_invalid,
+                          &domctl->u.audit_p2m.m2p_bad,
+                          &domctl->u.audit_p2m.p2m_bad);
+                ret = (copy_to_guest(u_domctl, domctl, 1)) ?
+                        -EFAULT : 0;
+#else
+                ret = -ENOSYS;
+#endif /* P2M_AUDIT */
+            }
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     case XEN_DOMCTL_set_access_required:
     {
         struct domain *d;
diff -r b2097819f2d9 -r 6626add0fef6 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -817,6 +817,7 @@ void ept_p2m_init(struct p2m_domain *p2m
     p2m->set_entry = ept_set_entry;
     p2m->get_entry = ept_get_entry;
     p2m->change_entry_type_global = ept_change_entry_type_global;
+    p2m->audit_p2m = NULL;
 }
 
 static void ept_dump_p2m_table(unsigned char key)
diff -r b2097819f2d9 -r 6626add0fef6 xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -522,7 +522,6 @@ p2m_pod_decrease_reservation(struct doma
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
 
     if ( unlikely(d->is_dying) )
         goto out_unlock;
@@ -616,7 +615,6 @@ out_entry_check:
     }
 
 out_unlock:
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
 out:
@@ -986,7 +984,6 @@ p2m_pod_demand_populate(struct p2m_domai
          */
         set_p2m_entry(p2m, gfn_aligned, _mfn(0), PAGE_ORDER_2M,
                       p2m_populate_on_demand, p2m->default_access);
-        audit_p2m(p2m, 1);
         return 0;
     }
 
@@ -1108,7 +1105,6 @@ guest_physmap_mark_populate_on_demand(st
         return rc;
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
 
     P2M_DEBUG("mark pod gfn=%#lx\n", gfn);
 
@@ -1142,7 +1138,6 @@ guest_physmap_mark_populate_on_demand(st
         BUG_ON(p2m->pod.entry_count < 0);
     }
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
 out:
diff -r b2097819f2d9 -r 6626add0fef6 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -483,7 +483,6 @@ static int p2m_pod_check_and_populate(st
     /* This is called from the p2m lookups, which can happen with or 
      * without the lock hed. */
     p2m_lock_recursive(p2m);
-    audit_p2m(p2m, 1);
 
     /* Check to make sure this is still PoD */
     if ( p2m_flags_to_type(l1e_get_flags(*p2m_entry)) != p2m_populate_on_demand )
@@ -494,7 +493,6 @@ static int p2m_pod_check_and_populate(st
 
     r = p2m_pod_demand_populate(p2m, gfn, order, q);
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
     return r;
@@ -975,118 +973,23 @@ static void p2m_change_type_global(struc
 
 }
 
-/* Set up the p2m function pointers for pagetable format */
-void p2m_pt_init(struct p2m_domain *p2m)
+#if P2M_AUDIT
+long p2m_pt_audit_p2m(struct p2m_domain *p2m)
 {
-    p2m->set_entry = p2m_set_entry;
-    p2m->get_entry = p2m_gfn_to_mfn;
-    p2m->change_entry_type_global = p2m_change_type_global;
-    p2m->write_p2m_entry = paging_write_p2m_entry;
-}
-
-
-#if P2M_AUDIT
-/* strict_m2p == 0 allows m2p mappings that don'#t match the p2m. 
- * It's intended for add_to_physmap, when the domain has just been allocated 
- * new mfns that might have stale m2p entries from previous owners */
-void audit_p2m(struct p2m_domain *p2m, int strict_m2p)
-{
-    struct page_info *page;
-    struct domain *od;
-    unsigned long mfn, gfn, m2pfn, lp2mfn = 0;
     int entry_count = 0;
-    mfn_t p2mfn;
-    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    unsigned long pmbad = 0;
+    unsigned long mfn, gfn, m2pfn;
     int test_linear;
-    p2m_type_t type;
     struct domain *d = p2m->domain;
 
-    if ( !paging_mode_translate(d) )
-        return;
-
-    //P2M_PRINTK("p2m audit starts\n");
+    ASSERT(p2m_locked_by_me(p2m));
 
     test_linear = ( (d == current->domain)
                     && !pagetable_is_null(current->arch.monitor_table) );
     if ( test_linear )
         flush_tlb_local();
 
-    spin_lock(&d->page_alloc_lock);
-
-    /* Audit part one: walk the domain's page allocation list, checking
-     * the m2p entries. */
-    page_list_for_each ( page, &d->page_list )
-    {
-        mfn = mfn_x(page_to_mfn(page));
-
-        // P2M_PRINTK("auditing guest page, mfn=%#lx\n", mfn);
-
-        od = page_get_owner(page);
-
-        if ( od != d )
-        {
-            P2M_PRINTK("wrong owner %#lx -> %p(%u) != %p(%u)\n",
-                       mfn, od, (od?od->domain_id:-1), d, d->domain_id);
-            continue;
-        }
-
-        gfn = get_gpfn_from_mfn(mfn);
-        if ( gfn == INVALID_M2P_ENTRY )
-        {
-            orphans_i++;
-            //P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
-            //               mfn);
-            continue;
-        }
-
-        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
-        {
-            orphans_d++;
-            //P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
-            //               mfn);
-            continue;
-        }
-
-        if ( gfn == SHARED_M2P_ENTRY )
-        {
-            P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
-                    mfn);
-            continue;
-        }
-
-        p2mfn = gfn_to_mfn_type_p2m(p2m, gfn, &type, p2m_query);
-        if ( strict_m2p && mfn_x(p2mfn) != mfn )
-        {
-            mpbad++;
-            P2M_PRINTK("map mismatch mfn %#lx -> gfn %#lx -> mfn %#lx"
-                       " (-> gfn %#lx)\n",
-                       mfn, gfn, mfn_x(p2mfn),
-                       (mfn_valid(p2mfn)
-                        ? get_gpfn_from_mfn(mfn_x(p2mfn))
-                        : -1u));
-            /* This m2p entry is stale: the domain has another frame in
-             * this physical slot.  No great disaster, but for neatness,
-             * blow away the m2p entry. */
-            set_gpfn_from_mfn(mfn, INVALID_M2P_ENTRY);
-        }
-
-        if ( test_linear && (gfn <= p2m->max_mapped_pfn) )
-        {
-            lp2mfn = mfn_x(gfn_to_mfn_type_p2m(p2m, gfn, &type, p2m_query));
-            if ( lp2mfn != mfn_x(p2mfn) )
-            {
-                P2M_PRINTK("linear mismatch gfn %#lx -> mfn %#lx "
-                           "(!= mfn %#lx)\n", gfn, lp2mfn, mfn_x(p2mfn));
-            }
-        }
-
-        // P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx, lp2mfn=%#lx\n",
-        //                mfn, gfn, mfn_x(p2mfn), lp2mfn);
-    }
-
-    spin_unlock(&d->page_alloc_lock);
-
-    /* Audit part two: walk the domain's p2m table, checking the entries. */
+    /* Audit part one: walk the domain's p2m table, checking the entries. */
     if ( pagetable_get_pfn(p2m_get_pagetable(p2m)) != 0 )
     {
         l2_pgentry_t *l2e;
@@ -1239,17 +1142,23 @@ void audit_p2m(struct p2m_domain *p2m, i
                entry_count);
         BUG();
     }
-        
-    //P2M_PRINTK("p2m audit complete\n");
-    //if ( orphans_i | orphans_d | mpbad | pmbad )
-    //    P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
-    //                   orphans_i + orphans_d, orphans_i, orphans_d);
-    if ( mpbad | pmbad )
-    {
-        P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
-                   pmbad, mpbad);
-        WARN();
-    }
+
+    return pmbad;
 }
 #endif /* P2M_AUDIT */
 
+/* Set up the p2m function pointers for pagetable format */
+void p2m_pt_init(struct p2m_domain *p2m)
+{
+    p2m->set_entry = p2m_set_entry;
+    p2m->get_entry = p2m_gfn_to_mfn;
+    p2m->change_entry_type_global = p2m_change_type_global;
+    p2m->write_p2m_entry = paging_write_p2m_entry;
+#if P2M_AUDIT
+    p2m->audit_p2m = p2m_pt_audit_p2m;
+#else
+    p2m->audit_p2m = NULL;
+#endif
+}
+
+
diff -r b2097819f2d9 -r 6626add0fef6 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -439,9 +439,7 @@ guest_physmap_remove_page(struct domain 
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
     p2m_remove_page(p2m, gfn, mfn, page_order);
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 }
 
@@ -482,7 +480,6 @@ guest_physmap_add_entry(struct domain *d
         return rc;
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 0);
 
     P2M_DEBUG("adding gfn=%#lx mfn=%#lx\n", gfn, mfn);
 
@@ -566,7 +563,6 @@ guest_physmap_add_entry(struct domain *d
         }
     }
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
     return rc;
@@ -656,7 +652,6 @@ set_mmio_p2m_entry(struct domain *d, uns
 
     P2M_DEBUG("set mmio %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_mmio_direct, p2m->default_access);
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
@@ -688,7 +683,6 @@ clear_mmio_p2m_entry(struct domain *d, u
         goto out;
     }
     rc = set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_invalid, p2m->default_access);
-    audit_p2m(p2m, 1);
 
 out:
     p2m_unlock(p2m);
@@ -785,7 +779,6 @@ int p2m_mem_paging_nominate(struct domai
 
     /* Fix p2m entry */
     set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_out, a);
-    audit_p2m(p2m, 1);
     ret = 0;
 
  out:
@@ -852,7 +845,6 @@ int p2m_mem_paging_evict(struct domain *
 
     /* Remove mapping from p2m table */
     set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_ram_paged, a);
-    audit_p2m(p2m, 1);
 
     /* Clear content before returning the page to Xen */
     scrub_one_page(page);
@@ -946,7 +938,6 @@ void p2m_mem_paging_populate(struct doma
             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
 
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
-        audit_p2m(p2m, 1);
     }
     p2m_unlock(p2m);
 
@@ -1014,7 +1005,6 @@ int p2m_mem_paging_prep(struct domain *d
 
     /* Fix p2m mapping */
     set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
-    audit_p2m(p2m, 1);
 
     atomic_dec(&d->paged_pages);
 
@@ -1065,7 +1055,6 @@ void p2m_mem_paging_resume(struct domain
                             paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, 
                             a);
             set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
-            audit_p2m(p2m, 1);
         }
         p2m_unlock(p2m);
     }
@@ -1427,6 +1416,119 @@ unsigned long paging_gva_to_gfn(struct v
     return hostmode->gva_to_gfn(v, hostp2m, va, pfec);
 }
 
+/*** Audit ***/
+
+#if P2M_AUDIT
+void audit_p2m(struct domain *d,
+                uint64_t *orphans_debug,
+                uint64_t *orphans_invalid,
+                uint64_t *m2p_bad,
+                uint64_t *p2m_bad)
+{
+    struct page_info *page;
+    struct domain *od;
+    unsigned long mfn, gfn;
+    mfn_t p2mfn;
+    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    p2m_access_t p2ma;
+    p2m_type_t type;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    if ( !paging_mode_translate(d) )
+        goto out_p2m_audit;
+
+    P2M_PRINTK("p2m audit starts\n");
+
+    p2m_lock(p2m);
+
+    if (p2m->audit_p2m)
+        pmbad = p2m->audit_p2m(p2m);
+
+    /* Audit part two: walk the domain's page allocation list, checking
+     * the m2p entries. */
+    spin_lock(&d->page_alloc_lock);
+    page_list_for_each ( page, &d->page_list )
+    {
+        mfn = mfn_x(page_to_mfn(page));
+
+        P2M_PRINTK("auditing guest page, mfn=%#lx\n", mfn);
+
+        od = page_get_owner(page);
+
+        if ( od != d )
+        {
+            P2M_PRINTK("wrong owner %#lx -> %p(%u) != %p(%u)\n",
+                       mfn, od, (od?od->domain_id:-1), d, d->domain_id);
+            continue;
+        }
+
+        gfn = get_gpfn_from_mfn(mfn);
+        if ( gfn == INVALID_M2P_ENTRY )
+        {
+            orphans_i++;
+            P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
+                           mfn);
+            continue;
+        }
+
+        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
+        {
+            orphans_d++;
+            P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
+                           mfn);
+            continue;
+        }
+
+        if ( gfn == SHARED_M2P_ENTRY )
+        {
+            P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
+                    mfn);
+            continue;
+        }
+
+        p2mfn = get_gfn_type_access(p2m, gfn, &type, &p2ma, p2m_query, NULL);
+        if ( mfn_x(p2mfn) != mfn )
+        {
+            mpbad++;
+            P2M_PRINTK("map mismatch mfn %#lx -> gfn %#lx -> mfn %#lx"
+                       " (-> gfn %#lx)\n",
+                       mfn, gfn, mfn_x(p2mfn),
+                       (mfn_valid(p2mfn)
+                        ? get_gpfn_from_mfn(mfn_x(p2mfn))
+                        : -1u));
+            /* This m2p entry is stale: the domain has another frame in
+             * this physical slot.  No great disaster, but for neatness,
+             * blow away the m2p entry. */
+            set_gpfn_from_mfn(mfn, INVALID_M2P_ENTRY);
+        }
+        __put_gfn(p2m, gfn);
+
+        P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx, lp2mfn=%#lx\n",
+                       mfn, gfn, mfn_x(p2mfn), lp2mfn);
+    }
+    spin_unlock(&d->page_alloc_lock);
+
+    p2m_unlock(p2m);
+ 
+    P2M_PRINTK("p2m audit complete\n");
+    if ( orphans_i | orphans_d | mpbad | pmbad )
+        P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
+                       orphans_i + orphans_d, orphans_i, orphans_d);
+    if ( mpbad | pmbad )
+    {
+        P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
+                   pmbad, mpbad);
+        WARN();
+    }
+
+out_p2m_audit:
+    *orphans_debug      = (uint64_t) orphans_d;
+    *orphans_invalid    = (uint64_t) orphans_i;
+    *m2p_bad            = (uint64_t) mpbad;
+    *p2m_bad            = (uint64_t) pmbad;
+}
+#endif /* P2M_AUDIT */
+
 /*
  * Local variables:
  * mode: C
diff -r b2097819f2d9 -r 6626add0fef6 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -245,6 +245,7 @@ struct p2m_domain {
                                           unsigned long gfn, l1_pgentry_t *p,
                                           mfn_t table_mfn, l1_pgentry_t new,
                                           unsigned int level);
+    long               (*audit_p2m)(struct p2m_domain *p2m);
 
     /* Default P2M access type for each page in the the domain: new pages,
      * swapped in pages, cleared pages, and pages that are ambiquously
@@ -559,13 +560,15 @@ int set_p2m_entry(struct p2m_domain *p2m
 extern void p2m_pt_init(struct p2m_domain *p2m);
 
 /* Debugging and auditing of the P2M code? */
-#define P2M_AUDIT     0
+#define P2M_AUDIT     1
 #define P2M_DEBUGGING 0
 
 #if P2M_AUDIT
-extern void audit_p2m(struct p2m_domain *p2m, int strict_m2p);
-#else
-# define audit_p2m(_p2m, _m2p) do { (void)(_p2m),(_m2p); } while (0)
+extern void audit_p2m(struct domain *d,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,
+                        uint64_t *p2m_bad);
 #endif /* P2M_AUDIT */
 
 /* Printouts */
diff -r b2097819f2d9 -r 6626add0fef6 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -800,6 +800,16 @@ struct xen_domctl_mem_sharing_op {
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_sharing_op_t);
 
+struct xen_domctl_audit_p2m {
+    /* OUT error counts */
+    uint64_t orphans_debug;
+    uint64_t orphans_invalid;
+    uint64_t m2p_bad;
+    uint64_t p2m_bad;
+};
+typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -898,6 +908,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_setvcpuextstate               62
 #define XEN_DOMCTL_getvcpuextstate               63
 #define XEN_DOMCTL_set_access_required           64
+#define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -951,6 +962,7 @@ struct xen_domctl {
         struct xen_domctl_vcpuextstate      vcpuextstate;
 #endif
         struct xen_domctl_set_access_required access_required;
+        struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCh-0004gU-Fa; Tue, 29 Nov 2011 20:22:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCg-0004ef-0a
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322598134!5460606!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDY3MQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8558 invoked from network); 29 Nov 2011 20:22:17 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 20:22:17 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id D24C433406C;
	Tue, 29 Nov 2011 12:22:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=OEfdTnPH2OKmkXTdZJiIwLipbPfTdINsBTuRow8iHRoS
	iAbzOVnsKA2qA4fSSuL2TvvDOSoEhp8KyVYmthH9zOrVSNCKaR2PfUhEyUFGDsb8
	1F/1D1DS2M536dk0hB5vNSCaJJVQC8ZxkG0Qw5ofOOjZYlVnLwOBJBBkpOYGvqc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=qhJh9arwJCUALTTB9SlK9QoR/GE=; b=Gtb7kndfPgq
	Nr/stWdUOpgFX8SVxza/zv8+1keaBBz0l5GUf2C11aKOip0AfXOlvHzowkfxukhI
	Kxf0rBiF2BGbC6zj8hOlqeQDtuifj77fpyeo6DDHiQE2kSljdUaHyRz9gbDo4OFJ
	i+1oQAq4BwRFGdRo9Sby6NCWt3FtS+4w=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 7ADA3334063; 
	Tue, 29 Nov 2011 12:22:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bea03a7fe212955e951c76f1c37f30ca63dd9e85
Message-Id: <bea03a7fe212955e951c.1322598100@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:40 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 9] x86/mm: Don't lose track of the log
	dirty bitmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/paging.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hap_log_dirty_init unconditionally sets the top of the log dirty
bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
then leaked, and the host crashes on an ASSERT when the domain is
cleaned up. Fixing it here.

Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1b241f984167 -r bea03a7fe212 xen/arch/x86/mm/paging.c
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -595,7 +595,6 @@ void paging_log_dirty_init(struct domain
     d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
     d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
     d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
-    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
 }
 
 /* This function fress log dirty bitmap resources. */
@@ -617,6 +616,7 @@ int paging_domain_init(struct domain *d,
 
     mm_lock_init(&d->arch.paging.lock);
 
+    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
     /* The order of the *_init calls below is important, as the later
      * ones may rewrite some common fields.  Shadow pagetables are the
      * default... */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCh-0004gU-Fa; Tue, 29 Nov 2011 20:22:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCg-0004ef-0a
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322598134!5460606!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDY3MQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8558 invoked from network); 29 Nov 2011 20:22:17 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 20:22:17 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id D24C433406C;
	Tue, 29 Nov 2011 12:22:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=OEfdTnPH2OKmkXTdZJiIwLipbPfTdINsBTuRow8iHRoS
	iAbzOVnsKA2qA4fSSuL2TvvDOSoEhp8KyVYmthH9zOrVSNCKaR2PfUhEyUFGDsb8
	1F/1D1DS2M536dk0hB5vNSCaJJVQC8ZxkG0Qw5ofOOjZYlVnLwOBJBBkpOYGvqc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=qhJh9arwJCUALTTB9SlK9QoR/GE=; b=Gtb7kndfPgq
	Nr/stWdUOpgFX8SVxza/zv8+1keaBBz0l5GUf2C11aKOip0AfXOlvHzowkfxukhI
	Kxf0rBiF2BGbC6zj8hOlqeQDtuifj77fpyeo6DDHiQE2kSljdUaHyRz9gbDo4OFJ
	i+1oQAq4BwRFGdRo9Sby6NCWt3FtS+4w=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 7ADA3334063; 
	Tue, 29 Nov 2011 12:22:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bea03a7fe212955e951c76f1c37f30ca63dd9e85
Message-Id: <bea03a7fe212955e951c.1322598100@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:40 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 9] x86/mm: Don't lose track of the log
	dirty bitmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/paging.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hap_log_dirty_init unconditionally sets the top of the log dirty
bitmap to INVALID_MFN. If there had been a bitmap allocated, it is
then leaked, and the host crashes on an ASSERT when the domain is
cleaned up. Fixing it here.

Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1b241f984167 -r bea03a7fe212 xen/arch/x86/mm/paging.c
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -595,7 +595,6 @@ void paging_log_dirty_init(struct domain
     d->arch.paging.log_dirty.enable_log_dirty = enable_log_dirty;
     d->arch.paging.log_dirty.disable_log_dirty = disable_log_dirty;
     d->arch.paging.log_dirty.clean_dirty_bitmap = clean_dirty_bitmap;
-    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
 }
 
 /* This function fress log dirty bitmap resources. */
@@ -617,6 +616,7 @@ int paging_domain_init(struct domain *d,
 
     mm_lock_init(&d->arch.paging.lock);
 
+    d->arch.paging.log_dirty.top = _mfn(INVALID_MFN);
     /* The order of the *_init calls below is important, as the later
      * ones may rewrite some common fields.  Shadow pagetables are the
      * default... */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCd-0004f1-1c; Tue, 29 Nov 2011 20:22:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCa-0004eQ-Qp
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322598109!50479209!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU0MDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14921 invoked from network); 29 Nov 2011 20:21:49 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.119) by server-4.tower-27.messagelabs.com with SMTP;
	29 Nov 2011 20:21:49 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 98E77334064;
	Tue, 29 Nov 2011 12:22:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=i3gUgatCMbnDDGl2kpidIl7rO92EHEGKk/adzg29QHQz
	Zk6IzcE2ZP5L7U4iP3N+ZQEnJG/FXiIlafBgUo+eYsAPCHEcyo0M+w3OIKW0xukZ
	/LFowmYc0b3Lp7q1Qa5WUN8hRfrh+y3Xj6e0M7l5bFdyVvtb6qlr4SRQNmDp4aw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=Ecl32k1flUVCqJZx1A1iYbG7MG8=; b=ToHqvbqN5eG
	NIy8iQNnVBCOCtk6VvmnKR5sGahgga2bW8Xd6HYPQkBPB3vQ4t8JwmPzoEhg0cG/
	DcbC7iaSWQGiS5eu3qB99rfSOR8zazc3BujxJ7Vvd4zkMdUJE9pmEVfmYC3sTXgG
	Z3jSL3dblV/cnBu4rkzwhDRWr09MtJ8c=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 0417D334063; 
	Tue, 29 Nov 2011 12:22:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6626add0fef6a258388aade38e2076657cfc833b
Message-Id: <6626add0fef6a258388a.1322598103@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:43 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 9] x86/mm: Rework stale p2m auditing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/domctl.c       |   30 +++++++++
 xen/arch/x86/mm/p2m-ept.c   |    1 +
 xen/arch/x86/mm/p2m-pod.c   |    5 -
 xen/arch/x86/mm/p2m-pt.c    |  137 +++++++------------------------------------
 xen/arch/x86/mm/p2m.c       |  124 ++++++++++++++++++++++++++++++++++++---
 xen/include/asm-x86/p2m.h   |   11 ++-
 xen/include/public/domctl.h |   12 +++
 7 files changed, 186 insertions(+), 134 deletions(-)


The p2m audit code doesn't even compile, let alone work. It also
partially supports ept. Make it:

- compile
- lay groundwork for eventual ept support
- move out of the way of all calls and turn it into a domctl. It's
  obviously not being used by anybody presently.
- enable it via said domctl

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b2097819f2d9 -r 6626add0fef6 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1449,6 +1449,36 @@ long arch_do_domctl(
     break;
 #endif /* __x86_64__ */
 
+    case XEN_DOMCTL_audit_p2m:
+    {
+        struct domain *d;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(domctl->domain);
+        if ( d != NULL )
+        {
+            ret = -EPERM;
+            if ( (domctl->domain != DOMID_SELF) &&
+                 (d != current->domain) &&
+                 (IS_PRIV_FOR(current->domain, d)) )
+            {
+#if P2M_AUDIT
+                audit_p2m(d,
+                          &domctl->u.audit_p2m.orphans_debug,
+                          &domctl->u.audit_p2m.orphans_invalid,
+                          &domctl->u.audit_p2m.m2p_bad,
+                          &domctl->u.audit_p2m.p2m_bad);
+                ret = (copy_to_guest(u_domctl, domctl, 1)) ?
+                        -EFAULT : 0;
+#else
+                ret = -ENOSYS;
+#endif /* P2M_AUDIT */
+            }
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     case XEN_DOMCTL_set_access_required:
     {
         struct domain *d;
diff -r b2097819f2d9 -r 6626add0fef6 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -817,6 +817,7 @@ void ept_p2m_init(struct p2m_domain *p2m
     p2m->set_entry = ept_set_entry;
     p2m->get_entry = ept_get_entry;
     p2m->change_entry_type_global = ept_change_entry_type_global;
+    p2m->audit_p2m = NULL;
 }
 
 static void ept_dump_p2m_table(unsigned char key)
diff -r b2097819f2d9 -r 6626add0fef6 xen/arch/x86/mm/p2m-pod.c
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -522,7 +522,6 @@ p2m_pod_decrease_reservation(struct doma
     steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
 
     if ( unlikely(d->is_dying) )
         goto out_unlock;
@@ -616,7 +615,6 @@ out_entry_check:
     }
 
 out_unlock:
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
 out:
@@ -986,7 +984,6 @@ p2m_pod_demand_populate(struct p2m_domai
          */
         set_p2m_entry(p2m, gfn_aligned, _mfn(0), PAGE_ORDER_2M,
                       p2m_populate_on_demand, p2m->default_access);
-        audit_p2m(p2m, 1);
         return 0;
     }
 
@@ -1108,7 +1105,6 @@ guest_physmap_mark_populate_on_demand(st
         return rc;
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
 
     P2M_DEBUG("mark pod gfn=%#lx\n", gfn);
 
@@ -1142,7 +1138,6 @@ guest_physmap_mark_populate_on_demand(st
         BUG_ON(p2m->pod.entry_count < 0);
     }
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
 out:
diff -r b2097819f2d9 -r 6626add0fef6 xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -483,7 +483,6 @@ static int p2m_pod_check_and_populate(st
     /* This is called from the p2m lookups, which can happen with or 
      * without the lock hed. */
     p2m_lock_recursive(p2m);
-    audit_p2m(p2m, 1);
 
     /* Check to make sure this is still PoD */
     if ( p2m_flags_to_type(l1e_get_flags(*p2m_entry)) != p2m_populate_on_demand )
@@ -494,7 +493,6 @@ static int p2m_pod_check_and_populate(st
 
     r = p2m_pod_demand_populate(p2m, gfn, order, q);
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
     return r;
@@ -975,118 +973,23 @@ static void p2m_change_type_global(struc
 
 }
 
-/* Set up the p2m function pointers for pagetable format */
-void p2m_pt_init(struct p2m_domain *p2m)
+#if P2M_AUDIT
+long p2m_pt_audit_p2m(struct p2m_domain *p2m)
 {
-    p2m->set_entry = p2m_set_entry;
-    p2m->get_entry = p2m_gfn_to_mfn;
-    p2m->change_entry_type_global = p2m_change_type_global;
-    p2m->write_p2m_entry = paging_write_p2m_entry;
-}
-
-
-#if P2M_AUDIT
-/* strict_m2p == 0 allows m2p mappings that don'#t match the p2m. 
- * It's intended for add_to_physmap, when the domain has just been allocated 
- * new mfns that might have stale m2p entries from previous owners */
-void audit_p2m(struct p2m_domain *p2m, int strict_m2p)
-{
-    struct page_info *page;
-    struct domain *od;
-    unsigned long mfn, gfn, m2pfn, lp2mfn = 0;
     int entry_count = 0;
-    mfn_t p2mfn;
-    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    unsigned long pmbad = 0;
+    unsigned long mfn, gfn, m2pfn;
     int test_linear;
-    p2m_type_t type;
     struct domain *d = p2m->domain;
 
-    if ( !paging_mode_translate(d) )
-        return;
-
-    //P2M_PRINTK("p2m audit starts\n");
+    ASSERT(p2m_locked_by_me(p2m));
 
     test_linear = ( (d == current->domain)
                     && !pagetable_is_null(current->arch.monitor_table) );
     if ( test_linear )
         flush_tlb_local();
 
-    spin_lock(&d->page_alloc_lock);
-
-    /* Audit part one: walk the domain's page allocation list, checking
-     * the m2p entries. */
-    page_list_for_each ( page, &d->page_list )
-    {
-        mfn = mfn_x(page_to_mfn(page));
-
-        // P2M_PRINTK("auditing guest page, mfn=%#lx\n", mfn);
-
-        od = page_get_owner(page);
-
-        if ( od != d )
-        {
-            P2M_PRINTK("wrong owner %#lx -> %p(%u) != %p(%u)\n",
-                       mfn, od, (od?od->domain_id:-1), d, d->domain_id);
-            continue;
-        }
-
-        gfn = get_gpfn_from_mfn(mfn);
-        if ( gfn == INVALID_M2P_ENTRY )
-        {
-            orphans_i++;
-            //P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
-            //               mfn);
-            continue;
-        }
-
-        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
-        {
-            orphans_d++;
-            //P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
-            //               mfn);
-            continue;
-        }
-
-        if ( gfn == SHARED_M2P_ENTRY )
-        {
-            P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
-                    mfn);
-            continue;
-        }
-
-        p2mfn = gfn_to_mfn_type_p2m(p2m, gfn, &type, p2m_query);
-        if ( strict_m2p && mfn_x(p2mfn) != mfn )
-        {
-            mpbad++;
-            P2M_PRINTK("map mismatch mfn %#lx -> gfn %#lx -> mfn %#lx"
-                       " (-> gfn %#lx)\n",
-                       mfn, gfn, mfn_x(p2mfn),
-                       (mfn_valid(p2mfn)
-                        ? get_gpfn_from_mfn(mfn_x(p2mfn))
-                        : -1u));
-            /* This m2p entry is stale: the domain has another frame in
-             * this physical slot.  No great disaster, but for neatness,
-             * blow away the m2p entry. */
-            set_gpfn_from_mfn(mfn, INVALID_M2P_ENTRY);
-        }
-
-        if ( test_linear && (gfn <= p2m->max_mapped_pfn) )
-        {
-            lp2mfn = mfn_x(gfn_to_mfn_type_p2m(p2m, gfn, &type, p2m_query));
-            if ( lp2mfn != mfn_x(p2mfn) )
-            {
-                P2M_PRINTK("linear mismatch gfn %#lx -> mfn %#lx "
-                           "(!= mfn %#lx)\n", gfn, lp2mfn, mfn_x(p2mfn));
-            }
-        }
-
-        // P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx, lp2mfn=%#lx\n",
-        //                mfn, gfn, mfn_x(p2mfn), lp2mfn);
-    }
-
-    spin_unlock(&d->page_alloc_lock);
-
-    /* Audit part two: walk the domain's p2m table, checking the entries. */
+    /* Audit part one: walk the domain's p2m table, checking the entries. */
     if ( pagetable_get_pfn(p2m_get_pagetable(p2m)) != 0 )
     {
         l2_pgentry_t *l2e;
@@ -1239,17 +1142,23 @@ void audit_p2m(struct p2m_domain *p2m, i
                entry_count);
         BUG();
     }
-        
-    //P2M_PRINTK("p2m audit complete\n");
-    //if ( orphans_i | orphans_d | mpbad | pmbad )
-    //    P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
-    //                   orphans_i + orphans_d, orphans_i, orphans_d);
-    if ( mpbad | pmbad )
-    {
-        P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
-                   pmbad, mpbad);
-        WARN();
-    }
+
+    return pmbad;
 }
 #endif /* P2M_AUDIT */
 
+/* Set up the p2m function pointers for pagetable format */
+void p2m_pt_init(struct p2m_domain *p2m)
+{
+    p2m->set_entry = p2m_set_entry;
+    p2m->get_entry = p2m_gfn_to_mfn;
+    p2m->change_entry_type_global = p2m_change_type_global;
+    p2m->write_p2m_entry = paging_write_p2m_entry;
+#if P2M_AUDIT
+    p2m->audit_p2m = p2m_pt_audit_p2m;
+#else
+    p2m->audit_p2m = NULL;
+#endif
+}
+
+
diff -r b2097819f2d9 -r 6626add0fef6 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -439,9 +439,7 @@ guest_physmap_remove_page(struct domain 
 {
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
     p2m_lock(p2m);
-    audit_p2m(p2m, 1);
     p2m_remove_page(p2m, gfn, mfn, page_order);
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 }
 
@@ -482,7 +480,6 @@ guest_physmap_add_entry(struct domain *d
         return rc;
 
     p2m_lock(p2m);
-    audit_p2m(p2m, 0);
 
     P2M_DEBUG("adding gfn=%#lx mfn=%#lx\n", gfn, mfn);
 
@@ -566,7 +563,6 @@ guest_physmap_add_entry(struct domain *d
         }
     }
 
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
 
     return rc;
@@ -656,7 +652,6 @@ set_mmio_p2m_entry(struct domain *d, uns
 
     P2M_DEBUG("set mmio %lx %lx\n", gfn, mfn_x(mfn));
     rc = set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_mmio_direct, p2m->default_access);
-    audit_p2m(p2m, 1);
     p2m_unlock(p2m);
     if ( 0 == rc )
         gdprintk(XENLOG_ERR,
@@ -688,7 +683,6 @@ clear_mmio_p2m_entry(struct domain *d, u
         goto out;
     }
     rc = set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_invalid, p2m->default_access);
-    audit_p2m(p2m, 1);
 
 out:
     p2m_unlock(p2m);
@@ -785,7 +779,6 @@ int p2m_mem_paging_nominate(struct domai
 
     /* Fix p2m entry */
     set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_out, a);
-    audit_p2m(p2m, 1);
     ret = 0;
 
  out:
@@ -852,7 +845,6 @@ int p2m_mem_paging_evict(struct domain *
 
     /* Remove mapping from p2m table */
     set_p2m_entry(p2m, gfn, _mfn(INVALID_MFN), PAGE_ORDER_4K, p2m_ram_paged, a);
-    audit_p2m(p2m, 1);
 
     /* Clear content before returning the page to Xen */
     scrub_one_page(page);
@@ -946,7 +938,6 @@ void p2m_mem_paging_populate(struct doma
             req.flags |= MEM_EVENT_FLAG_EVICT_FAIL;
 
         set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in_start, a);
-        audit_p2m(p2m, 1);
     }
     p2m_unlock(p2m);
 
@@ -1014,7 +1005,6 @@ int p2m_mem_paging_prep(struct domain *d
 
     /* Fix p2m mapping */
     set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
-    audit_p2m(p2m, 1);
 
     atomic_dec(&d->paged_pages);
 
@@ -1065,7 +1055,6 @@ void p2m_mem_paging_resume(struct domain
                             paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, 
                             a);
             set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
-            audit_p2m(p2m, 1);
         }
         p2m_unlock(p2m);
     }
@@ -1427,6 +1416,119 @@ unsigned long paging_gva_to_gfn(struct v
     return hostmode->gva_to_gfn(v, hostp2m, va, pfec);
 }
 
+/*** Audit ***/
+
+#if P2M_AUDIT
+void audit_p2m(struct domain *d,
+                uint64_t *orphans_debug,
+                uint64_t *orphans_invalid,
+                uint64_t *m2p_bad,
+                uint64_t *p2m_bad)
+{
+    struct page_info *page;
+    struct domain *od;
+    unsigned long mfn, gfn;
+    mfn_t p2mfn;
+    unsigned long orphans_d = 0, orphans_i = 0, mpbad = 0, pmbad = 0;
+    p2m_access_t p2ma;
+    p2m_type_t type;
+    struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+    if ( !paging_mode_translate(d) )
+        goto out_p2m_audit;
+
+    P2M_PRINTK("p2m audit starts\n");
+
+    p2m_lock(p2m);
+
+    if (p2m->audit_p2m)
+        pmbad = p2m->audit_p2m(p2m);
+
+    /* Audit part two: walk the domain's page allocation list, checking
+     * the m2p entries. */
+    spin_lock(&d->page_alloc_lock);
+    page_list_for_each ( page, &d->page_list )
+    {
+        mfn = mfn_x(page_to_mfn(page));
+
+        P2M_PRINTK("auditing guest page, mfn=%#lx\n", mfn);
+
+        od = page_get_owner(page);
+
+        if ( od != d )
+        {
+            P2M_PRINTK("wrong owner %#lx -> %p(%u) != %p(%u)\n",
+                       mfn, od, (od?od->domain_id:-1), d, d->domain_id);
+            continue;
+        }
+
+        gfn = get_gpfn_from_mfn(mfn);
+        if ( gfn == INVALID_M2P_ENTRY )
+        {
+            orphans_i++;
+            P2M_PRINTK("orphaned guest page: mfn=%#lx has invalid gfn\n",
+                           mfn);
+            continue;
+        }
+
+        if ( gfn == 0x55555555 || gfn == 0x5555555555555555 )
+        {
+            orphans_d++;
+            P2M_PRINTK("orphaned guest page: mfn=%#lx has debug gfn\n",
+                           mfn);
+            continue;
+        }
+
+        if ( gfn == SHARED_M2P_ENTRY )
+        {
+            P2M_PRINTK("shared mfn (%lx) on domain page list!\n",
+                    mfn);
+            continue;
+        }
+
+        p2mfn = get_gfn_type_access(p2m, gfn, &type, &p2ma, p2m_query, NULL);
+        if ( mfn_x(p2mfn) != mfn )
+        {
+            mpbad++;
+            P2M_PRINTK("map mismatch mfn %#lx -> gfn %#lx -> mfn %#lx"
+                       " (-> gfn %#lx)\n",
+                       mfn, gfn, mfn_x(p2mfn),
+                       (mfn_valid(p2mfn)
+                        ? get_gpfn_from_mfn(mfn_x(p2mfn))
+                        : -1u));
+            /* This m2p entry is stale: the domain has another frame in
+             * this physical slot.  No great disaster, but for neatness,
+             * blow away the m2p entry. */
+            set_gpfn_from_mfn(mfn, INVALID_M2P_ENTRY);
+        }
+        __put_gfn(p2m, gfn);
+
+        P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx, lp2mfn=%#lx\n",
+                       mfn, gfn, mfn_x(p2mfn), lp2mfn);
+    }
+    spin_unlock(&d->page_alloc_lock);
+
+    p2m_unlock(p2m);
+ 
+    P2M_PRINTK("p2m audit complete\n");
+    if ( orphans_i | orphans_d | mpbad | pmbad )
+        P2M_PRINTK("p2m audit found %lu orphans (%lu inval %lu debug)\n",
+                       orphans_i + orphans_d, orphans_i, orphans_d);
+    if ( mpbad | pmbad )
+    {
+        P2M_PRINTK("p2m audit found %lu odd p2m, %lu bad m2p entries\n",
+                   pmbad, mpbad);
+        WARN();
+    }
+
+out_p2m_audit:
+    *orphans_debug      = (uint64_t) orphans_d;
+    *orphans_invalid    = (uint64_t) orphans_i;
+    *m2p_bad            = (uint64_t) mpbad;
+    *p2m_bad            = (uint64_t) pmbad;
+}
+#endif /* P2M_AUDIT */
+
 /*
  * Local variables:
  * mode: C
diff -r b2097819f2d9 -r 6626add0fef6 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -245,6 +245,7 @@ struct p2m_domain {
                                           unsigned long gfn, l1_pgentry_t *p,
                                           mfn_t table_mfn, l1_pgentry_t new,
                                           unsigned int level);
+    long               (*audit_p2m)(struct p2m_domain *p2m);
 
     /* Default P2M access type for each page in the the domain: new pages,
      * swapped in pages, cleared pages, and pages that are ambiquously
@@ -559,13 +560,15 @@ int set_p2m_entry(struct p2m_domain *p2m
 extern void p2m_pt_init(struct p2m_domain *p2m);
 
 /* Debugging and auditing of the P2M code? */
-#define P2M_AUDIT     0
+#define P2M_AUDIT     1
 #define P2M_DEBUGGING 0
 
 #if P2M_AUDIT
-extern void audit_p2m(struct p2m_domain *p2m, int strict_m2p);
-#else
-# define audit_p2m(_p2m, _m2p) do { (void)(_p2m),(_m2p); } while (0)
+extern void audit_p2m(struct domain *d,
+                        uint64_t *orphans_debug,
+                        uint64_t *orphans_invalid,
+                        uint64_t *m2p_bad,
+                        uint64_t *p2m_bad);
 #endif /* P2M_AUDIT */
 
 /* Printouts */
diff -r b2097819f2d9 -r 6626add0fef6 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -800,6 +800,16 @@ struct xen_domctl_mem_sharing_op {
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_sharing_op_t);
 
+struct xen_domctl_audit_p2m {
+    /* OUT error counts */
+    uint64_t orphans_debug;
+    uint64_t orphans_invalid;
+    uint64_t m2p_bad;
+    uint64_t p2m_bad;
+};
+typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -898,6 +908,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_setvcpuextstate               62
 #define XEN_DOMCTL_getvcpuextstate               63
 #define XEN_DOMCTL_set_access_required           64
+#define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -951,6 +962,7 @@ struct xen_domctl {
         struct xen_domctl_vcpuextstate      vcpuextstate;
 #endif
         struct xen_domctl_set_access_required access_required;
+        struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCa-0004eK-03; Tue, 29 Nov 2011 20:22:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCY-0004du-Ii
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322598131!5193949!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTU5ODg=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32532 invoked from network); 29 Nov 2011 20:22:11 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.145) by server-2.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 20:22:11 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 4D5A133406C;
	Tue, 29 Nov 2011 12:22:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=FJ80wwWdGLqFjRuYrw+94YW83wD8A9SB/LPPcQy325S2
	hkJq5V+2xWAMmeP+IYq4hNk6OeKMRCOfV1vkqbdR7TZdcXFoUe9hrK62pnurjVTr
	oudgLfGc3DJMLzMG+B9sDbRePXXMhXGkK1pA4soVFGPN+y4+jqd/f5NkMEjuJZU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=S3+u3oXABh6+q2qXwu8DK3+mueY=; b=lhmA+1fex4I
	2o0P5lbl2FPtnIYWgg5EvRiyrqKfEOBfIRHInzsoRix9+GdronjQ6g6UMr7t98Ch
	Zp7hXOKFPzxCyFBWBkcQcMeZkL939VNpjurQDchDJnN3I71XprSwIHZYLzZcDFCH
	vbUMPUay7JVhJJ813kpPfbOmwjd7QFVA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 118D1334063; 
	Tue, 29 Nov 2011 12:22:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 47bfc8f8c0be233b7655de7d0b4b834f176e44e4
Message-Id: <47bfc8f8c0be233b7655.1322598098@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 9] Tools: When passing no bitmap for the
 shadow log dirty bitmap clean up, we should not get EFAULT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_domain.c |  2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)


This is due to a stale check for guest_handle_null in the hypervisor, which doesn't
necessarily work with the hypercall buffers.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 050e8684b6c8 -r 47bfc8f8c0be tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -430,6 +430,8 @@ int xc_shadow_control(xc_interface *xch,
     DECLARE_DOMCTL;
     DECLARE_HYPERCALL_BUFFER_ARGUMENT(dirty_bitmap);
 
+    memset(&domctl, 0, sizeof(domctl));
+
     domctl.cmd = XEN_DOMCTL_shadow_op;
     domctl.domain = (domid_t)domid;
     domctl.u.shadow_op.op     = sop;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCa-0004eK-03; Tue, 29 Nov 2011 20:22:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCY-0004du-Ii
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322598131!5193949!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTU5ODg=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32532 invoked from network); 29 Nov 2011 20:22:11 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.145) by server-2.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 20:22:11 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 4D5A133406C;
	Tue, 29 Nov 2011 12:22:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=FJ80wwWdGLqFjRuYrw+94YW83wD8A9SB/LPPcQy325S2
	hkJq5V+2xWAMmeP+IYq4hNk6OeKMRCOfV1vkqbdR7TZdcXFoUe9hrK62pnurjVTr
	oudgLfGc3DJMLzMG+B9sDbRePXXMhXGkK1pA4soVFGPN+y4+jqd/f5NkMEjuJZU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=S3+u3oXABh6+q2qXwu8DK3+mueY=; b=lhmA+1fex4I
	2o0P5lbl2FPtnIYWgg5EvRiyrqKfEOBfIRHInzsoRix9+GdronjQ6g6UMr7t98Ch
	Zp7hXOKFPzxCyFBWBkcQcMeZkL939VNpjurQDchDJnN3I71XprSwIHZYLzZcDFCH
	vbUMPUay7JVhJJ813kpPfbOmwjd7QFVA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 118D1334063; 
	Tue, 29 Nov 2011 12:22:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 47bfc8f8c0be233b7655de7d0b4b834f176e44e4
Message-Id: <47bfc8f8c0be233b7655.1322598098@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 9] Tools: When passing no bitmap for the
 shadow log dirty bitmap clean up, we should not get EFAULT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_domain.c |  2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)


This is due to a stale check for guest_handle_null in the hypervisor, which doesn't
necessarily work with the hypercall buffers.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 050e8684b6c8 -r 47bfc8f8c0be tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -430,6 +430,8 @@ int xc_shadow_control(xc_interface *xch,
     DECLARE_DOMCTL;
     DECLARE_HYPERCALL_BUFFER_ARGUMENT(dirty_bitmap);
 
+    memset(&domctl, 0, sizeof(domctl));
+
     domctl.cmd = XEN_DOMCTL_shadow_op;
     domctl.domain = (domid_t)domid;
     domctl.u.shadow_op.op     = sop;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCe-0004fQ-Fx; Tue, 29 Nov 2011 20:22:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCc-0004e3-KT
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:54 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322598136!560829!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2OTE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16095 invoked from network); 29 Nov 2011 20:22:16 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.177) by server-2.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 20:22:16 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 5E8C4334064;
	Tue, 29 Nov 2011 12:22:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=V01X59ltZeAcl5Ss9QrTPVNavlOsvrvEgWZSgFMB62LR
	pTF7NpYXEGBSjEff/CrXW9otAHvARrTJXTs3nCwiR3uKEiKtB3f70KsRS4MNCcs1
	LtLvG8mmZP9ZK9t4sOBFRczuD0C/oJhktVN+6DAR4XumO7L0zb+YnHwr0jnDh8I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=PdeIdS4nanyIMZl33WTiRQXBlUY=; b=X64ptlZLrpF
	0kGn0QH84yd0w10tOJP4vqkeo4crtgVcmuCerNX4d39CIXKnYUAS1t5kPOr3NHuw
	jTpoGiKjif2jDgEZNorcB+mijnPh0K4ytpfWSfzVysQ9sH12Je8qQfnNvzjo/MrI
	NHN+qV2rwwizVwT+8GOVWSj13TAp24Xg=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 0EAC8334063; 
	Tue, 29 Nov 2011 12:22:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 42e6ceb8138dd9f913f69a8494f7cb6b7ade6c9c
Message-Id: <42e6ceb8138dd9f913f6.1322598101@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:41 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 9] x86: Add conversion from a xen map to an
	mfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/asm-x86/page.h        |   1 +
 xen/include/asm-x86/x86_32/page.h |  11 +++++++++++
 xen/include/asm-x86/x86_64/page.h |   5 +++++
 3 files changed, 17 insertions(+), 0 deletions(-)


This conversion is a trivial invocation of virt_to_mfn in 64 bits.
In 32 bits it uses the linear_map.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/page.h
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -272,6 +272,7 @@ void copy_page_sse2(void *, const void *
 #define pfn_to_paddr(pfn)   __pfn_to_paddr(pfn)
 #define paddr_to_pfn(pa)    __paddr_to_pfn(pa)
 #define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
+#define xen_map_to_mfn(va)  __xen_map_to_mfn(va)
 
 #endif /* !defined(__ASSEMBLY__) */
 
diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/x86_32/page.h
--- a/xen/include/asm-x86/x86_32/page.h
+++ b/xen/include/asm-x86/x86_32/page.h
@@ -71,6 +71,17 @@ static inline void *__maddr_to_virt(unsi
     return (void *)(ma + DIRECTMAP_VIRT_START);
 }
 
+static inline unsigned long __xen_map_to_mfn(void *va)
+{
+    l1_pgentry_t *l1e;
+
+    ASSERT( (((unsigned long) va) >= MAPCACHE_VIRT_START) &&
+            (((unsigned long) va) <= MAPCACHE_VIRT_END) );
+    l1e = &__linear_l1_table[
+            l1_linear_offset((unsigned long) va)];
+    return l1e_get_pfn(*l1e);
+}
+
 /* read access (should only be used for debug printk's) */
 typedef u64 intpte_t;
 #define PRIpte "016llx"
diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/x86_64/page.h
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -104,6 +104,11 @@ static inline void *__maddr_to_virt(unsi
                      ((ma & ma_top_mask) >> pfn_pdx_hole_shift)));
 }
 
+static inline unsigned long __xen_map_to_mfn(void *va)
+{
+    return (__virt_to_maddr((unsigned long) va) >> PAGE_SHIFT);
+}
+
 /* read access (should only be used for debug printk's) */
 typedef u64 intpte_t;
 #define PRIpte "016lx"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCj-0004hK-Bx; Tue, 29 Nov 2011 20:23:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCi-0004f0-Ev
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:23:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322598142!3415749!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2OTE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16978 invoked from network); 29 Nov 2011 20:22:22 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.177) by server-15.tower-174.messagelabs.com with SMTP;
	29 Nov 2011 20:22:22 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id D1E51334064;
	Tue, 29 Nov 2011 12:22:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=udrmMVAkr89ohsrN5X2jxeLWykzh39zpPs/wwlAaOy51
	1I1Dz+z1vJ+nnIPczbcN293pt67V2I2MQWJvcYdOLWnJOGsjFjmlBPTl2BilT3Le
	odnvUk6+ukjj3kjf17zrEiViNLc+SjjFmB2oQ9cRxn+Y81F2OxjEh2BhkpzWzQQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=GpZC2SuxOZtdN8TGN2kDlFmLfJ0=; b=Yt1YqaYFiUT
	DpgjlmHCucfS4GqvfmclMERoj0zeg1+MKFSqfx3BQZmgqlDH6y6vJLY1e/xuldsl
	s8b0gCFgW2uA+jj1gEwwkg8LDnOth3w/rk6VtnsvveBejANZfBuHYReJg5RDRjkr
	t9wE6aIBStZBVS7Xa/qD4L9ejXuNpd8g=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 8D3C6334063; 
	Tue, 29 Nov 2011 12:22:20 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3489152b3a560be744ab3dbb46ae9fb75a8cde24
Message-Id: <3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:45 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 8 of 9] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


Check that the valid mfn is the one we are mapping, not the
mfn of the page table of the foreign domain.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 5286ed662c1e -r 3489152b3a56 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3572,7 +3572,8 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l1e_p2mt && !mfn_valid(mfn) )
+                    else if ( p2m_ram_paging_in_start == l1e_p2mt && 
+                                !mfn_valid(l1emfn) )
                     {
                         put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCe-0004fQ-Fx; Tue, 29 Nov 2011 20:22:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCc-0004e3-KT
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:54 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322598136!560829!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2OTE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16095 invoked from network); 29 Nov 2011 20:22:16 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.177) by server-2.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 20:22:16 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 5E8C4334064;
	Tue, 29 Nov 2011 12:22:15 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=V01X59ltZeAcl5Ss9QrTPVNavlOsvrvEgWZSgFMB62LR
	pTF7NpYXEGBSjEff/CrXW9otAHvARrTJXTs3nCwiR3uKEiKtB3f70KsRS4MNCcs1
	LtLvG8mmZP9ZK9t4sOBFRczuD0C/oJhktVN+6DAR4XumO7L0zb+YnHwr0jnDh8I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=PdeIdS4nanyIMZl33WTiRQXBlUY=; b=X64ptlZLrpF
	0kGn0QH84yd0w10tOJP4vqkeo4crtgVcmuCerNX4d39CIXKnYUAS1t5kPOr3NHuw
	jTpoGiKjif2jDgEZNorcB+mijnPh0K4ytpfWSfzVysQ9sH12Je8qQfnNvzjo/MrI
	NHN+qV2rwwizVwT+8GOVWSj13TAp24Xg=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 0EAC8334063; 
	Tue, 29 Nov 2011 12:22:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 42e6ceb8138dd9f913f69a8494f7cb6b7ade6c9c
Message-Id: <42e6ceb8138dd9f913f6.1322598101@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:41 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 9] x86: Add conversion from a xen map to an
	mfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/include/asm-x86/page.h        |   1 +
 xen/include/asm-x86/x86_32/page.h |  11 +++++++++++
 xen/include/asm-x86/x86_64/page.h |   5 +++++
 3 files changed, 17 insertions(+), 0 deletions(-)


This conversion is a trivial invocation of virt_to_mfn in 64 bits.
In 32 bits it uses the linear_map.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/page.h
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -272,6 +272,7 @@ void copy_page_sse2(void *, const void *
 #define pfn_to_paddr(pfn)   __pfn_to_paddr(pfn)
 #define paddr_to_pfn(pa)    __paddr_to_pfn(pa)
 #define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
+#define xen_map_to_mfn(va)  __xen_map_to_mfn(va)
 
 #endif /* !defined(__ASSEMBLY__) */
 
diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/x86_32/page.h
--- a/xen/include/asm-x86/x86_32/page.h
+++ b/xen/include/asm-x86/x86_32/page.h
@@ -71,6 +71,17 @@ static inline void *__maddr_to_virt(unsi
     return (void *)(ma + DIRECTMAP_VIRT_START);
 }
 
+static inline unsigned long __xen_map_to_mfn(void *va)
+{
+    l1_pgentry_t *l1e;
+
+    ASSERT( (((unsigned long) va) >= MAPCACHE_VIRT_START) &&
+            (((unsigned long) va) <= MAPCACHE_VIRT_END) );
+    l1e = &__linear_l1_table[
+            l1_linear_offset((unsigned long) va)];
+    return l1e_get_pfn(*l1e);
+}
+
 /* read access (should only be used for debug printk's) */
 typedef u64 intpte_t;
 #define PRIpte "016llx"
diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/x86_64/page.h
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -104,6 +104,11 @@ static inline void *__maddr_to_virt(unsi
                      ((ma & ma_top_mask) >> pfn_pdx_hole_shift)));
 }
 
+static inline unsigned long __xen_map_to_mfn(void *va)
+{
+    return (__virt_to_maddr((unsigned long) va) >> PAGE_SHIFT);
+}
+
 /* read access (should only be used for debug printk's) */
 typedef u64 intpte_t;
 #define PRIpte "016lx"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCa-0004ed-KL; Tue, 29 Nov 2011 20:22:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCZ-0004dv-Mr
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322598133!6293606!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU0MDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19629 invoked from network); 29 Nov 2011 20:22:13 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.119) by server-15.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 20:22:13 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 4CFC033406B;
	Tue, 29 Nov 2011 12:22:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=C+USuAHU3quVZ5vZRGhfJTWpueT9/H9ph/uBg0DKt/R1
	Zbd3jGjm+ypoVgSryCKiGKfW7Mpy1nRyGSGDGXlXfdx4cs5Mv5Xi2BE0ND0BOVh/
	zXJCKkKvrA4Ex1lpu+gfYwkQ2wDgAvIBmMLk/omhs9N1x17AE6vt3qcBNf/bwTY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7VmLwCWKpPAWx8K2/kPxMwWu5ho=; b=liD8COBKuf6
	PM0YK2FnZ44K6LWXOLAXcVl7OMnOx2Fjp7wn1fTXn/lzy18ob+GF2y1oeiBGRBp0
	mB0boLicv0MwatylYeTKt3YdvmCC//k79A9he2hv1pSZK9bkyN41696mvL3lLdHW
	75Ykjs6n2RJPWIyUfIW/k7Et0OKE1eIU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 7C6C0334063; 
	Tue, 29 Nov 2011 12:22:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1b241f9841675a8aaa557a5cd5f2ac572150682c
Message-Id: <1b241f9841675a8aaa55.1322598099@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 9] x86/mm: Don't trigger unnecessary shadow
 scans on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/shadow/common.c  |  6 ++----
 xen/arch/x86/mm/shadow/multi.c   |  2 +-
 xen/arch/x86/mm/shadow/private.h |  7 +++++++
 3 files changed, 10 insertions(+), 5 deletions(-)


When updating a p2m entry, the hypervisor scans all shadow pte's to find
mappings of that gfn and tear them down. This is avoided if the page count
reveals that there are no additional mappings. The current test ignores the
PGC_allocated flag and its effect on the page count.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 47bfc8f8c0be -r 1b241f984167 xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2464,7 +2464,6 @@ int sh_remove_write_access_from_sl1p(str
 int sh_remove_all_mappings(struct vcpu *v, mfn_t gmfn)
 {
     struct page_info *page = mfn_to_page(gmfn);
-    int expected_count;
 
     /* Dispatch table for getting per-type functions */
     static const hash_callback_t callbacks[SH_type_unused] = {
@@ -2501,7 +2500,7 @@ int sh_remove_all_mappings(struct vcpu *
         ;
 
     perfc_incr(shadow_mappings);
-    if ( (page->count_info & PGC_count_mask) == 0 )
+    if ( __check_page_no_refs(page) )
         return 0;
 
     /* Although this is an externally visible function, we do not know
@@ -2517,8 +2516,7 @@ int sh_remove_all_mappings(struct vcpu *
     hash_foreach(v, callback_mask, callbacks, gmfn);
 
     /* If that didn't catch the mapping, something is very wrong */
-    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
-    if ( (page->count_info & PGC_count_mask) != expected_count )
+    if ( !__check_page_no_refs(page) )
     {
         /* Don't complain if we're in HVM and there are some extra mappings: 
          * The qemu helper process has an untyped mapping of this dom's RAM 
diff -r 47bfc8f8c0be -r 1b241f984167 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4591,7 +4591,7 @@ int sh_rm_mappings_from_l1(struct vcpu *
         {
             (void) shadow_set_l1e(v, sl1e, shadow_l1e_empty(),
                                   p2m_invalid, sl1mfn);
-            if ( (mfn_to_page(target_mfn)->count_info & PGC_count_mask) == 0 )
+            if ( __check_page_no_refs(mfn_to_page(target_mfn)) )
                 /* This breaks us cleanly out of the FOREACH macro */
                 done = 1;
         }
diff -r 47bfc8f8c0be -r 1b241f984167 xen/arch/x86/mm/shadow/private.h
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -30,6 +30,7 @@
 #include <xen/domain_page.h>
 #include <asm/x86_emulate.h>
 #include <asm/hvm/support.h>
+#include <asm/atomic.h>
 
 #include "../mm-locks.h"
 
@@ -815,6 +816,12 @@ static inline unsigned long vtlb_lookup(
 }
 #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
 
+static inline int __check_page_no_refs(struct page_info *page)
+{
+    unsigned long __count = read_atomic(&page->count_info);
+    return ( (__count & PGC_count_mask) ==
+             ((__count & PGC_allocated) ? 1 : 0) ); 
+}
 
 #endif /* _XEN_SHADOW_PRIVATE_H */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCa-0004ed-KL; Tue, 29 Nov 2011 20:22:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCZ-0004dv-Mr
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:22:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322598133!6293606!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU0MDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19629 invoked from network); 29 Nov 2011 20:22:13 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.119) by server-15.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 20:22:13 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 4CFC033406B;
	Tue, 29 Nov 2011 12:22:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=C+USuAHU3quVZ5vZRGhfJTWpueT9/H9ph/uBg0DKt/R1
	Zbd3jGjm+ypoVgSryCKiGKfW7Mpy1nRyGSGDGXlXfdx4cs5Mv5Xi2BE0ND0BOVh/
	zXJCKkKvrA4Ex1lpu+gfYwkQ2wDgAvIBmMLk/omhs9N1x17AE6vt3qcBNf/bwTY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=7VmLwCWKpPAWx8K2/kPxMwWu5ho=; b=liD8COBKuf6
	PM0YK2FnZ44K6LWXOLAXcVl7OMnOx2Fjp7wn1fTXn/lzy18ob+GF2y1oeiBGRBp0
	mB0boLicv0MwatylYeTKt3YdvmCC//k79A9he2hv1pSZK9bkyN41696mvL3lLdHW
	75Ykjs6n2RJPWIyUfIW/k7Et0OKE1eIU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 7C6C0334063; 
	Tue, 29 Nov 2011 12:22:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1b241f9841675a8aaa557a5cd5f2ac572150682c
Message-Id: <1b241f9841675a8aaa55.1322598099@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 9] x86/mm: Don't trigger unnecessary shadow
 scans on p2m entry update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/shadow/common.c  |  6 ++----
 xen/arch/x86/mm/shadow/multi.c   |  2 +-
 xen/arch/x86/mm/shadow/private.h |  7 +++++++
 3 files changed, 10 insertions(+), 5 deletions(-)


When updating a p2m entry, the hypervisor scans all shadow pte's to find
mappings of that gfn and tear them down. This is avoided if the page count
reveals that there are no additional mappings. The current test ignores the
PGC_allocated flag and its effect on the page count.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 47bfc8f8c0be -r 1b241f984167 xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2464,7 +2464,6 @@ int sh_remove_write_access_from_sl1p(str
 int sh_remove_all_mappings(struct vcpu *v, mfn_t gmfn)
 {
     struct page_info *page = mfn_to_page(gmfn);
-    int expected_count;
 
     /* Dispatch table for getting per-type functions */
     static const hash_callback_t callbacks[SH_type_unused] = {
@@ -2501,7 +2500,7 @@ int sh_remove_all_mappings(struct vcpu *
         ;
 
     perfc_incr(shadow_mappings);
-    if ( (page->count_info & PGC_count_mask) == 0 )
+    if ( __check_page_no_refs(page) )
         return 0;
 
     /* Although this is an externally visible function, we do not know
@@ -2517,8 +2516,7 @@ int sh_remove_all_mappings(struct vcpu *
     hash_foreach(v, callback_mask, callbacks, gmfn);
 
     /* If that didn't catch the mapping, something is very wrong */
-    expected_count = (page->count_info & PGC_allocated) ? 1 : 0;
-    if ( (page->count_info & PGC_count_mask) != expected_count )
+    if ( !__check_page_no_refs(page) )
     {
         /* Don't complain if we're in HVM and there are some extra mappings: 
          * The qemu helper process has an untyped mapping of this dom's RAM 
diff -r 47bfc8f8c0be -r 1b241f984167 xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -4591,7 +4591,7 @@ int sh_rm_mappings_from_l1(struct vcpu *
         {
             (void) shadow_set_l1e(v, sl1e, shadow_l1e_empty(),
                                   p2m_invalid, sl1mfn);
-            if ( (mfn_to_page(target_mfn)->count_info & PGC_count_mask) == 0 )
+            if ( __check_page_no_refs(mfn_to_page(target_mfn)) )
                 /* This breaks us cleanly out of the FOREACH macro */
                 done = 1;
         }
diff -r 47bfc8f8c0be -r 1b241f984167 xen/arch/x86/mm/shadow/private.h
--- a/xen/arch/x86/mm/shadow/private.h
+++ b/xen/arch/x86/mm/shadow/private.h
@@ -30,6 +30,7 @@
 #include <xen/domain_page.h>
 #include <asm/x86_emulate.h>
 #include <asm/hvm/support.h>
+#include <asm/atomic.h>
 
 #include "../mm-locks.h"
 
@@ -815,6 +816,12 @@ static inline unsigned long vtlb_lookup(
 }
 #endif /* (SHADOW_OPTIMIZATIONS & SHOPT_VIRTUAL_TLB) */
 
+static inline int __check_page_no_refs(struct page_info *page)
+{
+    unsigned long __count = read_atomic(&page->count_info);
+    return ( (__count & PGC_count_mask) ==
+             ((__count & PGC_allocated) ? 1 : 0) ); 
+}
 
 #endif /* _XEN_SHADOW_PRIVATE_H */
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:23:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUCj-0004hK-Bx; Tue, 29 Nov 2011 20:23:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUCi-0004f0-Ev
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:23:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1322598142!3415749!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2OTE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16978 invoked from network); 29 Nov 2011 20:22:22 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.177) by server-15.tower-174.messagelabs.com with SMTP;
	29 Nov 2011 20:22:22 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id D1E51334064;
	Tue, 29 Nov 2011 12:22:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=udrmMVAkr89ohsrN5X2jxeLWykzh39zpPs/wwlAaOy51
	1I1Dz+z1vJ+nnIPczbcN293pt67V2I2MQWJvcYdOLWnJOGsjFjmlBPTl2BilT3Le
	odnvUk6+ukjj3kjf17zrEiViNLc+SjjFmB2oQ9cRxn+Y81F2OxjEh2BhkpzWzQQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=GpZC2SuxOZtdN8TGN2kDlFmLfJ0=; b=Yt1YqaYFiUT
	DpgjlmHCucfS4GqvfmclMERoj0zeg1+MKFSqfx3BQZmgqlDH6y6vJLY1e/xuldsl
	s8b0gCFgW2uA+jj1gEwwkg8LDnOth3w/rk6VtnsvveBejANZfBuHYReJg5RDRjkr
	t9wE6aIBStZBVS7Xa/qD4L9ejXuNpd8g=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPSA id 8D3C6334063; 
	Tue, 29 Nov 2011 12:22:20 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 3489152b3a560be744ab3dbb46ae9fb75a8cde24
Message-Id: <3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322598097@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:21:45 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 8 of 9] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


Check that the valid mfn is the one we are mapping, not the
mfn of the page table of the foreign domain.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 5286ed662c1e -r 3489152b3a56 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3572,7 +3572,8 @@ int do_mmu_update(
                         rc = -ENOENT;
                         break;
                     }
-                    else if ( p2m_ram_paging_in_start == l1e_p2mt && !mfn_valid(mfn) )
+                    else if ( p2m_ram_paging_in_start == l1e_p2mt && 
+                                !mfn_valid(l1emfn) )
                     {
                         put_gfn(pg_owner, l1egfn);
                         rc = -ENOENT;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:33:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUMn-0006S1-8Y; Tue, 29 Nov 2011 20:33:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUMl-0006Rt-VT
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:33:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322598765!5545800!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0NTU5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13552 invoked from network); 29 Nov 2011 20:32:45 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 20:32:45 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 40C97714083;
	Tue, 29 Nov 2011 12:32:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=gTzcXeLDE4QKy8NzgmCDeo
	YbZYvod1u2Dd1oawJ1I2sEB4hx6517wRSG9nysMSUr+yb1ot4sNVrsJ6VMgviUIX
	H7y2NbEzgVF0fvVd4oFMgTjI81oi0IPlcQXeK0sMaGRZu1lLA3Qp4C91JTX0Y1A0
	FQnXQU+vDTA+kEvwNkpcQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=vV3dyrrXiJQT
	b0nlbf4/e/sMp6s=; b=rM/5OM1LvZHj3NTCQtUwExwkEMoS6oMN2W6xVRA34jTA
	fGDKtAdg/BePN8j2fWNVycPG49DkZ6f7H7lL57R1fDcHJR4FF7xrzbjcQWNtI0kI
	cjnff1t8CaCgnUjlLqxfGHE5fybxKWt5zXGtNFShu4FqkW3TQ9jyHDkSXQcwhMo=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id C95C9714075; 
	Tue, 29 Nov 2011 12:32:42 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322598766@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:32:46 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Fix correctness race in
	xc_mem_paging_prep
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for this page. 
Foreign mappings of the gfn will now succeed. This is the key idea, as it 
allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Second patch is a tools patch, cc'ed maintainers.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  52 +++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 +++++-
 tools/libxc/xc_mem_event.c   |   4 +-
 tools/libxc/xc_mem_paging.c  |  23 +++++++++++++++++++
 tools/libxc/xenctrl.h        |   2 +
 8 files changed, 85 insertions(+), 10 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:33:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUMn-0006S1-8Y; Tue, 29 Nov 2011 20:33:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVUMl-0006Rt-VT
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:33:24 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1322598765!5545800!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0NTU5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13552 invoked from network); 29 Nov 2011 20:32:45 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 20:32:45 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 40C97714083;
	Tue, 29 Nov 2011 12:32:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=gTzcXeLDE4QKy8NzgmCDeo
	YbZYvod1u2Dd1oawJ1I2sEB4hx6517wRSG9nysMSUr+yb1ot4sNVrsJ6VMgviUIX
	H7y2NbEzgVF0fvVd4oFMgTjI81oi0IPlcQXeK0sMaGRZu1lLA3Qp4C91JTX0Y1A0
	FQnXQU+vDTA+kEvwNkpcQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=vV3dyrrXiJQT
	b0nlbf4/e/sMp6s=; b=rM/5OM1LvZHj3NTCQtUwExwkEMoS6oMN2W6xVRA34jTA
	fGDKtAdg/BePN8j2fWNVycPG49DkZ6f7H7lL57R1fDcHJR4FF7xrzbjcQWNtI0kI
	cjnff1t8CaCgnUjlLqxfGHE5fybxKWt5zXGtNFShu4FqkW3TQ9jyHDkSXQcwhMo=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPSA id C95C9714075; 
	Tue, 29 Nov 2011 12:32:42 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322598766@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 15:32:46 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Fix correctness race in
	xc_mem_paging_prep
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for this page. 
Foreign mappings of the gfn will now succeed. This is the key idea, as it 
allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Second patch is a tools patch, cc'ed maintainers.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  52 +++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 +++++-
 tools/libxc/xc_mem_event.c   |   4 +-
 tools/libxc/xc_mem_paging.c  |  23 +++++++++++++++++++
 tools/libxc/xenctrl.h        |   2 +
 8 files changed, 85 insertions(+), 10 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:48:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:48:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUbJ-0006vZ-HA; Tue, 29 Nov 2011 20:48:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVUbI-0006vS-2k
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:48:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322599665!3617833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30107 invoked from network); 29 Nov 2011 20:47:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 20:47:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,593,1315180800"; 
   d="scan'208";a="9194221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 20:47:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 20:47:45 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVUaf-0005ua-CQ;
	Tue, 29 Nov 2011 20:47:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVUaf-0003Iy-3u;
	Tue, 29 Nov 2011 20:47:45 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10183-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 20:47:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10183: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10183 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10183/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 10182

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   like 10176
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  9c55908af109
baseline version:
 xen                  a2cb7ed6d0a2

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Zhou Peng <zhoupeng@nfs.iscas.ac.cn>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 382 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:48:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:48:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUbJ-0006vZ-HA; Tue, 29 Nov 2011 20:48:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVUbI-0006vS-2k
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:48:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322599665!3617833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAwNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30107 invoked from network); 29 Nov 2011 20:47:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 20:47:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,593,1315180800"; 
   d="scan'208";a="9194221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 20:47:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 29 Nov 2011 20:47:45 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVUaf-0005ua-CQ;
	Tue, 29 Nov 2011 20:47:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVUaf-0003Iy-3u;
	Tue, 29 Nov 2011 20:47:45 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10183-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 29 Nov 2011 20:47:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10183: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10183 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10183/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 10182

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   like 10176
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  9c55908af109
baseline version:
 xen                  a2cb7ed6d0a2

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Zhou Peng <zhoupeng@nfs.iscas.ac.cn>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 382 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:54:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:54:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUgv-0007Fv-DP; Tue, 29 Nov 2011 20:54:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RVUgu-0007FF-7D
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:54:12 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322600012!5550739!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24667 invoked from network); 29 Nov 2011 20:53:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 20:53:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,593,1315195200"; d="scan'208";a="19503140"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:53:31 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Tue, 29 Nov 2011
	15:53:31 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, Paul Durrant <Paul.Durrant@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 15:53:32 -0500
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
	package called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIAAAJ5LcAACUPfPAAAr/AAAA82dWAADcQEA
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724D625C5D@FTLPMAILBOX02.citrite.net>
References: <291EDFCB1E9E224A99088639C4762022B5988E4F3D@LONPMAILBOX01.citrite.net>
	<CAFA6EE7.25E33%keir.xen@gmail.com>
In-Reply-To: <CAFA6EE7.25E33%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have been using EisaId(PNP0A06) in my device without any noticeable ill effect. I see that one in use in various DSDT's I have picked apart too (though I don't see the 0A05 one). So it gets my vote.

Thanks
Ross

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Tuesday, November 29, 2011 6:14 AM
> To: Paul Durrant; Ross Philipson; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> package called ADDR, evaluating to two
> 
> Pick a name and I can fix it up. :-)
> 
>  -- Keir
> 
> On 29/11/2011 17:25, "Paul Durrant" <Paul.Durrant@citrix.com> wrote:
> 
> > Keir,
> >
> > Do you want me to re-send that patch or will you fix it up?
> >
> >   Paul
> >
> >> -----Original Message-----
> >> From: Keir Fraser [mailto:keir.xen@gmail.com]
> >> Sent: 29 November 2011 09:20
> >> To: Ross Philipson; Paul Durrant; xen-devel@lists.xensource.com
> >> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> >> package called ADDR, evaluating to two
> >>
> >> On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com>
> >> wrote:
> >>
> >>>> I have no problem choosing a different _HID. I just don't have a
> >> good
> >>>> reference for what name is not going to clash with something
> >> else.
> >>>> Looks like ACPI0001 was a bad guess. Any better suggestions? What
> >> are
> >>>> the 'generic PNP device IDs'?
> >>>>
> >>>>   Paul
> >>>
> >>> Well I actually brought it up as a discussion point. I have the
> >> same
> >>> sort of issue - I have a generic device for a virtualized
> >> environment.
> >>> I don't really want it to be recognized as anything specific. I
> >> guess I see three options:
> >>>
> >>>  - Use an unassigned APCIXXXX string. I believe the _HID string
> >> values
> >>> of the form "ACPIXXXX" are defined by the ACPI specs themselves so
> >>> this may not work in the long run.
> >>>  - Use one of the predefined generic container EisaId PNP values.
> >> By
> >>> that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at
> >> the
> >>> Linux generic container driver, it doesn't do very much with these
> >>> devices so that might be OK.
> >>
> >> This option sounds reasonable. We have freedom to change it in future
> >> if it turns out to be a bad choice, not that I can see why it would
> >> be.
> >>
> >>  -- Keir
> >>
> >>>  - Acquire a vendor specific EisaId range for Xen (e.g.
> >>> EisaId(XENABCD)). Then we could carve up the product number part
> >> of the ID as we see fit.
> >>
> >
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:54:25 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:54:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUgv-0007Fv-DP; Tue, 29 Nov 2011 20:54:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RVUgu-0007FF-7D
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:54:12 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322600012!5550739!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDI0NzM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24667 invoked from network); 29 Nov 2011 20:53:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Nov 2011 20:53:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,593,1315195200"; d="scan'208";a="19503140"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Nov 2011 15:53:31 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Tue, 29 Nov 2011
	15:53:31 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, Paul Durrant <Paul.Durrant@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 29 Nov 2011 15:53:32 -0500
Thread-Topic: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
	package called ADDR, evaluating to two
Thread-Index: AcyuhdDSrNwbrDyJQb2Z0RNuu7SGowAINtJwAAIsvIAAAJ5LcAACUPfPAAAr/AAAA82dWAADcQEA
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724D625C5D@FTLPMAILBOX02.citrite.net>
References: <291EDFCB1E9E224A99088639C4762022B5988E4F3D@LONPMAILBOX01.citrite.net>
	<CAFA6EE7.25E33%keir.xen@gmail.com>
In-Reply-To: <CAFA6EE7.25E33%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
 package called ADDR, evaluating to two
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have been using EisaId(PNP0A06) in my device without any noticeable ill effect. I see that one in use in various DSDT's I have picked apart too (though I don't see the 0A05 one). So it gets my vote.

Thanks
Ross

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Tuesday, November 29, 2011 6:14 AM
> To: Paul Durrant; Ross Philipson; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> package called ADDR, evaluating to two
> 
> Pick a name and I can fix it up. :-)
> 
>  -- Keir
> 
> On 29/11/2011 17:25, "Paul Durrant" <Paul.Durrant@citrix.com> wrote:
> 
> > Keir,
> >
> > Do you want me to re-send that patch or will you fix it up?
> >
> >   Paul
> >
> >> -----Original Message-----
> >> From: Keir Fraser [mailto:keir.xen@gmail.com]
> >> Sent: 29 November 2011 09:20
> >> To: Ross Philipson; Paul Durrant; xen-devel@lists.xensource.com
> >> Subject: Re: [Xen-devel] [PATCH 1 of 6] Add an ACPI device exposing a
> >> package called ADDR, evaluating to two
> >>
> >> On 29/11/2011 16:29, "Ross Philipson" <Ross.Philipson@citrix.com>
> >> wrote:
> >>
> >>>> I have no problem choosing a different _HID. I just don't have a
> >> good
> >>>> reference for what name is not going to clash with something
> >> else.
> >>>> Looks like ACPI0001 was a bad guess. Any better suggestions? What
> >> are
> >>>> the 'generic PNP device IDs'?
> >>>>
> >>>>   Paul
> >>>
> >>> Well I actually brought it up as a discussion point. I have the
> >> same
> >>> sort of issue - I have a generic device for a virtualized
> >> environment.
> >>> I don't really want it to be recognized as anything specific. I
> >> guess I see three options:
> >>>
> >>>  - Use an unassigned APCIXXXX string. I believe the _HID string
> >> values
> >>> of the form "ACPIXXXX" are defined by the ACPI specs themselves so
> >>> this may not work in the long run.
> >>>  - Use one of the predefined generic container EisaId PNP values.
> >> By
> >>> that I meant using EisaId(PNP0A05) or EisaId(PNP0A06). Looking at
> >> the
> >>> Linux generic container driver, it doesn't do very much with these
> >>> devices so that might be OK.
> >>
> >> This option sounds reasonable. We have freedom to change it in future
> >> if it turns out to be a bad choice, not that I can see why it would
> >> be.
> >>
> >>  -- Keir
> >>
> >>>  - Acquire a vendor specific EisaId range for Xen (e.g.
> >>> EisaId(XENABCD)). Then we could carve up the product number part
> >> of the ID as we see fit.
> >>
> >
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:54:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUgr-0007FW-W8; Tue, 29 Nov 2011 20:54:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVUgp-0007Ep-P1
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:54:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322600007!6296040!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18826 invoked from network); 29 Nov 2011 20:53:29 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 20:53:29 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATKrNal013157
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 15:53:23 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATKrKfW013155;
	Tue, 29 Nov 2011 15:53:20 -0500
Date: Tue, 29 Nov 2011 16:53:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111129205320.GA5511@andromeda.dapyr.net>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
	<1322156679-9441-7-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322156679-9441-7-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V5 06/10] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 05:44:35PM +0000, Anthony PERARD wrote:
> From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
> 
> This function help Xen PCI Passthrough device to check for overlap.

helps
> 
> Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
>  hw/pci.h |    3 +++
>  2 files changed, 50 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 399227f..563bb37 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -2038,3 +2038,50 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
>  {
>      return dev->bus->address_space_io;
>  }
> +
> +int pci_check_bar_overlap(PCIDevice *dev,
> +                          pcibus_t addr, pcibus_t size, uint8_t type)
> +{
> +    PCIBus *bus = dev->bus;
> +    PCIDevice *devices = NULL;
> +    PCIIORegion *r;
> +    int i, j;
> +    int rc = 0;
> +
> +    /* check Overlapped to Base Address */
> +    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
> +        devices = bus->devices[i];
> +        if (!devices) {
> +            continue;
> +        }
> +
> +        /* skip itself */
> +        if (devices->devfn == dev->devfn) {
> +            continue;
> +        }
> +
> +        for (j = 0; j < PCI_NUM_REGIONS; j++) {
> +            r = &devices->io_regions[j];
> +
> +            /* skip different resource type, but don't skip when
> +             * prefetch and non-prefetch memory are compared.
> +             */
> +            if (type != r->type) {
> +                if (type == PCI_BASE_ADDRESS_SPACE_IO ||
> +                    r->type == PCI_BASE_ADDRESS_SPACE_IO) {
> +                    continue;
> +                }
> +            }
> +
> +            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {
> +                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
> +                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
> +                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
> +                       PCI_FUNC(devices->devfn), j, r->addr, r->size);
> +                rc = 1;
> +            }
> +        }
> +    }
> +
> +    return rc;
> +}
> diff --git a/hw/pci.h b/hw/pci.h
> index 625e717..9a723d2 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -552,4 +552,7 @@ static inline void pci_dma_sglist_init(QEMUSGList *qsg, PCIDevice *dev,
>      qemu_sglist_init(qsg, alloc_hint);
>  }
>  
> +int pci_check_bar_overlap(PCIDevice *dev,
> +                          pcibus_t addr, pcibus_t size, uint8_t type);
> +
>  #endif
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 20:54:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 20:54:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVUgr-0007FW-W8; Tue, 29 Nov 2011 20:54:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVUgp-0007Ep-P1
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 20:54:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322600007!6296040!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18826 invoked from network); 29 Nov 2011 20:53:29 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 20:53:29 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATKrNal013157
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 15:53:23 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATKrKfW013155;
	Tue, 29 Nov 2011 15:53:20 -0500
Date: Tue, 29 Nov 2011 16:53:20 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20111129205320.GA5511@andromeda.dapyr.net>
References: <1322156679-9441-1-git-send-email-anthony.perard@citrix.com>
	<1322156679-9441-7-git-send-email-anthony.perard@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1322156679-9441-7-git-send-email-anthony.perard@citrix.com>
User-Agent: Mutt/1.5.9i
Cc: Yuji Shimada <shimada-yxb@necst.nec.co.jp>,
	Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH V5 06/10] pci.c: Add pci_check_bar_overlap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Nov 24, 2011 at 05:44:35PM +0000, Anthony PERARD wrote:
> From: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
> 
> This function help Xen PCI Passthrough device to check for overlap.

helps
> 
> Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/pci.c |   47 +++++++++++++++++++++++++++++++++++++++++++++++
>  hw/pci.h |    3 +++
>  2 files changed, 50 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/pci.c b/hw/pci.c
> index 399227f..563bb37 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -2038,3 +2038,50 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
>  {
>      return dev->bus->address_space_io;
>  }
> +
> +int pci_check_bar_overlap(PCIDevice *dev,
> +                          pcibus_t addr, pcibus_t size, uint8_t type)
> +{
> +    PCIBus *bus = dev->bus;
> +    PCIDevice *devices = NULL;
> +    PCIIORegion *r;
> +    int i, j;
> +    int rc = 0;
> +
> +    /* check Overlapped to Base Address */
> +    for (i = 0; i < ARRAY_SIZE(bus->devices); i++) {
> +        devices = bus->devices[i];
> +        if (!devices) {
> +            continue;
> +        }
> +
> +        /* skip itself */
> +        if (devices->devfn == dev->devfn) {
> +            continue;
> +        }
> +
> +        for (j = 0; j < PCI_NUM_REGIONS; j++) {
> +            r = &devices->io_regions[j];
> +
> +            /* skip different resource type, but don't skip when
> +             * prefetch and non-prefetch memory are compared.
> +             */
> +            if (type != r->type) {
> +                if (type == PCI_BASE_ADDRESS_SPACE_IO ||
> +                    r->type == PCI_BASE_ADDRESS_SPACE_IO) {
> +                    continue;
> +                }
> +            }
> +
> +            if ((addr < (r->addr + r->size)) && ((addr + size) > r->addr)) {
> +                printf("Overlapped to device[%02x:%02x.%x][Region:%d]"
> +                       "[Address:%"PRIx64"h][Size:%"PRIx64"h]\n",
> +                       pci_bus_num(bus), PCI_SLOT(devices->devfn),
> +                       PCI_FUNC(devices->devfn), j, r->addr, r->size);
> +                rc = 1;
> +            }
> +        }
> +    }
> +
> +    return rc;
> +}
> diff --git a/hw/pci.h b/hw/pci.h
> index 625e717..9a723d2 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -552,4 +552,7 @@ static inline void pci_dma_sglist_init(QEMUSGList *qsg, PCIDevice *dev,
>      qemu_sglist_init(qsg, alloc_hint);
>  }
>  
> +int pci_check_bar_overlap(PCIDevice *dev,
> +                          pcibus_t addr, pcibus_t size, uint8_t type);
> +
>  #endif
> -- 
> Anthony PERARD
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:30:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVFK-000861-DK; Tue, 29 Nov 2011 21:29:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <wcohen@redhat.com>) id 1RVVFI-00085w-I9
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:29:44 +0000
X-Env-Sender: wcohen@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322602143!5189778!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU2OTE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29445 invoked from network); 29 Nov 2011 21:29:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 21:29:04 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pATLS8Nn022441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 29 Nov 2011 16:28:08 -0500
Received: from [10.11.231.236] (deploy7.rdu.redhat.com [10.11.231.236])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pATLS7iw012655; Tue, 29 Nov 2011 16:28:07 -0500
Message-ID: <4ED54E66.7040209@redhat.com>
Date: Tue, 29 Nov 2011 16:28:06 -0500
From: William Cohen <wcohen@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4ED4069E.7030307@redhat.com>
	<20111128224545.GA7821@andromeda.dapyr.net>
In-Reply-To: <20111128224545.GA7821@andromeda.dapyr.net>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/28/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
>> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 
> 
> There was one posted some time ago.. Ah:
> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz
> 
> I think that ones works , thought I haven't had a chance to test it
> myself.
>>
>> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?
> 
> Well, the desire is to get a performance tool in upstream that works
> with Xen very very very much.
> 
> The upstream is using the 'perf' framework which is different from oprofile
> and there hasn't been any patches to take advantage of it.
> 
> So to answer your question:
>  1). Its awesome you have posted a patch. Will need to spend some time
>      with it and and with the version that was posted to see if there is
>      something missing. Sadly, the kernel patch is not very
>      upstream-compatible as is. But it will get to folks be able to
>      do some perf analysis instead of using benchmark tools.

If anyone can exercise the patch and verify that it works well with the current upstream xen, that would be greatly appreciated.

> 
>  2). In the future we need to work out the optimal performance tool. It
>      might be oprofile or it might be perf (or it might be both?!). Or
>      it might something that has not yet been posted?
> 
> You wouldn't by any chance be interested in looking at the performance
> "stuff" and figure out what is the best route/tools to use with upstream
> kernels?

There has been some discussion for oprofile to make use of the perf interfaces in future versions of oprofile. The ARM oprofile kernel driver already uses the underlying perf support in the newer kernels. Making oprofile use the perf interface directly would allow normal users to use oprofile to see what is going on with their software and it would allow better cooperative resource allocation of the performance monitoring units.  Also perf allow keeping events on a per thread basis so there would be some hope that different virtual machines could use the counters concurrently.

perf hasn't been ideal. One of the common use cases would be using perf within a virtual machine, but perf didn't handle that case for the performance monitoring hardware. in the past perf claimed it programmed the performance monitoring hardware, but gave bogus measurements. Newer kernels in guest virtual machine now indicate can't hardware perf events are "<not supported>".  

-Will


-Will




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:30:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:30:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVFK-000861-DK; Tue, 29 Nov 2011 21:29:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <wcohen@redhat.com>) id 1RVVFI-00085w-I9
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:29:44 +0000
X-Env-Sender: wcohen@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1322602143!5189778!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDU2OTE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29445 invoked from network); 29 Nov 2011 21:29:04 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 21:29:04 -0000
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
	(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pATLS8Nn022441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 29 Nov 2011 16:28:08 -0500
Received: from [10.11.231.236] (deploy7.rdu.redhat.com [10.11.231.236])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id pATLS7iw012655; Tue, 29 Nov 2011 16:28:07 -0500
Message-ID: <4ED54E66.7040209@redhat.com>
Date: Tue, 29 Nov 2011 16:28:06 -0500
From: William Cohen <wcohen@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111104 Red Hat/3.1.16-2.el6_1
	Thunderbird/3.1.16
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <4ED4069E.7030307@redhat.com>
	<20111128224545.GA7821@andromeda.dapyr.net>
In-Reply-To: <20111128224545.GA7821@andromeda.dapyr.net>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com,
	oprofile-list <oprofile-list@lists.sourceforge.net>
Subject: Re: [Xen-devel] xenoprof patch for oprofile-0.9.7
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 11/28/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
>> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 
> 
> There was one posted some time ago.. Ah:
> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz
> 
> I think that ones works , thought I haven't had a chance to test it
> myself.
>>
>> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?
> 
> Well, the desire is to get a performance tool in upstream that works
> with Xen very very very much.
> 
> The upstream is using the 'perf' framework which is different from oprofile
> and there hasn't been any patches to take advantage of it.
> 
> So to answer your question:
>  1). Its awesome you have posted a patch. Will need to spend some time
>      with it and and with the version that was posted to see if there is
>      something missing. Sadly, the kernel patch is not very
>      upstream-compatible as is. But it will get to folks be able to
>      do some perf analysis instead of using benchmark tools.

If anyone can exercise the patch and verify that it works well with the current upstream xen, that would be greatly appreciated.

> 
>  2). In the future we need to work out the optimal performance tool. It
>      might be oprofile or it might be perf (or it might be both?!). Or
>      it might something that has not yet been posted?
> 
> You wouldn't by any chance be interested in looking at the performance
> "stuff" and figure out what is the best route/tools to use with upstream
> kernels?

There has been some discussion for oprofile to make use of the perf interfaces in future versions of oprofile. The ARM oprofile kernel driver already uses the underlying perf support in the newer kernels. Making oprofile use the perf interface directly would allow normal users to use oprofile to see what is going on with their software and it would allow better cooperative resource allocation of the performance monitoring units.  Also perf allow keeping events on a per thread basis so there would be some hope that different virtual machines could use the counters concurrently.

perf hasn't been ideal. One of the common use cases would be using perf within a virtual machine, but perf didn't handle that case for the performance monitoring hardware. in the past perf claimed it programmed the performance monitoring hardware, but gave bogus measurements. Newer kernels in guest virtual machine now indicate can't hardware perf events are "<not supported>".  

-Will


-Will




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:30:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVG0-0008AH-Rd; Tue, 29 Nov 2011 21:30:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RVVFz-00089g-Km
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:30:27 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322602187!4666490!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gNzc3MTQ=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gNzc3MTQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15018 invoked from network); 29 Nov 2011 21:29:48 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8) by server-13.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 21:29:48 -0000
Received: from klappe2.localnet
	(HSI-KBW-46-223-44-216.hsi.kabel-badenwuerttemberg.de
	[46.223.44.216])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0LnSda-1Qth793Px8-00hKPn; Tue, 29 Nov 2011 22:29:22 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Date: Tue, 29 Nov 2011 21:29:20 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201111292129.20444.arnd@arndb.de>
X-Provags-ID: V02:K0:u8QXi2JlxcuqOLSfaWZ+jXEtmsCZnv6W8WiXa97XIrN
	GS4W96JSnre3lXtRwVYObxrtbNBFGmXUDzewzmiQ6uOCSQ5WEG
	hhDgac2sNSc7TraxHW9OWqAwjYnOLXNDM3297f8l1M8x8S9raI
	8yrQrO/yV+rVt+ancWLhk5qs+DEhTqABIivbtUD1wJzhP3Hw7y
	YPHRacWnLRAuUDwYXvy5/zK8NuyuQtjZMV08Qu497CyRBspg1X
	Gh42C/LABezAgATGy/H8MrD/TYb4tGOmGdd+baRQwssleHgLs1
	TXfI5wGfGxURcrLm3jwkNXCbsqwicE/2osBXzw1ZMHuyAfraIg
	KntVhSLyTHT6EBMiS/zg=
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	kvm@vger.kernel.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	android-virt@lists.cs.columbia.edu, embeddedxen-devel@lists.sourceforge.net
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tuesday 29 November 2011, Stefano Stabellini wrote:
> Hi all,
> a few weeks ago I (and a few others) started hacking on a
> proof-of-concept hypervisor port to Cortex-A15 which uses and requires
> ARMv7 virtualization extensions. The intention of this work was to find
> out how to best support ARM v7+ on Xen. See
> http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
> for more details. 
> 
> I am pleased to announce that significant progress has been made, and
> that we now have a nascent Xen port for Cortex-A15. The port is based on
> xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
> the latest virtualization, LPAE, GIC and generic timer support in
> hardware.

Very nice!

Do you have a pointer to the kernel sources for the Linux guest?
Since Xen and KVM are both in an early working state right now,
it would be very nice if we could agree on the guest model to make
sure that it's always possible to run the same kernel in both
(and potentially other future) hypervisors without modifications.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:30:50 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVG0-0008AH-Rd; Tue, 29 Nov 2011 21:30:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RVVFz-00089g-Km
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:30:27 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322602187!4666490!1
X-Originating-IP: [212.227.17.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gNzc3MTQ=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjggPT4gNzc3MTQ=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15018 invoked from network); 29 Nov 2011 21:29:48 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.8) by server-13.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 21:29:48 -0000
Received: from klappe2.localnet
	(HSI-KBW-46-223-44-216.hsi.kabel-badenwuerttemberg.de
	[46.223.44.216])
	by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis)
	id 0LnSda-1Qth793Px8-00hKPn; Tue, 29 Nov 2011 22:29:22 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Date: Tue, 29 Nov 2011 21:29:20 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201111292129.20444.arnd@arndb.de>
X-Provags-ID: V02:K0:u8QXi2JlxcuqOLSfaWZ+jXEtmsCZnv6W8WiXa97XIrN
	GS4W96JSnre3lXtRwVYObxrtbNBFGmXUDzewzmiQ6uOCSQ5WEG
	hhDgac2sNSc7TraxHW9OWqAwjYnOLXNDM3297f8l1M8x8S9raI
	8yrQrO/yV+rVt+ancWLhk5qs+DEhTqABIivbtUD1wJzhP3Hw7y
	YPHRacWnLRAuUDwYXvy5/zK8NuyuQtjZMV08Qu497CyRBspg1X
	Gh42C/LABezAgATGy/H8MrD/TYb4tGOmGdd+baRQwssleHgLs1
	TXfI5wGfGxURcrLm3jwkNXCbsqwicE/2osBXzw1ZMHuyAfraIg
	KntVhSLyTHT6EBMiS/zg=
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	kvm@vger.kernel.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	android-virt@lists.cs.columbia.edu, embeddedxen-devel@lists.sourceforge.net
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tuesday 29 November 2011, Stefano Stabellini wrote:
> Hi all,
> a few weeks ago I (and a few others) started hacking on a
> proof-of-concept hypervisor port to Cortex-A15 which uses and requires
> ARMv7 virtualization extensions. The intention of this work was to find
> out how to best support ARM v7+ on Xen. See
> http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
> for more details. 
> 
> I am pleased to announce that significant progress has been made, and
> that we now have a nascent Xen port for Cortex-A15. The port is based on
> xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
> the latest virtualization, LPAE, GIC and generic timer support in
> hardware.

Very nice!

Do you have a pointer to the kernel sources for the Linux guest?
Since Xen and KVM are both in an early working state right now,
it would be very nice if we could agree on the guest model to make
sure that it's always possible to run the same kernel in both
(and potentially other future) hypervisors without modifications.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:54:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:54:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVcq-00009D-7v; Tue, 29 Nov 2011 21:54:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVco-000094-Q6
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:54:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322603563!58820528!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU1MjE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16964 invoked from network); 29 Nov 2011 21:52:44 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.202) by server-7.tower-27.messagelabs.com with SMTP;
	29 Nov 2011 21:52:44 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 056B55EC07E;
	Tue, 29 Nov 2011 13:53:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=K8FX2RMmvZ+BhK3CORyE5Tewuzvmew0XUVYvAyGv759/
	B6vhL5bEvwrB/7ytTjvwT5R26nm+UhTziPIIRmuIUWKi4dl0r/mTEAJ+2qzOkT77
	8Ju5HyPttAFVKynaApsjq5ZFvAe2I5oXhHejwzpXjE7Zj/lHoDdpYmhL0J70bpM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=zgcmeSof5AhFDRPjFfe80mywJmQ=; b=p0chdpmZS7J
	o7BHrx9jyuyC0zURrhX4o7eyVQiX2fMB9ZAc0qom+elb6ZstPyKVIPmBI86oer5C
	VcR0g7uWgLGRStpD3JdQKc3QupjsVmAgeF6Hp2NchPbyLSvwpqlKm9KrEOuBd1hf
	nj56QEqQDCpf0dJPtKdnIEwr3oTbdUGo=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id B13D85EC079; 
	Tue, 29 Nov 2011 13:53:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 15da109b0c7df26d8273b138ee714dc9e594fdc7
Message-Id: <15da109b0c7df26d8273.1322603561@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603559@xdev.gridcentric.ca>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:52:41 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Tools: Libxc wrappers to automatically
 fill in page oud page contents on prepare
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_event.c  |   4 ++--
 tools/libxc/xc_mem_paging.c |  23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h       |   2 ++
 3 files changed, 27 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 0ce71e5bfaac -r 15da109b0c7d tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,7 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
+                         unsigned int mode, void *page,
                          void *ring_page, unsigned long gfn)
 {
     DECLARE_DOMCTL;
@@ -34,7 +34,7 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.shared_addr = (unsigned long)shared_page;
+    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
 
     domctl.u.mem_event_op.gfn = gfn;
diff -r 0ce71e5bfaac -r 15da109b0c7d tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -65,6 +65,29 @@ int xc_mem_paging_prep(xc_interface *xch
                                 NULL, NULL, gfn);
 }
 
+int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
+                                unsigned long gfn, void *buffer)
+{
+    int rc;
+
+    if ( !buffer )
+        return -EINVAL;
+
+    if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
+        return -EINVAL;
+
+    if ( mlock(buffer, XC_PAGE_SIZE) )
+        return -errno;
+        
+    rc = xc_mem_event_control(xch, domain_id,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
+                                buffer, NULL, gfn);
+
+    (void)munlock(buffer, XC_PAGE_SIZE);
+    return rc;
+}
+
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
     return xc_mem_event_control(xch, domain_id,
diff -r 0ce71e5bfaac -r 15da109b0c7d tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1866,6 +1866,8 @@ int xc_mem_paging_nominate(xc_interface 
                            unsigned long gfn);
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn);
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
+int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
+                        unsigned long gfn, void *buffer);
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:54:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:54:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVcq-00009D-7v; Tue, 29 Nov 2011 21:54:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVco-000094-Q6
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:54:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322603563!58820528!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU1MjE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16964 invoked from network); 29 Nov 2011 21:52:44 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.202) by server-7.tower-27.messagelabs.com with SMTP;
	29 Nov 2011 21:52:44 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 056B55EC07E;
	Tue, 29 Nov 2011 13:53:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=K8FX2RMmvZ+BhK3CORyE5Tewuzvmew0XUVYvAyGv759/
	B6vhL5bEvwrB/7ytTjvwT5R26nm+UhTziPIIRmuIUWKi4dl0r/mTEAJ+2qzOkT77
	8Ju5HyPttAFVKynaApsjq5ZFvAe2I5oXhHejwzpXjE7Zj/lHoDdpYmhL0J70bpM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=zgcmeSof5AhFDRPjFfe80mywJmQ=; b=p0chdpmZS7J
	o7BHrx9jyuyC0zURrhX4o7eyVQiX2fMB9ZAc0qom+elb6ZstPyKVIPmBI86oer5C
	VcR0g7uWgLGRStpD3JdQKc3QupjsVmAgeF6Hp2NchPbyLSvwpqlKm9KrEOuBd1hf
	nj56QEqQDCpf0dJPtKdnIEwr3oTbdUGo=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id B13D85EC079; 
	Tue, 29 Nov 2011 13:53:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 15da109b0c7df26d8273b138ee714dc9e594fdc7
Message-Id: <15da109b0c7df26d8273.1322603561@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603559@xdev.gridcentric.ca>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:52:41 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Tools: Libxc wrappers to automatically
 fill in page oud page contents on prepare
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_event.c  |   4 ++--
 tools/libxc/xc_mem_paging.c |  23 +++++++++++++++++++++++
 tools/libxc/xenctrl.h       |   2 ++
 3 files changed, 27 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 0ce71e5bfaac -r 15da109b0c7d tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,7 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
+                         unsigned int mode, void *page,
                          void *ring_page, unsigned long gfn)
 {
     DECLARE_DOMCTL;
@@ -34,7 +34,7 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.shared_addr = (unsigned long)shared_page;
+    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
 
     domctl.u.mem_event_op.gfn = gfn;
diff -r 0ce71e5bfaac -r 15da109b0c7d tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -65,6 +65,29 @@ int xc_mem_paging_prep(xc_interface *xch
                                 NULL, NULL, gfn);
 }
 
+int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
+                                unsigned long gfn, void *buffer)
+{
+    int rc;
+
+    if ( !buffer )
+        return -EINVAL;
+
+    if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
+        return -EINVAL;
+
+    if ( mlock(buffer, XC_PAGE_SIZE) )
+        return -errno;
+        
+    rc = xc_mem_event_control(xch, domain_id,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
+                                buffer, NULL, gfn);
+
+    (void)munlock(buffer, XC_PAGE_SIZE);
+    return rc;
+}
+
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
     return xc_mem_event_control(xch, domain_id,
diff -r 0ce71e5bfaac -r 15da109b0c7d tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1866,6 +1866,8 @@ int xc_mem_paging_nominate(xc_interface 
                            unsigned long gfn);
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn);
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
+int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
+                        unsigned long gfn, void *buffer);
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:54:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVcq-00009K-KB; Tue, 29 Nov 2011 21:54:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVcp-000092-Me
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:54:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322603605!5188517!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2OTE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11344 invoked from network); 29 Nov 2011 21:53:26 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.177) by server-9.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 21:53:26 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 44F5E5EC07C;
	Tue, 29 Nov 2011 13:53:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=lUJ3WV3PKQGEcyCxf7dzSu
	2KbaVqZZSl7cz8GVPxRc2HOQQ9bhKYNkFXTkwkY+NRah03u/SRsO+6VEk0b+ogfM
	+RTGIUhX4Sj668RxYommLdt94L9Z1rOpmQKEGA1pBq+u7cqFG4TVPREucul4hf/y
	aQnpZbXuDnsyZHsoI7OnU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=vMj+qvVLn4pJ
	jff18KH57mcAXLA=; b=NlAAViuhqRpEo9O1+SqFFXcs9BDLu/R+zD4L3UKGXbEi
	LeZawrEARPDFn1itegNS4lMt7pbvKLdnh3sENLBVND2qFuw0p1MoGD5eomEq68vm
	onkmYQGNldfdBW6EFT1iTUzSLodjPDLgAdyR31R7nb3TCx6vClZ+VmMkZNAkark=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 2BE825EC079; 
	Tue, 29 Nov 2011 13:53:24 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322603559@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:52:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Fix correctness race in
	xc_mem_paging_prep
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for this page. 
Foreign mappings of the gfn will now succeed. This is the key idea, as it 
allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Second patch is a tools patch, cc'ed maintainers.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  52 +++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 +++++-
 tools/libxc/xc_mem_event.c   |   4 +-
 tools/libxc/xc_mem_paging.c  |  23 +++++++++++++++++++
 tools/libxc/xenctrl.h        |   2 +
 8 files changed, 85 insertions(+), 10 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:54:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:54:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVcq-00009K-KB; Tue, 29 Nov 2011 21:54:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVcp-000092-Me
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:54:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322603605!5188517!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTQ2OTE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11344 invoked from network); 29 Nov 2011 21:53:26 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.177) by server-9.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 21:53:26 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 44F5E5EC07C;
	Tue, 29 Nov 2011 13:53:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=lUJ3WV3PKQGEcyCxf7dzSu
	2KbaVqZZSl7cz8GVPxRc2HOQQ9bhKYNkFXTkwkY+NRah03u/SRsO+6VEk0b+ogfM
	+RTGIUhX4Sj668RxYommLdt94L9Z1rOpmQKEGA1pBq+u7cqFG4TVPREucul4hf/y
	aQnpZbXuDnsyZHsoI7OnU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=vMj+qvVLn4pJ
	jff18KH57mcAXLA=; b=NlAAViuhqRpEo9O1+SqFFXcs9BDLu/R+zD4L3UKGXbEi
	LeZawrEARPDFn1itegNS4lMt7pbvKLdnh3sENLBVND2qFuw0p1MoGD5eomEq68vm
	onkmYQGNldfdBW6EFT1iTUzSLodjPDLgAdyR31R7nb3TCx6vClZ+VmMkZNAkark=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 2BE825EC079; 
	Tue, 29 Nov 2011 13:53:24 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322603559@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:52:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Fix correctness race in
	xc_mem_paging_prep
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for this page. 
Foreign mappings of the gfn will now succeed. This is the key idea, as it 
allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Second patch is a tools patch, cc'ed maintainers.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  52 +++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 +++++-
 tools/libxc/xc_mem_event.c   |   4 +-
 tools/libxc/xc_mem_paging.c  |  23 +++++++++++++++++++
 tools/libxc/xenctrl.h        |   2 +
 8 files changed, 85 insertions(+), 10 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:54:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:54:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVcv-00009Z-1c; Tue, 29 Nov 2011 21:54:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVcs-000093-VY
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:54:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322603608!6141322!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU2ODU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17369 invoked from network); 29 Nov 2011 21:53:28 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.202) by server-6.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 21:53:28 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 48DD75EC080;
	Tue, 29 Nov 2011 13:53:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=qajCWKjtqmj49bLyv8Xsu5eZphWKgDVc3ZNcJgIt74I5
	Eu5VDOAFgWn98DVX3AT8Xd4/Lk7eukyzMvGX4EbSs/gxpuZSY7uD4pKbwPJrm+q4
	GYNhTomhz0onSNq4F66K1Gw5kdJ2yWJ3vy44fJPXs7ollh16G3osMv0zACnJTXg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=LceoB2RPPaiIdtHOFGKBMwXnTZo=; b=FFAL1X6Kl7x
	vgegcsAnNn8lOA0KRIeMXAg0qHwMDLKfWu0htY9hJ9wBvmQuRl72xR7Wl+0N4vFp
	AU+cYWmEtopaLWpJXHODhAh6UjZnS/inEUlTA/k1iYjVmq+rUsIRZdnhpsARjlPs
	kmHKouXG/8sdMJiab16jGsIQoA2eyNXk=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 876105EC079; 
	Tue, 29 Nov 2011 13:53:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0ce71e5bfaac7e8fe5b83f1b75d3b896882c7494
Message-Id: <0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603559@xdev.gridcentric.ca>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:52:40 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  52 +++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 +++++-
 5 files changed, 58 insertions(+), 8 deletions(-)


p2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for that page.
Foreign mappings of the gfn will now succeed. This is the key idea, as
it allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -45,7 +45,7 @@ static int mem_event_enable(struct domai
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->shared_addr;
+    unsigned long shared_addr = mec->u.shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -47,7 +47,7 @@ int mem_paging_domctl(struct domain *d, 
     case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn);
+        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
     }
     break;
 
diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -974,14 +974,43 @@ void p2m_mem_paging_populate(struct doma
  * mfn if populate was called for  gfn which was nominated but not evicted. In
  * this case only the p2mt needs to be forwarded.
  */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
 {
     struct page_info *page;
     p2m_type_t p2mt;
     p2m_access_t a;
-    mfn_t mfn;
+    mfn_t mfn, buf_mfn = _mfn(INVALID_MFN);
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int ret;
+    int ret, page_extant = 1;
+    void *buf_map = NULL;
+
+    /* Map buffer page, if any, and get a reference */
+    if ( buffer )
+    {
+        l1_pgentry_t l1e;
+        unsigned long buf_gfn;
+        p2m_type_t buf_p2mt;
+
+        if ( (buffer & (PAGE_SIZE - 1)) || 
+             (!access_ok(buffer, PAGE_SIZE)) )
+            return -EINVAL;
+
+        guest_get_eff_l1e(current, buffer, &l1e);
+        buf_gfn = l1e_get_pfn(l1e);
+        buf_mfn = get_gfn(current->domain, buf_gfn, 
+                            &buf_p2mt);
+
+        if ( likely( mfn_valid(buf_mfn) &&
+                     p2m_is_ram(buf_p2mt) ) )
+        {
+            get_page(mfn_to_page(buf_mfn), current->domain);
+            buf_map = map_domain_page(mfn_x(buf_mfn));
+            put_gfn(current->domain, buf_gfn);
+        } else {
+            put_gfn(current->domain, buf_gfn);
+            return -EINVAL;
+        }
+    }
 
     p2m_lock(p2m);
 
@@ -1001,6 +1030,18 @@ int p2m_mem_paging_prep(struct domain *d
         if ( unlikely(page == NULL) )
             goto out;
         mfn = page_to_mfn(page);
+        page_extant = 0;
+    }
+
+    /* If we were given a buffer, now is the time to use it */
+    if ( !page_extant && buffer )
+    {
+        void *guest_map;
+
+        ASSERT( mfn_valid(mfn) );
+        guest_map = map_domain_page(mfn_x(mfn));
+        memcpy(guest_map, buf_map, PAGE_SIZE);
+        unmap_domain_page(guest_map);
     }
 
     /* Fix p2m mapping */
@@ -1012,6 +1053,11 @@ int p2m_mem_paging_prep(struct domain *d
 
  out:
     p2m_unlock(p2m);
+    if ( buffer )
+    {
+        unmap_domain_page(buf_map);
+        put_page(mfn_to_page(buf_mfn));
+    }
     return ret;
 }
 
diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -479,7 +479,7 @@ void p2m_mem_paging_drop_page(struct dom
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn);
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer);
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -742,8 +742,12 @@ struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    /* OP_ENABLE */
-    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
+    union {
+        /* OP_ENABLE IN:  Virtual address of shared page */
+        uint64_aligned_t shared_addr;  
+        /* PAGING_PREP IN: buffer to immediately fill page in */
+        uint64_aligned_t buffer;
+    } u;
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
 
     /* Other OPs */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:54:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:54:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVcv-00009Z-1c; Tue, 29 Nov 2011 21:54:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVcs-000093-VY
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:54:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322603608!6141322!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU2ODU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17369 invoked from network); 29 Nov 2011 21:53:28 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.202) by server-6.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 21:53:28 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 48DD75EC080;
	Tue, 29 Nov 2011 13:53:27 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=qajCWKjtqmj49bLyv8Xsu5eZphWKgDVc3ZNcJgIt74I5
	Eu5VDOAFgWn98DVX3AT8Xd4/Lk7eukyzMvGX4EbSs/gxpuZSY7uD4pKbwPJrm+q4
	GYNhTomhz0onSNq4F66K1Gw5kdJ2yWJ3vy44fJPXs7ollh16G3osMv0zACnJTXg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=LceoB2RPPaiIdtHOFGKBMwXnTZo=; b=FFAL1X6Kl7x
	vgegcsAnNn8lOA0KRIeMXAg0qHwMDLKfWu0htY9hJ9wBvmQuRl72xR7Wl+0N4vFp
	AU+cYWmEtopaLWpJXHODhAh6UjZnS/inEUlTA/k1iYjVmq+rUsIRZdnhpsARjlPs
	kmHKouXG/8sdMJiab16jGsIQoA2eyNXk=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 876105EC079; 
	Tue, 29 Nov 2011 13:53:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0ce71e5bfaac7e8fe5b83f1b75d3b896882c7494
Message-Id: <0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603559@xdev.gridcentric.ca>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:52:40 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c |   2 +-
 xen/arch/x86/mm/p2m.c        |  52 +++++++++++++++++++++++++++++++++++++++++--
 xen/include/asm-x86/p2m.h    |   2 +-
 xen/include/public/domctl.h  |   8 +++++-
 5 files changed, 58 insertions(+), 8 deletions(-)


p2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for that page.
Foreign mappings of the gfn will now succeed. This is the key idea, as
it allows the pager to now map the gfn and fill in its contents.

Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.

Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -45,7 +45,7 @@ static int mem_event_enable(struct domai
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->shared_addr;
+    unsigned long shared_addr = mec->u.shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -47,7 +47,7 @@ int mem_paging_domctl(struct domain *d, 
     case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn);
+        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
     }
     break;
 
diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -974,14 +974,43 @@ void p2m_mem_paging_populate(struct doma
  * mfn if populate was called for  gfn which was nominated but not evicted. In
  * this case only the p2mt needs to be forwarded.
  */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
 {
     struct page_info *page;
     p2m_type_t p2mt;
     p2m_access_t a;
-    mfn_t mfn;
+    mfn_t mfn, buf_mfn = _mfn(INVALID_MFN);
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
-    int ret;
+    int ret, page_extant = 1;
+    void *buf_map = NULL;
+
+    /* Map buffer page, if any, and get a reference */
+    if ( buffer )
+    {
+        l1_pgentry_t l1e;
+        unsigned long buf_gfn;
+        p2m_type_t buf_p2mt;
+
+        if ( (buffer & (PAGE_SIZE - 1)) || 
+             (!access_ok(buffer, PAGE_SIZE)) )
+            return -EINVAL;
+
+        guest_get_eff_l1e(current, buffer, &l1e);
+        buf_gfn = l1e_get_pfn(l1e);
+        buf_mfn = get_gfn(current->domain, buf_gfn, 
+                            &buf_p2mt);
+
+        if ( likely( mfn_valid(buf_mfn) &&
+                     p2m_is_ram(buf_p2mt) ) )
+        {
+            get_page(mfn_to_page(buf_mfn), current->domain);
+            buf_map = map_domain_page(mfn_x(buf_mfn));
+            put_gfn(current->domain, buf_gfn);
+        } else {
+            put_gfn(current->domain, buf_gfn);
+            return -EINVAL;
+        }
+    }
 
     p2m_lock(p2m);
 
@@ -1001,6 +1030,18 @@ int p2m_mem_paging_prep(struct domain *d
         if ( unlikely(page == NULL) )
             goto out;
         mfn = page_to_mfn(page);
+        page_extant = 0;
+    }
+
+    /* If we were given a buffer, now is the time to use it */
+    if ( !page_extant && buffer )
+    {
+        void *guest_map;
+
+        ASSERT( mfn_valid(mfn) );
+        guest_map = map_domain_page(mfn_x(mfn));
+        memcpy(guest_map, buf_map, PAGE_SIZE);
+        unmap_domain_page(guest_map);
     }
 
     /* Fix p2m mapping */
@@ -1012,6 +1053,11 @@ int p2m_mem_paging_prep(struct domain *d
 
  out:
     p2m_unlock(p2m);
+    if ( buffer )
+    {
+        unmap_domain_page(buf_map);
+        put_page(mfn_to_page(buf_mfn));
+    }
     return ret;
 }
 
diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -479,7 +479,7 @@ void p2m_mem_paging_drop_page(struct dom
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
-int p2m_mem_paging_prep(struct domain *d, unsigned long gfn);
+int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer);
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -742,8 +742,12 @@ struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    /* OP_ENABLE */
-    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
+    union {
+        /* OP_ENABLE IN:  Virtual address of shared page */
+        uint64_aligned_t shared_addr;  
+        /* PAGING_PREP IN: buffer to immediately fill page in */
+        uint64_aligned_t buffer;
+    } u;
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
 
     /* Other OPs */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVen-0000NO-It; Tue, 29 Nov 2011 21:56:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVel-0000LP-Qg
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:56:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322603724!6154240!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2ODYy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2ODYy\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11159 invoked from network); 29 Nov 2011 21:55:24 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-12.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 21:55:24 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id A6BC645807B;
	Tue, 29 Nov 2011 13:55:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=YXHXbVJ/izs95JeewQzppeH15i8VrlYG/C3cdRaTlx7w
	0cvp1YahTMKa3RUdEbu5Z2QTuWngdIVSKosWC3e0THi8khIPRw8vlvvGQlNYszRz
	49GzvG+JhCtIOLtgmR4zFpRH0Wj3Rcjd1Gq/NON+BMnn3Tu8EW/tslkVeCBQCXU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=gsdOFk4nQkI7CmJvzauD1UPMtRM=; b=jaMTRSfTIvk
	JJK74uMAEuHxKcwb6Pd5BffZ7O02KrQoBfucwL0h9c4jTlfpL+4MiIFQxKNQ4Lnk
	ceGcYs00pCO5+eYBGml0D8bm4lrNuDdPMsCk5ne4Ikskr6LBDlM0hy8O3WYXy176
	C1bpLKl9oaYvpUMGsATBrcW/BjcbLvIQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id B83FC458085; 
	Tue, 29 Nov 2011 13:55:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 96ba0cb6e255c724ae728649af05801abe55df18
Message-Id: <96ba0cb6e255c724ae72.1322603712@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603709@xdev.gridcentric.ca>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:12 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 5] Create a generic callback mechanism for
 Xen-bound event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/ia64/vmx/vmx_init.c |   2 +-
 xen/arch/x86/hvm/hvm.c       |   7 ++-
 xen/arch/x86/mm/mem_event.c  |   3 +-
 xen/common/event_channel.c   |  75 ++++++++++++++++++++++++++++++++++---------
 xen/include/xen/event.h      |   5 ++-
 xen/include/xen/sched.h      |   2 +-
 6 files changed, 70 insertions(+), 24 deletions(-)


For event channels for which Xen is the consumer, there currently is
a single action. With this patch, we allow event channel creators to
specify a generic callback (or no callback). Because the expectation
is that there will be few callbacks, they are stored in a small table.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 43dc614d543c -r 96ba0cb6e255 xen/arch/ia64/vmx/vmx_init.c
--- a/xen/arch/ia64/vmx/vmx_init.c
+++ b/xen/arch/ia64/vmx/vmx_init.c
@@ -377,7 +377,7 @@ vmx_vcpu_initialise(struct vcpu *v)
 {
 	struct vmx_ioreq_page *iorp = &v->domain->arch.hvm_domain.ioreq;
 
-	int rc = alloc_unbound_xen_event_channel(v, 0);
+	int rc = alloc_unbound_xen_event_channel(v, 0, NULL);
 	if (rc < 0)
 		return rc;
 	v->arch.arch_vmx.xen_port = rc;
diff -r 43dc614d543c -r 96ba0cb6e255 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -979,7 +979,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
         goto fail3;
 
     /* Create ioreq event channel. */
-    rc = alloc_unbound_xen_event_channel(v, 0);
+    rc = alloc_unbound_xen_event_channel(v, 0, NULL);
     if ( rc < 0 )
         goto fail4;
 
@@ -989,7 +989,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
     if ( v->vcpu_id == 0 )
     {
         /* Create bufioreq event channel. */
-        rc = alloc_unbound_xen_event_channel(v, 0);
+        rc = alloc_unbound_xen_event_channel(v, 0, NULL);
         if ( rc < 0 )
             goto fail2;
         v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN] = rc;
@@ -3551,7 +3551,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 for_each_vcpu ( d, v )
                 {
                     int old_port, new_port;
-                    new_port = alloc_unbound_xen_event_channel(v, a.value);
+                    new_port = alloc_unbound_xen_event_channel(
+                        v, a.value, NULL);
                     if ( new_port < 0 )
                     {
                         rc = new_port;
diff -r 43dc614d543c -r 96ba0cb6e255 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -96,7 +96,8 @@ static int mem_event_enable(struct domai
 
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
-                                         current->domain->domain_id);
+                                         current->domain->domain_id,
+                                         NULL);
     if ( rc < 0 )
         goto err;
 
diff -r 43dc614d543c -r 96ba0cb6e255 xen/common/event_channel.c
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -57,6 +57,51 @@
         goto out;                                                   \
     } while ( 0 )
 
+#define consumer_is_xen(e) (!!(e)->xen_consumer)
+
+/*
+ * The function alloc_unbound_xen_event_channel() allows an arbitrary
+ * notifier function to be specified. However, very few unique functions
+ * are specified in practice, so to prevent bloating the evtchn structure
+ * with a pointer, we stash them dynamically in a small lookup array which
+ * can be indexed by a small integer.
+ */
+static xen_event_channel_notification_t xen_consumers[8];
+
+/* Default notification action: wake up from wait_on_xen_event_channel(). */
+static void default_xen_notification_fn(struct vcpu *v, unsigned int port)
+{
+    /* Consumer needs notification only if blocked. */
+    if ( test_and_clear_bit(_VPF_blocked_in_xen, &v->pause_flags) )
+        vcpu_wake(v);
+}
+
+/*
+ * Given a notification function, return the value to stash in
+ * the evtchn->xen_consumer field.
+ */
+static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
+{
+    unsigned int i;
+
+    if ( fn == NULL )
+        fn = default_xen_notification_fn;
+
+    for ( i = 0; i < ARRAY_SIZE(xen_consumers); i++ )
+    {
+        if ( xen_consumers[i] == NULL )
+            xen_consumers[i] = fn;
+        if ( xen_consumers[i] == fn )
+            break;
+    }
+
+    BUG_ON(i >= ARRAY_SIZE(xen_consumers));
+    return i+1;
+}
+
+/* Get the notification function for a given Xen-bound event channel. */
+#define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
+
 static int evtchn_set_pending(struct vcpu *v, int port);
 
 static int virq_is_global(int virq)
@@ -397,7 +442,7 @@ static long __evtchn_close(struct domain
     chn1 = evtchn_from_port(d1, port1);
 
     /* Guest cannot close a Xen-attached event channel. */
-    if ( unlikely(chn1->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(chn1)) )
     {
         rc = -EINVAL;
         goto out;
@@ -537,7 +582,7 @@ int evtchn_send(struct domain *d, unsign
     lchn = evtchn_from_port(ld, lport);
 
     /* Guest cannot send via a Xen-attached event channel. */
-    if ( unlikely(lchn->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(lchn)) )
     {
         spin_unlock(&ld->event_lock);
         return -EINVAL;
@@ -554,13 +599,8 @@ int evtchn_send(struct domain *d, unsign
         rport = lchn->u.interdomain.remote_port;
         rchn  = evtchn_from_port(rd, rport);
         rvcpu = rd->vcpu[rchn->notify_vcpu_id];
-        if ( rchn->consumer_is_xen )
-        {
-            /* Xen consumers need notification only if they are blocked. */
-            if ( test_and_clear_bit(_VPF_blocked_in_xen,
-                                    &rvcpu->pause_flags) )
-                vcpu_wake(rvcpu);
-        }
+        if ( consumer_is_xen(rchn) )
+            (*xen_notification_fn(rchn))(rvcpu, rport);
         else
         {
             evtchn_set_pending(rvcpu, rport);
@@ -787,7 +827,7 @@ long evtchn_bind_vcpu(unsigned int port,
     chn = evtchn_from_port(d, port);
 
     /* Guest cannot re-bind a Xen-attached event channel. */
-    if ( unlikely(chn->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(chn)) )
     {
         rc = -EINVAL;
         goto out;
@@ -998,7 +1038,8 @@ long do_event_channel_op(int cmd, XEN_GU
 
 
 int alloc_unbound_xen_event_channel(
-    struct vcpu *local_vcpu, domid_t remote_domid)
+    struct vcpu *local_vcpu, domid_t remote_domid,
+    xen_event_channel_notification_t notification_fn)
 {
     struct evtchn *chn;
     struct domain *d = local_vcpu->domain;
@@ -1011,7 +1052,7 @@ int alloc_unbound_xen_event_channel(
     chn = evtchn_from_port(d, port);
 
     chn->state = ECS_UNBOUND;
-    chn->consumer_is_xen = 1;
+    chn->xen_consumer = get_xen_consumer(notification_fn);
     chn->notify_vcpu_id = local_vcpu->vcpu_id;
     chn->u.unbound.remote_domid = remote_domid;
 
@@ -1038,8 +1079,8 @@ void free_xen_event_channel(
 
     BUG_ON(!port_is_valid(d, port));
     chn = evtchn_from_port(d, port);
-    BUG_ON(!chn->consumer_is_xen);
-    chn->consumer_is_xen = 0;
+    BUG_ON(!consumer_is_xen(chn));
+    chn->xen_consumer = 0;
 
     spin_unlock(&d->event_lock);
 
@@ -1063,7 +1104,7 @@ void notify_via_xen_event_channel(struct
 
     ASSERT(port_is_valid(ld, lport));
     lchn = evtchn_from_port(ld, lport);
-    ASSERT(lchn->consumer_is_xen);
+    ASSERT(consumer_is_xen(lchn));
 
     if ( likely(lchn->state == ECS_INTERDOMAIN) )
     {
@@ -1106,7 +1147,7 @@ void evtchn_destroy(struct domain *d)
     /* Close all existing event channels. */
     for ( i = 0; port_is_valid(d, i); i++ )
     {
-        evtchn_from_port(d, i)->consumer_is_xen = 0;
+        evtchn_from_port(d, i)->xen_consumer = 0;
         (void)__evtchn_close(d, i);
     }
 
@@ -1192,7 +1233,7 @@ static void domain_dump_evtchn_info(stru
             printk(" v=%d", chn->u.virq);
             break;
         }
-        printk(" x=%d\n", chn->consumer_is_xen);
+        printk(" x=%d\n", chn->xen_consumer);
     }
 
     spin_unlock(&d->event_lock);
diff -r 43dc614d543c -r 96ba0cb6e255 xen/include/xen/event.h
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -51,8 +51,11 @@ int evtchn_unmask(unsigned int port);
 void evtchn_move_pirqs(struct vcpu *v);
 
 /* Allocate/free a Xen-attached event channel port. */
+typedef void (*xen_event_channel_notification_t)(
+    struct vcpu *v, unsigned int port);
 int alloc_unbound_xen_event_channel(
-    struct vcpu *local_vcpu, domid_t remote_domid);
+    struct vcpu *local_vcpu, domid_t remote_domid,
+    xen_event_channel_notification_t notification_fn);
 void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
diff -r 43dc614d543c -r 96ba0cb6e255 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -47,7 +47,7 @@ struct evtchn
 #define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
 #define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
     u8  state;             /* ECS_* */
-    u8  consumer_is_xen;   /* Consumed by Xen or by guest? */
+    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
     u16 notify_vcpu_id;    /* VCPU for local delivery notification */
     union {
         struct {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVen-0000NO-It; Tue, 29 Nov 2011 21:56:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVel-0000LP-Qg
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:56:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1322603724!6154240!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2ODYy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE2ODYy\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11159 invoked from network); 29 Nov 2011 21:55:24 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-12.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 21:55:24 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id A6BC645807B;
	Tue, 29 Nov 2011 13:55:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=YXHXbVJ/izs95JeewQzppeH15i8VrlYG/C3cdRaTlx7w
	0cvp1YahTMKa3RUdEbu5Z2QTuWngdIVSKosWC3e0THi8khIPRw8vlvvGQlNYszRz
	49GzvG+JhCtIOLtgmR4zFpRH0Wj3Rcjd1Gq/NON+BMnn3Tu8EW/tslkVeCBQCXU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=gsdOFk4nQkI7CmJvzauD1UPMtRM=; b=jaMTRSfTIvk
	JJK74uMAEuHxKcwb6Pd5BffZ7O02KrQoBfucwL0h9c4jTlfpL+4MiIFQxKNQ4Lnk
	ceGcYs00pCO5+eYBGml0D8bm4lrNuDdPMsCk5ne4Ikskr6LBDlM0hy8O3WYXy176
	C1bpLKl9oaYvpUMGsATBrcW/BjcbLvIQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id B83FC458085; 
	Tue, 29 Nov 2011 13:55:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 96ba0cb6e255c724ae728649af05801abe55df18
Message-Id: <96ba0cb6e255c724ae72.1322603712@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603709@xdev.gridcentric.ca>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:12 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 5] Create a generic callback mechanism for
 Xen-bound event channels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/ia64/vmx/vmx_init.c |   2 +-
 xen/arch/x86/hvm/hvm.c       |   7 ++-
 xen/arch/x86/mm/mem_event.c  |   3 +-
 xen/common/event_channel.c   |  75 ++++++++++++++++++++++++++++++++++---------
 xen/include/xen/event.h      |   5 ++-
 xen/include/xen/sched.h      |   2 +-
 6 files changed, 70 insertions(+), 24 deletions(-)


For event channels for which Xen is the consumer, there currently is
a single action. With this patch, we allow event channel creators to
specify a generic callback (or no callback). Because the expectation
is that there will be few callbacks, they are stored in a small table.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 43dc614d543c -r 96ba0cb6e255 xen/arch/ia64/vmx/vmx_init.c
--- a/xen/arch/ia64/vmx/vmx_init.c
+++ b/xen/arch/ia64/vmx/vmx_init.c
@@ -377,7 +377,7 @@ vmx_vcpu_initialise(struct vcpu *v)
 {
 	struct vmx_ioreq_page *iorp = &v->domain->arch.hvm_domain.ioreq;
 
-	int rc = alloc_unbound_xen_event_channel(v, 0);
+	int rc = alloc_unbound_xen_event_channel(v, 0, NULL);
 	if (rc < 0)
 		return rc;
 	v->arch.arch_vmx.xen_port = rc;
diff -r 43dc614d543c -r 96ba0cb6e255 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -979,7 +979,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
         goto fail3;
 
     /* Create ioreq event channel. */
-    rc = alloc_unbound_xen_event_channel(v, 0);
+    rc = alloc_unbound_xen_event_channel(v, 0, NULL);
     if ( rc < 0 )
         goto fail4;
 
@@ -989,7 +989,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
     if ( v->vcpu_id == 0 )
     {
         /* Create bufioreq event channel. */
-        rc = alloc_unbound_xen_event_channel(v, 0);
+        rc = alloc_unbound_xen_event_channel(v, 0, NULL);
         if ( rc < 0 )
             goto fail2;
         v->domain->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN] = rc;
@@ -3551,7 +3551,8 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 for_each_vcpu ( d, v )
                 {
                     int old_port, new_port;
-                    new_port = alloc_unbound_xen_event_channel(v, a.value);
+                    new_port = alloc_unbound_xen_event_channel(
+                        v, a.value, NULL);
                     if ( new_port < 0 )
                     {
                         rc = new_port;
diff -r 43dc614d543c -r 96ba0cb6e255 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -96,7 +96,8 @@ static int mem_event_enable(struct domai
 
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
-                                         current->domain->domain_id);
+                                         current->domain->domain_id,
+                                         NULL);
     if ( rc < 0 )
         goto err;
 
diff -r 43dc614d543c -r 96ba0cb6e255 xen/common/event_channel.c
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -57,6 +57,51 @@
         goto out;                                                   \
     } while ( 0 )
 
+#define consumer_is_xen(e) (!!(e)->xen_consumer)
+
+/*
+ * The function alloc_unbound_xen_event_channel() allows an arbitrary
+ * notifier function to be specified. However, very few unique functions
+ * are specified in practice, so to prevent bloating the evtchn structure
+ * with a pointer, we stash them dynamically in a small lookup array which
+ * can be indexed by a small integer.
+ */
+static xen_event_channel_notification_t xen_consumers[8];
+
+/* Default notification action: wake up from wait_on_xen_event_channel(). */
+static void default_xen_notification_fn(struct vcpu *v, unsigned int port)
+{
+    /* Consumer needs notification only if blocked. */
+    if ( test_and_clear_bit(_VPF_blocked_in_xen, &v->pause_flags) )
+        vcpu_wake(v);
+}
+
+/*
+ * Given a notification function, return the value to stash in
+ * the evtchn->xen_consumer field.
+ */
+static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
+{
+    unsigned int i;
+
+    if ( fn == NULL )
+        fn = default_xen_notification_fn;
+
+    for ( i = 0; i < ARRAY_SIZE(xen_consumers); i++ )
+    {
+        if ( xen_consumers[i] == NULL )
+            xen_consumers[i] = fn;
+        if ( xen_consumers[i] == fn )
+            break;
+    }
+
+    BUG_ON(i >= ARRAY_SIZE(xen_consumers));
+    return i+1;
+}
+
+/* Get the notification function for a given Xen-bound event channel. */
+#define xen_notification_fn(e) (xen_consumers[(e)->xen_consumer-1])
+
 static int evtchn_set_pending(struct vcpu *v, int port);
 
 static int virq_is_global(int virq)
@@ -397,7 +442,7 @@ static long __evtchn_close(struct domain
     chn1 = evtchn_from_port(d1, port1);
 
     /* Guest cannot close a Xen-attached event channel. */
-    if ( unlikely(chn1->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(chn1)) )
     {
         rc = -EINVAL;
         goto out;
@@ -537,7 +582,7 @@ int evtchn_send(struct domain *d, unsign
     lchn = evtchn_from_port(ld, lport);
 
     /* Guest cannot send via a Xen-attached event channel. */
-    if ( unlikely(lchn->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(lchn)) )
     {
         spin_unlock(&ld->event_lock);
         return -EINVAL;
@@ -554,13 +599,8 @@ int evtchn_send(struct domain *d, unsign
         rport = lchn->u.interdomain.remote_port;
         rchn  = evtchn_from_port(rd, rport);
         rvcpu = rd->vcpu[rchn->notify_vcpu_id];
-        if ( rchn->consumer_is_xen )
-        {
-            /* Xen consumers need notification only if they are blocked. */
-            if ( test_and_clear_bit(_VPF_blocked_in_xen,
-                                    &rvcpu->pause_flags) )
-                vcpu_wake(rvcpu);
-        }
+        if ( consumer_is_xen(rchn) )
+            (*xen_notification_fn(rchn))(rvcpu, rport);
         else
         {
             evtchn_set_pending(rvcpu, rport);
@@ -787,7 +827,7 @@ long evtchn_bind_vcpu(unsigned int port,
     chn = evtchn_from_port(d, port);
 
     /* Guest cannot re-bind a Xen-attached event channel. */
-    if ( unlikely(chn->consumer_is_xen) )
+    if ( unlikely(consumer_is_xen(chn)) )
     {
         rc = -EINVAL;
         goto out;
@@ -998,7 +1038,8 @@ long do_event_channel_op(int cmd, XEN_GU
 
 
 int alloc_unbound_xen_event_channel(
-    struct vcpu *local_vcpu, domid_t remote_domid)
+    struct vcpu *local_vcpu, domid_t remote_domid,
+    xen_event_channel_notification_t notification_fn)
 {
     struct evtchn *chn;
     struct domain *d = local_vcpu->domain;
@@ -1011,7 +1052,7 @@ int alloc_unbound_xen_event_channel(
     chn = evtchn_from_port(d, port);
 
     chn->state = ECS_UNBOUND;
-    chn->consumer_is_xen = 1;
+    chn->xen_consumer = get_xen_consumer(notification_fn);
     chn->notify_vcpu_id = local_vcpu->vcpu_id;
     chn->u.unbound.remote_domid = remote_domid;
 
@@ -1038,8 +1079,8 @@ void free_xen_event_channel(
 
     BUG_ON(!port_is_valid(d, port));
     chn = evtchn_from_port(d, port);
-    BUG_ON(!chn->consumer_is_xen);
-    chn->consumer_is_xen = 0;
+    BUG_ON(!consumer_is_xen(chn));
+    chn->xen_consumer = 0;
 
     spin_unlock(&d->event_lock);
 
@@ -1063,7 +1104,7 @@ void notify_via_xen_event_channel(struct
 
     ASSERT(port_is_valid(ld, lport));
     lchn = evtchn_from_port(ld, lport);
-    ASSERT(lchn->consumer_is_xen);
+    ASSERT(consumer_is_xen(lchn));
 
     if ( likely(lchn->state == ECS_INTERDOMAIN) )
     {
@@ -1106,7 +1147,7 @@ void evtchn_destroy(struct domain *d)
     /* Close all existing event channels. */
     for ( i = 0; port_is_valid(d, i); i++ )
     {
-        evtchn_from_port(d, i)->consumer_is_xen = 0;
+        evtchn_from_port(d, i)->xen_consumer = 0;
         (void)__evtchn_close(d, i);
     }
 
@@ -1192,7 +1233,7 @@ static void domain_dump_evtchn_info(stru
             printk(" v=%d", chn->u.virq);
             break;
         }
-        printk(" x=%d\n", chn->consumer_is_xen);
+        printk(" x=%d\n", chn->xen_consumer);
     }
 
     spin_unlock(&d->event_lock);
diff -r 43dc614d543c -r 96ba0cb6e255 xen/include/xen/event.h
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -51,8 +51,11 @@ int evtchn_unmask(unsigned int port);
 void evtchn_move_pirqs(struct vcpu *v);
 
 /* Allocate/free a Xen-attached event channel port. */
+typedef void (*xen_event_channel_notification_t)(
+    struct vcpu *v, unsigned int port);
 int alloc_unbound_xen_event_channel(
-    struct vcpu *local_vcpu, domid_t remote_domid);
+    struct vcpu *local_vcpu, domid_t remote_domid,
+    xen_event_channel_notification_t notification_fn);
 void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
diff -r 43dc614d543c -r 96ba0cb6e255 xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -47,7 +47,7 @@ struct evtchn
 #define ECS_VIRQ         5 /* Channel is bound to a virtual IRQ line.        */
 #define ECS_IPI          6 /* Channel is bound to a virtual IPI line.        */
     u8  state;             /* ECS_* */
-    u8  consumer_is_xen;   /* Consumed by Xen or by guest? */
+    u8  xen_consumer;      /* Consumer in Xen, if any? (0 = send to guest) */
     u16 notify_vcpu_id;    /* VCPU for local delivery notification */
     union {
         struct {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVem-0000Mp-El; Tue, 29 Nov 2011 21:56:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVek-0000LE-1e
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:56:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322603723!6141461!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTU3Nzg=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21295 invoked from network); 29 Nov 2011 21:55:23 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 21:55:23 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8A788458080;
	Tue, 29 Nov 2011 13:55:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ia02FqF7YXTgqJlPYK/4PswL0KmT0R0JyOpB9OteZvD/
	uoqJt/Pv+UXFNvB/Xh//MFABKf/DLevINcBTORutc9vwr+zt5aiefF5lN5Lhi4yH
	3MAVTOT6pd4XZRvwf7HGrZde1anxaGRgof2TLzccH9Z/rcykqRd21BA3Luhohxo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=/wPKf06Dhe0D1c5IFZQJ+77UgN8=; b=W/V1PNTkdO7
	XMZDqLGu+QUHOTJ/SFW11vlbOWN9vXR2m2KaqN2sJ47OxL61aIVQe0hROkB0W1Gr
	e4nb+uaxoOov2ZWFzhdaJ5t9OlvK4hGHM3FPHjh/RV9S5GoLYTZgEO5o6jFRTHxx
	DyG7SZSCUFLLq8DwMuNHtXDpWbuhT8Kg=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id 82DD645807B; 
	Tue, 29 Nov 2011 13:55:21 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 43dc614d543cdf84189d1ddf5b45520aab124e4c
Message-Id: <43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603709@xdev.gridcentric.ca>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:11 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c          |   20 ++-
 xen/arch/x86/mm/mem_event.c     |  205 ++++++++++++++++++++++++++++++---------
 xen/arch/x86/mm/mem_sharing.c   |   27 +++-
 xen/arch/x86/mm/p2m.c           |  104 ++++++++++---------
 xen/common/memory.c             |    7 +-
 xen/include/asm-x86/mem_event.h |   16 ++-
 xen/include/asm-x86/p2m.h       |    6 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |    5 +-
 9 files changed, 268 insertions(+), 124 deletions(-)


The memevent code currently has a mechanism for reserving space in the ring
before putting an event, but each caller must individually ensure that the
vCPUs are correctly paused if no space is available.

This fixes that issue by reversing the semantics: we ensure that enough space
is always left for one event per vCPU in the ring.  If, after putting the
current request, this constraint will be violated by the current vCPU
when putting putting another request in the ring, we pause the vCPU.

For mem events caused by foreign vcpus, we simply drop the event if the
space constraint will be violated. Foreign vcpus are expected to retry
mapping operations (and thus the associated paging populate mem events
will be re issued).

Finally, guests can cause an unbound number of paging drop events via the
balloon -> decrease_reservation hypercall. Thus, notify the hypercall
there is no more space in the ring so a continuation is scheduled.

With all these mechanisms, no guest events are lost and there is no need
for wait-queues. Our testing includes 1. ballooning down 512 MiBs; 2. a
mem event mode in which every page access in a four-vCPU guest results in
an event, with no vCPU pausing, and the four vCPUs touching all RAM. No
guest events were lost in either case, and qemu-dm had no mapping problems.

Additionally, we ensure that no events are lost by Xen as a consumer if multiple
responses land on the ring for a single domctl. While the current domctl-based
notifications to Xen disallow batching, this is required for later patches.

Finally, mark_and_pause_vcpus was misleading, beacause it wasn't strictly
pausing the vcpu's, rather sending them to sleep. Change to actual
vcpu_pause, which protects wakeups via an atomic count. This is useful when
an event pauses a vcpu and the vcpu gets mark and paused due to ring congestion.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8d67f4d5bafa -r 43dc614d543c xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4108,7 +4108,6 @@ static int hvm_memory_event_traps(long p
     struct vcpu* v = current;
     struct domain *d = v->domain;
     mem_event_request_t req;
-    int rc;
 
     if ( !(p & HVMPME_MODE_MASK) ) 
         return 0;
@@ -4116,10 +4115,6 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_access);
-    if ( rc )
-        return rc;
-    
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = reason;
@@ -4139,7 +4134,20 @@ static int hvm_memory_event_traps(long p
         req.gla_valid = 1;
     }
     
-    mem_event_put_request(d, &d->mem_access, &req);
+    if ( mem_event_put_request(d, &d->mem_access, &req) == -ENOSYS )
+    {
+        /* rc == -ENOSYS
+         * If there was no ring to send the event, then simply unpause the
+         * vcpu (if we had previously paused it). It will retry the 
+         * instruction (with the exception "handled") and go on */
+        if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) 
+            vcpu_unpause(v);
+        /* rc == -EBUSY
+         * If the ring is full, the vcpu has been marked and paused,
+         *  and the exception has been communicated to the consumer.
+         * Once there is room in the ring, the vcpu will be woken up 
+         * and will retry. */
+    }
     
     return 1;
 }
diff -r 8d67f4d5bafa -r 43dc614d543c xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -91,6 +91,9 @@ static int mem_event_enable(struct domai
     put_gfn(dom_mem_event, ring_gfn);
     put_gfn(dom_mem_event, shared_gfn); 
 
+    /* Set the number of currently blocked vCPUs to 0. */
+    med->blocked = 0;
+
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
                                          current->domain->domain_id);
@@ -108,7 +111,7 @@ static int mem_event_enable(struct domai
     mem_event_ring_lock_init(med);
 
     /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, med);
 
     return 0;
 
@@ -122,8 +125,57 @@ static int mem_event_enable(struct domai
     return rc;
 }
 
-static int mem_event_disable(struct mem_event_domain *med)
+static void __mem_event_unpause_vcpus(struct domain *d, 
+                                        struct mem_event_domain *med, int free)
 {
+    struct vcpu *v;
+    int i, j, k;
+    int online = d->max_vcpus;
+
+    /*
+     * We ensure that we only have vCPUs online if there are enough free slots
+     * for their memory events to be processed.  This will ensure that no
+     * memory events are lost (due to the fact that certain types of events
+     * cannot be replayed, we need to ensure that there is space in the ring
+     * for when they are hit). 
+     * See large comment above in mem_event_put_request().
+     */
+    for_each_vcpu ( d, v )
+        if ( test_bit(_VPF_mem_event, &v->pause_flags) )
+            online--;
+
+    /* We remember which vcpu last woke up to avoid scanning always linearly
+     * from zero and starving higher-numbered vcpus under high load */
+    if ( d->vcpu )
+    {
+        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
+        {
+            k = i % d->max_vcpus;
+            v = d->vcpu[k];
+            if ( !v ) continue;
+
+            if ( !(med->blocked) || online >= free )
+                break;
+            if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                online++;
+                med->blocked--;
+                med->last_vcpu_wake_up = k;
+            }
+        }
+    }
+}
+
+static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
+{
+    if ( !med )
+        return 0;
+
+    /* Wake up everybody, regardless */
+    med->last_vcpu_wake_up = 0;
+    __mem_event_unpause_vcpus(d, med, d->max_vcpus);
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -133,31 +185,95 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static inline int mem_event_ring_free(struct domain *d, struct mem_event_domain *med)
 {
+    int free_requests;
+
+    free_requests = RING_FREE_REQUESTS(&med->front_ring);
+    if ( unlikely(free_requests < d->max_vcpus) )
+    {
+        /* This may happen during normal operation (hopefully not often). */
+        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d: %d\n",
+                               d->domain_id, free_requests);
+    }
+
+    return free_requests;
+}
+
+/* Return values
+ * zero: success
+ * -ENOSYS: no ring
+ * -EAGAIN: ring is full and the event has not been transmitted.
+ *          Only foreign vcpu's get EAGAIN
+ * -EBUSY: guest vcpu has been paused due to ring congestion
+ */ 
+int mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+{
+    int ret = 0;
+    int foreign = (d != current->domain);
     mem_event_front_ring_t *front_ring;
     RING_IDX req_prod;
 
+    if ( mem_event_check_ring(d, med) )
+        return -ENOSYS;
+
     mem_event_ring_lock(med);
 
-    front_ring = &med->front_ring;
-    req_prod = front_ring->req_prod_pvt;
+    if ( foreign &&
+        (mem_event_ring_free(d, med) <= (d->max_vcpus - med->blocked)) )
+    {
+        /* This is an event caused by a foreign mapper. Putting the event
+         * in the ring could preclude a guest vcpu from putting an event.
+         * The foreign mapper has to retry. */
+        gdprintk(XENLOG_DEBUG, "Foreign-caused (%u) event will not be put"
+                 " in ring with %d slots %d sleepers", current->domain->domain_id, 
+                 mem_event_ring_free(d, med), med->blocked);
+        mem_event_ring_unlock(med);
+        return -EAGAIN;
+    }
 
-    /* Copy request */
-    memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
-    req_prod++;
+    if ( mem_event_ring_free(d, med) == 0 )
+    {
+        /* This should *never* happen */
+        gdprintk(XENLOG_WARNING, "possible lost mem_event for domain %d\n",
+                                 d->domain_id);
+        ret = -EBUSY;
+    }
+    else
+    {
+        front_ring = &med->front_ring;
+        req_prod = front_ring->req_prod_pvt;
 
-    /* Update ring */
-    med->req_producers--;
-    front_ring->req_prod_pvt = req_prod;
-    RING_PUSH_REQUESTS(front_ring);
+        /* Copy request */
+        memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
+        req_prod++;
+
+        /* Update ring */
+        front_ring->req_prod_pvt = req_prod;
+        RING_PUSH_REQUESTS(front_ring);
+    }
+
+    /*
+     * We ensure that each vcpu can put at least *one* event -- because some
+     * events are not repeatable, such as dropping a page.  This will ensure no
+     * vCPU is left with an event that they must place on the ring, but cannot.
+     * They will be paused after the event is placed.
+     * See large comment below in mem_event_unpause_vcpus().
+     */
+    if ( !foreign && mem_event_ring_free(d, med) < d->max_vcpus )
+    {
+        mem_event_mark_and_pause(current, med);
+        ret = -EBUSY;
+    }
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return ret;
 }
 
-void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med, mem_event_response_t *rsp)
 {
     mem_event_front_ring_t *front_ring;
     RING_IDX rsp_cons;
@@ -167,6 +283,12 @@ void mem_event_get_response(struct mem_e
     front_ring = &med->front_ring;
     rsp_cons = front_ring->rsp_cons;
 
+    if ( !RING_HAS_UNCONSUMED_RESPONSES(front_ring) )
+    {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     /* Copy response */
     memcpy(rsp, RING_GET_RESPONSE(front_ring, rsp_cons), sizeof(*rsp));
     rsp_cons++;
@@ -176,54 +298,35 @@ void mem_event_get_response(struct mem_e
     front_ring->sring->rsp_event = rsp_cons + 1;
 
     mem_event_ring_unlock(med);
+
+    return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *v;
+    mem_event_ring_lock(med);
 
-    for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
-            vcpu_wake(v);
+    if ( med->blocked )
+        __mem_event_unpause_vcpus(d, med, mem_event_ring_free(d, med));
+
+    mem_event_ring_unlock(med);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
-    vcpu_sleep_nosync(v);
-}
-
-void mem_event_put_req_producers(struct mem_event_domain *med)
-{
-    mem_event_ring_lock(med);
-    med->req_producers--;
-    mem_event_ring_unlock(med);
+    if ( !test_and_set_bit(_VPF_mem_event, &v->pause_flags) )
+    {
+        vcpu_pause_nosync(v);
+        med->blocked++;
+    }
 }
 
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
-    int free_requests;
-    int ring_full = 1;
+    if ( !med->ring_page )
+        return -ENOSYS;
 
-    if ( !med->ring_page )
-        return -1;
-
-    mem_event_ring_lock(med);
-
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
-    {
-        med->req_producers++;
-        ring_full = 0;
-    }
-
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
-
-    mem_event_ring_unlock(med);
-
-    return ring_full;
+    return 0;
 }
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
@@ -294,7 +397,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(med);
+                rc = mem_event_disable(d, med);
         }
         break;
 
@@ -333,7 +436,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(&d->mem_access);
+                rc = mem_event_disable(d, &d->mem_access);
         }
         break;
 
diff -r 8d67f4d5bafa -r 43dc614d543c xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -281,12 +281,19 @@ static struct page_info* mem_sharing_all
     vcpu_pause_nosync(v);
     req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
 
-    if(mem_event_check_ring(d, &d->mem_share)) return page;
-
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
-    mem_event_put_request(d, &d->mem_share, &req);
+
+    /* If there is no ring, and we're out of memory, then
+     * there is no way out. */
+    if ( mem_event_put_request(d, &d->mem_share, &req) == -ENOSYS )
+    {
+        gdprintk(XENLOG_ERR, 
+                 "Failed alloc on unshare path for %hu and no ring "
+                 "to upcall\n", d->domain_id);
+        domain_crash(d);
+    }
 
     return page;
 }
@@ -300,12 +307,16 @@ int mem_sharing_sharing_resume(struct do
 {
     mem_event_response_t rsp;
 
-    /* Get request off the ring */
-    mem_event_get_response(&d->mem_share, &rsp);
+    /* Get all requests off the ring */
+    while ( mem_event_get_response(d, &d->mem_share, &rsp) )
+    {
+        /* Unpause domain/vcpu */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    }
 
-    /* Unpause domain/vcpu */
-    if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    /* Unpause any domains that were paused because the ring was full */
+    mem_event_unpause_vcpus(d, &d->mem_paging);
 
     return 0;
 }
diff -r 8d67f4d5bafa -r 43dc614d543c xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -871,13 +871,15 @@ int p2m_mem_paging_evict(struct domain *
  * p2m_mem_paging_drop_page() will notify the pager that a paged-out gfn was
  * released by the guest. The pager is supposed to drop its reference of the
  * gfn.
+ * Returns zero on success, EAGAIN for foreign mappers and EBUSY for guest 
+ * vcpus if the ring is congested.
  */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
     mem_event_request_t req;
 
-    /* Check that there's space on the ring for this request */
+    /* Check that there's a paging listener who cares about this */
     if ( mem_event_check_ring(d, &d->mem_paging) == 0)
     {
         /* Send release notification to pager */
@@ -886,8 +888,11 @@ void p2m_mem_paging_drop_page(struct dom
         req.gfn = gfn;
         req.vcpu_id = v->vcpu_id;
 
-        mem_event_put_request(d, &d->mem_paging, &req);
+        /* rc cannot be ENOSYS, as we checked before */
+        return mem_event_put_request(d, &d->mem_paging, &req);
     }
+
+    return 0;
 }
 
 /**
@@ -920,9 +925,14 @@ void p2m_mem_paging_populate(struct doma
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
-    /* Check that there's space on the ring for this request */
+    /* We're paging. There should be a ring */
     if ( mem_event_check_ring(d, &d->mem_paging) )
+    {
+        gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
+                    "in place\n", d->domain_id, gfn);
+        domain_crash(d);
         return;
+    }
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_PAGING;
@@ -951,7 +961,6 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_paging);
         return;
     }
 
@@ -960,7 +969,10 @@ void p2m_mem_paging_populate(struct doma
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_paging, &req);
+    (void)mem_event_put_request(d, &d->mem_paging, &req);
+    /* If the ring is full, foreign mappers will retry, and guest
+     * vcpus remain paused. Guest vcpu will wake up and retry once
+     * the consumer has made some space in the ring. */
 }
 
 /**
@@ -1084,33 +1096,34 @@ void p2m_mem_paging_resume(struct domain
     p2m_access_t a;
     mfn_t mfn;
 
-    /* Pull the response off the ring */
-    mem_event_get_response(&d->mem_paging, &rsp);
+    /* Pull all responses off the ring */
+    while( mem_event_get_response(d, &d->mem_paging, &rsp) )
+    {
+        /* Fix p2m entry if the page was not dropped */
+        if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
+        {
+            p2m_lock(p2m);
+            mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
+            /* Allow only pages which were prepared properly, or pages which
+             * were nominated but not evicted */
+            if ( mfn_valid(mfn) && 
+                 (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
+            {
+                set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
+                                paging_mode_log_dirty(d) ? p2m_ram_logdirty : 
+                                p2m_ram_rw, a);
+                set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
+            }
+            p2m_unlock(p2m);
+        }
 
-    /* Fix p2m entry if the page was not dropped */
-    if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
-    {
-        p2m_lock(p2m);
-        mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
-        /* Allow only pages which were prepared properly, or pages which
-         * were nominated but not evicted */
-        if ( mfn_valid(mfn) && 
-             (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
-        {
-            set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
-                            paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, 
-                            a);
-            set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
-        }
-        p2m_unlock(p2m);
+        /* Unpause domain */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause domain */
-    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
-
     /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, &d->mem_paging);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1121,7 +1134,6 @@ void p2m_mem_access_check(unsigned long 
     unsigned long gfn = gpa >> PAGE_SHIFT;
     struct domain *d = v->domain;    
     struct p2m_domain* p2m = p2m_get_hostp2m(d);
-    int res;
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
@@ -1139,17 +1151,14 @@ void p2m_mem_access_check(unsigned long 
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_access);
-    if ( res < 0 ) 
+    if ( mem_event_check_ring(d, &d->mem_access) == -ENOSYS ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
         {
-            printk(XENLOG_INFO 
-                   "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
-                   v->vcpu_id, d->domain_id);
-
-            mem_event_mark_and_pause(v);
+            gdprintk(XENLOG_INFO, "Memory access permissions failure, no mem_event "
+                     "listener VCPU %d, dom %d\n", v->vcpu_id, d->domain_id);
+            domain_crash(v->domain);
         }
         else
         {
@@ -1161,8 +1170,6 @@ void p2m_mem_access_check(unsigned long 
 
         return;
     }
-    else if ( res > 0 )
-        return;  /* No space in buffer; VCPU paused */
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
@@ -1183,9 +1190,8 @@ void p2m_mem_access_check(unsigned long 
     
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_access, &req);
-
-    /* VCPU paused, mem event request sent */
+    (void)mem_event_put_request(d, &d->mem_access, &req);
+    /* VCPU paused */
 }
 
 void p2m_mem_access_resume(struct p2m_domain *p2m)
@@ -1193,15 +1199,17 @@ void p2m_mem_access_resume(struct p2m_do
     struct domain *d = p2m->domain;
     mem_event_response_t rsp;
 
-    mem_event_get_response(&d->mem_access, &rsp);
-
-    /* Unpause domain */
-    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    /* Pull all responses off the ring */
+    while( mem_event_get_response(d, &d->mem_access, &rsp) )
+    {
+        /* Unpause domain */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    }
 
     /* Unpause any domains that were paused because the ring was full or no listener 
      * was available */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, &d->mem_access);
 }
 
 
diff -r 8d67f4d5bafa -r 43dc614d543c xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -165,10 +165,13 @@ int guest_remove_page(struct domain *d, 
     mfn = mfn_x(get_gfn(d, gmfn, &p2mt)); 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
+        int rc; 
         guest_physmap_remove_page(d, gmfn, mfn, 0);
-        p2m_mem_paging_drop_page(d, gmfn);
+        rc = p2m_mem_paging_drop_page(d, gmfn);
         put_gfn(d, gmfn);
-        return 1;
+        /* drop_page returns zero on success, we return 1 on success.
+         * drop_page returns negative on error, never returns 1. */
+        return rc ? rc : 1;
     }
 #else
     mfn = gmfn_to_mfn(d, gmfn);
diff -r 8d67f4d5bafa -r 43dc614d543c xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -25,12 +25,18 @@
 #define __MEM_EVENT_H__
 
 /* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med);
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
-void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med);
+
+/* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is 
+ * a ring or no space. FOr success or -EBUSY. the vCPU is left blocked to 
+ * ensure that the ring does not lose events.  In general, put_request should 
+ * not fail, as it attempts to ensure that each vCPU can put at least one req. */
+int mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                            mem_event_request_t *req);
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
+                            mem_event_response_t *rsp);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r 8d67f4d5bafa -r 43dc614d543c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -475,7 +475,7 @@ int p2m_mem_paging_nominate(struct domai
 /* Evict a frame */
 int p2m_mem_paging_evict(struct domain *d, unsigned long gfn);
 /* Tell xenpaging to drop a paged out frame */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn);
+int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn);
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
@@ -483,8 +483,8 @@ int p2m_mem_paging_prep(struct domain *d
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
-static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
-{ }
+static inline int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+{ return 0; }
 static inline void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 { }
 #endif
diff -r 8d67f4d5bafa -r 43dc614d543c xen/include/xen/mm.h
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -318,6 +318,8 @@ page_list_splice(struct page_list_head *
 
 void scrub_one_page(struct page_info *);
 
+/* Returns 1 on success, 0 on error, negative if the ring
+ * for event propagation is full in the presence of paging */
 int guest_remove_page(struct domain *d, unsigned long gmfn);
 
 #define RAM_TYPE_CONVENTIONAL 0x00000001
diff -r 8d67f4d5bafa -r 43dc614d543c xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -183,13 +183,16 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
     void *ring_page;
     /* front-end ring */
     mem_event_front_ring_t front_ring;
+    /* the number of vCPUs blocked */
+    unsigned int blocked;
+    /* The last vcpu woken up */
+    unsigned int last_vcpu_wake_up;
     /* event channel port (vcpu0 only) */
     int xen_port;
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVem-0000Mp-El; Tue, 29 Nov 2011 21:56:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVek-0000LE-1e
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:56:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322603723!6141461!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTU3Nzg=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21295 invoked from network); 29 Nov 2011 21:55:23 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 21:55:23 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8A788458080;
	Tue, 29 Nov 2011 13:55:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ia02FqF7YXTgqJlPYK/4PswL0KmT0R0JyOpB9OteZvD/
	uoqJt/Pv+UXFNvB/Xh//MFABKf/DLevINcBTORutc9vwr+zt5aiefF5lN5Lhi4yH
	3MAVTOT6pd4XZRvwf7HGrZde1anxaGRgof2TLzccH9Z/rcykqRd21BA3Luhohxo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=/wPKf06Dhe0D1c5IFZQJ+77UgN8=; b=W/V1PNTkdO7
	XMZDqLGu+QUHOTJ/SFW11vlbOWN9vXR2m2KaqN2sJ47OxL61aIVQe0hROkB0W1Gr
	e4nb+uaxoOov2ZWFzhdaJ5t9OlvK4hGHM3FPHjh/RV9S5GoLYTZgEO5o6jFRTHxx
	DyG7SZSCUFLLq8DwMuNHtXDpWbuhT8Kg=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id 82DD645807B; 
	Tue, 29 Nov 2011 13:55:21 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 43dc614d543cdf84189d1ddf5b45520aab124e4c
Message-Id: <43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603709@xdev.gridcentric.ca>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:11 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c          |   20 ++-
 xen/arch/x86/mm/mem_event.c     |  205 ++++++++++++++++++++++++++++++---------
 xen/arch/x86/mm/mem_sharing.c   |   27 +++-
 xen/arch/x86/mm/p2m.c           |  104 ++++++++++---------
 xen/common/memory.c             |    7 +-
 xen/include/asm-x86/mem_event.h |   16 ++-
 xen/include/asm-x86/p2m.h       |    6 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |    5 +-
 9 files changed, 268 insertions(+), 124 deletions(-)


The memevent code currently has a mechanism for reserving space in the ring
before putting an event, but each caller must individually ensure that the
vCPUs are correctly paused if no space is available.

This fixes that issue by reversing the semantics: we ensure that enough space
is always left for one event per vCPU in the ring.  If, after putting the
current request, this constraint will be violated by the current vCPU
when putting putting another request in the ring, we pause the vCPU.

For mem events caused by foreign vcpus, we simply drop the event if the
space constraint will be violated. Foreign vcpus are expected to retry
mapping operations (and thus the associated paging populate mem events
will be re issued).

Finally, guests can cause an unbound number of paging drop events via the
balloon -> decrease_reservation hypercall. Thus, notify the hypercall
there is no more space in the ring so a continuation is scheduled.

With all these mechanisms, no guest events are lost and there is no need
for wait-queues. Our testing includes 1. ballooning down 512 MiBs; 2. a
mem event mode in which every page access in a four-vCPU guest results in
an event, with no vCPU pausing, and the four vCPUs touching all RAM. No
guest events were lost in either case, and qemu-dm had no mapping problems.

Additionally, we ensure that no events are lost by Xen as a consumer if multiple
responses land on the ring for a single domctl. While the current domctl-based
notifications to Xen disallow batching, this is required for later patches.

Finally, mark_and_pause_vcpus was misleading, beacause it wasn't strictly
pausing the vcpu's, rather sending them to sleep. Change to actual
vcpu_pause, which protects wakeups via an atomic count. This is useful when
an event pauses a vcpu and the vcpu gets mark and paused due to ring congestion.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 8d67f4d5bafa -r 43dc614d543c xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4108,7 +4108,6 @@ static int hvm_memory_event_traps(long p
     struct vcpu* v = current;
     struct domain *d = v->domain;
     mem_event_request_t req;
-    int rc;
 
     if ( !(p & HVMPME_MODE_MASK) ) 
         return 0;
@@ -4116,10 +4115,6 @@ static int hvm_memory_event_traps(long p
     if ( (p & HVMPME_onchangeonly) && (value == old) )
         return 1;
     
-    rc = mem_event_check_ring(d, &d->mem_access);
-    if ( rc )
-        return rc;
-    
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = reason;
@@ -4139,7 +4134,20 @@ static int hvm_memory_event_traps(long p
         req.gla_valid = 1;
     }
     
-    mem_event_put_request(d, &d->mem_access, &req);
+    if ( mem_event_put_request(d, &d->mem_access, &req) == -ENOSYS )
+    {
+        /* rc == -ENOSYS
+         * If there was no ring to send the event, then simply unpause the
+         * vcpu (if we had previously paused it). It will retry the 
+         * instruction (with the exception "handled") and go on */
+        if ( req.flags & MEM_EVENT_FLAG_VCPU_PAUSED ) 
+            vcpu_unpause(v);
+        /* rc == -EBUSY
+         * If the ring is full, the vcpu has been marked and paused,
+         *  and the exception has been communicated to the consumer.
+         * Once there is room in the ring, the vcpu will be woken up 
+         * and will retry. */
+    }
     
     return 1;
 }
diff -r 8d67f4d5bafa -r 43dc614d543c xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -91,6 +91,9 @@ static int mem_event_enable(struct domai
     put_gfn(dom_mem_event, ring_gfn);
     put_gfn(dom_mem_event, shared_gfn); 
 
+    /* Set the number of currently blocked vCPUs to 0. */
+    med->blocked = 0;
+
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
                                          current->domain->domain_id);
@@ -108,7 +111,7 @@ static int mem_event_enable(struct domai
     mem_event_ring_lock_init(med);
 
     /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, med);
 
     return 0;
 
@@ -122,8 +125,57 @@ static int mem_event_enable(struct domai
     return rc;
 }
 
-static int mem_event_disable(struct mem_event_domain *med)
+static void __mem_event_unpause_vcpus(struct domain *d, 
+                                        struct mem_event_domain *med, int free)
 {
+    struct vcpu *v;
+    int i, j, k;
+    int online = d->max_vcpus;
+
+    /*
+     * We ensure that we only have vCPUs online if there are enough free slots
+     * for their memory events to be processed.  This will ensure that no
+     * memory events are lost (due to the fact that certain types of events
+     * cannot be replayed, we need to ensure that there is space in the ring
+     * for when they are hit). 
+     * See large comment above in mem_event_put_request().
+     */
+    for_each_vcpu ( d, v )
+        if ( test_bit(_VPF_mem_event, &v->pause_flags) )
+            online--;
+
+    /* We remember which vcpu last woke up to avoid scanning always linearly
+     * from zero and starving higher-numbered vcpus under high load */
+    if ( d->vcpu )
+    {
+        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
+        {
+            k = i % d->max_vcpus;
+            v = d->vcpu[k];
+            if ( !v ) continue;
+
+            if ( !(med->blocked) || online >= free )
+                break;
+            if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                online++;
+                med->blocked--;
+                med->last_vcpu_wake_up = k;
+            }
+        }
+    }
+}
+
+static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
+{
+    if ( !med )
+        return 0;
+
+    /* Wake up everybody, regardless */
+    med->last_vcpu_wake_up = 0;
+    __mem_event_unpause_vcpus(d, med, d->max_vcpus);
+
     unmap_domain_page(med->ring_page);
     med->ring_page = NULL;
 
@@ -133,31 +185,95 @@ static int mem_event_disable(struct mem_
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static inline int mem_event_ring_free(struct domain *d, struct mem_event_domain *med)
 {
+    int free_requests;
+
+    free_requests = RING_FREE_REQUESTS(&med->front_ring);
+    if ( unlikely(free_requests < d->max_vcpus) )
+    {
+        /* This may happen during normal operation (hopefully not often). */
+        gdprintk(XENLOG_INFO, "mem_event request slots for domain %d: %d\n",
+                               d->domain_id, free_requests);
+    }
+
+    return free_requests;
+}
+
+/* Return values
+ * zero: success
+ * -ENOSYS: no ring
+ * -EAGAIN: ring is full and the event has not been transmitted.
+ *          Only foreign vcpu's get EAGAIN
+ * -EBUSY: guest vcpu has been paused due to ring congestion
+ */ 
+int mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+{
+    int ret = 0;
+    int foreign = (d != current->domain);
     mem_event_front_ring_t *front_ring;
     RING_IDX req_prod;
 
+    if ( mem_event_check_ring(d, med) )
+        return -ENOSYS;
+
     mem_event_ring_lock(med);
 
-    front_ring = &med->front_ring;
-    req_prod = front_ring->req_prod_pvt;
+    if ( foreign &&
+        (mem_event_ring_free(d, med) <= (d->max_vcpus - med->blocked)) )
+    {
+        /* This is an event caused by a foreign mapper. Putting the event
+         * in the ring could preclude a guest vcpu from putting an event.
+         * The foreign mapper has to retry. */
+        gdprintk(XENLOG_DEBUG, "Foreign-caused (%u) event will not be put"
+                 " in ring with %d slots %d sleepers", current->domain->domain_id, 
+                 mem_event_ring_free(d, med), med->blocked);
+        mem_event_ring_unlock(med);
+        return -EAGAIN;
+    }
 
-    /* Copy request */
-    memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
-    req_prod++;
+    if ( mem_event_ring_free(d, med) == 0 )
+    {
+        /* This should *never* happen */
+        gdprintk(XENLOG_WARNING, "possible lost mem_event for domain %d\n",
+                                 d->domain_id);
+        ret = -EBUSY;
+    }
+    else
+    {
+        front_ring = &med->front_ring;
+        req_prod = front_ring->req_prod_pvt;
 
-    /* Update ring */
-    med->req_producers--;
-    front_ring->req_prod_pvt = req_prod;
-    RING_PUSH_REQUESTS(front_ring);
+        /* Copy request */
+        memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
+        req_prod++;
+
+        /* Update ring */
+        front_ring->req_prod_pvt = req_prod;
+        RING_PUSH_REQUESTS(front_ring);
+    }
+
+    /*
+     * We ensure that each vcpu can put at least *one* event -- because some
+     * events are not repeatable, such as dropping a page.  This will ensure no
+     * vCPU is left with an event that they must place on the ring, but cannot.
+     * They will be paused after the event is placed.
+     * See large comment below in mem_event_unpause_vcpus().
+     */
+    if ( !foreign && mem_event_ring_free(d, med) < d->max_vcpus )
+    {
+        mem_event_mark_and_pause(current, med);
+        ret = -EBUSY;
+    }
 
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
+
+    return ret;
 }
 
-void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med, mem_event_response_t *rsp)
 {
     mem_event_front_ring_t *front_ring;
     RING_IDX rsp_cons;
@@ -167,6 +283,12 @@ void mem_event_get_response(struct mem_e
     front_ring = &med->front_ring;
     rsp_cons = front_ring->rsp_cons;
 
+    if ( !RING_HAS_UNCONSUMED_RESPONSES(front_ring) )
+    {
+        mem_event_ring_unlock(med);
+        return 0;
+    }
+
     /* Copy response */
     memcpy(rsp, RING_GET_RESPONSE(front_ring, rsp_cons), sizeof(*rsp));
     rsp_cons++;
@@ -176,54 +298,35 @@ void mem_event_get_response(struct mem_e
     front_ring->sring->rsp_event = rsp_cons + 1;
 
     mem_event_ring_unlock(med);
+
+    return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *v;
+    mem_event_ring_lock(med);
 
-    for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
-            vcpu_wake(v);
+    if ( med->blocked )
+        __mem_event_unpause_vcpus(d, med, mem_event_ring_free(d, med));
+
+    mem_event_ring_unlock(med);
 }
 
-void mem_event_mark_and_pause(struct vcpu *v)
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
 {
-    set_bit(_VPF_mem_event, &v->pause_flags);
-    vcpu_sleep_nosync(v);
-}
-
-void mem_event_put_req_producers(struct mem_event_domain *med)
-{
-    mem_event_ring_lock(med);
-    med->req_producers--;
-    mem_event_ring_unlock(med);
+    if ( !test_and_set_bit(_VPF_mem_event, &v->pause_flags) )
+    {
+        vcpu_pause_nosync(v);
+        med->blocked++;
+    }
 }
 
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
 {
-    struct vcpu *curr = current;
-    int free_requests;
-    int ring_full = 1;
+    if ( !med->ring_page )
+        return -ENOSYS;
 
-    if ( !med->ring_page )
-        return -1;
-
-    mem_event_ring_lock(med);
-
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
-    {
-        med->req_producers++;
-        ring_full = 0;
-    }
-
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
-
-    mem_event_ring_unlock(med);
-
-    return ring_full;
+    return 0;
 }
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
@@ -294,7 +397,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(med);
+                rc = mem_event_disable(d, med);
         }
         break;
 
@@ -333,7 +436,7 @@ int mem_event_domctl(struct domain *d, x
         case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(&d->mem_access);
+                rc = mem_event_disable(d, &d->mem_access);
         }
         break;
 
diff -r 8d67f4d5bafa -r 43dc614d543c xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -281,12 +281,19 @@ static struct page_info* mem_sharing_all
     vcpu_pause_nosync(v);
     req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
 
-    if(mem_event_check_ring(d, &d->mem_share)) return page;
-
     req.gfn = gfn;
     req.p2mt = p2m_ram_shared;
     req.vcpu_id = v->vcpu_id;
-    mem_event_put_request(d, &d->mem_share, &req);
+
+    /* If there is no ring, and we're out of memory, then
+     * there is no way out. */
+    if ( mem_event_put_request(d, &d->mem_share, &req) == -ENOSYS )
+    {
+        gdprintk(XENLOG_ERR, 
+                 "Failed alloc on unshare path for %hu and no ring "
+                 "to upcall\n", d->domain_id);
+        domain_crash(d);
+    }
 
     return page;
 }
@@ -300,12 +307,16 @@ int mem_sharing_sharing_resume(struct do
 {
     mem_event_response_t rsp;
 
-    /* Get request off the ring */
-    mem_event_get_response(&d->mem_share, &rsp);
+    /* Get all requests off the ring */
+    while ( mem_event_get_response(d, &d->mem_share, &rsp) )
+    {
+        /* Unpause domain/vcpu */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    }
 
-    /* Unpause domain/vcpu */
-    if( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    /* Unpause any domains that were paused because the ring was full */
+    mem_event_unpause_vcpus(d, &d->mem_paging);
 
     return 0;
 }
diff -r 8d67f4d5bafa -r 43dc614d543c xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -871,13 +871,15 @@ int p2m_mem_paging_evict(struct domain *
  * p2m_mem_paging_drop_page() will notify the pager that a paged-out gfn was
  * released by the guest. The pager is supposed to drop its reference of the
  * gfn.
+ * Returns zero on success, EAGAIN for foreign mappers and EBUSY for guest 
+ * vcpus if the ring is congested.
  */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
     mem_event_request_t req;
 
-    /* Check that there's space on the ring for this request */
+    /* Check that there's a paging listener who cares about this */
     if ( mem_event_check_ring(d, &d->mem_paging) == 0)
     {
         /* Send release notification to pager */
@@ -886,8 +888,11 @@ void p2m_mem_paging_drop_page(struct dom
         req.gfn = gfn;
         req.vcpu_id = v->vcpu_id;
 
-        mem_event_put_request(d, &d->mem_paging, &req);
+        /* rc cannot be ENOSYS, as we checked before */
+        return mem_event_put_request(d, &d->mem_paging, &req);
     }
+
+    return 0;
 }
 
 /**
@@ -920,9 +925,14 @@ void p2m_mem_paging_populate(struct doma
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
-    /* Check that there's space on the ring for this request */
+    /* We're paging. There should be a ring */
     if ( mem_event_check_ring(d, &d->mem_paging) )
+    {
+        gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
+                    "in place\n", d->domain_id, gfn);
+        domain_crash(d);
         return;
+    }
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_PAGING;
@@ -951,7 +961,6 @@ void p2m_mem_paging_populate(struct doma
     else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
     {
         /* gfn is already on its way back and vcpu is not paused */
-        mem_event_put_req_producers(&d->mem_paging);
         return;
     }
 
@@ -960,7 +969,10 @@ void p2m_mem_paging_populate(struct doma
     req.p2mt = p2mt;
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_paging, &req);
+    (void)mem_event_put_request(d, &d->mem_paging, &req);
+    /* If the ring is full, foreign mappers will retry, and guest
+     * vcpus remain paused. Guest vcpu will wake up and retry once
+     * the consumer has made some space in the ring. */
 }
 
 /**
@@ -1084,33 +1096,34 @@ void p2m_mem_paging_resume(struct domain
     p2m_access_t a;
     mfn_t mfn;
 
-    /* Pull the response off the ring */
-    mem_event_get_response(&d->mem_paging, &rsp);
+    /* Pull all responses off the ring */
+    while( mem_event_get_response(d, &d->mem_paging, &rsp) )
+    {
+        /* Fix p2m entry if the page was not dropped */
+        if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
+        {
+            p2m_lock(p2m);
+            mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
+            /* Allow only pages which were prepared properly, or pages which
+             * were nominated but not evicted */
+            if ( mfn_valid(mfn) && 
+                 (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
+            {
+                set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
+                                paging_mode_log_dirty(d) ? p2m_ram_logdirty : 
+                                p2m_ram_rw, a);
+                set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
+            }
+            p2m_unlock(p2m);
+        }
 
-    /* Fix p2m entry if the page was not dropped */
-    if ( !(rsp.flags & MEM_EVENT_FLAG_DROP_PAGE) )
-    {
-        p2m_lock(p2m);
-        mfn = p2m->get_entry(p2m, rsp.gfn, &p2mt, &a, p2m_query, NULL);
-        /* Allow only pages which were prepared properly, or pages which
-         * were nominated but not evicted */
-        if ( mfn_valid(mfn) && 
-             (p2mt == p2m_ram_paging_in || p2mt == p2m_ram_paging_in_start) )
-        {
-            set_p2m_entry(p2m, rsp.gfn, mfn, PAGE_ORDER_4K, 
-                            paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw, 
-                            a);
-            set_gpfn_from_mfn(mfn_x(mfn), rsp.gfn);
-        }
-        p2m_unlock(p2m);
+        /* Unpause domain */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
     }
 
-    /* Unpause domain */
-    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
-
     /* Unpause any domains that were paused because the ring was full */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, &d->mem_paging);
 }
 
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1121,7 +1134,6 @@ void p2m_mem_access_check(unsigned long 
     unsigned long gfn = gpa >> PAGE_SHIFT;
     struct domain *d = v->domain;    
     struct p2m_domain* p2m = p2m_get_hostp2m(d);
-    int res;
     mfn_t mfn;
     p2m_type_t p2mt;
     p2m_access_t p2ma;
@@ -1139,17 +1151,14 @@ void p2m_mem_access_check(unsigned long 
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
-    res = mem_event_check_ring(d, &d->mem_access);
-    if ( res < 0 ) 
+    if ( mem_event_check_ring(d, &d->mem_access) == -ENOSYS ) 
     {
         /* No listener */
         if ( p2m->access_required ) 
         {
-            printk(XENLOG_INFO 
-                   "Memory access permissions failure, no mem_event listener: pausing VCPU %d, dom %d\n",
-                   v->vcpu_id, d->domain_id);
-
-            mem_event_mark_and_pause(v);
+            gdprintk(XENLOG_INFO, "Memory access permissions failure, no mem_event "
+                     "listener VCPU %d, dom %d\n", v->vcpu_id, d->domain_id);
+            domain_crash(v->domain);
         }
         else
         {
@@ -1161,8 +1170,6 @@ void p2m_mem_access_check(unsigned long 
 
         return;
     }
-    else if ( res > 0 )
-        return;  /* No space in buffer; VCPU paused */
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
@@ -1183,9 +1190,8 @@ void p2m_mem_access_check(unsigned long 
     
     req.vcpu_id = v->vcpu_id;
 
-    mem_event_put_request(d, &d->mem_access, &req);
-
-    /* VCPU paused, mem event request sent */
+    (void)mem_event_put_request(d, &d->mem_access, &req);
+    /* VCPU paused */
 }
 
 void p2m_mem_access_resume(struct p2m_domain *p2m)
@@ -1193,15 +1199,17 @@ void p2m_mem_access_resume(struct p2m_do
     struct domain *d = p2m->domain;
     mem_event_response_t rsp;
 
-    mem_event_get_response(&d->mem_access, &rsp);
-
-    /* Unpause domain */
-    if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
-        vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    /* Pull all responses off the ring */
+    while( mem_event_get_response(d, &d->mem_access, &rsp) )
+    {
+        /* Unpause domain */
+        if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
+            vcpu_unpause(d->vcpu[rsp.vcpu_id]);
+    }
 
     /* Unpause any domains that were paused because the ring was full or no listener 
      * was available */
-    mem_event_unpause_vcpus(d);
+    mem_event_unpause_vcpus(d, &d->mem_access);
 }
 
 
diff -r 8d67f4d5bafa -r 43dc614d543c xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -165,10 +165,13 @@ int guest_remove_page(struct domain *d, 
     mfn = mfn_x(get_gfn(d, gmfn, &p2mt)); 
     if ( unlikely(p2m_is_paging(p2mt)) )
     {
+        int rc; 
         guest_physmap_remove_page(d, gmfn, mfn, 0);
-        p2m_mem_paging_drop_page(d, gmfn);
+        rc = p2m_mem_paging_drop_page(d, gmfn);
         put_gfn(d, gmfn);
-        return 1;
+        /* drop_page returns zero on success, we return 1 on success.
+         * drop_page returns negative on error, never returns 1. */
+        return rc ? rc : 1;
     }
 #else
     mfn = gmfn_to_mfn(d, gmfn);
diff -r 8d67f4d5bafa -r 43dc614d543c xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -25,12 +25,18 @@
 #define __MEM_EVENT_H__
 
 /* Pauses VCPU while marking pause flag for mem event */
-void mem_event_mark_and_pause(struct vcpu *v);
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med);
 int mem_event_check_ring(struct domain *d, struct mem_event_domain *med);
-void mem_event_put_req_producers(struct mem_event_domain *med);
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req);
-void mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp);
-void mem_event_unpause_vcpus(struct domain *d);
+void mem_event_unpause_vcpus(struct domain *d, struct mem_event_domain *med);
+
+/* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is 
+ * a ring or no space. FOr success or -EBUSY. the vCPU is left blocked to 
+ * ensure that the ring does not lose events.  In general, put_request should 
+ * not fail, as it attempts to ensure that each vCPU can put at least one req. */
+int mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                            mem_event_request_t *req);
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
+                            mem_event_response_t *rsp);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff -r 8d67f4d5bafa -r 43dc614d543c xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -475,7 +475,7 @@ int p2m_mem_paging_nominate(struct domai
 /* Evict a frame */
 int p2m_mem_paging_evict(struct domain *d, unsigned long gfn);
 /* Tell xenpaging to drop a paged out frame */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn);
+int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn);
 /* Start populating a paged out frame */
 void p2m_mem_paging_populate(struct domain *d, unsigned long gfn);
 /* Prepare the p2m for paging a frame in */
@@ -483,8 +483,8 @@ int p2m_mem_paging_prep(struct domain *d
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
-static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
-{ }
+static inline int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+{ return 0; }
 static inline void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 { }
 #endif
diff -r 8d67f4d5bafa -r 43dc614d543c xen/include/xen/mm.h
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -318,6 +318,8 @@ page_list_splice(struct page_list_head *
 
 void scrub_one_page(struct page_info *);
 
+/* Returns 1 on success, 0 on error, negative if the ring
+ * for event propagation is full in the presence of paging */
 int guest_remove_page(struct domain *d, unsigned long gmfn);
 
 #define RAM_TYPE_CONVENTIONAL 0x00000001
diff -r 8d67f4d5bafa -r 43dc614d543c xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -183,13 +183,16 @@ struct mem_event_domain
 {
     /* ring lock */
     spinlock_t ring_lock;
-    unsigned int req_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
     void *ring_page;
     /* front-end ring */
     mem_event_front_ring_t front_ring;
+    /* the number of vCPUs blocked */
+    unsigned int blocked;
+    /* The last vcpu woken up */
+    unsigned int last_vcpu_wake_up;
     /* event channel port (vcpu0 only) */
     int xen_port;
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVep-0000Nx-2C; Tue, 29 Nov 2011 21:56:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVen-0000Ld-Ab
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:56:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322603726!3622398!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0NjU5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19517 invoked from network); 29 Nov 2011 21:55:27 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.5) by server-9.tower-174.messagelabs.com with SMTP;
	29 Nov 2011 21:55:27 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 1E51D458085;
	Tue, 29 Nov 2011 13:55:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=m3xZeoJdSg6XBMpAdUi2ZYqw0800OFNWhrbpC+wA2KkL
	iah4imBFfUeIpSGiv9q/MWGSjTtWU+QU1Xmj8ToF+a9urL+71fkE6KamKqfK4/ci
	vcvBx8bxP6JD6/xpH3DwFfHdEcOb1B1QgQ346WE76fln9b7NUCGFPW//2rhAywg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=oqtfeq+6V7Fqky1QzT++8SOFI0k=; b=kyVrW9OSOx0
	kcCA1Sa0WzUOn4oGwUzDT+d/bK+AACRELyB/VG6i9tZrxQ+Jy4LWwyg8B5xhYEzV
	1rz4zp67lDi6pCkzj5UC/tb5C4B9uHKZiJAd27Toa74LHz9J1EFA0XiB+TOCskks
	exdiA4DcZQSFk/8geNXRN77c7AiBKQkU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id 1229145807C; 
	Tue, 29 Nov 2011 13:55:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 29701f5bdd84ed90cb0f6733162b2f7686b5f0f2
Message-Id: <29701f5bdd84ed90cb0f.1322603714@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603709@xdev.gridcentric.ca>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:14 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 5] Allow memevent responses to be signaled
 via the event channel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c |  26 ++++++++++++++++++++------
 1 files changed, 20 insertions(+), 6 deletions(-)


Don't require a separate domctl to notify the memevent interface that an event
has occured.  This domctl can be taxing, particularly when you are scaling
events and paging to many domains across a single system.  Instead, we use the
existing event channel to signal when we place something in the ring (as per
normal ring operation).

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c2b5e65331ee -r 29701f5bdd84 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -37,9 +37,11 @@
 #define mem_event_ring_lock(_med)       spin_lock(&(_med)->ring_lock)
 #define mem_event_ring_unlock(_med)     spin_unlock(&(_med)->ring_lock)
 
-static int mem_event_enable(struct domain *d,
-                            xen_domctl_mem_event_op_t *mec,
-                            struct mem_event_domain *med)
+static int mem_event_enable(
+    struct domain *d,
+    xen_domctl_mem_event_op_t *mec,
+    struct mem_event_domain *med,
+    xen_event_channel_notification_t notification_fn)
 {
     int rc;
     struct domain *dom_mem_event = current->domain;
@@ -97,7 +99,7 @@ static int mem_event_enable(struct domai
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
                                          current->domain->domain_id,
-                                         NULL);
+                                         notification_fn);
     if ( rc < 0 )
         goto err;
 
@@ -330,6 +332,18 @@ int mem_event_check_ring(struct domain *
     return 0;
 }
 
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_paging_notification(struct vcpu *v, unsigned int port)
+{
+    p2m_mem_paging_resume(v->domain);
+}
+
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_access_notification(struct vcpu *v, unsigned int port)
+{
+    p2m_mem_access_resume(v->domain);
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -391,7 +405,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, med, mem_paging_notification);
         }
         break;
 
@@ -430,7 +444,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, med, mem_access_notification);
         }
         break;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVep-0000Nx-2C; Tue, 29 Nov 2011 21:56:07 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVen-0000Ld-Ab
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:56:05 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322603726!3622398!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0NjU5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19517 invoked from network); 29 Nov 2011 21:55:27 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.5) by server-9.tower-174.messagelabs.com with SMTP;
	29 Nov 2011 21:55:27 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 1E51D458085;
	Tue, 29 Nov 2011 13:55:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=m3xZeoJdSg6XBMpAdUi2ZYqw0800OFNWhrbpC+wA2KkL
	iah4imBFfUeIpSGiv9q/MWGSjTtWU+QU1Xmj8ToF+a9urL+71fkE6KamKqfK4/ci
	vcvBx8bxP6JD6/xpH3DwFfHdEcOb1B1QgQ346WE76fln9b7NUCGFPW//2rhAywg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=oqtfeq+6V7Fqky1QzT++8SOFI0k=; b=kyVrW9OSOx0
	kcCA1Sa0WzUOn4oGwUzDT+d/bK+AACRELyB/VG6i9tZrxQ+Jy4LWwyg8B5xhYEzV
	1rz4zp67lDi6pCkzj5UC/tb5C4B9uHKZiJAd27Toa74LHz9J1EFA0XiB+TOCskks
	exdiA4DcZQSFk/8geNXRN77c7AiBKQkU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id 1229145807C; 
	Tue, 29 Nov 2011 13:55:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 29701f5bdd84ed90cb0f6733162b2f7686b5f0f2
Message-Id: <29701f5bdd84ed90cb0f.1322603714@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603709@xdev.gridcentric.ca>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:14 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 5] Allow memevent responses to be signaled
 via the event channel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_event.c |  26 ++++++++++++++++++++------
 1 files changed, 20 insertions(+), 6 deletions(-)


Don't require a separate domctl to notify the memevent interface that an event
has occured.  This domctl can be taxing, particularly when you are scaling
events and paging to many domains across a single system.  Instead, we use the
existing event channel to signal when we place something in the ring (as per
normal ring operation).

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c2b5e65331ee -r 29701f5bdd84 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -37,9 +37,11 @@
 #define mem_event_ring_lock(_med)       spin_lock(&(_med)->ring_lock)
 #define mem_event_ring_unlock(_med)     spin_unlock(&(_med)->ring_lock)
 
-static int mem_event_enable(struct domain *d,
-                            xen_domctl_mem_event_op_t *mec,
-                            struct mem_event_domain *med)
+static int mem_event_enable(
+    struct domain *d,
+    xen_domctl_mem_event_op_t *mec,
+    struct mem_event_domain *med,
+    xen_event_channel_notification_t notification_fn)
 {
     int rc;
     struct domain *dom_mem_event = current->domain;
@@ -97,7 +99,7 @@ static int mem_event_enable(struct domai
     /* Allocate event channel */
     rc = alloc_unbound_xen_event_channel(d->vcpu[0],
                                          current->domain->domain_id,
-                                         NULL);
+                                         notification_fn);
     if ( rc < 0 )
         goto err;
 
@@ -330,6 +332,18 @@ int mem_event_check_ring(struct domain *
     return 0;
 }
 
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_paging_notification(struct vcpu *v, unsigned int port)
+{
+    p2m_mem_paging_resume(v->domain);
+}
+
+/* Registered with Xen-bound event channel for incoming notifications. */
+static void mem_access_notification(struct vcpu *v, unsigned int port)
+{
+    p2m_mem_access_resume(v->domain);
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -391,7 +405,7 @@ int mem_event_domctl(struct domain *d, x
             if ( p2m->pod.entry_count )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, med, mem_paging_notification);
         }
         break;
 
@@ -430,7 +444,7 @@ int mem_event_domctl(struct domain *d, x
             if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
                 break;
 
-            rc = mem_event_enable(d, mec, med);
+            rc = mem_event_enable(d, mec, med, mem_access_notification);
         }
         break;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVen-0000ND-2h; Tue, 29 Nov 2011 21:56:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVel-0000LM-J7
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:56:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322603723!6141461!2
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTU3Nzg=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21316 invoked from network); 29 Nov 2011 21:55:25 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 21:55:25 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id D882C458080;
	Tue, 29 Nov 2011 13:55:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=TAhhPE1ZYD/s0T5a9XlIijpiZK844p/jrpngnpmFOws2
	SORSz4kfzG67CMoRFNx0vsDj3sl0W9ku+F7nwUqW1mwaE3WnpvYJ/AO89wLxbRBn
	roMR2IUWqjH0Vt9ine3ylc8KbRFDKAMLYP7qjdhXWOuwiG0q0sdidytZaAthY2U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=9hsdFMoRtbq3FcJCnzdkmtiK62A=; b=naqvo0N3Ie8
	ywBbmEhdjoRNGwJuMoL2tvf2aLTbtJwWi+heyxKP+7GgSWoL9hgaAvB0uBUktjAt
	e28BXGTKeP9INvmc4L3Y2U/+GLtpJPqQiyAUBdmbOrps7tAcuv9o60q4vKP7i49i
	oQ4bY2HH6MTFOeGvFn7nXpLUCb8IlVSQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id DD11345807C; 
	Tue, 29 Nov 2011 13:55:23 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c2b5e65331ee1fccdcd4eed0b5fbfdafbf44c38b
Message-Id: <c2b5e65331ee1fccdcd4.1322603713@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603709@xdev.gridcentric.ca>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:13 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 5] Make the prototype of
	p2m_mem_access_resume consistent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_access.c |  3 +--
 xen/arch/x86/mm/p2m.c        |  3 +--
 xen/include/asm-x86/p2m.h    |  2 +-
 3 files changed, 3 insertions(+), 5 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 96ba0cb6e255 -r c2b5e65331ee xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -29,13 +29,12 @@ int mem_access_domctl(struct domain *d, 
                       XEN_GUEST_HANDLE(void) u_domctl)
 {
     int rc;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     switch( mec->op )
     {
     case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME:
     {
-        p2m_mem_access_resume(p2m);
+        p2m_mem_access_resume(d);
         rc = 0;
     }
     break;
diff -r 96ba0cb6e255 -r c2b5e65331ee xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1194,9 +1194,8 @@ void p2m_mem_access_check(unsigned long 
     /* VCPU paused */
 }
 
-void p2m_mem_access_resume(struct p2m_domain *p2m)
+void p2m_mem_access_resume(struct domain *d)
 {
-    struct domain *d = p2m->domain;
     mem_event_response_t rsp;
 
     /* Pull all responses off the ring */
diff -r 96ba0cb6e255 -r c2b5e65331ee xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -495,7 +495,7 @@ static inline void p2m_mem_paging_popula
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x);
 /* Resumes the running of the VCPU, restarting the last instruction */
-void p2m_mem_access_resume(struct p2m_domain *p2m);
+void p2m_mem_access_resume(struct domain *d);
 
 /* Set access type for a region of pfns.
  * If start_pfn == -1ul, sets the default access type */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVen-0000ND-2h; Tue, 29 Nov 2011 21:56:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVel-0000LM-J7
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:56:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322603723!6141461!2
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTU3Nzg=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21316 invoked from network); 29 Nov 2011 21:55:25 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.145) by server-6.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 21:55:25 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id D882C458080;
	Tue, 29 Nov 2011 13:55:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=TAhhPE1ZYD/s0T5a9XlIijpiZK844p/jrpngnpmFOws2
	SORSz4kfzG67CMoRFNx0vsDj3sl0W9ku+F7nwUqW1mwaE3WnpvYJ/AO89wLxbRBn
	roMR2IUWqjH0Vt9ine3ylc8KbRFDKAMLYP7qjdhXWOuwiG0q0sdidytZaAthY2U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=9hsdFMoRtbq3FcJCnzdkmtiK62A=; b=naqvo0N3Ie8
	ywBbmEhdjoRNGwJuMoL2tvf2aLTbtJwWi+heyxKP+7GgSWoL9hgaAvB0uBUktjAt
	e28BXGTKeP9INvmc4L3Y2U/+GLtpJPqQiyAUBdmbOrps7tAcuv9o60q4vKP7i49i
	oQ4bY2HH6MTFOeGvFn7nXpLUCb8IlVSQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id DD11345807C; 
	Tue, 29 Nov 2011 13:55:23 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c2b5e65331ee1fccdcd4eed0b5fbfdafbf44c38b
Message-Id: <c2b5e65331ee1fccdcd4.1322603713@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603709@xdev.gridcentric.ca>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:13 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 5] Make the prototype of
	p2m_mem_access_resume consistent
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mem_access.c |  3 +--
 xen/arch/x86/mm/p2m.c        |  3 +--
 xen/include/asm-x86/p2m.h    |  2 +-
 3 files changed, 3 insertions(+), 5 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Keir Fraser <keir@xen.org>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 96ba0cb6e255 -r c2b5e65331ee xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -29,13 +29,12 @@ int mem_access_domctl(struct domain *d, 
                       XEN_GUEST_HANDLE(void) u_domctl)
 {
     int rc;
-    struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
     switch( mec->op )
     {
     case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME:
     {
-        p2m_mem_access_resume(p2m);
+        p2m_mem_access_resume(d);
         rc = 0;
     }
     break;
diff -r 96ba0cb6e255 -r c2b5e65331ee xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1194,9 +1194,8 @@ void p2m_mem_access_check(unsigned long 
     /* VCPU paused */
 }
 
-void p2m_mem_access_resume(struct p2m_domain *p2m)
+void p2m_mem_access_resume(struct domain *d)
 {
-    struct domain *d = p2m->domain;
     mem_event_response_t rsp;
 
     /* Pull all responses off the ring */
diff -r 96ba0cb6e255 -r c2b5e65331ee xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -495,7 +495,7 @@ static inline void p2m_mem_paging_popula
 void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x);
 /* Resumes the running of the VCPU, restarting the last instruction */
-void p2m_mem_access_resume(struct p2m_domain *p2m);
+void p2m_mem_access_resume(struct domain *d);
 
 /* Set access type for a region of pfns.
  * If start_pfn == -1ul, sets the default access type */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVei-0000Ll-JW; Tue, 29 Nov 2011 21:56:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVeh-0000Kw-Hs
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:55:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322603721!5210172!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0NTU5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17805 invoked from network); 29 Nov 2011 21:55:21 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 21:55:21 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 28258458080;
	Tue, 29 Nov 2011 13:55:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=pDcEp8OziZFern8u3R7neN
	5VD4QkewOqZiH+vvGjmx2DMnc6NApD52ILCwm0VVZDU9lqbdFNaXARF8A7Nsmm9t
	c7Tt0WSyM6T378FWOGCn90+ICM+BAz1Aobj4XmVuk3roZOuH6TuGJjJ29XVnJmA4
	AwQiGa74ARPNOnVKB/j9I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=QE+BW1/SzxS0
	kzjxd3Hl4sltVeM=; b=rKGq4L8UWLGNGROASi5MbNkZntiFqadl992vjC7o3+4+
	1LF2PAhe8OQSVXGgphvZ1/efERzsneToKrpvGuOam9RoMgLtd3z0qDiZztYMBNPd
	o8tKivjT6NIR01+vvRkCDIMN7cVGq9EJQQ1ctVHdWvPrtxgCk3005qWiaWvMtgU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id 2B95F45807B; 
	Tue, 29 Nov 2011 13:55:18 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:09 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 5] Memory event interface improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In this patch series we improve the management of congestion in the memory
events ring. We ensure no guest events are lost, even in the face of unbounded
flooding from foreign maps, or balloon.

Also, we enable resumption of mem events via an event channel kick from
user-space to Xen. This is more light-weight and scalable than the current
domctl interface, and allows for batching as well.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/common/memory.c             |   29 +++++-
 xen/arch/x86/hvm/hvm.c          |   20 ++-
 xen/arch/x86/mm/mem_event.c     |  205 ++++++++++++++++++++++++++++++---------
 xen/arch/x86/mm/mem_sharing.c   |   27 +++-
 xen/arch/x86/mm/p2m.c           |  104 ++++++++++---------
 xen/common/memory.c             |    7 +-
 xen/include/asm-x86/mem_event.h |   16 ++-
 xen/include/asm-x86/p2m.h       |    6 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |    5 +-
 xen/arch/ia64/vmx/vmx_init.c    |    2 +-
 xen/arch/x86/hvm/hvm.c          |    7 +-
 xen/arch/x86/mm/mem_event.c     |    3 +-
 xen/common/event_channel.c      |   75 +++++++++++---
 xen/include/xen/event.h         |    5 +-
 xen/include/xen/sched.h         |    2 +-
 xen/arch/x86/mm/mem_access.c    |    3 +-
 xen/arch/x86/mm/p2m.c           |    3 +-
 xen/include/asm-x86/p2m.h       |    2 +-
 xen/arch/x86/mm/mem_event.c     |   26 +++-
 20 files changed, 389 insertions(+), 160 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVei-0000Ll-JW; Tue, 29 Nov 2011 21:56:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVeh-0000Kw-Hs
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:55:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322603721!5210172!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE0NTU5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17805 invoked from network); 29 Nov 2011 21:55:21 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 21:55:21 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 28258458080;
	Tue, 29 Nov 2011 13:55:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=pDcEp8OziZFern8u3R7neN
	5VD4QkewOqZiH+vvGjmx2DMnc6NApD52ILCwm0VVZDU9lqbdFNaXARF8A7Nsmm9t
	c7Tt0WSyM6T378FWOGCn90+ICM+BAz1Aobj4XmVuk3roZOuH6TuGJjJ29XVnJmA4
	AwQiGa74ARPNOnVKB/j9I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=QE+BW1/SzxS0
	kzjxd3Hl4sltVeM=; b=rKGq4L8UWLGNGROASi5MbNkZntiFqadl992vjC7o3+4+
	1LF2PAhe8OQSVXGgphvZ1/efERzsneToKrpvGuOam9RoMgLtd3z0qDiZztYMBNPd
	o8tKivjT6NIR01+vvRkCDIMN7cVGq9EJQQ1ctVHdWvPrtxgCk3005qWiaWvMtgU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id 2B95F45807B; 
	Tue, 29 Nov 2011 13:55:18 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:09 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 5] Memory event interface improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In this patch series we improve the management of congestion in the memory
events ring. We ensure no guest events are lost, even in the face of unbounded
flooding from foreign maps, or balloon.

Also, we enable resumption of mem events via an event channel kick from
user-space to Xen. This is more light-weight and scalable than the current
domctl interface, and allows for batching as well.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/common/memory.c             |   29 +++++-
 xen/arch/x86/hvm/hvm.c          |   20 ++-
 xen/arch/x86/mm/mem_event.c     |  205 ++++++++++++++++++++++++++++++---------
 xen/arch/x86/mm/mem_sharing.c   |   27 +++-
 xen/arch/x86/mm/p2m.c           |  104 ++++++++++---------
 xen/common/memory.c             |    7 +-
 xen/include/asm-x86/mem_event.h |   16 ++-
 xen/include/asm-x86/p2m.h       |    6 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |    5 +-
 xen/arch/ia64/vmx/vmx_init.c    |    2 +-
 xen/arch/x86/hvm/hvm.c          |    7 +-
 xen/arch/x86/mm/mem_event.c     |    3 +-
 xen/common/event_channel.c      |   75 +++++++++++---
 xen/include/xen/event.h         |    5 +-
 xen/include/xen/sched.h         |    2 +-
 xen/arch/x86/mm/mem_access.c    |    3 +-
 xen/arch/x86/mm/p2m.c           |    3 +-
 xen/include/asm-x86/p2m.h       |    2 +-
 xen/arch/x86/mm/mem_event.c     |   26 +++-
 20 files changed, 389 insertions(+), 160 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVek-0000M6-0s; Tue, 29 Nov 2011 21:56:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVei-0000L5-MP
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:56:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322603722!5188593!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU0MDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16080 invoked from network); 29 Nov 2011 21:55:22 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 21:55:22 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 53A4245807C;
	Tue, 29 Nov 2011 13:55:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=k69QIDHQRKseJ6VderYgy0vYWWhNOlhYn1nXAaVPYJRC
	OyFBd15mLE38hL2cCoj5oiGTjBvJE+wyN6+eHRA6bW8co+DLGH1MwDLNTx+j2rF8
	7+ZP3mgbsknu4a2xQoaVnjd1DdigMVCtW61qkWqavkOFUSc3NCdZO3SBaDMfn1M=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=canZ/9zEPpzd8VAeEkzkm+rHSEA=; b=cT0s5SIADIq
	gRst3bOWS0MF4c0EAAuLMi4LM48AqIFdvm9OeuAYLFVkuZVQBMUmFtTmlGzuvCMn
	THsG7sGyvecamTHZI8g23TGCRskp2F92/ltKR1+BC/JnvkYTVI/z4GkJxrCz70uA
	buaPiBsfLSIralrAx2TcvDdrB7Fw3K6E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id 5521445807B; 
	Tue, 29 Nov 2011 13:55:20 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8d67f4d5bafa3b75f01fde4cccc25be92416b63f
Message-Id: <8d67f4d5bafa3b75f01f.1322603710@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603709@xdev.gridcentric.ca>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:10 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 5] Allow decrease_reservation to be
 preempted if remove_page returns negative
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/memory.c |  29 ++++++++++++++++++++++++++++-
 1 files changed, 28 insertions(+), 1 deletions(-)


This will allow for handling of full paging rings in a more graceful manner.
ATM, remove_page does not return negative values, so this code is not yet
exercised.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 15da109b0c7d -r 8d67f4d5bafa xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -226,6 +226,8 @@ static void decrease_reservation(struct 
 
     for ( i = a->nr_done; i < a->nr_extents; i++ )
     {
+        int one_remove_succeeded = 0;
+
         if ( hypercall_preempt_check() )
         {
             a->preempted = 1;
@@ -255,8 +257,33 @@ static void decrease_reservation(struct 
             continue;
 
         for ( j = 0; j < (1 << a->extent_order); j++ )
-            if ( !guest_remove_page(a->domain, gmfn + j) )
+        {
+            int rv = guest_remove_page(a->domain, gmfn + j);
+            /* negative rv is a result of a mem event ring full
+             * in the presence of paging. We preempt the hypercall */
+            if ( rv < 0 )
+            {
+                /* Indicate we're done with this extent */
+                if ((j+1) == (1 << a->extent_order))
+                    i++;
+                a->preempted = 1;
+                raise_softirq(SCHEDULE_SOFTIRQ);
                 goto out;
+            }
+            /* rv of zero means we tried to remove a gfn with no backing
+             * mfn. It can be a bad argument, or, a continuation in the midst
+             * of an extent. Heuristically determine second case. */
+            if ( !rv )
+            {
+                /* Has to be first extent */
+                if ( i != a->nr_done )
+                    goto out;
+                /* No previous remove in this extent must have succeeded */
+                if ( one_remove_succeeded )
+                    goto out;
+            } else
+                one_remove_succeeded = 1;
+        }
     }
 
  out:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:56:17 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:56:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVek-0000M6-0s; Tue, 29 Nov 2011 21:56:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVei-0000L5-MP
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:56:00 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322603722!5188593!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU0MDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16080 invoked from network); 29 Nov 2011 21:55:22 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 21:55:22 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 53A4245807C;
	Tue, 29 Nov 2011 13:55:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=k69QIDHQRKseJ6VderYgy0vYWWhNOlhYn1nXAaVPYJRC
	OyFBd15mLE38hL2cCoj5oiGTjBvJE+wyN6+eHRA6bW8co+DLGH1MwDLNTx+j2rF8
	7+ZP3mgbsknu4a2xQoaVnjd1DdigMVCtW61qkWqavkOFUSc3NCdZO3SBaDMfn1M=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=canZ/9zEPpzd8VAeEkzkm+rHSEA=; b=cT0s5SIADIq
	gRst3bOWS0MF4c0EAAuLMi4LM48AqIFdvm9OeuAYLFVkuZVQBMUmFtTmlGzuvCMn
	THsG7sGyvecamTHZI8g23TGCRskp2F92/ltKR1+BC/JnvkYTVI/z4GkJxrCz70uA
	buaPiBsfLSIralrAx2TcvDdrB7Fw3K6E=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPSA id 5521445807B; 
	Tue, 29 Nov 2011 13:55:20 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 8d67f4d5bafa3b75f01fde4cccc25be92416b63f
Message-Id: <8d67f4d5bafa3b75f01f.1322603710@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603709@xdev.gridcentric.ca>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:55:10 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.campbell@citrix.com, andres@gridcentric.ca, tim@xen.org,
	keir.xen@gmail.com, JBeulich@suse.com, ian.jackson@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 5] Allow decrease_reservation to be
 preempted if remove_page returns negative
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/common/memory.c |  29 ++++++++++++++++++++++++++++-
 1 files changed, 28 insertions(+), 1 deletions(-)


This will allow for handling of full paging rings in a more graceful manner.
ATM, remove_page does not return negative values, so this code is not yet
exercised.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 15da109b0c7d -r 8d67f4d5bafa xen/common/memory.c
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -226,6 +226,8 @@ static void decrease_reservation(struct 
 
     for ( i = a->nr_done; i < a->nr_extents; i++ )
     {
+        int one_remove_succeeded = 0;
+
         if ( hypercall_preempt_check() )
         {
             a->preempted = 1;
@@ -255,8 +257,33 @@ static void decrease_reservation(struct 
             continue;
 
         for ( j = 0; j < (1 << a->extent_order); j++ )
-            if ( !guest_remove_page(a->domain, gmfn + j) )
+        {
+            int rv = guest_remove_page(a->domain, gmfn + j);
+            /* negative rv is a result of a mem event ring full
+             * in the presence of paging. We preempt the hypercall */
+            if ( rv < 0 )
+            {
+                /* Indicate we're done with this extent */
+                if ((j+1) == (1 << a->extent_order))
+                    i++;
+                a->preempted = 1;
+                raise_softirq(SCHEDULE_SOFTIRQ);
                 goto out;
+            }
+            /* rv of zero means we tried to remove a gfn with no backing
+             * mfn. It can be a bad argument, or, a continuation in the midst
+             * of an extent. Heuristically determine second case. */
+            if ( !rv )
+            {
+                /* Has to be first extent */
+                if ( i != a->nr_done )
+                    goto out;
+                /* No previous remove in this extent must have succeeded */
+                if ( one_remove_succeeded )
+                    goto out;
+            } else
+                one_remove_succeeded = 1;
+        }
     }
 
  out:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:59:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:59:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVhd-0001CW-OS; Tue, 29 Nov 2011 21:59:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVhd-0001BQ-1a
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:59:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322603902!5500572!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU0MDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26275 invoked from network); 29 Nov 2011 21:58:23 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.119) by server-3.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 21:58:23 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 917B8300064;
	Tue, 29 Nov 2011 13:58:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=a9J3yJxp8dWE2oA05LlVFS
	TA67WpnywYwtNW+38Se0OkG7v5OoFXVPp2KAkiWhufhghCbb8F1R09GaD/4X+gX6
	HRh2asCmK3CrtUtgA3B4ByfVhPb7jO2i0CtqJ57bJQYQ67mU+UARwunTzF1gUTzP
	XSNJH+P1jy1iUL7dBqYhg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=Fqbk1WRID3Wr
	Ci470AucHOwtMpc=; b=Cnc+6v0RaKkuZhJTrWBbEmEf3Fbc2osdS4b6UP4UHCag
	6jxgxqKElgSEaBMzvYPA3MA4+4xfJQHVV5wq2KpCPPk4TSCvkkonjVTGSCofzCrp
	rOvFTh5vtM9d4ZRqQN0Y6Q8DtrfFu6g1YLAdVak8dZsvcbJ5kWx1HnqnX0F7BI0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id E6695300072; 
	Tue, 29 Nov 2011 13:58:21 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322603903@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:58:23 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] New mem access type: None -> RWX
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/hvm/hvm.c          |  45 ++++++++++++++++++++++++++++++++++------
 xen/arch/x86/mm/p2m.c           |   8 ++++--
 xen/include/asm-x86/p2m.h       |   9 ++++---
 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++--------
 xen/include/asm-x86/p2m.h       |   3 ++
 xen/include/public/hvm/hvm_op.h |   3 ++
 8 files changed, 77 insertions(+), 23 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:59:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:59:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVhd-0001CW-OS; Tue, 29 Nov 2011 21:59:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVhd-0001BQ-1a
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:59:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322603902!5500572!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU0MDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26275 invoked from network); 29 Nov 2011 21:58:23 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.119) by server-3.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 21:58:23 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 917B8300064;
	Tue, 29 Nov 2011 13:58:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=a9J3yJxp8dWE2oA05LlVFS
	TA67WpnywYwtNW+38Se0OkG7v5OoFXVPp2KAkiWhufhghCbb8F1R09GaD/4X+gX6
	HRh2asCmK3CrtUtgA3B4ByfVhPb7jO2i0CtqJ57bJQYQ67mU+UARwunTzF1gUTzP
	XSNJH+P1jy1iUL7dBqYhg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:date:from:to:cc; s=lagarcavilla.org; bh=Fqbk1WRID3Wr
	Ci470AucHOwtMpc=; b=Cnc+6v0RaKkuZhJTrWBbEmEf3Fbc2osdS4b6UP4UHCag
	6jxgxqKElgSEaBMzvYPA3MA4+4xfJQHVV5wq2KpCPPk4TSCvkkonjVTGSCofzCrp
	rOvFTh5vtM9d4ZRqQN0Y6Q8DtrfFu6g1YLAdVak8dZsvcbJ5kWx1HnqnX0F7BI0=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id E6695300072; 
	Tue, 29 Nov 2011 13:58:21 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1322603903@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:58:23 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] New mem access type: None -> RWX
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/hvm/hvm.c          |  45 ++++++++++++++++++++++++++++++++++------
 xen/arch/x86/mm/p2m.c           |   8 ++++--
 xen/include/asm-x86/p2m.h       |   9 ++++---
 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++--------
 xen/include/asm-x86/p2m.h       |   3 ++
 xen/include/public/hvm/hvm_op.h |   3 ++
 8 files changed, 77 insertions(+), 23 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:59:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVhf-0001D1-6d; Tue, 29 Nov 2011 21:59:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVhe-0001BU-1O
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:59:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322603903!5522992!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU0MDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11073 invoked from network); 29 Nov 2011 21:58:24 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.119) by server-4.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 21:58:24 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 7F0B1300079;
	Tue, 29 Nov 2011 13:58:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=VfSmd1sE/WIUS3WNP1pA1cMZPkTx62VOLlO5WAZscEtH
	hIq8R4RQTtr+zdiXhUWEQEAS90LLDGTku7c5WCO+j0oGn6+uBT7QM6DelUh6kAZg
	BE0CS3eKx56Mk8gqoqt6PzabMuqluHy8ef8uKi9QZaszYFal4e3LQ4PpiCTg9gM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=TSQiGRJp2zeLG/u8ZoRk5XcQDrY=; b=PnjQLp3u9SF
	cuHCExpOaalI/CHLS/ynMS8jl7Z4DQb6kOCILsTGT7Z3X7REbLWXfGW3YwoU3ZkP
	VVL3AfLPnJDEVXJOV7+QTtB/T0bBh2eVkPz0+cyaX029rVgqDm+hlPxUhpq+QOGg
	tzctMvxjJi7kxQYIdZ1aTl8ntHW737R8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id CC22D300072; 
	Tue, 29 Nov 2011 13:58:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d6354df726a0637404238c99eeb5d0537f6f242d
Message-Id: <d6354df726a063740423.1322603904@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603903@xdev.gridcentric.ca>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:58:24 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: When mem event automatically
 promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c    |  45 ++++++++++++++++++++++++++++++++++++++-------
 xen/arch/x86/mm/p2m.c     |   8 +++++---
 xen/include/asm-x86/p2m.h |   9 +++++----
 3 files changed, 48 insertions(+), 14 deletions(-)


The mem event fault handler in the p2m can automatically promote the access
rights of a p2m entry. In those scenarios, vcpu's are not paused and they will
immediately retry the faulting instructions. This will generate a second fault
if the underlying entry type requires so (paging, unsharing, pod, etc).
Collapse the two faults into a single one.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1278,9 +1278,13 @@ int hvm_hap_nested_page_fault(unsigned l
 
         if ( violation )
         {
-            p2m_mem_access_check(gpa, gla_valid, gla, access_r, access_w, access_x);
-            rc = 1;
-            goto out_put_gfn;
+            if ( !p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
+                                        access_w, access_x) )
+            {
+                /* Rights not promoted, vcpu paused, work here is done */
+                rc = 1;
+                goto out_put_gfn;
+            }
         }
     }
 
@@ -1288,7 +1292,8 @@ int hvm_hap_nested_page_fault(unsigned l
      * If this GFN is emulated MMIO or marked as read-only, pass the fault
      * to the mmio handler.
      */
-    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
+    if ( (p2mt == p2m_mmio_dm) || 
+         (access_w && (p2mt == p2m_ram_ro)) )
     {
         if ( !handle_mmio() )
             hvm_inject_exception(TRAP_gp_fault, 0, 0);
@@ -1302,7 +1307,7 @@ int hvm_hap_nested_page_fault(unsigned l
         p2m_mem_paging_populate(v->domain, gfn);
 
     /* Mem sharing: unshare the page and try again */
-    if ( p2mt == p2m_ram_shared )
+    if ( access_w && (p2mt == p2m_ram_shared) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
         mem_sharing_unshare_page(p2m->domain, gfn, 0);
@@ -1319,14 +1324,15 @@ int hvm_hap_nested_page_fault(unsigned l
          * a large page, we do not change other pages type within that large
          * page.
          */
-        paging_mark_dirty(v->domain, mfn_x(mfn));
+        if ( access_w )
+            paging_mark_dirty(v->domain, mfn_x(mfn));
         p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
         rc = 1;
         goto out_put_gfn;
     }
 
     /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
-    if ( p2mt == p2m_grant_map_ro )
+    if ( access_w && (p2mt == p2m_grant_map_ro) )
     {
         gdprintk(XENLOG_WARNING,
                  "trying to write to read-only grant mapping\n");
@@ -1335,6 +1341,31 @@ int hvm_hap_nested_page_fault(unsigned l
         goto out_put_gfn;
     }
 
+    if ( access_x && (p2m_is_grant(p2mt)) )
+    {
+        gdprintk(XENLOG_WARNING,
+                 "trying to execut a grant mapping\n");
+        hvm_inject_exception(TRAP_gp_fault, 0, 0);
+        rc = 1;
+        goto out_put_gfn;
+    }
+
+    if ( p2m_is_grant(p2mt) )
+    {
+        /* If we haven't caught this by now, then it's a valid access */
+        rc = 1;
+        goto out_put_gfn;
+    }
+
+    if ( p2mt == p2m_mmio_direct )
+    {
+        if ( !(access_w && 
+                rangeset_contains_singleton(mmio_ro_ranges, mfn_x(mfn))) ) {
+            rc = 1;
+            goto out_put_gfn;
+        }
+    }
+
     rc = 0;
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1126,7 +1126,7 @@ void p2m_mem_paging_resume(struct domain
     mem_event_unpause_vcpus(d, &d->mem_paging);
 }
 
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+int p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x)
 {
     struct vcpu *v = current;
@@ -1146,7 +1146,7 @@ void p2m_mem_access_check(unsigned long 
     {
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
         p2m_unlock(p2m);
-        return;
+        return 1;
     }
     p2m_unlock(p2m);
 
@@ -1166,9 +1166,10 @@ void p2m_mem_access_check(unsigned long 
             p2m_lock(p2m);
             p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
             p2m_unlock(p2m);
+            return 1;
         }
 
-        return;
+        return 0;
     }
 
     memset(&req, 0, sizeof(req));
@@ -1192,6 +1193,7 @@ void p2m_mem_access_check(unsigned long 
 
     (void)mem_event_put_request(d, &d->mem_access, &req);
     /* VCPU paused */
+    return 0;
 }
 
 void p2m_mem_access_resume(struct domain *d)
diff -r 29701f5bdd84 -r d6354df726a0 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -491,8 +491,9 @@ static inline void p2m_mem_paging_popula
 
 #ifdef __x86_64__
 /* Send mem event based on the access (gla is -1ull if not available).  Handles
- * the rw2rx conversion */
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+ * the rw2rx conversion. Return value indicate if access rights have been
+ * promoted with no underlying vcpu pause. */
+int p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x);
 /* Resumes the running of the VCPU, restarting the last instruction */
 void p2m_mem_access_resume(struct domain *d);
@@ -508,10 +509,10 @@ int p2m_get_mem_access(struct domain *d,
                        hvmmem_access_t *access);
 
 #else
-static inline void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
+static inline int p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
                                         unsigned long gla, bool_t access_r, 
                                         bool_t access_w, bool_t access_x)
-{ }
+{ return 1; }
 static inline int p2m_set_mem_access(struct domain *d, 
                                      unsigned long start_pfn, 
                                      uint32_t nr, hvmmem_access_t access)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:59:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVhf-0001D1-6d; Tue, 29 Nov 2011 21:59:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVhe-0001BU-1O
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:59:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322603903!5522992!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTU0MDY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11073 invoked from network); 29 Nov 2011 21:58:24 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.119) by server-4.tower-216.messagelabs.com with SMTP;
	29 Nov 2011 21:58:24 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 7F0B1300079;
	Tue, 29 Nov 2011 13:58:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=VfSmd1sE/WIUS3WNP1pA1cMZPkTx62VOLlO5WAZscEtH
	hIq8R4RQTtr+zdiXhUWEQEAS90LLDGTku7c5WCO+j0oGn6+uBT7QM6DelUh6kAZg
	BE0CS3eKx56Mk8gqoqt6PzabMuqluHy8ef8uKi9QZaszYFal4e3LQ4PpiCTg9gM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=TSQiGRJp2zeLG/u8ZoRk5XcQDrY=; b=PnjQLp3u9SF
	cuHCExpOaalI/CHLS/ynMS8jl7Z4DQb6kOCILsTGT7Z3X7REbLWXfGW3YwoU3ZkP
	VVL3AfLPnJDEVXJOV7+QTtB/T0bBh2eVkPz0+cyaX029rVgqDm+hlPxUhpq+QOGg
	tzctMvxjJi7kxQYIdZ1aTl8ntHW737R8=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id CC22D300072; 
	Tue, 29 Nov 2011 13:58:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d6354df726a0637404238c99eeb5d0537f6f242d
Message-Id: <d6354df726a063740423.1322603904@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603903@xdev.gridcentric.ca>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:58:24 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: When mem event automatically
 promotes access rights, let other subsystems know
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c    |  45 ++++++++++++++++++++++++++++++++++++++-------
 xen/arch/x86/mm/p2m.c     |   8 +++++---
 xen/include/asm-x86/p2m.h |   9 +++++----
 3 files changed, 48 insertions(+), 14 deletions(-)


The mem event fault handler in the p2m can automatically promote the access
rights of a p2m entry. In those scenarios, vcpu's are not paused and they will
immediately retry the faulting instructions. This will generate a second fault
if the underlying entry type requires so (paging, unsharing, pod, etc).
Collapse the two faults into a single one.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1278,9 +1278,13 @@ int hvm_hap_nested_page_fault(unsigned l
 
         if ( violation )
         {
-            p2m_mem_access_check(gpa, gla_valid, gla, access_r, access_w, access_x);
-            rc = 1;
-            goto out_put_gfn;
+            if ( !p2m_mem_access_check(gpa, gla_valid, gla, access_r, 
+                                        access_w, access_x) )
+            {
+                /* Rights not promoted, vcpu paused, work here is done */
+                rc = 1;
+                goto out_put_gfn;
+            }
         }
     }
 
@@ -1288,7 +1292,8 @@ int hvm_hap_nested_page_fault(unsigned l
      * If this GFN is emulated MMIO or marked as read-only, pass the fault
      * to the mmio handler.
      */
-    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
+    if ( (p2mt == p2m_mmio_dm) || 
+         (access_w && (p2mt == p2m_ram_ro)) )
     {
         if ( !handle_mmio() )
             hvm_inject_exception(TRAP_gp_fault, 0, 0);
@@ -1302,7 +1307,7 @@ int hvm_hap_nested_page_fault(unsigned l
         p2m_mem_paging_populate(v->domain, gfn);
 
     /* Mem sharing: unshare the page and try again */
-    if ( p2mt == p2m_ram_shared )
+    if ( access_w && (p2mt == p2m_ram_shared) )
     {
         ASSERT(!p2m_is_nestedp2m(p2m));
         mem_sharing_unshare_page(p2m->domain, gfn, 0);
@@ -1319,14 +1324,15 @@ int hvm_hap_nested_page_fault(unsigned l
          * a large page, we do not change other pages type within that large
          * page.
          */
-        paging_mark_dirty(v->domain, mfn_x(mfn));
+        if ( access_w )
+            paging_mark_dirty(v->domain, mfn_x(mfn));
         p2m_change_type(v->domain, gfn, p2m_ram_logdirty, p2m_ram_rw);
         rc = 1;
         goto out_put_gfn;
     }
 
     /* Shouldn't happen: Maybe the guest was writing to a r/o grant mapping? */
-    if ( p2mt == p2m_grant_map_ro )
+    if ( access_w && (p2mt == p2m_grant_map_ro) )
     {
         gdprintk(XENLOG_WARNING,
                  "trying to write to read-only grant mapping\n");
@@ -1335,6 +1341,31 @@ int hvm_hap_nested_page_fault(unsigned l
         goto out_put_gfn;
     }
 
+    if ( access_x && (p2m_is_grant(p2mt)) )
+    {
+        gdprintk(XENLOG_WARNING,
+                 "trying to execut a grant mapping\n");
+        hvm_inject_exception(TRAP_gp_fault, 0, 0);
+        rc = 1;
+        goto out_put_gfn;
+    }
+
+    if ( p2m_is_grant(p2mt) )
+    {
+        /* If we haven't caught this by now, then it's a valid access */
+        rc = 1;
+        goto out_put_gfn;
+    }
+
+    if ( p2mt == p2m_mmio_direct )
+    {
+        if ( !(access_w && 
+                rangeset_contains_singleton(mmio_ro_ranges, mfn_x(mfn))) ) {
+            rc = 1;
+            goto out_put_gfn;
+        }
+    }
+
     rc = 0;
 out_put_gfn:
     put_gfn(p2m->domain, gfn);
diff -r 29701f5bdd84 -r d6354df726a0 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1126,7 +1126,7 @@ void p2m_mem_paging_resume(struct domain
     mem_event_unpause_vcpus(d, &d->mem_paging);
 }
 
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+int p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x)
 {
     struct vcpu *v = current;
@@ -1146,7 +1146,7 @@ void p2m_mem_access_check(unsigned long 
     {
         p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rw);
         p2m_unlock(p2m);
-        return;
+        return 1;
     }
     p2m_unlock(p2m);
 
@@ -1166,9 +1166,10 @@ void p2m_mem_access_check(unsigned long 
             p2m_lock(p2m);
             p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
             p2m_unlock(p2m);
+            return 1;
         }
 
-        return;
+        return 0;
     }
 
     memset(&req, 0, sizeof(req));
@@ -1192,6 +1193,7 @@ void p2m_mem_access_check(unsigned long 
 
     (void)mem_event_put_request(d, &d->mem_access, &req);
     /* VCPU paused */
+    return 0;
 }
 
 void p2m_mem_access_resume(struct domain *d)
diff -r 29701f5bdd84 -r d6354df726a0 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -491,8 +491,9 @@ static inline void p2m_mem_paging_popula
 
 #ifdef __x86_64__
 /* Send mem event based on the access (gla is -1ull if not available).  Handles
- * the rw2rx conversion */
-void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
+ * the rw2rx conversion. Return value indicate if access rights have been
+ * promoted with no underlying vcpu pause. */
+int p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
                           bool_t access_r, bool_t access_w, bool_t access_x);
 /* Resumes the running of the VCPU, restarting the last instruction */
 void p2m_mem_access_resume(struct domain *d);
@@ -508,10 +509,10 @@ int p2m_get_mem_access(struct domain *d,
                        hvmmem_access_t *access);
 
 #else
-static inline void p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
+static inline int p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, 
                                         unsigned long gla, bool_t access_r, 
                                         bool_t access_w, bool_t access_x)
-{ }
+{ return 1; }
 static inline int p2m_set_mem_access(struct domain *d, 
                                      unsigned long start_pfn, 
                                      uint32_t nr, hvmmem_access_t access)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:59:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:59:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVhf-0001DX-QU; Tue, 29 Nov 2011 21:59:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVhf-0001Bk-2E
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:59:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322603904!4320824!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU2ODU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8876 invoked from network); 29 Nov 2011 21:58:25 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.202) by server-13.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 21:58:25 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 4D6F9300072;
	Tue, 29 Nov 2011 13:58:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=JPWp+9EpQvJdXzhKu6uC4xXBT8Ar3eRYP8UNAaDWGcYf
	fNPzsUxFAozyf+uMWG0ldf4Xx5m/8wjfXP4fnJ1bZv/o2mQ1qiTlmZZqAZ6RnPsy
	4NObhWCiOHvjn6TXgECUcGKvAkozrneAkijkP/BV0ABy99ZkSORqK/fd1hfppdQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=hPYxUbBA0MZtRkyEAsAwAZQ9+GE=; b=a6VH0PXtl41
	xoVe3Bk7Mqlm/UWhMUWXxCRsbY6ug5s/wSuvo+vByQNgiqXXiQExeG9r/1LvIq4Q
	ui6iOyGiZT0TxZLaRgOJRRTWy/VSu14cUjswBnkHSybiQOaFFYF4Z3k2BTiFmNNt
	9oVnIsbjCiZ3qRjg3Lp8j/XQZJhzDaHc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id AC65630006C; 
	Tue, 29 Nov 2011 13:58:23 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 52d6aede6206e2cd7d17d4541a08bcb2ef4d9250
Message-Id: <52d6aede6206e2cd7d17.1322603905@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603903@xdev.gridcentric.ca>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:58:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] x86/mm: New mem access type to log access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++++---------
 xen/include/asm-x86/p2m.h       |   3 +++
 xen/include/public/hvm/hvm_op.h |   3 +++
 5 files changed, 29 insertions(+), 9 deletions(-)


This patch adds a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r d6354df726a0 -r 52d6aede6206 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1250,6 +1250,7 @@ int hvm_hap_nested_page_fault(unsigned l
         switch (p2ma) 
         {
         case p2m_access_n:
+        case p2m_access_n2rwx:
         default:
             violation = access_r || access_w || access_x;
             break;
diff -r d6354df726a0 -r 52d6aede6206 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -111,6 +111,7 @@ static void ept_p2m_type_to_flags(ept_en
     switch (access) 
     {
         case p2m_access_n:
+        case p2m_access_n2rwx:
             entry->r = entry->w = entry->x = 0;
             break;
         case p2m_access_r:
diff -r d6354df726a0 -r 52d6aede6206 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1148,6 +1148,11 @@ int p2m_mem_access_check(unsigned long g
         p2m_unlock(p2m);
         return 1;
     }
+    else if ( p2ma == p2m_access_n2rwx )
+    {
+        ASSERT(access_w || access_r || access_x);
+        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+    }
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
@@ -1162,10 +1167,13 @@ int p2m_mem_access_check(unsigned long g
         }
         else
         {
-            /* A listener is not required, so clear the access restrictions */
-            p2m_lock(p2m);
-            p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
-            p2m_unlock(p2m);
+            if ( p2ma != p2m_access_n2rwx )
+            {
+                /* A listener is not required, so clear the access restrictions */
+                p2m_lock(p2m);
+                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+                p2m_unlock(p2m);
+            }
             return 1;
         }
 
@@ -1176,9 +1184,12 @@ int p2m_mem_access_check(unsigned long g
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = MEM_EVENT_REASON_VIOLATION;
 
-    /* Pause the current VCPU unconditionally */
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+    /* Pause the current VCPU */
+    if ( p2ma != p2m_access_n2rwx )
+    {
+        vcpu_pause_nosync(v);
+        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    } 
 
     /* Send request to mem event */
     req.gfn = gfn;
@@ -1192,8 +1203,8 @@ int p2m_mem_access_check(unsigned long g
     req.vcpu_id = v->vcpu_id;
 
     (void)mem_event_put_request(d, &d->mem_access, &req);
-    /* VCPU paused */
-    return 0;
+    /* VCPU may be paused, return whether we promoted automatically */
+    return (p2ma == p2m_access_n2rwx);
 }
 
 void p2m_mem_access_resume(struct domain *d)
@@ -1237,6 +1248,7 @@ int p2m_set_mem_access(struct domain *d,
         p2m_access_wx,
         p2m_access_rwx,
         p2m_access_rx2rw,
+        p2m_access_n2rwx,
         p2m->default_access,
     };
 
diff -r d6354df726a0 -r 52d6aede6206 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -108,6 +108,9 @@ typedef enum {
     p2m_access_wx    = 6, 
     p2m_access_rwx   = 7,
     p2m_access_rx2rw = 8, /* Special: page goes from RX to RW on write */
+    p2m_access_n2rwx = 9, /* Special: page goes from N to RWX on access, *
+                           * generates an event but does not pause the
+                           * vcpu */
 
     /* NOTE: Assumed to be only 4 bits right now */
 } p2m_access_t;
diff -r d6354df726a0 -r 52d6aede6206 xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -174,6 +174,9 @@ typedef enum {
     HVMMEM_access_rwx,
     HVMMEM_access_rx2rw,       /* Page starts off as r-x, but automatically
                                 * change to r-w on a write */
+    HVMMEM_access_n2rwx,       /* Log access: starts off as n, automatically 
+                                * goes to rwx, generating an event without
+                                * pausing the vcpu */
     HVMMEM_access_default      /* Take the domain default */
 } hvmmem_access_t;
 /* Notify that a region of memory is to have specific access types */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 21:59:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 21:59:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVVhf-0001DX-QU; Tue, 29 Nov 2011 21:59:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVVhf-0001Bk-2E
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 21:59:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322603904!4320824!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU2ODU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8876 invoked from network); 29 Nov 2011 21:58:25 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.202) by server-13.tower-21.messagelabs.com with SMTP;
	29 Nov 2011 21:58:25 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 4D6F9300072;
	Tue, 29 Nov 2011 13:58:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=JPWp+9EpQvJdXzhKu6uC4xXBT8Ar3eRYP8UNAaDWGcYf
	fNPzsUxFAozyf+uMWG0ldf4Xx5m/8wjfXP4fnJ1bZv/o2mQ1qiTlmZZqAZ6RnPsy
	4NObhWCiOHvjn6TXgECUcGKvAkozrneAkijkP/BV0ABy99ZkSORqK/fd1hfppdQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=hPYxUbBA0MZtRkyEAsAwAZQ9+GE=; b=a6VH0PXtl41
	xoVe3Bk7Mqlm/UWhMUWXxCRsbY6ug5s/wSuvo+vByQNgiqXXiQExeG9r/1LvIq4Q
	ui6iOyGiZT0TxZLaRgOJRRTWy/VSu14cUjswBnkHSybiQOaFFYF4Z3k2BTiFmNNt
	9oVnIsbjCiZ3qRjg3Lp8j/XQZJhzDaHc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPSA id AC65630006C; 
	Tue, 29 Nov 2011 13:58:23 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 52d6aede6206e2cd7d17d4541a08bcb2ef4d9250
Message-Id: <52d6aede6206e2cd7d17.1322603905@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1322603903@xdev.gridcentric.ca>
References: <patchbomb.1322603903@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 29 Nov 2011 16:58:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, keir.xen@gmail.com, tim@xen.org, JBeulich@suse.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] x86/mm: New mem access type to log access
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/hvm.c          |   1 +
 xen/arch/x86/mm/p2m-ept.c       |   1 +
 xen/arch/x86/mm/p2m.c           |  30 +++++++++++++++++++++---------
 xen/include/asm-x86/p2m.h       |   3 +++
 xen/include/public/hvm/hvm_op.h |   3 +++
 5 files changed, 29 insertions(+), 9 deletions(-)


This patch adds a new p2m access type, n2rwx. It allows for implement a "log
access" mode in the hypervisor, aking to log dirty but for all types of
accesses. Faults caused by this access mode automatically promote the
access rights of the ofending p2m entry, place the event in the ring, and
let the vcpu keep on executing.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r d6354df726a0 -r 52d6aede6206 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1250,6 +1250,7 @@ int hvm_hap_nested_page_fault(unsigned l
         switch (p2ma) 
         {
         case p2m_access_n:
+        case p2m_access_n2rwx:
         default:
             violation = access_r || access_w || access_x;
             break;
diff -r d6354df726a0 -r 52d6aede6206 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -111,6 +111,7 @@ static void ept_p2m_type_to_flags(ept_en
     switch (access) 
     {
         case p2m_access_n:
+        case p2m_access_n2rwx:
             entry->r = entry->w = entry->x = 0;
             break;
         case p2m_access_r:
diff -r d6354df726a0 -r 52d6aede6206 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1148,6 +1148,11 @@ int p2m_mem_access_check(unsigned long g
         p2m_unlock(p2m);
         return 1;
     }
+    else if ( p2ma == p2m_access_n2rwx )
+    {
+        ASSERT(access_w || access_r || access_x);
+        p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+    }
     p2m_unlock(p2m);
 
     /* Otherwise, check if there is a memory event listener, and send the message along */
@@ -1162,10 +1167,13 @@ int p2m_mem_access_check(unsigned long g
         }
         else
         {
-            /* A listener is not required, so clear the access restrictions */
-            p2m_lock(p2m);
-            p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
-            p2m_unlock(p2m);
+            if ( p2ma != p2m_access_n2rwx )
+            {
+                /* A listener is not required, so clear the access restrictions */
+                p2m_lock(p2m);
+                p2m->set_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2mt, p2m_access_rwx);
+                p2m_unlock(p2m);
+            }
             return 1;
         }
 
@@ -1176,9 +1184,12 @@ int p2m_mem_access_check(unsigned long g
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = MEM_EVENT_REASON_VIOLATION;
 
-    /* Pause the current VCPU unconditionally */
-    vcpu_pause_nosync(v);
-    req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
+    /* Pause the current VCPU */
+    if ( p2ma != p2m_access_n2rwx )
+    {
+        vcpu_pause_nosync(v);
+        req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
+    } 
 
     /* Send request to mem event */
     req.gfn = gfn;
@@ -1192,8 +1203,8 @@ int p2m_mem_access_check(unsigned long g
     req.vcpu_id = v->vcpu_id;
 
     (void)mem_event_put_request(d, &d->mem_access, &req);
-    /* VCPU paused */
-    return 0;
+    /* VCPU may be paused, return whether we promoted automatically */
+    return (p2ma == p2m_access_n2rwx);
 }
 
 void p2m_mem_access_resume(struct domain *d)
@@ -1237,6 +1248,7 @@ int p2m_set_mem_access(struct domain *d,
         p2m_access_wx,
         p2m_access_rwx,
         p2m_access_rx2rw,
+        p2m_access_n2rwx,
         p2m->default_access,
     };
 
diff -r d6354df726a0 -r 52d6aede6206 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -108,6 +108,9 @@ typedef enum {
     p2m_access_wx    = 6, 
     p2m_access_rwx   = 7,
     p2m_access_rx2rw = 8, /* Special: page goes from RX to RW on write */
+    p2m_access_n2rwx = 9, /* Special: page goes from N to RWX on access, *
+                           * generates an event but does not pause the
+                           * vcpu */
 
     /* NOTE: Assumed to be only 4 bits right now */
 } p2m_access_t;
diff -r d6354df726a0 -r 52d6aede6206 xen/include/public/hvm/hvm_op.h
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -174,6 +174,9 @@ typedef enum {
     HVMMEM_access_rwx,
     HVMMEM_access_rx2rw,       /* Page starts off as r-x, but automatically
                                 * change to r-w on a write */
+    HVMMEM_access_n2rwx,       /* Log access: starts off as n, automatically 
+                                * goes to rwx, generating an event without
+                                * pausing the vcpu */
     HVMMEM_access_default      /* Take the domain default */
 } hvmmem_access_t;
 /* Notify that a region of memory is to have specific access types */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 22:40:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 22:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVWLb-0002Tc-GU; Tue, 29 Nov 2011 22:40:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RVWLa-0002TQ-2w
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 22:40:18 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322606376!5203638!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20692 invoked from network); 29 Nov 2011 22:39:39 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-2.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Nov 2011 22:39:39 -0000
Received: from smtp2.bendigoit.com.au ([203.16.207.99]
	helo=mail.bendigoit.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RVWKr-0000ha-1f; Wed, 30 Nov 2011 09:39:33 +1100
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 30 Nov 2011 09:39:32 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EDFF99@trantor>
In-Reply-To: <4ED510C0.8000202@hfp.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] State of GPLPV tests - 28.11.11
Thread-Index: AcyuuRQ0qh1MgRFaSEehkp8pCHodrQALndJg
References: <4ED39164.5040203@hfp.de>
	<AEC6C66638C05B468B556EA548C1A77D01EDFF48@trantor>
	<4ED510C0.8000202@hfp.de>
From: "James Harper" <james.harper@bendigoit.com.au>
To: "Andreas Kinzler" <ml-xen-devel@hfp.de>
X-Really-From-Bendigo-IT: magichashvalue
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] State of GPLPV tests - 28.11.11
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> On 29.11.2011 00:16, James Harper wrote:
> >> I am still running tests 7 days a week on two test systems. Results
> >> are quite discouraging though. After experiencing crash after crash
I
> >> wanted to test if the configuration I called "stable" (Xen 4.0.1,
> >> GPLPV 0.11.0.213, dom0 kernel
> >> 2.6.32.18-pvops0-ak3) was stable indeed. But even that config
crashed
> >> when running my torture test. It is stable on our production
systems
> >> - running other workloads of course.
> > What crash are you getting these days? Is it the same one as you
used
> > to get?
> 
> Yes, still exactly the same crashes.
> 
> Good good news: I think I have found the bug. Since I am not really a
Xen or
> Windows kernel developer it cannot say for sure but here is what I
found:
> 
> When domU hang I ran xentop and found out that the number of vbd read
> requests was an number like 0x7FFFzzzz in hex which lead me to a
thesis:
> GPLPV crashes as soon as the number of disk requests reaches 2^32. On
my
> hardware with 5000 IIOPs/sec this is reached in
> 2^32 / 5000 IIOPs / 3600 sec-per-hour / 24 hours-per-day = 9.94 days
And
> there we go: there are the 9-10 days I was always seeing.
> 
> I studied the source code of blkback/blktap/aio and found nothing. But
in
> GPLPV and its use of the ring macros I found suspicious code in every
version
> of GPLPV I ever used
> 
>    while (more_to_do)
>    {
>      rp = xvdd->ring.sring->rsp_prod;
>      KeMemoryBarrier();
>      for (i = xvdd->ring.rsp_cons; i < rp; i++)
>      {
>        rep = XenVbd_GetResponse(xvdd, i);
> 
> If now rp is 10 for example and xvdd->ring.rsp_cons is 0xFFFFFFF7 then
the
> for loop is skipped, responses are not delivered and we see the hang.
> 

Good work! I'm impressed :)

I'll get straight on that... I must have gone wrong somewhere very early
on in development.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 22:40:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 22:40:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVWLb-0002Tc-GU; Tue, 29 Nov 2011 22:40:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RVWLa-0002TQ-2w
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 22:40:18 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322606376!5203638!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20692 invoked from network); 29 Nov 2011 22:39:39 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-2.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Nov 2011 22:39:39 -0000
Received: from smtp2.bendigoit.com.au ([203.16.207.99]
	helo=mail.bendigoit.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1RVWKr-0000ha-1f; Wed, 30 Nov 2011 09:39:33 +1100
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 30 Nov 2011 09:39:32 +1100
Message-ID: <AEC6C66638C05B468B556EA548C1A77D01EDFF99@trantor>
In-Reply-To: <4ED510C0.8000202@hfp.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] State of GPLPV tests - 28.11.11
Thread-Index: AcyuuRQ0qh1MgRFaSEehkp8pCHodrQALndJg
References: <4ED39164.5040203@hfp.de>
	<AEC6C66638C05B468B556EA548C1A77D01EDFF48@trantor>
	<4ED510C0.8000202@hfp.de>
From: "James Harper" <james.harper@bendigoit.com.au>
To: "Andreas Kinzler" <ml-xen-devel@hfp.de>
X-Really-From-Bendigo-IT: magichashvalue
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] State of GPLPV tests - 28.11.11
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> On 29.11.2011 00:16, James Harper wrote:
> >> I am still running tests 7 days a week on two test systems. Results
> >> are quite discouraging though. After experiencing crash after crash
I
> >> wanted to test if the configuration I called "stable" (Xen 4.0.1,
> >> GPLPV 0.11.0.213, dom0 kernel
> >> 2.6.32.18-pvops0-ak3) was stable indeed. But even that config
crashed
> >> when running my torture test. It is stable on our production
systems
> >> - running other workloads of course.
> > What crash are you getting these days? Is it the same one as you
used
> > to get?
> 
> Yes, still exactly the same crashes.
> 
> Good good news: I think I have found the bug. Since I am not really a
Xen or
> Windows kernel developer it cannot say for sure but here is what I
found:
> 
> When domU hang I ran xentop and found out that the number of vbd read
> requests was an number like 0x7FFFzzzz in hex which lead me to a
thesis:
> GPLPV crashes as soon as the number of disk requests reaches 2^32. On
my
> hardware with 5000 IIOPs/sec this is reached in
> 2^32 / 5000 IIOPs / 3600 sec-per-hour / 24 hours-per-day = 9.94 days
And
> there we go: there are the 9-10 days I was always seeing.
> 
> I studied the source code of blkback/blktap/aio and found nothing. But
in
> GPLPV and its use of the ring macros I found suspicious code in every
version
> of GPLPV I ever used
> 
>    while (more_to_do)
>    {
>      rp = xvdd->ring.sring->rsp_prod;
>      KeMemoryBarrier();
>      for (i = xvdd->ring.rsp_cons; i < rp; i++)
>      {
>        rep = XenVbd_GetResponse(xvdd, i);
> 
> If now rp is 10 for example and xvdd->ring.rsp_cons is 0xFFFFFFF7 then
the
> for loop is skipped, responses are not delivered and we see the hang.
> 

Good work! I'm impressed :)

I'll get straight on that... I must have gone wrong somewhere very early
on in development.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 23:03:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 23:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVWhT-0003ly-MP; Tue, 29 Nov 2011 23:02:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVWhS-0003lj-Tx
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 23:02:55 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322607735!5208243!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15013 invoked from network); 29 Nov 2011 23:02:16 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 23:02:16 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATN2CmP026354
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 18:02:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATN2CcE026351;
	Tue, 29 Nov 2011 18:02:12 -0500
Date: Tue, 29 Nov 2011 19:02:12 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Message-ID: <20111129230212.GA23958@andromeda.dapyr.net>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED5215D.1010403@hfp.de>
User-Agent: Mutt/1.5.9i
Cc: Roderick Colenbrander <thunderbird2k@gmail.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 07:15:57PM +0100, Andreas Kinzler wrote:
> >>Not in this year of my stability tests. In this year I am always
> >>experiencing crashes of domU only. dom0 was always stable.
> >>But last year, I hunted a very serious problem which causes nasty
> >>hangs/crashes in dom0 (which crashes domU as a consequence). See this
> >>mailing list post:
> >>http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
> >>In my tests it clearly shows that if you have a CPU without ARAT and you
> >>don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash 
> >>under
> >>load and/or after a while. What is your CPU?
> >Most of our machines use i7 950 CPUs. They don't seem to have ARAT.
> 
> Yes, i7 950 does not have ARAT as it is the first Nehalem generation.
> 
> >Some other machines use Xeon CPUs with ARAT support. We never had
> >issues on the Xeon systems, so we may actually be suffering from the
> >ARAT issue. Are you still using the patch you linked to in a
> >production environment?
> 
> Absolutely. As I mentioned I just re-performed tests recently and found 
> that even Xen 4.1.1 (earlier tests were for 4.0.1) is unstable without 
> my patch on non-ARAT-CPUs.

Did you try 4.1.2? This looks quite similar to one particular bug where
the vectors were not migrated properly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 23:03:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 23:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVWhT-0003ly-MP; Tue, 29 Nov 2011 23:02:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVWhS-0003lj-Tx
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 23:02:55 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322607735!5208243!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15013 invoked from network); 29 Nov 2011 23:02:16 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 23:02:16 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATN2CmP026354
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 18:02:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATN2CcE026351;
	Tue, 29 Nov 2011 18:02:12 -0500
Date: Tue, 29 Nov 2011 19:02:12 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andreas Kinzler <ml-xen-devel@hfp.de>
Message-ID: <20111129230212.GA23958@andromeda.dapyr.net>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED5215D.1010403@hfp.de>
User-Agent: Mutt/1.5.9i
Cc: Roderick Colenbrander <thunderbird2k@gmail.com>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 07:15:57PM +0100, Andreas Kinzler wrote:
> >>Not in this year of my stability tests. In this year I am always
> >>experiencing crashes of domU only. dom0 was always stable.
> >>But last year, I hunted a very serious problem which causes nasty
> >>hangs/crashes in dom0 (which crashes domU as a consequence). See this
> >>mailing list post:
> >>http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
> >>In my tests it clearly shows that if you have a CPU without ARAT and you
> >>don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash 
> >>under
> >>load and/or after a while. What is your CPU?
> >Most of our machines use i7 950 CPUs. They don't seem to have ARAT.
> 
> Yes, i7 950 does not have ARAT as it is the first Nehalem generation.
> 
> >Some other machines use Xeon CPUs with ARAT support. We never had
> >issues on the Xeon systems, so we may actually be suffering from the
> >ARAT issue. Are you still using the patch you linked to in a
> >production environment?
> 
> Absolutely. As I mentioned I just re-performed tests recently and found 
> that even Xen 4.1.1 (earlier tests were for 4.0.1) is unstable without 
> my patch on non-ARAT-CPUs.

Did you try 4.1.2? This looks quite similar to one particular bug where
the vectors were not migrated properly.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 23:25:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 23:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVX2c-0004Lt-Gq; Tue, 29 Nov 2011 23:24:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVX2b-0004Lo-KN
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 23:24:45 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322609002!58825313!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28649 invoked from network); 29 Nov 2011 23:23:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 23:23:23 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATNO7EM029387
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 18:24:07 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATNO4Br029380;
	Tue, 29 Nov 2011 18:24:04 -0500
Date: Tue, 29 Nov 2011 19:24:04 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Bastian Blank <bastian@waldi.eu.org>, xen-devel@lists.xensource.com
Message-ID: <20111129232404.GD23958@andromeda.dapyr.net>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-2-git-send-email-waldi@debian.org>
	<20111128181439.GB21369@andromeda.dapyr.net>
	<20111128183830.GC6828@wavehammer.waldi.eu.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111128183830.GC6828@wavehammer.waldi.eu.org>
User-Agent: Mutt/1.5.9i
Subject: Re: [Xen-devel] [PATCH 1/5] xen/sys/hypervisor: Export
	guest_properties/is_initial_domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 07:38:30PM +0100, Bastian Blank wrote:
> On Mon, Nov 28, 2011 at 02:14:39PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Sun, Nov 27, 2011 at 11:07:04PM +0100, Bastian Blank wrote:
> > > diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> > > index 1e0fe01..d0916e8 100644
> > > --- a/drivers/xen/sys-hypervisor.c
> > > +++ b/drivers/xen/sys-hypervisor.c
> > > @@ -355,6 +355,35 @@ static void xen_properties_destroy(void)
> > >  	sysfs_remove_group(hypervisor_kobj, &xen_properties_group);
> > >  }
> > >  
> > > +/* xen guest properties info */
> > 
> > Properties is plural, but this is a single attribute.
> 
> Just like the old /proc/xen/capabilites, it only supported one attribute
> ever. However it could export a flag for hvm domain.
> 
> >                      Perhaps the name 'is_initial_domain' would be a
> > better name?
> 
> It is already called this was.

Ah yes. Somehow I was thinking it was guest_properties.
> 
> >              What is the purpose of this attribute?
> 
> Replace /proc/xen/capabilities. See
> <20100605162947.GA31336@wavehammer.waldi.eu.org>
> 
> >                                                     Who/what tools
> > benefit from this?
> 
> The init scripts are the only users.
> 
> Bastian
> 
> -- 
> Deflector shields just came on, Captain.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 23:25:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 23:25:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVX2c-0004Lt-Gq; Tue, 29 Nov 2011 23:24:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVX2b-0004Lo-KN
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 23:24:45 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322609002!58825313!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28649 invoked from network); 29 Nov 2011 23:23:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Nov 2011 23:23:23 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pATNO7EM029387
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 29 Nov 2011 18:24:07 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pATNO4Br029380;
	Tue, 29 Nov 2011 18:24:04 -0500
Date: Tue, 29 Nov 2011 19:24:04 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Bastian Blank <bastian@waldi.eu.org>, xen-devel@lists.xensource.com
Message-ID: <20111129232404.GD23958@andromeda.dapyr.net>
References: <1322431628-21760-1-git-send-email-waldi@debian.org>
	<1322431628-21760-2-git-send-email-waldi@debian.org>
	<20111128181439.GB21369@andromeda.dapyr.net>
	<20111128183830.GC6828@wavehammer.waldi.eu.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111128183830.GC6828@wavehammer.waldi.eu.org>
User-Agent: Mutt/1.5.9i
Subject: Re: [Xen-devel] [PATCH 1/5] xen/sys/hypervisor: Export
	guest_properties/is_initial_domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Nov 28, 2011 at 07:38:30PM +0100, Bastian Blank wrote:
> On Mon, Nov 28, 2011 at 02:14:39PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Sun, Nov 27, 2011 at 11:07:04PM +0100, Bastian Blank wrote:
> > > diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
> > > index 1e0fe01..d0916e8 100644
> > > --- a/drivers/xen/sys-hypervisor.c
> > > +++ b/drivers/xen/sys-hypervisor.c
> > > @@ -355,6 +355,35 @@ static void xen_properties_destroy(void)
> > >  	sysfs_remove_group(hypervisor_kobj, &xen_properties_group);
> > >  }
> > >  
> > > +/* xen guest properties info */
> > 
> > Properties is plural, but this is a single attribute.
> 
> Just like the old /proc/xen/capabilites, it only supported one attribute
> ever. However it could export a flag for hvm domain.
> 
> >                      Perhaps the name 'is_initial_domain' would be a
> > better name?
> 
> It is already called this was.

Ah yes. Somehow I was thinking it was guest_properties.
> 
> >              What is the purpose of this attribute?
> 
> Replace /proc/xen/capabilities. See
> <20100605162947.GA31336@wavehammer.waldi.eu.org>
> 
> >                                                     Who/what tools
> > benefit from this?
> 
> The init scripts are the only users.
> 
> Bastian
> 
> -- 
> Deflector shields just came on, Captain.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 23:56:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 23:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVXWz-0005QR-NI; Tue, 29 Nov 2011 23:56:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RVXWy-0005QM-Ep
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 23:56:08 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322610930!4675649!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6873 invoked from network); 29 Nov 2011 23:55:30 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-13.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 23:55:30 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RVXWL-0004N5-H7
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 23:55:29 +0000
Received: from mail-yx0-f176.google.com ([209.85.213.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RVXWL-0004Mw-Ah for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Tue, 29 Nov 2011 23:55:29 +0000
Received: by yenl9 with SMTP id l9so7900120yen.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Tue, 29 Nov 2011 15:55:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=SfnZclFRpYS6kG/7JG8xuiKDajUzE6I1fTR/7UMuRI8=;
	b=SYOlZF33urNxOp3dUe29yFo/ndA0WhyhjAHBVHGId8gb6PCTOm8Nce/Mw8SiktKUa3
	+IsFDQkZxCOddSPYM9bRwi0YqxCPXeF9KS6cBggY6c5wZU6wRbW/0vXZleD6UbnhSuWb
	yxJ5VcYK3+kpFUzAwzZ1N0Lt4Qpy2N+Lrk9Rg=
MIME-Version: 1.0
Received: by 10.182.141.68 with SMTP id rm4mr14154580obb.23.1322610927042;
	Tue, 29 Nov 2011 15:55:27 -0800 (PST)
Received: by 10.182.35.167 with HTTP; Tue, 29 Nov 2011 15:55:26 -0800 (PST)
Date: Tue, 29 Nov 2011 15:55:26 -0800
Message-ID: <CACm5R6QXOyCDpzROOaeg=6e+jntyuA4C7BkhJRdXMSAVgmKh=w@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Wiki SPAM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

http://wiki.xen.org/wiki/The_best_way_to_Download_Free_Nintendo_Ds_Game_titles
http://wiki.xen.org/wiki/The_Reasons_Why_The_Stokke_Sleepi_Bedding_Selection_Is_Better_To_Get

And then, there's these two:
http://wiki.xen.org/wiki/McClurg
http://wiki.xen.org/wiki/Trash

which may not be SPAM, but are not very useful in the Main wiki namespace.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Nov 29 23:56:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 29 Nov 2011 23:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVXWz-0005QR-NI; Tue, 29 Nov 2011 23:56:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RVXWy-0005QM-Ep
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 23:56:08 +0000
X-Env-Sender: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322610930!4675649!1
X-Originating-IP: [216.75.62.102]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6873 invoked from network); 29 Nov 2011 23:55:30 -0000
Received: from gourmet7.spamgourmet.com (HELO gourmet8.spamgourmet.com)
	(216.75.62.102) by server-13.tower-182.messagelabs.com with SMTP;
	29 Nov 2011 23:55:30 -0000
Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RVXWL-0004N5-H7
	for xen-devel@lists.xensource.com; Tue, 29 Nov 2011 23:55:29 +0000
Received: from mail-yx0-f176.google.com ([209.85.213.176])
	by gourmet7.spamgourmet.com with esmtp (Exim 4.69)
	(envelope-from <xen-devel.GarveyPatrickD@OrdinaryAmerican.net>)
	id 1RVXWL-0004Mw-Ah for
	+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com;
	Tue, 29 Nov 2011 23:55:29 +0000
Received: by yenl9 with SMTP id l9so7900120yen.7 for
	<+xen-devel+GarveyPatrickD+fbe7693c78.xen-devel#lists.xensource.com@spamgourmet.com>;
	Tue, 29 Nov 2011 15:55:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=SfnZclFRpYS6kG/7JG8xuiKDajUzE6I1fTR/7UMuRI8=;
	b=SYOlZF33urNxOp3dUe29yFo/ndA0WhyhjAHBVHGId8gb6PCTOm8Nce/Mw8SiktKUa3
	+IsFDQkZxCOddSPYM9bRwi0YqxCPXeF9KS6cBggY6c5wZU6wRbW/0vXZleD6UbnhSuWb
	yxJ5VcYK3+kpFUzAwzZ1N0Lt4Qpy2N+Lrk9Rg=
MIME-Version: 1.0
Received: by 10.182.141.68 with SMTP id rm4mr14154580obb.23.1322610927042;
	Tue, 29 Nov 2011 15:55:27 -0800 (PST)
Received: by 10.182.35.167 with HTTP; Tue, 29 Nov 2011 15:55:26 -0800 (PST)
Date: Tue, 29 Nov 2011 15:55:26 -0800
Message-ID: <CACm5R6QXOyCDpzROOaeg=6e+jntyuA4C7BkhJRdXMSAVgmKh=w@mail.gmail.com>
From: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
To: xen-devel@lists.xensource.com
X-Spamgourmet: 
Subject: [Xen-devel] Wiki SPAM
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

http://wiki.xen.org/wiki/The_best_way_to_Download_Free_Nintendo_Ds_Game_titles
http://wiki.xen.org/wiki/The_Reasons_Why_The_Stokke_Sleepi_Bedding_Selection_Is_Better_To_Get

And then, there's these two:
http://wiki.xen.org/wiki/McClurg
http://wiki.xen.org/wiki/Trash

which may not be SPAM, but are not very useful in the Main wiki namespace.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 00:03:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 00:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVXdA-00066v-Iu; Wed, 30 Nov 2011 00:02:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RVXd8-00066f-NS
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 00:02:30 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322611310!3619074!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14314 invoked from network); 30 Nov 2011 00:01:52 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 00:01:52 -0000
Received: by ghbz2 with SMTP id z2so38351ghb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 16:01:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=7NqAc3yQq5NwdWdeYhuoSfKkM3Q9oi2l84K0Ac3Rl2o=;
	b=d3y46ATVg1AvosAnd7CcTGTBWRpMyt66EfNqHrPMCELPg+iRkTcogsBMq+PjKnK0Ei
	gGtNPTDiGyvW6N8hMzgxRFF00K6aBrkqJ84uS9Q8FCeBSkEYrDT7CFUGA1ZjJWHDoJ7A
	EdMhmi0EkYs7+nRcTrcSdVxeJCf+4bCdkKIT8=
MIME-Version: 1.0
Received: by 10.100.189.15 with SMTP id m15mr1129481anf.148.1322611309739;
	Tue, 29 Nov 2011 16:01:49 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Tue, 29 Nov 2011 16:01:49 -0800 (PST)
In-Reply-To: <20111129230212.GA23958@andromeda.dapyr.net>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
Date: Tue, 29 Nov 2011 16:01:49 -0800
Message-ID: <CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 3:02 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Tue, Nov 29, 2011 at 07:15:57PM +0100, Andreas Kinzler wrote:
>> >>Not in this year of my stability tests. In this year I am always
>> >>experiencing crashes of domU only. dom0 was always stable.
>> >>But last year, I hunted a very serious problem which causes nasty
>> >>hangs/crashes in dom0 (which crashes domU as a consequence). See this
>> >>mailing list post:
>> >>http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
>> >>In my tests it clearly shows that if you have a CPU without ARAT and you
>> >>don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash
>> >>under
>> >>load and/or after a while. What is your CPU?
>> >Most of our machines use i7 950 CPUs. They don't seem to have ARAT.
>>
>> Yes, i7 950 does not have ARAT as it is the first Nehalem generation.
>>
>> >Some other machines use Xeon CPUs with ARAT support. We never had
>> >issues on the Xeon systems, so we may actually be suffering from the
>> >ARAT issue. Are you still using the patch you linked to in a
>> >production environment?
>>
>> Absolutely. As I mentioned I just re-performed tests recently and found
>> that even Xen 4.1.1 (earlier tests were for 4.0.1) is unstable without
>> my patch on non-ARAT-CPUs.
>
> Did you try 4.1.2? This looks quite similar to one particular bug where
> the vectors were not migrated properly.

I haven't tried Xen 4.1.2 yet. We likely had the issue on Xen 4.0.1
though our data is not conclusive. Was the Xen 4.1.2 bug you refer to
also around in Xen 4.0.1?

I'm still preparing our tests. Is there any special logging option
which would be useful to log anything? All systems are now setup with
serial consoles and we log Xen and Dom0 to there.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 00:03:01 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 00:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVXdA-00066v-Iu; Wed, 30 Nov 2011 00:02:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RVXd8-00066f-NS
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 00:02:30 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1322611310!3619074!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14314 invoked from network); 30 Nov 2011 00:01:52 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 00:01:52 -0000
Received: by ghbz2 with SMTP id z2so38351ghb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 16:01:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=7NqAc3yQq5NwdWdeYhuoSfKkM3Q9oi2l84K0Ac3Rl2o=;
	b=d3y46ATVg1AvosAnd7CcTGTBWRpMyt66EfNqHrPMCELPg+iRkTcogsBMq+PjKnK0Ei
	gGtNPTDiGyvW6N8hMzgxRFF00K6aBrkqJ84uS9Q8FCeBSkEYrDT7CFUGA1ZjJWHDoJ7A
	EdMhmi0EkYs7+nRcTrcSdVxeJCf+4bCdkKIT8=
MIME-Version: 1.0
Received: by 10.100.189.15 with SMTP id m15mr1129481anf.148.1322611309739;
	Tue, 29 Nov 2011 16:01:49 -0800 (PST)
Received: by 10.100.48.10 with HTTP; Tue, 29 Nov 2011 16:01:49 -0800 (PST)
In-Reply-To: <20111129230212.GA23958@andromeda.dapyr.net>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<20111129230212.GA23958@andromeda.dapyr.net>
Date: Tue, 29 Nov 2011 16:01:49 -0800
Message-ID: <CAEc3jaAO0JhtOt6phQHwtE_A+NF7uGHGZ8uJv3BirEYybfVceg@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, Andreas Kinzler <ml-xen-devel@hfp.de>
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, 2011 at 3:02 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Tue, Nov 29, 2011 at 07:15:57PM +0100, Andreas Kinzler wrote:
>> >>Not in this year of my stability tests. In this year I am always
>> >>experiencing crashes of domU only. dom0 was always stable.
>> >>But last year, I hunted a very serious problem which causes nasty
>> >>hangs/crashes in dom0 (which crashes domU as a consequence). See this
>> >>mailing list post:
>> >>http://lists.xen.org/archives/html/xen-devel/2010-09/msg00556.html
>> >>In my tests it clearly shows that if you have a CPU without ARAT and you
>> >>don't have the patch from my post, your Xen 4.0.1 or 4.1.1 will crash
>> >>under
>> >>load and/or after a while. What is your CPU?
>> >Most of our machines use i7 950 CPUs. They don't seem to have ARAT.
>>
>> Yes, i7 950 does not have ARAT as it is the first Nehalem generation.
>>
>> >Some other machines use Xeon CPUs with ARAT support. We never had
>> >issues on the Xeon systems, so we may actually be suffering from the
>> >ARAT issue. Are you still using the patch you linked to in a
>> >production environment?
>>
>> Absolutely. As I mentioned I just re-performed tests recently and found
>> that even Xen 4.1.1 (earlier tests were for 4.0.1) is unstable without
>> my patch on non-ARAT-CPUs.
>
> Did you try 4.1.2? This looks quite similar to one particular bug where
> the vectors were not migrated properly.

I haven't tried Xen 4.1.2 yet. We likely had the issue on Xen 4.0.1
though our data is not conclusive. Was the Xen 4.1.2 bug you refer to
also around in Xen 4.0.1?

I'm still preparing our tests. Is there any special logging option
which would be useful to log anything? All systems are now setup with
serial consoles and we log Xen and Dom0 to there.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 00:33:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 00:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVY6f-0006Ov-AT; Wed, 30 Nov 2011 00:33:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVY6e-0006Oi-I3
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 00:33:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322613141!6150822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTEzNA==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11021 invoked from network); 30 Nov 2011 00:32:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 00:32:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,594,1315180800"; 
   d="scan'208";a="9195765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 00:32:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 00:32:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVY5u-0007HF-Q4;
	Wed, 30 Nov 2011 00:32:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVY5u-0004hZ-Ph;
	Wed, 30 Nov 2011 00:32:14 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10185-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 00:32:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10185: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10185 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10185/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  df7cec2c6c03
baseline version:
 xen                  a2cb7ed6d0a2

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Zhou Peng <zhoupeng@nfs.iscas.ac.cn>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=df7cec2c6c03
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable df7cec2c6c03
+ branch=xen-unstable
+ revision=df7cec2c6c03
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r df7cec2c6c03 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 24 changesets with 57 changes to 28 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 00:33:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 00:33:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVY6f-0006Ov-AT; Wed, 30 Nov 2011 00:33:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVY6e-0006Oi-I3
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 00:33:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1322613141!6150822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTEzNA==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11021 invoked from network); 30 Nov 2011 00:32:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 00:32:22 -0000
X-IronPort-AV: E=Sophos;i="4.69,594,1315180800"; 
   d="scan'208";a="9195765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 00:32:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 00:32:15 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVY5u-0007HF-Q4;
	Wed, 30 Nov 2011 00:32:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVY5u-0004hZ-Ph;
	Wed, 30 Nov 2011 00:32:14 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10185-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 00:32:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10185: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10185 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10185/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  df7cec2c6c03
baseline version:
 xen                  a2cb7ed6d0a2

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
  Zhou Peng <zhoupeng@nfs.iscas.ac.cn>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=df7cec2c6c03
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable df7cec2c6c03
+ branch=xen-unstable
+ revision=df7cec2c6c03
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r df7cec2c6c03 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 24 changesets with 57 changes to 28 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 01:40:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 01:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVZ9O-0003Lj-EN; Wed, 30 Nov 2011 01:39:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netlogic.xen@gmail.com>) id 1RVZ9M-0003Le-S9
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 01:39:53 +0000
X-Env-Sender: netlogic.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322616770!54234808!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11912 invoked from network); 30 Nov 2011 01:32:51 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 01:32:51 -0000
Received: by ywt34 with SMTP id 34so148105ywt.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 17:34:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=2PY3uC+e+i4+fH0YG1ksJFekF8ucS24X8Wry//UzT7A=;
	b=PTjA7XwgTyxH92f+SmoOHPYWI05fabC9qAALa/QWxg8loeUA90BkmLgY7IxtrLP9Lx
	OYrM8WOrBCtf7LpxJbc14Q1Nimb2CsPTth/JiwjRd2JbO74eclTh5AABgyjriOGEmLWj
	XDWhHTTMaEnnX8bAI5G/px+q4Vq+SzxrN0Z7U=
MIME-Version: 1.0
Received: by 10.68.52.104 with SMTP id s8mr2613634pbo.20.1322616875422; Tue,
	29 Nov 2011 17:34:35 -0800 (PST)
Received: by 10.142.234.10 with HTTP; Tue, 29 Nov 2011 17:34:35 -0800 (PST)
In-Reply-To: <1321459710.3664.194.camel@zakaz.uk.xensource.com>
References: <CAPw52B9wm-2VfRcLRhRBgpjDmgwU5LqNryZ0pLpNALF+eYpitQ@mail.gmail.com>
	<1317884089.24742.9.camel@dagon.hellion.org.uk>
	<CAPw52B_-K5Hy+Wo3UnarYoAb85WLhxTb4KtfByMPpL5_g+COVQ@mail.gmail.com>
	<1318411454.21903.606.camel@zakaz.uk.xensource.com>
	<CAPw52B9EEg_xHbFOCQmHDmW0evi0F6kFkronYSAAjz6ifXx72Q@mail.gmail.com>
	<1320743395.955.44.camel@zakaz.uk.xensource.com>
	<CAPw52B9c475fYmbT5e41OcLmbTyOkxPbzG6sa9pJKjDAbH=yqQ@mail.gmail.com>
	<1321459710.3664.194.camel@zakaz.uk.xensource.com>
Date: Tue, 29 Nov 2011 17:34:35 -0800
Message-ID: <CAPw52B-9cq4TMrXnZ8Loxng=nUiwNfDs37A=HPyJ5_ed7wP6bw@mail.gmail.com>
From: Prasad B <netlogic.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] reg dom0 console
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3810882472830861502=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3810882472830861502==
Content-Type: multipart/alternative; boundary=bcaec543079408957204b2e9bd5b

--bcaec543079408957204b2e9bd5b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 16, 2011 at 8:08 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:


> xl just execs /usr/lib/xen/bin/xenconsole to talk to the console.
>
> xenconsole is just a client for xenconsoled which is the daemon which
> actually consumes guest consoles. The source for both is in
> tools/console.
>
> My memory is fuzzy but IIRC the toolstack writes the
> keys /local/domain/<DOMID>/console/{ring-ref,port} to xenstore which
> xenconsoled picks up in order to communicate with the domain. The guest
> gets its end of things from the startinfo.
>

Thanks Ian. We currently have both dom0 and domU versions of MIPS Linux up
and running. However, we are in the process of connecting to domU through
xenconsole. In the interim, domU too uses dom0 console functions and so the
bootup process of domU could be seen. When domU's console functions are
switched to write to the domU console page, domU output (after early printk
usage) could not be read through "xl console <domId>" command. The sequence
of commands are

xenstored -D
xenconsoled
xl create domU.config
xl console 1

It was ensured that domU console page and its event channel descriptor were
allocated correctly in domU. Is there anything else that needs to be plumb
the connection between dom0 and domU ? Could any other controlled test be
run to ensure that all the required steps are done ?

thank you,
Prasad.

--bcaec543079408957204b2e9bd5b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Nov 16, 2011 at 8:08 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><div>=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(20=
4, 204, 204); padding-left: 1ex;">
xl just execs /usr/lib/xen/bin/xenconsole to talk to the console.<br>
<br>
xenconsole is just a client for xenconsoled which is the daemon which<br>
actually consumes guest consoles. The source for both is in<br>
tools/console.<br>
<br>
My memory is fuzzy but IIRC the toolstack writes the<br>
keys /local/domain/&lt;DOMID&gt;/console/{ring-ref,port} to xenstore which<=
br>
xenconsoled picks up in order to communicate with the domain. The guest<br>
gets its end of things from the startinfo.<br></blockquote><div><br>Thanks =
Ian. We currently have both dom0 and domU versions of MIPS Linux up and run=
ning. However, we are in the process of connecting to domU through xenconso=
le. In the interim, domU too uses dom0 console functions and so the bootup =
process of domU could be seen. When domU&#39;s console functions are switch=
ed to write to the domU console page, domU output (after early printk usage=
) could not be read through &quot;xl console &lt;domId&gt;&quot; command. T=
he sequence of commands are<br>
<br>xenstored -D<br>xenconsoled<br>xl create domU.config<br>xl console 1<br=
><br>It was ensured that domU console page and its event channel descriptor=
 were allocated correctly in domU. Is there anything else that needs to be =
plumb the connection between dom0 and domU ? Could any other controlled tes=
t be run to ensure that all the required steps are done ?<br>
<br>thank you,<br>Prasad.<br></div></div>

--bcaec543079408957204b2e9bd5b--


--===============3810882472830861502==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3810882472830861502==--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 01:40:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 01:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVZ9O-0003Lj-EN; Wed, 30 Nov 2011 01:39:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netlogic.xen@gmail.com>) id 1RVZ9M-0003Le-S9
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 01:39:53 +0000
X-Env-Sender: netlogic.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1322616770!54234808!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11912 invoked from network); 30 Nov 2011 01:32:51 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 01:32:51 -0000
Received: by ywt34 with SMTP id 34so148105ywt.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 17:34:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=2PY3uC+e+i4+fH0YG1ksJFekF8ucS24X8Wry//UzT7A=;
	b=PTjA7XwgTyxH92f+SmoOHPYWI05fabC9qAALa/QWxg8loeUA90BkmLgY7IxtrLP9Lx
	OYrM8WOrBCtf7LpxJbc14Q1Nimb2CsPTth/JiwjRd2JbO74eclTh5AABgyjriOGEmLWj
	XDWhHTTMaEnnX8bAI5G/px+q4Vq+SzxrN0Z7U=
MIME-Version: 1.0
Received: by 10.68.52.104 with SMTP id s8mr2613634pbo.20.1322616875422; Tue,
	29 Nov 2011 17:34:35 -0800 (PST)
Received: by 10.142.234.10 with HTTP; Tue, 29 Nov 2011 17:34:35 -0800 (PST)
In-Reply-To: <1321459710.3664.194.camel@zakaz.uk.xensource.com>
References: <CAPw52B9wm-2VfRcLRhRBgpjDmgwU5LqNryZ0pLpNALF+eYpitQ@mail.gmail.com>
	<1317884089.24742.9.camel@dagon.hellion.org.uk>
	<CAPw52B_-K5Hy+Wo3UnarYoAb85WLhxTb4KtfByMPpL5_g+COVQ@mail.gmail.com>
	<1318411454.21903.606.camel@zakaz.uk.xensource.com>
	<CAPw52B9EEg_xHbFOCQmHDmW0evi0F6kFkronYSAAjz6ifXx72Q@mail.gmail.com>
	<1320743395.955.44.camel@zakaz.uk.xensource.com>
	<CAPw52B9c475fYmbT5e41OcLmbTyOkxPbzG6sa9pJKjDAbH=yqQ@mail.gmail.com>
	<1321459710.3664.194.camel@zakaz.uk.xensource.com>
Date: Tue, 29 Nov 2011 17:34:35 -0800
Message-ID: <CAPw52B-9cq4TMrXnZ8Loxng=nUiwNfDs37A=HPyJ5_ed7wP6bw@mail.gmail.com>
From: Prasad B <netlogic.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] reg dom0 console
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3810882472830861502=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3810882472830861502==
Content-Type: multipart/alternative; boundary=bcaec543079408957204b2e9bd5b

--bcaec543079408957204b2e9bd5b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 16, 2011 at 8:08 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:


> xl just execs /usr/lib/xen/bin/xenconsole to talk to the console.
>
> xenconsole is just a client for xenconsoled which is the daemon which
> actually consumes guest consoles. The source for both is in
> tools/console.
>
> My memory is fuzzy but IIRC the toolstack writes the
> keys /local/domain/<DOMID>/console/{ring-ref,port} to xenstore which
> xenconsoled picks up in order to communicate with the domain. The guest
> gets its end of things from the startinfo.
>

Thanks Ian. We currently have both dom0 and domU versions of MIPS Linux up
and running. However, we are in the process of connecting to domU through
xenconsole. In the interim, domU too uses dom0 console functions and so the
bootup process of domU could be seen. When domU's console functions are
switched to write to the domU console page, domU output (after early printk
usage) could not be read through "xl console <domId>" command. The sequence
of commands are

xenstored -D
xenconsoled
xl create domU.config
xl console 1

It was ensured that domU console page and its event channel descriptor were
allocated correctly in domU. Is there anything else that needs to be plumb
the connection between dom0 and domU ? Could any other controlled test be
run to ensure that all the required steps are done ?

thank you,
Prasad.

--bcaec543079408957204b2e9bd5b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Nov 16, 2011 at 8:08 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><div>=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(20=
4, 204, 204); padding-left: 1ex;">
xl just execs /usr/lib/xen/bin/xenconsole to talk to the console.<br>
<br>
xenconsole is just a client for xenconsoled which is the daemon which<br>
actually consumes guest consoles. The source for both is in<br>
tools/console.<br>
<br>
My memory is fuzzy but IIRC the toolstack writes the<br>
keys /local/domain/&lt;DOMID&gt;/console/{ring-ref,port} to xenstore which<=
br>
xenconsoled picks up in order to communicate with the domain. The guest<br>
gets its end of things from the startinfo.<br></blockquote><div><br>Thanks =
Ian. We currently have both dom0 and domU versions of MIPS Linux up and run=
ning. However, we are in the process of connecting to domU through xenconso=
le. In the interim, domU too uses dom0 console functions and so the bootup =
process of domU could be seen. When domU&#39;s console functions are switch=
ed to write to the domU console page, domU output (after early printk usage=
) could not be read through &quot;xl console &lt;domId&gt;&quot; command. T=
he sequence of commands are<br>
<br>xenstored -D<br>xenconsoled<br>xl create domU.config<br>xl console 1<br=
><br>It was ensured that domU console page and its event channel descriptor=
 were allocated correctly in domU. Is there anything else that needs to be =
plumb the connection between dom0 and domU ? Could any other controlled tes=
t be run to ensure that all the required steps are done ?<br>
<br>thank you,<br>Prasad.<br></div></div>

--bcaec543079408957204b2e9bd5b--


--===============3810882472830861502==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3810882472830861502==--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 02:56:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 02:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVaLE-0004UM-QP; Wed, 30 Nov 2011 02:56:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RVaLC-0004UD-HN
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 02:56:10 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322621730!4685751!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA2MTc1\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2672 invoked from network); 30 Nov 2011 02:55:31 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-182.messagelabs.com with SMTP;
	30 Nov 2011 02:55:31 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 29 Nov 2011 18:55:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.69,595,1315206000"; d="scan'208";a="42340027"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by AZSMGA002.ch.intel.com with ESMTP; 29 Nov 2011 18:55:20 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 30 Nov 2011 10:53:52 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 30 Nov 2011 10:53:52 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Wed, 30 Nov 2011 10:53:51 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 30 Nov 2011 10:53:48 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcytogY9JOWjbFW2Qhy2Xb/FBKvaNABAl/QQ
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E28707E67E4@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
	<4ED34AA2020000780006394D@nat28.tlf.novell.com>
In-Reply-To: <4ED34AA2020000780006394D@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> This patch disable PCID/INVPCID for dom0.
>>> 
>>> Do we really need to disable it, rather than making it work?
>>> Conceptually the feature seems usable, and the instruction would
>>> need replacement by a hypercall anyway (just like invlpg).
>> 
>> It's a design choice.
>> Exposing PCID/INVPCID to pv would involve some additional task, like
>> coordinated PCID allocation algorithm, or change vmm vcpu context
>> swich, which would make it complex. However, exposing PCID/INVPCID
>> to pv has not obvious benefit or even result in performance
>> regression. 
> 
> Would you mind elaborating on that statement?
> 
> Jan

For pv, if expose PCID to pv, the PCIDs of different pv domain may conflict, which make processor confused at TLB.
To make PCID work at pv, it need
1, either a coordinated PCID allocation algorithm, so that the local PCID of pv domain can be changed to a global unique PCID;
2, or, a 'clean' vcpu context switch logic to flush all TLB;
method 1 make things complex w/o obvious benefit;
method 2 need change current vcpu context switch logic (i.e, mov cr3 only flush TLB entries of specific PCID if PCID enabled), and if flush *all* TLB is required at context switch, we lose the change to optimize context switch by partly flush TLB case by case, which may result in performance regression;

Thanks,
Jinsong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 02:56:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 02:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVaLE-0004UM-QP; Wed, 30 Nov 2011 02:56:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1RVaLC-0004UD-HN
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 02:56:10 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322621730!4685751!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA2MTc1\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2672 invoked from network); 30 Nov 2011 02:55:31 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-13.tower-182.messagelabs.com with SMTP;
	30 Nov 2011 02:55:31 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 29 Nov 2011 18:55:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.69,595,1315206000"; d="scan'208";a="42340027"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by AZSMGA002.ch.intel.com with ESMTP; 29 Nov 2011 18:55:20 -0800
Received: from pgsmsx102.gar.corp.intel.com (10.221.44.80) by
	pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 30 Nov 2011 10:53:52 +0800
Received: from shsmsx601.ccr.corp.intel.com (10.239.4.112) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 30 Nov 2011 10:53:52 +0800
Received: from shsmsx502.ccr.corp.intel.com ([10.239.4.96]) by
	shsmsx601.ccr.corp.intel.com ([10.239.4.112]) with mapi;
	Wed, 30 Nov 2011 10:53:51 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 30 Nov 2011 10:53:48 +0800
Thread-Topic: [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
Thread-Index: AcytogY9JOWjbFW2Qhy2Xb/FBKvaNABAl/QQ
Message-ID: <BC00F5384FCFC9499AF06F92E8B78A9E28707E67E4@shsmsx502.ccr.corp.intel.com>
References: <BC00F5384FCFC9499AF06F92E8B78A9E2867CF9A7E@shsmsx502.ccr.corp.intel.com>
	<4ECFA6C302000078000634A1@nat28.tlf.novell.com>
	<BC00F5384FCFC9499AF06F92E8B78A9E286DAED1B8@shsmsx502.ccr.corp.intel.com>
	<4ED34AA2020000780006394D@nat28.tlf.novell.com>
In-Reply-To: <4ED34AA2020000780006394D@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 3/6] X86: Disable PCID/INVPCID for dom0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich wrote:
>>>> On 27.11.11 at 11:16, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan Beulich wrote:
>>>>>> On 24.11.11 at 16:53, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>>>> wrote: 
>>>> This patch disable PCID/INVPCID for dom0.
>>> 
>>> Do we really need to disable it, rather than making it work?
>>> Conceptually the feature seems usable, and the instruction would
>>> need replacement by a hypercall anyway (just like invlpg).
>> 
>> It's a design choice.
>> Exposing PCID/INVPCID to pv would involve some additional task, like
>> coordinated PCID allocation algorithm, or change vmm vcpu context
>> swich, which would make it complex. However, exposing PCID/INVPCID
>> to pv has not obvious benefit or even result in performance
>> regression. 
> 
> Would you mind elaborating on that statement?
> 
> Jan

For pv, if expose PCID to pv, the PCIDs of different pv domain may conflict, which make processor confused at TLB.
To make PCID work at pv, it need
1, either a coordinated PCID allocation algorithm, so that the local PCID of pv domain can be changed to a global unique PCID;
2, or, a 'clean' vcpu context switch logic to flush all TLB;
method 1 make things complex w/o obvious benefit;
method 2 need change current vcpu context switch logic (i.e, mov cr3 only flush TLB entries of specific PCID if PCID enabled), and if flush *all* TLB is required at context switch, we lose the change to optimize context switch by partly flush TLB case by case, which may result in performance regression;

Thanks,
Jinsong

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 03:54:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 03:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVbF9-00059U-5N; Wed, 30 Nov 2011 03:53:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wanging.liu@gmail.com>) id 1RVbF6-00059P-Vj
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 03:53:57 +0000
X-Env-Sender: wanging.liu@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322625173!54775066!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4948 invoked from network); 30 Nov 2011 03:52:53 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 03:52:53 -0000
Received: by bkbzt12 with SMTP id zt12so297287bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 19:53:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Ma8HEN5ZL2iL4DulByaTv22iRxxxLZD177Ky6jMXV0o=;
	b=AtsVZS0FJll1TCNqgmO8cMHsaX9ZF5FYmMHOt6O3NP4I9QfhPx7VYtL9WWwUJp7yO1
	rJNMDPoNaJ23TV6skEECBV/bmEj9L/TFQsPYBmF9mNI4PVHfuj/4dK01Gv1EbSl2+ULr
	jFbIMY+PFHm0r7pAOeacWVIpkaS5m6qaF0KV0=
MIME-Version: 1.0
Received: by 10.204.9.211 with SMTP id m19mr234201bkm.92.1322625203310; Tue,
	29 Nov 2011 19:53:23 -0800 (PST)
Received: by 10.223.96.141 with HTTP; Tue, 29 Nov 2011 19:53:23 -0800 (PST)
Date: Wed, 30 Nov 2011 11:53:23 +0800
Message-ID: <CAAkTt5js9o2ed2iqauQMsswSMtWf92LHtLAako=RCgf+ftjw7A@mail.gmail.com>
From: =?GB2312?B?wfXN+g==?= <wanging.liu@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] which functions are used to handle the block r/w
 request from domain U (HVM)?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8298938164154390122=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8298938164154390122==
Content-Type: multipart/alternative; boundary=0015175cb2d66a116704b2ebade4

--0015175cb2d66a116704b2ebade4
Content-Type: text/plain; charset=ISO-8859-1

I am a novice and I am reading the code of
 linux-2.6.18-xen-3.4.0/drivers/xen.

blktap handle the r/w request to virtual disk(eg: XX.img) in domain 0, but
when a create a HVM vm, which module  has the same functions as blktap?


-- 

Won Liu
Beijing University of Posts and Telecommunications

--0015175cb2d66a116704b2ebade4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am a novice and I am reading the code of =A0linux-2.6.18-xen-3.4.0/driver=
s/xen.<div><br><div>blktap handle the r/w request to virtual disk(eg: XX.im=
g) in domain 0,=A0<span style=3D"background-color: transparent; ">but when =
a create a HVM vm, which=A0module=A0=A0has the same functions as blktap?</s=
pan></div>
<div><span style=3D"background-color: transparent; "><br></span></div><div>=
<div><br></div>-- <br><br>Won Liu<br>Beijing University of Posts and Teleco=
mmunications<br><br>
</div></div>

--0015175cb2d66a116704b2ebade4--


--===============8298938164154390122==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8298938164154390122==--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 03:54:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 03:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVbF9-00059U-5N; Wed, 30 Nov 2011 03:53:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wanging.liu@gmail.com>) id 1RVbF6-00059P-Vj
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 03:53:57 +0000
X-Env-Sender: wanging.liu@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1322625173!54775066!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4948 invoked from network); 30 Nov 2011 03:52:53 -0000
Received: from mail-bw0-f43.google.com (HELO mail-bw0-f43.google.com)
	(209.85.214.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 03:52:53 -0000
Received: by bkbzt12 with SMTP id zt12so297287bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 19:53:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Ma8HEN5ZL2iL4DulByaTv22iRxxxLZD177Ky6jMXV0o=;
	b=AtsVZS0FJll1TCNqgmO8cMHsaX9ZF5FYmMHOt6O3NP4I9QfhPx7VYtL9WWwUJp7yO1
	rJNMDPoNaJ23TV6skEECBV/bmEj9L/TFQsPYBmF9mNI4PVHfuj/4dK01Gv1EbSl2+ULr
	jFbIMY+PFHm0r7pAOeacWVIpkaS5m6qaF0KV0=
MIME-Version: 1.0
Received: by 10.204.9.211 with SMTP id m19mr234201bkm.92.1322625203310; Tue,
	29 Nov 2011 19:53:23 -0800 (PST)
Received: by 10.223.96.141 with HTTP; Tue, 29 Nov 2011 19:53:23 -0800 (PST)
Date: Wed, 30 Nov 2011 11:53:23 +0800
Message-ID: <CAAkTt5js9o2ed2iqauQMsswSMtWf92LHtLAako=RCgf+ftjw7A@mail.gmail.com>
From: =?GB2312?B?wfXN+g==?= <wanging.liu@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] which functions are used to handle the block r/w
 request from domain U (HVM)?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8298938164154390122=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8298938164154390122==
Content-Type: multipart/alternative; boundary=0015175cb2d66a116704b2ebade4

--0015175cb2d66a116704b2ebade4
Content-Type: text/plain; charset=ISO-8859-1

I am a novice and I am reading the code of
 linux-2.6.18-xen-3.4.0/drivers/xen.

blktap handle the r/w request to virtual disk(eg: XX.img) in domain 0, but
when a create a HVM vm, which module  has the same functions as blktap?


-- 

Won Liu
Beijing University of Posts and Telecommunications

--0015175cb2d66a116704b2ebade4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am a novice and I am reading the code of =A0linux-2.6.18-xen-3.4.0/driver=
s/xen.<div><br><div>blktap handle the r/w request to virtual disk(eg: XX.im=
g) in domain 0,=A0<span style=3D"background-color: transparent; ">but when =
a create a HVM vm, which=A0module=A0=A0has the same functions as blktap?</s=
pan></div>
<div><span style=3D"background-color: transparent; "><br></span></div><div>=
<div><br></div>-- <br><br>Won Liu<br>Beijing University of Posts and Teleco=
mmunications<br><br>
</div></div>

--0015175cb2d66a116704b2ebade4--


--===============8298938164154390122==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8298938164154390122==--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 06:13:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 06:13:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVdOv-0005wR-Q1; Wed, 30 Nov 2011 06:12:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVdOv-0005wM-2p
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 06:12:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322633494!5468988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTEzNA==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10865 invoked from network); 30 Nov 2011 06:11:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 06:11:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,595,1315180800"; 
   d="scan'208";a="9197140"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 06:11:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 06:11:33 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVdOH-0000ha-K3;
	Wed, 30 Nov 2011 06:11:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVdOH-0002ZB-Hn;
	Wed, 30 Nov 2011 06:11:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10189-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 06:11:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10189: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10189 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10189/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-win           14 guest-start.2               fail pass in 10185

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check      fail in 10185 never pass

version targeted for testing:
 xen                  df7cec2c6c03
baseline version:
 xen                  df7cec2c6c03

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 06:13:05 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 06:13:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVdOv-0005wR-Q1; Wed, 30 Nov 2011 06:12:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVdOv-0005wM-2p
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 06:12:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322633494!5468988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTEzNA==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10865 invoked from network); 30 Nov 2011 06:11:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 06:11:35 -0000
X-IronPort-AV: E=Sophos;i="4.69,595,1315180800"; 
   d="scan'208";a="9197140"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 06:11:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 06:11:33 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVdOH-0000ha-K3;
	Wed, 30 Nov 2011 06:11:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVdOH-0002ZB-Hn;
	Wed, 30 Nov 2011 06:11:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10189-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 06:11:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10189: tolerable FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10189 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10189/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-win           14 guest-start.2               fail pass in 10185

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check      fail in 10185 never pass

version targeted for testing:
 xen                  df7cec2c6c03
baseline version:
 xen                  df7cec2c6c03

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 06:14:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 06:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVdQq-0005zq-B6; Wed, 30 Nov 2011 06:14:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maillists.shan@gmail.com>) id 1RVdQp-0005za-2T
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 06:14:11 +0000
X-Env-Sender: maillists.shan@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322633611!5495910!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20380 invoked from network); 30 Nov 2011 06:13:32 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 06:13:32 -0000
Received: by ggnr4 with SMTP id r4so383237ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 22:13:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=PVGGWFJLC9Gm1i1qA7QqfnF0nmNCj99WjHEtgUyzjNU=;
	b=kUcBPOz6BCeUbbcW+pyabg6F5NRzLoLXwcrjK4gQeqt/oAj7HJVjUj7ENJ77YAwgco
	XFPdMj1mM4nqldvubL2Kso4BEZgt6mTzA5z0OE/j+XEC9Uh65TOi7MC+gar5uERkdUz4
	AJO1yLqJr3yceG2SPzhceOmbkirwf3L48yDvE=
MIME-Version: 1.0
Received: by 10.68.12.73 with SMTP id w9mr4584748pbb.6.1322633611056; Tue, 29
	Nov 2011 22:13:31 -0800 (PST)
Received: by 10.143.77.10 with HTTP; Tue, 29 Nov 2011 22:13:30 -0800 (PST)
In-Reply-To: <4EBA58F2020000780005FCCC@nat28.tlf.novell.com>
References: <4EBA58F2020000780005FCCC@nat28.tlf.novell.com>
Date: Wed, 30 Nov 2011 14:13:30 +0800
Message-ID: <CAFQ2Z+d_Oq+6L9x=V9mPJ2jTSOa5k5k2Cpgyd9rYBsrOcMeFQw@mail.gmail.com>
From: Haitao Shan <maillists.shan@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/cpuidle: add Westmere-EX support to hw
 residencies reading logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ACK!
Thanks Jan for making the cpu model list more complete.

Shan Haitao

2011/11/9 Jan Beulich <JBeulich@suse.com>:
> This is in accordance with
> http://software.intel.com/en-us/articles/intel-processor-identification-w=
ith-cpuid-model-and-family-numbers/
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -120,6 +120,7 @@ static void do_get_hw_residencies(void *
> =A0 =A0 /* Westmere */
> =A0 =A0 case 0x25:
> =A0 =A0 case 0x2C:
> + =A0 =A0case 0x2F:
> =A0 =A0 =A0 =A0 GET_PC3_RES(hw_res->pc3);
> =A0 =A0 =A0 =A0 GET_PC6_RES(hw_res->pc6);
> =A0 =A0 =A0 =A0 GET_PC7_RES(hw_res->pc7);
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 06:14:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 06:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVdQq-0005zq-B6; Wed, 30 Nov 2011 06:14:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maillists.shan@gmail.com>) id 1RVdQp-0005za-2T
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 06:14:11 +0000
X-Env-Sender: maillists.shan@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322633611!5495910!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20380 invoked from network); 30 Nov 2011 06:13:32 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 06:13:32 -0000
Received: by ggnr4 with SMTP id r4so383237ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 29 Nov 2011 22:13:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=PVGGWFJLC9Gm1i1qA7QqfnF0nmNCj99WjHEtgUyzjNU=;
	b=kUcBPOz6BCeUbbcW+pyabg6F5NRzLoLXwcrjK4gQeqt/oAj7HJVjUj7ENJ77YAwgco
	XFPdMj1mM4nqldvubL2Kso4BEZgt6mTzA5z0OE/j+XEC9Uh65TOi7MC+gar5uERkdUz4
	AJO1yLqJr3yceG2SPzhceOmbkirwf3L48yDvE=
MIME-Version: 1.0
Received: by 10.68.12.73 with SMTP id w9mr4584748pbb.6.1322633611056; Tue, 29
	Nov 2011 22:13:31 -0800 (PST)
Received: by 10.143.77.10 with HTTP; Tue, 29 Nov 2011 22:13:30 -0800 (PST)
In-Reply-To: <4EBA58F2020000780005FCCC@nat28.tlf.novell.com>
References: <4EBA58F2020000780005FCCC@nat28.tlf.novell.com>
Date: Wed, 30 Nov 2011 14:13:30 +0800
Message-ID: <CAFQ2Z+d_Oq+6L9x=V9mPJ2jTSOa5k5k2Cpgyd9rYBsrOcMeFQw@mail.gmail.com>
From: Haitao Shan <maillists.shan@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/cpuidle: add Westmere-EX support to hw
 residencies reading logic
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ACK!
Thanks Jan for making the cpu model list more complete.

Shan Haitao

2011/11/9 Jan Beulich <JBeulich@suse.com>:
> This is in accordance with
> http://software.intel.com/en-us/articles/intel-processor-identification-w=
ith-cpuid-model-and-family-numbers/
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -120,6 +120,7 @@ static void do_get_hw_residencies(void *
> =A0 =A0 /* Westmere */
> =A0 =A0 case 0x25:
> =A0 =A0 case 0x2C:
> + =A0 =A0case 0x2F:
> =A0 =A0 =A0 =A0 GET_PC3_RES(hw_res->pc3);
> =A0 =A0 =A0 =A0 GET_PC6_RES(hw_res->pc6);
> =A0 =A0 =A0 =A0 GET_PC7_RES(hw_res->pc7);
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 09:22:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 09:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVgLy-0007kn-Qv; Wed, 30 Nov 2011 09:21:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVgLw-0007ki-6B
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:21:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322644841!5565429!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25356 invoked from network); 30 Nov 2011 09:20:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 09:20:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 09:20:40 +0000
Message-Id: <4ED6037302000078000644A3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 09:20:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4ED52AF9.2080200@citrix.com>
In-Reply-To: <4ED52AF9.2080200@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 29.11.11 at 19:56, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> As I have little to no knowledge of this stage of the boot process, is
> this a sensible way to be setting up the per_cpu areas?  I have a
> sneaking suspicion that it will fall over if a CPU is onlined after
> boot, and may also fall over if a CPU is offlined and reonlined later. 
> There appears to be no infrastructure currently in place for this type
> of initialization, which is quite possibly why the code exists in its
> current form.

I actually wonder how you came to those 4 statements you make in
the description - none of these seem to me like they are really an
issue (this would instead be plain bugs in Dom0). Did you actually look
at the existing Dom0 implementation(s)?

Further, while not being a huge waste of memory, it still is one in case
kexec gets never enabled, especially when considering a Dom0 kernel
that's being built without CONFIG_KEXEC (or an incapable on, like any
pv-ops kernel to date). So I also conceptually question that change.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 09:22:08 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 09:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVgLy-0007kn-Qv; Wed, 30 Nov 2011 09:21:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVgLw-0007ki-6B
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:21:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322644841!5565429!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25356 invoked from network); 30 Nov 2011 09:20:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 09:20:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 09:20:40 +0000
Message-Id: <4ED6037302000078000644A3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 09:20:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4ED52AF9.2080200@citrix.com>
In-Reply-To: <4ED52AF9.2080200@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 29.11.11 at 19:56, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> As I have little to no knowledge of this stage of the boot process, is
> this a sensible way to be setting up the per_cpu areas?  I have a
> sneaking suspicion that it will fall over if a CPU is onlined after
> boot, and may also fall over if a CPU is offlined and reonlined later. 
> There appears to be no infrastructure currently in place for this type
> of initialization, which is quite possibly why the code exists in its
> current form.

I actually wonder how you came to those 4 statements you make in
the description - none of these seem to me like they are really an
issue (this would instead be plain bugs in Dom0). Did you actually look
at the existing Dom0 implementation(s)?

Further, while not being a huge waste of memory, it still is one in case
kexec gets never enabled, especially when considering a Dom0 kernel
that's being built without CONFIG_KEXEC (or an incapable on, like any
pv-ops kernel to date). So I also conceptually question that change.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 09:31:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 09:31:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVgVA-0007w8-7Q; Wed, 30 Nov 2011 09:30:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVgV8-0007w3-4t
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:30:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322645410!5275442!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20560 invoked from network); 30 Nov 2011 09:30:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 09:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9200161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:30:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 09:30:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Prasad B <netlogic.xen@gmail.com>
Date: Wed, 30 Nov 2011 09:30:06 +0000
In-Reply-To: <CAPw52B-9cq4TMrXnZ8Loxng=nUiwNfDs37A=HPyJ5_ed7wP6bw@mail.gmail.com>
References: <CAPw52B9wm-2VfRcLRhRBgpjDmgwU5LqNryZ0pLpNALF+eYpitQ@mail.gmail.com>
	<1317884089.24742.9.camel@dagon.hellion.org.uk>
	<CAPw52B_-K5Hy+Wo3UnarYoAb85WLhxTb4KtfByMPpL5_g+COVQ@mail.gmail.com>
	<1318411454.21903.606.camel@zakaz.uk.xensource.com>
	<CAPw52B9EEg_xHbFOCQmHDmW0evi0F6kFkronYSAAjz6ifXx72Q@mail.gmail.com>
	<1320743395.955.44.camel@zakaz.uk.xensource.com>
	<CAPw52B9c475fYmbT5e41OcLmbTyOkxPbzG6sa9pJKjDAbH=yqQ@mail.gmail.com>
	<1321459710.3664.194.camel@zakaz.uk.xensource.com>
	<CAPw52B-9cq4TMrXnZ8Loxng=nUiwNfDs37A=HPyJ5_ed7wP6bw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322645406.31810.38.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] reg dom0 console
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 01:34 +0000, Prasad B wrote:
> On Wed, Nov 16, 2011 at 8:08 AM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
>  
>         xl just execs /usr/lib/xen/bin/xenconsole to talk to the
>         console.
>         
>         xenconsole is just a client for xenconsoled which is the
>         daemon which
>         actually consumes guest consoles. The source for both is in
>         tools/console.
>         
>         My memory is fuzzy but IIRC the toolstack writes the
>         keys /local/domain/<DOMID>/console/{ring-ref,port} to xenstore
>         which
>         xenconsoled picks up in order to communicate with the domain.
>         The guest
>         gets its end of things from the startinfo.
> 
> Thanks Ian. We currently have both dom0 and domU versions of MIPS
> Linux up and running. However, we are in the process of connecting to
> domU through xenconsole. In the interim, domU too uses dom0 console
> functions and so the bootup process of domU could be seen. When domU's
> console functions are switched to write to the domU console page, domU
> output (after early printk usage) could not be read through "xl
> console <domId>" command. The sequence of commands are
> 
> xenstored -D
> xenconsoled
> xl create domU.config
> xl console 1
> 
> It was ensured that domU console page and its event channel descriptor
> were allocated correctly in domU.

By allocated do you mean picked up out of the start info? The console
mfn and evtchn for a pv guest are allocated by the builder and put into
the start info rather than the guest making them up/allocating them
itself. You should also see mention of them
in /local/domain/<domid>/console, esp port == evtchn and ring-ref == mfn
(I think) those should match what you pickup within the guest.

What does "xenstore-ls -fp" show?

>  Is there anything else that needs to be plumb the connection between
> dom0 and domU ? Could any other controlled test be run to ensure that
> all the required steps are done ?

You might be able to adapt tools/misc/xen-ringwatch or write your own
simple dom0 utility using libxc to dump the content of the shared ring,
to check if data is making it in there.

Running strace on xencoosled ought to show it polling on /dev/xen/evtch,
waking and doing a read to receive the evtchn notifications but to be
sure you could also instrument drivers/xen/xen-evtchn.c in dom0 to check
if anything was being received/delivered to userspace.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 09:31:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 09:31:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVgVA-0007w8-7Q; Wed, 30 Nov 2011 09:30:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVgV8-0007w3-4t
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 09:30:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322645410!5275442!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20560 invoked from network); 30 Nov 2011 09:30:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 09:30:11 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9200161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:30:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 09:30:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Prasad B <netlogic.xen@gmail.com>
Date: Wed, 30 Nov 2011 09:30:06 +0000
In-Reply-To: <CAPw52B-9cq4TMrXnZ8Loxng=nUiwNfDs37A=HPyJ5_ed7wP6bw@mail.gmail.com>
References: <CAPw52B9wm-2VfRcLRhRBgpjDmgwU5LqNryZ0pLpNALF+eYpitQ@mail.gmail.com>
	<1317884089.24742.9.camel@dagon.hellion.org.uk>
	<CAPw52B_-K5Hy+Wo3UnarYoAb85WLhxTb4KtfByMPpL5_g+COVQ@mail.gmail.com>
	<1318411454.21903.606.camel@zakaz.uk.xensource.com>
	<CAPw52B9EEg_xHbFOCQmHDmW0evi0F6kFkronYSAAjz6ifXx72Q@mail.gmail.com>
	<1320743395.955.44.camel@zakaz.uk.xensource.com>
	<CAPw52B9c475fYmbT5e41OcLmbTyOkxPbzG6sa9pJKjDAbH=yqQ@mail.gmail.com>
	<1321459710.3664.194.camel@zakaz.uk.xensource.com>
	<CAPw52B-9cq4TMrXnZ8Loxng=nUiwNfDs37A=HPyJ5_ed7wP6bw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322645406.31810.38.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] reg dom0 console
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 01:34 +0000, Prasad B wrote:
> On Wed, Nov 16, 2011 at 8:08 AM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
>  
>         xl just execs /usr/lib/xen/bin/xenconsole to talk to the
>         console.
>         
>         xenconsole is just a client for xenconsoled which is the
>         daemon which
>         actually consumes guest consoles. The source for both is in
>         tools/console.
>         
>         My memory is fuzzy but IIRC the toolstack writes the
>         keys /local/domain/<DOMID>/console/{ring-ref,port} to xenstore
>         which
>         xenconsoled picks up in order to communicate with the domain.
>         The guest
>         gets its end of things from the startinfo.
> 
> Thanks Ian. We currently have both dom0 and domU versions of MIPS
> Linux up and running. However, we are in the process of connecting to
> domU through xenconsole. In the interim, domU too uses dom0 console
> functions and so the bootup process of domU could be seen. When domU's
> console functions are switched to write to the domU console page, domU
> output (after early printk usage) could not be read through "xl
> console <domId>" command. The sequence of commands are
> 
> xenstored -D
> xenconsoled
> xl create domU.config
> xl console 1
> 
> It was ensured that domU console page and its event channel descriptor
> were allocated correctly in domU.

By allocated do you mean picked up out of the start info? The console
mfn and evtchn for a pv guest are allocated by the builder and put into
the start info rather than the guest making them up/allocating them
itself. You should also see mention of them
in /local/domain/<domid>/console, esp port == evtchn and ring-ref == mfn
(I think) those should match what you pickup within the guest.

What does "xenstore-ls -fp" show?

>  Is there anything else that needs to be plumb the connection between
> dom0 and domU ? Could any other controlled test be run to ensure that
> all the required steps are done ?

You might be able to adapt tools/misc/xen-ringwatch or write your own
simple dom0 utility using libxc to dump the content of the shared ring,
to check if data is making it in there.

Running strace on xencoosled ought to show it polling on /dev/xen/evtch,
waking and doing a read to receive the evtchn notifications but to be
sure you could also instrument drivers/xen/xen-evtchn.c in dom0 to check
if anything was being received/delivered to userspace.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 10:08:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 10:08:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVh4e-0008F8-M5; Wed, 30 Nov 2011 10:07:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVh4d-0008F3-Rz
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 10:07:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322647613!4731765!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8439 invoked from network); 30 Nov 2011 10:06:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 10:06:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 10:06:52 +0000
Message-Id: <4ED60E4B02000078000644C1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 10:06:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<42e6ceb8138dd9f913f6.1322598101@xdev.gridcentric.ca>
In-Reply-To: <42e6ceb8138dd9f913f6.1322598101@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 4 of 9] x86: Add conversion from a xen map
 to an mfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> xen/include/asm-x86/page.h        |   1 +
>  xen/include/asm-x86/x86_32/page.h |  11 +++++++++++
>  xen/include/asm-x86/x86_64/page.h |   5 +++++
>  3 files changed, 17 insertions(+), 0 deletions(-)
> 
> 
> This conversion is a trivial invocation of virt_to_mfn in 64 bits.
> In 32 bits it uses the linear_map.

This is not a bug fix by itself, and imo belongs into the next patch.

Jan

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/page.h
> --- a/xen/include/asm-x86/page.h
> +++ b/xen/include/asm-x86/page.h
> @@ -272,6 +272,7 @@ void copy_page_sse2(void *, const void *
>  #define pfn_to_paddr(pfn)   __pfn_to_paddr(pfn)
>  #define paddr_to_pfn(pa)    __paddr_to_pfn(pa)
>  #define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
> +#define xen_map_to_mfn(va)  __xen_map_to_mfn(va)
>  
>  #endif /* !defined(__ASSEMBLY__) */
>  
> diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/x86_32/page.h
> --- a/xen/include/asm-x86/x86_32/page.h
> +++ b/xen/include/asm-x86/x86_32/page.h
> @@ -71,6 +71,17 @@ static inline void *__maddr_to_virt(unsi
>      return (void *)(ma + DIRECTMAP_VIRT_START);
>  }
>  
> +static inline unsigned long __xen_map_to_mfn(void *va)
> +{
> +    l1_pgentry_t *l1e;
> +
> +    ASSERT( (((unsigned long) va) >= MAPCACHE_VIRT_START) &&
> +            (((unsigned long) va) <= MAPCACHE_VIRT_END) );
> +    l1e = &__linear_l1_table[
> +            l1_linear_offset((unsigned long) va)];
> +    return l1e_get_pfn(*l1e);
> +}
> +
>  /* read access (should only be used for debug printk's) */
>  typedef u64 intpte_t;
>  #define PRIpte "016llx"
> diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/x86_64/page.h
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
> @@ -104,6 +104,11 @@ static inline void *__maddr_to_virt(unsi
>                       ((ma & ma_top_mask) >> pfn_pdx_hole_shift)));
>  }
>  
> +static inline unsigned long __xen_map_to_mfn(void *va)
> +{
> +    return (__virt_to_maddr((unsigned long) va) >> PAGE_SHIFT);
> +}
> +
>  /* read access (should only be used for debug printk's) */
>  typedef u64 intpte_t;
>  #define PRIpte "016lx"




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 10:08:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 10:08:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVh4e-0008F8-M5; Wed, 30 Nov 2011 10:07:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVh4d-0008F3-Rz
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 10:07:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322647613!4731765!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8439 invoked from network); 30 Nov 2011 10:06:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 10:06:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 10:06:52 +0000
Message-Id: <4ED60E4B02000078000644C1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 10:06:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<42e6ceb8138dd9f913f6.1322598101@xdev.gridcentric.ca>
In-Reply-To: <42e6ceb8138dd9f913f6.1322598101@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 4 of 9] x86: Add conversion from a xen map
 to an mfn
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> xen/include/asm-x86/page.h        |   1 +
>  xen/include/asm-x86/x86_32/page.h |  11 +++++++++++
>  xen/include/asm-x86/x86_64/page.h |   5 +++++
>  3 files changed, 17 insertions(+), 0 deletions(-)
> 
> 
> This conversion is a trivial invocation of virt_to_mfn in 64 bits.
> In 32 bits it uses the linear_map.

This is not a bug fix by itself, and imo belongs into the next patch.

Jan

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/page.h
> --- a/xen/include/asm-x86/page.h
> +++ b/xen/include/asm-x86/page.h
> @@ -272,6 +272,7 @@ void copy_page_sse2(void *, const void *
>  #define pfn_to_paddr(pfn)   __pfn_to_paddr(pfn)
>  #define paddr_to_pfn(pa)    __paddr_to_pfn(pa)
>  #define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
> +#define xen_map_to_mfn(va)  __xen_map_to_mfn(va)
>  
>  #endif /* !defined(__ASSEMBLY__) */
>  
> diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/x86_32/page.h
> --- a/xen/include/asm-x86/x86_32/page.h
> +++ b/xen/include/asm-x86/x86_32/page.h
> @@ -71,6 +71,17 @@ static inline void *__maddr_to_virt(unsi
>      return (void *)(ma + DIRECTMAP_VIRT_START);
>  }
>  
> +static inline unsigned long __xen_map_to_mfn(void *va)
> +{
> +    l1_pgentry_t *l1e;
> +
> +    ASSERT( (((unsigned long) va) >= MAPCACHE_VIRT_START) &&
> +            (((unsigned long) va) <= MAPCACHE_VIRT_END) );
> +    l1e = &__linear_l1_table[
> +            l1_linear_offset((unsigned long) va)];
> +    return l1e_get_pfn(*l1e);
> +}
> +
>  /* read access (should only be used for debug printk's) */
>  typedef u64 intpte_t;
>  #define PRIpte "016llx"
> diff -r bea03a7fe212 -r 42e6ceb8138d xen/include/asm-x86/x86_64/page.h
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
> @@ -104,6 +104,11 @@ static inline void *__maddr_to_virt(unsi
>                       ((ma & ma_top_mask) >> pfn_pdx_hole_shift)));
>  }
>  
> +static inline unsigned long __xen_map_to_mfn(void *va)
> +{
> +    return (__virt_to_maddr((unsigned long) va) >> PAGE_SHIFT);
> +}
> +
>  /* read access (should only be used for debug printk's) */
>  typedef u64 intpte_t;
>  #define PRIpte "016lx"




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 10:11:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 10:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVh84-0008L6-B9; Wed, 30 Nov 2011 10:11:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVh82-0008Ku-It
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 10:11:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322647824!5268590!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23737 invoked from network); 30 Nov 2011 10:10:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 10:10:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 10:10:23 +0000
Message-Id: <4ED60F1D02000078000644C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 10:10:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
In-Reply-To: <b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Ensure maps used by nested
 hvm code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1828,7 +1831,12 @@ static void *__hvm_map_guest_frame(unsig
>      if ( writable )
>          paging_mark_dirty(d, mfn);
>  
> -    return map_domain_page(mfn);
> +    pg = mfn_to_page(mfn);
> +    page_get_owner_and_reference(pg);

This can (at least theoretically) fail, and you must handle failure (or
explain in a comment why not).

Jan

> +
> +    map = map_domain_page(mfn);
> +    put_gfn(d, gfn);
> +    return map;
>  }
>  
>  void *hvm_map_guest_frame_rw(unsigned long gfn)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 10:11:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 10:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVh84-0008L6-B9; Wed, 30 Nov 2011 10:11:04 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVh82-0008Ku-It
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 10:11:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322647824!5268590!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23737 invoked from network); 30 Nov 2011 10:10:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 10:10:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 10:10:23 +0000
Message-Id: <4ED60F1D02000078000644C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 10:10:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
In-Reply-To: <b2097819f2d9f7087057.1322598102@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Ensure maps used by nested
 hvm code cannot be paged out
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 >>> On 29.11.11 at 21:21, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1828,7 +1831,12 @@ static void *__hvm_map_guest_frame(unsig
>      if ( writable )
>          paging_mark_dirty(d, mfn);
>  
> -    return map_domain_page(mfn);
> +    pg = mfn_to_page(mfn);
> +    page_get_owner_and_reference(pg);

This can (at least theoretically) fail, and you must handle failure (or
explain in a comment why not).

Jan

> +
> +    map = map_domain_page(mfn);
> +    put_gfn(d, gfn);
> +    return map;
>  }
>  
>  void *hvm_map_guest_frame_rw(unsigned long gfn)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 10:28:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 10:28:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVhNP-000074-Sr; Wed, 30 Nov 2011 10:26:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVhNN-00006w-GP
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 10:26:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322648654!46416072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8343 invoked from network); 30 Nov 2011 10:24:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 10:24:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9201965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 10:26:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 10:26:14 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 10:26:14 +0000
In-Reply-To: <20179.30537.970866.190935@mariner.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322648774.31810.69.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 11:58 +0000, Ian Jackson wrote:
> # HG changeset patch
> # User Ian Jackson <Ian.Jackson@eu.citrix.com>
> # Date 1322481443 0
> # Node ID a9c67c2daf4b0181ef2581471ea920eecb495616
> # Parent  95d4e2e0bed374602b5a78ee004b057ad8715d65
> tools: Revert to our built-in aio
> 
> These two changesets:
>    24184:4ecd3615e726  tools: use system installed libaio by default.
>    24186:7aa5838499d1  tools: use system libaio for blktap1 as well.
> cause HVM guest installs (both Windows and Redhat) to fail on Debian
> squeeze with xl.  So change the default for now.
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

AIUI the tester is now installs libaio1 so we can revert this one?

According to
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
changeset 24227:1027e7d13d02 was tested and failed. That would have
included
24206:05dd94652d8d tools/check: Add files missing from 24205:5c88358164cc
24205:5c88358164cc tools: check for libaio unless user has configured CONFIG_SYSTEM_LIBAIO=n

Now I don't think the bisector would ever have given us reason to look
at this commits but if they had gone it at the same time as the new
dependency this could have saved a lot of trouble tracking down the
problem.

In
http://www.chiark.greenend.org.uk/~xensrcts/logs/10032/build-i386/4.ts-xen-build.log (one of the runs finger by the bisector which included the above commits) I can see the CHECK-BUILD runes getting run but not the CHECK-INSTALL ones.

The call to ./chk install in the install target seems to have been
deliberately removed in 16906:f4ee7e5793cf for reasons I don't quite
understand (I suspect because of the install-into-a-staging-dir property
of install). Since you install on a different host to the build host
it's possible that the tester might need to jump through some extra
hoops to cause this stuff to run there anyway. Perhaps the tester could
copy tools/check over and execute "./chk install" or "make
check-install" itself? The top-level install.sh does something like
this, but I'm not sure you are (or should be) using it.

Ian.

> 
> diff -r 95d4e2e0bed3 -r a9c67c2daf4b Config.mk
> --- a/Config.mk	Fri Nov 25 20:32:05 2011 +0000
> +++ b/Config.mk	Mon Nov 28 11:57:23 2011 +0000
> @@ -232,7 +232,7 @@ PYTHON_TOOLS       ?= y
>  OCAML_TOOLS        ?= y
>  CONFIG_MINITERM    ?= n
>  CONFIG_LOMOUNT     ?= n
> -CONFIG_SYSTEM_LIBAIO ?= y
> +CONFIG_SYSTEM_LIBAIO ?= n
>  
>  ifeq ($(OCAML_TOOLS),y)
>  OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 10:28:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 10:28:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVhNP-000074-Sr; Wed, 30 Nov 2011 10:26:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVhNN-00006w-GP
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 10:26:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322648654!46416072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8343 invoked from network); 30 Nov 2011 10:24:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 10:24:14 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9201965"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 10:26:14 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 10:26:14 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 10:26:14 +0000
In-Reply-To: <20179.30537.970866.190935@mariner.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322648774.31810.69.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2011-11-28 at 11:58 +0000, Ian Jackson wrote:
> # HG changeset patch
> # User Ian Jackson <Ian.Jackson@eu.citrix.com>
> # Date 1322481443 0
> # Node ID a9c67c2daf4b0181ef2581471ea920eecb495616
> # Parent  95d4e2e0bed374602b5a78ee004b057ad8715d65
> tools: Revert to our built-in aio
> 
> These two changesets:
>    24184:4ecd3615e726  tools: use system installed libaio by default.
>    24186:7aa5838499d1  tools: use system libaio for blktap1 as well.
> cause HVM guest installs (both Windows and Redhat) to fail on Debian
> squeeze with xl.  So change the default for now.
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

AIUI the tester is now installs libaio1 so we can revert this one?

According to
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
changeset 24227:1027e7d13d02 was tested and failed. That would have
included
24206:05dd94652d8d tools/check: Add files missing from 24205:5c88358164cc
24205:5c88358164cc tools: check for libaio unless user has configured CONFIG_SYSTEM_LIBAIO=n

Now I don't think the bisector would ever have given us reason to look
at this commits but if they had gone it at the same time as the new
dependency this could have saved a lot of trouble tracking down the
problem.

In
http://www.chiark.greenend.org.uk/~xensrcts/logs/10032/build-i386/4.ts-xen-build.log (one of the runs finger by the bisector which included the above commits) I can see the CHECK-BUILD runes getting run but not the CHECK-INSTALL ones.

The call to ./chk install in the install target seems to have been
deliberately removed in 16906:f4ee7e5793cf for reasons I don't quite
understand (I suspect because of the install-into-a-staging-dir property
of install). Since you install on a different host to the build host
it's possible that the tester might need to jump through some extra
hoops to cause this stuff to run there anyway. Perhaps the tester could
copy tools/check over and execute "./chk install" or "make
check-install" itself? The top-level install.sh does something like
this, but I'm not sure you are (or should be) using it.

Ian.

> 
> diff -r 95d4e2e0bed3 -r a9c67c2daf4b Config.mk
> --- a/Config.mk	Fri Nov 25 20:32:05 2011 +0000
> +++ b/Config.mk	Mon Nov 28 11:57:23 2011 +0000
> @@ -232,7 +232,7 @@ PYTHON_TOOLS       ?= y
>  OCAML_TOOLS        ?= y
>  CONFIG_MINITERM    ?= n
>  CONFIG_LOMOUNT     ?= n
> -CONFIG_SYSTEM_LIBAIO ?= y
> +CONFIG_SYSTEM_LIBAIO ?= n
>  
>  ifeq ($(OCAML_TOOLS),y)
>  OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 10:28:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 10:28:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVhOa-00009H-C7; Wed, 30 Nov 2011 10:28:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RVhOZ-00008r-BB; Wed, 30 Nov 2011 10:28:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322648846!6361770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30735 invoked from network); 30 Nov 2011 10:27:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 10:27:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9201991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 10:26:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 10:26:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>, <xen-users@lists.xensource.com>
Date: Wed, 30 Nov 2011 10:26:53 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322648814.31810.70.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [ANNOUNCE] In tree documentation now online
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

All,

The in tree documentation has been published online at:
http://xenbits.xen.org/docs/unstable/

This contains various pieces of documentation created as part of the two
recent documentation days as well as some other existing miscellaneous
documentation.

Updates to this documentation, in the form of patches against
xen-unstable.hg, would be gladly received on the xen-devel mailing list.
See http://wiki.xen.org/wiki/SubmittingXenPatches for hints and tips on
how to go about submitting a patch.

For new prose documentation the markdown syntax is preferred, see
http://daringfireball.net/projects/markdown/. For man pages the POD
syntax is preferred, see perlpod(1)/perlpodspec(1) or
http://perldoc.perl.org/perlpod.html /
http://perldoc.perl.org/perlpodspec.html.

The documentation site will be automatically updated based on the latest
xen-unstable tree each evening (GMT).

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 10:28:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 10:28:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVhOa-00009H-C7; Wed, 30 Nov 2011 10:28:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RVhOZ-00008r-BB; Wed, 30 Nov 2011 10:28:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1322648846!6361770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30735 invoked from network); 30 Nov 2011 10:27:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 10:27:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9201991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 10:26:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 10:26:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>, <xen-users@lists.xensource.com>
Date: Wed, 30 Nov 2011 10:26:53 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322648814.31810.70.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [ANNOUNCE] In tree documentation now online
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

All,

The in tree documentation has been published online at:
http://xenbits.xen.org/docs/unstable/

This contains various pieces of documentation created as part of the two
recent documentation days as well as some other existing miscellaneous
documentation.

Updates to this documentation, in the form of patches against
xen-unstable.hg, would be gladly received on the xen-devel mailing list.
See http://wiki.xen.org/wiki/SubmittingXenPatches for hints and tips on
how to go about submitting a patch.

For new prose documentation the markdown syntax is preferred, see
http://daringfireball.net/projects/markdown/. For man pages the POD
syntax is preferred, see perlpod(1)/perlpodspec(1) or
http://perldoc.perl.org/perlpod.html /
http://perldoc.perl.org/perlpodspec.html.

The documentation site will be automatically updated based on the latest
xen-unstable tree each evening (GMT).

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 10:46:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 10:46:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVhgG-0000rB-UY; Wed, 30 Nov 2011 10:46:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xieliwei@gmail.com>) id 1RVhgF-0000qu-GS
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 10:46:23 +0000
X-Env-Sender: xieliwei@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322649943!5626132!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9480 invoked from network); 30 Nov 2011 10:45:45 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 10:45:45 -0000
Received: by ghbz2 with SMTP id z2so690293ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 02:45:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=pl52pw0m3VvkQBcpH2Nm+qXVwvMGUsQ9QKUiXE197ig=;
	b=qs1dNGFYE/7rf+nui8QMy0Udk5WeEEq2FDHY2SJv26PqTQ9egnFIgcL75L65cnXn5F
	RoKjGavy7Fi0/UoHc0s+oN7axvq3ifHq9cLyQZ+45e4fPoV2ssPgsi0KCmM5sSGuzMcq
	Lql14W8+hVjbETZ1GWr+uwf1R06jLt2l1NSUo=
Received: by 10.101.7.23 with SMTP id k23mr305467ani.76.1322649943345; Wed, 30
	Nov 2011 02:45:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.111.9 with HTTP; Wed, 30 Nov 2011 02:45:20 -0800 (PST)
From: Liwei <xieliwei@gmail.com>
Date: Wed, 30 Nov 2011 18:45:20 +0800
Message-ID: <CAPE0SYwiSFPZsV5S1Fu=OFgezTzZZVo5oUsG_ua5gFm=-TF2OA@mail.gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Xen BUG at page_alloc.c:425, alloc_heap_pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello all,
    My graphics card died today so I temporarily swapped it out for
the old GTX460.
    Now xen keeps bugging out on me within minutes after boot. I
realise this could be a hardware problem, but what does this bug point
to?

(XEN) ----[ Xen-4.1.2-rc3-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82c480113bf2>] alloc_heap_pages+0x542/0x570
(XEN) RFLAGS: 0000000000010206   CONTEXT: hypervisor
(XEN) rax: ffff82c480290e40   rbx: ffff82f606700000   rcx: 0000000000000009
(XEN) rdx: ffff82c4802929e0   rsi: 00000000ffffffff   rdi: ffff82c480290c40
(XEN) rbp: ffff82f606703040   rsp: ffff830431b7fcd8   r8:  0000000000000000
(XEN) r9:  ffff82c480294088   r10: 0000000000000015   r11: ffff82c480293fe0
(XEN) r12: ffff82c4802bba9c   r13: 0000000000000182   r14: 0000000000000200
(XEN) r15: 0180000000000000   cr0: 0000000080050033   cr4: 00000000000026f0
(XEN) cr3: 0000000408398000   cr2: ffff880018b011f0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff830431b7fcd8:
(XEN)    0000000000000027 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000001 ffff82c480120a63
(XEN)    0000000000000002 ffff8302b5e1e000 0000000000000000 0000000000000027
(XEN)    0000000000000009 0000000000000000 ffff830431b7ff18 ffff82c480114716
(XEN)    ffff830431b7ff18 000000000215400c ffff8302b5e1e000 0000000000000200
(XEN)    0000000000000001 ffff82c4801112b0 0000000000000292 0000000000000292
(XEN)    ffff82f6082a50a0 ffff830431bcd068 ffff82c4802bc5d0 0000000000000000
(XEN)    0000000000000009 0000000002156004 0000000000000004 ffff830431b7ff18
(XEN)    0000000000000006 ffff82c480298480 ffff82c400000004 ffff830431b88080
(XEN)    ffff82c4802a9f60 0000000000000092 000000000000001e ffff82c4802bb880
(XEN)    0000000000000005 ffff830431b880a8 ffff82c480122d1b ffff8300bf76a000
(XEN)    ffff8300bf76a000 ffff82c480150769 0000001da663789e ffff82c48015421d
(XEN)    ffff82c4802bb6e0 ffff82c48011dc4b 0000000000000000 ffff82c48017ea86
(XEN)    ffff8300bf76a000 0000000001c9c380 0000000002154004 0000000000000004
(XEN)    0000000000000009 0000000000000002 ffff8302b5e1e000 000000000007c200
(XEN)    0000000000338200 0000000000000100 00007f6de3ec33b7 0000000000000033
(XEN)    0000000000000246 ffff8300bf76a000 00000000ffffffe7 00007fff5d864a80
(XEN)    ffff8800272edd40 00007fff5d864b70 000000000007f800 ffff82c4801f6418
(XEN)    000000000007f800 00007fff5d864b70 ffff8800272edd40 00007fff5d864a80
(XEN)    00000000ffffffe7 ffff88002d5c8000 0000000000000282 00007fff5d864ac0
(XEN) Xen call trace:
(XEN)    [<ffff82c480113bf2>] alloc_heap_pages+0x542/0x570
(XEN)    [<ffff82c480120a63>] cpumask_raise_softirq+0x83/0x90
(XEN)    [<ffff82c480114716>] alloc_domheap_pages+0xe6/0x110
(XEN)    [<ffff82c4801112b0>] do_memory_op+0x680/0x1ae0
(XEN)    [<ffff82c480122d1b>] add_entry+0x4b/0xb0
(XEN)    [<ffff82c480150769>] continue_nonidle_domain+0x9/0x30
(XEN)    [<ffff82c48015421d>] continue_running+0xd/0x20
(XEN)    [<ffff82c48011dc4b>] schedule+0x42b/0x560
(XEN)    [<ffff82c48017ea86>] copy_from_user+0x26/0x90
(XEN)    [<ffff82c4801f6418>] syscall_enter+0x88/0x8d
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 5:
(XEN) Xen BUG at page_alloc.c:425
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 10:46:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 10:46:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVhgG-0000rB-UY; Wed, 30 Nov 2011 10:46:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xieliwei@gmail.com>) id 1RVhgF-0000qu-GS
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 10:46:23 +0000
X-Env-Sender: xieliwei@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322649943!5626132!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9480 invoked from network); 30 Nov 2011 10:45:45 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 10:45:45 -0000
Received: by ghbz2 with SMTP id z2so690293ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 02:45:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:from:date:message-id:subject:to:content-type;
	bh=pl52pw0m3VvkQBcpH2Nm+qXVwvMGUsQ9QKUiXE197ig=;
	b=qs1dNGFYE/7rf+nui8QMy0Udk5WeEEq2FDHY2SJv26PqTQ9egnFIgcL75L65cnXn5F
	RoKjGavy7Fi0/UoHc0s+oN7axvq3ifHq9cLyQZ+45e4fPoV2ssPgsi0KCmM5sSGuzMcq
	Lql14W8+hVjbETZ1GWr+uwf1R06jLt2l1NSUo=
Received: by 10.101.7.23 with SMTP id k23mr305467ani.76.1322649943345; Wed, 30
	Nov 2011 02:45:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.111.9 with HTTP; Wed, 30 Nov 2011 02:45:20 -0800 (PST)
From: Liwei <xieliwei@gmail.com>
Date: Wed, 30 Nov 2011 18:45:20 +0800
Message-ID: <CAPE0SYwiSFPZsV5S1Fu=OFgezTzZZVo5oUsG_ua5gFm=-TF2OA@mail.gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Xen BUG at page_alloc.c:425, alloc_heap_pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello all,
    My graphics card died today so I temporarily swapped it out for
the old GTX460.
    Now xen keeps bugging out on me within minutes after boot. I
realise this could be a hardware problem, but what does this bug point
to?

(XEN) ----[ Xen-4.1.2-rc3-pre  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    5
(XEN) RIP:    e008:[<ffff82c480113bf2>] alloc_heap_pages+0x542/0x570
(XEN) RFLAGS: 0000000000010206   CONTEXT: hypervisor
(XEN) rax: ffff82c480290e40   rbx: ffff82f606700000   rcx: 0000000000000009
(XEN) rdx: ffff82c4802929e0   rsi: 00000000ffffffff   rdi: ffff82c480290c40
(XEN) rbp: ffff82f606703040   rsp: ffff830431b7fcd8   r8:  0000000000000000
(XEN) r9:  ffff82c480294088   r10: 0000000000000015   r11: ffff82c480293fe0
(XEN) r12: ffff82c4802bba9c   r13: 0000000000000182   r14: 0000000000000200
(XEN) r15: 0180000000000000   cr0: 0000000080050033   cr4: 00000000000026f0
(XEN) cr3: 0000000408398000   cr2: ffff880018b011f0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff830431b7fcd8:
(XEN)    0000000000000027 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000001 ffff82c480120a63
(XEN)    0000000000000002 ffff8302b5e1e000 0000000000000000 0000000000000027
(XEN)    0000000000000009 0000000000000000 ffff830431b7ff18 ffff82c480114716
(XEN)    ffff830431b7ff18 000000000215400c ffff8302b5e1e000 0000000000000200
(XEN)    0000000000000001 ffff82c4801112b0 0000000000000292 0000000000000292
(XEN)    ffff82f6082a50a0 ffff830431bcd068 ffff82c4802bc5d0 0000000000000000
(XEN)    0000000000000009 0000000002156004 0000000000000004 ffff830431b7ff18
(XEN)    0000000000000006 ffff82c480298480 ffff82c400000004 ffff830431b88080
(XEN)    ffff82c4802a9f60 0000000000000092 000000000000001e ffff82c4802bb880
(XEN)    0000000000000005 ffff830431b880a8 ffff82c480122d1b ffff8300bf76a000
(XEN)    ffff8300bf76a000 ffff82c480150769 0000001da663789e ffff82c48015421d
(XEN)    ffff82c4802bb6e0 ffff82c48011dc4b 0000000000000000 ffff82c48017ea86
(XEN)    ffff8300bf76a000 0000000001c9c380 0000000002154004 0000000000000004
(XEN)    0000000000000009 0000000000000002 ffff8302b5e1e000 000000000007c200
(XEN)    0000000000338200 0000000000000100 00007f6de3ec33b7 0000000000000033
(XEN)    0000000000000246 ffff8300bf76a000 00000000ffffffe7 00007fff5d864a80
(XEN)    ffff8800272edd40 00007fff5d864b70 000000000007f800 ffff82c4801f6418
(XEN)    000000000007f800 00007fff5d864b70 ffff8800272edd40 00007fff5d864a80
(XEN)    00000000ffffffe7 ffff88002d5c8000 0000000000000282 00007fff5d864ac0
(XEN) Xen call trace:
(XEN)    [<ffff82c480113bf2>] alloc_heap_pages+0x542/0x570
(XEN)    [<ffff82c480120a63>] cpumask_raise_softirq+0x83/0x90
(XEN)    [<ffff82c480114716>] alloc_domheap_pages+0xe6/0x110
(XEN)    [<ffff82c4801112b0>] do_memory_op+0x680/0x1ae0
(XEN)    [<ffff82c480122d1b>] add_entry+0x4b/0xb0
(XEN)    [<ffff82c480150769>] continue_nonidle_domain+0x9/0x30
(XEN)    [<ffff82c48015421d>] continue_running+0xd/0x20
(XEN)    [<ffff82c48011dc4b>] schedule+0x42b/0x560
(XEN)    [<ffff82c48017ea86>] copy_from_user+0x26/0x90
(XEN)    [<ffff82c4801f6418>] syscall_enter+0x88/0x8d
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 5:
(XEN) Xen BUG at page_alloc.c:425
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 11:40:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 11:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RViV5-0001GL-FH; Wed, 30 Nov 2011 11:38:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RViV4-0001GG-2R
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 11:38:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322653095!5271495!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6778 invoked from network); 30 Nov 2011 11:38:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 11:38:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9204066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 11:38:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 11:38:15 +0000
Date: Wed, 30 Nov 2011 11:39:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Arnd Bergmann <arnd@arndb.de>
In-Reply-To: <201111292129.20444.arnd@arndb.de>
Message-ID: <alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 29 Nov 2011, Arnd Bergmann wrote:
> On Tuesday 29 November 2011, Stefano Stabellini wrote:
> > Hi all,
> > a few weeks ago I (and a few others) started hacking on a
> > proof-of-concept hypervisor port to Cortex-A15 which uses and requires
> > ARMv7 virtualization extensions. The intention of this work was to find
> > out how to best support ARM v7+ on Xen. See
> > http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
> > for more details. 
> > 
> > I am pleased to announce that significant progress has been made, and
> > that we now have a nascent Xen port for Cortex-A15. The port is based on
> > xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
> > the latest virtualization, LPAE, GIC and generic timer support in
> > hardware.
> 
> Very nice!
> 
> Do you have a pointer to the kernel sources for the Linux guest?

We have very few changes to the Linux kernel at the moment (only 3
commits!), just enough to be able to issue hypercalls and start a PV
console.


A git branch is available here (not ready for submission):

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm

the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
even though guests don't really need lpae support to run on Xen.


> Since Xen and KVM are both in an early working state right now,
> it would be very nice if we could agree on the guest model to make
> sure that it's always possible to run the same kernel in both
> (and potentially other future) hypervisors without modifications.

Yes, that would be ideal.
We don't plan on making many changes other than enabling PV frontends
and backends. 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 11:40:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 11:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RViV5-0001GL-FH; Wed, 30 Nov 2011 11:38:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RViV4-0001GG-2R
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 11:38:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322653095!5271495!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6778 invoked from network); 30 Nov 2011 11:38:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 11:38:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9204066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 11:38:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 11:38:15 +0000
Date: Wed, 30 Nov 2011 11:39:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Arnd Bergmann <arnd@arndb.de>
In-Reply-To: <201111292129.20444.arnd@arndb.de>
Message-ID: <alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 29 Nov 2011, Arnd Bergmann wrote:
> On Tuesday 29 November 2011, Stefano Stabellini wrote:
> > Hi all,
> > a few weeks ago I (and a few others) started hacking on a
> > proof-of-concept hypervisor port to Cortex-A15 which uses and requires
> > ARMv7 virtualization extensions. The intention of this work was to find
> > out how to best support ARM v7+ on Xen. See
> > http://old-list-archives.xen.org/archives/html/xen-arm/2011-09/msg00013.html
> > for more details. 
> > 
> > I am pleased to announce that significant progress has been made, and
> > that we now have a nascent Xen port for Cortex-A15. The port is based on
> > xen-unstable (HG CS 8d6edc3d26d2) and written from scratch exploiting
> > the latest virtualization, LPAE, GIC and generic timer support in
> > hardware.
> 
> Very nice!
> 
> Do you have a pointer to the kernel sources for the Linux guest?

We have very few changes to the Linux kernel at the moment (only 3
commits!), just enough to be able to issue hypercalls and start a PV
console.


A git branch is available here (not ready for submission):

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm

the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
even though guests don't really need lpae support to run on Xen.


> Since Xen and KVM are both in an early working state right now,
> it would be very nice if we could agree on the guest model to make
> sure that it's always possible to run the same kernel in both
> (and potentially other future) hypervisors without modifications.

Yes, that would be ideal.
We don't plan on making many changes other than enabling PV frontends
and backends. 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 11:42:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 11:42:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RViXm-0001LL-25; Wed, 30 Nov 2011 11:41:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RViXk-0001L5-I3
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 11:41:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322653262!5547268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14372 invoked from network); 30 Nov 2011 11:41:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 11:41:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9204133"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 11:41:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 11:41:02 +0000
Date: Wed, 30 Nov 2011 11:41:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anup Patel <anup@brainfault.org>
In-Reply-To: <CAAhSdy3F1oUQP=f_Tig4_MnufwPRpNooZYW8_cSTAse7aOaDoA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111301112400.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<CAAhSdy3F1oUQP=f_Tig4_MnufwPRpNooZYW8_cSTAse7aOaDoA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 30 Nov 2011, Anup Patel wrote:
> Hi all,
> 
> I wanted to know how Xen-ARM for A15 will address following concerns:
> 
> - How will Xen-ARM for A15 support legacy guest environment like ARMv5 or ARMv6 ?

It is not our focus at the moment; we are targeting operating systems
that support a modern ARMv7 machine with GIC support. 
That said, it might be possible to run legacy guests in the future,
introducing more emulation to the hypervisor.


> - What if my Cortex-A15 board does not have a GIC with virtualization support ?

We expect most hardware vendors to provide a GIC with virtualization
support. However if they do not, in order to support their boards we'll
have to do more emulation in the hypervisor.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 11:42:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 11:42:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RViXm-0001LL-25; Wed, 30 Nov 2011 11:41:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RViXk-0001L5-I3
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 11:41:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322653262!5547268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14372 invoked from network); 30 Nov 2011 11:41:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 11:41:02 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9204133"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 11:41:02 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 11:41:02 +0000
Date: Wed, 30 Nov 2011 11:41:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anup Patel <anup@brainfault.org>
In-Reply-To: <CAAhSdy3F1oUQP=f_Tig4_MnufwPRpNooZYW8_cSTAse7aOaDoA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111301112400.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<CAAhSdy3F1oUQP=f_Tig4_MnufwPRpNooZYW8_cSTAse7aOaDoA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 30 Nov 2011, Anup Patel wrote:
> Hi all,
> 
> I wanted to know how Xen-ARM for A15 will address following concerns:
> 
> - How will Xen-ARM for A15 support legacy guest environment like ARMv5 or ARMv6 ?

It is not our focus at the moment; we are targeting operating systems
that support a modern ARMv7 machine with GIC support. 
That said, it might be possible to run legacy guests in the future,
introducing more emulation to the hypervisor.


> - What if my Cortex-A15 board does not have a GIC with virtualization support ?

We expect most hardware vendors to provide a GIC with virtualization
support. However if they do not, in order to support their boards we'll
have to do more emulation in the hypervisor.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 12:13:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 12:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVj2V-0001qp-3G; Wed, 30 Nov 2011 12:13:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RVj2T-0001q1-0B
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 12:13:25 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322655166!6400458!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29852 invoked from network); 30 Nov 2011 12:12:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 12:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9204877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 12:12:42 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 12:12:42 +0000
Date: Wed, 30 Nov 2011 12:12:36 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20179.51666.829995.721200@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111301208120.8085@perard.uk.xensource.com>
References: <1322233395-29575-1-git-send-email-anthony.perard@citrix.com>
	<20179.51666.829995.721200@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Apply CLOEXEC to the restore_fd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 28 Nov 2011, Ian Jackson wrote:

> Anthony PERARD writes ("[Xen-devel] [PATCH] xl: Apply CLOEXEC to the restore_fd."):
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 080aa2b..8bdfc32 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -1382,6 +1382,7 @@ static int create_domain(struct domain_create *dom_info)
> >
> >          restore_fd = migrate_fd >= 0 ? migrate_fd :
> >              open(restore_file, O_RDONLY);
> > +        libxl_fd_set_cloexec(restore_fd);
>
> I don't think it's really sensible for this function to set cloexec on
> a descriptor provided by its caller.  I'm afraid that although it
> makes the code longer, I would prefer it if the cloexec was set at
> each point when the fd is opened.

I think, for `xl restore`, the open is here, and I forgot the rest.
I will set cloexec where the fd is opened.

Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 12:13:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 12:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVj2V-0001qp-3G; Wed, 30 Nov 2011 12:13:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RVj2T-0001q1-0B
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 12:13:25 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1322655166!6400458!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29852 invoked from network); 30 Nov 2011 12:12:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 12:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9204877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 12:12:42 +0000
Received: from dhcp-3-28.uk.xensource.com (10.80.3.28) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 12:12:42 +0000
Date: Wed, 30 Nov 2011 12:12:36 +0000
From: Anthony PERARD <anthony.perard@citrix.com>
X-X-Sender: anthony@perard.uk.xensource.com
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
In-Reply-To: <20179.51666.829995.721200@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1111301208120.8085@perard.uk.xensource.com>
References: <1322233395-29575-1-git-send-email-anthony.perard@citrix.com>
	<20179.51666.829995.721200@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Apply CLOEXEC to the restore_fd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 28 Nov 2011, Ian Jackson wrote:

> Anthony PERARD writes ("[Xen-devel] [PATCH] xl: Apply CLOEXEC to the restore_fd."):
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 080aa2b..8bdfc32 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -1382,6 +1382,7 @@ static int create_domain(struct domain_create *dom_info)
> >
> >          restore_fd = migrate_fd >= 0 ? migrate_fd :
> >              open(restore_file, O_RDONLY);
> > +        libxl_fd_set_cloexec(restore_fd);
>
> I don't think it's really sensible for this function to set cloexec on
> a descriptor provided by its caller.  I'm afraid that although it
> makes the code longer, I would prefer it if the cloexec was set at
> each point when the fd is opened.

I think, for `xl restore`, the open is here, and I forgot the rest.
I will set cloexec where the fd is opened.

Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 12:48:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 12:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVjZb-00025u-9X; Wed, 30 Nov 2011 12:47:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVjZZ-00025g-Fa
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 12:47:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322657218!5600456!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzQyMDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzQyMDI=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1504 invoked from network); 30 Nov 2011 12:46:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Nov 2011 12:46:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322657218; l=612;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=lwg4uTr4EbjvzTWW43E1pNOXFro=;
	b=Dj4h4pXxAgt0fxuwsG+C5CNTNcRnUU8GrRISiHlqAcBceGGn9unK0DYEwnc+xUqG4bx
	Gx/Pe8KmRF9V/hEbeb5EAXEdcPqM6xmt9pvKlmiDbOC4fOdBolFqjdnk5Lv8PQasD0gge
	6ieDlozH4xhvGpd5h78yOF4NeIaAYnRcH+4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by post.strato.de (mrclete mo40) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L02818nAUC91XN ;
	Wed, 30 Nov 2011 13:46:51 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6A66118637; Wed, 30 Nov 2011 13:46:50 +0100 (CET)
Date: Wed, 30 Nov 2011 13:46:50 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111130124650.GA15723@aepfle.de>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Andres Lagar-Cavilla wrote:

> Check that the valid mfn is the one we are mapping, not the
> mfn of the page table of the foreign domain.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Olaf Hering <olaf@aepfle.de>


> diff -r 5286ed662c1e -r 3489152b3a56 xen/arch/x86/mm.c
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3572,7 +3572,8 @@ int do_mmu_update(
>                          rc = -ENOENT;
>                          break;
>                      }
> -                    else if ( p2m_ram_paging_in_start == l1e_p2mt && !mfn_valid(mfn) )
> +                    else if ( p2m_ram_paging_in_start == l1e_p2mt && 
> +                                !mfn_valid(l1emfn) )


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 12:48:16 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 12:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVjZb-00025u-9X; Wed, 30 Nov 2011 12:47:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVjZZ-00025g-Fa
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 12:47:37 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-216.messagelabs.com!1322657218!5600456!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzQyMDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzQyMDI=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1504 invoked from network); 30 Nov 2011 12:46:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Nov 2011 12:46:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322657218; l=612;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=lwg4uTr4EbjvzTWW43E1pNOXFro=;
	b=Dj4h4pXxAgt0fxuwsG+C5CNTNcRnUU8GrRISiHlqAcBceGGn9unK0DYEwnc+xUqG4bx
	Gx/Pe8KmRF9V/hEbeb5EAXEdcPqM6xmt9pvKlmiDbOC4fOdBolFqjdnk5Lv8PQasD0gge
	6ieDlozH4xhvGpd5h78yOF4NeIaAYnRcH+4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by post.strato.de (mrclete mo40) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L02818nAUC91XN ;
	Wed, 30 Nov 2011 13:46:51 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6A66118637; Wed, 30 Nov 2011 13:46:50 +0100 (CET)
Date: Wed, 30 Nov 2011 13:46:50 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111130124650.GA15723@aepfle.de>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Andres Lagar-Cavilla wrote:

> Check that the valid mfn is the one we are mapping, not the
> mfn of the page table of the foreign domain.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Olaf Hering <olaf@aepfle.de>


> diff -r 5286ed662c1e -r 3489152b3a56 xen/arch/x86/mm.c
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3572,7 +3572,8 @@ int do_mmu_update(
>                          rc = -ENOENT;
>                          break;
>                      }
> -                    else if ( p2m_ram_paging_in_start == l1e_p2mt && !mfn_valid(mfn) )
> +                    else if ( p2m_ram_paging_in_start == l1e_p2mt && 
> +                                !mfn_valid(l1emfn) )


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:00:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVjkj-0002IN-JJ; Wed, 30 Nov 2011 12:59:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVjki-0002IH-KJ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 12:59:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322657909!3512500!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3220 invoked from network); 30 Nov 2011 12:58:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Nov 2011 12:58:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322657909; l=1009;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=joRAKwqDqEkvwxFehu07Xv8T8iQ=;
	b=ahKrvOYdtsbzWKwhrzQy9FqUACDY2bEZmUcr/LV3JrzWeAsKaS4YDmrXUyBQmaA5cRo
	6Z//EERWS7KTMmNDNPpnCINhsoWrj6nvd9T+zP/IW4oz7NQckPn3MFv6m6bJwz8IEabTF
	LHx5QboqnhnEqtq01iSqBCYGXhRgtfXGeGQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by smtp.strato.de (klopstock mo4) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id h04ccfnAUBm3H5 ;
	Wed, 30 Nov 2011 13:58:22 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 8792A18637; Wed, 30 Nov 2011 13:58:21 +0100 (CET)
Date: Wed, 30 Nov 2011 13:58:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111130125821.GB15723@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Andres Lagar-Cavilla wrote:

>  xen/arch/x86/hvm/hvm.c          |   20 ++-
>  xen/arch/x86/mm/mem_event.c     |  205 ++++++++++++++++++++++++++++++---------
>  xen/arch/x86/mm/mem_sharing.c   |   27 +++-
>  xen/arch/x86/mm/p2m.c           |  104 ++++++++++---------
>  xen/common/memory.c             |    7 +-
>  xen/include/asm-x86/mem_event.h |   16 ++-
>  xen/include/asm-x86/p2m.h       |    6 +-
>  xen/include/xen/mm.h            |    2 +
>  xen/include/xen/sched.h         |    5 +-
>  9 files changed, 268 insertions(+), 124 deletions(-)
> 
> 
> The memevent code currently has a mechanism for reserving space in the ring
> before putting an event, but each caller must individually ensure that the
> vCPUs are correctly paused if no space is available.

I have an improved patch which uses wait queues in
mem_event_put_request() and also the new wake_up_nr(). Using pause here
and wait queues in get_gfn does not mix well AFAICS. My wait queue patch
for get_gfn is not yet finished.

I propose to use wait queues for both mem_event and get_gfn.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:00:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVjkj-0002IN-JJ; Wed, 30 Nov 2011 12:59:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVjki-0002IH-KJ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 12:59:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1322657909!3512500!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3220 invoked from network); 30 Nov 2011 12:58:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Nov 2011 12:58:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322657909; l=1009;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=joRAKwqDqEkvwxFehu07Xv8T8iQ=;
	b=ahKrvOYdtsbzWKwhrzQy9FqUACDY2bEZmUcr/LV3JrzWeAsKaS4YDmrXUyBQmaA5cRo
	6Z//EERWS7KTMmNDNPpnCINhsoWrj6nvd9T+zP/IW4oz7NQckPn3MFv6m6bJwz8IEabTF
	LHx5QboqnhnEqtq01iSqBCYGXhRgtfXGeGQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by smtp.strato.de (klopstock mo4) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id h04ccfnAUBm3H5 ;
	Wed, 30 Nov 2011 13:58:22 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 8792A18637; Wed, 30 Nov 2011 13:58:21 +0100 (CET)
Date: Wed, 30 Nov 2011 13:58:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111130125821.GB15723@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Andres Lagar-Cavilla wrote:

>  xen/arch/x86/hvm/hvm.c          |   20 ++-
>  xen/arch/x86/mm/mem_event.c     |  205 ++++++++++++++++++++++++++++++---------
>  xen/arch/x86/mm/mem_sharing.c   |   27 +++-
>  xen/arch/x86/mm/p2m.c           |  104 ++++++++++---------
>  xen/common/memory.c             |    7 +-
>  xen/include/asm-x86/mem_event.h |   16 ++-
>  xen/include/asm-x86/p2m.h       |    6 +-
>  xen/include/xen/mm.h            |    2 +
>  xen/include/xen/sched.h         |    5 +-
>  9 files changed, 268 insertions(+), 124 deletions(-)
> 
> 
> The memevent code currently has a mechanism for reserving space in the ring
> before putting an event, but each caller must individually ensure that the
> vCPUs are correctly paused if no space is available.

I have an improved patch which uses wait queues in
mem_event_put_request() and also the new wake_up_nr(). Using pause here
and wait queues in get_gfn does not mix well AFAICS. My wait queue patch
for get_gfn is not yet finished.

I propose to use wait queues for both mem_event and get_gfn.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:03:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:03:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVjom-0002Sg-Bf; Wed, 30 Nov 2011 13:03:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVjok-0002SI-MC
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:03:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322658160!5297076!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3910 invoked from network); 30 Nov 2011 13:02:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 13:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9206556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 13:02:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 13:02:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 30 Nov 2011 13:02:36 +0000
In-Reply-To: <1322219529495-5022556.post@n5.nabble.com>
References: <1322219529495-5022556.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322658156.31810.86.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 11:12 +0000, Fantu wrote:
> I try to use cdrom in domU linux pv, on Lucid and Natty with
> 'phy:/dev/scd0,xvdc,r' see it as internal disk (not cdrom) and only
> administrators can mount it, i try also 'phy:/dev/scd0,xvdc1,r' but not
> work.
> On Oneiric and Precise (daily build) with 'phy:/dev/scd0,xvdc,r' see it as
> cdrom but not automount it, work only manual mount of xvdc; i try also
> 'phy:/dev/scd0,xvdc1,r' but not work.
> Is possible use cdrom on linux domU pv full working where also normal user
> can mount it without terminal?
> I do something wrong, or there are still bugs in this regard?

You don't say which toolstack you are using but if you consult
http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt you
will see that you need to explicitly mark a device as a CDROM.

Ian.

> Thanks for any reply.
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5022556p5022556.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:03:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:03:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVjom-0002Sg-Bf; Wed, 30 Nov 2011 13:03:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVjok-0002SI-MC
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:03:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322658160!5297076!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3910 invoked from network); 30 Nov 2011 13:02:40 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 13:02:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9206556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 13:02:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 13:02:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Fantu <fantonifabio@tiscali.it>
Date: Wed, 30 Nov 2011 13:02:36 +0000
In-Reply-To: <1322219529495-5022556.post@n5.nabble.com>
References: <1322219529495-5022556.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322658156.31810.86.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2011-11-25 at 11:12 +0000, Fantu wrote:
> I try to use cdrom in domU linux pv, on Lucid and Natty with
> 'phy:/dev/scd0,xvdc,r' see it as internal disk (not cdrom) and only
> administrators can mount it, i try also 'phy:/dev/scd0,xvdc1,r' but not
> work.
> On Oneiric and Precise (daily build) with 'phy:/dev/scd0,xvdc,r' see it as
> cdrom but not automount it, work only manual mount of xvdc; i try also
> 'phy:/dev/scd0,xvdc1,r' but not work.
> Is possible use cdrom on linux domU pv full working where also normal user
> can mount it without terminal?
> I do something wrong, or there are still bugs in this regard?

You don't say which toolstack you are using but if you consult
http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt you
will see that you need to explicitly mark a device as a CDROM.

Ian.

> Thanks for any reply.
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5022556p5022556.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:04:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVjpe-0002WI-QR; Wed, 30 Nov 2011 13:04:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RVjpc-0002Vp-J1
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:04:12 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322658214!5613674!1
X-Originating-IP: [212.227.17.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4xMCA9PiA3NTkzNg==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8460 invoked from network); 30 Nov 2011 13:03:34 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.10) by server-13.tower-216.messagelabs.com with SMTP;
	30 Nov 2011 13:03:34 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis)
	id 0MQaxF-1ROLJq3xlt-00Txdh; Wed, 30 Nov 2011 14:03:30 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 13:03:23 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201111301303.23851.arnd@arndb.de>
X-Provags-ID: V02:K0:yO3QYRv/tV0cvlbKetPYikmxAMy/xeoY1O3g7UVEQfs
	HfDjbIGA+ldgcNVB32LorGgSwECxyFpsENBWyMy5SXv4lynbw2
	Mn1GonGMemlPRAPhd/EVvsvRQH36i/t3WrUR1Di+2t2mF5nz4b
	yidnsVj2+j4s0RRxl0NYDEArvUQIdAtxqT6E3dSwq9wqGKCWGq
	OL/VVsID9t58AiXzk3O93bxzRHUF5+0nk5vn/TNgApzlQ7oh0X
	AaCW8Dksze0VBdtwsGFPYYqsmdCamfyEF3H5PRrlniVhgBnED5
	D0UwgXJF0iBpF2h4RVpLI/ik2UPrLQIFq8lrTuzaNGYbndM8Vf
	EghSQz76kbIC04Wt70RU=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wednesday 30 November 2011, Stefano Stabellini wrote:
> On Tue, 29 Nov 2011, Arnd Bergmann wrote:
> > On Tuesday 29 November 2011, Stefano Stabellini wrote:
> > 
> > Do you have a pointer to the kernel sources for the Linux guest?
> 
> We have very few changes to the Linux kernel at the moment (only 3
> commits!), just enough to be able to issue hypercalls and start a PV
> console.
> 
> A git branch is available here (not ready for submission):
> 
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm

Ok, interesting. There really isn't much of the platform support
that I was expecting there. I finally found the information
I was looking for in the xen construct_dom0() function:

 167     regs->r0 = 0; /* SBZ */
 168     regs->r1 = 2272; /* Machine NR: Versatile Express */
 169     regs->r2 = 0xc0000100; /* ATAGS */

What this means is that you are emulating the current ARM/Keil reference
board, at least to the degree that is necessary to get the guest started.

This is the same choice people have made for KVM, but it's not
necessarily the best option in the long run. In particular, this
board has a lot of hardware that you claim to have by putting the
machine number there, when you don't really want to emulate it.

Pawell Moll is working on a variant of the vexpress code that uses
the flattened device tree to describe the present hardware [1], and
I think that would be a much better target for an official release.
Ideally, the hypervisor should provide the device tree binary (dtb)
to the guest OS describing the hardware that is actually there.

This would also be the place where you tell the guest that it should
look for PV devices. I'm not familiar with how Xen announces PV
devices to the guest on other architectures, but you have the
choice between providing a full "binding", i.e. a formal specification
in device tree format for the guest to detect PV devices in the
same way as physical or emulated devices, or just providing a single
place in the device tree in which the guest detects the presence
of a xen device bus and then uses hcalls to find the devices on that
bus.

Another topic is the question whether there are any hcalls that
we should try to standardize before we get another architecture
with multiple conflicting hcall APIs as we have on x86 and powerpc.

	Arnd

[1] http://www.spinics.net/lists/arm-kernel/msg149604.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:04:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVjpe-0002WI-QR; Wed, 30 Nov 2011 13:04:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RVjpc-0002Vp-J1
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:04:12 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1322658214!5613674!1
X-Originating-IP: [212.227.17.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIyNy4xNy4xMCA9PiA3NTkzNg==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8460 invoked from network); 30 Nov 2011 13:03:34 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.10) by server-13.tower-216.messagelabs.com with SMTP;
	30 Nov 2011 13:03:34 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis)
	id 0MQaxF-1ROLJq3xlt-00Txdh; Wed, 30 Nov 2011 14:03:30 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 13:03:23 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
MIME-Version: 1.0
Message-Id: <201111301303.23851.arnd@arndb.de>
X-Provags-ID: V02:K0:yO3QYRv/tV0cvlbKetPYikmxAMy/xeoY1O3g7UVEQfs
	HfDjbIGA+ldgcNVB32LorGgSwECxyFpsENBWyMy5SXv4lynbw2
	Mn1GonGMemlPRAPhd/EVvsvRQH36i/t3WrUR1Di+2t2mF5nz4b
	yidnsVj2+j4s0RRxl0NYDEArvUQIdAtxqT6E3dSwq9wqGKCWGq
	OL/VVsID9t58AiXzk3O93bxzRHUF5+0nk5vn/TNgApzlQ7oh0X
	AaCW8Dksze0VBdtwsGFPYYqsmdCamfyEF3H5PRrlniVhgBnED5
	D0UwgXJF0iBpF2h4RVpLI/ik2UPrLQIFq8lrTuzaNGYbndM8Vf
	EghSQz76kbIC04Wt70RU=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wednesday 30 November 2011, Stefano Stabellini wrote:
> On Tue, 29 Nov 2011, Arnd Bergmann wrote:
> > On Tuesday 29 November 2011, Stefano Stabellini wrote:
> > 
> > Do you have a pointer to the kernel sources for the Linux guest?
> 
> We have very few changes to the Linux kernel at the moment (only 3
> commits!), just enough to be able to issue hypercalls and start a PV
> console.
> 
> A git branch is available here (not ready for submission):
> 
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm

Ok, interesting. There really isn't much of the platform support
that I was expecting there. I finally found the information
I was looking for in the xen construct_dom0() function:

 167     regs->r0 = 0; /* SBZ */
 168     regs->r1 = 2272; /* Machine NR: Versatile Express */
 169     regs->r2 = 0xc0000100; /* ATAGS */

What this means is that you are emulating the current ARM/Keil reference
board, at least to the degree that is necessary to get the guest started.

This is the same choice people have made for KVM, but it's not
necessarily the best option in the long run. In particular, this
board has a lot of hardware that you claim to have by putting the
machine number there, when you don't really want to emulate it.

Pawell Moll is working on a variant of the vexpress code that uses
the flattened device tree to describe the present hardware [1], and
I think that would be a much better target for an official release.
Ideally, the hypervisor should provide the device tree binary (dtb)
to the guest OS describing the hardware that is actually there.

This would also be the place where you tell the guest that it should
look for PV devices. I'm not familiar with how Xen announces PV
devices to the guest on other architectures, but you have the
choice between providing a full "binding", i.e. a formal specification
in device tree format for the guest to detect PV devices in the
same way as physical or emulated devices, or just providing a single
place in the device tree in which the guest detects the presence
of a xen device bus and then uses hcalls to find the devices on that
bus.

Another topic is the question whether there are any hcalls that
we should try to standardize before we get another architecture
with multiple conflicting hcall APIs as we have on x86 and powerpc.

	Arnd

[1] http://www.spinics.net/lists/arm-kernel/msg149604.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:12:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:12:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVjxa-0002pZ-Qd; Wed, 30 Nov 2011 13:12:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RVjxa-0002pR-3y
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:12:26 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322658673!48949604!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13056 invoked from network); 30 Nov 2011 13:11:13 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-6.tower-27.messagelabs.com with SMTP;
	30 Nov 2011 13:11:13 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 747BB1AABDF;
	Wed, 30 Nov 2011 14:11:46 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id PCVhEoncroaD; Wed, 30 Nov 2011 14:11:46 +0100 (CET)
Received: from [10.0.0.1] (p5DCB6C98.dip.t-dialin.net [93.203.108.152])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Wed, 30 Nov 2011 14:11:46 +0100 (CET)
Message-ID: <4ED62B94.4040502@hfp.de>
Date: Wed, 30 Nov 2011 14:11:48 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Roderick Colenbrander <thunderbird2k@gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<CAEc3jaA3GgpGzP52D86qBMMRDNRBO7H08RDfxuF6pG609h96iA@mail.gmail.com>
In-Reply-To: <CAEc3jaA3GgpGzP52D86qBMMRDNRBO7H08RDfxuF6pG609h96iA@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> The patch actually only disables HPET broadcast which has some downsides
>> because it effectively disables C3 states. Without C3 states Nehalem and
>> later CPUs cannot enter turbo-mode. So there is some loss of performance.
> Would disabling any low CPU power states and turbo clocks in the BIOS,
> help as well? Just curious. I have seen other 'weird' performance

I would leave the BIOS to its default and I'd guess that playing with 
BIOS settings only makes it worse.

> issues between machines using the same hardware. Some CPU intensive
> algorithm could be twice as slow running on Dom0 compared to the same
> kernel without Xen. On other identical systems I didn't see that
> issue. I didn't have time to investigate, but I felt there may have
> been BIOS setting differences.

Xen does not use the performance governor by default which has a notable 
performance impact in my tests. My Xen boot config is:

kernel /xen.gz dom0_mem=1024m dom0_max_vcpus=2 cpufreq=xen:performance
module /linux-2.6.32.36-pvops0-ak2 root=/dev/sda5

Regards Andreas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:12:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:12:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVjxa-0002pZ-Qd; Wed, 30 Nov 2011 13:12:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ml-xen-devel@hfp.de>) id 1RVjxa-0002pR-3y
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:12:26 +0000
X-Env-Sender: ml-xen-devel@hfp.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322658673!48949604!1
X-Originating-IP: [88.205.101.6]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13056 invoked from network); 30 Nov 2011 13:11:13 -0000
Received: from rootsrv.hfp.de (HELO rootsrv.hfp.de) (88.205.101.6)
	by server-6.tower-27.messagelabs.com with SMTP;
	30 Nov 2011 13:11:13 -0000
Received: from localhost (localhost [127.0.0.1])
	by rootsrv.hfp.de (Postfix) with ESMTP id 747BB1AABDF;
	Wed, 30 Nov 2011 14:11:46 +0100 (CET)
X-Virus-Scanned: amavisd-new/ClamAV at rootsrv.hfp.de
Received: from rootsrv.hfp.de ([127.0.0.1])
	by localhost (rootsrv.hfp.de [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id PCVhEoncroaD; Wed, 30 Nov 2011 14:11:46 +0100 (CET)
Received: from [10.0.0.1] (p5DCB6C98.dip.t-dialin.net [93.203.108.152])
	by rootsrv.hfp.de (Postfix) with ESMTPA;
	Wed, 30 Nov 2011 14:11:46 +0100 (CET)
Message-ID: <4ED62B94.4040502@hfp.de>
Date: Wed, 30 Nov 2011 14:11:48 +0100
From: Andreas Kinzler <ml-xen-devel@hfp.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Roderick Colenbrander <thunderbird2k@gmail.com>
References: <CAEc3jaBds7xmiKH8RMfmEHQumkEeZ3PopVfbZPs_B-Kz8-DsWw@mail.gmail.com>
	<4ED51291.1010308@hfp.de>
	<CAEc3jaAa7y8C2NNBn1=L3AhS0uuYFP6ze8o1cZ9yG2VYHx6qMA@mail.gmail.com>
	<4ED5215D.1010403@hfp.de>
	<CAEc3jaA3GgpGzP52D86qBMMRDNRBO7H08RDfxuF6pG609h96iA@mail.gmail.com>
In-Reply-To: <CAEc3jaA3GgpGzP52D86qBMMRDNRBO7H08RDfxuF6pG609h96iA@mail.gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Questions about GPLPV stability tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>> The patch actually only disables HPET broadcast which has some downsides
>> because it effectively disables C3 states. Without C3 states Nehalem and
>> later CPUs cannot enter turbo-mode. So there is some loss of performance.
> Would disabling any low CPU power states and turbo clocks in the BIOS,
> help as well? Just curious. I have seen other 'weird' performance

I would leave the BIOS to its default and I'd guess that playing with 
BIOS settings only makes it worse.

> issues between machines using the same hardware. Some CPU intensive
> algorithm could be twice as slow running on Dom0 compared to the same
> kernel without Xen. On other identical systems I didn't see that
> issue. I didn't have time to investigate, but I felt there may have
> been BIOS setting differences.

Xen does not use the performance governor by default which has a notable 
performance impact in my tests. My Xen boot config is:

kernel /xen.gz dom0_mem=1024m dom0_max_vcpus=2 cpufreq=xen:performance
module /linux-2.6.32.36-pvops0-ak2 root=/dev/sda5

Regards Andreas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:16:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVk0j-0002vm-F7; Wed, 30 Nov 2011 13:15:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVk0h-0002vd-Q1
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:15:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322658899!5650894!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28901 invoked from network); 30 Nov 2011 13:15:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 13:15:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315195200"; d="scan'208";a="172344803"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 08:14:58 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 30 Nov 2011
	08:14:58 -0500
Message-ID: <4ED62C50.7060204@citrix.com>
Date: Wed, 30 Nov 2011 13:14:56 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
In-Reply-To: <CAFA7027.25E35%keir.xen@gmail.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/11 11:19, Keir Fraser wrote:
> On 29/11/2011 18:56, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>
>> Hello,
>>  
>> As I have little to no knowledge of this stage of the boot process, is
>> this a sensible way to be setting up the per_cpu areas?  I have a
>> sneaking suspicion that it will fall over if a CPU is onlined after
>> boot, and may also fall over if a CPU is offlined and reonlined later.
>> There appears to be no infrastructure currently in place for this type
>> of initialization, which is quite possibly why the code exists in its
>> current form.
> No it's bad. For starters you should use for_each_online_cpu, not do an
> open-coded for-loop. Secondly you should register a cpu hotplug notifier
> (register_cpu_notifier()) to pick up and handle future
> CPU_UP_PREPARE/CPU_UP_CANCELED/CPU_DEAD events. This can be hung off an
> __initcall. See common/stop_machine.c for example, or common/timer.c, which
> doesn't even require a for_each_online_cpu loop because its init code gets
> run before we bring up secondary CPUs.
>
>  -- Keir 
>

Thanks - this is exactly what I was looking for.

Sadly, after thinking about cpu hotplug safety, it is not safe to store
the crash note pointer in the per cpu data.  Once you have reported an
area to dom0 via KEXEC_CMD_get_reserve, the areas reported cant possibly
move.

Therefore, I need to redesign a little bit.

Thanks,

~Andrew

>> Thanks,
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:16:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVk0j-0002vm-F7; Wed, 30 Nov 2011 13:15:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVk0h-0002vd-Q1
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:15:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322658899!5650894!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28901 invoked from network); 30 Nov 2011 13:15:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 13:15:00 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315195200"; d="scan'208";a="172344803"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 08:14:58 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 30 Nov 2011
	08:14:58 -0500
Message-ID: <4ED62C50.7060204@citrix.com>
Date: Wed, 30 Nov 2011 13:14:56 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CAFA7027.25E35%keir.xen@gmail.com>
In-Reply-To: <CAFA7027.25E35%keir.xen@gmail.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/11 11:19, Keir Fraser wrote:
> On 29/11/2011 18:56, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>
>> Hello,
>>  
>> As I have little to no knowledge of this stage of the boot process, is
>> this a sensible way to be setting up the per_cpu areas?  I have a
>> sneaking suspicion that it will fall over if a CPU is onlined after
>> boot, and may also fall over if a CPU is offlined and reonlined later.
>> There appears to be no infrastructure currently in place for this type
>> of initialization, which is quite possibly why the code exists in its
>> current form.
> No it's bad. For starters you should use for_each_online_cpu, not do an
> open-coded for-loop. Secondly you should register a cpu hotplug notifier
> (register_cpu_notifier()) to pick up and handle future
> CPU_UP_PREPARE/CPU_UP_CANCELED/CPU_DEAD events. This can be hung off an
> __initcall. See common/stop_machine.c for example, or common/timer.c, which
> doesn't even require a for_each_online_cpu loop because its init code gets
> run before we bring up secondary CPUs.
>
>  -- Keir 
>

Thanks - this is exactly what I was looking for.

Sadly, after thinking about cpu hotplug safety, it is not safe to store
the crash note pointer in the per cpu data.  Once you have reported an
area to dom0 via KEXEC_CMD_get_reserve, the areas reported cant possibly
move.

Therefore, I need to redesign a little bit.

Thanks,

~Andrew

>> Thanks,
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:22:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:22:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVk6q-000390-Bi; Wed, 30 Nov 2011 13:22:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVk6o-00038r-Oh
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:21:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322659279!661512!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDMzMzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDMzMzI=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28125 invoked from network); 30 Nov 2011 13:21:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Nov 2011 13:21:20 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322659279; l=735;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TU6S2lDOlxbsgZ/CzjWez7ZeyKc=;
	b=QlzBzu8Px+YLbxyUHwJYxvPLwgJGfu1KFrnFgsNCI6/s1RbeGWJMdIOeX8buoU4wpwA
	wK9dB9zaHpnXnffdbGxk2VcIZ9FZXXcfKWKkUPlN8a3U+9FIdnSu33u7sBsIKiZKbhrp+
	cdvRY9HkQqDpP2o7iF9bIQdL+LLhFH6eWzk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by smtp.strato.de (fruni mo23) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id I05c9enAUDIAQb ;
	Wed, 30 Nov 2011 14:21:00 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3884118637; Wed, 30 Nov 2011 14:21:00 +0100 (CET)
Date: Wed, 30 Nov 2011 14:21:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111130132100.GA17890@aepfle.de>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322603559@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Fix correctness race in
 xc_mem_paging_prep
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Andres Lagar-Cavilla wrote:

> P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
> transitions to the next state in the paging state machine for this page. 
> Foreign mappings of the gfn will now succeed. This is the key idea, as it 
> allows the pager to now map the gfn and fill in its contents.
> 
> Unfortunately, it also allows any other foreign mapper to map the gfn and read
> its contents. This is particularly dangerous when the populate is launched
> by a foreign mapper in the first place, which will be actively retrying the
> map operation and might race with the pager. Qemu-dm being a prime example.

Yes, I think thats a real issue. The concept looks ok to me.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:22:23 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:22:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVk6q-000390-Bi; Wed, 30 Nov 2011 13:22:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVk6o-00038r-Oh
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:21:58 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322659279!661512!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDMzMzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDMzMzI=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28125 invoked from network); 30 Nov 2011 13:21:20 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-2.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Nov 2011 13:21:20 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322659279; l=735;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=TU6S2lDOlxbsgZ/CzjWez7ZeyKc=;
	b=QlzBzu8Px+YLbxyUHwJYxvPLwgJGfu1KFrnFgsNCI6/s1RbeGWJMdIOeX8buoU4wpwA
	wK9dB9zaHpnXnffdbGxk2VcIZ9FZXXcfKWKkUPlN8a3U+9FIdnSu33u7sBsIKiZKbhrp+
	cdvRY9HkQqDpP2o7iF9bIQdL+LLhFH6eWzk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by smtp.strato.de (fruni mo23) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id I05c9enAUDIAQb ;
	Wed, 30 Nov 2011 14:21:00 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3884118637; Wed, 30 Nov 2011 14:21:00 +0100 (CET)
Date: Wed, 30 Nov 2011 14:21:00 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111130132100.GA17890@aepfle.de>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1322603559@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Fix correctness race in
 xc_mem_paging_prep
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Andres Lagar-Cavilla wrote:

> P2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
> transitions to the next state in the paging state machine for this page. 
> Foreign mappings of the gfn will now succeed. This is the key idea, as it 
> allows the pager to now map the gfn and fill in its contents.
> 
> Unfortunately, it also allows any other foreign mapper to map the gfn and read
> its contents. This is particularly dangerous when the populate is launched
> by a foreign mapper in the first place, which will be actively retrying the
> map operation and might race with the pager. Qemu-dm being a prime example.

Yes, I think thats a real issue. The concept looks ok to me.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:26:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkAx-0003J6-9A; Wed, 30 Nov 2011 13:26:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVkAw-0003Iw-G2
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:26:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322659515!50343531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15729 invoked from network); 30 Nov 2011 13:25:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 13:25:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9207145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 13:25:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 13:25:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 30 Nov 2011 13:25:34 +0000
In-Reply-To: <201111301303.23851.arnd@arndb.de>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<201111301303.23851.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322659535.31810.97.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 13:03 +0000, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Stefano Stabellini wrote:
> > On Tue, 29 Nov 2011, Arnd Bergmann wrote:
> > > On Tuesday 29 November 2011, Stefano Stabellini wrote:
> > > 
> > > Do you have a pointer to the kernel sources for the Linux guest?
> > 
> > We have very few changes to the Linux kernel at the moment (only 3
> > commits!), just enough to be able to issue hypercalls and start a PV
> > console.
> > 
> > A git branch is available here (not ready for submission):
> > 
> > git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
> 
> Ok, interesting. There really isn't much of the platform support
> that I was expecting there. I finally found the information
> I was looking for in the xen construct_dom0() function:
> 
>  167     regs->r0 = 0; /* SBZ */
>  168     regs->r1 = 2272; /* Machine NR: Versatile Express */
>  169     regs->r2 = 0xc0000100; /* ATAGS */
> 
> What this means is that you are emulating the current ARM/Keil reference
> board, at least to the degree that is necessary to get the guest started.
> 
> This is the same choice people have made for KVM, but it's not
> necessarily the best option in the long run. In particular, this
> board has a lot of hardware that you claim to have by putting the
> machine number there, when you don't really want to emulate it.

This code is actually setting up dom0 which (for the most part) sees the
real hardware.

The hardcoding of the platform is just a short term hack.

> Pawell Moll is working on a variant of the vexpress code that uses
> the flattened device tree to describe the present hardware [1], and
> I think that would be a much better target for an official release.
> Ideally, the hypervisor should provide the device tree binary (dtb)
> to the guest OS describing the hardware that is actually there.

Agreed. Our intention was to use DT so this fits perfectly with our
plans.

For dom0 we would expose a (possibly filtered) version of the DT given
to us by the firmware (e.g. we might hide a serial port to reserve it
for Xen's use, we'd likely fiddle with the memory map etc).

For domU the DT would presumably be constructed by the toolstack (in
dom0 userspace) as appropriate for the guest configuration. I guess this
needn't correspond to any particular "real" hardware platform.

> This would also be the place where you tell the guest that it should
> look for PV devices. I'm not familiar with how Xen announces PV
> devices to the guest on other architectures, but you have the
> choice between providing a full "binding", i.e. a formal specification
> in device tree format for the guest to detect PV devices in the
> same way as physical or emulated devices, or just providing a single
> place in the device tree in which the guest detects the presence
> of a xen device bus and then uses hcalls to find the devices on that
> bus.

On x86 there is an emulated PCI device which serves as the hooking point
for the PV drivers. For ARM I don't think it would be unreasonable to
have a DT entry instead. I think it would be fine just represent the
root of the "xenbus" and further discovery would occur using the normal
xenbus mechanisms (so not a full binding). AIUI for buses which are
enumerable this is the preferred DT scheme to use.

> Another topic is the question whether there are any hcalls that
> we should try to standardize before we get another architecture
> with multiple conflicting hcall APIs as we have on x86 and powerpc.

The hcall API we are currently targeting is the existing Xen API (at
least the generic parts of it). These generally deal with fairly Xen
specific concepts like grant tables etc.

Ian.

> 
> 	Arnd
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg149604.html
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:26:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkAx-0003J6-9A; Wed, 30 Nov 2011 13:26:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVkAw-0003Iw-G2
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:26:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322659515!50343531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15729 invoked from network); 30 Nov 2011 13:25:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 13:25:15 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9207145"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 13:25:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 13:25:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 30 Nov 2011 13:25:34 +0000
In-Reply-To: <201111301303.23851.arnd@arndb.de>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<201111301303.23851.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322659535.31810.97.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 13:03 +0000, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Stefano Stabellini wrote:
> > On Tue, 29 Nov 2011, Arnd Bergmann wrote:
> > > On Tuesday 29 November 2011, Stefano Stabellini wrote:
> > > 
> > > Do you have a pointer to the kernel sources for the Linux guest?
> > 
> > We have very few changes to the Linux kernel at the moment (only 3
> > commits!), just enough to be able to issue hypercalls and start a PV
> > console.
> > 
> > A git branch is available here (not ready for submission):
> > 
> > git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
> 
> Ok, interesting. There really isn't much of the platform support
> that I was expecting there. I finally found the information
> I was looking for in the xen construct_dom0() function:
> 
>  167     regs->r0 = 0; /* SBZ */
>  168     regs->r1 = 2272; /* Machine NR: Versatile Express */
>  169     regs->r2 = 0xc0000100; /* ATAGS */
> 
> What this means is that you are emulating the current ARM/Keil reference
> board, at least to the degree that is necessary to get the guest started.
> 
> This is the same choice people have made for KVM, but it's not
> necessarily the best option in the long run. In particular, this
> board has a lot of hardware that you claim to have by putting the
> machine number there, when you don't really want to emulate it.

This code is actually setting up dom0 which (for the most part) sees the
real hardware.

The hardcoding of the platform is just a short term hack.

> Pawell Moll is working on a variant of the vexpress code that uses
> the flattened device tree to describe the present hardware [1], and
> I think that would be a much better target for an official release.
> Ideally, the hypervisor should provide the device tree binary (dtb)
> to the guest OS describing the hardware that is actually there.

Agreed. Our intention was to use DT so this fits perfectly with our
plans.

For dom0 we would expose a (possibly filtered) version of the DT given
to us by the firmware (e.g. we might hide a serial port to reserve it
for Xen's use, we'd likely fiddle with the memory map etc).

For domU the DT would presumably be constructed by the toolstack (in
dom0 userspace) as appropriate for the guest configuration. I guess this
needn't correspond to any particular "real" hardware platform.

> This would also be the place where you tell the guest that it should
> look for PV devices. I'm not familiar with how Xen announces PV
> devices to the guest on other architectures, but you have the
> choice between providing a full "binding", i.e. a formal specification
> in device tree format for the guest to detect PV devices in the
> same way as physical or emulated devices, or just providing a single
> place in the device tree in which the guest detects the presence
> of a xen device bus and then uses hcalls to find the devices on that
> bus.

On x86 there is an emulated PCI device which serves as the hooking point
for the PV drivers. For ARM I don't think it would be unreasonable to
have a DT entry instead. I think it would be fine just represent the
root of the "xenbus" and further discovery would occur using the normal
xenbus mechanisms (so not a full binding). AIUI for buses which are
enumerable this is the preferred DT scheme to use.

> Another topic is the question whether there are any hcalls that
> we should try to standardize before we get another architecture
> with multiple conflicting hcall APIs as we have on x86 and powerpc.

The hcall API we are currently targeting is the existing Xen API (at
least the generic parts of it). These generally deal with fairly Xen
specific concepts like grant tables etc.

Ian.

> 
> 	Arnd
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg149604.html
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkNq-0003Xz-Mx; Wed, 30 Nov 2011 13:39:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVkNo-0003Xt-JE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:39:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322660332!6968238!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15422 invoked from network); 30 Nov 2011 13:38:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 13:38:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322660332; l=398;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=st+72Q4W6qi1Tf25YIvnWfZ1FDk=;
	b=U0311fdlm/AO6QQLbsD+U1VQs9HQDwwf7Sk3RZSRi8aHSDQ0SyRROviJRoDFtvlcpsd
	f6w2P40UifY0AxJ5/AmC66lnfWaj8smr8lw4D33bMqWm/B2M5i+aNLM2GV+BrG23OwRmY
	74efbijhHREakU0pRpeWaRGn9oTU9XLCVTk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by smtp.strato.de (jimi mo59) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g05844nAUDALpE ;
	Wed, 30 Nov 2011 14:38:47 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4F89F18637; Wed, 30 Nov 2011 14:38:47 +0100 (CET)
Date: Wed, 30 Nov 2011 14:38:47 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111130133847.GA22200@aepfle.de>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
	<20111130124650.GA15723@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130124650.GA15723@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, Olaf Hering wrote:

> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
> 
> > Check that the valid mfn is the one we are mapping, not the
> > mfn of the page table of the foreign domain.
> > 
> > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Acked-by: Olaf Hering <olaf@aepfle.de>
> 

There are more issues like that in this file, not just the l1e.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:39:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkNq-0003Xz-Mx; Wed, 30 Nov 2011 13:39:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVkNo-0003Xt-JE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:39:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-216.messagelabs.com!1322660332!6968238!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15422 invoked from network); 30 Nov 2011 13:38:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 13:38:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322660332; l=398;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=st+72Q4W6qi1Tf25YIvnWfZ1FDk=;
	b=U0311fdlm/AO6QQLbsD+U1VQs9HQDwwf7Sk3RZSRi8aHSDQ0SyRROviJRoDFtvlcpsd
	f6w2P40UifY0AxJ5/AmC66lnfWaj8smr8lw4D33bMqWm/B2M5i+aNLM2GV+BrG23OwRmY
	74efbijhHREakU0pRpeWaRGn9oTU9XLCVTk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by smtp.strato.de (jimi mo59) (RZmta 26.10 AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id g05844nAUDALpE ;
	Wed, 30 Nov 2011 14:38:47 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4F89F18637; Wed, 30 Nov 2011 14:38:47 +0100 (CET)
Date: Wed, 30 Nov 2011 14:38:47 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111130133847.GA22200@aepfle.de>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
	<20111130124650.GA15723@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111130124650.GA15723@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, Olaf Hering wrote:

> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
> 
> > Check that the valid mfn is the one we are mapping, not the
> > mfn of the page table of the foreign domain.
> > 
> > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Acked-by: Olaf Hering <olaf@aepfle.de>
> 

There are more issues like that in this file, not just the l1e.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:45:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:45:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkSv-0003jD-Mh; Wed, 30 Nov 2011 13:44:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RVkSt-0003il-PE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:44:47 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322660649!3707602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29885 invoked from network); 30 Nov 2011 13:44:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 13:44:09 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9207705"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 13:44:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 13:44:09 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RVkSG-0003DJ-Km;
	Wed, 30 Nov 2011 13:44:08 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RVkS0-00063a-VV;
	Wed, 30 Nov 2011 13:43:53 +0000
Date: Wed, 30 Nov 2011 13:43:52 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111130134352.GM28670@spongy.cam.xci-test.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
	<20174.37746.873433.6131@mariner.uk.xensource.com>
	<20111125092908.GA11790@spongy.cam.xci-test.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111125092908.GA11790@spongy.cam.xci-test.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for
 pt_pci_host_read/write
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11 09:29, Jean Guyader wrote:
> On 24/11 06:56, Ian Jackson wrote:
> > Jean Guyader writes ("[Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for pt_pci_host_read/write"):
> > > pt_pci_host_read/write now takes a struct pci_dev*.
> > 
> > Why ?
> > 
> > Ian.
> 
> I found it more elegant that having to do thing like that:
>         val = pt_pci_host_read(0, PCI_SLOT(pci_dev->devfn),
>                 0, config_addr, len);
> pci_dev is already of the right type.
> 
> With the old approach you would give a B:D:F to pt_pci_host_read
> then the function will call to libpci to get a pci_dev from that
> to do the config space access. In pretty much all the cases we
> already have a pci_dev, so I figured that we should be using it
> directly.
> 

Hi Ian,

Any thought about this serie?

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:45:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:45:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkSv-0003jD-Mh; Wed, 30 Nov 2011 13:44:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RVkSt-0003il-PE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 13:44:47 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1322660649!3707602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29885 invoked from network); 30 Nov 2011 13:44:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 13:44:09 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; 
   d="scan'208";a="9207705"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 13:44:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 13:44:09 +0000
Received: from spongy.cam.xci-test.com ([10.80.248.53])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<jean.guyader@eu.citrix.com>)	id 1RVkSG-0003DJ-Km;
	Wed, 30 Nov 2011 13:44:08 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RVkS0-00063a-VV;
	Wed, 30 Nov 2011 13:43:53 +0000
Date: Wed, 30 Nov 2011 13:43:52 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20111130134352.GM28670@spongy.cam.xci-test.com>
References: <1322056319-19725-1-git-send-email-jean.guyader@eu.citrix.com>
	<20174.37746.873433.6131@mariner.uk.xensource.com>
	<20111125092908.GA11790@spongy.cam.xci-test.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111125092908.GA11790@spongy.cam.xci-test.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for
 pt_pci_host_read/write
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/11 09:29, Jean Guyader wrote:
> On 24/11 06:56, Ian Jackson wrote:
> > Jean Guyader writes ("[Xen-devel] [PATCH 1/3] qemu-xen: Change prototype for pt_pci_host_read/write"):
> > > pt_pci_host_read/write now takes a struct pci_dev*.
> > 
> > Why ?
> > 
> > Ian.
> 
> I found it more elegant that having to do thing like that:
>         val = pt_pci_host_read(0, PCI_SLOT(pci_dev->devfn),
>                 0, config_addr, len);
> pci_dev is already of the right type.
> 
> With the old approach you would give a B:D:F to pt_pci_host_read
> then the function will call to libpci to get a pci_dev from that
> to do the config space access. In pretty much all the cases we
> already have a pci_dev, so I figured that we should be using it
> directly.
> 

Hi Ian,

Any thought about this serie?

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:49:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:49:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkXG-0003uV-Ee; Wed, 30 Nov 2011 13:49:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.baruchi@gmail.com>)
	id 1RVkXF-0003uM-IK; Wed, 30 Nov 2011 13:49:17 +0000
X-Env-Sender: mail.baruchi@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322660883!48007168!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20175 invoked from network); 30 Nov 2011 13:48:05 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 13:48:05 -0000
Received: by vcbfo1 with SMTP id fo1so470856vcb.30
	for <multiple recipients>; Wed, 30 Nov 2011 05:48:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=zRJaZ43dT8IhYQaRMu+K+hqEM7SL8V3Xk+nE1diwxuI=;
	b=QvVPv1qwFcBlXI8Cg5zO440YRhJw0+/BqOXsgWlIKv88G18whIQJWhrXKUcYGWBqYa
	Z3b962FiSNVxrSx9EOvBq2tFKPr6sAzvkU3bF2uvYZyoL1jy+xpc8CFWaLmIb6bzJj0k
	41jHw2mZw71gE4EoPAZAusB0gqOsf4wIE/NTc=
MIME-Version: 1.0
Received: by 10.220.155.66 with SMTP id r2mr424594vcw.42.1322660922457; Wed,
	30 Nov 2011 05:48:42 -0800 (PST)
Received: by 10.52.187.4 with HTTP; Wed, 30 Nov 2011 05:48:42 -0800 (PST)
Date: Wed, 30 Nov 2011 11:48:42 -0200
Message-ID: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
From: Artur Baruchi <mail.baruchi@gmail.com>
To: xen-users <Xen-users@lists.xensource.com>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi.

Im installing a VM to run a benchmark, Im able to install the VM issue
the first boot (to setup network configurations), but if I reboot the
VM it just hangs and do not boot. I've re-installed the machine but no
success. Follow some details:

- Dom0: Opensuse 11.3 (x86_64), kernel 2.6.34-12-xen,
xen-4.0.0_21091_05-6.6.x86_64
- DomU: Full Virtualization, Opensuse 11.3 (x86_64), kernel 2.6.34-12-desktop

Some errors in message file (not sure that this errors mean something
for this problem):
Nov 27 23:02:17 linuxtemp01 kernel: [ 5681.075141] ata1: link is slow
to respond, please be patient (ready=0)
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073141] ata1: device not
ready (errno=-16), forcing hardreset
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073236] ata1: soft resetting link
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.228817] ata1.00: configured
for MWDMA2
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230503] ata1.01: configured
for MWDMA1
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230508] ata1.00: device
reported invalid CHS sector 0
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230515] ata1: EH complete
Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701259] ata1.01: exception
Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701262] ata1.01: failed
command: WRITE DMA EXT
Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701265] ata1.01: cmd
35/00:98:ef:c0:24/00:02:02:00:00/f0 tag 0 dma 339968 out
Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701266]          res
40/00:01:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701268] ata1.01: status: { DRDY }
Nov 27 23:08:29 linuxtemp01 kernel: [ 6052.750078] ata1: link is slow
to respond, please be patient (ready=0)
Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748079] ata1: device not
ready (errno=-16), forcing hardreset
Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748134] ata1: soft resetting link
Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.902320] ata1.00: configured
for MWDMA2
Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903499] ata1.01: configured
for MWDMA1
Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903503] ata1.01: device
reported invalid CHS sector 0
Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903506] ata1: EH complete

My problem is very similar to this one:
http://web.archiveorange.com/archive/v/wmeLDfqXdkxOOQURv2Ak

But the workaround for this issue is not working for me.

Any help will be welcome.

Thanks in advance.

Att.
Artur Baruchi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 13:49:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 13:49:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkXG-0003uV-Ee; Wed, 30 Nov 2011 13:49:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.baruchi@gmail.com>)
	id 1RVkXF-0003uM-IK; Wed, 30 Nov 2011 13:49:17 +0000
X-Env-Sender: mail.baruchi@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1322660883!48007168!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20175 invoked from network); 30 Nov 2011 13:48:05 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 13:48:05 -0000
Received: by vcbfo1 with SMTP id fo1so470856vcb.30
	for <multiple recipients>; Wed, 30 Nov 2011 05:48:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=zRJaZ43dT8IhYQaRMu+K+hqEM7SL8V3Xk+nE1diwxuI=;
	b=QvVPv1qwFcBlXI8Cg5zO440YRhJw0+/BqOXsgWlIKv88G18whIQJWhrXKUcYGWBqYa
	Z3b962FiSNVxrSx9EOvBq2tFKPr6sAzvkU3bF2uvYZyoL1jy+xpc8CFWaLmIb6bzJj0k
	41jHw2mZw71gE4EoPAZAusB0gqOsf4wIE/NTc=
MIME-Version: 1.0
Received: by 10.220.155.66 with SMTP id r2mr424594vcw.42.1322660922457; Wed,
	30 Nov 2011 05:48:42 -0800 (PST)
Received: by 10.52.187.4 with HTTP; Wed, 30 Nov 2011 05:48:42 -0800 (PST)
Date: Wed, 30 Nov 2011 11:48:42 -0200
Message-ID: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
From: Artur Baruchi <mail.baruchi@gmail.com>
To: xen-users <Xen-users@lists.xensource.com>, Xen-devel@lists.xensource.com
Subject: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi.

Im installing a VM to run a benchmark, Im able to install the VM issue
the first boot (to setup network configurations), but if I reboot the
VM it just hangs and do not boot. I've re-installed the machine but no
success. Follow some details:

- Dom0: Opensuse 11.3 (x86_64), kernel 2.6.34-12-xen,
xen-4.0.0_21091_05-6.6.x86_64
- DomU: Full Virtualization, Opensuse 11.3 (x86_64), kernel 2.6.34-12-desktop

Some errors in message file (not sure that this errors mean something
for this problem):
Nov 27 23:02:17 linuxtemp01 kernel: [ 5681.075141] ata1: link is slow
to respond, please be patient (ready=0)
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073141] ata1: device not
ready (errno=-16), forcing hardreset
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073236] ata1: soft resetting link
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.228817] ata1.00: configured
for MWDMA2
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230503] ata1.01: configured
for MWDMA1
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230508] ata1.00: device
reported invalid CHS sector 0
Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230515] ata1: EH complete
Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701259] ata1.01: exception
Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701262] ata1.01: failed
command: WRITE DMA EXT
Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701265] ata1.01: cmd
35/00:98:ef:c0:24/00:02:02:00:00/f0 tag 0 dma 339968 out
Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701266]          res
40/00:01:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701268] ata1.01: status: { DRDY }
Nov 27 23:08:29 linuxtemp01 kernel: [ 6052.750078] ata1: link is slow
to respond, please be patient (ready=0)
Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748079] ata1: device not
ready (errno=-16), forcing hardreset
Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748134] ata1: soft resetting link
Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.902320] ata1.00: configured
for MWDMA2
Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903499] ata1.01: configured
for MWDMA1
Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903503] ata1.01: device
reported invalid CHS sector 0
Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903506] ata1: EH complete

My problem is very similar to this one:
http://web.archiveorange.com/archive/v/wmeLDfqXdkxOOQURv2Ak

But the workaround for this issue is not working for me.

Any help will be welcome.

Thanks in advance.

Att.
Artur Baruchi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:01:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:01:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkiA-0004AE-RE; Wed, 30 Nov 2011 14:00:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RVki9-0004A5-7h
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:00:33 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322661593!5657487!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28568 invoked from network); 30 Nov 2011 13:59:54 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	30 Nov 2011 13:59:54 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RVkhU-00012A-9d
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 05:59:52 -0800
Date: Wed, 30 Nov 2011 05:59:52 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1322661592292-5035582.post@n5.nabble.com>
In-Reply-To: <1322658156.31810.86.camel@zakaz.uk.xensource.com>
References: <1322219529495-5022556.post@n5.nabble.com>
	<1322658156.31810.86.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for reply and sorry for my mistake on write here, in the configuration
I have do right with :cdrom ('phy:/dev/scd0,xvdc:cdrom,r'), i have also
report this problem time ago without reply:
http://xen.1045712.n5.nabble.com/Cdrom-not-working-on-Lucid-domU-td4586693.html
The toolstack use now is always xm, and test i write in first message is all
with :cdrom.

I have also one question about xl, probably soon I begin to test xen 4.2
from unstable with toolstack xl, I see on xl configuration link disk format
support raw, qcow, qcow2, vhd with deprecated prefix (tap2...) ignored.
The blktap continue to be used automatically based on format choise and if
not present use "file" or it will not need additional modules?


--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5022556p5035582.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:01:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:01:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkiA-0004AE-RE; Wed, 30 Nov 2011 14:00:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RVki9-0004A5-7h
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:00:33 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1322661593!5657487!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28568 invoked from network); 30 Nov 2011 13:59:54 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	30 Nov 2011 13:59:54 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RVkhU-00012A-9d
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 05:59:52 -0800
Date: Wed, 30 Nov 2011 05:59:52 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1322661592292-5035582.post@n5.nabble.com>
In-Reply-To: <1322658156.31810.86.camel@zakaz.uk.xensource.com>
References: <1322219529495-5022556.post@n5.nabble.com>
	<1322658156.31810.86.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for reply and sorry for my mistake on write here, in the configuration
I have do right with :cdrom ('phy:/dev/scd0,xvdc:cdrom,r'), i have also
report this problem time ago without reply:
http://xen.1045712.n5.nabble.com/Cdrom-not-working-on-Lucid-domU-td4586693.html
The toolstack use now is always xm, and test i write in first message is all
with :cdrom.

I have also one question about xl, probably soon I begin to test xen 4.2
from unstable with toolstack xl, I see on xl configuration link disk format
support raw, qcow, qcow2, vhd with deprecated prefix (tap2...) ignored.
The blktap continue to be used automatically based on format choise and if
not present use "file" or it will not need additional modules?


--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5022556p5035582.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:02:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:02:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkkA-0004G4-Dd; Wed, 30 Nov 2011 14:02:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVkk8-0004Fl-W7
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:02:37 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322661717!5611703!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1056 invoked from network); 30 Nov 2011 14:01:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315195200"; d="scan'208";a="19523324"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:01:56 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 30 Nov 2011
	09:01:56 -0500
Message-ID: <4ED63753.4000007@citrix.com>
Date: Wed, 30 Nov 2011 14:01:55 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ED52AF9.2080200@citrix.com>
	<4ED6037302000078000644A3@nat28.tlf.novell.com>
In-Reply-To: <4ED6037302000078000644A3@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/11/11 09:20, Jan Beulich wrote:
>>>> On 29.11.11 at 19:56, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> As I have little to no knowledge of this stage of the boot process, is
>> this a sensible way to be setting up the per_cpu areas?  I have a
>> sneaking suspicion that it will fall over if a CPU is onlined after
>> boot, and may also fall over if a CPU is offlined and reonlined later. 
>> There appears to be no infrastructure currently in place for this type
>> of initialization, which is quite possibly why the code exists in its
>> current form.
> I actually wonder how you came to those 4 statements you make in
> the description - none of these seem to me like they are really an
> issue (this would instead be plain bugs in Dom0). Did you actually look
> at the existing Dom0 implementation(s)?
>
> Further, while not being a huge waste of memory, it still is one in case
> kexec gets never enabled, especially when considering a Dom0 kernel
> that's being built without CONFIG_KEXEC (or an incapable on, like any
> pv-ops kernel to date). So I also conceptually question that change.
>
> Jan

We (XenServer) have had many cases of the kexec path failing on customer
boxes under weird and seemingly inexplicable circumstances.  This is why
I am working on trying to bullet-proofing the entire path.

We have 1 ticket where the contents of a crash note is clearly bogus (a
PRSTATUS is not 2GB long).  We have a ticket where it appears that the
kdump kernel has failed to reassemble /proc/vmcore from elfcorehdr as a
few pcpus worth of crash notes are missing.  I seem to remember a ticket
from before my time with a crash while writing the crash notes in Xen
itself. We even have a ticket stating that you get different crash notes
depending on whether you crash using the Xen debug keys (crash notes
appear completely bogus) or /proc/sysrq-trigger in dom0 (seems to be fine).

All of these are uncertain on reproducibility (except the final one
which was shown to reproduce on Xen-3.x and not on Xen-4.x so was not
investigated further) and have a habit of being unreproducible on any of
our local hardware, which makes fixing the problems tricky.

So yes -  the 4 points I have made are certainly not regular or common
behavior, but given some of the tickets we have, I am fairly sure it is
not a bug-free path.  I have checked the 2.6.32 implementation of dom0's
side of this and agree that it looks ok.  However, it is my opinion that
relying on a certain hypercalling pattern from dom0 is a perilous route
for Xen, whether it is likely for that pattern to change in the future
or not.

Having said all of this, I agree with your second paragraph.  As already
noted in my other email in this thread, I need to change the
implementation of this, so I will key the initial allocation of memory
on whether crashkernel= has been passed.  This should be sufficient
indication as to whether the user minds having the space allocated or not.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:02:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:02:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkkA-0004G4-Dd; Wed, 30 Nov 2011 14:02:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVkk8-0004Fl-W7
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:02:37 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322661717!5611703!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1056 invoked from network); 30 Nov 2011 14:01:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:01:58 -0000
X-IronPort-AV: E=Sophos;i="4.69,596,1315195200"; d="scan'208";a="19523324"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:01:56 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 30 Nov 2011
	09:01:56 -0500
Message-ID: <4ED63753.4000007@citrix.com>
Date: Wed, 30 Nov 2011 14:01:55 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4ED52AF9.2080200@citrix.com>
	<4ED6037302000078000644A3@nat28.tlf.novell.com>
In-Reply-To: <4ED6037302000078000644A3@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot
	time
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/11/11 09:20, Jan Beulich wrote:
>>>> On 29.11.11 at 19:56, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> As I have little to no knowledge of this stage of the boot process, is
>> this a sensible way to be setting up the per_cpu areas?  I have a
>> sneaking suspicion that it will fall over if a CPU is onlined after
>> boot, and may also fall over if a CPU is offlined and reonlined later. 
>> There appears to be no infrastructure currently in place for this type
>> of initialization, which is quite possibly why the code exists in its
>> current form.
> I actually wonder how you came to those 4 statements you make in
> the description - none of these seem to me like they are really an
> issue (this would instead be plain bugs in Dom0). Did you actually look
> at the existing Dom0 implementation(s)?
>
> Further, while not being a huge waste of memory, it still is one in case
> kexec gets never enabled, especially when considering a Dom0 kernel
> that's being built without CONFIG_KEXEC (or an incapable on, like any
> pv-ops kernel to date). So I also conceptually question that change.
>
> Jan

We (XenServer) have had many cases of the kexec path failing on customer
boxes under weird and seemingly inexplicable circumstances.  This is why
I am working on trying to bullet-proofing the entire path.

We have 1 ticket where the contents of a crash note is clearly bogus (a
PRSTATUS is not 2GB long).  We have a ticket where it appears that the
kdump kernel has failed to reassemble /proc/vmcore from elfcorehdr as a
few pcpus worth of crash notes are missing.  I seem to remember a ticket
from before my time with a crash while writing the crash notes in Xen
itself. We even have a ticket stating that you get different crash notes
depending on whether you crash using the Xen debug keys (crash notes
appear completely bogus) or /proc/sysrq-trigger in dom0 (seems to be fine).

All of these are uncertain on reproducibility (except the final one
which was shown to reproduce on Xen-3.x and not on Xen-4.x so was not
investigated further) and have a habit of being unreproducible on any of
our local hardware, which makes fixing the problems tricky.

So yes -  the 4 points I have made are certainly not regular or common
behavior, but given some of the tickets we have, I am fairly sure it is
not a bug-free path.  I have checked the 2.6.32 implementation of dom0's
side of this and agree that it looks ok.  However, it is my opinion that
relying on a certain hypercalling pattern from dom0 is a perilous route
for Xen, whether it is likely for that pattern to change in the future
or not.

Having said all of this, I agree with your second paragraph.  As already
noted in my other email in this thread, I need to change the
implementation of this, so I will key the initial allocation of memory
on whether crashkernel= has been passed.  This should be sufficient
indication as to whether the user minds having the space allocated or not.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:15:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkwX-0004WF-In; Wed, 30 Nov 2011 14:15:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkwV-0004W8-8J
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:15:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322662484!4420498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27507 invoked from network); 30 Nov 2011 14:14:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:14:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9208575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:14:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:14:44 +0000
Date: Wed, 30 Nov 2011 14:15:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 00/19] xl.pod.1 updates and fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series containes few updates and fixes to xl.pod.1.

Stefano Stabellini (19):
      xl.pod.1: add a barebone description of tmem commands
      xl.pod.1: add a description of console options
      xl.pod.1: improve create documentation
      xl.pod.1: add a description of the global options
      xl.pod.1: order subcommands alphabetically
      xl.pod.1: remove the two FIXME
      xl.pod.1: add a reference to create in the -e option
      xl.pod.1: state when a command requires PV drivers installed
      xl.pod.1: better description for the sysreq subcommand
      xl.pod.1: state when a subcommand is only available to HVM guests
      xl.pod.1: introduce a TO BE DOCUMENTED section
      xl.pod.1: improve the debug-keys subcommand description
      xl.pod.1: improve the description of the info subcommand
      xl.pod.1: improve the description of pci-list-assignable-devices
      xl.pod.1: remove dry-run option from create and cpupool-create
      xl.pod.1: improve description of virtual device subcommands
      xl.pod.1: remove AUTHORS section
      xl.pod.1: add a refence to http://wiki.xen.org/xenwiki/ReportingBugs
      xl.pod.1: add a note about autoballoon and dom0_mem

 docs/man/xl.pod.1 |  317 ++++++++++++++++++++++++++++++++++++++---------------
 1 files changed, 229 insertions(+), 88 deletions(-)


A git branch based on xen-unstable is available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git docs

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:15:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkwX-0004WF-In; Wed, 30 Nov 2011 14:15:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkwV-0004W8-8J
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:15:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322662484!4420498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27507 invoked from network); 30 Nov 2011 14:14:44 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:14:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9208575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:14:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:14:44 +0000
Date: Wed, 30 Nov 2011 14:15:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 00/19] xl.pod.1 updates and fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series containes few updates and fixes to xl.pod.1.

Stefano Stabellini (19):
      xl.pod.1: add a barebone description of tmem commands
      xl.pod.1: add a description of console options
      xl.pod.1: improve create documentation
      xl.pod.1: add a description of the global options
      xl.pod.1: order subcommands alphabetically
      xl.pod.1: remove the two FIXME
      xl.pod.1: add a reference to create in the -e option
      xl.pod.1: state when a command requires PV drivers installed
      xl.pod.1: better description for the sysreq subcommand
      xl.pod.1: state when a subcommand is only available to HVM guests
      xl.pod.1: introduce a TO BE DOCUMENTED section
      xl.pod.1: improve the debug-keys subcommand description
      xl.pod.1: improve the description of the info subcommand
      xl.pod.1: improve the description of pci-list-assignable-devices
      xl.pod.1: remove dry-run option from create and cpupool-create
      xl.pod.1: improve description of virtual device subcommands
      xl.pod.1: remove AUTHORS section
      xl.pod.1: add a refence to http://wiki.xen.org/xenwiki/ReportingBugs
      xl.pod.1: add a note about autoballoon and dom0_mem

 docs/man/xl.pod.1 |  317 ++++++++++++++++++++++++++++++++++++++---------------
 1 files changed, 229 insertions(+), 88 deletions(-)


A git branch based on xen-unstable is available here:

git://xenbits.xen.org/people/sstabellini/xen-unstable.git docs

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxS-0004aZ-EQ; Wed, 30 Nov 2011 14:16:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxQ-0004ZS-Cz
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27358 invoked from network); 30 Nov 2011 14:15:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523796"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:43 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ3021387;
	Wed, 30 Nov 2011 06:15:32 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:22 +0000
Message-ID: <1322662596-30764-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 05/19] xl.pod.1: order subcommands
	alphabetically
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   59 ++++++++++++++++++++++++++---------------------------
 1 files changed, 29 insertions(+), 30 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 292b3c6..d860c00 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -68,6 +68,11 @@ previously, most commands take I<domain-id> as the first parameter.
 
 =over 4
 
+=item B<button-press> I<domain-id> I<button>
+
+Indicate an ACPI button press to the domain. I<button> is may be 'power' or
+'sleep'.
+
 =item B<create> [I<configfile>] [I<OPTIONS>]
 
 The create subcommand takes a config file as first argument: see
@@ -155,20 +160,6 @@ Connect to console number I<NUM>. Console numbers start from 0.
 
 =back
 
-=item B<vncviewer> [I<OPTIONS>] I<domain-id>
-
-Attach to domain's VNC server, forking a vncviewer process.
-
-B<OPTIONS>
-
-=over 4
-
-=item I<--autopass>
-
-Pass VNC password to vncviewer via stdin.
-
-=back
-
 =item B<destroy> I<domain-id>
 
 Immediately terminate the domain I<domain-id>.  This doesn't give the
@@ -195,6 +186,10 @@ I<filename> specified, without pausing the domain.  The dump file will
 be written to a distribution specific directory for dump files.  Such
 as: /var/lib/xen/dump or /var/xen/dump.
 
+=item B<getenforce>
+
+Returns the current enforcing mode of the Flask Xen security module.
+
 =item B<help> [I<--long>]
 
 Displays the short help message (i.e. common commands).
@@ -298,6 +293,10 @@ less utilized than a high CPU workload.  Consider yourself warned.
 
 =back
 
+=item B<loadpolicy> I<policyfile>
+
+Loads a new policy int the Flask Xen security module.
+
 =item B<mem-max> I<domain-id> I<mem>
 
 Specify the maximum amount of memory the domain is able to use, appending 't'
@@ -386,6 +385,10 @@ Enable debug messages.
 
 =back
 
+=item B<setenforce> I<1|0|Enforcing|Permissive>
+
+Sets the current enforcing mode of the Flask Xen security module
+
 =item B<save> [I<OPTIONS>] I<domain-id> I<CheckpointFile> [I<ConfigFile>]
 
 Saves a running domain to a state file so that it can be restored
@@ -395,7 +398,6 @@ B<xl restore> restores from this checkpoint file.
 Passing a config file argument allows the user to manually select the VM config
 file used to create the domain.
 
-
 =over 4
 
 =item B<-c>
@@ -433,6 +435,11 @@ Send a I<Magic System Request> signal to the domain.  For more
 information on available magic sys req operations, see sysrq.txt in
 your Linux Kernel sources.
 
+=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>]
+
+Send a trigger to a domain, where the trigger can be: nmi, reset, init, power
+or sleep.  Optionally a specific vcpu number can be passed as an argument.
+
 =item B<unpause> I<domain-id>
 
 Moves a domain out of the paused state.  This will allow a previously
@@ -472,27 +479,19 @@ different run state is appropriate.  Pinning can be used to restrict
 this, by ensuring certain VCPUs can only run on certain physical
 CPUs.
 
-=item B<button-press> I<domain-id> I<button>
-
-Indicate an ACPI button press to the domain. I<button> is may be 'power' or
-'sleep'.
-
-=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>]
-
-Send a trigger to a domain, where the trigger can be: nmi, reset, init, power
-or sleep.  Optionally a specific vcpu number can be passed as an argument.
+=item B<vncviewer> [I<OPTIONS>] I<domain-id>
 
-=item B<getenforce>
+Attach to domain's VNC server, forking a vncviewer process.
 
-Returns the current enforcing mode of the Flask Xen security module.
+B<OPTIONS>
 
-=item B<setenforce> I<1|0|Enforcing|Permissive>
+=over 4
 
-Sets the current enforcing mode of the Flask Xen security module
+=item I<--autopass>
 
-=item B<loadpolicy> I<policyfile>
+Pass VNC password to vncviewer via stdin.
 
-Loads a new policy int the Flask Xen security module.
+=back
 
 =back
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxS-0004aZ-EQ; Wed, 30 Nov 2011 14:16:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxQ-0004ZS-Cz
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27358 invoked from network); 30 Nov 2011 14:15:27 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:27 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523796"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:43 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ3021387;
	Wed, 30 Nov 2011 06:15:32 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:22 +0000
Message-ID: <1322662596-30764-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 05/19] xl.pod.1: order subcommands
	alphabetically
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   59 ++++++++++++++++++++++++++---------------------------
 1 files changed, 29 insertions(+), 30 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 292b3c6..d860c00 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -68,6 +68,11 @@ previously, most commands take I<domain-id> as the first parameter.
 
 =over 4
 
+=item B<button-press> I<domain-id> I<button>
+
+Indicate an ACPI button press to the domain. I<button> is may be 'power' or
+'sleep'.
+
 =item B<create> [I<configfile>] [I<OPTIONS>]
 
 The create subcommand takes a config file as first argument: see
@@ -155,20 +160,6 @@ Connect to console number I<NUM>. Console numbers start from 0.
 
 =back
 
-=item B<vncviewer> [I<OPTIONS>] I<domain-id>
-
-Attach to domain's VNC server, forking a vncviewer process.
-
-B<OPTIONS>
-
-=over 4
-
-=item I<--autopass>
-
-Pass VNC password to vncviewer via stdin.
-
-=back
-
 =item B<destroy> I<domain-id>
 
 Immediately terminate the domain I<domain-id>.  This doesn't give the
@@ -195,6 +186,10 @@ I<filename> specified, without pausing the domain.  The dump file will
 be written to a distribution specific directory for dump files.  Such
 as: /var/lib/xen/dump or /var/xen/dump.
 
+=item B<getenforce>
+
+Returns the current enforcing mode of the Flask Xen security module.
+
 =item B<help> [I<--long>]
 
 Displays the short help message (i.e. common commands).
@@ -298,6 +293,10 @@ less utilized than a high CPU workload.  Consider yourself warned.
 
 =back
 
+=item B<loadpolicy> I<policyfile>
+
+Loads a new policy int the Flask Xen security module.
+
 =item B<mem-max> I<domain-id> I<mem>
 
 Specify the maximum amount of memory the domain is able to use, appending 't'
@@ -386,6 +385,10 @@ Enable debug messages.
 
 =back
 
+=item B<setenforce> I<1|0|Enforcing|Permissive>
+
+Sets the current enforcing mode of the Flask Xen security module
+
 =item B<save> [I<OPTIONS>] I<domain-id> I<CheckpointFile> [I<ConfigFile>]
 
 Saves a running domain to a state file so that it can be restored
@@ -395,7 +398,6 @@ B<xl restore> restores from this checkpoint file.
 Passing a config file argument allows the user to manually select the VM config
 file used to create the domain.
 
-
 =over 4
 
 =item B<-c>
@@ -433,6 +435,11 @@ Send a I<Magic System Request> signal to the domain.  For more
 information on available magic sys req operations, see sysrq.txt in
 your Linux Kernel sources.
 
+=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>]
+
+Send a trigger to a domain, where the trigger can be: nmi, reset, init, power
+or sleep.  Optionally a specific vcpu number can be passed as an argument.
+
 =item B<unpause> I<domain-id>
 
 Moves a domain out of the paused state.  This will allow a previously
@@ -472,27 +479,19 @@ different run state is appropriate.  Pinning can be used to restrict
 this, by ensuring certain VCPUs can only run on certain physical
 CPUs.
 
-=item B<button-press> I<domain-id> I<button>
-
-Indicate an ACPI button press to the domain. I<button> is may be 'power' or
-'sleep'.
-
-=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>]
-
-Send a trigger to a domain, where the trigger can be: nmi, reset, init, power
-or sleep.  Optionally a specific vcpu number can be passed as an argument.
+=item B<vncviewer> [I<OPTIONS>] I<domain-id>
 
-=item B<getenforce>
+Attach to domain's VNC server, forking a vncviewer process.
 
-Returns the current enforcing mode of the Flask Xen security module.
+B<OPTIONS>
 
-=item B<setenforce> I<1|0|Enforcing|Permissive>
+=over 4
 
-Sets the current enforcing mode of the Flask Xen security module
+=item I<--autopass>
 
-=item B<loadpolicy> I<policyfile>
+Pass VNC password to vncviewer via stdin.
 
-Loads a new policy int the Flask Xen security module.
+=back
 
 =back
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxU-0004bV-9T; Wed, 30 Nov 2011 14:16:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxT-0004af-0a
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31231 invoked from network); 30 Nov 2011 14:15:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354090"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:48 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJD021387;
	Wed, 30 Nov 2011 06:15:42 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:32 +0000
Message-ID: <1322662596-30764-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 15/19] xl.pod.1: remove dry-run option
	from create and cpupool-create
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

there is already a global dry-run option, there is no point in adding
another one for each subcommand

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    9 ---------
 1 files changed, 0 insertions(+), 9 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 7620a2b..3b1407f 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -98,11 +98,6 @@ No console output.
 
 Use the given configuration file.
 
-=item B<-n>, B<--dryrun>
-
-Dry run - prints the resulting configuration in SXP but does not create
-the domain.
-
 =item B<-p>
 
 Leave the domain paused after it is created.
@@ -684,10 +679,6 @@ B<OPTIONS>
 
 Use the given configuration file.
 
-=item B<-n>, B<--dryrun>
-
-Dry run - prints the resulting configuration.
-
 =back
 
 =item B<cpupool-list> [I<-c|--cpus>] [I<cpu-pool>]
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxU-0004bV-9T; Wed, 30 Nov 2011 14:16:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxT-0004af-0a
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31231 invoked from network); 30 Nov 2011 14:15:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354090"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:48 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJD021387;
	Wed, 30 Nov 2011 06:15:42 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:32 +0000
Message-ID: <1322662596-30764-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 15/19] xl.pod.1: remove dry-run option
	from create and cpupool-create
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

there is already a global dry-run option, there is no point in adding
another one for each subcommand

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    9 ---------
 1 files changed, 0 insertions(+), 9 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 7620a2b..3b1407f 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -98,11 +98,6 @@ No console output.
 
 Use the given configuration file.
 
-=item B<-n>, B<--dryrun>
-
-Dry run - prints the resulting configuration in SXP but does not create
-the domain.
-
 =item B<-p>
 
 Leave the domain paused after it is created.
@@ -684,10 +679,6 @@ B<OPTIONS>
 
 Use the given configuration file.
 
-=item B<-n>, B<--dryrun>
-
-Dry run - prints the resulting configuration.
-
 =back
 
 =item B<cpupool-list> [I<-c|--cpus>] [I<cpu-pool>]
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxM-0004ZJ-Ml; Wed, 30 Nov 2011 14:16:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxL-0004Yv-CE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27214 invoked from network); 30 Nov 2011 14:15:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523792"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:40 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ0021387;
	Wed, 30 Nov 2011 06:15:28 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:19 +0000
Message-ID: <1322662596-30764-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 02/19] xl.pod.1: add a description of
	console options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 92593a6..426b8e8 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -105,7 +105,7 @@ soon as it is run.
 
 =back
 
-=item B<console> I<domain-id>
+=item B<console> [I<OPTIONS>] I<domain-id>
 
 Attach to domain I<domain-id>'s console.  If you've set up your domains to
 have a traditional log in console this will look much like a normal
@@ -113,6 +113,23 @@ text log in screen.
 
 Use the key combination Ctrl+] to detach the domain console.
 
+B<OPTIONS>
+
+=over 4
+
+=item I<-t [pv|serial]>
+
+Connect to a PV console or connect to an emulated serial console.
+PV consoles are the only consoles available for PV domains while HVM
+domains can have both. If this option is not specified it defaults to
+emulated serial for HVM guests and PV console for PV guests.
+
+=item I<-n NUM>
+
+Connect to console number I<NUM>. Console numbers start from 0.
+
+=back
+
 =item B<vncviewer> [I<OPTIONS>] I<domain-id>
 
 Attach to domain's VNC server, forking a vncviewer process.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxT-0004bA-S7; Wed, 30 Nov 2011 14:16:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxS-0004aV-Es
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31184 invoked from network); 30 Nov 2011 14:15:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354089"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:47 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJC021387;
	Wed, 30 Nov 2011 06:15:41 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:31 +0000
Message-ID: <1322662596-30764-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 14/19] xl.pod.1: improve the
	description of pci-list-assignable-devices
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index a765a11..7620a2b 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -614,6 +614,9 @@ Prints the current uptime of the domains running.
 =item B<pci-list-assignable-devices>
 
 List all the assignable PCI devices.
+These are devices in the system which are configured to be
+available for passthrough and are bound to a suitable PCI
+backend driver in domain 0 rather than a real driver.
 
 =back
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxN-0004Zc-H7; Wed, 30 Nov 2011 14:16:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxM-0004Z6-ET
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27314 invoked from network); 30 Nov 2011 14:15:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523795"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:42 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ2021387;
	Wed, 30 Nov 2011 06:15:31 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:21 +0000
Message-ID: <1322662596-30764-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 04/19] xl.pod.1: add a description of
	the global options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 8cc9779..292b3c6 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -45,6 +45,22 @@ Most B<xl> commands require root privileges to run due to the
 communications channels used to talk to the hypervisor.  Running as
 non root will return an error.
 
+=head1 GLOBAL OPTIONS
+
+Some global options are always available:
+
+=over 4
+
+=item B<-v>
+
+Verbose.
+
+=item B<-N>
+
+Dry run: do not actually execute the command.
+
+=back
+
 =head1 DOMAIN SUBCOMMANDS
 
 The following subcommands manipulate domains directly.  As stated
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxM-0004ZJ-Ml; Wed, 30 Nov 2011 14:16:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxL-0004Yv-CE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27214 invoked from network); 30 Nov 2011 14:15:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:25 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523792"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:40 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ0021387;
	Wed, 30 Nov 2011 06:15:28 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:19 +0000
Message-ID: <1322662596-30764-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 02/19] xl.pod.1: add a description of
	console options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 92593a6..426b8e8 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -105,7 +105,7 @@ soon as it is run.
 
 =back
 
-=item B<console> I<domain-id>
+=item B<console> [I<OPTIONS>] I<domain-id>
 
 Attach to domain I<domain-id>'s console.  If you've set up your domains to
 have a traditional log in console this will look much like a normal
@@ -113,6 +113,23 @@ text log in screen.
 
 Use the key combination Ctrl+] to detach the domain console.
 
+B<OPTIONS>
+
+=over 4
+
+=item I<-t [pv|serial]>
+
+Connect to a PV console or connect to an emulated serial console.
+PV consoles are the only consoles available for PV domains while HVM
+domains can have both. If this option is not specified it defaults to
+emulated serial for HVM guests and PV console for PV guests.
+
+=item I<-n NUM>
+
+Connect to console number I<NUM>. Console numbers start from 0.
+
+=back
+
 =item B<vncviewer> [I<OPTIONS>] I<domain-id>
 
 Attach to domain's VNC server, forking a vncviewer process.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxU-0004bm-N3; Wed, 30 Nov 2011 14:16:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxT-0004aA-HE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27568 invoked from network); 30 Nov 2011 14:15:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523799"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:46 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJB021387;
	Wed, 30 Nov 2011 06:15:40 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:30 +0000
Message-ID: <1322662596-30764-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 13/19] xl.pod.1: improve the
	description of the info subcommand
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

also update the example

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   55 +++++++++++++++++++++++++++-------------------------
 1 files changed, 29 insertions(+), 26 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index ab8a2f3..a765a11 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -526,39 +526,41 @@ Clears Xen's message buffer.
 
 Print information about the Xen host in I<name : value> format.  When
 reporting a Xen bug, please provide this information as part of the
-bug report.
+bug report. See I<http://wiki.xen.org/xenwiki/ReportingBugs> on how to
+report Xen bugs.
 
-Sample output looks as follows (lines wrapped manually to make the man
-page more readable):
+Sample output looks as follows:
 
- host                   : talon
- release                : 2.6.12.6-xen0
- version                : #1 Mon Nov 14 14:26:26 EST 2005
- machine                : i686
- nr_cpus                : 2
+ host                   : scarlett
+ release                : 3.1.0-rc4+
+ version                : #1001 SMP Wed Oct 19 11:09:54 UTC 2011
+ machine                : x86_64
+ nr_cpus                : 4
  nr_nodes               : 1
- cores_per_socket       : 1
+ cores_per_socket       : 4
  threads_per_core       : 1
- cpu_mhz                : 696
- hw_caps                : 0383fbff:00000000:00000000:00000040
- total_memory           : 767
- free_memory            : 37
- xen_major              : 3
- xen_minor              : 0
- xen_extra              : -devel
- xen_caps               : xen-3.0-x86_32
+ cpu_mhz                : 2266
+ hw_caps                : bfebfbff:28100800:00000000:00003b40:009ce3bd:00000000:00000001:00000000
+ virt_caps              : hvm hvm_directio
+ total_memory           : 6141
+ free_memory            : 4274
+ 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=0xfc000000
- xen_changeset          : Mon Nov 14 18:13:38 2005 +0100 
-                          7793:090e44133d40
- cc_compiler            : gcc version 3.4.3 (Mandrakelinux 
-                          10.2 3.4.3-7mdk)
- cc_compile_by          : sdague
- cc_compile_domain      : (none)
- cc_compile_date        : Mon Nov 14 14:16:48 EST 2005
+ platform_params        : virt_start=0xffff800000000000
+ xen_changeset          : Wed Nov 02 17:09:09 2011 +0000 24066:54a5e994a241
+ xen_commandline        : com1=115200,8n1 guest_loglvl=all dom0_mem=750M console=com1 
+ cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8) 
+ cc_compile_by          : sstabellini
+ cc_compile_domain      : uk.xensource.com
+ cc_compile_date        : Tue Nov  8 12:03:05 UTC 2011
  xend_config_format     : 4
 
+
 B<FIELDS>
 
 Not all fields will be explained here, but some of the less obvious
@@ -570,7 +572,8 @@ ones deserve explanation:
 
 A vector showing what hardware capabilities are supported by your
 processor.  This is equivalent to, though more cryptic, the flags
-field in /proc/cpuinfo on a normal Linux machine.
+field in /proc/cpuinfo on a normal Linux machine: they both derive from
+the feature bits returned by the cpuid command on x86 platforms.
 
 =item B<free_memory>
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxa-0004hf-KH; Wed, 30 Nov 2011 14:16:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxY-0004ar-Go
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31273 invoked from network); 30 Nov 2011 14:15:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354091"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:48 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ8021387;
	Wed, 30 Nov 2011 06:15:37 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:27 +0000
Message-ID: <1322662596-30764-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 10/19] xl.pod.1: state when a
	subcommand is only available to HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index c9b2f44..b9927a4 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -71,7 +71,7 @@ previously, most commands take I<domain-id> as the first parameter.
 =item B<button-press> I<domain-id> I<button>
 
 Indicate an ACPI button press to the domain. I<button> is may be 'power' or
-'sleep'.
+'sleep'. This command is only available for HVM domains.
 
 =item B<create> [I<configfile>] [I<OPTIONS>]
 
@@ -443,6 +443,7 @@ It requires PV drivers to be installed in your guest OS.
 
 Send a trigger to a domain, where the trigger can be: nmi, reset, init, power
 or sleep.  Optionally a specific vcpu number can be passed as an argument.
+This command is only available for HVM domains.
 
 =item B<unpause> I<domain-id>
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxX-0004dr-8I; Wed, 30 Nov 2011 14:16:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxV-0004aD-Ju
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31056 invoked from network); 30 Nov 2011 14:15:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354079"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:45 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ5021387;
	Wed, 30 Nov 2011 06:15:34 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:24 +0000
Message-ID: <1322662596-30764-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 07/19] xl.pod.1: add a reference to
	create in the -e option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Add a reference to the create subcommand in the description of
the -e option to unpause and migrate.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 14c7433..2895853 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -337,7 +337,7 @@ Use <sshcommand> instead of ssh.  String will be passed to sh. If empty, run
 =item B<-e>
 
 On the new host, do not wait in the background (on <host>) for the death of the
-domain.
+domain. See the corresponding option of the I<create> subcommand.
 
 =item B<-C> I<config>
 
@@ -377,6 +377,7 @@ Do not unpause domain after restoring it.
 =item B<-e>
 
 Do not wait in the background for the death of the domain on the new host.
+See the corresponding option of the I<create> subcommand.
 
 =item B<-d>
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxN-0004ZV-3P; Wed, 30 Nov 2011 14:16:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxL-0004Yx-SJ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27268 invoked from network); 30 Nov 2011 14:15:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523793"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:41 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:41 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ1021387;
	Wed, 30 Nov 2011 06:15:29 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:20 +0000
Message-ID: <1322662596-30764-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 03/19] xl.pod.1: improve create
	documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   21 +++++++++++++++------
 1 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 426b8e8..8cc9779 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -52,13 +52,14 @@ previously, most commands take I<domain-id> as the first parameter.
 
 =over 4
 
-=item B<create> [I<OPTIONS>] I<configfile>
+=item B<create> [I<configfile>] [I<OPTIONS>]
 
-The create subcommand requires a config file: see L<xl.cfg(5)> for
-full details of that file format and possible options.
+The create subcommand takes a config file as first argument: see
+L<xl.cfg> for full details of that file format and possible options.
+If I<configfile> is missing B<XL> creates the domain starting from the
+default value for every option.
 
-I<configfile> can either be an absolute path to a file, or a relative
-path to a file located in /etc/xen.
+I<configfile> has to be an absolute path to a file.
 
 Create will return B<as soon> as the domain is started.  This B<does
 not> mean the guest OS in the domain has actually booted, or is
@@ -88,7 +89,15 @@ Leave the domain paused after it is created.
 =item B<-c>
 
 Attach console to the domain as soon as it has started.  This is
-useful for determining issues with crashing domains.
+useful for determining issues with crashing domains and just as a
+general convenience since you often want to watch the
+domain boot.
+
+=item B<key=value>
+
+It is possible to pass I<key=value> pairs on the command line to provide
+options as if they were written in the configuration file; these override
+whatever is in the I<configfile>.
 
 =back
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxU-0004bm-N3; Wed, 30 Nov 2011 14:16:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxT-0004aA-HE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27568 invoked from network); 30 Nov 2011 14:15:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:30 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523799"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:46 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJB021387;
	Wed, 30 Nov 2011 06:15:40 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:30 +0000
Message-ID: <1322662596-30764-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 13/19] xl.pod.1: improve the
	description of the info subcommand
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

also update the example

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   55 +++++++++++++++++++++++++++-------------------------
 1 files changed, 29 insertions(+), 26 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index ab8a2f3..a765a11 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -526,39 +526,41 @@ Clears Xen's message buffer.
 
 Print information about the Xen host in I<name : value> format.  When
 reporting a Xen bug, please provide this information as part of the
-bug report.
+bug report. See I<http://wiki.xen.org/xenwiki/ReportingBugs> on how to
+report Xen bugs.
 
-Sample output looks as follows (lines wrapped manually to make the man
-page more readable):
+Sample output looks as follows:
 
- host                   : talon
- release                : 2.6.12.6-xen0
- version                : #1 Mon Nov 14 14:26:26 EST 2005
- machine                : i686
- nr_cpus                : 2
+ host                   : scarlett
+ release                : 3.1.0-rc4+
+ version                : #1001 SMP Wed Oct 19 11:09:54 UTC 2011
+ machine                : x86_64
+ nr_cpus                : 4
  nr_nodes               : 1
- cores_per_socket       : 1
+ cores_per_socket       : 4
  threads_per_core       : 1
- cpu_mhz                : 696
- hw_caps                : 0383fbff:00000000:00000000:00000040
- total_memory           : 767
- free_memory            : 37
- xen_major              : 3
- xen_minor              : 0
- xen_extra              : -devel
- xen_caps               : xen-3.0-x86_32
+ cpu_mhz                : 2266
+ hw_caps                : bfebfbff:28100800:00000000:00003b40:009ce3bd:00000000:00000001:00000000
+ virt_caps              : hvm hvm_directio
+ total_memory           : 6141
+ free_memory            : 4274
+ 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=0xfc000000
- xen_changeset          : Mon Nov 14 18:13:38 2005 +0100 
-                          7793:090e44133d40
- cc_compiler            : gcc version 3.4.3 (Mandrakelinux 
-                          10.2 3.4.3-7mdk)
- cc_compile_by          : sdague
- cc_compile_domain      : (none)
- cc_compile_date        : Mon Nov 14 14:16:48 EST 2005
+ platform_params        : virt_start=0xffff800000000000
+ xen_changeset          : Wed Nov 02 17:09:09 2011 +0000 24066:54a5e994a241
+ xen_commandline        : com1=115200,8n1 guest_loglvl=all dom0_mem=750M console=com1 
+ cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8) 
+ cc_compile_by          : sstabellini
+ cc_compile_domain      : uk.xensource.com
+ cc_compile_date        : Tue Nov  8 12:03:05 UTC 2011
  xend_config_format     : 4
 
+
 B<FIELDS>
 
 Not all fields will be explained here, but some of the less obvious
@@ -570,7 +572,8 @@ ones deserve explanation:
 
 A vector showing what hardware capabilities are supported by your
 processor.  This is equivalent to, though more cryptic, the flags
-field in /proc/cpuinfo on a normal Linux machine.
+field in /proc/cpuinfo on a normal Linux machine: they both derive from
+the feature bits returned by the cpuid command on x86 platforms.
 
 =item B<free_memory>
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxX-0004dr-8I; Wed, 30 Nov 2011 14:16:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxV-0004aD-Ju
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31056 invoked from network); 30 Nov 2011 14:15:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:03 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354079"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:45 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ5021387;
	Wed, 30 Nov 2011 06:15:34 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:24 +0000
Message-ID: <1322662596-30764-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 07/19] xl.pod.1: add a reference to
	create in the -e option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Add a reference to the create subcommand in the description of
the -e option to unpause and migrate.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 14c7433..2895853 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -337,7 +337,7 @@ Use <sshcommand> instead of ssh.  String will be passed to sh. If empty, run
 =item B<-e>
 
 On the new host, do not wait in the background (on <host>) for the death of the
-domain.
+domain. See the corresponding option of the I<create> subcommand.
 
 =item B<-C> I<config>
 
@@ -377,6 +377,7 @@ Do not unpause domain after restoring it.
 =item B<-e>
 
 Do not wait in the background for the death of the domain on the new host.
+See the corresponding option of the I<create> subcommand.
 
 =item B<-d>
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxQ-0004a1-0J; Wed, 30 Nov 2011 14:16:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxO-0004Yq-O6
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322662534!3722697!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10959 invoked from network); 30 Nov 2011 14:15:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354061"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:39 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ4021387;
	Wed, 30 Nov 2011 06:15:33 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:23 +0000
Message-ID: <1322662596-30764-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 06/19] xl.pod.1: remove the two FIXME
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index d860c00..14c7433 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -263,7 +263,8 @@ scheduling by the Xen hypervisor.
 
 =item B<s - shutdown>
 
-FIXME: Why would you ever see this state?
+The guest OS has shut down (SCHEDOP_shutdown has been called) but the
+domain is not dying yet.
 
 =item B<c - crashed>
 
@@ -276,8 +277,6 @@ restart on crash.  See L<xl.cfg(5)> for more info.
 The domain is in process of dying, but hasn't completely shutdown or
 crashed.
 
-FIXME: Is this right?
-
 =back
 
 B<NOTES>
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxQ-0004a1-0J; Wed, 30 Nov 2011 14:16:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxO-0004Yq-O6
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322662534!3722697!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10959 invoked from network); 30 Nov 2011 14:15:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354061"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:39 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ4021387;
	Wed, 30 Nov 2011 06:15:33 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:23 +0000
Message-ID: <1322662596-30764-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 06/19] xl.pod.1: remove the two FIXME
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index d860c00..14c7433 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -263,7 +263,8 @@ scheduling by the Xen hypervisor.
 
 =item B<s - shutdown>
 
-FIXME: Why would you ever see this state?
+The guest OS has shut down (SCHEDOP_shutdown has been called) but the
+domain is not dying yet.
 
 =item B<c - crashed>
 
@@ -276,8 +277,6 @@ restart on crash.  See L<xl.cfg(5)> for more info.
 The domain is in process of dying, but hasn't completely shutdown or
 crashed.
 
-FIXME: Is this right?
-
 =back
 
 B<NOTES>
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxT-0004bA-S7; Wed, 30 Nov 2011 14:16:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxS-0004aV-Es
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31184 invoked from network); 30 Nov 2011 14:15:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354089"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:47 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJC021387;
	Wed, 30 Nov 2011 06:15:41 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:31 +0000
Message-ID: <1322662596-30764-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 14/19] xl.pod.1: improve the
	description of pci-list-assignable-devices
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index a765a11..7620a2b 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -614,6 +614,9 @@ Prints the current uptime of the domains running.
 =item B<pci-list-assignable-devices>
 
 List all the assignable PCI devices.
+These are devices in the system which are configured to be
+available for passthrough and are bound to a suitable PCI
+backend driver in domain 0 rather than a real driver.
 
 =back
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxN-0004ZV-3P; Wed, 30 Nov 2011 14:16:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxL-0004Yx-SJ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27268 invoked from network); 30 Nov 2011 14:15:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523793"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:41 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:41 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ1021387;
	Wed, 30 Nov 2011 06:15:29 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:20 +0000
Message-ID: <1322662596-30764-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 03/19] xl.pod.1: improve create
	documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   21 +++++++++++++++------
 1 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 426b8e8..8cc9779 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -52,13 +52,14 @@ previously, most commands take I<domain-id> as the first parameter.
 
 =over 4
 
-=item B<create> [I<OPTIONS>] I<configfile>
+=item B<create> [I<configfile>] [I<OPTIONS>]
 
-The create subcommand requires a config file: see L<xl.cfg(5)> for
-full details of that file format and possible options.
+The create subcommand takes a config file as first argument: see
+L<xl.cfg> for full details of that file format and possible options.
+If I<configfile> is missing B<XL> creates the domain starting from the
+default value for every option.
 
-I<configfile> can either be an absolute path to a file, or a relative
-path to a file located in /etc/xen.
+I<configfile> has to be an absolute path to a file.
 
 Create will return B<as soon> as the domain is started.  This B<does
 not> mean the guest OS in the domain has actually booted, or is
@@ -88,7 +89,15 @@ Leave the domain paused after it is created.
 =item B<-c>
 
 Attach console to the domain as soon as it has started.  This is
-useful for determining issues with crashing domains.
+useful for determining issues with crashing domains and just as a
+general convenience since you often want to watch the
+domain boot.
+
+=item B<key=value>
+
+It is possible to pass I<key=value> pairs on the command line to provide
+options as if they were written in the configuration file; these override
+whatever is in the I<configfile>.
 
 =back
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxN-0004Zc-H7; Wed, 30 Nov 2011 14:16:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxM-0004Z6-ET
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27314 invoked from network); 30 Nov 2011 14:15:26 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:26 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523795"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:42 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ2021387;
	Wed, 30 Nov 2011 06:15:31 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:21 +0000
Message-ID: <1322662596-30764-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 04/19] xl.pod.1: add a description of
	the global options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 8cc9779..292b3c6 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -45,6 +45,22 @@ Most B<xl> commands require root privileges to run due to the
 communications channels used to talk to the hypervisor.  Running as
 non root will return an error.
 
+=head1 GLOBAL OPTIONS
+
+Some global options are always available:
+
+=over 4
+
+=item B<-v>
+
+Verbose.
+
+=item B<-N>
+
+Dry run: do not actually execute the command.
+
+=back
+
 =head1 DOMAIN SUBCOMMANDS
 
 The following subcommands manipulate domains directly.  As stated
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxa-0004hf-KH; Wed, 30 Nov 2011 14:16:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxY-0004ar-Go
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31273 invoked from network); 30 Nov 2011 14:15:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354091"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:48 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:48 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ8021387;
	Wed, 30 Nov 2011 06:15:37 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:27 +0000
Message-ID: <1322662596-30764-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 10/19] xl.pod.1: state when a
	subcommand is only available to HVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index c9b2f44..b9927a4 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -71,7 +71,7 @@ previously, most commands take I<domain-id> as the first parameter.
 =item B<button-press> I<domain-id> I<button>
 
 Indicate an ACPI button press to the domain. I<button> is may be 'power' or
-'sleep'.
+'sleep'. This command is only available for HVM domains.
 
 =item B<create> [I<configfile>] [I<OPTIONS>]
 
@@ -443,6 +443,7 @@ It requires PV drivers to be installed in your guest OS.
 
 Send a trigger to a domain, where the trigger can be: nmi, reset, init, power
 or sleep.  Optionally a specific vcpu number can be passed as an argument.
+This command is only available for HVM domains.
 
 =item B<unpause> I<domain-id>
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxb-0004jV-Qn; Wed, 30 Nov 2011 14:16:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxZ-0004bc-Tv
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322662550!5313373!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6529 invoked from network); 30 Nov 2011 14:15:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354094"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:49 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJE021387;
	Wed, 30 Nov 2011 06:15:43 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:33 +0000
Message-ID: <1322662596-30764-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 16/19] xl.pod.1: improve description
	of virtual device subcommands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Add a reference to xl-disk-configuration and xl-network-configuration.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   21 +++++++++++++++------
 1 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 3b1407f..8348cd4 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -716,8 +716,8 @@ Splits up the machine into one cpu-pool per numa node.
 =head1 VIRTUAL DEVICE COMMANDS
 
 Most virtual devices can be added and removed while guests are
-running.  The effect to the guest OS is much the same as any hotplug
-event.
+running, assuming that the necessary support exists in the guest.  The
+effect to the guest OS is much the same as any hotplug event.
 
 =head2 BLOCK DEVICES
 
@@ -739,7 +739,8 @@ The domain id of the guest domain that the device will be attached to.
 =item I<disc-spec-component>
 
 A disc specification in the same format used for the B<disk> variable in
-the domain config file. See F<xl-disk-configuration>.
+the domain config file. See
+L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>.
 
 =back
 
@@ -794,8 +795,9 @@ I<VirtualDevice> is the cdrom device in the guest to eject.
 
 Creates a new network device in the domain specified by I<domain-id>.
 I<network-device> describes the device to attach, using the same format as the
-B<vif> string in the domain config file. See L<xl.cfg(5)> for the
-description.
+B<vif> string in the domain config file. See L<xl.cfg> and
+L<http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html>
+for more informations.
 
 =item B<network-detach> I<domain-id> I<devid|mac>
 
@@ -917,7 +919,14 @@ Xen Flask security module.
 
 =head1 SEE ALSO
 
-L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
+The following man pages:
+
+L<xl.cfg>(5), L<xlcpupool.cfg>(5), B<xentop>(1)
+
+And the following documents on the xen.org website:
+
+L<http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html>
+L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
 
 =head1 AUTHOR
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxW-0004dP-Qa; Wed, 30 Nov 2011 14:16:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxU-0004bY-PF
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31384 invoked from network); 30 Nov 2011 14:15:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:08 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354095"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:50 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJF021387;
	Wed, 30 Nov 2011 06:15:44 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:34 +0000
Message-ID: <1322662596-30764-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 17/19] xl.pod.1: remove AUTHORS section
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 8348cd4..54e0f51 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -928,13 +928,6 @@ And the following documents on the xen.org website:
 L<http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html>
 L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
 
-=head1 AUTHOR
-
-  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
-  Vincent Hanquez <vincent.hanquez@eu.citrix.com>
-  Ian Jackson <ian.jackson@eu.citrix.com>
-  Ian Campbell <Ian.Campbell@citrix.com>
-
 =head1 BUGS
 
 Send bugs to xen-devel@lists.xensource.com.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxb-0004jV-Qn; Wed, 30 Nov 2011 14:16:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxZ-0004bc-Tv
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322662550!5313373!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6529 invoked from network); 30 Nov 2011 14:15:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:51 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354094"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:49 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJE021387;
	Wed, 30 Nov 2011 06:15:43 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:33 +0000
Message-ID: <1322662596-30764-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 16/19] xl.pod.1: improve description
	of virtual device subcommands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Add a reference to xl-disk-configuration and xl-network-configuration.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   21 +++++++++++++++------
 1 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 3b1407f..8348cd4 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -716,8 +716,8 @@ Splits up the machine into one cpu-pool per numa node.
 =head1 VIRTUAL DEVICE COMMANDS
 
 Most virtual devices can be added and removed while guests are
-running.  The effect to the guest OS is much the same as any hotplug
-event.
+running, assuming that the necessary support exists in the guest.  The
+effect to the guest OS is much the same as any hotplug event.
 
 =head2 BLOCK DEVICES
 
@@ -739,7 +739,8 @@ The domain id of the guest domain that the device will be attached to.
 =item I<disc-spec-component>
 
 A disc specification in the same format used for the B<disk> variable in
-the domain config file. See F<xl-disk-configuration>.
+the domain config file. See
+L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>.
 
 =back
 
@@ -794,8 +795,9 @@ I<VirtualDevice> is the cdrom device in the guest to eject.
 
 Creates a new network device in the domain specified by I<domain-id>.
 I<network-device> describes the device to attach, using the same format as the
-B<vif> string in the domain config file. See L<xl.cfg(5)> for the
-description.
+B<vif> string in the domain config file. See L<xl.cfg> and
+L<http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html>
+for more informations.
 
 =item B<network-detach> I<domain-id> I<devid|mac>
 
@@ -917,7 +919,14 @@ Xen Flask security module.
 
 =head1 SEE ALSO
 
-L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
+The following man pages:
+
+L<xl.cfg>(5), L<xlcpupool.cfg>(5), B<xentop>(1)
+
+And the following documents on the xen.org website:
+
+L<http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html>
+L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
 
 =head1 AUTHOR
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxM-0004ZB-9f; Wed, 30 Nov 2011 14:16:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxL-0004YY-7Q
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322662534!3722697!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10756 invoked from network); 30 Nov 2011 14:15:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354051"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:33 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRIx021387;
	Wed, 30 Nov 2011 06:15:27 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:18 +0000
Message-ID: <1322662596-30764-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 01/19] xl.pod.1: add a barebone
	description of tmem commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   66 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index bd83192..92593a6 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -793,6 +793,72 @@ List pass-through pci devices for a domain.
 
 =back
 
+=head2 TMEM
+
+=over 4
+
+=item B<tmem-list> I[<-l>] I<domain-id>
+
+List tmem pools. If I<-l> is specified, also list tmem stats.
+
+=item B<tmem-freeze> I<domain-id>
+
+Freeze tmem pools.
+
+=item B<tmem-destroy> I<domain-id>
+
+Destroy tmem pools.
+
+=item B<tmem-thaw> I<domain-id>
+
+Thaw tmem pools.
+
+=item B<tmem-set> I<domain-id> [I<OPTIONS>]
+
+Change tmem settings.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-w> I<WEIGHT>
+
+Weight (int)
+
+=item B<-c> I<CAP>
+
+Cap (int)
+
+=item B<-p> I<COMPRESS>
+
+Compress (int)
+
+=back
+
+=item B<tmem-shared-auth> I<domain-id> [I<OPTIONS>]
+
+De/authenticate shared tmem pool.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-u> I<UUID>
+
+Specify uuid (abcdef01-2345-6789-1234-567890abcdef)
+
+=item B<-a> I<AUTH>
+
+0=auth,1=deauth
+
+=back
+
+=item B<tmem-freeable>
+
+Get information about how much freeable memory (MB) is in-use by tmem.
+
+=back
+
 =head1 SEE ALSO
 
 L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxY-0004es-4Q; Wed, 30 Nov 2011 14:16:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxW-0004aR-Po
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31134 invoked from network); 30 Nov 2011 14:15:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354088"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:47 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ7021387;
	Wed, 30 Nov 2011 06:15:36 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:26 +0000
Message-ID: <1322662596-30764-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 09/19] xl.pod.1: better description
	for the sysreq subcommand
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index df0610b..c9b2f44 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -433,9 +433,11 @@ Wait for the domain to complete shutdown before returning.
 
 =item B<sysrq> I<domain-id> I<letter>
 
-Send a I<Magic System Request> signal to the domain.  For more
-information on available magic sys req operations, see sysrq.txt in
-your Linux Kernel sources.
+Send a <Magic System Request> to the domain, each type of request is
+represented by a different letter.
+It can be used to send SysRq requests to Linux guests, see sysrq.txt in
+your Linux Kernel sources for more information.
+It requires PV drivers to be installed in your guest OS.
 
 =item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>]
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxW-0004dP-Qa; Wed, 30 Nov 2011 14:16:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxU-0004bY-PF
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31384 invoked from network); 30 Nov 2011 14:15:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:08 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354095"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:50 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:50 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJF021387;
	Wed, 30 Nov 2011 06:15:44 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:34 +0000
Message-ID: <1322662596-30764-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 17/19] xl.pod.1: remove AUTHORS section
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 8348cd4..54e0f51 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -928,13 +928,6 @@ And the following documents on the xen.org website:
 L<http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html>
 L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
 
-=head1 AUTHOR
-
-  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
-  Vincent Hanquez <vincent.hanquez@eu.citrix.com>
-  Ian Jackson <ian.jackson@eu.citrix.com>
-  Ian Campbell <Ian.Campbell@citrix.com>
-
 =head1 BUGS
 
 Send bugs to xen-devel@lists.xensource.com.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxV-0004cN-Bt; Wed, 30 Nov 2011 14:16:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxU-0004aO-6X
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27603 invoked from network); 30 Nov 2011 14:15:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523800"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:46 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ6021387;
	Wed, 30 Nov 2011 06:15:35 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:25 +0000
Message-ID: <1322662596-30764-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 08/19] xl.pod.1: state when a command
	requires PV drivers installed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Remove an old incorrect comment about vcpu-set requiring cooperation
from the guest.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 2895853..df0610b 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -357,6 +357,7 @@ Reboot a domain.  This acts just as if the domain had the B<reboot>
 command run from the console.  The command returns as soon as it has
 executed the reboot action, which may be significantly before the
 domain actually reboots.
+It requires PV drivers installed in your guest OS.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_reboot> parameter of the domain configuration file when the
@@ -414,6 +415,7 @@ to perform graceful shutdown, so there is no guarantee that it will
 succeed, and may take a variable length of time depending on what
 services must be shutdown in the domain.  The command returns
 immediately after signally the domain unless that B<-w> flag is used.
+For HVM domains it requires PV drivers to be installed in your guest OS.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_shutdown> parameter of the domain configuration file when the
@@ -459,10 +461,6 @@ Attempting to set the VCPUs to a number larger than the initially
 configured VCPU count is an error.  Trying to set VCPUs to < 1 will be
 quietly ignored.
 
-Because this operation requires cooperation from the domain operating
-system, there is no guarantee that it will succeed.  This command will
-not work with a full virt domain.
-
 =item B<vcpu-list> [I<domain-id>]
 
 Lists VCPU information for a specific domain.  If no domain is
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxM-0004ZB-9f; Wed, 30 Nov 2011 14:16:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxL-0004YY-7Q
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322662534!3722697!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10756 invoked from network); 30 Nov 2011 14:15:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:36 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354051"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:33 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRIx021387;
	Wed, 30 Nov 2011 06:15:27 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:18 +0000
Message-ID: <1322662596-30764-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 01/19] xl.pod.1: add a barebone
	description of tmem commands
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   66 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index bd83192..92593a6 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -793,6 +793,72 @@ List pass-through pci devices for a domain.
 
 =back
 
+=head2 TMEM
+
+=over 4
+
+=item B<tmem-list> I[<-l>] I<domain-id>
+
+List tmem pools. If I<-l> is specified, also list tmem stats.
+
+=item B<tmem-freeze> I<domain-id>
+
+Freeze tmem pools.
+
+=item B<tmem-destroy> I<domain-id>
+
+Destroy tmem pools.
+
+=item B<tmem-thaw> I<domain-id>
+
+Thaw tmem pools.
+
+=item B<tmem-set> I<domain-id> [I<OPTIONS>]
+
+Change tmem settings.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-w> I<WEIGHT>
+
+Weight (int)
+
+=item B<-c> I<CAP>
+
+Cap (int)
+
+=item B<-p> I<COMPRESS>
+
+Compress (int)
+
+=back
+
+=item B<tmem-shared-auth> I<domain-id> [I<OPTIONS>]
+
+De/authenticate shared tmem pool.
+
+B<OPTIONS>
+
+=over 4
+
+=item B<-u> I<UUID>
+
+Specify uuid (abcdef01-2345-6789-1234-567890abcdef)
+
+=item B<-a> I<AUTH>
+
+0=auth,1=deauth
+
+=back
+
+=item B<tmem-freeable>
+
+Get information about how much freeable memory (MB) is in-use by tmem.
+
+=back
+
 =head1 SEE ALSO
 
 L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxY-0004es-4Q; Wed, 30 Nov 2011 14:16:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxW-0004aR-Po
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31134 invoked from network); 30 Nov 2011 14:15:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354088"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:47 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:47 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ7021387;
	Wed, 30 Nov 2011 06:15:36 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:26 +0000
Message-ID: <1322662596-30764-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 09/19] xl.pod.1: better description
	for the sysreq subcommand
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index df0610b..c9b2f44 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -433,9 +433,11 @@ Wait for the domain to complete shutdown before returning.
 
 =item B<sysrq> I<domain-id> I<letter>
 
-Send a I<Magic System Request> signal to the domain.  For more
-information on available magic sys req operations, see sysrq.txt in
-your Linux Kernel sources.
+Send a <Magic System Request> to the domain, each type of request is
+represented by a different letter.
+It can be used to send SysRq requests to Linux guests, see sysrq.txt in
+your Linux Kernel sources for more information.
+It requires PV drivers to be installed in your guest OS.
 
 =item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>]
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxb-0004iQ-4z; Wed, 30 Nov 2011 14:16:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxZ-0004b1-2k
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31330 invoked from network); 30 Nov 2011 14:15:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354093"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:49 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ9021387;
	Wed, 30 Nov 2011 06:15:38 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:28 +0000
Message-ID: <1322662596-30764-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 11/19] xl.pod.1: introduce a TO BE
	DOCUMENTED section
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index b9927a4..2344f4d 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -901,6 +901,22 @@ Get information about how much freeable memory (MB) is in-use by tmem.
 
 =back
 
+=head1 TO BE DOCUMENTED
+
+We need better documentation for:
+
+=over 4
+
+=item B<tmem>
+
+Trascendent Memory.
+
+=item B<Flask>
+
+Xen Flask security module.
+
+=back
+
 =head1 SEE ALSO
 
 L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxV-0004cN-Bt; Wed, 30 Nov 2011 14:16:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxU-0004aO-6X
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1322662524!47706457!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMDMzMzE=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27603 invoked from network); 30 Nov 2011 14:15:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:31 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="19523800"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:46 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ6021387;
	Wed, 30 Nov 2011 06:15:35 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:25 +0000
Message-ID: <1322662596-30764-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 08/19] xl.pod.1: state when a command
	requires PV drivers installed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Remove an old incorrect comment about vcpu-set requiring cooperation
from the guest.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 2895853..df0610b 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -357,6 +357,7 @@ Reboot a domain.  This acts just as if the domain had the B<reboot>
 command run from the console.  The command returns as soon as it has
 executed the reboot action, which may be significantly before the
 domain actually reboots.
+It requires PV drivers installed in your guest OS.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_reboot> parameter of the domain configuration file when the
@@ -414,6 +415,7 @@ to perform graceful shutdown, so there is no guarantee that it will
 succeed, and may take a variable length of time depending on what
 services must be shutdown in the domain.  The command returns
 immediately after signally the domain unless that B<-w> flag is used.
+For HVM domains it requires PV drivers to be installed in your guest OS.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_shutdown> parameter of the domain configuration file when the
@@ -459,10 +461,6 @@ Attempting to set the VCPUs to a number larger than the initially
 configured VCPU count is an error.  Trying to set VCPUs to < 1 will be
 quietly ignored.
 
-Because this operation requires cooperation from the domain operating
-system, there is no guarantee that it will succeed.  This command will
-not work with a full virt domain.
-
 =item B<vcpu-list> [I<domain-id>]
 
 Lists VCPU information for a specific domain.  If no domain is
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxb-0004iQ-4z; Wed, 30 Nov 2011 14:16:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxZ-0004b1-2k
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31330 invoked from network); 30 Nov 2011 14:15:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:07 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354093"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:49 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:49 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJ9021387;
	Wed, 30 Nov 2011 06:15:38 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:28 +0000
Message-ID: <1322662596-30764-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 11/19] xl.pod.1: introduce a TO BE
	DOCUMENTED section
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index b9927a4..2344f4d 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -901,6 +901,22 @@ Get information about how much freeable memory (MB) is in-use by tmem.
 
 =back
 
+=head1 TO BE DOCUMENTED
+
+We need better documentation for:
+
+=over 4
+
+=item B<tmem>
+
+Trascendent Memory.
+
+=item B<Flask>
+
+Xen Flask security module.
+
+=back
+
 =head1 SEE ALSO
 
 L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxX-0004e9-MF; Wed, 30 Nov 2011 14:16:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxW-0004aP-5f
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31090 invoked from network); 30 Nov 2011 14:15:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354080"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:45 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJA021387;
	Wed, 30 Nov 2011 06:15:39 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:29 +0000
Message-ID: <1322662596-30764-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 12/19] xl.pod.1: improve the
	debug-keys subcommand description
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 2344f4d..ab8a2f3 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -502,7 +502,8 @@ Pass VNC password to vncviewer via stdin.
 
 =item B<debug-keys> I<keys>
 
-Send debug I<keys> to Xen.
+Send debug I<keys> to Xen. It is the same as pressing the Xen
+"conswitch" (Ctrl-A by default) three times and then pressing "keys".
 
 =item B<dmesg> [B<-c>]
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:36 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxX-0004e9-MF; Wed, 30 Nov 2011 14:16:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxW-0004aP-5f
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322662502!55477485!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31090 invoked from network); 30 Nov 2011 14:15:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354080"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:45 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJA021387;
	Wed, 30 Nov 2011 06:15:39 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:29 +0000
Message-ID: <1322662596-30764-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 12/19] xl.pod.1: improve the
	debug-keys subcommand description
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 2344f4d..ab8a2f3 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -502,7 +502,8 @@ Pass VNC password to vncviewer via stdin.
 
 =item B<debug-keys> I<keys>
 
-Send debug I<keys> to Xen.
+Send debug I<keys> to Xen. It is the same as pressing the Xen
+"conswitch" (Ctrl-A by default) three times and then pressing "keys".
 
 =item B<dmesg> [B<-c>]
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxi-0004u5-NH; Wed, 30 Nov 2011 14:16:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxg-0004i8-CB
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322662553!3724383!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15282 invoked from network); 30 Nov 2011 14:15:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354112"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:56 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJG021387;
	Wed, 30 Nov 2011 06:15:45 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:35 +0000
Message-ID: <1322662596-30764-18-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 18/19] xl.pod.1: add a refence to
	http://wiki.xen.org/xenwiki/ReportingBugs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 54e0f51..e8a5d21 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -930,4 +930,5 @@ L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
 
 =head1 BUGS
 
-Send bugs to xen-devel@lists.xensource.com.
+Send bugs to xen-devel@lists.xensource.com, see
+http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxi-0004u5-NH; Wed, 30 Nov 2011 14:16:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxg-0004i8-CB
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322662553!3724383!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15282 invoked from network); 30 Nov 2011 14:15:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354112"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:56 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJG021387;
	Wed, 30 Nov 2011 06:15:45 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:35 +0000
Message-ID: <1322662596-30764-18-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 18/19] xl.pod.1: add a refence to
	http://wiki.xen.org/xenwiki/ReportingBugs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 54e0f51..e8a5d21 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -930,4 +930,5 @@ L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
 
 =head1 BUGS
 
-Send bugs to xen-devel@lists.xensource.com.
+Send bugs to xen-devel@lists.xensource.com, see
+http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxh-0004sZ-M4; Wed, 30 Nov 2011 14:16:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxe-0004fM-2m
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322662553!3724383!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15115 invoked from network); 30 Nov 2011 14:15:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354101"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:52 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJH021387;
	Wed, 30 Nov 2011 06:15:46 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:36 +0000
Message-ID: <1322662596-30764-19-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 19/19] xl.pod.1: add a note about
	autoballoon and dom0_mem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index e8a5d21..eb85ca0 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -32,19 +32,35 @@ each of those subcommands.
 
 =head1 NOTES
 
+=over 4
+
+=item start the script B</etc/init.d/xencommons> at boot time
+
 Most B<xl> operations rely upon B<xenstored> and B<xenconsoled>: make
 sure you start the script B</etc/init.d/xencommons> at boot time to
 initialize all the daemons needed by B<xl>.
 
+=item setup a B<xenbr0> bridge in dom0
+
 In the most common network configuration, you need to setup a bridge in dom0
 named B<xenbr0> in order to have a working network in the guest domains.
 Please refer to the documentation of your Linux distribution to know how to
 setup the bridge.
 
+=item B<autoballoon>
+
+If you specify the amount of memory dom0 has, passing B<dom0_mem> to
+Xen, it is highly reccomended to disable B<autoballoon>. Edit
+B</etc/xen/xl.conf> and set it to 0.
+
+=item run xl as B<root>
+
 Most B<xl> commands require root privileges to run due to the
 communications channels used to talk to the hypervisor.  Running as
 non root will return an error.
 
+=back
+
 =head1 GLOBAL OPTIONS
 
 Some global options are always available:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:16:46 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:16:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVkxh-0004sZ-M4; Wed, 30 Nov 2011 14:16:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVkxe-0004fM-2m
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:16:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322662553!3724383!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15115 invoked from network); 30 Nov 2011 14:15:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:15:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354101"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:15:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:15:52 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id pAUEFRJH021387;
	Wed, 30 Nov 2011 06:15:46 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 14:16:36 +0000
Message-ID: <1322662596-30764-19-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH XenDocDay 19/19] xl.pod.1: add a note about
	autoballoon and dom0_mem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 docs/man/xl.pod.1 |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index e8a5d21..eb85ca0 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -32,19 +32,35 @@ each of those subcommands.
 
 =head1 NOTES
 
+=over 4
+
+=item start the script B</etc/init.d/xencommons> at boot time
+
 Most B<xl> operations rely upon B<xenstored> and B<xenconsoled>: make
 sure you start the script B</etc/init.d/xencommons> at boot time to
 initialize all the daemons needed by B<xl>.
 
+=item setup a B<xenbr0> bridge in dom0
+
 In the most common network configuration, you need to setup a bridge in dom0
 named B<xenbr0> in order to have a working network in the guest domains.
 Please refer to the documentation of your Linux distribution to know how to
 setup the bridge.
 
+=item B<autoballoon>
+
+If you specify the amount of memory dom0 has, passing B<dom0_mem> to
+Xen, it is highly reccomended to disable B<autoballoon>. Edit
+B</etc/xen/xl.conf> and set it to 0.
+
+=item run xl as B<root>
+
 Most B<xl> commands require root privileges to run due to the
 communications channels used to talk to the hypervisor.  Running as
 non root will return an error.
 
+=back
+
 =head1 GLOBAL OPTIONS
 
 Some global options are always available:
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:20:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:20:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVl1Y-0007G6-B7; Wed, 30 Nov 2011 14:20:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVl1V-0007D1-JQ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:20:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322662795!5624080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2859 invoked from network); 30 Nov 2011 14:19:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:19:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9208781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:19:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:19:55 +0000
Date: Wed, 30 Nov 2011 14:20:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111301420000.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 30 Nov 2011, Catalin Marinas wrote:
> On 30 November 2011 11:39, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > A git branch is available here (not ready for submission):
> >
> > git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
> >
> > the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
> > even though guests don't really need lpae support to run on Xen.
> 
> Indeed, you don't really need LPAE. What you may need though is
> generic timers support for A15, it would allow less Hypervisor traps.
> For up-to-date architecture patches (well, development tree, not
> guaranteed to be stable), I would recommend this (they get into
> mainline at some point):
> 
> http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary
> 
> Either use master or just cherry-pick the branches that you are interested in.

Thanks, I'll rebase on that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:20:39 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:20:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVl1Y-0007G6-B7; Wed, 30 Nov 2011 14:20:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVl1V-0007D1-JQ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:20:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322662795!5624080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2859 invoked from network); 30 Nov 2011 14:19:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:19:55 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9208781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:19:55 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:19:55 +0000
Date: Wed, 30 Nov 2011 14:20:51 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Catalin Marinas <catalin.marinas@arm.com>
In-Reply-To: <CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1111301420000.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111292129.20444.arnd@arndb.de>
	<alpine.DEB.2.00.1111301053300.31179@kaball-desktop>
	<CAHkRjk48jHO19H04rf8252+v04hk9qSdKBrfYCqJsZyamVhMEw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Arnd Bergmann <arnd@arndb.de>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 30 Nov 2011, Catalin Marinas wrote:
> On 30 November 2011 11:39, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > A git branch is available here (not ready for submission):
> >
> > git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git arm
> >
> > the branch above is based on git://linux-arm.org/linux-2.6.git arm-lpae,
> > even though guests don't really need lpae support to run on Xen.
> 
> Indeed, you don't really need LPAE. What you may need though is
> generic timers support for A15, it would allow less Hypervisor traps.
> For up-to-date architecture patches (well, development tree, not
> guaranteed to be stable), I would recommend this (they get into
> mainline at some point):
> 
> http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-arm-arch.git;a=summary
> 
> Either use master or just cherry-pick the branches that you are interested in.

Thanks, I'll rebase on that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:21:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:21:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVl1p-0007Ly-Pw; Wed, 30 Nov 2011 14:20:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RVl1p-0007KU-3p
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:20:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322662779!48962028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7429 invoked from network); 30 Nov 2011 14:19:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:19:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354678"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:19:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:19:09 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAUEJ807021432;	Wed, 30 Nov 2011 06:19:08 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 30 Nov 2011 14:19:04 +0000
Message-ID: <1322662744-27030-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V2] xl: Apply CLOEXEC to the restore_fd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At restore time, the file descriptor opened on the migration state file is
still open in the device model. Let's apply FD_CLOEXEC to it.

This patch provides libxl_fd_set_cloexec to users of libxl, instead of keeping
this function internal.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
Change:
  - this time, apply cloexec only to the opened migration state file and not
    the the fd provide by the caller.


 tools/libxl/libxl.c          |   13 +++++++++++++
 tools/libxl/libxl.h          |    3 +++
 tools/libxl/libxl_internal.c |   13 -------------
 tools/libxl/libxl_internal.h |    1 -
 tools/libxl/libxl_qmp.c      |    2 +-
 tools/libxl/xl_cmdimpl.c     |    8 ++++++--
 6 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a171142..de35adf 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3330,6 +3330,19 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     return 0;
 }
 
+int libxl_fd_set_cloexec(int fd)
+{
+    int flags = 0;
+
+    if ((flags = fcntl(fd, F_GETFD)) == -1) {
+        flags = 0;
+    }
+    if ((flags & FD_CLOEXEC)) {
+        return 0;
+    }
+    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 289dc85..8e42822 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -635,6 +635,9 @@ const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
+/* misc */
+int libxl_fd_set_cloexec(int fd);
+
 #endif /* LIBXL_H */
 
 /*
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..028f90f 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -306,19 +306,6 @@ _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b)
     return 0;
 }
 
-int libxl__fd_set_cloexec(int fd)
-{
-    int flags = 0;
-
-    if ((flags = fcntl(fd, F_GETFD)) == -1) {
-        flags = 0;
-    }
-    if ((flags & FD_CLOEXEC)) {
-        return 0;
-    }
-    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
-}
-
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..6ce34fd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -503,7 +503,6 @@ _hidden int libxl__error_set(libxl__gc *gc, int code);
 
 _hidden int libxl__file_reference_map(libxl_file_reference *f);
 _hidden int libxl__file_reference_unmap(libxl_file_reference *f);
-_hidden int libxl__fd_set_cloexec(int fd);
 
 _hidden int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..66a0134 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -324,7 +324,7 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
     if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
         return -1;
     }
-    libxl__fd_set_cloexec(qmp->qmp_fd);
+    libxl_fd_set_cloexec(qmp->qmp_fd);
 
     memset(&qmp->addr, 0, sizeof (&qmp->addr));
     qmp->addr.sun_family = AF_UNIX;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f1e729c..97141d1 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1459,8 +1459,12 @@ static int create_domain(struct domain_create *dom_info)
         union { uint32_t u32; char b[4]; } u32buf;
         uint32_t badflags;
 
-        restore_fd = migrate_fd >= 0 ? migrate_fd :
-            open(restore_file, O_RDONLY);
+        if (migrate_fd >= 0) {
+            restore_fd = migrate_fd;
+        } else {
+            restore_fd = open(restore_file, O_RDONLY);
+            libxl_fd_set_cloexec(restore_fd);
+        }
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
                    sizeof(hdr), restore_file, "header") );
-- 
tg: (4ed28e3..) fix/close-migration-state (depends on: master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:21:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:21:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVl1p-0007Ly-Pw; Wed, 30 Nov 2011 14:20:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1RVl1p-0007KU-3p
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:20:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1322662779!48962028!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7429 invoked from network); 30 Nov 2011 14:19:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:19:40 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172354678"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 09:19:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 09:19:09 -0500
Received: from perard.uk.xensource.com (dhcp-3-28.uk.xensource.com
	[10.80.3.28] (may be forged))	by smtp01.ad.xensource.com
	(8.13.1/8.13.1) with
	ESMTP id pAUEJ807021432;	Wed, 30 Nov 2011 06:19:08 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Wed, 30 Nov 2011 14:19:04 +0000
Message-ID: <1322662744-27030-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH V2] xl: Apply CLOEXEC to the restore_fd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At restore time, the file descriptor opened on the migration state file is
still open in the device model. Let's apply FD_CLOEXEC to it.

This patch provides libxl_fd_set_cloexec to users of libxl, instead of keeping
this function internal.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
Change:
  - this time, apply cloexec only to the opened migration state file and not
    the the fd provide by the caller.


 tools/libxl/libxl.c          |   13 +++++++++++++
 tools/libxl/libxl.h          |    3 +++
 tools/libxl/libxl_internal.c |   13 -------------
 tools/libxl/libxl_internal.h |    1 -
 tools/libxl/libxl_qmp.c      |    2 +-
 tools/libxl/xl_cmdimpl.c     |    8 ++++++--
 6 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a171142..de35adf 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3330,6 +3330,19 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     return 0;
 }
 
+int libxl_fd_set_cloexec(int fd)
+{
+    int flags = 0;
+
+    if ((flags = fcntl(fd, F_GETFD)) == -1) {
+        flags = 0;
+    }
+    if ((flags & FD_CLOEXEC)) {
+        return 0;
+    }
+    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 289dc85..8e42822 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -635,6 +635,9 @@ const char *libxl_lock_dir_path(void);
 const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
+/* misc */
+int libxl_fd_set_cloexec(int fd);
+
 #endif /* LIBXL_H */
 
 /*
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 34edaf3..028f90f 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -306,19 +306,6 @@ _hidden int libxl__compare_macs(libxl_mac *a, libxl_mac *b)
     return 0;
 }
 
-int libxl__fd_set_cloexec(int fd)
-{
-    int flags = 0;
-
-    if ((flags = fcntl(fd, F_GETFD)) == -1) {
-        flags = 0;
-    }
-    if ((flags & FD_CLOEXEC)) {
-        return 0;
-    }
-    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
-}
-
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 84da6b1..6ce34fd 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -503,7 +503,6 @@ _hidden int libxl__error_set(libxl__gc *gc, int code);
 
 _hidden int libxl__file_reference_map(libxl_file_reference *f);
 _hidden int libxl__file_reference_unmap(libxl_file_reference *f);
-_hidden int libxl__fd_set_cloexec(int fd);
 
 _hidden int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config);
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f749e01..66a0134 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -324,7 +324,7 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
     if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
         return -1;
     }
-    libxl__fd_set_cloexec(qmp->qmp_fd);
+    libxl_fd_set_cloexec(qmp->qmp_fd);
 
     memset(&qmp->addr, 0, sizeof (&qmp->addr));
     qmp->addr.sun_family = AF_UNIX;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f1e729c..97141d1 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1459,8 +1459,12 @@ static int create_domain(struct domain_create *dom_info)
         union { uint32_t u32; char b[4]; } u32buf;
         uint32_t badflags;
 
-        restore_fd = migrate_fd >= 0 ? migrate_fd :
-            open(restore_file, O_RDONLY);
+        if (migrate_fd >= 0) {
+            restore_fd = migrate_fd;
+        } else {
+            restore_fd = open(restore_file, O_RDONLY);
+            libxl_fd_set_cloexec(restore_fd);
+        }
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
                    sizeof(hdr), restore_file, "header") );
-- 
tg: (4ed28e3..) fix/close-migration-state (depends on: master)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:34:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlEV-00084V-BV; Wed, 30 Nov 2011 14:33:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RVlET-00083w-SX
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:33:58 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322663598!3678676!1
X-Originating-IP: [212.227.17.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjkgPT4gODA5MTE=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjkgPT4gODA5MTE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18780 invoked from network); 30 Nov 2011 14:33:18 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.9) by server-2.tower-174.messagelabs.com with SMTP;
	30 Nov 2011 14:33:18 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis)
	id 0M2WiT-1QeLFc172r-00szEA; Wed, 30 Nov 2011 15:32:57 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 30 Nov 2011 14:32:54 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301303.23851.arnd@arndb.de>
	<1322659535.31810.97.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322659535.31810.97.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201111301432.54463.arnd@arndb.de>
X-Provags-ID: V02:K0:KiyS5/mKTB55iLS0W4BKJPYzZdPPz/YC+/JscRaM0ef
	CoS+X6fI7K9zEu+Ng77TIUmFPDrSEj8tg+PCYjfBVHsnNzsL36
	uqi+9cytQ1YPvwD2FEvrWzs+YuGEDazmaZJq5A0LHneEjHcvVn
	MiJd1gaw7tWiawwcHcHJK5ojBYrdc4ynccSqe2p4G8d71ZyjY2
	ul06DIizQiKrqnRX2lxQIcJyGIIOjPgnkVYTZ7UKXYdP7Yo7we
	Mj+Zd4elP7Gbm4CEofPcPG8RMwBkUjQMyeeDHdnqTkm8ip/Pjl
	jvBNURr29ZrDxrjX2vH+Ngo4D3wo3RzFHo++rAv8rIDj6+tsW6
	2kdRZHslojueUVJpqRy0=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wednesday 30 November 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 13:03 +0000, Arnd Bergmann wrote:
> > On Wednesday 30 November 2011, Stefano Stabellini wrote:
> > This is the same choice people have made for KVM, but it's not
> > necessarily the best option in the long run. In particular, this
> > board has a lot of hardware that you claim to have by putting the
> > machine number there, when you don't really want to emulate it.
> 
> This code is actually setting up dom0 which (for the most part) sees the
> real hardware.

Ok, I see.

> > Pawell Moll is working on a variant of the vexpress code that uses
> > the flattened device tree to describe the present hardware [1], and
> > I think that would be a much better target for an official release.
> > Ideally, the hypervisor should provide the device tree binary (dtb)
> > to the guest OS describing the hardware that is actually there.
> 
> Agreed. Our intention was to use DT so this fits perfectly with our
> plans.
> 
> For dom0 we would expose a (possibly filtered) version of the DT given
> to us by the firmware (e.g. we might hide a serial port to reserve it
> for Xen's use, we'd likely fiddle with the memory map etc).

Ah, very good.

> For domU the DT would presumably be constructed by the toolstack (in
> dom0 userspace) as appropriate for the guest configuration. I guess this
> needn't correspond to any particular "real" hardware platform.

Correct, but it needs to correspond to some platform that is supported
by the guest OS, which leaves the choice between emulating a real
hardware platform, adding a completely new platform specifically for
virtual machines, or something in between the two.

What I suggested to the KVM developers is to start out with the
vexpress platform, but then generalize it to the point where it fits
your needs. All hardware that one expects a guest to have (GIC, timer,
...) will still show up in the same location as on a real vexpress,
while anything that makes no sense or is better paravirtualized (LCD,
storage, ...) just becomes optional and has to be described in the
device tree if it's actually there.

> > This would also be the place where you tell the guest that it should
> > look for PV devices. I'm not familiar with how Xen announces PV
> > devices to the guest on other architectures, but you have the
> > choice between providing a full "binding", i.e. a formal specification
> > in device tree format for the guest to detect PV devices in the
> > same way as physical or emulated devices, or just providing a single
> > place in the device tree in which the guest detects the presence
> > of a xen device bus and then uses hcalls to find the devices on that
> > bus.
> 
> On x86 there is an emulated PCI device which serves as the hooking point
> for the PV drivers. For ARM I don't think it would be unreasonable to
> have a DT entry instead. I think it would be fine just represent the
> root of the "xenbus" and further discovery would occur using the normal
> xenbus mechanisms (so not a full binding). AIUI for buses which are
> enumerable this is the preferred DT scheme to use.

In general that is the case, yes. One could argue that any software
protocol between Xen and the guest is as good as any other, so it
makes sense to use the device tree to describe all devices here.
The counterargument to that is that Linux and other OSs already
support Xenbus, so there is no need to come up with a new binding.

I don't care much either way, but I think it would be good to
use similar solutions across all hypervisors. The two options
that I've seen discussed for KVM were to use either a virtual PCI
bus with individual virtio-pci devices as on the PC, or to
use the new virtio-mmio driver and individually put virtio devices
into the device tree.

> > Another topic is the question whether there are any hcalls that
> > we should try to standardize before we get another architecture
> > with multiple conflicting hcall APIs as we have on x86 and powerpc.
> 
> The hcall API we are currently targeting is the existing Xen API (at
> least the generic parts of it). These generally deal with fairly Xen
> specific concepts like grant tables etc.

Ok. It would of course still be possible to agree on an argument passing
convention so that we can share the macros used to issue the hcalls,
even if the individual commands are all different. I think I also
remember talk about the need for a set of hypervisor independent calls
that everyone should implement, but I can't remember what those were.
Maybe we can split the number space into a range of some generic and
some vendor specific hcalls?

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:34:12 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:34:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlEV-00084V-BV; Wed, 30 Nov 2011 14:33:59 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RVlET-00083w-SX
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:33:58 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1322663598!3678676!1
X-Originating-IP: [212.227.17.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjkgPT4gODA5MTE=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjE3LjkgPT4gODA5MTE=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18780 invoked from network); 30 Nov 2011 14:33:18 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.17.9) by server-2.tower-174.messagelabs.com with SMTP;
	30 Nov 2011 14:33:18 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis)
	id 0M2WiT-1QeLFc172r-00szEA; Wed, 30 Nov 2011 15:32:57 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 30 Nov 2011 14:32:54 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301303.23851.arnd@arndb.de>
	<1322659535.31810.97.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322659535.31810.97.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201111301432.54463.arnd@arndb.de>
X-Provags-ID: V02:K0:KiyS5/mKTB55iLS0W4BKJPYzZdPPz/YC+/JscRaM0ef
	CoS+X6fI7K9zEu+Ng77TIUmFPDrSEj8tg+PCYjfBVHsnNzsL36
	uqi+9cytQ1YPvwD2FEvrWzs+YuGEDazmaZJq5A0LHneEjHcvVn
	MiJd1gaw7tWiawwcHcHJK5ojBYrdc4ynccSqe2p4G8d71ZyjY2
	ul06DIizQiKrqnRX2lxQIcJyGIIOjPgnkVYTZ7UKXYdP7Yo7we
	Mj+Zd4elP7Gbm4CEofPcPG8RMwBkUjQMyeeDHdnqTkm8ip/Pjl
	jvBNURr29ZrDxrjX2vH+Ngo4D3wo3RzFHo++rAv8rIDj6+tsW6
	2kdRZHslojueUVJpqRy0=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wednesday 30 November 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 13:03 +0000, Arnd Bergmann wrote:
> > On Wednesday 30 November 2011, Stefano Stabellini wrote:
> > This is the same choice people have made for KVM, but it's not
> > necessarily the best option in the long run. In particular, this
> > board has a lot of hardware that you claim to have by putting the
> > machine number there, when you don't really want to emulate it.
> 
> This code is actually setting up dom0 which (for the most part) sees the
> real hardware.

Ok, I see.

> > Pawell Moll is working on a variant of the vexpress code that uses
> > the flattened device tree to describe the present hardware [1], and
> > I think that would be a much better target for an official release.
> > Ideally, the hypervisor should provide the device tree binary (dtb)
> > to the guest OS describing the hardware that is actually there.
> 
> Agreed. Our intention was to use DT so this fits perfectly with our
> plans.
> 
> For dom0 we would expose a (possibly filtered) version of the DT given
> to us by the firmware (e.g. we might hide a serial port to reserve it
> for Xen's use, we'd likely fiddle with the memory map etc).

Ah, very good.

> For domU the DT would presumably be constructed by the toolstack (in
> dom0 userspace) as appropriate for the guest configuration. I guess this
> needn't correspond to any particular "real" hardware platform.

Correct, but it needs to correspond to some platform that is supported
by the guest OS, which leaves the choice between emulating a real
hardware platform, adding a completely new platform specifically for
virtual machines, or something in between the two.

What I suggested to the KVM developers is to start out with the
vexpress platform, but then generalize it to the point where it fits
your needs. All hardware that one expects a guest to have (GIC, timer,
...) will still show up in the same location as on a real vexpress,
while anything that makes no sense or is better paravirtualized (LCD,
storage, ...) just becomes optional and has to be described in the
device tree if it's actually there.

> > This would also be the place where you tell the guest that it should
> > look for PV devices. I'm not familiar with how Xen announces PV
> > devices to the guest on other architectures, but you have the
> > choice between providing a full "binding", i.e. a formal specification
> > in device tree format for the guest to detect PV devices in the
> > same way as physical or emulated devices, or just providing a single
> > place in the device tree in which the guest detects the presence
> > of a xen device bus and then uses hcalls to find the devices on that
> > bus.
> 
> On x86 there is an emulated PCI device which serves as the hooking point
> for the PV drivers. For ARM I don't think it would be unreasonable to
> have a DT entry instead. I think it would be fine just represent the
> root of the "xenbus" and further discovery would occur using the normal
> xenbus mechanisms (so not a full binding). AIUI for buses which are
> enumerable this is the preferred DT scheme to use.

In general that is the case, yes. One could argue that any software
protocol between Xen and the guest is as good as any other, so it
makes sense to use the device tree to describe all devices here.
The counterargument to that is that Linux and other OSs already
support Xenbus, so there is no need to come up with a new binding.

I don't care much either way, but I think it would be good to
use similar solutions across all hypervisors. The two options
that I've seen discussed for KVM were to use either a virtual PCI
bus with individual virtio-pci devices as on the PC, or to
use the new virtio-mmio driver and individually put virtio devices
into the device tree.

> > Another topic is the question whether there are any hcalls that
> > we should try to standardize before we get another architecture
> > with multiple conflicting hcall APIs as we have on x86 and powerpc.
> 
> The hcall API we are currently targeting is the existing Xen API (at
> least the generic parts of it). These generally deal with fairly Xen
> specific concepts like grant tables etc.

Ok. It would of course still be possible to agree on an argument passing
convention so that we can share the macros used to issue the hcalls,
even if the individual commands are all different. I think I also
remember talk about the need for a set of hypervisor independent calls
that everyone should implement, but I can't remember what those were.
Maybe we can split the number space into a range of some generic and
some vendor specific hcalls?

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:36:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlGx-0008BD-Uw; Wed, 30 Nov 2011 14:36:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVlGw-0008Au-60
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:36:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322663750!3707535!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12069 invoked from network); 30 Nov 2011 14:35:50 -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;
	30 Nov 2011 14:35:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209319"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:35:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:35:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVlGH-0003Uy-Od; Wed, 30 Nov 2011 14:35:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVlGH-0006cW-Ji;
	Wed, 30 Nov 2011 14:35:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20182.16197.598115.440948@mariner.uk.xensource.com>
Date: Wed, 30 Nov 2011 14:35:49 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322648774.31810.69.camel@zakaz.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
	<1322648774.31810.69.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

~Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL"):
>> According to
> http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
> changeset 24227:1027e7d13d02 was tested and failed. That would have
> included
> 24206:05dd94652d8d tools/check: Add files missing from 24205:5c88358164cc
> 24205:5c88358164cc tools: check for libaio unless user has configured CONFIG_SYSTEM_LIBAIO=n
> 
> Now I don't think the bisector would ever have given us reason to look
> at this commits but if they had gone it at the same time as the new
> dependency this could have saved a lot of trouble tracking down the
> problem.

"gone in" I guess.  I spent a while staring that trying to make sense
of it assuming it was meant to say "done it".

But, no, because the check would have passed because it's run on the
build host and the build host has the runtime lib installed because
it's a dependency of the dev lib.

> In
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10032/build-i386/4.ts-xen-build.log (one of the runs finger by the bisector which included the above commits) I can see the CHECK-BUILD runes getting run but not the CHECK-INSTALL ones.
> 
> The call to ./chk install in the install target seems to have been
> deliberately removed in 16906:f4ee7e5793cf for reasons I don't quite
> understand (I suspect because of the install-into-a-staging-dir property
> of install). Since you install on a different host to the build host
> it's possible that the tester might need to jump through some extra
> hoops to cause this stuff to run there anyway. Perhaps the tester could
> copy tools/check over and execute "./chk install" or "make
> check-install" itself? The top-level install.sh does something like
> this, but I'm not sure you are (or should be) using it.

I could have the tester run ./chk install on the install host and
see.  But I don't think we promise that this will work.

Running ./chk install on the build host during "make install" is a
good idea but wouldn't have found this problem more quickly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:36:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlGx-0008BD-Uw; Wed, 30 Nov 2011 14:36:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVlGw-0008Au-60
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:36:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322663750!3707535!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12069 invoked from network); 30 Nov 2011 14:35:50 -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;
	30 Nov 2011 14:35:50 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209319"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:35:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:35:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVlGH-0003Uy-Od; Wed, 30 Nov 2011 14:35:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVlGH-0006cW-Ji;
	Wed, 30 Nov 2011 14:35:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20182.16197.598115.440948@mariner.uk.xensource.com>
Date: Wed, 30 Nov 2011 14:35:49 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1322648774.31810.69.camel@zakaz.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
	<1322648774.31810.69.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

~Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL"):
>> According to
> http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
> changeset 24227:1027e7d13d02 was tested and failed. That would have
> included
> 24206:05dd94652d8d tools/check: Add files missing from 24205:5c88358164cc
> 24205:5c88358164cc tools: check for libaio unless user has configured CONFIG_SYSTEM_LIBAIO=n
> 
> Now I don't think the bisector would ever have given us reason to look
> at this commits but if they had gone it at the same time as the new
> dependency this could have saved a lot of trouble tracking down the
> problem.

"gone in" I guess.  I spent a while staring that trying to make sense
of it assuming it was meant to say "done it".

But, no, because the check would have passed because it's run on the
build host and the build host has the runtime lib installed because
it's a dependency of the dev lib.

> In
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10032/build-i386/4.ts-xen-build.log (one of the runs finger by the bisector which included the above commits) I can see the CHECK-BUILD runes getting run but not the CHECK-INSTALL ones.
> 
> The call to ./chk install in the install target seems to have been
> deliberately removed in 16906:f4ee7e5793cf for reasons I don't quite
> understand (I suspect because of the install-into-a-staging-dir property
> of install). Since you install on a different host to the build host
> it's possible that the tester might need to jump through some extra
> hoops to cause this stuff to run there anyway. Perhaps the tester could
> copy tools/check over and execute "./chk install" or "make
> check-install" itself? The top-level install.sh does something like
> this, but I'm not sure you are (or should be) using it.

I could have the tester run ./chk install on the install host and
see.  But I don't think we promise that this will work.

Running ./chk install on the build host during "make install" is a
good idea but wouldn't have found this problem more quickly.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:40:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:40:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlKR-0008Rg-Rt; Wed, 30 Nov 2011 14:40:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVlKQ-0008RL-5p
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:40:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322663924!55482320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2741 invoked from network); 30 Nov 2011 14:38:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:38:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:39:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:39:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVlJn-0003WE-Dx; Wed, 30 Nov 2011 14:39:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVlJn-0006d1-CU;
	Wed, 30 Nov 2011 14:39:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20182.16415.161883.868393@mariner.uk.xensource.com>
Date: Wed, 30 Nov 2011 14:39:27 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <47bfc8f8c0be233b7655.1322598098@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<47bfc8f8c0be233b7655.1322598098@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 9] Tools: When passing no bitmap for
 the shadow log dirty bitmap clean up, we should not get EFAULT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 1 of 9] Tools: When passing no bitmap for the shadow log dirty bitmap clean up, we should not get EFAULT"):
>  tools/libxc/xc_domain.c |  2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> 
> This is due to a stale check for guest_handle_null in the
> hypervisor, which doesn't necessarily work with the hypercall
> buffers.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:40:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:40:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlKR-0008Rg-Rt; Wed, 30 Nov 2011 14:40:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVlKQ-0008RL-5p
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:40:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322663924!55482320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2741 invoked from network); 30 Nov 2011 14:38:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:38:44 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209437"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:39:27 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:39:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVlJn-0003WE-Dx; Wed, 30 Nov 2011 14:39:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVlJn-0006d1-CU;
	Wed, 30 Nov 2011 14:39:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20182.16415.161883.868393@mariner.uk.xensource.com>
Date: Wed, 30 Nov 2011 14:39:27 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <47bfc8f8c0be233b7655.1322598098@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<47bfc8f8c0be233b7655.1322598098@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 9] Tools: When passing no bitmap for
 the shadow log dirty bitmap clean up, we should not get EFAULT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 1 of 9] Tools: When passing no bitmap for the shadow log dirty bitmap clean up, we should not get EFAULT"):
>  tools/libxc/xc_domain.c |  2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> 
> This is due to a stale check for guest_handle_null in the
> hypervisor, which doesn't necessarily work with the hypercall
> buffers.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:44:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:44:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlNv-0000FV-IS; Wed, 30 Nov 2011 14:43:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVlNu-0000F6-Kz
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:43:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322664184!5658801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15464 invoked from network); 30 Nov 2011 14:43:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:43:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:43:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVlNH-0003XN-AF; Wed, 30 Nov 2011 14:43:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVlNH-0006dN-7P;
	Wed, 30 Nov 2011 14:43:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20182.16631.214743.930644@mariner.uk.xensource.com>
Date: Wed, 30 Nov 2011 14:43:03 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <5286ed662c1e26823999.1322598104@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<5286ed662c1e26823999.1322598104@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 7 of 9] Tools: Add libxc wrapper for p2m
	audit domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 7 of 9] Tools: Add libxc wrapper for p2m audit domctl"):
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Assuming the hypervisor changes go in, of course.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:44:06 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:44:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlNv-0000FV-IS; Wed, 30 Nov 2011 14:43:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVlNu-0000F6-Kz
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:43:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322664184!5658801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15464 invoked from network); 30 Nov 2011 14:43:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:43:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:43:03 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVlNH-0003XN-AF; Wed, 30 Nov 2011 14:43:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVlNH-0006dN-7P;
	Wed, 30 Nov 2011 14:43:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20182.16631.214743.930644@mariner.uk.xensource.com>
Date: Wed, 30 Nov 2011 14:43:03 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <5286ed662c1e26823999.1322598104@xdev.gridcentric.ca>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<5286ed662c1e26823999.1322598104@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 7 of 9] Tools: Add libxc wrapper for p2m
	audit domctl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 7 of 9] Tools: Add libxc wrapper for p2m audit domctl"):
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Assuming the hypervisor changes go in, of course.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:47:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlR6-0000QE-7t; Wed, 30 Nov 2011 14:47:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVlR4-0000PL-K1
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:46:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322664379!6369710!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22126 invoked from network); 30 Nov 2011 14:46:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:46:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:46:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:46:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVlQR-0003YP-Cv; Wed, 30 Nov 2011 14:46:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVlQR-0006dk-BT;
	Wed, 30 Nov 2011 14:46:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20182.16827.193505.730789@mariner.uk.xensource.com>
Date: Wed, 30 Nov 2011 14:46:19 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 1 of 2] After preparing a page for page-in, allow immediate fill-in of the page contents"):
> -    /* OP_ENABLE */
> -    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
> +    union {
> +        /* OP_ENABLE IN:  Virtual address of shared page */
> +        uint64_aligned_t shared_addr;  
> +        /* PAGING_PREP IN: buffer to immediately fill page in */
> +        uint64_aligned_t buffer;
> +    } u;

Do we care that this interface is very binary-incompatible ?  Is there
a flag or version somewhere where we can at least arrange for this to
be detected ?  Perhaps we should allocate a new domctl number for this
version, so old code gets "no idea what you're talking about" rather
than wrong behaviour ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:47:13 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:47:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlR6-0000QE-7t; Wed, 30 Nov 2011 14:47:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVlR4-0000PL-K1
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:46:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1322664379!6369710!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22126 invoked from network); 30 Nov 2011 14:46:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:46:20 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209717"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:46:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 14:46:19 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RVlQR-0003YP-Cv; Wed, 30 Nov 2011 14:46:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RVlQR-0006dk-BT;
	Wed, 30 Nov 2011 14:46:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20182.16827.193505.730789@mariner.uk.xensource.com>
Date: Wed, 30 Nov 2011 14:46:19 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>, "Tim
	\(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 1 of 2] After preparing a page for page-in, allow immediate fill-in of the page contents"):
> -    /* OP_ENABLE */
> -    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
> +    union {
> +        /* OP_ENABLE IN:  Virtual address of shared page */
> +        uint64_aligned_t shared_addr;  
> +        /* PAGING_PREP IN: buffer to immediately fill page in */
> +        uint64_aligned_t buffer;
> +    } u;

Do we care that this interface is very binary-incompatible ?  Is there
a flag or version somewhere where we can at least arrange for this to
be detected ?  Perhaps we should allocate a new domctl number for this
version, so old code gets "no idea what you're talking about" rather
than wrong behaviour ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:47:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:47:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlRO-0000S4-MO; Wed, 30 Nov 2011 14:47:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlRM-0000RD-Kd
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:47:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322664384!57151553!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3740 invoked from network); 30 Nov 2011 14:46:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:46:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209729"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:46:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:46:39 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:46:39 +0000
In-Reply-To: <1322662596-30764-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
	<1322662596-30764-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664399.31810.105.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 03/19] xl.pod.1: improve create
 documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:16 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  docs/man/xl.pod.1 |   21 +++++++++++++++------
>  1 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index 426b8e8..8cc9779 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -52,13 +52,14 @@ previously, most commands take I<domain-id> as the first parameter.
>  
>  =over 4
>  
> -=item B<create> [I<OPTIONS>] I<configfile>
> +=item B<create> [I<configfile>] [I<OPTIONS>]

I think this is actually:

	[I<OPTIONS>] [I<configfile>] [I<config-statements>]

<OPTIONS> are things like -c and -e etc.

<config-statements> are any statement you might write into I<configfile>
and you could even build a guest entirely by passing stuff on the
command line. I'm not sure if there is any ordering constraints, e.g.
I'm not sure if you can mix all these arbitrarily, but the above would
be the natural/normal ordering.

>  
> -The create subcommand requires a config file: see L<xl.cfg(5)> for
> -full details of that file format and possible options.
> +The create subcommand takes a config file as first argument: see
> +L<xl.cfg> for full details of that file format and possible options.
> +If I<configfile> is missing B<XL> creates the domain starting from the
> +default value for every option.

n.b. there is no default for "name" and so it must be given somewhere.

>  
> -I<configfile> can either be an absolute path to a file, or a relative
> -path to a file located in /etc/xen.
> +I<configfile> has to be an absolute path to a file.
>  
>  Create will return B<as soon> as the domain is started.  This B<does
>  not> mean the guest OS in the domain has actually booted, or is
> @@ -88,7 +89,15 @@ Leave the domain paused after it is created.
>  =item B<-c>
>  
>  Attach console to the domain as soon as it has started.  This is
> -useful for determining issues with crashing domains.
> +useful for determining issues with crashing domains and just as a
> +general convenience since you often want to watch the
> +domain boot.
> +
> +=item B<key=value>

Ah, this is what I was calling <config-statements> above.

Ian.

> +
> +It is possible to pass I<key=value> pairs on the command line to provide
> +options as if they were written in the configuration file; these override
> +whatever is in the I<configfile>.
>  
>  =back
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:47:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:47:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlRO-0000S4-MO; Wed, 30 Nov 2011 14:47:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlRM-0000RD-Kd
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:47:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322664384!57151553!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3740 invoked from network); 30 Nov 2011 14:46:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:46:24 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209729"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:46:39 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:46:39 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:46:39 +0000
In-Reply-To: <1322662596-30764-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
	<1322662596-30764-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664399.31810.105.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 03/19] xl.pod.1: improve create
 documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:16 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  docs/man/xl.pod.1 |   21 +++++++++++++++------
>  1 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index 426b8e8..8cc9779 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -52,13 +52,14 @@ previously, most commands take I<domain-id> as the first parameter.
>  
>  =over 4
>  
> -=item B<create> [I<OPTIONS>] I<configfile>
> +=item B<create> [I<configfile>] [I<OPTIONS>]

I think this is actually:

	[I<OPTIONS>] [I<configfile>] [I<config-statements>]

<OPTIONS> are things like -c and -e etc.

<config-statements> are any statement you might write into I<configfile>
and you could even build a guest entirely by passing stuff on the
command line. I'm not sure if there is any ordering constraints, e.g.
I'm not sure if you can mix all these arbitrarily, but the above would
be the natural/normal ordering.

>  
> -The create subcommand requires a config file: see L<xl.cfg(5)> for
> -full details of that file format and possible options.
> +The create subcommand takes a config file as first argument: see
> +L<xl.cfg> for full details of that file format and possible options.
> +If I<configfile> is missing B<XL> creates the domain starting from the
> +default value for every option.

n.b. there is no default for "name" and so it must be given somewhere.

>  
> -I<configfile> can either be an absolute path to a file, or a relative
> -path to a file located in /etc/xen.
> +I<configfile> has to be an absolute path to a file.
>  
>  Create will return B<as soon> as the domain is started.  This B<does
>  not> mean the guest OS in the domain has actually booted, or is
> @@ -88,7 +89,15 @@ Leave the domain paused after it is created.
>  =item B<-c>
>  
>  Attach console to the domain as soon as it has started.  This is
> -useful for determining issues with crashing domains.
> +useful for determining issues with crashing domains and just as a
> +general convenience since you often want to watch the
> +domain boot.
> +
> +=item B<key=value>

Ah, this is what I was calling <config-statements> above.

Ian.

> +
> +It is possible to pass I<key=value> pairs on the command line to provide
> +options as if they were written in the configuration file; these override
> +whatever is in the I<configfile>.
>  
>  =back
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlTO-0000dF-8j; Wed, 30 Nov 2011 14:49:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlTN-0000cv-IB
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:49:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322664513!5544377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26396 invoked from network); 30 Nov 2011 14:48:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:48:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209818"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:48:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:48:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:48:33 +0000
In-Reply-To: <1322662596-30764-13-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
	<1322662596-30764-13-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664513.31810.106.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 13/19] xl.pod.1: improve the
 description of the info subcommand
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:16 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> also update the example
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  docs/man/xl.pod.1 |   55 +++++++++++++++++++++++++++-------------------------
>  1 files changed, 29 insertions(+), 26 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index ab8a2f3..a765a11 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -526,39 +526,41 @@ Clears Xen's message buffer.
>  
>  Print information about the Xen host in I<name : value> format.  When
>  reporting a Xen bug, please provide this information as part of the
> -bug report.
> +bug report. See I<http://wiki.xen.org/xenwiki/ReportingBugs> on how to

Please link to the new wiki.

> +report Xen bugs.
>  
> -Sample output looks as follows (lines wrapped manually to make the man
> -page more readable):
> +Sample output looks as follows:
>  
> - host                   : talon
> - release                : 2.6.12.6-xen0
> - version                : #1 Mon Nov 14 14:26:26 EST 2005
> - machine                : i686
> - nr_cpus                : 2
> + host                   : scarlett
> + release                : 3.1.0-rc4+
> + version                : #1001 SMP Wed Oct 19 11:09:54 UTC 2011
> + machine                : x86_64
> + nr_cpus                : 4
>   nr_nodes               : 1
> - cores_per_socket       : 1
> + cores_per_socket       : 4
>   threads_per_core       : 1
> - cpu_mhz                : 696
> - hw_caps                : 0383fbff:00000000:00000000:00000040
> - total_memory           : 767
> - free_memory            : 37
> - xen_major              : 3
> - xen_minor              : 0
> - xen_extra              : -devel
> - xen_caps               : xen-3.0-x86_32
> + cpu_mhz                : 2266
> + hw_caps                : bfebfbff:28100800:00000000:00003b40:009ce3bd:00000000:00000001:00000000
> + virt_caps              : hvm hvm_directio
> + total_memory           : 6141
> + free_memory            : 4274
> + 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=0xfc000000
> - xen_changeset          : Mon Nov 14 18:13:38 2005 +0100 
> -                          7793:090e44133d40
> - cc_compiler            : gcc version 3.4.3 (Mandrakelinux 
> -                          10.2 3.4.3-7mdk)
> - cc_compile_by          : sdague
> - cc_compile_domain      : (none)
> - cc_compile_date        : Mon Nov 14 14:16:48 EST 2005
> + platform_params        : virt_start=0xffff800000000000
> + xen_changeset          : Wed Nov 02 17:09:09 2011 +0000 24066:54a5e994a241
> + xen_commandline        : com1=115200,8n1 guest_loglvl=all dom0_mem=750M console=com1 
> + cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8) 
> + cc_compile_by          : sstabellini
> + cc_compile_domain      : uk.xensource.com
> + cc_compile_date        : Tue Nov  8 12:03:05 UTC 2011
>   xend_config_format     : 4
>  
> +
>  B<FIELDS>
>  
>  Not all fields will be explained here, but some of the less obvious
> @@ -570,7 +572,8 @@ ones deserve explanation:
>  
>  A vector showing what hardware capabilities are supported by your
>  processor.  This is equivalent to, though more cryptic, the flags
> -field in /proc/cpuinfo on a normal Linux machine.
> +field in /proc/cpuinfo on a normal Linux machine: they both derive from
> +the feature bits returned by the cpuid command on x86 platforms.
>  
>  =item B<free_memory>
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:49:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:49:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlTO-0000dF-8j; Wed, 30 Nov 2011 14:49:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlTN-0000cv-IB
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:49:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1322664513!5544377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26396 invoked from network); 30 Nov 2011 14:48:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:48:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209818"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:48:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:48:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:48:33 +0000
In-Reply-To: <1322662596-30764-13-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
	<1322662596-30764-13-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664513.31810.106.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 13/19] xl.pod.1: improve the
 description of the info subcommand
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:16 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> also update the example
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  docs/man/xl.pod.1 |   55 +++++++++++++++++++++++++++-------------------------
>  1 files changed, 29 insertions(+), 26 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index ab8a2f3..a765a11 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -526,39 +526,41 @@ Clears Xen's message buffer.
>  
>  Print information about the Xen host in I<name : value> format.  When
>  reporting a Xen bug, please provide this information as part of the
> -bug report.
> +bug report. See I<http://wiki.xen.org/xenwiki/ReportingBugs> on how to

Please link to the new wiki.

> +report Xen bugs.
>  
> -Sample output looks as follows (lines wrapped manually to make the man
> -page more readable):
> +Sample output looks as follows:
>  
> - host                   : talon
> - release                : 2.6.12.6-xen0
> - version                : #1 Mon Nov 14 14:26:26 EST 2005
> - machine                : i686
> - nr_cpus                : 2
> + host                   : scarlett
> + release                : 3.1.0-rc4+
> + version                : #1001 SMP Wed Oct 19 11:09:54 UTC 2011
> + machine                : x86_64
> + nr_cpus                : 4
>   nr_nodes               : 1
> - cores_per_socket       : 1
> + cores_per_socket       : 4
>   threads_per_core       : 1
> - cpu_mhz                : 696
> - hw_caps                : 0383fbff:00000000:00000000:00000040
> - total_memory           : 767
> - free_memory            : 37
> - xen_major              : 3
> - xen_minor              : 0
> - xen_extra              : -devel
> - xen_caps               : xen-3.0-x86_32
> + cpu_mhz                : 2266
> + hw_caps                : bfebfbff:28100800:00000000:00003b40:009ce3bd:00000000:00000001:00000000
> + virt_caps              : hvm hvm_directio
> + total_memory           : 6141
> + free_memory            : 4274
> + 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=0xfc000000
> - xen_changeset          : Mon Nov 14 18:13:38 2005 +0100 
> -                          7793:090e44133d40
> - cc_compiler            : gcc version 3.4.3 (Mandrakelinux 
> -                          10.2 3.4.3-7mdk)
> - cc_compile_by          : sdague
> - cc_compile_domain      : (none)
> - cc_compile_date        : Mon Nov 14 14:16:48 EST 2005
> + platform_params        : virt_start=0xffff800000000000
> + xen_changeset          : Wed Nov 02 17:09:09 2011 +0000 24066:54a5e994a241
> + xen_commandline        : com1=115200,8n1 guest_loglvl=all dom0_mem=750M console=com1 
> + cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8) 
> + cc_compile_by          : sstabellini
> + cc_compile_domain      : uk.xensource.com
> + cc_compile_date        : Tue Nov  8 12:03:05 UTC 2011
>   xend_config_format     : 4
>  
> +
>  B<FIELDS>
>  
>  Not all fields will be explained here, but some of the less obvious
> @@ -570,7 +572,8 @@ ones deserve explanation:
>  
>  A vector showing what hardware capabilities are supported by your
>  processor.  This is equivalent to, though more cryptic, the flags
> -field in /proc/cpuinfo on a normal Linux machine.
> +field in /proc/cpuinfo on a normal Linux machine: they both derive from
> +the feature bits returned by the cpuid command on x86 platforms.
>  
>  =item B<free_memory>
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:50:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlU1-0000ie-Ox; Wed, 30 Nov 2011 14:50:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlU0-0000hd-DJ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:50:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322664561!3728687!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13813 invoked from network); 30 Nov 2011 14:49:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:49:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:49:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:49:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:49:20 +0000
In-Reply-To: <1322662596-30764-15-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
	<1322662596-30764-15-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664560.31810.107.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 15/19] xl.pod.1: remove dry-run
 option from create and cpupool-create
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:16 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> there is already a global dry-run option, there is no point in adding
> another one for each subcommand

I thin we actually deprecated these individual ones so it is correct (or
at least acceptable) to not document them IMHO.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  docs/man/xl.pod.1 |    9 ---------
>  1 files changed, 0 insertions(+), 9 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index 7620a2b..3b1407f 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -98,11 +98,6 @@ No console output.
>  
>  Use the given configuration file.
>  
> -=item B<-n>, B<--dryrun>
> -
> -Dry run - prints the resulting configuration in SXP but does not create
> -the domain.
> -
>  =item B<-p>
>  
>  Leave the domain paused after it is created.
> @@ -684,10 +679,6 @@ B<OPTIONS>
>  
>  Use the given configuration file.
>  
> -=item B<-n>, B<--dryrun>
> -
> -Dry run - prints the resulting configuration.
> -
>  =back
>  
>  =item B<cpupool-list> [I<-c|--cpus>] [I<cpu-pool>]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:50:09 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:50:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlU1-0000ie-Ox; Wed, 30 Nov 2011 14:50:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlU0-0000hd-DJ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:50:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322664561!3728687!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13813 invoked from network); 30 Nov 2011 14:49:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:49:21 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:49:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:49:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:49:20 +0000
In-Reply-To: <1322662596-30764-15-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
	<1322662596-30764-15-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664560.31810.107.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 15/19] xl.pod.1: remove dry-run
 option from create and cpupool-create
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:16 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> there is already a global dry-run option, there is no point in adding
> another one for each subcommand

I thin we actually deprecated these individual ones so it is correct (or
at least acceptable) to not document them IMHO.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  docs/man/xl.pod.1 |    9 ---------
>  1 files changed, 0 insertions(+), 9 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index 7620a2b..3b1407f 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -98,11 +98,6 @@ No console output.
>  
>  Use the given configuration file.
>  
> -=item B<-n>, B<--dryrun>
> -
> -Dry run - prints the resulting configuration in SXP but does not create
> -the domain.
> -
>  =item B<-p>
>  
>  Leave the domain paused after it is created.
> @@ -684,10 +679,6 @@ B<OPTIONS>
>  
>  Use the given configuration file.
>  
> -=item B<-n>, B<--dryrun>
> -
> -Dry run - prints the resulting configuration.
> -
>  =back
>  
>  =item B<cpupool-list> [I<-c|--cpus>] [I<cpu-pool>]



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:51:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlVm-0000ub-Cg; Wed, 30 Nov 2011 14:51:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlVk-0000u1-Qe
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:51:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322664670!5320140!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20419 invoked from network); 30 Nov 2011 14:51:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:51:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:50:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:50:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:50:07 +0000
In-Reply-To: <1322662596-30764-18-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
	<1322662596-30764-18-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664607.31810.108.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 18/19] xl.pod.1: add a refence to
 http://wiki.xen.org/xenwiki/ReportingBugs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:16 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  docs/man/xl.pod.1 |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index 54e0f51..e8a5d21 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -930,4 +930,5 @@ L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
>  
>  =head1 BUGS
>  
> -Send bugs to xen-devel@lists.xensource.com.
> +Send bugs to xen-devel@lists.xensource.com, see
> +http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.

Should be new wiki...

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:51:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlVm-0000ub-Cg; Wed, 30 Nov 2011 14:51:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlVk-0000u1-Qe
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:51:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322664670!5320140!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20419 invoked from network); 30 Nov 2011 14:51:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:51:10 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:50:08 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:50:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:50:07 +0000
In-Reply-To: <1322662596-30764-18-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
	<1322662596-30764-18-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664607.31810.108.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 18/19] xl.pod.1: add a refence to
 http://wiki.xen.org/xenwiki/ReportingBugs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:16 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  docs/man/xl.pod.1 |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index 54e0f51..e8a5d21 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -930,4 +930,5 @@ L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
>  
>  =head1 BUGS
>  
> -Send bugs to xen-devel@lists.xensource.com.
> +Send bugs to xen-devel@lists.xensource.com, see
> +http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.

Should be new wiki...

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:53:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlX7-00015F-W1; Wed, 30 Nov 2011 14:53:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlX6-00014b-C8
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:53:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322664748!143295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4366 invoked from network); 30 Nov 2011 14:52:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:52:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:52:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:52:10 +0000
In-Reply-To: <1322662596-30764-19-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
	<1322662596-30764-19-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664731.31810.110.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 19/19] xl.pod.1: add a note about
 autoballoon and dom0_mem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:16 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  docs/man/xl.pod.1 |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index e8a5d21..eb85ca0 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -32,19 +32,35 @@ each of those subcommands.
>  
>  =head1 NOTES
>  
> +=over 4
> +
> +=item start the script B</etc/init.d/xencommons> at boot time
> +
>  Most B<xl> operations rely upon B<xenstored> and B<xenconsoled>: make
>  sure you start the script B</etc/init.d/xencommons> at boot time to
>  initialize all the daemons needed by B<xl>.
>  
> +=item setup a B<xenbr0> bridge in dom0
> +
>  In the most common network configuration, you need to setup a bridge in dom0
>  named B<xenbr0> in order to have a working network in the guest domains.
>  Please refer to the documentation of your Linux distribution to know how to
>  setup the bridge.

You could also reference
http://wiki.xen.org/wiki/HostConfiguration/Networking here.

> +=item B<autoballoon>
> +
> +If you specify the amount of memory dom0 has, passing B<dom0_mem> to
> +Xen, it is highly reccomended to disable B<autoballoon>. Edit

                     recommended

> +B</etc/xen/xl.conf> and set it to 0.
> +
> +=item run xl as B<root>
> +
>  Most B<xl> commands require root privileges to run due to the
>  communications channels used to talk to the hypervisor.  Running as
>  non root will return an error.

probably ;-)

>  
> +=back
> +
>  =head1 GLOBAL OPTIONS
>  
>  Some global options are always available:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:53:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:53:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlX7-00015F-W1; Wed, 30 Nov 2011 14:53:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlX6-00014b-C8
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:53:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322664748!143295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4366 invoked from network); 30 Nov 2011 14:52:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9209964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:52:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:52:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:52:10 +0000
In-Reply-To: <1322662596-30764-19-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
	<1322662596-30764-19-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664731.31810.110.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 19/19] xl.pod.1: add a note about
 autoballoon and dom0_mem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:16 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  docs/man/xl.pod.1 |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
> index e8a5d21..eb85ca0 100644
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -32,19 +32,35 @@ each of those subcommands.
>  
>  =head1 NOTES
>  
> +=over 4
> +
> +=item start the script B</etc/init.d/xencommons> at boot time
> +
>  Most B<xl> operations rely upon B<xenstored> and B<xenconsoled>: make
>  sure you start the script B</etc/init.d/xencommons> at boot time to
>  initialize all the daemons needed by B<xl>.
>  
> +=item setup a B<xenbr0> bridge in dom0
> +
>  In the most common network configuration, you need to setup a bridge in dom0
>  named B<xenbr0> in order to have a working network in the guest domains.
>  Please refer to the documentation of your Linux distribution to know how to
>  setup the bridge.

You could also reference
http://wiki.xen.org/wiki/HostConfiguration/Networking here.

> +=item B<autoballoon>
> +
> +If you specify the amount of memory dom0 has, passing B<dom0_mem> to
> +Xen, it is highly reccomended to disable B<autoballoon>. Edit

                     recommended

> +B</etc/xen/xl.conf> and set it to 0.
> +
> +=item run xl as B<root>
> +
>  Most B<xl> commands require root privileges to run due to the
>  communications channels used to talk to the hypervisor.  Running as
>  non root will return an error.

probably ;-)

>  
> +=back
> +
>  =head1 GLOBAL OPTIONS
>  
>  Some global options are always available:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:54:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlYH-0001FL-Ki; Wed, 30 Nov 2011 14:54:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlYG-0001Ec-LT
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:54:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322664825!676606!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1745 invoked from network); 30 Nov 2011 14:53:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:53:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9210035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:53:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:53:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:53:43 +0000
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664824.31810.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 00/19] xl.pod.1 updates and fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:15 +0000, Stefano Stabellini wrote:
> Hi all,
> this patch series containes few updates and fixes to xl.pod.1.

Thanks.

I made a few (mostly incidental) comments. Rather than send ~19 acked-by
you can consider anything I didn't comment on:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Stefano Stabellini (19):
>       xl.pod.1: add a barebone description of tmem commands
>       xl.pod.1: add a description of console options
>       xl.pod.1: improve create documentation
>       xl.pod.1: add a description of the global options
>       xl.pod.1: order subcommands alphabetically
>       xl.pod.1: remove the two FIXME
>       xl.pod.1: add a reference to create in the -e option
>       xl.pod.1: state when a command requires PV drivers installed
>       xl.pod.1: better description for the sysreq subcommand
>       xl.pod.1: state when a subcommand is only available to HVM guests
>       xl.pod.1: introduce a TO BE DOCUMENTED section
>       xl.pod.1: improve the debug-keys subcommand description
>       xl.pod.1: improve the description of the info subcommand
>       xl.pod.1: improve the description of pci-list-assignable-devices
>       xl.pod.1: remove dry-run option from create and cpupool-create
>       xl.pod.1: improve description of virtual device subcommands
>       xl.pod.1: remove AUTHORS section
>       xl.pod.1: add a refence to http://wiki.xen.org/xenwiki/ReportingBugs
>       xl.pod.1: add a note about autoballoon and dom0_mem
> 
>  docs/man/xl.pod.1 |  317 ++++++++++++++++++++++++++++++++++++++---------------
>  1 files changed, 229 insertions(+), 88 deletions(-)
> 
> 
> A git branch based on xen-unstable is available here:
> 
> git://xenbits.xen.org/people/sstabellini/xen-unstable.git docs
> 
> Cheers,
> 
> Stefano
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 14:54:35 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 14:54:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlYH-0001FL-Ki; Wed, 30 Nov 2011 14:54:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVlYG-0001Ec-LT
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 14:54:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1322664825!676606!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1745 invoked from network); 30 Nov 2011 14:53:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 14:53:45 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9210035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 14:53:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 14:53:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 30 Nov 2011 14:53:43 +0000
In-Reply-To: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111301409360.31179@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322664824.31810.111.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH XenDocDay 00/19] xl.pod.1 updates and fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:15 +0000, Stefano Stabellini wrote:
> Hi all,
> this patch series containes few updates and fixes to xl.pod.1.

Thanks.

I made a few (mostly incidental) comments. Rather than send ~19 acked-by
you can consider anything I didn't comment on:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> Stefano Stabellini (19):
>       xl.pod.1: add a barebone description of tmem commands
>       xl.pod.1: add a description of console options
>       xl.pod.1: improve create documentation
>       xl.pod.1: add a description of the global options
>       xl.pod.1: order subcommands alphabetically
>       xl.pod.1: remove the two FIXME
>       xl.pod.1: add a reference to create in the -e option
>       xl.pod.1: state when a command requires PV drivers installed
>       xl.pod.1: better description for the sysreq subcommand
>       xl.pod.1: state when a subcommand is only available to HVM guests
>       xl.pod.1: introduce a TO BE DOCUMENTED section
>       xl.pod.1: improve the debug-keys subcommand description
>       xl.pod.1: improve the description of the info subcommand
>       xl.pod.1: improve the description of pci-list-assignable-devices
>       xl.pod.1: remove dry-run option from create and cpupool-create
>       xl.pod.1: improve description of virtual device subcommands
>       xl.pod.1: remove AUTHORS section
>       xl.pod.1: add a refence to http://wiki.xen.org/xenwiki/ReportingBugs
>       xl.pod.1: add a note about autoballoon and dom0_mem
> 
>  docs/man/xl.pod.1 |  317 ++++++++++++++++++++++++++++++++++++++---------------
>  1 files changed, 229 insertions(+), 88 deletions(-)
> 
> 
> A git branch based on xen-unstable is available here:
> 
> git://xenbits.xen.org/people/sstabellini/xen-unstable.git docs
> 
> Cheers,
> 
> Stefano
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:03:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:03:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlgj-0001tI-T3; Wed, 30 Nov 2011 15:03:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVlgi-0001sv-Bo
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:03:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322665349!3726105!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3Mjcz\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3Mjcz\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29411 invoked from network); 30 Nov 2011 15:02:29 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-174.messagelabs.com with SMTP;
	30 Nov 2011 15:02:29 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id EF6665EC07C;
	Wed, 30 Nov 2011 07:02:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=PCKB+kpiesmoz2bz4wbMaztFfTZDFZhSx+zbXQgO+Xcm
	3nnomxpQvMxNErpDLxLVdALzqcAzPJjHfwbkwDxOkDK+xDh/MzUkJMvlmAl9as1N
	DQKh8TdORhY9FW3OYVaUPnPJN/t/a16vDCO0kO6f0AcHVqW9jPFPd0VSXETCegg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=SA8HcN4niSKNWaMEhz5udiS/UfM=; b=Rb3iDh2M
	1uVt66YlQi4L12UH9JXX1HkNdWOajcF6blxtQPjcgNn0a2uADkzrhYbPNQXYSVDH
	/0im2ECNCWkSktLXVzSnvtut1kVPknkFCYUN/NVFArUsuqIXqMLMlzi6QY8QzVbx
	+RKhQMu0rTU4fcpjAjuI2wdp61agnCc6XS0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 6CBF55EC014; 
	Wed, 30 Nov 2011 07:02:28 -0800 (PST)
Received: from 69.196.140.71 (proxying for 69.196.140.71)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 30 Nov 2011 07:02:28 -0800
Message-ID: <6c568931e29d09dc4ab0e0b4ee9b0ec5.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111130133847.GA22200@aepfle.de>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
	<20111130124650.GA15723@aepfle.de> <20111130133847.GA22200@aepfle.de>
Date: Wed, 30 Nov 2011 07:02:28 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I see, l2emfn, etc. Clearly never exercised. Certainly worth another patch.
Andres
> On Wed, Nov 30, Olaf Hering wrote:
>
>> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
>>
>> > Check that the valid mfn is the one we are mapping, not the
>> > mfn of the page table of the foreign domain.
>> >
>> > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> Acked-by: Olaf Hering <olaf@aepfle.de>
>>
>
> There are more issues like that in this file, not just the l1e.
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:03:21 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:03:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlgj-0001tI-T3; Wed, 30 Nov 2011 15:03:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVlgi-0001sv-Bo
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:03:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322665349!3726105!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3Mjcz\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3Mjcz\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29411 invoked from network); 30 Nov 2011 15:02:29 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-174.messagelabs.com with SMTP;
	30 Nov 2011 15:02:29 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id EF6665EC07C;
	Wed, 30 Nov 2011 07:02:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=PCKB+kpiesmoz2bz4wbMaztFfTZDFZhSx+zbXQgO+Xcm
	3nnomxpQvMxNErpDLxLVdALzqcAzPJjHfwbkwDxOkDK+xDh/MzUkJMvlmAl9as1N
	DQKh8TdORhY9FW3OYVaUPnPJN/t/a16vDCO0kO6f0AcHVqW9jPFPd0VSXETCegg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=SA8HcN4niSKNWaMEhz5udiS/UfM=; b=Rb3iDh2M
	1uVt66YlQi4L12UH9JXX1HkNdWOajcF6blxtQPjcgNn0a2uADkzrhYbPNQXYSVDH
	/0im2ECNCWkSktLXVzSnvtut1kVPknkFCYUN/NVFArUsuqIXqMLMlzi6QY8QzVbx
	+RKhQMu0rTU4fcpjAjuI2wdp61agnCc6XS0=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 6CBF55EC014; 
	Wed, 30 Nov 2011 07:02:28 -0800 (PST)
Received: from 69.196.140.71 (proxying for 69.196.140.71)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 30 Nov 2011 07:02:28 -0800
Message-ID: <6c568931e29d09dc4ab0e0b4ee9b0ec5.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111130133847.GA22200@aepfle.de>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
	<20111130124650.GA15723@aepfle.de> <20111130133847.GA22200@aepfle.de>
Date: Wed, 30 Nov 2011 07:02:28 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I see, l2emfn, etc. Clearly never exercised. Certainly worth another patch.
Andres
> On Wed, Nov 30, Olaf Hering wrote:
>
>> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
>>
>> > Check that the valid mfn is the one we are mapping, not the
>> > mfn of the page table of the foreign domain.
>> >
>> > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>
>> Acked-by: Olaf Hering <olaf@aepfle.de>
>>
>
> There are more issues like that in this file, not just the l1e.
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:09:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlmq-0002BT-Qs; Wed, 30 Nov 2011 15:09:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVlmo-0002BA-Ui
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:09:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322665728!5259295!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3455 invoked from network); 30 Nov 2011 15:08:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Nov 2011 15:08:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322665727; l=218;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=edzfQF802Hd9H2dafXB6huen2iw=;
	b=lXHLd3dPSqJ4WJb8BPI+EsFl4ogATAF7yM7n/aEt42eDXRl4bWPD9CyisE7kkvhgCoP
	gvgjCzjrH3jv3zCtZoIpZL0K94MGfeP4zloTLDclg/ftX/yprC93FUnFldq6u3UBN7Vrg
	1WFPhObhCuBph4oQ+prxAi9H+2AyMkWhuRA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by smtp.strato.de (fruni mo43) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Q06bacnAUDk7Of ;
	Wed, 30 Nov 2011 16:08:42 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id AB97818637; Wed, 30 Nov 2011 16:08:41 +0100 (CET)
Date: Wed, 30 Nov 2011 16:08:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111130150841.GB8029@aepfle.de>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
	<20111130124650.GA15723@aepfle.de>
	<20111130133847.GA22200@aepfle.de>
	<6c568931e29d09dc4ab0e0b4ee9b0ec5.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6c568931e29d09dc4ab0e0b4ee9b0ec5.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, Andres Lagar-Cavilla wrote:

> I see, l2emfn, etc. Clearly never exercised. Certainly worth another patch.

I'm working on an optimization patch in that area which will cover this
change.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:09:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:09:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlmq-0002BT-Qs; Wed, 30 Nov 2011 15:09:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVlmo-0002BA-Ui
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:09:27 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322665728!5259295!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3455 invoked from network); 30 Nov 2011 15:08:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Nov 2011 15:08:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322665727; l=218;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=edzfQF802Hd9H2dafXB6huen2iw=;
	b=lXHLd3dPSqJ4WJb8BPI+EsFl4ogATAF7yM7n/aEt42eDXRl4bWPD9CyisE7kkvhgCoP
	gvgjCzjrH3jv3zCtZoIpZL0K94MGfeP4zloTLDclg/ftX/yprC93FUnFldq6u3UBN7Vrg
	1WFPhObhCuBph4oQ+prxAi9H+2AyMkWhuRA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by smtp.strato.de (fruni mo43) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Q06bacnAUDk7Of ;
	Wed, 30 Nov 2011 16:08:42 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id AB97818637; Wed, 30 Nov 2011 16:08:41 +0100 (CET)
Date: Wed, 30 Nov 2011 16:08:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20111130150841.GB8029@aepfle.de>
References: <patchbomb.1322598097@xdev.gridcentric.ca>
	<3489152b3a560be744ab.1322598105@xdev.gridcentric.ca>
	<20111130124650.GA15723@aepfle.de>
	<20111130133847.GA22200@aepfle.de>
	<6c568931e29d09dc4ab0e0b4ee9b0ec5.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6c568931e29d09dc4ab0e0b4ee9b0ec5.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 8 of 9] x86/mm: Fix checks during foreign
 mapping of paged pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, Andres Lagar-Cavilla wrote:

> I see, l2emfn, etc. Clearly never exercised. Certainly worth another patch.

I'm working on an optimization patch in that area which will cover this
change.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:11:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:11:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVloy-0002KC-Rb; Wed, 30 Nov 2011 15:11:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVloy-0002Js-9F
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:11:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322665817!55488803!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDkwNg==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25191 invoked from network); 30 Nov 2011 15:10:18 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-27.messagelabs.com with SMTP;
	30 Nov 2011 15:10:18 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 652E6458079;
	Wed, 30 Nov 2011 07:11:00 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=cL3OjtYpkVE2UsSZkGq99zKpwFK9PcXXxHlg15vZJZmO
	mw/VTLkPuwHIYJhW9Tc8aM87Z327RU+sP0ldz6gOi2gPRPdI58hjUbSJyt6ykRV9
	7dHDfgFSPfgNBJej78YzVNJqCXTKCi5E62GiZi1ZaSCTuF6cBTH+ew89lJAXjUw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=+/duSrcEwmerBL8XBspjnnS6R1E=; b=nNrlLn+t
	eBA5a0goh59+AZWdlwiVAhNOGIuLUd6KEp/DFaCJqZrXOmK6bATZGKIHFNXPnFDP
	L4HoSmTlQCUQePNyc+266iWDDCBK0POgaPOiNzNFnPBHkrIg/HrmJqA1dtIUNvuP
	yfcfVugZf/cKxlkLS4bMEDq8Wfy5ubdt9ZU=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 1D53F45808B; 
	Wed, 30 Nov 2011 07:11:00 -0800 (PST)
Received: from 69.196.140.71 (proxying for 69.196.140.71)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 30 Nov 2011 07:11:00 -0800
Message-ID: <86f622285e1ceb506d0bdbae7cfa9b0b.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111130125821.GB15723@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111130125821.GB15723@aepfle.de>
Date: Wed, 30 Nov 2011 07:11:00 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
>
>>  xen/arch/x86/hvm/hvm.c          |   20 ++-
>>  xen/arch/x86/mm/mem_event.c     |  205
>> ++++++++++++++++++++++++++++++---------
>>  xen/arch/x86/mm/mem_sharing.c   |   27 +++-
>>  xen/arch/x86/mm/p2m.c           |  104 ++++++++++---------
>>  xen/common/memory.c             |    7 +-
>>  xen/include/asm-x86/mem_event.h |   16 ++-
>>  xen/include/asm-x86/p2m.h       |    6 +-
>>  xen/include/xen/mm.h            |    2 +
>>  xen/include/xen/sched.h         |    5 +-
>>  9 files changed, 268 insertions(+), 124 deletions(-)
>>
>>
>> The memevent code currently has a mechanism for reserving space in the
>> ring
>> before putting an event, but each caller must individually ensure that
>> the
>> vCPUs are correctly paused if no space is available.
>
> I have an improved patch which uses wait queues in
> mem_event_put_request() and also the new wake_up_nr(). Using pause here
> and wait queues in get_gfn does not mix well AFAICS. My wait queue patch
> for get_gfn is not yet finished.
>
> I propose to use wait queues for both mem_event and get_gfn.

Well, given the patch I submitted, my position ought to be clear :)

I have four cents to add:
- Our patch works. We're blasting the ring with multi-vcpu events. Nothing
is ever lost, no vcpu is left blocked and forgotten.

- This isn't a problem that necessitates wait-queues for solving. Just
careful logic.

- I am not sure what your concerns about the mix are. get_gfn* would call
populate on a paged out gfn, and then go to sleep if it's a guest vcpu.
With our patch, the guest vcpu event is guaranteed to go in the ring. vcpu
pausing will stack (and unwind) properly.

- This patch does not preclude wait queues where they are absolutely
needed. I think once wait queues are in, they'll be a welcome breakthrough
for hypervisor code that just can't handle paged out pages gracefully. I
look forward to that.

Andres

>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:11:53 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:11:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVloy-0002KC-Rb; Wed, 30 Nov 2011 15:11:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVloy-0002Js-9F
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:11:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1322665817!55488803!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNDkwNg==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25191 invoked from network); 30 Nov 2011 15:10:18 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-27.messagelabs.com with SMTP;
	30 Nov 2011 15:10:18 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 652E6458079;
	Wed, 30 Nov 2011 07:11:00 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=cL3OjtYpkVE2UsSZkGq99zKpwFK9PcXXxHlg15vZJZmO
	mw/VTLkPuwHIYJhW9Tc8aM87Z327RU+sP0ldz6gOi2gPRPdI58hjUbSJyt6ykRV9
	7dHDfgFSPfgNBJej78YzVNJqCXTKCi5E62GiZi1ZaSCTuF6cBTH+ew89lJAXjUw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=+/duSrcEwmerBL8XBspjnnS6R1E=; b=nNrlLn+t
	eBA5a0goh59+AZWdlwiVAhNOGIuLUd6KEp/DFaCJqZrXOmK6bATZGKIHFNXPnFDP
	L4HoSmTlQCUQePNyc+266iWDDCBK0POgaPOiNzNFnPBHkrIg/HrmJqA1dtIUNvuP
	yfcfVugZf/cKxlkLS4bMEDq8Wfy5ubdt9ZU=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 1D53F45808B; 
	Wed, 30 Nov 2011 07:11:00 -0800 (PST)
Received: from 69.196.140.71 (proxying for 69.196.140.71)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 30 Nov 2011 07:11:00 -0800
Message-ID: <86f622285e1ceb506d0bdbae7cfa9b0b.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20111130125821.GB15723@aepfle.de>
References: <patchbomb.1322603709@xdev.gridcentric.ca>
	<43dc614d543cdf84189d.1322603711@xdev.gridcentric.ca>
	<20111130125821.GB15723@aepfle.de>
Date: Wed, 30 Nov 2011 07:11:00 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 2 of 5] Improve ring management for memory
 events. Do not lose guest events
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Tue, Nov 29, Andres Lagar-Cavilla wrote:
>
>>  xen/arch/x86/hvm/hvm.c          |   20 ++-
>>  xen/arch/x86/mm/mem_event.c     |  205
>> ++++++++++++++++++++++++++++++---------
>>  xen/arch/x86/mm/mem_sharing.c   |   27 +++-
>>  xen/arch/x86/mm/p2m.c           |  104 ++++++++++---------
>>  xen/common/memory.c             |    7 +-
>>  xen/include/asm-x86/mem_event.h |   16 ++-
>>  xen/include/asm-x86/p2m.h       |    6 +-
>>  xen/include/xen/mm.h            |    2 +
>>  xen/include/xen/sched.h         |    5 +-
>>  9 files changed, 268 insertions(+), 124 deletions(-)
>>
>>
>> The memevent code currently has a mechanism for reserving space in the
>> ring
>> before putting an event, but each caller must individually ensure that
>> the
>> vCPUs are correctly paused if no space is available.
>
> I have an improved patch which uses wait queues in
> mem_event_put_request() and also the new wake_up_nr(). Using pause here
> and wait queues in get_gfn does not mix well AFAICS. My wait queue patch
> for get_gfn is not yet finished.
>
> I propose to use wait queues for both mem_event and get_gfn.

Well, given the patch I submitted, my position ought to be clear :)

I have four cents to add:
- Our patch works. We're blasting the ring with multi-vcpu events. Nothing
is ever lost, no vcpu is left blocked and forgotten.

- This isn't a problem that necessitates wait-queues for solving. Just
careful logic.

- I am not sure what your concerns about the mix are. get_gfn* would call
populate on a paged out gfn, and then go to sleep if it's a guest vcpu.
With our patch, the guest vcpu event is guaranteed to go in the ring. vcpu
pausing will stack (and unwind) properly.

- This patch does not preclude wait queues where they are absolutely
needed. I think once wait queues are in, they'll be a welcome breakthrough
for hypervisor code that just can't handle paged out pages gracefully. I
look forward to that.

Andres

>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:14:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlrN-0002XJ-Fc; Wed, 30 Nov 2011 15:14:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVlrM-0002Wv-A9
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:14:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322665888!46467002!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU4MjU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29980 invoked from network); 30 Nov 2011 15:11:28 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.202) by server-14.tower-27.messagelabs.com with SMTP;
	30 Nov 2011 15:11:28 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id EE30525006C;
	Wed, 30 Nov 2011 07:13:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=cPQSq+FM0HBbBaOuCmngKZ2QARg1a397bTBxnGBBA8eU
	n1sXAm2AzGCh2L9LWRGc1KZK2kz/nO2iycK3KNQM3Y1dQ+uMnvHYza8TgwfiUVD6
	aE0MDLd2LNQFiDtHGhcJDsCReAmSODAyVy/GZ9oQy15JJ8DbHCiTLdgIq8+VuKA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=POSL55fQiFxzyTWIDqlgpLWeVfk=; b=G0M0STw0
	6MBa2msPZYs5migzoVKujZSjdTDfpHFHMCNajOB3jmXZt6O1zvKuCKssKfJEoyG2
	qz7eqpRTZBX94RDGTZqL6pG32fwxOU4LlHNNes5X5S7NHZ6p+qyNPSvOgb3X7kk4
	DRyiOgxxidq4Dubrmqb105EfeHGCgv6ymUk=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id 7090925006B; 
	Wed, 30 Nov 2011 07:13:28 -0800 (PST)
Received: from 69.196.140.71 (proxying for 69.196.140.71)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 30 Nov 2011 07:13:28 -0800
Message-ID: <46e688f8f091ced3a0d5458280392477.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20182.16827.193505.730789@mariner.uk.xensource.com>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
	<20182.16827.193505.730789@mariner.uk.xensource.com>
Date: Wed, 30 Nov 2011 07:13:28 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Andres Lagar-Cavilla writes ("[PATCH 1 of 2] After preparing a page for
> page-in, allow immediate fill-in of the page contents"):
>> -    /* OP_ENABLE */
>> -    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared
>> page */
>> +    union {
>> +        /* OP_ENABLE IN:  Virtual address of shared page */
>> +        uint64_aligned_t shared_addr;
>> +        /* PAGING_PREP IN: buffer to immediately fill page in */
>> +        uint64_aligned_t buffer;
>> +    } u;
>
> Do we care that this interface is very binary-incompatible ?  Is there
> a flag or version somewhere where we can at least arrange for this to
> be detected ?  Perhaps we should allocate a new domctl number for this
> version, so old code gets "no idea what you're talking about" rather
> than wrong behaviour ?

I turned the field into a union of the same size, so it should be binary
compatible. Should...

There is no reason to use a union other than clarity: "this field is used
for different purposes in different domctls".

I think this is fine, but your call.

Andres
>
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:14:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlrN-0002XJ-Fc; Wed, 30 Nov 2011 15:14:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RVlrM-0002Wv-A9
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:14:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1322665888!46467002!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTU4MjU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29980 invoked from network); 30 Nov 2011 15:11:28 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.202) by server-14.tower-27.messagelabs.com with SMTP;
	30 Nov 2011 15:11:28 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id EE30525006C;
	Wed, 30 Nov 2011 07:13:28 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=cPQSq+FM0HBbBaOuCmngKZ2QARg1a397bTBxnGBBA8eU
	n1sXAm2AzGCh2L9LWRGc1KZK2kz/nO2iycK3KNQM3Y1dQ+uMnvHYza8TgwfiUVD6
	aE0MDLd2LNQFiDtHGhcJDsCReAmSODAyVy/GZ9oQy15JJ8DbHCiTLdgIq8+VuKA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:in-reply-to:references:date:subject:from:to:cc
	:reply-to:mime-version:content-type:content-transfer-encoding;
	s=lagarcavilla.org; bh=POSL55fQiFxzyTWIDqlgpLWeVfk=; b=G0M0STw0
	6MBa2msPZYs5migzoVKujZSjdTDfpHFHMCNajOB3jmXZt6O1zvKuCKssKfJEoyG2
	qz7eqpRTZBX94RDGTZqL6pG32fwxOU4LlHNNes5X5S7NHZ6p+qyNPSvOgb3X7kk4
	DRyiOgxxidq4Dubrmqb105EfeHGCgv6ymUk=
Received: from webmail.lagarcavilla.org (ahfbbjcaiaae.dreamhost.com
	[75.119.208.4]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPA id 7090925006B; 
	Wed, 30 Nov 2011 07:13:28 -0800 (PST)
Received: from 69.196.140.71 (proxying for 69.196.140.71)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 30 Nov 2011 07:13:28 -0800
Message-ID: <46e688f8f091ced3a0d5458280392477.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20182.16827.193505.730789@mariner.uk.xensource.com>
References: <patchbomb.1322603559@xdev.gridcentric.ca>
	<0ce71e5bfaac7e8fe5b8.1322603560@xdev.gridcentric.ca>
	<20182.16827.193505.730789@mariner.uk.xensource.com>
Date: Wed, 30 Nov 2011 07:13:28 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	"andres@gridcentric.ca" <andres@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, "keir.xen@gmail.com" <keir.xen@gmail.com>,
	"JBeulich@suse.com" <jbeulich@suse.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in,
 allow immediate fill-in of the page contents
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Andres Lagar-Cavilla writes ("[PATCH 1 of 2] After preparing a page for
> page-in, allow immediate fill-in of the page contents"):
>> -    /* OP_ENABLE */
>> -    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared
>> page */
>> +    union {
>> +        /* OP_ENABLE IN:  Virtual address of shared page */
>> +        uint64_aligned_t shared_addr;
>> +        /* PAGING_PREP IN: buffer to immediately fill page in */
>> +        uint64_aligned_t buffer;
>> +    } u;
>
> Do we care that this interface is very binary-incompatible ?  Is there
> a flag or version somewhere where we can at least arrange for this to
> be detected ?  Perhaps we should allocate a new domctl number for this
> version, so old code gets "no idea what you're talking about" rather
> than wrong behaviour ?

I turned the field into a union of the same size, so it should be binary
compatible. Should...

There is no reason to use a union other than clarity: "this field is used
for different purposes in different domctls".

I think this is fine, but your call.

Andres
>
> Ian.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlwx-0002qz-Iu; Wed, 30 Nov 2011 15:19:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVlwv-0002qp-Bz
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:19:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322666353!5342720!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21827 invoked from network); 30 Nov 2011 15:19:14 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 15:19:14 -0000
Received: by vbbfq11 with SMTP id fq11so584530vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 07:19:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=otQAXFEBATkEpDYtkeTYu1/P6Wq5XeEE99evwkOy4Mg=;
	b=to/4y2KCfI0UV5CVY4zW31uQWHRVNfIBeR6Y7EZig94y/+/goa/+xaR4HgsVGLxgCg
	unHllJGYu1+RGYNM6X51oP1+4TH3oobLI1w1bXbG4n/Gxv1WFtXWwbYdDuYpKLtjVE55
	kwmwhsAsmiKLf6LoWti96WiSPsZQ62zW3dAas=
Received: by 10.182.149.33 with SMTP id tx1mr497760obb.62.1322666353278;
	Wed, 30 Nov 2011 07:19:13 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id p4sm3739995obt.4.2011.11.30.07.19.07
	(version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 07:19:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 30 Nov 2011 07:19:03 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAFB8967.26128%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 6] Add support for a VM generation ID
	virtual device (v2)
Thread-Index: Acyvc2SNQS/atcU160y4DsrB9+37Ng==
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0 of 6] Add support for a VM generation ID
 virtual device (v2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/2011 10:53, "Paul Durrant" <paul.durrant@citrix.com> wrote:

> Patch 1 adds the device and an acpi_info field to allow population
> of the ADDR package.

Applied.

> Patch 2 adds ctype infrastructure to hvloader in preparation for...

Applied.

> Patch 3 adds all the code to plumb the value of a new 'generation_id'
> parameter in the VM config through to the VM generation id buffer at
> VM boot time.

Applied the hvmloader part. Forgot to change the comment that refers to
libxl, oops! But I didn;t check in the libxl part (it didn't apply cleanly
to tip anyway).

> Patch 4 adds an implementation of sprintf() to hvmloader.

Applied (inc. snprintf update).

> Patch 5 adds an implementation of xenstore-write to hvmloader.

Applied (inc. incremental fix).

> Patch 6 adds support for tracking the address of the VM generation id
> buffer (via xenstore) across save/restore or migrate and updating the
> value of the buffer with the value from the VM config file.

Applied the hvmloader part.

In summary, all the hvmloader changes are in. A toolstack maintainer should
check in the other toolstack parts.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:20:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:20:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVlwx-0002qz-Iu; Wed, 30 Nov 2011 15:19:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVlwv-0002qp-Bz
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:19:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322666353!5342720!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21827 invoked from network); 30 Nov 2011 15:19:14 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 15:19:14 -0000
Received: by vbbfq11 with SMTP id fq11so584530vbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 07:19:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=otQAXFEBATkEpDYtkeTYu1/P6Wq5XeEE99evwkOy4Mg=;
	b=to/4y2KCfI0UV5CVY4zW31uQWHRVNfIBeR6Y7EZig94y/+/goa/+xaR4HgsVGLxgCg
	unHllJGYu1+RGYNM6X51oP1+4TH3oobLI1w1bXbG4n/Gxv1WFtXWwbYdDuYpKLtjVE55
	kwmwhsAsmiKLf6LoWti96WiSPsZQ62zW3dAas=
Received: by 10.182.149.33 with SMTP id tx1mr497760obb.62.1322666353278;
	Wed, 30 Nov 2011 07:19:13 -0800 (PST)
Received: from [10.68.4.99] ([96.49.152.177])
	by mx.google.com with ESMTPS id p4sm3739995obt.4.2011.11.30.07.19.07
	(version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 07:19:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 30 Nov 2011 07:19:03 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paul Durrant <paul.durrant@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CAFB8967.26128%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0 of 6] Add support for a VM generation ID
	virtual device (v2)
Thread-Index: Acyvc2SNQS/atcU160y4DsrB9+37Ng==
In-Reply-To: <patchbomb.1322563998@cosworth.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0 of 6] Add support for a VM generation ID
 virtual device (v2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 29/11/2011 10:53, "Paul Durrant" <paul.durrant@citrix.com> wrote:

> Patch 1 adds the device and an acpi_info field to allow population
> of the ADDR package.

Applied.

> Patch 2 adds ctype infrastructure to hvloader in preparation for...

Applied.

> Patch 3 adds all the code to plumb the value of a new 'generation_id'
> parameter in the VM config through to the VM generation id buffer at
> VM boot time.

Applied the hvmloader part. Forgot to change the comment that refers to
libxl, oops! But I didn;t check in the libxl part (it didn't apply cleanly
to tip anyway).

> Patch 4 adds an implementation of sprintf() to hvmloader.

Applied (inc. snprintf update).

> Patch 5 adds an implementation of xenstore-write to hvmloader.

Applied (inc. incremental fix).

> Patch 6 adds support for tracking the address of the VM generation id
> buffer (via xenstore) across save/restore or migrate and updating the
> value of the buffer with the value from the VM config file.

Applied the hvmloader part.

In summary, all the hvmloader changes are in. A toolstack maintainer should
check in the other toolstack parts.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:27:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:27:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVm4A-00032Y-LJ; Wed, 30 Nov 2011 15:27:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVm49-00032T-Fe
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:27:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322666802!5259077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29863 invoked from network); 30 Nov 2011 15:26:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 15:26:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9211073"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 15:26:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 15:26:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVm3W-0003mB-5o;
	Wed, 30 Nov 2011 15:26:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVm3V-00038f-Tl;
	Wed, 30 Nov 2011 15:26:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10190-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 15:26:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10190: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10190 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10190/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   like 10189
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  64088ba60263
baseline version:
 xen                  df7cec2c6c03

------------------------------------------------------------
People who touched revisions under test:
  Haitao Shan <maillists.shan@gmail.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=64088ba60263
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 64088ba60263
+ branch=xen-unstable
+ revision=64088ba60263
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 64088ba60263 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:27:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:27:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVm4A-00032Y-LJ; Wed, 30 Nov 2011 15:27:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVm49-00032T-Fe
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:27:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322666802!5259077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29863 invoked from network); 30 Nov 2011 15:26:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 15:26:42 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9211073"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 15:26:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 15:26:42 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVm3W-0003mB-5o;
	Wed, 30 Nov 2011 15:26:42 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVm3V-00038f-Tl;
	Wed, 30 Nov 2011 15:26:42 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10190-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 15:26:41 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10190: tolerable FAIL - PUSHED
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10190 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10190/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   like 10189
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  64088ba60263
baseline version:
 xen                  df7cec2c6c03

------------------------------------------------------------
People who touched revisions under test:
  Haitao Shan <maillists.shan@gmail.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=64088ba60263
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable 64088ba60263
+ branch=xen-unstable
+ revision=64088ba60263
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ : xen@xenbits.xensource.com
+ : xen@xenbits.xensource.com:git/linux-pvops
+ : master
+ : tested/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 64088ba60263 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:44:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmKi-0003Nf-5x; Wed, 30 Nov 2011 15:44:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmKg-0003NV-AE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:44:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322667827!5629153!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2423 invoked from network); 30 Nov 2011 15:43:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 15:43:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 15:43:47 +0000
Message-Id: <4ED65D42020000780006465D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 15:43:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liwei" <xieliwei@gmail.com>
References: <CAPE0SYwiSFPZsV5S1Fu=OFgezTzZZVo5oUsG_ua5gFm=-TF2OA@mail.gmail.com>
In-Reply-To: <CAPE0SYwiSFPZsV5S1Fu=OFgezTzZZVo5oUsG_ua5gFm=-TF2OA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen BUG at page_alloc.c:425, alloc_heap_pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.11.11 at 11:45, Liwei <xieliwei@gmail.com> wrote:
> Hello all,
>     My graphics card died today so I temporarily swapped it out for
> the old GTX460.
>     Now xen keeps bugging out on me within minutes after boot. I
> realise this could be a hardware problem, but what does this bug point
> to?

Internal state corruption in Xen. Without a full log and information on
what the system is doing at the point of the crash there's pretty little
we can guess from what you provided.

Jan

> (XEN) ----[ Xen-4.1.2-rc3-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    5
> (XEN) RIP:    e008:[<ffff82c480113bf2>] alloc_heap_pages+0x542/0x570
> (XEN) RFLAGS: 0000000000010206   CONTEXT: hypervisor
> (XEN) rax: ffff82c480290e40   rbx: ffff82f606700000   rcx: 0000000000000009
> (XEN) rdx: ffff82c4802929e0   rsi: 00000000ffffffff   rdi: ffff82c480290c40
> (XEN) rbp: ffff82f606703040   rsp: ffff830431b7fcd8   r8:  0000000000000000
> (XEN) r9:  ffff82c480294088   r10: 0000000000000015   r11: ffff82c480293fe0
> (XEN) r12: ffff82c4802bba9c   r13: 0000000000000182   r14: 0000000000000200
> (XEN) r15: 0180000000000000   cr0: 0000000080050033   cr4: 00000000000026f0
> (XEN) cr3: 0000000408398000   cr2: ffff880018b011f0
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=ffff830431b7fcd8:
> (XEN)    0000000000000027 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000001 ffff82c480120a63
> (XEN)    0000000000000002 ffff8302b5e1e000 0000000000000000 0000000000000027
> (XEN)    0000000000000009 0000000000000000 ffff830431b7ff18 ffff82c480114716
> (XEN)    ffff830431b7ff18 000000000215400c ffff8302b5e1e000 0000000000000200
> (XEN)    0000000000000001 ffff82c4801112b0 0000000000000292 0000000000000292
> (XEN)    ffff82f6082a50a0 ffff830431bcd068 ffff82c4802bc5d0 0000000000000000
> (XEN)    0000000000000009 0000000002156004 0000000000000004 ffff830431b7ff18
> (XEN)    0000000000000006 ffff82c480298480 ffff82c400000004 ffff830431b88080
> (XEN)    ffff82c4802a9f60 0000000000000092 000000000000001e ffff82c4802bb880
> (XEN)    0000000000000005 ffff830431b880a8 ffff82c480122d1b ffff8300bf76a000
> (XEN)    ffff8300bf76a000 ffff82c480150769 0000001da663789e ffff82c48015421d
> (XEN)    ffff82c4802bb6e0 ffff82c48011dc4b 0000000000000000 ffff82c48017ea86
> (XEN)    ffff8300bf76a000 0000000001c9c380 0000000002154004 0000000000000004
> (XEN)    0000000000000009 0000000000000002 ffff8302b5e1e000 000000000007c200
> (XEN)    0000000000338200 0000000000000100 00007f6de3ec33b7 0000000000000033
> (XEN)    0000000000000246 ffff8300bf76a000 00000000ffffffe7 00007fff5d864a80
> (XEN)    ffff8800272edd40 00007fff5d864b70 000000000007f800 ffff82c4801f6418
> (XEN)    000000000007f800 00007fff5d864b70 ffff8800272edd40 00007fff5d864a80
> (XEN)    00000000ffffffe7 ffff88002d5c8000 0000000000000282 00007fff5d864ac0
> (XEN) Xen call trace:
> (XEN)    [<ffff82c480113bf2>] alloc_heap_pages+0x542/0x570
> (XEN)    [<ffff82c480120a63>] cpumask_raise_softirq+0x83/0x90
> (XEN)    [<ffff82c480114716>] alloc_domheap_pages+0xe6/0x110
> (XEN)    [<ffff82c4801112b0>] do_memory_op+0x680/0x1ae0
> (XEN)    [<ffff82c480122d1b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c480150769>] continue_nonidle_domain+0x9/0x30
> (XEN)    [<ffff82c48015421d>] continue_running+0xd/0x20
> (XEN)    [<ffff82c48011dc4b>] schedule+0x42b/0x560
> (XEN)    [<ffff82c48017ea86>] copy_from_user+0x26/0x90
> (XEN)    [<ffff82c4801f6418>] syscall_enter+0x88/0x8d
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 5:
> (XEN) Xen BUG at page_alloc.c:425
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:44:59 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:44:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmKi-0003Nf-5x; Wed, 30 Nov 2011 15:44:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmKg-0003NV-AE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:44:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322667827!5629153!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2423 invoked from network); 30 Nov 2011 15:43:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 15:43:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 15:43:47 +0000
Message-Id: <4ED65D42020000780006465D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 15:43:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liwei" <xieliwei@gmail.com>
References: <CAPE0SYwiSFPZsV5S1Fu=OFgezTzZZVo5oUsG_ua5gFm=-TF2OA@mail.gmail.com>
In-Reply-To: <CAPE0SYwiSFPZsV5S1Fu=OFgezTzZZVo5oUsG_ua5gFm=-TF2OA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen BUG at page_alloc.c:425, alloc_heap_pages
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.11.11 at 11:45, Liwei <xieliwei@gmail.com> wrote:
> Hello all,
>     My graphics card died today so I temporarily swapped it out for
> the old GTX460.
>     Now xen keeps bugging out on me within minutes after boot. I
> realise this could be a hardware problem, but what does this bug point
> to?

Internal state corruption in Xen. Without a full log and information on
what the system is doing at the point of the crash there's pretty little
we can guess from what you provided.

Jan

> (XEN) ----[ Xen-4.1.2-rc3-pre  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    5
> (XEN) RIP:    e008:[<ffff82c480113bf2>] alloc_heap_pages+0x542/0x570
> (XEN) RFLAGS: 0000000000010206   CONTEXT: hypervisor
> (XEN) rax: ffff82c480290e40   rbx: ffff82f606700000   rcx: 0000000000000009
> (XEN) rdx: ffff82c4802929e0   rsi: 00000000ffffffff   rdi: ffff82c480290c40
> (XEN) rbp: ffff82f606703040   rsp: ffff830431b7fcd8   r8:  0000000000000000
> (XEN) r9:  ffff82c480294088   r10: 0000000000000015   r11: ffff82c480293fe0
> (XEN) r12: ffff82c4802bba9c   r13: 0000000000000182   r14: 0000000000000200
> (XEN) r15: 0180000000000000   cr0: 0000000080050033   cr4: 00000000000026f0
> (XEN) cr3: 0000000408398000   cr2: ffff880018b011f0
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=ffff830431b7fcd8:
> (XEN)    0000000000000027 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000000 0000000000000001 ffff82c480120a63
> (XEN)    0000000000000002 ffff8302b5e1e000 0000000000000000 0000000000000027
> (XEN)    0000000000000009 0000000000000000 ffff830431b7ff18 ffff82c480114716
> (XEN)    ffff830431b7ff18 000000000215400c ffff8302b5e1e000 0000000000000200
> (XEN)    0000000000000001 ffff82c4801112b0 0000000000000292 0000000000000292
> (XEN)    ffff82f6082a50a0 ffff830431bcd068 ffff82c4802bc5d0 0000000000000000
> (XEN)    0000000000000009 0000000002156004 0000000000000004 ffff830431b7ff18
> (XEN)    0000000000000006 ffff82c480298480 ffff82c400000004 ffff830431b88080
> (XEN)    ffff82c4802a9f60 0000000000000092 000000000000001e ffff82c4802bb880
> (XEN)    0000000000000005 ffff830431b880a8 ffff82c480122d1b ffff8300bf76a000
> (XEN)    ffff8300bf76a000 ffff82c480150769 0000001da663789e ffff82c48015421d
> (XEN)    ffff82c4802bb6e0 ffff82c48011dc4b 0000000000000000 ffff82c48017ea86
> (XEN)    ffff8300bf76a000 0000000001c9c380 0000000002154004 0000000000000004
> (XEN)    0000000000000009 0000000000000002 ffff8302b5e1e000 000000000007c200
> (XEN)    0000000000338200 0000000000000100 00007f6de3ec33b7 0000000000000033
> (XEN)    0000000000000246 ffff8300bf76a000 00000000ffffffe7 00007fff5d864a80
> (XEN)    ffff8800272edd40 00007fff5d864b70 000000000007f800 ffff82c4801f6418
> (XEN)    000000000007f800 00007fff5d864b70 ffff8800272edd40 00007fff5d864a80
> (XEN)    00000000ffffffe7 ffff88002d5c8000 0000000000000282 00007fff5d864ac0
> (XEN) Xen call trace:
> (XEN)    [<ffff82c480113bf2>] alloc_heap_pages+0x542/0x570
> (XEN)    [<ffff82c480120a63>] cpumask_raise_softirq+0x83/0x90
> (XEN)    [<ffff82c480114716>] alloc_domheap_pages+0xe6/0x110
> (XEN)    [<ffff82c4801112b0>] do_memory_op+0x680/0x1ae0
> (XEN)    [<ffff82c480122d1b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c480150769>] continue_nonidle_domain+0x9/0x30
> (XEN)    [<ffff82c48015421d>] continue_running+0xd/0x20
> (XEN)    [<ffff82c48011dc4b>] schedule+0x42b/0x560
> (XEN)    [<ffff82c48017ea86>] copy_from_user+0x26/0x90
> (XEN)    [<ffff82c4801f6418>] syscall_enter+0x88/0x8d
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 5:
> (XEN) Xen BUG at page_alloc.c:425
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:57:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:57:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmW9-0003Yv-HM; Wed, 30 Nov 2011 15:56:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVmW8-0003Yq-7a
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:56:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322668537!5316857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11005 invoked from network); 30 Nov 2011 15:55:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 15:55:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9211921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 15:55:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 15:55:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 15:55:37 +0000
In-Reply-To: <20182.16197.598115.440948@mariner.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
	<1322648774.31810.69.camel@zakaz.uk.xensource.com>
	<20182.16197.598115.440948@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322668537.31810.119.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:35 +0000, Ian Jackson wrote:
> ~Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL"):
> >> According to
> > http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
> > changeset 24227:1027e7d13d02 was tested and failed. That would have
> > included
> > 24206:05dd94652d8d tools/check: Add files missing from 24205:5c88358164cc
> > 24205:5c88358164cc tools: check for libaio unless user has configured CONFIG_SYSTEM_LIBAIO=n
> > 
> > Now I don't think the bisector would ever have given us reason to look
> > at this commits but if they had gone it at the same time as the new
> > dependency this could have saved a lot of trouble tracking down the
> > problem.
> 
> "gone in" I guess.  I spent a while staring that trying to make sense
> of it assuming it was meant to say "done it".

Yes, sorry. "... if they had gone in at the ... "

> But, no, because the check would have passed because it's run on the
> build host and the build host has the runtime lib installed because
> it's a dependency of the dev lib.
> 
> > In
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/10032/build-i386/4.ts-xen-build.log (one of the runs finger by the bisector which included the above commits) I can see the CHECK-BUILD runes getting run but not the CHECK-INSTALL ones.
> > 
> > The call to ./chk install in the install target seems to have been
> > deliberately removed in 16906:f4ee7e5793cf for reasons I don't quite
> > understand (I suspect because of the install-into-a-staging-dir property
> > of install). Since you install on a different host to the build host
> > it's possible that the tester might need to jump through some extra
> > hoops to cause this stuff to run there anyway. Perhaps the tester could
> > copy tools/check over and execute "./chk install" or "make
> > check-install" itself? The top-level install.sh does something like
> > this, but I'm not sure you are (or should be) using it.
> 
> I could have the tester run ./chk install on the install host and
> see.  But I don't think we promise that this will work.

We could decide to promise it going forward if it is useful.

> Running ./chk install on the build host during "make install" is a
> good idea but wouldn't have found this problem more quickly.

Right, if they are running on the same host I don't think ./chk install
will find much which is not found by ./chk build in practice.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 15:57:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 15:57:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmW9-0003Yv-HM; Wed, 30 Nov 2011 15:56:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVmW8-0003Yq-7a
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 15:56:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322668537!5316857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11005 invoked from network); 30 Nov 2011 15:55:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 15:55:37 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9211921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 15:55:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 15:55:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 15:55:37 +0000
In-Reply-To: <20182.16197.598115.440948@mariner.uk.xensource.com>
References: <osstest-10135-mainreport@xen.org>
	<20179.30537.970866.190935@mariner.uk.xensource.com>
	<1322648774.31810.69.camel@zakaz.uk.xensource.com>
	<20182.16197.598115.440948@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322668537.31810.119.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:35 +0000, Ian Jackson wrote:
> ~Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL"):
> >> According to
> > http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
> > changeset 24227:1027e7d13d02 was tested and failed. That would have
> > included
> > 24206:05dd94652d8d tools/check: Add files missing from 24205:5c88358164cc
> > 24205:5c88358164cc tools: check for libaio unless user has configured CONFIG_SYSTEM_LIBAIO=n
> > 
> > Now I don't think the bisector would ever have given us reason to look
> > at this commits but if they had gone it at the same time as the new
> > dependency this could have saved a lot of trouble tracking down the
> > problem.
> 
> "gone in" I guess.  I spent a while staring that trying to make sense
> of it assuming it was meant to say "done it".

Yes, sorry. "... if they had gone in at the ... "

> But, no, because the check would have passed because it's run on the
> build host and the build host has the runtime lib installed because
> it's a dependency of the dev lib.
> 
> > In
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/10032/build-i386/4.ts-xen-build.log (one of the runs finger by the bisector which included the above commits) I can see the CHECK-BUILD runes getting run but not the CHECK-INSTALL ones.
> > 
> > The call to ./chk install in the install target seems to have been
> > deliberately removed in 16906:f4ee7e5793cf for reasons I don't quite
> > understand (I suspect because of the install-into-a-staging-dir property
> > of install). Since you install on a different host to the build host
> > it's possible that the tester might need to jump through some extra
> > hoops to cause this stuff to run there anyway. Perhaps the tester could
> > copy tools/check over and execute "./chk install" or "make
> > check-install" itself? The top-level install.sh does something like
> > this, but I'm not sure you are (or should be) using it.
> 
> I could have the tester run ./chk install on the install host and
> see.  But I don't think we promise that this will work.

We could decide to promise it going forward if it is useful.

> Running ./chk install on the build host during "make install" is a
> good idea but wouldn't have found this problem more quickly.

Right, if they are running on the same host I don't think ./chk install
will find much which is not found by ./chk build in practice.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:06:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmfL-0004Ff-Jb; Wed, 30 Nov 2011 16:05:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmfK-0004FT-EC
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:05:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322669097!5672019!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20598 invoked from network); 30 Nov 2011 16:05:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:05:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:04:57 +0000
Message-Id: <4ED66238020000780006466F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:04:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/4] x86: emulator improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

1: x86/emulator: generalize movq emulation (SSE2 and AVX variants)
2: x86/emulator: add emulation of SIMD FP moves
3: x86/emulator: properly handle lzcnt and tzcnt
4: x86/emulator: cleanup

Note that while AVX support is being included here, I didn't add tests for
VEX encoded instructions in the tester, since I don't have hardware to
actually try this out on.

Signed-off-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:06:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmfL-0004Ff-Jb; Wed, 30 Nov 2011 16:05:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmfK-0004FT-EC
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:05:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1322669097!5672019!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20598 invoked from network); 30 Nov 2011 16:05:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:05:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:04:57 +0000
Message-Id: <4ED66238020000780006466F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:04:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/4] x86: emulator improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

1: x86/emulator: generalize movq emulation (SSE2 and AVX variants)
2: x86/emulator: add emulation of SIMD FP moves
3: x86/emulator: properly handle lzcnt and tzcnt
4: x86/emulator: cleanup

Note that while AVX support is being included here, I didn't add tests for
VEX encoded instructions in the tester, since I don't have hardware to
actually try this out on.

Signed-off-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:07:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmgN-0004JA-Im; Wed, 30 Nov 2011 16:06:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmgL-0004IN-Qu
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:06:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322669170!5619042!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1308 invoked from network); 30 Nov 2011 16:06:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:06:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:06:10 +0000
Message-Id: <4ED662810200007800064677@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:06:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC5EA5061.0__="
Subject: [Xen-devel] [PATCH 2/4] x86/emulator: add emulation of SIMD FP moves
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartC5EA5061.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Clone the existing movq emulation to also support the most fundamental
SIMD FP moves.

Extend the testing code to also exercise these instructions.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -629,6 +629,60 @@ int main(int argc, char **argv)
     else
         printf("skipped\n");
=20
+    printf("%-40s", "Testing movsd %xmm5,(%ecx)...");
+    memset(res, 0x77, 64);
+    memset(res + 10, 0x66, 8);
+    if ( stack_exec && cpu_has_sse2 )
+    {
+        extern const unsigned char movsd_to_mem[];
+
+        asm volatile ( "movlpd %0, %%xmm5\n\t"
+                       "movhpd %0, %%xmm5\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movsd_to_mem: movsd %%xmm5, (%1)\n"
+                       ".popsection" :: "m" (res[10]), "c" (NULL) );
+
+        memcpy(instr, movsd_to_mem, 15);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D (unsigned long)(res + 2);
+        regs.edx    =3D 0;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( (rc !=3D X86EMUL_OKAY) || memcmp(res, res + 8, 32) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+    {
+        printf("skipped\n");
+        memset(res + 2, 0x66, 8);
+    }
+
+    printf("%-40s", "Testing movaps (%edx),%xmm7...");
+    if ( stack_exec && cpu_has_sse )
+    {
+        extern const unsigned char movaps_from_mem[];
+
+        asm volatile ( "xorps %%xmm7, %%xmm7\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movaps_from_mem: movaps (%0), %%xmm7\n"
+                       ".popsection" :: "d" (NULL) );
+
+        memcpy(instr, movaps_from_mem, 15);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D 0;
+        regs.edx    =3D (unsigned long)res;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( rc !=3D X86EMUL_OKAY )
+            goto fail;
+        asm ( "cmpeqps %1, %%xmm7\n\t"
+              "movmskps %%xmm7, %0" : "=3Dr" (rc) : "m" (res[8]) );
+        if ( rc !=3D 0xf )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
     for ( j =3D 1; j <=3D 2; j++ )
     {
 #if defined(__i386__)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -176,7 +176,7 @@ static uint8_t twobyte_table[256] =3D {
     /* 0x08 - 0x0F */
     ImplicitOps, ImplicitOps, 0, 0, 0, ImplicitOps|ModRM, 0, 0,
     /* 0x10 - 0x17 */
-    0, 0, 0, 0, 0, 0, 0, 0,
+    ImplicitOps|ModRM, ImplicitOps|ModRM, 0, 0, 0, 0, 0, 0,
     /* 0x18 - 0x1F */
     ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|M=
odRM,
     ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|M=
odRM,
@@ -184,7 +184,7 @@ static uint8_t twobyte_table[256] =3D {
     ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|M=
odRM,
     0, 0, 0, 0,
     /* 0x28 - 0x2F */
-    0, 0, 0, 0, 0, 0, 0, 0,
+    ImplicitOps|ModRM, ImplicitOps|ModRM, 0, ImplicitOps|ModRM, 0, 0, 0, =
0,
     /* 0x30 - 0x37 */
     ImplicitOps, ImplicitOps, ImplicitOps, 0,
     ImplicitOps, ImplicitOps, 0, 0,
@@ -273,6 +273,16 @@ enum vex_pfx {
     vex_f2
 };
=20
+#define VEX_PREFIX_DOUBLE_MASK 0x1
+#define VEX_PREFIX_SCALAR_MASK 0x2
+
+static const uint8_t sse_prefix[] =3D { 0x66, 0xf3, 0xf2 };
+
+#define SET_SSE_PREFIX(dst, vex_pfx) do { \
+    if ( vex_pfx ) \
+        (dst) =3D sse_prefix[(vex_pfx) - 1]; \
+} while (0)
+
 union vex {
     uint8_t raw[2];
     struct {
@@ -3850,6 +3860,76 @@ x86_emulate(
     case 0x19 ... 0x1f: /* nop (amd-defined) */
         break;
=20
+    case 0x2b: /* {,v}movntp{s,d} xmm,m128 */
+               /* vmovntp{s,d} ymm,m256 */
+        fail_if(ea.type !=3D OP_MEM);
+        /* fall through */
+    case 0x28: /* {,v}movap{s,d} xmm/m128,xmm */
+               /* vmovap{s,d} ymm/m256,ymm */
+    case 0x29: /* {,v}movap{s,d} xmm,xmm/m128 */
+               /* vmovap{s,d} ymm,ymm/m256 */
+        fail_if(vex.pfx & VEX_PREFIX_SCALAR_MASK);
+        /* fall through */
+    case 0x10: /* {,v}movup{s,d} xmm/m128,xmm */
+               /* vmovup{s,d} ymm/m256,ymm */
+               /* {,v}movss xmm/m32,xmm */
+               /* {,v}movsd xmm/m64,xmm */
+    case 0x11: /* {,v}movup{s,d} xmm,xmm/m128 */
+               /* vmovup{s,d} ymm,ymm/m256 */
+               /* {,v}movss xmm,xmm/m32 */
+               /* {,v}movsd xmm,xmm/m64 */
+    {
+        uint8_t stub[] =3D { 0x3e, 0x3e, 0x0f, b, modrm, 0xc3 };
+        struct fpu_insn_ctxt fic =3D { .insn_bytes =3D sizeof(stub)-1 };
+
+        if ( vex.opcx =3D=3D vex_none )
+        {
+            if ( vex.pfx & VEX_PREFIX_DOUBLE_MASK )
+                vcpu_must_have_sse2();
+            else
+                vcpu_must_have_sse();
+            ea.bytes =3D 16;
+            SET_SSE_PREFIX(stub[0], vex.pfx);
+            get_fpu(X86EMUL_FPU_xmm, &fic);
+        }
+        else
+        {
+            fail_if((vex.opcx !=3D vex_0f) ||
+                    (vex.reg && ((ea.type =3D=3D OP_MEM) ||
+                                 !(vex.pfx & VEX_PREFIX_SCALAR_MASK))));
+            vcpu_must_have_avx();
+            get_fpu(X86EMUL_FPU_ymm, &fic);
+            ea.bytes =3D 16 << vex.l;
+        }
+        if ( vex.pfx & VEX_PREFIX_SCALAR_MASK )
+            ea.bytes =3D vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4;
+        if ( ea.type =3D=3D OP_MEM )
+        {
+            /* XXX enable once there is ops->ea() or equivalent
+            generate_exception_if((b >=3D 0x28) &&
+                                  (ops->ea(ea.mem.seg, ea.mem.off)
+                                   & (ea.bytes - 1)), EXC_GP, 0); */
+            if ( !(b & 1) )
+                rc =3D ops->read(ea.mem.seg, ea.mem.off+0, mmvalp,
+                               ea.bytes, ctxt);
+            /* convert memory operand to (%rAX) */
+            rex_prefix &=3D ~REX_B;
+            vex.b =3D 1;
+            stub[4] &=3D 0x38;
+        }
+        if ( !rc )
+        {
+           copy_REX_VEX(stub, rex_prefix, vex);
+           asm volatile ( "call *%0" : : "r" (stub), "a" (mmvalp)
+                                     : "memory" );
+        }
+        put_fpu(&fic);
+        if ( !rc && (b & 1) && (ea.type =3D=3D OP_MEM) )
+            rc =3D ops->write(ea.mem.seg, ea.mem.off, mmvalp,
+                            ea.bytes, ctxt);
+        goto done;
+    }
+
     case 0x20: /* mov cr,reg */
     case 0x21: /* mov dr,reg */
     case 0x22: /* mov reg,cr */



--=__PartC5EA5061.0__=
Content-Type: text/plain; name="x86-emul-xmm-mov.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-emul-xmm-mov.patch"

x86/emulator: add emulation of SIMD FP moves=0A=0AClone the existing movq =
emulation to also support the most fundamental=0ASIMD FP moves.=0A=0AExtend=
 the testing code to also exercise these instructions.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/tools/tests/x86_emulator/test_x8=
6_emulator.c=0A+++ b/tools/tests/x86_emulator/test_x86_emulator.c=0A@@ =
-629,6 +629,60 @@ int main(int argc, char **argv)=0A     else=0A         =
printf("skipped\n");=0A =0A+    printf("%-40s", "Testing movsd %xmm5,(%ecx)=
...");=0A+    memset(res, 0x77, 64);=0A+    memset(res + 10, 0x66, 8);=0A+ =
   if ( stack_exec && cpu_has_sse2 )=0A+    {=0A+        extern const =
unsigned char movsd_to_mem[];=0A+=0A+        asm volatile ( "movlpd %0, =
%%xmm5\n\t"=0A+                       "movhpd %0, %%xmm5\n"=0A+            =
           ".pushsection .test, \"a\", @progbits\n"=0A+                    =
   "movsd_to_mem: movsd %%xmm5, (%1)\n"=0A+                       =
".popsection" :: "m" (res[10]), "c" (NULL) );=0A+=0A+        memcpy(instr, =
movsd_to_mem, 15);=0A+        regs.eip    =3D (unsigned long)&instr[0];=0A+=
        regs.ecx    =3D (unsigned long)(res + 2);=0A+        regs.edx    =
=3D 0;=0A+        rc =3D x86_emulate(&ctxt, &emulops);=0A+        if ( (rc =
!=3D X86EMUL_OKAY) || memcmp(res, res + 8, 32) )=0A+            goto =
fail;=0A+        printf("okay\n");=0A+    }=0A+    else=0A+    {=0A+       =
 printf("skipped\n");=0A+        memset(res + 2, 0x66, 8);=0A+    =
}=0A+=0A+    printf("%-40s", "Testing movaps (%edx),%xmm7...");=0A+    if =
( stack_exec && cpu_has_sse )=0A+    {=0A+        extern const unsigned =
char movaps_from_mem[];=0A+=0A+        asm volatile ( "xorps %%xmm7, =
%%xmm7\n"=0A+                       ".pushsection .test, \"a\", @progbits\n=
"=0A+                       "movaps_from_mem: movaps (%0), %%xmm7\n"=0A+   =
                    ".popsection" :: "d" (NULL) );=0A+=0A+        =
memcpy(instr, movaps_from_mem, 15);=0A+        regs.eip    =3D (unsigned =
long)&instr[0];=0A+        regs.ecx    =3D 0;=0A+        regs.edx    =3D =
(unsigned long)res;=0A+        rc =3D x86_emulate(&ctxt, &emulops);=0A+    =
    if ( rc !=3D X86EMUL_OKAY )=0A+            goto fail;=0A+        asm ( =
"cmpeqps %1, %%xmm7\n\t"=0A+              "movmskps %%xmm7, %0" : "=3Dr" =
(rc) : "m" (res[8]) );=0A+        if ( rc !=3D 0xf )=0A+            goto =
fail;=0A+        printf("okay\n");=0A+    }=0A+    else=0A+        =
printf("skipped\n");=0A+=0A     for ( j =3D 1; j <=3D 2; j++ )=0A     {=0A =
#if defined(__i386__)=0A--- a/xen/arch/x86/x86_emulate/x86_emulate.c=0A+++ =
b/xen/arch/x86/x86_emulate/x86_emulate.c=0A@@ -176,7 +176,7 @@ static =
uint8_t twobyte_table[256] =3D {=0A     /* 0x08 - 0x0F */=0A     ImplicitOp=
s, ImplicitOps, 0, 0, 0, ImplicitOps|ModRM, 0, 0,=0A     /* 0x10 - 0x17 =
*/=0A-    0, 0, 0, 0, 0, 0, 0, 0,=0A+    ImplicitOps|ModRM, ImplicitOps|Mod=
RM, 0, 0, 0, 0, 0, 0,=0A     /* 0x18 - 0x1F */=0A     ImplicitOps|ModRM, =
ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,=0A     ImplicitOps=
|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,=0A@@ =
-184,7 +184,7 @@ static uint8_t twobyte_table[256] =3D {=0A     ImplicitOps=
|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,=0A     0, =
0, 0, 0,=0A     /* 0x28 - 0x2F */=0A-    0, 0, 0, 0, 0, 0, 0, 0,=0A+    =
ImplicitOps|ModRM, ImplicitOps|ModRM, 0, ImplicitOps|ModRM, 0, 0, 0, 0,=0A =
    /* 0x30 - 0x37 */=0A     ImplicitOps, ImplicitOps, ImplicitOps, 0,=0A  =
   ImplicitOps, ImplicitOps, 0, 0,=0A@@ -273,6 +273,16 @@ enum vex_pfx =
{=0A     vex_f2=0A };=0A =0A+#define VEX_PREFIX_DOUBLE_MASK 0x1=0A+#define =
VEX_PREFIX_SCALAR_MASK 0x2=0A+=0A+static const uint8_t sse_prefix[] =3D { =
0x66, 0xf3, 0xf2 };=0A+=0A+#define SET_SSE_PREFIX(dst, vex_pfx) do { \=0A+ =
   if ( vex_pfx ) \=0A+        (dst) =3D sse_prefix[(vex_pfx) - 1]; \=0A+} =
while (0)=0A+=0A union vex {=0A     uint8_t raw[2];=0A     struct {=0A@@ =
-3850,6 +3860,76 @@ x86_emulate(=0A     case 0x19 ... 0x1f: /* nop =
(amd-defined) */=0A         break;=0A =0A+    case 0x2b: /* {,v}movntp{s,d}=
 xmm,m128 */=0A+               /* vmovntp{s,d} ymm,m256 */=0A+        =
fail_if(ea.type !=3D OP_MEM);=0A+        /* fall through */=0A+    case =
0x28: /* {,v}movap{s,d} xmm/m128,xmm */=0A+               /* vmovap{s,d} =
ymm/m256,ymm */=0A+    case 0x29: /* {,v}movap{s,d} xmm,xmm/m128 */=0A+    =
           /* vmovap{s,d} ymm,ymm/m256 */=0A+        fail_if(vex.pfx & =
VEX_PREFIX_SCALAR_MASK);=0A+        /* fall through */=0A+    case 0x10: =
/* {,v}movup{s,d} xmm/m128,xmm */=0A+               /* vmovup{s,d} =
ymm/m256,ymm */=0A+               /* {,v}movss xmm/m32,xmm */=0A+          =
     /* {,v}movsd xmm/m64,xmm */=0A+    case 0x11: /* {,v}movup{s,d} =
xmm,xmm/m128 */=0A+               /* vmovup{s,d} ymm,ymm/m256 */=0A+       =
        /* {,v}movss xmm,xmm/m32 */=0A+               /* {,v}movsd =
xmm,xmm/m64 */=0A+    {=0A+        uint8_t stub[] =3D { 0x3e, 0x3e, 0x0f, =
b, modrm, 0xc3 };=0A+        struct fpu_insn_ctxt fic =3D { .insn_bytes =
=3D sizeof(stub)-1 };=0A+=0A+        if ( vex.opcx =3D=3D vex_none )=0A+   =
     {=0A+            if ( vex.pfx & VEX_PREFIX_DOUBLE_MASK )=0A+          =
      vcpu_must_have_sse2();=0A+            else=0A+                =
vcpu_must_have_sse();=0A+            ea.bytes =3D 16;=0A+            =
SET_SSE_PREFIX(stub[0], vex.pfx);=0A+            get_fpu(X86EMUL_FPU_xmm, =
&fic);=0A+        }=0A+        else=0A+        {=0A+            fail_if((ve=
x.opcx !=3D vex_0f) ||=0A+                    (vex.reg && ((ea.type =3D=3D =
OP_MEM) ||=0A+                                 !(vex.pfx & VEX_PREFIX_SCALA=
R_MASK))));=0A+            vcpu_must_have_avx();=0A+            get_fpu(X86=
EMUL_FPU_ymm, &fic);=0A+            ea.bytes =3D 16 << vex.l;=0A+        =
}=0A+        if ( vex.pfx & VEX_PREFIX_SCALAR_MASK )=0A+            =
ea.bytes =3D vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4;=0A+        if ( =
ea.type =3D=3D OP_MEM )=0A+        {=0A+            /* XXX enable once =
there is ops->ea() or equivalent=0A+            generate_exception_if((b =
>=3D 0x28) &&=0A+                                  (ops->ea(ea.mem.seg, =
ea.mem.off)=0A+                                   & (ea.bytes - 1)), =
EXC_GP, 0); */=0A+            if ( !(b & 1) )=0A+                rc =3D =
ops->read(ea.mem.seg, ea.mem.off+0, mmvalp,=0A+                            =
   ea.bytes, ctxt);=0A+            /* convert memory operand to (%rAX) =
*/=0A+            rex_prefix &=3D ~REX_B;=0A+            vex.b =3D 1;=0A+  =
          stub[4] &=3D 0x38;=0A+        }=0A+        if ( !rc )=0A+        =
{=0A+           copy_REX_VEX(stub, rex_prefix, vex);=0A+           asm =
volatile ( "call *%0" : : "r" (stub), "a" (mmvalp)=0A+                     =
                : "memory" );=0A+        }=0A+        put_fpu(&fic);=0A+   =
     if ( !rc && (b & 1) && (ea.type =3D=3D OP_MEM) )=0A+            rc =
=3D ops->write(ea.mem.seg, ea.mem.off, mmvalp,=0A+                         =
   ea.bytes, ctxt);=0A+        goto done;=0A+    }=0A+=0A     case 0x20: =
/* mov cr,reg */=0A     case 0x21: /* mov dr,reg */=0A     case 0x22: /* =
mov reg,cr */=0A
--=__PartC5EA5061.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartC5EA5061.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:07:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmgN-0004JA-Im; Wed, 30 Nov 2011 16:06:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmgL-0004IN-Qu
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:06:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1322669170!5619042!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1308 invoked from network); 30 Nov 2011 16:06:11 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:06:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:06:10 +0000
Message-Id: <4ED662810200007800064677@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:06:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC5EA5061.0__="
Subject: [Xen-devel] [PATCH 2/4] x86/emulator: add emulation of SIMD FP moves
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartC5EA5061.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Clone the existing movq emulation to also support the most fundamental
SIMD FP moves.

Extend the testing code to also exercise these instructions.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -629,6 +629,60 @@ int main(int argc, char **argv)
     else
         printf("skipped\n");
=20
+    printf("%-40s", "Testing movsd %xmm5,(%ecx)...");
+    memset(res, 0x77, 64);
+    memset(res + 10, 0x66, 8);
+    if ( stack_exec && cpu_has_sse2 )
+    {
+        extern const unsigned char movsd_to_mem[];
+
+        asm volatile ( "movlpd %0, %%xmm5\n\t"
+                       "movhpd %0, %%xmm5\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movsd_to_mem: movsd %%xmm5, (%1)\n"
+                       ".popsection" :: "m" (res[10]), "c" (NULL) );
+
+        memcpy(instr, movsd_to_mem, 15);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D (unsigned long)(res + 2);
+        regs.edx    =3D 0;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( (rc !=3D X86EMUL_OKAY) || memcmp(res, res + 8, 32) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+    {
+        printf("skipped\n");
+        memset(res + 2, 0x66, 8);
+    }
+
+    printf("%-40s", "Testing movaps (%edx),%xmm7...");
+    if ( stack_exec && cpu_has_sse )
+    {
+        extern const unsigned char movaps_from_mem[];
+
+        asm volatile ( "xorps %%xmm7, %%xmm7\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movaps_from_mem: movaps (%0), %%xmm7\n"
+                       ".popsection" :: "d" (NULL) );
+
+        memcpy(instr, movaps_from_mem, 15);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D 0;
+        regs.edx    =3D (unsigned long)res;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( rc !=3D X86EMUL_OKAY )
+            goto fail;
+        asm ( "cmpeqps %1, %%xmm7\n\t"
+              "movmskps %%xmm7, %0" : "=3Dr" (rc) : "m" (res[8]) );
+        if ( rc !=3D 0xf )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
     for ( j =3D 1; j <=3D 2; j++ )
     {
 #if defined(__i386__)
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -176,7 +176,7 @@ static uint8_t twobyte_table[256] =3D {
     /* 0x08 - 0x0F */
     ImplicitOps, ImplicitOps, 0, 0, 0, ImplicitOps|ModRM, 0, 0,
     /* 0x10 - 0x17 */
-    0, 0, 0, 0, 0, 0, 0, 0,
+    ImplicitOps|ModRM, ImplicitOps|ModRM, 0, 0, 0, 0, 0, 0,
     /* 0x18 - 0x1F */
     ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|M=
odRM,
     ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|M=
odRM,
@@ -184,7 +184,7 @@ static uint8_t twobyte_table[256] =3D {
     ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|M=
odRM,
     0, 0, 0, 0,
     /* 0x28 - 0x2F */
-    0, 0, 0, 0, 0, 0, 0, 0,
+    ImplicitOps|ModRM, ImplicitOps|ModRM, 0, ImplicitOps|ModRM, 0, 0, 0, =
0,
     /* 0x30 - 0x37 */
     ImplicitOps, ImplicitOps, ImplicitOps, 0,
     ImplicitOps, ImplicitOps, 0, 0,
@@ -273,6 +273,16 @@ enum vex_pfx {
     vex_f2
 };
=20
+#define VEX_PREFIX_DOUBLE_MASK 0x1
+#define VEX_PREFIX_SCALAR_MASK 0x2
+
+static const uint8_t sse_prefix[] =3D { 0x66, 0xf3, 0xf2 };
+
+#define SET_SSE_PREFIX(dst, vex_pfx) do { \
+    if ( vex_pfx ) \
+        (dst) =3D sse_prefix[(vex_pfx) - 1]; \
+} while (0)
+
 union vex {
     uint8_t raw[2];
     struct {
@@ -3850,6 +3860,76 @@ x86_emulate(
     case 0x19 ... 0x1f: /* nop (amd-defined) */
         break;
=20
+    case 0x2b: /* {,v}movntp{s,d} xmm,m128 */
+               /* vmovntp{s,d} ymm,m256 */
+        fail_if(ea.type !=3D OP_MEM);
+        /* fall through */
+    case 0x28: /* {,v}movap{s,d} xmm/m128,xmm */
+               /* vmovap{s,d} ymm/m256,ymm */
+    case 0x29: /* {,v}movap{s,d} xmm,xmm/m128 */
+               /* vmovap{s,d} ymm,ymm/m256 */
+        fail_if(vex.pfx & VEX_PREFIX_SCALAR_MASK);
+        /* fall through */
+    case 0x10: /* {,v}movup{s,d} xmm/m128,xmm */
+               /* vmovup{s,d} ymm/m256,ymm */
+               /* {,v}movss xmm/m32,xmm */
+               /* {,v}movsd xmm/m64,xmm */
+    case 0x11: /* {,v}movup{s,d} xmm,xmm/m128 */
+               /* vmovup{s,d} ymm,ymm/m256 */
+               /* {,v}movss xmm,xmm/m32 */
+               /* {,v}movsd xmm,xmm/m64 */
+    {
+        uint8_t stub[] =3D { 0x3e, 0x3e, 0x0f, b, modrm, 0xc3 };
+        struct fpu_insn_ctxt fic =3D { .insn_bytes =3D sizeof(stub)-1 };
+
+        if ( vex.opcx =3D=3D vex_none )
+        {
+            if ( vex.pfx & VEX_PREFIX_DOUBLE_MASK )
+                vcpu_must_have_sse2();
+            else
+                vcpu_must_have_sse();
+            ea.bytes =3D 16;
+            SET_SSE_PREFIX(stub[0], vex.pfx);
+            get_fpu(X86EMUL_FPU_xmm, &fic);
+        }
+        else
+        {
+            fail_if((vex.opcx !=3D vex_0f) ||
+                    (vex.reg && ((ea.type =3D=3D OP_MEM) ||
+                                 !(vex.pfx & VEX_PREFIX_SCALAR_MASK))));
+            vcpu_must_have_avx();
+            get_fpu(X86EMUL_FPU_ymm, &fic);
+            ea.bytes =3D 16 << vex.l;
+        }
+        if ( vex.pfx & VEX_PREFIX_SCALAR_MASK )
+            ea.bytes =3D vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4;
+        if ( ea.type =3D=3D OP_MEM )
+        {
+            /* XXX enable once there is ops->ea() or equivalent
+            generate_exception_if((b >=3D 0x28) &&
+                                  (ops->ea(ea.mem.seg, ea.mem.off)
+                                   & (ea.bytes - 1)), EXC_GP, 0); */
+            if ( !(b & 1) )
+                rc =3D ops->read(ea.mem.seg, ea.mem.off+0, mmvalp,
+                               ea.bytes, ctxt);
+            /* convert memory operand to (%rAX) */
+            rex_prefix &=3D ~REX_B;
+            vex.b =3D 1;
+            stub[4] &=3D 0x38;
+        }
+        if ( !rc )
+        {
+           copy_REX_VEX(stub, rex_prefix, vex);
+           asm volatile ( "call *%0" : : "r" (stub), "a" (mmvalp)
+                                     : "memory" );
+        }
+        put_fpu(&fic);
+        if ( !rc && (b & 1) && (ea.type =3D=3D OP_MEM) )
+            rc =3D ops->write(ea.mem.seg, ea.mem.off, mmvalp,
+                            ea.bytes, ctxt);
+        goto done;
+    }
+
     case 0x20: /* mov cr,reg */
     case 0x21: /* mov dr,reg */
     case 0x22: /* mov reg,cr */



--=__PartC5EA5061.0__=
Content-Type: text/plain; name="x86-emul-xmm-mov.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-emul-xmm-mov.patch"

x86/emulator: add emulation of SIMD FP moves=0A=0AClone the existing movq =
emulation to also support the most fundamental=0ASIMD FP moves.=0A=0AExtend=
 the testing code to also exercise these instructions.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/tools/tests/x86_emulator/test_x8=
6_emulator.c=0A+++ b/tools/tests/x86_emulator/test_x86_emulator.c=0A@@ =
-629,6 +629,60 @@ int main(int argc, char **argv)=0A     else=0A         =
printf("skipped\n");=0A =0A+    printf("%-40s", "Testing movsd %xmm5,(%ecx)=
...");=0A+    memset(res, 0x77, 64);=0A+    memset(res + 10, 0x66, 8);=0A+ =
   if ( stack_exec && cpu_has_sse2 )=0A+    {=0A+        extern const =
unsigned char movsd_to_mem[];=0A+=0A+        asm volatile ( "movlpd %0, =
%%xmm5\n\t"=0A+                       "movhpd %0, %%xmm5\n"=0A+            =
           ".pushsection .test, \"a\", @progbits\n"=0A+                    =
   "movsd_to_mem: movsd %%xmm5, (%1)\n"=0A+                       =
".popsection" :: "m" (res[10]), "c" (NULL) );=0A+=0A+        memcpy(instr, =
movsd_to_mem, 15);=0A+        regs.eip    =3D (unsigned long)&instr[0];=0A+=
        regs.ecx    =3D (unsigned long)(res + 2);=0A+        regs.edx    =
=3D 0;=0A+        rc =3D x86_emulate(&ctxt, &emulops);=0A+        if ( (rc =
!=3D X86EMUL_OKAY) || memcmp(res, res + 8, 32) )=0A+            goto =
fail;=0A+        printf("okay\n");=0A+    }=0A+    else=0A+    {=0A+       =
 printf("skipped\n");=0A+        memset(res + 2, 0x66, 8);=0A+    =
}=0A+=0A+    printf("%-40s", "Testing movaps (%edx),%xmm7...");=0A+    if =
( stack_exec && cpu_has_sse )=0A+    {=0A+        extern const unsigned =
char movaps_from_mem[];=0A+=0A+        asm volatile ( "xorps %%xmm7, =
%%xmm7\n"=0A+                       ".pushsection .test, \"a\", @progbits\n=
"=0A+                       "movaps_from_mem: movaps (%0), %%xmm7\n"=0A+   =
                    ".popsection" :: "d" (NULL) );=0A+=0A+        =
memcpy(instr, movaps_from_mem, 15);=0A+        regs.eip    =3D (unsigned =
long)&instr[0];=0A+        regs.ecx    =3D 0;=0A+        regs.edx    =3D =
(unsigned long)res;=0A+        rc =3D x86_emulate(&ctxt, &emulops);=0A+    =
    if ( rc !=3D X86EMUL_OKAY )=0A+            goto fail;=0A+        asm ( =
"cmpeqps %1, %%xmm7\n\t"=0A+              "movmskps %%xmm7, %0" : "=3Dr" =
(rc) : "m" (res[8]) );=0A+        if ( rc !=3D 0xf )=0A+            goto =
fail;=0A+        printf("okay\n");=0A+    }=0A+    else=0A+        =
printf("skipped\n");=0A+=0A     for ( j =3D 1; j <=3D 2; j++ )=0A     {=0A =
#if defined(__i386__)=0A--- a/xen/arch/x86/x86_emulate/x86_emulate.c=0A+++ =
b/xen/arch/x86/x86_emulate/x86_emulate.c=0A@@ -176,7 +176,7 @@ static =
uint8_t twobyte_table[256] =3D {=0A     /* 0x08 - 0x0F */=0A     ImplicitOp=
s, ImplicitOps, 0, 0, 0, ImplicitOps|ModRM, 0, 0,=0A     /* 0x10 - 0x17 =
*/=0A-    0, 0, 0, 0, 0, 0, 0, 0,=0A+    ImplicitOps|ModRM, ImplicitOps|Mod=
RM, 0, 0, 0, 0, 0, 0,=0A     /* 0x18 - 0x1F */=0A     ImplicitOps|ModRM, =
ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,=0A     ImplicitOps=
|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,=0A@@ =
-184,7 +184,7 @@ static uint8_t twobyte_table[256] =3D {=0A     ImplicitOps=
|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM,=0A     0, =
0, 0, 0,=0A     /* 0x28 - 0x2F */=0A-    0, 0, 0, 0, 0, 0, 0, 0,=0A+    =
ImplicitOps|ModRM, ImplicitOps|ModRM, 0, ImplicitOps|ModRM, 0, 0, 0, 0,=0A =
    /* 0x30 - 0x37 */=0A     ImplicitOps, ImplicitOps, ImplicitOps, 0,=0A  =
   ImplicitOps, ImplicitOps, 0, 0,=0A@@ -273,6 +273,16 @@ enum vex_pfx =
{=0A     vex_f2=0A };=0A =0A+#define VEX_PREFIX_DOUBLE_MASK 0x1=0A+#define =
VEX_PREFIX_SCALAR_MASK 0x2=0A+=0A+static const uint8_t sse_prefix[] =3D { =
0x66, 0xf3, 0xf2 };=0A+=0A+#define SET_SSE_PREFIX(dst, vex_pfx) do { \=0A+ =
   if ( vex_pfx ) \=0A+        (dst) =3D sse_prefix[(vex_pfx) - 1]; \=0A+} =
while (0)=0A+=0A union vex {=0A     uint8_t raw[2];=0A     struct {=0A@@ =
-3850,6 +3860,76 @@ x86_emulate(=0A     case 0x19 ... 0x1f: /* nop =
(amd-defined) */=0A         break;=0A =0A+    case 0x2b: /* {,v}movntp{s,d}=
 xmm,m128 */=0A+               /* vmovntp{s,d} ymm,m256 */=0A+        =
fail_if(ea.type !=3D OP_MEM);=0A+        /* fall through */=0A+    case =
0x28: /* {,v}movap{s,d} xmm/m128,xmm */=0A+               /* vmovap{s,d} =
ymm/m256,ymm */=0A+    case 0x29: /* {,v}movap{s,d} xmm,xmm/m128 */=0A+    =
           /* vmovap{s,d} ymm,ymm/m256 */=0A+        fail_if(vex.pfx & =
VEX_PREFIX_SCALAR_MASK);=0A+        /* fall through */=0A+    case 0x10: =
/* {,v}movup{s,d} xmm/m128,xmm */=0A+               /* vmovup{s,d} =
ymm/m256,ymm */=0A+               /* {,v}movss xmm/m32,xmm */=0A+          =
     /* {,v}movsd xmm/m64,xmm */=0A+    case 0x11: /* {,v}movup{s,d} =
xmm,xmm/m128 */=0A+               /* vmovup{s,d} ymm,ymm/m256 */=0A+       =
        /* {,v}movss xmm,xmm/m32 */=0A+               /* {,v}movsd =
xmm,xmm/m64 */=0A+    {=0A+        uint8_t stub[] =3D { 0x3e, 0x3e, 0x0f, =
b, modrm, 0xc3 };=0A+        struct fpu_insn_ctxt fic =3D { .insn_bytes =
=3D sizeof(stub)-1 };=0A+=0A+        if ( vex.opcx =3D=3D vex_none )=0A+   =
     {=0A+            if ( vex.pfx & VEX_PREFIX_DOUBLE_MASK )=0A+          =
      vcpu_must_have_sse2();=0A+            else=0A+                =
vcpu_must_have_sse();=0A+            ea.bytes =3D 16;=0A+            =
SET_SSE_PREFIX(stub[0], vex.pfx);=0A+            get_fpu(X86EMUL_FPU_xmm, =
&fic);=0A+        }=0A+        else=0A+        {=0A+            fail_if((ve=
x.opcx !=3D vex_0f) ||=0A+                    (vex.reg && ((ea.type =3D=3D =
OP_MEM) ||=0A+                                 !(vex.pfx & VEX_PREFIX_SCALA=
R_MASK))));=0A+            vcpu_must_have_avx();=0A+            get_fpu(X86=
EMUL_FPU_ymm, &fic);=0A+            ea.bytes =3D 16 << vex.l;=0A+        =
}=0A+        if ( vex.pfx & VEX_PREFIX_SCALAR_MASK )=0A+            =
ea.bytes =3D vex.pfx & VEX_PREFIX_DOUBLE_MASK ? 8 : 4;=0A+        if ( =
ea.type =3D=3D OP_MEM )=0A+        {=0A+            /* XXX enable once =
there is ops->ea() or equivalent=0A+            generate_exception_if((b =
>=3D 0x28) &&=0A+                                  (ops->ea(ea.mem.seg, =
ea.mem.off)=0A+                                   & (ea.bytes - 1)), =
EXC_GP, 0); */=0A+            if ( !(b & 1) )=0A+                rc =3D =
ops->read(ea.mem.seg, ea.mem.off+0, mmvalp,=0A+                            =
   ea.bytes, ctxt);=0A+            /* convert memory operand to (%rAX) =
*/=0A+            rex_prefix &=3D ~REX_B;=0A+            vex.b =3D 1;=0A+  =
          stub[4] &=3D 0x38;=0A+        }=0A+        if ( !rc )=0A+        =
{=0A+           copy_REX_VEX(stub, rex_prefix, vex);=0A+           asm =
volatile ( "call *%0" : : "r" (stub), "a" (mmvalp)=0A+                     =
                : "memory" );=0A+        }=0A+        put_fpu(&fic);=0A+   =
     if ( !rc && (b & 1) && (ea.type =3D=3D OP_MEM) )=0A+            rc =
=3D ops->write(ea.mem.seg, ea.mem.off, mmvalp,=0A+                         =
   ea.bytes, ctxt);=0A+        goto done;=0A+    }=0A+=0A     case 0x20: =
/* mov cr,reg */=0A     case 0x21: /* mov dr,reg */=0A     case 0x22: /* =
mov reg,cr */=0A
--=__PartC5EA5061.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartC5EA5061.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:07:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmgN-0004It-3B; Wed, 30 Nov 2011 16:06:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmgL-0004IL-5L
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:06:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322669133!5581458!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7855 invoked from network); 30 Nov 2011 16:05:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:05:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:05:33 +0000
Message-Id: <4ED6625B0200007800064673@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:05:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFFD06A5B.0__="
Subject: [Xen-devel] [PATCH 1/4] x86/emulator: generalize movq emulation
 (SSE2 and AVX variants)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartFFD06A5B.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Extend the existing movq emulation to also support its SSE2 and AVX
variants, the latter implying the addition of VEX decoding. Fold the
read and write cases (as most of the logic is identical), and add
movntq and variants (as they're very similar).

Extend the testing code to also exercise these instructions.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1,3 +1,5 @@
+#include <errno.h>
+#include <stdbool.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
@@ -53,11 +55,84 @@ static int cmpxchg(
     return X86EMUL_OKAY;
 }
=20
+static int cpuid(
+    unsigned int *eax,
+    unsigned int *ebx,
+    unsigned int *ecx,
+    unsigned int *edx,
+    struct x86_emulate_ctxt *ctxt)
+{
+    asm ("cpuid" : "+a" (*eax), "+c" (*ecx), "=3Dd" (*edx), "=3Db" =
(*ebx));
+    return X86EMUL_OKAY;
+}
+
+#define cpu_has_mmx ({ \
+    unsigned int eax =3D 1, ecx =3D 0, edx; \
+    cpuid(&eax, &ecx, &ecx, &edx, NULL); \
+    (edx & (1U << 23)) !=3D 0; \
+})
+
+#define cpu_has_sse ({ \
+    unsigned int eax =3D 1, ecx =3D 0, edx; \
+    cpuid(&eax, &ecx, &ecx, &edx, NULL); \
+    (edx & (1U << 25)) !=3D 0; \
+})
+
+#define cpu_has_sse2 ({ \
+    unsigned int eax =3D 1, ecx =3D 0, edx; \
+    cpuid(&eax, &ecx, &ecx, &edx, NULL); \
+    (edx & (1U << 26)) !=3D 0; \
+})
+
+static inline uint64_t xgetbv(uint32_t xcr)
+{
+    uint64_t res;
+
+    asm ( ".byte 0x0f, 0x01, 0xd0" : "=3DA" (res) : "c" (xcr) );
+
+    return res;
+}
+
+#define cpu_has_avx ({ \
+    unsigned int eax =3D 1, ecx =3D 0, edx; \
+    cpuid(&eax, &edx, &ecx, &edx, NULL); \
+    if ( !(ecx & (1U << 27)) || ((xgetbv(0) & 6) !=3D 6) ) \
+        ecx =3D 0; \
+    (ecx & (1U << 28)) !=3D 0; \
+})
+
+int get_fpu(
+    void (*exception_callback)(void *, struct cpu_user_regs *),
+    void *exception_callback_arg,
+    enum x86_emulate_fpu_type type,
+    struct x86_emulate_ctxt *ctxt)
+{
+    switch ( type )
+    {
+    case X86EMUL_FPU_fpu:
+        break;
+    case X86EMUL_FPU_ymm:
+        if ( cpu_has_avx )
+            break;
+    case X86EMUL_FPU_xmm:
+        if ( cpu_has_sse )
+            break;
+    case X86EMUL_FPU_mmx:
+        if ( cpu_has_mmx )
+            break;
+    default:
+        return X86EMUL_UNHANDLEABLE;
+    }
+    return X86EMUL_OKAY;
+}
+
 static struct x86_emulate_ops emulops =3D {
     .read       =3D read,
     .insn_fetch =3D read,
     .write      =3D write,
     .cmpxchg    =3D cmpxchg,
+    .cpuid      =3D cpuid,
+    .get_fpu    =3D get_fpu,
 };
=20
 int main(int argc, char **argv)
@@ -66,6 +141,8 @@ int main(int argc, char **argv)
     struct cpu_user_regs regs;
     char *instr;
     unsigned int *res, i, j;
+    unsigned long sp;
+    bool stack_exec;
     int rc;
 #ifndef __x86_64__
     unsigned int bcdres_native, bcdres_emul;
@@ -85,6 +162,16 @@ int main(int argc, char **argv)
     }
     instr =3D (char *)res + 0x100;
=20
+#ifdef __x86_64__
+    asm ("movq %%rsp, %0" : "=3Dg" (sp));
+#else
+    asm ("movl %%esp, %0" : "=3Dg" (sp));
+#endif
+    stack_exec =3D mprotect((void *)(sp & -0x1000L) - (MMAP_SZ - 0x1000),
+                          MMAP_SZ, PROT_READ|PROT_WRITE|PROT_EXEC) =3D=3D =
0;
+    if ( !stack_exec )
+        printf("Warning: Stack could not be made executable (%d).\n", =
errno);
+
     printf("%-40s", "Testing addl %%ecx,(%%eax)...");
     instr[0] =3D 0x01; instr[1] =3D 0x08;
     regs.eflags =3D 0x200;
@@ -442,6 +529,106 @@ int main(int argc, char **argv)
     printf("skipped\n");
 #endif
=20
+    printf("%-40s", "Testing movq %mm3,(%ecx)...");
+    if ( stack_exec && cpu_has_mmx )
+    {
+        extern const unsigned char movq_to_mem[];
+
+        asm volatile ( "pcmpeqb %%mm3, %%mm3\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movq_to_mem: movq %%mm3, (%0)\n"
+                       ".popsection" :: "c" (NULL) );
+
+        memcpy(instr, movq_to_mem, 15);
+        memset(res, 0x33, 64);
+        memset(res + 8, 0xff, 8);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D (unsigned long)res;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( (rc !=3D X86EMUL_OKAY) || memcmp(res, res + 8, 32) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing movq (%edx),%mm5...");
+    if ( stack_exec && cpu_has_mmx )
+    {
+        extern const unsigned char movq_from_mem[];
+
+        asm volatile ( "pcmpgtb %%mm5, %%mm5\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movq_from_mem: movq (%0), %%mm5\n"
+                       ".popsection" :: "d" (NULL) );
+
+        memcpy(instr, movq_from_mem, 15);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D 0;
+        regs.edx    =3D (unsigned long)res;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( rc !=3D X86EMUL_OKAY )
+            goto fail;
+        asm ( "pcmpeqb %%mm3, %%mm3\n\t"
+              "pcmpeqb %%mm5, %%mm3\n\t"
+              "pmovmskb %%mm3, %0" : "=3Dr" (rc) );
+        if ( rc !=3D 0xff )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing movdqu %xmm2,(%ecx)...");
+    if ( stack_exec && cpu_has_sse2 )
+    {
+        extern const unsigned char movdqu_to_mem[];
+
+        asm volatile ( "pcmpeqb %%xmm2, %%xmm2\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movdqu_to_mem: movdqu %%xmm2, (%0)\n"
+                       ".popsection" :: "c" (NULL) );
+
+        memcpy(instr, movdqu_to_mem, 15);
+        memset(res, 0x55, 64);
+        memset(res + 8, 0xff, 16);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D (unsigned long)res;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( (rc !=3D X86EMUL_OKAY) || memcmp(res, res + 8, 32) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing movdqu (%edx),%xmm4...");
+    if ( stack_exec && cpu_has_sse2 )
+    {
+        extern const unsigned char movdqu_from_mem[];
+
+        asm volatile ( "pcmpgtb %%xmm4, %%xmm4\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movdqu_from_mem: movdqu (%0), %%xmm4\n"
+                       ".popsection" :: "d" (NULL) );
+
+        memcpy(instr, movdqu_from_mem, 15);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D 0;
+        regs.edx    =3D (unsigned long)res;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( rc !=3D X86EMUL_OKAY )
+            goto fail;
+        asm ( "pcmpeqb %%xmm2, %%xmm2\n\t"
+              "pcmpeqb %%xmm4, %%xmm2\n\t"
+              "pmovmskb %%xmm2, %0" : "=3Dr" (rc) );
+        if ( rc !=3D 0xffff )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
     for ( j =3D 1; j <=3D 2; j++ )
     {
 #if defined(__i386__)
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -16,6 +16,7 @@
 #include <xen/paging.h>
 #include <xen/trace.h>
 #include <asm/event.h>
+#include <asm/xstate.h>
 #include <asm/hvm/emulate.h>
 #include <asm/hvm/hvm.h>
 #include <asm/hvm/trace.h>
@@ -928,6 +929,20 @@ static int hvmemul_get_fpu(
         if ( !cpu_has_mmx )
             return X86EMUL_UNHANDLEABLE;
         break;
+    case X86EMUL_FPU_xmm:
+        if ( !cpu_has_xmm ||
+             (curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_EM) ||
+             !(curr->arch.hvm_vcpu.guest_cr[4] & X86_CR4_OSFXSR) )
+            return X86EMUL_UNHANDLEABLE;
+        break;
+    case X86EMUL_FPU_ymm:
+        if ( !(curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) ||
+             vm86_mode(ctxt->regs) ||
+             !(curr->arch.hvm_vcpu.guest_cr[4] & X86_CR4_OSXSAVE) ||
+             !(curr->arch.xcr0 & XSTATE_SSE) ||
+             !(curr->arch.xcr0 & XSTATE_YMM) )
+            return X86EMUL_UNHANDLEABLE;
+        break;
     default:
         return X86EMUL_UNHANDLEABLE;
     }
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -248,11 +248,52 @@ static uint8_t twobyte_table[256] =3D {
     /* 0xD0 - 0xDF */
     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
     /* 0xE0 - 0xEF */
-    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+    0, 0, 0, 0, 0, 0, 0, ImplicitOps|ModRM, 0, 0, 0, 0, 0, 0, 0, 0,
     /* 0xF0 - 0xFF */
     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
 };
=20
+#define REX_PREFIX 0x40
+#define REX_B 0x01
+#define REX_X 0x02
+#define REX_R 0x04
+#define REX_W 0x08
+
+#define vex_none 0
+
+enum vex_opcx {
+    vex_0f =3D vex_none + 1,
+    vex_0f38,
+    vex_0f3a,
+};
+
+enum vex_pfx {
+    vex_66 =3D vex_none + 1,
+    vex_f3,
+    vex_f2
+};
+
+union vex {
+    uint8_t raw[2];
+    struct {
+        uint8_t opcx:5;
+        uint8_t b:1;
+        uint8_t x:1;
+        uint8_t r:1;
+        uint8_t pfx:2;
+        uint8_t l:1;
+        uint8_t reg:4;
+        uint8_t w:1;
+    };
+};
+
+#define copy_REX_VEX(ptr, rex, vex) do { \
+    if ( (vex).opcx !=3D vex_none ) \
+        ptr[0] =3D 0xc4, ptr[1] =3D (vex).raw[0], ptr[2] =3D (vex).raw[1];=
 \
+    else if ( mode_64bit() ) \
+        ptr[1] =3D rex | REX_PREFIX; \
+} while (0)
+
 /* Type, address-of, and value of an instruction's operand. */
 struct operand {
     enum { OP_REG, OP_MEM, OP_IMM, OP_NONE } type;
@@ -281,6 +322,23 @@ struct operand {
     };
 };
=20
+typedef union {
+    uint64_t mmx;
+    uint64_t __attribute__ ((aligned(16))) xmm[2];
+    uint64_t __attribute__ ((aligned(32))) ymm[4];
+} mmval_t;
+
+/*
+ * While proper alignment gets specified above, this doesn't get honored =
by
+ * the compiler for automatic variables. Use this helper to instantiate a
+ * suitably aligned variable, producing a pointer to access it.
+ */
+#define DECLARE_ALIGNED(type, var)                                   \
+    long __##var[sizeof(type) + __alignof(type) - __alignof(long)];  \
+    type *const var##p =3D                                             \
+        (void *)((long)(__##var + __alignof(type) - __alignof(long)) \
+                 & -__alignof(type))
+
 /* MSRs. */
 #define MSR_TSC          0x00000010
 #define MSR_SYSENTER_CS  0x00000174
@@ -992,9 +1050,12 @@ static bool_t vcpu_has(
=20
 #define vcpu_must_have(leaf, reg, bit) \
     generate_exception_if(!vcpu_has(leaf, reg, bit, ctxt, ops), EXC_UD, =
-1)
+#define vcpu_must_have_mmx()  vcpu_must_have(0x00000001, EDX, 23)
+#define vcpu_must_have_sse()  vcpu_must_have(0x00000001, EDX, 25)
 #define vcpu_must_have_sse2() vcpu_must_have(0x00000001, EDX, 26)
 #define vcpu_must_have_sse3() vcpu_must_have(0x00000001, ECX,  0)
 #define vcpu_must_have_cx16() vcpu_must_have(0x00000001, ECX, 13)
+#define vcpu_must_have_avx()  vcpu_must_have(0x00000001, ECX, 28)
=20
 static int
 in_longmode(
@@ -1252,13 +1313,14 @@ x86_emulate(
=20
     uint8_t b, d, sib, sib_index, sib_base, twobyte =3D 0, rex_prefix =3D =
0;
     uint8_t modrm =3D 0, modrm_mod =3D 0, modrm_reg =3D 0, modrm_rm =3D =
0;
+    union vex vex =3D {};
     unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes;
 #define REPE_PREFIX  1
 #define REPNE_PREFIX 2
     unsigned int lock_prefix =3D 0, rep_prefix =3D 0;
     int override_seg =3D -1, rc =3D X86EMUL_OKAY;
     struct operand src, dst;
-
+    DECLARE_ALIGNED(mmval_t, mmval);
     /*
      * Data operand effective address (usually computed from ModRM).
      * Default is a memory operand relative to segment DS.
@@ -1284,6 +1346,7 @@ x86_emulate(
         {
         case 0x66: /* operand-size override */
             op_bytes =3D def_op_bytes ^ 6;
+            vex.pfx =3D vex_66;
             break;
         case 0x67: /* address-size override */
             ad_bytes =3D def_ad_bytes ^ (mode_64bit() ? 12 : 6);
@@ -1311,9 +1374,11 @@ x86_emulate(
             break;
         case 0xf2: /* REPNE/REPNZ */
             rep_prefix =3D REPNE_PREFIX;
+            vex.pfx =3D vex_f2;
             break;
         case 0xf3: /* REP/REPE/REPZ */
             rep_prefix =3D REPE_PREFIX;
+            vex.pfx =3D vex_f3;
             break;
         case 0x40 ... 0x4f: /* REX */
             if ( !mode_64bit() )
@@ -1357,6 +1422,70 @@ x86_emulate(
     {
         modrm =3D insn_fetch_type(uint8_t);
         modrm_mod =3D (modrm & 0xc0) >> 6;
+
+        if ( !twobyte && ((b & ~1) =3D=3D 0xc4) )
+            switch ( def_ad_bytes )
+            {
+            default:
+                BUG();
+            case 2:
+                if ( in_realmode(ctxt, ops) || (_regs.eflags & EFLG_VM) )
+                    break;
+                /* fall through */
+            case 4:
+                if ( modrm_mod !=3D 3 )
+                    break;
+                /* fall through */
+            case 8:
+                /* VEX */
+                generate_exception_if(rex_prefix || vex.pfx, EXC_UD, -1);
+
+                vex.raw[0] =3D b;
+                if ( b & 1 )
+                {
+                    vex.raw[1] =3D b;
+                    vex.opcx =3D vex_0f;
+                    vex.x =3D 1;
+                    vex.b =3D 1;
+                    vex.w =3D 0;
+                }
+                else
+                {
+                    vex.raw[1] =3D insn_fetch_type(uint8_t);
+                    if ( mode_64bit() )
+                    {
+                        if ( !vex.b )
+                            rex_prefix |=3D REX_B;
+                        if ( !vex.x )
+                            rex_prefix |=3D REX_X;
+                        if ( vex.w )
+                        {
+                            rex_prefix |=3D REX_W;
+                            op_bytes =3D 8;
+                        }
+                    }
+                }
+                vex.reg ^=3D 0xf;
+                if ( !mode_64bit() )
+                    vex.reg &=3D 0x7;
+                else if ( !vex.r )
+                    rex_prefix |=3D REX_R;
+
+                fail_if(vex.opcx !=3D vex_0f);
+                twobyte =3D 1;
+                b =3D insn_fetch_type(uint8_t);
+                d =3D twobyte_table[b];
+
+                /* Unrecognised? */
+                if ( d =3D=3D 0 )
+                    goto cannot_emulate;
+
+                modrm =3D insn_fetch_type(uint8_t);
+                modrm_mod =3D (modrm & 0xc0) >> 6;
+
+                break;
+            }
+
         modrm_reg =3D ((rex_prefix & 4) << 1) | ((modrm & 0x38) >> 3);
         modrm_rm  =3D modrm & 0x07;
=20
@@ -3914,44 +4043,78 @@ x86_emulate(
         break;
     }
=20
-    case 0x6f: /* movq mm/m64,mm */ {
-        uint8_t stub[] =3D { 0x0f, 0x6f, modrm, 0xc3 };
+    case 0xe7: /* movntq mm,m64 */
+               /* {,v}movntdq xmm,m128 */
+               /* vmovntdq ymm,m256 */
+        fail_if(ea.type !=3D OP_MEM);
+        fail_if(vex.pfx =3D=3D vex_f3);
+        /* fall through */
+    case 0x6f: /* movq mm/m64,mm */
+               /* {,v}movdq{a,u} xmm/m128,xmm */
+               /* vmovdq{a,u} ymm/m256,ymm */
+    case 0x7f: /* movq mm,mm/m64 */
+               /* {,v}movdq{a,u} xmm,xmm/m128 */
+               /* vmovdq{a,u} ymm,ymm/m256 */
+    {
+        uint8_t stub[] =3D { 0x3e, 0x3e, 0x0f, b, modrm, 0xc3 };
         struct fpu_insn_ctxt fic =3D { .insn_bytes =3D sizeof(stub)-1 };
-        uint64_t val;
-        if ( ea.type =3D=3D OP_MEM )
+
+        if ( vex.opcx =3D=3D vex_none )
         {
-            unsigned long lval, hval;
-            if ( (rc =3D read_ulong(ea.mem.seg, ea.mem.off+0,
-                                  &lval, 4, ctxt, ops)) ||
-                 (rc =3D read_ulong(ea.mem.seg, ea.mem.off+4,
-                                  &hval, 4, ctxt, ops)) )
-                goto done;
-            val =3D ((uint64_t)hval << 32) | (uint32_t)lval;
-            stub[2] =3D modrm & 0x38; /* movq (%eax),%mmN */
+            switch ( vex.pfx )
+            {
+            case vex_66:
+            case vex_f3:
+                vcpu_must_have_sse2();
+                stub[0] =3D 0x66; /* movdqa */
+                get_fpu(X86EMUL_FPU_xmm, &fic);
+                ea.bytes =3D 16;
+                break;
+            case vex_none:
+                if ( b !=3D 0xe7 )
+                    vcpu_must_have_mmx();
+                else
+                    vcpu_must_have_sse();
+                get_fpu(X86EMUL_FPU_mmx, &fic);
+                ea.bytes =3D 8;
+                break;
+            default:
+                goto cannot_emulate;
+            }
+        }
+        else
+        {
+            fail_if((vex.opcx !=3D vex_0f) || vex.reg ||
+                    ((vex.pfx !=3D vex_66) && (vex.pfx !=3D vex_f3)));
+            vcpu_must_have_avx();
+            get_fpu(X86EMUL_FPU_ymm, &fic);
+            ea.bytes =3D 16 << vex.l;
         }
-        get_fpu(X86EMUL_FPU_mmx, &fic);
-        asm volatile ( "call *%0" : : "r" (stub), "a" (&val) : "memory" =
);
-        put_fpu(&fic);
-        break;
-    }
-
-    case 0x7f: /* movq mm,mm/m64 */ {
-        uint8_t stub[] =3D { 0x0f, 0x7f, modrm, 0xc3 };
-        struct fpu_insn_ctxt fic =3D { .insn_bytes =3D sizeof(stub)-1 };
-        uint64_t val;
-        if ( ea.type =3D=3D OP_MEM )
-            stub[2] =3D modrm & 0x38; /* movq %mmN,(%eax) */
-        get_fpu(X86EMUL_FPU_mmx, &fic);
-        asm volatile ( "call *%0" : : "r" (stub), "a" (&val) : "memory" =
);
-        put_fpu(&fic);
         if ( ea.type =3D=3D OP_MEM )
         {
-            unsigned long lval =3D (uint32_t)val, hval =3D (uint32_t)(val =
>> 32);
-            if ( (rc =3D ops->write(ea.mem.seg, ea.mem.off+0, &lval, 4, =
ctxt)) ||
-                 (rc =3D ops->write(ea.mem.seg, ea.mem.off+4, &hval, 4, =
ctxt)) )
-                goto done;
+            /* XXX enable once there is ops->ea() or equivalent
+            generate_exception_if((vex.pfx =3D=3D vex_66) &&
+                                  (ops->ea(ea.mem.seg, ea.mem.off)
+                                   & (ea.bytes - 1)), EXC_GP, 0); */
+            if ( b =3D=3D 0x6f )
+                rc =3D ops->read(ea.mem.seg, ea.mem.off+0, mmvalp,
+                               ea.bytes, ctxt);
+            /* convert memory operand to (%rAX) */
+            rex_prefix &=3D ~REX_B;
+            vex.b =3D 1;
+            stub[4] &=3D 0x38;
+        }
+        if ( !rc )
+        {
+           copy_REX_VEX(stub, rex_prefix, vex);
+           asm volatile ( "call *%0" : : "r" (stub), "a" (mmvalp)
+                                     : "memory" );
         }
-        break;
+        put_fpu(&fic);
+        if ( !rc && (b !=3D 0x6f) && (ea.type =3D=3D OP_MEM) )
+            rc =3D ops->write(ea.mem.seg, ea.mem.off, mmvalp,
+                            ea.bytes, ctxt);
+        goto done;
     }
=20
     case 0x80 ... 0x8f: /* jcc (near) */ {
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -99,7 +99,9 @@ struct segment_register {
 /* FPU sub-types which may be requested via ->get_fpu(). */
 enum x86_emulate_fpu_type {
     X86EMUL_FPU_fpu, /* Standard FPU coprocessor instruction set */
-    X86EMUL_FPU_mmx  /* MMX instruction set (%mm0-%mm7) */
+    X86EMUL_FPU_mmx, /* MMX instruction set (%mm0-%mm7) */
+    X86EMUL_FPU_xmm, /* SSE instruction set (%xmm0-%xmm7/15) */
+    X86EMUL_FPU_ymm  /* AVX/XOP instruction set (%ymm0-%ymm7/15) */
 };
=20
 /*
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -218,7 +218,7 @@
 #define cpu_has_x2apic          boot_cpu_has(X86_FEATURE_X2APIC)
=20
 #define cpu_has_xsave           boot_cpu_has(X86_FEATURE_XSAVE)
-
+#define cpu_has_avx             boot_cpu_has(X86_FEATURE_AVX)
 #define cpu_has_lwp             boot_cpu_has(X86_FEATURE_LWP)
=20
 #define cpu_has_arch_perfmon    boot_cpu_has(X86_FEATURE_ARCH_PERFMON)



--=__PartFFD06A5B.0__=
Content-Type: text/plain; name="x86-emul-mm-mov.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-emul-mm-mov.patch"

x86/emulator: generalize movq emulation (SSE2 and AVX variants)=0A=0AExtend=
 the existing movq emulation to also support its SSE2 and AVX=0Avariants, =
the latter implying the addition of VEX decoding. Fold the=0Aread and =
write cases (as most of the logic is identical), and add=0Amovntq and =
variants (as they're very similar).=0A=0AExtend the testing code to also =
exercise these instructions.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse=
.com>=0A=0A--- a/tools/tests/x86_emulator/test_x86_emulator.c=0A+++ =
b/tools/tests/x86_emulator/test_x86_emulator.c=0A@@ -1,3 +1,5 @@=0A+#includ=
e <errno.h>=0A+#include <stdbool.h>=0A #include <stdio.h>=0A #include =
<stdlib.h>=0A #include <string.h>=0A@@ -53,11 +55,84 @@ static int =
cmpxchg(=0A     return X86EMUL_OKAY;=0A }=0A =0A+static int cpuid(=0A+    =
unsigned int *eax,=0A+    unsigned int *ebx,=0A+    unsigned int *ecx,=0A+ =
   unsigned int *edx,=0A+    struct x86_emulate_ctxt *ctxt)=0A+{=0A+    =
asm ("cpuid" : "+a" (*eax), "+c" (*ecx), "=3Dd" (*edx), "=3Db" (*ebx));=0A+=
    return X86EMUL_OKAY;=0A+}=0A+=0A+#define cpu_has_mmx ({ \=0A+    =
unsigned int eax =3D 1, ecx =3D 0, edx; \=0A+    cpuid(&eax, &ecx, &ecx, =
&edx, NULL); \=0A+    (edx & (1U << 23)) !=3D 0; \=0A+})=0A+=0A+#define =
cpu_has_sse ({ \=0A+    unsigned int eax =3D 1, ecx =3D 0, edx; \=0A+    =
cpuid(&eax, &ecx, &ecx, &edx, NULL); \=0A+    (edx & (1U << 25)) !=3D 0; =
\=0A+})=0A+=0A+#define cpu_has_sse2 ({ \=0A+    unsigned int eax =3D 1, =
ecx =3D 0, edx; \=0A+    cpuid(&eax, &ecx, &ecx, &edx, NULL); \=0A+    =
(edx & (1U << 26)) !=3D 0; \=0A+})=0A+=0A+static inline uint64_t xgetbv(uin=
t32_t xcr)=0A+{=0A+    uint64_t res;=0A+=0A+    asm ( ".byte 0x0f, 0x01, =
0xd0" : "=3DA" (res) : "c" (xcr) );=0A+=0A+    return res;=0A+}=0A+=0A+#def=
ine cpu_has_avx ({ \=0A+    unsigned int eax =3D 1, ecx =3D 0, edx; \=0A+  =
  cpuid(&eax, &edx, &ecx, &edx, NULL); \=0A+    if ( !(ecx & (1U << 27)) =
|| ((xgetbv(0) & 6) !=3D 6) ) \=0A+        ecx =3D 0; \=0A+    (ecx & (1U =
<< 28)) !=3D 0; \=0A+})=0A+=0A+int get_fpu(=0A+    void (*exception_callbac=
k)(void *, struct cpu_user_regs *),=0A+    void *exception_callback_arg,=0A=
+    enum x86_emulate_fpu_type type,=0A+    struct x86_emulate_ctxt =
*ctxt)=0A+{=0A+    switch ( type )=0A+    {=0A+    case X86EMUL_FPU_fpu:=0A=
+        break;=0A+    case X86EMUL_FPU_ymm:=0A+        if ( cpu_has_avx =
)=0A+            break;=0A+    case X86EMUL_FPU_xmm:=0A+        if ( =
cpu_has_sse )=0A+            break;=0A+    case X86EMUL_FPU_mmx:=0A+       =
 if ( cpu_has_mmx )=0A+            break;=0A+    default:=0A+        =
return X86EMUL_UNHANDLEABLE;=0A+    }=0A+    return X86EMUL_OKAY;=0A+}=0A+=
=0A static struct x86_emulate_ops emulops =3D {=0A     .read       =3D =
read,=0A     .insn_fetch =3D read,=0A     .write      =3D write,=0A     =
.cmpxchg    =3D cmpxchg,=0A+    .cpuid      =3D cpuid,=0A+    .get_fpu    =
=3D get_fpu,=0A };=0A =0A int main(int argc, char **argv)=0A@@ -66,6 =
+141,8 @@ int main(int argc, char **argv)=0A     struct cpu_user_regs =
regs;=0A     char *instr;=0A     unsigned int *res, i, j;=0A+    unsigned =
long sp;=0A+    bool stack_exec;=0A     int rc;=0A #ifndef __x86_64__=0A   =
  unsigned int bcdres_native, bcdres_emul;=0A@@ -85,6 +162,16 @@ int =
main(int argc, char **argv)=0A     }=0A     instr =3D (char *)res + =
0x100;=0A =0A+#ifdef __x86_64__=0A+    asm ("movq %%rsp, %0" : "=3Dg" =
(sp));=0A+#else=0A+    asm ("movl %%esp, %0" : "=3Dg" (sp));=0A+#endif=0A+ =
   stack_exec =3D mprotect((void *)(sp & -0x1000L) - (MMAP_SZ - 0x1000),=0A=
+                          MMAP_SZ, PROT_READ|PROT_WRITE|PROT_EXEC) =3D=3D =
0;=0A+    if ( !stack_exec )=0A+        printf("Warning: Stack could not =
be made executable (%d).\n", errno);=0A+=0A     printf("%-40s", "Testing =
addl %%ecx,(%%eax)...");=0A     instr[0] =3D 0x01; instr[1] =3D 0x08;=0A   =
  regs.eflags =3D 0x200;=0A@@ -442,6 +529,106 @@ int main(int argc, char =
**argv)=0A     printf("skipped\n");=0A #endif=0A =0A+    printf("%-40s", =
"Testing movq %mm3,(%ecx)...");=0A+    if ( stack_exec && cpu_has_mmx =
)=0A+    {=0A+        extern const unsigned char movq_to_mem[];=0A+=0A+    =
    asm volatile ( "pcmpeqb %%mm3, %%mm3\n"=0A+                       =
".pushsection .test, \"a\", @progbits\n"=0A+                       =
"movq_to_mem: movq %%mm3, (%0)\n"=0A+                       ".popsection" =
:: "c" (NULL) );=0A+=0A+        memcpy(instr, movq_to_mem, 15);=0A+        =
memset(res, 0x33, 64);=0A+        memset(res + 8, 0xff, 8);=0A+        =
regs.eip    =3D (unsigned long)&instr[0];=0A+        regs.ecx    =3D =
(unsigned long)res;=0A+        rc =3D x86_emulate(&ctxt, &emulops);=0A+    =
    if ( (rc !=3D X86EMUL_OKAY) || memcmp(res, res + 8, 32) )=0A+          =
  goto fail;=0A+        printf("okay\n");=0A+    }=0A+    else=0A+        =
printf("skipped\n");=0A+=0A+    printf("%-40s", "Testing movq (%edx),%mm5..=
.");=0A+    if ( stack_exec && cpu_has_mmx )=0A+    {=0A+        extern =
const unsigned char movq_from_mem[];=0A+=0A+        asm volatile ( =
"pcmpgtb %%mm5, %%mm5\n"=0A+                       ".pushsection .test, =
\"a\", @progbits\n"=0A+                       "movq_from_mem: movq (%0), =
%%mm5\n"=0A+                       ".popsection" :: "d" (NULL) );=0A+=0A+  =
      memcpy(instr, movq_from_mem, 15);=0A+        regs.eip    =3D =
(unsigned long)&instr[0];=0A+        regs.ecx    =3D 0;=0A+        =
regs.edx    =3D (unsigned long)res;=0A+        rc =3D x86_emulate(&ctxt, =
&emulops);=0A+        if ( rc !=3D X86EMUL_OKAY )=0A+            goto =
fail;=0A+        asm ( "pcmpeqb %%mm3, %%mm3\n\t"=0A+              =
"pcmpeqb %%mm5, %%mm3\n\t"=0A+              "pmovmskb %%mm3, %0" : "=3Dr" =
(rc) );=0A+        if ( rc !=3D 0xff )=0A+            goto fail;=0A+       =
 printf("okay\n");=0A+    }=0A+    else=0A+        printf("skipped\n");=0A+=
=0A+    printf("%-40s", "Testing movdqu %xmm2,(%ecx)...");=0A+    if ( =
stack_exec && cpu_has_sse2 )=0A+    {=0A+        extern const unsigned =
char movdqu_to_mem[];=0A+=0A+        asm volatile ( "pcmpeqb %%xmm2, =
%%xmm2\n"=0A+                       ".pushsection .test, \"a\", @progbits\n=
"=0A+                       "movdqu_to_mem: movdqu %%xmm2, (%0)\n"=0A+     =
                  ".popsection" :: "c" (NULL) );=0A+=0A+        memcpy(inst=
r, movdqu_to_mem, 15);=0A+        memset(res, 0x55, 64);=0A+        =
memset(res + 8, 0xff, 16);=0A+        regs.eip    =3D (unsigned long)&instr=
[0];=0A+        regs.ecx    =3D (unsigned long)res;=0A+        rc =3D =
x86_emulate(&ctxt, &emulops);=0A+        if ( (rc !=3D X86EMUL_OKAY) || =
memcmp(res, res + 8, 32) )=0A+            goto fail;=0A+        printf("oka=
y\n");=0A+    }=0A+    else=0A+        printf("skipped\n");=0A+=0A+    =
printf("%-40s", "Testing movdqu (%edx),%xmm4...");=0A+    if ( stack_exec =
&& cpu_has_sse2 )=0A+    {=0A+        extern const unsigned char movdqu_fro=
m_mem[];=0A+=0A+        asm volatile ( "pcmpgtb %%xmm4, %%xmm4\n"=0A+      =
                 ".pushsection .test, \"a\", @progbits\n"=0A+              =
         "movdqu_from_mem: movdqu (%0), %%xmm4\n"=0A+                      =
 ".popsection" :: "d" (NULL) );=0A+=0A+        memcpy(instr, movdqu_from_me=
m, 15);=0A+        regs.eip    =3D (unsigned long)&instr[0];=0A+        =
regs.ecx    =3D 0;=0A+        regs.edx    =3D (unsigned long)res;=0A+      =
  rc =3D x86_emulate(&ctxt, &emulops);=0A+        if ( rc !=3D X86EMUL_OKAY=
 )=0A+            goto fail;=0A+        asm ( "pcmpeqb %%xmm2, %%xmm2\n\t"=
=0A+              "pcmpeqb %%xmm4, %%xmm2\n\t"=0A+              "pmovmskb =
%%xmm2, %0" : "=3Dr" (rc) );=0A+        if ( rc !=3D 0xffff )=0A+          =
  goto fail;=0A+        printf("okay\n");=0A+    }=0A+    else=0A+        =
printf("skipped\n");=0A+=0A     for ( j =3D 1; j <=3D 2; j++ )=0A     {=0A =
#if defined(__i386__)=0A--- a/xen/arch/x86/hvm/emulate.c=0A+++ b/xen/arch/x=
86/hvm/emulate.c=0A@@ -16,6 +16,7 @@=0A #include <xen/paging.h>=0A =
#include <xen/trace.h>=0A #include <asm/event.h>=0A+#include <asm/xstate.h>=
=0A #include <asm/hvm/emulate.h>=0A #include <asm/hvm/hvm.h>=0A #include =
<asm/hvm/trace.h>=0A@@ -928,6 +929,20 @@ static int hvmemul_get_fpu(=0A    =
     if ( !cpu_has_mmx )=0A             return X86EMUL_UNHANDLEABLE;=0A    =
     break;=0A+    case X86EMUL_FPU_xmm:=0A+        if ( !cpu_has_xmm =
||=0A+             (curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_EM) ||=0A+   =
          !(curr->arch.hvm_vcpu.guest_cr[4] & X86_CR4_OSFXSR) )=0A+        =
    return X86EMUL_UNHANDLEABLE;=0A+        break;=0A+    case X86EMUL_FPU_=
ymm:=0A+        if ( !(curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) =
||=0A+             vm86_mode(ctxt->regs) ||=0A+             !(curr->arch.hv=
m_vcpu.guest_cr[4] & X86_CR4_OSXSAVE) ||=0A+             !(curr->arch.xcr0 =
& XSTATE_SSE) ||=0A+             !(curr->arch.xcr0 & XSTATE_YMM) )=0A+     =
       return X86EMUL_UNHANDLEABLE;=0A+        break;=0A     default:=0A   =
      return X86EMUL_UNHANDLEABLE;=0A     }=0A--- a/xen/arch/x86/x86_emulat=
e/x86_emulate.c=0A+++ b/xen/arch/x86/x86_emulate/x86_emulate.c=0A@@ =
-248,11 +248,52 @@ static uint8_t twobyte_table[256] =3D {=0A     /* 0xD0 =
- 0xDF */=0A     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,=0A     /* =
0xE0 - 0xEF */=0A-    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,=0A+  =
  0, 0, 0, 0, 0, 0, 0, ImplicitOps|ModRM, 0, 0, 0, 0, 0, 0, 0, 0,=0A     =
/* 0xF0 - 0xFF */=0A     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0=0A =
};=0A =0A+#define REX_PREFIX 0x40=0A+#define REX_B 0x01=0A+#define REX_X =
0x02=0A+#define REX_R 0x04=0A+#define REX_W 0x08=0A+=0A+#define vex_none =
0=0A+=0A+enum vex_opcx {=0A+    vex_0f =3D vex_none + 1,=0A+    =
vex_0f38,=0A+    vex_0f3a,=0A+};=0A+=0A+enum vex_pfx {=0A+    vex_66 =3D =
vex_none + 1,=0A+    vex_f3,=0A+    vex_f2=0A+};=0A+=0A+union vex {=0A+    =
uint8_t raw[2];=0A+    struct {=0A+        uint8_t opcx:5;=0A+        =
uint8_t b:1;=0A+        uint8_t x:1;=0A+        uint8_t r:1;=0A+        =
uint8_t pfx:2;=0A+        uint8_t l:1;=0A+        uint8_t reg:4;=0A+       =
 uint8_t w:1;=0A+    };=0A+};=0A+=0A+#define copy_REX_VEX(ptr, rex, vex) =
do { \=0A+    if ( (vex).opcx !=3D vex_none ) \=0A+        ptr[0] =3D =
0xc4, ptr[1] =3D (vex).raw[0], ptr[2] =3D (vex).raw[1]; \=0A+    else if ( =
mode_64bit() ) \=0A+        ptr[1] =3D rex | REX_PREFIX; \=0A+} while =
(0)=0A+=0A /* Type, address-of, and value of an instruction's operand. =
*/=0A struct operand {=0A     enum { OP_REG, OP_MEM, OP_IMM, OP_NONE } =
type;=0A@@ -281,6 +322,23 @@ struct operand {=0A     };=0A };=0A =0A+typede=
f union {=0A+    uint64_t mmx;=0A+    uint64_t __attribute__ ((aligned(16))=
) xmm[2];=0A+    uint64_t __attribute__ ((aligned(32))) ymm[4];=0A+} =
mmval_t;=0A+=0A+/*=0A+ * While proper alignment gets specified above, this =
doesn't get honored by=0A+ * the compiler for automatic variables. Use =
this helper to instantiate a=0A+ * suitably aligned variable, producing a =
pointer to access it.=0A+ */=0A+#define DECLARE_ALIGNED(type, var)         =
                          \=0A+    long __##var[sizeof(type) + __alignof(ty=
pe) - __alignof(long)];  \=0A+    type *const var##p =3D                   =
                          \=0A+        (void *)((long)(__##var + __alignof(=
type) - __alignof(long)) \=0A+                 & -__alignof(type))=0A+=0A =
/* MSRs. */=0A #define MSR_TSC          0x00000010=0A #define MSR_SYSENTER_=
CS  0x00000174=0A@@ -992,9 +1050,12 @@ static bool_t vcpu_has(=0A =0A =
#define vcpu_must_have(leaf, reg, bit) \=0A     generate_exception_if(!vcpu=
_has(leaf, reg, bit, ctxt, ops), EXC_UD, -1)=0A+#define vcpu_must_have_mmx(=
)  vcpu_must_have(0x00000001, EDX, 23)=0A+#define vcpu_must_have_sse()  =
vcpu_must_have(0x00000001, EDX, 25)=0A #define vcpu_must_have_sse2() =
vcpu_must_have(0x00000001, EDX, 26)=0A #define vcpu_must_have_sse3() =
vcpu_must_have(0x00000001, ECX,  0)=0A #define vcpu_must_have_cx16() =
vcpu_must_have(0x00000001, ECX, 13)=0A+#define vcpu_must_have_avx()  =
vcpu_must_have(0x00000001, ECX, 28)=0A =0A static int=0A in_longmode(=0A@@ =
-1252,13 +1313,14 @@ x86_emulate(=0A =0A     uint8_t b, d, sib, sib_index, =
sib_base, twobyte =3D 0, rex_prefix =3D 0;=0A     uint8_t modrm =3D 0, =
modrm_mod =3D 0, modrm_reg =3D 0, modrm_rm =3D 0;=0A+    union vex vex =3D =
{};=0A     unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes;=0A =
#define REPE_PREFIX  1=0A #define REPNE_PREFIX 2=0A     unsigned int =
lock_prefix =3D 0, rep_prefix =3D 0;=0A     int override_seg =3D -1, rc =
=3D X86EMUL_OKAY;=0A     struct operand src, dst;=0A-=0A+    DECLARE_ALIGNE=
D(mmval_t, mmval);=0A     /*=0A      * Data operand effective address =
(usually computed from ModRM).=0A      * Default is a memory operand =
relative to segment DS.=0A@@ -1284,6 +1346,7 @@ x86_emulate(=0A         =
{=0A         case 0x66: /* operand-size override */=0A             =
op_bytes =3D def_op_bytes ^ 6;=0A+            vex.pfx =3D vex_66;=0A       =
      break;=0A         case 0x67: /* address-size override */=0A          =
   ad_bytes =3D def_ad_bytes ^ (mode_64bit() ? 12 : 6);=0A@@ -1311,9 =
+1374,11 @@ x86_emulate(=0A             break;=0A         case 0xf2: /* =
REPNE/REPNZ */=0A             rep_prefix =3D REPNE_PREFIX;=0A+            =
vex.pfx =3D vex_f2;=0A             break;=0A         case 0xf3: /* =
REP/REPE/REPZ */=0A             rep_prefix =3D REPE_PREFIX;=0A+            =
vex.pfx =3D vex_f3;=0A             break;=0A         case 0x40 ... 0x4f: =
/* REX */=0A             if ( !mode_64bit() )=0A@@ -1357,6 +1422,70 @@ =
x86_emulate(=0A     {=0A         modrm =3D insn_fetch_type(uint8_t);=0A    =
     modrm_mod =3D (modrm & 0xc0) >> 6;=0A+=0A+        if ( !twobyte && =
((b & ~1) =3D=3D 0xc4) )=0A+            switch ( def_ad_bytes )=0A+        =
    {=0A+            default:=0A+                BUG();=0A+            =
case 2:=0A+                if ( in_realmode(ctxt, ops) || (_regs.eflags & =
EFLG_VM) )=0A+                    break;=0A+                /* fall =
through */=0A+            case 4:=0A+                if ( modrm_mod !=3D 3 =
)=0A+                    break;=0A+                /* fall through */=0A+  =
          case 8:=0A+                /* VEX */=0A+                =
generate_exception_if(rex_prefix || vex.pfx, EXC_UD, -1);=0A+=0A+          =
      vex.raw[0] =3D b;=0A+                if ( b & 1 )=0A+                =
{=0A+                    vex.raw[1] =3D b;=0A+                    vex.opcx =
=3D vex_0f;=0A+                    vex.x =3D 1;=0A+                    =
vex.b =3D 1;=0A+                    vex.w =3D 0;=0A+                }=0A+  =
              else=0A+                {=0A+                    vex.raw[1] =
=3D insn_fetch_type(uint8_t);=0A+                    if ( mode_64bit() =
)=0A+                    {=0A+                        if ( !vex.b )=0A+    =
                        rex_prefix |=3D REX_B;=0A+                        =
if ( !vex.x )=0A+                            rex_prefix |=3D REX_X;=0A+    =
                    if ( vex.w )=0A+                        {=0A+          =
                  rex_prefix |=3D REX_W;=0A+                            =
op_bytes =3D 8;=0A+                        }=0A+                    }=0A+  =
              }=0A+                vex.reg ^=3D 0xf;=0A+                if =
( !mode_64bit() )=0A+                    vex.reg &=3D 0x7;=0A+             =
   else if ( !vex.r )=0A+                    rex_prefix |=3D REX_R;=0A+=0A+=
                fail_if(vex.opcx !=3D vex_0f);=0A+                twobyte =
=3D 1;=0A+                b =3D insn_fetch_type(uint8_t);=0A+              =
  d =3D twobyte_table[b];=0A+=0A+                /* Unrecognised? */=0A+   =
             if ( d =3D=3D 0 )=0A+                    goto cannot_emulate;=
=0A+=0A+                modrm =3D insn_fetch_type(uint8_t);=0A+            =
    modrm_mod =3D (modrm & 0xc0) >> 6;=0A+=0A+                break;=0A+   =
         }=0A+=0A         modrm_reg =3D ((rex_prefix & 4) << 1) | ((modrm =
& 0x38) >> 3);=0A         modrm_rm  =3D modrm & 0x07;=0A =0A@@ -3914,44 =
+4043,78 @@ x86_emulate(=0A         break;=0A     }=0A =0A-    case 0x6f: =
/* movq mm/m64,mm */ {=0A-        uint8_t stub[] =3D { 0x0f, 0x6f, modrm, =
0xc3 };=0A+    case 0xe7: /* movntq mm,m64 */=0A+               /* =
{,v}movntdq xmm,m128 */=0A+               /* vmovntdq ymm,m256 */=0A+      =
  fail_if(ea.type !=3D OP_MEM);=0A+        fail_if(vex.pfx =3D=3D =
vex_f3);=0A+        /* fall through */=0A+    case 0x6f: /* movq mm/m64,mm =
*/=0A+               /* {,v}movdq{a,u} xmm/m128,xmm */=0A+               =
/* vmovdq{a,u} ymm/m256,ymm */=0A+    case 0x7f: /* movq mm,mm/m64 */=0A+  =
             /* {,v}movdq{a,u} xmm,xmm/m128 */=0A+               /* =
vmovdq{a,u} ymm,ymm/m256 */=0A+    {=0A+        uint8_t stub[] =3D { 0x3e, =
0x3e, 0x0f, b, modrm, 0xc3 };=0A         struct fpu_insn_ctxt fic =3D { =
.insn_bytes =3D sizeof(stub)-1 };=0A-        uint64_t val;=0A-        if ( =
ea.type =3D=3D OP_MEM )=0A+=0A+        if ( vex.opcx =3D=3D vex_none )=0A  =
       {=0A-            unsigned long lval, hval;=0A-            if ( (rc =
=3D read_ulong(ea.mem.seg, ea.mem.off+0,=0A-                               =
   &lval, 4, ctxt, ops)) ||=0A-                 (rc =3D read_ulong(ea.mem.s=
eg, ea.mem.off+4,=0A-                                  &hval, 4, ctxt, =
ops)) )=0A-                goto done;=0A-            val =3D ((uint64_t)hva=
l << 32) | (uint32_t)lval;=0A-            stub[2] =3D modrm & 0x38; /* =
movq (%eax),%mmN */=0A+            switch ( vex.pfx )=0A+            {=0A+ =
           case vex_66:=0A+            case vex_f3:=0A+                =
vcpu_must_have_sse2();=0A+                stub[0] =3D 0x66; /* movdqa =
*/=0A+                get_fpu(X86EMUL_FPU_xmm, &fic);=0A+                =
ea.bytes =3D 16;=0A+                break;=0A+            case vex_none:=0A=
+                if ( b !=3D 0xe7 )=0A+                    vcpu_must_have_m=
mx();=0A+                else=0A+                    vcpu_must_have_sse();=
=0A+                get_fpu(X86EMUL_FPU_mmx, &fic);=0A+                =
ea.bytes =3D 8;=0A+                break;=0A+            default:=0A+      =
          goto cannot_emulate;=0A+            }=0A+        }=0A+        =
else=0A+        {=0A+            fail_if((vex.opcx !=3D vex_0f) || vex.reg =
||=0A+                    ((vex.pfx !=3D vex_66) && (vex.pfx !=3D =
vex_f3)));=0A+            vcpu_must_have_avx();=0A+            get_fpu(X86E=
MUL_FPU_ymm, &fic);=0A+            ea.bytes =3D 16 << vex.l;=0A         =
}=0A-        get_fpu(X86EMUL_FPU_mmx, &fic);=0A-        asm volatile ( =
"call *%0" : : "r" (stub), "a" (&val) : "memory" );=0A-        put_fpu(&fic=
);=0A-        break;=0A-    }=0A-=0A-    case 0x7f: /* movq mm,mm/m64 */ =
{=0A-        uint8_t stub[] =3D { 0x0f, 0x7f, modrm, 0xc3 };=0A-        =
struct fpu_insn_ctxt fic =3D { .insn_bytes =3D sizeof(stub)-1 };=0A-       =
 uint64_t val;=0A-        if ( ea.type =3D=3D OP_MEM )=0A-            =
stub[2] =3D modrm & 0x38; /* movq %mmN,(%eax) */=0A-        get_fpu(X86EMUL=
_FPU_mmx, &fic);=0A-        asm volatile ( "call *%0" : : "r" (stub), "a" =
(&val) : "memory" );=0A-        put_fpu(&fic);=0A         if ( ea.type =
=3D=3D OP_MEM )=0A         {=0A-            unsigned long lval =3D =
(uint32_t)val, hval =3D (uint32_t)(val >> 32);=0A-            if ( (rc =3D =
ops->write(ea.mem.seg, ea.mem.off+0, &lval, 4, ctxt)) ||=0A-               =
  (rc =3D ops->write(ea.mem.seg, ea.mem.off+4, &hval, 4, ctxt)) )=0A-      =
          goto done;=0A+            /* XXX enable once there is ops->ea() =
or equivalent=0A+            generate_exception_if((vex.pfx =3D=3D vex_66) =
&&=0A+                                  (ops->ea(ea.mem.seg, ea.mem.off)=0A=
+                                   & (ea.bytes - 1)), EXC_GP, 0); */=0A+  =
          if ( b =3D=3D 0x6f )=0A+                rc =3D ops->read(ea.mem.s=
eg, ea.mem.off+0, mmvalp,=0A+                               ea.bytes, =
ctxt);=0A+            /* convert memory operand to (%rAX) */=0A+           =
 rex_prefix &=3D ~REX_B;=0A+            vex.b =3D 1;=0A+            =
stub[4] &=3D 0x38;=0A+        }=0A+        if ( !rc )=0A+        {=0A+     =
      copy_REX_VEX(stub, rex_prefix, vex);=0A+           asm volatile ( =
"call *%0" : : "r" (stub), "a" (mmvalp)=0A+                                =
     : "memory" );=0A         }=0A-        break;=0A+        put_fpu(&fic);=
=0A+        if ( !rc && (b !=3D 0x6f) && (ea.type =3D=3D OP_MEM) )=0A+     =
       rc =3D ops->write(ea.mem.seg, ea.mem.off, mmvalp,=0A+               =
             ea.bytes, ctxt);=0A+        goto done;=0A     }=0A =0A     =
case 0x80 ... 0x8f: /* jcc (near) */ {=0A--- a/xen/arch/x86/x86_emulate/x86=
_emulate.h=0A+++ b/xen/arch/x86/x86_emulate/x86_emulate.h=0A@@ -99,7 +99,9 =
@@ struct segment_register {=0A /* FPU sub-types which may be requested =
via ->get_fpu(). */=0A enum x86_emulate_fpu_type {=0A     X86EMUL_FPU_fpu, =
/* Standard FPU coprocessor instruction set */=0A-    X86EMUL_FPU_mmx  /* =
MMX instruction set (%mm0-%mm7) */=0A+    X86EMUL_FPU_mmx, /* MMX =
instruction set (%mm0-%mm7) */=0A+    X86EMUL_FPU_xmm, /* SSE instruction =
set (%xmm0-%xmm7/15) */=0A+    X86EMUL_FPU_ymm  /* AVX/XOP instruction set =
(%ymm0-%ymm7/15) */=0A };=0A =0A /*=0A--- a/xen/include/asm-x86/cpufeature.=
h=0A+++ b/xen/include/asm-x86/cpufeature.h=0A@@ -218,7 +218,7 @@=0A =
#define cpu_has_x2apic          boot_cpu_has(X86_FEATURE_X2APIC)=0A =0A =
#define cpu_has_xsave           boot_cpu_has(X86_FEATURE_XSAVE)=0A-=0A+#def=
ine cpu_has_avx             boot_cpu_has(X86_FEATURE_AVX)=0A #define =
cpu_has_lwp             boot_cpu_has(X86_FEATURE_LWP)=0A =0A #define =
cpu_has_arch_perfmon    boot_cpu_has(X86_FEATURE_ARCH_PERFMON)=0A
--=__PartFFD06A5B.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartFFD06A5B.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:07:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmgN-0004It-3B; Wed, 30 Nov 2011 16:06:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmgL-0004IL-5L
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:06:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322669133!5581458!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7855 invoked from network); 30 Nov 2011 16:05:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:05:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:05:33 +0000
Message-Id: <4ED6625B0200007800064673@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:05:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFFD06A5B.0__="
Subject: [Xen-devel] [PATCH 1/4] x86/emulator: generalize movq emulation
 (SSE2 and AVX variants)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartFFD06A5B.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Extend the existing movq emulation to also support its SSE2 and AVX
variants, the latter implying the addition of VEX decoding. Fold the
read and write cases (as most of the logic is identical), and add
movntq and variants (as they're very similar).

Extend the testing code to also exercise these instructions.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1,3 +1,5 @@
+#include <errno.h>
+#include <stdbool.h>
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
@@ -53,11 +55,84 @@ static int cmpxchg(
     return X86EMUL_OKAY;
 }
=20
+static int cpuid(
+    unsigned int *eax,
+    unsigned int *ebx,
+    unsigned int *ecx,
+    unsigned int *edx,
+    struct x86_emulate_ctxt *ctxt)
+{
+    asm ("cpuid" : "+a" (*eax), "+c" (*ecx), "=3Dd" (*edx), "=3Db" =
(*ebx));
+    return X86EMUL_OKAY;
+}
+
+#define cpu_has_mmx ({ \
+    unsigned int eax =3D 1, ecx =3D 0, edx; \
+    cpuid(&eax, &ecx, &ecx, &edx, NULL); \
+    (edx & (1U << 23)) !=3D 0; \
+})
+
+#define cpu_has_sse ({ \
+    unsigned int eax =3D 1, ecx =3D 0, edx; \
+    cpuid(&eax, &ecx, &ecx, &edx, NULL); \
+    (edx & (1U << 25)) !=3D 0; \
+})
+
+#define cpu_has_sse2 ({ \
+    unsigned int eax =3D 1, ecx =3D 0, edx; \
+    cpuid(&eax, &ecx, &ecx, &edx, NULL); \
+    (edx & (1U << 26)) !=3D 0; \
+})
+
+static inline uint64_t xgetbv(uint32_t xcr)
+{
+    uint64_t res;
+
+    asm ( ".byte 0x0f, 0x01, 0xd0" : "=3DA" (res) : "c" (xcr) );
+
+    return res;
+}
+
+#define cpu_has_avx ({ \
+    unsigned int eax =3D 1, ecx =3D 0, edx; \
+    cpuid(&eax, &edx, &ecx, &edx, NULL); \
+    if ( !(ecx & (1U << 27)) || ((xgetbv(0) & 6) !=3D 6) ) \
+        ecx =3D 0; \
+    (ecx & (1U << 28)) !=3D 0; \
+})
+
+int get_fpu(
+    void (*exception_callback)(void *, struct cpu_user_regs *),
+    void *exception_callback_arg,
+    enum x86_emulate_fpu_type type,
+    struct x86_emulate_ctxt *ctxt)
+{
+    switch ( type )
+    {
+    case X86EMUL_FPU_fpu:
+        break;
+    case X86EMUL_FPU_ymm:
+        if ( cpu_has_avx )
+            break;
+    case X86EMUL_FPU_xmm:
+        if ( cpu_has_sse )
+            break;
+    case X86EMUL_FPU_mmx:
+        if ( cpu_has_mmx )
+            break;
+    default:
+        return X86EMUL_UNHANDLEABLE;
+    }
+    return X86EMUL_OKAY;
+}
+
 static struct x86_emulate_ops emulops =3D {
     .read       =3D read,
     .insn_fetch =3D read,
     .write      =3D write,
     .cmpxchg    =3D cmpxchg,
+    .cpuid      =3D cpuid,
+    .get_fpu    =3D get_fpu,
 };
=20
 int main(int argc, char **argv)
@@ -66,6 +141,8 @@ int main(int argc, char **argv)
     struct cpu_user_regs regs;
     char *instr;
     unsigned int *res, i, j;
+    unsigned long sp;
+    bool stack_exec;
     int rc;
 #ifndef __x86_64__
     unsigned int bcdres_native, bcdres_emul;
@@ -85,6 +162,16 @@ int main(int argc, char **argv)
     }
     instr =3D (char *)res + 0x100;
=20
+#ifdef __x86_64__
+    asm ("movq %%rsp, %0" : "=3Dg" (sp));
+#else
+    asm ("movl %%esp, %0" : "=3Dg" (sp));
+#endif
+    stack_exec =3D mprotect((void *)(sp & -0x1000L) - (MMAP_SZ - 0x1000),
+                          MMAP_SZ, PROT_READ|PROT_WRITE|PROT_EXEC) =3D=3D =
0;
+    if ( !stack_exec )
+        printf("Warning: Stack could not be made executable (%d).\n", =
errno);
+
     printf("%-40s", "Testing addl %%ecx,(%%eax)...");
     instr[0] =3D 0x01; instr[1] =3D 0x08;
     regs.eflags =3D 0x200;
@@ -442,6 +529,106 @@ int main(int argc, char **argv)
     printf("skipped\n");
 #endif
=20
+    printf("%-40s", "Testing movq %mm3,(%ecx)...");
+    if ( stack_exec && cpu_has_mmx )
+    {
+        extern const unsigned char movq_to_mem[];
+
+        asm volatile ( "pcmpeqb %%mm3, %%mm3\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movq_to_mem: movq %%mm3, (%0)\n"
+                       ".popsection" :: "c" (NULL) );
+
+        memcpy(instr, movq_to_mem, 15);
+        memset(res, 0x33, 64);
+        memset(res + 8, 0xff, 8);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D (unsigned long)res;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( (rc !=3D X86EMUL_OKAY) || memcmp(res, res + 8, 32) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing movq (%edx),%mm5...");
+    if ( stack_exec && cpu_has_mmx )
+    {
+        extern const unsigned char movq_from_mem[];
+
+        asm volatile ( "pcmpgtb %%mm5, %%mm5\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movq_from_mem: movq (%0), %%mm5\n"
+                       ".popsection" :: "d" (NULL) );
+
+        memcpy(instr, movq_from_mem, 15);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D 0;
+        regs.edx    =3D (unsigned long)res;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( rc !=3D X86EMUL_OKAY )
+            goto fail;
+        asm ( "pcmpeqb %%mm3, %%mm3\n\t"
+              "pcmpeqb %%mm5, %%mm3\n\t"
+              "pmovmskb %%mm3, %0" : "=3Dr" (rc) );
+        if ( rc !=3D 0xff )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing movdqu %xmm2,(%ecx)...");
+    if ( stack_exec && cpu_has_sse2 )
+    {
+        extern const unsigned char movdqu_to_mem[];
+
+        asm volatile ( "pcmpeqb %%xmm2, %%xmm2\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movdqu_to_mem: movdqu %%xmm2, (%0)\n"
+                       ".popsection" :: "c" (NULL) );
+
+        memcpy(instr, movdqu_to_mem, 15);
+        memset(res, 0x55, 64);
+        memset(res + 8, 0xff, 16);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D (unsigned long)res;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( (rc !=3D X86EMUL_OKAY) || memcmp(res, res + 8, 32) )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
+    printf("%-40s", "Testing movdqu (%edx),%xmm4...");
+    if ( stack_exec && cpu_has_sse2 )
+    {
+        extern const unsigned char movdqu_from_mem[];
+
+        asm volatile ( "pcmpgtb %%xmm4, %%xmm4\n"
+                       ".pushsection .test, \"a\", @progbits\n"
+                       "movdqu_from_mem: movdqu (%0), %%xmm4\n"
+                       ".popsection" :: "d" (NULL) );
+
+        memcpy(instr, movdqu_from_mem, 15);
+        regs.eip    =3D (unsigned long)&instr[0];
+        regs.ecx    =3D 0;
+        regs.edx    =3D (unsigned long)res;
+        rc =3D x86_emulate(&ctxt, &emulops);
+        if ( rc !=3D X86EMUL_OKAY )
+            goto fail;
+        asm ( "pcmpeqb %%xmm2, %%xmm2\n\t"
+              "pcmpeqb %%xmm4, %%xmm2\n\t"
+              "pmovmskb %%xmm2, %0" : "=3Dr" (rc) );
+        if ( rc !=3D 0xffff )
+            goto fail;
+        printf("okay\n");
+    }
+    else
+        printf("skipped\n");
+
     for ( j =3D 1; j <=3D 2; j++ )
     {
 #if defined(__i386__)
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -16,6 +16,7 @@
 #include <xen/paging.h>
 #include <xen/trace.h>
 #include <asm/event.h>
+#include <asm/xstate.h>
 #include <asm/hvm/emulate.h>
 #include <asm/hvm/hvm.h>
 #include <asm/hvm/trace.h>
@@ -928,6 +929,20 @@ static int hvmemul_get_fpu(
         if ( !cpu_has_mmx )
             return X86EMUL_UNHANDLEABLE;
         break;
+    case X86EMUL_FPU_xmm:
+        if ( !cpu_has_xmm ||
+             (curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_EM) ||
+             !(curr->arch.hvm_vcpu.guest_cr[4] & X86_CR4_OSFXSR) )
+            return X86EMUL_UNHANDLEABLE;
+        break;
+    case X86EMUL_FPU_ymm:
+        if ( !(curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) ||
+             vm86_mode(ctxt->regs) ||
+             !(curr->arch.hvm_vcpu.guest_cr[4] & X86_CR4_OSXSAVE) ||
+             !(curr->arch.xcr0 & XSTATE_SSE) ||
+             !(curr->arch.xcr0 & XSTATE_YMM) )
+            return X86EMUL_UNHANDLEABLE;
+        break;
     default:
         return X86EMUL_UNHANDLEABLE;
     }
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -248,11 +248,52 @@ static uint8_t twobyte_table[256] =3D {
     /* 0xD0 - 0xDF */
     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
     /* 0xE0 - 0xEF */
-    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+    0, 0, 0, 0, 0, 0, 0, ImplicitOps|ModRM, 0, 0, 0, 0, 0, 0, 0, 0,
     /* 0xF0 - 0xFF */
     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
 };
=20
+#define REX_PREFIX 0x40
+#define REX_B 0x01
+#define REX_X 0x02
+#define REX_R 0x04
+#define REX_W 0x08
+
+#define vex_none 0
+
+enum vex_opcx {
+    vex_0f =3D vex_none + 1,
+    vex_0f38,
+    vex_0f3a,
+};
+
+enum vex_pfx {
+    vex_66 =3D vex_none + 1,
+    vex_f3,
+    vex_f2
+};
+
+union vex {
+    uint8_t raw[2];
+    struct {
+        uint8_t opcx:5;
+        uint8_t b:1;
+        uint8_t x:1;
+        uint8_t r:1;
+        uint8_t pfx:2;
+        uint8_t l:1;
+        uint8_t reg:4;
+        uint8_t w:1;
+    };
+};
+
+#define copy_REX_VEX(ptr, rex, vex) do { \
+    if ( (vex).opcx !=3D vex_none ) \
+        ptr[0] =3D 0xc4, ptr[1] =3D (vex).raw[0], ptr[2] =3D (vex).raw[1];=
 \
+    else if ( mode_64bit() ) \
+        ptr[1] =3D rex | REX_PREFIX; \
+} while (0)
+
 /* Type, address-of, and value of an instruction's operand. */
 struct operand {
     enum { OP_REG, OP_MEM, OP_IMM, OP_NONE } type;
@@ -281,6 +322,23 @@ struct operand {
     };
 };
=20
+typedef union {
+    uint64_t mmx;
+    uint64_t __attribute__ ((aligned(16))) xmm[2];
+    uint64_t __attribute__ ((aligned(32))) ymm[4];
+} mmval_t;
+
+/*
+ * While proper alignment gets specified above, this doesn't get honored =
by
+ * the compiler for automatic variables. Use this helper to instantiate a
+ * suitably aligned variable, producing a pointer to access it.
+ */
+#define DECLARE_ALIGNED(type, var)                                   \
+    long __##var[sizeof(type) + __alignof(type) - __alignof(long)];  \
+    type *const var##p =3D                                             \
+        (void *)((long)(__##var + __alignof(type) - __alignof(long)) \
+                 & -__alignof(type))
+
 /* MSRs. */
 #define MSR_TSC          0x00000010
 #define MSR_SYSENTER_CS  0x00000174
@@ -992,9 +1050,12 @@ static bool_t vcpu_has(
=20
 #define vcpu_must_have(leaf, reg, bit) \
     generate_exception_if(!vcpu_has(leaf, reg, bit, ctxt, ops), EXC_UD, =
-1)
+#define vcpu_must_have_mmx()  vcpu_must_have(0x00000001, EDX, 23)
+#define vcpu_must_have_sse()  vcpu_must_have(0x00000001, EDX, 25)
 #define vcpu_must_have_sse2() vcpu_must_have(0x00000001, EDX, 26)
 #define vcpu_must_have_sse3() vcpu_must_have(0x00000001, ECX,  0)
 #define vcpu_must_have_cx16() vcpu_must_have(0x00000001, ECX, 13)
+#define vcpu_must_have_avx()  vcpu_must_have(0x00000001, ECX, 28)
=20
 static int
 in_longmode(
@@ -1252,13 +1313,14 @@ x86_emulate(
=20
     uint8_t b, d, sib, sib_index, sib_base, twobyte =3D 0, rex_prefix =3D =
0;
     uint8_t modrm =3D 0, modrm_mod =3D 0, modrm_reg =3D 0, modrm_rm =3D =
0;
+    union vex vex =3D {};
     unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes;
 #define REPE_PREFIX  1
 #define REPNE_PREFIX 2
     unsigned int lock_prefix =3D 0, rep_prefix =3D 0;
     int override_seg =3D -1, rc =3D X86EMUL_OKAY;
     struct operand src, dst;
-
+    DECLARE_ALIGNED(mmval_t, mmval);
     /*
      * Data operand effective address (usually computed from ModRM).
      * Default is a memory operand relative to segment DS.
@@ -1284,6 +1346,7 @@ x86_emulate(
         {
         case 0x66: /* operand-size override */
             op_bytes =3D def_op_bytes ^ 6;
+            vex.pfx =3D vex_66;
             break;
         case 0x67: /* address-size override */
             ad_bytes =3D def_ad_bytes ^ (mode_64bit() ? 12 : 6);
@@ -1311,9 +1374,11 @@ x86_emulate(
             break;
         case 0xf2: /* REPNE/REPNZ */
             rep_prefix =3D REPNE_PREFIX;
+            vex.pfx =3D vex_f2;
             break;
         case 0xf3: /* REP/REPE/REPZ */
             rep_prefix =3D REPE_PREFIX;
+            vex.pfx =3D vex_f3;
             break;
         case 0x40 ... 0x4f: /* REX */
             if ( !mode_64bit() )
@@ -1357,6 +1422,70 @@ x86_emulate(
     {
         modrm =3D insn_fetch_type(uint8_t);
         modrm_mod =3D (modrm & 0xc0) >> 6;
+
+        if ( !twobyte && ((b & ~1) =3D=3D 0xc4) )
+            switch ( def_ad_bytes )
+            {
+            default:
+                BUG();
+            case 2:
+                if ( in_realmode(ctxt, ops) || (_regs.eflags & EFLG_VM) )
+                    break;
+                /* fall through */
+            case 4:
+                if ( modrm_mod !=3D 3 )
+                    break;
+                /* fall through */
+            case 8:
+                /* VEX */
+                generate_exception_if(rex_prefix || vex.pfx, EXC_UD, -1);
+
+                vex.raw[0] =3D b;
+                if ( b & 1 )
+                {
+                    vex.raw[1] =3D b;
+                    vex.opcx =3D vex_0f;
+                    vex.x =3D 1;
+                    vex.b =3D 1;
+                    vex.w =3D 0;
+                }
+                else
+                {
+                    vex.raw[1] =3D insn_fetch_type(uint8_t);
+                    if ( mode_64bit() )
+                    {
+                        if ( !vex.b )
+                            rex_prefix |=3D REX_B;
+                        if ( !vex.x )
+                            rex_prefix |=3D REX_X;
+                        if ( vex.w )
+                        {
+                            rex_prefix |=3D REX_W;
+                            op_bytes =3D 8;
+                        }
+                    }
+                }
+                vex.reg ^=3D 0xf;
+                if ( !mode_64bit() )
+                    vex.reg &=3D 0x7;
+                else if ( !vex.r )
+                    rex_prefix |=3D REX_R;
+
+                fail_if(vex.opcx !=3D vex_0f);
+                twobyte =3D 1;
+                b =3D insn_fetch_type(uint8_t);
+                d =3D twobyte_table[b];
+
+                /* Unrecognised? */
+                if ( d =3D=3D 0 )
+                    goto cannot_emulate;
+
+                modrm =3D insn_fetch_type(uint8_t);
+                modrm_mod =3D (modrm & 0xc0) >> 6;
+
+                break;
+            }
+
         modrm_reg =3D ((rex_prefix & 4) << 1) | ((modrm & 0x38) >> 3);
         modrm_rm  =3D modrm & 0x07;
=20
@@ -3914,44 +4043,78 @@ x86_emulate(
         break;
     }
=20
-    case 0x6f: /* movq mm/m64,mm */ {
-        uint8_t stub[] =3D { 0x0f, 0x6f, modrm, 0xc3 };
+    case 0xe7: /* movntq mm,m64 */
+               /* {,v}movntdq xmm,m128 */
+               /* vmovntdq ymm,m256 */
+        fail_if(ea.type !=3D OP_MEM);
+        fail_if(vex.pfx =3D=3D vex_f3);
+        /* fall through */
+    case 0x6f: /* movq mm/m64,mm */
+               /* {,v}movdq{a,u} xmm/m128,xmm */
+               /* vmovdq{a,u} ymm/m256,ymm */
+    case 0x7f: /* movq mm,mm/m64 */
+               /* {,v}movdq{a,u} xmm,xmm/m128 */
+               /* vmovdq{a,u} ymm,ymm/m256 */
+    {
+        uint8_t stub[] =3D { 0x3e, 0x3e, 0x0f, b, modrm, 0xc3 };
         struct fpu_insn_ctxt fic =3D { .insn_bytes =3D sizeof(stub)-1 };
-        uint64_t val;
-        if ( ea.type =3D=3D OP_MEM )
+
+        if ( vex.opcx =3D=3D vex_none )
         {
-            unsigned long lval, hval;
-            if ( (rc =3D read_ulong(ea.mem.seg, ea.mem.off+0,
-                                  &lval, 4, ctxt, ops)) ||
-                 (rc =3D read_ulong(ea.mem.seg, ea.mem.off+4,
-                                  &hval, 4, ctxt, ops)) )
-                goto done;
-            val =3D ((uint64_t)hval << 32) | (uint32_t)lval;
-            stub[2] =3D modrm & 0x38; /* movq (%eax),%mmN */
+            switch ( vex.pfx )
+            {
+            case vex_66:
+            case vex_f3:
+                vcpu_must_have_sse2();
+                stub[0] =3D 0x66; /* movdqa */
+                get_fpu(X86EMUL_FPU_xmm, &fic);
+                ea.bytes =3D 16;
+                break;
+            case vex_none:
+                if ( b !=3D 0xe7 )
+                    vcpu_must_have_mmx();
+                else
+                    vcpu_must_have_sse();
+                get_fpu(X86EMUL_FPU_mmx, &fic);
+                ea.bytes =3D 8;
+                break;
+            default:
+                goto cannot_emulate;
+            }
+        }
+        else
+        {
+            fail_if((vex.opcx !=3D vex_0f) || vex.reg ||
+                    ((vex.pfx !=3D vex_66) && (vex.pfx !=3D vex_f3)));
+            vcpu_must_have_avx();
+            get_fpu(X86EMUL_FPU_ymm, &fic);
+            ea.bytes =3D 16 << vex.l;
         }
-        get_fpu(X86EMUL_FPU_mmx, &fic);
-        asm volatile ( "call *%0" : : "r" (stub), "a" (&val) : "memory" =
);
-        put_fpu(&fic);
-        break;
-    }
-
-    case 0x7f: /* movq mm,mm/m64 */ {
-        uint8_t stub[] =3D { 0x0f, 0x7f, modrm, 0xc3 };
-        struct fpu_insn_ctxt fic =3D { .insn_bytes =3D sizeof(stub)-1 };
-        uint64_t val;
-        if ( ea.type =3D=3D OP_MEM )
-            stub[2] =3D modrm & 0x38; /* movq %mmN,(%eax) */
-        get_fpu(X86EMUL_FPU_mmx, &fic);
-        asm volatile ( "call *%0" : : "r" (stub), "a" (&val) : "memory" =
);
-        put_fpu(&fic);
         if ( ea.type =3D=3D OP_MEM )
         {
-            unsigned long lval =3D (uint32_t)val, hval =3D (uint32_t)(val =
>> 32);
-            if ( (rc =3D ops->write(ea.mem.seg, ea.mem.off+0, &lval, 4, =
ctxt)) ||
-                 (rc =3D ops->write(ea.mem.seg, ea.mem.off+4, &hval, 4, =
ctxt)) )
-                goto done;
+            /* XXX enable once there is ops->ea() or equivalent
+            generate_exception_if((vex.pfx =3D=3D vex_66) &&
+                                  (ops->ea(ea.mem.seg, ea.mem.off)
+                                   & (ea.bytes - 1)), EXC_GP, 0); */
+            if ( b =3D=3D 0x6f )
+                rc =3D ops->read(ea.mem.seg, ea.mem.off+0, mmvalp,
+                               ea.bytes, ctxt);
+            /* convert memory operand to (%rAX) */
+            rex_prefix &=3D ~REX_B;
+            vex.b =3D 1;
+            stub[4] &=3D 0x38;
+        }
+        if ( !rc )
+        {
+           copy_REX_VEX(stub, rex_prefix, vex);
+           asm volatile ( "call *%0" : : "r" (stub), "a" (mmvalp)
+                                     : "memory" );
         }
-        break;
+        put_fpu(&fic);
+        if ( !rc && (b !=3D 0x6f) && (ea.type =3D=3D OP_MEM) )
+            rc =3D ops->write(ea.mem.seg, ea.mem.off, mmvalp,
+                            ea.bytes, ctxt);
+        goto done;
     }
=20
     case 0x80 ... 0x8f: /* jcc (near) */ {
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -99,7 +99,9 @@ struct segment_register {
 /* FPU sub-types which may be requested via ->get_fpu(). */
 enum x86_emulate_fpu_type {
     X86EMUL_FPU_fpu, /* Standard FPU coprocessor instruction set */
-    X86EMUL_FPU_mmx  /* MMX instruction set (%mm0-%mm7) */
+    X86EMUL_FPU_mmx, /* MMX instruction set (%mm0-%mm7) */
+    X86EMUL_FPU_xmm, /* SSE instruction set (%xmm0-%xmm7/15) */
+    X86EMUL_FPU_ymm  /* AVX/XOP instruction set (%ymm0-%ymm7/15) */
 };
=20
 /*
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -218,7 +218,7 @@
 #define cpu_has_x2apic          boot_cpu_has(X86_FEATURE_X2APIC)
=20
 #define cpu_has_xsave           boot_cpu_has(X86_FEATURE_XSAVE)
-
+#define cpu_has_avx             boot_cpu_has(X86_FEATURE_AVX)
 #define cpu_has_lwp             boot_cpu_has(X86_FEATURE_LWP)
=20
 #define cpu_has_arch_perfmon    boot_cpu_has(X86_FEATURE_ARCH_PERFMON)



--=__PartFFD06A5B.0__=
Content-Type: text/plain; name="x86-emul-mm-mov.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-emul-mm-mov.patch"

x86/emulator: generalize movq emulation (SSE2 and AVX variants)=0A=0AExtend=
 the existing movq emulation to also support its SSE2 and AVX=0Avariants, =
the latter implying the addition of VEX decoding. Fold the=0Aread and =
write cases (as most of the logic is identical), and add=0Amovntq and =
variants (as they're very similar).=0A=0AExtend the testing code to also =
exercise these instructions.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse=
.com>=0A=0A--- a/tools/tests/x86_emulator/test_x86_emulator.c=0A+++ =
b/tools/tests/x86_emulator/test_x86_emulator.c=0A@@ -1,3 +1,5 @@=0A+#includ=
e <errno.h>=0A+#include <stdbool.h>=0A #include <stdio.h>=0A #include =
<stdlib.h>=0A #include <string.h>=0A@@ -53,11 +55,84 @@ static int =
cmpxchg(=0A     return X86EMUL_OKAY;=0A }=0A =0A+static int cpuid(=0A+    =
unsigned int *eax,=0A+    unsigned int *ebx,=0A+    unsigned int *ecx,=0A+ =
   unsigned int *edx,=0A+    struct x86_emulate_ctxt *ctxt)=0A+{=0A+    =
asm ("cpuid" : "+a" (*eax), "+c" (*ecx), "=3Dd" (*edx), "=3Db" (*ebx));=0A+=
    return X86EMUL_OKAY;=0A+}=0A+=0A+#define cpu_has_mmx ({ \=0A+    =
unsigned int eax =3D 1, ecx =3D 0, edx; \=0A+    cpuid(&eax, &ecx, &ecx, =
&edx, NULL); \=0A+    (edx & (1U << 23)) !=3D 0; \=0A+})=0A+=0A+#define =
cpu_has_sse ({ \=0A+    unsigned int eax =3D 1, ecx =3D 0, edx; \=0A+    =
cpuid(&eax, &ecx, &ecx, &edx, NULL); \=0A+    (edx & (1U << 25)) !=3D 0; =
\=0A+})=0A+=0A+#define cpu_has_sse2 ({ \=0A+    unsigned int eax =3D 1, =
ecx =3D 0, edx; \=0A+    cpuid(&eax, &ecx, &ecx, &edx, NULL); \=0A+    =
(edx & (1U << 26)) !=3D 0; \=0A+})=0A+=0A+static inline uint64_t xgetbv(uin=
t32_t xcr)=0A+{=0A+    uint64_t res;=0A+=0A+    asm ( ".byte 0x0f, 0x01, =
0xd0" : "=3DA" (res) : "c" (xcr) );=0A+=0A+    return res;=0A+}=0A+=0A+#def=
ine cpu_has_avx ({ \=0A+    unsigned int eax =3D 1, ecx =3D 0, edx; \=0A+  =
  cpuid(&eax, &edx, &ecx, &edx, NULL); \=0A+    if ( !(ecx & (1U << 27)) =
|| ((xgetbv(0) & 6) !=3D 6) ) \=0A+        ecx =3D 0; \=0A+    (ecx & (1U =
<< 28)) !=3D 0; \=0A+})=0A+=0A+int get_fpu(=0A+    void (*exception_callbac=
k)(void *, struct cpu_user_regs *),=0A+    void *exception_callback_arg,=0A=
+    enum x86_emulate_fpu_type type,=0A+    struct x86_emulate_ctxt =
*ctxt)=0A+{=0A+    switch ( type )=0A+    {=0A+    case X86EMUL_FPU_fpu:=0A=
+        break;=0A+    case X86EMUL_FPU_ymm:=0A+        if ( cpu_has_avx =
)=0A+            break;=0A+    case X86EMUL_FPU_xmm:=0A+        if ( =
cpu_has_sse )=0A+            break;=0A+    case X86EMUL_FPU_mmx:=0A+       =
 if ( cpu_has_mmx )=0A+            break;=0A+    default:=0A+        =
return X86EMUL_UNHANDLEABLE;=0A+    }=0A+    return X86EMUL_OKAY;=0A+}=0A+=
=0A static struct x86_emulate_ops emulops =3D {=0A     .read       =3D =
read,=0A     .insn_fetch =3D read,=0A     .write      =3D write,=0A     =
.cmpxchg    =3D cmpxchg,=0A+    .cpuid      =3D cpuid,=0A+    .get_fpu    =
=3D get_fpu,=0A };=0A =0A int main(int argc, char **argv)=0A@@ -66,6 =
+141,8 @@ int main(int argc, char **argv)=0A     struct cpu_user_regs =
regs;=0A     char *instr;=0A     unsigned int *res, i, j;=0A+    unsigned =
long sp;=0A+    bool stack_exec;=0A     int rc;=0A #ifndef __x86_64__=0A   =
  unsigned int bcdres_native, bcdres_emul;=0A@@ -85,6 +162,16 @@ int =
main(int argc, char **argv)=0A     }=0A     instr =3D (char *)res + =
0x100;=0A =0A+#ifdef __x86_64__=0A+    asm ("movq %%rsp, %0" : "=3Dg" =
(sp));=0A+#else=0A+    asm ("movl %%esp, %0" : "=3Dg" (sp));=0A+#endif=0A+ =
   stack_exec =3D mprotect((void *)(sp & -0x1000L) - (MMAP_SZ - 0x1000),=0A=
+                          MMAP_SZ, PROT_READ|PROT_WRITE|PROT_EXEC) =3D=3D =
0;=0A+    if ( !stack_exec )=0A+        printf("Warning: Stack could not =
be made executable (%d).\n", errno);=0A+=0A     printf("%-40s", "Testing =
addl %%ecx,(%%eax)...");=0A     instr[0] =3D 0x01; instr[1] =3D 0x08;=0A   =
  regs.eflags =3D 0x200;=0A@@ -442,6 +529,106 @@ int main(int argc, char =
**argv)=0A     printf("skipped\n");=0A #endif=0A =0A+    printf("%-40s", =
"Testing movq %mm3,(%ecx)...");=0A+    if ( stack_exec && cpu_has_mmx =
)=0A+    {=0A+        extern const unsigned char movq_to_mem[];=0A+=0A+    =
    asm volatile ( "pcmpeqb %%mm3, %%mm3\n"=0A+                       =
".pushsection .test, \"a\", @progbits\n"=0A+                       =
"movq_to_mem: movq %%mm3, (%0)\n"=0A+                       ".popsection" =
:: "c" (NULL) );=0A+=0A+        memcpy(instr, movq_to_mem, 15);=0A+        =
memset(res, 0x33, 64);=0A+        memset(res + 8, 0xff, 8);=0A+        =
regs.eip    =3D (unsigned long)&instr[0];=0A+        regs.ecx    =3D =
(unsigned long)res;=0A+        rc =3D x86_emulate(&ctxt, &emulops);=0A+    =
    if ( (rc !=3D X86EMUL_OKAY) || memcmp(res, res + 8, 32) )=0A+          =
  goto fail;=0A+        printf("okay\n");=0A+    }=0A+    else=0A+        =
printf("skipped\n");=0A+=0A+    printf("%-40s", "Testing movq (%edx),%mm5..=
.");=0A+    if ( stack_exec && cpu_has_mmx )=0A+    {=0A+        extern =
const unsigned char movq_from_mem[];=0A+=0A+        asm volatile ( =
"pcmpgtb %%mm5, %%mm5\n"=0A+                       ".pushsection .test, =
\"a\", @progbits\n"=0A+                       "movq_from_mem: movq (%0), =
%%mm5\n"=0A+                       ".popsection" :: "d" (NULL) );=0A+=0A+  =
      memcpy(instr, movq_from_mem, 15);=0A+        regs.eip    =3D =
(unsigned long)&instr[0];=0A+        regs.ecx    =3D 0;=0A+        =
regs.edx    =3D (unsigned long)res;=0A+        rc =3D x86_emulate(&ctxt, =
&emulops);=0A+        if ( rc !=3D X86EMUL_OKAY )=0A+            goto =
fail;=0A+        asm ( "pcmpeqb %%mm3, %%mm3\n\t"=0A+              =
"pcmpeqb %%mm5, %%mm3\n\t"=0A+              "pmovmskb %%mm3, %0" : "=3Dr" =
(rc) );=0A+        if ( rc !=3D 0xff )=0A+            goto fail;=0A+       =
 printf("okay\n");=0A+    }=0A+    else=0A+        printf("skipped\n");=0A+=
=0A+    printf("%-40s", "Testing movdqu %xmm2,(%ecx)...");=0A+    if ( =
stack_exec && cpu_has_sse2 )=0A+    {=0A+        extern const unsigned =
char movdqu_to_mem[];=0A+=0A+        asm volatile ( "pcmpeqb %%xmm2, =
%%xmm2\n"=0A+                       ".pushsection .test, \"a\", @progbits\n=
"=0A+                       "movdqu_to_mem: movdqu %%xmm2, (%0)\n"=0A+     =
                  ".popsection" :: "c" (NULL) );=0A+=0A+        memcpy(inst=
r, movdqu_to_mem, 15);=0A+        memset(res, 0x55, 64);=0A+        =
memset(res + 8, 0xff, 16);=0A+        regs.eip    =3D (unsigned long)&instr=
[0];=0A+        regs.ecx    =3D (unsigned long)res;=0A+        rc =3D =
x86_emulate(&ctxt, &emulops);=0A+        if ( (rc !=3D X86EMUL_OKAY) || =
memcmp(res, res + 8, 32) )=0A+            goto fail;=0A+        printf("oka=
y\n");=0A+    }=0A+    else=0A+        printf("skipped\n");=0A+=0A+    =
printf("%-40s", "Testing movdqu (%edx),%xmm4...");=0A+    if ( stack_exec =
&& cpu_has_sse2 )=0A+    {=0A+        extern const unsigned char movdqu_fro=
m_mem[];=0A+=0A+        asm volatile ( "pcmpgtb %%xmm4, %%xmm4\n"=0A+      =
                 ".pushsection .test, \"a\", @progbits\n"=0A+              =
         "movdqu_from_mem: movdqu (%0), %%xmm4\n"=0A+                      =
 ".popsection" :: "d" (NULL) );=0A+=0A+        memcpy(instr, movdqu_from_me=
m, 15);=0A+        regs.eip    =3D (unsigned long)&instr[0];=0A+        =
regs.ecx    =3D 0;=0A+        regs.edx    =3D (unsigned long)res;=0A+      =
  rc =3D x86_emulate(&ctxt, &emulops);=0A+        if ( rc !=3D X86EMUL_OKAY=
 )=0A+            goto fail;=0A+        asm ( "pcmpeqb %%xmm2, %%xmm2\n\t"=
=0A+              "pcmpeqb %%xmm4, %%xmm2\n\t"=0A+              "pmovmskb =
%%xmm2, %0" : "=3Dr" (rc) );=0A+        if ( rc !=3D 0xffff )=0A+          =
  goto fail;=0A+        printf("okay\n");=0A+    }=0A+    else=0A+        =
printf("skipped\n");=0A+=0A     for ( j =3D 1; j <=3D 2; j++ )=0A     {=0A =
#if defined(__i386__)=0A--- a/xen/arch/x86/hvm/emulate.c=0A+++ b/xen/arch/x=
86/hvm/emulate.c=0A@@ -16,6 +16,7 @@=0A #include <xen/paging.h>=0A =
#include <xen/trace.h>=0A #include <asm/event.h>=0A+#include <asm/xstate.h>=
=0A #include <asm/hvm/emulate.h>=0A #include <asm/hvm/hvm.h>=0A #include =
<asm/hvm/trace.h>=0A@@ -928,6 +929,20 @@ static int hvmemul_get_fpu(=0A    =
     if ( !cpu_has_mmx )=0A             return X86EMUL_UNHANDLEABLE;=0A    =
     break;=0A+    case X86EMUL_FPU_xmm:=0A+        if ( !cpu_has_xmm =
||=0A+             (curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_EM) ||=0A+   =
          !(curr->arch.hvm_vcpu.guest_cr[4] & X86_CR4_OSFXSR) )=0A+        =
    return X86EMUL_UNHANDLEABLE;=0A+        break;=0A+    case X86EMUL_FPU_=
ymm:=0A+        if ( !(curr->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) =
||=0A+             vm86_mode(ctxt->regs) ||=0A+             !(curr->arch.hv=
m_vcpu.guest_cr[4] & X86_CR4_OSXSAVE) ||=0A+             !(curr->arch.xcr0 =
& XSTATE_SSE) ||=0A+             !(curr->arch.xcr0 & XSTATE_YMM) )=0A+     =
       return X86EMUL_UNHANDLEABLE;=0A+        break;=0A     default:=0A   =
      return X86EMUL_UNHANDLEABLE;=0A     }=0A--- a/xen/arch/x86/x86_emulat=
e/x86_emulate.c=0A+++ b/xen/arch/x86/x86_emulate/x86_emulate.c=0A@@ =
-248,11 +248,52 @@ static uint8_t twobyte_table[256] =3D {=0A     /* 0xD0 =
- 0xDF */=0A     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,=0A     /* =
0xE0 - 0xEF */=0A-    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,=0A+  =
  0, 0, 0, 0, 0, 0, 0, ImplicitOps|ModRM, 0, 0, 0, 0, 0, 0, 0, 0,=0A     =
/* 0xF0 - 0xFF */=0A     0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0=0A =
};=0A =0A+#define REX_PREFIX 0x40=0A+#define REX_B 0x01=0A+#define REX_X =
0x02=0A+#define REX_R 0x04=0A+#define REX_W 0x08=0A+=0A+#define vex_none =
0=0A+=0A+enum vex_opcx {=0A+    vex_0f =3D vex_none + 1,=0A+    =
vex_0f38,=0A+    vex_0f3a,=0A+};=0A+=0A+enum vex_pfx {=0A+    vex_66 =3D =
vex_none + 1,=0A+    vex_f3,=0A+    vex_f2=0A+};=0A+=0A+union vex {=0A+    =
uint8_t raw[2];=0A+    struct {=0A+        uint8_t opcx:5;=0A+        =
uint8_t b:1;=0A+        uint8_t x:1;=0A+        uint8_t r:1;=0A+        =
uint8_t pfx:2;=0A+        uint8_t l:1;=0A+        uint8_t reg:4;=0A+       =
 uint8_t w:1;=0A+    };=0A+};=0A+=0A+#define copy_REX_VEX(ptr, rex, vex) =
do { \=0A+    if ( (vex).opcx !=3D vex_none ) \=0A+        ptr[0] =3D =
0xc4, ptr[1] =3D (vex).raw[0], ptr[2] =3D (vex).raw[1]; \=0A+    else if ( =
mode_64bit() ) \=0A+        ptr[1] =3D rex | REX_PREFIX; \=0A+} while =
(0)=0A+=0A /* Type, address-of, and value of an instruction's operand. =
*/=0A struct operand {=0A     enum { OP_REG, OP_MEM, OP_IMM, OP_NONE } =
type;=0A@@ -281,6 +322,23 @@ struct operand {=0A     };=0A };=0A =0A+typede=
f union {=0A+    uint64_t mmx;=0A+    uint64_t __attribute__ ((aligned(16))=
) xmm[2];=0A+    uint64_t __attribute__ ((aligned(32))) ymm[4];=0A+} =
mmval_t;=0A+=0A+/*=0A+ * While proper alignment gets specified above, this =
doesn't get honored by=0A+ * the compiler for automatic variables. Use =
this helper to instantiate a=0A+ * suitably aligned variable, producing a =
pointer to access it.=0A+ */=0A+#define DECLARE_ALIGNED(type, var)         =
                          \=0A+    long __##var[sizeof(type) + __alignof(ty=
pe) - __alignof(long)];  \=0A+    type *const var##p =3D                   =
                          \=0A+        (void *)((long)(__##var + __alignof(=
type) - __alignof(long)) \=0A+                 & -__alignof(type))=0A+=0A =
/* MSRs. */=0A #define MSR_TSC          0x00000010=0A #define MSR_SYSENTER_=
CS  0x00000174=0A@@ -992,9 +1050,12 @@ static bool_t vcpu_has(=0A =0A =
#define vcpu_must_have(leaf, reg, bit) \=0A     generate_exception_if(!vcpu=
_has(leaf, reg, bit, ctxt, ops), EXC_UD, -1)=0A+#define vcpu_must_have_mmx(=
)  vcpu_must_have(0x00000001, EDX, 23)=0A+#define vcpu_must_have_sse()  =
vcpu_must_have(0x00000001, EDX, 25)=0A #define vcpu_must_have_sse2() =
vcpu_must_have(0x00000001, EDX, 26)=0A #define vcpu_must_have_sse3() =
vcpu_must_have(0x00000001, ECX,  0)=0A #define vcpu_must_have_cx16() =
vcpu_must_have(0x00000001, ECX, 13)=0A+#define vcpu_must_have_avx()  =
vcpu_must_have(0x00000001, ECX, 28)=0A =0A static int=0A in_longmode(=0A@@ =
-1252,13 +1313,14 @@ x86_emulate(=0A =0A     uint8_t b, d, sib, sib_index, =
sib_base, twobyte =3D 0, rex_prefix =3D 0;=0A     uint8_t modrm =3D 0, =
modrm_mod =3D 0, modrm_reg =3D 0, modrm_rm =3D 0;=0A+    union vex vex =3D =
{};=0A     unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes;=0A =
#define REPE_PREFIX  1=0A #define REPNE_PREFIX 2=0A     unsigned int =
lock_prefix =3D 0, rep_prefix =3D 0;=0A     int override_seg =3D -1, rc =
=3D X86EMUL_OKAY;=0A     struct operand src, dst;=0A-=0A+    DECLARE_ALIGNE=
D(mmval_t, mmval);=0A     /*=0A      * Data operand effective address =
(usually computed from ModRM).=0A      * Default is a memory operand =
relative to segment DS.=0A@@ -1284,6 +1346,7 @@ x86_emulate(=0A         =
{=0A         case 0x66: /* operand-size override */=0A             =
op_bytes =3D def_op_bytes ^ 6;=0A+            vex.pfx =3D vex_66;=0A       =
      break;=0A         case 0x67: /* address-size override */=0A          =
   ad_bytes =3D def_ad_bytes ^ (mode_64bit() ? 12 : 6);=0A@@ -1311,9 =
+1374,11 @@ x86_emulate(=0A             break;=0A         case 0xf2: /* =
REPNE/REPNZ */=0A             rep_prefix =3D REPNE_PREFIX;=0A+            =
vex.pfx =3D vex_f2;=0A             break;=0A         case 0xf3: /* =
REP/REPE/REPZ */=0A             rep_prefix =3D REPE_PREFIX;=0A+            =
vex.pfx =3D vex_f3;=0A             break;=0A         case 0x40 ... 0x4f: =
/* REX */=0A             if ( !mode_64bit() )=0A@@ -1357,6 +1422,70 @@ =
x86_emulate(=0A     {=0A         modrm =3D insn_fetch_type(uint8_t);=0A    =
     modrm_mod =3D (modrm & 0xc0) >> 6;=0A+=0A+        if ( !twobyte && =
((b & ~1) =3D=3D 0xc4) )=0A+            switch ( def_ad_bytes )=0A+        =
    {=0A+            default:=0A+                BUG();=0A+            =
case 2:=0A+                if ( in_realmode(ctxt, ops) || (_regs.eflags & =
EFLG_VM) )=0A+                    break;=0A+                /* fall =
through */=0A+            case 4:=0A+                if ( modrm_mod !=3D 3 =
)=0A+                    break;=0A+                /* fall through */=0A+  =
          case 8:=0A+                /* VEX */=0A+                =
generate_exception_if(rex_prefix || vex.pfx, EXC_UD, -1);=0A+=0A+          =
      vex.raw[0] =3D b;=0A+                if ( b & 1 )=0A+                =
{=0A+                    vex.raw[1] =3D b;=0A+                    vex.opcx =
=3D vex_0f;=0A+                    vex.x =3D 1;=0A+                    =
vex.b =3D 1;=0A+                    vex.w =3D 0;=0A+                }=0A+  =
              else=0A+                {=0A+                    vex.raw[1] =
=3D insn_fetch_type(uint8_t);=0A+                    if ( mode_64bit() =
)=0A+                    {=0A+                        if ( !vex.b )=0A+    =
                        rex_prefix |=3D REX_B;=0A+                        =
if ( !vex.x )=0A+                            rex_prefix |=3D REX_X;=0A+    =
                    if ( vex.w )=0A+                        {=0A+          =
                  rex_prefix |=3D REX_W;=0A+                            =
op_bytes =3D 8;=0A+                        }=0A+                    }=0A+  =
              }=0A+                vex.reg ^=3D 0xf;=0A+                if =
( !mode_64bit() )=0A+                    vex.reg &=3D 0x7;=0A+             =
   else if ( !vex.r )=0A+                    rex_prefix |=3D REX_R;=0A+=0A+=
                fail_if(vex.opcx !=3D vex_0f);=0A+                twobyte =
=3D 1;=0A+                b =3D insn_fetch_type(uint8_t);=0A+              =
  d =3D twobyte_table[b];=0A+=0A+                /* Unrecognised? */=0A+   =
             if ( d =3D=3D 0 )=0A+                    goto cannot_emulate;=
=0A+=0A+                modrm =3D insn_fetch_type(uint8_t);=0A+            =
    modrm_mod =3D (modrm & 0xc0) >> 6;=0A+=0A+                break;=0A+   =
         }=0A+=0A         modrm_reg =3D ((rex_prefix & 4) << 1) | ((modrm =
& 0x38) >> 3);=0A         modrm_rm  =3D modrm & 0x07;=0A =0A@@ -3914,44 =
+4043,78 @@ x86_emulate(=0A         break;=0A     }=0A =0A-    case 0x6f: =
/* movq mm/m64,mm */ {=0A-        uint8_t stub[] =3D { 0x0f, 0x6f, modrm, =
0xc3 };=0A+    case 0xe7: /* movntq mm,m64 */=0A+               /* =
{,v}movntdq xmm,m128 */=0A+               /* vmovntdq ymm,m256 */=0A+      =
  fail_if(ea.type !=3D OP_MEM);=0A+        fail_if(vex.pfx =3D=3D =
vex_f3);=0A+        /* fall through */=0A+    case 0x6f: /* movq mm/m64,mm =
*/=0A+               /* {,v}movdq{a,u} xmm/m128,xmm */=0A+               =
/* vmovdq{a,u} ymm/m256,ymm */=0A+    case 0x7f: /* movq mm,mm/m64 */=0A+  =
             /* {,v}movdq{a,u} xmm,xmm/m128 */=0A+               /* =
vmovdq{a,u} ymm,ymm/m256 */=0A+    {=0A+        uint8_t stub[] =3D { 0x3e, =
0x3e, 0x0f, b, modrm, 0xc3 };=0A         struct fpu_insn_ctxt fic =3D { =
.insn_bytes =3D sizeof(stub)-1 };=0A-        uint64_t val;=0A-        if ( =
ea.type =3D=3D OP_MEM )=0A+=0A+        if ( vex.opcx =3D=3D vex_none )=0A  =
       {=0A-            unsigned long lval, hval;=0A-            if ( (rc =
=3D read_ulong(ea.mem.seg, ea.mem.off+0,=0A-                               =
   &lval, 4, ctxt, ops)) ||=0A-                 (rc =3D read_ulong(ea.mem.s=
eg, ea.mem.off+4,=0A-                                  &hval, 4, ctxt, =
ops)) )=0A-                goto done;=0A-            val =3D ((uint64_t)hva=
l << 32) | (uint32_t)lval;=0A-            stub[2] =3D modrm & 0x38; /* =
movq (%eax),%mmN */=0A+            switch ( vex.pfx )=0A+            {=0A+ =
           case vex_66:=0A+            case vex_f3:=0A+                =
vcpu_must_have_sse2();=0A+                stub[0] =3D 0x66; /* movdqa =
*/=0A+                get_fpu(X86EMUL_FPU_xmm, &fic);=0A+                =
ea.bytes =3D 16;=0A+                break;=0A+            case vex_none:=0A=
+                if ( b !=3D 0xe7 )=0A+                    vcpu_must_have_m=
mx();=0A+                else=0A+                    vcpu_must_have_sse();=
=0A+                get_fpu(X86EMUL_FPU_mmx, &fic);=0A+                =
ea.bytes =3D 8;=0A+                break;=0A+            default:=0A+      =
          goto cannot_emulate;=0A+            }=0A+        }=0A+        =
else=0A+        {=0A+            fail_if((vex.opcx !=3D vex_0f) || vex.reg =
||=0A+                    ((vex.pfx !=3D vex_66) && (vex.pfx !=3D =
vex_f3)));=0A+            vcpu_must_have_avx();=0A+            get_fpu(X86E=
MUL_FPU_ymm, &fic);=0A+            ea.bytes =3D 16 << vex.l;=0A         =
}=0A-        get_fpu(X86EMUL_FPU_mmx, &fic);=0A-        asm volatile ( =
"call *%0" : : "r" (stub), "a" (&val) : "memory" );=0A-        put_fpu(&fic=
);=0A-        break;=0A-    }=0A-=0A-    case 0x7f: /* movq mm,mm/m64 */ =
{=0A-        uint8_t stub[] =3D { 0x0f, 0x7f, modrm, 0xc3 };=0A-        =
struct fpu_insn_ctxt fic =3D { .insn_bytes =3D sizeof(stub)-1 };=0A-       =
 uint64_t val;=0A-        if ( ea.type =3D=3D OP_MEM )=0A-            =
stub[2] =3D modrm & 0x38; /* movq %mmN,(%eax) */=0A-        get_fpu(X86EMUL=
_FPU_mmx, &fic);=0A-        asm volatile ( "call *%0" : : "r" (stub), "a" =
(&val) : "memory" );=0A-        put_fpu(&fic);=0A         if ( ea.type =
=3D=3D OP_MEM )=0A         {=0A-            unsigned long lval =3D =
(uint32_t)val, hval =3D (uint32_t)(val >> 32);=0A-            if ( (rc =3D =
ops->write(ea.mem.seg, ea.mem.off+0, &lval, 4, ctxt)) ||=0A-               =
  (rc =3D ops->write(ea.mem.seg, ea.mem.off+4, &hval, 4, ctxt)) )=0A-      =
          goto done;=0A+            /* XXX enable once there is ops->ea() =
or equivalent=0A+            generate_exception_if((vex.pfx =3D=3D vex_66) =
&&=0A+                                  (ops->ea(ea.mem.seg, ea.mem.off)=0A=
+                                   & (ea.bytes - 1)), EXC_GP, 0); */=0A+  =
          if ( b =3D=3D 0x6f )=0A+                rc =3D ops->read(ea.mem.s=
eg, ea.mem.off+0, mmvalp,=0A+                               ea.bytes, =
ctxt);=0A+            /* convert memory operand to (%rAX) */=0A+           =
 rex_prefix &=3D ~REX_B;=0A+            vex.b =3D 1;=0A+            =
stub[4] &=3D 0x38;=0A+        }=0A+        if ( !rc )=0A+        {=0A+     =
      copy_REX_VEX(stub, rex_prefix, vex);=0A+           asm volatile ( =
"call *%0" : : "r" (stub), "a" (mmvalp)=0A+                                =
     : "memory" );=0A         }=0A-        break;=0A+        put_fpu(&fic);=
=0A+        if ( !rc && (b !=3D 0x6f) && (ea.type =3D=3D OP_MEM) )=0A+     =
       rc =3D ops->write(ea.mem.seg, ea.mem.off, mmvalp,=0A+               =
             ea.bytes, ctxt);=0A+        goto done;=0A     }=0A =0A     =
case 0x80 ... 0x8f: /* jcc (near) */ {=0A--- a/xen/arch/x86/x86_emulate/x86=
_emulate.h=0A+++ b/xen/arch/x86/x86_emulate/x86_emulate.h=0A@@ -99,7 +99,9 =
@@ struct segment_register {=0A /* FPU sub-types which may be requested =
via ->get_fpu(). */=0A enum x86_emulate_fpu_type {=0A     X86EMUL_FPU_fpu, =
/* Standard FPU coprocessor instruction set */=0A-    X86EMUL_FPU_mmx  /* =
MMX instruction set (%mm0-%mm7) */=0A+    X86EMUL_FPU_mmx, /* MMX =
instruction set (%mm0-%mm7) */=0A+    X86EMUL_FPU_xmm, /* SSE instruction =
set (%xmm0-%xmm7/15) */=0A+    X86EMUL_FPU_ymm  /* AVX/XOP instruction set =
(%ymm0-%ymm7/15) */=0A };=0A =0A /*=0A--- a/xen/include/asm-x86/cpufeature.=
h=0A+++ b/xen/include/asm-x86/cpufeature.h=0A@@ -218,7 +218,7 @@=0A =
#define cpu_has_x2apic          boot_cpu_has(X86_FEATURE_X2APIC)=0A =0A =
#define cpu_has_xsave           boot_cpu_has(X86_FEATURE_XSAVE)=0A-=0A+#def=
ine cpu_has_avx             boot_cpu_has(X86_FEATURE_AVX)=0A #define =
cpu_has_lwp             boot_cpu_has(X86_FEATURE_LWP)=0A =0A #define =
cpu_has_arch_perfmon    boot_cpu_has(X86_FEATURE_ARCH_PERFMON)=0A
--=__PartFFD06A5B.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartFFD06A5B.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:07:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmh3-0004P2-8M; Wed, 30 Nov 2011 16:07:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmh2-0004OQ-5N
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:07:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322669213!5632609!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13944 invoked from network); 30 Nov 2011 16:06:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:06:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:06:53 +0000
Message-Id: <4ED662AC020000780006467B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:06:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2807BD8C.0__="
Subject: [Xen-devel] [PATCH 3/4] x86/emulator: properly handle lzcnt and
	tzcnt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part2807BD8C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

These instructions are prefix selected flavors of bsf and bsr
respectively, and hence the presences of the F3 prefix must be handled
in the emulation code in order to avoid running into problems on newer
CPUs.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1058,6 +1058,9 @@ static bool_t vcpu_has(
     return rc =3D=3D X86EMUL_OKAY;
 }
=20
+#define vcpu_has_lzcnt() vcpu_has(0x80000001, ECX,  5, ctxt, ops)
+#define vcpu_has_bmi1()  vcpu_has(0x00000007, EBX,  3, ctxt, ops)
+
 #define vcpu_must_have(leaf, reg, bit) \
     generate_exception_if(!vcpu_has(leaf, reg, bit, ctxt, ops), EXC_UD, =
-1)
 #define vcpu_must_have_mmx()  vcpu_must_have(0x00000001, EDX, 23)
@@ -4357,13 +4360,24 @@ x86_emulate(
         dst.val   =3D (uint8_t)src.val;
         break;
=20
-    case 0xbc: /* bsf */ {
-        int zf;
+    case 0xbc: /* bsf or tzcnt */ {
+        bool_t zf;
         asm ( "bsf %2,%0; setz %b1"
               : "=3Dr" (dst.val), "=3Dq" (zf)
-              : "r" (src.val), "1" (0) );
+              : "r" (src.val) );
         _regs.eflags &=3D ~EFLG_ZF;
-        if ( zf )
+        if ( (rep_prefix =3D=3D REPE_PREFIX) && vcpu_has_bmi1() )
+        {
+            _regs.eflags &=3D ~EFLG_CF;
+            if ( zf )
+            {
+                _regs.eflags |=3D EFLG_CF;
+                dst.val =3D op_bytes * 8;
+            }
+            else if ( !dst.val )
+                _regs.eflags |=3D EFLG_ZF;
+        }
+        else if ( zf )
         {
             _regs.eflags |=3D EFLG_ZF;
             dst.type =3D OP_NONE;
@@ -4371,13 +4385,28 @@ x86_emulate(
         break;
     }
=20
-    case 0xbd: /* bsr */ {
-        int zf;
+    case 0xbd: /* bsr or lzcnt */ {
+        bool_t zf;
         asm ( "bsr %2,%0; setz %b1"
               : "=3Dr" (dst.val), "=3Dq" (zf)
-              : "r" (src.val), "1" (0) );
+              : "r" (src.val) );
         _regs.eflags &=3D ~EFLG_ZF;
-        if ( zf )
+        if ( (rep_prefix =3D=3D REPE_PREFIX) && vcpu_has_lzcnt() )
+        {
+            _regs.eflags &=3D ~EFLG_CF;
+            if ( zf )
+            {
+                _regs.eflags |=3D EFLG_CF;
+                dst.val =3D op_bytes * 8;
+            }
+            else
+            {
+                dst.val =3D op_bytes * 8 - 1 - dst.val;
+                if ( !dst.val )
+                    _regs.eflags |=3D EFLG_ZF;
+            }
+        }
+        else if ( zf )
         {
             _regs.eflags |=3D EFLG_ZF;
             dst.type =3D OP_NONE;




--=__Part2807BD8C.0__=
Content-Type: text/plain; name="x86-emul-lzcnt.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-emul-lzcnt.patch"

x86/emulator: properly handle lzcnt and tzcnt=0A=0AThese instructions are =
prefix selected flavors of bsf and bsr=0Arespectively, and hence the =
presences of the F3 prefix must be handled=0Ain the emulation code in =
order to avoid running into problems on newer=0ACPUs.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/x86_emulate/x86_emu=
late.c=0A+++ b/xen/arch/x86/x86_emulate/x86_emulate.c=0A@@ -1058,6 +1058,9 =
@@ static bool_t vcpu_has(=0A     return rc =3D=3D X86EMUL_OKAY;=0A }=0A =
=0A+#define vcpu_has_lzcnt() vcpu_has(0x80000001, ECX,  5, ctxt, ops)=0A+#d=
efine vcpu_has_bmi1()  vcpu_has(0x00000007, EBX,  3, ctxt, ops)=0A+=0A =
#define vcpu_must_have(leaf, reg, bit) \=0A     generate_exception_if(!vcpu=
_has(leaf, reg, bit, ctxt, ops), EXC_UD, -1)=0A #define vcpu_must_have_mmx(=
)  vcpu_must_have(0x00000001, EDX, 23)=0A@@ -4357,13 +4360,24 @@ x86_emulat=
e(=0A         dst.val   =3D (uint8_t)src.val;=0A         break;=0A =0A-    =
case 0xbc: /* bsf */ {=0A-        int zf;=0A+    case 0xbc: /* bsf or =
tzcnt */ {=0A+        bool_t zf;=0A         asm ( "bsf %2,%0; setz %b1"=0A =
              : "=3Dr" (dst.val), "=3Dq" (zf)=0A-              : "r" =
(src.val), "1" (0) );=0A+              : "r" (src.val) );=0A         =
_regs.eflags &=3D ~EFLG_ZF;=0A-        if ( zf )=0A+        if ( (rep_prefi=
x =3D=3D REPE_PREFIX) && vcpu_has_bmi1() )=0A+        {=0A+            =
_regs.eflags &=3D ~EFLG_CF;=0A+            if ( zf )=0A+            {=0A+  =
              _regs.eflags |=3D EFLG_CF;=0A+                dst.val =3D =
op_bytes * 8;=0A+            }=0A+            else if ( !dst.val )=0A+     =
           _regs.eflags |=3D EFLG_ZF;=0A+        }=0A+        else if ( zf =
)=0A         {=0A             _regs.eflags |=3D EFLG_ZF;=0A             =
dst.type =3D OP_NONE;=0A@@ -4371,13 +4385,28 @@ x86_emulate(=0A         =
break;=0A     }=0A =0A-    case 0xbd: /* bsr */ {=0A-        int zf;=0A+   =
 case 0xbd: /* bsr or lzcnt */ {=0A+        bool_t zf;=0A         asm ( =
"bsr %2,%0; setz %b1"=0A               : "=3Dr" (dst.val), "=3Dq" (zf)=0A- =
             : "r" (src.val), "1" (0) );=0A+              : "r" (src.val) =
);=0A         _regs.eflags &=3D ~EFLG_ZF;=0A-        if ( zf )=0A+        =
if ( (rep_prefix =3D=3D REPE_PREFIX) && vcpu_has_lzcnt() )=0A+        =
{=0A+            _regs.eflags &=3D ~EFLG_CF;=0A+            if ( zf )=0A+  =
          {=0A+                _regs.eflags |=3D EFLG_CF;=0A+              =
  dst.val =3D op_bytes * 8;=0A+            }=0A+            else=0A+       =
     {=0A+                dst.val =3D op_bytes * 8 - 1 - dst.val;=0A+      =
          if ( !dst.val )=0A+                    _regs.eflags |=3D =
EFLG_ZF;=0A+            }=0A+        }=0A+        else if ( zf )=0A        =
 {=0A             _regs.eflags |=3D EFLG_ZF;=0A             dst.type =3D =
OP_NONE;=0A
--=__Part2807BD8C.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part2807BD8C.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:07:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmh3-0004P2-8M; Wed, 30 Nov 2011 16:07:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmh2-0004OQ-5N
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:07:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1322669213!5632609!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13944 invoked from network); 30 Nov 2011 16:06:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:06:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:06:53 +0000
Message-Id: <4ED662AC020000780006467B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:06:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2807BD8C.0__="
Subject: [Xen-devel] [PATCH 3/4] x86/emulator: properly handle lzcnt and
	tzcnt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part2807BD8C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

These instructions are prefix selected flavors of bsf and bsr
respectively, and hence the presences of the F3 prefix must be handled
in the emulation code in order to avoid running into problems on newer
CPUs.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1058,6 +1058,9 @@ static bool_t vcpu_has(
     return rc =3D=3D X86EMUL_OKAY;
 }
=20
+#define vcpu_has_lzcnt() vcpu_has(0x80000001, ECX,  5, ctxt, ops)
+#define vcpu_has_bmi1()  vcpu_has(0x00000007, EBX,  3, ctxt, ops)
+
 #define vcpu_must_have(leaf, reg, bit) \
     generate_exception_if(!vcpu_has(leaf, reg, bit, ctxt, ops), EXC_UD, =
-1)
 #define vcpu_must_have_mmx()  vcpu_must_have(0x00000001, EDX, 23)
@@ -4357,13 +4360,24 @@ x86_emulate(
         dst.val   =3D (uint8_t)src.val;
         break;
=20
-    case 0xbc: /* bsf */ {
-        int zf;
+    case 0xbc: /* bsf or tzcnt */ {
+        bool_t zf;
         asm ( "bsf %2,%0; setz %b1"
               : "=3Dr" (dst.val), "=3Dq" (zf)
-              : "r" (src.val), "1" (0) );
+              : "r" (src.val) );
         _regs.eflags &=3D ~EFLG_ZF;
-        if ( zf )
+        if ( (rep_prefix =3D=3D REPE_PREFIX) && vcpu_has_bmi1() )
+        {
+            _regs.eflags &=3D ~EFLG_CF;
+            if ( zf )
+            {
+                _regs.eflags |=3D EFLG_CF;
+                dst.val =3D op_bytes * 8;
+            }
+            else if ( !dst.val )
+                _regs.eflags |=3D EFLG_ZF;
+        }
+        else if ( zf )
         {
             _regs.eflags |=3D EFLG_ZF;
             dst.type =3D OP_NONE;
@@ -4371,13 +4385,28 @@ x86_emulate(
         break;
     }
=20
-    case 0xbd: /* bsr */ {
-        int zf;
+    case 0xbd: /* bsr or lzcnt */ {
+        bool_t zf;
         asm ( "bsr %2,%0; setz %b1"
               : "=3Dr" (dst.val), "=3Dq" (zf)
-              : "r" (src.val), "1" (0) );
+              : "r" (src.val) );
         _regs.eflags &=3D ~EFLG_ZF;
-        if ( zf )
+        if ( (rep_prefix =3D=3D REPE_PREFIX) && vcpu_has_lzcnt() )
+        {
+            _regs.eflags &=3D ~EFLG_CF;
+            if ( zf )
+            {
+                _regs.eflags |=3D EFLG_CF;
+                dst.val =3D op_bytes * 8;
+            }
+            else
+            {
+                dst.val =3D op_bytes * 8 - 1 - dst.val;
+                if ( !dst.val )
+                    _regs.eflags |=3D EFLG_ZF;
+            }
+        }
+        else if ( zf )
         {
             _regs.eflags |=3D EFLG_ZF;
             dst.type =3D OP_NONE;




--=__Part2807BD8C.0__=
Content-Type: text/plain; name="x86-emul-lzcnt.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-emul-lzcnt.patch"

x86/emulator: properly handle lzcnt and tzcnt=0A=0AThese instructions are =
prefix selected flavors of bsf and bsr=0Arespectively, and hence the =
presences of the F3 prefix must be handled=0Ain the emulation code in =
order to avoid running into problems on newer=0ACPUs.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/x86_emulate/x86_emu=
late.c=0A+++ b/xen/arch/x86/x86_emulate/x86_emulate.c=0A@@ -1058,6 +1058,9 =
@@ static bool_t vcpu_has(=0A     return rc =3D=3D X86EMUL_OKAY;=0A }=0A =
=0A+#define vcpu_has_lzcnt() vcpu_has(0x80000001, ECX,  5, ctxt, ops)=0A+#d=
efine vcpu_has_bmi1()  vcpu_has(0x00000007, EBX,  3, ctxt, ops)=0A+=0A =
#define vcpu_must_have(leaf, reg, bit) \=0A     generate_exception_if(!vcpu=
_has(leaf, reg, bit, ctxt, ops), EXC_UD, -1)=0A #define vcpu_must_have_mmx(=
)  vcpu_must_have(0x00000001, EDX, 23)=0A@@ -4357,13 +4360,24 @@ x86_emulat=
e(=0A         dst.val   =3D (uint8_t)src.val;=0A         break;=0A =0A-    =
case 0xbc: /* bsf */ {=0A-        int zf;=0A+    case 0xbc: /* bsf or =
tzcnt */ {=0A+        bool_t zf;=0A         asm ( "bsf %2,%0; setz %b1"=0A =
              : "=3Dr" (dst.val), "=3Dq" (zf)=0A-              : "r" =
(src.val), "1" (0) );=0A+              : "r" (src.val) );=0A         =
_regs.eflags &=3D ~EFLG_ZF;=0A-        if ( zf )=0A+        if ( (rep_prefi=
x =3D=3D REPE_PREFIX) && vcpu_has_bmi1() )=0A+        {=0A+            =
_regs.eflags &=3D ~EFLG_CF;=0A+            if ( zf )=0A+            {=0A+  =
              _regs.eflags |=3D EFLG_CF;=0A+                dst.val =3D =
op_bytes * 8;=0A+            }=0A+            else if ( !dst.val )=0A+     =
           _regs.eflags |=3D EFLG_ZF;=0A+        }=0A+        else if ( zf =
)=0A         {=0A             _regs.eflags |=3D EFLG_ZF;=0A             =
dst.type =3D OP_NONE;=0A@@ -4371,13 +4385,28 @@ x86_emulate(=0A         =
break;=0A     }=0A =0A-    case 0xbd: /* bsr */ {=0A-        int zf;=0A+   =
 case 0xbd: /* bsr or lzcnt */ {=0A+        bool_t zf;=0A         asm ( =
"bsr %2,%0; setz %b1"=0A               : "=3Dr" (dst.val), "=3Dq" (zf)=0A- =
             : "r" (src.val), "1" (0) );=0A+              : "r" (src.val) =
);=0A         _regs.eflags &=3D ~EFLG_ZF;=0A-        if ( zf )=0A+        =
if ( (rep_prefix =3D=3D REPE_PREFIX) && vcpu_has_lzcnt() )=0A+        =
{=0A+            _regs.eflags &=3D ~EFLG_CF;=0A+            if ( zf )=0A+  =
          {=0A+                _regs.eflags |=3D EFLG_CF;=0A+              =
  dst.val =3D op_bytes * 8;=0A+            }=0A+            else=0A+       =
     {=0A+                dst.val =3D op_bytes * 8 - 1 - dst.val;=0A+      =
          if ( !dst.val )=0A+                    _regs.eflags |=3D =
EFLG_ZF;=0A+            }=0A+        }=0A+        else if ( zf )=0A        =
 {=0A             _regs.eflags |=3D EFLG_ZF;=0A             dst.type =3D =
OP_NONE;=0A
--=__Part2807BD8C.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part2807BD8C.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:08:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmhb-0004Uj-Oe; Wed, 30 Nov 2011 16:08:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmha-0004Tu-BT
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:08:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322669247!5656481!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23587 invoked from network); 30 Nov 2011 16:07:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:07:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:07:27 +0000
Message-Id: <4ED662CD020000780006468F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:07:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part09269CAD.0__="
Subject: [Xen-devel] [PATCH 4/4] x86/emulator: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part09269CAD.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Utilize some of the additions in the prior patches to clean up other
code:
- keep track of REP prefixes in only one variable
- use REX_W in a few more places (instead of a literal number)

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -304,6 +304,10 @@ union vex {
         ptr[1] =3D rex | REX_PREFIX; \
 } while (0)
=20
+#define rep_prefix()   (vex.pfx >=3D vex_f3)
+#define repe_prefix()  (vex.pfx =3D=3D vex_f3)
+#define repne_prefix() (vex.pfx =3D=3D vex_f2)
+
 /* Type, address-of, and value of an instruction's operand. */
 struct operand {
     enum { OP_REG, OP_MEM, OP_IMM, OP_NONE } type;
@@ -734,7 +738,7 @@ static unsigned long __get_rep_prefix(
=20
 #define get_rep_prefix() ({                                             \
     unsigned long max_reps =3D 1;                                         =
\
-    if ( rep_prefix )                                                   \
+    if ( rep_prefix() )                                                 \
         max_reps =3D __get_rep_prefix(&_regs, ctxt->regs, ad_bytes);      =
\
     if ( max_reps =3D=3D 0 )                                              =
  \
         goto done;                                                      \
@@ -765,7 +769,7 @@ static void __put_rep_prefix(
 }
=20
 #define put_rep_prefix(reps_completed) ({                               \
-    if ( rep_prefix )                                                   \
+    if ( rep_prefix() )                                                 \
         __put_rep_prefix(&_regs, ctxt->regs, ad_bytes, reps_completed); \
 })
=20
@@ -1328,9 +1332,7 @@ x86_emulate(
     uint8_t modrm =3D 0, modrm_mod =3D 0, modrm_reg =3D 0, modrm_rm =3D =
0;
     union vex vex =3D {};
     unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes;
-#define REPE_PREFIX  1
-#define REPNE_PREFIX 2
-    unsigned int lock_prefix =3D 0, rep_prefix =3D 0;
+    bool_t lock_prefix =3D 0;
     int override_seg =3D -1, rc =3D X86EMUL_OKAY;
     struct operand src, dst;
     DECLARE_ALIGNED(mmval_t, mmval);
@@ -1359,7 +1361,8 @@ x86_emulate(
         {
         case 0x66: /* operand-size override */
             op_bytes =3D def_op_bytes ^ 6;
-            vex.pfx =3D vex_66;
+            if ( !vex.pfx )
+                vex.pfx =3D vex_66;
             break;
         case 0x67: /* address-size override */
             ad_bytes =3D def_ad_bytes ^ (mode_64bit() ? 12 : 6);
@@ -1386,11 +1389,9 @@ x86_emulate(
             lock_prefix =3D 1;
             break;
         case 0xf2: /* REPNE/REPNZ */
-            rep_prefix =3D REPNE_PREFIX;
             vex.pfx =3D vex_f2;
             break;
         case 0xf3: /* REP/REPE/REPZ */
-            rep_prefix =3D REPE_PREFIX;
             vex.pfx =3D vex_f3;
             break;
         case 0x40 ... 0x4f: /* REX */
@@ -1407,7 +1408,7 @@ x86_emulate(
     }
  done_prefixes:
=20
-    if ( rex_prefix & 8 ) /* REX.W */
+    if ( rex_prefix & REX_W )
         op_bytes =3D 8;
=20
     /* Opcode byte(s). */
@@ -2418,8 +2419,8 @@ x86_emulate(
         put_rep_prefix(1);
         /* cmp: dst - src =3D=3D> src=3D*%%edi,dst=3D*%%esi =3D=3D> =
*%%esi - *%%edi */
         emulate_2op_SrcV("cmp", src, dst, _regs.eflags);
-        if ( ((rep_prefix =3D=3D REPE_PREFIX) && !(_regs.eflags & =
EFLG_ZF)) ||
-             ((rep_prefix =3D=3D REPNE_PREFIX) && (_regs.eflags & =
EFLG_ZF)) )
+        if ( (repe_prefix() && !(_regs.eflags & EFLG_ZF)) ||
+             (repne_prefix() && (_regs.eflags & EFLG_ZF)) )
             _regs.eip =3D next_eip;
         break;
     }
@@ -2464,8 +2465,8 @@ x86_emulate(
         put_rep_prefix(1);
         /* cmp: dst - src =3D=3D> src=3D*%%edi,dst=3D%%eax =3D=3D> %%eax =
- *%%edi */
         emulate_2op_SrcV("cmp", src, dst, _regs.eflags);
-        if ( ((rep_prefix =3D=3D REPE_PREFIX) && !(_regs.eflags & =
EFLG_ZF)) ||
-             ((rep_prefix =3D=3D REPNE_PREFIX) && (_regs.eflags & =
EFLG_ZF)) )
+        if ( (repe_prefix() && !(_regs.eflags & EFLG_ZF)) ||
+             (repne_prefix() && (_regs.eflags & EFLG_ZF)) )
             _regs.eip =3D next_eip;
         break;
     }
@@ -4076,7 +4077,7 @@ x86_emulate(
     case 0x35: /* sysexit */ {
         uint64_t msr_content;
         struct segment_register cs, ss;
-        int user64 =3D !!(rex_prefix & 8); /* REX.W */
+        bool_t user64 =3D !!(rex_prefix & REX_W);
         int rc;
=20
         generate_exception_if(!mode_ring0(), EXC_GP, 0);
@@ -4366,7 +4367,7 @@ x86_emulate(
               : "=3Dr" (dst.val), "=3Dq" (zf)
               : "r" (src.val) );
         _regs.eflags &=3D ~EFLG_ZF;
-        if ( (rep_prefix =3D=3D REPE_PREFIX) && vcpu_has_bmi1() )
+        if ( (vex.pfx =3D=3D vex_f3) && vcpu_has_bmi1() )
         {
             _regs.eflags &=3D ~EFLG_CF;
             if ( zf )
@@ -4391,7 +4392,7 @@ x86_emulate(
               : "=3Dr" (dst.val), "=3Dq" (zf)
               : "r" (src.val) );
         _regs.eflags &=3D ~EFLG_ZF;
-        if ( (rep_prefix =3D=3D REPE_PREFIX) && vcpu_has_lzcnt() )
+        if ( (vex.pfx =3D=3D vex_f3) && vcpu_has_lzcnt() )
         {
             _regs.eflags &=3D ~EFLG_CF;
             if ( zf )



--=__Part09269CAD.0__=
Content-Type: text/plain; name="x86-emul-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-emul-cleanup.patch"

x86/emulator: cleanup=0A=0AUtilize some of the additions in the prior =
patches to clean up other=0Acode:=0A- keep track of REP prefixes in only =
one variable=0A- use REX_W in a few more places (instead of a literal =
number)=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/x86_emulate/x86_emulate.c=0A+++ b/xen/arch/x86/x86_emulate/x=
86_emulate.c=0A@@ -304,6 +304,10 @@ union vex {=0A         ptr[1] =3D rex =
| REX_PREFIX; \=0A } while (0)=0A =0A+#define rep_prefix()   (vex.pfx >=3D =
vex_f3)=0A+#define repe_prefix()  (vex.pfx =3D=3D vex_f3)=0A+#define =
repne_prefix() (vex.pfx =3D=3D vex_f2)=0A+=0A /* Type, address-of, and =
value of an instruction's operand. */=0A struct operand {=0A     enum { =
OP_REG, OP_MEM, OP_IMM, OP_NONE } type;=0A@@ -734,7 +738,7 @@ static =
unsigned long __get_rep_prefix(=0A =0A #define get_rep_prefix() ({         =
                                    \=0A     unsigned long max_reps =3D 1; =
                                        \=0A-    if ( rep_prefix )         =
                                          \=0A+    if ( rep_prefix() )     =
                                            \=0A         max_reps =3D =
__get_rep_prefix(&_regs, ctxt->regs, ad_bytes);      \=0A     if ( =
max_reps =3D=3D 0 )                                                \=0A    =
     goto done;                                                      =
\=0A@@ -765,7 +769,7 @@ static void __put_rep_prefix(=0A }=0A =0A #define =
put_rep_prefix(reps_completed) ({                               \=0A-    =
if ( rep_prefix )                                                   \=0A+  =
  if ( rep_prefix() )                                                 \=0A =
        __put_rep_prefix(&_regs, ctxt->regs, ad_bytes, reps_completed); =
\=0A })=0A =0A@@ -1328,9 +1332,7 @@ x86_emulate(=0A     uint8_t modrm =3D =
0, modrm_mod =3D 0, modrm_reg =3D 0, modrm_rm =3D 0;=0A     union vex vex =
=3D {};=0A     unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes;=
=0A-#define REPE_PREFIX  1=0A-#define REPNE_PREFIX 2=0A-    unsigned int =
lock_prefix =3D 0, rep_prefix =3D 0;=0A+    bool_t lock_prefix =3D 0;=0A   =
  int override_seg =3D -1, rc =3D X86EMUL_OKAY;=0A     struct operand src, =
dst;=0A     DECLARE_ALIGNED(mmval_t, mmval);=0A@@ -1359,7 +1361,8 @@ =
x86_emulate(=0A         {=0A         case 0x66: /* operand-size override =
*/=0A             op_bytes =3D def_op_bytes ^ 6;=0A-            vex.pfx =
=3D vex_66;=0A+            if ( !vex.pfx )=0A+                vex.pfx =3D =
vex_66;=0A             break;=0A         case 0x67: /* address-size =
override */=0A             ad_bytes =3D def_ad_bytes ^ (mode_64bit() ? 12 =
: 6);=0A@@ -1386,11 +1389,9 @@ x86_emulate(=0A             lock_prefix =3D =
1;=0A             break;=0A         case 0xf2: /* REPNE/REPNZ */=0A-       =
     rep_prefix =3D REPNE_PREFIX;=0A             vex.pfx =3D vex_f2;=0A    =
         break;=0A         case 0xf3: /* REP/REPE/REPZ */=0A-            =
rep_prefix =3D REPE_PREFIX;=0A             vex.pfx =3D vex_f3;=0A          =
   break;=0A         case 0x40 ... 0x4f: /* REX */=0A@@ -1407,7 +1408,7 @@ =
x86_emulate(=0A     }=0A  done_prefixes:=0A =0A-    if ( rex_prefix & 8 ) =
/* REX.W */=0A+    if ( rex_prefix & REX_W )=0A         op_bytes =3D 8;=0A =
=0A     /* Opcode byte(s). */=0A@@ -2418,8 +2419,8 @@ x86_emulate(=0A      =
   put_rep_prefix(1);=0A         /* cmp: dst - src =3D=3D> src=3D*%%edi,dst=
=3D*%%esi =3D=3D> *%%esi - *%%edi */=0A         emulate_2op_SrcV("cmp", =
src, dst, _regs.eflags);=0A-        if ( ((rep_prefix =3D=3D REPE_PREFIX) =
&& !(_regs.eflags & EFLG_ZF)) ||=0A-             ((rep_prefix =3D=3D =
REPNE_PREFIX) && (_regs.eflags & EFLG_ZF)) )=0A+        if ( (repe_prefix()=
 && !(_regs.eflags & EFLG_ZF)) ||=0A+             (repne_prefix() && =
(_regs.eflags & EFLG_ZF)) )=0A             _regs.eip =3D next_eip;=0A      =
   break;=0A     }=0A@@ -2464,8 +2465,8 @@ x86_emulate(=0A         =
put_rep_prefix(1);=0A         /* cmp: dst - src =3D=3D> src=3D*%%edi,dst=3D=
%%eax =3D=3D> %%eax - *%%edi */=0A         emulate_2op_SrcV("cmp", src, =
dst, _regs.eflags);=0A-        if ( ((rep_prefix =3D=3D REPE_PREFIX) && =
!(_regs.eflags & EFLG_ZF)) ||=0A-             ((rep_prefix =3D=3D =
REPNE_PREFIX) && (_regs.eflags & EFLG_ZF)) )=0A+        if ( (repe_prefix()=
 && !(_regs.eflags & EFLG_ZF)) ||=0A+             (repne_prefix() && =
(_regs.eflags & EFLG_ZF)) )=0A             _regs.eip =3D next_eip;=0A      =
   break;=0A     }=0A@@ -4076,7 +4077,7 @@ x86_emulate(=0A     case 0x35: =
/* sysexit */ {=0A         uint64_t msr_content;=0A         struct =
segment_register cs, ss;=0A-        int user64 =3D !!(rex_prefix & 8); /* =
REX.W */=0A+        bool_t user64 =3D !!(rex_prefix & REX_W);=0A         =
int rc;=0A =0A         generate_exception_if(!mode_ring0(), EXC_GP, =
0);=0A@@ -4366,7 +4367,7 @@ x86_emulate(=0A               : "=3Dr" =
(dst.val), "=3Dq" (zf)=0A               : "r" (src.val) );=0A         =
_regs.eflags &=3D ~EFLG_ZF;=0A-        if ( (rep_prefix =3D=3D REPE_PREFIX)=
 && vcpu_has_bmi1() )=0A+        if ( (vex.pfx =3D=3D vex_f3) && vcpu_has_b=
mi1() )=0A         {=0A             _regs.eflags &=3D ~EFLG_CF;=0A         =
    if ( zf )=0A@@ -4391,7 +4392,7 @@ x86_emulate(=0A               : =
"=3Dr" (dst.val), "=3Dq" (zf)=0A               : "r" (src.val) );=0A       =
  _regs.eflags &=3D ~EFLG_ZF;=0A-        if ( (rep_prefix =3D=3D REPE_PREFI=
X) && vcpu_has_lzcnt() )=0A+        if ( (vex.pfx =3D=3D vex_f3) && =
vcpu_has_lzcnt() )=0A         {=0A             _regs.eflags &=3D =
~EFLG_CF;=0A             if ( zf )=0A
--=__Part09269CAD.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part09269CAD.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:08:20 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmhb-0004Uj-Oe; Wed, 30 Nov 2011 16:08:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmha-0004Tu-BT
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:08:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322669247!5656481!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23587 invoked from network); 30 Nov 2011 16:07:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:07:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:07:27 +0000
Message-Id: <4ED662CD020000780006468F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:07:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part09269CAD.0__="
Subject: [Xen-devel] [PATCH 4/4] x86/emulator: cleanup
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part09269CAD.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Utilize some of the additions in the prior patches to clean up other
code:
- keep track of REP prefixes in only one variable
- use REX_W in a few more places (instead of a literal number)

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -304,6 +304,10 @@ union vex {
         ptr[1] =3D rex | REX_PREFIX; \
 } while (0)
=20
+#define rep_prefix()   (vex.pfx >=3D vex_f3)
+#define repe_prefix()  (vex.pfx =3D=3D vex_f3)
+#define repne_prefix() (vex.pfx =3D=3D vex_f2)
+
 /* Type, address-of, and value of an instruction's operand. */
 struct operand {
     enum { OP_REG, OP_MEM, OP_IMM, OP_NONE } type;
@@ -734,7 +738,7 @@ static unsigned long __get_rep_prefix(
=20
 #define get_rep_prefix() ({                                             \
     unsigned long max_reps =3D 1;                                         =
\
-    if ( rep_prefix )                                                   \
+    if ( rep_prefix() )                                                 \
         max_reps =3D __get_rep_prefix(&_regs, ctxt->regs, ad_bytes);      =
\
     if ( max_reps =3D=3D 0 )                                              =
  \
         goto done;                                                      \
@@ -765,7 +769,7 @@ static void __put_rep_prefix(
 }
=20
 #define put_rep_prefix(reps_completed) ({                               \
-    if ( rep_prefix )                                                   \
+    if ( rep_prefix() )                                                 \
         __put_rep_prefix(&_regs, ctxt->regs, ad_bytes, reps_completed); \
 })
=20
@@ -1328,9 +1332,7 @@ x86_emulate(
     uint8_t modrm =3D 0, modrm_mod =3D 0, modrm_reg =3D 0, modrm_rm =3D =
0;
     union vex vex =3D {};
     unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes;
-#define REPE_PREFIX  1
-#define REPNE_PREFIX 2
-    unsigned int lock_prefix =3D 0, rep_prefix =3D 0;
+    bool_t lock_prefix =3D 0;
     int override_seg =3D -1, rc =3D X86EMUL_OKAY;
     struct operand src, dst;
     DECLARE_ALIGNED(mmval_t, mmval);
@@ -1359,7 +1361,8 @@ x86_emulate(
         {
         case 0x66: /* operand-size override */
             op_bytes =3D def_op_bytes ^ 6;
-            vex.pfx =3D vex_66;
+            if ( !vex.pfx )
+                vex.pfx =3D vex_66;
             break;
         case 0x67: /* address-size override */
             ad_bytes =3D def_ad_bytes ^ (mode_64bit() ? 12 : 6);
@@ -1386,11 +1389,9 @@ x86_emulate(
             lock_prefix =3D 1;
             break;
         case 0xf2: /* REPNE/REPNZ */
-            rep_prefix =3D REPNE_PREFIX;
             vex.pfx =3D vex_f2;
             break;
         case 0xf3: /* REP/REPE/REPZ */
-            rep_prefix =3D REPE_PREFIX;
             vex.pfx =3D vex_f3;
             break;
         case 0x40 ... 0x4f: /* REX */
@@ -1407,7 +1408,7 @@ x86_emulate(
     }
  done_prefixes:
=20
-    if ( rex_prefix & 8 ) /* REX.W */
+    if ( rex_prefix & REX_W )
         op_bytes =3D 8;
=20
     /* Opcode byte(s). */
@@ -2418,8 +2419,8 @@ x86_emulate(
         put_rep_prefix(1);
         /* cmp: dst - src =3D=3D> src=3D*%%edi,dst=3D*%%esi =3D=3D> =
*%%esi - *%%edi */
         emulate_2op_SrcV("cmp", src, dst, _regs.eflags);
-        if ( ((rep_prefix =3D=3D REPE_PREFIX) && !(_regs.eflags & =
EFLG_ZF)) ||
-             ((rep_prefix =3D=3D REPNE_PREFIX) && (_regs.eflags & =
EFLG_ZF)) )
+        if ( (repe_prefix() && !(_regs.eflags & EFLG_ZF)) ||
+             (repne_prefix() && (_regs.eflags & EFLG_ZF)) )
             _regs.eip =3D next_eip;
         break;
     }
@@ -2464,8 +2465,8 @@ x86_emulate(
         put_rep_prefix(1);
         /* cmp: dst - src =3D=3D> src=3D*%%edi,dst=3D%%eax =3D=3D> %%eax =
- *%%edi */
         emulate_2op_SrcV("cmp", src, dst, _regs.eflags);
-        if ( ((rep_prefix =3D=3D REPE_PREFIX) && !(_regs.eflags & =
EFLG_ZF)) ||
-             ((rep_prefix =3D=3D REPNE_PREFIX) && (_regs.eflags & =
EFLG_ZF)) )
+        if ( (repe_prefix() && !(_regs.eflags & EFLG_ZF)) ||
+             (repne_prefix() && (_regs.eflags & EFLG_ZF)) )
             _regs.eip =3D next_eip;
         break;
     }
@@ -4076,7 +4077,7 @@ x86_emulate(
     case 0x35: /* sysexit */ {
         uint64_t msr_content;
         struct segment_register cs, ss;
-        int user64 =3D !!(rex_prefix & 8); /* REX.W */
+        bool_t user64 =3D !!(rex_prefix & REX_W);
         int rc;
=20
         generate_exception_if(!mode_ring0(), EXC_GP, 0);
@@ -4366,7 +4367,7 @@ x86_emulate(
               : "=3Dr" (dst.val), "=3Dq" (zf)
               : "r" (src.val) );
         _regs.eflags &=3D ~EFLG_ZF;
-        if ( (rep_prefix =3D=3D REPE_PREFIX) && vcpu_has_bmi1() )
+        if ( (vex.pfx =3D=3D vex_f3) && vcpu_has_bmi1() )
         {
             _regs.eflags &=3D ~EFLG_CF;
             if ( zf )
@@ -4391,7 +4392,7 @@ x86_emulate(
               : "=3Dr" (dst.val), "=3Dq" (zf)
               : "r" (src.val) );
         _regs.eflags &=3D ~EFLG_ZF;
-        if ( (rep_prefix =3D=3D REPE_PREFIX) && vcpu_has_lzcnt() )
+        if ( (vex.pfx =3D=3D vex_f3) && vcpu_has_lzcnt() )
         {
             _regs.eflags &=3D ~EFLG_CF;
             if ( zf )



--=__Part09269CAD.0__=
Content-Type: text/plain; name="x86-emul-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-emul-cleanup.patch"

x86/emulator: cleanup=0A=0AUtilize some of the additions in the prior =
patches to clean up other=0Acode:=0A- keep track of REP prefixes in only =
one variable=0A- use REX_W in a few more places (instead of a literal =
number)=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/x86_emulate/x86_emulate.c=0A+++ b/xen/arch/x86/x86_emulate/x=
86_emulate.c=0A@@ -304,6 +304,10 @@ union vex {=0A         ptr[1] =3D rex =
| REX_PREFIX; \=0A } while (0)=0A =0A+#define rep_prefix()   (vex.pfx >=3D =
vex_f3)=0A+#define repe_prefix()  (vex.pfx =3D=3D vex_f3)=0A+#define =
repne_prefix() (vex.pfx =3D=3D vex_f2)=0A+=0A /* Type, address-of, and =
value of an instruction's operand. */=0A struct operand {=0A     enum { =
OP_REG, OP_MEM, OP_IMM, OP_NONE } type;=0A@@ -734,7 +738,7 @@ static =
unsigned long __get_rep_prefix(=0A =0A #define get_rep_prefix() ({         =
                                    \=0A     unsigned long max_reps =3D 1; =
                                        \=0A-    if ( rep_prefix )         =
                                          \=0A+    if ( rep_prefix() )     =
                                            \=0A         max_reps =3D =
__get_rep_prefix(&_regs, ctxt->regs, ad_bytes);      \=0A     if ( =
max_reps =3D=3D 0 )                                                \=0A    =
     goto done;                                                      =
\=0A@@ -765,7 +769,7 @@ static void __put_rep_prefix(=0A }=0A =0A #define =
put_rep_prefix(reps_completed) ({                               \=0A-    =
if ( rep_prefix )                                                   \=0A+  =
  if ( rep_prefix() )                                                 \=0A =
        __put_rep_prefix(&_regs, ctxt->regs, ad_bytes, reps_completed); =
\=0A })=0A =0A@@ -1328,9 +1332,7 @@ x86_emulate(=0A     uint8_t modrm =3D =
0, modrm_mod =3D 0, modrm_reg =3D 0, modrm_rm =3D 0;=0A     union vex vex =
=3D {};=0A     unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes;=
=0A-#define REPE_PREFIX  1=0A-#define REPNE_PREFIX 2=0A-    unsigned int =
lock_prefix =3D 0, rep_prefix =3D 0;=0A+    bool_t lock_prefix =3D 0;=0A   =
  int override_seg =3D -1, rc =3D X86EMUL_OKAY;=0A     struct operand src, =
dst;=0A     DECLARE_ALIGNED(mmval_t, mmval);=0A@@ -1359,7 +1361,8 @@ =
x86_emulate(=0A         {=0A         case 0x66: /* operand-size override =
*/=0A             op_bytes =3D def_op_bytes ^ 6;=0A-            vex.pfx =
=3D vex_66;=0A+            if ( !vex.pfx )=0A+                vex.pfx =3D =
vex_66;=0A             break;=0A         case 0x67: /* address-size =
override */=0A             ad_bytes =3D def_ad_bytes ^ (mode_64bit() ? 12 =
: 6);=0A@@ -1386,11 +1389,9 @@ x86_emulate(=0A             lock_prefix =3D =
1;=0A             break;=0A         case 0xf2: /* REPNE/REPNZ */=0A-       =
     rep_prefix =3D REPNE_PREFIX;=0A             vex.pfx =3D vex_f2;=0A    =
         break;=0A         case 0xf3: /* REP/REPE/REPZ */=0A-            =
rep_prefix =3D REPE_PREFIX;=0A             vex.pfx =3D vex_f3;=0A          =
   break;=0A         case 0x40 ... 0x4f: /* REX */=0A@@ -1407,7 +1408,7 @@ =
x86_emulate(=0A     }=0A  done_prefixes:=0A =0A-    if ( rex_prefix & 8 ) =
/* REX.W */=0A+    if ( rex_prefix & REX_W )=0A         op_bytes =3D 8;=0A =
=0A     /* Opcode byte(s). */=0A@@ -2418,8 +2419,8 @@ x86_emulate(=0A      =
   put_rep_prefix(1);=0A         /* cmp: dst - src =3D=3D> src=3D*%%edi,dst=
=3D*%%esi =3D=3D> *%%esi - *%%edi */=0A         emulate_2op_SrcV("cmp", =
src, dst, _regs.eflags);=0A-        if ( ((rep_prefix =3D=3D REPE_PREFIX) =
&& !(_regs.eflags & EFLG_ZF)) ||=0A-             ((rep_prefix =3D=3D =
REPNE_PREFIX) && (_regs.eflags & EFLG_ZF)) )=0A+        if ( (repe_prefix()=
 && !(_regs.eflags & EFLG_ZF)) ||=0A+             (repne_prefix() && =
(_regs.eflags & EFLG_ZF)) )=0A             _regs.eip =3D next_eip;=0A      =
   break;=0A     }=0A@@ -2464,8 +2465,8 @@ x86_emulate(=0A         =
put_rep_prefix(1);=0A         /* cmp: dst - src =3D=3D> src=3D*%%edi,dst=3D=
%%eax =3D=3D> %%eax - *%%edi */=0A         emulate_2op_SrcV("cmp", src, =
dst, _regs.eflags);=0A-        if ( ((rep_prefix =3D=3D REPE_PREFIX) && =
!(_regs.eflags & EFLG_ZF)) ||=0A-             ((rep_prefix =3D=3D =
REPNE_PREFIX) && (_regs.eflags & EFLG_ZF)) )=0A+        if ( (repe_prefix()=
 && !(_regs.eflags & EFLG_ZF)) ||=0A+             (repne_prefix() && =
(_regs.eflags & EFLG_ZF)) )=0A             _regs.eip =3D next_eip;=0A      =
   break;=0A     }=0A@@ -4076,7 +4077,7 @@ x86_emulate(=0A     case 0x35: =
/* sysexit */ {=0A         uint64_t msr_content;=0A         struct =
segment_register cs, ss;=0A-        int user64 =3D !!(rex_prefix & 8); /* =
REX.W */=0A+        bool_t user64 =3D !!(rex_prefix & REX_W);=0A         =
int rc;=0A =0A         generate_exception_if(!mode_ring0(), EXC_GP, =
0);=0A@@ -4366,7 +4367,7 @@ x86_emulate(=0A               : "=3Dr" =
(dst.val), "=3Dq" (zf)=0A               : "r" (src.val) );=0A         =
_regs.eflags &=3D ~EFLG_ZF;=0A-        if ( (rep_prefix =3D=3D REPE_PREFIX)=
 && vcpu_has_bmi1() )=0A+        if ( (vex.pfx =3D=3D vex_f3) && vcpu_has_b=
mi1() )=0A         {=0A             _regs.eflags &=3D ~EFLG_CF;=0A         =
    if ( zf )=0A@@ -4391,7 +4392,7 @@ x86_emulate(=0A               : =
"=3Dr" (dst.val), "=3Dq" (zf)=0A               : "r" (src.val) );=0A       =
  _regs.eflags &=3D ~EFLG_ZF;=0A-        if ( (rep_prefix =3D=3D REPE_PREFI=
X) && vcpu_has_lzcnt() )=0A+        if ( (vex.pfx =3D=3D vex_f3) && =
vcpu_has_lzcnt() )=0A         {=0A             _regs.eflags &=3D =
~EFLG_CF;=0A             if ( zf )=0A
--=__Part09269CAD.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part09269CAD.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:26:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:26:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmz4-00059Q-Ln; Wed, 30 Nov 2011 16:26:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVmz3-000595-81
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:26:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322670313!57168728!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16897 invoked from network); 30 Nov 2011 16:25:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 16:25:14 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUGPD4D017520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 16:25:14 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUGPAaH020925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 16:25:10 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUGP3Jc005526; Wed, 30 Nov 2011 10:25:03 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 08:25:02 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 5882141C2D;
	Wed, 30 Nov 2011 11:24:33 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUGNWfw010876;
	Wed, 30 Nov 2011 11:23:32 -0500
Date: Wed, 30 Nov 2011 11:23:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20111130162332.GA10832@phenom.dumpdata.com>
References: <20110106223121.GT2754@reaktio.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF"
Content-Disposition: inline
In-Reply-To: <20110106223121.GT2754@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4ED658EC.0079,ss=1,re=-6.500,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v01] Xen PVSCSI drivers for pvops
 xen/stable-2.6.32.x kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 07, 2011 at 12:31:21AM +0200, Pasi K=E4rkk=E4inen wrote:
> Hello,
>=20
> http://pasik.reaktio.net/xen/patches/xen-pvscsi-drivers-linux-2.6.32.27=
-pvops-v01.diff
>=20
> This is the first version of Xen PVSCSI drivers, both the scsiback back=
end and
> scsifront frontend, ported from Novell SLES11SP1 2.6.32 Xenlinux kernel=
 to=20
> pvops xen/stable-2.6.32.x branch.
>=20
> At the moment it's *only* compile-tested with the latest xen/stable-2.6=
.32.x=20
> git kernel as of today (2.6.32.27), on Fedora 14 x86_64.
>=20
> Comments welcome.
>=20
> I'm sure there are still things to fix in it.=20
> Hopefully I managed to properly fix all the differences between Xenlinu=
x <-> pvops..
> Let me know how it goes, if you feel adventurous enough to try it :)

I took a look at the patches and rebased them on top of v3.0 some time ag=
o.

Had to fix up some things, but not much (most of the P2M API calls, and s=
ome of the
grant table modifications) and stuck the patches in:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/xen-sc=
si.v1.0

Attached is also the full patch against v3.0 kernel. I found that it work=
s
with my SCSI disks, but you need to use Xen 4.1 (and xm). Earlier version=
s
do something weird. I am not really sure who is using it=20

Ah, I also put the 2Tb fix in it.

 drivers/scsi/Kconfig                   |   16 +
 drivers/scsi/Makefile                  |    2 +
 drivers/scsi/xen-scsiback/Makefile     |    4 +
 drivers/scsi/xen-scsiback/common.h     |  187 ++++++++
 drivers/scsi/xen-scsiback/emulate.c    |  478 ++++++++++++++++++++
 drivers/scsi/xen-scsiback/interface.c  |  141 ++++++
 drivers/scsi/xen-scsiback/scsiback.c   |  757 ++++++++++++++++++++++++++=
++++++
 drivers/scsi/xen-scsiback/translate.c  |  168 +++++++
 drivers/scsi/xen-scsiback/xenbus.c     |  374 ++++++++++++++++
 drivers/scsi/xen-scsifront/Makefile    |    4 +
 drivers/scsi/xen-scsifront/common.h    |  137 ++++++
 drivers/scsi/xen-scsifront/scsifront.c |  469 ++++++++++++++++++++
 drivers/scsi/xen-scsifront/xenbus.c    |  414 +++++++++++++++++
 include/xen/interface/grant_table.h    |    4 +
 include/xen/interface/io/vscsiif.h     |  105 +++++
 15 files changed, 3260 insertions(+), 0 deletions(-)

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="pv-scsi-against.v3.0.patch"

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 8d9dae8..380e4f05 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1909,6 +1909,22 @@ config SCSI_BFA_FC
 	  To compile this driver as a module, choose M here. The module will
 	  be called bfa.
 
+config XEN_SCSI_FRONTEND
+        tristate "Xen PVSCSI frontend driver"
+        depends on XEN && SCSI
+        default m
+        help
+          The SCSI frontend driver allows the kernel to access SCSI Devices
+          within another guest OS.
+
+config XEN_SCSI_BACKEND
+        tristate "Xen PVSCSI backend driver"
+        depends on XEN_BACKEND && SCSI
+        default m
+        help
+          The PVSCSI backend driver allows the kernel to export its SCSI Devices
+          to other Xen guests via a high-performance shared-memory interface.
+
 endif # SCSI_LOWLEVEL
 
 source "drivers/scsi/pcmcia/Kconfig"
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 3c08f53..7b6f4d2 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -140,6 +140,8 @@ obj-$(CONFIG_SCSI_CXGB4_ISCSI)	+= libiscsi.o libiscsi_tcp.o cxgbi/
 obj-$(CONFIG_SCSI_BNX2_ISCSI)	+= libiscsi.o bnx2i/
 obj-$(CONFIG_BE2ISCSI)		+= libiscsi.o be2iscsi/
 obj-$(CONFIG_SCSI_PMCRAID)	+= pmcraid.o
+obj-$(CONFIG_XEN_SCSI_FRONTEND)	+= xen-scsifront/
+obj-$(CONFIG_XEN_SCSI_BACKEND)	+= xen-scsiback/
 obj-$(CONFIG_VMWARE_PVSCSI)	+= vmw_pvscsi.o
 
 obj-$(CONFIG_ARM)		+= arm/
diff --git a/drivers/scsi/xen-scsiback/Makefile b/drivers/scsi/xen-scsiback/Makefile
new file mode 100644
index 0000000..94926dc
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/Makefile
@@ -0,0 +1,4 @@
+obj-$(CONFIG_XEN_SCSI_BACKEND) := xen-scsiback.o
+
+xen-scsiback-y	:= interface.o scsiback.o xenbus.o translate.o emulate.o
+
diff --git a/drivers/scsi/xen-scsiback/common.h b/drivers/scsi/xen-scsiback/common.h
new file mode 100644
index 0000000..dafa79e
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/common.h
@@ -0,0 +1,187 @@
+/*
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * Based on the blkback driver code.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __SCSIIF__BACKEND__COMMON_H__
+#define __SCSIIF__BACKEND__COMMON_H__
+
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
+#include <linux/wait.h>
+#include <linux/sched.h>
+#include <linux/kthread.h>
+#include <linux/blkdev.h>
+#include <linux/list.h>
+#include <linux/kthread.h>
+#include <scsi/scsi.h>
+#include <scsi/scsi_cmnd.h>
+#include <scsi/scsi_host.h>
+#include <scsi/scsi_device.h>
+#include <scsi/scsi_dbg.h>
+#include <scsi/scsi_eh.h>
+#include <asm/io.h>
+#include <asm/setup.h>
+#include <asm/pgalloc.h>
+#include <asm/delay.h>
+#include <xen/evtchn.h>
+#include <asm/hypervisor.h>
+#include <xen/xen.h>
+#include <xen/events.h>
+#include <xen/grant_table.h>
+#include <xen/xenbus.h>
+#include <xen/page.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/io/ring.h>
+#include <xen/interface/grant_table.h>
+#include <xen/interface/io/vscsiif.h>
+
+
+#define DPRINTK(_f, _a...)			\
+	pr_debug("(file=%s, line=%d) " _f,	\
+		 __FILE__ , __LINE__ , ## _a )
+
+struct ids_tuple {
+	unsigned int hst;		/* host    */
+	unsigned int chn;		/* channel */
+	unsigned int tgt;		/* target  */
+	unsigned int lun;		/* LUN     */
+};
+
+struct v2p_entry {
+	struct ids_tuple v;		/* translate from */
+	struct scsi_device *sdev;	/* translate to   */
+	struct list_head l;
+};
+
+struct vscsibk_info {
+	struct xenbus_device *dev;
+
+	domid_t domid;
+	unsigned int evtchn;
+	unsigned int irq;
+
+	int feature;
+
+	struct vscsiif_back_ring  ring;
+	void  *ring_area;
+
+	spinlock_t ring_lock;
+	atomic_t nr_unreplied_reqs;
+
+	spinlock_t v2p_lock;
+	struct list_head v2p_entry_lists;
+
+	struct task_struct *kthread;
+	wait_queue_head_t waiting_to_free;
+	wait_queue_head_t wq;
+	unsigned int waiting_reqs;
+	struct page **mmap_pages;
+
+};
+
+typedef struct {
+	unsigned char act;
+	struct vscsibk_info *info;
+	struct scsi_device *sdev;
+
+	uint16_t rqid;
+
+	uint16_t v_chn, v_tgt;
+
+	uint8_t nr_segments;
+	uint8_t cmnd[VSCSIIF_MAX_COMMAND_SIZE];
+	uint8_t cmd_len;
+
+	uint8_t sc_data_direction;
+	uint16_t timeout_per_command;
+
+	uint32_t request_bufflen;
+	struct scatterlist *sgl;
+	grant_ref_t gref[VSCSIIF_SG_TABLESIZE];
+
+	int32_t rslt;
+	uint32_t resid;
+	uint8_t sense_buffer[VSCSIIF_SENSE_BUFFERSIZE];
+
+	struct list_head free_list;
+} pending_req_t;
+
+
+
+#define scsiback_get(_b) (atomic_inc(&(_b)->nr_unreplied_reqs))
+#define scsiback_put(_b)				\
+	do {						\
+		if (atomic_dec_and_test(&(_b)->nr_unreplied_reqs))	\
+			wake_up(&(_b)->waiting_to_free);\
+	} while (0)
+
+#define VSCSIIF_TIMEOUT		(900*HZ)
+
+#define VSCSI_TYPE_HOST		1
+
+irqreturn_t scsiback_intr(int, void *);
+int scsiback_init_sring(struct vscsibk_info *info,
+		unsigned long ring_ref, unsigned int evtchn);
+int scsiback_schedule(void *data);
+
+
+struct vscsibk_info *vscsibk_info_alloc(domid_t domid);
+void scsiback_free(struct vscsibk_info *info);
+void scsiback_disconnect(struct vscsibk_info *info);
+int __init scsiback_interface_init(void);
+void scsiback_interface_exit(void);
+int scsiback_xenbus_init(void);
+void scsiback_xenbus_unregister(void);
+
+void scsiback_init_translation_table(struct vscsibk_info *info);
+
+int scsiback_add_translation_entry(struct vscsibk_info *info,
+			struct scsi_device *sdev, struct ids_tuple *v);
+
+int scsiback_del_translation_entry(struct vscsibk_info *info,
+				struct ids_tuple *v);
+struct scsi_device *scsiback_do_translation(struct vscsibk_info *info,
+			struct ids_tuple *v);
+void scsiback_release_translation_entry(struct vscsibk_info *info);
+
+
+void scsiback_cmd_exec(pending_req_t *pending_req);
+void scsiback_do_resp_with_sense(char *sense_buffer, int32_t result,
+			uint32_t resid, pending_req_t *pending_req);
+void scsiback_fast_flush_area(pending_req_t *req);
+
+void scsiback_rsp_emulation(pending_req_t *pending_req);
+void scsiback_req_emulation_or_cmdexec(pending_req_t *pending_req);
+void scsiback_emulation_init(void);
+
+
+#endif /* __SCSIIF__BACKEND__COMMON_H__ */
diff --git a/drivers/scsi/xen-scsiback/emulate.c b/drivers/scsi/xen-scsiback/emulate.c
new file mode 100644
index 0000000..c5b0999
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/emulate.c
@@ -0,0 +1,478 @@
+/*
+ * Xen SCSI backend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/*
+* Patched to support >2TB drives + allow tape & autoloader operations
+* 2010, Samuel Kvasnica, IMS Nanofabrication AG
+*/
+
+#include <scsi/scsi.h>
+#include <scsi/scsi_cmnd.h>
+#include <scsi/scsi_device.h>
+#include "common.h"
+
+/* Following SCSI commands are not defined in scsi/scsi.h */
+#define EXTENDED_COPY		0x83	/* EXTENDED COPY command        */
+#define REPORT_ALIASES		0xa3	/* REPORT ALIASES command       */
+#define CHANGE_ALIASES		0xa4	/* CHANGE ALIASES command       */
+#define SET_PRIORITY		0xa4	/* SET PRIORITY command         */
+
+
+/*
+  The bitmap in order to control emulation.
+  (Bit 3 to 7 are reserved for future use.)
+*/
+#define VSCSIIF_NEED_CMD_EXEC		0x01	/* If this bit is set, cmd exec	*/
+						/* is required.			*/
+#define VSCSIIF_NEED_EMULATE_REQBUF	0x02	/* If this bit is set, need	*/
+						/* emulation reqest buff before	*/
+						/* cmd exec.			*/
+#define VSCSIIF_NEED_EMULATE_RSPBUF	0x04	/* If this bit is set, need	*/
+						/* emulation resp buff after	*/
+						/* cmd exec.			*/
+
+/* Additional Sense Code (ASC) used */
+#define NO_ADDITIONAL_SENSE		0x0
+#define LOGICAL_UNIT_NOT_READY		0x4
+#define UNRECOVERED_READ_ERR		0x11
+#define PARAMETER_LIST_LENGTH_ERR	0x1a
+#define INVALID_OPCODE			0x20
+#define ADDR_OUT_OF_RANGE		0x21
+#define INVALID_FIELD_IN_CDB		0x24
+#define INVALID_FIELD_IN_PARAM_LIST	0x26
+#define POWERON_RESET			0x29
+#define SAVING_PARAMS_UNSUP		0x39
+#define THRESHOLD_EXCEEDED		0x5d
+#define LOW_POWER_COND_ON		0x5e
+
+
+
+/* Number os SCSI op_code	*/
+#define VSCSI_MAX_SCSI_OP_CODE		256
+static unsigned char bitmap[VSCSI_MAX_SCSI_OP_CODE];
+
+#define NO_EMULATE(cmd) \
+	bitmap[cmd] = VSCSIIF_NEED_CMD_EXEC; \
+	pre_function[cmd] = NULL; \
+	post_function[cmd] = NULL
+
+
+
+/*
+  Emulation routines for each SCSI op_code.
+*/
+static void (*pre_function[VSCSI_MAX_SCSI_OP_CODE])(pending_req_t *, void *);
+static void (*post_function[VSCSI_MAX_SCSI_OP_CODE])(pending_req_t *, void *);
+
+
+static const int check_condition_result =
+		(DRIVER_SENSE << 24) | SAM_STAT_CHECK_CONDITION;
+
+static void scsiback_mk_sense_buffer(uint8_t *data, uint8_t key,
+			uint8_t asc, uint8_t asq)
+{
+	data[0] = 0x70;  /* fixed, current */
+	data[2] = key;
+	data[7] = 0xa;	  /* implies 18 byte sense buffer */
+	data[12] = asc;
+	data[13] = asq;
+}
+
+static void resp_not_supported_cmd(pending_req_t *pending_req, void *data)
+{
+	scsiback_mk_sense_buffer(pending_req->sense_buffer, ILLEGAL_REQUEST,
+		INVALID_OPCODE, 0);
+	pending_req->resid = 0;
+	pending_req->rslt  = check_condition_result;
+}
+
+
+static int __copy_to_sg(struct scatterlist *sgl, unsigned int nr_sg,
+	       void *buf, unsigned int buflen)
+{
+	struct scatterlist *sg;
+	void *from = buf;
+	void *to;
+	unsigned int from_rest = buflen;
+	unsigned int to_capa;
+	unsigned int copy_size = 0;
+	unsigned int i;
+	unsigned long pfn;
+
+	for_each_sg (sgl, sg, nr_sg, i) {
+		if (sg_page(sg) == NULL) {
+			printk(KERN_WARNING "%s: inconsistent length field in "
+			       "scatterlist\n", __FUNCTION__);
+			return -ENOMEM;
+		}
+
+		to_capa  = sg->length;
+		copy_size = min_t(unsigned int, to_capa, from_rest);
+
+		pfn = page_to_pfn(sg_page(sg));
+		to = pfn_to_kaddr(pfn) + (sg->offset);
+		memcpy(to, from, copy_size);
+
+		from_rest  -= copy_size;
+		if (from_rest == 0) {
+			return 0;
+		}
+
+		from += copy_size;
+	}
+
+	printk(KERN_WARNING "%s: no space in scatterlist\n",
+	       __FUNCTION__);
+	return -ENOMEM;
+}
+#if 0
+static int __copy_from_sg(struct scatterlist *sgl, unsigned int nr_sg,
+		 void *buf, unsigned int buflen)
+{
+	struct scatterlist *sg;
+	void *from;
+	void *to = buf;
+	unsigned int from_rest;
+	unsigned int to_capa = buflen;
+	unsigned int copy_size;
+	unsigned int i;
+	unsigned long pfn;
+
+	for_each_sg (sgl, sg, nr_sg, i) {
+		if (sg_page(sg) == NULL) {
+			printk(KERN_WARNING "%s: inconsistent length field in "
+			       "scatterlist\n", __FUNCTION__);
+			return -ENOMEM;
+		}
+
+		from_rest = sg->length;
+		if ((from_rest > 0) && (to_capa < from_rest)) {
+			printk(KERN_WARNING
+			       "%s: no space in destination buffer\n",
+			       __FUNCTION__);
+			return -ENOMEM;
+		}
+		copy_size = from_rest;
+
+		pfn = page_to_pfn(sg_page(sg));
+		from = pfn_to_kaddr(pfn) + (sg->offset);
+		memcpy(to, from, copy_size);
+
+		to_capa  -= copy_size;
+		to += copy_size;
+	}
+
+	return 0;
+}
+#endif
+static int __nr_luns_under_host(struct vscsibk_info *info)
+{
+	struct v2p_entry *entry;
+	struct list_head *head = &(info->v2p_entry_lists);
+	unsigned long flags;
+	int lun_cnt = 0;
+
+	spin_lock_irqsave(&info->v2p_lock, flags);
+	list_for_each_entry(entry, head, l) {
+			lun_cnt++;
+	}
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+
+	return (lun_cnt);
+}
+
+
+/* REPORT LUNS Define*/
+#define VSCSI_REPORT_LUNS_HEADER	8
+#define VSCSI_REPORT_LUNS_RETRY		3
+
+/* quoted scsi_debug.c/resp_report_luns() */
+static void __report_luns(pending_req_t *pending_req, void *data)
+{
+	struct vscsibk_info *info   = pending_req->info;
+	unsigned int        channel = pending_req->v_chn;
+	unsigned int        target  = pending_req->v_tgt;
+	unsigned int        nr_seg  = pending_req->nr_segments;
+	unsigned char *cmd = (unsigned char *)pending_req->cmnd;
+
+	unsigned char *buff = NULL;
+	unsigned char alloc_len;
+	unsigned int alloc_luns = 0;
+	unsigned int req_bufflen = 0;
+	unsigned int actual_len = 0;
+	unsigned int retry_cnt = 0;
+	int select_report = (int)cmd[2];
+	int i, lun_cnt = 0, lun, upper, err = 0;
+
+	struct v2p_entry *entry;
+	struct list_head *head = &(info->v2p_entry_lists);
+	unsigned long flags;
+
+	struct scsi_lun *one_lun;
+
+	req_bufflen = cmd[9] + (cmd[8] << 8) + (cmd[7] << 16) + (cmd[6] << 24);
+	if ((req_bufflen < 4) || (select_report != 0))
+		goto fail;
+
+	alloc_luns = __nr_luns_under_host(info);
+	alloc_len  = sizeof(struct scsi_lun) * alloc_luns
+				+ VSCSI_REPORT_LUNS_HEADER;
+retry:
+	if ((buff = kzalloc(alloc_len, GFP_KERNEL)) == NULL) {
+		printk(KERN_ERR "scsiback:%s kmalloc err\n", __FUNCTION__);
+		goto fail;
+	}
+
+	one_lun = (struct scsi_lun *) &buff[8];
+	spin_lock_irqsave(&info->v2p_lock, flags);
+	list_for_each_entry(entry, head, l) {
+		if ((entry->v.chn == channel) &&
+		    (entry->v.tgt == target)) {
+			/* check overflow */
+			if (lun_cnt >= alloc_luns) {
+				spin_unlock_irqrestore(&info->v2p_lock,
+							flags);
+
+				if (retry_cnt < VSCSI_REPORT_LUNS_RETRY) {
+					retry_cnt++;
+					if (buff)
+						kfree(buff);
+					goto retry;
+				}
+
+				goto fail;
+			}
+
+			lun = entry->v.lun;
+			upper = (lun >> 8) & 0x3f;
+			if (upper)
+				one_lun[lun_cnt].scsi_lun[0] = upper;
+			one_lun[lun_cnt].scsi_lun[1] = lun & 0xff;
+			lun_cnt++;
+		}
+	}
+
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+
+	buff[2] = ((sizeof(struct scsi_lun) * lun_cnt) >> 8) & 0xff;
+	buff[3] = (sizeof(struct scsi_lun) * lun_cnt) & 0xff;
+
+	actual_len = lun_cnt * sizeof(struct scsi_lun)
+				+ VSCSI_REPORT_LUNS_HEADER;
+	req_bufflen = 0;
+	for (i = 0; i < nr_seg; i++)
+		req_bufflen += pending_req->sgl[i].length;
+
+	err = __copy_to_sg(pending_req->sgl, nr_seg, buff,
+				min(req_bufflen, actual_len));
+	if (err)
+		goto fail;
+
+	memset(pending_req->sense_buffer, 0, VSCSIIF_SENSE_BUFFERSIZE);
+	pending_req->rslt = 0x00;
+	pending_req->resid = req_bufflen - min(req_bufflen, actual_len);
+
+	kfree(buff);
+	return;
+
+fail:
+	scsiback_mk_sense_buffer(pending_req->sense_buffer, ILLEGAL_REQUEST,
+		INVALID_FIELD_IN_CDB, 0);
+	pending_req->rslt  = check_condition_result;
+	pending_req->resid = 0;
+	if (buff)
+		kfree(buff);
+	return;
+}
+
+
+
+int __pre_do_emulation(pending_req_t *pending_req, void *data)
+{
+	uint8_t op_code = pending_req->cmnd[0];
+
+	if ((bitmap[op_code] & VSCSIIF_NEED_EMULATE_REQBUF) &&
+	    pre_function[op_code] != NULL) {
+		pre_function[op_code](pending_req, data);
+	}
+
+	/*
+	    0: no need for native driver call, so should return immediately.
+	    1: non emulation or should call native driver
+	       after modifing the request buffer.
+	*/
+	return !!(bitmap[op_code] & VSCSIIF_NEED_CMD_EXEC);
+}
+
+void scsiback_rsp_emulation(pending_req_t *pending_req)
+{
+	uint8_t op_code = pending_req->cmnd[0];
+
+	if ((bitmap[op_code] & VSCSIIF_NEED_EMULATE_RSPBUF) &&
+	    post_function[op_code] != NULL) {
+		post_function[op_code](pending_req, NULL);
+	}
+
+	return;
+}
+
+
+void scsiback_req_emulation_or_cmdexec(pending_req_t *pending_req)
+{
+	if (__pre_do_emulation(pending_req, NULL)) {
+		scsiback_cmd_exec(pending_req);
+	}
+	else {
+		scsiback_fast_flush_area(pending_req);
+		scsiback_do_resp_with_sense(pending_req->sense_buffer,
+		  pending_req->rslt, pending_req->resid, pending_req);
+	}
+}
+
+
+/*
+  Following are not customizable functions.
+*/
+void scsiback_emulation_init(void)
+{
+	int i;
+
+	/* Initialize to default state */
+	for (i = 0; i < VSCSI_MAX_SCSI_OP_CODE; i++) {
+		bitmap[i]        = (VSCSIIF_NEED_EMULATE_REQBUF |
+					VSCSIIF_NEED_EMULATE_RSPBUF);
+		pre_function[i]  = resp_not_supported_cmd;
+		post_function[i] = NULL;
+		/* means,
+		   - no need for pre-emulation
+		   - no need for post-emulation
+		   - call native driver
+		*/
+	}
+
+	/*
+	  Register appropriate functions below as you need.
+	  (See scsi/scsi.h for definition of SCSI op_code.)
+	*/
+
+	/*
+	  Following commands do not require emulation.
+	*/
+	NO_EMULATE(TEST_UNIT_READY);       /*0x00*/ /* sd,st */
+	NO_EMULATE(REZERO_UNIT);           /*0x01*/ /* st */
+	NO_EMULATE(REQUEST_SENSE);         /*0x03*/
+	NO_EMULATE(FORMAT_UNIT);           /*0x04*/
+	NO_EMULATE(READ_BLOCK_LIMITS);     /*0x05*/ /* st */
+	/*NO_EMULATE(REASSIGN_BLOCKS);       *//*0x07*/
+	NO_EMULATE(INITIALIZE_ELEMENT_STATUS); /*0x07*/ /* ch */
+	NO_EMULATE(READ_6);                /*0x08*/ /* sd,st */
+	NO_EMULATE(WRITE_6);               /*0x0a*/ /* sd,st */
+	NO_EMULATE(SEEK_6);                /*0x0b*/
+	/*NO_EMULATE(READ_REVERSE);          *//*0x0f*/
+	NO_EMULATE(WRITE_FILEMARKS);       /*0x10*/ /* st */
+	NO_EMULATE(SPACE);                 /*0x11*/ /* st */
+	NO_EMULATE(INQUIRY);               /*0x12*/
+	/*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
+	NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
+	/*NO_EMULATE(RESERVE);               *//*0x16*/
+	/*NO_EMULATE(RELEASE);               *//*0x17*/
+	/*NO_EMULATE(COPY);                  *//*0x18*/
+	NO_EMULATE(ERASE);                 /*0x19*/ /* st */
+	NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
+	NO_EMULATE(START_STOP);            /*0x1b*/ /* sd,st */
+	NO_EMULATE(RECEIVE_DIAGNOSTIC);    /*0x1c*/
+	NO_EMULATE(SEND_DIAGNOSTIC);       /*0x1d*/
+	NO_EMULATE(ALLOW_MEDIUM_REMOVAL);  /*0x1e*/
+
+	/*NO_EMULATE(SET_WINDOW);            *//*0x24*/
+	NO_EMULATE(READ_CAPACITY);         /*0x25*/ /* sd */
+	NO_EMULATE(READ_10);               /*0x28*/ /* sd */
+	NO_EMULATE(WRITE_10);              /*0x2a*/ /* sd */
+	NO_EMULATE(SEEK_10);               /*0x2b*/ /* st */
+	NO_EMULATE(POSITION_TO_ELEMENT);   /*0x2b*/ /* ch */
+	/*NO_EMULATE(WRITE_VERIFY);          *//*0x2e*/
+	/*NO_EMULATE(VERIFY);                *//*0x2f*/
+	/*NO_EMULATE(SEARCH_HIGH);           *//*0x30*/
+	/*NO_EMULATE(SEARCH_EQUAL);          *//*0x31*/
+	/*NO_EMULATE(SEARCH_LOW);            *//*0x32*/
+	NO_EMULATE(SET_LIMITS);            /*0x33*/
+	NO_EMULATE(PRE_FETCH);             /*0x34*/ /* st! */
+	NO_EMULATE(READ_POSITION);          /*0x34*/ /* st */
+	NO_EMULATE(SYNCHRONIZE_CACHE);      /*0x35*/ /* sd */
+	NO_EMULATE(LOCK_UNLOCK_CACHE);     /*0x36*/
+	NO_EMULATE(READ_DEFECT_DATA);      /*0x37*/
+	NO_EMULATE(MEDIUM_SCAN);           /*0x38*/
+	/*NO_EMULATE(COMPARE);               *//*0x39*/
+	/*NO_EMULATE(COPY_VERIFY);           *//*0x3a*/
+	NO_EMULATE(WRITE_BUFFER);          /*0x3b*/
+	NO_EMULATE(READ_BUFFER);           /*0x3c*/ /* osst */
+	/*NO_EMULATE(UPDATE_BLOCK);          *//*0x3d*/
+	/*NO_EMULATE(READ_LONG);             *//*0x3e*/
+	/*NO_EMULATE(WRITE_LONG);            *//*0x3f*/
+	/*NO_EMULATE(CHANGE_DEFINITION);     *//*0x40*/
+	/*NO_EMULATE(WRITE_SAME);            *//*0x41*/
+	NO_EMULATE(READ_TOC);              /*0x43*/ /* sr */
+	NO_EMULATE(LOG_SELECT);            /*0x4c*/
+	NO_EMULATE(LOG_SENSE);             /*0x4d*/ /* st! */
+	/*NO_EMULATE(MODE_SELECT_10);        *//*0x55*/
+	/*NO_EMULATE(RESERVE_10);            *//*0x56*/
+	/*NO_EMULATE(RELEASE_10);            *//*0x57*/
+	NO_EMULATE(MODE_SENSE_10);         /*0x5a*/ /* scsi_lib */
+	/*NO_EMULATE(PERSISTENT_RESERVE_IN); *//*0x5e*/
+	/*NO_EMULATE(PERSISTENT_RESERVE_OUT); *//*0x5f*/
+	/*           REPORT_LUNS             *//*0xa0*//*Full emulaiton*/
+	NO_EMULATE(MAINTENANCE_IN);           /*0xa3*/ /* IFT alua */
+	NO_EMULATE(MAINTENANCE_OUT);       /*0xa4*/ /* IFT alua */
+	NO_EMULATE(MOVE_MEDIUM);           /*0xa5*/ /* ch */
+	NO_EMULATE(EXCHANGE_MEDIUM);       /*0xa6*/ /* ch */
+	/*NO_EMULATE(READ_12);               *//*0xa8*/
+	/*NO_EMULATE(WRITE_12);              *//*0xaa*/
+	/*NO_EMULATE(WRITE_VERIFY_12);       *//*0xae*/
+	/*NO_EMULATE(SEARCH_HIGH_12);        *//*0xb0*/
+	/*NO_EMULATE(SEARCH_EQUAL_12);       *//*0xb1*/
+	/*NO_EMULATE(SEARCH_LOW_12);         *//*0xb2*/
+	NO_EMULATE(READ_ELEMENT_STATUS);   /*0xb8*/ /* ch */
+	NO_EMULATE(SEND_VOLUME_TAG);       /*0xb6*/ /* ch */
+	/*NO_EMULATE(WRITE_LONG_2);          *//*0xea*/
+	NO_EMULATE(READ_16);               /*0x88*/ /* sd >2TB */
+	NO_EMULATE(WRITE_16);              /*0x8a*/ /* sd >2TB */
+	NO_EMULATE(VERIFY_16);	           /*0x8f*/
+	NO_EMULATE(SERVICE_ACTION_IN);     /*0x9e*/ /* sd >2TB */
+
+/* st: QFA_REQUEST_BLOCK, QFA_SEEK_BLOCK might be needed ? */
+	/*
+	  Following commands require emulation.
+	*/
+	pre_function[REPORT_LUNS] = __report_luns;
+	bitmap[REPORT_LUNS] = (VSCSIIF_NEED_EMULATE_REQBUF |
+					VSCSIIF_NEED_EMULATE_RSPBUF);
+
+	return;
+}
diff --git a/drivers/scsi/xen-scsiback/interface.c b/drivers/scsi/xen-scsiback/interface.c
new file mode 100644
index 0000000..663568e
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/interface.c
@@ -0,0 +1,141 @@
+/*
+ * interface management.
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * Based on the blkback driver code.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <scsi/scsi.h>
+#include <scsi/scsi_host.h>
+#include <scsi/scsi_device.h>
+#include "common.h"
+
+#include <xen/evtchn.h>
+#include <linux/kthread.h>
+#include <linux/delay.h>
+
+
+static struct kmem_cache *scsiback_cachep;
+
+struct vscsibk_info *vscsibk_info_alloc(domid_t domid)
+{
+	struct vscsibk_info *info;
+
+	info = kmem_cache_zalloc(scsiback_cachep, GFP_KERNEL);
+	if (!info)
+		return ERR_PTR(-ENOMEM);
+
+	info->domid = domid;
+	spin_lock_init(&info->ring_lock);
+	atomic_set(&info->nr_unreplied_reqs, 0);
+	init_waitqueue_head(&info->wq);
+	init_waitqueue_head(&info->waiting_to_free);
+
+	return info;
+}
+
+int scsiback_init_sring(struct vscsibk_info *info,
+		unsigned long ring_ref, unsigned int evtchn)
+{
+	struct vscsiif_sring *sring;
+	int err;
+
+	if (!info)
+		return -ENODEV;
+
+	if (info->irq) {
+		printk(KERN_ERR "scsiback: Already connected through?\n");
+		return -1;
+	}
+
+	err = xenbus_map_ring_valloc(info->dev, ring_ref, &info->ring_area);
+	if (err < 0)
+		return -ENOMEM;
+
+	sring = (struct vscsiif_sring *) info->ring_area;
+	BACK_RING_INIT(&info->ring, sring, PAGE_SIZE);
+
+	err = bind_interdomain_evtchn_to_irqhandler(
+			info->domid, evtchn,
+			scsiback_intr, 0, "vscsiif-backend", info);
+	if (err < 0)
+		goto unmap_page;
+
+	info->irq = err;
+
+	return 0;
+
+unmap_page:
+	xenbus_unmap_ring_vfree(info->dev, info->ring_area);
+
+	return err;
+}
+
+void scsiback_disconnect(struct vscsibk_info *info)
+{
+	if (info->kthread) {
+		kthread_stop(info->kthread);
+		info->kthread = NULL;
+	}
+
+	wait_event(info->waiting_to_free,
+		atomic_read(&info->nr_unreplied_reqs) == 0);
+
+	if (info->irq) {
+		unbind_from_irqhandler(info->irq, info);
+		info->irq = 0;
+	}
+
+	if (info->ring.sring || info->ring_area) {
+		xenbus_unmap_ring_vfree(info->dev, info->ring_area);
+		info->ring.sring = NULL;
+		info->ring_area = NULL;
+	}
+}
+
+void scsiback_free(struct vscsibk_info *info)
+{
+	kmem_cache_free(scsiback_cachep, info);
+}
+
+int __init scsiback_interface_init(void)
+{
+	scsiback_cachep = kmem_cache_create("vscsiif_cache",
+		sizeof(struct vscsibk_info), 0, 0, NULL);
+	if (!scsiback_cachep) {
+		printk(KERN_ERR "scsiback: can't init scsi cache\n");
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+void scsiback_interface_exit(void)
+{
+	kmem_cache_destroy(scsiback_cachep);
+}
diff --git a/drivers/scsi/xen-scsiback/scsiback.c b/drivers/scsi/xen-scsiback/scsiback.c
new file mode 100644
index 0000000..a209f87
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/scsiback.c
@@ -0,0 +1,757 @@
+/*
+ * Xen SCSI backend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * Based on the blkback driver code.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/spinlock.h>
+#include <linux/kthread.h>
+#include <linux/list.h>
+#include <linux/delay.h>
+#include <xen/balloon.h>
+#include <asm/hypervisor.h>
+#include <scsi/scsi.h>
+#include <scsi/scsi_cmnd.h>
+#include <scsi/scsi_host.h>
+#include <scsi/scsi_device.h>
+#include <scsi/scsi_dbg.h>
+#include <scsi/scsi_eh.h>
+
+#include "common.h"
+
+
+struct list_head pending_free;
+DEFINE_SPINLOCK(pending_free_lock);
+DECLARE_WAIT_QUEUE_HEAD(pending_free_wq);
+
+int vscsiif_reqs = VSCSIIF_BACK_MAX_PENDING_REQS;
+module_param_named(reqs, vscsiif_reqs, int, 0);
+MODULE_PARM_DESC(reqs, "Number of scsiback requests to allocate");
+
+static unsigned int log_print_stat;
+module_param(log_print_stat, int, 0644);
+
+#define SCSIBACK_INVALID_HANDLE (~0)
+
+static pending_req_t *pending_reqs;
+static struct page **pending_pages;
+static grant_handle_t *pending_grant_handles;
+
+static int vaddr_pagenr(pending_req_t *req, int seg)
+{
+	return (req - pending_reqs) * VSCSIIF_SG_TABLESIZE + seg;
+}
+
+static unsigned long vaddr(pending_req_t *req, int seg)
+{
+	unsigned long pfn = page_to_pfn(pending_pages[vaddr_pagenr(req, seg)]);
+	return (unsigned long)pfn_to_kaddr(pfn);
+}
+
+#define pending_handle(_req, _seg) \
+	(pending_grant_handles[vaddr_pagenr(_req, _seg)])
+
+
+void scsiback_fast_flush_area(pending_req_t *req)
+{
+	struct gnttab_unmap_grant_ref unmap[VSCSIIF_SG_TABLESIZE];
+	unsigned int i, invcount = 0;
+	grant_handle_t handle;
+	int err;
+
+	if (req->nr_segments) {
+		for (i = 0; i < req->nr_segments; i++) {
+			handle = pending_handle(req, i);
+			if (handle == SCSIBACK_INVALID_HANDLE)
+				continue;
+			gnttab_set_unmap_op(&unmap[i], vaddr(req, i),
+						GNTMAP_host_map, handle);
+			pending_handle(req, i) = SCSIBACK_INVALID_HANDLE;
+			invcount++;
+		}
+
+		err = HYPERVISOR_grant_table_op(
+			GNTTABOP_unmap_grant_ref, unmap, invcount);
+		BUG_ON(err);
+		for (i = 0; i <invcount; i++) {
+			err = m2p_remove_override(
+				virt_to_page(unmap[i].host_addr), false);
+			WARN_ON(err);
+		}
+		kfree(req->sgl);
+	}
+
+	return;
+}
+
+
+static pending_req_t * alloc_req(struct vscsibk_info *info)
+{
+	pending_req_t *req = NULL;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pending_free_lock, flags);
+	if (!list_empty(&pending_free)) {
+		req = list_entry(pending_free.next, pending_req_t, free_list);
+		list_del(&req->free_list);
+	}
+	spin_unlock_irqrestore(&pending_free_lock, flags);
+	return req;
+}
+
+
+static void free_req(pending_req_t *req)
+{
+	unsigned long flags;
+	int was_empty;
+
+	spin_lock_irqsave(&pending_free_lock, flags);
+	was_empty = list_empty(&pending_free);
+	list_add(&req->free_list, &pending_free);
+	spin_unlock_irqrestore(&pending_free_lock, flags);
+	if (was_empty)
+		wake_up(&pending_free_wq);
+}
+
+
+static void scsiback_notify_work(struct vscsibk_info *info)
+{
+	info->waiting_reqs = 1;
+	wake_up(&info->wq);
+}
+
+void scsiback_do_resp_with_sense(char *sense_buffer, int32_t result,
+			uint32_t resid, pending_req_t *pending_req)
+{
+	vscsiif_response_t *ring_res;
+	struct vscsibk_info *info = pending_req->info;
+	int notify;
+	int more_to_do = 1;
+	struct scsi_sense_hdr sshdr;
+	unsigned long flags;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	spin_lock_irqsave(&info->ring_lock, flags);
+
+	ring_res = RING_GET_RESPONSE(&info->ring, info->ring.rsp_prod_pvt);
+	info->ring.rsp_prod_pvt++;
+
+	ring_res->rslt   = result;
+	ring_res->rqid   = pending_req->rqid;
+
+	if (sense_buffer != NULL) {
+		if (scsi_normalize_sense(sense_buffer,
+			sizeof(sense_buffer), &sshdr)) {
+
+			int len = 8 + sense_buffer[7];
+
+			if (len > VSCSIIF_SENSE_BUFFERSIZE)
+				len = VSCSIIF_SENSE_BUFFERSIZE;
+
+			memcpy(ring_res->sense_buffer, sense_buffer, len);
+			ring_res->sense_len = len;
+		}
+	} else {
+		ring_res->sense_len = 0;
+	}
+
+	ring_res->residual_len = resid;
+
+	RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&info->ring, notify);
+	if (info->ring.rsp_prod_pvt == info->ring.req_cons) {
+		RING_FINAL_CHECK_FOR_REQUESTS(&info->ring, more_to_do);
+	} else if (RING_HAS_UNCONSUMED_REQUESTS(&info->ring)) {
+		more_to_do = 1;
+	}
+
+	spin_unlock_irqrestore(&info->ring_lock, flags);
+
+	if (more_to_do)
+		scsiback_notify_work(info);
+
+	if (notify)
+		notify_remote_via_irq(info->irq);
+
+	free_req(pending_req);
+}
+
+static void scsiback_print_status(char *sense_buffer, int errors,
+					pending_req_t *pending_req)
+{
+	struct scsi_device *sdev = pending_req->sdev;
+
+	printk(KERN_ERR "scsiback: %d:%d:%d:%d ",sdev->host->host_no,
+			sdev->channel, sdev->id, sdev->lun);
+	printk(KERN_ERR "status = 0x%02x, message = 0x%02x, host = 0x%02x, driver = 0x%02x\n",
+			status_byte(errors), msg_byte(errors),
+			host_byte(errors), driver_byte(errors));
+
+	printk(KERN_ERR "scsiback: cmnd[0]=0x%02X\n",
+			pending_req->cmnd[0]);
+
+	if (CHECK_CONDITION & status_byte(errors))
+		__scsi_print_sense("scsiback", sense_buffer, SCSI_SENSE_BUFFERSIZE);
+}
+
+
+static void scsiback_cmd_done(struct request *req, int uptodate)
+{
+	pending_req_t *pending_req = req->end_io_data;
+	unsigned char *sense_buffer;
+	unsigned int resid;
+	int errors;
+
+	sense_buffer = req->sense;
+	resid        = blk_rq_bytes(req);
+	errors       = req->errors;
+
+	if (errors != 0) {
+		if (log_print_stat)
+			scsiback_print_status(sense_buffer, errors, pending_req);
+	}
+
+	/* The Host mode is through as for Emulation. */
+	if (pending_req->info->feature != VSCSI_TYPE_HOST)
+		scsiback_rsp_emulation(pending_req);
+
+	scsiback_fast_flush_area(pending_req);
+	scsiback_do_resp_with_sense(sense_buffer, errors, resid, pending_req);
+	scsiback_put(pending_req->info);
+
+	__blk_put_request(req->q, req);
+}
+
+
+static int scsiback_gnttab_data_map(vscsiif_request_t *ring_req,
+					pending_req_t *pending_req)
+{
+	u32 flags;
+	int write;
+	int i, err = 0;
+	unsigned int data_len = 0;
+	struct gnttab_map_grant_ref map[VSCSIIF_SG_TABLESIZE];
+	struct vscsibk_info *info   = pending_req->info;
+
+	int data_dir = pending_req->sc_data_direction;
+	unsigned int nr_segments = (unsigned int)pending_req->nr_segments;
+
+	write = (data_dir == DMA_TO_DEVICE);
+
+	if (nr_segments) {
+		struct scatterlist *sg;
+
+		/* free of (sgl) in fast_flush_area()*/
+		pending_req->sgl = kmalloc(sizeof(struct scatterlist) * nr_segments,
+						GFP_KERNEL);
+		if (!pending_req->sgl) {
+			printk(KERN_ERR "scsiback: %s: kmalloc() error.\n", __FUNCTION__);
+			return -ENOMEM;
+		}
+
+		sg_init_table(pending_req->sgl, nr_segments);
+
+		for (i = 0; i < nr_segments; i++) {
+			flags = GNTMAP_host_map;
+			if (write)
+				flags |= GNTMAP_readonly;
+
+			gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
+						ring_req->seg[i].gref,
+						info->domid);
+		}
+
+		err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, nr_segments);
+		BUG_ON(err);
+
+		/* Retry maps with GNTST_eagain */
+		for(i=0; i < nr_segments; i++) {
+		    while(unlikely(map[i].status == GNTST_eagain))
+		    {
+				msleep(10);
+				err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
+							&map[i],
+							1);
+				BUG_ON(err);
+		    }
+		}
+
+		for_each_sg (pending_req->sgl, sg, nr_segments, i) {
+			struct page *pg;
+
+			if (unlikely(map[i].status != 0)) {
+				printk(KERN_ERR "scsiback: invalid buffer -- could not remap it: " \
+					"%d/%d, err:%d\n", i, nr_segments, map[i].status);
+				map[i].handle = SCSIBACK_INVALID_HANDLE;
+				err |= 1;
+			}
+
+			pending_handle(pending_req, i) = map[i].handle;
+
+			if (err)
+				continue;
+
+			pg = pending_pages[vaddr_pagenr(pending_req, i)];
+
+			m2p_add_override(PFN_DOWN(map[i].dev_bus_addr), pg, false);
+			sg_set_page(sg, pg, ring_req->seg[i].length,
+				    ring_req->seg[i].offset);
+			data_len += sg->length;
+
+			barrier();
+			if (sg->offset >= PAGE_SIZE ||
+			    sg->length > PAGE_SIZE ||
+			    sg->offset + sg->length > PAGE_SIZE)
+				err |= 1;
+
+		}
+
+		if (err)
+			goto fail_flush;
+	}
+
+	pending_req->request_bufflen = data_len;
+
+	return 0;
+
+fail_flush:
+	scsiback_fast_flush_area(pending_req);
+	return -ENOMEM;
+}
+
+/* quoted scsi_lib.c/scsi_bi_endio */
+static void scsiback_bi_endio(struct bio *bio, int error)
+{
+	bio_put(bio);
+}
+
+
+
+/* quoted scsi_lib.c/scsi_req_map_sg . */
+static struct bio *request_map_sg(pending_req_t *pending_req)
+{
+	struct request_queue *q = pending_req->sdev->request_queue;
+	unsigned int nsegs = (unsigned int)pending_req->nr_segments;
+	unsigned int i, len, bytes, off, nr_pages, nr_vecs = 0;
+	struct scatterlist *sg;
+	struct page *page;
+	struct bio *bio = NULL, *bio_first = NULL, *bio_last = NULL;
+	int err;
+
+	for_each_sg (pending_req->sgl, sg, nsegs, i) {
+		page = sg_page(sg);
+		off = sg->offset;
+		len = sg->length;
+
+		nr_pages = (len + off + PAGE_SIZE - 1) >> PAGE_SHIFT;
+		while (len > 0) {
+			bytes = min_t(unsigned int, len, PAGE_SIZE - off);
+
+			if (!bio) {
+				nr_vecs = min_t(unsigned int, BIO_MAX_PAGES,
+					 	nr_pages);
+				nr_pages -= nr_vecs;
+				bio = bio_alloc(GFP_KERNEL, nr_vecs);
+				if (!bio) {
+					err = -ENOMEM;
+					goto free_bios;
+				}
+				bio->bi_end_io = scsiback_bi_endio;
+				if (bio_last)
+					bio_last->bi_next = bio;
+				else
+					bio_first = bio;
+				bio_last = bio;
+			}
+
+			if (bio_add_pc_page(q, bio, page, bytes, off) !=
+						bytes) {
+				bio_put(bio);
+				err = -EINVAL;
+				goto free_bios;
+			}
+
+			if (bio->bi_vcnt >= nr_vecs) {
+				bio->bi_flags &= ~(1 << BIO_SEG_VALID);
+				if (pending_req->sc_data_direction == WRITE)
+					bio->bi_rw |= REQ_WRITE;
+				bio = NULL;
+			}
+
+			page++;
+			len -= bytes;
+			off = 0;
+		}
+	}
+
+	return bio_first;
+
+free_bios:
+	while ((bio = bio_first) != NULL) {
+		bio_first = bio->bi_next;
+		bio_put(bio);
+	}
+
+	return ERR_PTR(err);
+}
+
+
+void scsiback_cmd_exec(pending_req_t *pending_req)
+{
+	int cmd_len  = (int)pending_req->cmd_len;
+	int data_dir = (int)pending_req->sc_data_direction;
+	unsigned int timeout;
+	struct request *rq;
+	int write;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	/* because it doesn't timeout backend earlier than frontend.*/
+	if (pending_req->timeout_per_command)
+		timeout = pending_req->timeout_per_command * HZ;
+	else
+		timeout = VSCSIIF_TIMEOUT;
+
+	write = (data_dir == DMA_TO_DEVICE);
+	if (pending_req->nr_segments) {
+		struct bio *bio = request_map_sg(pending_req);
+
+		if (IS_ERR(bio)) {
+			printk(KERN_ERR "scsiback: SG Request Map Error\n");
+			return;
+		}
+
+		rq = blk_make_request(pending_req->sdev->request_queue, bio,
+				      GFP_KERNEL);
+		if (IS_ERR(rq)) {
+			printk(KERN_ERR "scsiback: Make Request Error\n");
+			return;
+		}
+
+		rq->buffer = NULL;
+	} else {
+		rq = blk_get_request(pending_req->sdev->request_queue, write,
+				     GFP_KERNEL);
+		if (unlikely(!rq)) {
+			printk(KERN_ERR "scsiback: Get Request Error\n");
+			return;
+		}
+	}
+
+	rq->cmd_type = REQ_TYPE_BLOCK_PC;
+	rq->cmd_len = cmd_len;
+	memcpy(rq->cmd, pending_req->cmnd, cmd_len);
+
+	memset(pending_req->sense_buffer, 0, VSCSIIF_SENSE_BUFFERSIZE);
+	rq->sense       = pending_req->sense_buffer;
+	rq->sense_len = 0;
+
+	/* not allowed to retry in backend.                   */
+	rq->retries   = 0;
+	rq->timeout   = timeout;
+	rq->end_io_data = pending_req;
+
+	scsiback_get(pending_req->info);
+	blk_execute_rq_nowait(rq->q, NULL, rq, 1, scsiback_cmd_done);
+
+	return ;
+}
+
+
+static void scsiback_device_reset_exec(pending_req_t *pending_req)
+{
+	struct vscsibk_info *info = pending_req->info;
+	int err;
+	struct scsi_device *sdev = pending_req->sdev;
+
+	scsiback_get(info);
+	err = scsi_reset_provider(sdev, SCSI_TRY_RESET_DEVICE);
+
+	scsiback_do_resp_with_sense(NULL, err, 0, pending_req);
+	scsiback_put(info);
+
+	return;
+}
+
+
+irqreturn_t scsiback_intr(int irq, void *dev_id)
+{
+	scsiback_notify_work((struct vscsibk_info *)dev_id);
+	return IRQ_HANDLED;
+}
+
+static int prepare_pending_reqs(struct vscsibk_info *info,
+		vscsiif_request_t *ring_req, pending_req_t *pending_req)
+{
+	struct scsi_device *sdev;
+	struct ids_tuple vir;
+	int err = -EINVAL;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	pending_req->rqid       = ring_req->rqid;
+	pending_req->act        = ring_req->act;
+
+	pending_req->info       = info;
+
+	pending_req->v_chn = vir.chn = ring_req->channel;
+	pending_req->v_tgt = vir.tgt = ring_req->id;
+	vir.lun = ring_req->lun;
+
+	rmb();
+	sdev = scsiback_do_translation(info, &vir);
+	if (!sdev) {
+		pending_req->sdev = NULL;
+		DPRINTK("scsiback: doesn't exist.\n");
+		err = -ENODEV;
+		goto invalid_value;
+	}
+	pending_req->sdev = sdev;
+
+	/* request range check from frontend */
+	pending_req->sc_data_direction = ring_req->sc_data_direction;
+	barrier();
+	if ((pending_req->sc_data_direction != DMA_BIDIRECTIONAL) &&
+		(pending_req->sc_data_direction != DMA_TO_DEVICE) &&
+		(pending_req->sc_data_direction != DMA_FROM_DEVICE) &&
+		(pending_req->sc_data_direction != DMA_NONE)) {
+		DPRINTK("scsiback: invalid parameter data_dir = %d\n",
+			pending_req->sc_data_direction);
+		err = -EINVAL;
+		goto invalid_value;
+	}
+
+	pending_req->nr_segments = ring_req->nr_segments;
+	barrier();
+	if (pending_req->nr_segments > VSCSIIF_SG_TABLESIZE) {
+		DPRINTK("scsiback: invalid parameter nr_seg = %d\n",
+			pending_req->nr_segments);
+		err = -EINVAL;
+		goto invalid_value;
+	}
+
+	pending_req->cmd_len = ring_req->cmd_len;
+	barrier();
+	if (pending_req->cmd_len > VSCSIIF_MAX_COMMAND_SIZE) {
+		DPRINTK("scsiback: invalid parameter cmd_len = %d\n",
+			pending_req->cmd_len);
+		err = -EINVAL;
+		goto invalid_value;
+	}
+	memcpy(pending_req->cmnd, ring_req->cmnd, pending_req->cmd_len);
+
+	pending_req->timeout_per_command = ring_req->timeout_per_command;
+
+	if(scsiback_gnttab_data_map(ring_req, pending_req)) {
+		DPRINTK("scsiback: invalid buffer\n");
+		err = -EINVAL;
+		goto invalid_value;
+	}
+
+	return 0;
+
+invalid_value:
+	return err;
+}
+
+
+static int scsiback_do_cmd_fn(struct vscsibk_info *info)
+{
+	struct vscsiif_back_ring *ring = &info->ring;
+	vscsiif_request_t  *ring_req;
+
+	pending_req_t *pending_req;
+	RING_IDX rc, rp;
+	int err, more_to_do = 0;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	rc = ring->req_cons;
+	rp = ring->sring->req_prod;
+	rmb();
+
+	while ((rc != rp)) {
+		if (RING_REQUEST_CONS_OVERFLOW(ring, rc))
+			break;
+		pending_req = alloc_req(info);
+		if (NULL == pending_req) {
+			more_to_do = 1;
+			break;
+		}
+
+		ring_req = RING_GET_REQUEST(ring, rc);
+		ring->req_cons = ++rc;
+
+		err = prepare_pending_reqs(info, ring_req,
+						pending_req);
+		if (err == -EINVAL) {
+			scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << 24),
+				0, pending_req);
+			continue;
+		} else if (err == -ENODEV) {
+			scsiback_do_resp_with_sense(NULL, (DID_NO_CONNECT << 16),
+				0, pending_req);
+			continue;
+		}
+
+		if (pending_req->act == VSCSIIF_ACT_SCSI_CDB) {
+
+			/* The Host mode is through as for Emulation. */
+			if (info->feature == VSCSI_TYPE_HOST)
+				scsiback_cmd_exec(pending_req);
+			else
+				scsiback_req_emulation_or_cmdexec(pending_req);
+
+		} else if (pending_req->act == VSCSIIF_ACT_SCSI_RESET) {
+			scsiback_device_reset_exec(pending_req);
+		} else {
+			printk(KERN_ERR "scsiback: invalid parameter for request\n");
+			scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << 24),
+				0, pending_req);
+			continue;
+		}
+	}
+
+	if (RING_HAS_UNCONSUMED_REQUESTS(ring))
+		more_to_do = 1;
+
+	/* Yield point for this unbounded loop. */
+	cond_resched();
+
+	return more_to_do;
+}
+
+
+int scsiback_schedule(void *data)
+{
+	struct vscsibk_info *info = (struct vscsibk_info *)data;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(
+			info->wq,
+			info->waiting_reqs || kthread_should_stop());
+		wait_event_interruptible(
+			pending_free_wq,
+			!list_empty(&pending_free) || kthread_should_stop());
+
+		info->waiting_reqs = 0;
+		smp_mb();
+
+		if (scsiback_do_cmd_fn(info))
+			info->waiting_reqs = 1;
+	}
+
+	return 0;
+}
+
+
+static int __init scsiback_init(void)
+{
+	int i, mmap_pages;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	mmap_pages = vscsiif_reqs * VSCSIIF_SG_TABLESIZE;
+
+	pending_reqs          = kzalloc(sizeof(pending_reqs[0]) *
+					vscsiif_reqs, GFP_KERNEL);
+	pending_grant_handles = kmalloc(sizeof(pending_grant_handles[0]) *
+					mmap_pages, GFP_KERNEL);
+	pending_pages         = kzalloc(sizeof(pending_pages[0]) *
+					mmap_pages, GFP_KERNEL);
+
+	if (!pending_reqs || !pending_grant_handles || !pending_pages)
+		goto out_of_memory;
+
+	for (i = 0; i < mmap_pages; i++) {
+		pending_grant_handles[i] = SCSIBACK_INVALID_HANDLE;
+		pending_pages[i] = alloc_page(GFP_KERNEL);
+		if (pending_pages[i] == NULL)
+			goto out_of_memory;
+	}
+	if (scsiback_interface_init() < 0)
+		goto out_of_kmem;
+
+	memset(pending_reqs, 0, sizeof(pending_reqs));
+	INIT_LIST_HEAD(&pending_free);
+
+	for (i = 0; i < vscsiif_reqs; i++)
+		list_add_tail(&pending_reqs[i].free_list, &pending_free);
+
+	if (scsiback_xenbus_init())
+		goto out_of_xenbus;
+
+	scsiback_emulation_init();
+
+	return 0;
+
+out_of_xenbus:
+	scsiback_xenbus_unregister();
+out_of_kmem:
+	scsiback_interface_exit();
+out_of_memory:
+	if (pending_pages) {
+		for (i = 0; i < mmap_pages; i++) {
+			if (pending_pages[i])
+				__free_page(pending_pages[i]);
+		}
+		kfree(pending_pages);
+	}
+	kfree(pending_reqs);
+	kfree(pending_grant_handles);
+	printk(KERN_ERR "scsiback: %s: out of memory\n", __FUNCTION__);
+	return -ENOMEM;
+}
+
+
+static void __exit scsiback_exit(void)
+{
+	scsiback_xenbus_unregister();
+	scsiback_interface_exit();
+	kfree(pending_reqs);
+	kfree(pending_grant_handles);
+	if (pending_pages) {
+		unsigned int i;
+		unsigned int mmap_pages = vscsiif_reqs * VSCSIIF_SG_TABLESIZE;
+		for (i = 0; i < mmap_pages; i++) {
+			if (pending_pages[i])
+				__free_page(pending_pages[i]);
+		}
+		kfree(pending_pages);
+	}
+}
+
+module_init(scsiback_init);
+module_exit(scsiback_exit);
+
+MODULE_DESCRIPTION("Xen SCSI backend driver");
+MODULE_LICENSE("Dual BSD/GPL");
diff --git a/drivers/scsi/xen-scsiback/translate.c b/drivers/scsi/xen-scsiback/translate.c
new file mode 100644
index 0000000..36873cc
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/translate.c
@@ -0,0 +1,168 @@
+/*
+ * Xen SCSI backend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/list.h>
+#include <linux/gfp.h>
+
+#include "common.h"
+
+/*
+  Initialize the translation entry list
+*/
+void scsiback_init_translation_table(struct vscsibk_info *info)
+{
+	INIT_LIST_HEAD(&info->v2p_entry_lists);
+	spin_lock_init(&info->v2p_lock);
+}
+
+
+/*
+  Add a new translation entry
+*/
+int scsiback_add_translation_entry(struct vscsibk_info *info,
+			struct scsi_device *sdev, struct ids_tuple *v)
+{
+	int err = 0;
+	struct v2p_entry *entry;
+	struct v2p_entry *new;
+	struct list_head *head = &(info->v2p_entry_lists);
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->v2p_lock, flags);
+
+	/* Check double assignment to identical virtual ID */
+	list_for_each_entry(entry, head, l) {
+		if ((entry->v.chn == v->chn) &&
+		    (entry->v.tgt == v->tgt) &&
+		    (entry->v.lun == v->lun)) {
+			printk(KERN_WARNING "scsiback: Virtual ID is already used. "
+			       "Assignment was not performed.\n");
+			err = -EEXIST;
+			goto out;
+		}
+
+	}
+
+	/* Create a new translation entry and add to the list */
+	if ((new = kmalloc(sizeof(struct v2p_entry), GFP_ATOMIC)) == NULL) {
+		printk(KERN_ERR "scsiback: %s: kmalloc() error.\n", __FUNCTION__);
+		err = -ENOMEM;
+		goto out;
+	}
+	new->v = *v;
+	new->sdev = sdev;
+	list_add_tail(&new->l, head);
+
+out:
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+	return err;
+}
+
+
+/*
+  Delete the translation entry specfied
+*/
+int scsiback_del_translation_entry(struct vscsibk_info *info,
+				struct ids_tuple *v)
+{
+	struct v2p_entry *entry;
+	struct list_head *head = &(info->v2p_entry_lists);
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->v2p_lock, flags);
+	/* Find out the translation entry specified */
+	list_for_each_entry(entry, head, l) {
+		if ((entry->v.chn == v->chn) &&
+		    (entry->v.tgt == v->tgt) &&
+		    (entry->v.lun == v->lun)) {
+			goto found;
+		}
+	}
+
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+	return 1;
+
+found:
+	/* Delete the translation entry specfied */
+	scsi_device_put(entry->sdev);
+	list_del(&entry->l);
+	kfree(entry);
+
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+	return 0;
+}
+
+
+/*
+  Perform virtual to physical translation
+*/
+struct scsi_device *scsiback_do_translation(struct vscsibk_info *info,
+			struct ids_tuple *v)
+{
+	struct v2p_entry *entry;
+	struct list_head *head = &(info->v2p_entry_lists);
+	struct scsi_device *sdev = NULL;
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->v2p_lock, flags);
+	list_for_each_entry(entry, head, l) {
+		if ((entry->v.chn == v->chn) &&
+		    (entry->v.tgt == v->tgt) &&
+		    (entry->v.lun == v->lun)) {
+			sdev = entry->sdev;
+			goto out;
+		}
+	}
+out:
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+	return sdev;
+}
+
+
+/*
+  Release the translation entry specfied
+*/
+void scsiback_release_translation_entry(struct vscsibk_info *info)
+{
+	struct v2p_entry *entry, *tmp;
+	struct list_head *head = &(info->v2p_entry_lists);
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->v2p_lock, flags);
+	list_for_each_entry_safe(entry, tmp, head, l) {
+		scsi_device_put(entry->sdev);
+		list_del(&entry->l);
+		kfree(entry);
+	}
+
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+	return;
+
+}
diff --git a/drivers/scsi/xen-scsiback/xenbus.c b/drivers/scsi/xen-scsiback/xenbus.c
new file mode 100644
index 0000000..0816c0e
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/xenbus.c
@@ -0,0 +1,374 @@
+/*
+ * Xen SCSI backend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * Based on the blkback driver code.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <stdarg.h>
+#include <linux/module.h>
+#include <linux/kthread.h>
+#include <scsi/scsi.h>
+#include <scsi/scsi_host.h>
+#include <scsi/scsi_device.h>
+
+#include "common.h"
+
+struct backend_info
+{
+	struct xenbus_device *dev;
+	struct vscsibk_info *info;
+};
+
+
+static int __vscsiif_name(struct backend_info *be, char *buf)
+{
+	struct xenbus_device *dev = be->dev;
+	unsigned int domid, id;
+
+	sscanf(dev->nodename, "backend/vscsi/%u/%u", &domid, &id);
+	snprintf(buf, TASK_COMM_LEN, "vscsi.%u.%u", be->info->domid, id);
+
+	return 0;
+}
+
+static int scsiback_map(struct backend_info *be)
+{
+	struct xenbus_device *dev = be->dev;
+	unsigned long ring_ref = 0;
+	unsigned int evtchn = 0;
+	int err;
+	char name[TASK_COMM_LEN];
+
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+			"ring-ref", "%lu", &ring_ref,
+			"event-channel", "%u", &evtchn, NULL);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "reading %s ring", dev->otherend);
+		return err;
+	}
+	err = scsiback_init_sring(be->info, ring_ref, evtchn);
+	if (err)
+		return err;
+
+	err = __vscsiif_name(be, name);
+	if (err) {
+		xenbus_dev_error(dev, err, "get scsiback dev name");
+		return err;
+	}
+
+	be->info->kthread = kthread_run(scsiback_schedule, be->info, name);
+	if (IS_ERR(be->info->kthread)) {
+		err = PTR_ERR(be->info->kthread);
+		be->info->kthread = NULL;
+		xenbus_dev_error(be->dev, err, "start vscsiif");
+		return err;
+	}
+
+	return 0;
+}
+
+
+struct scsi_device *scsiback_get_scsi_device(struct ids_tuple *phy)
+{
+	struct Scsi_Host *shost;
+	struct scsi_device *sdev = NULL;
+
+	shost = scsi_host_lookup(phy->hst);
+	if (IS_ERR(shost)) {
+		printk(KERN_ERR "scsiback: host%d doesn't exist.\n",
+			phy->hst);
+		return NULL;
+	}
+	sdev   = scsi_device_lookup(shost, phy->chn, phy->tgt, phy->lun);
+	if (!sdev) {
+		printk(KERN_ERR "scsiback: %d:%d:%d:%d doesn't exist.\n",
+			phy->hst, phy->chn, phy->tgt, phy->lun);
+		scsi_host_put(shost);
+		return NULL;
+	}
+
+	scsi_host_put(shost);
+	return (sdev);
+}
+
+#define VSCSIBACK_OP_ADD_OR_DEL_LUN	1
+#define VSCSIBACK_OP_UPDATEDEV_STATE	2
+
+
+static void scsiback_do_lun_hotplug(struct backend_info *be, int op)
+{
+	int i, err = 0;
+	struct ids_tuple phy, vir;
+	int device_state;
+	char str[64], state_str[64];
+	char **dir;
+	unsigned int dir_n = 0;
+	struct xenbus_device *dev = be->dev;
+	struct scsi_device *sdev;
+
+	dir = xenbus_directory(XBT_NIL, dev->nodename, "vscsi-devs", &dir_n);
+	if (IS_ERR(dir))
+		return;
+
+	for (i = 0; i < dir_n; i++) {
+		/* read status */
+		snprintf(state_str, sizeof(state_str), "vscsi-devs/%s/state", dir[i]);
+		err = xenbus_scanf(XBT_NIL, dev->nodename, state_str, "%u",
+			&device_state);
+		if (XENBUS_EXIST_ERR(err))
+			continue;
+
+		/* physical SCSI device */
+		snprintf(str, sizeof(str), "vscsi-devs/%s/p-dev", dir[i]);
+		err = xenbus_scanf(XBT_NIL, dev->nodename, str,
+			"%u:%u:%u:%u", &phy.hst, &phy.chn, &phy.tgt, &phy.lun);
+		if (XENBUS_EXIST_ERR(err)) {
+			xenbus_printf(XBT_NIL, dev->nodename, state_str,
+					"%d", XenbusStateClosed);
+			continue;
+		}
+
+		/* virtual SCSI device */
+		snprintf(str, sizeof(str), "vscsi-devs/%s/v-dev", dir[i]);
+		err = xenbus_scanf(XBT_NIL, dev->nodename, str,
+			"%u:%u:%u:%u", &vir.hst, &vir.chn, &vir.tgt, &vir.lun);
+		if (XENBUS_EXIST_ERR(err)) {
+			xenbus_printf(XBT_NIL, dev->nodename, state_str,
+					"%d", XenbusStateClosed);
+			continue;
+		}
+
+		switch (op) {
+		case VSCSIBACK_OP_ADD_OR_DEL_LUN:
+			if (device_state == XenbusStateInitialising) {
+				sdev = scsiback_get_scsi_device(&phy);
+				if (!sdev)
+					xenbus_printf(XBT_NIL, dev->nodename, state_str,
+							    "%d", XenbusStateClosed);
+				else {
+					err = scsiback_add_translation_entry(be->info, sdev, &vir);
+					if (!err) {
+						if (xenbus_printf(XBT_NIL, dev->nodename, state_str,
+								    "%d", XenbusStateInitialised)) {
+							printk(KERN_ERR "scsiback: xenbus_printf error %s\n", state_str);
+							scsiback_del_translation_entry(be->info, &vir);
+						}
+					} else {
+						scsi_device_put(sdev);
+						xenbus_printf(XBT_NIL, dev->nodename, state_str,
+								    "%d", XenbusStateClosed);
+					}
+				}
+			}
+
+			if (device_state == XenbusStateClosing) {
+				if (!scsiback_del_translation_entry(be->info, &vir)) {
+					if (xenbus_printf(XBT_NIL, dev->nodename, state_str,
+							    "%d", XenbusStateClosed))
+						printk(KERN_ERR "scsiback: xenbus_printf error %s\n", state_str);
+				}
+			}
+			break;
+
+		case VSCSIBACK_OP_UPDATEDEV_STATE:
+			if (device_state == XenbusStateInitialised) {
+				/* modify vscsi-devs/dev-x/state */
+				if (xenbus_printf(XBT_NIL, dev->nodename, state_str,
+						    "%d", XenbusStateConnected)) {
+					printk(KERN_ERR "scsiback: xenbus_printf error %s\n", state_str);
+					scsiback_del_translation_entry(be->info, &vir);
+					xenbus_printf(XBT_NIL, dev->nodename, state_str,
+							    "%d", XenbusStateClosed);
+				}
+			}
+			break;
+		/*When it is necessary, processing is added here.*/
+		default:
+			break;
+		}
+	}
+
+	kfree(dir);
+	return ;
+}
+
+
+static void scsiback_frontend_changed(struct xenbus_device *dev,
+					enum xenbus_state frontend_state)
+{
+	struct backend_info *be = dev_get_drvdata(&dev->dev);
+	int err;
+
+	switch (frontend_state) {
+	case XenbusStateInitialising:
+		break;
+	case XenbusStateInitialised:
+		err = scsiback_map(be);
+		if (err)
+			break;
+
+		scsiback_do_lun_hotplug(be, VSCSIBACK_OP_ADD_OR_DEL_LUN);
+		xenbus_switch_state(dev, XenbusStateConnected);
+
+		break;
+	case XenbusStateConnected:
+
+		scsiback_do_lun_hotplug(be, VSCSIBACK_OP_UPDATEDEV_STATE);
+
+		if (dev->state == XenbusStateConnected)
+			break;
+
+		xenbus_switch_state(dev, XenbusStateConnected);
+
+		break;
+
+	case XenbusStateClosing:
+		scsiback_disconnect(be->info);
+		xenbus_switch_state(dev, XenbusStateClosing);
+		break;
+
+	case XenbusStateClosed:
+		xenbus_switch_state(dev, XenbusStateClosed);
+		if (xenbus_dev_is_online(dev))
+			break;
+		/* fall through if not online */
+	case XenbusStateUnknown:
+		device_unregister(&dev->dev);
+		break;
+
+	case XenbusStateReconfiguring:
+		scsiback_do_lun_hotplug(be, VSCSIBACK_OP_ADD_OR_DEL_LUN);
+
+		xenbus_switch_state(dev, XenbusStateReconfigured);
+
+		break;
+
+	default:
+		xenbus_dev_fatal(dev, -EINVAL, "saw state %d at frontend",
+					frontend_state);
+		break;
+	}
+}
+
+
+static int scsiback_remove(struct xenbus_device *dev)
+{
+	struct backend_info *be = dev_get_drvdata(&dev->dev);
+
+	if (be->info) {
+		scsiback_disconnect(be->info);
+		scsiback_release_translation_entry(be->info);
+		scsiback_free(be->info);
+		be->info = NULL;
+	}
+
+	kfree(be);
+	dev_set_drvdata(&dev->dev, NULL);
+
+	return 0;
+}
+
+
+static int scsiback_probe(struct xenbus_device *dev,
+			   const struct xenbus_device_id *id)
+{
+	int err;
+	unsigned val = 0;
+
+	struct backend_info *be = kzalloc(sizeof(struct backend_info),
+					  GFP_KERNEL);
+
+	if (!be) {
+		xenbus_dev_fatal(dev, -ENOMEM,
+				 "allocating backend structure");
+		return -ENOMEM;
+	}
+	be->dev = dev;
+	dev_set_drvdata(&dev->dev, be);
+
+	be->info = vscsibk_info_alloc(dev->otherend_id);
+	if (IS_ERR(be->info)) {
+		err = PTR_ERR(be->info);
+		be->info = NULL;
+		xenbus_dev_fatal(dev, err, "creating scsihost interface");
+		goto fail;
+	}
+
+	be->info->dev = dev;
+	be->info->irq = 0;
+	be->info->feature = 0;	/*default not HOSTMODE.*/
+
+	scsiback_init_translation_table(be->info);
+
+	err = xenbus_scanf(XBT_NIL, dev->nodename,
+				"feature-host", "%d", &val);
+	if (XENBUS_EXIST_ERR(err))
+		val = 0;
+
+	if (val)
+		be->info->feature = VSCSI_TYPE_HOST;
+
+	err = xenbus_switch_state(dev, XenbusStateInitWait);
+	if (err)
+		goto fail;
+
+	return 0;
+
+
+fail:
+	printk(KERN_WARNING "scsiback: %s failed\n",__func__);
+	scsiback_remove(dev);
+
+	return err;
+}
+
+
+static struct xenbus_device_id scsiback_ids[] = {
+	{ "vscsi" },
+	{ "" }
+};
+
+static struct xenbus_driver scsiback = {
+	.name			= "vscsi",
+	.owner			= THIS_MODULE,
+	.ids			= scsiback_ids,
+	.probe			= scsiback_probe,
+	.remove			= scsiback_remove,
+	.otherend_changed	= scsiback_frontend_changed
+};
+
+int scsiback_xenbus_init(void)
+{
+	return xenbus_register_backend(&scsiback);
+}
+
+void scsiback_xenbus_unregister(void)
+{
+	xenbus_unregister_driver(&scsiback);
+}
diff --git a/drivers/scsi/xen-scsifront/Makefile b/drivers/scsi/xen-scsifront/Makefile
new file mode 100644
index 0000000..18a5329
--- /dev/null
+++ b/drivers/scsi/xen-scsifront/Makefile
@@ -0,0 +1,4 @@
+
+obj-$(CONFIG_XEN_SCSI_FRONTEND)	:= xen-scsifront.o
+xen-scsifront-objs := scsifront.o xenbus.o
+
diff --git a/drivers/scsi/xen-scsifront/common.h b/drivers/scsi/xen-scsifront/common.h
new file mode 100644
index 0000000..cfa1c32
--- /dev/null
+++ b/drivers/scsi/xen-scsifront/common.h
@@ -0,0 +1,137 @@
+/*
+ * Xen SCSI frontend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_DRIVERS_SCSIFRONT_H__
+#define __XEN_DRIVERS_SCSIFRONT_H__
+
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/kthread.h>
+#include <linux/wait.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/sched.h>
+#include <linux/blkdev.h>
+#include <scsi/scsi_cmnd.h>
+#include <scsi/scsi_device.h>
+#include <scsi/scsi.h>
+#include <scsi/scsi_host.h>
+#include <asm/xen/page.h>
+#include <xen/xenbus.h>
+#include <xen/grant_table.h>
+#include <xen/events.h>
+#include <xen/evtchn.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/io/ring.h>
+#include <xen/interface/io/vscsiif.h>
+#include <xen/interface/grant_table.h>
+#include <xen/interface/io/protocols.h>
+#include <asm/delay.h>
+#include <asm/hypervisor.h>
+/*#include <asm/maddr.h>*/
+
+#ifdef HAVE_XEN_PLATFORM_COMPAT_H
+#include <xen/platform-compat.h>
+#endif
+
+#define GRANT_INVALID_REF	0
+#define VSCSI_IN_ABORT		1
+#define VSCSI_IN_RESET		2
+
+/* tuning point*/
+#define VSCSIIF_DEFAULT_CMD_PER_LUN 10
+#define VSCSIIF_MAX_TARGET          64
+#define VSCSIIF_MAX_LUN             255
+
+#define VSCSIIF_RING_SIZE	__CONST_RING_SIZE(vscsiif, PAGE_SIZE)
+#define VSCSIIF_MAX_REQS	VSCSIIF_RING_SIZE
+
+struct vscsifrnt_shadow {
+	uint16_t next_free;
+
+	/* command between backend and frontend
+	 * VSCSIIF_ACT_SCSI_CDB or VSCSIIF_ACT_SCSI_RESET */
+	unsigned char act;
+
+	/* do reset function */
+	wait_queue_head_t wq_reset;	/* reset work queue           */
+	int wait_reset;			/* reset work queue condition */
+	int32_t rslt_reset;		/* reset response status      */
+					/* (SUCESS or FAILED)         */
+
+	/* for DMA_TO_DEVICE(1), DMA_FROM_DEVICE(2), DMA_NONE(3)
+	   requests */
+	unsigned int sc_data_direction;
+
+	/* Number of pieces of scatter-gather */
+	unsigned int nr_segments;
+
+	/* requested struct scsi_cmnd is stored from kernel */
+	unsigned long req_scsi_cmnd;
+	int gref[VSCSIIF_SG_TABLESIZE];
+};
+
+struct vscsifrnt_info {
+	struct xenbus_device *dev;
+
+	struct Scsi_Host *host;
+
+	spinlock_t io_lock;
+	spinlock_t shadow_lock;
+	unsigned int evtchn;
+	unsigned int irq;
+
+	grant_ref_t ring_ref;
+	struct vscsiif_front_ring ring;
+	struct vscsiif_response	ring_res;
+
+	struct vscsifrnt_shadow shadow[VSCSIIF_MAX_REQS];
+	uint32_t shadow_free;
+
+	struct task_struct *kthread;
+	wait_queue_head_t wq;
+	unsigned int waiting_resp;
+
+};
+
+#define DPRINTK(_f, _a...)				\
+	pr_debug("(file=%s, line=%d) " _f,	\
+		 __FILE__ , __LINE__ , ## _a )
+
+int scsifront_xenbus_init(void);
+void scsifront_xenbus_unregister(void);
+int scsifront_schedule(void *data);
+irqreturn_t scsifront_intr(int irq, void *dev_id);
+int scsifront_cmd_done(struct vscsifrnt_info *info);
+
+
+#endif /* __XEN_DRIVERS_SCSIFRONT_H__  */
diff --git a/drivers/scsi/xen-scsifront/scsifront.c b/drivers/scsi/xen-scsifront/scsifront.c
new file mode 100644
index 0000000..2d5e25f
--- /dev/null
+++ b/drivers/scsi/xen-scsifront/scsifront.c
@@ -0,0 +1,469 @@
+/*
+ * Xen SCSI frontend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/version.h>
+#include "common.h"
+
+static int get_id_from_freelist(struct vscsifrnt_info *info)
+{
+	unsigned long flags;
+	uint32_t free;
+
+	spin_lock_irqsave(&info->shadow_lock, flags);
+
+	free = info->shadow_free;
+	BUG_ON(free > VSCSIIF_MAX_REQS);
+	info->shadow_free = info->shadow[free].next_free;
+	info->shadow[free].next_free = 0x0fff;
+
+	info->shadow[free].wait_reset = 0;
+
+	spin_unlock_irqrestore(&info->shadow_lock, flags);
+
+	return free;
+}
+
+static void add_id_to_freelist(struct vscsifrnt_info *info, uint32_t id)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->shadow_lock, flags);
+
+	info->shadow[id].next_free  = info->shadow_free;
+	info->shadow[id].req_scsi_cmnd = 0;
+	info->shadow_free = id;
+
+	spin_unlock_irqrestore(&info->shadow_lock, flags);
+}
+
+
+struct vscsiif_request * scsifront_pre_request(struct vscsifrnt_info *info)
+{
+	struct vscsiif_front_ring *ring = &(info->ring);
+	vscsiif_request_t *ring_req;
+	uint32_t id;
+
+	ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
+
+	ring->req_prod_pvt++;
+
+	id = get_id_from_freelist(info);	/* use id by response */
+	ring_req->rqid = (uint16_t)id;
+
+	return ring_req;
+}
+
+
+static void scsifront_notify_work(struct vscsifrnt_info *info)
+{
+	info->waiting_resp = 1;
+	wake_up(&info->wq);
+}
+
+
+static void scsifront_do_request(struct vscsifrnt_info *info)
+{
+	struct vscsiif_front_ring *ring = &(info->ring);
+	unsigned int irq = info->irq;
+	int notify;
+
+	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(ring, notify);
+	if (notify)
+		notify_remote_via_irq(irq);
+}
+
+irqreturn_t scsifront_intr(int irq, void *dev_id)
+{
+	scsifront_notify_work((struct vscsifrnt_info *)dev_id);
+	return IRQ_HANDLED;
+}
+
+
+static void scsifront_gnttab_done(struct vscsifrnt_shadow *s, uint32_t id)
+{
+	int i;
+
+	if (s->sc_data_direction == DMA_NONE)
+		return;
+
+	if (s->nr_segments) {
+		for (i = 0; i < s->nr_segments; i++) {
+			if (unlikely(gnttab_query_foreign_access(
+				s->gref[i]) != 0)) {
+				printk(KERN_ALERT "scsifront: "
+					"grant still in use by backend.\n");
+				BUG();
+			}
+			gnttab_end_foreign_access(s->gref[i], 0, 0UL);
+		}
+	}
+
+	return;
+}
+
+
+static void scsifront_cdb_cmd_done(struct vscsifrnt_info *info,
+		       vscsiif_response_t *ring_res)
+{
+	struct scsi_cmnd *sc;
+	uint32_t id;
+	uint8_t sense_len;
+
+	id = ring_res->rqid;
+	sc = (struct scsi_cmnd *)info->shadow[id].req_scsi_cmnd;
+
+	if (sc == NULL)
+		BUG();
+
+	scsifront_gnttab_done(&info->shadow[id], id);
+	add_id_to_freelist(info, id);
+
+	sc->result = ring_res->rslt;
+	scsi_set_resid(sc, ring_res->residual_len);
+
+	if (ring_res->sense_len > VSCSIIF_SENSE_BUFFERSIZE)
+		sense_len = VSCSIIF_SENSE_BUFFERSIZE;
+	else
+		sense_len = ring_res->sense_len;
+
+	if (sense_len)
+		memcpy(sc->sense_buffer, ring_res->sense_buffer, sense_len);
+
+	sc->scsi_done(sc);
+
+	return;
+}
+
+
+static void scsifront_sync_cmd_done(struct vscsifrnt_info *info,
+				vscsiif_response_t *ring_res)
+{
+	uint16_t id = ring_res->rqid;
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->shadow_lock, flags);
+	info->shadow[id].wait_reset = 1;
+	info->shadow[id].rslt_reset = ring_res->rslt;
+	spin_unlock_irqrestore(&info->shadow_lock, flags);
+
+	wake_up(&(info->shadow[id].wq_reset));
+}
+
+
+int scsifront_cmd_done(struct vscsifrnt_info *info)
+{
+	vscsiif_response_t *ring_res;
+
+	RING_IDX i, rp;
+	int more_to_do = 0;
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->io_lock, flags);
+
+	rp = info->ring.sring->rsp_prod;
+	rmb();
+	for (i = info->ring.rsp_cons; i != rp; i++) {
+
+		ring_res = RING_GET_RESPONSE(&info->ring, i);
+
+		if (info->shadow[ring_res->rqid].act == VSCSIIF_ACT_SCSI_CDB)
+			scsifront_cdb_cmd_done(info, ring_res);
+		else
+			scsifront_sync_cmd_done(info, ring_res);
+	}
+
+	info->ring.rsp_cons = i;
+
+	if (i != info->ring.req_prod_pvt) {
+		RING_FINAL_CHECK_FOR_RESPONSES(&info->ring, more_to_do);
+	} else {
+		info->ring.sring->rsp_event = i + 1;
+	}
+
+	spin_unlock_irqrestore(&info->io_lock, flags);
+
+
+	/* Yield point for this unbounded loop. */
+	cond_resched();
+
+	return more_to_do;
+}
+
+
+
+
+int scsifront_schedule(void *data)
+{
+	struct vscsifrnt_info *info = (struct vscsifrnt_info *)data;
+
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(
+			info->wq,
+			info->waiting_resp || kthread_should_stop());
+
+		info->waiting_resp = 0;
+		smp_mb();
+
+		if (scsifront_cmd_done(info))
+			info->waiting_resp = 1;
+	}
+
+	return 0;
+}
+
+
+
+static int map_data_for_request(struct vscsifrnt_info *info,
+		struct scsi_cmnd *sc, vscsiif_request_t *ring_req, uint32_t id)
+{
+	grant_ref_t gref_head;
+	int err, ref, ref_cnt = 0;
+	int write = (sc->sc_data_direction == DMA_TO_DEVICE);
+	unsigned int i, nr_pages, off, len, bytes;
+	unsigned long buffer_mfn, buffer_pfn;
+
+	if (sc->sc_data_direction == DMA_NONE)
+		return 0;
+
+	err = gnttab_alloc_grant_references(VSCSIIF_SG_TABLESIZE, &gref_head);
+	if (err) {
+		printk(KERN_ERR "scsifront: gnttab_alloc_grant_references() error\n");
+		return -ENOMEM;
+	}
+
+	if (scsi_bufflen(sc)) {
+		/* quoted scsi_lib.c/scsi_req_map_sg . */
+		struct scatterlist *sg, *sgl = scsi_sglist(sc);
+		unsigned int data_len = scsi_bufflen(sc);
+
+		nr_pages = (data_len + sgl->offset + PAGE_SIZE - 1) >> PAGE_SHIFT;
+		if (nr_pages > VSCSIIF_SG_TABLESIZE) {
+			printk(KERN_ERR "scsifront: Unable to map request_buffer for command!\n");
+			ref_cnt = (-E2BIG);
+			goto big_to_sg;
+		}
+
+		for_each_sg (sgl, sg, scsi_sg_count(sc), i) {
+			off = sg->offset;
+			len = sg->length;
+
+			buffer_pfn = page_to_pfn(sg_page(sg));
+			while (len > 0 && data_len > 0) {
+				/*
+				 * sg sends a scatterlist that is larger than
+				 * the data_len it wants transferred for certain
+				 * IO sizes
+				 */
+				bytes = min_t(unsigned int, len, PAGE_SIZE - off);
+				bytes = min(bytes, data_len);
+
+				ref = gnttab_claim_grant_reference(&gref_head);
+				BUG_ON(ref == -ENOSPC);
+
+				buffer_mfn = pfn_to_mfn(buffer_pfn);
+				gnttab_grant_foreign_access_ref(ref, info->dev->otherend_id,
+					buffer_mfn, write);
+
+				info->shadow[id].gref[ref_cnt]  = ref;
+				ring_req->seg[ref_cnt].gref     = ref;
+				ring_req->seg[ref_cnt].offset   = (uint16_t)off;
+				ring_req->seg[ref_cnt].length   = (uint16_t)bytes;
+
+				buffer_pfn ++;
+				len -= bytes;
+				data_len -= bytes;
+				off = 0;
+				ref_cnt++;
+			}
+		}
+	}
+
+big_to_sg:
+
+	gnttab_free_grant_references(gref_head);
+
+	return ref_cnt;
+}
+
+static int scsifront_queuecommand(struct Scsi_Host *h, struct scsi_cmnd *sc)
+{
+	struct vscsifrnt_info *info =
+		(struct vscsifrnt_info *) sc->device->host->hostdata;
+	vscsiif_request_t *ring_req;
+	int ref_cnt;
+	uint16_t rqid;
+
+	if (RING_FULL(&info->ring)) {
+		goto out_host_busy;
+	}
+
+	sc->result    = 0;
+
+	ring_req          = scsifront_pre_request(info);
+	rqid              = ring_req->rqid;
+	ring_req->act     = VSCSIIF_ACT_SCSI_CDB;
+
+	ring_req->id      = sc->device->id;
+	ring_req->lun     = sc->device->lun;
+	ring_req->channel = sc->device->channel;
+	ring_req->cmd_len = sc->cmd_len;
+
+	BUG_ON(sc->cmd_len > VSCSIIF_MAX_COMMAND_SIZE);
+
+	if (sc->cmd_len)
+		memcpy(ring_req->cmnd, sc->cmnd, sc->cmd_len);
+	else
+		memset(ring_req->cmnd, 0, VSCSIIF_MAX_COMMAND_SIZE);
+
+	ring_req->sc_data_direction   = (uint8_t)sc->sc_data_direction;
+	ring_req->timeout_per_command = (sc->request->timeout / HZ);
+
+	info->shadow[rqid].req_scsi_cmnd     = (unsigned long)sc;
+	info->shadow[rqid].sc_data_direction = sc->sc_data_direction;
+	info->shadow[rqid].act               = ring_req->act;
+
+	ref_cnt = map_data_for_request(info, sc, ring_req, rqid);
+	if (ref_cnt < 0) {
+		add_id_to_freelist(info, rqid);
+		if (ref_cnt == (-ENOMEM))
+			goto out_host_busy;
+		else {
+			sc->result = (DID_ERROR << 16);
+			goto out_fail_command;
+		}
+	}
+
+	ring_req->nr_segments          = (uint8_t)ref_cnt;
+	info->shadow[rqid].nr_segments = ref_cnt;
+
+	scsifront_do_request(info);
+
+	return 0;
+
+out_host_busy:
+	return SCSI_MLQUEUE_HOST_BUSY;
+
+out_fail_command:
+	sc->scsi_done(sc);
+	return 0;
+}
+
+
+static int scsifront_eh_abort_handler(struct scsi_cmnd *sc)
+{
+	return (FAILED);
+}
+
+/* vscsi supports only device_reset, because it is each of LUNs */
+static int scsifront_dev_reset_handler(struct scsi_cmnd *sc)
+{
+	struct Scsi_Host *host = sc->device->host;
+	struct vscsifrnt_info *info =
+		(struct vscsifrnt_info *) sc->device->host->hostdata;
+
+	vscsiif_request_t *ring_req;
+	uint16_t rqid;
+	int err;
+
+	spin_lock_irq(host->host_lock);
+
+	ring_req      = scsifront_pre_request(info);
+	ring_req->act = VSCSIIF_ACT_SCSI_RESET;
+
+	rqid          = ring_req->rqid;
+	info->shadow[rqid].act = VSCSIIF_ACT_SCSI_RESET;
+
+	ring_req->channel = sc->device->channel;
+	ring_req->id      = sc->device->id;
+	ring_req->lun     = sc->device->lun;
+	ring_req->cmd_len = sc->cmd_len;
+
+	if ( sc->cmd_len )
+		memcpy(ring_req->cmnd, sc->cmnd, sc->cmd_len);
+	else
+		memset(ring_req->cmnd, 0, VSCSIIF_MAX_COMMAND_SIZE);
+
+	ring_req->sc_data_direction   = (uint8_t)sc->sc_data_direction;
+	ring_req->timeout_per_command = (sc->request->timeout / HZ);
+	ring_req->nr_segments         = 0;
+
+	scsifront_do_request(info);
+
+	spin_unlock_irq(host->host_lock);
+	wait_event_interruptible(info->shadow[rqid].wq_reset,
+			 info->shadow[rqid].wait_reset);
+	spin_lock_irq(host->host_lock);
+
+	err = info->shadow[rqid].rslt_reset;
+
+	add_id_to_freelist(info, rqid);
+
+	spin_unlock_irq(host->host_lock);
+	return (err);
+}
+
+
+struct scsi_host_template scsifront_sht = {
+	.module			= THIS_MODULE,
+	.name			= "Xen SCSI frontend driver",
+	.queuecommand		= scsifront_queuecommand,
+	.eh_abort_handler	= scsifront_eh_abort_handler,
+	.eh_device_reset_handler= scsifront_dev_reset_handler,
+	.cmd_per_lun		= VSCSIIF_DEFAULT_CMD_PER_LUN,
+	.can_queue		= VSCSIIF_MAX_REQS,
+	.this_id 		= -1,
+	.sg_tablesize		= VSCSIIF_SG_TABLESIZE,
+	.use_clustering		= DISABLE_CLUSTERING,
+	.proc_name		= "scsifront",
+};
+
+
+static int __init scsifront_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = scsifront_xenbus_init();
+
+	return err;
+}
+
+static void __exit scsifront_exit(void)
+{
+	scsifront_xenbus_unregister();
+}
+
+module_init(scsifront_init);
+module_exit(scsifront_exit);
+
+MODULE_DESCRIPTION("Xen SCSI frontend driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/scsi/xen-scsifront/xenbus.c b/drivers/scsi/xen-scsifront/xenbus.c
new file mode 100644
index 0000000..3b9f04a
--- /dev/null
+++ b/drivers/scsi/xen-scsifront/xenbus.c
@@ -0,0 +1,414 @@
+/*
+ * Xen SCSI frontend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/version.h>
+#include "common.h"
+
+extern struct scsi_host_template scsifront_sht;
+
+static void scsifront_free(struct vscsifrnt_info *info)
+{
+	struct Scsi_Host *host = info->host;
+
+	if (host->shost_state != SHOST_DEL)
+		scsi_remove_host(info->host);
+
+	if (info->ring_ref != GRANT_INVALID_REF) {
+		gnttab_end_foreign_access(info->ring_ref,
+					0, (unsigned long)info->ring.sring);
+		info->ring_ref = GRANT_INVALID_REF;
+		info->ring.sring = NULL;
+	}
+
+	if (info->irq)
+		unbind_from_irqhandler(info->irq, info);
+	info->irq = 0;
+
+	scsi_host_put(info->host);
+}
+
+
+static int scsifront_alloc_ring(struct vscsifrnt_info *info)
+{
+	struct xenbus_device *dev = info->dev;
+	struct vscsiif_sring *sring;
+	int err = -ENOMEM;
+
+
+	info->ring_ref = GRANT_INVALID_REF;
+
+	/***** Frontend to Backend ring start *****/
+	sring = (struct vscsiif_sring *) __get_free_page(GFP_KERNEL);
+	if (!sring) {
+		xenbus_dev_fatal(dev, err, "fail to allocate shared ring (Front to Back)");
+		return err;
+	}
+	SHARED_RING_INIT(sring);
+	FRONT_RING_INIT(&info->ring, sring, PAGE_SIZE);
+
+	err = xenbus_grant_ring(dev, virt_to_mfn(sring));
+	if (err < 0) {
+		free_page((unsigned long) sring);
+		info->ring.sring = NULL;
+		xenbus_dev_fatal(dev, err, "fail to grant shared ring (Front to Back)");
+		goto free_sring;
+	}
+	info->ring_ref = err;
+
+	err = xenbus_alloc_evtchn(dev, &info->evtchn);
+	if (err)
+		goto free_sring;
+
+	err = bind_evtchn_to_irqhandler(
+			info->evtchn, scsifront_intr,
+			IRQF_SAMPLE_RANDOM, "scsifront", info);
+
+	if (err <= 0) {
+		xenbus_dev_fatal(dev, err, "bind_evtchn_to_irqhandler");
+		goto free_sring;
+	}
+	info->irq = err;
+
+	return 0;
+
+/* free resource */
+free_sring:
+	scsifront_free(info);
+
+	return err;
+}
+
+
+static int scsifront_init_ring(struct vscsifrnt_info *info)
+{
+	struct xenbus_device *dev = info->dev;
+	struct xenbus_transaction xbt;
+	int err;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	err = scsifront_alloc_ring(info);
+	if (err)
+		return err;
+	DPRINTK("%u %u\n", info->ring_ref, info->evtchn);
+
+again:
+	err = xenbus_transaction_start(&xbt);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "starting transaction");
+	}
+
+	err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u",
+				info->ring_ref);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "%s", "writing ring-ref");
+		goto fail;
+	}
+
+	err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+				info->evtchn);
+
+	if (err) {
+		xenbus_dev_fatal(dev, err, "%s", "writing event-channel");
+		goto fail;
+	}
+
+	err = xenbus_transaction_end(xbt, 0);
+	if (err) {
+		if (err == -EAGAIN)
+			goto again;
+		xenbus_dev_fatal(dev, err, "completing transaction");
+		goto free_sring;
+	}
+
+	return 0;
+
+fail:
+	xenbus_transaction_end(xbt, 1);
+free_sring:
+	/* free resource */
+	scsifront_free(info);
+
+	return err;
+}
+
+
+static int scsifront_probe(struct xenbus_device *dev,
+				const struct xenbus_device_id *id)
+{
+	struct vscsifrnt_info *info;
+	struct Scsi_Host *host;
+	int i, err = -ENOMEM;
+	char name[TASK_COMM_LEN];
+
+	host = scsi_host_alloc(&scsifront_sht, sizeof(*info));
+	if (!host) {
+		xenbus_dev_fatal(dev, err, "fail to allocate scsi host");
+		return err;
+	}
+	info = (struct vscsifrnt_info *) host->hostdata;
+	info->host = host;
+
+
+	dev_set_drvdata(&dev->dev, info);
+	info->dev  = dev;
+
+	for (i = 0; i < VSCSIIF_MAX_REQS; i++) {
+		info->shadow[i].next_free = i + 1;
+		init_waitqueue_head(&(info->shadow[i].wq_reset));
+		info->shadow[i].wait_reset = 0;
+	}
+	info->shadow[VSCSIIF_MAX_REQS - 1].next_free = 0x0fff;
+
+	err = scsifront_init_ring(info);
+	if (err) {
+		scsi_host_put(host);
+		return err;
+	}
+
+	init_waitqueue_head(&info->wq);
+	spin_lock_init(&info->io_lock);
+	spin_lock_init(&info->shadow_lock);
+
+	snprintf(name, TASK_COMM_LEN, "vscsiif.%d", info->host->host_no);
+
+	info->kthread = kthread_run(scsifront_schedule, info, name);
+	if (IS_ERR(info->kthread)) {
+		err = PTR_ERR(info->kthread);
+		info->kthread = NULL;
+		printk(KERN_ERR "scsifront: kthread start err %d\n", err);
+		goto free_sring;
+	}
+
+	host->max_id      = VSCSIIF_MAX_TARGET;
+	host->max_channel = 0;
+	host->max_lun     = VSCSIIF_MAX_LUN;
+	host->max_sectors = (VSCSIIF_SG_TABLESIZE - 1) * PAGE_SIZE / 512;
+	host->max_cmd_len = VSCSIIF_MAX_COMMAND_SIZE;
+
+	err = scsi_add_host(host, &dev->dev);
+	if (err) {
+		printk(KERN_ERR "scsifront: fail to add scsi host %d\n", err);
+		goto free_sring;
+	}
+
+	xenbus_switch_state(dev, XenbusStateInitialised);
+
+	return 0;
+
+free_sring:
+	/* free resource */
+	scsifront_free(info);
+	return err;
+}
+
+static int scsifront_remove(struct xenbus_device *dev)
+{
+	struct vscsifrnt_info *info = dev_get_drvdata(&dev->dev);
+
+	DPRINTK("%s: %s removed\n",__FUNCTION__ ,dev->nodename);
+
+	if (info->kthread) {
+		kthread_stop(info->kthread);
+		info->kthread = NULL;
+	}
+
+	scsifront_free(info);
+
+	return 0;
+}
+
+
+static int scsifront_disconnect(struct vscsifrnt_info *info)
+{
+	struct xenbus_device *dev = info->dev;
+	struct Scsi_Host *host = info->host;
+
+	DPRINTK("%s: %s disconnect\n",__FUNCTION__ ,dev->nodename);
+
+	/*
+	  When this function is executed,  all devices of
+	  Frontend have been deleted.
+	  Therefore, it need not block I/O before remove_host.
+	*/
+
+	scsi_remove_host(host);
+	xenbus_frontend_closed(dev);
+
+	return 0;
+}
+
+#define VSCSIFRONT_OP_ADD_LUN	1
+#define VSCSIFRONT_OP_DEL_LUN	2
+
+static void scsifront_do_lun_hotplug(struct vscsifrnt_info *info, int op)
+{
+	struct xenbus_device *dev = info->dev;
+	int i, err = 0;
+	char str[64], state_str[64];
+	char **dir;
+	unsigned int dir_n = 0;
+	unsigned int device_state;
+	unsigned int hst, chn, tgt, lun;
+	struct scsi_device *sdev;
+
+	dir = xenbus_directory(XBT_NIL, dev->otherend, "vscsi-devs", &dir_n);
+	if (IS_ERR(dir))
+		return;
+
+	for (i = 0; i < dir_n; i++) {
+		/* read status */
+		snprintf(str, sizeof(str), "vscsi-devs/%s/state", dir[i]);
+		err = xenbus_scanf(XBT_NIL, dev->otherend, str, "%u",
+			&device_state);
+		if (XENBUS_EXIST_ERR(err))
+			continue;
+
+		/* virtual SCSI device */
+		snprintf(str, sizeof(str), "vscsi-devs/%s/v-dev", dir[i]);
+		err = xenbus_scanf(XBT_NIL, dev->otherend, str,
+			"%u:%u:%u:%u", &hst, &chn, &tgt, &lun);
+		if (XENBUS_EXIST_ERR(err))
+			continue;
+
+		/* front device state path */
+		snprintf(state_str, sizeof(state_str), "vscsi-devs/%s/state", dir[i]);
+
+		switch (op) {
+		case VSCSIFRONT_OP_ADD_LUN:
+			if (device_state == XenbusStateInitialised) {
+				sdev = scsi_device_lookup(info->host, chn, tgt, lun);
+				if (sdev) {
+					printk(KERN_ERR "scsifront: Device already in use.\n");
+					scsi_device_put(sdev);
+					xenbus_printf(XBT_NIL, dev->nodename,
+						state_str, "%d", XenbusStateClosed);
+				} else {
+					scsi_add_device(info->host, chn, tgt, lun);
+					xenbus_printf(XBT_NIL, dev->nodename,
+						state_str, "%d", XenbusStateConnected);
+				}
+			}
+			break;
+		case VSCSIFRONT_OP_DEL_LUN:
+			if (device_state == XenbusStateClosing) {
+				sdev = scsi_device_lookup(info->host, chn, tgt, lun);
+				if (sdev) {
+					scsi_remove_device(sdev);
+					scsi_device_put(sdev);
+					xenbus_printf(XBT_NIL, dev->nodename,
+						state_str, "%d", XenbusStateClosed);
+				}
+			}
+			break;
+		default:
+			break;
+		}
+	}
+
+	kfree(dir);
+	return;
+}
+
+
+
+
+static void scsifront_backend_changed(struct xenbus_device *dev,
+				enum xenbus_state backend_state)
+{
+	struct vscsifrnt_info *info = dev_get_drvdata(&dev->dev);
+
+	DPRINTK("%p %u %u\n", dev, dev->state, backend_state);
+
+	switch (backend_state) {
+	case XenbusStateUnknown:
+	case XenbusStateInitialising:
+	case XenbusStateInitWait:
+	case XenbusStateClosed:
+		break;
+
+	case XenbusStateInitialised:
+		break;
+
+	case XenbusStateConnected:
+		if (xenbus_read_driver_state(dev->nodename) ==
+			XenbusStateInitialised) {
+			scsifront_do_lun_hotplug(info, VSCSIFRONT_OP_ADD_LUN);
+		}
+
+		if (dev->state == XenbusStateConnected)
+			break;
+
+		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateClosing:
+		scsifront_disconnect(info);
+		break;
+
+	case XenbusStateReconfiguring:
+		scsifront_do_lun_hotplug(info, VSCSIFRONT_OP_DEL_LUN);
+		xenbus_switch_state(dev, XenbusStateReconfiguring);
+		break;
+
+	case XenbusStateReconfigured:
+		scsifront_do_lun_hotplug(info, VSCSIFRONT_OP_ADD_LUN);
+		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+	}
+}
+
+
+static struct xenbus_device_id scsifront_ids[] = {
+	{ "vscsi" },
+	{ "" }
+};
+MODULE_ALIAS("xen:vscsi");
+
+static struct xenbus_driver scsifront_driver = {
+	.name			= "vscsi",
+	.owner			= THIS_MODULE,
+	.ids			= scsifront_ids,
+	.probe			= scsifront_probe,
+	.remove			= scsifront_remove,
+/* 	.resume			= scsifront_resume, */
+	.otherend_changed	= scsifront_backend_changed,
+};
+
+int scsifront_xenbus_init(void)
+{
+	return xenbus_register_frontend(&scsifront_driver);
+}
+
+void scsifront_xenbus_unregister(void)
+{
+	xenbus_unregister_driver(&scsifront_driver);
+}
+
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index 39e5717..ef2b377 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -363,6 +363,8 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
 #define GNTST_permission_denied (-8) /* Not enough privilege for operation.  */
 #define GNTST_bad_page         (-9) /* Specified page was invalid for op.    */
 #define GNTST_bad_copy_arg    (-10) /* copy arguments cross page boundary */
+#define GNTST_address_too_big (-11) /* transfer page address too large.      */
+#define GNTST_eagain          (-12) /* Could not map at the moment. Retry.   */
 
 #define GNTTABOP_error_msgs {                   \
     "okay",                                     \
@@ -376,6 +378,8 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
     "permission denied",                        \
     "bad page",                                 \
     "copy arguments cross page boundary"        \
+    "page address size too large",              \
+    "could not map at the moment, retry"        \
 }
 
 #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
diff --git a/include/xen/interface/io/vscsiif.h b/include/xen/interface/io/vscsiif.h
new file mode 100644
index 0000000..7fbe688
--- /dev/null
+++ b/include/xen/interface/io/vscsiif.h
@@ -0,0 +1,105 @@
+/******************************************************************************
+ * vscsiif.h
+ *
+ * Based on the blkif.h code.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright(c) FUJITSU Limited 2008.
+ */
+
+#ifndef __XEN__PUBLIC_IO_SCSI_H__
+#define __XEN__PUBLIC_IO_SCSI_H__
+
+#include "ring.h"
+#include "../grant_table.h"
+
+/* command between backend and frontend */
+#define VSCSIIF_ACT_SCSI_CDB         1    /* SCSI CDB command */
+#define VSCSIIF_ACT_SCSI_ABORT       2    /* SCSI Device(Lun) Abort*/
+#define VSCSIIF_ACT_SCSI_RESET       3    /* SCSI Device(Lun) Reset*/
+
+
+#define VSCSIIF_BACK_MAX_PENDING_REQS    128
+
+/*
+ * Maximum scatter/gather segments per request.
+ *
+ * Considering balance between allocating al least 16 "vscsiif_request"
+ * structures on one page (4096bytes) and number of scatter gather
+ * needed, we decided to use 26 as a magic number.
+ */
+#define VSCSIIF_SG_TABLESIZE             26
+
+/*
+ * base on linux kernel 2.6.18
+ */
+#define VSCSIIF_MAX_COMMAND_SIZE         16
+#define VSCSIIF_SENSE_BUFFERSIZE         96
+
+
+struct vscsiif_request {
+    uint16_t rqid;          /* private guest value, echoed in resp  */
+    uint8_t act;            /* command between backend and frontend */
+    uint8_t cmd_len;
+
+    uint8_t cmnd[VSCSIIF_MAX_COMMAND_SIZE];
+    uint16_t timeout_per_command;     /* The command is issued by twice
+                                         the value in Backend. */
+    uint16_t channel, id, lun;
+    uint16_t padding;
+    uint8_t sc_data_direction;        /* for DMA_TO_DEVICE(1)
+                                         DMA_FROM_DEVICE(2)
+                                         DMA_NONE(3) requests  */
+    uint8_t nr_segments;              /* Number of pieces of scatter-gather */
+
+    struct scsiif_request_segment {
+        grant_ref_t gref;
+        uint16_t offset;
+        uint16_t length;
+    } seg[VSCSIIF_SG_TABLESIZE];
+    uint32_t reserved[3];
+};
+typedef struct vscsiif_request vscsiif_request_t;
+
+struct vscsiif_response {
+    uint16_t rqid;
+    uint8_t padding;
+    uint8_t sense_len;
+    uint8_t sense_buffer[VSCSIIF_SENSE_BUFFERSIZE];
+    int32_t rslt;
+    uint32_t residual_len;     /* request bufflen -
+                                  return the value from physical device */
+    uint32_t reserved[36];
+};
+typedef struct vscsiif_response vscsiif_response_t;
+
+DEFINE_RING_TYPES(vscsiif, struct vscsiif_request, struct vscsiif_response);
+
+
+#endif  /*__XEN__PUBLIC_IO_SCSI_H__*/
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--3MwIy2ne0vdjdPXF--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:26:30 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:26:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmz4-00059Q-Ln; Wed, 30 Nov 2011 16:26:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVmz3-000595-81
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:26:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1322670313!57168728!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16897 invoked from network); 30 Nov 2011 16:25:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 16:25:14 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUGPD4D017520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 16:25:14 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUGPAaH020925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 16:25:10 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUGP3Jc005526; Wed, 30 Nov 2011 10:25:03 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 08:25:02 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 5882141C2D;
	Wed, 30 Nov 2011 11:24:33 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUGNWfw010876;
	Wed, 30 Nov 2011 11:23:32 -0500
Date: Wed, 30 Nov 2011 11:23:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20111130162332.GA10832@phenom.dumpdata.com>
References: <20110106223121.GT2754@reaktio.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF"
Content-Disposition: inline
In-Reply-To: <20110106223121.GT2754@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4ED658EC.0079,ss=1,re=-6.500,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH v01] Xen PVSCSI drivers for pvops
 xen/stable-2.6.32.x kernel
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 07, 2011 at 12:31:21AM +0200, Pasi K=E4rkk=E4inen wrote:
> Hello,
>=20
> http://pasik.reaktio.net/xen/patches/xen-pvscsi-drivers-linux-2.6.32.27=
-pvops-v01.diff
>=20
> This is the first version of Xen PVSCSI drivers, both the scsiback back=
end and
> scsifront frontend, ported from Novell SLES11SP1 2.6.32 Xenlinux kernel=
 to=20
> pvops xen/stable-2.6.32.x branch.
>=20
> At the moment it's *only* compile-tested with the latest xen/stable-2.6=
.32.x=20
> git kernel as of today (2.6.32.27), on Fedora 14 x86_64.
>=20
> Comments welcome.
>=20
> I'm sure there are still things to fix in it.=20
> Hopefully I managed to properly fix all the differences between Xenlinu=
x <-> pvops..
> Let me know how it goes, if you feel adventurous enough to try it :)

I took a look at the patches and rebased them on top of v3.0 some time ag=
o.

Had to fix up some things, but not much (most of the P2M API calls, and s=
ome of the
grant table modifications) and stuck the patches in:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git devel/xen-sc=
si.v1.0

Attached is also the full patch against v3.0 kernel. I found that it work=
s
with my SCSI disks, but you need to use Xen 4.1 (and xm). Earlier version=
s
do something weird. I am not really sure who is using it=20

Ah, I also put the 2Tb fix in it.

 drivers/scsi/Kconfig                   |   16 +
 drivers/scsi/Makefile                  |    2 +
 drivers/scsi/xen-scsiback/Makefile     |    4 +
 drivers/scsi/xen-scsiback/common.h     |  187 ++++++++
 drivers/scsi/xen-scsiback/emulate.c    |  478 ++++++++++++++++++++
 drivers/scsi/xen-scsiback/interface.c  |  141 ++++++
 drivers/scsi/xen-scsiback/scsiback.c   |  757 ++++++++++++++++++++++++++=
++++++
 drivers/scsi/xen-scsiback/translate.c  |  168 +++++++
 drivers/scsi/xen-scsiback/xenbus.c     |  374 ++++++++++++++++
 drivers/scsi/xen-scsifront/Makefile    |    4 +
 drivers/scsi/xen-scsifront/common.h    |  137 ++++++
 drivers/scsi/xen-scsifront/scsifront.c |  469 ++++++++++++++++++++
 drivers/scsi/xen-scsifront/xenbus.c    |  414 +++++++++++++++++
 include/xen/interface/grant_table.h    |    4 +
 include/xen/interface/io/vscsiif.h     |  105 +++++
 15 files changed, 3260 insertions(+), 0 deletions(-)

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="pv-scsi-against.v3.0.patch"

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 8d9dae8..380e4f05 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1909,6 +1909,22 @@ config SCSI_BFA_FC
 	  To compile this driver as a module, choose M here. The module will
 	  be called bfa.
 
+config XEN_SCSI_FRONTEND
+        tristate "Xen PVSCSI frontend driver"
+        depends on XEN && SCSI
+        default m
+        help
+          The SCSI frontend driver allows the kernel to access SCSI Devices
+          within another guest OS.
+
+config XEN_SCSI_BACKEND
+        tristate "Xen PVSCSI backend driver"
+        depends on XEN_BACKEND && SCSI
+        default m
+        help
+          The PVSCSI backend driver allows the kernel to export its SCSI Devices
+          to other Xen guests via a high-performance shared-memory interface.
+
 endif # SCSI_LOWLEVEL
 
 source "drivers/scsi/pcmcia/Kconfig"
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 3c08f53..7b6f4d2 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -140,6 +140,8 @@ obj-$(CONFIG_SCSI_CXGB4_ISCSI)	+= libiscsi.o libiscsi_tcp.o cxgbi/
 obj-$(CONFIG_SCSI_BNX2_ISCSI)	+= libiscsi.o bnx2i/
 obj-$(CONFIG_BE2ISCSI)		+= libiscsi.o be2iscsi/
 obj-$(CONFIG_SCSI_PMCRAID)	+= pmcraid.o
+obj-$(CONFIG_XEN_SCSI_FRONTEND)	+= xen-scsifront/
+obj-$(CONFIG_XEN_SCSI_BACKEND)	+= xen-scsiback/
 obj-$(CONFIG_VMWARE_PVSCSI)	+= vmw_pvscsi.o
 
 obj-$(CONFIG_ARM)		+= arm/
diff --git a/drivers/scsi/xen-scsiback/Makefile b/drivers/scsi/xen-scsiback/Makefile
new file mode 100644
index 0000000..94926dc
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/Makefile
@@ -0,0 +1,4 @@
+obj-$(CONFIG_XEN_SCSI_BACKEND) := xen-scsiback.o
+
+xen-scsiback-y	:= interface.o scsiback.o xenbus.o translate.o emulate.o
+
diff --git a/drivers/scsi/xen-scsiback/common.h b/drivers/scsi/xen-scsiback/common.h
new file mode 100644
index 0000000..dafa79e
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/common.h
@@ -0,0 +1,187 @@
+/*
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * Based on the blkback driver code.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __SCSIIF__BACKEND__COMMON_H__
+#define __SCSIIF__BACKEND__COMMON_H__
+
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
+#include <linux/wait.h>
+#include <linux/sched.h>
+#include <linux/kthread.h>
+#include <linux/blkdev.h>
+#include <linux/list.h>
+#include <linux/kthread.h>
+#include <scsi/scsi.h>
+#include <scsi/scsi_cmnd.h>
+#include <scsi/scsi_host.h>
+#include <scsi/scsi_device.h>
+#include <scsi/scsi_dbg.h>
+#include <scsi/scsi_eh.h>
+#include <asm/io.h>
+#include <asm/setup.h>
+#include <asm/pgalloc.h>
+#include <asm/delay.h>
+#include <xen/evtchn.h>
+#include <asm/hypervisor.h>
+#include <xen/xen.h>
+#include <xen/events.h>
+#include <xen/grant_table.h>
+#include <xen/xenbus.h>
+#include <xen/page.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/io/ring.h>
+#include <xen/interface/grant_table.h>
+#include <xen/interface/io/vscsiif.h>
+
+
+#define DPRINTK(_f, _a...)			\
+	pr_debug("(file=%s, line=%d) " _f,	\
+		 __FILE__ , __LINE__ , ## _a )
+
+struct ids_tuple {
+	unsigned int hst;		/* host    */
+	unsigned int chn;		/* channel */
+	unsigned int tgt;		/* target  */
+	unsigned int lun;		/* LUN     */
+};
+
+struct v2p_entry {
+	struct ids_tuple v;		/* translate from */
+	struct scsi_device *sdev;	/* translate to   */
+	struct list_head l;
+};
+
+struct vscsibk_info {
+	struct xenbus_device *dev;
+
+	domid_t domid;
+	unsigned int evtchn;
+	unsigned int irq;
+
+	int feature;
+
+	struct vscsiif_back_ring  ring;
+	void  *ring_area;
+
+	spinlock_t ring_lock;
+	atomic_t nr_unreplied_reqs;
+
+	spinlock_t v2p_lock;
+	struct list_head v2p_entry_lists;
+
+	struct task_struct *kthread;
+	wait_queue_head_t waiting_to_free;
+	wait_queue_head_t wq;
+	unsigned int waiting_reqs;
+	struct page **mmap_pages;
+
+};
+
+typedef struct {
+	unsigned char act;
+	struct vscsibk_info *info;
+	struct scsi_device *sdev;
+
+	uint16_t rqid;
+
+	uint16_t v_chn, v_tgt;
+
+	uint8_t nr_segments;
+	uint8_t cmnd[VSCSIIF_MAX_COMMAND_SIZE];
+	uint8_t cmd_len;
+
+	uint8_t sc_data_direction;
+	uint16_t timeout_per_command;
+
+	uint32_t request_bufflen;
+	struct scatterlist *sgl;
+	grant_ref_t gref[VSCSIIF_SG_TABLESIZE];
+
+	int32_t rslt;
+	uint32_t resid;
+	uint8_t sense_buffer[VSCSIIF_SENSE_BUFFERSIZE];
+
+	struct list_head free_list;
+} pending_req_t;
+
+
+
+#define scsiback_get(_b) (atomic_inc(&(_b)->nr_unreplied_reqs))
+#define scsiback_put(_b)				\
+	do {						\
+		if (atomic_dec_and_test(&(_b)->nr_unreplied_reqs))	\
+			wake_up(&(_b)->waiting_to_free);\
+	} while (0)
+
+#define VSCSIIF_TIMEOUT		(900*HZ)
+
+#define VSCSI_TYPE_HOST		1
+
+irqreturn_t scsiback_intr(int, void *);
+int scsiback_init_sring(struct vscsibk_info *info,
+		unsigned long ring_ref, unsigned int evtchn);
+int scsiback_schedule(void *data);
+
+
+struct vscsibk_info *vscsibk_info_alloc(domid_t domid);
+void scsiback_free(struct vscsibk_info *info);
+void scsiback_disconnect(struct vscsibk_info *info);
+int __init scsiback_interface_init(void);
+void scsiback_interface_exit(void);
+int scsiback_xenbus_init(void);
+void scsiback_xenbus_unregister(void);
+
+void scsiback_init_translation_table(struct vscsibk_info *info);
+
+int scsiback_add_translation_entry(struct vscsibk_info *info,
+			struct scsi_device *sdev, struct ids_tuple *v);
+
+int scsiback_del_translation_entry(struct vscsibk_info *info,
+				struct ids_tuple *v);
+struct scsi_device *scsiback_do_translation(struct vscsibk_info *info,
+			struct ids_tuple *v);
+void scsiback_release_translation_entry(struct vscsibk_info *info);
+
+
+void scsiback_cmd_exec(pending_req_t *pending_req);
+void scsiback_do_resp_with_sense(char *sense_buffer, int32_t result,
+			uint32_t resid, pending_req_t *pending_req);
+void scsiback_fast_flush_area(pending_req_t *req);
+
+void scsiback_rsp_emulation(pending_req_t *pending_req);
+void scsiback_req_emulation_or_cmdexec(pending_req_t *pending_req);
+void scsiback_emulation_init(void);
+
+
+#endif /* __SCSIIF__BACKEND__COMMON_H__ */
diff --git a/drivers/scsi/xen-scsiback/emulate.c b/drivers/scsi/xen-scsiback/emulate.c
new file mode 100644
index 0000000..c5b0999
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/emulate.c
@@ -0,0 +1,478 @@
+/*
+ * Xen SCSI backend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/*
+* Patched to support >2TB drives + allow tape & autoloader operations
+* 2010, Samuel Kvasnica, IMS Nanofabrication AG
+*/
+
+#include <scsi/scsi.h>
+#include <scsi/scsi_cmnd.h>
+#include <scsi/scsi_device.h>
+#include "common.h"
+
+/* Following SCSI commands are not defined in scsi/scsi.h */
+#define EXTENDED_COPY		0x83	/* EXTENDED COPY command        */
+#define REPORT_ALIASES		0xa3	/* REPORT ALIASES command       */
+#define CHANGE_ALIASES		0xa4	/* CHANGE ALIASES command       */
+#define SET_PRIORITY		0xa4	/* SET PRIORITY command         */
+
+
+/*
+  The bitmap in order to control emulation.
+  (Bit 3 to 7 are reserved for future use.)
+*/
+#define VSCSIIF_NEED_CMD_EXEC		0x01	/* If this bit is set, cmd exec	*/
+						/* is required.			*/
+#define VSCSIIF_NEED_EMULATE_REQBUF	0x02	/* If this bit is set, need	*/
+						/* emulation reqest buff before	*/
+						/* cmd exec.			*/
+#define VSCSIIF_NEED_EMULATE_RSPBUF	0x04	/* If this bit is set, need	*/
+						/* emulation resp buff after	*/
+						/* cmd exec.			*/
+
+/* Additional Sense Code (ASC) used */
+#define NO_ADDITIONAL_SENSE		0x0
+#define LOGICAL_UNIT_NOT_READY		0x4
+#define UNRECOVERED_READ_ERR		0x11
+#define PARAMETER_LIST_LENGTH_ERR	0x1a
+#define INVALID_OPCODE			0x20
+#define ADDR_OUT_OF_RANGE		0x21
+#define INVALID_FIELD_IN_CDB		0x24
+#define INVALID_FIELD_IN_PARAM_LIST	0x26
+#define POWERON_RESET			0x29
+#define SAVING_PARAMS_UNSUP		0x39
+#define THRESHOLD_EXCEEDED		0x5d
+#define LOW_POWER_COND_ON		0x5e
+
+
+
+/* Number os SCSI op_code	*/
+#define VSCSI_MAX_SCSI_OP_CODE		256
+static unsigned char bitmap[VSCSI_MAX_SCSI_OP_CODE];
+
+#define NO_EMULATE(cmd) \
+	bitmap[cmd] = VSCSIIF_NEED_CMD_EXEC; \
+	pre_function[cmd] = NULL; \
+	post_function[cmd] = NULL
+
+
+
+/*
+  Emulation routines for each SCSI op_code.
+*/
+static void (*pre_function[VSCSI_MAX_SCSI_OP_CODE])(pending_req_t *, void *);
+static void (*post_function[VSCSI_MAX_SCSI_OP_CODE])(pending_req_t *, void *);
+
+
+static const int check_condition_result =
+		(DRIVER_SENSE << 24) | SAM_STAT_CHECK_CONDITION;
+
+static void scsiback_mk_sense_buffer(uint8_t *data, uint8_t key,
+			uint8_t asc, uint8_t asq)
+{
+	data[0] = 0x70;  /* fixed, current */
+	data[2] = key;
+	data[7] = 0xa;	  /* implies 18 byte sense buffer */
+	data[12] = asc;
+	data[13] = asq;
+}
+
+static void resp_not_supported_cmd(pending_req_t *pending_req, void *data)
+{
+	scsiback_mk_sense_buffer(pending_req->sense_buffer, ILLEGAL_REQUEST,
+		INVALID_OPCODE, 0);
+	pending_req->resid = 0;
+	pending_req->rslt  = check_condition_result;
+}
+
+
+static int __copy_to_sg(struct scatterlist *sgl, unsigned int nr_sg,
+	       void *buf, unsigned int buflen)
+{
+	struct scatterlist *sg;
+	void *from = buf;
+	void *to;
+	unsigned int from_rest = buflen;
+	unsigned int to_capa;
+	unsigned int copy_size = 0;
+	unsigned int i;
+	unsigned long pfn;
+
+	for_each_sg (sgl, sg, nr_sg, i) {
+		if (sg_page(sg) == NULL) {
+			printk(KERN_WARNING "%s: inconsistent length field in "
+			       "scatterlist\n", __FUNCTION__);
+			return -ENOMEM;
+		}
+
+		to_capa  = sg->length;
+		copy_size = min_t(unsigned int, to_capa, from_rest);
+
+		pfn = page_to_pfn(sg_page(sg));
+		to = pfn_to_kaddr(pfn) + (sg->offset);
+		memcpy(to, from, copy_size);
+
+		from_rest  -= copy_size;
+		if (from_rest == 0) {
+			return 0;
+		}
+
+		from += copy_size;
+	}
+
+	printk(KERN_WARNING "%s: no space in scatterlist\n",
+	       __FUNCTION__);
+	return -ENOMEM;
+}
+#if 0
+static int __copy_from_sg(struct scatterlist *sgl, unsigned int nr_sg,
+		 void *buf, unsigned int buflen)
+{
+	struct scatterlist *sg;
+	void *from;
+	void *to = buf;
+	unsigned int from_rest;
+	unsigned int to_capa = buflen;
+	unsigned int copy_size;
+	unsigned int i;
+	unsigned long pfn;
+
+	for_each_sg (sgl, sg, nr_sg, i) {
+		if (sg_page(sg) == NULL) {
+			printk(KERN_WARNING "%s: inconsistent length field in "
+			       "scatterlist\n", __FUNCTION__);
+			return -ENOMEM;
+		}
+
+		from_rest = sg->length;
+		if ((from_rest > 0) && (to_capa < from_rest)) {
+			printk(KERN_WARNING
+			       "%s: no space in destination buffer\n",
+			       __FUNCTION__);
+			return -ENOMEM;
+		}
+		copy_size = from_rest;
+
+		pfn = page_to_pfn(sg_page(sg));
+		from = pfn_to_kaddr(pfn) + (sg->offset);
+		memcpy(to, from, copy_size);
+
+		to_capa  -= copy_size;
+		to += copy_size;
+	}
+
+	return 0;
+}
+#endif
+static int __nr_luns_under_host(struct vscsibk_info *info)
+{
+	struct v2p_entry *entry;
+	struct list_head *head = &(info->v2p_entry_lists);
+	unsigned long flags;
+	int lun_cnt = 0;
+
+	spin_lock_irqsave(&info->v2p_lock, flags);
+	list_for_each_entry(entry, head, l) {
+			lun_cnt++;
+	}
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+
+	return (lun_cnt);
+}
+
+
+/* REPORT LUNS Define*/
+#define VSCSI_REPORT_LUNS_HEADER	8
+#define VSCSI_REPORT_LUNS_RETRY		3
+
+/* quoted scsi_debug.c/resp_report_luns() */
+static void __report_luns(pending_req_t *pending_req, void *data)
+{
+	struct vscsibk_info *info   = pending_req->info;
+	unsigned int        channel = pending_req->v_chn;
+	unsigned int        target  = pending_req->v_tgt;
+	unsigned int        nr_seg  = pending_req->nr_segments;
+	unsigned char *cmd = (unsigned char *)pending_req->cmnd;
+
+	unsigned char *buff = NULL;
+	unsigned char alloc_len;
+	unsigned int alloc_luns = 0;
+	unsigned int req_bufflen = 0;
+	unsigned int actual_len = 0;
+	unsigned int retry_cnt = 0;
+	int select_report = (int)cmd[2];
+	int i, lun_cnt = 0, lun, upper, err = 0;
+
+	struct v2p_entry *entry;
+	struct list_head *head = &(info->v2p_entry_lists);
+	unsigned long flags;
+
+	struct scsi_lun *one_lun;
+
+	req_bufflen = cmd[9] + (cmd[8] << 8) + (cmd[7] << 16) + (cmd[6] << 24);
+	if ((req_bufflen < 4) || (select_report != 0))
+		goto fail;
+
+	alloc_luns = __nr_luns_under_host(info);
+	alloc_len  = sizeof(struct scsi_lun) * alloc_luns
+				+ VSCSI_REPORT_LUNS_HEADER;
+retry:
+	if ((buff = kzalloc(alloc_len, GFP_KERNEL)) == NULL) {
+		printk(KERN_ERR "scsiback:%s kmalloc err\n", __FUNCTION__);
+		goto fail;
+	}
+
+	one_lun = (struct scsi_lun *) &buff[8];
+	spin_lock_irqsave(&info->v2p_lock, flags);
+	list_for_each_entry(entry, head, l) {
+		if ((entry->v.chn == channel) &&
+		    (entry->v.tgt == target)) {
+			/* check overflow */
+			if (lun_cnt >= alloc_luns) {
+				spin_unlock_irqrestore(&info->v2p_lock,
+							flags);
+
+				if (retry_cnt < VSCSI_REPORT_LUNS_RETRY) {
+					retry_cnt++;
+					if (buff)
+						kfree(buff);
+					goto retry;
+				}
+
+				goto fail;
+			}
+
+			lun = entry->v.lun;
+			upper = (lun >> 8) & 0x3f;
+			if (upper)
+				one_lun[lun_cnt].scsi_lun[0] = upper;
+			one_lun[lun_cnt].scsi_lun[1] = lun & 0xff;
+			lun_cnt++;
+		}
+	}
+
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+
+	buff[2] = ((sizeof(struct scsi_lun) * lun_cnt) >> 8) & 0xff;
+	buff[3] = (sizeof(struct scsi_lun) * lun_cnt) & 0xff;
+
+	actual_len = lun_cnt * sizeof(struct scsi_lun)
+				+ VSCSI_REPORT_LUNS_HEADER;
+	req_bufflen = 0;
+	for (i = 0; i < nr_seg; i++)
+		req_bufflen += pending_req->sgl[i].length;
+
+	err = __copy_to_sg(pending_req->sgl, nr_seg, buff,
+				min(req_bufflen, actual_len));
+	if (err)
+		goto fail;
+
+	memset(pending_req->sense_buffer, 0, VSCSIIF_SENSE_BUFFERSIZE);
+	pending_req->rslt = 0x00;
+	pending_req->resid = req_bufflen - min(req_bufflen, actual_len);
+
+	kfree(buff);
+	return;
+
+fail:
+	scsiback_mk_sense_buffer(pending_req->sense_buffer, ILLEGAL_REQUEST,
+		INVALID_FIELD_IN_CDB, 0);
+	pending_req->rslt  = check_condition_result;
+	pending_req->resid = 0;
+	if (buff)
+		kfree(buff);
+	return;
+}
+
+
+
+int __pre_do_emulation(pending_req_t *pending_req, void *data)
+{
+	uint8_t op_code = pending_req->cmnd[0];
+
+	if ((bitmap[op_code] & VSCSIIF_NEED_EMULATE_REQBUF) &&
+	    pre_function[op_code] != NULL) {
+		pre_function[op_code](pending_req, data);
+	}
+
+	/*
+	    0: no need for native driver call, so should return immediately.
+	    1: non emulation or should call native driver
+	       after modifing the request buffer.
+	*/
+	return !!(bitmap[op_code] & VSCSIIF_NEED_CMD_EXEC);
+}
+
+void scsiback_rsp_emulation(pending_req_t *pending_req)
+{
+	uint8_t op_code = pending_req->cmnd[0];
+
+	if ((bitmap[op_code] & VSCSIIF_NEED_EMULATE_RSPBUF) &&
+	    post_function[op_code] != NULL) {
+		post_function[op_code](pending_req, NULL);
+	}
+
+	return;
+}
+
+
+void scsiback_req_emulation_or_cmdexec(pending_req_t *pending_req)
+{
+	if (__pre_do_emulation(pending_req, NULL)) {
+		scsiback_cmd_exec(pending_req);
+	}
+	else {
+		scsiback_fast_flush_area(pending_req);
+		scsiback_do_resp_with_sense(pending_req->sense_buffer,
+		  pending_req->rslt, pending_req->resid, pending_req);
+	}
+}
+
+
+/*
+  Following are not customizable functions.
+*/
+void scsiback_emulation_init(void)
+{
+	int i;
+
+	/* Initialize to default state */
+	for (i = 0; i < VSCSI_MAX_SCSI_OP_CODE; i++) {
+		bitmap[i]        = (VSCSIIF_NEED_EMULATE_REQBUF |
+					VSCSIIF_NEED_EMULATE_RSPBUF);
+		pre_function[i]  = resp_not_supported_cmd;
+		post_function[i] = NULL;
+		/* means,
+		   - no need for pre-emulation
+		   - no need for post-emulation
+		   - call native driver
+		*/
+	}
+
+	/*
+	  Register appropriate functions below as you need.
+	  (See scsi/scsi.h for definition of SCSI op_code.)
+	*/
+
+	/*
+	  Following commands do not require emulation.
+	*/
+	NO_EMULATE(TEST_UNIT_READY);       /*0x00*/ /* sd,st */
+	NO_EMULATE(REZERO_UNIT);           /*0x01*/ /* st */
+	NO_EMULATE(REQUEST_SENSE);         /*0x03*/
+	NO_EMULATE(FORMAT_UNIT);           /*0x04*/
+	NO_EMULATE(READ_BLOCK_LIMITS);     /*0x05*/ /* st */
+	/*NO_EMULATE(REASSIGN_BLOCKS);       *//*0x07*/
+	NO_EMULATE(INITIALIZE_ELEMENT_STATUS); /*0x07*/ /* ch */
+	NO_EMULATE(READ_6);                /*0x08*/ /* sd,st */
+	NO_EMULATE(WRITE_6);               /*0x0a*/ /* sd,st */
+	NO_EMULATE(SEEK_6);                /*0x0b*/
+	/*NO_EMULATE(READ_REVERSE);          *//*0x0f*/
+	NO_EMULATE(WRITE_FILEMARKS);       /*0x10*/ /* st */
+	NO_EMULATE(SPACE);                 /*0x11*/ /* st */
+	NO_EMULATE(INQUIRY);               /*0x12*/
+	/*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
+	NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
+	/*NO_EMULATE(RESERVE);               *//*0x16*/
+	/*NO_EMULATE(RELEASE);               *//*0x17*/
+	/*NO_EMULATE(COPY);                  *//*0x18*/
+	NO_EMULATE(ERASE);                 /*0x19*/ /* st */
+	NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
+	NO_EMULATE(START_STOP);            /*0x1b*/ /* sd,st */
+	NO_EMULATE(RECEIVE_DIAGNOSTIC);    /*0x1c*/
+	NO_EMULATE(SEND_DIAGNOSTIC);       /*0x1d*/
+	NO_EMULATE(ALLOW_MEDIUM_REMOVAL);  /*0x1e*/
+
+	/*NO_EMULATE(SET_WINDOW);            *//*0x24*/
+	NO_EMULATE(READ_CAPACITY);         /*0x25*/ /* sd */
+	NO_EMULATE(READ_10);               /*0x28*/ /* sd */
+	NO_EMULATE(WRITE_10);              /*0x2a*/ /* sd */
+	NO_EMULATE(SEEK_10);               /*0x2b*/ /* st */
+	NO_EMULATE(POSITION_TO_ELEMENT);   /*0x2b*/ /* ch */
+	/*NO_EMULATE(WRITE_VERIFY);          *//*0x2e*/
+	/*NO_EMULATE(VERIFY);                *//*0x2f*/
+	/*NO_EMULATE(SEARCH_HIGH);           *//*0x30*/
+	/*NO_EMULATE(SEARCH_EQUAL);          *//*0x31*/
+	/*NO_EMULATE(SEARCH_LOW);            *//*0x32*/
+	NO_EMULATE(SET_LIMITS);            /*0x33*/
+	NO_EMULATE(PRE_FETCH);             /*0x34*/ /* st! */
+	NO_EMULATE(READ_POSITION);          /*0x34*/ /* st */
+	NO_EMULATE(SYNCHRONIZE_CACHE);      /*0x35*/ /* sd */
+	NO_EMULATE(LOCK_UNLOCK_CACHE);     /*0x36*/
+	NO_EMULATE(READ_DEFECT_DATA);      /*0x37*/
+	NO_EMULATE(MEDIUM_SCAN);           /*0x38*/
+	/*NO_EMULATE(COMPARE);               *//*0x39*/
+	/*NO_EMULATE(COPY_VERIFY);           *//*0x3a*/
+	NO_EMULATE(WRITE_BUFFER);          /*0x3b*/
+	NO_EMULATE(READ_BUFFER);           /*0x3c*/ /* osst */
+	/*NO_EMULATE(UPDATE_BLOCK);          *//*0x3d*/
+	/*NO_EMULATE(READ_LONG);             *//*0x3e*/
+	/*NO_EMULATE(WRITE_LONG);            *//*0x3f*/
+	/*NO_EMULATE(CHANGE_DEFINITION);     *//*0x40*/
+	/*NO_EMULATE(WRITE_SAME);            *//*0x41*/
+	NO_EMULATE(READ_TOC);              /*0x43*/ /* sr */
+	NO_EMULATE(LOG_SELECT);            /*0x4c*/
+	NO_EMULATE(LOG_SENSE);             /*0x4d*/ /* st! */
+	/*NO_EMULATE(MODE_SELECT_10);        *//*0x55*/
+	/*NO_EMULATE(RESERVE_10);            *//*0x56*/
+	/*NO_EMULATE(RELEASE_10);            *//*0x57*/
+	NO_EMULATE(MODE_SENSE_10);         /*0x5a*/ /* scsi_lib */
+	/*NO_EMULATE(PERSISTENT_RESERVE_IN); *//*0x5e*/
+	/*NO_EMULATE(PERSISTENT_RESERVE_OUT); *//*0x5f*/
+	/*           REPORT_LUNS             *//*0xa0*//*Full emulaiton*/
+	NO_EMULATE(MAINTENANCE_IN);           /*0xa3*/ /* IFT alua */
+	NO_EMULATE(MAINTENANCE_OUT);       /*0xa4*/ /* IFT alua */
+	NO_EMULATE(MOVE_MEDIUM);           /*0xa5*/ /* ch */
+	NO_EMULATE(EXCHANGE_MEDIUM);       /*0xa6*/ /* ch */
+	/*NO_EMULATE(READ_12);               *//*0xa8*/
+	/*NO_EMULATE(WRITE_12);              *//*0xaa*/
+	/*NO_EMULATE(WRITE_VERIFY_12);       *//*0xae*/
+	/*NO_EMULATE(SEARCH_HIGH_12);        *//*0xb0*/
+	/*NO_EMULATE(SEARCH_EQUAL_12);       *//*0xb1*/
+	/*NO_EMULATE(SEARCH_LOW_12);         *//*0xb2*/
+	NO_EMULATE(READ_ELEMENT_STATUS);   /*0xb8*/ /* ch */
+	NO_EMULATE(SEND_VOLUME_TAG);       /*0xb6*/ /* ch */
+	/*NO_EMULATE(WRITE_LONG_2);          *//*0xea*/
+	NO_EMULATE(READ_16);               /*0x88*/ /* sd >2TB */
+	NO_EMULATE(WRITE_16);              /*0x8a*/ /* sd >2TB */
+	NO_EMULATE(VERIFY_16);	           /*0x8f*/
+	NO_EMULATE(SERVICE_ACTION_IN);     /*0x9e*/ /* sd >2TB */
+
+/* st: QFA_REQUEST_BLOCK, QFA_SEEK_BLOCK might be needed ? */
+	/*
+	  Following commands require emulation.
+	*/
+	pre_function[REPORT_LUNS] = __report_luns;
+	bitmap[REPORT_LUNS] = (VSCSIIF_NEED_EMULATE_REQBUF |
+					VSCSIIF_NEED_EMULATE_RSPBUF);
+
+	return;
+}
diff --git a/drivers/scsi/xen-scsiback/interface.c b/drivers/scsi/xen-scsiback/interface.c
new file mode 100644
index 0000000..663568e
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/interface.c
@@ -0,0 +1,141 @@
+/*
+ * interface management.
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * Based on the blkback driver code.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <scsi/scsi.h>
+#include <scsi/scsi_host.h>
+#include <scsi/scsi_device.h>
+#include "common.h"
+
+#include <xen/evtchn.h>
+#include <linux/kthread.h>
+#include <linux/delay.h>
+
+
+static struct kmem_cache *scsiback_cachep;
+
+struct vscsibk_info *vscsibk_info_alloc(domid_t domid)
+{
+	struct vscsibk_info *info;
+
+	info = kmem_cache_zalloc(scsiback_cachep, GFP_KERNEL);
+	if (!info)
+		return ERR_PTR(-ENOMEM);
+
+	info->domid = domid;
+	spin_lock_init(&info->ring_lock);
+	atomic_set(&info->nr_unreplied_reqs, 0);
+	init_waitqueue_head(&info->wq);
+	init_waitqueue_head(&info->waiting_to_free);
+
+	return info;
+}
+
+int scsiback_init_sring(struct vscsibk_info *info,
+		unsigned long ring_ref, unsigned int evtchn)
+{
+	struct vscsiif_sring *sring;
+	int err;
+
+	if (!info)
+		return -ENODEV;
+
+	if (info->irq) {
+		printk(KERN_ERR "scsiback: Already connected through?\n");
+		return -1;
+	}
+
+	err = xenbus_map_ring_valloc(info->dev, ring_ref, &info->ring_area);
+	if (err < 0)
+		return -ENOMEM;
+
+	sring = (struct vscsiif_sring *) info->ring_area;
+	BACK_RING_INIT(&info->ring, sring, PAGE_SIZE);
+
+	err = bind_interdomain_evtchn_to_irqhandler(
+			info->domid, evtchn,
+			scsiback_intr, 0, "vscsiif-backend", info);
+	if (err < 0)
+		goto unmap_page;
+
+	info->irq = err;
+
+	return 0;
+
+unmap_page:
+	xenbus_unmap_ring_vfree(info->dev, info->ring_area);
+
+	return err;
+}
+
+void scsiback_disconnect(struct vscsibk_info *info)
+{
+	if (info->kthread) {
+		kthread_stop(info->kthread);
+		info->kthread = NULL;
+	}
+
+	wait_event(info->waiting_to_free,
+		atomic_read(&info->nr_unreplied_reqs) == 0);
+
+	if (info->irq) {
+		unbind_from_irqhandler(info->irq, info);
+		info->irq = 0;
+	}
+
+	if (info->ring.sring || info->ring_area) {
+		xenbus_unmap_ring_vfree(info->dev, info->ring_area);
+		info->ring.sring = NULL;
+		info->ring_area = NULL;
+	}
+}
+
+void scsiback_free(struct vscsibk_info *info)
+{
+	kmem_cache_free(scsiback_cachep, info);
+}
+
+int __init scsiback_interface_init(void)
+{
+	scsiback_cachep = kmem_cache_create("vscsiif_cache",
+		sizeof(struct vscsibk_info), 0, 0, NULL);
+	if (!scsiback_cachep) {
+		printk(KERN_ERR "scsiback: can't init scsi cache\n");
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+void scsiback_interface_exit(void)
+{
+	kmem_cache_destroy(scsiback_cachep);
+}
diff --git a/drivers/scsi/xen-scsiback/scsiback.c b/drivers/scsi/xen-scsiback/scsiback.c
new file mode 100644
index 0000000..a209f87
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/scsiback.c
@@ -0,0 +1,757 @@
+/*
+ * Xen SCSI backend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * Based on the blkback driver code.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/spinlock.h>
+#include <linux/kthread.h>
+#include <linux/list.h>
+#include <linux/delay.h>
+#include <xen/balloon.h>
+#include <asm/hypervisor.h>
+#include <scsi/scsi.h>
+#include <scsi/scsi_cmnd.h>
+#include <scsi/scsi_host.h>
+#include <scsi/scsi_device.h>
+#include <scsi/scsi_dbg.h>
+#include <scsi/scsi_eh.h>
+
+#include "common.h"
+
+
+struct list_head pending_free;
+DEFINE_SPINLOCK(pending_free_lock);
+DECLARE_WAIT_QUEUE_HEAD(pending_free_wq);
+
+int vscsiif_reqs = VSCSIIF_BACK_MAX_PENDING_REQS;
+module_param_named(reqs, vscsiif_reqs, int, 0);
+MODULE_PARM_DESC(reqs, "Number of scsiback requests to allocate");
+
+static unsigned int log_print_stat;
+module_param(log_print_stat, int, 0644);
+
+#define SCSIBACK_INVALID_HANDLE (~0)
+
+static pending_req_t *pending_reqs;
+static struct page **pending_pages;
+static grant_handle_t *pending_grant_handles;
+
+static int vaddr_pagenr(pending_req_t *req, int seg)
+{
+	return (req - pending_reqs) * VSCSIIF_SG_TABLESIZE + seg;
+}
+
+static unsigned long vaddr(pending_req_t *req, int seg)
+{
+	unsigned long pfn = page_to_pfn(pending_pages[vaddr_pagenr(req, seg)]);
+	return (unsigned long)pfn_to_kaddr(pfn);
+}
+
+#define pending_handle(_req, _seg) \
+	(pending_grant_handles[vaddr_pagenr(_req, _seg)])
+
+
+void scsiback_fast_flush_area(pending_req_t *req)
+{
+	struct gnttab_unmap_grant_ref unmap[VSCSIIF_SG_TABLESIZE];
+	unsigned int i, invcount = 0;
+	grant_handle_t handle;
+	int err;
+
+	if (req->nr_segments) {
+		for (i = 0; i < req->nr_segments; i++) {
+			handle = pending_handle(req, i);
+			if (handle == SCSIBACK_INVALID_HANDLE)
+				continue;
+			gnttab_set_unmap_op(&unmap[i], vaddr(req, i),
+						GNTMAP_host_map, handle);
+			pending_handle(req, i) = SCSIBACK_INVALID_HANDLE;
+			invcount++;
+		}
+
+		err = HYPERVISOR_grant_table_op(
+			GNTTABOP_unmap_grant_ref, unmap, invcount);
+		BUG_ON(err);
+		for (i = 0; i <invcount; i++) {
+			err = m2p_remove_override(
+				virt_to_page(unmap[i].host_addr), false);
+			WARN_ON(err);
+		}
+		kfree(req->sgl);
+	}
+
+	return;
+}
+
+
+static pending_req_t * alloc_req(struct vscsibk_info *info)
+{
+	pending_req_t *req = NULL;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pending_free_lock, flags);
+	if (!list_empty(&pending_free)) {
+		req = list_entry(pending_free.next, pending_req_t, free_list);
+		list_del(&req->free_list);
+	}
+	spin_unlock_irqrestore(&pending_free_lock, flags);
+	return req;
+}
+
+
+static void free_req(pending_req_t *req)
+{
+	unsigned long flags;
+	int was_empty;
+
+	spin_lock_irqsave(&pending_free_lock, flags);
+	was_empty = list_empty(&pending_free);
+	list_add(&req->free_list, &pending_free);
+	spin_unlock_irqrestore(&pending_free_lock, flags);
+	if (was_empty)
+		wake_up(&pending_free_wq);
+}
+
+
+static void scsiback_notify_work(struct vscsibk_info *info)
+{
+	info->waiting_reqs = 1;
+	wake_up(&info->wq);
+}
+
+void scsiback_do_resp_with_sense(char *sense_buffer, int32_t result,
+			uint32_t resid, pending_req_t *pending_req)
+{
+	vscsiif_response_t *ring_res;
+	struct vscsibk_info *info = pending_req->info;
+	int notify;
+	int more_to_do = 1;
+	struct scsi_sense_hdr sshdr;
+	unsigned long flags;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	spin_lock_irqsave(&info->ring_lock, flags);
+
+	ring_res = RING_GET_RESPONSE(&info->ring, info->ring.rsp_prod_pvt);
+	info->ring.rsp_prod_pvt++;
+
+	ring_res->rslt   = result;
+	ring_res->rqid   = pending_req->rqid;
+
+	if (sense_buffer != NULL) {
+		if (scsi_normalize_sense(sense_buffer,
+			sizeof(sense_buffer), &sshdr)) {
+
+			int len = 8 + sense_buffer[7];
+
+			if (len > VSCSIIF_SENSE_BUFFERSIZE)
+				len = VSCSIIF_SENSE_BUFFERSIZE;
+
+			memcpy(ring_res->sense_buffer, sense_buffer, len);
+			ring_res->sense_len = len;
+		}
+	} else {
+		ring_res->sense_len = 0;
+	}
+
+	ring_res->residual_len = resid;
+
+	RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&info->ring, notify);
+	if (info->ring.rsp_prod_pvt == info->ring.req_cons) {
+		RING_FINAL_CHECK_FOR_REQUESTS(&info->ring, more_to_do);
+	} else if (RING_HAS_UNCONSUMED_REQUESTS(&info->ring)) {
+		more_to_do = 1;
+	}
+
+	spin_unlock_irqrestore(&info->ring_lock, flags);
+
+	if (more_to_do)
+		scsiback_notify_work(info);
+
+	if (notify)
+		notify_remote_via_irq(info->irq);
+
+	free_req(pending_req);
+}
+
+static void scsiback_print_status(char *sense_buffer, int errors,
+					pending_req_t *pending_req)
+{
+	struct scsi_device *sdev = pending_req->sdev;
+
+	printk(KERN_ERR "scsiback: %d:%d:%d:%d ",sdev->host->host_no,
+			sdev->channel, sdev->id, sdev->lun);
+	printk(KERN_ERR "status = 0x%02x, message = 0x%02x, host = 0x%02x, driver = 0x%02x\n",
+			status_byte(errors), msg_byte(errors),
+			host_byte(errors), driver_byte(errors));
+
+	printk(KERN_ERR "scsiback: cmnd[0]=0x%02X\n",
+			pending_req->cmnd[0]);
+
+	if (CHECK_CONDITION & status_byte(errors))
+		__scsi_print_sense("scsiback", sense_buffer, SCSI_SENSE_BUFFERSIZE);
+}
+
+
+static void scsiback_cmd_done(struct request *req, int uptodate)
+{
+	pending_req_t *pending_req = req->end_io_data;
+	unsigned char *sense_buffer;
+	unsigned int resid;
+	int errors;
+
+	sense_buffer = req->sense;
+	resid        = blk_rq_bytes(req);
+	errors       = req->errors;
+
+	if (errors != 0) {
+		if (log_print_stat)
+			scsiback_print_status(sense_buffer, errors, pending_req);
+	}
+
+	/* The Host mode is through as for Emulation. */
+	if (pending_req->info->feature != VSCSI_TYPE_HOST)
+		scsiback_rsp_emulation(pending_req);
+
+	scsiback_fast_flush_area(pending_req);
+	scsiback_do_resp_with_sense(sense_buffer, errors, resid, pending_req);
+	scsiback_put(pending_req->info);
+
+	__blk_put_request(req->q, req);
+}
+
+
+static int scsiback_gnttab_data_map(vscsiif_request_t *ring_req,
+					pending_req_t *pending_req)
+{
+	u32 flags;
+	int write;
+	int i, err = 0;
+	unsigned int data_len = 0;
+	struct gnttab_map_grant_ref map[VSCSIIF_SG_TABLESIZE];
+	struct vscsibk_info *info   = pending_req->info;
+
+	int data_dir = pending_req->sc_data_direction;
+	unsigned int nr_segments = (unsigned int)pending_req->nr_segments;
+
+	write = (data_dir == DMA_TO_DEVICE);
+
+	if (nr_segments) {
+		struct scatterlist *sg;
+
+		/* free of (sgl) in fast_flush_area()*/
+		pending_req->sgl = kmalloc(sizeof(struct scatterlist) * nr_segments,
+						GFP_KERNEL);
+		if (!pending_req->sgl) {
+			printk(KERN_ERR "scsiback: %s: kmalloc() error.\n", __FUNCTION__);
+			return -ENOMEM;
+		}
+
+		sg_init_table(pending_req->sgl, nr_segments);
+
+		for (i = 0; i < nr_segments; i++) {
+			flags = GNTMAP_host_map;
+			if (write)
+				flags |= GNTMAP_readonly;
+
+			gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
+						ring_req->seg[i].gref,
+						info->domid);
+		}
+
+		err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, nr_segments);
+		BUG_ON(err);
+
+		/* Retry maps with GNTST_eagain */
+		for(i=0; i < nr_segments; i++) {
+		    while(unlikely(map[i].status == GNTST_eagain))
+		    {
+				msleep(10);
+				err = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
+							&map[i],
+							1);
+				BUG_ON(err);
+		    }
+		}
+
+		for_each_sg (pending_req->sgl, sg, nr_segments, i) {
+			struct page *pg;
+
+			if (unlikely(map[i].status != 0)) {
+				printk(KERN_ERR "scsiback: invalid buffer -- could not remap it: " \
+					"%d/%d, err:%d\n", i, nr_segments, map[i].status);
+				map[i].handle = SCSIBACK_INVALID_HANDLE;
+				err |= 1;
+			}
+
+			pending_handle(pending_req, i) = map[i].handle;
+
+			if (err)
+				continue;
+
+			pg = pending_pages[vaddr_pagenr(pending_req, i)];
+
+			m2p_add_override(PFN_DOWN(map[i].dev_bus_addr), pg, false);
+			sg_set_page(sg, pg, ring_req->seg[i].length,
+				    ring_req->seg[i].offset);
+			data_len += sg->length;
+
+			barrier();
+			if (sg->offset >= PAGE_SIZE ||
+			    sg->length > PAGE_SIZE ||
+			    sg->offset + sg->length > PAGE_SIZE)
+				err |= 1;
+
+		}
+
+		if (err)
+			goto fail_flush;
+	}
+
+	pending_req->request_bufflen = data_len;
+
+	return 0;
+
+fail_flush:
+	scsiback_fast_flush_area(pending_req);
+	return -ENOMEM;
+}
+
+/* quoted scsi_lib.c/scsi_bi_endio */
+static void scsiback_bi_endio(struct bio *bio, int error)
+{
+	bio_put(bio);
+}
+
+
+
+/* quoted scsi_lib.c/scsi_req_map_sg . */
+static struct bio *request_map_sg(pending_req_t *pending_req)
+{
+	struct request_queue *q = pending_req->sdev->request_queue;
+	unsigned int nsegs = (unsigned int)pending_req->nr_segments;
+	unsigned int i, len, bytes, off, nr_pages, nr_vecs = 0;
+	struct scatterlist *sg;
+	struct page *page;
+	struct bio *bio = NULL, *bio_first = NULL, *bio_last = NULL;
+	int err;
+
+	for_each_sg (pending_req->sgl, sg, nsegs, i) {
+		page = sg_page(sg);
+		off = sg->offset;
+		len = sg->length;
+
+		nr_pages = (len + off + PAGE_SIZE - 1) >> PAGE_SHIFT;
+		while (len > 0) {
+			bytes = min_t(unsigned int, len, PAGE_SIZE - off);
+
+			if (!bio) {
+				nr_vecs = min_t(unsigned int, BIO_MAX_PAGES,
+					 	nr_pages);
+				nr_pages -= nr_vecs;
+				bio = bio_alloc(GFP_KERNEL, nr_vecs);
+				if (!bio) {
+					err = -ENOMEM;
+					goto free_bios;
+				}
+				bio->bi_end_io = scsiback_bi_endio;
+				if (bio_last)
+					bio_last->bi_next = bio;
+				else
+					bio_first = bio;
+				bio_last = bio;
+			}
+
+			if (bio_add_pc_page(q, bio, page, bytes, off) !=
+						bytes) {
+				bio_put(bio);
+				err = -EINVAL;
+				goto free_bios;
+			}
+
+			if (bio->bi_vcnt >= nr_vecs) {
+				bio->bi_flags &= ~(1 << BIO_SEG_VALID);
+				if (pending_req->sc_data_direction == WRITE)
+					bio->bi_rw |= REQ_WRITE;
+				bio = NULL;
+			}
+
+			page++;
+			len -= bytes;
+			off = 0;
+		}
+	}
+
+	return bio_first;
+
+free_bios:
+	while ((bio = bio_first) != NULL) {
+		bio_first = bio->bi_next;
+		bio_put(bio);
+	}
+
+	return ERR_PTR(err);
+}
+
+
+void scsiback_cmd_exec(pending_req_t *pending_req)
+{
+	int cmd_len  = (int)pending_req->cmd_len;
+	int data_dir = (int)pending_req->sc_data_direction;
+	unsigned int timeout;
+	struct request *rq;
+	int write;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	/* because it doesn't timeout backend earlier than frontend.*/
+	if (pending_req->timeout_per_command)
+		timeout = pending_req->timeout_per_command * HZ;
+	else
+		timeout = VSCSIIF_TIMEOUT;
+
+	write = (data_dir == DMA_TO_DEVICE);
+	if (pending_req->nr_segments) {
+		struct bio *bio = request_map_sg(pending_req);
+
+		if (IS_ERR(bio)) {
+			printk(KERN_ERR "scsiback: SG Request Map Error\n");
+			return;
+		}
+
+		rq = blk_make_request(pending_req->sdev->request_queue, bio,
+				      GFP_KERNEL);
+		if (IS_ERR(rq)) {
+			printk(KERN_ERR "scsiback: Make Request Error\n");
+			return;
+		}
+
+		rq->buffer = NULL;
+	} else {
+		rq = blk_get_request(pending_req->sdev->request_queue, write,
+				     GFP_KERNEL);
+		if (unlikely(!rq)) {
+			printk(KERN_ERR "scsiback: Get Request Error\n");
+			return;
+		}
+	}
+
+	rq->cmd_type = REQ_TYPE_BLOCK_PC;
+	rq->cmd_len = cmd_len;
+	memcpy(rq->cmd, pending_req->cmnd, cmd_len);
+
+	memset(pending_req->sense_buffer, 0, VSCSIIF_SENSE_BUFFERSIZE);
+	rq->sense       = pending_req->sense_buffer;
+	rq->sense_len = 0;
+
+	/* not allowed to retry in backend.                   */
+	rq->retries   = 0;
+	rq->timeout   = timeout;
+	rq->end_io_data = pending_req;
+
+	scsiback_get(pending_req->info);
+	blk_execute_rq_nowait(rq->q, NULL, rq, 1, scsiback_cmd_done);
+
+	return ;
+}
+
+
+static void scsiback_device_reset_exec(pending_req_t *pending_req)
+{
+	struct vscsibk_info *info = pending_req->info;
+	int err;
+	struct scsi_device *sdev = pending_req->sdev;
+
+	scsiback_get(info);
+	err = scsi_reset_provider(sdev, SCSI_TRY_RESET_DEVICE);
+
+	scsiback_do_resp_with_sense(NULL, err, 0, pending_req);
+	scsiback_put(info);
+
+	return;
+}
+
+
+irqreturn_t scsiback_intr(int irq, void *dev_id)
+{
+	scsiback_notify_work((struct vscsibk_info *)dev_id);
+	return IRQ_HANDLED;
+}
+
+static int prepare_pending_reqs(struct vscsibk_info *info,
+		vscsiif_request_t *ring_req, pending_req_t *pending_req)
+{
+	struct scsi_device *sdev;
+	struct ids_tuple vir;
+	int err = -EINVAL;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	pending_req->rqid       = ring_req->rqid;
+	pending_req->act        = ring_req->act;
+
+	pending_req->info       = info;
+
+	pending_req->v_chn = vir.chn = ring_req->channel;
+	pending_req->v_tgt = vir.tgt = ring_req->id;
+	vir.lun = ring_req->lun;
+
+	rmb();
+	sdev = scsiback_do_translation(info, &vir);
+	if (!sdev) {
+		pending_req->sdev = NULL;
+		DPRINTK("scsiback: doesn't exist.\n");
+		err = -ENODEV;
+		goto invalid_value;
+	}
+	pending_req->sdev = sdev;
+
+	/* request range check from frontend */
+	pending_req->sc_data_direction = ring_req->sc_data_direction;
+	barrier();
+	if ((pending_req->sc_data_direction != DMA_BIDIRECTIONAL) &&
+		(pending_req->sc_data_direction != DMA_TO_DEVICE) &&
+		(pending_req->sc_data_direction != DMA_FROM_DEVICE) &&
+		(pending_req->sc_data_direction != DMA_NONE)) {
+		DPRINTK("scsiback: invalid parameter data_dir = %d\n",
+			pending_req->sc_data_direction);
+		err = -EINVAL;
+		goto invalid_value;
+	}
+
+	pending_req->nr_segments = ring_req->nr_segments;
+	barrier();
+	if (pending_req->nr_segments > VSCSIIF_SG_TABLESIZE) {
+		DPRINTK("scsiback: invalid parameter nr_seg = %d\n",
+			pending_req->nr_segments);
+		err = -EINVAL;
+		goto invalid_value;
+	}
+
+	pending_req->cmd_len = ring_req->cmd_len;
+	barrier();
+	if (pending_req->cmd_len > VSCSIIF_MAX_COMMAND_SIZE) {
+		DPRINTK("scsiback: invalid parameter cmd_len = %d\n",
+			pending_req->cmd_len);
+		err = -EINVAL;
+		goto invalid_value;
+	}
+	memcpy(pending_req->cmnd, ring_req->cmnd, pending_req->cmd_len);
+
+	pending_req->timeout_per_command = ring_req->timeout_per_command;
+
+	if(scsiback_gnttab_data_map(ring_req, pending_req)) {
+		DPRINTK("scsiback: invalid buffer\n");
+		err = -EINVAL;
+		goto invalid_value;
+	}
+
+	return 0;
+
+invalid_value:
+	return err;
+}
+
+
+static int scsiback_do_cmd_fn(struct vscsibk_info *info)
+{
+	struct vscsiif_back_ring *ring = &info->ring;
+	vscsiif_request_t  *ring_req;
+
+	pending_req_t *pending_req;
+	RING_IDX rc, rp;
+	int err, more_to_do = 0;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	rc = ring->req_cons;
+	rp = ring->sring->req_prod;
+	rmb();
+
+	while ((rc != rp)) {
+		if (RING_REQUEST_CONS_OVERFLOW(ring, rc))
+			break;
+		pending_req = alloc_req(info);
+		if (NULL == pending_req) {
+			more_to_do = 1;
+			break;
+		}
+
+		ring_req = RING_GET_REQUEST(ring, rc);
+		ring->req_cons = ++rc;
+
+		err = prepare_pending_reqs(info, ring_req,
+						pending_req);
+		if (err == -EINVAL) {
+			scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << 24),
+				0, pending_req);
+			continue;
+		} else if (err == -ENODEV) {
+			scsiback_do_resp_with_sense(NULL, (DID_NO_CONNECT << 16),
+				0, pending_req);
+			continue;
+		}
+
+		if (pending_req->act == VSCSIIF_ACT_SCSI_CDB) {
+
+			/* The Host mode is through as for Emulation. */
+			if (info->feature == VSCSI_TYPE_HOST)
+				scsiback_cmd_exec(pending_req);
+			else
+				scsiback_req_emulation_or_cmdexec(pending_req);
+
+		} else if (pending_req->act == VSCSIIF_ACT_SCSI_RESET) {
+			scsiback_device_reset_exec(pending_req);
+		} else {
+			printk(KERN_ERR "scsiback: invalid parameter for request\n");
+			scsiback_do_resp_with_sense(NULL, (DRIVER_ERROR << 24),
+				0, pending_req);
+			continue;
+		}
+	}
+
+	if (RING_HAS_UNCONSUMED_REQUESTS(ring))
+		more_to_do = 1;
+
+	/* Yield point for this unbounded loop. */
+	cond_resched();
+
+	return more_to_do;
+}
+
+
+int scsiback_schedule(void *data)
+{
+	struct vscsibk_info *info = (struct vscsibk_info *)data;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(
+			info->wq,
+			info->waiting_reqs || kthread_should_stop());
+		wait_event_interruptible(
+			pending_free_wq,
+			!list_empty(&pending_free) || kthread_should_stop());
+
+		info->waiting_reqs = 0;
+		smp_mb();
+
+		if (scsiback_do_cmd_fn(info))
+			info->waiting_reqs = 1;
+	}
+
+	return 0;
+}
+
+
+static int __init scsiback_init(void)
+{
+	int i, mmap_pages;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	mmap_pages = vscsiif_reqs * VSCSIIF_SG_TABLESIZE;
+
+	pending_reqs          = kzalloc(sizeof(pending_reqs[0]) *
+					vscsiif_reqs, GFP_KERNEL);
+	pending_grant_handles = kmalloc(sizeof(pending_grant_handles[0]) *
+					mmap_pages, GFP_KERNEL);
+	pending_pages         = kzalloc(sizeof(pending_pages[0]) *
+					mmap_pages, GFP_KERNEL);
+
+	if (!pending_reqs || !pending_grant_handles || !pending_pages)
+		goto out_of_memory;
+
+	for (i = 0; i < mmap_pages; i++) {
+		pending_grant_handles[i] = SCSIBACK_INVALID_HANDLE;
+		pending_pages[i] = alloc_page(GFP_KERNEL);
+		if (pending_pages[i] == NULL)
+			goto out_of_memory;
+	}
+	if (scsiback_interface_init() < 0)
+		goto out_of_kmem;
+
+	memset(pending_reqs, 0, sizeof(pending_reqs));
+	INIT_LIST_HEAD(&pending_free);
+
+	for (i = 0; i < vscsiif_reqs; i++)
+		list_add_tail(&pending_reqs[i].free_list, &pending_free);
+
+	if (scsiback_xenbus_init())
+		goto out_of_xenbus;
+
+	scsiback_emulation_init();
+
+	return 0;
+
+out_of_xenbus:
+	scsiback_xenbus_unregister();
+out_of_kmem:
+	scsiback_interface_exit();
+out_of_memory:
+	if (pending_pages) {
+		for (i = 0; i < mmap_pages; i++) {
+			if (pending_pages[i])
+				__free_page(pending_pages[i]);
+		}
+		kfree(pending_pages);
+	}
+	kfree(pending_reqs);
+	kfree(pending_grant_handles);
+	printk(KERN_ERR "scsiback: %s: out of memory\n", __FUNCTION__);
+	return -ENOMEM;
+}
+
+
+static void __exit scsiback_exit(void)
+{
+	scsiback_xenbus_unregister();
+	scsiback_interface_exit();
+	kfree(pending_reqs);
+	kfree(pending_grant_handles);
+	if (pending_pages) {
+		unsigned int i;
+		unsigned int mmap_pages = vscsiif_reqs * VSCSIIF_SG_TABLESIZE;
+		for (i = 0; i < mmap_pages; i++) {
+			if (pending_pages[i])
+				__free_page(pending_pages[i]);
+		}
+		kfree(pending_pages);
+	}
+}
+
+module_init(scsiback_init);
+module_exit(scsiback_exit);
+
+MODULE_DESCRIPTION("Xen SCSI backend driver");
+MODULE_LICENSE("Dual BSD/GPL");
diff --git a/drivers/scsi/xen-scsiback/translate.c b/drivers/scsi/xen-scsiback/translate.c
new file mode 100644
index 0000000..36873cc
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/translate.c
@@ -0,0 +1,168 @@
+/*
+ * Xen SCSI backend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/list.h>
+#include <linux/gfp.h>
+
+#include "common.h"
+
+/*
+  Initialize the translation entry list
+*/
+void scsiback_init_translation_table(struct vscsibk_info *info)
+{
+	INIT_LIST_HEAD(&info->v2p_entry_lists);
+	spin_lock_init(&info->v2p_lock);
+}
+
+
+/*
+  Add a new translation entry
+*/
+int scsiback_add_translation_entry(struct vscsibk_info *info,
+			struct scsi_device *sdev, struct ids_tuple *v)
+{
+	int err = 0;
+	struct v2p_entry *entry;
+	struct v2p_entry *new;
+	struct list_head *head = &(info->v2p_entry_lists);
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->v2p_lock, flags);
+
+	/* Check double assignment to identical virtual ID */
+	list_for_each_entry(entry, head, l) {
+		if ((entry->v.chn == v->chn) &&
+		    (entry->v.tgt == v->tgt) &&
+		    (entry->v.lun == v->lun)) {
+			printk(KERN_WARNING "scsiback: Virtual ID is already used. "
+			       "Assignment was not performed.\n");
+			err = -EEXIST;
+			goto out;
+		}
+
+	}
+
+	/* Create a new translation entry and add to the list */
+	if ((new = kmalloc(sizeof(struct v2p_entry), GFP_ATOMIC)) == NULL) {
+		printk(KERN_ERR "scsiback: %s: kmalloc() error.\n", __FUNCTION__);
+		err = -ENOMEM;
+		goto out;
+	}
+	new->v = *v;
+	new->sdev = sdev;
+	list_add_tail(&new->l, head);
+
+out:
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+	return err;
+}
+
+
+/*
+  Delete the translation entry specfied
+*/
+int scsiback_del_translation_entry(struct vscsibk_info *info,
+				struct ids_tuple *v)
+{
+	struct v2p_entry *entry;
+	struct list_head *head = &(info->v2p_entry_lists);
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->v2p_lock, flags);
+	/* Find out the translation entry specified */
+	list_for_each_entry(entry, head, l) {
+		if ((entry->v.chn == v->chn) &&
+		    (entry->v.tgt == v->tgt) &&
+		    (entry->v.lun == v->lun)) {
+			goto found;
+		}
+	}
+
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+	return 1;
+
+found:
+	/* Delete the translation entry specfied */
+	scsi_device_put(entry->sdev);
+	list_del(&entry->l);
+	kfree(entry);
+
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+	return 0;
+}
+
+
+/*
+  Perform virtual to physical translation
+*/
+struct scsi_device *scsiback_do_translation(struct vscsibk_info *info,
+			struct ids_tuple *v)
+{
+	struct v2p_entry *entry;
+	struct list_head *head = &(info->v2p_entry_lists);
+	struct scsi_device *sdev = NULL;
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->v2p_lock, flags);
+	list_for_each_entry(entry, head, l) {
+		if ((entry->v.chn == v->chn) &&
+		    (entry->v.tgt == v->tgt) &&
+		    (entry->v.lun == v->lun)) {
+			sdev = entry->sdev;
+			goto out;
+		}
+	}
+out:
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+	return sdev;
+}
+
+
+/*
+  Release the translation entry specfied
+*/
+void scsiback_release_translation_entry(struct vscsibk_info *info)
+{
+	struct v2p_entry *entry, *tmp;
+	struct list_head *head = &(info->v2p_entry_lists);
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->v2p_lock, flags);
+	list_for_each_entry_safe(entry, tmp, head, l) {
+		scsi_device_put(entry->sdev);
+		list_del(&entry->l);
+		kfree(entry);
+	}
+
+	spin_unlock_irqrestore(&info->v2p_lock, flags);
+	return;
+
+}
diff --git a/drivers/scsi/xen-scsiback/xenbus.c b/drivers/scsi/xen-scsiback/xenbus.c
new file mode 100644
index 0000000..0816c0e
--- /dev/null
+++ b/drivers/scsi/xen-scsiback/xenbus.c
@@ -0,0 +1,374 @@
+/*
+ * Xen SCSI backend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * Based on the blkback driver code.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <stdarg.h>
+#include <linux/module.h>
+#include <linux/kthread.h>
+#include <scsi/scsi.h>
+#include <scsi/scsi_host.h>
+#include <scsi/scsi_device.h>
+
+#include "common.h"
+
+struct backend_info
+{
+	struct xenbus_device *dev;
+	struct vscsibk_info *info;
+};
+
+
+static int __vscsiif_name(struct backend_info *be, char *buf)
+{
+	struct xenbus_device *dev = be->dev;
+	unsigned int domid, id;
+
+	sscanf(dev->nodename, "backend/vscsi/%u/%u", &domid, &id);
+	snprintf(buf, TASK_COMM_LEN, "vscsi.%u.%u", be->info->domid, id);
+
+	return 0;
+}
+
+static int scsiback_map(struct backend_info *be)
+{
+	struct xenbus_device *dev = be->dev;
+	unsigned long ring_ref = 0;
+	unsigned int evtchn = 0;
+	int err;
+	char name[TASK_COMM_LEN];
+
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+			"ring-ref", "%lu", &ring_ref,
+			"event-channel", "%u", &evtchn, NULL);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "reading %s ring", dev->otherend);
+		return err;
+	}
+	err = scsiback_init_sring(be->info, ring_ref, evtchn);
+	if (err)
+		return err;
+
+	err = __vscsiif_name(be, name);
+	if (err) {
+		xenbus_dev_error(dev, err, "get scsiback dev name");
+		return err;
+	}
+
+	be->info->kthread = kthread_run(scsiback_schedule, be->info, name);
+	if (IS_ERR(be->info->kthread)) {
+		err = PTR_ERR(be->info->kthread);
+		be->info->kthread = NULL;
+		xenbus_dev_error(be->dev, err, "start vscsiif");
+		return err;
+	}
+
+	return 0;
+}
+
+
+struct scsi_device *scsiback_get_scsi_device(struct ids_tuple *phy)
+{
+	struct Scsi_Host *shost;
+	struct scsi_device *sdev = NULL;
+
+	shost = scsi_host_lookup(phy->hst);
+	if (IS_ERR(shost)) {
+		printk(KERN_ERR "scsiback: host%d doesn't exist.\n",
+			phy->hst);
+		return NULL;
+	}
+	sdev   = scsi_device_lookup(shost, phy->chn, phy->tgt, phy->lun);
+	if (!sdev) {
+		printk(KERN_ERR "scsiback: %d:%d:%d:%d doesn't exist.\n",
+			phy->hst, phy->chn, phy->tgt, phy->lun);
+		scsi_host_put(shost);
+		return NULL;
+	}
+
+	scsi_host_put(shost);
+	return (sdev);
+}
+
+#define VSCSIBACK_OP_ADD_OR_DEL_LUN	1
+#define VSCSIBACK_OP_UPDATEDEV_STATE	2
+
+
+static void scsiback_do_lun_hotplug(struct backend_info *be, int op)
+{
+	int i, err = 0;
+	struct ids_tuple phy, vir;
+	int device_state;
+	char str[64], state_str[64];
+	char **dir;
+	unsigned int dir_n = 0;
+	struct xenbus_device *dev = be->dev;
+	struct scsi_device *sdev;
+
+	dir = xenbus_directory(XBT_NIL, dev->nodename, "vscsi-devs", &dir_n);
+	if (IS_ERR(dir))
+		return;
+
+	for (i = 0; i < dir_n; i++) {
+		/* read status */
+		snprintf(state_str, sizeof(state_str), "vscsi-devs/%s/state", dir[i]);
+		err = xenbus_scanf(XBT_NIL, dev->nodename, state_str, "%u",
+			&device_state);
+		if (XENBUS_EXIST_ERR(err))
+			continue;
+
+		/* physical SCSI device */
+		snprintf(str, sizeof(str), "vscsi-devs/%s/p-dev", dir[i]);
+		err = xenbus_scanf(XBT_NIL, dev->nodename, str,
+			"%u:%u:%u:%u", &phy.hst, &phy.chn, &phy.tgt, &phy.lun);
+		if (XENBUS_EXIST_ERR(err)) {
+			xenbus_printf(XBT_NIL, dev->nodename, state_str,
+					"%d", XenbusStateClosed);
+			continue;
+		}
+
+		/* virtual SCSI device */
+		snprintf(str, sizeof(str), "vscsi-devs/%s/v-dev", dir[i]);
+		err = xenbus_scanf(XBT_NIL, dev->nodename, str,
+			"%u:%u:%u:%u", &vir.hst, &vir.chn, &vir.tgt, &vir.lun);
+		if (XENBUS_EXIST_ERR(err)) {
+			xenbus_printf(XBT_NIL, dev->nodename, state_str,
+					"%d", XenbusStateClosed);
+			continue;
+		}
+
+		switch (op) {
+		case VSCSIBACK_OP_ADD_OR_DEL_LUN:
+			if (device_state == XenbusStateInitialising) {
+				sdev = scsiback_get_scsi_device(&phy);
+				if (!sdev)
+					xenbus_printf(XBT_NIL, dev->nodename, state_str,
+							    "%d", XenbusStateClosed);
+				else {
+					err = scsiback_add_translation_entry(be->info, sdev, &vir);
+					if (!err) {
+						if (xenbus_printf(XBT_NIL, dev->nodename, state_str,
+								    "%d", XenbusStateInitialised)) {
+							printk(KERN_ERR "scsiback: xenbus_printf error %s\n", state_str);
+							scsiback_del_translation_entry(be->info, &vir);
+						}
+					} else {
+						scsi_device_put(sdev);
+						xenbus_printf(XBT_NIL, dev->nodename, state_str,
+								    "%d", XenbusStateClosed);
+					}
+				}
+			}
+
+			if (device_state == XenbusStateClosing) {
+				if (!scsiback_del_translation_entry(be->info, &vir)) {
+					if (xenbus_printf(XBT_NIL, dev->nodename, state_str,
+							    "%d", XenbusStateClosed))
+						printk(KERN_ERR "scsiback: xenbus_printf error %s\n", state_str);
+				}
+			}
+			break;
+
+		case VSCSIBACK_OP_UPDATEDEV_STATE:
+			if (device_state == XenbusStateInitialised) {
+				/* modify vscsi-devs/dev-x/state */
+				if (xenbus_printf(XBT_NIL, dev->nodename, state_str,
+						    "%d", XenbusStateConnected)) {
+					printk(KERN_ERR "scsiback: xenbus_printf error %s\n", state_str);
+					scsiback_del_translation_entry(be->info, &vir);
+					xenbus_printf(XBT_NIL, dev->nodename, state_str,
+							    "%d", XenbusStateClosed);
+				}
+			}
+			break;
+		/*When it is necessary, processing is added here.*/
+		default:
+			break;
+		}
+	}
+
+	kfree(dir);
+	return ;
+}
+
+
+static void scsiback_frontend_changed(struct xenbus_device *dev,
+					enum xenbus_state frontend_state)
+{
+	struct backend_info *be = dev_get_drvdata(&dev->dev);
+	int err;
+
+	switch (frontend_state) {
+	case XenbusStateInitialising:
+		break;
+	case XenbusStateInitialised:
+		err = scsiback_map(be);
+		if (err)
+			break;
+
+		scsiback_do_lun_hotplug(be, VSCSIBACK_OP_ADD_OR_DEL_LUN);
+		xenbus_switch_state(dev, XenbusStateConnected);
+
+		break;
+	case XenbusStateConnected:
+
+		scsiback_do_lun_hotplug(be, VSCSIBACK_OP_UPDATEDEV_STATE);
+
+		if (dev->state == XenbusStateConnected)
+			break;
+
+		xenbus_switch_state(dev, XenbusStateConnected);
+
+		break;
+
+	case XenbusStateClosing:
+		scsiback_disconnect(be->info);
+		xenbus_switch_state(dev, XenbusStateClosing);
+		break;
+
+	case XenbusStateClosed:
+		xenbus_switch_state(dev, XenbusStateClosed);
+		if (xenbus_dev_is_online(dev))
+			break;
+		/* fall through if not online */
+	case XenbusStateUnknown:
+		device_unregister(&dev->dev);
+		break;
+
+	case XenbusStateReconfiguring:
+		scsiback_do_lun_hotplug(be, VSCSIBACK_OP_ADD_OR_DEL_LUN);
+
+		xenbus_switch_state(dev, XenbusStateReconfigured);
+
+		break;
+
+	default:
+		xenbus_dev_fatal(dev, -EINVAL, "saw state %d at frontend",
+					frontend_state);
+		break;
+	}
+}
+
+
+static int scsiback_remove(struct xenbus_device *dev)
+{
+	struct backend_info *be = dev_get_drvdata(&dev->dev);
+
+	if (be->info) {
+		scsiback_disconnect(be->info);
+		scsiback_release_translation_entry(be->info);
+		scsiback_free(be->info);
+		be->info = NULL;
+	}
+
+	kfree(be);
+	dev_set_drvdata(&dev->dev, NULL);
+
+	return 0;
+}
+
+
+static int scsiback_probe(struct xenbus_device *dev,
+			   const struct xenbus_device_id *id)
+{
+	int err;
+	unsigned val = 0;
+
+	struct backend_info *be = kzalloc(sizeof(struct backend_info),
+					  GFP_KERNEL);
+
+	if (!be) {
+		xenbus_dev_fatal(dev, -ENOMEM,
+				 "allocating backend structure");
+		return -ENOMEM;
+	}
+	be->dev = dev;
+	dev_set_drvdata(&dev->dev, be);
+
+	be->info = vscsibk_info_alloc(dev->otherend_id);
+	if (IS_ERR(be->info)) {
+		err = PTR_ERR(be->info);
+		be->info = NULL;
+		xenbus_dev_fatal(dev, err, "creating scsihost interface");
+		goto fail;
+	}
+
+	be->info->dev = dev;
+	be->info->irq = 0;
+	be->info->feature = 0;	/*default not HOSTMODE.*/
+
+	scsiback_init_translation_table(be->info);
+
+	err = xenbus_scanf(XBT_NIL, dev->nodename,
+				"feature-host", "%d", &val);
+	if (XENBUS_EXIST_ERR(err))
+		val = 0;
+
+	if (val)
+		be->info->feature = VSCSI_TYPE_HOST;
+
+	err = xenbus_switch_state(dev, XenbusStateInitWait);
+	if (err)
+		goto fail;
+
+	return 0;
+
+
+fail:
+	printk(KERN_WARNING "scsiback: %s failed\n",__func__);
+	scsiback_remove(dev);
+
+	return err;
+}
+
+
+static struct xenbus_device_id scsiback_ids[] = {
+	{ "vscsi" },
+	{ "" }
+};
+
+static struct xenbus_driver scsiback = {
+	.name			= "vscsi",
+	.owner			= THIS_MODULE,
+	.ids			= scsiback_ids,
+	.probe			= scsiback_probe,
+	.remove			= scsiback_remove,
+	.otherend_changed	= scsiback_frontend_changed
+};
+
+int scsiback_xenbus_init(void)
+{
+	return xenbus_register_backend(&scsiback);
+}
+
+void scsiback_xenbus_unregister(void)
+{
+	xenbus_unregister_driver(&scsiback);
+}
diff --git a/drivers/scsi/xen-scsifront/Makefile b/drivers/scsi/xen-scsifront/Makefile
new file mode 100644
index 0000000..18a5329
--- /dev/null
+++ b/drivers/scsi/xen-scsifront/Makefile
@@ -0,0 +1,4 @@
+
+obj-$(CONFIG_XEN_SCSI_FRONTEND)	:= xen-scsifront.o
+xen-scsifront-objs := scsifront.o xenbus.o
+
diff --git a/drivers/scsi/xen-scsifront/common.h b/drivers/scsi/xen-scsifront/common.h
new file mode 100644
index 0000000..cfa1c32
--- /dev/null
+++ b/drivers/scsi/xen-scsifront/common.h
@@ -0,0 +1,137 @@
+/*
+ * Xen SCSI frontend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_DRIVERS_SCSIFRONT_H__
+#define __XEN_DRIVERS_SCSIFRONT_H__
+
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/kthread.h>
+#include <linux/wait.h>
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/sched.h>
+#include <linux/blkdev.h>
+#include <scsi/scsi_cmnd.h>
+#include <scsi/scsi_device.h>
+#include <scsi/scsi.h>
+#include <scsi/scsi_host.h>
+#include <asm/xen/page.h>
+#include <xen/xenbus.h>
+#include <xen/grant_table.h>
+#include <xen/events.h>
+#include <xen/evtchn.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/io/ring.h>
+#include <xen/interface/io/vscsiif.h>
+#include <xen/interface/grant_table.h>
+#include <xen/interface/io/protocols.h>
+#include <asm/delay.h>
+#include <asm/hypervisor.h>
+/*#include <asm/maddr.h>*/
+
+#ifdef HAVE_XEN_PLATFORM_COMPAT_H
+#include <xen/platform-compat.h>
+#endif
+
+#define GRANT_INVALID_REF	0
+#define VSCSI_IN_ABORT		1
+#define VSCSI_IN_RESET		2
+
+/* tuning point*/
+#define VSCSIIF_DEFAULT_CMD_PER_LUN 10
+#define VSCSIIF_MAX_TARGET          64
+#define VSCSIIF_MAX_LUN             255
+
+#define VSCSIIF_RING_SIZE	__CONST_RING_SIZE(vscsiif, PAGE_SIZE)
+#define VSCSIIF_MAX_REQS	VSCSIIF_RING_SIZE
+
+struct vscsifrnt_shadow {
+	uint16_t next_free;
+
+	/* command between backend and frontend
+	 * VSCSIIF_ACT_SCSI_CDB or VSCSIIF_ACT_SCSI_RESET */
+	unsigned char act;
+
+	/* do reset function */
+	wait_queue_head_t wq_reset;	/* reset work queue           */
+	int wait_reset;			/* reset work queue condition */
+	int32_t rslt_reset;		/* reset response status      */
+					/* (SUCESS or FAILED)         */
+
+	/* for DMA_TO_DEVICE(1), DMA_FROM_DEVICE(2), DMA_NONE(3)
+	   requests */
+	unsigned int sc_data_direction;
+
+	/* Number of pieces of scatter-gather */
+	unsigned int nr_segments;
+
+	/* requested struct scsi_cmnd is stored from kernel */
+	unsigned long req_scsi_cmnd;
+	int gref[VSCSIIF_SG_TABLESIZE];
+};
+
+struct vscsifrnt_info {
+	struct xenbus_device *dev;
+
+	struct Scsi_Host *host;
+
+	spinlock_t io_lock;
+	spinlock_t shadow_lock;
+	unsigned int evtchn;
+	unsigned int irq;
+
+	grant_ref_t ring_ref;
+	struct vscsiif_front_ring ring;
+	struct vscsiif_response	ring_res;
+
+	struct vscsifrnt_shadow shadow[VSCSIIF_MAX_REQS];
+	uint32_t shadow_free;
+
+	struct task_struct *kthread;
+	wait_queue_head_t wq;
+	unsigned int waiting_resp;
+
+};
+
+#define DPRINTK(_f, _a...)				\
+	pr_debug("(file=%s, line=%d) " _f,	\
+		 __FILE__ , __LINE__ , ## _a )
+
+int scsifront_xenbus_init(void);
+void scsifront_xenbus_unregister(void);
+int scsifront_schedule(void *data);
+irqreturn_t scsifront_intr(int irq, void *dev_id);
+int scsifront_cmd_done(struct vscsifrnt_info *info);
+
+
+#endif /* __XEN_DRIVERS_SCSIFRONT_H__  */
diff --git a/drivers/scsi/xen-scsifront/scsifront.c b/drivers/scsi/xen-scsifront/scsifront.c
new file mode 100644
index 0000000..2d5e25f
--- /dev/null
+++ b/drivers/scsi/xen-scsifront/scsifront.c
@@ -0,0 +1,469 @@
+/*
+ * Xen SCSI frontend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/version.h>
+#include "common.h"
+
+static int get_id_from_freelist(struct vscsifrnt_info *info)
+{
+	unsigned long flags;
+	uint32_t free;
+
+	spin_lock_irqsave(&info->shadow_lock, flags);
+
+	free = info->shadow_free;
+	BUG_ON(free > VSCSIIF_MAX_REQS);
+	info->shadow_free = info->shadow[free].next_free;
+	info->shadow[free].next_free = 0x0fff;
+
+	info->shadow[free].wait_reset = 0;
+
+	spin_unlock_irqrestore(&info->shadow_lock, flags);
+
+	return free;
+}
+
+static void add_id_to_freelist(struct vscsifrnt_info *info, uint32_t id)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->shadow_lock, flags);
+
+	info->shadow[id].next_free  = info->shadow_free;
+	info->shadow[id].req_scsi_cmnd = 0;
+	info->shadow_free = id;
+
+	spin_unlock_irqrestore(&info->shadow_lock, flags);
+}
+
+
+struct vscsiif_request * scsifront_pre_request(struct vscsifrnt_info *info)
+{
+	struct vscsiif_front_ring *ring = &(info->ring);
+	vscsiif_request_t *ring_req;
+	uint32_t id;
+
+	ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
+
+	ring->req_prod_pvt++;
+
+	id = get_id_from_freelist(info);	/* use id by response */
+	ring_req->rqid = (uint16_t)id;
+
+	return ring_req;
+}
+
+
+static void scsifront_notify_work(struct vscsifrnt_info *info)
+{
+	info->waiting_resp = 1;
+	wake_up(&info->wq);
+}
+
+
+static void scsifront_do_request(struct vscsifrnt_info *info)
+{
+	struct vscsiif_front_ring *ring = &(info->ring);
+	unsigned int irq = info->irq;
+	int notify;
+
+	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(ring, notify);
+	if (notify)
+		notify_remote_via_irq(irq);
+}
+
+irqreturn_t scsifront_intr(int irq, void *dev_id)
+{
+	scsifront_notify_work((struct vscsifrnt_info *)dev_id);
+	return IRQ_HANDLED;
+}
+
+
+static void scsifront_gnttab_done(struct vscsifrnt_shadow *s, uint32_t id)
+{
+	int i;
+
+	if (s->sc_data_direction == DMA_NONE)
+		return;
+
+	if (s->nr_segments) {
+		for (i = 0; i < s->nr_segments; i++) {
+			if (unlikely(gnttab_query_foreign_access(
+				s->gref[i]) != 0)) {
+				printk(KERN_ALERT "scsifront: "
+					"grant still in use by backend.\n");
+				BUG();
+			}
+			gnttab_end_foreign_access(s->gref[i], 0, 0UL);
+		}
+	}
+
+	return;
+}
+
+
+static void scsifront_cdb_cmd_done(struct vscsifrnt_info *info,
+		       vscsiif_response_t *ring_res)
+{
+	struct scsi_cmnd *sc;
+	uint32_t id;
+	uint8_t sense_len;
+
+	id = ring_res->rqid;
+	sc = (struct scsi_cmnd *)info->shadow[id].req_scsi_cmnd;
+
+	if (sc == NULL)
+		BUG();
+
+	scsifront_gnttab_done(&info->shadow[id], id);
+	add_id_to_freelist(info, id);
+
+	sc->result = ring_res->rslt;
+	scsi_set_resid(sc, ring_res->residual_len);
+
+	if (ring_res->sense_len > VSCSIIF_SENSE_BUFFERSIZE)
+		sense_len = VSCSIIF_SENSE_BUFFERSIZE;
+	else
+		sense_len = ring_res->sense_len;
+
+	if (sense_len)
+		memcpy(sc->sense_buffer, ring_res->sense_buffer, sense_len);
+
+	sc->scsi_done(sc);
+
+	return;
+}
+
+
+static void scsifront_sync_cmd_done(struct vscsifrnt_info *info,
+				vscsiif_response_t *ring_res)
+{
+	uint16_t id = ring_res->rqid;
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->shadow_lock, flags);
+	info->shadow[id].wait_reset = 1;
+	info->shadow[id].rslt_reset = ring_res->rslt;
+	spin_unlock_irqrestore(&info->shadow_lock, flags);
+
+	wake_up(&(info->shadow[id].wq_reset));
+}
+
+
+int scsifront_cmd_done(struct vscsifrnt_info *info)
+{
+	vscsiif_response_t *ring_res;
+
+	RING_IDX i, rp;
+	int more_to_do = 0;
+	unsigned long flags;
+
+	spin_lock_irqsave(&info->io_lock, flags);
+
+	rp = info->ring.sring->rsp_prod;
+	rmb();
+	for (i = info->ring.rsp_cons; i != rp; i++) {
+
+		ring_res = RING_GET_RESPONSE(&info->ring, i);
+
+		if (info->shadow[ring_res->rqid].act == VSCSIIF_ACT_SCSI_CDB)
+			scsifront_cdb_cmd_done(info, ring_res);
+		else
+			scsifront_sync_cmd_done(info, ring_res);
+	}
+
+	info->ring.rsp_cons = i;
+
+	if (i != info->ring.req_prod_pvt) {
+		RING_FINAL_CHECK_FOR_RESPONSES(&info->ring, more_to_do);
+	} else {
+		info->ring.sring->rsp_event = i + 1;
+	}
+
+	spin_unlock_irqrestore(&info->io_lock, flags);
+
+
+	/* Yield point for this unbounded loop. */
+	cond_resched();
+
+	return more_to_do;
+}
+
+
+
+
+int scsifront_schedule(void *data)
+{
+	struct vscsifrnt_info *info = (struct vscsifrnt_info *)data;
+
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(
+			info->wq,
+			info->waiting_resp || kthread_should_stop());
+
+		info->waiting_resp = 0;
+		smp_mb();
+
+		if (scsifront_cmd_done(info))
+			info->waiting_resp = 1;
+	}
+
+	return 0;
+}
+
+
+
+static int map_data_for_request(struct vscsifrnt_info *info,
+		struct scsi_cmnd *sc, vscsiif_request_t *ring_req, uint32_t id)
+{
+	grant_ref_t gref_head;
+	int err, ref, ref_cnt = 0;
+	int write = (sc->sc_data_direction == DMA_TO_DEVICE);
+	unsigned int i, nr_pages, off, len, bytes;
+	unsigned long buffer_mfn, buffer_pfn;
+
+	if (sc->sc_data_direction == DMA_NONE)
+		return 0;
+
+	err = gnttab_alloc_grant_references(VSCSIIF_SG_TABLESIZE, &gref_head);
+	if (err) {
+		printk(KERN_ERR "scsifront: gnttab_alloc_grant_references() error\n");
+		return -ENOMEM;
+	}
+
+	if (scsi_bufflen(sc)) {
+		/* quoted scsi_lib.c/scsi_req_map_sg . */
+		struct scatterlist *sg, *sgl = scsi_sglist(sc);
+		unsigned int data_len = scsi_bufflen(sc);
+
+		nr_pages = (data_len + sgl->offset + PAGE_SIZE - 1) >> PAGE_SHIFT;
+		if (nr_pages > VSCSIIF_SG_TABLESIZE) {
+			printk(KERN_ERR "scsifront: Unable to map request_buffer for command!\n");
+			ref_cnt = (-E2BIG);
+			goto big_to_sg;
+		}
+
+		for_each_sg (sgl, sg, scsi_sg_count(sc), i) {
+			off = sg->offset;
+			len = sg->length;
+
+			buffer_pfn = page_to_pfn(sg_page(sg));
+			while (len > 0 && data_len > 0) {
+				/*
+				 * sg sends a scatterlist that is larger than
+				 * the data_len it wants transferred for certain
+				 * IO sizes
+				 */
+				bytes = min_t(unsigned int, len, PAGE_SIZE - off);
+				bytes = min(bytes, data_len);
+
+				ref = gnttab_claim_grant_reference(&gref_head);
+				BUG_ON(ref == -ENOSPC);
+
+				buffer_mfn = pfn_to_mfn(buffer_pfn);
+				gnttab_grant_foreign_access_ref(ref, info->dev->otherend_id,
+					buffer_mfn, write);
+
+				info->shadow[id].gref[ref_cnt]  = ref;
+				ring_req->seg[ref_cnt].gref     = ref;
+				ring_req->seg[ref_cnt].offset   = (uint16_t)off;
+				ring_req->seg[ref_cnt].length   = (uint16_t)bytes;
+
+				buffer_pfn ++;
+				len -= bytes;
+				data_len -= bytes;
+				off = 0;
+				ref_cnt++;
+			}
+		}
+	}
+
+big_to_sg:
+
+	gnttab_free_grant_references(gref_head);
+
+	return ref_cnt;
+}
+
+static int scsifront_queuecommand(struct Scsi_Host *h, struct scsi_cmnd *sc)
+{
+	struct vscsifrnt_info *info =
+		(struct vscsifrnt_info *) sc->device->host->hostdata;
+	vscsiif_request_t *ring_req;
+	int ref_cnt;
+	uint16_t rqid;
+
+	if (RING_FULL(&info->ring)) {
+		goto out_host_busy;
+	}
+
+	sc->result    = 0;
+
+	ring_req          = scsifront_pre_request(info);
+	rqid              = ring_req->rqid;
+	ring_req->act     = VSCSIIF_ACT_SCSI_CDB;
+
+	ring_req->id      = sc->device->id;
+	ring_req->lun     = sc->device->lun;
+	ring_req->channel = sc->device->channel;
+	ring_req->cmd_len = sc->cmd_len;
+
+	BUG_ON(sc->cmd_len > VSCSIIF_MAX_COMMAND_SIZE);
+
+	if (sc->cmd_len)
+		memcpy(ring_req->cmnd, sc->cmnd, sc->cmd_len);
+	else
+		memset(ring_req->cmnd, 0, VSCSIIF_MAX_COMMAND_SIZE);
+
+	ring_req->sc_data_direction   = (uint8_t)sc->sc_data_direction;
+	ring_req->timeout_per_command = (sc->request->timeout / HZ);
+
+	info->shadow[rqid].req_scsi_cmnd     = (unsigned long)sc;
+	info->shadow[rqid].sc_data_direction = sc->sc_data_direction;
+	info->shadow[rqid].act               = ring_req->act;
+
+	ref_cnt = map_data_for_request(info, sc, ring_req, rqid);
+	if (ref_cnt < 0) {
+		add_id_to_freelist(info, rqid);
+		if (ref_cnt == (-ENOMEM))
+			goto out_host_busy;
+		else {
+			sc->result = (DID_ERROR << 16);
+			goto out_fail_command;
+		}
+	}
+
+	ring_req->nr_segments          = (uint8_t)ref_cnt;
+	info->shadow[rqid].nr_segments = ref_cnt;
+
+	scsifront_do_request(info);
+
+	return 0;
+
+out_host_busy:
+	return SCSI_MLQUEUE_HOST_BUSY;
+
+out_fail_command:
+	sc->scsi_done(sc);
+	return 0;
+}
+
+
+static int scsifront_eh_abort_handler(struct scsi_cmnd *sc)
+{
+	return (FAILED);
+}
+
+/* vscsi supports only device_reset, because it is each of LUNs */
+static int scsifront_dev_reset_handler(struct scsi_cmnd *sc)
+{
+	struct Scsi_Host *host = sc->device->host;
+	struct vscsifrnt_info *info =
+		(struct vscsifrnt_info *) sc->device->host->hostdata;
+
+	vscsiif_request_t *ring_req;
+	uint16_t rqid;
+	int err;
+
+	spin_lock_irq(host->host_lock);
+
+	ring_req      = scsifront_pre_request(info);
+	ring_req->act = VSCSIIF_ACT_SCSI_RESET;
+
+	rqid          = ring_req->rqid;
+	info->shadow[rqid].act = VSCSIIF_ACT_SCSI_RESET;
+
+	ring_req->channel = sc->device->channel;
+	ring_req->id      = sc->device->id;
+	ring_req->lun     = sc->device->lun;
+	ring_req->cmd_len = sc->cmd_len;
+
+	if ( sc->cmd_len )
+		memcpy(ring_req->cmnd, sc->cmnd, sc->cmd_len);
+	else
+		memset(ring_req->cmnd, 0, VSCSIIF_MAX_COMMAND_SIZE);
+
+	ring_req->sc_data_direction   = (uint8_t)sc->sc_data_direction;
+	ring_req->timeout_per_command = (sc->request->timeout / HZ);
+	ring_req->nr_segments         = 0;
+
+	scsifront_do_request(info);
+
+	spin_unlock_irq(host->host_lock);
+	wait_event_interruptible(info->shadow[rqid].wq_reset,
+			 info->shadow[rqid].wait_reset);
+	spin_lock_irq(host->host_lock);
+
+	err = info->shadow[rqid].rslt_reset;
+
+	add_id_to_freelist(info, rqid);
+
+	spin_unlock_irq(host->host_lock);
+	return (err);
+}
+
+
+struct scsi_host_template scsifront_sht = {
+	.module			= THIS_MODULE,
+	.name			= "Xen SCSI frontend driver",
+	.queuecommand		= scsifront_queuecommand,
+	.eh_abort_handler	= scsifront_eh_abort_handler,
+	.eh_device_reset_handler= scsifront_dev_reset_handler,
+	.cmd_per_lun		= VSCSIIF_DEFAULT_CMD_PER_LUN,
+	.can_queue		= VSCSIIF_MAX_REQS,
+	.this_id 		= -1,
+	.sg_tablesize		= VSCSIIF_SG_TABLESIZE,
+	.use_clustering		= DISABLE_CLUSTERING,
+	.proc_name		= "scsifront",
+};
+
+
+static int __init scsifront_init(void)
+{
+	int err;
+
+	if (!xen_domain())
+		return -ENODEV;
+
+	err = scsifront_xenbus_init();
+
+	return err;
+}
+
+static void __exit scsifront_exit(void)
+{
+	scsifront_xenbus_unregister();
+}
+
+module_init(scsifront_init);
+module_exit(scsifront_exit);
+
+MODULE_DESCRIPTION("Xen SCSI frontend driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/scsi/xen-scsifront/xenbus.c b/drivers/scsi/xen-scsifront/xenbus.c
new file mode 100644
index 0000000..3b9f04a
--- /dev/null
+++ b/drivers/scsi/xen-scsifront/xenbus.c
@@ -0,0 +1,414 @@
+/*
+ * Xen SCSI frontend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include <linux/version.h>
+#include "common.h"
+
+extern struct scsi_host_template scsifront_sht;
+
+static void scsifront_free(struct vscsifrnt_info *info)
+{
+	struct Scsi_Host *host = info->host;
+
+	if (host->shost_state != SHOST_DEL)
+		scsi_remove_host(info->host);
+
+	if (info->ring_ref != GRANT_INVALID_REF) {
+		gnttab_end_foreign_access(info->ring_ref,
+					0, (unsigned long)info->ring.sring);
+		info->ring_ref = GRANT_INVALID_REF;
+		info->ring.sring = NULL;
+	}
+
+	if (info->irq)
+		unbind_from_irqhandler(info->irq, info);
+	info->irq = 0;
+
+	scsi_host_put(info->host);
+}
+
+
+static int scsifront_alloc_ring(struct vscsifrnt_info *info)
+{
+	struct xenbus_device *dev = info->dev;
+	struct vscsiif_sring *sring;
+	int err = -ENOMEM;
+
+
+	info->ring_ref = GRANT_INVALID_REF;
+
+	/***** Frontend to Backend ring start *****/
+	sring = (struct vscsiif_sring *) __get_free_page(GFP_KERNEL);
+	if (!sring) {
+		xenbus_dev_fatal(dev, err, "fail to allocate shared ring (Front to Back)");
+		return err;
+	}
+	SHARED_RING_INIT(sring);
+	FRONT_RING_INIT(&info->ring, sring, PAGE_SIZE);
+
+	err = xenbus_grant_ring(dev, virt_to_mfn(sring));
+	if (err < 0) {
+		free_page((unsigned long) sring);
+		info->ring.sring = NULL;
+		xenbus_dev_fatal(dev, err, "fail to grant shared ring (Front to Back)");
+		goto free_sring;
+	}
+	info->ring_ref = err;
+
+	err = xenbus_alloc_evtchn(dev, &info->evtchn);
+	if (err)
+		goto free_sring;
+
+	err = bind_evtchn_to_irqhandler(
+			info->evtchn, scsifront_intr,
+			IRQF_SAMPLE_RANDOM, "scsifront", info);
+
+	if (err <= 0) {
+		xenbus_dev_fatal(dev, err, "bind_evtchn_to_irqhandler");
+		goto free_sring;
+	}
+	info->irq = err;
+
+	return 0;
+
+/* free resource */
+free_sring:
+	scsifront_free(info);
+
+	return err;
+}
+
+
+static int scsifront_init_ring(struct vscsifrnt_info *info)
+{
+	struct xenbus_device *dev = info->dev;
+	struct xenbus_transaction xbt;
+	int err;
+
+	DPRINTK("%s\n",__FUNCTION__);
+
+	err = scsifront_alloc_ring(info);
+	if (err)
+		return err;
+	DPRINTK("%u %u\n", info->ring_ref, info->evtchn);
+
+again:
+	err = xenbus_transaction_start(&xbt);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "starting transaction");
+	}
+
+	err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u",
+				info->ring_ref);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "%s", "writing ring-ref");
+		goto fail;
+	}
+
+	err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+				info->evtchn);
+
+	if (err) {
+		xenbus_dev_fatal(dev, err, "%s", "writing event-channel");
+		goto fail;
+	}
+
+	err = xenbus_transaction_end(xbt, 0);
+	if (err) {
+		if (err == -EAGAIN)
+			goto again;
+		xenbus_dev_fatal(dev, err, "completing transaction");
+		goto free_sring;
+	}
+
+	return 0;
+
+fail:
+	xenbus_transaction_end(xbt, 1);
+free_sring:
+	/* free resource */
+	scsifront_free(info);
+
+	return err;
+}
+
+
+static int scsifront_probe(struct xenbus_device *dev,
+				const struct xenbus_device_id *id)
+{
+	struct vscsifrnt_info *info;
+	struct Scsi_Host *host;
+	int i, err = -ENOMEM;
+	char name[TASK_COMM_LEN];
+
+	host = scsi_host_alloc(&scsifront_sht, sizeof(*info));
+	if (!host) {
+		xenbus_dev_fatal(dev, err, "fail to allocate scsi host");
+		return err;
+	}
+	info = (struct vscsifrnt_info *) host->hostdata;
+	info->host = host;
+
+
+	dev_set_drvdata(&dev->dev, info);
+	info->dev  = dev;
+
+	for (i = 0; i < VSCSIIF_MAX_REQS; i++) {
+		info->shadow[i].next_free = i + 1;
+		init_waitqueue_head(&(info->shadow[i].wq_reset));
+		info->shadow[i].wait_reset = 0;
+	}
+	info->shadow[VSCSIIF_MAX_REQS - 1].next_free = 0x0fff;
+
+	err = scsifront_init_ring(info);
+	if (err) {
+		scsi_host_put(host);
+		return err;
+	}
+
+	init_waitqueue_head(&info->wq);
+	spin_lock_init(&info->io_lock);
+	spin_lock_init(&info->shadow_lock);
+
+	snprintf(name, TASK_COMM_LEN, "vscsiif.%d", info->host->host_no);
+
+	info->kthread = kthread_run(scsifront_schedule, info, name);
+	if (IS_ERR(info->kthread)) {
+		err = PTR_ERR(info->kthread);
+		info->kthread = NULL;
+		printk(KERN_ERR "scsifront: kthread start err %d\n", err);
+		goto free_sring;
+	}
+
+	host->max_id      = VSCSIIF_MAX_TARGET;
+	host->max_channel = 0;
+	host->max_lun     = VSCSIIF_MAX_LUN;
+	host->max_sectors = (VSCSIIF_SG_TABLESIZE - 1) * PAGE_SIZE / 512;
+	host->max_cmd_len = VSCSIIF_MAX_COMMAND_SIZE;
+
+	err = scsi_add_host(host, &dev->dev);
+	if (err) {
+		printk(KERN_ERR "scsifront: fail to add scsi host %d\n", err);
+		goto free_sring;
+	}
+
+	xenbus_switch_state(dev, XenbusStateInitialised);
+
+	return 0;
+
+free_sring:
+	/* free resource */
+	scsifront_free(info);
+	return err;
+}
+
+static int scsifront_remove(struct xenbus_device *dev)
+{
+	struct vscsifrnt_info *info = dev_get_drvdata(&dev->dev);
+
+	DPRINTK("%s: %s removed\n",__FUNCTION__ ,dev->nodename);
+
+	if (info->kthread) {
+		kthread_stop(info->kthread);
+		info->kthread = NULL;
+	}
+
+	scsifront_free(info);
+
+	return 0;
+}
+
+
+static int scsifront_disconnect(struct vscsifrnt_info *info)
+{
+	struct xenbus_device *dev = info->dev;
+	struct Scsi_Host *host = info->host;
+
+	DPRINTK("%s: %s disconnect\n",__FUNCTION__ ,dev->nodename);
+
+	/*
+	  When this function is executed,  all devices of
+	  Frontend have been deleted.
+	  Therefore, it need not block I/O before remove_host.
+	*/
+
+	scsi_remove_host(host);
+	xenbus_frontend_closed(dev);
+
+	return 0;
+}
+
+#define VSCSIFRONT_OP_ADD_LUN	1
+#define VSCSIFRONT_OP_DEL_LUN	2
+
+static void scsifront_do_lun_hotplug(struct vscsifrnt_info *info, int op)
+{
+	struct xenbus_device *dev = info->dev;
+	int i, err = 0;
+	char str[64], state_str[64];
+	char **dir;
+	unsigned int dir_n = 0;
+	unsigned int device_state;
+	unsigned int hst, chn, tgt, lun;
+	struct scsi_device *sdev;
+
+	dir = xenbus_directory(XBT_NIL, dev->otherend, "vscsi-devs", &dir_n);
+	if (IS_ERR(dir))
+		return;
+
+	for (i = 0; i < dir_n; i++) {
+		/* read status */
+		snprintf(str, sizeof(str), "vscsi-devs/%s/state", dir[i]);
+		err = xenbus_scanf(XBT_NIL, dev->otherend, str, "%u",
+			&device_state);
+		if (XENBUS_EXIST_ERR(err))
+			continue;
+
+		/* virtual SCSI device */
+		snprintf(str, sizeof(str), "vscsi-devs/%s/v-dev", dir[i]);
+		err = xenbus_scanf(XBT_NIL, dev->otherend, str,
+			"%u:%u:%u:%u", &hst, &chn, &tgt, &lun);
+		if (XENBUS_EXIST_ERR(err))
+			continue;
+
+		/* front device state path */
+		snprintf(state_str, sizeof(state_str), "vscsi-devs/%s/state", dir[i]);
+
+		switch (op) {
+		case VSCSIFRONT_OP_ADD_LUN:
+			if (device_state == XenbusStateInitialised) {
+				sdev = scsi_device_lookup(info->host, chn, tgt, lun);
+				if (sdev) {
+					printk(KERN_ERR "scsifront: Device already in use.\n");
+					scsi_device_put(sdev);
+					xenbus_printf(XBT_NIL, dev->nodename,
+						state_str, "%d", XenbusStateClosed);
+				} else {
+					scsi_add_device(info->host, chn, tgt, lun);
+					xenbus_printf(XBT_NIL, dev->nodename,
+						state_str, "%d", XenbusStateConnected);
+				}
+			}
+			break;
+		case VSCSIFRONT_OP_DEL_LUN:
+			if (device_state == XenbusStateClosing) {
+				sdev = scsi_device_lookup(info->host, chn, tgt, lun);
+				if (sdev) {
+					scsi_remove_device(sdev);
+					scsi_device_put(sdev);
+					xenbus_printf(XBT_NIL, dev->nodename,
+						state_str, "%d", XenbusStateClosed);
+				}
+			}
+			break;
+		default:
+			break;
+		}
+	}
+
+	kfree(dir);
+	return;
+}
+
+
+
+
+static void scsifront_backend_changed(struct xenbus_device *dev,
+				enum xenbus_state backend_state)
+{
+	struct vscsifrnt_info *info = dev_get_drvdata(&dev->dev);
+
+	DPRINTK("%p %u %u\n", dev, dev->state, backend_state);
+
+	switch (backend_state) {
+	case XenbusStateUnknown:
+	case XenbusStateInitialising:
+	case XenbusStateInitWait:
+	case XenbusStateClosed:
+		break;
+
+	case XenbusStateInitialised:
+		break;
+
+	case XenbusStateConnected:
+		if (xenbus_read_driver_state(dev->nodename) ==
+			XenbusStateInitialised) {
+			scsifront_do_lun_hotplug(info, VSCSIFRONT_OP_ADD_LUN);
+		}
+
+		if (dev->state == XenbusStateConnected)
+			break;
+
+		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateClosing:
+		scsifront_disconnect(info);
+		break;
+
+	case XenbusStateReconfiguring:
+		scsifront_do_lun_hotplug(info, VSCSIFRONT_OP_DEL_LUN);
+		xenbus_switch_state(dev, XenbusStateReconfiguring);
+		break;
+
+	case XenbusStateReconfigured:
+		scsifront_do_lun_hotplug(info, VSCSIFRONT_OP_ADD_LUN);
+		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+	}
+}
+
+
+static struct xenbus_device_id scsifront_ids[] = {
+	{ "vscsi" },
+	{ "" }
+};
+MODULE_ALIAS("xen:vscsi");
+
+static struct xenbus_driver scsifront_driver = {
+	.name			= "vscsi",
+	.owner			= THIS_MODULE,
+	.ids			= scsifront_ids,
+	.probe			= scsifront_probe,
+	.remove			= scsifront_remove,
+/* 	.resume			= scsifront_resume, */
+	.otherend_changed	= scsifront_backend_changed,
+};
+
+int scsifront_xenbus_init(void)
+{
+	return xenbus_register_frontend(&scsifront_driver);
+}
+
+void scsifront_xenbus_unregister(void)
+{
+	xenbus_unregister_driver(&scsifront_driver);
+}
+
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index 39e5717..ef2b377 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -363,6 +363,8 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
 #define GNTST_permission_denied (-8) /* Not enough privilege for operation.  */
 #define GNTST_bad_page         (-9) /* Specified page was invalid for op.    */
 #define GNTST_bad_copy_arg    (-10) /* copy arguments cross page boundary */
+#define GNTST_address_too_big (-11) /* transfer page address too large.      */
+#define GNTST_eagain          (-12) /* Could not map at the moment. Retry.   */
 
 #define GNTTABOP_error_msgs {                   \
     "okay",                                     \
@@ -376,6 +378,8 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_query_size);
     "permission denied",                        \
     "bad page",                                 \
     "copy arguments cross page boundary"        \
+    "page address size too large",              \
+    "could not map at the moment, retry"        \
 }
 
 #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
diff --git a/include/xen/interface/io/vscsiif.h b/include/xen/interface/io/vscsiif.h
new file mode 100644
index 0000000..7fbe688
--- /dev/null
+++ b/include/xen/interface/io/vscsiif.h
@@ -0,0 +1,105 @@
+/******************************************************************************
+ * vscsiif.h
+ *
+ * Based on the blkif.h code.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright(c) FUJITSU Limited 2008.
+ */
+
+#ifndef __XEN__PUBLIC_IO_SCSI_H__
+#define __XEN__PUBLIC_IO_SCSI_H__
+
+#include "ring.h"
+#include "../grant_table.h"
+
+/* command between backend and frontend */
+#define VSCSIIF_ACT_SCSI_CDB         1    /* SCSI CDB command */
+#define VSCSIIF_ACT_SCSI_ABORT       2    /* SCSI Device(Lun) Abort*/
+#define VSCSIIF_ACT_SCSI_RESET       3    /* SCSI Device(Lun) Reset*/
+
+
+#define VSCSIIF_BACK_MAX_PENDING_REQS    128
+
+/*
+ * Maximum scatter/gather segments per request.
+ *
+ * Considering balance between allocating al least 16 "vscsiif_request"
+ * structures on one page (4096bytes) and number of scatter gather
+ * needed, we decided to use 26 as a magic number.
+ */
+#define VSCSIIF_SG_TABLESIZE             26
+
+/*
+ * base on linux kernel 2.6.18
+ */
+#define VSCSIIF_MAX_COMMAND_SIZE         16
+#define VSCSIIF_SENSE_BUFFERSIZE         96
+
+
+struct vscsiif_request {
+    uint16_t rqid;          /* private guest value, echoed in resp  */
+    uint8_t act;            /* command between backend and frontend */
+    uint8_t cmd_len;
+
+    uint8_t cmnd[VSCSIIF_MAX_COMMAND_SIZE];
+    uint16_t timeout_per_command;     /* The command is issued by twice
+                                         the value in Backend. */
+    uint16_t channel, id, lun;
+    uint16_t padding;
+    uint8_t sc_data_direction;        /* for DMA_TO_DEVICE(1)
+                                         DMA_FROM_DEVICE(2)
+                                         DMA_NONE(3) requests  */
+    uint8_t nr_segments;              /* Number of pieces of scatter-gather */
+
+    struct scsiif_request_segment {
+        grant_ref_t gref;
+        uint16_t offset;
+        uint16_t length;
+    } seg[VSCSIIF_SG_TABLESIZE];
+    uint32_t reserved[3];
+};
+typedef struct vscsiif_request vscsiif_request_t;
+
+struct vscsiif_response {
+    uint16_t rqid;
+    uint8_t padding;
+    uint8_t sense_len;
+    uint8_t sense_buffer[VSCSIIF_SENSE_BUFFERSIZE];
+    int32_t rslt;
+    uint32_t residual_len;     /* request bufflen -
+                                  return the value from physical device */
+    uint32_t reserved[36];
+};
+typedef struct vscsiif_response vscsiif_response_t;
+
+DEFINE_RING_TYPES(vscsiif, struct vscsiif_request, struct vscsiif_response);
+
+
+#endif  /*__XEN__PUBLIC_IO_SCSI_H__*/
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--3MwIy2ne0vdjdPXF--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:26:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmz8-0005A8-EV; Wed, 30 Nov 2011 16:26:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmz7-00059E-69
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:26:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322670334!5335959!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30656 invoked from network); 30 Nov 2011 16:25:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:25:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:25:34 +0000
Message-Id: <4ED6670C02000078000646B4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:25:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/2] x86: microcode fixes and improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

1: x86: consolidate microcode loading code
2: x86/microcode: enable boot time (pre-Dom0) loading

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:26:31 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVmz8-0005A8-EV; Wed, 30 Nov 2011 16:26:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVmz7-00059E-69
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:26:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1322670334!5335959!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30656 invoked from network); 30 Nov 2011 16:25:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:25:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:25:34 +0000
Message-Id: <4ED6670C02000078000646B4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:25:32 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/2] x86: microcode fixes and improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

1: x86: consolidate microcode loading code
2: x86/microcode: enable boot time (pre-Dom0) loading

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:27:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:27:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVn07-0005K3-W2; Wed, 30 Nov 2011 16:27:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVn05-0005Iu-CH
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:27:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322670393!5272133!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20687 invoked from network); 30 Nov 2011 16:26:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:26:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:26:33 +0000
Message-Id: <4ED6674702000078000646B8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:26:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part8EA11B27.0__="
Subject: [Xen-devel] [PATCH 1/2] x86: consolidate microcode loading code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part8EA11B27.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- memory was leaked on a CPU offline/online cycle (including S3)
- memory was leaked on AMD systems when microcode_update() ran a 2nd
  time with the same data that was used on the first run
- microcode never got restored on APs during S3 resume (or post-boot
  onlining of a CPU that was also online when microcode_update() first
  ran [in the event the prior microcode update got lost intermediately,
  which supposedly shouldn't happen]); this will still be the case when
  no other online CPU has an identical signature (which however is now
  consistent with bringing up such a CPU the very first time)
- resume was unimplemented in the AMD case
- there was a race between microcode_update_cpu() and
  microcode_resume_cpu()

This also moves vendor specific type declarations to the vendor source
file and sets the stage for boot time microcode loading (i.e. without
Dom0 involvement).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -30,9 +30,10 @@ obj-y +=3D io_apic.o
 obj-y +=3D msi.o
 obj-y +=3D ioport_emulate.o
 obj-y +=3D irq.o
-obj-y +=3D microcode.o
 obj-y +=3D microcode_amd.o
 obj-y +=3D microcode_intel.o
+# This must come after the vendor specific files.
+obj-y +=3D microcode.o
 obj-y +=3D mm.o
 obj-y +=3D mpparse.o
 obj-y +=3D nmi.o
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -22,17 +22,17 @@
  */
=20
 #include <xen/config.h>
+#include <xen/cpu.h>
 #include <xen/lib.h>
 #include <xen/kernel.h>
 #include <xen/init.h>
+#include <xen/notifier.h>
 #include <xen/sched.h>
 #include <xen/smp.h>
 #include <xen/spinlock.h>
 #include <xen/guest_access.h>
=20
-#include <asm/current.h>
 #include <asm/msr.h>
-#include <asm/uaccess.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
=20
@@ -69,30 +69,50 @@ int microcode_resume_cpu(int cpu)
     int err;
     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
     struct cpu_signature nsig;
+    unsigned int cpu2;
=20
-    if ( !uci->mc.mc_valid )
-        return -EIO;
+    spin_lock(&microcode_mutex);
=20
-    /*
-     * Let's verify that the 'cached' ucode does belong
-     * to this cpu (a bit of paranoia):
-     */
-    err =3D microcode_ops->collect_cpu_info(cpu, &nsig);
+    err =3D microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig);
     if ( err )
     {
-        microcode_fini_cpu(cpu);
+        __microcode_fini_cpu(cpu);
+        spin_unlock(&microcode_mutex);
         return err;
     }
=20
-    if ( microcode_ops->microcode_resume_match(cpu, &nsig) )
+    if ( uci->mc.mc_valid )
     {
-        return microcode_ops->apply_microcode(cpu);
+        err =3D microcode_ops->microcode_resume_match(cpu, uci->mc.mc_vali=
d);
+        if ( err >=3D 0 )
+        {
+            if ( err )
+                err =3D microcode_ops->apply_microcode(cpu);
+            spin_unlock(&microcode_mutex);
+            return err;
+        }
     }
-    else
+
+    nsig =3D uci->cpu_sig;
+    __microcode_fini_cpu(cpu);
+    uci->cpu_sig =3D nsig;
+
+    err =3D -EIO;
+    for_each_online_cpu ( cpu2 )
     {
-        microcode_fini_cpu(cpu);
-        return -EIO;
+        uci =3D &per_cpu(ucode_cpu_info, cpu2);
+        if ( uci->mc.mc_valid &&
+             microcode_ops->microcode_resume_match(cpu, uci->mc.mc_valid) =
> 0 )
+        {
+            err =3D microcode_ops->apply_microcode(cpu);
+            break;
+        }
     }
+
+    __microcode_fini_cpu(cpu);
+    spin_unlock(&microcode_mutex);
+
+    return err;
 }
=20
 static int microcode_update_cpu(const void *buf, size_t size)
@@ -162,3 +182,30 @@ int microcode_update(XEN_GUEST_HANDLE(co
=20
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, =
info);
 }
+
+static int microcode_percpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu =3D (unsigned long)hcpu;
+
+    switch ( action )
+    {
+    case CPU_DEAD:
+        microcode_fini_cpu(cpu);
+        break;
+    }
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block microcode_percpu_nfb =3D {
+    .notifier_call =3D microcode_percpu_callback,
+};
+
+static int __init microcode_presmp_init(void)
+{
+    if ( microcode_ops )
+        register_cpu_notifier(&microcode_percpu_nfb);
+    return 0;
+}
+presmp_initcall(microcode_presmp_init);
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -23,27 +23,53 @@
 #include <xen/spinlock.h>
=20
 #include <asm/msr.h>
-#include <asm/uaccess.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
=20
 #define pr_debug(x...) ((void)0)
=20
+struct equiv_cpu_entry {
+    uint32_t installed_cpu;
+    uint32_t fixed_errata_mask;
+    uint32_t fixed_errata_compare;
+    uint16_t equiv_cpu;
+    uint16_t reserved;
+} __attribute__((packed));
+
+struct microcode_header_amd {
+    uint32_t data_code;
+    uint32_t patch_id;
+    uint8_t  mc_patch_data_id[2];
+    uint8_t  mc_patch_data_len;
+    uint8_t  init_flag;
+    uint32_t mc_patch_data_checksum;
+    uint32_t nb_dev_id;
+    uint32_t sb_dev_id;
+    uint16_t processor_rev_id;
+    uint8_t  nb_rev_id;
+    uint8_t  sb_rev_id;
+    uint8_t  bios_api_rev;
+    uint8_t  reserved1[3];
+    uint32_t match_reg[8];
+} __attribute__((packed));
+
 #define UCODE_MAGIC                0x00414d44
 #define UCODE_EQUIV_CPU_TABLE_TYPE 0x00000000
 #define UCODE_UCODE_TYPE           0x00000001
=20
 #define UCODE_MAX_SIZE          (2048)
-#define DEFAULT_UCODE_DATASIZE  (896)
 #define MC_HEADER_SIZE          (sizeof(struct microcode_header_amd))
-#define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + MC_HEADER_SIZE)
-#define DWSIZE                  (sizeof(uint32_t))
+
+struct microcode_amd {
+    struct microcode_header_amd hdr;
+    unsigned int mpb[(UCODE_MAX_SIZE - MC_HEADER_SIZE) / 4];
+    unsigned int equiv_cpu_table_size;
+    struct equiv_cpu_entry equiv_cpu_table[];
+};
=20
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
=20
-struct equiv_cpu_entry *equiv_cpu_table;
-
 static int collect_cpu_info(int cpu, struct cpu_signature *csig)
 {
     struct cpuinfo_x86 *c =3D &cpu_data[cpu];
@@ -65,10 +91,11 @@ static int collect_cpu_info(int cpu, str
     return 0;
 }
=20
-static int microcode_fits(void *mc, int cpu)
+static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
-    struct microcode_header_amd *mc_header =3D mc;
+    const struct microcode_header_amd *mc_header =3D &mc_amd->hdr;
+    const struct equiv_cpu_entry *equiv_cpu_table =3D mc_amd->equiv_cpu_ta=
ble;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id =3D 0x0;
     unsigned int i;
@@ -99,7 +126,7 @@ static int microcode_fits(void *mc, int=20
     }
=20
     if ( mc_header->patch_id <=3D uci->cpu_sig.rev )
-        return -EINVAL;
+        return 0;
=20
     printk(KERN_DEBUG "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=3D0x%x)\n",
@@ -186,17 +213,15 @@ static int get_next_ucode_from_buffer_am
     return 0;
 }
=20
-static int install_equiv_cpu_table(const void *buf, uint32_t size,
-                                   unsigned long *offset)
+static int install_equiv_cpu_table(
+    struct microcode_amd *mc_amd,
+    const uint32_t *buf_pos,
+    unsigned long *offset)
 {
-    const uint32_t *buf_pos =3D buf;
-    unsigned long off;
-
-    off =3D *offset;
-    *offset =3D 0;
+    uint32_t size =3D buf_pos[2];
=20
     /* No more data */
-    if ( off >=3D size )
+    if ( size + 12 >=3D *offset )
         return -EINVAL;
=20
     if ( buf_pos[1] !=3D UCODE_EQUIV_CPU_TABLE_TYPE )
@@ -213,15 +238,8 @@ static int install_equiv_cpu_table(const
         return -EINVAL;
     }
=20
-    equiv_cpu_table =3D xmalloc_bytes(size);
-    if ( equiv_cpu_table =3D=3D NULL )
-    {
-        printk(KERN_ERR "microcode: error, can't allocate "
-               "memory for equiv CPU table\n");
-        return -ENOMEM;
-    }
-
-    memcpy(equiv_cpu_table, (const void *)&buf_pos[3], size);
+    memcpy(mc_amd->equiv_cpu_table, &buf_pos[3], size);
+    mc_amd->equiv_cpu_table_size =3D size;
=20
     *offset =3D size + 12;	/* add header length */
=20
@@ -231,11 +249,11 @@ static int install_equiv_cpu_table(const
 static int cpu_request_microcode(int cpu, const void *buf, size_t size)
 {
     const uint32_t *buf_pos;
-    unsigned long offset =3D 0;
+    struct microcode_amd *mc_amd, *mc_old;
+    unsigned long offset =3D size;
     int error =3D 0;
     int ret;
     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
-    void *mc;
=20
     /* We should bind the task to the CPU */
     BUG_ON(cpu !=3D raw_smp_processor_id());
@@ -249,59 +267,85 @@ static int cpu_request_microcode(int cpu
         return -EINVAL;
     }
=20
-    error =3D install_equiv_cpu_table(buf, (uint32_t)(buf_pos[2]), =
&offset);
-    if ( error )
+    mc_amd =3D xmalloc_bytes(sizeof(*mc_amd) + buf_pos[2]);
+    if ( !mc_amd )
     {
-        printk(KERN_ERR "microcode: installing equivalent cpu table =
failed\n");
-        return -EINVAL;
+        printk(KERN_ERR "microcode: error! "
+               "Can not allocate memory for microcode patch\n");
+        return -ENOMEM;
     }
=20
-    mc =3D xmalloc_bytes(UCODE_MAX_SIZE);
-    if ( mc =3D=3D NULL )
+    error =3D install_equiv_cpu_table(mc_amd, buf, &offset);
+    if ( error )
     {
-        printk(KERN_ERR "microcode: error! "
-               "Can not allocate memory for microcode patch\n");
-        error =3D -ENOMEM;
-        goto out;
+        xfree(mc_amd);
+        printk(KERN_ERR "microcode: installing equivalent cpu table =
failed\n");
+        return -EINVAL;
     }
=20
+    mc_old =3D uci->mc.mc_amd;
     /* implicitely validates uci->mc.mc_valid */
-    uci->mc.mc_amd =3D mc;
+    uci->mc.mc_amd =3D mc_amd;
=20
     /*
      * It's possible the data file has multiple matching ucode,
      * lets keep searching till the latest version
      */
-    while ( (ret =3D get_next_ucode_from_buffer_amd(mc, buf, size, =
&offset)) =3D=3D 0)
+    while ( (ret =3D get_next_ucode_from_buffer_amd(&mc_amd->hdr, buf, =
size,
+                                                  &offset)) =3D=3D 0 )
     {
-        error =3D microcode_fits(mc, cpu);
+        error =3D microcode_fits(mc_amd, cpu);
         if (error <=3D 0)
             continue;
=20
         error =3D apply_microcode(cpu);
         if (error =3D=3D 0)
+        {
+            error =3D 1;
             break;
+        }
     }
=20
+    if ( ret < 0 )
+        error =3D ret;
+
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error) {
-        xfree(mc);
-        mc =3D NULL;
-    }
-    uci->mc.mc_amd =3D mc;
-
-out:
-    xfree(equiv_cpu_table);
-    equiv_cpu_table =3D NULL;
+    if (error =3D=3D 1)
+    {
+        xfree(mc_old);
+        return 0;
+    }
+    xfree(mc_amd);
+    uci->mc.mc_amd =3D mc_old;
=20
     return error;
 }
=20
-static int microcode_resume_match(int cpu, struct cpu_signature *nsig)
+static int microcode_resume_match(int cpu, const void *mc)
 {
-    return 0;
+    struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
+    struct microcode_amd *mc_amd =3D uci->mc.mc_amd;
+    const struct microcode_amd *src =3D mc;
+    int res =3D microcode_fits(src, cpu);
+
+    if ( res <=3D 0 )
+        return res;
+
+    if ( src !=3D mc_amd )
+    {
+        xfree(mc_amd);
+        mc_amd =3D xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size)=
;
+        uci->mc.mc_amd =3D mc_amd;
+        if ( !mc_amd )
+            return -ENOMEM;
+        memcpy(mc_amd, src, UCODE_MAX_SIZE);
+        memcpy(mc_amd->equiv_cpu_table, src->equiv_cpu_table,
+               src->equiv_cpu_table_size);
+    }
+
+    return 1;
 }
=20
 static const struct microcode_ops microcode_amd_ops =3D {
@@ -317,4 +361,4 @@ static __init int microcode_init_amd(voi
         microcode_ops =3D &microcode_amd_ops;
     return 0;
 }
-__initcall(microcode_init_amd);
+presmp_initcall(microcode_init_amd);
--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -30,12 +30,43 @@
 #include <xen/spinlock.h>
=20
 #include <asm/msr.h>
-#include <asm/uaccess.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
=20
 #define pr_debug(x...) ((void)0)
=20
+struct microcode_header_intel {
+    unsigned int hdrver;
+    unsigned int rev;
+    unsigned int date;
+    unsigned int sig;
+    unsigned int cksum;
+    unsigned int ldrver;
+    unsigned int pf;
+    unsigned int datasize;
+    unsigned int totalsize;
+    unsigned int reserved[3];
+};
+
+struct microcode_intel {
+    struct microcode_header_intel hdr;
+    unsigned int bits[0];
+};
+
+/* microcode format is extended from prescott processors */
+struct extended_signature {
+    unsigned int sig;
+    unsigned int pf;
+    unsigned int cksum;
+};
+
+struct extended_sigtable {
+    unsigned int count;
+    unsigned int cksum;
+    unsigned int reserved[3];
+    struct extended_signature sigs[0];
+};
+
 #define DEFAULT_UCODE_DATASIZE  (2000)
 #define MC_HEADER_SIZE          (sizeof(struct microcode_header_intel))
 #define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + MC_HEADER_SIZE)
@@ -98,7 +129,8 @@ static int collect_cpu_info(int cpu_num,
 }
=20
 static inline int microcode_update_match(
-    int cpu_num, struct microcode_header_intel *mc_header, int sig, int =
pf)
+    int cpu_num, const struct microcode_header_intel *mc_header,
+    int sig, int pf)
 {
     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu_num);
=20
@@ -200,11 +232,11 @@ static int microcode_sanity_check(void *
  * return 1 - found update
  * return < 0 - error
  */
-static int get_matching_microcode(void *mc, int cpu)
+static int get_matching_microcode(const void *mc, int cpu)
 {
     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
-    struct microcode_header_intel *mc_header =3D mc;
-    struct extended_sigtable *ext_header;
+    const struct microcode_header_intel *mc_header =3D mc;
+    const struct extended_sigtable *ext_header;
     unsigned long total_size =3D get_totalsize(mc_header);
     int ext_sigcount, i;
     struct extended_signature *ext_sig;
@@ -229,6 +261,8 @@ static int get_matching_microcode(void *
     }
     return 0;
  find:
+    if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >=3D mc_header->rev=
 )
+        return 0;
     pr_debug("microcode: CPU%d found a matching microcode update with"
              " version 0x%x (current=3D0x%x)\n",
              cpu, mc_header->rev, uci->cpu_sig.rev);
@@ -239,10 +273,8 @@ static int get_matching_microcode(void *
         return -ENOMEM;
     }
=20
-    /* free previous update file */
-    xfree(uci->mc.mc_intel);
-
     memcpy(new_mc, mc, total_size);
+    xfree(uci->mc.mc_intel);
     uci->mc.mc_intel =3D new_mc;
     return 1;
 }
@@ -361,12 +393,9 @@ static int cpu_request_microcode(int cpu
     return error;
 }
=20
-static int microcode_resume_match(int cpu, struct cpu_signature *nsig)
+static int microcode_resume_match(int cpu, const void *mc)
 {
-    struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
-
-    return (sigmatch(nsig->sig, uci->cpu_sig.sig, nsig->pf, uci->cpu_sig.p=
f) &&
-            (uci->cpu_sig.rev > nsig->rev));
+    return get_matching_microcode(mc, cpu);
 }
=20
 static const struct microcode_ops microcode_intel_ops =3D {
@@ -382,4 +411,4 @@ static __init int microcode_init_intel(v
         microcode_ops =3D &microcode_intel_ops;
     return 0;
 }
-__initcall(microcode_init_intel);
+presmp_initcall(microcode_init_intel);
--- a/xen/include/asm-x86/microcode.h
+++ b/xen/include/asm-x86/microcode.h
@@ -7,74 +7,12 @@ struct cpu_signature;
 struct ucode_cpu_info;
=20
 struct microcode_ops {
-    int (*microcode_resume_match)(int cpu, struct cpu_signature *nsig);
+    int (*microcode_resume_match)(int cpu, const void *mc);
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
 };
=20
-struct microcode_header_intel {
-    unsigned int hdrver;
-    unsigned int rev;
-    unsigned int date;
-    unsigned int sig;
-    unsigned int cksum;
-    unsigned int ldrver;
-    unsigned int pf;
-    unsigned int datasize;
-    unsigned int totalsize;
-    unsigned int reserved[3];
-};
-
-struct microcode_intel {
-    struct microcode_header_intel hdr;
-    unsigned int bits[0];
-};
-
-/* microcode format is extended from prescott processors */
-struct extended_signature {
-    unsigned int sig;
-    unsigned int pf;
-    unsigned int cksum;
-};
-
-struct extended_sigtable {
-    unsigned int count;
-    unsigned int cksum;
-    unsigned int reserved[3];
-    struct extended_signature sigs[0];
-};
-
-struct equiv_cpu_entry {
-    uint32_t installed_cpu;
-    uint32_t fixed_errata_mask;
-    uint32_t fixed_errata_compare;
-    uint16_t equiv_cpu;
-    uint16_t reserved;
-} __attribute__((packed));
-
-struct microcode_header_amd {
-    uint32_t data_code;
-    uint32_t patch_id;
-    uint8_t  mc_patch_data_id[2];
-    uint8_t  mc_patch_data_len;
-    uint8_t  init_flag;
-    uint32_t mc_patch_data_checksum;
-    uint32_t nb_dev_id;
-    uint32_t sb_dev_id;
-    uint16_t processor_rev_id;
-    uint8_t  nb_rev_id;
-    uint8_t  sb_rev_id;
-    uint8_t  bios_api_rev;
-    uint8_t  reserved1[3];
-    uint32_t match_reg[8];
-} __attribute__((packed));
-
-struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[0];
-};
-
 struct cpu_signature {
     unsigned int sig;
     unsigned int pf;



--=__Part8EA11B27.0__=
Content-Type: text/plain; name="x86-ucode-consolidation.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ucode-consolidation.patch"

x86: consolidate microcode loading code=0A=0A- memory was leaked on a CPU =
offline/online cycle (including S3)=0A- memory was leaked on AMD systems =
when microcode_update() ran a 2nd=0A  time with the same data that was =
used on the first run=0A- microcode never got restored on APs during S3 =
resume (or post-boot=0A  onlining of a CPU that was also online when =
microcode_update() first=0A  ran [in the event the prior microcode update =
got lost intermediately,=0A  which supposedly shouldn't happen]); this =
will still be the case when=0A  no other online CPU has an identical =
signature (which however is now=0A  consistent with bringing up such a CPU =
the very first time)=0A- resume was unimplemented in the AMD case=0A- =
there was a race between microcode_update_cpu() and=0A  microcode_resume_cp=
u()=0A=0AThis also moves vendor specific type declarations to the vendor =
source=0Afile and sets the stage for boot time microcode loading (i.e. =
without=0ADom0 involvement).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse=
.com>=0A=0A--- a/xen/arch/x86/Makefile=0A+++ b/xen/arch/x86/Makefile=0A@@ =
-30,9 +30,10 @@ obj-y +=3D io_apic.o=0A obj-y +=3D msi.o=0A obj-y +=3D =
ioport_emulate.o=0A obj-y +=3D irq.o=0A-obj-y +=3D microcode.o=0A obj-y =
+=3D microcode_amd.o=0A obj-y +=3D microcode_intel.o=0A+# This must come =
after the vendor specific files.=0A+obj-y +=3D microcode.o=0A obj-y +=3D =
mm.o=0A obj-y +=3D mpparse.o=0A obj-y +=3D nmi.o=0A--- a/xen/arch/x86/micro=
code.c=0A+++ b/xen/arch/x86/microcode.c=0A@@ -22,17 +22,17 @@=0A  */=0A =
=0A #include <xen/config.h>=0A+#include <xen/cpu.h>=0A #include <xen/lib.h>=
=0A #include <xen/kernel.h>=0A #include <xen/init.h>=0A+#include <xen/notif=
ier.h>=0A #include <xen/sched.h>=0A #include <xen/smp.h>=0A #include =
<xen/spinlock.h>=0A #include <xen/guest_access.h>=0A =0A-#include =
<asm/current.h>=0A #include <asm/msr.h>=0A-#include <asm/uaccess.h>=0A =
#include <asm/processor.h>=0A #include <asm/microcode.h>=0A =0A@@ -69,30 =
+69,50 @@ int microcode_resume_cpu(int cpu)=0A     int err;=0A     struct =
ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);=0A     struct =
cpu_signature nsig;=0A+    unsigned int cpu2;=0A =0A-    if ( !uci->mc.mc_v=
alid )=0A-        return -EIO;=0A+    spin_lock(&microcode_mutex);=0A =0A- =
   /*=0A-     * Let's verify that the 'cached' ucode does belong=0A-     * =
to this cpu (a bit of paranoia):=0A-     */=0A-    err =3D microcode_ops->c=
ollect_cpu_info(cpu, &nsig);=0A+    err =3D microcode_ops->collect_cpu_info=
(cpu, &uci->cpu_sig);=0A     if ( err )=0A     {=0A-        microcode_fini_=
cpu(cpu);=0A+        __microcode_fini_cpu(cpu);=0A+        spin_unlock(&mic=
rocode_mutex);=0A         return err;=0A     }=0A =0A-    if ( microcode_op=
s->microcode_resume_match(cpu, &nsig) )=0A+    if ( uci->mc.mc_valid )=0A  =
   {=0A-        return microcode_ops->apply_microcode(cpu);=0A+        err =
=3D microcode_ops->microcode_resume_match(cpu, uci->mc.mc_valid);=0A+      =
  if ( err >=3D 0 )=0A+        {=0A+            if ( err )=0A+             =
   err =3D microcode_ops->apply_microcode(cpu);=0A+            spin_unlock(=
&microcode_mutex);=0A+            return err;=0A+        }=0A     }=0A-    =
else=0A+=0A+    nsig =3D uci->cpu_sig;=0A+    __microcode_fini_cpu(cpu);=0A=
+    uci->cpu_sig =3D nsig;=0A+=0A+    err =3D -EIO;=0A+    for_each_online=
_cpu ( cpu2 )=0A     {=0A-        microcode_fini_cpu(cpu);=0A-        =
return -EIO;=0A+        uci =3D &per_cpu(ucode_cpu_info, cpu2);=0A+        =
if ( uci->mc.mc_valid &&=0A+             microcode_ops->microcode_resume_ma=
tch(cpu, uci->mc.mc_valid) > 0 )=0A+        {=0A+            err =3D =
microcode_ops->apply_microcode(cpu);=0A+            break;=0A+        }=0A =
    }=0A+=0A+    __microcode_fini_cpu(cpu);=0A+    spin_unlock(&microcode_m=
utex);=0A+=0A+    return err;=0A }=0A =0A static int microcode_update_cpu(c=
onst void *buf, size_t size)=0A@@ -162,3 +182,30 @@ int microcode_update(XE=
N_GUEST_HANDLE(co=0A =0A     return continue_hypercall_on_cpu(info->cpu, =
do_microcode_update, info);=0A }=0A+=0A+static int microcode_percpu_callbac=
k(=0A+    struct notifier_block *nfb, unsigned long action, void *hcpu)=0A+=
{=0A+    unsigned int cpu =3D (unsigned long)hcpu;=0A+=0A+    switch ( =
action )=0A+    {=0A+    case CPU_DEAD:=0A+        microcode_fini_cpu(cpu);=
=0A+        break;=0A+    }=0A+=0A+    return NOTIFY_DONE;=0A+}=0A+=0A+stat=
ic struct notifier_block microcode_percpu_nfb =3D {=0A+    .notifier_call =
=3D microcode_percpu_callback,=0A+};=0A+=0A+static int __init microcode_pre=
smp_init(void)=0A+{=0A+    if ( microcode_ops )=0A+        register_cpu_not=
ifier(&microcode_percpu_nfb);=0A+    return 0;=0A+}=0A+presmp_initcall(micr=
ocode_presmp_init);=0A--- a/xen/arch/x86/microcode_amd.c=0A+++ b/xen/arch/x=
86/microcode_amd.c=0A@@ -23,27 +23,53 @@=0A #include <xen/spinlock.h>=0A =
=0A #include <asm/msr.h>=0A-#include <asm/uaccess.h>=0A #include <asm/proce=
ssor.h>=0A #include <asm/microcode.h>=0A =0A #define pr_debug(x...) =
((void)0)=0A =0A+struct equiv_cpu_entry {=0A+    uint32_t installed_cpu;=0A=
+    uint32_t fixed_errata_mask;=0A+    uint32_t fixed_errata_compare;=0A+ =
   uint16_t equiv_cpu;=0A+    uint16_t reserved;=0A+} __attribute__((packed=
));=0A+=0A+struct microcode_header_amd {=0A+    uint32_t data_code;=0A+    =
uint32_t patch_id;=0A+    uint8_t  mc_patch_data_id[2];=0A+    uint8_t  =
mc_patch_data_len;=0A+    uint8_t  init_flag;=0A+    uint32_t mc_patch_data=
_checksum;=0A+    uint32_t nb_dev_id;=0A+    uint32_t sb_dev_id;=0A+    =
uint16_t processor_rev_id;=0A+    uint8_t  nb_rev_id;=0A+    uint8_t  =
sb_rev_id;=0A+    uint8_t  bios_api_rev;=0A+    uint8_t  reserved1[3];=0A+ =
   uint32_t match_reg[8];=0A+} __attribute__((packed));=0A+=0A #define =
UCODE_MAGIC                0x00414d44=0A #define UCODE_EQUIV_CPU_TABLE_TYPE=
 0x00000000=0A #define UCODE_UCODE_TYPE           0x00000001=0A =0A =
#define UCODE_MAX_SIZE          (2048)=0A-#define DEFAULT_UCODE_DATASIZE  =
(896)=0A #define MC_HEADER_SIZE          (sizeof(struct microcode_header_am=
d))=0A-#define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + MC_HEADER_=
SIZE)=0A-#define DWSIZE                  (sizeof(uint32_t))=0A+=0A+struct =
microcode_amd {=0A+    struct microcode_header_amd hdr;=0A+    unsigned =
int mpb[(UCODE_MAX_SIZE - MC_HEADER_SIZE) / 4];=0A+    unsigned int =
equiv_cpu_table_size;=0A+    struct equiv_cpu_entry equiv_cpu_table[];=0A+}=
;=0A =0A /* serialize access to the physical write */=0A static DEFINE_SPIN=
LOCK(microcode_update_lock);=0A =0A-struct equiv_cpu_entry *equiv_cpu_table=
;=0A-=0A static int collect_cpu_info(int cpu, struct cpu_signature =
*csig)=0A {=0A     struct cpuinfo_x86 *c =3D &cpu_data[cpu];=0A@@ -65,10 =
+91,11 @@ static int collect_cpu_info(int cpu, str=0A     return 0;=0A =
}=0A =0A-static int microcode_fits(void *mc, int cpu)=0A+static int =
microcode_fits(const struct microcode_amd *mc_amd, int cpu)=0A {=0A     =
struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);=0A-    =
struct microcode_header_amd *mc_header =3D mc;=0A+    const struct =
microcode_header_amd *mc_header =3D &mc_amd->hdr;=0A+    const struct =
equiv_cpu_entry *equiv_cpu_table =3D mc_amd->equiv_cpu_table;=0A     =
unsigned int current_cpu_id;=0A     unsigned int equiv_cpu_id =3D 0x0;=0A  =
   unsigned int i;=0A@@ -99,7 +126,7 @@ static int microcode_fits(void =
*mc, int =0A     }=0A =0A     if ( mc_header->patch_id <=3D uci->cpu_sig.re=
v )=0A-        return -EINVAL;=0A+        return 0;=0A =0A     printk(KERN_=
DEBUG "microcode: CPU%d found a matching microcode "=0A            "update =
with version 0x%x (current=3D0x%x)\n",=0A@@ -186,17 +213,15 @@ static int =
get_next_ucode_from_buffer_am=0A     return 0;=0A }=0A =0A-static int =
install_equiv_cpu_table(const void *buf, uint32_t size,=0A-                =
                   unsigned long *offset)=0A+static int install_equiv_cpu_t=
able(=0A+    struct microcode_amd *mc_amd,=0A+    const uint32_t =
*buf_pos,=0A+    unsigned long *offset)=0A {=0A-    const uint32_t =
*buf_pos =3D buf;=0A-    unsigned long off;=0A-=0A-    off =3D *offset;=0A-=
    *offset =3D 0;=0A+    uint32_t size =3D buf_pos[2];=0A =0A     /* No =
more data */=0A-    if ( off >=3D size )=0A+    if ( size + 12 >=3D =
*offset )=0A         return -EINVAL;=0A =0A     if ( buf_pos[1] !=3D =
UCODE_EQUIV_CPU_TABLE_TYPE )=0A@@ -213,15 +238,8 @@ static int install_equi=
v_cpu_table(const=0A         return -EINVAL;=0A     }=0A =0A-    equiv_cpu_=
table =3D xmalloc_bytes(size);=0A-    if ( equiv_cpu_table =3D=3D NULL =
)=0A-    {=0A-        printk(KERN_ERR "microcode: error, can't allocate =
"=0A-               "memory for equiv CPU table\n");=0A-        return =
-ENOMEM;=0A-    }=0A-=0A-    memcpy(equiv_cpu_table, (const void *)&buf_pos=
[3], size);=0A+    memcpy(mc_amd->equiv_cpu_table, &buf_pos[3], size);=0A+ =
   mc_amd->equiv_cpu_table_size =3D size;=0A =0A     *offset =3D size + =
12;	/* add header length */=0A =0A@@ -231,11 +249,11 @@ static int =
install_equiv_cpu_table(const=0A static int cpu_request_microcode(int cpu, =
const void *buf, size_t size)=0A {=0A     const uint32_t *buf_pos;=0A-    =
unsigned long offset =3D 0;=0A+    struct microcode_amd *mc_amd, =
*mc_old;=0A+    unsigned long offset =3D size;=0A     int error =3D 0;=0A  =
   int ret;=0A     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, =
cpu);=0A-    void *mc;=0A =0A     /* We should bind the task to the CPU =
*/=0A     BUG_ON(cpu !=3D raw_smp_processor_id());=0A@@ -249,59 +267,85 @@ =
static int cpu_request_microcode(int cpu=0A         return -EINVAL;=0A     =
}=0A =0A-    error =3D install_equiv_cpu_table(buf, (uint32_t)(buf_pos[2]),=
 &offset);=0A-    if ( error )=0A+    mc_amd =3D xmalloc_bytes(sizeof(*mc_a=
md) + buf_pos[2]);=0A+    if ( !mc_amd )=0A     {=0A-        printk(KERN_ER=
R "microcode: installing equivalent cpu table failed\n");=0A-        =
return -EINVAL;=0A+        printk(KERN_ERR "microcode: error! "=0A+        =
       "Can not allocate memory for microcode patch\n");=0A+        return =
-ENOMEM;=0A     }=0A =0A-    mc =3D xmalloc_bytes(UCODE_MAX_SIZE);=0A-    =
if ( mc =3D=3D NULL )=0A+    error =3D install_equiv_cpu_table(mc_amd, =
buf, &offset);=0A+    if ( error )=0A     {=0A-        printk(KERN_ERR =
"microcode: error! "=0A-               "Can not allocate memory for =
microcode patch\n");=0A-        error =3D -ENOMEM;=0A-        goto =
out;=0A+        xfree(mc_amd);=0A+        printk(KERN_ERR "microcode: =
installing equivalent cpu table failed\n");=0A+        return -EINVAL;=0A  =
   }=0A =0A+    mc_old =3D uci->mc.mc_amd;=0A     /* implicitely validates =
uci->mc.mc_valid */=0A-    uci->mc.mc_amd =3D mc;=0A+    uci->mc.mc_amd =
=3D mc_amd;=0A =0A     /*=0A      * It's possible the data file has =
multiple matching ucode,=0A      * lets keep searching till the latest =
version=0A      */=0A-    while ( (ret =3D get_next_ucode_from_buffer_amd(m=
c, buf, size, &offset)) =3D=3D 0)=0A+    while ( (ret =3D get_next_ucode_fr=
om_buffer_amd(&mc_amd->hdr, buf, size,=0A+                                 =
                 &offset)) =3D=3D 0 )=0A     {=0A-        error =3D =
microcode_fits(mc, cpu);=0A+        error =3D microcode_fits(mc_amd, =
cpu);=0A         if (error <=3D 0)=0A             continue;=0A =0A         =
error =3D apply_microcode(cpu);=0A         if (error =3D=3D 0)=0A+        =
{=0A+            error =3D 1;=0A             break;=0A+        }=0A     =
}=0A =0A+    if ( ret < 0 )=0A+        error =3D ret;=0A+=0A     /* On =
success keep the microcode patch for=0A      * re-apply on resume.=0A      =
*/=0A-    if (error) {=0A-        xfree(mc);=0A-        mc =3D NULL;=0A-   =
 }=0A-    uci->mc.mc_amd =3D mc;=0A-=0A-out:=0A-    xfree(equiv_cpu_table);=
=0A-    equiv_cpu_table =3D NULL;=0A+    if (error =3D=3D 1)=0A+    {=0A+  =
      xfree(mc_old);=0A+        return 0;=0A+    }=0A+    xfree(mc_amd);=0A=
+    uci->mc.mc_amd =3D mc_old;=0A =0A     return error;=0A }=0A =0A-static=
 int microcode_resume_match(int cpu, struct cpu_signature *nsig)=0A+static =
int microcode_resume_match(int cpu, const void *mc)=0A {=0A-    return =
0;=0A+    struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, =
cpu);=0A+    struct microcode_amd *mc_amd =3D uci->mc.mc_amd;=0A+    const =
struct microcode_amd *src =3D mc;=0A+    int res =3D microcode_fits(src, =
cpu);=0A+=0A+    if ( res <=3D 0 )=0A+        return res;=0A+=0A+    if ( =
src !=3D mc_amd )=0A+    {=0A+        xfree(mc_amd);=0A+        mc_amd =3D =
xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);=0A+        =
uci->mc.mc_amd =3D mc_amd;=0A+        if ( !mc_amd )=0A+            return =
-ENOMEM;=0A+        memcpy(mc_amd, src, UCODE_MAX_SIZE);=0A+        =
memcpy(mc_amd->equiv_cpu_table, src->equiv_cpu_table,=0A+               =
src->equiv_cpu_table_size);=0A+    }=0A+=0A+    return 1;=0A }=0A =0A =
static const struct microcode_ops microcode_amd_ops =3D {=0A@@ -317,4 =
+361,4 @@ static __init int microcode_init_amd(voi=0A         microcode_ops=
 =3D &microcode_amd_ops;=0A     return 0;=0A }=0A-__initcall(microcode_init=
_amd);=0A+presmp_initcall(microcode_init_amd);=0A--- a/xen/arch/x86/microco=
de_intel.c=0A+++ b/xen/arch/x86/microcode_intel.c=0A@@ -30,12 +30,43 @@=0A =
#include <xen/spinlock.h>=0A =0A #include <asm/msr.h>=0A-#include =
<asm/uaccess.h>=0A #include <asm/processor.h>=0A #include <asm/microcode.h>=
=0A =0A #define pr_debug(x...) ((void)0)=0A =0A+struct microcode_header_int=
el {=0A+    unsigned int hdrver;=0A+    unsigned int rev;=0A+    unsigned =
int date;=0A+    unsigned int sig;=0A+    unsigned int cksum;=0A+    =
unsigned int ldrver;=0A+    unsigned int pf;=0A+    unsigned int =
datasize;=0A+    unsigned int totalsize;=0A+    unsigned int reserved[3];=
=0A+};=0A+=0A+struct microcode_intel {=0A+    struct microcode_header_intel=
 hdr;=0A+    unsigned int bits[0];=0A+};=0A+=0A+/* microcode format is =
extended from prescott processors */=0A+struct extended_signature {=0A+    =
unsigned int sig;=0A+    unsigned int pf;=0A+    unsigned int cksum;=0A+};=
=0A+=0A+struct extended_sigtable {=0A+    unsigned int count;=0A+    =
unsigned int cksum;=0A+    unsigned int reserved[3];=0A+    struct =
extended_signature sigs[0];=0A+};=0A+=0A #define DEFAULT_UCODE_DATASIZE  =
(2000)=0A #define MC_HEADER_SIZE          (sizeof(struct microcode_header_i=
ntel))=0A #define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + =
MC_HEADER_SIZE)=0A@@ -98,7 +129,8 @@ static int collect_cpu_info(int =
cpu_num,=0A }=0A =0A static inline int microcode_update_match(=0A-    int =
cpu_num, struct microcode_header_intel *mc_header, int sig, int pf)=0A+    =
int cpu_num, const struct microcode_header_intel *mc_header,=0A+    int =
sig, int pf)=0A {=0A     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_=
info, cpu_num);=0A =0A@@ -200,11 +232,11 @@ static int microcode_sanity_che=
ck(void *=0A  * return 1 - found update=0A  * return < 0 - error=0A  =
*/=0A-static int get_matching_microcode(void *mc, int cpu)=0A+static int =
get_matching_microcode(const void *mc, int cpu)=0A {=0A     struct =
ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);=0A-    struct =
microcode_header_intel *mc_header =3D mc;=0A-    struct extended_sigtable =
*ext_header;=0A+    const struct microcode_header_intel *mc_header =3D =
mc;=0A+    const struct extended_sigtable *ext_header;=0A     unsigned =
long total_size =3D get_totalsize(mc_header);=0A     int ext_sigcount, =
i;=0A     struct extended_signature *ext_sig;=0A@@ -229,6 +261,8 @@ static =
int get_matching_microcode(void *=0A     }=0A     return 0;=0A  find:=0A+  =
  if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >=3D mc_header->rev =
)=0A+        return 0;=0A     pr_debug("microcode: CPU%d found a matching =
microcode update with"=0A              " version 0x%x (current=3D0x%x)\n",=
=0A              cpu, mc_header->rev, uci->cpu_sig.rev);=0A@@ -239,10 =
+273,8 @@ static int get_matching_microcode(void *=0A         return =
-ENOMEM;=0A     }=0A =0A-    /* free previous update file */=0A-    =
xfree(uci->mc.mc_intel);=0A-=0A     memcpy(new_mc, mc, total_size);=0A+    =
xfree(uci->mc.mc_intel);=0A     uci->mc.mc_intel =3D new_mc;=0A     return =
1;=0A }=0A@@ -361,12 +393,9 @@ static int cpu_request_microcode(int cpu=0A =
    return error;=0A }=0A =0A-static int microcode_resume_match(int cpu, =
struct cpu_signature *nsig)=0A+static int microcode_resume_match(int cpu, =
const void *mc)=0A {=0A-    struct ucode_cpu_info *uci =3D &per_cpu(ucode_c=
pu_info, cpu);=0A-=0A-    return (sigmatch(nsig->sig, uci->cpu_sig.sig, =
nsig->pf, uci->cpu_sig.pf) &&=0A-            (uci->cpu_sig.rev > nsig->rev)=
);=0A+    return get_matching_microcode(mc, cpu);=0A }=0A =0A static const =
struct microcode_ops microcode_intel_ops =3D {=0A@@ -382,4 +411,4 @@ =
static __init int microcode_init_intel(v=0A         microcode_ops =3D =
&microcode_intel_ops;=0A     return 0;=0A }=0A-__initcall(microcode_init_in=
tel);=0A+presmp_initcall(microcode_init_intel);=0A--- a/xen/include/asm-x86=
/microcode.h=0A+++ b/xen/include/asm-x86/microcode.h=0A@@ -7,74 +7,12 @@ =
struct cpu_signature;=0A struct ucode_cpu_info;=0A =0A struct microcode_ops=
 {=0A-    int (*microcode_resume_match)(int cpu, struct cpu_signature =
*nsig);=0A+    int (*microcode_resume_match)(int cpu, const void *mc);=0A  =
   int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);=0A =
    int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);=0A     =
int (*apply_microcode)(int cpu);=0A };=0A =0A-struct microcode_header_intel=
 {=0A-    unsigned int hdrver;=0A-    unsigned int rev;=0A-    unsigned =
int date;=0A-    unsigned int sig;=0A-    unsigned int cksum;=0A-    =
unsigned int ldrver;=0A-    unsigned int pf;=0A-    unsigned int =
datasize;=0A-    unsigned int totalsize;=0A-    unsigned int reserved[3];=
=0A-};=0A-=0A-struct microcode_intel {=0A-    struct microcode_header_intel=
 hdr;=0A-    unsigned int bits[0];=0A-};=0A-=0A-/* microcode format is =
extended from prescott processors */=0A-struct extended_signature {=0A-    =
unsigned int sig;=0A-    unsigned int pf;=0A-    unsigned int cksum;=0A-};=
=0A-=0A-struct extended_sigtable {=0A-    unsigned int count;=0A-    =
unsigned int cksum;=0A-    unsigned int reserved[3];=0A-    struct =
extended_signature sigs[0];=0A-};=0A-=0A-struct equiv_cpu_entry {=0A-    =
uint32_t installed_cpu;=0A-    uint32_t fixed_errata_mask;=0A-    uint32_t =
fixed_errata_compare;=0A-    uint16_t equiv_cpu;=0A-    uint16_t =
reserved;=0A-} __attribute__((packed));=0A-=0A-struct microcode_header_amd =
{=0A-    uint32_t data_code;=0A-    uint32_t patch_id;=0A-    uint8_t  =
mc_patch_data_id[2];=0A-    uint8_t  mc_patch_data_len;=0A-    uint8_t  =
init_flag;=0A-    uint32_t mc_patch_data_checksum;=0A-    uint32_t =
nb_dev_id;=0A-    uint32_t sb_dev_id;=0A-    uint16_t processor_rev_id;=0A-=
    uint8_t  nb_rev_id;=0A-    uint8_t  sb_rev_id;=0A-    uint8_t  =
bios_api_rev;=0A-    uint8_t  reserved1[3];=0A-    uint32_t match_reg[8];=
=0A-} __attribute__((packed));=0A-=0A-struct microcode_amd {=0A-    struct =
microcode_header_amd hdr;=0A-    unsigned int mpb[0];=0A-};=0A-=0A struct =
cpu_signature {=0A     unsigned int sig;=0A     unsigned int pf;=0A
--=__Part8EA11B27.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part8EA11B27.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:27:27 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:27:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVn07-0005K3-W2; Wed, 30 Nov 2011 16:27:15 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVn05-0005Iu-CH
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:27:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1322670393!5272133!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20687 invoked from network); 30 Nov 2011 16:26:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:26:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:26:33 +0000
Message-Id: <4ED6674702000078000646B8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:26:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part8EA11B27.0__="
Subject: [Xen-devel] [PATCH 1/2] x86: consolidate microcode loading code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part8EA11B27.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- memory was leaked on a CPU offline/online cycle (including S3)
- memory was leaked on AMD systems when microcode_update() ran a 2nd
  time with the same data that was used on the first run
- microcode never got restored on APs during S3 resume (or post-boot
  onlining of a CPU that was also online when microcode_update() first
  ran [in the event the prior microcode update got lost intermediately,
  which supposedly shouldn't happen]); this will still be the case when
  no other online CPU has an identical signature (which however is now
  consistent with bringing up such a CPU the very first time)
- resume was unimplemented in the AMD case
- there was a race between microcode_update_cpu() and
  microcode_resume_cpu()

This also moves vendor specific type declarations to the vendor source
file and sets the stage for boot time microcode loading (i.e. without
Dom0 involvement).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -30,9 +30,10 @@ obj-y +=3D io_apic.o
 obj-y +=3D msi.o
 obj-y +=3D ioport_emulate.o
 obj-y +=3D irq.o
-obj-y +=3D microcode.o
 obj-y +=3D microcode_amd.o
 obj-y +=3D microcode_intel.o
+# This must come after the vendor specific files.
+obj-y +=3D microcode.o
 obj-y +=3D mm.o
 obj-y +=3D mpparse.o
 obj-y +=3D nmi.o
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -22,17 +22,17 @@
  */
=20
 #include <xen/config.h>
+#include <xen/cpu.h>
 #include <xen/lib.h>
 #include <xen/kernel.h>
 #include <xen/init.h>
+#include <xen/notifier.h>
 #include <xen/sched.h>
 #include <xen/smp.h>
 #include <xen/spinlock.h>
 #include <xen/guest_access.h>
=20
-#include <asm/current.h>
 #include <asm/msr.h>
-#include <asm/uaccess.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
=20
@@ -69,30 +69,50 @@ int microcode_resume_cpu(int cpu)
     int err;
     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
     struct cpu_signature nsig;
+    unsigned int cpu2;
=20
-    if ( !uci->mc.mc_valid )
-        return -EIO;
+    spin_lock(&microcode_mutex);
=20
-    /*
-     * Let's verify that the 'cached' ucode does belong
-     * to this cpu (a bit of paranoia):
-     */
-    err =3D microcode_ops->collect_cpu_info(cpu, &nsig);
+    err =3D microcode_ops->collect_cpu_info(cpu, &uci->cpu_sig);
     if ( err )
     {
-        microcode_fini_cpu(cpu);
+        __microcode_fini_cpu(cpu);
+        spin_unlock(&microcode_mutex);
         return err;
     }
=20
-    if ( microcode_ops->microcode_resume_match(cpu, &nsig) )
+    if ( uci->mc.mc_valid )
     {
-        return microcode_ops->apply_microcode(cpu);
+        err =3D microcode_ops->microcode_resume_match(cpu, uci->mc.mc_vali=
d);
+        if ( err >=3D 0 )
+        {
+            if ( err )
+                err =3D microcode_ops->apply_microcode(cpu);
+            spin_unlock(&microcode_mutex);
+            return err;
+        }
     }
-    else
+
+    nsig =3D uci->cpu_sig;
+    __microcode_fini_cpu(cpu);
+    uci->cpu_sig =3D nsig;
+
+    err =3D -EIO;
+    for_each_online_cpu ( cpu2 )
     {
-        microcode_fini_cpu(cpu);
-        return -EIO;
+        uci =3D &per_cpu(ucode_cpu_info, cpu2);
+        if ( uci->mc.mc_valid &&
+             microcode_ops->microcode_resume_match(cpu, uci->mc.mc_valid) =
> 0 )
+        {
+            err =3D microcode_ops->apply_microcode(cpu);
+            break;
+        }
     }
+
+    __microcode_fini_cpu(cpu);
+    spin_unlock(&microcode_mutex);
+
+    return err;
 }
=20
 static int microcode_update_cpu(const void *buf, size_t size)
@@ -162,3 +182,30 @@ int microcode_update(XEN_GUEST_HANDLE(co
=20
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, =
info);
 }
+
+static int microcode_percpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu =3D (unsigned long)hcpu;
+
+    switch ( action )
+    {
+    case CPU_DEAD:
+        microcode_fini_cpu(cpu);
+        break;
+    }
+
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block microcode_percpu_nfb =3D {
+    .notifier_call =3D microcode_percpu_callback,
+};
+
+static int __init microcode_presmp_init(void)
+{
+    if ( microcode_ops )
+        register_cpu_notifier(&microcode_percpu_nfb);
+    return 0;
+}
+presmp_initcall(microcode_presmp_init);
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -23,27 +23,53 @@
 #include <xen/spinlock.h>
=20
 #include <asm/msr.h>
-#include <asm/uaccess.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
=20
 #define pr_debug(x...) ((void)0)
=20
+struct equiv_cpu_entry {
+    uint32_t installed_cpu;
+    uint32_t fixed_errata_mask;
+    uint32_t fixed_errata_compare;
+    uint16_t equiv_cpu;
+    uint16_t reserved;
+} __attribute__((packed));
+
+struct microcode_header_amd {
+    uint32_t data_code;
+    uint32_t patch_id;
+    uint8_t  mc_patch_data_id[2];
+    uint8_t  mc_patch_data_len;
+    uint8_t  init_flag;
+    uint32_t mc_patch_data_checksum;
+    uint32_t nb_dev_id;
+    uint32_t sb_dev_id;
+    uint16_t processor_rev_id;
+    uint8_t  nb_rev_id;
+    uint8_t  sb_rev_id;
+    uint8_t  bios_api_rev;
+    uint8_t  reserved1[3];
+    uint32_t match_reg[8];
+} __attribute__((packed));
+
 #define UCODE_MAGIC                0x00414d44
 #define UCODE_EQUIV_CPU_TABLE_TYPE 0x00000000
 #define UCODE_UCODE_TYPE           0x00000001
=20
 #define UCODE_MAX_SIZE          (2048)
-#define DEFAULT_UCODE_DATASIZE  (896)
 #define MC_HEADER_SIZE          (sizeof(struct microcode_header_amd))
-#define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + MC_HEADER_SIZE)
-#define DWSIZE                  (sizeof(uint32_t))
+
+struct microcode_amd {
+    struct microcode_header_amd hdr;
+    unsigned int mpb[(UCODE_MAX_SIZE - MC_HEADER_SIZE) / 4];
+    unsigned int equiv_cpu_table_size;
+    struct equiv_cpu_entry equiv_cpu_table[];
+};
=20
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
=20
-struct equiv_cpu_entry *equiv_cpu_table;
-
 static int collect_cpu_info(int cpu, struct cpu_signature *csig)
 {
     struct cpuinfo_x86 *c =3D &cpu_data[cpu];
@@ -65,10 +91,11 @@ static int collect_cpu_info(int cpu, str
     return 0;
 }
=20
-static int microcode_fits(void *mc, int cpu)
+static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
-    struct microcode_header_amd *mc_header =3D mc;
+    const struct microcode_header_amd *mc_header =3D &mc_amd->hdr;
+    const struct equiv_cpu_entry *equiv_cpu_table =3D mc_amd->equiv_cpu_ta=
ble;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id =3D 0x0;
     unsigned int i;
@@ -99,7 +126,7 @@ static int microcode_fits(void *mc, int=20
     }
=20
     if ( mc_header->patch_id <=3D uci->cpu_sig.rev )
-        return -EINVAL;
+        return 0;
=20
     printk(KERN_DEBUG "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=3D0x%x)\n",
@@ -186,17 +213,15 @@ static int get_next_ucode_from_buffer_am
     return 0;
 }
=20
-static int install_equiv_cpu_table(const void *buf, uint32_t size,
-                                   unsigned long *offset)
+static int install_equiv_cpu_table(
+    struct microcode_amd *mc_amd,
+    const uint32_t *buf_pos,
+    unsigned long *offset)
 {
-    const uint32_t *buf_pos =3D buf;
-    unsigned long off;
-
-    off =3D *offset;
-    *offset =3D 0;
+    uint32_t size =3D buf_pos[2];
=20
     /* No more data */
-    if ( off >=3D size )
+    if ( size + 12 >=3D *offset )
         return -EINVAL;
=20
     if ( buf_pos[1] !=3D UCODE_EQUIV_CPU_TABLE_TYPE )
@@ -213,15 +238,8 @@ static int install_equiv_cpu_table(const
         return -EINVAL;
     }
=20
-    equiv_cpu_table =3D xmalloc_bytes(size);
-    if ( equiv_cpu_table =3D=3D NULL )
-    {
-        printk(KERN_ERR "microcode: error, can't allocate "
-               "memory for equiv CPU table\n");
-        return -ENOMEM;
-    }
-
-    memcpy(equiv_cpu_table, (const void *)&buf_pos[3], size);
+    memcpy(mc_amd->equiv_cpu_table, &buf_pos[3], size);
+    mc_amd->equiv_cpu_table_size =3D size;
=20
     *offset =3D size + 12;	/* add header length */
=20
@@ -231,11 +249,11 @@ static int install_equiv_cpu_table(const
 static int cpu_request_microcode(int cpu, const void *buf, size_t size)
 {
     const uint32_t *buf_pos;
-    unsigned long offset =3D 0;
+    struct microcode_amd *mc_amd, *mc_old;
+    unsigned long offset =3D size;
     int error =3D 0;
     int ret;
     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
-    void *mc;
=20
     /* We should bind the task to the CPU */
     BUG_ON(cpu !=3D raw_smp_processor_id());
@@ -249,59 +267,85 @@ static int cpu_request_microcode(int cpu
         return -EINVAL;
     }
=20
-    error =3D install_equiv_cpu_table(buf, (uint32_t)(buf_pos[2]), =
&offset);
-    if ( error )
+    mc_amd =3D xmalloc_bytes(sizeof(*mc_amd) + buf_pos[2]);
+    if ( !mc_amd )
     {
-        printk(KERN_ERR "microcode: installing equivalent cpu table =
failed\n");
-        return -EINVAL;
+        printk(KERN_ERR "microcode: error! "
+               "Can not allocate memory for microcode patch\n");
+        return -ENOMEM;
     }
=20
-    mc =3D xmalloc_bytes(UCODE_MAX_SIZE);
-    if ( mc =3D=3D NULL )
+    error =3D install_equiv_cpu_table(mc_amd, buf, &offset);
+    if ( error )
     {
-        printk(KERN_ERR "microcode: error! "
-               "Can not allocate memory for microcode patch\n");
-        error =3D -ENOMEM;
-        goto out;
+        xfree(mc_amd);
+        printk(KERN_ERR "microcode: installing equivalent cpu table =
failed\n");
+        return -EINVAL;
     }
=20
+    mc_old =3D uci->mc.mc_amd;
     /* implicitely validates uci->mc.mc_valid */
-    uci->mc.mc_amd =3D mc;
+    uci->mc.mc_amd =3D mc_amd;
=20
     /*
      * It's possible the data file has multiple matching ucode,
      * lets keep searching till the latest version
      */
-    while ( (ret =3D get_next_ucode_from_buffer_amd(mc, buf, size, =
&offset)) =3D=3D 0)
+    while ( (ret =3D get_next_ucode_from_buffer_amd(&mc_amd->hdr, buf, =
size,
+                                                  &offset)) =3D=3D 0 )
     {
-        error =3D microcode_fits(mc, cpu);
+        error =3D microcode_fits(mc_amd, cpu);
         if (error <=3D 0)
             continue;
=20
         error =3D apply_microcode(cpu);
         if (error =3D=3D 0)
+        {
+            error =3D 1;
             break;
+        }
     }
=20
+    if ( ret < 0 )
+        error =3D ret;
+
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error) {
-        xfree(mc);
-        mc =3D NULL;
-    }
-    uci->mc.mc_amd =3D mc;
-
-out:
-    xfree(equiv_cpu_table);
-    equiv_cpu_table =3D NULL;
+    if (error =3D=3D 1)
+    {
+        xfree(mc_old);
+        return 0;
+    }
+    xfree(mc_amd);
+    uci->mc.mc_amd =3D mc_old;
=20
     return error;
 }
=20
-static int microcode_resume_match(int cpu, struct cpu_signature *nsig)
+static int microcode_resume_match(int cpu, const void *mc)
 {
-    return 0;
+    struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
+    struct microcode_amd *mc_amd =3D uci->mc.mc_amd;
+    const struct microcode_amd *src =3D mc;
+    int res =3D microcode_fits(src, cpu);
+
+    if ( res <=3D 0 )
+        return res;
+
+    if ( src !=3D mc_amd )
+    {
+        xfree(mc_amd);
+        mc_amd =3D xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size)=
;
+        uci->mc.mc_amd =3D mc_amd;
+        if ( !mc_amd )
+            return -ENOMEM;
+        memcpy(mc_amd, src, UCODE_MAX_SIZE);
+        memcpy(mc_amd->equiv_cpu_table, src->equiv_cpu_table,
+               src->equiv_cpu_table_size);
+    }
+
+    return 1;
 }
=20
 static const struct microcode_ops microcode_amd_ops =3D {
@@ -317,4 +361,4 @@ static __init int microcode_init_amd(voi
         microcode_ops =3D &microcode_amd_ops;
     return 0;
 }
-__initcall(microcode_init_amd);
+presmp_initcall(microcode_init_amd);
--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -30,12 +30,43 @@
 #include <xen/spinlock.h>
=20
 #include <asm/msr.h>
-#include <asm/uaccess.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
=20
 #define pr_debug(x...) ((void)0)
=20
+struct microcode_header_intel {
+    unsigned int hdrver;
+    unsigned int rev;
+    unsigned int date;
+    unsigned int sig;
+    unsigned int cksum;
+    unsigned int ldrver;
+    unsigned int pf;
+    unsigned int datasize;
+    unsigned int totalsize;
+    unsigned int reserved[3];
+};
+
+struct microcode_intel {
+    struct microcode_header_intel hdr;
+    unsigned int bits[0];
+};
+
+/* microcode format is extended from prescott processors */
+struct extended_signature {
+    unsigned int sig;
+    unsigned int pf;
+    unsigned int cksum;
+};
+
+struct extended_sigtable {
+    unsigned int count;
+    unsigned int cksum;
+    unsigned int reserved[3];
+    struct extended_signature sigs[0];
+};
+
 #define DEFAULT_UCODE_DATASIZE  (2000)
 #define MC_HEADER_SIZE          (sizeof(struct microcode_header_intel))
 #define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + MC_HEADER_SIZE)
@@ -98,7 +129,8 @@ static int collect_cpu_info(int cpu_num,
 }
=20
 static inline int microcode_update_match(
-    int cpu_num, struct microcode_header_intel *mc_header, int sig, int =
pf)
+    int cpu_num, const struct microcode_header_intel *mc_header,
+    int sig, int pf)
 {
     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu_num);
=20
@@ -200,11 +232,11 @@ static int microcode_sanity_check(void *
  * return 1 - found update
  * return < 0 - error
  */
-static int get_matching_microcode(void *mc, int cpu)
+static int get_matching_microcode(const void *mc, int cpu)
 {
     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
-    struct microcode_header_intel *mc_header =3D mc;
-    struct extended_sigtable *ext_header;
+    const struct microcode_header_intel *mc_header =3D mc;
+    const struct extended_sigtable *ext_header;
     unsigned long total_size =3D get_totalsize(mc_header);
     int ext_sigcount, i;
     struct extended_signature *ext_sig;
@@ -229,6 +261,8 @@ static int get_matching_microcode(void *
     }
     return 0;
  find:
+    if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >=3D mc_header->rev=
 )
+        return 0;
     pr_debug("microcode: CPU%d found a matching microcode update with"
              " version 0x%x (current=3D0x%x)\n",
              cpu, mc_header->rev, uci->cpu_sig.rev);
@@ -239,10 +273,8 @@ static int get_matching_microcode(void *
         return -ENOMEM;
     }
=20
-    /* free previous update file */
-    xfree(uci->mc.mc_intel);
-
     memcpy(new_mc, mc, total_size);
+    xfree(uci->mc.mc_intel);
     uci->mc.mc_intel =3D new_mc;
     return 1;
 }
@@ -361,12 +393,9 @@ static int cpu_request_microcode(int cpu
     return error;
 }
=20
-static int microcode_resume_match(int cpu, struct cpu_signature *nsig)
+static int microcode_resume_match(int cpu, const void *mc)
 {
-    struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);
-
-    return (sigmatch(nsig->sig, uci->cpu_sig.sig, nsig->pf, uci->cpu_sig.p=
f) &&
-            (uci->cpu_sig.rev > nsig->rev));
+    return get_matching_microcode(mc, cpu);
 }
=20
 static const struct microcode_ops microcode_intel_ops =3D {
@@ -382,4 +411,4 @@ static __init int microcode_init_intel(v
         microcode_ops =3D &microcode_intel_ops;
     return 0;
 }
-__initcall(microcode_init_intel);
+presmp_initcall(microcode_init_intel);
--- a/xen/include/asm-x86/microcode.h
+++ b/xen/include/asm-x86/microcode.h
@@ -7,74 +7,12 @@ struct cpu_signature;
 struct ucode_cpu_info;
=20
 struct microcode_ops {
-    int (*microcode_resume_match)(int cpu, struct cpu_signature *nsig);
+    int (*microcode_resume_match)(int cpu, const void *mc);
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
 };
=20
-struct microcode_header_intel {
-    unsigned int hdrver;
-    unsigned int rev;
-    unsigned int date;
-    unsigned int sig;
-    unsigned int cksum;
-    unsigned int ldrver;
-    unsigned int pf;
-    unsigned int datasize;
-    unsigned int totalsize;
-    unsigned int reserved[3];
-};
-
-struct microcode_intel {
-    struct microcode_header_intel hdr;
-    unsigned int bits[0];
-};
-
-/* microcode format is extended from prescott processors */
-struct extended_signature {
-    unsigned int sig;
-    unsigned int pf;
-    unsigned int cksum;
-};
-
-struct extended_sigtable {
-    unsigned int count;
-    unsigned int cksum;
-    unsigned int reserved[3];
-    struct extended_signature sigs[0];
-};
-
-struct equiv_cpu_entry {
-    uint32_t installed_cpu;
-    uint32_t fixed_errata_mask;
-    uint32_t fixed_errata_compare;
-    uint16_t equiv_cpu;
-    uint16_t reserved;
-} __attribute__((packed));
-
-struct microcode_header_amd {
-    uint32_t data_code;
-    uint32_t patch_id;
-    uint8_t  mc_patch_data_id[2];
-    uint8_t  mc_patch_data_len;
-    uint8_t  init_flag;
-    uint32_t mc_patch_data_checksum;
-    uint32_t nb_dev_id;
-    uint32_t sb_dev_id;
-    uint16_t processor_rev_id;
-    uint8_t  nb_rev_id;
-    uint8_t  sb_rev_id;
-    uint8_t  bios_api_rev;
-    uint8_t  reserved1[3];
-    uint32_t match_reg[8];
-} __attribute__((packed));
-
-struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[0];
-};
-
 struct cpu_signature {
     unsigned int sig;
     unsigned int pf;



--=__Part8EA11B27.0__=
Content-Type: text/plain; name="x86-ucode-consolidation.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ucode-consolidation.patch"

x86: consolidate microcode loading code=0A=0A- memory was leaked on a CPU =
offline/online cycle (including S3)=0A- memory was leaked on AMD systems =
when microcode_update() ran a 2nd=0A  time with the same data that was =
used on the first run=0A- microcode never got restored on APs during S3 =
resume (or post-boot=0A  onlining of a CPU that was also online when =
microcode_update() first=0A  ran [in the event the prior microcode update =
got lost intermediately,=0A  which supposedly shouldn't happen]); this =
will still be the case when=0A  no other online CPU has an identical =
signature (which however is now=0A  consistent with bringing up such a CPU =
the very first time)=0A- resume was unimplemented in the AMD case=0A- =
there was a race between microcode_update_cpu() and=0A  microcode_resume_cp=
u()=0A=0AThis also moves vendor specific type declarations to the vendor =
source=0Afile and sets the stage for boot time microcode loading (i.e. =
without=0ADom0 involvement).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse=
.com>=0A=0A--- a/xen/arch/x86/Makefile=0A+++ b/xen/arch/x86/Makefile=0A@@ =
-30,9 +30,10 @@ obj-y +=3D io_apic.o=0A obj-y +=3D msi.o=0A obj-y +=3D =
ioport_emulate.o=0A obj-y +=3D irq.o=0A-obj-y +=3D microcode.o=0A obj-y =
+=3D microcode_amd.o=0A obj-y +=3D microcode_intel.o=0A+# This must come =
after the vendor specific files.=0A+obj-y +=3D microcode.o=0A obj-y +=3D =
mm.o=0A obj-y +=3D mpparse.o=0A obj-y +=3D nmi.o=0A--- a/xen/arch/x86/micro=
code.c=0A+++ b/xen/arch/x86/microcode.c=0A@@ -22,17 +22,17 @@=0A  */=0A =
=0A #include <xen/config.h>=0A+#include <xen/cpu.h>=0A #include <xen/lib.h>=
=0A #include <xen/kernel.h>=0A #include <xen/init.h>=0A+#include <xen/notif=
ier.h>=0A #include <xen/sched.h>=0A #include <xen/smp.h>=0A #include =
<xen/spinlock.h>=0A #include <xen/guest_access.h>=0A =0A-#include =
<asm/current.h>=0A #include <asm/msr.h>=0A-#include <asm/uaccess.h>=0A =
#include <asm/processor.h>=0A #include <asm/microcode.h>=0A =0A@@ -69,30 =
+69,50 @@ int microcode_resume_cpu(int cpu)=0A     int err;=0A     struct =
ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);=0A     struct =
cpu_signature nsig;=0A+    unsigned int cpu2;=0A =0A-    if ( !uci->mc.mc_v=
alid )=0A-        return -EIO;=0A+    spin_lock(&microcode_mutex);=0A =0A- =
   /*=0A-     * Let's verify that the 'cached' ucode does belong=0A-     * =
to this cpu (a bit of paranoia):=0A-     */=0A-    err =3D microcode_ops->c=
ollect_cpu_info(cpu, &nsig);=0A+    err =3D microcode_ops->collect_cpu_info=
(cpu, &uci->cpu_sig);=0A     if ( err )=0A     {=0A-        microcode_fini_=
cpu(cpu);=0A+        __microcode_fini_cpu(cpu);=0A+        spin_unlock(&mic=
rocode_mutex);=0A         return err;=0A     }=0A =0A-    if ( microcode_op=
s->microcode_resume_match(cpu, &nsig) )=0A+    if ( uci->mc.mc_valid )=0A  =
   {=0A-        return microcode_ops->apply_microcode(cpu);=0A+        err =
=3D microcode_ops->microcode_resume_match(cpu, uci->mc.mc_valid);=0A+      =
  if ( err >=3D 0 )=0A+        {=0A+            if ( err )=0A+             =
   err =3D microcode_ops->apply_microcode(cpu);=0A+            spin_unlock(=
&microcode_mutex);=0A+            return err;=0A+        }=0A     }=0A-    =
else=0A+=0A+    nsig =3D uci->cpu_sig;=0A+    __microcode_fini_cpu(cpu);=0A=
+    uci->cpu_sig =3D nsig;=0A+=0A+    err =3D -EIO;=0A+    for_each_online=
_cpu ( cpu2 )=0A     {=0A-        microcode_fini_cpu(cpu);=0A-        =
return -EIO;=0A+        uci =3D &per_cpu(ucode_cpu_info, cpu2);=0A+        =
if ( uci->mc.mc_valid &&=0A+             microcode_ops->microcode_resume_ma=
tch(cpu, uci->mc.mc_valid) > 0 )=0A+        {=0A+            err =3D =
microcode_ops->apply_microcode(cpu);=0A+            break;=0A+        }=0A =
    }=0A+=0A+    __microcode_fini_cpu(cpu);=0A+    spin_unlock(&microcode_m=
utex);=0A+=0A+    return err;=0A }=0A =0A static int microcode_update_cpu(c=
onst void *buf, size_t size)=0A@@ -162,3 +182,30 @@ int microcode_update(XE=
N_GUEST_HANDLE(co=0A =0A     return continue_hypercall_on_cpu(info->cpu, =
do_microcode_update, info);=0A }=0A+=0A+static int microcode_percpu_callbac=
k(=0A+    struct notifier_block *nfb, unsigned long action, void *hcpu)=0A+=
{=0A+    unsigned int cpu =3D (unsigned long)hcpu;=0A+=0A+    switch ( =
action )=0A+    {=0A+    case CPU_DEAD:=0A+        microcode_fini_cpu(cpu);=
=0A+        break;=0A+    }=0A+=0A+    return NOTIFY_DONE;=0A+}=0A+=0A+stat=
ic struct notifier_block microcode_percpu_nfb =3D {=0A+    .notifier_call =
=3D microcode_percpu_callback,=0A+};=0A+=0A+static int __init microcode_pre=
smp_init(void)=0A+{=0A+    if ( microcode_ops )=0A+        register_cpu_not=
ifier(&microcode_percpu_nfb);=0A+    return 0;=0A+}=0A+presmp_initcall(micr=
ocode_presmp_init);=0A--- a/xen/arch/x86/microcode_amd.c=0A+++ b/xen/arch/x=
86/microcode_amd.c=0A@@ -23,27 +23,53 @@=0A #include <xen/spinlock.h>=0A =
=0A #include <asm/msr.h>=0A-#include <asm/uaccess.h>=0A #include <asm/proce=
ssor.h>=0A #include <asm/microcode.h>=0A =0A #define pr_debug(x...) =
((void)0)=0A =0A+struct equiv_cpu_entry {=0A+    uint32_t installed_cpu;=0A=
+    uint32_t fixed_errata_mask;=0A+    uint32_t fixed_errata_compare;=0A+ =
   uint16_t equiv_cpu;=0A+    uint16_t reserved;=0A+} __attribute__((packed=
));=0A+=0A+struct microcode_header_amd {=0A+    uint32_t data_code;=0A+    =
uint32_t patch_id;=0A+    uint8_t  mc_patch_data_id[2];=0A+    uint8_t  =
mc_patch_data_len;=0A+    uint8_t  init_flag;=0A+    uint32_t mc_patch_data=
_checksum;=0A+    uint32_t nb_dev_id;=0A+    uint32_t sb_dev_id;=0A+    =
uint16_t processor_rev_id;=0A+    uint8_t  nb_rev_id;=0A+    uint8_t  =
sb_rev_id;=0A+    uint8_t  bios_api_rev;=0A+    uint8_t  reserved1[3];=0A+ =
   uint32_t match_reg[8];=0A+} __attribute__((packed));=0A+=0A #define =
UCODE_MAGIC                0x00414d44=0A #define UCODE_EQUIV_CPU_TABLE_TYPE=
 0x00000000=0A #define UCODE_UCODE_TYPE           0x00000001=0A =0A =
#define UCODE_MAX_SIZE          (2048)=0A-#define DEFAULT_UCODE_DATASIZE  =
(896)=0A #define MC_HEADER_SIZE          (sizeof(struct microcode_header_am=
d))=0A-#define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + MC_HEADER_=
SIZE)=0A-#define DWSIZE                  (sizeof(uint32_t))=0A+=0A+struct =
microcode_amd {=0A+    struct microcode_header_amd hdr;=0A+    unsigned =
int mpb[(UCODE_MAX_SIZE - MC_HEADER_SIZE) / 4];=0A+    unsigned int =
equiv_cpu_table_size;=0A+    struct equiv_cpu_entry equiv_cpu_table[];=0A+}=
;=0A =0A /* serialize access to the physical write */=0A static DEFINE_SPIN=
LOCK(microcode_update_lock);=0A =0A-struct equiv_cpu_entry *equiv_cpu_table=
;=0A-=0A static int collect_cpu_info(int cpu, struct cpu_signature =
*csig)=0A {=0A     struct cpuinfo_x86 *c =3D &cpu_data[cpu];=0A@@ -65,10 =
+91,11 @@ static int collect_cpu_info(int cpu, str=0A     return 0;=0A =
}=0A =0A-static int microcode_fits(void *mc, int cpu)=0A+static int =
microcode_fits(const struct microcode_amd *mc_amd, int cpu)=0A {=0A     =
struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);=0A-    =
struct microcode_header_amd *mc_header =3D mc;=0A+    const struct =
microcode_header_amd *mc_header =3D &mc_amd->hdr;=0A+    const struct =
equiv_cpu_entry *equiv_cpu_table =3D mc_amd->equiv_cpu_table;=0A     =
unsigned int current_cpu_id;=0A     unsigned int equiv_cpu_id =3D 0x0;=0A  =
   unsigned int i;=0A@@ -99,7 +126,7 @@ static int microcode_fits(void =
*mc, int =0A     }=0A =0A     if ( mc_header->patch_id <=3D uci->cpu_sig.re=
v )=0A-        return -EINVAL;=0A+        return 0;=0A =0A     printk(KERN_=
DEBUG "microcode: CPU%d found a matching microcode "=0A            "update =
with version 0x%x (current=3D0x%x)\n",=0A@@ -186,17 +213,15 @@ static int =
get_next_ucode_from_buffer_am=0A     return 0;=0A }=0A =0A-static int =
install_equiv_cpu_table(const void *buf, uint32_t size,=0A-                =
                   unsigned long *offset)=0A+static int install_equiv_cpu_t=
able(=0A+    struct microcode_amd *mc_amd,=0A+    const uint32_t =
*buf_pos,=0A+    unsigned long *offset)=0A {=0A-    const uint32_t =
*buf_pos =3D buf;=0A-    unsigned long off;=0A-=0A-    off =3D *offset;=0A-=
    *offset =3D 0;=0A+    uint32_t size =3D buf_pos[2];=0A =0A     /* No =
more data */=0A-    if ( off >=3D size )=0A+    if ( size + 12 >=3D =
*offset )=0A         return -EINVAL;=0A =0A     if ( buf_pos[1] !=3D =
UCODE_EQUIV_CPU_TABLE_TYPE )=0A@@ -213,15 +238,8 @@ static int install_equi=
v_cpu_table(const=0A         return -EINVAL;=0A     }=0A =0A-    equiv_cpu_=
table =3D xmalloc_bytes(size);=0A-    if ( equiv_cpu_table =3D=3D NULL =
)=0A-    {=0A-        printk(KERN_ERR "microcode: error, can't allocate =
"=0A-               "memory for equiv CPU table\n");=0A-        return =
-ENOMEM;=0A-    }=0A-=0A-    memcpy(equiv_cpu_table, (const void *)&buf_pos=
[3], size);=0A+    memcpy(mc_amd->equiv_cpu_table, &buf_pos[3], size);=0A+ =
   mc_amd->equiv_cpu_table_size =3D size;=0A =0A     *offset =3D size + =
12;	/* add header length */=0A =0A@@ -231,11 +249,11 @@ static int =
install_equiv_cpu_table(const=0A static int cpu_request_microcode(int cpu, =
const void *buf, size_t size)=0A {=0A     const uint32_t *buf_pos;=0A-    =
unsigned long offset =3D 0;=0A+    struct microcode_amd *mc_amd, =
*mc_old;=0A+    unsigned long offset =3D size;=0A     int error =3D 0;=0A  =
   int ret;=0A     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, =
cpu);=0A-    void *mc;=0A =0A     /* We should bind the task to the CPU =
*/=0A     BUG_ON(cpu !=3D raw_smp_processor_id());=0A@@ -249,59 +267,85 @@ =
static int cpu_request_microcode(int cpu=0A         return -EINVAL;=0A     =
}=0A =0A-    error =3D install_equiv_cpu_table(buf, (uint32_t)(buf_pos[2]),=
 &offset);=0A-    if ( error )=0A+    mc_amd =3D xmalloc_bytes(sizeof(*mc_a=
md) + buf_pos[2]);=0A+    if ( !mc_amd )=0A     {=0A-        printk(KERN_ER=
R "microcode: installing equivalent cpu table failed\n");=0A-        =
return -EINVAL;=0A+        printk(KERN_ERR "microcode: error! "=0A+        =
       "Can not allocate memory for microcode patch\n");=0A+        return =
-ENOMEM;=0A     }=0A =0A-    mc =3D xmalloc_bytes(UCODE_MAX_SIZE);=0A-    =
if ( mc =3D=3D NULL )=0A+    error =3D install_equiv_cpu_table(mc_amd, =
buf, &offset);=0A+    if ( error )=0A     {=0A-        printk(KERN_ERR =
"microcode: error! "=0A-               "Can not allocate memory for =
microcode patch\n");=0A-        error =3D -ENOMEM;=0A-        goto =
out;=0A+        xfree(mc_amd);=0A+        printk(KERN_ERR "microcode: =
installing equivalent cpu table failed\n");=0A+        return -EINVAL;=0A  =
   }=0A =0A+    mc_old =3D uci->mc.mc_amd;=0A     /* implicitely validates =
uci->mc.mc_valid */=0A-    uci->mc.mc_amd =3D mc;=0A+    uci->mc.mc_amd =
=3D mc_amd;=0A =0A     /*=0A      * It's possible the data file has =
multiple matching ucode,=0A      * lets keep searching till the latest =
version=0A      */=0A-    while ( (ret =3D get_next_ucode_from_buffer_amd(m=
c, buf, size, &offset)) =3D=3D 0)=0A+    while ( (ret =3D get_next_ucode_fr=
om_buffer_amd(&mc_amd->hdr, buf, size,=0A+                                 =
                 &offset)) =3D=3D 0 )=0A     {=0A-        error =3D =
microcode_fits(mc, cpu);=0A+        error =3D microcode_fits(mc_amd, =
cpu);=0A         if (error <=3D 0)=0A             continue;=0A =0A         =
error =3D apply_microcode(cpu);=0A         if (error =3D=3D 0)=0A+        =
{=0A+            error =3D 1;=0A             break;=0A+        }=0A     =
}=0A =0A+    if ( ret < 0 )=0A+        error =3D ret;=0A+=0A     /* On =
success keep the microcode patch for=0A      * re-apply on resume.=0A      =
*/=0A-    if (error) {=0A-        xfree(mc);=0A-        mc =3D NULL;=0A-   =
 }=0A-    uci->mc.mc_amd =3D mc;=0A-=0A-out:=0A-    xfree(equiv_cpu_table);=
=0A-    equiv_cpu_table =3D NULL;=0A+    if (error =3D=3D 1)=0A+    {=0A+  =
      xfree(mc_old);=0A+        return 0;=0A+    }=0A+    xfree(mc_amd);=0A=
+    uci->mc.mc_amd =3D mc_old;=0A =0A     return error;=0A }=0A =0A-static=
 int microcode_resume_match(int cpu, struct cpu_signature *nsig)=0A+static =
int microcode_resume_match(int cpu, const void *mc)=0A {=0A-    return =
0;=0A+    struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, =
cpu);=0A+    struct microcode_amd *mc_amd =3D uci->mc.mc_amd;=0A+    const =
struct microcode_amd *src =3D mc;=0A+    int res =3D microcode_fits(src, =
cpu);=0A+=0A+    if ( res <=3D 0 )=0A+        return res;=0A+=0A+    if ( =
src !=3D mc_amd )=0A+    {=0A+        xfree(mc_amd);=0A+        mc_amd =3D =
xmalloc_bytes(sizeof(*src) + src->equiv_cpu_table_size);=0A+        =
uci->mc.mc_amd =3D mc_amd;=0A+        if ( !mc_amd )=0A+            return =
-ENOMEM;=0A+        memcpy(mc_amd, src, UCODE_MAX_SIZE);=0A+        =
memcpy(mc_amd->equiv_cpu_table, src->equiv_cpu_table,=0A+               =
src->equiv_cpu_table_size);=0A+    }=0A+=0A+    return 1;=0A }=0A =0A =
static const struct microcode_ops microcode_amd_ops =3D {=0A@@ -317,4 =
+361,4 @@ static __init int microcode_init_amd(voi=0A         microcode_ops=
 =3D &microcode_amd_ops;=0A     return 0;=0A }=0A-__initcall(microcode_init=
_amd);=0A+presmp_initcall(microcode_init_amd);=0A--- a/xen/arch/x86/microco=
de_intel.c=0A+++ b/xen/arch/x86/microcode_intel.c=0A@@ -30,12 +30,43 @@=0A =
#include <xen/spinlock.h>=0A =0A #include <asm/msr.h>=0A-#include =
<asm/uaccess.h>=0A #include <asm/processor.h>=0A #include <asm/microcode.h>=
=0A =0A #define pr_debug(x...) ((void)0)=0A =0A+struct microcode_header_int=
el {=0A+    unsigned int hdrver;=0A+    unsigned int rev;=0A+    unsigned =
int date;=0A+    unsigned int sig;=0A+    unsigned int cksum;=0A+    =
unsigned int ldrver;=0A+    unsigned int pf;=0A+    unsigned int =
datasize;=0A+    unsigned int totalsize;=0A+    unsigned int reserved[3];=
=0A+};=0A+=0A+struct microcode_intel {=0A+    struct microcode_header_intel=
 hdr;=0A+    unsigned int bits[0];=0A+};=0A+=0A+/* microcode format is =
extended from prescott processors */=0A+struct extended_signature {=0A+    =
unsigned int sig;=0A+    unsigned int pf;=0A+    unsigned int cksum;=0A+};=
=0A+=0A+struct extended_sigtable {=0A+    unsigned int count;=0A+    =
unsigned int cksum;=0A+    unsigned int reserved[3];=0A+    struct =
extended_signature sigs[0];=0A+};=0A+=0A #define DEFAULT_UCODE_DATASIZE  =
(2000)=0A #define MC_HEADER_SIZE          (sizeof(struct microcode_header_i=
ntel))=0A #define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + =
MC_HEADER_SIZE)=0A@@ -98,7 +129,8 @@ static int collect_cpu_info(int =
cpu_num,=0A }=0A =0A static inline int microcode_update_match(=0A-    int =
cpu_num, struct microcode_header_intel *mc_header, int sig, int pf)=0A+    =
int cpu_num, const struct microcode_header_intel *mc_header,=0A+    int =
sig, int pf)=0A {=0A     struct ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_=
info, cpu_num);=0A =0A@@ -200,11 +232,11 @@ static int microcode_sanity_che=
ck(void *=0A  * return 1 - found update=0A  * return < 0 - error=0A  =
*/=0A-static int get_matching_microcode(void *mc, int cpu)=0A+static int =
get_matching_microcode(const void *mc, int cpu)=0A {=0A     struct =
ucode_cpu_info *uci =3D &per_cpu(ucode_cpu_info, cpu);=0A-    struct =
microcode_header_intel *mc_header =3D mc;=0A-    struct extended_sigtable =
*ext_header;=0A+    const struct microcode_header_intel *mc_header =3D =
mc;=0A+    const struct extended_sigtable *ext_header;=0A     unsigned =
long total_size =3D get_totalsize(mc_header);=0A     int ext_sigcount, =
i;=0A     struct extended_signature *ext_sig;=0A@@ -229,6 +261,8 @@ static =
int get_matching_microcode(void *=0A     }=0A     return 0;=0A  find:=0A+  =
  if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >=3D mc_header->rev =
)=0A+        return 0;=0A     pr_debug("microcode: CPU%d found a matching =
microcode update with"=0A              " version 0x%x (current=3D0x%x)\n",=
=0A              cpu, mc_header->rev, uci->cpu_sig.rev);=0A@@ -239,10 =
+273,8 @@ static int get_matching_microcode(void *=0A         return =
-ENOMEM;=0A     }=0A =0A-    /* free previous update file */=0A-    =
xfree(uci->mc.mc_intel);=0A-=0A     memcpy(new_mc, mc, total_size);=0A+    =
xfree(uci->mc.mc_intel);=0A     uci->mc.mc_intel =3D new_mc;=0A     return =
1;=0A }=0A@@ -361,12 +393,9 @@ static int cpu_request_microcode(int cpu=0A =
    return error;=0A }=0A =0A-static int microcode_resume_match(int cpu, =
struct cpu_signature *nsig)=0A+static int microcode_resume_match(int cpu, =
const void *mc)=0A {=0A-    struct ucode_cpu_info *uci =3D &per_cpu(ucode_c=
pu_info, cpu);=0A-=0A-    return (sigmatch(nsig->sig, uci->cpu_sig.sig, =
nsig->pf, uci->cpu_sig.pf) &&=0A-            (uci->cpu_sig.rev > nsig->rev)=
);=0A+    return get_matching_microcode(mc, cpu);=0A }=0A =0A static const =
struct microcode_ops microcode_intel_ops =3D {=0A@@ -382,4 +411,4 @@ =
static __init int microcode_init_intel(v=0A         microcode_ops =3D =
&microcode_intel_ops;=0A     return 0;=0A }=0A-__initcall(microcode_init_in=
tel);=0A+presmp_initcall(microcode_init_intel);=0A--- a/xen/include/asm-x86=
/microcode.h=0A+++ b/xen/include/asm-x86/microcode.h=0A@@ -7,74 +7,12 @@ =
struct cpu_signature;=0A struct ucode_cpu_info;=0A =0A struct microcode_ops=
 {=0A-    int (*microcode_resume_match)(int cpu, struct cpu_signature =
*nsig);=0A+    int (*microcode_resume_match)(int cpu, const void *mc);=0A  =
   int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);=0A =
    int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);=0A     =
int (*apply_microcode)(int cpu);=0A };=0A =0A-struct microcode_header_intel=
 {=0A-    unsigned int hdrver;=0A-    unsigned int rev;=0A-    unsigned =
int date;=0A-    unsigned int sig;=0A-    unsigned int cksum;=0A-    =
unsigned int ldrver;=0A-    unsigned int pf;=0A-    unsigned int =
datasize;=0A-    unsigned int totalsize;=0A-    unsigned int reserved[3];=
=0A-};=0A-=0A-struct microcode_intel {=0A-    struct microcode_header_intel=
 hdr;=0A-    unsigned int bits[0];=0A-};=0A-=0A-/* microcode format is =
extended from prescott processors */=0A-struct extended_signature {=0A-    =
unsigned int sig;=0A-    unsigned int pf;=0A-    unsigned int cksum;=0A-};=
=0A-=0A-struct extended_sigtable {=0A-    unsigned int count;=0A-    =
unsigned int cksum;=0A-    unsigned int reserved[3];=0A-    struct =
extended_signature sigs[0];=0A-};=0A-=0A-struct equiv_cpu_entry {=0A-    =
uint32_t installed_cpu;=0A-    uint32_t fixed_errata_mask;=0A-    uint32_t =
fixed_errata_compare;=0A-    uint16_t equiv_cpu;=0A-    uint16_t =
reserved;=0A-} __attribute__((packed));=0A-=0A-struct microcode_header_amd =
{=0A-    uint32_t data_code;=0A-    uint32_t patch_id;=0A-    uint8_t  =
mc_patch_data_id[2];=0A-    uint8_t  mc_patch_data_len;=0A-    uint8_t  =
init_flag;=0A-    uint32_t mc_patch_data_checksum;=0A-    uint32_t =
nb_dev_id;=0A-    uint32_t sb_dev_id;=0A-    uint16_t processor_rev_id;=0A-=
    uint8_t  nb_rev_id;=0A-    uint8_t  sb_rev_id;=0A-    uint8_t  =
bios_api_rev;=0A-    uint8_t  reserved1[3];=0A-    uint32_t match_reg[8];=
=0A-} __attribute__((packed));=0A-=0A-struct microcode_amd {=0A-    struct =
microcode_header_amd hdr;=0A-    unsigned int mpb[0];=0A-};=0A-=0A struct =
cpu_signature {=0A     unsigned int sig;=0A     unsigned int pf;=0A
--=__Part8EA11B27.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__Part8EA11B27.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:28:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:28:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVn0l-0005SO-Nn; Wed, 30 Nov 2011 16:27:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVn0k-0005Qp-9P
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:27:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322670435!5321661!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26324 invoked from network); 30 Nov 2011 16:27:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:27:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:27:14 +0000
Message-Id: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:27:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE6C9734F.0__="
Subject: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time (pre-Dom0)
	loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE6C9734F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Largely as a result of the continuing resistance of Linux maintainers
to accept a microcode loading patch for pv-ops Xen kernels, this
follows the suggested route and provides a means to load microcode
updates without the assistance of Dom0, thus also addressing eventual
problems in the hardware much earlier.

This leverages the fact that via the multiboot protocol another blob
of data can be easily added in the form of just an extra module. Since
microcode data cannot reliably be recognized by looking at the
provided data, this requires (in the non-EFI case) the use of a
command line parameter ("ucode=3D<number>") to identify which of the
modules is to be parsed for an eventual microcode update (in the EFI
case the module is being identified in the config file, and hence the
command line argument, if given, will be ignored).

This required to adjust the XSM module determination logic accordingly.

The format of the data to be provided is the raw binary blob already
used for AMD CPUs, and the output of the intel-microcode2ucode utility
for the Intel case (either the per-(family,model,stepping) file or -
to make things easier for distro-s integration-wise - simply the
concatenation of all of them).

In order to not convert the spin_lock() in microcode_update_cpu() (and
then obviously also all other uses on microcode_mutex) to
spin_lock_irqsave() (which would be undesirable for the hypercall
context in which the function also runs), the boot time handling gets
done using a tasklet (instead of using on_selected_cpus()).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/efi/boot.c
+++ b/xen/arch/x86/efi/boot.c
@@ -49,6 +49,7 @@ static UINT32 __initdata mdesc_ver;
 static struct file __initdata cfg;
 static struct file __initdata kernel;
 static struct file __initdata ramdisk;
+static struct file __initdata ucode;
 static struct file __initdata xsm;
=20
 static multiboot_info_t __initdata mbi =3D {
@@ -174,6 +175,8 @@ static void __init __attribute__((__nore
         efi_bs->FreePages(kernel.addr, PFN_UP(kernel.size));
     if ( ramdisk.addr )
         efi_bs->FreePages(ramdisk.addr, PFN_UP(ramdisk.size));
+    if ( ucode.addr )
+        efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
     if ( xsm.addr )
         efi_bs->FreePages(xsm.addr, PFN_UP(xsm.size));
=20
@@ -806,6 +809,17 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
         efi_bs->FreePool(name.w);
     }
=20
+    name.s =3D get_value(&cfg, section.s, "ucode");
+    if ( !name.s )
+        name.s =3D get_value(&cfg, "global", "ucode");
+    if ( name.s )
+    {
+        microcode_set_module(mbi.mods_count);
+        split_value(name.s);
+        read_file(dir_handle, s2w(&name), &ucode);
+        efi_bs->FreePool(name.w);
+    }
+
     name.s =3D get_value(&cfg, section.s, "xsm");
     if ( name.s )
     {
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -29,13 +29,49 @@
 #include <xen/notifier.h>
 #include <xen/sched.h>
 #include <xen/smp.h>
+#include <xen/softirq.h>
 #include <xen/spinlock.h>
+#include <xen/tasklet.h>
 #include <xen/guest_access.h>
=20
 #include <asm/msr.h>
 #include <asm/processor.h>
+#include <asm/setup.h>
 #include <asm/microcode.h>
=20
+static module_t __initdata ucode_mod;
+static void *(*__initdata ucode_mod_map)(const module_t *);
+static unsigned int __initdata ucode_mod_idx;
+static bool_t __initdata ucode_mod_forced;
+static cpumask_t __initdata init_mask;
+
+void __init microcode_set_module(unsigned int idx)
+{
+    ucode_mod_idx =3D idx;
+    ucode_mod_forced =3D 1;
+}
+
+static void __init parse_ucode(char *s)
+{
+    if ( !ucode_mod_forced )
+        ucode_mod_idx =3D simple_strtoul(s, NULL, 0);
+}
+custom_param("ucode", parse_ucode);
+
+void __init microcode_grab_module(
+    unsigned long *module_map,
+    const multiboot_info_t *mbi,
+    void *(*map)(const module_t *))
+{
+    module_t *mod =3D (module_t *)__va(mbi->mods_addr);
+
+    if ( !ucode_mod_idx || ucode_mod_idx >=3D mbi->mods_count ||
+         !__test_and_clear_bit(ucode_mod_idx, module_map) )
+        return;
+    ucode_mod =3D mod[ucode_mod_idx];
+    ucode_mod_map =3D map;
+}
+
 const struct microcode_ops *microcode_ops;
=20
 static DEFINE_SPINLOCK(microcode_mutex);
@@ -183,6 +219,41 @@ int microcode_update(XEN_GUEST_HANDLE(co
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, =
info);
 }
=20
+static void __init _do_microcode_update(unsigned long data)
+{
+    microcode_update_cpu((void *)data, ucode_mod.mod_end);
+    cpumask_set_cpu(smp_processor_id(), &init_mask);
+}
+
+static int __init microcode_init(void)
+{
+    void *data;
+    static struct tasklet __initdata tasklet;
+    unsigned int cpu;
+
+    if ( !microcode_ops || !ucode_mod.mod_end )
+        return 0;
+
+    data =3D ucode_mod_map(&ucode_mod);
+    if ( !data )
+        return -ENOMEM;
+
+    softirq_tasklet_init(&tasklet, _do_microcode_update, (unsigned =
long)data);
+
+    for_each_online_cpu ( cpu )
+    {
+        tasklet_schedule_on_cpu(&tasklet, cpu);
+        do {
+            process_pending_softirqs();
+        } while ( !cpumask_test_cpu(cpu, &init_mask) );
+    }
+
+    ucode_mod_map(NULL);
+
+    return 0;
+}
+__initcall(microcode_init);
+
 static int microcode_percpu_callback(
     struct notifier_block *nfb, unsigned long action, void *hcpu)
 {
@@ -205,7 +276,20 @@ static struct notifier_block microcode_p
 static int __init microcode_presmp_init(void)
 {
     if ( microcode_ops )
+    {
+        if ( ucode_mod.mod_end )
+        {
+            void *data =3D ucode_mod_map(&ucode_mod);
+
+            if ( data )
+                microcode_update_cpu(data, ucode_mod.mod_end);
+
+            ucode_mod_map(NULL);
+        }
+
         register_cpu_notifier(&microcode_percpu_nfb);
+    }
+
     return 0;
 }
 presmp_initcall(microcode_presmp_init);
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -550,10 +550,10 @@ void __init __start_xen(unsigned long mb
 {
     char *memmap_type =3D NULL;
     char *cmdline, *kextra, *loader;
-    unsigned int initrdidx =3D 1;
+    unsigned int initrdidx;
     multiboot_info_t *mbi =3D __va(mbi_p);
     module_t *mod =3D (module_t *)__va(mbi->mods_addr);
-    unsigned long nr_pages, modules_headroom;
+    unsigned long nr_pages, modules_headroom, *module_map;
     int i, j, e820_warn =3D 0, bytes =3D 0;
     bool_t acpi_boot_table_init_done =3D 0;
     struct ns16550_defaults ns16550 =3D {
@@ -1229,7 +1229,13 @@ void __init __start_xen(unsigned long mb
=20
     init_IRQ();
=20
-    xsm_init(&initrdidx, mbi, bootstrap_map);
+    module_map =3D xmalloc_array(unsigned long, BITS_TO_LONGS(mbi->mods_co=
unt));
+    bitmap_fill(module_map, mbi->mods_count);
+    __clear_bit(0, module_map); /* Dom0 kernel is always first */
+
+    xsm_init(module_map, mbi, bootstrap_map);
+
+    microcode_grab_module(module_map, mbi, bootstrap_map);
=20
     timer_init();
=20
@@ -1356,6 +1362,12 @@ void __init __start_xen(unsigned long mb
     if ( xen_cpuidle )
         xen_processor_pmbits |=3D XEN_PROCESSOR_PM_CX;
=20
+    initrdidx =3D find_first_bit(module_map, mbi->mods_count);
+    if ( bitmap_weight(module_map, mbi->mods_count) > 1 )
+        printk(XENLOG_WARNING
+               "Multiple initrd candidates, picking module #%u\n",
+               initrdidx);
+
     /*
      * We're going to setup domain0 using the module(s) that we stashed =
safely
      * above our heap. The second module, if present, is an initrd =
ramdisk.
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -598,6 +598,7 @@ int cpuid_hypervisor_leaves( uint32_t id
 int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val);
 int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val);
=20
+void microcode_set_module(unsigned int);
 int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len);
 int microcode_resume_cpu(int cpu);
=20
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -44,4 +44,7 @@ void discard_initial_images(void);
 int xen_in_range(unsigned long mfn);
 void arch_get_xen_caps(xen_capabilities_info_t *info);
=20
+void microcode_grab_module(
+    unsigned long *, const multiboot_info_t *, void *(*)(const module_t =
*));
+
 #endif
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -454,14 +454,15 @@ static inline long __do_xsm_op (XEN_GUES
 }
=20
 #ifdef XSM_ENABLE
-extern int xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
+extern int xsm_init(unsigned long *module_map, const multiboot_info_t =
*mbi,
                     void *(*bootstrap_map)(const module_t *));
-extern int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t=
 *mbi,
+extern int xsm_policy_init(unsigned long *module_map,
+                           const multiboot_info_t *mbi,
                            void *(*bootstrap_map)(const module_t *));
 extern int register_xsm(struct xsm_operations *ops);
 extern int unregister_xsm(struct xsm_operations *ops);
 #else
-static inline int xsm_init (unsigned int *initrdidx,
+static inline int xsm_init (unsigned long *module_map,
                             const multiboot_info_t *mbi,
                             void *(*bootstrap_map)(const module_t *))
 {
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -43,7 +43,7 @@ static void __init do_xsm_initcalls(void
     }
 }
=20
-int __init xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
+int __init xsm_init(unsigned long *module_map, const multiboot_info_t =
*mbi,
                     void *(*bootstrap_map)(const module_t *))
 {
     int ret =3D 0;
@@ -52,7 +52,7 @@ int __init xsm_init(unsigned int *initrd
=20
     if ( XSM_MAGIC )
     {
-        ret =3D xsm_policy_init(initrdidx, mbi, bootstrap_map);
+        ret =3D xsm_policy_init(module_map, mbi, bootstrap_map);
         if ( ret )
         {
             bootstrap_map(NULL);
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -20,11 +20,12 @@
=20
 #include <xsm/xsm.h>
 #include <xen/multiboot.h>
+#include <asm/bitops.h>
=20
 char *__initdata policy_buffer =3D NULL;
 u32 __initdata policy_size =3D 0;
=20
-int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
+int xsm_policy_init(unsigned long *module_map, const multiboot_info_t =
*mbi,
                     void *(*bootstrap_map)(const module_t *))
 {
     int i;
@@ -35,10 +36,13 @@ int xsm_policy_init(unsigned int *initrd
=20
     /*
      * Try all modules and see whichever could be the binary policy.
-     * Adjust the initrdidx if module[1] is the binary policy.
+     * Adjust module_map for the module that is the binary policy.
      */
     for ( i =3D mbi->mods_count-1; i >=3D 1; i-- )
     {
+        if ( !test_bit(i, module_map) )
+            continue;
+
         _policy_start =3D bootstrap_map(mod + i);
         _policy_len   =3D mod[i].mod_end;
=20
@@ -50,8 +54,7 @@ int xsm_policy_init(unsigned int *initrd
             printk("Policy len  0x%lx, start at %p.\n",
                    _policy_len,_policy_start);
=20
-            if ( i =3D=3D 1 )
-                *initrdidx =3D (mbi->mods_count > 2) ? 2 : 0;
+            __clear_bit(i, module_map);
             break;
=20
         }



--=__PartE6C9734F.0__=
Content-Type: text/plain; name="x86-ucode-boot-load.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ucode-boot-load.patch"

x86/microcode: enable boot time (pre-Dom0) loading=0A=0ALargely as a =
result of the continuing resistance of Linux maintainers=0Ato accept a =
microcode loading patch for pv-ops Xen kernels, this=0Afollows the =
suggested route and provides a means to load microcode=0Aupdates without =
the assistance of Dom0, thus also addressing eventual=0Aproblems in the =
hardware much earlier.=0A=0AThis leverages the fact that via the multiboot =
protocol another blob=0Aof data can be easily added in the form of just an =
extra module. Since=0Amicrocode data cannot reliably be recognized by =
looking at the=0Aprovided data, this requires (in the non-EFI case) the =
use of a=0Acommand line parameter ("ucode=3D<number>") to identify which =
of the=0Amodules is to be parsed for an eventual microcode update (in the =
EFI=0Acase the module is being identified in the config file, and hence =
the=0Acommand line argument, if given, will be ignored).=0A=0AThis =
required to adjust the XSM module determination logic accordingly.=0A=0AThe=
 format of the data to be provided is the raw binary blob already=0Aused =
for AMD CPUs, and the output of the intel-microcode2ucode utility=0Afor =
the Intel case (either the per-(family,model,stepping) file or -=0Ato make =
things easier for distro-s integration-wise - simply the=0Aconcatenation =
of all of them).=0A=0AIn order to not convert the spin_lock() in microcode_=
update_cpu() (and=0Athen obviously also all other uses on microcode_mutex) =
to=0Aspin_lock_irqsave() (which would be undesirable for the hypercall=0Aco=
ntext in which the function also runs), the boot time handling gets=0Adone =
using a tasklet (instead of using on_selected_cpus()).=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/efi/boot.c=0A+++ =
b/xen/arch/x86/efi/boot.c=0A@@ -49,6 +49,7 @@ static UINT32 __initdata =
mdesc_ver;=0A static struct file __initdata cfg;=0A static struct file =
__initdata kernel;=0A static struct file __initdata ramdisk;=0A+static =
struct file __initdata ucode;=0A static struct file __initdata xsm;=0A =0A =
static multiboot_info_t __initdata mbi =3D {=0A@@ -174,6 +175,8 @@ static =
void __init __attribute__((__nore=0A         efi_bs->FreePages(kernel.addr,=
 PFN_UP(kernel.size));=0A     if ( ramdisk.addr )=0A         efi_bs->FreePa=
ges(ramdisk.addr, PFN_UP(ramdisk.size));=0A+    if ( ucode.addr )=0A+      =
  efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));=0A     if ( xsm.addr =
)=0A         efi_bs->FreePages(xsm.addr, PFN_UP(xsm.size));=0A =0A@@ =
-806,6 +809,17 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A         =
efi_bs->FreePool(name.w);=0A     }=0A =0A+    name.s =3D get_value(&cfg, =
section.s, "ucode");=0A+    if ( !name.s )=0A+        name.s =3D get_value(=
&cfg, "global", "ucode");=0A+    if ( name.s )=0A+    {=0A+        =
microcode_set_module(mbi.mods_count);=0A+        split_value(name.s);=0A+  =
      read_file(dir_handle, s2w(&name), &ucode);=0A+        efi_bs->FreePoo=
l(name.w);=0A+    }=0A+=0A     name.s =3D get_value(&cfg, section.s, =
"xsm");=0A     if ( name.s )=0A     {=0A--- a/xen/arch/x86/microcode.c=0A++=
+ b/xen/arch/x86/microcode.c=0A@@ -29,13 +29,49 @@=0A #include <xen/notifie=
r.h>=0A #include <xen/sched.h>=0A #include <xen/smp.h>=0A+#include =
<xen/softirq.h>=0A #include <xen/spinlock.h>=0A+#include <xen/tasklet.h>=0A=
 #include <xen/guest_access.h>=0A =0A #include <asm/msr.h>=0A #include =
<asm/processor.h>=0A+#include <asm/setup.h>=0A #include <asm/microcode.h>=
=0A =0A+static module_t __initdata ucode_mod;=0A+static void *(*__initdata =
ucode_mod_map)(const module_t *);=0A+static unsigned int __initdata =
ucode_mod_idx;=0A+static bool_t __initdata ucode_mod_forced;=0A+static =
cpumask_t __initdata init_mask;=0A+=0A+void __init microcode_set_module(uns=
igned int idx)=0A+{=0A+    ucode_mod_idx =3D idx;=0A+    ucode_mod_forced =
=3D 1;=0A+}=0A+=0A+static void __init parse_ucode(char *s)=0A+{=0A+    if =
( !ucode_mod_forced )=0A+        ucode_mod_idx =3D simple_strtoul(s, NULL, =
0);=0A+}=0A+custom_param("ucode", parse_ucode);=0A+=0A+void __init =
microcode_grab_module(=0A+    unsigned long *module_map,=0A+    const =
multiboot_info_t *mbi,=0A+    void *(*map)(const module_t *))=0A+{=0A+    =
module_t *mod =3D (module_t *)__va(mbi->mods_addr);=0A+=0A+    if ( =
!ucode_mod_idx || ucode_mod_idx >=3D mbi->mods_count ||=0A+         =
!__test_and_clear_bit(ucode_mod_idx, module_map) )=0A+        return;=0A+  =
  ucode_mod =3D mod[ucode_mod_idx];=0A+    ucode_mod_map =3D map;=0A+}=0A+=
=0A const struct microcode_ops *microcode_ops;=0A =0A static DEFINE_SPINLOC=
K(microcode_mutex);=0A@@ -183,6 +219,41 @@ int microcode_update(XEN_GUEST_H=
ANDLE(co=0A     return continue_hypercall_on_cpu(info->cpu, do_microcode_up=
date, info);=0A }=0A =0A+static void __init _do_microcode_update(unsigned =
long data)=0A+{=0A+    microcode_update_cpu((void *)data, ucode_mod.mod_end=
);=0A+    cpumask_set_cpu(smp_processor_id(), &init_mask);=0A+}=0A+=0A+stat=
ic int __init microcode_init(void)=0A+{=0A+    void *data;=0A+    static =
struct tasklet __initdata tasklet;=0A+    unsigned int cpu;=0A+=0A+    if =
( !microcode_ops || !ucode_mod.mod_end )=0A+        return 0;=0A+=0A+    =
data =3D ucode_mod_map(&ucode_mod);=0A+    if ( !data )=0A+        return =
-ENOMEM;=0A+=0A+    softirq_tasklet_init(&tasklet, _do_microcode_update, =
(unsigned long)data);=0A+=0A+    for_each_online_cpu ( cpu )=0A+    {=0A+  =
      tasklet_schedule_on_cpu(&tasklet, cpu);=0A+        do {=0A+          =
  process_pending_softirqs();=0A+        } while ( !cpumask_test_cpu(cpu, =
&init_mask) );=0A+    }=0A+=0A+    ucode_mod_map(NULL);=0A+=0A+    return =
0;=0A+}=0A+__initcall(microcode_init);=0A+=0A static int microcode_percpu_c=
allback(=0A     struct notifier_block *nfb, unsigned long action, void =
*hcpu)=0A {=0A@@ -205,7 +276,20 @@ static struct notifier_block microcode_p=
=0A static int __init microcode_presmp_init(void)=0A {=0A     if ( =
microcode_ops )=0A+    {=0A+        if ( ucode_mod.mod_end )=0A+        =
{=0A+            void *data =3D ucode_mod_map(&ucode_mod);=0A+=0A+         =
   if ( data )=0A+                microcode_update_cpu(data, ucode_mod.mod_=
end);=0A+=0A+            ucode_mod_map(NULL);=0A+        }=0A+=0A         =
register_cpu_notifier(&microcode_percpu_nfb);=0A+    }=0A+=0A     return =
0;=0A }=0A presmp_initcall(microcode_presmp_init);=0A--- a/xen/arch/x86/set=
up.c=0A+++ b/xen/arch/x86/setup.c=0A@@ -550,10 +550,10 @@ void __init =
__start_xen(unsigned long mb=0A {=0A     char *memmap_type =3D NULL;=0A    =
 char *cmdline, *kextra, *loader;=0A-    unsigned int initrdidx =3D 1;=0A+ =
   unsigned int initrdidx;=0A     multiboot_info_t *mbi =3D __va(mbi_p);=0A=
     module_t *mod =3D (module_t *)__va(mbi->mods_addr);=0A-    unsigned =
long nr_pages, modules_headroom;=0A+    unsigned long nr_pages, modules_hea=
droom, *module_map;=0A     int i, j, e820_warn =3D 0, bytes =3D 0;=0A     =
bool_t acpi_boot_table_init_done =3D 0;=0A     struct ns16550_defaults =
ns16550 =3D {=0A@@ -1229,7 +1229,13 @@ void __init __start_xen(unsigned =
long mb=0A =0A     init_IRQ();=0A =0A-    xsm_init(&initrdidx, mbi, =
bootstrap_map);=0A+    module_map =3D xmalloc_array(unsigned long, =
BITS_TO_LONGS(mbi->mods_count));=0A+    bitmap_fill(module_map, mbi->mods_c=
ount);=0A+    __clear_bit(0, module_map); /* Dom0 kernel is always first =
*/=0A+=0A+    xsm_init(module_map, mbi, bootstrap_map);=0A+=0A+    =
microcode_grab_module(module_map, mbi, bootstrap_map);=0A =0A     =
timer_init();=0A =0A@@ -1356,6 +1362,12 @@ void __init __start_xen(unsigned=
 long mb=0A     if ( xen_cpuidle )=0A         xen_processor_pmbits |=3D =
XEN_PROCESSOR_PM_CX;=0A =0A+    initrdidx =3D find_first_bit(module_map, =
mbi->mods_count);=0A+    if ( bitmap_weight(module_map, mbi->mods_count) > =
1 )=0A+        printk(XENLOG_WARNING=0A+               "Multiple initrd =
candidates, picking module #%u\n",=0A+               initrdidx);=0A+=0A    =
 /*=0A      * We're going to setup domain0 using the module(s) that we =
stashed safely=0A      * above our heap. The second module, if present, is =
an initrd ramdisk.=0A--- a/xen/include/asm-x86/processor.h=0A+++ b/xen/incl=
ude/asm-x86/processor.h=0A@@ -598,6 +598,7 @@ int cpuid_hypervisor_leaves( =
uint32_t id=0A int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val);=0A =
int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val);=0A =0A+void =
microcode_set_module(unsigned int);=0A int microcode_update(XEN_GUEST_HANDL=
E(const_void), unsigned long len);=0A int microcode_resume_cpu(int =
cpu);=0A =0A--- a/xen/include/asm-x86/setup.h=0A+++ b/xen/include/asm-x86/s=
etup.h=0A@@ -44,4 +44,7 @@ void discard_initial_images(void);=0A int =
xen_in_range(unsigned long mfn);=0A void arch_get_xen_caps(xen_capabilities=
_info_t *info);=0A =0A+void microcode_grab_module(=0A+    unsigned long *, =
const multiboot_info_t *, void *(*)(const module_t *));=0A+=0A #endif=0A---=
 a/xen/include/xsm/xsm.h=0A+++ b/xen/include/xsm/xsm.h=0A@@ -454,14 =
+454,15 @@ static inline long __do_xsm_op (XEN_GUES=0A }=0A =0A #ifdef =
XSM_ENABLE=0A-extern int xsm_init(unsigned int *initrdidx, const multiboot_=
info_t *mbi,=0A+extern int xsm_init(unsigned long *module_map, const =
multiboot_info_t *mbi,=0A                     void *(*bootstrap_map)(const =
module_t *));=0A-extern int xsm_policy_init(unsigned int *initrdidx, const =
multiboot_info_t *mbi,=0A+extern int xsm_policy_init(unsigned long =
*module_map,=0A+                           const multiboot_info_t *mbi,=0A =
                           void *(*bootstrap_map)(const module_t *));=0A =
extern int register_xsm(struct xsm_operations *ops);=0A extern int =
unregister_xsm(struct xsm_operations *ops);=0A #else=0A-static inline int =
xsm_init (unsigned int *initrdidx,=0A+static inline int xsm_init (unsigned =
long *module_map,=0A                             const multiboot_info_t =
*mbi,=0A                             void *(*bootstrap_map)(const module_t =
*))=0A {=0A--- a/xen/xsm/xsm_core.c=0A+++ b/xen/xsm/xsm_core.c=0A@@ -43,7 =
+43,7 @@ static void __init do_xsm_initcalls(void=0A     }=0A }=0A =0A-int =
__init xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,=0A+in=
t __init xsm_init(unsigned long *module_map, const multiboot_info_t =
*mbi,=0A                     void *(*bootstrap_map)(const module_t *))=0A =
{=0A     int ret =3D 0;=0A@@ -52,7 +52,7 @@ int __init xsm_init(unsigned =
int *initrd=0A =0A     if ( XSM_MAGIC )=0A     {=0A-        ret =3D =
xsm_policy_init(initrdidx, mbi, bootstrap_map);=0A+        ret =3D =
xsm_policy_init(module_map, mbi, bootstrap_map);=0A         if ( ret )=0A  =
       {=0A             bootstrap_map(NULL);=0A--- a/xen/xsm/xsm_policy.c=
=0A+++ b/xen/xsm/xsm_policy.c=0A@@ -20,11 +20,12 @@=0A =0A #include =
<xsm/xsm.h>=0A #include <xen/multiboot.h>=0A+#include <asm/bitops.h>=0A =
=0A char *__initdata policy_buffer =3D NULL;=0A u32 __initdata policy_size =
=3D 0;=0A =0A-int xsm_policy_init(unsigned int *initrdidx, const multiboot_=
info_t *mbi,=0A+int xsm_policy_init(unsigned long *module_map, const =
multiboot_info_t *mbi,=0A                     void *(*bootstrap_map)(const =
module_t *))=0A {=0A     int i;=0A@@ -35,10 +36,13 @@ int xsm_policy_init(u=
nsigned int *initrd=0A =0A     /*=0A      * Try all modules and see =
whichever could be the binary policy.=0A-     * Adjust the initrdidx if =
module[1] is the binary policy.=0A+     * Adjust module_map for the module =
that is the binary policy.=0A      */=0A     for ( i =3D mbi->mods_count-1;=
 i >=3D 1; i-- )=0A     {=0A+        if ( !test_bit(i, module_map) )=0A+   =
         continue;=0A+=0A         _policy_start =3D bootstrap_map(mod + =
i);=0A         _policy_len   =3D mod[i].mod_end;=0A =0A@@ -50,8 +54,7 @@ =
int xsm_policy_init(unsigned int *initrd=0A             printk("Policy len =
 0x%lx, start at %p.\n",=0A                    _policy_len,_policy_start);=
=0A =0A-            if ( i =3D=3D 1 )=0A-                *initrdidx =3D =
(mbi->mods_count > 2) ? 2 : 0;=0A+            __clear_bit(i, module_map);=
=0A             break;=0A =0A         }=0A
--=__PartE6C9734F.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartE6C9734F.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:28:11 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:28:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVn0l-0005SO-Nn; Wed, 30 Nov 2011 16:27:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVn0k-0005Qp-9P
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:27:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1322670435!5321661!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26324 invoked from network); 30 Nov 2011 16:27:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:27:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:27:14 +0000
Message-Id: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:27:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE6C9734F.0__="
Subject: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time (pre-Dom0)
	loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE6C9734F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Largely as a result of the continuing resistance of Linux maintainers
to accept a microcode loading patch for pv-ops Xen kernels, this
follows the suggested route and provides a means to load microcode
updates without the assistance of Dom0, thus also addressing eventual
problems in the hardware much earlier.

This leverages the fact that via the multiboot protocol another blob
of data can be easily added in the form of just an extra module. Since
microcode data cannot reliably be recognized by looking at the
provided data, this requires (in the non-EFI case) the use of a
command line parameter ("ucode=3D<number>") to identify which of the
modules is to be parsed for an eventual microcode update (in the EFI
case the module is being identified in the config file, and hence the
command line argument, if given, will be ignored).

This required to adjust the XSM module determination logic accordingly.

The format of the data to be provided is the raw binary blob already
used for AMD CPUs, and the output of the intel-microcode2ucode utility
for the Intel case (either the per-(family,model,stepping) file or -
to make things easier for distro-s integration-wise - simply the
concatenation of all of them).

In order to not convert the spin_lock() in microcode_update_cpu() (and
then obviously also all other uses on microcode_mutex) to
spin_lock_irqsave() (which would be undesirable for the hypercall
context in which the function also runs), the boot time handling gets
done using a tasklet (instead of using on_selected_cpus()).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/efi/boot.c
+++ b/xen/arch/x86/efi/boot.c
@@ -49,6 +49,7 @@ static UINT32 __initdata mdesc_ver;
 static struct file __initdata cfg;
 static struct file __initdata kernel;
 static struct file __initdata ramdisk;
+static struct file __initdata ucode;
 static struct file __initdata xsm;
=20
 static multiboot_info_t __initdata mbi =3D {
@@ -174,6 +175,8 @@ static void __init __attribute__((__nore
         efi_bs->FreePages(kernel.addr, PFN_UP(kernel.size));
     if ( ramdisk.addr )
         efi_bs->FreePages(ramdisk.addr, PFN_UP(ramdisk.size));
+    if ( ucode.addr )
+        efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
     if ( xsm.addr )
         efi_bs->FreePages(xsm.addr, PFN_UP(xsm.size));
=20
@@ -806,6 +809,17 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
         efi_bs->FreePool(name.w);
     }
=20
+    name.s =3D get_value(&cfg, section.s, "ucode");
+    if ( !name.s )
+        name.s =3D get_value(&cfg, "global", "ucode");
+    if ( name.s )
+    {
+        microcode_set_module(mbi.mods_count);
+        split_value(name.s);
+        read_file(dir_handle, s2w(&name), &ucode);
+        efi_bs->FreePool(name.w);
+    }
+
     name.s =3D get_value(&cfg, section.s, "xsm");
     if ( name.s )
     {
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -29,13 +29,49 @@
 #include <xen/notifier.h>
 #include <xen/sched.h>
 #include <xen/smp.h>
+#include <xen/softirq.h>
 #include <xen/spinlock.h>
+#include <xen/tasklet.h>
 #include <xen/guest_access.h>
=20
 #include <asm/msr.h>
 #include <asm/processor.h>
+#include <asm/setup.h>
 #include <asm/microcode.h>
=20
+static module_t __initdata ucode_mod;
+static void *(*__initdata ucode_mod_map)(const module_t *);
+static unsigned int __initdata ucode_mod_idx;
+static bool_t __initdata ucode_mod_forced;
+static cpumask_t __initdata init_mask;
+
+void __init microcode_set_module(unsigned int idx)
+{
+    ucode_mod_idx =3D idx;
+    ucode_mod_forced =3D 1;
+}
+
+static void __init parse_ucode(char *s)
+{
+    if ( !ucode_mod_forced )
+        ucode_mod_idx =3D simple_strtoul(s, NULL, 0);
+}
+custom_param("ucode", parse_ucode);
+
+void __init microcode_grab_module(
+    unsigned long *module_map,
+    const multiboot_info_t *mbi,
+    void *(*map)(const module_t *))
+{
+    module_t *mod =3D (module_t *)__va(mbi->mods_addr);
+
+    if ( !ucode_mod_idx || ucode_mod_idx >=3D mbi->mods_count ||
+         !__test_and_clear_bit(ucode_mod_idx, module_map) )
+        return;
+    ucode_mod =3D mod[ucode_mod_idx];
+    ucode_mod_map =3D map;
+}
+
 const struct microcode_ops *microcode_ops;
=20
 static DEFINE_SPINLOCK(microcode_mutex);
@@ -183,6 +219,41 @@ int microcode_update(XEN_GUEST_HANDLE(co
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, =
info);
 }
=20
+static void __init _do_microcode_update(unsigned long data)
+{
+    microcode_update_cpu((void *)data, ucode_mod.mod_end);
+    cpumask_set_cpu(smp_processor_id(), &init_mask);
+}
+
+static int __init microcode_init(void)
+{
+    void *data;
+    static struct tasklet __initdata tasklet;
+    unsigned int cpu;
+
+    if ( !microcode_ops || !ucode_mod.mod_end )
+        return 0;
+
+    data =3D ucode_mod_map(&ucode_mod);
+    if ( !data )
+        return -ENOMEM;
+
+    softirq_tasklet_init(&tasklet, _do_microcode_update, (unsigned =
long)data);
+
+    for_each_online_cpu ( cpu )
+    {
+        tasklet_schedule_on_cpu(&tasklet, cpu);
+        do {
+            process_pending_softirqs();
+        } while ( !cpumask_test_cpu(cpu, &init_mask) );
+    }
+
+    ucode_mod_map(NULL);
+
+    return 0;
+}
+__initcall(microcode_init);
+
 static int microcode_percpu_callback(
     struct notifier_block *nfb, unsigned long action, void *hcpu)
 {
@@ -205,7 +276,20 @@ static struct notifier_block microcode_p
 static int __init microcode_presmp_init(void)
 {
     if ( microcode_ops )
+    {
+        if ( ucode_mod.mod_end )
+        {
+            void *data =3D ucode_mod_map(&ucode_mod);
+
+            if ( data )
+                microcode_update_cpu(data, ucode_mod.mod_end);
+
+            ucode_mod_map(NULL);
+        }
+
         register_cpu_notifier(&microcode_percpu_nfb);
+    }
+
     return 0;
 }
 presmp_initcall(microcode_presmp_init);
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -550,10 +550,10 @@ void __init __start_xen(unsigned long mb
 {
     char *memmap_type =3D NULL;
     char *cmdline, *kextra, *loader;
-    unsigned int initrdidx =3D 1;
+    unsigned int initrdidx;
     multiboot_info_t *mbi =3D __va(mbi_p);
     module_t *mod =3D (module_t *)__va(mbi->mods_addr);
-    unsigned long nr_pages, modules_headroom;
+    unsigned long nr_pages, modules_headroom, *module_map;
     int i, j, e820_warn =3D 0, bytes =3D 0;
     bool_t acpi_boot_table_init_done =3D 0;
     struct ns16550_defaults ns16550 =3D {
@@ -1229,7 +1229,13 @@ void __init __start_xen(unsigned long mb
=20
     init_IRQ();
=20
-    xsm_init(&initrdidx, mbi, bootstrap_map);
+    module_map =3D xmalloc_array(unsigned long, BITS_TO_LONGS(mbi->mods_co=
unt));
+    bitmap_fill(module_map, mbi->mods_count);
+    __clear_bit(0, module_map); /* Dom0 kernel is always first */
+
+    xsm_init(module_map, mbi, bootstrap_map);
+
+    microcode_grab_module(module_map, mbi, bootstrap_map);
=20
     timer_init();
=20
@@ -1356,6 +1362,12 @@ void __init __start_xen(unsigned long mb
     if ( xen_cpuidle )
         xen_processor_pmbits |=3D XEN_PROCESSOR_PM_CX;
=20
+    initrdidx =3D find_first_bit(module_map, mbi->mods_count);
+    if ( bitmap_weight(module_map, mbi->mods_count) > 1 )
+        printk(XENLOG_WARNING
+               "Multiple initrd candidates, picking module #%u\n",
+               initrdidx);
+
     /*
      * We're going to setup domain0 using the module(s) that we stashed =
safely
      * above our heap. The second module, if present, is an initrd =
ramdisk.
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -598,6 +598,7 @@ int cpuid_hypervisor_leaves( uint32_t id
 int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val);
 int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val);
=20
+void microcode_set_module(unsigned int);
 int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len);
 int microcode_resume_cpu(int cpu);
=20
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -44,4 +44,7 @@ void discard_initial_images(void);
 int xen_in_range(unsigned long mfn);
 void arch_get_xen_caps(xen_capabilities_info_t *info);
=20
+void microcode_grab_module(
+    unsigned long *, const multiboot_info_t *, void *(*)(const module_t =
*));
+
 #endif
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -454,14 +454,15 @@ static inline long __do_xsm_op (XEN_GUES
 }
=20
 #ifdef XSM_ENABLE
-extern int xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
+extern int xsm_init(unsigned long *module_map, const multiboot_info_t =
*mbi,
                     void *(*bootstrap_map)(const module_t *));
-extern int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t=
 *mbi,
+extern int xsm_policy_init(unsigned long *module_map,
+                           const multiboot_info_t *mbi,
                            void *(*bootstrap_map)(const module_t *));
 extern int register_xsm(struct xsm_operations *ops);
 extern int unregister_xsm(struct xsm_operations *ops);
 #else
-static inline int xsm_init (unsigned int *initrdidx,
+static inline int xsm_init (unsigned long *module_map,
                             const multiboot_info_t *mbi,
                             void *(*bootstrap_map)(const module_t *))
 {
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -43,7 +43,7 @@ static void __init do_xsm_initcalls(void
     }
 }
=20
-int __init xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
+int __init xsm_init(unsigned long *module_map, const multiboot_info_t =
*mbi,
                     void *(*bootstrap_map)(const module_t *))
 {
     int ret =3D 0;
@@ -52,7 +52,7 @@ int __init xsm_init(unsigned int *initrd
=20
     if ( XSM_MAGIC )
     {
-        ret =3D xsm_policy_init(initrdidx, mbi, bootstrap_map);
+        ret =3D xsm_policy_init(module_map, mbi, bootstrap_map);
         if ( ret )
         {
             bootstrap_map(NULL);
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -20,11 +20,12 @@
=20
 #include <xsm/xsm.h>
 #include <xen/multiboot.h>
+#include <asm/bitops.h>
=20
 char *__initdata policy_buffer =3D NULL;
 u32 __initdata policy_size =3D 0;
=20
-int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
+int xsm_policy_init(unsigned long *module_map, const multiboot_info_t =
*mbi,
                     void *(*bootstrap_map)(const module_t *))
 {
     int i;
@@ -35,10 +36,13 @@ int xsm_policy_init(unsigned int *initrd
=20
     /*
      * Try all modules and see whichever could be the binary policy.
-     * Adjust the initrdidx if module[1] is the binary policy.
+     * Adjust module_map for the module that is the binary policy.
      */
     for ( i =3D mbi->mods_count-1; i >=3D 1; i-- )
     {
+        if ( !test_bit(i, module_map) )
+            continue;
+
         _policy_start =3D bootstrap_map(mod + i);
         _policy_len   =3D mod[i].mod_end;
=20
@@ -50,8 +54,7 @@ int xsm_policy_init(unsigned int *initrd
             printk("Policy len  0x%lx, start at %p.\n",
                    _policy_len,_policy_start);
=20
-            if ( i =3D=3D 1 )
-                *initrdidx =3D (mbi->mods_count > 2) ? 2 : 0;
+            __clear_bit(i, module_map);
             break;
=20
         }



--=__PartE6C9734F.0__=
Content-Type: text/plain; name="x86-ucode-boot-load.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ucode-boot-load.patch"

x86/microcode: enable boot time (pre-Dom0) loading=0A=0ALargely as a =
result of the continuing resistance of Linux maintainers=0Ato accept a =
microcode loading patch for pv-ops Xen kernels, this=0Afollows the =
suggested route and provides a means to load microcode=0Aupdates without =
the assistance of Dom0, thus also addressing eventual=0Aproblems in the =
hardware much earlier.=0A=0AThis leverages the fact that via the multiboot =
protocol another blob=0Aof data can be easily added in the form of just an =
extra module. Since=0Amicrocode data cannot reliably be recognized by =
looking at the=0Aprovided data, this requires (in the non-EFI case) the =
use of a=0Acommand line parameter ("ucode=3D<number>") to identify which =
of the=0Amodules is to be parsed for an eventual microcode update (in the =
EFI=0Acase the module is being identified in the config file, and hence =
the=0Acommand line argument, if given, will be ignored).=0A=0AThis =
required to adjust the XSM module determination logic accordingly.=0A=0AThe=
 format of the data to be provided is the raw binary blob already=0Aused =
for AMD CPUs, and the output of the intel-microcode2ucode utility=0Afor =
the Intel case (either the per-(family,model,stepping) file or -=0Ato make =
things easier for distro-s integration-wise - simply the=0Aconcatenation =
of all of them).=0A=0AIn order to not convert the spin_lock() in microcode_=
update_cpu() (and=0Athen obviously also all other uses on microcode_mutex) =
to=0Aspin_lock_irqsave() (which would be undesirable for the hypercall=0Aco=
ntext in which the function also runs), the boot time handling gets=0Adone =
using a tasklet (instead of using on_selected_cpus()).=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/efi/boot.c=0A+++ =
b/xen/arch/x86/efi/boot.c=0A@@ -49,6 +49,7 @@ static UINT32 __initdata =
mdesc_ver;=0A static struct file __initdata cfg;=0A static struct file =
__initdata kernel;=0A static struct file __initdata ramdisk;=0A+static =
struct file __initdata ucode;=0A static struct file __initdata xsm;=0A =0A =
static multiboot_info_t __initdata mbi =3D {=0A@@ -174,6 +175,8 @@ static =
void __init __attribute__((__nore=0A         efi_bs->FreePages(kernel.addr,=
 PFN_UP(kernel.size));=0A     if ( ramdisk.addr )=0A         efi_bs->FreePa=
ges(ramdisk.addr, PFN_UP(ramdisk.size));=0A+    if ( ucode.addr )=0A+      =
  efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));=0A     if ( xsm.addr =
)=0A         efi_bs->FreePages(xsm.addr, PFN_UP(xsm.size));=0A =0A@@ =
-806,6 +809,17 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A         =
efi_bs->FreePool(name.w);=0A     }=0A =0A+    name.s =3D get_value(&cfg, =
section.s, "ucode");=0A+    if ( !name.s )=0A+        name.s =3D get_value(=
&cfg, "global", "ucode");=0A+    if ( name.s )=0A+    {=0A+        =
microcode_set_module(mbi.mods_count);=0A+        split_value(name.s);=0A+  =
      read_file(dir_handle, s2w(&name), &ucode);=0A+        efi_bs->FreePoo=
l(name.w);=0A+    }=0A+=0A     name.s =3D get_value(&cfg, section.s, =
"xsm");=0A     if ( name.s )=0A     {=0A--- a/xen/arch/x86/microcode.c=0A++=
+ b/xen/arch/x86/microcode.c=0A@@ -29,13 +29,49 @@=0A #include <xen/notifie=
r.h>=0A #include <xen/sched.h>=0A #include <xen/smp.h>=0A+#include =
<xen/softirq.h>=0A #include <xen/spinlock.h>=0A+#include <xen/tasklet.h>=0A=
 #include <xen/guest_access.h>=0A =0A #include <asm/msr.h>=0A #include =
<asm/processor.h>=0A+#include <asm/setup.h>=0A #include <asm/microcode.h>=
=0A =0A+static module_t __initdata ucode_mod;=0A+static void *(*__initdata =
ucode_mod_map)(const module_t *);=0A+static unsigned int __initdata =
ucode_mod_idx;=0A+static bool_t __initdata ucode_mod_forced;=0A+static =
cpumask_t __initdata init_mask;=0A+=0A+void __init microcode_set_module(uns=
igned int idx)=0A+{=0A+    ucode_mod_idx =3D idx;=0A+    ucode_mod_forced =
=3D 1;=0A+}=0A+=0A+static void __init parse_ucode(char *s)=0A+{=0A+    if =
( !ucode_mod_forced )=0A+        ucode_mod_idx =3D simple_strtoul(s, NULL, =
0);=0A+}=0A+custom_param("ucode", parse_ucode);=0A+=0A+void __init =
microcode_grab_module(=0A+    unsigned long *module_map,=0A+    const =
multiboot_info_t *mbi,=0A+    void *(*map)(const module_t *))=0A+{=0A+    =
module_t *mod =3D (module_t *)__va(mbi->mods_addr);=0A+=0A+    if ( =
!ucode_mod_idx || ucode_mod_idx >=3D mbi->mods_count ||=0A+         =
!__test_and_clear_bit(ucode_mod_idx, module_map) )=0A+        return;=0A+  =
  ucode_mod =3D mod[ucode_mod_idx];=0A+    ucode_mod_map =3D map;=0A+}=0A+=
=0A const struct microcode_ops *microcode_ops;=0A =0A static DEFINE_SPINLOC=
K(microcode_mutex);=0A@@ -183,6 +219,41 @@ int microcode_update(XEN_GUEST_H=
ANDLE(co=0A     return continue_hypercall_on_cpu(info->cpu, do_microcode_up=
date, info);=0A }=0A =0A+static void __init _do_microcode_update(unsigned =
long data)=0A+{=0A+    microcode_update_cpu((void *)data, ucode_mod.mod_end=
);=0A+    cpumask_set_cpu(smp_processor_id(), &init_mask);=0A+}=0A+=0A+stat=
ic int __init microcode_init(void)=0A+{=0A+    void *data;=0A+    static =
struct tasklet __initdata tasklet;=0A+    unsigned int cpu;=0A+=0A+    if =
( !microcode_ops || !ucode_mod.mod_end )=0A+        return 0;=0A+=0A+    =
data =3D ucode_mod_map(&ucode_mod);=0A+    if ( !data )=0A+        return =
-ENOMEM;=0A+=0A+    softirq_tasklet_init(&tasklet, _do_microcode_update, =
(unsigned long)data);=0A+=0A+    for_each_online_cpu ( cpu )=0A+    {=0A+  =
      tasklet_schedule_on_cpu(&tasklet, cpu);=0A+        do {=0A+          =
  process_pending_softirqs();=0A+        } while ( !cpumask_test_cpu(cpu, =
&init_mask) );=0A+    }=0A+=0A+    ucode_mod_map(NULL);=0A+=0A+    return =
0;=0A+}=0A+__initcall(microcode_init);=0A+=0A static int microcode_percpu_c=
allback(=0A     struct notifier_block *nfb, unsigned long action, void =
*hcpu)=0A {=0A@@ -205,7 +276,20 @@ static struct notifier_block microcode_p=
=0A static int __init microcode_presmp_init(void)=0A {=0A     if ( =
microcode_ops )=0A+    {=0A+        if ( ucode_mod.mod_end )=0A+        =
{=0A+            void *data =3D ucode_mod_map(&ucode_mod);=0A+=0A+         =
   if ( data )=0A+                microcode_update_cpu(data, ucode_mod.mod_=
end);=0A+=0A+            ucode_mod_map(NULL);=0A+        }=0A+=0A         =
register_cpu_notifier(&microcode_percpu_nfb);=0A+    }=0A+=0A     return =
0;=0A }=0A presmp_initcall(microcode_presmp_init);=0A--- a/xen/arch/x86/set=
up.c=0A+++ b/xen/arch/x86/setup.c=0A@@ -550,10 +550,10 @@ void __init =
__start_xen(unsigned long mb=0A {=0A     char *memmap_type =3D NULL;=0A    =
 char *cmdline, *kextra, *loader;=0A-    unsigned int initrdidx =3D 1;=0A+ =
   unsigned int initrdidx;=0A     multiboot_info_t *mbi =3D __va(mbi_p);=0A=
     module_t *mod =3D (module_t *)__va(mbi->mods_addr);=0A-    unsigned =
long nr_pages, modules_headroom;=0A+    unsigned long nr_pages, modules_hea=
droom, *module_map;=0A     int i, j, e820_warn =3D 0, bytes =3D 0;=0A     =
bool_t acpi_boot_table_init_done =3D 0;=0A     struct ns16550_defaults =
ns16550 =3D {=0A@@ -1229,7 +1229,13 @@ void __init __start_xen(unsigned =
long mb=0A =0A     init_IRQ();=0A =0A-    xsm_init(&initrdidx, mbi, =
bootstrap_map);=0A+    module_map =3D xmalloc_array(unsigned long, =
BITS_TO_LONGS(mbi->mods_count));=0A+    bitmap_fill(module_map, mbi->mods_c=
ount);=0A+    __clear_bit(0, module_map); /* Dom0 kernel is always first =
*/=0A+=0A+    xsm_init(module_map, mbi, bootstrap_map);=0A+=0A+    =
microcode_grab_module(module_map, mbi, bootstrap_map);=0A =0A     =
timer_init();=0A =0A@@ -1356,6 +1362,12 @@ void __init __start_xen(unsigned=
 long mb=0A     if ( xen_cpuidle )=0A         xen_processor_pmbits |=3D =
XEN_PROCESSOR_PM_CX;=0A =0A+    initrdidx =3D find_first_bit(module_map, =
mbi->mods_count);=0A+    if ( bitmap_weight(module_map, mbi->mods_count) > =
1 )=0A+        printk(XENLOG_WARNING=0A+               "Multiple initrd =
candidates, picking module #%u\n",=0A+               initrdidx);=0A+=0A    =
 /*=0A      * We're going to setup domain0 using the module(s) that we =
stashed safely=0A      * above our heap. The second module, if present, is =
an initrd ramdisk.=0A--- a/xen/include/asm-x86/processor.h=0A+++ b/xen/incl=
ude/asm-x86/processor.h=0A@@ -598,6 +598,7 @@ int cpuid_hypervisor_leaves( =
uint32_t id=0A int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val);=0A =
int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val);=0A =0A+void =
microcode_set_module(unsigned int);=0A int microcode_update(XEN_GUEST_HANDL=
E(const_void), unsigned long len);=0A int microcode_resume_cpu(int =
cpu);=0A =0A--- a/xen/include/asm-x86/setup.h=0A+++ b/xen/include/asm-x86/s=
etup.h=0A@@ -44,4 +44,7 @@ void discard_initial_images(void);=0A int =
xen_in_range(unsigned long mfn);=0A void arch_get_xen_caps(xen_capabilities=
_info_t *info);=0A =0A+void microcode_grab_module(=0A+    unsigned long *, =
const multiboot_info_t *, void *(*)(const module_t *));=0A+=0A #endif=0A---=
 a/xen/include/xsm/xsm.h=0A+++ b/xen/include/xsm/xsm.h=0A@@ -454,14 =
+454,15 @@ static inline long __do_xsm_op (XEN_GUES=0A }=0A =0A #ifdef =
XSM_ENABLE=0A-extern int xsm_init(unsigned int *initrdidx, const multiboot_=
info_t *mbi,=0A+extern int xsm_init(unsigned long *module_map, const =
multiboot_info_t *mbi,=0A                     void *(*bootstrap_map)(const =
module_t *));=0A-extern int xsm_policy_init(unsigned int *initrdidx, const =
multiboot_info_t *mbi,=0A+extern int xsm_policy_init(unsigned long =
*module_map,=0A+                           const multiboot_info_t *mbi,=0A =
                           void *(*bootstrap_map)(const module_t *));=0A =
extern int register_xsm(struct xsm_operations *ops);=0A extern int =
unregister_xsm(struct xsm_operations *ops);=0A #else=0A-static inline int =
xsm_init (unsigned int *initrdidx,=0A+static inline int xsm_init (unsigned =
long *module_map,=0A                             const multiboot_info_t =
*mbi,=0A                             void *(*bootstrap_map)(const module_t =
*))=0A {=0A--- a/xen/xsm/xsm_core.c=0A+++ b/xen/xsm/xsm_core.c=0A@@ -43,7 =
+43,7 @@ static void __init do_xsm_initcalls(void=0A     }=0A }=0A =0A-int =
__init xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,=0A+in=
t __init xsm_init(unsigned long *module_map, const multiboot_info_t =
*mbi,=0A                     void *(*bootstrap_map)(const module_t *))=0A =
{=0A     int ret =3D 0;=0A@@ -52,7 +52,7 @@ int __init xsm_init(unsigned =
int *initrd=0A =0A     if ( XSM_MAGIC )=0A     {=0A-        ret =3D =
xsm_policy_init(initrdidx, mbi, bootstrap_map);=0A+        ret =3D =
xsm_policy_init(module_map, mbi, bootstrap_map);=0A         if ( ret )=0A  =
       {=0A             bootstrap_map(NULL);=0A--- a/xen/xsm/xsm_policy.c=
=0A+++ b/xen/xsm/xsm_policy.c=0A@@ -20,11 +20,12 @@=0A =0A #include =
<xsm/xsm.h>=0A #include <xen/multiboot.h>=0A+#include <asm/bitops.h>=0A =
=0A char *__initdata policy_buffer =3D NULL;=0A u32 __initdata policy_size =
=3D 0;=0A =0A-int xsm_policy_init(unsigned int *initrdidx, const multiboot_=
info_t *mbi,=0A+int xsm_policy_init(unsigned long *module_map, const =
multiboot_info_t *mbi,=0A                     void *(*bootstrap_map)(const =
module_t *))=0A {=0A     int i;=0A@@ -35,10 +36,13 @@ int xsm_policy_init(u=
nsigned int *initrd=0A =0A     /*=0A      * Try all modules and see =
whichever could be the binary policy.=0A-     * Adjust the initrdidx if =
module[1] is the binary policy.=0A+     * Adjust module_map for the module =
that is the binary policy.=0A      */=0A     for ( i =3D mbi->mods_count-1;=
 i >=3D 1; i-- )=0A     {=0A+        if ( !test_bit(i, module_map) )=0A+   =
         continue;=0A+=0A         _policy_start =3D bootstrap_map(mod + =
i);=0A         _policy_len   =3D mod[i].mod_end;=0A =0A@@ -50,8 +54,7 @@ =
int xsm_policy_init(unsigned int *initrd=0A             printk("Policy len =
 0x%lx, start at %p.\n",=0A                    _policy_len,_policy_start);=
=0A =0A-            if ( i =3D=3D 1 )=0A-                *initrdidx =3D =
(mbi->mods_count > 2) ? 2 : 0;=0A+            __clear_bit(i, module_map);=
=0A             break;=0A =0A         }=0A
--=__PartE6C9734F.0__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=__PartE6C9734F.0__=--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:28:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVn1O-0005aa-Ac; Wed, 30 Nov 2011 16:28:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVn1M-0005ZI-Kk
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:28:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322670473!3744258!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26431 invoked from network); 30 Nov 2011 16:27:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 16:27:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9212840"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 16:27:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 16:27:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 30 Nov 2011 16:27:53 +0000
In-Reply-To: <201111301432.54463.arnd@arndb.de>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301303.23851.arnd@arndb.de>
	<1322659535.31810.97.camel@zakaz.uk.xensource.com>
	<201111301432.54463.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322670473.31810.129.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Ian Campbell wrote:
> > On Wed, 2011-11-30 at 13:03 +0000, Arnd Bergmann wrote:
> > For domU the DT would presumably be constructed by the toolstack (in
> > dom0 userspace) as appropriate for the guest configuration. I guess this
> > needn't correspond to any particular "real" hardware platform.
> 
> Correct, but it needs to correspond to some platform that is supported
> by the guest OS, which leaves the choice between emulating a real
> hardware platform, adding a completely new platform specifically for
> virtual machines, or something in between the two.
> 
> What I suggested to the KVM developers is to start out with the
> vexpress platform, but then generalize it to the point where it fits
> your needs. All hardware that one expects a guest to have (GIC, timer,
> ...) will still show up in the same location as on a real vexpress,
> while anything that makes no sense or is better paravirtualized (LCD,
> storage, ...) just becomes optional and has to be described in the
> device tree if it's actually there.

That's along the lines of what I was thinking as well.

The DT contains the address of GIC, timer etc as well right? So at least
in principal we needn't provide e.g. the GIC at the same address as any
real platform but in practice I expect we will.

In principal we could also offer the user options as to which particular
platform a guest looks like.

> > > This would also be the place where you tell the guest that it should
> > > look for PV devices. I'm not familiar with how Xen announces PV
> > > devices to the guest on other architectures, but you have the
> > > choice between providing a full "binding", i.e. a formal specification
> > > in device tree format for the guest to detect PV devices in the
> > > same way as physical or emulated devices, or just providing a single
> > > place in the device tree in which the guest detects the presence
> > > of a xen device bus and then uses hcalls to find the devices on that
> > > bus.
> > 
> > On x86 there is an emulated PCI device which serves as the hooking point
> > for the PV drivers. For ARM I don't think it would be unreasonable to
> > have a DT entry instead. I think it would be fine just represent the
> > root of the "xenbus" and further discovery would occur using the normal
> > xenbus mechanisms (so not a full binding). AIUI for buses which are
> > enumerable this is the preferred DT scheme to use.
> 
> In general that is the case, yes. One could argue that any software
> protocol between Xen and the guest is as good as any other, so it
> makes sense to use the device tree to describe all devices here.
> The counterargument to that is that Linux and other OSs already
> support Xenbus, so there is no need to come up with a new binding.

Right.

> I don't care much either way, but I think it would be good to
> use similar solutions across all hypervisors. The two options
> that I've seen discussed for KVM were to use either a virtual PCI
> bus with individual virtio-pci devices as on the PC, or to
> use the new virtio-mmio driver and individually put virtio devices
> into the device tree.
> 
> > > Another topic is the question whether there are any hcalls that
> > > we should try to standardize before we get another architecture
> > > with multiple conflicting hcall APIs as we have on x86 and powerpc.
> > 
> > The hcall API we are currently targeting is the existing Xen API (at
> > least the generic parts of it). These generally deal with fairly Xen
> > specific concepts like grant tables etc.
> 
> Ok. It would of course still be possible to agree on an argument passing
> convention so that we can share the macros used to issue the hcalls,
> even if the individual commands are all different.

I think it likely that we can all agree on a common calling convention
for N-argument hypercalls. It doubt there are that many useful choices
with conflicting requirements yet strongly compelling advantages.

>  I think I also
> remember talk about the need for a set of hypervisor independent calls
> that everyone should implement, but I can't remember what those were.

I'd not heard of this, maybe I just wasn't looking the right way though.

> Maybe we can split the number space into a range of some generic and
> some vendor specific hcalls?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:28:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVn1O-0005aa-Ac; Wed, 30 Nov 2011 16:28:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RVn1M-0005ZI-Kk
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:28:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1322670473!3744258!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26431 invoked from network); 30 Nov 2011 16:27:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 16:27:54 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9212840"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 16:27:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 16:27:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 30 Nov 2011 16:27:53 +0000
In-Reply-To: <201111301432.54463.arnd@arndb.de>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301303.23851.arnd@arndb.de>
	<1322659535.31810.97.camel@zakaz.uk.xensource.com>
	<201111301432.54463.arnd@arndb.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1322670473.31810.129.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
 extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
> On Wednesday 30 November 2011, Ian Campbell wrote:
> > On Wed, 2011-11-30 at 13:03 +0000, Arnd Bergmann wrote:
> > For domU the DT would presumably be constructed by the toolstack (in
> > dom0 userspace) as appropriate for the guest configuration. I guess this
> > needn't correspond to any particular "real" hardware platform.
> 
> Correct, but it needs to correspond to some platform that is supported
> by the guest OS, which leaves the choice between emulating a real
> hardware platform, adding a completely new platform specifically for
> virtual machines, or something in between the two.
> 
> What I suggested to the KVM developers is to start out with the
> vexpress platform, but then generalize it to the point where it fits
> your needs. All hardware that one expects a guest to have (GIC, timer,
> ...) will still show up in the same location as on a real vexpress,
> while anything that makes no sense or is better paravirtualized (LCD,
> storage, ...) just becomes optional and has to be described in the
> device tree if it's actually there.

That's along the lines of what I was thinking as well.

The DT contains the address of GIC, timer etc as well right? So at least
in principal we needn't provide e.g. the GIC at the same address as any
real platform but in practice I expect we will.

In principal we could also offer the user options as to which particular
platform a guest looks like.

> > > This would also be the place where you tell the guest that it should
> > > look for PV devices. I'm not familiar with how Xen announces PV
> > > devices to the guest on other architectures, but you have the
> > > choice between providing a full "binding", i.e. a formal specification
> > > in device tree format for the guest to detect PV devices in the
> > > same way as physical or emulated devices, or just providing a single
> > > place in the device tree in which the guest detects the presence
> > > of a xen device bus and then uses hcalls to find the devices on that
> > > bus.
> > 
> > On x86 there is an emulated PCI device which serves as the hooking point
> > for the PV drivers. For ARM I don't think it would be unreasonable to
> > have a DT entry instead. I think it would be fine just represent the
> > root of the "xenbus" and further discovery would occur using the normal
> > xenbus mechanisms (so not a full binding). AIUI for buses which are
> > enumerable this is the preferred DT scheme to use.
> 
> In general that is the case, yes. One could argue that any software
> protocol between Xen and the guest is as good as any other, so it
> makes sense to use the device tree to describe all devices here.
> The counterargument to that is that Linux and other OSs already
> support Xenbus, so there is no need to come up with a new binding.

Right.

> I don't care much either way, but I think it would be good to
> use similar solutions across all hypervisors. The two options
> that I've seen discussed for KVM were to use either a virtual PCI
> bus with individual virtio-pci devices as on the PC, or to
> use the new virtio-mmio driver and individually put virtio devices
> into the device tree.
> 
> > > Another topic is the question whether there are any hcalls that
> > > we should try to standardize before we get another architecture
> > > with multiple conflicting hcall APIs as we have on x86 and powerpc.
> > 
> > The hcall API we are currently targeting is the existing Xen API (at
> > least the generic parts of it). These generally deal with fairly Xen
> > specific concepts like grant tables etc.
> 
> Ok. It would of course still be possible to agree on an argument passing
> convention so that we can share the macros used to issue the hcalls,
> even if the individual commands are all different.

I think it likely that we can all agree on a common calling convention
for N-argument hypercalls. It doubt there are that many useful choices
with conflicting requirements yet strongly compelling advantages.

>  I think I also
> remember talk about the need for a set of hypervisor independent calls
> that everyone should implement, but I can't remember what those were.

I'd not heard of this, maybe I just wasn't looking the right way though.

> Maybe we can split the number space into a range of some generic and
> some vendor specific hcalls?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:48:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:48:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnKY-0006Pe-LK; Wed, 30 Nov 2011 16:48:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVnKX-0006PZ-GP
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:48:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322671662!5595121!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29382 invoked from network); 30 Nov 2011 16:47:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:47:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:47:42 +0000
Message-Id: <4ED66C3B0200007800064709@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:47:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: [Xen-devel] Ping: qemu MSI-X handling patch disposition
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

in http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01161.html 
Haitao proposed a patch to deal with an MSI-X security issue, which you
never commented on but which also never got committed. What's the
situation/plan here?

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 16:48:38 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 16:48:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnKY-0006Pe-LK; Wed, 30 Nov 2011 16:48:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RVnKX-0006PZ-GP
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 16:48:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322671662!5595121!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ0ODc=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29382 invoked from network); 30 Nov 2011 16:47:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 16:47:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 30 Nov 2011 16:47:42 +0000
Message-Id: <4ED66C3B0200007800064709@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 30 Nov 2011 16:47:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: [Xen-devel] Ping: qemu MSI-X handling patch disposition
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

in http://lists.xensource.com/archives/html/xen-devel/2011-09/msg01161.html 
Haitao proposed a patch to deal with an MSI-X security issue, which you
never commented on but which also never got committed. What's the
situation/plan here?

Thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:00:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:00:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnWK-0006d1-Vm; Wed, 30 Nov 2011 17:00:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVnWJ-0006cp-4X
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:00:31 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322672357!46070152!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4063 invoked from network); 30 Nov 2011 16:59:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 16:59:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9213571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 16:59:52 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 30 Nov 2011
	16:59:52 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 30 Nov 2011 16:59:58 +0000
Thread-Topic: [Xen-devel] [PATCH 0 of 6] Add support for a VM generation ID
	virtual device (v2)
Thread-Index: Acyvc2SNQS/atcU160y4DsrB9+37NgADgQIA
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5074@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<CAFB8967.26128%keir.xen@gmail.com>
In-Reply-To: <CAFB8967.26128%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 0 of 6] Add support for a VM generation ID
 virtual device (v2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ok, thanks. I'll re-sync my tree and re-spin the xl/libxl bits.

  Paul

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: 30 November 2011 07:19
> To: Paul Durrant; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 0 of 6] Add support for a VM
> generation ID virtual device (v2)
> 
> On 29/11/2011 10:53, "Paul Durrant" <paul.durrant@citrix.com> wrote:
> 
> > Patch 1 adds the device and an acpi_info field to allow population
> of
> > the ADDR package.
> 
> Applied.
> 
> > Patch 2 adds ctype infrastructure to hvloader in preparation
> for...
> 
> Applied.
> 
> > Patch 3 adds all the code to plumb the value of a new
> 'generation_id'
> > parameter in the VM config through to the VM generation id buffer
> at
> > VM boot time.
> 
> Applied the hvmloader part. Forgot to change the comment that refers
> to libxl, oops! But I didn;t check in the libxl part (it didn't
> apply cleanly to tip anyway).
> 
> > Patch 4 adds an implementation of sprintf() to hvmloader.
> 
> Applied (inc. snprintf update).
> 
> > Patch 5 adds an implementation of xenstore-write to hvmloader.
> 
> Applied (inc. incremental fix).
> 
> > Patch 6 adds support for tracking the address of the VM generation
> id
> > buffer (via xenstore) across save/restore or migrate and updating
> the
> > value of the buffer with the value from the VM config file.
> 
> Applied the hvmloader part.
> 
> In summary, all the hvmloader changes are in. A toolstack maintainer
> should check in the other toolstack parts.
> 
>  -- Keir
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:00:57 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:00:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnWK-0006d1-Vm; Wed, 30 Nov 2011 17:00:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVnWJ-0006cp-4X
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:00:31 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322672357!46070152!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4063 invoked from network); 30 Nov 2011 16:59:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 16:59:17 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315180800"; 
   d="scan'208";a="9213571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 16:59:52 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 30 Nov 2011
	16:59:52 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Wed, 30 Nov 2011 16:59:58 +0000
Thread-Topic: [Xen-devel] [PATCH 0 of 6] Add support for a VM generation ID
	virtual device (v2)
Thread-Index: Acyvc2SNQS/atcU160y4DsrB9+37NgADgQIA
Message-ID: <291EDFCB1E9E224A99088639C4762022B5988E5074@LONPMAILBOX01.citrite.net>
References: <patchbomb.1322563998@cosworth.uk.xensource.com>
	<CAFB8967.26128%keir.xen@gmail.com>
In-Reply-To: <CAFB8967.26128%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 0 of 6] Add support for a VM generation ID
 virtual device (v2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ok, thanks. I'll re-sync my tree and re-spin the xl/libxl bits.

  Paul

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: 30 November 2011 07:19
> To: Paul Durrant; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 0 of 6] Add support for a VM
> generation ID virtual device (v2)
> 
> On 29/11/2011 10:53, "Paul Durrant" <paul.durrant@citrix.com> wrote:
> 
> > Patch 1 adds the device and an acpi_info field to allow population
> of
> > the ADDR package.
> 
> Applied.
> 
> > Patch 2 adds ctype infrastructure to hvloader in preparation
> for...
> 
> Applied.
> 
> > Patch 3 adds all the code to plumb the value of a new
> 'generation_id'
> > parameter in the VM config through to the VM generation id buffer
> at
> > VM boot time.
> 
> Applied the hvmloader part. Forgot to change the comment that refers
> to libxl, oops! But I didn;t check in the libxl part (it didn't
> apply cleanly to tip anyway).
> 
> > Patch 4 adds an implementation of sprintf() to hvmloader.
> 
> Applied (inc. snprintf update).
> 
> > Patch 5 adds an implementation of xenstore-write to hvmloader.
> 
> Applied (inc. incremental fix).
> 
> > Patch 6 adds support for tracking the address of the VM generation
> id
> > buffer (via xenstore) across save/restore or migrate and updating
> the
> > value of the buffer with the value from the VM config file.
> 
> Applied the hvmloader part.
> 
> In summary, all the hvmloader changes are in. A toolstack maintainer
> should check in the other toolstack parts.
> 
>  -- Keir
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:03:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnYs-0006kd-Ii; Wed, 30 Nov 2011 17:03:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVnYr-0006kM-Q8
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:03:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322672550!5649637!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30086 invoked from network); 30 Nov 2011 17:02:31 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 17:02:31 -0000
Received: by vcbfo1 with SMTP id fo1so773634vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 09:02:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=dheWv1NiESHpf7iNNW3lZVRIFUUSNsALF5nl0+Oifh4=;
	b=LEL9GXrA0a3wXnqpe1u6b2RsK+OjsrKPa1Ee/hQmXAAPTmrTBMAa66hlLortjm0vui
	ovGsch33astJiBW0YxlPFQgkI9JXOEuMUKqGmnVPMCZBpJbfW383+dyagwqGsC9Tyohq
	f5IaE+QZnJxXGO0G8+tWszNsq81/Rl3dAI2u0=
Received: by 10.182.139.4 with SMTP id qu4mr613117obb.13.1322672549872;
	Wed, 30 Nov 2011 09:02:29 -0800 (PST)
Received: from [206.87.107.190] (dhcp-0-27-10-2e-fa-f8.ubcvisitor.wifi.ubc.ca.
	[206.87.107.190])
	by mx.google.com with ESMTPS id l7sm591853obo.0.2011.11.30.09.02.27
	(version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 09:02:28 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 30 Nov 2011 09:02:25 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAFBA1A1.26152%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0/4] x86: emulator improvements
Thread-Index: AcyvgdU7Vzh16NCHVEmonfzoxOPbyQ==
In-Reply-To: <4ED66238020000780006466F@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/4] x86: emulator improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/11/2011 16:04, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: x86/emulator: generalize movq emulation (SSE2 and AVX variants)
> 2: x86/emulator: add emulation of SIMD FP moves
> 3: x86/emulator: properly handle lzcnt and tzcnt
> 4: x86/emulator: cleanup
> 
> Note that while AVX support is being included here, I didn't add tests for
> VEX encoded instructions in the tester, since I don't have hardware to
> actually try this out on.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Looks good.

Acked-by: Keir Fraser <keir@xen.org>

> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:03:26 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnYs-0006kd-Ii; Wed, 30 Nov 2011 17:03:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVnYr-0006kM-Q8
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:03:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322672550!5649637!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30086 invoked from network); 30 Nov 2011 17:02:31 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 17:02:31 -0000
Received: by vcbfo1 with SMTP id fo1so773634vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 09:02:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=dheWv1NiESHpf7iNNW3lZVRIFUUSNsALF5nl0+Oifh4=;
	b=LEL9GXrA0a3wXnqpe1u6b2RsK+OjsrKPa1Ee/hQmXAAPTmrTBMAa66hlLortjm0vui
	ovGsch33astJiBW0YxlPFQgkI9JXOEuMUKqGmnVPMCZBpJbfW383+dyagwqGsC9Tyohq
	f5IaE+QZnJxXGO0G8+tWszNsq81/Rl3dAI2u0=
Received: by 10.182.139.4 with SMTP id qu4mr613117obb.13.1322672549872;
	Wed, 30 Nov 2011 09:02:29 -0800 (PST)
Received: from [206.87.107.190] (dhcp-0-27-10-2e-fa-f8.ubcvisitor.wifi.ubc.ca.
	[206.87.107.190])
	by mx.google.com with ESMTPS id l7sm591853obo.0.2011.11.30.09.02.27
	(version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 09:02:28 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 30 Nov 2011 09:02:25 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAFBA1A1.26152%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0/4] x86: emulator improvements
Thread-Index: AcyvgdU7Vzh16NCHVEmonfzoxOPbyQ==
In-Reply-To: <4ED66238020000780006466F@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/4] x86: emulator improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/11/2011 16:04, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: x86/emulator: generalize movq emulation (SSE2 and AVX variants)
> 2: x86/emulator: add emulation of SIMD FP moves
> 3: x86/emulator: properly handle lzcnt and tzcnt
> 4: x86/emulator: cleanup
> 
> Note that while AVX support is being included here, I didn't add tests for
> VEX encoded instructions in the tester, since I don't have hardware to
> actually try this out on.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Looks good.

Acked-by: Keir Fraser <keir@xen.org>

> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:06:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnbt-0006yt-7W; Wed, 30 Nov 2011 17:06:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVnbr-0006yP-Sw
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:06:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322672735!5663868!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5141 invoked from network); 30 Nov 2011 17:05:36 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 17:05:36 -0000
Received: by vcbfo1 with SMTP id fo1so779089vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 09:05:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=S0i7u7kgUNInx6ECxJltvQeYs5nPUHswYZDs8FrWDgo=;
	b=mqvZciGlnV/PItmNptWEznyugpKvvDi+pV14Sdg5OLtnB30aJTJdrWyVYh4ihc7vaO
	3ApuUoaCO1WR1E1DG4gbvtZoJKXyiYcoBV5oX3NXax3hR0vr9TH5s1lB9Yg0WkPUB6tg
	iAm3YEoVGZiw7HlE8mlaEQBw+61+QTVsmWOYg=
Received: by 10.182.152.65 with SMTP id uw1mr609784obb.10.1322672735115;
	Wed, 30 Nov 2011 09:05:35 -0800 (PST)
Received: from [206.87.107.190] (dhcp-0-27-10-2e-fa-f8.ubcvisitor.wifi.ubc.ca.
	[206.87.107.190])
	by mx.google.com with ESMTPS id q10sm3888761obv.1.2011.11.30.09.05.33
	(version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 09:05:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 30 Nov 2011 09:05:29 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAFBA259.26155%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
	(pre-Dom0) loading
Thread-Index: AcyvgkLnrk7LwPES506Cnfo1RbDXnQ==
In-Reply-To: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/11/2011 16:27, "Jan Beulich" <JBeulich@suse.com> wrote:

> 
> In order to not convert the spin_lock() in microcode_update_cpu() (and
> then obviously also all other uses on microcode_mutex) to
> spin_lock_irqsave() (which would be undesirable for the hypercall
> context in which the function also runs), the boot time handling gets
> done using a tasklet (instead of using on_selected_cpus()).

Can you explain this some more? Why would the conversion to
spin_lock_irqsave be required when spin_lock is sufficient for current usage
from dom0 hypercall?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:06:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:06:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnbt-0006yt-7W; Wed, 30 Nov 2011 17:06:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RVnbr-0006yP-Sw
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:06:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322672735!5663868!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=DATE_IN_PAST_06_12,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5141 invoked from network); 30 Nov 2011 17:05:36 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 17:05:36 -0000
Received: by vcbfo1 with SMTP id fo1so779089vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 30 Nov 2011 09:05:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=S0i7u7kgUNInx6ECxJltvQeYs5nPUHswYZDs8FrWDgo=;
	b=mqvZciGlnV/PItmNptWEznyugpKvvDi+pV14Sdg5OLtnB30aJTJdrWyVYh4ihc7vaO
	3ApuUoaCO1WR1E1DG4gbvtZoJKXyiYcoBV5oX3NXax3hR0vr9TH5s1lB9Yg0WkPUB6tg
	iAm3YEoVGZiw7HlE8mlaEQBw+61+QTVsmWOYg=
Received: by 10.182.152.65 with SMTP id uw1mr609784obb.10.1322672735115;
	Wed, 30 Nov 2011 09:05:35 -0800 (PST)
Received: from [206.87.107.190] (dhcp-0-27-10-2e-fa-f8.ubcvisitor.wifi.ubc.ca.
	[206.87.107.190])
	by mx.google.com with ESMTPS id q10sm3888761obv.1.2011.11.30.09.05.33
	(version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 09:05:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 30 Nov 2011 09:05:29 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CAFBA259.26155%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
	(pre-Dom0) loading
Thread-Index: AcyvgkLnrk7LwPES506Cnfo1RbDXnQ==
In-Reply-To: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
 (pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/11/2011 16:27, "Jan Beulich" <JBeulich@suse.com> wrote:

> 
> In order to not convert the spin_lock() in microcode_update_cpu() (and
> then obviously also all other uses on microcode_mutex) to
> spin_lock_irqsave() (which would be undesirable for the hypercall
> context in which the function also runs), the boot time handling gets
> done using a tasklet (instead of using on_selected_cpus()).

Can you explain this some more? Why would the conversion to
spin_lock_irqsave be required when spin_lock is sufficient for current usage
from dom0 hypercall?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:08:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVndU-00075L-Ox; Wed, 30 Nov 2011 17:07:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <niall.fleming@webanywhere.co.uk>) id 1RVndT-00074l-1Y
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:07:55 +0000
X-Env-Sender: niall.fleming@webanywhere.co.uk
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322672835!5358620!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzU3NjY=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzU3NjY=\n, HTML_40_50, HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18281 invoked from network); 30 Nov 2011 17:07:15 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187) by server-5.tower-182.messagelabs.com with SMTP;
	30 Nov 2011 17:07:15 -0000
Received: from [192.168.80.60] (host81-130-62-168.in-addr.btopenworld.com
	[81.130.62.168])
	by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis)
	id 0LlJ1m-1Qv5h12aOs-00b9Te; Wed, 30 Nov 2011 18:06:59 +0100
Message-ID: <4ED662B0.8060105@webanywhere.co.uk>
Date: Wed, 30 Nov 2011 17:06:56 +0000
From: Niall Fleming <niall.fleming@webanywhere.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>
	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
In-Reply-To: <20111116142604.GA7476@phenom.dumpdata.com>
Content-Type: multipart/mixed; boundary="------------090409030509090602080107"
X-Provags-ID: V02:K0:yO/yh9FtwdMNpbZ0T4ChGiot4IzEmkdtKZB7sNzYR6i
	8XlXhjd9DgeXAqfctR6lWBBw0y+XNSG1wo5Cg1k8mcDK5htCwX
	M7yMYgAJxdVETpKC64x3zEdifJsNklyi79UKySi7mivo/I1sRr
	Ja49feH+dl+2prx2G8JLDeUmzuZPn446Wuq5iLwyWYVGnQGME2
	UT199mkqn/nSdTmBFOKJy/Uv2MwdV1o8wKHtct3cHvTxMkz9/C
	/oY5Gx83vr2f1pCs5hHUkkZLehjLQzzy3FMGdxdAIbF1jOjOhN
	Jz/DO1TFrJ/5ypPtIZNOzXQZij0zNvQDr6aBNnnb2Cmdztv+Ey
	GXIXfau/ngLjFy2e4bsc1DLYvMbQ8jaJJ53E4Cpwd
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	keir.xen@gmail.com, Jan Beulich <JBeulich@suse.com>,
	pbonzini@redhat.com, lersek@redhat.com
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------090409030509090602080107
Content-Type: multipart/alternative;
 boundary="------------040106090902070402050703"


--------------040106090902070402050703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Another week, and no response?

ping?

Please?

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>> Right. With those patches too (he used the xen-settime patch set which has it).
>>> The hypercall is done (and the do_settime gets called) and the results are saved
>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>
>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>> existing guests.
>>>
>>> If you launch a new guest after the 'hwclock', the new guests
>>> retains the old wallclock time.
>> Existing (pvops) guests shouldn't see updated wallclock time, because
>> they never look at the hypervisor's wallclock after boot time.
>>
>> It's surprising that new guests don't see the updated wallclock though.
>> That sounds like a Xen issue.
> <nods>  That is what I think is happening here.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

--------------040106090902070402050703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Another week, and no response?<br>
    <br>
    ping?<br>
    <br>
    Please?<br>
    <div class="moz-signature"><br>
      <b>Niall Fleming BSc. (Hons)</b><br>
      Systems Administrator<br>
      Webanywhere Limited<br>
      <br>
      Phone: 0800 862 0131 Ext: 203<br>
      Web: <a class="moz-txt-link-freetext"
        href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a><br>
      <br>
      Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB<br>
      Registered in England with company number 4881346</div>
    <br>
    On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
    <blockquote cite="mid:20111116142604.GA7476@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Right. With those patches too (he used the xen-settime patch set which has it).
The hypercall is done (and the do_settime gets called) and the results are saved
in the RTC. And the wc_sec and wc_nsec are updated and propagated.

The problem is that wc_sec and wc_nsec are only propagated to the
existing guests.

If you launch a new guest after the 'hwclock', the new guests
retains the old wallclock time.
</pre>
        </blockquote>
        <pre wrap="">Existing (pvops) guests shouldn't see updated wallclock time, because
they never look at the hypervisor's wallclock after boot time.

It's surprising that new guests don't see the updated wallclock though. 
That sounds like a Xen issue.
</pre>
      </blockquote>
      <pre wrap="">&lt;nods&gt; That is what I think is happening here.

_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
<a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>
</pre>
    </blockquote>
  </body>
</html>

--------------040106090902070402050703--

--------------090409030509090602080107
Content-Type: text/plain;
 name="Attached Message Part"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Attached Message Part"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel


--------------090409030509090602080107
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------090409030509090602080107--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:08:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVndU-00075L-Ox; Wed, 30 Nov 2011 17:07:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <niall.fleming@webanywhere.co.uk>) id 1RVndT-00074l-1Y
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:07:55 +0000
X-Env-Sender: niall.fleming@webanywhere.co.uk
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322672835!5358620!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzU3NjY=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzU3NjY=\n, HTML_40_50, HTML_MESSAGE
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18281 invoked from network); 30 Nov 2011 17:07:15 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187) by server-5.tower-182.messagelabs.com with SMTP;
	30 Nov 2011 17:07:15 -0000
Received: from [192.168.80.60] (host81-130-62-168.in-addr.btopenworld.com
	[81.130.62.168])
	by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis)
	id 0LlJ1m-1Qv5h12aOs-00b9Te; Wed, 30 Nov 2011 18:06:59 +0100
Message-ID: <4ED662B0.8060105@webanywhere.co.uk>
Date: Wed, 30 Nov 2011 17:06:56 +0000
From: Niall Fleming <niall.fleming@webanywhere.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>
	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
In-Reply-To: <20111116142604.GA7476@phenom.dumpdata.com>
Content-Type: multipart/mixed; boundary="------------090409030509090602080107"
X-Provags-ID: V02:K0:yO/yh9FtwdMNpbZ0T4ChGiot4IzEmkdtKZB7sNzYR6i
	8XlXhjd9DgeXAqfctR6lWBBw0y+XNSG1wo5Cg1k8mcDK5htCwX
	M7yMYgAJxdVETpKC64x3zEdifJsNklyi79UKySi7mivo/I1sRr
	Ja49feH+dl+2prx2G8JLDeUmzuZPn446Wuq5iLwyWYVGnQGME2
	UT199mkqn/nSdTmBFOKJy/Uv2MwdV1o8wKHtct3cHvTxMkz9/C
	/oY5Gx83vr2f1pCs5hHUkkZLehjLQzzy3FMGdxdAIbF1jOjOhN
	Jz/DO1TFrJ/5ypPtIZNOzXQZij0zNvQDr6aBNnnb2Cmdztv+Ey
	GXIXfau/ngLjFy2e4bsc1DLYvMbQ8jaJJ53E4Cpwd
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	keir.xen@gmail.com, Jan Beulich <JBeulich@suse.com>,
	pbonzini@redhat.com, lersek@redhat.com
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--------------090409030509090602080107
Content-Type: multipart/alternative;
 boundary="------------040106090902070402050703"


--------------040106090902070402050703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Another week, and no response?

ping?

Please?

*Niall Fleming BSc. (Hons)*
Systems Administrator
Webanywhere Limited

Phone: 0800 862 0131 Ext: 203
Web: http://www.webanywhere.co.uk

Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
Registered in England with company number 4881346

On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
>> On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>> Right. With those patches too (he used the xen-settime patch set which has it).
>>> The hypercall is done (and the do_settime gets called) and the results are saved
>>> in the RTC. And the wc_sec and wc_nsec are updated and propagated.
>>>
>>> The problem is that wc_sec and wc_nsec are only propagated to the
>>> existing guests.
>>>
>>> If you launch a new guest after the 'hwclock', the new guests
>>> retains the old wallclock time.
>> Existing (pvops) guests shouldn't see updated wallclock time, because
>> they never look at the hypervisor's wallclock after boot time.
>>
>> It's surprising that new guests don't see the updated wallclock though.
>> That sounds like a Xen issue.
> <nods>  That is what I think is happening here.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

--------------040106090902070402050703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Another week, and no response?<br>
    <br>
    ping?<br>
    <br>
    Please?<br>
    <div class="moz-signature"><br>
      <b>Niall Fleming BSc. (Hons)</b><br>
      Systems Administrator<br>
      Webanywhere Limited<br>
      <br>
      Phone: 0800 862 0131 Ext: 203<br>
      Web: <a class="moz-txt-link-freetext"
        href="http://www.webanywhere.co.uk">http://www.webanywhere.co.uk</a><br>
      <br>
      Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB<br>
      Registered in England with company number 4881346</div>
    <br>
    On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
    <blockquote cite="mid:20111116142604.GA7476@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Right. With those patches too (he used the xen-settime patch set which has it).
The hypercall is done (and the do_settime gets called) and the results are saved
in the RTC. And the wc_sec and wc_nsec are updated and propagated.

The problem is that wc_sec and wc_nsec are only propagated to the
existing guests.

If you launch a new guest after the 'hwclock', the new guests
retains the old wallclock time.
</pre>
        </blockquote>
        <pre wrap="">Existing (pvops) guests shouldn't see updated wallclock time, because
they never look at the hypervisor's wallclock after boot time.

It's surprising that new guests don't see the updated wallclock though. 
That sounds like a Xen issue.
</pre>
      </blockquote>
      <pre wrap="">&lt;nods&gt; That is what I think is happening here.

_______________________________________________
Xen-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a>
<a class="moz-txt-link-freetext" href="http://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>
</pre>
    </blockquote>
  </body>
</html>

--------------040106090902070402050703--

--------------090409030509090602080107
Content-Type: text/plain;
 name="Attached Message Part"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Attached Message Part"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel


--------------090409030509090602080107
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------090409030509090602080107--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrY-0007O0-BQ; Wed, 30 Nov 2011 17:22:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrW-0007Mp-CH
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322673706!5276718!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDIwMzk5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21343 invoked from network); 30 Nov 2011 17:21:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLcYI022013
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:39 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLbLs025148
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:37 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLWxI019644; Wed, 30 Nov 2011 11:21:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:31 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id DEF3241C34;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL8OB014726;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:21:02 -0500
Message-Id: <1322673664-14642-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4ED66623.00BE,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 6/8] ACPI: processor: override the interface of
	register acpi processor handler for Xen vcpu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Tang Liang <liang.tang@oracle.com>

This patch calls the check which detectes whether to override
the interface to register ACPI processor.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_driver.c |    2 ++
 include/acpi/processor.h        |    4 ++++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 55f0b89..2fec82e 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -815,6 +815,8 @@ static int __init acpi_processor_init(void)
 
 	memset(&errata, 0, sizeof(errata));
 
+	xen_processor_driver_register();
+
 	if (__acpi_processor_register_driver) {
 		result = __acpi_processor_register_driver();
 		if (result < 0)
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index 969cbc9..cf53ed8 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -283,6 +283,10 @@ static inline void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
 }
 #endif
 
+/* in processor_xen.c */
+extern void xen_processor_driver_register(void);
+
+
 /* in processor_perflib.c */
 
 #ifdef CONFIG_CPU_FREQ
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:41 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrY-0007O0-BQ; Wed, 30 Nov 2011 17:22:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrW-0007Mp-CH
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1322673706!5276718!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDIwMzk5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21343 invoked from network); 30 Nov 2011 17:21:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLcYI022013
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:39 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLbLs025148
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:37 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLWxI019644; Wed, 30 Nov 2011 11:21:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:31 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id DEF3241C34;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL8OB014726;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:21:02 -0500
Message-Id: <1322673664-14642-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4ED66623.00BE,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 6/8] ACPI: processor: override the interface of
	register acpi processor handler for Xen vcpu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Tang Liang <liang.tang@oracle.com>

This patch calls the check which detectes whether to override
the interface to register ACPI processor.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_driver.c |    2 ++
 include/acpi/processor.h        |    4 ++++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 55f0b89..2fec82e 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -815,6 +815,8 @@ static int __init acpi_processor_init(void)
 
 	memset(&errata, 0, sizeof(errata));
 
+	xen_processor_driver_register();
+
 	if (__acpi_processor_register_driver) {
 		result = __acpi_processor_register_driver();
 		if (result < 0)
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index 969cbc9..cf53ed8 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -283,6 +283,10 @@ static inline void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
 }
 #endif
 
+/* in processor_xen.c */
+extern void xen_processor_driver_register(void);
+
+
 /* in processor_perflib.c */
 
 #ifdef CONFIG_CPU_FREQ
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrY-0007OB-Ro; Wed, 30 Nov 2011 17:22:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrW-0007Mq-Gv
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322673706!6216574!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDIwMzk5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10735 invoked from network); 30 Nov 2011 17:21:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLbb3022002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLaf5025127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:37 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLU4g019618; Wed, 30 Nov 2011 11:21:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:29 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 7478E41C31;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL8Hm014719;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:20:59 -0500
Message-Id: <1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4ED66623.006A,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Tang Liang <liang.tang@oracle.com>

This patch implement __acpi_processor_[un]register_driver helper,
so we can registry override processor driver function. Specifically
the Xen processor driver.

By default the values are set to the native one.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_driver.c |   35 +++++++++++++++++++++++++++++------
 include/acpi/processor.h        |    6 +++++-
 2 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 211c078..55f0b89 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -90,6 +90,11 @@ static const struct acpi_device_id processor_device_ids[] = {
 };
 MODULE_DEVICE_TABLE(acpi, processor_device_ids);
 
+int (*__acpi_processor_register_driver)(void) = acpi_processor_register_driver;
+void (*__acpi_processor_unregister_driver)(void) \
+	= acpi_processor_unregister_driver;
+
+
 static struct acpi_driver acpi_processor_driver = {
 	.name = "processor",
 	.class = ACPI_PROCESSOR_CLASS,
@@ -779,6 +784,22 @@ void acpi_processor_uninstall_hotplug_notify(void)
 	unregister_hotcpu_notifier(&acpi_cpu_notifier);
 }
 
+int acpi_processor_register_driver(void)
+{
+	int result = 0;
+
+	result = acpi_bus_register_driver(&acpi_processor_driver);
+	return result;
+}
+
+void acpi_processor_unregister_driver(void)
+{
+	acpi_bus_unregister_driver(&acpi_processor_driver);
+
+	cpuidle_unregister_driver(&acpi_idle_driver);
+
+	return;
+}
 /*
  * We keep the driver loaded even when ACPI is not running.
  * This is needed for the powernow-k8 driver, that works even without
@@ -794,9 +815,11 @@ static int __init acpi_processor_init(void)
 
 	memset(&errata, 0, sizeof(errata));
 
-	result = acpi_bus_register_driver(&acpi_processor_driver);
-	if (result < 0)
-		return result;
+	if (__acpi_processor_register_driver) {
+		result = __acpi_processor_register_driver();
+		if (result < 0)
+			return result;
+	}
 
 	acpi_processor_install_hotplug_notify();
 
@@ -809,6 +832,7 @@ static int __init acpi_processor_init(void)
 	return 0;
 }
 
+
 static void __exit acpi_processor_exit(void)
 {
 	if (acpi_disabled)
@@ -820,9 +844,8 @@ static void __exit acpi_processor_exit(void)
 
 	acpi_processor_uninstall_hotplug_notify();
 
-	acpi_bus_unregister_driver(&acpi_processor_driver);
-
-	cpuidle_unregister_driver(&acpi_idle_driver);
+	if (__acpi_processor_unregister_driver)
+		__acpi_processor_unregister_driver();
 
 	return;
 }
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index bd99fb6..969cbc9 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -225,6 +225,9 @@ struct acpi_processor_errata {
 	} piix4;
 };
 
+extern int (*__acpi_processor_register_driver)(void);
+extern void (*__acpi_processor_unregister_driver)(void);
+
 extern int acpi_processor_preregister_performance(struct
 						  acpi_processor_performance
 						  __percpu *performance);
@@ -242,7 +245,8 @@ int acpi_processor_notify_smm(struct module *calling_module);
 
 void acpi_processor_install_hotplug_notify(void);
 void acpi_processor_uninstall_hotplug_notify(void);
-
+int acpi_processor_register_driver(void);
+void acpi_processor_unregister_driver(void);
 int acpi_processor_add(struct acpi_device *device);
 int acpi_processor_remove(struct acpi_device *device, int type);
 void acpi_processor_notify(struct acpi_device *device, u32 event);
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrY-0007OB-Ro; Wed, 30 Nov 2011 17:22:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrW-0007Mq-Gv
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1322673706!6216574!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDIwMzk5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10735 invoked from network); 30 Nov 2011 17:21:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLbb3022002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLaf5025127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:37 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLU4g019618; Wed, 30 Nov 2011 11:21:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:29 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 7478E41C31;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL8Hm014719;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:20:59 -0500
Message-Id: <1322673664-14642-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4ED66623.006A,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Tang Liang <liang.tang@oracle.com>

This patch implement __acpi_processor_[un]register_driver helper,
so we can registry override processor driver function. Specifically
the Xen processor driver.

By default the values are set to the native one.

Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_driver.c |   35 +++++++++++++++++++++++++++++------
 include/acpi/processor.h        |    6 +++++-
 2 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 211c078..55f0b89 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -90,6 +90,11 @@ static const struct acpi_device_id processor_device_ids[] = {
 };
 MODULE_DEVICE_TABLE(acpi, processor_device_ids);
 
+int (*__acpi_processor_register_driver)(void) = acpi_processor_register_driver;
+void (*__acpi_processor_unregister_driver)(void) \
+	= acpi_processor_unregister_driver;
+
+
 static struct acpi_driver acpi_processor_driver = {
 	.name = "processor",
 	.class = ACPI_PROCESSOR_CLASS,
@@ -779,6 +784,22 @@ void acpi_processor_uninstall_hotplug_notify(void)
 	unregister_hotcpu_notifier(&acpi_cpu_notifier);
 }
 
+int acpi_processor_register_driver(void)
+{
+	int result = 0;
+
+	result = acpi_bus_register_driver(&acpi_processor_driver);
+	return result;
+}
+
+void acpi_processor_unregister_driver(void)
+{
+	acpi_bus_unregister_driver(&acpi_processor_driver);
+
+	cpuidle_unregister_driver(&acpi_idle_driver);
+
+	return;
+}
 /*
  * We keep the driver loaded even when ACPI is not running.
  * This is needed for the powernow-k8 driver, that works even without
@@ -794,9 +815,11 @@ static int __init acpi_processor_init(void)
 
 	memset(&errata, 0, sizeof(errata));
 
-	result = acpi_bus_register_driver(&acpi_processor_driver);
-	if (result < 0)
-		return result;
+	if (__acpi_processor_register_driver) {
+		result = __acpi_processor_register_driver();
+		if (result < 0)
+			return result;
+	}
 
 	acpi_processor_install_hotplug_notify();
 
@@ -809,6 +832,7 @@ static int __init acpi_processor_init(void)
 	return 0;
 }
 
+
 static void __exit acpi_processor_exit(void)
 {
 	if (acpi_disabled)
@@ -820,9 +844,8 @@ static void __exit acpi_processor_exit(void)
 
 	acpi_processor_uninstall_hotplug_notify();
 
-	acpi_bus_unregister_driver(&acpi_processor_driver);
-
-	cpuidle_unregister_driver(&acpi_idle_driver);
+	if (__acpi_processor_unregister_driver)
+		__acpi_processor_unregister_driver();
 
 	return;
 }
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index bd99fb6..969cbc9 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -225,6 +225,9 @@ struct acpi_processor_errata {
 	} piix4;
 };
 
+extern int (*__acpi_processor_register_driver)(void);
+extern void (*__acpi_processor_unregister_driver)(void);
+
 extern int acpi_processor_preregister_performance(struct
 						  acpi_processor_performance
 						  __percpu *performance);
@@ -242,7 +245,8 @@ int acpi_processor_notify_smm(struct module *calling_module);
 
 void acpi_processor_install_hotplug_notify(void);
 void acpi_processor_uninstall_hotplug_notify(void);
-
+int acpi_processor_register_driver(void);
+void acpi_processor_unregister_driver(void);
 int acpi_processor_add(struct acpi_device *device);
 int acpi_processor_remove(struct acpi_device *device, int type);
 void acpi_processor_notify(struct acpi_device *device, u32 event);
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnra-0007Oy-FI; Wed, 30 Nov 2011 17:22:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrY-0007My-LY
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322673708!5676463!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12091 invoked from network); 30 Nov 2011 17:21:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 17:21:49 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLdiL008429
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:40 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLbKi013980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLWtc019650; Wed, 30 Nov 2011 11:21:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:31 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 0DB3841C35;
	Wed, 30 Nov 2011 12:21:09 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL9dO014727;
	Wed, 30 Nov 2011 12:21:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:21:03 -0500
Message-Id: <1322673664-14642-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4ED66624.00B5,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 7/8] ACPI: xen processor: add PM notification
	interfaces.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

Since cpu power is controlled by VMM in Xen, to provide
that information to the VMM, we have to use hypercall to exchange
power management state between domain with hypervisor.

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/acpi_processor.c |  216 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 216 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/acpi_processor.c b/drivers/xen/acpi_processor.c
index 8fa7914..23730d8 100644
--- a/drivers/xen/acpi_processor.c
+++ b/drivers/xen/acpi_processor.c
@@ -24,6 +24,7 @@
 #include <acpi/processor.h>
 #include <xen/acpi.h>
 
+#include <xen/interface/platform.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
 
@@ -50,4 +51,219 @@ int processor_cntl_xen_notify(struct acpi_processor *pr, int event, int type)
 }
 EXPORT_SYMBOL(processor_cntl_xen_notify);
 
+static inline void xen_convert_pct_reg(struct xen_pct_register *xpct,
+	struct acpi_pct_register *apct)
+{
+	xpct->descriptor = apct->descriptor;
+	xpct->length     = apct->length;
+	xpct->space_id   = apct->space_id;
+	xpct->bit_width  = apct->bit_width;
+	xpct->bit_offset = apct->bit_offset;
+	xpct->reserved   = apct->reserved;
+	xpct->address    = apct->address;
+}
+
+static inline void xen_convert_pss_states(struct xen_processor_px *xpss,
+	struct acpi_processor_px *apss, int state_count)
+{
+	int i;
+	for (i = 0; i < state_count; i++) {
+		xpss->core_frequency     = apss->core_frequency;
+		xpss->power              = apss->power;
+		xpss->transition_latency = apss->transition_latency;
+		xpss->bus_master_latency = apss->bus_master_latency;
+		xpss->control            = apss->control;
+		xpss->status             = apss->status;
+		xpss++;
+		apss++;
+	}
+}
+
+static inline void xen_convert_psd_pack(struct xen_psd_package *xpsd,
+	struct acpi_psd_package *apsd)
+{
+	xpsd->num_entries    = apsd->num_entries;
+	xpsd->revision       = apsd->revision;
+	xpsd->domain         = apsd->domain;
+	xpsd->coord_type     = apsd->coord_type;
+	xpsd->num_processors = apsd->num_processors;
+}
+
+static int xen_cx_notifier(struct acpi_processor *pr, int action)
+{
+	int ret, count = 0, i;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_CX,
+	};
+	struct xen_processor_cx *data, *buf;
+	struct acpi_processor_cx *cx;
+	struct acpi_power_register *reg;
+
+	if (action == PROCESSOR_PM_CHANGE)
+		return -EINVAL;
+
+	/* Convert to Xen defined structure and hypercall */
+	buf = kzalloc(pr->power.count * sizeof(struct xen_processor_cx)\
+		, GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
+	data = buf;
+	for (i = 1; i <= pr->power.count; i++) {
+		cx = &pr->power.states[i];
+		reg = &cx->reg;
+		/* Skip invalid cstate entry */
+		if (!cx->valid)
+			continue;
+
+		data->type = cx->type;
+		data->latency = cx->latency;
+		data->power = cx->power;
+		data->reg.space_id = reg->space_id;
+		data->reg.bit_width = reg->bit_width;
+		data->reg.bit_offset = reg->bit_offset;
+		data->reg.access_size = reg->access_size;
+		data->reg.address = reg->address;
+
+		/* Get dependency relationships, _CSD is not supported yet */
+		data->dpcnt = 0;
+		set_xen_guest_handle(data->dp, NULL);
+
+		data++;
+		count++;
+	}
+
+	if (!count) {
+		printk(KERN_ERR "No available Cx info for cpu %d\n",
+				pr->acpi_id);
+		kfree(buf);
+		return -EINVAL;
+	}
+
+	op.u.set_pminfo.power.count = count;
+	op.u.set_pminfo.power.flags.bm_control = pr->flags.bm_control;
+	op.u.set_pminfo.power.flags.bm_check = pr->flags.bm_check;
+	op.u.set_pminfo.power.flags.has_cst = pr->flags.has_cst;
+	op.u.set_pminfo.power.flags.power_setup_done =
+		pr->flags.power_setup_done;
+
+	set_xen_guest_handle(op.u.set_pminfo.power.states, buf);
+	ret = HYPERVISOR_dom0_op(&op);
+	kfree(buf);
+	return ret;
+}
+
+static int xen_px_notifier(struct acpi_processor *pr, int action)
+{
+	int ret = -EINVAL;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+	struct xen_processor_performance *perf;
+	struct xen_processor_px *states = NULL;
+	struct acpi_processor_performance *px;
+	struct acpi_psd_package *pdomain;
+
+	if (!pr)
+		return -EINVAL;
+
+	perf = &op.u.set_pminfo.perf;
+	px = pr->performance;
+
+	switch (action) {
+	case PROCESSOR_PM_CHANGE:
+		/* ppc dynamic handle */
+		perf->flags = XEN_PX_PPC;
+		perf->platform_limit = pr->performance_platform_limit;
+
+		ret = HYPERVISOR_dom0_op(&op);
+		break;
+
+	case PROCESSOR_PM_INIT:
+		/* px normal init */
+		perf->flags = XEN_PX_PPC |
+			      XEN_PX_PCT |
+			      XEN_PX_PSS |
+			      XEN_PX_PSD;
+
+		/* ppc */
+		perf->platform_limit = pr->performance_platform_limit;
+
+		/* pct */
+		xen_convert_pct_reg(&perf->control_register,
+				&px->control_register);
+		xen_convert_pct_reg(&perf->status_register,
+				&px->status_register);
+
+		/* pss */
+		perf->state_count = px->state_count;
+		states = kzalloc(px->state_count*\
+			sizeof(struct xen_processor_px), GFP_KERNEL);
+		if (!states)
+			return -ENOMEM;
+		xen_convert_pss_states(states, px->states, px->state_count);
+		set_xen_guest_handle(perf->states, states);
+
+		/* psd */
+		pdomain = &px->domain_info;
+		/* Some sanity check */
+		if ((pdomain->revision != ACPI_PSD_REV0_REVISION) ||
+			(pdomain->num_entries != ACPI_PSD_REV0_ENTRIES) ||
+			((pdomain->coord_type != DOMAIN_COORD_TYPE_SW_ALL) &&
+			(pdomain->coord_type != DOMAIN_COORD_TYPE_SW_ANY) &&
+			(pdomain->coord_type != DOMAIN_COORD_TYPE_HW_ALL))) {
+			ret = -EINVAL;
+			kfree(states);
+			break;
+		}
+
+		xen_convert_psd_pack(&perf->domain_info, pdomain);
+		if (pdomain->coord_type == DOMAIN_COORD_TYPE_SW_ALL)
+			perf->shared_type = CPUFREQ_SHARED_TYPE_ALL;
+		else if (pdomain->coord_type == DOMAIN_COORD_TYPE_SW_ANY)
+			perf->shared_type = CPUFREQ_SHARED_TYPE_ANY;
+		else if (pdomain->coord_type == DOMAIN_COORD_TYPE_HW_ALL)
+			perf->shared_type = CPUFREQ_SHARED_TYPE_HW;
+		else {
+			ret = -EINVAL;
+			kfree(states);
+			break;
+		}
+
+		ret = HYPERVISOR_dom0_op(&op);
+		kfree(states);
+		break;
+
+	default:
+		break;
+	}
+
+	return ret;
+}
+
+static int __init xen_acpi_processor_extcntl_init(void)
+{
+	unsigned int pmbits;
+
+	/* Only xen dom0 is allowed to handle ACPI processor info */
+	if (!xen_initial_domain())
+		return 0;
+
+	pmbits = (xen_start_info->flags & SIF_PM_MASK) >> 8;
+
+	if (pmbits & XEN_PROCESSOR_PM_CX)
+		xen_ops.pm_ops[PM_TYPE_IDLE] = xen_cx_notifier;
+	if (pmbits & XEN_PROCESSOR_PM_PX)
+		xen_ops.pm_ops[PM_TYPE_PERF] = xen_px_notifier;
+
+	return 0;
+}
+
+subsys_initcall(xen_acpi_processor_extcntl_init);
 MODULE_LICENSE("GPL");
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnra-0007Oy-FI; Wed, 30 Nov 2011 17:22:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrY-0007My-LY
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322673708!5676463!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12091 invoked from network); 30 Nov 2011 17:21:49 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 17:21:49 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLdiL008429
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:40 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLbKi013980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLWtc019650; Wed, 30 Nov 2011 11:21:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:31 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 0DB3841C35;
	Wed, 30 Nov 2011 12:21:09 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL9dO014727;
	Wed, 30 Nov 2011 12:21:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:21:03 -0500
Message-Id: <1322673664-14642-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4ED66624.00B5,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 7/8] ACPI: xen processor: add PM notification
	interfaces.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

Since cpu power is controlled by VMM in Xen, to provide
that information to the VMM, we have to use hypercall to exchange
power management state between domain with hypervisor.

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/acpi_processor.c |  216 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 216 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/acpi_processor.c b/drivers/xen/acpi_processor.c
index 8fa7914..23730d8 100644
--- a/drivers/xen/acpi_processor.c
+++ b/drivers/xen/acpi_processor.c
@@ -24,6 +24,7 @@
 #include <acpi/processor.h>
 #include <xen/acpi.h>
 
+#include <xen/interface/platform.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
 
@@ -50,4 +51,219 @@ int processor_cntl_xen_notify(struct acpi_processor *pr, int event, int type)
 }
 EXPORT_SYMBOL(processor_cntl_xen_notify);
 
+static inline void xen_convert_pct_reg(struct xen_pct_register *xpct,
+	struct acpi_pct_register *apct)
+{
+	xpct->descriptor = apct->descriptor;
+	xpct->length     = apct->length;
+	xpct->space_id   = apct->space_id;
+	xpct->bit_width  = apct->bit_width;
+	xpct->bit_offset = apct->bit_offset;
+	xpct->reserved   = apct->reserved;
+	xpct->address    = apct->address;
+}
+
+static inline void xen_convert_pss_states(struct xen_processor_px *xpss,
+	struct acpi_processor_px *apss, int state_count)
+{
+	int i;
+	for (i = 0; i < state_count; i++) {
+		xpss->core_frequency     = apss->core_frequency;
+		xpss->power              = apss->power;
+		xpss->transition_latency = apss->transition_latency;
+		xpss->bus_master_latency = apss->bus_master_latency;
+		xpss->control            = apss->control;
+		xpss->status             = apss->status;
+		xpss++;
+		apss++;
+	}
+}
+
+static inline void xen_convert_psd_pack(struct xen_psd_package *xpsd,
+	struct acpi_psd_package *apsd)
+{
+	xpsd->num_entries    = apsd->num_entries;
+	xpsd->revision       = apsd->revision;
+	xpsd->domain         = apsd->domain;
+	xpsd->coord_type     = apsd->coord_type;
+	xpsd->num_processors = apsd->num_processors;
+}
+
+static int xen_cx_notifier(struct acpi_processor *pr, int action)
+{
+	int ret, count = 0, i;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_CX,
+	};
+	struct xen_processor_cx *data, *buf;
+	struct acpi_processor_cx *cx;
+	struct acpi_power_register *reg;
+
+	if (action == PROCESSOR_PM_CHANGE)
+		return -EINVAL;
+
+	/* Convert to Xen defined structure and hypercall */
+	buf = kzalloc(pr->power.count * sizeof(struct xen_processor_cx)\
+		, GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
+	data = buf;
+	for (i = 1; i <= pr->power.count; i++) {
+		cx = &pr->power.states[i];
+		reg = &cx->reg;
+		/* Skip invalid cstate entry */
+		if (!cx->valid)
+			continue;
+
+		data->type = cx->type;
+		data->latency = cx->latency;
+		data->power = cx->power;
+		data->reg.space_id = reg->space_id;
+		data->reg.bit_width = reg->bit_width;
+		data->reg.bit_offset = reg->bit_offset;
+		data->reg.access_size = reg->access_size;
+		data->reg.address = reg->address;
+
+		/* Get dependency relationships, _CSD is not supported yet */
+		data->dpcnt = 0;
+		set_xen_guest_handle(data->dp, NULL);
+
+		data++;
+		count++;
+	}
+
+	if (!count) {
+		printk(KERN_ERR "No available Cx info for cpu %d\n",
+				pr->acpi_id);
+		kfree(buf);
+		return -EINVAL;
+	}
+
+	op.u.set_pminfo.power.count = count;
+	op.u.set_pminfo.power.flags.bm_control = pr->flags.bm_control;
+	op.u.set_pminfo.power.flags.bm_check = pr->flags.bm_check;
+	op.u.set_pminfo.power.flags.has_cst = pr->flags.has_cst;
+	op.u.set_pminfo.power.flags.power_setup_done =
+		pr->flags.power_setup_done;
+
+	set_xen_guest_handle(op.u.set_pminfo.power.states, buf);
+	ret = HYPERVISOR_dom0_op(&op);
+	kfree(buf);
+	return ret;
+}
+
+static int xen_px_notifier(struct acpi_processor *pr, int action)
+{
+	int ret = -EINVAL;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+	struct xen_processor_performance *perf;
+	struct xen_processor_px *states = NULL;
+	struct acpi_processor_performance *px;
+	struct acpi_psd_package *pdomain;
+
+	if (!pr)
+		return -EINVAL;
+
+	perf = &op.u.set_pminfo.perf;
+	px = pr->performance;
+
+	switch (action) {
+	case PROCESSOR_PM_CHANGE:
+		/* ppc dynamic handle */
+		perf->flags = XEN_PX_PPC;
+		perf->platform_limit = pr->performance_platform_limit;
+
+		ret = HYPERVISOR_dom0_op(&op);
+		break;
+
+	case PROCESSOR_PM_INIT:
+		/* px normal init */
+		perf->flags = XEN_PX_PPC |
+			      XEN_PX_PCT |
+			      XEN_PX_PSS |
+			      XEN_PX_PSD;
+
+		/* ppc */
+		perf->platform_limit = pr->performance_platform_limit;
+
+		/* pct */
+		xen_convert_pct_reg(&perf->control_register,
+				&px->control_register);
+		xen_convert_pct_reg(&perf->status_register,
+				&px->status_register);
+
+		/* pss */
+		perf->state_count = px->state_count;
+		states = kzalloc(px->state_count*\
+			sizeof(struct xen_processor_px), GFP_KERNEL);
+		if (!states)
+			return -ENOMEM;
+		xen_convert_pss_states(states, px->states, px->state_count);
+		set_xen_guest_handle(perf->states, states);
+
+		/* psd */
+		pdomain = &px->domain_info;
+		/* Some sanity check */
+		if ((pdomain->revision != ACPI_PSD_REV0_REVISION) ||
+			(pdomain->num_entries != ACPI_PSD_REV0_ENTRIES) ||
+			((pdomain->coord_type != DOMAIN_COORD_TYPE_SW_ALL) &&
+			(pdomain->coord_type != DOMAIN_COORD_TYPE_SW_ANY) &&
+			(pdomain->coord_type != DOMAIN_COORD_TYPE_HW_ALL))) {
+			ret = -EINVAL;
+			kfree(states);
+			break;
+		}
+
+		xen_convert_psd_pack(&perf->domain_info, pdomain);
+		if (pdomain->coord_type == DOMAIN_COORD_TYPE_SW_ALL)
+			perf->shared_type = CPUFREQ_SHARED_TYPE_ALL;
+		else if (pdomain->coord_type == DOMAIN_COORD_TYPE_SW_ANY)
+			perf->shared_type = CPUFREQ_SHARED_TYPE_ANY;
+		else if (pdomain->coord_type == DOMAIN_COORD_TYPE_HW_ALL)
+			perf->shared_type = CPUFREQ_SHARED_TYPE_HW;
+		else {
+			ret = -EINVAL;
+			kfree(states);
+			break;
+		}
+
+		ret = HYPERVISOR_dom0_op(&op);
+		kfree(states);
+		break;
+
+	default:
+		break;
+	}
+
+	return ret;
+}
+
+static int __init xen_acpi_processor_extcntl_init(void)
+{
+	unsigned int pmbits;
+
+	/* Only xen dom0 is allowed to handle ACPI processor info */
+	if (!xen_initial_domain())
+		return 0;
+
+	pmbits = (xen_start_info->flags & SIF_PM_MASK) >> 8;
+
+	if (pmbits & XEN_PROCESSOR_PM_CX)
+		xen_ops.pm_ops[PM_TYPE_IDLE] = xen_cx_notifier;
+	if (pmbits & XEN_PROCESSOR_PM_PX)
+		xen_ops.pm_ops[PM_TYPE_PERF] = xen_px_notifier;
+
+	return 0;
+}
+
+subsys_initcall(xen_acpi_processor_extcntl_init);
 MODULE_LICENSE("GPL");
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrZ-0007Of-Qw; Wed, 30 Nov 2011 17:22:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrX-0007Ms-Dj
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322673707!3746483!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4290 invoked from network); 30 Nov 2011 17:21:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:48 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLcwv008410
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLb0t005529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:37 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLUcZ000898; Wed, 30 Nov 2011 11:21:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:30 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 9760E41C32;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL8er014722;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:21:00 -0500
Message-Id: <1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4ED66623.007B,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 4/8] ACPI: processor: Don't setup cpu idle
	driver and handler when we do not want them.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

This patch inhibits processing of the CPU idle handler if it is not
set to the appropiate one. This is needed by the Xen processor driver
which, while still needing processor details, wants to use the default_idle
call (which makes a yield hypercall).

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_idle.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index d88974a..0ad347f 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1127,7 +1127,7 @@ int acpi_processor_hotplug(struct acpi_processor *pr)
 	cpuidle_pause_and_lock();
 	cpuidle_disable_device(&pr->power.dev);
 	acpi_processor_get_power_info(pr);
-	if (pr->flags.power) {
+	if (pr->flags.power  && (cpuidle_get_driver() == &acpi_idle_driver)) {
 		acpi_processor_setup_cpuidle_cx(pr);
 		ret = cpuidle_enable_device(&pr->power.dev);
 	}
@@ -1183,7 +1183,8 @@ int acpi_processor_cst_has_changed(struct acpi_processor *pr)
 			if (!_pr || !_pr->flags.power_setup_done)
 				continue;
 			acpi_processor_get_power_info(_pr);
-			if (_pr->flags.power) {
+			if (_pr->flags.power && (cpuidle_get_driver()
+						== &acpi_idle_driver)) {
 				acpi_processor_setup_cpuidle_cx(_pr);
 				cpuidle_enable_device(&_pr->power.dev);
 			}
@@ -1237,7 +1238,8 @@ int __cpuinit acpi_processor_power_init(struct acpi_processor *pr,
 	 * Note that we use previously set idle handler will be used on
 	 * platforms that only support C1.
 	 */
-	if (pr->flags.power) {
+	if (pr->flags.power && (__acpi_processor_register_driver ==
+				acpi_processor_register_driver)) {
 		/* Register acpi_idle_driver if not already registered */
 		if (!acpi_processor_registered) {
 			acpi_processor_setup_cpuidle_states(pr);
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrZ-0007Of-Qw; Wed, 30 Nov 2011 17:22:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrX-0007Ms-Dj
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1322673707!3746483!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4290 invoked from network); 30 Nov 2011 17:21:48 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:48 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLcwv008410
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLb0t005529
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:37 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLUcZ000898; Wed, 30 Nov 2011 11:21:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:30 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 9760E41C32;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL8er014722;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:21:00 -0500
Message-Id: <1322673664-14642-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4ED66623.007B,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 4/8] ACPI: processor: Don't setup cpu idle
	driver and handler when we do not want them.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

This patch inhibits processing of the CPU idle handler if it is not
set to the appropiate one. This is needed by the Xen processor driver
which, while still needing processor details, wants to use the default_idle
call (which makes a yield hypercall).

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_idle.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index d88974a..0ad347f 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1127,7 +1127,7 @@ int acpi_processor_hotplug(struct acpi_processor *pr)
 	cpuidle_pause_and_lock();
 	cpuidle_disable_device(&pr->power.dev);
 	acpi_processor_get_power_info(pr);
-	if (pr->flags.power) {
+	if (pr->flags.power  && (cpuidle_get_driver() == &acpi_idle_driver)) {
 		acpi_processor_setup_cpuidle_cx(pr);
 		ret = cpuidle_enable_device(&pr->power.dev);
 	}
@@ -1183,7 +1183,8 @@ int acpi_processor_cst_has_changed(struct acpi_processor *pr)
 			if (!_pr || !_pr->flags.power_setup_done)
 				continue;
 			acpi_processor_get_power_info(_pr);
-			if (_pr->flags.power) {
+			if (_pr->flags.power && (cpuidle_get_driver()
+						== &acpi_idle_driver)) {
 				acpi_processor_setup_cpuidle_cx(_pr);
 				cpuidle_enable_device(&_pr->power.dev);
 			}
@@ -1237,7 +1238,8 @@ int __cpuinit acpi_processor_power_init(struct acpi_processor *pr,
 	 * Note that we use previously set idle handler will be used on
 	 * platforms that only support C1.
 	 */
-	if (pr->flags.power) {
+	if (pr->flags.power && (__acpi_processor_register_driver ==
+				acpi_processor_register_driver)) {
 		/* Register acpi_idle_driver if not already registered */
 		if (!acpi_processor_registered) {
 			acpi_processor_setup_cpuidle_states(pr);
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrZ-0007OS-B0; Wed, 30 Nov 2011 17:22:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrW-0007Mr-Ja
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322673706!5338968!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4670 invoked from network); 30 Nov 2011 17:21:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLd54008426
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLbL4025169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLWMk000914; Wed, 30 Nov 2011 11:21:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:31 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 31B1E41C36;
	Wed, 30 Nov 2011 12:21:09 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL9oV014728;
	Wed, 30 Nov 2011 12:21:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:21:04 -0500
Message-Id: <1322673664-14642-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4ED66624.008E,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 8/8] ACPI: xen processor: set ignore_ppc to
	handle PPC event for Xen vcpu.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

Xen acpi processor does not CPUFREQ_START, hence we we need to set
ignore_ppc to handle PPC events.

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_perflib.c |    2 +-
 drivers/acpi/processor_xen.c     |    2 ++
 include/acpi/processor.h         |    1 +
 3 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 22c6195..e622a0d 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -65,7 +65,7 @@ static DEFINE_MUTEX(performance_mutex);
  *  0 -> cpufreq low level drivers initialized -> consider _PPC values
  *  1 -> ignore _PPC totally -> forced by user through boot param
  */
-static int ignore_ppc = -1;
+int ignore_ppc = -1;
 module_param(ignore_ppc, int, 0644);
 MODULE_PARM_DESC(ignore_ppc, "If the frequency of your machine gets wrongly" \
 		 "limited by BIOS, this should help");
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index fc3cc0b..a87b222 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -217,12 +217,14 @@ int xen_acpi_processor_init(void)
 	if (result < 0)
 		return result;
 		/* mark ready for handling ppc */
+	ignore_ppc = 0;
 
 	return 0;
 }
 
 void xen_acpi_processor_exit(void)
 {
+	ignore_ppc = -1;
 
 	acpi_bus_unregister_driver(&xen_acpi_processor_driver);
 }
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index cf53ed8..1380bb7 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -290,6 +290,7 @@ extern void xen_processor_driver_register(void);
 /* in processor_perflib.c */
 
 #ifdef CONFIG_CPU_FREQ
+extern int ignore_ppc;
 void acpi_processor_ppc_init(void);
 void acpi_processor_ppc_exit(void);
 int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int event_flag);
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrZ-0007OS-B0; Wed, 30 Nov 2011 17:22:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrW-0007Mr-Ja
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322673706!5338968!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4670 invoked from network); 30 Nov 2011 17:21:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLd54008426
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLbL4025169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLWMk000914; Wed, 30 Nov 2011 11:21:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:31 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 31B1E41C36;
	Wed, 30 Nov 2011 12:21:09 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL9oV014728;
	Wed, 30 Nov 2011 12:21:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:21:04 -0500
Message-Id: <1322673664-14642-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4ED66624.008E,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 8/8] ACPI: xen processor: set ignore_ppc to
	handle PPC event for Xen vcpu.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

Xen acpi processor does not CPUFREQ_START, hence we we need to set
ignore_ppc to handle PPC events.

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_perflib.c |    2 +-
 drivers/acpi/processor_xen.c     |    2 ++
 include/acpi/processor.h         |    1 +
 3 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 22c6195..e622a0d 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -65,7 +65,7 @@ static DEFINE_MUTEX(performance_mutex);
  *  0 -> cpufreq low level drivers initialized -> consider _PPC values
  *  1 -> ignore _PPC totally -> forced by user through boot param
  */
-static int ignore_ppc = -1;
+int ignore_ppc = -1;
 module_param(ignore_ppc, int, 0644);
 MODULE_PARM_DESC(ignore_ppc, "If the frequency of your machine gets wrongly" \
 		 "limited by BIOS, this should help");
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index fc3cc0b..a87b222 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -217,12 +217,14 @@ int xen_acpi_processor_init(void)
 	if (result < 0)
 		return result;
 		/* mark ready for handling ppc */
+	ignore_ppc = 0;
 
 	return 0;
 }
 
 void xen_acpi_processor_exit(void)
 {
+	ignore_ppc = -1;
 
 	acpi_bus_unregister_driver(&xen_acpi_processor_driver);
 }
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index cf53ed8..1380bb7 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -290,6 +290,7 @@ extern void xen_processor_driver_register(void);
 /* in processor_perflib.c */
 
 #ifdef CONFIG_CPU_FREQ
+extern int ignore_ppc;
 void acpi_processor_ppc_init(void);
 void acpi_processor_ppc_exit(void);
 int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int event_flag);
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrb-0007PZ-PQ; Wed, 30 Nov 2011 17:22:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrZ-0007Mz-J9
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322673705!5676459!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDIwMzk5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12135 invoked from network); 30 Nov 2011 17:21:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 17:21:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLbpL022005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLaRg013930
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:36 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLUox019617; Wed, 30 Nov 2011 11:21:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:29 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 27BEE41C2F;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL8ts014713;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:20:57 -0500
Message-Id: <1322673664-14642-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4ED66623.0088,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 1/8] ACPI: processor: export necessary interfaces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

This patch export some necessary functions which parse processor
power management information. The Xen ACPI processor driver uses them.

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_driver.c  |   11 +++--------
 drivers/acpi/processor_perflib.c |    4 ++--
 include/acpi/processor.h         |   10 +++++++++-
 3 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 9d7bc9f..211c078 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -79,9 +79,6 @@ MODULE_AUTHOR("Paul Diefenbaugh");
 MODULE_DESCRIPTION("ACPI Processor Driver");
 MODULE_LICENSE("GPL");
 
-static int acpi_processor_add(struct acpi_device *device);
-static int acpi_processor_remove(struct acpi_device *device, int type);
-static void acpi_processor_notify(struct acpi_device *device, u32 event);
 static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int *p_cpu);
 static int acpi_processor_handle_eject(struct acpi_processor *pr);
 
@@ -378,7 +375,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
 
 static DEFINE_PER_CPU(void *, processor_device_array);
 
-static void acpi_processor_notify(struct acpi_device *device, u32 event)
+void acpi_processor_notify(struct acpi_device *device, u32 event)
 {
 	struct acpi_processor *pr = acpi_driver_data(device);
 	int saved;
@@ -442,7 +439,7 @@ static struct notifier_block acpi_cpu_notifier =
 	    .notifier_call = acpi_cpu_soft_notify,
 };
 
-static int __cpuinit acpi_processor_add(struct acpi_device *device)
+int __cpuinit acpi_processor_add(struct acpi_device *device)
 {
 	struct acpi_processor *pr = NULL;
 	int result = 0;
@@ -545,7 +542,7 @@ err_free_cpumask:
 	return result;
 }
 
-static int acpi_processor_remove(struct acpi_device *device, int type)
+int acpi_processor_remove(struct acpi_device *device, int type)
 {
 	struct acpi_processor *pr = NULL;
 
@@ -758,7 +755,6 @@ static int acpi_processor_handle_eject(struct acpi_processor *pr)
 }
 #endif
 
-static
 void acpi_processor_install_hotplug_notify(void)
 {
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
@@ -771,7 +767,6 @@ void acpi_processor_install_hotplug_notify(void)
 	register_hotcpu_notifier(&acpi_cpu_notifier);
 }
 
-static
 void acpi_processor_uninstall_hotplug_notify(void)
 {
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 85b3237..22c6195 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -386,7 +386,7 @@ static int acpi_processor_get_performance_states(struct acpi_processor *pr)
 	return result;
 }
 
-static int acpi_processor_get_performance_info(struct acpi_processor *pr)
+int acpi_processor_get_performance_info(struct acpi_processor *pr)
 {
 	int result = 0;
 	acpi_status status = AE_OK;
@@ -492,7 +492,7 @@ int acpi_processor_notify_smm(struct module *calling_module)
 
 EXPORT_SYMBOL(acpi_processor_notify_smm);
 
-static int acpi_processor_get_psd(struct acpi_processor	*pr)
+int acpi_processor_get_psd(struct acpi_processor	*pr)
 {
 	int result = 0;
 	acpi_status status = AE_OK;
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index 610f6fb..12657bb 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -239,6 +239,12 @@ extern void acpi_processor_unregister_performance(struct
          if a _PPC object exists, rmmod is disallowed then */
 int acpi_processor_notify_smm(struct module *calling_module);
 
+void acpi_processor_install_hotplug_notify(void);
+void acpi_processor_uninstall_hotplug_notify(void);
+
+int acpi_processor_add(struct acpi_device *device);
+int acpi_processor_remove(struct acpi_device *device, int type);
+void acpi_processor_notify(struct acpi_device *device, u32 event);
 /* for communication between multiple parts of the processor kernel module */
 DECLARE_PER_CPU(struct acpi_processor *, processors);
 extern struct acpi_processor_errata errata;
@@ -278,7 +284,9 @@ static inline void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
 void acpi_processor_ppc_init(void);
 void acpi_processor_ppc_exit(void);
 int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int event_flag);
-extern int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
+int acpi_processor_get_performance_info(struct acpi_processor *pr);
+int acpi_processor_get_psd(struct acpi_processor *pr);
+int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
 #else
 static inline void acpi_processor_ppc_init(void)
 {
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrb-0007PZ-PQ; Wed, 30 Nov 2011 17:22:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrZ-0007Mz-J9
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1322673705!5676459!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDIwMzk5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12135 invoked from network); 30 Nov 2011 17:21:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 17:21:50 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLbpL022005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLaRg013930
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:36 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLUox019617; Wed, 30 Nov 2011 11:21:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:29 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 27BEE41C2F;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL8ts014713;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:20:57 -0500
Message-Id: <1322673664-14642-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4ED66623.0088,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 1/8] ACPI: processor: export necessary interfaces
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

This patch export some necessary functions which parse processor
power management information. The Xen ACPI processor driver uses them.

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_driver.c  |   11 +++--------
 drivers/acpi/processor_perflib.c |    4 ++--
 include/acpi/processor.h         |   10 +++++++++-
 3 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 9d7bc9f..211c078 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -79,9 +79,6 @@ MODULE_AUTHOR("Paul Diefenbaugh");
 MODULE_DESCRIPTION("ACPI Processor Driver");
 MODULE_LICENSE("GPL");
 
-static int acpi_processor_add(struct acpi_device *device);
-static int acpi_processor_remove(struct acpi_device *device, int type);
-static void acpi_processor_notify(struct acpi_device *device, u32 event);
 static acpi_status acpi_processor_hotadd_init(acpi_handle handle, int *p_cpu);
 static int acpi_processor_handle_eject(struct acpi_processor *pr);
 
@@ -378,7 +375,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
 
 static DEFINE_PER_CPU(void *, processor_device_array);
 
-static void acpi_processor_notify(struct acpi_device *device, u32 event)
+void acpi_processor_notify(struct acpi_device *device, u32 event)
 {
 	struct acpi_processor *pr = acpi_driver_data(device);
 	int saved;
@@ -442,7 +439,7 @@ static struct notifier_block acpi_cpu_notifier =
 	    .notifier_call = acpi_cpu_soft_notify,
 };
 
-static int __cpuinit acpi_processor_add(struct acpi_device *device)
+int __cpuinit acpi_processor_add(struct acpi_device *device)
 {
 	struct acpi_processor *pr = NULL;
 	int result = 0;
@@ -545,7 +542,7 @@ err_free_cpumask:
 	return result;
 }
 
-static int acpi_processor_remove(struct acpi_device *device, int type)
+int acpi_processor_remove(struct acpi_device *device, int type)
 {
 	struct acpi_processor *pr = NULL;
 
@@ -758,7 +755,6 @@ static int acpi_processor_handle_eject(struct acpi_processor *pr)
 }
 #endif
 
-static
 void acpi_processor_install_hotplug_notify(void)
 {
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
@@ -771,7 +767,6 @@ void acpi_processor_install_hotplug_notify(void)
 	register_hotcpu_notifier(&acpi_cpu_notifier);
 }
 
-static
 void acpi_processor_uninstall_hotplug_notify(void)
 {
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 85b3237..22c6195 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -386,7 +386,7 @@ static int acpi_processor_get_performance_states(struct acpi_processor *pr)
 	return result;
 }
 
-static int acpi_processor_get_performance_info(struct acpi_processor *pr)
+int acpi_processor_get_performance_info(struct acpi_processor *pr)
 {
 	int result = 0;
 	acpi_status status = AE_OK;
@@ -492,7 +492,7 @@ int acpi_processor_notify_smm(struct module *calling_module)
 
 EXPORT_SYMBOL(acpi_processor_notify_smm);
 
-static int acpi_processor_get_psd(struct acpi_processor	*pr)
+int acpi_processor_get_psd(struct acpi_processor	*pr)
 {
 	int result = 0;
 	acpi_status status = AE_OK;
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index 610f6fb..12657bb 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -239,6 +239,12 @@ extern void acpi_processor_unregister_performance(struct
          if a _PPC object exists, rmmod is disallowed then */
 int acpi_processor_notify_smm(struct module *calling_module);
 
+void acpi_processor_install_hotplug_notify(void);
+void acpi_processor_uninstall_hotplug_notify(void);
+
+int acpi_processor_add(struct acpi_device *device);
+int acpi_processor_remove(struct acpi_device *device, int type);
+void acpi_processor_notify(struct acpi_device *device, u32 event);
 /* for communication between multiple parts of the processor kernel module */
 DECLARE_PER_CPU(struct acpi_processor *, processors);
 extern struct acpi_processor_errata errata;
@@ -278,7 +284,9 @@ static inline void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
 void acpi_processor_ppc_init(void);
 void acpi_processor_ppc_exit(void);
 int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int event_flag);
-extern int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
+int acpi_processor_get_performance_info(struct acpi_processor *pr);
+int acpi_processor_get_psd(struct acpi_processor *pr);
+int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
 #else
 static inline void acpi_processor_ppc_init(void)
 {
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrb-0007PP-8W; Wed, 30 Nov 2011 17:22:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrZ-0007N2-Ks
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322673709!6260409!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22319 invoked from network); 30 Nov 2011 17:21:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:50 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLbL5008404
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLaV3027749
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:36 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLUmb030847; Wed, 30 Nov 2011 11:21:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:29 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 4D6EB41C30;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL827014716;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:20:58 -0500
Message-Id: <1322673664-14642-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4ED66623.0063,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 2/8] ACPI: processor: cache acpi_power_register
	in cx structure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

This patch save acpi_power_register in cx structure because we need
pass this to the Xen ACPI processor driver.

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_idle.c |    2 +-
 include/acpi/processor.h      |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 0e8e2de..d88974a 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -418,7 +418,7 @@ static int acpi_processor_get_power_info_cst(struct acpi_processor *pr)
 		if (reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO &&
 		    (reg->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE))
 			continue;
-
+		memcpy(&(cx.reg), reg, sizeof(*reg));
 		/* There should be an easy way to extract an integer... */
 		obj = &(element->package.elements[1]);
 		if (obj->type != ACPI_TYPE_INTEGER)
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index 12657bb..bd99fb6 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -65,6 +65,7 @@ struct acpi_processor_cx {
 	u64 time;
 	u8 bm_sts_skip;
 	char desc[ACPI_CX_DESC_LEN];
+	struct acpi_power_register reg;
 };
 
 struct acpi_processor_power {
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:43 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrb-0007PP-8W; Wed, 30 Nov 2011 17:22:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrZ-0007N2-Ks
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1322673709!6260409!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22319 invoked from network); 30 Nov 2011 17:21:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:50 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLbL5008404
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLaV3027749
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:36 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLUmb030847; Wed, 30 Nov 2011 11:21:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:29 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 4D6EB41C30;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL827014716;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:20:58 -0500
Message-Id: <1322673664-14642-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4ED66623.0063,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 2/8] ACPI: processor: cache acpi_power_register
	in cx structure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

This patch save acpi_power_register in cx structure because we need
pass this to the Xen ACPI processor driver.

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/processor_idle.c |    2 +-
 include/acpi/processor.h      |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 0e8e2de..d88974a 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -418,7 +418,7 @@ static int acpi_processor_get_power_info_cst(struct acpi_processor *pr)
 		if (reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO &&
 		    (reg->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE))
 			continue;
-
+		memcpy(&(cx.reg), reg, sizeof(*reg));
 		/* There should be an easy way to extract an integer... */
 		obj = &(element->package.elements[1]);
 		if (obj->type != ACPI_TYPE_INTEGER)
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index 12657bb..bd99fb6 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -65,6 +65,7 @@ struct acpi_processor_cx {
 	u64 time;
 	u8 bm_sts_skip;
 	char desc[ACPI_CX_DESC_LEN];
+	struct acpi_power_register reg;
 };
 
 struct acpi_processor_power {
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrW-0007Ng-SB; Wed, 30 Nov 2011 17:22:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrV-0007Mo-I0
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322673705!4449607!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16147 invoked from network); 30 Nov 2011 17:21:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLbKt008405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLamj027752
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:36 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLUR5019619; Wed, 30 Nov 2011 11:21:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:29 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 02BB441C2D;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL6wc014706;
	Wed, 30 Nov 2011 12:21:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:20:56 -0500
Message-Id: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4ED66623.005F,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [RFC PATCH] Exporting ACPI Pxx/Cxx states to other
	kernel subsystems (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

The following patches are a solution to a problem we have encountered
when using the Xen hypervisor:
 - Need Pxx/Cxx states to save on power consumption when using Xen (we
   do want those datacenters to consume less power!),
 - Also need to figure out the Turbo mode so that the scheduler can properly
   boost a core for CPU bound guests.

In essence the Xen hypervisor requires that information to work efficiently.

There are some other ways of solving this problem as well that have
been tossed around. I am enumerating them here, but I don't have the
full records of the disadvantages/advantges so hopefully some other people
can chime in.
 - Parse the information in userspace. I am not really sure how that would
   work, but one thought was export in SysFS the Pxx/Cxx states and other ones
   (hand-waving here) and the libvirt/xend/xl toolstack would parse those as
   needed and push them up (say when the guest is started). But it does have
   a disadvantage that it would not work well with CPU hotplug, nor with the
   physical CPU != virtual CPU discountinty (that is Linux sees only one CPU,
   and the ACPI Pxx says there are eight of them - with different values than
   the CPU0).
 - Make the ACPI subsystem export some of this functionality so that there
   can be multiple ACPI processor drivers and they can share common code.
   This is what this patch series follows. This does mean exporting some
   ACPI "stuff" outside drivers/acpi. 
 - Implement the ACPI DSDT parsing in the hypervisor. The couple of reasons
   that pop in my head for not going that route is foremost it seems an
   overkill just so that this specific information (Pxx/Cxx) can pushed in
   the hypervisor.  We already use the Linux ACPI to figure out the IRQ routing,
   or for ACPI states changes like button pushing, docking events, etc.
   Making it all be done in the hypervisor seems well, an overkill.

The original authors of the code are Intel folks. Liang has been working
on this to see if the abstraction can be improved, but I am by no means
an ACPI expert - so feedback, guidance or input would be much appreciated.


Liang:
 ACPI: processor: Don't setup cpu idle driver and handler

I think it can be actually dropped - now that disable_cpuidle() functionality
exists and we use it? 

Kevin Tian (6):
      ACPI: processor: export necessary interfaces
      ACPI: processor: cache acpi_power_register in cx structure
      ACPI: processor: Don't setup cpu idle driver and handler when we do not want them.
      ACPI: add processor driver for Xen virtual CPUs.
      ACPI: xen processor: add PM notification interfaces.
      ACPI: xen processor: set ignore_ppc to handle PPC event for Xen vcpu.

Tang Liang (2):
      ACPI: processor: add __acpi_processor_[un]register_driver helpers.
      ACPI: processor: override the interface of register acpi processor handler for Xen vcpu

 drivers/acpi/Makefile            |    1 +
 drivers/acpi/processor_driver.c  |   48 +++++--
 drivers/acpi/processor_idle.c    |   10 +-
 drivers/acpi/processor_perflib.c |    6 +-
 drivers/acpi/processor_xen.c     |  246 ++++++++++++++++++++++++++++++++++
 drivers/xen/Kconfig              |    5 +
 drivers/xen/Makefile             |    3 +
 drivers/xen/acpi_processor.c     |  269 ++++++++++++++++++++++++++++++++++++++
 include/acpi/processor.h         |   20 +++-
 include/xen/acpi.h               |  104 +++++++++++++++
 10 files changed, 690 insertions(+), 22 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:44 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrW-0007Ng-SB; Wed, 30 Nov 2011 17:22:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrV-0007Mo-I0
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322673705!4449607!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16147 invoked from network); 30 Nov 2011 17:21:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:46 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLbKt008405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:38 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLamj027752
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:36 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLUR5019619; Wed, 30 Nov 2011 11:21:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:29 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 02BB441C2D;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL6wc014706;
	Wed, 30 Nov 2011 12:21:06 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:20:56 -0500
Message-Id: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4ED66623.005F,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [RFC PATCH] Exporting ACPI Pxx/Cxx states to other
	kernel subsystems (v1).
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

The following patches are a solution to a problem we have encountered
when using the Xen hypervisor:
 - Need Pxx/Cxx states to save on power consumption when using Xen (we
   do want those datacenters to consume less power!),
 - Also need to figure out the Turbo mode so that the scheduler can properly
   boost a core for CPU bound guests.

In essence the Xen hypervisor requires that information to work efficiently.

There are some other ways of solving this problem as well that have
been tossed around. I am enumerating them here, but I don't have the
full records of the disadvantages/advantges so hopefully some other people
can chime in.
 - Parse the information in userspace. I am not really sure how that would
   work, but one thought was export in SysFS the Pxx/Cxx states and other ones
   (hand-waving here) and the libvirt/xend/xl toolstack would parse those as
   needed and push them up (say when the guest is started). But it does have
   a disadvantage that it would not work well with CPU hotplug, nor with the
   physical CPU != virtual CPU discountinty (that is Linux sees only one CPU,
   and the ACPI Pxx says there are eight of them - with different values than
   the CPU0).
 - Make the ACPI subsystem export some of this functionality so that there
   can be multiple ACPI processor drivers and they can share common code.
   This is what this patch series follows. This does mean exporting some
   ACPI "stuff" outside drivers/acpi. 
 - Implement the ACPI DSDT parsing in the hypervisor. The couple of reasons
   that pop in my head for not going that route is foremost it seems an
   overkill just so that this specific information (Pxx/Cxx) can pushed in
   the hypervisor.  We already use the Linux ACPI to figure out the IRQ routing,
   or for ACPI states changes like button pushing, docking events, etc.
   Making it all be done in the hypervisor seems well, an overkill.

The original authors of the code are Intel folks. Liang has been working
on this to see if the abstraction can be improved, but I am by no means
an ACPI expert - so feedback, guidance or input would be much appreciated.


Liang:
 ACPI: processor: Don't setup cpu idle driver and handler

I think it can be actually dropped - now that disable_cpuidle() functionality
exists and we use it? 

Kevin Tian (6):
      ACPI: processor: export necessary interfaces
      ACPI: processor: cache acpi_power_register in cx structure
      ACPI: processor: Don't setup cpu idle driver and handler when we do not want them.
      ACPI: add processor driver for Xen virtual CPUs.
      ACPI: xen processor: add PM notification interfaces.
      ACPI: xen processor: set ignore_ppc to handle PPC event for Xen vcpu.

Tang Liang (2):
      ACPI: processor: add __acpi_processor_[un]register_driver helpers.
      ACPI: processor: override the interface of register acpi processor handler for Xen vcpu

 drivers/acpi/Makefile            |    1 +
 drivers/acpi/processor_driver.c  |   48 +++++--
 drivers/acpi/processor_idle.c    |   10 +-
 drivers/acpi/processor_perflib.c |    6 +-
 drivers/acpi/processor_xen.c     |  246 ++++++++++++++++++++++++++++++++++
 drivers/xen/Kconfig              |    5 +
 drivers/xen/Makefile             |    3 +
 drivers/xen/acpi_processor.c     |  269 ++++++++++++++++++++++++++++++++++++++
 include/acpi/processor.h         |   20 +++-
 include/xen/acpi.h               |  104 +++++++++++++++
 10 files changed, 690 insertions(+), 22 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrU-0007N0-7W; Wed, 30 Nov 2011 17:22:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrS-0007Mt-Gp
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322673686!50383683!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32100 invoked from network); 30 Nov 2011 17:21:28 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLcvb008419
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLbj7013963
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:37 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLWHn030912; Wed, 30 Nov 2011 11:21:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:31 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id BB57841C33;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL82H014725;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:21:01 -0500
Message-Id: <1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4ED66624.0027,ss=1,re=-2.300,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen virtual
	CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

Because the processor is controlled by the VMM in xen,
we need new acpi processor driver for Xen virtual CPU.

Specifically we need to be able to pass the CXX/PXX states
to the hypervisor, and as well deal with the peculiarity
that the amount of CPUs that Linux parses in the ACPI
is different from the amount visible to the Linux kernel.

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/Makefile        |    1 +
 drivers/acpi/processor_xen.c |  244 ++++++++++++++++++++++++++++++++++++++++++
 drivers/xen/Kconfig          |    5 +
 drivers/xen/Makefile         |    3 +
 drivers/xen/acpi_processor.c |   53 +++++++++
 include/xen/acpi.h           |  104 ++++++++++++++++++
 6 files changed, 410 insertions(+), 0 deletions(-)
 create mode 100644 drivers/acpi/processor_xen.c
 create mode 100644 drivers/xen/acpi_processor.c
 create mode 100644 include/xen/acpi.h

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index ecb26b4..1f39861f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 # processor has its own "processor." module_param namespace
 processor-y			:= processor_driver.o processor_throttling.o
 processor-y			+= processor_idle.o processor_thermal.o
+processor-y			+= processor_xen.o
 processor-$(CONFIG_CPU_FREQ)	+= processor_perflib.o
 
 obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
new file mode 100644
index 0000000..fc3cc0b
--- /dev/null
+++ b/drivers/acpi/processor_xen.c
@@ -0,0 +1,244 @@
+/*
+ * processor_xen.c - ACPI Processor Driver for xen
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+#include <xen/acpi.h>
+#include <linux/export.h>
+
+#define PREFIX "ACPI: "
+
+#define ACPI_PROCESSOR_CLASS            "processor"
+#define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
+#define ACPI_PROCESSOR_NOTIFY_POWER	0x81
+#define ACPI_PROCESSOR_NOTIFY_THROTTLING	0x82
+
+#define _COMPONENT              ACPI_PROCESSOR_COMPONENT
+ACPI_MODULE_NAME("processor_xen");
+
+#if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
+defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
+static const struct acpi_device_id processor_device_ids[] = {
+	{ACPI_PROCESSOR_OBJECT_HID, 0},
+	{"ACPI0007", 0},
+	{"", 0},
+};
+
+static int xen_acpi_processor_add(struct acpi_device *device);
+static void xen_acpi_processor_notify(struct acpi_device *device, u32 event);
+
+struct acpi_driver xen_acpi_processor_driver = {
+	.name = "processor",
+	.class = ACPI_PROCESSOR_CLASS,
+	.ids = processor_device_ids,
+	.ops = {
+		.add = xen_acpi_processor_add,
+		.remove = acpi_processor_remove,
+		.suspend = acpi_processor_suspend,
+		.resume = acpi_processor_resume,
+		.notify = xen_acpi_processor_notify,
+		},
+};
+
+#ifdef CONFIG_CPU_FREQ
+/*
+ * Existing ACPI module does parse performance states at some point,
+ * when acpi-cpufreq driver is loaded which however is something
+ * we'd like to disable to avoid confliction with xen PM
+ * logic. So we have to collect raw performance information here
+ * when ACPI processor object is found and started.
+ */
+static int xen_acpi_processor_get_performance(struct acpi_processor *pr)
+{
+	int ret;
+	struct acpi_processor_performance *perf;
+	struct acpi_psd_package *pdomain;
+
+	if (pr->performance)
+		return -EBUSY;
+
+	perf = kzalloc(sizeof(struct acpi_processor_performance), GFP_KERNEL);
+	if (!perf)
+		return -ENOMEM;
+
+	pr->performance = perf;
+	/* Get basic performance state information */
+	ret = acpi_processor_get_performance_info(pr);
+	if (ret < 0)
+		goto err_out;
+
+	/* invoke raw psd parse interface directly, as it's useless to
+	 * construct a shared map around dom0's vcpu ID.
+	 */
+	pdomain = &pr->performance->domain_info;
+	pdomain->num_processors = 0;
+	ret = acpi_processor_get_psd(pr);
+	if (ret < 0) {
+		/*
+		 * _PSD is optional - assume no coordination if absent (or
+		 * broken), matching native kernels' behavior.
+		 */
+		pdomain->num_entries = ACPI_PSD_REV0_ENTRIES;
+		pdomain->revision = ACPI_PSD_REV0_REVISION;
+		pdomain->domain = pr->acpi_id;
+		pdomain->coord_type = DOMAIN_COORD_TYPE_SW_ALL;
+		pdomain->num_processors = 1;
+	}
+
+	processor_cntl_xen_notify(pr, PROCESSOR_PM_INIT, PM_TYPE_PERF);
+
+	/* Last step is to notify BIOS that xen exists */
+	acpi_processor_notify_smm(THIS_MODULE);
+
+	return 0;
+err_out:
+	pr->performance = NULL;
+	kfree(perf);
+	return ret;
+}
+#endif /* CONFIG_CPU_FREQ */
+
+static int __cpuinit xen_acpi_processor_add(struct acpi_device *device)
+{
+	struct acpi_processor *pr = NULL;
+	int result = 0;
+
+	result = acpi_processor_add(device);
+	if (result < 0)
+		return result;
+
+	pr = acpi_driver_data(device);
+	if (!pr)
+		return -EINVAL;
+
+	if (pr->id == -1) {
+		int device_declaration;
+		int apic_id = -1;
+
+		if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID))
+			device_declaration = 0;
+		else
+			device_declaration = 1;
+
+		apic_id = acpi_get_cpuid(pr->handle,
+			device_declaration, pr->acpi_id);
+		if (apic_id == -1) {
+			/* Processor is not present in MADT table */
+			return 0;
+		}
+
+		/*
+		 * It's possible to have pr->id as '-1' even when it's actually
+		 * present in MADT table, e.g. due to limiting dom0 max vcpus
+		 * less than physical present number. In such case we still want
+		 * to parse ACPI processor object information, so mimic the
+		 * pr->id to CPU-0. This should be safe because we only care
+		 * about raw ACPI information, which only relies on pr->acpi_id.
+		 * For other information relying on pr->id and gathered through
+		 * SMP function call, it's safe to let them run on CPU-0 since
+		 * underlying Xen will collect them. Only a valid pr->id can
+		 * make later invocations forward progress.
+		 */
+		pr->id = 0;
+	}
+
+	if (likely(!pr->flags.power_setup_done)) {
+		/* reset idle boot option which we don't care */
+		boot_option_idle_override = IDLE_NO_OVERRIDE;
+		acpi_processor_power_init(pr, device);
+		/* set to IDLE_HALT for trapping into Xen */
+		boot_option_idle_override = IDLE_HALT;
+
+		if (pr->flags.power)
+			processor_cntl_xen_notify(pr,
+					PROCESSOR_PM_INIT, PM_TYPE_IDLE);
+	}
+
+#ifdef CONFIG_CPU_FREQ
+	if (likely(!pr->performance))
+		xen_acpi_processor_get_performance(pr);
+#endif
+
+	return 0;
+}
+
+static void xen_acpi_processor_notify(struct acpi_device *device, u32 event)
+{
+	struct acpi_processor *pr = acpi_driver_data(device);
+
+	if (!pr)
+		return;
+
+	acpi_processor_notify(device, event);
+
+	switch (event) {
+	case ACPI_PROCESSOR_NOTIFY_PERFORMANCE:
+#ifdef CONFIG_CPU_FREQ
+		processor_cntl_xen_notify(pr,
+				PROCESSOR_PM_CHANGE, PM_TYPE_PERF);
+#endif
+		break;
+	case ACPI_PROCESSOR_NOTIFY_POWER:
+		processor_cntl_xen_notify(pr,
+				PROCESSOR_PM_CHANGE, PM_TYPE_IDLE);
+		break;
+	default:
+		break;
+	}
+
+	return;
+}
+
+/* init and exit */
+
+/* we don't install acpi cpuidle driver because dom0 itself is running
+ * as a guest which has no knowledge whether underlying is actually idle
+ */
+int xen_acpi_processor_init(void)
+{
+	int result = 0;
+
+	result = acpi_bus_register_driver(&xen_acpi_processor_driver);
+	if (result < 0)
+		return result;
+		/* mark ready for handling ppc */
+
+	return 0;
+}
+
+void xen_acpi_processor_exit(void)
+{
+
+	acpi_bus_unregister_driver(&xen_acpi_processor_driver);
+}
+#endif
+
+#if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
+defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
+void xen_processor_driver_register(void)
+{
+	if (xen_initial_domain()) {
+		__acpi_processor_register_driver = xen_acpi_processor_init;
+		__acpi_processor_unregister_driver = xen_acpi_processor_exit;
+	}
+}
+#else
+void xen_processor_driver_register(void)
+{
+}
+#endif
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..640bbf5 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -117,6 +117,11 @@ config XEN_SYS_HYPERVISOR
 	 virtual environment, /sys/hypervisor will still be present,
 	 but will have no xen contents.
 
+config ACPI_PROCESSOR_XEN
+	tristate
+	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
+	default m
+
 config XEN_XENBUS_FRONTEND
 	tristate
 
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 974fffd..f67450c 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -19,6 +19,9 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
+ifdef CONFIG_ACPI_PROCESSOR_XEN
+obj-$(CONFIG_ACPI_PROCESSOR)		+= acpi_processor.o
+endif
 
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
diff --git a/drivers/xen/acpi_processor.c b/drivers/xen/acpi_processor.c
new file mode 100644
index 0000000..8fa7914
--- /dev/null
+++ b/drivers/xen/acpi_processor.c
@@ -0,0 +1,53 @@
+/*
+ *  acpi_processor.c - interface to notify Xen on acpi processor object
+ *                     info parsing
+ *
+ *  Copyright (C) 2008, Intel corporation
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ */
+
+#include <linux/acpi.h>
+#include <linux/module.h>
+#include <linux/cpufreq.h>
+#include <acpi/processor.h>
+#include <xen/acpi.h>
+
+#include <asm/xen/hypercall.h>
+#include <asm/xen/hypervisor.h>
+
+static struct processor_cntl_xen_ops xen_ops;
+int processor_cntl_xen_notify(struct acpi_processor *pr, int event, int type)
+{
+	int ret = -EINVAL;
+
+	switch (event) {
+	case PROCESSOR_PM_INIT:
+	case PROCESSOR_PM_CHANGE:
+		if ((type >= PM_TYPE_MAX) ||
+			!xen_ops.pm_ops[type])
+			break;
+
+		ret = xen_ops.pm_ops[type](pr, event);
+		break;
+	default:
+		printk(KERN_ERR "Unsupport processor events %d.\n", event);
+		break;
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL(processor_cntl_xen_notify);
+
+MODULE_LICENSE("GPL");
diff --git a/include/xen/acpi.h b/include/xen/acpi.h
new file mode 100644
index 0000000..99e1270
--- /dev/null
+++ b/include/xen/acpi.h
@@ -0,0 +1,104 @@
+/******************************************************************************
+ * acpi.h
+ * acpi file for domain 0 kernel
+ *
+ * Copyright (c) 2011 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+ * Copyright (c) 2011 Yu Ke <ke.yu@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef _XEN_ACPI_H
+#define _XEN_ACPI_H
+
+#include <linux/types.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+
+/*
+ * Following are interfaces for xen acpi processor control
+ */
+#if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
+defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
+/* Events notified to xen */
+#define PROCESSOR_PM_INIT	1
+#define PROCESSOR_PM_CHANGE	2
+#define PROCESSOR_HOTPLUG	3
+
+/* Objects for the PM events */
+#define PM_TYPE_IDLE		0
+#define PM_TYPE_PERF		1
+#define PM_TYPE_THR		2
+#define PM_TYPE_MAX		3
+
+#define XEN_MAX_ACPI_ID 255
+
+/* Processor hotplug events */
+#define HOTPLUG_TYPE_ADD	0
+#define HOTPLUG_TYPE_REMOVE	1
+
+extern int (*__acpi_processor_register_driver)(void);
+extern void (*__acpi_processor_unregister_driver)(void);
+#endif
+
+#ifndef CONFIG_CPU_FREQ
+static inline int xen_acpi_processor_get_performance(struct acpi_processor *pr)
+{
+	printk(KERN_WARNING
+		"Warning: xen_acpi_processor_get_performance not supported\n"
+		"Consider compiling CPUfreq support into your kernel.\n");
+	return 0;
+}
+#endif
+
+#if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
+defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
+
+struct processor_cntl_xen_ops {
+	/* Transfer processor PM events to xen */
+int (*pm_ops[PM_TYPE_MAX])(struct acpi_processor *pr, int event);
+	/* Notify physical processor status to xen */
+	int (*hotplug)(struct acpi_processor *pr, int type);
+};
+
+extern int processor_cntl_xen_notify(struct acpi_processor *pr,
+			int event, int type);
+extern int processor_cntl_xen_power_cache(int cpu, int cx,
+		struct acpi_power_register *reg);
+#else
+
+static inline int processor_cntl_xen_notify(struct acpi_processor *pr,
+			int event, int type)
+{
+	return 0;
+}
+static inline int processor_cntl_xen_power_cache(int cpu, int cx,
+		struct acpi_power_register *reg)
+{
+	return 0;
+}
+#endif /* CONFIG_ACPI_PROCESSOR_XEN */
+
+#endif	/* _XEN_ACPI_H */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:22:45 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:22:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnrU-0007N0-7W; Wed, 30 Nov 2011 17:22:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVnrS-0007Mt-Gp
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:22:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1322673686!50383683!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32100 invoked from network); 30 Nov 2011 17:21:28 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 17:21:28 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUHLcvb008419
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 17:21:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUHLbj7013963
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 17:21:37 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUHLWHn030912; Wed, 30 Nov 2011 11:21:32 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 09:21:31 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id BB57841C33;
	Wed, 30 Nov 2011 12:21:08 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUHL82H014725;
	Wed, 30 Nov 2011 12:21:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ke.yu@intel.com, kevin.tian@intel.com, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org, rjw@sisk.pl
Date: Wed, 30 Nov 2011 12:21:01 -0500
Message-Id: <1322673664-14642-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
References: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4ED66624.0027,ss=1,re=-2.300,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	mike.mcclurg@citrix.com, stefan.bader@canonical.com,
	konrad@kernel.org, liang.tang@oracle.com
Subject: [Xen-devel] [PATCH 5/8] ACPI: add processor driver for Xen virtual
	CPUs.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Kevin Tian <kevin.tian@intel.com>

Because the processor is controlled by the VMM in xen,
we need new acpi processor driver for Xen virtual CPU.

Specifically we need to be able to pass the CXX/PXX states
to the hypervisor, and as well deal with the peculiarity
that the amount of CPUs that Linux parses in the ACPI
is different from the amount visible to the Linux kernel.

Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Tian Kevin <kevin.tian@intel.com>
Signed-off-by: Tang Liang <liang.tang@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/acpi/Makefile        |    1 +
 drivers/acpi/processor_xen.c |  244 ++++++++++++++++++++++++++++++++++++++++++
 drivers/xen/Kconfig          |    5 +
 drivers/xen/Makefile         |    3 +
 drivers/xen/acpi_processor.c |   53 +++++++++
 include/xen/acpi.h           |  104 ++++++++++++++++++
 6 files changed, 410 insertions(+), 0 deletions(-)
 create mode 100644 drivers/acpi/processor_xen.c
 create mode 100644 drivers/xen/acpi_processor.c
 create mode 100644 include/xen/acpi.h

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index ecb26b4..1f39861f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 # processor has its own "processor." module_param namespace
 processor-y			:= processor_driver.o processor_throttling.o
 processor-y			+= processor_idle.o processor_thermal.o
+processor-y			+= processor_xen.o
 processor-$(CONFIG_CPU_FREQ)	+= processor_perflib.o
 
 obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
new file mode 100644
index 0000000..fc3cc0b
--- /dev/null
+++ b/drivers/acpi/processor_xen.c
@@ -0,0 +1,244 @@
+/*
+ * processor_xen.c - ACPI Processor Driver for xen
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+#include <xen/acpi.h>
+#include <linux/export.h>
+
+#define PREFIX "ACPI: "
+
+#define ACPI_PROCESSOR_CLASS            "processor"
+#define ACPI_PROCESSOR_NOTIFY_PERFORMANCE 0x80
+#define ACPI_PROCESSOR_NOTIFY_POWER	0x81
+#define ACPI_PROCESSOR_NOTIFY_THROTTLING	0x82
+
+#define _COMPONENT              ACPI_PROCESSOR_COMPONENT
+ACPI_MODULE_NAME("processor_xen");
+
+#if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
+defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
+static const struct acpi_device_id processor_device_ids[] = {
+	{ACPI_PROCESSOR_OBJECT_HID, 0},
+	{"ACPI0007", 0},
+	{"", 0},
+};
+
+static int xen_acpi_processor_add(struct acpi_device *device);
+static void xen_acpi_processor_notify(struct acpi_device *device, u32 event);
+
+struct acpi_driver xen_acpi_processor_driver = {
+	.name = "processor",
+	.class = ACPI_PROCESSOR_CLASS,
+	.ids = processor_device_ids,
+	.ops = {
+		.add = xen_acpi_processor_add,
+		.remove = acpi_processor_remove,
+		.suspend = acpi_processor_suspend,
+		.resume = acpi_processor_resume,
+		.notify = xen_acpi_processor_notify,
+		},
+};
+
+#ifdef CONFIG_CPU_FREQ
+/*
+ * Existing ACPI module does parse performance states at some point,
+ * when acpi-cpufreq driver is loaded which however is something
+ * we'd like to disable to avoid confliction with xen PM
+ * logic. So we have to collect raw performance information here
+ * when ACPI processor object is found and started.
+ */
+static int xen_acpi_processor_get_performance(struct acpi_processor *pr)
+{
+	int ret;
+	struct acpi_processor_performance *perf;
+	struct acpi_psd_package *pdomain;
+
+	if (pr->performance)
+		return -EBUSY;
+
+	perf = kzalloc(sizeof(struct acpi_processor_performance), GFP_KERNEL);
+	if (!perf)
+		return -ENOMEM;
+
+	pr->performance = perf;
+	/* Get basic performance state information */
+	ret = acpi_processor_get_performance_info(pr);
+	if (ret < 0)
+		goto err_out;
+
+	/* invoke raw psd parse interface directly, as it's useless to
+	 * construct a shared map around dom0's vcpu ID.
+	 */
+	pdomain = &pr->performance->domain_info;
+	pdomain->num_processors = 0;
+	ret = acpi_processor_get_psd(pr);
+	if (ret < 0) {
+		/*
+		 * _PSD is optional - assume no coordination if absent (or
+		 * broken), matching native kernels' behavior.
+		 */
+		pdomain->num_entries = ACPI_PSD_REV0_ENTRIES;
+		pdomain->revision = ACPI_PSD_REV0_REVISION;
+		pdomain->domain = pr->acpi_id;
+		pdomain->coord_type = DOMAIN_COORD_TYPE_SW_ALL;
+		pdomain->num_processors = 1;
+	}
+
+	processor_cntl_xen_notify(pr, PROCESSOR_PM_INIT, PM_TYPE_PERF);
+
+	/* Last step is to notify BIOS that xen exists */
+	acpi_processor_notify_smm(THIS_MODULE);
+
+	return 0;
+err_out:
+	pr->performance = NULL;
+	kfree(perf);
+	return ret;
+}
+#endif /* CONFIG_CPU_FREQ */
+
+static int __cpuinit xen_acpi_processor_add(struct acpi_device *device)
+{
+	struct acpi_processor *pr = NULL;
+	int result = 0;
+
+	result = acpi_processor_add(device);
+	if (result < 0)
+		return result;
+
+	pr = acpi_driver_data(device);
+	if (!pr)
+		return -EINVAL;
+
+	if (pr->id == -1) {
+		int device_declaration;
+		int apic_id = -1;
+
+		if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID))
+			device_declaration = 0;
+		else
+			device_declaration = 1;
+
+		apic_id = acpi_get_cpuid(pr->handle,
+			device_declaration, pr->acpi_id);
+		if (apic_id == -1) {
+			/* Processor is not present in MADT table */
+			return 0;
+		}
+
+		/*
+		 * It's possible to have pr->id as '-1' even when it's actually
+		 * present in MADT table, e.g. due to limiting dom0 max vcpus
+		 * less than physical present number. In such case we still want
+		 * to parse ACPI processor object information, so mimic the
+		 * pr->id to CPU-0. This should be safe because we only care
+		 * about raw ACPI information, which only relies on pr->acpi_id.
+		 * For other information relying on pr->id and gathered through
+		 * SMP function call, it's safe to let them run on CPU-0 since
+		 * underlying Xen will collect them. Only a valid pr->id can
+		 * make later invocations forward progress.
+		 */
+		pr->id = 0;
+	}
+
+	if (likely(!pr->flags.power_setup_done)) {
+		/* reset idle boot option which we don't care */
+		boot_option_idle_override = IDLE_NO_OVERRIDE;
+		acpi_processor_power_init(pr, device);
+		/* set to IDLE_HALT for trapping into Xen */
+		boot_option_idle_override = IDLE_HALT;
+
+		if (pr->flags.power)
+			processor_cntl_xen_notify(pr,
+					PROCESSOR_PM_INIT, PM_TYPE_IDLE);
+	}
+
+#ifdef CONFIG_CPU_FREQ
+	if (likely(!pr->performance))
+		xen_acpi_processor_get_performance(pr);
+#endif
+
+	return 0;
+}
+
+static void xen_acpi_processor_notify(struct acpi_device *device, u32 event)
+{
+	struct acpi_processor *pr = acpi_driver_data(device);
+
+	if (!pr)
+		return;
+
+	acpi_processor_notify(device, event);
+
+	switch (event) {
+	case ACPI_PROCESSOR_NOTIFY_PERFORMANCE:
+#ifdef CONFIG_CPU_FREQ
+		processor_cntl_xen_notify(pr,
+				PROCESSOR_PM_CHANGE, PM_TYPE_PERF);
+#endif
+		break;
+	case ACPI_PROCESSOR_NOTIFY_POWER:
+		processor_cntl_xen_notify(pr,
+				PROCESSOR_PM_CHANGE, PM_TYPE_IDLE);
+		break;
+	default:
+		break;
+	}
+
+	return;
+}
+
+/* init and exit */
+
+/* we don't install acpi cpuidle driver because dom0 itself is running
+ * as a guest which has no knowledge whether underlying is actually idle
+ */
+int xen_acpi_processor_init(void)
+{
+	int result = 0;
+
+	result = acpi_bus_register_driver(&xen_acpi_processor_driver);
+	if (result < 0)
+		return result;
+		/* mark ready for handling ppc */
+
+	return 0;
+}
+
+void xen_acpi_processor_exit(void)
+{
+
+	acpi_bus_unregister_driver(&xen_acpi_processor_driver);
+}
+#endif
+
+#if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
+defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
+void xen_processor_driver_register(void)
+{
+	if (xen_initial_domain()) {
+		__acpi_processor_register_driver = xen_acpi_processor_init;
+		__acpi_processor_unregister_driver = xen_acpi_processor_exit;
+	}
+}
+#else
+void xen_processor_driver_register(void)
+{
+}
+#endif
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..640bbf5 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -117,6 +117,11 @@ config XEN_SYS_HYPERVISOR
 	 virtual environment, /sys/hypervisor will still be present,
 	 but will have no xen contents.
 
+config ACPI_PROCESSOR_XEN
+	tristate
+	depends on XEN_DOM0 && ACPI_PROCESSOR && CPU_FREQ
+	default m
+
 config XEN_XENBUS_FRONTEND
 	tristate
 
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 974fffd..f67450c 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -19,6 +19,9 @@ obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
+ifdef CONFIG_ACPI_PROCESSOR_XEN
+obj-$(CONFIG_ACPI_PROCESSOR)		+= acpi_processor.o
+endif
 
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
diff --git a/drivers/xen/acpi_processor.c b/drivers/xen/acpi_processor.c
new file mode 100644
index 0000000..8fa7914
--- /dev/null
+++ b/drivers/xen/acpi_processor.c
@@ -0,0 +1,53 @@
+/*
+ *  acpi_processor.c - interface to notify Xen on acpi processor object
+ *                     info parsing
+ *
+ *  Copyright (C) 2008, Intel corporation
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or (at
+ *  your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ */
+
+#include <linux/acpi.h>
+#include <linux/module.h>
+#include <linux/cpufreq.h>
+#include <acpi/processor.h>
+#include <xen/acpi.h>
+
+#include <asm/xen/hypercall.h>
+#include <asm/xen/hypervisor.h>
+
+static struct processor_cntl_xen_ops xen_ops;
+int processor_cntl_xen_notify(struct acpi_processor *pr, int event, int type)
+{
+	int ret = -EINVAL;
+
+	switch (event) {
+	case PROCESSOR_PM_INIT:
+	case PROCESSOR_PM_CHANGE:
+		if ((type >= PM_TYPE_MAX) ||
+			!xen_ops.pm_ops[type])
+			break;
+
+		ret = xen_ops.pm_ops[type](pr, event);
+		break;
+	default:
+		printk(KERN_ERR "Unsupport processor events %d.\n", event);
+		break;
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL(processor_cntl_xen_notify);
+
+MODULE_LICENSE("GPL");
diff --git a/include/xen/acpi.h b/include/xen/acpi.h
new file mode 100644
index 0000000..99e1270
--- /dev/null
+++ b/include/xen/acpi.h
@@ -0,0 +1,104 @@
+/******************************************************************************
+ * acpi.h
+ * acpi file for domain 0 kernel
+ *
+ * Copyright (c) 2011 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+ * Copyright (c) 2011 Yu Ke <ke.yu@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef _XEN_ACPI_H
+#define _XEN_ACPI_H
+
+#include <linux/types.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+
+/*
+ * Following are interfaces for xen acpi processor control
+ */
+#if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
+defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
+/* Events notified to xen */
+#define PROCESSOR_PM_INIT	1
+#define PROCESSOR_PM_CHANGE	2
+#define PROCESSOR_HOTPLUG	3
+
+/* Objects for the PM events */
+#define PM_TYPE_IDLE		0
+#define PM_TYPE_PERF		1
+#define PM_TYPE_THR		2
+#define PM_TYPE_MAX		3
+
+#define XEN_MAX_ACPI_ID 255
+
+/* Processor hotplug events */
+#define HOTPLUG_TYPE_ADD	0
+#define HOTPLUG_TYPE_REMOVE	1
+
+extern int (*__acpi_processor_register_driver)(void);
+extern void (*__acpi_processor_unregister_driver)(void);
+#endif
+
+#ifndef CONFIG_CPU_FREQ
+static inline int xen_acpi_processor_get_performance(struct acpi_processor *pr)
+{
+	printk(KERN_WARNING
+		"Warning: xen_acpi_processor_get_performance not supported\n"
+		"Consider compiling CPUfreq support into your kernel.\n");
+	return 0;
+}
+#endif
+
+#if defined(CONFIG_ACPI_PROCESSOR_XEN) || \
+defined(CONFIG_ACPI_PROCESSOR_XEN_MODULE)
+
+struct processor_cntl_xen_ops {
+	/* Transfer processor PM events to xen */
+int (*pm_ops[PM_TYPE_MAX])(struct acpi_processor *pr, int event);
+	/* Notify physical processor status to xen */
+	int (*hotplug)(struct acpi_processor *pr, int type);
+};
+
+extern int processor_cntl_xen_notify(struct acpi_processor *pr,
+			int event, int type);
+extern int processor_cntl_xen_power_cache(int cpu, int cx,
+		struct acpi_power_register *reg);
+#else
+
+static inline int processor_cntl_xen_notify(struct acpi_processor *pr,
+			int event, int type)
+{
+	return 0;
+}
+static inline int processor_cntl_xen_power_cache(int cpu, int cx,
+		struct acpi_power_register *reg)
+{
+	return 0;
+}
+#endif /* CONFIG_ACPI_PROCESSOR_XEN */
+
+#endif	/* _XEN_ACPI_H */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:25:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnul-0008Me-HA; Wed, 30 Nov 2011 17:25:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVnuj-0008L6-Ms
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:25:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322673903!4809338!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22111 invoked from network); 30 Nov 2011 17:25:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 17:25:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172394017"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 12:24:39 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 30 Nov 2011
	12:24:38 -0500
Message-ID: <4ED666D5.5060603@citrix.com>
Date: Wed, 30 Nov 2011 17:24:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
In-Reply-To: <4ED62C50.7060204@citrix.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------040808070305050009070901"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot time v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------040808070305050009070901
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

Presented is version 2 of this patch, which uses cpu hotplug
notifications to be rather safer when allocating buffers.

It occurs to me that there is a bit of an API problem with it comes to
combining a crashdump kernel with potential hotplug events.

If dom0 does not get notification of new/removed pcpus, and if it
doesn't re-evaluate /proc/iomem by recalling things like
KEXEC_CMD_get_range, then subsequent calls to /sbin/kexec -p will bundle
up stale information into the kdump magic bundle.

Even if dom0 does get a notification of pcpu hotplug events, and it
updates its iomem map, /sbin/kexec would still need to be called to
bundle the new information into the kdump magic bundle.  Possibly doable
off a udev CPU hotplug event.

Even if /sbin/kexec gets called after hotplug events, a crash before the
new kexec magic bundle has been loaded will still result in the old
bundle being used, with its stale information regarding the position and
number of crash notes.

Sadly, I don't see any easy or sensible solution to these problems. 
However, it is probably worth knowing as a potential limitation.

I have worked around this problem by never deallocating crash notes, so
even if information is stale as to the number of crash notes to be
expected, the stale physical addresses still point to allocated notes
buffers which have been partially initialized to have sensible note
headers in.  This unfortunately means that an offlined cpu which was
present at boot time will have a notes section with zero'd data.  It
also means that a cpu onlined after boot which crashes will not have its
register state presented to the kdump environment.

I would like to hope that both of these cases are unlikely, but again,
it is still a potential limitation.

The cpu crash notes themselves (PRSTATUS and XEN_ELFNOTE_CRASH_REGS)
don't contain a reference to which pcpu they represent.  This is
inferred by /sbin/kexec from the order in which they appear in dom0's
/proc/iomem, meaning that the kdump environments idea of which pcpu is
which might differ from Xen's. This depending on whether Xen allocates
the notes buffer in ascending order, whether dom0 sorts memory addresses
reported, and, as it currently gets it correct, whether either of these
behaviors change in the future.

This final issue is within my ability to fix and I will do so in the
near future, along with some other additions I already need to make to
the per cpu crash notes.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------040808070305050009070901
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot v2

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.

 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.

 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,14 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+static void * crash_notes[NR_CPUS];
 
 static Elf_Note *xen_crash_note;
 
@@ -165,7 +166,7 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note = crash_notes[cpu];
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
@@ -245,25 +246,6 @@ static long kexec_reboot(void *_image)
     return 0;
 }
 
-static void do_crashdump_trigger(unsigned char key)
-{
-    printk("'%c' pressed -> triggering crashdump\n", key);
-    kexec_crash();
-    printk(" * no crash kernel loaded!\n");
-}
-
-static struct keyhandler crashdump_trigger_keyhandler = {
-    .u.fn = do_crashdump_trigger,
-    .desc = "trigger a crashdump"
-};
-
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -280,6 +262,110 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const int cpu)
+{
+    Elf_Note * note;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu < 0 || cpu >= NR_CPUS );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu] )
+        return 0;
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( 0 == cpu )
+        nr_bytes = nr_bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    note = xmalloc_bytes(nr_bytes);
+    if ( ! note )
+        /* Ideally, this would be -ENOMEM.  However, there are more problems
+         * assocated with trying to deal with -ENOMEM sensibly than just
+         * pretending that the crash note area doesn't exist. */
+        return 0;
+
+    crash_notes[cpu] = note;
+
+    /* Setup CORE note. */
+    setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+    note = ELFNOTE_NEXT(note);
+
+    /* Setup Xen CORE note. */
+    setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+               sizeof(crash_xen_core_t));
+
+    if ( 0 == cpu )
+    {
+        /* Set up Xen Crash Info note. */
+        xen_crash_note = note = ELFNOTE_NEXT(note);
+        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                   sizeof(crash_xen_info_t));
+    }
+
+    return 0;
+}
+
+static void do_crashdump_trigger(unsigned char key)
+{
+    printk("'%c' pressed -> triggering crashdump\n", key);
+    kexec_crash();
+    printk(" * no crash kernel loaded!\n");
+}
+
+static struct keyhandler crashdump_trigger_keyhandler = {
+    .u.fn = do_crashdump_trigger,
+    .desc = "trigger a crashdump"
+};
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(long)smp_processor_id();
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( 0 == kexec_crash_area.size )
+        return 0;
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -296,7 +382,7 @@ static int kexec_get_cpu(xen_kexec_range
     int nr = range->nr;
     int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes[nr] )
         return -EINVAL;
 
     nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
@@ -306,31 +392,7 @@ static int kexec_get_cpu(xen_kexec_range
     if ( nr == 0 )
         nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
+    range->start = __pa((unsigned long)crash_notes[nr]);
     range->size = nr_bytes;
     return 0;
 }

--------------040808070305050009070901
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040808070305050009070901--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 17:25:56 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 17:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVnul-0008Me-HA; Wed, 30 Nov 2011 17:25:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RVnuj-0008L6-Ms
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 17:25:46 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1322673903!4809338!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22111 invoked from network); 30 Nov 2011 17:25:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 17:25:06 -0000
X-IronPort-AV: E=Sophos;i="4.69,597,1315195200"; d="scan'208";a="172394017"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 12:24:39 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 30 Nov 2011
	12:24:38 -0500
Message-ID: <4ED666D5.5060603@citrix.com>
Date: Wed, 30 Nov 2011 17:24:37 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CAFA7027.25E35%keir.xen@gmail.com> <4ED62C50.7060204@citrix.com>
In-Reply-To: <4ED62C50.7060204@citrix.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------040808070305050009070901"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot time v2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------040808070305050009070901
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

Presented is version 2 of this patch, which uses cpu hotplug
notifications to be rather safer when allocating buffers.

It occurs to me that there is a bit of an API problem with it comes to
combining a crashdump kernel with potential hotplug events.

If dom0 does not get notification of new/removed pcpus, and if it
doesn't re-evaluate /proc/iomem by recalling things like
KEXEC_CMD_get_range, then subsequent calls to /sbin/kexec -p will bundle
up stale information into the kdump magic bundle.

Even if dom0 does get a notification of pcpu hotplug events, and it
updates its iomem map, /sbin/kexec would still need to be called to
bundle the new information into the kdump magic bundle.  Possibly doable
off a udev CPU hotplug event.

Even if /sbin/kexec gets called after hotplug events, a crash before the
new kexec magic bundle has been loaded will still result in the old
bundle being used, with its stale information regarding the position and
number of crash notes.

Sadly, I don't see any easy or sensible solution to these problems. 
However, it is probably worth knowing as a potential limitation.

I have worked around this problem by never deallocating crash notes, so
even if information is stale as to the number of crash notes to be
expected, the stale physical addresses still point to allocated notes
buffers which have been partially initialized to have sensible note
headers in.  This unfortunately means that an offlined cpu which was
present at boot time will have a notes section with zero'd data.  It
also means that a cpu onlined after boot which crashes will not have its
register state presented to the kdump environment.

I would like to hope that both of these cases are unlikely, but again,
it is still a potential limitation.

The cpu crash notes themselves (PRSTATUS and XEN_ELFNOTE_CRASH_REGS)
don't contain a reference to which pcpu they represent.  This is
inferred by /sbin/kexec from the order in which they appear in dom0's
/proc/iomem, meaning that the kdump environments idea of which pcpu is
which might differ from Xen's. This depending on whether Xen allocates
the notes buffer in ascending order, whether dom0 sorts memory addresses
reported, and, as it currently gets it correct, whether either of these
behaviors change in the future.

This final issue is within my ability to fix and I will do so in the
near future, along with some other additions I already need to make to
the per cpu crash notes.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------040808070305050009070901
Content-Type: text/x-patch; name="KEXEC-setup-crash-notes-during-boot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="KEXEC-setup-crash-notes-during-boot.patch"

# HG changeset patch
# Parent b5ceec1ccccad6e79053a80820132303ff1e136f
KEXEC: Allocate crash notes on boot v2

Currently, the buffers for crash notes are allocated per CPU when a
KEXEC_CMD_kexec_get_range hypercall is made, referencing the CPU in
question.

Although it certainly works in general, there are a few edge case problems:

1) There appears to be no guarentee that dom0 will make this hypercall
   for each pcpu on the system.  There appears to be variable
   behaviour depending on how many cpus dom0 is compiled for, and how
   many vcpus Xen gives to dom0.

2) The allocation of these buffers occur at the whim of dom0.  While
   this is typically very early on dom0 boot, but not guarenteed.

3) It is possible (although not sensible) for a crash
   kernel to be loaded without these (or some of these) hypercalls
   being made. Under these circumstances, a crash would cause the
   crash note code path will suffer a slew of null pointer deferences.

4) If the hypercalls are made after late in the day, it is possible
   for the hypercall to return -ENOMEM.  As code tends to be more
   fragile once memory is enhausted, the likelyhood of us needing the
   crash kernel is greater.

In addition, my forthcoming code to support 32bit kdump kernels on
64bit Xen on large (>64GB) boxes will require some guarentees as to
where the crash note buffers are actually allocated in physical
memory.  This is far easier to sort out at boot time, rather than
after dom0 has been booted and potentially using the physical memory
required.

Therefore, allocate the crash note buffers at boot time.

Changes since v1:

 *  Use cpu hotplug notifiers to handle allocating of the notes
    buffers rather than assuming the boot state of cpus will be the
    same as the crash state.

 *  Move crash_notes from being per_cpu.  This is because the kdump
    kernel elf binary put in the crash area is hard coded to physical
    addresses which the dom0 kernel typically obtains at boot time.
    If a cpu is offlined, its buffer should not be deallocated because
    the kdump kernel would read junk when trying to get the crash
    notes.  Similarly, the same problem would occur if the cpu was
    re-onlined later and its crash notes buffer was allocated elsewhere.

 *  Only attempt to allocate buffers if a crash area has been
    specified.  Else, allocating crash note buffers is a waste of
    space.  Along with this, change the test in kexec_get_cpu to
    return -EINVAL if no buffers have been allocated.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r df7cec2c6c03 xen/common/kexec.c
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -25,13 +25,14 @@
 #include <xen/kexec.h>
 #include <public/elfnote.h>
 #include <xsm/xsm.h>
+#include <xen/cpu.h>
 #ifdef CONFIG_COMPAT
 #include <compat/kexec.h>
 #endif
 
 bool_t kexecing = FALSE;
 
-static DEFINE_PER_CPU_READ_MOSTLY(void *, crash_notes);
+static void * crash_notes[NR_CPUS];
 
 static Elf_Note *xen_crash_note;
 
@@ -165,7 +166,7 @@ static void one_cpu_only(void)
 void kexec_crash_save_cpu(void)
 {
     int cpu = smp_processor_id();
-    Elf_Note *note = per_cpu(crash_notes, cpu);
+    Elf_Note *note = crash_notes[cpu];
     ELF_Prstatus *prstatus;
     crash_xen_core_t *xencore;
 
@@ -245,25 +246,6 @@ static long kexec_reboot(void *_image)
     return 0;
 }
 
-static void do_crashdump_trigger(unsigned char key)
-{
-    printk("'%c' pressed -> triggering crashdump\n", key);
-    kexec_crash();
-    printk(" * no crash kernel loaded!\n");
-}
-
-static struct keyhandler crashdump_trigger_keyhandler = {
-    .u.fn = do_crashdump_trigger,
-    .desc = "trigger a crashdump"
-};
-
-static __init int register_crashdump_trigger(void)
-{
-    register_keyhandler('C', &crashdump_trigger_keyhandler);
-    return 0;
-}
-__initcall(register_crashdump_trigger);
-
 static void setup_note(Elf_Note *n, const char *name, int type, int descsz)
 {
     int l = strlen(name) + 1;
@@ -280,6 +262,110 @@ static int sizeof_note(const char *name,
             ELFNOTE_ALIGN(descsz));
 }
 
+/* Allocate a crash note buffer for a newly onlined cpu. */
+static int kexec_init_cpu_notes(const int cpu)
+{
+    Elf_Note * note;
+    int nr_bytes = 0;
+
+    BUG_ON( cpu < 0 || cpu >= NR_CPUS );
+
+    /* If already allocated, nothing to do. */
+    if ( crash_notes[cpu] )
+        return 0;
+
+    /* All CPUs present a PRSTATUS and crash_xen_core note. */
+    nr_bytes =
+        sizeof_note("CORE", sizeof(ELF_Prstatus)) +
+        sizeof_note("Xen", sizeof(crash_xen_core_t));
+
+    /* CPU0 also presents the crash_xen_info note. */
+    if ( 0 == cpu )
+        nr_bytes = nr_bytes +
+            sizeof_note("Xen", sizeof(crash_xen_info_t));
+
+    note = xmalloc_bytes(nr_bytes);
+    if ( ! note )
+        /* Ideally, this would be -ENOMEM.  However, there are more problems
+         * assocated with trying to deal with -ENOMEM sensibly than just
+         * pretending that the crash note area doesn't exist. */
+        return 0;
+
+    crash_notes[cpu] = note;
+
+    /* Setup CORE note. */
+    setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
+    note = ELFNOTE_NEXT(note);
+
+    /* Setup Xen CORE note. */
+    setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS,
+               sizeof(crash_xen_core_t));
+
+    if ( 0 == cpu )
+    {
+        /* Set up Xen Crash Info note. */
+        xen_crash_note = note = ELFNOTE_NEXT(note);
+        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO,
+                   sizeof(crash_xen_info_t));
+    }
+
+    return 0;
+}
+
+static void do_crashdump_trigger(unsigned char key)
+{
+    printk("'%c' pressed -> triggering crashdump\n", key);
+    kexec_crash();
+    printk(" * no crash kernel loaded!\n");
+}
+
+static struct keyhandler crashdump_trigger_keyhandler = {
+    .u.fn = do_crashdump_trigger,
+    .desc = "trigger a crashdump"
+};
+
+static int cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+
+    /* Only hook on CPU_UP_PREPARE because once a crash_note has been reported
+     * to dom0, it must keep it around in case of a crash, as the crash kernel
+     * will be hard coded to the original physical address reported. */
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        kexec_init_cpu_notes(cpu);
+        break;
+    default:
+        break;
+    }
+    return NOTIFY_DONE;
+}
+
+static struct notifier_block cpu_nfb = {
+    .notifier_call = cpu_callback
+};
+
+static int __init kexec_init(void)
+{
+    void *cpu = (void *)(long)smp_processor_id();
+
+    register_keyhandler('C', &crashdump_trigger_keyhandler);
+
+    /* If no crash area, no need to allocate space for notes. */
+    if ( 0 == kexec_crash_area.size )
+        return 0;
+
+    cpu_callback(&cpu_nfb, CPU_UP_PREPARE, cpu);
+    register_cpu_notifier(&cpu_nfb);
+    return 0;
+}
+/* The reason for this to be a presmp_initcall as opposed to a regular
+ * __initcall is to allow the setup of the cpu hotplug handler before APs are
+ * brought up. */
+presmp_initcall(kexec_init);
+
 static int kexec_get_reserve(xen_kexec_range_t *range)
 {
     if ( kexec_crash_area.size > 0 && kexec_crash_area.start > 0) {
@@ -296,7 +382,7 @@ static int kexec_get_cpu(xen_kexec_range
     int nr = range->nr;
     int nr_bytes = 0;
 
-    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) )
+    if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes[nr] )
         return -EINVAL;
 
     nr_bytes += sizeof_note("CORE", sizeof(ELF_Prstatus));
@@ -306,31 +392,7 @@ static int kexec_get_cpu(xen_kexec_range
     if ( nr == 0 )
         nr_bytes += sizeof_note("Xen", sizeof(crash_xen_info_t));
 
-    if ( per_cpu(crash_notes, nr) == NULL )
-    {
-        Elf_Note *note;
-
-        note = per_cpu(crash_notes, nr) = xmalloc_bytes(nr_bytes);
-
-        if ( note == NULL )
-            return -ENOMEM;
-
-        /* Setup CORE note. */
-        setup_note(note, "CORE", NT_PRSTATUS, sizeof(ELF_Prstatus));
-
-        /* Setup Xen CORE note. */
-        note = ELFNOTE_NEXT(note);
-        setup_note(note, "Xen", XEN_ELFNOTE_CRASH_REGS, sizeof(crash_xen_core_t));
-
-        if (nr == 0)
-        {
-            /* Setup system wide Xen info note. */
-            xen_crash_note = note = ELFNOTE_NEXT(note);
-            setup_note(note, "Xen", XEN_ELFNOTE_CRASH_INFO, sizeof(crash_xen_info_t));
-        }
-    }
-
-    range->start = __pa((unsigned long)per_cpu(crash_notes, nr));
+    range->start = __pa((unsigned long)crash_notes[nr]);
     range->size = nr_bytes;
     return 0;
 }

--------------040808070305050009070901
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040808070305050009070901--


From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:16:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:16:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoha-0001Eg-E0; Wed, 30 Nov 2011 18:16:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RVohZ-0001Eb-7h
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:16:13 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322676934!5657174!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzU3NjY=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzU3NjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30580 invoked from network); 30 Nov 2011 18:15:34 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187) by server-4.tower-216.messagelabs.com with SMTP;
	30 Nov 2011 18:15:34 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis)
	id 0Mfepz-1RBfGt06gN-00P5bO; Wed, 30 Nov 2011 19:15:04 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 30 Nov 2011 18:15:01 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322670473.31810.129.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201111301815.01297.arnd@arndb.de>
X-Provags-ID: V02:K0:0QF1cQvBrkFixJKucsdEWFs++J4ZdGCXd6xZLH0sUdP
	21sqNZwWW2YwtvqbQU2Vs+iQ4BgIvZVvo/jsjy2ecSHgQveLPk
	Tjz7jIsFzmcDdfNKxCi3i0SWyVisDmPvpwSOiWUs3+qYfYotgY
	SzSFXIT4rrefbhicv0lGTuxjkL8QLX8Rt+d+4AMJRi2qoyJNZk
	hjHtyd8Tvl4d8Pr4lm8BaAqnC29b/z/Ofz4aoYhjXHxQaVhYP1
	sa9U+vGtMYMM4pgmbuMUug7CKpm50HgsgC8Pyanp79QMu5i4kc
	GJLL0GRZ3vW3xUL2hHubZN0QyoqMEefw/Q7qX0RdMYvcLoHidJ
	nlIloH22xJUm+hwTXhNE=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wednesday 30 November 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
> > On Wednesday 30 November 2011, Ian Campbell wrote:
> > What I suggested to the KVM developers is to start out with the
> > vexpress platform, but then generalize it to the point where it fits
> > your needs. All hardware that one expects a guest to have (GIC, timer,
> > ...) will still show up in the same location as on a real vexpress,
> > while anything that makes no sense or is better paravirtualized (LCD,
> > storage, ...) just becomes optional and has to be described in the
> > device tree if it's actually there.
> 
> That's along the lines of what I was thinking as well.
> 
> The DT contains the address of GIC, timer etc as well right? So at least
> in principal we needn't provide e.g. the GIC at the same address as any
> real platform but in practice I expect we will.

Yes.

> In principal we could also offer the user options as to which particular
> platform a guest looks like.

At least when using a qemu based simulation. Most platforms have some
characteristics that are not meaningful in a classic virtualization
scenario, but it would certainly be helpful to use the virtualization
extensions to run a kernel that was built for a particular platform
faster than with pure qemu, when you want to test that kernel image.

It has been suggested in the past that it would be nice to run the
guest kernel built for the same platform as the host kernel by
default, but I think it would be much better to have just one
platform that we end up using for guests on any host platform,
unless there is a strong reason to do otherwise.

There is also ongoing restructuring in the ARM Linux kernel to
allow running the same kernel binary on multiple platforms. While
there is still a lot of work to be done, you should assume that
we will finish it before you see lots of users in production, there
is no need to plan for the current one-kernel-per-board case.

> > Ok. It would of course still be possible to agree on an argument passing
> > convention so that we can share the macros used to issue the hcalls,
> > even if the individual commands are all different.
> 
> I think it likely that we can all agree on a common calling convention
> for N-argument hypercalls. It doubt there are that many useful choices
> with conflicting requirements yet strongly compelling advantages.

Exactly. I think it's only lack of communication that has resulted in
different interfaces for each hypervisor on the other architectures.

KVM and Xen at least both fall into the single-return-value category,
so we should be able to agree on a calling conventions. KVM does not
have an hcall API on ARM yet, and I see no reason not to use the
same implementation that you have in the Xen guest.

Stefano, can you split out the generic parts of your asm/xen/hypercall.h
file into a common asm/hypercall.h and submit it for review to the
arm kernel list?

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:16:42 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:16:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoha-0001Eg-E0; Wed, 30 Nov 2011 18:16:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1RVohZ-0001Eb-7h
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:16:13 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-4.tower-216.messagelabs.com!1322676934!5657174!1
X-Originating-IP: [212.227.126.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzU3NjY=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODcgPT4gNzU3NjY=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30580 invoked from network); 30 Nov 2011 18:15:34 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.187) by server-4.tower-216.messagelabs.com with SMTP;
	30 Nov 2011 18:15:34 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis)
	id 0Mfepz-1RBfGt06gN-00P5bO; Wed, 30 Nov 2011 19:15:04 +0100
From: Arnd Bergmann <arnd@arndb.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 30 Nov 2011 18:15:01 +0000
User-Agent: KMail/1.12.2 (Linux/3.2.0-rc1+; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
In-Reply-To: <1322670473.31810.129.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201111301815.01297.arnd@arndb.de>
X-Provags-ID: V02:K0:0QF1cQvBrkFixJKucsdEWFs++J4ZdGCXd6xZLH0sUdP
	21sqNZwWW2YwtvqbQU2Vs+iQ4BgIvZVvo/jsjy2ecSHgQveLPk
	Tjz7jIsFzmcDdfNKxCi3i0SWyVisDmPvpwSOiWUs3+qYfYotgY
	SzSFXIT4rrefbhicv0lGTuxjkL8QLX8Rt+d+4AMJRi2qoyJNZk
	hjHtyd8Tvl4d8Pr4lm8BaAqnC29b/z/Ofz4aoYhjXHxQaVhYP1
	sa9U+vGtMYMM4pgmbuMUug7CKpm50HgsgC8Pyanp79QMu5i4kc
	GJLL0GRZ3vW3xUL2hHubZN0QyoqMEefw/Q7qX0RdMYvcLoHidJ
	nlIloH22xJUm+hwTXhNE=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen port to Cortex-A15 / ARMv7 with virt
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wednesday 30 November 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
> > On Wednesday 30 November 2011, Ian Campbell wrote:
> > What I suggested to the KVM developers is to start out with the
> > vexpress platform, but then generalize it to the point where it fits
> > your needs. All hardware that one expects a guest to have (GIC, timer,
> > ...) will still show up in the same location as on a real vexpress,
> > while anything that makes no sense or is better paravirtualized (LCD,
> > storage, ...) just becomes optional and has to be described in the
> > device tree if it's actually there.
> 
> That's along the lines of what I was thinking as well.
> 
> The DT contains the address of GIC, timer etc as well right? So at least
> in principal we needn't provide e.g. the GIC at the same address as any
> real platform but in practice I expect we will.

Yes.

> In principal we could also offer the user options as to which particular
> platform a guest looks like.

At least when using a qemu based simulation. Most platforms have some
characteristics that are not meaningful in a classic virtualization
scenario, but it would certainly be helpful to use the virtualization
extensions to run a kernel that was built for a particular platform
faster than with pure qemu, when you want to test that kernel image.

It has been suggested in the past that it would be nice to run the
guest kernel built for the same platform as the host kernel by
default, but I think it would be much better to have just one
platform that we end up using for guests on any host platform,
unless there is a strong reason to do otherwise.

There is also ongoing restructuring in the ARM Linux kernel to
allow running the same kernel binary on multiple platforms. While
there is still a lot of work to be done, you should assume that
we will finish it before you see lots of users in production, there
is no need to plan for the current one-kernel-per-board case.

> > Ok. It would of course still be possible to agree on an argument passing
> > convention so that we can share the macros used to issue the hcalls,
> > even if the individual commands are all different.
> 
> I think it likely that we can all agree on a common calling convention
> for N-argument hypercalls. It doubt there are that many useful choices
> with conflicting requirements yet strongly compelling advantages.

Exactly. I think it's only lack of communication that has resulted in
different interfaces for each hypervisor on the other architectures.

KVM and Xen at least both fall into the single-return-value category,
so we should be able to agree on a calling conventions. KVM does not
have an hcall API on ARM yet, and I see no reason not to use the
same implementation that you have in the Xen guest.

Stefano, can you split out the generic parts of your asm/xen/hypercall.h
file into a common asm/hypercall.h and submit it for review to the
arm kernel list?

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:17:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoiY-0001IW-I4; Wed, 30 Nov 2011 18:17:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVoiX-0001Hq-9o
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:17:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322676992!3553112!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26960 invoked from network); 30 Nov 2011 18:16:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 18:16:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUIGRMs019310
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 18:16:28 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUIGQfC026500
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 18:16:27 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUIGLtM028798; Wed, 30 Nov 2011 12:16:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 10:16:20 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id CAC4C41C2D;
	Wed, 30 Nov 2011 13:15:59 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUIFxdo015811;
	Wed, 30 Nov 2011 13:15:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, lidongyang@novell.com, JBeulich@novell.com
Date: Wed, 30 Nov 2011 13:15:52 -0500
Message-Id: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020206.4ED672FD.00EB,ss=1,re=0.000,fgs=0
Cc: axboe@kernel.dk
Subject: [Xen-devel] [PATCH] Xen block improvements for 3.3 [secure-discard
	flag](v1)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Way back in 3.2 time-frame we worked out some of these patches and how
to improve the code. I don't think I had posted them after we chatted
about what to do or how to do it...

Either way, posting them here to kick-start the conversation and
see if we can improve these patches some more. I've been running
with these patches for some time now so I am quite confident that I got
the 32-bit to 64-bit structure padding worked out.

(Ran it with old guests/new guests/32-bit/64-bit/Linux/Windows
combination. Around 18 different scenarios).

Konrad Rzeszutek Wilk (3):
      xen/blk[front|back]: Squash blkif_request_rw and blkif_request_discard together
      xen/blk[front|back]: Enhance discard support with secure erasing support.
      xen/blkback: Move processing of BLKIF_OP_DISCARD from dispatch_rw_block_io

Li Dongyang (1):
      xen-blkback: convert hole punching to discard request on loop devices

 drivers/block/xen-blkback/blkback.c |   84 ++++++++++++++--------------------
 drivers/block/xen-blkback/common.h  |   67 ++++++++++++++++------------
 drivers/block/xen-blkback/xenbus.c  |   12 +++++
 drivers/block/xen-blkfront.c        |   77 +++++++++++++++++++++-----------
 include/xen/interface/io/blkif.h    |   40 ++++++++++++++---
 5 files changed, 169 insertions(+), 111 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:17:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoiY-0001IW-I4; Wed, 30 Nov 2011 18:17:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVoiX-0001Hq-9o
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:17:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322676992!3553112!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26960 invoked from network); 30 Nov 2011 18:16:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 18:16:34 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUIGRMs019310
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 18:16:28 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUIGQfC026500
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 18:16:27 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUIGLtM028798; Wed, 30 Nov 2011 12:16:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 10:16:20 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id CAC4C41C2D;
	Wed, 30 Nov 2011 13:15:59 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUIFxdo015811;
	Wed, 30 Nov 2011 13:15:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, lidongyang@novell.com, JBeulich@novell.com
Date: Wed, 30 Nov 2011 13:15:52 -0500
Message-Id: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020206.4ED672FD.00EB,ss=1,re=0.000,fgs=0
Cc: axboe@kernel.dk
Subject: [Xen-devel] [PATCH] Xen block improvements for 3.3 [secure-discard
	flag](v1)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Way back in 3.2 time-frame we worked out some of these patches and how
to improve the code. I don't think I had posted them after we chatted
about what to do or how to do it...

Either way, posting them here to kick-start the conversation and
see if we can improve these patches some more. I've been running
with these patches for some time now so I am quite confident that I got
the 32-bit to 64-bit structure padding worked out.

(Ran it with old guests/new guests/32-bit/64-bit/Linux/Windows
combination. Around 18 different scenarios).

Konrad Rzeszutek Wilk (3):
      xen/blk[front|back]: Squash blkif_request_rw and blkif_request_discard together
      xen/blk[front|back]: Enhance discard support with secure erasing support.
      xen/blkback: Move processing of BLKIF_OP_DISCARD from dispatch_rw_block_io

Li Dongyang (1):
      xen-blkback: convert hole punching to discard request on loop devices

 drivers/block/xen-blkback/blkback.c |   84 ++++++++++++++--------------------
 drivers/block/xen-blkback/common.h  |   67 ++++++++++++++++------------
 drivers/block/xen-blkback/xenbus.c  |   12 +++++
 drivers/block/xen-blkfront.c        |   77 +++++++++++++++++++++-----------
 include/xen/interface/io/blkif.h    |   40 ++++++++++++++---
 5 files changed, 169 insertions(+), 111 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:17:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoib-0001JF-QW; Wed, 30 Nov 2011 18:17:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVoiZ-0001Hz-Jd
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:17:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322676994!3758215!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDIwMzk5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10037 invoked from network); 30 Nov 2011 18:16:36 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 18:16:36 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUIGSpe000458
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 18:16:29 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUIGRnR007463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 18:16:28 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUIGLqD010078; Wed, 30 Nov 2011 12:16:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 10:16:21 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id F25D641C2F;
	Wed, 30 Nov 2011 13:15:59 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUIFxWl015814;
	Wed, 30 Nov 2011 13:15:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, lidongyang@novell.com, JBeulich@novell.com
Date: Wed, 30 Nov 2011 13:15:53 -0500
Message-Id: <1322676956-15691-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
References: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4ED672FD.008A,ss=1,re=-2.300,fgs=0
Cc: axboe@kernel.dk, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/4] xen/blk[front|back]: Squash
	blkif_request_rw and blkif_request_discard together
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In a union type structure to deal with the overlapping
attributes in a easier manner.

Suggested-by: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c |   13 ++++---
 drivers/block/xen-blkback/common.h  |   64 +++++++++++++++++++---------------
 drivers/block/xen-blkfront.c        |   44 ++++++++++++-----------
 include/xen/interface/io/blkif.h    |   24 +++++++++----
 4 files changed, 83 insertions(+), 62 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 15ec4db..d7104ab 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -362,7 +362,7 @@ static int xen_blkbk_map(struct blkif_request *req,
 {
 	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 	int i;
-	int nseg = req->nr_segments;
+	int nseg = req->u.rw.nr_segments;
 	int ret = 0;
 
 	/*
@@ -449,7 +449,7 @@ static void xen_blk_discard(struct xen_blkif *blkif, struct blkif_request *req)
 	} else if (err)
 		status = BLKIF_RSP_ERROR;
 
-	make_response(blkif, req->id, req->operation, status);
+	make_response(blkif, req->u.discard.id, req->operation, status);
 }
 
 static void xen_blk_drain_io(struct xen_blkif *blkif)
@@ -644,7 +644,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	}
 
 	/* Check that the number of segments is sane. */
-	nseg = req->nr_segments;
+	nseg = req->u.rw.nr_segments;
+
 	if (unlikely(nseg == 0 && operation != WRITE_FLUSH &&
 				operation != REQ_DISCARD) ||
 	    unlikely(nseg > BLKIF_MAX_SEGMENTS_PER_REQUEST)) {
@@ -654,12 +655,12 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 		goto fail_response;
 	}
 
-	preq.dev           = req->handle;
+	preq.dev           = req->u.rw.handle;
 	preq.sector_number = req->u.rw.sector_number;
 	preq.nr_sects      = 0;
 
 	pending_req->blkif     = blkif;
-	pending_req->id        = req->id;
+	pending_req->id        = req->u.rw.id;
 	pending_req->operation = req->operation;
 	pending_req->status    = BLKIF_RSP_OKAY;
 	pending_req->nr_pages  = nseg;
@@ -784,7 +785,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	xen_blkbk_unmap(pending_req);
  fail_response:
 	/* Haven't submitted any bio's yet. */
-	make_response(blkif, req->id, req->operation, BLKIF_RSP_ERROR);
+	make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
 	free_req(pending_req);
 	msleep(1); /* back off a bit */
 	return -EIO;
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index dfb1b3a..dbfe7b3 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -60,58 +60,66 @@ struct blkif_common_response {
 	char dummy;
 };
 
-/* i386 protocol version */
-#pragma pack(push, 4)
-
 struct blkif_x86_32_request_rw {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   handle;       /* only for read/write requests         */
+	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
 	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-};
+} __attribute__((__packed__));
 
 struct blkif_x86_32_request_discard {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   _pad1;        /* was "handle" for read/write requests */
+	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	uint64_t nr_sectors;
-};
+	uint64_t       nr_sectors;
+} __attribute__((__packed__));
 
 struct blkif_x86_32_request {
 	uint8_t        operation;    /* BLKIF_OP_???                         */
-	uint8_t        nr_segments;  /* number of segments                   */
-	blkif_vdev_t   handle;       /* only for read/write requests         */
-	uint64_t       id;           /* private guest value, echoed in resp  */
 	union {
 		struct blkif_x86_32_request_rw rw;
 		struct blkif_x86_32_request_discard discard;
 	} u;
-};
+} __attribute__((__packed__));
+
+/* i386 protocol version */
+#pragma pack(push, 4)
 struct blkif_x86_32_response {
 	uint64_t        id;              /* copied from request */
 	uint8_t         operation;       /* copied from request */
 	int16_t         status;          /* BLKIF_RSP_???       */
 };
 #pragma pack(pop)
-
 /* x86_64 protocol version */
 
 struct blkif_x86_64_request_rw {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   handle;       /* only for read/write requests         */
+	uint32_t       _pad1;        /* offsetof(blkif_reqest..,u.rw.id)==8  */
+	uint64_t       id;
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
 	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-};
+} __attribute__((__packed__));
 
 struct blkif_x86_64_request_discard {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   _pad1;        /* was "handle" for read/write requests */
+        uint32_t       _pad2;        /* offsetof(blkif_..,u.discard.id)==8   */
+	uint64_t       id;
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	uint64_t nr_sectors;
-};
+	uint64_t       nr_sectors;
+} __attribute__((__packed__));
 
 struct blkif_x86_64_request {
 	uint8_t        operation;    /* BLKIF_OP_???                         */
-	uint8_t        nr_segments;  /* number of segments                   */
-	blkif_vdev_t   handle;       /* only for read/write requests         */
-	uint64_t       __attribute__((__aligned__(8))) id;
 	union {
 		struct blkif_x86_64_request_rw rw;
 		struct blkif_x86_64_request_discard discard;
 	} u;
-};
+} __attribute__((__packed__));
+
 struct blkif_x86_64_response {
 	uint64_t       __attribute__((__aligned__(8))) id;
 	uint8_t         operation;       /* copied from request */
@@ -237,18 +245,18 @@ static inline void blkif_get_x86_32_req(struct blkif_request *dst,
 {
 	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
 	dst->operation = src->operation;
-	dst->nr_segments = src->nr_segments;
-	dst->handle = src->handle;
-	dst->id = src->id;
 	switch (src->operation) {
 	case BLKIF_OP_READ:
 	case BLKIF_OP_WRITE:
 	case BLKIF_OP_WRITE_BARRIER:
 	case BLKIF_OP_FLUSH_DISKCACHE:
+		dst->u.rw.nr_segments = src->u.rw.nr_segments;
+		dst->u.rw.handle = src->u.rw.handle;
+		dst->u.rw.id = src->u.rw.id;
 		dst->u.rw.sector_number = src->u.rw.sector_number;
 		barrier();
-		if (n > dst->nr_segments)
-			n = dst->nr_segments;
+		if (n > dst->u.rw.nr_segments)
+			n = dst->u.rw.nr_segments;
 		for (i = 0; i < n; i++)
 			dst->u.rw.seg[i] = src->u.rw.seg[i];
 		break;
@@ -266,18 +274,18 @@ static inline void blkif_get_x86_64_req(struct blkif_request *dst,
 {
 	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
 	dst->operation = src->operation;
-	dst->nr_segments = src->nr_segments;
-	dst->handle = src->handle;
-	dst->id = src->id;
 	switch (src->operation) {
 	case BLKIF_OP_READ:
 	case BLKIF_OP_WRITE:
 	case BLKIF_OP_WRITE_BARRIER:
 	case BLKIF_OP_FLUSH_DISKCACHE:
+		dst->u.rw.nr_segments = src->u.rw.nr_segments;
+		dst->u.rw.handle = src->u.rw.handle;
+		dst->u.rw.id = src->u.rw.id;
 		dst->u.rw.sector_number = src->u.rw.sector_number;
 		barrier();
-		if (n > dst->nr_segments)
-			n = dst->nr_segments;
+		if (n > dst->u.rw.nr_segments)
+			n = dst->u.rw.nr_segments;
 		for (i = 0; i < n; i++)
 			dst->u.rw.seg[i] = src->u.rw.seg[i];
 		break;
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 7b2ec59..2c2c4be 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -135,15 +135,15 @@ static int get_id_from_freelist(struct blkfront_info *info)
 {
 	unsigned long free = info->shadow_free;
 	BUG_ON(free >= BLK_RING_SIZE);
-	info->shadow_free = info->shadow[free].req.id;
-	info->shadow[free].req.id = 0x0fffffee; /* debug */
+	info->shadow_free = info->shadow[free].req.u.rw.id;
+	info->shadow[free].req.u.rw.id = 0x0fffffee; /* debug */
 	return free;
 }
 
 static void add_id_to_freelist(struct blkfront_info *info,
 			       unsigned long id)
 {
-	info->shadow[id].req.id  = info->shadow_free;
+	info->shadow[id].req.u.rw.id  = info->shadow_free;
 	info->shadow[id].request = NULL;
 	info->shadow_free = id;
 }
@@ -287,9 +287,9 @@ static int blkif_queue_request(struct request *req)
 	id = get_id_from_freelist(info);
 	info->shadow[id].request = req;
 
-	ring_req->id = id;
+	ring_req->u.rw.id = id;
 	ring_req->u.rw.sector_number = (blkif_sector_t)blk_rq_pos(req);
-	ring_req->handle = info->handle;
+	ring_req->u.rw.handle = info->handle;
 
 	ring_req->operation = rq_data_dir(req) ?
 		BLKIF_OP_WRITE : BLKIF_OP_READ;
@@ -308,13 +308,15 @@ static int blkif_queue_request(struct request *req)
 	if (unlikely(req->cmd_flags & REQ_DISCARD)) {
 		/* id, sector_number and handle are set above. */
 		ring_req->operation = BLKIF_OP_DISCARD;
-		ring_req->nr_segments = 0;
+		ring_req->u.discard.nr_segments = 0;
 		ring_req->u.discard.nr_sectors = blk_rq_sectors(req);
 	} else {
-		ring_req->nr_segments = blk_rq_map_sg(req->q, req, info->sg);
-		BUG_ON(ring_req->nr_segments > BLKIF_MAX_SEGMENTS_PER_REQUEST);
+		ring_req->u.rw.nr_segments = blk_rq_map_sg(req->q, req,
+							   info->sg);
+		BUG_ON(ring_req->u.rw.nr_segments >
+		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
-		for_each_sg(info->sg, sg, ring_req->nr_segments, i) {
+		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
 			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
@@ -705,7 +707,7 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 static void blkif_completion(struct blk_shadow *s)
 {
 	int i;
-	for (i = 0; i < s->req.nr_segments; i++)
+	for (i = 0; i < s->req.u.rw.nr_segments; i++)
 		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
 }
 
@@ -763,7 +765,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
-				     info->shadow[id].req.nr_segments == 0)) {
+				     info->shadow[id].req.u.rw.nr_segments == 0)) {
 				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
 				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
 				       "barrier" :  "flush disk cache",
@@ -984,8 +986,8 @@ static int blkfront_probe(struct xenbus_device *dev,
 	INIT_WORK(&info->work, blkif_restart_queue);
 
 	for (i = 0; i < BLK_RING_SIZE; i++)
-		info->shadow[i].req.id = i+1;
-	info->shadow[BLK_RING_SIZE-1].req.id = 0x0fffffff;
+		info->shadow[i].req.u.rw.id = i+1;
+	info->shadow[BLK_RING_SIZE-1].req.u.rw.id = 0x0fffffff;
 
 	/* Front end dir is a number, which is used as the id. */
 	info->handle = simple_strtoul(strrchr(dev->nodename, '/')+1, NULL, 0);
@@ -1019,9 +1021,9 @@ static int blkif_recover(struct blkfront_info *info)
 	/* Stage 2: Set up free list. */
 	memset(&info->shadow, 0, sizeof(info->shadow));
 	for (i = 0; i < BLK_RING_SIZE; i++)
-		info->shadow[i].req.id = i+1;
+		info->shadow[i].req.u.rw.id = i+1;
 	info->shadow_free = info->ring.req_prod_pvt;
-	info->shadow[BLK_RING_SIZE-1].req.id = 0x0fffffff;
+	info->shadow[BLK_RING_SIZE-1].req.u.rw.id = 0x0fffffff;
 
 	/* Stage 3: Find pending requests and requeue them. */
 	for (i = 0; i < BLK_RING_SIZE; i++) {
@@ -1034,17 +1036,17 @@ static int blkif_recover(struct blkfront_info *info)
 		*req = copy[i].req;
 
 		/* We get a new request id, and must reset the shadow state. */
-		req->id = get_id_from_freelist(info);
-		memcpy(&info->shadow[req->id], &copy[i], sizeof(copy[i]));
+		req->u.rw.id = get_id_from_freelist(info);
+		memcpy(&info->shadow[req->u.rw.id], &copy[i], sizeof(copy[i]));
 
 		/* Rewrite any grant references invalidated by susp/resume. */
-		for (j = 0; j < req->nr_segments; j++)
+		for (j = 0; j < req->u.rw.nr_segments; j++)
 			gnttab_grant_foreign_access_ref(
 				req->u.rw.seg[j].gref,
 				info->xbdev->otherend_id,
-				pfn_to_mfn(info->shadow[req->id].frame[j]),
-				rq_data_dir(info->shadow[req->id].request));
-		info->shadow[req->id].req = *req;
+				pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
+				rq_data_dir(info->shadow[req->u.rw.id].request));
+		info->shadow[req->u.rw.id].req = *req;
 
 		info->ring.req_prod_pvt++;
 	}
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index 9324488..f88e28b 100644
--- a/include/xen/interface/io/blkif.h
+++ b/include/xen/interface/io/blkif.h
@@ -95,6 +95,12 @@ typedef uint64_t blkif_sector_t;
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
 struct blkif_request_rw {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   handle;       /* only for read/write requests         */
+#ifdef CONFIG_X86_64
+	uint32_t       _pad1;	     /* offsetof(blkif_request,u.rw.id) == 8 */
+#endif
+	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
 	struct blkif_request_segment {
 		grant_ref_t gref;        /* reference to I/O buffer frame        */
@@ -102,23 +108,27 @@ struct blkif_request_rw {
 		/* @last_sect: last sector in frame to transfer (inclusive).     */
 		uint8_t     first_sect, last_sect;
 	} seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-};
+} __attribute__((__packed__));
 
 struct blkif_request_discard {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   _pad1;        /* only for read/write requests         */
+#ifdef CONFIG_X86_64
+	uint32_t       _pad2;        /* offsetof(blkif_req..,u.discard.id)==8*/
+#endif
+	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;
-	uint64_t nr_sectors;
-};
+	uint64_t       nr_sectors;
+	uint8_t        _pad3;
+} __attribute__((__packed__));
 
 struct blkif_request {
 	uint8_t        operation;    /* BLKIF_OP_???                         */
-	uint8_t        nr_segments;  /* number of segments                   */
-	blkif_vdev_t   handle;       /* only for read/write requests         */
-	uint64_t       id;           /* private guest value, echoed in resp  */
 	union {
 		struct blkif_request_rw rw;
 		struct blkif_request_discard discard;
 	} u;
-};
+} __attribute__((__packed__));
 
 struct blkif_response {
 	uint64_t        id;              /* copied from request */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:17:32 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:17:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoib-0001JF-QW; Wed, 30 Nov 2011 18:17:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVoiZ-0001Hz-Jd
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:17:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1322676994!3758215!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDIwMzk5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10037 invoked from network); 30 Nov 2011 18:16:36 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 18:16:36 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUIGSpe000458
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 18:16:29 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUIGRnR007463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 18:16:28 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUIGLqD010078; Wed, 30 Nov 2011 12:16:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 10:16:21 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id F25D641C2F;
	Wed, 30 Nov 2011 13:15:59 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUIFxWl015814;
	Wed, 30 Nov 2011 13:15:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, lidongyang@novell.com, JBeulich@novell.com
Date: Wed, 30 Nov 2011 13:15:53 -0500
Message-Id: <1322676956-15691-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
References: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4ED672FD.008A,ss=1,re=-2.300,fgs=0
Cc: axboe@kernel.dk, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/4] xen/blk[front|back]: Squash
	blkif_request_rw and blkif_request_discard together
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In a union type structure to deal with the overlapping
attributes in a easier manner.

Suggested-by: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c |   13 ++++---
 drivers/block/xen-blkback/common.h  |   64 +++++++++++++++++++---------------
 drivers/block/xen-blkfront.c        |   44 ++++++++++++-----------
 include/xen/interface/io/blkif.h    |   24 +++++++++----
 4 files changed, 83 insertions(+), 62 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 15ec4db..d7104ab 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -362,7 +362,7 @@ static int xen_blkbk_map(struct blkif_request *req,
 {
 	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 	int i;
-	int nseg = req->nr_segments;
+	int nseg = req->u.rw.nr_segments;
 	int ret = 0;
 
 	/*
@@ -449,7 +449,7 @@ static void xen_blk_discard(struct xen_blkif *blkif, struct blkif_request *req)
 	} else if (err)
 		status = BLKIF_RSP_ERROR;
 
-	make_response(blkif, req->id, req->operation, status);
+	make_response(blkif, req->u.discard.id, req->operation, status);
 }
 
 static void xen_blk_drain_io(struct xen_blkif *blkif)
@@ -644,7 +644,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	}
 
 	/* Check that the number of segments is sane. */
-	nseg = req->nr_segments;
+	nseg = req->u.rw.nr_segments;
+
 	if (unlikely(nseg == 0 && operation != WRITE_FLUSH &&
 				operation != REQ_DISCARD) ||
 	    unlikely(nseg > BLKIF_MAX_SEGMENTS_PER_REQUEST)) {
@@ -654,12 +655,12 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 		goto fail_response;
 	}
 
-	preq.dev           = req->handle;
+	preq.dev           = req->u.rw.handle;
 	preq.sector_number = req->u.rw.sector_number;
 	preq.nr_sects      = 0;
 
 	pending_req->blkif     = blkif;
-	pending_req->id        = req->id;
+	pending_req->id        = req->u.rw.id;
 	pending_req->operation = req->operation;
 	pending_req->status    = BLKIF_RSP_OKAY;
 	pending_req->nr_pages  = nseg;
@@ -784,7 +785,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	xen_blkbk_unmap(pending_req);
  fail_response:
 	/* Haven't submitted any bio's yet. */
-	make_response(blkif, req->id, req->operation, BLKIF_RSP_ERROR);
+	make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
 	free_req(pending_req);
 	msleep(1); /* back off a bit */
 	return -EIO;
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index dfb1b3a..dbfe7b3 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -60,58 +60,66 @@ struct blkif_common_response {
 	char dummy;
 };
 
-/* i386 protocol version */
-#pragma pack(push, 4)
-
 struct blkif_x86_32_request_rw {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   handle;       /* only for read/write requests         */
+	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
 	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-};
+} __attribute__((__packed__));
 
 struct blkif_x86_32_request_discard {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   _pad1;        /* was "handle" for read/write requests */
+	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	uint64_t nr_sectors;
-};
+	uint64_t       nr_sectors;
+} __attribute__((__packed__));
 
 struct blkif_x86_32_request {
 	uint8_t        operation;    /* BLKIF_OP_???                         */
-	uint8_t        nr_segments;  /* number of segments                   */
-	blkif_vdev_t   handle;       /* only for read/write requests         */
-	uint64_t       id;           /* private guest value, echoed in resp  */
 	union {
 		struct blkif_x86_32_request_rw rw;
 		struct blkif_x86_32_request_discard discard;
 	} u;
-};
+} __attribute__((__packed__));
+
+/* i386 protocol version */
+#pragma pack(push, 4)
 struct blkif_x86_32_response {
 	uint64_t        id;              /* copied from request */
 	uint8_t         operation;       /* copied from request */
 	int16_t         status;          /* BLKIF_RSP_???       */
 };
 #pragma pack(pop)
-
 /* x86_64 protocol version */
 
 struct blkif_x86_64_request_rw {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   handle;       /* only for read/write requests         */
+	uint32_t       _pad1;        /* offsetof(blkif_reqest..,u.rw.id)==8  */
+	uint64_t       id;
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
 	struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-};
+} __attribute__((__packed__));
 
 struct blkif_x86_64_request_discard {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   _pad1;        /* was "handle" for read/write requests */
+        uint32_t       _pad2;        /* offsetof(blkif_..,u.discard.id)==8   */
+	uint64_t       id;
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
-	uint64_t nr_sectors;
-};
+	uint64_t       nr_sectors;
+} __attribute__((__packed__));
 
 struct blkif_x86_64_request {
 	uint8_t        operation;    /* BLKIF_OP_???                         */
-	uint8_t        nr_segments;  /* number of segments                   */
-	blkif_vdev_t   handle;       /* only for read/write requests         */
-	uint64_t       __attribute__((__aligned__(8))) id;
 	union {
 		struct blkif_x86_64_request_rw rw;
 		struct blkif_x86_64_request_discard discard;
 	} u;
-};
+} __attribute__((__packed__));
+
 struct blkif_x86_64_response {
 	uint64_t       __attribute__((__aligned__(8))) id;
 	uint8_t         operation;       /* copied from request */
@@ -237,18 +245,18 @@ static inline void blkif_get_x86_32_req(struct blkif_request *dst,
 {
 	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
 	dst->operation = src->operation;
-	dst->nr_segments = src->nr_segments;
-	dst->handle = src->handle;
-	dst->id = src->id;
 	switch (src->operation) {
 	case BLKIF_OP_READ:
 	case BLKIF_OP_WRITE:
 	case BLKIF_OP_WRITE_BARRIER:
 	case BLKIF_OP_FLUSH_DISKCACHE:
+		dst->u.rw.nr_segments = src->u.rw.nr_segments;
+		dst->u.rw.handle = src->u.rw.handle;
+		dst->u.rw.id = src->u.rw.id;
 		dst->u.rw.sector_number = src->u.rw.sector_number;
 		barrier();
-		if (n > dst->nr_segments)
-			n = dst->nr_segments;
+		if (n > dst->u.rw.nr_segments)
+			n = dst->u.rw.nr_segments;
 		for (i = 0; i < n; i++)
 			dst->u.rw.seg[i] = src->u.rw.seg[i];
 		break;
@@ -266,18 +274,18 @@ static inline void blkif_get_x86_64_req(struct blkif_request *dst,
 {
 	int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
 	dst->operation = src->operation;
-	dst->nr_segments = src->nr_segments;
-	dst->handle = src->handle;
-	dst->id = src->id;
 	switch (src->operation) {
 	case BLKIF_OP_READ:
 	case BLKIF_OP_WRITE:
 	case BLKIF_OP_WRITE_BARRIER:
 	case BLKIF_OP_FLUSH_DISKCACHE:
+		dst->u.rw.nr_segments = src->u.rw.nr_segments;
+		dst->u.rw.handle = src->u.rw.handle;
+		dst->u.rw.id = src->u.rw.id;
 		dst->u.rw.sector_number = src->u.rw.sector_number;
 		barrier();
-		if (n > dst->nr_segments)
-			n = dst->nr_segments;
+		if (n > dst->u.rw.nr_segments)
+			n = dst->u.rw.nr_segments;
 		for (i = 0; i < n; i++)
 			dst->u.rw.seg[i] = src->u.rw.seg[i];
 		break;
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 7b2ec59..2c2c4be 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -135,15 +135,15 @@ static int get_id_from_freelist(struct blkfront_info *info)
 {
 	unsigned long free = info->shadow_free;
 	BUG_ON(free >= BLK_RING_SIZE);
-	info->shadow_free = info->shadow[free].req.id;
-	info->shadow[free].req.id = 0x0fffffee; /* debug */
+	info->shadow_free = info->shadow[free].req.u.rw.id;
+	info->shadow[free].req.u.rw.id = 0x0fffffee; /* debug */
 	return free;
 }
 
 static void add_id_to_freelist(struct blkfront_info *info,
 			       unsigned long id)
 {
-	info->shadow[id].req.id  = info->shadow_free;
+	info->shadow[id].req.u.rw.id  = info->shadow_free;
 	info->shadow[id].request = NULL;
 	info->shadow_free = id;
 }
@@ -287,9 +287,9 @@ static int blkif_queue_request(struct request *req)
 	id = get_id_from_freelist(info);
 	info->shadow[id].request = req;
 
-	ring_req->id = id;
+	ring_req->u.rw.id = id;
 	ring_req->u.rw.sector_number = (blkif_sector_t)blk_rq_pos(req);
-	ring_req->handle = info->handle;
+	ring_req->u.rw.handle = info->handle;
 
 	ring_req->operation = rq_data_dir(req) ?
 		BLKIF_OP_WRITE : BLKIF_OP_READ;
@@ -308,13 +308,15 @@ static int blkif_queue_request(struct request *req)
 	if (unlikely(req->cmd_flags & REQ_DISCARD)) {
 		/* id, sector_number and handle are set above. */
 		ring_req->operation = BLKIF_OP_DISCARD;
-		ring_req->nr_segments = 0;
+		ring_req->u.discard.nr_segments = 0;
 		ring_req->u.discard.nr_sectors = blk_rq_sectors(req);
 	} else {
-		ring_req->nr_segments = blk_rq_map_sg(req->q, req, info->sg);
-		BUG_ON(ring_req->nr_segments > BLKIF_MAX_SEGMENTS_PER_REQUEST);
+		ring_req->u.rw.nr_segments = blk_rq_map_sg(req->q, req,
+							   info->sg);
+		BUG_ON(ring_req->u.rw.nr_segments >
+		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
-		for_each_sg(info->sg, sg, ring_req->nr_segments, i) {
+		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
 			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
@@ -705,7 +707,7 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 static void blkif_completion(struct blk_shadow *s)
 {
 	int i;
-	for (i = 0; i < s->req.nr_segments; i++)
+	for (i = 0; i < s->req.u.rw.nr_segments; i++)
 		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
 }
 
@@ -763,7 +765,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 				error = -EOPNOTSUPP;
 			}
 			if (unlikely(bret->status == BLKIF_RSP_ERROR &&
-				     info->shadow[id].req.nr_segments == 0)) {
+				     info->shadow[id].req.u.rw.nr_segments == 0)) {
 				printk(KERN_WARNING "blkfront: %s: empty write %s op failed\n",
 				       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
 				       "barrier" :  "flush disk cache",
@@ -984,8 +986,8 @@ static int blkfront_probe(struct xenbus_device *dev,
 	INIT_WORK(&info->work, blkif_restart_queue);
 
 	for (i = 0; i < BLK_RING_SIZE; i++)
-		info->shadow[i].req.id = i+1;
-	info->shadow[BLK_RING_SIZE-1].req.id = 0x0fffffff;
+		info->shadow[i].req.u.rw.id = i+1;
+	info->shadow[BLK_RING_SIZE-1].req.u.rw.id = 0x0fffffff;
 
 	/* Front end dir is a number, which is used as the id. */
 	info->handle = simple_strtoul(strrchr(dev->nodename, '/')+1, NULL, 0);
@@ -1019,9 +1021,9 @@ static int blkif_recover(struct blkfront_info *info)
 	/* Stage 2: Set up free list. */
 	memset(&info->shadow, 0, sizeof(info->shadow));
 	for (i = 0; i < BLK_RING_SIZE; i++)
-		info->shadow[i].req.id = i+1;
+		info->shadow[i].req.u.rw.id = i+1;
 	info->shadow_free = info->ring.req_prod_pvt;
-	info->shadow[BLK_RING_SIZE-1].req.id = 0x0fffffff;
+	info->shadow[BLK_RING_SIZE-1].req.u.rw.id = 0x0fffffff;
 
 	/* Stage 3: Find pending requests and requeue them. */
 	for (i = 0; i < BLK_RING_SIZE; i++) {
@@ -1034,17 +1036,17 @@ static int blkif_recover(struct blkfront_info *info)
 		*req = copy[i].req;
 
 		/* We get a new request id, and must reset the shadow state. */
-		req->id = get_id_from_freelist(info);
-		memcpy(&info->shadow[req->id], &copy[i], sizeof(copy[i]));
+		req->u.rw.id = get_id_from_freelist(info);
+		memcpy(&info->shadow[req->u.rw.id], &copy[i], sizeof(copy[i]));
 
 		/* Rewrite any grant references invalidated by susp/resume. */
-		for (j = 0; j < req->nr_segments; j++)
+		for (j = 0; j < req->u.rw.nr_segments; j++)
 			gnttab_grant_foreign_access_ref(
 				req->u.rw.seg[j].gref,
 				info->xbdev->otherend_id,
-				pfn_to_mfn(info->shadow[req->id].frame[j]),
-				rq_data_dir(info->shadow[req->id].request));
-		info->shadow[req->id].req = *req;
+				pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
+				rq_data_dir(info->shadow[req->u.rw.id].request));
+		info->shadow[req->u.rw.id].req = *req;
 
 		info->ring.req_prod_pvt++;
 	}
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index 9324488..f88e28b 100644
--- a/include/xen/interface/io/blkif.h
+++ b/include/xen/interface/io/blkif.h
@@ -95,6 +95,12 @@ typedef uint64_t blkif_sector_t;
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
 struct blkif_request_rw {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   handle;       /* only for read/write requests         */
+#ifdef CONFIG_X86_64
+	uint32_t       _pad1;	     /* offsetof(blkif_request,u.rw.id) == 8 */
+#endif
+	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
 	struct blkif_request_segment {
 		grant_ref_t gref;        /* reference to I/O buffer frame        */
@@ -102,23 +108,27 @@ struct blkif_request_rw {
 		/* @last_sect: last sector in frame to transfer (inclusive).     */
 		uint8_t     first_sect, last_sect;
 	} seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-};
+} __attribute__((__packed__));
 
 struct blkif_request_discard {
+	uint8_t        nr_segments;  /* number of segments                   */
+	blkif_vdev_t   _pad1;        /* only for read/write requests         */
+#ifdef CONFIG_X86_64
+	uint32_t       _pad2;        /* offsetof(blkif_req..,u.discard.id)==8*/
+#endif
+	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;
-	uint64_t nr_sectors;
-};
+	uint64_t       nr_sectors;
+	uint8_t        _pad3;
+} __attribute__((__packed__));
 
 struct blkif_request {
 	uint8_t        operation;    /* BLKIF_OP_???                         */
-	uint8_t        nr_segments;  /* number of segments                   */
-	blkif_vdev_t   handle;       /* only for read/write requests         */
-	uint64_t       id;           /* private guest value, echoed in resp  */
 	union {
 		struct blkif_request_rw rw;
 		struct blkif_request_discard discard;
 	} u;
-};
+} __attribute__((__packed__));
 
 struct blkif_response {
 	uint64_t        id;              /* copied from request */
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:17:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:17:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoib-0001J2-DB; Wed, 30 Nov 2011 18:17:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVoiY-0001Hw-UT
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:17:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322676994!5345844!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDIwMzk5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14901 invoked from network); 30 Nov 2011 18:16:35 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 18:16:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUIGSVt000454
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 18:16:29 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUIGRBQ007845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 18:16:27 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUIGLMn010081; Wed, 30 Nov 2011 12:16:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 10:16:21 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 193DE41C30;
	Wed, 30 Nov 2011 13:16:00 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUIG0DZ015817;
	Wed, 30 Nov 2011 13:16:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, lidongyang@novell.com, JBeulich@novell.com
Date: Wed, 30 Nov 2011 13:15:54 -0500
Message-Id: <1322676956-15691-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
References: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4ED672FD.0085,ss=1,re=-2.300,fgs=0
Cc: axboe@kernel.dk, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/4] xen/blk[front|back]: Enhance discard
	support with secure erasing support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Part of the blkdev_issue_discard(xx) operation is that it can also
issue a secure discard operation that will permanantly remove the
sectors in question. We advertise that we can support that via the
'discard-secure' attribute and on the request, if the 'secure' bit
is set, we will attempt to pass in REQ_DISCARD | REQ_SECURE.

CC: Li Dongyang <lidongyang@novell.com>
[v1: Used 'flag' instead of 'secure:1' bit]
[v2: Use 'reserved' uint8_t instead of adding a new value]
[v3: Check for nseg when mapping instead of operation]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c |   18 ++++++++++-----
 drivers/block/xen-blkback/common.h  |    7 ++++-
 drivers/block/xen-blkback/xenbus.c  |   12 ++++++++++
 drivers/block/xen-blkfront.c        |   41 ++++++++++++++++++++++++++--------
 include/xen/interface/io/blkif.h    |   18 ++++++++++++++-
 5 files changed, 77 insertions(+), 19 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index d7104ab..9d2261b 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -422,13 +422,16 @@ static void xen_blk_discard(struct xen_blkif *blkif, struct blkif_request *req)
 	int status = BLKIF_RSP_OKAY;
 	struct block_device *bdev = blkif->vbd.bdev;
 
-	if (blkif->blk_backend_type == BLKIF_BACKEND_PHY)
+	if (blkif->blk_backend_type == BLKIF_BACKEND_PHY) {
+		unsigned long secure = (blkif->vbd.discard_secure &&
+			(req->u.discard.flag & BLKIF_DISCARD_SECURE)) ?
+			BLKDEV_DISCARD_SECURE : 0;
 		/* just forward the discard request */
 		err = blkdev_issue_discard(bdev,
 				req->u.discard.sector_number,
 				req->u.discard.nr_sectors,
-				GFP_KERNEL, 0);
-	else if (blkif->blk_backend_type == BLKIF_BACKEND_FILE) {
+				GFP_KERNEL, secure);
+	} else if (blkif->blk_backend_type == BLKIF_BACKEND_FILE) {
 		/* punch a hole in the backing file */
 		struct loop_device *lo = bdev->bd_disk->private_data;
 		struct file *file = lo->lo_backing_file;
@@ -643,8 +646,11 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 		break;
 	}
 
-	/* Check that the number of segments is sane. */
-	nseg = req->u.rw.nr_segments;
+	if (unlikely(operation == REQ_DISCARD))
+		nseg = 0;
+	else
+		/* Check that the number of segments is sane. */
+		nseg = req->u.rw.nr_segments;
 
 	if (unlikely(nseg == 0 && operation != WRITE_FLUSH &&
 				operation != REQ_DISCARD) ||
@@ -708,7 +714,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (operation != REQ_DISCARD && xen_blkbk_map(req, pending_req, seg))
+	if (nseg && xen_blkbk_map(req, pending_req, seg))
 		goto fail_flush;
 
 	/*
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index dbfe7b3..d0ee7ed 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -69,7 +69,7 @@ struct blkif_x86_32_request_rw {
 } __attribute__((__packed__));
 
 struct blkif_x86_32_request_discard {
-	uint8_t        nr_segments;  /* number of segments                   */
+	uint8_t        flag;         /* BLKIF_DISCARD_SECURE or zero         */
 	blkif_vdev_t   _pad1;        /* was "handle" for read/write requests */
 	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
@@ -104,7 +104,7 @@ struct blkif_x86_64_request_rw {
 } __attribute__((__packed__));
 
 struct blkif_x86_64_request_discard {
-	uint8_t        nr_segments;  /* number of segments                   */
+	uint8_t        flag;         /* BLKIF_DISCARD_SECURE or zero         */
 	blkif_vdev_t   _pad1;        /* was "handle" for read/write requests */
         uint32_t       _pad2;        /* offsetof(blkif_..,u.discard.id)==8   */
 	uint64_t       id;
@@ -164,6 +164,7 @@ struct xen_vbd {
 	/* Cached size parameter. */
 	sector_t		size;
 	bool			flush_support;
+	bool			discard_secure;
 };
 
 struct backend_info;
@@ -261,6 +262,7 @@ static inline void blkif_get_x86_32_req(struct blkif_request *dst,
 			dst->u.rw.seg[i] = src->u.rw.seg[i];
 		break;
 	case BLKIF_OP_DISCARD:
+		dst->u.discard.flag = src->u.discard.flag;
 		dst->u.discard.sector_number = src->u.discard.sector_number;
 		dst->u.discard.nr_sectors = src->u.discard.nr_sectors;
 		break;
@@ -290,6 +292,7 @@ static inline void blkif_get_x86_64_req(struct blkif_request *dst,
 			dst->u.rw.seg[i] = src->u.rw.seg[i];
 		break;
 	case BLKIF_OP_DISCARD:
+		dst->u.discard.flag = src->u.discard.flag;
 		dst->u.discard.sector_number = src->u.discard.sector_number;
 		dst->u.discard.nr_sectors = src->u.discard.nr_sectors;
 		break;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index f759ad4..187fd2c 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -338,6 +338,9 @@ static int xen_vbd_create(struct xen_blkif *blkif, blkif_vdev_t handle,
 	if (q && q->flush_flags)
 		vbd->flush_support = true;
 
+	if (q && blk_queue_secdiscard(q))
+		vbd->discard_secure = true;
+
 	DPRINTK("Successful creation of handle=%04x (dom=%u)\n",
 		handle, blkif->domid);
 	return 0;
@@ -420,6 +423,15 @@ int xen_blkbk_discard(struct xenbus_transaction xbt, struct backend_info *be)
 				state = 1;
 				blkif->blk_backend_type = BLKIF_BACKEND_PHY;
 			}
+			/* Optional. */
+			err = xenbus_printf(xbt, dev->nodename,
+				"discard-secure", "%d",
+				blkif->vbd.discard_secure);
+			if (err) {
+				xenbus_dev_fatal(dev, err,
+					"writting discard-secure");
+				goto kfree;
+			}
 		}
 	} else {
 		err = PTR_ERR(type);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c2c4be..351ddef 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -98,7 +98,8 @@ struct blkfront_info
 	unsigned long shadow_free;
 	unsigned int feature_flush;
 	unsigned int flush_op;
-	unsigned int feature_discard;
+	unsigned int feature_discard:1;
+	unsigned int feature_secdiscard:1;
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
 	int is_ready;
@@ -305,11 +306,14 @@ static int blkif_queue_request(struct request *req)
 		ring_req->operation = info->flush_op;
 	}
 
-	if (unlikely(req->cmd_flags & REQ_DISCARD)) {
+	if (unlikely(req->cmd_flags & (REQ_DISCARD | REQ_SECURE))) {
 		/* id, sector_number and handle are set above. */
 		ring_req->operation = BLKIF_OP_DISCARD;
-		ring_req->u.discard.nr_segments = 0;
 		ring_req->u.discard.nr_sectors = blk_rq_sectors(req);
+		if ((req->cmd_flags & REQ_SECURE) && info->feature_secdiscard)
+			ring_req->u.discard.flag = BLKIF_DISCARD_SECURE;
+		else
+			ring_req->u.discard.flag = 0;
 	} else {
 		ring_req->u.rw.nr_segments = blk_rq_map_sg(req->q, req,
 							   info->sg);
@@ -426,6 +430,8 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
 		blk_queue_max_discard_sectors(rq, get_capacity(gd));
 		rq->limits.discard_granularity = info->discard_granularity;
 		rq->limits.discard_alignment = info->discard_alignment;
+		if (info->feature_secdiscard)
+			queue_flag_set_unlocked(QUEUE_FLAG_SECDISCARD, rq);
 	}
 
 	/* Hard sector size and max sectors impersonate the equiv. hardware. */
@@ -707,6 +713,8 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 static void blkif_completion(struct blk_shadow *s)
 {
 	int i;
+	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
+	 * flag. */
 	for (i = 0; i < s->req.u.rw.nr_segments; i++)
 		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
 }
@@ -738,7 +746,8 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		id   = bret->id;
 		req  = info->shadow[id].request;
 
-		blkif_completion(&info->shadow[id]);
+		if (bret->operation != BLKIF_OP_DISCARD)
+			blkif_completion(&info->shadow[id]);
 
 		add_id_to_freelist(info, id);
 
@@ -751,7 +760,9 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 					   info->gd->disk_name);
 				error = -EOPNOTSUPP;
 				info->feature_discard = 0;
+				info->feature_secdiscard = 0;
 				queue_flag_clear(QUEUE_FLAG_DISCARD, rq);
+				queue_flag_clear(QUEUE_FLAG_SECDISCARD, rq);
 			}
 			__blk_end_request_all(req, error);
 			break;
@@ -1039,13 +1050,15 @@ static int blkif_recover(struct blkfront_info *info)
 		req->u.rw.id = get_id_from_freelist(info);
 		memcpy(&info->shadow[req->u.rw.id], &copy[i], sizeof(copy[i]));
 
+		if (req->operation != BLKIF_OP_DISCARD) {
 		/* Rewrite any grant references invalidated by susp/resume. */
-		for (j = 0; j < req->u.rw.nr_segments; j++)
-			gnttab_grant_foreign_access_ref(
-				req->u.rw.seg[j].gref,
-				info->xbdev->otherend_id,
-				pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
-				rq_data_dir(info->shadow[req->u.rw.id].request));
+			for (j = 0; j < req->u.rw.nr_segments; j++)
+				gnttab_grant_foreign_access_ref(
+					req->u.rw.seg[j].gref,
+					info->xbdev->otherend_id,
+					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
+					rq_data_dir(info->shadow[req->u.rw.id].request));
+		}
 		info->shadow[req->u.rw.id].req = *req;
 
 		info->ring.req_prod_pvt++;
@@ -1137,11 +1150,13 @@ static void blkfront_setup_discard(struct blkfront_info *info)
 	char *type;
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
+	unsigned int discard_secure;
 
 	type = xenbus_read(XBT_NIL, info->xbdev->otherend, "type", NULL);
 	if (IS_ERR(type))
 		return;
 
+	info->feature_secdiscard = 0;
 	if (strncmp(type, "phy", 3) == 0) {
 		err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			"discard-granularity", "%u", &discard_granularity,
@@ -1152,6 +1167,12 @@ static void blkfront_setup_discard(struct blkfront_info *info)
 			info->discard_granularity = discard_granularity;
 			info->discard_alignment = discard_alignment;
 		}
+		err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
+			    "discard-secure", "%d", &discard_secure,
+			    NULL);
+		if (!err)
+			info->feature_secdiscard = discard_secure;
+
 	} else if (strncmp(type, "file", 4) == 0)
 		info->feature_discard = 1;
 
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index f88e28b..ee338bf 100644
--- a/include/xen/interface/io/blkif.h
+++ b/include/xen/interface/io/blkif.h
@@ -84,6 +84,21 @@ typedef uint64_t blkif_sector_t;
  *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
  * http://www.seagate.com/staticfiles/support/disc/manuals/
  *     Interface%20manuals/100293068c.pdf
+ * The backend can optionally provide three extra XenBus attributes to
+ * further optimize the discard functionality:
+ * 'discard-aligment' - Devices that support discard functionality may
+ * internally allocate space in units that are bigger than the exported
+ * logical block size. The discard-alignment parameter indicates how many bytes
+ * the beginning of the partition is offset from the internal allocation unit's
+ * natural alignment.
+ * 'discard-granularity'  - Devices that support discard functionality may
+ * internally allocate space using units that are bigger than the logical block
+ * size. The discard-granularity parameter indicates the size of the internal
+ * allocation unit in bytes if reported by the device. Otherwise the
+ * discard-granularity will be set to match the device's physical block size.
+ * 'discard-secure' - All copies of the discarded sectors (potentially created
+ * by garbage collection) must also be erased.  To use this feature, the flag
+ * BLKIF_DISCARD_SECURE must be set in the blkif_request_trim.
  */
 #define BLKIF_OP_DISCARD           5
 
@@ -111,7 +126,8 @@ struct blkif_request_rw {
 } __attribute__((__packed__));
 
 struct blkif_request_discard {
-	uint8_t        nr_segments;  /* number of segments                   */
+	uint8_t        flag;         /* BLKIF_DISCARD_SECURE or zero.        */
+#define BLKIF_DISCARD_SECURE (1<<0)  /* ignored if discard-secure=0          */
 	blkif_vdev_t   _pad1;        /* only for read/write requests         */
 #ifdef CONFIG_X86_64
 	uint32_t       _pad2;        /* offsetof(blkif_req..,u.discard.id)==8*/
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:17:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:17:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoib-0001J2-DB; Wed, 30 Nov 2011 18:17:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVoiY-0001Hw-UT
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:17:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322676994!5345844!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDIwMzk5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14901 invoked from network); 30 Nov 2011 18:16:35 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 18:16:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUIGSVt000454
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 18:16:29 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUIGRBQ007845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 18:16:27 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUIGLMn010081; Wed, 30 Nov 2011 12:16:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 10:16:21 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 193DE41C30;
	Wed, 30 Nov 2011 13:16:00 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUIG0DZ015817;
	Wed, 30 Nov 2011 13:16:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, lidongyang@novell.com, JBeulich@novell.com
Date: Wed, 30 Nov 2011 13:15:54 -0500
Message-Id: <1322676956-15691-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
References: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4ED672FD.0085,ss=1,re=-2.300,fgs=0
Cc: axboe@kernel.dk, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/4] xen/blk[front|back]: Enhance discard
	support with secure erasing support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Part of the blkdev_issue_discard(xx) operation is that it can also
issue a secure discard operation that will permanantly remove the
sectors in question. We advertise that we can support that via the
'discard-secure' attribute and on the request, if the 'secure' bit
is set, we will attempt to pass in REQ_DISCARD | REQ_SECURE.

CC: Li Dongyang <lidongyang@novell.com>
[v1: Used 'flag' instead of 'secure:1' bit]
[v2: Use 'reserved' uint8_t instead of adding a new value]
[v3: Check for nseg when mapping instead of operation]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c |   18 ++++++++++-----
 drivers/block/xen-blkback/common.h  |    7 ++++-
 drivers/block/xen-blkback/xenbus.c  |   12 ++++++++++
 drivers/block/xen-blkfront.c        |   41 ++++++++++++++++++++++++++--------
 include/xen/interface/io/blkif.h    |   18 ++++++++++++++-
 5 files changed, 77 insertions(+), 19 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index d7104ab..9d2261b 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -422,13 +422,16 @@ static void xen_blk_discard(struct xen_blkif *blkif, struct blkif_request *req)
 	int status = BLKIF_RSP_OKAY;
 	struct block_device *bdev = blkif->vbd.bdev;
 
-	if (blkif->blk_backend_type == BLKIF_BACKEND_PHY)
+	if (blkif->blk_backend_type == BLKIF_BACKEND_PHY) {
+		unsigned long secure = (blkif->vbd.discard_secure &&
+			(req->u.discard.flag & BLKIF_DISCARD_SECURE)) ?
+			BLKDEV_DISCARD_SECURE : 0;
 		/* just forward the discard request */
 		err = blkdev_issue_discard(bdev,
 				req->u.discard.sector_number,
 				req->u.discard.nr_sectors,
-				GFP_KERNEL, 0);
-	else if (blkif->blk_backend_type == BLKIF_BACKEND_FILE) {
+				GFP_KERNEL, secure);
+	} else if (blkif->blk_backend_type == BLKIF_BACKEND_FILE) {
 		/* punch a hole in the backing file */
 		struct loop_device *lo = bdev->bd_disk->private_data;
 		struct file *file = lo->lo_backing_file;
@@ -643,8 +646,11 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 		break;
 	}
 
-	/* Check that the number of segments is sane. */
-	nseg = req->u.rw.nr_segments;
+	if (unlikely(operation == REQ_DISCARD))
+		nseg = 0;
+	else
+		/* Check that the number of segments is sane. */
+		nseg = req->u.rw.nr_segments;
 
 	if (unlikely(nseg == 0 && operation != WRITE_FLUSH &&
 				operation != REQ_DISCARD) ||
@@ -708,7 +714,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (operation != REQ_DISCARD && xen_blkbk_map(req, pending_req, seg))
+	if (nseg && xen_blkbk_map(req, pending_req, seg))
 		goto fail_flush;
 
 	/*
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index dbfe7b3..d0ee7ed 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -69,7 +69,7 @@ struct blkif_x86_32_request_rw {
 } __attribute__((__packed__));
 
 struct blkif_x86_32_request_discard {
-	uint8_t        nr_segments;  /* number of segments                   */
+	uint8_t        flag;         /* BLKIF_DISCARD_SECURE or zero         */
 	blkif_vdev_t   _pad1;        /* was "handle" for read/write requests */
 	uint64_t       id;           /* private guest value, echoed in resp  */
 	blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
@@ -104,7 +104,7 @@ struct blkif_x86_64_request_rw {
 } __attribute__((__packed__));
 
 struct blkif_x86_64_request_discard {
-	uint8_t        nr_segments;  /* number of segments                   */
+	uint8_t        flag;         /* BLKIF_DISCARD_SECURE or zero         */
 	blkif_vdev_t   _pad1;        /* was "handle" for read/write requests */
         uint32_t       _pad2;        /* offsetof(blkif_..,u.discard.id)==8   */
 	uint64_t       id;
@@ -164,6 +164,7 @@ struct xen_vbd {
 	/* Cached size parameter. */
 	sector_t		size;
 	bool			flush_support;
+	bool			discard_secure;
 };
 
 struct backend_info;
@@ -261,6 +262,7 @@ static inline void blkif_get_x86_32_req(struct blkif_request *dst,
 			dst->u.rw.seg[i] = src->u.rw.seg[i];
 		break;
 	case BLKIF_OP_DISCARD:
+		dst->u.discard.flag = src->u.discard.flag;
 		dst->u.discard.sector_number = src->u.discard.sector_number;
 		dst->u.discard.nr_sectors = src->u.discard.nr_sectors;
 		break;
@@ -290,6 +292,7 @@ static inline void blkif_get_x86_64_req(struct blkif_request *dst,
 			dst->u.rw.seg[i] = src->u.rw.seg[i];
 		break;
 	case BLKIF_OP_DISCARD:
+		dst->u.discard.flag = src->u.discard.flag;
 		dst->u.discard.sector_number = src->u.discard.sector_number;
 		dst->u.discard.nr_sectors = src->u.discard.nr_sectors;
 		break;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index f759ad4..187fd2c 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -338,6 +338,9 @@ static int xen_vbd_create(struct xen_blkif *blkif, blkif_vdev_t handle,
 	if (q && q->flush_flags)
 		vbd->flush_support = true;
 
+	if (q && blk_queue_secdiscard(q))
+		vbd->discard_secure = true;
+
 	DPRINTK("Successful creation of handle=%04x (dom=%u)\n",
 		handle, blkif->domid);
 	return 0;
@@ -420,6 +423,15 @@ int xen_blkbk_discard(struct xenbus_transaction xbt, struct backend_info *be)
 				state = 1;
 				blkif->blk_backend_type = BLKIF_BACKEND_PHY;
 			}
+			/* Optional. */
+			err = xenbus_printf(xbt, dev->nodename,
+				"discard-secure", "%d",
+				blkif->vbd.discard_secure);
+			if (err) {
+				xenbus_dev_fatal(dev, err,
+					"writting discard-secure");
+				goto kfree;
+			}
 		}
 	} else {
 		err = PTR_ERR(type);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c2c4be..351ddef 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -98,7 +98,8 @@ struct blkfront_info
 	unsigned long shadow_free;
 	unsigned int feature_flush;
 	unsigned int flush_op;
-	unsigned int feature_discard;
+	unsigned int feature_discard:1;
+	unsigned int feature_secdiscard:1;
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
 	int is_ready;
@@ -305,11 +306,14 @@ static int blkif_queue_request(struct request *req)
 		ring_req->operation = info->flush_op;
 	}
 
-	if (unlikely(req->cmd_flags & REQ_DISCARD)) {
+	if (unlikely(req->cmd_flags & (REQ_DISCARD | REQ_SECURE))) {
 		/* id, sector_number and handle are set above. */
 		ring_req->operation = BLKIF_OP_DISCARD;
-		ring_req->u.discard.nr_segments = 0;
 		ring_req->u.discard.nr_sectors = blk_rq_sectors(req);
+		if ((req->cmd_flags & REQ_SECURE) && info->feature_secdiscard)
+			ring_req->u.discard.flag = BLKIF_DISCARD_SECURE;
+		else
+			ring_req->u.discard.flag = 0;
 	} else {
 		ring_req->u.rw.nr_segments = blk_rq_map_sg(req->q, req,
 							   info->sg);
@@ -426,6 +430,8 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
 		blk_queue_max_discard_sectors(rq, get_capacity(gd));
 		rq->limits.discard_granularity = info->discard_granularity;
 		rq->limits.discard_alignment = info->discard_alignment;
+		if (info->feature_secdiscard)
+			queue_flag_set_unlocked(QUEUE_FLAG_SECDISCARD, rq);
 	}
 
 	/* Hard sector size and max sectors impersonate the equiv. hardware. */
@@ -707,6 +713,8 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 static void blkif_completion(struct blk_shadow *s)
 {
 	int i;
+	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
+	 * flag. */
 	for (i = 0; i < s->req.u.rw.nr_segments; i++)
 		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
 }
@@ -738,7 +746,8 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		id   = bret->id;
 		req  = info->shadow[id].request;
 
-		blkif_completion(&info->shadow[id]);
+		if (bret->operation != BLKIF_OP_DISCARD)
+			blkif_completion(&info->shadow[id]);
 
 		add_id_to_freelist(info, id);
 
@@ -751,7 +760,9 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 					   info->gd->disk_name);
 				error = -EOPNOTSUPP;
 				info->feature_discard = 0;
+				info->feature_secdiscard = 0;
 				queue_flag_clear(QUEUE_FLAG_DISCARD, rq);
+				queue_flag_clear(QUEUE_FLAG_SECDISCARD, rq);
 			}
 			__blk_end_request_all(req, error);
 			break;
@@ -1039,13 +1050,15 @@ static int blkif_recover(struct blkfront_info *info)
 		req->u.rw.id = get_id_from_freelist(info);
 		memcpy(&info->shadow[req->u.rw.id], &copy[i], sizeof(copy[i]));
 
+		if (req->operation != BLKIF_OP_DISCARD) {
 		/* Rewrite any grant references invalidated by susp/resume. */
-		for (j = 0; j < req->u.rw.nr_segments; j++)
-			gnttab_grant_foreign_access_ref(
-				req->u.rw.seg[j].gref,
-				info->xbdev->otherend_id,
-				pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
-				rq_data_dir(info->shadow[req->u.rw.id].request));
+			for (j = 0; j < req->u.rw.nr_segments; j++)
+				gnttab_grant_foreign_access_ref(
+					req->u.rw.seg[j].gref,
+					info->xbdev->otherend_id,
+					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
+					rq_data_dir(info->shadow[req->u.rw.id].request));
+		}
 		info->shadow[req->u.rw.id].req = *req;
 
 		info->ring.req_prod_pvt++;
@@ -1137,11 +1150,13 @@ static void blkfront_setup_discard(struct blkfront_info *info)
 	char *type;
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
+	unsigned int discard_secure;
 
 	type = xenbus_read(XBT_NIL, info->xbdev->otherend, "type", NULL);
 	if (IS_ERR(type))
 		return;
 
+	info->feature_secdiscard = 0;
 	if (strncmp(type, "phy", 3) == 0) {
 		err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			"discard-granularity", "%u", &discard_granularity,
@@ -1152,6 +1167,12 @@ static void blkfront_setup_discard(struct blkfront_info *info)
 			info->discard_granularity = discard_granularity;
 			info->discard_alignment = discard_alignment;
 		}
+		err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
+			    "discard-secure", "%d", &discard_secure,
+			    NULL);
+		if (!err)
+			info->feature_secdiscard = discard_secure;
+
 	} else if (strncmp(type, "file", 4) == 0)
 		info->feature_discard = 1;
 
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index f88e28b..ee338bf 100644
--- a/include/xen/interface/io/blkif.h
+++ b/include/xen/interface/io/blkif.h
@@ -84,6 +84,21 @@ typedef uint64_t blkif_sector_t;
  *     e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
  * http://www.seagate.com/staticfiles/support/disc/manuals/
  *     Interface%20manuals/100293068c.pdf
+ * The backend can optionally provide three extra XenBus attributes to
+ * further optimize the discard functionality:
+ * 'discard-aligment' - Devices that support discard functionality may
+ * internally allocate space in units that are bigger than the exported
+ * logical block size. The discard-alignment parameter indicates how many bytes
+ * the beginning of the partition is offset from the internal allocation unit's
+ * natural alignment.
+ * 'discard-granularity'  - Devices that support discard functionality may
+ * internally allocate space using units that are bigger than the logical block
+ * size. The discard-granularity parameter indicates the size of the internal
+ * allocation unit in bytes if reported by the device. Otherwise the
+ * discard-granularity will be set to match the device's physical block size.
+ * 'discard-secure' - All copies of the discarded sectors (potentially created
+ * by garbage collection) must also be erased.  To use this feature, the flag
+ * BLKIF_DISCARD_SECURE must be set in the blkif_request_trim.
  */
 #define BLKIF_OP_DISCARD           5
 
@@ -111,7 +126,8 @@ struct blkif_request_rw {
 } __attribute__((__packed__));
 
 struct blkif_request_discard {
-	uint8_t        nr_segments;  /* number of segments                   */
+	uint8_t        flag;         /* BLKIF_DISCARD_SECURE or zero.        */
+#define BLKIF_DISCARD_SECURE (1<<0)  /* ignored if discard-secure=0          */
 	blkif_vdev_t   _pad1;        /* only for read/write requests         */
 #ifdef CONFIG_X86_64
 	uint32_t       _pad2;        /* offsetof(blkif_req..,u.discard.id)==8*/
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:17:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:17:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoiY-0001IO-3H; Wed, 30 Nov 2011 18:17:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVoiW-0001Hg-Jz
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:17:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322676992!6435915!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19512 invoked from network); 30 Nov 2011 18:16:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 18:16:33 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUIGSBL019313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 18:16:28 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUIGRGS007844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 18:16:27 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUIGLYj010082; Wed, 30 Nov 2011 12:16:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 10:16:21 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 54F0141C32;
	Wed, 30 Nov 2011 13:16:00 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUIG0kJ015824;
	Wed, 30 Nov 2011 13:16:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, lidongyang@novell.com, JBeulich@novell.com
Date: Wed, 30 Nov 2011 13:15:56 -0500
Message-Id: <1322676956-15691-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
References: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020209.4ED672FD.00C5,ss=1,re=0.000,fgs=0
Cc: axboe@kernel.dk, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 4/4] xen-blkback: convert hole punching to
	discard request on loop devices
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Li Dongyang <lidongyang@novell.com>

As of dfaa2ef68e80c378e610e3c8c536f1c239e8d3ef, loop devices support
discard request now. We could just issue a discard request, and
the loop driver will punch the hole for us, so we don't need to touch
the internals of loop device and punch the hole ourselves, Thanks.

V0->V1: rebased on devel/for-jens-3.3

Signed-off-by: Li Dongyang <lidongyang@novell.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c |   19 ++-----------------
 1 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index b058de7..0088bf6 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -39,9 +39,6 @@
 #include <linux/list.h>
 #include <linux/delay.h>
 #include <linux/freezer.h>
-#include <linux/loop.h>
-#include <linux/falloc.h>
-#include <linux/fs.h>
 
 #include <xen/events.h>
 #include <xen/page.h>
@@ -426,27 +423,15 @@ static int dispatch_discard_io(struct xen_blkif *blkif,
 	blkif->st_ds_req++;
 
 	xen_blkif_get(blkif);
-	if (blkif->blk_backend_type == BLKIF_BACKEND_PHY) {
+	if (blkif->blk_backend_type == BLKIF_BACKEND_PHY ||
+	    blkif->blk_backend_type == BLKIF_BACKEND_FILE) {
 		unsigned long secure = (blkif->vbd.discard_secure &&
 			(req->u.discard.flag & BLKIF_DISCARD_SECURE)) ?
 			BLKDEV_DISCARD_SECURE : 0;
-		/* just forward the discard request */
 		err = blkdev_issue_discard(bdev,
 				req->u.discard.sector_number,
 				req->u.discard.nr_sectors,
 				GFP_KERNEL, secure);
-	} else if (blkif->blk_backend_type == BLKIF_BACKEND_FILE) {
-		/* punch a hole in the backing file */
-		struct loop_device *lo = bdev->bd_disk->private_data;
-		struct file *file = lo->lo_backing_file;
-
-		if (file->f_op->fallocate)
-			err = file->f_op->fallocate(file,
-				FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,
-				req->u.discard.sector_number << 9,
-				req->u.discard.nr_sectors << 9);
-		else
-			err = -EOPNOTSUPP;
 	} else
 		err = -EOPNOTSUPP;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:17:33 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:17:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoiY-0001IO-3H; Wed, 30 Nov 2011 18:17:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVoiW-0001Hg-Jz
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:17:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322676992!6435915!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19512 invoked from network); 30 Nov 2011 18:16:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Nov 2011 18:16:33 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUIGSBL019313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 18:16:28 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUIGRGS007844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 18:16:27 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUIGLYj010082; Wed, 30 Nov 2011 12:16:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 10:16:21 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 54F0141C32;
	Wed, 30 Nov 2011 13:16:00 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUIG0kJ015824;
	Wed, 30 Nov 2011 13:16:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, lidongyang@novell.com, JBeulich@novell.com
Date: Wed, 30 Nov 2011 13:15:56 -0500
Message-Id: <1322676956-15691-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
References: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020209.4ED672FD.00C5,ss=1,re=0.000,fgs=0
Cc: axboe@kernel.dk, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 4/4] xen-blkback: convert hole punching to
	discard request on loop devices
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Li Dongyang <lidongyang@novell.com>

As of dfaa2ef68e80c378e610e3c8c536f1c239e8d3ef, loop devices support
discard request now. We could just issue a discard request, and
the loop driver will punch the hole for us, so we don't need to touch
the internals of loop device and punch the hole ourselves, Thanks.

V0->V1: rebased on devel/for-jens-3.3

Signed-off-by: Li Dongyang <lidongyang@novell.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c |   19 ++-----------------
 1 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index b058de7..0088bf6 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -39,9 +39,6 @@
 #include <linux/list.h>
 #include <linux/delay.h>
 #include <linux/freezer.h>
-#include <linux/loop.h>
-#include <linux/falloc.h>
-#include <linux/fs.h>
 
 #include <xen/events.h>
 #include <xen/page.h>
@@ -426,27 +423,15 @@ static int dispatch_discard_io(struct xen_blkif *blkif,
 	blkif->st_ds_req++;
 
 	xen_blkif_get(blkif);
-	if (blkif->blk_backend_type == BLKIF_BACKEND_PHY) {
+	if (blkif->blk_backend_type == BLKIF_BACKEND_PHY ||
+	    blkif->blk_backend_type == BLKIF_BACKEND_FILE) {
 		unsigned long secure = (blkif->vbd.discard_secure &&
 			(req->u.discard.flag & BLKIF_DISCARD_SECURE)) ?
 			BLKDEV_DISCARD_SECURE : 0;
-		/* just forward the discard request */
 		err = blkdev_issue_discard(bdev,
 				req->u.discard.sector_number,
 				req->u.discard.nr_sectors,
 				GFP_KERNEL, secure);
-	} else if (blkif->blk_backend_type == BLKIF_BACKEND_FILE) {
-		/* punch a hole in the backing file */
-		struct loop_device *lo = bdev->bd_disk->private_data;
-		struct file *file = lo->lo_backing_file;
-
-		if (file->f_op->fallocate)
-			err = file->f_op->fallocate(file,
-				FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,
-				req->u.discard.sector_number << 9,
-				req->u.discard.nr_sectors << 9);
-		else
-			err = -EOPNOTSUPP;
 	} else
 		err = -EOPNOTSUPP;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:17:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoiY-0001Ie-VA; Wed, 30 Nov 2011 18:17:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVoiX-0001Hp-BX
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:17:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322676992!5344221!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21948 invoked from network); 30 Nov 2011 18:16:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 18:16:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUIGRIK019304
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 18:16:28 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUIGQ4F016109
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 18:16:26 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUIGL7c007634; Wed, 30 Nov 2011 12:16:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 10:16:21 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 36B5A41C31;
	Wed, 30 Nov 2011 13:16:00 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUIG0a9015820;
	Wed, 30 Nov 2011 13:16:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, lidongyang@novell.com, JBeulich@novell.com
Date: Wed, 30 Nov 2011 13:15:55 -0500
Message-Id: <1322676956-15691-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
References: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020206.4ED672FC.0121,ss=1,re=0.000,fgs=0
Cc: axboe@kernel.dk, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/4] xen/blkback: Move processing of
	BLKIF_OP_DISCARD from dispatch_rw_block_io
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

. and move it to its own function that will deal with the
discard operation.

Suggested-by: Jan Beulich <JBeulich@novell.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c |   54 +++++++++++++++-------------------
 1 files changed, 24 insertions(+), 30 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 9d2261b..b058de7 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -416,12 +416,16 @@ static int xen_blkbk_map(struct blkif_request *req,
 	return ret;
 }
 
-static void xen_blk_discard(struct xen_blkif *blkif, struct blkif_request *req)
+static int dispatch_discard_io(struct xen_blkif *blkif,
+				struct blkif_request *req)
 {
 	int err = 0;
 	int status = BLKIF_RSP_OKAY;
 	struct block_device *bdev = blkif->vbd.bdev;
 
+	blkif->st_ds_req++;
+
+	xen_blkif_get(blkif);
 	if (blkif->blk_backend_type == BLKIF_BACKEND_PHY) {
 		unsigned long secure = (blkif->vbd.discard_secure &&
 			(req->u.discard.flag & BLKIF_DISCARD_SECURE)) ?
@@ -453,6 +457,8 @@ static void xen_blk_discard(struct xen_blkif *blkif, struct blkif_request *req)
 		status = BLKIF_RSP_ERROR;
 
 	make_response(blkif, req->u.discard.id, req->operation, status);
+	xen_blkif_put(blkif);
+	return err;
 }
 
 static void xen_blk_drain_io(struct xen_blkif *blkif)
@@ -576,8 +582,11 @@ __do_block_io_op(struct xen_blkif *blkif)
 
 		/* Apply all sanity checks to /private copy/ of request. */
 		barrier();
-
-		if (dispatch_rw_block_io(blkif, &req, pending_req))
+		if (unlikely(req.operation == BLKIF_OP_DISCARD)) {
+			free_req(pending_req);
+			if (dispatch_discard_io(blkif, &req))
+				break;
+		} else if (dispatch_rw_block_io(blkif, &req, pending_req))
 			break;
 
 		/* Yield point for this unbounded loop. */
@@ -636,24 +645,16 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 		blkif->st_f_req++;
 		operation = WRITE_FLUSH;
 		break;
-	case BLKIF_OP_DISCARD:
-		blkif->st_ds_req++;
-		operation = REQ_DISCARD;
-		break;
 	default:
 		operation = 0; /* make gcc happy */
 		goto fail_response;
 		break;
 	}
 
-	if (unlikely(operation == REQ_DISCARD))
-		nseg = 0;
-	else
-		/* Check that the number of segments is sane. */
-		nseg = req->u.rw.nr_segments;
+	/* Check that the number of segments is sane. */
+	nseg = req->u.rw.nr_segments;
 
-	if (unlikely(nseg == 0 && operation != WRITE_FLUSH &&
-				operation != REQ_DISCARD) ||
+	if (unlikely(nseg == 0 && operation != WRITE_FLUSH) ||
 	    unlikely(nseg > BLKIF_MAX_SEGMENTS_PER_REQUEST)) {
 		pr_debug(DRV_PFX "Bad number of segments in request (%d)\n",
 			 nseg);
@@ -714,7 +715,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (nseg && xen_blkbk_map(req, pending_req, seg))
+	if (xen_blkbk_map(req, pending_req, seg))
 		goto fail_flush;
 
 	/*
@@ -746,23 +747,16 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 
 	/* This will be hit if the operation was a flush or discard. */
 	if (!bio) {
-		BUG_ON(operation != WRITE_FLUSH && operation != REQ_DISCARD);
+		BUG_ON(operation != WRITE_FLUSH);
 
-		if (operation == WRITE_FLUSH) {
-			bio = bio_alloc(GFP_KERNEL, 0);
-			if (unlikely(bio == NULL))
-				goto fail_put_bio;
+		bio = bio_alloc(GFP_KERNEL, 0);
+		if (unlikely(bio == NULL))
+			goto fail_put_bio;
 
-			biolist[nbio++] = bio;
-			bio->bi_bdev    = preq.bdev;
-			bio->bi_private = pending_req;
-			bio->bi_end_io  = end_block_io_op;
-		} else if (operation == REQ_DISCARD) {
-			xen_blk_discard(blkif, req);
-			xen_blkif_put(blkif);
-			free_req(pending_req);
-			return 0;
-		}
+		biolist[nbio++] = bio;
+		bio->bi_bdev    = preq.bdev;
+		bio->bi_private = pending_req;
+		bio->bi_end_io  = end_block_io_op;
 	}
 
 	/*
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:17:34 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:17:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVoiY-0001Ie-VA; Wed, 30 Nov 2011 18:17:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RVoiX-0001Hp-BX
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:17:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1322676992!5344221!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQxNjMxNw==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21948 invoked from network); 30 Nov 2011 18:16:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 18:16:33 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pAUIGRIK019304
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 30 Nov 2011 18:16:28 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pAUIGQ4F016109
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 30 Nov 2011 18:16:26 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pAUIGL7c007634; Wed, 30 Nov 2011 12:16:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 30 Nov 2011 10:16:21 -0800
Received: from phenom.dumpdata.com (localhost.localdomain [127.0.0.1])
	by phenom.dumpdata.com (Postfix) with ESMTP id 36B5A41C31;
	Wed, 30 Nov 2011 13:16:00 -0500 (EST)
Received: (from konrad@localhost)
	by phenom.dumpdata.com (8.14.5/8.14.5/Submit) id pAUIG0a9015820;
	Wed, 30 Nov 2011 13:16:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com, lidongyang@novell.com, JBeulich@novell.com
Date: Wed, 30 Nov 2011 13:15:55 -0500
Message-Id: <1322676956-15691-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
References: <1322676956-15691-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020206.4ED672FC.0121,ss=1,re=0.000,fgs=0
Cc: axboe@kernel.dk, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/4] xen/blkback: Move processing of
	BLKIF_OP_DISCARD from dispatch_rw_block_io
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

. and move it to its own function that will deal with the
discard operation.

Suggested-by: Jan Beulich <JBeulich@novell.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c |   54 +++++++++++++++-------------------
 1 files changed, 24 insertions(+), 30 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 9d2261b..b058de7 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -416,12 +416,16 @@ static int xen_blkbk_map(struct blkif_request *req,
 	return ret;
 }
 
-static void xen_blk_discard(struct xen_blkif *blkif, struct blkif_request *req)
+static int dispatch_discard_io(struct xen_blkif *blkif,
+				struct blkif_request *req)
 {
 	int err = 0;
 	int status = BLKIF_RSP_OKAY;
 	struct block_device *bdev = blkif->vbd.bdev;
 
+	blkif->st_ds_req++;
+
+	xen_blkif_get(blkif);
 	if (blkif->blk_backend_type == BLKIF_BACKEND_PHY) {
 		unsigned long secure = (blkif->vbd.discard_secure &&
 			(req->u.discard.flag & BLKIF_DISCARD_SECURE)) ?
@@ -453,6 +457,8 @@ static void xen_blk_discard(struct xen_blkif *blkif, struct blkif_request *req)
 		status = BLKIF_RSP_ERROR;
 
 	make_response(blkif, req->u.discard.id, req->operation, status);
+	xen_blkif_put(blkif);
+	return err;
 }
 
 static void xen_blk_drain_io(struct xen_blkif *blkif)
@@ -576,8 +582,11 @@ __do_block_io_op(struct xen_blkif *blkif)
 
 		/* Apply all sanity checks to /private copy/ of request. */
 		barrier();
-
-		if (dispatch_rw_block_io(blkif, &req, pending_req))
+		if (unlikely(req.operation == BLKIF_OP_DISCARD)) {
+			free_req(pending_req);
+			if (dispatch_discard_io(blkif, &req))
+				break;
+		} else if (dispatch_rw_block_io(blkif, &req, pending_req))
 			break;
 
 		/* Yield point for this unbounded loop. */
@@ -636,24 +645,16 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 		blkif->st_f_req++;
 		operation = WRITE_FLUSH;
 		break;
-	case BLKIF_OP_DISCARD:
-		blkif->st_ds_req++;
-		operation = REQ_DISCARD;
-		break;
 	default:
 		operation = 0; /* make gcc happy */
 		goto fail_response;
 		break;
 	}
 
-	if (unlikely(operation == REQ_DISCARD))
-		nseg = 0;
-	else
-		/* Check that the number of segments is sane. */
-		nseg = req->u.rw.nr_segments;
+	/* Check that the number of segments is sane. */
+	nseg = req->u.rw.nr_segments;
 
-	if (unlikely(nseg == 0 && operation != WRITE_FLUSH &&
-				operation != REQ_DISCARD) ||
+	if (unlikely(nseg == 0 && operation != WRITE_FLUSH) ||
 	    unlikely(nseg > BLKIF_MAX_SEGMENTS_PER_REQUEST)) {
 		pr_debug(DRV_PFX "Bad number of segments in request (%d)\n",
 			 nseg);
@@ -714,7 +715,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (nseg && xen_blkbk_map(req, pending_req, seg))
+	if (xen_blkbk_map(req, pending_req, seg))
 		goto fail_flush;
 
 	/*
@@ -746,23 +747,16 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 
 	/* This will be hit if the operation was a flush or discard. */
 	if (!bio) {
-		BUG_ON(operation != WRITE_FLUSH && operation != REQ_DISCARD);
+		BUG_ON(operation != WRITE_FLUSH);
 
-		if (operation == WRITE_FLUSH) {
-			bio = bio_alloc(GFP_KERNEL, 0);
-			if (unlikely(bio == NULL))
-				goto fail_put_bio;
+		bio = bio_alloc(GFP_KERNEL, 0);
+		if (unlikely(bio == NULL))
+			goto fail_put_bio;
 
-			biolist[nbio++] = bio;
-			bio->bi_bdev    = preq.bdev;
-			bio->bi_private = pending_req;
-			bio->bi_end_io  = end_block_io_op;
-		} else if (operation == REQ_DISCARD) {
-			xen_blk_discard(blkif, req);
-			xen_blkif_put(blkif);
-			free_req(pending_req);
-			return 0;
-		}
+		biolist[nbio++] = bio;
+		bio->bi_bdev    = preq.bdev;
+		bio->bi_private = pending_req;
+		bio->bi_end_io  = end_block_io_op;
 	}
 
 	/*
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:23:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVooR-0002DY-0H; Wed, 30 Nov 2011 18:23:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1RVooP-0002D8-8U
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:23:17 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322677358!6436564!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwMzQ5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5590 invoked from network); 30 Nov 2011 18:22:38 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-21.messagelabs.com with SMTP;
	30 Nov 2011 18:22:38 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 30 Nov 2011 10:22:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="81695395"
Received: from agluck-desktop.sc.intel.com ([10.3.52.68])
	by orsmga002.jf.intel.com with SMTP; 30 Nov 2011 10:22:37 -0800
From: "Luck, Tony" <tony.luck@intel.com>
To: Annie Li <annie.li@oracle.com>
Date: Wed, 30 Nov 2011 10:22:37 -0800
Message-Id: <4ed6746d25537aefd2@agluck-desktop.sc.intel.com>
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] ia64: fix build breakage because of conflicting
	u64 guest handles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8230622985307717026=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8230622985307717026==
Content-Type: text/plain

include/xen/interface/xen.h:526: error: conflicting types for ‘__guest_handle_u64’
arch/ia64/include/asm/xen/interface.h:74: error: previous declaration of ‘__guest_handle_u64’ was here

Problem introduced by "xen/granttable: Introducing grant table V2 stucture"

which added a new definition to include/xen/interface/xen.h for "u64".

Fix: delete the ia64 arch specific definition.

Signed-off-by: Tony Luck <tony.luck@intel.com>
---

Can someone either fold this into the above patch, or add it to the
same tree that is feeding into linux-next - I saw the breakage in
today's "next-20111130" tag.  Thanks.

 arch/ia64/include/asm/xen/interface.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 1d2427d..fbb5198 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -71,7 +71,7 @@
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint, unsigned int);
 __DEFINE_GUEST_HANDLE(ulong, unsigned long);
-__DEFINE_GUEST_HANDLE(u64, unsigned long);
+
 DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(long);
-- 
1.7.3.1



--===============8230622985307717026==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8230622985307717026==--

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:23:37 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVooR-0002DY-0H; Wed, 30 Nov 2011 18:23:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tony.luck@intel.com>) id 1RVooP-0002D8-8U
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:23:17 +0000
X-Env-Sender: tony.luck@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1322677358!6436564!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIwMzQ5\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5590 invoked from network); 30 Nov 2011 18:22:38 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-21.messagelabs.com with SMTP;
	30 Nov 2011 18:22:38 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 30 Nov 2011 10:22:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="81695395"
Received: from agluck-desktop.sc.intel.com ([10.3.52.68])
	by orsmga002.jf.intel.com with SMTP; 30 Nov 2011 10:22:37 -0800
From: "Luck, Tony" <tony.luck@intel.com>
To: Annie Li <annie.li@oracle.com>
Date: Wed, 30 Nov 2011 10:22:37 -0800
Message-Id: <4ed6746d25537aefd2@agluck-desktop.sc.intel.com>
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] ia64: fix build breakage because of conflicting
	u64 guest handles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8230622985307717026=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8230622985307717026==
Content-Type: text/plain

include/xen/interface/xen.h:526: error: conflicting types for ‘__guest_handle_u64’
arch/ia64/include/asm/xen/interface.h:74: error: previous declaration of ‘__guest_handle_u64’ was here

Problem introduced by "xen/granttable: Introducing grant table V2 stucture"

which added a new definition to include/xen/interface/xen.h for "u64".

Fix: delete the ia64 arch specific definition.

Signed-off-by: Tony Luck <tony.luck@intel.com>
---

Can someone either fold this into the above patch, or add it to the
same tree that is feeding into linux-next - I saw the breakage in
today's "next-20111130" tag.  Thanks.

 arch/ia64/include/asm/xen/interface.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 1d2427d..fbb5198 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -71,7 +71,7 @@
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint, unsigned int);
 __DEFINE_GUEST_HANDLE(ulong, unsigned long);
-__DEFINE_GUEST_HANDLE(u64, unsigned long);
+
 DEFINE_GUEST_HANDLE(char);
 DEFINE_GUEST_HANDLE(int);
 DEFINE_GUEST_HANDLE(long);
-- 
1.7.3.1



--===============8230622985307717026==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8230622985307717026==--

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:32:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVox3-0002SL-9q; Wed, 30 Nov 2011 18:32:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVox1-0002SG-5g
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:32:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322677851!58959368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18478 invoked from network); 30 Nov 2011 18:30:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 18:30:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,272,1320624000"; 
   d="scan'208";a="9215614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 18:31:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 18:31:37 +0000
Date: Wed, 30 Nov 2011 18:32:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Arnd Bergmann <arnd@arndb.de>
In-Reply-To: <201111301815.01297.arnd@arndb.de>
Message-ID: <alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Embeddedxen-devel] [ANNOUNCE] Xen port to
 Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > In principal we could also offer the user options as to which particular
> > platform a guest looks like.
> 
> At least when using a qemu based simulation. Most platforms have some
> characteristics that are not meaningful in a classic virtualization
> scenario, but it would certainly be helpful to use the virtualization
> extensions to run a kernel that was built for a particular platform
> faster than with pure qemu, when you want to test that kernel image.
> 
> It has been suggested in the past that it would be nice to run the
> guest kernel built for the same platform as the host kernel by
> default, but I think it would be much better to have just one
> platform that we end up using for guests on any host platform,
> unless there is a strong reason to do otherwise.
> 
> There is also ongoing restructuring in the ARM Linux kernel to
> allow running the same kernel binary on multiple platforms. While
> there is still a lot of work to be done, you should assume that
> we will finish it before you see lots of users in production, there
> is no need to plan for the current one-kernel-per-board case.

It is very good to hear, I am counting on it.


> > > Ok. It would of course still be possible to agree on an argument passing
> > > convention so that we can share the macros used to issue the hcalls,
> > > even if the individual commands are all different.
> > 
> > I think it likely that we can all agree on a common calling convention
> > for N-argument hypercalls. It doubt there are that many useful choices
> > with conflicting requirements yet strongly compelling advantages.
> 
> Exactly. I think it's only lack of communication that has resulted in
> different interfaces for each hypervisor on the other architectures.

It is also due to history: on X86 it was possible to issue hypercalls to
Xen before VMCALL (the X86 version of HVC) was available.


> KVM and Xen at least both fall into the single-return-value category,
> so we should be able to agree on a calling conventions. KVM does not
> have an hcall API on ARM yet, and I see no reason not to use the
> same implementation that you have in the Xen guest.
> 
> Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> file into a common asm/hypercall.h and submit it for review to the
> arm kernel list?

Sure, I can do that.
Usually the hypercall calling convention is very hypervisor specific,
but if it turns out that we have the same requirements I happy to design
a common interface.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:32:29 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:32:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVox3-0002SL-9q; Wed, 30 Nov 2011 18:32:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RVox1-0002SG-5g
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 18:32:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1322677851!58959368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18478 invoked from network); 30 Nov 2011 18:30:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 18:30:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,272,1320624000"; 
   d="scan'208";a="9215614"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 18:31:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 18:31:37 +0000
Date: Wed, 30 Nov 2011 18:32:33 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Arnd Bergmann <arnd@arndb.de>
In-Reply-To: <201111301815.01297.arnd@arndb.de>
Message-ID: <alpine.DEB.2.00.1111301820290.31179@kaball-desktop>
References: <alpine.DEB.2.00.1111281009090.31179@kaball-desktop>
	<201111301432.54463.arnd@arndb.de>
	<1322670473.31810.129.camel@zakaz.uk.xensource.com>
	<201111301815.01297.arnd@arndb.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"android-virt@lists.cs.columbia.edu" <android-virt@lists.cs.columbia.edu>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"embeddedxen-devel@lists.sourceforge.net"
	<embeddedxen-devel@lists.sourceforge.net>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [Embeddedxen-devel] [ANNOUNCE] Xen port to
 Cortex-A15 / ARMv7 with virt extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 30 Nov 2011, Arnd Bergmann wrote:
> > In principal we could also offer the user options as to which particular
> > platform a guest looks like.
> 
> At least when using a qemu based simulation. Most platforms have some
> characteristics that are not meaningful in a classic virtualization
> scenario, but it would certainly be helpful to use the virtualization
> extensions to run a kernel that was built for a particular platform
> faster than with pure qemu, when you want to test that kernel image.
> 
> It has been suggested in the past that it would be nice to run the
> guest kernel built for the same platform as the host kernel by
> default, but I think it would be much better to have just one
> platform that we end up using for guests on any host platform,
> unless there is a strong reason to do otherwise.
> 
> There is also ongoing restructuring in the ARM Linux kernel to
> allow running the same kernel binary on multiple platforms. While
> there is still a lot of work to be done, you should assume that
> we will finish it before you see lots of users in production, there
> is no need to plan for the current one-kernel-per-board case.

It is very good to hear, I am counting on it.


> > > Ok. It would of course still be possible to agree on an argument passing
> > > convention so that we can share the macros used to issue the hcalls,
> > > even if the individual commands are all different.
> > 
> > I think it likely that we can all agree on a common calling convention
> > for N-argument hypercalls. It doubt there are that many useful choices
> > with conflicting requirements yet strongly compelling advantages.
> 
> Exactly. I think it's only lack of communication that has resulted in
> different interfaces for each hypervisor on the other architectures.

It is also due to history: on X86 it was possible to issue hypercalls to
Xen before VMCALL (the X86 version of HVC) was available.


> KVM and Xen at least both fall into the single-return-value category,
> so we should be able to agree on a calling conventions. KVM does not
> have an hcall API on ARM yet, and I see no reason not to use the
> same implementation that you have in the Xen guest.
> 
> Stefano, can you split out the generic parts of your asm/xen/hypercall.h
> file into a common asm/hypercall.h and submit it for review to the
> arm kernel list?

Sure, I can do that.
Usually the hypercall calling convention is very hypervisor specific,
but if it turns out that we have the same requirements I happy to design
a common interface.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:48:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:48:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVpC0-0002dB-SU; Wed, 30 Nov 2011 18:47:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.baruchi@gmail.com>)
	id 1RVpBz-0002d3-74; Wed, 30 Nov 2011 18:47:39 +0000
X-Env-Sender: mail.baruchi@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322678817!5673794!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28405 invoked from network); 30 Nov 2011 18:46:59 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 18:46:59 -0000
Received: by vcbfo1 with SMTP id fo1so935069vcb.30
	for <multiple recipients>; Wed, 30 Nov 2011 10:46:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=WR/i2wsfEChAfEnP90lT6MA8JAwhBA5sX4gyUe6RPeg=;
	b=X5zWneW6muAb9h9DPC75Y8rlhm/p97UUkb4g1ubWMEk7TFWcTo7i3cdYUVjCtpsVfZ
	5OlgYy+CLtlX8b1Jw23Wg9Eir/hMfyghtwB/1wtuMKJto1aAoEK18dtz3cRWOQKttlXF
	uHdzyZ5LetVdwfLFDcF/T+xH0PrsBJoD+YSPg=
MIME-Version: 1.0
Received: by 10.220.155.66 with SMTP id r2mr670553vcw.42.1322678815778; Wed,
	30 Nov 2011 10:46:55 -0800 (PST)
Received: by 10.52.187.4 with HTTP; Wed, 30 Nov 2011 10:46:55 -0800 (PST)
In-Reply-To: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
Date: Wed, 30 Nov 2011 16:46:55 -0200
Message-ID: <CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
From: Artur Baruchi <mail.baruchi@gmail.com>
To: xen-users <Xen-users@lists.xensource.com>, Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I just configured the serial console to see what is going on during
the boot. I tried to run fsck and changed the grub to use the device
path (/dev/sdaX) instead udisks-part-id, but no success.

Follow the console errors:

Loading drivers, configuring devices: [   69.701448] ata1.00:
exception Emask 0x0 SAct 0x0 SErr 0x0 act
 ion 0x6 frozen
[   69.705706] ata1.00: failed command: READ DMA
[   69.708402] ata1.00: cmd c8/00:20:b8:7a:66/00:00:00:00:00/e0 tag 0
dma 16384 in
[   69.708403]          res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask
0x4 (timeout)
[   69.717358] ata1.00: status: { DRDY }
[   69.872400] ata1.00: revalidation failed (errno=3D-2)
[   75.023385] ata1.00: revalidation failed (errno=3D-2)
[   80.174383] ata1.00: revalidation failed (errno=3D-2)
[   80.329687] end_request: I/O error, dev sda, sector 6716088
[   80.333096] end_request: I/O error, dev sda, sector 6716088
[   80.336676] end_request: I/O error, dev sda, sector 6716088
[   80.340408] end_request: I/O error, dev sda, sector 6145504
[   80.344063] end_request: I/O error, dev sda, sector 6145504
[   80.347465] end_request: I/O error, dev sda, sector 6145504
[   80.351795] end_request: I/O error, dev sda, sector 6145504
[   80.356081] end_request: I/O error, dev sda, sector 6145504
[   80.359587] end_request: I/O error, dev sda, sector 6145504
[   80.363115] end_request: I/O error, dev sda, sector 6145504
[   80.366535] end_request: I/O error, dev sda, sector 6145504
[   80.370034] end_request: I/O error, dev sda, sector 6145504
[   80.373924] end_request: I/O error, dev sda, sector 9979920
[   80.377458] Buffer I/O error on device sda3, logical block 721410
[   80.389108] end_request: I/O error, dev sda, sector 4970504
[   80.392576] end_request: I/O error, dev sda, sector 4970504
[   80.396208] end_request: I/O error, dev sda, sector 11290592
[   80.399747] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
[   80.406333] end_request: I/O error, dev sda, sector 4208640
[   80.409650] Buffer I/O error on device sda3, logical block 0
udevd-work[1631]: exec of program '/lib/udev/ata_id' failed

[   80.416228] end_request: I/O error, dev sda, sector 6796224
[   80.419759] end_request: I/O error, dev sda, sector 6796288
[   80.423135] end_request: I/O error, dev sda, sector 6796288
[   80.425117] end_request: I/O error, dev sda, sector 6796288
[   80.427447] end_request: I/O error, dev sda, sector 6796288
[   80.429840] end_request: I/O error, dev sda, sector 6796288
[   80.432094] end_request: I/O error, dev sda, sector 6796288
[   80.434425] end_request: I/O error, dev sda, sector 6796288
[   80.436746] end_request: I/O error, dev sda, sector 6796288
[   80.439043] end_request: I/O error, dev sda, sector 6796288
[   80.441358] end_request: I/O error, dev sda, sector 6796288
[   80.443626] end_request: I/O error, dev sda, sector 6796288
[   80.445864] end_request: I/O error, dev sda, sector 6796288
[   80.448051] end_request: I/O error, dev sda, sector 6796288
[   80.450271] end_request: I/O error, dev sda, sector 6796288
[   80.452482] end_request: I/O error, dev sda, sector 6796288
[   80.454745] end_request: I/O error, dev sda, sector 6796288
[   80.457029] end_request: I/O error, dev sda, sector 6796288
[   80.459299] end_request: I/O error, dev sda, sector 6796288
[   80.461604] end_request: I/O error, dev sda, sector 6796288
[   80.463843] end_request: I/O error, dev sda, sector 6796288
[   80.466045] end_request: I/O error, dev sda, sector 6796288
[   80.468274] end_request: I/O error, dev sda, sector 6796288
[   80.470510] end_request: I/O error, dev sda, sector 6796288
[   80.472725] end_request: I/O error, dev sda, sector 6796288
[   80.474902] end_request: I/O error, dev sda, sector 6796288
[   80.477103] end_request: I/O error, dev sda, sector 6796288
[   80.479278] end_request: I/O error, dev sda, sector 6796288
[   80.481514] end_request: I/O error, dev sda, sector 6796288
[   80.483647] end_request: I/O error, dev sda, sector 6796288
[   80.485780] end_request: I/O error, dev sda, sector 6796288
[   80.487838] end_request: I/O error, dev sda, sector 6796288
[   80.489897] end_request: I/O error, dev sda, sector 6796224
[   80.491920] end_request: I/O error, dev sda, sector 6796224
[   80.494294] end_request: I/O error, dev sda, sector 4971928
[   80.496445] end_request: I/O error, dev sda, sector 4971928
[   80.498650] end_request: I/O error, dev sda, sector 11290592
[   80.500834] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
[   80.504930] end_request: I/O error, dev sda, sector 4208640
[   80.507019] Buffer I/O error on device sda3, logical block 0
udevd-work[1632]: exec of program '/lib/udev/scsi_id' failed

[   80.511028] end_request: I/O error, dev sda, sector 12352272
[   80.513236] Buffer I/O error on device sda3, logical block 1017954
[   80.515677] end_request: I/O error, dev sda, sector 12360888
[   80.518021] Buffer I/O error on device sda3, logical block 1019031
[   80.520527] Buffer I/O error on device sda3, logical block 1019032
[   80.523072] end_request: I/O error, dev sda, sector 9980016
[   80.525394] journal_bmap: journal block not found at offset 12 on sda3
[   80.527956] Aborting journal on device sda3.
[   80.529854] end_request: I/O error, dev sda, sector 9979920
[   80.532119] Buffer I/O error on device sda3, logical block 721410
[   80.534799] end_request: I/O error, dev sda, sector 9979928
[   80.537239] end_request: I/O error, dev sda, sector 9979936
[   80.539639] end_request: I/O error, dev sda, sector 9370632
[   80.542144] end_request: I/O error, dev sda, sector 9370632
[   80.544499] EXT3-fs (sda3): error: ext3_journal_start_sb: Detected
aborted journal
[   80.547659] EXT3-fs (sda3): error: remounting filesystem read-only
[   80.550535] end_request: I/O error, dev sda, sector 11290592
[   80.552989] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
udevd-work[1634]: exec of program '/sbin/blkid' failed

[   80.559337] end_request: I/O error, dev sda, sector 4972560
[   80.561964] end_request: I/O error, dev sda, sector 4972560
[   80.564546] end_request: I/O error, dev sda, sector 11290592
[   80.567069] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
udevd-work[1635]: exec of program '/lib/udev/edd_id' failed

[   80.576377] end_request: I/O error, dev sda, sector 4952712
[   80.580086] end_request: I/O error, dev sda, sector 4952712
[   80.583689] end_request: I/O error, dev sda, sector 11290592
[   80.586292] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
udevd-work[1636]: exec of program '/lib/udev/udisks-part-id' failed

[   80.593995] end_request: I/O error, dev sda, sector 9370632
[   80.596704] end_request: I/O error, dev sda, sector 9370632
[   80.596755] end_request: I/O error, dev sda, sector 11290592
[   80.596760] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
udevd-work[1637][   80.608632] end_request: I/O error, dev sda, sector 1129=
0592
: exec of program '/sbin/blkid' failed[   80.612951] EXT3-fs error
(device sda3): ext3_get_inode_loc: u
nable to read inode block - inode=3D223126, block=3D885244


[   80.621449] end_request: I/O error, dev sda, sector 9370632
[   80.624665] end_request: I/O error, dev sda, sector 11290592
[   80.627305] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
udevd-work[1638]: exec of program '/sbin/blkid' failed

udevd-work[1639]: exec of program '/sbin/blkid' failed

[   80.635017] end_request: I/O error, dev sda, sector 4952712
[   80.637899] end_request: I/O error, dev sda, sector 4952712
[   80.637956] end_request: I/O error, dev sda, sector 11290592
[   80.637962] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
[   80.649954] end_request: I/O error, dev sda, sector 4952712
udevd-work[1640]: exec of program '/lib/udev/udi[   80.649974]
end_request: I/O error, dev sda, sector
11290592
sks-part-id' failed
[   80.649981] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244

udevd-work[1641][   80.664921] end_request: I/O error, dev sda, sector 1129=
0592
: exec of program '/lib/udev/udisks-part-id' fai[   80.669088] EXT3-fs
error (device sda3): ext3_get_in
ode_loc: ledunable to read inode block - inode=3D223126, block=3D885244


udevd-work[1642]: exec of program '/lib/udev/udisks-part-id' failed

                                                                      done
[   80.688649] end_request: I/O error, dev sda, sector 11516760
[   80.693402] end_request: I/O error, dev sda, sector 11517320
[   80.698410] end_request: I/O error, dev sda, sector 11516760
boot.loadmodules: Input/output error
[   80.705752] end_request: I/O error, dev sda, sector 11517320
boot.rootfsck: Input/output error
[   80.712719] end_request: I/O error, dev sda, sector 11516496
[   80.717814] end_request: I/O error, dev sda, sector 11516704
[   80.730101] end_request: I/O error, dev sda, sector 11516496
boot.clock: Input/output error
[   80.736217] end_request: I/O error, dev sda, sector 11516768
[   80.741296] end_request: I/O error, dev sda, sector 11352104
[   80.745949] end_request: I/O error, dev sda, sector 11352104
boot.device-mapper: Input/output error
[   80.753208] end_request: I/O error, dev sda, sector 11516768
boot.localfs: Input/output error
[   80.760052] end_request: I/O error, dev sda, sector 11516488
[   80.764909] end_request: I/O error, dev sda, sector 11499608
[   80.769502] end_request: I/O error, dev sda, sector 11303224
[   80.775085] end_request: I/O error, dev sda, sector 11516744
[   80.779703] end_request: I/O error, dev sda, sector 11517168
[   80.784166] end_request: I/O error, dev sda, sector 11517360
[   80.788596] end_request: I/O error, dev sda, sector 11518640
[   80.793861] end_request: I/O error, dev sda, sector 11518640
[   80.798273] end_request: I/O error, dev sda, sector 11517360
[   80.803364] end_request: I/O error, dev sda, sector 11517176
boot.swap: Input/output error
[   80.809435] end_request: I/O error, dev sda, sector 11517168
boot.proc: Input/output error
[   80.815339] end_request: I/O error, dev sda, sector 11516488
boot.localnet: Input/output error[   80.820846] end_request: I/O
error, dev sda, sector 11516744
[   80.825458] end_request: I/O error, dev sda, sector 11499608
[   80.829771] end_request: I/O error, dev sda, sector 11303224
[   80.834086] end_request: I/O error, dev sda, sector 11516752

boot.cleanup: In[   80.838667] end_request: I/O error, dev sda, sector 1151=
8160
put/output error[   80.843568] end_request: I/O error, dev sda, sector 1151=
6752

[   80.847792] end_request: I/O error, dev sda, sector 11518160
boot.cycle: Input/output error[   80.853141] end_request: I/O error,
dev sda, sector 11417656

[   80.853840] end_request: I/O error, dev sda, sector 11417656
boot.fuse: Input/output error
boot.klog: Input/output error
boot.sysctl: Input/output error
[   80.865148] end_request: I/O error, dev sda, sector 11516712
[   80.865199] end_request: I/O error, dev sda, sector 11516712
boot.ldconfig: Input/output error
boot.udev_retry: Input/output error
boot.apparmor: Input/output error
boot.ipconfig: Input/output error
System Boot Control: The system has been                              set up
Failed features: boot.loadmodules boot.rootfsck boot.clock
boot.device-mapper boot.localfs boot.cleanup
     boot.cycle boot.fuse boot.klog boot.localnet boot.proc boot.swap
boot.sysctl boot.ldconfig boot.udev_r
etry boot.apparmor boot.ipconfig
System Boot Control: Running /etc/init.d/boot.local
[   80.890020] end_request: I/O error, dev sda, sector 11540760
[   80.892185] end_request: I/O error, dev sda, sector 11540760
/etc/init.d/boot.local: /etc/init.d/boot.local: Input/output error    failed
[   80.897735] end_request: I/O error, dev sda, sector 9369944
[   80.900025] end_request: I/O error, dev sda, sector 9369944
[   80.902265] end_request: I/O error, dev sda, sector 9369944
/etc/init.d/boot: line 314: /sbin/killproc: Input/output error
/etc/init.d/boot: line 326: /var/run/no_blogd: Read-only file system
[   80.909885] end_request: I/O error, dev sda, sector 12335128
[   80.913314] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2539                               69,
block=3D1015811
[   80.920333] end_request: I/O error, dev sda, sector 12335128
[   80.923922] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2539                               69,
block=3D1015811
[   80.931552] end_request: I/O error, dev sda, sector 12335128
[   80.935604] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2539                               69,
block=3D1015811
[   80.944776] end_request: I/O error, dev sda, sector 11290592
[   80.948819] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
INIT: Entering runlevel: 3
[   80.965451] end_request: I/O error, dev sda, sector 11519720
[   80.969737] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   80.980514] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
80.987414] end_request: I/O erro                               r, dev
sda, sector 11519720

[   80.991743] end_request: I/O error, dev sda, sector 11519720
/etc/initscript:[   80.996145] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/s[   81.005996] end_request: I/O error,
dev sda, sector 11519720
ysconfig/ulimit: Input/output er[   81.010510] end_request: I/O error,
dev sda, sector 11519720
ror[   81.016077] end_request: I/O error, dev sda, sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
81.022320] end_request: I/O erro                               r, dev
sda, sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript:[   81.030711] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit:[   81.035523] end_request: I/O error,
dev sda, sector 11519720
 Input/output error
/etc/initscript:[   81.043077] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit:[   81.047889] end_request: I/O error,
dev sda, sector 11519720
 Input/output error[   81.052231] end_request: I/O error, dev sda,
sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
81.062739] end_request: I/O error, dev s
da, sector 11519720
ut error
[   81.066952] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.081287] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.087077]
end_request: I/O error, dev sda, sector
11519720
 Input/output error
[   81.092828] end_request: I/O error, dev sda, sector 11519720
[   81.097171] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
81.105199] end_request: I/O error,                                dev
sda, sector 11519720
ror
/etc/initscript: line 77: /[   81.109861] end_request: I/O error, dev
sda, sector 11519720
etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input[   81.116079]
end_request: I/O error, dev sda, s                               ector
11519720
/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/uli[   81.123656]
end_request: I/O error, dev sda, sector 1151
    9720
mit: Input/output error
[   81.131077] end_request: I/O error, dev sda, sector 11519720
/etc/initscript:[   81.135256] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.145043] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
81.151102] end_request: I/O erro                               r, dev
sda, sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript:[   81.158246] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error[   81.163908]
end_request: I/O error, dev sda, sect                               or
11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript:[   81.170077] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error
[   81.175614] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
81.181692] end_request: I/O erro                               r, dev
sda, sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.188834] end_request: I/O error, dev sda, sector 11519720
[   81.193074] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ul[   81.202959] end_request:
I/O error, dev sda, sector 11519                               720
imit: Input/output error
[   81.209078] end_request: I/O error, dev sda, sector 11519720
[   81.215046] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.220029]
end_request: I/O error, dev sda, sector
11519720
 Input/output error
/etc/initscript:[   81.224860] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error[   81.230950]
end_request: I/O error, dev sda, sect                               or
11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.241445] end_request: I/O error, dev sda, sector 11519720
[   81.245133] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
81.253519] end_request: I/O erro                               r, dev
sda, sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
81.259342] end_request: I/O error,                                dev
sda, sector 11519720
ror
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
81.265077] end_request: I/O error, dev s
da, sector 11519720
ut error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sy[   81.271786] end_request: I/O
error, dev sda, sector 11519720
sconfig/ulimit: Input/output error
[   81.277066] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.284078] end_request: I/O error, dev sda, sector 11519720
[   81.287740] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.292708]
end_request: I/O error, dev sda, sector
11519720
 Input/output error[   81.298719] end_request: I/O error, dev sda,
sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript:[   81.304841] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.313187] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.324518] end_request: I/O error, dev sda, sector 11519720
[   81.329435] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
81.334830] end_request: I/O error,                                dev
sda, sector 11519720
ror
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line [   81.341698] end_request: I/O error, dev sda,
sector 11519720
77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
INIT: Id "6[   81.349010] end_request: I/O error, dev sda, sector 11519720
" respawning too fast: disabled for 5 minutes
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
81.355880] end_request: I/O error,                                dev
sda, sector 11519720
ror
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.363875] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
81.369261] end_request: I/O error,                                dev
sda, sector 11519720
ror
INIT: Id "co" respawning too fast: disabled for 5 minutes
/etc/initscript: line 77: /etc[   81.376228] end_request: I/O error,
dev sda, sector 11519720
/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
INI[   81.383188] end_request: I/O error, dev sda, sector 11519720
T: Id "3" respawning too fast: disabled for 5 minutes
/etc/initscript: line 77[   81.389244] end_request: I/O error, dev
sda, sector 11519720
: /etc/sysconfig/ulimit: Input/output error
INIT: Id "4" respawning too fast: disabled for 5 minutes
/etc/in[   81.395907] end_request: I/O error, dev sda, sector 11519720
itscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: I[   81.403341]
end_request: I/O error, dev sda, secto                               r
11519720
nput/output error
INIT: Id "5" respawning too fast: disabled for 5 minutes
/etc/initscript: [   81.410018] end_request: I/O error, dev sda, sector 115=
19720
line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
INIT: Id "1" respawning too fast: disabled for 5 minutes
[   81.420725] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.430746] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.440664] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
INIT: Id "2" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel




On Wed, Nov 30, 2011 at 11:48 AM, Artur Baruchi <mail.baruchi@gmail.com> wr=
ote:
> Hi.
>
> Im installing a VM to run a benchmark, Im able to install the VM issue
> the first boot (to setup network configurations), but if I reboot the
> VM it just hangs and do not boot. I've re-installed the machine but no
> success. Follow some details:
>
> - Dom0: Opensuse 11.3 (x86_64), kernel 2.6.34-12-xen,
> xen-4.0.0_21091_05-6.6.x86_64
> - DomU: Full Virtualization, Opensuse 11.3 (x86_64), kernel 2.6.34-12-des=
ktop
>
> Some errors in message file (not sure that this errors mean something
> for this problem):
> Nov 27 23:02:17 linuxtemp01 kernel: [ 5681.075141] ata1: link is slow
> to respond, please be patient (ready=3D0)
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073141] ata1: device not
> ready (errno=3D-16), forcing hardreset
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073236] ata1: soft resetting l=
ink
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.228817] ata1.00: configured
> for MWDMA2
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230503] ata1.01: configured
> for MWDMA1
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230508] ata1.00: device
> reported invalid CHS sector 0
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230515] ata1: EH complete
> Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701259] ata1.01: exception
> Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701262] ata1.01: failed
> command: WRITE DMA EXT
> Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701265] ata1.01: cmd
> 35/00:98:ef:c0:24/00:02:02:00:00/f0 tag 0 dma 339968 out
> Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701266] =A0 =A0 =A0 =A0 =A0res
> 40/00:01:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
> Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701268] ata1.01: status: { DRD=
Y }
> Nov 27 23:08:29 linuxtemp01 kernel: [ 6052.750078] ata1: link is slow
> to respond, please be patient (ready=3D0)
> Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748079] ata1: device not
> ready (errno=3D-16), forcing hardreset
> Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748134] ata1: soft resetting l=
ink
> Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.902320] ata1.00: configured
> for MWDMA2
> Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903499] ata1.01: configured
> for MWDMA1
> Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903503] ata1.01: device
> reported invalid CHS sector 0
> Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903506] ata1: EH complete
>
> My problem is very similar to this one:
> http://web.archiveorange.com/archive/v/wmeLDfqXdkxOOQURv2Ak
>
> But the workaround for this issue is not working for me.
>
> Any help will be welcome.
>
> Thanks in advance.
>
> Att.
> Artur Baruchi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 18:48:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 18:48:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVpC0-0002dB-SU; Wed, 30 Nov 2011 18:47:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.baruchi@gmail.com>)
	id 1RVpBz-0002d3-74; Wed, 30 Nov 2011 18:47:39 +0000
X-Env-Sender: mail.baruchi@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1322678817!5673794!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28405 invoked from network); 30 Nov 2011 18:46:59 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 18:46:59 -0000
Received: by vcbfo1 with SMTP id fo1so935069vcb.30
	for <multiple recipients>; Wed, 30 Nov 2011 10:46:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=WR/i2wsfEChAfEnP90lT6MA8JAwhBA5sX4gyUe6RPeg=;
	b=X5zWneW6muAb9h9DPC75Y8rlhm/p97UUkb4g1ubWMEk7TFWcTo7i3cdYUVjCtpsVfZ
	5OlgYy+CLtlX8b1Jw23Wg9Eir/hMfyghtwB/1wtuMKJto1aAoEK18dtz3cRWOQKttlXF
	uHdzyZ5LetVdwfLFDcF/T+xH0PrsBJoD+YSPg=
MIME-Version: 1.0
Received: by 10.220.155.66 with SMTP id r2mr670553vcw.42.1322678815778; Wed,
	30 Nov 2011 10:46:55 -0800 (PST)
Received: by 10.52.187.4 with HTTP; Wed, 30 Nov 2011 10:46:55 -0800 (PST)
In-Reply-To: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
Date: Wed, 30 Nov 2011 16:46:55 -0200
Message-ID: <CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
From: Artur Baruchi <mail.baruchi@gmail.com>
To: xen-users <Xen-users@lists.xensource.com>, Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I just configured the serial console to see what is going on during
the boot. I tried to run fsck and changed the grub to use the device
path (/dev/sdaX) instead udisks-part-id, but no success.

Follow the console errors:

Loading drivers, configuring devices: [   69.701448] ata1.00:
exception Emask 0x0 SAct 0x0 SErr 0x0 act
 ion 0x6 frozen
[   69.705706] ata1.00: failed command: READ DMA
[   69.708402] ata1.00: cmd c8/00:20:b8:7a:66/00:00:00:00:00/e0 tag 0
dma 16384 in
[   69.708403]          res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask
0x4 (timeout)
[   69.717358] ata1.00: status: { DRDY }
[   69.872400] ata1.00: revalidation failed (errno=3D-2)
[   75.023385] ata1.00: revalidation failed (errno=3D-2)
[   80.174383] ata1.00: revalidation failed (errno=3D-2)
[   80.329687] end_request: I/O error, dev sda, sector 6716088
[   80.333096] end_request: I/O error, dev sda, sector 6716088
[   80.336676] end_request: I/O error, dev sda, sector 6716088
[   80.340408] end_request: I/O error, dev sda, sector 6145504
[   80.344063] end_request: I/O error, dev sda, sector 6145504
[   80.347465] end_request: I/O error, dev sda, sector 6145504
[   80.351795] end_request: I/O error, dev sda, sector 6145504
[   80.356081] end_request: I/O error, dev sda, sector 6145504
[   80.359587] end_request: I/O error, dev sda, sector 6145504
[   80.363115] end_request: I/O error, dev sda, sector 6145504
[   80.366535] end_request: I/O error, dev sda, sector 6145504
[   80.370034] end_request: I/O error, dev sda, sector 6145504
[   80.373924] end_request: I/O error, dev sda, sector 9979920
[   80.377458] Buffer I/O error on device sda3, logical block 721410
[   80.389108] end_request: I/O error, dev sda, sector 4970504
[   80.392576] end_request: I/O error, dev sda, sector 4970504
[   80.396208] end_request: I/O error, dev sda, sector 11290592
[   80.399747] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
[   80.406333] end_request: I/O error, dev sda, sector 4208640
[   80.409650] Buffer I/O error on device sda3, logical block 0
udevd-work[1631]: exec of program '/lib/udev/ata_id' failed

[   80.416228] end_request: I/O error, dev sda, sector 6796224
[   80.419759] end_request: I/O error, dev sda, sector 6796288
[   80.423135] end_request: I/O error, dev sda, sector 6796288
[   80.425117] end_request: I/O error, dev sda, sector 6796288
[   80.427447] end_request: I/O error, dev sda, sector 6796288
[   80.429840] end_request: I/O error, dev sda, sector 6796288
[   80.432094] end_request: I/O error, dev sda, sector 6796288
[   80.434425] end_request: I/O error, dev sda, sector 6796288
[   80.436746] end_request: I/O error, dev sda, sector 6796288
[   80.439043] end_request: I/O error, dev sda, sector 6796288
[   80.441358] end_request: I/O error, dev sda, sector 6796288
[   80.443626] end_request: I/O error, dev sda, sector 6796288
[   80.445864] end_request: I/O error, dev sda, sector 6796288
[   80.448051] end_request: I/O error, dev sda, sector 6796288
[   80.450271] end_request: I/O error, dev sda, sector 6796288
[   80.452482] end_request: I/O error, dev sda, sector 6796288
[   80.454745] end_request: I/O error, dev sda, sector 6796288
[   80.457029] end_request: I/O error, dev sda, sector 6796288
[   80.459299] end_request: I/O error, dev sda, sector 6796288
[   80.461604] end_request: I/O error, dev sda, sector 6796288
[   80.463843] end_request: I/O error, dev sda, sector 6796288
[   80.466045] end_request: I/O error, dev sda, sector 6796288
[   80.468274] end_request: I/O error, dev sda, sector 6796288
[   80.470510] end_request: I/O error, dev sda, sector 6796288
[   80.472725] end_request: I/O error, dev sda, sector 6796288
[   80.474902] end_request: I/O error, dev sda, sector 6796288
[   80.477103] end_request: I/O error, dev sda, sector 6796288
[   80.479278] end_request: I/O error, dev sda, sector 6796288
[   80.481514] end_request: I/O error, dev sda, sector 6796288
[   80.483647] end_request: I/O error, dev sda, sector 6796288
[   80.485780] end_request: I/O error, dev sda, sector 6796288
[   80.487838] end_request: I/O error, dev sda, sector 6796288
[   80.489897] end_request: I/O error, dev sda, sector 6796224
[   80.491920] end_request: I/O error, dev sda, sector 6796224
[   80.494294] end_request: I/O error, dev sda, sector 4971928
[   80.496445] end_request: I/O error, dev sda, sector 4971928
[   80.498650] end_request: I/O error, dev sda, sector 11290592
[   80.500834] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
[   80.504930] end_request: I/O error, dev sda, sector 4208640
[   80.507019] Buffer I/O error on device sda3, logical block 0
udevd-work[1632]: exec of program '/lib/udev/scsi_id' failed

[   80.511028] end_request: I/O error, dev sda, sector 12352272
[   80.513236] Buffer I/O error on device sda3, logical block 1017954
[   80.515677] end_request: I/O error, dev sda, sector 12360888
[   80.518021] Buffer I/O error on device sda3, logical block 1019031
[   80.520527] Buffer I/O error on device sda3, logical block 1019032
[   80.523072] end_request: I/O error, dev sda, sector 9980016
[   80.525394] journal_bmap: journal block not found at offset 12 on sda3
[   80.527956] Aborting journal on device sda3.
[   80.529854] end_request: I/O error, dev sda, sector 9979920
[   80.532119] Buffer I/O error on device sda3, logical block 721410
[   80.534799] end_request: I/O error, dev sda, sector 9979928
[   80.537239] end_request: I/O error, dev sda, sector 9979936
[   80.539639] end_request: I/O error, dev sda, sector 9370632
[   80.542144] end_request: I/O error, dev sda, sector 9370632
[   80.544499] EXT3-fs (sda3): error: ext3_journal_start_sb: Detected
aborted journal
[   80.547659] EXT3-fs (sda3): error: remounting filesystem read-only
[   80.550535] end_request: I/O error, dev sda, sector 11290592
[   80.552989] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
udevd-work[1634]: exec of program '/sbin/blkid' failed

[   80.559337] end_request: I/O error, dev sda, sector 4972560
[   80.561964] end_request: I/O error, dev sda, sector 4972560
[   80.564546] end_request: I/O error, dev sda, sector 11290592
[   80.567069] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
udevd-work[1635]: exec of program '/lib/udev/edd_id' failed

[   80.576377] end_request: I/O error, dev sda, sector 4952712
[   80.580086] end_request: I/O error, dev sda, sector 4952712
[   80.583689] end_request: I/O error, dev sda, sector 11290592
[   80.586292] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
udevd-work[1636]: exec of program '/lib/udev/udisks-part-id' failed

[   80.593995] end_request: I/O error, dev sda, sector 9370632
[   80.596704] end_request: I/O error, dev sda, sector 9370632
[   80.596755] end_request: I/O error, dev sda, sector 11290592
[   80.596760] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
udevd-work[1637][   80.608632] end_request: I/O error, dev sda, sector 1129=
0592
: exec of program '/sbin/blkid' failed[   80.612951] EXT3-fs error
(device sda3): ext3_get_inode_loc: u
nable to read inode block - inode=3D223126, block=3D885244


[   80.621449] end_request: I/O error, dev sda, sector 9370632
[   80.624665] end_request: I/O error, dev sda, sector 11290592
[   80.627305] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
udevd-work[1638]: exec of program '/sbin/blkid' failed

udevd-work[1639]: exec of program '/sbin/blkid' failed

[   80.635017] end_request: I/O error, dev sda, sector 4952712
[   80.637899] end_request: I/O error, dev sda, sector 4952712
[   80.637956] end_request: I/O error, dev sda, sector 11290592
[   80.637962] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
[   80.649954] end_request: I/O error, dev sda, sector 4952712
udevd-work[1640]: exec of program '/lib/udev/udi[   80.649974]
end_request: I/O error, dev sda, sector
11290592
sks-part-id' failed
[   80.649981] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244

udevd-work[1641][   80.664921] end_request: I/O error, dev sda, sector 1129=
0592
: exec of program '/lib/udev/udisks-part-id' fai[   80.669088] EXT3-fs
error (device sda3): ext3_get_in
ode_loc: ledunable to read inode block - inode=3D223126, block=3D885244


udevd-work[1642]: exec of program '/lib/udev/udisks-part-id' failed

                                                                      done
[   80.688649] end_request: I/O error, dev sda, sector 11516760
[   80.693402] end_request: I/O error, dev sda, sector 11517320
[   80.698410] end_request: I/O error, dev sda, sector 11516760
boot.loadmodules: Input/output error
[   80.705752] end_request: I/O error, dev sda, sector 11517320
boot.rootfsck: Input/output error
[   80.712719] end_request: I/O error, dev sda, sector 11516496
[   80.717814] end_request: I/O error, dev sda, sector 11516704
[   80.730101] end_request: I/O error, dev sda, sector 11516496
boot.clock: Input/output error
[   80.736217] end_request: I/O error, dev sda, sector 11516768
[   80.741296] end_request: I/O error, dev sda, sector 11352104
[   80.745949] end_request: I/O error, dev sda, sector 11352104
boot.device-mapper: Input/output error
[   80.753208] end_request: I/O error, dev sda, sector 11516768
boot.localfs: Input/output error
[   80.760052] end_request: I/O error, dev sda, sector 11516488
[   80.764909] end_request: I/O error, dev sda, sector 11499608
[   80.769502] end_request: I/O error, dev sda, sector 11303224
[   80.775085] end_request: I/O error, dev sda, sector 11516744
[   80.779703] end_request: I/O error, dev sda, sector 11517168
[   80.784166] end_request: I/O error, dev sda, sector 11517360
[   80.788596] end_request: I/O error, dev sda, sector 11518640
[   80.793861] end_request: I/O error, dev sda, sector 11518640
[   80.798273] end_request: I/O error, dev sda, sector 11517360
[   80.803364] end_request: I/O error, dev sda, sector 11517176
boot.swap: Input/output error
[   80.809435] end_request: I/O error, dev sda, sector 11517168
boot.proc: Input/output error
[   80.815339] end_request: I/O error, dev sda, sector 11516488
boot.localnet: Input/output error[   80.820846] end_request: I/O
error, dev sda, sector 11516744
[   80.825458] end_request: I/O error, dev sda, sector 11499608
[   80.829771] end_request: I/O error, dev sda, sector 11303224
[   80.834086] end_request: I/O error, dev sda, sector 11516752

boot.cleanup: In[   80.838667] end_request: I/O error, dev sda, sector 1151=
8160
put/output error[   80.843568] end_request: I/O error, dev sda, sector 1151=
6752

[   80.847792] end_request: I/O error, dev sda, sector 11518160
boot.cycle: Input/output error[   80.853141] end_request: I/O error,
dev sda, sector 11417656

[   80.853840] end_request: I/O error, dev sda, sector 11417656
boot.fuse: Input/output error
boot.klog: Input/output error
boot.sysctl: Input/output error
[   80.865148] end_request: I/O error, dev sda, sector 11516712
[   80.865199] end_request: I/O error, dev sda, sector 11516712
boot.ldconfig: Input/output error
boot.udev_retry: Input/output error
boot.apparmor: Input/output error
boot.ipconfig: Input/output error
System Boot Control: The system has been                              set up
Failed features: boot.loadmodules boot.rootfsck boot.clock
boot.device-mapper boot.localfs boot.cleanup
     boot.cycle boot.fuse boot.klog boot.localnet boot.proc boot.swap
boot.sysctl boot.ldconfig boot.udev_r
etry boot.apparmor boot.ipconfig
System Boot Control: Running /etc/init.d/boot.local
[   80.890020] end_request: I/O error, dev sda, sector 11540760
[   80.892185] end_request: I/O error, dev sda, sector 11540760
/etc/init.d/boot.local: /etc/init.d/boot.local: Input/output error    failed
[   80.897735] end_request: I/O error, dev sda, sector 9369944
[   80.900025] end_request: I/O error, dev sda, sector 9369944
[   80.902265] end_request: I/O error, dev sda, sector 9369944
/etc/init.d/boot: line 314: /sbin/killproc: Input/output error
/etc/init.d/boot: line 326: /var/run/no_blogd: Read-only file system
[   80.909885] end_request: I/O error, dev sda, sector 12335128
[   80.913314] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2539                               69,
block=3D1015811
[   80.920333] end_request: I/O error, dev sda, sector 12335128
[   80.923922] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2539                               69,
block=3D1015811
[   80.931552] end_request: I/O error, dev sda, sector 12335128
[   80.935604] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2539                               69,
block=3D1015811
[   80.944776] end_request: I/O error, dev sda, sector 11290592
[   80.948819] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
to read inode block - inode=3D2231                               26,
block=3D885244
INIT: Entering runlevel: 3
[   80.965451] end_request: I/O error, dev sda, sector 11519720
[   80.969737] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   80.980514] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
80.987414] end_request: I/O erro                               r, dev
sda, sector 11519720

[   80.991743] end_request: I/O error, dev sda, sector 11519720
/etc/initscript:[   80.996145] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/s[   81.005996] end_request: I/O error,
dev sda, sector 11519720
ysconfig/ulimit: Input/output er[   81.010510] end_request: I/O error,
dev sda, sector 11519720
ror[   81.016077] end_request: I/O error, dev sda, sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
81.022320] end_request: I/O erro                               r, dev
sda, sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript:[   81.030711] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit:[   81.035523] end_request: I/O error,
dev sda, sector 11519720
 Input/output error
/etc/initscript:[   81.043077] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit:[   81.047889] end_request: I/O error,
dev sda, sector 11519720
 Input/output error[   81.052231] end_request: I/O error, dev sda,
sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
81.062739] end_request: I/O error, dev s
da, sector 11519720
ut error
[   81.066952] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.081287] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.087077]
end_request: I/O error, dev sda, sector
11519720
 Input/output error
[   81.092828] end_request: I/O error, dev sda, sector 11519720
[   81.097171] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
81.105199] end_request: I/O error,                                dev
sda, sector 11519720
ror
/etc/initscript: line 77: /[   81.109861] end_request: I/O error, dev
sda, sector 11519720
etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input[   81.116079]
end_request: I/O error, dev sda, s                               ector
11519720
/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/uli[   81.123656]
end_request: I/O error, dev sda, sector 1151
    9720
mit: Input/output error
[   81.131077] end_request: I/O error, dev sda, sector 11519720
/etc/initscript:[   81.135256] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.145043] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
81.151102] end_request: I/O erro                               r, dev
sda, sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript:[   81.158246] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error[   81.163908]
end_request: I/O error, dev sda, sect                               or
11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript:[   81.170077] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error
[   81.175614] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
81.181692] end_request: I/O erro                               r, dev
sda, sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.188834] end_request: I/O error, dev sda, sector 11519720
[   81.193074] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ul[   81.202959] end_request:
I/O error, dev sda, sector 11519                               720
imit: Input/output error
[   81.209078] end_request: I/O error, dev sda, sector 11519720
[   81.215046] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.220029]
end_request: I/O error, dev sda, sector
11519720
 Input/output error
/etc/initscript:[   81.224860] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error[   81.230950]
end_request: I/O error, dev sda, sect                               or
11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.241445] end_request: I/O error, dev sda, sector 11519720
[   81.245133] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
81.253519] end_request: I/O erro                               r, dev
sda, sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
81.259342] end_request: I/O error,                                dev
sda, sector 11519720
ror
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
81.265077] end_request: I/O error, dev s
da, sector 11519720
ut error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sy[   81.271786] end_request: I/O
error, dev sda, sector 11519720
sconfig/ulimit: Input/output error
[   81.277066] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.284078] end_request: I/O error, dev sda, sector 11519720
[   81.287740] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.292708]
end_request: I/O error, dev sda, sector
11519720
 Input/output error[   81.298719] end_request: I/O error, dev sda,
sector 11519720

/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript:[   81.304841] end_request: I/O error, dev sda, sector 1151=
9720
 line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.313187] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.324518] end_request: I/O error, dev sda, sector 11519720
[   81.329435] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
81.334830] end_request: I/O error,                                dev
sda, sector 11519720
ror
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line [   81.341698] end_request: I/O error, dev sda,
sector 11519720
77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
INIT: Id "6[   81.349010] end_request: I/O error, dev sda, sector 11519720
" respawning too fast: disabled for 5 minutes
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
81.355880] end_request: I/O error,                                dev
sda, sector 11519720
ror
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.363875] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
81.369261] end_request: I/O error,                                dev
sda, sector 11519720
ror
INIT: Id "co" respawning too fast: disabled for 5 minutes
/etc/initscript: line 77: /etc[   81.376228] end_request: I/O error,
dev sda, sector 11519720
/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
INI[   81.383188] end_request: I/O error, dev sda, sector 11519720
T: Id "3" respawning too fast: disabled for 5 minutes
/etc/initscript: line 77[   81.389244] end_request: I/O error, dev
sda, sector 11519720
: /etc/sysconfig/ulimit: Input/output error
INIT: Id "4" respawning too fast: disabled for 5 minutes
/etc/in[   81.395907] end_request: I/O error, dev sda, sector 11519720
itscript: line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: I[   81.403341]
end_request: I/O error, dev sda, secto                               r
11519720
nput/output error
INIT: Id "5" respawning too fast: disabled for 5 minutes
/etc/initscript: [   81.410018] end_request: I/O error, dev sda, sector 115=
19720
line 77: /etc/sysconfig/ulimit: Input/output error
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
INIT: Id "1" respawning too fast: disabled for 5 minutes
[   81.420725] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.430746] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
[   81.440664] end_request: I/O error, dev sda, sector 11519720
/etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
INIT: Id "2" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel




On Wed, Nov 30, 2011 at 11:48 AM, Artur Baruchi <mail.baruchi@gmail.com> wr=
ote:
> Hi.
>
> Im installing a VM to run a benchmark, Im able to install the VM issue
> the first boot (to setup network configurations), but if I reboot the
> VM it just hangs and do not boot. I've re-installed the machine but no
> success. Follow some details:
>
> - Dom0: Opensuse 11.3 (x86_64), kernel 2.6.34-12-xen,
> xen-4.0.0_21091_05-6.6.x86_64
> - DomU: Full Virtualization, Opensuse 11.3 (x86_64), kernel 2.6.34-12-des=
ktop
>
> Some errors in message file (not sure that this errors mean something
> for this problem):
> Nov 27 23:02:17 linuxtemp01 kernel: [ 5681.075141] ata1: link is slow
> to respond, please be patient (ready=3D0)
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073141] ata1: device not
> ready (errno=3D-16), forcing hardreset
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073236] ata1: soft resetting l=
ink
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.228817] ata1.00: configured
> for MWDMA2
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230503] ata1.01: configured
> for MWDMA1
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230508] ata1.00: device
> reported invalid CHS sector 0
> Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230515] ata1: EH complete
> Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701259] ata1.01: exception
> Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701262] ata1.01: failed
> command: WRITE DMA EXT
> Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701265] ata1.01: cmd
> 35/00:98:ef:c0:24/00:02:02:00:00/f0 tag 0 dma 339968 out
> Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701266] =A0 =A0 =A0 =A0 =A0res
> 40/00:01:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
> Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701268] ata1.01: status: { DRD=
Y }
> Nov 27 23:08:29 linuxtemp01 kernel: [ 6052.750078] ata1: link is slow
> to respond, please be patient (ready=3D0)
> Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748079] ata1: device not
> ready (errno=3D-16), forcing hardreset
> Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748134] ata1: soft resetting l=
ink
> Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.902320] ata1.00: configured
> for MWDMA2
> Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903499] ata1.01: configured
> for MWDMA1
> Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903503] ata1.01: device
> reported invalid CHS sector 0
> Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903506] ata1: EH complete
>
> My problem is very similar to this one:
> http://web.archiveorange.com/archive/v/wmeLDfqXdkxOOQURv2Ak
>
> But the workaround for this issue is not working for me.
>
> Any help will be welcome.
>
> Thanks in advance.
>
> Att.
> Artur Baruchi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 19:14:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 19:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVpbp-0002y0-Ng; Wed, 30 Nov 2011 19:14:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVpbn-0002xv-MH
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 19:14:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322680420!5371033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6630 invoked from network); 30 Nov 2011 19:13:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 19:13:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,272,1320624000"; 
   d="scan'208";a="9216289"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 19:13:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 19:13:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVpb9-00050t-NV;
	Wed, 30 Nov 2011 19:13:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVpb9-0004Zv-Ii;
	Wed, 30 Nov 2011 19:13:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10191-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 19:13:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10191: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10191 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10191/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 10190

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   like 10190
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  3c4c29899d8a
baseline version:
 xen                  64088ba60263

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <maillists.shan@gmail.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24271:3c4c29899d8a
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 07:18:11 2011 -0800
    
    hvmloader: Write address of VM generation id buffer into xenstore
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24270:08716a7f1b74
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 30 07:12:41 2011 -0800
    
    Free d->mem_event on domain destruction.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24269:2cbc53a24683
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Nov 30 07:08:53 2011 -0800
    
    mem_event: move mem_event_domain out of struct domain
    
    An upcoming change may increase the size of mem_event_domain. The result
    is a build failure because struct domain gets larger than a page.
    Allocate the room for the three mem_event_domain members at runtime.
    
    v2:
     - remove mem_ prefix from members of new struct
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24268:31f751ef3e00
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Wed Nov 30 07:06:24 2011 -0800
    
    x86/hvm/vmx: Trace traps and realmode exits
    
    Add some more tracing to vmexits that don't currently have
    trace information:
     * VMX realmode emulation
     * Various VMX traps
     * Fast-pathed APIC accesses
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24267:77421dbd4871
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:57:20 2011 -0800
    
    hvmloader: Add xenstore-write support
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24266:295337e5d4e0
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:55:31 2011 -0800
    
    hvmloader: Add snprintf()
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24265:54a9e172a373
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:53:36 2011 -0800
    
    hvmloader: Allocate an 8 byte buffer to contain the VM generation id
    and populate it at boot time with a value read from
    "platform/generation_id". Also add code to libxl to populate this
    xenstore key with the value of a new 'generation_id' parameter in the
    VM config file.  Populate the ADDR package of VM_Gen_Counter ACPI
    device such that the first integer evaluates to the low order 32 bits
    of the buffer address and the second integer evaluates to the high
    order 32 bits of the buffer address.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24264:e925e4719844
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:50:45 2011 -0800
    
    hvmloader: Add 'ctype' infrastructure
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24263:e5a53cdd4252
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:47:16 2011 -0800
    
    hvmloader: Add an ACPI device exposing a package called ADDR,
    evaluating to two integers, and with _CID and _DDN set to
    "VM_Gen_Counter".
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24262:67c447c02537
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:42:04 2011 -0800
    
    x86/hvm: Re-instate HVM IRQ debug code and add keyhandler.
    
    I found this patch useful a couple of times while trying to debug the
    viridian problem.  irq_dump() was #ifdef-ed out so this patch puts it
    back and registers a handler on the 'I' key to iterate over all HVM
    domains and call it.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24261:64088ba60263
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Nov 30 10:23:41 2011 +0100
    
    x86/cpuidle: add Westmere-EX support to hw residencies reading logic
    
    This is in accordance with
    http://software.intel.com/en-us/articles/intel-processor-identification-with-cpuid-model-and-family-numbers/
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Haitao Shan <maillists.shan@gmail.com>
    
    
========================================
commit 89daacab7035d408f32f2cb1acf68c96d6cbefed
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Nov 28 17:16:52 2011 +0000

    qemu-dm: open char devices "file:..." with O_APPEND
    
    The "file:..." character open method is used by serial and parallel
    ports, to divert the output to a file (and these devices never produce
    any input).  This is like a logfile, and so should be opened for
    append.
    
    In qemu-xen-unstable, this is used only for the qemu stderr by libxl.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 19:14:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 19:14:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVpbp-0002y0-Ng; Wed, 30 Nov 2011 19:14:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVpbn-0002xv-MH
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 19:14:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322680420!5371033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6630 invoked from network); 30 Nov 2011 19:13:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 19:13:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,272,1320624000"; 
   d="scan'208";a="9216289"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 19:13:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 19:13:40 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVpb9-00050t-NV;
	Wed, 30 Nov 2011 19:13:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVpb9-0004Zv-Ii;
	Wed, 30 Nov 2011 19:13:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10191-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 19:13:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10191: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10191 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10191/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf      7 debian-install            fail REGR. vs. 10190

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   like 10190
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  3c4c29899d8a
baseline version:
 xen                  64088ba60263

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <maillists.shan@gmail.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24271:3c4c29899d8a
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 07:18:11 2011 -0800
    
    hvmloader: Write address of VM generation id buffer into xenstore
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24270:08716a7f1b74
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 30 07:12:41 2011 -0800
    
    Free d->mem_event on domain destruction.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24269:2cbc53a24683
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Nov 30 07:08:53 2011 -0800
    
    mem_event: move mem_event_domain out of struct domain
    
    An upcoming change may increase the size of mem_event_domain. The result
    is a build failure because struct domain gets larger than a page.
    Allocate the room for the three mem_event_domain members at runtime.
    
    v2:
     - remove mem_ prefix from members of new struct
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24268:31f751ef3e00
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Wed Nov 30 07:06:24 2011 -0800
    
    x86/hvm/vmx: Trace traps and realmode exits
    
    Add some more tracing to vmexits that don't currently have
    trace information:
     * VMX realmode emulation
     * Various VMX traps
     * Fast-pathed APIC accesses
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24267:77421dbd4871
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:57:20 2011 -0800
    
    hvmloader: Add xenstore-write support
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24266:295337e5d4e0
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:55:31 2011 -0800
    
    hvmloader: Add snprintf()
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24265:54a9e172a373
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:53:36 2011 -0800
    
    hvmloader: Allocate an 8 byte buffer to contain the VM generation id
    and populate it at boot time with a value read from
    "platform/generation_id". Also add code to libxl to populate this
    xenstore key with the value of a new 'generation_id' parameter in the
    VM config file.  Populate the ADDR package of VM_Gen_Counter ACPI
    device such that the first integer evaluates to the low order 32 bits
    of the buffer address and the second integer evaluates to the high
    order 32 bits of the buffer address.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24264:e925e4719844
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:50:45 2011 -0800
    
    hvmloader: Add 'ctype' infrastructure
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24263:e5a53cdd4252
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:47:16 2011 -0800
    
    hvmloader: Add an ACPI device exposing a package called ADDR,
    evaluating to two integers, and with _CID and _DDN set to
    "VM_Gen_Counter".
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24262:67c447c02537
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:42:04 2011 -0800
    
    x86/hvm: Re-instate HVM IRQ debug code and add keyhandler.
    
    I found this patch useful a couple of times while trying to debug the
    viridian problem.  irq_dump() was #ifdef-ed out so this patch puts it
    back and registers a handler on the 'I' key to iterate over all HVM
    domains and call it.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24261:64088ba60263
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Nov 30 10:23:41 2011 +0100
    
    x86/cpuidle: add Westmere-EX support to hw residencies reading logic
    
    This is in accordance with
    http://software.intel.com/en-us/articles/intel-processor-identification-with-cpuid-model-and-family-numbers/
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Haitao Shan <maillists.shan@gmail.com>
    
    
========================================
commit 89daacab7035d408f32f2cb1acf68c96d6cbefed
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Nov 28 17:16:52 2011 +0000

    qemu-dm: open char devices "file:..." with O_APPEND
    
    The "file:..." character open method is used by serial and parallel
    ports, to divert the output to a file (and these devices never produce
    any input).  This is like a logfile, and so should be opened for
    append.
    
    In qemu-xen-unstable, this is used only for the qemu stderr by libxl.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 20:52:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 20:52:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVr7m-0004VI-Ow; Wed, 30 Nov 2011 20:51:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVr7l-0004VB-NZ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 20:51:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322686246!5617113!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12229 invoked from network); 30 Nov 2011 20:50:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-11.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Nov 2011 20:50:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322686246; l=300;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/DMdRSvvSPuTt+5DNm7v2NRQhYI=;
	b=EpBwOm7CE9tzDM//7Dd2/A6MJzvKQyFjeldOwxp5bJVPRLgVWzQJs0UUU2FRqpd2ABe
	HxS/7CRK9rALS6CGBrcs+GFFDGT03QZTFMShciXotrcn1mCVD0sq4MIAO1bYRbyPnlzNe
	rKJMNpjeu7Uwlq9op7FmUnR36sqx2BnmIU4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by post.strato.de (mrclete mo17) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w019d9nAUJntIb ;
	Wed, 30 Nov 2011 21:50:38 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 24EB918637; Wed, 30 Nov 2011 21:50:38 +0100 (CET)
Date: Wed, 30 Nov 2011 21:50:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20111130205037.GA5176@aepfle.de>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
	<37b46c492f8ac8d356b2.1322576453@cosworth.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <37b46c492f8ac8d356b2.1322576453@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 17 v3] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Ian Campbell wrote:

> +use List::MoreUtils qw/ uniq /;

This adds a new requires of perl-List-MoreUtils.rpm for make docs.
I'm not sure wether such buildrequires need to be listed in the README,
but at least markdown is listed. I think it is recommended for make docs

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 20:52:02 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 20:52:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVr7m-0004VI-Ow; Wed, 30 Nov 2011 20:51:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RVr7l-0004VB-NZ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 20:51:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1322686246!5617113!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDM=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12229 invoked from network); 30 Nov 2011 20:50:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-11.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Nov 2011 20:50:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322686246; l=300;
	s=domk; d=aepfle.de;
	h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From:
	Date:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=/DMdRSvvSPuTt+5DNm7v2NRQhYI=;
	b=EpBwOm7CE9tzDM//7Dd2/A6MJzvKQyFjeldOwxp5bJVPRLgVWzQJs0UUU2FRqpd2ABe
	HxS/7CRK9rALS6CGBrcs+GFFDGT03QZTFMShciXotrcn1mCVD0sq4MIAO1bYRbyPnlzNe
	rKJMNpjeu7Uwlq9op7FmUnR36sqx2BnmIU4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PFxZO
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-148.pools.arcor-ip.net [88.65.93.148])
	by post.strato.de (mrclete mo17) (RZmta 26.10 AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w019d9nAUJntIb ;
	Wed, 30 Nov 2011 21:50:38 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 24EB918637; Wed, 30 Nov 2011 21:50:38 +0100 (CET)
Date: Wed, 30 Nov 2011 21:50:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20111130205037.GA5176@aepfle.de>
References: <patchbomb.1322576442@cosworth.uk.xensource.com>
	<37b46c492f8ac8d356b2.1322576453@cosworth.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <37b46c492f8ac8d356b2.1322576453@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 11 of 17 v3] docs: generate an index for the
 html output
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Nov 29, Ian Campbell wrote:

> +use List::MoreUtils qw/ uniq /;

This adds a new requires of perl-List-MoreUtils.rpm for make docs.
I'm not sure wether such buildrequires need to be listed in the README,
but at least markdown is listed. I think it is recommended for make docs

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 21:00:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 21:00:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVrFn-0004fe-Ou; Wed, 30 Nov 2011 20:59:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVrFl-0004fW-PY
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 20:59:42 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322686741!157575!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7234 invoked from network); 30 Nov 2011 20:59:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 20:59:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,273,1320642000"; d="scan'208";a="172432792"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 15:59:00 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 15:59:00 -0500
MIME-Version: 1.0
X-Mercurial-Node: 94a17182f386c8bb414eba55dddf763b8982c76d
Message-ID: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 30 Nov 2011 20:58:37 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322686267 0
# Node ID 94a17182f386c8bb414eba55dddf763b8982c76d
# Parent  3c4c29899d8a2a0c0f9109b7236da95bb72b77b6
Add code to track the address of the VM generation id buffer across a
save/restore or migrate and inject a new value.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Nov 30 20:51:07 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  uint64_t gid)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Nov 30 20:51:07 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_gid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/xc_domain_restore.c	Wed Nov 30 20:51:07 2011 +0000
@@ -676,6 +676,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1386,6 +1399,33 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                unsigned int offset;
+                unsigned char *buf;
+
+                /*
+                 * Map the VM generation id buffer and inject the new value.
+                 */
+
+                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+            
+                if ( (pfn >= dinfo->p2m_size) ||
+                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                {
+                    ERROR("generation id buffer frame is bad");
+                    goto out;
+                }
+
+                mfn = ctx->p2m[pfn];
+                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                           PROT_READ | PROT_WRITE, mfn);
+                *(unsigned long long *)(buf + offset) = gid;
+                munmap(buf, PAGE_SIZE);
+
+                *vm_gid_addr = pagebuf.vm_gid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/xc_domain_save.c	Wed Nov 30 20:51:07 2011 +0000
@@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_gid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/xenguest.h	Wed Nov 30 20:51:07 2011 +0000
@@ -57,7 +57,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr);
 
 
 /**
@@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
+ * @parm vm_gid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid, unsigned long *vm_gid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/xg_save_restore.h	Wed Nov 30 20:51:07 2011 +0000
@@ -135,6 +135,7 @@
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxl_create.c	Wed Nov 30 20:51:07 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.generation_id = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -191,13 +192,15 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 7, sizeof(char *));
+        localents = libxl__calloc(gc, 9, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
         localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
         localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[6] = "platform/generation_id";
+        localents[7] = libxl__sprintf(gc, "0x%llx", info->u.hvm.generation_id);
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxl_dom.c	Wed Nov 30 20:51:07 2011 +0000
@@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    uint64_t gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        gid = info->u.hvm.generation_id;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, gid, &state->vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_gid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_gid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxl_internal.h	Wed Nov 30 20:51:07 2011 +0000
@@ -199,6 +199,8 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+
+    unsigned long vm_gid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxl_types.idl	Wed Nov 30 20:51:07 2011 +0000
@@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("generation_id", uint64),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxlu_cfg.c	Wed Nov 30 20:51:07 2011 +0000
@@ -235,6 +235,37 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
+                          long long *value_r, int dont_warn) {
+    long long ll;
+    XLU_ConfigSetting *set;
+    int e;
+    char *ep;
+
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
+    errno= 0; ll= strtoll(set->values[0], &ep, 0);
+    e= errno;
+    if (errno) {
+        e= errno;
+        assert(e==EINVAL || e==ERANGE);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' could not be parsed"
+                    " as a number: %s\n",
+                    cfg->filename, set->lineno, n, strerror(e));
+        return e;
+    }
+    if (*ep || ep==set->values[0]) {
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is not a valid number\n",
+                    cfg->filename, set->lineno, n);
+        return EINVAL;
+    }
+    *value_r= ll;
+    return 0;
+}
+
 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxlutil.h	Wed Nov 30 20:51:07 2011 +0000
@@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
                            char **value_r, int dont_warn);
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
                      int dont_warn);
+int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long long *value_r,
+                          int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Wed Nov 30 20:51:07 2011 +0000
@@ -573,6 +573,7 @@ static void parse_config_data(const char
 {
     const char *buf;
     long l;
+    long long ll;
     XLU_Config *config;
     XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
@@ -764,6 +765,8 @@ static void parse_config_data(const char
             b_info->u.hvm.timer_mode = l;
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long_long (config, "generation_id", &ll, 0))
+            b_info->u.hvm.nested_hvm = ll;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
diff -r 3c4c29899d8a -r 94a17182f386 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Nov 30 20:51:07 2011 +0000
@@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_gid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_gid_addr = 0;
     }
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/xcutils/xc_restore.c	Wed Nov 30 20:51:07 2011 +0000
@@ -23,7 +23,8 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_gid_addr;
+    uint64_t gid;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    gid = strtoll(argv[9], NULL, 0);
+    else
+	    gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            gid, &vm_gid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_gid_addr);
 	fflush(stdout);
     }
 
diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/xcutils/xc_save.c	Wed Nov 30 20:51:07 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_gid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 21:00:15 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 21:00:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVrFn-0004fe-Ou; Wed, 30 Nov 2011 20:59:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1RVrFl-0004fW-PY
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 20:59:42 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1322686741!157575!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcwNTU=\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7234 invoked from network); 30 Nov 2011 20:59:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 20:59:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,273,1320642000"; d="scan'208";a="172432792"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 15:59:00 -0500
Received: from cosworth.uk.xensource.com (10.80.16.52) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 30 Nov 2011 15:59:00 -0500
MIME-Version: 1.0
X-Mercurial-Node: 94a17182f386c8bb414eba55dddf763b8982c76d
Message-ID: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 30 Nov 2011 20:58:37 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Add code to track the address of the VM
 generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Paul Durrant <paul.durrant@citrix.com>
# Date 1322686267 0
# Node ID 94a17182f386c8bb414eba55dddf763b8982c76d
# Parent  3c4c29899d8a2a0c0f9109b7236da95bb72b77b6
Add code to track the address of the VM generation id buffer across a
save/restore or migrate and inject a new value.
The address of the buffer is written into xenstore by hvmloader at
boot time. It must be read from xenstore by the caller of
xc_domain_save() and then written back again by the caller of
xc_domain_restore().

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Nov 30 20:51:07 2011 +0000
@@ -548,7 +548,8 @@ int
 xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                   unsigned int store_evtchn, unsigned long *store_mfn,
                   unsigned int console_evtchn, unsigned long *console_mfn,
-                  unsigned int hvm, unsigned int pae, int superpages)
+                  unsigned int hvm, unsigned int pae, int superpages,
+                  uint64_t gid)
 {
     DECLARE_DOMCTL;
     int rc = 1;
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Nov 30 20:51:07 2011 +0000
@@ -382,7 +382,8 @@ out:
 int
 xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                uint32_t max_factor, uint32_t flags,
-               struct save_callbacks* callbacks, int hvm)
+               struct save_callbacks* callbacks, int hvm,
+               unsigned long vm_gid_addr)
 {
     DECLARE_DOMCTL;
     xc_dominfo_t info;
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/xc_domain_restore.c	Wed Nov 30 20:51:07 2011 +0000
@@ -676,6 +676,7 @@ typedef struct {
     uint64_t console_pfn;
     uint64_t acpi_ioport_location;
     uint64_t viridian;
+    uint64_t vm_gid_addr;
 } pagebuf_t;
 
 static int pagebuf_init(pagebuf_t* buf)
@@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface 
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
+        /* Skip padding 4 bytes then read the generation id buffer location. */
+        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
+             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
+        {
+            PERROR("error read the generation id buffer location");
+            return -1;
+        }
+        DPRINTF("read generation id buffer address");
+        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
             ERROR("Max batch size exceeded (%d). Giving up.", count);
@@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages)
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid, unsigned long *vm_gid_addr)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1386,6 +1399,33 @@ int xc_domain_restore(xc_interface *xch,
                 xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
             if ( pagebuf.console_pfn )
                 console_pfn = pagebuf.console_pfn;
+            if ( pagebuf.vm_gid_addr ) {
+                unsigned int offset;
+                unsigned char *buf;
+
+                /*
+                 * Map the VM generation id buffer and inject the new value.
+                 */
+
+                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
+                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
+            
+                if ( (pfn >= dinfo->p2m_size) ||
+                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
+                {
+                    ERROR("generation id buffer frame is bad");
+                    goto out;
+                }
+
+                mfn = ctx->p2m[pfn];
+                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
+                                           PROT_READ | PROT_WRITE, mfn);
+                *(unsigned long long *)(buf + offset) = gid;
+                munmap(buf, PAGE_SIZE);
+
+                *vm_gid_addr = pagebuf.vm_gid_addr;
+            }
+
             break;  /* our work here is done */
         }
 
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/xc_domain_save.c	Wed Nov 30 20:51:07 2011 +0000
@@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
 
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags,
-                   struct save_callbacks* callbacks, int hvm)
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr)
 {
     xc_dominfo_t info;
     DECLARE_DOMCTL;
@@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
             uint64_t data;
         } chunk = { 0, };
 
+        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
+        chunk.data = vm_gid_addr;
+
+        if ( (chunk.data != 0) &&
+             wrexact(io_fd, &chunk, sizeof(chunk)) )
+        {
+            PERROR("Error when writing the generation id buffer location for guest");
+            goto out;
+        }
+
         chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
         chunk.data = 0;
         xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/xenguest.h	Wed Nov 30 20:51:07 2011 +0000
@@ -57,7 +57,8 @@ struct save_callbacks {
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
                    uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
-                   struct save_callbacks* callbacks, int hvm);
+                   struct save_callbacks* callbacks, int hvm,
+                   unsigned long vm_gid_addr);
 
 
 /**
@@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
+ * @parm gid the new generation id of the VM
+ * @parm vm_gid_addr returned with the address of the generation id buffer
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int store_evtchn, unsigned long *store_mfn,
                       unsigned int console_evtchn, unsigned long *console_mfn,
-                      unsigned int hvm, unsigned int pae, int superpages);
+                      unsigned int hvm, unsigned int pae, int superpages,
+                      uint64_t gid, unsigned long *vm_gid_addr);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xg_save_restore.h
--- a/tools/libxc/xg_save_restore.h	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxc/xg_save_restore.h	Wed Nov 30 20:51:07 2011 +0000
@@ -135,6 +135,7 @@
 #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
 #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
 #define XC_SAVE_ID_HVM_VIRIDIAN       -11
+#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxl_create.c	Wed Nov 30 20:51:07 2011 +0000
@@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
+        b_info->u.hvm.generation_id = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -191,13 +192,15 @@ int libxl__domain_build(libxl__gc *gc,
         vments[4] = "start_time";
         vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
 
-        localents = libxl__calloc(gc, 7, sizeof(char *));
+        localents = libxl__calloc(gc, 9, sizeof(char *));
         localents[0] = "platform/acpi";
         localents[1] = (info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
         localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
         localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[6] = "platform/generation_id";
+        localents[7] = libxl__sprintf(gc, "0x%llx", info->u.hvm.generation_id);
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxl_dom.c	Wed Nov 30 20:51:07 2011 +0000
@@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
     if (info->cpuid != NULL)
         libxl_cpuid_set(ctx, domid, info->cpuid);
 
-    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
+    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
     ents[0] = "memory/static-max";
     ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
     ents[2] = "memory/target";
@@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
     ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
     ents[10] = "store/ring-ref";
     ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
+    ents[12] = "data/generation-id";
+    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
     for (i = 0; i < info->max_vcpus; i++) {
-        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
-        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
+        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
+        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
                             ? "offline" : "online";
     }
 
@@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    uint64_t gid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        gid = info->u.hvm.generation_id;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
         superpages = 0;
         pae = 1;
+        gid = 0;
         break;
     default:
         return ERROR_INVAL;
@@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages);
+                           hvm, pae, superpages, gid, &state->vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
     struct save_callbacks callbacks;
     struct suspendinfo si;
     int hvm, rc = ERROR_FAIL;
+    unsigned long vm_gid_addr;
 
     switch (type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
+    case LIBXL_DOMAIN_TYPE_HVM: {
+        char *path;
+        char *addr;
+
+        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
+        addr = libxl__xs_read(gc, XBT_NULL, path);
+
+        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
         hvm = 1;
         break;
+    }
     case LIBXL_DOMAIN_TYPE_PV:
+        vm_gid_addr = 0;
         hvm = 0;
         break;
     default:
@@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
-    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
+    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
+                        hvm, vm_gid_addr);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
                          si.guest_responded ?
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxl_internal.h	Wed Nov 30 20:51:07 2011 +0000
@@ -199,6 +199,8 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+
+    unsigned long vm_gid_addr;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxl_types.idl	Wed Nov 30 20:51:07 2011 +0000
@@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("generation_id", uint64),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxlu_cfg.c	Wed Nov 30 20:51:07 2011 +0000
@@ -235,6 +235,37 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
+                          long long *value_r, int dont_warn) {
+    long long ll;
+    XLU_ConfigSetting *set;
+    int e;
+    char *ep;
+
+    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
+    errno= 0; ll= strtoll(set->values[0], &ep, 0);
+    e= errno;
+    if (errno) {
+        e= errno;
+        assert(e==EINVAL || e==ERANGE);
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' could not be parsed"
+                    " as a number: %s\n",
+                    cfg->filename, set->lineno, n, strerror(e));
+        return e;
+    }
+    if (*ep || ep==set->values[0]) {
+        if (!dont_warn)
+            fprintf(cfg->report,
+                    "%s:%d: warning: parameter `%s' is not a valid number\n",
+                    cfg->filename, set->lineno, n);
+        return EINVAL;
+    }
+    *value_r= ll;
+    return 0;
+}
+
 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/libxlutil.h	Wed Nov 30 20:51:07 2011 +0000
@@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
                            char **value_r, int dont_warn);
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
                      int dont_warn);
+int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long long *value_r,
+                          int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,
diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Wed Nov 30 20:51:07 2011 +0000
@@ -573,6 +573,7 @@ static void parse_config_data(const char
 {
     const char *buf;
     long l;
+    long long ll;
     XLU_Config *config;
     XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt = 0;
@@ -764,6 +765,8 @@ static void parse_config_data(const char
             b_info->u.hvm.timer_mode = l;
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
+        if (!xlu_cfg_get_long_long (config, "generation_id", &ll, 0))
+            b_info->u.hvm.nested_hvm = ll;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
diff -r 3c4c29899d8a -r 94a17182f386 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
--- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Nov 30 20:51:07 2011 +0000
@@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s
 {
     int hvm, rc;
     int flags = XCFLAGS_LIVE;
+    unsigned long vm_gid_addr;
 
     if (!s->domid) {
        s->errstr = "checkpoint state not opened";
@@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s
 
     hvm = s->domtype > dt_pv;
     if (hvm) {
+       char path[128];
+       char *addr;
+
+       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
+       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
+
+       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+       free(addr);
+
        flags |= XCFLAGS_HVM;
        if (switch_qemu_logdirty(s, 1))
            return -1;
+    } else {
+       vm_gid_addr = 0;
     }
 
     callbacks->switch_qemu_logdirty = noop_switch_logdirty;
 
-    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
+    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
 
     if (hvm)
        switch_qemu_logdirty(s, 0);
diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_restore.c
--- a/tools/xcutils/xc_restore.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/xcutils/xc_restore.c	Wed Nov 30 20:51:07 2011 +0000
@@ -23,7 +23,8 @@ main(int argc, char **argv)
     xc_interface *xch;
     int io_fd, ret;
     int superpages;
-    unsigned long store_mfn, console_mfn;
+    unsigned long store_mfn, console_mfn, vm_gid_addr;
+    uint64_t gid;
 
     if ( (argc != 8) && (argc != 9) )
         errx(1, "usage: %s iofd domid store_evtchn "
@@ -40,19 +41,25 @@ main(int argc, char **argv)
     hvm  = atoi(argv[5]);
     pae  = atoi(argv[6]);
     apic = atoi(argv[7]);
-    if ( argc == 9 )
+    if ( argc >= 9 )
 	    superpages = atoi(argv[8]);
     else
 	    superpages = !!hvm;
+    if ( argc >= 10 )
+	    gid = strtoll(argv[9], NULL, 0);
+    else
+	    gid = 0;
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages);
+                            console_evtchn, &console_mfn, hvm, pae, superpages,
+                            gid, &vm_gid_addr);
 
     if ( ret == 0 )
     {
 	printf("store-mfn %li\n", store_mfn);
         if ( !hvm )
             printf("console-mfn %li\n", console_mfn);
+	printf("vm-gid-addr %lx\n", vm_gid_addr);
 	fflush(stdout);
     }
 
diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_save.c
--- a/tools/xcutils/xc_save.c	Wed Nov 30 07:18:11 2011 -0800
+++ b/tools/xcutils/xc_save.c	Wed Nov 30 20:51:07 2011 +0000
@@ -169,6 +169,10 @@ main(int argc, char **argv)
     unsigned int maxit, max_f;
     int io_fd, ret, port;
     struct save_callbacks callbacks;
+    char path[128];
+    struct xs_handle *xs;
+    char *addr;
+    unsigned long vm_gid_addr;
 
     if (argc != 6)
         errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
@@ -207,8 +211,21 @@ main(int argc, char **argv)
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = suspend;
     callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
+
+    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
+
+    if ((xs = xs_daemon_open()) == NULL)
+        errx(1, "Couldn't contact xenstore");
+
+    addr = xs_read(xs, XBT_NULL, path, NULL);
+
+    xs_daemon_close(xs);
+
+    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
+    free(addr);
+
     ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
-                         &callbacks, !!(si.flags & XCFLAGS_HVM));
+                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
 
     if (si.suspend_evtchn > 0)
 	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:15:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVsQm-0005pJ-Am; Wed, 30 Nov 2011 22:15:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVsQk-0005pE-Gn
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 22:15:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322691264!5369250!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24290 invoked from network); 30 Nov 2011 22:14:26 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 22:14:26 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAUMEKKl016694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 17:14:20 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAUMEJ15016692;
	Wed, 30 Nov 2011 17:14:19 -0500
Date: Wed, 30 Nov 2011 18:14:19 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20111130221419.GA16651@andromeda.dapyr.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 08:58:37PM +0000, Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322686267 0
> # Node ID 94a17182f386c8bb414eba55dddf763b8982c76d
> # Parent  3c4c29899d8a2a0c0f9109b7236da95bb72b77b6
> Add code to track the address of the VM generation id buffer across a
> save/restore or migrate and inject a new value.

So what is a generation id? What is the use-case for this?

> The address of the buffer is written into xenstore by hvmloader at
> boot time. It must be read from xenstore by the caller of
> xc_domain_save() and then written back again by the caller of
> xc_domain_restore().
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/ia64/xc_ia64_linux_restore.c
> --- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -548,7 +548,8 @@ int
>  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                    unsigned int store_evtchn, unsigned long *store_mfn,
>                    unsigned int console_evtchn, unsigned long *console_mfn,
> -                  unsigned int hvm, unsigned int pae, int superpages)
> +                  unsigned int hvm, unsigned int pae, int superpages,
> +                  uint64_t gid)
>  {
>      DECLARE_DOMCTL;
>      int rc = 1;
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/ia64/xc_ia64_linux_save.c
> --- a/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -382,7 +382,8 @@ out:
>  int
>  xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
>                 uint32_t max_factor, uint32_t flags,
> -               struct save_callbacks* callbacks, int hvm)
> +               struct save_callbacks* callbacks, int hvm,
> +               unsigned long vm_gid_addr)
>  {
>      DECLARE_DOMCTL;
>      xc_dominfo_t info;
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/xc_domain_restore.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -676,6 +676,7 @@ typedef struct {
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
>      uint64_t viridian;
> +    uint64_t vm_gid_addr;
>  } pagebuf_t;
>  
>  static int pagebuf_init(pagebuf_t* buf)
> @@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface 
>          }
>          return pagebuf_get_one(xch, ctx, buf, fd, dom);
>  
> +    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
> +        /* Skip padding 4 bytes then read the generation id buffer location. */
> +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the generation id buffer location");
> +            return -1;
> +        }
> +        DPRINTF("read generation id buffer address");
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.", count);
> @@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                        unsigned int store_evtchn, unsigned long *store_mfn,
>                        unsigned int console_evtchn, unsigned long *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int superpages)
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      uint64_t gid, unsigned long *vm_gid_addr)
>  {
>      DECLARE_DOMCTL;
>      int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> @@ -1386,6 +1399,33 @@ int xc_domain_restore(xc_interface *xch,
>                  xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
>              if ( pagebuf.console_pfn )
>                  console_pfn = pagebuf.console_pfn;
> +            if ( pagebuf.vm_gid_addr ) {
> +                unsigned int offset;
> +                unsigned char *buf;
> +
> +                /*
> +                 * Map the VM generation id buffer and inject the new value.
> +                 */
> +
> +                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
> +                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
> +            
> +                if ( (pfn >= dinfo->p2m_size) ||
> +                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
> +                {
> +                    ERROR("generation id buffer frame is bad");
> +                    goto out;
> +                }
> +
> +                mfn = ctx->p2m[pfn];
> +                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
> +                                           PROT_READ | PROT_WRITE, mfn);
> +                *(unsigned long long *)(buf + offset) = gid;
> +                munmap(buf, PAGE_SIZE);
> +
> +                *vm_gid_addr = pagebuf.vm_gid_addr;
> +            }
> +
>              break;  /* our work here is done */
>          }
>  
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/xc_domain_save.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
>  
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
>                     uint32_t max_factor, uint32_t flags,
> -                   struct save_callbacks* callbacks, int hvm)
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr)
>  {
>      xc_dominfo_t info;
>      DECLARE_DOMCTL;
> @@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
>              uint64_t data;
>          } chunk = { 0, };
>  
> +        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
> +        chunk.data = vm_gid_addr;
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the generation id buffer location for guest");
> +            goto out;
> +        }
> +
>          chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
>          chunk.data = 0;
>          xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xenguest.h
> --- a/tools/libxc/xenguest.h	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/xenguest.h	Wed Nov 30 20:51:07 2011 +0000
> @@ -57,7 +57,8 @@ struct save_callbacks {
>   */
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
>                     uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
> -                   struct save_callbacks* callbacks, int hvm);
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr);
>  
>  
>  /**
> @@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
>   * @parm hvm non-zero if this is a HVM restore
>   * @parm pae non-zero if this HVM domain has PAE support enabled
>   * @parm superpages non-zero to allocate guest memory with superpages
> + * @parm gid the new generation id of the VM
> + * @parm vm_gid_addr returned with the address of the generation id buffer
>   * @return 0 on success, -1 on failure
>   */
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                        unsigned int store_evtchn, unsigned long *store_mfn,
>                        unsigned int console_evtchn, unsigned long *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int superpages);
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      uint64_t gid, unsigned long *vm_gid_addr);
>  /**
>   * xc_domain_restore writes a file to disk that contains the device
>   * model saved state.
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/xg_save_restore.h	Wed Nov 30 20:51:07 2011 +0000
> @@ -135,6 +135,7 @@
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
>  #define XC_SAVE_ID_HVM_VIRIDIAN       -11
> +#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
>  
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_create.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
>          b_info->u.hvm.vpt_align = 1;
>          b_info->u.hvm.timer_mode = 1;
>          b_info->u.hvm.nested_hvm = 0;
> +        b_info->u.hvm.generation_id = 0;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          b_info->u.pv.slack_memkb = 8 * 1024;
> @@ -191,13 +192,15 @@ int libxl__domain_build(libxl__gc *gc,
>          vments[4] = "start_time";
>          vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
>  
> -        localents = libxl__calloc(gc, 7, sizeof(char *));
> +        localents = libxl__calloc(gc, 9, sizeof(char *));
>          localents[0] = "platform/acpi";
>          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
>          localents[2] = "platform/acpi_s3";
>          localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
>          localents[4] = "platform/acpi_s4";
>          localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
> +        localents[6] = "platform/generation_id";
> +        localents[7] = libxl__sprintf(gc, "0x%llx", info->u.hvm.generation_id);
>  
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_dom.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
>      if (info->cpuid != NULL)
>          libxl_cpuid_set(ctx, domid, info->cpuid);
>  
> -    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
> +    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
>      ents[0] = "memory/static-max";
>      ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
>      ents[2] = "memory/target";
> @@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
>      ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
>      ents[10] = "store/ring-ref";
>      ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
> +    ents[12] = "data/generation-id";
> +    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
>      for (i = 0; i < info->max_vcpus; i++) {
> -        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
> -        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
> +        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
> +        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
>                              ? "offline" : "online";
>      }
>  
> @@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
>      /* read signature */
>      int rc;
>      int hvm, pae, superpages;
> +    uint64_t gid;
>      switch (info->type) {
>      case LIBXL_DOMAIN_TYPE_HVM:
>          hvm = 1;
>          superpages = 1;
>          pae = info->u.hvm.pae;
> +        gid = info->u.hvm.generation_id;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          hvm = 0;
>          superpages = 0;
>          pae = 1;
> +        gid = 0;
>          break;
>      default:
>          return ERROR_INVAL;
> @@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
>      rc = xc_domain_restore(ctx->xch, fd, domid,
>                             state->store_port, &state->store_mfn,
>                             state->console_port, &state->console_mfn,
> -                           hvm, pae, superpages);
> +                           hvm, pae, superpages, gid, &state->vm_gid_addr);
>      if ( rc ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
>          return ERROR_FAIL;
> @@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
>      struct save_callbacks callbacks;
>      struct suspendinfo si;
>      int hvm, rc = ERROR_FAIL;
> +    unsigned long vm_gid_addr;
>  
>      switch (type) {
> -    case LIBXL_DOMAIN_TYPE_HVM:
> +    case LIBXL_DOMAIN_TYPE_HVM: {
> +        char *path;
> +        char *addr;
> +
> +        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
> +        addr = libxl__xs_read(gc, XBT_NULL, path);
> +
> +        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
>          hvm = 1;
>          break;
> +    }
>      case LIBXL_DOMAIN_TYPE_PV:
> +        vm_gid_addr = 0;
>          hvm = 0;
>          break;
>      default:
> @@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
>      callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
>      callbacks.data = &si;
>  
> -    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
> +    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
> +                        hvm, vm_gid_addr);
>      if ( rc ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
>                           si.guest_responded ?
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_internal.h	Wed Nov 30 20:51:07 2011 +0000
> @@ -199,6 +199,8 @@ typedef struct {
>  
>      uint32_t console_port;
>      unsigned long console_mfn;
> +
> +    unsigned long vm_gid_addr;
>  } libxl__domain_build_state;
>  
>  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_types.idl	Wed Nov 30 20:51:07 2011 +0000
> @@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("vpt_align", bool),
>                                         ("timer_mode", integer),
>                                         ("nested_hvm", bool),
> +                                       ("generation_id", uint64),
>                                         ])),
>                   ("pv", Struct(None, [("kernel", libxl_file_reference),
>                                        ("slack_memkb", uint32),
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlu_cfg.c
> --- a/tools/libxl/libxlu_cfg.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxlu_cfg.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -235,6 +235,37 @@ int xlu_cfg_get_long(const XLU_Config *c
>      return 0;
>  }
>  
> +int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
> +                          long long *value_r, int dont_warn) {
> +    long long ll;
> +    XLU_ConfigSetting *set;
> +    int e;
> +    char *ep;
> +
> +    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
> +    errno= 0; ll= strtoll(set->values[0], &ep, 0);
> +    e= errno;
> +    if (errno) {
> +        e= errno;
> +        assert(e==EINVAL || e==ERANGE);
> +        if (!dont_warn)
> +            fprintf(cfg->report,
> +                    "%s:%d: warning: parameter `%s' could not be parsed"
> +                    " as a number: %s\n",
> +                    cfg->filename, set->lineno, n, strerror(e));
> +        return e;
> +    }
> +    if (*ep || ep==set->values[0]) {
> +        if (!dont_warn)
> +            fprintf(cfg->report,
> +                    "%s:%d: warning: parameter `%s' is not a valid number\n",
> +                    cfg->filename, set->lineno, n);
> +        return EINVAL;
> +    }
> +    *value_r= ll;
> +    return 0;
> +}
> +
>  
>  int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
>                       XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlutil.h
> --- a/tools/libxl/libxlutil.h	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxlutil.h	Wed Nov 30 20:51:07 2011 +0000
> @@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
>                             char **value_r, int dont_warn);
>  int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
>                       int dont_warn);
> +int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long long *value_r,
> +                          int dont_warn);
>  
>  int xlu_cfg_get_list(const XLU_Config*, const char *n,
>                       XLU_ConfigList **list_r /* may be 0 */,
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -573,6 +573,7 @@ static void parse_config_data(const char
>  {
>      const char *buf;
>      long l;
> +    long long ll;
>      XLU_Config *config;
>      XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
>      int pci_power_mgmt = 0;
> @@ -764,6 +765,8 @@ static void parse_config_data(const char
>              b_info->u.hvm.timer_mode = l;
>          if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
>              b_info->u.hvm.nested_hvm = l;
> +        if (!xlu_cfg_get_long_long (config, "generation_id", &ll, 0))
> +            b_info->u.hvm.nested_hvm = ll;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>      {
> diff -r 3c4c29899d8a -r 94a17182f386 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s
>  {
>      int hvm, rc;
>      int flags = XCFLAGS_LIVE;
> +    unsigned long vm_gid_addr;
>  
>      if (!s->domid) {
>         s->errstr = "checkpoint state not opened";
> @@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s
>  
>      hvm = s->domtype > dt_pv;
>      if (hvm) {
> +       char path[128];
> +       char *addr;
> +
> +       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
> +       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
> +
> +       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +       free(addr);
> +
>         flags |= XCFLAGS_HVM;
>         if (switch_qemu_logdirty(s, 1))
>             return -1;
> +    } else {
> +       vm_gid_addr = 0;
>      }
>  
>      callbacks->switch_qemu_logdirty = noop_switch_logdirty;
>  
> -    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
> +    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
>  
>      if (hvm)
>         switch_qemu_logdirty(s, 0);
> diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/xcutils/xc_restore.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>      xc_interface *xch;
>      int io_fd, ret;
>      int superpages;
> -    unsigned long store_mfn, console_mfn;
> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> +    uint64_t gid;
>  
>      if ( (argc != 8) && (argc != 9) )
>          errx(1, "usage: %s iofd domid store_evtchn "
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>      hvm  = atoi(argv[5]);
>      pae  = atoi(argv[6]);
>      apic = atoi(argv[7]);
> -    if ( argc == 9 )
> +    if ( argc >= 9 )
>  	    superpages = atoi(argv[8]);
>      else
>  	    superpages = !!hvm;
> +    if ( argc >= 10 )
> +	    gid = strtoll(argv[9], NULL, 0);
> +    else
> +	    gid = 0;
>  
>      ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
> -                            console_evtchn, &console_mfn, hvm, pae, superpages);
> +                            console_evtchn, &console_mfn, hvm, pae, superpages,
> +                            gid, &vm_gid_addr);
>  
>      if ( ret == 0 )
>      {
>  	printf("store-mfn %li\n", store_mfn);
>          if ( !hvm )
>              printf("console-mfn %li\n", console_mfn);
> +	printf("vm-gid-addr %lx\n", vm_gid_addr);
>  	fflush(stdout);
>      }
>  
> diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_save.c
> --- a/tools/xcutils/xc_save.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/xcutils/xc_save.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -169,6 +169,10 @@ main(int argc, char **argv)
>      unsigned int maxit, max_f;
>      int io_fd, ret, port;
>      struct save_callbacks callbacks;
> +    char path[128];
> +    struct xs_handle *xs;
> +    char *addr;
> +    unsigned long vm_gid_addr;
>  
>      if (argc != 6)
>          errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
> @@ -207,8 +211,21 @@ main(int argc, char **argv)
>      memset(&callbacks, 0, sizeof(callbacks));
>      callbacks.suspend = suspend;
>      callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
> +
> +    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
> +
> +    if ((xs = xs_daemon_open()) == NULL)
> +        errx(1, "Couldn't contact xenstore");
> +
> +    addr = xs_read(xs, XBT_NULL, path, NULL);
> +
> +    xs_daemon_close(xs);
> +
> +    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +    free(addr);
> +
>      ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
> -                         &callbacks, !!(si.flags & XCFLAGS_HVM));
> +                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
>  
>      if (si.suspend_evtchn > 0)
>  	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:15:52 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVsQm-0005pJ-Am; Wed, 30 Nov 2011 22:15:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVsQk-0005pE-Gn
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 22:15:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322691264!5369250!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24290 invoked from network); 30 Nov 2011 22:14:26 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 22:14:26 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAUMEKKl016694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 17:14:20 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAUMEJ15016692;
	Wed, 30 Nov 2011 17:14:19 -0500
Date: Wed, 30 Nov 2011 18:14:19 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20111130221419.GA16651@andromeda.dapyr.net>
References: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <94a17182f386c8bb414e.1322686717@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add code to track the address of the VM
	generation id buffer across a
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 08:58:37PM +0000, Paul Durrant wrote:
> # HG changeset patch
> # User Paul Durrant <paul.durrant@citrix.com>
> # Date 1322686267 0
> # Node ID 94a17182f386c8bb414eba55dddf763b8982c76d
> # Parent  3c4c29899d8a2a0c0f9109b7236da95bb72b77b6
> Add code to track the address of the VM generation id buffer across a
> save/restore or migrate and inject a new value.

So what is a generation id? What is the use-case for this?

> The address of the buffer is written into xenstore by hvmloader at
> boot time. It must be read from xenstore by the caller of
> xc_domain_save() and then written back again by the caller of
> xc_domain_restore().
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/ia64/xc_ia64_linux_restore.c
> --- a/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -548,7 +548,8 @@ int
>  xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                    unsigned int store_evtchn, unsigned long *store_mfn,
>                    unsigned int console_evtchn, unsigned long *console_mfn,
> -                  unsigned int hvm, unsigned int pae, int superpages)
> +                  unsigned int hvm, unsigned int pae, int superpages,
> +                  uint64_t gid)
>  {
>      DECLARE_DOMCTL;
>      int rc = 1;
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/ia64/xc_ia64_linux_save.c
> --- a/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/ia64/xc_ia64_linux_save.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -382,7 +382,8 @@ out:
>  int
>  xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
>                 uint32_t max_factor, uint32_t flags,
> -               struct save_callbacks* callbacks, int hvm)
> +               struct save_callbacks* callbacks, int hvm,
> +               unsigned long vm_gid_addr)
>  {
>      DECLARE_DOMCTL;
>      xc_dominfo_t info;
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_restore.c
> --- a/tools/libxc/xc_domain_restore.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/xc_domain_restore.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -676,6 +676,7 @@ typedef struct {
>      uint64_t console_pfn;
>      uint64_t acpi_ioport_location;
>      uint64_t viridian;
> +    uint64_t vm_gid_addr;
>  } pagebuf_t;
>  
>  static int pagebuf_init(pagebuf_t* buf)
> @@ -820,6 +821,17 @@ static int pagebuf_get_one(xc_interface 
>          }
>          return pagebuf_get_one(xch, ctx, buf, fd, dom);
>  
> +    case XC_SAVE_ID_HVM_GENERATION_ID_ADDR:
> +        /* Skip padding 4 bytes then read the generation id buffer location. */
> +        if ( RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint32_t)) ||
> +             RDEXACT(fd, &buf->vm_gid_addr, sizeof(uint64_t)) )
> +        {
> +            PERROR("error read the generation id buffer location");
> +            return -1;
> +        }
> +        DPRINTF("read generation id buffer address");
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +
>      default:
>          if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
>              ERROR("Max batch size exceeded (%d). Giving up.", count);
> @@ -1186,7 +1198,8 @@ static int apply_batch(xc_interface *xch
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                        unsigned int store_evtchn, unsigned long *store_mfn,
>                        unsigned int console_evtchn, unsigned long *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int superpages)
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      uint64_t gid, unsigned long *vm_gid_addr)
>  {
>      DECLARE_DOMCTL;
>      int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> @@ -1386,6 +1399,33 @@ int xc_domain_restore(xc_interface *xch,
>                  xc_set_hvm_param(xch, dom, HVM_PARAM_VM86_TSS, pagebuf.vm86_tss);
>              if ( pagebuf.console_pfn )
>                  console_pfn = pagebuf.console_pfn;
> +            if ( pagebuf.vm_gid_addr ) {
> +                unsigned int offset;
> +                unsigned char *buf;
> +
> +                /*
> +                 * Map the VM generation id buffer and inject the new value.
> +                 */
> +
> +                pfn = pagebuf.vm_gid_addr >> PAGE_SHIFT;
> +                offset = pagebuf.vm_gid_addr & (PAGE_SIZE - 1);
> +            
> +                if ( (pfn >= dinfo->p2m_size) ||
> +                     (pfn_type[pfn] != XEN_DOMCTL_PFINFO_NOTAB) )
> +                {
> +                    ERROR("generation id buffer frame is bad");
> +                    goto out;
> +                }
> +
> +                mfn = ctx->p2m[pfn];
> +                buf = xc_map_foreign_range(xch, dom, PAGE_SIZE,
> +                                           PROT_READ | PROT_WRITE, mfn);
> +                *(unsigned long long *)(buf + offset) = gid;
> +                munmap(buf, PAGE_SIZE);
> +
> +                *vm_gid_addr = pagebuf.vm_gid_addr;
> +            }
> +
>              break;  /* our work here is done */
>          }
>  
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/xc_domain_save.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -754,7 +754,8 @@ static int save_tsc_info(xc_interface *x
>  
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
>                     uint32_t max_factor, uint32_t flags,
> -                   struct save_callbacks* callbacks, int hvm)
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr)
>  {
>      xc_dominfo_t info;
>      DECLARE_DOMCTL;
> @@ -1460,6 +1461,16 @@ int xc_domain_save(xc_interface *xch, in
>              uint64_t data;
>          } chunk = { 0, };
>  
> +        chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
> +        chunk.data = vm_gid_addr;
> +
> +        if ( (chunk.data != 0) &&
> +             wrexact(io_fd, &chunk, sizeof(chunk)) )
> +        {
> +            PERROR("Error when writing the generation id buffer location for guest");
> +            goto out;
> +        }
> +
>          chunk.id = XC_SAVE_ID_HVM_IDENT_PT;
>          chunk.data = 0;
>          xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xenguest.h
> --- a/tools/libxc/xenguest.h	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/xenguest.h	Wed Nov 30 20:51:07 2011 +0000
> @@ -57,7 +57,8 @@ struct save_callbacks {
>   */
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iters,
>                     uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
> -                   struct save_callbacks* callbacks, int hvm);
> +                   struct save_callbacks* callbacks, int hvm,
> +                   unsigned long vm_gid_addr);
>  
>  
>  /**
> @@ -71,12 +72,15 @@ int xc_domain_save(xc_interface *xch, in
>   * @parm hvm non-zero if this is a HVM restore
>   * @parm pae non-zero if this HVM domain has PAE support enabled
>   * @parm superpages non-zero to allocate guest memory with superpages
> + * @parm gid the new generation id of the VM
> + * @parm vm_gid_addr returned with the address of the generation id buffer
>   * @return 0 on success, -1 on failure
>   */
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>                        unsigned int store_evtchn, unsigned long *store_mfn,
>                        unsigned int console_evtchn, unsigned long *console_mfn,
> -                      unsigned int hvm, unsigned int pae, int superpages);
> +                      unsigned int hvm, unsigned int pae, int superpages,
> +                      uint64_t gid, unsigned long *vm_gid_addr);
>  /**
>   * xc_domain_restore writes a file to disk that contains the device
>   * model saved state.
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxc/xg_save_restore.h
> --- a/tools/libxc/xg_save_restore.h	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxc/xg_save_restore.h	Wed Nov 30 20:51:07 2011 +0000
> @@ -135,6 +135,7 @@
>  #define XC_SAVE_ID_LAST_CHECKPOINT    -9 /* Commit to restoring after completion of current iteration. */
>  #define XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION -10
>  #define XC_SAVE_ID_HVM_VIRIDIAN       -11
> +#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -12
>  
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_create.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -101,6 +101,7 @@ int libxl_init_build_info(libxl_ctx *ctx
>          b_info->u.hvm.vpt_align = 1;
>          b_info->u.hvm.timer_mode = 1;
>          b_info->u.hvm.nested_hvm = 0;
> +        b_info->u.hvm.generation_id = 0;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          b_info->u.pv.slack_memkb = 8 * 1024;
> @@ -191,13 +192,15 @@ int libxl__domain_build(libxl__gc *gc,
>          vments[4] = "start_time";
>          vments[5] = libxl__sprintf(gc, "%lu.%02d", start_time.tv_sec,(int)start_time.tv_usec/10000);
>  
> -        localents = libxl__calloc(gc, 7, sizeof(char *));
> +        localents = libxl__calloc(gc, 9, sizeof(char *));
>          localents[0] = "platform/acpi";
>          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
>          localents[2] = "platform/acpi_s3";
>          localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
>          localents[4] = "platform/acpi_s4";
>          localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
> +        localents[6] = "platform/generation_id";
> +        localents[7] = libxl__sprintf(gc, "0x%llx", info->u.hvm.generation_id);
>  
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_dom.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -125,7 +125,7 @@ int libxl__build_post(libxl__gc *gc, uin
>      if (info->cpuid != NULL)
>          libxl_cpuid_set(ctx, domid, info->cpuid);
>  
> -    ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *));
> +    ents = libxl__calloc(gc, 14 + (info->max_vcpus * 2) + 2, sizeof(char *));
>      ents[0] = "memory/static-max";
>      ents[1] = libxl__sprintf(gc, "%d", info->max_memkb);
>      ents[2] = "memory/target";
> @@ -138,9 +138,11 @@ int libxl__build_post(libxl__gc *gc, uin
>      ents[9] = libxl__sprintf(gc, "%"PRIu32, state->store_port);
>      ents[10] = "store/ring-ref";
>      ents[11] = libxl__sprintf(gc, "%lu", state->store_mfn);
> +    ents[12] = "data/generation-id";
> +    ents[13] = libxl__sprintf(gc, "0x%lx", state->vm_gid_addr);
>      for (i = 0; i < info->max_vcpus; i++) {
> -        ents[12+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
> -        ents[12+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
> +        ents[14+(i*2)]   = libxl__sprintf(gc, "cpu/%d/availability", i);
> +        ents[14+(i*2)+1] = (i && info->cur_vcpus && !(info->cur_vcpus & (1 << i)))
>                              ? "offline" : "online";
>      }
>  
> @@ -357,16 +359,19 @@ int libxl__domain_restore_common(libxl__
>      /* read signature */
>      int rc;
>      int hvm, pae, superpages;
> +    uint64_t gid;
>      switch (info->type) {
>      case LIBXL_DOMAIN_TYPE_HVM:
>          hvm = 1;
>          superpages = 1;
>          pae = info->u.hvm.pae;
> +        gid = info->u.hvm.generation_id;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>          hvm = 0;
>          superpages = 0;
>          pae = 1;
> +        gid = 0;
>          break;
>      default:
>          return ERROR_INVAL;
> @@ -374,7 +379,7 @@ int libxl__domain_restore_common(libxl__
>      rc = xc_domain_restore(ctx->xch, fd, domid,
>                             state->store_port, &state->store_mfn,
>                             state->console_port, &state->console_mfn,
> -                           hvm, pae, superpages);
> +                           hvm, pae, superpages, gid, &state->vm_gid_addr);
>      if ( rc ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
>          return ERROR_FAIL;
> @@ -540,12 +545,22 @@ int libxl__domain_suspend_common(libxl__
>      struct save_callbacks callbacks;
>      struct suspendinfo si;
>      int hvm, rc = ERROR_FAIL;
> +    unsigned long vm_gid_addr;
>  
>      switch (type) {
> -    case LIBXL_DOMAIN_TYPE_HVM:
> +    case LIBXL_DOMAIN_TYPE_HVM: {
> +        char *path;
> +        char *addr;
> +
> +        path = libxl__sprintf(gc, "%s/data/generation-id", libxl__xs_get_dompath(gc, domid));
> +        addr = libxl__xs_read(gc, XBT_NULL, path);
> +
> +        vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
>          hvm = 1;
>          break;
> +    }
>      case LIBXL_DOMAIN_TYPE_PV:
> +        vm_gid_addr = 0;
>          hvm = 0;
>          break;
>      default:
> @@ -583,7 +598,8 @@ int libxl__domain_suspend_common(libxl__
>      callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
>      callbacks.data = &si;
>  
> -    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
> +    rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
> +                        hvm, vm_gid_addr);
>      if ( rc ) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s",
>                           si.guest_responded ?
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_internal.h	Wed Nov 30 20:51:07 2011 +0000
> @@ -199,6 +199,8 @@ typedef struct {
>  
>      uint32_t console_port;
>      unsigned long console_mfn;
> +
> +    unsigned long vm_gid_addr;
>  } libxl__domain_build_state;
>  
>  _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxl_types.idl	Wed Nov 30 20:51:07 2011 +0000
> @@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain
>                                         ("vpt_align", bool),
>                                         ("timer_mode", integer),
>                                         ("nested_hvm", bool),
> +                                       ("generation_id", uint64),
>                                         ])),
>                   ("pv", Struct(None, [("kernel", libxl_file_reference),
>                                        ("slack_memkb", uint32),
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlu_cfg.c
> --- a/tools/libxl/libxlu_cfg.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxlu_cfg.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -235,6 +235,37 @@ int xlu_cfg_get_long(const XLU_Config *c
>      return 0;
>  }
>  
> +int xlu_cfg_get_long_long(const XLU_Config *cfg, const char *n,
> +                          long long *value_r, int dont_warn) {
> +    long long ll;
> +    XLU_ConfigSetting *set;
> +    int e;
> +    char *ep;
> +
> +    e= find_atom(cfg,n,&set,dont_warn);  if (e) return e;
> +    errno= 0; ll= strtoll(set->values[0], &ep, 0);
> +    e= errno;
> +    if (errno) {
> +        e= errno;
> +        assert(e==EINVAL || e==ERANGE);
> +        if (!dont_warn)
> +            fprintf(cfg->report,
> +                    "%s:%d: warning: parameter `%s' could not be parsed"
> +                    " as a number: %s\n",
> +                    cfg->filename, set->lineno, n, strerror(e));
> +        return e;
> +    }
> +    if (*ep || ep==set->values[0]) {
> +        if (!dont_warn)
> +            fprintf(cfg->report,
> +                    "%s:%d: warning: parameter `%s' is not a valid number\n",
> +                    cfg->filename, set->lineno, n);
> +        return EINVAL;
> +    }
> +    *value_r= ll;
> +    return 0;
> +}
> +
>  
>  int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
>                       XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxlutil.h
> --- a/tools/libxl/libxlutil.h	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/libxlutil.h	Wed Nov 30 20:51:07 2011 +0000
> @@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
>                             char **value_r, int dont_warn);
>  int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
>                       int dont_warn);
> +int xlu_cfg_get_long_long(const XLU_Config*, const char *n, long long *value_r,
> +                          int dont_warn);
>  
>  int xlu_cfg_get_list(const XLU_Config*, const char *n,
>                       XLU_ConfigList **list_r /* may be 0 */,
> diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -573,6 +573,7 @@ static void parse_config_data(const char
>  {
>      const char *buf;
>      long l;
> +    long long ll;
>      XLU_Config *config;
>      XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
>      int pci_power_mgmt = 0;
> @@ -764,6 +765,8 @@ static void parse_config_data(const char
>              b_info->u.hvm.timer_mode = l;
>          if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
>              b_info->u.hvm.nested_hvm = l;
> +        if (!xlu_cfg_get_long_long (config, "generation_id", &ll, 0))
> +            b_info->u.hvm.nested_hvm = ll;
>          break;
>      case LIBXL_DOMAIN_TYPE_PV:
>      {
> diff -r 3c4c29899d8a -r 94a17182f386 tools/python/xen/lowlevel/checkpoint/libcheckpoint.c
> --- a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -174,6 +174,7 @@ int checkpoint_start(checkpoint_state* s
>  {
>      int hvm, rc;
>      int flags = XCFLAGS_LIVE;
> +    unsigned long vm_gid_addr;
>  
>      if (!s->domid) {
>         s->errstr = "checkpoint state not opened";
> @@ -184,14 +185,25 @@ int checkpoint_start(checkpoint_state* s
>  
>      hvm = s->domtype > dt_pv;
>      if (hvm) {
> +       char path[128];
> +       char *addr;
> +
> +       sprintf(path, "/local/domain/%u/data/generation-id", s->domid);
> +       addr = xs_read(s->xsh, XBT_NULL, path, NULL);
> +
> +       vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +       free(addr);
> +
>         flags |= XCFLAGS_HVM;
>         if (switch_qemu_logdirty(s, 1))
>             return -1;
> +    } else {
> +       vm_gid_addr = 0;
>      }
>  
>      callbacks->switch_qemu_logdirty = noop_switch_logdirty;
>  
> -    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm);
> +    rc = xc_domain_save(s->xch, fd, s->domid, 0, 0, flags, callbacks, hvm, vm_gid_addr);
>  
>      if (hvm)
>         switch_qemu_logdirty(s, 0);
> diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_restore.c
> --- a/tools/xcutils/xc_restore.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/xcutils/xc_restore.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -23,7 +23,8 @@ main(int argc, char **argv)
>      xc_interface *xch;
>      int io_fd, ret;
>      int superpages;
> -    unsigned long store_mfn, console_mfn;
> +    unsigned long store_mfn, console_mfn, vm_gid_addr;
> +    uint64_t gid;
>  
>      if ( (argc != 8) && (argc != 9) )
>          errx(1, "usage: %s iofd domid store_evtchn "
> @@ -40,19 +41,25 @@ main(int argc, char **argv)
>      hvm  = atoi(argv[5]);
>      pae  = atoi(argv[6]);
>      apic = atoi(argv[7]);
> -    if ( argc == 9 )
> +    if ( argc >= 9 )
>  	    superpages = atoi(argv[8]);
>      else
>  	    superpages = !!hvm;
> +    if ( argc >= 10 )
> +	    gid = strtoll(argv[9], NULL, 0);
> +    else
> +	    gid = 0;
>  
>      ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
> -                            console_evtchn, &console_mfn, hvm, pae, superpages);
> +                            console_evtchn, &console_mfn, hvm, pae, superpages,
> +                            gid, &vm_gid_addr);
>  
>      if ( ret == 0 )
>      {
>  	printf("store-mfn %li\n", store_mfn);
>          if ( !hvm )
>              printf("console-mfn %li\n", console_mfn);
> +	printf("vm-gid-addr %lx\n", vm_gid_addr);
>  	fflush(stdout);
>      }
>  
> diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_save.c
> --- a/tools/xcutils/xc_save.c	Wed Nov 30 07:18:11 2011 -0800
> +++ b/tools/xcutils/xc_save.c	Wed Nov 30 20:51:07 2011 +0000
> @@ -169,6 +169,10 @@ main(int argc, char **argv)
>      unsigned int maxit, max_f;
>      int io_fd, ret, port;
>      struct save_callbacks callbacks;
> +    char path[128];
> +    struct xs_handle *xs;
> +    char *addr;
> +    unsigned long vm_gid_addr;
>  
>      if (argc != 6)
>          errx(1, "usage: %s iofd domid maxit maxf flags", argv[0]);
> @@ -207,8 +211,21 @@ main(int argc, char **argv)
>      memset(&callbacks, 0, sizeof(callbacks));
>      callbacks.suspend = suspend;
>      callbacks.switch_qemu_logdirty = switch_qemu_logdirty;
> +
> +    sprintf(path, "/local/domain/%d/data/generation-id", si.domid);
> +
> +    if ((xs = xs_daemon_open()) == NULL)
> +        errx(1, "Couldn't contact xenstore");
> +
> +    addr = xs_read(xs, XBT_NULL, path, NULL);
> +
> +    xs_daemon_close(xs);
> +
> +    vm_gid_addr = (addr) ? strtoul(addr, NULL, 0) : 0;
> +    free(addr);
> +
>      ret = xc_domain_save(si.xch, io_fd, si.domid, maxit, max_f, si.flags, 
> -                         &callbacks, !!(si.flags & XCFLAGS_HVM));
> +                         &callbacks, !!(si.flags & XCFLAGS_HVM), vm_gid_addr);
>  
>      if (si.suspend_evtchn > 0)
>  	 xc_suspend_evtchn_release(si.xch, si.xce, si.domid, si.suspend_evtchn);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:17:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:17:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVsS7-0005sR-Qw; Wed, 30 Nov 2011 22:16:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>)
	id 1RVsS6-0005s6-EB; Wed, 30 Nov 2011 22:16:30 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322691346!5374113!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19159 invoked from network); 30 Nov 2011 22:15:48 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 22:15:48 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAUMFjAF016745
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 17:15:45 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAUMFj7v016743;
	Wed, 30 Nov 2011 17:15:45 -0500
Date: Wed, 30 Nov 2011 18:15:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Artur Baruchi <mail.baruchi@gmail.com>
Message-ID: <20111130221545.GB16651@andromeda.dapyr.net>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, xen-users <Xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 04:46:55PM -0200, Artur Baruchi wrote:
> I just configured the serial console to see what is going on during
> the boot. I tried to run fsck and changed the grub to use the device
> path (/dev/sdaX) instead udisks-part-id, but no success.
> 
> Follow the console errors:
> 

That looks like your disk is going bad?

Was there anything before this? Like the IRQs not setup properly?

> Loading drivers, configuring devices: [   69.701448] ata1.00:
> exception Emask 0x0 SAct 0x0 SErr 0x0 act
>  ion 0x6 frozen
> [   69.705706] ata1.00: failed command: READ DMA
> [   69.708402] ata1.00: cmd c8/00:20:b8:7a:66/00:00:00:00:00/e0 tag 0
> dma 16384 in
> [   69.708403]          res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask
> 0x4 (timeout)
> [   69.717358] ata1.00: status: { DRDY }
> [   69.872400] ata1.00: revalidation failed (errno=-2)
> [   75.023385] ata1.00: revalidation failed (errno=-2)
> [   80.174383] ata1.00: revalidation failed (errno=-2)
> [   80.329687] end_request: I/O error, dev sda, sector 6716088
> [   80.333096] end_request: I/O error, dev sda, sector 6716088
> [   80.336676] end_request: I/O error, dev sda, sector 6716088
> [   80.340408] end_request: I/O error, dev sda, sector 6145504
> [   80.344063] end_request: I/O error, dev sda, sector 6145504
> [   80.347465] end_request: I/O error, dev sda, sector 6145504
> [   80.351795] end_request: I/O error, dev sda, sector 6145504
> [   80.356081] end_request: I/O error, dev sda, sector 6145504
> [   80.359587] end_request: I/O error, dev sda, sector 6145504
> [   80.363115] end_request: I/O error, dev sda, sector 6145504
> [   80.366535] end_request: I/O error, dev sda, sector 6145504
> [   80.370034] end_request: I/O error, dev sda, sector 6145504
> [   80.373924] end_request: I/O error, dev sda, sector 9979920
> [   80.377458] Buffer I/O error on device sda3, logical block 721410
> [   80.389108] end_request: I/O error, dev sda, sector 4970504
> [   80.392576] end_request: I/O error, dev sda, sector 4970504
> [   80.396208] end_request: I/O error, dev sda, sector 11290592
> [   80.399747] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> [   80.406333] end_request: I/O error, dev sda, sector 4208640
> [   80.409650] Buffer I/O error on device sda3, logical block 0
> udevd-work[1631]: exec of program '/lib/udev/ata_id' failed
> 
> [   80.416228] end_request: I/O error, dev sda, sector 6796224
> [   80.419759] end_request: I/O error, dev sda, sector 6796288
> [   80.423135] end_request: I/O error, dev sda, sector 6796288
> [   80.425117] end_request: I/O error, dev sda, sector 6796288
> [   80.427447] end_request: I/O error, dev sda, sector 6796288
> [   80.429840] end_request: I/O error, dev sda, sector 6796288
> [   80.432094] end_request: I/O error, dev sda, sector 6796288
> [   80.434425] end_request: I/O error, dev sda, sector 6796288
> [   80.436746] end_request: I/O error, dev sda, sector 6796288
> [   80.439043] end_request: I/O error, dev sda, sector 6796288
> [   80.441358] end_request: I/O error, dev sda, sector 6796288
> [   80.443626] end_request: I/O error, dev sda, sector 6796288
> [   80.445864] end_request: I/O error, dev sda, sector 6796288
> [   80.448051] end_request: I/O error, dev sda, sector 6796288
> [   80.450271] end_request: I/O error, dev sda, sector 6796288
> [   80.452482] end_request: I/O error, dev sda, sector 6796288
> [   80.454745] end_request: I/O error, dev sda, sector 6796288
> [   80.457029] end_request: I/O error, dev sda, sector 6796288
> [   80.459299] end_request: I/O error, dev sda, sector 6796288
> [   80.461604] end_request: I/O error, dev sda, sector 6796288
> [   80.463843] end_request: I/O error, dev sda, sector 6796288
> [   80.466045] end_request: I/O error, dev sda, sector 6796288
> [   80.468274] end_request: I/O error, dev sda, sector 6796288
> [   80.470510] end_request: I/O error, dev sda, sector 6796288
> [   80.472725] end_request: I/O error, dev sda, sector 6796288
> [   80.474902] end_request: I/O error, dev sda, sector 6796288
> [   80.477103] end_request: I/O error, dev sda, sector 6796288
> [   80.479278] end_request: I/O error, dev sda, sector 6796288
> [   80.481514] end_request: I/O error, dev sda, sector 6796288
> [   80.483647] end_request: I/O error, dev sda, sector 6796288
> [   80.485780] end_request: I/O error, dev sda, sector 6796288
> [   80.487838] end_request: I/O error, dev sda, sector 6796288
> [   80.489897] end_request: I/O error, dev sda, sector 6796224
> [   80.491920] end_request: I/O error, dev sda, sector 6796224
> [   80.494294] end_request: I/O error, dev sda, sector 4971928
> [   80.496445] end_request: I/O error, dev sda, sector 4971928
> [   80.498650] end_request: I/O error, dev sda, sector 11290592
> [   80.500834] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> [   80.504930] end_request: I/O error, dev sda, sector 4208640
> [   80.507019] Buffer I/O error on device sda3, logical block 0
> udevd-work[1632]: exec of program '/lib/udev/scsi_id' failed
> 
> [   80.511028] end_request: I/O error, dev sda, sector 12352272
> [   80.513236] Buffer I/O error on device sda3, logical block 1017954
> [   80.515677] end_request: I/O error, dev sda, sector 12360888
> [   80.518021] Buffer I/O error on device sda3, logical block 1019031
> [   80.520527] Buffer I/O error on device sda3, logical block 1019032
> [   80.523072] end_request: I/O error, dev sda, sector 9980016
> [   80.525394] journal_bmap: journal block not found at offset 12 on sda3
> [   80.527956] Aborting journal on device sda3.
> [   80.529854] end_request: I/O error, dev sda, sector 9979920
> [   80.532119] Buffer I/O error on device sda3, logical block 721410
> [   80.534799] end_request: I/O error, dev sda, sector 9979928
> [   80.537239] end_request: I/O error, dev sda, sector 9979936
> [   80.539639] end_request: I/O error, dev sda, sector 9370632
> [   80.542144] end_request: I/O error, dev sda, sector 9370632
> [   80.544499] EXT3-fs (sda3): error: ext3_journal_start_sb: Detected
> aborted journal
> [   80.547659] EXT3-fs (sda3): error: remounting filesystem read-only
> [   80.550535] end_request: I/O error, dev sda, sector 11290592
> [   80.552989] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> udevd-work[1634]: exec of program '/sbin/blkid' failed
> 
> [   80.559337] end_request: I/O error, dev sda, sector 4972560
> [   80.561964] end_request: I/O error, dev sda, sector 4972560
> [   80.564546] end_request: I/O error, dev sda, sector 11290592
> [   80.567069] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> udevd-work[1635]: exec of program '/lib/udev/edd_id' failed
> 
> [   80.576377] end_request: I/O error, dev sda, sector 4952712
> [   80.580086] end_request: I/O error, dev sda, sector 4952712
> [   80.583689] end_request: I/O error, dev sda, sector 11290592
> [   80.586292] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> udevd-work[1636]: exec of program '/lib/udev/udisks-part-id' failed
> 
> [   80.593995] end_request: I/O error, dev sda, sector 9370632
> [   80.596704] end_request: I/O error, dev sda, sector 9370632
> [   80.596755] end_request: I/O error, dev sda, sector 11290592
> [   80.596760] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> udevd-work[1637][   80.608632] end_request: I/O error, dev sda, sector 11290592
> : exec of program '/sbin/blkid' failed[   80.612951] EXT3-fs error
> (device sda3): ext3_get_inode_loc: u
> nable to read inode block - inode=223126, block=885244
> 
> 
> [   80.621449] end_request: I/O error, dev sda, sector 9370632
> [   80.624665] end_request: I/O error, dev sda, sector 11290592
> [   80.627305] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> udevd-work[1638]: exec of program '/sbin/blkid' failed
> 
> udevd-work[1639]: exec of program '/sbin/blkid' failed
> 
> [   80.635017] end_request: I/O error, dev sda, sector 4952712
> [   80.637899] end_request: I/O error, dev sda, sector 4952712
> [   80.637956] end_request: I/O error, dev sda, sector 11290592
> [   80.637962] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> [   80.649954] end_request: I/O error, dev sda, sector 4952712
> udevd-work[1640]: exec of program '/lib/udev/udi[   80.649974]
> end_request: I/O error, dev sda, sector
> 11290592
> sks-part-id' failed
> [   80.649981] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> 
> udevd-work[1641][   80.664921] end_request: I/O error, dev sda, sector 11290592
> : exec of program '/lib/udev/udisks-part-id' fai[   80.669088] EXT3-fs
> error (device sda3): ext3_get_in
> ode_loc: ledunable to read inode block - inode=223126, block=885244
> 
> 
> udevd-work[1642]: exec of program '/lib/udev/udisks-part-id' failed
> 
>                                                                       done
> [   80.688649] end_request: I/O error, dev sda, sector 11516760
> [   80.693402] end_request: I/O error, dev sda, sector 11517320
> [   80.698410] end_request: I/O error, dev sda, sector 11516760
> boot.loadmodules: Input/output error
> [   80.705752] end_request: I/O error, dev sda, sector 11517320
> boot.rootfsck: Input/output error
> [   80.712719] end_request: I/O error, dev sda, sector 11516496
> [   80.717814] end_request: I/O error, dev sda, sector 11516704
> [   80.730101] end_request: I/O error, dev sda, sector 11516496
> boot.clock: Input/output error
> [   80.736217] end_request: I/O error, dev sda, sector 11516768
> [   80.741296] end_request: I/O error, dev sda, sector 11352104
> [   80.745949] end_request: I/O error, dev sda, sector 11352104
> boot.device-mapper: Input/output error
> [   80.753208] end_request: I/O error, dev sda, sector 11516768
> boot.localfs: Input/output error
> [   80.760052] end_request: I/O error, dev sda, sector 11516488
> [   80.764909] end_request: I/O error, dev sda, sector 11499608
> [   80.769502] end_request: I/O error, dev sda, sector 11303224
> [   80.775085] end_request: I/O error, dev sda, sector 11516744
> [   80.779703] end_request: I/O error, dev sda, sector 11517168
> [   80.784166] end_request: I/O error, dev sda, sector 11517360
> [   80.788596] end_request: I/O error, dev sda, sector 11518640
> [   80.793861] end_request: I/O error, dev sda, sector 11518640
> [   80.798273] end_request: I/O error, dev sda, sector 11517360
> [   80.803364] end_request: I/O error, dev sda, sector 11517176
> boot.swap: Input/output error
> [   80.809435] end_request: I/O error, dev sda, sector 11517168
> boot.proc: Input/output error
> [   80.815339] end_request: I/O error, dev sda, sector 11516488
> boot.localnet: Input/output error[   80.820846] end_request: I/O
> error, dev sda, sector 11516744
> [   80.825458] end_request: I/O error, dev sda, sector 11499608
> [   80.829771] end_request: I/O error, dev sda, sector 11303224
> [   80.834086] end_request: I/O error, dev sda, sector 11516752
> 
> boot.cleanup: In[   80.838667] end_request: I/O error, dev sda, sector 11518160
> put/output error[   80.843568] end_request: I/O error, dev sda, sector 11516752
> 
> [   80.847792] end_request: I/O error, dev sda, sector 11518160
> boot.cycle: Input/output error[   80.853141] end_request: I/O error,
> dev sda, sector 11417656
> 
> [   80.853840] end_request: I/O error, dev sda, sector 11417656
> boot.fuse: Input/output error
> boot.klog: Input/output error
> boot.sysctl: Input/output error
> [   80.865148] end_request: I/O error, dev sda, sector 11516712
> [   80.865199] end_request: I/O error, dev sda, sector 11516712
> boot.ldconfig: Input/output error
> boot.udev_retry: Input/output error
> boot.apparmor: Input/output error
> boot.ipconfig: Input/output error
> System Boot Control: The system has been                              set up
> Failed features: boot.loadmodules boot.rootfsck boot.clock
> boot.device-mapper boot.localfs boot.cleanup
>      boot.cycle boot.fuse boot.klog boot.localnet boot.proc boot.swap
> boot.sysctl boot.ldconfig boot.udev_r
> etry boot.apparmor boot.ipconfig
> System Boot Control: Running /etc/init.d/boot.local
> [   80.890020] end_request: I/O error, dev sda, sector 11540760
> [   80.892185] end_request: I/O error, dev sda, sector 11540760
> /etc/init.d/boot.local: /etc/init.d/boot.local: Input/output error    failed
> [   80.897735] end_request: I/O error, dev sda, sector 9369944
> [   80.900025] end_request: I/O error, dev sda, sector 9369944
> [   80.902265] end_request: I/O error, dev sda, sector 9369944
> /etc/init.d/boot: line 314: /sbin/killproc: Input/output error
> /etc/init.d/boot: line 326: /var/run/no_blogd: Read-only file system
> [   80.909885] end_request: I/O error, dev sda, sector 12335128
> [   80.913314] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2539                               69,
> block=1015811
> [   80.920333] end_request: I/O error, dev sda, sector 12335128
> [   80.923922] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2539                               69,
> block=1015811
> [   80.931552] end_request: I/O error, dev sda, sector 12335128
> [   80.935604] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2539                               69,
> block=1015811
> [   80.944776] end_request: I/O error, dev sda, sector 11290592
> [   80.948819] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> INIT: Entering runlevel: 3
> [   80.965451] end_request: I/O error, dev sda, sector 11519720
> [   80.969737] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   80.980514] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> 80.987414] end_request: I/O erro                               r, dev
> sda, sector 11519720
> 
> [   80.991743] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript:[   80.996145] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/s[   81.005996] end_request: I/O error,
> dev sda, sector 11519720
> ysconfig/ulimit: Input/output er[   81.010510] end_request: I/O error,
> dev sda, sector 11519720
> ror[   81.016077] end_request: I/O error, dev sda, sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> 81.022320] end_request: I/O erro                               r, dev
> sda, sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript:[   81.030711] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit:[   81.035523] end_request: I/O error,
> dev sda, sector 11519720
>  Input/output error
> /etc/initscript:[   81.043077] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit:[   81.047889] end_request: I/O error,
> dev sda, sector 11519720
>  Input/output error[   81.052231] end_request: I/O error, dev sda,
> sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
> 81.062739] end_request: I/O error, dev s
> da, sector 11519720
> ut error
> [   81.066952] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.081287] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.087077]
> end_request: I/O error, dev sda, sector
> 11519720
>  Input/output error
> [   81.092828] end_request: I/O error, dev sda, sector 11519720
> [   81.097171] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> 81.105199] end_request: I/O error,                                dev
> sda, sector 11519720
> ror
> /etc/initscript: line 77: /[   81.109861] end_request: I/O error, dev
> sda, sector 11519720
> etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input[   81.116079]
> end_request: I/O error, dev sda, s                               ector
> 11519720
> /output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/uli[   81.123656]
> end_request: I/O error, dev sda, sector 1151
>     9720
> mit: Input/output error
> [   81.131077] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript:[   81.135256] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.145043] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> 81.151102] end_request: I/O erro                               r, dev
> sda, sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript:[   81.158246] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error[   81.163908]
> end_request: I/O error, dev sda, sect                               or
> 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript:[   81.170077] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.175614] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> 81.181692] end_request: I/O erro                               r, dev
> sda, sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.188834] end_request: I/O error, dev sda, sector 11519720
> [   81.193074] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ul[   81.202959] end_request:
> I/O error, dev sda, sector 11519                               720
> imit: Input/output error
> [   81.209078] end_request: I/O error, dev sda, sector 11519720
> [   81.215046] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.220029]
> end_request: I/O error, dev sda, sector
> 11519720
>  Input/output error
> /etc/initscript:[   81.224860] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error[   81.230950]
> end_request: I/O error, dev sda, sect                               or
> 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.241445] end_request: I/O error, dev sda, sector 11519720
> [   81.245133] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> 81.253519] end_request: I/O erro                               r, dev
> sda, sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> 81.259342] end_request: I/O error,                                dev
> sda, sector 11519720
> ror
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
> 81.265077] end_request: I/O error, dev s
> da, sector 11519720
> ut error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sy[   81.271786] end_request: I/O
> error, dev sda, sector 11519720
> sconfig/ulimit: Input/output error
> [   81.277066] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.284078] end_request: I/O error, dev sda, sector 11519720
> [   81.287740] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.292708]
> end_request: I/O error, dev sda, sector
> 11519720
>  Input/output error[   81.298719] end_request: I/O error, dev sda,
> sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript:[   81.304841] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.313187] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.324518] end_request: I/O error, dev sda, sector 11519720
> [   81.329435] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> 81.334830] end_request: I/O error,                                dev
> sda, sector 11519720
> ror
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line [   81.341698] end_request: I/O error, dev sda,
> sector 11519720
> 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> INIT: Id "6[   81.349010] end_request: I/O error, dev sda, sector 11519720
> " respawning too fast: disabled for 5 minutes
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> 81.355880] end_request: I/O error,                                dev
> sda, sector 11519720
> ror
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.363875] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> 81.369261] end_request: I/O error,                                dev
> sda, sector 11519720
> ror
> INIT: Id "co" respawning too fast: disabled for 5 minutes
> /etc/initscript: line 77: /etc[   81.376228] end_request: I/O error,
> dev sda, sector 11519720
> /sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> INI[   81.383188] end_request: I/O error, dev sda, sector 11519720
> T: Id "3" respawning too fast: disabled for 5 minutes
> /etc/initscript: line 77[   81.389244] end_request: I/O error, dev
> sda, sector 11519720
> : /etc/sysconfig/ulimit: Input/output error
> INIT: Id "4" respawning too fast: disabled for 5 minutes
> /etc/in[   81.395907] end_request: I/O error, dev sda, sector 11519720
> itscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: I[   81.403341]
> end_request: I/O error, dev sda, secto                               r
> 11519720
> nput/output error
> INIT: Id "5" respawning too fast: disabled for 5 minutes
> /etc/initscript: [   81.410018] end_request: I/O error, dev sda, sector 11519720
> line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> INIT: Id "1" respawning too fast: disabled for 5 minutes
> [   81.420725] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.430746] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.440664] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> INIT: Id "2" respawning too fast: disabled for 5 minutes
> INIT: no more processes left in this runlevel
> 
> 
> 
> 
> On Wed, Nov 30, 2011 at 11:48 AM, Artur Baruchi <mail.baruchi@gmail.com> wrote:
> > Hi.
> >
> > Im installing a VM to run a benchmark, Im able to install the VM issue
> > the first boot (to setup network configurations), but if I reboot the
> > VM it just hangs and do not boot. I've re-installed the machine but no
> > success. Follow some details:
> >
> > - Dom0: Opensuse 11.3 (x86_64), kernel 2.6.34-12-xen,
> > xen-4.0.0_21091_05-6.6.x86_64
> > - DomU: Full Virtualization, Opensuse 11.3 (x86_64), kernel 2.6.34-12-desktop
> >
> > Some errors in message file (not sure that this errors mean something
> > for this problem):
> > Nov 27 23:02:17 linuxtemp01 kernel: [ 5681.075141] ata1: link is slow
> > to respond, please be patient (ready=0)
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073141] ata1: device not
> > ready (errno=-16), forcing hardreset
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073236] ata1: soft resetting link
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.228817] ata1.00: configured
> > for MWDMA2
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230503] ata1.01: configured
> > for MWDMA1
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230508] ata1.00: device
> > reported invalid CHS sector 0
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230515] ata1: EH complete
> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701259] ata1.01: exception
> > Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701262] ata1.01: failed
> > command: WRITE DMA EXT
> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701265] ata1.01: cmd
> > 35/00:98:ef:c0:24/00:02:02:00:00/f0 tag 0 dma 339968 out
> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701266] ? ? ? ? ?res
> > 40/00:01:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701268] ata1.01: status: { DRDY }
> > Nov 27 23:08:29 linuxtemp01 kernel: [ 6052.750078] ata1: link is slow
> > to respond, please be patient (ready=0)
> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748079] ata1: device not
> > ready (errno=-16), forcing hardreset
> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748134] ata1: soft resetting link
> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.902320] ata1.00: configured
> > for MWDMA2
> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903499] ata1.01: configured
> > for MWDMA1
> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903503] ata1.01: device
> > reported invalid CHS sector 0
> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903506] ata1: EH complete
> >
> > My problem is very similar to this one:
> > http://web.archiveorange.com/archive/v/wmeLDfqXdkxOOQURv2Ak
> >
> > But the workaround for this issue is not working for me.
> >
> > Any help will be welcome.
> >
> > Thanks in advance.
> >
> > Att.
> > Artur Baruchi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:17:03 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:17:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVsS7-0005sR-Qw; Wed, 30 Nov 2011 22:16:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>)
	id 1RVsS6-0005s6-EB; Wed, 30 Nov 2011 22:16:30 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1322691346!5374113!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19159 invoked from network); 30 Nov 2011 22:15:48 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 22:15:48 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAUMFjAF016745
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 17:15:45 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAUMFj7v016743;
	Wed, 30 Nov 2011 17:15:45 -0500
Date: Wed, 30 Nov 2011 18:15:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Artur Baruchi <mail.baruchi@gmail.com>
Message-ID: <20111130221545.GB16651@andromeda.dapyr.net>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: Xen-devel@lists.xensource.com, xen-users <Xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 04:46:55PM -0200, Artur Baruchi wrote:
> I just configured the serial console to see what is going on during
> the boot. I tried to run fsck and changed the grub to use the device
> path (/dev/sdaX) instead udisks-part-id, but no success.
> 
> Follow the console errors:
> 

That looks like your disk is going bad?

Was there anything before this? Like the IRQs not setup properly?

> Loading drivers, configuring devices: [   69.701448] ata1.00:
> exception Emask 0x0 SAct 0x0 SErr 0x0 act
>  ion 0x6 frozen
> [   69.705706] ata1.00: failed command: READ DMA
> [   69.708402] ata1.00: cmd c8/00:20:b8:7a:66/00:00:00:00:00/e0 tag 0
> dma 16384 in
> [   69.708403]          res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask
> 0x4 (timeout)
> [   69.717358] ata1.00: status: { DRDY }
> [   69.872400] ata1.00: revalidation failed (errno=-2)
> [   75.023385] ata1.00: revalidation failed (errno=-2)
> [   80.174383] ata1.00: revalidation failed (errno=-2)
> [   80.329687] end_request: I/O error, dev sda, sector 6716088
> [   80.333096] end_request: I/O error, dev sda, sector 6716088
> [   80.336676] end_request: I/O error, dev sda, sector 6716088
> [   80.340408] end_request: I/O error, dev sda, sector 6145504
> [   80.344063] end_request: I/O error, dev sda, sector 6145504
> [   80.347465] end_request: I/O error, dev sda, sector 6145504
> [   80.351795] end_request: I/O error, dev sda, sector 6145504
> [   80.356081] end_request: I/O error, dev sda, sector 6145504
> [   80.359587] end_request: I/O error, dev sda, sector 6145504
> [   80.363115] end_request: I/O error, dev sda, sector 6145504
> [   80.366535] end_request: I/O error, dev sda, sector 6145504
> [   80.370034] end_request: I/O error, dev sda, sector 6145504
> [   80.373924] end_request: I/O error, dev sda, sector 9979920
> [   80.377458] Buffer I/O error on device sda3, logical block 721410
> [   80.389108] end_request: I/O error, dev sda, sector 4970504
> [   80.392576] end_request: I/O error, dev sda, sector 4970504
> [   80.396208] end_request: I/O error, dev sda, sector 11290592
> [   80.399747] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> [   80.406333] end_request: I/O error, dev sda, sector 4208640
> [   80.409650] Buffer I/O error on device sda3, logical block 0
> udevd-work[1631]: exec of program '/lib/udev/ata_id' failed
> 
> [   80.416228] end_request: I/O error, dev sda, sector 6796224
> [   80.419759] end_request: I/O error, dev sda, sector 6796288
> [   80.423135] end_request: I/O error, dev sda, sector 6796288
> [   80.425117] end_request: I/O error, dev sda, sector 6796288
> [   80.427447] end_request: I/O error, dev sda, sector 6796288
> [   80.429840] end_request: I/O error, dev sda, sector 6796288
> [   80.432094] end_request: I/O error, dev sda, sector 6796288
> [   80.434425] end_request: I/O error, dev sda, sector 6796288
> [   80.436746] end_request: I/O error, dev sda, sector 6796288
> [   80.439043] end_request: I/O error, dev sda, sector 6796288
> [   80.441358] end_request: I/O error, dev sda, sector 6796288
> [   80.443626] end_request: I/O error, dev sda, sector 6796288
> [   80.445864] end_request: I/O error, dev sda, sector 6796288
> [   80.448051] end_request: I/O error, dev sda, sector 6796288
> [   80.450271] end_request: I/O error, dev sda, sector 6796288
> [   80.452482] end_request: I/O error, dev sda, sector 6796288
> [   80.454745] end_request: I/O error, dev sda, sector 6796288
> [   80.457029] end_request: I/O error, dev sda, sector 6796288
> [   80.459299] end_request: I/O error, dev sda, sector 6796288
> [   80.461604] end_request: I/O error, dev sda, sector 6796288
> [   80.463843] end_request: I/O error, dev sda, sector 6796288
> [   80.466045] end_request: I/O error, dev sda, sector 6796288
> [   80.468274] end_request: I/O error, dev sda, sector 6796288
> [   80.470510] end_request: I/O error, dev sda, sector 6796288
> [   80.472725] end_request: I/O error, dev sda, sector 6796288
> [   80.474902] end_request: I/O error, dev sda, sector 6796288
> [   80.477103] end_request: I/O error, dev sda, sector 6796288
> [   80.479278] end_request: I/O error, dev sda, sector 6796288
> [   80.481514] end_request: I/O error, dev sda, sector 6796288
> [   80.483647] end_request: I/O error, dev sda, sector 6796288
> [   80.485780] end_request: I/O error, dev sda, sector 6796288
> [   80.487838] end_request: I/O error, dev sda, sector 6796288
> [   80.489897] end_request: I/O error, dev sda, sector 6796224
> [   80.491920] end_request: I/O error, dev sda, sector 6796224
> [   80.494294] end_request: I/O error, dev sda, sector 4971928
> [   80.496445] end_request: I/O error, dev sda, sector 4971928
> [   80.498650] end_request: I/O error, dev sda, sector 11290592
> [   80.500834] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> [   80.504930] end_request: I/O error, dev sda, sector 4208640
> [   80.507019] Buffer I/O error on device sda3, logical block 0
> udevd-work[1632]: exec of program '/lib/udev/scsi_id' failed
> 
> [   80.511028] end_request: I/O error, dev sda, sector 12352272
> [   80.513236] Buffer I/O error on device sda3, logical block 1017954
> [   80.515677] end_request: I/O error, dev sda, sector 12360888
> [   80.518021] Buffer I/O error on device sda3, logical block 1019031
> [   80.520527] Buffer I/O error on device sda3, logical block 1019032
> [   80.523072] end_request: I/O error, dev sda, sector 9980016
> [   80.525394] journal_bmap: journal block not found at offset 12 on sda3
> [   80.527956] Aborting journal on device sda3.
> [   80.529854] end_request: I/O error, dev sda, sector 9979920
> [   80.532119] Buffer I/O error on device sda3, logical block 721410
> [   80.534799] end_request: I/O error, dev sda, sector 9979928
> [   80.537239] end_request: I/O error, dev sda, sector 9979936
> [   80.539639] end_request: I/O error, dev sda, sector 9370632
> [   80.542144] end_request: I/O error, dev sda, sector 9370632
> [   80.544499] EXT3-fs (sda3): error: ext3_journal_start_sb: Detected
> aborted journal
> [   80.547659] EXT3-fs (sda3): error: remounting filesystem read-only
> [   80.550535] end_request: I/O error, dev sda, sector 11290592
> [   80.552989] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> udevd-work[1634]: exec of program '/sbin/blkid' failed
> 
> [   80.559337] end_request: I/O error, dev sda, sector 4972560
> [   80.561964] end_request: I/O error, dev sda, sector 4972560
> [   80.564546] end_request: I/O error, dev sda, sector 11290592
> [   80.567069] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> udevd-work[1635]: exec of program '/lib/udev/edd_id' failed
> 
> [   80.576377] end_request: I/O error, dev sda, sector 4952712
> [   80.580086] end_request: I/O error, dev sda, sector 4952712
> [   80.583689] end_request: I/O error, dev sda, sector 11290592
> [   80.586292] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> udevd-work[1636]: exec of program '/lib/udev/udisks-part-id' failed
> 
> [   80.593995] end_request: I/O error, dev sda, sector 9370632
> [   80.596704] end_request: I/O error, dev sda, sector 9370632
> [   80.596755] end_request: I/O error, dev sda, sector 11290592
> [   80.596760] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> udevd-work[1637][   80.608632] end_request: I/O error, dev sda, sector 11290592
> : exec of program '/sbin/blkid' failed[   80.612951] EXT3-fs error
> (device sda3): ext3_get_inode_loc: u
> nable to read inode block - inode=223126, block=885244
> 
> 
> [   80.621449] end_request: I/O error, dev sda, sector 9370632
> [   80.624665] end_request: I/O error, dev sda, sector 11290592
> [   80.627305] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> udevd-work[1638]: exec of program '/sbin/blkid' failed
> 
> udevd-work[1639]: exec of program '/sbin/blkid' failed
> 
> [   80.635017] end_request: I/O error, dev sda, sector 4952712
> [   80.637899] end_request: I/O error, dev sda, sector 4952712
> [   80.637956] end_request: I/O error, dev sda, sector 11290592
> [   80.637962] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> [   80.649954] end_request: I/O error, dev sda, sector 4952712
> udevd-work[1640]: exec of program '/lib/udev/udi[   80.649974]
> end_request: I/O error, dev sda, sector
> 11290592
> sks-part-id' failed
> [   80.649981] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> 
> udevd-work[1641][   80.664921] end_request: I/O error, dev sda, sector 11290592
> : exec of program '/lib/udev/udisks-part-id' fai[   80.669088] EXT3-fs
> error (device sda3): ext3_get_in
> ode_loc: ledunable to read inode block - inode=223126, block=885244
> 
> 
> udevd-work[1642]: exec of program '/lib/udev/udisks-part-id' failed
> 
>                                                                       done
> [   80.688649] end_request: I/O error, dev sda, sector 11516760
> [   80.693402] end_request: I/O error, dev sda, sector 11517320
> [   80.698410] end_request: I/O error, dev sda, sector 11516760
> boot.loadmodules: Input/output error
> [   80.705752] end_request: I/O error, dev sda, sector 11517320
> boot.rootfsck: Input/output error
> [   80.712719] end_request: I/O error, dev sda, sector 11516496
> [   80.717814] end_request: I/O error, dev sda, sector 11516704
> [   80.730101] end_request: I/O error, dev sda, sector 11516496
> boot.clock: Input/output error
> [   80.736217] end_request: I/O error, dev sda, sector 11516768
> [   80.741296] end_request: I/O error, dev sda, sector 11352104
> [   80.745949] end_request: I/O error, dev sda, sector 11352104
> boot.device-mapper: Input/output error
> [   80.753208] end_request: I/O error, dev sda, sector 11516768
> boot.localfs: Input/output error
> [   80.760052] end_request: I/O error, dev sda, sector 11516488
> [   80.764909] end_request: I/O error, dev sda, sector 11499608
> [   80.769502] end_request: I/O error, dev sda, sector 11303224
> [   80.775085] end_request: I/O error, dev sda, sector 11516744
> [   80.779703] end_request: I/O error, dev sda, sector 11517168
> [   80.784166] end_request: I/O error, dev sda, sector 11517360
> [   80.788596] end_request: I/O error, dev sda, sector 11518640
> [   80.793861] end_request: I/O error, dev sda, sector 11518640
> [   80.798273] end_request: I/O error, dev sda, sector 11517360
> [   80.803364] end_request: I/O error, dev sda, sector 11517176
> boot.swap: Input/output error
> [   80.809435] end_request: I/O error, dev sda, sector 11517168
> boot.proc: Input/output error
> [   80.815339] end_request: I/O error, dev sda, sector 11516488
> boot.localnet: Input/output error[   80.820846] end_request: I/O
> error, dev sda, sector 11516744
> [   80.825458] end_request: I/O error, dev sda, sector 11499608
> [   80.829771] end_request: I/O error, dev sda, sector 11303224
> [   80.834086] end_request: I/O error, dev sda, sector 11516752
> 
> boot.cleanup: In[   80.838667] end_request: I/O error, dev sda, sector 11518160
> put/output error[   80.843568] end_request: I/O error, dev sda, sector 11516752
> 
> [   80.847792] end_request: I/O error, dev sda, sector 11518160
> boot.cycle: Input/output error[   80.853141] end_request: I/O error,
> dev sda, sector 11417656
> 
> [   80.853840] end_request: I/O error, dev sda, sector 11417656
> boot.fuse: Input/output error
> boot.klog: Input/output error
> boot.sysctl: Input/output error
> [   80.865148] end_request: I/O error, dev sda, sector 11516712
> [   80.865199] end_request: I/O error, dev sda, sector 11516712
> boot.ldconfig: Input/output error
> boot.udev_retry: Input/output error
> boot.apparmor: Input/output error
> boot.ipconfig: Input/output error
> System Boot Control: The system has been                              set up
> Failed features: boot.loadmodules boot.rootfsck boot.clock
> boot.device-mapper boot.localfs boot.cleanup
>      boot.cycle boot.fuse boot.klog boot.localnet boot.proc boot.swap
> boot.sysctl boot.ldconfig boot.udev_r
> etry boot.apparmor boot.ipconfig
> System Boot Control: Running /etc/init.d/boot.local
> [   80.890020] end_request: I/O error, dev sda, sector 11540760
> [   80.892185] end_request: I/O error, dev sda, sector 11540760
> /etc/init.d/boot.local: /etc/init.d/boot.local: Input/output error    failed
> [   80.897735] end_request: I/O error, dev sda, sector 9369944
> [   80.900025] end_request: I/O error, dev sda, sector 9369944
> [   80.902265] end_request: I/O error, dev sda, sector 9369944
> /etc/init.d/boot: line 314: /sbin/killproc: Input/output error
> /etc/init.d/boot: line 326: /var/run/no_blogd: Read-only file system
> [   80.909885] end_request: I/O error, dev sda, sector 12335128
> [   80.913314] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2539                               69,
> block=1015811
> [   80.920333] end_request: I/O error, dev sda, sector 12335128
> [   80.923922] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2539                               69,
> block=1015811
> [   80.931552] end_request: I/O error, dev sda, sector 12335128
> [   80.935604] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2539                               69,
> block=1015811
> [   80.944776] end_request: I/O error, dev sda, sector 11290592
> [   80.948819] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
> to read inode block - inode=2231                               26,
> block=885244
> INIT: Entering runlevel: 3
> [   80.965451] end_request: I/O error, dev sda, sector 11519720
> [   80.969737] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   80.980514] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> 80.987414] end_request: I/O erro                               r, dev
> sda, sector 11519720
> 
> [   80.991743] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript:[   80.996145] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/s[   81.005996] end_request: I/O error,
> dev sda, sector 11519720
> ysconfig/ulimit: Input/output er[   81.010510] end_request: I/O error,
> dev sda, sector 11519720
> ror[   81.016077] end_request: I/O error, dev sda, sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> 81.022320] end_request: I/O erro                               r, dev
> sda, sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript:[   81.030711] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit:[   81.035523] end_request: I/O error,
> dev sda, sector 11519720
>  Input/output error
> /etc/initscript:[   81.043077] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit:[   81.047889] end_request: I/O error,
> dev sda, sector 11519720
>  Input/output error[   81.052231] end_request: I/O error, dev sda,
> sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
> 81.062739] end_request: I/O error, dev s
> da, sector 11519720
> ut error
> [   81.066952] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.081287] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.087077]
> end_request: I/O error, dev sda, sector
> 11519720
>  Input/output error
> [   81.092828] end_request: I/O error, dev sda, sector 11519720
> [   81.097171] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> 81.105199] end_request: I/O error,                                dev
> sda, sector 11519720
> ror
> /etc/initscript: line 77: /[   81.109861] end_request: I/O error, dev
> sda, sector 11519720
> etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input[   81.116079]
> end_request: I/O error, dev sda, s                               ector
> 11519720
> /output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/uli[   81.123656]
> end_request: I/O error, dev sda, sector 1151
>     9720
> mit: Input/output error
> [   81.131077] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript:[   81.135256] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.145043] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> 81.151102] end_request: I/O erro                               r, dev
> sda, sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript:[   81.158246] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error[   81.163908]
> end_request: I/O error, dev sda, sect                               or
> 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript:[   81.170077] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.175614] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> 81.181692] end_request: I/O erro                               r, dev
> sda, sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.188834] end_request: I/O error, dev sda, sector 11519720
> [   81.193074] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ul[   81.202959] end_request:
> I/O error, dev sda, sector 11519                               720
> imit: Input/output error
> [   81.209078] end_request: I/O error, dev sda, sector 11519720
> [   81.215046] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.220029]
> end_request: I/O error, dev sda, sector
> 11519720
>  Input/output error
> /etc/initscript:[   81.224860] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error[   81.230950]
> end_request: I/O error, dev sda, sect                               or
> 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.241445] end_request: I/O error, dev sda, sector 11519720
> [   81.245133] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
> 81.253519] end_request: I/O erro                               r, dev
> sda, sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> 81.259342] end_request: I/O error,                                dev
> sda, sector 11519720
> ror
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
> 81.265077] end_request: I/O error, dev s
> da, sector 11519720
> ut error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sy[   81.271786] end_request: I/O
> error, dev sda, sector 11519720
> sconfig/ulimit: Input/output error
> [   81.277066] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.284078] end_request: I/O error, dev sda, sector 11519720
> [   81.287740] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit:[   81.292708]
> end_request: I/O error, dev sda, sector
> 11519720
>  Input/output error[   81.298719] end_request: I/O error, dev sda,
> sector 11519720
> 
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript:[   81.304841] end_request: I/O error, dev sda, sector 11519720
>  line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.313187] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.324518] end_request: I/O error, dev sda, sector 11519720
> [   81.329435] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> 81.334830] end_request: I/O error,                                dev
> sda, sector 11519720
> ror
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line [   81.341698] end_request: I/O error, dev sda,
> sector 11519720
> 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> INIT: Id "6[   81.349010] end_request: I/O error, dev sda, sector 11519720
> " respawning too fast: disabled for 5 minutes
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> 81.355880] end_request: I/O error,                                dev
> sda, sector 11519720
> ror
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.363875] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
> 81.369261] end_request: I/O error,                                dev
> sda, sector 11519720
> ror
> INIT: Id "co" respawning too fast: disabled for 5 minutes
> /etc/initscript: line 77: /etc[   81.376228] end_request: I/O error,
> dev sda, sector 11519720
> /sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> INI[   81.383188] end_request: I/O error, dev sda, sector 11519720
> T: Id "3" respawning too fast: disabled for 5 minutes
> /etc/initscript: line 77[   81.389244] end_request: I/O error, dev
> sda, sector 11519720
> : /etc/sysconfig/ulimit: Input/output error
> INIT: Id "4" respawning too fast: disabled for 5 minutes
> /etc/in[   81.395907] end_request: I/O error, dev sda, sector 11519720
> itscript: line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: I[   81.403341]
> end_request: I/O error, dev sda, secto                               r
> 11519720
> nput/output error
> INIT: Id "5" respawning too fast: disabled for 5 minutes
> /etc/initscript: [   81.410018] end_request: I/O error, dev sda, sector 11519720
> line 77: /etc/sysconfig/ulimit: Input/output error
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> INIT: Id "1" respawning too fast: disabled for 5 minutes
> [   81.420725] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.430746] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> [   81.440664] end_request: I/O error, dev sda, sector 11519720
> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
> INIT: Id "2" respawning too fast: disabled for 5 minutes
> INIT: no more processes left in this runlevel
> 
> 
> 
> 
> On Wed, Nov 30, 2011 at 11:48 AM, Artur Baruchi <mail.baruchi@gmail.com> wrote:
> > Hi.
> >
> > Im installing a VM to run a benchmark, Im able to install the VM issue
> > the first boot (to setup network configurations), but if I reboot the
> > VM it just hangs and do not boot. I've re-installed the machine but no
> > success. Follow some details:
> >
> > - Dom0: Opensuse 11.3 (x86_64), kernel 2.6.34-12-xen,
> > xen-4.0.0_21091_05-6.6.x86_64
> > - DomU: Full Virtualization, Opensuse 11.3 (x86_64), kernel 2.6.34-12-desktop
> >
> > Some errors in message file (not sure that this errors mean something
> > for this problem):
> > Nov 27 23:02:17 linuxtemp01 kernel: [ 5681.075141] ata1: link is slow
> > to respond, please be patient (ready=0)
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073141] ata1: device not
> > ready (errno=-16), forcing hardreset
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073236] ata1: soft resetting link
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.228817] ata1.00: configured
> > for MWDMA2
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230503] ata1.01: configured
> > for MWDMA1
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230508] ata1.00: device
> > reported invalid CHS sector 0
> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230515] ata1: EH complete
> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701259] ata1.01: exception
> > Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701262] ata1.01: failed
> > command: WRITE DMA EXT
> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701265] ata1.01: cmd
> > 35/00:98:ef:c0:24/00:02:02:00:00/f0 tag 0 dma 339968 out
> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701266] ? ? ? ? ?res
> > 40/00:01:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701268] ata1.01: status: { DRDY }
> > Nov 27 23:08:29 linuxtemp01 kernel: [ 6052.750078] ata1: link is slow
> > to respond, please be patient (ready=0)
> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748079] ata1: device not
> > ready (errno=-16), forcing hardreset
> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748134] ata1: soft resetting link
> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.902320] ata1.00: configured
> > for MWDMA2
> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903499] ata1.01: configured
> > for MWDMA1
> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903503] ata1.01: device
> > reported invalid CHS sector 0
> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903506] ata1: EH complete
> >
> > My problem is very similar to this one:
> > http://web.archiveorange.com/archive/v/wmeLDfqXdkxOOQURv2Ak
> >
> > But the workaround for this issue is not working for me.
> >
> > Any help will be welcome.
> >
> > Thanks in advance.
> >
> > Att.
> > Artur Baruchi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:25:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:25:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVsa4-0006BH-Gy; Wed, 30 Nov 2011 22:24:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVsa2-0006BC-DE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 22:24:42 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322691840!5369953!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8757 invoked from network); 30 Nov 2011 22:24:01 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 22:24:01 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAUMO0QY016989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 17:24:00 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAUMNxJl016987;
	Wed, 30 Nov 2011 17:23:59 -0500
Date: Wed, 30 Nov 2011 18:23:59 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111130222359.GC16651@andromeda.dapyr.net>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
	(pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 04:27:11PM +0000, Jan Beulich wrote:
> Largely as a result of the continuing resistance of Linux maintainers
> to accept a microcode loading patch for pv-ops Xen kernels, this
> follows the suggested route and provides a means to load microcode
> updates without the assistance of Dom0, thus also addressing eventual
> problems in the hardware much earlier.
> 
> This leverages the fact that via the multiboot protocol another blob
> of data can be easily added in the form of just an extra module. Since
> microcode data cannot reliably be recognized by looking at the
> provided data, this requires (in the non-EFI case) the use of a
> command line parameter ("ucode=<number>") to identify which of the

Well, usually there would be two modules - the kernel (which we can
identify) and the initramfs (which I guess one can also identify)?
It seems that by process of elimination we could determine that the
remaining module is the blob? Or would that be simple too dangerous
to make such assumption?

> modules is to be parsed for an eventual microcode update (in the EFI
> case the module is being identified in the config file, and hence the
> command line argument, if given, will be ignored).
> 
> This required to adjust the XSM module determination logic accordingly.
> 
> The format of the data to be provided is the raw binary blob already
> used for AMD CPUs, and the output of the intel-microcode2ucode utility
> for the Intel case (either the per-(family,model,stepping) file or -
> to make things easier for distro-s integration-wise - simply the
> concatenation of all of them).

There was some talk by hpa and borislav of how they wanted the payload,
but it never got finalized I think? Would it make sense to CC them on
this to see how they are planning to implement it in GRUB2?

I got the impression they wanted some new .pack format or so?
Or is the format that they were talking about exactly what you picked?

> 
> In order to not convert the spin_lock() in microcode_update_cpu() (and
> then obviously also all other uses on microcode_mutex) to
> spin_lock_irqsave() (which would be undesirable for the hypercall
> context in which the function also runs), the boot time handling gets
> done using a tasklet (instead of using on_selected_cpus()).

Thanks for writing this.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/efi/boot.c
> +++ b/xen/arch/x86/efi/boot.c
> @@ -49,6 +49,7 @@ static UINT32 __initdata mdesc_ver;
>  static struct file __initdata cfg;
>  static struct file __initdata kernel;
>  static struct file __initdata ramdisk;
> +static struct file __initdata ucode;
>  static struct file __initdata xsm;
>  
>  static multiboot_info_t __initdata mbi = {
> @@ -174,6 +175,8 @@ static void __init __attribute__((__nore
>          efi_bs->FreePages(kernel.addr, PFN_UP(kernel.size));
>      if ( ramdisk.addr )
>          efi_bs->FreePages(ramdisk.addr, PFN_UP(ramdisk.size));
> +    if ( ucode.addr )
> +        efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
>      if ( xsm.addr )
>          efi_bs->FreePages(xsm.addr, PFN_UP(xsm.size));
>  
> @@ -806,6 +809,17 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>          efi_bs->FreePool(name.w);
>      }
>  
> +    name.s = get_value(&cfg, section.s, "ucode");
> +    if ( !name.s )
> +        name.s = get_value(&cfg, "global", "ucode");
> +    if ( name.s )
> +    {
> +        microcode_set_module(mbi.mods_count);
> +        split_value(name.s);
> +        read_file(dir_handle, s2w(&name), &ucode);
> +        efi_bs->FreePool(name.w);
> +    }
> +
>      name.s = get_value(&cfg, section.s, "xsm");
>      if ( name.s )
>      {
> --- a/xen/arch/x86/microcode.c
> +++ b/xen/arch/x86/microcode.c
> @@ -29,13 +29,49 @@
>  #include <xen/notifier.h>
>  #include <xen/sched.h>
>  #include <xen/smp.h>
> +#include <xen/softirq.h>
>  #include <xen/spinlock.h>
> +#include <xen/tasklet.h>
>  #include <xen/guest_access.h>
>  
>  #include <asm/msr.h>
>  #include <asm/processor.h>
> +#include <asm/setup.h>
>  #include <asm/microcode.h>
>  
> +static module_t __initdata ucode_mod;
> +static void *(*__initdata ucode_mod_map)(const module_t *);
> +static unsigned int __initdata ucode_mod_idx;
> +static bool_t __initdata ucode_mod_forced;
> +static cpumask_t __initdata init_mask;
> +
> +void __init microcode_set_module(unsigned int idx)
> +{
> +    ucode_mod_idx = idx;
> +    ucode_mod_forced = 1;
> +}
> +
> +static void __init parse_ucode(char *s)
> +{
> +    if ( !ucode_mod_forced )
> +        ucode_mod_idx = simple_strtoul(s, NULL, 0);
> +}
> +custom_param("ucode", parse_ucode);
> +
> +void __init microcode_grab_module(
> +    unsigned long *module_map,
> +    const multiboot_info_t *mbi,
> +    void *(*map)(const module_t *))
> +{
> +    module_t *mod = (module_t *)__va(mbi->mods_addr);
> +
> +    if ( !ucode_mod_idx || ucode_mod_idx >= mbi->mods_count ||
> +         !__test_and_clear_bit(ucode_mod_idx, module_map) )
> +        return;
> +    ucode_mod = mod[ucode_mod_idx];
> +    ucode_mod_map = map;
> +}
> +
>  const struct microcode_ops *microcode_ops;
>  
>  static DEFINE_SPINLOCK(microcode_mutex);
> @@ -183,6 +219,41 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> +static void __init _do_microcode_update(unsigned long data)
> +{
> +    microcode_update_cpu((void *)data, ucode_mod.mod_end);
> +    cpumask_set_cpu(smp_processor_id(), &init_mask);
> +}
> +
> +static int __init microcode_init(void)
> +{
> +    void *data;
> +    static struct tasklet __initdata tasklet;
> +    unsigned int cpu;
> +
> +    if ( !microcode_ops || !ucode_mod.mod_end )
> +        return 0;
> +
> +    data = ucode_mod_map(&ucode_mod);
> +    if ( !data )
> +        return -ENOMEM;
> +
> +    softirq_tasklet_init(&tasklet, _do_microcode_update, (unsigned long)data);
> +
> +    for_each_online_cpu ( cpu )
> +    {
> +        tasklet_schedule_on_cpu(&tasklet, cpu);
> +        do {
> +            process_pending_softirqs();
> +        } while ( !cpumask_test_cpu(cpu, &init_mask) );
> +    }
> +
> +    ucode_mod_map(NULL);
> +
> +    return 0;
> +}
> +__initcall(microcode_init);
> +
>  static int microcode_percpu_callback(
>      struct notifier_block *nfb, unsigned long action, void *hcpu)
>  {
> @@ -205,7 +276,20 @@ static struct notifier_block microcode_p
>  static int __init microcode_presmp_init(void)
>  {
>      if ( microcode_ops )
> +    {
> +        if ( ucode_mod.mod_end )
> +        {
> +            void *data = ucode_mod_map(&ucode_mod);
> +
> +            if ( data )
> +                microcode_update_cpu(data, ucode_mod.mod_end);
> +
> +            ucode_mod_map(NULL);
> +        }
> +
>          register_cpu_notifier(&microcode_percpu_nfb);
> +    }
> +
>      return 0;
>  }
>  presmp_initcall(microcode_presmp_init);
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -550,10 +550,10 @@ void __init __start_xen(unsigned long mb
>  {
>      char *memmap_type = NULL;
>      char *cmdline, *kextra, *loader;
> -    unsigned int initrdidx = 1;
> +    unsigned int initrdidx;
>      multiboot_info_t *mbi = __va(mbi_p);
>      module_t *mod = (module_t *)__va(mbi->mods_addr);
> -    unsigned long nr_pages, modules_headroom;
> +    unsigned long nr_pages, modules_headroom, *module_map;
>      int i, j, e820_warn = 0, bytes = 0;
>      bool_t acpi_boot_table_init_done = 0;
>      struct ns16550_defaults ns16550 = {
> @@ -1229,7 +1229,13 @@ void __init __start_xen(unsigned long mb
>  
>      init_IRQ();
>  
> -    xsm_init(&initrdidx, mbi, bootstrap_map);
> +    module_map = xmalloc_array(unsigned long, BITS_TO_LONGS(mbi->mods_count));
> +    bitmap_fill(module_map, mbi->mods_count);
> +    __clear_bit(0, module_map); /* Dom0 kernel is always first */
> +
> +    xsm_init(module_map, mbi, bootstrap_map);
> +
> +    microcode_grab_module(module_map, mbi, bootstrap_map);
>  
>      timer_init();
>  
> @@ -1356,6 +1362,12 @@ void __init __start_xen(unsigned long mb
>      if ( xen_cpuidle )
>          xen_processor_pmbits |= XEN_PROCESSOR_PM_CX;
>  
> +    initrdidx = find_first_bit(module_map, mbi->mods_count);
> +    if ( bitmap_weight(module_map, mbi->mods_count) > 1 )
> +        printk(XENLOG_WARNING
> +               "Multiple initrd candidates, picking module #%u\n",
> +               initrdidx);
> +
>      /*
>       * We're going to setup domain0 using the module(s) that we stashed safely
>       * above our heap. The second module, if present, is an initrd ramdisk.
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -598,6 +598,7 @@ int cpuid_hypervisor_leaves( uint32_t id
>  int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val);
>  int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val);
>  
> +void microcode_set_module(unsigned int);
>  int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len);
>  int microcode_resume_cpu(int cpu);
>  
> --- a/xen/include/asm-x86/setup.h
> +++ b/xen/include/asm-x86/setup.h
> @@ -44,4 +44,7 @@ void discard_initial_images(void);
>  int xen_in_range(unsigned long mfn);
>  void arch_get_xen_caps(xen_capabilities_info_t *info);
>  
> +void microcode_grab_module(
> +    unsigned long *, const multiboot_info_t *, void *(*)(const module_t *));
> +
>  #endif
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -454,14 +454,15 @@ static inline long __do_xsm_op (XEN_GUES
>  }
>  
>  #ifdef XSM_ENABLE
> -extern int xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *));
> -extern int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +extern int xsm_policy_init(unsigned long *module_map,
> +                           const multiboot_info_t *mbi,
>                             void *(*bootstrap_map)(const module_t *));
>  extern int register_xsm(struct xsm_operations *ops);
>  extern int unregister_xsm(struct xsm_operations *ops);
>  #else
> -static inline int xsm_init (unsigned int *initrdidx,
> +static inline int xsm_init (unsigned long *module_map,
>                              const multiboot_info_t *mbi,
>                              void *(*bootstrap_map)(const module_t *))
>  {
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -43,7 +43,7 @@ static void __init do_xsm_initcalls(void
>      }
>  }
>  
> -int __init xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +int __init xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *))
>  {
>      int ret = 0;
> @@ -52,7 +52,7 @@ int __init xsm_init(unsigned int *initrd
>  
>      if ( XSM_MAGIC )
>      {
> -        ret = xsm_policy_init(initrdidx, mbi, bootstrap_map);
> +        ret = xsm_policy_init(module_map, mbi, bootstrap_map);
>          if ( ret )
>          {
>              bootstrap_map(NULL);
> --- a/xen/xsm/xsm_policy.c
> +++ b/xen/xsm/xsm_policy.c
> @@ -20,11 +20,12 @@
>  
>  #include <xsm/xsm.h>
>  #include <xen/multiboot.h>
> +#include <asm/bitops.h>
>  
>  char *__initdata policy_buffer = NULL;
>  u32 __initdata policy_size = 0;
>  
> -int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +int xsm_policy_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *))
>  {
>      int i;
> @@ -35,10 +36,13 @@ int xsm_policy_init(unsigned int *initrd
>  
>      /*
>       * Try all modules and see whichever could be the binary policy.
> -     * Adjust the initrdidx if module[1] is the binary policy.
> +     * Adjust module_map for the module that is the binary policy.
>       */
>      for ( i = mbi->mods_count-1; i >= 1; i-- )
>      {
> +        if ( !test_bit(i, module_map) )
> +            continue;
> +
>          _policy_start = bootstrap_map(mod + i);
>          _policy_len   = mod[i].mod_end;
>  
> @@ -50,8 +54,7 @@ int xsm_policy_init(unsigned int *initrd
>              printk("Policy len  0x%lx, start at %p.\n",
>                     _policy_len,_policy_start);
>  
> -            if ( i == 1 )
> -                *initrdidx = (mbi->mods_count > 2) ? 2 : 0;
> +            __clear_bit(i, module_map);
>              break;
>  
>          }
> 
> 

> x86/microcode: enable boot time (pre-Dom0) loading
> 
> Largely as a result of the continuing resistance of Linux maintainers
> to accept a microcode loading patch for pv-ops Xen kernels, this
> follows the suggested route and provides a means to load microcode
> updates without the assistance of Dom0, thus also addressing eventual
> problems in the hardware much earlier.
> 
> This leverages the fact that via the multiboot protocol another blob
> of data can be easily added in the form of just an extra module. Since
> microcode data cannot reliably be recognized by looking at the
> provided data, this requires (in the non-EFI case) the use of a
> command line parameter ("ucode=<number>") to identify which of the
> modules is to be parsed for an eventual microcode update (in the EFI
> case the module is being identified in the config file, and hence the
> command line argument, if given, will be ignored).
> 
> This required to adjust the XSM module determination logic accordingly.
> 
> The format of the data to be provided is the raw binary blob already
> used for AMD CPUs, and the output of the intel-microcode2ucode utility
> for the Intel case (either the per-(family,model,stepping) file or -
> to make things easier for distro-s integration-wise - simply the
> concatenation of all of them).
> 
> In order to not convert the spin_lock() in microcode_update_cpu() (and
> then obviously also all other uses on microcode_mutex) to
> spin_lock_irqsave() (which would be undesirable for the hypercall
> context in which the function also runs), the boot time handling gets
> done using a tasklet (instead of using on_selected_cpus()).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/efi/boot.c
> +++ b/xen/arch/x86/efi/boot.c
> @@ -49,6 +49,7 @@ static UINT32 __initdata mdesc_ver;
>  static struct file __initdata cfg;
>  static struct file __initdata kernel;
>  static struct file __initdata ramdisk;
> +static struct file __initdata ucode;
>  static struct file __initdata xsm;
>  
>  static multiboot_info_t __initdata mbi = {
> @@ -174,6 +175,8 @@ static void __init __attribute__((__nore
>          efi_bs->FreePages(kernel.addr, PFN_UP(kernel.size));
>      if ( ramdisk.addr )
>          efi_bs->FreePages(ramdisk.addr, PFN_UP(ramdisk.size));
> +    if ( ucode.addr )
> +        efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
>      if ( xsm.addr )
>          efi_bs->FreePages(xsm.addr, PFN_UP(xsm.size));
>  
> @@ -806,6 +809,17 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>          efi_bs->FreePool(name.w);
>      }
>  
> +    name.s = get_value(&cfg, section.s, "ucode");
> +    if ( !name.s )
> +        name.s = get_value(&cfg, "global", "ucode");
> +    if ( name.s )
> +    {
> +        microcode_set_module(mbi.mods_count);
> +        split_value(name.s);
> +        read_file(dir_handle, s2w(&name), &ucode);
> +        efi_bs->FreePool(name.w);
> +    }
> +
>      name.s = get_value(&cfg, section.s, "xsm");
>      if ( name.s )
>      {
> --- a/xen/arch/x86/microcode.c
> +++ b/xen/arch/x86/microcode.c
> @@ -29,13 +29,49 @@
>  #include <xen/notifier.h>
>  #include <xen/sched.h>
>  #include <xen/smp.h>
> +#include <xen/softirq.h>
>  #include <xen/spinlock.h>
> +#include <xen/tasklet.h>
>  #include <xen/guest_access.h>
>  
>  #include <asm/msr.h>
>  #include <asm/processor.h>
> +#include <asm/setup.h>
>  #include <asm/microcode.h>
>  
> +static module_t __initdata ucode_mod;
> +static void *(*__initdata ucode_mod_map)(const module_t *);
> +static unsigned int __initdata ucode_mod_idx;
> +static bool_t __initdata ucode_mod_forced;
> +static cpumask_t __initdata init_mask;
> +
> +void __init microcode_set_module(unsigned int idx)
> +{
> +    ucode_mod_idx = idx;
> +    ucode_mod_forced = 1;
> +}
> +
> +static void __init parse_ucode(char *s)
> +{
> +    if ( !ucode_mod_forced )
> +        ucode_mod_idx = simple_strtoul(s, NULL, 0);
> +}
> +custom_param("ucode", parse_ucode);
> +
> +void __init microcode_grab_module(
> +    unsigned long *module_map,
> +    const multiboot_info_t *mbi,
> +    void *(*map)(const module_t *))
> +{
> +    module_t *mod = (module_t *)__va(mbi->mods_addr);
> +
> +    if ( !ucode_mod_idx || ucode_mod_idx >= mbi->mods_count ||
> +         !__test_and_clear_bit(ucode_mod_idx, module_map) )
> +        return;
> +    ucode_mod = mod[ucode_mod_idx];
> +    ucode_mod_map = map;
> +}
> +
>  const struct microcode_ops *microcode_ops;
>  
>  static DEFINE_SPINLOCK(microcode_mutex);
> @@ -183,6 +219,41 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> +static void __init _do_microcode_update(unsigned long data)
> +{
> +    microcode_update_cpu((void *)data, ucode_mod.mod_end);
> +    cpumask_set_cpu(smp_processor_id(), &init_mask);
> +}
> +
> +static int __init microcode_init(void)
> +{
> +    void *data;
> +    static struct tasklet __initdata tasklet;
> +    unsigned int cpu;
> +
> +    if ( !microcode_ops || !ucode_mod.mod_end )
> +        return 0;
> +
> +    data = ucode_mod_map(&ucode_mod);
> +    if ( !data )
> +        return -ENOMEM;
> +
> +    softirq_tasklet_init(&tasklet, _do_microcode_update, (unsigned long)data);
> +
> +    for_each_online_cpu ( cpu )
> +    {
> +        tasklet_schedule_on_cpu(&tasklet, cpu);
> +        do {
> +            process_pending_softirqs();
> +        } while ( !cpumask_test_cpu(cpu, &init_mask) );
> +    }
> +
> +    ucode_mod_map(NULL);
> +
> +    return 0;
> +}
> +__initcall(microcode_init);
> +
>  static int microcode_percpu_callback(
>      struct notifier_block *nfb, unsigned long action, void *hcpu)
>  {
> @@ -205,7 +276,20 @@ static struct notifier_block microcode_p
>  static int __init microcode_presmp_init(void)
>  {
>      if ( microcode_ops )
> +    {
> +        if ( ucode_mod.mod_end )
> +        {
> +            void *data = ucode_mod_map(&ucode_mod);
> +
> +            if ( data )
> +                microcode_update_cpu(data, ucode_mod.mod_end);
> +
> +            ucode_mod_map(NULL);
> +        }
> +
>          register_cpu_notifier(&microcode_percpu_nfb);
> +    }
> +
>      return 0;
>  }
>  presmp_initcall(microcode_presmp_init);
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -550,10 +550,10 @@ void __init __start_xen(unsigned long mb
>  {
>      char *memmap_type = NULL;
>      char *cmdline, *kextra, *loader;
> -    unsigned int initrdidx = 1;
> +    unsigned int initrdidx;
>      multiboot_info_t *mbi = __va(mbi_p);
>      module_t *mod = (module_t *)__va(mbi->mods_addr);
> -    unsigned long nr_pages, modules_headroom;
> +    unsigned long nr_pages, modules_headroom, *module_map;
>      int i, j, e820_warn = 0, bytes = 0;
>      bool_t acpi_boot_table_init_done = 0;
>      struct ns16550_defaults ns16550 = {
> @@ -1229,7 +1229,13 @@ void __init __start_xen(unsigned long mb
>  
>      init_IRQ();
>  
> -    xsm_init(&initrdidx, mbi, bootstrap_map);
> +    module_map = xmalloc_array(unsigned long, BITS_TO_LONGS(mbi->mods_count));
> +    bitmap_fill(module_map, mbi->mods_count);
> +    __clear_bit(0, module_map); /* Dom0 kernel is always first */
> +
> +    xsm_init(module_map, mbi, bootstrap_map);
> +
> +    microcode_grab_module(module_map, mbi, bootstrap_map);
>  
>      timer_init();
>  
> @@ -1356,6 +1362,12 @@ void __init __start_xen(unsigned long mb
>      if ( xen_cpuidle )
>          xen_processor_pmbits |= XEN_PROCESSOR_PM_CX;
>  
> +    initrdidx = find_first_bit(module_map, mbi->mods_count);
> +    if ( bitmap_weight(module_map, mbi->mods_count) > 1 )
> +        printk(XENLOG_WARNING
> +               "Multiple initrd candidates, picking module #%u\n",
> +               initrdidx);
> +
>      /*
>       * We're going to setup domain0 using the module(s) that we stashed safely
>       * above our heap. The second module, if present, is an initrd ramdisk.
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -598,6 +598,7 @@ int cpuid_hypervisor_leaves( uint32_t id
>  int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val);
>  int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val);
>  
> +void microcode_set_module(unsigned int);
>  int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len);
>  int microcode_resume_cpu(int cpu);
>  
> --- a/xen/include/asm-x86/setup.h
> +++ b/xen/include/asm-x86/setup.h
> @@ -44,4 +44,7 @@ void discard_initial_images(void);
>  int xen_in_range(unsigned long mfn);
>  void arch_get_xen_caps(xen_capabilities_info_t *info);
>  
> +void microcode_grab_module(
> +    unsigned long *, const multiboot_info_t *, void *(*)(const module_t *));
> +
>  #endif
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -454,14 +454,15 @@ static inline long __do_xsm_op (XEN_GUES
>  }
>  
>  #ifdef XSM_ENABLE
> -extern int xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *));
> -extern int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +extern int xsm_policy_init(unsigned long *module_map,
> +                           const multiboot_info_t *mbi,
>                             void *(*bootstrap_map)(const module_t *));
>  extern int register_xsm(struct xsm_operations *ops);
>  extern int unregister_xsm(struct xsm_operations *ops);
>  #else
> -static inline int xsm_init (unsigned int *initrdidx,
> +static inline int xsm_init (unsigned long *module_map,
>                              const multiboot_info_t *mbi,
>                              void *(*bootstrap_map)(const module_t *))
>  {
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -43,7 +43,7 @@ static void __init do_xsm_initcalls(void
>      }
>  }
>  
> -int __init xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +int __init xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *))
>  {
>      int ret = 0;
> @@ -52,7 +52,7 @@ int __init xsm_init(unsigned int *initrd
>  
>      if ( XSM_MAGIC )
>      {
> -        ret = xsm_policy_init(initrdidx, mbi, bootstrap_map);
> +        ret = xsm_policy_init(module_map, mbi, bootstrap_map);
>          if ( ret )
>          {
>              bootstrap_map(NULL);
> --- a/xen/xsm/xsm_policy.c
> +++ b/xen/xsm/xsm_policy.c
> @@ -20,11 +20,12 @@
>  
>  #include <xsm/xsm.h>
>  #include <xen/multiboot.h>
> +#include <asm/bitops.h>
>  
>  char *__initdata policy_buffer = NULL;
>  u32 __initdata policy_size = 0;
>  
> -int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +int xsm_policy_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *))
>  {
>      int i;
> @@ -35,10 +36,13 @@ int xsm_policy_init(unsigned int *initrd
>  
>      /*
>       * Try all modules and see whichever could be the binary policy.
> -     * Adjust the initrdidx if module[1] is the binary policy.
> +     * Adjust module_map for the module that is the binary policy.
>       */
>      for ( i = mbi->mods_count-1; i >= 1; i-- )
>      {
> +        if ( !test_bit(i, module_map) )
> +            continue;
> +
>          _policy_start = bootstrap_map(mod + i);
>          _policy_len   = mod[i].mod_end;
>  
> @@ -50,8 +54,7 @@ int xsm_policy_init(unsigned int *initrd
>              printk("Policy len  0x%lx, start at %p.\n",
>                     _policy_len,_policy_start);
>  
> -            if ( i == 1 )
> -                *initrdidx = (mbi->mods_count > 2) ? 2 : 0;
> +            __clear_bit(i, module_map);
>              break;
>  
>          }

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:25:10 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:25:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVsa4-0006BH-Gy; Wed, 30 Nov 2011 22:24:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVsa2-0006BC-DE
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 22:24:42 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1322691840!5369953!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8757 invoked from network); 30 Nov 2011 22:24:01 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 22:24:01 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAUMO0QY016989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 17:24:00 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAUMNxJl016987;
	Wed, 30 Nov 2011 17:23:59 -0500
Date: Wed, 30 Nov 2011 18:23:59 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111130222359.GC16651@andromeda.dapyr.net>
References: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED6676F02000078000646BC@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/microcode: enable boot time
	(pre-Dom0) loading
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 04:27:11PM +0000, Jan Beulich wrote:
> Largely as a result of the continuing resistance of Linux maintainers
> to accept a microcode loading patch for pv-ops Xen kernels, this
> follows the suggested route and provides a means to load microcode
> updates without the assistance of Dom0, thus also addressing eventual
> problems in the hardware much earlier.
> 
> This leverages the fact that via the multiboot protocol another blob
> of data can be easily added in the form of just an extra module. Since
> microcode data cannot reliably be recognized by looking at the
> provided data, this requires (in the non-EFI case) the use of a
> command line parameter ("ucode=<number>") to identify which of the

Well, usually there would be two modules - the kernel (which we can
identify) and the initramfs (which I guess one can also identify)?
It seems that by process of elimination we could determine that the
remaining module is the blob? Or would that be simple too dangerous
to make such assumption?

> modules is to be parsed for an eventual microcode update (in the EFI
> case the module is being identified in the config file, and hence the
> command line argument, if given, will be ignored).
> 
> This required to adjust the XSM module determination logic accordingly.
> 
> The format of the data to be provided is the raw binary blob already
> used for AMD CPUs, and the output of the intel-microcode2ucode utility
> for the Intel case (either the per-(family,model,stepping) file or -
> to make things easier for distro-s integration-wise - simply the
> concatenation of all of them).

There was some talk by hpa and borislav of how they wanted the payload,
but it never got finalized I think? Would it make sense to CC them on
this to see how they are planning to implement it in GRUB2?

I got the impression they wanted some new .pack format or so?
Or is the format that they were talking about exactly what you picked?

> 
> In order to not convert the spin_lock() in microcode_update_cpu() (and
> then obviously also all other uses on microcode_mutex) to
> spin_lock_irqsave() (which would be undesirable for the hypercall
> context in which the function also runs), the boot time handling gets
> done using a tasklet (instead of using on_selected_cpus()).

Thanks for writing this.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/efi/boot.c
> +++ b/xen/arch/x86/efi/boot.c
> @@ -49,6 +49,7 @@ static UINT32 __initdata mdesc_ver;
>  static struct file __initdata cfg;
>  static struct file __initdata kernel;
>  static struct file __initdata ramdisk;
> +static struct file __initdata ucode;
>  static struct file __initdata xsm;
>  
>  static multiboot_info_t __initdata mbi = {
> @@ -174,6 +175,8 @@ static void __init __attribute__((__nore
>          efi_bs->FreePages(kernel.addr, PFN_UP(kernel.size));
>      if ( ramdisk.addr )
>          efi_bs->FreePages(ramdisk.addr, PFN_UP(ramdisk.size));
> +    if ( ucode.addr )
> +        efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
>      if ( xsm.addr )
>          efi_bs->FreePages(xsm.addr, PFN_UP(xsm.size));
>  
> @@ -806,6 +809,17 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>          efi_bs->FreePool(name.w);
>      }
>  
> +    name.s = get_value(&cfg, section.s, "ucode");
> +    if ( !name.s )
> +        name.s = get_value(&cfg, "global", "ucode");
> +    if ( name.s )
> +    {
> +        microcode_set_module(mbi.mods_count);
> +        split_value(name.s);
> +        read_file(dir_handle, s2w(&name), &ucode);
> +        efi_bs->FreePool(name.w);
> +    }
> +
>      name.s = get_value(&cfg, section.s, "xsm");
>      if ( name.s )
>      {
> --- a/xen/arch/x86/microcode.c
> +++ b/xen/arch/x86/microcode.c
> @@ -29,13 +29,49 @@
>  #include <xen/notifier.h>
>  #include <xen/sched.h>
>  #include <xen/smp.h>
> +#include <xen/softirq.h>
>  #include <xen/spinlock.h>
> +#include <xen/tasklet.h>
>  #include <xen/guest_access.h>
>  
>  #include <asm/msr.h>
>  #include <asm/processor.h>
> +#include <asm/setup.h>
>  #include <asm/microcode.h>
>  
> +static module_t __initdata ucode_mod;
> +static void *(*__initdata ucode_mod_map)(const module_t *);
> +static unsigned int __initdata ucode_mod_idx;
> +static bool_t __initdata ucode_mod_forced;
> +static cpumask_t __initdata init_mask;
> +
> +void __init microcode_set_module(unsigned int idx)
> +{
> +    ucode_mod_idx = idx;
> +    ucode_mod_forced = 1;
> +}
> +
> +static void __init parse_ucode(char *s)
> +{
> +    if ( !ucode_mod_forced )
> +        ucode_mod_idx = simple_strtoul(s, NULL, 0);
> +}
> +custom_param("ucode", parse_ucode);
> +
> +void __init microcode_grab_module(
> +    unsigned long *module_map,
> +    const multiboot_info_t *mbi,
> +    void *(*map)(const module_t *))
> +{
> +    module_t *mod = (module_t *)__va(mbi->mods_addr);
> +
> +    if ( !ucode_mod_idx || ucode_mod_idx >= mbi->mods_count ||
> +         !__test_and_clear_bit(ucode_mod_idx, module_map) )
> +        return;
> +    ucode_mod = mod[ucode_mod_idx];
> +    ucode_mod_map = map;
> +}
> +
>  const struct microcode_ops *microcode_ops;
>  
>  static DEFINE_SPINLOCK(microcode_mutex);
> @@ -183,6 +219,41 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> +static void __init _do_microcode_update(unsigned long data)
> +{
> +    microcode_update_cpu((void *)data, ucode_mod.mod_end);
> +    cpumask_set_cpu(smp_processor_id(), &init_mask);
> +}
> +
> +static int __init microcode_init(void)
> +{
> +    void *data;
> +    static struct tasklet __initdata tasklet;
> +    unsigned int cpu;
> +
> +    if ( !microcode_ops || !ucode_mod.mod_end )
> +        return 0;
> +
> +    data = ucode_mod_map(&ucode_mod);
> +    if ( !data )
> +        return -ENOMEM;
> +
> +    softirq_tasklet_init(&tasklet, _do_microcode_update, (unsigned long)data);
> +
> +    for_each_online_cpu ( cpu )
> +    {
> +        tasklet_schedule_on_cpu(&tasklet, cpu);
> +        do {
> +            process_pending_softirqs();
> +        } while ( !cpumask_test_cpu(cpu, &init_mask) );
> +    }
> +
> +    ucode_mod_map(NULL);
> +
> +    return 0;
> +}
> +__initcall(microcode_init);
> +
>  static int microcode_percpu_callback(
>      struct notifier_block *nfb, unsigned long action, void *hcpu)
>  {
> @@ -205,7 +276,20 @@ static struct notifier_block microcode_p
>  static int __init microcode_presmp_init(void)
>  {
>      if ( microcode_ops )
> +    {
> +        if ( ucode_mod.mod_end )
> +        {
> +            void *data = ucode_mod_map(&ucode_mod);
> +
> +            if ( data )
> +                microcode_update_cpu(data, ucode_mod.mod_end);
> +
> +            ucode_mod_map(NULL);
> +        }
> +
>          register_cpu_notifier(&microcode_percpu_nfb);
> +    }
> +
>      return 0;
>  }
>  presmp_initcall(microcode_presmp_init);
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -550,10 +550,10 @@ void __init __start_xen(unsigned long mb
>  {
>      char *memmap_type = NULL;
>      char *cmdline, *kextra, *loader;
> -    unsigned int initrdidx = 1;
> +    unsigned int initrdidx;
>      multiboot_info_t *mbi = __va(mbi_p);
>      module_t *mod = (module_t *)__va(mbi->mods_addr);
> -    unsigned long nr_pages, modules_headroom;
> +    unsigned long nr_pages, modules_headroom, *module_map;
>      int i, j, e820_warn = 0, bytes = 0;
>      bool_t acpi_boot_table_init_done = 0;
>      struct ns16550_defaults ns16550 = {
> @@ -1229,7 +1229,13 @@ void __init __start_xen(unsigned long mb
>  
>      init_IRQ();
>  
> -    xsm_init(&initrdidx, mbi, bootstrap_map);
> +    module_map = xmalloc_array(unsigned long, BITS_TO_LONGS(mbi->mods_count));
> +    bitmap_fill(module_map, mbi->mods_count);
> +    __clear_bit(0, module_map); /* Dom0 kernel is always first */
> +
> +    xsm_init(module_map, mbi, bootstrap_map);
> +
> +    microcode_grab_module(module_map, mbi, bootstrap_map);
>  
>      timer_init();
>  
> @@ -1356,6 +1362,12 @@ void __init __start_xen(unsigned long mb
>      if ( xen_cpuidle )
>          xen_processor_pmbits |= XEN_PROCESSOR_PM_CX;
>  
> +    initrdidx = find_first_bit(module_map, mbi->mods_count);
> +    if ( bitmap_weight(module_map, mbi->mods_count) > 1 )
> +        printk(XENLOG_WARNING
> +               "Multiple initrd candidates, picking module #%u\n",
> +               initrdidx);
> +
>      /*
>       * We're going to setup domain0 using the module(s) that we stashed safely
>       * above our heap. The second module, if present, is an initrd ramdisk.
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -598,6 +598,7 @@ int cpuid_hypervisor_leaves( uint32_t id
>  int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val);
>  int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val);
>  
> +void microcode_set_module(unsigned int);
>  int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len);
>  int microcode_resume_cpu(int cpu);
>  
> --- a/xen/include/asm-x86/setup.h
> +++ b/xen/include/asm-x86/setup.h
> @@ -44,4 +44,7 @@ void discard_initial_images(void);
>  int xen_in_range(unsigned long mfn);
>  void arch_get_xen_caps(xen_capabilities_info_t *info);
>  
> +void microcode_grab_module(
> +    unsigned long *, const multiboot_info_t *, void *(*)(const module_t *));
> +
>  #endif
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -454,14 +454,15 @@ static inline long __do_xsm_op (XEN_GUES
>  }
>  
>  #ifdef XSM_ENABLE
> -extern int xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *));
> -extern int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +extern int xsm_policy_init(unsigned long *module_map,
> +                           const multiboot_info_t *mbi,
>                             void *(*bootstrap_map)(const module_t *));
>  extern int register_xsm(struct xsm_operations *ops);
>  extern int unregister_xsm(struct xsm_operations *ops);
>  #else
> -static inline int xsm_init (unsigned int *initrdidx,
> +static inline int xsm_init (unsigned long *module_map,
>                              const multiboot_info_t *mbi,
>                              void *(*bootstrap_map)(const module_t *))
>  {
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -43,7 +43,7 @@ static void __init do_xsm_initcalls(void
>      }
>  }
>  
> -int __init xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +int __init xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *))
>  {
>      int ret = 0;
> @@ -52,7 +52,7 @@ int __init xsm_init(unsigned int *initrd
>  
>      if ( XSM_MAGIC )
>      {
> -        ret = xsm_policy_init(initrdidx, mbi, bootstrap_map);
> +        ret = xsm_policy_init(module_map, mbi, bootstrap_map);
>          if ( ret )
>          {
>              bootstrap_map(NULL);
> --- a/xen/xsm/xsm_policy.c
> +++ b/xen/xsm/xsm_policy.c
> @@ -20,11 +20,12 @@
>  
>  #include <xsm/xsm.h>
>  #include <xen/multiboot.h>
> +#include <asm/bitops.h>
>  
>  char *__initdata policy_buffer = NULL;
>  u32 __initdata policy_size = 0;
>  
> -int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +int xsm_policy_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *))
>  {
>      int i;
> @@ -35,10 +36,13 @@ int xsm_policy_init(unsigned int *initrd
>  
>      /*
>       * Try all modules and see whichever could be the binary policy.
> -     * Adjust the initrdidx if module[1] is the binary policy.
> +     * Adjust module_map for the module that is the binary policy.
>       */
>      for ( i = mbi->mods_count-1; i >= 1; i-- )
>      {
> +        if ( !test_bit(i, module_map) )
> +            continue;
> +
>          _policy_start = bootstrap_map(mod + i);
>          _policy_len   = mod[i].mod_end;
>  
> @@ -50,8 +54,7 @@ int xsm_policy_init(unsigned int *initrd
>              printk("Policy len  0x%lx, start at %p.\n",
>                     _policy_len,_policy_start);
>  
> -            if ( i == 1 )
> -                *initrdidx = (mbi->mods_count > 2) ? 2 : 0;
> +            __clear_bit(i, module_map);
>              break;
>  
>          }
> 
> 

> x86/microcode: enable boot time (pre-Dom0) loading
> 
> Largely as a result of the continuing resistance of Linux maintainers
> to accept a microcode loading patch for pv-ops Xen kernels, this
> follows the suggested route and provides a means to load microcode
> updates without the assistance of Dom0, thus also addressing eventual
> problems in the hardware much earlier.
> 
> This leverages the fact that via the multiboot protocol another blob
> of data can be easily added in the form of just an extra module. Since
> microcode data cannot reliably be recognized by looking at the
> provided data, this requires (in the non-EFI case) the use of a
> command line parameter ("ucode=<number>") to identify which of the
> modules is to be parsed for an eventual microcode update (in the EFI
> case the module is being identified in the config file, and hence the
> command line argument, if given, will be ignored).
> 
> This required to adjust the XSM module determination logic accordingly.
> 
> The format of the data to be provided is the raw binary blob already
> used for AMD CPUs, and the output of the intel-microcode2ucode utility
> for the Intel case (either the per-(family,model,stepping) file or -
> to make things easier for distro-s integration-wise - simply the
> concatenation of all of them).
> 
> In order to not convert the spin_lock() in microcode_update_cpu() (and
> then obviously also all other uses on microcode_mutex) to
> spin_lock_irqsave() (which would be undesirable for the hypercall
> context in which the function also runs), the boot time handling gets
> done using a tasklet (instead of using on_selected_cpus()).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/efi/boot.c
> +++ b/xen/arch/x86/efi/boot.c
> @@ -49,6 +49,7 @@ static UINT32 __initdata mdesc_ver;
>  static struct file __initdata cfg;
>  static struct file __initdata kernel;
>  static struct file __initdata ramdisk;
> +static struct file __initdata ucode;
>  static struct file __initdata xsm;
>  
>  static multiboot_info_t __initdata mbi = {
> @@ -174,6 +175,8 @@ static void __init __attribute__((__nore
>          efi_bs->FreePages(kernel.addr, PFN_UP(kernel.size));
>      if ( ramdisk.addr )
>          efi_bs->FreePages(ramdisk.addr, PFN_UP(ramdisk.size));
> +    if ( ucode.addr )
> +        efi_bs->FreePages(ucode.addr, PFN_UP(ucode.size));
>      if ( xsm.addr )
>          efi_bs->FreePages(xsm.addr, PFN_UP(xsm.size));
>  
> @@ -806,6 +809,17 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>          efi_bs->FreePool(name.w);
>      }
>  
> +    name.s = get_value(&cfg, section.s, "ucode");
> +    if ( !name.s )
> +        name.s = get_value(&cfg, "global", "ucode");
> +    if ( name.s )
> +    {
> +        microcode_set_module(mbi.mods_count);
> +        split_value(name.s);
> +        read_file(dir_handle, s2w(&name), &ucode);
> +        efi_bs->FreePool(name.w);
> +    }
> +
>      name.s = get_value(&cfg, section.s, "xsm");
>      if ( name.s )
>      {
> --- a/xen/arch/x86/microcode.c
> +++ b/xen/arch/x86/microcode.c
> @@ -29,13 +29,49 @@
>  #include <xen/notifier.h>
>  #include <xen/sched.h>
>  #include <xen/smp.h>
> +#include <xen/softirq.h>
>  #include <xen/spinlock.h>
> +#include <xen/tasklet.h>
>  #include <xen/guest_access.h>
>  
>  #include <asm/msr.h>
>  #include <asm/processor.h>
> +#include <asm/setup.h>
>  #include <asm/microcode.h>
>  
> +static module_t __initdata ucode_mod;
> +static void *(*__initdata ucode_mod_map)(const module_t *);
> +static unsigned int __initdata ucode_mod_idx;
> +static bool_t __initdata ucode_mod_forced;
> +static cpumask_t __initdata init_mask;
> +
> +void __init microcode_set_module(unsigned int idx)
> +{
> +    ucode_mod_idx = idx;
> +    ucode_mod_forced = 1;
> +}
> +
> +static void __init parse_ucode(char *s)
> +{
> +    if ( !ucode_mod_forced )
> +        ucode_mod_idx = simple_strtoul(s, NULL, 0);
> +}
> +custom_param("ucode", parse_ucode);
> +
> +void __init microcode_grab_module(
> +    unsigned long *module_map,
> +    const multiboot_info_t *mbi,
> +    void *(*map)(const module_t *))
> +{
> +    module_t *mod = (module_t *)__va(mbi->mods_addr);
> +
> +    if ( !ucode_mod_idx || ucode_mod_idx >= mbi->mods_count ||
> +         !__test_and_clear_bit(ucode_mod_idx, module_map) )
> +        return;
> +    ucode_mod = mod[ucode_mod_idx];
> +    ucode_mod_map = map;
> +}
> +
>  const struct microcode_ops *microcode_ops;
>  
>  static DEFINE_SPINLOCK(microcode_mutex);
> @@ -183,6 +219,41 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> +static void __init _do_microcode_update(unsigned long data)
> +{
> +    microcode_update_cpu((void *)data, ucode_mod.mod_end);
> +    cpumask_set_cpu(smp_processor_id(), &init_mask);
> +}
> +
> +static int __init microcode_init(void)
> +{
> +    void *data;
> +    static struct tasklet __initdata tasklet;
> +    unsigned int cpu;
> +
> +    if ( !microcode_ops || !ucode_mod.mod_end )
> +        return 0;
> +
> +    data = ucode_mod_map(&ucode_mod);
> +    if ( !data )
> +        return -ENOMEM;
> +
> +    softirq_tasklet_init(&tasklet, _do_microcode_update, (unsigned long)data);
> +
> +    for_each_online_cpu ( cpu )
> +    {
> +        tasklet_schedule_on_cpu(&tasklet, cpu);
> +        do {
> +            process_pending_softirqs();
> +        } while ( !cpumask_test_cpu(cpu, &init_mask) );
> +    }
> +
> +    ucode_mod_map(NULL);
> +
> +    return 0;
> +}
> +__initcall(microcode_init);
> +
>  static int microcode_percpu_callback(
>      struct notifier_block *nfb, unsigned long action, void *hcpu)
>  {
> @@ -205,7 +276,20 @@ static struct notifier_block microcode_p
>  static int __init microcode_presmp_init(void)
>  {
>      if ( microcode_ops )
> +    {
> +        if ( ucode_mod.mod_end )
> +        {
> +            void *data = ucode_mod_map(&ucode_mod);
> +
> +            if ( data )
> +                microcode_update_cpu(data, ucode_mod.mod_end);
> +
> +            ucode_mod_map(NULL);
> +        }
> +
>          register_cpu_notifier(&microcode_percpu_nfb);
> +    }
> +
>      return 0;
>  }
>  presmp_initcall(microcode_presmp_init);
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -550,10 +550,10 @@ void __init __start_xen(unsigned long mb
>  {
>      char *memmap_type = NULL;
>      char *cmdline, *kextra, *loader;
> -    unsigned int initrdidx = 1;
> +    unsigned int initrdidx;
>      multiboot_info_t *mbi = __va(mbi_p);
>      module_t *mod = (module_t *)__va(mbi->mods_addr);
> -    unsigned long nr_pages, modules_headroom;
> +    unsigned long nr_pages, modules_headroom, *module_map;
>      int i, j, e820_warn = 0, bytes = 0;
>      bool_t acpi_boot_table_init_done = 0;
>      struct ns16550_defaults ns16550 = {
> @@ -1229,7 +1229,13 @@ void __init __start_xen(unsigned long mb
>  
>      init_IRQ();
>  
> -    xsm_init(&initrdidx, mbi, bootstrap_map);
> +    module_map = xmalloc_array(unsigned long, BITS_TO_LONGS(mbi->mods_count));
> +    bitmap_fill(module_map, mbi->mods_count);
> +    __clear_bit(0, module_map); /* Dom0 kernel is always first */
> +
> +    xsm_init(module_map, mbi, bootstrap_map);
> +
> +    microcode_grab_module(module_map, mbi, bootstrap_map);
>  
>      timer_init();
>  
> @@ -1356,6 +1362,12 @@ void __init __start_xen(unsigned long mb
>      if ( xen_cpuidle )
>          xen_processor_pmbits |= XEN_PROCESSOR_PM_CX;
>  
> +    initrdidx = find_first_bit(module_map, mbi->mods_count);
> +    if ( bitmap_weight(module_map, mbi->mods_count) > 1 )
> +        printk(XENLOG_WARNING
> +               "Multiple initrd candidates, picking module #%u\n",
> +               initrdidx);
> +
>      /*
>       * We're going to setup domain0 using the module(s) that we stashed safely
>       * above our heap. The second module, if present, is an initrd ramdisk.
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -598,6 +598,7 @@ int cpuid_hypervisor_leaves( uint32_t id
>  int rdmsr_hypervisor_regs(uint32_t idx, uint64_t *val);
>  int wrmsr_hypervisor_regs(uint32_t idx, uint64_t val);
>  
> +void microcode_set_module(unsigned int);
>  int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len);
>  int microcode_resume_cpu(int cpu);
>  
> --- a/xen/include/asm-x86/setup.h
> +++ b/xen/include/asm-x86/setup.h
> @@ -44,4 +44,7 @@ void discard_initial_images(void);
>  int xen_in_range(unsigned long mfn);
>  void arch_get_xen_caps(xen_capabilities_info_t *info);
>  
> +void microcode_grab_module(
> +    unsigned long *, const multiboot_info_t *, void *(*)(const module_t *));
> +
>  #endif
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -454,14 +454,15 @@ static inline long __do_xsm_op (XEN_GUES
>  }
>  
>  #ifdef XSM_ENABLE
> -extern int xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *));
> -extern int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +extern int xsm_policy_init(unsigned long *module_map,
> +                           const multiboot_info_t *mbi,
>                             void *(*bootstrap_map)(const module_t *));
>  extern int register_xsm(struct xsm_operations *ops);
>  extern int unregister_xsm(struct xsm_operations *ops);
>  #else
> -static inline int xsm_init (unsigned int *initrdidx,
> +static inline int xsm_init (unsigned long *module_map,
>                              const multiboot_info_t *mbi,
>                              void *(*bootstrap_map)(const module_t *))
>  {
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -43,7 +43,7 @@ static void __init do_xsm_initcalls(void
>      }
>  }
>  
> -int __init xsm_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +int __init xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *))
>  {
>      int ret = 0;
> @@ -52,7 +52,7 @@ int __init xsm_init(unsigned int *initrd
>  
>      if ( XSM_MAGIC )
>      {
> -        ret = xsm_policy_init(initrdidx, mbi, bootstrap_map);
> +        ret = xsm_policy_init(module_map, mbi, bootstrap_map);
>          if ( ret )
>          {
>              bootstrap_map(NULL);
> --- a/xen/xsm/xsm_policy.c
> +++ b/xen/xsm/xsm_policy.c
> @@ -20,11 +20,12 @@
>  
>  #include <xsm/xsm.h>
>  #include <xen/multiboot.h>
> +#include <asm/bitops.h>
>  
>  char *__initdata policy_buffer = NULL;
>  u32 __initdata policy_size = 0;
>  
> -int xsm_policy_init(unsigned int *initrdidx, const multiboot_info_t *mbi,
> +int xsm_policy_init(unsigned long *module_map, const multiboot_info_t *mbi,
>                      void *(*bootstrap_map)(const module_t *))
>  {
>      int i;
> @@ -35,10 +36,13 @@ int xsm_policy_init(unsigned int *initrd
>  
>      /*
>       * Try all modules and see whichever could be the binary policy.
> -     * Adjust the initrdidx if module[1] is the binary policy.
> +     * Adjust module_map for the module that is the binary policy.
>       */
>      for ( i = mbi->mods_count-1; i >= 1; i-- )
>      {
> +        if ( !test_bit(i, module_map) )
> +            continue;
> +
>          _policy_start = bootstrap_map(mod + i);
>          _policy_len   = mod[i].mod_end;
>  
> @@ -50,8 +54,7 @@ int xsm_policy_init(unsigned int *initrd
>              printk("Policy len  0x%lx, start at %p.\n",
>                     _policy_len,_policy_start);
>  
> -            if ( i == 1 )
> -                *initrdidx = (mbi->mods_count > 2) ? 2 : 0;
> +            __clear_bit(i, module_map);
>              break;
>  
>          }

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:26:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:26:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVsbD-0006EP-WE; Wed, 30 Nov 2011 22:25:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVsbC-0006E6-Ba
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 22:25:54 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322691913!3757707!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15774 invoked from network); 30 Nov 2011 22:25:15 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 22:25:15 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAUMPCU0017046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 17:25:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAUMPCHm017044;
	Wed, 30 Nov 2011 17:25:12 -0500
Date: Wed, 30 Nov 2011 18:25:12 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111130222512.GD16651@andromeda.dapyr.net>
References: <4ED6670C02000078000646B4@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED6670C02000078000646B4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/2] x86: microcode fixes and improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 04:25:32PM +0000, Jan Beulich wrote:
> 1: x86: consolidate microcode loading code
> 2: x86/microcode: enable boot time (pre-Dom0) loading


Yeeeey!
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:26:18 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:26:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVsbD-0006EP-WE; Wed, 30 Nov 2011 22:25:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVsbC-0006E6-Ba
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 22:25:54 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1322691913!3757707!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15774 invoked from network); 30 Nov 2011 22:25:15 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 22:25:15 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAUMPCU0017046
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 17:25:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAUMPCHm017044;
	Wed, 30 Nov 2011 17:25:12 -0500
Date: Wed, 30 Nov 2011 18:25:12 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20111130222512.GD16651@andromeda.dapyr.net>
References: <4ED6670C02000078000646B4@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED6670C02000078000646B4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0/2] x86: microcode fixes and improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 04:25:32PM +0000, Jan Beulich wrote:
> 1: x86: consolidate microcode loading code
> 2: x86/microcode: enable boot time (pre-Dom0) loading


Yeeeey!
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:27:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVscZ-0006Kc-G1; Wed, 30 Nov 2011 22:27:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVscY-0006K6-3W
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 22:27:18 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322691997!5387240!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20921 invoked from network); 30 Nov 2011 22:26:38 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 22:26:38 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAUMQWfi017101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 17:26:32 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAUMQTi4017099;
	Wed, 30 Nov 2011 17:26:29 -0500
Date: Wed, 30 Nov 2011 18:26:29 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Niall Fleming <niall.fleming@webanywhere.co.uk>
Message-ID: <20111130222628.GE16651@andromeda.dapyr.net>
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>
	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
	<4ED662B0.8060105@webanywhere.co.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED662B0.8060105@webanywhere.co.uk>
User-Agent: Mutt/1.5.9i
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	keir.xen@gmail.com, Jan Beulich <JBeulich@suse.com>,
	pbonzini@redhat.com, lersek@redhat.com
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 05:06:56PM +0000, Niall Fleming wrote:
> Another week, and no response?

I am sooo tempted to make a time joke :-)
> 
> ping?

We are just swamped. <sigh> Wish I had a better response,
like: Try this patch, but not yet.

> 
> Please?
> 
> *Niall Fleming BSc. (Hons)*
> Systems Administrator
> Webanywhere Limited
> 
> Phone: 0800 862 0131 Ext: 203
> Web: http://www.webanywhere.co.uk
> 
> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
> Registered in England with company number 4881346
> 
> On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> >On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
> >>On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
> >>>Right. With those patches too (he used the xen-settime patch set which 
> >>>has it).
> >>>The hypercall is done (and the do_settime gets called) and the results 
> >>>are saved
> >>>in the RTC. And the wc_sec and wc_nsec are updated and propagated.
> >>>
> >>>The problem is that wc_sec and wc_nsec are only propagated to the
> >>>existing guests.
> >>>
> >>>If you launch a new guest after the 'hwclock', the new guests
> >>>retains the old wallclock time.
> >>Existing (pvops) guests shouldn't see updated wallclock time, because
> >>they never look at the hypervisor's wallclock after boot time.
> >>
> >>It's surprising that new guests don't see the updated wallclock though.
> >>That sounds like a Xen issue.
> ><nods>  That is what I think is happening here.
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xensource.com
> >http://lists.xensource.com/xen-devel

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:27:40 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:27:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVscZ-0006Kc-G1; Wed, 30 Nov 2011 22:27:19 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1RVscY-0006K6-3W
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 22:27:18 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1322691997!5387240!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20921 invoked from network); 30 Nov 2011 22:26:38 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Nov 2011 22:26:38 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	pAUMQWfi017101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 30 Nov 2011 17:26:32 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id pAUMQTi4017099;
	Wed, 30 Nov 2011 17:26:29 -0500
Date: Wed, 30 Nov 2011 18:26:29 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Niall Fleming <niall.fleming@webanywhere.co.uk>
Message-ID: <20111130222628.GE16651@andromeda.dapyr.net>
References: <4EBD5AA0.3090906@webanywhere.co.uk>
	<20111111183913.GA9283@phenom.dumpdata.com>
	<4EC0F20D0200007800060B7D@nat28.tlf.novell.com>
	<20111114180045.GA14517@phenom.dumpdata.com>
	<4EC16CA7.70901@goop.org>
	<20111116142604.GA7476@phenom.dumpdata.com>
	<4ED662B0.8060105@webanywhere.co.uk>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4ED662B0.8060105@webanywhere.co.uk>
User-Agent: Mutt/1.5.9i
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	keir.xen@gmail.com, Jan Beulich <JBeulich@suse.com>,
	pbonzini@redhat.com, lersek@redhat.com
Subject: Re: [Xen-devel] Time Change Issue Xen 4.1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Nov 30, 2011 at 05:06:56PM +0000, Niall Fleming wrote:
> Another week, and no response?

I am sooo tempted to make a time joke :-)
> 
> ping?

We are just swamped. <sigh> Wish I had a better response,
like: Try this patch, but not yet.

> 
> Please?
> 
> *Niall Fleming BSc. (Hons)*
> Systems Administrator
> Webanywhere Limited
> 
> Phone: 0800 862 0131 Ext: 203
> Web: http://www.webanywhere.co.uk
> 
> Aire Valley Business Centre, Lawkholme Lane, Keighley, BD21 3BB
> Registered in England with company number 4881346
> 
> On 16/11/2011 14:26, Konrad Rzeszutek Wilk wrote:
> >On Mon, Nov 14, 2011 at 11:31:51AM -0800, Jeremy Fitzhardinge wrote:
> >>On 11/14/2011 10:00 AM, Konrad Rzeszutek Wilk wrote:
> >>>Right. With those patches too (he used the xen-settime patch set which 
> >>>has it).
> >>>The hypercall is done (and the do_settime gets called) and the results 
> >>>are saved
> >>>in the RTC. And the wc_sec and wc_nsec are updated and propagated.
> >>>
> >>>The problem is that wc_sec and wc_nsec are only propagated to the
> >>>existing guests.
> >>>
> >>>If you launch a new guest after the 'hwclock', the new guests
> >>>retains the old wallclock time.
> >>Existing (pvops) guests shouldn't see updated wallclock time, because
> >>they never look at the hypervisor's wallclock after boot time.
> >>
> >>It's surprising that new guests don't see the updated wallclock though.
> >>That sounds like a Xen issue.
> ><nods>  That is what I think is happening here.
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xensource.com
> >http://lists.xensource.com/xen-devel

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:52:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVt0v-0006je-1t; Wed, 30 Nov 2011 22:52:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVt0t-0006jW-4p
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 22:52:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322693507!5367840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29423 invoked from network); 30 Nov 2011 22:51:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 22:51:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,273,1320624000"; 
   d="scan'208";a="9218261"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 22:51:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 22:51:47 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVt0E-0006Cp-Sm;
	Wed, 30 Nov 2011 22:51:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVt0E-0006qi-Ry;
	Wed, 30 Nov 2011 22:51:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10192-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 22:51:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10192: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10192 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10192/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate        fail REGR. vs. 10190

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   like 10190
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  3c4c29899d8a
baseline version:
 xen                  64088ba60263

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <maillists.shan@gmail.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24271:3c4c29899d8a
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 07:18:11 2011 -0800
    
    hvmloader: Write address of VM generation id buffer into xenstore
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24270:08716a7f1b74
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 30 07:12:41 2011 -0800
    
    Free d->mem_event on domain destruction.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24269:2cbc53a24683
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Nov 30 07:08:53 2011 -0800
    
    mem_event: move mem_event_domain out of struct domain
    
    An upcoming change may increase the size of mem_event_domain. The result
    is a build failure because struct domain gets larger than a page.
    Allocate the room for the three mem_event_domain members at runtime.
    
    v2:
     - remove mem_ prefix from members of new struct
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24268:31f751ef3e00
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Wed Nov 30 07:06:24 2011 -0800
    
    x86/hvm/vmx: Trace traps and realmode exits
    
    Add some more tracing to vmexits that don't currently have
    trace information:
     * VMX realmode emulation
     * Various VMX traps
     * Fast-pathed APIC accesses
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24267:77421dbd4871
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:57:20 2011 -0800
    
    hvmloader: Add xenstore-write support
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24266:295337e5d4e0
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:55:31 2011 -0800
    
    hvmloader: Add snprintf()
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24265:54a9e172a373
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:53:36 2011 -0800
    
    hvmloader: Allocate an 8 byte buffer to contain the VM generation id
    and populate it at boot time with a value read from
    "platform/generation_id". Also add code to libxl to populate this
    xenstore key with the value of a new 'generation_id' parameter in the
    VM config file.  Populate the ADDR package of VM_Gen_Counter ACPI
    device such that the first integer evaluates to the low order 32 bits
    of the buffer address and the second integer evaluates to the high
    order 32 bits of the buffer address.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24264:e925e4719844
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:50:45 2011 -0800
    
    hvmloader: Add 'ctype' infrastructure
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24263:e5a53cdd4252
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:47:16 2011 -0800
    
    hvmloader: Add an ACPI device exposing a package called ADDR,
    evaluating to two integers, and with _CID and _DDN set to
    "VM_Gen_Counter".
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24262:67c447c02537
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:42:04 2011 -0800
    
    x86/hvm: Re-instate HVM IRQ debug code and add keyhandler.
    
    I found this patch useful a couple of times while trying to debug the
    viridian problem.  irq_dump() was #ifdef-ed out so this patch puts it
    back and registers a handler on the 'I' key to iterate over all HVM
    domains and call it.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24261:64088ba60263
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Nov 30 10:23:41 2011 +0100
    
    x86/cpuidle: add Westmere-EX support to hw residencies reading logic
    
    This is in accordance with
    http://software.intel.com/en-us/articles/intel-processor-identification-with-cpuid-model-and-family-numbers/
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Haitao Shan <maillists.shan@gmail.com>
    
    
========================================
commit 89daacab7035d408f32f2cb1acf68c96d6cbefed
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Nov 28 17:16:52 2011 +0000

    qemu-dm: open char devices "file:..." with O_APPEND
    
    The "file:..." character open method is used by serial and parallel
    ports, to divert the output to a file (and these devices never produce
    any input).  This is like a logfile, and so should be opened for
    append.
    
    In qemu-xen-unstable, this is used only for the qemu stderr by libxl.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 22:52:54 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 22:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVt0v-0006je-1t; Wed, 30 Nov 2011 22:52:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RVt0t-0006jW-4p
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 22:52:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1322693507!5367840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OQ==\n
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29423 invoked from network); 30 Nov 2011 22:51:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 22:51:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,273,1320624000"; 
   d="scan'208";a="9218261"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Nov 2011 22:51:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 30 Nov 2011 22:51:47 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RVt0E-0006Cp-Sm;
	Wed, 30 Nov 2011 22:51:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RVt0E-0006qi-Ry;
	Wed, 30 Nov 2011 22:51:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10192-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 30 Nov 2011 22:51:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10192: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 10192 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10192/

Regressions :-(

Tests which did not succeed and are blocking:
 test-amd64-amd64-xl-sedf     11 guest-localmigrate        fail REGR. vs. 10190

Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-i386-xl-win7-amd64  7 windows-install              fail  never pass
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win7-amd64  7 windows-install              fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-win           14 guest-start.2                fail   like 10190
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  3c4c29899d8a
baseline version:
 xen                  64088ba60263

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <maillists.shan@gmail.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   24271:3c4c29899d8a
tag:         tip
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 07:18:11 2011 -0800
    
    hvmloader: Write address of VM generation id buffer into xenstore
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24270:08716a7f1b74
user:        Keir Fraser <keir@xen.org>
date:        Wed Nov 30 07:12:41 2011 -0800
    
    Free d->mem_event on domain destruction.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24269:2cbc53a24683
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Nov 30 07:08:53 2011 -0800
    
    mem_event: move mem_event_domain out of struct domain
    
    An upcoming change may increase the size of mem_event_domain. The result
    is a build failure because struct domain gets larger than a page.
    Allocate the room for the three mem_event_domain members at runtime.
    
    v2:
     - remove mem_ prefix from members of new struct
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24268:31f751ef3e00
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Wed Nov 30 07:06:24 2011 -0800
    
    x86/hvm/vmx: Trace traps and realmode exits
    
    Add some more tracing to vmexits that don't currently have
    trace information:
     * VMX realmode emulation
     * Various VMX traps
     * Fast-pathed APIC accesses
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24267:77421dbd4871
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:57:20 2011 -0800
    
    hvmloader: Add xenstore-write support
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24266:295337e5d4e0
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:55:31 2011 -0800
    
    hvmloader: Add snprintf()
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24265:54a9e172a373
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:53:36 2011 -0800
    
    hvmloader: Allocate an 8 byte buffer to contain the VM generation id
    and populate it at boot time with a value read from
    "platform/generation_id". Also add code to libxl to populate this
    xenstore key with the value of a new 'generation_id' parameter in the
    VM config file.  Populate the ADDR package of VM_Gen_Counter ACPI
    device such that the first integer evaluates to the low order 32 bits
    of the buffer address and the second integer evaluates to the high
    order 32 bits of the buffer address.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24264:e925e4719844
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:50:45 2011 -0800
    
    hvmloader: Add 'ctype' infrastructure
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24263:e5a53cdd4252
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:47:16 2011 -0800
    
    hvmloader: Add an ACPI device exposing a package called ADDR,
    evaluating to two integers, and with _CID and _DDN set to
    "VM_Gen_Counter".
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24262:67c447c02537
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Wed Nov 30 06:42:04 2011 -0800
    
    x86/hvm: Re-instate HVM IRQ debug code and add keyhandler.
    
    I found this patch useful a couple of times while trying to debug the
    viridian problem.  irq_dump() was #ifdef-ed out so this patch puts it
    back and registers a handler on the 'I' key to iterate over all HVM
    domains and call it.
    
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24261:64088ba60263
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Nov 30 10:23:41 2011 +0100
    
    x86/cpuidle: add Westmere-EX support to hw residencies reading logic
    
    This is in accordance with
    http://software.intel.com/en-us/articles/intel-processor-identification-with-cpuid-model-and-family-numbers/
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Haitao Shan <maillists.shan@gmail.com>
    
    
========================================
commit 89daacab7035d408f32f2cb1acf68c96d6cbefed
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Mon Nov 28 17:16:52 2011 +0000

    qemu-dm: open char devices "file:..." with O_APPEND
    
    The "file:..." character open method is used by serial and parallel
    ports, to divert the output to a file (and these devices never produce
    any input).  This is like a logfile, and so should be opened for
    append.
    
    In qemu-xen-unstable, this is used only for the qemu stderr by libxl.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:11:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtIY-0006yL-Sn; Wed, 30 Nov 2011 23:10:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.baruchi@gmail.com>)
	id 1RVtIW-0006yD-Uv; Wed, 30 Nov 2011 23:10:41 +0000
X-Env-Sender: mail.baruchi@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322694599!5389158!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5061 invoked from network); 30 Nov 2011 23:10:00 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 23:10:00 -0000
Received: by vbbfq11 with SMTP id fq11so2037811vbb.30
	for <multiple recipients>; Wed, 30 Nov 2011 15:09:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Af54gA+KUGDRpa165kJkC81TkhsUqn2ctUs7iBapZcE=;
	b=LMyqvD+uqEbnFyJN5GnJTfH3vjX1eu3LsE+hYA6hR4nZM9oZWrITuCxwfr+a4XjUAS
	ngWGtlKRPyK8HHbtt2eszZrYpKsj+4wjGTy6Ei/f9eEg0WOR4S009pach37lISKtQaXu
	69aGFdOamlVFYt/TP6CCx0WvdiaWeO9xuPB90=
MIME-Version: 1.0
Received: by 10.52.68.79 with SMTP id u15mr3958257vdt.5.1322694598457; Wed, 30
	Nov 2011 15:09:58 -0800 (PST)
Received: by 10.52.187.4 with HTTP; Wed, 30 Nov 2011 15:09:58 -0800 (PST)
In-Reply-To: <20111130221545.GB16651@andromeda.dapyr.net>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
	<20111130221545.GB16651@andromeda.dapyr.net>
Date: Wed, 30 Nov 2011 21:09:58 -0200
Message-ID: <CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
From: Artur Baruchi <mail.baruchi@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Xen-devel@lists.xensource.com, xen-users <Xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Konrad.

That was my first though (disk going bad). But I create another VM in
a different host and faced the same error. I tried to create another
file and use a physical device (logical volume) too, but no lucky. Im
guessing that it can be:

- There is a bug in this kernel version or in paravirtualized drivers
used by opensuse 11.3 (based on some google searchs that I made, with
similar errors); OR
- Some configuration problem (for example, need to enable acpi in my
vm kernel, or anything like this).

Thanks.

Att.
Artur Baruchi


On Wed, Nov 30, 2011 at 8:15 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Wed, Nov 30, 2011 at 04:46:55PM -0200, Artur Baruchi wrote:
>> I just configured the serial console to see what is going on during
>> the boot. I tried to run fsck and changed the grub to use the device
>> path (/dev/sdaX) instead udisks-part-id, but no success.
>>
>> Follow the console errors:
>>
>
> That looks like your disk is going bad?
>
> Was there anything before this? Like the IRQs not setup properly?
>
>> Loading drivers, configuring devices: [ =A0 69.701448] ata1.00:
>> exception Emask 0x0 SAct 0x0 SErr 0x0 act
>> =A0ion 0x6 frozen
>> [ =A0 69.705706] ata1.00: failed command: READ DMA
>> [ =A0 69.708402] ata1.00: cmd c8/00:20:b8:7a:66/00:00:00:00:00/e0 tag 0
>> dma 16384 in
>> [ =A0 69.708403] =A0 =A0 =A0 =A0 =A0res 40/00:01:00:00:00/00:00:00:00:00=
/a0 Emask
>> 0x4 (timeout)
>> [ =A0 69.717358] ata1.00: status: { DRDY }
>> [ =A0 69.872400] ata1.00: revalidation failed (errno=3D-2)
>> [ =A0 75.023385] ata1.00: revalidation failed (errno=3D-2)
>> [ =A0 80.174383] ata1.00: revalidation failed (errno=3D-2)
>> [ =A0 80.329687] end_request: I/O error, dev sda, sector 6716088
>> [ =A0 80.333096] end_request: I/O error, dev sda, sector 6716088
>> [ =A0 80.336676] end_request: I/O error, dev sda, sector 6716088
>> [ =A0 80.340408] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.344063] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.347465] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.351795] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.356081] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.359587] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.363115] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.366535] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.370034] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.373924] end_request: I/O error, dev sda, sector 9979920
>> [ =A0 80.377458] Buffer I/O error on device sda3, logical block 721410
>> [ =A0 80.389108] end_request: I/O error, dev sda, sector 4970504
>> [ =A0 80.392576] end_request: I/O error, dev sda, sector 4970504
>> [ =A0 80.396208] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.399747] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> [ =A0 80.406333] end_request: I/O error, dev sda, sector 4208640
>> [ =A0 80.409650] Buffer I/O error on device sda3, logical block 0
>> udevd-work[1631]: exec of program '/lib/udev/ata_id' failed
>>
>> [ =A0 80.416228] end_request: I/O error, dev sda, sector 6796224
>> [ =A0 80.419759] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.423135] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.425117] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.427447] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.429840] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.432094] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.434425] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.436746] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.439043] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.441358] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.443626] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.445864] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.448051] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.450271] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.452482] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.454745] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.457029] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.459299] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.461604] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.463843] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.466045] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.468274] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.470510] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.472725] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.474902] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.477103] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.479278] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.481514] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.483647] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.485780] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.487838] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.489897] end_request: I/O error, dev sda, sector 6796224
>> [ =A0 80.491920] end_request: I/O error, dev sda, sector 6796224
>> [ =A0 80.494294] end_request: I/O error, dev sda, sector 4971928
>> [ =A0 80.496445] end_request: I/O error, dev sda, sector 4971928
>> [ =A0 80.498650] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.500834] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> [ =A0 80.504930] end_request: I/O error, dev sda, sector 4208640
>> [ =A0 80.507019] Buffer I/O error on device sda3, logical block 0
>> udevd-work[1632]: exec of program '/lib/udev/scsi_id' failed
>>
>> [ =A0 80.511028] end_request: I/O error, dev sda, sector 12352272
>> [ =A0 80.513236] Buffer I/O error on device sda3, logical block 1017954
>> [ =A0 80.515677] end_request: I/O error, dev sda, sector 12360888
>> [ =A0 80.518021] Buffer I/O error on device sda3, logical block 1019031
>> [ =A0 80.520527] Buffer I/O error on device sda3, logical block 1019032
>> [ =A0 80.523072] end_request: I/O error, dev sda, sector 9980016
>> [ =A0 80.525394] journal_bmap: journal block not found at offset 12 on s=
da3
>> [ =A0 80.527956] Aborting journal on device sda3.
>> [ =A0 80.529854] end_request: I/O error, dev sda, sector 9979920
>> [ =A0 80.532119] Buffer I/O error on device sda3, logical block 721410
>> [ =A0 80.534799] end_request: I/O error, dev sda, sector 9979928
>> [ =A0 80.537239] end_request: I/O error, dev sda, sector 9979936
>> [ =A0 80.539639] end_request: I/O error, dev sda, sector 9370632
>> [ =A0 80.542144] end_request: I/O error, dev sda, sector 9370632
>> [ =A0 80.544499] EXT3-fs (sda3): error: ext3_journal_start_sb: Detected
>> aborted journal
>> [ =A0 80.547659] EXT3-fs (sda3): error: remounting filesystem read-only
>> [ =A0 80.550535] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.552989] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> udevd-work[1634]: exec of program '/sbin/blkid' failed
>>
>> [ =A0 80.559337] end_request: I/O error, dev sda, sector 4972560
>> [ =A0 80.561964] end_request: I/O error, dev sda, sector 4972560
>> [ =A0 80.564546] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.567069] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> udevd-work[1635]: exec of program '/lib/udev/edd_id' failed
>>
>> [ =A0 80.576377] end_request: I/O error, dev sda, sector 4952712
>> [ =A0 80.580086] end_request: I/O error, dev sda, sector 4952712
>> [ =A0 80.583689] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.586292] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> udevd-work[1636]: exec of program '/lib/udev/udisks-part-id' failed
>>
>> [ =A0 80.593995] end_request: I/O error, dev sda, sector 9370632
>> [ =A0 80.596704] end_request: I/O error, dev sda, sector 9370632
>> [ =A0 80.596755] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.596760] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> udevd-work[1637][ =A0 80.608632] end_request: I/O error, dev sda, sector=
 11290592
>> : exec of program '/sbin/blkid' failed[ =A0 80.612951] EXT3-fs error
>> (device sda3): ext3_get_inode_loc: u
>> nable to read inode block - inode=3D223126, block=3D885244
>>
>>
>> [ =A0 80.621449] end_request: I/O error, dev sda, sector 9370632
>> [ =A0 80.624665] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.627305] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> udevd-work[1638]: exec of program '/sbin/blkid' failed
>>
>> udevd-work[1639]: exec of program '/sbin/blkid' failed
>>
>> [ =A0 80.635017] end_request: I/O error, dev sda, sector 4952712
>> [ =A0 80.637899] end_request: I/O error, dev sda, sector 4952712
>> [ =A0 80.637956] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.637962] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> [ =A0 80.649954] end_request: I/O error, dev sda, sector 4952712
>> udevd-work[1640]: exec of program '/lib/udev/udi[ =A0 80.649974]
>> end_request: I/O error, dev sda, sector
>> 11290592
>> sks-part-id' failed
>> [ =A0 80.649981] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>>
>> udevd-work[1641][ =A0 80.664921] end_request: I/O error, dev sda, sector=
 11290592
>> : exec of program '/lib/udev/udisks-part-id' fai[ =A0 80.669088] EXT3-fs
>> error (device sda3): ext3_get_in
>> ode_loc: ledunable to read inode block - inode=3D223126, block=3D885244
>>
>>
>> udevd-work[1642]: exec of program '/lib/udev/udisks-part-id' failed
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 done
>> [ =A0 80.688649] end_request: I/O error, dev sda, sector 11516760
>> [ =A0 80.693402] end_request: I/O error, dev sda, sector 11517320
>> [ =A0 80.698410] end_request: I/O error, dev sda, sector 11516760
>> boot.loadmodules: Input/output error
>> [ =A0 80.705752] end_request: I/O error, dev sda, sector 11517320
>> boot.rootfsck: Input/output error
>> [ =A0 80.712719] end_request: I/O error, dev sda, sector 11516496
>> [ =A0 80.717814] end_request: I/O error, dev sda, sector 11516704
>> [ =A0 80.730101] end_request: I/O error, dev sda, sector 11516496
>> boot.clock: Input/output error
>> [ =A0 80.736217] end_request: I/O error, dev sda, sector 11516768
>> [ =A0 80.741296] end_request: I/O error, dev sda, sector 11352104
>> [ =A0 80.745949] end_request: I/O error, dev sda, sector 11352104
>> boot.device-mapper: Input/output error
>> [ =A0 80.753208] end_request: I/O error, dev sda, sector 11516768
>> boot.localfs: Input/output error
>> [ =A0 80.760052] end_request: I/O error, dev sda, sector 11516488
>> [ =A0 80.764909] end_request: I/O error, dev sda, sector 11499608
>> [ =A0 80.769502] end_request: I/O error, dev sda, sector 11303224
>> [ =A0 80.775085] end_request: I/O error, dev sda, sector 11516744
>> [ =A0 80.779703] end_request: I/O error, dev sda, sector 11517168
>> [ =A0 80.784166] end_request: I/O error, dev sda, sector 11517360
>> [ =A0 80.788596] end_request: I/O error, dev sda, sector 11518640
>> [ =A0 80.793861] end_request: I/O error, dev sda, sector 11518640
>> [ =A0 80.798273] end_request: I/O error, dev sda, sector 11517360
>> [ =A0 80.803364] end_request: I/O error, dev sda, sector 11517176
>> boot.swap: Input/output error
>> [ =A0 80.809435] end_request: I/O error, dev sda, sector 11517168
>> boot.proc: Input/output error
>> [ =A0 80.815339] end_request: I/O error, dev sda, sector 11516488
>> boot.localnet: Input/output error[ =A0 80.820846] end_request: I/O
>> error, dev sda, sector 11516744
>> [ =A0 80.825458] end_request: I/O error, dev sda, sector 11499608
>> [ =A0 80.829771] end_request: I/O error, dev sda, sector 11303224
>> [ =A0 80.834086] end_request: I/O error, dev sda, sector 11516752
>>
>> boot.cleanup: In[ =A0 80.838667] end_request: I/O error, dev sda, sector=
 11518160
>> put/output error[ =A0 80.843568] end_request: I/O error, dev sda, sector=
 11516752
>>
>> [ =A0 80.847792] end_request: I/O error, dev sda, sector 11518160
>> boot.cycle: Input/output error[ =A0 80.853141] end_request: I/O error,
>> dev sda, sector 11417656
>>
>> [ =A0 80.853840] end_request: I/O error, dev sda, sector 11417656
>> boot.fuse: Input/output error
>> boot.klog: Input/output error
>> boot.sysctl: Input/output error
>> [ =A0 80.865148] end_request: I/O error, dev sda, sector 11516712
>> [ =A0 80.865199] end_request: I/O error, dev sda, sector 11516712
>> boot.ldconfig: Input/output error
>> boot.udev_retry: Input/output error
>> boot.apparmor: Input/output error
>> boot.ipconfig: Input/output error
>> System Boot Control: The system has been =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0set up
>> Failed features: boot.loadmodules boot.rootfsck boot.clock
>> boot.device-mapper boot.localfs boot.cleanup
>> =A0 =A0 =A0boot.cycle boot.fuse boot.klog boot.localnet boot.proc boot.s=
wap
>> boot.sysctl boot.ldconfig boot.udev_r
>> etry boot.apparmor boot.ipconfig
>> System Boot Control: Running /etc/init.d/boot.local
>> [ =A0 80.890020] end_request: I/O error, dev sda, sector 11540760
>> [ =A0 80.892185] end_request: I/O error, dev sda, sector 11540760
>> /etc/init.d/boot.local: /etc/init.d/boot.local: Input/output error =A0 =
=A0failed
>> [ =A0 80.897735] end_request: I/O error, dev sda, sector 9369944
>> [ =A0 80.900025] end_request: I/O error, dev sda, sector 9369944
>> [ =A0 80.902265] end_request: I/O error, dev sda, sector 9369944
>> /etc/init.d/boot: line 314: /sbin/killproc: Input/output error
>> /etc/init.d/boot: line 326: /var/run/no_blogd: Read-only file system
>> [ =A0 80.909885] end_request: I/O error, dev sda, sector 12335128
>> [ =A0 80.913314] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2539 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 69,
>> block=3D1015811
>> [ =A0 80.920333] end_request: I/O error, dev sda, sector 12335128
>> [ =A0 80.923922] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2539 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 69,
>> block=3D1015811
>> [ =A0 80.931552] end_request: I/O error, dev sda, sector 12335128
>> [ =A0 80.935604] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2539 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 69,
>> block=3D1015811
>> [ =A0 80.944776] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.948819] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> INIT: Entering runlevel: 3
>> [ =A0 80.965451] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 80.969737] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 80.980514] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
>> 80.987414] end_request: I/O erro =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 r, dev
>> sda, sector 11519720
>>
>> [ =A0 80.991743] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript:[ =A0 80.996145] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/s[ =A0 81.005996] end_request: I/O error,
>> dev sda, sector 11519720
>> ysconfig/ulimit: Input/output er[ =A0 81.010510] end_request: I/O error,
>> dev sda, sector 11519720
>> ror[ =A0 81.016077] end_request: I/O error, dev sda, sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
>> 81.022320] end_request: I/O erro =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 r, dev
>> sda, sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript:[ =A0 81.030711] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit:[ =A0 81.035523] end_request: I/O erro=
r,
>> dev sda, sector 11519720
>> =A0Input/output error
>> /etc/initscript:[ =A0 81.043077] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit:[ =A0 81.047889] end_request: I/O erro=
r,
>> dev sda, sector 11519720
>> =A0Input/output error[ =A0 81.052231] end_request: I/O error, dev sda,
>> sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
>> 81.062739] end_request: I/O error, dev s
>> da, sector 11519720
>> ut error
>> [ =A0 81.066952] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.081287] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ =A0 81.087077]
>> end_request: I/O error, dev sda, sector
>> 11519720
>> =A0Input/output error
>> [ =A0 81.092828] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.097171] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
>> 81.105199] end_request: I/O error, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0dev
>> sda, sector 11519720
>> ror
>> /etc/initscript: line 77: /[ =A0 81.109861] end_request: I/O error, dev
>> sda, sector 11519720
>> etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input[ =A0 81.116079]
>> end_request: I/O error, dev sda, s =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 ector
>> 11519720
>> /output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/uli[ =A0 81.123656]
>> end_request: I/O error, dev sda, sector 1151
>> =A0 =A0 9720
>> mit: Input/output error
>> [ =A0 81.131077] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript:[ =A0 81.135256] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.145043] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
>> 81.151102] end_request: I/O erro =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 r, dev
>> sda, sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript:[ =A0 81.158246] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error[ =A0 81.163908]
>> end_request: I/O error, dev sda, sect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 or
>> 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript:[ =A0 81.170077] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.175614] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
>> 81.181692] end_request: I/O erro =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 r, dev
>> sda, sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.188834] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.193074] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ul[ =A0 81.202959] end_request:
>> I/O error, dev sda, sector 11519 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 720
>> imit: Input/output error
>> [ =A0 81.209078] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.215046] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ =A0 81.220029]
>> end_request: I/O error, dev sda, sector
>> 11519720
>> =A0Input/output error
>> /etc/initscript:[ =A0 81.224860] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error[ =A0 81.230950]
>> end_request: I/O error, dev sda, sect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 or
>> 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.241445] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.245133] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
>> 81.253519] end_request: I/O erro =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 r, dev
>> sda, sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
>> 81.259342] end_request: I/O error, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0dev
>> sda, sector 11519720
>> ror
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
>> 81.265077] end_request: I/O error, dev s
>> da, sector 11519720
>> ut error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sy[ =A0 81.271786] end_request: I/O
>> error, dev sda, sector 11519720
>> sconfig/ulimit: Input/output error
>> [ =A0 81.277066] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.284078] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.287740] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ =A0 81.292708]
>> end_request: I/O error, dev sda, sector
>> 11519720
>> =A0Input/output error[ =A0 81.298719] end_request: I/O error, dev sda,
>> sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript:[ =A0 81.304841] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.313187] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.324518] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.329435] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
>> 81.334830] end_request: I/O error, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0dev
>> sda, sector 11519720
>> ror
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line [ =A0 81.341698] end_request: I/O error, dev sda,
>> sector 11519720
>> 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> INIT: Id "6[ =A0 81.349010] end_request: I/O error, dev sda, sector 1151=
9720
>> " respawning too fast: disabled for 5 minutes
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
>> 81.355880] end_request: I/O error, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0dev
>> sda, sector 11519720
>> ror
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.363875] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
>> 81.369261] end_request: I/O error, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0dev
>> sda, sector 11519720
>> ror
>> INIT: Id "co" respawning too fast: disabled for 5 minutes
>> /etc/initscript: line 77: /etc[ =A0 81.376228] end_request: I/O error,
>> dev sda, sector 11519720
>> /sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> INI[ =A0 81.383188] end_request: I/O error, dev sda, sector 11519720
>> T: Id "3" respawning too fast: disabled for 5 minutes
>> /etc/initscript: line 77[ =A0 81.389244] end_request: I/O error, dev
>> sda, sector 11519720
>> : /etc/sysconfig/ulimit: Input/output error
>> INIT: Id "4" respawning too fast: disabled for 5 minutes
>> /etc/in[ =A0 81.395907] end_request: I/O error, dev sda, sector 11519720
>> itscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: I[ =A0 81.403341]
>> end_request: I/O error, dev sda, secto =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 r
>> 11519720
>> nput/output error
>> INIT: Id "5" respawning too fast: disabled for 5 minutes
>> /etc/initscript: [ =A0 81.410018] end_request: I/O error, dev sda, secto=
r 11519720
>> line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> INIT: Id "1" respawning too fast: disabled for 5 minutes
>> [ =A0 81.420725] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.430746] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.440664] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> INIT: Id "2" respawning too fast: disabled for 5 minutes
>> INIT: no more processes left in this runlevel
>>
>>
>>
>>
>> On Wed, Nov 30, 2011 at 11:48 AM, Artur Baruchi <mail.baruchi@gmail.com>=
 wrote:
>> > Hi.
>> >
>> > Im installing a VM to run a benchmark, Im able to install the VM issue
>> > the first boot (to setup network configurations), but if I reboot the
>> > VM it just hangs and do not boot. I've re-installed the machine but no
>> > success. Follow some details:
>> >
>> > - Dom0: Opensuse 11.3 (x86_64), kernel 2.6.34-12-xen,
>> > xen-4.0.0_21091_05-6.6.x86_64
>> > - DomU: Full Virtualization, Opensuse 11.3 (x86_64), kernel 2.6.34-12-=
desktop
>> >
>> > Some errors in message file (not sure that this errors mean something
>> > for this problem):
>> > Nov 27 23:02:17 linuxtemp01 kernel: [ 5681.075141] ata1: link is slow
>> > to respond, please be patient (ready=3D0)
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073141] ata1: device not
>> > ready (errno=3D-16), forcing hardreset
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073236] ata1: soft resettin=
g link
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.228817] ata1.00: configured
>> > for MWDMA2
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230503] ata1.01: configured
>> > for MWDMA1
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230508] ata1.00: device
>> > reported invalid CHS sector 0
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230515] ata1: EH complete
>> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701259] ata1.01: exception
>> > Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701262] ata1.01: failed
>> > command: WRITE DMA EXT
>> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701265] ata1.01: cmd
>> > 35/00:98:ef:c0:24/00:02:02:00:00/f0 tag 0 dma 339968 out
>> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701266] ? ? ? ? ?res
>> > 40/00:01:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
>> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701268] ata1.01: status: { =
DRDY }
>> > Nov 27 23:08:29 linuxtemp01 kernel: [ 6052.750078] ata1: link is slow
>> > to respond, please be patient (ready=3D0)
>> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748079] ata1: device not
>> > ready (errno=3D-16), forcing hardreset
>> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748134] ata1: soft resettin=
g link
>> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.902320] ata1.00: configured
>> > for MWDMA2
>> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903499] ata1.01: configured
>> > for MWDMA1
>> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903503] ata1.01: device
>> > reported invalid CHS sector 0
>> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903506] ata1: EH complete
>> >
>> > My problem is very similar to this one:
>> > http://web.archiveorange.com/archive/v/wmeLDfqXdkxOOQURv2Ak
>> >
>> > But the workaround for this issue is not working for me.
>> >
>> > Any help will be welcome.
>> >
>> > Thanks in advance.
>> >
>> > Att.
>> > Artur Baruchi
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:11:07 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:11:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtIY-0006yL-Sn; Wed, 30 Nov 2011 23:10:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.baruchi@gmail.com>)
	id 1RVtIW-0006yD-Uv; Wed, 30 Nov 2011 23:10:41 +0000
X-Env-Sender: mail.baruchi@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322694599!5389158!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5061 invoked from network); 30 Nov 2011 23:10:00 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Nov 2011 23:10:00 -0000
Received: by vbbfq11 with SMTP id fq11so2037811vbb.30
	for <multiple recipients>; Wed, 30 Nov 2011 15:09:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Af54gA+KUGDRpa165kJkC81TkhsUqn2ctUs7iBapZcE=;
	b=LMyqvD+uqEbnFyJN5GnJTfH3vjX1eu3LsE+hYA6hR4nZM9oZWrITuCxwfr+a4XjUAS
	ngWGtlKRPyK8HHbtt2eszZrYpKsj+4wjGTy6Ei/f9eEg0WOR4S009pach37lISKtQaXu
	69aGFdOamlVFYt/TP6CCx0WvdiaWeO9xuPB90=
MIME-Version: 1.0
Received: by 10.52.68.79 with SMTP id u15mr3958257vdt.5.1322694598457; Wed, 30
	Nov 2011 15:09:58 -0800 (PST)
Received: by 10.52.187.4 with HTTP; Wed, 30 Nov 2011 15:09:58 -0800 (PST)
In-Reply-To: <20111130221545.GB16651@andromeda.dapyr.net>
References: <CAAiDW_RNUWUUm7rsgXUMJnc6gnQ7FbEv0eVX-tJQ+PAnjrOmeg@mail.gmail.com>
	<CAAiDW_Trg-B8Bq=sjnedZoxjxi2T+H=ADvuiBdE8jr+B1a5Jgg@mail.gmail.com>
	<20111130221545.GB16651@andromeda.dapyr.net>
Date: Wed, 30 Nov 2011 21:09:58 -0200
Message-ID: <CAAiDW_T2Eutw=NibLv2s1f1DJsbSY39oHL_pH8RkmAi=iWK0HA@mail.gmail.com>
From: Artur Baruchi <mail.baruchi@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Xen-devel@lists.xensource.com, xen-users <Xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] VM Hanging after reboot
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Konrad.

That was my first though (disk going bad). But I create another VM in
a different host and faced the same error. I tried to create another
file and use a physical device (logical volume) too, but no lucky. Im
guessing that it can be:

- There is a bug in this kernel version or in paravirtualized drivers
used by opensuse 11.3 (based on some google searchs that I made, with
similar errors); OR
- Some configuration problem (for example, need to enable acpi in my
vm kernel, or anything like this).

Thanks.

Att.
Artur Baruchi


On Wed, Nov 30, 2011 at 8:15 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> On Wed, Nov 30, 2011 at 04:46:55PM -0200, Artur Baruchi wrote:
>> I just configured the serial console to see what is going on during
>> the boot. I tried to run fsck and changed the grub to use the device
>> path (/dev/sdaX) instead udisks-part-id, but no success.
>>
>> Follow the console errors:
>>
>
> That looks like your disk is going bad?
>
> Was there anything before this? Like the IRQs not setup properly?
>
>> Loading drivers, configuring devices: [ =A0 69.701448] ata1.00:
>> exception Emask 0x0 SAct 0x0 SErr 0x0 act
>> =A0ion 0x6 frozen
>> [ =A0 69.705706] ata1.00: failed command: READ DMA
>> [ =A0 69.708402] ata1.00: cmd c8/00:20:b8:7a:66/00:00:00:00:00/e0 tag 0
>> dma 16384 in
>> [ =A0 69.708403] =A0 =A0 =A0 =A0 =A0res 40/00:01:00:00:00/00:00:00:00:00=
/a0 Emask
>> 0x4 (timeout)
>> [ =A0 69.717358] ata1.00: status: { DRDY }
>> [ =A0 69.872400] ata1.00: revalidation failed (errno=3D-2)
>> [ =A0 75.023385] ata1.00: revalidation failed (errno=3D-2)
>> [ =A0 80.174383] ata1.00: revalidation failed (errno=3D-2)
>> [ =A0 80.329687] end_request: I/O error, dev sda, sector 6716088
>> [ =A0 80.333096] end_request: I/O error, dev sda, sector 6716088
>> [ =A0 80.336676] end_request: I/O error, dev sda, sector 6716088
>> [ =A0 80.340408] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.344063] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.347465] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.351795] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.356081] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.359587] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.363115] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.366535] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.370034] end_request: I/O error, dev sda, sector 6145504
>> [ =A0 80.373924] end_request: I/O error, dev sda, sector 9979920
>> [ =A0 80.377458] Buffer I/O error on device sda3, logical block 721410
>> [ =A0 80.389108] end_request: I/O error, dev sda, sector 4970504
>> [ =A0 80.392576] end_request: I/O error, dev sda, sector 4970504
>> [ =A0 80.396208] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.399747] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> [ =A0 80.406333] end_request: I/O error, dev sda, sector 4208640
>> [ =A0 80.409650] Buffer I/O error on device sda3, logical block 0
>> udevd-work[1631]: exec of program '/lib/udev/ata_id' failed
>>
>> [ =A0 80.416228] end_request: I/O error, dev sda, sector 6796224
>> [ =A0 80.419759] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.423135] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.425117] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.427447] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.429840] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.432094] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.434425] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.436746] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.439043] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.441358] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.443626] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.445864] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.448051] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.450271] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.452482] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.454745] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.457029] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.459299] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.461604] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.463843] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.466045] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.468274] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.470510] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.472725] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.474902] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.477103] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.479278] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.481514] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.483647] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.485780] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.487838] end_request: I/O error, dev sda, sector 6796288
>> [ =A0 80.489897] end_request: I/O error, dev sda, sector 6796224
>> [ =A0 80.491920] end_request: I/O error, dev sda, sector 6796224
>> [ =A0 80.494294] end_request: I/O error, dev sda, sector 4971928
>> [ =A0 80.496445] end_request: I/O error, dev sda, sector 4971928
>> [ =A0 80.498650] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.500834] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> [ =A0 80.504930] end_request: I/O error, dev sda, sector 4208640
>> [ =A0 80.507019] Buffer I/O error on device sda3, logical block 0
>> udevd-work[1632]: exec of program '/lib/udev/scsi_id' failed
>>
>> [ =A0 80.511028] end_request: I/O error, dev sda, sector 12352272
>> [ =A0 80.513236] Buffer I/O error on device sda3, logical block 1017954
>> [ =A0 80.515677] end_request: I/O error, dev sda, sector 12360888
>> [ =A0 80.518021] Buffer I/O error on device sda3, logical block 1019031
>> [ =A0 80.520527] Buffer I/O error on device sda3, logical block 1019032
>> [ =A0 80.523072] end_request: I/O error, dev sda, sector 9980016
>> [ =A0 80.525394] journal_bmap: journal block not found at offset 12 on s=
da3
>> [ =A0 80.527956] Aborting journal on device sda3.
>> [ =A0 80.529854] end_request: I/O error, dev sda, sector 9979920
>> [ =A0 80.532119] Buffer I/O error on device sda3, logical block 721410
>> [ =A0 80.534799] end_request: I/O error, dev sda, sector 9979928
>> [ =A0 80.537239] end_request: I/O error, dev sda, sector 9979936
>> [ =A0 80.539639] end_request: I/O error, dev sda, sector 9370632
>> [ =A0 80.542144] end_request: I/O error, dev sda, sector 9370632
>> [ =A0 80.544499] EXT3-fs (sda3): error: ext3_journal_start_sb: Detected
>> aborted journal
>> [ =A0 80.547659] EXT3-fs (sda3): error: remounting filesystem read-only
>> [ =A0 80.550535] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.552989] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> udevd-work[1634]: exec of program '/sbin/blkid' failed
>>
>> [ =A0 80.559337] end_request: I/O error, dev sda, sector 4972560
>> [ =A0 80.561964] end_request: I/O error, dev sda, sector 4972560
>> [ =A0 80.564546] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.567069] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> udevd-work[1635]: exec of program '/lib/udev/edd_id' failed
>>
>> [ =A0 80.576377] end_request: I/O error, dev sda, sector 4952712
>> [ =A0 80.580086] end_request: I/O error, dev sda, sector 4952712
>> [ =A0 80.583689] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.586292] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> udevd-work[1636]: exec of program '/lib/udev/udisks-part-id' failed
>>
>> [ =A0 80.593995] end_request: I/O error, dev sda, sector 9370632
>> [ =A0 80.596704] end_request: I/O error, dev sda, sector 9370632
>> [ =A0 80.596755] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.596760] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> udevd-work[1637][ =A0 80.608632] end_request: I/O error, dev sda, sector=
 11290592
>> : exec of program '/sbin/blkid' failed[ =A0 80.612951] EXT3-fs error
>> (device sda3): ext3_get_inode_loc: u
>> nable to read inode block - inode=3D223126, block=3D885244
>>
>>
>> [ =A0 80.621449] end_request: I/O error, dev sda, sector 9370632
>> [ =A0 80.624665] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.627305] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> udevd-work[1638]: exec of program '/sbin/blkid' failed
>>
>> udevd-work[1639]: exec of program '/sbin/blkid' failed
>>
>> [ =A0 80.635017] end_request: I/O error, dev sda, sector 4952712
>> [ =A0 80.637899] end_request: I/O error, dev sda, sector 4952712
>> [ =A0 80.637956] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.637962] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> [ =A0 80.649954] end_request: I/O error, dev sda, sector 4952712
>> udevd-work[1640]: exec of program '/lib/udev/udi[ =A0 80.649974]
>> end_request: I/O error, dev sda, sector
>> 11290592
>> sks-part-id' failed
>> [ =A0 80.649981] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>>
>> udevd-work[1641][ =A0 80.664921] end_request: I/O error, dev sda, sector=
 11290592
>> : exec of program '/lib/udev/udisks-part-id' fai[ =A0 80.669088] EXT3-fs
>> error (device sda3): ext3_get_in
>> ode_loc: ledunable to read inode block - inode=3D223126, block=3D885244
>>
>>
>> udevd-work[1642]: exec of program '/lib/udev/udisks-part-id' failed
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 done
>> [ =A0 80.688649] end_request: I/O error, dev sda, sector 11516760
>> [ =A0 80.693402] end_request: I/O error, dev sda, sector 11517320
>> [ =A0 80.698410] end_request: I/O error, dev sda, sector 11516760
>> boot.loadmodules: Input/output error
>> [ =A0 80.705752] end_request: I/O error, dev sda, sector 11517320
>> boot.rootfsck: Input/output error
>> [ =A0 80.712719] end_request: I/O error, dev sda, sector 11516496
>> [ =A0 80.717814] end_request: I/O error, dev sda, sector 11516704
>> [ =A0 80.730101] end_request: I/O error, dev sda, sector 11516496
>> boot.clock: Input/output error
>> [ =A0 80.736217] end_request: I/O error, dev sda, sector 11516768
>> [ =A0 80.741296] end_request: I/O error, dev sda, sector 11352104
>> [ =A0 80.745949] end_request: I/O error, dev sda, sector 11352104
>> boot.device-mapper: Input/output error
>> [ =A0 80.753208] end_request: I/O error, dev sda, sector 11516768
>> boot.localfs: Input/output error
>> [ =A0 80.760052] end_request: I/O error, dev sda, sector 11516488
>> [ =A0 80.764909] end_request: I/O error, dev sda, sector 11499608
>> [ =A0 80.769502] end_request: I/O error, dev sda, sector 11303224
>> [ =A0 80.775085] end_request: I/O error, dev sda, sector 11516744
>> [ =A0 80.779703] end_request: I/O error, dev sda, sector 11517168
>> [ =A0 80.784166] end_request: I/O error, dev sda, sector 11517360
>> [ =A0 80.788596] end_request: I/O error, dev sda, sector 11518640
>> [ =A0 80.793861] end_request: I/O error, dev sda, sector 11518640
>> [ =A0 80.798273] end_request: I/O error, dev sda, sector 11517360
>> [ =A0 80.803364] end_request: I/O error, dev sda, sector 11517176
>> boot.swap: Input/output error
>> [ =A0 80.809435] end_request: I/O error, dev sda, sector 11517168
>> boot.proc: Input/output error
>> [ =A0 80.815339] end_request: I/O error, dev sda, sector 11516488
>> boot.localnet: Input/output error[ =A0 80.820846] end_request: I/O
>> error, dev sda, sector 11516744
>> [ =A0 80.825458] end_request: I/O error, dev sda, sector 11499608
>> [ =A0 80.829771] end_request: I/O error, dev sda, sector 11303224
>> [ =A0 80.834086] end_request: I/O error, dev sda, sector 11516752
>>
>> boot.cleanup: In[ =A0 80.838667] end_request: I/O error, dev sda, sector=
 11518160
>> put/output error[ =A0 80.843568] end_request: I/O error, dev sda, sector=
 11516752
>>
>> [ =A0 80.847792] end_request: I/O error, dev sda, sector 11518160
>> boot.cycle: Input/output error[ =A0 80.853141] end_request: I/O error,
>> dev sda, sector 11417656
>>
>> [ =A0 80.853840] end_request: I/O error, dev sda, sector 11417656
>> boot.fuse: Input/output error
>> boot.klog: Input/output error
>> boot.sysctl: Input/output error
>> [ =A0 80.865148] end_request: I/O error, dev sda, sector 11516712
>> [ =A0 80.865199] end_request: I/O error, dev sda, sector 11516712
>> boot.ldconfig: Input/output error
>> boot.udev_retry: Input/output error
>> boot.apparmor: Input/output error
>> boot.ipconfig: Input/output error
>> System Boot Control: The system has been =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0set up
>> Failed features: boot.loadmodules boot.rootfsck boot.clock
>> boot.device-mapper boot.localfs boot.cleanup
>> =A0 =A0 =A0boot.cycle boot.fuse boot.klog boot.localnet boot.proc boot.s=
wap
>> boot.sysctl boot.ldconfig boot.udev_r
>> etry boot.apparmor boot.ipconfig
>> System Boot Control: Running /etc/init.d/boot.local
>> [ =A0 80.890020] end_request: I/O error, dev sda, sector 11540760
>> [ =A0 80.892185] end_request: I/O error, dev sda, sector 11540760
>> /etc/init.d/boot.local: /etc/init.d/boot.local: Input/output error =A0 =
=A0failed
>> [ =A0 80.897735] end_request: I/O error, dev sda, sector 9369944
>> [ =A0 80.900025] end_request: I/O error, dev sda, sector 9369944
>> [ =A0 80.902265] end_request: I/O error, dev sda, sector 9369944
>> /etc/init.d/boot: line 314: /sbin/killproc: Input/output error
>> /etc/init.d/boot: line 326: /var/run/no_blogd: Read-only file system
>> [ =A0 80.909885] end_request: I/O error, dev sda, sector 12335128
>> [ =A0 80.913314] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2539 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 69,
>> block=3D1015811
>> [ =A0 80.920333] end_request: I/O error, dev sda, sector 12335128
>> [ =A0 80.923922] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2539 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 69,
>> block=3D1015811
>> [ =A0 80.931552] end_request: I/O error, dev sda, sector 12335128
>> [ =A0 80.935604] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2539 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 69,
>> block=3D1015811
>> [ =A0 80.944776] end_request: I/O error, dev sda, sector 11290592
>> [ =A0 80.948819] EXT3-fs error (device sda3): ext3_get_inode_loc: unable
>> to read inode block - inode=3D2231 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 26,
>> block=3D885244
>> INIT: Entering runlevel: 3
>> [ =A0 80.965451] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 80.969737] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 80.980514] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
>> 80.987414] end_request: I/O erro =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 r, dev
>> sda, sector 11519720
>>
>> [ =A0 80.991743] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript:[ =A0 80.996145] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/s[ =A0 81.005996] end_request: I/O error,
>> dev sda, sector 11519720
>> ysconfig/ulimit: Input/output er[ =A0 81.010510] end_request: I/O error,
>> dev sda, sector 11519720
>> ror[ =A0 81.016077] end_request: I/O error, dev sda, sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
>> 81.022320] end_request: I/O erro =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 r, dev
>> sda, sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript:[ =A0 81.030711] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit:[ =A0 81.035523] end_request: I/O erro=
r,
>> dev sda, sector 11519720
>> =A0Input/output error
>> /etc/initscript:[ =A0 81.043077] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit:[ =A0 81.047889] end_request: I/O erro=
r,
>> dev sda, sector 11519720
>> =A0Input/output error[ =A0 81.052231] end_request: I/O error, dev sda,
>> sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
>> 81.062739] end_request: I/O error, dev s
>> da, sector 11519720
>> ut error
>> [ =A0 81.066952] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.081287] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ =A0 81.087077]
>> end_request: I/O error, dev sda, sector
>> 11519720
>> =A0Input/output error
>> [ =A0 81.092828] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.097171] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
>> 81.105199] end_request: I/O error, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0dev
>> sda, sector 11519720
>> ror
>> /etc/initscript: line 77: /[ =A0 81.109861] end_request: I/O error, dev
>> sda, sector 11519720
>> etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input[ =A0 81.116079]
>> end_request: I/O error, dev sda, s =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 ector
>> 11519720
>> /output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/uli[ =A0 81.123656]
>> end_request: I/O error, dev sda, sector 1151
>> =A0 =A0 9720
>> mit: Input/output error
>> [ =A0 81.131077] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript:[ =A0 81.135256] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.145043] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
>> 81.151102] end_request: I/O erro =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 r, dev
>> sda, sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript:[ =A0 81.158246] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error[ =A0 81.163908]
>> end_request: I/O error, dev sda, sect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 or
>> 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript:[ =A0 81.170077] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.175614] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
>> 81.181692] end_request: I/O erro =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 r, dev
>> sda, sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.188834] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.193074] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ul[ =A0 81.202959] end_request:
>> I/O error, dev sda, sector 11519 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 720
>> imit: Input/output error
>> [ =A0 81.209078] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.215046] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ =A0 81.220029]
>> end_request: I/O error, dev sda, sector
>> 11519720
>> =A0Input/output error
>> /etc/initscript:[ =A0 81.224860] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error[ =A0 81.230950]
>> end_request: I/O error, dev sda, sect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 or
>> 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.241445] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.245133] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error[
>> 81.253519] end_request: I/O erro =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 r, dev
>> sda, sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
>> 81.259342] end_request: I/O error, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0dev
>> sda, sector 11519720
>> ror
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/outp[
>> 81.265077] end_request: I/O error, dev s
>> da, sector 11519720
>> ut error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sy[ =A0 81.271786] end_request: I/O
>> error, dev sda, sector 11519720
>> sconfig/ulimit: Input/output error
>> [ =A0 81.277066] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.284078] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.287740] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit:[ =A0 81.292708]
>> end_request: I/O error, dev sda, sector
>> 11519720
>> =A0Input/output error[ =A0 81.298719] end_request: I/O error, dev sda,
>> sector 11519720
>>
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript:[ =A0 81.304841] end_request: I/O error, dev sda, sector=
 11519720
>> =A0line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.313187] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.324518] end_request: I/O error, dev sda, sector 11519720
>> [ =A0 81.329435] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
>> 81.334830] end_request: I/O error, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0dev
>> sda, sector 11519720
>> ror
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line [ =A0 81.341698] end_request: I/O error, dev sda,
>> sector 11519720
>> 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> INIT: Id "6[ =A0 81.349010] end_request: I/O error, dev sda, sector 1151=
9720
>> " respawning too fast: disabled for 5 minutes
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
>> 81.355880] end_request: I/O error, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0dev
>> sda, sector 11519720
>> ror
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.363875] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output er[
>> 81.369261] end_request: I/O error, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0dev
>> sda, sector 11519720
>> ror
>> INIT: Id "co" respawning too fast: disabled for 5 minutes
>> /etc/initscript: line 77: /etc[ =A0 81.376228] end_request: I/O error,
>> dev sda, sector 11519720
>> /sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> INI[ =A0 81.383188] end_request: I/O error, dev sda, sector 11519720
>> T: Id "3" respawning too fast: disabled for 5 minutes
>> /etc/initscript: line 77[ =A0 81.389244] end_request: I/O error, dev
>> sda, sector 11519720
>> : /etc/sysconfig/ulimit: Input/output error
>> INIT: Id "4" respawning too fast: disabled for 5 minutes
>> /etc/in[ =A0 81.395907] end_request: I/O error, dev sda, sector 11519720
>> itscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: I[ =A0 81.403341]
>> end_request: I/O error, dev sda, secto =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 r
>> 11519720
>> nput/output error
>> INIT: Id "5" respawning too fast: disabled for 5 minutes
>> /etc/initscript: [ =A0 81.410018] end_request: I/O error, dev sda, secto=
r 11519720
>> line 77: /etc/sysconfig/ulimit: Input/output error
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> INIT: Id "1" respawning too fast: disabled for 5 minutes
>> [ =A0 81.420725] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.430746] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> [ =A0 81.440664] end_request: I/O error, dev sda, sector 11519720
>> /etc/initscript: line 77: /etc/sysconfig/ulimit: Input/output error
>> INIT: Id "2" respawning too fast: disabled for 5 minutes
>> INIT: no more processes left in this runlevel
>>
>>
>>
>>
>> On Wed, Nov 30, 2011 at 11:48 AM, Artur Baruchi <mail.baruchi@gmail.com>=
 wrote:
>> > Hi.
>> >
>> > Im installing a VM to run a benchmark, Im able to install the VM issue
>> > the first boot (to setup network configurations), but if I reboot the
>> > VM it just hangs and do not boot. I've re-installed the machine but no
>> > success. Follow some details:
>> >
>> > - Dom0: Opensuse 11.3 (x86_64), kernel 2.6.34-12-xen,
>> > xen-4.0.0_21091_05-6.6.x86_64
>> > - DomU: Full Virtualization, Opensuse 11.3 (x86_64), kernel 2.6.34-12-=
desktop
>> >
>> > Some errors in message file (not sure that this errors mean something
>> > for this problem):
>> > Nov 27 23:02:17 linuxtemp01 kernel: [ 5681.075141] ata1: link is slow
>> > to respond, please be patient (ready=3D0)
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073141] ata1: device not
>> > ready (errno=3D-16), forcing hardreset
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.073236] ata1: soft resettin=
g link
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.228817] ata1.00: configured
>> > for MWDMA2
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230503] ata1.01: configured
>> > for MWDMA1
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230508] ata1.00: device
>> > reported invalid CHS sector 0
>> > Nov 27 23:02:22 linuxtemp01 kernel: [ 5686.230515] ata1: EH complete
>> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701259] ata1.01: exception
>> > Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701262] ata1.01: failed
>> > command: WRITE DMA EXT
>> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701265] ata1.01: cmd
>> > 35/00:98:ef:c0:24/00:02:02:00:00/f0 tag 0 dma 339968 out
>> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701266] ? ? ? ? ?res
>> > 40/00:01:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
>> > Nov 27 23:08:24 linuxtemp01 kernel: [ 6047.701268] ata1.01: status: { =
DRDY }
>> > Nov 27 23:08:29 linuxtemp01 kernel: [ 6052.750078] ata1: link is slow
>> > to respond, please be patient (ready=3D0)
>> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748079] ata1: device not
>> > ready (errno=3D-16), forcing hardreset
>> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.748134] ata1: soft resettin=
g link
>> > Nov 27 23:08:34 linuxtemp01 kernel: [ 6057.902320] ata1.00: configured
>> > for MWDMA2
>> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903499] ata1.01: configured
>> > for MWDMA1
>> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903503] ata1.01: device
>> > reported invalid CHS sector 0
>> > Nov 27 23:08:35 linuxtemp01 kernel: [ 6057.903506] ata1: EH complete
>> >
>> > My problem is very similar to this one:
>> > http://web.archiveorange.com/archive/v/wmeLDfqXdkxOOQURv2Ak
>> >
>> > But the workaround for this issue is not working for me.
>> >
>> > Any help will be welcome.
>> >
>> > Thanks in advance.
>> >
>> > Att.
>> > Artur Baruchi
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgT-0007Eh-FV; Wed, 30 Nov 2011 23:35:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Da-AJ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322696084!5390696!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11701 invoked from network); 30 Nov 2011 23:34:44 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-182.messagelabs.com with SMTP;
	30 Nov 2011 23:34:44 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYh44027129
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2N032692; 
	Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:52 -0500
Message-Id: <1322696099-13849-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 1/8] flask: Fix policy build with new checkpolicy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Version 26 of checkpolicy (shipped with Fedora 16) now requires that
roles be declared prior to setting types for a role. Add a declaration
of the system_r role to fix the build of default XSM/FLASK policy.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 0977939..d95a7da 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -151,4 +151,5 @@ sid iomem gen_context(system_u:object_r:iomem_t,s0)
 sid ioport gen_context(system_u:object_r:ioport_t,s0)
 sid device gen_context(system_u:object_r:device_t,s0)
 
+role system_r;
 role system_r types { xen_type domain_type };
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgT-0007Eh-FV; Wed, 30 Nov 2011 23:35:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Da-AJ
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1322696084!5390696!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11701 invoked from network); 30 Nov 2011 23:34:44 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-182.messagelabs.com with SMTP;
	30 Nov 2011 23:34:44 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYh44027129
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2N032692; 
	Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:52 -0500
Message-Id: <1322696099-13849-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 1/8] flask: Fix policy build with new checkpolicy
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Version 26 of checkpolicy (shipped with Fedora 16) now requires that
roles be declared prior to setting types for a role. Add a declaration
of the system_r role to fix the build of default XSM/FLASK policy.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 0977939..d95a7da 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -151,4 +151,5 @@ sid iomem gen_context(system_u:object_r:iomem_t,s0)
 sid ioport gen_context(system_u:object_r:ioport_t,s0)
 sid device gen_context(system_u:object_r:device_t,s0)
 
+role system_r;
 role system_r types { xen_type domain_type };
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgV-0007FB-15; Wed, 30 Nov 2011 23:35:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Dh-OO
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322696084!5368787!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17265 invoked from network); 30 Nov 2011 23:34:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-2.tower-182.messagelabs.com with SMTP;
	30 Nov 2011 23:34:45 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYilP008868
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:44 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2U032692; 
	Wed, 30 Nov 2011 18:34:44 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:59 -0500
Message-Id: <1322696099-13849-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 8/8] flask: Add flask-label-pci tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This allows a PCI device and its associated resources to be labeled
without hardcoding addresses (which may change from system to system) in
the security policy.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/utils/Makefile    |    5 +-
 tools/flask/utils/label-pci.c |  123 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 127 insertions(+), 1 deletions(-)
 create mode 100644 tools/flask/utils/label-pci.c

diff --git a/tools/flask/utils/Makefile b/tools/flask/utils/Makefile
index 25729a1..171a728 100644
--- a/tools/flask/utils/Makefile
+++ b/tools/flask/utils/Makefile
@@ -11,7 +11,7 @@ TESTDIR  = testsuite/tmp
 TESTFLAGS= -DTESTING
 TESTENV  = XENSTORED_ROOTDIR=$(TESTDIR) XENSTORED_RUNDIR=$(TESTDIR)
 
-CLIENTS := flask-loadpolicy flask-setenforce flask-getenforce
+CLIENTS := flask-loadpolicy flask-setenforce flask-getenforce flask-label-pci
 CLIENTS_SRCS := $(patsubst flask-%,%.c,$(CLIENTS))
 CLIENTS_OBJS := $(patsubst flask-%,%.o,$(CLIENTS))
 
@@ -27,6 +27,9 @@ flask-setenforce: setenforce.o
 flask-getenforce: getenforce.o
 	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
 
+flask-label-pci: label-pci.o
+	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+
 .PHONY: clean
 clean: 
 	rm -f *.o *.opic *.so
diff --git a/tools/flask/utils/label-pci.c b/tools/flask/utils/label-pci.c
new file mode 100644
index 0000000..839ad61
--- /dev/null
+++ b/tools/flask/utils/label-pci.c
@@ -0,0 +1,123 @@
+/*
+ *  Author:  Daniel De Graaf <dgdegra@tycho.nsa.gov>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2,
+ *  as published by the Free Software Foundation.
+ */
+
+#include <stdlib.h>
+#include <errno.h>
+#include <stdio.h>
+#include <xenctrl.h>
+#include <fcntl.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <string.h>
+#include <unistd.h>
+#include <libflask.h>
+
+/* Pulled from linux/include/linux/ioport.h */
+#define IORESOURCE_TYPE_BITS    0x00001f00  /* Resource type */
+#define IORESOURCE_IO       0x00000100
+#define IORESOURCE_MEM      0x00000200
+#define IORESOURCE_IRQ      0x00000400
+#define IORESOURCE_DMA      0x00000800
+#define IORESOURCE_BUS      0x00001000
+
+
+static void usage (int argCnt, char *argv[])
+{
+	fprintf(stderr, "Usage: %s SBDF label\n", argv[0]);
+	exit(1);
+}
+
+int main (int argCnt, char *argv[])
+{
+	int ret, err = 0;
+	xc_interface *xch = 0;
+	int seg, bus, dev, fn;
+	uint32_t sbdf;
+	uint64_t start, end, flags;
+	char buf[1024];
+	FILE *f;
+
+	if (argCnt != 3)
+		usage(argCnt, argv);
+
+	xch = xc_interface_open(0,0,0);
+	if ( !xch )
+	{
+		fprintf(stderr, "Unable to create interface to xenctrl: %s\n",
+				strerror(errno));
+		err = 1;
+		goto done;
+	}
+
+	sscanf(argv[1], "%x:%x:%x.%d", &seg, &bus, &dev, &fn);
+	sbdf = (seg << 16) | (bus << 8) | (dev << 3) | fn;
+
+	snprintf(buf, sizeof(buf), "/sys/bus/pci/devices/%04x:%02x:%02x.%d/resource",
+			seg, bus, dev, fn);
+
+	f = fopen(buf, "r");
+	if (!f) {
+		fprintf(stderr, "Unable to find device %s: %s\n", argv[1],
+				strerror(errno));
+		err = 1;
+		goto done;
+	}
+
+	ret = flask_add_device(xch, sbdf, argv[2]);
+	if (ret) {
+		fprintf(stderr, "flask_add_device: Unable to set context of PCI device %s (0x%x) to %s: %d\n",
+			argv[1], sbdf, argv[2], ret);
+		err = 2;
+		goto done;
+	}
+
+	while (fscanf(f, "0x%lx 0x%lx 0x%lx\n", &start, &end, &flags) == 3) {
+		if (flags & IORESOURCE_IO) {
+			// printf("Port %lx-%lx\n", start, end);
+			ret = flask_add_ioport(xch, start, end, argv[2]);
+			if (ret) {
+				fprintf(stderr, "flask_add_ioport %lx-%lx failed: %d\n",
+						start, end, ret);
+				err = 2;
+			}
+		} else if (flags & IORESOURCE_MEM) {
+			start >>= 12;
+			end >>= 12;
+			// printf("IOMEM %lx-%lx\n", start, end);
+			ret = flask_add_iomem(xch, start, end, argv[2]);
+			if (ret) {
+				fprintf(stderr, "flask_add_iomem %lx-%lx failed: %d\n",
+						start, end, ret);
+				err = 2;
+			}
+		}
+	}
+	fclose(f);
+
+	snprintf(buf, sizeof(buf), "/sys/bus/pci/devices/%04x:%02x:%02x.%d/irq",
+			seg, bus, dev, fn);
+	f = fopen(buf, "r");
+	if (!f)
+		goto done;
+	start = 0;
+	fscanf(f, "%ld", &start);
+	if (start) {
+		ret = flask_add_pirq(xch, start, argv[2]);
+		if (ret) {
+			fprintf(stderr, "flask_add_pirq %ld failed: %d\n",
+					start, ret);
+			err = 2;
+		}
+	}
+	fclose(f);
+done:
+	if ( xch )
+		xc_interface_close(xch);
+
+	return err;
+}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:47 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgV-0007FB-15; Wed, 30 Nov 2011 23:35:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Dh-OO
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-182.messagelabs.com!1322696084!5368787!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17265 invoked from network); 30 Nov 2011 23:34:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-2.tower-182.messagelabs.com with SMTP;
	30 Nov 2011 23:34:45 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYilP008868
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:44 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2U032692; 
	Wed, 30 Nov 2011 18:34:44 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:59 -0500
Message-Id: <1322696099-13849-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 8/8] flask: Add flask-label-pci tool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This allows a PCI device and its associated resources to be labeled
without hardcoding addresses (which may change from system to system) in
the security policy.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/utils/Makefile    |    5 +-
 tools/flask/utils/label-pci.c |  123 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 127 insertions(+), 1 deletions(-)
 create mode 100644 tools/flask/utils/label-pci.c

diff --git a/tools/flask/utils/Makefile b/tools/flask/utils/Makefile
index 25729a1..171a728 100644
--- a/tools/flask/utils/Makefile
+++ b/tools/flask/utils/Makefile
@@ -11,7 +11,7 @@ TESTDIR  = testsuite/tmp
 TESTFLAGS= -DTESTING
 TESTENV  = XENSTORED_ROOTDIR=$(TESTDIR) XENSTORED_RUNDIR=$(TESTDIR)
 
-CLIENTS := flask-loadpolicy flask-setenforce flask-getenforce
+CLIENTS := flask-loadpolicy flask-setenforce flask-getenforce flask-label-pci
 CLIENTS_SRCS := $(patsubst flask-%,%.c,$(CLIENTS))
 CLIENTS_OBJS := $(patsubst flask-%,%.o,$(CLIENTS))
 
@@ -27,6 +27,9 @@ flask-setenforce: setenforce.o
 flask-getenforce: getenforce.o
 	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
 
+flask-label-pci: label-pci.o
+	$(CC) $(LDFLAGS) $< $(LDLIBS) -L$(LIBFLASK_ROOT) -lflask $(LDLIBS_libxenctrl) -o $@
+
 .PHONY: clean
 clean: 
 	rm -f *.o *.opic *.so
diff --git a/tools/flask/utils/label-pci.c b/tools/flask/utils/label-pci.c
new file mode 100644
index 0000000..839ad61
--- /dev/null
+++ b/tools/flask/utils/label-pci.c
@@ -0,0 +1,123 @@
+/*
+ *  Author:  Daniel De Graaf <dgdegra@tycho.nsa.gov>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2,
+ *  as published by the Free Software Foundation.
+ */
+
+#include <stdlib.h>
+#include <errno.h>
+#include <stdio.h>
+#include <xenctrl.h>
+#include <fcntl.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <string.h>
+#include <unistd.h>
+#include <libflask.h>
+
+/* Pulled from linux/include/linux/ioport.h */
+#define IORESOURCE_TYPE_BITS    0x00001f00  /* Resource type */
+#define IORESOURCE_IO       0x00000100
+#define IORESOURCE_MEM      0x00000200
+#define IORESOURCE_IRQ      0x00000400
+#define IORESOURCE_DMA      0x00000800
+#define IORESOURCE_BUS      0x00001000
+
+
+static void usage (int argCnt, char *argv[])
+{
+	fprintf(stderr, "Usage: %s SBDF label\n", argv[0]);
+	exit(1);
+}
+
+int main (int argCnt, char *argv[])
+{
+	int ret, err = 0;
+	xc_interface *xch = 0;
+	int seg, bus, dev, fn;
+	uint32_t sbdf;
+	uint64_t start, end, flags;
+	char buf[1024];
+	FILE *f;
+
+	if (argCnt != 3)
+		usage(argCnt, argv);
+
+	xch = xc_interface_open(0,0,0);
+	if ( !xch )
+	{
+		fprintf(stderr, "Unable to create interface to xenctrl: %s\n",
+				strerror(errno));
+		err = 1;
+		goto done;
+	}
+
+	sscanf(argv[1], "%x:%x:%x.%d", &seg, &bus, &dev, &fn);
+	sbdf = (seg << 16) | (bus << 8) | (dev << 3) | fn;
+
+	snprintf(buf, sizeof(buf), "/sys/bus/pci/devices/%04x:%02x:%02x.%d/resource",
+			seg, bus, dev, fn);
+
+	f = fopen(buf, "r");
+	if (!f) {
+		fprintf(stderr, "Unable to find device %s: %s\n", argv[1],
+				strerror(errno));
+		err = 1;
+		goto done;
+	}
+
+	ret = flask_add_device(xch, sbdf, argv[2]);
+	if (ret) {
+		fprintf(stderr, "flask_add_device: Unable to set context of PCI device %s (0x%x) to %s: %d\n",
+			argv[1], sbdf, argv[2], ret);
+		err = 2;
+		goto done;
+	}
+
+	while (fscanf(f, "0x%lx 0x%lx 0x%lx\n", &start, &end, &flags) == 3) {
+		if (flags & IORESOURCE_IO) {
+			// printf("Port %lx-%lx\n", start, end);
+			ret = flask_add_ioport(xch, start, end, argv[2]);
+			if (ret) {
+				fprintf(stderr, "flask_add_ioport %lx-%lx failed: %d\n",
+						start, end, ret);
+				err = 2;
+			}
+		} else if (flags & IORESOURCE_MEM) {
+			start >>= 12;
+			end >>= 12;
+			// printf("IOMEM %lx-%lx\n", start, end);
+			ret = flask_add_iomem(xch, start, end, argv[2]);
+			if (ret) {
+				fprintf(stderr, "flask_add_iomem %lx-%lx failed: %d\n",
+						start, end, ret);
+				err = 2;
+			}
+		}
+	}
+	fclose(f);
+
+	snprintf(buf, sizeof(buf), "/sys/bus/pci/devices/%04x:%02x:%02x.%d/irq",
+			seg, bus, dev, fn);
+	f = fopen(buf, "r");
+	if (!f)
+		goto done;
+	start = 0;
+	fscanf(f, "%ld", &start);
+	if (start) {
+		ret = flask_add_pirq(xch, start, argv[2]);
+		if (ret) {
+			fprintf(stderr, "flask_add_pirq %ld failed: %d\n",
+					start, ret);
+			err = 2;
+		}
+	}
+	fclose(f);
+done:
+	if ( xch )
+		xc_interface_close(xch);
+
+	return err;
+}
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgT-0007ER-1i; Wed, 30 Nov 2011 23:35:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgQ-0007De-LV
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322696054!50647443!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12075 invoked from network); 30 Nov 2011 23:34:14 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-27.messagelabs.com with SMTP;
	30 Nov 2011 23:34:14 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYi44027135
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:44 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2T032692; 
	Wed, 30 Nov 2011 18:34:44 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:58 -0500
Message-Id: <1322696099-13849-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 7/8] xsm: clean up initial SIDs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The domU SID is never used before a policy load, and so does not belong
in the initial_sids list.

The PIRQ SID is now incorrectly named; it should simply be called IRQ.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/initial_sids  |    3 +--
 tools/flask/policy/policy/modules/xen/xen.if  |    4 ++--
 tools/flask/policy/policy/modules/xen/xen.te  |    9 ++++-----
 xen/xsm/flask/include/flask.h                 |   19 +++++++++----------
 xen/xsm/flask/include/initial_sid_to_string.h |    3 +--
 xen/xsm/flask/ss/services.c                   |    2 +-
 6 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/tools/flask/policy/policy/flask/initial_sids b/tools/flask/policy/policy/flask/initial_sids
index 9b78fba..e508bde 100644
--- a/tools/flask/policy/policy/flask/initial_sids
+++ b/tools/flask/policy/policy/flask/initial_sids
@@ -5,13 +5,12 @@
 #
 sid xen
 sid dom0
-sid domU
 sid domio
 sid domxen
 sid unlabeled
 sid security
 sid ioport
 sid iomem
-sid pirq
+sid irq
 sid device
 # FLASK
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index d12af74..1b50898 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -70,10 +70,10 @@ define(`create_passthrough_resource', `
         allow $1 $2:resource {add remove};
         allow $1 ioport_t:resource {add_ioport use};
         allow $1 iomem_t:resource {add_iomem use};
-        allow $1 pirq_t:resource  {add_irq use};
+        allow $1 irq_t:resource  {add_irq use};
         allow $1 domio_t:mmu {map_read map_write};
         allow $2 domio_t:mmu {map_write};
-        allow $2 pirq_t:resource {use};
+        allow $2 irq_t:resource {use};
         allow $1 $3:resource {add_irq add_iomem add_ioport remove_irq remove_iomem remove_ioport use add_device remove_device};
         allow $2 $3:resource {use add_ioport add_iomem remove_ioport remove_iomem};
         allow $2 $3:mmu {map_read map_write};
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 8113467..1a7f29a 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -16,7 +16,7 @@ type unlabeled_t, domain_type;
 
 type security_t, domain_type;
 
-type pirq_t, resource_type;
+type irq_t, resource_type;
 type ioport_t, resource_type;
 type iomem_t, resource_type;
 type device_t, resource_type;
@@ -43,8 +43,8 @@ allow xen_t ioport_t:resource {add_ioport remove_ioport};
 allow dom0_t ioport_t:resource {use};
 allow xen_t iomem_t:resource {add_iomem remove_iomem};
 allow dom0_t iomem_t:resource {use};
-allow xen_t pirq_t:resource {add_irq remove_irq};
-allow dom0_t pirq_t:resource { add_irq remove_irq use};
+allow xen_t irq_t:resource {add_irq remove_irq};
+allow dom0_t irq_t:resource { add_irq remove_irq use};
 allow dom0_t dom0_t:resource { add remove };
 allow dom0_t xen_t:xen firmware;
 
@@ -140,12 +140,11 @@ manage_domain(dom0_t, domHU_t)
 ################################################################################
 sid xen gen_context(system_u:system_r:xen_t,s0)
 sid dom0 gen_context(system_u:system_r:dom0_t,s0)
-sid domU gen_context(system_u:system_r:domU_t,s0)
 sid domxen gen_context(system_u:system_r:domxen_t,s0)
 sid domio gen_context(system_u:system_r:domio_t,s0)
 sid unlabeled gen_context(system_u:system_r:unlabeled_t,s0)
 sid security gen_context(system_u:system_r:security_t,s0)
-sid pirq gen_context(system_u:object_r:pirq_t,s0)
+sid irq gen_context(system_u:object_r:irq_t,s0)
 sid iomem gen_context(system_u:object_r:iomem_t,s0)
 sid ioport gen_context(system_u:object_r:ioport_t,s0)
 sid device gen_context(system_u:object_r:device_t,s0)
diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
index 333edcd..6d29c5a 100644
--- a/xen/xsm/flask/include/flask.h
+++ b/xen/xsm/flask/include/flask.h
@@ -20,16 +20,15 @@
  */
 #define SECINITSID_XEN                                  1
 #define SECINITSID_DOM0                                 2
-#define SECINITSID_DOMU                                 3
-#define SECINITSID_DOMIO                                4
-#define SECINITSID_DOMXEN                               5
-#define SECINITSID_UNLABELED                            6
-#define SECINITSID_SECURITY                             7
-#define SECINITSID_IOPORT                               8
-#define SECINITSID_IOMEM                                9
-#define SECINITSID_PIRQ                                 10
-#define SECINITSID_DEVICE                               11
+#define SECINITSID_DOMIO                                3
+#define SECINITSID_DOMXEN                               4
+#define SECINITSID_UNLABELED                            5
+#define SECINITSID_SECURITY                             6
+#define SECINITSID_IOPORT                               7
+#define SECINITSID_IOMEM                                8
+#define SECINITSID_IRQ                                  9
+#define SECINITSID_DEVICE                               10
 
-#define SECINITSID_NUM                                  11
+#define SECINITSID_NUM                                  10
 
 #endif
diff --git a/xen/xsm/flask/include/initial_sid_to_string.h b/xen/xsm/flask/include/initial_sid_to_string.h
index 3bf8ff2..814f4bf 100644
--- a/xen/xsm/flask/include/initial_sid_to_string.h
+++ b/xen/xsm/flask/include/initial_sid_to_string.h
@@ -4,14 +4,13 @@ static char *initial_sid_to_string[] =
     "null",
     "xen",
     "dom0",
-    "domU",
     "domio",
     "domxen",
     "unlabeled",
     "security",
     "ioport",
     "iomem",
-    "pirq",
+    "irq",
     "device",
 };
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 1eb8e4c..c810e9b 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1546,7 +1546,7 @@ int security_irq_sid(int pirq, u32 *out_sid)
     }
     else
     {
-        *out_sid = SECINITSID_PIRQ;
+        *out_sid = SECINITSID_IRQ;
     }
 
 out:
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgV-0007FX-Ur; Wed, 30 Nov 2011 23:35:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Df-JG
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:25 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322696084!5697448!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9415 invoked from network); 30 Nov 2011 23:34:44 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-216.messagelabs.com with SMTP;
	30 Nov 2011 23:34:44 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYi44027134
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:44 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2R032692; 
	Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:56 -0500
Message-Id: <1322696099-13849-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 5/8] xsm: Expand I/O resource hooks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The XSM hooks inside rangeset are not useful in capturing the PIRQ
mappings in HVM domains. They can also be called from softirq context
where current->domain is invalid, causing spurious AVC denials from
unrelated domains on such calls.

Within FLASK code, the rangeset hooks were already divided between IRQs,
I/O memory, and x86 IO ports; propagate this division back through the
XSM hooks and call the XSM functions directly when needed.

This removes XSM checks for the initial rangeset population for dom0 and
the removal checks on domain destruction; denying either of these
actions does not make sense.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/domctl.c  |   24 +++++++++++++--
 xen/arch/x86/irq.c     |    9 ++++++
 xen/arch/x86/physdev.c |    4 ++
 xen/common/domctl.c    |   10 +++++-
 xen/common/rangeset.c  |    8 -----
 xen/include/xsm/xsm.h  |   22 ++++++++------
 xen/xsm/dummy.c        |   14 ++++++---
 xen/xsm/flask/hooks.c  |   73 ++++++++++++------------------------------------
 8 files changed, 81 insertions(+), 83 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 5ed211f..a676f79 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -76,6 +76,7 @@ long arch_do_domctl(
         struct domain *d;
         unsigned int fp = domctl->u.ioport_permission.first_port;
         unsigned int np = domctl->u.ioport_permission.nr_ports;
+        int allow = domctl->u.ioport_permission.allow_access;
 
         ret = -EINVAL;
         if ( (fp + np) > 65536 )
@@ -87,7 +88,9 @@ long arch_do_domctl(
 
         if ( np == 0 )
             ret = 0;
-        else if ( domctl->u.ioport_permission.allow_access )
+        else if ( xsm_ioport_permission(d, fp, fp + np - 1, allow) )
+            ret = -EPERM;
+        else if ( allow )
             ret = ioports_permit_access(d, fp, fp + np - 1);
         else
             ret = ioports_deny_access(d, fp, fp + np - 1);
@@ -822,6 +825,7 @@ long arch_do_domctl(
         unsigned long gfn = domctl->u.memory_mapping.first_gfn;
         unsigned long mfn = domctl->u.memory_mapping.first_mfn;
         unsigned long nr_mfns = domctl->u.memory_mapping.nr_mfns;
+        int add = domctl->u.memory_mapping.add_mapping;
         int i;
 
         ret = -EINVAL;
@@ -837,8 +841,13 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret=0;
-        if ( domctl->u.memory_mapping.add_mapping )
+        ret = xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, add);
+        if ( ret ) {
+            rcu_unlock_domain(d);
+            break;
+        }
+
+        if ( add )
         {
             gdprintk(XENLOG_INFO,
                 "memory_map:add: gfn=%lx mfn=%lx nr_mfns=%lx\n",
@@ -871,6 +880,7 @@ long arch_do_domctl(
         unsigned int fgp = domctl->u.ioport_mapping.first_gport;
         unsigned int fmp = domctl->u.ioport_mapping.first_mport;
         unsigned int np = domctl->u.ioport_mapping.nr_ports;
+        unsigned int add = domctl->u.ioport_mapping.add_mapping;
         struct g2m_ioport *g2m_ioport;
         int found = 0;
 
@@ -893,8 +903,14 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
+        ret = xsm_ioport_permission(d, fmp, fmp + np - 1, add);
+        if ( ret ) {
+            rcu_unlock_domain(d);
+            break;
+        }
+
         hd = domain_hvm_iommu(d);
-        if ( domctl->u.ioport_mapping.add_mapping )
+        if ( add )
         {
             gdprintk(XENLOG_INFO,
                 "ioport_map:add f_gport=%x f_mport=%x np=%x\n",
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 9149096..b1c5d42 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -18,6 +18,7 @@
 #include <xen/iocap.h>
 #include <xen/iommu.h>
 #include <xen/trace.h>
+#include <xsm/xsm.h>
 #include <asm/msi.h>
 #include <asm/current.h>
 #include <asm/flushtlb.h>
@@ -1817,6 +1818,14 @@ int map_domain_pirq(
         return 0;
     }
 
+    ret = xsm_irq_permission(d, irq, 1);
+    if ( ret )
+    {
+        dprintk(XENLOG_G_ERR, "dom%d: could not permit access to irq %d mapping to pirq %d\n",
+                d->domain_id, irq, pirq);
+        return ret;
+    }
+
     ret = irq_permit_access(d, pirq);
     if ( ret )
     {
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 5c7ab68..5a4acae 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -229,6 +229,10 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( !IS_PRIV_FOR(current->domain, d) )
         goto free_domain;
 
+    ret = xsm_irq_permission(d, pirq, 0);
+    if ( ret )
+        goto free_domain;
+
     spin_lock(&pcidevs_lock);
     spin_lock(&d->event_lock);
     ret = unmap_domain_pirq(d, pirq);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 6705a57..06594a0 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -858,6 +858,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     {
         struct domain *d;
         unsigned int pirq = op->u.irq_permission.pirq;
+        int allow = op->u.irq_permission.allow_access;
 
         ret = -ESRCH;
         d = rcu_lock_domain_by_id(op->domain);
@@ -866,7 +867,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
         if ( pirq >= d->nr_pirqs )
             ret = -EINVAL;
-        else if ( op->u.irq_permission.allow_access )
+        else if ( xsm_irq_permission(d, pirq, allow) )
+            ret = -EPERM;
+        else if ( allow )
             ret = irq_permit_access(d, pirq);
         else
             ret = irq_deny_access(d, pirq);
@@ -880,6 +883,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         struct domain *d;
         unsigned long mfn = op->u.iomem_permission.first_mfn;
         unsigned long nr_mfns = op->u.iomem_permission.nr_mfns;
+        int allow = op->u.iomem_permission.allow_access;
 
         ret = -EINVAL;
         if ( (mfn + nr_mfns - 1) < mfn ) /* wrap? */
@@ -890,7 +894,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( d == NULL )
             break;
 
-        if ( op->u.iomem_permission.allow_access )
+        if ( xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, allow) )
+            ret = -EPERM;
+        else if ( allow )
             ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
         else
             ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index bb9523f..f09c0c4 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -97,10 +97,6 @@ int rangeset_add_range(
     struct range *x, *y;
     int rc = 0;
 
-    rc = xsm_add_range(r->domain, r->name, s, e);
-    if ( rc )
-        return rc;
-
     ASSERT(s <= e);
 
     spin_lock(&r->lock);
@@ -169,10 +165,6 @@ int rangeset_remove_range(
     struct range *x, *y, *t;
     int rc = 0;
 
-    rc = xsm_remove_range(r->domain, r->name, s, e);
-    if ( rc )
-        return rc;
-
     ASSERT(s <= e);
 
     spin_lock(&r->lock);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index da1f5d0..45fee21 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -106,8 +106,8 @@ struct xsm_operations {
 
     int (*kexec) (void);
     int (*schedop_shutdown) (struct domain *d1, struct domain *d2);
-    int (*add_range) (struct domain *d, char *name, unsigned long s, unsigned long e);
-    int (*remove_range) (struct domain *d, char *name, unsigned long s, unsigned long e);
+    int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
+    int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
 
     int (*test_assign_device) (uint32_t machine_bdf);
     int (*assign_device) (struct domain *d, uint32_t machine_bdf);
@@ -152,6 +152,7 @@ struct xsm_operations {
     int (*pin_mem_cacheattr) (struct domain *d);
     int (*ext_vcpucontext) (struct domain *d, uint32_t cmd);
     int (*vcpuextstate) (struct domain *d, uint32_t cmd);
+    int (*ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
 #endif
 };
 
@@ -415,16 +416,14 @@ static inline int xsm_schedop_shutdown (struct domain *d1, struct domain *d2)
     return xsm_call(schedop_shutdown(d1, d2));
 }
 
-static inline int xsm_add_range (struct domain *d, char *name, unsigned long s,
-                                                                        unsigned long e)
+static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
-    return xsm_call(add_range(d, name, s, e));
+    return xsm_call(irq_permission(d, pirq, allow));
 }
- 
-static inline int xsm_remove_range (struct domain *d, char *name, unsigned long s,
-                                                                        unsigned long e)
+
+static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(remove_range(d, name, s, e));
+    return xsm_call(iomem_permission(d, s, e, allow));
 }
 
 static inline int xsm_test_assign_device(uint32_t machine_bdf)
@@ -639,6 +638,11 @@ static inline int xsm_vcpuextstate(struct domain *d, uint32_t cmd)
 {
     return xsm_call(vcpuextstate(d, cmd));
 }
+
+static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return xsm_call(ioport_permission(d, s, e, allow));
+}
 #endif /* CONFIG_X86 */
 
 extern struct xsm_operations dummy_xsm_ops;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index ef461e6..a629396 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -273,13 +273,12 @@ static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
     return -ENOSYS;
 }
 
-static int dummy_add_range (struct domain *d, char *name, unsigned long s, unsigned long e)
+static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
 }
 
-static int dummy_remove_range (struct domain *d, char *name, unsigned long s, 
-                                                                        unsigned long e)
+static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
     return 0;
 }
@@ -462,6 +461,10 @@ static int dummy_vcpuextstate (struct domain *d, uint32_t cmd)
     return 0;
 }
 
+static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
 #endif
 
 struct xsm_operations dummy_xsm_ops;
@@ -536,8 +539,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, kexec);
     set_to_dummy_if_null(ops, schedop_shutdown);
 
-    set_to_dummy_if_null(ops, add_range);
-    set_to_dummy_if_null(ops, remove_range);
+    set_to_dummy_if_null(ops, irq_permission);
+    set_to_dummy_if_null(ops, iomem_permission);
 
     set_to_dummy_if_null(ops, __do_xsm_op);
 
@@ -577,5 +580,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
     set_to_dummy_if_null(ops, ext_vcpucontext);
     set_to_dummy_if_null(ops, vcpuextstate);
+    set_to_dummy_if_null(ops, ioport_permission);
 #endif
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 80c1f70..1bea498 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -643,7 +643,7 @@ static inline u32 resource_to_perm(uint8_t access)
         return RESOURCE__REMOVE;
 }
 
-static int irq_has_perm(struct domain *d, uint8_t pirq, uint8_t access)
+static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
 {
     u32 perm;
     u32 rsid;
@@ -678,10 +678,9 @@ static int irq_has_perm(struct domain *d, uint8_t pirq, uint8_t access)
         return rc;
 
     if ( access )
-        return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
+        rc = avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
                             RESOURCE__USE, &ad);
-    else
-        return rc;
+    return rc;
 }
 
 struct iomem_has_perm_data {
@@ -706,7 +705,7 @@ static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-static int iomem_has_perm(struct domain *d, unsigned long start, unsigned long end, uint8_t access)
+static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
 {
     struct iomem_has_perm_data data;
     int rc;
@@ -784,7 +783,7 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
 }
 
 
-static int ioport_has_perm(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
 {
     int rc;
     struct ioport_has_perm_data data;
@@ -1142,23 +1141,30 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
 {
     u32 rsid;
     int rc = -EPERM;
+    int irq;
     struct domain_security_struct *ssec, *tsec;
+    struct avc_audit_data ad;
 
     rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
-    rc = security_pirq_sid(bind->machine_irq, &rsid);
+    irq = domain_pirq_to_irq(d, bind->machine_irq);
+
+    rc = security_pirq_sid(irq, &rsid);
     if ( rc )
         return rc;
 
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = (unsigned long)irq;
+
     ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, NULL);
+    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
     if ( rc )
         return rc;
 
     tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
+    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_pin_mem_cacheattr (struct domain *d)
@@ -1205,50 +1211,6 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
 }
 #endif
 
-static int io_has_perm(struct domain *d, char *name, unsigned long s, 
-                       unsigned long e, u32 access)
-{
-    int rc = -EPERM;
-
-    if ( strcmp(name, "I/O Memory") == 0 )
-    {
-        rc = iomem_has_perm(d, s, e, access);
-        if ( rc )
-            return rc;
-    }
-    else if ( strcmp(name, "Interrupts") == 0 )
-    {
-        while (s <= e) {
-            rc = irq_has_perm(d, s, access);
-            if ( rc )
-                return rc;
-            s++;
-        }
-    }
-#ifdef CONFIG_X86
-    else if ( strcmp(name, "I/O Ports") == 0 )
-    {
-        rc = ioport_has_perm(d, s, e, access);
-        if ( rc )
-            return rc;
-    }
-#endif
-
-    return rc;    
-}
-
-static int flask_add_range(struct domain *d, char *name, unsigned long s,
-                           unsigned long e)
-{
-    return io_has_perm(d, name, s, e, 1);
-}
-
-static int flask_remove_range(struct domain *d, char *name, unsigned long s,
-                              unsigned long e)
-{
-    return io_has_perm(d, name, s, e, 0);
-}
-
 long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op);
 
 static struct xsm_operations flask_ops = {
@@ -1308,8 +1270,8 @@ static struct xsm_operations flask_ops = {
     .kexec = flask_kexec,
     .schedop_shutdown = flask_schedop_shutdown,
 
-    .add_range = flask_add_range,
-    .remove_range = flask_remove_range,
+    .irq_permission = flask_irq_permission,
+    .iomem_permission = flask_iomem_permission,
 
     .__do_xsm_op = do_flask_op,
 
@@ -1348,6 +1310,7 @@ static struct xsm_operations flask_ops = {
     .pin_mem_cacheattr = flask_pin_mem_cacheattr,
     .ext_vcpucontext = flask_ext_vcpucontext,
     .vcpuextstate = flask_vcpuextstate,
+    .ioport_permission = flask_ioport_permission,
 #endif
 };
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgO-0007Dn-K9; Wed, 30 Nov 2011 23:35:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgN-0007Db-A1
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:19 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322696049!46099946!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6165 invoked from network); 30 Nov 2011 23:34:09 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-27.messagelabs.com with SMTP;
	30 Nov 2011 23:34:09 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYhlP008864
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2O032692; 
	Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:53 -0500
Message-Id: <1322696099-13849-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 2/8] xsm: remove unused xsm_assign_vector check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The PHYSDEVOP_alloc_irq_vector hypercall is a noop, so its XSM check is
not useful. Remove it and the "event vector" FLASK permission.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |    1 -
 tools/flask/policy/policy/modules/xen/xen.if   |    1 -
 tools/flask/policy/policy/modules/xen/xen.te   |    1 -
 xen/arch/x86/physdev.c                         |    4 ----
 xen/include/xsm/xsm.h                          |    6 ------
 xen/xsm/dummy.c                                |    6 ------
 xen/xsm/flask/hooks.c                          |   13 -------------
 xen/xsm/flask/include/av_perm_to_string.h      |    3 +--
 xen/xsm/flask/include/av_permissions.h         |    3 +--
 9 files changed, 2 insertions(+), 36 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 9d09c5b..1b2687a 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -100,7 +100,6 @@ class event
 	status
 	notify
 	create
-    vector
     reset
 }
 
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index bf3b794..d12af74 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -67,7 +67,6 @@ define(`create_channel', `
 ###############################################################################
 define(`create_passthrough_resource', `
         type $3, resource_type;
-        allow $1 $3:event vector;
         allow $1 $2:resource {add remove};
         allow $1 ioport_t:resource {add_ioport use};
         allow $1 iomem_t:resource {add_iomem use};
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index d95a7da..8113467 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -31,7 +31,6 @@ scheduler physinfo heap quirk readconsole writeconsole settime microcode};
 
 allow dom0_t domio_t:mmu {map_read map_write};
 allow dom0_t iomem_t:mmu {map_read map_write};
-allow dom0_t pirq_t:event {vector};
 allow dom0_t xen_t:mmu {memorymap};
 
 allow dom0_t dom0_t:mmu {pinpage map_read map_write adjust updatemp};
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index cca56bb..5c7ab68 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -452,10 +452,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( !IS_PRIV(v->domain) )
             break;
 
-        ret = xsm_assign_vector(v->domain, irq_op.irq);
-        if ( ret )
-            break;
-
         /* Vector is only used by hypervisor, and dom0 shouldn't
            touch it in its world, return irq_op.irq as the vecotr,
            and make this hypercall dummy, and also defer the vector 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 1f70e87..82f510d 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -129,7 +129,6 @@ struct xsm_operations {
     int (*hvm_set_pci_link_route) (struct domain *d);
     int (*hvm_inject_msi) (struct domain *d);
     int (*apic) (struct domain *d, int cmd);
-    int (*assign_vector) (struct domain *d, uint32_t pirq);
     int (*xen_settime) (void);
     int (*memtype) (uint32_t access);
     int (*microcode) (void);
@@ -535,11 +534,6 @@ static inline int xsm_apic (struct domain *d, int cmd)
     return xsm_call(apic(d, cmd));
 }
 
-static inline int xsm_assign_vector (struct domain *d, uint32_t pirq)
-{
-    return xsm_call(assign_vector(d, pirq));
-}
-
 static inline int xsm_xen_settime (void)
 {
     return xsm_call(xen_settime());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 6536948..1b50d0e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -345,11 +345,6 @@ static int dummy_apic (struct domain *d, int cmd)
     return 0;
 }
 
-static int dummy_assign_vector (struct domain *d, uint32_t pirq)
-{
-    return 0;
-}
-
 static int dummy_xen_settime (void)
 {
     return 0;
@@ -560,7 +555,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
     set_to_dummy_if_null(ops, apic);
-    set_to_dummy_if_null(ops, assign_vector);
     set_to_dummy_if_null(ops, xen_settime);
     set_to_dummy_if_null(ops, memtype);
     set_to_dummy_if_null(ops, microcode);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 37b297e..97ae4d9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -907,18 +907,6 @@ static int flask_apic(struct domain *d, int cmd)
     return domain_has_xen(d, perm);
 }
 
-static int flask_assign_vector(struct domain *d, uint32_t pirq)
-{
-    u32 psid;
-    struct domain_security_struct *dsec;
-    dsec = d->ssid;
-
-    if ( security_pirq_sid(pirq, &psid) )
-        return -EPERM;
-
-    return avc_has_perm(dsec->sid, psid, SECCLASS_EVENT, EVENT__VECTOR, NULL);
-}
-
 static int flask_xen_settime(void)
 {
     return domain_has_xen(current->domain, XEN__SETTIME);
@@ -1306,7 +1294,6 @@ static struct xsm_operations flask_ops = {
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
     .apic = flask_apic,
-    .assign_vector = flask_assign_vector,
     .xen_settime = flask_xen_settime,
     .memtype = flask_memtype,
     .microcode = flask_microcode,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index c32488e..70aa02d 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -56,18 +56,17 @@
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
    S_(SECCLASS_HVM, HVM__GETPARAM, "getparam")
-   S_(SECCLASS_HVM, HVM__TRACKDIRTYVRAM, "trackdirtyvram")
    S_(SECCLASS_HVM, HVM__PCILEVEL, "pcilevel")
    S_(SECCLASS_HVM, HVM__IRQLEVEL, "irqlevel")
    S_(SECCLASS_HVM, HVM__PCIROUTE, "pciroute")
    S_(SECCLASS_HVM, HVM__BIND_IRQ, "bind_irq")
    S_(SECCLASS_HVM, HVM__CACHEATTR, "cacheattr")
+   S_(SECCLASS_HVM, HVM__TRACKDIRTYVRAM, "trackdirtyvram")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
    S_(SECCLASS_EVENT, EVENT__NOTIFY, "notify")
    S_(SECCLASS_EVENT, EVENT__CREATE, "create")
-   S_(SECCLASS_EVENT, EVENT__VECTOR, "vector")
    S_(SECCLASS_EVENT, EVENT__RESET, "reset")
    S_(SECCLASS_GRANT, GRANT__MAP_READ, "map_read")
    S_(SECCLASS_GRANT, GRANT__MAP_WRITE, "map_write")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index f5dcc6f..4c2ffb6 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -70,8 +70,7 @@
 #define EVENT__STATUS                             0x00000004UL
 #define EVENT__NOTIFY                             0x00000008UL
 #define EVENT__CREATE                             0x00000010UL
-#define EVENT__VECTOR                             0x00000020UL
-#define EVENT__RESET                              0x00000040UL
+#define EVENT__RESET                              0x00000020UL
 
 #define GRANT__MAP_READ                           0x00000001UL
 #define GRANT__MAP_WRITE                          0x00000002UL
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgV-0007FX-Ur; Wed, 30 Nov 2011 23:35:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Df-JG
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:25 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1322696084!5697448!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9415 invoked from network); 30 Nov 2011 23:34:44 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-216.messagelabs.com with SMTP;
	30 Nov 2011 23:34:44 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYi44027134
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:44 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2R032692; 
	Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:56 -0500
Message-Id: <1322696099-13849-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 5/8] xsm: Expand I/O resource hooks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The XSM hooks inside rangeset are not useful in capturing the PIRQ
mappings in HVM domains. They can also be called from softirq context
where current->domain is invalid, causing spurious AVC denials from
unrelated domains on such calls.

Within FLASK code, the rangeset hooks were already divided between IRQs,
I/O memory, and x86 IO ports; propagate this division back through the
XSM hooks and call the XSM functions directly when needed.

This removes XSM checks for the initial rangeset population for dom0 and
the removal checks on domain destruction; denying either of these
actions does not make sense.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/domctl.c  |   24 +++++++++++++--
 xen/arch/x86/irq.c     |    9 ++++++
 xen/arch/x86/physdev.c |    4 ++
 xen/common/domctl.c    |   10 +++++-
 xen/common/rangeset.c  |    8 -----
 xen/include/xsm/xsm.h  |   22 ++++++++------
 xen/xsm/dummy.c        |   14 ++++++---
 xen/xsm/flask/hooks.c  |   73 ++++++++++++------------------------------------
 8 files changed, 81 insertions(+), 83 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 5ed211f..a676f79 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -76,6 +76,7 @@ long arch_do_domctl(
         struct domain *d;
         unsigned int fp = domctl->u.ioport_permission.first_port;
         unsigned int np = domctl->u.ioport_permission.nr_ports;
+        int allow = domctl->u.ioport_permission.allow_access;
 
         ret = -EINVAL;
         if ( (fp + np) > 65536 )
@@ -87,7 +88,9 @@ long arch_do_domctl(
 
         if ( np == 0 )
             ret = 0;
-        else if ( domctl->u.ioport_permission.allow_access )
+        else if ( xsm_ioport_permission(d, fp, fp + np - 1, allow) )
+            ret = -EPERM;
+        else if ( allow )
             ret = ioports_permit_access(d, fp, fp + np - 1);
         else
             ret = ioports_deny_access(d, fp, fp + np - 1);
@@ -822,6 +825,7 @@ long arch_do_domctl(
         unsigned long gfn = domctl->u.memory_mapping.first_gfn;
         unsigned long mfn = domctl->u.memory_mapping.first_mfn;
         unsigned long nr_mfns = domctl->u.memory_mapping.nr_mfns;
+        int add = domctl->u.memory_mapping.add_mapping;
         int i;
 
         ret = -EINVAL;
@@ -837,8 +841,13 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret=0;
-        if ( domctl->u.memory_mapping.add_mapping )
+        ret = xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, add);
+        if ( ret ) {
+            rcu_unlock_domain(d);
+            break;
+        }
+
+        if ( add )
         {
             gdprintk(XENLOG_INFO,
                 "memory_map:add: gfn=%lx mfn=%lx nr_mfns=%lx\n",
@@ -871,6 +880,7 @@ long arch_do_domctl(
         unsigned int fgp = domctl->u.ioport_mapping.first_gport;
         unsigned int fmp = domctl->u.ioport_mapping.first_mport;
         unsigned int np = domctl->u.ioport_mapping.nr_ports;
+        unsigned int add = domctl->u.ioport_mapping.add_mapping;
         struct g2m_ioport *g2m_ioport;
         int found = 0;
 
@@ -893,8 +903,14 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
+        ret = xsm_ioport_permission(d, fmp, fmp + np - 1, add);
+        if ( ret ) {
+            rcu_unlock_domain(d);
+            break;
+        }
+
         hd = domain_hvm_iommu(d);
-        if ( domctl->u.ioport_mapping.add_mapping )
+        if ( add )
         {
             gdprintk(XENLOG_INFO,
                 "ioport_map:add f_gport=%x f_mport=%x np=%x\n",
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 9149096..b1c5d42 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -18,6 +18,7 @@
 #include <xen/iocap.h>
 #include <xen/iommu.h>
 #include <xen/trace.h>
+#include <xsm/xsm.h>
 #include <asm/msi.h>
 #include <asm/current.h>
 #include <asm/flushtlb.h>
@@ -1817,6 +1818,14 @@ int map_domain_pirq(
         return 0;
     }
 
+    ret = xsm_irq_permission(d, irq, 1);
+    if ( ret )
+    {
+        dprintk(XENLOG_G_ERR, "dom%d: could not permit access to irq %d mapping to pirq %d\n",
+                d->domain_id, irq, pirq);
+        return ret;
+    }
+
     ret = irq_permit_access(d, pirq);
     if ( ret )
     {
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 5c7ab68..5a4acae 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -229,6 +229,10 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( !IS_PRIV_FOR(current->domain, d) )
         goto free_domain;
 
+    ret = xsm_irq_permission(d, pirq, 0);
+    if ( ret )
+        goto free_domain;
+
     spin_lock(&pcidevs_lock);
     spin_lock(&d->event_lock);
     ret = unmap_domain_pirq(d, pirq);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 6705a57..06594a0 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -858,6 +858,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     {
         struct domain *d;
         unsigned int pirq = op->u.irq_permission.pirq;
+        int allow = op->u.irq_permission.allow_access;
 
         ret = -ESRCH;
         d = rcu_lock_domain_by_id(op->domain);
@@ -866,7 +867,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
         if ( pirq >= d->nr_pirqs )
             ret = -EINVAL;
-        else if ( op->u.irq_permission.allow_access )
+        else if ( xsm_irq_permission(d, pirq, allow) )
+            ret = -EPERM;
+        else if ( allow )
             ret = irq_permit_access(d, pirq);
         else
             ret = irq_deny_access(d, pirq);
@@ -880,6 +883,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         struct domain *d;
         unsigned long mfn = op->u.iomem_permission.first_mfn;
         unsigned long nr_mfns = op->u.iomem_permission.nr_mfns;
+        int allow = op->u.iomem_permission.allow_access;
 
         ret = -EINVAL;
         if ( (mfn + nr_mfns - 1) < mfn ) /* wrap? */
@@ -890,7 +894,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( d == NULL )
             break;
 
-        if ( op->u.iomem_permission.allow_access )
+        if ( xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, allow) )
+            ret = -EPERM;
+        else if ( allow )
             ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
         else
             ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index bb9523f..f09c0c4 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -97,10 +97,6 @@ int rangeset_add_range(
     struct range *x, *y;
     int rc = 0;
 
-    rc = xsm_add_range(r->domain, r->name, s, e);
-    if ( rc )
-        return rc;
-
     ASSERT(s <= e);
 
     spin_lock(&r->lock);
@@ -169,10 +165,6 @@ int rangeset_remove_range(
     struct range *x, *y, *t;
     int rc = 0;
 
-    rc = xsm_remove_range(r->domain, r->name, s, e);
-    if ( rc )
-        return rc;
-
     ASSERT(s <= e);
 
     spin_lock(&r->lock);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index da1f5d0..45fee21 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -106,8 +106,8 @@ struct xsm_operations {
 
     int (*kexec) (void);
     int (*schedop_shutdown) (struct domain *d1, struct domain *d2);
-    int (*add_range) (struct domain *d, char *name, unsigned long s, unsigned long e);
-    int (*remove_range) (struct domain *d, char *name, unsigned long s, unsigned long e);
+    int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
+    int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
 
     int (*test_assign_device) (uint32_t machine_bdf);
     int (*assign_device) (struct domain *d, uint32_t machine_bdf);
@@ -152,6 +152,7 @@ struct xsm_operations {
     int (*pin_mem_cacheattr) (struct domain *d);
     int (*ext_vcpucontext) (struct domain *d, uint32_t cmd);
     int (*vcpuextstate) (struct domain *d, uint32_t cmd);
+    int (*ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
 #endif
 };
 
@@ -415,16 +416,14 @@ static inline int xsm_schedop_shutdown (struct domain *d1, struct domain *d2)
     return xsm_call(schedop_shutdown(d1, d2));
 }
 
-static inline int xsm_add_range (struct domain *d, char *name, unsigned long s,
-                                                                        unsigned long e)
+static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
-    return xsm_call(add_range(d, name, s, e));
+    return xsm_call(irq_permission(d, pirq, allow));
 }
- 
-static inline int xsm_remove_range (struct domain *d, char *name, unsigned long s,
-                                                                        unsigned long e)
+
+static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(remove_range(d, name, s, e));
+    return xsm_call(iomem_permission(d, s, e, allow));
 }
 
 static inline int xsm_test_assign_device(uint32_t machine_bdf)
@@ -639,6 +638,11 @@ static inline int xsm_vcpuextstate(struct domain *d, uint32_t cmd)
 {
     return xsm_call(vcpuextstate(d, cmd));
 }
+
+static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return xsm_call(ioport_permission(d, s, e, allow));
+}
 #endif /* CONFIG_X86 */
 
 extern struct xsm_operations dummy_xsm_ops;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index ef461e6..a629396 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -273,13 +273,12 @@ static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
     return -ENOSYS;
 }
 
-static int dummy_add_range (struct domain *d, char *name, unsigned long s, unsigned long e)
+static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
 }
 
-static int dummy_remove_range (struct domain *d, char *name, unsigned long s, 
-                                                                        unsigned long e)
+static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
     return 0;
 }
@@ -462,6 +461,10 @@ static int dummy_vcpuextstate (struct domain *d, uint32_t cmd)
     return 0;
 }
 
+static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
 #endif
 
 struct xsm_operations dummy_xsm_ops;
@@ -536,8 +539,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, kexec);
     set_to_dummy_if_null(ops, schedop_shutdown);
 
-    set_to_dummy_if_null(ops, add_range);
-    set_to_dummy_if_null(ops, remove_range);
+    set_to_dummy_if_null(ops, irq_permission);
+    set_to_dummy_if_null(ops, iomem_permission);
 
     set_to_dummy_if_null(ops, __do_xsm_op);
 
@@ -577,5 +580,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
     set_to_dummy_if_null(ops, ext_vcpucontext);
     set_to_dummy_if_null(ops, vcpuextstate);
+    set_to_dummy_if_null(ops, ioport_permission);
 #endif
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 80c1f70..1bea498 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -643,7 +643,7 @@ static inline u32 resource_to_perm(uint8_t access)
         return RESOURCE__REMOVE;
 }
 
-static int irq_has_perm(struct domain *d, uint8_t pirq, uint8_t access)
+static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
 {
     u32 perm;
     u32 rsid;
@@ -678,10 +678,9 @@ static int irq_has_perm(struct domain *d, uint8_t pirq, uint8_t access)
         return rc;
 
     if ( access )
-        return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
+        rc = avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
                             RESOURCE__USE, &ad);
-    else
-        return rc;
+    return rc;
 }
 
 struct iomem_has_perm_data {
@@ -706,7 +705,7 @@ static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-static int iomem_has_perm(struct domain *d, unsigned long start, unsigned long end, uint8_t access)
+static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
 {
     struct iomem_has_perm_data data;
     int rc;
@@ -784,7 +783,7 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
 }
 
 
-static int ioport_has_perm(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
 {
     int rc;
     struct ioport_has_perm_data data;
@@ -1142,23 +1141,30 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
 {
     u32 rsid;
     int rc = -EPERM;
+    int irq;
     struct domain_security_struct *ssec, *tsec;
+    struct avc_audit_data ad;
 
     rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
-    rc = security_pirq_sid(bind->machine_irq, &rsid);
+    irq = domain_pirq_to_irq(d, bind->machine_irq);
+
+    rc = security_pirq_sid(irq, &rsid);
     if ( rc )
         return rc;
 
+    AVC_AUDIT_DATA_INIT(&ad, DEV);
+    ad.device = (unsigned long)irq;
+
     ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, NULL);
+    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
     if ( rc )
         return rc;
 
     tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
+    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_pin_mem_cacheattr (struct domain *d)
@@ -1205,50 +1211,6 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
 }
 #endif
 
-static int io_has_perm(struct domain *d, char *name, unsigned long s, 
-                       unsigned long e, u32 access)
-{
-    int rc = -EPERM;
-
-    if ( strcmp(name, "I/O Memory") == 0 )
-    {
-        rc = iomem_has_perm(d, s, e, access);
-        if ( rc )
-            return rc;
-    }
-    else if ( strcmp(name, "Interrupts") == 0 )
-    {
-        while (s <= e) {
-            rc = irq_has_perm(d, s, access);
-            if ( rc )
-                return rc;
-            s++;
-        }
-    }
-#ifdef CONFIG_X86
-    else if ( strcmp(name, "I/O Ports") == 0 )
-    {
-        rc = ioport_has_perm(d, s, e, access);
-        if ( rc )
-            return rc;
-    }
-#endif
-
-    return rc;    
-}
-
-static int flask_add_range(struct domain *d, char *name, unsigned long s,
-                           unsigned long e)
-{
-    return io_has_perm(d, name, s, e, 1);
-}
-
-static int flask_remove_range(struct domain *d, char *name, unsigned long s,
-                              unsigned long e)
-{
-    return io_has_perm(d, name, s, e, 0);
-}
-
 long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op);
 
 static struct xsm_operations flask_ops = {
@@ -1308,8 +1270,8 @@ static struct xsm_operations flask_ops = {
     .kexec = flask_kexec,
     .schedop_shutdown = flask_schedop_shutdown,
 
-    .add_range = flask_add_range,
-    .remove_range = flask_remove_range,
+    .irq_permission = flask_irq_permission,
+    .iomem_permission = flask_iomem_permission,
 
     .__do_xsm_op = do_flask_op,
 
@@ -1348,6 +1310,7 @@ static struct xsm_operations flask_ops = {
     .pin_mem_cacheattr = flask_pin_mem_cacheattr,
     .ext_vcpucontext = flask_ext_vcpucontext,
     .vcpuextstate = flask_vcpuextstate,
+    .ioport_permission = flask_ioport_permission,
 #endif
 };
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgT-0007Eo-Qy; Wed, 30 Nov 2011 23:35:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Dd-Fs
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322696084!193345!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7122 invoked from network); 30 Nov 2011 23:34:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-21.messagelabs.com with SMTP;
	30 Nov 2011 23:34:45 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYilP008867
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:44 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2S032692; 
	Wed, 30 Nov 2011 18:34:44 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:57 -0500
Message-Id: <1322696099-13849-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 6/8] xsm: rename security_pirq_sid to
	security_irq_sid
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Attempting to manage the PIRQ namespace is not useful as guests can
assign any mapping of IRQ to PIRQ (although the identity mapping is the
most common). Change the internal names to reflect this change.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c            |    4 ++--
 xen/xsm/flask/include/security.h |    2 +-
 xen/xsm/flask/ss/services.c      |    4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 1bea498..0feb070 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -666,7 +666,7 @@ static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
     ssec = current->domain->ssid;
     tsec = d->ssid;
 
-    rc = security_pirq_sid(pirq, &rsid);
+    rc = security_irq_sid(pirq, &rsid);
     if ( rc )
         return rc;
 
@@ -1151,7 +1151,7 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
 
     irq = domain_pirq_to_irq(d, bind->machine_irq);
 
-    rc = security_pirq_sid(irq, &rsid);
+    rc = security_irq_sid(irq, &rsid);
     if ( rc )
         return rc;
 
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 0dc21c8..67ca6d0 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -71,7 +71,7 @@ int security_context_to_sid(char *scontext, u32 scontext_len, u32 *out_sid);
 
 int security_get_user_sids(u32 callsid, char *username, u32 **sids, u32 *nel);
 
-int security_pirq_sid(int pirq, u32 *out_sid);
+int security_irq_sid(int pirq, u32 *out_sid);
 
 int security_iomem_sid(unsigned long, u32 *out_sid);
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index b880762..1eb8e4c 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1514,11 +1514,11 @@ err:
 }
 
 /**
- * security_pirq_sid - Obtain the SID for a physical irq.
+ * security_irq_sid - Obtain the SID for a physical irq.
  * @pirq: physical irq
  * @out_sid: security identifier
  */
-int security_pirq_sid(int pirq, u32 *out_sid)
+int security_irq_sid(int pirq, u32 *out_sid)
 {
     int rc = 0;
     struct ocontext *c;
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgT-0007ER-1i; Wed, 30 Nov 2011 23:35:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgQ-0007De-LV
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1322696054!50647443!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12075 invoked from network); 30 Nov 2011 23:34:14 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-27.messagelabs.com with SMTP;
	30 Nov 2011 23:34:14 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYi44027135
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:44 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2T032692; 
	Wed, 30 Nov 2011 18:34:44 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:58 -0500
Message-Id: <1322696099-13849-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 7/8] xsm: clean up initial SIDs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The domU SID is never used before a policy load, and so does not belong
in the initial_sids list.

The PIRQ SID is now incorrectly named; it should simply be called IRQ.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/initial_sids  |    3 +--
 tools/flask/policy/policy/modules/xen/xen.if  |    4 ++--
 tools/flask/policy/policy/modules/xen/xen.te  |    9 ++++-----
 xen/xsm/flask/include/flask.h                 |   19 +++++++++----------
 xen/xsm/flask/include/initial_sid_to_string.h |    3 +--
 xen/xsm/flask/ss/services.c                   |    2 +-
 6 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/tools/flask/policy/policy/flask/initial_sids b/tools/flask/policy/policy/flask/initial_sids
index 9b78fba..e508bde 100644
--- a/tools/flask/policy/policy/flask/initial_sids
+++ b/tools/flask/policy/policy/flask/initial_sids
@@ -5,13 +5,12 @@
 #
 sid xen
 sid dom0
-sid domU
 sid domio
 sid domxen
 sid unlabeled
 sid security
 sid ioport
 sid iomem
-sid pirq
+sid irq
 sid device
 # FLASK
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index d12af74..1b50898 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -70,10 +70,10 @@ define(`create_passthrough_resource', `
         allow $1 $2:resource {add remove};
         allow $1 ioport_t:resource {add_ioport use};
         allow $1 iomem_t:resource {add_iomem use};
-        allow $1 pirq_t:resource  {add_irq use};
+        allow $1 irq_t:resource  {add_irq use};
         allow $1 domio_t:mmu {map_read map_write};
         allow $2 domio_t:mmu {map_write};
-        allow $2 pirq_t:resource {use};
+        allow $2 irq_t:resource {use};
         allow $1 $3:resource {add_irq add_iomem add_ioport remove_irq remove_iomem remove_ioport use add_device remove_device};
         allow $2 $3:resource {use add_ioport add_iomem remove_ioport remove_iomem};
         allow $2 $3:mmu {map_read map_write};
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 8113467..1a7f29a 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -16,7 +16,7 @@ type unlabeled_t, domain_type;
 
 type security_t, domain_type;
 
-type pirq_t, resource_type;
+type irq_t, resource_type;
 type ioport_t, resource_type;
 type iomem_t, resource_type;
 type device_t, resource_type;
@@ -43,8 +43,8 @@ allow xen_t ioport_t:resource {add_ioport remove_ioport};
 allow dom0_t ioport_t:resource {use};
 allow xen_t iomem_t:resource {add_iomem remove_iomem};
 allow dom0_t iomem_t:resource {use};
-allow xen_t pirq_t:resource {add_irq remove_irq};
-allow dom0_t pirq_t:resource { add_irq remove_irq use};
+allow xen_t irq_t:resource {add_irq remove_irq};
+allow dom0_t irq_t:resource { add_irq remove_irq use};
 allow dom0_t dom0_t:resource { add remove };
 allow dom0_t xen_t:xen firmware;
 
@@ -140,12 +140,11 @@ manage_domain(dom0_t, domHU_t)
 ################################################################################
 sid xen gen_context(system_u:system_r:xen_t,s0)
 sid dom0 gen_context(system_u:system_r:dom0_t,s0)
-sid domU gen_context(system_u:system_r:domU_t,s0)
 sid domxen gen_context(system_u:system_r:domxen_t,s0)
 sid domio gen_context(system_u:system_r:domio_t,s0)
 sid unlabeled gen_context(system_u:system_r:unlabeled_t,s0)
 sid security gen_context(system_u:system_r:security_t,s0)
-sid pirq gen_context(system_u:object_r:pirq_t,s0)
+sid irq gen_context(system_u:object_r:irq_t,s0)
 sid iomem gen_context(system_u:object_r:iomem_t,s0)
 sid ioport gen_context(system_u:object_r:ioport_t,s0)
 sid device gen_context(system_u:object_r:device_t,s0)
diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
index 333edcd..6d29c5a 100644
--- a/xen/xsm/flask/include/flask.h
+++ b/xen/xsm/flask/include/flask.h
@@ -20,16 +20,15 @@
  */
 #define SECINITSID_XEN                                  1
 #define SECINITSID_DOM0                                 2
-#define SECINITSID_DOMU                                 3
-#define SECINITSID_DOMIO                                4
-#define SECINITSID_DOMXEN                               5
-#define SECINITSID_UNLABELED                            6
-#define SECINITSID_SECURITY                             7
-#define SECINITSID_IOPORT                               8
-#define SECINITSID_IOMEM                                9
-#define SECINITSID_PIRQ                                 10
-#define SECINITSID_DEVICE                               11
+#define SECINITSID_DOMIO                                3
+#define SECINITSID_DOMXEN                               4
+#define SECINITSID_UNLABELED                            5
+#define SECINITSID_SECURITY                             6
+#define SECINITSID_IOPORT                               7
+#define SECINITSID_IOMEM                                8
+#define SECINITSID_IRQ                                  9
+#define SECINITSID_DEVICE                               10
 
-#define SECINITSID_NUM                                  11
+#define SECINITSID_NUM                                  10
 
 #endif
diff --git a/xen/xsm/flask/include/initial_sid_to_string.h b/xen/xsm/flask/include/initial_sid_to_string.h
index 3bf8ff2..814f4bf 100644
--- a/xen/xsm/flask/include/initial_sid_to_string.h
+++ b/xen/xsm/flask/include/initial_sid_to_string.h
@@ -4,14 +4,13 @@ static char *initial_sid_to_string[] =
     "null",
     "xen",
     "dom0",
-    "domU",
     "domio",
     "domxen",
     "unlabeled",
     "security",
     "ioport",
     "iomem",
-    "pirq",
+    "irq",
     "device",
 };
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 1eb8e4c..c810e9b 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1546,7 +1546,7 @@ int security_irq_sid(int pirq, u32 *out_sid)
     }
     else
     {
-        *out_sid = SECINITSID_PIRQ;
+        *out_sid = SECINITSID_IRQ;
     }
 
 out:
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgO-0007Dn-K9; Wed, 30 Nov 2011 23:35:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgN-0007Db-A1
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:19 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-27.messagelabs.com!1322696049!46099946!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6165 invoked from network); 30 Nov 2011 23:34:09 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-27.messagelabs.com with SMTP;
	30 Nov 2011 23:34:09 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYhlP008864
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2O032692; 
	Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:53 -0500
Message-Id: <1322696099-13849-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 2/8] xsm: remove unused xsm_assign_vector check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The PHYSDEVOP_alloc_irq_vector hypercall is a noop, so its XSM check is
not useful. Remove it and the "event vector" FLASK permission.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |    1 -
 tools/flask/policy/policy/modules/xen/xen.if   |    1 -
 tools/flask/policy/policy/modules/xen/xen.te   |    1 -
 xen/arch/x86/physdev.c                         |    4 ----
 xen/include/xsm/xsm.h                          |    6 ------
 xen/xsm/dummy.c                                |    6 ------
 xen/xsm/flask/hooks.c                          |   13 -------------
 xen/xsm/flask/include/av_perm_to_string.h      |    3 +--
 xen/xsm/flask/include/av_permissions.h         |    3 +--
 9 files changed, 2 insertions(+), 36 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 9d09c5b..1b2687a 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -100,7 +100,6 @@ class event
 	status
 	notify
 	create
-    vector
     reset
 }
 
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index bf3b794..d12af74 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -67,7 +67,6 @@ define(`create_channel', `
 ###############################################################################
 define(`create_passthrough_resource', `
         type $3, resource_type;
-        allow $1 $3:event vector;
         allow $1 $2:resource {add remove};
         allow $1 ioport_t:resource {add_ioport use};
         allow $1 iomem_t:resource {add_iomem use};
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index d95a7da..8113467 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -31,7 +31,6 @@ scheduler physinfo heap quirk readconsole writeconsole settime microcode};
 
 allow dom0_t domio_t:mmu {map_read map_write};
 allow dom0_t iomem_t:mmu {map_read map_write};
-allow dom0_t pirq_t:event {vector};
 allow dom0_t xen_t:mmu {memorymap};
 
 allow dom0_t dom0_t:mmu {pinpage map_read map_write adjust updatemp};
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index cca56bb..5c7ab68 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -452,10 +452,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( !IS_PRIV(v->domain) )
             break;
 
-        ret = xsm_assign_vector(v->domain, irq_op.irq);
-        if ( ret )
-            break;
-
         /* Vector is only used by hypervisor, and dom0 shouldn't
            touch it in its world, return irq_op.irq as the vecotr,
            and make this hypercall dummy, and also defer the vector 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 1f70e87..82f510d 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -129,7 +129,6 @@ struct xsm_operations {
     int (*hvm_set_pci_link_route) (struct domain *d);
     int (*hvm_inject_msi) (struct domain *d);
     int (*apic) (struct domain *d, int cmd);
-    int (*assign_vector) (struct domain *d, uint32_t pirq);
     int (*xen_settime) (void);
     int (*memtype) (uint32_t access);
     int (*microcode) (void);
@@ -535,11 +534,6 @@ static inline int xsm_apic (struct domain *d, int cmd)
     return xsm_call(apic(d, cmd));
 }
 
-static inline int xsm_assign_vector (struct domain *d, uint32_t pirq)
-{
-    return xsm_call(assign_vector(d, pirq));
-}
-
 static inline int xsm_xen_settime (void)
 {
     return xsm_call(xen_settime());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 6536948..1b50d0e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -345,11 +345,6 @@ static int dummy_apic (struct domain *d, int cmd)
     return 0;
 }
 
-static int dummy_assign_vector (struct domain *d, uint32_t pirq)
-{
-    return 0;
-}
-
 static int dummy_xen_settime (void)
 {
     return 0;
@@ -560,7 +555,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
     set_to_dummy_if_null(ops, apic);
-    set_to_dummy_if_null(ops, assign_vector);
     set_to_dummy_if_null(ops, xen_settime);
     set_to_dummy_if_null(ops, memtype);
     set_to_dummy_if_null(ops, microcode);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 37b297e..97ae4d9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -907,18 +907,6 @@ static int flask_apic(struct domain *d, int cmd)
     return domain_has_xen(d, perm);
 }
 
-static int flask_assign_vector(struct domain *d, uint32_t pirq)
-{
-    u32 psid;
-    struct domain_security_struct *dsec;
-    dsec = d->ssid;
-
-    if ( security_pirq_sid(pirq, &psid) )
-        return -EPERM;
-
-    return avc_has_perm(dsec->sid, psid, SECCLASS_EVENT, EVENT__VECTOR, NULL);
-}
-
 static int flask_xen_settime(void)
 {
     return domain_has_xen(current->domain, XEN__SETTIME);
@@ -1306,7 +1294,6 @@ static struct xsm_operations flask_ops = {
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
     .apic = flask_apic,
-    .assign_vector = flask_assign_vector,
     .xen_settime = flask_xen_settime,
     .memtype = flask_memtype,
     .microcode = flask_microcode,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index c32488e..70aa02d 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -56,18 +56,17 @@
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
    S_(SECCLASS_HVM, HVM__GETPARAM, "getparam")
-   S_(SECCLASS_HVM, HVM__TRACKDIRTYVRAM, "trackdirtyvram")
    S_(SECCLASS_HVM, HVM__PCILEVEL, "pcilevel")
    S_(SECCLASS_HVM, HVM__IRQLEVEL, "irqlevel")
    S_(SECCLASS_HVM, HVM__PCIROUTE, "pciroute")
    S_(SECCLASS_HVM, HVM__BIND_IRQ, "bind_irq")
    S_(SECCLASS_HVM, HVM__CACHEATTR, "cacheattr")
+   S_(SECCLASS_HVM, HVM__TRACKDIRTYVRAM, "trackdirtyvram")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
    S_(SECCLASS_EVENT, EVENT__NOTIFY, "notify")
    S_(SECCLASS_EVENT, EVENT__CREATE, "create")
-   S_(SECCLASS_EVENT, EVENT__VECTOR, "vector")
    S_(SECCLASS_EVENT, EVENT__RESET, "reset")
    S_(SECCLASS_GRANT, GRANT__MAP_READ, "map_read")
    S_(SECCLASS_GRANT, GRANT__MAP_WRITE, "map_write")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index f5dcc6f..4c2ffb6 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -70,8 +70,7 @@
 #define EVENT__STATUS                             0x00000004UL
 #define EVENT__NOTIFY                             0x00000008UL
 #define EVENT__CREATE                             0x00000010UL
-#define EVENT__VECTOR                             0x00000020UL
-#define EVENT__RESET                              0x00000040UL
+#define EVENT__RESET                              0x00000020UL
 
 #define GRANT__MAP_READ                           0x00000001UL
 #define GRANT__MAP_WRITE                          0x00000002UL
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgT-0007Eo-Qy; Wed, 30 Nov 2011 23:35:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Dd-Fs
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-21.messagelabs.com!1322696084!193345!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7122 invoked from network); 30 Nov 2011 23:34:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-21.messagelabs.com with SMTP;
	30 Nov 2011 23:34:45 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYilP008867
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:44 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2S032692; 
	Wed, 30 Nov 2011 18:34:44 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:57 -0500
Message-Id: <1322696099-13849-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 6/8] xsm: rename security_pirq_sid to
	security_irq_sid
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Attempting to manage the PIRQ namespace is not useful as guests can
assign any mapping of IRQ to PIRQ (although the identity mapping is the
most common). Change the internal names to reflect this change.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c            |    4 ++--
 xen/xsm/flask/include/security.h |    2 +-
 xen/xsm/flask/ss/services.c      |    4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 1bea498..0feb070 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -666,7 +666,7 @@ static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
     ssec = current->domain->ssid;
     tsec = d->ssid;
 
-    rc = security_pirq_sid(pirq, &rsid);
+    rc = security_irq_sid(pirq, &rsid);
     if ( rc )
         return rc;
 
@@ -1151,7 +1151,7 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
 
     irq = domain_pirq_to_irq(d, bind->machine_irq);
 
-    rc = security_pirq_sid(irq, &rsid);
+    rc = security_irq_sid(irq, &rsid);
     if ( rc )
         return rc;
 
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 0dc21c8..67ca6d0 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -71,7 +71,7 @@ int security_context_to_sid(char *scontext, u32 scontext_len, u32 *out_sid);
 
 int security_get_user_sids(u32 callsid, char *username, u32 **sids, u32 *nel);
 
-int security_pirq_sid(int pirq, u32 *out_sid);
+int security_irq_sid(int pirq, u32 *out_sid);
 
 int security_iomem_sid(unsigned long, u32 *out_sid);
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index b880762..1eb8e4c 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1514,11 +1514,11 @@ err:
 }
 
 /**
- * security_pirq_sid - Obtain the SID for a physical irq.
+ * security_irq_sid - Obtain the SID for a physical irq.
  * @pirq: physical irq
  * @out_sid: security identifier
  */
-int security_pirq_sid(int pirq, u32 *out_sid)
+int security_irq_sid(int pirq, u32 *out_sid)
 {
     int rc = 0;
     struct ocontext *c;
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgU-0007F3-JU; Wed, 30 Nov 2011 23:35:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Dg-LV
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322696084!3576456!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2087 invoked from network); 30 Nov 2011 23:34:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-14.tower-174.messagelabs.com with SMTP;
	30 Nov 2011 23:34:45 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYhlP008866
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2Q032692; 
	Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:55 -0500
Message-Id: <1322696099-13849-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 4/8] xsm: always allow setting non-present PTEs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 2cb3e16..80c1f70 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1016,6 +1016,9 @@ static int flask_mmu_normal_update(struct domain *d, struct domain *f,
     struct domain_security_struct *dsec;
     u32 fsid;
 
+    if ( !(l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_PRESENT) )
+        return 0;
+
     dsec = d->ssid;
 
     if ( l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_RW )
@@ -1053,6 +1056,12 @@ static int flask_update_va_mapping(struct domain *d, struct domain *f,
     unsigned long mfn;
     struct domain_security_struct *dsec;
 
+    if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) )
+        return 0;
+
+    if ( l1e_get_flags(pte) & _PAGE_RW )
+        map_perms |= MMU__MAP_WRITE;
+
     dsec = d->ssid;
 
     mfn = get_gfn_untyped(f, l1e_get_pfn(pte));
@@ -1060,9 +1069,6 @@ static int flask_update_va_mapping(struct domain *d, struct domain *f,
     if ( rc )
         return rc;
 
-    if ( l1e_get_flags(pte) & _PAGE_RW )
-        map_perms |= MMU__MAP_WRITE;
-
     return avc_has_perm(dsec->sid, psid, SECCLASS_MMU, map_perms, NULL);
 }
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgU-0007F3-JU; Wed, 30 Nov 2011 23:35:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Dg-LV
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-174.messagelabs.com!1322696084!3576456!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2087 invoked from network); 30 Nov 2011 23:34:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-14.tower-174.messagelabs.com with SMTP;
	30 Nov 2011 23:34:45 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYhlP008866
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2Q032692; 
	Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:55 -0500
Message-Id: <1322696099-13849-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 4/8] xsm: always allow setting non-present PTEs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 2cb3e16..80c1f70 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1016,6 +1016,9 @@ static int flask_mmu_normal_update(struct domain *d, struct domain *f,
     struct domain_security_struct *dsec;
     u32 fsid;
 
+    if ( !(l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_PRESENT) )
+        return 0;
+
     dsec = d->ssid;
 
     if ( l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_RW )
@@ -1053,6 +1056,12 @@ static int flask_update_va_mapping(struct domain *d, struct domain *f,
     unsigned long mfn;
     struct domain_security_struct *dsec;
 
+    if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) )
+        return 0;
+
+    if ( l1e_get_flags(pte) & _PAGE_RW )
+        map_perms |= MMU__MAP_WRITE;
+
     dsec = d->ssid;
 
     mfn = get_gfn_untyped(f, l1e_get_pfn(pte));
@@ -1060,9 +1069,6 @@ static int flask_update_va_mapping(struct domain *d, struct domain *f,
     if ( rc )
         return rc;
 
-    if ( l1e_get_flags(pte) & _PAGE_RW )
-        map_perms |= MMU__MAP_WRITE;
-
     return avc_has_perm(dsec->sid, psid, SECCLASS_MMU, map_perms, NULL);
 }
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgU-0007Ew-6u; Wed, 30 Nov 2011 23:35:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Dc-FD
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322696084!5619609!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10759 invoked from network); 30 Nov 2011 23:34:44 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-216.messagelabs.com with SMTP;
	30 Nov 2011 23:34:44 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYh44027128
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2M032692
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:51 -0500
Message-Id: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
Subject: [Xen-devel] [PATCH 0/8] XSM/FLASK updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This series is mostly cleanup and fixing bugs that have crept in; see
individual patch descriptions for details.

In their present state, these patches require a recompile of existing
XSM policy due to the changes in initial SIDs and permissions. If
backwards compatability with older policy (or newer policy used with
older hypervisors) is needed, the definitions for old permissions could
be left in by reverting the header file changes in #2 and not applying
#7.

[PATCH 1/8] flask: Fix policy build with new checkpolicy
[PATCH 2/8] xsm: remove unused xsm_assign_vector check
[PATCH 3/8] xsm: Revert "Fix xsm_mmu_* and xsm_update_va_mapping
[PATCH 4/8] xsm: always allow setting non-present PTEs
[PATCH 5/8] xsm: Expand I/O resource hooks
[PATCH 6/8] xsm: rename security_pirq_sid to security_irq_sid
[PATCH 7/8] xsm: clean up initial SIDs
[PATCH 8/8] flask: Add flask-label-pci tool

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:48 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgU-0007Ew-6u; Wed, 30 Nov 2011 23:35:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Dc-FD
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-216.messagelabs.com!1322696084!5619609!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10759 invoked from network); 30 Nov 2011 23:34:44 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-216.messagelabs.com with SMTP;
	30 Nov 2011 23:34:44 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYh44027128
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2M032692
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:51 -0500
Message-Id: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
Subject: [Xen-devel] [PATCH 0/8] XSM/FLASK updates
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This series is mostly cleanup and fixing bugs that have crept in; see
individual patch descriptions for details.

In their present state, these patches require a recompile of existing
XSM policy due to the changes in initial SIDs and permissions. If
backwards compatability with older policy (or newer policy used with
older hypervisors) is needed, the definitions for old permissions could
be left in by reverting the header file changes in #2 and not applying
#7.

[PATCH 1/8] flask: Fix policy build with new checkpolicy
[PATCH 2/8] xsm: remove unused xsm_assign_vector check
[PATCH 3/8] xsm: Revert "Fix xsm_mmu_* and xsm_update_va_mapping
[PATCH 4/8] xsm: always allow setting non-present PTEs
[PATCH 5/8] xsm: Expand I/O resource hooks
[PATCH 6/8] xsm: rename security_pirq_sid to security_irq_sid
[PATCH 7/8] xsm: clean up initial SIDs
[PATCH 8/8] flask: Add flask-label-pci tool

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgV-0007FI-G6; Wed, 30 Nov 2011 23:35:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Di-QF
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:25 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322696084!4478249!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13893 invoked from network); 30 Nov 2011 23:34:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-21.messagelabs.com with SMTP;
	30 Nov 2011 23:34:45 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYhlP008865
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2P032692; 
	Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:54 -0500
Message-Id: <1322696099-13849-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 3/8] xsm: Revert "Fix xsm_mmu_* and
	xsm_update_va_mapping hooks"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This reverts 23220:56a3b9c7367f, which removes all validation of the
target pages in the mapping. This crash was solved by properly marking
pages without known SIDs in 22207:20f139010445.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/mm.c     |   30 +++++++++++-------------------
 xen/include/xsm/xsm.h |   28 +++++++++++++---------------
 xen/xsm/dummy.c       |   11 +++++------
 xen/xsm/flask/hooks.c |   41 +++++++++++++++++++++++++++++++++--------
 4 files changed, 62 insertions(+), 48 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index b00c277..64af6ff 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3517,6 +3517,9 @@ int do_mmu_update(
         {
             p2m_type_t p2mt;
 
+            rc = xsm_mmu_normal_update(d, pg_owner, req.val);
+            if ( rc )
+                break;
             rc = -EINVAL;
 
             req.ptr -= cmd;
@@ -3545,14 +3548,6 @@ int do_mmu_update(
                           (unsigned long)(req.ptr & ~PAGE_MASK));
             page = mfn_to_page(mfn);
 
-            rc = xsm_mmu_normal_update(d, req.val, page);
-            if ( rc ) {
-                unmap_domain_page_with_cache(va, &mapcache);
-                put_page(page);
-                put_gfn(pt_owner, gmfn);
-                break;
-            }
-
             if ( page_lock(page) )
             {
                 switch ( page->u.inuse.type_info & PGT_type_mask )
@@ -3736,6 +3731,10 @@ int do_mmu_update(
             mfn = req.ptr >> PAGE_SHIFT;
             gpfn = req.val;
 
+            rc = xsm_mmu_machphys_update(d, mfn);
+            if ( rc )
+                break;
+
             if ( unlikely(!get_page_from_pagenr(mfn, pg_owner)) )
             {
                 MEM_LOG("Could not get page for mach->phys update");
@@ -3750,10 +3749,6 @@ int do_mmu_update(
                 break;
             }
 
-            rc = xsm_mmu_machphys_update(d, mfn_to_page(mfn));
-            if ( rc )
-                break;
-
             set_gpfn_from_mfn(mfn, gpfn);
 
             paging_mark_dirty(pg_owner, mfn);
@@ -4380,6 +4375,10 @@ static int __do_update_va_mapping(
 
     perfc_incr(calls_to_update_va);
 
+    rc = xsm_update_va_mapping(d, pg_owner, val);
+    if ( rc )
+        return rc;
+
     rc = -EINVAL;
     pl1e = guest_map_l1e(v, va, &gl1mfn);
     if ( unlikely(!pl1e || !get_page_from_pagenr(gl1mfn, d)) )
@@ -4399,13 +4398,6 @@ static int __do_update_va_mapping(
         goto out;
     }
 
-    rc = xsm_update_va_mapping(d, val, gl1pg);
-    if ( rc ) {
-        page_unlock(gl1pg);
-        put_page(gl1pg);
-        goto out;
-    }
-
     rc = mod_l1_entry(pl1e, val, gl1mfn, 0, v, pg_owner);
 
     page_unlock(gl1pg);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 82f510d..da1f5d0 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -141,12 +141,11 @@ struct xsm_operations {
     int (*getidletime) (void);
     int (*machine_memory_map) (void);
     int (*domain_memory_map) (struct domain *d);
-    int (*mmu_normal_update) (struct domain *d,
-			      intpte_t fpte, struct page_info *page);
-    int (*mmu_machphys_update) (struct domain *d, struct page_info *page);
-    int (*update_va_mapping) (struct domain *d,
-			      l1_pgentry_t pte,
-			      struct page_info *page);
+    int (*mmu_normal_update) (struct domain *d, struct domain *f, 
+                                                                intpte_t fpte);
+    int (*mmu_machphys_update) (struct domain *d, unsigned long mfn);
+    int (*update_va_mapping) (struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
@@ -594,22 +593,21 @@ static inline int xsm_domain_memory_map(struct domain *d)
     return xsm_call(domain_memory_map(d));
 }
 
-static inline int xsm_mmu_normal_update (struct domain *d,
-					 intpte_t fpte, struct page_info *page)
+static inline int xsm_mmu_normal_update (struct domain *d, struct domain *f, 
+                                                                intpte_t fpte)
 {
-    return xsm_call(mmu_normal_update(d, fpte, page));
+    return xsm_call(mmu_normal_update(d, f, fpte));
 }
 
-static inline int xsm_mmu_machphys_update (struct domain *d, struct page_info *page)
+static inline int xsm_mmu_machphys_update (struct domain *d, unsigned long mfn)
 {
-    return xsm_call(mmu_machphys_update(d, page));
+    return xsm_call(mmu_machphys_update(d, mfn));
 }
 
-static inline int xsm_update_va_mapping(struct domain *d,
-					l1_pgentry_t pte,
-					struct page_info *page)
+static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte)
 {
-    return xsm_call(update_va_mapping(d, pte, page));
+    return xsm_call(update_va_mapping(d, f, pte));
 }
 
 static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 1b50d0e..ef461e6 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -400,20 +400,19 @@ static int dummy_domain_memory_map (struct domain *d)
     return 0;
 }
 
-static int dummy_mmu_normal_update (struct domain *d,
-				    intpte_t fpte, struct page_info *page)
+static int dummy_mmu_normal_update (struct domain *d, struct domain *f, 
+                                                                intpte_t fpte)
 {
     return 0;
 }
 
-static int dummy_mmu_machphys_update (struct domain *d, struct page_info *page)
+static int dummy_mmu_machphys_update (struct domain *d, unsigned long mfn)
 {
     return 0;
 }
 
-static int dummy_update_va_mapping (struct domain *d,
-				    l1_pgentry_t pte,
-				    struct page_info *page)
+static int dummy_update_va_mapping (struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte)
 {
     return 0;
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 97ae4d9..2cb3e16 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -348,6 +348,26 @@ static int get_page_sid(struct page_info *page, u32 *sid)
     return rc;
 }
 
+static int get_mfn_sid(unsigned long mfn, u32 *sid)
+{
+    int rc = 0;
+    struct page_info *page;
+
+    if ( mfn_valid(mfn) )
+    {
+        /*mfn is valid if this is a page that Xen is tracking!*/
+        page = mfn_to_page(mfn);
+        rc = get_page_sid(page, sid);
+    }
+    else
+    {
+        /*Possibly an untracked IO page?*/
+        rc = security_iomem_sid(mfn, sid);
+    }
+
+    return rc;    
+}
+
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -987,11 +1007,12 @@ static int flask_domain_memory_map(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
-static int flask_mmu_normal_update(struct domain *d, 
-                                   intpte_t fpte, struct page_info *page)
+static int flask_mmu_normal_update(struct domain *d, struct domain *f, 
+                                   intpte_t fpte)
 {
     int rc = 0;
     u32 map_perms = MMU__MAP_READ;
+    unsigned long fmfn;
     struct domain_security_struct *dsec;
     u32 fsid;
 
@@ -1000,38 +1021,42 @@ static int flask_mmu_normal_update(struct domain *d,
     if ( l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_RW )
         map_perms |= MMU__MAP_WRITE;
 
-    rc = get_page_sid(page, &fsid);
+    fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte)));
+
+    rc = get_mfn_sid(fmfn, &fsid);
     if ( rc )
         return rc;
 
     return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, NULL);
 }
 
-static int flask_mmu_machphys_update(struct domain *d, struct page_info *page)
+static int flask_mmu_machphys_update(struct domain *d, unsigned long mfn)
 {
     int rc = 0;
     u32 psid;
     struct domain_security_struct *dsec;
     dsec = d->ssid;
 
-    rc = get_page_sid(page, &psid);
+    rc = get_mfn_sid(mfn, &psid);
     if ( rc )
         return rc;
 
     return avc_has_perm(dsec->sid, psid, SECCLASS_MMU, MMU__UPDATEMP, NULL);
 }
 
-static int flask_update_va_mapping(struct domain *d,
-                                   l1_pgentry_t pte, struct page_info *page)
+static int flask_update_va_mapping(struct domain *d, struct domain *f,
+                                   l1_pgentry_t pte)
 {
     int rc = 0;
     u32 psid;
     u32 map_perms = MMU__MAP_READ;
+    unsigned long mfn;
     struct domain_security_struct *dsec;
 
     dsec = d->ssid;
 
-    rc = get_page_sid(page, &psid);
+    mfn = get_gfn_untyped(f, l1e_get_pfn(pte));
+    rc = get_mfn_sid(mfn, &psid);
     if ( rc )
         return rc;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Nov 30 23:35:49 2011
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 30 Nov 2011 23:35:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RVtgV-0007FI-G6; Wed, 30 Nov 2011 23:35:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RVtgS-0007Di-QF
	for xen-devel@lists.xensource.com; Wed, 30 Nov 2011 23:35:25 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-21.messagelabs.com!1322696084!4478249!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13893 invoked from network); 30 Nov 2011 23:34:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-21.messagelabs.com with SMTP;
	30 Nov 2011 23:34:45 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	pAUNYhlP008865
	for <xen-devel@lists.xensource.com>; Wed, 30 Nov 2011 23:34:43 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id pAUNYh2P032692; 
	Wed, 30 Nov 2011 18:34:43 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 30 Nov 2011 18:34:54 -0500
Message-Id: <1322696099-13849-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.3
In-Reply-To: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1322696099-13849-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 3/8] xsm: Revert "Fix xsm_mmu_* and
	xsm_update_va_mapping hooks"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This reverts 23220:56a3b9c7367f, which removes all validation of the
target pages in the mapping. This crash was solved by properly marking
pages without known SIDs in 22207:20f139010445.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/mm.c     |   30 +++++++++++-------------------
 xen/include/xsm/xsm.h |   28 +++++++++++++---------------
 xen/xsm/dummy.c       |   11 +++++------
 xen/xsm/flask/hooks.c |   41 +++++++++++++++++++++++++++++++++--------
 4 files changed, 62 insertions(+), 48 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index b00c277..64af6ff 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3517,6 +3517,9 @@ int do_mmu_update(
         {
             p2m_type_t p2mt;
 
+            rc = xsm_mmu_normal_update(d, pg_owner, req.val);
+            if ( rc )
+                break;
             rc = -EINVAL;
 
             req.ptr -= cmd;
@@ -3545,14 +3548,6 @@ int do_mmu_update(
                           (unsigned long)(req.ptr & ~PAGE_MASK));
             page = mfn_to_page(mfn);
 
-            rc = xsm_mmu_normal_update(d, req.val, page);
-            if ( rc ) {
-                unmap_domain_page_with_cache(va, &mapcache);
-                put_page(page);
-                put_gfn(pt_owner, gmfn);
-                break;
-            }
-
             if ( page_lock(page) )
             {
                 switch ( page->u.inuse.type_info & PGT_type_mask )
@@ -3736,6 +3731,10 @@ int do_mmu_update(
             mfn = req.ptr >> PAGE_SHIFT;
             gpfn = req.val;
 
+            rc = xsm_mmu_machphys_update(d, mfn);
+            if ( rc )
+                break;
+
             if ( unlikely(!get_page_from_pagenr(mfn, pg_owner)) )
             {
                 MEM_LOG("Could not get page for mach->phys update");
@@ -3750,10 +3749,6 @@ int do_mmu_update(
                 break;
             }
 
-            rc = xsm_mmu_machphys_update(d, mfn_to_page(mfn));
-            if ( rc )
-                break;
-
             set_gpfn_from_mfn(mfn, gpfn);
 
             paging_mark_dirty(pg_owner, mfn);
@@ -4380,6 +4375,10 @@ static int __do_update_va_mapping(
 
     perfc_incr(calls_to_update_va);
 
+    rc = xsm_update_va_mapping(d, pg_owner, val);
+    if ( rc )
+        return rc;
+
     rc = -EINVAL;
     pl1e = guest_map_l1e(v, va, &gl1mfn);
     if ( unlikely(!pl1e || !get_page_from_pagenr(gl1mfn, d)) )
@@ -4399,13 +4398,6 @@ static int __do_update_va_mapping(
         goto out;
     }
 
-    rc = xsm_update_va_mapping(d, val, gl1pg);
-    if ( rc ) {
-        page_unlock(gl1pg);
-        put_page(gl1pg);
-        goto out;
-    }
-
     rc = mod_l1_entry(pl1e, val, gl1mfn, 0, v, pg_owner);
 
     page_unlock(gl1pg);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 82f510d..da1f5d0 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -141,12 +141,11 @@ struct xsm_operations {
     int (*getidletime) (void);
     int (*machine_memory_map) (void);
     int (*domain_memory_map) (struct domain *d);
-    int (*mmu_normal_update) (struct domain *d,
-			      intpte_t fpte, struct page_info *page);
-    int (*mmu_machphys_update) (struct domain *d, struct page_info *page);
-    int (*update_va_mapping) (struct domain *d,
-			      l1_pgentry_t pte,
-			      struct page_info *page);
+    int (*mmu_normal_update) (struct domain *d, struct domain *f, 
+                                                                intpte_t fpte);
+    int (*mmu_machphys_update) (struct domain *d, unsigned long mfn);
+    int (*update_va_mapping) (struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
@@ -594,22 +593,21 @@ static inline int xsm_domain_memory_map(struct domain *d)
     return xsm_call(domain_memory_map(d));
 }
 
-static inline int xsm_mmu_normal_update (struct domain *d,
-					 intpte_t fpte, struct page_info *page)
+static inline int xsm_mmu_normal_update (struct domain *d, struct domain *f, 
+                                                                intpte_t fpte)
 {
-    return xsm_call(mmu_normal_update(d, fpte, page));
+    return xsm_call(mmu_normal_update(d, f, fpte));
 }
 
-static inline int xsm_mmu_machphys_update (struct domain *d, struct page_info *page)
+static inline int xsm_mmu_machphys_update (struct domain *d, unsigned long mfn)
 {
-    return xsm_call(mmu_machphys_update(d, page));
+    return xsm_call(mmu_machphys_update(d, mfn));
 }
 
-static inline int xsm_update_va_mapping(struct domain *d,
-					l1_pgentry_t pte,
-					struct page_info *page)
+static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte)
 {
-    return xsm_call(update_va_mapping(d, pte, page));
+    return xsm_call(update_va_mapping(d, f, pte));
 }
 
 static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 1b50d0e..ef461e6 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -400,20 +400,19 @@ static int dummy_domain_memory_map (struct domain *d)
     return 0;
 }
 
-static int dummy_mmu_normal_update (struct domain *d,
-				    intpte_t fpte, struct page_info *page)
+static int dummy_mmu_normal_update (struct domain *d, struct domain *f, 
+                                                                intpte_t fpte)
 {
     return 0;
 }
 
-static int dummy_mmu_machphys_update (struct domain *d, struct page_info *page)
+static int dummy_mmu_machphys_update (struct domain *d, unsigned long mfn)
 {
     return 0;
 }
 
-static int dummy_update_va_mapping (struct domain *d,
-				    l1_pgentry_t pte,
-				    struct page_info *page)
+static int dummy_update_va_mapping (struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte)
 {
     return 0;
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 97ae4d9..2cb3e16 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -348,6 +348,26 @@ static int get_page_sid(struct page_info *page, u32 *sid)
     return rc;
 }
 
+static int get_mfn_sid(unsigned long mfn, u32 *sid)
+{
+    int rc = 0;
+    struct page_info *page;
+
+    if ( mfn_valid(mfn) )
+    {
+        /*mfn is valid if this is a page that Xen is tracking!*/
+        page = mfn_to_page(mfn);
+        rc = get_page_sid(page, sid);
+    }
+    else
+    {
+        /*Possibly an untracked IO page?*/
+        rc = security_iomem_sid(mfn, sid);
+    }
+
+    return rc;    
+}
+
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -987,11 +1007,12 @@ static int flask_domain_memory_map(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
-static int flask_mmu_normal_update(struct domain *d, 
-                                   intpte_t fpte, struct page_info *page)
+static int flask_mmu_normal_update(struct domain *d, struct domain *f, 
+                                   intpte_t fpte)
 {
     int rc = 0;
     u32 map_perms = MMU__MAP_READ;
+    unsigned long fmfn;
     struct domain_security_struct *dsec;
     u32 fsid;
 
@@ -1000,38 +1021,42 @@ static int flask_mmu_normal_update(struct domain *d,
     if ( l1e_get_flags(l1e_from_intpte(fpte)) & _PAGE_RW )
         map_perms |= MMU__MAP_WRITE;
 
-    rc = get_page_sid(page, &fsid);
+    fmfn = get_gfn_untyped(f, l1e_get_pfn(l1e_from_intpte(fpte)));
+
+    rc = get_mfn_sid(fmfn, &fsid);
     if ( rc )
         return rc;
 
     return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, NULL);
 }
 
-static int flask_mmu_machphys_update(struct domain *d, struct page_info *page)
+static int flask_mmu_machphys_update(struct domain *d, unsigned long mfn)
 {
     int rc = 0;
     u32 psid;
     struct domain_security_struct *dsec;
     dsec = d->ssid;
 
-    rc = get_page_sid(page, &psid);
+    rc = get_mfn_sid(mfn, &psid);
     if ( rc )
         return rc;
 
     return avc_has_perm(dsec->sid, psid, SECCLASS_MMU, MMU__UPDATEMP, NULL);
 }
 
-static int flask_update_va_mapping(struct domain *d,
-                                   l1_pgentry_t pte, struct page_info *page)
+static int flask_update_va_mapping(struct domain *d, struct domain *f,
+                                   l1_pgentry_t pte)
 {
     int rc = 0;
     u32 psid;
     u32 map_perms = MMU__MAP_READ;
+    unsigned long mfn;
     struct domain_security_struct *dsec;
 
     dsec = d->ssid;
 
-    rc = get_page_sid(page, &psid);
+    mfn = get_gfn_untyped(f, l1e_get_pfn(pte));
+    rc = get_mfn_sid(mfn, &psid);
     if ( rc )
         return rc;
 
-- 
1.7.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel